AMD Will Continue Maintaining Multiple Compute Stacks For Linux

[phoronix]

Phoronix: AMD Will Continue Maintaining Multiple Compute Stacks For Linux

With the great shape that ROCm has been getting into recently for open-source Radeon GPU compute support on Linux including advancing OpenCL support, one might have rightfully assumed that was going to be their centralized compute stack moving forward. It turns out that their PAL-based compute stack will continue to be maintained too...

http://www.phoronix.com/scan.php?page=news_item&px=ROCm-PAL-Future

[juno]

The remaining question is whether the PAL based driver will be open sourced and run on the already open sourced version of PAL so that packagers of all distributions could finally supply decent opencl packages for all amd GPUs and end users stop relying on amd provided packages

[Meteorhead]

How does this translate to Windows users? Given how ROCm is targeted to gain Windows support, the same argument should be made on Windows as well, but with different names.

I take it that the DRM of Windows is WDDM, but how does the HSA runtime integrate with the system? Does it circumvent WDDM for compute tasks? Will we still have one installer that installs both the PAL and ROCm stack when it hits Windows? Does that mean that 'pure' compute contexts (a regular OpenCL context per say) will be ROCm and when I ask for graphics interop within the context, then a PAL instance will be spun up?

I'm just curious how all this translates to me, given my devbox is Windows, but my target is Linux cluster, which I am also a sysadmin of. (Using ISO C++, MPI, OpenMP, OpenCL, OpenGL, SYCL, etc... all portable stuff. Oh, and I'm loving WSL! Makes my life a whole lot easier.)

[Meteorhead]

The remaining question is whether the PAL based driver will be open sourced and run on the already open sourced version of PAL so that packagers of all distributions could finally supply decent opencl packages for all amd GPUs and end users stop relying on amd provided packages

Excellent question! +1

[darkbasic]

Can you please point me to the source code for the PAL OpenCL driver? Can I run it with the HD 7950?

[RussianNeuroMancer]

So seems like maintain additional codepatch turns out be easier than make all Radeons HSA-compliant. Which is, honestly, very sad. But I guess now we can confidently say that HSA doesn't gain traction from other vendors besides AMD so PAL OpenCL implementation that cover broad range of hardware is surely welcome.

If I mistake somewhere, please proof me wrong.

[TemplarGR]

So seems like maintain additional codepatch turns out be easier than make all Radeons HSA-compliant. Which is, honestly, very sad. But I guess now we can confidently say that HSA doesn't gain traction from other vendors besides AMD so PAL OpenGL implementation that cover broad range of hardware is surely welcome.

If I mistake somewhere, please proof me wrong.

The part you are wrong is that HSA is hardware-reliant, not just driver-reliant. So yes, they can't make all radeon architectures HSA compliant because they lack specific hardware functions.

Other than that, i hope Mr Bridgman and company will provide us non ROCm compatible users with a nice traditional OpenCL solution, sometime in the future. I own an FX6300 (thus no pcie atomics) and a Tonga gpu and would like to have the option to run some decent OpenCL on my gpu. My next upgrade won't happen before 7nm AMD products because i am satisfied with my current desktop performance, so any OpenCL would be welcome in the meantime... Clover is so unfinished it hurts.

[boxie]

So seems like maintain additional codepatch turns out be easier than make all Radeons HSA-compliant. Which is, honestly, very sad. But I guess now we can confidently say that HSA doesn't gain traction from other vendors besides AMD so PAL OpenGL implementation that cover broad range of hardware is surely welcome.

If I mistake somewhere, please proof me wrong.

I would argue that the higher end products have the silicon budget to implement the required things for ROCm, whereas the lower end products do not.

Without knowing where the line is for PAL only we can only guess.

[boxie]

The part you are wrong is that HSA is hardware-reliant, not just driver-reliant. So yes, they can't make all radeon architectures HSA compliant because they lack specific hardware functions.

Other than that, i hope Mr Bridgman and company will provide us non ROCm compatible users with a nice traditional OpenCL solution, sometime in the future. I own an FX6300 (thus no pcie atomics) and a Tonga gpu and would like to have the option to run some decent OpenCL on my gpu. My next upgrade won't happen before 7nm AMD products because i am satisfied with my current desktop performance, so any OpenCL would be welcome in the meantime... Clover is so unfinished it hurts.

you might have to make use of the PAL OpenCL implementation via the AMDGPU-PRO driver

[pmarcelll]

When HSA was announced, the big problem was that nobody had the proper hardware for it, not even AMD. And now, when Raven Ridge is fully HSA compliant (correct me if I'm wrong), AMD only focuses on the high end GPUs on the software side. I understand that they finally managed to move on from 28nm and Zen is very good, so there's no real pressure to pursue the "HSA APU dream", but when we can't shrink chips further (probably in 5+ years), it will probably be one of the best ways to increase the performance of a processor. I just hope AMD will have enough money to be able to experiment freely and create a futureproof solution (starting with hiring even more people for the compute stack).