Bug 92590 - [BSW] [GLES 3.1 CTS] ES31-CTS.shader_storage_buffer_object.* GPU_HANG
Summary: [BSW] [GLES 3.1 CTS] ES31-CTS.shader_storage_buffer_object.* GPU_HANG
Status: VERIFIED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 11.0
Hardware: Other All
: high major
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-22 10:07 UTC by Marta Löfstedt
Modified: 2015-11-13 09:35 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg with GPU_HANG (144.92 KB, text/plain)
2015-10-22 10:07 UTC, Marta Löfstedt
Details

Description Marta Löfstedt 2015-10-22 10:07:37 UTC
Created attachment 119062 [details]
dmesg with GPU_HANG

Software versions:
    4.2.1-040201-generic
    OpenGL version string: 3.0 Mesa 11.1.0-devel (git-13a5805)

GPU hardware:
    OpenGL renderer string: Mesa DRI Intel(R) HD Graphics (Cherryview)
    00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:22b1] (rev 21)

CPU hardware:
    x86_64
    Genuine Intel(R) CPU         @ 1.52GHz

CTS version:
git@67ae88f31295

command: 
./glcts --deqp-case=ES31-CTS.shader_storage_buffer_object*

Environment:
Mesa built with: --enable-debug
export MESA_GLES_VERSION_OVERRIDE=3.1
export MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader

-------------------------------------------
When running all the SSBO tests of the OpenGL ES 3.1 CTS, execution stops after:
'ES31-CTS.shader_storage_buffer_object.advanced-indirectAddressing-case1-cs'..
with: intel_do_flush_locked failed: Input/output error
dmesg contains:
[drm] GPU HANG: ecode 8:0:0x85ddfffb, in glcts [11749], reason: Ring hung, action: reset

if I run the ES31-CTS.shader_storage_buffer_object.advanced-indirectAddressing-case1-cs alone there are no issues.
Comment 1 Kenneth Graunke 2015-10-26 06:28:28 UTC
If these pass on Broadwell but break on Braswell, you might see if the SSBO code is emitting integer MUL instructions for indirect address calculations.  CHV/BSW have funky MUL rules...
Comment 2 Iago Toral 2015-10-29 11:14:08 UTC
(In reply to Kenneth Graunke from comment #1)
> If these pass on Broadwell but break on Braswell, you might see if the SSBO
> code is emitting integer MUL instructions for indirect address calculations.
> CHV/BSW have funky MUL rules...

Yeah, that can happen. I see this for some local ssbo tests I have that use indirect addressing:

vec1 ssa_7 = f2i ssa_6
vec1 ssa_8 = imul ssa_7, ssa_3
vec1 ssa_9 = iadd ssa_8, ssa_2
ntrinsic store_ssbo_indirect (ssa_1, ssa_0, ssa_9) () (0, 1)

which leads to:

mov(8)          g3<1>D          g2<8,8,1>F               { align1 1Q compacted };
mul(8)          g4<1>D          g3<8,8,1>D      16D      { align1 1Q compacted };
add(8)          g6<1>D          g4<8,8,1>D      12D      { align1 1Q compacted };
send(8)         null            g5<8,8,1>UD
         data ( DC untyped surface write, 1, 46) mlen 3 rlen 0 { align1 1Q };
Comment 3 Marta Löfstedt 2015-11-02 09:19:06 UTC
This issue is not reproducible with Mesa git@af7c98


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.