• Home
Name Date Size #Lines LOC

..--

glcpp/12-May-2024-7,1204,389

tests/12-May-2024-6,2624,748

READMED12-May-202410.5 KiB228182

TODOD12-May-2024689 1310

ast.hD12-May-202436.6 KiB1,407731

ast_array_index.cppD12-May-202415 KiB365207

ast_expr.cppD12-May-20242.2 KiB9663

ast_function.cppD12-May-202495.2 KiB2,5621,692

ast_to_hir.cppD12-May-2024346.7 KiB9,1455,798

ast_type.cppD12-May-202432.4 KiB1,026811

builtin_functions.cppD12-May-2024446.2 KiB8,5966,909

builtin_functions.hD12-May-20242.3 KiB7936

builtin_int64.hD12-May-202440.8 KiB1,141645

builtin_types.cppD12-May-202419.4 KiB475368

builtin_variables.cppD12-May-202464.5 KiB1,6961,292

float64.glslD12-May-202454.6 KiB1,7251,564

generate_ir.cppD12-May-20241.3 KiB347

gl_nir.hD12-May-20242.6 KiB6633

gl_nir_link_atomics.cD12-May-202413 KiB376265

gl_nir_link_uniform_blocks.cD12-May-202423.4 KiB654344

gl_nir_link_uniform_initializers.cD12-May-202410.7 KiB309244

gl_nir_link_uniforms.cD12-May-202471.5 KiB1,9371,329

gl_nir_link_varyings.cD12-May-2024119.9 KiB3,2132,028

gl_nir_link_varyings.hD12-May-20245.9 KiB22152

gl_nir_link_xfb.cD12-May-20248.6 KiB230123

gl_nir_linker.cD12-May-202436.1 KiB1,000667

gl_nir_linker.hD12-May-20244.7 KiB12173

gl_nir_lower_atomics.cD12-May-20245.7 KiB179111

gl_nir_lower_buffers.cD12-May-202414 KiB362238

gl_nir_lower_images.cD12-May-20244.3 KiB13787

gl_nir_lower_packed_varyings.cD12-May-202439.9 KiB1,082637

gl_nir_lower_samplers.cD12-May-20241.7 KiB409

gl_nir_lower_samplers_as_deref.cD12-May-202413.9 KiB404245

gl_nir_lower_xfb_varying.cD12-May-20247.1 KiB210146

gl_nir_opt_dead_builtin_varyings.cD12-May-202418 KiB550369

glsl_lexer.llD12-May-202441.7 KiB796721

glsl_parser.yyD12-May-202494.8 KiB3,1102,854

glsl_parser_extras.cppD12-May-202480.1 KiB2,4421,779

glsl_parser_extras.hD12-May-202434.5 KiB1,079710

glsl_symbol_table.cppD12-May-20249 KiB295222

glsl_symbol_table.hD12-May-20243.6 KiB11437

glsl_to_nir.cppD12-May-202492.9 KiB2,7832,232

glsl_to_nir.hD12-May-20241.8 KiB5419

hir_field_selection.cppD12-May-20243.1 KiB8141

int64.glslD12-May-20242.3 KiB10084

ir.cppD12-May-202466.9 KiB2,4161,899

ir.hD12-May-202472.7 KiB2,5561,127

ir_array_refcount.cppD12-May-20246 KiB208119

ir_array_refcount.hD12-May-20243.6 KiB12844

ir_basic_block.cppD12-May-20243.3 KiB10039

ir_basic_block.hD12-May-20241.4 KiB348

ir_builder.cppD12-May-202410.9 KiB636498

ir_builder.hD12-May-20246.9 KiB242167

ir_builder_print_visitor.cppD12-May-202423.3 KiB776606

ir_builder_print_visitor.hD12-May-20241.3 KiB325

ir_clone.cppD12-May-202412.4 KiB439317

ir_constant_expression.cppD12-May-202434.3 KiB1,236761

ir_equals.cppD12-May-20245.5 KiB218151

ir_expression_flattening.cppD12-May-20242.6 KiB8539

