Ian Romanick <i...@freedesktop.org> writes:
> 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 think you probably will have to do something for the vec4 backend.
Currently it generates an instruction like this:
cmp.z.f0(8) g8<1>.xUD g9<4,4,1>.xUD 0x00000000UD
g9 contains the MCS data. If I understand correctly for 16x MSAA the
second half of the MCS data is in the y component which is currently
ignored by this instruction. Maybe something like this would work:
if (mcs.file == BRW_IMMEDIATE_VALUE) {
emit(MOV(dest, src_reg(0u)));
} else if ((key_tex->msaa_16 & (1 << sampler))) {
dst_reg tmp(this, glsl_type::uint_type);
dst_reg swizzled_mcs = mcs;
swizzled_mcs.swizzle = BRW_SWIZZLE_YYYY;
emit(OR(tmp, mcs, swizzled_mcs));
emit(CMP(dest, tmp, src_reg(0u), BRW_CONDITIONAL_EQ));
} else {
emit(CMP(dest, mcs, src_reg(0u), BRW_CONDITIONAL_EQ));
}
Sadly the optimiser doesn't optimise out the extra instruction this
time. There's probably a better way to do it. On the other hand I can't
think why anyone would be using this function in the vec4 backend so
it's probably not worth worrying about.
I haven't tested this at all. I guess to test it you would have to write
a GS version of the Piglit test? I think that is the only place that
uses the vec4 backend on SKL.
If we don't want to risk this we could always just make it return false
when msaa_16 is set for the sampler. On the other hand if there is
currently no test for the 8x version either then we should probably
assume that neither of them work… maybe it wouldn't be so bad to just
always return false in the vec4 backend until we've tested it?
Regards,
- Neil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
