[E-devel] X11 dependencies hardcoded in ecore_evas
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Sun Apr 18 03:53:09 CEST 2010
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
> 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
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
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
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
> > 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
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.
> mobi phil
> being mobile, but including technology
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
More information about the community