<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:kenneth@whitecape.org" title="Kenneth Graunke <kenneth@whitecape.org>"> <span class="fn">Kenneth Graunke</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [SKL][bisected] DiRT Rally GPU hang"
href="https://bugs.freedesktop.org/show_bug.cgi?id=103101">bug 103101</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>FIXED
</td>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>ASSIGNED
</td>
<td>RESOLVED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [SKL][bisected] DiRT Rally GPU hang"
href="https://bugs.freedesktop.org/show_bug.cgi?id=103101#c9">Comment # 9</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [SKL][bisected] DiRT Rally GPU hang"
href="https://bugs.freedesktop.org/show_bug.cgi?id=103101">bug 103101</a>
from <span class="vcard"><a class="email" href="mailto:kenneth@whitecape.org" title="Kenneth Graunke <kenneth@whitecape.org>"> <span class="fn">Kenneth Graunke</span></a>
</span></b>
<pre>Fixed by:
commit cfc5af588cf8e0cfb41ea907a7da3cca676be1c2
Author: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>>
AuthorDate: Wed Nov 29 00:27:18 2017 -0800
Commit: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>>
CommitDate: Wed Nov 29 11:48:29 2017 -0800
i965: Program the dynamic state heap size to MAX_STATE_SIZE.
STATE_BASE_ADDRESS specifies a maximum size of the dynamic state
section, beyond which data supposedly reads back as 0. On Gen8+,
we were programming it to the size of the buffer. This worked fine
until we started growing the state buffer in commit 2dfc119f22f25708.
When the state buffer grows, the value in STATE_BASE_ADDRESS becomes
too small, and our state beyond STATE_SZ bytes would read back as 0.
To avoid having to update the value, we program it to MAX_STATE_SIZE.
We used to program the upper bound to the maximum on older hardware
anyway, so programming it too large isn't a big deal.
Bogus SURFACE_STATE can easily lead to GPU hangs and misrendering.
DiRT Rally was hitting the statebuffer growth path, and suffered from
bad texture corruption and GPU hangs (usually around the same time).
This patch fixes both issues.
Fixes: 2dfc119f22f257082ab0 "i965: Grow the batch/state buffers if we need
space and can't flush."
Bugzilla: <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [SKL][bisected] DiRT Rally GPU hang"
href="show_bug.cgi?id=103101">https://bugs.freedesktop.org/show_bug.cgi?id=103101</a>
Tested-by: Jordan Justen <<a href="mailto:jordan.l.justen@intel.com">jordan.l.justen@intel.com</a>>
Reviewed-by: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
Reviewed-by: Jordan Justen <<a href="mailto:jordan.l.justen@intel.com">jordan.l.justen@intel.com</a>>
Reviewed-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>>
These patches are also relevant stable candidates for fixing related bugs:
commit 2af70854609509adf5dc92af2fcf1c30938e2a5d
Author: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>>
Date: Tue Nov 28 08:30:50 2017 -0800
i965: Use old_bo->align when growing batch/state buffer instead of 4096.
The intention here is make the new BO use the same alignment as the old
BO. This isn't strictly necessary, but we would have to update the
'alignment' field in the validation list when swapping it out, and we
don't bother today.
The batch and state buffers use an alignment of 4096, so this should be
equivalent - it's just clearer than cut and pasting a magic constant.
Fixes: 2dfc119f22f257082ab0 "i965: Grow the batch/state buffers if we need
space and can't flush."
Reviewed-by: Ian Romanick <<a href="mailto:ian.d.romanick@intel.com">ian.d.romanick@intel.com</a>>
Reviewed-by: Jordan Justen <<a href="mailto:jordan.l.justen@intel.com">jordan.l.justen@intel.com</a>>
commit 52d32917e1f3f70abcbcff5508f7423e94626b41
Author: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>>
Date: Tue Nov 28 08:59:07 2017 -0800
i965: Preserve EXEC_OBJECT_CAPTURE when growing the BO.
The original state buffer was marked with EXEC_OBJECT_CAPTURE. When
growing it, we want to preserve that flag so we continue to capture it
in GPU hang reports.
Fixes: 2dfc119f22f257082ab0 "i965: Grow the batch/state buffers if we need
s
pace and can't flush."
Reviewed-by: Ian Romanick <<a href="mailto:ian.d.romanick@intel.com">ian.d.romanick@intel.com</a>>
commit ca4361658635f2b401e9793c0b982721998ecb70
Author: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>>
Date: Tue Nov 28 08:20:39 2017 -0800
i965: Don't grow batch/state buffer on every emit after an overflow.
Once we reach the intended size of the buffer (BATCH_SZ or STATE_SZ), we
try and flush. If we're not allowed to flush, we resort to growing the
buffer so that there's space for the data we need to emit.
We accidentally got the threshold wrong. The first non-wrappable call
beyond (e.g.) STATE_SZ would grow the buffer to floor(1.5 * STATE_SZ),
The next call would see we were beyond STATE_SZ and think we needed to
grow a second time - when the buffer was already large enough.
We still want to flush when we hit STATE_SZ, but for growing, we should
use the actual size of the buffer as the threshold. This way, we only
grow when actually necessary.
v2: Simplify the control flow (suggested by Jordan)
Fixes: 2dfc119f22f257082ab0 "i965: Grow the batch/state buffers if we need
s
pace and can't flush."
Reviewed-by: Jordan Justen <<a href="mailto:jordan.l.justen@intel.com">jordan.l.justen@intel.com</a>>
One more related fix remains unreviewed:
i965: Avoid problems from referencing orphaned BOs after growing.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>