Announcement

Collapse
No announcement yet.

Intel Pushes XenGT For GPU Access To Virtual Machines

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

  • Intel Pushes XenGT For GPU Access To Virtual Machines

    Phoronix: Intel Pushes XenGT For GPU Access To Virtual Machines

    Last month on Phoronix I wrote about Intel's new XenGT project as a means of mediated GPU pass-through to Xen-based guests. Today at the Linux Foundation Collaboration Summit is an update by an Intel engineer on the XenGT technology...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I don't get it - what separates this from Xen's built-in GPU passthrough? Seems like the exact same thing IMO.

    Comment


    • #3
      Originally posted by schmidtbag View Post
      I don't get it - what separates this from Xen's built-in GPU passthrough? Seems like the exact same thing IMO.
      The article clearly states that it's different. Whereas passthrough gives the GPU to a particular VM, XenGT allows for sharing of the GPU between several VMs.

      Comment


      • #4
        Originally posted by kobblestown View Post
        The article clearly states that it's different. Whereas passthrough gives the GPU to a particular VM, XenGT allows for sharing of the GPU between several VMs.
        Oh whoops I didn't see that it said "same GPU". My bad.

        Comment


        • #5
          Will this just allow the integrated GPU to be shared or will it potentially allow other GPUs in the system to be shared between the guest and the host?

          edit: And presumably this will still only work for VT-d supporting CPUs?
          Last edited by Tom B; 27 March 2014, 08:21 PM.

          Comment


          • #6
            Originally posted by Tom B View Post
            edit: And presumably this will still only work for VT-d supporting CPUs?
            I don't think that's the case. From https://01.org/xen/blogs/srclarkx/20...lization-xengt

            Performance critical resources are passed through to a VM:

            Part of the global virtual memory space
            VM?s own per-process virtual memory spaces
            VM?s own allocated command buffers (actually in graphics memory)

            Other operations are privileged, and must be trapped and emulated by the mediator, including:

            MMIO/PIO
            PCI configuration registers
            GTT tables
            Submission of queued GPU commands
            With VT-d there would be no need to emulate these things. For the pass-through resources it looks like they are all memory-related and can be done with EPT because this is only for intel's IGPs where the video memory is shared with the system memory. I may be wrong though so please feel free to correct me.

            Comment


            • #7
              Very interesting news - but I suspect that the (early, at least) drawback would be that the drivers of the Host OS would have to be cooperative to a certain degree?

              Comment


              • #8
                Originally posted by Nognir View Post
                Very interesting news - but I suspect that the (early, at least) drawback would be that the drivers of the Host OS would have to be cooperative to a certain degree?
                This doesn't seem to be the case. From the link above:

                XenGT implements the mediator in dom0. This avoids adding complex device knowledge to Xen, and also permits a more flexible release model. In the meantime, we want to have a unified architecture to mediate all the VMs, including dom0, itself. So, the mediator is implemented as a separate module from dom0?s graphics driver. It brings a new challenge, that Xen must selectively trap the accesses from dom0?s driver while granting permission to the mediator. We call it a ?deprivileged? dom0 mode.
                I interpret this to mean that there are no changes to host or guest drivers. Sounds too good to be true. But I guess it has performance impact so it's a sort of compromise between flexibility and performance (as usual).

                Anyway, it looks like a pretty good solution in case you only need the GPU for desktop effects and such. And that's all I need.

                Comment


                • #9
                  Originally posted by kobblestown View Post
                  Anyway, it looks like a pretty good solution in case you only need the GPU for desktop effects and such. And that's all I need.
                  Actually, at least according to the 01 link, with some optimization they may actually pass the 50% mark of native speed that will make it viable for both gaming and 3D/CAD applications.
                  Remember that unlike VT-d based solutions, mutiple-VMs + host can share the same GPU (as the mediator runs in dom0) making it far more viable solution for desktop virtualization.

                  - Gilboa
                  oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
                  oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
                  oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
                  Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

                  Comment

                  Working...
                  X