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

[curaga]

ROFL, that is not a LLVM bug you genius...

Sire, the r600 backend has been merged for a long time now. So bugs in it are LLVM bugs.

[makomk]

Oh joy. I'm still suffering from the after-effects of Intel deciding to rewrite the GLSL compiler and breaking stuff that never got fixed (and why would it - it's not like anyone runs anything graphically-intensive on Intel GPUs). Wonder what this will break.

[0xBADCODE]

ROFL, that is not a LLVM bug you genius...

Unless I messed something up, this messasge comes from LLVM. Hence it seems to be LLVM bug.

But keep on with you holy mission to spread FUD about LLVM.

There is no mission to "spread FUD". But now we have some third-rate library which is a real headache and that's sad state of things I do not like.

And then I filed bug almost a week ago. And then - guess what - nobody appeared in bug tracker to even adequately triage new bug. This makes bug tracker to feel a bit like desert. Then, LLVM supports AMD backend, but bug tracker totally lacks appropriate settings so there is no even good way to specify its AMD-specific bug. TBH all this is very well below of my understending how quality software supposed to look like.

[przemoli]

Using LLVM is one thing.

Using llvm Intermediate Representation is different.

1) How usefull will it be for OpenCL?
2) How usefull will it be for Compute?
3) How usefull will it be for SPIR (OpenCL IR)?
4) How usefull will it be for OpenGL NG?
5) Ho usefull would it be for other APIs supported by Mesa?



LLVM generate code. And that generation capability may not be easily utilized for some archs (Intel GEN).

But why not use LLVM IR?

Its mature enough so that even Khronos is OK with using it (for OpenCL).

[mattst88]

Oh joy. I'm still suffering from the after-effects of Intel deciding to rewrite the GLSL compiler and breaking stuff that never got fixed (and why would it - it's not like anyone runs anything graphically-intensive on Intel GPUs). Wonder what this will break.

I wish people like you wouldn't use the software I write.

But more on point... seriously? The new GLSL compiler was merged in 2010.

[pasaulais]

Using LLVM is one thing.

Using llvm Intermediate Representation is different.

1) How usefull will it be for OpenCL?
2) How usefull will it be for Compute?
3) How usefull will it be for SPIR (OpenCL IR)?
4) How usefull will it be for OpenGL NG?
5) Ho usefull would it be for other APIs supported by Mesa?



LLVM generate code. And that generation capability may not be easily utilized for some archs (Intel GEN).

But why not use LLVM IR?

Its mature enough so that even Khronos is OK with using it (for OpenCL).

Exactly, depending on the IR is not the same as depending on the compiler. You can implement the IR in Mesa without linking to or embedding LLVM itself.

I may be biased since I work on LLVM, but I think the tools to manipulate this IR are quite nice, and it is quite easy to modify it by hand too.

[sdack]

Using LLVM is one thing.

Using llvm Intermediate Representation is different.

1) How usefull will it be for OpenCL?
2) How usefull will it be for Compute?
3) How usefull will it be for SPIR (OpenCL IR)?
4) How usefull will it be for OpenGL NG?
5) Ho usefull would it be for other APIs supported by Mesa?

Well, LLVM's IR is just like others with one outstanding feature: it is SSA-based right from the start. You do not first have to transform an IR into SSA form to optimize it, when the IR itself is the SSA form. Other (older) IRs only try to find the most common representation suitable to all front-ends. An SSA-based IR goes further and aims at providing the best optimization. It is just good forward-thinking if you so will.

It does not need to be LLVM's IR, but it is SSA, which matters and for which many optimization algorithms exist (you can find these algorithms in LLVM as well as GCC for example). Using LLVM's IR simply makes these algorithms available without having to implement them yourself. If you actually want to use all available algorithms is a different matter (you probably will in the future), but you could develop your own SSA-based IR and only implement the algorithms, which you need and be free from all the rest that comes with LLVM.

[log0]

Fresh from the mailing list:

Thomas asked for performance numbers. There are many different domains
in which performance can be measured (timedemos, frame looping,
scheduler clock estimates, shader_time logging, etc). We found some
areas of the i965 backend which needed improvement, so our performance
numbers include both LunarGlass and backend changes. However, even
before we made i965 BE changes, we saw improvements from the FE/ME
replacement alone. Our overall (ME+BE changes) timedemo results are in
the range of 0-14% for several major AAA titles (i.e, no performance
regressions that I've seen, and multiple progressions). Note that those
numbers are through actual applications, so exist in a complex
environment of other performance factors such as mixtures of light and
heavyweight frames, other bottlenecks, and so forth.

So the LLVM version is already faster than the intel driver alone. After what, 2-3 months work?

But yeah, LLVM is obviously an utter broken pile of shit, that everyone should avoid at all costs.

[log0]

Sire, the r600 backend has been merged for a long time now. So bugs in it are LLVM bugs.

So the GPU hanging/crashing because the backend fails to compile a kernel (due to whatever missing functionality) is a LLVM bug and shows how much LLVM sucks right?

From my point of view the driver shouldn't attempt to run that kernel in the first place. But what do I know.

[log0]

Unless I messed something up, this messasge comes from LLVM. Hence it seems to be LLVM bug.


There is no mission to "spread FUD". But now we have some third-rate library which is a real headache and that's sad state of things I do not like.

And then I filed bug almost a week ago. And then - guess what - nobody appeared in bug tracker to even adequately triage new bug. This makes bug tracker to feel a bit like desert. Then, LLVM supports AMD backend, but bug tracker totally lacks appropriate settings so there is no even good way to specify its AMD-specific bug. TBH all this is very well below of my understending how quality software supposed to look like.

This was the first line and the header for your little rant:

IMO LLVM just suxx.

Not amd mesa driver sucks or radeonsi sucks or amd open source opencl support sucks...