Chiebot-Mirror
/
FFmpeg
mirror of https://github.com/FFmpeg/FFmpeg.git
8
0
Fork 0
Code Issues Projects Releases Wiki Activity

whitespace cosmetics

Browse Source 
Originally committed as revision 27188 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
pull/126/head
Diego Biurrun 17 years ago
parent 7a4d5e174c
commit 4bdc44c7fe
2 changed files with 81 additions and 82 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 53
      libswscale/internal_bfin.S
  2. 70
      libswscale/yuv2rgb_altivec.c

53
libswscale/internal_bfin.S
Unescape View File

@ -24,37 +24,37 @@
/*
YUV420 to RGB565 conversion. This routine takes a YUV 420 planar macroblock
and converts it to RGB565. R:5 bits, G:6 bits, B:5 bits.. packed into shorts
YUV420 to RGB565 conversion. This routine takes a YUV 420 planar macroblock
and converts it to RGB565. R:5 bits, G:6 bits, B:5 bits.. packed into shorts
The following calculation is used for the conversion:
The following calculation is used for the conversion:
r = clipz((y-oy)*cy + crv*(v-128))
g = clipz((y-oy)*cy + cgv*(v-128) + cgu*(u-128))
b = clipz((y-oy)*cy + cbu*(u-128))
y,u,v are pre scaled by a factor of 4 i.e. left shifted to gain precision.
y,u,v are pre scaled by a factor of 4 i.e. left shifted to gain precision.
New factorization to eliminate the truncation error which was
occuring due to the byteop3p.
New factorization to eliminate the truncation error which was
occuring due to the byteop3p.
1) use the bytop16m to subtract quad bytes we use this in U8 this
1) use the bytop16m to subtract quad bytes we use this in U8 this
then so the offsets need to be renormalized to 8bits.
2) scale operands up by a factor of 4 not 8 because Blackfin
2) scale operands up by a factor of 4 not 8 because Blackfin
multiplies include a shift.
3) compute into the accumulators cy*yx0, cy*yx1
3) compute into the accumulators cy*yx0, cy*yx1
4) compute each of the linear equations
r = clipz((y-oy)*cy + crv*(v-128))
4) compute each of the linear equations
r = clipz((y - oy) * cy + crv * (v - 128))
g = clipz((y-oy)*cy + cgv*(v-128) + cgu*(u-128))
g = clipz((y - oy) * cy + cgv * (v - 128) + cgu * (u - 128))
b = clipz((y-oy)*cy + cbu*(u-128))
b = clipz((y - oy) * cy + cbu * (u - 128))
reuse of the accumulators requires that we actually multiply
twice once with addition and the second time with a subtaction.
@ -71,27 +71,26 @@
i2 = cb i3 = cr
i1 = coeff i0 = y
Where coeffs have the following layout in memory.
uint32_t oy,oc,zero,cy,crv,rmask,cbu,bmask,cgu,cgv;
Where coeffs have the following layout in memory.
coeffs is a pointer to oy.
uint32_t oy,oc,zero,cy,crv,rmask,cbu,bmask,cgu,cgv;
the {rgb} masks are only utilized by the 565 packing algorithm. Note the data
replication is used to simplify the internal algorithms for the dual mac architecture
of BlackFin.
coeffs is a pointer to oy.
All routines are exported with _ff_bfin_ as a symbol prefix
the {rgb} masks are only utilized by the 565 packing algorithm. Note the data
replication is used to simplify the internal algorithms for the dual mac architecture
of BlackFin.
rough performance gain compared against -O3:
All routines are exported with _ff_bfin_ as a symbol prefix
2779809/1484290 187.28%
rough performance gain compared against -O3:
which translates to ~33c/pel to ~57c/pel for the reference vs 17.5
c/pel for the optimized implementations. Not sure why there is such a
huge variation on the reference codes on Blackfin I guess it must have
to do with the memory system.
2779809/1484290 187.28%
which translates to ~33c/pel to ~57c/pel for the reference vs 17.5
c/pel for the optimized implementations. Not sure why there is such a
huge variation on the reference codes on Blackfin I guess it must have
to do with the memory system.
*/
#define mL3 .text

70
libswscale/yuv2rgb_altivec.c
Unescape View File