ir_expression_flattening.hD12-May-20241.8 KiB445

ir_expression_operation.pyD12-May-202443.4 KiB829576

ir_function.cppD12-May-202413.8 KiB412234

ir_function_can_inline.cppD12-May-20242.4 KiB7630

ir_function_detect_recursion.cppD12-May-202411.5 KiB361157

ir_function_inlining.hD12-May-20241.4 KiB364

ir_hierarchical_visitor.cppD12-May-20249 KiB404298

ir_hierarchical_visitor.hD12-May-20249.1 KiB21767

ir_hv_accept.cppD12-May-202411.9 KiB458320

ir_optimization.hD12-May-20246 KiB14691

ir_print_visitor.cppD12-May-202416.7 KiB671530

ir_print_visitor.hD12-May-20243.1 KiB9541

ir_reader.cppD12-May-202435.4 KiB1,2121,002

ir_reader.hD12-May-20241.4 KiB346

ir_rvalue_visitor.cppD12-May-20246.7 KiB316239

ir_rvalue_visitor.hD12-May-20243.8 KiB8949

ir_set_program_inouts.cppD12-May-202415 KiB442260

ir_uniform.hD12-May-20246.5 KiB23460

ir_validate.cppD12-May-202438.1 KiB1,2281,007

ir_variable_refcount.cppD12-May-20244.5 KiB15386

ir_variable_refcount.hD12-May-20242.9 KiB9232

ir_visitor.hD12-May-20243.6 KiB9550

link_functions.cppD12-May-202411.7 KiB340180

link_interface_blocks.cppD12-May-202420.2 KiB553297

link_uniform_block_active_visitor.cppD12-May-202410.2 KiB295174

link_uniform_block_active_visitor.hD12-May-20242.7 KiB8337

link_uniform_blocks.cppD12-May-202420.9 KiB579392

link_uniforms.cppD12-May-202410.3 KiB284165

link_varyings.cppD12-May-202432.9 KiB805528

link_varyings.hD12-May-20241.9 KiB4914

linker.cppD12-May-2024143.9 KiB3,9942,480

linker.hD12-May-20248 KiB19975

linker_util.cppD12-May-202415.7 KiB441253

linker_util.hD12-May-20243.9 KiB11857

list.hD12-May-202421.9 KiB778513

lower_blend_equation_advanced.cppD12-May-202418.4 KiB572366

lower_builtins.cppD12-May-20241.9 KiB6827

lower_cs_derived.cppD12-May-20247.5 KiB236154

lower_discard.cppD12-May-20244.7 KiB20267

lower_discard_flow.cppD12-May-20244.6 KiB15582

lower_distance.cppD12-May-202424.2 KiB686386

lower_instructions.cppD12-May-202455.6 KiB1,559919

lower_int64.cppD12-May-202411.3 KiB380224

lower_jumps.cppD12-May-202434.9 KiB938445

lower_mat_op_to_vec.cppD12-May-202414.1 KiB442297

lower_named_interface_blocks.cppD12-May-202411.1 KiB324206

lower_output_reads.cppD12-May-20246 KiB18399

lower_packing_builtins.cppD12-May-202446.3 KiB1,312473

lower_precision.cppD12-May-202444.2 KiB1,377920

lower_subroutine.cppD12-May-20243.7 KiB12577

lower_tess_level.cppD12-May-202415.8 KiB462237

lower_vec_index_to_cond_assign.cppD12-May-20245.7 KiB18297

lower_vec_index_to_swizzle.cppD12-May-20243.3 KiB10342

lower_vector_derefs.cppD12-May-20247.6 KiB204123

lower_vector_insert.cppD12-May-20245.7 KiB17996

lower_vertex_id.cppD12-May-20244.7 KiB14789

main.cppD12-May-20243.4 KiB10859

meson.buildD12-May-20248 KiB274256

opt_add_neg_to_sub.hD12-May-20242 KiB6227

opt_algebraic.cppD12-May-202432.3 KiB1,057751

opt_array_splitting.cppD12-May-202414.4 KiB500289

opt_constant_folding.cppD12-May-20245.7 KiB196113

