On 02/18/2016 11:36 AM, Charmaine Lee wrote:

From: Brian Paul <bri...@vmware.com>
Sent: Thursday, February 18, 2016 7:51 AM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee
Subject: [PATCH] svga: allow non-contiguous VS input declarations

This fixes a glDrawPixels regression since b63fe0552b5f.  The new
quad-drawing utility code uses 3 vertex attributes (xyz, rgba, st).
For glDrawPixels path we don't use the rgba attribute so there's a
gap in the TGSI VS input declarations (INPUT[0] = pos, INPUT[2] =
texcoord).  The TGSI->VGPU10 translations code did not handle this
correctly.  I missed this because my VM was configured for HWv11
while testing.

Another way to fix this would be to change the tgsi_scan.c code so
that the tgsi_shader_info::num_inputs (and num_outputs) included
the unused inputs/outputs.  These counts would then actually be
"max input register index + 1" rather than "number of used inputs".
But that change could impact all drivers so put it off for now.

No regressions found with piglit or typical GL apps.
---
src/gallium/drivers/svga/svga_tgsi_vgpu10.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/svga/svga_tgsi_vgpu10.c 
b/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
index 1223e44..384fb9e 100644
--- a/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
+++ b/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
@@ -2446,7 +2446,7 @@ emit_input_declarations(struct svga_shader_emitter_v10 
*emit)
    else {
       assert(emit->unit == PIPE_SHADER_VERTEX);

-      for (i = 0; i < emit->info.num_inputs; i++) {
+      for (i = 0; i < emit->info.file_max[TGSI_FILE_INPUT] + 1; i++) {
          unsigned usage_mask = emit->info.input_usage_mask[i];
          unsigned index = i;

num_inputs are referenced in other functions as well such as 
svga_get_generic_inputs_mask,
don't we need to fix those as well?

svga_get_generic_inputs_mask() is only concerned with FS inputs so we're OK there. IIRC, the GLSL linker (or maybe the GLSL->TGSI converter) allocates contiguous outputs/inputs between shader stages so there should be no gaps there. I think it's just VS inputs where we can have gaps.

But now I'm looking at alloc_system_value_index() which uses info.num_inputs, potentially for the VS...

-Brian


_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to