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

[Gerd Hoffmann]

On Mon, Mar 09, 2020 at 06:08:10PM -0700, Gurchetan Singh wrote:
> We don't want fences from different 3D contexts/processes (GL, VK) to
> be on the same timeline. Sending this out as a RFC to solicit feedback
> on the general approach.

NACK.

virtio fences are global, period.  You can't simply change fence
semantics like this.  At least not without a virtio protocol update
because guest and host need to be on the same page here.  Just look at
virgl_renderer_callbacks->write_fences() and how it doesn't consider
contexts at all.

So one way out would be to add a virtio feature flag for this, so guest
& host can negotiate whenever fences are global or per-context.

Another approach would be to go multiqueue, with each virtqueue being
roughly the same as a rendering pipeline on physical hardware, then have
per-virtqueue fences.

When going multiqueue we might also rethink the cursor queue approach.
I think it makes sense to simply allow sending cursor commands to any
queue then.  A separate cursor queue continues to be an option for the
guest then, but I'm not sure how useful that actually is in practice
given that cursor image updates are regular resource updates and have to
go through the control queue, so virtio_gpu_cursor_plane_update() has to
wait for the resource update finish before it can queue the cursor
command.  I suspect the idea to fast-track cursor updates with a
separate queue doesn't work that well in practice because of that.

cheers,
  Gerd