← Back to branch summary

~mmach/netext73/mesa-haswell

« back to all changes in this revision

Viewing changes to src/compiler/nir/README

  • Committer: mmach
  • Date: 2022-09-22 19:56:13 UTC
  • Revision ID: netbit73@gmail.com-20220922195613-wtik9mmy20tmor0i
2022-09-22 21:17:09

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/compiler/nir/README
1
 
New IR, or NIR, is an IR for Mesa intended to sit below GLSL IR and Mesa IR.
2
 
Its design inherits from the various IRs that Mesa has used in the past, as
3
 
well as Direct3D assembly, and it includes a few new ideas as well. It is a
4
 
flat (in terms of using instructions instead of expressions), typeless IR,
5
 
similar to TGSI and Mesa IR.  It also supports SSA (although it doesn't require
6
 
it).
7
 
 
8
 
Variables
9
 
=========
10
 
 
11
 
NIR includes support for source-level GLSL variables through a structure mostly
12
 
copied from GLSL IR. These will be used for linking and conversion from GLSL IR
13
 
(and later, from an AST), but for the most part, they will be lowered to
14
 
registers (see below) and loads/stores.
15
 
 
16
 
Registers
17
 
=========
18
 
 
19
 
Registers are light-weight; they consist of a structure that only contains its
20
 
size, its index for liveness analysis, and an optional name for debugging. In
21
 
addition, registers can be local to a function or global to the entire shader;
22
 
the latter will be used in ARB_shader_subroutine for passing parameters and
23
 
getting return values from subroutines. Registers can also be an array, in which
24
 
case they can be accessed indirectly. Each ALU instruction (add, subtract, etc.)
25
 
works directly with registers or SSA values (see below).
26
 
 
27
 
SSA
28
 
========
29
 
 
30
 
Everywhere a register can be loaded/stored, an SSA value can be used instead.
31
 
The only exception is that arrays/indirect addressing are not supported with
32
 
SSA; although research has been done on extensions of SSA to arrays before, it's
33
 
usually for the purpose of parallelization (which we're not interested in), and
34
 
adds some overhead in the form of adding copies or extra arrays (which is much
35
 
more expensive than introducing copies between non-array registers). SSA uses
36
 
point directly to their corresponding definition, which in turn points to the
37
 
instruction it is part of. This creates an implicit use-def chain and avoids the
38
 
need for an external structure for each SSA register.
39
 
 
40
 
Functions
41
 
=========
42
 
 
43
 
Support for function calls is mostly similar to GLSL IR. Each shader contains a
44
 
list of functions, and each function has a list of overloads. Each overload
45
 
contains a list of parameters, and may contain an implementation which specifies
46
 
the variables that correspond to the parameters and return value. Inlining a
47
 
function, assuming it has a single return point, is as simple as copying its
48
 
instructions, registers, and local variables into the target function and then
49
 
inserting copies to and from the new parameters as appropriate. After functions
50
 
are inlined and any non-subroutine functions are deleted, parameters and return
51
 
variables will be converted to global variables and then global registers. We
52
 
don't do this lowering earlier (i.e. the fortranizer idea) for a few reasons:
53
 
 
54
 
- If we want to do optimizations before link time, we need to have the function
55
 
signature available during link-time.
56
 
 
57
 
- If we do any inlining before link time, then we might wind up with the
58
 
inlined function and the non-inlined function using the same global
59
 
variables/registers which would preclude optimization.
60
 
 
61
 
Intrinsics
62
 
=========
63
 
 
64
 
Any operation (other than function calls and textures) which touches a variable
65
 
or is not referentially transparent is represented by an intrinsic. Intrinsics
66
 
are similar to the idea of a "builtin function," i.e. a function declaration
67
 
whose implementation is provided by the backend, except they are more powerful
68
 
in the following ways:
69
 
 
70
 
- They can also load and store registers when appropriate, which limits the
71
 
number of variables needed in later stages of the IR while obviating the need
72
 
for a separate load/store variable instruction.
73
 
 
74
 
- Intrinsics can be marked as side-effect free, which permits them to be
75
 
treated like any other instruction when it comes to optimizations. This allows
76
 
load intrinsics to be represented as intrinsics while still being optimized
77
 
away by dead code elimination, common subexpression elimination, etc.
78
 
 
79
 
Intrinsics are used for:
80
 
 
81
 
- Atomic operations
82
 
- Memory barriers
83
 
- Subroutine calls
84
 
- Geometry shader emitVertex and endPrimitive
85
 
- Loading and storing variables (before lowering)
86
 
- Loading and storing uniforms, shader inputs and outputs, etc (after lowering)
87
 
- Copying variables (cases where in GLSL the destination is a structure or
88
 
array)
89
 
- The kitchen sink
90
 
- ...
91
 
 
92
 
Textures
93
 
=========
94
 
 
95
 
Unfortunately, there are far too many texture operations to represent each one
96
 
of them with an intrinsic, so there's a special texture instruction similar to
97
 
the GLSL IR one. The biggest difference is that, while the texture instruction
98
 
has a sampler dereference field used just like in GLSL IR, this gets lowered to
99
 
a texture unit index (with a possible indirect offset) while the type
100
 
information of the original sampler is kept around for backends. Also, all the
101
 
non-constant sources are stored in a single array to make it easier for
102
 
optimization passes to iterate over all the sources.
103
 
 
104
 
Control Flow
105
 
=========
106
 
 
107
 
Like in GLSL IR, control flow consists of a tree of "control flow nodes", which
108
 
include if statements and loops, and jump instructions (break, continue, and
109
 
return). Unlike GLSL IR, though, the leaves of the tree aren't statements but
110
 
basic blocks. Each basic block also keeps track of its successors and
111
 
predecessors, and function implementations keep track of the beginning basic
112
 
block (the first basic block of the function) and the ending basic block (a fake
113
 
basic block that every return statement points to). Together, these elements
114
 
make up the control flow graph, in this case a redundant piece of information on
115
 
top of the control flow tree that will be used by almost all the optimizations.
116
 
There are helper functions to add and remove control flow nodes that also update
117
 
the control flow graph, and so usually it doesn't need to be touched by passes
118
 
that modify control flow nodes.