Need good performance (zero-copy) for GLES applications running in GLES compositing window manager (KWin, gnome-shell, ...)

[ssvb]

We can't use hardware layers for a window if it is managed by a compositing manager because hardware layers can only present a simple rectangle. And we have no control or knowledge about the fancy visual effects being added to windows by the compositing manager (deformed windows, translucency, ...).

In the case of ordinary windows, the backing pixmap is just migrated to UMP buffer and the performance is ok (no redundant copies). But in the case of GLES applications, we have also front and back DRI2 buffers requested for their windows, which typically have window decorations (this causes some size mismatch between the window itself and the backing pixmap). Adding buffers swapping to the mix, we get a somewhat non-trivial problem to solve. Currently we just fallback to a slow memory copy done by the CPU. This needs to be fixed.

[dsd]

@ssvb do you have a plan on how to fix this?

My understanding is that this is a X11 limitation. The reparenting involved in adding window decorations means that buffer sizes mismatch and that the pixmap-flip can't happen. Even 'good' drivers like nouveau fall back to blit here (see can_exchange() in nouveau_dri2.c).

I guess the only option here for fbturbo is doing an accelerated blit in this case with G2D?

[ssvb]

@dsd Yes, the trick is to copy window decorations instead of the client area when doing buffer swaps. Window decorations are usually smaller, which means less overhead copying this stuff. And also window decorations are unlikely to change very often, so damage tracking can be employed to skip this copy in most of the cases. This is actually a reasonably obvious solution and has been also presented at "Future directions for the X Window System" https://www.youtube.com/watch?v=TDIvSIUQnEY (this part is at 36:20). Not sure if any real Xorg driver implements this yet though (ideas are dime a dozen). And yes, I know that both radeon and nouveau drivers are just cheating with accelerated copy: http://irclog.whitequark.org/linux-sunxi/2013-03-28#3386190;

Regarding the priority of this fix. This issue only affects GLES applications, which are almost non-existing even now. And I'm really disappointed about this: http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/4705 Also this is only relevant for the composited desktop, which is generally a bad idea for low end ARM hardware such as Allwinner devices. Additinally Mali blob drivers have quite a number of quirks, and I don't feel like doing anything "advanced" at this point, which might potentially expose some of the not yet discovered latent bugs. Debugging binary blobs is a real pita. So I'm kind of waiting for @libv to provide some initial revision of open source reverse engineered Mali400 support in Mesa before implementing anything more sophisticated :)

[ssvb]

But patches are always welcome.

[dsd]

Thanks for the info - especially Keith's presentation was very useful!