[Intel-gfx] [PATCH] drm/vgem: Couple in drm_syncobj support
Jason Ekstrand
jason at jlekstrand.net
Thu Aug 10 01:35:11 UTC 2017
On Wed, Aug 9, 2017 at 6:23 PM, Chris Wilson <chris at 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 <chris at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20170809/09879336/attachment.html>
More information about the Intel-gfx
mailing list