<p>The shader language is bound to the APIs/engines that support it (glsl to openGL &amp; WebGL and hlsl to D3D). There are tools to translate from one to the other but they aren't perfect.</p>

<p>This means the main reason to pick one over the other is which platform you will be working on.</p>

<p>However by the end of the year a new binary shader representation will come out called Spir-V designed for Vulkan and an OpenGL extension for it is expected to follow shortly. This will allow you to write shaders in many languages as long as a translation tool to Spir-V exists (several are in the works including a Python and Haskell tool).</p>

CC BY-SA 3.0
2015-08-20T11:07:42.403Z
You were like a few seconds faster than I and even have information about Spir-V, which I did not even know.
Nero
CC BY-SA 3.0
2015-08-20T11:02:54.187Z
2015-08-20T11:02:54.187Z
ratchet freak
<p>The HLSL shader language is used in DirectX family APIs and GLSL for the OpenGL family APIs. This means that the choice of graphics API will limit the shader language as well, so if cross platform is a concern then GLSL will be the choice. However, this comes with some caveats as well.</p>

<p>One difference is that in OpenGL the shading language is compiled on driver level, this means that the binary representation is not stable and can change with driver updates. In HLSL it is compiled to a hardware independent representation that can be used on multiple GPUs. This should really be a problem for writing shaders, but it sometimes means that certain things work different with other drivers and especially operating systems.</p>

<p>Another thing to take note is that OpenGL features extensions, these can be enabled inside GLSL to utilize extra functionality. With newer OpenGL versions some of these extensions might be added to the core profile. Vendors then have to implement these extensions to be compliant, which sometimes results in things working different. The HLSL shading language syntax only changes with new introduction of DirectX APIs.</p>

<p>Some syntactic differences are that HLSL can use #include, in GLSL this is not default. When searching for GLSL tutorials you might find different syntax, because it has changed quite a lot as of OpenGL 3 and 4. GLSL shaders have a void main() as shader entry point. In HLSL this entry point can be named and have input (vertex data) and output (pixel shader input).</p>

<p>Learning either of these will introduce you to some common ground which will make it easy to learn to other one. HLSL is more standardized, but it also only works on a single operating system. There are also other attempts of shader languages that compile to both OpenGL and DirectX, one example is <a href="https://developer.nvidia.com/cg-toolkit" rel="nofollow">Cg</a> which is deprecated by now. Many game engines (Unity, Unreal Engine) also have their own flavors, but their syntax is like HLSL or GLSL.</p>

<p>As already mentioned Vulkan will introduce an open intermediate language representation called Spir-V. This means that if a language can be compiled to this representation it can be used to write shaders.</p>

