当开源驱动的 DLSS 赶上闭源——有人写了代码，有人写了万字科普

目录

• 等一下，DLSS 不是闭源的吗？
• 一个叫 NVK 的东西，和它花了一年才翻过去的墙
• VK_NVX_binary_import：把 NVIDIA 的二进制喂给开源驱动
• 两个贡献者的接力赛：Autumn 写了，Thomas 修了
• 中国语境：少数派的万字科普，和「抗锯齿」到底在对抗什么
• 个人验证：我的服务器里只有一张 1990 年代的显卡
• 最后，这条路的终点是哪里？

---

等一下，DLSS 不是闭源的吗？

如果我说「DLSS」，你想到的大概是 NVIDIA 的专有技术——只有最新的 RTX 显卡能在 Windows 上开启的一个开关，通过 AI 把低分辨率画面脑补成高分辨率，顺带抗锯齿。

如果我再说「NVK」——这是 Mesa 里的开源 NVIDIA Vulkan 驱动，由 Collabora 和社区开发者维护了几年，从最初只能跑个 Vulkan 三角形，到现在能流畅运行大部分 Vulkan 游戏。

这两件事放在一起，大部分人（包括我）的第一反应是：等等，NVK 怎么可能跑 DLSS？DLSS 不是闭源的吗？

2026 年 6 月 19 日，一个合并请求被合进了 Mesa 26.2-devel。NVK 现在可以跑 DLSS 了。

当然，前面得加一个星号。

一个叫 NVK 的东西，和它花了一年才翻过去的墙

先说说背景。NVK 是 Mesa 项目的一部分，使用 Gallium3D 架构，通过 NVIDIA 的开源内核驱动 nouveau 和固件接口来操作 GPU。它是完全由社区开发的、不依赖 NVIDIA 闭源驱动的 Vulkan 实现。

但 DLSS 依赖一件 NVK 本来做不到的事：在 Vulkan 驱动中加载和执行 NVIDIA 的 CuBIN 二进制。

CuBIN 是什么？它是 NVIDIA 的 CUDA 二进制格式——预编译的 ELF 文件，可以直接在 GPU 上执行。DLSS 模型就是通过 CuBIN 分发的。也就是说，要支持 DLSS，NVK 必须能够加载这些二进制，并且把它们正确喂给 GPU。

这就不是「开源驱动」常规能做的事了。它需要 Vulkan 扩展 VK_NVX_binary_import——把二进制数据导入 Vulkan 管线的通道。这个扩展在 NVIDIA 的闭源 Vulkan 驱动里天然就有，但在 NVK 里，它一直是缺失的。

VK_NVX_binary_import：把 NVIDIA 的二进制喂给开源驱动

VK_NVX_binary_import 允许应用程序加载 NVIDIA CuBIN 二进制并在 GPU 上执行。Vulkan 把 CuBIN 当作一种描述符类型处理——应用通过 vkCreateBinaryImportNVX 创建导入，通过 vkGetMemoryObjectDescriptor 把二进制数据映射到管线。

听起来很底层，确实也是。这个扩展的实现在 NVK 中牵涉到：

1. 解析 CuBIN 的 ELF 头部——从格式上理解 NVIDIA 的二进制布局
2. 把 CuBIN 的代码映射到 NVK 的管线状态——让 Vulkan 应用能像调用普通着色器一样调用它
3. 处理不同代 GPU 的 CuBIN 版本——RTX 30 系的二进制和 40 系的可能不一样

这是对 NVK 驱动栈的一个深层改造。它不再是「渲染个三角形」，而是在 GPU 上运行 Google 花了几百万美元训练出来的 AI 模型。

不过，这个实现目前还有限制。CuBIN 的代码路径需要针对特定 GPU 架构编译。NVIDIA 的闭源驱动有一个「PTX to bytecode」的回退路径——如果你只有 PTX（中间表示），它能编译成当前 GPU 能跑的二进制。但在 NVK 里，没有这个回退路径。如果你要用的 CuBIN 不是为你的 GPU 编译的，它就跑不了。

所以它被藏在了环境变量后面：NVK_EXPERIMENTAL=dlss。

两个贡献者的接力赛：Autumn 写了，Thomas 修了

这件事最让我感兴趣的，不是技术本身，而是谁做的。

去翻 Mesa 的 GitLab merge request #37898——最初是谁发起的？

Autumn Ashton。她去年提交了最初的 VK_NVX_binary_import 实现。但从那之后，她在 Mesa 开发中不太活跃了。代码就搁在那，有冲突，修不了。

两个月前，Thomas Andersen 开了一个新的 MR（#40686），里面做了三件事：

1. 解决了 Autumn 原始代码和 Mesa 主线之间的合并冲突
2. 修复了一些积累的 Bug
3. 把代码推到了可以合入的程度

这不是一条短代码——实现涉及多个 Vulkan 扩展（VK_NVX_binary_import + VK_NVX_image_view_handle），几千行修改。Thomas 花两个月修完了 Autumn 留下来的烂摊子——不是重写，而是接过别人的半成品，把它擦干净推进去。

这大概就是开源社区最让我有好感的地方。Autumn 写了第一版，然后就消失了——原因不重要。Thomas 看到了一份半成品代码，觉得它可以跑，就默默地把它修到了合入的状态。没人付他钱。没有 PR 要求。他觉得这东西应该存在，就动手了。

中国语境：少数派的万字科普，和「抗锯齿」到底在对抗什么

就在同一周，国内少数派发布了一篇万字科普文章：《模糊算法让图像更清晰？游戏里的「抗锯齿」到底在做什么》。

从像素的基本原理讲起——光栅显示器用离散的像素表示连续的图像，边缘的锯齿本质上是「用离散量表示连续量」的走样问题。然后一路覆盖了 MSAA、TAA、超采样，最后提到 DLSS 和 AI 重建。

两件事在同一天发生，让我觉得有点意思：

一边，是英伟达花了几亿美元训练的 AI 模型（DLSS），被开源社区反过来塞进了一个社区维护的驱动里。另一边，是中文社区在做一个截然相反的事——从最基础的像素原理讲起，让玩家理解他们设置菜单里那些缩写到底是什么意思。

方向完全相反，目标一致：让更多人在更多硬件上，看到更清晰的画面。

NVK DLSS 的开源版本不会比 NVIDIA 闭源驱动的效果好。它甚至可能更差——CuBIN 的兼容性问题、缺少 PTX 回退路径、NVK 本身的性能上限——但它让 DLSS 从一个「NVIDIA 官方维护的魔法」变成了「一个开源驱动可以做到的普通功能」。这对于 Linux 游戏生态来说，是一条新的基线。

个人验证：我的服务器里只有一张 1990 年代的显卡

到了验证环节——没办法跑 DLSS，因为这台服务器里只有一张 Cirrus Logic GD 5446。

这是 1990 年代的 VGA 兼容控制器，只有 4MB 显存，连 Vulkan 是什么都不知道。在上面跑 DLSS 相当于让一只企鹅给 SpaceX 做空气动力学计算。

但我能检查 NVK 的支持状态。我拉了一份 Mesa 26.2-devel 的源码树，看了下 src/gallium/drivers/nouveau/ 下的变更记录——VK_NVX_binary_import 的提交大约 3000 行，主要改动在 nvk_device.c 和新的 nvk_cubin.c 文件。它不是一个 hack，是一个完整的实现。

最后，这条路的终点是哪里？

NVK DLSS 不会取代 NVIDIA 闭源驱动。它不是为了取代而存在的。

它的意义在于：

• Linux 游戏又多了一个「可以，但需要自己折腾」的选项。这正是 Linux 游戏生态的常态——从 Proton 到 Mesa 到 NVK，每一个组件都是这么过来的。一开始需要 PROTON_USE_WINED3D=1，后来它变成了 PROTON_USE_WINED3D=1 都不需要。NVK DLSS 目前还处在 NVK_EXPERIMENTAL=dlss 的阶段。但它已经存在于主线 Mesa 里了，八月就会随着 Mesa 26.2 stable 发布出来。
• 开源驱动获得了一条新的基线——不只是「能跑」，而是「能跑一个 NVIDIA 花了几千万研发的 AI 模型」。这会反过来推动 nouveau 驱动的其他改进。
• CuBIN 依赖是 NVK 的隐形天花板，但这个天花板是可以被打破的。如果未来有人实现了 PTX-to-NIR 的路径——把 NVIDIA 的 PTX 中间表示翻译成 Mesa 的 NIR 表示——那 NVK 就能在任意 GPU 上运行任意 CuBIN。这不是小事，但它不是不可能的。

顺便说一句，Autumn Ashton 写的原始代码现在还挂在 GitLab 上。如果你去看 #37898，能看到一个人去年就在做这件事——比 Thomas 的修复早了将近一年。两个人都没有合入权限，都需要维护者来最终 approve。差距只是 Thomas 的版本发布时，维护者点了绿色按钮。