mac: add macosvk gpu context #12493
mac: add macosvk gpu context #12493
Conversation
|
Sorry to make your rebase more painful but could you keep the separate commits of the original branch? Makes it easier to read and also keeps the credit of who wrote what clearer. |
|
#7857 is something different and is not related to this tbh. like i said before, the TODOs on my original PR should still be done. the hwdec changes should be completely separate. |
Oh, I don't think I can do it again, sorry. I remember I had to do rebase multiple times due to build system and hwdec changes. I might break something if I'll do it again. I can change commit message or author for credits.
Yeah, but even with broken precise timer it still plays media without issues on an ARM mac :) Feel free to edit this PR / commits or tell me how should I change it. |
|
If this is an improvement over the status quo (which it sounds like it is), then I'm all for it even if it is incomplete simply because it finally gives us a path forward to stop using the vo_libmpv hack.
I'll do the rebase for you. Give me a second. |
add an animation lock to the window to prevent the window from closing while animating. if this is done while the fs animation is running the dock will stay hidden. this is not used yet, because it's unnecessary for cocoa-cb but will be for new vo backends.
use VK_PRESENT_MODE_FIFO_KHR for video-sync some more changes icc, size backport some fixes debugging shit fix 100% cpu usage, and some wrong frame sizes generalise moltenvk backend log cleanup generalisations add icc profile (incomplete) only clear when newly initialised mac override mac some cleanups mac vulkan use layer struct mac cleanup mac mac cleanup mac: update icc profile on swap
mac remove debug print, manually sync to vsync
|
Okay rebased now and hopefully I didn't break something. I took the liberty to slightly reword a couple of commit messages as well. I included the hwdec and embedding support commits for now, but I'm thinking we should probably just drop them? The hwdec has nothing to do with this PR and I presume the embedding one doesn't actually work given it has a WIP. Edit: woops messed up the hwdec rebase. I'll just drop those two commits for now. |
|
Download the artifacts for this pull request: |
|
Tested, looks good. Now hwdec isn't working with --vo=gpu-next but it's still working with old backend. I guess hwdec commits can be pushed in the next PR. |
|
I accidentally nuked your docs commit btw if you don't mind doing that again. |
|
Done. |
but it isn't without issues, i can vouch for several. the past 2 years none even tried to attempt to finish those todos. there is like near 0% chance anyone will finish it. the point should not just be to merge something 'working'. it should adhere to a minimum standard of code quality. which it doesn't, at least the comments within the code should be handled or removed. if something isn't working currently, it should be removed to keep the code base clean and tidy. if i felt like it was good enough, i could have merged it +2 years ago.
it's not incomplete per se, it's broken in parts. tbh, i wouldn't call it a clear improvement. it works better in some way and worse in others. i wouldn't even call it on par with the current status quo, but rather experimental. that's how it should be marked for now imo. cocoa-cb isn't really a hack. it's a first party libmpv user. i would like to veto on merging this for now. it might sound like an empty promise, though i recently got a mac again after mine broke some time ago. i am planning to clean up the mess i created with my absence the past 2 years. currently i am in the process of creating a todo list for all the needed, broken and new things. the first task will be cleaning up the missing things on the moltenvk backend PR. it would be nice if you could give me some (more) time to cleanup my own mess. |
|
To be clear, it's
Sure that sounds good. I was just wanting a viable way to get macos onto gpu-next so that way we can push forward with it. The two options would basically be either have a libplacebo backend for the render API or have a moltenvk and/or metal context. I'm of the opinion that the render API is not worth supporting. It's basically rotting code anyways, so something like this is the ultimately the right way to go. |
That's good :) Let's close this PR then. |
This adds support for long awaited vo gpu-next on macOS via Vulkan/MoltenVK.
This is a rebased version of https://github.com/rcombs/mpv/tree/mac_vulkan.
Might improve performance and battery life.
Tested on MacBook Air M2.
closes: #7482
closes: #7857