AMDKFD GPUVM Support Updated For Radeon Discrete GPUs

[aufkrawall]

On Arch, you can simply install opencl-amd from the AUR, works with newest mainline kernel (e.g. folding@home works here on Polaris).

[phred14]

AMDKFD is not about openCL support. It is HSA

HSA in extreme simplification means, that there is no need of data transfer form CPU RAM into GPU RAM and vice versa.

The result is speedup as of

https://img.purch.com/w/600/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS9LL00vNDQ2NTY2L29yaWdpbmFsLzEwLUxpYnJlT2ZmaWNlLUhTQS5wbmc=

form

http://www.tomshardware.com/reviews/amd-a10-7800-kaveri-apu-efficiency,3899-5.html

where execution of same code on the CPU lasts 855.4% time of HSA code execution and pure openCL code runs 643.5% of execution time for HSA code
but it only runs on APUs at least for open source driver.

AMDKFD enables HSA (GPU's capability of read form CPU RAM) for discrete AMD GPUs

All true. However in the closer term, I want to just enable the "opencl" USE flag in Gentoo and see a performance boost. I agree that it won't be as good as native HSA, but simply finding much in the way of native HSA applications is not likely to happen any time soon. A better job of OpenCL-on-HSA will show more benefit, sooner. It's a bit like "WinOS2" in the old days, where the better WinOS2 applications worked, the less the pressure for native OS/2 applications. In this case perhaps the better course would be to help define future OpenCL features to be able to better take advantage of HSA, if present. Then eventually you may get HSA in every respect except name. But you'd still have a compelling hardware sales feature.

[bridgman]

OpenCL on ROCM is just another ROC application - it can't come much earlier than the rest of the stack unfortunately.

On the other hand once the kernel bits are upstream the rest is already in place.

[pete910]

On Arch, you can simply install opencl-amd from the AUR, works with newest mainline kernel (e.g. folding@home works here on Polaris).

Don't work on vega cards though.