Multi-threaded composition is actually mostly serialized by SurfaceStack::guard.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Fix Released
|
Medium
|
Kevin DuBois | ||
mir (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Multi-threaded composition is actually mostly serialized by SurfaceStack:
Mir has one thread per DisplayBufferCo
void mc::DefaultDisp
mir:
std:
{
renderer-
mc:
FilterForVi
scene-
overlay_
}
Unfortunately the function that is locked is the one which potentially does most of the work, unless your GL driver likes to defer absolutely everything.
A simple solution would be to use a read-write lock in SurfaceStack. However I do wonder if finally executing GLRenderer concurrently in multiple threads is something that class is truely ready for... ?
Related branches
- Alan Griffiths: Approve
- Alexandros Frantzis (community): Approve
- PS Jenkins bot (community): Approve (continuous-integration)
- Alberto Aguirre (community): Approve
-
Diff: 342 lines (+58/-198)7 files modifiedsrc/server/compositor/CMakeLists.txt (+0/-1)
src/server/compositor/default_display_buffer_compositor.cpp (+14/-32)
src/server/compositor/rendering_operator.cpp (+0/-37)
src/server/compositor/rendering_operator.h (+0/-49)
tests/unit-tests/compositor/CMakeLists.txt (+0/-1)
tests/unit-tests/compositor/test_default_display_buffer_compositor.cpp (+44/-2)
tests/unit-tests/compositor/test_rendering_operator.cpp (+0/-76)
tags: | added: multimonitor performance |
Changed in mir: | |
status: | New → Triaged |
Changed in mir: | |
importance: | Undecided → Medium |
Changed in mir: | |
status: | Fix Committed → Fix Released |
I think this was resolved by: lp:~kdub/mir/no-rendering-operator