GitLab

Feedback fixes.  Added check_decode_callback for checking if DXVA decode should be used given the SeqHdr.  Fixed function signitures so that decode_callback or release_callback can release decode buffers.  Updated playback tool with changes.

Based on review feedback remove bitstream allocation callbacks: alloc_bitstream_callbakc and release_bitstream_callback.
Replaced with passing tile group data directly to decode_callback which can then copy bitstream data itself.  Note that
this requires publishing an internal structure: Dav1dTileGroup.

Also found some cases where picture information is necessary for accurate DXVA structure allocation.  So Dav1dPicture parameter
was added to alloc_callback.

API review has completed on the DXVA structure definitions for AV1.  This resulted in a few minor naming changes.  This commit updates the copy in dAV1D to match.

A new set of callbacks have been added which allow an application to have dAV1d generate AV1 DXVA structures.
The application can then take these generated structures and use them to call DXVA APIs (in DX9, DX11, or DX12).  When using DXVA
to decode dAV1d software based decoding is disabled and replaced with the DXVA callback functions.

There are 5 new callbacks:
 * decode_callback - called to perform DXVA decode (using SubmitBuffers)
 * alloc_callback / release_callback - for allocating and releasing AV1 DXVA picture structs
 * alloc_bitstream_callback / release_bitstream_callback - used for allocating and releasing
     GPU backed memory for bitstream data.

 These callbacks are designed to be compatible with all 3 variants of DXVA decoding: DX9, DX11 and DX12.
 Currently when DXVA decode is enabled (by setting up the DXVA callback structure), the following decoder behaviours are changed:
 * decoder always operates in single threaded mode (multi-threaded operation only works for DX12)
 ...

Niklas Haas authored May 27, 2020 and Jean-Baptiste Kempf committed Jun 07, 2020

Blacklisted some files not directly relevant to the codebase (such as
tests, tools and debugging functions).

The coverage HTML report gets attached as a build artifact, although
unfortunately we can't link directly to the `index.html`. We also attach
the coverage XML as a cobertura report, although I'm not sure if it does
anything.

Martin Storsjö authored May 31, 2020 and Jean-Baptiste Kempf committed Jun 04, 2020

This is currently not used in dav1d (yet), but there's a need for
it in rav1e, which shares this header with dav1d.

mc_scaled_8tap_regular_w2_8bpc_c: 764.4
mc_scaled_8tap_regular_w2_8bpc_avx2: 191.3
mc_scaled_8tap_regular_w2_dy1_8bpc_c: 705.8
mc_scaled_8tap_regular_w2_dy1_8bpc_avx2: 89.5
mc_scaled_8tap_regular_w2_dy2_8bpc_c: 964.0
mc_scaled_8tap_regular_w2_dy2_8bpc_avx2: 120.3

mc_scaled_8tap_regular_w4_8bpc_c: 1355.7
mc_scaled_8tap_regular_w4_8bpc_avx2: 180.9
mc_scaled_8tap_regular_w4_dy1_8bpc_c: 1233.2
mc_scaled_8tap_regular_w4_dy1_8bpc_avx2: 115.3
mc_scaled_8tap_regular_w4_dy2_8bpc_c: 1707.6
mc_scaled_8tap_regular_w4_dy2_8bpc_avx2: 117.9

mc_scaled_8tap_regular_w8_8bpc_c: 2483.2
mc_scaled_8tap_regular_w8_8bpc_avx2: 294.8
mc_scaled_8tap_regular_w8_dy1_8bpc_c: 2166.4
mc_scaled_8tap_regular_w8_dy1_8bpc_avx2: 222.0
mc_scaled_8tap_regular_w8_dy2_8bpc_c: 3133.7
mc_scaled_8tap_regular_w8_dy2_8bpc_avx2: 292.6

mc_scaled_8tap_regular_w16_8bpc_c: 5239.2
mc_scaled_8tap_regular_w16_8bpc_avx2: 729.9
mc_scaled_8tap_regular_w16_dy1_8bpc_c: 5156.5
mc_scaled_8tap_regular_w16_dy1_8bpc_avx2: 602.2
mc_scaled_8tap_regular_w16_dy2_8bpc_c: 8018.4
mc_scaled_8tap_regular_w16_dy2_8bpc_avx2: 783.1

mc_scaled_8tap_regular_w32_8bpc_c: 14745.0
mc_scaled_8tap_regular_w32_8bpc_avx2: 2205.0
mc_scaled_8tap_regular_w32_dy1_8bpc_c: 14862.3
mc_scaled_8tap_regular_w32_dy1_8bpc_avx2: 1721.3
mc_scaled_8tap_regular_w32_dy2_8bpc_c: 23607.6
mc_scaled_8tap_regular_w32_dy2_8bpc_avx2: 2325.7

