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
