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?> 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. Thanks, Vivek> > It might be useful to add support for display-less virtio-gpu, i.e. > "qemu -device virtio-gpu-pci,max_outputs=0". Right now the linux driver throws an error > in case no output (crtc) is present. Should be fixable without too much effort though, > effectively the sanity check would have to be moved from driver initialization to > commands like SET_SCANOUT which manage the outputs. > > take care, > Gerd
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. 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
> -----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