Radeon Open Compute 1.3 Platform Brings Polaris & Other Features

[bridgman]

Until we get dGPU support in amdkfd upstreamed (the 1.3 stack is the first to include eviction code, which is a pre-requisite for upstream) the ROC stack is primarily compute-oriented, ie not much testing for graphics.

HW support is currently Fiji (honkin' fast SP), Hawaii (honkin' fast DP) and Polaris (perf/$, perf/W although Fury Nano has pretty good perf/W as well). Other CIK parts could potentially be supported but SI is a non-starter since the MEC block that HSA/ROC builds on appeared in CIK. At the moment the plan is just to enable ROC on parts which can really benefit from it, basically the list above.

[juno]

Not sure what the plans are for device ID switching inside the OpenCL runtime - I expect that specific device IDs will use the ROC back-end while everything else will use the current Orca back-end (we don't want to break existing users), so may not be possible to run unsupported HW over ROCm until the OpenCL code gets open sourced.

Hmm, okay. Do you know if orca, or the amdgpu-pro opencl driver, relies on not yet upstreamed changes in amdgpu? Or will we possibly be able to use the opencl driver on top of the free stack?

HW support is currently Fiji (honkin' fast SP), Hawaii (honkin' fast DP) and Polaris (perf/$, perf/W

Does it matter if using Radeon or FirePRO? Radeons are borked when it comes to DP, but Hawaii R9 290/390 series will still be able to run the software, albeit with low DP performance, right?

[Amarildo]

"ie not much testing for graphics"

Sure, but blender takes advantage of compute performance (OpenCL/CUDA) for rendering.

"basically the list above"

So this means SI will be supported, just not now?

[juno]

the MEC block that HSA/ROC builds on

Sorry, also forgot one: Is Orca at all using the MECs or has OpenCL been done by the ME?

[juno]

So this means SI will be supported, just not now?

As bridgman said, ROCm relies on the MECs, some logic blocks inside the GPU that was introduced with CIK, so: no. Only starting from CIK.
Blender/Cycles is using OpenCL, so you won't be able to run it at all until OpenCL is running over ROCm, which seems to happen as a developer preview in December.

http://www.planet3dnow.de/cms/wp-con...-ROCm-SC16.png

[Amarildo]

Looking at John's words I don't have hopes for opensource OpenCL on my GCN 1.0 anymore. Total and utter bullshit. I really thought support was coming.

Thanks for nothing AMD.

[bridgman]

Hmm, okay. Do you know if orca, or the amdgpu-pro opencl driver, relies on not yet upstreamed changes in amdgpu? Or will we possibly be able to use the opencl driver on top of the free stack?

I believe it does rely on non-upstreamed changes at the moment, but the performance hit from running on upstream isn't too bad. That's one of the big reasons for open-sourcing it... so there will be an open userspace driver that uses the IOCTLs we want to upstream.

Does it matter if using Radeon or FirePRO? Radeons are borked when it comes to DP, but Hawaii R9 290/390 series will still be able to run the software, albeit with low DP performance, right?

Will check - for Fiji we supported the consumer IDs as well as the FirePRO ones in ROC, and I imagine we'll want to run all variants of a chip through the same code paths.

[juno]

Nice, thanks for the answers!

[pal666]

For dGPU we are not able to rely on IOMMUv2 since (a) some of our target market uses Intel and other CPUs without IOMMUv2 and (b) dGPUs rely heavily on local VRAM/HBM which is not managed by IOMMUv2 anyways

but will it use iommu when available (host memory on amd cpu)?

[pal666]

Looking at John's words I don't have hopes for opensource OpenCL on my GCN 1.0 anymore.

you already have opensource opencl support in mesa