On Mon, 6 May 2002, Zdenek Kabelac wrote:
> Well the worst problem isn't the memcpy itself - the enemy here
> is the memory bandwidth and it's very bad to process image this way:
>
> decompress image - scale - rgb covert - rotate - blur - compress.
>
Do you mean to do all filter process separetely for few lines (or more
lines) ?
I mean anything like this ?
for(in_all_lines/16){ //for exapmle working on sets of 16 lines
get_lines(16);
decompress();
scale();
rgb2yuv();
rotate();
blur();
compress();
put_processed_lines();
}
if you select optimal line count, all operations will be under L1 (L2)
cache and memorry will be transferred only at start and end of the
process. This strategy brings much better bus utilization and some
performance improvement too.
Or do you mean anything else ?
> the best here is to program a filter (I call it mmx pipeline just
> because it's supposed to use any available acceleration)
> which will consume some set of line and will do operation with them
> with just small chunks and will take advantage of the L2 cache.
> (Of course if you have Xeon CPU you have no problems here as
> 1MB L2 usually solve the problems here :)
>
--
Tomas Konir
Brno
ICQ 25849167
_______________________________________________
Avifile mailing list
[EMAIL PROTECTED]
http://prak.org/mailman/listinfo/avifile
