Announcement

Collapse
No announcement yet.

VirtIO Video Driver Coming Together For The Mainline Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • VirtIO Video Driver Coming Together For The Mainline Linux Kernel

    Phoronix: VirtIO Video Driver Coming Together For The Mainline Linux Kernel

    VirtIO-Video is a VirtIO-based video driver for a virtual V4L2 streaming device with input/output buffers for sharing of video devices with guests. VirtIO Video has existed for a while now but it looks like it could be getting close to upstreaming in the Linux kernel...

    http://www.phoronix.com/scan.php?pag...tIO-Video-2020

  • #2
    That's nice, but it makes me wonder how hard can it be to write a VirtIO-Vulkan driver and have Vulkan compatible Windows games happily run in a Windows guest, at least for those hosts that have Vulkan compatible hardware and driver.

    I know, there's VirtIO-GPU in the works, but that's part of virgl project, whose name (the "gl" part), makes me suspect they're following the much harder route of providing Vulkan guest support over OGL hosts.

    I'm thinking of a more direct 1-1 mapping from guest to host that would work only for those hosts that can provide Vulkan themselves.
    Last edited by lucrus; 03-26-2020, 05:37 AM.

    Comment


    • #3
      One big feature that I miss in Linux is watching movies in high quality, especially now with all that's happening.
      On Windows 7 I use MPC-HC + MadVr which are part of K-lite codec pack which give impressive quality, hardware accelerated and also handles nicely HDR-> normal screen conversion.
      With this change can I use the same setup to watch movies in high quality as a guest in something like Virtualbox ?

      Comment


      • #4
        It'd be cool at some point to see a microkernel system that can slowly subsume these services from the linux kernel, until what's left is simply a compatible runtime. As the virtual accelerated graphics devices become more mature, I think this is basically almost ready to start. This is, in many ways, the HAL dream of yore, but actually practical.

        Comment


        • #5
          Originally posted by lucrus View Post
          That's nice, but it makes me wonder how hard can it be to write a VirtIO-Vulkan driver and have Vulkan compatible Windows games happily run in a Windows guest, at least for those hosts that have Vulkan compatible hardware and driver.

          I know, there's VirtIO-GPU in the works, but that's part of virgl project, whose name (the "gl" part), makes me suspect they're following the much harder route of providing Vulkan guest support over OGL hosts.

          I'm thinking of a more direct 1-1 mapping from guest to host that would work only for those hosts that can provide Vulkan themselves.
          It's not really possible to build Vulkan on top of OpenGL. You can't build a low-overhead API on top of an API with a higher overhead. Especially since Vulkan is intended to give greater control over contexts and object lifetime. No one's intending to do that. It'd royally screw up a lot of games.

          Virgl (which was also called Virgil 3D at one point) was given the name trying to be clever at a time when OpenGL was the only open 3D stack around. FOSS loves its clever names, and calling virtualized GL support Virgil was too tempting to pass up. Project goals (long-term) also include a Direct3D driver for windows and OpenGL ES support, so it's not like they're only working with OpenGL.

          It's also relevant that David Airlie started Virgil, and Bas and he also started radv (the open source vulkan driver for AMD GPUs). They may not be the ones to get virtualized Vulkan support in the end, but they're not unfamiliar with Vulkan and virtualization in general.

          Comment


          • #6
            Originally posted by Danny3 View Post
            One big feature that I miss in Linux is watching movies in high quality, especially now with all that's happening.
            On Windows 7 I use MPC-HC + MadVr which are part of K-lite codec pack which give impressive quality, hardware accelerated and also handles nicely HDR-> normal screen conversion.
            With this change can I use the same setup to watch movies in high quality as a guest in something like Virtualbox ?
            Disclaimer: I am not a color/colour expert. I have not read about VirtIO-Video much, so I'm making a lot of assumptions.

            High quality is a relative term - High quality in terms of 1920x1080 and 32bpp has been possible to on Linux for ~17 years, codecs were not very good but GPU resolution and colour was. In terms of 3840 x 2160 and HDR10/HDR10+ it is not yet stable on Linux. AFAIK support has been mainlined for AMD GPUs, but you'll probably need to use a desktop environment that implements these ideas https://lists.freedesktop.org/archiv...ry/039809.html . I have an AMD GPU and HDR screen, but have not test it yet (waiting for more news first).

            If you want to run Windows + said codec pack then convert HDR -> sRGB and display it on your Linux desktop you can do that already. I tested it (without conversion/hardware-acceleration) ~7 years ago, you'll have to do some tweaks and make sure that you're using virtualization software that works well. Initially I ran it over uncompressed VNC connection, it was good enough for movies. Later I switched to spice client which was a lot better and "just worked" without having to tweak anything, I could even play games over it. I'm not sure how well this will work with Virtualbox, best to ask someone that has used it regularly.

            From my understanding VirtIO-Video will provide hardware acceleration from the host OS and provide an easier way with less-overhead and smaller-size/faster/more-reliable frames than previous methods like VNC or Spice. I wonder how much inspiration, if any, they got from https://github.com/gnif/LookingGlass (which is an awesome project for a niche group). I would like to see a demo of VirtIO-Video sometime. An addition use-case of VirtIO-Video would be to use a virtual machine for headless hardware accelerated video encoding. I can see how some might use that and just ignore remote displays completely.

            These days I use a Windows VM with iommu/vfio GPU that is passed it. I plug my HDR screen directly into my GPU that is connected to my Windows VM and watch movies or play games there, since the screen is connected directly to the GPU and native Windows drivers are used all content works flawlessly including things like HDCP and I can backup/restore Windows at any time without much inconvenience.

            It would be awesome if it works natively on Linux out of the box, but I don't think we are there yet.

            Comment


            • #7
              does this mean that i can finally have a decent speed on qemu android emulator?

              Comment


              • #8
                Originally posted by Danny3 View Post
                One big feature that I miss in Linux is watching movies in high quality, especially now with all that's happening.
                On Windows 7 I use MPC-HC + MadVr which are part of K-lite codec pack which give impressive quality, hardware accelerated and also handles nicely HDR-> normal screen conversion.
                With this change can I use the same setup to watch movies in high quality as a guest in something like Virtualbox ?
                https://en.wikipedia.org/wiki/Video4Linux
                Wrong video this is about Video4Linux stuff as in webcams, cameras, tv tuners, strange methods of screen capture...

                MadVr is different set of stuff.

                https://trac.ffmpeg.org/wiki/HWAccelIntro
                Did you try opencl support kind of makes a huge different on Linux video playback at times.

                https://www.phoronix.com/scan.php?pa...AMD-AMF-Vulkan
                There will be other acceleration methods added for Linux users in time.

                Really MadVr is getting very long in the tooth.

                Comment


                • #9
                  Originally posted by Terrablit View Post

                  It's not really possible to build Vulkan on top of OpenGL. You can't build a low-overhead API on top of an API with a higher overhead. Especially since Vulkan is intended to give greater control over contexts and object lifetime. No one's intending to do that. It'd royally screw up a lot of games.
                  Thanks for the explanation, very appreciated.

                  But now my question is: why is it so hard to do a 1:1 mapping of the Vulkan API between the VirtIO-GPU driver and the undelying host Vulkan driver?

                  Comment


                  • #10
                    Originally posted by lucrus View Post

                    Thanks for the explanation, very appreciated.

                    But now my question is: why is it so hard to do a 1:1 mapping of the Vulkan API between the VirtIO-GPU driver and the undelying host Vulkan driver?
                    https://www.kraxel.org/blog/2019/11/...tus-and-plans/

                    The problem is not the 1:1 map its how to share memory and metadata correctly across the virtio system. Work is under way todo the low level changes required for Vulkan to work. Basically vulkan and opengl on this stuff is two very different beasts and it will take some time to lay the foundations for vulkan. But some extentions of opengl cannot be made work without sections of the memory management and metadata vulkan requires so problem has to be solved.

                    Comment

                    Working...
                    X