AMD Publishes Video To Explain The Radeon Open Compute Stack (ROCm)

[geearf]

Are you using it together with mesa? If yes, please tell us, how are you doing this. Cause, llvm can't be mixed in different versions. And ROCm is using some dev-version of llvm (llvm-11 at the moment) whereas mesa works with the latest released version of llvm (llvm-10 or llvm-9).

I don't know about ROCm, but Mesa only needs llvm-libs, and you can definitely install those in parallel. I currently have 10 and 11 installed (though my package for 11 does not seem to have as many files as the one for 10, so maybe it's not that easy).

[TemplarGR]

While CLover does not have the same scope (as a project) as ROCm, i agree that it should have been the ideal solution. I get that Bridgman says (and in some ways he is right) that since only AMD contributed to CLover, they saw no point and proceeded to do their own thing, but still in my opinion they should have at least kept CLover as their official open OpenCL implemantation and just let ROCm implement the other stuff around it. Right now there are 2 OpenCL open implemenations for AMD, both of them with issues. And one binary OpenCL implemantation that is not exactly perfect either. If 3rd party contributors manage to improve Clover in the near future (which might be the case seeing some companies pledging to contribute to it) then we might see the paradox of Clover being a better opensource OpenCL implementation on AMD cards than ROCm, without AMD's help....

In an ideal world, Intel would have adopted CLover as well, since it is pretty much Gallium Compute, and they have already adopted Gallium for OpenGL, so why not OpenCL? In an even more ideal world, Nvidia would have adopted Nouveau as well, so all 3 main vendors would contribute to CLover, making it the defacto standard implementation for OpenCL and ensuring perfect compatibility for everybody (since all OpenCL apps would ensure they work on Clover). Sadly we are not living in an ideal world.

[Venemo]

Vulkan doesn't do compute (for now).

Actually Vulkan supports compute. Here is an example: https://www.phoronix.com/scan.php?pa...e-Small-Sample

[illwieckz]

The code to grok OpenCL does not share code with the one groking OpenGL. You can't assume you can accelerate Darktable with OpenCL because your OpenGL game is rendered efficiently.

As long as you're using ROCm and not clover. The latter is mesa, but it's even in a much worse state than ROCm (in terms of features). But hey, at least it works together with the mesa graphics driver. I'm hoping, the OpenCL-efforts for nouveau will bring benefits for amdgpu too.

Clover lacks the OpenCL features required by Darktable. Maybe you can run some cryptocurrency job with clover, I don't know, but I never been able to make something with the OpenCL-based tools I use like darktable:

$ clinfo | sed -e 's/^ *//;s/ \+/\t/g' | grep 'Name' | sort -u | column -t -s "$(printf '\t')"
Device Name AMD Radeon (TM) R9 390 Series (HAWAII, DRM 3.35.0, 5.4.0-33-generic, LLVM 9.0.1)
ICD loader Name OpenCL ICD Loader
Platform Name Clover

