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

This leads to suspicion that NVidia plans to add a

[t0qer]

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.

Smells like glide!

And we are calling NVidia bad?

[SeanTobin]

Just found this quote funny... especially because of the knock on nvidia for working with our favorite evil empire (emphesis added)...

This approach will be extended to embrace emerging new hardware features without the need of proprietary 'standards'.

I guess the evil empire has gone everywhere they wanted to go today.

It's a shader language...

[invispace]

1. It's not C.

2. Exluna was bought by nVidia.

3. Exluna makes 2 renderman compliant renderers.

4. Shaders are used by renderman.

5. nVidia is touting CG as a compiled shader... just like one has to compile shaders for renderman.

6. Fill in the next 2 years here of having look development tools for major graphics studios that look close enough to the final renders that it speeds up FX work to near realtime for shading and lighting.

Whining about competition...

[kbonin]

I love the line regarding Codeplay's own product: "This approach will be extended to embrace emerging new hardware features without the need of proprietary 'standards'." So, the point is: 'Don't waste your time on that competitors product, wait for us to finish ours!' Where have I heard this marketing approach before? :)

Codeplay's VectorC is optimized around Playstation2 centric vector graphics hardware and scene graph libraries, whereas nVidia's Cg is optimized for most current PC accelerators. Most playstation developers use licensed scene graph libraries, whereas most PC game developers use custom or licensed engines over low level libraries, so both approaches are appropriate for their current customer base...

I think its reasonable to assume Cg will evolve with its target hardware, and I'd rather nVidia do a good job with the current version than waste time hypothetical future features. I'm using Cg now, and its a great step in the right direction - a high level shader language not owned by M$ and/or tied to D3D.

I think the biggest issue w/ Cg is how nVidia is going to address the divergence in silicon budgets between themselves and ATI - nVidia is pushing for more, faster vertex shaders, while ATI (w/ M$'s backing) is pushing for more powerful pixel shaders, i.e. D3D pixel shaders v1.4, exposed in D3D 8.1, are supported in ATI Radeon 8*, but no publically announced nVidia cards support the nicely expanded instruction set and associated capabilities. nVidia also needs to complete fragment[pixel] shader support for OpenGL (and release source or a multithreaded version of the GL runtimes...)

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:My bone with Cg

[h2odragon]

Didn't you post this same rant on the last nvidia article? What, are you a bitter ex-3dfx employee?

Re:I don't get it

[zenyu]

What does a vectorizing compiler for a C-like language for the x86/PS2 have to do with a C-like shader language for nVIDIA graphics processors?

The PS2 has two almost identical MIPS chips souped up with fast SIMD math instructions. One runs the OS/AI/etc, as a pretty standard processor. The other is dedicated to process vertex arrays and the like. This is the "GPU" But really it is a full fledged processor that simply used in a streaming fashion.

The talk this year at SIGGRAPH was all about how the GPU's are all becoming streaming processors that can handle almost anything thrown at them. Using them effectively is all about never asking for any data not already fetched, that is no random access to memory. A huge portion of the die on a modern CPU is dedicated to caching, GPU's get faster at a greater rate because they use most of their die for logic gates and what is left is used for the very specialized texture memory access, with little or no caching of random access.

As for the integer arguement, I think nVidia heard that loud and clear, and it's almost certainly going to be in OpenGL 2 shader language (which is C like and has branching and loops even in the fragment shader.) 3D Labs and ATI promise drivers weeks after ratification. Except for integers nVidia should be able to do this in their driver with extra passes. For integers they can just suggest 'safe' texture sizes for data as a work around.

OpenGL2 also asks for effectively unlimited program size, which no one will have initially. This of course can be simulated with more passes, but you'll be reponsible for any such splitting since it tells you whether the shader compiled and 'out of program space' is one of the acceptable errors.

ATI is known for not so great drivers and 3D Labs has an external company writing their linux drivers, so I'm not sure they will be any more stable than the nVidia ones. Both booths told me the linux drivers would be closed source, but I didn't ask so I guess they are hearing people asking for easier to fix drivers.