AMD Begins Posting More KFD Patches For Discrete GPUs

[phoronix]

Phoronix: AMD Begins Posting More KFD Patches For Discrete GPUs

For the past number of months AMD has been working on upstreaming more KFD changes, AMDKFD is their kernel driver to the HSA compute stack. AMD began with upstreaming their APU changes while now they have finally moved onto their "dGPU" changes...

http://www.phoronix.com/scan.php?page=news_item&px=AMDKFD-dGPU-Patches-Coming

[r1348]

What hardware generations will be supported by this?

[bridgman]

AFAIK the intent is to support the same as the current ROCM stack, so Fiji / Polaris / Vega plus Hawaii with some limitations.

SI and earlier parts do not have MEC (aka ACE) hardware, and early CI/VI parts are missing some MEC/ACE functionality.

[fusionS]

Many APU systems with hardware support is still blocked by missing BIOS setup/configuration, especially wrongly defined CRAT table and no updates avail from motherboard vendors.

bridgman Is there any way of overriding the CRAT, IVRS acpi tables found in many BIOSes with working ones during Linux boot?

Most notably I am missing support from Vendors+AMI on a number of APUs, including Carrizo which is annoying as it support hsa in the silicon.

Do you have any tool to generate a correct and verified CRAT etc table?

[caligula]

So how does this help normal users? I'm not familiar with the HSA stuff.

[bridgman]

Is there any way of overriding the CRAT, IVRS acpi tables found in many BIOSes with working ones during Linux boot?

Most notably I am missing support from Vendors+AMI on a number of APUs, including Carrizo which is annoying as it support hsa in the silicon.

Do you have any tool to generate a correct and verified CRAT etc table?

For dGPUs we generate a CRAT on the fly (this is required because platform SBIOS does not know about the graphics card when being generated) and that could probably be extended to fix up APUs as well. See kfd_create_crat_image_virtual() in kfd_crat.c :

https://github.com/RadeonOpenCompute...kfd/kfd_crat.c

At the moment I believe we do a bit of on-the-fly patching of broken APU CRAT tables but if CRAT is missing completely we treat the APU like a CPU instead.

CRAT issues notwithstanding, a bigger problem is that a lot of the BIOSes seem to disable IOMMU completely without providing a GUI option to enable... not sure we have a solution for that yet.

[bridgman]

So how does this help normal users? I'm not familiar with the HSA stuff.

If "normal users" means "users not doing compute-intensive work" it doesn't. What it will do when finished, however, is allow use of ROCm compute paths using an upstream kernel instead of requiring out-of-tree code from the ROCm stack:

https://github.com/RadeonOpenCompute/ROCm

[caligula]

If "normal users" means "users not doing compute-intensive work" it doesn't. What it will do when finished, however, is allow use of ROCm compute paths on the upstream open source driver stack:

https://github.com/RadeonOpenCompute/ROCm

Would (OpenCL) photography filters in Darktable/GIMP count as compute-intensive work?

[bridgman]

Would (OpenCL) photography filters in Darktable/GIMP count as compute-intensive work?

Yes - we have released an open source OpenCL implementation that runs over the ROCm stack. OpenCL-over-ROCm is the default implementation for Vega, however for earlier ASICs the default is OpenCL running over the graphics paths rather than ROCm/KFD.

[fusionS]

Thank you bridgman for the answer.
Will poke around on an APU laptop laying around. It has AMI bios with IOMMU enabled and working, but wrong CRAT and see what can be done virtually.

A lot of systems must have this problem.

Any chance of seeing (a possibly slower) but working OpenCL stack without the coherency benefits of hsa for systems where IOMMU/kfd is broken?