[Mesa-dev] [PATCH 1/2] ac/nir: fix interp mode for nir_intrinsic_interp_var_at_sample

[Samuel Pitoiset]

On 04/18/2018 12:19 PM, Nicolai Hähnle wrote:
> On 17.04.2018 15:08, Samuel Pitoiset wrote:
>> This fixes the following CTS tests:
>> dEQP-VK.pipeline.multisample_interpolation.sample_interpolate_at_consistency.* 
>>
>>
>> This restores the previous behaviour, maybe the CTS tests
>> were wrong?
>>
>> Fixes: 22b116171f8 ("radv: fix interp at sample code.")
>> Signed-off-by: Samuel Pitoiset <samuel.pitoiset at gmail.com>
>> ---
>>   src/amd/common/ac_nir_to_llvm.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/src/amd/common/ac_nir_to_llvm.c 
>> b/src/amd/common/ac_nir_to_llvm.c
>> index 45405d30fe8..b0631ad41a8 100644
>> --- a/src/amd/common/ac_nir_to_llvm.c
>> +++ b/src/amd/common/ac_nir_to_llvm.c
>> @@ -2710,6 +2710,9 @@ static LLVMValueRef visit_interp(struct 
>> ac_nir_context *ctx,
>>           location = INTERP_CENTROID;
>>           break;
>>       case nir_intrinsic_interp_var_at_sample:
>> +        location = INTERP_SAMPLE;
>> +        src0 = get_src(ctx, instr->src[0]);
>> +        break;
> 
> This makes no sense. Consider the code below; it will compute src_c{0,1} 
> in the nir_intrinsic_interp_var_at_sample case, but by setting location 
> == INTERP_SAMPLE, those values will never actually be used.
> 
> Is it possible that the test uses sample rate shading, and the sample 
> number passed into the intrinsic coincides with the sample number of the 
> PS invocation?

Right, that makes no sense actually...

Yes, sample rate shading is enabled but I don't know if the sample 
number coincides.

> 
> Cheers,
> Nicolai
> 
> 
>>       case nir_intrinsic_interp_var_at_offset:
>>           location = INTERP_CENTER;
>>           src0 = get_src(ctx, instr->src[0]);
>>
> 
>