On 11/19/2015 09:34 AM, Neil Roberts wrote:
> Jason Ekstrand <ja...@jlekstrand.net> writes:
>
>> On Nov 18, 2015 6:38 PM, "Ian Romanick" <i...@freedesktop.org> wrote:
>>>
>>> From: Ian Romanick <ian.d.roman...@intel.com>
>>>
>>> v2: Handle immediate value for MCS smarter. Rebase on changes to
>>> nir_texop_sampels_identical (missing second parameter). Suggested by
>>> Jason. This still doesn't handle the 16x MSAA case.
>
> 16x MSAA has a field in the program sampler key because it needs a new
> instruction to fetch from the texture. For 16x MSAA it just uses two of
> the registers that are returned by the MCS fetch instruction instead of
> just one. Maybe you could do something like this:
>
> if (mcs.file == BRW_IMMEDIATE_VALUE) {
> bld.MOV(dst, fs_reg(0));
> } else if ((key_tex->msaa_16 & (1 << sampler))) {
> fs_reg tmp = vgrf(glsl_type::uint_type);
> bld.OR(tmp, mcs, offset(mcs, bld, 1));
> bld.CMP(dst, tmp, src_reg(0u), BRW_CONDITIONAL_EQ);
> } else {
> bld.CMP(dst, mcs, src_reg(0u), BRW_CONDITIONAL_EQ);
> }
>
> I tested this on my SKL and it passes all of your Piglit tests. The
> optimiser quite neatly removes the second instruction and the temporary
> register in the 16x case and makes the OR directly update the flag
> registers, so it is possibly the same cost as the 8x case in practice.
I was looking at the msaa_16 flags last night after I sent out v2. I
was thinking of something along these lines. Am I correct that nothing
special is needed in the vec4 backend? It seems like mcs should know
the register size, and the CMP with 0 should just do the right thing.
I'll add your code to the FS and your S-o-b to the commit message... and
hopefully this can land soon. :)
> I can confirm that I've already pushed the 16x MSAA patches to master.
>
> Regards,
> - Neil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