$ darktable-cltest | egrep 'found|discarding|no suitable|FINALLY'
0.035284 [opencl_init] found opencl runtime library 'libOpenCL.so.1'
0.035303 [opencl_init] opencl library 'libOpenCL.so.1' found on your system and loaded
0.107821 [opencl_init] found 1 platform
0.107840 [opencl_init] found 1 device
0.107885 [opencl_init] discarding device 0 `AMD Radeon (TM) R9 390 Series (HAWAII, DRM 3.35.0, 5.4.0-33-generic, LLVM 9.0.1)' - The OpenCL driver doesn't provide image support. See also 'clinfo' output.
0.107888 [opencl_init] no suitable devices found.
0.107890 [opencl_init] FINALLY: opencl is NOT AVAILABLE on this system.

There is only two ways to get Darktable working with OpenCL with an AMD GPU on Linux: the ROCm stack if you have a supported GPU (mine is listed as “maybe” but does not work), or the proprietary stack from amdgpu-pro driver. You may need to get your hands dirty to get it working if you're not using a two years old LTS Ubuntu (and you may break your package manager if you don't follow the procedure correctly).

[Soul_keeper]

What the community needed was a project that supports every AMD card, GCN 1.0 and later, for all users.
A single unified build system ... bam installed for everyone ! All distros .... Sounds crazy to some, but that's the way most all gnu/linux open source projects are.
The longer it takes to see this the harder it'll be to implement as more and more cards/archs get released.
Sadly, i'm not hopefull. Although something is better than nothing.
Atleast kfd is native in the kernel for most everyone/everything now. Just sitting there waiting to be used someday.

[Soul_keeper]

While CLover does not have the same scope (as a project) as ROCm, i agree that it should have been the ideal solution. I get that Bridgman says (and in some ways he is right) that since only AMD contributed to CLover, they saw no point and proceeded to do their own thing, but still in my opinion they should have at least kept CLover as their official open OpenCL implemantation and just let ROCm implement the other stuff around it. Right now there are 2 OpenCL open implemenations for AMD, both of them with issues. And one binary OpenCL implemantation that is not exactly perfect either. If 3rd party contributors manage to improve Clover in the near future (which might be the case seeing some companies pledging to contribute to it) then we might see the paradox of Clover being a better opensource OpenCL implementation on AMD cards than ROCm, without AMD's help....

In an ideal world, Intel would have adopted CLover as well, since it is pretty much Gallium Compute, and they have already adopted Gallium for OpenGL, so why not OpenCL? In an even more ideal world, Nvidia would have adopted Nouveau as well, so all 3 main vendors would contribute to CLover, making it the defacto standard implementation for OpenCL and ensuring perfect compatibility for everybody (since all OpenCL apps would ensure they work on Clover). Sadly we are not living in an ideal world.

This is exactly my thoughts on the matter. Since OpenCL was first released I had envisioned industry standards and it being embraced by everyone.

[sp82]

Probably only way efficiently to use cross-platform compute anytime soon will be WebGPU and its "native" equivalent wgpu. I'm not bothering with ROCm at all. It's an utter mess.

WebGPU? what about Vulkan and SPIR-V they are awesome and really rocks!

[sp82]

Vulkan doesn't do compute (for now). And unlike Vulkan, or DX12, webgpu is supported by everyone including Apple, and therefore will be standard in browsers. It's the first api that we're likely to see implemented by everyone.

We can't compare WebGPU with ROCm, WebGPU as nothing to do with raw computing on desktop, it's for the web browsers. ROCm is the opposite, is for datacenter and HPC applications also not for desktop. The problem is that AMD can't care less to make rocm friendly on desktop and notebooks particularly. So most consumers and professional users on AMD desktop hardware on Linux have poor experience with this OpenCL implementation.
For me OpenCL for desktop usage as failed big. NVIDIA expose only opencl 1.2, I think, because the care only CUDA.
With the last release of Radeon Rays (a raytracing library) even AMD stop using opencl and start using Vulkan.
Software like Blender and Luxrender better start converting their opencl backend to SPIRV backend running on Vulkan. So they can support NVIDIA and AMD with a single implementation supporting multiple gpus even multiple vendors configuration without a problem thanks to Vulkan.

[vegabook]

We can't compare WebGPU with ROCm, WebGPU as nothing to do with raw computing on desktop, it's for the web browsers. ROCm is the opposite, is for datacenter and HPC applications also not for desktop. The problem is that AMD can't care less to make rocm friendly on desktop and notebooks particularly. So most consumers and professional users on AMD desktop hardware on Linux have poor experience with this OpenCL implementation.
For me OpenCL for desktop usage as failed big. NVIDIA expose only opencl 1.2, I think, because the care only CUDA.
With the last release of Radeon Rays (a raytracing library) even AMD stop using opencl and start using Vulkan.
Software like Blender and Luxrender better start converting their opencl backend to SPIRV backend running on Vulkan. So they can support NVIDIA and AMD with a single implementation supporting multiple gpus even multiple vendors configuration without a problem thanks to Vulkan.

actually it has everything to do with raw compute on the desktop. In the same way that most desktop apps are now electron-based, i entirely predict that the native version of webgpu, known as wgpu, will dominate compute as a target for application developers, web/electron and native. It'll talk down to Vulkan/DX12/Metal as appropriate, but will solve the absolute mess that is cross platform GPU targeting because the economic incentives for graphics card vendors will ensure that they MUST implement it since it will be a browser standard across all three major desktop OSs. So what if you lose 20 or 30% performance if you're getting 1-2 orders of magnitude in the first place. 15x - 30% is still 11.5x.

[vein]

Are you using it together with mesa? If yes, please tell us, how are you doing this. Cause, llvm can't be mixed in different versions. And ROCm is using some dev-version of llvm (llvm-11 at the moment) whereas mesa works with the latest released version of llvm (llvm-10 or llvm-9).

I finally got some time to check this during the weekend and yes you are correct. The aur packages include an arch package called "llvm-amdgpu" I guess this package it the llvm-version that you were talking about, and this is why it works for me.