Merge lp:~kdub/mir/avert-1563287 into lp:mir
| Status: | Merged |
|---|---|
| Approved by: | Daniel van Vugt on 2016-04-20 |
| Approved revision: | 3463 |
| Merged at revision: | 3466 |
| Proposed branch: | lp:~kdub/mir/avert-1563287 |
| Merge into: | lp:mir |
| Diff against target: |
15 lines (+5/-0) 1 file modified
src/platforms/android/server/device_quirks.cpp (+5/-0) |
| To merge this branch: | bzr merge lp:~kdub/mir/avert-1563287 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Mir CI Bot | continuous-integration | Approve on 2016-04-20 | |
| Daniel van Vugt | 2016-04-19 | Approve on 2016-04-20 | |
|
Review via email:
|
|||
Commit Message
avert LP: #1563287 by disabling EGL_sync_fence extensions on our Mali devices. It was shown that the added synchronization added sub-millisecond times to each buffer mapping, which became visible when many clients were open.
Description of the Change
avert LP: #1563287 by disabling EGL_sync_fence extensions on our Mali devices. It was shown that the added synchronization added sub-millisecond times to each buffer mapping, which became visible when many clients were open.
The plan to fix this properly is to analyze hybris and android's performance of eglCreateSyncKHR (which should be lightweight, but is not in ubuntu_touch+mali)
Will reopen LP: #1517205 for mali only (or perhaps start a new mali only bug in the same vein)
NB: the TODO is https:/
| Kevin DuBois (kdub) wrote : | # |
unrelated 18:22:16 12: [ FAILED ] ClientLatency.
| Mir CI Bot (mir-ci-bot) wrote : | # |
FAILED: Continuous integration, rev:3463
https:/
Executed test runs:
FAILURE: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
FAILURE: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
| Daniel van Vugt (vanvugt) wrote : | # |
Tested on krillin.
I can confirm this branch reduces the compositor-report render time for five triangles from 35ms to 14ms. But that's still nowhere near the 1.8ms we used to have in r3296.
Maybe that's OK, maybe not. I recall when I first wrote the compositor report in 2013 that we did have such issues with the compositor render time getting rounded up to one frame on Android, and that was nothing to be concerned about. Just a quirk of Android's post arrangement that we could not separate the rendering from the post.
This might not be sufficient by itself to solve the bug. Although I had already measured and suspected we made a secondary regression at some point after r3297 too. So need to check that...
| Daniel van Vugt (vanvugt) wrote : | # |
OK, I've bisected the secondary regression. That's new enough that it hasn't hit anyone's phone yet. So don't worry about that (bug 1572406).
FAILED: Continuous integration, rev:3463
https:/
Executed test runs:
FAILURE: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
FAILURE: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
FAILURE: https:/
Click here to trigger a rebuild:
https:/