Hello world, kala with a64
Well, I say it's time we finally settled this. What gets you more fps in CS2? Windows or Linux? We all know that all the pros play on Windows and all the big tournaments are played on Windows but why was the Linux version of the game foresaken? We're here to help answer these questions and even if the results might seem predictable we will also explain and speculate on to what lead to our conclusions.
First things first I have a few things to address regarding os trends and also techinacalities in regards to out testbench and methodology in order to be fully transparent as to how the numbers were achieved. Lets us start with a summary of why all pro players and tournaments are on Windows. The most obvious reason is the nVidia driver situation that until very recently was dire on the Linux side but it has gotten better in recent times. Another reason is HID as in human interface device support because very few peripherics manufacturers that require 3rd party applications to function provide these applications for Linux. Third party anticheat support is also a major Linux deterrant for obvious reasons and all of these put together result in non existing adoption. In this video I will also point out some other major reasons Linux is to be avoided for now but also the advantages that it brings.
Okay lets move on to our testbench and I want to say that I am aware that the hardware we will be testing on is not at all reminescent to what anyone plays CS2 on in 26 and obviously a X3D with Blackwell graphics would constitute a better performance difference indicatior between Windows and Linux in the current context so feel free to take the results with a grain of salt and use this information to build on your own opinion on this matter. Right, back to it; the testbench is the system that we ran for the Are six cores enough in 2025 video minus the GPU so check out that video to learn more about it. We are running a mild overclock for the CPU and ram and I'll talk more about the GPU later on.
One more disclaimer, the Windows we will conduct testing on isn't really your typical Windows. We wanted to give Windows a best case scenario or a fighting chance to put it better so we are using the in house 1 gig Windows as in Windows 11 that idles at 1gig of ram. Please check out the Windows 11 on a diet video to learn more about what was kept and what was cut down from the stock variant. The build version is 26200.7705 so from january 26. I know it's not the latest version but there shouldn't be any differences in performance from this regard. Whilst on the topic of Windows I would really like to know what version TOs use; I know CS still runs on Windows 10 also but i'd be interested to know if they use custom images perhaps and what is cut if so; I'd be really surprised if they just used stock but they're really hush hush about it. I'd be really cool to know what's the formula for the best performance is all i'm saying. Finally this video does not include a stock Windows benchmark because frankly i have no respect for the version of Windows that microslop provides it's bloated to the point that the OS aspect gets drowned out in a sea of trash so if you're looking for that kind of benchmark this video is not it.
Okay, before we get into benchmarking, the map used is cs2 fps benchmark dust2 by frequencycs and angel and we'll be taking the best of three runs so the system is warmed up for the following configurations. 720 by 400 with everything on minimum and no FidelityFX super resolution and 1920 by 1080 with the following settings: 2x ms aa, very high shadows, all dynaic shadows, low textures, 4x anisotropic, high shader, low partices, high ambient oclusion and quality hdr also without fsr. As we are about to head into Windows benchmarking let me tell you about the GPU we are running. It's an Asus Radeon 260X 2gig version I have to mention because there was also a 1gig variant so Volcanic Islands Bonaire XTX so the best iteration of Bonaire graphics core next 2.0 or 1.1 and we are running the fabulous r.id 23.9.3 2109 legacy GCN drivers from march 25 alongside a mild overclock. Now, for the overclock, this particular Asus came downclocked from factory runnign 1075 base instead of 1100 for core and 1250 instead of 1625 for memory. We managed to clock the core at 1155 and the memory at 1600 with a minimal core undervolt consisting of the following p-state drops: 0 0 -2 -5 -10 -15 -18 and -24 milivolt and also a 20% increase of the stock power limit. I also want to mention that we are running CS2 on the stock DX11 api here on Windows. With that said, lets tackle the benchmarks.
We'll start with low settings and what we can see straight off the bat is that the GPU utilisation does sometimes drop alongside the core clock and miraculously CS2 on the lowest of settings does not bounce off our 2 gigabyte vram limit staying just 200mb under it. Also the CPU utilisation and consumption is higher than what you will see on the high settings because it has to keep up with more frames per second. On the topic of frames, we can see stellar frametimes which was to be expected considering we still have some GPU overhead somehow and finally the dram amount the system is consuming is around 6.8 gigabyte which would be more like 6.5, 6.6 without monitoring. Also, the numbers you see in the bottom left corner are taken without monitoring so a little higher than the run displayed right now; this will go for all benchmarks. Talking about it 253 average with 124 1% lows are obviouly stellar results out of the hardware but obviously no one is playing 700 by 400, this is more to see what heppens when the GPU bottleneck gets removed and how or if there is a difference between cpu performance across Windows and Linux.
Moving on the other set of settings, now we can finally see the GPU pretty much staying at 100% load and the vram limit being exceeded thus also increasing the dram consumtion just above 8gig and I'm guessing that without monitoring you can still fit high settings CS2 on a 8gig system even if you're facing a worst canse scenario like this one where your gpu only has 2 gigabyte of vram. As I said, the CPU utilisation has dropped to under half of what it was on the lowest settings and another interesting indicator here is the frametime graph where we can occasionally see these waves; not really spikes that I think are generated because of texture and effects streaming to the gpu getting bottlenecked by it's miniscule memory bus and bandwith obviously paired with the fact that a lot of information gets offloaded or paged to system dram so this is a really good showing of how the pros call it VRAM overflow. This graphics configuration was obviously tested in order to see the difference between the GPU driver here on Windows and the one Linux has to offer. Finally, let's talk about actual performance; 55 fps on average with 20.8 fps 1% lows on these settings in CS2 are unexpected. This is way higher than I thought the 260X could achieve and considering I did Windows bechmarking before linux I really believed that there is no way you can get better performance out of this hardware but let's find out together as we move on to Linux.
Bazzite is the de facto Linux gaming distro based on Fedora. Alongside CachyOS and a few others, these stand at the vanguard of the new age Linux gaming distros that have been said to rival and have potential to overthrow Windows in terms of gaming; however seeing that we've been stuck in the year of the Linux for the past 5 or more years we can say that at least for now Microsoft still boasts the undisputed majority of the vast pc gaming userbase. So, let's find out if that's warranted or not.
First of all, this is the Bazzite version we're using and these are the GPU drivers; thanks valve because AMD does not provide official legacy drivers. Now, GPU overclocking on Linux, oh boy. In order to be fully clear here before I show you the actual overclock and driver limitations I want to say that from this point of view, yeah the testing might not seem correct, might not seem objective however I want to remind you that here we are testing OSes so if the driver on Windows allows me to have higher clocks than the one here on Linux I'm going to give that to Windows as being superior in terms of performance because if you want to purely find out what OS is best you have to aknowledge the strengths and weakneses of the contenters and not arbitrarily limit the performance of one to match the other when it can obviously surpass it, allright. So with that said, let's get onto GPU overclocking on Linux. You want to go to sys class drm card1 device and here you will find all that you need basically. Starting with core your states are stored in power play dpm serial clock and you can overclock by modifying the value inside power play sclk od. Here the value represents a percentage and is limited to 20. The same goes for memory but replace sclk with mclk and here is the first limiting factor of the Linux drivers. Since we are limited to 20% increase, we cannot go to 1.6 gigaherts instead we are stuck at 1.5. Now, this would not have been an issue since I thought you could easily edit the power play table and de-restrict the od values however I haven't found a powerplay table editor that supports gcn 1.1/2 so we're stuck at 1.5. The next issue that we're facing is voltage state control. The driver simply does not provide what should be powerplay od clk voltage so we have no interface for voltage control unfortunately. Another issue is the power limit that is set in stone at 105 watts so, yeah. The final thing that we can do is fan control via hwmon hwmon1. So, that was underwhelming, it's crazy to see that Linux has more safeguards than Windows and that's a sentence I cant beleive im saying. I'm sure some basement dweller in Shenzhen unlocked overclocking for this card ten years ago but i'm not bothering for this video. Also I guess fuck you if you dont write your own GPU drivers so, yeah skill issue for me. Overall, I quite like the cli overcloking and interface here on Linux the only thing apart from limited control I think is missing is granularity as in od values should accept decimal point in my opinion but, yeah, I thoroughly recommend you do your own reding of the driver documentation as there is quite a lot to cover inside a single video.
Before we move onto the actual banchmark I want to address the idle ram consumption of Bazzite which I know is not a good indicator of performance but I still think it's interesting to compare between OSes. This value was around 2.3 gigabyte which is a value. I expected quite a bit less but here we are.
I have to mention that CS2 runs Vulkan here on Linux unlike DX11 on Windows. On to the benchmarks finally, starting with the lowest settings. The stuttering you're seing is caused by the monitoring overlay and I'll remind you that the values taken are without monitoring and the games does not stutter when we remove MangoHUD this is just how it goes. I will now switch to a recording taken without MangoHUD and go from there. So, there are a few things I'd like to discuss. First unlike Windows where these exact settings fit inside the card's 2gig vram limit, on Linux it tops and overflows into the system ram for some reason also the GPU is constantly at 100% whereas on Windows it mostly stayed under that showing the massive driver or api overhead difference between Windows and Linux. CPU utilisation is about the same so no comment there and finally the worst offender is system dram consumption. We can see a 2gig jump from 6.8 to 8.7 gigabyte ingame so that's about a 30% increase which is not good. Finally the system cleard the map at 217.7 fps average and 122 fps 1%lows. Now these numbers are awfully close to what we got on Windows and I think that if we had access to the proper GPU OC Bazzite would have cleared 1%lows and maybe matched average in this scenario where a lot of heavy lifting is also done by CPU due to the superior Linux scheduler and less load store memory addressing so credit where it's due.
Coming on to the high settings nothing really changes apart from CPU utilisation dropping which was expected and dram consuming jumping by half a gig up to 9.2. Here where the bottleneck is clearly the GPU, the linux drivers simply cannot keep up with what we had on Windows and I dont think any amount of overclocking is moving the 28.4 frames anywhere close to the 55 we got on Windows. 1% lows were close and maybe you could argue that with proper OC it might have matched Windows but I doubt it.
So, that was Bazzite, now I want to move to something proper light that being Artix, based on arch. Here is the version, GPU driver and overclock that is identical to what we ran on Bazzite. The idle ram consumption is under 700mb which is stellar and it's time to move on to the low settings benchmark.
Overall behaviour was identical to what we saw on Bazzite with less system ram consumption; however it returned just 136.6 fps average and 86.7 fps 1%low so clearly gaming flavoured Linux does indeed boost gaming performance to no ones surprise.
High settings, again identical behaviour to that of Bazzite with less dram consumption and a lower fps return albeit this time the difference between the two Linux distros was smaller. 22.5 average fps and 14.1 fps 1%lows.
Finally, before we move on to conclusions I want to address the difference between average and 1% returns across all configurations. Here we can see that Artix wins stability by a considerable margin, offering the lowest variance in fps returns and I must say that it was more than deffinitely noticeable in game; even though it scored the least fps it was the smoothest. Following not far behind is Bazzite, again offering a smooth experience and lastly Windows that was deffinitely the choppiest if you can even call it that because it was still pretty smooth and I would deffinitely prefer to play on Windows despite it losing in this metric.
So, what can we take away from this video? First, the 1gig Windows 11 offers stellar performance, the r.id third party drivers also offer amazing performance, overclocking on Windows is the best bar none and I think that the numbers we saw for the Windows benchmark prove that this is the formula for getting the utmost performance out of this hardware. Second, amdgpu Linux drivers are massively lacking in terms of performance as well as overclocking capabilities, the Linux scheduler and CPU calls performance is more sophisticated and vastly more performant than what Windows offers and finally all of this doesn't matter; feel free to run the OS of your choice as they are all rubbish anyways.
Well, you made it to the end, who would've thunk that Windows beats the 70s mainframe in gaming huh. I personally was sad to see it. Hopefully if SteamOS ever gets an official desktop release it wil perform much better than what we saw here and toaday but until than we're stuck with what we have. Most importantly, do your own investigation, don't take this video as the be all and end all of os performance metrics; read the docs for yourself and I guess we should all start writing Linux GPU drivers. Thank you for watching!!!  (fuck microsoft!!)