Hi Wojtek, I'd be inclined to keep that hack in there for a while longer. It isn't doing any harm.
Robert. On Wed, Aug 27, 2008 at 8:58 AM, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote: > Hi All, > > Yesterday on Nvidia website appeared new driver version 177.92. I made a > check and it looks like this driver fixes the issues for which I made my > duplicated MakeCurrentContext workaround. So it looks like we may now remove > this workaround. > Unfortunately this driver has Beta status and is not yet available from WHQL > certified list. Its available through beta drivers download. > So I would wait a little bit more until this driver becomes official latest > driver for GeForce 6,7,8,9,200 for WinXP. > Let me know what is your opinion. If you prefer to act early I may send a > submission with former workaround wrapped with #if 0 and modified comment > saying "that new drivers exist where its not needed anymore". > > Cheers, > Wojtek > > > > > > > >> 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
