Performance impact of Atlas Texture Size

[Zanthra]

I was playing around with some options the other day, and when I set the "Atlas texture size" in the options to largest possible I had a big FPS drop in a large modded factory. I was not particularly surprised about this, as textures of that size are hard for the CPU/GPU to move around and find contiguous memory for, and there can be caching impacts with lines as wide as 16384. I set it back to 2048 and didn't worry about it. Looking at various threads in the Technical Support forum, many of those with FPS issues have log files indicating 16384 (Largest possible) Atlas texture size. One issue is probably a "bigger is better" mindset which is not always true in computers. Even with large amounts of VRAM and some efficiency gains with batching, the mobility provided to the driver to move the smaller textures around where they are needed can be a large boon. The issue is I only have one machine to test this on, so I wanted to ask more folks for info to confirm this. If there is confirmed to be a performance hit from using larget Atlas texture sizes, perhaps reducing the Atlas texture size to 2048 can be added to the sticky in the Technical Help forum, and as a first step recommendation for resolving FPS issues.

If folks could provide information on their GPU and their approximate FPS zoomed out in a moderately busy game, while running with Largest Possible atlas texture size, vs 2048 atlas texture size in a decent sized game, I think would be sufficnet.

GPU: Nvidia GTX 980
FPS Largest Possible: 30 - 60 depending the number of different objects on screen.
FPS 2048: 60+

[orzelek]

I think you might need to extend the data about testing.
Few more data points would be good (2048 is very small as far as texture size goes) - try with 4096 textures too.

Also infromation about VRAM memory usage would be necessary for any test like this.
My assumption is that bigger is better should hold as long as GPU can easily fit all the texture data into VRAM. When this is not met then texture size might come into play when textures need to be swapped out from memory.

[Rseding91]

If your GPU can handle the larger texture size (fit them all into VRAM without ever needing to swap them out) then it performs better runtime (higher FPS by reduced time to render). If it can't, then you have to use the smaller texture sizes and suffer a larger impact the smaller the texture size goes.

The benefit of the larger texture is the game doesn't have to do as many draw calls to render everything it needs. The more times it has to swap textures to render the longer it takes.

That is, assuming it can even handle the larger texture. If it can't then that's your limit - which is why the setting exists.

[Rseding91]

For reference: the difference between being able to batch virtually all of the draw calls into one draw call vs sending them one at a time (no atlas system/every sprite in its own atlas) gave a 6x performance improvement when rendering blueprint tooltips.

[Zanthra]

To some extent yes. Some GPU models have 2 or 3 variants with different ammounts of VRAM, unfortunately it's not always trivial to determine the VRAM avaiable, although it does show up in the factorio log file. One thing to include would be what mods are installed that add large numbers of new sprites to the game, as that can grow the size of the large texture atlases that may not be full in the base game.

As for intermediate measurements at 4096 and 8192, I think that the performance lost if the driver cannot quickly and efficiently manage memory due to the size of the textures it has to juggle will dwarf any sprite batching performance gains such that at least to determine if atlas texture size is an issue, going all the way down to 2048 would be the best recommendation. One could optimize it by stepping up from there to find the best option for their setup, but there are many platitudes against premature optimization. The 2048 texture size is likely to provide the most consistent performance (even if slightly below maximum) across most setups.

I feel that some people may equate atlas texture size with either visual quality or see it as a bigger is better, which is certainly not the case for my machine where I get less than 50% of the FPS of atlas size 2048, and at least three of the reports of low FPS also have logs showing factorio building 16384 wide atlases (suggesting it either defaults to that, or people are setting it to that).

For my machine again:

Large Mods: Bob's and Angels
GPU: GTX 980
VRAM: 4G
Largest Possible: 30-60 FPS depending on the objects on screen
8192: 60 FPS
4096: 60 FPS
2048: 60 FPS

PS:

For reference: the difference between being able to batch virtually all of the draw calls into one draw call vs sending them one at a time (no atlas system/every sprite in its own atlas) gave a 6x performance improvement when rendering blueprint tooltips.

