On Wed, Aug 9, 2017 at 6:23 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
Quoting Jason Ekstrand (2017-08-10 02:02:43)
> On Wed, Aug 9, 2017 at 12:03 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
