Im working on a multiplatform (Pc,Mac,Linux) game that uses shaders quite extensively. Since we do not have any funding, it is pretty hard to test our game on all possible hardware configurations.

While our engine seems to run fine on different platforms, its usually the slight differences in GLSL compiling that gives us headaches. We have things set up such that we can test the shaders on Ati/Nvidia cards, but since the new Macbooks have Intel graphics, I'm really looking for a tool that can simply validate my GLSL shaders for different hardware without the need of yet another system.

Does anyone know such a tool?

  • 9
    \$\begingroup\$ In the past, I've done quick performance testing by going into an Apple store and just downloading my programs onto various computers which are out on display. Not as useful as having a proper tool, but at least it lets me avoid splashing out for a new laptop every time I want to check on some new platform. \$\endgroup\$ Sep 5 '11 at 22:15
  • 5
    \$\begingroup\$ @Trevor Powell I instantly got the image of the geek Indie game developper in the Apple Store secretly testing his games until someone threw him out lol. \$\endgroup\$
    – anthonyvd
    Sep 6 '11 at 4:21

The GLSL specification defines how the language works. If you write a shader that conforms to that specification, and it does not work on a particular OpenGL implementation, then that OpenGL implementation has a bug in it. Which means that you are effectively asking for a tool that can reproduce the bugs in Apple's Intel drivers.

That is pretty much impossible. To do that, someone would have to have a list of every bug for every driver revision in Apple's Intel graphics drivers. Even if someone tried to get a list of those bugs and wrote a parser that reproduced them, that wouldn't guarantee you anything, since there could always be new bugs introduced. Or the "validator" could have implemented those bugs incorrectly.

The best you can hope for would be a shader validator that could tell if your GLSL shader conformed to the specification. But that's about it.

  • 2
    \$\begingroup\$ Or most likely, the validator itself would have slightly different bugs. \$\endgroup\$
    – user744
    Sep 5 '11 at 23:51
  • \$\begingroup\$ Do you know of a validator that is very strict regarding the specifications? \$\endgroup\$
    – Pjotterke
    Sep 6 '11 at 7:26
  • \$\begingroup\$ @Pjotterke: 3D Labs used to have one, but they went under years ago. I'm not aware of any compiler that is particularly less error prone than any other. \$\endgroup\$ Sep 6 '11 at 7:28
  • \$\begingroup\$ Luckily, drawelements (drawelements.com) has a plan to force opengl es drivers towards compliance =) \$\endgroup\$ Sep 7 '11 at 8:50
  • \$\begingroup\$ @Jari: That's great for OpenGL ES. But that does nothing for those on desktops. \$\endgroup\$ Sep 7 '11 at 9:16

Khronos provides a reference GLSL compiler.

It is capable of validating GLSL up to version 3.50 (full support) and up to 4.50 (partial support). It also handles ESSL (OpenGL ES's GLSL).

The tool verifies that the shader conforms to the GLSL specification. This does not necessarily guarantee that it works with all drivers but it does guarantee that the shader will work with any compliant driver. This is a much stricter guarantee than merely checking the shader against a specific driver.

The tool does not validate that the results of the GLSL are what you expect. In particular, there are perfectly valid GLSL sequences that have weakly specified behavior. That can result in a perfectly valid shader having quite different output on different fully-conforming implementations.

A buggy driver may reject or miscompile compliant GLSL. There's no proof against that but - thankfully - it's increasingly rare as Khronos' conformance test suite has become more complete.

The standalone Khronos reference GLSL compiler is easy enough to integrate into a build system to validate stand-alone GLSL files. More intricate systems that load GLSL out of specialized container format or stitch GLSL together from other sources can use the library interface to validate things.


This might be bit far fetched but how about adding a screenshot feature to your game. The game would run with a script controlling game play so it follows predefined path and takes screenshots at critical points. After script is completed it sends them to you with specs of the machine.

Then just crowdsource the whole exercise.

  • \$\begingroup\$ This is the kind of far fetched I like. \$\endgroup\$ Sep 6 '11 at 11:38
  • \$\begingroup\$ That is pretty cool but debugging from a screenshot really is a nightmare. Especially since the game probably wont run or the screen turns black, etc \$\endgroup\$
    – Pjotterke
    Sep 6 '11 at 13:50
  • \$\begingroup\$ I imagine it could be used to find out setups that are totally unplayable and those that are only slightly off. Then pick the ones worth of fixing - the 80-20 rule applies here as well I guess. \$\endgroup\$
    – Petteri H
    Sep 6 '11 at 14:09
  • \$\begingroup\$ That is far fetched for a shader validator, but it is widely used in regression testing on nightly builds in actual production games. If you want to pinpoint the moment things all went to hell, it is invaluable... people writing code rarely know what the artist intended so can miss little things they break. \$\endgroup\$ Nov 28 '14 at 3:02

Write your own botnet.

I faced the same problem of not being able to test if shaders even compiled and linked on GLSL implementations and it drove me to a crude solution.

I made small tools that ran in the background on a machine, waiting for JSON bundles with shaders sources to compile and link together using a windowless OpenGL context, returning the results and logs over the network.

Deploy those to people who trust you, and submit requests either directly to the nodes or via a command-and-control server, preferably with some sort of auth, as it's a huge security hole to compile arbitrary shader code, not to mention malicious shader code.

It's of course possible to extend the tool to render to texture to get some actual validation of shader effects back too, but that's far along my roadmap and just seeing if your shaders compile at all on different context versions, profiles and driver versions is worth a lot.

  • 1
    \$\begingroup\$ Do make sure that the people running your "botnet" software have explicitly agreed to send information back to you, otherwise you'll almost certainly have a lawsuit on your hands. \$\endgroup\$
    – Dan
    Jan 1 '17 at 21:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.