[Mesa-dev] [PATCH 06/12] i965/fs: Add a sampler program key for whether the texture is 16x MSAA

Ben Widawsky ben at bwidawsk.net
Wed Sep 23 10:52:45 PDT 2015


On Wed, Sep 23, 2015 at 06:08:33PM +0100, Neil Roberts wrote:
> Ben Widawsky <ben at bwidawsk.net> writes:
> 
> > On Thu, Sep 17, 2015 at 05:00:08PM +0100, Neil Roberts wrote:
> >> When 16x MSAA is used for sampling with texelFetch the compiler needs
> >> to use a different instruction which passes more arguments for the MCS
> >> data. Previously on skl+ it was unconditionally using this new
> >> instruction. However since 16x MSAA is probably going to be pretty
> >> rare, it is probably worthwhile to avoid using this instruction for
> >> the other sample counts. In order to do that this patch adds a new
> >> member to brw_sampler_prog_key_data to track when a sampler refers to
> >> a buffer with 16 samples.
> >> 
> >> Note that this isn't done for the vec4 backend because it wouldn't
> >> change how many registers it uses.
> >
> > Hmm. I was of the other opinion actually, I'd prefer to always use the
> > new instruction to limit the variability between tests. I suppose if
> > we're often passing the LOD parameter that is problematic, but we
> > don't do that either, right?
> 
> Using the ld2dms_w instruction on SIMD8 or SIMD16 requires sending one
> extra parameter to the sampler regardless of whether the LOD is sent.

Hmm. As I read it, it sounded like you didn't have to send LOD it's implied to
be 0 if you don't send it. If I am wrong about that, then I agree with you
completely.

> This requires at least one extra instruction to fill it in. Also, if the
> r parameter is sent then on SIMD16 the message length will flow over the
> maximum of 11 registers and the send message will have to be split into
> two with an exec size of 8. I think this is quite a big overheard so I'm
> strongly in favour of avoiding this where possible seeing as 16x MSAA is
> probably going to be quite rare. All of the piglit tests dealing with
> MSAA seem to test the whole range of sample counts so I don't think
> there's too much worry of this code path not getting tested.
> 
> Shader db reports this:
> 
> total instructions in shared programs: 7651410 -> 7651318 (-0.00%)
> instructions in affected programs:     4906 -> 4814 (-1.88%)
> helped:                                52
> HURT:                                  0
> GAINED:                                0
> LOST:                                  0
> 
> Regards,
> - Neil


More information about the mesa-dev mailing list