PDA

View Full Version : CG rather than raw GLSL



knackered
06-27-2006, 10:58 AM
Any thoughts on the pros and cons of using CG versus directly using GLSL?
I've never really got into using CG - at the time of its release I was deep into the assembly languages. When I eventually got chance to look around, GLSL was in the drivers so I naturally went for that.
But now, I'm looking at CG.....it's cross platform, compiles to any level of hardware, compiles to GLSL, is easy to use, and has the brilliant fx files which allow an artist to tweek the params in 3dsMax.
So why would anyone use GLSL as their primary shader language?

Zengar
06-27-2006, 11:01 AM
The two are really almost equivalent in syntax and features... GLSL is better integrated in OpenGL though...

zeoverlord
06-27-2006, 11:18 AM
They are infact so equivalent in syntax and features that Nvidia just modded their CG compiler into the GLSL compiler in their drivers.

But in my opinion GLSL has a syntax that is a bit cleaner and easier to read than CG.

knackered
06-27-2006, 12:27 PM
Quickly comparing the two languages, I agree that the syntax of GLSL is much better than CG, plus it has all those built in uniforms.
But it's the other aspects of CG that I'm really talking about - the FX framework, the 3dsMax/Maya plugins, the FX composer. There just doesn't seem to be these tools for GLSL. Or am I missing something?

[edit]
hold on one cotton-picking minute...there's no module support in CG? There's no compile+link stages?
Right, in that case forget it, I can't imagine the plethora of shaders I'd have to generate...
That's a pretty dire omission from CG.

yooyo
06-27-2006, 02:27 PM
Im not sure... if im wrong someone should explain this better...
CG code can be compiled using CG compiler. Right? Output is ARB VP/FP. NVidia extend ARB VP/FP with few more instruction to support SM3.0 features. I don't have ATI card but im wondering did ATI extend ARB VP/FP with their SM3 instructions? 3DLabs Wildcat support only GLSL... no ARB VP/FP. So... from my point of view GLSL has better support.

Matt Zamborsky
06-27-2006, 02:50 PM
CG can be also compiled to GLSL in version 1.5, which is still beta.

zed
06-27-2006, 11:28 PM
glsl syntax is cleaner + more c like (cg == c for graphics == misnomer) though i wish glsl would relax the strict use of floats 1.0 cant be written as 1, also float4 is better than vec4 plus other minor quibles.

the major benifit of cg is its whats used on the ps3

mjkrol
06-28-2006, 10:08 AM
Originally posted by knackered:
There just doesn't seem to be these tools for GLSL. Or am I missing something? Actually, there is a tool for GLSL - it is... CG.
Don't you see? GLSL and CG can't be compared, because they live in different worlds. The language you choose (ASM, GLSL, CG) depends on the complexity of your project. When you develop e.g. a 3D engine, you come to a point, where you need some sort of a management system for your shaders. Depending on your needs, GLSL with its multiple module feature is sufficent, or you pick CG with multiple target feature to cover bigger market, but you must deal with this "plethora of shaders".
If CG had not have something GLSL has, I would go for GLSL. But I think they do not differ so much, so the issue collapses to a simple choice - which language has longer feature and programing-candies list.

Regards

Korval
06-28-2006, 12:12 PM
Right, in that case forget it, I can't imagine the plethora of shaders I'd have to generate...I know the feeling. If there was one thing that glslang got right, it was that.

knackered
06-28-2006, 12:50 PM
Originally posted by mjkrol:
Actually, there is a tool for GLSL - it is... CG.
Don't you see? GLSL and CG can't be compared, because they live in different worlds...I know what you're saying, I understand perfectly well CG's roll in all this - and I appreciate your input, really I do.

I suppose the #include directive in CG can be levered into emulating a proper compile/link environment. Then instead of just compiling source files and linking, you'd just generate a proxy source file which includes the other sources, and call 'compile' on it....but then, which source file declares the uniforms etc.
Seems a bit crap, but there you go.
I suppose what I'm really saying is - can someone (not me) write a decent FX file format for GLSL and a couple of 3dsMax/Maya material/viewport plugins?
[edit]
it seems I'd forgotten completely about rendermonkey....it's come so far since last I looked.
http://developer.3dlabs.com/openGL2/rendermonkey/index.htm
[edit]
bollocks to that, last updated 2004 - I'm so ashamed.

