<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 12, 2017 at 9:45 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">
    <div class="m_9095598565780015075moz-cite-prefix">Am 12.07.2017 um 17:53 schrieb Jason
      Ekstrand:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">[SNIP]<span class=""><br>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
              </span>Is that easier than just waiting in the kernel, I'm
              not sure how<br>
              optimised we need this path to be.<span class="m_9095598565780015075HOEnZb"><font color="#888888"><br>
                </font></span></blockquote>
          </span></div>
          <br>
        </div><span class="">
        <div class="gmail_extra">I don't think so.  I think it's
          more-or-less the same code regardless of how it's done.  The
          advantage of doing it in the kernel is that it's standardized
          (we don't have to both go write that userspace code) and it
          doesn't have the problems stated above.<br>
        </div>
      </span></div>
    </blockquote>
    <br>
    Ok, I'm convinced. The next price question is then how do we do it?<br>
    <br>
    I mean writing an IOCTL to wait for a fence to appear is simple, but
    do we also need to wait for a fence to change?<span class="HOEnZb"><font color="#888888"><br>
  </font></span></div>

</blockquote></div><br></div><div class="gmail_extra">I don't think so.  Taking a page from the Vulkan book, I think the "right" thing to do would be to have a reset ioctl that simply deletes the dma_fence and replaces it with NULL.  Then the only behavior you care about is "wait for a fence to appear".  The usage pattern becomes:<br><br></div><div class="gmail_extra"> 1) Submit work to signal the syncobj<br></div><div class="gmail_extra"> 2) Wait on the syncobj (this may happen before the submit)<br></div><div class="gmail_extra"> 3) Once everyone is done waiting, reset the syncobj<br><br></div><div class="gmail_extra">If someone does a wait on a stale syncobj that has completed and not yet been reset, they return immediately.  Yes, there is a possible race between 2 and 3, especially if 2 is waiting on multiple syncobjs.  Ideally, we'd make it so that a reset in the middle of someone else's wait wouldn't cause them to wait until that syncobj gets triggerd a second time.  However, I don't think it's a deal-breaker as any client that sets the "wait for submit" flag should know that it's liable to wait forever and set a timeout.<br></div></div>