Re: RFC: inline assembly for alphablend functions

On ke, 2012-04-25 at 21:00 +0200, Roland Scheidegger wrote:
> Hi,
> 
> xine's alphablend functions are terrible cpu hogs (in particular with hd
> streams). I was wondering if it would be worthwile to improve things a
> bit with simd instructions. I started with mem_blend32 because that's a
> natural fit for mmx without touching anything else (and because this
> itself uses a lot of time with yuy2 blending). 
> Seems to work and reduce
> executed instructions a lot though only on a K8 do I see any performance
> improvement (the thing is once again heavily limited by memory
> bandwidth). Of course it does exactly nothing unless you have
> video.output.disable_exact_alphablend set. The code is also compiled and
> executed unconditionally which obviously would need to change.
> I guess there would be more of an improvement with the exact blend
> function (looks a bit less limited by memory bandwidth) but that's
> definitely much more work.
> So what do you think?

Check
http://anonscm.debian.org/hg/xine-lib/playgrounds/xine-lib-1.2-mpz/

I recently made some benchmarks with alphablending code. Simplifying
blending functions resulted in ~50% speedup with quite minimal effort.
To avoid lot of code duplication, hacks and so on some minor changes to
alphablending API would be useful...

Darren, should we branch 1.3 ? :)

DVD clipping areas are checked very often for all kind of overlays. This
could be done only once and only when clipping area is used.
We could combine palettes so that first 256 entries are "normal" and
next 256 for clipping area. Then we could simply modify palette indexes
in compressed image by setting higher byte to 1 or 0 based on clipping
area. This way blending functions and video drivers won't need to know
anything about clipping areas.

RLE could be re-generated when overlay changes or video size changes.
This would eliminate checks for blending outside of dest image. At same
time RLE elements could be breaked at end of each line (and at clipping
area boundaries) eliminating some more checks...

Sometimes it could be faster to uncompress line to temporary buffer and
then blend it with SIMD functions. VDR menus have large semitransparent
background areas. Long RLE elements are probably faster to blend with
current code. But if there's also lot of (antialiased) text it breaks
RLE elements to quite small bites...
We could analyze compressed image when it has been changed, and
uncompress parts with lot of small elements. Either on the fly while
blending or once when image changes.
Maybe we could use some marker in RLE to mark uncompressed areas ?
something like
if (rle->color == -1) {
  blend_uncompressed(dst, (uint8_t*)(rle + 1), rle->len);
  rle += len + 1;
  continue;
}
All this could be implemented in video_out (requires changes to video
drivers too) or hidden to alphablend functions (by attaching custom
acceleration data to overlays, and a flag to indicate changed overlay
image).


- Petri



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/