ZbuffeR
06-29-2006, 02:21 AM
And what about Shader Designer (http://www.typhoonlabs.com/index.php?option=com_content&task=view&id=13&Itemid=33) ?

knackered
06-29-2006, 09:05 AM
mmm, looking into it now...thanks.

CaseMillennium
07-07-2006, 08:40 AM
Originally posted by knackered:
hold on one cotton-picking minute...there's no module support in CG? There's no compile+link stages?
Right, in that case forget it, I can't imagine the plethora of shaders I'd have to generate...
That's a pretty dire omission from CG. [/QB]Mmhhh, ok, what exactly do you mean by modules in GLSL?
I have been using both, GLSL and CG, and while GLSL has a much clearer syntax it misses some very handy features like interfaces which make programming a lot easier ( I would not want to do something like maya┬┤s hypershade with GLSL while doing it with CG was pretty easy). Also, CG is not just a Shaderlanguage but a complete toolkit which takes care of loading and compiling your shader.

Case

Overmind
07-07-2006, 10:23 AM
Mmhhh, ok, what exactly do you mean by modules in GLSL?Linking multiple shader objects (multiple = more than one of each kind) into a single program object.

knackered
07-07-2006, 01:09 PM
Yes, like, a directional phong light module, which declares the varyings and uniforms it requires.
If these same varyings are needed by a point light module, there's no problem, the point light module declares it, and the linker sorts it out so the varyings are shared amongst the modules. With CG you have to make do with the #include directive, and/or some mad string juggling.
This is one of the chief things that separates C from basic (and apparently GLSL from CG). Modularity.
But CG does have an awful lot going for it, like its tool chain, and FX files, but to be honest I'm not overly concerned with fall backs, so techniques aren't that valuable in reality (just haven't the need to build 3 different versions of the same effect to accomodate obsolete hardware) - and I'd imagine they'll become less and less important each passing month. So you're left comparing the two languages from a software engineers point of view.

Chuck0
07-08-2006, 04:32 AM
uhm cg has interfaces which are a rather complete replacement for the linking which is possible in glsl.

knackered
07-08-2006, 07:08 AM
Ok, right, just read about CG interfaces, and it does look like a nice system.
So now I'm looking at the tool chain as a whole again....and CG is looking better.

Overmind
07-08-2006, 07:30 AM
cg has interfaces which are a rather complete replacement for the linking which is possible in glsl.Could you elaborate this a bit further? Sure, interfaces look like a nice abstraction for different implementations of a function.

But what about the situation where a different implementation of a function requires additional vertex attributes? Do I declare the variables inside the struct, or outside? What if I need it in two interfaces, but I don't know that in advance?

And what about additional varyings that are needed only in some of my modules, and not in others?

With GLSL it's easy, just declare every variable you need, the linker figures it out.

Perhaps I misunderstood something about cg interfaces, but I just don't see any easy solution for these problems.

knackered
07-08-2006, 08:08 AM
This is something I'm not clear on either, without physically trying it out. (I'm aware this isn't a CG forum, but this thread is a comparison between GLSL and CG).
Uniforms are passed in as parameters to the main in a CG program, but these uniforms can be structures, and these structures can also be derived from interfaces?
Taking the example from the user manual:-

....CG program....

interface Light
{
float4 value();
};
struct SpotLight : Light
{
float4 value() { return float4(1,2,3,4); }
};
float4 main(uniform Light l[]) : COLOR
{
float4 v = float4(0,0,0,0);
for (int i = 0; i < l.length; ++l)
v += l[i].value();
return v;
}

...cgFX file....

SpotLight spots[4];
technique
{
pass
{
FragmentProgram = compile arbfp1 main(spots);
}
}What about materials? Do I have to store the materials in a light structure repeatedly for each light, or is there a way of writing into a global set of uniforms?

Chuck0
07-08-2006, 12:58 PM
Originally posted by Overmind:

cg has interfaces which are a rather complete replacement for the linking which is possible in glsl.Could you elaborate this a bit further? Sure, interfaces look like a nice abstraction for different implementations of a function.

But what about the situation where a different implementation of a function requires additional vertex attributes? Do I declare the variables inside the struct, or outside? What if I need it in two interfaces, but I don't know that in advance?

And what about additional varyings that are needed only in some of my modules, and not in others?

With GLSL it's easy, just declare every variable you need, the linker figures it out.

i have to confess i didnt try this out (and i dont have much experience with glsl) but for example the following should work...




Perhaps I misunderstood something about cg interfaces, but I just don't see any easy solution for these problems. Im not sure, if the posted code completely satisfies you, but i guess it shows how cg shaders could work in the situations you described.

Chuck0
07-08-2006, 01:21 PM
Originally posted by knackered:
What about materials? Do I have to store the materials in a light structure repeatedly for each light, or is there a way of writing into a global set of uniforms? im not quite sure if i understood the question correctly, but what about writing a material structure which can be passed as parameter to the lighting function of the light structure like this:

struct Material
{

float4 diffuse;
};

interface Light
{
float4 performLighting(Material m);
};

struct DirLight: Light
{

float4 performLighting(Material m)
{
return m.diffuse;
}
};furthermore it is possible to declare global variables (just like in c).

Overmind
07-09-2006, 03:43 PM
What you posted is a partial solution to the situation I described. It works only if there is no overlap in required attributes. What if I have two independant interfaces, and both of them might need some particular attribute in one of their implementations?

The other situation that is not covered in your example is adding additional varying variables. For example, some light models might require the view vector, while others require just the light vector...

knackered
07-10-2006, 07:13 AM
This is all a bit confusing. I'll stick with GLSL for now, I'm comfortable with its compile/link stages and I didn't have to read a manual to understand it.

Chuck0
07-10-2006, 01:23 PM
i guess in the end it comes down to personal preference and familiarity when deciding which high level language should be chosen.

and yep i guess there are cases where cg just isnt as flexible as glsl. (it was the first language i tried and well... i got used to it :) ). still i think it does have its merits.