On Wed, Aug 9, 2017 at 6:23 PM, Chris Wilson <ch...@chris-wilson.co.uk>
> 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>
> > To further facilitate GEM testing, allow testing of drm_syncobj by
> > attaching them to vgem fences. These fences are already employed by
> > for testing inter-driver fence handling (across dmabuf and
> > 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