绕开 WSI 的 Vulkan/Wayland：无 libwayland 的 GPU 渲染新路径

从软件渲染到 GPU：为什么绕开 WSI？

上一篇文章里，我把一个软件渲染的窗口放上了 Wayland 屏幕，全程没有碰 libwayland。我描述过 Wayland wire protocol 如何运作，也演示了怎么在没有 libwayland 的情况下自己序列化消息。那是个好的起点，但说实话，对性能有要求的程序来说，软件渲染顶多算个热身。这篇文章要解决的问题就是，能不能让 GPU 也走同样的路。来源：ptrtoliam

标准 Vulkan 应用要跟窗口系统打交道，得通过 WSI。WSI 是 Vulkan 里做窗口系统集成的层，负责把渲染结果跟具体平台连接起来，几乎所有教程都从它开始。但这篇文章的标题明晃晃写着 Using Vulkan on Wayland Without WSI，作者想绕开这个层。这种设计在别人看来有点反直觉，因为 Wayland 的 WSI 扩展明明提供了现成的集成路径。作者偏要自己搭一条，理由可能是想彻底摆脱对窗口系统特定扩展的依赖。来源：ptrtoliam

作者在目录里放了一节 Accepting libc... For Now，表示他目前接受 libc 依赖，但觉得以后可以去掉。这种暂时接受、留待改进的态度，跟整体方案一脉相承。软件渲染那一版已经证明了无 libwayland 可行，这版想再进一步，把 GPU 也拉进来，同时尽量少依赖系统库。来源：ptrtoliam

技术路线：无 WSI 的 Vulkan 呈现管线

上篇文章的流程有八步。连接 socket、绑定全局接口、创建 wl_surface 和 xdg_surface 等、commit、等 configure 事件、打开 shmfile 建 wl_shm_pool、从 pool 创建 wl_buffer、damage/attach/commit。这八步里，画面数据从 CPU 内存直接给合成器，wl_buffer 就是一块共享内存。新方案把渲染挪到 GPU，流程本身没少多少，但中间的数据路径换了，得重新想清楚每一步在做什么。来源：ptrtoliam

作者在 Vulkan 层面分配一个可导出的 VkImage，再通过 linux-dmabuf 协议把它变成 wl_buffer。图像格式要协调 DRM 格式和 Vulkan 格式，设备选择要枚举 GPU 并确认支持 dmabuf 导出。这里面每一步都有讲究，DRM 格式和 Vulkan 格式不是一一对应的，得找到两边都认的格式，否则图像根本导不出去。设备也要挑，不是每个 GPU 都支持 dmabuf 导出，有的驱动可能只对特定硬件开放这个功能。来源：ptrtoliam

呈现帧的时候，VkImage 先导出为 dmabuf，再包装成 wl_buffer，attach 到 wl_surface 上提交。还有个小插曲。在 GNOME 桌面上，需要额外创建 zxdg_toplevel_decoration_v1 接口，其他桌面不需要。这说明同一套代码在不同桌面环境下的行为并不完全一样，得留个心眼。来源：ptrtoliam

现状、潜在问题与交叉验证

原文目录里有两节，Potential Issues 和 What's Left。作者自己承认方案还没完全解决。这篇博客在 Hacker News 上拿了 1 分、0 条评论，跟它展现的技术深度不太匹配。这个主题可能确实小众，能理解作者为什么选择自己写博客而不是到处宣传。HN 的评分有时候跟内容质量没关系，尤其是这种偏底层的协议探索。来源：HN

和软件渲染相比，这条路径避免了 CPU 复制，但代价是依赖 Vulkan 和 DMA-BUF。软件渲染只需要把像素数据写进共享内存，合成器直接读走。这条新路径把渲染放到 GPU，数据导出需要经过 dmabuf，多了一层协议转换。对某些场景是优化，对另一些场景可能增加复杂度。来源：ptrtoliam

我不确定作者接下来会不会真的去掉 libc 依赖，也不确定 Potential Issues 里具体是什么问题。但有一点可以判断。在不依赖 libwayland 的前提下把 GPU 渲染接进 Wayland，这件事本身已经比软件渲染难一个量级，而作者确实把它走通了。至于这个方案能不能被更多人接受，要看它解决的是不是真需求。来源：ptrtoliam

原文：

Using Vulkan on Wayland Without WSI · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月30日