> If virgl=true (which means blob=false at the moment), then things work > very differently. Yes, we're using virglrenderer. The flushed resources are backed by host allocated buffers. We tried posting the flushed resource directly to the display and replied to the flush immediately (since not fenced), but I see artifacts - I assume the guest is reusing the resource as its being posted. So now I'm doing a gpu-blit from the flushed resource into a separate set of backbuffers for display. The blit is done in another thread and I have it synchronized so that a second flush can't return until the first flush's resource has been copied, making it safe for the guest to reuse. This is working ok with a double buffered guest compositor, but its not ideal as it can still hold up processing the virtio controlq. I really need these flushes to be fenced so I can defer their response... So in my case, what's the best way to handle the flush? In case its relevant, at the moment I'm supporting an older virglrenderer that doesn't make use of the virtio-v1.2 VIRTIO_GPU_F_RESOURCE_BLOB or VIRTIO_GPU_F_CONTEXT_INIT features. Thanks, Josh
