Centralization of graphical awesomeness

Mon Oct 26 14:11:26 CET 2009

On Mon, 26 Oct 2009 12:23:51 +0000 Vasco Névoa <vasco.nevoa at sapo.pt> said:

> 
> Downgrading to QVGA is something that should have been done a long time ago.
> There's no point in trying to force a badly designed system.
> 
> How do we do it? Which files must be changed?

last i checked... 1. xmd-line option to xglamo (kdrive) server to select it, 2.
xrandr to runtime select it. note that toushcreen driver didn't account for res
change so ts coords were still assuming 480x640 - this is a small fix needed
for it to be totally usable. not sure if this was ever fixed, but if it
hasn't been - this is a good indicator of how no one has bothered with qvga.
thus the complaints. try it. you'll find it significantly faster. see videos
below - 206mhz ipaq3660.. smooth.

> Citando Carsten Haitzler <raster at rasterman.com>:
> 
> > On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin  
> > <anthropophagite at gmail.com>
> > said:
> >
> >> 2009/10/26 Carsten Haitzler <raster at rasterman.com>:
> >> > you want speed? you will need to give up something. if you still  
> >> want it to
> >> > look nice, then drop pixels. its the simplest and easiest  
> >> solution. its the
> >> > right resolution for that cpu anyway. the glamo will still hurt you, but
> >> > not as much.
> >>
> >>    I'm sure everybody who has any professional connections with
> >> Freerunner+Glamo development already took all possible measures to
> >> solve this problem. But what concrete steps were taken to ease Glamo
> >> bottleneck? If its throughput is so narrow, can we lower amount of
> >
> > none. it's a hardware issue. you simply cant read or write to video  
> > ram faster
> > than that. andy tried timing stuff all that happened was instability from
> > memory. glamo is most likely also the cause for the cpu runnig at 400 not
> > 500mhz. the extra load on the memory bus (because glamo is hooked there
> > externally providing another addressable chip) probably caused the  
> > instability.
> > remove it and there is a big change the cpu could run at 500mhz  
> > instead of 400.
> > it's rated to do 500. (yes power consumption would go up - but it'd  
> > only be up
> > while its on. when suspended it wont matter).
> >
> >> data flowing through it? There's one neighbor unanswered thread with a
> >
> > render on the device - and this will then limit what you can render.  
> > evas can't
> > be fully accelerated by the glamo. it has too many opretations. a bit like
> > asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx
> > chip ever was designed to do and you will hit software fallbacks. evas has
> > multiple engnines. software (which is what is used - the 16bit renderer as
> > opposed to the full 32bit one). it has xrender - if xrender were fully
> > accelerated this should be better, but glamo cannot fully accelerate all the
> > ops evas uses, so... it will rely on software fallbacks. thus slow  
> > down. my bet
> > is you'll end up same speed as the pure software engine, or worse. aftera
> > bunch of hard work you'll have gone nowhere. evas also has a gl and gles2
> > engine - but thats no use on glamo. it's gles1.1 and very limited  
> > (from memory
> > texture size is 256x256 which is pretty useless for 2d as most data you deal
> > with breaks these bounds).
> >
> >> question on how to start the kernel with qvga resolution. Aside of
> >
> > no need to do that - just configure x for qgva. :)
> >
> >> this, what can be reduced, for example amount of available colours
> >> (256 or even 16)? And if this [too] low throughput only of video
> >> memory channel?
> >
> > 256 won't help. it increases complexity and really reduces display quality
> > through the floor. the best best is qvga 16bpp. its simple. it  
> > doesn't require
> > any hard work. it is actually the most common resolution for most phones and
> > devices out there so the software is more portable if you work on that (and
> > then higher). but... in the past everyone has moaned and complained  
> > and refused
> > to use it, and insisted on their vga resolution... and then complained about
> > speed.
> >
> > if people don't believe me that the gta02 is just plain a "bad bit of
> > hardware and you have few choices" here's some examples. here'es an ooold
> > efl demo app i did:
> >
> > http://www.rasterman.com/files/eem.avi
> > and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash,  
> > qvga(240x320).
> > it's from like 2001/2002 (from memory). its ancient. and watch it run evas:
> > http://www.rasterman.com/files/eem-live.avi
> >
> > here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m
> > ram, and 800x480 (higher res than gta02):
> >
> > http://www.rasterman.com/files/ello-elementary-smartq5.mp4
> >
> > everywhere i look... theres much better hardware. if you look at  
> > performance vs
> > age of hardware (when it was released) gta02 is almost at the bottom of the
> > pile. :( you simply have a bad piece of hardware if you want graphics
> > performance. as soon as you acknowledge that and either downgrade the device
> > resolution for example to bring it in line with its performance, or just use
> > different hardware, the better life will be :)
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler)    raster at rasterman.com
> >
> >
> > _______________________________________________
> > Openmoko community mailing list
> > community at lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> >
> 
> 
> 
> _______________________________________________
> 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