Mir

[regression] transparent indicator on mx4 with the 0.18 release silo (21)

Bug #1524414 reported by Kevin DuBois
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Fix Released
Critical
Kevin DuBois
0.18
Fix Released
Critical
Kevin DuBois
mir (Ubuntu)
Critical
Unassigned

Bug Description

Indicators are transparent when they should be opaque on the mx4 after installing the release silo 21 containing the 0.18 release.

marking critical, as its blocking 0.18 release

Related branches

Changed in mir:
milestone: 0.18.0 → 0.19.0
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Do you have a screenshot?

Any idea what Mir could be doing wrong to cause this?

Revision history for this message
Andreas Pokorny (andreas-pokorny) wrote :

The indicator background rectangles are drawn with the other opaque objects. While the transparent objects are drawn on top back to front. The qt renderer uses depth-ids to have a state change driven but not depth sorted rendering of opaque objects. Due to buffer allocation and egl config changes, it seems that on mx4 qtmir either gets a framebuffer with lacking depth buffer accuracy or even no depth buffer at all.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Mir is designed to not provide a depth buffer by default, for best performance.

We have an EGL config API in the server setup that is meant to allow servers to add their own requirements (like depth) to the list. Maybe that's now broken?

Revision history for this message
Kevin DuBois (kdub) wrote :

since its blocking 0.18, and the fix will be released there, it seems to me the target should be 0.18.

Revision history for this message
Kevin DuBois (kdub) wrote :

ah, so it has two targets... makes sense to me the more I thought about it :)

Revision history for this message
Kevin DuBois (kdub) wrote :

Image of problem

Revision history for this message
Alberto Aguirre (albaguirre) wrote :

The root cause seems to be a bug in the PowerVR driver after the insertion of an egl sync fence during Buffer::gl_bind_to_texture

This seems to be a bug in the PowerVR driver

- alternatively, glFenceSync/glWaitSync could be used instead of EGL_KHR_fence_sync since the MX4 driver supports OpenEGL ES3.0 but that needs libhybris support (to expose the GLESv3 entry points)

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Adding (some/all?) new ES3.0 entry points to libhybris would actually work by virtue of another libhybris bug I have open. That is it already blindly reports GL version as ES3.0 directly from the driver, but the hybris library itself only exports the ES2.0 symbols at present.

Revision history for this message
Kevin DuBois (kdub) wrote :

Either way, I think for 0.18, we'll roll back the EGLSync extensions to unblock release.

Changed in mir:
status: Confirmed → In Progress
assignee: Alberto Aguirre (albaguirre) → Kevin DuBois (kdub)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir at revision 3194, scheduled for release in mir, milestone 0.19.0

Changed in mir:
status: In Progress → Fix Committed
Kevin DuBois (kdub)
Changed in mir:
status: Fix Committed → Fix Released
status: Fix Released → Fix Committed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

mir (0.18.0+16.04.20151216.1-0ubuntu1) xenial; urgency=medium

Changed in mir (Ubuntu):
importance: Undecided → Critical
status: New → Fix Released
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Fix Released in Mir 0.18.0. Although it's good to mention this bug got different fixes between the 0.18 and 0.19 branches, it's probably still best to only mention it in the changelog for one of them.

Changed in mir:
milestone: 0.19.0 → none
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments