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.pitoi...@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]);
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
