From 5cec8933846e633d33ebf6bd581d46583a308dd5 Mon Sep 17 00:00:00 2001 From: Iago Toral Quiroga Date: Fri, 21 Jan 2022 13:30:22 +0100 Subject: [PATCH] broadcom/compiler: update comment on load_uniform fast-path MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The comment for 16-bit applies to 8-bit uniforms as well. Reviewed-by: Alejandro Piñeiro Part-of: --- src/broadcom/compiler/nir_to_vir.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/broadcom/compiler/nir_to_vir.c b/src/broadcom/compiler/nir_to_vir.c index 2a6fdbfb3d6..56635f0a69e 100644 --- a/src/broadcom/compiler/nir_to_vir.c +++ b/src/broadcom/compiler/nir_to_vir.c @@ -2648,11 +2648,12 @@ ntq_emit_load_uniform(struct v3d_compile *c, nir_intrinsic_instr *instr) nir_src_as_uint(instr->src[0])); /* Even though ldunif is strictly 32-bit we can still use it - * to load scalar 16-bit uniforms so long as their offset is - * 32-bit aligned. In this case, ldunif would still load 32-bit - * into the destination with the 16-bit uniform data in the LSB - * and garbage in the MSB, but that is fine because we don't - * access the MSB of a 16-bit register. + * to load scalar 8-bit/16-bit uniforms so long as their offset + * is * 32-bit aligned. In this case, ldunif would still load + * 32-bit into the destination with the 8-bit/16-bit uniform + * data in the LSB and garbage in the MSB, but that is fine + * because we should only be accessing the valid bits of the + * destination. * * FIXME: if in the future we improve our register allocator to * pack 2 16-bit variables in the MSB and LSB of the same