All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: RE: [PATCH 1/3] virtio-gpu uapi: Add VIRTIO_GPU_F_EXPLICIT_FLUSH feature
Date: Tue, 11 May 2021 20:53:31 +0000	[thread overview]
Message-ID: <8dc2bbd037964224bcc6609fd47b5698@intel.com> (raw)
In-Reply-To: <20210511102958.46ybk2q33vg4iayi@sirius.home.kraxel.org>

Hi Gerd,

> On Tue, May 11, 2021 at 01:36:08AM -0700, Vivek Kasireddy wrote:
> > This feature enables the Guest to wait until a flush has been
> > performed on a buffer it has submitted to the Host.
> 
> This needs a virtio-spec update documenting the new feature.
[Kasireddy, Vivek] Yes, I was planning to do that after getting your 
thoughts on this feature.

> 
> > +	VIRTIO_GPU_CMD_WAIT_FLUSH,
> 
> Why a new command?
> 
> If I understand it correctly you want wait until
> VIRTIO_GPU_CMD_RESOURCE_FLUSH is done.  We could
> extend the VIRTIO_GPU_CMD_RESOURCE_FLUSH command
> for that instead.
[Kasireddy, Vivek] VIRTIO_GPU_CMD_RESOURCE_FLUSH can trigger/queue a
redraw that may be performed synchronously or asynchronously depending on the
UI (Glarea is async and gtk-egl is sync but can be made async). I'd like to make the
Guest wait until the actual redraw happens (until GlFLush or eglSwapBuffers, again
depending on the UI). 

However, as part of this feature (explicit flush), I'd like to make the Guest wait until
the current resource (as specified by resource_flush or set_scanout) is flushed or
synchronized. But for a different feature I am thinking of (explicit sync), I'd like to
make the Guest wait for the previous buffer/resource submitted (available via 
old_state->fb).

I think it may be possible to accomplish both features by overloading resource_flush
but given the various combinations of Guests (Android/Chrome OS, Windows, Linux)
and Hosts (Android/Chrome OS, Linux) that are or will be supported with virtio-gpu +
i915, I figured adding a new command might be cleaner.

Thanks,
Vivek


> 
> take care,
>   Gerd


  reply	other threads:[~2021-05-11 20:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-11  8:36 [PATCH 1/3] virtio-gpu uapi: Add VIRTIO_GPU_F_EXPLICIT_FLUSH feature Vivek Kasireddy
2021-05-11  8:36 ` [PATCH 2/3] drm/virtio: Add VIRTIO_GPU_CMD_WAIT_FLUSH cmd Vivek Kasireddy
2021-05-11  8:36 ` [PATCH 3/3] drm/virtio: Probe and implement VIRTIO_GPU_F_EXPLICIT_FLUSH feature Vivek Kasireddy
2021-05-11 10:29 ` [PATCH 1/3] virtio-gpu uapi: Add " Gerd Hoffmann
2021-05-11 20:53   ` Kasireddy, Vivek [this message]
2021-05-12  6:44     ` Gerd Hoffmann
2021-05-12 21:18       ` Kasireddy, Vivek
2021-05-14 10:38         ` Gerd Hoffmann
2021-05-18  5:45           ` Kasireddy, Vivek
2021-05-24 19:55             ` Kasireddy, Vivek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8dc2bbd037964224bcc6609fd47b5698@intel.com \
    --to=vivek.kasireddy@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kraxel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.