RX 480 AMDGPU Driver Failing To Load On Debian Sid

jwhittles · 08-22-2016, 11:36 AM

I recently built a PC with an RX480 and installed the open source AMDGPU driver stack according to this guide. The only step I did not follow exactly was the kernel compilation-- I simply downloaded the 4.7.0rc7 kernel from the Debian experimental repository.

---
Output of:

Code:

uname -a

Code:

Linux Eleanor 4.7.0-rc7-amd64 #1 SMP Debian 4.7~rc7-1~exp1 (2016-07-14) x86_64 GNU/Linux

---

The graphics card appears to initialize just fine...

---
Output of:

Code:

dmesg | grep amd

Code:

[    0.000000] Linux version 4.7.0-rc7-amd64 (debian-kernel@lists.debian.org) (gcc version 5.4.0 20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.7~rc7-1~exp1 (2016-07-14)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.7.0-rc7-amd64 root=UUID=3117fb8f-0774-4d8e-97aa-3b8e936eff78 ro quiet
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.7.0-rc7-amd64 root=UUID=3117fb8f-0774-4d8e-97aa-3b8e936eff78 ro quiet
[    2.153126] usb usb1: Manufacturer: Linux 4.7.0-rc7-amd64 ehci_hcd
[    2.165066] usb usb2: Manufacturer: Linux 4.7.0-rc7-amd64 ehci_hcd
[    2.166215] usb usb3: Manufacturer: Linux 4.7.0-rc7-amd64 xhci-hcd
[    2.169419] usb usb4: Manufacturer: Linux 4.7.0-rc7-amd64 xhci-hcd
[    2.170615] usb usb5: Manufacturer: Linux 4.7.0-rc7-amd64 xhci-hcd
[    2.173869] usb usb6: Manufacturer: Linux 4.7.0-rc7-amd64 xhci-hcd
[    2.249402] usb usb7: Manufacturer: Linux 4.7.0-rc7-amd64 ohci_hcd
[    2.309116] usb usb8: Manufacturer: Linux 4.7.0-rc7-amd64 ohci_hcd
[    2.369146] usb usb9: Manufacturer: Linux 4.7.0-rc7-amd64 ohci_hcd
[    3.586002] [drm] amdgpu kernel modesetting enabled.
[    3.596360] amdgpu 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff
[    3.597447] amdgpu 0000:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_mc.bin
[    3.597459] amdgpu 0000:01:00.0: VRAM: 8192M 0x0000000000000000 - 0x00000001FFFFFFFF (8192M used)
[    3.597460] amdgpu 0000:01:00.0: GTT: 8192M 0x0000000200000000 - 0x00000003FFFFFFFF
[    3.600719] [drm] amdgpu: 8192M of VRAM memory ready
[    3.600720] [drm] amdgpu: 8192M of GTT memory ready.
[    3.602047] amdgpu 0000:01:00.0: amdgpu: using MSI.
[    3.602072] [drm] amdgpu: irq initialized.
[    3.602267] amdgpu: powerplay initialized
[    3.603145] amdgpu 0000:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_pfp.bin
[    3.603623] amdgpu 0000:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_me.bin
[    3.604144] amdgpu 0000:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_ce.bin
[    3.604371] amdgpu 0000:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_rlc.bin
[    3.605133] amdgpu 0000:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_mec.bin
[    3.605991] amdgpu 0000:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_mec2.bin
[    3.606549] amdgpu 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000200000008, cpu addr 0xffff8800b7e0f008
[    3.606652] amdgpu 0000:01:00.0: fence driver on ring 1 use gpu addr 0x000000020000001c, cpu addr 0xffff8800b7e0f01c
[    3.606681] amdgpu 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000200000030, cpu addr 0xffff8800b7e0f030
[    3.607618] amdgpu 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000200000044, cpu addr 0xffff8800b7e0f044
[    3.607885] amdgpu 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000200000058, cpu addr 0xffff8800b7e0f058
[    3.607936] amdgpu 0000:01:00.0: fence driver on ring 5 use gpu addr 0x000000020000006c, cpu addr 0xffff8800b7e0f06c
[    3.607959] amdgpu 0000:01:00.0: fence driver on ring 6 use gpu addr 0x0000000200000080, cpu addr 0xffff8800b7e0f080
[    3.607981] amdgpu 0000:01:00.0: fence driver on ring 7 use gpu addr 0x0000000200000094, cpu addr 0xffff8800b7e0f094
[    3.608003] amdgpu 0000:01:00.0: fence driver on ring 8 use gpu addr 0x00000002000000a8, cpu addr 0xffff8800b7e0f0a8
[    3.608401] amdgpu 0000:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_sdma.bin
[    3.610223] amdgpu 0000:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_sdma1.bin
[    3.623985] amdgpu 0000:01:00.0: fence driver on ring 9 use gpu addr 0x00000002000000bc, cpu addr 0xffff8800b7e0f0bc
[    3.624056] amdgpu 0000:01:00.0: fence driver on ring 10 use gpu addr 0x00000002000000d0, cpu addr 0xffff8800b7e0f0d0
[    3.633260] amdgpu 0000:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_uvd.bin
[    3.647029] amdgpu 0000:01:00.0: fence driver on ring 11 use gpu addr 0x000000000109c420, cpu addr 0xffffc9000325a420
[    3.648313] amdgpu 0000:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_vce.bin
[    3.653698] amdgpu 0000:01:00.0: fence driver on ring 12 use gpu addr 0x00000002000000f8, cpu addr 0xffff8800b7e0f0f8
[    3.654283] amdgpu 0000:01:00.0: fence driver on ring 13 use gpu addr 0x000000020000010c, cpu addr 0xffff8800b7e0f10c
[    3.725085] amdgpu 0000:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_smc.bin
[    4.358248] fbcon: amdgpudrmfb (fb0) is primary device
[    4.767814] amdgpu 0000:01:00.0: fb0: amdgpudrmfb frame buffer device
[    4.784116] [drm] Initialized amdgpu 3.2.0 20150101 for 0000:01:00.0 on minor 0

---

And GDM3 starts successfully with no graphical errors, whereas before installing the driver it wouldn't even run. However, it lags horribly and it is extremely evident that the driver isn't actually fully loaded, because animations are disabled in GNOME and the desktop environment still manages to drop frames like an old woman trying to gather her pennies. Let's have a look at the error messages from the Xorg log file after starting GNOME.

---
Output of:

Code:

cat .local/share/xorg/Xorg.0.log | grep "(EE)"

Code:

        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   216.095] (EE) Failed to load module "ati" (module does not exist, 0)
