On Sun, 18 Apr 2010 03:05:24 +0200 mobi phil <m...@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) ras...@rasterman.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
