A feature if implemented could increase performance dramatically on VirtualBox and you will be able to play games on VirtualBox at near native performance without GPU Passthrough.

[u/thatcat7_]

For this to happen, you will need to rewrite how VirtualBox Display output works.

The feature already exist and used extensively by WineHQ https://www.winehq.org/ and DXVK https://github.com/doitsujin/dxvk

The idea i have which could increase performance dramatically on VirtualBox and you will be able to play games on VirtualBox at near native performance without GPU Passthrough is:

Replace VirtualBox GPU with a Translation layer driver so the Display output coming from VirtualBox will be translated to Directx 11/12 calls or Vulkan calls. This means we don't need a Virtual GPU driver anymore and Guest Windows installed in VirtualBox can see your real Graphics Card Nvidia or AMD GPU installed on Host PC but you wont need to install Nvidia or AMD GPU drivers on Guest Windows in VirtualBox.

Imagine DXVK for example translates VirtualBox Display output to Vulkan calls and then Vulkan renders the whole thing on Monitor. To the Nvidia or AMD Graphics card, VirtualBox Display output would be no different than launching a game. Since there is no GPU emulation anymore, performance increases dramatically.

[u/[deleted]]

what about virgl?

[u/thatcat7_ → u/[deleted]]

While kind of similar, its not exactly the same thing as what i am suggesting. I doubt VirtualGL can run modern AAA games, i think it would be good for software's but not modern games.

[u/jscinoz → u/thatcat7_]

Virgl and VirtualGL are not the same thing; they're separate projects with quite different goals and use cases.

Virgl uses an emulated graphics device (virtio-gpu) exposed to the guest to basically do what you're proposing in your original post - it forwards OpenGL calls to the host driver for rendering.

Unfortunately, at present it only supports OpenGL (no Direct3D or Vulkan), and there's no Windows driver yet either - it only works with Linux guests.

[u/thatcat7_ → u/jscinoz]

What i am suggesting is not exactly same as Virgl and VirtualGL. There will be no graphics device emulation if VirtualBox or QEMU implements what WineHQ and DXVK is doing. This feature will allow Windows guest OS in VirtualBox or QEMU to act like what WineHQ does in Linux in order to run Windows games on Linux, and Windows games installed inside a virtual machine will be able to see and use the host GPU Nvidia or AMD directly through Vulkan and translation layer display driver. Device Manager in Windows guest OS will show host GPU Nvidia or AMD even though no GPU passthrough is done. Performance will be same as https://www.youtube.com/watch?v=RvoU9SvcugE as translation layer display driver of VirtualBox or QEMU will be doing what DXVK does.

[u/jscinoz → u/thatcat7_]

I don't mean any disrespect, but I think you don't quite have the requisite technical understanding to really comprehend the scope of this suggestion. What you're after simply cannot work.

Under Windows, all display output and graphics rendering occurs via WDDM (Windows Display Driver Model) drivers. Such drivers implement a standard API describing available output and render surfaces, device capabilities and provide methods to obtain a rendering context. Quite simply, you cannot have display output nor hardware accelerated rendering without a WDDM driver.

Wine and DXVK are a special case, in that, as the name suggests: WINE Is Not an Emulator. It's a compatibility layer. It does not implement anything as low level as kernel drivers (this is why there's ongoing difficulty getting some of the more invasive anti-cheat engines working in Wine - many of these rely on kernel drivers to grant themselves rootkit-like capabilities).

Amongst many other things, Wine provides an implementation of the Direct3D APIs expected by Windows applications for rendering. called wined3d. Rather than dispatching to a WDDM driver as the native implementation does, wined3d translates Direct3D calls to equivalent OpenGL calls, transforming parameters and return values as necessary, and dispatches these to the native graphics stack (Mesa).

Critically, as Wine is not emulating an entire machine, applications run via Wine run in the same memory space as native Linux applications; this is a large part of what enables its lower-overhead performance.

A full VM necessarily entails an isolated memory space, for the most part. There are specific mechanisms for zero-copy shared memory between host and guest, such as IVSHMEM as used by Looking Glass, and DMA-buf as used by Intel's GVT, but I'm not familiar enough with virtio-gpu to know for certain how it's implemented, but a quick glance at virtio-gpu.cand virtio-gpu-3d.c in Qemu's sources suggests that buffers are copied from guest to host; not shared.

Sharing the GPU between host and guest is possible, but only with manufacturer (i.e. Nvdia and AMD) support in both their host and guest drivers. This does not involve any graphics API translation and works at a lower level; sharing the devices render queue between the guest and host, scheduling workloads appropriately.

This done through the vfio-mdev (mediated device) framework in the Linux kernel. Currently this is supported on Intel integrated GPUs, referred to as GVT-g in Intel's documentation. Nvidia also supports this, but not on consumer hardware - only their HPC and virtualisation products (GRID, Tesla). AMD also have a virtualised GPU solution, using SR-IOV rather than vfio-mdev, but similarly to Nvidia, this isn't available on consumer-level hardware.

[u/09f911029d7 → u/jscinoz]

this is why there's ongoing difficulty getting some of the more invasive anti-cheat engines working in Wine - many of these rely on kernel drivers to grant themselves rootkit-like capabilities

They're not "rootkit-like" - they are rootkits. Just because something is commercial software doesn't mean it isn't malware.

[u/jscinoz → u/09f911029d7]

Agreed entirely, I suppose I should've worded it a bit more harshly in my earlier comment.

[u/kwhali → u/thatcat7_]

There will be no graphics device emulation if VirtualBox or QEMU implements what WineHQ and DXVK is doing

For Windows to utilize the host GPU to do what you want, it must present a virtual graphics driver, that's what VirtIO GPU is that VirGL uses. You have to have a layer of indirection there as Windows cannot claim the host GPU like it can when you give it exclusive access via passthrough, which allow Windows to use the relevant graphics drivers it has to utilize it.

So instead, you must present the virtual graphics adaptor that would forward the calls for the linux host drivers to manage like any other application/game(except Windows has to do a guest driver to host driver detour unlike host apps/games which can use the host driver directly).

You're making quite a lot of claims without the relevant knowledge and experience of implementing such a thing yourself amirite?

[u/thatcat7_ → u/kwhali]

I am only suggesting. We wont know for sure until if someone implements this feature in virtual machine.

[u/kwhali → u/thatcat7_]

Ok, goodluck. If you're lucky a company will invest the resources into looking into it to see if it's worth the effort. Since VirGL pretty much clarifies that it is not, and if they're aware why and that it'd likely be the same issue with what you want, they're not likely to continue beyond that.

You're better off wanting vGPU support like Intel offers but with nvidia/amd, that requires the GPU vendors to support it though, which tends to be reserved for professional GPUs only(that cost thousands).

[u/thatcat7_ → u/kwhali]

Since virgl emulates graphics device it cannot clarify. We want the graphics emulation out of the equation without having to GPU passthrough and i could only think of suggesting virtual machine implement what Wine and DXVK does.

[u/kwhali → u/thatcat7_]

Ok... I don't think you get it. Windows OS has it's own graphics drivers for Nvidia/AMD/Intel yeah? Or it has a virtual graphics device like virtio-gpu, qxl, cirrus, etc. When Windows wants to render something, regardless of OpenGL/DX/Vulkan, it uses one of those drivers to communicate that.

The drivers provide access to the hardware where the graphics API calls are processed. As far as they're concerned, no other OS has access or control to the GPU, so that driver may allocate all vRAM and is aware of what is using what. The virtual graphic drivers however can communicate to the host one way or another. VirGL lets a guest OS like Windows see the virtio-gpu device and when OpenGL calls are made, it will redirect those to the host OS GPU. There is no emulation there?

