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."

Bias?! What bias?!

Evil Empire [microsoft.com]

No bias here at all!

what?

Who uses goto statements? I'd count that as a feature.

VectorC

Mmmm... I'd love to see Gnome and KDE compiled with VectorC or intel's compiler...

wow!

an almost-monopoly and a true monopoly combine like voltron to create yet another monopoly on graphics languages.

who gets to be the battleship?

Wahhh!

"such as the lack of ... pointers"

Well, Nvidia sure knows how to make a C guru cry!

This leads to suspicion that NVidia plans to add a

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?

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...

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.

what about 3dlabs

This guys got some good points, espically with regard to pipelines with more progammibility such as the PlayStation 2 gpu. 3Dlabs is also developing highly progammible pipelines
3DLabs press release [3dlabs.com]

Having better control structures and pointers will be important down the line.

Yikes! Mucho deneros!

OMG! That compiler is $800 (the one with P4 support). These guys have got a case of the M$ pricing delerium. /Me thinks I save my money and buy a shiny new p4-2.8G instead.

"Never cuss a man until you've walked a mile in his shoes. Then if he gets mad, you'll have a headstart and he'll be barefoot."

Whining about competition...

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...)

whats the go?

This is the second article in a row with the word "badass" in it :)

NVidia has it right

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

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 [stanford.edu] 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 [sgi.com]. 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 [3dlabs.com] 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.

Sour grapes?

Quote from the article :

"Overall, Cg is not a generic language for graphics programming; it is a language for NVIDIA's current generation of graphics card."

Well, what does anyone expect! Cg is a tool to help developers take advantage of pixel and vertex shaders *today*. And which pixel and vertex shaders do they know best? NVidia stated in their original press announcement that it would work across DirectX and OpenGL, as well as with other pixel and vertex shaders that comply with the specifications and even mentioned that other chip makers would be able to optimise the compiler for their particular hardware.

The games industry moves along at a rocket pace, it's all about performance and getting the most out of the hardware right now. I applaud NVidia for actually doing something for today, rather than just talking about how great things are going to be tomorrow, and fail to see why leaving features unimplemented is a cardinal sin when they're not available in their current generation of chips.

Reading their press release, I don't know what the hell Codeplay want. Some attention maybe.

Linux on GeForge 6...

I would like to see Linux ported to GeForge 6 (or whatever) shader language.

Than we'll have "portable" software!

Just kidding... :)

I don't get it

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? It seems to me they are different languages for different purposes, even running on different parts of the same system.

I think this is not such a bad solution.

The deal here is that we currently have GPU's that simply cannot implement anything like a full-up C compiler. There is no point in wishing for something that the hardware simply cannot support.

Cg doesn't have integers because GeForce chips don't implement integer math operations. There are no pointers because the hardware doesn't implement them.

So, the choice here is either to put up with a C subset that will grow with the hardware until it's not a subset anymore (and live with the consequent lack of compatibility between versions of the hardware and Cg compilers) -- OR you carry on writing GPU-based shaders in machine-code (which *also* changes with hardware versions).

We are at the very beginning of a revolution here and as such, we have to put up with some initial inconveniences.

