<p>I think it is fair to say that the reason there are so many niche variations of GLSL/HLSL/Cg/whatnot is because no programming language is nor will ever be a one size fits all tool. Different problems require different tools, so sometimes it is worth the effort of developing a custom built tool if it is going to pay off in the long run.</p>

<p>Stock GLSL is by itself pretty much unusable. It hasn't even acquired much stability across versions, so for a program that targets more than one OpenGL version, some sort of preprocessing is a must. HLSL is a bit more stable across versions, but again, if targeting more than one D3D version, some work will need to done to get good portability.</p>

<p>The kinds of things people usually do are pretty much what you said, like a adding support for basic programming features such as modules and uniform syntax across versions, or even portability across different APIs (GL/D3D) without having to rewrite the shader code. More sophisticated things include fully fledged material systems or things like <a href="http://gameangst.com/?p=441" rel="nofollow">generating shader programs on-the-fly</a>.</p>

<p>Shading languages will probably get better and more generic in the future, incorporating things that today are commonly hand-rolled as core features. The new <a href="https://en.wikipedia.org/wiki/Graphics_Core_Next" rel="nofollow">GCN architecture</a> is a sign of that. So shading languages will be more usable out-of-the-box a while from now, but custom built solutions will never go away because there's only so much you can generalize.</p>

CC BY-SA 3.0
2015-12-15T01:22:18.650Z
I'm curious - what languages like this are out there? I know there are engine-specific ones like Unity's or UE4's shader systems, plus some academic researchy things like [Spark](https://graphics.stanford.edu/papers/spark/), but I'm not aware of anything else in current use in this space.
Nathan Reed
CC BY-SA 3.0
2015-12-15T02:42:46.927Z
@NathanReed, probably Apple's [Metal](https://developer.apple.com/library/ios/documentation/Metal/Reference/MetalShadingLanguageGuide/Introduction/Introduction.html) is one of the most notable, as of now, but I haven't looked into much detail...
glampert
CC BY-SA 3.0
2015-12-15T04:42:36.130Z
Oh, OK. Metal isn't on top of HLSL or GLSL though; it's a primary shading language for Apple GPUs that compiles directly to HW microcode (via a proprietary LLVM backend I believe).
Nathan Reed
CC BY-SA 3.0
2015-12-10T03:11:35.820Z
2015-12-10T03:11:35.820Z
glampert
<p>Whew, that was a long title.</p>

<p>Either way, I'm asking this question, since I like to think about various things, and it occurred to me that there isn't really any simple, open source layers on top of GLSL, even if only to add simple things such as includes, or commonly used functions.</p>

<p>As research of sorts, I'm asking this question, since my own awareness of such languages is minuscule to say the least - I know of bgfx's shading language, and Unity's ShaderLab, but I don't really know what they accomplish - or why - being a relative newbie to computer graphics.</p>

<p>Alternatively, what would your wishlist for a shading language like this be? Mine so far is includes, some compatibility between versions, optional "hidden" inputs that allow easily accessing textures at pixel offsets, or image sizes, etc. and probably passes - for, say, two-pass gaussian blur.</p>

<p>Thoughts?</p>

CC BY-SA 3.0
2015-12-08T15:09:24.190Z
This sounds more like a forum discussion than a specific question. This site works best with questions that can be answered with a single, factual answer. The "what is your wishlist" part is definitely not suitable for an SE site.
Dan Hulme
CC BY-SA 3.0
2015-12-08T18:45:12.097Z
You can come to [the cornell box](http://chat.stackexchange.com/rooms/26589/the-cornell-box) our chatroom and fire up a discussion
ratchet freak
<shader>
There are many shading languages built on top of GLSL or HLSL - what problems do they typically solve, and what worthwhile advancements do they make?
Llamageddon
# There are many shading languages built on top of GLSL or HLSL - what problems do they typically solve, and what worthwhile advancements do they make?

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

Whew, that was a long title.

Either way, I'm asking this question, since I like to think about various things, and it occurred to me that there isn't really any simple, open source layers on top of GLSL, even if only to add simple things such as includes, or commonly used functions.

As research of sorts, I'm asking this question, since my own awareness of such languages is minuscule to say the least - I know of bgfx's shading language, and Unity's ShaderLab, but I don't really know what they accomplish - or why - being a relative newbie to computer graphics.

Alternatively, what would your wishlist for a shading language like this be? Mine so far is includes, some compatibility between versions, optional "hidden" inputs that allow easily accessing textures at pixel offsets, or image sizes, etc. and probably passes - for, say, two-pass gaussian blur.

Thoughts?

**Tags:** shader

> **Comments:**
> **username_1**: This sounds more like a forum discussion than a specific question. This site works best with questions that can be answered with a single, factual answer. The "what is your wishlist" part is definitely not suitable for an SE site.  
> **username_2**: You can come to [the cornell box](http://chat.stackexchange.com/rooms/26589/the-cornell-box) our chatroom and fire up a discussion  

---

## 1 answers

### Answer by username_3 on 2015-12-10. Score: 2

I think it is fair to say that the reason there are so many niche variations of GLSL/HLSL/Cg/whatnot is because no programming language is nor will ever be a one size fits all tool. Different problems require different tools, so sometimes it is worth the effort of developing a custom built tool if it is going to pay off in the long run.

Stock GLSL is by itself pretty much unusable. It hasn't even acquired much stability across versions, so for a program that targets more than one OpenGL version, some sort of preprocessing is a must. HLSL is a bit more stable across versions, but again, if targeting more than one D3D version, some work will need to done to get good portability.

The kinds of things people usually do are pretty much what you said, like a adding support for basic programming features such as modules and uniform syntax across versions, or even portability across different APIs (GL/D3D) without having to rewrite the shader code. More sophisticated things include fully fledged material systems or things like [generating shader programs on-the-fly](http://gameangst.com/?p=441).

Shading languages will probably get better and more generic in the future, incorporating things that today are commonly hand-rolled as core features. The new [GCN architecture](https://en.wikipedia.org/wiki/Graphics_Core_Next) is a sign of that. So shading languages will be more usable out-of-the-box a while from now, but custom built solutions will never go away because there's only so much you can generalize.

> **Comments:**
> **username_4**: I'm curious - what languages like this are out there? I know there are engine-specific ones like Unity's or UE4's shader systems, plus some academic researchy things like [Spark](https://graphics.stanford.edu/papers/spark/), but I'm not aware of anything else in current use in this space.  
> **username_3**: @username_4, probably Apple's [Metal](https://developer.apple.com/library/ios/documentation/Metal/Reference/MetalShadingLanguageGuide/Introduction/Introduction.html) is one of the most notable, as of now, but I haven't looked into much detail...  
> **username_4**: Oh, OK. Metal isn't on top of HLSL or GLSL though; it's a primary shading language for Apple GPUs that compiles directly to HW microcode (via a proprietary LLVM backend I believe).  

---

