XDC2026: Vulkan Gallium（代号 “Shiva”）技术报告

来源:XDC 2026《Is it time for Vulkan Gallium?》

演讲人:Faith Ekstrand(Collabora)

整理日期:2026-10-08

摘要

本报告基于 Faith Ekstrand 于 XDC 2026 的演讲，系统梳理 Mesa Vulkan 运行时当前面临的架构困境，并介绍其提出的解决方案------一个借鉴 OpenGL Gallium 思路、面向 Vulkan 的全新中间抽象层，代号 Shiva 。核心结论是:当前的 Vulkan 实现模型已难以为继，是时候引入 "Vulkan Gallium"。需特别说明，该项目目前尚无代码，所有设计与计划均为初步构想，可能随时变动。

1. 问题背景

1.1 根本问题

当前 Mesa Vulkan 运行时(runtime)的根本缺陷在于:

Vulkan 运行时嵌入在驱动内部，而非位于驱动之上。

这一架构导致职责边界模糊、代码交叉耦合严重。

1.2 入口点实现混乱

Vulkan 入口点(entrypoint)由多方共同实现，彼此交叉调用:

驱动(Drivers)
运行时(The runtime)
窗口系统集成(WSI)
驱动层(Driver layers)
vkFoo2() 包装器

且这些入口点常常以其他入口点的形式相互实现，形成复杂调用网。

1.3 继承模型泛滥

现有代码同时采用了所有继承模型，互相调用:

模型	示例
结构体继承	`nvk_foo` 以 `vk_foo` 开头
Vfunc 表	分发表、管线的 vfunc 表等
包含(Containment)	`vk_command_buffer` 内含 `vk_dynamic_graphics_state`

1.4 现状评估

这套机制远比预期运行得好，仅因为 Vulkan 在许多场景下是一个相当不错的抽象层级;
但它已经不再有效。Vulkan 在 2016 年易于实现，到 2026 年已充满向后兼容的历史包袱，且随着 Vulkan 持续演进只会更糟。

2. 案例研究

2.1 案例一:`VkFormatFeatureFlags2`

在 Vulkan 1.3 中引入;
提供了转换到 v1 的 helper:vk_format_features2_to_features();
驱动必须到处手动调用该 helper;
存在两套 DRM format modifier 属性结构体------因其为数组而无法扩展，驱动须手动处理两者;
几乎无改进空间------目前没有办法封装查询(wrap queries);
位(bits)即将耗尽，而 Khronos 已在讨论推出 v3。

2.2 案例二:Subpass merging(子通道合并)

表面简单:由启发式决定何时合并、取渲染目标并集、将输入附件读取替换为 framebuffer fetch、在子通道边界更新输入/输出附件位置;
实则必须把上述全部信息传递给编译器------现有一批获取 vk_render_pass 版本 pNext 结构的 helper，正变得越来越脆弱(janky);
渲染目标重排序不会重排混合(blend)状态 :VK_KHR_dynamic_rendering 允许改变附件位置，但仅更新"着色器→附件"的映射，混合仍按 VkRenderingInfo::pColorAttachments 顺序;
于是不得不增加更多动态状态:出现第二种可重排混合的附件重排方式，两者交互定义不清;
结论:亟需一种更好的状态拦截(state intercept)机制。

2.3 案例三:Vulkan meta

Vulkan meta 虽远不如 OpenGL meta 那样危险，但仍不理想;
状态保存/恢复(state save/restore)是逐驱动实现且极其脆弱。

3. 解决方案:Shiva 模型

3.1 借鉴 Gallium 模型

OpenGL 的 Gallium 架构层级:

复制代码

Mesa GL Classic → State Tracker → Gallium API → HW driver / aux·blit

Gallium 的优势:

完全位于驱动与 API 之间，驱动实现 Gallium API 而非 OpenGL;
更强的能力去"消化" GL 的历史怪癖;
为 meta 操作提供更优 API(u_blitter 以 gallium 实现 gallium，而非 GL-on-GL);
提供一个可按需变更的可变 API------Vulkan 与 OpenGL 是 ABI 稳定的，历史包袱永不消失。

3.2 Shiva 架构

对应的 Vulkan 版本架构:

复制代码

Vulkan runtime "classic" → Vulkan state tracker → Shiva API → HW driver / aux·blit

命名由来:Shiva 是《最终幻想》神话中的冰之女神，而 Vulcan 是火神，相映成趣。

