Testing different libGL implementations

I recently learned that the Intel i965 hardware is capable of handling GLSL 1.30, but nobody got around to add support for this in the DRI/mesa 3D driver. The developers at Intel are focusing on their latest hardware which means GLSL 1.30 support won’t be added soon. The core mesa supports GLSL 1.30 and later generations of the Intel hardware are supported as well. Luckily Intel provides all the necessary 3D documentation that allows anyone to implement it.

But how do we get started? First of all you need to test the driver and see where you are starting. The best way to do this is using piglit. Piglit is an awesome tool maintained by the open source mesa developers to perform reproducible tests. You can see it as a conformance suite or a regression test. So the first thing is figure out what tests from piglit can be used to check for GLSL 1.30 support. Piglit ships lots of tests for specification conformance, including tests/spec/glsl-1.30.

Piglit also ships some test profiles, including all.tests. This will execute all tests known to piglit. For our purpose it is sufficient only to run the GLSL 1.30 tests. I went ahead and commented the tests not relevant for now.

$ ./piglit-run.py tests/all.tests results/2013-02-13_base
$ export MESA_GLSL_VERSION_OVERRIDE="130"
$ ./piglit-run.py tests/all.tests results/2013-02-13_base_130
$ ./piglit-summary-html.py --overwrite out results/2013-02-13_base*

I started with the command listed above. It will run the piglit tests using your currently installed driver. The first run will be using GLSL 1.20 which is announced by the driver, the second run will use 1.30. After that you can generate a nice HTML form to show the differences. If everything went fine you will quickly see tests changing from skipped to failed or passed. These will be the tests you will need to look into.

For me the tests caused a GPU lockup somewhere in the tests. This is to be expected when overriding the GLSL version to something not supported by the driver. Only use this when you are developing the graphics driver! Piglit already wrote parts of the result file so I started to compare the incomplete differences and picked the first that failed. In my case this is varying-packing-simple float separate -auto -fbo which caused a segfault (it’s not the GPU lockup, but let’s start with an easy example). Before you start of installing debug packages for you distribution you should verify that a failure is still present in the latest git code. It is best to build mesa using the same configuration options as your distribution does (I’m not going into the details of how to get these as they vary from distribution to distribution).

Now on to the interesting part: How do you use a different version of libGL and the DRI drivers without messing with your installed drivers? It’s pretty easy once you know the trick. First of all you need to tell the linker where to look for shared objects.

$ ldd varying-packing-simple float separate
  ...
  libGL.so.1 => /usr/lib/libGL.so.1 (....)
  ...
$ export LD_LIBRARY_PATH=/home/cbrill/source/mesa/lib
$ ldd varying-packing-simple float separate
  ...
  libGL.so.1 => /home/cbrill/source/mesa/lib/libGL.so.1 (....)
  ...

Now you managed to load a different libGL.so when you are executing you tests. But be aware: libGL will dynamically load your installed hardware drivers! This might cause some crashes if the installed driver does not match the development libGL.

$ export LIBGL_DRIVERS_PATH=/home/cbrill/source/mesa/lib
$ export EGL_DRIVERS_PATH=/home/cbrill/source/mesa/lib/egl

Now you are using your a local copy of mesa to test your implementation. The benefit of user space 3D drivers is pretty huge here, because otherwise you’d have to load/unload a kernel module very often. And debugging crashes in kernel space is much more complicated than in user space.

In my case the segfaulting test no longer crashed when using mesa from git. I’m currently in the process of generating a piglit run but I get a GPU lockup and don’t see the results. A good recommendation would be to run tests from a different machine that is not affected by your test (e.g. serial console or ssh connection). To run applications on the display when connected by ssh you need to do the following on you test machine

$ xhost +

After that that you can run any command, e.g. glxgears, on that display by doing:

$ DISPLAY=:0 glxgear

That pretty much sums up everything you need to test your driver. Have fun!

Note: for a complete list of environment variables see the mesa3d documentation.

Copyright © christophbrill.de, 2002-2017.