Thanks for the detailed explanation :) This has pinpointed exactly where we're losing all performance. I will have a chat with the Intel devs. I'm already building for egl/gles, by the way.
Dan On Fri, Jul 1, 2016 at 10:55 AM, Carsten Haitzler <[email protected]> wrote: > On Thu, 30 Jun 2016 11:27:41 +1000 Daniel Kasak <[email protected]> said: > >> Hi all. >> >> My workplace is rolling out new display hardware, including a >> 'DisplayLink' hub. DisplayLink products provide connectivity to >> monitors over USB. We're using DisplayLink 3 devices, which have >> proprietary drivers. I'm having a lot of issues getting things working >> smoothly. A thread on our performance issues is at: >> >> http://displaylink.org/forum/showthread.php?t=64603 >> >> I've recently been asked about the compositor's "swapping method". I >> currently have it set to auto. After I read this question, I thought >> I'd try out other methods ( at home, no DisplayLink stuff connected ). >> After this testing, I assume my setup is using the "Invalidate (full >> redraw)" method, because this is the only method that works well. >> >> "Copy from back to front", "Double buffered swaps" and "Triple >> buffered swaps" produce a LOT of flickering and artifacts when I drag > > ok. that's because you FORCE evas (the renderer) to assuming the gl back-end > is > either doing copies, double or triple buffered swaps. it's not a driver bug. > it's forcing evas to assume the driver works in a specific way. auto is the > default because... well it asks the gl implementation how it works. :) > >> windows around. I assume this is a driver issue ( Intel GPU, mesa >> built from git, 4.7 kernel, X built from git )? If so, does anyone >> know if bugs are entered against the relevant components yet? > > nope. as above. :) > >> The DisplayLink people have said in other threads that compositing >> managers that force a full screen refresh leave them with no option >> but to do a lot of processing, causing high CPU usage and bad latency >> in display updates. > > so. evas works by doing a glxswapbuffer() or an eglswapbuffer() depends if efl > is built for egl or glx). evas supports buffer age in glx. the only glx driver > to support this is the nvidia driver. what this extension does, it tells us > how > old the buffer is after we swapped. knowing this means we can only draw the > changes between now and that older frame. this allows partial updates. evas > fully supports this if detected. i have noticed the nvidia driver seems buggy > here and reports and incorrect age. i am relatively sure it's the driver > because the same update region handling code has been tested with a simulated > driver where it pretends to do copies, double, triple, quadrouple etc. > buffering and can even change the age of a buffer every now and again. also > the > exact same code for partial update handling ships on tizen for compositor and > all client apps and it works correctly there too. > > we ALSO support the egl buffer age extension. in egl there is another > extension > to swap buffer with region updates. this is basically supported only on some > embedded drivers and generally nowhere else. why? because on embedded this > really helps performance. :) this means we use buffer age to decide what > regions to update/redraw and then we TEL the display which regions were > updated when we swap buffers by providing a list of rectangles with the swap. > > so we swap. we support just about every extension that exists to minimize > damaged regions. it's up tot he egl drivers to go support this. the for glx > there is only something to minimze what we render (buffer age) but nothing to > provide updated regions at swap time. > > we COULD render to an fbo and literally do front buffer rendering and copy the > update to the frontbuffer. this has issues. > > 1. you cant vsync and do tear-free renderring this way > 2. it ALWAYS is a copy and copies are not free. swapping above can be zero > copy > if the driver is smart (if you render fullscreen like the compositor does, > most > drivers switch to swapping from copying). > > so 1. build for egl/gles, 2. poke your driver maintainers to support these > extensions above because these allow zero copy for the compositor AND zero > copy > for client windows AND partial updating. > >> Am I out of luck? >> >> Dan >> >> ------------------------------------------------------------------------------ >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San >> Francisco, CA to explore cutting-edge tech and listen to tech luminaries >> present their vision of the future. This family event has something for >> everyone, including kids. Get more information and register today. >> http://sdm.link/attshape >> _______________________________________________ >> enlightenment-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users >> > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
