What are the pros / cons of the three?

  • 2
    \$\begingroup\$ It seems like you first would need to decide on what API you were going for (OGL or DX) and what platforms before you decide what shader language. \$\endgroup\$
    – Tetrad
    Sep 22, 2011 at 15:45
  • 1
    \$\begingroup\$ I think this question is brilliant. How about a community wiki? I am new to all this and a question of the differences to shaders is exactly what I need to know. \$\endgroup\$ Jul 18, 2013 at 9:03
  • 3
    \$\begingroup\$ Correction: "closed as not constructive" should say "closed as violating dimwit policy", because this IS constructive. \$\endgroup\$ Oct 19, 2014 at 19:33
  • \$\begingroup\$ This is no longer accepting answers, sadly, so I'll have to leave a comment: you can choose either GLSL or HLSL if you're using Vulkan, both can be compiled to SPIR-V. \$\endgroup\$ Jul 15, 2021 at 8:58

6 Answers 6


coderanger is right about HLSL targeting DirectX, GLSL targeting OpenGL and CG being available with both interfaces.

However there are other things to consider (learned on the OGRE forum) :

  • CG will not allow you to use the latest features of GLSL (I'm not sure about HLSL). It's a middle ground so you'll not be able to fully exploit the GLSL features, only the common one until Shader Model 3.0 (AFAI understood).
  • CG is made by NVidia that optimize it for it's card but don't seem to do lot of work for ATI cards... some people report that there might be problems with ATI cards using CG.
  • OpenGL seem to be a bit slower than DirectX on Windows platforms. That's really relative to what you're doing and the reason for this find it's source in the drivers implementations but it's good to know before you choose the API and the associated shader language. However, OpenGL is the only one interface available on all (win/mac/unix/some consoles) platforms. So knowing that, using exclusively GLSL might be the better choice for a non-Microsft-centric-cross-platform game.
  • NVidia drivers on Linux seem to be more stable than ATI drivers, making CG more interesting if you need to be sure it works nicely on linux (that's all reported informations, you'll have to check for details)

So, if you're not using the lastest shader features, CG seem a good choice. GLSL seem a beter one if you're going full OpenGL. HLSL if you're going exclusively on Microsoft platforms.

Now first developping in HLSL for windows to use DirectX and then convert to GLSL for linux and mac could be the better solution to be sure of performance and have the larger set of shader features available. It might however be a lot of work (didn't do it myself so I cannot tell). OGRE graphics engine (and other engines) allow to use any API (DirectX or OpenGL or others) so it helps, but there is still shader code to convert if you go this way.

That's all the information I gathered while choosing my shader language (I've not made my decision yet).

Update: Valve did a conversion of one of their game to OpenGL and found no way to make the DirectX version faster than the OGL one. So keep in mind that the state of driver implementation, API quality, etc., all that change too much each year for you to totally rely on raw performance as an argument to choose one or the other. With this in mind, choose OpenGL/GLSL to simplify your life when working (or having plans or hopes to work) with other platforms than Windows, use DirectX/HLSL if you really want to use only Microsoft platforms and focus and maybe have some good API faster than OpenGL (this is reversing now, so don't count on it); use CG if you want to provide both possibilities to the user, but if you have the work force (and tools) to do it, using both GLSL and HLSL might be a viable solution too.

Update (2012): It is important to note that CG has been discontinued, and is no longer supported or actively worked on by Nvidia. Nvidia recommends that all users switch to a combination of GLSL and HLSL, or a newer library such as nvFX (on github). This is because it was too difficult to maintain feature-compatibility between GLSL and HLSL.

  • 3
    \$\begingroup\$ Yes. NVIDIA doesn't seem to care about problems with ATI cards. \$\endgroup\$
    – bobobobo
    Sep 21, 2011 at 17:07
  • 4
    \$\begingroup\$ "OpenGL seem to be a bit slower than DirectX on Windows platforms." In most cases it's usually due to vendor support for drivers with OpenGL is not as good on Windows as it is with DirectX. \$\endgroup\$
    – ChrisC
    Sep 21, 2011 at 21:10
  • 1
    \$\begingroup\$ Note: I chose OpenGL/GLSL in the end because of recent improvements and the need to make sure my game works on some non-MS tablets. \$\endgroup\$
    – Klaim
    Dec 8, 2012 at 10:28
  • 2
    \$\begingroup\$ @Community: Do you have any links for the discontinuing of support for Cg? \$\endgroup\$ Jul 29, 2013 at 8:21
  • 1
    \$\begingroup\$ developer.nvidia.com/cg-toolkit \$\endgroup\$
    – Jinbom Heo
    Oct 14, 2014 at 9:19

I can only talk about CG vs HLSL because those are the 2 I have used so far.

Cg is not the same as HLSL.

In Cg, NVIDIA did an excellent job in creating a very clean shader syntax. Its very similar to HLSL.

But, tie-together with D3D9/D3D11 (init code, shader compilation code) is much cleaner on HLSL than Cg. -1 Cg. Cg has a nasty bit of start up code that you don't even need to have for HLSL over D3D.

In Cg, you have to "cgGetNamedParameter" for every uniform shader variable you want to set/modify. And you have to maintain a CGparameter reference in your code for that variable

// C++ code to interact with Cg shader variable (shader language independent)
CGparameter mvp = cgGetNamedParameter( vs, "modelViewProj" ); 
CG::getLastError("Getting modelViewProj parameter");  // check for errors
cgSetMatrixParameterdr( mvp, &modelViewProj._11 ) ;   // setting the matrix values

In HLSL, this ends up being much cleaner - just one line, and you don't have to maintain that CGparameter variable.

// D3D9 C++ code to interact with HLSL shader variable
DX_CHECK( id3dxEffect->SetMatrix("modelViewProj", &mvp._11 ), "Set matrix" ) ;

In the above, DX_CHECK is just a simple function that checks the HRESULT that gets returned from the SetMatrix call. The above code is d3d9. D3D10 and 11, are of course, a lot more painful (since there isn't an ID3DX11Effect object).

Before I started using HLSL, I used to look at this code and actually get jealous.

Although NVIDIA did their best to make a common interface for Cg between OpenGL/D3D, practically speaking its not that way, and you have cgGL*, cgD3D9, cgD3D10, cgD3D11 function groups to contend with. So that whole works for OpenGL and D3D!! claim only goes so far. You still have to wrap everything up into OpenGL/D3D #ifdef type groups to make it work on different platforms. -2 Cg.

Further I have recently had a bad experience with Cg/ATI cards, which I'm pretty sure isn't my bad. (Someone else try it out?). I think it may be true that NVIDIA doesn't completely test ATI cards, as Klaim claims. Or that ATI doesn't test on Cg. One way or the other, there's a mismatch there and some sort of conflict of interests. -3 Cg.

All in all I preferred Cg. Its shader code syntax and naming is clean, sweet, and tidy. Its too bad its got these other problems.


My very basic understanding is that HLSL is only for DirectX and GLSL is only for OpenGL. Cg is basically the same language as HLSL, but can be used with either DirectX or OpenGL (though via different runtime code).

  • \$\begingroup\$ +1 That's my understanding as well, personally I like using cg whenever I can, but it does add an extra dependency beyond the render system itself; and I seem to recall having some strange issues with OpenGL, cg and ATI drivers with some more complex effects... \$\endgroup\$ Oct 1, 2010 at 21:20
  • \$\begingroup\$ I'm using Ogre and thus have all three available to me, but if I want to have both DirectX and OpenGL I have to either write the shaders in both HLSL and GLSL or just cg? Is that right? \$\endgroup\$
    – Z_guy
    Oct 1, 2010 at 21:53
  • 16
    \$\begingroup\$ -1. This is an extremely rudimentary answer and one would hope to find more extensive information on this site. \$\endgroup\$
    – bobobobo
    Sep 21, 2011 at 17:23
  • 2
    \$\begingroup\$ -1: I agree with bobobobo. \$\endgroup\$ Sep 22, 2011 at 1:13
  • 1
    \$\begingroup\$ Unfortunately I have to -1 for the same reasons as bobobobo. \$\endgroup\$ Mar 15, 2012 at 15:13

Another crucial difference between HLSL and GLSL (I don't know CG so I can't speak for it) is that with HLSL Microsoft provide the shader compiler as part of the D3D runtime whereas with GLSL your hardware vendor provides it as part of their driver.

This has advantages and disadvantages on both sides.

With the GLSL method the vendor can tune the compiler to the capabilities of their hardware. They know their own hardware best, they know what to do and what not to do. On the other hand the disadvantage is that - in a world where there are multiple hardware vendors - you have a situationwhere there can be inconsistencies between shader compilers, and the vendor also has complete free reign to screw up.

With the HLSL method Microsoft control the compiler. Everyone is on a consistent tech base, and if a shader compiles successfully in one place then it can be reasonably supposed to compile everywhere. The same shader will produce the same compiled output irrespective of vendor (all other things being equal of course). On the other hand the HLSL compiler has to be a "works consistently on everything" thing, so it's not able to pull any special vendor-specific tricks to get the last few drops of juice out of the tank.

If this comes across as though I have a preference for the HLSL view of the world it's because I do. I've been bitten badly before by wildly inconsistent behaviour on different platforms, and in one case even ended up having to roll a load of GLSL back to ARB ASM just to get a baseline that worked. NVIDIA's GLSL compiler can be viewed as particularly notorious here - it will even accept HLSL syntax and keywords, meaning that if you're not careful you can end up producing shaders that will only work on NVIDIA and nothing else. It is a jungle out there.

  • 1
    \$\begingroup\$ To be fair, NVIDIA's GLSL compiler has gotten rather more strict about what it does and does not accept since those days. But even today, there are what I call "NVIDIA traps" that make it easy to do something that you think should work, but don't according to the actual spec and AMD drivers. \$\endgroup\$ Sep 22, 2011 at 1:08
  • \$\begingroup\$ I'd even go so far as to say that developing on ATI/AMD, or at the very least cross-checking with ATI/AMD on a regular basis, is still an absolute must. You get two kills for the price of one there as you'll also catch bugs in their OpenGL driver too. \$\endgroup\$ Sep 22, 2011 at 20:51
  • \$\begingroup\$ When targeting Vulkan, or OpenGL implementations supporting SPIR-V, GLSL shaders can be pre-compiled to SPIR-V. \$\endgroup\$
    – Andrea
    May 14, 2019 at 11:24
  • \$\begingroup\$ @Andrea - yes, that's correct; obviously neither Vulkan nor SPIR-V existed at the time the question was asked (and the asnwer was written). \$\endgroup\$ May 14, 2019 at 17:52

I have been using both, I started with glsl and moved to hlsl only because the project demands it. Given the choice, it's glsl all the way. glsl feels very slick and hlsl feels like it came out off an engineer's hobby bench.


You might want to look into the RTSS (Run Time Shader System) that comes with Ogre as well. It is fairly new, but you basically write shaders in code rather than external files. I have not implemented it yet, but definitely plan to use this when the time comes.

Here is a huge series of tutorials on the Ogre wiki as well for writing shaders. http://www.ogre3d.org/tikiwiki/JaJDoo+Shader+Guide

As for your original question, like Praetor said, its not really a matter of pros/cons, it is a matter of what rendering system you want are going to use. Since using DX/OpenGL with Ogre is just a matter of loading the plugin, you will most likely want to use .cg format.


Not the answer you're looking for? Browse other questions tagged .