<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - radv: OpControlBarrier does not always work correctly (bisected)"
href="https://bugs.freedesktop.org/show_bug.cgi?id=107460">107460</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>radv: OpControlBarrier does not always work correctly (bisected)
</td>
</tr>
<tr>
<th>Product</th>
<td>Mesa
</td>
</tr>
<tr>
<th>Version</th>
<td>git
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Drivers/Vulkan/radeon
</td>
</tr>
<tr>
<th>Assignee</th>
<td>mesa-dev@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>philip.rebohle@tu-dortmund.de
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>mesa-dev@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=140941" name="attach_140941" title="Probably affected compute shader">attachment 140941</a> <a href="attachment.cgi?id=140941&action=edit" title="Probably affected compute shader">[details]</a></span>
Probably affected compute shader
Hello,
a regression that affects OpControlBarrier instructions in compute shaders
causes major rendering issues in Final Fantasy XV. The attached shader seems to
be the one running into this issue.
In short, DXVK translates sync_g_t instructions to the following:
OpControlBarrier Workgroup, Workgroup, WorkgroupMemory | AcquireRelease
This currently does not work as expected. Interestingly, inserting an
additional OpMemoryBarrier seems to fix the problem:
OpMemoryBarrier Workgroup, WorkgroupMemory | AcquireRelease
OpControlBarrier Workgroup, Workgroup, WorkgroupMemory | AcquireRelease
While this is closer to what glslang emits for equivalent GLSL barriers,
emitting the extra OpMemoryBarrier instruction should not be necessary
according to the SPIR-V spec for OpControlBarrier.
The commit which introduced the problem is:
[f2b3e96e754a5d722f2b0fa1bd5efa1c0640ed3b]
radv: drop copy of ac_create_target_machine.
Looking at the difference between the two implementations, there's the
following line in ac_create_target_machine:
bool barrier_does_waitcnt = family != CHIP_VEGA20;
Changing this to 'false' fixes the problem for me. My GPU is an RX 480 (Polaris
10).
Unfortunately it is quite hard to isolate the exact issue in the game, a
renderdoc capture was not useful because the bug got baked into it for some
reason, so here's a D3D11 apitrace that needs to be replayed with DXVK in order
to reproduce the bug.
<a href="https://drive.google.com/file/d/1ywMEhn-P68Sino1_5yBkceLcMACTtDAI/view?usp=sharing">https://drive.google.com/file/d/1ywMEhn-P68Sino1_5yBkceLcMACTtDAI/view?usp=sharing</a></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>