Vulkan with AMD's GCN 1.0

Hello Lvl1Forums!

I was wondering if you can help me out here, I’m a couple of weeks deep into getting this to work and I’m loosing hope.

I’m running a R9 280X (GCN 1.0 GPU, pretty much a rebranded HD 7970), and I’m using Pop_OS! (which is just a Ubuntu 18.04LTS re-skin that uses systemd-boot instead of the typical grub boot).
I want to use vulkan, I know it’s supported on this GPU. However there are 3 types of AMD drivers (to my knowledge), the proprietary one (which currently is AMDGPU-PRO), and two opensource drivers (RADEON and AMDGPU). The proprietary isn’t fully supported on my GPU, and I prefer sticking to opensource software.
Vulkan drivers don’t come ready out of the box, so I installed them by following a couple of guides, I believe they are properly installed. I also know there is RADV and AMDVLK.

My kernel is: 4.18.5-041805-generic
Mesa is: Mesa 18.3.0-devel
My driver PPA is Oibaf

This is the error I get:

eze@pop-os:~$ vulkaninfo
===========
VULKAN INFO
===========

Vulkan Instance Version: 1.1.70

ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_intel.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_radeon.so: wrong ELF class: ELFCLASS32
/build/vulkan-Kbdbga/vulkan-1.1.70+dfsg1/demos/vulkaninfo.c:2700: failed with VK_ERROR_INITIALIZATION_FAILED

This is what happens:

eze@pop-os:~$ lspci -k | grep -EA3 'VGA|3D|Display' 
20:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X]
	Subsystem: XFX Pine Group Inc. Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X] (Tahiti XTL [Radeon R9 280X])
	Kernel driver in use: radeon
	Kernel modules: radeon, amdgpu

As you can see I’m stuck with RADEON.
According to Phoronix, as well as other forums, I should update grub with the proper kernel option. So I edited /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT=“radeon.si_support=0 amdgpu.si_support=1”

In addition I added this:

eze@pop-os:/etc/X11$ cat xorg.conf
Section "Device"
    Identifier "AMD"
    Driver "amdgpu"
    Option "TearFree" "true"
EndSection

The last hits on the nail’s head were trying a blacklist.

Added this into /etc/modprobe.d/blacklist.conf

#GPU
blacklist radeon

and then I updated initramfs

I’ve also tried a couple other ways to blacklist this, just like adding it to /etc/default/grub
#GRUB_CMDLINE_LINUX_DEFAULT="modprobe.blacklist=radeon"
But it didn’t accomplished anything, so I commented that line.

I read a couple of benchmarks on openbenchmarking.org and people are using GPUs just like mine (GNC 1.0) with AMDGPU + radeon.si_support=0 amdgpu.si_support=1 and having vulkan work successfully.

TL;DR= How can I use AMDGPU instead of RADEON?
or How can I use vulkan while using RADEON?
I don’t want top notch performance, I just want to use vulkan :smiley:

Thanks for all the help provided, this forum already saved my skin a couple of times!!

1 Like

I also have

...
MODULES=(amdgpu)
...

in my /etc/mkinitcpio.conf

Check this out, I know this is Arch, but the principle is the same:

https://wiki.archlinux.org/index.php/AMDGPU

Oh it says right there:

To make sure the amdgpu is loaded first use the following Mkinitcpio#MODULES array, e.g. MODULES=(amdgpu radeon).


Also heads, up it’s GCN :wink: Oh and BTW, I am R9 270X user.

image

Hello there :wink:

Oh my :ashamed: you found me there :stuck_out_tongue:

That arch wiki link seems pretty helpful, I’ve been reading it now.

Just to make sure, it suggests I change the load order for these drivers. Having AMDGPU being the first option, right?

And adding MODULES=(amdgpu radeon) would be the way to do it. Is this something I should edit into /etc/modprobe.d/modprobe.conf) or is it part of /etc/defaults/grub ? (I want to make sure I’m editing the right config file lol).
I haven’t found /etc/mkinitcpio.conf on my system.

Oh I think it’s different on debian based ones, check /etc/initramfs/initramfs.conf? Should look something like this:

As you cam see I only have amdgpu in there. Didn’t blacklist radeon but I don’t have it installed, so I don’t really need to. But if you have both, better blacklist it.

Anyways, add it to the MODULES. then rebuild the initramfs. Should work :wink:

Ok, I readed some documentation about initramfs.
While I can just edit it and then build it again, the intended way is to use initramfs-tools.
One of these tools is meant for modules, (that are loaded either in /etc/modules or /etc/modules-load.d/modules.conf) and it’s /etc/initramfs-tools/modules. After editing that file, update-initramfs -u is run (I use -u so it updates the current initramfs, I’m kinda scared to use -c so it creates a new initramfs).

eze@pop-os:/etc/initramfs-tools$ cat modules
# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
#
# Syntax:  module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod
amdgpu
radeon

only one module per line is supported. I tried with only amdgpu but I also tried the stated above. What’s cool about this tool is that you can specify boot order.

However this did nothing, so I still have radeon as the loaded driver hahahahaha.

Could something be wrong with my AMDGPU driver? I mean, some problem with it that makes the system go “NOPE BACK TO RADEON”?

Hmm, debian systems do initramfs so much differently…

