[E-devel] X11 dependencies hardcoded in ecore_evas

[Carsten Haitzler (The Rasterman)]

On Sun, 18 Apr 2010 11:22:24 +0200 Ed Kapitein <ed at kapitein.org> said:

> Hi Carsten,
> 
> Thanks for all the time you take, answering questions about glamo in
> this list, i really appreciate it.
> I am sure i don't understand half of the technology bottle necks that
> the glamo has, but if the limit is 512x512 for 3D and 2D, would it be
> possible to just use 480x512 on the FR? or even 480x480?
> 
> 480x512 would leave +/- 12 mm screen unused, but i think that could be a
> fair trade-off if the rest of the screen is much faster ( for video and
> such )
> And perhaps the unused space could be used as status bar or top shelf.
> 
> Is this at all possible? i have no deep knowledge about graphic chips,
> so the simpler the answer, there more likely it is that i will
> understand it :-)

i didn't look that far. if you can't use all of the tiny 2.8" u have - it's
useless. imho. waste of time. you could try rendering in multiple passes with 2
buffers and piece them together i guess - but by that stage it was plain -
glamo wasnt intended for vga. qvga was its intended resolution. run at qvga and
you'll be ok. but that will be the case with software rendering too.

> Kind regards,
> Ed
>  
> On 04/18/2010 03:53 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Sun, 18 Apr 2010 03:05:24 +0200 mobi phil <mobi at mobiphil.com> said:
> >
> >   
> >> Thanks for the detailed answer... You told me what I did not find out in
> >> weeks :)... nevertheless:
> >>
> >>
> >> if you are talking of directfb accelerated on top of glamo - good luck.
> >> last 
> >>> i
> >>> checked it wasn't and you'd have something a LOT slower.
> >>>       
> >> No.. there is nothing... was thinking to write sthg. on top of Thomas
> >> White's:
> >>
> >>  http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html
> >>
> >> drm/kms work.
> >>
> >> My main point was to have sthg. that is common to both X world, and fb (Qt,
> >> non-X elf etc, other lightweight fb apps), the lowest c. denominator.
> >> And that could have been directfb, but I am more convinced that not. One of
> >> usage of this c. denominator would have been to have a "global" keyboard,
> >> that would cold be rendered on top of any application. "taping" the
> >> rendering engine, probably would have been easy.
> >>     
> > dfb isnt common to fb and x11 - it is an enitre display system of its own.
> > there is a specific xdirectfb server on top of dfb. but it is not a common
> > component. i think you misunderstand directfb... :) but - you'd need all the
> > acceleration written and even then the chip simply is not capable of many
> > ops you need or it makes them needlessly complex (you will need to go via
> > the 3d unit and that limits all pixel primitives to 256x256 as a source and
> > output cant be more than 512x512 for any buffer - you'd need to do complex
> > tiling of all input and output and that will wreak havoc on things like
> > transforms/scaling to make it look right - and effectively make it
> > impossible).
> >
> > trust me - have full hw docs. had them from the day i started with glamo
> > long before gta02 came out. after some reading i went from excited to
> > despondent. glamo does not live up to what it seems to appear reading its
> > checklist features. sure - it's possible to go accelerate some things and
> > get some benefit. for each of those you now have a downside as u need a
> > software fallback for the ones you can't - and... those now get more
> > complex WITH more overhead. you make operation a 2x faster and operation b
> > gets half the speed. and so on. my bet is that even if you do it all as
> > optimally as possible with glamo+gta02 arch - you will have spent a
> > mountain of effort going nowhere. ie not be able better in general. some
> > things improved, some worse. and now you have a monster of complexity that
> > has no future. glamo is a dead end chip. openmoko a dead end product line.
> > a source base that will not be useful for any future hardware developed nor
> > even todays hardware. the future is mostly opengl-es2 based with the
> > ability to punt off preparation pipeline stages to multiple cpu cores - or
> > if you are lucky, some dsp cores. as such even without this punting off to
> > multiple cores, with gl-es2 - things work damned well - silky smooth on a
> > modern soc. thats including rendering everything at 32bpp, compositor in
> > x11, and more.
> >
> >   
> >>> the hardware there is a dead end. sdl doesn't provide any acceleration
> >>> itself anyway - sdl is a
> >>> wrapper to get a dumb fb. evas's raw fb engine/support will be just as
> >>> good, if
> >>> not better.
> >>>       
> >> in this situation, I admit, no point to have nor directfb nor sdl. Just a
> >> broken illusion, that efl on top of directfb would make things faster.
> >>     
> > :)
> >
> >   
> >> But I can draw very fast the conclusion that in case of glamo, running
> >> illume and other apps, there is no point to have X windows...
> >>     
> > i disagree. how do u think you get a vkbd up on screen separate to the app,
> > or the top-shelf (place for app name, battery, reception etc.) ? i think
> > you are under the illusion also that somehow windows have some massive
> > overhead in x11
> > - they don't - they are simply clipping regions for doing draws - that go to
> > the framebuffer (with compositing - different story with redirection but you
> > end up producing the same design no matter the display system).
> > clip regions are just a list of rectangles "only draw within this region"
> > when drawing. you ask x11 to do the drawing to the fb for you to make sure
> > all of this is co-ordinated and the clip regions obeyed. x11 is also
> > asynchronous and buffers so its NOT:
> >
> > draw thing, wait for x, x sends "draw done",...
> > draw next thing, wait for x, x sends "draw done"...
> >
> > that'd be stupid. you CAN write code that works like that with x11 - but
> > then i'd shoot you to save the world a little more oxygen as you'd be using
> > up too much of it. :) (joking! but you would be stupid) :)
> >
> > in x11 (with efl) it's like this:
> >
> > prepare stuff locally, send draw, send draw, send draw, prepare locally,
> > send draw, send draw, send draw, .... frame finished
> >
> > at frame finish it waits for x (to syncronise and make sure app doesnt go
> > and queue many frames ahead of what x has managed to draw/copy to the
> > screen). all those prepare/send happens in the app without context
> > switching to x11 - there is no overhead compared to anything fb oriented.
> >
> >   
> >> I wonder if anybody from the openmoko community can confirm that efl would
> >> be faster with accelerated X, what I doubt... probably the opposite, at
> >> least what concerns loading times, as less binary has to cross the narrow
> >> channel.
> >>     
> > in theory xrender could accel some things, but it'd lose on others. as i
> > said - i gave up on xrender - on desktop it's a waste of time. the only
> > thins worth bothering with these days are:
> >
> > 1. software (use cpu - or multiple cpu cores - i include dsp's and other
> > such things here if you can specifically write code that they run to
> > prepare/munge/calculate data).
> > 2. use opengl(-es). if you want shaders thats opengl-es2. and yes - you do
> > want them. this means closed binary drivers n all cases these days. glamo
> > is not capable of gl-es2 - gl-es1.1 which is shader-free. glamo also is
> > very limited in its gl features - like 256x256 max texture size, 512x512
> > max render/3d buffer (thus u cant even to 640x480 in 3d - vga is already
> > pushing the limits of glamo.if you look at it it was designed for qvga -
> > maaaaaybe hvga at a stretch - vga was just a "well lcd controller can do it
> > - lets say we can do it to look good on spec sheets". it's like saying that
> > your vw beetle can pull a semi-trailer - sure, on a flat smooth road, in
> > 1st gear only, at 2 km/h - but it "can do it".
> >
> >   
> >>> as such directfb is little-loved and not maintained. as and engine. sdl is
> >>> being loved/used on the palm pre (webos) and it works there, so no idea
> >>> what's
> >>> up with you there, but they seem to be having some fine success.
> >>>       
> >> Honestly I just discovered, that you guys do a superset of directfb
> >> features. And directfb did not evolve the last 4-5 years since I keep an
> >> eye on it..
> >>     
> > correct. :) dfb came and well - went. there was excitement over it - but it
> > never got anywhere. it's a dead end unfortunately and so the engine gets no
> > love. nothing dfb does that x11 can't do these days - and then some.
> >
> >   
> >>>> The intention of my experience was to see if evas/ecore would behave
> >>>>         
> >>> better
> >>>       
> >>>> on top of a potentially accelerated directfb backend. However as far I
> >>>> understood from the code evas/ecore would have zero benefit from a 2d
> >>>> accelerated directfb driver.
> >>>>         
> >>>       
> >> Sorry.. what do you mean "as far as I understood" ... you did not write
> >> that part?
> >>     
> > you wrote that one. you'll have to ask yourself that question :):):)
> >
> >   
> >>> in theory they would - fact is directfb won't be accelerated. all the
> >>> rendering
> >>> is done by evas - ecore isn't involved there beyond providing events and
> >>> mainloop. but dfb is not maintained and behind. as such it's very little
> >>> used
> >>> in real life and not worth the trouble. nothing dfb does can't be done in
> >>> x11.
> >>>
> >>>       
> >>>> My question is:
> >>>>
> >>>> 1. as  was reading on some other threads that one wants to get rid of
> >>>> Xrender. Would however efl be able to use some 2d acceleration (blit from
> >>>> videa ram to videa ram, draw/fill rectangle etc.)
> >>>>         
> >>> useless when all the other ops are slow. waste of time and effort. i've
> >>> been
> >>> wasting and waiting for a decade. i've had enough of it. xrender engine is
> >>> already partly broken as it doesn't support some of the modern things like
> >>> map.
> >>> note that on glamo xrender als is not accelerated and in fact is not able
> >>> to be
> >>> properly accelerated and you will have lots of software fallbacks doing
> >>> read/modify/write across the anemic video bus to glamo. i've been here.
> >>> long
> >>> ago. i have the full glamo hw docs. i read them in entirety and made
> >>> decisions
> >>> off that. what you see in the checkbox list of features vs what glamo
> >>> actually
> >>> does makes you think again about it as a useful chip.
> >>>
> >>>
> >>>       
> >>
> >>     
> >>>> 2. is there any "interface" to inject some 2d accelerated code into the
> >>>>         
> >>> fb
> >>>       
> >>>> driver?
> >>>>         
> >>> no. you do a new engine. eg fb-glamo. it will fail becauuse in the end you
> >>> will
> >>> create something very complex that is actually no faster. you will win on
> >>> operation a and then lose on operation b. glamo's problem is its
> >>> operations are
> >>> asymmetric. you can use rgba as src - but never create rgba as a dest -
> >>> only
> >>> rgb565. pointless for intermediate buffers than now need fallbacks. also
> >>> leads
> >>> to cumulative rendering error when dropping down to rgb565 and quality
> >>> will suffer badly.
> >>>       
> >> hm... did not know this issue with rgb565... You mean I cannot blit from an
> >> "unvisible" VRAM area to the "visible" one?
> >>     
> > you can - but there are limits on the source and destination formats. and
> > formats directly have vvisiblee implications - eg NO alpha channel, or 1 bit
> > onoff alpha - or rgb4444 (4 bits for r, g, b and a only) and so on.
> >
> >   
> >> The idea was, when scrolling (like when moving maps) to redraw only new
> >> parts, and the rest do by two copies inside the VRAM.
> >>
> >> I wonder if there is sthg. similar implemented for scrolling in Xglamo..
> >>     
> > not possible in the efl world. evas is designed to work with modern gpu
> > architectures - and that means redraws due to alpha channels and just
> > general gpu design (as games dont blit. they redraw the whole screen every
> > frame so gpu's are optimised for redraws). the scrolling you think of is a
> > subset of what evas actually does. in the end it just does a redraw as that
> > covers all cases.
> >
> >   
> >>  > For example the most annoying on openmoko freerunner is slow scrolling.
> >>     
> >>> For
> >>>       
> >>>> example your map example becomes the same sluggish. This could be
> >>>>         
> >>> probably
> >>>       
> >>>> solved by scrolling through a temp invisible video memory buffer.
> >>>>         
> >>> the freerunner itself is slow - it's a very poor piece of hardware.
> >>>       
> >> We know that... And the most annoying is the scrolling when everything has
> >> to be redrawn, whereas only parts should be.
> >> Well.. in the worst case I will understand that it is impossible (hower it
> >> does not seem to be)..
> >>     
> > not in efl design - doing what you want creates limitations - and those
> > limitations then perform poorly on other modern rendering mechanisms - thus
> > in return for making a a poor bit of hw a little better - you screw
> > yourself for the future. all the toolkits have had to change their ways and
> > move to a "redraw things" model to work with gpu's and modern requirements.
> > efl just started there from its design and thus can be 100% gpu accelerated
> > as its design is in-step with how gpu's work. the software enigne has an
> > optimised redraw path too - and it tries to limit redraws where it can. but
> > you can't just blit as that doesn't work if your drawing model is more
> > powerful - like having alpha channels etc. yes - you can go on about not
> > wanting/needing them and being a waste of resources - if thats all you care
> > about then efl is not for you. you can do your apps in raw xlib - or gtk if
> > you like, but you will hit their limits eventually, but.. that assumes you
> > will move off the freerunner eventually to some hardware that is vaguely
> > modern.. but then you will have painted yourself into a corner and want all
> > the features efl has offered for years and need to redo everything
> > anyway... so more work.
> >
> > time is money - and i am very short on time. hardware is cheap and easy to
> > come by - compared to time. the time to invest in things lime freerunenr
> > (glamo +s3c2442 etc.) is simply not worth it as that kind of model is a
> > dead-end.
> >
> >   
> >> scrolling in efl is a redraw. why? because doing otherwise is nuts -
> >>     
> >>> especially
> >>> if you want to support things like opengl. also in the need when people
> >>> want
> >>> their translucent list items with static bg's etc. - you do redraws
> >>> anyway. you
> >>> can cut out some redraw with intermediate buffers - but then you pay a
> >>> price in
> >>> memory usage.
> >>>       
> >> in memory usage of RAM or VRAM?
> >>     
> > wherever the buffers are stored. depends on the rendering subsystem.
> >
> >   
> >>> you can do this via map... but.. gasp.. that needs an
> >>> intermediate buffer and... glammo cant generate those other than in
> >>> software.
> >>>
> >>>       
> >> what do you mean "other than in software"
> >>     
> > there is no silicon on glamo to do it. i'm now talking 2d.
> >
> >   
> >> I think with drm/dri it can be done ..
> >>     
> > drm/dri cant do anything - they are simply interfaces to get access to the
> > gpu hw - get memory management sorted and access to the registters or
> > cmd-queue. the actual gpu is not covered by dri/drm.
> >
> > glamo has a 2d subsystem. it has a 3d one. the 2d one has a max size of
> > 640x640 for any source or destination buffer. this is already close to
> > useless as yes - images and buffers do extend beyond 640x640 - this means
> > you need to create a tiling architecture for all pixmaps etc. and
> > source/dest buffers/primitives. hooray. the 2d engine can handle argb32 as
> > a source format - but not as a destination. this is the ACTUAL chip - the
> > transistors. the silicon. it CANT do it. so - you need to use software to
> > render to argb32 buffers as glamo can't. the simplest way to deal with the
> > 640x640 limit is to use software instead of any hardware for source or dest
> > buffers bigger than 640 in any dimension. ho. did i mention you will need
> > to migrate these buffer (copy) in and out of video ram? hardware can't work
> > on them if they are not in vram - and software will take a big speed hit if
> > it works on them directly in vram - so copying out first is good if you
> > then will do lots of work on the buffers, but copying is a cost. software
> > engine (100% software) can get away with 0 copies until final display of
> > buffer. in some hybrid some accelerated, some not driver you will be
> > copying around often during draws and the overhead of all of this - or of
> > software directly working in vram trying to not copy, will negate any gains
> > you make by using glamo to accelerate some ops. you likely will come out
> > slower even. 
> >
> > now there is the 3d unit - here it has more limitations 256x256 for any
> > texture - thus the above 640x640 tile limit but worse. you will hit this one
> > almost instantly. then you need to do meshes. and thats a pain - also
> > suffers quality-wise and complexity (and thus speed due to complexity
> > overhead). max dest buuffer - 512x512 - also limited. cant even cover the
> > screen. that alone is enough for me to say the 3d unit is useless for
> > anyting other than trinkety little qvga 3d games with low resolution
> > textures (where if you have a TEXTURE for a game you wrap around a model -
> > you can afford to have it degrade to lower res - and display quality simply
> > duffers with blurry textures, but this not possible in 2d - you cant make
> > such tradeoffs. howd you like your text to be blurry and buttons to be
> > blurry/blocky blobs? due to the images being used being dropped to 1/2 or
> > 1/4 resolution etc. etc. - in 3d you have triangles define the shapes and
> > outlines of your primitives and textures simply add "skin". in 2d - not so.
> > and the 3d unit n the glamo is at best useful for such simple 3d game-lets
> > and tasks, nothing vaguely serious. it's interesting that 2d actually is
> > relatively demanding on 3d units mostly due to it not being able to make
> > such quality tradeoffs very often.
> >
> >
> >   
> >> -- 
> >> rgrds,
> >> mobi phil
> >>
> >> being mobile, but including technology
> >> http://mobiphil.com
> >>
> >>     
> >
> >   
> 


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