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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]>: > >> > >> 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 > >> <[EMAIL PROTECTED]> 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 > >> >> <[EMAIL PROTECTED]> 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 > >> >>>>>> <[EMAIL PROTECTED]> 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 > >> >>>>>> [email protected] > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> osg-users mailing list > >> >>>>> [email protected] > >> >>>>> > >> >>>>> > >> >>>>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> >>>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > -------------------------------------------------------------------------------- > >> >>> > >> >>> > >> >>>> _______________________________________________ > >> >>>> osg-users mailing list > >> >>>> [email protected] > >> >>>> > >> >>>> > >> >>>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> >>>> > >> >>> > >> >>> _______________________________________________ > >> >>> osg-users mailing list > >> >>> [email protected] > >> >>> > >> >>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> >>> > >> >>> > >> >> _______________________________________________ > >> >> osg-users mailing list > >> >> [email protected] > >> >> > >> >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > > >> > _______________________________________________ > >> > osg-users mailing list > >> > [email protected] > >> > > >> > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > > >> _______________________________________________ > >> osg-users mailing list > >> [email protected] > >> > 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 > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > _______________________________________________ > osg-users mailing list > [email protected] > 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 [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
