<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 9, 2017 at 6:23 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">Quoting Jason Ekstrand (2017-08-10 02:02:43)<br>
<span class="">> On Wed, Aug 9, 2017 at 12:03 PM, Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> wrote:<br>
><br>
>     To further facilitate GEM testing, allow testing of drm_syncobj by<br>
>     attaching them to vgem fences. These fences are already employed by igt<br>
>     for testing inter-driver fence handling (across dmabuf and sync_file).<br>
><br>
>     An igt example use would be like:<br>
><br>
>        int vgem = drm_driver_open(DRIVER_VGEM);<br>
>        uint32_t handle = vgem_create_dummy(vgem);<br>
><br>
><br>
> This is a bit nasty... Why do we need a BO?  Why can't we just create and<br>
> attach a fence without the BO?<br>
<br>
</span>Attach a fence to what? vgem is a wrapper around memory with the fences<br>
for coordinating exclusive/shared access to that memory. If you remove<br>
that memory, you remove the only functionality vgem has.<br>
<br>
You would be left with just some fences each on their own abstract<br>
timeline. At that point, you might as well use sw_sync, at least that<br>
exports a notion of a timeline (which may or may not be useful).<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Then maybe sw_sync is a better tool for testing syncobj.  I had one version of my i-g-t patches which used it and it worked out quite well.  Maybe I should just go back to that. <br></div></div><br></div></div>