summaryrefslogtreecommitdiffstats
path: root/video/out/opengl
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: opengl: add hack for ancient Mesa/GLXwm42019-11-301-23/+47
| | | | | | | | | | | | | | | | glx.h recursively includes gl.h, and there is no way to prevent this. Old Mesa defines some GL symbols, but not all which mpv needs. In particular, one user who was too lazy to update his ancient Ubuntu and preferred to bother us with obscure bug reports, had Mesa headers which did not define GL 3.2, so GLsync was not defined. All in all I still think the idea of providing the GL API definitions ourselves was a good idea; just GLX should have been isolated better. But isolating GLX now is too much effort. Not sure why I'm bothering with this at all. Fixes: #7201 (unconfirmed)
* vo_gpu: opengl: do not free "GL" sub-allocationswm42019-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | This function always expects the GL struct pointer to be a talloc allocation. So far so bad. But the terrible thing is that _lots_ of code in mpv didn't quite get this (including the code which introduced the way it is used this way). For example, in context_glx.c you see this: struct priv { GL gl; ... GL is not a talloc allocation, but since it's at the start of a talloc allocation, it works anyway. So far so bad. But the really terrible thing is that mpgl_load_functions2() calls talloc_free_children() on the GL pointer, which means that all of priv's. This would be unintentional and could create dangling pointers. And this happens at the about 1 dozen of callers. I'm amazed it didn't broke yet anywhere. Removing this anti-pattern with making GL "implicitly" a talloc allocation would be too much effort at this point. So just manually free the only allocation that the function attached to GL.
* vo_gpu: context_glx: Add X11 native resourcePhilip Langdale2019-11-161-0/+2
| | | | | | | Surprisingly, we've managed to get this far without context_glx ever adding the X11 display as a native resource. But with the recent change to attempt to enable vdpau when using EGL, the hwdec now requires the display to be added. So let's add it.
* wayland: use eglGetPlatformDisplay()Dudemanguy2019-11-161-1/+2
| | | | | See aacc194. The same logic all applies to Wayland. In fact, we already require EGL 1.5 for wayland anyway, so it's better to do it right.
* x11: require EGL 1.5 and use eglGetPlatformDisplay()wm42019-11-161-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | eglGetPlatform() is a broken API, since it takes a windowing specific argument, yet is supposed to work for multiple APIs at the same time. On Linux, it can take both a X11 "Display" and a "wl_display". Obviously there is no way to specify what kind of display the argument is (it's just a void*). Mesa has _eglNativePlatformDetectNativeDisplay, which does funny stuff to try to guess the display type, including trying to call mincore() to determine whether the pointer can be accessed at all. I guess this recently accidentally broke (as a bug), but on the other hand, maybe it's time to do this properly. The fix is using eglGetPlaformDisplay(). This requires EGL 1.5, plus Mesa needs to support the associated platform extension (EGL_KHR_platform_x11). Since I see no reasonable way to do this in a compatible way, just require that EGL 1.5 is available. The problem is that EGL 1.4 seems to require you to create a display to query EGL version and extension, and you have a chicken-and-egg problem. It's very stupid. Maybe you could jump through some more hoops to get something compatible, but fuck that. Users on "too old" Mesa will fall back to GLX (which we keep around for a regrettable company known by the name of Nvidia). I think Wayland and GBM should do the same. They're sufficiently bleeding-edge that you can expect them to have EGL 1.5. On the other hand, the cursed RPI code will have to stay with a eglGetDisplay(). Speculative fix for #7154. (Rant about EGL follows. Actually I deleted it.)
* vo_gpu: context_x11egl: check eglGetConfigAttrib() for errorswm42019-11-081-1/+4
| | | | | Not sure why it assumes that it always succeeds (although generally it won't fail).
* vo_gpu: vdpau actually works under EGLwm42019-11-071-4/+2
| | | | | | | | | | | | | | | | | | The use of glXGetCurrentDisplay() restricted this to the GLX backend. But actually it works under EGL as well. Removing the GLX-specific call and using the general mpv-internal method to get the X "Display" makes it work in mpv. I didn't know this. Nvidia didn't list this as extension in the EGL context when I still used their GPUs. Note that this might in theory break use of vdpau in some libmpv clients using the render API. But only if MPV_RENDER_PARAM_X11_DISPLAY is not used, and they relied on mpv using glXGetCurrentDisplay(). EGL does not provide such an API, and hwdec_vaapi.c also uses what hwdec_vdpau.c uses now. Considering that vaapi is preferable these days, it's not bad at all if these clients get "broken". They can be easily fixed by passing the display to mpv correctly.
* vo_gpu: opengl: add support for IMGFMT_RGB30wm42019-11-021-0/+11
| | | | | | | | This integrates it as "special" format, with no alpha component, as the equivalent IMGFMT_RGB30 isn't meant to contain any. Nothing can produce this format in the video chain yet, so the next commits are needed to make this actually work.
* vo_gpu/opengl: fully initialize FBO when passing it to renderingJan Ekström2019-10-301-2/+4
| | | | | | | Until now, we only properly initialized two values, leaving the rest be garbage. Fixes #7104
* wayland: fix presentation timeDudemanguy9112019-10-201-1/+1
| | | | | | | | | | There's 2 stupid things here that need to be fixed. First of all, vulkan wasn't actually using presentation time because somehow the get_vsync function in context.c disappeared. Secondly, if the mpv window was hidden it was updating the ust time based on the refresh_usec but really it should simply just not feed any information to the vsync info structure. So this adds some logic to assume whether or not a window is hidden.
* wayland: add various render-related optionsdudemanguy2019-10-201-1/+2
| | | | | The newest wayland changes have some new logic that make sense to expose to users as configurable options.
* wayland: add presentation timedudemanguy2019-10-201-2/+78
| | | | | Use ust/msc/refresh values from wayland's presentation time in mpv's ra_swapchain_fns.get_vsync for the wayland contexts.
* vo_gpu: hwdec_d3d11egl: add missing P010 format to supported listwm42019-10-171-1/+1
| | | | | | | | This was obviously missing from the recent commit, which probably broke 10 bit decoding. The original commit didn't test this for lack of working hardware; this commit isn't tested either. Fixes: a1c7d613935424b69b3
* vo_gpu: hwdec_d3d11eglrgb: remove thiswm42019-10-161-279/+0
| | | | | Finally. Since with the previous commit we can (probably) handle P010 directly, this hack isn't needed anymore.
* vo_gpu: hwdec_d3d11egl: adapt to newer ANGLE APIwm42019-10-161-24/+33
| | | | | | | | | | | | | | | | | | | 2 years ago, ANGLE removed the old NV12-specific extension, and added a new one that supports a number of formats, including P010. Actually they just renamed it and removed their initial annoying and obvious design error (bravo, Google). Since it broke 2 years ago, nobody should give a shit about this code, and it should just be removed. But for some reason I still dived the shit-tank (Windows development). I guess Intel code monkeys can't write drivers (or maybe the issue is because we're doing zero-copy, which probably maybe is not actually allowed by D3D11 due to array textures, see --d3d11va-zero-copy), so the P010 path is completely untested. It doesn't work, I'll delete all this ANGLE hwdec code. Fixes: #7054
* wayland: use callback flag + poll for buffer swapdudemanguy2019-10-101-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old way of using wayland in mpv relied on an external renderloop for semi-accurate timings. This had multiple issues though. Display sync would break whenever the window was hidden (since the frame callback stopped being executed) which was really annoying. Also the entire external renderloop logic was kind of fragile and didn't play well with mpv's internal structure (i.e. using presentation time in that old paradigm breaks stats.lua). Basically the problem is that swap buffers blocks on wayland which is crap whenever you hide the mpv window since it looks up the entire player. So you have to make swap buffers not block, but this has a different problem. Timings will be terrible if you use the unblocked swap buffers call. Based on some discussion in #wayland, the trick here is relatively simple and works well enough for our purposes. Instead we basically build a way to block with a timeout in the wayland buffer swap functions. A bool is set in the frame callback function that indicates whether or not mpv is waiting for a frame to be displayed. In the actual buffer swap function, we enter into a while loop waiting for this flag to be set. At the same time, the wl_display is polled to block the thread and wakeup if it receives any events from the compositor. This loop only breaks if enough time has passed or if the frame callback bool is received. In the near future, it is better to set whether or not frame a frame has been displayed in the presentation feedback. However as a first pass, doing it in the frame callback is more than good enough. The "downside" is that we render frames that aren't actually shown on screen when the player is hidden (it seems like wayland people don't like that). But who cares. Accurate timings are way more important. It's probably not too hard to add that behavior back in the player though.
* wayland opengl: actually call uninit if init failsdudemanguy2019-10-031-1/+3
| | | | | | | | This is the proper fix to the memory leak @wm4 pointed out. It turns out that when you autoprobe opengl and vo_wayland_init returns false, vo_wayland_uninit is never actually executed. So you have a leftover pointer. The vulkan context does this correctly which was why my old, dumb "fix" broke it.
* vo: make swapchain-depth option generic for all VOsAnton Kindestam2019-09-284-6/+7
| | | | In preparation for making vo_drm able to use swapchain-depth
* drm: refactor page_flipped callbackAnton Kindestam2019-09-281-54/+6
| | | | | Avoid duplicating the same callback function in both context_drm_egl and vo_drm.
* drm: move struct vsync_tuple into drm_common as drm_vsync_tupleAnton Kindestam2019-09-281-9/+2
| | | | This struct will be useful in vo_drm as well.
* context_drm_egl: define EGL_PLATFORM_GBM_MESA, EGL_PLATFORM_GBM_KHR if not ↵Anton Kindestam2019-09-271-0/+8
| | | | | | | in system headers To account for oddball setups where EGL_PLATFORM_GBM_MESA or EGL_PLATFORM_GBM_KHR might not be defined for whatever reason.
* vo_gpu: hwdec_drmprime_drm: add hwdec ctxJonas Karlman2019-09-271-0/+14
| | | | | | | This allows to use drm hwaccels that require a hwdevice. Tested with v4l2request hwaccel and cedrus driver on an allwinner device running mpv with --vo=gpu --gpu-context=drm --hwdec=drm.
* context_android: move common code to a separate filesfan52019-09-271-52/+9
| | | | | | In preparation for a Vulkan Android context. This also replaces querying for EGL_WIDTH and EGL_HEIGHT with equivalent ANativeWindow calls.
* context_drm_egl: Don't get stuck forever if drmHandleEvent failsAnton Kindestam2019-09-221-1/+3
|
* context_drm_egl: Use eglGetPlatformDisplayEXT if availablememeka2019-09-201-1/+20
| | | | | | | | Check if eglGetPlatformDisplayEXT is available and try to use it to obtain the display connection. Fall back to eglGetDisplay if eglGetPlatformDisplayEXT is not available or failing. From PR #5992
* rpi: Update for modern systemsCameron Cawley2019-09-201-2/+2
|
* oml_sync: fix typo in commentwm42019-09-201-2/+2
| | | | I think... Also reword another part of the text.
* vo_gpu: remove vdpau/GLX backendwm42019-09-191-417/+0
| | | | | | | Useless garbage. This was once added to test whether vdpau presentation feedback could be used. Results were always unsatisfactory, and now vdpau is dead.
* vo_gpu: remove mali-fbdevwm42019-09-191-158/+0
| | | | | Useless at this point, I don't even know if it still works, or how to test it.
* drm: fix libmpv ABI breakage introduced in ↵Anton Kindestam2019-09-182-7/+7
| | | | | | | | | | | | | | | 351c083487050c88adb0e3d60f2174850f869018 Extending the client-allocated mpv_opengl_drm_params struct constituted a break of ABI that could cause UB. Create a clean break by deprecating "drm_params" and related structs and enum values, and replacing it with "drm_params_v2". Also fix some comments and code that wrongly assumed that open could return any other negative number than -1 for failure. This commit updates the libmpv version to 1.104
* vo_gpu: x11: remove special vdpau probing, use EGL by defaultwm42019-09-151-25/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, vo_gpu/vo_opengl considered the case of Nvidia proprietary drivers, which required vdpau/GLX, and Intel open source drivers, which require vaapi/EGL. Since window creation and GPU context creation are inseparable in mpv's internal API, it had to pick the correct API very early, or hardware decoding wouldn't work. "x11probe" was introduced for this reason. It created a GLX context (without showing the window yet), and checked whether vdpau was available. If yes, it used GLX, if not, it continued probing x11/EGL. (Obviously it couldn't always fail on GLX without vdpau, which is why it was a separate "probe" backend.) Years passed, and now the situation is different. Vdpau is dead. Nvidia drivers and libavcodec now provide CUDA interop, which requires EGL, and fixes some of the vdpau problems. AMD drivers now provide vaapi, which generally works better than vdpau. Intel didn't change. In particular, vaapi provides working HEVC Main10 support. In theory, it should work on vdpau too, with quality reduction (no 10 bit surfaces), but I couldn't get it to work. So always prefer EGL. And suddenly hardware decoding works. This is actually rather important, because HEVC is unfortunately on the rise, despite shitty encoders and unoptimized decoders. The latter may mean that hardware decoding works better than libavcodec. This should have been done a long, long time ago.
* vo_gpu: x11egl: support Mesa OML sync extensionwm42019-09-081-0/+24
| | | | | | | | | | | | | | | | | | | | Mesa supports the EGL_CHROMIUM_sync_control extension, and it's available out of the box with AMD drivers. In practice, this is exactly the same as GLX_OML_sync_control, but for EGL. The extension specification is separate from the GLX one though, and buried somewhere in the Chromium code. This appears to work, although I don't know if it really works. In theory, this could be useful for other EGL targets. Support code for it could have been added to egl_helpers.c to avoid some minor duplicated glue code if another EGL target were to provide this extension. I didn't bother with that. ANGLE on Windows can't support it, because the extension spec. explicitly requires POSIX timers. ANGLE on Linux/OSX is actively harmful for mpv and hopefully won't ever use it. Wayland uses EGL, but has its own fancy presentation feedback stuff (and besides, I don't think basic video player functionality works on Wayland at all). context_drm_egl maybe? But I think DRM has its own stuff.
* vo_gpu: glx: move OML sync code to an independent filewm42019-09-083-96/+145
| | | | | | | | | | | | | | | | | So the next commit can make EGL use it. EGL has a quite similar function, that practically works the same. Although it's relatively trivial, it's still tricky, and probably shouldn't end up as duplicated code. There are no functional changes, except initialization, and how failure of the glXGetSyncValues call is handled. Also, some comments mention the EGL extension. Note that there's no intention for this code to handle anything else than the very specific OML sync extension (and its EGL equivalent). This is just too weirdly specific to the weird idiosyncrasies of the extension, and it makes no sense to extend it to handle anything else. (Such as Wayland or DXGI presentation feedback.)
* vo_gpu: hwdec_vaegl: Rename and move to hwdec_vaapiPhilip Langdale2019-07-081-558/+0
| | | | | In preparation for adding Vulkan interop support, let's rename to remove the egl reference and move to an api neutral location.
* vo/gpu: hwdec_vdpau: Support direct mode for 4:4:4 contentPhilip Langdale2019-07-081-4/+15
| | | | | | | New releases of VDPAU support decoding 4:4:4 content, and that comes back as NV24 when using 'direct mode' in OpenGL Interop. That means we need to be a little bit smarter about how we set up the OpenGL textures.
* opengl/context_wayland: Fix crash on configure before initial reconfigMichael Forney2019-07-081-1/+3
| | | | | | | | | If the compositor sends a configure event before the surface is initially mapped, resize gets called before the egl_window gets created, resulting in a crash in wl_egl_window_resize. This was fixed back in 618361c697, but was reintroduced when the wayland code was rewritten in 68f9ee7e0b.
* video/out/gpu: Add a `storable` flag to ra_formatPhilip Langdale2019-07-081-0/+3
| | | | | | | | | | | | | | | | While `ra` supports the concept of a texture as a storage destination, it does not support the concept of a texture format being usable for a storage texture. This can lead to us attempting to create a texture from an incompatible format, with undefined results. So, let's introduce an explicit format flag for storage and use it. In `ra_pl` we can simply reflect the `storable` flag. For GL and D3D, we'll need to write some new code to do the compatibility checks. I'm not going to do it here because it's not a regression; we were already implicitly assuming all formats were storable. Fixes #6657
* drm_common: Add proper help option to drm-modeAnton Kindestam2019-05-041-1/+1
| | | | | | | This was implemented by using OPT_STRING_VALIDATE for drm-mode, instead of OPT_INT. Using a string here also prepares for future additions to drm-mode that aim to allow specifying a mode by its resolution.
* drm_common: Add option to toggle use of atomic modesettingAnton Kindestam2019-05-041-1/+2
| | | | | | It is useful when debugging to be able to force atomic off, or as a workaround if atomic breaks for some user. Legacy modesetting is less likely to break by virtue of being a less complex API.
* vo/gpu: hwdec_cuda: Refactor gpu api specific code into separate filesPhilip Langdale2019-05-031-749/+0
| | | | | | | | The amount of code now present that's specific to Vulkan or OpenGL has reached the point where we really want to split it out to avoid a mess of #ifdefs. At the same time, I'm moving the code to an api neutral location.
* context_drm_egl: Add support for presentation feedbackAnton Kindestam2019-05-031-15/+118
| | | | | This implements presentation feedback for context_drm_egl using the values that get fed to the page flip handler.
* vo_gpu/hwdec_cuda: fixup compilation with vulkan disabledJan Ekström2019-04-221-0/+2
| | | | | | | The actual code utilizing this enum was seemingly properly if'd, but not the enum in the struct itself. Fixes compilation.
* vo/gpu: hwdec_cuda: Reorganise backend-specific codePhilip Langdale2019-04-211-151/+223
| | | | | This tries to tidy up the GL vs Vulkan code to be a bit cleaner and easier to read.
* vo_gpu: hwdec_cuda: Implement interop for placeboPhilip Langdale2019-04-211-145/+224
| | | | | | | | | | | | | | | | | | | | This change updates the vulkan interop code to work with the libplacebo based ra_vk, but also introduces direct VkImage sharing to avoid the use of the intermediate buffer. It is also necessary and desirable to introduce explicit semaphore bsed synchronisation for operations on the shared images. Synchronisation means we can safely reuse the same VkImage for every mapped frame, by ensuring the frame is copied to the VkImage before mapping the next frame. This functionality requires a 417.xx or newer nvidia driver, due to bugs in the VkImage interop in the earlier 411 and 415 drivers. It's definitely worth the effort, as the raw throughput is about twice that of implementation using an intermediate buffer.
* vo_gpu: vulkan: use libplacebo insteadNiklas Haas2019-04-211-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | This commit rips out the entire mpv vulkan implementation in favor of exposing lightweight wrappers on top of libplacebo instead, which provides much of the same except in a more up-to-date and polished form. This (finally) unifies the code base between mpv and libplacebo, which is something I've been hoping to do for a long time. Note: The ra_pl wrappers are abstract enough from the actual libplacebo device type that we can in theory re-use them for other devices like d3d11 or even opengl in the future, so I moved them to a separate directory for the time being. However, the rest of the code is still vulkan-specific, so I've kept the "vulkan" naming and file paths, rather than introducing a new `--gpu-api` type. (Which would have been ended up with significantly more code duplicaiton) Plus, the code and functionality is similar enough that for most users this should just be a straight-up drop-in replacement. Note: This commit excludes some changes; specifically, the updates to context_win and hwdec_cuda are deferred to separate commits for authorship reasons.
* vo_gpu: index desc namespaces by raNiklas Haas2019-04-211-1/+1
| | | | | No reason to require them be constant. This allows them to depend on runtime characteristics of the `ra`.
* Merge branch 'master' into pr6360Jan Ekström2019-03-112-59/+151
|\ | | | | | | | | | | Manual changes done: * Merged the interface-changes under the already master'd changes. * Moved the hwdec-related option changes to video/decode/vd_lavc.c.
| * context_drm_egl: implement n-bufferingAnton Kindestam2019-02-251-59/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows context_drm_egl to use as many buffers as libgbm or the swapchain_depth setting allows (whichever is smaller). On pause and on still images (cover art etc.) to make sure that output does not lag behind user input, the swapchain is drained and reverts to working in a dual buffered (equivalent to swapchain-depth=1) manner. When possible (swapchain-depth>=2), the wait on the page flip event is now not done immediately after queueing, but is deferred to the next invocation of swap_buffers. Which should give us more CPU time between invocations. Although, since gbm_surface_has_free_buffers() can only tell us a boolean value and not how many buffers we have left, we are forced to do this contortionist dance where we first overshoot until gbm_surface_has_free_buffers() reports 0, followed by immediately waiting so we can free a buffer, to be able to get the deferred wait on page flip rolling. With this commit we do not rely on the default vsync fences/latency emulation of video/out/opengl/context.c, but supply our own, since the places we create and wait for th