Plan to deprecate vo=gpu

[Obegg]

I've seen it time and time again, the topic of deprecation of vo=gpu in favor of vo=gpu-next,
but every time the topic comes up, I have hard time to figure out what the next step should be,
and as far as I can see it doesn't seem to have a plan (to-do list) in order to achieve it, which is what I'm suggesting here.

Create a plan to deprecate vo=gpu in favor of vo=gpu-next.
This plan could have many forms, the first form could be in a open and pinned issue where there will be a checklist like this:

• Do X
• Do Y
• Do Z

The other form could be to create a project.

[Dudemanguy]

@haasn can correct if I'm wrong somewhere, but I believe the rough plan is essentially release a new version of libplacebo -> hard require libplacebo in mpv -> update mpv's code to the new APIs -> release a new stable version of mpv -> switch the default probe order to prefer gpu-next -> eventually remove vo_gpu sometime in the future

[haasn]

@haasn can correct if I'm wrong somewhere, but I believe the rough plan is essentially release a new version of libplacebo -> hard require libplacebo in mpv -> update mpv's code to the new APIs -> release a new stable version of mpv -> switch the default probe order to prefer gpu-next -> eventually remove vo_gpu sometime in the future

This

[Obegg]

@haasn can correct if I'm wrong somewhere, but I believe the rough plan is essentially release a new version of libplacebo -> hard require libplacebo in mpv -> update mpv's code to the new APIs -> release a new stable version of mpv -> switch the default probe order to prefer gpu-next -> eventually remove vo_gpu sometime in the future

It really does sounds like a rough plan, I was expecting/suggesting something more in-depth.
By my understanding there's also one important thing that needs to be added in vo=gpu-next and that thing is libmpv, which if by "update mpv's code to the new APIs" you meant this, then I'm sorry for not understanding.
I understand that there are some changes that have to come before other changes.
While as a user there are some things I can understand, there are some that I don't, and I was suggesting it more for the developers to keep track of what needs to be done and in what order in to deprecate vo=gpu the most efficient way, to avoid mistakes or waste time, if you think there's no need for in-depth checklist for this then feel free to close this issue,

[Dudemanguy]

Strictly speaking, there's no problem with libmpv and gpu-next. I use it all the time actually. The problem is with the render API (a subset of libmpv). To make matters worse, macos actually uses the render API in core mpv code. If you want my honest opinion, macos should just be shoved onto moltenvk and then the render API/vo_libmpv should be deprecated and removed. I'm aware this will break some libmpv clients out there but I don't care. I considered writing pl backend for it at one point and concluded that the whole thing is just bad.

[haasn]

I am planning to write a native metal backend for libplacebo

[m154k1]

If you want my honest opinion, macos should just be shoved onto moltenvk and then the render API/vo_libmpv should be deprecated and removed.

Can we just merge this mac_vulkan branch? It might not be finished from the code perspective but it's already better than the current backend.
I use it daily for months without any issues. MoltenVK even got VK_KHR_synchronization2 recently (KhronosGroup/MoltenVK#2021).

If someone wants to test it I've rebased these changes as a patch here:
https://github.com/m154k1/mpv-build-macOS/blob/master/patches/mpv/0001-vo-gpu-next-macosvk.patch

Check mpv-build-macOS for the complete build guide.

[Dudemanguy]

The branch needs some minor cleanups (e.g. all the waf stuff obviously needs to go). But if you polish up the commits a bit and say that it works for you, I will be quite happy to merge. Regardless of libplacebo having a metal backend or not, I see no reason why we can't have both.

[m154k1]

@Dudemanguy ok, let's try with #12493

[mlindner]

As a simple user of mpv, getting completely rid of libmpv would be a godsend. It's the biggest pain point on MacOS. I've disliked it ever since mpv forced users on to it and got rid of the old macos native video output that worked so much smoother. libmpv is slow and clunky. Metal, Vulkan or whatever, just something other than libmpv. Maybe the deprecation of OpenGL will finally force it to go away.

As a side note, whatever the future of macos display should allow something similar to games that have "fullscreen window" options as opposed to the standard MacOS fullscreen. This might allow bypassing of the annoying fullscreen animation.

[low-batt]

The IINA project is dependent upon libmpv as well as vo=gpu. Mentioning removing them is making me nervous.

I am excited to hear there is a plan to write a native metal backend for libplacebo.

With respects to macOS and the animated visual transition effects when going in and out of full screen mode, see: Stop or reduce onscreen motion on Mac

With the macOS Reduce motion setting enabled the animations are still present, but are reduced. If the IINA setting Use legacy full screen is enabled along with Reduce motion then IINA will enter and leave full screen mode immediately without any animation whatsoever.

To do this IINA does not use the AppKit toggleFullScreen method and instead uses its own custom full screen mode implementation. This is permitted by Apple, however AppKit defects added in Big Sur require workarounds.

[Dudemanguy]

I am currently working on a render API replacement that would allow you to use any vo and would allow for embedding the window on any platform. No promises though, I haven't even reached proof of concept yet (but in my head it should work anyway).

[Dudemanguy]

I am currently working on a render API replacement that would allow you to use any vo and would allow for embedding the window on any platform.

Well nevermind that. It seems wayland doesn't even allow you to create a subsurface when using the surface from mpv and the gui application's surface which makes the whole idea effectively useless. I guess there's still no solution.

[kasper93]

The remaining issues/task are tracked by this milestone. No need for discussion issues. Please create specific issue that should be worked one.