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...
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.
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.
Originally Posted by HokTar
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!
Originally Posted by tstellar