Jump to content

  • Log In with Google      Sign In   
  • Create Account

HLSL vs Cg: Any significant difference?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
15 replies to this topic

#1 Nairou   Members   -  Reputation: 431

Like
0Likes
Like

Posted 07 November 2004 - 07:03 PM

From what I understand so far, both HLSL and Cg accomplish exactly the same thing, and both are compiled into the same form of shader assembly code. Does this mean that, really, there is no significant difference between them? Can a shader implementation use the compiled code from either language identically, without regard to which language it was compiled from? If so, are HLSL and Cg nothing more than ways of making shaders easier to write, than actually adding features? If neither really adds anything new, why do we even have the two languages, as opposed to one? How different could they really be from each other?

Sponsor:

#2 superpig   Staff Emeritus   -  Reputation: 1825

Like
0Likes
Like

Posted 07 November 2004 - 09:24 PM

The reason they both exist is because they were brought out by two seperate companies. Cg was NVIDIA's creation; HLSL is Microsoft's.

NVIDIA have all but stopped supporting CG these days. Most people programming for Win32 use HLSL with DirectX; people on other platforms can use GLSL with OpenGL.

#3 mattnewport   GDNet+   -  Reputation: 1029

Like
0Likes
Like

Posted 07 November 2004 - 10:27 PM

The syntax of the two languages is nearly identical - most Cg code will compile with the HLSL compiler with minimal changes and vice-versa. Either compiler will generate more or less the same shader assembly for DirectX and the compiled shader code is independent of the language used to generate it. The difference lies in things like the constant tables - mapping shader input variables to constant registers will require different CPU side code for Cg and HLSL.

Microsoft and nVIDIA collaborated on the language design and development. The main reason Cg exists is that nVIDIA wanted to release it some time before HLSL was due to appear in DirectX and also wanted to support OpenGL and DirectX with the same language. At the time there was no GLSL and clearly MS weren't going to support HLSL for OpenGL.

The languages are 'nothing more than ways of making shaders easier to write' but don't understimate the value of that - C++ (and all other high level languages) is nothing more than a way of making assembly language easier to write but that doesn't make it useless. The reasons for the existence of both languages (really both variants of the same language) are historical / political and they're really not very different from each other.

#4 gjaegy   Members   -  Reputation: 104

Like
0Likes
Like

Posted 08 November 2004 - 12:00 AM

superpig: I thought CG development still go on. They released a beta version some weeks ago...

#5 superpig   Staff Emeritus   -  Reputation: 1825

Like
0Likes
Like

Posted 08 November 2004 - 12:52 AM

Quote:
Original post by gjaegy
superpig: I thought CG development still go on. They released a beta version some weeks ago...
Really? They're certainly not making a big deal of it any more - they're more pushing their HLSL-based tools, like FX Composer.

#6 Nairou   Members   -  Reputation: 431

Like
0Likes
Like

Posted 08 November 2004 - 08:35 AM

Awesome, thanks guys! That clears it up for me. I didn't know GLSL existed, thats good to know, I guess I'll just focus on HLSL then. :)


#7 Clueless   Members   -  Reputation: 181

Like
0Likes
Like

Posted 09 November 2004 - 09:22 AM

Just to be sure: I think I read that old hardware supports Cg but not GLSL.

Is that correct? Does it make sense to support CG and GLSL in one engine then?

#8 AdAvis   Members   -  Reputation: 518

Like
0Likes
Like

Posted 09 November 2004 - 10:35 AM

Quote:
Original post by Clueless
Is that correct? Does it make sense to support CG and GLSL in one engine then?


Personally I would just choose one and stick with it. GLSL requires a ARB_vertex_shader/ARB_fragment_shader level card--Cg can compile some Cg shaders down to a vp20/fp20 (NV register combiners) level card--of course I doubt you'll be able to compile all of your shaders to that level. At least I've had some problems with shaders that compile fine for the arbfp1 that don't like compiling for a GeForce 4.

But I digress--If you need support for older cards and/or API independance, go with Cg. Else use GLSL.

That's just my opinion, though. [smile]

#9 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 09 November 2004 - 10:59 AM

Correct me if I am wrong here, but for those who want to go for API independence, neither HLSL or GLSL is an appropriate choice, correct? Afterall, no one wants to write two different versions of the same shader for their game.

#10 AdAvis   Members   -  Reputation: 518

Like
0Likes
Like

Posted 09 November 2004 - 11:03 AM

Quote:
Original post by Anonymous Poster
Correct me if I am wrong here, but for those who want to go for API independence, neither HLSL or GLSL is an appropriate choice, correct? Afterall, no one wants to write two different versions of the same shader for their game.


You are correct, HLSL and GLSL are specific to Direct3D and OpenGL, respectively. However, Cg (though being an almost indentical language as HLSL) has runtime bindings for both Direct3D and OpenGL--you can use the same shader code for either API with Cg.

