Hello, In France, one of the major ADSL provider, just give an SDK to develop on there "box". It based on javascript and EFL (from rasterman, that does Enlightenment, E17, it was pretty well known in the past in the 2D area). EFL is used on this "freebox" but also on next phone of Samsung or sony-ericson.
EFL is a clean and fast 2.5D library that will be used in embedded area. I had ask the main maintener some hints for hardware developement. To make it short, it goes to opengl-es2.0, to avoid having to much code path. I transmit you his complete answer. Regards, Nicolas Boulay ---------- Forwarded message ---------- From: Carsten Haitzler <raster> Date: 2009/11/22 Subject: Re: Graphical hardware for EFL To: Nicolas Boulay On Sat, 21 Nov 2009 18:14:34 +0100 Nicolas Boulay said: > I follow the project opengraphics. The goal is to create an "open > source friendly" hardware. They open also the specification. > > The performance are around ATI 7500 and fixed 3D pipeline. > > I would like to know what is usualy the bottleneck of the performance > on the EFL what could be interresting to add, when the host cpu is > weak. What is the basic fonctionnality that are always too slow? depends on what you are doing, and engine. i'll explain a bit. 1. rendering and "canvas state" is evas's job. everything else builds on top, so this is the core you care about. 2. rendering in evas is abstracted to engines that much like a high-lexel xaa/exa thing i x, abstract the nuts and bolts of doing the drawing. evas takes a scene-graph/canvas and figure out what changes, how and how to draw it, and then asks the engine to do the immediate-mode rendering 3. engines are modules. they are pluggable and loadable runtime. it is the app that selects the engine, not evas. different engines may come with different caveats. the engine does whatever it was designed t do - call opengl calls, xlib, just sit and spin in software rendering routines, xrender, whatever. so... we have many engines: 1. software_generic based ones 2. xrender (tired of xrender blowing goats nuts, so might kill this one off) 3. opengl(-es)2.0 4. software-16, directfb.. direct3d, ... more - i'll ignore these for now the software_generic engines use the cpu to compute everything. all rendering is software. the only bit where you interact with your display target is "how do i copy my rendered pixels to the display?". fb engine simply does a conversion from argb32 to screen format and copy in one pass (all software rendering is 32bit) - just fyi the software-16 engine is a totally 16bit enigine (i'd like to see it die - pita to maintain, not to mention quality is attrocious). anyway - the x11 engine uses xshm to copy - it has even a shm segment cache to avoid re-allocating segements to copies. updates can be any region of the canvas from 1x1 pixel to the whole thing and any number of them per "frame" (render). all software engines inherit from a generic one and just implement the display layer things (via x11+xshm, /dev/fb, sdl, win32 gdi, etc. etc.). so these engines are totally cpu+mem bandwidth bound (unless somehow there is an awful bottleneck in copying data to the screen - this does happen on some platforms). the more mem bandwidth, lower mem latency, bigger faster caches, more clock cycles.... the faster it goes. the software engines are pretty much the default you see everywhere. all the rendering is pumping the cpu. why? it's stable. it's fast. it works everywhere. it looks good (better than gl or xrender as scaling is higher quality - downscaling is full super-sampling for example). xrender engine is as of now, incomplete. doesn't do the new map (3d/rotation) stuff. i'm not feeling interested in bringing it up to snuff. i'm tired of xrender blowing goats nuts. i've had an xrender engine for years and years. i've benchmarked and played with xrender since like 2001 or so. i give up. let it die. technically this would be a very good engine to use as in theory it shoudl be possible to be fully accelerated - anywhere that does decent 3d - it should manage this without issue. but alas - not the case. it tends to be horribly done. only some common paths done. transforms generally being ignored. so i give up. gl engine... this is where the acceleration is at these days. it's opengl2.0/ gl-es2.0 - it does both from 1 codebase. this means its totally shader based. no shaders. no go. no fixed pipeline support. will not be any. why? opengl-es2.0 is ONLY shader based. no fixed pipeline. i'm not going to maintain both paths - in addition to the mountain of other code to maintain. it needs to be cut down. too many damned engines. anyway - this uses modern GL features. FBO's + render-to-texture, vertex buffer arrays (vbo's are not immensely useful, but i have considered using them to reduce geometry overhead which is pretty high when doing text). use shaders for yuv to rgb (yes - planar yuv gets nicely supported here as i have 3 textures, a y, a u and a v plane and the shader does the piecing-together). shaders also do the argb -> rgba swizzling for rendering (mostly because opengl-es doesnt understand the most common argb (or bgra as they call it) pixel format thats pretty much the format-du-jour of anything 2d in the past decade). yes - extensions exist. not everywhere. shaders solve it universally. also eyeing using them for filters (blur for example). > I would like to know if a small change or fonctionnality added to > opengraphics could speed up EFL. and now i get to this. the above was an intro so you know how it works. so... you won't speed up the software engine unless you have a bottelneck in copies to screen. xrender is one thnig you'd probably want to do- including transforms. but beware. i'm on the "tired of this shit" bandwagon for xrender. so not sure effort will help as it may get axed. it's not you really - it's every other gfx unit out there. nvidia's acel is half-arsed. fglrx is worse. nouveo and radeon/ati drivers for me are no-goes as i need properly and fully done GL drivers. i have real-life targets to keep in mind like embedded systems. and yes - u'd need a properly baked gl on desktop to emulate. odd, but true. and then there's the GL-ES world. i've chosen the path that gets me the sanest code with the least work. so... if you wanted it to be fast- do shaders. and make sure you are OpenGL2.0+ - make sure context switches don't kill you (eg gldrawarrays then change blend mode, bind new texture etc. etc.). right now i am limted in texture access due to having no universal way to pass texture id's to a shader (eg like passing vertex coords, tex uv coords, color vals etc. - i'd like to pass "and please use texture from unit #3" but.. thats not possible. odd, but true. it may happen to work in some places, but its only supported as a uniform, not a varying. texture arrays are not useful as in 2d we cant go making all our textures the same size. also supporting non-power-of-2 textures is a pretty important thing. i can work without, but its rather wasteful for 2d. does that help? :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
