Ubuntu
mir package

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

Bug #1576032 reported by Daniel van Vugt
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mir
Confirmed
Medium
Unassigned
mesa (Ubuntu)
Incomplete
Undecided
Unassigned
mir (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

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)

See original description
Daniel van Vugt (vanvugt)
description: updated
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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).

summary: - Software compositing of EGL clients is much slower than software clients
+ Software compositing of EGL clients is much slower than software
+ compositing of software clients
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in mesa (Ubuntu):
status: New → Confirmed
Changed in mir (Ubuntu):
status: New → Confirmed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Changed in mir:
importance: Undecided → Low
Changed in mir (Ubuntu):
importance: Undecided → Low
Changed in mir:
status: New → Confirmed
Changed in mesa (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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)
tags: added: vm
Changed in mir:
importance: Low → Medium
Changed in mir (Ubuntu):
importance: Low → Medium
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.