4 ms·

> More complex than that. MIG covers compute use cases only. For workloads where graphics are needed (or even the graphics APIs), you have to use preemptive sch

> More complex than that. MIG covers compute use cases only. For workloads where graphics are needed (or even the graphics APIs), you have to use preemptive scheduling, even on Ampere. Thanks for the correction! Shows how much I've really used it outside of "does nvidia-smi do the right thing, and can I map those to pods". I had assumed that, since nvidia-smi on Ampere did both GPU and CPU slicing, that maybe they found a solution which allowed them to sidestep all of the inherent problems with trying to share GPU memory, but too much to hope for. > No. It's gone on Gen11 and later. :/ And no replacement yet. I've been relatively distanced from the nitty-gritty parts of GPU virt for a couple of years, but how/why did the end up pushing for root SR-IOV support for Xe along with patches for ReBAR at the same time as they dropped this? https://www.intel.com/content/www/us/en/support/articles/000058558/graphics.html https://www.intel.com/content/www/us/en/support/articles/000... I guess they'll gate it behind enterprise dGPU SKUs when/if they ever release. Welp. > The OSS NV KM stack doesn't support GPU virt at all yet. I would have thought this also. As bad as the doc in the link is, it does explicitly reference OpenRM verification. I wouldn't trust nVidia's "big ball of hardly-commented source" for anything yet, but at least it is the "real" driver and not Nouveau, so I'd expect GPU virt to be supported, even if the code may be inscrutable. I'm really just waiting for the HN link to confirm/deny the long-held suspicion that nVidia suddenly got really good around the same time SGI was in its death throes, and that the reason they resisted opening their drivers was due to routines with... questionable IP.

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 ago
  Curious 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 ago
    I 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 ago

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 ago
Curious 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 ago
  I 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 ago