3.3 设计原则(Why Shiva?)

停止直接实现 Vulkan------规避日益累积的兼容性包袱;
提供可修改、可扩展的 API------取代当前大量伪扩展(pseudo-extensions);伪扩展有时因 Zink 或 VKD3D 需要而被标准化，最终使 Vulkan 更复杂;
能够拦截所有状态------当前运行时约 90% 是可选的(含全部状态拦截)，现有的拦截方式脆弱;
能安全地自我调用------改善 meta 操作与状态保存/恢复;
为 Vulkan 量身设计------Shiva 不会是 Gallium 的复制粘贴;
对 Rust 与 C++ 驱动更安全。

4. Shiva API 设计

4.1 总体设计

位于 Vulkan state tracker 与 Shiva 驱动之间;
现代化、尽量无历史包袱(shader objects、dynamic rendering 等);
摒弃 pNext 链与 flags2:传给驱动的一切都是带默认值的扁平结构体;
明确规定对象生命周期与所有权;
力求 meta 操作友好。

4.2 Rust 后端支持

支持 Rust 后端是明确的设计目标:

API 自动绑定到 Rust:C 侧用 vfunc 表，Rust 侧用 trait;
遵循 Rust 的生命周期规则;
使用 Rust 的切片(slice)等概念------也可能提供给出 std::span 的 C++ 头文件;
引用计数类型采用 Rust 智能指针。

4.3 待决的开放问题

如何定义 Shiva API?(XML?JSON?C 头文件?Rust?)
如何表达可能超过 64 位的 flags?
是否为所有驱动暴露单一 Shiva 实例?
描述符(descriptors)应如何工作?
动态状态如何处理?是否以某种方式复制 Gallium 的 CSO?

5. 迁移与演进策略

"classic" Vulkan 运行时仍将保留;
Shiva 的 Vulkan state tracker 将作为一个 "classic" 驱动存在;
state tracker 调用 Shiva API，驱动则实现 Shiva API;
抽象层将按需迁入 Shiva:若 Shiva 是某能力的唯一使用者则并入;部分能力因 Shiva 能做得更好而值得重复实现。

6. 项目计划与时间线

以下均为初步估计(best guess)。

阶段	预计时间
Faith 个人开始动工	XDC 之后(约 2026 年 10 月底)
其他人加入	约 1 年后
初期原型平台	Nouveau(Rust 后端)+ Panfrost(C 后端)
对用户就绪	约 2 年后(仅 Nouveau，或含 Panfrost)
其他驱动迁移	缓慢推进

补充说明:

项目初期需要"编辑式"主导(editorial voice)，而非委员会设计(design-by-committee);整个 API 可能被多次重写;
Nouveau 与 Panfrost 是演讲人最熟悉的两款硬件;
需先在少数驱动上验证，再考虑大规模移植;
当年全员迁移到 Gallium 花了 10 年，预计 Shiva 迁移不会更快。

7. 结论

当前 Vulkan 的实现模型因运行时内嵌于驱动、入口点交叉耦合、历史包袱累积而难以持续。借鉴 Gallium 经验的 Shiva 中间抽象层，通过在驱动与 Vulkan API 之间引入一个可演进、可全状态拦截、meta 友好且对 Rust 友好的内部 API，有望从根本上改善可维护性。该项目刚刚起步，面临诸多未决设计问题，并需要数年乃至十年级别的长期迁移周期。

免责声明(演讲原文): 目前尚无代码，一切都可能随时变动，最终成果不保证与 XDC 幻灯片完全一致。

8. 开源地址

截至本报告整理日期(2026-10-08)，Shiva 尚无独立的公开代码仓库。根据演讲，Faith Ekstrand 计划在 XDC 之后(约 2026 年 10 月底)才开始动工，因此目前仍处于"只有幻灯片、没有代码"的阶段。

作为 Mesa 生态的一部分，Shiva 未来预计会托管在 Mesa 的上游仓库中。相关可关注的官方渠道如下:

Mesa 主仓库(未来可能的落地位置):https://gitlab.freedesktop.org/mesa/mesa
本次演讲页面(XDC 2026):https://indico.freedesktop.org/event/12/contributions/523/

注:上述 Mesa 仓库为 Shiva 预期的未来宿主，并非当前已存在的 Shiva 代码地址;请以后续 Mesa 官方合并请求(MR)与邮件列表公告为准。