Which Mesa versions will talk to an old amdgpu? A survey of the DRM version gate

Mesa's AMD code refuses to initialise below a minimum amdgpu uAPI version, and that minimum has been raised four times. If you maintain an out-of-tree or downstream amdgpu — a BSD port, a vendor fork, a frozen kernel — this decides which Mesa releases you can ship, and the answer is not "whatever is current".

Everything below was extracted mechanically from a full Mesa clone (226783 commits, 944 tags) and from Linux's amdgpu_drv.c version log. The extraction points are documented at the end so the numbers can be re-derived rather than trusted.

The worked example is the DragonFlyBSD amdgpu port, which reports DRM 3.27. If you are here for the general table, skip the DragonFly-specific rows.

The gate

ac_query_gpu_info() in src/amd/common/ac_gpu_info.c hard-rejects anything below a minimum, printing "amdgpu: DRM version is X.Y.Z, but this driver is only compatible with A.B.0 or later" and failing. The gate is shared by radeonsi (GL) and radv (Vulkan), so it is all-or-nothing.

Mesa	Released	Minimum amdgpu uAPI
≤ 22.1		no hard reject
22.2 – 23.1	2022-09 → 2023-05	3.15
23.3 – 25.0	2023-11 → 2025-02	3.27 (kernel 4.20)
25.1 – 26.0	2025-05 → 2026-02	3.42 (kernel 5.15)
26.1+	2026-05 →	3.54 (kernel 6.6)

Note 23.3 through 25.0 is a five-release, fifteen-month window at 3.27.

You cannot patch the check out

Each bump also deleted the fallback code for older kernels, so removing the version test from a newer Mesa leaves it calling into uAPI that is no longer conditionally guarded:

The 3.42 bump (8b3056343fe) removed 25 lines and 6 drm_minor branches.
The 3.54 bump (cb469cc945c) removed 76 lines across 11 files.

Worth knowing: the 3.42 bump's stated reason is policy, not a missing feature — "Linux 5.15+ (LTS) has been released in October 31 and it's supported until December 2026. Linux 4.x are very old at this point."

What each bump made unconditional

This is the part that matters if you are deciding what to implement.

3.27 → 3.42 (entering Mesa 25.1)

uAPI	What it is	Mesa 25.1 now	Consequence on an older kernel
3.31	DC can change tiling attributes per flip	GFX9 without dedicated VRAM gets display DCC unconditionally	Real hazard — see below
3.35	`tcc_disabled_mask`	read unconditionally, VRAM-size estimate hack dropped	GFX10+ only; unreachable on older parts
3.36	more status registers readable on si/cik	TMZ probe actually attempts a `GEM_CREATE_ENCRYPTED` alloc	unknown flag, alloc fails, probe returns false — degrades cleanly
3.41	video codec capability query	`AMDGPU_INFO_VIDEO_CAPS` issued unconditionally, return value not checked	query fails, caps stay zero — no hardware decode advertised, no crash

3.42 → 3.54 (entering Mesa 26.1)

uAPI	What it is	Reachable pre-GFX10?
3.43	device hot plug/unplug	Mesa does not consume it
3.44	DCN3 DCC independent block settings	no — needs DCN3
3.45	context stable pstate	yes; `ctx_set_pstate` failure degrades
3.47	`GEM_CREATE_DISCARDABLE`, `VM_PAGE_NOALLOC`	yes — must be accepted
3.48	IP discovery version in HW INFO	still self-guarded by the value being non-zero
3.49	CS gang submit	no — all three Mesa uses need GFX10.3+
3.50	minimum clocks, PEAK_PSTATE sensors	dev_info fields
3.51	PCIe gen and lane count	yes; zero changes a BO-placement heuristic
3.52	`CONFORMANT_TRUNC_COORD` + cache geometry	dev_info fields
3.53	GFX11 CP GFX shadowing	no — needs GFX11
3.54	`CTX_QUERY2_FLAGS_RESET_IN_PROGRESS`	yes; one flag

The 3.42 → 3.54 gap is smaller than twelve version numbers suggests. Everything in it that genuinely needs newer hardware is additionally gated in Mesa by gfx_level >= GFX10_3 / GFX11 / GFX12, so it never executes on older parts. Of the twelve, four are unreachable, five are honest zeros in a struct Mesa already reads, and exactly one — AMDGPU_GEM_CREATE_DISCARDABLE — must actually be accepted or every allocation fails, because Mesa 26.1 sets it unconditionally on any device with dedicated VRAM.

Counter-intuitively, 3.27 → 3.42 is the harder half, because of 3.31.

The one that will bite you: 3.31 and display DCC

If your DM does not program display DCC, Mesa 25.1 and later will corrupt the screen on GFX9 APUs, silently. The chain:

