paddq is an SSE2 instruction so it cannot be used for MMX.
This was probably just a typo because the sums are dwords anyway.
Reviewed-by: Pascal Massimino <pascal.massimino@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
integration by Neil Birkbeck, with help from Vitor Sessak.
core SSE2 loop by Skal (pascal.massimino@gmail.com)
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
And use the x86util ones instead, which are optimized for mmxext/sse2.
About ~1% increase in performance on pre SSSE3 processors.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This makes C and MMX match, no change to fate as the differences where
apparently not sufficient to show up in fate
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Those macros take a byte number as shift argument, as this argument
differs between MMX and SSE2 instructions.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit a87b17f328.
This reduces the amount of non LGPL code, making a relicensing to LGPL
easier
Conflicts:
libavfilter/vf_yadif.c
libavfilter/x86/yadif.c
libavfilter/x86/yadif_template.c
libavfilter/yadif.h
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit fc5fe4804fd2ee9a29de502e9431b12d027c0c89, reversing
changes made to ffe3350098.
The factoring is broken; it's not calling the ssse3 code anymore, and
calling the mmx2 code with bad alignment. It also broke some FATE
instances.
Conflicts:
libavfilter/x86/vf_gradfun_init.c
Always use the special filter for the first and last 3 columns (only).
Changes made in 64ed397 slowed the filter to just under 3/4 of what it
was. This commit restores the speed while maintaining identical output.
For reference, on my Athlon64:
1733222 decicycles in old
2358563 decicycles in new
1727558 decicycles in this
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Current code divides before increasing precision.
Also reduce upper bound for strength from 255 to 64. This will prevent
an overflow in the SSSE3 and MMX filter_line code: delta is expressed as
an u16 being shifted by 2 to the left. If it overflows, having a
strength not above 64 will make sure that m is set to 0 (making the
m*m*delta >> 14 expression void).
A value above 64 should not make any sense unless gradfun is used as
a blur filter.
Signed-off-by: Anton Khirnov <anton@khirnov.net>