This change adds some smarter logic than the dumb per-channel clip. We
first get rid of negative (e.g. super-red) components by mixing in
enough gray until the result is no longer oversaturated, and then we
linearly scale all components down to get rid of too-bright values.

I experimented briefly with using e.g. BT.2390 tone-mapping instead of a
linear scale for the second step, but the results were not significantly
better enough to justify the performance hit of BT.2390.

I tested this by inspecting the resulting gamut-clipped values on a Yxy
chromaticity diagram and confirmed that the resulting color was indeed
at the same angle (relative to the white point) as the original, but
contained within the gamut (with Y preserved).

Subjective comparisons using a wide gamut monitor between the original
(unclipped) source and the clipped BT.709 versions of various test clips
seem visually pleasing, so I enabled it by default.

Fixes #101

For consistency with other functions, and in case we ever do end up
re-using pl_shader_tone_map multiple times within the shader (e.g. for
soft gamut mapping).

The API change referenced in 52305682 was introduced in between patch
level 3743 and patch level 3763. The current check breaks the tagged
release 8.13.3743 which does not include the change yet.

Bump the check up to 3763 to get around this. In classic glslang style,
this means that there are a few commits which will always fail to
compile no matter what we do... but that's the reality we have to live
with when building against glslang. It's either that or they figure out
how to bump their patch level on breaking API changes.

Seems like I completely forgot about this function. Implement and test
it. Also bump the API version, not just because the signature changed,
but also because this is effectively the first version to actually
introduce the function - it's as though it didn't exist prior.

I realized that for the purposes of e.g. `pl_shader_detect_peak`,
dispatching it as a compute shader while ignoring its output can be
useful. Based on this shader alone, there's no reason to force compute
shaders to have no output.

Not bumping the API version for this because it doesn't represent any
change in the signature, and only enables extra semantics that are
currently useless anyway. (The next commit will fix that)

This function can be used to copy bytes from one buffer to another,
which may be helpful in the case of e.g. needing to read-back from a
device-local shader storage buffer.

I didn't like the confusing way random pl_buf_* commands either required
host synchronization or didn't. This change makes thins uniform by
making it so that synchronization is *only* required for "external"
access to buffers (e.g. host-mapped buffers or external API interop).

In the vulkan implementation of these semantics, we expand the
`buf_barrier` mechanism to keep track of writes separately, so that we
don't unnecessary block simply due to reading from a buffer twice.
(Although in theory we could make pl_buf_write non-blocking by always
queueing a command buffer write even for host-mapped buffers.)

For OpenGL, we switch to just always using the GL commands, which should
be doing the equivalent internally already.

Turns out with the way this is implemented there is effectively no need
for the multiple-of-4 restriction, since the actual access to the buffer
is via the host. So drop that requirement.

Not bumping the API version because it's such a minor change in
functionality.

Using the ReadWithoutFormat/WriteWithoutFormat device features. This
suppresses the annoying "Storable format has no matching format
qualifier" warning spam, and makes it a proper warning.

Technically an API break but I decided it's not major enough to bump the
API version, because it's sort of a strict upgrade, and I don't think
this API has any users besides mpv (which handles it correctly already).

See #87 for a
discussion of why.

Upon re-consideration I've determined that I'm not comfortable exposing
`pl_tex_poll` because I still fail to see a sane use case for this. The
only reasonable scenario is when using it together with `pl_tex_export`,
but that function already requires synchronization using semaphores.

I'd have to change the signature to make the `sync` optional, but I'm
not comfortable doing this without a good motivating example, because I
think omitting the `sync` and using CPU-based waits is a last resort.
(And that said, it would have to be done in both directions or risk UB)

For some reason this was done using a lazy destructor even though the
whole point of refcounting is to let commands hold on to a reference of
the buffer while it's in use. No need for the extra laziness, so just
directly deref buffers on pl_buf_destroy.

Rather than the first compatible surface format, we pick the surface
with the highest score. That means: The highest total bit depth, the
best format (UNORM > SNORM > FLOAT > *), and, depending on user
preference, HDR > SDR (or vice versa).

I should really stop doing this.

We sort of hackily recreate the concept of a program cache containing a
cache for multiple shaders, because of the way the `pl_pass` program
cache works.

