quote:Yes there is a ''reasion'' at least : with Cg you can''t fully control the GL state changes. That''s a good point as well as a bad point.

I don''t understand this one... looks like it can do everything I need to do in the fragment pipe. Can you please explain me what do you mean?

quote:The good point is that Cg handles everything for you (well, almost everything ). The bad point is that you can''t fully optimize your engine since you don''t know which GL calls are performed inside the Cg functions.

Ack. This is a very unfortunate thing. Maybe CgFX helps here but for now I really need to parse out the Cg shader to understand what''s going on (for example, separate multiple passes, set up texcoords accordingly and so on).
Looks like in a totally data-driven world Cg takes a lot of time to fully integrate in a scalable technology.

For simple programs I must say it''s a definite step over ARB_vp and ARB_fp. If you have only register combiners that there''s a real gain anyway (I wasn''t able to get nvParse anyway ).

Well, you group by shader instead of specific state changes. Though, since Cg compiles down into ARB_VP and ARB_FP/NV_parse code anyway, you know pretty much exactly what it''s doing.

You have to remember that you''re unique, just like everybody else.

quote:Original post by vincoof
I mean that in Cg you basically use a shader by calling something like :
shader.setup();
and in that call you never know exactly what happens inside, so it''s hard to optimize state changes with other shaders you may have made yourself for other objects.

Mh, I agree, this may be a problem but every VP/FP pair is pretty "self contained" in itself so I personally don''t think this is a real problem. If you do your VP/FP combo well enough I think there will be just few things to mind about (blendFunc,depthFunc and polyOffset comes to mind) which are the things which VP/FP cannot control.

My two cents on not optimizing state changes too much.