Talk:AMDGPU

From ArchWiki

Supported Hardware

I just crawled the product names "Radeon xyz" of VI/CI GPUs together and was going to go on for professional products "FirePro xzy", too.

Afaik, there is no such complete listing on the web. There is a lot of confusion about the code and product names, due to AMD repeatedly rebranding their products and even change code names for same GPUs (Tonga = Antigua, Hawaii = Grenada, Carrizo = Bristol Ridge?, ...)

When I started using gnu/linux, the arch wiki was a great help and there are still a lot of people struggling with graphics drivers. Now I know it is not hard to understand, but it is still confusing for beginners, coming from windows and just being used to install one software suite (not a drm driver, libdrm, mesa, gallium, etc.), supporting all the current hardware.

now everyone has to go through all of this every time to determine 1) which hardware is really in their product and 2) which driver suits their hardware


tl;dr I think maintaining such a list would be really useful for beginners, maybe not here but in a separate article? Iuno (talk) 09:27, 16 February 2016 (UTC)Reply[reply]

Well, Gentoo wiki has a simple two-line summary. If it's still not sufficiently clear or the list is already much larger, I guess we could have a separate subpage to not clutter the main page... -- Lahwaacz (talk) 10:20, 16 February 2016 (UTC)Reply[reply]
yes, in the meantime I also found this table. It looks good but it is not complete. And completing the list would blow up the table cells a lot. I guess we should wait until vulkan and the new OpenCL driver has been released. Until then, there is no real reason for owners of pre-VI hardware to switch over to amdgpu. All vi and post-vi will be covered, so there is no need to list those separately. For the others I could create a subpage when switching to amdgpu gives you the opportunity for opencl 2.1 and vulkan -- Iuno (talk) 10:50, 16 February 2016 (UTC)Reply[reply]

Enable amdgpu for Sea Islands Cards

testing my Hawaii card w/ amdgpu last week, sound did not work, even though 6 pcm/hdmi audio devices were listed. Might be added as an issue (as I think this is important deciding between radeon and amdgpu), but needs further investigation/confirmation from other testers. Iuno (talk) 09:53, 16 February 2016 (UTC)Reply[reply]

Please remember the AMDGPU is still in beta, and there's still info and knowledge/experience missing (e.g. most users use the Radeon driver).
AMD isn't that great in providing info and so far a lot of users are confused about their hardware support in use with amdgpu.
Remember there are flags like exp_hw_support. More info need to be added, but it will take some time.
Francoism (talk) 13:14, 16 February 2016 (UTC)Reply[reply]
It does indeed seem like that was no CI issue. Audio over hdmi is not supported by amdgpu atm, respectively only with the (upcoming) DAL changes[1], although it is listed as 'done' here. Iuno (talk) 15:59, 22 February 2016 (UTC)Reply[reply]

Sea Islands cards not working with 4.5.x?

I stumbled across this wiki page in hopes of getting more performance after seeing Michael from Phoronix get his 290 working with this. Following through all the instructions, menuconfiging and compiling new kernels, in the end all I get is a blank screen with my r9 390. No errors on Xorg.0.log. Can anyone confirm that it isn't just me? Katorisenko (talk) 07:46, 24 April 2016 (UTC)Reply[reply]

AMDGPU and HDMI Audio

According to this Freedesktop.org bug comment, HDMI audio support in AMDGPU requires DAL which is "not upstream yet", and won't be anytime soon according to this Phoronix article. I'm currently struggling to make my HDMI audio work with my AMD Radeon R9 380; if this happens to be impossible with AMDGPU, should we mention it in the "Troubleshooting" section of this page? --Hellpe (talk) 23:26, 3 January 2017 (UTC)Reply[reply]

I am in favor of adding the information notice to the troubleshooting section. I think users who do not keep up with the news will be confused when Pulseaudio seems to add the HDMI audio devices, despite them being non-functional until the DAL code is refactored and accepted upstream then pushed to regular users. I know it was not immediately clear to me when I upgraded from my radeonsi card to an RX series amdgpu card until I did some reading. I "think" currently the only way to get HDMI audio is to use the AMDGPU-PRO driver for the time being. Ase1590 (talk) 15:48, 4 January 2017 (UTC)Reply[reply]
I have it working with an R9 380 under Xorg. I did nothing special, simply disabled the built-in audio and enabled the HDMI audio. It does not work under Wayland however. Pavucontrol shows unavailable. Unit73e (talk) 12:22, 2 December 2017 (UTC)Reply[reply]

Some experiments with integrated AMD graphics

Some results after playing with "radeon" and "amdgpu" drivers and gnome (for AMD A10 7850K):

- Having both drivers loaded causes systemd to hang at system shutdown (xorg). Using amdgpu and blacklisting radeon or using radeon and blacklisting amdgpu both fix this problem.

