[Mali GPU] corruption in software clients on some platforms when GL-rendered on the server
Bug #1573014 reported by
Kevin DuBois
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Won't Fix
|
High
|
Kevin DuBois | ||
mir-android-platform |
New
|
Undecided
|
Unassigned |
Bug Description
Android software cliest will tear on tagged platforms, due to lack of available eglCreateSyncKHR extensions. They are disabled and/or non functioning on tagged platforms.
This is an intentional regression of bug 1517205, introduced in lp:mir r3466 in order to solve other performance problems.
Test case: Run two or more mir_demo_
Expected: No tearing/corruption.
Observed: Tearing and corruption.
Changed in mir: | |
milestone: | none → 0.23.0 |
description: | updated |
description: | updated |
summary: |
- corrpution in swapinterval 0 software clients on some platforms when GL- - rendered on the server + [Mali GPU] corrpution in swapinterval 0 software clients on some + platforms when GL-rendered on the server |
Changed in mir: | |
status: | In Progress → Confirmed |
summary: |
- [Mali GPU] corrpution in swapinterval 0 software clients on some + [Mali GPU] corruption in swapinterval 0 software clients on some platforms when GL-rendered on the server |
Changed in mir: | |
milestone: | 0.23.0 → none |
description: | updated |
To post a comment you must log in.
Problem is turning out to be a bit of bear...
The corruption is due to releasing a buffer that's being used as a texture in the server's GL render loop. Unfortunately though, the egl sync extensions that we need to get this right don't appear to working properly on mali.
The installation of sync points on mali can be very non-performant, taking between 500us-1ms per fence install (see lp: 1563287).
This can be worked around by installing post-eglSwapBuffers (this is the path surfaceflinger takes). This limits install time to a reasonable 50-80us.
With this worked around, the sync points still appear to be broken somehow, as waiting on the sync point (even after glFlush and eglSwapBuffers) is seemingly triggered by the hwc commit, delaying by many ms (which is incorrect, the fence should clear very shortly after issuing the gpu commands)
I've experimented with shifting the synchronization from the compositor loop as it sends back the buffers, to the client when it tries to access the buffers. This though still seems to have the fences tied to the post/vsync event though, so it degrades our swapinterval-0 performance unacceptably.