Software compositing of EGL clients is much slower than software compositing of software clients

[Daniel van Vugt]

Software compositing of EGL clients is much slower than software clients. Even when the EGL client is allowed to render in hardware. There is something weirdly slow about our EGL texture binding compared to software textures...

Start the server with software rendering:
$ sudo env GBM_ALWAYS_SOFTWARE=1 mir_proving_server --compositor-report=log

Now start a fullscreen client (even with hardware rendering enabled) and drag the window around (so it's no longer bypassed).

Compositor performance:
7 FPS with mir_demo_client_eglflash (rendered in hardware, only rendering 1 FPS)
7 FPS with mir_demo_client_egltriangle (rendered in hardware)
30 FPS with mir_demo_client_fingerpaint (not redrawing at all)
30 FPS with 'mir_demo_client_progressbar 1' (rendered in software at 1 FPS)
30 FPS with 'mir_demo_client_progressbar 60' (rendered in software at 60 FPS)
30 FPS with 'mir_demo_client_flicker' (rendered in software at 60 FPS)

[Daniel van Vugt (vanvugt)]

I'm guessing this might be related to the fact I'm running on an Intel graphics desktop. So the buffer implementation for the EGL clients is still GBM. However the buffer implementation for the software clients is just local memory (ShmBuffer).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

This is possibly not a bug at all.

It's quite reasonable that uploading a software texture in software should be much faster than interpreting an EGL image in software and uploading that. Although leave the bug open because I hope we can get the figure of 7FPS closer to the 30FPS seen elsewhere.

[Daniel van Vugt (vanvugt)]

It's possible that simply choosing a more native texture format or EGL config will help to avoid conversions and make software rendering faster than this...

[Daniel van Vugt (vanvugt)]

Update: Today if I try GBM_ALWAYS_SOFTWARE=1 on my desktop Mir gets:
  60 FPS in the egltriangle client
  30 FPS in the compositor (17ms/frame)
or:
  60 FPS in the flicker client
  60 FPS in the compositor (3.3ms/frame)

So indeed it appears we have a major bottleneck in LLVMpipe interpreting EGL images (GBM buffers). This might be solved eventually when we have a proper software solution that's always using ShmBuffer.