Graphics Performance

Thomas White taw at
Fri Apr 3 12:36:39 CEST 2009

On Thu, 02 Apr 2009 11:17:42 -0400
"Iain B. FIndleton" <ifindleton at> wrote:

> A significant issue for me is the performance of the graphics display
> on the FR. I recall some discussions a while back about making use of
> the XGlamo acceleration features. Has any progress been made here? It 
> appears to me that the graphics performance on the FR is poor
> compared to, for instance, the iPhone or iTouch, both of which have
> slower CPUs. When applications running on the FR have their X output
> routed to a machine with accelerated graphics, it is apparent that
> the FR processor can deliver the X events fast enough, but the FR
> graphics chip interface can't keep up.

[I wrote this before the other replies came through, so it re-covers a
bit of ground.]

We do have some acceleration already - both XGlamo (the Kdrive X server)
and xf86-video-glamo (the Glamo driver for Xorg) make use of Glamo's 2D
engine to accelerate tasks such as flood-filling large areas and moving
blocks of data around the screen or onto the screen from offscreen.

However, I do agree that we can do a lot more.  So far, we've
concentrated on trying to implement conventional acceleration protocols
while being limited by what Glamo can't do.  Instead, I think we should
look at what the little chip CAN do, and really make it work, HARD, for
us.  Particularly its 3D engine.  With that, we could do things like
(dare I say it, iPhone-style) flying launcher icons, or alpha-blended
overlays, or other things I can't even imagine right now...

There are many limitations of the chip, but I don't see them as a
reason to give up on this kind of thing.  For example, it's often
mentioned that the 3D engine won't render to a buffer larger than
511x511 pixels.  That would seem to rule out such graphical fanciness
at the native resolution of 480x640, but how about we just cover a
480x511 region of the screen with accelerated graphics and make the
remaining area into some kind of tool or status bar?  Maximum texture
size of 256x256?  Then design the UI so that the accelerated parts of
the UI split into blocks of that size or less.  And so on.

I see more potential in working 3D acceleration than just Quake, and
I'm not in the least bit put off by the knowledge that the chip is a


More information about the community mailing list