Probably a dumb question, did you reboot after you rebuilt the initramfs?

yeah, i’m pretty much shutting down and turning the system on pretty much after every change that seems relevant, I’m running everything from one SSD, and man this OS boots FAST lol

1 Like

Things like this make me reconsider my OS option, something like Arch where I build exactly what I want to run seem to be the obvious option for a user like me.
However it is intimidating as I’m not that savvy, and also I only have free time with my system on the weekends, during the week it gets used about 30-60 mins per day and for stuff that is kinda critical and needs to work.
So pretty much I use days like this to update stuff, add new software, and game! If I break something I have up to sunday’s night to put everything back the way it was lol.

Well, huh. It was really easy switched for me… So I doubt it’s the drivers. Sorry I am not as familiar with debian based distros, been running Arch since I started using Linux.

1 Like

can you check journalctl (maybe use -a flag for all) maybe there are some errors and AMDGPU can’t start.

Running it with | grep amdgpu gives me details on all sessions. This is the latest session [2065]

Aug 25 15:38:37 pop-os /usr/lib/gdm3/gdm-x-session[2065]: (II) LoadModule: "amdgpu"
Aug 25 15:38:37 pop-os /usr/lib/gdm3/gdm-x-session[2065]: (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so
Aug 25 15:38:37 pop-os /usr/lib/gdm3/gdm-x-session[2065]: (II) Module amdgpu: vendor="X.Org Foundation"
Aug 25 15:38:37 pop-os /usr/lib/gdm3/gdm-x-session[2065]:         All GPUs supported by the amdgpu kernel driver
Aug 25 15:38:37 pop-os /usr/lib/gdm3/gdm-x-session[2065]: amdgpu_device_initialize: DRM version is 2.50.0 but this driver is only compatible with 3.x.x.
Aug 25 15:38:37 pop-os /usr/lib/gdm3/gdm-x-session[2065]: (EE) AMDGPU(0): amdgpu_device_initialize failed
Aug 25 15:38:37 pop-os /usr/lib/gdm3/gdm-x-session[2065]: amdgpu_device_initialize: DRM version is 2.50.0 but this driver is only compatible with 3.x.x.
Aug 25 15:38:37 pop-os /usr/lib/gdm3/gdm-x-session[2065]: (EE) AMDGPU(G0): amdgpu_device_initialize failed
Aug 25 15:38:37 pop-os /usr/lib/gdm3/gdm-x-session[2065]: (II) UnloadModule: "amdgpu"
Aug 25 15:38:37 pop-os /usr/lib/gdm3/gdm-x-session[2065]: (II) UnloadModule: "amdgpu"
Aug 25 15:38:37 pop-os /usr/lib/gdm3/gdm-x-session[2065]:         All GPUs supported by the amdgpu kernel driver
Aug 25 15:38:37 pop-os /usr/lib/gdm3/gdm-x-session[2065]: (II) UnloadModule: "amdgpu"

Am I crazy or it just loads it first (as I commanded) but then it checks DRM version and it realizes its old(???) then it unloads everythig related to AMDGPU and justs gives up on it?

1 Like

Well hey, this is new info. We might get to somewhere :slight_smile:

did you leave this in your kernel command line? This is 100% needed.

Also what is your kernel? (uname -r)
nvm recheked the OP

apparently radeon uses DRM 2.5.0 while amdgpu uses 3.X.X
So this is the radeon driver and amdgpu driver not playing well together on the same system…

Yup, I still have it selected. Tried also putting it in different order, but it changed nothing.

The line currently is>

GRUB_CMDLINE_LINUX_DEFAULT="amdgpu.si_support=1 radeon.si_support=0"

Finally when running X -configure as root I got the following helpful log message before crashing:
amdgpu_device_initialize: DRM version is 2.49.0 but this driver is only compatible with 3.x.x.

After some searching I found that I should blacklist the radeon module to get the amdgpu module working, and indeed adding this file fixed it:

/etc/modprobe.d/blacklist-radeon.conf
# cannot load both amdgpu and radeon
blacklist radeon

Then: sudo update-initramfs -u -k all

Just to be sure, you left the blacklist, and rebuilt the initramfs like this?

I am starting to wonder if Pop OS kernel is compiled with the support for the driver…

You might need to recompile the kernel with CONFIG_DRM_AMDGPU_SI=Y switched on. Seems like Arch Linux default linuxkernel is compiled with those on. Remember GCN 1 is barely supported for AMDGPU.

I also wonder if the order of the kernel args matter. I have them switched.

amdgpu.si_support=1 radeon.si_support=0


Just realized I don’t lol… :man_facepalming:

yup tried this already.

However, I did just built sudo update-initramfs -u -k all
aaaand apparently it killed everything lol.

Basically I think you are right, there isnt proper kernel support here because there isn-t a properly built kernel.

im typing this from recovery, as I can-t boot anymore lol.

I edited the blacklist back, but I need to rebuild initramfs back in order to use it. Do you have any idea on how should I do it from here?

I tried using ctrl+alt+F1 and doing it there, but it-s not responding.

Ouch. Sorry to hear that.

If you can’t boot in even with framebuffer tty. Maybe you can use liveUSB, then chroot into the installed system, delete the blacklist and update initramfs?

The kernel might indeed been compiled without that option…