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

amalric alexandre alex.pixxim at gmail.com
Thu Jul 3 02:13:05 PDT 2008


Hi Robert,

no need to start a new thread I found my mistake, I was using a

osg::ref_ptr<osgViewer::CompositeViewer>
instead of a

osgViewer::CompositeViewer*
Now the wglMakeCurrent is working correctly.

I don't understand why ref pointer produce this kinf of behaviour, sorry to
flood you like this.

Kind regards,

2008/7/3 Robert Osfield <robert.osfield at gmail.com>:

> 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
> >
> >
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080703/c30248fc/attachment-0003.htm>


More information about the osg-users mailing list