Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 34

Thread: R600 Gallium3D Disables LLVM Back-End By Default

  1. #11
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by 89c51 View Post
    Does this also mean that r600 will never get FOSS OpenCL ?? (when and if ready)
    No it does not. The LLVM work on VLIW was originally intended for compute paths only, not graphics paths, but Tom was using graphics paths to test the new compiler code before an OpenCL framework was available. The results (graphics + llvm + VLIW) looked sufficiently promising to pursue further. Compute paths would continue to use llvm AFAIK.

  2. #12
    Join Date
    Dec 2007
    Posts
    2,395

    Default

    Quote Originally Posted by edoantonioco View Post
    Does this means less performance? And are we talking about mesa 10.2?, because its not explained.
    It won't affect performance. llvm has never been enabled by default in r600g. The llvm support in r600g was only originally intended to support OpenCL, it was just enabled optionally for OpenGL for testing purposes, but it never got full support for a lot of the features required for OpenGL. What this patch does is disable OpenGL llvm support by default when it's enabled in the driver.

  3. #13
    Join Date
    Jan 2009
    Posts
    625

    Default

    As far as I remember, the LLVM backend has always been slower on R600 since Vadim's backend was merged. Why people think LLVM should be faster is a mystery to me.

  4. #14
    Join Date
    Apr 2013
    Posts
    131

    Default

    Some time ago in mesa 9.2 there was a new feature (the r600 back-end) that bring better performance, but it was disabled by default (enabled by default in 10.0). I activate that feature with
    R600_DEBUG=sb,nollvm
    and the performance was better, but if I did this
    R600_DEBUG=sb
    the performance was even better.
    That means than the LLVM stuff meant more performance. Thats why I was curious about how the performance would be affected now than the feature is going to be disabled.

  5. #15
    Join Date
    Jan 2009
    Posts
    1,435

    Default

    Does this mean we shouldn't expect llvmpipe to reach parity with the hardware drivers for some time? Is the reason for these features not being implemented because of an issue with upstream, with the current implementation of llvm, or with the codebase?

  6. #16
    Join Date
    Oct 2008
    Posts
    3,173

    Default

    Quote Originally Posted by liam View Post
    Does this mean we shouldn't expect llvmpipe to reach parity with the hardware drivers for some time? Is the reason for these features not being implemented because of an issue with upstream, with the current implementation of llvm, or with the codebase?
    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.
    Last edited by smitty3268; 04-18-2014 at 02:16 AM.

  7. #17
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,911

    Default

    Quote Originally Posted by marek View Post
    Why people think LLVM should be faster is a mystery to me.
    I think its more along the lines of people think LLVM should be faster eventually and could be made to be faster. LLVM brings to the table quick compilation, ontop of a full compiler that can be optimized to be very platform specific. With at least a chance of getting free performance bumps from optimizations made to other parts of LLVM.

    Contrastly Vadim's work, while VERY appreciated and applauded, is a compiler that was written by one person for one task and currently receives an unknown amount of attention and optimization. Meanwhile the development effort on LLVM is known.

    Also there's the issue of LLVM's expanding usage in many things and the assumption that comes with that growth that LLVM would be flexible enough to handle anything and everything, including graphics shader work.

  8. #18
    Join Date
    Jan 2013
    Posts
    1,458

    Default

    Quote Originally Posted by Ericg View Post
    I think its more along the lines of people think LLVM should be faster eventually
    Faster than what?

  9. #19
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,911

    Default

    Quote Originally Posted by dee. View Post
    Faster than what?
    Vadim's sb compiler

  10. #20
    Join Date
    Oct 2008
    Posts
    3,173

    Default

    Quote Originally Posted by Ericg View Post
    I think its more along the lines of people think LLVM should be faster eventually and could be made to be faster. LLVM brings to the table quick compilation, ontop of a full compiler that can be optimized to be very platform specific. With at least a chance of getting free performance bumps from optimizations made to other parts of LLVM.

    Contrastly Vadim's work, while VERY appreciated and applauded, is a compiler that was written by one person for one task and currently receives an unknown amount of attention and optimization. Meanwhile the development effort on LLVM is known.

    Also there's the issue of LLVM's expanding usage in many things and the assumption that comes with that growth that LLVM would be flexible enough to handle anything and everything, including graphics shader work.
    I don't think most people really give it that much thought. LLVM has become a buzzword. People see it and automatically think it must be better.

    Also, there's the whole thing of having the SI driver use it. People think if the newer driver is requiring it, there has to be a good reason they went that way, and in the realm of 3d drivers that often equates to better performance.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •