SysadminNews

AMD RDNA 4m firmware: what reached Linux, and what did not

On this page
  1. Read the merge at component level
  2. Three dependencies, then an actual workload
  3. A concrete acceptance worksheet

AMD firmware for GC 11.7 reached linux-firmware on August 21. That is an identifiable step toward support for the GPUs LLVM calls RDNA 4m, but it is not a launch announcement or a complete compatibility result.

Firmware, kernel driver and user-space graphics support are separate dependencies. Display, rendering, resume and video decode require distinct observations on actual hardware.
Firmware, kernel driver and user-space graphics support are separate dependencies. Display, rendering, resume and video decode require distinct observations on actual hardware. Chart : PeopleAreGeek. Data source.
View full-size image

Read the merge at component level

The linux-firmware merge introduces GC 11.7.0 and 11.7.1 files, with associated PSP, SDMA, VPE and display-controller firmware. DCN 4.2 DMCUB is already among the changes; it should not be described as merely a possible later addition.

These names identify hardware blocks and firmware versions. The LLVM processor table groups GFX11.7 under RDNA 4m and lists gfx1170, gfx1171 and gfx1172 as APU targets. A compiler target name is not a verified retail product name, release date or specification sheet. The earlier article's proposed product mapping was stronger than this evidence supports.

Three dependencies, then an actual workload

For a graphics application, firmware availability is one layer. The kernel driver must initialize and manage the device; user-space graphics drivers and compilers must support the relevant operations. The application then exercises a particular path through that stack. Updating one layer does not automatically update the others.

The useful distinction is between a file existing upstream, a distribution packaging it, and the running system loading the intended version. A distribution can lag the upstream repository, or carry backports that make a simple minimum-version rule misleading. This merge alone does not justify promising that a named kernel and Mesa pair supports every function.

A concrete acceptance worksheet

On actual hardware, record the device identifier, distribution package versions and firmware-loading messages before interpreting a failure. Then separate four outcomes: display output, accelerated rendering, suspend/resume and the particular video codec needed. Successful desktop startup does not answer all four questions.

For an original example, suppose a laptop displays the desktop and renders a scene but loses the screen after resume. The first two observations remain valid; they do not turn the third into a pass. Likewise, a codec failure should not be reported as proof that all GPU acceleration is absent.

This is a proposed way to evaluate forthcoming support. PeopleAreGeek has not tested an RDNA 4m laptop or installed these firmware files to produce benchmark results. The news here is the upstream component delivery, with the rest of the stack still requiring version-specific evidence.

Verify the actual firmware merge and LLVM names; distinguish firmware availability from a complete tested graphics stack.