In theory this is somewhat redundant with the existing concept of e.g. a
VkShaderModule, but we do things this way because it allows us to also
save other resources related to programs, for example the cached SPIR-V
(and also allows us to work with APIs that only cache programs on a
per-program basis)

We also expose this to the `pl_renderer` API.

Closes #99

This was left over from a development version, but the actual logic was
to use the existence of `pass->pass` as a way to check if the pass is
failed or not.

Also, one of the checks was actually referencing this unused field.

This is more in theme with the rest of the libplacebo code.

I decided the current semantics of this struct don't really make sense.
There's no point in forcing _every_ user to constantly be setting unique
signatures. Most users don't care, and in particular, I've made the same
mistake in my own code more often than not.

Furthermore, it's incredibly disingenuous to imply that libplacebo
caches images to speed up redraws when it effectively does not. I'm not
even sure if I think this is a good thing. It's probably a better idea
for the user to do this, because they're the only ones that have a clear
understanding of which frames will be redraws and which will not.

The bottom line is, I've decided that pl_render_image does not and
should not need to cache. So remove all references to the frame cache.

Fixes #96 by
making it clear to API users that such invocations are not supported by
the API. (Probably doesn't fix the actual bug there, but that seems to
be downstream)

There were some FIXMEs that needed addressing.

VK_ is the vulkan namespace, so we shouldn't introduce upon it.

Using GL_ARB_timer_query and GL_TIME_ELAPSED, which matches the
semantics of pl_timer almost exactly identically.

The current memory barriers were either used illegally
(tex_gl->target??), overspecified (e.g. the forced barrier after
glDispatchCompute), or just plain missing (e.g. barriers for storage
images that might also be used in other ways).

Fix this mess by making the barrier usage consistent:
1. Only submit memory barriers on descriptors when unbinding them from
   shaders that might write to the resource
2. Skip unnecessary memory barriers for readonly resources
3. Submit *all* the barriers required for the object's usage flags

We consider all descriptors to be 'restrict'-qualified, because there
just plain is no use case we have for aliasing different descriptors.
Readonly/writeonly is alreayd handled by the descriptor access mode, so
no need to duplicate those memory qualifiers either.

The only ones left are 'coherent', which is required for the peak
detection shader's memory barriers to work, and 'volatile', which we
don't use. Might have a use for it in the future though, especially for
development purposes.

Slight performance gain for compute shaders (especially AV1 grain), but
more importantly, fixes a bug.

This warns about the cast from anonymous enum to named enum, so use a
preprocessor symbol for them instead.

This was done using one scale, but it should have been done with a
separate scale factor for the width and height.

Suggested by @jojo61

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

Instead, implement a fallback path.

GLES 2.0 doesn't allow querying the default framebuffer like this.

We request the pbuffer surface type anyway, so might as well actually
create a pbuffer surface and test the swapchain, right?

Make it point at the actual HTML coverage report.

Use `expose_as` to link to the HTML report, and also attach the xml as a
cobertura artifact

Turns out:
1) utils_gen.py works on both py3 and py2,
2) meson can only use py3 anyway

This commit should guarantee it exists.

I'm not entirely convinced this is sane or needed, and that this isn't a
meson bug, but whatever, it's an easy work-around to carry in order to
solve a very real bug.

Fixes #97

This style of matching elements based on tag contents was introduced in
python3.7, breaking builds for some users stuck with older python
versions. Fix it by simply turning the xpath expression into a manual
loop/check.

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

xmfile -> xmlfile

Users complained about being confronted with a python stack trace. So
just catch the failure and give a better error message to more clearly
communicate to the user what must be done.

Fixes #93

Hard-code some common alternative locations to the vulkan XML, and
improve the error message otherwise.

Fixes https://github.com/haasn/libplacebo/issues/75
Fixes videolan/libplacebo#95

This allows us to accept sampler types other than sampler2D. In
principle, any sampler type is supported, but due to shaders/sampling
being the only user of this API, we can restrict ourselves to only 2D
samplers in the implementation. Notably, though, we also support e.g.
PL_SAMPLER_RECT.

VLC needs this in order to integrate the pl_opengl abstraction into
their OpenGL-based video output module.

Closes #91