This causes regressions with latest versions of vulkan-headers,
including GPU hangs and shader execution errors.

Disable it for the time being, until the upstream issues have been
resolved.

Kacper Michajłow authored 2 years ago and Niklas Haas committed 2 years ago

This change enables libplacebo to work in the WSL2 (WSLg) environment
where OpenGL is implemented on top of D3D12.

This reverts commit https://github.com/mpv-player/mpv/commit/149d98d24495550f7ee1e187225e2924b1b90024

Mentioned OpenGL implementation (GDI Generic) in the original change
will be rejected by version check, so there is no need to handle it
manually.

See-Also: https://github.com/mpv-player/mpv/pull/11061


Signed-off-by: Kacper Michajłow <kasper93@gmail.com>

Thomas Weißschuh authored 2 years ago and Niklas Haas committed 2 years ago

Remove unnecessry allocation of `render_pass.tmp`.

When commit [0] added this reallocation of render_pass.tmp for reuse of
the struct it was still necessary to do so.
Down the line `pass_init()` was introduced which also allocates the
field tmp.
The object presiously pointed to by this field was not freed however,
leading to a memory leak of 32 bytes everytime the reallocation was
executed.

Remove the explicit allocation to fix the leak.

[0] eeed2d7f ("renderer: fix several bugs related to pl_render_image reuse")

No longer relevant.

Instead of highlighting after 0.5% of peak delta, highlight at a very
generous threshold (1e-6). To counteract the negative effects of
transforming a bunch of slightly-out-of-gamut dark pixels into bright
pink, change the highlighting algorithm to simply rotate the hue vector
by 180°

This should be strictly more noticeable than the previous while also
allowing you to still see what's being highlighted, as an added benefit.

Fixes: #239

This logic regressed sometime in the move from mpv vo_gpu to libplacebo.

Fixes: https://github.com/mpv-player/mpv/issues/11036
See-Also: https://github.com/mpv-player/mpv/issues/4631

This is redundant with the switch coverage check, fails to capture the
intended logic correctly (due to `ded_image` also linking something into
`pNext`), and causes inexplicable issues when compiling under certain
versions of clang.

Fixes: #238

AV1 only allows up to 12-bit depth out of the box, but we want to handle
the case of already up-converted input files. This should fix triggering
a `pl_assert` on input files with a bit depth above 12, by constraining
the logical bit depth.

Simple wrong check. PL_CHANNEL_NONE is not 0.

Fixes: https://github.com/mpv-player/mpv/issues/10239
Fixes: https://github.com/mpv-player/mpv/issues/10903

The current desaturation function extends linearly to infinity,
resulting in very bad behavior for extreme HDR->SDR ratios (e.g. 49:1).
Replace it by a logarithmic map to smooth this out more naturally at an
asymptote.

This is more or less what the original code was intending, I think.

Fixes: 73785267

The desaturation code was seemingly completely wrong. I have no idea
what it was even doing, but it's clear that whatever the intent was, it
was not working correctly in practice.

Fixes: https://github.com/mpv-player/mpv/issues/10844

This branch was meant to be simplified by the introduction of the common
scale factor defined above, but somehow forgotten about.

Since these are almost always a bug we want users to be aware about, due
to triggering other format selection errors.

These are definitely expected to change per-frame. Suppress the LUT
reinitialization warning, which is normally there to warn us about LUTs
not being cached properly.

The old code was written around the assumption that the film grain step
is always the first step being executed. This is no longer the case, as
of 67f8fe5d, causing a regression.

Fixes: https://github.com/mpv-player/mpv/issues/10854

Prevents pl_shader_obj from getting freed before any allocated shaders
are done using them.

Closes: #232

Brad Smith authored 2 years ago and Niklas Haas committed 2 years ago

As mentioned in https://github.com/haasn/libplacebo/issues/147 there is a
better way of doing this with newer Meson, but for a greater level of
backwards compatibility just use the same style as is already there.

No need to parse this off the start beacuse we strip the line
immediately afterwards anyway. Change it for consistency with the other
parsers. There's an argument to be had on whether or not this is
intended behavior, as it allows mis-parsing something like
"//!DESCRIPTION" as "//!DESC RIPTION", but oh well.

It's read-only.

Such as the newly introduced AV_PIX_FMT_RGBF32LE.

The change from PL_SHADER_SIG_NONE to PL_SHADER_SIG_COLOR was erroneous.

See-Also: https://github.com/mpv-player/mpv/issues/10246

The way the logic was implemented in libplacebo, we resolve the output
dimensions and generate the fbo first. But for compatibility with mpv,
we need to silently ignore shaders that reference unknown binds. This
requires re-ordering the code to resolve binds before the output
dimensions.

Fixes: https://github.com/mpv-player/mpv/issues/10246

This can leak if we `goto error` from a context in which a shader is in
construction.

This should alias to MAINPRESUB, but it didn't

Rafael Ristovski authored 2 years ago and Niklas Haas committed 2 years ago

This is required to get hardware decoding, which needs
EGL_EXT_image_dma_buf_import / EGL_MESA_image_dma_buf_export to work.

For synthetic/test profiles which are so weird that black doesn't even
map to a positive luminance number, this code results in NaNs. Guard
against it by forcibly clamping black to 0.

These can apparently happen on some profiles containing very badly
behaving data, so better play it safe and avoid propagating NaNs out of
this function.

In theory we should never see NaNs, but a good idea to preserve this
check just in case.

Instead of hard-failing.

See-Also: https://github.com/mpv-player/mpv/issues/10814

This is technically undefined behavior otherwise, at least until there's
an official resolution upstream. So, use this as safety precaution for
now. In theory this should be a no-op because we already emit
`vk_wait_idle` before that point.

See-Also: https://github.com/KhronosGroup/Vulkan-Docs/issues/1678
See-Also: https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/4733

The current logic still failed when confronted with subpixel offsets.
There's an easy and a hard way to fix this properly - the hard way is to
round the dimensions to explicit integer pixels and then adjust the src2
rect to compensate.

The easy way is to just completely skip scaling in the first direction
by brute-forcing this to the texture dimensions.

I'll choose the easy way.

Direct float comparison against 1.0 was a terrible idea. I have no idea
how this survived my tests up to this point, but it definitely breaks
sporadically in some cases.

Otherwise, this introduces unwanted one-pixel scaling (and/or trips the
ortho2 bidirectional scaling detection logic).

Investigating a bug with broken yuv422 scaling on a cropped texture made
me conclude that this API is fundamentally broken. We cannot discard the
unused component from inside this function without knowing what the
source crop was. We need it to be less magic and to move responsibility
onto the API user.

Since this is a significant break in API, rename it to
`pl_shader_sample_ortho2` and preserve the original name for backwards
compatibility. Annoying, but necessary, because otherwise this regresses
current users of `pl_shader_sample_ortho` (e.g. vs-placebo).

The logic in `vk_buf_flush` treates buffers imported from
PL_HANDLE_HOST_PTR identically to `host_mapped` buffers, but this
assumption is only true if we assume that the host pointers were
imported to a host-visible memory type. This is not always the case.

Relax the restriction to only require invalidating mapped memory if the
memory is actually mapped.

Fixes: https://github.com/haasn/libplacebo/issues/146

Pulls in a bug fix for building on some platforms we transitively care
about.

Doing this too early doesn't undefined it before the symbol is defined.

Otherwise, gl->MemoryBarrier expands to something that the CPP expects
to be a macro invocation. Oops.

No need to use these to join strings, since it's just shorthand for '/'

3rdparty/Vulkan-Headers might exist, but be empty.