Created attachment 134798 [details]
GPU hang log
I'm developing a compression system through compute shaders. The first shader now works fine, but after adding a second shader (even if it's got an empty main()), I've started getting GPU hangs:
[2557115.719316] [drm] GPU HANG: ecode 7:0:0x8fd8ffff, in narabu-encoder , reason: Hang on rcs0, action: reset
[2557115.719318] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[2557115.719319] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[2557115.719320] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[2557115.719321] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[2557115.719321] [drm] GPU crash dump saved to /sys/class/drm/card0/error
This is a Haswell laptop (Lenovo X240), Mesa 17.2.2, kernel 4.13.0. Attached is a gzipped crash dump (error.gz). My current code is available at
Make narabu-encoder and run it; it hangs the GPU nearly every time for me, adding 125 ms or so to the measured runtime.
Hm, after some research, it seems I cannot rely on compute shader invocations not to stomp on each other, even from the same draw call. If I insert glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT) between the two glDispatchCompute() calls, it stops hanging.
Nevertheless, it's odd that adding an empty shader should cause the problem to appear. I'm leaning towards not-a-bug, though.
There's a lot of potential state changes that could occur
by changing and dispatching another program, even if it is
empty. Therefore it is at least plausible that the empty
program could somehow trigger the application memory
barrier bug to show itself. Anyway, I'll close this for now.