On Fri, 8 Sep 2006 20:23:18 -0400
"Timothy Miller" <[EMAIL PROTECTED]> wrote:
> Converting YUV to RGB is computationally expensive, but splicing bytes
> together is not. We can support formats like xYUV and YUYV, but when
> it comes to more exotic formats (like where U and V are supplied only
> for alternating lines), we'll need some help from software.
The most common used subsampling format is 4:2:0 where there is
one U/V sample per 4 Y sample. Ie one U/V sample per every second
pixel and every second line.
And i wouldn't impose that onto the CPU. The Matrox G200 used
and interleaved YUV format, which mean that the player software
had to first convert the planar data into a interleaved format
and then showel it over to the card. In the case of MPlayer this
made a 10-20% performance los for the whole player (comparing
the G200 to the G400), which means that for the transfere the
los must have been somewhere between 50% and 80%.
> This converter is one of those things that could end up on the
> chopping block if it's too expensive to fit in the ASIC. Even so,
> people will still be able to play video... just with more CPU
> overhead.
I wouldn't do that. It really costs a lot of performance
to do this thing on the CPU. IMHO the easiest way to implement
the YUV->RGB conversion including upsampling is to store all
3 planes in video memory, then using a counter with programmable
dividers for the adressing of the image data. This would need
3 11bit-12bit counters (plus-one adder + feedback register)
for the addressing and two small, maybe just 2bit counters for
the dividers. With that you can easily feed a YUV->RGB converter
with the data it needs and then either pass it on directly into
some processing block or put it back into memory.
The only problem with that approach is that each pixel needs
3 read accesses (and one write if it's stored back), so there need
to be some form of cache to allow the RAM to work in burst mode.
Attila Kinali
--
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
-- reeler in +kaosu
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
