On Sat, 9 Sep 2006 12:38:17 -0400 "Timothy Miller" <[EMAIL PROTECTED]> wrote:
> It has the advantage of being able to, for zero cost, apply alpha > blending, rops, and planemasks directly to image uploads. > Essentially, a graphics memory write can be diverted through the > drawing engine where it becomes a fragment and can therefore have any > drawing engine feature applied to it. (There are limits for cases > where the fragment has an address but not coordinates.) The drawback > is that writes have a huge latency... if you ever want to read the > word back, you have to know what you did and flush the engine pipeline > before you try to read it back. Assume for now, that we do not provide any read back to host memory. It makes our life much simpler :) > We can move the YUV/RGB logic into the engine where we can send YUYV > for one scanline, then change modes (just drop a configuration write > down the pipeline) and provide an offset where we provide YYYY and > have the GPU read memory from an appropriate offset back from where > we're writing. You could alternate YUYV and YYYY, or you could do all > YUYV at once and then interleave the YYYY in there. > > In this case, since we're storing as RGB, we'd have to sneak U and V > into the alpha channel bits of image being uploaded. So alternating > pixels would be stored as URGB and then VRGB. If you want to apply an > alpha blend to the video data when it's being composited onto the > screen, you can provide it as a constant in the texture unit. I would not mix in YUYV, that format is hardly used anymore and IMHO makes our life harder than simpler. You'd have to be very carefull in associating the correct pixel with the correct converter to get the righ pixel values in the end. Currently i propose to do the whole think in 3 steps: 1) When the image data enters our card, do a horizontal upsampling. This is fairly easy as the data enters line by line, and each line will be complete. The only difficulty will be that the pci transferes will not be continous and that some other transfere might sneek in. So we need to safe some state at the end of each transfere operation and compare that state against the next operation to ensure that we are working with the correct data. 2) read the image out, but not in the usual order, but in vertical lines. perform vertical upsampling if neccessary. Advantage is that we have to read the data only once, when we will read it anyways. Drawback is that we get the data in an order we don't want to (vertical lines instead of horizontal lines). 3) perform YUV->RGB conversion. Now that the data is upsampled, this is very easy and just a matrix*vector multiplication. > A point not to be lost here is that we're not wasting any memory > bandwidth by storing unnecessary YUV in the framebuffer. It's an > on-the-fly conversion, and it's one-way. Who cares about our memory usage ;) BTW: I started a discussion on ffmpeg-devel about this conversion stuff, to see what is really important: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-September/044690.html If you want to join the discussion, please get the mails from the mbox at http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/ so that threading isnt broken. Currently the main points that came out are * Different YUV->RGB coefficients aren't that important * Correct upsampling from 4:2:0 and 4:2:2 to 4:4:4 is important * Only 4:2:2 and 4:2:0 are important * Only 4:2:2, 4:2:0, 4:1:1 and 4:1:0 are relevant, but 4:1:x can be left out. 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)
