Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
Hi Martin! > On 10 Feb 2021, at 22:53, Martin Storsjö wrote: > > +.macro idct_16x16 bitdepth > +function ff_hevc_idct_16x16_\bitdepth\()_neon, export=1 > +//r0 - coeffs > +mov x15, lr > + Binutils doesn't recognize "lr" as alias for x30 >>> It didn’t have an issue in the Debian unstable VM? >>> That seems like the kind of workaround where it would be >>> better to leave a comment with more info, if you know >>> what exactly is affected. >> >> Binutils 2.28 doesn't recognize "lr" while 2.30 does, it seems. >> >> FWIW, all the existing aarch64 assembly just uses "x30" to refer to this >> register, none of it uses "lr". > > Do you want to follow up on this patch? IIRC changing it to use "x30" instead > of "lr" was the only blocker from my point of view (and the add_residual > patch that goes on top of it was mostly fine as well)? Sorry, I forgot about that comment when I sent the last revision. Josh has been doing some polishing of these patches, so unless I hear otherwise I’ll assume he’s volunteering to do these minor fixes (thanks in advance), otherwise we just end up stepping on each other’s toes. But I am around in principle and will if necessary help out getting it merged. Best regards, Reimar ___ 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".
Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
Hi Reimar, On Sat, 16 Jan 2021, Martin Storsjö wrote: +.macro idct_16x16 bitdepth +function ff_hevc_idct_16x16_\bitdepth\()_neon, export=1 +//r0 - coeffs +mov x15, lr + Binutils doesn't recognize "lr" as alias for x30 It didn’t have an issue in the Debian unstable VM? That seems like the kind of workaround where it would be better to leave a comment with more info, if you know what exactly is affected. Binutils 2.28 doesn't recognize "lr" while 2.30 does, it seems. FWIW, all the existing aarch64 assembly just uses "x30" to refer to this register, none of it uses "lr". Do you want to follow up on this patch? IIRC changing it to use "x30" instead of "lr" was the only blocker from my point of view (and the add_residual patch that goes on top of it was mostly fine as well)? // 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".
Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
On Sat, 16 Jan 2021, Reimar Döffinger wrote:
On 15 Jan 2021, at 23:55, Martin Storsjö wrote:
On Tue, 12 Jan 2021, reimar.doeffin...@gmx.de wrote:
create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S
create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c
This patch fails checkasm
Fixed, one mis-translated coefficient index...
Ok, good.
+.macro fixsqrshrn d, dt, n, m
+ .ifc \dt, .8H
+sqrshrn2\d\dt, \n\().4S, \m
+ .else
+sqrshrn \n\().4H, \n\().4S, \m
+mov \d\().D[0], \n\().D[0]
+ .endif
+.endm
Is this to set the lower half of the dest register, without wiping the upper
part? It looks a bit clumsy (and stall-prone on in-order cores), but I guess
it's not easy to do things differently without rewriting the higher level
structure?
Did not have a good idea, but I was also aiming for keeping the structure of
the 32-bit and 64-bit code similar.
In particular since I did not know about checkasm and expected some further
painful debug.
+.macro transpose_8x8 r0, r1, r2, r3, r4, r5, r6, r7
+transpose8_4x4 \r0, \r1, \r2, \r3
+transpose8_4x4 \r4, \r5, \r6, \r7
+.endm
+
There's a bunch of existing transposes in libavcodec/aarch64/neon.S - can they
be used? Not that they're rocket science, though... And I see that the existing
arm version also has got its own transpose macros.
If it's inconvenient to use shared macros, this is fine.
They are different and seem to not be documented, so it would take some
time to figure out how to replace them.
There’s also a bit of a question if I’d want to give up alignment
with the 32-bit code just yet.
Sure - one doesn't have to give up on matching the overall structure, but
it doesn't necessarily need to stay 1:1 on the individual instruction
level, if things are done more efficiently in one way or another on the
other architecture. Not saying that these are more or less efficient; a
transpose usually is the same anyway, but the aarch64 macros take a number
of more temp regs as arguments.
+// Transpose each 4x4 block, and swap how d4-d7 and d8-d11 are used.
+// Layout before:
+// d0 d1
+// d2 d3
+// d4 d5
+// d6 d7
+// d8 d9
+// d10 d11
+// d12 d13
+// d14 d15
These layouts don't look like they're up to date for the aarch64 version?
Removed in new version as it seems not that useful.
+vst1.s32{\in7}, [r3, :128]
+.endm
This is left behind untranslated (and thus unused)
Removed. I am not sure if that means it’s also unused in the 32-bit version.
Possibly - a patch for removing that, if it is, would be good too.
+
+movrel x1, trans + 16
The movrel macro has got a separate third optional argument for the offset, so write this
"movrel x1, trans, 16". (Older versions of llvm are picky with the symbol
offset syntax and break with this, as the macro right now adds its own implicit +(0)
here. If you pass the offset in the macro parameter, all the offsets get passed within
the parentheses.
Changed.
+.macro idct_16x16 bitdepth
+function ff_hevc_idct_16x16_\bitdepth\()_neon, export=1
+//r0 - coeffs
+mov x15, lr
+
Binutils doesn't recognize "lr" as alias for x30
It didn’t have an issue in the Debian unstable VM?
That seems like the kind of workaround where it would be
better to leave a comment with more info, if you know
what exactly is affected.
Binutils 2.28 doesn't recognize "lr" while 2.30 does, it seems.
FWIW, all the existing aarch64 assembly just uses "x30" to refer to this
register, none of it uses "lr".
// 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".
Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
> On 15 Jan 2021, at 23:55, Martin Storsjö wrote:
>
> On Tue, 12 Jan 2021, reimar.doeffin...@gmx.de wrote:
>
>> create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S
>> create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c
>
> This patch fails checkasm
Fixed, one mis-translated coefficient index...
>>
>> +.macro fixsqrshrn d, dt, n, m
>> + .ifc \dt, .8H
>> +sqrshrn2\d\dt, \n\().4S, \m
>> + .else
>> +sqrshrn \n\().4H, \n\().4S, \m
>> +mov \d\().D[0], \n\().D[0]
>> + .endif
>> +.endm
>
> Is this to set the lower half of the dest register, without wiping the upper
> part? It looks a bit clumsy (and stall-prone on in-order cores), but I guess
> it's not easy to do things differently without rewriting the higher level
> structure?
Did not have a good idea, but I was also aiming for keeping the structure of
the 32-bit and 64-bit code similar.
In particular since I did not know about checkasm and expected some further
painful debug.
>
>> +.macro transpose_8x8 r0, r1, r2, r3, r4, r5, r6, r7
>> +transpose8_4x4 \r0, \r1, \r2, \r3
>> +transpose8_4x4 \r4, \r5, \r6, \r7
>> +.endm
>> +
>
> There's a bunch of existing transposes in libavcodec/aarch64/neon.S - can
> they be used? Not that they're rocket science, though... And I see that the
> existing arm version also has got its own transpose macros.
>
> If it's inconvenient to use shared macros, this is fine.
They are different and seem to not be documented, so it would take some
time to figure out how to replace them.
There’s also a bit of a question if I’d want to give up alignment
with the 32-bit code just yet.
>
>> +// Transpose each 4x4 block, and swap how d4-d7 and d8-d11 are used.
>> +// Layout before:
>> +// d0 d1
>> +// d2 d3
>> +// d4 d5
>> +// d6 d7
>> +// d8 d9
>> +// d10 d11
>> +// d12 d13
>> +// d14 d15
>
> These layouts don't look like they're up to date for the aarch64 version?
Removed in new version as it seems not that useful.
>>
>> +vst1.s32{\in7}, [r3, :128]
>> +.endm
>
> This is left behind untranslated (and thus unused)
Removed. I am not sure if that means it’s also unused in the 32-bit version.
>> +
>> +movrel x1, trans + 16
>
> The movrel macro has got a separate third optional argument for the offset,
> so write this "movrel x1, trans, 16". (Older versions of llvm are picky with
> the symbol offset syntax and break with this, as the macro right now adds its
> own implicit +(0) here. If you pass the offset in the macro parameter, all
> the offsets get passed within the parentheses.
Changed.
>> +.macro idct_16x16 bitdepth
>> +function ff_hevc_idct_16x16_\bitdepth\()_neon, export=1
>> +//r0 - coeffs
>> +mov x15, lr
>> +
>
> Binutils doesn't recognize "lr" as alias for x30
It didn’t have an issue in the Debian unstable VM?
That seems like the kind of workaround where it would be
better to leave a comment with more info, if you know
what exactly is affected.
___
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".
[FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
From: Reimar Döffinger Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth available on aarch64. For a UHD HDR (10 bit) sample video these were consuming the most time and this optimization reduced overall decode time from 19.4s to 16.4s, approximately 15% speedup. Test sample was the first 300 frames of "LG 4K HDR Demo - New York.ts", running on Apple M1. --- libavcodec/aarch64/Makefile | 2 + libavcodec/aarch64/hevcdsp_idct_neon.S| 380 ++ libavcodec/aarch64/hevcdsp_init_aarch64.c | 45 +++ libavcodec/hevcdsp.c | 2 + libavcodec/hevcdsp.h | 1 + 5 files changed, 430 insertions(+) create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile index f6434e40da..2ea1d74a38 100644 --- a/libavcodec/aarch64/Makefile +++ b/libavcodec/aarch64/Makefile @@ -61,3 +61,5 @@ NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o \ aarch64/vp9lpf_neon.o \ aarch64/vp9mc_16bpp_neon.o \ aarch64/vp9mc_neon.o +NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_idct_neon.o \ + aarch64/hevcdsp_init_aarch64.o diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S b/libavcodec/aarch64/hevcdsp_idct_neon.S new file mode 100644 index 00..4aac205e22 --- /dev/null +++ b/libavcodec/aarch64/hevcdsp_idct_neon.S @@ -0,0 +1,380 @@ +/* + * ARM NEON optimised IDCT functions for HEVC decoding + * Copyright (c) 2014 Seppo Tomperi + * Copyright (c) 2017 Alexandra Hájková + * + * Ported from arm/hevcdsp_idct_neon.S by + * Copyright (c) 2020 Reimar Döffinger + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "libavutil/aarch64/asm.S" + +const trans, align=4 +.short 64, 83, 64, 36 +.short 89, 75, 50, 18 +.short 90, 87, 80, 70 +.short 57, 43, 25, 9 +.short 90, 90, 88, 85 +.short 82, 78, 73, 67 +.short 61, 54, 46, 38 +.short 31, 22, 13, 4 +endconst + +.macro sum_sub out, in, c, op, p + .ifc \op, + +smlal\p \out, \in, \c + .else +smlsl\p \out, \in, \c + .endif +.endm + +.macro fixsqrshrn d, dt, n, m + .ifc \dt, .8H +sqrshrn2\d\dt, \n\().4S, \m + .else +sqrshrn \n\().4H, \n\().4S, \m +mov \d\().D[0], \n\().D[0] + .endif +.endm + +// uses and clobbers v28-v31 as temp registers +.macro tr_4x4_8 in0, in1, in2, in3, out0, out1, out2, out3, p1, p2 + sshll\p1 v28.4S, \in0, #6 + movv29.16B, v28.16B + smull\p1 v30.4S, \in1, v0.H[1] + smull\p1 v31.4S, \in1, v0.H[3] + smlal\p2 v28.4S, \in2, v0.H[0] //e0 + smlsl\p2 v29.4S, \in2, v0.H[0] //e1 + smlal\p2 v30.4S, \in3, v0.H[3] //o0 + smlsl\p2 v31.4S, \in3, v0.H[1] //o1 + + add\out0, v28.4S, v30.4S + add\out1, v29.4S, v31.4S + sub\out2, v29.4S, v31.4S + sub\out3, v28.4S, v30.4S +.endm + +.macro transpose8_4x4 r0, r1, r2, r3 +trn1v2.8H, \r0\().8H, \r1\().8H +trn2v3.8H, \r0\().8H, \r1\().8H +trn1v4.8H, \r2\().8H, \r3\().8H +trn2v5.8H, \r2\().8H, \r3\().8H +trn1\r0\().4S, v2.4S, v4.4S +trn2\r2\().4S, v2.4S, v4.4S +trn1\r1\().4S, v3.4S, v5.4S +trn2\r3\().4S, v3.4S, v5.4S +.endm + +.macro transpose_8x8 r0, r1, r2, r3, r4, r5, r6, r7 +transpose8_4x4 \r0, \r1, \r2, \r3 +transpose8_4x4 \r4, \r5, \r6, \r7 +.endm + +.macro tr_8x4 shift, in0,in0t, in1,in1t, in2,in2t, in3,in3t, in4,in4t, in5,in5t, in6,in6t, in7,in7t, p1, p2 +tr_4x4_8\in0\in0t, \in2\in2t, \in4\in4t, \in6\in6t, v24.4S, v25.4S, v26.4S, v27.4S, \p1, \p2 + +smull\p1v30.4S, \in1\in1t, v0.H[6] +smull\p1
Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
On Tue, 12 Jan 2021, reimar.doeffin...@gmx.de wrote: From: Reimar Döffinger Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth available on aarch64. For a UHD HDR (10 bit) sample video these were consuming the most time and this optimization reduced overall decode time from 19.4s to 16.4s, approximately 15% speedup. Test sample was the first 300 frames of "LG 4K HDR Demo - New York.ts", running on Apple M1. --- libavcodec/aarch64/Makefile | 2 + libavcodec/aarch64/hevcdsp_idct_neon.S| 423 ++ libavcodec/aarch64/hevcdsp_init_aarch64.c | 45 +++ libavcodec/hevcdsp.c | 2 + libavcodec/hevcdsp.h | 1 + 5 files changed, 473 insertions(+) create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c This patch fails checkasm diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile index f6434e40da..2ea1d74a38 100644 --- a/libavcodec/aarch64/Makefile +++ b/libavcodec/aarch64/Makefile @@ -61,3 +61,5 @@ NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o \ aarch64/vp9lpf_neon.o \ aarch64/vp9mc_16bpp_neon.o \ aarch64/vp9mc_neon.o +NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_idct_neon.o \ + aarch64/hevcdsp_init_aarch64.o diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S b/libavcodec/aarch64/hevcdsp_idct_neon.S new file mode 100644 index 00..6b42f6ca3a --- /dev/null +++ b/libavcodec/aarch64/hevcdsp_idct_neon.S @@ -0,0 +1,423 @@ +/* + * ARM NEON optimised IDCT functions for HEVC decoding + * Copyright (c) 2014 Seppo Tomperi + * Copyright (c) 2017 Alexandra Hájková + * + * Ported from arm/hevcdsp_idct_neon.S by + * Copyright (c) 2020 Reimar Döffinger + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "libavutil/aarch64/asm.S" + +const trans, align=4 +.short 64, 83, 64, 36 +.short 89, 75, 50, 18 +.short 90, 87, 80, 70 +.short 57, 43, 25, 9 +.short 90, 90, 88, 85 +.short 82, 78, 73, 67 +.short 61, 54, 46, 38 +.short 31, 22, 13, 4 +endconst + +.macro sum_sub out, in, c, op, p + .ifc \op, + +smlal\p \out, \in, \c + .else +smlsl\p \out, \in, \c + .endif +.endm + +.macro fixsqrshrn d, dt, n, m + .ifc \dt, .8H +sqrshrn2\d\dt, \n\().4S, \m + .else +sqrshrn \n\().4H, \n\().4S, \m +mov \d\().D[0], \n\().D[0] + .endif +.endm Is this to set the lower half of the dest register, without wiping the upper part? It looks a bit clumsy (and stall-prone on in-order cores), but I guess it's not easy to do things differently without rewriting the higher level structure? + +// uses and clobbers v28-v31 as temp registers +.macro tr_4x4_8 in0, in1, in2, in3, out0, out1, out2, out3, p1, p2 + sshll\p1 v28.4S, \in0, #6 + movv29.16B, v28.16B + smull\p1 v30.4S, \in1, v0.H[1] + smull\p1 v31.4S, \in1, v0.H[3] + smlal\p2 v28.4S, \in2, v0.H[0] //e0 + smlsl\p2 v29.4S, \in2, v0.H[0] //e1 + smlal\p2 v30.4S, \in3, v0.H[3] //o0 + smlsl\p2 v31.4S, \in3, v0.H[1] //o1 + + add\out0, v28.4S, v30.4S + add\out1, v29.4S, v31.4S + sub\out2, v29.4S, v31.4S + sub\out3, v28.4S, v30.4S +.endm + +.macro transpose8_4x4 r0, r1, r2, r3 +trn1v2.8H, \r0\().8H, \r1\().8H +trn2v3.8H, \r0\().8H, \r1\().8H +trn1v4.8H, \r2\().8H, \r3\().8H +trn2v5.8H, \r2\().8H, \r3\().8H +trn1\r0\().4S, v2.4S, v4.4S +trn2\r2\().4S, v2.4S, v4.4S +trn1\r1\().4S, v3.4S, v5.4S +trn2\r3\().4S, v3.4S, v5.4S +.endm + +.macro transpose_8x8 r0, r1, r2, r3, r4, r5, r6, r7 +transpose8_4x4 \r0, \r1, \r2, \r3 +transpose8_4x4
Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
On Tue, 12 Jan 2021, Reimar Döffinger wrote: On 12 Jan 2021, at 13:24, Josh Dekker wrote: Hi, AS libavcodec/aarch64/hevcdsp_idct_neon.o libavcodec/aarch64/hevcdsp_idct_neon.S: Assembler messages: libavcodec/aarch64/hevcdsp_idct_neon.S:418: Error: operand mismatch -- `mov v29.4S,v28.4S' Yes, I noticed that a few days ago, I sent the fixed version now. I had only tested on Apple assembler, assuming it would be the same. Really stupid behaviour by the GNU one, as if the type mattered for a mov instruction, needlessly complicates macros. Yes, this particular restriction is a bit annoying, but there's also a number of other cases, with assembly constructs that are accepted by GAS but not supported by LLVM/Clang, like "umov w0, v0.4h[0]" (where the canonical form, that LLVM supports, is "umov w0, v0.h[0]"). If you just test your code with one tool, there's always a possibility of these slipping in, but by testing with more than one tool (either proactively by the developer, or by a reviewer, or ultimately by FATE) one can pick up on such issues, and in practice, all common tools (GAS, LLVM, and armasm64) usually support the canonical spellings of instructions. (See my other reply about explanations around the fact that armasm64, while it uses a different syntax for directives, still can build all of our assembly thanks to the gas-preprocessor tool.) // 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".
Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
> On 12 Jan 2021, at 13:24, Josh Dekker wrote: > > Hi, > > On 2021-01-08 21:36, reimar.doeffin...@gmx.de wrote: >> From: Reimar Döffinger >> Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth >> available on aarch64. >> For a UHD HDR (10 bit) sample video these were consuming the most time >> and this optimization reduced overall decode time from 19.4s to 16.4s, >> approximately 15% speedup. >> Test sample was the first 300 frames of "LG 4K HDR Demo - New York.ts", >> running on Apple M1. >> --- >> libavcodec/aarch64/Makefile | 2 + >> libavcodec/aarch64/hevcdsp_idct_neon.S| 426 ++ >> libavcodec/aarch64/hevcdsp_init_aarch64.c | 45 +++ >> libavcodec/hevcdsp.c | 2 + >> libavcodec/hevcdsp.h | 1 + >> 5 files changed, 476 insertions(+) >> create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S >> create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c >> [...] > > ASlibavcodec/aarch64/hevcdsp_idct_neon.o > libavcodec/aarch64/hevcdsp_idct_neon.S: Assembler messages: > libavcodec/aarch64/hevcdsp_idct_neon.S:418: Error: operand mismatch -- `mov > v29.4S,v28.4S' Yes, I noticed that a few days ago, I sent the fixed version now. I had only tested on Apple assembler, assuming it would be the same. Really stupid behaviour by the GNU one, as if the type mattered for a mov instruction, needlessly complicates macros. >> Thanks for porting this, I was in the process of writing HEVC > assembly (see my set on the ML) and would be interested to rebase this on top > of that set. Sorry, I had not seen that as I’ve only recently started reading the list (well, only my threads to be honest). Hope I’ve not duplicated/complicated any of your work, I was mostly just interested in learning something new, otherwise I would have checked first for related work. Thanks for the interest, Reimar ___ 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".
[FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
From: Reimar Döffinger Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth available on aarch64. For a UHD HDR (10 bit) sample video these were consuming the most time and this optimization reduced overall decode time from 19.4s to 16.4s, approximately 15% speedup. Test sample was the first 300 frames of "LG 4K HDR Demo - New York.ts", running on Apple M1. --- libavcodec/aarch64/Makefile | 2 + libavcodec/aarch64/hevcdsp_idct_neon.S| 423 ++ libavcodec/aarch64/hevcdsp_init_aarch64.c | 45 +++ libavcodec/hevcdsp.c | 2 + libavcodec/hevcdsp.h | 1 + 5 files changed, 473 insertions(+) create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile index f6434e40da..2ea1d74a38 100644 --- a/libavcodec/aarch64/Makefile +++ b/libavcodec/aarch64/Makefile @@ -61,3 +61,5 @@ NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o \ aarch64/vp9lpf_neon.o \ aarch64/vp9mc_16bpp_neon.o \ aarch64/vp9mc_neon.o +NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_idct_neon.o \ + aarch64/hevcdsp_init_aarch64.o diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S b/libavcodec/aarch64/hevcdsp_idct_neon.S new file mode 100644 index 00..6b42f6ca3a --- /dev/null +++ b/libavcodec/aarch64/hevcdsp_idct_neon.S @@ -0,0 +1,423 @@ +/* + * ARM NEON optimised IDCT functions for HEVC decoding + * Copyright (c) 2014 Seppo Tomperi + * Copyright (c) 2017 Alexandra Hájková + * + * Ported from arm/hevcdsp_idct_neon.S by + * Copyright (c) 2020 Reimar Döffinger + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "libavutil/aarch64/asm.S" + +const trans, align=4 +.short 64, 83, 64, 36 +.short 89, 75, 50, 18 +.short 90, 87, 80, 70 +.short 57, 43, 25, 9 +.short 90, 90, 88, 85 +.short 82, 78, 73, 67 +.short 61, 54, 46, 38 +.short 31, 22, 13, 4 +endconst + +.macro sum_sub out, in, c, op, p + .ifc \op, + +smlal\p \out, \in, \c + .else +smlsl\p \out, \in, \c + .endif +.endm + +.macro fixsqrshrn d, dt, n, m + .ifc \dt, .8H +sqrshrn2\d\dt, \n\().4S, \m + .else +sqrshrn \n\().4H, \n\().4S, \m +mov \d\().D[0], \n\().D[0] + .endif +.endm + +// uses and clobbers v28-v31 as temp registers +.macro tr_4x4_8 in0, in1, in2, in3, out0, out1, out2, out3, p1, p2 + sshll\p1 v28.4S, \in0, #6 + movv29.16B, v28.16B + smull\p1 v30.4S, \in1, v0.H[1] + smull\p1 v31.4S, \in1, v0.H[3] + smlal\p2 v28.4S, \in2, v0.H[0] //e0 + smlsl\p2 v29.4S, \in2, v0.H[0] //e1 + smlal\p2 v30.4S, \in3, v0.H[3] //o0 + smlsl\p2 v31.4S, \in3, v0.H[1] //o1 + + add\out0, v28.4S, v30.4S + add\out1, v29.4S, v31.4S + sub\out2, v29.4S, v31.4S + sub\out3, v28.4S, v30.4S +.endm + +.macro transpose8_4x4 r0, r1, r2, r3 +trn1v2.8H, \r0\().8H, \r1\().8H +trn2v3.8H, \r0\().8H, \r1\().8H +trn1v4.8H, \r2\().8H, \r3\().8H +trn2v5.8H, \r2\().8H, \r3\().8H +trn1\r0\().4S, v2.4S, v4.4S +trn2\r2\().4S, v2.4S, v4.4S +trn1\r1\().4S, v3.4S, v5.4S +trn2\r3\().4S, v3.4S, v5.4S +.endm + +.macro transpose_8x8 r0, r1, r2, r3, r4, r5, r6, r7 +transpose8_4x4 \r0, \r1, \r2, \r3 +transpose8_4x4 \r4, \r5, \r6, \r7 +.endm + +.macro tr_8x4 shift, in0,in0t, in1,in1t, in2,in2t, in3,in3t, in4,in4t, in5,in5t, in6,in6t, in7,in7t, p1, p2 +tr_4x4_8\in0\in0t, \in2\in2t, \in4\in4t, \in6\in6t, v24.4S, v25.4S, v26.4S, v27.4S, \p1, \p2 + +smull\p1v30.4S, \in1\in1t, v0.H[6] +smull\p1
Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
Hi, On 2021-01-08 21:36, reimar.doeffin...@gmx.de wrote: From: Reimar Döffinger Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth available on aarch64. For a UHD HDR (10 bit) sample video these were consuming the most time and this optimization reduced overall decode time from 19.4s to 16.4s, approximately 15% speedup. Test sample was the first 300 frames of "LG 4K HDR Demo - New York.ts", running on Apple M1. --- libavcodec/aarch64/Makefile | 2 + libavcodec/aarch64/hevcdsp_idct_neon.S| 426 ++ libavcodec/aarch64/hevcdsp_init_aarch64.c | 45 +++ libavcodec/hevcdsp.c | 2 + libavcodec/hevcdsp.h | 1 + 5 files changed, 476 insertions(+) create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c [...] AS libavcodec/aarch64/hevcdsp_idct_neon.o libavcodec/aarch64/hevcdsp_idct_neon.S: Assembler messages: libavcodec/aarch64/hevcdsp_idct_neon.S:418: Error: operand mismatch -- `mov v29.4S,v28.4S' libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:did you mean this? libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.8b, v28.8b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:other valid variant(s): libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.16b, v28.16b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Error: operand mismatch -- `mov v29.4S,v28.4S' libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:did you mean this? libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.8b, v28.8b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:other valid variant(s): libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.16b, v28.16b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Error: operand mismatch -- `mov v29.4S,v28.4S' libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:did you mean this? libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.8b, v28.8b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:other valid variant(s): libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.16b, v28.16b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Error: operand mismatch -- `mov v29.4S,v28.4S' libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:did you mean this? libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.8b, v28.8b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:other valid variant(s): libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.16b, v28.16b This doesn't build on GNU assembler (GNU Binutils for Ubuntu) 2.34 (aarch64). Thanks for porting this, I was in the process of writing HEVC assembly (see my set on the ML) and would be interested to rebase this on top of that set. -- Josh ___ 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".
[FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
From: Reimar Döffinger Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth available on aarch64. For a UHD HDR (10 bit) sample video these were consuming the most time and this optimization reduced overall decode time from 19.4s to 16.4s, approximately 15% speedup. Test sample was the first 300 frames of "LG 4K HDR Demo - New York.ts", running on Apple M1. --- libavcodec/aarch64/Makefile | 2 + libavcodec/aarch64/hevcdsp_idct_neon.S| 426 ++ libavcodec/aarch64/hevcdsp_init_aarch64.c | 45 +++ libavcodec/hevcdsp.c | 2 + libavcodec/hevcdsp.h | 1 + 5 files changed, 476 insertions(+) create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile index f6434e4..2ea1d74 100644 --- a/libavcodec/aarch64/Makefile +++ b/libavcodec/aarch64/Makefile @@ -61,3 +61,5 @@ NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o \ aarch64/vp9lpf_neon.o \ aarch64/vp9mc_16bpp_neon.o \ aarch64/vp9mc_neon.o +NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_idct_neon.o \ + aarch64/hevcdsp_init_aarch64.o diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S b/libavcodec/aarch64/hevcdsp_idct_neon.S new file mode 100644 index 000..9f67e45 --- /dev/null +++ b/libavcodec/aarch64/hevcdsp_idct_neon.S @@ -0,0 +1,426 @@ +/* + * ARM NEON optimised IDCT functions for HEVC decoding + * Copyright (c) 2014 Seppo Tomperi + * Copyright (c) 2017 Alexandra Hájková + * + * Ported from arm/hevcdsp_idct_neon.S by + * Copyright (c) 2020 Reimar Döffinger + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "libavutil/aarch64/asm.S" + +const trans, align=4 +.short 64, 83, 64, 36 +.short 89, 75, 50, 18 +.short 90, 87, 80, 70 +.short 57, 43, 25, 9 +.short 90, 90, 88, 85 +.short 82, 78, 73, 67 +.short 61, 54, 46, 38 +.short 31, 22, 13, 4 +endconst + +.macro sum_sub out, in, c, op, p + .ifc \op, + +smlal\p \out, \in, \c + .else +smlsl\p \out, \in, \c + .endif +.endm + +.macro fixsqrshrn d, dt, n, m + .ifc \dt, .8H +sqrshrn2\d\dt, \n\().4S, \m + .else +sqrshrn \n\().4H, \n\().4S, \m +mov \d\().D[0], \n\().D[0] + .endif +.endm + +.macro tr_4x4_8 in0, in1, in2, in3, out0, out1, out2, out3, tmp0, tmp1, tmp2, tmp3, p1, p2 + sshll\p1 \tmp0, \in0, #6 + mov\tmp1, \tmp0 + smull\p1 \tmp2, \in1, v0.H[1] + smull\p1 \tmp3, \in1, v0.H[3] + smlal\p2 \tmp0, \in2, v0.H[0] //e0 + smlsl\p2 \tmp1, \in2, v0.H[0] //e1 + smlal\p2 \tmp2, \in3, v0.H[3] //o0 + smlsl\p2 \tmp3, \in3, v0.H[1] //o1 + + add\out0, \tmp0, \tmp2 + add\out1, \tmp1, \tmp3 + sub\out2, \tmp1, \tmp3 + sub\out3, \tmp0, \tmp2 +.endm + +.macro transpose8_4x4 r0, r1, r2, r3 +trn1v2.8H, \r0\().8H, \r1\().8H +trn2v3.8H, \r0\().8H, \r1\().8H +trn1v4.8H, \r2\().8H, \r3\().8H +trn2v5.8H, \r2\().8H, \r3\().8H +trn1\r0\().4S, v2.4S, v4.4S +trn2\r2\().4S, v2.4S, v4.4S +trn1\r1\().4S, v3.4S, v5.4S +trn2\r3\().4S, v3.4S, v5.4S +.endm + +.macro transpose_8x8 r0, r1, r2, r3, r4, r5, r6, r7 +transpose8_4x4 \r0, \r1, \r2, \r3 +transpose8_4x4 \r4, \r5, \r6, \r7 +.endm + +.macro tr_8x4 shift, in0,in0t, in1,in1t, in2,in2t, in3,in3t, in4,in4t, in5,in5t, in6,in6t, in7,in7t, p1, p2 +tr_4x4_8\in0\in0t, \in2\in2t, \in4\in4t, \in6\in6t, v24.4S, v25.4S, v26.4S, v27.4S, v28.4S, v29.4S, v30.4S, v31.4S, \p1, \p2 + +smull\p1v30.4S, \in1\in1t, v0.H[6] +smull\p1v28.4S, \in1\in1t,
