[2.1.7] Large rendering performance regression on Linux

[SteveofDoom]

After downloading experimental release of version 2.1.7 for Linux directly from factorio.com and opening the editor to test new things I noticed a very large rendering performance regression compared to the latest stable version (2.0.77) caused by decoratives.

Steps to reproduce:
-Create a new editor scenario with sandbox scenario type
-Use default settings for map generation (the seed in the screenshots is 666666)
-Go to surfaces tab in the map editor menu and click generate planets
-Change surface to Vulcanus and zoom out as far as possible

Doing these steps should show a rather high Draw Call time usage in the time usage debug menu compared to 2.0.77. Disabling decoratives drops the Draw Call time usage down to reasonable levels.

I am running Linux 7.1 and KDE Plasma 6.7 on Wayland. Both versions were run from freshly extracted zip files downloaded from factorio.com with no mods and no settings changed outside of graphics settings which are visible in the screenshots.

Performance in 2.0.77:

perf_2077.png (4.2 MiB) Viewed 865 times

Performance in 2.1.7:

perf_217.png (4.23 MiB) Viewed 865 times

Log files for both versions attached.

[Rseding91]

Nothing has changed about rendering decoratives in 2.1. Most likely 2.1 uses slightly more VRAM, or the layout of textures is different within the atlases resulting in more atlas switching while drawing. The level of difference you're seeing almost looks like hardware-rendering vs software-rendering.

[SteveofDoom]

I did notice 200-300 MB higher VRAM usage but that alone shouldn't have noticeable impact. Could it be caused by SDL3 or some other middleware that cannot properly detect some hardware features?
From my own limited game dev experience my intuition would tell me that the decoratives somehow aren't being properly batched resulting in many unnecessary draw calls but you said that nothing about the way decoratives are drawn has changed so it cannot be that.

Please let me know if you need some additional information about my configuration. Happy to help figure this out.

[SteveofDoom]

I've done some additional testing and it looks like the Windows version is running as expected so it seems to be a Linux-specific issue. Another user on Reddit seems to also have what appears to be the same issue on Linux when viewing Vulcanus's surface.

[Sanqui]

2.1.7 for Linux was compiled without LTO (link-time optimizations) due to a last minute issue cropping up when linking against the Steam dynamic library (.so). This large of a loss in performance is unexpected (LTO is supposed to account for ~2-3%) but it may be related nevertheless -- we'll try our best to fix this for the next release.

[SteveofDoom]

Thank you for looking into it, hopefully the fix is simple.

[Sanqui]

Good news, I don't yet know if it's the root cause of this perf regression, but I did manage to fix LTO for Linux builds by downgrading mold (the linker we use). It'll go out with the next release.

[SteveofDoom]

I tried the same scenario again in 2.1.8 and the problem persists. The number of draw calls (if that's what's displayed in the first row of debug text in the screenshots) is still ~40x higher than in 2.0.77. Might be something really strange going on with SDL3 or some other library that interfaces with graphics. Unfortunately I cannot test it on X11 at the moment to check if it's only a Wayland issue.

[SpoilageTycoon]

I want to confirm this issue. I see a massive performance degradation from 2.0 to 2.1.7 and 2.1.8. It's noticeable on Vulcanus, other surfaces seem minimally or not affected.
Tested on the Steam version of the game.

System configuration
OS: Fedora Linux 44 (Workstation Edition) x86_64
Kernel: Linux 7.0.12-201.fc44.x86_64
CPU: AMD Ryzen 5 4600H (12) @ 3.00 GHz
NVIDIA GeForce GTX 1650 Ti Mobile [Discrete]
AMD Radeon Vega Series / Radeon Vega Mobile Series [Integrated]

2.0.77:

Screenshot From 2026-06-26 08-49-22.png (3.87 MiB) Viewed 443 times

2.1.8:

Screenshot From 2026-06-26 08-54-15.png (4.02 MiB) Viewed 443 times

[pioruns]

Out of curiosity, I cloned Factorio folder and tested 2.1.8 on my computer (details in the signature). I have Xlibre (fork of Xorg), version:

Code: Select all

Package: xlibre
Version: 1:7.8+5

No Wayland. It works very well on my setup. Both 2.0.77 and 2.1.8 shows 60.0/60.0 FPS/UPS on my advanced save. One thing I noticed is that Wayland driver performs poorly on X11 system, selecting Wayland preferred driver caused FPS/UPS drop to 40s.

For anyone experiencing performance problems, try X11/Wayland back and forth see if that changes anything.

[SteveofDoom]

I've done even more testing today. I tried running the game on my laptop with both an AMD iGPU and Nvidia dGPU. Since it's Linux, AMD iGPU performs better than the Nvidia dGPU, nothing unusual there. There was maybe a small difference between X11 and Wayland so it's not only a Wayland issue.

The thing that stays the same between all 4 combinations I've tested today is the number of draw calls. The cost of a draw call is a lot lower on an AMD GPU and therefore I get almost 60 FPS while on Nvidia it's about 33 FPS. Looks like the problem that's actually at play is the extremely large number of draw calls compared to 2.0.77 in the same scenario. Vulcanus tends to have the highest amount due to decoratives, but Gleba and Nauvis could also cause performance issues on weaker CPUs.

EDIT: The number of draw calls on Windows is still high, but they are much more efficient compared to Linux.

[Rseding91]

I want to confirm this issue. I see a massive performance degradation from 2.0 to 2.1.7 and 2.1.8. It's noticeable on Vulcanus, other surfaces seem minimally or not affected.

Could you upload the save file you're using for that example such that I could test it on 2.0 and 2.1 on my system? I might not be able to reproduce the performance difference but I can try to investigate the draw call difference.

[SpoilageTycoon]

Could you upload the save file you're using for that example

Sure, here it is.