On Mon, 2007-06-04 at 19:15 +0200, NoiseEHC wrote: > The problem with 3d graphics as I see is memory bandwidth. Filling > 1200x900 even if only just one color component in every pixel is a > no-no. The only option is to render to an overlay surface and scale that > to the display. There is a video of full screen Doom on the OLPC so it > is a viable route (however I cannot find the message when Christopher > Blizzard asked for overlay support, so ask him how he did this, he works > in RedHat too).
Not only that, his cube is right next to mine, and I was in the room when the famous youtube videos were filmed. Actually, I had prboom running on an atest board with first-rev panel and DCON grafted on, well before btest hardware existed. It was using the doom sw renderer, not Mesa. Full RGB though, not YUV. > So I think it is better using this (page 286): > "6.5.1.9 Video Overlay Support > The GUI block also supports a video overlay function. The > DC has flexible addressing capability for YUV 4:2:2 and > YUV 4:2:0 display surfaces. Video data is stored in a separate > buffer within the off-screen frame buffer. Independent > surface pitch control is provided for Y and U/V." > > Rendering into YUV will be a little bit easier since only the Y > component requires lighting (no colored lights) but the renderer must > average the U and V components. If the renderer outputs one line with > MOVNTQ and never overdraws pixels then the only limiting thing can be > the texture fetch. It could be done with reasonably small textures if > all the textures in one line fit into the L2 cache (but I still need > info about that from AMD). If you're willing to render to YUV then yeah, this should be fine. My reply was thinking you were going for RGB. - ajax _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
