On Wed, Aug 9, 2017 at 6:23 PM, Chris Wilson <ch...@chris-wilson.co.uk>
wrote:

> Quoting Jason Ekstrand (2017-08-10 02:02:43)
> > On Wed, Aug 9, 2017 at 12:03 PM, Chris Wilson <ch...@chris-wilson.co.uk>
> wrote:
> >
> >     To further facilitate GEM testing, allow testing of drm_syncobj by
> >     attaching them to vgem fences. These fences are already employed by
> igt
> >     for testing inter-driver fence handling (across dmabuf and
> sync_file).
> >
> >     An igt example use would be like:
> >
> >        int vgem = drm_driver_open(DRIVER_VGEM);
> >        uint32_t handle = vgem_create_dummy(vgem);
> >
> >
> > This is a bit nasty... Why do we need a BO?  Why can't we just create and
> > attach a fence without the BO?
>
> Attach a fence to what? vgem is a wrapper around memory with the fences
> for coordinating exclusive/shared access to that memory. If you remove
> that memory, you remove the only functionality vgem has.
>
> You would be left with just some fences each on their own abstract
> timeline. At that point, you might as well use sw_sync, at least that
> exports a notion of a timeline (which may or may not be useful).
>

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.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to