nVidia FP uniforms driver optimization lags

[Jackis]

Hi all!

Some time ago we wrote about very strange problem, causing a driver to stall for some dramatic time, when FP uniforms are changed (or set for the very 1st time) and some geometry were drawn, but not even a bit of comments were got, except for other people complained about pretty the same problem and the official advice to pre-render everything (which is not fairly well in most cases).

But the problem were found and localized - nVidia drivers don't like exact numbers like +-0.0f, +-0.5f and +-1.0f in FP uniform constant!!! Changing even a bit of mantissa of these "magic" values fixes almost all our problems. To all appearances, taking into consideration FP uniforms "constant" nature, driver thinks that it can improve this shader in order to make it much more fast and powerful (sic), and it creates unique shader realisation for this FP uniform value sub-set!

So please bear in mind, that some optimizations may be wanted to take place right in the middle of your application's execution.

Hope, that helps someone, who wrecked not a single week to localize, why sometimes lags take places.

[Jeff Russell]

Thank you, this is useful information.

[Zengar]

I would advice you submitting a test case to Nvidia, they should fix it.

[Jackis]

By the way, according to shader's complexity, this lag varies from 50 mS to 200 mS, which is unacceptable by all means.

[Don't Disturb]

Thanks from me also, a 50ms pause while my app is running would screw things up spectacularly!

[Dark Photon]

And please post a link to that test program on the forum too. I think many of us would like to try that test program to confirm it (lots of quick, free test data for you).

[Jackis]

By the way,

The same goes to GLSTATE uniform semantics. If you want to use state uniforms directly in your fragment shader, bear all these magic things in mind.
Even for glstate.light[0].position.

Tested on GeForceFX, GeForce6, GeForce7 on 93.71 forceware (the very last official drivers)

[Jackis]

Okey, back to this topic...

I had not enough time to make test app, but now I'm ready to post it.

I hoped, that this bug would be fixed, but it is not fixed yet, so we've got small test application, which creates some VBOs with the same shaders, which are copied number of times to force effect to appear. It renders 200 quads with 200 copies of the same shader and with unique VBO each.
Buttons 0,1,2,3,4,5 makes it to change one uniform, which presents in lighting calculation as simple additive value ('H' displays some help dialog).
0 - uniform is 0.300 (default)
1 - uniform is 0.000 exactly
2 - uniform is 0.001 exactly
3 - uniform is 0.500 exactly
4 - uniform is 0.999 exactly
5 - uniform is 1.000 exactly
After you push the button, program will measure next frame time.
As you may see, when we set this uniform to one of the "dangerous" values (0, 0.5, 1) for the first time, we've got big lag.
Nothing special, shader is very easy (if it were more complicated - delay would be much worse, but it's enough to see, that lag really takes place).

Link on test program with sources: http://slil.ru/24377623

By the way, NV30 and G80 generations are free from this issue, so, it happens on all GeForce6 and GeForce7 chips.

[Zengar]

I can confirm your results, I see it on my 7900gs too. OS is Vista with latest beta drivers.

[kon]

Tested on my 6800GO and I get the big delay only for the value 0.0 (key 1)!
Btw, why does the text in the menu bar changes after pressing it a second time?