Nvidia Cg toolkit

[Nutty]

http://www.nvnews.net/articles/cg_to..._toolkit.shtml

Looks V. interesting.. Any idea when it's coming out?

Nutty

[zeckensack]

First I want to know "What the hell is it?"

If it's a shader compiler (likely, but still no conclusive descriptions out there), then, ummm, what's the point?

[kehziah]

What about OGL 2.0 shading language? Will NVIDIA once again try to impose its own standard while other IHVs are trying to agree on a common solution?

[davepermen]

not at all interesting.. why can't nvidia follow the standarts of the others? they can't do it with the exts, now they can't with gl2.0..

i guess thats what nvidia once said about "we develop an own glide, a modern one for modern gpu's"

well.. imho, its bull****

[Robbo]

I suggest this would not be the case. It is entirely reasonable to expect the compiler to spit out GL2.0 shader symbols rather than NVIDIA ones. The interesting thing about this is that it sits on top of DirectX and OpenGL, rather than just OpenGL.

[davepermen]

it doesn't sit on top, it sits beside. and i dont need a 3rd api. really not.i dont get more features, i dont get more power, i dont get stuff that i could not get before.

just support gl2.0. why? because then we can code for EVERYONE, not just for nvidia. if i have to code for nvidia only, i want to see money from nvidia, for sure.

[pocketmoon]

http://www.cgshaders.org/shaders/VertexNoise/

I see that a new dedicated site, cgshaders.org , is up already. The .org extension I suppose indicates a non-proprietary leaning.

By strange co-incidence the 'feature shader' is a vertex noise shader!

I wonder if Cg is flexible enough to allow me to port my "128 instruction Two Octaves 3D Noise with Surface Normals" vertex prog!

Remember folks, If anyone offers you a sub-standard 1 Octave 3D noise shader tell them you can get better elsewhere

Rob J.

[LordKronos]

Nutty, you beat me to it

Anyway, I think Cg looks halfway interesting. From reading about it, my take on it is that it will theoretically allow you to write a single instructions set and compile it to DirectX 8, DirectX 9, register combiners/vertex programs, and OpenGL 2. That would be a tremendous improvement over the current state of things. But in order for this to become something more than a sort of NV-GLIDE, we need other IHVs to support it. Until that happens, nvidia calling this "the new industry-standard Cg language" is nothing but a joke. Unfortunately, a glance at their list of "Companies Supporting Cg" does not yet include any of the IHVs.

I havent had time to look at it in detail yet. I did look at a few source files and it looks pretty nice. What Im not yet sure about is how this all goes into your app. Does it stay as source code and get compiled by the runtime? Does it get compiled to a platform-neutral bytecode? Will the code be able to dynamically upgrade to new platforms (such as if you ship it in an app today, then when OpenGL 2 or DirectX9 ships it will automatically use whatever is available). How do you deal with things like instruction set/number differences between hardware (say I ship a program using it today, and another IHV suddenly supports it a few months from now, but has a fixed set/number of instructions).

It looks like we still end up writing for multiple targets. The main advantage (assuming other IHVs support it) is just that we can use the same language for nvidia/ATI/matrox/etc opengl and for various versions of directX too. For the time being (until DX9/OGL2 support in hardware is mainstream) we wont have to write less code paths, just learn fewer languages/instruction sets.

[This message has been edited by LordKronos (edited 06-13-2002).]

[LordKronos]

In thinking more about it, I am actually starting to realize that perhaps the largest benefit of Cg is that you can write shaders in a high level language. I know that's pretty obvious, and its something that nvidia is pointing out, but I guess it didnt sink in for me because I personally am pretty comfortable with things like assembly language. Writing shaders in assembly or using register combiners is not a hold up for me. However, for a lot of programmers, it is. I always thought register combiners were perfectly fine, but in speaking to some nvidia guys a few years ago they said their biggest complaint was that a lot of developers were having trouble learning or getting comfortable with combiners. Same thing happens in assembly, a lot of programmers dont get the concept of a limited number of registers. They have X number of registers, but need 5x number of temporary variables. Sharing the registers among their "variables" just doesnt click with them. Being able to program in a high level language will let a lot more poeple do it.

Wait a minute. I dont want that to happen...it makes my skills LESS valuable

[santyhamer]

Hey, NVIDIA, what about the OGL 2.0 shading language? Deal to impose your standards in an .ORG WITHOUT the consent of other companies like ATI, SGI or Matrox???

I think the Shader-language war is started...