I see the same bug on a
Ivy Bridge i7-3540M with Linux 4.10.8 (OpenSUSE Tumbleweed), Mesa 17.0.1

The last time I tried qrenderdoc, it fell over right away due to incompatibilities that it had with the Intel vulkan driver.  I also encountered at least one issue with Mesa that was fixed (after 17.0).

If you want to try qrenderdoc on Intel hardware, be aware that the author is not testing the tool with Mesa.  YMMV.

You will need to run a newer Mesa.  I recommend using mesa's master branch.

I was able to use qrenderdoc on extremely simple workloads (VulkanTools demos) for a few minutes before the tool reported a device lost error.  Since the Mesa driver is passing the conformance test and running complex workloads (DOTA, Talos), I expect there is an issue with qrenderdoc, not Mesa.

You can re-open this bug if you can easily reproduce similar behavior on BDW or later hardware, with current Mesa.

Apologies, I didn't realize this was a trace of a gl workload.

This is probably a bug in RenderDoc.  When I run it:

Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_NUM_SHADING_LANGUAGE_VERSIONS)
Log     - GLSL version 150
Warning - Quad overdraw requires GLSL 4.50 for dFd(xy)fine, using possibly coarse dFd(xy).
qrenderdoc: /home/majanes/src/jenkins/repos/mesa/src/intel/blorp/blorp_blit.c:2326: surf_convert_to_uncompressed: Assertion `info->surf.phys_level0_sa.width % fmtl->bw == 0' failed.


Jeff, have you been able to capture and replay your workload on other GPUs?  Does RenderDoc work with this file on windows? What are you trying to accomplish with RenderDoc?

Mark,

Is it common for Intel driver to crash because of GL error?

I've spent some time trying to debug this, but unfortunately
I've not made any substantial discoveries.

I suspect it is something unexpected happening with creating
a shared GL context to replay the rendering trace, but I'm
kind of stuck.

Ben suggested that the kernel code is behaving in a very
unexpected manner, and he suggested that I should try to
isolate what is happening in the kernel. I have not had
time to investigate that.

I reproduced it on Skylake and Haswell.

Dimitry, what indication is there that Mesa crashes on this workload?

If I turn off assertions, I get many errors indicating that the application is making invalid calls.  I think qrenderdoc is crashing, not mesa.

Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)'
Warning - Technically you could try and readback the contents of a RenderBuffer via pixel copy.
Warning - Currently we don't support that though, and initial contents will be uninitialised.
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 30, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Timer chunk initialisation - 311.896 ms
Log     - QRenderDoc - renderer created for "/home/majanes/Downloads/wrench.rdc"
Warning - QFileSystemWatcher::removePaths: list is empty
intel_do_flush_locked failed: No such file or directory
Warning - QObject::~QObject: Timers cannot be stopped from another thread

FWIW, I tried to open this file on windows RenderDoc.  It hung trying to open the file on a skylake win10 system.  RenderDoc generally supports cross-platform support for log files, which may indicate that a missing hardware feature is required by RenderDoc.

Baldurk (creator of RenderDoc) will take a look at this log file in Intel hardware.

Note that baldurk appears to be done (for now) with
investigating the renderdoc side and currently has
concluded that it must be a driver bug.

Hey Jeff,

Can you tell us who the end-user customer is that's experiencing this issue and the impact of this particular issue on their business?

Thanks.

I guess the end-user customer is Mozilla and this is limiting our ability to develop and debug WebRender on Intel hardware.

After more investigation, this seems to be a duplicate of
https://bugs.freedesktop.org/show_bug.cgi?id=54971
which has been open since 2012.

I talked to baldurk on irc, and he agreed to look into
whether renderdoc can be changed to only call XOpenDisplay
once.

Baldurk put a work-around into upstream for this.

I'll close this as we already have other open bugs
(such as 41736, 54971) for the XOpenDisplay issue.

git://github.com/baldurk/renderdoc.git

commit 3ab7510c7f4695afa1a21426f791de288329878d
Author: baldurk <baldurk@baldurk.org>
Date:   Tue May 30 12:02:00 2017 +0100

    Avoid calling XOpenDisplay multiple times, fixes crashes on Intel Mesa

    * See https://bugs.freedesktop.org/show_bug.cgi?id=99831
      https://bugs.freedesktop.org/show_bug.cgi?id=54971
    * It's not clear if it's invalid to call XOpenDisplay more than once but
      at the very least it's only really used as convenience to avoid
      plumbing the display handle through.

*** This bug has been marked as a duplicate of bug 54971 ***