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