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