AMD hardware support in Manjaro

amd
amdgpu
manjaro
graphics
radeon

#148

Hello,

Could someone tell me if Bonaire/Tobago Pro GPU is still working with amdgpu and 4.15 kernel ?
With my card, Xorg is unable to detect which output (hdmi) is connected to the monitor, I had to go back to radeon.

3.806] (II) AMDGPU(0): Output DisplayPort-0 has no monitor section
[ 3.806] (II) AMDGPU(0): Output HDMI-A-0 has no monitor section
[ 3.806] (II) AMDGPU(0): Output DVI-D-0 has no monitor section
[ 3.808] (II) AMDGPU(0): EDID for output DisplayPort-0
[ 3.808] (II) AMDGPU(0): EDID for output HDMI-A-0
[ 3.808] (II) AMDGPU(0): EDID for output DVI-D-0
[ 3.808] (II) AMDGPU(0): Output DisplayPort-0 disconnected
[ 3.808] (II) AMDGPU(0): Output HDMI-A-0 disconnected
[ 3.808] (II) AMDGPU(0): Output DVI-D-0 disconnected
[ 3.808] (WW) AMDGPU(0): No outputs definitely connected, trying again…
[ 3.808] (II) AMDGPU(0): Output DisplayPort-0 disconnected
[ 3.808] (II) AMDGPU(0): Output HDMI-A-0 disconnected
[ 3.808] (II) AMDGPU(0): Output DVI-D-0 disconnected
[ 3.808] (WW) AMDGPU(0): Unable to find connected outputs - setting 1024x768 initial framebuffer


#149

Without deeper knowledge of your card i can say:

Bonaire = GCN 2nd Gen. = Sea Islands

Also, since kernel 4.13, adding the amdgpu.si_support=1 radeon.si_support=0 or amdgpu.cik_support=1 radeon.cik_support=0 kernel parameter is required. Otherwise, AMDGPU will not start and you will end up with either radeon being used instead or the display being frozen during the boot.

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


#150

My card (R7 360 OEM) has been working with amdgpu driver since October 2016 until 4.14 kernel, and boot option in Grub was fine, I had to change it to go back to radeon.


#151

As always, for breakages, I recommend trying linux-amd-staging-git aur package.

As always, I guess, somebody will tell me that’s gonna break something (as if something wasn’t already broken to begin with, and we were checking whether opening a bug on freedesktop was worth a thing)


#152

hey, one part is broken - lets break some more parts and check if the first thing is whole again … lol

do you by any chance still have an xorg.conf or some other graphic-related configs in /etc/X11/xorg.conf.d/?

Which drivers do you have installed in mhwd?


#153

Said that, I’ll remove the video-amdgpu experimental parts of mhwd with the next release. so the only thing remaining will be amdgpu-experimental in pacman. wich will do the whole stuff of switching from radeon to amdgpu, enabling amdgpu.dc on supported hardware (thats what the package already do)


#154

It seems the module was properly loaded :

