From Gentoo Wiki
Jump to:navigation Jump to:search
This is a talk page. Please add newer comments below older ones, and sign your comments using four tildes (~~~~). When adding a new section (at the bottom of the page), please mark it as "open for discussion" by using {{talk|open}} so it will show up in the list of open discussions.

Firmware for R500?

Talk status
This discussion is done.

It is now claimed that "IRQ microcode is required for R500 and newer GPUs." This is misleading. The R520_cp.bin file which is mentioned for whatever historical reason in the firmware table has been part of a non-deblobbed kernel since it gained support for R500.

If there are no objections I will revert the misleading change and also remove the reference to R520_cp.bin.

Removed. --Chithanh (talk) 12:42, 8 September 2013 (UTC)

glamor acceleration

Talk status
This discussion is done.

Currently, glamor is listed as not recommended. But it is the only working 2D acceleration for Southern Islands. Should the recommendation be changed, or a note be added to the table of USE flags? --Chithanh (talk) 19:37, 9 May 2013 (UTC)

Remove the non recommendation and add to the USE flag description a note. Astaecker (talk) 08:03, 10 May 2013 (UTC)
Like that? {{USEflag|package=x11-drivers/xf86-video-ati |glamor++no+For pre-Southern Islands cards |glamor++yes+For Southern Islands and newer |udev+yes+yes }}
--Chithanh (talk) 16:54, 11 May 2013 (UTC)
Nice solution. But don't miss the USE flag description:

{{USEflag|package=x11-drivers/xf86-video-ati |glamor++no+(For Northern Islands and older cards) Enable Glamor OpenGL 2D acceleration |glamor++yes+(For Southern Islands and newer cards) Enable Glamor OpenGL 2D acceleration }}

Astaecker (talk) 07:37, 13 May 2013 (UTC)
ok, I added descriptions. --Chithanh (talk) 17:05, 16 May 2013 (UTC)

Firmware for UVD

Talk status
This discussion is still ongoing.

Since gentoo-sources-3.9.1 the UVD patchset is included. This requires new firmware which has not reached stable yet. The firmware files are the following:

Family/Chipset name Firmware
RV710, RV730, RV740 RV710_uvd.bin

Should they be in the normal firmware table? Or an extra table for the time being? --Chithanh (talk) 19:37, 9 May 2013 (UTC)

Add them to the normal firmware table and use references (below the table) to add additional information, see the Feature table. Astaecker (talk) 08:01, 10 May 2013 (UTC)
Ok, added. --Chithanh (talk) 17:16, 11 May 2013 (UTC)

(possible change in the very files used with recent 4.12.x kernels)
just had problems with 4.12.12 (transition from 4.12.4) on my Kabini system - it would stall at boot for ~50 secs with a message that radeon/bonaire_uvd.bin could not be loaded (error -2). After several checks and recompiles of my kernel (basically just copied the .config from my former kernel) I noticed that bonaire in the error messages was NOT capitalized! So I rewrote .config to include the /lib/firmware/radeon/bonaire_uvd.bin (an not (just) as before the working BONAIRE_uvd.bin) and lo and behold! it would boot again.
So there might be a change in upstream code inbetween the point releases of 4.12 to use bonaire_uvd.bin instead of BONAIRE_uvd.bin. If someone could check this and maybe re-write the howto in the wiki; that would be nice and might be helpful for others, too.
PS: the RX 5xx series is also missing from the list, and since it is an updated polaris 1x arch, it is not entirely certain which firmware in amdgpu/... to use best. (Sorry for the noob formatting.) --Adarion (talk) 13:12, 25 September 2017 (UTC)

addition on RS780 and the likes (onboard Radeon 3xxx, usually comes with 7xxG chipsets)
Today I found that at least recent 4.16.x kernels also want RS780_me.bin and RS780_pfp.bin (plus the already mentioned others). Otherwise you'll get the usual stall for 30 - 60 seconds and a pure text boot. (Older kernels would work without them, iirc. I had some 4.11 running on that system.) --Adarion (talk) 18:32, 6 May 2018 (UTC)


Talk status
This discussion is done.

Is there any reason these two are checked (especially the second one)? Was this just a copy-paste from the intel article, or is there an actual reason why they should be enabled?

