Enjoying this issue?
Get tomorrow's AI & engineering digest in your inbox — hand-picked, summarized, and always spam-free.
No summary yet. Click “Regenerate summary” to queue one.
Stop scrolling. Start reading smarter.
Receive the day's most important AI & engineering updates in one concise email. No spam.
Transcript (captions)
Assign your whole graphics card to one virtual machine and your host desktop and other guests lose access. You've got one GPU and two virtual machines that need graphics acceleration, but only one
gets the card. Your second virtual machine still exists. Its access to that GPU doesn't. Why must handing a GPU to one virtual machine take it away from everything else? With whole device pass
through, the device gets detached from its host driver for assignment. One guest gets access to the device and the host and other active guests can't use it simultaneously. Experimental virtual
MVGPU takes another route, the host keeps control of the GPU and guests forward driver requests to it. You're changing what crosses the boundary. Instead of handing over the card, you
send operations to the driver that controls it on the host. Say an app needs a buffer to hold graphics data for a frame. Follow its request to make that buffer available. Our app's inside a
Linux guest, but the driver controlling the physical GPU is on the host. Its request needs to reach that driver. Nvidia's own user mode driver runs unchanged inside the guest. That's the
part running outside the operating system kernel. A module inside the guest kernel forwards the device control request through a Q to a backend on the host. Our buffer request has now crossed
the boundary, but the guest reference to that buffer won't necessarily mean the same thing on the host. Before calling the host driver, the backend translates those references. That includes memory
pointers, resource handles, and file descriptors which identify open files or devices. Different references can then lead to the same resource. Picture one buffer with two views, one from the
guest and one from the host. A shared memory window gives a guest access to mapped GPU memory. Both views point into that same buffer, so graphics data there doesn't need to become a separate copy
for each view. Once those mappings exist, the documented rendering path submits work through them. Drawing can use the access that's already been set up. It doesn't require a separate
forwarded message for every draw call. Our request helped establish access to a buffer. It wasn't carrying a completed frame. That Q carrying device control requests is called a vert Q. Think of it
as the route our buffer request took to the host back end. It isn't a conveyor belt shipping completed frames between guest and host. For the rendering path we followed, the shared mappings provide
access to the memory. Keeping the guests existing NVIDIA user mode driver is a clever part of this arrangement. Its requests still need references the host can understand. Even virtual machines
have paperwork. Here the forwarding module and backend handle that work so the host driver can act on the guest requests bring the second guest back into view. It can have its own
forwarding path toward the same GPU. Unlike the exclusive assignment at the start, this arrangement leaves the physical card with the host. Requests from more than one guest can reach the
driver that controls it. According to the project, four Linux guests used one RTX 3060. Its documentation disagrees with itself. The architecture introduction still calls multi- guest
support unbuilt while the Redmi and benchmark table report it working. These are the project's results without independent confirmation. Start with a single guest measurement, 102.9 frames
pers. One guest ran a synthetic workload on the RTX 3060 and produced that output. With just one guest active, the whole bar represents its result. Now, we're going to add guests while keeping
the same physical card. Run the same workload in four guests, and each gets about 26 frames per second. Together, they reach 103.69. combined output stays approximately
where it started, but each guest's output falls. You're seeing four contributions to roughly the same total, all coming from one card. Four guests didn't each get the original 103 frames
per second. Each contributed roughly a quarter of the combined output in this test. If you're using one of those guests, its individual rate is what matters to you. Even though the card's
total output barely changed, sharing answers and access problem. More guests can reach the GPU. It doesn't multiply the card's compute or memory capacity. When several guests ask for substantial
GPU work at once, one physical card still has to do that work with the resources it already has. Each guest ran the same synthetic workload measured for 30 seconds after an 8-second warm-up.
So, we're comparing matching jobs under defined conditions. Four different demanding applications would be a different test, and this result doesn't tell us how they'd behave together.
Closing numbers can tempt you to imagine four equal reserved shares, but this result doesn't promise fixed quotas or guaranteed fairness, and it doesn't establish separate chunks of protected
graphics memory. We're seeing how much work each guest completed in one workload, not guarantees about what each guest owns. Four is the reported guest count rather than an established
maximum. Adding another four boxes to the diagram wouldn't give us a measured eight guest result. For now, the configuration behind these numbers is specific. Four guests running the same
workload on one RTX 30060. Four doorbells, same kitchen. Extra guests create more ways to ask for GPU work. They don't create another GPU. We've got a way to share access with the card's
capacity still fixed. What could you use this for? And what still hasn't been demonstrated? Before picking a use, separate two costs. Several guests can divide a card's available output, as
we've just seen. Forwarding can also add time even when only one guest is running. A separate single guest comparison measures that extra frame time for particular workloads. In one
synthetic case, a frame on the host took approximately 2 milliseconds. Running it in a single guest was 1.7% slower. That's a small addition beside the original frame time. For this particular
workload, forwarding added relatively little to the time needed to finish a frame, change to a much shorter workload, and the percentage jumps. Host frames taking roughly 0.05 milliseconds
became 40.8% slower in the guest. Both measurements matter. A much larger relative penalty can sit beside a much shorter original job. A small extra weight takes a bigger bite out of a very
short job. That's why you need the original frame time beside the percentage. Percentages can get very dramatic about a very short weight. Here, the two durations keep that
difference in proportion. According to the authors, much of the short frame difference comes from waking the guest after the GP finishes. GP work completes, then the guest needs to
resume. Finishing the work and getting the guest moving again happen at different points on that timeline. A tiny workload can expose that weight more clearly because there's so little
other work around it. Longer frames make the added time a smaller share of the hole. Neither result gives you a universal overhead figure. So these measurements don't support a general
promise of near native performance. For a game, you'd need measurements from that game. Our four guest bar comes from a synthetic workload, so it can't tell you how a heavier interactive session
would feel. Keep that distinction in mind as we move to the work the project actually reports supporting. Headless streaming is the intended use. Imagine a guest producing an image that reaches
you as a video stream. You view it on a remote screen instead of through a monitor plugged into the GPU. Physical display output is outside this project scope. Guests can present images and
encode them in H264, a common video compression format. According to the readme, they use Vulcan video, a programming interface for video processing. Four lightweight encoding
sessions also ran at once. That's a route towards several remote sessions. It doesn't demonstrate four demanding games. Choose the application you care about before choosing which benchmark
number to lean on. If you're planning several guests, their combined output matters, but so does what each guest gets. For a particular workload, frame time adds another piece. How long its
individual frames take. Suppose you already run several Linux virtual machines and want graphics acceleration inside more than one. You have the access problem this experiment could
help with. Several guests can reach the card while the host retains control, giving you more flexibility about where you put GPU work. Maybe you want separate remote environments with
graphics access. Presenting images and encoding video inside the guests points toward that use. Whether those environments would suit you still depends on the applications you need and
what this project supports. A working video path answers only part of that. Being able to put work in different guests without assigning the entire GPU to one is the attraction. Whether that
saves you another hardware purchase depends on your needs. purchase savings, power savings, and setup time reductions weren't measured. So, there's no supported figure to put beside those
possibilities. If you use one ordinary desktop and don't need multiple virtual machines, you aren't facing that access problem. Your desktop already has its path to the GPU. Adding guests doesn't
by itself give you a useful improvement. You need a reason to run the work in separate environments. Already pushing your card as hard as it'll go. Adding guests won't supply another card's
resources. In the synthetic result, roughly the same total output got divided among four guests. Sharing could change where you run the work, but it doesn't solve a shortage of GPU
capacity. GPU sharing already exists. NVIDIA's virtual GPU systems can divide GPU time among virtual machines. On supported GPUs, multi-instance GPU or MIG divides hardware resources into
separate instances. Those are different approaches from this project's arrangement for forwarding requests to the host driver. Keep those mechanisms separate. NVIDIA's documented scheduling
modes don't tell us how this experiment divides GPU time. Likewise, MIG's hardware partitions don't establish isolation here. You can't borrow another systems guarantees just because both
systems let several virtual machines use a GPU. Untrusted guests bring another requirement, keeping them securely isolated. Here, the sandboxed helper and multi-tenant infrastructure are still
unfinished. Getting several guests to use one GP doesn't demonstrate that they're securely separated from each other. Successful graphics work can't answer that security question. CUDA,
Nvidia's platform for running computations on its GPUs, needs an equally clear boundary. Reported testing has reached device enumeration, meaning the GP can be recognized. recognition
doesn't demonstrate a completed CUDA calculation or establish local AI inference, training, or compatibility with a particular CUDA application. Its name badge isn't a work sample. For a
CUDA dependent use, you'd want an actual workload to run and produce results you can assess. Finding the GPU is a step toward that test, but the calculation itself still needs to happen before you
can judge the application. Remember the backend translating our buffer reference? It has to understand the driver interface it's handling. Compatibility depends on support for
that interface called the driver ABI. Keeping Nvidia's user mode driver unchanged doesn't automatically make every driver version or application combination compatible with the
forwarding layer. Treat virtual NVGPU as an engineering experiment for Linux guests with reported graphics sharing and lightweight encoding. A Windows gaming setup or demanding multi-user
game service goes beyond those results. I'd keep it in the experiment category rather than recommend installing it on your everyday machine. If you already run several Linux VMs, start with which
guests need GPU access at the same time. Flexible access is the reason to care. Lightweight streamed graphics gives that possibility a practical direction. Whether it fits your applications is the
next thing that needs an answer. I'd want to see real applications measured both per guest and together. Those results would make it much easier to judge the value for a particular setup.
For now, the mechanism gives guests a path to one host controlled card using forwarded requests and mapped memory. In the reported synthetic test, about 103 frames per second in one guest became
roughly 26 each across four. Same card, approximately the same total output. For a Linux VM enthusiast who needs shared GPU access, I'd watch this project. Supporting your workloads is what'll
decide its value. For an ordinary single desktop user, I'd leave the setup alone on this evidence. There's no demonstrated immediate benefit. One GP, four guests, more access with the same
card doing the work. Which of your existing virtual machines actually needs GP access at the same time?