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?
Cheers,
Nicolai
case nir_intrinsic_interp_var_at_offset:
location = INTERP_CENTER;
src0 = get_src(ctx, instr->src[0]);
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