opt_constant_propagation.cppD12-May-202415.2 KiB531352

opt_constant_variable.cppD12-May-20246.7 KiB230136

opt_copy_propagation_elements.cppD12-May-202420.6 KiB743505

opt_dead_builtin_variables.cppD12-May-20243.3 KiB8227

opt_dead_code.cppD12-May-20246.7 KiB19886

opt_dead_code_local.cppD12-May-20249.9 KiB352232

opt_dead_functions.cppD12-May-20243.9 KiB15384

opt_flatten_nested_if_blocks.cppD12-May-20242.7 KiB10442

opt_flip_matrices.cppD12-May-20243.9 KiB12470

opt_function_inlining.cppD12-May-202413.3 KiB467292

opt_if_simplification.cppD12-May-20243.7 KiB12855

opt_minmax.cppD12-May-202416 KiB534362

opt_rebalance_tree.cppD12-May-20249.4 KiB338195

opt_structure_splitting.cppD12-May-202410.7 KiB375244

opt_tree_grafting.cppD12-May-202411.3 KiB420275

program.hD12-May-20241.7 KiB4817

propagate_invariance.cppD12-May-20243.7 KiB13070

s_expression.cppD12-May-20246 KiB221147

s_expression.hD12-May-20244.6 KiB17993

serialize.cppD12-May-202448.3 KiB1,3461,079

serialize.hD12-May-20241.6 KiB5120

shader_cache.cppD12-May-20249.4 KiB267146

shader_cache.hD12-May-20241.5 KiB4112

standalone.cppD12-May-202421.7 KiB621482

standalone.hD12-May-20241.7 KiB5625

standalone_scaffolding.cppD12-May-20248.7 KiB276199

standalone_scaffolding.hD12-May-20243.8 KiB11559

string_to_uint_map.cppD12-May-20241.5 KiB4311

string_to_uint_map.hD12-May-20245.1 KiB17891

test.cppD12-May-20242.4 KiB7933

test_optpass.cppD12-May-20248.8 KiB255189

test_optpass.hD12-May-20241.2 KiB304

README

