running qrenderdoc on linux haswell exits with "intel_do_flush_locked failed"

[jrmuizel]

I've filed https://bugs.freedesktop.org/show_bug.cgi?id=99831 about this.

[baldurk]

I'm not clear - do you suspect this is a bug driver side or renderdoc side?

[jrmuizel]

This is a driver side bug being triggered by renderdoc. It's probably valuable for renderdoc to work around it if possible. Hopefully, with some help from the driver authors it will be easier to understand what's going wrong.

[baldurk]

OK, as long as it doesn't have too big an impact I don't mind adding driver workarounds. I'd need more information to figure that out though.

I'm going to close this issue for now since there's nothing to do on my side, but either comment here or open a new issue if it turns out to be a bug in renderdoc or there's a workaround available. People will find this bug if they're searching for that error code.

[octylFractal]

The comments on that bug seem to suggest an error in renderdoc. I'm having a similar problem, here is a capture that reliably reproduces the crash: java_2017.05.09_02.41.54_frame138.rdc

I'm running Ubuntu 17.10 with Mesa 17.0.3, and am working on updating to Mesa master to see if it works there. If you need anything else, just ask and I will get it to you ASAP.

[baldurk]

I investigated it from my side, but the errors being thrown are invalid (ie. the calls are legal). They seem pretty harmless though apart from firing an error.

I found that I could narrow down what was causing the crash by inserting glFlush() around key points. I got the repro case working if I commented out some key bits of the display loop, so it was still replaying just not displaying on screen. I had no idea how to investigate any further though, so I passed that information on to Mark Janes and Jordan Justen in IRC.

[jljusten]

I got the repro case working if I commented out some key bits of the display loop, so it was still replaying just not displaying on screen.

@baldurk: Could you share a branch or patch that makes the crash go away so we can take a look? It might help isolate the bug.

[baldurk]

Commenting out the internal clear, texture preview render, and the blit from internal backbuffer -> window context real backbuffer lets me run renderdoccmd replay wrench.rdc and it stays stable:

diff --git a/renderdoc/driver/gl/gl_debug.cpp b/renderdoc/driver/gl/gl_debug.cpp
index 6893126..b490cea 100644
--- a/renderdoc/driver/gl/gl_debug.cpp
+++ b/renderdoc/driver/gl/gl_debug.cpp
@@ -2015,6 +2015,7 @@ bool GLReplay::RenderTextureInternal(TextureDisplay cfg, int flags)
   gl.glEnable(eGL_FRAMEBUFFER_SRGB);

   gl.glBindVertexArray(DebugData.emptyVAO);
-  gl.glDrawArrays(eGL_TRIANGLE_STRIP, 0, 4);
+  // gl.glDrawArrays(eGL_TRIANGLE_STRIP, 0, 4);
   gl.glDrawArrays(eGL_TRIANGLE_STRIP, 0, 4);

   if(maxlevel[0] >= 0)
diff --git a/renderdoc/driver/gl/gl_replay.cpp b/renderdoc/driver/gl/gl_replay.cpp
index 7be5980..25a6a24 100644
--- a/renderdoc/driver/gl/gl_replay.cpp
+++ b/renderdoc/driver/gl/gl_replay.cpp
@@ -331,7 +331,7 @@ void GLReplay::ClearOutputWindowColor(uint64_t id, float col[4])

   MakeCurrentReplayContext(m_DebugCtx);

-  m_pDriver->glClearBufferfv(eGL_COLOR, 0, col);
+  // m_pDriver->glClearBufferfv(eGL_COLOR, 0, col);
 }

 void GLReplay::ClearOutputWindowDepth(uint64_t id, float depth, uint8_t stencil)
@@ -367,8 +367,8 @@ void GLReplay::FlipOutputWindow(uint64_t id)

   gl.glEnable(eGL_FRAMEBUFFER_SRGB);

-  gl.glBlitFramebuffer(0, 0, outw.width, outw.height, 0, 0, outw.width, outw.height,
-                       GL_COLOR_BUFFER_BIT, eGL_NEAREST);
+  // gl.glBlitFramebuffer(0, 0, outw.width, outw.height, 0, 0, outw.width, outw.height,
+  //                      GL_COLOR_BUFFER_BIT, eGL_NEAREST);

   SwapBuffers(&outw);
 }

So this is still doing all of the 'hard work' of replaying the capture internally each frame, and drawing a checkerboard behind where the texture preview would be, it's just not displaying the backbuffer texture and then blitting the result to the screen.

I also had success changing the shader used for texture preview to a simple one that just renders the checkerboard, but the other two functions still have to be commented out:

diff --git a/renderdoc/driver/gl/gl_debug.cpp b/renderdoc/driver/gl/gl_debug.cpp
index 6893126..b490cea 100644
--- a/renderdoc/driver/gl/gl_debug.cpp
+++ b/renderdoc/driver/gl/gl_debug.cpp
@@ -2015,6 +2015,7 @@ bool GLReplay::RenderTextureInternal(TextureDisplay cfg, int flags)
   gl.glEnable(eGL_FRAMEBUFFER_SRGB);

   gl.glBindVertexArray(DebugData.emptyVAO);
+  gl.glUseProgram(DebugData.checkerProg);
   gl.glDrawArrays(eGL_TRIANGLE_STRIP, 0, 4);

   if(maxlevel[0] >= 0)

What's weird though is that if you put a glFlush right after the texture draw with no other modifications, you can get it to crash right there before it even gets to e.g. the blit - which I thought indicated the problem inside that draw. But if you only comment it out and leave everything else, you just get the same problem happening later:

diff --git a/renderdoc/driver/gl/gl_debug.cpp b/renderdoc/driver/gl/gl_debug.cpp
index 6893126..2b6828e 100644
--- a/renderdoc/driver/gl/gl_debug.cpp
+++ b/renderdoc/driver/gl/gl_debug.cpp
@@ -2016,6 +2016,9 @@ bool GLReplay::RenderTextureInternal(TextureDisplay cfg, int flags)

   gl.glBindVertexArray(DebugData.emptyVAO);
   gl.glDrawArrays(eGL_TRIANGLE_STRIP, 0, 4);
+  RDCLOG("Crash after this is printed");
+  gl.glFlush();
+  RDCLOG("Crash before this is printed");

   if(maxlevel[0] >= 0)
     gl.glTextureParameterivEXT(texname, target, eGL_TEXTURE_MAX_LEVEL, maxlevel);

gives output:

...
Log     - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 29, 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 29, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glGetProgramStageiv'
Log     - Timer chunk initialisation - 1495.982 ms
Log     - Crash after this is printed
intel_do_flush_locked failed: No such file or directory

[jljusten]

work around added to renderdoc in 3ab7510c7f46