On Wed, 23 Jan 2013 13:29:51 -0600 Jeff Hoogland <jeffhoogl...@linux.com> said:
"compositing is the problem" is entirely wrong. http://www.enlightenment.org/ss/e-51007211524a49.09575794.png pentium-600, 2 terms, 1 with animated blinking cursor, other running top refreshing every second. so its far from idle (it'll be generating frames probably > 50% of the time. e is using 2%... terminology is using more than 2x what e is to rendering its terms... and x as well (having to copy pixels to pixmaps and allow e to read them back and then copy pixels to the screen from e's comp when composited). software compositing. "98% cpu usage" is something else. something "continuously animating AND rendering". something likely large. it may re-draw the exact same thing every frame... so you dont know - but it is. maybe its some totally other bogus thing spinning nothing to do with comp at all. maybe the blacklists in evas haven't detected a software gl implementation (they do have specific tests for it). i810 cant do gl with evas. too primitive, so *IF* they are using gl... and somehow evas is not failing, they have gotten themselves a SOFTWARE gl rasterizer.. and THAT is going to eat cpu until the cows come home. i'd love to know the gl vendor/renderer/version strings for that driver so i can blacklist it (glxinfo). until then - they should switch to SOFTWARE. that is assuming its comp + gl + software gl. it could just be a poor theme. something with lots of shaped windows. shaped windows are evil and comp gets a bunch of extra overhead - even with gl, to deal with them. ARGB windows are fine (though now comp needs to alpha blend vs just blit/copy). there ARE situations of high cpu usage even with gl - nvidia closed binary blobs have in recent times regressed to polling spinning gpu/vblank sync - they dont "sleep" waiting for the gpu to screen retrace to begin, but SPIN in a loop thus consuming 100% cpu - this is a DRIVER bug. on weaker gpu's e will use massively less cpu than on these nvidia+high powered gpu combos when rendering. older drivers were much better behaved. i have yet to get around to filing a bug on this as i need to sit down and actually "prove" this before filing and identify the exact point with some debugging code (a bit of /proc trawling around glxswapbuffers etc. should do the trick). > I understand all those reasons, the difference is I'm just going to have to > start telling people like this -> > > http://forums.bodhilinux.com/index.php?/topic/7701-enlightenment-cpu-usage-at-98-on-intel-i810/ > > That they simply can't use E17 because it will eat all of their CPU all the > time with compositing :-/ > > Personally I use compositing on all my system, it looks great in general. > > > On Mon, Jan 21, 2013 at 10:26 PM, Carsten Haitzler > <ras...@rasterman.com>wrote: > > > On Mon, 21 Jan 2013 10:51:01 -0600 Jeff Hoogland <jeffhoogl...@linux.com> > > said: > > > > > Raster had mentioned on IRC last night that compositing had become > > > non-optional in SVN builds already. What is the reason for this? I > > > understand compositing is the future - but forcing it on everyone it > > going > > > to make E much less usable on legacy hardware - a place where it really > > > shines. > > > > reasons: > > > > 1. aesthetics. having to "design" for both compositing and non-compositing > > is > > limiting and painful. > > 2. code simplification - this cuts down mem usage and resource usage where > > we > > make non-compositing code paths redundant (never loaded) or even get > > totally > > removed. it also makes e and efl's code MUCH easier to maintain as we cut > > out a > > whole class of pain. > > 3. if you do non-compositing, then your other option is avoid anything that > > isnt a pure rectangle.. or use shapes... do u have any idea how inefficient > > shaped windows are? do you know how they are implemented? compositing is > > MORE > > efficient than shaped windows except for the most trivial shape cases. it > > also > > has fewer artefacts. don't make me do a rundown on the actual > > implementation of > > xshape etc... i have little enough time as-is. take if from someone who > > started > > doing x shape stuff back in 1996... > > 4. wayland - we cant sensibly become a wayland compositor without ALWAYS > > compositing. > > 5. compositing only allows us to move content out of windows (eg the > > container > > bg window that holds a canvas with wallpaper and your efm icons etc.) and > > merge > > it into the COMPOSITOR canvas. this reduces mem footrpint drastically - > > example. you have a 1600x1200 screen. you have a 1600x1200 walllpaper. e > > will > > keep the rgba pixels for that wallpaper inside its memory because it > > renders > > them to the bg canvas with software. this bg canvas is a window..that is > > composited.. this means this window consumes at least 1 pixmap of memory... > > that means 1600x1200 (8mb) for the original PLUS 8mb for the composited > > pixmap.. to store essentially the same content PLUS some icons. if we move > > it > > into the compositor canvas we get: > > > > 1. wallpaper image is rendered and scaled by the same enigne as the > > compositor > > (sw or gl). > > 2. only the original wp image is needed, not an intermediate window > > pixmap. we > > save 8mb of memory insnantly. > > 3. evas already has caches for scaled data and can throw out original data > > etc. > > so we also recycle this infra directly. > > 4. "animated" wallpapers now get faster as they render with gl... as do > > wallpaper transitions etc. > > > > repeat for everything else in e17... it all goes into the compositor canvas > > EXCEPT "window content" (client windows - be they e's internal dialogs or > > external apps - to e's compositor these will just be image objects - they > > currently are, but they also include the frame window sections > > (borders/titles) > > provided by e - these will be split out to live in the canvas). > > 6. if objects move into the comp canvas - like window borders, menus, > > shelves... we solve the clipping problem. right now borders, shelves, menus > > etc. get clipped by their window. that's life. once they live in the comp > > canvas they can extend beyond their object bounds (add glows, shadows, > > other > > effects or pixels/imagery extending beyond their bounds). this comes for > > "free" > > when moving into evas and out of a window and that is part of the plan - to > > migrate content all into the compositor canvas. > > 7. i can go on... (tldr time - you asked "why" so read, or never ask again > > :)) > > this has been talked about a lot amongst devs already. it's not possible > > to do > > non-compositing AND compositing and move forward. we have little enough > > developer resources as-is. this simplifies and allows us to have a future. > > the > > fact that we BOTHERED to have fast software compositing is a big part of > > the > > commitment to make compositing work for EVERYONE - you DONT need a > > "supported > > gpu + driver" to use it. yes - it means extra system load, and slowdowns > > for > > those avoiding compositing now entirely - but that's the price of progress. > > we've "lowered" the cost, but it isn't "free". no one is totally LEFT OUT. > > the > > software compositor works even in 16bpp (with extra overhead though). and > > 8bpp .. well ok - sorry 8bpp people. if you can only do 8bpp then we're > > leaving > > you behind. sorry. 1995 will be happy to keep you. :( we CAN reduce > > overhead of > > software compositing still - it's heavy because we HAVE to copy pixels > > from x > > (read data via x(shm)getimage). we can't fix that unless we can get a > > zero-copy > > path. x allows us no such path for software (shared pixmaps are not an > > option > > fyi). we COULD shortcut this path - but we need to do it at BOTH sides of > > the > > pipeline. that means modify toolkits/apps. we CAN modify efl to bypass x > > entirely for rendering and only use it for focus/input/events and use a > > back-channel shared memory system to export pixel buffers direct from > > client to > > comp. it's doable. we'd cut overhead in half for copies as we... get rid of > > them (we only have now rendering overehead). *IF* comp also bypasses x's fb > > management and goes direct to fbdev or kms... and does evil stuff... we can > > ALSO make "rendered pixel uploads" totally free. ie zero copy buffer > > swaps. - > > then the ONLY overhead we have is filling the comp "backbuffer". what you > > may > > not be aware of is.. evas ALREADY has this infra. it can already do this > > little > > zero-copy buffer swap trick... all the code is there.. it's even been > > tested > > with real drivers that do support this - there is even a virtual buffer > > swap > > emulation layer to test it if you don't have such a magic driver.... > > BUT... it > > requires driver work to make this possible - or bypassing x's fb driver > > entirely... but we can already do this kind of stuff. we're FAR from > > maximum > > optimal level in sw compositing. in fact if we did both of the above for > > things > > like scrolling your browser window around we'd basically increase > > framerate by > > 3 times compared to now. that's our existing potential upside if we plug > > all > > the bits together. we're far from pure ultimate potential, and even being > > far > > from it.. we are very usable on low end systems. so without a gpu to > > accelerate > > it all and make it all zero-copy... we have a potential upside (for efl > > apps) > > of up to 3 TIMES faster (and a minimum of 2 times faster). for non-efl > > epps up > > to 2 TIMES faster. though at this point.. we're almost being a wayland > > style > > compositor directly, so i'm wondering if we'll ever bother with x stuff to > > optimize this far and just jump to being wayland from there, as wayland is > > all > > about sending buffers around and avoiding copies... efl already lends > > itself > > very well to this. it already has the start of a wayland port and a wayland > > compositor in e17. and as above... we cant move to doing wayland stuff > > unless > > we move to being "compositing only". keeping mind "compositing only" does > > not > > EXCLUDe optimizations like "zeo copy/composite" you do for things like > > fullscreen windows (games etc.). if you do this just right you can take the > > client pixel buffer it sends you (it sends a handle to it - it doesn't > > COPY it > > to you) and you just program the gfx chipset to pint the real hw buffer > > scanout > > to the client buffer. ALL the compositor is doing is updating where the fb > > points to... it's doing zero actual compositing/copying/blending work in > > this > > case. its turles... err.. zero copy all the way down. so your games are not > > affected at all. if at any point some menu or dialog appears on top.. it > > begins > > compositing again for that frame on until that overlayed window goes away. > > given smart enough compositing and the right hardware you can EVEN avoid > > compositing in such simple scenarios.. a lot of hardware supports RGBA > > OVERLAYS > > - multiple buffers blended on top of eachother. your hw mouse cursor is > > exactly > > such an overlay buffer. "xv video acceleration uses such a wh buffer often > > too > > - but its yuv, not rgba... but same principle. a smart compositor can > > PROGRAM > > the overlay buffer to point to this "popup menu/dialog" and keep the 2 > > framebuffers totally separate... zero compositing/copies... until the 3 of > > windows becomes too complex to point directly at hw buffer layers, then it > > has > > to start compositing for real... my point here is... this is the path we > > MUST > > go down. we NEED to. wayland is being designed for this.. and they're > > right. > > this is how u get zero-tearing smooth screen updates with minimal overhead. > > it's a fundamental shift in perspective from copying pixels to a single > > shared > > framebuffer with clip rects, but it is the reality of most hardware you > > already > > have from phones through to set top boxes, tablets, laptops and desktops. > > you > > just don't know it. most of these capabilities lie idle and unused because > > our > > display system is too "old school" AND because of nay-sayers holding back > > progress saying "waaaa - i don't want compositing!". reality is that > > basically > > anyone who KNOWS graphics, hw and infra all the way down to these nuts and > > bolts is already in agreement - this is the way to go. we agree because we > > know > > what is actually going on behind the scenes. the decision to be compositing > > only is a big step - but in the right direction. suffice to say, that if > > you > > don't "get it" now, in a few years, you will. the penny may drop. maybe for > > some it won't - you may be the same people who think a green screen vt100 > > is > > all u ever need. pixels are useless. color is a waste of memory. reality > > is... > > sticking to non-composited displays is as useful as sticking to a vt100 > > attached to a 192000 baud serial line. :) > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > > -- > ~Jeff Hoogland <http://jeffhoogland.com/> > Thoughts on Technology <http://jeffhoogland.blogspot.com/>, Tech Blog > Bodhi Linux <http://bodhilinux.com/>, Enlightenment for your Desktop -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
