[RFC PATCH 0/8] *** Per context fencing ***

[Chia-I Wu]

On Mon, Mar 16, 2020 at 3:44 PM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
> > >> At virtio level it is pretty simple:  The host completes the SUBMIT_3D
> > >> virtio command when it finished rendering, period.
> > >>
> > >>
> > >> On the guest side we don't need the fence_id.  The completion callback
> > >> gets passed the virtio_gpu_vbuffer, so it can figure which command did
> > >> actually complete without looking at virtio_gpu_ctrl_hdr->fence_id.
> > >>
> > >> On the host side we depend on the fence_id right now, but only because
> > >> that is the way the virgl_renderer_callbacks->write_fence interface is
> > >> designed.  We have to change that anyway for per-context (or whatever)
> > >> fences, so it should not be a problem to drop the fence_id dependency
> > >> too and just pass around an opaque pointer instead.
> >
> > I am still catching up, but IIUC, indeed I don't think the host needs
> > to depend on fence_id.  We should be able to repurpose fence_id.
>
> I'd rather ignore it altogether for FENCE_V2 (or whatever we call the
> feature flag).

That's fine when one assumes each virtqueue has one host GPU timeline.
But when there are multiple (e.g., multiplexing multiple contexts over
one virtqueue, or multiple VkQueues), fence_id can be repurposed as
the host timeline id.

>
> > On the other hand, the VIRTIO_GPU_FLAG_FENCE flag is interesting, and
> > it indicates that the vbuf is on the host GPU timeline instead of the
> > host CPU timeline.
>
> Yep, we have to keep that (unless we do command completion on GPU
> timeline unconditionally with FENCE_V2).

I think it will be useful when EXECBUFFER is used for metadata query
and write the metadata directly to a guest BO's sg list.  We want the
query to be on the CPU timeline.




> cheers,
>   Gerd
>