3d graphics

[Adam Jackson]

On Thu, 2007-05-31 at 10:36 +0200, NoiseEHC wrote:
> I have meant displaying with scaling. Filling 1200x900 in 30fps is 
> impossible I think.
> IMHO there is no feature in the Geode DC which could be used by the 
> rasterizer so I think it is not a problem to concentrate on this one 
> feature (scaling) it can do quite well.
> As I see in the DCON documentation, it simply scraps 2/3 of the frame 
> buffer data when deswizzling so it seems that not generating that data 
> would be a win either way.

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.

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.
1M is 8388608 bits, but 1200x900 of packed 6-bit words is 6480000 bits.
The antialiasing, when enabled, happens on input to the DCON (math done
over rgb676), but the ouput from the antialiasing stage is back down to
6-bit.

We could also use the LX's output scaler [1], so that the panel would
always be driven natively at 1200x900 but you'd render to, say, 800x600.
Of course if you do this you can't optimize fragment emission by
subpixel channels.  800x600 would effectively give you pixels with a 2x2
geometry, the top left being:

  R G
  G B

and then swizzled in the usual fashion along both axes.  Weirdly,
800x900 would work (R+G for first pixel, B+R for second pixel, etc), but
the math for your view frustum would get more complex.  So you probably
can't do the fragment color optimization, but you would likely save
enough in memory bandwidth to make it worthwhile.  I recommend 400x300
if we go this route, just to make your pixels a uniform color.

The problem with doing so is the interaction with Sugar.  Even if it
were smart enough to catch the root window resize and reposition the
frame, it'd have to also scale all the icons down, and do a mode switch
on activity switch, and etc.

[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