On Fri, Apr 30, 2021 at 07:32:58PM +0400, Marc-André Lureau wrote: > Hi > > On Fri, Apr 30, 2021 at 4:23 PM Gerd Hoffmann <kra...@redhat.com> wrote: > > > Currently we have one virtio-gpu device. Problem with this approach is > > that if you compile a full-featured qemu you'll get a virtio-gpu device > > which depends on opengl and virgl, so these dependencies must be > > installed and the libraries will be loaded into memory even if you don't > > use virgl. Also the code is cluttered with #ifdefs and a bit messy. > > > > This patch series splits the virtio-gpu device into two: > > > > (1) virtio-gpu-device becomes the non-virgl device, same as > > virtio-gpu-device,virgl=off today. > > (2) virtio-gpu-gl-device is the new virgl device, same as > > virtio-gpu-device,virgl=on today. > > > > When compiling qemu without virglrenderer support virtio-gpu-device > > behavior doesn't change. > > > > v2: > > - rebase to latest master. > > - move pci and vga wrappers to separate modules. > > - fix ci failures. > > > > The patch series looks good. > > But isn't that a breaking change? Any existing user of > virtio-gpu/vga,virgl=on will no longer get a working setup. Right?
Correct. > Imho, in > this case (virgl VM being not very common) the benefit is worth it. > However, I suggest to keep the 'virgl=' property, and print a deprecation / > replaced-by warning, falling back to non-virgl/2d mode. Problem with that is that libvirt uses the virgl property to figure whenever virtio-gpu-pci / virtio-vga supports virgl or not. So a dummy virgl property just for printing a warning message doesn't look like a good idea to me. > Or perhaps we could > have more cleverness to have virgl=on aliasing to the new devices. If that is doable without ugly hacks I'm open to it. Suggestions how to do that anyone? take care, Gerd