KERNEL Including radeon driver
Device Drivers  --->
    Graphics support  --->
        <*> /dev/agpgart (AGP Support)  --->
            <*>  Intel 440LX/BX/GX, I8xx and E7x05 chipset support

--Alec 22:55, 22 November 2011 (UTC)

Good catch! I had this checked in my kernel but it is something specific to my old laptop. --Lidel 23:17, 22 November 2011 (UTC)
Checked today -- my old notebook had i915 intel chip. Sorry about causing confusion. --Lidel 20:30, 24 November 2011 (UTC)
CONFIG_DRM_RADEON - Depends on: HAS_IOMEM [=y] && DRM [=y] && PCI [=y] so it isn't required?
But alas:
"Note that this is the only means to have X/GLX use write-combining with MTRR support on the AGP bus. Without it, OpenGL direct rendering will be a lot slower but still faster than PIO.
So its still a good idea if its sits on a AGP port? Any expert about? /Ni1s 23:22, 22 November 2011 (UTC)
I changed the intel line to AMD (since that's obviously wrong), but I'm now really curious if my PhenomII board with an on-board Radeon needs agpgart... --Alec 02:15, 23 November 2011 (UTC)

Not for Proprietary drivers?

Talk status
This discussion is done.

This wiki appears to be for the open source drivers only, and not for the proprietary AMD/ATI drivers.

If this is correct, the please make a note of this, and redirect those who wish to use proprietary drivers to another source (e.g. Fglrx).

this article is indeed for the open source radeon driver, you could create a new article for the fglrx driver, because they are hardly related. Disi 22:28, 6 July 2012 (UTC)

Radeon HD 7340

I have an AMD E-series APU with Wrestler Radeon HD7340. In addition to the firmware files listet under Evergreen - PALM (Wrestler), I had to include radeon/SUMO_rlc.bin in my kernel to make in work.

Firmware for HD6320 (AMD E-450)

So I have SUMO, when I put: CONFIG_EXTRA_FIRMWARE="radeon/SUMO_me.bin radeon/SUMO_pfp.bin radeon/SUMO_rlc.bin radeon/SUMO_uvd.bin"
dmesg said:

[    1.551956] r600_cp: Failed to load firmware "radeon/PALM_pfp.bin" 
[    1.552056] [drm:evergreen_startup] *ERROR* Failed to load firmware! 
[    1.552106] radeon 0000:00:01.0: disabling GPU acceleration

Here is full output:
So maybe I need both from PALM as well: radeon/PALM_me.bin radeon/PALM_pfp.bin — The preceding unsigned comment was added by Emc (talkcontribs)

I can confirm that, had the same problem with HD6320 and solved it by adding PALM firmware — The preceding unsigned comment was added by Banzai (talkcontribs)
I confirm that. In article we have SUMO, but kernel always try to load PALM, and print "[ 8.069610] [drm:evergreen_init] *ERROR* Failed to load firmware!" in dmesg if in config only sumo (CONFIG_EXTRA_FIRMWARE="radeon/SUMO_me.bin radeon/SUMO_pfp.bin radeon/SUMO_rlc.bin radeon/SUMO_uvd.bin"). This bug of kernel or bug in article? — The preceding unsigned comment was added by Mapt (talkcontribs)


Talk status
This discussion is still ongoing.

I am not sure if "" has any more effect on kernels newer than 3.13. Also this options seems to be accessible by xrandr now:

--EoD (talk) 01:30, 18 March 2014 (UTC)

OpenGL support does not match Xorg features matrix

Talk status
This discussion is still ongoing.

The Xorg features matrix for the Radeon driver lists support for higher versions of OpenGL than this page. Is that a mistake on this page or is there a reason that Gentoo does not support the same versions?

Full memory clock speed

Talk status
This discussion is still ongoing.
With more than one monitor connected, the memory clock will NOT be on full speed as it was before.

Where is the source for this? I remember reading a kernel commit message regarding this change. I remember when 3.13 came out, I disabled dpm (by using the kernel argument) and this worked for a while. Recently I jumped to 3.16.2 and this "trick" doesn't work any more (radeon lags screen updates). I suspect this is caused by the clock speed issue.

Radeon Video Coding Engine firmware (TAHITI_vce.bin) might be needed in other chips

Talk status
This discussion is done.

After going in circles for a while, I have found out that my Apple MacBookPro11,5 laptop has a graphic chip [AMD/ATI] Venus XT [Radeon HD 8870M / R9 M270X/M370X] (rev 83) (lspci -s 01:00), that has PCI ID 1002:6821 (rev 83), subsystem 106b:0149 (lspci -s 01:00), and that thing seems to be a AMD R9 M370X, Mac edition (; — here I am not sure — and that this is some type of Cape Verde chip. When I load radeon kernel driver, it complains it also wants radeon/TAHITI_vce.bin. From the code of the driver (drivers/gpu/drm/radeon/radeon_vce.c), it seems that this applies to all Cape Verde chips, and on all Pitcairn, Oland, Aruba and Tahiti chips too. I don't trust myself enough to add these to the text, nor I have means to test these other cards. --Hamlet (talk) 20:31, 25 July 2016 (UTC) [edited: formatting and signature]

Good information. Please don't forget to sign your contributions to talk pages. Kind regards, --Maffblaster (talk) 19:36, 25 July 2016 (UTC)
Thank you, I have found the relevant Gentoo guidelines (and I am trying to apply them). --Hamlet (talk) 20:31, 25 July 2016 (UTC)

Radeon Video Coding Engine firmware needed for HD7970 (TAHITI_vce.bin)

Talk status
This discussion is done.

Had messages in kernel log complaining about missing this firmware blob after switching from fglrx to radeon, the documentation on this page skips this firmware blob for the HD79XX series in the table. --_andyj_ (talk) 21:17, 25 Sept 2016 (UTC)

The page is totally open for edit! You should add it! :) --Maffblaster (talk) 15:26, 26 September 2016 (UTC)

CONFIG_DRM_FBDEV_EMULATION required for console now?

At some point I lost my access to virtual consoles and struggled to figure out why. It turns out that you need to enable CONFIG_DRM_FBDEV_EMULATION for virtual consoles to work. The description: "Choose this option if you have a need for the legacy fbdev support. Note that this support also provides the linux console support on top of your modesetting driver."

It wasn't obvious to me that this "legacy" support was needed for the built-in virtual console to work. Granted, you don't NEED a virtual console to use linux, but I imagine the typical Gentoo user would appreciate one. --Rich0 (talk) 14:03, 3 July 2017 (UTC)

This is still true currently (kernel 5.9.11). I've tested an AMD laptop and an Intel desktop, both with integrated graphic cards. What happens is that the monitor gets black without backlighting as if it were turned off when it should've entered graphics console mode. You can't see anything but it otherwise works (didn't try to 'startx' though, I wonder if it would've worked, probably so). Unsetting CONFIG_DRM_FBDEV_EMULATION=y (ie. setting it to =n) removes others which I have had set such as these: CONFIG_DRM_KMS_FB_HELPER=y, CONFIG_DRM_FBDEV_OVERALLOC=100, CONFIG_FB_CFB_FILLRECT=y, CONFIG_FB_CFB_COPYAREA=y, CONFIG_FB_CFB_IMAGEBLIT=y, CONFIG_FB_SYS_FILLRECT=y, CONFIG_FB_SYS_COPYAREA=y, CONFIG_FB_SYS_IMAGEBLIT=y, CONFIG_FB_SYS_FOPS=y, CONFIG_FB_DEFERRED_IO=y
--Okwtwnow (talk) 12:10, 29 November 2020 (UTC)


Talk status
This discussion is still ongoing.

AMDGPU drivers for GCN 1.1 are still experimental, therefore I wouldn't recommend on using them instead of radeon drivers.

I think it would be a good idea to warn about it in. "For cards based on Graphics Core Next (GCN) 1.1 and higher, read the AMDGPU article instead." --ET (talk) 21:07, 20 March 2019 (UTC)

Outdated menu options?

From the Radeon#General paragraph, I could not find the options "[*] Enable modesetting on radeon by default", " -*- Support for frame buffer devices ---" nor "< > ATI Radeon display support", in the current latest stable kernel (5.4.48). That part may be a bit outdated. Akar (talk) 00:34, 20 July 2020 (UTC)

Same for the Xorg/Guide#AMD.2FATI article
--Charles17 (talk) 06:32, 20 July 2020 (UTC)