[MPlayer-cvslog] r27188 - in trunk/libswscale: internal_bfin.S yuv2rgb_altivec.c
diego
subversion at mplayerhq.hu
Fri Jul 4 15:14:29 CEST 2008
Author: diego
Date: Fri Jul 4 15:14:29 2008
New Revision: 27188
Log:
whitespace cosmetics
Modified:
trunk/libswscale/internal_bfin.S
trunk/libswscale/yuv2rgb_altivec.c
Modified: trunk/libswscale/internal_bfin.S
==============================================================================
--- trunk/libswscale/internal_bfin.S (original)
+++ trunk/libswscale/internal_bfin.S Fri Jul 4 15:14:29 2008
@@ -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:
- 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))
+The following calculation is used for the conversion:
- y,u,v are pre scaled by a factor of 4 i.e. left shifted to gain precision.
+ 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.
- 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.
- 2) scale operands up by a factor of 4 not 8 because Blackfin
- multiplies include a shift.
+1) use the bytop16m to subtract quad bytes we use this in U8 this
+ then so the offsets need to be renormalized to 8bits.
- 3) compute into the accumulators cy*yx0, cy*yx1
+2) scale operands up by a factor of 4 not 8 because Blackfin
+ multiplies include a shift.
- 4) compute each of the linear equations
- r = clipz((y-oy)*cy + crv*(v-128))
+3) compute into the accumulators cy*yx0, cy*yx1
- g = clipz((y-oy)*cy + cgv*(v-128) + cgu*(u-128))
+4) compute each of the linear equations
+ r = clipz((y - oy) * cy + crv * (v - 128))
- b = clipz((y-oy)*cy + cbu*(u-128))
+ g = clipz((y - oy) * cy + cgv * (v - 128) + cgu * (u - 128))
- reuse of the accumulators requires that we actually multiply
- twice once with addition and the second time with a subtaction.
+ b = clipz((y - oy) * cy + cbu * (u - 128))
- 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.
+ reuse of the accumulators requires that we actually multiply
+ twice once with addition and the second time with a subtaction.
- api: yuv2rgb_kind (uint8_t *Y, uint8_t *U, uint8_t *V, int *out,
- int dW, uint32_t *coeffs);
+ 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.
- A B
- --- ---
- i2 = cb i3 = cr
- i1 = coeff i0 = y
+ api: yuv2rgb_kind (uint8_t *Y, uint8_t *U, uint8_t *V, int *out,
+ int dW, uint32_t *coeffs);
- Where coeffs have the following layout in memory.
+ A B
+ --- ---
+ i2 = cb i3 = cr
+ i1 = coeff i0 = y
- 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
Modified: trunk/libswscale/yuv2rgb_altivec.c
==============================================================================
--- trunk/libswscale/yuv2rgb_altivec.c (original)
+++ trunk/libswscale/yuv2rgb_altivec.c Fri Jul 4 15:14:29 2008
@@ -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>
More information about the MPlayer-cvslog
mailing list