CC BY-SA 3.0
2015-08-20T17:41:34.143Z
GLSL functions cannot return a value? Hum? From where did you get this idea?
glampert
CC BY-SA 3.0
2015-08-20T18:14:37.627Z
I always used to the value-return calling convention as described here https://www.opengl.org/wiki/Core_Language_%28GLSL%29#Functions. If it is possible to define the return type and use "return variable;" syntax I will change it. EDIT: nvm, you're right. The OpenGL 4.5 specification says it should be possible (but I don't know when it was introduced)
Maurice
CC BY-SA 3.0
2015-08-20T18:26:30.610Z
Return values have always been supported, AFAIK. If you look at the [1.2 specification, section 6.1](https://www.opengl.org/registry/doc/GLSLangSpec.Full.1.20.8.pdf), you can see the function declaration syntax: `returnType functionName (type0 arg0, type1 arg1, ..., typen argn);`. Plus, a lot of builtin functions return a value... Perhaps the existence of `in/out` parameters has tricked you into thinking it didn't support return values, but both are orthogonal concepts. Apart from that, your answer is pretty good, btw ;)
glampert
CC BY-SA 3.0
2015-08-20T18:42:21.180Z
Yeah, I probably just looked at the wiki instead of the specification itself. Never occurred to me that both methods are possible, although indeed the buildin functions do use it.
Maurice
CC BY-SA 3.0
2015-08-20T15:55:56.167Z
2015-08-20T18:34:36.977Z
2015-08-20T18:34:36.977Z
Maurice
<p>I don't know any shader languages. I've heard of GLSL and HLSL, and I'm interested in learning one or both.</p>

<p>Are there significant differences between them that would make one or other better in certain situations? Is it useful to know both or would either cover most needs?</p>

<p>I don't want vague answers indicating personal preference. I'm looking for specific measurable differences so that I can decide for myself which will suit me best. I don't have a specific task in mind - I'm hoping to discover whether there is one or other that I can learn and then apply to any future tasks, rather than having to learn a new language for each new task.</p>

<p>If there are other shader languages which I have not mentioned I would be interested to hear the comparison for those too, provided they are not dependent on any particular GPU manufacturer. I want my code to be portable across different graphics cards.</p>

<gpu><glsl><shader><hlsl>
What factors affect which shader language to learn?
trichoplax is on Codidact now
# What factors affect which shader language to learn?

(Asked by: username_0 on 2015-08-20)

I don't know any shader languages. I've heard of GLSL and HLSL, and I'm interested in learning one or both.

Are there significant differences between them that would make one or other better in certain situations? Is it useful to know both or would either cover most needs?

I don't want vague answers indicating personal preference. I'm looking for specific measurable differences so that I can decide for myself which will suit me best. I don't have a specific task in mind - I'm hoping to discover whether there is one or other that I can learn and then apply to any future tasks, rather than having to learn a new language for each new task.

If there are other shader languages which I have not mentioned I would be interested to hear the comparison for those too, provided they are not dependent on any particular GPU manufacturer. I want my code to be portable across different graphics cards.

**Tags:** gpu, glsl, shader, hlsl


---

## 2 answers

### Answer by username_1 on 2015-08-20. Score: 7

The shader language is bound to the APIs/engines that support it (glsl to openGL & WebGL and hlsl to D3D). There are tools to translate from one to the other but they aren't perfect.

This means the main reason to pick one over the other is which platform you will be working on.

However by the end of the year a new binary shader representation will come out called Spir-V designed for Vulkan and an OpenGL extension for it is expected to follow shortly. This will allow you to write shaders in many languages as long as a translation tool to Spir-V exists (several are in the works including a Python and Haskell tool).

> **Comments:**
> **username_2**: You were like a few seconds faster than I and even have information about Spir-V, which I did not even know.  

---

### Answer by username_3 on 2015-08-20. Score: 4

The HLSL shader language is used in DirectX family APIs and GLSL for the OpenGL family APIs. This means that the choice of graphics API will limit the shader language as well, so if cross platform is a concern then GLSL will be the choice. However, this comes with some caveats as well.

One difference is that in OpenGL the shading language is compiled on driver level, this means that the binary representation is not stable and can change with driver updates. In HLSL it is compiled to a hardware independent representation that can be used on multiple GPUs. This should really be a problem for writing shaders, but it sometimes means that certain things work different with other drivers and especially operating systems.

Another thing to take note is that OpenGL features extensions, these can be enabled inside GLSL to utilize extra functionality. With newer OpenGL versions some of these extensions might be added to the core profile. Vendors then have to implement these extensions to be compliant, which sometimes results in things working different. The HLSL shading language syntax only changes with new introduction of DirectX APIs.

Some syntactic differences are that HLSL can use #include, in GLSL this is not default. When searching for GLSL tutorials you might find different syntax, because it has changed quite a lot as of OpenGL 3 and 4. GLSL shaders have a void main() as shader entry point. In HLSL this entry point can be named and have input (vertex data) and output (pixel shader input).

Learning either of these will introduce you to some common ground which will make it easy to learn to other one. HLSL is more standardized, but it also only works on a single operating system. There are also other attempts of shader languages that compile to both OpenGL and DirectX, one example is [Cg](https://developer.nvidia.com/cg-toolkit) which is deprecated by now. Many game engines (Unity, Unreal Engine) also have their own flavors, but their syntax is like HLSL or GLSL.

As already mentioned Vulkan will introduce an open intermediate language representation called Spir-V. This means that if a language can be compiled to this representation it can be used to write shaders.

> **Comments:**
> **username_4**: GLSL functions cannot return a value? Hum? From where did you get this idea?  
> **username_3**: I always used to the value-return calling convention as described here https://www.opengl.org/wiki/Core_Language_%28GLSL%29#Functions. If it is possible to define the return type and use "return variable;" syntax I will change it. EDIT: nvm, you're right. The OpenGL 4.5 specification says it should be possible (but I don't know when it was introduced)  
> **username_4**: Return values have always been supported, AFAIK. If you look at the [1.2 specification, section 6.1](https://www.opengl.org/registry/doc/GLSLangSpec.Full.1.20.8.pdf), you can see the function declaration syntax: `returnType functionName (type0 arg0, type1 arg1, ..., typen argn);`. Plus, a lot of builtin functions return a value... Perhaps the existence of `in/out` parameters has tricked you into thinking it didn't support return values, but both are orthogonal concepts. Apart from that, your answer is pretty good, btw ;)  
> **username_3**: Yeah, I probably just looked at the wiki instead of the specification itself. Never occurred to me that both methods are possible, although indeed the buildin functions do use it.  

---

