Live data from Hacker News

Show HN: vGPU and SR-IOV on consumer GPUs

arccompute.com

11–20 of 82 posts

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#11
I'm familiar with linux virtualization, gpu passthrough, etc. I've never heard of arcd and they've made no attempt in this doc or on their git to explain what it is or why it exists as, I assume, a replacement (or wrapper?) for qemu.

My past experience with looking-glass is that it falls on its face at anything > 1440p@60Hz. I'm interested in vGPU for my linux VMs (spice is slow and sdl/gtk display is flakey) but for gaming, I don't want looking-glass and prefer to just do the passthrough thing with a KVM switch.

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#12
post #9

Great! Still requires vGPU support and the merged driver approach last time I tried won't support CUDA on host (I was probably the first one tried the merged driver thing with vgpu_unlocked?). Looking forward someone write a Vulkan driver on Windows that just shuttles down to the Linux host. virgl used to be a promising project ...

I CUDA does work on the host in our testing. :) We also run Vulkan/DirectX/OpenGL at full performance in the guest! It's WAY faster than Virgl.

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#13

I'm familiar with linux virtualization, gpu passthrough, etc. I've never heard of arcd and they've made no attempt in this doc or on their git to explain what it is or why it exists as, I assume, a replacement (or wrapper?) for qemu. My past experience with looking-glass is that it falls on its face at anything > 1440p@60Hz. I'm interested in vGPU for my linux VMs (spice is slow and sdl/gtk display is flakey) but for…

We are still trying to make the documentation better. We're actually hiring right now so if you can recommend someone who might be able to help with that I'd love to talk to them. :)

Also looking-glass is an option under introspection: in the yaml. You can use whatever type of virtual display you like best. We chose looking glass as the default because in our testing it was the most performant.

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#14
post #7
post #6

This is insanely impressive. Having tried set up GPU passthrough in proxmox a few years ago, it was an absolute disaster. I would love to see this kind of approach more widely supported by other hypervisors! It's a real shame consumer GPUs are arbitrary locked down when the enterprise counterparts (often with the exact same chip) have much better support for virtualization.

The enterprise versions of these products have a lot of bugs and gotchas because so few use the feature.

I'm making this because I had the same problem. My hope is that we can move the needle a little bit.

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#15
post #3

Note Intel GVT-g is only available on <=Gen9 GPU's. Gen11 and 12 are not supported.

It also works on Intel's ARC and DG1/DG2 discrete GPUs. Our software also works on most consumer Nvidia cards and also some consumer AMD cards.

Do you have any specific knowledge of Intels support for graphics virtualization on ARC GPU's?

What are the security implications of LibVF and would it be compatible with the QubesOS security model?

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#17
post #7

Earlier quoted context omitted.

The enterprise versions of these products have a lot of bugs and gotchas because so few use the feature.

I'm making this because I had the same problem. My hope is that we can move the needle a little bit.

As far as I'm concerned anyone that's working of virtualized GPU is doing the Lord's work.

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#18
post #15

Earlier quoted context omitted.

It also works on Intel's ARC and DG1/DG2 discrete GPUs. Our software also works on most consumer Nvidia cards and also some consumer AMD cards.

Do you have any specific knowledge of Intels support for graphics virtualization on ARC GPU's? What are the security implications of LibVF and would it be compatible with the QubesOS security model?

Ya, they are enabling GVT-g on all their GPUs going forward including the ARC branded devices (not just the embedded GPUs with Xe branding). They have no plans to lock out those features on consumer devices. In fact I bought a $700 computer from Best Buy that had an intel discrete GPU in it for development. :)

Ya, I have been talking with the Qubes guys. I'm trying my best to figure out how I can help them ship something with LibVF.IO but they are currently based on Xen which uses Libxl rather than VFIO which may present some challenges.

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#19
post #16

Very impressive. You should also post this to the Level1Techs forum

Wendell tweeted about LibVF.IO and it made my whole month haha: https://twitter.com/tekwendell/status/1449054328766013440

Also I posted in the Level1Techs forum! https://forum.level1techs.com/t/libvf-io-a-commodity-gpu-mul...

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#20
I tried doing this years ago, and never quite go it to work.

Some of the software involved in that article simply didn't exist yet, and GPUs weren't shipping with SR-IOV support yet (instead, I did Intel iGPU for Linux fbcon, real AMD GPU fed directly to the Windows VM with PCI-E Passthrough). In the end, I bailed on that dream and moved the Linux install to its own smaller machine, and ran Windows bare on the big machine.

The problem was, if the GPU locked up hard, and GPUs back then would not respond to PCI Device Reset, if it wasn't something that merely re-initializing it on VM restart would fix... I had to restart the entire machine, thus defeating the purpose of having Windows in the VM in the first place!

All my long-lived processes now run on the stand-alone Linux machine, and anything that is free to explode runs on my Windows machine. Windows gets wonky? Restart, ssh back into my screen sessions, reopen the browser, restart a bunch of cloud slaved apps, tada.

Post reply on HN