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 >>>>>> osg-users@lists.openscenegraph.org >>>>>> >>>>>> >>>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>>> >>>>> _______________________________________________ >>>>> osg-users mailing list >>>>> osg-users@lists.openscenegraph.org >>>>> >>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>> >>> >>> >>> >>> -------------------------------------------------------------------------------- >>> >>> >>>> _______________________________________________ >>>> osg-users mailing list >>>> osg-users@lists.openscenegraph.org >>>> >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>> >>> >>> _______________________________________________ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
