Some questions I always wanted to ask

Carsten Haitzler (The Rasterman) raster at rasterman.com
Mon Apr 20 14:58:30 CEST 2009


On Sun, 19 Apr 2009 13:57:38 -0700 Steve Mosher <steve at openmoko.com> said:

> I'll explain what bits and pieces I know
> 
> Laszlo KREKACS wrote:
> > Hi!
> > 
> > I would like to ask some question which always bugged me.
> > 
> > Glamo:
> > 
> > 1. Why glamo was choosen in the first place back in the GTA02 design phase?
> > - 2442 required it absolutely? (ie. a graphics accelerator is needed
> > in any case.)
>     Don't know. When I came on board in late 08, the decision was already
>     made. I would suspect it was the ONLY 3D chip that met the "open"
>     requirmrents. Since I have a pretty extensive backgound in 3D
>     I made the rounds to all my friends at 3D companies late in 08..
>     no joy.

ok. glamo i think mostly came in because people wanted wifi. wifi needed a new
sdio line (spi wasnt a supported path by atheros last i checked - it worked,
but they didnt want to support it). i think this was the case - anyway. glamo
did 2 things

1. removed video refresh bandwidth from main memory (giving you back some
performance. (refresh on the gta01 @ 75hz uses up about 44m/s of memory
bandwidth. that is just to keep the screen alive. nothing more. when you only
have something in the region of 200m/s of bandwidth (i can't remember the exact
figures but its in that ballpark)... you pay a big cost just to refresh lcd.
(by contrast qvga only needs about 11m/s - which really is the kind of
ballpark the glamo AND 2442 were intended for. they CAN do VGA. but they were
not optimal for it - much like i can throw 2 people on a 50cc scooter and
drive up a steep hill. it might make it.. but it wont be doing it fast and
smoothly :))

2. added the SDIO line to hook up the wifi so we gained an extra SDIO line and
could keep mmc and wifi

3. on paper offered graphics acceleration and 3d etc.

4. at the time smedia were actually interested in opening the docs on proviso's
(they are reviewed, input given back to them, and then they get opened).

that pretty much is it as i understand it. as steve said - i came on in oct
2007 - decision was made. first thing i did was get the glamo chip programming
docs.. and read hem cover to cover... twice. i soon began to see some holes in
the plan... and began to make some noises. when you read the docs as a WHOLE
you get the impression glamo was meant for qvga. vga is "possible" but an
outer limit. read enough of the specs and thats how it looks. i also began to
see holes. the 3d was not going to be capable of acceleratng 2d sanely. it
simply lacked things you would want for 2d to use the 3d unit to DO the 2d ops.
render to texture. 256x256 texture limits and the 515x155 dest 3d buffer limit
for starters. the 2d unit also lacked large blobs of a 2d pipeline to
accelerate beyond the most basic x ops (blit, fill). it could partly accelerate
xrender. but not fully. it maybe could do 20% of xrender's ops.

here comes the catch. the moment you canto 100% accelerate a pipeline... you
need to use software fallbacks. even 1 fallback can kill acceleration back to
software speeds. more than 1 can make it SLOWER than software. after some mental
mulling and thinking i got to the conclusion "if we do all the drivers and
implement everything glamo can do.. we will have something that is gove or take
the same speed as pure software now. except for video (yuv->rgb+scale for
xvieo (mplayer etc.)). i was at the pint of "we can spend 12 man months on
drivers and... get absolutely nowhere. this is bad.". but glamo was already in
by then - too late to turn back. at th time i did not have any idea of the
bandwidth problems as i had yet to have a stable working gta02 to use - i had
one with problems. eventually i got one and started to play and only noticed
the bandwidth problems then.

> > - There were no alternative graphics chip to glamo?
>     not that met the open requirements.

in fact there are incredibly few stand-along gfx accel chips for embedded. very
very very few. most are integrated into the cpu's (soc's) these days.

