Re: RFC: inline assembly for alphablend functions

Am 26.04.2012 11:26, schrieb Petri Hintukainen:
> 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).
> 

Oh very nice. That stuff is old? Certainly better than my crude
mem_blend32 attempt which failed to even recognize that it isn't
necessary to reload src (but even then it was like 3 times less
instructions in the loop than the c code).
Still, it doesn't have y yuy2_exact mmx version, which is the one I'd
really want :-). But I guess that needs different organization of line
buffer to make it useful (I was also wondering if it wouldn't be easier
if the y values would be just stored in the line buffer too and then one
loop could blend both y and chroma values - not sure though.)

Roland


------------------------------------------------------------------------------
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/