Merge dav1d 0.3.0 AArch64 Assembly

[vibhoothi]

Hi,

This new patchset advances addition of dav1d 0.2.0 and 0.2.1, 0.2.2, 0.3.0 to rav1e.

Overview

From 0.2.0 till 0.3.0 Release of dav1d, mainly we have is:

• mc optimisations for Cortex A53.
• CDEF dir and filters
• Implementations of warp8x8{,t} functions.
• Improvements to Loop Restoration filtering.
• smart padding for CDEF
• SGR Looprestoration
• Loopfiltering

We are skipping the above for_now as accordance with x86.
We would be integrating Looprestoration, Loopfiltering, CDEF once we complete the initial phase of merging till 0.5.0 of dav1d arm.

There are around 25 new functions from dav1d 0.2.0..0.3.0, which are merged but not integerated for_now

• rav1e_cdef_padding8_neon
• rav1e_cdef_padding4_neon
• rav1e_cdef_filter8_neon
• rav1e_cdef_filter4_neon
• rav1e_cdef_find_dir_neon
• rav1e_warp_affine_8x8_8bpc_neon
• rav1e_warp_affine_8x8t_8bpc_neon
• rav1e_lpf_v_sb_y_neon
• rav1e_lpf_h_sb_y_neon
• rav1e_lpf_v_sb_uv_neon
• rav1e_lpf_h_sb_uv_neon
• rav1e_wiener_filter_h_neon
• rav1e_wiener_filter_v_neon
• rav1e_copy_narrow_neon
• rav1e_sgr_box3_h_neon
• rav1e_sgr_box5_h_neon
• rav1e_sgr_box3_v_neon
• rav1e_sgr_box5_v_neon
• rav1e_sgr_calc_ab1_neon
• rav1e_sgr_calc_ab2_neon
• rav1e_sgr_x_by_x
• rav1e_sgr_finish_filter1_neon
• rav1e_sgr_finish_filter2_neon
• rav1e_sgr_weighted1_neon
• rav1e_sgr_weighted2_neon

The loop restoration cannot be taken for now as it is using wiener_filter while we have an expensive RDO in rav1e, but we can use for the final calculation of RDO and also add upon, later in dav1d 3.0 there are self-guided filters which could be adapted if we do some hacking over it.

On Initial assessment of better neon optimised for A53, we noticed an improvement of ~1_1.5 mins.

The next PR which has dav1d 0.4.0 merge would be really interesting to see as we have those in x86.

Reference
#1754

[coveralls]

Coverage remained the same at 75.4% when pulling 944175b on vibhoothiiaanand:src-arm-0.2.0 into 4abaed9 on xiph:master.

[EwoutH]

Great work again. Is it worth pulling in Aarch32 NEON, considering the increase in binary size and compile times, the very low performance of ARMv7 cores and the declining adoption? I think Aarch64 should be the (only) focus for Arm.

[lu-zero]

I'd postpone any 32bit work until the 64bit codepaths work flawlessly.

[barrbrain]

Having the AArch32 sources available is inconsequential to AArch64 builds, so there's no harm in updating the ARM sources in the same order as upstream. Although, one difference with x86 is that the 32 and 64 bit sources are completely separated which makes it easier to skip the 32 bit sources.

[barrbrain]

very low performance of ARMv7 cores and the declining adoption

While armv8 cores are commonly adopted, they generally include support for both AArch32 and AArch64. The adoption of AArch64 software stacks is nowhere near as ubiquitous as armv8. This at least partly due to the large increase in code size from AArch32 to AArch64. So for the near future, there are likely applications for AArch32 on armv8.

[barrbrain]

For testing purposes, we can match the constant stride in assembly to the buffer used by the encoder.

[EwoutH]

What's the status of this PR? Need any help testing?

[vibhoothi]

So,

• Please ignore the Merge request branch name
• This PR advances the merge process while we do not have any major gains but very minor gains,
  on an average for 5 Frames encoding, an approx of 10 seconds and 0.01 FPS gain we got, encoded 5 frames(720p4:2:0), if we do detailed testing, we should get more
• Helps the future expected gains.

[barrbrain]

Awesome, this matches the changes in dav1d from 0.1.0 to 0.3.0.
Thank you for catching the warnings in src/arm/tables.S.