Hi,
> - 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.
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.
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).
take care,
Gerd
