Announcement

Collapse
No announcement yet.

R600 Gallium3D Disables LLVM Back-End By Default

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic R600 Gallium3D Disables LLVM Back-End By Default

    R600 Gallium3D Disables LLVM Back-End By Default

    Phoronix: R600 Gallium3D Disables LLVM Back-End By Default

    AMD has decided to disable the LLVM compiler back-end by default within the R600 era Gallium3D graphics driver...

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

  • marek
    replied
    Originally posted by vadimg View Post
    Honestly, I don't like to push my solutions, so if no one wants it, I don't care.
    People want it, but most people are not GPU driver developers (or don't want to be). And those who are are too busy with other stuff.

    Leave a comment:


  • mannerov
    replied
    If llvm backend is buggy and slower for r600, then it's ok to me to hide this backend to users.

    About the radeonsi llvm backend, do we have information about its optimality? Would radeonsi benefit from a new sb backend?

    Leave a comment:


  • _SXX_
    replied
    Originally posted by liam View Post
    However I want aware that the reason for removing it was basically one of shifting of resources rather than inherent problems with llvm itself.
    They didn't "remove" it, but make ability to have it compiled within Mesa while disabled by default. Actually it's pretty good thing; before I have to always re-compile Mesa manually if I want to use it because nobody at all have it enabled in builds.

    Now Oibaf PPA provide builds with LLVM backend so possible more people will actually able to test it without pain in ass.
    Last edited by _SXX_; 04-19-2014, 08:35 PM.

    Leave a comment:


  • liam
    replied
    Originally posted by smitty3268 View Post
    This has nothing to do with llvmpipe, or even radeonSI.

    It's about the r600 backend inside llvm, which isn't as good as the compiler and sb optimizer inside mesa's r600g driver. Nothing else.

    And the reason it's not is because no one is really working on it - everyone on the llvm side is busy getting OpenCL and the radeonSI driver working. Nobody cares about getting it working for r600g because that driver already works without it.
    My point was about llvm in general, hence why I asked about llvmpipe and its future. I was aware of vadim's sb alternative, so llvm wasn't necessary for anything other than opencl. However I want aware that the reason for removing it was basically one of shifting of resources rather than inherent problems with llvm itself.
    Last edited by liam; 04-19-2014, 02:38 PM. Reason: Correction

    Leave a comment:


  • vadimg
    replied
    Originally posted by marek View Post
    In the long term, it doesn't make sense to use both LLVM and SB backends together, thus the option is not even considered. Both of them do a similar set of optimizations, and most importantly, the latter backend reverses the effect of some optimizations done by the former backend, so a lot of time spent in LLVM is for nothing.
    Honestly, this option probably makes sense for the apps that hit register allocation issues with stock backend. LLVM can solve some issues of that kind. On the other hand, I really hoped that LLVM backend will get enough attention and will become the main backend in the end. Now it looks like it's abandoned. That's a bit unexpected for me.
    I'm still considering support of SB, adding geometry shaders etc, but I really have no time. Anyway I tried hard to warn about it before upstreaming it. But I think it still works in most of the cases and improves performance, and it's exactly what people want.
    FWIW, in some tests LLVM may improve the performance, but in most tests LLVM made the code less optimizable just because some heuristics in SB were tuned for the stock backend, and LLVM was hiding the optimization opportunities. There were also other LLVM codegen problems that resulted in asserts in SB because SB checks correctness of the source code. Anyway. I always suggested not to use LLVM with SB because it was less tested and less stable.
    There is a branch in my repo that solved register allocation issues with SB by removing stock r600 backend from the equation and introducing direct translator from TGSI to SB, but no one was interested enough:
    http://cgit.freedesktop.org/~vadimg/...?h=wip-sb-tgsi
    It may be updated to replace the default backend with minimal efforts (well, geometry shaders will need some work).

    Honestly, I don't like to push my solutions, so if no one wants it, I don't care.
    1) I'll try to improve it to support geom shaders etc, but if no one else is interested... I've switched to SI card for gaming etc, so I'm not very interested in working on R600.
    2) If anyone is interested to support it, I'll be happy to provide all the help I can.
    3) supporting a backend for 4 generations of R600 cards was a huge trouble, because I had only one card. Great thanks to the people from all over the world, they tested it and sent me debug reports, tested the patches and sent me the logs again, and so on. But making it work with all chips took more time than initial implementation. I simply have no time right now to test and fix anyt improvements for all other cards. I'm not AMD.
    4) people are asking me about the backend for SI. I believe LLVM compiler works a lot better for SI than it was for R600 VLIW architecture, that's why I'm not really sure if custom compiler may help with newer cards. I'll probably look into it if I'll have time and if it will be obvious that SI compiler is not very efficient, but so far it's not the case.
    5) the apps that are failing due to register allocation issues with SB are mostly not optimized at all. AAA apps are working fine, but some crazy shaders in crazy apps are failing because they are really crazy. Please ask game developers to optimize them. I can help if it's needed, so feel free to give them my email.

    Leave a comment:


  • Ericg
    replied
    Originally posted by agd5f View Post
    Try updating your version of mesa. I think you need 10.1 and llvm 3.4 for OpenGL 3.1 support on radeonsi. For OpenGL 3.3 support you need mesa from git and llvm 3.5.
    Okay, I was just curious. All the proper parts should be coming in within a couple weeks so i'll retest thing. Thanks for the response.

    Leave a comment:


  • V10lator
    replied
    Originally posted by Ericg View Post
    LLVM 3.3.4
    I know I'm not Alex, but I think you need a higher LLVM version (maybe a higher Mesa version, like 10.2-devel may help, too. With both up2date you should get OpenGL 3.3).

    //EDIT: Alex was faster than me.

    Leave a comment:


  • agd5f
    replied
    Originally posted by Ericg View Post
    Vendor was listed as AMD Kaveri, direct rendering was yes. Like nothing shouted "Youre on software rendering!" but I would've expected at least OpenGL 3.1 to be listed, not 2.1.
    Try updating your version of mesa. I think you need 10.1 and llvm 3.4 for OpenGL 3.1 support on radeonsi. For OpenGL 3.3 support you need mesa from git and llvm 3.5.

    Leave a comment:


  • Ericg
    replied
    Originally posted by agd5f View Post
    For SI and up LLVM.
    For R600, LLVM for OpenCL, build in compiler for OpenGL.
    Hey Alex, totally unrelated to the LLVM topic but I wanted to catch you while I could...


    Last night my 7850K came and I was playing around with it on a Fedora 20 x64 hard drive and I noticed something possibly odd. In actually released code, what version of OpenGL should RadeonSI be up to?

    Latest Fedora 20 updates are:

    Mesa 10.0.4
    LLVM 3.3.4
    Kernel 3.13.10
    X Server 1.14.4

    glxinfo 1) Crashed X & kwin, and 2) reported GLSL 1.30 or 1.50 I forget which, but also reported OpenGL 2.1

    Vendor was listed as AMD Kaveri, direct rendering was yes. Like nothing shouted "Youre on software rendering!" but I would've expected at least OpenGL 3.1 to be listed, not 2.1.

    Later that night I wiped the drive to test out windows (Sorry >.> It was my only spare drive) but does that seem "right" to you?

    Leave a comment:

Working...
X