Hi, > > No. VIRTGPU_BLOB_FLAG_USE_SHAREABLE means the host (aka device in virtio > > terms) *can* create a shared mapping. So, the guest sends still needs to send transfer > > commands, and then the device can shortcut the transfer commands on the host side in > > case a shared mapping exists. > [Kasireddy, Vivek] Ok. IIUC, are you saying that the device may or may not create a shared > mapping (meaning res->image) and that the driver should not make any assumptions about > that and thus still do the transfers and flushes? Yes. > Also, could you please briefly explain what does > VIRTIO_GPU_BLOB_FLAG_USE_MAPPABLE mean given that the spec does not > describe these blob_flags clearly? This is what the spec says: This matters for VIRTIO_GPU_BLOB_MEM_HOST3D resources only. VIRTIO_GPU_BLOB_FLAG_USE_MAPPABLE indicates the guest wants map the resource for cpu access. When the flag is not set only gpu access is needed. > And, what should be the default blob_flags value for a dumb bo if the > userspace does not specify them? Just VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE is fine for VIRTIO_GPU_BLOB_MEM_GUEST. > [Kasireddy, Vivek] With the patches I tested with: > https://lists.nongnu.org/archive/html/qemu-devel/2021-03/msg09786.html Saw the series, not looked in detail yet. > I noticed that if we do not have res->image and only have res->blob, we have to > re-submit the blob/dmabuf and update the displaysurface if guest made updates to it > (in this case same FB) flush must call dpy_gfx_update() or dpy_gl_update(). Oh, and make sure you use qemu master (or 6.0-rc). In 5.2 + older display updates might not work properly due to a missing glFlush() in qemu. take care, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
