Unity8-dash on Intel Atom graphics crashes and restarts continuously [qtubuntu: ASSERT: "eglDestroyContext(mEglDisplay, EglContext) == EGL_TRUE"]

Bug #1549455 reported by Emanuele Antonio Faraone
48
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Fix Committed
Undecided
Unassigned
Mir
Invalid
High
Unassigned
mesa (Ubuntu)
Invalid
Undecided
Unassigned
mir (Ubuntu)
Invalid
High
Unassigned
qtdeclarative (Ubuntu)
Invalid
Undecided
Unassigned
qtmir (Ubuntu)
Invalid
Critical
Unassigned
qtubuntu (Ubuntu)
Fix Released
Critical
Gerry Boland
unity8 (Ubuntu)
Invalid
Critical
Unassigned

Bug Description

Qt clients are failing to create an egl context when running on Intel Diamondville and Pineview, but not Cherryview systems under Mir.

eglCreateContext fails with a EGL_BAD_MATCH error code.

When it fails, Qt tries to delete & recreate the context, which then crashes the client (bug 1580118)

=== Original bug description ===
This bug Makes the pc UNUSABLE
when I try to launch Unity 8 and Mir, after writing the password on the login (in the image attached) the bar to enter the password disappears and my computer screen stays stuck without them let me do anything. the connection begins to separate and reattach alone and I can only move the cursor. it makes the computer unusable and I am forced to restart forced to then enter into Unity 7. represented in the screenshot is the lock status after entering the password.
Version: unity8.12+16.04.201604.01.1
Version of Mir : 0.21

Related branches

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :
summary: - Unity 8 doesn't load
+ Unity 8/Mir doesn't load
description: updated
Revision history for this message
Michał Sawicz (saviq) wrote : Re: Unity 8/Mir doesn't load

When this happens you should actually be able to press Esc to recover the greeter. You can also press Ctrl+Alt+F1 and log in there, following by "sudo service lightdm restart", that will restart the display manager.

That said, can you please clear /var/log/lightdm and ~/.cache/upstart/, try logging in to the unity8 session and collect the logs from both directories and attach here?

Changed in unity8 (Ubuntu):
status: New → Incomplete
Revision history for this message
Michał Sawicz (saviq) wrote :

Oh and also ~/.xsession-errors might be interesting - delete it as well before trying to log in a Unity8 session.

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

I did what you told me, but after pressing esc telling me that the password was wrong, but he was right, then I rebooted I pressed esc and the same thing happened to me, after I pressed ctrl + alt + f1 and I I added the command that you told me, but I would say again that the password is wrong

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

I tried without pressing esc and I was able to access, after putting the command restarts the screen but the problem is not resolved. how can I clean those libraries that you wrote me?

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

ok I did everything you told me including cleaning of those libraries, but it still does not work

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

I managed somehow to get in, but I do not open the applications and remain with the load wheel to 'infinity

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

We know about this issue and it's probably bug 1536662 you are seeing.

I hope to get some attention to this in the coming days.

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

By the way, the screenshot in comment #1 is what I see too (after bug 1536662 has timed out, Mir crashes and returns you to a broken login screen)

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

Although if your USC/Unity8 is crashing for some other reason than bug 1536662, I guess you would also see the same broken login screen.

So it really depends: Does it take 30 seconds to return you to the login screen or is it immediate?

Please attach these files so we can find out what the cause is:
  ~/.cache/upstart/unity8.log
  /var/log/lightdm/unity-system-compositor.log

Changed in mir:
importance: Undecided → High
Changed in unity8 (Ubuntu):
importance: Undecided → High
Changed in mir:
status: New → Incomplete
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

But now the situation has changed, because I can not access but the cursor is slow and no application is opened, remains in loading, even the scope opens

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

how do I get those logs?

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

To get the logs you will need to:

1. Reboot and log into Unity 7 (not Unity8)
2. Open a terminal with Ctrl+Alt+T
3. Run: cp ~/.cache/upstart/unity8.log ~/Documents/
4. Run: sudo cat /var/log/lightdm/unity-system-compositor.log > ~/Documents/unity-system-compositor.log
5. Now open your web browser and attach the two files from your Documents folder to this bug.

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

Please note the above steps will only be helpful if you could not log in previously. If you did log in per comment #11 then please do not attach those files to this bug.

