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

[Zhang, Tina]

> -----Original Message-----
> From: dri-devel <dri-devel-bounces at lists.freedesktop.org> On Behalf Of Gerd
> Hoffmann
> Sent: Friday, February 12, 2021 7:02 PM
> To: Kasireddy, Vivek <vivek.kasireddy at intel.com>
> Cc: Kim, Dongwon <dongwon.kim at intel.com>; christian.koenig at amd.com;
> daniel.vetter at ffwll.ch; dri-devel at lists.freedesktop.org;
> virtualization at lists.linux-foundation.org; Vetter, Daniel
> <daniel.vetter at intel.com>; linux-media at 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:
> > Hi Gerd,
> >
> > > > > 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.
> 
> > > 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.
> > [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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel