AMD hardware support in Manjaro



Or you just wait a few hours till 55 is released… b13 was released on 27th, so it should be today… - IF nothing serious happens!


It’s not out yet but anyways it’s not that bad, not always happens.


Tids, thank you so much for continually taking this on. I’m still running a GCN 1 GPU and as per the link below I asume there is no point in switching over to AMDGPU yet unless wanting to help test eh?

As well, does anyone know if these big patches will help with older GPUs or are just for Vega and such?

Am willing to help but don’t really know how to do so. Could a guy just run Manjaro with AMDGPU on like a USB stick and have it run tests or something? Please excuse my ignorance! There is a test kernel for AMDGPU with a whole bunch of these updates. Is it possible for us to spin something for Manjaro?


DC is a game-changer for everything using AMDGPU driver.

Manjaro doesn’t need any fancy spinning of anything, since being based on arch it’s simply “1. check AUR 2. profit”


this looks like an arch linux 4.11 kernel with amdgpu + DC/DAL.

here some advice:
when testing this, please keep in the mind the different update cadence of arch and manjaro. this means, if you install an arch linux kernel on manjaro the following situation is likely to happen:
the kernel updates, but kernel modules (like virtualbox host/guest driver, wifi driver, etc.) do not update, because they are manjaro packages. when kernel modules are not in sync with the kernel version, they break!

you can switch to the unstable branch of manjaro, which receives updates much more often. you can also try to install virtualbox from the AUR (i never did that) and hope that it will continue to work. you can also install dkms (including kernel headers and virtualbox module); this should work much better.
in any way, i would keep at least 1 manjaro kernel installed, in case something goes wrong.


Well, that’s what he was looking for.

Manjaro isn’t offering any (and I dunno if it should even) so… That’s it.


that kernel is EOL - so not what he wanted.

It is better to use the mesa-git repo to install the amd staging kernel based on 4.12 with AMDGPU display code integrated - AMD ditched the DC and DAL names. The repository is maintained by an Arch trusted developer.

To install the amd-staging-kernel, you have to simply ad

SigLevel = PackageOptional
Server =$repo/$arch

to the /etc/pacman.conf and do a sudo pacman -Syyu
After that you need to do sudo pacman -S linux-amd-staging linux-amd-staging-headers
After that, for failsafe purposes, do a sudo update-grub and reboot, in grub, chose the amd staging kernel.


They already have updated to kernel 4.12 today.


Isn’t better approach to add the repo so that it updates easily with the rest of packages using pacman?

What about amdgpu-pro? Doesn’t it already come with DC?


Yes it is. AUR is always a bad idea as long as there are repos available with the packages inside. Especially when the repos are maintained by arch developers.
AUR can always contain some user-created bugs, bloatware or even spyware.

It is only working on Ubuntu and RedHat - and has a worse performance then stock amdgpu.


My machine doesn’t boot with this kernel.
It boots with -ck kernel and Manjaro kernels + amdgpu + mhwd-amdgpu + amdgpu-experimental.

eugen@mjaro ~> inxi -Gxxxz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Kabini [Radeon HD 8280 / R3 Series]
           bus-ID: 00:01.0 chip-ID: 1002:9836
           Display Server: x11 (X.Org 1.19.3) drivers: amdgpu (unloaded: modesetting)
           Resolution: 1920x1080@60.00hz
           OpenGL: renderer: Gallium 0.4 on AMD KABINI (DRM 3.10.0 / 4.11.12-1-ck, LLVM 4.0.1)
           version: 4.5 Mesa 17.1.6 (compat-v: 3.0) Direct Render: Yes


I’ve experiment with Aur staging kernel 4.12. It’s working (but not out of the box) with some sound settings issues with alsa/pulse (need some tweeking). I also had to disable sleep timer. When resuming from sleep everything freeze at login. So I just shutdown my tv manually for the moment.

inxi -Gxxxz

Graphics: Card: Advanced Micro Devices [AMD/ATI] Ellesmere [Radeon RX 470/480]
bus-ID: 22:00.0 chip-ID: 1002:67df
Display Server: x11 (X.Org 1.19.3) driver: amdgpu
Resolution: 1920x1080@60.00hz
OpenGL: renderer: Gallium 0.4 on AMD POLARIS10 (DRM 3.18.0 / 4.12.0-1-amd-staging-git, LLVM 4.0.1)
version: 4.5 Mesa 17.1.6 (compat-v: 3.0) Direct Render: Yes


GCN1.0 hardware might require some additional flag tinkering I guess.


Still no time for me because of the new job. Sorry for this.

For the Catalyst situation - what would you think when we remove support for GCN1.0 and later from the catalyst installation scripts, but leave catalyst in there for everything older?


would be a good first approach.


As long as that is, I’m fine.

Btw, I’m told forward references inside module level code have been implemented in ACPICA.
This should make for a step improvement for fglrx when it ships in 4.14.
EDIT: just discovered the changes I was looking forward to, are yet do be released into acpica


fglrx is dead since 2015. It will definitely not be improved anymore.


Well, I get quite a lot of ACPI errors now because of that windows/linux asymmetry.

Call it whatever you want, but if all goes well resuming could even start to work properly for as much as I know.


you are mixing a lot of different things in here.

I guess what you are talking about is AMD’s display code (the former DC/DAL) - it has absolutely nothing to do with the old beast fglrx.

The resume - problem is caused by some blk-mq patches and the mq-schedulers, which have absolutely nothing to do with the graphic drivers.


I’m not sure what in the slightest hell you are talking about.

I stand by what I said. Fglrx, catalyst, is modeled after windows driver. Current linux implementation differs, and that’s making for some issues.

These will be addressed on the next acpica merge.
Suspend problem could improve or not - certainly at least something else will.
Wtf is then?