嗯 如题
一个是 Vulkan
一个是 OpenGL
你这是从哪里臆想出来的？
1 Like
那是窗口管理的事没做好，不能说本身是图形api的问题。niri本身还是opengl后端呢。这俩API都对wayland display handle有足够的支持扩展。像glfw这些都早已支持wayland，还有包括Alacritty，Quickshell（除非使用QSG_RHI_BACKEND），它们都是opengl后端，显然能完美在wayland下运行。
简单说就是vulkan使用的对象模型而opengl说白了就是个全局状态机。现代图形API都趋向于使用对象模型，控制更加精细，可以做到更底层。事实上Vulkan也确实非常底层，基本以我理解，就是靠着一万个扩展对硬件做了抽象。理论上当然是能比OpenGL获得更高的性能的。但事实并不一定是如此。Vulkan的渲染管线当然更复杂，写得不好了是完全有可能性能比不上同样的OpenGL程序的。
顺便说下，甚至，我在wgpu上还遇到过这两个情况：第一个，是一个图形程序，设置为DX12后端在Linux上使用VKD3D运行，会比直接原生Vulkan后端运行还要快个几帧。最终我只能归咎于是wgpu的Vulkan实现不优。第二个是一个计算程序，在Linux上使用Vulkan后端运行的效率会是Windows上以DX12后端运行的足足1/6。所以我就不很喜欢所谓“神话Vulkan”的。不过也有相反的，比如“宇宙沙盘”这款游戏在Linux上使用Vulkan后端运行，会比dx11->dxvk->vulkan以及dx12->vkd3d->vulkan路径要高个数帧至十几帧，亲测。当然这也是“它本该的”。
之前MC换图形API那事也是，一堆就说，啊仿佛“一换”Vulkan了能什么几倍性能提升。我就在那提醒，说Vulkan更底层更复杂，实现得不好是有可能还不如OpenGL实现的，别期待落空（事实说明真的是这样，第一个快照性能有下降）。毕竟OpenGL管线也是麻将打磨了那么久的。有时候做一样事情OpenGL直接做效率反而会比Vulkan要来得高（因为opengl更“上层”，它自己里面会帮你做一些事情有时可以有优化效果），Vulkan很多东西需要自己来弄。
当然从应用来说总的来说Vulkan绝对是更现代的，体验更好。OpenGL也是要慢慢淘汰了，很多东西都设计得很远古很麻烦，就比如现在在Linux上我用Vulkan想切换显卡设备，一个VK_ICD_FILENAMES就行了，而OpenGL我得加好几个带双下划线的EGL跟GLX环境变量，加载器路径绕啊绕反正我是没太弄明白过。MangoHud与lsfg-vk（正如其vk名）也是对Vulkan支持会更加好。
可实现低延迟、无撕裂
相反，有时就是需要靠高刷和允许tearing来实现低延迟的，一般认为当开启了vsync时（通过fifo），延迟会增高，因为渲染管线里要看显示器的脸色去present，对有些游戏来说input事件处理就会被这里拖住。正因为这样，Wayland协议反而要有tearing-flip支持，实现了这个的合成器才能允许应用使用immediate模式（比如，wgpu API, Vulkan API）来刷屏，以实现超出屏幕刷新率的更新来实现更低延迟。现在niri合成器就没有实现这个协议，所以当应用全屏时，就会被自动降低为fifo模式（也就是vsync）。
还有就是使用不使用xwayland，跟原生vulkan运行，其实这俩性能倒真不会有明显差别。
1 Like
正式版本Vulkan的性能确实要好了不少——不过我更在意的是硬件光追啊。