On Mon, 11 Jan 2021, reimar.doeffin...@gmx.de wrote:
From: Reimar Döffinger <reimar.doeffin...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
