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?

Comments

Re:Could someone explain what's this?

[sdjunky]

What's a "Cg compiler"

Cg compiler stands for "C for Graphics"

People who write pixel shaders ( those nice little algorithms that makes games pretty ) for things like fog effects, lighting etc have to use some low level assembly ( which is sometimes tied to the card as well ). This will allow for a higher level language so you can use do loops, for next etc. with writing shaders and for possible expanded ( cross card ) support

Nvidia's Cg

[Anonymous Coward]

I've been coding in Cg for some time, there have been a number of problems I've faced so far:

1. The vertex engine calls are not logical. Sometimes you call passing a referenced pointer, other time you have to pass a referenced strucute, some form of standarization to calls would have made it easier for developers to write function calls (more insane than POSIX threads).

2. The lanugae is not truely Turning complete. Which could have been fixed by taking some more time and making the language more complete.

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

4. Confusing definitions of pointer/references. They could have made this easier by removing the entire pointer usage.

5. Class calls outside of friend functions can at certain times reach memory outside of parent definitions (Bad language design?! I think this is one of the most debated feature/bug, since you can piggyback this to implement vertex calls within lighmaps).

6. No SMP support in current implmentation and no thoughts to future support (What about threading?!).

7. Inlining support is bad and possibly unusable outside the scope of inling cg within c.

Re:Nvidia's Cg

[ToLu the Happy Furby]

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?

Re:Nvidia's Cg

[Anonymous Coward]

I have trouble following what you are saying. First of all, there are no pointers in Cg. Input variables have the qualifier "in" (this qualifier can be omitted), and output variables have the qualifier "out". All parameters are passed by value. There are no pointers, and there are no references in the style of C++.

While there are no pointers explicitly in the language, you can effectively get pointer dereferencing by doing a dependent texture lookup. This is a common technique today with DX8 (e.g. reflective bump mapping) but so far it isn't commonly discussed as a "pointer dereference" or "indirection".

Also, in your comment you seem to be confusing the Cg shading language and the Cg runtime environement API, which are two quite-different things.

Eric

Re:Nvidia's Cg

[nihilogos]

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

About the license

[Anonymous Coward]

Please read here:
http://www.cgshaders.org/contest/
As you can see from the terms and conditions on that CG site, they favour and link to the ZLib license.

I think that CG will be under the PHP/ZLib license.

Re:Could someone explain what's this?

[mark-t]

I've read the article, but I believe I'm not enough of a graphics geek to understand it

Then what're reading Slashdot for? ;)

I'm not sure if it will help, but you can read more about Cg Here.

Re:If you like it

[The Rogue86]

They dont need to open source to port it to *BSD. But it would make developing simpler. It seems you have fallen victim to the assumption that closed source is evil. It can be a good thing in a comptative system. Nvidia doesnt need to open their drivers just port them. Last time I checked Creative didnt have open drivers for the SoundBlaster cards but they run just fine on Linux (I have not checked for BSD support and dont really plan on doing it). That is an example of a company with a great product that is cross platform compatible. Open drivers are nice but ultimatly not that important. It's the existance of drivers that is the issue.

isn't that the whole point?

[Anonymous Coward]

The lanugae is not truely Turning complete.
I thought the whole reason they made a new language (Cg) is because the chipsets weren't Turing complete. If they WERE Turing complete, then it would be a complete waste of time to make a new language -- just make a new back-end for your favourite C compiler and write a bit of run-time.

However, the chips themselves can't do very much -- they can't do a conditional branch, for example. This makes it quite difficult to make a C compiler target them :)

It would be very cool to just be able to do gcc -b nvidia-geforce9 ... or what have you since you'd be able to take advantage of a rich existing toolchain. But, alas, it's not to be.

Amen to that.

[gatesh8r]

Even though they don't have GPL'ed drivers for Linux, they have full support. They give me the source code for the kernel driver so I can compile my own kernel and not be stuck to a stock kernel. Yeah, the licence doesn't allow redistribution, but I'm not exactly concerned about that since 1) They're giving the program to me for free as in beer, and 2) I'm not a developer so issues about code modification isn't my concern.

They have kick-ass products that officially support my platform of choice. 'Nuff said. :-)

Re:If you like it

[be-fan]

Theoretically, you don't need source to port to BSD. The kernel driver has an abstraction layer (which comes in source form) and is fully portable. The XFree86 module (by design of the XFree86 driver model) is platform independent and can be loaded on any x86 OS. As it stands, it is not in NVIDIA's best interest to release the driver code. First, parts of it are copyrighted by other parties. Second, you can bet that ATI and Matrox would love to get their hands on it. Remember, an OpenGL ICD is an entire OpenGL implementation, not just a hardware banger. That makes the situation rather unique. ATI has some hardware that could be seriously compatitive with NVIDIA's if it had proper drivers. Why should NVIDIA jepordize their company to placate 0.01% of its users?

Re:ATI Would Be Happy

[dinivin]

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