AMD GPUs are famous for working very well on Linux. However, what about the very first GCN GPUs? In this post, I’m going to summarize how well these old GPUs are supported and what I’ve been doing to improve that.

This story is about the first two generations of GCN: GFX6 aka. GCN1 - Southern Islands (SI) and GFX7 aka. GCN2 - Sea Islands (CIK).

Working on old GPUs

While AMD GPUs generally have a good reputation on Linux, these old GCN graphics cards have been a sore spot for as long as I’ve been working on the driver stack.

It occurred to me that resolving some of the long-standing issues on these old GPUs might be a great way to get me started on working on the amdgpu kernel driver and would help improve the default user experience of Linux users on these GPUs. I figured that it would give me a good base understanding, and later I could also start contributing code to newer GPUs.

Where I started

The RADV team has supported RADV on GFX6-7 GPUs for a long time. RADV support was already there even before I joined the team. Daniel added ACO support for GFX7 in November 2019, and Samuel added ACO support for GFX6 in January 2020. More recently, we added a Tahiti (GFX6) and Hawaii (GFX7) GPU to the Mesa CI which are running post-merge “nightly” jobs. So we can catch regressions and test our work on these GPUs quite quickly.

However, the kernel driver situation was less fortunate.

On the kernel side, amdgpu has supported GFX7 since April 2015 and GFX6 since January 2016. DC (the new display driver) has supported GFX7 since September 2017 (the beginning), and GFX6 was added in July 2020 by Mauro. However, neither amdgpu nor DC was enabled by default on the GPUs. Instead, the old radeon driver was the default choice. Unfortunately, radeon doesn’t support Vulkan, so in the default user experience, users couldn’t play most games or benefit from any of the Linux gaming related work we’ve been doing for the last 10 years.

In order to get working Vulkan support, you needed to use the following kernel params:

radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1

Then, you could boot with amdgpu and enjoy a semblance of a good user experience until the GPU crashed / hung, or until you tried to use some functionality which was missing from amdgpu, or until you plugged in a display which the display driver couldn’t handle.

It was… not the best user experience.

Where to go from here?

The first question that came to mind is, why wasn’t amdgpu the default kernel driver for these GPUs? Since the “experimental” support had been there for 10 years, we had thought the kernel devs would eventually just enable amdgpu by default, but that never happened.

At XDC 2024 I met Alex Deucher, the lead developer of amdgpu and asked him what was missing. Alex explained to me that the main reason the default wasn’t switched is to avoid regressions for users who rely on some functionality not supported by amdgpu:

  • Display features: analog connectors in DC (or DP/HDMI audio support in non-DC)
  • VCE1 for video coding on SI

It doesn’t seem like much, does it? How hard can it be?

Display features

On a 2025 summer afternoon…

I messaged Alex Deucher to get some advice on where to start. Alex was very considerate and helped me to get an understanding of how the code is organized and which parts I should start reading. Harry Wentland also helped a lot with making a plan how to fit analog connectors in DC. Then, I plugged my monitors into my Raphael iGPU to be used as a primary GPU, then plugged in an old Oland (GFX6) as a secondary GPU, and started hacking.

Analog connector support in DC

Analog connectors have been actually quite easy to deal with, once I understood the structure of the DC (display core) codebase. I could use the non-DC (legacy) display code as a reference. The DAC (digital to analog converter) is actually programmed by the VBIOS, and the driver just needs to call the VBIOS and tell it what to do. Easier said than done, but not too hard.

It also turned out that some chips that already defaulted to DC (eg. Tonga, Hawaii) also have analog connectors, which apparently just didn’t work on Linux by default. I managed to submit the first version of this in July. Then I was sidetracked with a lot of other issues, so I submitted the second version of the series in September, which then got merged.

Going shopping

It is incredibly difficult to debug issues when you don’t have the hardware to reproduce them yourself. Some developers have a good talent for writing patches to fix issues without actually seeing the issue, but I feel I still have a long way to go to be that good. It was pretty clear from the beginning that the only way to make sure my work actually works on all SI/CIK GPUs is to test all of them myself.

So, I went ahead an acquired at least one of each SI and CIK chip. I got most of them from used hardware ad sites, and Leonardo Frassetto sent me a few as well.

Fixing DC support on SI (DCE6)

After I got the analog connector working using the old GPUs as a secondary GPU, I thought it’s time to test how well it works as a primary GPU. You know, the way most actual users would use them. So I disabled the iGPU and booted my computer with each dGPU with amdgpu.dc=1 to see what happens. This is where things started going crazy…

It turns out that just because DC had code to support these GPUs, doesn’t mean it actually supported them well.

  • Tahiti (R9 280X) booted into “no signal”, absolutely dead
  • Oland (R7 250) had heavy flickering and hung very quickly
  • Oland (Radeon 520) booted into “unsupported signal” with DC and massive flickering with non-DC
  • Pitcairn (R9 270X) had some artifacts
  • Cape Verde (HD 7770) I didn’t even plug it in at this point…

