From a7c8811fe4012b60a9bcdb2ea2ef6ab79e402809 Mon Sep 17 00:00:00 2001 From: Jason Ekstrand Date: Sat, 25 Apr 2020 14:15:11 -0500 Subject: [PATCH] intel/vec4: Stomp the return type of RESINFO to UINT32 We already do this in the FS back-end; we just weren't doing it in vec4 so RESINFO messages weren't returning the right data. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Kenneth Graunke Part-of: --- src/intel/compiler/brw_vec4_generator.cpp | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/intel/compiler/brw_vec4_generator.cpp b/src/intel/compiler/brw_vec4_generator.cpp index be6697cc16c..3fe1edc38ac 100644 --- a/src/intel/compiler/brw_vec4_generator.cpp +++ b/src/intel/compiler/brw_vec4_generator.cpp @@ -270,6 +270,17 @@ generate_tex(struct brw_codegen *p, break; } + /* Stomp the resinfo output type to UINT32. On gens 4-5, the output type + * is set as part of the message descriptor. On gen4, the PRM seems to + * allow UINT32 and FLOAT32 (i965 PRM, Vol. 4 Section 4.8.1.1), but on + * later gens UINT32 is required. Once you hit Sandy Bridge, the bit is + * gone from the message descriptor entirely and you just get UINT32 all + * the time regasrdless. Since we can really only do non-UINT32 on gen4, + * just stomp it to UINT32 all the time. + */ + if (inst->opcode == SHADER_OPCODE_TXS) + return_format = BRW_SAMPLER_RETURN_FORMAT_UINT32; + uint32_t base_binding_table_index = (inst->opcode == SHADER_OPCODE_TG4 || inst->opcode == SHADER_OPCODE_TG4_OFFSET) ? prog_data->base.binding_table.gather_texture_start -- 2.30.2