> -----Original Message----- > From: dri-devel <dri-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Gerd > Hoffmann > Sent: Friday, February 12, 2021 7:02 PM > To: Kasireddy, Vivek <vivek.kasireddy@xxxxxxxxx> > Cc: Kim, Dongwon <dongwon.kim@xxxxxxxxx>; christian.koenig@xxxxxxx; > daniel.vetter@xxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; > virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx; Vetter, Daniel > <daniel.vetter@xxxxxxxxx>; linux-media@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel
