did not "reply to all" ... so here is the forward maybe it is of interest
for someone else...
Changed the topic name....
Thanks for your time for helping clarifying the mistery
> 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... :) \
No!!! I do not misunderstand... Yourself you said the same... Indeed there
is a simple xdirectfb on top of dfb. So If everybody, Qt based apps (QtMoko)
and X would talk to directfb, then directfb would be an almost perfect
lowest common denominator.
> 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).
>
Why would I go through the 3d unit? Again... I have limited info, but what
is the most important is to have at least the
>
> 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.
If one would get the first 80% (that is for me scrolling and maybe huge fill
rects), then I think it would be a huge step, or?
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.
>
Why would op. be get half speed? Unless we are talking about concrete
example, would be difficult to argue.
> 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.
Not dead end for me and others who bought it. I think 99% people on the list
have more interest to improve/hack as potentiality, not as commercial
intention etc.
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.
>
That is also true... unless I spend another few bucks, I will not get
another hardware...
>
> > 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.) ?
There are ways... directfb has also multi app mode and basic window manager.
The vkbd as I mentioned would be a completely different story. The magic
idea (and this could apply even in the future for opengl stories) is to
capture any "paint" access to the video, and as final step redraw the (full
screen transparent) keyboard on top of it with a given alpha.
> 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"...
I know about X arguments. However I was reading even on efl homepage
somewhere the argument that efl apps on fb are much faster than on X
windows. On the other side, as mentioned in my prev emails, loading X and
apps adds to slowness due to a little fat libraries.
>
>
> 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.
>
Well as far as I know direcfb does the same... draw draw draw (internally
clipp if necessary) and then Flip.
> > 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:
>
I wonder what could xrender accelerate if you do not give it the oportunity.
Maybe you should know based on the code if any oportunity is given. But
probably not. If a new frame is prepared each time, I do not think that
Xrender would do any delta to send only deltas etc...
> 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).
>
Do not necessarily agree. Again... do not know too much about glamo. But,
again let's take the already mentioned example with scrolling. Given that
scrolling adds some 5% of new info and removes 5%. Why would you prepare the
full 100% of the frame and send it to any VRAM (lets not talk only about
glame), when it would be just two memory copies in VRAM (done with 2d
commands). I can bet that on devices like iPhone scrolling is implemented
like that.
> 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".
>
I was convinced about blown up spec sheets from the first day I had the
device in my hands. I started a thread on openmoko with sthg. "glamo is
slow, is that a bad joke?"
Honestly, personally I have 0 interest in 3d. I need decent 2d especially
for maps and reading some basic text.
>
> > > 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 :):):)
>
:) ... sorry.... with all this quote the quote the quote:)
>
> > 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.
>
Personally would be happy with less colors, but smoother ops. But... hm...
few months ago was playing with some commands. Was drawing rectangles in
random position with different flags. I had the impression that something
more than on/off alpha was happeinnig... hm.. will redo that
>
> > 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.
>
Well, I believe you ... but after looking deeper into gui/drawing patterns,
was a bit dissapointed.
>
> 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.
>
well after all I agree...
>
> > 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.
>
still did not understand this. I will quote again your original text:
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. you can do this via map... but.. gasp.. that needs an
intermediate buffer and... glammo cant generate those other than in
software.
You have 8MB (if remember well) of VRAM. We have enough for intermediate
buffers, or? Whoever (opengl) was drawing, we move the 90% and let opengl
repaint the rest..
> > 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.
>
"can be done" I mean to have access to the full VRAM (or more than the
/dev/fb0). -- well I am still focusing on scrolling --
>
> 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.
>
I will need to read more... Probably I have a simplistic idea about several
things... Maybe you could "share in secret" all those documents you were
talking about... It is easy to be king of the castle if you have the wisdom
in your hands :)
What I thought was that you have the "visible area" (the one thatmaps to
lcd) and rest invisible, where you could store/do whatever you want. So you
have 16 bit depth (I even do not know why we are talking about 32 bits)
areas. The visible area is 480*640*2 bytes lets call it A. And for the
invisible one we allocate again 480*640*2, we call it B. So what you say
that we cannot just copy with 2d engine A to B ?
Let's assume that this works.... But... Well.. for scrolling I have oversee
a little detail. copying from A to B+ y*480*2 can do simply the scrolling
down /up, but hm... not scrolling left right... Baffffffff!!! that means I
would need to send almost 640*2 commands to the engine to move each line "a
bit left" or " a bit right"...
> 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.
>
well... I started to "feel" the full picture...
> 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.
>
> ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) ras...@rasterman.com
>
>
Spendito time ergo sum (" I spent time therefore I am " -- in very vulgar
latin :) )
Well... thanks for all the clarifications... Well openmoko and glamo will
remain a playground to learn how not to do things, with less chance to learn
how to do :)
--
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
--
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
