This reverts commit 52c21bbc.

This reverts commit adab9b76.

Forgot to actually mark them as dedicated, which led to them never
getting cleaned up.

We already have logic to pre-cache swapchain frames, so it's trivial for
us to fetch the first swapchain image and hold it in place. As a plus,
this way we can make sure it actually works, and return NULL if it
doesn't.

Just use some dirty hacks to signal the VkSemaphore, for lack of any
actual external API usage here.

Edge case that can arise in the test suite.

This is similar to the old vulkan hold/release_external but more
generalized and more powerful. It also cleans up some of the semantics
related to external image interop. To avoid headaches, just delete the
old vulkan interop code in the same commit.

To make sure we don't keep around references to destroyed sync objects,
we refcount them. (This also means we don't need a lazy destructor,
since a sync object that's not in use can be destroyed immediately -
whereas a sync object that's in use will only be deref'd when the cmd
callback fires)

These must eventually be ref-counted once we start using them to
synchronize access to actual GPU resources.

This change introduces the generic definition of an exported semaphore
pair. Such a pair can be imported by an external API for signalling and
waiting, and will be passable to _hold() and _release() methods once
those get introduced.

Semaphores for internal use should just be created directly.

When we introduce exportable semaphores, we'll have handles which are
not memory-backed. To avoid a sloppy API, let's explicitly separate the
two ideas. This also presents an opportunity to pull the object offset
within the memory into the mem_handle definition. We also refactor the
way the handle caps are presented to the user, to allow distinguishing
between caps for shared memory and those for semaphores.

We also turn the struct pl_gpu_handle into a union, since in practice,
it is not going to be useful to export a given resource as multiple
types of external handle - it will just one or another type. (This is
mostly a simple substitution, but we must also note that vk_slabs must
also carry the handle type explicitly, as we can no longer look at which
field(s) are set in a pl_gpu_handle.)

This is obviously an API break for any external usage of buffers or
textures.

I missed this assertion when I added support for exportable textures.

Forgot this one in the previous commit.

I'm not 100% sure that this is guaranteed to be a power of two - and
even if it is currently, it may not be after some unlucky refactor in
the future. Just do the safe thing and waste the 1 CPU cycle in order to
avoid blowing up under unforeseen circumstances.

This mirrors a similar change in mpv, which helped reduce vsync jitter
measurements by including the time of frame acquisition in the
`swap_buffers` call. In general, doing things this way around is nicer
for the user. In typical swapchain implementations, it also "does the
right thing" w.r.t actually blocking until the buffer swap.

As a side effect of the necessary internal cache metadata, we also make
the vulkan swapchain more robust against API misuse (especially
out-of-order / non-lockstepped swapchain calls).

The vertex buffer might be larger than the amount of vertex information
we're actually rendering, so don't use `vertex->params.size`!

This is analogous to the existing functionality for buffers. A
texture may be created, requesting that it be exported. A
texture is transitioned between external and internal use with
pl_vulkan_hold (with export set to true) and pl_vulkan_release.

ra -> gpu

This makes no real sense in gpu.h, since the pl_gpu doesn't actually
need this information in any way. It's only needed for the shader header
generation inside dispatch.h, so having it in shaders.h is the right
place.

Makes some code arguably a bit uglier, but whatever.

No reason to have the space inside the string.

Ever since SPIRV-Cross has started emulating std140 layout when
cross-compiling SPIR-V to D3D11, there's no more real justification for
us to make this dependent on the backend type.

In theory, metal could require something different here - but even then
we should work around it in SPIRV-Cross rather than trying to make our
code depend on it at runtime.

Rather than editing this every time there's a new extension, it's
probably saner in the long run to just add error/object strings as we
add extensions. This avoids getting random warnings for future versions
of dependencies.

Since there's no better way to check for the existence of this value
other than by literally probing the header during the build step, we
introduce a new "private" config.h for internal checks like this. (Which
the user is unlikely to ever care about)

Rename subX/Y to sub_x/y for consistency

The code as written always used the subsampled weights for chroma, even
if the actual chroma plane was not subsampled. Fix that.

While the access mask is ignored for a queue family ownership transfer,
the pipeline stage is not. For lack of anything sane to put here, just
use TOP/BOTTOM.

See the justification in the comments. Works around build issues on some
platforms. Not the cleanest implementation, but then again, C linking is
not the cleanest topic. (Actually not giving meson the blame here)

Oops.

That brings back down the CPU usage of the API2 demo to basically zero.
Doesn't change the execution time, just the CPU usage - so I don't have
to update the results.

Also fix a race condition when DR is in use.

The renderer no longer has any abort() code paths, and the API version
indicator is now stable on git master. Hooray!

The underlying device memory may get reused by libplacebo, thus
invalidating the contents of anything an external API user has aliased
to the same device memory, such as imported buffer objects.