Mesa 26.2 Adds AMD GFX1156 Plumbing, Pointing to a New Post-Strix-Halo RDNA 3.5 APU

AMD engineers have merged initial support for the GFX1156 graphics IP block into Mesa 26.2, the open-source graphics stack that powers the RadeonSI Gallium3D and RADV Vulkan drivers on Linux. The user-space addition arrives in lockstep with kernel-side enablement targeting the upcoming Linux 7.2 merge window, where the AMDGPU and AMDKFD drivers will pick up the GFX 11.5.6 block and a cluster of companion IP versions.

The version numbering tells most of the story here. GFX1156 decodes as GFX 11.5.6, which slots it firmly into the GFX115x family that AMD uses for its RDNA 3.5 "refresh" generation. RDNA 3.5 is the graphics architecture currently shipping inside AMD's monolithic APUs, including the Ryzen AI 300 "Strix Point" and the larger Ryzen AI Max 300 "Strix Halo" parts. A new entry this late in the 115x sequence means another APU configuration is in the pipeline rather than a discrete GPU or a next-generation architecture.

What ships alongside GFX1156

The kernel submission bundles GFX 11.5.6 with a long list of refreshed IP blocks: SDMA 6.4 for the system DMA engines, NBIO 7.11.5 for the northbridge I/O, IH 6.4 for the interrupt handler, HDP 6.4 for the host data path, MMHUB 3.4.2 and ATHUB 3.4.2 for the memory and address-translation hubs, SMU 15.0.5 for the system management unit, and VPE 2.2 for the video processing engine. That spread of incremented block versions is consistent with a new SoC tape-out rather than a minor stepping, since each subsystem carries its own version identifier that AMD bumps when the silicon changes.

On the Mesa side, the work is deliberately minimal at this stage. The patch routes GFX1156 through the same common driver code paths as GFX1153, exposing no additional feature differences for now. GFX1153 is the version associated with Ryzen AI "Medusa Point," the next mainstream mobile APU line. Reusing those paths is a practical pattern for AMD: get the device recognized and functional early, then layer in any hardware-specific quirks closer to launch. Any divergent behavior, different cache configurations, clock domains, or display capabilities, can be merged later without blocking the initial enablement.

{{IMAGE:2}}

Narrowing down the product

The more interesting detail is what GFX1156 is not. The Mesa change trims the range covered by AMDGPU_STRIX_HALO_RANGE to stop just before GFX1156, which explicitly excludes it from the Strix Halo or Strix Point families. That rules out the parts already on the market.

Working through AMD's roadmap by elimination leaves a short list. The Ryzen AI Max 400 "Gorgon Halo" series is unlikely, since its launch timing suggests Linux support should already be upstream, whether it reuses the existing Strix Halo graphics IP or one of the other reserved versions AMD has staged. At the other end, the Ryzen AI Max 500 "Medusa Halo" SoCs are rumored to move to RDNA5, which would carry a GFX12-class version rather than anything in the 115x range. That positions GFX1156 as a separate off-shoot in the same neighborhood as GFX1153 Medusa Point, plausibly a variant or sibling configuration built on the same RDNA 3.5 graphics generation.

Why early enablement matters

For Linux users, the value of these pre-launch merges is concrete: by the time the hardware reaches retail, distributions shipping recent kernels and Mesa builds will already recognize the GPU and run accelerated graphics and compute out of the box. AMD has standardized on this cadence of submitting IP block support months ahead of product announcements, which is why day-one Linux support on Ryzen APUs has become routine rather than a gamble.

The practical takeaway is that another RDNA 3.5 APU exists in AMD's plans, distinct from everything currently shipping, even if the marketing name stays hidden behind a version number for now. The plumbing is in Mesa 26.2 as of today, ready to meet the kernel-side AMDGPU and AMDKFD support when the Linux 7.2 merge window opens. Whatever GFX1156 turns out to be, the open-source driver stack will be waiting for it.