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