Core i7 / Core i9 / Ryzen 7 / Threadripper OpenGL+Vulkan Linux Gaming Benchmarks

[audi.rs4]

Here we go again. Games are not highly threaded applications because there's nothing to multithread in a game engine. Rendering can be parallelized, but that's on GPU.
A game is not a video editor that can slice up a frame into zones and offload each zone onto a thread. It's not a 3D renderer that can use a thread for each ray it traces. Games (at least in the form we know them today) simply benefit more from 4-8 cores running at high frequencies.

You should take a look at most of the lastest DX12 and Vulkan games.

Hitman
F1 2017
Battlefield 1
Ashes of the Singularity
Rise of the Tomb Raider

All of these games will utilize all of a i7 7700k's 8 threads at about 30% per thread. An i5 in Hitman is at capacity of 95% across its 4 cores. So, yes, games can also be highly threaded, and all thanks to the enhancements of DX12 and Vulkan.

[andyprough]

Looks like i7 is still the biggest value in terms of the way games are currently designed. Kudos to Intel.

[mbello]

Great! Can we now all agree that TR is not a Gaming CPU?

Now, mobo manufacturers, please stop making gaming mobos for TR and give us some nice mobos targetted at those wishing to build small servers:
- 2 x 10Gbe
- IPMI so that we do not need a GPU
- 10 SATA ports
- 4 well ventilated m.2 NVMe slots
- no LED circus, please.

[Marc Driftmeyer]

You should take a look at most of the lastest DX12 and Vulkan games.

Hitman
F1 2017
Battlefield 1
Ashes of the Singularity
Rise of the Tomb Raider

All of these games will utilize all of a i7 7700k's 8 threads at about 30% per thread. An i5 in Hitman is at capacity of 95% across its 4 cores. So, yes, games can also be highly threaded, and all thanks to the enhancements of DX12 and Vulkan.

That's not a lot of threads, nor cores. To design around the maximum no. of threads per instruction a core can manage per I/O is moronic. Look at Operating Systems. They're dealing with hundreds of threads not 2x the CPU cores.

[gamerk2]

You should take a look at most of the lastest DX12 and Vulkan games.

Hitman
F1 2017
Battlefield 1
Ashes of the Singularity
Rise of the Tomb Raider

All of these games will utilize all of a i7 7700k's 8 threads at about 30% per thread. An i5 in Hitman is at capacity of 95% across its 4 cores. So, yes, games can also be highly threaded, and all thanks to the enhancements of DX12 and Vulkan.

Bolded for emphasis. DX12/Vulkan gave the ability to easily break up exactly one thread: The primary rendering thread. The rest of a games logic can't be made parallel, as the majority of the code is sequential logic (See: Amdhals Law: https://en.wikipedia.org/wiki/Amdahl%27s_law).

I also note that adding threads doesn't lead to any performance benefit unless you alleviate a CPU bottleneck in the process.

[gamerk2]

That's not a lot of threads, nor cores. To design around the maximum no. of threads per instruction a core can manage per I/O is moronic. Look at Operating Systems. They're dealing with hundreds of threads not 2x the CPU cores.

Basic rule of thumb: Is the code reasonably independent or parallel and does not require significant synchronization mechanisms? If yes, make it a thread, otherwise don't bother.

I've NEVER coded against a specific CPU architecture or code count, as that's moronic. If the code is independent, I make a thread. Otherwise I leave it alone. Forcing serial code into threads for no reason other then to make your core utilization graphs looks pretty is idiotic at best, and damaging to overall performance at worst.

[bug77]

You should take a look at most of the lastest DX12 and Vulkan games.

Hitman
F1 2017
Battlefield 1
Ashes of the Singularity
Rise of the Tomb Raider

All of these games will utilize all of a i7 7700k's 8 threads at about 30% per thread. An i5 in Hitman is at capacity of 95% across its 4 cores. So, yes, games can also be highly threaded, and all thanks to the enhancements of DX12 and Vulkan.

So basically will on a tri-core with room to spare.

[linuxgeex]

This Gigabyte board doesn't yet offer that on my TR system.

However you do have 2 options available to you still to reduce latency and increase cache coherence:

1) disable SMT by shutting down all the odd cores:

sudo su -c 'c=1; while p=/sys/devices/system/cpu/cpu$c; [[ -d $p ]]; do echo 0 > $p/online; ((c+=2)); done'

2) emulate NUMA Mode by shutting down the second CCX:

sudo su -c 'c=16; while p=/sys/devices/system/cpu/cpu$c; [[ -d $p ]]; do echo 0 > $p/online; ((c+=1)); done'

These will have the identical effect to disabling SMT or enabling NUMA Mode in the BIOS.

P.S. if you run as user "phoronix" and add this via visudo at the end of your config then you can automate it:

phoronix ALL = NOPASSWD: ALL

I know you dislike root/sudo for PTS, but really it would be trivial to have PTS test whether or not someone granted this permission for $USER when PTS starts up, and then act accordingly.

[linuxgeex]

So basically will on a tri-core with room to spare.

It's not so much about the room to spare as it is about how long the CPU takes to run the bits it needs to. Frame timings are in the low milliseconds. You want everything to do with rendering to be as near 0ms as possible. So ideally you want one completely unloaded core so that it can respond instantly for rendering. So even if the game is only loading 3 cores to 25% (25ms of a 100ms time slice) you still want a 4th because if the rendering request hits that core it's going to wait 25ms sometimes to get serviced... 16ms is 60hz refresh, so that could interfere with a steady 60fps render rate. Not always. If one core is sitting at 25% usage and busy-waiting on the rendering thread, and no core ever hits 100% for a full time slice then the kernel will never pre-empt the rendering thread even though it's behaving poorly.

[linuxgeex]

That's not a lot of threads, nor cores. To design around the maximum no. of threads per instruction a core can manage per I/O is moronic. Look at Operating Systems. They're dealing with hundreds of threads not 2x the CPU cores.

I'm not sure I've ever heard of an architecture that has a maximum number of threads per instruction greater than 1. Multiple simultaneous instructions per thread (superscalar / multi-issue execution model) is just the opposite.

Anyhow regardless of what you meant or what you think you meant, designing to the limitations of customer platforms isn't ever 'moronic'. It's called optimisation. People happily pay extra for that because it makes software work well here and now. Maybe the design decisions turn out to suck when you run it on a future platform, but we can't know the future. Nobody who worked on Pong ever put time into considering whether they should have implemented it using Vulcan on an infinite-way SMP processor. Instead it targeted a handful of discrete TTL components, that worked well, was cheap and accessible to consumers.