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.

Re:Whining about competition...

[AltaMannen]

I'd say most Playstation 2 developers use custom graphics code for each game, whereas most PC developers use custom translators for high level graphics libraries (because low level libraries would require too much per card customization).

But that's just my opinion. And Vector C fits pretty well in with the PS2 VUs but almost every developer has at least one person doing mainly VU asm anyway so they may not be so eager to switch.

Re:This leads to suspicion that NVidia plans to ad

[Anonymous Coward]

You tards, cg is compiled into OpenGL/DirectX shaders.

Re:It's a shader language...

[Milinar]

A couples notes about the above:

- CG came around long before exluna was bought by Nvidia. I overheard Tony Apodaca (the co-author author of Advanced Renderman with Larry Gritz, the founder of exluna, at siggraph this week saying how CG was pioneered by a bunch of renderman users who wanted to bring that technology to real-time hardware. Since renderman is almost 15 years old now, the user base that CG could reach is vast.

- PIxar's lawsuit with exluna over trade secrets was settled, and the company was subsequently bought out by Nvidia. There is no guanantee that any of exluna's work will be continued. It's not uncommon in these situations to never see anything come of it. It's a nice idea that maybe nvidia will make renderman-supported hardware, but don't hold your breath. Nvidia wants to be the next intel, or microsoft, and you don't get there by support other people's software, you get there by eating competitors alive and flushing their work down the toilet.

- Best-case scenario: Larry Gritz re-releases BMRT, his free (as in beer) renderman ray-tracer, and at least we don't have to pay thousands for a production-quality renderman implementation. Or (even better) someone writes and releases another free (as in freedom) renderer that actually works.

Dan

Re:what?

[XMunkki]

I'd simply say, that without "goto" (the functionality, not the language contruct), many tasks of programming woul be nearly impossible. The trick is, many high level languages discourage or lack goto, and that's a completely different matter when compared to a low-level "assembly like" programming like the PS2 VUs or (I assume) CG.

So even if you never use gotos in c/c++, they still are compile in as unconditional jumps at assembly level. The same should happen with pixel/vertex programming.

Not a universal graphics language.

[KewlPC]

Cg isn't a universal, all-purpose graphics language. It is specifically tailored for writing custom pixel and vertex shaders for newer 3D cards like the GeForce3 & 4 and newer ATI cards.

The hardware in those cards has certain limitations (dunno 'bout the integers, but I've heard (from John Carmack's .plan file) that the hardware itself lacks support for conditional jumps i.e. if...else) when it comes to custom pixel and vertex shaders.

It seems like there's rampant misunderstanding when it comes to Cg, so I'll try to clear things up:
1)It is *ONLY* for writing custom pixel and vertex shaders for 3D cards that support custom pixel and vertex shaders.
2)The alternative to Cg is to write your pixel/vertex shader(s) in an assembly-like language. This is assembly language for the 3D hardware, not the CPU or anything else. Again, this isn't x86 assembly.
3)The shaders produced are only used by the 3D hardware, and only for the purpose of allowing developers more control over how objects look (i.e. the developer can write a shader that mathematically simulates the way light bounces off human skin, then tell the 3D hardware to use that shader for all polygons that are supposed to be human skin), and have absolutely nothing to do with speeding up graphics operations or other speed optimizations.