-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x11: always prefer EGL over GLX (may break vdpau) #5298
Conversation
|
I'm the one who prefers VDPAU for whatever reason (namely, because CUVID/NVDEC seems somehow broken with h264)... Anyway, it would be good to keep a way to set VDPAU+GLX explicitly. |
|
Edit: The logs reveal: Seems like it isn't finding any of the valid vsync control extensions, so it's falling back to the default/system-wide settings. (vsync disabled) |
|
Seems like the relevant function call would be Fuck knows what versions of EGL have it / what extensions are required, the documentation doesn't say |
|
Works perfectly fine for me. Seems like you have vsync disabled in the nvidia control panel or so. The official default for EGL swap interval is 1 AFAIK, so mpv doesn't try to set it (or even hook it up in any way). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to be getting rid of the weird x11_probe context. For those skeptical, note that this doesn't remove vdpau+glx interop. It just doesn't probe for it automatically. While it's not nice to have to manually specify --gpu-context=x11 for vdpau interop on old nvidia, it's not nice either to have to specify --gpu-context=egl on new AMD. The choice is therefore between a dying API and one that is now used by two out of three graphics vendors on Linux and allows us to handle hwdec interop with no quality reduction.
DOCS/interface-changes.rst
Outdated
| @@ -22,6 +22,8 @@ Interface changes | |||
| --- mpv 0.29.0 --- | |||
| - drop deprecated --videotoolbox-format, --ff-aid, --ff-vid, --ff-sid, | |||
| --ad-spdif-dtshd, --softvol options | |||
| - always prefer EGL over GLX, which helps with AMD/vaapi, but will break | |||
| vdpau - use --gpu-context=x11 to be able to use vdpau | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should add that --vo=vdpau and --hwdec=vdpau-copy are unaffected
|
For those who want to try, #5300 makes EGL backends respect the swapinterval setting. |
VDPAU is pretty much on its way out. It's inadequate for new video formats such as HEVC, and has been neglected by nvidia (unfixed bugs like broken rendering even of 8 bit HEVC). VDPAU also doesn't work on EGL, but fortunately nvdec does. On the other hand, AMD has support for both vdpau and vaapi. AMD+Vaapi with libva 2 and some extensions that were added after the 2.0 release (probably still git-only) supports full EGL interop, making vdpau unnecessary. The problem is that we strictly prefer GLX if the vdpau GL extension is present. This means on AMD we will always GLX over EGL, this preferring vdpau over vaapi. This makes the hardware decoding situation worse for AMD. Decide that it's time to drop the GLX probing, and always use EGL.
|
@kevmitch added. |
|
Just realized about git master dependencies. Maybe we should hold off merging this until the relevant code is in libva and mesa releases, otherwise the number of people this hurts will likely be more than it helps. |
|
Also, can anyone confirm that Mesa/AMD does not have an extension or anything that makes vdpau interop usable with EGL? (Because that would solve the issue.) |
|
Does this patch mean that I who have a NVIDIA card will not get vdpau by default? |
|
It doesn't touch vo_vdpau at all. It doesn't matter much with vo_gpu (with OpenGL backends) either, because we already prefer nvdec by default. Vdpau is in disrepair and doesn't support important aspects of newer codecs. The presentation API doesn't seem to be overlay useful either. There's a vdpauglx backend for vo_gpu, which makes primitive use of the vdpau presentation API, and it appears to report less ideal timings than just native GLX/EGL. |
|
The vdpau presentation API includes scheduling several frames to display at specific vsyncs and a way to follow up after when it was displayed. Missing in va API and opengl. vulkan have a swapchain but there you cannot schedule several frames in advance at specific vsyncs. I hope this will be standardised some day. |
|
Was the VAAPI GLX interop really that useless? Who knows when Radeon EGL will really work with upstream when mesa-git and libva-git still need to be patched even today? |
For me |
|
vaapi-copy is currently the only way to use vaapi with Radeon & mpv, and only vaapi can decode HEVC 10 bit in hardware. |
|
The old GLX interop was crap and broke with anything that didn't use the old colorspaces, and it also broke some of the fancier GL renderer features. The EGL interop (or an equivalent alternative) is the only way forward. So bug those Mesa people, if they haven't merged it yet. |
|
vdpau can work with egl. Let vdpau render video to a x11 pixmap using the presentation queue created from |
|
Yeah, but that's a bad hack and probably not even faster than using vdpau-copy. |
It's the best we can do. In my tests it's faster than copy. BTW, why do you think it's a hack? interoping with pixmaps is standard, see http://www.nvidia.com/content/GTC-2010/pdfs/2016_GTC2010.pdf |
|
vaapi x11egl will work also on AMD with Mesa 18.1. Edit: It got backported into Mesa 18.0.1 |
|
Since Mesa 18.0.1 and FFmpeg 4.0 have been released for some time now, imho this can be merged without regrets before mpv 0.29.0. |
|
Fully agree with aufkrawall. We now have the problem that users would get hardware decoding out of the box on AMD (well, not completely, they still need to set hwdec), but loading VAAPI fails because GLX is picked and the user has to be instructed to manually set --gpu-context=x11egl |
|
You may want to check this change on hybrid nvidia hardware, at least here it makes the use of hwdec=vdpau or --hwdec=vdpau not possible. |
|
Did vdpau ever work on hybrid nvidia systems? I don't see how this change could affect specifically hybrid systems. It does affect vdpau as a whole, but that's a deliberate change due to the following: a) vdpau is dead (no 10bit video, no VP9 decoding, no Wayland support, 8bit HEVC is buggy on nvidia) |
|
Well of course vdpau hwdec works on nvidia hybrid hardware. |
|
To the extent that anyone wants to actually tackle this problem, we could just dig a little deeper to distinguish the nvidia and amd cases so that the glx preference doesn't apply on amd. Of course, I'm personally happy with switching the default because I don't care about vdpau anymore. |
|
Yes, if would be good if correct choice could be done for both nvidia and amd. I only use nvidia and would prefer it to work like today. Nvidia have since this request was added, fixed fixed several of the problems with vdpau. |
|
But it still doesn't support VP9 and HEVC 10 bit, right? So it's rather dead, despite of any bug fixes. |
+1 |
|
Today again someone's "problem" with getting hardware decode to work was solved by specifying gpu-context=x11egl. This PR really should get merged. Or, to not screw up Nvidia users, I propose the following: Rather than looking for the vdpau_interop extension and choosing GLX vs EGL based on that, check the GL vendor string - if it's "NVIDIA Corporation" use GLX, otherwise use EGL. That would provide out-of-the-box functionality for both AMD/VAAPI and Nvidia/VDPAU. |
|
Merged as 0abe34e . |
VDPAU is pretty much on its way out. It's inadequate for new video
formats such as HEVC, and has been neglected by nvidia (unfixed bugs
like broken rendering even of 8 bit HEVC). VDPAU also doesn't work on
EGL, but fortunately nvdec does.
On the other hand, AMD has support for both vdpau and vaapi. AMD+Vaapi
with libva 2 and some extensions that were added after the 2.0 release
(probably still git-only) supports full EGL interop, making vdpau
unnecessary.
The problem is that we strictly prefer GLX if the vdpau GL extension is
present. This means on AMD we will always GLX over EGL, this preferring
vdpau over vaapi. This makes the hardware decoding situation worse for
AMD.
Decide that it's time to drop the GLX probing, and always use EGL.
I don't know if everyone would agree to this. Those who prefer vdpau for whatever reasons probably won't.
This does of course not affect vo=vdpau.