Results 1 to 5 of 5

Thread: R600 LLVM Back-End Gets Indirect Addressing Support

  1. #1
    Join Date
    Jan 2007
    Posts
    15,181

    Default R600 LLVM Back-End Gets Indirect Addressing Support

    Phoronix: R600 LLVM Back-End Gets Indirect Addressing Support

    The open-source Radeon R600 LLVM back-end has finally received support for indirect memory addressing...

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

  2. #2
    Join Date
    May 2011
    Posts
    35

    Default

    It's not really clear from my mailing list message or the article, but the indirect addressing support is currently for compute only. The TGSI->LLVM implementation for r600g and radeonsi does not translate indirect addressing yet, so that would need to be done before indirect addressing will work for graphics. In addition, the indirect addressing support in the backend is not really suitable for graphics, because it only supports a maximum of 16 dwords for indirect addressing, which is not really enough for most graphics shaders, especially since with TGSI one must assume that all registers might potential be accessed via indirect addressing.

    My priority now is to improve compute support in the compiler, I don't have any near term plans to work on indirect addressing for r600g graphics shaders. However, the TGSI->LLVM piece will likely be implemented when indirect addressing support is added to radeonsi.

  3. #3
    Join Date
    Dec 2009
    Posts
    338

    Default

    @tstellar:

    Could you please give us an update on OpenCL with r600g in general?
    How far are you from a fully functional implementation, what needs to be still done, when do you expect a "1.0" release, etc. Maybe you are not yet this far, then please simplify/scale down my questions!
    I'm really curious when I'll be able to run Einstein@Home on my GPU (aruba, so r600g)?

    Thanks a lot in advance!

  4. #4
    Join Date
    May 2011
    Posts
    35

    Default

    Quote Originally Posted by HokTar View Post
    @tstellar:

    Could you please give us an update on OpenCL with r600g in general?
    How far are you from a fully functional implementation, what needs to be still done, when do you expect a "1.0" release, etc. Maybe you are not yet this far, then please simplify/scale down my questions!
    I'm really curious when I'll be able to run Einstein@Home on my GPU (aruba, so r600g)?

    Thanks a lot in advance!
    Unfortunately Aruba is not supported as well as the other Northern Islands GPUs, and I haven't done much testing on it, so it's hard for me to say how well things will work with it. I have a limited number of real applications to test with (basically the Gegl library and the Phoronix OpenCL tests), so if you are interested in getting Einstein@Home to work, try it out with the Open Source driver and then file a bug with any problems you discover.

    For a general update on OpenCL and r600g, I would say that things have been improving a lot over the last few months. The biggest deficiency at this point is missing builtin implementations in the libclc library. This is the main reason that most programs crash. As the libclc implementation becomes more complete it should expand the number of programs that clover/r600g can run and make it a little clearer what is and isn't supported.

    I'm not really sure when to expect a "1.0" release, it really depends a lot on how many other community members get involved.

  5. #5
    Join Date
    Dec 2009
    Posts
    338

    Default

    Quote Originally Posted by tstellar View Post
    Unfortunately Aruba is not supported as well as the other Northern Islands GPUs, and I haven't done much testing on it, so it's hard for me to say how well things will work with it. I have a limited number of real applications to test with (basically the Gegl library and the Phoronix OpenCL tests), so if you are interested in getting Einstein@Home to work, try it out with the Open Source driver and then file a bug with any problems you discover.

    For a general update on OpenCL and r600g, I would say that things have been improving a lot over the last few months. The biggest deficiency at this point is missing builtin implementations in the libclc library. This is the main reason that most programs crash. As the libclc implementation becomes more complete it should expand the number of programs that clover/r600g can run and make it a little clearer what is and isn't supported.

    I'm not really sure when to expect a "1.0" release, it really depends a lot on how many other community members get involved.
    Thanks for the update, I might try to run E@H in the near future!

Posting Permissions

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