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

[Rakot]

Try to see it from Intel pov. To switch to LLVM would mean rewrite a lot of code for no reason, there is no guarantee that LLVM will be faster than current code. They also would be dependent on LLVM, which can be seen as a handicap, as you are less flexible compared to using your own code.

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.

[xeekei]

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.

None of the three vendors are perfect when it comes to graphics drivers on Linux. It seems we can't have nice things.

[log0]

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.

Maybe they thought it would be an interesting task for an intern? Also an IR doesn't make a compiler...

And the points I've named in my reply are not technical reasons? I see.

[Rakot]

Maybe they thought it would be an interesting task for an intern? Also an IR doesn't make a compiler...

And the points I've named in my reply are not technical reasons? I see.

For me not really. It's just a bunch of assumptions. For me the example of the technical reasons are Vadim's posts about why LLVM is not good when he introduced his SB backend (you can check mesa-mailing list somewhere in november, 2013).
As for this particular work the same argument applies to NIR (just for reference check Ian's posts in February).
To be clear, I'm not against new technologies. I'm for wider communication and unification between different vendors in Linux world. I appreciate the amount of effort intel put into linux graphics stack but when it comes to incompatible solutions it is not good at all (and i don't mean NIR here).

[gigaplex]

Didn't Khronos announce that the "next generation" OpenGL will come with its own new IR? If that's true, there's little point reinventing new placeholder IRs at this time.

[Daktyl198]

I'm confused. Is this new IR here to replace the old Mesa IR? Well it can't very well do that, because of stupid backwards-compatibility and all that. So then it's here to supplement the Mesa IR on just the Intel driver? So we're putting an Intel-driver specific (probably large) piece of code into Mesa as a whole?

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.

Feel free to explain this to an idiot like me.

[smitty3268]

I'm confused. Is this new IR here to replace the old Mesa IR? Well it can't very well do that, because of stupid backwards-compatibility and all that. So then it's here to supplement the Mesa IR on just the Intel driver? So we're putting an Intel-driver specific (probably large) piece of code into Mesa as a whole?

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.

Feel free to explain this to an idiot like me.

It's to replace GLSL IR, in the compiler Intel wrote in the first place that all the other drivers use too.

Yes, they'll write a native backend in their i965 driver to handle it, just like they currently do with GLSL IR.

For Gallium, it will just get translated into TGSI, just like GLSL IR already does, and from there it will be exactly the same as it already is.

So really no big deal, except for Intel since they are writing the GLSL compiler and integrating it into their driver. If they want to do that, then it shouldn't bother anyone else.

[Veto]

Didn't Khronos announce that the "next generation" OpenGL will come with its own new IR? If that's true, there's little point reinventing new placeholder IRs at this time.

Well, an IR does not appear out of thin air - even for Khronos - and it is difficult to make the "IR to bind them all" without prior experiments and experience. Who knows, maybe NIR will be the foundation for OpenGl 5 IR? ;-)

It would be really interesting to see a Wiki or LWN article explaining the differences between the IRs.

[rohcQaH]

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.

[Ziple]

That's kind of fun. Once I saw this announcement first time the MIR just came into my mind. After reading the description of this patch set and earlier discussion I confirmed my first impression that it is NIH syndrome. More interesting is that this kid suffered from the same problem as all young unexperienced people: he really underestimated the complexity of the problem. In February he wrote that the initial work would take him at most 2 months while other developers mentioned a half of year time frame. And you know what, it took him exactly 6 months to make this first patchset.
As a side note. What I also do not understand is why does Intel ignore LLVM. Ian mentioned that they tried a couple of time and they did not succeed. Meantime Tom from AMD and a couple of other folks already achieved speed parity of radeonSI hardware compared to catalyst in a number of workloads. So does it mean that intel developers are so weak? Or am I missing very important point here?
Also how does this patchset overlap with Vadim's sb work?

Parity between AMD closed source driver and open source is certainly due to that both use LLVM in fact.