[Mesa-dev] [PATCH] i965: Improve (i.e. remove) some grf-to-mrf unnecessary moves

Segovia, Benjamin benjamin.segovia at intel.com
Mon Jul 26 16:36:25 PDT 2010


Thanks for the cleanup. I rushed the code yesterday and it was not quite perfect.
________________________________________
From: Eric Anholt [eric at anholt.net]
Sent: Monday, July 26, 2010 2:12 PM
To: Segovia, Benjamin; mesa-dev at lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] i965: Improve (i.e. remove) some grf-to-mrf unnecessary moves

On Sun, 25 Jul 2010 21:30:19 -0700, Benjamin Segovia <benjamin.segovia at intel.com> wrote:
> - Several routines directly analyze the grf-to-mrf moves from the Gen binary
>   code. When it is possible, the mov is removed and the message register is
>   directly written in the arithmetic instruction
>
> - Also redundant mrf-to-grf moves are removed (frequently for example, when
>   sampling many textures with the same uv)
>
> - Code was tested with piglit, warsow and nexuiz on an Ironlake machine. No
>   regression was found there
>
> - Note that the optimizations are *deactivated* on Gen4 and Gen6 since I did
>   test them properly yet. No reason there are bugs but who knows
>
> - The optimizations are currently done in branch free programs *only*.
>   Considering branches is more complicated and there are actually two paths:
>   one for branch free programs and one for programs with branches

Yeah, the remove-repeated-mov pass at least seems like it could be
changed to a basic-block pass successfully.  Less so for the other one.

>
> - Also some other optimizations should be done during the emission itself but
>   considering that some code is shader between vertex shaders (AOS) and pixel
>   shaders (SOA) and that we may have branches or not, it is pretty hard to both
>   factorize the code and have one good set of strategies

Looks pretty good, and the generated programs sure look a lot better.
I've gone ahead and pushed it plus a few cleanups of the code.


More information about the mesa-dev mailing list