ArcVRArthur

Ya, libvf.io works on nearly all recent Nvidia consumer cards with the exception of Ampere. The same goes for Intel GPUs like the DG1/DG2. There is no need to use a server card.

Edit: There's not really an explicit need to trick the card. Nvidia co-wrote the VFIO-Mdev API with Intel and RedHat which is what we use. If you want to use the optional nv merged driver package that will do some of the things you mention but it's not required.

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

Ya exactly! Compatibility with QEMU commands right inside the yaml was a great addition by my co-author. I wrote an earlier version that lacked that functionality and I have to say the new version with that feature has proven really handy.

They have made the APIs open on all of their discrete GPUs going forward. I actually have an Intel discrete GPU board (based on the Intel's DG1 - Discrete Graphics 1) that supports GVT-g and all the same standard APIs we deal with. I think Intel is going to be a huge disruptor in the GPU market because of this!

The good news is that we also support consumer Nvidia GPUs and some consumer AMD GPUs as well. There are more limitations in AMD land than the other vendors but I'm hopeful that they will make some improvements across time.

That's actually a great idea!

Is there any documentation you would suggest I read to get started understanding NVMe namespaces?

We're also very open to feature additions/pull requests at our repo: https://libvf.io/ I'm very new to this whole thing of building an open source community but I hope if people find value in some of what they built that they might consider helping us with our code.

If you have any suggestions on how we could improve and build a good open source community I'd love to hear them!

We've been working on this for awhile and ya, I hope it is the start of something! If you want to read the logical origin point of where I started thinking about this project check this out:

https://arccompute.com/blog/why-computers-suck-and-how-openb...

https://news.ycombinator.com/item?id=21776370

We're not using Nvidia's APIs in our code! libvf.io is entirely based on cross-vendor, standard APIs. :D

The one that is a bit weird is AMD who is fairly far behind Nvidia and Intel but I think if they want to modernize support they can definitely do it. My hope is that consumers will start asking for this capability more (especially with Intel's ARC GPUs enabling GVT-g at every price point) and AMD will update their stuff to reflect that demand.

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. :)

I'm not entirely sure on how wide the vendor support is but I wouldn't be entirely surprised if they were upsetting some folks with it. Happily we're just a little team right now making stuff that's useful for ourselves so we don't have all the same pressures big companies have. I hope if we ever grow we'll act in the same spirit (I'll try my best to see that we do anyway).

I think Hyper-V is GPU-P is great! I think Microsoft's hypervisor team is one of the most talented in the world, and honestly I think I could learn a lot from them.

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.

vGPU_Unlock's Merged driver is an optional package you can include but if you don't want to use it there's no explicit dependance. We actually enable these features using a vendor neutral API called VFIO-Mdev:

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!

We're supporting Ampere in our own VPS cloud (arccompute.com) but there are some hurtles on getting it working on consumer Ampere gear in the nv merged driver due to changes in the use of SR-IOV APIs - that is to say Nvidia has now enabled SR-IOV whereas before they were doing their entirely different thing to achieve similar functionality. We've got SR-IOV APIs working with our use of mdevType: "sriovdev" in our yaml configuration layer so from our perspective it's already possible to use but unfortunately until the nv merged drivers work with Ampere we won't be able to do a lot on our end.. Right now I think the vGPU_Unlock guys are working on the 3090 and we'll be sure to support it once it's ready. I'll also try to remember to post about it on GitHub once I've tested it out for myself and confirmed our software works with it.

By the way, we're hiring GPU driver engineers and kernel hackers!

Please reach out to me if you know anyone who might be interested. My email is: arthur@arccompute.com

I have to pinch myself from time to time to remind myself I'm not dreaming. I honestly feel like I'm working on the coolest project in the world with some of the smartest people I've ever met. If you know anyone who wants to help us work on open source vGPU stuff please reach out to me at arthur@arccompute.com.

We're hiring!!!

arcd is actually the part of the program that you call in your shell to use our library's functions. Arc Compute is the name of our company so arcd seemed like a reasonable name. We also considered calling it vfd but so far we've settled on arcd.

All the source code for arcd is here: https://github.com/Arc-Compute/libvf.io/tree/master/src

:)

I got into writing this actually because graphics sharing was such a bad experience that I would usually run a Windows host and then Linux guests in something like VirtualBox or VMWare Workstation. I always wanted a host with fault tolerant guests but GPU sharing features seemed to be locked to "enterprise GPUs" and it wouldn't work on my consumer GPU. This solves some of those problems I was having and lets me run Linux on my host with a full performance Windows guest (at least for me it does).

We actually are a replacement for Libvirt that tries to simplify a few things. Take a look at LibVF.IO's user API. I tried to make it a bit more human friendly, like Docker: https://github.com/Arc-Compute/libvf.io/blob/master/example/...

Ya the lock out is absolutely arbitrary. There is zero physical difference between the consumer and server chips for these features. I think actually there's a lot of benefit to consumers by having these features enabled! I talk about that a bit here in our Xorg Developer Conference 2021 talk: https://www.youtube.com/watch?v=8pVrTyLqV_I

We're going to try to add support for more distributions in the coming days.

Right now we've got support in our install script for Ubuntu 20.04 hosts and arbitrary guest operating systems (Windows guests work best so far) but if people on GitHub are posting issues asking for support for other systems I'll try my best to get to those.

I'm going to try to add official support for Arch, PopOS, and Fedora as I know some people who I think would use it on those systems and a few others.

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...

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.

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

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.

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.

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.

GVT-g uses KVMgt. Intel has not yet upstreamed their patches.

I think the most reasonable solution to this problem is to not purchase Apple products for a few years given how they have responded to criticism and promoted the characterization of privacy advocates as "screeching voices". I was thinking of upgrading my iPhone given it's getting pretty old now but I can't really see myself doing that now.

Free open source software funded by donations is evil because it undermines Google’s ads business. Free must be free with ads, not free with donations. Richard Stallman was right. :^)

I agree entirely.

One of many. matrix.org/clients

Element.io rebranded from Riot.

This is very disruptive to me. Our business chose to use Element because of the privacy and interoperability functions it afforded us through end-to-end encryption and the bridges feature (matrix.org/bridges).