   CG vs GLSL?
  Which shader language do you prefer and why? My question has nothing to do with the compiler but rather a comparison of the syntax of the two languages. In other words which language is "prettier?"   
  The only syntactical preference I have in GLSL is initializing a vector from a single float as [font="Lucida Console"]vec4 one = vec4(1)[/font] instead of HLSL's [font="Lucida Console"]float4 one = (float4)1[/font].Besides that, I prefer HLSL's syntax (AKA Cg) for pretty much everything else.The lack of [font="Lucida Console"]saturate[/font] in GLSL really bugs me (having to write [font="Lucida Console"]clamp(x,0.0,1.0)[/font] instead). Also, GLSLs strictness on always putting a ".0" on the end of constants to stop them becoming integers gets a bit much sometimes too.Plus -- off topic but -- the HLSL compilers are stricter on syntax errors, whereas the GLSL driver is part of your graphics driver -- meaning syntax that compiles without warnings on one driver, may in fact fail to compile at all on other drivers.;Plus -- off topic but -- the HLSL compilers are stricter on syntax errors, whereas the GLSL driver is part of your graphics driver -- meaning syntax that compiles without warnings on one driver, may in fact fail to compile at all on other drivers.Use the #version directive to avoid getting caught in such problems. The compiler will have to respect the GLSL specification.http://www.opengl.org/wiki/GLSL_:_recommendations   ;Use the #version directive to avoid getting caught in such problems. The compiler will have to respect the GLSL specification.I was thinking of the fact that nVidia divers accept HLSL syntax (e.g. float4, saturate) without error/warning, no matter the #version specified. i.e. nVidia's driver's GLSL compiler accepts code from an entirely different language... ;[quote name='V-man' timestamp='1303574434' post='4801977']Use the #version directive to avoid getting caught in such problems. The compiler will have to respect the GLSL specification.I was thinking of the fact that nVidia divers accept HLSL syntax (e.g. float4, saturate) without error/warning, no matter the #version specified. i.e. nVidia's driver's GLSL compiler accepts code from an entirely different language... [/quote]Not in my case.If I don't specify the version, then it outputs as a warning.If I do specify the version, those warnings turn into error messages.I just tested it now for float4 and also saturate().   ;Plus -- off topic but -- the HLSL compilers are stricter on syntax errors, whereas the GLSL driver is part of your graphics driver -- meaning syntax that compiles without warnings on one driver, may in fact fail to compile at all on other drivers.Yeah, I got caught out with GLSL array initialisation. On Windows the driver was silently letting me do it, but on Mac it failed on me. I blame Nvidia for being lax. (Actually, I wasn't really impressed, as I wasted some time tracking down what the problem was.)   ;  GLSL over CG. I like the GLSL syntax much more, and recently had too much trouble just finding a reference on the NVidia site and discovering that CG doesn't implement an inverse function for matrices. NVidia seem to have several failings nowadays (dodgy compiler, website reorganisation / broken links).I actually prefer clamp(x, 0.0, 1.0) over saturate() because saturate is a fairly non-descriptive name. With clamp it's immediately obvious that I'm clamping a value between two other values, with saturate find I have to actually think about it. Personally I'd rather type 5 extra characters and make what I'm doing more apparent, but YMMV...I've always found GLSL quite a pretty language to use, whereas HLSL / CG are fairly ugly with all the semantics : COLOR, : POSITION around the place.   ;[quote name='V-man' timestamp='1303574434' post='4801977']Use the #version directive to avoid getting caught in such problems. The compiler will have to respect the GLSL specification.I was thinking of the fact that nVidia divers accept HLSL syntax (e.g. float4, saturate) without error/warning, no matter the #version specified. i.e. nVidia's driver's GLSL compiler accepts code from an entirely different language... [/quote]more like CG syntax. Apparently NVidia is using a modified CG compiler for GLSL or something like that, because it allows some non-GLSL statements, while AMD compiler follows the specification in a more strict way.;  @V-man - interesting, maybe their drivers have gotten better since I last checked  Still a con that the compiler is paired with the driver though, rather than being standalone.more like CG syntax. Potayto/potahto -- "Microsoft HLSL" and "nVidia Cg" are two different implementations of the HLSL.I actually prefer clamp(x, 0.0, 1.0) over saturate() because saturate is a fairly non-descriptive name. With clamp it's immediately obvious that I'm clamping a value between two other values, with saturate find I have to actually think about it. Personally I'd rather type 5 extra characters and make what I'm doing more apparent, but YMMV...That's a good point, but I prefer saturate for the very same reason  A clamp-to-0-and-1 (aka saturate) operation can be appended onto other operations for free, whereas any other kind of clamp can't. So I prefer to write saturate when I mean clamp-to-0-and-1 so it's more apparent that I want a "free clamp" rather than an "expensive clamp".   ;  Are you saying that the driver can't detects the clamp(x, 0.0, 1.0) and append a SAT and you don't get your free "clamp"?Also, if you really want saturate() then I'm sure that you can define your own in GLSL.All that are poor examples of chosing one over the other.The biggest reason to chose GLSL is that it is native to GL. It will work on AMD and nVidia.Cg would have to be compiled to GLSL to work on AMD.Or, Cg would have to be compiled to the archaic ARB_vp ARB_fp and that is not recommended for years.Even on D3D10 and 11, you have to code in their own HLSL. Cg is a dead end technology.http://www.opengl.org/wiki/Selecting_a_Shading_Language   