<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 28, 2017 at 3:04 PM, Chris Wilson <span dir="ltr"><<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Feb 28, 2017 at 08:56:45AM -0800, Jason Ekstrand wrote:<br>
</span><span class="">> +   if (handleTypes == 0) {<br>
> +      /* The DRM execbuffer ioctl always execute in-oder, even between<br>
> +       * different rings. As such, a dummy no-op semaphore is a perfectly<br>
> +       * valid implementation.<br>
<br>
</span>That's not quite true. Each engine is its own timeline within the context.<br>
Every execbuf on a particular ring is executed in submission order.<br>
Between rings, order is based on dependencies - batches that only share<br>
read access to the same buffers (or nothing shared) will be executed in<br>
parallel, but any writes impose a strong ordering between the engines.<br>
(That being the basis of TYPE_BO.)<br>
<br>
I don't think it affects anv since there is only a single render queue,<br>
but I think the explanation of TYPE_DUMMY needs a little more fleshing<br>
out to avoid leaving a trap behind.<br></blockquote><div><br></div><div>You're correct.  Thanks for pointing that out.  I'll fix the comment to not say stupid things about different rings.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888">-Chris<br>
</font></span><span class="im HOEnZb"><br>
> +       */<br>
> +      semaphore->permanent.type = ANV_SEMAPHORE_TYPE_DUMMY;<br>
<br>
</span><div class="HOEnZb"><div class="h5">--<br>
Chris Wilson, Intel Open Source Technology Centre<br>
</div></div></blockquote></div><br></div></div>