More useful in theory, though in practice we just want the ability to
filter compute shaders for the CI...

Ostensibly for testing, in reality so we can make CI work again :^)

This reverts commit f8f90f5d.

Why are we even working around suspected driver bugs? It's really not
our issue, and I can't have this limit our release process. If users of
libplacebo want to work around such bugs, they still can.

What the limit should be is sort of an open-ended question. It's clear
that *some* sort of limit makes sense, to prevent users from
accidentally getting into loops of queueing up hundreds of thousands of
commands, but at the same time, 64 was too low in practice.

1024 might be a good compromise here. That's like 40 seconds of video
processing at 24 fps, if you were to accidentally queue it all up
without any flushes. Much higher and people might legitimately not be
testing on long enough clips to notice such bugs in their loop design.

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

1. Try VK_LAYER_KHRONOS_validation before VK_LAYER_LUNARG_standard_validation
2. Fail gracefully if neither are supported

It would also be nice if we could fail more gracefully if the debug
report extension is not supported, but that's a problem for another
commit.

It's useful to have these in the logs for debugging, since I can't
always ask users to run `vulkaninfo` on their devices.

This makes the GPU CI stuff actually work. Finally, coverage \o/

ANV seems to deadlock on our compute shaders. Pending investigation. For
now, this makes it work on intel iGPUs, even though it's an ugly hack.

Even though vulkan technically requires the compute queue be a thing, we
might disable it internally for debugging purposes. So we want our code
to be robust against this queue simply not existing.

Some of those are invalid for C++, so restrict them to C.

By adding support for VK_AMD_display_native_hdr, even though we can't
really do much with it at the moment since we don't know *which* color
space it is.

All hail the cloud overlords and their VMs with GPUs

This fixes the CI/licensing issues introduced by 68375667 without
regressing #67. We will now link against SPIRV-Tools where we can, and
won't otherwise. Apparently glslang can sometimes depend on SPIRV-Tools
and sometimes not...

A better solution for this might still be needed to avoid licensing
issues. But for now, I don't particularly care, especially since we
don't actually use any code from SPIRV-Tools so in theory the license
shouldn't matter.

Turns out this makes no sense anyway, since we need to degrade to a full
pipeline barrier to ensure the host writes are made visible.

MoltenVK likes to dump to stderr on every single vkCreateEvent call.
Avoid thrashing stderr by remembering when this doesn't work..

This fixes blowing up with excessive grain on e.g. HDR sources. I
decided not to change the signature of the deband shader itself at this
time, since the deband shader doesn't really know anything about the
meaning / interpretation of what it's debanding. This is the user's
responsibility when using the shader directly.

Fixes #59.

Since we control to a very fine degree when and where memory flushing
and invalidation happens anyway, there's no reason for us to require
coherent memory.

This is a very slight performance gain on my tested platforms, but more
importantly, this allows libplacebo to work on platforms which only have
noncoherent memory (such as some iGPUs).

In some configurations (perhaps related to linker settings), glslang
seems to depend on SPIRV-Tools, and failing to explicitly load this
dependency causes link issues.

Fix this by simply adding the dependencies to the dependency list.
(Seriously, can glslang get a .pc file already?)

Fixes #67

Since the fix version is not part of the ABI, we can't use a header
define for it. (And indeed, users can't use this information as part of
any preprocessor check - nor should they need to)

I won't bother bumping the API version for this change because it's
unlikely to result in any breakage.

Importing image memory is a funny thing; there's no core mechanism
to communicate the layout of the image. Depending on how exactly
the memory was imported, and where it was imported from, it might
be possible to manage without explicit knowledge of layout, or
out-of-band mechanisms might exist to communicate it.

Today, we specifically can handle importing of memory via dma_buf
fds. While there is a Vulakn extension defined that could help
to communicate layout (VK_EXT_image_drm_format_modifier), this
extension isn't actually implemented in any driver and it doesn't
look like it will happen any time soon.

Without it, we have to hope that imported memory has the same layout
that Vulkan expects, based on the declared image format. In
practice, this has proven to be true for the real world scenario
we care about - which is importing decoded video from VAAPI - there
are only a couple of relevant formats, and the drivers for both
Vulkan and VAAPI are written by the same sets of people following
the same hardware driven recommendations for layout.

