Yummy new CPU/GPU combo

Marc Bantle openmoko at rcie.de
Thu Jun 5 11:50:43 CEST 2008

Carsten Haitzler (The Rasterman) wrote:
> On Wed, 4 Jun 2008 19:59:35 +0200 Tom Cooksey <thomas.cooksey at trolltech.com>
> babbled:
>> On Tuesday 03 June 2008 09:06:35 Carsten Haitzler wrote:
>>> the day nvidia comes with open drivers for this... we can begin to take an
>>> interest :)
>> Sorry, just how open is the current glamo driver exactly?
> the driver is open. the chip specs so you can go write your own driver from
> scratch are only available under nda though :(.
>> IMO, OpenMoko's choice of using the the glamo was a big mistake (Connecting
>> it to a shared, 4-bit bus was probably the _biggest_ mistake).
> i definitely can't argue here. :) i know when i turned up glamo was already in.
> my guess after some quick poking and a lot of spec doc reading was that given
> full drivers - we'd give or take have about the same performance as pure
> software only drivers (for 2d) in a dumb framebuffer - i.e. - what gta01 has.
> the exception might be opengl (3d) there where software won't be able to render
> and keep up with the glamo, but 3d comes with a lot of caveats on the glamo,
> like max 256x256 textures. no render-to-texture (so intermediate buffers are...
> well.. a pain), and the unhappiest is the max 3d buffer size (target for
> rendering) of 511x511 - so as such we can't manage fullscreen 3d @vga res. we'd
> always have to go down to something like qvga. 
>> OpenMoko insisted on having open source drivers, and the only hardware vendor
>> which would let them do it was SMedia. So we get this massively underpowered
>> graphics processor - but that's ok because OpenMoko can release the source
>> code to the driver! Except SMedia wont let OpenMoko realease any technical
>> info about the chip. So, in fact, the glamo driver can only be developed by
>> people employed by OpenMoko and only after they sign an NDA.
> well we can't release the docs smedia gave us. but we are allowed to talk about
> the technical details all we like in public. THOSE docs that smedia wrote are
> theirs and we can't give them out. we are allowed to go write our own docs
> based on it - but that won't be a small document, and right now internally no
> one has the time to just sit down and write such a doc (as opposed to writing
> code).
>> The Xglamo may be open source, but it is not, nor can it ever be, a community
>> project.
> it can - partially, but only in as far as any chip specs that are apparent in
> the existing code.
>> Now look at the other options OpenMoko could have gone with. Well, _the_
>> option of cource would be to have used a half-decent SoC, one with an
>> integrated GPU such as a Freescale i.MX or TI OMAP, even an XScale would have
>> been better. You'd then get a PowerVR GPU (same as used in the iPhone), which
>> already has Linux drivers. What's more, OpenMoko would get the source code
>> for the drivers, under NDA from Imagination Technologies. The only
>> restriction would be that OpenMoko couldn't release the source. But that's no
>> different to the glamo, given that only OpenMoko employees can work on it.
> again - we could have chosen much better soc's indeed, but as it stands right
> now that isn't happening. gta02 is basically a gta01 slightly improved. gta03
> will at this stage be a gta02 minus glamo (which simplifies things a lot and at
> least for 2d stuff should get us an improvement).
>> We would also have had a decent processor, one with a more up-to-date
>> instruction set than the nearly 10-year-old armv4t. So there may not have
>> been Cortex A8s around 2 years ago when GTA02 development began, but there
>> were plenty of options. Why on earth did OpenMoko stick with an aging CPU and
>> an almost useless GPU when there were so much better options? And please
>> don't say BOM, I refuse to believe the combined price of the 2442 and glamo
>> is cheaper than e.g. an i.MX31 or OMAP2420.
> because even before that the neo was inherited from an older project to do a
> windows-mobile phone... the hardware is based on an ancient product design.
>> Cheers,
>> Tom
>> PS: Very sorry for the rant, I just had such high hopes for OpenMoko and am
>> just fustrated with the hardware design decisions.
> understood. i can't blame you. i've done my share of ranting too. but even
> internally the most i have managed to do, i think, is influence the glamo to
> vanish from the gta03, but otherwise we have what we have now (just a new case,
> different battery, added a camera, a different gsm module).
> gta04 was looking good. the samsung 6400 as such is a nice soc. i've dug into
> the 2d gfx portion of the docs. it's a bit tricky to use, but much better than
> the glamo and much more powerful in the 2d department (u'll manage scaling
> and compositing even in argb32 bit) nicely on that baby. it's memory bus was
> way better than gta02, and as it's graphics is integrated on the soc software
> cpu access to do fallbacks as well as mixing with hardware accel is sane and
> performant (unlike accessing video memory across a puny bus from the cpu when
> you need to fall back to using the cpu to do stuff).
> but... gta03 is back from the dead, gta04 is off the map (for now) and
> everything is going to be based on the existing 2442 arm v4 samsung soc for
> gta03.
Thanks, Tom and Carsten, for this essential resume on Neo
graphics hardware decisions. Haven't read it that clear before :-)
> quick question - would you prefer a qvga lcd (save a bit of cost) since we'e
> going to need to software-drive all graphics - the fewer pixels you have to
> fill, the better for speed. i'm really tossing up if the speed of qvga is worth
> the loss of resolution. i'm just not sure.
Would that be 320x240 (QVGA [1]) or 480x320?

I think the latter would be acceptable in terms of usability.
OTOH it would also
- create extra maintenance cost for system and app themes
- narrow on-screen information for people with good eye-sight
(granny won't be affected ;-)

Sofar I haven't suffered from lacking graphic speed on my
GTA01. It seemed that waiting for UI feedback was mainly
cause by other background processes (e.g. SD-read or such)
My interest are standard smartphone and geo apps and for
those I'd rather go for resolution.


[1] http://de.wikipedia.org/wiki/Quarter_Video_Graphics_Array

More information about the community mailing list