Had to do a few doubletakes on this, but even with the recent hacks and progress on NVIDIA releasing Tegra source code, I didn't expect this for another few years.
Holy shit.
It's even licensed as MIT.
Even OpenBSD could conceivably port this with enough manpower. Adding enough just emulation for the userspace driver would be a lot easier than maintaining a complete linux emulator.
This is one of the biggest things to happen to hardware support for open source OSes in well over a decade.
Presumably market segmentation. You're only allowed VMs that dont feel like shit (i.e. have gpu accel) if you pay for enterprise vGPU shit. Can't have someone buy two of your GPUs to give one to a VM, obviously.
For AMD the driver is difficult to find and poorly documented (and only available on ESXi unlike NVIDIA vGPU support for Xen, Hyper-V, KVM, Nutanix, and ESXi, etc.). At least the guest drivers don't have licensing issues unlike with NVIDIA IIUC.
Plus the quality of the overall experience. And I understand NVIDIA is even worse re: GPU virtualization.
The end result is that it is unusable in practice. Very difficult and restricted to few CPUs/GPUs and very specific software chain.
Otherwise, it'd be open source, universally available and trivial to use.
The good news is that I understand this support is actually good on the Intel side, and Intel has promised that they will actually release competitive GPUs soon. Should this truly be the case, it will automatically make Intel the go-to for GPU virtualization, and might help motivate NVIDIA/AMD to stop segmenting re: GPU virtualization, ending this shitty situation.
And it’s locked out from most AMD SKUs today, so even if you got a modern GIM driver, you’ll need very special SKUs to enable it and use virtual GPUs.
> The good news is that I understand this support is actually good on the Intel side
Not anymore. GVT-g is gone on Ice Lake (Intel 10th generation mobile, 11th gen desktop) so that you can no longer do hardware vGPU on newer Intel parts at all.
Sad thing is that what you said used to be true.
Meanwhile NVIDIA GRID needs licensing fees but actually works, with high end GPU options being available. And has all the fancy stuff like vGPU live migration for seamless maintenance too. It doesn’t even compare.
Given the recent moves by Nvidia I wonder if they'd consider the holy grail of passthrough: Officially supporting (even a single) vGPU on linux so that you could use the card on the linux host and a guest.
The tech already seems possible since people have modded the enterprise drivers to do it, but that isn't official support. A few years ago I would have said there was no chance of this happening from nvidia. But I was also hopefully Intel's dedicated GPUs would support GVT-g back then!
Wow, I hadn't heard that AMD added that check. Between that and their unending reset problems that makes them a completely inferior choice for GPU passthrough. Before Nvidia stopped the passthrough blocking you could make a case that AMD was a better choice.
It's fair to extrapolate because their strategic decisions will be based on extrapolations.
NVIDIA had to overclock and hustle the current generation of cards and it's looking even worse for the next generation. Software was a moat when AMD was heavily resource constrained, but now they can afford the headcount to give chase. Between the chip shortage and crypto, there was plenty of noise on top of fundamentals, but one doesn't make strategic plans based on noise.
This is all speculative, of course. I'm sure if asked they would say it was a total coincidence. Just like AMD and Intel switching places on their stance towards overclocking. Complete coincidence that it matches the optimal strategy for their market position -- "milk it" vs "give chase." Somehow it always seems to match, though, and speculation is fun :)
I wish my company were in the same desperate situation as Nvidia. One where we’d be faster than the competition with similar perf/W while using a much inferior silicon process…
The difference is getting blurry. Apus have generally better communication/latency/shared resources with the CPU.
The ultimate ideal of an APU is to have a unified memory with the CPU, which is the case in e.g the PS3/PS4
Despite progress in heterogenous computing (the neglected HSA), in SOCs, 3D ingerposers, high bandwidth buses interconnects and 3D memory such as HBM, the PC platform has yet to see a proper APU. In fact the M1 is probably the closest thing to an ideal APU on the market.
But yes the more time pass, the more the term IGPU denote APU.
AMD bought ATI because of the fusion vision, the idea that sharing silicon, resources and memory between the CPU and the GPU would be the future of computing.
An unrelated but very underrated is the egpu.
Egpus are external to the pc unlike a dgpu.
So you can buy a thin laptop, connect it via Thunderbolt to a rtx 3080 and enjoy faster gpu performance than allowed on any laptop on the market, and enjoy a thin lightweight, silent laptop the rest of the time.
Disclaimer Thunderbolt is still a moderate limiting factor in reaching peak performance.
Wat. AMD literally invented the term 'APU' and has been shipping them since 2011. Fully unified CPU+GPU memory since 2014's Kavari. That's full cache coherent CPU & GPU along with the GPU using the same shared virtual pageable memory as the CPU.
It's a spectrum. I don't think that cache coherency was useable by developers/compilers. The two only ways I know (HMM and HSA) are niche, used by nobody.
GPGPU compute would GREATLY benefit from programs that can share memory between cpu and gou without having to do needless high latency round-trips and copies.
So they failed in practice.
They never did a CPU addressable HBM interposer (despite having invented HBM) unlike what I believe is the M1.
> An unrelated but very underrated is the egpu. Egpus are external to the pc unlike a dgpu. So you can buy a thin laptop, connect it via Thunderbolt to a rtx 3080 and enjoy faster gpu performance than allowed on any laptop on the market, and enjoy a thin lightweight, silent laptop the rest of the time. Disclaimer Thunderbolt is still a moderate limiting factor in reaching peak performance.
Not just for laptops: this sounds also a bit like what the Switch dock could have been.
(And in some sense, it reminds me of Super FX chip for the SNES.)
APUs are AMD-speak for CPU and GPU on the same die (Intel has similar but doesn't call them that). Integrated graphics cards (a misnomer since there is no card -- IGP or iGPU is probably more accurate) may or may not be on the same die (instead could be on the motherboard, particularly in the chipset). That design is pretty rare/antiquated at this point though. Being on the same die means higher bandwidth, lower latency, etc.
Just had my first graphics stack issue since 2013 upgrading to Fedora 36 and was caught flat-footed. I've got multiple GPUs, so now I've got to figure out if it's Wayland, amdgpu, nouveau (since unblacklisting), or dkms. "Just working" has made me lazy.
Was in similar boat recently, I'm not that up to day with the whole X11 vs Wayland, but dammit am I mad !
I feel like JUST as the "Linux X11 Discrete Graphics Scenario" started to become more stable and less (not none, but less) of an issue to setup and upgrade without getting black screens, the Linux-world is now turning to a "new windowing server" i.e Wayland, we starting all over again sigh
Maybe the answer to having a decent and carefree discrete graphics Linux stack is to fork (Don't you dare link to the XKCD comic about 'Standards') SteamOS.
They are at least motivated (as it's part of their core product) to make it work most of the time. And have a done boat load of good work for Linux ecosystem. Well done guys ! :)
>. Adding enough just emulation for the userspace driver would be a lot easier than maintaining a complete linux emulator.
OpenBSD it's the best BSD on support for free (Intel) and semi free drivers such as the ones from AMD, they already adapted all the src from Linux, KMS included.
That's very different. The source code for the userspace portions of the MESA drivers for AMD/Intel are released under a permissive licenses, so OpenBSD (and other BSDs) have been able to modify them to compile under their OS (and get those changes committed to the original tree). With NVIDIA, the userspace portions don't use MESA, so would need some form of translation layer to work on an OS other than Linux.
But, said translation layer would have limited scope; so is a lot more feasible than maintaining a general purpose translation layer indefinitely.
Nvidia have always shipped closed-source drivers, despite AMD and Intel providing open source drivers for their GPUs. This made the experience on Linux second class to Windows, where while also closed source, at least you knew that bugs would probably get fixed. Various non-core features simply wouldn't have support on Linux, e.g. Optimus. Also, shipping closed source binaries would limit which kernel you could run to supported versions.
Lastly, of course, this opens the way to non-Linux OSes receiving support as well.
If you just search the web for "Nvidia issues Linux" you'll see quite a few complaints. Particularly from people who have obscure configurations -- they pretty much had no chance of getting anything to work.
>If you just search the web for "Nvidia issues Linux" you'll see quite a few complaints.
I'd wager that is the BULK of the linux-power-user complaints. I'm definitely never buying NVIDIA again for my next PC. The last time I decided to go for Nvidia was because of their CUDA/ML eco-system.
Next time I'll just use the cloud for any ML/GPU-computing.
The amount of time wasted by nvidia-driver nonsense is actually absurd !
Holy shit.
It's even licensed as MIT.
Even OpenBSD could conceivably port this with enough manpower. Adding enough just emulation for the userspace driver would be a lot easier than maintaining a complete linux emulator.
This is one of the biggest things to happen to hardware support for open source OSes in well over a decade.