summaryrefslogtreecommitdiffstats
path: root/video/out/opengl
Commit message (Collapse)AuthorAgeFilesLines
* vo: hwdec: Pass the ra_ctx to hwdecs instead of just the raPhilip Langdale2023-05-288-16/+18
| | | | | | We will need the full ra_ctx to be able to look up all the state required to initialise an ffmpeg vulkan hwcontext, so pass let's pass the ra_ctx instead of just the ra.
* opengl: move `ra_gl_ctx_params.flipped` to `struct GL`Niklas Haas2023-05-275-8/+8
| | | | | | This is motivated by a need to access it from vo_gpu_next's opengl wrapping code, and justified by it being an inherent property of the GL context itself,
* context_drm_egl: check for non-existant drm in uninitMatthew Lindner2023-05-221-19/+24
| | | | | | | | Previously, if vo_drm_init failed at the start of drm_egl_init it caused a use-after-free in drm_egl_uninit when it tried to access the non-existant drm context. At that point vo_drm_uninit had already been called resulting in two different null pointer dereference. In this situation the DRM private context had also not been allocated.
* context_angle: include eglext_angle.h explicitlyKacper Michajłow2023-03-301-0/+1
| | | | | Recent MSYS update switched to using vanilla EGL headers, which doesn't include eglext_angle.h implicitly.
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-213-10/+9
| | | | | | c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
* various: drop unused #include "config.h"Thomas Weißschuh2023-02-202-4/+0
| | | | | | Most sources don't need config.h. The inclusion only leads to lots of unneeded recompilation if the configuration is changed.
* osdep: add MP_FALLTHROUGHKacper Michajłow2023-02-021-1/+1
|
* vo_opengl/angle_dynamic: simplify symbol renaming to make it more ↵Kacper Michajłow2023-01-282-8/+5
| | | | straightforward
* x11: remove PresentNotifyMSC from egl/glx/vulkan to fix xpresent timingSultan Alsawaf2023-01-252-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PresentNotifyMSC turns out to be not only redundant, but also harmful with mesa-backed egl/glx/vulkan VOs because for all of them, mesa uses PresentPixmap behind the scenes when DRI3 is available, which already spawns a PresentCompleteNotify event when the buffer swap actually finishes. This is important because without using the timing information from these PresentCompleteKindPixmap events, there's no way for mpv to know exactly when a frame becomes visible on the display. By using PresentNotifyMSC in conjunction with DRI3-enabled mesa, two problems are created: 1. mpv assumes that a vblank won't elapse (i.e., it assumes the current MSC won't change) between the time when mesa enqueues the buffer swap and the time when mpv calls PresentNotifyMSC to ask xorg for a notification at the next MSC, relative to the current MSC at the time that xorg reads it for the PresentNotifyMSC call. This means that mpv could get a notification one or more vblanks later than it expects, since the intention here is for mpv to get a notification at the MSC that the buffer swap completes. 2. mpv assumes that a buffer swap always takes one vblank to complete, which isn't always true. A buffer swap (i.e., a page flip) could take longer than that depending on hardware conditions (if the GPU is running slowly or needs to exit a low-power state), scheduling delays (under heavy system or GPU load), or unfortunate timing (if the raster scan line happens to be at one of the last few rows of pixels and a vblank elapses just before the buffer swap is enqueued). This causes mpv to have a faulty assumption of when frames become visible. Since mpv already receives the PresentCompleteNotify events generated by mesa's buffer swaps under the hood, the PresentNotifyMSC usage is unneeded and just throws a wrench in mpv's vsync timing when xpresent is enabled. Simply removing the PresentNotifyMSC usage from the egl, glx, and vulkan VOs fixes the xpresent vsync timing.
* wayland: add wp-fractional-scale-v1 supportDudemanguy2023-01-241-0/+2
| | | | | | | | | | | | | This protocol is pretty important since it finally lets us solve the longstanding issue of fractional scaling in wayland (no more mpv doing rendering over the target resolution and then being scaled down). This protocol also can completely replace the buffer_scale usage that we are currently using for integer scaling so hopefully this can be removed sometime in the future. Note that vo_dmabuf_wayland is omitted from the fractional scale handling because we want the compositor to handle all the scaling for that VO. Fixes #9443.
* wayland: rewrite geometry and scaling handlingDudemanguy2023-01-241-4/+4
| | | | | | | | | This is in preparation for fractional scaling support. Basically, redo all the coordinates in wayland so that wl->geometry is equal exactly to what is being put out to the screen (no extra wl->scaling multiplication required). The wl->vdparams variable is also eliminated for simplicity. This changes mpv's behavior on wayland with hidpi scaling but that will be addressed in more detail with the next commit.
* vo_gpu: implement VO_DR_FLAG_HOST_CACHEDsfan52023-01-233-0/+18
| | | | | | | | For OpenGL, this is based on simply comparing GL_VENDOR strings against a list of allowed vendors. Co-authored-by: Nicolas F. <ovdev@fratti.ch> Co-authored-by: Niklas Haas <git@haasn.dev>
* drm: rewrite based around vo_drm_stateDudemanguy2023-01-211-336/+93
| | | | | | | | | | | A longstanding pain point of the drm VOs is the relative lack of state sharing. While drm_common does provide some sharing, it's far less than other platforms like x11 or wayland. What we do here is essentially copy them by creating a new vo_drm_state struct and using it in vo_drm and context_drm_egl. Much of the functionality that was essentially duplicated in both VOs/contexts is now reduced simple functions in drm_common. The usage of the term 'kms' was also mostly eliminated since this is libdrm nowadays from a userspace perspective.
* various: replace abort() with MP_ASSERT_UNREACHABLE() where appropriatesfan52023-01-121-7/+7
| | | | | | | | In debug mode the macro causes an assertion failure. In release mode it works differently and tells the compiler that it can assume the codepath will never execute. For this reason I was conversative in replacing it, e.g. in mpv-internal code that exhausts all valid values of an enum or when a condition is clear from directly preceding code.
* wayland: make vo_wayland_reconfig a boolDudemanguy2023-01-081-4/+1
| | | | | | This was already returning true/false but the type was int. Also simplify a few places in the wayland contexts where we can just return the value of this function instead of doing redundant checks.
* wayland: cleanup on vo_wayland_init errorDudemanguy2023-01-081-4/+1
| | | | | | Instead of just returning true/false, it's better to have this function cleanup itself. We can eliminate some redundant uninit calls elsewhere in the code as well.
* vo_opengl: do not blindly reject all Microsoft's OpenGL implementationsKacper Michajłow2022-12-301-3/+3
| | | | | | | | | | | | | This change enables mpv to work in the WSL2 (WSLg) environment where OpenGL is implemented on top of D3D12. This reverts commit 149d98d244. Mentioned OpenGL implementation (GDI Generic) in the original change will be rejected by version check, so there is no need to handle it manually. Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
* drm: remove legacy APILaserEyess2022-11-161-109/+46
| | | | | | | | | | | | | The legacy DRM API adds some complexity to the DRM code. There are only 4 drivers that do not support the DRM Atomic API: 1. radeon (early GCN amd cards) 2. gma500 (ancient intel GPUs) 3. ast (ASPEED SoCs) 4. nouveau Going forward, new DRM drivers will be guaranteed to support the atomic API so this is a safe removal.
* vo_gpu/hwdec: rename and introduce legacy names for some interopsPhilip Langdale2022-10-111-322/+0
| | | | | | | | | | | | We've had some annoying names for interops, which we can't simply rename because that would break config files and command lines. So we need to put a little more effort in and add a concept of legacy names that allow us to continue loading them, but with a warning. The two I'm renaming here are: * vaapi-egl -> vaapi (vaapi works with Vulkan too) * drmprime-drm -> drmprime-overlay (actually describes what it does) * cuda-nvdec -> cuda (cuda interop is not nvdec specific)
* wayland: correctly handle non-CLOCK_MONOTONIC clocksDudemanguy2022-10-061-2/+2
| | | | | | | | | | | | | The wayland presentation time code currently always assumes that only CLOCK_MONOTONIC can be used. There is a naive attempt to ignore clocks other than CLOCK_MONOTONIC, but the logic is actually totally wrong and the timestamps would be used anyway. Fix this by checking a use_present bool (similar to use_present in xorg) which is set to true if we receive a valid clock in the clockid event. Additionally, allow CLOCK_MONOTONIC_RAW as a valid clockid. In practice, it should be the same as CLOCK_MONOTONIC for us (ntp/adjustime difference wouldn't matter). Since this is a linux-specific clock, add a define for it if it is not found.
* vo: hwdec: do hwdec interop lookup by image formatPhilip Langdale2022-09-216-0/+6
| | | | | | | | | | | | | | It turns out that it's generally more useful to look up hwdecs by image format, rather than device type. In the situations where we need to find one, we generally know the image format we're dealing with. Doing this avoids us having to create mappings from image format to device type. The most significant part of this change is filling in the image format for the various hw interops. There is a hw_imgfmt field today today, but only a couple of the interops fill it in, and that seems to be because we've never actually used this piece of metadata before. Well, now we have a good use for it.
* vo_gpu_next: pass GL get_proc_addr pointer to libplaceboNiklas Haas2022-08-192-0/+7
| | | | | | | | | | | | | | | | | Facing down the multitude of ways to somehow wrangle the get_fn pointer out of the GL environment and into libplacebo, I decided the easiest is to just store it inside the GL struct itself. The lifetime of this get_fn function is a bit murky, since it's not clear on whether or not it survives the VO init call (especially in the case of the GL render API, which explicitly states that parameters do not need to survive the call they're passed to), so just add a disclaimer. (It's fine for us to use like this because `gpu_ctx_create` is still part of VO init) Closes https://code.videolan.org/videolan/libplacebo/-/issues/216
* context_drm_egl: skip page flip wait on errorHo Ming Shun2022-08-111-1/+1
| | | | | Any error in page flipping caused mpv to wait indefinitely for a page flip callback.
* drm: avoid drmModeAtomicCommit races by blockingHo Ming Shun2022-08-031-1/+1
| | | | | | | | On S905X (meson) boards drmModeAtomicCommit called from disable_video_plane in hwdec_drmprime_drm.c might still be running when another call is made from queue_flip in context_drm_egl.c. This causes EBUSY error in queue_flip, and causes mpv to hang.
* drm_prime: fix newline in error messageHo Ming Shun2022-07-051-1/+1
|
* context_x11egl: remove supposed transparency fixDudemanguy2022-07-011-3/+0
| | | | | | | | | | | | | | | | This was introduced in 7fb972fd3997bfa389caa7c1eb899ea4b8444083 and later revised in f5a094db047ee0162774301a2ce4ed685ca9d539. Transparency in EGL/X11 has been broken upstream for years in Mesa unfortunately. However, the first commit claimed to have found a way to preserve transparency by doing a trick with picking EGLConfigs (the second commit revises this but keeps the logic in place). However, it doesn't appear that the first commit actually fixes anything (transparency doesn't work on my machine) and no one else seems to have reported it working. On the other hand, if Mesa does ever actually fix this, transparency would immediately be broken since mpv would always set the EGL_ALPHA_SIZE to 0. Go ahead and remove this since it doesn't seem to have any actual utility and is technically a bit of a timebomb (not that deleting two lines is a lot of work but still) if upstream ever does fix this.
* x11: avoid XPresent API calls when it's not neededDudemanguy2022-06-222-6/+12
| | | | | | | | | | | This commit kind of mixes several related things together. The main thing is to avoid calling any XPresent functions or internal functions related to presentation when the feature is not auto-whitelisted or enabled by the user. Internally rework this so it all works off of a use_present bool (have_present is eliminated because having a non-zero present_code covers exactly the same thing) and make sure it updates on runtime. Finally, put some actual logging in here whenever XPresent is enabled/disabled. Fixes #10326.
* x11: support xorg present extensionDudemanguy2022-06-194-191/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This builds off of present_sync which was introduced in a previous commit to support xorg's present extension in all of the X11 backends (sans vdpau) in mpv. It turns out there is an Xpresent library that integrates the xorg present extention with Xlib (which barely anyone seems to use), so this can be added without too much trouble. The workflow is to first setup the event by telling Xorg we would like to receive PresentCompleteNotify (there are others in the extension but this is the only one we really care about). After that, just call XPresentNotifyMSC after every buffer swap with a target_msc of 0. Xorg then returns the last presentation through its usual event loop and we go ahead and use that information to update mpv's values for vsync timing purposes. One theoretical weakness of this approach is that the present event is put on the same queue as the rest of the XEvents. It would be nicer for it be placed somewhere else so we could just wait on that queue without having to deal with other possible events in there. In theory, xcb could do that with special events, but it doesn't really matter in practice. Unsurprisingly, this doesn't work on NVIDIA. Well NVIDIA does actually receive presentation events, but for whatever the calculations used make timings worse which defeats the purpose. This works perfectly fine on Mesa however. Utilizing the previous commit that detects Xrandr providers, we can enable this mechanism for users that have both Mesa and not NVIDIA (to avoid messing up anyone that has a switchable graphics system or such). Patches welcome if anyone figures out how to fix this on NVIDIA. Unlike the EGL/GLX sync extensions, the present extension works with any graphics API (good for vulkan since its timing extension has been in development hell). NVIDIA also happens to have zero support for the EGL/GLX sync extensions, so we can just remove it with no loss. Only Xorg ever used it and other backends already have their own present methods. vo_vdpau VO is a special case that has its own fancying timing code in its flip_page. This presumably works well, and I have no way of testing it so just leave it as it is.
* vo: move wayland presentation to separate filesDudemanguy2022-06-191-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Wayland had some specific code that it used for implementing the presentation time protocol. It turns out that xorg's present extension is extremely similar, so it would be silly to duplicate this whole mess again. Factor this out to separate, independent code and introduce the mp_present struct which is used for handling the ust/msc values and some other associated values. Also, add in some helper functions so all the dirty details live specifically in present_sync. The only wayland-specific part is actually obtaining ust/msc values. Since only wayland or xorg are expected to use this, add a conditional to the build that only adds this file when either one of those are present. You may observe that sbc is completely omitted. This field existed in wayland, but was completely unused (presentation time doesn't return this). Xorg's present extension also doesn't use this so just get rid of it all together. The actual calculation is slightly altered so it is correct for our purposes. We want to get the presentation event of the last frame that was just occured (this function executes right after the buffer swap). The adjustment is to just remove the vsync_duration subtraction. Also, The overly-complicated queue approach is removed. This has no actual use in practice (on wayland or xorg). Presentation statistics are only ever used after the immediate preceding swap to update vsync timings or thrown away.
* wayland_gl: fix a typoDudemanguy2022-06-111-1/+1
| | | | | Somehow in commit 661b5542de21d46d4d7c4693e564f4eec0526812, my editor snuck in a ￥ sign in here. Oops.
* wayland_gl: wait until resize to create egl_windowDudemanguy2022-06-101-34/+32
| | | | | | | | | | | | | Some wayland compositors (i.e. weston) get extremely picky about committed buffer sizes not matching the configured state. In particular, weston throws an error on you if you attempt to launch with --window-maximized and use opengl (vo_vaapi_wayland actually errors as well in this case, but that's a different issue). The culprit here is actually wl_egl_window_create. This creates an initial buffer at the sizes passed in the arguments which is what weston doesn't like. Instead, move the egl_window creation call to the resize function. This ensures that mpv is using the size obtained via the toplevel event, and it should always be the buffer size we want.
* wayland_gl: use wl->scaling when creating egl_windowDudemanguy2022-06-071-2/+3
| | | | | | | | | | | | | This was actually always bugged, but we just got lucky that compositors ignored it. The egl window was created only using wl->geometry's coordinates but those do not include the scale factor. So technically, the initial window creation always had the wrong size (off by whatever the scaling factor is). The resize call later fixes it because that correctly uses wl->scaling so in practice nothing bad was seen. wlroots's master branch has started sending an error in this case however and this is what trips it. Fix it correctly by using the scale factor. This is what cd3b4edea06dec659d9676f2649cc1b1be2e8565 tried to fix (but was incorrect).
* context_drm_egl: support monitor parDudemanguy2022-05-051-0/+9
| | | | | | These values and options were simply never looked at in the drm egl context. This pretty much is just a copy and paste of what is in vo_drm. Fixes #10157.
* various: fix typosCœur2022-04-251-1/+1
|
* x11: avoid wasteful rendering when possibleDudemanguy2022-04-112-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because wayland is a special snowflake, mpv wound up incorporating a lot of logic into its render loop where visibilty checks are performed before rendering anything (in the name of efficiency of course). Only wayland actually uses this, but there's no reason why other backends (x11 in this commit) can't be smarter. It's far easier on xorg since we can just query _NET_WM_STATE_HIDDEN directly and not have to do silly callback dances. The function, vo_x11_check_net_wm_state_change, already tracks net wm changes, including _NET_WM_STATE_HIDDEN. There is an already existing window_hidden variable but that is actually just for checking if the window was mapped and has nothing to do with this particular atom. mpv also currently assumes that a _NET_WM_STATE_HIDDEN is exactly the same as being minimized but according to the spec, that's not neccesarily true (in practice, it's likely that these are the same though). Anyways, just keep track of this state in a new variable (hidden) and use that for determing if mpv should render or not. There is one catch though: this cannot work if a display sync mode is used. This is why the previous commit is needed. The display sync modes in mpv require a blocking vsync implementation since its render loop is directly driven by vsync. In xorg, if nothing is actually rendered, then there's nothing for eglSwapBuffers (or FIFO for vulkan) to block on so it returns immediately. This, of course, results in completely broken video. We just need to check to make sure that we aren't in a display sync mode before trying to be smart about rendering. Display sync is power inefficient anyways, so no one is really being hurt here. As an aside, this happens to work in wayland because there's basically a custom (and ugly) vsync blocking function + timeout but that's off topic.
* wayland: unify visibility checking codeDudemanguy2022-04-113-16/+21
| | | | | | | | | | | A bit of a personal pet peeve. vulkan, opengl, and wlshm all had different methods for doing wayland's "check for visibility before drawing" thing. The specific backend doesn't matter in this case and the logic should all be shared. Additionally, the external swapchain that the opengl code on wayland uses is done away with and it instead copies vulkan by using a param. This keeps things looking more uniform across backends and also makes it easier to extend to other platforms (see the next couple of commits).
* egl_helpers: request at least 8 alpha bits if necessaryOlivier Perret2022-04-071-1/+1
| | | | | | Previously on wayland, it would result in an egl config with only 2 alpha bits, which technically matches what was requested, but is not very useful. Fixes #9862
* drm: context_drm_egl: add support for enabling VRRPhilip Langdale2022-04-051-0/+18
| | | | | | | | | | | | | | Variable Refresh Rate (VRR), aka Freesync or Adaptive Sync can be used with DRM by setting the VRR_ENABLED property on a crtc if the connector reports that it is VRR_CAPABLE. This is a useful feature for us as it is common to play 24/25/50 fps content on displays that are nominally locked to 60Hz. VRR can allow this content to play at native framerates. This is a simple change as we just need to check the capability and set the enabled property if requested by the user. I've defaulted it to disabled for now, but it might make sense to default to auto in the long term.
* vo_gpu: stop hard-coding max compute group threadsPhilip Langdale2021-12-192-0/+3
| | | | | | | | | | We've been assuming that maximum number of compute group threads is never less than the 1024 defined by the desktop GL spec. Given that we haven't had working compute shaders for GLES and I guess the Vulkan spec defines at least as high a value, we've gotten away with it so far. But we should really look the value up and respect it.
* {player,video}: remove references to obsolete opengl-cb APIsfan52021-12-153-34/+2
|
* 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.
* 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.
* 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.
*