Ben Widawsky <b...@bwidawsk.net> writes:
>> + /* On Gen9+ we'll use lcd2ms_w instead which has two registers for
>> + * the MCS data.
>> + */
>> + if (op == SHADER_OPCODE_TXF_CMS_W) {
>> + bld.MOV(retype(sources[length], BRW_REGISTER_TYPE_UD),
>> + mcs.file == IMM ?
>> + mcs :
>> + offset(mcs, bld, 1));
>> + length++;
>> + }
>
> This hunk is very confusing to me without more context from later patches. I
> assume the upper bits of mcs are 0 for the cases where you're doing < 16x, but
> there is no way to determine that.
Well, the documentation says that the upper bits of MCS are ignored when
the sample count is < 16, so it doesn't really matter if it's zeroed or
not. The MCS data is retrieved from ld_mcs which already returns 4 or 8
registers of data even before SKL. I guess I could add that to the
commit message.
> I am not a big fan of the, lay out all the infrastructure, then use it
> later, when it comes to patch review. Or am I missing something?
Hrm, I think for other patches I've had the opposite complaint so I
don't know what is best.
> (Also, I think a separate case for SHADER_OPCODE_TXF_CMS_W would
> probably look a bit nicer, but that's just a random thought).
Yes, you're probably right. I guess this patch is going to conflict with
your fast clear branch anyway so one of us will have to split it out at
that point :)
Regards,
- Neil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