If the cursor is slow, that is likely bug 1539009 which we will release a fix for soon.

And if no applications open, please log a new bug for that here:
https://bugs.launchpad.net/ubuntu/+source/unity8/+filebug

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

emanuele@emanuele-AOD255:~$ cp ~/.cache/upstart/unity8.log ~/Documenti/
cp: impossibile eseguire stat di '/home/emanuele/.cache/upstart/unity8.log': File o directory non esistente
emanuele@emanuele-AOD255:~$ sudo cat /var/log/lightdm/unity-system-compositor.log > ~/Documents/unity-system-compositor.log
bash: /home/emanuele/Documents/unity-system-compositor.log: File o directory non esistente
emanuele@emanuele-AOD255:~$

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

not load

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

OK, try this then:

$ cp ~/.cache/upstart/unity8.log.1.gz ~/Documenti/
$ sudo zcat /var/log/lightdm/unity-system-compositor.log.1.gz > ~/Documents/unity-system-compositor.log

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

ok, i have send them

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

ok?

Changed in mir:
status: Incomplete → Confirmed
Changed in unity8 (Ubuntu):
status: Incomplete → Confirmed
Changed in mir:
status: Confirmed → New
Changed in unity8 (Ubuntu):
status: Confirmed → New
summary: - Unity 8/Mir doesn't load
+ Unity 8/Mir doesn't load on Intel Pineview graphics
Changed in mir:
status: New → Triaged
Changed in mir:
status: Triaged → Invalid
status: Invalid → New
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: Unity 8/Mir doesn't load on Intel Pineview graphics

Thanks for the logs. That explains a lot, and I hope it's not a problem specific to your Intel Pineview hardware...

Mir 0.19.3 worked once, but mostly failed to start (Failed to find platform for current system). The new Mir 0.20.0 seems to be working more consistently for you.

Now that you can get Unity8 on screen, it seems to be just Unity8 issues remaining. I wonder if I can get a 10" Pineview netbook like yours to test on...

description: updated
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

you managed to find a computer with graphic Pineview?

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

No, it will take me weeks/months to source that hardware. If I can get it at all cheaply...

In the meantime, can you please describe more about the problems you see in Unity8 (comment #11)?

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

no nothing, when I entered seemed to me the scope of the window loaded with the wheel but you never opened

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

Can you please take a photo or screenshot and attach it here?

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

but because if I open an app for unity 8 ( in this case the browser ) in unity 7 it starts and runs ?

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

It remains indefinitely

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

I have an intel atom catching some dust here. As long as pineview does not contain the GMA 500 poulsbo gpu.. it should be a similar chip.

And what happens is, that unity8-dash keeps restarting. Last time I tracked that down this was due to lack of GL 2.0 support in mesa for that cpu. Just upgrading now, to check if this is still the case.

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

Ok thanks you for signing interested

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

Any update?

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

Yes I believe there is still a problem setting up the rendering context. When I run unity8-dash in isolation I get this:
file:///usr/share/unity8//Dash/Dash.qml:39: ReferenceError: window is not defined
file:///usr/share/unity8//Dash/Dash.qml:265: ReferenceError: scopeStyle is not defined
ASSERT: "eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE" in file ../../../src/ubuntumirclient/glcontext.cpp, line 71

A failure there will affect all qt applications..

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

then?

Changed in mir:
status: New → Invalid
Revision history for this message
Andreas Pokorny (andreas-pokorny) wrote :

Mesa in Ubuntu has a patch for i915 that disables OpenGL 2.0 but not GLES 2,0. Thats why all mir clients and the unity8 session starts up.. since mirserver always use GL|ES.

Regular qt clients do the EGL init in a different path and they insist on GL 2.0.

When you recompile mesa without that patch you get the unity8 desktop but it is just too slow.. It would be better to implement a less demanding QtQuick backend .. and/or use a different mir compositor..

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

i915 does not have native shader support so mesa simulate that with llvmpipe, using i915 only for blitting.. So a less demanding - (but also not existing) fixed-function gl-1.x backend is the probably your best chance to use that gpu with unity8.

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

Ok

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

I've mentioned the possibility of a GL 1.x backend before in other bugs (somewhere...). While it's a fun thought, the problem I recall is that GL 1.x may not provide any sufficient EGLImage binding extensions (which we need to get client window contents on screen). Without that you will forever just see the shell but can't see the client window contents.

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

Then i don't have possibility for use unity8?

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

Nothing is impossible and you should not assume all the above comments are always relevant and accurate :)

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mesa (Ubuntu):
status: New → Confirmed
Changed in unity8 (Ubuntu):
status: New → Confirmed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Keeping this bug open in the Mir project so we don't lose it. Looks like a third Pineview user is reporting the same crash.

