[Mesa-dev] [PATCH 1/9] radeonsi: reorder sample locations as required by EQAA

[Marek Olšák]

On Mon, May 7, 2018 at 7:49 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:

> On 02.05.2018 06:13, Marek Olšák wrote:
>
>> From: Marek Olšák <marek.olsak at amd.com>
>>
>> ---
>>   src/gallium/drivers/radeonsi/si_state.c      |   3 -
>>   src/gallium/drivers/radeonsi/si_state_msaa.c | 154 ++++++++++++-------
>>   2 files changed, 98 insertions(+), 59 deletions(-)
>>
>> diff --git a/src/gallium/drivers/radeonsi/si_state.c
>> b/src/gallium/drivers/radeonsi/si_state.c
>> index 62d0ed99d94..3f9332081bf 100644
>> --- a/src/gallium/drivers/radeonsi/si_state.c
>> +++ b/src/gallium/drivers/radeonsi/si_state.c
>> @@ -4688,23 +4688,20 @@ static void si_init_config(struct si_context
>> *sctx)
>>                 si_pm4_set_reg(pm4, R_028B98_VGT_STRMOUT_BUFFER_CONFIG,
>> 0x0);
>>         }
>>         si_pm4_set_reg(pm4, R_028AA0_VGT_INSTANCE_STEP_RATE_0, 1);
>>         if (!has_clear_state)
>>                 si_pm4_set_reg(pm4, R_028AB8_VGT_VTX_CNT_EN, 0x0);
>>         if (sctx->chip_class < CIK)
>>                 si_pm4_set_reg(pm4, R_008A14_PA_CL_ENHANCE,
>> S_008A14_NUM_CLIP_SEQ(3) |
>>                                S_008A14_CLIP_VTX_REORDER_ENA(1));
>>   -     si_pm4_set_reg(pm4, R_028BD4_PA_SC_CENTROID_PRIORITY_0,
>> 0x76543210);
>> -       si_pm4_set_reg(pm4, R_028BD8_PA_SC_CENTROID_PRIORITY_1,
>> 0xfedcba98);
>> -
>>         if (!has_clear_state)
>>                 si_pm4_set_reg(pm4, R_02882C_PA_SU_PRIM_FILTER_CNTL, 0);
>>         /* CLEAR_STATE doesn't clear these correctly on certain
>> generations.
>>          * I don't know why. Deduced by trial and error.
>>          */
>>         if (sctx->chip_class <= CIK) {
>>                 si_pm4_set_reg(pm4, R_028B28_VGT_STRMOUT_DRAW_OPAQUE_OFFSET,
>> 0);
>>                 si_pm4_set_reg(pm4, R_028204_PA_SC_WINDOW_SCISSOR_TL,
>> S_028204_WINDOW_OFFSET_DISABLE(1));
>>                 si_pm4_set_reg(pm4, R_028240_PA_SC_GENERIC_SCISSOR_TL,
>> S_028240_WINDOW_OFFSET_DISABLE(1));
>> diff --git a/src/gallium/drivers/radeonsi/si_state_msaa.c
>> b/src/gallium/drivers/radeonsi/si_state_msaa.c
>> index 7ee17a9f292..0f9e0fea1c7 100644
>> --- a/src/gallium/drivers/radeonsi/si_state_msaa.c
>> +++ b/src/gallium/drivers/radeonsi/si_state_msaa.c
>> @@ -30,45 +30,97 @@
>>          (((unsigned)(s1x) & 0xf) << 8)  | (((unsigned)(s1y) & 0xf) <<
>> 12) | \
>>          (((unsigned)(s2x) & 0xf) << 16) | (((unsigned)(s2y) & 0xf) <<
>> 20) | \
>>          (((unsigned)(s3x) & 0xf) << 24) | (((unsigned)(s3y) & 0xf) <<
>> 28))
>>     /* For obtaining location coordinates from registers */
>>   #define SEXT4(x)              ((int)((x) | ((x) & 0x8 ? 0xfffffff0 :
>> 0)))
>>   #define GET_SFIELD(reg, index)        SEXT4(((reg) >> ((index) * 4)) &
>> 0xf)
>>   #define GET_SX(reg, index)    GET_SFIELD((reg)[(index) / 4], ((index) %
>> 4) * 2)
>>   #define GET_SY(reg, index)    GET_SFIELD((reg)[(index) / 4], ((index) %
>> 4) * 2 + 1)
>>   +/* The following sample ordering is required by EQAA.
>> + *
>> + * Sample 0 is approx. in the top-left quadrant.
>> + * Sample 1 is approx. in the bottom-right quadrant.
>> + *
>> + * Sample 2 is approx. in the bottom-left quadrant.
>> + * Sample 3 is approx. in the top-right quadrant.
>> + * (sample I={2,3} adds more detail to the vicinity of sample I-2)
>>
>
> Isn't technically the requirement only that 0/1 are in opposite quadrants
> and 2/3 fill in the rest. Anyway,
>

Yes, you can say that, and indeed it doesn't make a lot of sense to talk
about vicinity with only 4 samples, but it's how EQAA works when you have
fewer Z samples than coverage samples. In that case, the hw has to use the
closest defined Z sample, which is I-2. So the definition that "sample
I={2,3} adds more detail to the vicinity of sample I-2" is accurate with
respect to EQAA with undefined Z samples.

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180507/b8c4b483/attachment.html>