With Intel developers earlier this week expressing their plans to merge their new GLSL compiler into Mesa by the end of next month, which besides providing various shader compiler optimizations and being a better framework going forward is already set to correct 50+ bugs, we decided to try out this Mesa "GLSL2" compiler. However, as Intel explicitly stated they haven't tested this new GL Shading Language compiler that's been in development for months with any other hardware drivers (or even Gallium3D) besides their own Intel DRI driver, we decided to see how well it works with the open-source Radeon classic and Gallium3D drivers. It ended up being both good and bad.
First when testing the latest GLSL2 branch with an ATI Radeon HD 4670 graphics card using the classic Mesa driver on an Ubuntu 10.04 LTS installation, everything was initially fine with no apparent regressions with either the OpenGL performance or visual artifacts. The usual assortment of Phoronix Test Suite tests were run with World of Padman, Nexuiz, and other titles. However, once running Warsow is where there were problems using this new compiler.
Rebuilding the latest mainline Mesa 7.9-devel code confirmed that the unpleasant Warsow experience with the ATI R700 graphics card is indeed introduced by the GLSL2 branch. At least games with the ioquake3 game engine appear to be handling the new GLSL compiler fine with the classic Mesa R600/700 driver, but the Qfusion-based Warsow at least is where there are problems.
More general than the end-user driver experience, when building the GLSL2 branch of Mesa compared to the current mainline state, on an Ubuntu installation the following extra dependencies were required: flex, bison, and libtalloc-dev. Additionally, when building the latest Mesa GLSL2 branch as of the night of 2010-07-23, the build process initially stopped as swrastg_dri (the Gallium3D software rasterizer) failed to build followed by the Radeon Gallium3D target failed to build. These build failures were due to multiple undefined references, which were worked around by adding -lstdc++ to the DRI_LIB_DEPS within the Makefile of the problematic areas. The Gallium3D Radeon driver was built as next the R300g driver was tested on a notebook with an ATI Mobility Radeon X1400 (RV515) to see how Gallium3D plays with Intel's new open-source compiler.
Warsow again proved to be problematic when using the GLSL2 branch with the R300g driver. However, the textures were not nearly as off as they were when using the R600 classic driver. Textures more often than not just ended up showing as black and in other cases they were simply off-colored compared to normal. Other issue we also ran into with both setups was the VDrift racing game and Lightsmark OpenGL lighting benchmark immediately crashing when launching the respective binaries.
While there is some fallout with this GLSL2 compiler -- namely with Warsow and then aforementioned crashes -- it is not too bad and is better than we had expected, at least when using the ATI Mesa drivers. We will be testing this new GLSL compiler more as its merge to master approaches and examine how this compiler affects the different hardware and drivers. We will also be looking to see whether the Warsow problem occurs when using the Intel DRI driver.