summaryrefslogtreecommitdiffstats
path: root/libswscale
diff options
context:
space:
mode:
authordiego <diego@b3059339-0415-0410-9bf9-f77b7e298cf2>2008-07-04 13:14:29 +0000
committerdiego <diego@b3059339-0415-0410-9bf9-f77b7e298cf2>2008-07-04 13:14:29 +0000
commit38c51d7eb68300a56407a487f8b8982839765258 (patch)
treebdd4cfbc90304d9cc362edd69a499e9ac0d56332 /libswscale
parent98b0b52fcec38d59ba15b80d1180b9120cfc728f (diff)
downloadmpv-38c51d7eb68300a56407a487f8b8982839765258.tar.bz2
mpv-38c51d7eb68300a56407a487f8b8982839765258.tar.xz
whitespace cosmetics
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27188 b3059339-0415-0410-9bf9-f77b7e298cf2
Diffstat (limited to 'libswscale')
-rw-r--r--libswscale/internal_bfin.S85
-rw-r--r--libswscale/yuv2rgb_altivec.c78
2 files changed, 81 insertions, 82 deletions
diff --git a/libswscale/internal_bfin.S b/libswscale/internal_bfin.S
index 2d5c61a14a..7dcd019fae 100644
--- a/libswscale/internal_bfin.S
+++ b/libswscale/internal_bfin.S
@@ -24,74 +24,73 @@
/*
- 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))
+ 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
- then so the offsets need to be renormalized to 8bits.
+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
- multiplies include a shift.
+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.
+ reuse of the accumulators requires that we actually multiply
+ twice once with addition and the second time with a subtaction.
- because of this we need to compute the equations in the order R B
- then G saving the writes for B in the case of 24/32 bit color
- formats.
+ because of this we need to compute the equations in the order R B
+ then G saving the writes for B in the case of 24/32 bit color
+ formats.
- api: yuv2rgb_kind (uint8_t *Y, uint8_t *U, uint8_t *V, int *out,
- int dW, uint32_t *coeffs);
+ api: yuv2rgb_kind (uint8_t *Y, uint8_t *U, uint8_t *V, int *out,
+ int dW, uint32_t *coeffs);
- A B
- --- ---
- i2 = cb i3 = cr
- i1 = coeff i0 = y
+ A B
+ --- ---
+ i2 = cb i3 = cr
+ i1 = coeff i0 = y
- Where coeffs have the following layout in memory.
+Where coeffs have the following layout in memory.
- uint32_t oy,oc,zero,cy,crv,rmask,cbu,bmask,cgu,cgv;
+uint32_t oy,oc,zero,cy,crv,rmask,cbu,bmask,cgu,cgv;
- coeffs is a pointer to oy.
+coeffs is a pointer to oy.
- 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.
+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.
- All routines are exported with _ff_bfin_ as a symbol prefix
+All routines are exported with _ff_bfin_ as a symbol prefix
- rough performance gain compared against -O3:
+rough performance gain compared against -O3:
- 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.
+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
diff --git a/libswscale/yuv2rgb_altivec.c b/libswscale/yuv2rgb_altivec.c
index de6390001a..3583e4bf65 100644
--- a/libswscale/yuv2rgb_altivec.c
+++ b/libswscale/yuv2rgb_altivec.c
@@ -21,63 +21,63 @@
*/
/*
- 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.
+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.
- 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.
- so we currently use max min to clip
+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>