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
