5
\$\begingroup\$

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?

\$\endgroup\$
2
  • 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\$ Commented Sep 5, 2011 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
    Commented Sep 6, 2011 at 4:21

4 Answers 4

7
\$\begingroup\$

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.

\$\endgroup\$
6
  • 2
    \$\begingroup\$ Or most likely, the validator itself would have slightly different bugs. \$\endgroup\$
    – user744
    Commented Sep 5, 2011 at 23:51
  • \$\begingroup\$ Do you know of a validator that is very strict regarding the specifications? \$\endgroup\$
    – Pjotterke
    Commented Sep 6, 2011 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\$ Commented Sep 6, 2011 at 7:28
  • \$\begingroup\$ Luckily, drawelements (drawelements.com) has a plan to force opengl es drivers towards compliance =) \$\endgroup\$ Commented Sep 7, 2011 at 8:50
  • \$\begingroup\$ @Jari: That's great for OpenGL ES. But that does nothing for those on desktops. \$\endgroup\$ Commented Sep 7, 2011 at 9:16
11
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ This is the kind of far fetched I like. \$\endgroup\$ Commented Sep 6, 2011 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
    Commented Sep 6, 2011 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
    Commented Sep 6, 2011 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\$ Commented Nov 28, 2014 at 3:02
0
\$\begingroup\$

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.

\$\endgroup\$
1
  • 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
    Commented Jan 1, 2017 at 21:40

You must log in to answer this question.

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