[Mesa-dev] [PATCH 1/4] i965: Remove fixed-function texture projection avoidance optimization.

Kenneth Graunke kenneth at whitecape.org
Wed Apr 3 22:34:16 PDT 2013


On 03/13/2013 09:17 AM, Eric Anholt wrote:
> Kenneth Graunke <kenneth at whitecape.org> writes:
>
>> This optimization attempts to avoid extra attribute interpolation
>> instructions for texture coordinates where the W-component is 1.0.
>>
>> Unfortunately, it requires a lot of complexity: the brw_wm_input_sizes
>> state atom (all the brw_vs_constval.c code) needs to run on each draw.
>> It computes the input_size_masks array, then uses that to compute
>> proj_attrib_mask.  Differences in proj_attrib_mask can cause
>> state-dependent fragment shader recompiles.  We also often fail to guess
>> proj_attrib_mask for the fragment shader precompile, causing us to
>> needlessly compile it twice.
>>
>> Furthermore, this optimization only applies to fixed-function programs;
>> it does not help modern GLSL-based programs at all.  Generally, older
>> fixed-function programs run fine on modern hardware anyway.
>>
>> The optimization has existed in some form since the initial commit.  When
>> we rewrote the fragment shader backend, we dropped it for a while.  Eric
>> readded it in commit eb30820f268608cf451da32de69723036dddbc62 as part of
>> an attempt to cure a ~1% performance regression caused by converting the
>> fixed-function fragment shader generation code from Mesa IR to GLSL IR.
>> However, no performance data was included in the commit message, so it's
>> unclear whether or not it was successful.
>>
>> Time has passed, so I decided to re-measure this.  Surprisingly,
>> Eric's OpenArena timedemo actually runs /faster/ after removing this and
>> the brw_wm_input_sizes atom.  On Ivybridge at 1024x768, I measured a
>> 1.39532% +/- 0.91833% increase in FPS (n = 55).
>
> Removing it on SNB+ makes sense to me.  But given the higher cost of
> math pre-gen6, I think we should test on one of those too.

I finally rebased this patch series ("proj_attrib" in my tree).  On 
Ironlake, OpenArena at 1024x768 (n = 37) shows no statistically 
significant difference.

So, can we just scrap it altogether?


More information about the mesa-dev mailing list