This is not quite a proper resolution to the linked issue, because we
still forcibly skip the main scaling pass without FBOs. But it allows
using fast bicubic (or oversample) for the chroma plane, which is an
improvement.

See-Also: videolan/libplacebo#173

By adding a check.

This got renamed aeons ago.

No longer the case since a857cce8.

Fixes very undersaturated OSD on displays with an ICC profile whose
actual primaries differ significantly from the encoding primaries.

Actually fixes a bug, where we incorrectly used the pl_cache_params
values sometimes.

Instead of rgba32f. Halves size of 3DLUTs, in exchange for slightly more
overhead during generation.

In theory we could somehow do this conversion already inside
pl_gamut_map_generate, but I can't be bothered breaking API just for
this. Maybe if somebody else cares enough to micro-optimize this, feel
free, but since this code only runs on cache miss it isn't super
critical.

No idea how this compiles locally on my end, but I don't care to find
out.

Fixes overallocation of ICC 3DLUTs by factor 2x, which also fixes the
icc_load/save legacy fallback path.

Guard against num_entries overflow, guard against size overflow.
Omit separate read() call for padding, just oversize buffer.

Extremely hypothetical edge case, but trivial to guard against.

With xxhash, 50 MB is plenty fast enough compared to the general vulkan
init etc. overhead, and gives us plenty of room to store a number of ICC
3DLUTs and gamut mapping 3DLUTs.

To help understand wtf is going on sometimes

Use 64-bit value, since we operate on 64-bit hashes. And give it a name.

We no longer support running MSAN without fully instrumented
dependencies at all, either in the CI or otherwise. So, no more need for
all these hacks.

It was fun while it lasted.

Make sure our cache header has a "good" size, i.e. multiple of uint64_t.
We don't actually care about this fact internally currently, but it may
make a difference in some future.

Since these can be a source of non-negligible startup latency.

xxhash is fast enough to not really worry about a few-MB large objects
slowing down init process.

No reason to delete siphash just yet, it can be used as fallback for
systems with xxhash.

Closes: #300

In preparation for move to XXH3, which we want to inline always

So we can inline the hash function only into files that actually need
it.

For debug purposes.

Probably won't work for ICC/3DLUT cache but these probably want their
own custom mechanism anyway, since they're quite large.

No longer used by any current demo.

Caching is now done directly inside the pl_gpu, via the pl_cache
mechanism. This cache layer is no longer functional or needed.

Redirect the calls for backwards compatibility, although this will
still regress API users who do not set `pl_cache` explicitly.

No longer functional after the recent changes to make pl_gpu use
pl_cache directly. No need for backwards compatibility because there is
basically no user of this API in the wild.

Cosmetic.

Hendrik Leppkes authored 1 year ago and Niklas Haas committed 1 year ago

Trivial port by just replacing cached_program with
pl_cache_lookup/insert.

The cache key is made up of the shader body only, but we keep an
internal signature in the cache header to verify and invalidate the
cache when the shader compiler changes.

Co-authored-by: Niklas Haas <git@haasn.dev>

Rebased on top of revised pl_cache API. This version is a bit more
wasteful than it could optimally be, since we could be re-using the
buffer from the old cache object to store the new data. But I'd rather
avoid the headache right now.

Following same approach as d3d11. For simplicity, keep the current
gl_cache_header, since we still need to write out the format. We don't
need CACHE_MAGIC / CACHE_VERSION anymore since we can just touch the key
to invalidate all cached objects.

And ignore cached_program entirely.

Slightly more convenient because it will enable caching.

This is actually a constant, and could be precomputed and stored inside
static data if we had a language smart enough to do compile-time
arbitrary code execution.

But oh well, for now, this is a better compromise than status quo.

Since this can eat up some nontrivial amounts of compute time.
Just make sure it identifies the method and size.

Now users can be explicit about which cache they want to use, with the
save/load callbacks being used as a fallback for backwards
compatibility (for now).

Currently only enabled when explicitly provided by the caller, to avoid
unexpected surprises. (And also, because caching most other 3DLUTs is
currently pretty pointless)