NIR: A New IR Developed For Mesa That's Better Than GLSL IR

[log0]

don't forget that work on this IR started before opengl next was announced.

I haven't seen any actual technical arguments against LLVM, except that it causes tables to flip. If there was an actual discussion about the shortcomings of LLVM-IR, I think that'd be more productive than a single vendor creating a new IR from scratch without input from the others. Right now, to an outside observer, it looks like intel was unable to get LLVM to work and thus decided to pull a NIH instead.

From mailing list:

NIR supports structured control flow, swizzles and writemasks, modifiers
(abs, negate, saturate), etc. natively in the IR instead of something
that's tacked on or something that drivers have to do themselves. So
no, I'm not re-inventing LLVM.

I guess they want something that better matches their hw?

From http://www.freedesktop.org/wiki/Soft...ured_branches/

Transforming the LLVM IR code into structured code results in basically reverse-engineering the LLVM code into the original C code.

Although it seems to be a solved issue, at least for Beignet.

[bouliiii]

From mailing list:

I guess they want something that better matches their hw?

From http://www.freedesktop.org/wiki/Soft...ured_branches/

Although it seems to be a solved issue, at least for Beignet.

Control flow in SIMD program is an interesting topic. Beignet developpers quite improved the initial implementation described here. They first used if/endif to mask out block. This allows much better codegen. And they added some structural analysis to match if/else/endif, if/endif, ifnot/endif and ifnot/else/endif. This allows recursive mixing of simple (hardware supported) structured branches and software emulated unstructured branches as I did initially.

Other stuffs should be considered then like interaction with loops, divergence analysis to ensure proper reconvergence of control flow. For example, structured control flow may be not that good regarding SIMD occupancy. break instructions (as in HLSL IR or glsl IR or even in HW) are an example of a poorly designed approach regarding SIMD occupancy. Even HW implementers poorly designed some of their branches regarding SIMD occupancy.

Anyway, this is a cool topic :-)

[robclark]

Have you already take the compilers course in the university ?
Joking aside, if you hadn't yet you should before finalizing the language. It would save a lot of grief in the future.

s/take/teach/ :-P

I really doubt an undergrad level compiler course would teach cwabbot anything new at this point.

re: LLVM.. I'm not really sure it is worth the headache. It sounds very attractive in concept. It would be nice if it wasn't written in C++, or at least restricted itself to a subset of C++ to make it a bit more sane to use as a library. I am at least pretty happy not to have to frequently rebuild whatever private version of LLVM that mesa needs that week on a little arm device. It would be nice if somehow (at the gallium level) I could get an SSA (or use-def) type IR (rather than TGSI) with a concept of basic-blocks, which would save me from having to turn TGSI back into use-def graph. I guess if there was a way to re-use passes for CSE and perhaps rematerialization that could be nice. OTOH, instruction scheduling and that sort of thing really aren't too hard to implement once you have SSA/use-def.

[robclark]

And why the heck they decided to implement this new IR?
To me these decisions are made mostly due to political rather than technical reasons. Exactly the same thing as intel did with mir. You may like or hate Canonical for this decision but why to remove support from the driver? Intel is known for making its own in-home solutions incompatible with other drivers (keeping classic mesa driver, ignoring clover by introducing new technology, ignoring LLVM etc).
If someone could clarify their decisions with only technical arguments I'll be more than happy to change my pov.

I see very little in common between mir vs. wayland, and LLVM vs. NIR. At least the latter does not have impact on application writers, toolkit writers, etc. It is merely an implementation detail within mesa.

[robclark]

Why didn't Intel and this developer just take the Gallium TGSI IR and maybe tweak that a bit here and there to suit their needs? That seems like less work, for sure, with very similar results in the end. Plus, then we wouldn't have what? 4 different freaking IRs? 2 of which we either don't use, or use as an intermediary step for literally no reason other than nobody wants to do the work to remove that step.

TGSI is not a real IR. Every gallium driver that needs to do any sort of optimization, instruction scheduling, etc, turns TGSI into it's own private internal IR.

I'd be curious if they make the same mistake w/ the NewGL (is there a name for it yet?) IR.. if so, then we'll be back to turning it into something suitable for a compiler.

[xxmitsu]

And why the heck they decided to implement this new IR?
Intel is known for making its own in-home solutions incompatible with other drivers (keeping classic mesa driver, ignoring clover by introducing new technology, ignoring LLVM etc).
If someone could clarify their decisions with only technical arguments I'll be more than happy to change my pov.

IMO, so that others (competition) would not benefit so much(directly) from their work.

[robclark]

IMO, so that others (competition) would not benefit so much(directly) from their work.

I don't expect LLVM vs NIR makes any difference to re-use from other mesa drivers, so much so as figuring out how to plumb it through gallium..

The non-mesa drivers, we don't care about one way or another.