https://bugs.dolphin-emu.org/https://bugs.dolphin-emu.org/favicon.ico?12018-02-22T03:58:21ZDolphin bug trackerEmulator - Emulator Issues #10904: Mesa/radeonsi hangs during glClientWaitSync()https://bugs.dolphin-emu.org/issues/10904?journal_id=7322352018-02-22T03:58:21ZStenzekstenzek@gmail.com
<ul><li><strong>Subject</strong> changed from <i>StreamBuffer is a disaster!</i> to <i>Mesa/radeonsi hangs during glClientWaitSync()</i></li><li><strong>Status</strong> changed from <i>New</i> to <i>Accepted</i></li><li><strong>Operating system</strong> <i>Linux</i> added</li><li><strong>Operating system</strong> deleted (<del><i>N/A</i></del>)</li></ul><p>Thank you for the detailed investigation and write-up.</p>
<p>I can investigate the fence leaking situation when I get a chance, however, I think the underlying issue here is a bug in the radeonsi driver. I also found Dolphin was hanging in client_wait_sync when reading back staging textures in <a href="https://github.com/dolphin-emu/dolphin/pull/6367" class="external">https://github.com/dolphin-emu/dolphin/pull/6367</a></p>
<p>Funnily enough, doing an explicit glFlush() here fixes the problem too. But obviously this will have a performance cost, so it's not something we want to be doing all the time, particularly during sub-buffer allocations. Looking into the driver source, for glClientWaitSync(), the GL_SYNC_FLUSH_COMMANDS_BIT flag is completely ignored, the driver flushes unconditionally here. But there appears to be a difference between the flush which happens in glClientWaitSync() vs glFlush(). I didn't end up investigating it any further, as the early flush can potentially hand us performance benefits when the access does not immediately follow the flush.</p>
<p>All that said, radv works quite well with Dolphin, so that's always an option in the meantime.</p>
Emulator - Emulator Issues #10904: Mesa/radeonsi hangs during glClientWaitSync()https://bugs.dolphin-emu.org/issues/10904?journal_id=7322362018-02-22T14:59:38Zdark_sylinc
<ul></ul><p>Yes! Your glFlush in the staging textures is what prompted me to do the same. My thoughts were "well... that doesn't make sense. The flush bit should do the same as glFlush so why is Dolphin here.... unless they found the same bug and I'm looking at a workaround".</p>
<p>Regarding your performance concerns:</p>
<p>glFlush isn't veeeeeeeeeery expensive because it just tells the driver to send everything it has queued to the GPU. Flushing excessively can cause threading synchronization overhead, prevent the driver from optimizing a batch by analyzing all the commands (I seriously doubt Mesa does this sort of thing, and other drivers seem to be moving away from doing this) and maybe some HW excessive synchronization too (e.g. PCIE sync packet overhead, kernel transitions etc).</p>
<p>But it's not thaaaaat expensive. Furthermore:</p>
<ol>
<li>glClientSync is supposed to flush already (in fact Mesa's source code says they ignore the flush flag and always assume it's set because many apps forget to set it).</li>
<li>The glFlush is only when the buffer is full</li>
<li>At least with Tales of Symphonia DotNW, when I was printf debugging, I saw that the buffer gets full like 3 times per second (time measure is eyeballed)</li>
<li>If you're that seriously concerned, you'll gain <em>a lot more</em> performance by only calling glClientWaitSync on the last fence you need to delete. Right now you're calling glClientWaitSync on each one of them, sequentially.</li>
</ol>
<p>Stenzek wrote:</p>
<blockquote>
<p>All that said, radv works quite well with Dolphin, so that's always an option in the meantime.</p>
</blockquote>
<p>Thanks! Last time I checked 6 months ago, radv would freeze my system quickly enough. But 6 months is eons ago for that driver.</p>
<p>Anyway, I'm already playing with my custom build. About 1 hour of gameplay and no hangs yet; unless having to disable the bloody screensaver because I'm not touching the keyboard or mouse counts as a bug :)</p>
Emulator - Emulator Issues #10904: Mesa/radeonsi hangs during glClientWaitSync()https://bugs.dolphin-emu.org/issues/10904?journal_id=7322412018-02-23T00:56:03ZStenzekstenzek@gmail.com
<ul></ul><blockquote>
<p>glFlush isn't veeeeeeeeeery expensive because it just tells the driver to send everything it has queued to the GPU. Flushing excessively can cause threading synchronization overhead, prevent the driver from optimizing a batch by analyzing all the commands (I seriously doubt Mesa does this sort of thing, and other drivers seem to be moving away from doing this) and maybe some HW excessive synchronization too (e.g. PCIE sync packet overhead, kernel transitions etc).</p>
</blockquote>
<p>Yep. That's the only reason I even considered it as a workaround for staging textures, as the CPU readback is a slow path anyway.</p>
<blockquote>
<p>glClientSync is supposed to flush already (in fact Mesa's source code says they ignore the flush flag and always assume it's set because many apps forget to set it).<br>
That was my conclusion as well. But something does not appear to be working correctly here. I found the hang was deterministic in that it happened at the same point after booting each time, but didn't narrow down the exact state where it happens.</p>
<p>At least with Tales of Symphonia DotNW, when I was printf debugging, I saw that the buffer gets full like 3 times per second (time measure is eyeballed)</p>
</blockquote>
<p>Three times per second is fine when we're pushing 30/60 frames per second. It only becomes an issue if we have to flush and sync on the same frame that the sub-buffer is used, as otherwise the implicit flush on swap takes care of it.</p>
<p>However, our vertex streaming code currently has some disadvantages. We require the full "maximum batch size" to be reserved at the beginning of every batch, even though almost all of the time, not all this storage is committed. IIRC we set the buffer to 2*maxsize. So as soon as we use half the buffer, we can no longer reserve maxsize, therefore wrapping around early and syncing. I've been wanting to address this for a while now, but been busy with other things.</p>
<blockquote>
<p>If you're that seriously concerned, you'll gain <em>a lot more</em> performance by only calling glClientWaitSync on the last fence you need to delete. Right now you're calling glClientWaitSync on each one of them, sequentially.</p>
</blockquote>
<p>Yep, this is a potential optimization. However, it depends on how the driver implements syncs, a "best case" here would simply return immediately as the intermediate sync objects have already been signaled.</p>
Emulator - Emulator Issues #10904: Mesa/radeonsi hangs during glClientWaitSync()https://bugs.dolphin-emu.org/issues/10904?journal_id=7322422018-02-23T06:04:39ZLithium64
<ul></ul><p>I can reproduce the issue, but it only happens with 18.1.0-devel here.</p>
<p>My specs are:</p>
<p>i3 4150 @ 3.50ghz<br>
DDR3 12GB RAM<br>
AMD R7 260X 2GB VRAM<br>
Ubuntu 17.10<br>
Kernel 4.15.4<br>
Mesa 18.1.0-devel</p>
Emulator - Emulator Issues #10904: Mesa/radeonsi hangs during glClientWaitSync()https://bugs.dolphin-emu.org/issues/10904?journal_id=7323192018-03-05T01:11:38Zdark_sylinc
<ul></ul><p>I've been able to reproduce this bug in one of my samples (completely unrelated to Dolphin) which confirms this is a Mesa bug.</p>
<p>I've reported the bug to Mesa <a href="https://bugs.freedesktop.org/show_bug.cgi?id=105339" class="external">https://bugs.freedesktop.org/show_bug.cgi?id=105339</a> and sent them a repro sample. While it's not a trivial sample, it's far simpler than Dolphin.</p>
Emulator - Emulator Issues #10904: Mesa/radeonsi hangs during glClientWaitSync()https://bugs.dolphin-emu.org/issues/10904?journal_id=7405812020-10-19T18:04:53ZBilliard26jordan.woyak@gmail.com
<ul><li><strong>Status</strong> changed from <i>Accepted</i> to <i>Fixed</i></li></ul><p>The above linked Mesa issue is marked as fixed.<br>
Will re-open upon request.</p>