Mir

Merge lp:~albaguirre/mir/fix-1256360 into lp:mir

Proposed by Alberto Aguirre
Status: Merged
Approved by: Alexandros Frantzis
Approved revision: no longer in the source branch.
Merged at revision: 1537
Proposed branch: lp:~albaguirre/mir/fix-1256360
Merge into: lp:mir
Diff against target: 45 lines (+17/-0)
2 files modified
src/server/scene/gl_pixel_buffer.cpp (+7/-0)
tests/unit-tests/scene/test_gl_pixel_buffer.cpp (+10/-0)
To merge this branch: bzr merge lp:~albaguirre/mir/fix-1256360
Reviewer Review Type Date Requested Status
Alexandros Frantzis (community) Approve
PS Jenkins bot (community) continuous-integration Approve
Kevin DuBois (community) Approve
Review via email: mp+214355@code.launchpad.net

Commit message

make current before deleting gl resources in GLPixelBuffer (LP: #1256360)

Description of the change

make current before deleting gl resources in GLPixelBuffer (LP: #1256360)

To post a comment you must log in.
Revision history for this message
Kevin DuBois (kdub) wrote :

looks good

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

Great!

review: Approve
Revision history for this message
Alexandros Frantzis (afrantzis) wrote :

One caveat: to be completely safe, we need to ensure that the gl_context is not current to any other thread (e.g. the snapshoting thread) when we make current in the destructor. You would guess that destroying a thread with a current context (e.g. when the internal snapshotting thread is destroyed) would unbind that context, but unfortunately, at least in Mesa, that's not the case. That is:

T1: create context C
T2: make current C
T2: ~destroy
T1: make current C => fails at least with Mesa, haven't tried on the phone

This sounds like a problem with Mesa since the current context is thread specific state, and it make no sense to keep a context associated with a non-existent thread, but perhaps the spec is vague and Mesa interprets it differently. We should verify the expected behavior with Khronos and fix Mesa if needed.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'src/server/scene/gl_pixel_buffer.cpp'
2--- src/server/scene/gl_pixel_buffer.cpp 2014-03-06 06:05:17 +0000
3+++ src/server/scene/gl_pixel_buffer.cpp 2014-04-04 22:59:35 +0000
4@@ -65,6 +65,13 @@
5
6 ms::GLPixelBuffer::~GLPixelBuffer() noexcept
7 {
8+ /*
9+ * This may be called from a different thread
10+ * than the one that called prepare
11+ */
12+ if (tex != 0 || fbo != 0)
13+ gl_context->make_current();
14+
15 if (tex != 0)
16 glDeleteTextures(1, &tex);
17 if (fbo != 0)
18
19=== modified file 'tests/unit-tests/scene/test_gl_pixel_buffer.cpp'
20--- tests/unit-tests/scene/test_gl_pixel_buffer.cpp 2014-03-12 02:46:58 +0000
21+++ tests/unit-tests/scene/test_gl_pixel_buffer.cpp 2014-04-04 22:59:35 +0000
22@@ -138,6 +138,11 @@
23 EXPECT_CALL(mock_gl, glReadPixels(0, 0, width, height,
24 GL_BGRA_EXT, GL_UNSIGNED_BYTE, _))
25 .WillOnce(FillPixels());
26+
27+ /* at destruction */
28+ EXPECT_CALL(mock_context, make_current());
29+ EXPECT_CALL(mock_gl, glDeleteTextures(_,_));
30+ EXPECT_CALL(mock_gl, glDeleteFramebuffers(_,_));
31 }
32
33 ms::GLPixelBuffer pixels{std::move(context)};
34@@ -194,6 +199,11 @@
35 EXPECT_CALL(mock_gl, glReadPixels(0, 0, width, height,
36 GL_RGBA, GL_UNSIGNED_BYTE, _))
37 .WillOnce(FillPixelsRGBA());
38+
39+ /* at destruction */
40+ EXPECT_CALL(mock_context, make_current());
41+ EXPECT_CALL(mock_gl, glDeleteTextures(_,_));
42+ EXPECT_CALL(mock_gl, glDeleteFramebuffers(_,_));
43 }
44
45 ms::GLPixelBuffer pixels{std::move(context)};

Subscribers

People subscribed via source and target branches