[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