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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
