Not CPU limited, actually the opposite. It targets games where the CPU is frequently waiting for the GPU to catch up. It fixes a defect in the AMD pstate driver’s active (EPP guided) mode that would cause the CPU to be treated like it’s idle if it’s often taking short sleeps, even if it’s actually quite busy.
sparkling arch, sparkling fedora, and diet arch
Arch teaches you to exercise muscles that would otherwise atrophy. Understanding how your system is put together, how to diagnose and fix problems, how to handle upgrades safely. It becomes just as easy as any other OS and you’re better off for it.
That doesn’t follow. What I think you mean is that by defining the constraints so rigorously, you’ve basically solved the problem yourself. But that’s exactly the point. The LLM isn’t the problem solver, it’s the execution engine that does the wiring-up and the ticking of boxes. The easy part, arguably, sure. But still considerable effort that can be saved, and that effort may be better spent on the problem-solving + constraint-defining stage.
Mandatory disclaimer that this is not a pro-AI post. I also don’t agree that this setup works, anyway. It’s a classic Bob Martinism, the idea that writing good enough specifications makes the implementation irrelevant; it’s the type of idea that is allergic to reality
The 3ms figure is nonsense anyway. 2ms of that is just bad scheduling/presentation config that disappeared when using dxvk-low-latency. Use native wayland or Gamescope+WSI and you’re within 1ms of X11 generally.
It would be trivial to add online only drm with a killswitch to physical media. If that’s the problem, discs aren’t the solution. What we actually need is legal protection for consumers.
update your system
delete your game’s wineprefix, it’ll regenerate and may fix issues from changing versions
lutris is not likely the issue unless you’re using its runtime and something is clashing with it. With proton-cachyos-slr, you should have lutris runtime disabled and prefer system libraries enabled. See here: https://wiki.cachyos.org/configuration/gaming/
wild guess, but new versions of proton-cachyos use ntsync by default which requires a kernel module that may not exist in your older system. I’m not sure if it falls back to fsync in this case, but that could cause issues. System update fixes this.
if you’re on wayland and using PROTON_USE_WAYLAND, the change to proton 11 may have broken some games. These typically would be crashes / white screens rather than lag. In this case you can disable PROTON_USE_WAYLAND or use the older proton 10 based version of proton
Gullikit ones generally have this functionality
A bit of friction when going off the beaten path is generally a good thing. Some people always take this too far though
Official support is a higher bar than “we did the bare minimum to make sure it’s theoretically possible for Proton to run it.” They’re probably just doing a little testing to make sure everything works decently before endorsing their product on Linux.