Comparing Vulkan and OpenGL Software Rendering in Thrive (No GPU)

I am comparing the performance differences between Vulkan and OpenGL rendering modes in Thrive, along with testing out software rendering of the game with no GPU.

I am testing on the latest mesa llvmpipe on Ubuntu 22.04. Using AMD Ryzen 9 5950X 16-Core Processor.

For OpenGL mode when I set it to 50% resolution on 1080p screen and disabled AA and anisotropic, otherwise default settings. Gets 10fps in microscopic freebuild with good amount of other species in patch. But it actually feels a lot smoother than that, it must be a pretty consistent 10fps. I could play Thrive like this.
Disabling chromatic aberration jumps to 20fps, this becomes very playable. And the game still looks quite nice, all of the other graphical effects combine to preserve the aesthetics.
I have noticed that the damage effect tanks the fps when active, might look into that. I would disable on screen damage effect setting if I was playing this more.

For comparison, the Vulkan software renderer only gets around 6fps with those settings, 3-4 times slower than the opengl software renderer. Might be because Vulkan software rendering is still a lot less optimized than the opengl version, I think they have been focusing on feature support over performance right now. It does seem to work without any graphical glitches though, so I would expect this option to become more useful over time with further optimization.

Here are the results from running the benchmark on my machine with all combinations of Vulkan-OpenGL and GPU-Software Rendering, I also listed the commands I used to select these options:

Settings:
Completely default settings except for using windowed mode, on 1080p screen.

Vulkan GPU:
./Thrive
Benchmark results for MicrobeBenchmark v1
Stationary microbes score: 314.784
AI microbes score: 336.275
Spawns until no 60 FPS: 2493
Microbe stress average FPS: 149.115
Microbe stress min FPS: 58
Alive microbes: 268
Waiting for microbes to die: 427.126
Microbe deaths minimum FPS: 90
Remaining microbes: 39
Total test duration: 447.1s
CPU: AMD Ryzen 9 5950X 16-Core Processor (used tasks: 16, native: 8, sim threads: True)
GPU: AMD Radeon RX 6800
OS: Linux

Opengl 3.3 GPU:
./Thrive --rendering-driver opengl3
Benchmark results for MicrobeBenchmark v1
Stationary microbes score: 252.373
AI microbes score: 290.902
Spawns until no 60 FPS: 2493
Microbe stress average FPS: 127.085
Microbe stress min FPS: 58
Alive microbes: 292
Waiting for microbes to die: 324.211
Microbe deaths minimum FPS: 76
Remaining microbes: 40
Total test duration: 447.4s
CPU: AMD Ryzen 9 5950X 16-Core Processor (used tasks: 16, native: 8, sim threads: True)
GPU: AMD Radeon RX 6800 (navi21, LLVM 15.0.7, DRM 3.57, 6.8.0-57-generic)
OS: Linux

Vulkan CPU:
MESA_VK_DEVICE_SELECT=“10005:0” MESA_VK_DEVICE_SELECT_FORCE_DEFAULT_DEVICE=1 ./Thrive
Benchmark results for MicrobeBenchmark v1
Stationary microbes score: 3.51
AI microbes score: 3.961
Microbe stress average FPS: 10
Microbe stress min FPS: 10
Waiting for microbes to die: 10.08
Microbe deaths minimum FPS: 9
Total test duration: 177.9s
CPU: AMD Ryzen 9 5950X 16-Core Processor (used tasks: 16, native: 8, sim threads: True)
GPU: llvmpipe (LLVM 15.0.7, 256 bits)
OS: Linux

Opengl 3.3 CPU:
LIBGL_ALWAYS_SOFTWARE=1 ./Thrive --rendering-driver opengl3
Benchmark results for MicrobeBenchmark v1
Stationary microbes score: 6.196
AI microbes score: 6.706
Microbe stress average FPS: 16
Microbe stress min FPS: 16
Waiting for microbes to die: 16.44
Microbe deaths minimum FPS: 16
Total test duration: 115.7s
CPU: AMD Ryzen 9 5950X 16-Core Processor (used tasks: 16, native: 8, sim threads: True)
GPU: llvmpipe (LLVM 15.0.7, 256 bits)
OS: Linux

3 Likes

While I know this isn’t directly related to the topic, I suppose I am not the only one who noticed the game doesn’t really seem to want to progress with this step at times due to the computer being “too optimized” for the microbe count to lower the FPS below 60fps for too long as the ones spawned further ago die, decreasing the count, right?

2 Likes

I noticed this too, it seems like it just skips this benchmark on systems that are low enough performance. Not sure if this would be best to change to somethink like “Spawns until no 30 FPS” or if it doesn’t matter much.

1 Like

You mean on these low performance machines?

From the Oldest Computer That You Have Run Thrive On topic, as well as the software rendering modes tested in this thread. It has been fairly common.

1 Like

