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.

Valve is one of the main contributors to the RADV Vulkan driver for AMD GPUs, and a bunch of other parts of Mesa and the open driver stack in general.

I should probably add that some of this work is on RDNA3 FSR4 support, which isn’t even supported on Windows. It’s not amazingly fast, but it’s now faster than native and that might be enough to make it worth it (especially in the cases where it improves image quality due to poor TAA implementations).

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.

It’s main benefit is compatibility. As you said fsync is a hack and can cause issues with some games and applications.

The other benefit is more about packaging and the like, in that you won’t have to deal with third party patches. Not an issue if you’re using Proton but can be if you’re using vanilla Wine.

Youtube varies from genuinely good content, to generic filler, to complete and utter trash, and there is much of the latter two because it’s not curated by anyone (other than by algorithms).

Try “We Own This City” from David Simon, if you want a documentary on the police that isn’t propaganda.

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

Your kernel must be patched with ntsync patches. If your system does not have /dev/ntsync then your kernel does not have the patches required to use ntsync.

It might also be compiled as a module, but not loaded by default.

sudo modprobe ntsync can be used to test this.

Intel provides solid Linux support, I’d say it’s probably on par with AMD.

I’d say in the long run yes, but they tend to be slower at adding features compared to AMD (which tends to be where all of the experimental stuff happens first). Or rather that AMD cards are often the first target for Mesa developers, which includes the likes of Valve.

I’m almost at the point where all of my connections are IPv6, but still hampered by my mobile provider (ironically, since IPv6 was generally adopted earlier on mobile in many countries).

I go even further and set the proportion to 100%, since ZSTD compresses so well (and the % is based on uncompressed usage).

There are theoretically some cases where zram can be harmful, but in general I find it works reliably.

This article on the repo is also an interesting read:

Porting LSFG to native Vulkan

Or to put it more eloquently: go away, 'baiting!

A bit of a downside is that the minimum driver requirements are pretty aggressive at the moment, so people could be stuck using WineD3D without realising it. But I suppose crashing isn’t really much better. And people who play games should use a distribution that moves pretty quickly in general.

I don’t have this controller but the Vader 4 pro was updated in the same update, and supports every single extra button + gyro at the same time, provided dinput mode is set.

Full compatibility means native steam input support, which means that gyro + back buttons work together. No need to emulate a specific console controller and lose out on either gyro or back button support.

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 looks like mainly a Hyprland fix (and maybe some wlroots based compositors). The old method still works with sway for me, and there’s a another approach using a virtual edid that should work everywhere, but perhaps not with Nvidia cards (see here: https://discuss.kde.org/t/how-to-create-a-virtual-monitor-display/2725/5).

I’m not sure if Plasma or Gnome have any support for headless monitors outside of the EDID method.

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.