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."
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
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.
In the case of supporting the ps2 vu's, goto is a gift from (insert the god you worship).
And i think the same would apply for other vertex/pixel shading units.
Why?
Because the VUs has a very small amount of memory and to get the most of it you should almost count cycles aswell.
I haven't tried vectorC but considering the VU i think it's the only sane option apart from the stuff in asm(that i think might be preferable anyhow).
As for Cg i think i have to agree with the points Codeplay makes about Cg being too simple and aimed at the current NVidia implementations, but the statement itself is to be considered FUD.
I have been working with 3d for some years now and spent the last two years coding professionally for the PS2 and Dreamcast.
IMHO most stuff defining appearance(bumpmap,etc) should when it comes to supporting 3d hardware be translated from a really high level(renderman?).
Cg feels too lowlevel and specific for this, especially if you plan on supporting consoles.
vectorC could possibly(though questionable in reality?) get away in this case because the most of the code will be C/C++ anyhow and thus the specific code could be taken out and recompiled with vectorC when aiming for performance.
/ Jonas Lund
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.
One entry found for monopoly.
Main Entry: monopoly
Pronunciation: m&-'nä-p(&-)lE
Function: noun
Inflected Form(s): plural -lies
Etymology: Latin monopolium, from Greek monopOlion, from mon- + pOlein to sell
Date: 1534
1 : exclusive ownership through legal privilege, command of supply, or concerted action
they have almost all of the market share. they are almost a monopoly. i don't see what's so hard about this point. ati is making a valiant effort, but they aren't shipping the kind of units/chips that nvidia is. sis, matrox, 3dlabs and trident do not have a 3d architecture even comparable to the latest nvidia offerings.
if tomorrow nvidia released detonator drivers with a special feature or program, it would become a standard. big companies make games for nvidia chips. people speak about games in nvidia terms (that game's a geforce2 featureset game).
face it kiddo, nvidia is *the* video card maker right now when it comes to consumer desktop 3d.