Switching Textures, Parameters, etc, How optimized is Cg? Options

[RealMarkP]

Is Cg smart enough to ignore repeated cgD3D9SetTexture() which pass the same pointer to a texture?

[Nigel @ NVIDIA]

Is Cg smart enough to ignore repeated cgD3D9SetTexture() which pass the same pointer to a texture?

Probably not. Generally we wouldn't want to penalize better-written applications for the sake
of less-well written ones. That's my understanding of the "rule of thumb".

- Nigel

[Matthias]

In general I found cgfx, especially the d3d9 version of cgfx to be very slow and unoptimized. The main problem is the runtime, who will issue way to many d3d api calls. E.g. for every parameter you set it will generate a d3ddevice->SetVertex/PixelShaderConstantF call. In my application this piled up to more than 16.000 calls per frame. Cg was using more than 50% of the cpu time on my machine due to internal functions being called and due to simple flooding of the driver with commands.

In the end, I wrote my own little version of the cg runtime, which batches things much more, uses constant buffers, also takes care of potential redundant set commands and the result is that I have less than 1000 d3d api calls now and my application performance is much much better.

If you have lots of objects with changing parameters, you will very likely have to write your own runtime, too. The cg d3d9 module has various problems (e.g. try using a CullMode state assignment - debugging with PIX will show you that cg d3d9 will completely ignore it. Or try setting some invalid effect state like "Blub = Linear;" - it will fail silently, fail the following state assignments and leave you scratching your head about things not working). This is not to bash cg - after all I am using it - but you can safe yourself some time if you use an alternative to cgd3d9 like cgd3d10 (which seems better from my rough first tests) or hlsl (with d3d11).

-Matthias

[MakKlaski]

In general I found cgfx, especially the d3d9 version of cgfx to be very slow and unoptimized.
Cg was using more than 50% of the cpu time on my machine due to internal functions being called and due to simple flooding of the driver with commands.

Totally agree!
CgFX is very cpu-hungry and when I use PerfHUD to list all d3d calls per frame, I get a huge list of redundant state changes.
Here is my post about this: http://developer.nvidia.com/forums/index.php?showtopic=3755
So, looks like, if app uses CgFX, then it is CPU-bound and "even infinitely fast GPU can't make it run faster" ©. (In other words: no need for next-gen NVIDIA cards on the market.)
Too bad Cg users are forced to write their own runtime. Lot of time wasted.