[   216.096] (EE) Failed to load module "fbdev" (module does not exist, 0)
[   216.096] (EE) Failed to load module "vesa" (module does not exist, 0)
[   216.220] (EE) AMDGPU(0): glamor detected, failed to initialize EGL.
[   216.952] (EE) AIGLX error: Calling driver entry point failed
[   216.952] (EE) AIGLX: reverting to software rendering

---

Running "glxgears" manages to pump out an impressive amount of frames despite being run through a software renderer, but the problem there is more of the same...

---
Output of:

Code:

LIBGL_DEBUG=verbose glxgears

Code:

pci id for fd 4: 1002:67df, driver (null)
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
pci id for fd 5: 1002:67df, driver (null)
libGL error: failed to create dri screen
libGL error: failed to load driver: radeonsi
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
libGL: Can't open configuration file /home/jessie/.drirc: No such file or directory.
libGL: Can't open configuration file /home/jessie/.drirc: No such file or directory.
5197 frames in 5.0 seconds = 1039.346 FPS

---

I had a quick look to be sure, and the driver is indeed present at "/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so" so it's not a matter of it missing. "glxinfo" creates the same errors as well, though I'm not sure what to make of its output.

---
Output of:

Code:

glxinfo | grep OpenGL

Code:

pci id for fd 4: 1002:67df, driver (null)
pci id for fd 5: 1002:67df, driver (null)
libGL error: failed to create dri screen
libGL error: failed to load driver: radeonsi
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.8, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.2.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

---

