Graphics Performance

Carsten Haitzler (The Rasterman) raster at rasterman.com
Wed Apr 8 02:52:42 CEST 2009


On Tue, 07 Apr 2009 11:35:41 -0400 "Iain B. Findleton"
<ifindleton at videotron.ca> said:

this is one of the problems with glamo. as i know it will not be used in any
future products beyond gta02. no other phones i know use it - no other linux
devices. writing an app totally around the glamo and how it works or doesnt
work well will simply heavily screw with the ability to port to any other
new/future/different platforms.

fi glamo was less limited with less gotchas - it'd be sane ad you use what is a
generic common pipeline and simply speed it up on glamo - all of the pipeline
fits. and the next device has a different gfx chip..and again - all the
pipeline fits.

i can say doing things like draw to offscreen pixmap then copy to screen to
"avoid draping" using the "blitter" will in fact impact you badly on MANY MANY
MANY platforms as you add an extra copy to the pipeline you don't need. MOST
platforms in the embedded world - and pc/desktop world, have FAST framebuffer
WRITE access. for just this reason. so for the sake of 1 gfx chip - you impact
performance on most other platforms (note - ecore_evas does actually abstract
this - it's an option for a canvas window. "avoid damage" renders to a
offscreen pixmap to avoid redraws and copies the pixmap to the window on
updates or exposes, so it can be turned on, but for other things like SDL
using apps you'll have to specially change the pipeline. this of course is a
simple part of it. the complicated "make the most of glamo" involves specially
limiting 3d window sizes and filling the rest with non-gl drawn window parts
like toolbars, which are pointless on other systems. limiting all your
textures to 256x256 and now having to add complicated texture meshing code
that now also impacts in nasty ways on scaling and interpolation quality... i
can get into having to avoid the software pipeline bits of xrender - were you
to partially accelerate it in glamo (its partially possible - but not enough
of it to the point where i'd consider it a win to do).).

yes. glamo can accel. yes - xglamo accelerates blits, fills and xvideo. its
not unaccelerated. yes it can to gles1.1 (at a very low/limited spec). in my
playing with gles even the high-powered gles chipsets (sgx and 6410) are not
fast. they are quite slow - at least trying to get them to do 2d and comparing
them to software routines doing the same (blending, fillts, blits, etc.).
xrender (thus aa text that uses xft etc.) can be sped up partially, but not
fully. the moment you can't fully accelerate a whole subsystem.. you need to
stand back and think "some bits speed up - some bits "slow down" (compared to
doing to 100% in software).

you need to weight up "will the sped up bits outweigh the slowed down bits so
overall i win?". that call - at least when i looked at it, i made in favor of
"unlikely to be a win - chances are you will just break even, and have spent a
lot of time on code and debugging it, making it stable, just to have gone
precisely nowhere". that was my conclusion. others may disagree. that is fine.
if you disagree strongly enough - implement the acceleration and show to me i
am wrong.. and i'll happily go "oops - well. i was wrong!" :)

i know i dont want to spend months of my time on acceleration i believe will go
nowhere. i can get better gains from spending that time on other code :)

> That should be fine.
> 
> Of course, if the phone has no future....
> 
> Thomas White wrote:
> > On Fri, 03 Apr 2009 21:14:16 +0100
> > Ian Stirling <OpenMoko at mauve.plus.com> wrote:
> >
> >   
> >>> What is the bandwidth for memory moves?
> >>>       
> >> About 6-8 or so - with 100% CPU utilisation
> >>     
> >
> > Or "one pixel per 2D engine clock cycle" for moves inside Glamo's memory
> > using its blitter (i.e. VRAM->VRAM).  I think that in the Freerunner
> > the relevant clock runs at 50MHz, but I haven't managed to properly
> > decipher what's going on in that regard.
> >
> > Tom
> >
> > _______________________________________________
> > Openmoko community mailing list
> > community at lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> >   
> 
> 
> -- 
> Iain B. Findleton
> Tel: 514-457-0744
> 
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
> 


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





More information about the community mailing list