Khronos really, *really* loves dropping the KHR/EXT suffixes when
promoting extensions to core. And we really, *really* don't like
hard-coding multiple function names for every function in existence.

Brute force the problem by trying to load every function with the suffix
stripped, in case of failure.

When VK_KHR_get_physical_device_properties2 is missing. Currently, it
just segfaults.

This can be used by the config scripts of other projects without having
to do actual header feature testing. (In particular, we do the same for
libepoxy in our build script)

Seems like glslang upstream is more than happy to make their patch level
go back down to 0 now. To handle the mishmash of old and new versioning
schemes, we map the old patch level to version 0.0.x, which ensures it's
forwards-compatible with the new versioning scheme (that was fortunately
introduced after every relevant check of ours).

Fixes https://github.com/haasn/libplacebo/issues/83 again, properly this
time.

This uses round(), which requires GLSL 130+

Instead of raw identifiers of the form 0x%x. We can leverage our lovely
vk.xml-parsing utils generator to generate friendly name boilerplate
code for this.

Closes #107

This updates our checks to use the new header locations as introduced in
https://github.com/KhronosGroup/glslang/pull/2277. Fortunately, it seems
that the new version scheme is backwards compatible with the old one, so
we don't need any excessively complicated logic updates.

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

Something something, empty function lists get interpreted as "unknown
signature" rather than "void signature". Dunno if this is still relevant
for C++, but may as well get into the habit.

To prevent logic errors when overflowing e.g. the BT.2390 function, and
also make functions behave more predictably on overflow in general.

This ensures no function will ever see something larger than sig_peak.
Requires changes to `clip` and `linear` to make them work properly
again.

These are not included as part of the GCC visibility pragma.

A hilariously awkward mix-up. This probably meant the ICC profile code
never actually produced correct results in practice unless the two color
spaces happened to coincide.

Good thing nobody used it in production yet (tm)

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

Fixes #85

This can end up comparing undefined memory regions, because unpadded
areas of structs may not be initialized with anything particular.

This is needed primarily because some OpenGL/Vulkan drivers will end up
calling the pl_msg functions from random threads. Prevent any issues
when doing this by making sure these functions are thread safe.

VkResult in particular can return errors defined by extensions, like
VK_ERROR_INVALID_EXTERNAL_HANDLE. These are included as enum extension
in the registry.

As a side note, replace `findall` by `iterfind` for performance.

The use of GL_FRAMEBUFFER can generate an INVALID_ENUM error on older
GLES versions, apparently - and all commands specify it as equivalent to
GL_DRAW_FRAMEBUFFER anyway.

This isn't supported on GLES 3.0, only glInvalidateFramebuffer is.

For debugging purposes.

At least shaderc doesn't like the patch version being present here, so
make sure to manually strip it to prevent any confusion. This commit
enables us to actually use higher version SPIR-V features.

We don't actually want to force sampling at 32-bit, the precision only
makes sense for the float type.

highp is the normal 32-bit float, medium should be avoided unless
absolutely necessary.

cf. https://github.com/mpv-player/mpv/commit/5141662427

This slightly speeds up LUT computation because we skip having to check
the cache every pixel. We don't ever send it repeat values anyway.

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.

I should really stop doing this.

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.

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

This commit introduces the ability to explicitly mark storage buffers as
coherent, but that requires an API change. To avoid breaking API of this
release branch, we hard-code all storage buffers as coherent. This
shouldn't matter much in practice.

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.