1Welcome to Mesa's GLSL compiler.  A brief overview of how things flow:
2
31) lex and yacc-based preprocessor takes the incoming shader string
4and produces a new string containing the preprocessed shader.  This
5takes care of things like #if, #ifdef, #define, and preprocessor macro
6invocations.  Note that #version, #extension, and some others are
7passed straight through.  See glcpp/*
8
92) lex and yacc-based parser takes the preprocessed string and
10generates the AST (abstract syntax tree).  Almost no checking is
11performed in this stage.  See glsl_lexer.ll and glsl_parser.yy.
12
133) The AST is converted to "HIR".  This is the intermediate
14representation of the compiler.  Constructors are generated, function
15calls are resolved to particular function signatures, and all the
16semantic checking is performed.  See ast_*.cpp for the conversion, and
17ir.h for the IR structures.
18
194) The driver (Mesa, or main.cpp for the standalone binary) performs
20optimizations.  These include copy propagation, dead code elimination,
21constant folding, and others.  Generally the driver will call
22optimizations in a loop, as each may open up opportunities for other
23optimizations to do additional work.  See most files called ir_*.cpp
24
255) linking is performed.  This does checking to ensure that the
26outputs of the vertex shader match the inputs of the fragment shader,
27and assigns locations to uniforms, attributes, and varyings.  See
28linker.cpp.
29
306) The driver may perform additional optimization at this point, as
31for example dead code elimination previously couldn't remove functions
32or global variable usage when we didn't know what other code would be
33linked in.
34
357) The driver performs code generation out of the IR, taking a linked
36shader program and producing a compiled program for each stage.  See
37../mesa/program/ir_to_mesa.cpp for Mesa IR code generation.
38
39FAQ:
40
41Q: What is HIR versus IR versus LIR?
42
43A: The idea behind the naming was that ast_to_hir would produce a
44high-level IR ("HIR"), with things like matrix operations, structure
45assignments, etc., present.  A series of lowering passes would occur
46that do things like break matrix multiplication into a series of dot
47products/MADs, make structure assignment be a series of assignment of
48components, flatten if statements into conditional moves, and such,
49producing a low level IR ("LIR").
50
51However, it now appears that each driver will have different
52requirements from a LIR.  A 915-generation chipset wants all functions
53inlined, all loops unrolled, all ifs flattened, no variable array
54accesses, and matrix multiplication broken down.  The Mesa IR backend
55for swrast would like matrices and structure assignment broken down,
56but it can support function calls and dynamic branching.  A 965 vertex
57shader IR backend could potentially even handle some matrix operations
58without breaking them down, but the 965 fragment shader IR backend
59would want to break to have (almost) all operations down channel-wise
60and perform optimization on that.  As a result, there's no single
61low-level IR that will make everyone happy.  So that usage has fallen
62out of favor, and each driver will perform a series of lowering passes
63to take the HIR down to whatever restrictions it wants to impose
64before doing codegen.
65
66Q: How is the IR structured?
67
68A: The best way to get started seeing it would be to run the
69standalone compiler against a shader:
70
71./glsl_compiler --dump-lir \
72	~/src/piglit/tests/shaders/glsl-orangebook-ch06-bump.frag
73
74So for example one of the ir_instructions in main() contains:
75
76(assign (constant bool (1)) (var_ref litColor)  (expression vec3 * (var_ref Surf
77aceColor) (var_ref __retval) ) )
78
79Or more visually:
80                     (assign)
81                 /       |        \
82        (var_ref)  (expression *)  (constant bool 1)
83         /          /           \
84(litColor)      (var_ref)    (var_ref)
85                  /                  \
86           (SurfaceColor)          (__retval)
87
88which came from:
89
90litColor = SurfaceColor * max(dot(normDelta, LightDir), 0.0);
91
92(the max call is not represented in this expression tree, as it was a
93function call that got inlined but not brought into this expression
94tree)
95
96Each of those nodes is a subclass of ir_instruction.  A particular
97ir_instruction instance may only appear once in the whole IR tree with
98the exception of ir_variables, which appear once as variable
99declarations:
100
101(declare () vec3 normDelta)
102
103and multiple times as the targets of variable dereferences:
104...
105(assign (constant bool (1)) (var_ref __retval) (expression float dot
106 (var_ref normDelta) (var_ref LightDir) ) )
107...
108(assign (constant bool (1)) (var_ref __retval) (expression vec3 -
109 (var_ref LightDir) (expression vec3 * (constant float (2.000000))
110 (expression vec3 * (expression float dot (var_ref normDelta) (var_ref
111 LightDir) ) (var_ref normDelta) ) ) ) )
112...
113
114Each node has a type.  Expressions may involve several different types:
115(declare (uniform ) mat4 gl_ModelViewMatrix)
116((assign (constant bool (1)) (var_ref constructor_tmp) (expression
117 vec4 * (var_ref gl_ModelViewMatrix) (var_ref gl_Vertex) ) )
118
119An expression tree can be arbitrarily deep, and the compiler tries to
120keep them structured like that so that things like algebraic
121optimizations ((color * 1.0 == color) and ((mat1 * mat2) * vec == mat1
122* (mat2 * vec))) or recognizing operation patterns for code generation
123(vec1 * vec2 + vec3 == mad(vec1, vec2, vec3)) are easier.  This comes
124at the expense of additional trickery in implementing some
125optimizations like CSE where one must navigate an expression tree.
126
127Q: Why no SSA representation?
128
129A: Converting an IR tree to SSA form makes dead code elimination,
130common subexpression elimination, and many other optimizations much
131easier.  However, in our primarily vector-based language, there's some
132major questions as to how it would work.  Do we do SSA on the scalar
133or vector level?  If we do it at the vector level, we're going to end
134up with many different versions of the variable when encountering code
135like:
136
137(assign (constant bool (1)) (swiz x (var_ref __retval) ) (var_ref a) )
138(assign (constant bool (1)) (swiz y (var_ref __retval) ) (var_ref b) )
139(assign (constant bool (1)) (swiz z (var_ref __retval) ) (var_ref c) )
140
141If every masked update of a component relies on the previous value of
142the variable, then we're probably going to be quite limited in our
143dead code elimination wins, and recognizing common expressions may
144just not happen.  On the other hand, if we operate channel-wise, then
145we'll be prone to optimizing the operation on one of the channels at
146the expense of making its instruction flow different from the other
147channels, and a vector-based GPU would end up with worse code than if
148we didn't optimize operations on that channel!
149
150Once again, it appears that our optimization requirements are driven
151significantly by the target architecture.  For now, targeting the Mesa
152IR backend, SSA does not appear to be that important to producing
153excellent code, but we do expect to do some SSA-based optimizations
154for the 965 fragment shader backend when that is developed.
155
156Q: How should I expand instructions that take multiple backend instructions?
157
158Sometimes you'll have to do the expansion in your code generation.
159However, in many cases you'll want to do a pass over the IR to convert
160non-native instructions to a series of native instructions.  For
161example, for the Mesa backend we have ir_div_to_mul_rcp.cpp because
162Mesa IR (and many hardware backends) only have a reciprocal
163instruction, not a divide.  Implementing non-native instructions this
164way gives the chance for constant folding to occur, so (a / 2.0)
165becomes (a * 0.5) after codegen instead of (a * (1.0 / 2.0))
166
167Q: How shoud I handle my special hardware instructions with respect to IR?
168
169Our current theory is that if multiple targets have an instruction for
170some operation, then we should probably be able to represent that in
171the IR.  Generally this is in the form of an ir_{bin,un}op expression
172type.  For example, we initially implemented fract() using (a -
173floor(a)), but both 945 and 965 have instructions to give that result,
174and it would also simplify the implementation of mod(), so
175ir_unop_fract was added.  The following areas need updating to add a
176new expression type:
177
178ir.h (new enum)
179ir.cpp:operator_strs (used for ir_reader)
180ir_constant_expression.cpp (you probably want to be able to constant fold)
181ir_validate.cpp (check users have the right types)
182
183You may also need to update the backends if they will see the new expr type:
184
185../mesa/program/ir_to_mesa.cpp
186
187You can then use the new expression from builtins (if all backends
188would rather see it), or scan the IR and convert to use your new
189expression type (see ir_mod_to_floor, for example).
190
191Q: How is memory management handled in the compiler?
192
193The hierarchical memory allocator "talloc" developed for the Samba
194project is used, so that things like optimization passes don't have to
195worry about their garbage collection so much.  It has a few nice
196features, including low performance overhead and good debugging
197support that's trivially available.
198
199Generally, each stage of the compile creates a talloc context and
200allocates its memory out of that or children of it.  At the end of the
201stage, the pieces still live are stolen to a new context and the old
202one freed, or the whole context is kept for use by the next stage.
203
204For IR transformations, a temporary context is used, then at the end
205of all transformations, reparent_ir reparents all live nodes under the
206shader's IR list, and the old context full of dead nodes is freed.
207When developing a single IR transformation pass, this means that you
208want to allocate instruction nodes out of the temporary context, so if
209it becomes dead it doesn't live on as the child of a live node.  At
210the moment, optimization passes aren't passed that temporary context,
211so they find it by calling talloc_parent() on a nearby IR node.  The
212talloc_parent() call is expensive, so many passes will cache the
213result of the first talloc_parent().  Cleaning up all the optimization
214passes to take a context argument and not call talloc_parent() is left
215as an exercise.
216
217Q: What is the file naming convention in this directory?
218
219Initially, there really wasn't one.  We have since adopted one:
220
221 - Files that implement code lowering passes should be named lower_*
222   (e.g., lower_builtins.cpp).
223 - Files that implement optimization passes should be named opt_*.
224 - Files that implement a class that is used throught the code should
225   take the name of that class (e.g., ir_hierarchical_visitor.cpp).
226 - Files that contain code not fitting in one of the previous
227   categories should have a sensible name (e.g., glsl_parser.yy).
228