3d graphics

[NoiseEHC]

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). I would suggest in this mode to turn on the Geode's 
frame buffer compression (I suppose it is disabled by default) and clear 
the screen (with the color key). When the user clicks on the Frame (the 
thingy in Sugar) then it will simply be displayed over the video 
(because of the color key) otherwise it will limit the Display 
Controller's memory reads.
> You could certainly attempt to optimize fragment generation for the
> swizzle layout to only emit the relevant color, but I suspect you're
> going to be saving only CPU time there, not memory bandwidth.  Your
> pixels are still going to be 4 bytes wide on the path from the CPU to
> the framebuffer, and I strongly doubt the cacheline flush can write
> anything less than dwords at a time.
>   
I am not sure that driving the DDR RAM is that simple, however I am 
clearly not a hardware engineer. I asked about that topic here but no 
answer. I hope somebody will reply from AMD since the LX's pdf is not 
the same quality as for example the IA-32 Intel? Architecture 
Optimization Reference Manual...
> Strictly speaking, the display is always throwing away 2/3 of your pixel
> data, but the pixels coming out of the Geode GPU are always fully
> loaded.  The storage optimization is just in the DCON's internal RAM,
> not the GPU framebuffer, and it's purely optimizing for component cost.
>   
snipped
> [1] - I think.  I'm reasonably sure this is effectively free as it's
> happening in the DAC not the GPU, but I'm not sure.  Also, I don't
> remember if this exists on both GX and LX.  Even if it does, this is
> RANDR code in the geode driver that just isn't there yet.
>
> - ajax
>
>
>   
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).