Mir

Merge lp:~alan-griffiths/mir/bfi-fix-1416482 into lp:mir/0.11

Proposed by Alan Griffiths
Status: Merged
Approved by: Alan Griffiths
Approved revision: no longer in the source branch.
Merged at revision: 2283
Proposed branch: lp:~alan-griffiths/mir/bfi-fix-1416482
Merge into: lp:mir/0.11
Diff against target: 26 lines (+10/-0)
1 file modified
src/server/compositor/gl_program_family.cpp (+10/-0)
To merge this branch: bzr merge lp:~alan-griffiths/mir/bfi-fix-1416482
Reviewer Review Type Date Requested Status
PS Jenkins bot (community) continuous-integration Approve
Alexandros Frantzis (community) Approve
Review via email: mp+248227@code.launchpad.net

Commit message

compositor: avoid segfault when running two monitors "sidebyside"

Description of the change

compositor: avoid segfault when running two monitors "sidebyside"

I'm not really familiar with this area of code, so if there's a more elegant solution please suggest it.

To post a comment you must log in.
Revision history for this message
Alexandros Frantzis (afrantzis) wrote :

We need to serialize one level higher, in GLProgramFamily::add_program(), to ensure glCreateProgram() is also protected from concurrent access.

Note that we now have two points at which we allocate program and shader ids: GLProgramFamily
and GLProgramFactory (used only in the Android backend after a recent refactoring). Although they may be (or rather will be after this fix) invidually protected from concurrent access, in theory two threads could run concurrently in the two different classes. Not sure if it's a problem in practice, but ideally the two classes should also get synchronized or merged (not in this MP); we don't really need two implementations offering the same functionality.

Some background:

This was first addressed in r923 [1] :

/*
 * We need to serialize renderer creation because some GL calls used
 * during renderer construction that create unique resource ids
 * (e.g. glCreateProgram) are not thread-safe when the threads are
 * have the same or shared EGL contexts.
 */

Since then the code has been refactored multiple times and the serialization logic moved around. In a recent refactoring (the transition from GLProgramFactory to GLProgramFamily for GLRenderer), the serialization logic was lost.

[1] https://bazaar.launchpad.net/~mir-team/mir/0.11/revision/923

review: Needs Fixing
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Approve (continuous-integration)
Revision history for this message
Alexandros Frantzis (afrantzis) wrote :

Looks good.

review: Approve
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Approve (continuous-integration)

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'src/server/compositor/gl_program_family.cpp'
2--- src/server/compositor/gl_program_family.cpp 2015-01-07 03:18:31 +0000
3+++ src/server/compositor/gl_program_family.cpp 2015-02-02 14:04:44 +0000
4@@ -18,6 +18,8 @@
5
6 #include "mir/compositor/gl_program_family.h"
7
8+#include <mutex>
9+
10 namespace mir { namespace compositor {
11
12 void GLProgramFamily::Shader::init(GLenum type, const GLchar* src)
13@@ -73,6 +75,14 @@
14 GLuint GLProgramFamily::add_program(const GLchar* const vshader_src,
15 const GLchar* const fshader_src)
16 {
17+ // Serialize calls - avoids segfault on multimonitor (see lp:1416482)
18+ // We need to serialize renderer creation because some GL calls used
19+ // during renderer construction that create unique resource ids
20+ // (e.g. glCreateProgram) are not thread-safe when the threads are
21+ // have the same or shared EGL contexts.
22+ static std::mutex lp1416482_mutex;
23+ std::lock_guard<decltype(lp1416482_mutex)> lock{lp1416482_mutex};
24+
25 auto& v = vshader[vshader_src];
26 if (!v.id) v.init(GL_VERTEX_SHADER, vshader_src);
27

Subscribers

People subscribed via source and target branches