@ -21,63 +21,63 @@
*/
/*
convert I420 YV12 to RGB in various formats,
convert I420 YV12 to RGB in various formats,
it rejects images that are not in 420 formats
it rejects images that don't have widths of multiples of 16
it rejects images that don't have heights of multiples of 2
reject defers to C simulation codes.
reject defers to C simulation codes.
lots of optimizations to be done here
lots of optimizations to be done here
1. need to fix saturation code, I just couldn't get it to fly with packs and adds.
1. need to fix saturation code, I just couldn't get it to fly with packs and adds.
so we currently use max min to clip
2. the inefficient use of chroma loading needs a bit of brushing up
2. the inefficient use of chroma loading needs a bit of brushing up
3. analysis of pipeline stalls needs to be done, use shark to identify pipeline stalls
3. analysis of pipeline stalls needs to be done, use shark to identify pipeline stalls
MODIFIED to calculate coeffs from currently selected color space.
MODIFIED core to be a macro which you spec the output format.
ADDED UYVY conversion which is never called due to some thing in SWSCALE.
CORRECTED algorithim selection to be strict on input formats.
ADDED runtime detection of altivec.
MODIFIED to calculate coeffs from currently selected color space.
MODIFIED core to be a macro which you spec the output format.
ADDED UYVY conversion which is never called due to some thing in SWSCALE.
CORRECTED algorithim selection to be strict on input formats.
ADDED runtime detection of altivec.
ADDED altivec_yuv2packedX vertical scl + RGB converter
ADDED altivec_yuv2packedX vertical scl + RGB converter
March 27,2004
PERFORMANCE ANALYSIS
March 27,2004
PERFORMANCE ANALYSIS
The C version use 25% of the processor or ~250Mips for D1 video rawvideo used as test
The ALTIVEC version uses 10% of the processor or ~100Mips for D1 video same sequence
The C version use 25% of the processor or ~250Mips for D1 video rawvideo used as test
The ALTIVEC version uses 10% of the processor or ~100Mips for D1 video same sequence
720*480*30 ~10MPS
720*480*30 ~10MPS
so we have roughly 10clocks per pixel this is too high something has to be wrong.
so we have roughly 10clocks per pixel this is too high something has to be wrong.
OPTIMIZED clip codes to utilize vec_max and vec_packs removing the need for vec_min.
OPTIMIZED clip codes to utilize vec_max and vec_packs removing the need for vec_min.
OPTIMIZED DST OUTPUT cache/dma controls. we are pretty much
guaranteed to have the input video frame it was just decompressed so
it probably resides in L1 caches. However we are creating the
output video stream this needs to use the DSTST instruction to
optimize for the cache. We couple this with the fact that we are
not going to be visiting the input buffer again so we mark it Least
Recently Used. This shaves 25% of the processor cycles off.
OPTIMIZED DST OUTPUT cache/dma controls. we are pretty much
guaranteed to have the input video frame it was just decompressed so
it probably resides in L1 caches. However we are creating the
output video stream this needs to use the DSTST instruction to
optimize for the cache. We couple this with the fact that we are
not going to be visiting the input buffer again so we mark it Least
Recently Used. This shaves 25% of the processor cycles off.
Now MEMCPY is the largest mips consumer in the system, probably due
to the inefficient X11 stuff.
Now MEMCPY is the largest mips consumer in the system, probably due
to the inefficient X11 stuff.
GL libraries seem to be very slow on this machine 1.33Ghz PB running
Jaguar, this is not the case for my 1Ghz PB. I thought it might be
a versioning issues, however I have libGL.1.2.dylib for both
machines. ((We need to figure this out now))
GL libraries seem to be very slow on this machine 1.33Ghz PB running
Jaguar, this is not the case for my 1Ghz PB. I thought it might be
a versioning issues, however I have libGL.1.2.dylib for both
machines. ((We need to figure this out now))
GL2 libraries work now with patch for RGB32
GL2 libraries work now with patch for RGB32
NOTE quartz vo driver ARGB32_to_RGB24 consumes 30% of the processor
NOTE quartz vo driver ARGB32_to_RGB24 consumes 30% of the processor
Integrated luma prescaling adjustment for saturation/contrast/brightness adjustment.
Integrated luma prescaling adjustment for saturation/contrast/brightness adjustment.
*/
#include <stdio.h>

Write Preview
Loading…
Cancel
Save