Setting Up The Radeon Open Compute Platform On Linux

[bridgman]

I have Kaveri desktop and want to experiment with ROCm with GCN native backend, which seems currently supported only on VI hardware. Can I add Fiji to my desktop and use it? It seems AMD only seems to support Intel CPU as the host CPU for ROCm at the moment.

The programming models for dGPU and APU are slightly different (APU runs through IOMMUv2 for full-speed access to unpinned system memory, dGPU relies on local memory for performance) so the stack needed to either support mixed-mode programming across both models (it doesn't yet) or at least disable the Kaveri GPU for ROC compute when dGPUs were active. I believe code for the latter option has been added now, will check.

Also, will the binary compiled with the native backend work on Polaris as well, or does it need to be recompiled? I was surprised to find that AMD is concentrating on the tools that generate native GCN ISA. I thought HSAIL was one of the main feature of HSA that maintains compatibility. Does AMD feel that the GCN ISA has stabilized enough that compiling directly to GCN ISA is good idea?

Not sure about Fiji-to-Polaris ISA compatibility (it's certainly pretty close) but ISA binaries are still tagged with a compute capability level and only try to run on hardware with the same capability level.

[juno]

Our current OpenCL stack will probably migrate to run on ROC rather than the graphics driver over time.

I don't quite get what that means. I'm still expecting the current OpenCL driver to be released as free software (of course after the initial release of the hybrid stack) on top of amdgpu. So this will be an intermediate solution, also for consumers? Will end-users have to install both the graphics- and roc-stack for real-time graphics and parallel computing workloads?
Should consumer at all care about roc or is it just for hpc workloads with multi gpu racks etc? Is it "just" easier for development for highly parallel, platform independent computing or does it provide runtime-benefits, too? Would developers of current OpenCL-accelerated everyday-software (OpenCL renderers, LibreOffice, Adobe software, ...) at all care to port to ROC?

[bridgman]

I don't quite get what that means. I'm still expecting the current OpenCL driver to be released as free software (of course after the initial release of the hybrid stack) on top of amdgpu. So this will be an intermediate solution, also for consumers? Will end-users have to install both the graphics- and roc-stack for real-time graphics and parallel computing workloads? Should consumer at all care about roc or is it just for hpc workloads with multi gpu racks etc?

The OpenCL driver we release in open source will probably run over ROC.

Think about ROC as part of the normal driver stack, just developed on a separate schedule from graphics driver releases and initially targetting new business areas. The code is being integrated via upstream and ROC will become just another part of the open and hybrid stacks.

[bridgman]

moderated

[bridgman]

It's hard editing a post you can't see, but one thing I *think* I missed from the currently moderated post was the point that out-of-tree releases are valuable in the short term because they allow us to optimize the stack for HPC in ways that would not be acceptable upstream in their current form, eg pinning memory from userspace or allowing GART to use the entire system physical memory for GPU access.

We are working in parallel on "housebroken" versions of all those optimizations which should be able to go upstream and into a common stack, but being able to release out-of-tree does let us deliver functionality more quickly at times. That is also part of the rationale for the hybrid driver, of course.

[bridgman]

aaaand... moderated again

[juno]

The OpenCL driver we release in open source will probably run over ROC.

Think about ROC as part of the normal driver stack, just developed on a separate schedule from graphics driver releases and initially targetting new business areas. The code is being integrated via upstream and ROC will become just another part of the open and hybrid stacks.

Thanks for the answers
I think it's actually quite confusing with the naming again... so the "new ROCK kernel driver" isn't actually a new kernel driver but instead just features additions to amdgpu/amdkfd that might not go upstream?! So the OpenCL driver will still hook into amdgpu via libdrm_amdgpu, and not require a new kernel driver?

[ribalda]

Sorry, but I am lost trying to understand what codename belongs to what. I have an APU which I believe it is Ontario. (PCI ID 1002:9806) and clinfo says that it is "Loveland platform". I heavily rely on OpenCL. What are my options now that flgrx is getting deprecated.? Thanks!

[phred14]

@brigman
A while back I purchased a Kaveri desktop, hoping someday to do some simulation development with it, and knowing that it would be at least a year until HSA support matured sufficiently for a non-expert (like me) to use. That said, I mostly quit paying attention to it all, just occasionally seeing that bits and pieces appeared to be progressing. With this announcement there appears to be a new range of alphabet soup, and I get a distinct flavor that my Kaveri has been left in the dust - that the maturing software will be maturing for new products.

Can you comment / set me straight / reassure? I hope to become interested in electrical / physics simulation with this machine. (This was purchased as a potential "retirement computer", and that stuff will interest me more then.)

[bsp2020]

Sorry, but I am lost trying to understand what codename belongs to what. I have an APU which I believe it is Ontario. (PCI ID 1002:9806) and clinfo says that it is "Loveland platform". I heavily rely on OpenCL. What are my options now that flgrx is getting deprecated.? Thanks!

AMD dropped support for pre-GCN hardware some time ago. So, even if flgrx was not deprecated, you wouldn't have gotten updates any way. If your current set up works for you now, you will probably need to stick with that set up. Ontario is very old and uses VLIW based GPU (https://en.wikipedia.org/wiki/AMD_Ac...Desna.2C_Hondo).