- Having amdgpu driver without mkinitcpio.conf entry causes 1. Wayland can't be enabled (always in xorg mode) and XDG_SESSION_TYPE shows "x11" 2. HDMI sound output is shown only in rare cases

- Having amdgpu driver with mkinitcpio.conf entry causes 1. Wayland is enabled by default and XDG_SESSION_TYPE shows "wayland" 2. HDMI sound is always disabled

- Having radeon driver without mkinitcpio.conf entry causes 1. Wayland can't be enabled (always in xorg mode) and XDG_SESSION_TYPE shows "x11" 2. HDMI sound is always correctly detected and working

- Having radeon driver with mkinitcpio.conf entry 1. Wayland is enabled by default and XDG_SESSION_TYPE shows "wayland" 2. HDMI sound is always correctly detected and working

Beoldhin (talk) 19:07, 23 May 2017 (UTC)Reply[reply]

Update: with kernel 4.11.2-1: HDMI sound output is now working with "amdgpu" but only in as "Gnome in xorg" login option (still no sound with Wayland). There are still some graphical glitches when running Wayland with the radeon driver: external screen doesn't turn off after timeout, windows can't be maximized with the "wmctrl" command and updating text in terminal causes some text updating problems (these don't exist with xorg, amdgpu and radeon both work fine). So in summary: I can now select either amdgpu or radeon driver but Wayland is still unstable.

Beoldhin (talk) 19:07, 23 May 2017 (UTC)Reply[reply]

Vega Changes for Wiki

With Vega releasing around the end of the month, the DC/DAL is still not it the kernel. Should we just put a note for users to use the AMDGPU-PRO drivers if they have VEGA cards? We could possibly add a note saying that in the AUR, there is an alternate kernel built from their repos with the DC/DAL code. Alternate kernel--> linux-amd-staging-gitAUR Sesese9 (talk) 00:40, 10 July 2017 (UTC)Reply[reply]

Moving "Enable GPU display scaling" to xrandr

I thought about it to put this under xrandr directly, but for example for my integrated Intel 6th gen GPU I don't have the "scaling mode" option, and I don't know about NVIDIA. And even if the "scaling mode" option exists for other vendors and or cards, I don't know if the possible values for "scaling mode" are the same everywhere, as far as I remember there are not. That was the reason I did put it here. Bertl (talk) 16:01, 18 February 2018 (UTC)Reply[reply]

Ok, looks like Intel uses the same settings, but it's only available for internal (LVDS, eDP) ports, but at least according to https://bugs.freedesktop.org/show_bug.cgi?id=90989 it also uses "None, Full, Center, Full aspect".
I know that radeonsi uses the same commands, but still don't know about NVIDIA.
But yea, now I also think that it should be moved and the Intel section should be merged into it. Bertl (talk) 18:37, 18 February 2018 (UTC)Reply[reply]

Update on kernel parameters

this part does not seems to be required on 4.17:

>> 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.

—This unsigned comment is by Lesto (talk) 12:10, 22 April 2018‎. Please sign your posts with ~~~~!

Renaming AMDGPU-PRO to Radeon Software for Linux?

So AMD basically changed the name of their AMDGPU-PRO driver as simply Radeon™ Software for Linux, see 17.40, 18.10 and 18.20 preview release notes. With that in mind, should the names on wiki be slowly changed, or the alternative name/note being added somewhere? I'm not sure if AMDGPU-PRO is still used by AMD officially and whether AMDGPU (without PRO) term is being used as well, but the name sure definitely stuck among community – any ideas? Faalagorn / 17:33, 11 May 2018 (UTC)Reply[reply]

EDIT: Probably worth noticing is the similar situation happened between Fglrx and AMD Catalyst naming back then. Faalagorn / 17:38, 11 May 2018 (UTC)Reply[reply]

Vulkan support for FreeSync on Mesa 19.1

Mesa 19.1 recently came out and it supposedly has FreeSync support for Vulkan. I can't test it right now but I was running the freesync patch before 19.1 and it worked for me. Anyone can confirm it is working on 19.1 and edit the FreeSync part about "only OpenGL is supported"

Igo95862 (talk) 08:56, 5 July 2019 (UTC)Reply[reply]

Move Variable Refresh Rate to New Page

NVIDIA has supported freesync for a while now as well as having their own variable refresh rate technology (Gsync). I think it would make more sense to make a separate page for it. Cknight70 (talk) 17:00, 2 August 2019 (UTC)Reply[reply]

I have started writing the article on my personal page. Please feel free to make edits, I will create the new page in a couple of days if there are no objections. Cknight70 (talk) 18:58, 3 August 2019 (UTC)Reply[reply]
Check out Variable Refresh Rate Cknight70 (talk) 15:49, 9 August 2019 (UTC)Reply[reply]

OpenCL implementation?

I've just spent the past day finding out how to get OpenCL to work with AMDGPU and I just found the answer on the Blender page by using opencl-amdAUR. I don't really know if it would fit in with the page (as I could of solved this much sooner by searching up OpenCL and just looking at GPGPU) but I was still confused by people saying that only AMDGPU-PRO has OpenCL 2 support, so if it was mentioned somehow on the page I think it would be very helpful. Polygonerror (talk) 15:45, 20 December 2019 (UTC)Reply[reply]

Navi power consumption addition: Idle power consumption & memory clocks with Navi 10 and multiple monitors

Using a Gigabyte 5700 XT Gaming OC and 2 Monitors (LG OLED 55" and Dell 25") connected, the GPU won't throttle down and uses around 30W in idle. Xorg.conf and xrandr etc. don't help. A workaround is to suspend and resume, using the following as an systemd user job.

.config/systemd/user/xrandr.service

[Unit]
Description=xrandr
After=suspend.target

[Service]
Type=oneshot
Environment=DISPLAY=:0
ExecStart=/usr/bin/xrandr -s 2560x1440 --dpi 117 --output DisplayPort-2 --mode 2560x1440 --primary --output HDMI-A-0 --same-as DisplayPort-2  --scale-from 2560x1440 --mode 1920x1080 --rate 60 --dpi 96
ExecStart=/usr/bin/xrandr --output HDMI-A-0 --off


[Install]
WantedBy=suspend.target

Change ports and resolutions and enable with

systemctl --user enable xrandr

Setting --rate of the LG OLED to 120 will not reduce power consumption as much, because the GPU needs to clock the memory higher.

Everything works as expected after resuming. Power1 from amdgpu is around 9-10W in idle.

Is there anything official to fix this that I didn't find?

The problem is still present in 5.5.15-1-ck and 5.6rc7-1.

Is it OK to include this in the troubleshooting section ?

Strikemybread (talk) 11:29, 7 April 2020 (UTC)Reply[reply]

still present in 5.7-mainline Strikemybread (talk)
OK, using a modeline _without_ reduced blanking gives proper power usage right after boot (cvt 2560 1440 60). More than the max. reported pixel clock of the monitor(connection). Power reading is now ~10 W, with workaround above ~ 8 W. And, workaround doesn't work anymore with > 5.9.14. Strikemybread (talk)

Adding suggestion to install `xf86-video-amdgpu` when using southern islands gpu?

In my case it wasn't possible to create `/etc/X11/xorg.conf.d/20-amdgpu.conf` and restart pc without crash. (for tearfree option)

—This unsigned comment is by Shfil (talk) 18:53, 18 June 2020‎. Please sign your posts with ~~~~!

amdvlk inclusion

I've noticed that amdvlk isn't properly explained or listed as an option, nor is there a clear explanation about how amd gpu drivers can be installed along side each-other and switched between; this is particularly relevant when you consider how trivial it is to switch between divers when amd gpus are compared to nvidia gpus. The wiki could be more clear, complete, and comprehensive if it included such information.

Additionally there is a comment under the AOC compiler section which flatly states mesa with the AOC compiler preforms better than amdvlk, unfortunately that is inaccurate. There are still applications/games which require or preform much better under amdvlk. Also because the drivers in question are still very much "moving targets" its unlikely for one driver to be definitively better than the other for quite sometime.

Desulate (talk) 22:27, 28 November 2020 (UTC)Reply[reply]

Enable Southern Islands (SI) and Sea Islands (CIK) support

This chapter is entirely obsolete, at least for Navi GPUs (Radeon Pro W5700 in my case).

No {cik,si}_support module parameters are needed and things work fine with amdgpu out-of-the-box. There is no need for radeon anywhere in this context; it can be just blacklisted (or not; it doesn't matter). (Also, there is a separate Wiki page for radeon and legacy GPUs; radeon should be mentioned (only) there.) Andrej (talk) 19:25, 15 December 2020 (UTC)Reply[reply]

You are missing the purpose of these parameters. On some old gpus the radeon driver is loaded by default, but they could work with amdgpu also. These parameters are for activating amdgpu driver for them. Ashark (talk) 19:38, 15 December 2020 (UTC)Reply[reply]

Section about Colour Spaces and how to change them

I recently read about the issues around colour spaces with AMDGPU via HDMI. Apparently? AMDGPU uses YCbCr color format. There should be a section explaining how to change this behavior, as it is a common issue among users, causing weird colors with monitors in some cases. This blog post shows a possible workaround, by editing the monitor's EDID and passing that to KMS with a kernel parameter. Though it might not be the desired workaround for many people. The section should also mention possible settings on the monitor itself (changing colour space there).

Scrumplex (talk) 08:47, 7 April 2021 (UTC)Reply[reply]