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

Tom Stellard tstellar at gmail.com
Wed May 18 20:30:06 PDT 2011


On Wed, May 18, 2011 at 12:23:40PM -0700, Eric Anholt wrote:
> On Wed, 18 May 2011 09:00:09 +0200, Ian Romanick <idr at freedesktop.org> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 05/18/2011 05:22 AM, Eric Anholt wrote:
> > > 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
> > > branch.
> > > 
> > > 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
> > 
> > This is one of those ideas that seems so obvious after you hear about it
> > that you can't believe you hadn't thought of it years ago.  This seems
> > like something we'd want in piglit, but I'm not sure how that would look.
> 
> Incidentally, Tom Stellard has apparently been doing this across piglit
> already.  This makes me think that maybe I want to just roll the
> captured open-source shaders into glslparsertest, and just use the
> analysis stuff on piglit.
>

I use this piglit patch to help capture shader stats:
http://lists.freedesktop.org/archives/piglit/2010-December/000189.html

It redirects any line of output that begins with ~ to a stats file. Then
I use sdiff to compare stats files from different piglit runs.

The output looks like this:

shaders/glsl-orangebook-ch06-bump
~~~~~~~~ FRAGMENT PROGRAM ~~~~~~~
~  25 Instructions
~  25 Vector Instructions (RGB)
~   4 Scalar Instructions (Alpha)
~   0 Flow Control Instructions
~   0 Texture Instructions
~   2 Presub Operations
~   6 Temporary Registers
~~~~~~~~~~~~~~ END ~~~~~~~~~~~~~~

This patch is probably a little overkill, though, because as Marek
pointed out, the same thing could be accomplished by grep'ing the raw
output from piglit.  This has been useful for testing compiler
optimizations, but it would be much better if there were some real world
shaders in piglit.

Also, the glslparsertest hack isn't working on r300g, because shaders
don't get compiled in the r300 backend until the first time they are used.
It's done this way so the driver can emulate things like shadow samplers
in the shader.  I'm not sure what the best solution is for this.  Maybe
we could add an environment variable to force compilation at link time.

-Tom




More information about the mesa-dev mailing list