Altivec can only load naturally aligned vectors. To handle possibly
unaligned data a second vector is loaded from an offset of the original
location and the data is recovered through a vector permutation.
Overreads are minimal if the offset for second load points to the last
element of data. This is 7 for loading eight 8-bit pixels and overreads
are reduced from 16 bytes to 8 bytes if the pixels are 64-bit aligned.
For unaligned pixels the overread is reduced from 23 bytes to 15 bytes
in the worst case.
* commit 'a03a642d5ceb5f2f7c6ebbf56ff365dfbcdb65eb':
h264: do not use 422 functions for monochrome
See: 07abf13da4
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a6b650118543e1580e872896d8976042b7c32d01':
ppc: cosmetics: Consistently format CPU flag detection invocations
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f61bece684d9685b07895508e6c1c733b5564ccf':
ppc: Add and use convenience macro to check for AltiVec availability
Conflicts:
libavcodec/ppc/dsputil_ppc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Implicit vector loads on POWER7 hardware can use the VSX
instruction set instead of classic Altivec/VMX. Let's force
a VMX load in this case.
Signed-off-by: Martin Storsjö <martin@martin.st>
* qatar/master:
Consistently use "cpu_flags" as variable/parameter name for CPU flags
Conflicts:
libavcodec/x86/dsputil_init.c
libavcodec/x86/h264dsp_init.c
libavcodec/x86/hpeldsp_init.c
libavcodec/x86/motion_est.c
libavcodec/x86/mpegvideo.c
libavcodec/x86/proresdsp_init.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
arm: Only output eabi attributes if building for ELF
fix scalarproduct_and_madd_int16_altivec() for orders > 16
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It was previously declared as int.
Does not change fate results for x86.
Conflicts:
libavcodec/ppc/fmtconvert_altivec.c
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7f75f2f2bd692857c1c1ca7f414eb30ece3de93d':
ppc: Drop unnecessary ff_ name prefixes from static functions
x86: Drop unnecessary ff_ name prefixes from static functions
arm: Drop unnecessary ff_ name prefixes from static functions
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '42b9150b0d4f0a130c1d93dc991fd5412743a8cf':
fft: Remove pointless #ifdefs around function declarations
ppc: Move AltiVec utility headers out of AltiVec ifdefs
Conflicts:
libavcodec/fft.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6b110d3a739c31602b59887ad65c67025df3f49d':
ppc: More consistent names for H.264 optimizations files
mpegaudiosp: More consistent names for ppc/x86 optimization files
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This way, the special IDCT permutations are no longer needed. This
is similar to how H264 does it, and removes the dsputil dependency
imposed by the scantable code.
Also remove the unused type == 0 cases from the plain C version
of the idct.
Signed-off-by: Martin Storsjö <martin@martin.st>
The non-intra-pcm branch in hl_decode_mb (simple, 8bpp) goes from 700
to 672 cycles, and the complete loop of decode_mb_cabac and hl_decode_mb
(in the decode_slice loop) goes from 1759 to 1733 cycles on the clip
tested (cathedral), i.e. almost 30 cycles per mb faster.
Signed-off-by: Martin Storsjö <martin@martin.st>
This way, the special IDCT permutations are no longer needed. Bfin code
is disabled until someone updates it. This is similar to how H264 does
it, and removes the dsputil dependency imposed by the scantable code.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The non-intra-pcm branch in hl_decode_mb (simple, 8bpp) goes from 700
to 672 cycles, and the complete loop of decode_mb_cabac and hl_decode_mb
(in the decode_slice loop) goes from 1759 to 1733 cycles on the clip
tested (cathedral), i.e. almost 30 cycles per mb faster.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
