qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gerd Hoffmann
Subject: Re: [PATCH v2 8/8] virtio-gpu: Add gl_flushed callback
Date: Tue, 15 Jun 2021 07:50:26 +0200

  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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]