Changed in mir:
status: Invalid → Confirmed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Note that the failing assertion is in qtubuntu ...

ASSERT: "eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE" in file ../../../src/ubuntumirclient/glcontext.cpp, line 71

affects: unity8 (Ubuntu) → qtubuntu (Ubuntu)
summary: - Unity 8/Mir doesn't load on Intel Pineview graphics
+ Unity 8 doesn't load on Intel Pineview graphics (qtubuntu: ASSERT:
+ "eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE")
summary: - Unity 8 doesn't load on Intel Pineview graphics (qtubuntu: ASSERT:
- "eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE")
+ Unity 8 doesn't load on Intel Pineview graphics [qtubuntu: ASSERT:
+ "eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE"]
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: Unity 8 doesn't load on Intel Pineview graphics [qtubuntu: ASSERT: "eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE"]

Although the original reporter doesn't seem to get to the ASSERT. Two other Pineview users have got that far. So I think safe to group all these issues under "Pineview doesn't work".

Revision history for this message
David Talmage (talmage-acm) wrote :

I experience this bug on my WeTab. On login, I get a black screen. How can I help to fix it?

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

now happens to me a black screen and nothing else, I upgraded to mir 0:21 and does not access its only black screen rhyme

Changed in mir (Ubuntu):
status: New → Confirmed
importance: Undecided → High
description: updated
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

if I try to open on unity(7) an application developed for unity (8) and mir (es.dekko or browser) it opens but it is very slow and the commands are received after 5 seconds. Please fix this bug.

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

This bug cannot be fixed in mir or qtubuntu - applications like unity8 and the applications using qtdeclarative will be slow within x11 and mir. A backend for fixed function gpus, i.e using only GL1.5 would be required to fix that..

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

Slower, yes. But they shouldn't be unusable.

Given Pineview probably works in Unity7 now, and old Intel Atoms definitely work in Unity7 now, we have very little excuse to not ensure Unity8 eventually works on them. To some degree.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in qtdeclarative (Ubuntu):
status: New → Confirmed
Revision history for this message
Alistair Buxton (a-j-buxton) wrote :

I have an Atom N455 convertible with Pineview graphics. Unity8 session just displays a black screen forever. Unity 7 works fine.

Revision history for this message
Alex Ray (m-flex-q) wrote :

I have the same (or very similar) problem on a fresh 16.04 install (same problem on 15.10 upgraded to 16.04, but I reinstalled to be sure).

Dell Latitude E4300

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
 Subsystem: Dell Mobile 4 Series Chipset Integrated Graphics Controller
 Kernel driver in use: i915
 Kernel modules: i915
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
 Subsystem: Dell Mobile 4 Series Chipset Integrated Graphics Controller

If I login with unity 8, I just get a black screen. Interestingly, sometimes I get a partially rendered desktop - however, I cannot get the launcher to work, switching windows doesn't work, and in general interacting with it is impossible. Another odd thing is that if I do this, after I login on lightdm, I am presented a different login screen - the password text field isn't properly aligned either which is odd.

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

Thanks for your input.

Please keep this bug about Intel Pineview systems only: http://ark.intel.com/products/codename/32201/Pineview#@All

If you still have black screen or corruption bugs on other systems, please log them separately so we can investigate:
https://bugs.launchpad.net/ubuntu/+source/unity8/+filebug

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

but this bug is solved in a short time or not?

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

I am still trying to get Pineview hardware. It's very difficult to find now...

Revision history for this message
Albert Astals Cid (aacid) wrote :

Daniel, i have an Asus S10-3t netbook lying around, that according to wikipedia has a Intel Atom N470 processor which would be a pineview?

If you want me to try some stuff I can do. If you would rather have some form of ssh access i guess we could also arrange it.

tags: added: black-screen
Changed in qtubuntu (Ubuntu):
importance: High → Critical
status: Confirmed → Triaged
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I finally got hold of a Pineview system. Seems Mir things mostly work, except for unity8-dash crashing continuously:

