[Mesa-dev] shader-db, and justifying an i965 compiler optimization.

Eric Anholt eric at anholt.net
Tue May 17 20:22:53 PDT 2011

One of the pain points of working on compiler optimizations has been
justifying them -- sometimes I come up with something I think is
useful and spend a day or two on it, but the value doesn't show up as
fps in the application that suggested the optimization to me.  Then I
wonder if this transformation of the code is paying off in general,
and thus if I should push it.  If I don't push it, I end up bringing
that patch out on every application I look at that it could affect, to
see if now I finally have justification to get it out of a private

At a conference this week, we heard about how another team is are
using a database of (assembly) shaders, which they run through their
compiler and count resulting instructions for testing purposes.  This
sounded like a fun idea, so I threw one together.  Patch #1 is good in
general (hey, link errors, finally!), but also means that a quick hack
to glslparsertest makes it link a passing compile shader and therefore
generate assembly that gets dumped under INTEL_DEBUG=wm.  Patch #2 I
used for automatic scraping of shaders in every application I could
find on my system at the time.  The open-source ones I pushed to:


And finally, patch #3 is something I built before but couldn't really
justify until now.  However, given that it reduced fragment shader
instructions 0.3% across 831 shaders (affecting 52 of them including
yofrankie, warsow, norsetto, and gstreamer) and didn't increase
instructions anywhere, I'm a lot happier now.

Hopefully we hook up EXT_timer_query to apitrace soon so I can do more
targeted optimizations and need this less :) In the meantime, I hope
this can prove useful to others -- if you want to contribute
appropriately-licensed shaders to the database so we track those, or
if you want to make the analysis work on your hardware backend, feel

More information about the mesa-dev mailing list