US only I suspect, and likely to be gutted by the Trump administration.

I’m not really an expert, but I’ll try and answer your questions one by one.

Don’t VMs have a virtual GPU with a driver for that GPU in the guest that, I imagine, forwards the graphics instructions and routines to the driver on the host?

Yes, this is what VirGL (OGL) and Venus (Vulkan) do. The latter works pretty well because Vulkan is more low level and better represents the underlying hardware so there is less of a performance overhead. However, this does mean you need to translate all APIs one by one, not just OGL and Vulkan, but also hardware decoding and encoding of videos, and compute, so it’s a fair amount of work.

Native contexts, in contrast, are basically the “real” host driver used in the guest, and they essentially pass through everything 1:1 to the host driver where the actual work is carried out. They aren’t really like virtualisation extensions as the hardware doesn’t need to support it AFAICT, just the drivers on both the host and the guest. There’s a presentation and slides on native contexts vs virgl/venus which may be helpful.

Where in that does Magma come in? My guess is that magma sits in the guest as the graphics driver and on the host before Mesa, but I know little about virtualisation outside of containers.

To be honest, I don’t fully understand the details either, but your interpretation seems more or less correct. From looking at the diagram on the MR it seems that it’s a layer between the userspace graphics driver and the native context (virtgpu) layer on the guest side, which in turn communicates with another Magma layer on the host, and finally passes data to the host GPU driver, which may be Mesa but could also be other drivers as long as they implement Magma.

The broader idea is to abstract implementation details, so applications and userspace drivers don’t need to know the native context implementation details (other than interfacing with Magma). And the native context layer doesn’t need to know which host gpu driver is being used, it just needs to interface with Magma.

The other points have been answered, so I’ll try and give a surface view of Magma. It’s basically an abstraction layer for virtual GPU drivers used in VMs. Currently, you need specific implementations to handle all of the pathways between different types of VM guests and hosts, which gets complicated fast, and duplicates a lot of work. The idea is the Magma abstracts this away, and so host and guest GPU drivers only need to interface with Magma. Which means you can swap out different host OSes/GPU drivers and different guest OSes and GPU drivers, and as long as they interface with Magma, they should “just work”.

Of course, whether it will work out that way in practice remains to be seen. I think Google is using it internally but it’s not in Mesa yet, so it may not even roll out widely. You can follow the MR if you want more detail or to see its progress.

If you’re wondering why Google is implementing this it appears to be for Fuschia and Android, and compatibility between those two and with desktop Linux, with Windows support also supported as an additional value add. Chromebooks in particular should benefit from this, since ChromeOS is being retired I believe.

And as an aside, unlike some of the traditional GPU implementations you’d find in VMs, these are or will be pretty much just the normal graphics driver that you’d use on the host. They are generally called “native contexts” and have been implemented for AMD and Intel at the least, but only on non-Windows systems for now. These implementations alone, once they are widely supported, should result in near native GPU performance in VMs, without having to use GPU passthrough (I.e. passing through a physical GPU to the VM guest). So even without Magma there’s some promising stuff happening, albeit mainly on the Linux host -> Linux guest pathway.

I’m guessing it’s the AI agent stuff. Which at the moment is literally just automating browsing through a website.

Apparently there will be APIs to do this in the future. Ironically, AI wouldn’t even be needed for that to be useful.

mpv supports Dolby vision (along with the Jellyfin clients that depend on it), but if you mean with streaming services, that’s unlikely to happen due to DRM.

Neither Reddit nor Lemmy are monoliths. Yes, some are likely being hypocritical, but it’s also likely that there isn’t much overlap between those that were critical of Nvidia’s FG and not of LSFG. I say this because there is still a lot of people shitting on FG in general, whether it’s justified or not.

Another useful use case is that the tool works on videos with mpv to interpolate to a higher frame rate. I know that subjectively not everyone likes that for film, but for footage that doesn’t rely on sets and the like such as sport and Youtube videos it’s a nice improvement.

In terms of quality vs performance, I’d say it’s somewhere between the lower quality SVP default and the higher quality (but very resource intensive) RIFE implementation. There’s also LSFG_PERF_MODE=1 and decreasing the flow rate, but the former was a pretty obvious decline in quality, but might be needed on slower GPUs.

EDIT: Another piece of advice I’ll give is to set PROTON_USE_WOW64=1 if you’re trying to run a 32-bit game, as there isn’t a 32-bit build for lsfg-vk at the moment. The env above allows 32-bit games to use 64-bit dependencies, provided it’s a Windows game and you use a recent version of Proton (Experimental and likely Proton GE 10 or greater).

Yes, although the approach that was fixed only applies to Hyprland and some other wlroots compositors. You can use the virtual edid approach on other systems, but it may not be supported on Nvidia GPUs. You can also use it as a simple supersampling method, such as rendering at 1600p to a Steam Deck, for example.

It’s so LFC works properly. If there isn’t a large range to work with, you can end up with gaps where VRR doesn’t work, causing stuttering or tearing. LFC is needed in general because you want VRR to still work when FPS drops below the minimum frame rate. And while it’s more of an issue with OLED displays there can be negative side effects such as flickering if the display minimum refresh rate is set too low.

The 120Hz refresh rate doesn’t seem to make a lot of sense if frames can’t even transition at a rate that keeps up with it.

The main use is for VRR, with bigger ranges making it more usable (and input latency should improve, but few games are going to run at 120fps). However, it seems like the feature is mostly broken in retail games, with it only really working in that paid tie-in game.

The original impetus to do these comparisons was that there were reports of significant motion blur on the Switch 2, so comparing it was the whole point.

And indeed, it’s even worse than the original LCD Switch display.

I thought it was clear from context I was talking about X.

Most of those are lesser evils compared to X, and that’s probably the best you can hope for. And Bluesky is the obvious alternative lesser evil choice if you want a like for like replacement and aren’t open to Mastodon.

If you’re technically inclined, self-host navidrome or jellyfin.

If you just want music and don’t care about the streaming part, bandcamp (although it does have some basic streaming I believe.

If you want streaming and aren’t technically inclined, Tidal.

I get where you’re coming from, but it’s not like there aren’t multiple obvious alternatives (and not just on the fediverse). And someone being clued in enough to boycott Spotify should have no trouble finding those alternatives. Additionally, the platform being owned by an outright Nazi should give even the most out of touch people pause.

But agreed that people could stand to be a bit more tactful about it and not immediately go on the attack.

Not to mention giving 100s of millions of dollars to fund Joe Rogan and his extreme right-wing propaganda.