CG stands for C for graphics. Instead of programming in assembler we now program in C/C++

So you can program your GPU in CG instead of assembler code. On the NVidia website you will find all the things you need for CG including tutorials..

quote:Original post by gimp
Oh, and I''ve noticed that a nVidia specific compiler exists, does that mean that I need to get the ati compiler to also have my code run on ATI cards? Why is a compiler card specific?

Chris Brodie
http:\\fourth.flipcode.com

Nope.
You have to specify a target profile for compilation.

Available profiles include DX8 and DX9 vertex and pixel shaders.
Of course such profiles makes you able to run your programs on every vard supporting DX8/9 shaders.

On OGL side, supported profiles include arb vertex program and arb fragment program.
ATI cards should support them like latest nvidia drivers release.

As far as I know today Cg is the only High Level Shading Language available that can run on different cards and different systems (of course DX HLSL is bounded to win32 applications).

Uhm just to make some concepts clearer...

quote:Original post by gimp
1) From a programming perspective what can all this stuff really be used for? I''ve looked over a few shaders but I can''t seem to gauge the extents of this technology. Will it even replace the need for most textures perhaps by proceedurally creating them?

I don''t think shaders will ever replace textures.
Actually a shader can be used to lower CPU usage (i.e. you can implement a skinning shader, a particle system manager, etc.) or to create astonishing effects.

In order to draw polygons fast it is suggested to have vertex buffers stored in video card memory.
To modify every frame a vertex buffer can slow down your application. By using shaders you can keep your data throughput as high as possible, while the GPU makes all the work.

quote:
2) Is cg\shaders like a congruent method for performing special effects on a card?

Yes.

quote:
3) Will this replace most of the requirements for all those Gl extentions?

Yes and no. Yes because extensions like arb_vertex_program, arb_fragment_program, nv_vertex_program, etc. are directly accessed by Cg libraries. No because the bigger part of OGL extensions are not about vertex/pixel shaders. Vertex and pixel shaders come into play after you send a primitive. Everything you do before it is a your own problem..

quote:
4) If I add a cg block of code on a a surface in my game am I likely to run it on say most of the HW out there, if not, then what would happen on those machines?

You should take care of it and it depends upon the type of program you''re writing. If I have a cloth simulation on a vertex shader and I''m running my app on non-vs hw probably there''s no problem. The cloth is non-interactive and drawn always like original mesh. On the other hand, if I have a skinning shader, my charachters would never animate.

quote:
5) How does this all fit in with OpenGL?

It doesn''t fit into OpenGL. You make some calls to Cg and CgGL libs, and they directly interface with OpenGL.