The glamo chip and its future

[Carsten Haitzler (The Rasterman)]

On Sat, 28 Jun 2008 13:26:24 +0300 Mikko Rauhala <mjrauhal at cc.helsinki.fi>
babbled:

> la, 2008-06-28 kello 09:43 +0200, Michael Stather kirjoitti:
> > At least this is what I read, 
> > since neither read 2D or 3D acceleration is possible.
> 
> That is quite an overstatement of the problems. At least Xv and mpeg4
> accelerations are possible with available software. I don't know exactly
> how much accelerated support there otherwise is, but at least seems from
> public statements that basic stuff like blitting/solid fills/rotation
> etc is there. So please, while the Glamo is no panacea, and the
> bandwidth issues are real enough, no FUD that nothing is possible with
> it.

bingo. correct. the mpeg4 accel is definitely hackish as there is no well
defined access api/system for it. it wont forward-=port to any new/different
soc's.

> Also, while this is purely speculative, balrog-kun (the guy responsible
> for mpeg-4 acceleration) at least at some point had some ambitions on
> doing basic 3d acceleration support, but that would probably require
> running in QVGA mode even if that pans out. (The Glamo is not really
> designed for VGA displays even if it can drive one.)

yup. 3d accel wont be doable in vga. the max 3d buffer size is 511x511 (less
than vga in 1 dimension), so going down to qvga will be needed. you cover the
issues quite well here. i'm just confirming it. :)

> > So I wonder why this was done that way (since the older model had a much 
> > larger bandwidth), and whether it's changed for the next release.
> 
> It is public information that the Glamo is off the table for GTA03 due
> to it not panning out quite as well as was originally hoped.
> 
> As for why, I can only speculate. The short specs without the caveats
> were attractive enough, they got permission to do a free driver, and the
> Glamo provided an extra SD controller (though limited by its bus) which
> was necessary with the wifi chip requiring one.

yup. when you read initial specs for glamo you go "oooh nice". then you find
the gotchas. (256x256 max texture size, no render-to-texture, 511x511 max 3d
destination buffer size, ...) and you being to see how much work it will be to
work with it. if we had a qvga display glamo would be a better match. vga is at
the upper limit of the glamo. a lot of stuff CAN be done. given enough time and
effort and willingness to accept the limitations (eg yes - 3d can be done, but
only openglES 1.1, and qvga output). i had been thinking of doing all 2d accel
via the 3d pipe at one point. this would have given us fantastic support for
xrender, compositing, 3d for games and more, but the limitations made me
realise we'd fall short on many parts of that pipeline. it's all possible - but
there are things that will limit you, and that's just a fact of life with the
chip. i didn't have any idea access to/from video ram would be the speed it is.
we did try dma to alleviate it - but that was a failed experiment. in the end
we have product to ship and what is there now is "good enough". we can't go
delaying a product forever to play games for 1 graphics chip.

> > I mean e.g. games (3D games, or emulators) are IMHO an important part of
> > the functionality of such a smartphone.
> 
> For fast-paced games you might want to use QVGA mode to alleviate the
> bandwidth issues, but IMAO on such a small screen that isn't a bad deal
> anyway (for fast-paced games spesifically). Something like scumm
> adventure games should be fine in higher resolution, but that isn't a
> promise as I don't have a GTA02 myself yet (the order _is_ in :).

yup. qvga would help a lot.

> Realize that the GTA03 will apparently be dumb framebuffer again, like
> GTA01. While that speeds up pure blitting to the screen from the main
> memory, do not expect wonders from it either.
> 
> Where future devices go, we shall see. The reality is that most high-end
> embedded graphics stuff is closed as hell. What with Android and even
> Nokia announcing preliminary plans for Linux phones, there are quite
> enough high-profile companies doing this stuff with no regard for real
> openness (witness Android FAQ and partner list, and Nokia's Maemo).

yup. the way graphics on embedded is going is that it is part of the cpu
(soc). so you get what you get with the soc. you don't choose it separately.
this itself makes lots of dev work to squeeze everything from the glamo a less
attractive proposition. we need to tread carefully in the future to ensure:

1. our products stay OPEN.
2. we try and provide as much as possible given limitations.

the glamo is not bad - if you don't try and push it. we, unfortunately, are
pushing it already by virtue of shipping a vga lcd. :) then it begins to show
that it has limitations.

> I for one would like OpenMoko to differentiate in this respect and stay
> the course even with the difficulties it may pose.
> 
> -- 
> Mikko Rauhala   - mjr at iki.fi     - <URL:http://www.iki.fi/mjr/>
> Transhumanist   - WTA member     - <URL:http://www.transhumanism.org/>
> Singularitarian - SIAI supporter - <URL:http://www.singinst.org/>
> 
> 
> 
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>