| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
It is not needed at all.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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;
^ ~~~~
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
All of these const struct pointers got typedefs, clean up the code
accordingly.
|
| |
|
|
|
| |
Use the pl_log APIs introduced in libplacebo v4, replacing the
deprecated pl_context concept.
|
| |
|
|
| |
Matches what `pl_log_create` does as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
So I can reuse it in vo_gpu_next.
|
| |
|
|
| |
No longer needed with the bump to v3.104.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A subtle regression from c26d833. On sway if mpv was set to be a
floating window in the config, set_buffer_scale would actually get
applied twice according to the wayland log. That meant a 1920x1080
window would appear as a 960x540 window if the scale of the wl_output
was set to 2. This only affected egl on sway (didn't occur on weston and
was too lazy to try anything else; probably they were fine). Since
wl->render is initially false, that meant that the very first run
through the render loop returns false. This probably caused something
weird to happen with the set_buffer_scale calls (the egl window gets
created and everything but mpv doesn't write to it just yet) which makes
the set_buffer_scale call happen an extra time. Since it was always
intended for mpv to initally render, this is worth fixing. Just chnage
wl->render to wl->hidden (again) and flip the bools around. That way,
the initial false value results in render == true and mpv tries to draw
on the first pass. This fixes the weird scaling behavior because
reasons.
|
| |
|
|
| |
Presentation time only lives in in wayland_common.
|
| |
|
|
|
|
|
| |
Mostly a cosmetic change that (hopefully) makes things look better. Some
functions and structs that were previously being exported in the wayland
header were made static to the wayland_common.c file (these shouldn't be
accessed by anyone else).
|
| |
|
|
|
|
|
|
| |
If a plane is not connected to any displays, we won't set an entry in
the mapping of planes to displays. So ensure these unset entries are
null and skip them.
Fixes #8913
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the Vulkan equivalent of the drm context for OpenGL, with
the big difference that it's implemented purely in terms of Vulkan
calls and doesn't actually require drm or kms.
The basic idea is to identify a display, mode, and plane on a device,
and then create a display backed surface for the swapchain. In theory,
past that point, everything is the same, and this is in fact the case
on Intel hardware. I can get a video playing on a vt.
On nvidia, naturally, things don't work that way. Instead, nvidia only
implemented the extension for scenarios where a VR application is
stealing a display from a running window system, and not for
standalone scenarios. With additional code, I've got this scenario to
work but that's a separate incremental change.
Other people have tested on AMD, and report roughly the same behaviour
as on Intel.
Note, that in this change, the VT will not be correctly restored after
qutting. The only way to restore the VT is to introduce some drm
specific code which I will illustrate in a separate change.
|
| |
|
|
|
|
|
|
|
|
|
| |
The VkDisplayKHR context type requires making calls against the
physical device before the libplacebo context is initialised.
That means we can't simply use the physical device object that
libplacebo would create - instead we have to create a separate one,
but make sure it's referring to the same physical device.
To that end, we need the device name that the user may have requested
so we can pass it on.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Take two. f4e89dd went wrong by moving vo_wayland_wait_frame before
start_frame was called. Whether or not this matters depends on the
compositor, but some weird things can happen. Basically, it's a
scheduling issue. vo_wayland_wait_frame queues all events and sends them
to the server to process (with no blocking if presentation time is
available). If mpv changes state while rendering (and this function is
called before every frame is drawn), then that event also gets
dispatched and sent to the compositor. This, in some cases, can cause
some funny behavior because the next frame gets attached to the surface
while the old buffer is getting released. It's safer to call this
function after the swap already happens and well before mpv calls its
next draw. There's no weird scheduling of events, and the compositor log
is more normal.
The second part of this is to fix some stuttering issues. This is mostly
just conjecture, but probably what was happening was this thing called
"composition". The easiest way to see this is to play a video on the
default audio sync mode (probably easiest to see on a typical 23.976
video). Have that in a window and float it over firefox (floating
windows are bloat on a tiling wm anyway). Then in firefox, do some short
bursts of smooth scrolling (likely uses egl). Some stutter in video
rendering could be observed, particularly in panning shots.
Compositors are supposed to prevent tearing so what likely was happening
was that the compositor was simply holding the buffer a wee bit longer
to make sure it happened in sync with the smooth scrolling. Because the
mpv code waits precisely on presentation time, the loop would timeout on
occasion instead of receiving the frame callback. This would then lead
to a skipped frame when rendering and thus causing stuttering.
The fix is simple: just only count consecutive timeouts as not receiving
frame callback. If a compositor holds the mpv buffer slightly longer to
avoid tearing, then we will definitely receive frame callback on the
next round of the render loop. This logic also appears to be sound for
plasma (funfact: Plasma always returns frame callback even when the
window is hidden. Not sure what's up with that, but luckily it doesn't
matter to us.), so get rid of the goofy 1/vblank_time thing and just
keep it a simple > 1 check.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is actually a very nice simplification that should have been
thought of years ago (sue me). In a nutshell, the story with the
wayland code is that the frame callback and swap buffer behavior doesn't
fit very well with mpv's rendering loop. It's been refactored/changed
quite a few times over the years and works well enough but things could
be better. The current iteration works with an external swapchain to
check if we have frame callback before deciding whether or not to
render. This logic was implemented in both egl and vulkan.
This does have its warts however. There's some hidden state detection
logic which works but is kind of ugly. Since wayland doesn't allow
clients to know if they are actually visible (questionable but
whatever), you can just reasonably assume that if a bunch of callbacks
are missed in a row, you're probably not visible. That's fine, but it is
indeed less than ideal since the threshold is basically entirely
arbitrary and mpv does do a few wasteful renders before it decides that
the window is actually hidden.
The biggest urk in the vo_wayland_wait_frame is the use of
wl_display_roundtrip. Wayland developers would probably be offended by
the way mpv abuses that function, but essentially it was a way to have
semi-blocking behavior needed for display-resample to work. Since the
swap interval must be 0 on wayland (otherwise it will block the entire
player's rendering loop), we need some other way to wait on vsync. The
idea here was to dispatch and poll a bunch of wayland events, wait (with
a timeout) until we get frame callback, and then wait for the compositor
to process it. That pretty much perfectly waits on vsync and lets us
keep all the good timings and all that jazz that we want for mpv. The
problem is that wl_display_roundtrip is conceptually a bad function. It
can internally call wl_display_dispatch which in certain instances,
empty event queue, will block forever. Now strictly speaking, this
probably will never, ever happen (once I was able to to trigger it by
hardcoding an error into a compositor), but ideally
vo_wayland_wait_frame should never infinitely block and stall the
player. Unfortunately, removing that function always lead to problems
with timings and unsteady vsync intervals |
