[Mesa-dev] Mesa (master): i965/fs: Convert gen7 to using GRFs for texture messages.

Chia-I Wu olvaffe at gmail.com
Mon Oct 14 06:32:14 CEST 2013


On Sat, Oct 12, 2013 at 3:18 AM, Eric Anholt <eric at anholt.net> wrote:
> Chia-I Wu <olvaffe at gmail.com> writes:
>
>> Hi Eric,
>> The frame rate of Unigine Tropics (with low shader quality) dropped
>> from 40.8 to 23.5 after this change.
>
> Thanks for the note.  I see the regression as well, and I see a shader
> that's started spilling.  It looks like we can drop the regs_written <=
> 1 check on gen7+'s pre-regalloc scheduling to fix the problem (the MRF
> setup thing is no longer an issue, and its presence is now making us
> pessimize instead of optimize in general in the pre-regalloc
> scheduling).  I'll want to run a few more tests to make sure that this
> doesn't regress something else.
>
> This shader is also in bad shape now that we don't have the redundant
> MRF move optimization, and we need to look into grf_size > 1 CSE.  That
> would probably also have avoided the problem on this shader, though the
> scheduling problem is more general than this one shader.
The last shader_time output[1] for the fragment shader in question gives

BEFORE fs8   glsl   465:    959.12 Gcycles       1.1%
AFTER  fs8   glsl   465:  13336.14 Gcycles       9.6%

Comparing with the total cycles, those extra cycles should bring down
the fps to ~35.  What's odd is this shader

BEFORE vs    glsl   264:  16127.47 Gcycles      17.7%
AFTER  vs    glsl   264:  56543.36 Gcycles      40.8%

The generated code for this vertex shader is not affected by the
commit.  But it runs significantly slower, bringing the fps down to
~24.  I suspect it is context-switched away frequently and for a good
while, but I do not have a theory as to why.  Do you have a better
idea?

[1]  Formatted for this mail.  Also, the demo is time-based.  To make
sure the same frames are rendered, I have to use apitrace.

-- 
olv at LunarG.com


More information about the mesa-dev mailing list