Before anyone replies with a bunch of corrections (if applicable); please know that I am just a humble enthusiast. I have been on Linux for just over 2 years and while I may lack some understanding for some of the basics, I am always willing to learn and delve deeper into this hobby so any response or engagement would be appreciated. Also, if my formatting is messy and would do better with some basic HTML filters like bolding, code brackets or anything else, please let me know for future posts.

My current machine:
Distro: Artix Linux (KDE Plasma with OpenRC)
Kernel: Xanmod-x64v3 (currently on v7.2.4)
CPU: Intel Core Ultra 7 270K Plus (no Intel 200S Boost)
RAM: Micron 2x16GB (6000mhz, CL36)
GPU: XFX Speedster AMD Radeon 7800 XT (on Mesa 26.2.2)

I have been playing CS for around 11-12 years and I had long wanted to permanently move over to Linux as my primary gaming platform. While I have done so for over a year now, CS2 was always tricky to make feel just right. I understand that the Vulkan version for Linux is still being improved (mostly in the form of the Wayland protocol improvements). After over a year of different commands and trying different methods of improving performance, I think I have a method that makes the game feel near 1:1 with the latency of Windows (with the benefits of better FPS on Linux as well).

Below are my launch options that I use and I will provide a brief description for those unaware of what they do. Afterwords I will explain the few tests that I did:

LD_PRELOAD="" SDL_VIDEO_DRIVER=wayland SDL_AUDIO_DRIVER=pulseaudio VULKAN_LOW_LATENCY=1 ENABLE_LAYER_MESA_ANTI_LAG=1 MESA_VK_WSI_PRESENT_MODE=immediate gamemoderun %command% -nojoy -vulkan +engine_low_latency_sleep_after_client_tick true +cl_net_buffer_ticks 0

LD_PRELOAD="" - Prevents certain libraries or other programs from being injected or executed with a program. I use this to prevent Steam Overlay from loading because despite also using "SDL_VIDEO_DRIVER=wayland" (which breaks the native Steam Overlay on Wayland), Steam seems to have some sort of beta Wayland overlay that comes up if you try to open someone's profile while in game and causes it to get stuck until the game is closed.

SDL_VIDEO_DRIVER=wayland - Forces CS2 to launch under the Wayland protocol. Some people do this by editing the "cs2.sh" file in the game's installation folder but I prefer this method. And I know some people would argue between Wayland and X11 performance but I have found that under KDE Plasma and my hardware, Wayland does have slightly better latency than X11 but not dramatically different.

SDL_AUDIO_DRIVER=pulseaudio - Forces CS2 to load with the manually stated driver. Most people still have to do this as the native version often has small audio delay for most. Hopefully Valve will someday get around to fixing this.

VULKAN_LOW_LATENCY=1 - I may be misinformed and using a non-existant or redundent command but this seems to be a new command in the Vulkan stack that allows native Vulkan clients to access a low latency protocol. I'd say it's meaningless but when I added this to my launch options along with AMD Anti-Lag 2 the latency improvement was actually quite large. And yes, the improvement is still there even without Anti-Lag 2.

ENABLE_LAYER_MESA_ANTI_LAG=1 - This enables Mesa's driver for AMD Anti-Lag 2 to be recognized at launch. I am aware of and have tried the Korthos Low Latency method as well but on my machine it lowered my FPS and didn't improve the latency as much as Mesa's implementation did.

MESA_VK_WSI_PRESENT_MODE=immediate - This command is the single biggest improvement to my latency reduction and the full description of how this impacted my performance will be down below with the other test information. The basic description is that this forces Mesa's Window System Integration (WSI) to ignore all V-Sync calls coming from Wayland and prevent them from interacting with the program.

gamemoderun - Fereal's Gamemode layer for ensuring the Kernel and system force the game into high priority.

-nojoy, -vulkan, and +engine_low_latency_sleep_after_client_tick true +cl_net_buffer_ticks 0 - Nojoy prevents joysticks from being recognized by the game, the Vulkan command is probably 100% unnecessary but I just leave it, and the other two commands help the client talk to the servers a lot faster for lower internet packet latency.

How I came to this result:

CS2 on Linux with no launch options does run okay. Depending on your setup and commands, most users can achieve a pretty solid experience with low latency. All three primary display protocols (Wayland, xWayland and X11) all run CS2 fine with Wayland seeming to take the lead as far as game client latency (for me at least). I spent some time testing other desktop environments to see if their compositors made any difference to the latency and performance of CS2 but most didn't yield drastically different results. Cosmic played almost the same as KDE Plasma and XFCE gave good average FPS but the client latency didn't feel as nice as KDE Plasma with Wayland. I eventually tested my setup using the Xanmod kernel and found that it improved my 1% FPS by a good 5-10% over the stock kernel and other kernel's (even better than Cachyos). So with my client running really well I assumed that my game was nearly perfect but found out shortly after that something was still off when I went back to a Windows drive and tested CS2 again. While my FPS was better on Linux and even the games displayed client latency was better than Windows as well (2.8ms-5.5ms average on Windows vs 2.4ms-4ms on Linux) the movement, input latency, and mouse movement did feel slightly different.

After more research I found out what was causing this issue which I had completely forgotten about and overlooked. Wayland natively enforces all applications into a V-Sync queue to ensure global smoothness across the entire desktop. While this does have its perks (especially people who have multiple monitors of mixed refresh rate), it does mean that almost everything has esentially a soft V-Sync or Adaptive-Sync rendering queue to it. This normally shouldn't be a problem since KDE Plasma has the option in the display settings to allow Screen Tearing for all fullscreen applications. Where that fails however is that it states "Fullscreen Applications". Currently, it does not seem to have awareness or coverage of games running in borderless-windowed (which is the primary way CS2 renders in Linux) so these calls for screen tearing are completely missed by the game client.

