Thread (10 messages) 10 messages, 4 authors, 2021-03-15

RE: [RFC v3 2/3] virtio: Introduce Vdmabuf driver

From: Zhang, Tina <hidden>
Date: 2021-03-15 02:28:34
Also in: dri-devel, linux-media

-----Original Message-----
From: dri-devel <redacted> On Behalf Of Gerd
Hoffmann
Sent: Friday, February 12, 2021 7:02 PM
To: Kasireddy, Vivek <vivek.kasireddy@intel.com>
Cc: Kim, Dongwon <redacted>; christian.koenig@amd.com;
daniel.vetter@ffwll.ch; dri-devel@lists.freedesktop.org;
virtualization@lists.linux-foundation.org; Vetter, Daniel
[off-list ref]; linux-media@vger.kernel.org
Subject: Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver

On Fri, Feb 12, 2021 at 08:15:12AM +0000, Kasireddy, Vivek wrote:
quoted
Hi Gerd,
quoted
quoted
quoted
You don't have to use the rendering pipeline.  You can let the
i915 gpu render into a dma-buf shared with virtio-gpu, then use
virtio-gpu only for buffer sharing with the host.
[Kasireddy, Vivek] Just to confirm my understanding of what you are
suggesting, are you saying that we need to either have Weston allocate
scanout buffers (GBM surface/BO) using virtio-gpu and render into them
using i915; or have virtio-gpu allocate pages and export a dma-buf and
have Weston create a GBM BO by calling gbm_bo_import(fd) and render into
the BO using i915?

Not sure what the difference between the former and the latter is.
quoted
quoted
Hmm, why a big mode switch?  You should be able to do that without
modifying the virtio-gpu guest driver.  On the host side qemu needs
some work to support the most recent virtio-gpu features like the
buffer uuids (assuming you use qemu userspace), right now those are only
supported by crosvm.
quoted
[Kasireddy, Vivek] We are only interested in Qemu UI at the moment but
if we were to use virtio-gpu, we are going to need to add one more vq
and support for managing buffers, events, etc.
Should be easy and it should not need any virtio-gpu driver changes.

You can use virtio-gpu like a dumb scanout device.  Create a dumb bo, create a
framebuffer for the bo, map the framebuffer to the crtc.

Then export the bo, import into i915, use it as render target.  When rendering is
done flush (DRM_IOCTL_MODE_DIRTYFB).  Alternatively allocate multiple bo's +
framebuffers and pageflip.
Hi,

We've got a MR(https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9592) for this suggested implementation. Comments are welcome. Thanks.

BR,
Tina
Pretty standard workflow for cases where rendering and scanout are handled by
different devices.  As far I know not uncommon in the arm world.

Right now this will involve a memcpy() for any display update because qemu is a
bit behind on supporting recent virtio-gpu features.

take care,
  Gerd

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help