Loading module: 'libubuntu_application_api_desktop_mirclient.so.3.0.0'
file:///usr/share/unity8//Dash/Dash.qml:39: ReferenceError: window is not defined
file:///usr/share/unity8//Dash/GenericScopeView.qml:629: TypeError: Cannot read property 'activeFiltersCount' of null
file:///usr/share/unity8//Dash/GenericScopeView.qml:628: TypeError: Cannot read property 'filters' of null
file:///usr/share/unity8//Dash/Dash.qml:265: ReferenceError: scopeStyle is not defined
ASSERT: "eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE" in file ../../../src/ubuntumirclient/glcontext.cpp, line 71

Other findings:
mir-demos like mir_proving_server are super-fast, super-smooth (_except_ for eglplasma which is super-slow).
unity-system-compositor starts obviously.
unity8 starts very slowly and the mouse is unusably slow and jerky.
unity8-dash crashes and restarts infinitely (see also bug 1578469) per the above log.

summary: - Unity 8 doesn't load on Intel Pineview graphics [qtubuntu: ASSERT:
+ Unity8-dash doesn't load on Intel Pineview graphics [qtubuntu: ASSERT:
"eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE"]
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: Unity8-dash doesn't load on Intel Pineview graphics [qtubuntu: ASSERT: "eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE"]

Relative to Unity7 on the Pineview system:

mir_proving_server is much faster than Unity7 (perfect 60FPS compositing and egltriangle up to 1000FPS).

Unity8 is much slower than Unity7 (only a couple of FPS at most and sometimes less than 1).

Seems like (similar to mir_demo_client_eglplasma) some advanced shaders cause the performance to fall off a cliff. It's not obvious where the edge of the cliff is though, because everything keeps working, just much slower.

We probably need a shader/GL debugging expert to look into it.

