u/Interject_

The problem is how the overlay is injected into games and how it interacts with input capture etc, not what is used to render Steam's UI.

Basically every game ships with builtin upscaling options these days, and those look way better (thanks to being temporal upscalers with access to motion vector information from the game) than FSR1/other basic spatial methods through something like gamescope or lossless scaling

There is MangoHud for this. There's no reason to duplicate the effort that project has already put in. And injecting into everything globally is nontrivial - you need a Vulkan layer for VK (including translated DirectX) games, and specific library preloading for OpenGL. But either way, this is a solved problem with MangoHud

That's just the GUI, you don't need it running to keep the settings applied, and the daemon does not hold anything graphics related allocated so it will not use any VRAM.

LACT supports this (I added the functionality specifically for the Arc encoder card use case)

Don't buy Intel if you intend to play games on Linux, it will have worse performance disparity with Windows than on your post.

I have the same laptop and the same issue with the default WiFi adapter, and I'm considering swapping it with an Intel adapter from an older laptop. Do you know if this procedure voids the warranty?

It depends on the age of your CPU. On chips that have been designed after the exploits were known, disabling mitigations might reduce performance, since the CPUs were intended to always be used with the mitigations on (as that its the default for most people).

/sys/class/drm/card1/device/rom isn't the whole VBIOS, if you want to truly compare them on linux you should dump it from /sys/debug. LACT has a feature for a VBIOS dump, I don't remember the whole path off the top of my head to do it manually.

It does seem possible that the difference is hardware and not VBIOS though.

Enabling DLSS framegen in-game forces Nvidia Reflex to also get enabled, which offsets part of the latency increase. I don't believe you can use Reflex without the game integrating it.

ARM is not magically more power efficient, it just focused on low power usage designs for decades, so they tend to perform better than x86 chips scaled down to low power. For a desktop/workstation use case you can already buy ARM today such as various Ampere CPUs and Nvidia DGX Spark, but they aren't anything special power efficiency wise, and are similar or worse than recent AMD and Intel chips.

I hate when people say this as someone who specifically uses plain GTK4 without libadwaita so the UI is desktop-neutral and follows the system theme, yet people still complain about GTK and how it's the devil.

It has its issues, but GTK apps (either plain or libadwaita) at least tend to look correctly outside of Gnome, while theming QT apps is a huge mess outside of KDE, since QtWidgets and QML use different theming types. Though there is work being done by KDE to unify it.

"Performance" is a very broad term, the impact will hugely depend on what you are measuring and on what hardware.

A notable difference in the cachy kernel is that it uses the BORE scheduler (by default, other options are available) which prioritizes interactive tasks over what's deemed as "background" work. This is beneficial on a desktop system, and means that the desktop and your applications are less laggy when some CPU-heavy task such as compiling is running in the background. The default kernel behaviour aims to cover a wide range of use cases (desktop/server/mobile/embedded), so there are benefits to be had with a more specialized build.

There is also an option to use alternative schedulers defined in userspace with sched-ext, and this can be used on a recent upstream kernel as well.

A bug that caused GTK 4 applications to crash when using the Vulkan backend on Wayland has also been fixed.

In reality it's the opposite, with 580 all GTK4 applications hang indefinitely when closing windows

Have you tried using the xe kernel driver instead of i915? It's possible that it might have other issues as it's not the default, but Meteor Lake is the last target that defaults to i915, everything after it uses xe by default. Could be worth trying out: https://www.kernel.org/doc/html//next/gpu/rfc/xe.html#xe-platforms

Kill gnome-software, it's a resource hog even in the background.

They mostly work, but the gaming performance and compatibility is far worse than the results you see on Windows by a big margin. The B580 is a pretty good card there, but it's not really worth it on Linux, and I would not recommend A-series for gaming under any OS as they have hardware design flaws that cause them to significantly underperform in some scenarios.

All Intel cards are very good at video encode/decode and generally work fine for display output, but for gaming on linux you should get AMD or Nvidia instead. A 9060XT 16GB would be a good target, although it's noticeably more expensive than a B580. Maybe you can find a used 7800XT or similar for a good price.

This might change if ANV (Intel's Vulkan driver on Linux) gets significant improvements, but for now that's the state of things.

This isn't needed on a normal system, AMD BC-250 is basically a Playstation 5 chip that didn't make the cut, and was released as a crypto mining board. They no longer make sense for crypto mining so there's a good amount of them on the second hand market, and people are trying to run games on them. It's not quite a normal system CPU and GPU-wise so it needs these extra tweaks.

Should be resolved now: https://github.com/ilya-zlobintsev/LACT/commit/ba5ee6b910799dea741277bd68917117925d0b58

Functionality such as display or colours configuration is indeed not possible to implement, as it is only exposed through an Nvidia-specific X11 extension. This uses the nvidia management library, which is largely made with datacenter GPUs in mind. It doesn't have any graphical session requirements, and does support clockspeed/power limits/fan control on desktop cards as well.

You can use LACT as an alternative to CoreCtrl. There is also an option to set it manually through the SysFS: https://wiki.archlinux.org/title/AMDGPU#Manual_(default)

You don't need to enable overdrive to lower the power limit.

ConTroller

There are some issues with RX 6000 series GPUs which did not pop up during previous testing, it's being worked on currently. See this issue for more info