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: [RFC v1 2/4] virtio-gpu uapi: Add VIRTIO_GPU_F_OUT_FENCE feature
Date: Thu, 29 Jul 2021 18:53:44 +0000	[thread overview]
Message-ID: <6ffb3ea1b5e94af1af04b3c133c7e45f@intel.com> (raw)
In-Reply-To: <20210729095033.js2i6bjk27itcvhg@sirius.home.kraxel.org>

Hi Gerd,

> 
> On Thu, Jul 29, 2021 at 01:16:57AM -0700, Vivek Kasireddy wrote:
> > This feature enables the Guest to wait to know when a resource
> > is completely consumed by the Host.
> 
> virtio spec update?
> 
> What are the exact semantics?
[Kasireddy, Vivek] As of now, this is still a RFC version. If everyone (Weston
Upstream, drm upstream and you) agree that this is a reasonable way to
solve https://gitlab.freedesktop.org/wayland/weston/-/issues/514 then I'd go 
ahead and send out the spec updates and cleaner versions of these patches --
with more documentation.

> 
> Why a new command?  Can't you simply fence one of the commands sent
> anyway (set_scanout probably for page-flip updates)?
[Kasireddy, Vivek] Yes, I think I could add a fence (and an out_fence) to set-scanout-blob. 

> 
> (feature flag is probably needed even in case we don't need a new
> command to make sure the host sends the completion when processing
> the command is actually done, i.e. in case of qemu the recently added
> fence support is there).
[Kasireddy, Vivek] The recently added fence support was for resource_flush and
specifically for GTK-UI or similar backends. I tried using the same mechanism for
Wayland-UI backend but ran into the above Weston issue. This feature (OUT_FENCE)
is a potential solution for this issue.

Thanks,
Vivek
> 
> take care,
>   Gerd


  reply	other threads:[~2021-07-29 18:53 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29  8:16 [RFC v1 0/4] drm: Add support for DRM_CAP_DEFERRED_OUT_FENCE capability Vivek Kasireddy
2021-07-29  8:16 ` [RFC v1 1/4] drm: Add a capability flag to support deferred out_fence signalling Vivek Kasireddy
2021-07-29  8:16 ` [RFC v1 2/4] virtio-gpu uapi: Add VIRTIO_GPU_F_OUT_FENCE feature Vivek Kasireddy
2021-07-29  9:50   ` Gerd Hoffmann
2021-07-29 18:53     ` Kasireddy, Vivek [this message]
2021-07-29  8:16 ` [RFC v1 3/4] drm/virtio: Add VIRTIO_GPU_CMD_RESOURCE_OUT_FENCE cmd Vivek Kasireddy
2021-07-29  8:16 ` [RFC v1 4/4] drm/virtio: Probe and implement VIRTIO_GPU_F_OUT_FENCE feature Vivek Kasireddy
2021-07-29  9:52   ` Gerd Hoffmann
2021-07-29 18:55     ` Kasireddy, Vivek
2021-07-30 10:25 ` [RFC v1 0/4] drm: Add support for DRM_CAP_DEFERRED_OUT_FENCE capability Daniel Vetter
2021-07-30 12:50   ` Michel Dänzer
2021-08-02  7:59     ` Daniel Vetter
2021-08-02  8:49       ` Michel Dänzer
2021-08-02  9:06         ` Daniel Vetter
2021-08-02  9:19           ` Michel Dänzer
2021-07-30 13:38   ` Gerd Hoffmann
2021-08-02  9:09     ` Daniel Vetter
2021-08-02 12:50       ` Gerd Hoffmann
2021-08-02 14:35         ` Daniel Vetter
2021-08-03  6:18         ` Kasireddy, Vivek
2021-08-03  7:51           ` Gerd Hoffmann
2021-08-04  7:27             ` Kasireddy, Vivek
2021-08-02  4:48   ` Zhang, Tina
2021-08-02  6:51   ` Kasireddy, Vivek
2021-08-02  8:14     ` Daniel Vetter
2021-08-03  6:11       ` Kasireddy, Vivek
2021-08-03  7:33         ` Michel Dänzer
2021-08-04  7:25           ` Kasireddy, Vivek
2021-08-04 12:11           ` Daniel Vetter
2021-08-05  4:15             ` Kasireddy, Vivek
2021-08-05 12:08               ` Daniel Vetter
2021-08-06  7:27                 ` Kasireddy, Vivek
2021-08-09 14:15                   ` Daniel Vetter
2021-08-10  8:21                     ` Kasireddy, Vivek
2021-08-10  8:30                       ` Daniel Vetter
2021-08-10 10:57                         ` Michel Dänzer
2021-08-11  7:25                           ` Kasireddy, Vivek
2021-08-11  7:20                         ` 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=6ffb3ea1b5e94af1af04b3c133c7e45f@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.