Announcement

Collapse
No announcement yet.

VirtIO DRM Window Server Support: Letting Guest VMs Interface With Host's Compositor

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

  • #21
    Originally posted by starshipeleven View Post
    virt-io GPU is a way to access a host GPU from the guest, which is required to have the guest render stuff on its own in the first place. Then this patch adds a way to move over rendered "windows" to the host.
    Please type it name right its not virt-io gpu its virtio-gpu absolute correct and virtio gpu slightly wrong. There is something else out there called virt-io gpu and its totally a different thing.
    Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It this sentence on the patch you have not read or you at least missed the last bit. Why is it copying content as needed. With virtio-gpu due to having access to hosts gpu render tasks performed on host gpu the instruction to host compositor from guest might be using a frame that was generated host side and has not been transferred back to guest. So this virtio-gpu patch will not always be moving rendered windows over to host as host might have rendered the buffer following the guest instructions and now has a message to display that buffer so the buffer might never be transferred back to guest because virtio-gpu avoids pointless coping.


    Originally posted by starshipeleven View Post
    Wat?
    Looking Glass is still a way to pipe rendered frames to the host and integrate them seamlessly in it as if they were native programs, but per-se isn't exposing host GPU.

    While virtio-gpu is much more than just this feature (as it also exposes the GPU in the guest, which is still required because the guest still renders stuff on its own before sending the buffer to the host's compositor).
    One of the big difference between looking glass and virtio-gpu is the fact that under virtio-gpu the buffer the host compositor is being told to display might be a buffer the gpu connected to host has generated.

    Looking Glass at this stage would be passing a full video card in the very expensive cards then capturing and transferring. Virtio-gpu supports drm prime mode so you use a decanted a card to a virtual machine and use virtio-gpu to transfer the output of that card to the host as well.

    https://wiki.debian.org/VGAPassthrough When you say guest renders stuff on own this sound to me like VGAPassthrough as this would not be using the host resources. Using virtio-gpu gpu functionality is using the host resources. It is important to understand when you are using host or guest because this can provide very different resource starvation points.

    Looking glass is lot more primitive item.

    Comment


    • #22
      Originally posted by oiaohm View Post
      Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It this sentence on the patch you have not read or you at least missed the last bit. Why is it copying content as needed. With virtio-gpu due to having access to hosts gpu render tasks performed on host gpu the instruction to host compositor from guest might be using a frame that was generated host side and has not been transferred back to guest. So this virtio-gpu patch will not always be moving rendered windows over to host as host might have rendered the buffer following the guest instructions and now has a message to display that buffer so the buffer might never be transferred back to guest because virtio-gpu avoids pointless coping.
      Hm, this is very interesting, thanks.

      I didn't consider that if you offload the rendering to host GPU with virtio-gpu (instead of using a KVM/Xen passthrough GPU the host has no control over) then the rendered frame is already on the host and can be sent to compositor directly.

      Comment


      • #23
        Originally posted by starshipeleven View Post
        Hm, this is very interesting, thanks.

        I didn't consider that if you offload the rendering to host GPU with virtio-gpu (instead of using a KVM/Xen passthrough GPU the host has no control over) then the rendered frame is already on the host and can be sent to compositor directly.
        It makes a hell of a lot of difference as well. Remember PCIe transfer limits are lower than host ram transfer limits. So using KVM/Xen passthrough GPU and scraping the graphics back off to be transferred to host costs the PCI-e bus all the render request and the scrape then uploading the scrape onto the right video card. Virtio-gpu has more cpu mmu memory juggling and the possibility of bundling multi applications on one screen output before performing scrape but what is transferred across the pci-e bus is kept as light as possible. Of course Virtio-gpu used with Prime and a KVM/Xen pass-through will wake up a lot of the pce-e buss transfer space consume problems.

        So it will be how the applications choke the hardware that will decide if KVM/Xen pass-through gpu processing or virtio-gpu gpu processingis better and sometimes a mix of the two.

        Also with host controlled gpu something generated on the GPU can stay on the GPU in the GPU ram even it if request of generation was requested by a guest if the guest and host compositor never wants result and still have that fragment sent to output. This also can reduce volume of traffic that need to be transferred back to host and guest for virtio-gpu.

        Its really simple to forget the case of many small virtual machines doing many small light gpu dependant operations that user need to see the output of and that something like looking glass could run you out of the all import pci-e bus bandwidth.

        Comment


        • #24
          Originally posted by bofh80
          Not as good as you would think. Having to cross network adds a lot of latency. Windows TCP stack has connection limits.
          https://community.spiceworks.com/top...nection-limits

          Yes you desktop version of windows are between 10 to 20 incoming active tcp/udp connections. So using RDP or xpra you have consumed very valuable limited resource under Windows.

          Virtio-gpu and the new project looking glass are both using virtual machine supported IPC these don't count in the network stack.

          Also going into the network stack xpra introduces more latency so less felling like native than virtio-gpu and the new project looking glass.

          So like it or not what you are suggesting bofh80 is really not as good as we can do.

          With the connection issues of windows it would be great to have a virtio-filesystem that could be network file systems from host that are not consuming up the Windows limited network connections. So it could be possible for Windows to perform better under a virtual machine than native all due to inconvenient limitations designed into Windows.

          Comment


          • #25
            Originally posted by ermo View Post

            now that it has been demonstrated that you can create performant micro-kernel OSes.
            When has this been demonstrated? What project has demonstrated this? What are these performant micro-kernel OSes you are talking about?

            Comment


            • #26
              Originally posted by tajjada View Post

              When has this been demonstrated? What project has demonstrated this? What are these performant micro-kernel OSes you are talking about?
              AIUI, the L4 family demonstrated that high performance is achievable in a microkernel design.

              In addition, seL4 has the interesting property of being formally verified against its specification, which is admittedly orthogonal to any performance claims, but still pretty cool.

              Comment


              • #27
                Originally posted by ermo View Post

                AIUI, the L4 family demonstrated that high performance is achievable in a microkernel design.

                In addition, seL4 has the interesting property of being formally verified against its specification, which is admittedly orthogonal to any performance claims, but still pretty cool.
                Not really L4 microkernel made a good hyper-visor but most of the time it was using drivers in monolithic Linux kernel. So while the Linux kernel had the cpu time it was handling more than 1 hardware device. So there has not be a micro-kernel with micro-kernel drivers demonstrate high performance. Even QNX lot of it drivers went monolithic.

                Comment

                Working...
                X