summaryrefslogtreecommitdiffstats
path: root/video/out/vulkan
Commit message (Collapse)AuthorAgeFilesLines
* vf_gpu: vulkan and egl implementationsShreesh Adiga25 hours2-25/+39
| | | | | | | | Abstract out EGL, and allow choosing between EGL and vulkan at runtime. vf_gpu_egl.c contains GL specific context and creation/destroy code, vf_gpu_vulkan.c contains Vulkan specific. This allows vf_gpu being built in systems where EGL is not available and where Vulkan is available.
* various: add GPU context descriptionnanahi9 days6-0/+6
| | | | | | | Now that obj_settings_list is used for GPU contexts, detailed descriptions can be added so that --gpu-context=help can print the descriptions of the GPU contexts using standard obj_settings_list help printing.
* mac/vulkan: add support for frame timing via presentation feedbackder richter2024-04-101-0/+7
|
* vulkan: use pl_vk_inst_createKacper Michajłow2024-04-072-39/+39
| | | | | | | | | | | | This change is mostly motivated by missing VK_KHR_portability_enumeration instance extension when enumerating the devices. Which causes issues with MoltenVK which does not advertise full Vulkan conformance. To avoid duplicating code use pl_vk_inst_create() which correctly query availability and enables the mentioned extension. While at it fix the VkInstance leaking in vk_validate_dev().
* mac: cleanup swift bridge header imports and unify themder richter2024-03-291-0/+2
|
* hwdec/vulkan: enable the stable AV1 extensionLynne2024-03-241-2/+1
| | | | | | | As no drivers were ever released with the unstable extension, it's not needed anymore. Not bumping the required headers version yet.
* various: use thread safe mp_strerror()nanahi2024-03-191-1/+2
|
* vulkan: remove color_depth stubllyyr2024-03-191-6/+0
| | | | Needed for the next commit
* mac/vulkan: directly retrieve current render size without cachingder richter2024-03-061-1/+8
| | | | | | the render size cached in ctx->vo->dwidth/dheight can be outdated in some circumstances at the time the context needs resizing. instead use the current render size.
* mac/vulkan: remove old deprecated VK_MVK_macos_surface extension remainsder richter2024-02-292-2/+1
|
* various: avoid function pointer castsKacper Michajłow2024-02-281-2/+1
| | | | | | | | | | | | | The opt validator functions are casted to generic validator, which has erased type for value. Calling function by pointer of different definition is an UB. Avoid that by generating wrapper function that does proper argument type conversion and calls validator function. Type erased functions have mangled type in the name. Fixes UBSAN failures on Clang 17, which enabled fsanitize=function by default.
* osdep/mac: make mac naming of files, folders and function consistentder richter2024-02-281-1/+1
| | | | | rename all macOS namings (osx, macosx, macOS, macos, apple) to mac, to make naming consistent.
* vulkan/context_win: make --alpha work and runtime changeablenanahi2024-02-171-6/+15
| | | | | | If libplacebo manages to create a vulkan swapchain that allows alpha composition mode to be controlled by the DWM API, this makes it runtime changeable.
* wayland: drop buffer_scale use for viewporterDudemanguy2024-01-271-1/+1
| | | | | | | | | | | | | | | | | | | The core wayland protocol way of handling scaling is to use the buffer_scale mechanism. But this sucks in several ways for reasons I won't list here and fractional scaling rightly avoids this altogether and uses a buffer_scale of 1 (i.e. not setting it) along with viewporter. When originally implemented, this was only specifically used when the fractional scale protocol was available, but we actually can use it as a full replacement instead. This means that mpv now hard requires viewporter, but this protocol is supported by everyone and is one of the few that is actually stable. How it works is the same regardless of fractional scaling or not. When the compositor has a scale value not equal to 1, it will always scale the client by that factor (unless you set buffer_scale). What we do here is pass a viewporter size that exactly undos the compositor-side scale (sans a possible rounding error). So what we are left with is just the exactly physical pixels we want to display. Fixes #13316.
* vo: add missing return variable assignmentKacper Michajłow2023-11-181-1/+1
|
* vo_gpu/vo_gpu_next: add vulkan support for macOSder richter2023-10-142-0/+123
| | | | | | | | add support for vulkan through metal and a translation layer like MoltenVK. also add the possibility to use different render timing modes for testing. i still consider this experimental atm.
* vo: change vo->driver->wait_events to nanosecondsDudemanguy2023-10-103-5/+5
| | | | | | | | | | | | In many cases, this is purely cosmetic because poll still only accepts microseconds. There's still a gain here however since pthread_cond_timedwait can take a realtime ts now. Additionally, 37d6604d70c8c594de2817db26356c4c950ac0fd changed the value added to timeout_ms in X11 and Wayland to ensure that it would never be 0 and rounded up. This was both incomplete, several other parts of the player have this same problem like drm, and not really needed. Instead the MPCLAMP is just adjusted to have a min of 1.
* vo: vulkan: allow picking devices by UUIDPhilip Langdale2023-09-041-9/+47
| | | | | | | | | | | | | | | We currently only allow specifying the Vulkan device to use by name. We did this to avoid confusion around devices being enumerated in an unpredictable order. However, there is a valid edge case where a system may contain multiple devices of the same type - which means they will have the same name, and so you can't control which one is used. This change implements picking devices by UUID so that if names don't work, you have some option available. As Vulkan 1.1 is a hard requirement for libplacebo, we can just use UUIDs without conditional checks. Fixes #10898
* vulkan: don't assume all ra_ctx implementations have a swapchainPhilip Langdale2023-06-031-1/+1
| | | | | | | | | | | The dmabuf-wayland vo has a stub ra implementation that doesn't have a swapchain. That means that it's currently not safe to call ra_vk_ctx_get on that ra_ctx, but it must be safe to call on all ra implementations as this is how we discover if it is a vulkan ra. This hasn't been an issue before because no Vulkan code paths would be triggered when using dmabuf-wayland, but with the new vulkan hwdec, it becomes possible to trigger when hwdecs are probed.
* hwdec_vulkan: enable AV1 support if availablePhilip Langdale2023-05-291-0/+2
| | | | | | | | | | | AV1 support in Vulkan is extremely bleeding edge - to the point that the extension is not present in official Khronos releases, but it has a reserved identifier and we can look it up with a string literal for now. This will be skipped and ignored if the driver doesn't support it, so it's safe if/when the name changes later (it'll just never be activated in that case).
* hwdec_vulkan: simplify requirement checks for Vulkan interopPhilip Langdale2023-05-291-12/+8
| | | | | | | | | | | | | I originally wrote this trying to avoid doing an explicit version check on the headers, but it just makes things more confusing, and the requirements harder to understand. So, Vulkan interop now takes a dependency on the header release where they finalised the video decode headers. VK_EXT_descriptor_buffer was added in 1.3.235, so that's covered as well. Along the way I fixed a bug in the waf build where it was depending on libplacebo-next instead of libplacebo-decode.
* vo/vulkan: do not define zero sized arrayKacper Michajłow2023-05-291-4/+2
| | | | It is not needed at all.
* vo: vulkan: request additional extensions and features for ffmpegPhilip Langdale2023-05-281-0/+47
| | | | | | | | | | | | | | | | | Vulkan hwdec interop with the ffmpeg 6.1 vulkan code will require additional features beyond those activated by libplacebo by default. Enabling these features requires both requesting the features' extensions and then explicitly turning on the features. libplacebo handles detecting unsupported features and dropping them, to avoid failing to create the vulkan device. We then leave it to ffmpeg to decide if any missing features are required for functionality, and error out if necessary. As ffmpeg requires at least one bleeding edge extension (descriptor buffers), all of this logic is gated on the presence of sufficiently new Vulkan headers.
* options: remove explicit initialization of integers to 0Christoph Heinrich2023-02-211-5/+1
|
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-211-4/+4
| | | | | | 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.
* x11: remove PresentNotifyMSC from egl/glx/vulkan to fix xpresent timingSultan Alsawaf2023-01-251-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+1
| | | | | | | | | | | | | 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-2/+2
| | | | | | | | | 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.
* 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.
* vulkan: fix build error for 32bit builds with clangChristoph Reiter2023-01-081-1/+1
| | | | | | | | | | | vk->surface is a handle and not a pointer, so assign VK_NULL_HANDLE. This fixes the following build error on 32bit Windows when using clang for example, which errors out when assigning a 32bit pointer to a 64bit integer: ../mpv-0.35.0/video/out/vulkan/utils.c:37:21: error: incompatible pointer to integer conversion assigning to 'VkSurfaceKHR' (aka 'unsigned long long') from 'void *' [-Wint-conversion] vk->surface = NULL; ^ ~~~~
* vo_gpu_next: vulkan: libplacebo: unify log prefixNiklas Haas2022-10-092-4/+1
| | | | | | | | | | | | | | | | | | The new status quo is simple: all messages coming from libplacebo are marked "vo/gpu{-next}/libplacebo", regardless of the backend API (vulkan vs opengl/d3d11). Messages coming from mpv's internal vulkan code will continue to come from "vo/gpu{-next}/vulkan", and messages coming from the vo module itself will be marked "vo/gpu{-next}". This is significantly better than the old status quo of vulkan messages coming from "vo/gpu{-next}/vulkan/libplacebo" whereas opengl/d3d11 messages simply came from "vo/gpu{-next}", even when those messages originated from libplacebo. (It's worth noting that the the destructor for the log is redundant because it's attached to the ctx which is freed on uninit anyway)
* 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.
* vulkan: remove --vulkan-disable-eventsNiklas Haas2022-10-051-3/+1
| | | | | | This has had no effect since libplacebo v4.192.0, and was deprecated upstream a year ago. No deprecation period in mpv is justified by this being a debug / work-around option.
* x11: avoid XPresent API calls when it's not neededDudemanguy2022-06-221-3/+6
| | | | | | | | | | | 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-191-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* x11: avoid wasteful rendering when possibleDudemanguy2022-04-111-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-111-5/+1
| | | | | | | | | | | 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).
* vulkan: correctly inherit proc_addr pointerNiklas Haas2022-03-131-0/+1
| | | | | | As found out by @philipl, failing to pass this from the VkInstance to the VkDevice is bad style. We might want to override the get_proc_addr pointer in the future.
* libplacebo: switch to v4 naming conventionNiklas Haas2022-02-031-4/+4
| | | | | All of these const struct pointers got typedefs, clean up the code accordingly.
* libplacebo: update log helpersNiklas Haas2022-02-034-17/+13
| | | | | Use the pl_log APIs introduced in libplacebo v4, replacing the deprecated pl_context concept.
* vo_gpu: libplacebo: make version logging slightly clearerNiklas Haas2021-11-191-1/+2
| | | | Matches what `pl_log_create` does as well.
* 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
* vo_gpu_next: call start_frame in vulkan/context.cDudemanguy2021-11-041-2/+6
| | | | | | | | | 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.
* vo_gpu: vulkan: expose swapchain to mpvk_ctxNiklas Haas2021-11-032-8/+8
| | | | So I can reuse it in vo_gpu_next.
* vo_gpu: libplacebo: drop conditional code paths for old versionsNiklas Haas2021-10-041-4/+0
| | | | No longer needed with the bump to v3.104.
* wayland: fix wl_surface_set_buffer_scale usageDudemanguy2021-06-271-1/+0
| | | | | | | | | | | The wl_surface lives for the entire lifetime of the vo. It's only neccesary to set the scale initially and when the output scaling changes (the surface moves to a different output with a different scale or the output itself changes it scale). All of the calls that were being made in the egl/vulkan resize functions are not needed. vo_wlshm wasn't correctly rescaling itself before this commit since it had no logic to handle scale changes. This should all be shared, common code in the surface/output listeners.
* wayland: always be sure to initially try to renderDudemanguy2021-06-271-1/+1
| | | | | | | |