Bug 97083 - [IVB,BYT] GPU hang on deqp-gles31.functional.separate.shader.random
Summary: [IVB,BYT] GPU hang on deqp-gles31.functional.separate.shader.random
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Kenneth Graunke
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-25 23:21 UTC by Mark Janes
Modified: 2016-08-02 04:42 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Janes 2016-07-25 23:21:41 UTC
Bisected to:
1eef0b73aa323d94d5a080cd1efa81ccacdbd0d2
Author:     Kenneth Graunke <kenneth@whitecape.org>
i965: Rewrite FS input handling to use the new NIR intrinsics.

To reproduce, I ran deqp gles31 through piglit:

MESA_GLES_VERSION_OVERRIDE=3.1 PIGLIT_DEQP_GLES31_EXTRA_ARGS="--deqp-log-images=disable --deqp-gl-config-name=rgba8888d24s8 --deqp-surface-width=400 --deqp-surface-height=300 --deqp-visibility=hidden" PIGLIT_DEQP_GLES31_BIN=/tmp/build_root/m64/opt/deqp/modules/gles31/deqp-gles31  /tmp/build_root/m64/bin/piglit run -p gbm -c --include-tests deqp-gles31.functional.separate.shader.random deqp_gles31 /tmp/build_root/m64/test/ivb

GPU hang should reproduce in the first few test cases run.
Comment 1 Kenneth Graunke 2016-07-29 23:09:33 UTC
This should be fixed by:

commit ebdc82d06532f992aea592265c29a11330e698fa
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Tue Jul 26 13:19:46 2016 -0700

    i965: Fix move_interpolation_to_top() pass.
    
    ...

    Papers over GPU hangs on Ivybridge and Baytrail caused by the
    recent NIR FS input rework by restoring the old behavior.
    (I'm not honestly sure why they hang with PLN not at the top.)

However...it's probably worth trying to understand why they hang with move_interpolation_to_top disabled.
Comment 2 Kenneth Graunke 2016-08-02 04:42:52 UTC
Curro figured this one out.  The problem was the NoDDClear/NoDDCheck flags on the PLN instructions.  Normally, we do a (-f0.0) PLN with NoDDClear (for helper pixels) and a (+f0.0) PLN with NoDDCheck.  This works fine at the top level, because at least one pixel won't be a helper invocation, so the (-f0.0) PLN with NoDDClear will actually execute.

But with my (broken) rework, we started emitting PLNs inside control flow.  If only helper pixels take a certain control flow path, the (-f0.0) PLN with NoDDClear might not ever execute, leaving the register dependency set, so the next instruction that tries to touch that register would hang.

So, move to top is a real solution to this problem, not just papering over it.
I've also sent a patch to the mailing list that eliminates the PLN dependency hints, which will allow us to move PLNs into control flow safely (if we want to):
https://lists.freedesktop.org/archives/mesa-dev/2016-August/124946.html


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.