summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/radeonsi
diff options
context:
space:
mode:
authorPaul Berry <[email protected]>2013-01-11 14:39:32 -0800
committerPaul Berry <[email protected]>2013-01-24 16:30:30 -0800
commit42a29d89fd85c86387f0d119950e243b6de76d79 (patch)
tree9eee8f2d609855dc9c6813aac84f5fdcd6786a54 /src/gallium/drivers/radeonsi
parent7d51ead56e2b97d313c6a0fda22cc930b5c41e9d (diff)
glsl: Eliminate ambiguity between function ins/outs and shader ins/outs
This patch replaces the three ir_variable_mode enums: - ir_var_in - ir_var_out - ir_var_inout with the following five: - ir_var_shader_in - ir_var_shader_out - ir_var_function_in - ir_var_function_out - ir_var_function_inout This eliminates a frustrating ambiguity: it used to be impossible to tell whether an ir_var_{in,out} variable was a shader in/out or a function in/out without seeing where the variable was declared in the IR. This complicated some optimization and lowering passes, and would have become a problem for implementing varying structs. In the lisp-style serialization of GLSL IR to strings performed by ir_print_visitor.cpp and ir_reader.cpp, I've retained the names "in", "out", and "inout" for function parameters, to avoid introducing code churn to the src/glsl/builtins/ir/ directory. Note: a couple of comments in the code seemed to indicate that we were planning for a possible future in which geometry shaders could have shader-scope inout variables. Our GLSL grammar rejects shader-scope inout variables, and I've been unable to find any evidence in the GLSL standards documents (or extensions) that this will ever be allowed, so I've eliminated these comments. Reviewed-by: Carl Worth <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
Diffstat (limited to 'src/gallium/drivers/radeonsi')
0 files changed, 0 insertions, 0 deletions