pouët.net

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()?
added on the 2007-07-10 16:20:47 by KeyJ KeyJ
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.
added on the 2007-07-10 17:22:52 by Gargaj Gargaj
Yeah, the cubes look different on my system (c2d, gf7800gtx).
And also runs ok with win98 compatibility mode.
added on the 2007-07-10 17:27:11 by zoom zoom
oh yeah, my laptop is ATI, sorry.
added on the 2007-07-10 17:31:46 by Gargaj Gargaj
Seems like someone is a bit careless with their thread-usage..
Oh and winxp sp2 here with driver version 94.24.
added on the 2007-07-10 17:44:39 by zoom zoom
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.
added on the 2007-07-10 17:50:20 by Rubicante Rubicante
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).
added on the 2007-07-10 18:17:25 by KeyJ KeyJ
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 :)
added on the 2007-07-11 13:21:06 by KeyJ KeyJ
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 :)
added on the 2007-07-11 15:14:49 by KeyJ KeyJ
KeyJ: yeah, looks like glinterleavedarrays()/gldrawelements() bugs on our end too at the particle render. Nice catch.
added on the 2007-07-11 16:30:54 by BoyC BoyC
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
added on the 2007-07-11 17:14:07 by SilkCut SilkCut
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 :)
added on the 2007-07-11 18:21:36 by KeyJ KeyJ
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

ffs, don't use opengl.
added on the 2007-07-11 18:45:57 by imbusy imbusy
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.
added on the 2007-07-11 20:12:39 by winden winden
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 :)
added on the 2007-07-11 20:33:17 by KeyJ KeyJ
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..

login