RE: [PATCH v2 8/8] virtio-gpu: Add gl_flushed callback

["Kasireddy, Vivek" <vivek.kasireddy@intel.com>]

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