Re: [PATCH] faster yv12 to yuy2 color conversion

Hello!

On ti, 2012-04-10 at 01:55 +0200, Roland Scheidegger wrote:
> Missed the availability of pavgb instruction last time (since the code
> required mmxext anyway) which is VERY useful. Cuts down assembly
> instructions nearly in half (and makes it completely memory bound again,
> the performance improvement is less than 10% here). Keep the old version
> fixed to work with mmx only if that's still useful.

Nice :)

Some notes about the new (and old) code:

Instructions have some latency and now most of the new instructions
depend on each other (mm3 register). This slows down execution time.
Better scheduling might improve performance even more ?

".align ..." in beginning of asm block is useless. Loop is generated by
the compiler, so it should take care of aligning the block. Align here
can even make the loop slower, if there is some register loading in the
loop body before asm block.

Incrementing some of the data pointers could be interleaved to asm code.
This might speed up things when there are not enough registers to hold
all pointers (x86_32). Interleaving could speed up the code on x86_64
too (mmx/sse uses different execution units than add, and some bubbles
could be filled).

Multiplying by 5 and 7 might be faster with pmullw, if instructions are
interleaved properly. There are some other instructions that take long
time and have low throughput (unpack). But I don't know if it would
speed up the new mmxext version (or even mmx one).


Could the interlaced loops (y) be combined ? It could make the code
simpler. It could also reduce cache misses and even improve streaming
stores. The loop is already over 200 bytes long.


I don't know if streaming store is optimal here; in many cases data is
used immediately after conversion, and with some CPUs SD video fits
perfectly well in L2 cache.

Have you tried if using prefetch for YUV planes has any effect ?


> This code should also do better rounding (not 100% correct but better
> than the old code which did truncation),

Adding rounding to C version should not hurt performance much ? That
would allow testing of accelerated versions by running both versions and
comparing the results.

> and is also changed to use the
> same assembly for both odd and even lines (as a simple argument swap is
> all that's needed).

Applied this part.


I have also SSE2 and AVX versions of the code. Maybe we should create
template for the function, I don't like the idea of having 5 copies of
almost identical function ...

I was also thinking that we could leave all mmx (+mmxext?) versions out
when compiling to 64-bit systems, as there is always at least SSE2
support. I think even oldest 64-bit kernels support SSE2 too ?


- Petri



------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev