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
Changed in mir:
status: Invalid → Confirmed
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"]
Changed in mir (Ubuntu):
status: New → Confirmed
importance: Undecided → High
description: updated
Changed in qtdeclarative (Ubuntu):
status: New → Confirmed
tags: added: black-screen
Changed in qtubuntu (Ubuntu):
importance: High → Critical
status: Confirmed → Triaged
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"]
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"]
Changed in unity8 (Ubuntu):
importance: Undecided → Critical
Changed in qtmir (Ubuntu):
status: New → Confirmed
Changed in unity8 (Ubuntu):
status: New → Confirmed
Gerry Boland (gerboland)
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
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"]
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"]
31 comments hidden view all 111 comments
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
Displaying first 40 and last 40 comments. View all 111 comments or add a comment.
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.