#11 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 09 November 2004 - 11:07 AM

Originally when I had first started getting into shader languages I was really looking forward to using Cg, but then it looked like it was never getting updated. On top of that nVidia started releasing FX Composer (um.. ok?). It really didn't make sense to me. I'll be honest, this really feels like a situation where not only is there no right solution, but no good solution either.

#12 superpig   Staff Emeritus   -  Reputation: 1825

Like
0Likes
Like

Posted 09 November 2004 - 02:00 PM

Quote:
Original post by Anonymous Poster
Correct me if I am wrong here, but for those who want to go for API independence, neither HLSL or GLSL is an appropriate choice, correct? Afterall, no one wants to write two different versions of the same shader for their game.
That's a fair point. Though from what I understand, HLSL and GLSL are pretty similar - such that porting shaders from one to the other shouldn't be difficult. If you wanted to avoid porting altogether then Cg could well be a better bet.

#13 mattnewport   GDNet+   -  Reputation: 1029

Like
0Likes
Like

Posted 09 November 2004 - 11:48 PM

API independence is overrated. If you want to support non-Windows workstation/PC platforms (x86 Linux, Macs, maybe some other Unix flavours on x86, PowerPC, maybe even Itanium) then go with OpenGL and GLSL. If you are happy with just Windows support (and maybe easier porting to Microsoft console platforms) then go with Direct3D and HLSL. If you want to support other console platforms then there are no higher level shader languages or open APIs so the whole point is moot.

OpenGL is the closest thing to a cross platform graphics API there is. There's little point for most people in building an API independet renderer on top of it. Far better just to pick your API and get on with making your game.

#14 JesseT   Banned   -  Reputation: 402

Like
0Likes
Like

Posted 10 November 2004 - 10:45 PM

Quote:
Original post by superpig
Quote:
Original post by gjaegy
superpig: I thought CG development still go on. They released a beta version some weeks ago...
Really? They're certainly not making a big deal of it any more - they're more pushing their HLSL-based tools, like FX Composer.


Cg and HLSL are pretty much the same language, except that nVidia's Cg has some extra facilities to support OpenGL. In fact, Cg and HLSL were both co-developed by Microsoft and nVidia. So while you might hear less about Cg and more about HLSL as time progresses, Cg lives on in DirectX with a different name.

FX Composer is both an HLSL and a Cg tool, because the shaders you write with FX Composer can still target OpenGL using the Cg Toolkit SDK. But for the most part, it's 99.9% compatible with HLSL... right down to the use of techniques and effects.

One problem that the Cg Toolkit SDK doesn't support that DirectX does is vertex and pixel fragment linking. This allows you to construct shaders from multiple fragments that implement different aspects of a complete shader. It's exposed through the CG/HLSL keywords "vertexfragment" and "pixelfragment". In DirectX, you link fragments together using ID3DXFragmentLinker or Microsoft.DirectX.Direct3D.FragmentLinker.

I've complained to nVidia about this, so hopefully they will get around to supporting it in their tools. They're currently accepting input from the development community on which direction people would like to see nVidia's development tools go.

While semantically, there are many similiarities between HLSL/Cg and GLSL, syntactically they are different languages. And afaik, GLSL does not support fragment linking in any form.

The GLSL or OpenGL Shading Language was pioneerd by 3DLabs in their OpenGL 2.0 proposal, which was mostly scrapped, as they originally proposed to make OpenGL an object-oriented C++ API. But as you may know, this isn't the case with the OpenGL 2.0 specification today. Yet, GLSL was accepted by the OpenGL ARB over Cg, which nVidia pushed hard.

ATI and Discreet are working on some tools for abstracting the underying shader architecture. ATI's Ashli technology can transform an HLSL, GLSL, or a RenderMan shader into an either a compiled HLSL or GLSL shader. Discreet has integrated Ashli into 3DS Max 7 and has add a transformation pipeline for converting 3DS Max materials into compiled HLSL or GLSL shaders.

However, after looking at it, I still thought that these technologies were rather immature, as they generated subpar code and there were no good user interfaces to control the transformation process. I expect it will improve over time though.

I'm not sure what Alias or SoftImage have in mind for their DCC toolsets.

#15 Nairou   Members   -  Reputation: 431

Like
0Likes
Like

Posted 14 November 2004 - 12:51 PM

Now I'm a bit confused. Other than platform, whats the difference between HLSL and GLSL? I just assumed GLSL was OpenGL's way of using HLSL shaders.

#16 AdAvis   Members   -  Reputation: 518

Like
0Likes
Like

Posted 14 November 2004 - 01:05 PM

Quote:
Original post by Nairou
Now I'm a bit confused. Other than platform, whats the difference between HLSL and GLSL? I just assumed GLSL was OpenGL's way of using HLSL shaders.


GLSL is OpenGL's shading language (which is different than HLSL), which has recently been made part of the OpenGL core.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS