AMDGPU and Linux growing pains

[Darksurf]

Hey bridgman, I'm the author of the blog on sabayonlinux.org that you're looking for. Some of the team hit me up on IRC and let me know you were looking for me via reddit. If you have any clarifications for the article or information, to add to it I don't mind chatting The article was really meant to help with the questions I typically hear or get from Sabayon Linux users. I didn't expect it to be so widely noticed! I'd be glad to hear from you! I sent you a PM on reddit, but didn't hear from you. Figured this location may be better . The Sabayon dev team mentioned they were interested in the "option 3" which was the simplified method of choosing between opensource and proprietary?

[haagch]

The problem, and I've messaged both John Bridgman and Alex Deucher about it, is that AMD are using a really old libdrm, they've not opened it up, not even a public tree, because "it has ioctl's which no open driver uses." Which is frigging frustrating and a bit stupid really, as I say, they could have it available in a public tree, doesn't have to be mainlined! My current Gentoo Testing libdrm is 2.4.81, Gentoo's lowest is 2.4.75, AMD's was 2.4.66, I've just checked 17.10 release and it's now 2.4.70.

something around 2.4.81: https://cgit.freedesktop.org/~agd5f/...master20170517
Unfortunately a little bit buggy, needs amdgpu.ids from a build of the mainline libdrm in /usr/share/libdrm

They say they want to update it from time to time, but it's been 6 weeks already...

[haagch]

It's a generated file during the build process.

[Darksurf]

bridgman do you have any suggestions here?

[agd5f]

The ids file can be found here:

https://cgit.freedesktop.org/mesa/drm/tree/data/amdgpu.ids

[agd5f]

They say they want to update it from time to time, but it's been 6 weeks already...

I updated the hybrid branches. That said, there are only a handful of hybrid specific patches. Most if not all of them should cherry-pick to easily to any kernel. The vast majority of the patches in the hybrid kernel tree are kernel compatibility patches to support old enterprise distro kernels that you only need if you want to build the driver as a dkms module. The hybrid libdrm tree doesn't change much and you could rebase the branch on something newer if you wanted.

[haagch]

Thanks.
The thing is, I have no idea which patches to cherry pick. Taking a quick look at the cgit log, the first 2000+ patches in that branch are amd stuff. I assume the needed patches are some of the newest ones? I haven't slept a lot, so my memory is a bit fuzzy but I think amdgpu-pro vulkan since 17.20 and 17.30 didn't work on amd-staging-drm-next. It does work on the hybrid branch.

Anyway, the libdrm isn't so many commits apart. I cherry picked this (a bit out of order) as a compromise which allows to run radv git too: https://github.com/ChristophHaag/lib...commits/master. Still missed installing /usr/share/libdrm/amdgpu.ids for me but that's no problem to fix from upstream libdrm.

edit: Also ROCm OpenCL. Is it supposed to work on amd-staging-drm-next or will it only work on the hybrid driver? I'm currently compiling OpenCL runtime, hoping it won't run into strange errors on Arch.

[agd5f]

edit: Also ROCm OpenCL. Is it supposed to work on amd-staging-drm-next or will it only work on the hybrid driver? I'm currently compiling OpenCL runtime, hoping it won't run into strange errors on Arch.

ROCm requires either the ROCm kernel form gpuopen or the hybrid kernel until the current ROCm delta gets upstream. The ROCm kernel team is working on that now.