mpv icon indicating copy to clipboard operation
mpv copied to clipboard

video/out/gpu/context: prefer vulkan over opengl when reasonable

Open Dudemanguy opened this issue 1 year ago • 5 comments

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.

Dudemanguy avatar Oct 15 '24 01:10 Dudemanguy

Isn't --vo=gpu --gpu-api=vulkan basically libplacebo? Won't https://github.com/mpv-player/mpv/issues/11499#issuecomment-2380263005 occur?

guidocella avatar Oct 15 '24 06:10 guidocella

Isn't --vo=gpu --gpu-api=vulkan basically libplacebo? Won't #11499 (comment) occur?

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.

llyyr avatar Oct 15 '24 06:10 llyyr

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.

Keep in mind that vo_gpu + vulkan is the worst combination of vo/API as far as power efficiency goes. I documented some here https://github.com/mpv-player/mpv/issues/9551#issuecomment-2346784006 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.

llyyr avatar Oct 15 '24 07:10 llyyr

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.

Dudemanguy avatar Oct 15 '24 13:10 Dudemanguy

Since there were no comments since last week, I will merge this later if there is no NACK.

kasper93 avatar Oct 23 '24 12:10 kasper93

Wouldn't this break vaapi on AMD? https://github.com/mpv-player/mpv/issues/9657 https://github.com/mpv-player/mpv/issues/11236 https://github.com/mpv-player/mpv/issues/14934

na-na-hi avatar Oct 23 '24 14:10 na-na-hi

That has always worked for me.

guidocella avatar Oct 23 '24 14:10 guidocella

It would break it on old crappy cards like mine that don't support modifiers and thus go to vaapi-copy, but I don't think that's a blocker.

Dudemanguy avatar Oct 23 '24 14:10 Dudemanguy