Some questions I always wanted to ask

[Carsten Haitzler (The Rasterman)]

On Tue, 21 Apr 2009 08:15:53 -0300 Werner Almesberger <werner at openmoko.org>
said:

> Carsten Haitzler wrote:
> > ok. glamo i think mostly came in because people wanted wifi. wifi needed a
> > new sdio line
> 
> Hmm, I don't remember SDIO being much of a consideration when picking
> the Glamo. It was nice to find that it came with an MMC/SD port, sure,
> but that wasn't the deciding factor.

hmm ok - well i saw these 2 as hand in hand - maybe it was an added factor that
made wifi "possible".

> The whole "graphics accelerator" story started with the poor graphics
> performance of GTA01 that was caused by a very damanding GUI combined
> with weak hardware. Simplifying the GUI (which in the end has happened
> anyway) would have solved most of the problem, but this situation also
> left the impression that hardware needed improving as well.

oh yes. bad software. bad ui and a weaker SoC (266mhz) gta02 would be much
smoother and nicer today if it simply used the dumb fb of the 2442. the only
thing that would suffer a bit would be xvideo (ie mplayer). you would need to do
yuv->rgb16 in software. mind you mplayer has an optimised software path for
this (as does xine)m but it might be a bit nastier. of course dropping to qvga
and doing software yuv-->rg16 might actually be a little better than using the
glamo as the slower pixel upload of yuv might balance out with the extra
overhead of software yuv->rgb, and qvga gets you pixel-doubling then for free
(with lower bandwidth for video refresh also adding to more grunt).

the only bit that would be better would be glamo's mpeg4 decode - but thats a
tad problematic in that its a special path for playback and we couldnt use an
existing supported api to accelerate it - and would need to invent one (mind
you in the meantime openmax is there... though you'd want an x extension of
some sort as really x is the one in charge of the glamo and it would need to
be involved).

but overall a gta02 without glamo would work significantly better imho.

> Another thing that went wrong was that X driver development started
> only very late in the project, so we didn't really know there was more
> amiss than just a lack of optimization.

yup. though simply examining the glamo docs early on could have nuked it from
the table...

> I think there are mainly two lessons to learn from this:
> 
> - don't be shy about rejecting things that cause too much trouble. We
>   could have applied that twice, to the GUI and then to the Glamo.
> 
> - start trying to integrate early
> 
> What doesn't kill you ... gives you stuff to write about ;-)

hehhehe. indeed - go for the path that "is already supported". i.e. find a chip
with already known good drivers - dont get one you have to write ones for. also
graphics drivers are as complex as it gets. avoid them like the plague if you
can. a simpler system is better. i'd much rather vote in a faster SoC to
brute-force improve gfx (with zero software changed like drivers) and then
simply work on making the ui setup and look & feel be more tuned to the
horsepower you have. so ditto. agree.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com