ac_gpu_info.c enables displayable DCC for gfx_level == GFX9 && !has_dedicated_vram — Raven, Picasso, Renoir. The drm_minor >= 31 test that used to guard this was deleted along with the fallback.
The DCC description does not travel via a format modifier. ac_surface.c packs DCC_OFFSET_256B, DCC_PITCH_MAX and the independent-block bits into the legacy tiling flags on GFX9 whether anyone reads them or not. Not advertising DCC modifiers does not protect you.
amdgpu_display_framebuffer_init() validates nothing, so the framebuffer is accepted and the plane is programmed as uncompressed.

Result: compressed data scanned out as raw. Not a clean failure — a corrupt display. Discrete GFX9 (Vega10/Vega20) has dedicated VRAM and is not affected; GFX8 and older are in no branch at all.

Two implementation details from upstream's own reasoning, both easy to get wrong when porting fill_plane_dcc_attributes / fill_plane_tiling_attributes:

Do not write through plane_state. The state passed in is usually the one the hardware is scanning out, and DC compares it against the update structures to decide what to program. Modifying it in place makes the comparison find nothing to do, and nothing gets programmed.
Fill plane_info completely before overwriting tiling and dcc. DC reprograms whatever it is handed, so a half-filled plane_info zeroes the format, size and rotation.

Other gates, for completeness

Path	Gate	Since
radeon kernel driver (r300g/r600g/radeonsi)	DRM ≥ 2.50	2.3 in 11.2, 2.12 in 12.0, 2.50 since 22.2 and unchanged. See below — this path matters more than it looks
i915 (iris)	no DRM version test; needs `I915_PARAM_HAS_CONTEXT_ISOLATION`, i.e. kernel ≥ 4.16	Mesa 20.1, unchanged since
nouveau (NVK)	nouveau DRM ≥ 1.3.1	Mesa 23.3, unchanged since
amdgpu, second gate	`drmGetCap(DRM_CAP_SYNCOBJ)` must be non-zero	alongside the version gate

Intel has not moved its floor in six years. That contrast with amdgpu is the single most useful thing in this document if you are planning a port.

The escape hatch: radeonsi still drives the radeon kernel driver

Everything above concerns the amdgpu kernel driver. radeonsi has a second path that skips all of it, and it is easy to miss:

/* src/gallium/drivers/radeonsi/si_pipe.c, still there in 26.1 */
switch (version->version_major) {
case 2:  rw = radeon_drm_winsys_create(fd, config, ...);   /* radeon */
case 3:  rw = amdgpu_winsys_create(fd, config, ..., false); /* amdgpu */
}

The version ladder lives in ac_query_gpu_info(), which is only reached on the case 3 branch. A GCN card driven by the radeon kernel driver goes through radeon_drm_winsys instead and never sees it.

That path has its own gate, in radeon_drm_winsys.c: major must be 2 and minor at least 50. It went 2.3 → 2.12 → 2.50, and has not moved since July 2022 — four years, against three raises on the amdgpu side in the same period.

So on a kernel whose radeon driver reports 2.50 or better, SI and CIK — GCN1 and GCN2, the HD 7000 and R7/R9 200 families — get full radeonsi acceleration on Mesa 26 with none of the work described above. Which kernel driver claims those chips is a build-time and module-parameter decision, not a Mesa one:

chips	Linux default	DragonFly default
SI (Tahiti, Pitcairn, Verde, Oland, Hainan)	amdgpu (`radeon.si_support=0`)	radeon — SI is `#ifdef`-ed out of amdgpu entirely
CIK (Bonaire, Hawaii, Kaveri, Kabini, Mullins)	amdgpu (`radeon.cik_support=0`)	radeon — `amdgpu.cik_support=0`, the reverse of upstream

Worth checking before porting anything: if the cards you care about are GCN1 or GCN2, the radeon driver may already get you there, and the amdgpu uapi work is only needed from GFX8 (Tonga, Fiji, Polaris, Carrizo, Stoney) onward, where radeon does not bid at all.

Generation coverage over time

