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 IR's 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. 119
