Created attachment 137898 [details]
GPU crash dump saved to /sys/class/drm/card0/error
Hi, could you provide more information about your system and the issue?
Which mesa version are you using?
(In reply to Elizabeth from comment #1)
> Hi, could you provide more information about your system and the issue?
> Which mesa version are you using?
Mesa 17.3.6-1, Arch Linux
Any way to reproduce this? Is functional on previous mesa versions or alternative configuration?
Created attachment 138154 [details]
This program causes the hang
This program causes the hang. Uncommenting the commented section in "shadershadow.geometry.txt" stops the hang.
There are such results for the present moment:
There are NO any GPU HANGs (commented out or not the noted section in "shadershadow.geometry.txt").
Tests were ran with mesa 17.3.[6-8].
In mesa 17.3.6 and 17.3.7 an error occured: "Mesa: User error: GL_INVALID_ENUM in glEnable(GL_TEXTURE_2D)" (in main.cpp:707:8)
System: Kernel: 4.15.14-1-MANJARO x86_64 bits: 64 Desktop: Cinnamon 3.6.6
Distro: Manjaro Linux 17.1.7 Hakoila
CPU: Topology: Quad Core model: Intel Core i5-3470 type: MCP L2 cache: 6144 KB
Speed: 3501 MHz min/max: 1600/3600 MHz Core speeds (MHz): 1: 3534 2: 3583 3: 3588 4: 3551
Graphics: Card-1: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller driver: i915 v: kernel
Waiting for a SANDYBRIDGE for next steps.
I have "Intel(R) Celeron(R) CPU G530 @ 2.40GHz", maybe it matters.
Created attachment 140223 [details]
shader_test to reproduce tihs issue
I have reproduced it on SNB.
I think that I found the root cause of the issue.
I have created the patch to fix it:
I have created shader_test to reproduce this issue also.
(In reply to asimiklit from comment #8)
New link of the patch: https://patchwork.freedesktop.org/patch/230342/
Created attachment 140260 [details]
Added dump of Geomery Shader (NIR, Assembler) which leads to GPU hang (mesa 1802 dev)
Created attachment 140261 [details]
Added dump of Geometry Shader (NIR, Assembler) where this issue is fixed by workaround v2 in compiller
Fixed in master with:
commit 232c5d75ea8c9536a896a17c9156b8e2ad36a779 (HEAD -> master)
Author: Andrii Simiklit <firstname.lastname@example.org>
Date: Fri Jun 22 10:59:57 2018 +0300
i965/gen6/gs: Handle case where a GS doesn't allocate VUE
We can not use the VUE Dereference flags combination for EOT
message under ILK and SNB because the threads are not initialized
there with initial VUE handle unlike Pre-IL.
So to avoid GPU hangs on SNB and ILK we need
to avoid usage of the VUE Dereference flags combination.
(Was tested only on SNB but according to the specification
SNB Volume 2 Part 1: 22.214.171.124, 126.96.36.199
the ILK must behave itself in the similar way)
v2: Approach to fix this issue was changed.
Instead of different EOT flags in the program end
we will create VUE every time even if GS produces no output.
v3: Clean up the patch.
Signed-off-by: Andrii Simiklit <email@example.com>
Reviewed-by: Iago Toral Quiroga <firstname.lastname@example.org>
Tested-by: Mark Janes <email@example.com>