Some More Radeon Vega Frontier Edition Linux ROCm OpenCL Benchmarks

[bridgman]

We keep pushing changes upstream so I imagine this will come automatically with time. At the moment using older libraries doesn't necessarily just result in "slower / less optimized", I expect there would be some "broken" mixed in there as well.

Six months between llvm releases is a very long time right now because the stack is evolving so quickly.

EDIT - I haven't heard anything about LLVM point releases recently since Tom left.. might be worth trying to revive those.

[extraymond]

We keep pushing changes upstream so I imagine this will come automatically with time. At the moment using older libraries doesn't necessarily just result in "slower / less optimized", I expect there would be some "broken" mixed in there as well.

Six months is a very long time right now because the stack is evolving so quickly.

Hi! Mr. Bridgman:

Since rocm it's gonna be upstream, is tonga(gcn 1.2) gonna be supported by rocm? It seems rocm supports limited hardwares due to pcie spec, at least from what I've gather from rocm github page. It would be nice to know what will rocm and opencl shape up for at least all the gcn hardwares. Thx.

[bridgman]

Since rocm it's gonna be upstream, is tonga(gcn 1.2) gonna be supported by rocm? It seems rocm supports limited hardwares due to pcie spec, at least from what I've gather from rocm github page. It would be nice to know what will rocm and opencl shape up for at least all the gcn hardwares. Thx.

Hi,

Last time I asked there was some kind of HW issue with Tonga that interfered with ROCm support but I don't remember what it was - will ask again. I think it was related to PCIE atomics but not 100% sure.

[Berniyh]

We are in the process of adding the Kernel Compatibility Layer and DKMS support from AMDGPU-PRO to the ROCM stack - almost made it for 1.6 (you can see the /drivers/gpu/drm/amd/amdkcl folder) but not quite. That will allow you to install just driver modules rather than replace the kernel. Internal trees have now moved to 4.12, and we will be tracking upstream much more closely now that we have finished syncing up all of the driver variants (all-open, hybrid and ROCm).

Felix is also making progress on getting the latest ROC kernel code upstreamed:

https://lists.freedesktop.org/archiv...st/011984.html

Nice, I hope those things get resolved quickly. If it doesn't require a specific kernel version anymore that's a huge step forward.
The main problem I was facing was that there were many patches conflicting with other changes to the amdgpu driver and other drivers in the kernel, hence it was non-trivial to merge the trees and you would be stuck with that specific kernel version.

We supply prebuilt binaries as well IIRC. Or are you saying you want to build it yourself but want it to be easier ?

I did build it myself. That part wasn't exactly hard in principle although especially the install scripts are missing pieces here and there (already made contact on github to point that out).
However, what I actually want to do is to package it for my distribution (Exherbo), but for that I'd really like to prevent bundled packages and especially the whole-in-one structure but instead package the individual pieces.
I succeeded for some of the packages, e.g. ROCR-Runtime and ROCT-Thunk-Interface, but for most packages it's currently impossible to package them properly.
Hence, I hope that the cmake scripts are improved to allow for separate builds. If necessary, I'd help there.

As long as llvm is on a six month release cycle and we have customers expecting faster-than-that response time & progress we are going to have to operate out of tree, aren't we ? Or is there an easier solution I am missing ?

I totally understand that and it's good that there are binary packages and that there is an option for the bundled llvm to make it easier to build for those that are not keen with fiddling around with builds.

What I would like however is that there is the option to build it against system-llvm and system-clang.
I do realize that you need a specific tree or rather a patched llvm, but that is ok. I can introduce that patch-series optionally for system-llvm and then require that option, so the patches are not a problem.
Even requiring an scm tree + patches is possible, if necessary.
Of course it doesn't help here that llvm are still using svn and thus it can be harder to extract the patch-series.

[extraymond]

Hi,

Last time I asked there was some kind of HW issue with Tonga that interfered with ROCm support but I don't remember what it was - will ask again. I think it was related to PCIE atomics but not 100% sure.

Thx, still waiting for an detailed answer.