Setting Up The Radeon Open Compute Platform On Linux

[phoronix]

Phoronix: Setting Up The Radeon Open Compute Platform On Linux

Now that the Radeon Open Compute platform reached v1.0, if you are wanting to try out this ROCm platform with a Volcanic Islands GPU here is a guide...

http://www.phoronix.com/scan.php?page=news_item&px=Setup-Radeon-OCP-Linux

[RussianNeuroMancer]

I wonder if amdpro will be available for installation from http://packages.amd.com repository too?

[juno]

Why should it?
amdgpu itself is inside the kernel, the free components on top will be in the distribution's repos.

might be the case for the pro-stack, however... why not?

[Meteorhead]

I was somewhat disappointed that the range of supported HW is extremely slim. Practically only the newest of cards. SW lags so far behind, there is a vast range of capabilities even in GCN 1.0 HW that is extremely hard to get to with portable tools. I would much rather see a C++AMP compiler on Linux that is actually capable of compiling to all HW and does not seem like a dead end and I am not hesitant to build a project onto it.

[bridgman]

We could have delayed launch to add support for more hardware but on balance it did not seem like a good idea. We will probably add support for some existing HW (I would like to see Hawaii support, for example) but given Fiji's compute throughput (SP at least) and power efficiency I think it's fair to say that it was the logical first step for large scale compute. ROC is based on our HSA stack and really was designed around the HSA features we implemented in recent HW.

GCN 1.0 does not have an MEC block, only supports 2 compute queues, has no user queue support, no AQL support -- we hacked a single user queue to run on Tahiti/Trinity during early development but it was not pretty. We could write a completely *different* implementation for GCN 1.0 (eg submitting work via kernel queues rather than user queues, emulating AQL packets by translating them on the fly to PM4 etc...) but that really would be dead end code in the sense that it would only ever be useful on one chip (Tahiti).

GCN 1.1 has a number of limitations (among others MEC microcode store is fixed size so not able to support PM4 / AQL / HWS at the same time) but we may be able to extend support back.

GCN 1.2 (specifically Carrizo & Fiji but not Iceland/Topaz and Tonga) was the first generation with full HSA support, and ROC is derived from our HSA stack. Going forward support is easy but going back to pre-HSA parts is more difficult.

So I expect we may extend HW support back a bit but the focus will be on extending it forward. Were there specific older chips you had in mind (other than Hawaii), and was there a real benefit to supporting those other than "someone might have one lying around" ?

Thanks,
John

[drSeehas]

... we hacked a single user queue to run on Tahiti/Trinity ...

Trinity? This is an APU with a TeraScale 3 GPU.

... Carrizo & Fiji but not Iceland/Topaz and Tonga ...

Carrizo with only 512 is supported but not Tonga with 1792/2048?

[bridgman]

Trinity? This is an APU with a TeraScale 3 GPU.

Yep, but we only used the integrated GPU to run the desktop. What Trinity gave us was IOMMUv2 support via the PCIE bus, and Tahiti had an ATC block - put them together and you have the first GPU that could access unpinned system memory via ATS/PRI. That's what we used until we had Kaveri silicon.

Carrizo with only 512 is supported but not Tonga with 1792/2048?

Carrizo is full HSA, Tonga has a couple of HW gaps IIRC. That said, the biggest reason for not focusing on Tonga was that we were focusing on Fiji instead, with 4096

Carrizo support was largely finished before we even started adding dGPU support.

[whitecat]

Is this something related to OpenCL ?
Can we run OpenCL programs with this stack installed ?

[bsp2020]

@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.
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?

[bridgman]

Is this something related to OpenCL ?
Can we run OpenCL programs with this stack installed ?

Our current OpenCL stack will probably migrate to run on ROC rather than the graphics driver over time. At the moment the main focus is supporting newer standards for computing -- the HCC compiler focuses on C++17 with parallel extensions, which seems to be the "convergence point" for parallel compute.