We've been playing tf2 on 32 bit this whole time? Wtf valve

finally, 32 more bits

somehow this will lower my framerate even more

https://www.youtube.com/watch?v=fUA5ZzNY70A

https://lr.drgnz.club/r/tf2/comments/19ecd0k/linux_beta_vulkan_benchmark/
so far I've read of +25% to 30% uplifts

edit: also read about someone having the performance unchanged and when I tried the branch, it soft locked the entire system upon entering game's menu, so yeah

This is more overdue than any sort of content update they could give us tbh

im sure the 8 people that game on linux will be stoked

https://media.tenor.com/y0zptlFKiYIAAAAM/yay-kitty.gif

well it's supposed to be available first on linux but then on windows too meaning pretty much all players will gain (probably a lot of) performance from that sooner or later

I don't know if this will necessarily be the case, 64-bit might help with the occasional out of memory crashes that people experience in certain rare circumstances, and maybe fix things like this, but gmod for example has a 64-bit version and it performs about the same as the 32-bit one. I guess it's good future-proofing if microsoft ever decides to drop the 32-bit libraries from windows.

As for vulkan, valve has already released a vulkan shaderapi for games like csgo and portal 2 and at least on windows it seems to perform pretty consistently worse than the directx one across the board, but who knows, maybe tf2 will be different for some reason. For linux it's definitely a welcome addition.

64-bit alone will do a little bit for performance. Raising the game from SSE to SSE2 will allow the compiler to do better optimizations, especially for mathematical calculations (as well as more consistent rounding). And 64-bit compilers have new rules that finally force them to remove a bunch of legacy code that is incompatible with some compiler optimizations. It also forces more proper memory alignment in the engine, which can improve performance.

On Windows, 64-bit will eliminate the WoW64 compatibility layer, which adds some overhead to threading and disk reading mainly. I am not sure of the overhead, if any, of 32-bit support on Linux.

64-bit also increases the amount of RAM available from 4GB to practically unlimited. This fixes out-of-memory crashes that people sometimes get, especially with higher texture qualities (on DX8, I believe, and on some Linux drivers) because of system copies of texture data. But it also happens for 100-player servers and custom MvM missions sometimes.

The increased RAM can also allow people to increase cache sizes, which can help with cosmetic and sound loading and the stutters associated with both.

Furthermore, on Linux, the runtime is being upgraded from Ubuntu 12.04 to Steam Linux Runtime 3 (sniper), a much more modern set of tools in terms of the compiler, SDL graphics/input library, and more. This has performance improvements, bug fixes (for example, the MvM TFBot name issue on Valve servers), console text rendering fixes, and a double mouse sensitivity fix.

The port also means some libraries are being changed. The memory allocator is being changed to mimalloc, which is much faster and means there will be less overhead for a lot of operations. The MP3 reading is being changed from Miles to minimp3, which is also faster.

A new dxvk-based layer for DirectX to Vulkan is being added, which gets graphical parity for Linux compared to Windows, and also gets rid of overhead, massively improving performance for graphics rendering on Linux. On Windows, the dxvk results have been quite middling and inconsistent, though.

Finally, performance changes are being made, from TC2 and some new fixes. The extent of this is not fully known or realized yet but I can say that I am very optimistic about some pretty impactful performance improvements getting in.

but will it break sourcemod?

I'm sure they have been aware at some level for a while, and the beta testing period will be long enough for mods to catch up. The only thing sure to permanently break is PREC, but hopefully, Demo Support will get some fixes in this update to get parity with it. (https://www.teamfortress.tv/63486/why-use-p-rec-over-integrated-demo-support)

Do you think this would affect wall bugs and other things that occur with rounding issues?

might be a hot take round these parts but i'll gladly take the death of wallbugs for improved performance

i easily wallbug on cp_process_final so guessing nothing changed in that regard

probably would break linux bugs idk though https://jump.tf/forum/index.php?topic=3426.0

Given the cause of Linux bugs it doesn't seem likely that simply upgrading from 32 to 64 bits would break them.

Now available on Windows

How does one get this.

This is super good - do we need a different build of srcds for it to work on 64 bit or is it cross compatible?

Can someone try to benchtest a few demos on the 32 bit and 64 bit beta?

Loaded up the beta branch and played on a tr_walkway to see like ~10 fps increase. Definitely leaning toward coincidence though. Haven't tried demos yet but I'm betting they will be broken like after most updates now. I'll edit when I have time to test demos.

32bit

3267 frames 11.225 seconds 291.04 fps ( 3.44 ms/f) 24.448 fps variability

64bit

3267 frames 11.235 seconds 290.78 fps ( 3.44 ms/f) 43.185 fps variability

just a pub demo in a CPU limited scenario, no time in spawn or deathcam
dx95 mastercoms low

see below, testing was flawed

will the old betas still run in 32 bit?

Yes, they're not cross-compatible

You mean the betas that let you watch demos? They will probably remain 32bit

Yes that's what I meant, And what about programs like HLAE, Lawena and AviRecorder?

more benchmarks
this is on a 13600k

Windows 11

these results made me wonder why 64bit was faster on Win11 but not Win10.
it's because I forgot that it would be a new exe; on Win10 I use process lasso to set the core affinity of hl2.exe so that it doesn't try to use E-cores, and I also disable core 0 since that guy is always up to no good.

Windows 10 re-tested

Looks incredibly promising, core utilisation looks so much better, much more like the performance of TC2

On Win10, manually setting affinity is still a huge boost (as with 32bit).
Win11 already has good scheduling - I did test process lasso, showed no benefit

and the benchmark demo if anyone wants to try it

I can't speak for client side plugins but this will definitely break a lot if not all server side plugins. I know for a fact that all sourcepython based plugins (tempus being the biggest one) will be bricked for sure, and the sourcepy devs are very dead so thats going to be a lot of fun.