| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
The DWM compositor transparency API is runtime changeable.
Handle this in update_render_opts.
|
|
|
|
|
| |
This makes --alpha=yes work with d3d11 and --d3d11-flip=no.
transparent window doesn't work with flip model swapchain by design.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently, libplacebo always tries to reconfigure the d3d11 swapchain
to a 10-bit output format because disable_10bit_sdr isn't set to true,
even when an 8-bit format is explicitly requested via
--d3d11-output-format.
Fix this by passing the requested output format preference to libplacebo.
Document that this option may be ignored.
|
|
|
|
| |
To be able to reuse them in other parts of code.
|
|
|
|
| |
There is nothing d3d11 about those adapters.
|
| |
|
| |
|
|
|
|
|
| |
Both buffers have the same size (32) and if the source is not null
terminated it should be fixed there. Copy whole buffer.
|
| |
|
|
|
|
|
| |
There is no reason to use microseconds precision. We have precise timers
all all relevant platforms.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Filtering globally D3D11_MESSAGE_ID_CREATETEXTURE2D_INVALIDDIMENSIONS is
suboptimal, because can also hide other invalid usages. In the same time
it is not enough, because not only this message is emitted, but also one
about E_INVALIDARG. Just flush queue before and clear messages after to
ignore this part of code.
As a side note, I don't believe this texture size lookup is in fact
useful, but since it is there and is relatively harmless, let's leave
it as is.
|
|
|
|
| |
Found by codespell
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Most sources don't need config.h.
The inclusion only leads to lots of unneeded recompilation if the
configuration is changed.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
As it happens, `SIZE_T` and `size_t` are not the same length on 32-bit Windows
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
A VRAM memory leak was present in d3d11 when `idle=yes` and playback
stops for an item. This patch re-enables some of the code which is
only used during diagnostic which fixes the issue.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This lets us remap various messages which might now be happening at
each frame onto the trace level, thus unaffecting the initial debug
log level.
Additionally - thanks to this ability - the previously globally denied
message queue abandonment messages can now be handled and mapped to
trace log level, as on that log level they may be of use.
Recommended by rossy and based on his libplacebo commit
6d72f6445566eddb0493447d0bda72d98a99d40c .
|
|
|
|
|
|
| |
Instead of always having the reference outside of calling resize,
request a backbuffer at start and relieve the backbuffer at
submission for presentation.
|
|
|
|
|
|
|
| |
Query the description of the swap chain, which should in all theory
contain the format of the backbuffer. Then utilize a newly added
ra_d3d11 function to map the format to an ra_format. After that,
utilize the depth of the first plane of the format, as previously.
|
| |
|
|
|
|
| |
This mostly copies the API used in the GL backend.
|
|
|
|
|
|
|
|
|
|
| |
We don't need to hold on to buffers longer than necessary. Doesn't
matter for vo_gpu but greatly matters for vo_gpu_next, since it persists
hwdec mapped textures for longer periods.
Unfortunately, only provides benefits for hwdecs which do explicit
copies in their decode path, which currently just means cuda and
d3d11va.
|
|
|
|
| |
This enables us to utilize it from gpu-next.
|
|
|
|
|
|
|
|
| |
vo_gpu_next and libplacebo expect swapchain images to be able to be
blitted to, which for libplacebo on FL11_0 and up means they have to
have DXGI_USAGE_UNORDERED_ACCESS, since libplacebo uses a compute shader
to emulate certain kinds of blits. For libplacebo's benefit, set all
applicable usage flags on swapchain images.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today, validation is only possible for string type options. But there's
no particular reason why it needs to be restricted in this way, and
there are potential uses, to allow other options to be validated
without forcing the option to have to reimplement parsing from
scratch.
The first part, simply making the validation function an explicit
field instead of overloading priv is simple enough. But if we only do
that, then the validation function still needs to deal with the raw
pre-parsed string. Instead, we want to allow the value to be parsed
before it is validated. That in turn leads to us having validator
functions that should be type aware. Unfortunately, that means we need
to keep the explicit macro like OPT_STRING_VALIDATE() as a way to
enforce the correct typing of the function. Otherwise, we'd have to
have the validator take a void * and hope the implementation can cast
it correctly.
For help, we don't have this problem, as help doesn't look at the
value.
Then, we turn validators that are really help generators into explicit
help functions and where a validator is help + validation, we split
them into two parts.
I have, however, left functions that need to query information for both
help and validation as single functions to avoid code duplication.
In this change, I have not added an other OPT_FOO_VALIDATE() macros as
they are not needed, but I will add some in a separate change to
illustrate the pattern.
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation of presentation feedback was designed to be
used with flip model presentation. With the bitblt model,
GetFrameStatistics returns totally different values and it's not clear
if we can use them at all. Previously, this wasn't a problem because
with the bitblt model, GetFrameStatistics only worked in exclusive
fullscreen. Now that mpv supports exclusive fullscreen, we should
explicitly check for a flip model swapchain before using presentation
feedback.
|
|
|
|
|
| |
Update the cache whenever we utilize p->opts, as recommended by
wm4.
|
|
|
|
|
| |
Lets the application fully control the rendering onto the screen
instead of the compositor.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with
{"name", ...
followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.
I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.
Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.
Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.
In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default utilizes the color space of the desktop on which the
swap chain is located. If a specific value is defined, it will be
instead be utilized.
Enables configuration of the PQ color space (BT.2020 primaries,
PQ transfer function) for HDR.
Additionally, signals the swap chain color space to the renderer,
so that the render looks correct without having to specify
target-trc or target-prim manually.
Due to all of the APIs being Win10+ only, will only work starting
with Windows 10.
|
|
|
|
|
| |
This flag was added in e2976e662d92, but it was only set for Vulkan. In
D3D11 it can be set from info in D3D11_FEATURE_FORMAT_SUPPORT2.
|
|
|
|
|
|
|
| |
If expected_sync_pc is greater than submit_count, the unsigned
subtraction will wraparound, which breaks playback. This bug was found
while experimenting with bit-blt model present, but it might be possible
to trigger it with the flip model as well, if there was a dropped frame.
|
|
|
|
|
|
| |
This lets users set values such as "intel" or "nvidia" as the
adapter vendor is generally noted in the beginning of the
description string.
|
|
|
|
|
| |
I did ponder if I should have done this right away, and it seems
like not doing it at first was a mistake.
|
|
|
|
|
|
|
| |
Query information on the system output most linked to the swap chain,
and either utilize a user-configured format, or either 8bit
RGBA or 10bit RGB with 2bit alpha depending on the system output's
bit depth.
|
|
|
|
|
| |
And if backbuffer is not around, return an error value utilized
elsewhere already.
|
|
|
|
|
|
|
|
|
|
| |
This affects hwdec_dxva2dxgi, which uses ra_d3d11_wrap_tex to wrap RGB
video frames that are shared with a D3D9 device. Without it, mpv uses
nearest instead of bilinear scaling with --scale=bilinear (the default)
and --hwdec=dxva2. It's kind of hard to believe this bug has gone
unnoticed for almost two years, but that seems to have been the case.
Fixes: #7042
|
|
|
|
| |
Not the prettiest way to get it done, but seems to work.
|
|
|
|
| |
Set it from the adapter name in the d3d11 options.
|
|
|
|
|
| |
This lets the user define an adapter name that can then be passed
further into the internals.
|
|
|
|
| |
In preparation for making vo_drm able to use swapchain-depth
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think I was wrong about having to reset the stats when mpv stops
producing frames, eg. when it's paused. As long as the swapchain doesn't
underflow, last_queue_display_time will still be accurate, because the
next frame produced should still be presented one vsync after the
last one in the swapchain.
If the swapchain underflows (which is the common case for when mpv is
paused for more than 150ms,) the next predicted frame time should be in
the past. It should be fine to leave last_queue_display_time unset in
this case, since vo.c will use the current time instead, which is a
decent guess (though it doesn't take vsync phase into account.)
last_sync_refresh_count and last_sync_qpc_time should be kept on
swapchain underflow as well. Assuming the display refresh rate doesn't
change while mpv is paused, they'll only provide a more accurate guess
of the vsync duration when mpv starts playing again. Also,
vsync_duration_qpc never needs to get reset. It will get overwritten
immediately in most cases, and when it doesn't, it's still a better
guess of the vsync duration than nothing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds vsync reporting to the D3D11 backend using the presentation
feedback provided by DXGI, which is pretty similar to what's provided by
GLX_OML_sync_control in the GLX backend. In DirectX, PresentCount is the
SBC, PresentRefreshCount and SyncRefreshCount are kind of like the MSC
and SyncQPCTime is the UST.
Unlike GLX, the DXGI API makes it possible for PresentCount and
SyncQPCTime to refer to different physical vsyncs, in which case
PresentRefreshCount and SyncRefreshCount will be different. The code
supports this possibility, even though it's not clear whether it can
happen when using flip-model presentation. The docs say for flip-model
apps, PresentRefreshCount is equal to SyncRefreshCount "when the app
presents on every vsync," but on my hardware, they're always equal, even
when mpv misses a vsync. They can definitely be different in exclusive
fullscreen bitblt mode, though, which mpv doesn't support now, but might
support in future.
Another difference to GLX is that, at least on my hardware,
PresentRefreshCount and SyncRefreshCount always refer to the last
physical vsync on which mpv presented a frame, but glxGetSyncValues can
apparently return a MSC and UST from the most recent physical vsync,
even if mpv didn't present a new frame on it. This might result in
different behaviour between the two backends after dropped frames or
brief pauses.
Also note, the docs for the DXGI presentation feedback APIs are pretty
awful, even by Microsoft standards. In particular the docs for
DXGI_FRAME_STATISTICS are misleading (PresentCount really is the number
of times Present() has been called for that frame, not "the running
total count of times that an image was presented to the monitor since
the computer booted.")
For good documentation, try these:
https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-flip-model
https://docs.microsoft.com/en-us/windows/win32/direct3d9/d3dpresentstats
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/d3dkmthk/ns-d3dkmthk-_d3dkmt_present_stats
(Yeah, the docs for the D3D9Ex and even the kernel-mode version of this
structure are better than the DXGI ones. It seems possible that they're
all rewordings of the same internal Microsoft docs, but whoever wrote
the DXGI one didn't really understand it.)
|
|
|
|
| |
'ctx->ra' is null pointer when d3d11 init failed before call 'ra_d3d11_create' in 'd3d11_init'.
|
|
|
|
| |
'ctx11' be not release when d3d11 hwdec be uninit with 'mapper_uninit' method.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Somehow I got the idea that compound literals had function-scoped
lifetime. Instead, like all other objects with automatic storage
duration, compound literals are block-scoped, so they become invalid
after exiting the block they were declared in. It seems like a recent
change to GCC actually reuses the memory that the compound literals
used to occupy, which was causing a few bugs.
The pattern of conditionally assigning a pointer to a compound literal
was used in a few places in ra_d3d11 where the Direct3D API expects
either a pointer to an initialised struct or NULL. Change these to
ensure the lifetime of the struct includes the API call.
Should fix #6775.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While `ra` supports the concept of a texture as a storage
destination, it does not support the concept of a texture format
being usable for a storage texture. This can lead to us attempting
to create a texture from an incompatible format, with undefined
results.
So, let's introduce an explicit format flag for storage and use
it. In `ra_pl` we can simply reflect the `storable` flag. For
GL and D3D, we'll need to write some new code to do the compatibility
checks. I'm not going to do it here because it's not a regression;
we were already implicitly assuming all formats were storable.
Fixes #6657
|