On Mon, 13 Jan 2014, Janne Grunau wrote:
On 2014-01-13 16:33:43 +0200, Martin Storsjö wrote:
On Sat, 11 Jan 2014, Janne Grunau wrote:
Ported from ARMv7 NEON.
---
libavcodec/aarch64/h264dsp_init_aarch64.c | 25 +++
libavcodec/aarch64/h264dsp_neon.S | 266 ++++++++++++++++++++++++++++++
2 files changed, 291 insertions(+)
diff --git a/libavcodec/aarch64/h264dsp_neon.S
b/libavcodec/aarch64/h264dsp_neon.S
index 777ac01..2c47f21 100644
--- a/libavcodec/aarch64/h264dsp_neon.S
+++ b/libavcodec/aarch64/h264dsp_neon.S
@@ -259,3 +259,269 @@ function ff_h264_h_loop_filter_chroma_neon, export=1
ret
endfunc
+
+.macro biweight_16 macs, macd
+ dup v0.16B, w5
+ dup v1.16B, w6
+ mov v4.16B, v16.16B
+ mov v6.16B, v16.16B
+1: subs w3, w3, #2
+ ld1 {v20.16B}, [x0], x2
+ \macd v4.8H, v0.8B, v20.8B
+ //pld [r0]
+ \macd\()2 v6.8H, v0.16B, v20.16B
+ ld1 {v22.16B}, [x1], x2
+ \macs v4.8H, v1.8B, v22.8B
+ //pld [r1]
This looks like leftovers - any plan to either strip them out or use
prfm?
yes, leftover, forgot to change them to prfm and test
+
+/*
+void ff_biweight_h264_pixels_16_neon(uint8_t *dst, uint8_t *src, int stride,
+ int height, int log2_den, int weightd,
+ int weights, int offset);
+*/
+.macro biweight_func w
gas-preprocessor can't strip out these multiline comments, right? This
might probably work just fine here, but in general gas-pp kinda relies
on the fact that the comments are stripped out originally. Some of the
function prototypes in the existing arm asm source make gas-pp misbehave
when they use the word 'const' which is also a macro, unless these
comments are stripped out early.
It builds fine otherwise I would have remembered to remove them after
the function was working as expected.
Yes, obviously - I mostly meant that this might cause problems later if
someone (who doesn't use/check gas-pp regularly) tries to add a similar
comment which contains macros that cause problems. But even I try to add
the word const here I can't trigger the same issue as for normal arm if I
comment out the "remove all comments" part of gas-pp. So I we can
disregard this until an actual concrete issue pops up, if ever.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
