[osg-users] Workaround for the problems in OSG / XP / multimonitor/ multithreaded / NVidia

Robert Osfield robert.osfield at gmail.com
Thu Jul 3 01:30:54 PDT 2008


Hi Amalric,

Wojtek's workaround for the NVidia driver bug was only required for
XP, it wasn't required for Visita previosly.   If you have problems
with wglMakeCurrent failing under Visita then this it's likely to be a
totally different issue.

To find out the cause of the problems you are seeing you are best to
start a new thread, and in details explain what in your setup works
and what doesn't then others can help step through to see if they see
the same problems, and steadily work towards getting a better picture
of what works where and finally to some kind of recommendation of what
to do about it.  It could be a driver bug, it could be an OSG bug, it
could be an OS bug, it could be hardware fault, it could be an
application error, sooo many different options.  Piggybacking of this
thread is not the place to do it as it'll only confuse two different
issues.

Robert.

On Thu, Jul 3, 2008 at 9:15 AM, amalric alexandre <alex.pixxim at gmail.com> wrote:
> Hi osg-users,
>
> I am currently having problems with wglMakeCurrent wich fails every time it
> is called in
>
> bool GraphicsWindowWin32::makeCurrentImplementation()
>
> Is the fix working for every users ? am I the only one with this behaviour ?
>
> I am using OSG 2.5.3, Vista and NVIDIA 7900GS (forceware 175.19).
> Kind regards
> 2008/5/28 Robert Osfield <robert.osfield at gmail.com>:
>>
>> Hi Wojtek, thanks for clarification, I've gone ahead and merged the
>> workaround as it looks perfectly benign.
>>
>> On Wed, May 28, 2008 at 3:54 PM, Wojciech Lewandowski
>> <lewandowski at ai.com.pl> wrote:
>> > Hi Robert,
>> >
>> > I use it and have not observed any issues. I would say its rather safe.
>> >
>> > I reported this bug to NVidia. And it looks like they are doing
>> > something to
>> > fix the problem. In the meantime they sent me two bit cryptic emails
>> > informing they verified and fixed it. Last email was also saying that
>> > fix is
>> > awaiting for final verification and closure. I don't know when they make
>> > fixed drivers available, though, so I would vote for merging my
>> > workaround
>> > for time being.
>> >
>> > I promise I will let you know or even send the submission removing this
>> > workaround when NVidia informs me that fixed drivers are available.
>> >
>> > Cheers,
>> > Wojtek
>> >
>> >
>> >
>> >> Hi Wojtek,
>> >>
>> >> I'm just following up on your workaround for the NVidia WindowsXP
>> >> multi-thread make current bug.   Others have reported problems since
>> >> you posted your fix, and while I know the bug is now Nvidia have
>> >> acknowledged the problem, we don't yet know how long it might be to a
>> >> fix... so I'm tempted to merge your workaround.
>> >>
>> >> Thoughts?
>> >> Robert.
>> >>
>> >> On Mon, May 12, 2008 at 1:28 PM, Wojciech Lewandowski
>> >> <lewandowski at ai.com.pl> wrote:
>> >>>
>> >>> Hi again,
>> >>>
>> >>> I have modified GraphicsWindowWin32::makeCurrentImplementation method.
>> >>> Code
>> >>> attached. This modification solves both garbage in
>> >>> TriangleStrip/TriangleFans and FBO problems. So a complete succes for
>> >>> me
>> >>> ;-)
>> >>>
>> >>> I am posting it on osg users forum instead of osg submissions because
>> >>> I
>> >>> expecty we want some discussion before submitting it.
>> >>>
>> >>> I don't know how this workaroud should be additionaly wrapped. In this
>> >>> form
>> >>> its alredy rather non aggressive - second wglMakeCurrent will be
>> >>> called
>> >>> fairly seldom.  What additional conditions we would like to see tested
>> >>> before applying this worakoround. Any suggestions ? Should I check
>> >>> GL_VENDOR, GL_RENDERER, GL_VERSION strings ? Does OSG offer some
>> >>> methods
>> >>> to
>> >>> query OS, drivers version ?
>> >>>
>> >>> Maybe othe places in the code are more appriopriate for this call.
>> >>>
>> >>> Cheers,
>> >>> Wojtek
>> >>>
>> >>>> Hi Everyone,
>> >>>>
>> >>>> Lets get back to the main topic of this thread ie garbage in
>> >>>> Multicore
>> >>>> CPU
>> >>>> /
>> >>>> NVidia / DualView / Window XP.
>> >>>>
>> >>>> I attached my OpenGL repro for those who are interested. I would be
>> >>>> grateful
>> >>>> if somoene could check if my threading code is OK (and maybe simplify
>> >>>> it).
>> >>>> If it is, I will try to submit the bug to NVidia.
>> >>>>
>> >>>> Check out what happens when  repeatMakeCurrent variable gets changed
>> >>>> to
>> >>>> non
>> >>>> zero value. This causes repetition of wglMakeCurrent and fixes the
>> >>>> issue.
>> >>>> I
>> >>>> will try to check this method in OSG next week.
>> >>>>
>> >>>> I am heading back home for the weekend. I will stay online but I
>> >>>> don't
>> >>>> have
>> >>>> multicore CPU there so I won't be able to check codes till monday.
>> >>>>
>> >>>> Cheers,
>> >>>> Wojtek Lewandowski
>> >>>>
>> >>>>
>> >>>>> Hi Robert, Paul and J-S,
>> >>>>>
>> >>>>> I don't think I was clear enough. Its too early to say that
>> >>>>> wglMakeCurrent
>> >>>>> will be a good workaround for OSG.
>> >>>>> I only said that it "relaxed" the problem in my OpenGL repro.
>> >>>>>
>> >>>>> It looks like first wglMakeCurrent (when renderer thread is started)
>> >>>>> does
>> >>>>> not initialize properly some internal OpenGL context data. If I
>> >>>>> repeat
>> >>>>> it
>> >>>>> in second frame everything becomes correct. So if wglMakeCurrent was
>> >>>>> a
>> >>>>> solution it would be needed only once more on frame.
>> >>>>>
>> >>>>> But I learned all this using my open gl repro without Display Lists
>> >>>>> and
>> >>>>> to
>> >>>>> be honest I did not checked what will happen if DisplayLists are
>> >>>>> generated
>> >>>>> on a first frame (like OSG does). I suspect they might stay screwed
>> >>>>> even
>> >>>>> if second wglMAkeCurrent gets called.  I am currently trying to
>> >>>>> check
>> >>>>> this
>> >>>>> out. I just need some more time to investigate.
>> >>>>>
>> >>>>> I got some questions regarding this issue so I decided to inform
>> >>>>> guys
>> >>>>> for
>> >>>>> whom this is relevant by posting on osg-users. I am certainly far
>> >>>>> from
>> >>>>> proposing fixes at this moment.
>> >>>>>
>> >>>>> Wojtek
>> >>>>>
>> >>>>>
>> >>>>>> Hi Wojciech,
>> >>>>>>
>> >>>>>> On Fri, May 9, 2008 at 2:16 PM, Wojciech Lewandowski
>> >>>>>> <lewandowski at ai.com.pl> wrote:
>> >>>>>>>
>> >>>>>>> Problem could be relaxed when wglMakeCurrent gets called before
>> >>>>>>> each
>> >>>>>>> frame
>> >>>>>>> rendering. I noticed that artifacts appeared when wglMakeCurrent
>> >>>>>>> was
>> >>>>>>> called
>> >>>>>>> only once while worker rendering thread initialization . When
>> >>>>>>> wglMakeCurrent
>> >>>>>>> was called every frame artifacts did not appear.
>> >>>>>>
>> >>>>>> wglMakeCurrent "shouldn't" be required if one has a thread per
>> >>>>>> context, one a thread does a wglMakeCurrent() it shouldn't release
>> >>>>>> the
>> >>>>>> context till this thread calls release context (done with
>> >>>>>> wglMakeCurrent(_hdc, NULL)).
>> >>>>>>
>> >>>>>> As you are finding that the wglMakeCurrent() per frame is required,
>> >>>>>> this either suggests that the OpenGL driver is playing fast and
>> >>>>>> loose
>> >>>>>> with the graphics context behind the scenes so the app looses the
>> >>>>>> context being current, in which case this is very much a driver
>> >>>>>> bug,
>> >>>>>> or that the OSG itself is doing makeCurrent on the context from
>> >>>>>> another thread or releasing the context when it shouldn't.
>> >>>>>>
>> >>>>>> Could you put some debug output into GraphicsWindowWin32.cpp's
>> >>>>>> makeCurrentImplementation(..) and relaseContextImplementation(..)
>> >>>>>> to
>> >>>>>> see if there are being called when you wouldn't expect, printing
>> >>>>>> out
>> >>>>>> the
>> >>>>>> pointer to the current thread would be useful as well.
>> >>>>>>
>> >>>>>> Robert.
>> >>>>>> _______________________________________________
>> >>>>>> osg-users mailing list
>> >>>>>> osg-users at lists.openscenegraph.org
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> osg-users mailing list
>> >>>>> osg-users at lists.openscenegraph.org
>> >>>>>
>> >>>>>
>> >>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --------------------------------------------------------------------------------
>> >>>
>> >>>
>> >>>> _______________________________________________
>> >>>> osg-users mailing list
>> >>>> osg-users at lists.openscenegraph.org
>> >>>>
>> >>>>
>> >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >>>>
>> >>>
>> >>> _______________________________________________
>> >>> osg-users mailing list
>> >>> osg-users at lists.openscenegraph.org
>> >>>
>> >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >>>
>> >>>
>> >> _______________________________________________
>> >> osg-users mailing list
>> >> osg-users at lists.openscenegraph.org
>> >>
>> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >
>> > _______________________________________________
>> > osg-users mailing list
>> > osg-users at lists.openscenegraph.org
>> >
>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
> --
> Alexandre AMALRIC Ingénieur R&D
> ===================================
> PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
> http://www.pixxim.fr
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



More information about the osg-users mailing list