-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
running qrenderdoc on linux haswell exits with "intel_do_flush_locked failed" #515
Comments
I'm not clear - do you suspect this is a bug driver side or renderdoc side? |
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. |
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. |
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. |
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. |
@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. |
Commenting out the internal clear, texture preview render, and the blit from internal backbuffer -> window context real backbuffer lets me run 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:
|
work around added to renderdoc in 3ab7510c7f46 |
I've filed https://bugs.freedesktop.org/show_bug.cgi?id=99831 about this.
The text was updated successfully, but these errors were encountered: