On 18.04.2018 14:36, Samuel Pitoiset wrote:
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 <[email protected]>
---
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.
In that case, is it possible that the at_center interpolation
accidentally gets the sample location? Just stabbing in the dark,
admittedly...
Cheers,
Nicolai
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
