[Open-graphics] YUV conversion

[Peter Lund]

1) Shuffling scan lines around or duplicating them is also very cheap on
the CPU side as long as it is done before they leave the cache(s).

For a good approximation of CPU speed when doing simple massaging of
data you count actual memory reads and writes.  As long as things stay
in cache they are almost free.

If the video data stream is decompressed on the fly then the CPU does
actually have it in its cache...


2) moving/interleaving/deinterleaving/replicating data in the frame
buffer should be very cheap to do with the "blitter" (texture mapper).

If the YUV or whatever to RGB conversion is easier to do in hardware if
all the channel bytes are close together in memory (probable) or if
there needs to be very few variants of the format (probable) then it
might make sense to replicate/reshuffle things by the blitter.

I've seen Amiga demos that used the blitter to convert between "chunky"
and "planar" pixmaps.  Chunky in this context means "one byte at one
single address per pixel" and planar means that the pixmap was sliced
into a number of planes (rectangular areas) that each contribute one bit
to the colour.  Each address contained bits participating in eight
neighbouring pixels.  The original Amiga graphics modes were all planar
but if you wanted texture mapping for your doom clone demo then you
really really wanted a chunky frame buffer, even if you had to simulate
it.

The blitter wasn't all that fast at it so the task was often split
between the blitter and the CPU, sometimes with continuous automatic
correction of how the work was split.

If you can do that on a, say a 25 MHz 68020, then you should be able to
do a lot more on the OGQ9^OQB2^WQOD1^WOpen Graphics Card.  You don't
even need to interrupt the CPU every time the blitter is finished with a
command the way the Amiga blitter did -- you can put it all into one
command string in memory and send it off to the card.  You can perhaps
even reuse that command string for every frame.

-Peter