NVIDIA run-time shader re-compilation

[jpchristin]

Hi,

I’m working on a real-time simulation (60hz) and I'm trying to avoid all the run-time shaders re-compilation. I already find out many state changes that are triggering shaders re-compilation. To avoid having these performances glitches while running the application, I make sure to trigger all the known cases at startup.

Here is the list of the cases that triggers shaders re-compilation:
- Activating / Deactivating GL_LIGHT*
- Activating / Deactivating GL_CLIP_PLANE*
- Activating / Deactivating GL_MULTISAMPLE
- Changing glShadeModel
- Texture format changes (using a same texture unit between some formats cause re-compilation)
- Some uniforms changes (this can be deactivated by using a given NVIDIA profile)

Does anyone have a complete list of all the states that triggers shaders re-compilation on NVIDIA?

Also, does anyone know how to deactivate these shaders re-compilation on NVIDIA? Is there a way to deactivate these re-compilations at run-time?!

Thanks!

J-P

[Dark Photon]

I’m working on a real-time simulation (60hz) and I'm trying to avoid all the run-time shaders re-compilation. I already find out many state changes that are triggering shaders re-compilation. To avoid having these performances glitches while running the application, I make sure to trigger all the known cases at startup.

You're talking about shaders generated by the fixed-function pipeline. You can't really guarantee that these internally-managed shaders won't be rebuilt at run-time because you're not in charge of those shaders. Your best bet is to write your own shaders, and then you "can" determine when they're built and ensure that they're not built at runtime (assuming you have a halfway-recent card -- e.g. GeForce 8+).

There are lots of things one would expect would trigger a different shader permutation (most anything lighting, fogging, texgen, texturing, vtx/texcoord transform related). You mentioned a few. Multisample and texture format are two that surprise me though. What convinces you these are triggering a shader recompile? What GPU and driver version is this?

Is there a way to deactivate these re-compilations at run-time?!

Write your own shaders, and don't use an NVidia card older than GeForce 8.

[jpchristin]

You're talking about shaders generated by the fixed-function pipeline.

No, I'm always using shaders, I have one big uber shader and some smaller shaders.

Multisample and texture format are two that surprise me though. What convinces you these are triggering a shader recompile?

For multisample, I've made a small test application that uses a shader to draw a triangle and I monitor the draw time. The first frame, there is a performance hit (Multisampling activated) which is normal, then I draw 100 frames still with multisampling (this is very fast) and then I draw 1 frame without multisampling and there is a huge performance hit that is directly link to the size of the shader. Here is the test application (Observed with 257.21 NVIDIA driver): http://www.mediafire.com/?wttzj5lkzte

I also have the same kind of test application for texture format, by changing the usage of a texture unit, for example by using RGBA and then DEPTH32 on the same texture unit, it will also trigger a performance hit relative to the size of the shader.

What GPU and driver version is this?

257.21, most of these behaviors can be observed since a long time (since 180.48 at least)

Write your own shaders, and don't use an NVidia card older than GeForce 8.

As I said, I always use shader, I never use the fixed-function pipeline.

[Dark Photon]

You're talking about shaders generated by the fixed-function pipeline.

No, I'm always using shaders, I have one big uber shader and some smaller shaders.

Then it doesn't make sense why you're talking about GL_LIGHT* and such. These only have meaning to the fixed-function pipeline.

...then I draw 100 frames still with multisampling (this is very fast) and then I draw 1 frame without multisampling and there is a huge performance hit...

That's interesting. Though the hit may or may not be due to recompiling shaders. It could be reconfiguring the pipeline in other ways.

What GPU and driver version is this?

257.21, most of these behaviors can be observed since a long time (since 180.48 at least)

Ok, so very latest drivers.

What GPU?

Write your own shaders, and don't use an NVidia card older than GeForce 8.

As I said, I always use shader, I never use the fixed-function pipeline.

Then why are you talking about GL_LIGHT* which are legacy fixed-function vertex shader pipeline symbols?

[jpchristin]

What GPU?

GTX280/480 , Quadro FX5800 - on WinXP or Win7

Then why are you talking about GL_LIGHT* which are legacy fixed-function vertex shader pipeline symbols?

I'm sorry about the confusion for this one, you are right, in fact, this have been found a year or two ago and maybe that this is not causing problem anymore. If I remember well, activating/deactivating GL_LIGHTING and then drawing something with a shader binded, was triggering a shader recompilation.

But the main goal of my post is to know if others people were concern about these run-time shaders recompilation (this have been confirm by NVIDIA by the way). I would like to have a detailled list of what is causing these re-compilation and if there is a way to deactivated this behavior (which is absolutly not wanted on a real time simulation).