summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* {player,video}: remove references to obsolete opengl-cb APIsfan52021-12-155-37/+5
|
* vo_gpu: opengl: some fixes to make compute shaders work with GLESPhilip Langdale2021-12-124-10/+15
| | | | | | | | | It's supposed to work with GLES >= 3.1 but we had all sorts of bad assumptions in our version handling, and then our compute shaders turn out not to be GLSL-ES compliant. This change contains some necessary, but insufficient, tweaks to the shaders. Perhaps we'll make it actually work some day.
* vo_gpu: opengl: fix OpenGL ES version and extension handlingPhilip Langdale2021-12-122-5/+25
| | | | | | | | Some of the extension declarations did not include the ES version where they became core functionality, and in some of these cases, there was never actually an ES extension - it first appeared in core. We also had a number of buggy version checks where ES versions were compared against required desktop GL versions.
* vo_gpu: opengl: try and create context at version 440 againPhilip Langdale2021-12-071-0/+9
| | | | | | | | | | | | | | | | | | | | | nvidia follow the OpenGL spec very strictly, with two particular consequences: * They will give you the exact context version that you ask for, rather than the highest possible version that meets your request. * They will hide extensions that the specs say require a higher version than you request, even if it's technically possible to provide the extension at lower versions. In our case, we really want a variety of extensions, particularly compute shaders that are only available in 4.2 or higher. That means that we must explicitly include a high enough version in our list of versions to check for us to be able to get a 'good' enough context. As for which version? We restore the 4.4 version that we had in the old version selection logic. This is the highest version we ever asked for, and we have separate logic that clamps the GLSL version to 4.4, so anything newer wouldn't make a difference.
* vo_gpu: opengl: fix wrong glMemoryBarrierNiklas Haas2021-12-061-1/+1
| | | | This call was completely wrong.
* vo_gpu_next: fix UB in query_format()Niklas Haas2021-12-051-1/+1
| | | | | | | | | `plane_data_from_imgfmt` doesn't zero-initialize the struct, so this contained invalid values for e.g. `row_stride`, causing formats to *randomly* fail. (Especially any formats with specific alignment requirements) Might fix #9424 and #9425.
* wayland: ensure read and draw buffers are assignedKurt Kartaltepe2021-12-043-0/+9
| | | | | | | | | | | | | | | | | This is a workaround for nvidia proprietary drivers. The authors of those drivers interpret the spec such that eglMakeCurrent will not reconfigure the read and draw buffers. Thus windows wont display anything drawn by opengl. nvidia authors refer to https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_no_config_context.txt specifically Issues 2/3 which reference eglMakeCurrent. On mesa this is a non-issue and the read/draw targets are assigned with eglMakeCurrent. The context must be made current in order to query OpenGL strings. An earlier proposal to create the wayland window surface similarly to X11 during init was deemed inappropriate so instead we manually set the targets once we have created a window surface.
* opengl: support DebugMessageCallback on ESKurt Kartaltepe2021-12-021-0/+11
| | | | | This function is provided by a different extension on OpenGL ES so we add a separate gl_functions.
* vo_gpu_next: implement VOCTRL_SCREENSHOTNiklas Haas2021-11-281-2/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | Somewhat annoying but still relatively straightforward. There are several ways to approach this, but I settled on reusing the pl_queue as a cheap way to get access to the currently mapped frame. This saves us from having to process `vo_frame` at all, and also avoids any overhead from re-uploading the same frame twice. (However maybe there's some circumstance in which `vo_frame` needs to be queried/updated first, to get a screenshot of the correct frame? I'm not sure.) I also had the option of going with either pl_render_image() on the extract pl_frame, or just calling pl_render_image_mix directly on it. I went for the latter, because in the optimal case, this allows the rendered frame to be directly retrieved from the cache, actually entirely avoiding any sort of recompute overhead. This makes e.g. ctrl+s during playback essentially free. (Except for the download cost, obviously) It would be even neater if we could make this VOCTRL asynchronous and thereby leverage libplacebo's asynchronous download capabilities. But oh well. That will have to wait for a sufficiently rainy day. Closes #9388
* vo_gpu_next: factor out some common helpersNiklas Haas2021-11-281-43/+63
| | | | In preparation of VOCTRL_SCREENSHOT support
* vo_gpu_next: guard sentinel in free_dr_bufNiklas Haas2021-11-261-0/+1
| | | | | | As noticed in #9526, apparently there's some case in which DR buffers get corrupted. Add an explicit sentinel check to try and figure out which cases these are.
* vo_gpu: hwdec_vaapi: avoid drm_fourcc.h dependencyDave Airlie2021-11-251-1/+4
| | | | Suggested by haasn
* wayland: increase the vblank waiting timeDudemanguy2021-11-251-0/+2
| | | | | | | | | | | This commit sucks bad, but everything else is worse is other ways. Basically, the current vblank waiting time in the vo_wayland_wait_frame function (calculated very carefully using presentation statistics) is randomly too short. Some compositors are quite variable when they actually return callback so our timeout expires too quickly and throws everything off. The fix? Add an arbitrary 5% to the vblank value and pray that nothing gets off that much. Why did they have to make swapinterval 1/fifo mode indefinitely block? Fixes #9504.
* wayland: initialize presentation time values as 0Dudemanguy2021-11-241-0/+3
| | | | | | | Better to avoid any wonky calculations on startup with garbage values. The others end up being derived from last_ust/last_msc. refresh_interval is referenced exactly once and could, in theory, result in some terribly erroneous vblank time.
* wayland: cancel prepared reads when no eventsKurt Kartaltepe2021-11-251-6/+8
| | | | | | | | | | | | | A read can be prepared on the wayland display FD that is never actually read. This occurs when events are triggered on other FDs in the fd set. This change cancels a prepared read if poll reported no events for it. This fixes some hangs due to how nvidia's EGL implementation polls on the wayland fd unlike mesa implementations. It is based on nvidia's proposed fix for qt's similar message pump in https://codereview.qt-project.org/c/qt/qtwayland/+/373473 Signed-off-by: Kurt Kartaltepe <kkartaltepe@gmail.com>
* vo_gpu: hwdec_vaapi: add dma-buf modifiers support.Dave Airlie2021-11-232-1/+20
| | | | | If the EGL extension is present, pass the modifiers for each plane to the EGL driver.
* vo_gpu_next: implement OpenGL context supportsfan52021-11-222-7/+78
| | | | | Wrapping the context is pretty straightforward. This is only complicated by needing to account for the upside-down framebuffer in a few places.
* vo_gpu_next: factor out context-specific code to gpu_next/context.csfan52021-11-223-27/+138
| | | | | | This is done to avoid cluttering vo_gpu_next.c with more ifdeffery and context-specific code when additional backends are added in the near future. Eventually gpu_ctx is intended to take the place of ra_ctx to further separate gpu and gpu_next.
* video: opengl: teach start_frame() about out_fbo == NULLsfan52021-11-221-0/+2
| | | | | | This case was added in 662c793a557925319493297de8c941a636f18d73 for use in vo_gpu_next as a visibility test before rendering a frame. The OpenGL context doesn't have this so it just returns true.
* vo_gpu_next: respect tagged YUV colorspaceNiklas Haas2021-11-221-1/+2
| | | | Fixes 2b2442ee67913221e5c87cbc06010671e1b41c15
* vo_gpu_next: apply csp overrides for RGB/XYZ/YUV formatsNiklas Haas2021-11-221-11/+27
| | | | | | | | | | | | | This is needed when the color system is not explicitly tagged, but instead needs to be inferred by the VO. Note that there exists the function mp_image_params_guess_csp for this sort of stuff, but it contains a lot of baggage that I don't want to replicate, in order to move as much of this logic into pl_renderer as possible, and therefore also give it the best chance of knowing what shortcuts it can and can't take. Fixes the other half of https://github.com/mpv-player/mpv/issues/9499
* vo_gpu_next: fix timings without interpolationDudemanguy2021-11-211-3/+5
| | | | | | | | | | Adding vsync_offset to the pts in pl_queue_update actually messes up frame timings if one isn't using interpolation. The easiest way to see this is to have the monitor's refresh rate at an integer multiple of a video during a panning shot (classic case). There will be very visible judder/stutter in this case that does not happen in vo_gpu. The cause of this is the addition of the extra vsync_offset. Just match the semantics of vo_gpu where this is only used when interpolating.
* vo_gpu_next: fix OOM on waylandNiklas Haas2021-11-201-7/+3
| | | | | | Similar to ff0864d5f07d31c808014dbf1791ed3ec14644a8 Fixes #9484
* wayland: fix a potential segfault on surface enterDudemanguy2021-11-201-0/+3
| | | | | | | | | | | | | | | | | | This possibility actually existed for years. The wayland protocol is asynchronous and there's no restriction on when a compositor can send a surface enter event. In mpv's case, the surface enter event is used to set some vital things regarded geometry/scaling etc. However, this implictly assumes that wl->current_output is actually initialized. The vast majority of the time, vo_wayland_reconfig will happen first which is where wl->current_output is, and should, be created. There's no rule/law that the ordering of events will always occur in this order. Plasma with certain auto-profile conditions can send the surface enter event before mpv does its initial reconfig. That segfaults of course. Just add a check to make sure we have wl->current_output here and return if we don't. This assumes that the compositor will send us another surface enterance event when mpv actually does the initial surface commit and roundtrip request later. Wayland logs indicate this does happen. Fixes #9492.
* wayland: support modifiers during axis eventsDudemanguy2021-11-201-4/+5
| | | | | | It was never implemented before but it's trivial. As an aside, touch events currently don't support modifiers either (is this a thing?). Well if someone complains that can be done later. Fixes #9490.
* vo_gpu_next: always cache still framesNiklas Haas2021-11-191-1/+3
| | | | | | | Even when not display synced. Prevents redraw overhead for refreshes while paused. Also make the logic slightly clearer to follow (since it's inverted).
* vo_gpu_next: fix lancozs typo to lanczosLeo Izen2021-11-191-1/+1
| | | | | Fix typo in the warning to avoid ewa_lanczossharp because it might be removed in the future.
* vo_gpu: libplacebo: make version logging slightly clearerNiklas Haas2021-11-191-1/+2
| | | | Matches what `pl_log_create` does as well.
* vo_gpu_next: simplify and improve frame redrawing logicNiklas Haas2021-11-191-14/+6
| | | | | | | | | | | | | | | | | | This almost perfectly recreates the semantics of --vo=gpu, i.e.: - still frames are never interpolated - non-repeated frames bypass single frame cache The only difference is that libplacebo doesn't do a cache/blit on the full output image, but rather it re-runs the last rendering step. This has some advantages and some drawbacks. The most notable advantage is that it also allows re-using the image contents when the only thing that changes is the OSD (whereas `--vo=gpu` would force a full re-render for that). The most notable drawback is that it also implies going through the dithering and output LUT logic on redraws. All in all, I think this is a pretty good trade-off in favor of `--vo=gpu-next`. Fully fixes the last remaining performance difference in #9430.
* vo_gpu_next: fix panning on rotated videosNiklas Haas2021-11-191-4/+10
| | | | Closes #9454
* context_glx: fix check for wrong GLX extensionsfan52021-11-171-2/+2
| | | | | | | GLX_CONTEXT_PROFILE_MASK_ARB and related constants are provided by GLX_ARB_create_context_profile but the check was for _create_context. The former implies the latter (which we also need) so just replace the checked extension.
* context_{wayland,x11egl}: use mpegl_create_window_surface() toosfan52021-11-172-5/+12
| | | | Again no functional difference, just uses better APIs when they're available.
* context_drm_egl: make use of mpegl_create_window_surface()sfan52021-11-171-11/+3
| | | | This does what 3a10210c568f9c7d969ca6c4da2377c55fbf30f3 was supposed to, but better.
* egl_helpers: introduce wrapper around eglCreatePlatformWindowSurfacesfan52021-11-172-12/+50
| | | | | | It abstracts EGL 1.5, extension checks and other inconsistencies away. This can be used in context code as the (preferred) alternative to eglCreateWindowSurface().
* video: opengl: use gl_check_extension() instead of strstr()sfan52021-11-176-9/+8
| | | | | | Using a simple substring match for extension checks is considered bad practice because it's incorrect when one extension is a prefix of another's name. This will almost surely not make a difference in practice but do it for correctness anyway.
* context_drm_egl: use mpegl_get_display() helper over own codesfan52021-11-171-12/+7
| | | | | | Although there are no known problems with this, using the helper should be more portable. It will also prefer EGL 1.5's eglGetPlatformDisplay over eglGetPlatformDisplayEXT if available.
* vo_gpu: vulkan: open DRM render fd when using VK_KHR_displayPhilip Langdale2021-11-151-2/+102
| | | | | | | | | | | | | | | While the basic Vulkan Display context can theoretically drive the display without the involvement of any non-Vulkan code, that prevents us from using VAAPI acceleration. When initialising VAAPI without a window system, we need to provide it with an opened DRM render fd corresponding to the device to use. In the context of using VK_KHR_display, that means we need to identify which DRM device matches the selected Vulkan device, and then open its render fd and set the necessary state that VAAPI expects to find. With that done, the normal VAAPI<->Vulkan interop can kick in and we get working acceleration
* options: remove always true m_obj_list::allow_unknown_entriesEmil Velikov2021-11-151-1/+0
| | | | | | | Ever instance of m_obj_list is a constant and for all of them, the field is true. Just remove the field all together. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* egl_helpers: remove EGL_OPENGL_ES3_BITDudemanguy2021-11-111-2/+1
| | | | | | | | | | | | | | d2e8bc449986e012f257249a996386bd323febd0 was the the commit that originally introduced the usage of this bit. As the message states, the purpose was to force creating GLES 3 contexts on drivers that do not return a higher version context than what was requested. With the recent opengl refactors, mpv's gl selection has already moved away from such complicated queries. Perhaps when that commit was added things were different, but nowadays it seems like Mesa simply returns the highest driver version available that is compatibile with the request (i.e. requesting GLES 2 returns a GLES 3 context on my machine). In that case, let's just simply drop EGL_OPENGL_ES3_BIT altogether as it does break GLES 2 only machines. Fixes #9431.
* context_drm_egl: use eglCreatePlatformWindowSurfaceEXT if availablesfan52021-11-111-2/+12
| | | | | This is identical to eglCreateWindowSurface but should be preferred as part of EGL's platform extension.
* context_drm_egl: add support for BGR surface formatsPhilip Langdale2021-11-103-3/+34
| | | | | | | | | | | | The new GBM supporting nvidia drivers declare support for 10bit surfaces using BGR ordering, rather than RGB, so add support for them. We've also seen examples of hardware supporting BGR8888 but not RGB8888 so let's support those too. Of course, the nvidia EGL driver doesn't publish support for any 10bit formats so you can't actually do 10bit display. Perhaps they'll eventually fix that.
* context_drm_egl: use gbm_surface_create_with_modifiersPhilip Langdale2021-11-101-9/+93
| | | | | | | | | The GBM supporting nvidia driver doesn't support creating surfaces without modifiers and using modifiers is more and more recommended as the right way to do this. Enumerating modifiers is painfully verbose, but necessary if we are to allow the driver to pick the best possible one.
* vo_gpu_next: fix slight performance regressionNiklas Haas2021-11-101-3/+1
| | | | | | | | This logic, which was working around a libplacebo bug, ended up always alpha blending - even for sources without an alpha channel. This caused a minor slowdown to be constantly enabled. Due to the recent bump to libplacebo v170, this is no longer needed.
* vo_gpu_next: Initialize `pl_frame_mix`Starsam802021-11-091-1/+1
| | | | | Without initializing, the random data causes the `pl_render_image_mix` function to abort with a SIGSEGV.
* vo_gpu_next: implement HDR passthroughNiklas Haas2021-11-081-0/+60
| | | | | | | | Completely untested, since Linux still can't into HDR in 2021. Somebody please make sure it works. Technically covers #8219, since gpu-context=drm can be combined with vo=gpu-next.
* vo_gpu_next: drop PL_API_VER checksNiklas Haas2021-11-081-8/+0
| | | | These are no longer needed with the minimum version bump.
* vo_gpu_next: fix resource exhaustion on minimized windowsNiklas Haas2021-11-081-2/+8
| | | | | | | | This required an upstream API change to implement in a way that doesn't unnecessarily re-push or upload frames that won't be used. I consider this a big enough bug to justify bumping the minimum version for it. Closes #9401
* wayland: remove bogus scale_change variableDudemanguy2021-11-082-24/+1
| | | | | | | | | This was originally added in f2afae55e95b4b1eec1aeb828ba6ff1f0695d993 for unclear reasons (way to go me). This concept is clearly incorrect. It doesn't matter what state the window is in. As soon as mpv detects a scale change, it needs to reset the buffer scale of the window. Just remove all this junk and put wl_surface_set_buffer_scale in set_surface_scaling like it should be. Related issue: #9426.
* vo_gpu_next: add automatic translation for ewa_lanczossharpNiklas Haas2021-11-071-0/+7
| | | | | | | This one hits a lot of people. Probably because the man page explicitly recommends it. Fixes #9408
* vo_gpu_next: implement --dither-depthNiklas Haas2021-11-071-0/+8
| | | | | | I somehow completely forgot about this option existing. Closes #9416
* vo_gpu_next: remove --builtin-scalers optionNiklas Haas2021-11-071-4/+0
| | | | | | | | | | | Looking at this again I'm not sure it does anything useful at all. The man page entry is also wrong: `bicubic` is not affected, only `bicubic_fast`, and those filters are not configurable anyways. So this would only ever be a debugging option, and I don't see a pressing need for it. No interface-change.rst update because it only just got added anyways.
* vo_gpu_next: call start_frame in vulkan/context.cDudemanguy2021-11-042-2/+12
| | | | | | | | | In practice, this is for wayland. vo_gpu_next doesn't check the check_visible parameter since it didn't descend into the vulkan/context.c file when starting a frame. To make this happen, just call the start_frame function pointer but pass NULL as the ra_fbo. In there, we can do the visibility checks and after that bail out of the start_frame function if ra_fbo is NULL.
* wayland_vk: rename start_frame to check_visibleDudemanguy2021-11-043-9/+10
| | | | | | | | | | This vulkan-specific parameter was poorly named and probably causes confusion. Just rename it to check_visible instead to make clear what is going on here. Only wayland uses it for now but in theory anyone else can. As an aside, wayland egl accomplishes this by using an external swapchain instead (an opengl-only concept in the mpv code). This may or may not need to be changed in the future when gpu-next gets opengl support.
* osdep: rename MP_UNREACHABLENiklas Haas2021-11-034-10/+10
| | | | | It was pointed out on IRC that the name is misleading, since the actual semantics of the macro is to assert first.
* vo_gpu_next: fix --tone-mapping-param mappingNiklas Haas2021-11-031-0/+2
| | | | | | vo_gpu defaults this to NAN, libplacebo uses 0.0 as the default. Fixes https://github.com/mpv-player/mpv/issues/9386
* vo_gpu_next: add new libplacebo-based rendererNiklas Haas2021-11-034-0/+1396
| | | | | | | | | | | | | As discussed in #8799, this will eventually replace vo_gpu. However, it is not yet complete. Currently missing: - OpenGL contexts - hardware decoding - blend-subtitles=video - VOCTRL_SCREENSHOT However, it's usable enough to cover most use cases, and as such is enough to start getting in some crucial testing.
* osdep: add MP_UNREACHABLENiklas Haas2021-11-033-3/+3
| | | | | | | | | This seems to work on gcc, clang and mingw as-is, but I made it conditional on __GNUC__ just in case, even though I can't figure out which compilers we care about that don't export this define. Also replace all instances of assert(0) in the code by MP_UNREACHABLE(), which is a strict improvement.
* vo_gpu: allow using bare windows as --(t)scaleNiklas Haas2021-11-031-0/+20
| | | | | | | | | | | A lot of people seem to do something like --tscale=box --tscale-window=<function>. Just let them use --tscale=<function> directly, by also accepting raw windows. Kinda hacky but needed for feature parity with vo_gpu_next, which no longer has `--tscale=box`. Note that because the option struct is still shared, vo_gpu_next inherits the same option handling code, so we have to export this feature for vo_gpu as well.
* vo_gpu: vulkan: expose swapchain to mpvk_ctxNiklas Haas20