On Mon, Mar 16, 2020 at 3:44 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> 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 > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