Are we sure a substantial enough part of our playerbase will be playing Thrive on such computers to justify implementing this?

1 Like

Good thing for you to bring up, I should clarify this. The software rendering is part of the mesa drivers that are typically used by default in Linux. For example, if you are running a typical Linux distro like Ubuntu this software renderer would be installed by default, and would automatically run if you launched Thrive without a compatible GPU. Nothing was different on Thrive’s side, and all I did here was force it to use the software renderer instead of choosing the GPU by default.

Not sure what the circumstances would be for anyone to choose to use this, unless their GPU died or something, but it was interesting to test out.

2 Likes

So it should be in the game then considering this is more of a linux game than a windows game.

1 Like

Anyone running a normal linux distro from the last 5 years or so should be able to run it without a GPU just by running the game from the terminal like this:

LIBGL_ALWAYS_SOFTWARE=1 ./Thrive --rendering-driver opengl3

Windows might have something like this too, but it probably requires installing something.

2 Likes

I suppose 30 FPS would then be the general limit of playability?

For me I thought the game ran well at 20fps, though of course this limit varies significantly depending on the person. And I think it depends on what you are used to, if you are a low-end gamer then you can tolerate low fps better than someone who only plays on new hardware.

1 Like

I suppose 30 FPS could be a compromise option in such a case.

1 Like

It does seem like a better boundary for the “Spawns until no X FPS” limit, though maybe @hhyyrylainen could weigh in on why 60fps was chosen as the limit for the benchmark. It would probably make the test longer for higher end systems at least. Though benchmarks for lower end systems seem more important to prioritize for. (Not necessarily the unusually low end systems I have been posting about recently, but moreso the typical low end system from ~2012)

1 Like

Pretty sure 60fps was the lower boundary for “good framerate gameplay” back in the day. Maybe it still is for some games.

For recommended specs, maybe. But 30fps is a perfectly reasonable lower boundary for minimum spec systems. I would rather play 30fps at higher graphical detail than 60fps at lower graphical detail for instance.

Check out https://www.reddit.com/r/lowendgaming/ for instance; you will see plenty of people excited to get their games running at 24fps.

1 Like

I agree. Never seen why people want to play their games at absurd graphical quality standards that most wouldn’t notice.

It’s a fullscreen overlay so it causes an extra render pass. Fullscreen passes are always expensive so if we could combine multiple of our fullscreen effect shaders into one, that would increase performance. Though with an actual GPU this seems pretty minor which is why I haven’t considered spending the effort on this.

Kind of interesting. It could also be as OpenGL leaves a lot of the rendering details open that on a CPU they can do many shortcuts, but on Vulkan you need to much more closely model how a GPU functions. Though I have no evidence to back up my viewpoint.

Isn’t the number pretty much super low if you can’t get 60 FPS? I think by that point the benchmark could give an overall score saying that you can’t hit 60 FPS at all so the performance is really terrible.

Even with the current setup high end Windows systems sometimes really struggle to fall below 60 FPS. So if the limit was 30, I worry that some computers would never stop running the benchmark. So that would need a ton of changes for the benchmark.

Anyway I think if something is changed for the benchmark it would be that it just doesn’t give a score if your computer cannot hit 60 FPS at all. And instead has text saying that you need to change the performance settings or not have a good time in Thrive.

The benchmark is not meant for low end systems anyway, as you can immediately tell with them when starting the game that the performance is kind of bad. And gets worse very quickly.

3 Likes

That shouldn’t mean we ought to abandon these lower-performance-device playerbases.

My Surface Pro 3 has very similar specs to this system that a community member uses (from Oldest Computer That You Have Run Thrive On - #20 by Oncpapa):

I think Thrive is playable on my Surface Pro 3, and it seems like Oncpapa thinks so as well for his similar system. But the benchmark doesn’t give a benchmark value for the “Spawns until no 60 FPS” test even with settings lowered to a reasonable amount that gives a good experience in game. Maybe it doesn’t really matter too much for this one specific benchmark, as the rest of the benchmark still gives enough useful data. But I think we should still support systems like these, and if we edit the benchmarks in the future or add new ones (like 3D performance benchmarks) we should keep this in mind.

One of my goals is to get a really solid report of minimum and recommended specs for Thrive for the 1.0 release. I am testing some silly setups along the way like the software rendering mode, but that is more for the fun of seeing how far the boundaries can be pushed. So far, it looks like the minimum spec systems are still capable of running a playable Thrive game, and is even better than before with the resolution scaling options.

I have noticed this performance issue in OpenGL rendering modes for typical minimum spec systems with a normal gpu before, like the aforementioned Surface Pro 3, but it has just showed up as a slight hitching on those systems. Probably isn’t worth fixing for now.

1 Like

By the way, will multicellular development bring about some changes/updates to the benchmark to test how the game handles multiple multicell colonies and stuff?