<div>Hi osg-users,</div>
<div> </div>
<div>I am currently having problems with wglMakeCurrent wich fails every time it is called in<font color="#0000ff" size="2"><font color="#0000ff" size="2"></font></font></div>
<p>bool<font size="2"> GraphicsWindowWin32::makeCurrentImplementation()</font></p>
<div>Is the fix working for every users ? am I the only one with this behaviour ?</div>
<div> </div>
<div>I am using OSG 2.5.3, Vista and NVIDIA 7900GS (forceware 175.19).<br></div>
<div>Kind regards<br></div>
<div class="gmail_quote">2008/5/28 Robert Osfield <<a href="mailto:robert.osfield@gmail.com">robert.osfield@gmail.com</a>>:<br>
<blockquote style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid" class="gmail_quote">Hi Wojtek, thanks for clarification, I've gone ahead and merged the<br>workaround as it looks perfectly benign.<br>
<br>On Wed, May 28, 2008 at 3:54 PM, Wojciech Lewandowski<br>
<div>
<div></div>
<div class="Wj3C7c"><<a href="mailto:lewandowski@ai.com.pl">lewandowski@ai.com.pl</a>> wrote:<br>> Hi Robert,<br>><br>> I use it and have not observed any issues. I would say its rather safe.<br>><br>> I reported this bug to NVidia. And it looks like they are doing something to<br>
> fix the problem. In the meantime they sent me two bit cryptic emails<br>> informing they verified and fixed it. Last email was also saying that fix is<br>> awaiting for final verification and closure. I don't know when they make<br>
> fixed drivers available, though, so I would vote for merging my workaround<br>> for time being.<br>><br>> I promise I will let you know or even send the submission removing this<br>> workaround when NVidia informs me that fixed drivers are available.<br>
><br>> Cheers,<br>> Wojtek<br>><br>><br>><br>>> Hi Wojtek,<br>>><br>>> I'm just following up on your workaround for the NVidia WindowsXP<br>>> multi-thread make current bug.   Others have reported problems since<br>
>> you posted your fix, and while I know the bug is now Nvidia have<br>>> acknowledged the problem, we don't yet know how long it might be to a<br>>> fix... so I'm tempted to merge your workaround.<br>
>><br>>> Thoughts?<br>>> Robert.<br>>><br>>> On Mon, May 12, 2008 at 1:28 PM, Wojciech Lewandowski<br>>> <<a href="mailto:lewandowski@ai.com.pl">lewandowski@ai.com.pl</a>> wrote:<br>
>>><br>>>> Hi again,<br>>>><br>>>> I have modified GraphicsWindowWin32::makeCurrentImplementation method.<br>>>> Code<br>>>> attached. This modification solves both garbage in<br>
>>> TriangleStrip/TriangleFans and FBO problems. So a complete succes for me<br>>>> ;-)<br>>>><br>>>> I am posting it on osg users forum instead of osg submissions because I<br>>>> expecty we want some discussion before submitting it.<br>
>>><br>>>> I don't know how this workaroud should be additionaly wrapped. In this<br>>>> form<br>>>> its alredy rather non aggressive - second wglMakeCurrent will be called<br>>>> fairly seldom.  What additional conditions we would like to see tested<br>
>>> before applying this worakoround. Any suggestions ? Should I check<br>>>> GL_VENDOR, GL_RENDERER, GL_VERSION strings ? Does OSG offer some methods<br>>>> to<br>>>> query OS, drivers version ?<br>
>>><br>>>> Maybe othe places in the code are more appriopriate for this call.<br>>>><br>>>> Cheers,<br>>>> Wojtek<br>>>><br>>>>> Hi Everyone,<br>>>>><br>
>>>> Lets get back to the main topic of this thread ie garbage in Multicore<br>>>>> CPU<br>>>>> /<br>>>>> NVidia / DualView / Window XP.<br>>>>><br>>>>> I attached my OpenGL repro for those who are interested. I would be<br>
>>>> grateful<br>>>>> if somoene could check if my threading code is OK (and maybe simplify<br>>>>> it).<br>>>>> If it is, I will try to submit the bug to NVidia.<br>>>>><br>
>>>> Check out what happens when  repeatMakeCurrent variable gets changed to<br>>>>> non<br>>>>> zero value. This causes repetition of wglMakeCurrent and fixes the<br>>>>> issue.<br>
>>>> I<br>>>>> will try to check this method in OSG next week.<br>>>>><br>>>>> I am heading back home for the weekend. I will stay online but I don't<br>>>>> have<br>
>>>> multicore CPU there so I won't be able to check codes till monday.<br>>>>><br>>>>> Cheers,<br>>>>> Wojtek Lewandowski<br>>>>><br>>>>><br>>>>>> Hi Robert, Paul and J-S,<br>
>>>>><br>>>>>> I don't think I was clear enough. Its too early to say that<br>>>>>> wglMakeCurrent<br>>>>>> will be a good workaround for OSG.<br>>>>>> I only said that it "relaxed" the problem in my OpenGL repro.<br>
>>>>><br>>>>>> It looks like first wglMakeCurrent (when renderer thread is started)<br>>>>>> does<br>>>>>> not initialize properly some internal OpenGL context data. If I repeat<br>
>>>>> it<br>>>>>> in second frame everything becomes correct. So if wglMakeCurrent was a<br>>>>>> solution it would be needed only once more on frame.<br>>>>>><br>
>>>>> But I learned all this using my open gl repro without Display Lists and<br>>>>>> to<br>>>>>> be honest I did not checked what will happen if DisplayLists are<br>>>>>> generated<br>
>>>>> on a first frame (like OSG does). I suspect they might stay screwed<br>>>>>> even<br>>>>>> if second wglMAkeCurrent gets called.  I am currently trying to check<br>>>>>> this<br>
>>>>> out. I just need some more time to investigate.<br>>>>>><br>>>>>> I got some questions regarding this issue so I decided to inform guys<br>>>>>> for<br>>>>>> whom this is relevant by posting on osg-users. I am certainly far from<br>
>>>>> proposing fixes at this moment.<br>>>>>><br>>>>>> Wojtek<br>>>>>><br>>>>>><br>>>>>>> Hi Wojciech,<br>>>>>>><br>
>>>>>> On Fri, May 9, 2008 at 2:16 PM, Wojciech Lewandowski<br>>>>>>> <<a href="mailto:lewandowski@ai.com.pl">lewandowski@ai.com.pl</a>> wrote:<br>>>>>>>><br>
>>>>>>> Problem could be relaxed when wglMakeCurrent gets called before each<br>>>>>>>> frame<br>>>>>>>> rendering. I noticed that artifacts appeared when wglMakeCurrent was<br>
>>>>>>> called<br>>>>>>>> only once while worker rendering thread initialization . When<br>>>>>>>> wglMakeCurrent<br>>>>>>>> was called every frame artifacts did not appear.<br>
>>>>>><br>>>>>>> wglMakeCurrent "shouldn't" be required if one has a thread per<br>>>>>>> context, one a thread does a wglMakeCurrent() it shouldn't release the<br>
>>>>>> context till this thread calls release context (done with<br>>>>>>> wglMakeCurrent(_hdc, NULL)).<br>>>>>>><br>>>>>>> As you are finding that the wglMakeCurrent() per frame is required,<br>
>>>>>> this either suggests that the OpenGL driver is playing fast and loose<br>>>>>>> with the graphics context behind the scenes so the app looses the<br>>>>>>> context being current, in which case this is very much a driver bug,<br>
>>>>>> or that the OSG itself is doing makeCurrent on the context from<br>>>>>>> another thread or releasing the context when it shouldn't.<br>>>>>>><br>>>>>>> Could you put some debug output into GraphicsWindowWin32.cpp's<br>
>>>>>> makeCurrentImplementation(..) and relaseContextImplementation(..) to<br>>>>>>> see if there are being called when you wouldn't expect, printing out<br>>>>>>> the<br>
>>>>>> pointer to the current thread would be useful as well.<br>>>>>>><br>>>>>>> Robert.<br>>>>>>> _______________________________________________<br>
>>>>>> osg-users mailing list<br>>>>>>> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>>>>>>><br>>>>>>><br>
>>>>>> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>>>>>><br>
>>>>> _______________________________________________<br>>>>>> osg-users mailing list<br>>>>>> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
>>>>><br>>>>>> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
>>>><br>>>><br>>>><br>>>><br>>>> --------------------------------------------------------------------------------<br>>>><br>>>><br>>>>> _______________________________________________<br>
>>>> osg-users mailing list<br>>>>> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>>>>><br>>>>> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
>>>><br>>>><br>>>> _______________________________________________<br>>>> osg-users mailing list<br>>>> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
>>> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>>>><br>>>><br>
>> _______________________________________________<br>>> osg-users mailing list<br>>> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>>> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
><br>> _______________________________________________<br>> osg-users mailing list<br>> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
><br>_______________________________________________<br>osg-users mailing list<br><a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br><a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Alexandre AMALRIC Ingénieur R&D<br>===================================<br>PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille<br><a href="http://www.pixxim.fr">http://www.pixxim.fr</a>