[Mesa-dev] [RFC] GL fixed function fragment shaders

Eric Anholt eric at anholt.net
Mon Jan 17 13:40:12 PST 2011


On Thu, 13 Jan 2011 17:40:39 +0100, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 12.01.2011 23:04, schrieb Eric Anholt:
> > This is a work-in-progress patch series to switch texenvprogram.c from
> > generating ARB_fp style Mesa IR to generating GLSL IR as its product.
> > For drivers without native GLSL codegen, that is then turned into the
> > Mesa IR that can be consumed.  However, for 965 we don't use the Mesa
> > IR product and just use the GLSL output, producing much better code
> > thanks to the new backend.  This is part of a long term goal to get
> > Mesa drivers off of Mesa IR and producing their instruction stream
> > directly from the GLSL IR.
> > 
> > I'm not planning on committing this series immediately, as I've still
> > got a regression in the 965 driver with texrect-many on the last
> > commit.
> > 
> > As a comparison, here's one of the shaders from openarena before:
> 
> So what's the code looking like after conversion to mesa IR? As long
> as

Two shaders out of openarena.  Before:
# Fragment Program/Shader 0
  0: TXP TEMP[0], INPUT[4], texture[0], 2D;
  1: MUL OUTPUT[2].xyz, TEMP[0], INPUT[1];
  2: MOV OUTPUT[2].w, INPUT[1];
  3: END

After:
  0: TXP TEMP[2].xyz, INPUT[4].xyyw, texture[0], 2D;
  1: MUL TEMP[4].xyz, TEMP[2].xyzx, INPUT[1].xyzx;
  2: MOV TEMP[4].w, INPUT[1].wwww;
  3: MOV OUTPUT[2], TEMP[4];
  4: END

Before:
  0: TXP TEMP[0], INPUT[4], texture[0], 2D;
  1: TXP TEMP[1], INPUT[5], texture[1], 2D;
  2: MUL TEMP[2].xyz, TEMP[0], INPUT[1];
  3: MOV TEMP[2].w, INPUT[1];
  4: ADD_SAT OUTPUT[2].xyz, TEMP[1], TEMP[2];
  5: MOV OUTPUT[2].w, TEMP[2];
  6: END

After:
  0: TXP TEMP[0], INPUT[4].xyyw, texture[1], 2D;
  1: MUL TEMP[1].xyz, TEMP[0].xyzx, INPUT[1].xyzx;
  2: TXP TEMP[0], INPUT[5].xyyw, texture[0], 2D;
  3: ADD TEMP[2].xyz, TEMP[0], TEMP[1];
  4: MOV_SAT TEMP[0].xyz, TEMP[2].xyzx;
  5: MOV TEMP[0].w, INPUT[1].wwww;
  6: MOV OUTPUT[2], TEMP[0];
  7: END

So, there's one extra Mesa IR move added where we could compute into the
destination reg but don't.  This is a general problem with
ir_to_mesa.cpp that affects GLSL pretty badly.

Of course, talking about optimality of Mesa IR is kind of a joke, as for
the drivers that directly consume it (i915, 965 VS, r200, and I'm
discounting r300+ as they have their own IR that Mesa IR gets translated
to and actually optimized), we miss huge opportunities to reduce
instruction count due to swizzle sources including -1, 0, 1 as options
but Mesa IR not taking advantage of it.  If we were doing that right,
then the other MOV-reduction pass would hit and that extra move just
added here would go away, resulting in a net win.

Similarly, we add an extra indirection phase according to 915's
accounting of those on the second shader, but the fact that we don't
schedule those in our GLSL output anyway is a big issue for GLSL on
hardware with indirection limits.

> it's not worse than the original I guess this should be ok, though for
> those drivers consuming mesa IR I guess it's just more cpu time without
> any real benefit?

Assuming that the setup the app did was already optimal for a
programmable GPU, yes.  But I suspect that isn't generally the case --
while OA has reasonable looking fixed function setup (other than Mesa IR
we produce not using the swizzles), given how painful it is to program
using texenv I suspect there are a lot of "suboptimal" shader setups out
there that we could actually improve.

> For gallium we should probably address this some way
> or another, it seems quite backward to do ff->glsl->mesa ir->tgsi.

I'm surprised you guys haven't forked off ir_to_mesa.cpp to something
that produces TGSI, since you seem to prefer it as the thing for drivers
to consume over GLSL IR.  At least with sized variables, you could then
adapt the Mesa IR optimization passes on TGSI so that they wouldn't all
be disabled whenever relative addressing occurred.  I'm only interested
in Mesa IR for hardware that doesn't have relative addressing of temps,
so it's not really an issue to me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110117/cc799714/attachment.pgp>


More information about the mesa-dev mailing list