[FFmpeg-devel] [PATCH] libswscale/aarch64/hscale.S: Support more bit-depth variants.

Martin Storsjö martin at martin.st
Fri Jan 15 23:10:10 EET 2021


On Mon, 11 Jan 2021, Reimar.Doeffinger at gmx.de wrote:

> From: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
>
> Trivially expand hscale assembler to support > 8 bit formats
> both for input and output.
> 16-bit input is not supported as I am not certain how to
> get sufficient test coverage.
> ---
> libswscale/aarch64/hscale.S  | 53 ++++++++++++++++++++++++++----------
> libswscale/aarch64/swscale.c | 49 +++++++++++++++++++++++++++++++--
> 2 files changed, 85 insertions(+), 17 deletions(-)
>
> diff --git a/libswscale/aarch64/hscale.S b/libswscale/aarch64/hscale.S
> index af55ffe2b7..3b42d39dac 100644
> --- a/libswscale/aarch64/hscale.S
> +++ b/libswscale/aarch64/hscale.S
> @@ -20,7 +20,11 @@
> 
> #include "libavutil/aarch64/asm.S"
> 
> -function ff_hscale_8_to_15_neon, export=1
> +.macro hscale srcbits, dstbits, ldt, lds, c
> +function ff_hscale_\srcbits\()_to_\dstbits\()_neon, export=1
> +.if \dstbits >= 16
> +        movi                v20.4S, #(0x1 << (\dstbits - 16)), msl #16
> +.endif
>         sbfiz               x7, x6, #1, #32             // filterSize*2 (*2 because int16)
> 1:      ldr                 w8, [x5], #4                // filterPos[idx]
>         ldr                 w0, [x5], #4                // filterPos[idx + 1]
> @@ -34,30 +38,30 @@ function ff_hscale_8_to_15_neon, export=1
>         movi                v1.2D, #0                   // val sum part 2 (for dst[1])
>         movi                v2.2D, #0                   // val sum part 3 (for dst[2])
>         movi                v3.2D, #0                   // val sum part 4 (for dst[3])
> -        add                 x17, x3, w8, UXTW           // srcp + filterPos[0]
> -        add                 x8,  x3, w0, UXTW           // srcp + filterPos[1]
> -        add                 x0, x3, w11, UXTW           // srcp + filterPos[2]
> -        add                 x11, x3, w9, UXTW           // srcp + filterPos[3]
> +        add                 x17, x3, w8, UXTW #!!(\srcbits > 8) // srcp + filterPos[0]
> +        add                 x8,  x3, w0, UXTW #!!(\srcbits > 8) // srcp + filterPos[1]
> +        add                 x0, x3, w11, UXTW #!!(\srcbits > 8) // srcp + filterPos[2]
> +        add                 x11, x3, w9, UXTW #!!(\srcbits > 8) // srcp + filterPos[3]

This construct breaks with llvm's assembler and armasm64 - they don't 
evaluate !! here, ending up with errors like these:

<instantiation>:19:31: error: expected integer shift amount
         add x8, x3, w0, UXTW #!!(8 > 8)

libswscale\aarch64\hscale.o.asm(3093) 
: error A2007: wrong operand type for :LNOT:
         add                 x17, x3, w8, UXTW #!!0

While less elegant, I guess this can be handled easily by adding a macro 
parameter that represents the evaluated value of \srcbits > 8.


>         mov                 w15, w6                     // filterSize counter
> -2:      ld1                 {v4.8B}, [x17], #8          // srcp[filterPos[0] + {0..7}]
> +2:      ld1                 {v4.\ldt}, [x17], \lds      // srcp[filterPos[0] + {0..7}]
>         ld1                 {v5.8H}, [x16], #16         // load 8x16-bit filter values, part 1
> -        ld1                 {v6.8B}, [x8], #8           // srcp[filterPos[1] + {0..7}]
> +        ld1                 {v6.\ldt}, [x8], \lds       // srcp[filterPos[1] + {0..7}]
>         ld1                 {v7.8H}, [x12], #16         // load 8x16-bit at filter+filterSize
> -        uxtl                v4.8H, v4.8B                // unpack part 1 to 16-bit
> +\c\c    uxtl                v4.8H, v4.8B                // unpack part 1 to 16-bit

With gas-preprocessor and armasm64, // isn't considered a comment char by 
armasm64, only by the C preprocessor invoked by gas-preprocessor, so it 
doesn't strip out these lines properly. I guess one could add more code to 
gas-preprocessor to handle that, but that's probably a bit overkill...

Adding .if .endif around these instances isn't entirely elegant, but you 
can also make e.g. a macro uxtl_if, which takes a third parameter which is 
a predicate for whether the instruction should be included or not.

>         smlal               v0.4S, v4.4H, v5.4H         // v0 accumulates srcp[filterPos[0] + {0..3}] * filter[{0..3}]
>         smlal2              v0.4S, v4.8H, v5.8H         // v0 accumulates srcp[filterPos[0] + {4..7}] * filter[{4..7}]
> -        ld1                 {v16.8B}, [x0], #8          // srcp[filterPos[2] + {0..7}]
> +        ld1                 {v16.\ldt}, [x0], \lds      // srcp[filterPos[2] + {0..7}]

LLVM's assembler had a bug regarding passing parameters like "8h" as a 
parameter to a macro, which was only fixed in LLVM 8, see 
https://bugs.llvm.org/show_bug.cgi?id=32973.

That bug is easy to avoid by moving the dot into the macro argument, i.e. 
making this "ld1 {v16\ldt}, ..." and passing ".8h" as macro argument.

Additionally - we do have a checkasm test for this function, but not for 
these bitdepth combinations. It'd be great to extend the test to test 
these combinations as well - I'd prefer to not add much more assembly 
without a corresponding checkasm test.

// Martin


More information about the ffmpeg-devel mailing list