Centralization of graphical awesomeness

Carsten Haitzler (The Rasterman) raster at rasterman.com
Tue Oct 27 01:52:04 CET 2009


On Mon, 26 Oct 2009 23:16:45 +0300 Gennady Kupava <gb at bsdmn.com> said:

> Dear Carsten,
> 
> E is nice thing, but it look like highly unoptimized.

i beg to differ. it's more optimised than pretty much anything out there. read
what i wrote. watch some videos. try run something COMPARABLE.

> Yes, freerunner device is slow, but it is embedded device, and it's
> impossible to continue kicking glamo which is already dead, as only
> reason of slowness. People with GTA01 have no glamo and that? Is it
> better? As far as I know - not.

look at my videos. i have done efl on older slower "embedded devices". ipaq.
206mhz arm. 64m ram. qvga. efl was much faster. i have it on a host of devices.
the freerunner is by far the worst device given its age. even if it came out in
2001 or so when the ipaq did - unlesss it was qvga, it'd have also performed
more poorly than the ipaq.

> > http://www.rasterman.com/files/ello-elementary-smartq5.mp4
> 
> Thank you for videos, but on high-resolution one we can see exactly same
> slowness as on FreeRunner - exactly! See how top bar slides out  on
> close of clock and button test - exacly as on my FreeRunner. Look how
> slow scroll is, again as on FreeRunner!

that's because you have 2 processes competing for the cpu to render. it's not
slow. it is not consistent because of 1. having to compete for cpu and IO.
nothnig to do with optimisation.

> That is that 7mb? Bandwidth we can use to update glamo contents? We can
> count that 7mb if 10 fully updated frames for 640x480 at 16bit? This
> looks much more that enough.

for every second spent uploading contents to glamo, you CANNOT spend it
calculating a new fram. that's the problem. you lose a lot of cpu as a result.
ok. let's say.. 10 frames can be updated. you have 0 cpu time left to generate
those frames! if it was local memory you've be able to copy 10 frames AND still
have probably 2/3 of cpu time left to generate them.

> Also, I installed Qtv14 (thanks to Radek for that distribution), and
> that I see? I is fast enought, scrolls fast, react fast, and so on. So,

scrolling is different in qt. it is a simple blit. in efl it's a redraw. efl is
very much like GL. you get a lot of power and abilities with it, but you do
pay a price for it. unlike qt, efl's scrollers have smoothly scaled item
contents, backgrounds, translucency and everything. if you make the theme
SIMPLER with just solid rectangles, like qt - efl will begin to be closer to
the same speed. all that pretty stuff comes at a cost. and people want their
pretty. tone down the theme to bare rectangles and text and it'll be faster.
comparing qt and efl is apples vs oranges. efl simply does a hell of a lot more
in the graphics department. and people are using that "hell of a lot more"

> E and E's programs just need optimizations. Openembedded in all sucks,
> as it brings no benefit (same glibc and kernel) with bunch of drawbacks
> - no easy way to compile for it, so (for me) it's uneasy to figure out
> that's going on with E. No oprofile where.

you have no idea how many optimisations they have. saying they need them is
like saying "linux needs virtual memory! it just needs it!". it HAS it. in
spades. read the code. you wont find routines for rendering faster in most of
the world. (when it comes to software). the other engines can full offload to a
subsystem (gl, xrender, etc. etc.) *IF* it is there. WHAT e is doing is
different to qt because thats how it is being used. if you reduce what its
doing to be the same as qt, you will find the speed becomes similar. the reason
qt looks faster is that it is simply doing less.

> I wish E to be faster!
> 
> Gennady.
> 
> В Пнд, 26/10/2009 в 22:51 +1100, Carsten Haitzler пишет:
> > 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


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




More information about the community mailing list