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
