When LTO is enabled using -flto, simply compiling does not
produce an error. Either LTO must be turned off or a linking check must
be performed. LTO does not seem to affect non-assembly checks.

This behaviour can be seen in the following test:

    $ cat t.c
    int main(void)
    {
        __asm__ (".foobar this_directive_doesnt_exist");
        return 0;
    }
    $ cc t.c -o t.o -flto -c
    $ echo $?
    0
    $ cc t.c -o t.o -flto
    ld: <inline asm>:1:2: unknown directive
        .foobar this_directive_doesnt_exist
        ^
     for architecture arm64
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    $ echo $?
    1

Signed-off-by: J. Dekker <jdek@itanimul.li>

If a Metadata OBU appeared right before a Frame Header OBU with
show_existing_picture = 1, it was not being attached to it but to the next
assembled picture, which was in the following TU.

Signed-off-by: James Almer <jamrial@gmail.com>

Relative speedup over the C code:
                          Cortex A53    A55    A72    A73    A76   Apple M1
intra_pred_z3_w4_16bpc_neon:    3.06   2.87   2.17   1.97   2.33   7.75
intra_pred_z3_w8_16bpc_neon:    3.90   3.94   2.97   3.16   2.93   4.43
intra_pred_z3_w16_16bpc_neon:   4.08   4.48   3.31   4.68   3.13   5.00
intra_pred_z3_w32_16bpc_neon:   4.43   4.85   3.50   4.02   3.33   5.62
intra_pred_z3_w64_16bpc_neon:   4.68   5.30   3.72   3.96   3.52   5.78

Relative speedup over the C code:
                          Cortex A53    A55    A72    A73    A76   Apple M1
intra_pred_z1_w4_16bpc_neon:    3.49   2.63   2.83   3.85   3.14   9.00
intra_pred_z1_w8_16bpc_neon:    6.19   4.39   3.65   6.58   4.99   6.50
intra_pred_z1_w16_16bpc_neon:   6.65   4.64   3.97   7.78   4.87   7.00
intra_pred_z1_w32_16bpc_neon:   7.76   5.49   5.17   7.83   5.59   8.24
intra_pred_z1_w64_16bpc_neon:   8.02   5.80   5.33   8.41   5.77   8.70

For 8 bpc, there's probably not much difference to a decent memset,
but for 16 bpc, there might be a bigger difference.

Add comments explaining the exact dimensions of the gather tables
used currently. That reasoning shows that the w=8 case can do with
one register less.

Before:                  Cortex A53     A55     A72     A73    A76  Apple M1
intra_pred_z3_w8_8bpc_neon:   356.2   376.2   218.9   246.4  176.1  0.6
After:
intra_pred_z3_w8_8bpc_neon:   339.6   357.3   205.6   232.3  160.0  0.5

Start out the multiplication/accumulation with a register that is
available sooner.

Before:                    Cortex A53      A55      A72      A73     A76   Apple M1
intra_pred_z1_w8_8bpc_neon:     266.3    268.9    146.6    155.3   103.9   0.4
intra_pred_z1_w16_8bpc_neon:    528.6    574.4    333.9    364.3   209.1   0.7
intra_pred_z1_w32_8bpc_neon:   1149.3   1245.4    752.3    811.5   503.4   1.3
intra_pred_z1_w64_8bpc_neon:   2198.4   2360.6   1462.9   1575.0  1007.6   2.4
After:
intra_pred_z1_w8_8bpc_neon:     266.3    269.1    146.6    155.0   100.1   0.4
intra_pred_z1_w16_8bpc_neon:    528.6    573.3    347.9    352.4   204.3   0.7
intra_pred_z1_w32_8bpc_neon:   1149.2   1245.3    763.4    759.6   474.8   1.3
intra_pred_z1_w64_8bpc_neon:   2198.8   2360.6   1430.0   1417.4   943.5   2.3

The second register will at most contain one valid pixel, the
padding pixel. Thus skip padding the register and just fill it
with the padding pixel.

There were redundant leftovers from copypasting bits when writing this
function.

This is for cases with h >= 16.

Process 2 blocks per iteration instead of 4.

Credits to gramner@twoorioles.com.

We must reload error just before calling dav1d_decode_frame_exit, as
it may have become stale between the last load and that call.
This can result in crashes since we signal a seemingly successfully decoded
frame, when it's not.
Reloading error within the frame done condition's body ensures a non-stale
value, as we use 'f->task_thread.task_counter == 0' to ensure all other
threads / tasks have already completed when entering it. In other words, only
the last thread still working on this frame can execute this code, after
all other threads have returned to doing something else.

Pack the 5 bytes of data to improve memory and perf.

This fixes a regression from 7409a189

Co-authored-by: Henrik Gramner <gramner@twoorioles.com>

Henrik Gramner authored 2 years ago and Henrik Gramner committed 2 years ago

Improves readability.

Henrik Gramner authored 2 years ago and Henrik Gramner committed 2 years ago

It would previously print the full report() info for C functions
(with broken horizontal alignment as a side effect).

98b0c96d added an include of
src/ref.h in src/fg_apply_tmpl.c. That template source file is
included in tests/checkasm/filmgrain.c.

src/ref.h includes <stdatomic.h>. Including this file requires
declaring a dependency on stdatomic_dependencies in meson, which
provides the fallback implementation of stdatomic.h when building
with MSVC.

Create new references instead.

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

"From VideoLAN with love"

"only and except are not being actively developed. rules is the
preferred keyword to control when to add jobs to pipelines." [0]

[0] https://docs.gitlab.com/ee/ci/yaml/index.html#only--except

Calling meson with no command is deprecated since 0.64.0

The code in dav1d_drain_picture could result in a desync between
c->task_thread.first (oldest submitted frame) and c->frame_thread.next (first
frame to retrieve and/or next submit location).
As we loop through drain, we always increment next, but first only if the
frame has data. If the frame is visible we return. The problem arises when
encountering (an) invisible frame(s), and the next entries haven't been fed
yet, we then keep on looping increasing next but not first, as these have no
data.

We should always return when we encountered data (visible or
invisible decoded frame): for visible, the code already returns, for
invisible, we can store a boolean indicating we drained at least one frame,
whenever we reach an empty entry after that, we return (all subsequent
entries are guaranteed to be empty anyway), not incrementing next nor first.
This will have the effect to insert the next frame at the first free spot
(which is much better than the weird skips it's doing now).

So basically, c->frame_thread.next could skip some (empty) entries.
Now it's contiguous.

Fixes #416.

This reverts commit a51b6ce4.

We can't increment first when no data is there, otherwise we might do it
while the first frame was not yet decoded, messing up ordering: imagine
having a framedelay of 8, and a file with 7 frames. We feed 7 frames over 8
slots, now next points to [7] (empty entry), and we start draining cause EOF.
We do need next to be incremented to reach the first frame ([0]), so it can
be outputted, and only then first too.

Fixes #418.

Add an option for selecting the core where the single thread of
checkasm runs. This allows benchmarking on specific CPU cores on
heterogenous CPUs, like ARM big.LITTLE configurations.

On Linux, one can easily wrap an invocation of checkasm with
"taskset -c <n> [...]" - so this option isn't very essential
there - however it is quite useful on Windows.

On Windows, it is somewhat possible to do the same by launching
the tool with "start /B /affinity <hexmask> [...]", but that
doesn't work well with scripting ("start" returns before the
command has finished running, and it's not obvious how to
invoke "start" from within WSL).

Using "taskset" to launch processes on specific cores within WSL
on Windows doesn't work - regardless of the Linux level affinity,
the process ends up running on the performance cores anyway.