Return an empty frame mix until the first frame's PTS value has been
reached.

In case output is flipped/mirrored.

Fixes: videolan/libplacebo#284

Probably wouldn't happen anyway on any sane compiler, but nonetheless.

To avoid collisions with other vars named 'tmp'

Fixes: 3fd65b26

Avoids excessively over-saturating when tone mapping upwards in
brightness, which generally leads to an unnatural effect. Tested with
both black point compensation and inverse tone mapping.

Fixes: videolan/libplacebo#280

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

This avoids using designated initializers (compat issues with C++20)

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

These were forgotten in earlier changes.

Since this comes with a significant performance and CPU cost enhancement
at only minor debuggability penalty.

Instead of implicitly clamping the output image to the originally
specified dst_rect, this allows the result of applying a distortion
matrix to effectively exceed the indicated target crop area.

Of course, this is probably surprising to some users, but then again,
distortion isn't exactly a common use case - and I would argue that this
makes arbitrary rotation work much more intuitively.

Helper function to compute bounding boxes of transformations.

Requires generation of a low-res feature map. To avoid excessive ringing
artefacts, hard-code the sampler to bicubic. This ensures a clean
inversion with the bicubic interpolation that's performed as part of the
tone mapping shader.

Make this way less hacky and also more easily extended.

After a few iterations I settled on this, which is essentially a
HDR-specific sharpening filter, that tries to maintain perceptual local
contrast differences (in the HDR source) while tone-mapping global
contrast.

The basic idea is to split the image into HF and LF components and apply
the tone-mapping algorithm only to the LF component. Set to fairly
conservative values by default.

Closes: videolan/libplacebo#261

Mostly for cosmetic reasons, though I plan on extending at least one
instance of this.

I want to extend this with more "runtime"-provided (i.e. not
user-facing) parameters. Having learnt my lesson, a struct and _ex
renaming it is.

If gray maps to solid black, as in some extreme benchmark/test profiles,
y_approx ends up as infinity which breaks the following arithmetic.

Fix it to hard-code a fallback to gamma 1.0 in such extreme cases.

Fixes: videolan/libplacebo#282

Lest the very fabric of society fall apart and the world descend into
chaos.

The upscaler tests were actually no-ops because the output crop was
effectively hard-coded as 1x1. Make a number of changes to address
short-comings here:

1. Use a 50x50 texture instead of a 5x5 one.
2. Initialize it with random data (to actually hit edge cases etc.)
3. Test upscalers by explicitly cropping the input
4. Also test downscalers (by explicitly cropping the target)

1/6.0 etc. are not legal constants in GLES, need to write as 1.0/6.0.

Mostly for demonstration purposes.

Just to make sure the shaders compile and the main logic branch is
covered.

Mostly just as a convenience to the user, to avoid having to hook
PL_HOOK_PRE_OUTPUT and ship a custom hook for this. It's trivial for us
to integrate into the existing pattern of params.

For hooking the point immediately before alpha blending, for any shaders
that want to make a last-ditch image modification along the lines of
rotation, corner rounding, etc.

Simple helper function for a common-ish operation.

Could be done better (e.g. mipmapping to reduce aliasing, arbitrary EWA
interpolation, ...) but good enough to get the feature off the ground.

Closes: videolan/libplacebo#281

Needed for new feature.

This only affects pass_output_target and does not make it into the
cache.

Removes the clunky stateful peak_detect_active bool in exchange for a
properly scoped temporary FBO force bool.

Make it more explicit which case is which.

This variable was never currently set.

Kacper Michajłow authored 1 year ago and Niklas Haas committed 1 year ago

MinGW-w64 math functions are significantly slower than the UCRT ones.
In particular powf is over 7 times slower than UCRT counterpart. MinGW-w64
explicitly excludes some math functions from their ucrtbase def file and
replaces with own versions. To workaround the issue, generate the import
library and link it with UCRT versions of math functions.

Fixes slow gamut mapping LUT generation.

For 33x25x45 perceptual map:
Before: 816 ms
After : 109 ms

With linear interpolation, this gives enough precision even on a
256-element LUT, to pass the tests.

1232.685 ms -> 422.975 ms on my machine, almost 3x as fast.

It's worth pointing out that the inverse function, pq_oetf, is not a
major bottleneck and therefore does not need to be optimized. This is
quite fortunate, because quantizing the optical domain of PQ would be
rather terrible for precision.

To test impact of performance improvements to the 3DLUT generation code

Kacper Michajłow authored 1 year ago and Niklas Haas committed 1 year ago

Currently `include_directories` are ignored when used as `dependencies`
in `has_header_symbol`. Use `compile_args` as a workaround for this
limitation.

The root cause will be fixed by https://github.com/mesonbuild/meson/pull/10122

Kacper Michajłow authored 1 year ago and Niklas Haas committed 1 year ago

Prefer our Vulkan-Headers as they are always available and with correct
version. Also remove version check from Vulkan loader as we do not care
about it, it will be resolved during runtime if supported Vulkan version
is available.

This fixes build for Android and gives more portability in general.

Android NDK 25c provides Vulkan 1.3.203 headers, but without vk.xml registry
file which we use to generate some code.