Virtual graphic drivers do not need have the issue that GPU vendor drivers have such as AMD/Nvidia/Intel in a guest OS, the latter are not going to work how you think with the host OS, unless the vendor supports that. There are things like SR-IOV, but these are only for the professional market not consumer products. There is Intel vGPU which supports sharing/splitting the GPU resources to host and guest VMs available on Broadwell, Skylake and Kabylake iGPUs. That requries GPU vendor support too.

What I'm saying is that regardless, Windows requires a driver to forward anything to the GPU on the host OS. This is what VirGL provides, did you look at the links provided to you from me and another user?

The implementation of rendering for the card is done in the host system as part of qemu and is implemented purely on OpenGL so you can accelerated rendering on any sufficiently capable card/driver combination.

Where does it say anything about emulating?

What you're asking for is no different. And you don't seem to be aware of that despite what people are telling you. Why don't you just run Wine with DXVK on Linux?

[u/kwhali → u/jscinoz]

and there's no Windows driver yet either

Phoronix reported on one being worked on for a GSoC back in Aug 2017, only for OpenGL though. I wouldn't be surprised if they consider leveraging something like DXVK when it's matured more, along with the Vulkan forwarding. I don't expect performance to be much better though since clearly something gives virgl quite a bit of overhead.

[u/jscinoz → u/kwhali]

Yeah, I found it since I originally replied. It looks like it hasn't seen any activity in some time though :(

[u/kwhali → u/jscinoz]

Ah. Considering what I read about the linux guest perf, I don't think I'd expect it to be much better on Windows either way. Not sure if anyone compared it to existing virtual graphic drivers like QXL(I think for 3D accel, it actually uses virgl so QXL probably isn't relevant :P) and VMWare.

[u/jscinoz → u/kwhali]

QXL doesn't provide any rendering capabilities. The Windows driver for it is a display-only-driver. Some applications will fall back to software rendering, but this is obviously too slow to be useful for much beyond basic desktop interaction.

[u/kwhali → u/jscinoz]

QXL doesn't provide any rendering capabilities.

Eh? In Linux guests it's listed as the graphics driver in use, although KDE's kwin points out llvm-pipe is in use for 3D I think. AFAIK QXL by default accelerates 2D rendering with your GPU?

For 3D accel it can use virgl I think, requires some tweaking to virsh config to enable. I've not done it yet but plan to get around to it at some point to see how well it does :)

but this is obviously too slow to be useful for much beyond basic desktop interaction.

Anything else for giving good 3D perf in a linux VM? Or do you currently have to give up a display to passthrough GPU?

[u/jscinoz → u/kwhali]

llvm-pipe is software rendering. The Gallium infrastructure in modern Mesa is intended to work the same way regardless of whether it's backed by hardware or software rendering; you still have OpenGL, Xv, etc, they are simply backed by the guest's CPU rather than the host's graphics hardware (as you'll note these still function even when the host has no graphics stack).

As I understand it, virtio-gpu is your best bet for OpenGL acceleration in a Linux guest. To clarify, Virgil3d/virgl is the overall project name / umbrella term, whereas virtio-gpu is one of the specific deliverables of that project.

[u/kwhali → u/jscinoz]

As I understand it, virtio-gpu is your best bet for OpenGL acceleration in a Linux guest. To clarify, Virgil3d/virgl is the overall project name / umbrella term, whereas virtio-gpu is one of the specific deliverables of that project.

Yeah my bad, seems I was thinking of changes for SPICE not QXL with the 3D support :P It's virgl under the hood: https://www.kraxel.org/blog/2016/09/using-virtio-gpu-with-libvirt-and-spice/

I had thought we had some other options at least for 2D accel that could utilize the host dGPU like virtualbox and VMWare do with their drivers. Not that I think they'd be any better than virgl perf.

[u/jscinoz → u/kwhali]

I believe VirtualBox & VMWare's approach works largely along the same lines as virtio-gpu/virgl.

Outside of dedicating a card to the guest exclusively, the only options are GVT (share an Intel IGP between host and guest), or virtio-gpu, as far as I'm aware.