nVidia OpenGL driver bug?
category: general [glöplog]
I recently noticed a strange rendering issue I tracked down to what I think is a bug in nVidia's OpenGL driver. When using glInterleavedArrays()/glDrawElements() on systems equipped with multi-core CPUs, the driver will still use the vertex and index data even _after_ glDrawElements() returns. Thus, if I re-use the memory occupied by the vertices and indices directly after that call, I get incorrect results.
I'm reluctant to file this bug to nVidia without confirmation, so I wrote a small test application to check for this behaviour:
http://keyj.s2000.ws/?p=67#nvbug
I would be grateful if some of you could run that test on their machines (big fat warning: it might also crash your system, so please save your work first). The results of nVidia-GPU and dual-core-CPU users are most important, but everyone else is invited, too :) Or am I maybe completely wrong and I can indeed not rely on the atomicity of glDrawElements()?
I'm reluctant to file this bug to nVidia without confirmation, so I wrote a small test application to check for this behaviour:
http://keyj.s2000.ws/?p=67#nvbug
I would be grateful if some of you could run that test on their machines (big fat warning: it might also crash your system, so please save your work first). The results of nVidia-GPU and dual-core-CPU users are most important, but everyone else is invited, too :) Or am I maybe completely wrong and I can indeed not rely on the atomicity of glDrawElements()?
Interestingly it works on a Core2duo centrino.
Also, we seem to have a similar problem with our intros considering the particles - Zoom says it works in win98 compatibility mode, try that.
Also, we seem to have a similar problem with our intros considering the particles - Zoom says it works in win98 compatibility mode, try that.
Yeah, the cubes look different on my system (c2d, gf7800gtx).
And also runs ok with win98 compatibility mode.
And also runs ok with win98 compatibility mode.
oh yeah, my laptop is ATI, sorry.
Seems like someone is a bit careless with their thread-usage..
Oh and winxp sp2 here with driver version 94.24.
looked through the source and the binary, I will have to get home to try it on my geforce though. My laptop has ATI and it also worked fine.
It makes pretty much sense that Win98 compatibility mode helps with the issue, because this option forces the application to run on a single core (among other things).
maybe it's also related to the stuff described here?
http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=015274
http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=015274
Thanks for the hint, but the problem is only remotely related to what we're dealing with here. I wouldn't mind slow rendering as much as wrong rendering (let alone bluescreens), but this is what I observed :)
Works fine on the NVidia Quadro 4 NVS card
rasmus: Fine, but what kind of processor do you have? I bet it's a single-core model :)
KeyJ: yeah, looks like glinterleavedarrays()/gldrawelements() bugs on our end too at the particle render. Nice catch.
I will test this tonight at home but I am pretty sure I have the same problems (duo core E6600, 7600GT). I already mentioned this on pouet some months ago, but everyone said I should just update the drivers. I noticed it with MFX, Conspiracy and ASD demos.
jarig
In 3 days, yes!
KeyJ: What happens if you do a glGetIntegerv( GL_VIEWPORT, &foo) after the first EndList() (before modifying the cube)? ;)
Slummy: Interestingly, this solves the problem. Reading any of the states seems to help -- a simple glIsEnabled(GL_SOME_FREAKIN_STATE) does the trick, too. I just have no idea why :)
BTW, I also tried glFlush() which I thought is supposed to do the same thing ... but actually, it made matters worse, the cube looked really weird that way :)
BTW, I also tried glFlush() which I thought is supposed to do the same thing ... but actually, it made matters worse, the cube looked really weird that way :)
Ok, it bugs like expected.
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce 7600 GT/PCI/SSE2
OpenGL version: 2.1.1
CPU name: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce 7600 GT/PCI/SSE2
OpenGL version: 2.1.1
CPU name: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
ffs, don't use opengl.
KeyJ: Reading back state forces a flush of all the pipelined/queued driver operations running in the drivers own separate thread, before returning from the function. Calling glFlush just ensures that the internal state of the graphics system (driver & hw) will resolve "within finite time", it doesn't give you any guarantees regarding what state it is in when the function call returns.
so it's doing async processing/upload of the vertex data... this seems like an improvement for me! the solution is to place a glFence() after the glDrawWhatever() and a glWaitFence() just before starting to modify again these arrays.
Yes, it is a performance improvement, without any doubt. But if it comes at the cost of breaking stuff and violating the spec, it's not OK either :)
It's a bug in a performance-improvement.. However, this is enough serious pouet-posting for now.. I'm off to pollute diskmag-threads with photos of hairy transexuals with fish up their bums..