GL_ARB_separate_shader_objects allow to match by name variable or block
interface. Input varying can't be removed as it is will impact the location
assignment.

The patch only disable deadcode optimization for inputs that don't have
an explicit location. It allows to remove various builtin variables.

In theory, I think we must keep them as it could impact the location
assignment. However I'm not sure anyone use a mix of match by names/by
locations.

Interface example:
layout (location = 0) vec4 zero;
vec4 one;  // assignment might be 0 if zero isn't used.

It fixes the bug 79783 and likely any application that uses
GL_ARB_separate_shader_objects extension.

Signed-off-by: Gregory Hainaut <gregory.hain...@gmail.com>
---
 src/glsl/opt_dead_code.cpp | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/src/glsl/opt_dead_code.cpp b/src/glsl/opt_dead_code.cpp
index e4bf874..9852747 100644
--- a/src/glsl/opt_dead_code.cpp
+++ b/src/glsl/opt_dead_code.cpp
@@ -131,6 +131,22 @@ do_dead_code(exec_list *instructions, bool 
uniform_locations_assigned)
                continue;
          }
 
+         /* Section 7.4.1 (Shader Interface Matching) of the OpenGL 4.5
+          * (Core Profile) spec says:
+          *
+          *    "With separable program objects, interfaces between shader
+          *    stages may involve the outputs from one program object and the
+          *    inputs from a second program object.  For such interfaces, it is
+          *    not possible to detect mismatches at link time, because the
+          *    programs are linked separately. When each such program is
+          *    linked, all inputs or outputs interfacing with another program
+          *    stage are treated as active."
+          */
+        if (entry->var->data.mode == ir_var_shader_in &&
+               !entry->var->data.attribute_input &&
+               !entry->var->data.explicit_location)
+           continue;
+
         entry->var->remove();
         progress = true;
 
-- 
2.1.4

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

Reply via email to