<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 10, 2017 at 9:15 AM, Christian König <span dir="ltr"><<a href="mailto:deathsimple@vodafone.de" target="_blank">deathsimple@vodafone.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div class="m_-3527794384181374639moz-cite-prefix">Am 10.07.2017 um 17:52 schrieb Jason
Ekstrand:<br>
</div>
</span><blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span class="">On Mon, Jul 10, 2017 at 8:45 AM,
Christian König <span dir="ltr"><<a href="mailto:deathsimple@vodafone.de" target="_blank">deathsimple@vodafone.de</a>></span>
wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div>
<div class="m_-3527794384181374639gmail-h5"><span class="">
<div class="m_-3527794384181374639gmail-m_-226855681158848481moz-cite-prefix">Am
10.07.2017 um 17:28 schrieb Jason Ekstrand:<br>
</div>
</span><blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span class="">On Wed, Jul 5, 2017
at 6:04 PM, Dave Airlie <span dir="ltr"><<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.com</a>></span>
wrote:<br></span>
[SNIP]<span class=""><br>
<div>So, reading some CTS tests again, and I
think we have a problem here. The Vulkan
spec allows you to wait on a fence that is
in the unsignaled state.</div>
</span></div>
</div>
</div>
</blockquote>
<br>
</div>
</div><span class="">
At least on the closed source driver that would be
illegal as far as I know.<br>
</span></div>
</blockquote><span class="">
<div><br>
</div>
<div>Then they are doing workarounds in userspace. There
are definitely CTS tests for this:<br>
<br>
<a href="https://github.com/KhronosGroup/VK-GL-CTS/blob/master/external/vulkancts/modules/vulkan/synchronization/vktSynchronizationBasicFenceTests.cpp#L74" target="_blank">https://github.com/<wbr>KhronosGroup/VK-GL-CTS/blob/<wbr>master/external/vulkancts/<wbr>modules/vulkan/<wbr>synchronization/<wbr>vktSynchronizationBasicFenceTe<wbr>sts.cpp#L74</a><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> You can't wait on a semaphore before the signal
operation is send down to the kerel.</div>
</blockquote>
<div><br>
</div>
<div>We (Intel) deal with this today by tracking whether or
not the fence has been submitted and using a condition
variable in userspace to sort it all out.</div>
</span></div>
</div>
</div>
</blockquote>
<br>
Which sounds exactly like what AMD is doing in it's drivers as well.<span class=""><br></span></div></blockquote><div><br></div><div>Which doesn't work cross-process so... <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>If we ever want to share fences across processes (which
we do), then this needs to be sorted in the kernel. </div>
</div>
</div>
</div>
</blockquote>
<br></span>
That would clearly get a NAK from my side, even Microsoft forbids
wait before signal because you can easily end up in deadlock
situations.<br>
</div>
</blockquote></div><br></div><div class="gmail_extra">Please don't NAK things that are required by the API specification and CTS tests. That makes it very hard for people like me to get their jobs done. :-)<br><br></div><div class="gmail_extra">Now, as for whether or not it's a good idea. First off, we do have timeouts an a status querying mechanism so an application can just set a timeout of 1s and do something if it times out. Second, if the application is a compositor or something else that doesn't trust its client, it shouldn't be using the OPAQUE_FD mechanism of Vulkan semaphore/fence sharing anyway. For those scenarios, they can require the untrusted client to use FENCE_FD (sync file) and they have all of the usual guarantees about when the work got submitted, etc.<br><br></div><div class="gmail_extra">Also, I'm more than happy to put this all behind a flag so it's not the default behavior.<br><br></div><div class="gmail_extra">--Jason<br></div></div>