Hi Gerd, > > > - if (!cmd->finished) { > > + if (!cmd->finished && !(cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_FENCE)) { > > virtio_gpu_ctrl_response_nodata(g, cmd, cmd->error ? cmd->error : > > VIRTIO_GPU_RESP_OK_NODATA); > > } > > My idea would be more along the lines of ... > > if (!cmd->finished) { > if (renderer_blocked) { > g->pending_completion = cmd; > } else { > virtio_gpu_ctrl_response_nodata(...) > } > } > > Then, when resuming processing after unblock check pending_completion > and call virtio_gpu_ctrl_response_nodata if needed. > > Workflow: > > virtio_gpu_simple_process_cmd() > -> virtio_gpu_resource_flush() > -> dpy_gfx_update() > -> gd_gl_area_update() > call graphic_hw_gl_block(true), create fence. [Kasireddy, Vivek] So, with blobs, as you know we call dpy_gl_update() and this call just "queues" the render/redraw. And, GTK then later calls the render signal callback which in this case would be gd_gl_area_draw() which is where the actual Blit happens and also glFlush; only after which we can create a fence.
> virtio_gpu_simple_process_cmd() > -> will see renderer_blocked and delays RESOURCE_FLUSH completion. > > Then, when the fence is ready, gtk will: > - call graphic_hw_gl_block(false) > - call graphic_hw_gl_flush() > -> virtio-gpu resumes processing the cmd queue. [Kasireddy, Vivek] Yeah, I think this can be done. > > When you use the existing block/unblock functionality the fence can be a > gtk internal detail, virtio-gpu doesn't need to know that gtk uses a > fence to wait for the moment when it can unblock virtio queue processing > (the egl fence helpers still make sense). [Kasireddy, Vivek] Ok, I'll try to include your suggestions in v3. Thanks, Vivek > > take care, > Gerd