Is the process of unlocking these features on Nvidia GPUs similar to something like the vgpu_unlock tool is doing?[1] No affiliation, just came across it trying to find a replacement to the deprecated RemoteFX vGPU and am out of my depth.
(which is the direct successor)
The advantage is that it ships inbox in Windows and doesn't need license hacks or anything. It works cross-vendor too.
However, it needs the host OS to be Windows (with Hyper-V being used).
edit - apparently while this works on Server 2019 direct pass through is the only officially "supported" option. I wonder if this is a stepping on partners' toes sort of situation?
One of the benefits to using our approach instead of Microsoft's is that our tools are free open source software and (my biased opinion) I think we have an easier user setup. :)
Some day I would love to read Hyper-V's GPU-P code as I think they did a rather good job overall.
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/drive...
Here's a few examples of YAML for use with different GPU vendors:
Intel: https://github.com/Arc-Compute/libvf.io/blob/master/example/...
Nvidia: https://github.com/Arc-Compute/libvf.io/blob/master/example/...
AMD: https://github.com/Arc-Compute/libvf.io/blob/master/example/...
The odd one out is AMD that uses a different API due to the fact that the vendor has largely ignored standard open source interfaces in the kernel. We're still supporting that API but unfortunately there are very few AMD cards that work due to the fact that they refuse to release open source code to support their newer cards and they have locked out these features at the firmware level on consumer cards. Fortunately Nvidia and Intel GPUs are very well suited to this functionality and we've got support for most recent consumer cards from both!
I'm curious to see if this could be used in virtualizing macOS with GVT-g for 3D accelerated guests. I know that this was looked at a few year ago and no one had made it work then.
0: https://github.com/torvalds/linux/blob/2f111a6fd5b5297b4e92f...
You can see the GVT-Linux repository is also still receiving commits: https://github.com/intel/gvt-linux
As for GVT-g and Xe, according to a post in this[0] issue by one of the Intel devs, Rocket Lake (Xe) is not getting support and only does GVT-d.
Also in the same issue, someone pointed out that Intel themselves have states as much here[1].
I hope I am proven wrong in the end and GVT-g comes to then entire Xe and ARC lineup. Intel's communication on this matter has been...lacking.
0: https://github.com/intel/gvt-linux/issues/190
1: https://www.intel.com/content/www/us/en/support/articles/000...
Makes sense as in servers you probably want static partitioning anyways, but for desktop it was perfect.
It may be that they're changing internal APIs used for device mediation which wouldn't surprise me given both AMD and Nvidia use SR-IOV but only Intel uses GVT-g.