> > - There were no alternative CPU (like 6410 just two years earlier)
> > which does not require an external graphics chip?
> > 
> > 2. How deep was known all the glamo deficiencies when the GTA02 design
> > was finalized?
> 
>     Raster and I met for the first time in October of 2008 in TPE.
>     I had just come on board, so had he. At our first lunch we started
>     to go over the glamo in some detail. When I realized who the
>     chip designers were and what the features were (bandwidth is 
> everything) It became clear to me ( as was clear to raster) that
>      only some software miracles could improve things. In hindsight
>     both of us should have screamed to have the galmoectomy.. maybe
>     raster did..So, I guess you could put it this way. If Raster
>     or I were around when the design decision was made, neither of
>     us would have supported such a decision. Once we came on board
>     we lacked the courage/power/bandwidth to insist on changing
>     the design.. It basically became " hey raster, do your best to
>     speed shit up" but if you look at the speeds and feeds it was
>     a futile excercise.  Ah, early on ( at that first lunch and first 
> dinner that night) I think the two of us agreed the best thing
>    would be to punt to 320x240.. since that's what the chip was targeted
>     at.

yup. agree. if i had ben there before glamo had made it in and had had the time
to read the docs for it, i would have given my "this wil solve your SDIO
problem, but likely lave you no better of in the gfx department. it WILL create
a lot of work in writing drivers, integrating it into power management etc. and
so you will crate work for something that gives only 1 benefit - SDIO line.
could we find another way to do wifi without glamo?". that is what i would have
suggested. even a move to qvga would not remove the driver work. a qvga display
would of course be significantly faster with software rendering too... so the
benefit is glamo-agnostic. but the time had come and gone for that. and eh new
guy who just turned up suddenly saying to abandon a core bit of design for the
device.. wouldnt have happened.

> > - Raster always said that glamo was designed to 320x240 screen and not
> > 640x480. Was it known back then?
>     See above. I'm pretty sure the guys who selected the chip had no
>     comprehension of the performance requirements.

i suspect that it was selected for other reasons an they assumed its 2d/3d was
"good" and a lot of the gotchas that ended up happening... wouldnt.

> > - Glamo bandwith limit was known?
>     Again, I'm pretty sure the folks selecting the chip had no
>     comprehension of the imporatnce of BW or the implications
>     for overall design. System design study was not a strong suit

no idea. i had no idea from the paperdocs either. until much later when i
started going "why is this so slow?" and actually did some benchmarks...

this led me to try and get a solution. ok - bandwidth is slow. can we free up
the cpu from the upload work - get the 2442 dma to do it. dodji skeleti was
working on the glamo driver at this stage. smart good guy. i asked him to give
dma a go - at least get a proof of concept and test the bandwidth. i hoped
beyond hope it would at lats offload the copy to another unit in the 2442 and
leave the main unit to do its work. asynchronously. unfortunately this was a
glorious failure (and thus i accept the blame for that. i had hoped for more
from the 2442 than it was willing to give). this was complex as dma works in
linear memory only (it didnt go thru the mmu) so a kernel driver had to
schedule dma copies page by page (or across multiple if continuous). this made
it complicated and added overhead as for fragmented or small memory you'd spend
more time scheduling the dma than doing it. the result was hw dma (mem to mem)
was at BEST 1/2 the speed of he copy with the cpu. at BST. and it degraded from
there. that failed and unfortunately that petty much left the glamo pipe to
pretty much stay where it was. no real solution in sight if you had to upload or
download data (and you have to do this when doing software fallbacks - a lot
as an accelerator can only work on data inside its memory space).

but this came out in the wash late on. now to top it off i wanted to see if
doing glamo drivers may be worth it in a long run. i.. - right NOW glamo
sucks.... but what about glamo2> if there will b a successor chip - then..
drivers may make sense as they can be built on and the successor could solve
problems he glamo1 has... but that was not to be. glamo has no planned
successor. and that made me doubt there was much value in doing full drivers as
they have no lifespan beyond the gta02. they will never be used again anywhere -
they will likely curl up and die in a corner of the internet :(

> > 3. Was the GTA02 tested performance wise at all? (were most of the
> > glamo weakness would turn out)
> 
>     Not sure. IN my past I would have had a suite of Graphics performance
>     tests to run against the chip. But it's clear from the specs, that
>     its more likely to be a decelerator.. kinda like the Virge3d of
>     cellphone 3D.

hhehe. yup. just because it says it does 3d.. doesnt mean its good! tere are
enough example of that around. unfortunately glamo was one of those.
-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com




More information about the Gta03 mailing list