Trying To Run The AMDGPU Driver With A Hawaii GPU On Linux 4.5

[lostdistance]

How has your experience been running this way? I have an A10-7850 APU running radeon, and was thinking of trying amdgpu. Then I read somewhere that the backward capability was only in amdgpu for pre-hardware debug and would probably never be touched again, now that the planned hardware was available. They suggested sticking with radeon.

It worked OK apart from VA-API hardware video acceleration. I presume mesa has yet to implement this for amdgpu (as opposed to radeonsi).

These are my notes for getting amdgpu working with Gentoo Linux:

#### amdgpu

---- firmware:

emerge -u sys-firmware/amdgpu-ucode

---- kernel (see https://wiki.gentoo.org/wiki/Amdgpu):

CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="radeon/kaveri_ce.bin radeon/kaveri_me.bin radeon/kaveri_mec.bin radeon/kaveri_mec2.bin radeon/kaveri_pfp.bin radeon/kaveri_rlc.bin radeon/kaveri_sdma.bin radeon/kaveri_sdma1.bin radeon/kaveri_uvd.bin radeon/kaveri_vce.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
CONFIG_DRM=y
CONFIG_DRM_AMDGPU=y
CONFIG_DRM_AMDGPU_CIK=y
CONFIG_DRM_AMDGPU_USERPTR=y
CONFIG_FB=y
CONFIG_FRAMEBUFFER_CONSOLE=y

---- /etc/portage/make.conf:

VIDEO_CARDS="amdgpu radeon radeonsi"

---- eselect

eselect opengl set xorg-x11
eselect mesa set sw gallium

---- /etc/X11/xorg.conf:

Section "Device"
    Identifier    "A10 7800"
    Driver        "amdgpu"
EndSection

[kiffmet]

The AMDGPU Kernel driver loads successfully on Arch Linux x64 with linux-git from Aur on my R9 290! Performance is the same as with radeon kernel driver with stock mesa and stock llvm-libs in windowed unigine heaven in a gnome wayland session.

[duby229]

Alex, since there is no SDMA microcode for Tahiti, can I assume there is currently no way to even try to get amdgpu working on Tahiti/GCN 1.0 based cards (HD 7970 in my case)? Can we expect microcode updates for Tahiti as well, or should I just forget about amdgpu until I upgrade my hardware?

Tahiti should have 2 SDMA engines, so I wonder if there is a hardware reason, or if it is just not a priority right now.

Like I said, I am under the impression right now that radeon will get the required libdrm-amdgpu interface support so that it can support Vulkan. Amdgpu only supports GCN 1.1 unofficially and GCN 1.2+ officially. There is a good chance that GCN 1.1 owners can get amdgpu to work, but not GCN 1.0 owners.

Like I said once that libdrm-amdgpu interface becomes available for the radeon kernel driver, at that time it won't matter anymore.

[agd5f]

Alex, since there is no SDMA microcode for Tahiti, can I assume there is currently no way to even try to get amdgpu working on Tahiti/GCN 1.0 based cards (HD 7970 in my case)? Can we expect microcode updates for Tahiti as well, or should I just forget about amdgpu until I upgrade my hardware?

Tahiti should have 2 SDMA engines, so I wonder if there is a hardware reason, or if it is just not a priority right now.

Tahiti has an older DMA engine that does not use microcode so there is none required. You'd need to port all of the SI support from radeon to amdgpu to use it with amdgpu. There is currently no SI support in amdgpu.

[tg--]

Alex, since there is no SDMA microcode for Tahiti, can I assume there is currently no way to even try to get amdgpu working on Tahiti/GCN 1.0 based cards (HD 7970 in my case)? Can we expect microcode updates for Tahiti as well, or should I just forget about amdgpu until I upgrade my hardware?

Tahiti should have 2 SDMA engines, so I wonder if there is a hardware reason, or if it is just not a priority right now.

[duby229]

How has your experience been running this way? I have an A10-7850 APU running radeon, and was thinking of trying amdgpu. Then I read somewhere that the backward capability was only in amdgpu for pre-hardware debug and would probably never be touched again, now that the planned hardware was available. They suggested sticking with radeon.

I am currently under the impression that radeon will get the required libdrm-amdgpu interface so it can support Vulkan. If that indeed turns out to be the case, then you are right, you won't need to switch to amdgpu.

[bridgman]

"Replies below are on the next page. Click here to go to the next page." and "Unapproved" again. Definitely something wonky here...

This follow-on post also received a "next page" message, and as always when I click on the link I end up on the same page as before, ie the whole "next page" event seems to be bogus but always associated with a post being moderated.

[bridgman]

Then I read somewhere that the backward capability was only in amdgpu for pre-hardware debug

Not "only" for initial development but that is why it was there in the first place.

and would probably never be touched again, now that the planned hardware was available.

Don't think we said this... we were definitely planning to use amdgpu on CI for the hybrid driver (closed source userspace), and we have been pushing updates to the CIK code as well, not just VI.

They suggested sticking with radeon.

For open source stack, definitely... since that's where all the test coverage is. If we are able to make amdgpu the default driver in upstream & distro trees then obviously that could change, but at the moment we strongly recommend staying with radeon.

[phred14]

Did the kernel load the correct firmware files? That was the first problem I hit when running the AMDGPU driver on an A10-7800 APU.

How has your experience been running this way? I have an A10-7850 APU running radeon, and was thinking of trying amdgpu. Then I read somewhere that the backward capability was only in amdgpu for pre-hardware debug and would probably never be touched again, now that the planned hardware was available. They suggested sticking with radeon.

[agd5f]

Hey Alex, I had grabbed all of them (including sdma1) from http://people.freedesktop.org/~agd5f..._ucode/hawaii/ which looks like it is the same version? Then placed it in /lib/firmware/radeon/, or should it be at /lib/firmware/amdgpu perhaps or something?

Should be in /lib/firmware/radeon/. Make sure your initrd is updated if you are using one.