Originally posted by log0
View Post
Announcement
Collapse
No announcement yet.
NIR Still Being Discussed For Mesa, LLVM Gets Brought Up Again
Collapse
X
-
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.
Comment
-
Originally posted by log0 View PostROFL, that is not a LLVM bug you genius...
But keep on with you holy mission to spread FUD about LLVM.
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.Last edited by 0xBADCODE; 29 August 2014, 06:32 AM.
Comment
-
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).
Comment
-
Originally posted by makomk View PostOh 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.
But more on point... seriously? The new GLSL compiler was merged in 2010.
Comment
-
Originally posted by przemoli View PostUsing 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).
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.
Comment
-
Originally posted by przemoli View PostUsing 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?
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.
Comment
-
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.
But yeah, LLVM is obviously an utter broken pile of shit, that everyone should avoid at all costs.Last edited by log0; 29 August 2014, 01:53 PM.
Comment
-
Originally posted by curaga View PostSire, the r600 backend has been merged for a long time now. So bugs in it are LLVM bugs.
From my point of view the driver shouldn't attempt to run that kernel in the first place. But what do I know.
Comment
-
Originally posted by 0xBADCODE View PostUnless 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.
IMO LLVM just suxx.
Comment
Comment