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
