3d graphics

[Adam Jackson]

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