Slashdot Mirror
NVIDIA Cg Compiler Technology to be Open Source
Jim Norton writes "This announcement from nVidia states that
their Cg compiler technology for 3D applications will be Open Source and available under a free, unrestrictive license. The ETA for this is in August and will be available here." The linked company release says it will be under "a nonrestrictive, free license," but does not give further details. BSD?
Money talks. If you like what they are doing, tell them you like it by buying one of their cards.
I'm in a field totally different from graphics programming and hardware, but:
In my reading of earlier coverage of Cg, my understanding that most people weren't concerned about Cg or its compiler being open source, but rather that Cg would depend to some extent on hardware specs that are proprietary. This would have the effect of driving other hardware competitors out of business because they can't implement Cg components because of hardware patents. Sort of similar to fears associated with MS open sourcing part of C# while keeping a good deal of it dependent on proprietary stuff. The fear is that Cg would lead to people saying things like "well, your video card is so crappy it doesn't even support a standard graphics programming language" (all the while being unaware that the card can't because of hardware patents). Just because the language and compiler is open-source doesn't mean the hardware it will run on is.
Anyone more knowledgable care to comment? Am I misunderstanding this?
I'm not sure if it will help, but you can read more about Cg Here.
File under 'M' for 'Manic ranting'
i would really love to give some witty comments here -- but am at a loss of words. which could be fixed by thinking up a few words to form a witty comment with.
My life in the land of the rising sun.
2. The lanugae is not truely Turning complete. Which could have been fixed by taking some more time and making the language more complete.
This was done on purpose. Current (and next-generation) GPU shader hardware is not Turing complete, so it'd be quite silly for Cg to be. The problem is that while most extensions to Cg can be added with a vendor-specific profile, extensions which would make the language more general purpose (like pointers, full flow control, etc.) are apparently considered changes to the language design and only NVidia can add them. This isn't a problem now, but it would be if another vendor came out with a more general purpose shader implementation first. (Technically it may be possible to make Cg Turing complete through the extensions NVidia has made available, but probably not in a very friendly way.)
3. The compiled bytecode is giving a security mask that disables it's use on chips that do not carry a compliment decoder (To keep competetors away?).
Well, supposedly anyone can write a compiler/interpreter for Cg bytecode to target and optimize for their hardware just like NVidia can. (Of course they would need to introduce new functionality to the language through extensions, but the point is any standard Cg bytecode should execute on any DX8+ GPU with a compiler.) Indeed, this is one of (perhaps the only) huge plus to Cg: because it can be interpreted at runtime, rather than just compiled to shader assembly at compile time, new GPUs can (assuming they have an optimizing compiler) optimize existing shader code. This will be nice, for example, in allowing the same shader bytecode to run optimized on DX8 parts (few shader instructions allowed per pass), upcoming DX9 parts (many but not unlimited instructions per pass), and probably future parts with unlimited program length shaders.
Yes, it does require the other vendors to write their own backend for Cg, but NVidia has supposedly released enough for them to do that with no disadvantages. The question is whether they will want to, given that doing so would support a language that NVidia retains control over (as opposed to MS-controlled DX and by-committee OpenGL).
6. No SMP support in current implmentation and no thoughts to future support (What about threading?!).
Presumably this can be done via an extension, although it might get ugly to retain backwards compatability.
7. Inlining support is bad and possibly unusable outside the scope of inling cg within c.
What about inlining shader assembly in Cg? And beyond that, what sort of inlining would you want?
They have kick-ass products that officially support my platform of choice. 'Nuff said. :-)
Karma whorin' since 1999
I am pretty sure the above post is just rubbish someone made up to make a couple of moderators look stupid.
AFAIK Cg is a C like language designed to make writing vertex and pixel shaders easier. Real time shaders for nvidia's and ati's are currently done in assembly. It is not supposed to be a new language like C or Python or insert-language-here. All it has to do are transforms on 3d vertex or pixel information.
A vertex shader takes as input position, normal, colour, lighting and other relevent information for a single vertex. It performs calculations with access to some constant and temporary registers, then outputs a single vertex (this is what the chip is built for). It does this for every vertex in the object being shaded. Pixel shaders are a little more complex but similar.
Points 1-7 have nothing to do with Cg.
There is a very good article on vertex and pixel shaders here
:wq
NVidia cannot release the source code due to parts which are not belong to them (they belong to SGI and other parties)...
SGI has said, on a number of occaisions, that they are not at all involved in keeping the nVidia driver closed source. They have also stated that they are in favor of open sourcing the driver.
Dinivin