From: Gerd Hoffmann <kraxel@redhat.com>
To: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/virtio: Create Dumb BOs as guest Blobs
Date: Thu, 1 Apr 2021 08:53:24 +0200 [thread overview]
Message-ID: <20210401065324.vb44nfodohcgrdex@sirius.home.kraxel.org> (raw)
In-Reply-To: <db7373214e15407fa0203cf10dc996e7@intel.com>
Hi,
> > No. VIRTGPU_BLOB_FLAG_USE_SHAREABLE means the host (aka device in virtio
> > terms) *can* create a shared mapping. So, the guest sends still needs to send transfer
> > commands, and then the device can shortcut the transfer commands on the host side in
> > case a shared mapping exists.
> [Kasireddy, Vivek] Ok. IIUC, are you saying that the device may or may not create a shared
> mapping (meaning res->image) and that the driver should not make any assumptions about
> that and thus still do the transfers and flushes?
Yes.
> Also, could you please briefly explain what does
> VIRTIO_GPU_BLOB_FLAG_USE_MAPPABLE mean given that the spec does not
> describe these blob_flags clearly? This is what the spec says:
This matters for VIRTIO_GPU_BLOB_MEM_HOST3D resources only.
VIRTIO_GPU_BLOB_FLAG_USE_MAPPABLE indicates the guest wants map the
resource for cpu access. When the flag is not set only gpu access is
needed.
> And, what should be the default blob_flags value for a dumb bo if the
> userspace does not specify them?
Just VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE is fine for
VIRTIO_GPU_BLOB_MEM_GUEST.
> [Kasireddy, Vivek] With the patches I tested with:
> https://lists.nongnu.org/archive/html/qemu-devel/2021-03/msg09786.html
Saw the series, not looked in detail yet.
> I noticed that if we do not have res->image and only have res->blob, we have to
> re-submit the blob/dmabuf and update the displaysurface if guest made updates to it
> (in this case same FB)
flush must call dpy_gfx_update() or dpy_gl_update().
Oh, and make sure you use qemu master (or 6.0-rc). In 5.2 + older
display updates might not work properly due to a missing glFlush()
in qemu.
take care,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-04-01 6:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-31 3:04 [PATCH 1/2] drm/virtio: Create Dumb BOs as guest Blobs Vivek Kasireddy
2021-03-31 3:04 ` [PATCH 2/2] drm/virtio: Include modifier as part of set_scanout_blob Vivek Kasireddy
2021-03-31 7:59 ` Gerd Hoffmann
2021-04-02 7:55 ` Zhang, Tina
2021-04-02 16:07 ` Gurchetan Singh
2021-03-31 7:41 ` [PATCH 1/2] drm/virtio: Create Dumb BOs as guest Blobs Gerd Hoffmann
2021-04-01 3:51 ` Kasireddy, Vivek
2021-04-01 6:53 ` Gerd Hoffmann [this message]
2021-04-06 20:36 ` [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v2) Vivek Kasireddy
2021-04-07 0:34 ` Gurchetan Singh
2021-04-08 9:27 ` Gerd Hoffmann
2021-04-09 0:31 ` Gurchetan Singh
2021-04-09 7:48 ` Gerd Hoffmann
2021-04-13 0:58 ` Gurchetan Singh
[not found] ` <BN7PR11MB2786499E7902CE53326ACE97894F9@BN7PR11MB2786.namprd11.prod.outlook.com>
2021-04-13 4:57 ` Zhang, Tina
2021-04-13 5:26 ` [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v3) Vivek Kasireddy
2021-04-14 6:36 ` Zhang, Tina
2021-04-14 9:29 ` Gerd Hoffmann
2021-04-14 23:31 ` Gurchetan Singh
2021-04-15 9:07 ` Gerd Hoffmann
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=20210401065324.vb44nfodohcgrdex@sirius.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=vivek.kasireddy@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).