Bug 96671

Jairo, can you reproduce this?  Does it still occur with the quarterly release that you are currently testing?

Just a comment the "Installer" is actually a update tool, in this case updates the Mesa from 11.0.3 from Fedora to Mesa 11.1.2
Jairo will try to reproduce using the same components from the update tool and add logs. This is a Broadwell system Jairo please report your findings..

I was able to reproduce the issue. You are able to run Matlab in low graphics mode.

After applying changes from Installer tool. I got the following error executing any script that involves graphics in Matlab:

> run graphicsInteractiveApp.m
Error using hgopengl
Java exception occurred:
java.lang.RuntimeException: Waited 5000ms for: <67f6359a, 553946c8>[count 2 [ add. 0, orig 2], qsz 0, owner <Startup Class Loader>, add.owner Startup Class Loader-SharedResourceRunner] - <main>
	at jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock(RecursiveLockImpl01Unfairish.java:198)
	at com.jogamp.opengl.GLProfile.initSingleton(GLProfile.java:199)
	at com.jogamp.opengl.GLProfile.getDefaultDevice(GLProfile.java:2003)
	at com.jogamp.opengl.GLCapabilities.<init>(GLCapabilities.java:84)
	at com.mathworks.hg.uij.OpenGLUtils$MyGLListener.getGLInformation(OpenGLUtils.java:320)
	at com.mathworks.hg.uij.OpenGLUtils$MyGLListener.getGLData(OpenGLUtils.java:498)
	at com.mathworks.hg.uij.OpenGLUtils.getGLData(OpenGLUtils.java:78)

Error in hgopengl

Error in graphicsInteractiveApp (line 37)
d = opengl('data');


Error in run (line 96)
evalin('caller', [script ';']);.

Attaching Dmesg

Created attachment 126032 [details]
Dmesg

The installer tool summary (changes):

Added:
    intel-gpu-tools:x86_64 (2.99.917-23.intel20161)
    libva-intel-driver:x86_64 (1.7.0-23.intel20161)
    libva-utils:x86_64 (1.7.0-23.intel20161)
    libva:x86_64 (1.7.0-23.intel20161)
    mesa-libOSMesa:x86_64 (11.1.2-23.intel20161)
    
Upgraded:
    cairo-gobject:x86_64 (from 1.14.2-2.fc23 to 1.15.2-23.intel20161)
    cairo:x86_64 (from 1.14.2-2.fc23 to 1.15.2-23.intel20161)
    libdrm:x86_64 (from 2.4.66-1.fc23 to 2.4.67-23.intel20161)
    mesa-dri-drivers:x86_64 (from 11.1.0-4.20151218.fc23 to 11.1.2-23.intel20161)
    mesa-filesystem:x86_64 (from 11.1.0-4.20151218.fc23 to 11.1.2-23.intel20161)
    mesa-libEGL:x86_64 (from 11.1.0-4.20151218.fc23 to 11.1.2-23.intel20161)
    mesa-libGL:x86_64 (from 11.1.0-4.20151218.fc23 to 11.1.2-23.intel20161)
    mesa-libGLES:x86_64 (from 11.1.0-4.20151218.fc23 to 11.1.2-23.intel20161)
    mesa-libgbm:x86_64 (from 11.1.0-4.20151218.fc23 to 11.1.2-23.intel20161)
    mesa-libglapi:x86_64 (from 11.1.0-4.20151218.fc23 to 11.1.2-23.intel20161)
    mesa-libwayland-egl:x86_64 (from 11.1.0-4.20151218.fc23 to 11.1.2-23.intel20161)
    mesa-libxatracker:x86_64 (from 11.1.0-4.20151218.fc23 to 11.1.2-23.intel20161)
    xorg-x11-drv-intel:x86_64 (from 2.99.917-19.20151206.fc23 to 2.99.917-23.intel20161)

Playing arround with different Mesa Version, i found that you can try to compile 12.0.0 and install it, it is working for me so far.

Created attachment 126278 [details]
Screenshot

Application crashes when launched.

BDW-U Wilson Beach
Intel® Core™ i5-5300U CPU @ 2.30GHz
Intel® HD Graphics 5500 (Broadwell GT2) 
Ubuntu 16.04 LTS 64 bits
Bios: BDW-E2R1.86C.0095.R09.1410300006
Kernel: 4.8.0-rc4 9baa666 from http://cgit.freedesktop.org/drm-intel/
  commit 9baa666b3e48f71b46c5f63541f57d2a95a1b1c0
  Author: Chris Wilson <chris@chris-wilson.co.uk>
  Date:   Sat Sep 3 13:12:38 2016 +0100
  drm-intel-nightly: 2016y-09m-03d-12h-12m-15s UTC integration manifest

Created attachment 126279 [details]
matlab_crash_dump

Created attachment 126280 [details]
log

Created attachment 126281 [details]
kern.log

Created attachment 126282 [details]
glxinfo

(In reply to Elio from comment #6)
> Playing arround with different Mesa Version, i found that you can try to
> compile 12.0.0 and install it, it is working for me so far.

I'm going to close the bug based on this comment, but please feel free to reopen if you upgrade to Mesa 12 or 13 and find that it is still not working.

I tested the latest Intel LINUX driver and unfortunately the MATLAB hang issue does not appear to be resolved.

I tested using a Fedora 25 installation.  I was assuming that this version of Fedora would be using the latest Intel Mesa driver since it was just recently released.  This version of Fedora is indeed using a Mesa 12 based Intel driver, but unfortunately MATLAB still hangs when performing any type of graphics operation.  The following are the details of the renderer…

Version: '3.0 Mesa 12.0.3'
Vendor: 'Intel Open Source Technology Center’
Renderer: 'Mesa DRI Intel(R) Sandybridge Mobile '

All of my testing has been done on a Lenovo T520 ThinkPad. 

Fortunately, the workaround of setting the environment variable LIBGL_DRI3_DISABLE to 1 still works.

Could someone take another look into this issue?

Could someone also explain why using the LIBGL_DRI3_DISABLE environment variable avoids the issue?

Thanks.

(In reply to Rick from comment #13)
> I tested the latest Intel LINUX driver and unfortunately the MATLAB hang
> issue does not appear to be resolved.
> 
> I tested using a Fedora 25 installation.  I was assuming that this version
> of Fedora would be using the latest Intel Mesa driver since it was just
> recently released.  This version of Fedora is indeed using a Mesa 12 based
> Intel driver, but unfortunately MATLAB still hangs when performing any type
> of graphics operation.  The following are the details of the renderer…
> 
> Version: '3.0 Mesa 12.0.3'
> Vendor: 'Intel Open Source Technology Center’
> Renderer: 'Mesa DRI Intel(R) Sandybridge Mobile '
> 
> All of my testing has been done on a Lenovo T520 ThinkPad. 
> 
> Fortunately, the workaround of setting the environment variable
> LIBGL_DRI3_DISABLE to 1 still works.
> 
> Could someone take another look into this issue?
> 
> Could someone also explain why using the LIBGL_DRI3_DISABLE environment
> variable avoids the issue?
> 
> Thanks.

Could you share more details about which version of matlab you are using? On R2016b (free trial), matlab crashes as soon as it tries to use GL, but only when I start it with -nosoftwareopengl.

Could you share more about your setup?

The hang should occur with the latest MATLAB releases (16a and 16b).  MATLAB should be using hardware OpenGL by default, so there shouldn't be a need to provide the -nosoftwareopengl startup argument.  It is possible that MATLAB start up detected a problem with the graphics hardware support and switched to using software OpenGL.  If you start MATLAB without the -nosoftwareopengl argument, what output does the 'opengl info' command produce?  Thanks.

Created attachment 129134 [details]
Crash log of matlab on my system

(In reply to Rick from comment #15)
> The hang should occur with the latest MATLAB releases (16a and 16b).  MATLAB
> should be using hardware OpenGL by default, so there shouldn't be a need to
> provide the -nosoftwareopengl startup argument.  It is possible that MATLAB
> start up detected a problem with the graphics hardware support and switched
> to using software OpenGL.  If you start MATLAB without the -nosoftwareopengl
> argument, what output does the 'opengl info' command produce?  Thanks.

OK, I figured out why matlab reverted directly to using the software GL: sys/os/glnxa64/libstdc++.so.6: version `CXXABI_1.3.9' not found

This libstdc++ is a little old and does not support the new CXXABI introduced in gcc 4.9 which archlinux is using. I deleted this file and it reverted back to using the system-provided library.

I still get a crash though (https://bugs.freedesktop.org/attachment.cgi?id=129134). Will try to debug with gdb what the heck is going on.

(In reply to Martin Peres from comment #17)
> (In reply to Rick from comment #15)
> > The hang should occur with the latest MATLAB releases (16a and 16b).  MATLAB
> > should be using hardware OpenGL by default, so there shouldn't be a need to
> > provide the -nosoftwareopengl startup argument.  It is possible that MATLAB
> > start up detected a problem with the graphics hardware support and switched
> > to using software OpenGL.  If you start MATLAB without the -nosoftwareopengl
> > argument, what output does the 'opengl info' command produce?  Thanks.
> 
> OK, I figured out why matlab reverted directly to using the software GL:
> sys/os/glnxa64/libstdc++.so.6: version `CXXABI_1.3.9' not found
> 
> This libstdc++ is a little old and does not support the new CXXABI
> introduced in gcc 4.9 which archlinux is using. I deleted this file and it
> reverted back to using the system-provided library.
> 
> I still get a crash though
> (https://bugs.freedesktop.org/attachment.cgi?id=129134). Will try to debug
> with gdb what the heck is going on.

OK, got it to work quite well on mesa 17 but it crashes on mesa 13. The fix is

commit b6670157d742548e7f2430614786c733eb4c20e9
Author: Fredrik Höglund <fredrik@kde.org>
Date:   Sun Jan 1 15:34:17 2017 +0100

    dri3: Fix MakeCurrent without a default framebuffer
    
    In OpenGL 3.0 and later it is legal to make a context current without
    a default framebuffer.
    
    This has been broken since DRI3 support was introduced.
    
    Cc: "13.0 12.0" <mesa-stable@lists.freedesktop.org>
    Reviewed-by: Marek Olšák <marek.olsak@amd.com>


Not sure why you can even start the application at all :s However, I can say that the examples/graphics/AddAxisLabelsExample.m works quite well for me now.

This patch should make it in your distro relatively soon since it has been tagged for a new 13.X release but it has not landed yet. Please re-open the bug if the next version of mesa 13.x includes the patch (check like this: https://cgit.freedesktop.org/mesa/mesa/log/?h=13.0&qt=grep&q=dri3%3A+Fix+MakeCurrent+without+a+default+framebuffer) but you still experience the hangs.

Thanks.  I will try out the possible fix once it becomes available in Intel's graphics update tool...  https://01.org/linuxgraphics/downloads

That being said, is there any type of existing testing process that can be enhanced to avoid a recurrence of such an issue?  This issue has caused a bit of pain for numerous customers, but the problem could have been avoided with some basic application testing.  I would be interested in exploring ways of adding automated application specific testing to any existing regression testing process that you already have in place.  Please let me know if there is interest in this idea.  Thanks!

(In reply to Rick from comment #19)
> Thanks.  I will try out the possible fix once it becomes available in
> Intel's graphics update tool...  https://01.org/linuxgraphics/downloads
> 
> That being said, is there any type of existing testing process that can be
> enhanced to avoid a recurrence of such an issue?  This issue has caused a
> bit of pain for numerous customers, but the problem could have been avoided
> with some basic application testing.  I would be interested in exploring
> ways of adding automated application specific testing to any existing
> regression testing process that you already have in place.  Please let me
> know if there is interest in this idea.  Thanks!

Thanks a lot for caring about this!

Trust me when I say this. I am doing *everything* I can to improve the testing situation for our driver. In the coming days, I will make an apitrace trace of mathlab, so as we can use it in our testing to verify both correctness in rendering and in performance.

However, you will have to bear with us, as our current test systems are not geared towards this sort of testing, and this is what I am trying to change.

Sounds good.  Please do contact me if you need help in regards to MATLAB testing.  Thank you.

I just confirmed that the latest update tool released on June 5, 2017 fixes the issue for Fedora 25...

https://01.org/linuxgraphics/downloads/intel-graphics-update-tool-linux-os-v2.0.5

Thanks!

Since that issue is now addressed, is anyone interested in discussing ways automated MATLAB testing might be incorporated into your testing procedures to prevent an issue like this in the future?  As I mentioned previously, this particular issue caused a bit of pain to multiple customers and it would be good to avoid a recurrence of such a preventable issue (hang when performing graphics operations) in the future.  Thanks!

(In reply to Rick from comment #22)
> I just confirmed that the latest update tool released on June 5, 2017 fixes
> the issue for Fedora 25...
> 
> https://01.org/linuxgraphics/downloads/intel-graphics-update-tool-linux-os-
> v2.0.5
> 
> Thanks!
> 
> Since that issue is now addressed, is anyone interested in discussing ways
> automated MATLAB testing might be incorporated into your testing procedures
> to prevent an issue like this in the future?  As I mentioned previously,
> this particular issue caused a bit of pain to multiple customers and it
> would be good to avoid a recurrence of such a preventable issue (hang when
> performing graphics operations) in the future.  Thanks!

Thanks for checking!

I tried to make an apitrace of how matlab uses our driver, but it did not fare well (just a ton of commands, but no swapbuffer IIRC) and I took interest in something else.

If you manage to get useful apitraces of what matlab does, we could run them and check for crashes and changes in rendering.

Can you identify exactly what you need?  I would imagine some simple commands such as 'peaks', 'penny', 'image', 'surface', and 'plot(1:10,1:10)' would all perform some basic OpenGL rendering.  I could also provide some apitraces if you provide guidance on what you require.  Thanks.  Rick

...that being said...I am not sure if apitrace testing would have avoided this specific issue.  This issue seemed to be related to driver installation or initialization at startup.  Verification of graphics behavior with an actual MATLAB installation would be preferred over apitrace testing.   Thanks!