AMDKFD Looking To Be Merged Into AMDGPU Linux DRM Kernel Driver

[phoronix]

Phoronix: AMDKFD Looking To Be Merged Into AMDGPU Linux DRM Kernel Driver

While "AMDGPU" is often what is talked about when it comes to the Radeon graphics driver code within the Linux kernel with it being the Direct Rendering Manager (DRM) driver for AMD GCN graphics cards and newer, there is also the AMDKFD kernel driver that plays a vital role for compute support...

http://www.phoronix.com/scan.php?page=news_item&px=AMDKFD-Merge-Into-AMDGPU

[Meteorhead]

Does this mean that ROCm would eventually gain graphics interop capabilities!

[Brisse]

Hi, is there any source if information on how to use rocm with upstream kernel?

I don't think that is possible yet. Hopefully that will be fixed when ROCm 1.9 is released.

[guglovich]

Kaveri gcn 1.1, AMDGPU gcn 1.2 and higher. Thanks AMD

[Jumbotron]

Yep GCN 1.2 would cover Carrizo and Bristol Ridge.

[guglovich]

Yep GCN 1.2 would cover Carrizo and Bristol Ridge.

Resentment. I took Kaveri just for the sake of HSA. Oh, this marketing of AMD...

[ernstp]

Hi, is there any source if information on how to use rocm with upstream kernel?

https://lists.freedesktop.org/archives/amd-gfx/2017-September/013609.html

[bridgman]

Hi, is there any source if information on how to use rocm with upstream kernel?

Now that the KFD code is substantially upstream the next step is to align our internal trees with the upstream user/kernel interface, which is slightly different from the UKI in our internal trees (and hence in ROCm releases). The goal is to include this in the upcoming ROCm 1.9 release.

Note that the initial release may not include testing against upstream, just rebasing our internal trees against upstream KFD and then testing against the internal trees we use for the ROCm release. So we're going from saying "it won't work against upstream" to "it should work against upstream, but use the kernel code we release if you want to be sure".

Being able to say "it will work against upstream" will require at least doubling our current test coverage, which will take some time, but it is part of the plan.

[bridgman]

Kaveri gcn 1.1, AMDGPU gcn 1.2 and higher. Thanks AMD

Do you mean "radeon gcn 1.1, amdgpu gcn 1.2 and higher" ? I'm guessing that your "thanks" is sarcastic but not sure why.

Note that we have switched to using amdgpu with ROCM rather than radeon, even for GCN 1.1 - that is one of the things that makes the proposed merge possible.

[guglovich]

Do you mean "radeon gcn 1.1, amdgpu gcn 1.2 and higher" ? I'm guessing that your "thanks" is sarcastic but not sure why.

Note that we have switched to using amdgpu with ROCM rather than radeon, even for GCN 1.1 - that is one of the things that makes the proposed merge possible.

Nearly. I hint that the Kaveri are deprived of functionality in the future kernel. After all, as you wrote for Kaveri already Radeon DRM. And from the news, I realized that AMDKFD removed from the kernel and a duplicate code from the Radeon DRM. Correct if I'm wrong.

Also interesting is whether this means that there will finally be compatibility with Mesa OpenCL?