Hi Gerd,
If support for Blob resources is available, then dumb BOs created by the driver can be considered as guest Blobs. And, for guest Blobs, there is no need to do any transfers or flushes
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?
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:
"The driver MUST inform the device if the blob resource is used for memory access, sharing between driver instances and/or sharing with other devices. This is done via the \field{blob_flags} field."
And, what should be the default blob_flags value for a dumb bo if the userspace does not specify them?
flush commands are still needed for dirty tracking.
but we do need to do set_scanout even if the FB has not changed as part of plane updates.
Sounds like you workaround host bugs. This should not be needed with properly implemented flush.
[Kasireddy, Vivek] With the patches I tested with: https://lists.nongnu.org/archive/html/qemu-devel/2021-03/msg09786.html
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) which can only happen if we call set_scanout_blob. IIUC, flush only marks the area as dirty but does not re-submit the updated buffer/blob and I see a flicker if I let it do dpy_gfx_update().
Thanks, Vivek
take care, Gerd