H.274 currently requires CS support, so test for it first.

No reason to export 1 compute queue if we don't even have compute
shaders..

On systems where all channel queries are returned  with a depth of 0.
I'm not entirely sure if this is even legal for a driver to do, but in
any case, it's best not to do UB in this case. (Array out of bounds
read)

This holds on to the frame for a shorter duration, allowing it to
interop more easily with e.g. libavcodec filters. Note that this still
isn't thread safe (cf. pending upstream FFmpeg changes), but a necessary
step in that direction one way or the other.

This is particularly designed for hardware decoding and such, as well as
interop with e.g. lavfi vulkan. In either case, we don't want to
permanently consider frames mapped for the entire duration that they may
stick around in e.g. pl_queue, but rather dynamically acquire/release
them immediately surrounding the actual usage site.

This implementation is also designed to guarantee that only one frame
will ever be acquired at a time, which allows us to support some hwdecs
without requiring multiple mappers.

Fixes videolan/libplacebo#194

A bit ugly logic-wise but better for future extensibility, specifically
because I plan on using `pass_init` to e.g. acquire potentially-unmapped
frames.

This is conceptually not really a frame drawing pass, but a blend pass
(with 0 frames to be blended).

Makes this logic easier to extend in the future, and crucially also
provides a common place to do uninit code from.

Designed to match the endpoints provided by libavutil. Needed for safe
multi-threading in general, but especially when interoperating with
other API users (e.g. vulkan hwdec)

Closes videolan/libplacebo#196

See upstream.

I wanted to change the way this is handled such that shaders also get
printed when being re-loaded from the cache. Rather than re-adding the
same code to all three GPU instances, I decided it makes more sense to
just move it to the common helper code.

This does unfortunately re-order most shader debug messages such that
the errors get printed _above_ the re-print of the source code (on
errors), but this was the status quo anyways for vulkan. I can live with
it.

Closes #192

Looking at this API again, it really makes no sense to leave the
"non-unique" queues unset. Users can trivially recover a check for this
condition by just doing an equality test on the queues.

Testing for single family vs multi-family can also be done trivially by
testing for `pl_vulkan.num_queues`.

And lastly, API users (FFmpeg etc.) actually need all queues to be set.
So pre-setting them to the correctly defaulted values is actually
hugely useful.

Since we're setting all queues anyway, might as well also set them
unconditionally in the internal structs. Rewrite the queue family
selection code to make it cleaner overall.

This wasn't set at all. Oops. Also move the shared code between
pl_vulkan_create and pl_vulkan_import into a common helper, where it
should have been all this time.

I have no idea why it wasn't. Somebody shoot the author of this code.

I hate MSAN sometimes. This should at least be a permanent solution to
the issue.

This should not be exactly 0.5, but a value slightly higher than 0.5
(depending on the image bit depth).

It's possible that we should go with the mpv approach of just setting
the chroma channels to 0 altogether for grayscale formats. But that
would require some sort of API change, which I'm unwilling to do as part
of this commit.

The 0.5 constant for floating point YCbCr is almost surely not actually
correct, but that preserves the status quo. cf. #155

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

It's sometimes more convenient to get coredumps instead of plain stack
traces, especially if you didn't have gdb attached to the process at the
time.

Note that, asymmetrically, we add pl_debug_abort() to the vulkan debug
callbacks but not the opengl debug callbacks. This is motivated by
vulkan debug errors mainly corresponding to API usage violations (should
never happen!), whereas OpenGL debug errors mainly correspond to runtime
errors (e.g. invalid GLSL files), which should not trigger an abort().

(Note that you can also `(gdb) break pl_log_stack_trace`)

Older GLSL can't auto-promote 0xFF to 0xFFu. Sigh.

Instead of wasting 3 whole 32-bit integers on this (which probably
becomes 4 integers), pack them into a single 32-bit integer.

Probably doesn't matter much, but hey, it's better, right?

The ITU-R H.274 spec specifies what values to infer when the
num_model_values is lower than the required number of components.

As an aside, we also never correctly adapted the model values for
chroma planes. We also still don't correctly adapt them for subsampled
planes, but that is a problem for a future commit.

Lastly, the current behavior technically breaks on negative scale values
(which underflow to huge unsigned int values). Fix this by switching
from uvec to ivec.

Fixes #187

So, these flat out just don't work. Mesa supports DRM modifiers these
days, so the only driver this is useful for is AMDVLK. And I'd rather
AMD just update their driver to support DRM modifiers, than having to
play driver guesswork with trying to figure out the right set of
parameters to pass it.

