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