I would imagine that 2048x2048 already a lot better than no atlas system already though. I entirely agree that the option is great to have, but it may be important to consider reducing the atlas texture size to 2048 as a first step recommendation if people have FPS issues and have their texture size set to Largest Possible.

[Rseding91]

The first step when you have FPS issues it to not run HD graphics. If you add a bunch of new sprites with mods then you have to start reducing graphics settings.

For the default player who plays just the base game "largest possible" setting for atlas textures gives the most consistent high FPS. If your system can't handle that, that's why the settings exist.

[Zanthra]

The first step when you have FPS issues it to not run HD graphics. If you add a bunch of new sprites with mods then you have to start reducing graphics settings.

For the default player who plays just the base game "largest possible" setting for atlas textures gives the most consistent high FPS. If your system can't handle that, that's why the settings exist.

I guess it might not be first step recommendation, but I was hoping to gather some more information to have an understanding of whether I would be correct in it being a good recommendation.

I am not sure I would agree that not running HD graphics is always better than reducing texture size though. If you have a situation where not all the textures can fit in VRAM, smaller texture atlases may give the software and driver more flexibility to leave textures for objects that are not on screen in main memory while filling VRAM with textures for what is on screen. While it may cost more in CPU and driver time for the draw calls; in many cases, including on my machine, it can still maintain 60 FPS. The larger the textures, the more likely it is that some sprite in that texture will be on screen, and it will have to move the entire texture into VRAM every frame, potentially including many sprites that are not used.

[Rseding91]

Some additional information: if your graphics card can't store all of the atlases in VRAM you should change the "video memory usage" option so the game doesn't try to put all of the sprites into VRAM.

However, as with most settings - your results vary depending on the machine and mod setup as to what's best to solve what problem.

[Zanthra]

Some additional information: if your graphics card can't store all of the atlases in VRAM you should change the "video memory usage" option so the game doesn't try to put all of the sprites into VRAM.

I got a chance to play around with this, but have a few questions. When set to "ALL" does Factorio build all sprites into atlases and let the GPU driver move them from dedicated memory to shared system memory as needed, or does it just build as many as would fit in dedicated memory if it were empty? How are sprites chosen for the atlas in this case, are the largest textures the ones left out?

Going from All to Medium or Low video memory usage with largest available atlas size brings the FPS on my machine back to 60 FPS, while high does not. This may be due to the number of other programs I tend to have running on my computer which may have resources in VRAM (about 1.5GB / 4GB used on the desktop). It does seem to solve the memory issues present with mods + all video memory + largest available atlas size.

However, as with most settings - your results vary depending on the machine and mod setup as to what's best to solve what problem.

True, but perhaps it would make sense to add to the Techinal Help Sticky something like "If you have reduced FPS, especially in nodded games, try reducing the 'video memory usage' option in the graphics options".

PS: I see it now in the sticky of the Bug Report forum: viewtopic.php?t=9300 which may not be the first place someone looks when they have FPS issues. It might be reasonable to copy that here too.

[Rseding91]

When you select "all" for video memory usage the game puts every image it loads into VRAM (or tells the graphics card it wants to do that - what actually happens is up to the driver).

[posila]

I got a chance to play around with this, but have a few questions. When set to "ALL" does Factorio build all sprites into atlases and let the GPU driver move them from dedicated memory to shared system memory as needed, or does it just build as many as would fit in dedicated memory if it were empty? How are sprites chosen for the atlas in this case, are the largest textures the ones left out?

The former. "ALL" makes Factorio build all sprites into atlases. Atlases are allocaded as texture objects, so the driver will try to put them into VRAM if it can. If you don't use "All", sprites that are not included in any atlas are also allocated as texture object though (unless "Low VRAM mode" options is enabled). So it is really is up to the driver how it lays it all out to VRAM and RAM.

One of the things I am planning to do next in "rendering modernization" effort for 0.17 is to change atlases to use texture arrays. That way, instead of two 16384*16384 atlases we can create texture array 4096x4096x32 which will be easier for driver to deal with and we can improve batchning because we won't need to switch between atlases while drawing.