```
AMD has opened a Mesa merge request introducing very primitive GFX13 (RDNA5) support to the RADV Vulkan and RadeonSI Gallium3D/OpenGL drivers, according to Phoronix, which reported the move shortly after the company posted corresponding GFX13 patches for the AMDGPU kernel driver earlier the same week.
The sequence matters more than the patch contents. Within days, AMD pushed the kernel-side enablement and then followed with the userspace driver plumbing — a kernel-then-Mesa ordering that signals the open-source graphics stack is being treated as a first-class target for the forthcoming architecture, rather than as an afterthought that trails proprietary or Windows releases.
What "primitive support" actually means
Prospective users should temper expectations. The initial Mesa code is best understood as scaffolding: the baseline recognition and driver plumbing needed for RADV and RadeonSI to know GFX13 exists at all. Substantial functionality — the parts that make games and GPU-accelerated applications run correctly — typically arrives incrementally over many months of follow-up work. A merge request of this kind is a starting gun, not a feature release.
RADV, the open-source Vulkan driver that much of the Linux gaming ecosystem now relies on, and RadeonSI, AMD's long-standing OpenGL Gallium3D driver, are both covered by this first round of enablement, so the two userspace stacks begin from the same starting point rather than diverging at the outset.
Why the sequencing matters for distributions
For Linux distribution packagers and early adopters, the timing is the useful part. Kernel enablement landing first, with Mesa following days later, gives distributions a coherent window in which to assemble a stack that carries both halves of the support at roughly the same point in their release cycles. When kernel and userspace support arrive far apart, packagers can end up shipping half a stack — a kernel that recognises hardware the installed drivers cannot yet drive, or vice versa — and freeze deadlines can strand the gap for an entire release cycle.
That lead time is why an admittedly early-stage merge request is newsworthy at all: it establishes the pattern that downstream projects can plan around, even though nothing usable for RDNA5 hardware is expected to ship for months.
The Phoronix report does not address hardware availability, and readers should be cautious about inferring launch windows from driver-development cadence alone; open-source driver lead times routinely extend well past retail availability, with day-one usability for a new AMD GPU generation historically arriving only after sustained post-launch work.
The realistic timeline
For AMD GPU users on Linux, the practical takeaway is patience framed by good process. The upstream signal is encouraging: AMD is doing the enabling work in the open, in a sequence that downstreams can digest. But the distance between early driver scaffolding and a driver that plays current games reliably remains measured in months of incremental commits, bug fixes, and performance work.
The relevant milestone to watch is not this merge request, but the follow-up rounds of Mesa work that fill in the functionality behind the GFX13 skeleton — and whether that progress lands early enough for major distributions to fold it into their next freeze.
Source: Phoronix
```
據 Phoronix 報導，AMD 已提交一個 Mesa 合併請求，為 RADV Vulkan 及 RadeonSI Gallium3D／OpenGL 驅動程式引入非常初步的 GFX13（RDNA5）支援。相關報導在 AMD 同週稍早發布 AMDGPU kernel 驅動程式的對應 GFX13 修補程式後隨即刊出。
先後次序比修補程式內容更為重要。AMD 在數天內先推送 kernel 端的啟用程式碼，隨後再跟進 userspace 驅動程式的接駁工作——這種「先 kernel、後 Mesa」的排序，顯示開放原始碼圖形堆疊已被視為即將推出的架構的首要目標，而非滯後於專有版本或 Windows 版本的附帶考量。
「初步支援」實際上意味什麼
潛在用家應調整預期。初版 Mesa 代碼最好理解為腳手架：即 RADV 與 RadeonSI 認識 GFX13 存在所需的最基本辨識及驅動接駁。實質功能——令遊戲及 GPU 加速應用程式正確運作的部分——通常需要在後續多個月的工作中逐步到位。此類合併請求只是起跑槍，並非功能版本發布。
RADV 是 Linux 遊戲生態系統現今所倚賴的開放原始碼 Vulkan 驅動程式，而 RadeonSI 則是 AMD 歷史悠久的 OpenGL Gallium3D 驅動程式，兩者均涵蓋於這一輪啟用工作之內，因此兩套 userspace 堆疊由同一起點出發，而非一開始便各自分歧。
先後次序為何對發行版重要
對 Linux 發行版封裝者及早期採用者而言，時機才是關鍵。Kernel 支援先行落地、Mesa 數天後跟進，讓發行版獲得一個連貫的窗口，可在其發行周期的相近節點上組裝同時包含兩半支援的堆疊。當 kernel 與 userspace 支援相隔太久才到位，封裝者最終可能只出貨半套堆疊——例如 kernel 能辨識硬件、但已安裝的驅動程式尚無法驅動，反之亦然——而凍結死線更可能令這道鴻溝遺留整個發行周期。
正因有此提前量，一份公認仍處於早期階段的合併請求才具新聞價值：它確立了下游項目可據以規劃的模式，即使 RDNA5 硬件實際可用的版本預計仍需數月才會推出。
Phoronix 的報道並未涉及硬件供應情況，讀者亦不應單憑驅動開發節奏推斷發布窗口；開放原始碼驅動的前置時間通常遠長於零售上市時間，歷史上新一代 AMD GPU 的首日可用性，往往要待持續的發布後工作方能實現。
現實的時間表
對 Linux 上的 AMD GPU 用家而言，實質啟示是以良好流程為框架的耐心。上游信號令人鼓舞：AMD 正在公開環境中進行啟用工作，而且次序為下游項目所能消化。然而，從初期驅動腳手架到一個能穩定運行現今遊戲的驅動程式，其間距離仍以數個月的漸進 commits、bug 修復及性能調校來衡量。
值得留意的相關里程碑並非這次合併請求，而是其後數輪 Mesa 工作，填補 GFX13 骨架背後的功能——以及這些進展能否及早落地，讓主要發行版將其納入下一次凍結。
來源：Phoronix