working hires sprites on 2GB VRAM

[sthalik]

Hey,

I'm able to run hires sprites on the flaky Radeon 270x with 2GB VRAM. This throws a warning when choosing hires sprites but with the correct settings, allows for 60 FPS. I don't know how it works on the NVIDIA drivers, or on Linux. I expect Linux Mesa drivers perform better than Windows with its binary Radeon driver.

I hope this post is useful to anyone. See the end of the post for the exact settings. Here's my attempt at explanation for each option. Sadly it's technical. I'm going to play with atlas sizing some more to squeeze out more VRAM usage.

0. After VRAM is exhausted, the GPU will release whole atlases, not their parts. Better to make smaller atlases but more of them. A re-upload will cost precious latency. It's similar to downloading from GPU memory which forces a long wait if done synchronously (just like an upload has to be in this case). The PCI-X bandwidth is large but has long delays too.
1. My CPU usage on modern Core i5 is 60% of one core. Options costing CPU due to GPU driver overhead won't make the game starved for CPU. Any Haswell+ CPU should handle it.
2. Create specialized atlases: See (0).
3. Optimize atlas sprite packing: a) drawing in retained mode isn't completely expensive 2) eye-inspecting atlases via the debug key shows a major difference in their sizes.
4. Low VRAM mode: it's actually very sensible to lazy-load sprites. Loading each and every one at startup will choke without large VRAM amount. A decent amount could be never used actually, especially with mods.
5. Texture compression: From Wikipedia: There are five variations of the S3TC algorithm [...] resulting in compression ratios of 6:1 with 24-bit RGB input data or 4:1 with 32-bit RGBA input data. I recommend it under all circumstances. The GPUs support S3TC in hardware directly.
6. Atlas texture size: See point (0).
7. Sprite resolution: High. That's what we came for!
8. Render threads: Setting it to max value strangely helps a lot. The game's programmers seem to be very competent, given the difficulties of multicore rendering.
9. Video memory usage: I don't understand why it has to be set like that. I thought "High" scales with max VRAM, and that it should be the optimal value. But it lowers FPS to ~40.

factorio-gfx.png (96.7 KiB) Viewed 2447 times

[Jap2.0]

I'm also running high quality sprites on 2 GB VRAM, I'll see if I can get a screenshot of my settings (it may be a couple weeks though).

[mexmer]

That depends a lot on mods you use/play with.
if mods you use contain lot of own graphic, 2GB will not cut it at some point. If most mods you use reuses vanilla graphics, then there should not be issue.

[kreeg]

8. Render threads: Setting it to max value strangely helps a lot. The game's programmers seem to be very competent, given the difficulties of multicore rendering.

The text for this option states multi-thread rendering, not multi-core rendering. Multi-threaded and multi core are not the same thing. You are mingling the two.

It does not matter whether your CPU is Dual core or Octa core. Factorio uses only a single core.

[sthalik]

Have you tried this config option? The default "auto" option makes only some of the atlases S3TC-compressed.

It has one side effect–atlases lose their attributes. Hover over particular atlases in F3 view and see how they lack any of the "smoke", "mipmap", "decal", "terrain" or "linear-minification" metadata.

Code: Select all

; Options: false, true, auto
texture-compression=true

This is of course with Alien Biomes for more evil. Atlas texture size is 2048x2048. Render is GL. The test scenario is a single save game with max unzoom. Biomes were scaled to 10% of normal size during map generation. The GPU is Radeon 270x with a stock clock and 20% power increase. The CPU is i5 7600 running Turbo all the time when under load.

Code: Select all

opengl:
(normal/normal) Atlas memory size: 319.77MB / 43 FPS
(high/normal) Atlas memory size: 787.92MB / 38 FPS

d3d9:
(normal/normal) 40 FPS
(high/normal) 37 FPS

8. Render threads: Setting it to max value strangely helps a lot. The game's programmers seem to be very competent, given the difficulties of multicore rendering.

The text for this option states multi-thread rendering, not multi-core rendering. Multi-threaded and multi core are not the same thing. You are mingling the two.

It does not matter whether your CPU is Dual core or Octa core. Factorio uses only a single core.

Definitely it's possible to force all threads onto the same CPU with pinning. It's also possible to gain nothing or a negative amount if the GPU driver has coarse-grained locking around drawing routines. However, without pinning, the behavior for threads is to schedule around all available CPU cores. It doesn't mean they consume high quantities of CPU time, they may as well block in the driver's internals or on I/O. The Arma 2/3 games have a thread dedicated to loading assets and it doesn't do any heavy lifting, only waiting for disk reads to finish before starting more.

I'm also running high quality sprites on 2 GB VRAM, I'll see if I can get a screenshot of my settings (it may be a couple weeks though).

Can you show your VRAM usage? You have to enable verbose logging in the config file. Try comparing the "auto" S3TC setting to "yes" setting which is compressing everything.