Changed in mir (Ubuntu):
status: Confirmed → Invalid
Changed in mir:
status: Confirmed → Invalid
Changed in mesa (Ubuntu):
status: Confirmed → Invalid
Changed in qtmir (Ubuntu):
importance: Undecided → Critical
summary: - Unity8-dash doesn't load on Intel Pineview graphics [qtubuntu: ASSERT:
- "eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE"]
+ Unity8-dash on Intel Pineview graphics crashes and restarts continuously
+ [qtubuntu: ASSERT: "eglDestroyContext(mEglDisplay, mEglContext) ==
+ EGL_TRUE"]
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: Unity8-dash on Intel Pineview graphics crashes and restarts continuously [qtubuntu: ASSERT: "eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE"]

Mir server log on an Atom N450.

Changed in unity8 (Ubuntu):
importance: Undecided → Critical
Changed in qtmir (Ubuntu):
status: New → Confirmed
Changed in unity8 (Ubuntu):
status: New → Confirmed
Revision history for this message
Loïc Molinari (loic.molinari) wrote :

Not related to the assertion but I got a Netbook with such a chip and it was easily falling back to slow GPU/driver pathes. I remember for instance transcendental functions in pixel shaders (sin, cos, etc) taking ~1 sec to complete. So we could be hitting such an issue. Last time I checked QtQuick didn't use trigo though (except in visualisation debug modes).

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

Daniel, i have the same processor That hast thou,n450

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

Loïc:

Our findings appear to be identical. Basic rendering on Pineview (including shaders) is fast and smooth till I used trig functions in shaders (mir_demo_client_eglplasma).

I doubt Unity/Ubuntu toolkit uses much trig, but it probably hits some similarly expensive functions.

Expensive functions aren't the problem with the dash though. The dash never starts so that may be non-existent functions instead.

Revision history for this message
Gerry Boland (gerboland) wrote :

Albert was able to reproduce this on his netbook.

The dash issues we suspect are due to:
https://bugs.launchpad.net/qtubuntu/+bug/1580124
https://bugs.launchpad.net/qtubuntu/+bug/1580118

I suspect also that the poor unity8 performance is due to a GL/GLES mismatch in unity8. Running unity8 with MESA_DEBUG=1 EGL_LOG_LEVEL=debug reveals a few MESA errors:
http://paste.ubuntu.com/16344427/

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

Those Mesa errors "Mesa: User error:" all look like OpenGL features that Unity8 is hitting but mir-demos don't. So those gl calls are also good candidates for explaining poor performance, especially if Mesa is falling back to software rendering for them.

Unfortunately we're covering multiple issues here. This bug should be about the dash crashing continuously. We can deal with performance elsewhere...

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

P.S. In my experience, confusing GL and GLES is something Mesa actually does well. It provides a single API for both of them and even lets you accidentally use GL features in GLES that should not exist.

Revision history for this message
Gerry Boland (gerboland) wrote : Re: Qt clients on Intel Pineview graphics fail to create egl context with Mir

Just considering the Dash problem, the crash is a symptom of a bigger problem: seems qtubuntu is unable to choose or manage the egl config correctly. If a correct/working egl config was chosen, then this code path wouldn't be entered (which has the "delete when not created" bug seen here).

The actual problem is that eglCreateContext fails with EGL_BAD_MATCH on the problem hardware. I'm experimenting with lp:~gerboland/qtubuntu/adopt-more-eglconvenience2/ which uses Qt's EGL config choosing code (that works ok on X11) in case that works.

I've update this bug title/description to match.

You're right that the unity8 performance problem is a separate issue. I've logged bug 1580792 to encompass that.

summary: - Unity8-dash on Intel Pineview graphics crashes and restarts continuously
- [qtubuntu: ASSERT: "eglDestroyContext(mEglDisplay, mEglContext) ==
- EGL_TRUE"]
+ Qt clients on Intel Pineview graphics fail to create egl context with
+ Mir
description: updated
Revision history for this message
Gerry Boland (gerboland) wrote :

http://paste.ubuntu.com/16357238/ the output Qt gave me for the failing eglCreateContext

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: Unity8-dash on Intel Pineview graphics crashes and restarts continuously [qtubuntu: ASSERT: "eglDestroyContext(mEglDisplay, EglContext) == EGL_TRUE"]

Please keep the bug title in a form that's meaningful and relevant to users. Not a description of the source code.

summary: - Qt clients on Intel Pineview graphics fail to create egl context with
- Mir
+ Unity8-dash on Intel Pineview graphics crashes and restarts continuously
+ [qtubuntu: ASSERT: "eglDestroyContext(mEglDisplay, EglContext) ==
+ EGL_TRUE"]
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

Some news?

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

The short summary is: Both Mir and Unity8 developers have got hold of Pineview hardware and can now reproduce the bug. We have established it's a start-up failure in Unity8-dash only.

Unity8 does start on Pineview, but you have to wait a very long time for it to start (during which you see a black screen). If we don't have a bug for that start-up time issue then I'll log one soon. Even powerful desktops take a very long time to start Unity8.

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

Confirmed the same bug on a Diamondville Intel Atom N270. That's the whole netbook family affected then... not counting Cedarview which we can't support due to a proprietary GPU in that one.

https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors#Single-core_Netbook_processors

summary: - Unity8-dash on Intel Pineview graphics crashes and restarts continuously
+ Unity8-dash on Intel Atom graphics crashes and restarts continuously
[qtubuntu: ASSERT: "eglDestroyContext(mEglDisplay, EglContext) ==
EGL_TRUE"]
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

Today I tried again (with ubuntu 16.10) to reopen unity8, the session is very fast game more than usual (it was from 2 weeks since the felt) but still the applications do not work and remain in their infinite loading. the cursor was displayed very large and it was slow (although I think it is caused by failure of applications open)

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

Using mir 0.21 and unity8.12+16.10.201605.18

Changed in qtubuntu:
assignee: nobody → Gerry Boland (gerboland)
status: New → In Progress
importance: Undecided → Critical
Revision history for this message
Gerry Boland (gerboland) wrote :

Hi Emanuele,
you attached a branch of mine to this bug - it makes our GL/EGL managing code more robust. I had hoped it would fix this issue, but unfortunately it doesn't. That's why I didn't attach that branch to this bug.

Annoyingly I don't have the hardware to hand either, so I'm flying slightly blind. I make a change, then ask someone else to test it. I'll have access to the hardware in about 2 weeks time, hopefully I'll have a breakthrough then.

In the mean time, I've assembled some diagnostic applications that might help me out.

If you're feeling adventurous, grab and compile lp:~gerboland/+junk/qteglchooser/

Run it with
 ./qteglchooser -o
and
 ./qteglchooser -o -i
and pastebin me the output.

It's a tool I made to try explain how Qt is deciding which EGL
configuration to use. Qt can end up jumping through many hoops figuring
out a good EGL config, but also I might be using it slightly wrong
(hence the -i switch).

I would also appreciate if you could please grab, compile, run and
pastebin me the output of lp:~gerboland/+junk/eglinfo

That just prints the EGL configurations available, plus other EGL stuff.

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

Hi Gerry,
I'm sorry if I'm not very experienced, but could you explain the full procedure to download it and run? I am interested in trying it

Revision history for this message
Gerry Boland (gerboland) wrote :

Hey Emanuele,
Albert got me the data I wanted from those tools, and the results are still inconclusive. I think I need access to the hardware to make real progress on this. So there's no need to bother with the trying those tools.

If you fancy a go, just to play:
1. Install build dependencies (I don't know if I have all here):
sudo apt install bzr build-essential qtbase5-dev qtbase5-private-dev

2. Download the code:
bzr branch lp:~gerboland/+junk/qteglchooser/
cd qteglchooser/

3. Compile:
qmake
make

You should get a qteglchooser binary, that you can then run as above.

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

I currently have a problem with the internet and the network is down, but if you say you have not had good results does not know what to do

Revision history for this message
Gerry Boland (gerboland) wrote :

Ok, progress, my tools can exhibit the problem:
http://pastebin.ubuntu.com/16677278/

Problems include:
1. libEGL warning: DRI3: xcb_connect failed <- should not be trying that
2. EGL version: 8.-1225087968 <- this is garbage

I suspect that there is an issue with EGL.

Revision history for this message
Gerry Boland (gerboland) wrote :

Forgot to say, that was reproduced running the qteglchooser while there was no X server running, instead just a Mir server running.

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

It is a good thing that you are able to find the problem? It is fixable?

Revision history for this message
Gerry Boland (gerboland) wrote :

Ok, I figured out hte EGL issue, it was my misunderstanding. Modifying the tools to act correctly, I get this for eglinfo:
http://pastebin.ubuntu.com/16686113/
and the qteglchooser correctly chooses a valid Mir EGL config. Why Qt itself cannot do this, I have yet to understand.

Revision history for this message
Gerry Boland (gerboland) wrote :

Ok, I suspect I have found the issue. Seems this hardware only supports OpenGL 1.4 compatibility profile. Qt's EGL code is asking for at least version 2.0, and so getting no valid context back.

Could you please install "mesa-utils" package and run "glxinfo". On the hardware I have access to, I see these lines in the output:

    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 1.4
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0

I need to figure out why the X11 glx code is working, but the EGL code is not. I also need to understand why at least OpenGL2.0 is desired by Qt.

An option is to use GLES2 on this hardware, but as the GL/GLES switch is made in Qt at compile time, that won't be straightforward either.

Revision history for this message
Gerry Boland (gerboland) wrote :

/me has to stop using "Ok, " at the start of his sentences

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

@Gerry hahaha

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :
Download full text (10.9 KiB)

name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile,
    GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample,
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile,
    GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB,
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info,
    GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
    GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
    GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile,
    GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
    GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample,
    GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
    GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float,
    GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context,
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_SGI_make_current_read,
    GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile,
    GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB,
    GLX_ARB_get_proc_address, GLX_ARB_multisample,
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile,
    GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB,
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info,
    GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_SGI_make_current_read,
    GLX_SGI_swap_control, GLX_SGI_video_sync
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Pineview M (0xa011)
    Version: 11.2.1
    Accelerated: yes
    Video memory: 384MB
    Unified memory: yes
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 1.4
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Pineview M
OpenGL version string: 1.4 Mesa 11.2.1
OpenGL extensions:
    GL_3DFX_texture_compression_FXT1, GL_AMD_shader_trinary_minmax,
    GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5,
    GL_APPLE_...

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

this is the result of that unity 7

Revision history for this message
Daniel van Vugt (vanvugt) wrote :
Download full text (6.9 KiB)

Gerry:
I would say you're looking in the wrong place asking GLX, but can confirm the same results with EGL: Full desktop OpenGL on Pineview is limited to 1.4, but GLES is version 2.0. Also: https://www.opengl.org/wiki/FAQ#Why_is_my_GL_version_only_1.4_or_lower.3F

But I don't think this is a problem at all. Right now I can see Mir demo servers running perfectly on Pineview in either mode with full hardware acceleration (no fallbacks) and even full desktop GLSL support at version 1.20 ...

mir_proving_server from lp:mir - GLESv2 default build:

[2016-05-27 12:02:05.879585] GLRenderer: EGL vendor: Mesa Project
[2016-05-27 12:02:05.879710] GLRenderer: EGL version: 1.4 (DRI2)
[2016-05-27 12:02:05.880050] GLRenderer: EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
[2016-05-27 12:02:05.880144] GLRenderer: EGL extensions: EGL_EXT_buffer_age EGL_KHR_create_context EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_surfaceless_context EGL_MESA_configless_context EGL_MESA_drm_image EGL_WL_bind_wayland_display
[2016-05-27 12:02:05.880215] GLRenderer: GL vendor: Intel Open Source Technology Center
[2016-05-27 12:02:05.880357] GLRenderer: GL renderer: Mesa DRI Intel(R) Pineview M
[2016-05-27 12:02:05.880432] GLRenderer: GL version: OpenGL ES 2.0 Mesa 11.2.0
[2016-05-27 12:02:05.880492] GLRenderer: GLSL version: OpenGL ES GLSL ES 1.0.16
[2016-05-27 12:02:05.880554] GLRenderer: GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8888 GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_npot GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_NV_fbo_color_attachments GL_OES_EGL_sync GL_OES_vertex_array_object GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug GL_OES_surfaceless_context GL_EXT_separate_shader_objects GL_EXT_draw_elements_base_vertex GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex
[2016-05-27 12:02:05.880664] GLRenderer: GL max texture size = 2048
[2016-05-27 12:02:05.880767] GLRenderer: GL framebuffer bits: RGBA=8888, depth=0, stencil=0

mir_proving_server from lp:mir with desktop OpenGL (-DMIR_SERVER_LIBGL=libGL):

[2016-05-27 12:03:13.811224] GLRenderer: EGL vendor: Mesa Project
[2016-05-27 12:03:13.811352] GLRenderer: EGL version: 1.4 (DRI2)
[2016-05-27 12:03:13.811413] GLRenderer: EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
[2016-05-27 12:03:13.811586] GLRenderer: EGL extensions: EGL_EXT_buffer_age EGL_KHR_create_context EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image...

Read more...

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

Shorter version:

mir_proving_server from lp:mir - GLES v2 works:

[2016-05-27 12:02:05.879585] GLRenderer: EGL vendor: Mesa Project
[2016-05-27 12:02:05.879710] GLRenderer: EGL version: 1.4 (DRI2)
[2016-05-27 12:02:05.880050] GLRenderer: EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
[2016-05-27 12:02:05.880215] GLRenderer: GL vendor: Intel Open Source Technology Center
[2016-05-27 12:02:05.880357] GLRenderer: GL renderer: Mesa DRI Intel(R) Pineview M
[2016-05-27 12:02:05.880432] GLRenderer: GL version: OpenGL ES 2.0 Mesa 11.2.0
[2016-05-27 12:02:05.880492] GLRenderer: GLSL version: OpenGL ES GLSL ES 1.0.16
[2016-05-27 12:02:05.880664] GLRenderer: GL max texture size = 2048
[2016-05-27 12:02:05.880767] GLRenderer: GL framebuffer bits: RGBA=8888, depth=0, stencil=0

mir_proving_server from lp:mir with desktop OpenGL (-DMIR_SERVER_LIBGL=libGL):

[2016-05-27 12:03:13.811224] GLRenderer: EGL vendor: Mesa Project
[2016-05-27 12:03:13.811352] GLRenderer: EGL version: 1.4 (DRI2)
[2016-05-27 12:03:13.811413] GLRenderer: EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
[2016-05-27 12:03:13.811784] GLRenderer: GL vendor: Intel Open Source Technology Center
[2016-05-27 12:03:13.811880] GLRenderer: GL renderer: Mesa DRI Intel(R) Pineview M
[2016-05-27 12:03:13.812004] GLRenderer: GL version: 1.4 Mesa 11.2.0
[2016-05-27 12:03:13.812241] GLRenderer: GLSL version: 1.20
[2016-05-27 12:03:13.813381] GLRenderer: GL max texture size = 2048
[2016-05-27 12:03:13.813769] GLRenderer: GL framebuffer bits: RGBA=8888, depth=0, stencil=0

Revision history for this message
Gerry Boland (gerboland) wrote :

Using simple test apps (lp:~gerboland/+junk/openglwindow & lp:~gerboland/+junk/qquickwindow-debug), it appears that yes Qt is using OpenGL 1.4 on X for both raw GL and QtQuick apps.

./qquickwindow-debug
Window format: QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile 0)
Context format: QSurfaceFormat(version 1.4, options QFlags(0x4), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile 0)
GLES: false

The "Context format: ... version 1.4" the thing to look for.

The EGL backend for Qt (X uses the GLX backend) is requiring OpenGl2 or greater (since that is what the Window is asking for), but the GLX backend seems to ignore that request, and just work.

Revision history for this message
Gerry Boland (gerboland) wrote :

I've updated the attached branch with my proposed fix.

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

@Gerry, have you tested it on pineview hardware?

Revision history for this message
Gerry Boland (gerboland) wrote :

@Emanuele yes I did - but only via SSH. A colleague will verify it works visually before approving

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

@Gerry Ok thanks!

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

it works?

Revision history for this message
Gerry Boland (gerboland) wrote :

Yep. The branch has been approved, will take a while to get it landed.

Note that it will be almost unusable until bug 1585723 is resolved.

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

Thanks!!!

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

roughly how long should we wait?

Changed in qtubuntu (Ubuntu):
assignee: nobody → Gerry Boland (gerboland)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtubuntu - 0.62+16.10.20160614-0ubuntu1

---------------
qtubuntu (0.62+16.10.20160614-0ubuntu1) yakkety; urgency=medium

  [ Daniel d'Andrada ]
  * Generate better mir session names

  [ Gerry Boland ]
  * Convert UbuntuOpenGLContext to use QEGLPlatformContext, and allow
    clients to customize chosen GLConfig (LP: #1507817, #1549455)
  * Integration: no need for the non-const versions of createWindow and
    createGLContext

  [ Nick Dedekind ]
  * Support for cross building

 -- Albert Astals Cid <email address hidden> Tue, 14 Jun 2016 08:34:32 +0000

Changed in qtubuntu (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

I've Tried it but is very very slow!

Michał Sawicz (saviq)
Changed in qtubuntu:
status: In Progress → Fix Released
Revision history for this message
Michał Sawicz (saviq) wrote :

Had to revert this due to bug #1594198, stay tuned.

Changed in qtubuntu:
status: Fix Released → Triaged
Changed in qtubuntu (Ubuntu):
status: Fix Released → Triaged
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

and now that the fix is ​​no longer present, when will solve this bug? Now you can not use more

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

?

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

one day we will never use Unity 8 on Atom?

Revision history for this message
Gerry Boland (gerboland) wrote :

Of course we will. We need to re-land the fix. It was reverted because it broke something else, but that's been solved now. Sorry for the delay, but it takes time to get things done just right.

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

When?

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Added to the description that Cherryview (Braswell 14nm Atom with Broadwell-level 8th gen Intel graphics) seems similarly affected. I can test fixes.

description: updated
Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Correcting, err, the fifth time worked or something which I guess couldn't be possible with this bug. Also I did not find the EGL error from unity8-dash.log. Sorry for the noise.

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

I've already confirmed Cherryview is not affected by this bug. But I'll update and check again.

description: updated
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

I confirm that the atom N470 processor is affected by this bug.

Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

With the last version of QtUbuntu mir and unity8 work on Atom, thanks Gerry! It is very slow ( but faster than the old EGL convenience version) but it works.

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

Fix reapplied in lp:qtubuntu r335 and now fix released to yakkety in:
  qtubuntu 0.63+16.10.20160809-0ubuntu1

Changed in qtubuntu:
status: Triaged → Fix Released
Changed in qtubuntu (Ubuntu):
status: Triaged → Fix Released
Changed in qtdeclarative (Ubuntu):
status: Confirmed → Invalid
Changed in qtmir (Ubuntu):
status: Confirmed → Invalid
Changed in unity8 (Ubuntu):
status: Confirmed → Fix Released
tags: added: unity8-desktop
Changed in canonical-devices-system-image:
status: New → Fix Committed
Changed in unity8 (Ubuntu):
status: Fix Released → Invalid
Michał Sawicz (saviq)
no longer affects: qtubuntu
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.