Looking at the situation, the problem may to be related to the "AMDGPU(0): glamor detected, failed to initialize EGL." message that is created upon launching the X server, as the driver fails to load directly after that error. I've looked up the error and can't find anything related to my specific situation, however. Documentation and guides for installing the drivers are also incredibly sparse if not nonexistent. I could only find the one guide above that happened to work with Debian. I guess this is what I asked for when I bought a brand new card built on a brand new architecture running on experimental drivers. I've fiddled with things for 10 hours to get to this point and I'm finally stuck. Does anybody know where to look next, or what the problem might be caused by?

Also, this install is completely fresh. As in, built-and-installed-the-drivers-right-after-installing-the-system fresh. The only thing I did beforehand that may have interfered was make an attempt at installing the proprietary drivers off of AMD's website. I failed miserably and it barely worked, probably because the package was intended for Ubuntu systems. Only half of the packages installed and I removed all of them immediately after it failed to install the entire set.

Thanks.

seasons · 08-23-2016, 03:40 PM

If you used the xorg.conf configuration given by the guide, then the "AMDGPU(0): glamor detected, failed to initialize EGL." message would be expected and not a problem in and of itself.

My guess is that the original version of mesa installed is being used and fails because the card's PCI ID is too new for it to recognize (which is why you have to build your own mesa). Therefore, no 3D accel and you get these errors:

Code:

libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
pci id for fd 5: 1002:67df, driver (null)
libGL error: failed to create dri screen
libGL error: failed to load driver: radeonsi

You probably need to point the system to the custom version of mesa you built. There is an environment variable named LIBGL_DRIVERS_PATH that will help you. I'm not sure where you installed mesa. Check /usr/local/lib

EDIT: Oh yeah, you're definitely using the original version of mesa:

Quote:

OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.2

gradinaruvasile · 08-25-2016, 02:15 PM

Do you have xserver-xorg-video-amdgpu installed? I suppose you need it instead of -radeon? Check for libdrm-amdgpu1, firmware-amd-graphics.

And, look here:
https://wiki.archlinux.org/index.php...o_acceleration

There it says that you need to blacklist the radeon driver to make amdgpu work for some cards since they might conflict. You might try that even if your card is not Sea Islands and the amdgpu.exp_hw_support=1 kernel command line option.

PS. Why use that guide? Debian sid/experimental has everything you need in the repos.

There is mesa 12.0.1 in experimental. You should try upgrading your mesa stack to that one.

seasons · 08-25-2016, 05:39 PM

Quote:

Originally Posted by gradinaruvasile

Do you have xserver-xorg-video-amdgpu installed? I suppose you need it instead of -radeon? Check for libdrm-amdgpu1, firmware-amd-graphics.

If you look at the logs, the user has all of those components installed.

Quote:

There it says that you need to blacklist the radeon driver to make amdgpu work for some cards since they might conflict.

The RX 480 is an "Arctic Islands" card, so there's no need to blacklist radeon or force amdgpu, because radeon does not support those cards.
https://en.wikipedia.org/wiki/Graphics_Core_Next

Quote:

PS. Why use that guide? Debian sid/experimental has everything you need in the repos.
There is mesa 12.0.1 in experimental. You should try upgrading your mesa stack to that one.

I'm not sure about the difference(s) between 12.0.1 and 12.1 either, but now that the user has gone through the trouble to install a local copy of 12.1, it is probably best just to point LIBGL_DRIVERS_PATH to the local version of mesa and see if that works.

gradinaruvasile · 08-25-2016, 06:18 PM

I would advise reinstalling from scratch and using packages only from Debian sid/experimental repos cleanly to make sure no locally installed libs get in the way.

Installing a separate mesa is not trivial, i did it and it's not that simple, you can easily end up mixing loaded library versions and have all kinds of acceleration related issues like this. Also some compile switches change between minor versions sometimes and you really have to look up the options to make sure you actually have everything. And for control i really really recommend using .deb packages.
The only reliable way i found was to actually overwrite the system mesa libraries by creating a mega-mesa .deb package with checkinstall that replaced a truckload of mesa-related packages (and if you want anything 32bit related like Steam you have to do it twice, not specified in that guide, for 64 and 32 bit, the latter i had to compile in a chroot because of some -dev packages). This was working really well (created scripts do all the git fetching+compiling+creating debs) but i abandoned it since nowadays kernel+mesa upgrades are pretty fast in Debian experimental and the code for my video card is stabilized.