Codeplay Responds to NVidia's Cg

Da Masta writes "Codeplay Director Andrew Richards has some interesting things to say about NVidia's Cg graphics language. Just to refresh, Codeplay is the company that publishes Vector C, the badassed, high performance C compiler. In brief, it seems as though Cg isn't the universal, standard graphics language some pass it off to be. Certain design considerations in the language, such as the lack of integers, break/continue/goto/case/switch structures, and pointers suggest a general lack of universal usefulness. This leads to suspicion that NVidia plans to add and tailor the language in the future according to its own hardware and their respective features. Of course, this is all old news to those of us who noticed NVidia co-developed the language with the Evil Empire."

Comments

NVidia has it right

[Animats]

I'll have to go with NVidia on this one. A shader language should be limited and highly parallelizable. Ideally, you'd like to be able to run the per-pixel shaders simultaneously for all the pixels. In practice, you're going to be running more and more shaders simultaneously as the hardware transistor count goes up. So you don't want these little programs interacting with outside data too much.

If you put a general-purpose execution engine in the graphics engine, you need an OS, context switching, protection mechanisms, and all the usual system stuff. If pixel shaders aren't allowed to do much or run for long, managing them is much simpler. Bear in mind that all this stuff has to work in multiwindow environments - one app does not own the graphics engine, except on game consoles.

Cg isn't supposed to be a general-purpose language

[andycat]

I think what Richards is overlooking in his commentary is that Cg is not *supposed* to be a general-purpose graphics programming language. Its design goal was precisely what he said later in the article -- to expose the capabilities of current (and presumably future) NVIDIA hardware without requiring programmers to write assembly code. Likewise, conditionals like if, case, and switch aren't in there right now because the profiles the compiler is aimed at -- DirectX and OpenGL extensions -- don't yet support them. I expect this to change.

Also, Cg programs run at the level of vertices and pixels. This is the wrong place to be thinking about a scene graph: that happens at a much higher level of abstraction. Dealing with scene graphs in a fragment shader is a little bit like making L1 cache aware of the memory-management policy of whatever OS happens to be running.

After reading the article a few times, I think it's meant more as a "here's why our product is better than theirs" release than an honest criticism of the design of Cg. If he was interested in the latter, there are a few obvious issues. I won't go into them all, but here are two I ran into last week at a Cg workshop:

• Cg limits shaders to single-pass rendering. This is a design limitation: there are lots of interesting multipass effects, and it's not all that difficult to get the compiler to virtualize the shader to do multipass on its own. The Stanford Real-Time Shading Project people wrote a compiler that does precisely that: it uses Cg as an intermediate language. The advantage of that design decision is that you-the-programmer have fuller control over what's happening on the hardware, which is the entire point of the exercise.
• Cg requires that you write separate vertex and fragment shaders. You can't do things like texture lookups inside a vertex shader; you can't change the position of your vertices inside a fragment shader. Again, this gives you control over the details of the pipeline at the cost of some added complexity. This can be changed by changing the semantics of the language.

One final note: Cg is not the be-all and end-all of real-time shading languages. Nor is DirectX 8.1, 9, or whatever. Nor is the SGI shading language. Real-time shading on commodity hardware is still a new enough field that the languages and the hardware are evolving. DirectX 9 and OpenGL 2.0 both incorporate shading languages that will by nature be less tightly coupled to one vendor's hardware. Watch those over the next year or so.