Which in your oppinion would be the best shader language to learn,

Cg
glSlang
low level Vertex/Fragment Shaders
Other

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

I personaly would recomend low level Vertex/Fragment Shaders, because they run faster on most graphic cards, at least for now.
But GLSlang is good to, because it will be faster on the next generation of graphic cards.

With Shaders you invest in the future. So I think GLSLANG would be best. Lock at the recent poll. You see: less then 40% have shaderable(?) cards. And this is a OpenGL-Board. Normal users mostly don't have shaderable cards for now. When everybody has such cards, GLSLANG would also be fast enough.

Just my 2 cents

_________________
Blog: kevin-fleischer.de und fbaingermany.com

GLSL is slow because, the compiler is full of bugs, at least on ATI hw.
I prefer ARB_fp, because you will need many different shaders and you can't write them all by hand. If you've more than one standard material and one light type, there are many combinations for each light/material interaction and for each renderpass. It is necessary to generate them from a higher level material definition and that's easier with ARB_fp. GLSL is to high as a compile target, because it introduces another level of indirection that I don't need. ARB_fp is widely supported and it is fast.

What is this ARB_fp? How do I get my hands on it? And sites devoted to it? My Google search turned up nothing specific.

search for arb_fragmentprogram.
It's basicly the low level fragment shader language

your card needs to support ARB_FRAGMENTPROGRAM to use fragment shaders.

Nvidia 5 series and up support it (i think Fragment shaders started appearing on the 5 series)

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

I would say that Cg is a good middle ground, because it adapts to the card it is running on.

You could get the best performance from this for nvidia specifically because of the way you implement the actual cgCalls

It compiles to a number of different "Lower Level" languages, or you can ask it to just use the best it can find.
Also, another factor to consider is the amount of time you spend coding your shader.

I dont know about you, but I find it VERY hard to figure out what the ARB_fp etc.. does because of the ASM like code.

Where Cg models the C language, and is MUCH easier to read.

_________________
Im out of my mind but please leave a message...
www.sulaco.co.za

I don't intend to start a "windows vs. linux"- or "c vs. pascal"-like flamewar here (use whatever you prefer as long as you're happy with it), but would like to comment my concerns on cg

Cg might offer nice toolkits/libraries to speed up development, but remember what to 3Dfx's Glide happened. The company went bankrupt and the new owner (S3 i think) didn't have much interest in continuing their efforts, last thing of Glide i've seen was some major buggy DirectX wrapper.
I'm neither predicting that nVidia will bankrupt soonish, nor that the new owner would discontinue their strongest section. But remember that cg is property of nVidia and if a new graphics card vendor should enter the market, their hardware might not work flawless with cg default profiles you want to use or it might take a while till custom profiles are available for cg (but proper OpenGL support will most likely be one of that new vendor's major concerns, since cg can compile to standard OpenGL aswell). I might be wrong about this, but from what i know about cg it has optimized profiles for nvidia hardware extensions mostly, it might not be in their interest to support the competition at all - or the competition's interest to support nVidia's cg. If you already made the step to decide not to be tied to DirectX platforms it might be worth a thought not to tie yourself to a graphics card vendor. After all it's only about the $ for companies.

Conclusion: I tend to agree with Flash and Tomok. glslang is worth a look, especially since you will need some time to develop software - glslang will most likely improve

@Lars: You are right, glslang isn't very mature at it's current state, but would you really recommend a beginner zo shaders to start with arb_fp? I remember, you wrote fxPascal and are way beyond average's programmer skill...

@McClaw: The readability of your shaders in glslang is not much different from cg in my opinion, this argument applies to arb_fp though.

Just my 2c, didn't intend to offend anyone.

-Silk

_________________
"Look at you, Hacker. A pathetic creature of meat and bone, panting and sweating as you run through my corridors. How can you challenge a perfect, immortal machine?" - Shodan

Cg ist very similar to Direct3D HLSL. If NVidia stopps Cg development, you can always use DirectX.
GLSL is very easy to use and the idea of compiling in the driver is good, because the driver can optimize your shader. But infact it doesn't good enough. Even the NVidia glsl compiler produces not optimal code, when using ps30 features like loops. The performance difference between dynamic and static branching is very huge and the compiler doesn't detect when static brachning should be used. I testet the same shader with glsl,Cg and DirectX HLSL and only the Direct3D compiler produces the correct code. But sometimes glsl is faster than ARB_fp on NVidia cards.
You should use glsl, because it will be hopefully faster sometime, but the current implementations are not very useable. I suppose to support both. You have to support pixel shader 3.0 (glsl,nv_fragment_program2), because it it standard. But you also need to support ARB_fp, because there are many users with Radeons and GFFX. The best solution in my optinion is to use ARB_fp for ps20. The length of these shaders is limited and so it is not a problem to write them in ARB_fp. For pixel shader 3.0 it would suggest to use glsl and in the special case, when the compiler doesn't produces the fastest code, to use nv_fragment_program2 as an option on NVidia cards.

You can also use Cg to compile GLSL programs into ARB_vp/ARB_fp.

cgc -oglsl -profile vp40 test.txt