It's Going To Take More Time To Get Vega Compute Support With The Mainline Kernel

[phoronix]

Phoronix: It's Going To Take More Time To Get Vega Compute Support With The Mainline Kernel

This weekend I wrote how the AMDKFD discrete GPU support should be in place for the next kernel cycle, Linux 4.17. This is going to allow discrete Radeon GPUs to have ROCm working off the mainline kernel for OpenCL/compute support, but for 4.17 it's unlikely RX Vega GPUs will have compute working...

http://www.phoronix.com/scan.php?page=news_item&px=Vega-Mainline-Compute-State

[uentity]

It's a pity that we have another delay in proper OpenCL support for Vega.
Right now I have close to zero OpenCL capabilities on my Vega 64 GPU, because my AMD FX 8120 GPU doesn't support PCIe atomics required for ROCm stack, and AMDGPUpro 'legacy' OpenCL dirver do not support Vega from the beginning.

[Guest]

It's a pity that we have another delay in proper OpenCL support for Vega.
Right now I have close to zero OpenCL capabilities on my Vega 64 GPU, because my AMD FX 8120 GPU doesn't support PCIe atomics required for ROCm stack, and AMDGPUpro 'legacy' OpenCL dirver do not support Vega from the beginning.

Sucks... Buy xeon Phi

[Meteorhead]

Indeed. The Linux driver landscape of AMD seems worse than ever. There are too many stacks to maintain and no uniform place to hook both compute and graphics into.

Out of curiosity: we're acquiring ASUS ESC8000 G3 or G4 host machines (depending on how the grant goes) and many things will be run on it regardless of the answer, but: if I would like to have SYCL-GL interop through ComputeCpp. will there be ANY driver stack installable on Ubuntu Server 18.04 LTS that will be capable of pulling that off? Have SPIR & SPIR-V compute support AND OpenGL 3.3+, perhaps 4.3? Or the last time in history these two features coexisted was with fglrx?

The computation at hand would be multi-GPU lattice calculation of volumetric density distribution, each rendering their own view of the simulated data, and after would come a Z-order alpha-blend of the images. I'd need OpenGL-SYCL interop with the ability to capture Z-buffer via SYCL.

[gnarlin]

While the AMD drivers have improved immensely the last year or two why is it that they never seem to be able to reach a feature complete state? There is no major feature still missing from the windows versions is there? When will the only new code be optimizations and/or support for new hardware?

[pal666]

Right now I have close to zero OpenCL capabilities on my Vega 64 GPU, because my AMD FX 8120 GPU doesn't support PCIe atomics required for ROCm stack

you are lucky one. you can upgrade your cpu. imagine if you had ryzen, but no vega

[pal666]

While the AMD drivers have improved immensely the last year or two why is it that they never seem to be able to reach a feature complete state? There is no major feature still missing from the windows versions is there?

windows drivers have 100 times more customers, i.e. 100 times more funding

[ThoreauHD]

What a bunch of lazy assholes. What are people supposed to do with AMD on Linux? They've sold out of every damned GPU and chip they got. You'd think they could bother to hire more than 1 developer without a fucking timeline. This is bordering on operational negligence.

[schmidtbag]

Indeed. The Linux driver landscape of AMD seems worse than ever. There are too many stacks to maintain and no uniform place to hook both compute and graphics into.

Well, they're not all that related. To my understanding, OpenGL does not share many similarities to OpenCL, just as it doesn't share many similarities with Vulkan. As far as I'm aware, having a "uniform place" would not improve anything. If anything, it would slow down development, since you have to consider regressions and following a single release schedule rather than multiple independent ones.

My personal gripe is how we have multiple driver options and none of them are unanimously better than the others. For example, OpenGL with radeonsi/amdgpu/amdgpu-pro, or Vulkan with RADV/amdgpu-pro, or OpenCL ROCm/amdgpu-pro. I understand that a lot of this is just a transition of closed source to open source, but this is where I find there is too much divided attention. I know there are different teams who work on this, but I think progress could be made faster if some of these developers all worked together on the same project.

[bridgman]

It's a pity that we have another delay in proper OpenCL support for Vega. Right now I have close to zero OpenCL capabilities on my Vega 64 GPU, because my AMD FX 8120 GPU doesn't support PCIe atomics required for ROCm stack, and AMDGPUpro 'legacy' OpenCL dirver do not support Vega from the beginning.

We are working on a separate solution for OpenCL without PCIE atomics - with a bit of luck it will hit the next (18.10) release.