The way to debug these problems is the following:

  • Boot with amdgpu.dc=0, dump all DCE registers using umr: umr -r oland.dce600..* > oland_nodc_good.txt
  • Boot with amdgpu.dc=1, dump all DCE registers using umr: umr -r oland.dce600..* > oland_dc_bad.txt
  • Compare the two DCE register dumps using a diff viewer, eg. Meld. Try to find what are the register differences that are responsible for the bad behaviour.
  • Use umr (either the GUI or CLI) to try to change the registers in real time, poke at it until the issue is gone.
  • Wait until headache is gone.
  • Read the code that sets the problematic registers and develop an actual fix.

I sent a few patch series to address a bunch of display issues with SI (DCE6):

DisplayPort/HDMI audio support on SI (DCE6)

I noticed that HDMI audio worked alright on all GPUs with DC (as expected), however DP audio didn’t (which was unexpected). However it worked when both DP and HDMI were plugged in… After consulting with Alex and doing some trial and error, it turned out that this was just due to setting some clock frequency in the wrong way: Fix DP audio DTO1 clock source on DCE6.

In order to figure out the correct frequencies, I wrote a script that set the frequency using umr then played a sound. I just laid back and let the script run until I heard the sound. Then it was just a matter of figuring out why that frequency was correct.

A small fun fact: it turns out that DP audio on Tahiti didn’t work on any Linux driver before. Now it works with DC.

Poweeeeer

The DCE (Display Controller Engine), just like other parts of the GPU, has its own power requirements and needs certain clocks, voltages, etc. It is the responsibility of the power management code to make sure DCE gets the power it needs. Unfortunately, DC didn’t talk to the legacy power management code. Even more unfortunately, the power management code was buggy so that’s what I started with.

After I was mostly done with SI, I also fixed an issue with CIK, where the shutdown temperature was incorrectly reported.

VCE1 video encoding on SI

Video encoding is usually an afterthought, not something that most users think about unless they are interested in streaming or video transcoding. It was definitely an afterthought for the hardware designers of SI, which has the first generation VCE (video coding engine) that only supports H264 and only up to 2048 x 1152. However, the old radeon kernel driver supports this engine and for anyone relying on this functionality, it would be a regression when switching to amdgpu. So we need to support it. There was already some work by Alexandre Demers to support VCE1, but this work was stalled due to the firmware validation mechanism.

In order to switch SI to amdgpu by default, I needed to deal with VCE1. So I started a conversation with Christian König (amdgpu expert) to identify what the problem actually was, and with Alexandre to see how far along his work was.

  • It turns out that due to some HW/FW limitations, the firmware (VCPU BO) needs to be mapped at a low 32-bit address.
  • It also needs to be in VRAM for optimal performance (otherwise it would incur too many roundtrips to system RAM).
  • However, there was no way for amdgpu to place something in VRAM and map it in the low 32-bit address space. (Note, it can actually do this for the address space of userspace apps, just not inside the kernel itself.)

Christian helped me a lot with understanding how the memory controller and the page table work.

After I got over the headache, I came up with this idea:

  • Let amdgpu place the VCPU BO in VRAM
  • Map the GART (graphics address remapping table) in the low 32-bit address space (instead of using best fit)
  • Insert a few page table entries in the GART which would practically map the VCPU BO into the low 32-bit address space

With that out of the way, the rest of the work on VCE1 was pretty straightforward. I could use Alexandre’s research, as well as the VCE2 code from amdgpu and the VCE1 code from radeon as a reference. Finally, a few reviews and three revisions later, the VCE1 series was accepted.

Final thoughts

Who is this for?

In the current economic situation of our world, I expect that people are going to use GPUs for much longer, and replace them less often. And when an old GPU is replaced, it doesn’t die, it goes to somebody who upgrades an even older GPU. Eventually it will reach somebody that can’t afford a better one. There are some efforts to use Linux to keep old computers alive, for example this one. My goal with this work is to make Linux gaming a good experience for not only who can afford the latest and greatest, but also for those who use old GPUs.

Other than that, I also did it for myself. Not because I want to run old GPUs myself, but because it has been a great learning experience to get into the amdgpu kernel driver.

Why amdgpu? Why DC?

The open source community including AMD themselves as well as other entities like Valve, Igalia, Red Hat etc. have invested a lot of time and effort into amdgpu and DC, which now support many generations of AMD GPUs: GCN1-4, RDNA1-4, as well as CDNA. In fact amdgpu supports more generations of GPUs now than what came before, and it looks like it will support many generations of future GPUs.

By making amdgpu work well with SI and CIK, we ensure that these GPUs remain competently supported for the foreseeable future.

By switching SI and CIK to use DC by default, we enable the amdgpu maintainers to eventually move on from the legacy display code without losing functionality.