I'm pretty sure that the validation layers will give us hell regardless
of what we do, since using DRM textures without proper modifiers results
in violating all sorts of offset-related invariants one way or the
other. And simply disabling it also doesn't work, we get visibly corrupt
output.

Oh well. Closes #186

This code had several bugs in one:

1. It was looking at `repr`, when it should have been looking at
   `target->repr` as `repr` got normalized previously.
2. It was looking at `sample_depth` when it should have been looking at
   `color_depth`.
3. It was using `depth <= 16` even though the documentation claims that
   we only dither to below-16 bit FBOs.

No idea what was wrong with this, but it wasn't producing the expected
results at all. Rewrote it from the ground up to be correct, before
simplifying the math to get it as close as possible to the previous
state again.

Can probably be simplified further, but this doesn't need to be
super-optimized anyway.

Fixes #185

mpv introduced the = and % operators in 1d0349d3b. I personally disagree
with the implementation of = as `==`, and decided to instead use a fuzzy
equality test.

The convention throughout the rest of the code is to multiply ratios,
not divide them. Also simplifies the computation.

This failed to catch a real bug, because the check overflowed back to a
legal value.

This is a much cleaner way of handling flipped rendering on e.g. OpenGL,
requiring less intervention from the user side.

In addition, this can also be used to support planes with negative
stride. I may even revisit the type of `pl_plane_data.row_stride` to
support ptrdiff_t, but for now, I want to avoid breaking the API more.
(And the buffer path requires special handling from the user anyway)

It's worth pointing out that this implementation has a tiny
suboptimality: since plane flipping is only done as part of plane
scaling, this means it can't be merged with the debanding shader. Fixing
that would require a slight rewrite of the code involved, but I don't
really care to do it at the moment.

Lastly, also fix the libav/dav1d helpers to respect negative strides.

Closes videolan/libplacebo#183

Instead of calculating wbase by hard-coding a dependency on the pos_map
function, communicate the appropriate `base` from the per-pixel
calculated values of the correct shader invocation.

Compute the correct shader invocation based whether or not the src rect
is flipped, thus allowing this shader to work properly with flipped
rects.

Removes both of the current fast path restrictions, allowing the compute
shader to work with flipped rects and even the sampler2D interface.

PL_GAMUT_DARKEN had a lot of undesirable side effects. It's not a good
way of fixing this problem, and definitely not something we should hoist
on users by default if "HDR is too dark" is already the persistent
complaint around HDR.

Clipping is probably the most conservative default. It doesn't introduce
the weird white-ish hue shifts that people complain about with regards
to DESATURATE. It's also the closest to what users expect from naive
implementations.

Not bumping the API version for this because it doesn't change the
API/ABI, even though it affects the public header.

Hard-coded to hable for now. Ideally, users should be using a proper
state object here. But this is way better than the current status quo of
basically "breaking" (the NULL gets ignored, so the tone mapping
function somehow ends up being a simple sqrt() function, which in a
hilarious twist of fate actually doesn't look _too_ awful)

Ideally it would be nice to have more pure GLSL fallbacks for common
functions. But it's also worth noting that e.g. the LUT-based hable uses
BT.1886 BPC (instead of linear stretching), making it technically
distinct.

Fixes #184

This was supposed to be part of the previous commit, but I forgot to
update the remote branch before merging. My bad.

Instead of forcing per-image overlays to be rendered at image
resolution, allow them to be specified with respect to whatever
reference frame the user wants.

Additionally, stop rendering overlays directly onto image frames (even
at image resolution), and instead render them onto the final image. This
solves various bugs caused by overlays being blended directly onto
images that are being processed by hooks, at the cost of reducing
overlay scaling to bilinear quality.

Add some common.c boilerplate to support the new logic.

pl_rotation_matrix never made it into any public code.

Without this change, uploading e.g. an rgb8 image to an rgba8 texture
causes the alpha channel to end up as 0, which is definitely not the
intended result (sampling back from this texture should be identical to
sampling from a true rgb8 texture).

This implies moving the fbofmt decision-making from the pl_renderer
creation time to the pl_render_params, which means it gets re-inferred
per frame. Moves some decision making logic around slightly.

Closes #182

Print out the VkCommandBuffer address, and also give it (and the fence)
a debug tag corresponding to the function that caused its allocation.

These used to be relevant in the past, but past refactors have gradually
loosened up these restrictions to the point where it's no longer
necessary to check anything at all. Even in the case that it would be
necessary, the `pl_tex_upload` call itself would be responsible for
appropriate error checking, so asserting here is always wrong.

Retroactively add a short description of all previous API changes, for
quick reference. Reverse the order to put new entries at the top.

Zhao Zhili authored 3 years ago and Niklas Haas committed 3 years ago

To force linking time api check.