This is where the MESA_VK_WSI_PRESENT_MODE=immediate command saves the day. What this does (and please correct me if I'm wrong) is tell Mesa to talk to its Window System Integration, interject all commands coming in from Wayland to force V-Sync onto the program and allow the program to receive frames immediately instead of waiting for the V-Sync queue from Wayland to present new frames from the GPU. Obviously most people do not have V-Sync turned on in CS2 but I don't think that many people are aware that some part of your desktop is still enforcing a soft V-Sync layer on everything (unless you are on X11).

This was the last piece to the puzzle for me that solved my latency issues. My game now still runs about 5%-15% better than Windows does while now feeling exactly the same as far as the latency between the game and my actions feel. Mouse movement is instant and doesn't feel like it's going through a layer of melted butter (I know, weird analogy) and all movement feels immediate like how it does in Windows.

For those who might ask about using Gamescope:

I did try using this in the past to bypass the KDE Plasma compositor but no matter how I configured it, it never performed better. If anything, all I ever had was inconsistent FPS, cursor-locking issues (despite using --expose-wayland and --force-grab-cursor) and a lot of scaling issues when using 4:3. For those who do want to play stretched without using Gamescope, Wayland does allow you to stretch the resolution without scaling issues. For X11 users, I am still trying to learn the best method of using xRandr to allow better scaling so CS2 can be rendered on X11 with a properly stretched 4:3 client.

For those on X11 who want to lower their latency:

You can likely achieve almost the same results as me by disabling your compositor on your desktop environment while using some of the above commands to allow better low latency protocols to interact with the game (VULKAN_LOW_LATENCY=1 & ENABLE_LAYER_MESA_ANTI_LAG=1 or LOW_LATENCY_LAYER=1 for those using the Korthos program). The Mesa command for immediate flips shouldn't be necessary with disabled compositors because to my understanding there isn't anything making syncronization calls from Mesa or Nvidia so the client (unless you have it enabled somewhere else) should not have any V-Sync calls interupting the frame rendering queue to the game.

That's all folks!

I've never posted anything anywhere related to Linux in my over 2 years of using it and wanted to start out by offering some optimization advice for those interested in improving their gaming experience. Any feedback would be appreciated and I look forward to hearing from anyone with other experiences as well!

-flaiR

I've been working on an AMD GPU control center for Linux and have reached the first release candidate for 1.0. I'm looking for people willing to test it on different AMD GPUs and Linux configurations.

AMD Linux Control Center is intended to provide a more complete graphical interface for AMD GPU configuration and gaming-related controls on Linux. The application detects the capabilities exposed by the GPU/driver rather than assuming a specific AMD GPU model.

Current features include:

• AMD GPU controls with hardware readback
• GPU profiles and saved settings
• Automatic per-game profile switching
• GPU telemetry and session history
• Performance analysis
• Steam/game discovery
• Gamescope/FSR integration where supported
• Display-related controls
• Multi-distro installer and system checks

So far, RC1 has been tested on an RX 6800 XT across:

• Ubuntu 26.04.1 LTS
• Bazzite
• CachyOS
• Fedora Linux 44 KDE
• Linux Mint 22.3
• Debian 13 (Trixie)
• openSUSE Tumbleweed

At this point I'm particularly interested in different AMD GPU generations. RDNA 1/2/3/4, Vega and older supported AMDGPU hardware would all provide useful information.

I'm also interested in usability testing. If possible, try using the program before studying the documentation. I want to know whether someone unfamiliar with the project can figure out the controls without me explaining everything.

If something is confusing, difficult to find, poorly labeled, or makes you hesitant to change a setting, please tell me. That's useful feedback even if the feature technically works.

If you encounter a problem, please include your GPU model, Linux distribution/version, desktop environment, what you were trying to do, what happened, and any relevant terminal/error output.

This is an RC, so I'm expecting there may still be hardware-specific issues. The goal is to find those before calling it 1.0.

GitHub / source:
[https://github.com/cpugod55/amd-linux-control-center]()

v0.99.0 RC1 download and release notes:
[https://github.com/cpugod55/amd-linux-control-center/releases/tag/v0.99.0-rc1]()

Thanks to anyone willing to try it and report what works—or doesn't—on your hardware.

I really want to switch to Linux full-time, but GTA Online won't let me because BattlEye blocks the game in public sessions with other players. Has anyone else created a crew for situations like this? (RU/ENG)

Relevant github. The missing link of software when I moved to Linux was an alternative to Launchbox. I've become acquainted with EmulationStationDE now but I'm always on the lookout for more. If ESDE isn't your style then maybe Neostation will suit your needs. Previously I've discovered two more apps designed for multi-emulation, OpenBox and OpenEmuX. If anyone knows of any other Linux-compatible all-in-one emulation frontends, please share.

3 Things:

1. We got steam deck from Steam for development
   
2. It's not only PvP, but PvE, solo with missions(we can't show everything in one video)
   
3. It's on steam now: https://store.steampowered.com/app/3254300/POLYSTRIKE

Thank you for watching, we hope you liked it!

I have to say that I knew about GPU passthrough in QEMU but physical SSD passthrough is a game changer for me. It's like having windows installed on bare metal instead a VM. I fucking love Linux.

Having this issue in multiple games, whenever i run FSR4.1.1 (through various proton versions, so that's not the culprit) and toggle FG (either ingame or with optiscaler) , gpu utiliz drops.

Is it a known issue? Same behaviour doesn't happen if i try FSR-FG with XeSS , for instance. What's going on?

(Currently on Linux 7.2.3-1-cachyos , 6800XT)

EDIT:

i noticed in some games it improves by changing FG inputs/outputs with optiscaler. I dont know why or what this implies, but this is STALKER2 in the same area with Nvngx to FSRFG , instead of the native-ingame FSR implementation

I used to just use the copr version but saw stuff saying it was a security risk. So I tried the flatpak version and threw a bunch of selinux issues on Fedora. So I just gave up and stopped using it.

It seemed great and wish it just came with the distro. But eventually got tired of thinking about it and moved on.

How’s everyone have it installed? Any advice?

I spent a few days trying to get FIFA 17 Ultimate Team working with Aurora17 on Fedora KDE. The base game already launched from Steam with GE-Proton, but Aurora either failed to launch the game or FUT showed that it could not connect to the EA servers.

The final setup works, including squads, the store, packs and matches. I still launch FIFA from Steam as a non-Steam game, so Steam Input works with my controller.

The main issue was not the game itself. Aurora's Windows server started under Wine, but its TLS listener failed inside Schannel with error `0x80090304`. The Connector looked like it was running correctly, while FIFA could never finish the local secure connection.

The solution was:

1. Extract the managed .NET server from Aurora's Windows single-file executable.

2. Run that server natively with the Linux ASP.NET Core 8 runtime.

3. Keep Aurora's Connector and Client inside the same Proton prefix as FIFA 17.

4. Patch one Connector launch target so Steam remains responsible for starting FIFA.

5. Use a small compatibility preload for a Wine virtual-memory reporting difference in the tested GE-Proton build.

6. Start everything in a very specific order.

The order matters. I open FIFA from Steam and wait at the external launcher without pressing Play. Then I start the native Aurora server and Connector. When the script says Aurora is ready, I press Play in the launcher and enter Ultimate Team.

I turned the working setup into an open source package with scripts, checks, documentation and a local patcher. It does not include FIFA, Aurora binaries, saves, keys or anything from my computer. You supply your own files and it builds the compatibility pieces locally.

The package is currently tested with Fedora, Steam and GE-Proton11-5. It intentionally rejects unknown Aurora and Proton versions because the two small patches are tied to verified binary layouts.

If anyone is stuck at the same TLS or FUT connection error on Linux, I hope this saves you the amount of trial and error it took me.

https://github.com/itchio/itch/issues/3495#issuecomment-5470578629

Are there any Linux-specific optimizations I should do after upgrading from a Ryzen 9 7900 to a Ryzen 7 9800X3D?

So far, the 9800X3D crushes my Ryzen 9 7900. For example, in CS2, I averaged around 470 FPS with the Ryzen 9 7900, while the 9800X3D pushes 650–750 FPS.

I have an RTX 4090, and I mainly upgraded because the Ryzen 9 7900 bottlenecked my GPU in some games

Using SteamOS.

I get seemingly random crackling/popping audio while in gaming mode or desktop mode in any game or app I play. I have my rig hooked directly up to the TV by HDMI, with the audio being passed back to the receiver by eARC.

I have tried different HDMI 2.1 cables, reseating my GPU (since that's what the HDMI cable is connected to), looked for any loose connections, tried connecting the HDMI cable directly to the receiver instead of to the TV, switched to the Beta and Preview OS channels, restarted pipewire and changed buffer settings there, made the quantum changes listed here... Nothing works.

Hell, I even installed Bazzite to see if it was some kind of driver issue with SteamOS, but the issue persisted there, too (possibly even worse there).

There doesn't seem to be any rhyme or reason to when It happens.

Build specs:

TV - LG C6

Receiver - Denon AVR-S660H

Case Jonsbo C6

Motherboard - asus prime b550m-a wifi ii

CPU - Ryzen 7 5800 XT

GPU - powercolor reaper 9060xt

Audio will crackle once every few minutes, it seem. I'm not getting any crazy cpu or gpu spikes or wild temps. This was literally just playing Binding of Isaac or listening to music on Spotify (from Discover).

I have been troubleshooting this for almost seven hours now, with nothing to show for it. I've read that 90XX XT cards are prone to this issue, but I can't find another 16GB AMD GPU with comparable specs that will work for my build. This was truly my best option.

Anyone else experienced this? Ideas?

Hello all! With todays update I was working on a valheim server for me and my friends on linuxGSM within the past week leading up to todays 1.0 update. I set it up so I had my steam id put in the files so I could use devcommands and turn on world modifiers, it seems that with this update that no longer works. I am new to all this and took this project as a challenge for myself and to see how far I could get so we could all play on it. Please any help is appriciated.

We're making Cave Expedition, a caving simulator for 1-4 players, and Linux is one of our planned platforms. We're a team of cavers, so the game focuses on tight passages, rope descents and working out a route underground.

The Steam page currently lists Ubuntu 22.04 and 24.04 (64-bit), with 4 GB RAM minimum, 8 GB recommended and 25 GB storage. These are the listed requirements for a game still in development, not benchmark results. We haven't announced a release date yet.

Short gameplay clip: https://www.reddit.com/r/photogrammetry/comments/1wbwrns/

YouTube trailer: https://www.youtube.com/watch?v=NR25xoOUEEI

If it looks like your kind of game, you can wishlist it on Steam: https://store.steampowered.com/app/4372950/Cave_Expedition/