On Sun, 18 Apr 2010 11:22:24 +0200 Ed Kapitein <e...@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 <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 _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community