A better debate for the /. crowd is whether we should embrace Cg now - or wait a year (or more) for the hardware to catch up with something like the OpenGL 2.0 shader language (which is very similar to Cg - but isn't implementable on most hardware...yet).

At the OpenGL Birds-of-a-Feather session at SigGraph last week, nVidia clearly expressed an interest in working with ATI and 3Dlabs on the OpenGL 2.0 standard - but those of us who need to use realtime shader languages simply cannot wait another year. I think we should expect to use Cg until something better shows up - probably in the form of the OpenGL 2.0 shader language.

One should note that the Direct3D DX-9 shader language (called HLSL by Microsoft) is basically the same thing as Cg.

C-style pointers

No pointers. This is Cg's most serious omission. Pointers are necessary for storing scene graphs, so this will quickly become a serious omission for vector processors that can store and process the entire scene or even sections of it.

You do not need (C-style) pointers for high performance graphics. You do not need pointers even for representing relational structures. People have been implementing graph algorithms in languages without pointers since before most of us were born. You can even do it in a language as tedious as Fortran 66. C pointers are a bizarre aberration in language design and play havoc with high performance computing and optimization. You have to jump through hoops in order to even optimize siple uses, and then add lost of special purpose declarations to make them work. Any use of C pointers can be replaced with the use of arrays and integers (but the logic of your program may change dramatically).

Another reason pointers are generally not such a good idea in graphics or high performance is that they have to be large enough to address all of memory. An index into a array can be 1, 2, 3, or 4 bytes long depending on how much data it actually needs to address. That can lead to saving a lot of space.

When dedicated C hackers make such statements, it is understandable. But a company in the business of writing high performance compilers ought to be familiar with the work, programming styles, and languages that people in high performance computing adopt, and those often don't include pointers. C programmers want pointers becaues they are used to them, and CodePlay is in the business of satisfying this desire, but that doesn't make it a good engineering choice.

Incidentally, I program in C++, including numerical and graphics code. It is quite easy to eliminate most uses of pointers from C++ code, and the result is code that is a lot easier to debug and often run faster, too.

Sounds like Codeplay doesn't like the competition.

Codeplay is probably just upset because Nvidia is setting some precendece for graphics companies providing stuff like this free of charge to whoever wants it. It's got to be hurting Codeplay's business. It's obviously in Codeplay's favor if companies like Nvidia stay away from this stuff and leave it up to Codeplay so Codeplay can sell their proprietary commercial products to fill the gap. Other than dissent from Codeplay itself, Cg seems to be fairly well accepted by developers.

Codeplay was probably planning on making a DX9 backend for their commercial product, so Nvidia is just raining on their picnic. We'll see what happens to Codeplay over the next year or so.

could be interesting

i, for one will laugh when M$/Nvidia lose the race to ATI/Linux

*crosses fingers*

Prettiest Girl I know

lmb is SO horribly, wonderfully good looking!!

They can program in Logo for all I care

Anyone who's played games in the last two years knows that an NVidia chip is the way to go. They update their drivers on an almost weekly basis, and make all their beta's available for download as well. The On-line support is excellent, and just about every driver update seems to add a boost in performance. Add to this that their drivers are backwards compatible to at least the TNT2 chips, and I say I don't really care if they want to tout their own language, and make it propriatary to their chips. This is a company that actually survived the dotcom burst, and is continuing to thrive because they make a damn good product.

Vectoriziing stuff is not a new thing

C/C++ is not a language of choice for vector applications, hpf (High Performance FORTRAN) is, although a crockish hack on f90 it's quite usable, we really need some more vectorable languages. I have made an early atempt at a vector unit (GPL now, disregard copyright) Ganymede [bensin.org] but that is far from completion and will never se the light of day. Still we need vector processors though. For a good free hpf compiler check out this: Adaptor [www.gmd.de]

Huh?

I thought that Cg didn't support if...else (etc.) because the pixel and vertex shader hardware itself doesn't support that sort of thing. If the hardware doesn't support it, why should Cg?

I distinctly remember John Carmack saying in his .plan file how the lack of support for conditional jumps and suchsort in the shader hardware really annoyed him.

I doubt there is some evil conspiracy going on here. nVidia may add if...else to Cg in the future, not due to some underhanded plot, but because once the shader hardware supports conditional jumping it only makes sense that Cg would as well.

Not a universal graphics language.

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.

Competitor X Hates Competitor Y's Product...

...film at 11. If NVidia Cg can be used without diseasing your code, it makes VectorC's product irrelevant along with Intel's SIMD hack. It takes all of that and moves it onto dedicated hardware. The key word here is *IF* you can use Cg without mucking up your code. Just looking at VectorC's source for their benchmarks, I saw some things that were nonconforming for ANSI/ISO C. Pot. Kettle. Black. Also, maybe I missed it, but I didn't see what switches they used on the other compilers (grin).

I suspect that disciplined programmers can use either tool without making their code proprietary. Use MACROS for compiler dependant stuff! Wrap proprietary functions!!! Of course, when you are shoving games out the door, how many stop to think about coding discipline? So, then it becomes a question of who you would rather risk getting locked into...

Hrmz.....

Is it just me or are break, continue and goto all considered to be evil programming practices (with the exception of break in a switch structure)? And switch isn't at all necessary if you have if and else (you can make a switch structure out of those). Lack of pointers and integers may or may not be a problem, I don't really know much about the language.

What about NV30?

Um, I see a lot of comments along the lines of "NVIDIA aren't including loops in the language because GPUs just can't do loops". It seems NVIDIA [gamers.com] aren't aware of that, the next-generation "NV3x" hardware supports loops up to 64 levels of nesting... They've also grown the maximum pixel shader program size by a nice little factor of 512 (65,536 rather than 128 instructions per program). Also, it says "dynamic flow control" in the chart, which sounds like maybe arbitrary branching (there's your GOTO right there) could be supported.

That said, it does seem a bit weird not to make Cg strong enough to include features that are obviously needed for their own next-generation of hardware... But all the conspiracy theories have already been used up, I'll just settle for introducing some facts in the discussion. ;^)

markup language vs. procedural language

I haven't read too deeply into it, but I got the impression that it was supposed to be more of a markup language than a procedural language, much like VRML was a markup language.

You're supposed to be able to specify a scene in a procedure neutral way. Then the hardware will decide how best to optimize it in-terms of its capabilities.

Who ever said Cg was general purpose?

It's a shader language, not an all-purpose programming language. It's more like DSP-style programming, for those few people who are familiar with that sort of thing.

You don't need integers, for example, because NVidia's hardware works entirely in floating point. It's not like you could use Cg to parse text files, nor would you want to.

yes it is probably going to happen

Cg is useful right now. Some people will use it. If graphics hardware evolves into more general purpose CPU's, then people will use "something else". "Vector C" might be that "something else", although it is hard to predict the future.

I'd rather put my eggs in the "works right now"-basket then gamble on how the future will be. It is too early to standardize on something that doesn't even exist (or only exists for the PS2), so "Vector C" will not replace Cg anytime soon. Give it 5-10 years, and we will see what happens. In the meantime, if Cg is useful to you, go ahead and make use of it.

And please don't worry about standardization just yet. Before we can standardize, we need to find out which features are useful, and that will take several years of experimentation and competition in the marketplace. In the meantime, Cg could come in handy.

Dependent Texture Reads == Pointer Dereferencing

One of the most significant points made by the author of this article is the lack of pointers in Cg. While his reason for including pointers seems to be focussed on higher-level constructs such as scene description mechanisms (scene graphs, etc.) which are handled in the rendering pipeline entirely outside the likes of Cg (and very efficiently, I might add), this point is fundamentally untrue to begin with:

Dependent texture operations ARE pointer operations, and they have been in Cg from the start.

Re:My bone with Cg

I thought that by definition, Cg was mean to be a microcode compiler for Nvidia's GPUs. It makes perfect sense that Cg lacks all the features of a robust, general-purpose language because the target harward that will ultimately run the compiled instructions is not a general purpose processor.

Re:My bone with Cg

Uhh, I don't think you've ever used Cg have you? Its a shading language, not a general purpose programming language. Its used to control the vertex and pixel shaders in OpenGL and DirectX.

1. There are no pointers in Cg, not sure what you are talking about here.

2. Possibly

3. No idea what you are trying to say with this one. Cg will compile to DirectX 8 vertex/pixel shaders and ARB_vertex_program under OpenGL, meaning it will run on any card.

4. Again, no pointers.

5. No class's at all, this isn't C++, its C for graphics.

6. Its a shading language...

7. No idea what you are trying to say here.

---

Re:My bone with Cg

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