<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 26, 2017 at 7:57 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 class="m_7196519087789463477HOEnZb"><div class="m_7196519087789463477h5">Am 26.04.2017 um 11:57 schrieb Dave Airlie:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 26 April 2017 at 18:45, Christian König <<a href="mailto:deathsimple@vodafone.de" target="_blank">deathsimple@vodafone.de</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 26.04.2017 um 05:28 schrieb Dave Airlie:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Okay I've gone around the sun with these a few times, and<br>
pretty much implemented what I said last week.<br>
<br>
This is pretty much a complete revamp.<br>
<br>
1. sync objects are self contained drm objects, they<br>
have a file reference so can be passed between processes.<br>
<br>
2. Added a sync object wait interface modelled on the vulkan<br>
fence waiting API.<br>
<br>
3. sync_file interaction is explicitly different than<br>
opaque fd passing, you import a sync file state into an<br>
existing syncobj, or create a new sync_file from an<br>
existing syncobj. This means no touching the sync file code<br>
at all. \o/<br>
</blockquote></blockquote></blockquote></div></div></blockquote><div><br></div><div>I've done a quick scan over the patches and I like the API.  It almost looks as if Santa read my wish list. :-)<br><br></div><div>That said, it was a "quick scan" so don't take this as any sort of actual code review.  It'll probably be a little while before I get a chance to sit down and look at i915 again but things seem reasonable.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_7196519087789463477HOEnZb"><div class="m_7196519087789463477h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Doesn't that break the Vulkan requirement that if a sync_obj is exported to<br>
an fd and imported on the other side we get the same sync_obj again?<br>
<br>
In other words the fd is exported and imported only once and the expectation<br>
is that we fence containing it will change on each signaling operation.<br>
<br>
As far as I can see with the current implementation you get two sync_objects<br>
on in the exporting process and one in the importing one.<br>
</blockquote>
Are you talking about using sync_file interop for vulkan, then yes<br>
that would be wrong.<br>
<br>
But that isn't how this works, see 1. above the sync obj has a 1:1<br>
mapping with an<br>
opaque fd (non-sync_file) that is only used for interprocess passing<br>
of the syncobj.<br>
</blockquote>
<br></div></div>
Ah, ok that makes some more sense.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You can interoperate with sync_files by importing/exporting the<br>
syncobj fence into<br>
and out of them but that aren't meant for passing the fds around, more<br>
for where you<br>
get a sync_file fd from somewhere else and you want to use it and vice-versa.<br>
</blockquote>
<br></span>
I would prefer dealing only with one type of fd in userspace, but that approach should work as well.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd like to move any drm APIs away from sync_file to avoid the fd wastages,<br>
</blockquote>
<br></span>
That sounds like it make sense, but I would still rather vote for extending the sync_file interface than deprecating it with another one.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd also like to move the driver specific fences to syncobj where I can.<br>
</blockquote>
<br></span>
I'm pretty sure that is not a good idea.<br>
<br>
Beating the sequence based fence values we currently use for CPU sync in performance would be pretty hard. E.g. at least on amdgpu we can even check those by doing a simple 64bit read from a memory address, without IOCTL or any other overhead involved.<br>
<br>
Regards,<br>
Christian.<div class="m_7196519087789463477HOEnZb"><div class="m_7196519087789463477h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Dave.<br>
</blockquote>
<br>
<br>
______________________________<wbr>_________________<br>
dri-devel mailing list<br>
<a href="mailto:dri-devel@lists.freedesktop.org" target="_blank">dri-devel@lists.freedesktop.or<wbr>g</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/dri-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/dri-devel</a><br>
</div></div></blockquote></div><br></div></div>