Slashdot Mirror
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."
Evil Empire
No bias here at all!
Who uses goto statements? I'd count that as a feature.
Mmmm... I'd love to see Gnome and KDE compiled with VectorC or intel's compiler...
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
an almost-monopoly and a true monopoly combine like voltron to create yet another monopoly on graphics languages.
who gets to be the battleship?
"such as the lack of ... pointers"
Well, Nvidia sure knows how to make a C guru cry!
Buying a Dell computer is equivalent to dropping the soap in a prison shower.
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!
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.
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
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.
-- -- A truly great man never puts away the simplicity of a child
Who uses goto statements? I'd count that as a feature.
Some CS people hear "go to hell" and are more offended by the "go to" than by the "hell", but in my C code, I use goto carefully to break out of nested loops and to bail on exceptions. Even though the Java language has goto bound to nothing, it has nearly equivalent structures: 1. try...catch; 2. labeled break.
Will I retire or break 10K?
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
Having better control structures and pointers will be important down the line.
"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."
When all else fails, run.
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...)
This is the second article in a row with the word "badass" in it :)
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.
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:
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.
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.
If I was a gaming corporation, and I knew that an 800 dollar tool could make my game faster for my end users, I'd do it in a heart beat.
Lastly, you failed to mention that there is an 80 dollar version of the same software. It may not have the same features as its 800 version, but it comes close enough.
Sunny
Than we'll have "portable" software!
Just kidding... :)
In that case, I will be screwed again, that is if cg has the same effect on the market as glide did, then I will not be able to play games, seeming as I cannot currently afford a graphics board that can be used with this type of language. So I would hope that people will really create the games in opengl first, and then if they want to crank up the detail levels for the games, then they can use cg. Kind of what is in some games now, although they kind of don't have a choice with the way this language is looking to be designed, with no , ints and such.
Cg limits shaders to single-pass rendering.
Cg doesn't limit you to single-pass rendering at all. It just doesn't do it for you automatically, which would require some sort of scene graph or driver level support. You can still do multipass in the same manner its always been done.
The Stanford Real-Time Shading Project [stanford.edu] people wrote a compiler that does precisely that: it uses Cg as an intermediate language.
The Stanford language doesn't use Cg.
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
Current hardware/drivers don't expose any way of doing this so the only way to do it would be some sort of slow readback to CPU memory, which would be to slow to be of much use. Cg is designed to work with current and future hardware in the least intrusive way possible so it wouldn't make sense to implement some high level abstraction like what was done with the Stanford language.
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.
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.
---
I write code.
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.
/. 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).
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
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.
www.sjbaker.org
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.
You tards, cg is compiled into OpenGL/DirectX shaders.
Didn't you post this same rant on the last nvidia article? What, are you a bitter ex-3dfx employee?
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.
At a SIGGRAPH course on real-time shading last week, Eric Chan described a version of the Stanford compiler that broke a shader down into its component passes and used Cg as an intermediate language when aiming at NVIDIA cards. (Eric -- or anyone else who was at that course -- if you're reading this, I'd welcome corrections. I know it was the Stanford project and Cg as an intermediate language but I'm hazy on the details.)
Current hardware/drivers don't expose any way of [texture lookups in vertex shaders / position change in fragment shaders] so the only way to do it would be some sort of slow readback to CPU memory, which would be to slow to be of much use.
Exactly. This goes back to the Richards' claim that the Right Solution is to program everything in C/C++ and make the compiler smart enough to figure out how to partition it all into vertex shaders, fragment shaders, multiple passes, scene graph management, vector processing... I don't want a fully general language down in the fragment shaders. I want to know about what the hardware there can and can't do so I can make things run fast.
i, for one will laugh when M$/Nvidia lose the race to ATI/Linux
*crosses fingers*
Base 2 yields only ARTIFICIAL Intelligence
lmb is SO horribly, wonderfully good looking!!
In Soviet Russia you dant have to put up with these crappy jokes
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.
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 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
Ordo Militum Unix.
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?
.plan file how the lack of support for conditional jumps and suchsort in the shader hardware really annoyed him.
I distinctly remember John Carmack saying in his
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.
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.
.plan file) that the hardware itself lacks support for conditional jumps i.e. if...else) when it comes to custom pixel and vertex shaders.
The hardware in those cards has certain limitations (dunno 'bout the integers, but I've heard (from John Carmack's
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.
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...
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Use Nvidia for games if you like. For some of us, open source - which Nvidia drivers are not - matters more than video gaming frame rate.
Nvidia => no BSD support, no support if your Linux kernel strays too far from the snapshots they use.
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.
----
All of whose base are belong to the what-now?
What, are you a bitter ex-3dfx employee?
Or possibly a bitter ex-BitBoys employee?
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
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 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.
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
I don't agree that MS are 'evil', they are just a money grabbing megacorp just like [insert company name here]. OSS based corporations are just megacorp wannabes - give them a chance and they'd do the same coz it's all about money.
;-)
"As a result of Microsoft's acts of destruction, PC technology is ten years behind where it should be."
I feel compelled to agree with this though. Had standards bickering been pushed aside we may well have hover cars, cold fusion and AI spacecraft searching the galaxy on our behalf by now
Funny, I use return to break out of nested loops. If your functions are so huge you feel the need to use goto, that's a sign they need to be split up.
I write video drivers for soft real-time applications. If I split up a function into an inner function and an outer function wherever I need to break out of something, performance drops 30% because now I have to pass a dozen arguments to a function call in a loop, and on some architectures, function calls are very expensive.
Will I retire or break 10K?
one should never NEED to break ... out of a ... for loop
Then what do you do when you get a "Virtual memory exhausted" error on a widely deployed machine with extremely limited but non-upgradable RAM? Surely you don't switch to C++ exceptions, because that will take up even more RAM for the exception handling code, right?
USE A ... WHILE OR DO WHILE LOOP
I've considered this, but I'm not sure GCC's optimizer will know what to do with putting complicated expressions in a while loop's condition. I don't want my profiler to report a 30% performance hit from inefficient control structures.
Will I retire or break 10K?
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.
Being selfish and greedy, being openly malicious and arrogant, stabbing your freinds in the back and treating your customers badly is very evil. Justification doesn't change the bottom line.
But that's just my opinion, I've been proven wrong in the past...
It's been a long time.
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.
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.
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.