On Mon, May 7, 2018 at 7:49 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
> On 02.05.2018 06:13, Marek Olšák wrote:
>
>> From: Marek Olšák <marek.ol...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