Maximum supported generation per Mesa release, extracted from enum amd_gfx_level, include/pci_ids/*.h, and nvc0_screen.c's chipset switch.

Mesa	Date	AMD	Intel	NVIDIA (nouveau gallium)	NVK
11.2	2016-04	GFX8 · GCN3/4	Gen9 · Broxton	Maxwell	—
13.0	2016-11	GFX8	Gen9	Pascal	—
17.1	2017-05	GFX9 · Vega	Gen9 · Gemini Lake	Pascal	—
17.2	2017-09	GFX9	Gen10 · Cannon Lake	Pascal	—
18.1	2018-05	GFX9	Gen11 · Ice Lake	Pascal	—
19.2	2019-09	GFX10 · RDNA1	Gen11	Pascal	—
19.3	2019-12	GFX10	Gen12/Xe-LP · Tiger Lake	Pascal	—
20.2	2020-09	GFX10_3 · RDNA2	Gen12 · DG1	Turing	—
22.0	2022-03	GFX10_3	Xe-HPG · Alchemist	Turing	—
22.2	2022-09	GFX11 · RDNA3	Xe-HPG	Turing	—
23.0	2023-02	GFX11	Xe-LPG · Meteor Lake	Ampere	—
23.3	2023-11	GFX11_5 · RDNA3.5	Xe-LPG	Ada	first appears
24.2	2024-08	GFX12 · RDNA4	Xe2 · Battlemage	Ada	Turing–Ada
24.3	2024-11	GFX12	Xe3 · Panther Lake	Ada	Turing–Ada
25.2	2025-08	GFX12	Xe3 · Wildcat Lake	Ada	Turing–Ada
25.3	2025-11	GFX12	Xe3	Ada	Kepler–Ada + Blackwell B
26.0	2026-02	GFX12	Nova Lake	Ada	same

Minimums barely moved: AMD stays at R300 (r300g/r600g/radeonsi are all still in tree at 26.1); Intel stays at Gen3 via the i915 gallium driver; NVIDIA's floor rose from NV04 to NV30 when nouveau_vieux was removed in 22.0.

Two things worth noting. nouveau gallium's ceiling has been stuck at Ada since late 2023 — everything past that goes through NVK and GSP, not gallium. And NVK's hardware floor has always been Kepler, but until 25.3 only Turing–Ada was enabled by default; older parts needed NVK_I_WANT_A_BROKEN_VULKAN_DRIVER=1. From 25.3 an nvk_is_conformant() helper enables Kepler–Ada plus Blackwell B, still excluding Tegra.

Worked example: the DragonFlyBSD port

Driver	Reports	Hardware
amdgpu	DRM 3.27	GFX8 (Tonga/Fiji/Polaris/Carrizo/Stoney) – GFX9 (Vega/Raven). GFX7 CIK behind a tunable, default off. SI is `#ifdef`-ed out entirely. No RDNA.
radeon	DRM 2.50	R100 – GFX7 Sea Islands (Hawaii/Mullins), including all of SI
i915	DRM 1.6	Gen2 (i830) – Gen11 (Ice Lake)
nvgpu (native, GSP)	nouveau DRM 1.3.1	Turing TU102/104/106

3.27 passes the 3.27 gate exactly at the boundary, so Mesa 23.3 – 25.0 works unmodified. NVK's floor of 23.3 sets the lower end, amdgpu's 3.27 the upper. The newest usable release is 25.0.7.

Note that this only concerns GFX8 and later. SI and CIK on this system belong to the radeon driver, which reports 2.50 and clears the radeonsi gate above, so those cards are already served by Mesa 26 without any of it.

The constraint that moves is amdgpu's, and it is the only one. i915 contributes nothing — its Gen11 ceiling has been covered since Mesa 18.1 and the 4.16 kernel requirement has not changed. nvgpu's Turing has been covered by nouveau gallium since 20.2 and by NVK since 23.3, and its 1.3.1 is exactly NVK's floor.

How the numbers were extracted

Re-derivable, and two traps that produced wrong answers first:

amdgpu gate — the hard-reject branch in ac_gpu_info.c that prints "only compatible with X.Y" and fails. The same file contains many drm_minor < N feature probes which are not admission tests; conflating them is how you conclude the window is empty. (A drm_minor < 36 in has_tmz_support() looks exactly like a gate and is not one.)
AMD generation — last entry of enum amd_gfx_level in src/amd/common/amd_family.h; before 17.0, enum chip_class in src/gallium/drivers/radeon/radeon_winsys.h. Strip comments before parsing: SI, /* GFX6 */ truncates a naive split on commas and silently reports an older ceiling.
Intel generation — last CHIPSET() in include/pci_ids/{iris,i965,crocus}_pci_ids.h; these files are ordered oldest to newest.
NVIDIA generation — the switch (dev->chipset & ~0xf) case list in nvc0_screen.c. 0xc0/0xd0 Fermi, 0xe0–0x100 Kepler, 0x110/0x120 Maxwell, 0x130 Pascal, 0x140 Volta, 0x160 Turing, 0x170 Ampere, 0x190 Ada.
NVK range — nvk_physical_device.c: the cls_eng3d < KEPLER_A reject, and either the hardcoded TURING_A … ADA_A range or nvk_is_conformant().
Kernel side — the version log comment block at the top of Linux's drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c. Note the version-bump commit is often separate from the commit that implements the feature; 3.37's bump changes only the number, and the actual change (652a6a858fcf) touches only sdma_v5_0.c, making it a GFX10-only fix.

Caveats

None of the DragonFly-side conclusions have been verified at runtime. No card, and the driver has not been loaded. Passing the version gate is necessary, not sufficient.

The Mesa-side analysis is a static reading of call sites at specific tags. If you are relying on it, check the tag you actually ship.

lileding/mesa-amd-drm-gate.md

Select an option

No results found