video/out/gpu/context: prefer vulkan over opengl when reasonable #15095
Conversation
For most actual desktop users, vulkan should be the a superior experience over opengl as this point and our autoprobe should pick that. For linux users, vulkan on wayland is rapidly seeing improvements and is far ahead of egl. There is no sign of that changing anytime soon and working fifo is on the horizon, so really wayland users should just all be using vulkan from now on. For x11, there is not a big difference between using egl vs vulkan as far as I know and both work well. macOS already prefers the vulkan backend over the libmpv one anyways, and finally windows still defaults to d3d11. Probably virtually no one uses opengl on windows, but vulkan is reasonably common among windows users and it doesn't make any sense to prefer opengl over it. The two outliers here are Android and VK_KHR_display. On Android, vulkan drivers are probably just a total disaster and let's not put ourselves in that mess if there's no reason to. For VK_KHR_display, it actually works fine except for one really big problem: VT switching doesn't work. If you try it, enjoy losing all input and being forced to do a hard reboot. It might be fixable if you use logind or something, but the method of using signals like the drm context does won't work because VK_KHR_display uses render nodes not primary nodes. Also, the opengl drm context could support hdr in theory (some attempts were made but none succesful) so it is probably "better". Maybe. Anyways, for these two platforms, we still prefer opengl.
|
Download the artifacts for this pull request: |
|
Isn't |
I haven't heard any of the issues be reproduced with vo_gpu, since the libplacebo issues appear to mostly be related to compute shaders and not the graphics API. |
Keep in mind that vo_gpu + vulkan is the worst combination of vo/API as far as power efficiency goes. I documented some here #9551 (comment) but basically for the same settings vo_gpu + vulkan may use up 30-40W more than vo_gpu + opengl or vo_gpu_next + vulkan might. |
|
That is fair and a point for vo_gpu_next, but luckily for us we don't really aim for the lowest possible power efficiency out of the box. You'd have to enable hwdec anyways, so possibly changing the default vo to vo_gpu_next or vo_dmabuf_wayland is fine. People probably do that today anyways. We keep getting hit by opengl bugs on nvidia like apparently #15099 and I'd rather people need to flip some settings to save power as opposed to OOM'ing out of the box. |
For most actual desktop users, vulkan should be the a superior experience over opengl as this point and our autoprobe should pick that. For linux users, vulkan on wayland is rapidly seeing improvements and is far ahead of egl. There is no sign of that changing anytime soon and working fifo is on the horizon, so really wayland users should just all be using vulkan from now on. For x11, there is not a big difference between using egl vs vulkan as far as I know and both work well. macOS already prefers the vulkan backend over the libmpv one anyways, and finally windows still defaults to d3d11. Probably virtually no one uses opengl on windows, but vulkan is reasonably common among windows users and it doesn't make any sense to prefer opengl over it.
The two outliers here are Android and VK_KHR_display. On Android, vulkan drivers are probably just a total disaster and let's not put ourselves in that mess if there's no reason to. For VK_KHR_display, it actually works fine except for one really big problem: VT switching doesn't work. If you try it, enjoy losing all input and being forced to do a hard reboot. It might be fixable if you use logind or something, but the method of using signals like the drm context does won't work because VK_KHR_display uses render nodes not primary nodes. Also, the opengl drm context could support hdr in theory (some attempts were made but none succesful) so it is probably "better". Maybe. Anyways, for these two platforms, we still prefer opengl.
Something similar was done in #13620. But I don't believe this needs to wait until a consensus is formed around preferring
vo_gpu_next.