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

Similar to the SDL2 demo, except it doesn't actually do anything useful
yet. Contains all of the boilerplate for setting up a GLFW window for
use with libplacebo, though.

"Oops"

pl_format -> pl_fmt

Technically needed for wayland. Not that SDL2 supports it anyway.

This is used both for updating the size and querying the size. I don't
want to make these separate functions because it should be painfully
obvious that the size you get may not be the size you request.

This allows libplacebo to work on wayland, which mediates the concept of
swapchain resizing to protocols like xdg_shell that mesa/vulkan can't
know anything about (by design).

There's no reason the user shouldn't be allowed to change the log
parameters around later on.

Not implemented for the other types of objects, because the chances of a
user needing to associate unique data for objects is much less likely.
It helps for buf/tex in particular since the user can use this to e.g.
hold extra state that needs to be tracked for synchronization / external
API usage.

It's also motivated by the `pl_tex_dummy_create`, which can benefit from
allowing users to attach their own objects to dummy textures so they
know which one corresponds to what.

This is basically a software emulated `pl_gpu`, which does all
texture/buffer operations in host memory using CPU instructions.

Attempting to somehow soft-emulate shaders or rasterize is _way_ out of
scope for this dumb thing, so we don't support `pl_tex_blit` or
`pl_pass` at all. Literally the only point is to let users generate
"faux" shaders, while keeping track of the generated LUTs etc.

This was accidentally left exposed from a previous version of the API.
It makes no sense in the public-facing code, so move it to the private
`pl_shader_reset_ex`.

Also swap the order of parameters for consistency.

This was supposed to be `index`, not `ident`. No change to semantics,
but possibly confusing for users.

uint32_t -> `int` can overflow

Turns out, doing this improves coverage massively. :-)

Forgot to update this, now it compiles again (and tests sensible stuff)

We accidentally implemented this inside vulkan/gpu.c instead of the
general purpose wrapper code. That also meant we never tested the
`tex->params.export_handle` condition.

However, I realized that this condition is actually too restrictive for
our test framework, and working around it there would be sort of
annoying. So just drop the restriction.

I won't bother updating the API version for this change, since the
actual behavior hasn't changed. (And even if it had, it would only
matter for our own test framework)

As an aside, fix a bunch of related comments that still had outdated
field names in the documentation.

Turns out that this actually causes problems when e.g. trying to reuse
an SSBO between a compute shader and a fragment shader, which comes up
when using the new peak detection code.

One annoying thing about the implementation is that we will always need
to make sure that buf_flush happens after buf_signal, since the former
depends on the stage variable set by the latter. Maybe I'll change this
in the future if it gets annoying.

Fixes #49.

The whole reason this `prelinearized` field *exists* is because we
still want to pass the original colorspace when performing color
management or constructing the 3DLUT. It's weird how we never used it.
Fix this oversight.

This also allows us to finally separate peak detection from color
management. The current place in the code actually has almost no
drawbacks, since it's effectively free unless FBOs are disabled.

One annoying consequence is that this means we will now always perform
peak detection at the source resolution, even if the display is smaller.
In the relatively common case of 4K video on 1080p displays, this is a
performance regression. To fix it, we could try investigating whether to
do the analysis after up/downscaling, but then we have more special
cases to think about, so I think I'll live with the status quo for now.
Peak detection isn't the end of the world even at 4K.

Closes #40.

Now we actually have a use for this!

The previous approach of using an FIR with tunable hard threshold for
scene changes had several problems:

- the FIR involved annoying dynamic buffer sizes, high VRAM usage,
  and the FIR sum was prone to numerical overflow which limited the
  number of frames we could average over.

- the hard scene change detection was prone to both false positives and
  false negatives, each with their own (annoying) issues.

Scrap this entirely and switch to a dual approach of using a simple
single-pole IIR low pass filter to smooth out noise, while using a
softer scene change curve (with tunable low and high thresholds), based
on `smoothstep`. The IIR filter is extremely simple in its
implementation and has an arbitrarily user-tunable cutoff frequency,
while the smoothstep-based scene change curve provides a good, tunable
tradeoff between adaptation speed and stability - without exhibiting
either of the traditional issues associated with the hard cutoff.

Another way to think about the new options is that the "low threshold"
provides a margin of error within which we don't care about small
fluctuations in the scene (which will therefore be smoothed out by the
IIR filter).

While redesigning the algorithm, I also redesigned the API - so that
peak detection and tone mapping are separate, discrete steps that can be
done as part of two different shaders. (Or as part of the same shader)
This is required for #40, and in particular, means that issue is now
within reach.

cf. https://github.com/mpv-player/mpv/pull/6415