[ 3.567] (II) LoadModule: “amdgpu”
[ 3.567] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so
[ 3.572] (II) Module amdgpu: vendor=“X.Org Foundation”
[ 3.572] compiled for 1.19.3, module version = 1.4.0
[ 3.572] Module class: X.Org Video Driver
[ 3.572] ABI class: X.Org Video Driver, version 23.0
[ 3.572] (II) AMDGPU: Driver for AMD Radeon:
All GPUs supported by the amdgpu kernel driver
[ 3.572] (II) [KMS] Kernel modesetting enabled.
[ 3.573] (II) AMDGPU(0): Creating default Display subsection in Screen section
“Default Screen Section” for depth/fbbpp 24/32
[ 3.573] (==) AMDGPU(0): Depth 24, (–) framebuffer bpp 32
[ 3.573] (II) AMDGPU(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
[ 3.573] (==) AMDGPU(0): Default visual is TrueColor
[ 3.573] () AMDGPU(0): Option “TearFree” “on”
[ 3.573] (==) AMDGPU(0): RGB weight 888
[ 3.573] (II) AMDGPU(0): Using 8 bits per RGB (8 bit DAC)
[ 3.573] (–) AMDGPU(0): Chipset: “AMD Radeon ™ R7 300 Series” (ChipID = 0x665f)
[ 3.573] (II) Loading sub module “fb”
[ 3.573] (II) LoadModule: “fb”
[ 3.573] (II) Loading /usr/lib/xorg/modules/libfb.so
[ 3.576] (II) Module fb: vendor=“X.Org Foundation”
[ 3.576] compiled for 1.19.6, module version = 1.0.0
[ 3.576] ABI class: X.Org ANSI C Emulation, version 0.4
[ 3.576] (II) Loading sub module “dri2”
[ 3.576] (II) LoadModule: “dri2”
[ 3.576] (II) Module “dri2” already built-in
[ 3.777] (II) Loading sub module “glamoregl”
[ 3.777] (II) LoadModule: “glamoregl”
[ 3.777] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[ 3.784] (II) Module glamoregl: vendor=“X.Org Foundation”
[ 3.784] compiled for 1.19.6, module version = 1.0.0
[ 3.784] ABI class: X.Org ANSI C Emulation, version 0.4
[ 3.784] (II) glamor: OpenGL accelerated X.org driver based.
[ 3.795] (II) glamor: EGL version 1.5 (DRI2):
[ 3.806] (II) AMDGPU(0): glamor detected, initialising EGL layer.
[ 3.806] (
) AMDGPU(0): TearFree property default: on
[ 3.806] (II) AMDGPU(0): KMS Pageflipping: enabled
[ 3.806] (II) AMDGPU(0): Output DisplayPort-0 has no monitor section
[ 3.806] (II) AMDGPU(0): Output HDMI-A-0 has no monitor section
[ 3.806] (II) AMDGPU(0): Output DVI-D-0 has no monitor section
[ 3.808] (II) AMDGPU(0): EDID for output DisplayPort-0
[ 3.808] (II) AMDGPU(0): EDID for output HDMI-A-0
[ 3.808] (II) AMDGPU(0): EDID for output DVI-D-0
[ 3.808] (II) AMDGPU(0): Output DisplayPort-0 disconnected
[ 3.808] (II) AMDGPU(0): Output HDMI-A-0 disconnected
[ 3.808] (II) AMDGPU(0): Output DVI-D-0 disconnected
[ 3.808] (WW) AMDGPU(0): No outputs definitely connected, trying again…
[ 3.808] (II) AMDGPU(0): Output DisplayPort-0 disconnected
[ 3.808] (II) AMDGPU(0): Output HDMI-A-0 disconnected
[ 3.808] (II) AMDGPU(0): Output DVI-D-0 disconnected
[ 3.808] (WW) AMDGPU(0): Unable to find connected outputs - setting 1024x768 initial framebuffer

edit: forgot to mention I could not switch to console through Ctrl+Fx.


#155

Yes, that’s the point. Maybe with a tad less confidence.
Or do you think to be on windows where not even 100 users complaining about the same regression gets heard?


#156

Don’t get angry - in my opinion it is the Linux motto! :smiley:

I know why Linux is the better OS (yeahja, not Linux; get over it) cause i macgyver every day on different Windows systems - and helpful tips like “download this tool, execute it and it will uninstall the app…”


#157

so, if your cars headlight is broken, you also break the engine to check if it fixes the headlight? (and yes, this is the perfect methaphor because the kernel is the engine of Linux, and the screen detection is only a “minor” part)

the sane approach in software development and debugging is: Keep as many parts in a defined and reproducible state and only work on the broken part to really fix it. AUR packages or packages from external repositories are no defined and reproducible state. They bring in a lot of variables that make debugging and bugfixing a lot harder and in some cases make fixing impossible.

Good to know! Could it be that in this case, the activation of amdgpu.dc through the experimental package causes the screen detection issue?


#158

You could just rest this. DC is only on linux 4.15, the activation on 4.14 it’s changing nothing. So if it happens also on 4.14 it’s not dc.
It would be good to know if there is any xorg config and how the display is connected.


#159

No, it’s not better than the “you would download a car” campaign.
Then headlight and engine are by no means correlated in a car.
And last but not least, “it *will* break” … says who?

The kernel is a *single* part (for as much big).
AUR repos are perfectly “reproducible” and defined
And I’m not sure when it was the last time I have seen actual “debugging” on these forums.
At least for voodoo issues with drivers.


#160

Just found something:
All arch based 4.15 and newer kernels have DC enabled per default, even for Pre-Vega cards:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux#n5725
That is also true on Manjaro’s 4.15.8 kernel:

$ zcat /proc/config.gz | grep CONFIG_DRM_AMD
CONFIG_DRM_AMDGPU=m
CONFIG_DRM_AMDGPU_SI=y
CONFIG_DRM_AMDGPU_CIK=y
CONFIG_DRM_AMDGPU_USERPTR=y
# CONFIG_DRM_AMDGPU_GART_DEBUGFS is not set
CONFIG_DRM_AMD_ACP=y
CONFIG_DRM_AMD_DC=y
CONFIG_DRM_AMD_DC_PRE_VEGA=y
# CONFIG_DRM_AMD_DC_FBC is not set
CONFIG_DRM_AMD_DC_DCN1_0=y

Tested it, and only when using the boot parameter amdgpu.dc=0, DC was not loaded (the experimental package is not installed on my system)

I guess that might explain why even GCN 2 cards now tend to use amdgpu instead of radeon without installing the experimental package.


#161

We don’t work on arch kernels tbh.
And philip had already included it months prior to them (though, I’d guess he in turn copypasted somebody else)

Anyway, great news everyone
https://www.phoronix.com/scan.php?page=news_item&px=Airlie-Preps-Soft-FP64-Mesa


#162

thanks.
i have just removed the kernel boot parameter for starting DC.


#163

and that DC behaviour will be mainlined with 4.17:
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-4.17-Default

I guess you can rest the experimental package now :wink: (Or keep it for the GCN 1.0 cards only)


#164

Would be nice to have more experimental stuff enabled as stable function :slight_smile:

Still waiting for deep-color :smiley:


#165

Just to let you know, I can use amdgpu with my R7 360 again, I had to disable DC, now the output to the monitor is detected.


#166

Hi. I think this is a great idea. I just built a system using the Ryzen 5-2400G. I didn’t do enough research and was pretty surprised to find Linux didn’t work, in general with this chip. I finally got it to work somewhat using Ubuntu Budgie, but the performance was awful. It’s supposed to be a fairly snappy chip, and my system was slow and benchmarks I ran were lousy. Until today, I saw Manjaro had an unstable release using Mesa 18 and the newest Linux kernel rc (4.17). So I decided to take the plunge and take the risk of an unstable system. I’ve been running Manjaro all day, and installing, boot up were no problem. So far, the system only crashed once, but benchmarks I ran today with Manjaro show real performance improvement. So, I’m pretty happy at the moment.

I don’t have any coding knowledge or experience, but I can help the effort by being a guinea pig and run the unstable release and provide feedback. I hope this effort will be a big success.

System: Host: john-pc Kernel: 4.17.0-1-MANJARO x86_64 bits: 64 Desktop: KDE Plasma 5.12.4
Distro: Manjaro Linux 17.1.8 Hakoila
Machine: Type: Desktop Mobo: MSI model: B350M GAMING PRO (MS-7A39) v: 1.0 serial: N/A
UEFI: American Megatrends v: 2.F0 date: 03/19/2018
CPU: Topology: Quad Core model: AMD Ryzen 5 2400G with Radeon Vega Graphics type: MT MCP
L2 cache: 2048 KiB
Speed: 1660 MHz min/max: N/A Core speeds (MHz): 1: 1660 2: 1948 3: 1353 4: 1351
5: 1423 6: 1373 7: 2974 8: 2843
Graphics: Card-1: AMD Raven Bridge [Radeon Vega Series / Radeon Vega Mobile Series]
driver: amdgpu v: kernel
Display: x11 server: X.Org 1.19.6 driver: amdgpu,ati
unloaded: fbdev,modesetting,radeon,vesa tty: N/A
OpenGL: renderer: AMD RAVEN (DRM 3.25.0 / 4.17.0-1-MANJARO LLVM 6.0.0)
v: 4.5 Mesa 18.0.0
Audio: Card-1: AMD driver: snd_hda_intel
Card-2: AMD driver: snd_hda_intel
Sound Server: ALSA v: k4.17.0-1-MANJARO
Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8168
IF: enp27s0 state: down mac: 30:9c:23:00:f8:19
Card-2: Linksys AE1000 v1 802.11n [Ralink RT3572] type: USB driver: rt2800usb
IF: wlp21s0f0u6 state: up mac: 68:7f:74:f7:3e:6e
Drives: HDD Total Size: 232.89 GiB used: 12.96 GiB (5.6%)
ID-1: /dev/nvme0n1 model: Samsung_SSD_960_EVO_250GB size: 232.89 GiB
Partition: ID-1: / size: 227.72 GiB used: 12.96 GiB (5.7%) fs: ext4 dev: /dev/nvme0n1p1
Sensors: Message: No sensors data was found. Is sensors configured?
Info: Processes: 227 Uptime: 33m Memory: 7.55 GiB used: 2.44 GiB (32.3%) Shell: bash
inxi: 3.0.04


#167

We should have a linux-amd-staging-(next/git) package at this point, given how many times this week I have been telling people to try it.
… with more often than not, no answer since.