NIR Still Being Discussed For Mesa, LLVM Gets Brought Up Again

[phoronix]

Phoronix: NIR Still Being Discussed For Mesa, LLVM Gets Brought Up Again

Last week NIR was announced as a new intermediate representation for Mesa. Discussion around this new but experimental IR continues to happen among upstream developers while Mesa developers are back to discussing LLVM too...

http://www.phoronix.com/vr.php?view=MTc3Mzg

[Prescience500]

Please forgive my ignorance, but If there is really going to be an OpenGL-Next, will it be prudent to pour resources into redoing the compiler when they may need to do it again for OpenGL-Next? Or might they attempt to ensure that the new compiler will work well with OpenGL-Next, too?

[Marc Driftmeyer]

While LLVM is used extensively by Radeon (R600g/RadeonSI) and LLVMpipe drivers
most notably, Intel has been the main Mesa contributor against LLVM.

I find this rather ironic, as Intel won't shut up about pushing OpenMP into LLVM/Clang, and wonders how come the interest is minimal. Sorry, but Intel is a gnat in the LLVM/Clang community and it pisses them off.

If Mesa were smart, they'd be courting it more seeing as there isn't a damn bit of AMD help without it.

[Daktyl198]

Please forgive my ignorance, but If there is really going to be an OpenGL-Next, will it be prudent to pour resources into redoing the compiler when they may need to do it again for OpenGL-Next? Or might they attempt to ensure that the new compiler will work well with OpenGL-Next, too?

That's actually a good point. Would it not be better to use LLVM then, since it's a fairly generic IR, instead of using an OpenGL specific IR that may have to be completely rewritten/replaced when OpenGL-Next is announced instead of just slightly altered (in the case of LLVM usage).
Overall, actually, it seems like using LLVM would be "Lots of work now, much less work later down the road" compared to NIR or anything else.

Or am I talking out of my ass?

[jrch2k8]

That's actually a good point. Would it not be better to use LLVM then, since it's a fairly generic IR, instead of using an OpenGL specific IR that may have to be completely rewritten/replaced when OpenGL-Next is announced instead of just slightly altered (in the case of LLVM usage).
Overall, actually, it seems like using LLVM would be "Lots of work now, much less work later down the road" compared to NIR or anything else.

Or am I talking out of my ass?

well, i agreed with intel PoV the first time they reject the LLVM possibility, you know llvm 2.X wasn't that hot, tom stellard was talking crazy about using llvm for opencl and radeonsi was still an idea in mesa mailing list but today i believe they should seriously try again and move to gallium+llvm, i believe AMD has proven both are quite viable in hardware several times more complex than intel's with just 3 LLVM developers. I firmly believe with intel's man power all remaining rough edges in LLVM GPU support can be solved quite fast.

Additionally if intel will make that change and use LLVM mesa devs can nuke a massive chunk of dri mesa crudge out of tree and they could reuse a lot of code in gallium state trackers instead of reinventing the wheel over and over again with external libraries(va-vdapu, omx-va, clover-beignet, nine, openvg, etc.)

And maybe an idea to an student with enough time, why not add glsl/hlsl support as a language directly on LLVM and reuse internally the backends for compilation sake, for example:

program -> mesa -> gallium -> TGSI ->LLVM -> backend ->

shader -> mesa -> LLVM -> backend ->

i know is more complex, so just poking any interested there XD

[mattst88]

Please forgive my ignorance, but If there is really going to be an OpenGL-Next, will it be prudent to pour resources into redoing the compiler when they may need to do it again for OpenGL-Next? Or might they attempt to ensure that the new compiler will work well with OpenGL-Next, too?

We're aware of what the future holds...

I find this rather ironic, as Intel won't shut up about pushing OpenMP into LLVM/Clang, and wonders how come the interest is minimal. Sorry, but Intel is a gnat in the LLVM/Clang community and it pisses them off.

If Mesa were smart, they'd be courting it more seeing as there isn't a damn bit of AMD help without it.

I can't actually parse all of your message, but it seems like typical trolling.

I always find it interesting to hear about what "Intel" thinks, as if it's some collective entity with a single opinion. Everyone on the graphics team doesn't even share the same opinion.

That's actually a good point. Would it not be better to use LLVM then, since it's a fairly generic IR, instead of using an OpenGL specific IR that may have to be completely rewritten/replaced when OpenGL-Next is announced instead of just slightly altered (in the case of LLVM usage).
Overall, actually, it seems like using LLVM would be "Lots of work now, much less work later down the road" compared to NIR or anything else.

GLSL is a specialized graphics language with all sorts of special purpose functions. Why would one expect a "generic IR" to be better suited? The number of intrinsics in the document Jose linked gives a good idea of the scope.

The problem isn't about the amount of work either. There are a lot of technical problems to work through by using LLVM and the wonderful future of ponies and rainbows isn't assured.

Or am I talking out of my ass?

More or less. Sorry.



Opinions my own. Not Intel's.

[robclark]

Please forgive my ignorance, but If there is really going to be an OpenGL-Next, will it be prudent to pour resources into redoing the compiler when they may need to do it again for OpenGL-Next? Or might they attempt to ensure that the new compiler will work well with OpenGL-Next, too?

Well, whatever happens, I expect OpenGL will be around for quite some time. And in both cases drivers still need a compiler infrastructure. So I don't think OpenGL-next really changes anything here.

[sdack]

I think I can understand Intel. LLVM used to be an acronym, which stood for "Low-Level Virtual Machine", but now they have actually abandoned it as an acronym and only want LLVM to be known as its sole name. It is now just LLVM and shall have no connection to its past.

This alone I find is a weird move by the LLVM people. Their project has gained a lot of publicity, but nobody seems to be steering it and it just sprouts out to wherever it wants to, which means nobody knows where it is heading towards, what its goals are or what it tries to be (other than being an "umbrella" for all sorts of compiler-related stuff). Not to mention the issue people have with their license (see R.M. Stallman's comments on it).

That the name LLVM pops up here and there does not really surprise. When it is hard to tell what it is will some people always try to make it stick to something. Others will see an unlimited amount of potential in it, while the same could be said about the endless vacuum of space, too.

It is probably the worst kind of a project a corporation and money-making business such as Intel wants to invest into.

[sthalik]

That swizzle aliasing thing that they talk about here <http://lists.freedesktop.org/archives/mesa-dev/2014-August/066279.html> reminds of x86 aliasing of legacy registers with eax, etc. Doesn't LLVM already have infrastructure for that?

[smitty3268]

The problem isn't about the amount of work either. There are a lot of technical problems to work through by using LLVM and the wonderful future of ponies and rainbows isn't assured.

I don't really see any technical problems that haven't been resolved, or at least not many. The real blocker seems to be process/packaging issues.

It's insane to link to upstream LLVM the way the radeonsi drivers do. The only correct way to do things is to import LLVM into Mesa, do any custom work locally, and merge from upstream every so often.

And Intel seems to be of the opinion that would be a boatload of work... I suppose AMD does too, since they chose not to do things that way.