Vulkan vs. OpenGL Linux Game CPU Core Scaling

[M@yeulC]

Hmmm interesting. I believe that the graphs show that vulkan is more cpu independent than opengl as it supposed to be. That's why vulkan performance doesn't increase with more cpu threads. The lower performance on some benchmarks are because RADV isn't completely ready yet. So, in conclusion, I believe that performance not increasing with more threads, is something positive, since that means that performance depends only mostly on GPU (which isn't the case with opengl).

If the above conclusion is wrong, then please someone to correct me.

This analysis sounds right to me. That is, unless the engines don't do any mutithreading, in which case it's more an engine benchmark.

You would have to test a very CPU-limited (800x600) scenario to see if it scales well, I think.

But does that explain the tests where OpenGL caps out higher than vulkan? I agree with Michael here. Smells like a thread synchronization bottleneck to me

Yes, it does: imagine a perfectly lean driver (basically free on the CPU), but unoptimized (thus lower framerates). You would see the same results in GPU-bound scenarios (which would be always, barring any other CPU-hungry processing from the engine: physics, AI, etc...
No scaling (because the GPU is already well-fed, and crunching all numbers it can), but lower output framerate because it is not perfectly optimized yet.
Basically, it is more CPU-efficient.

Now, we would have to see the same test in a CPU-limited scenario (run the CPUs at 1GHz or lower the resolution -- but preferably the second option, to avoid starving non-graphics parts of the engine), to see if Vulkan scales well over the various physical threads.
Note that it is engine-dependent, though. Some game engines might not have more than one dedicated thread for graphics.


For those complaining about RADV being used there: it doesn't matter (as long as RADV supports the same extensions). The most interesting part is the relative core scaling, ie comparing the shape (or the relative increase/derivative) of the graphs, not the absolute performance value. I expect very similar results with nVidia (with an offset that depends on the card/driver performance; and in the Vulkan camp, at least -- who knows what tricks nVidia has up its sleeve to scale its OpenGL drivers with the number of cores? :P)

[gamerk2]

But does that explain the tests where OpenGL caps out higher than vulkan? I agree with Michael here. Smells like a thread synchronization bottleneck to me

Alternative Explanation: The Vulkan implementation is poor. If it were a thread problem, it would show up in OGL too. [Keep in mind, I've been screaming at people to fix the Linux scheduler for over two years now.]