Fixes build warning.

Oops?

Not sure this matters for anything. To be on the safe side, only force
it if there was an exact match.

Conform to a style more consistent with other infodumps in libplacebo,
and move it out of random logic and into a common place.

Again, the explicit parameters here are not making things clearer.

Just make `icc` itself mutable. It's already complicated enough anyway,
the explicit parameter list is not simplifying things.

For consistency

Supersedes: !643

Annoyingly we have to memcpy this array if we want to pretty-print the
Auto (%s) case like we used to. Oh well. This could probably be done
more elegantly, but it's definitely not worth the time investment.

Shocking, I know.

Motivated by !643, but also generally useful.

Explicit OOTF support was removed and baked into the EOTF step a long
time ago.

This is all black-scaled CSPs with the exception of HLG.

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

@SOURCE_ROOT@ points to parent project, instead use current source dir
to ensure that we get libplacebo version.

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

If peak detection is enabled it should have higher priority than static
metadata, that often is incorrect.

Fixes: https://github.com/mpv-player/mpv/issues/13609

So we can enable merge trains.

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

Commit 2f06c045 did output only, but we should use utf-8 for both.

If pbo_download_cb happens to fire first, buf is no longer valid
reference.

We use UTF-8 in all source files.

Instead of promoting *all* texture upload buffers to host-mapped VRAM,
only do it when there is sufficient space available (e.g. BAR devices).

Fixes: https://github.com/mpv-player/mpv/issues/13303
Fixes: https://github.com/mpv-player/mpv/issues/12517

Since this is very restricted on non-resizable BAR platforms.

Has the added advantage of allowing us to track which exact
`pl_buf_create` call created the buffer (i.e. imported or allocated).

After a certain input size, the gather kernel pulls ahead. This is
either due to interactions with the size of the texture cache, or due to
alignment with the 2x2 gather input grid, or both.

Regardless, this should generally speed things up for very high radius
polar kernels (especially when downscaling).

To fit with reduced hardware limits on some devices.

See-Also: https://github.com/mpv-player/mpv/issues/13405

No practical reason to limit this field to 32 bits.

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

It was sampling already sampled pixels when switching between direct and
gather sampling. There was a check only on first pixel, but if the first
one was not sampled yet, but the next were, it would overlap the gather
window.

Fixes: https://github.com/mpv-player/mpv/issues/13405

Because timeline semaphores are not currently supported.

See-Also: https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/7600

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

Cosmetic change, files like that doesn't make sense anyway. This change
follows ITU-T H.264 and H.265 defined limit.

Fixes UB reported by -fsanitize=function

The current behavior is very ad-hoc and presents numerous issues to
downstream clients. Make this configuration process more straightforward
by adding an explicit clearing mode enum field to `pl_render_params`,
which the old override fields are specific instances of.

Notably, this could be extended in the future, e.g. by PL_CLEAR_GRADIENT
or whatever. (Although this can already be done as of right now by
setting both clear modes to PL_CLEAR_NONE and using blend_params on top
of a custom-drawn gradient)

The default of `PL_COLOR_CLEAR` for both is consistent with the current
status quo, and also presents the least surprising outcome when
combining transparent/opaque images with transparent/opaque
framebuffers. This way, the user only gets transparent images output if
they explicitly opt-in to it, either by setting
`background_transparency` to 1 (like `plplay` does), or by setting the
background clearing mode to `PL_CLEAR_SKIP`.

In particular, `border = PL_CLEAR_SKIP` will result in "garbage" pixels
out of the box, at least on implementations which don't pre-clear
framebuffers for you.

Supersedes: videolan/libplacebo!637

Analog to pl_frame_clear_rgba. I had to decide carefully whether
I wanted to preserve the symmetry with `pl_frame_clear_rgba` in taking
only a `pl_gpu`, or if I should take the whole `pl_renderer` to gain
access to the internal `pl_dispatch`. But I decided to go with the
`pl_gpu`, since we might want to move this set of functions to
a different module in the future. (It's not really renderer-specific)

I also really regret having to go through such hoops every time to get
the per-plane subsampling ratio. Truthfully, this should probably be
a helper function.

See-Also: !637

This field was doing double duty between marking the alpha mode as
unknown and marking the alpha channel as absent, with inconsistent
results. In particular, pl_renderer always inferred the alpha channel if
present in the texture, leaving users with no options for easily
manually disabling it.

This patch adds PL_ALPHA_NONE to rectify the situation, allowing API
users to set `target.repr.alpha = PL_ALPHA_NONE` to explicitly disable
alpha blending even when the target supports it.

See-Also: !637

Relaxes some restrictions on this function, but also reduces the
tendency of this pass to introducing blurring/smudging.

Fixes: https://github.com/mpv-player/mpv/issues/13399