[Mesa-dev] [PATCH] i965/fs: Don't try 16-wide if 8-wide uses more than half the registers.

Eric Anholt eric at anholt.net
Tue Aug 21 22:49:32 PDT 2012


Kenneth Graunke <kenneth at whitecape.org> writes:

> 16-wide programs use roughly twice as many registers as 8-wide, and we
> don't support spilling in 16-wide.  So if an 8-wide program uses more
> than half the available GRFs, the 16-wide one almost certainly will fail
> to compile during register allocation.
>
> Not only that, but attempting to compiling such shaders is expensive:
> programs that use a lot of registers tend to be quite complex, meaning
> that we spend more time than usual generating and optimizing code.  If
> we fail at register allocation, we've failed at the last step, after
> needlessly burning through a lot of CPU time.
>
> To make things worse, such shader compilation typically happens at the
> first draw call using the shader, so it can cause the GPU to stall.
>
> With all that in mind, it makes sense to short-circuit the 16-wide
> attempt if the 8-wide program uses too many registers.  I've chosen 75
> to be conservative---if we /can/ compile a SIMD16 program, we want to.
>
> Reduces the number of GPU stalls due to fragment shader recompiles
> in Left 4 Dead 2 by about 20%, and reduces the duration of many of the
> remaining stalls by about half.

I don't like the idea of losing 16-wide on apps where it might have
succeeded if we just tried.  Note that a chunk of register space gets
eaten by things that don't scale with number of pixels, like attribute
setup, push constants, and the MRF hack.

I could be convinced otherwise with some shader-db stats, though.

However, there's that one shader that spills still, iirc, and we
definitely shouldn't try for 16-wide on that one!
-------------- 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/20120821/9e3ba9e3/attachment.pgp>


More information about the mesa-dev mailing list