What is left to do?

Now that amdgpu is at feature parity with radeon on old GPUs, we switched the default to amdgpu on SI and CIK dedicated GPUs. It’s time to start thinking about what else is left to do.

  • Add support for DRM format modifiers for all SI/CIK/VI/Polaris GPUs. This would be a huge step forward for the Vulkan ecosystem, it would enable using purely Vulkan based compositors, Zink, and other features.
  • Add support for TRAVIS and NUTMEG display bridges, so that we can also switch to amdgpu by default for CIK APUs. I couldn’t find the hardware for this work, if you have it and want to help, please reach out.
  • Refactor SI and KV power management so that we can retire the legacy power management code, which would further ease the maintenance burden of these GPUs.
  • Eventually retire the non-DC legacy display code from amdgpu to ease the maintenance burden.
  • Deal with a few lingering bugs, such as power limit on Radeon 430, black screen with the analog connector on Radeon HD 7790, as well as VM faults on SI/CIK.
  • Verify sparse mapping (PRT) support. I already wrote a kernel fix and a Mesa MR for enabling it.
  • Implement transfer queue support for old GPUs in RADV.

What have I learned from all this?

It isn’t that scary

Kernel development is not as scary as it looks. It is a different technical challenge than what I was used to, but not in a bad way. Just need to figure out a good workflow for how to configure a code editor, as well as what is a good way to test my work without rebuilding everything all the time.

Maintainers are friendly

Although there are a lot of memes and articles on the internet about attitude and rude/toxic messages by some kernel developers, this hasn’t been my experience.

I started talking to the maintainers (who will review my patches) even before I wrote a single line of code, to find what would be a good way to implement things according to them, and what I need to do to get my work accepted. That made the everything faster and more pleasant. In fact, all AMD engineers have been very nice and friendly to me throughout this experience.

Development latency

  • In Mesa, we can merge any features to the next Mesa release up to the branch point, and afterwards we backport bug fixes to that release. Simple and efficient.
  • In the Linux kernel, there is a deadline for merging new features to the next release, and it’s not clearly communicated when that is. Bug fixes may be backported to previous releases any time, but upstream maintainers aren’t involved in that.

There is a huge latency between a developer working on something and the work reaching end users. Even if the patches are accepted quickly, it can take 3~6 months until users can actually use it. In hindsight, if I had focused on finishing the analog support and VCE1 first (instead of fixing all the bugs I found), my work would have ended up in Linux 6.18 (including the bug fixes, as there is no deadline for those).

XDC 2025

I presented a lightning talk on this topic at XDC 2025, you can find the slide deck here and the video here.

Acknowledgements

I’d like to say a big thank you to all of these people. All of the work I mentioned in this post would not have been possible without them.

  • Alex Deucher, Christian König (amdgpu devs)
  • Harry Wentland, Rodrigo Siquiera (DC devs)
  • Marek Olsák, Pierre-Eric Pelloux-Prayer (radeonsi devs)
  • Bas Nieuwenhuizen, Samuel Pitoiset (radv devs)
  • Tom St Dennis (umr dev)
  • Mauro Rossi (DCE6 in DC)
  • Alexandre Demers (VCE1 research)
  • Leonardo Frassetto (donated HW)
  • Roman Elshin and others (testing)
  • Pierre-Loup Griffais (Valve)

Which graphics cards are affected exactly?

When in doubt, consult Wikipedia.

  • GFX6 aka. GCN1 - Southern Islands (SI)
    • Tahiti
      • Radeon HD 7870 XT, 7950, 7970, 7990, 8950, 8970, 8990
      • Radeon R9 280, 280X
      • FirePro W8000, W9000, D500, D700, S9000, S9050, S10000
      • Radeon Sky 700, 900
    • Pitcairn
      • Radeon HD 7850, 7870, 7970M, 8870, 8970M
      • Radeon R9 265, 270, 270X, 370, 370X, M290X, M390
      • FirePro W5000, W7000, D300, R5000, S7000
    • Cape Verde
      • Radeon HD 7730, 7750, 7770, 8730, 8760
      • Radeon R7 250E, 250X, 350, 450
      • FirePro W600, W4100, M4000, M6000
    • Oland
      • Radeon HD 8570, 8670
      • Radeon R5 240, 250, 330, 340, 350, 430, 520, 610
      • FirePro W2100
      • various mobile GPUs
    • Hainan
      • various mobile GPUs
  • GFX7 aka. GCN2 - Sea Islands (CIK)
    • Hawaii
      • Radeon R9 290, 290X, 295X2, 390, 390X
      • FirePro W8100, W9100, S9100, S9150, S9170
    • Bonaire
      • Radeon HD 7790/8870
      • Radeon R7 260/360/450
      • Radeon RX 455, FirePro W5100, etc.
      • various mobile GPUs