<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:jason@jlekstrand.net" title="Jason Ekstrand <jason@jlekstrand.net>"> <span class="fn">Jason Ekstrand</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - [cfl] GPU hang when running UE4Editor"
href="https://bugs.freedesktop.org/show_bug.cgi?id=110228">bug 110228</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;">CC</td>
<td>
</td>
<td>caio.oliveira@intel.com, kenneth@whitecape.org
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [cfl] GPU hang when running UE4Editor"
href="https://bugs.freedesktop.org/show_bug.cgi?id=110228#c27">Comment # 27</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [cfl] GPU hang when running UE4Editor"
href="https://bugs.freedesktop.org/show_bug.cgi?id=110228">bug 110228</a>
from <span class="vcard"><a class="email" href="mailto:jason@jlekstrand.net" title="Jason Ekstrand <jason@jlekstrand.net>"> <span class="fn">Jason Ekstrand</span></a>
</span></b>
<pre>First off, thanks for all your digging and I'm sorry I've not gotten back to
this yet.
I have a feeling I know what's going wrong here and I really don't like it.
When I've played with this before, I've observed that the hangs go away when I
disable L3 caching on those buffers via MOCS settings or changing the L3$
programming to disable the data cache. What I suspect is happening is that the
same cache line is getting pulled in to the sampler portion of the L3$ and into
the data cach portion of the L3$ at the same time and something about the
atomic is causing the cache to blow up and the chip to hang.
Your first reaction to this might be to say, "aren't cache lines usually 64B?"
Yes, that's the usual size or at least in the right area. However, our HW docs
expressly say that the sampler sometimes fetches more cache lines than you'd
naively think it needs. Also (and I am speculating a bit here), the cache
might be doing some speculative pre-fetching that reads outside of the normal
boundaries. I'm not sure if the two of those is enough to read 576B outside
but the evidence suggests maybe it does.
So how do we work around the issue? Good question. Unfortunately, because of
the way that buffer views work in Vulkan, we can't just force them to space
their buffers out. It's possible that we may be able to work around this in
the shader by doing some sort of barrier between the texture operation and the
atomic to ensure that, at the very least, the two aren't in-flight at the same
time.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>