4 ms·
Intel's Xe embedded SKUs are supported: https://openmdev.io/index.php/GPU_Support https://openmdev.io/index.php/GPU_Support We did some things to enable GPU v
by ArcVRArthur 4y ago
Intel's Xe embedded SKUs are supported:
https://openmdev.io/index.php/GPU_Support https://openmdev.io/index.php/GPU_Support
We did some things to enable GPU virtualization on older driver revisions for most Nvidia consumer GPUs and some AMD GPUs as well. Here's that post if you'd like to take a look:
https://news.ycombinator.com/item?id=28944426 https://news.ycombinator.com/item?id=28944426
We're building a free/libre (AGPLv3 & GPLv2) virtualization stack intended to support i915 (Intel) and Nvidia (OpenRM). We're planning support for Tenstorrent TPUs and in the longer term possibly AMD GPUs.
Here's a full summary of how GPU virtualization actually works under various modes from our wiki. This includes VFIO-Mediated Devices (Mdev), Single Root I/O Virtualization (SR-IOV), and Intel's new Scalable I/O Virtualization (SIOV):
https://openmdev.io/index.php/Mediated_Device_Internals https://openmdev.io/index.php/Mediated_Device_Internals
- yolo4553 4y agoCurious about Tenstorrent. Did you ever get your hands on any of their hardware? We are just getting excuses from them since several months and have not yet received even a single unit for evaluation.
- ArcVRArthur 4y agoI believe we're expecting units in a few weeks.
- evol262 4y ago> Intel's Xe embedded SKUs are supported: > https://openmdev.io/index.php/GPU_Support https://openmdev.io/index.php/GPU_Support I'm not trying to beat a dead horse here, but your matrix links to an archive of Intel's community forum, where it's a basic question, about Windows. https://archive.ph/0McAE#selection-4883.0-4943.35 https://archive.ph/0McAE#selection-4883.0-4943.35 Then a link to Intel's LTS Linux repo. Do your scripts, if it's Xe, actually clone/build this and boot into it? What does "supported" mean in this sense? Do you replace the user's kernel with the intel-lts fork? If so, do you tell them? > We did some things to enable GPU virtualization on older driver revisions for most Nvidia consumer GPUs and some AMD GPUs as well. Here's that post if you'd like to take a look: You have some patches to drivers. Which is great. But "we did some things" on HN is best followed with "here's what we did from a technical level" or "here's the source", not "here's how to install our product". https://github.com/Arc-Compute/LibVF.IO/tree/master/patches https://github.com/Arc-Compute/LibVF.IO/tree/master/patches Is there anything at all here which isn't applicable to other KVM-based virt platforms? It looks like not. > We're building a free/libre (AGPLv3 & GPLv2) virtualization stack intended to support i915 (Intel) and Nvidia (OpenRM). Again, this is great. But please be clear that "we're building a free/libre virtualization stack" is "we are building a very opinionated wrapper around qemu+KVM which is not using libvirt bindings for some reason". The "stack" definitely looks like "some utility scripts to make this easier". Is there a project homepage with a roadmap, goals, and issues/bugs, and so on?
- ArcVRArthur 4y agoAgain as in your other comment GVM does not actually have anything to do with LibVF.IO right now. They don't even work together. GVM/Mdev-GPU is actually a free software component that virtualizes GPUs, not a wrapper for QEMU/KVM. That's misinformation. GVM/Mdev-GPU is over here - not in the LibVF.IO codebase which you link to: https://github.com/Arc-Compute/Mdev-GPU https://github.com/Arc-Compute/Mdev-GPU https://docs.linux-gvm.org/mdev-gpu/ https://docs.linux-gvm.org/mdev-gpu/ Also Intel's SR-IOV isn't my code. You have to ask them about that.