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

[illwieckz]

i'm not aware of any issues with my rx580(but i don't use compute)

If you don't use compute, you don't know what people are talking about and your opinion does not matter.

AMD stuff works very well on the Mesa graphic side of things but you can't assume it's the same on non-graphic side, as those software stacks usually have almost nothing in common.

Assuming AMD compute stack is good because AMD graphic stack is good is wronger than assuming amdgpu-pro graphic driver that does not share anything with Mesa is good because Mesa's radeon is good.

Those are very different software stacks and they do very different things, the only thing in common may be they both run on the same kernel driver, but that's all: that unique “kernel driver” does not do anything related to those application developer targeted API that are OpenGL, OpenCL, etc.

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.

Basically, if you don't have the right GPU (Vega?) and the right distro (Ubuntu LTS?) you have to get your hands dirty to get compute working, and in some case you cannot have compute working at all.

[duby229]

If you don't use compute, you don't know what people are talking about and your opinion does not matter.

AMD stuff works very well on the Mesa graphic side of things but you can't assume it's the same on non-graphic side, as those software stacks usually have almost nothing in common.

Assuming AMD compute stack is good because AMD graphic stack is good is wronger than assuming amdgpu-pro graphic driver that does not share anything with Mesa is good because Mesa's radeon is good.

Those are very different software stacks and they do very different things, the only thing in common may be they both run on the same kernel driver, but that's all: that unique “kernel driver” does not do anything related to those application developer targeted API that are OpenGL, OpenCL, etc.

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.

Basically, if you don't have the right GPU (Vega?) and the right distro (Ubuntu LTS?) you have to get your hands dirty to get compute working, and in some case you cannot have compute working at all.

Bolded by me....

Yes, this, totally this..... AMD really needs to find an upstream project to contribute to. When they release their own code with their own upstream it really sucks ass. AMD OpenCL support at this time really sucks ass. Clover -STILL- has better compatibility than ROCm, the problem with Clover is AMD won't update it to support newer GPU's. ROCm really needs to be abandoned and Clover really needs to be picked back up. That is, at least, if AMD actually wants working OpenCL with a really great upstream community to maintain it.

[PuckPoltergeist]

I do not understand why people have sop much problems with these libraries. I have been using them for OpenCL and now OpenMP with my Fiji card for at least...2 years on Arch and AUR. I have had relatively few problems. Few hicks when upgrading to new versions, that have sorted themselves out pretty quickly.

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).

[duby229]

ROCm reeks of Beignet envy..... And Beignet failed miserably just as ROCm will for exactly the same reasons....

[jrch2k8]

proprietary shit is never an option
i'm guessing you are clueless

1.) if you are developing GPGPU code there is nothing else but CUDA, i don't like nVidia either but reality is AMD have nothing functional in this sense outside old PAL OpenCl code because ROCm is not something i would call functional.

2.) We are talking pure compute here not graphics and again is a fact that CUDA reign supreme in this segment, sadly i agree but is reality

[PuckPoltergeist]

[QUOTE=illwieckz;n1186022]
AMD stuff works very well on the Mesa graphic side of things but you can't assume it's the same on non-graphic side, as those software stacks usually have almost nothing in common.

...

Those are very different software stacks and they do very different things, the only thing in common may be they both run on the same kernel driver, but that's all:
[/QUOTE}
But that's a very big part.

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.

[vegabook]

it's a wrapper, which still requires underlying implementation. efficient and cross-platform compute is called vulkan

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.

[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).

Yes I am...and I honestly never thought about llvm versions. I installed it via aur in Arch ( the installation is an old antergos installation that went over to Arch). I just tried to install and when a package didn't work then I excluded it an tried again. When the packages finally went in, I installed the excluded ones with success. Just checked the version of rocm. It is 3.5

[duby229]

[QUOTE=PuckPoltergeist;n1186037]

AMD stuff works very well on the Mesa graphic side of things but you can't assume it's the same on non-graphic side, as those software stacks usually have almost nothing in common.

...

Those are very different software stacks and they do very different things, the only thing in common may be they both run on the same kernel driver, but that's all:
[/QUOTE}
But that's a very big part.


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.

The OpenCL efforts for Nouveau are being done on Clover, so if AMD wants to benefit or contribute then they will have to adopt Clover for OpenCL... ROCm in terms of compatibility really sucks and Clover is better.... But even then that's assuming you fall into the very tiny possibility that you can even get ROCm to work at all....

[Steffo]

Has anyone real experience with ROCm? As far as I know, AMD is mainting forks of tensorflow and PyTorch which doesn't make it to a first class citizen. Also the performance compared to CUDA is interesting to me.