4

GLSL is fundamentally different from other shader solutions because the server (GPU driver) is responsible for shader compilation. Cg and HLSL are (afaik) generally compiled a priori and sent to the GPU in that way.

This causes some real-world practical issues:

  • many drivers provide buggy compilers
  • compilers differ in terms of strictness (one GPU can accept a program while another won't)
  • also we can't know how the assembler code will be optimised

What are the upsides of GLSL's current approach? Is it worth it?

Kos
  • 1,424
  • 1
  • 14
  • 23

2 Answers2

3

The advantage is that it's easy to write programs that dynamically generate GLSL code, for example you can dynamically generate new shaders when the lights affecting an object changes.

The disadvantage is that the compile time can become significant and that the compilers generally do less optimization (in order to keep compile times down).

Morten
  • 54
  • 1
-1

This model pushes on code portability, decoupling the GLSL code from any specific platform (hardware and/or software). Because it is a royalty-free standard, every vendor could decide to support GLSL platform. Normally this support will result in a OS-specific OpenGL driver implementation.

many drivers provide buggy compilers

Probably there are many bugs in the drivers out there, but my experience says that the most of the times the bug is not a bug, but it is a misunderstanding of the GLSL specification. For example, this code run fine on NVIDIA platforms, while not on Intel platforms:

// We are in fragment shader

in vec2 ds_TexCoord[3];

uniform int ds_FrontMaterialAmbientTexCoord = -1;

uniform sampler2D ds_FrontMaterialAmbientTexture;

...

if (ds_FrontMaterialAmbientTexCoord >= 0) {
    fragmentMaterial.AmbientColor = texture(ds_FrontMaterialAmbientTexture, ds_TexCoord[ds_FrontMaterialAmbientTexCoord]);
}

The trick here is that the array cannot be accessed using directly an uniform variable. Indeed the code running on NVIDIA and Intel platforms is:

if (ds_FrontMaterialAmbientTexCoord >= 0) {
     int index = ds_FrontMaterialAmbientTexCoord;
    fragmentMaterial.AmbientColor = texture(ds_FrontMaterialAmbientTexture, ds_TexCoord[index]);
}

Once you got few tricks, writing portable GLSL code is just like writing C.

compilers differ in terms of strictness (one GPU can accept a program while another won't)

Use the strictest one. AMD and Intel have a strict interpretation of the GLSL specification, while NVIDIA don't: this is because the GLSL compiler is based on CG implementation, indeed being more permessive than what should be allowed.

The solution is simple: follow strctly the GLSL specification.

also we can't know how the assembler code will be optimised

If you can about optimization, write in ARB assembly (here some specification and hints). The driver will probably do the best it can for the current platform, will you do better?

Remember that the main goal is portability!

Luca
  • 294
  • 1
  • 9
  • I still believe that DirectX's approach to driver compilation (one reference compiler to a standard bytecode) would be better for portability. Like you, I once thought that GLSL compilation is the easy part of drivers, but turns out it isn't. And in the end we're stuck with implementations like the Galaxy S' which allegedly can crash when it sees a #define. That's nowhere near portability. And desktop OpenGL [isn't better](http://stackoverflow.com/q/4292063/399317). – Kos Sep 01 '12 at 16:28
  • 1
    This is questionable. – Luca Sep 01 '12 at 19:07
  • Yup, it is. DirectX drivers need to go through a complicated acceptance procedure (including a rigorous test suite), maybe OpenGL needs something like this too? Are there any decent OpenGL implementation test suites? – Kos Sep 02 '12 at 09:50
  • I think so, even if I never developed an OpenGL driver. Nobody can expose the brand without a conformance test. I know that COLLADA have a conformance test suite, released by Khronos (the board defining OpenGL and GLSL specs). But I'd like to avoid DirectX vs OpenGL debacle, don't you? :) – Luca Sep 02 '12 at 20:49
  • Yeah :), plus I'm in no position to actually participate in one. I'd call myself an OpenGL enthusiast but I feel kind of dissatisfied with the current state of affairs (and implementations), I want to get a better perspective. – Kos Sep 03 '12 at 07:41
  • "The trick here is that the array cannot be accessed using directly an uniform variable." That is a driver bug, not a "misunderstanding of the GLSL specification". *No version* of GLSL has ever declared that array indexing via a uniform is illegal, that you have to use an explicit temporary stack variable between them. – Nicol Bolas Jan 10 '16 at 14:22
  • @nicolbolas you're definitely right. Misunderstanding is a wrong word of my answer... – Luca Jan 10 '16 at 20:16