Does this also work for CUDA (e.g. deep learning jobs)?
CUDA works on the host. Stay tuned for more info about guest CUDA from libvf.io ;)
Show HN: vGPU and SR-IOV on consumer GPUs
71–80 of 82 posts
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#72Really hoping AMD eventually does the right thing here. Not that it particularly matters seeing as how decent AMD video cards have been unpurchaseable for 18 months now. Consumers should have the ability to use their hardware well too. Selling the same thing at 2X the price differentiating only on virtualization capabilities is not a moral path. > We remain hopeful that AMD will recognize forthcoming changes in GPU v…
I am disappointed in AMD. I bought AMD for Linux but when it comes to vGPU they don't give a shit. Intel was the leaders who made this semi-mainstream.
It is very disappointing for sure. I think the best thing we can do right now as users and developers is to make our voices heard and to ask AMD to support VFIO-Mdev on consumer GPUs. If enough people ask I think they will dedicate the energy to supporting these new open APIs as the other vendors now have. We have to be clear that we want this on consumer gear, not some artificially locked out server card where they have relegated these capabilities to with zero technical reason to do so.
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#73Just to clarify because I've failed at doing pretty much the setup that you are describing with my 1080Ti. Does this still require the vgpu_unlock changes for Nvidia cards or is this something that bypasses the need for it entirely?
My main development rig actually uses a 1080Ti! The normal vGPU_Unlock steps aren't a part of the user setup process, rather the optional merged driver package is built with a C version of the code that's been prepackaged. If you decide to use the vGPU_Unlock merged driver option during setup you won't have to do the (somewhat intense) process of vGPU_Unlock setup, you'll just skip straight to the end result. :)
Why is it optional? Why would someone want the option to use it if it’s not required?
Sorry I don’t understand well. A lot of jargon is being throw around and I haven’t touched this topic much once I got my pass through setup working
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#74Earlier quoted context omitted.
It would be helpful to note that Intel GVT-g is a dead end with 10th gen Comet Lake being the end of the road[0]. They do not support it with XE and have instead decided to go with SR-IOV. 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/2f111a6f…
Based on my reading of the link you provided I don't believe support for GVT-g has been removed. You can see the GVT-Linux repository is also still receiving commits: https://github.com/intel/gvt-linux
To be clear, I never said it was dead, only a dead end.
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...
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#75Earlier quoted context omitted.
Based on my reading of the link you provided I don't believe support for GVT-g has been removed. You can see the GVT-Linux repository is also still receiving commits: https://github.com/intel/gvt-linux
To be clear, I never said it was dead, only a dead end. 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 h…
Was on a call with Intel last week and they specifically confirmed there are no plans to bring GVT-g back. :-(
Makes sense as in servers you probably want static partitioning anyways, but for desktop it was perfect.
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#76Earlier quoted context omitted.
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 somet…
Just last week Intel confirmed to us that GVT-g is dead with their iris/xe generation of graphics and won't come back. Are you sure you didn't mean GVT-d?
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#77Once this is running on NixOS I'll be all over it. Great news!
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#78Earlier quoted context omitted.
> sdl/gtk display is flakey How is it compared to spice/qxl - does it have some advantages?
In my case with 4k monitors and virgl, it's substantially faster and a desktop env feels native. Spice feels quite laggy to me. The downside is that the sdl or gtk interface is coupled to the running vm and if they crash, the vm goes too. And in my experience, they crash a lot. I've been unable to get a two monitor setup working with either the sdl or gtk display but it works fine via spice.
I'd like to try this combination sdl+virgl that is better than spice, how do I force it on qemu? Like this?
https://www.collabora.com/news-and-blog/blog/2019/08/28/virg...
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#79Earlier quoted context omitted.
Based on my reading of the link you provided I don't believe support for GVT-g has been removed. You can see the GVT-Linux repository is also still receiving commits: https://github.com/intel/gvt-linux
To be clear, I never said it was dead, only a dead end. 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 h…
If they switch GVT-g for SR-IOV that shouldn't affect the use of VFIO-Mdev on consumer devices (the primary API we use).
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/drive...
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.
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#80Earlier quoted context omitted.
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 somet…
Just last week Intel confirmed to us that GVT-g is dead with their iris/xe generation of graphics and won't come back. Are you sure you didn't mean GVT-d?
Do you have a source for that intel confirmation?