mc_scaled_8tap_regular_w64_8bpc_c: 54891.7
mc_scaled_8tap_regular_w64_8bpc_avx2: 8351.4
mc_scaled_8tap_regular_w64_dy1_8bpc_c: 50249.0
mc_scaled_8tap_regular_w64_dy1_8bpc_avx2: 5864.4
mc_scaled_8tap_regular_w64_dy2_8bpc_c: 79400.1
mc_scaled_8tap_regular_w64_dy2_8bpc_avx2: 8295.7

mc_scaled_8tap_regular_w128_8bpc_c: 121046.8
mc_scaled_8tap_regular_w128_8bpc_avx2: 21809.1
mc_scaled_8tap_regular_w128_dy1_8bpc_c: 133720.4
mc_scaled_8tap_regular_w128_dy1_8bpc_avx2: 16197.8
mc_scaled_8tap_regular_w128_dy2_8bpc_c: 218774.8
mc_scaled_8tap_regular_w128_dy2_8bpc_avx2: 22993.1

posix_memalign is defined as a built-in in gcc in msys2 but it's not available
when linking with the Universal C Runtime. _aligned_malloc is available in the
UCRT.

That should only affect builds targeting Windows since _aligned_malloc is a MS
thing.

Eliminate store forwarding stalls.
Use shorter instruction encodings where possible.
Misc. tweaks.

Niklas Haas authored May 26, 2020 and Jean-Baptiste Kempf committed May 26, 2020

This one correctly sets the subsampling mode based on whether or not the
plane is actually subsampled, and also infers PL_CHROMA_UNKNOWN as
PL_CHROMA_TOP_LEFT in such cases.

libplacebo v66 got helper functions that make preserving the aspect
ratio in this case trivial. But we still need to make sure to clear the
FBO to black if the image doesn't cover it fully.

Returning out of this function when pl_render_image() fails is the wrong
thing to do, since that leaves the swapchain frame acquired but never
submitted. Instead, just clear the target FBO to blank red (to make it
clear that something went wrong) and continue on with presentation.

Annoying minor differences in this struct layout mean we can't just
memcpy the entire thing. Oh well.

Note: technically, PL_API_VER 33 added this API, but PL_API_VER 63 is
the minimum version of libplacebo that doesn't have glaring bugs when
generating chroma grain, so we require that as a minimum instead.

(I tested this version on some 4:2:2 and 4:2:0, 8-bit and 10-bit grain
samples I had lying around and made sure the output was identical up to
differences in rounding / dithering.)

Generalize the code to set the right pl_image metadata based on the
values signaled in the Dav1dPictureParameters / Dav1dSequenceHeader.

Some values are not mapped, in which case stdout will be spammed.
Whatever. Hopefully somebody sees that error spam and opens a bug report
for libplacebo to implement it.

Having the pl_image generation live in upload_planes() rather than
render() will make it easier to set the correct pl_image metadata based
on the Dav1dPicture headers moving forwards. Rename the function to make
more sense, semantically.

Reduce some code duplication by turning per-plane fields into arrays
wherever appropriate.

As an aside, also apply the correct chroma location rather than
hard-coding it as PL_CHROMA_LEFT.

This is turned into a const array in upstream libplacebo, which
generates warnings due to the implicit cast. Rewrite the code to have
the mutable array live inside a separate variable `extensions` and only
set `iparams.extensions` to this, rather than directly manipulating it.

Emmanuel Gil Peyrot authored May 16, 2020 and Jean-Baptiste Kempf committed May 16, 2020

Signed-off-by: Marvin Scholz <epirat07@gmail.com>

Add code to check that a function doesn't accidentally overwrite
anything in the area located just above the current stack frame.

This allows selecting at runtime if placebo should use OpenGL
or Vulkan for rendering.

To un-clutter the main dav1dplay.c, move the fifo to its own
file and header.

If the maximum number of arguments (currently 15) is changed into
an even number, and a function actually takes the full number of
arguments, we would have the situation where the checked spot on
the stack is at the same place as we store an inverted copy of it.

We already allocate enough space for two values though (for stack
alignment purposes, 16 bytes on arm64 and 8 bytes on arm32) so by
storing the reference in the upper half of this, the lower half of
it works as canary and isn't overwritten.

Use 'unsigned' instead of 'unsigned int' for consistency.
Add 'const' to a few variables.
Make proper use of C99 features.

Also skip the AVX warmup.