However, just because layouts match in practice, doesn't mean that
they pass validation. What we see is that, for some formats,
validation will fail when binding memory, saying that the memory
segment is smaller than the vulkan-calcuated memory size. I assume
this happens due to a difference in memory alignment (pretty much
any other cause would lead to visible errors).

As we would like to be able to use VAAPI imported surfaces without
sacrificing validation, we need a way to filter out these expected
errors, and let validation proceed as normal elsewhere.

The mechanism we've decided on is to provide a way to ignore
errors on a specified vulkan object (in our specific case, the
VkImage). We store the object ID before the bind call, and clear
it afterwards. While it is set, errors on that object will be
suppressed.

It's a simple mechanism that isn't thread safe, but could be made
so if/when the need arises.

I forgot what the original justification was for using short timeouts
here (perhaps some driver bug?) but in any case, it doesn't seem to make
any sense anymore.

This reduces CPU usage drastically on some drivers. I kept one loop at
10 ms since it shouldn't be hit anyways, and this way we know it's stuck
in that loop for absurd amounts of time.

The struct goes out of scope before it's used

Currently we only look at the swapchain-specific feature flags, but we
also still need to respect the image format's own limitations.

The current logic could end up with a buffer that needs to be both
device-local (for vertex information) and host-visible (for updates).
This is obviously nonsensical, so work around this case instead.

The ideal solution is to use a separate staging buffer, but that
requires more logic changes than this workaround, and the only
difference is that this might be possibly slower.

...instead of hard-coding <prefix>/include/libplacebo, which possibly
is different from the location specified by includedir.

Win32 compatible mmap() implementations exist, but it's easier to just
read the file into malloc() allocated memory. This uses fseeko() and
ftello(), which are available in POSIX and mingw-w64.

xtalloc was copied from mpv, which means that we see symbol
collisions if libplacebo is statically linked into mpv. So
use an `xta_` prefix for all the functions. In practice, this
has almost no effect on the consuming code because everything
is accessed via macros.

These structs are included via extern declarations, so they can
silently conflict with equivalently named declarations in an
application if libplacebo is included statically.

And this happens with mpv, which also declares a `spirv_shaderc`
struct.

So, prefix the struct names with `pl_` to avoid this.

These made it so that the async transfer queue was never actually used.
This is obviously a massive performance regression on all drivers
supporting asynchronous transfer (e.g. AMDVLK).

The spec explicitly allows the case where the transfer spans the entire
image, i.e. offset+extent = size.

dav1d people want this to be permissive so they can adapt it for
documentation purposes. I have no problems releasing this specific file
under a permissive license.

Note that since both the header and source code heavily depend on the
LGPLv2.1+ parts of libplacebo, this licensing change isn't terribly
useful unless you're just interested in copying fragments of the glsl
code or some of the C helper functions.

These are different enums, with different legal members. Not only does
this avoid a warning, it also avoids future disaster by conflating the
two.

We need to use the explicitly named functions like texture2D(),
texture3D() etc. for low GLSL versions. Add a bunch of shitty
compatibility code to template out the function name.

The specific way I solved it also opens us up to allowing e.g. rectangle
textures in the future.

Make this a function instead of a static inline, since it's complicated
enough.

This can be useful for API users that don't want to go through the
bother of setting up a dummy `pl_gpu` just to create some shaders.

- I wanted to add new parameters, and rather than having the function
  signature grow out of control, I decided to switch to the same
  `params`-style as the rest of libplacebo, for future forwards
  compatibility.

- We need to expose the identifier, because users of raw shaders might
  want to combine multiple shaders into the same GLSL program.

This kills off the hacky `_ex` functions and uses a params struct. Also
organizes some fields around, for reasons.

Instead of assuming the lowest possible, assume GLSL 130 as the
baseline. This requires bumping the API version because it is a breaking
change to some use cases.

Also a missing GLSL version compat check to the dither code.

- change HTML syntax to markdown syntax
- move the (now rather lengthy) authors section below the (more
  important) API overview section
- merge (and reword) the contributors and authors sections, which were a
  bit redundant
- also remove the (now redundant) support section