AMD released Threadripper CPUs in 2017, built on the same 14nm Zen architecture as Ryzen, but with up to 16 cores and 32 threads. Threadripper was widely believed to have pushed Intel to respond with the release of enthusiast-class Skylake-X chips with up to 18 cores. AMD also released Epyc-branded server chips with up to 32 cores.
This week at Computex 2018, Intel showed off a 28-core CPU intended for enthusiasts and high end desktop users. While the part was overclocked to 5 GHz, it required a one-horsepower water chiller to do so. The demonstration seemed to be timed to steal the thunder from AMD's own news.
Now, AMD has announced two Threadripper 2 CPUs: one with 24 cores, and another with 32 cores. They use the "12nm LP" GlobalFoundries process instead of "14nm", which could improve performance, but are currently clocked lower than previous Threadripper parts. The TDP has been pushed up to 250 W from the 180 W TDP of Threadripper 1950X. Although these new chips match the core counts of top Epyc CPUs, there are some differences:
At the AMD press event at Computex, it was revealed that these new processors would have up to 32 cores in total, mirroring the 32-core versions of EPYC. On EPYC, those processors have four active dies, with eight active cores on each die (four for each CCX). On EPYC however, there are eight memory channels, and AMD's X399 platform only has support for four channels. For the first generation this meant that each of the two active die would have two memory channels attached – in the second generation Threadripper this is still the case: the two now 'active' parts of the chip do not have direct memory access.
This also means that the number of PCIe lanes remains at 64 for Threadripper 2, rather than the 128 of Epyc.
Threadripper 1 had a "game mode" that disabled one of the two active dies, so it will be interesting to see if users of the new chips will be forced to disable even more cores in some scenarios.
Game authors _could_ use massively multi-threaded processing for many things (think: processing NPC logic and decisions), but game authors are driven by the mass market: what does their buying audience have access to, so, no, I doubt many game authors are going to go massively multi-threaded anytime soon. Lots of "gaming systems" are still just dual core.
If they develop their games on workstations, and test them on both the workstations and dual or quad-core PCs, they should be able to design engines/games that use even as many as 64 threads. Games like Skyrim ran pretty well on low-end systems as well as high-end systems. That's the way it should work: set your minimum requirements, as low as possible if you want to ensure people can at least run it, but scale to use everything available.
While Steam stats show many 2-4 core users, we now have 6-8 core "mainstream" chips from both AMD and Intel. The latest consoles also allow game developers to access about 6-7 of the 8 cores. The writing is on the wall, and people should design their stuff to work well with 64 or more threads even if customers don't have that yet. Even if the utilization is just running some basic parallel RadiantAI type stuff on every thread, but doing most of the work on 4 cores, so be it. The bleeding edge users should be able to enjoy a game mode that allows for thousands of NPCs.
people should design their stuff to work well with 64 or more threads even if customers don't have that yet
Who do you think runs EA, Activision and UbiSoft? Where's their motivation?
I agree with you, but I don't think that they do.
The current question tends to be : Will it run on Xbox/PS4 at reasonable settings, and how much does the extra PC eye candy cost ?
massively multi-threaded processing for many things (think: processing NPC logic and decisions),
Many games have a multiplayer option. So a popular way to reduce bandwidth is that the NPC logic and decisions are actually deterministic based on committed player input - which doesn't take that much bandwidth. The same actions by the same players at the same time will have the NPCs doing the same exact things. If the NPCs were not so deterministic the various client PCs will have to send each other zillions of detailed updates of the various independent NPCs, instead of mainly only sending the player actions to each other.
Making it massively multithreaded AND deterministic is possible but not so simple if you actually want it to be faster... And even less simple if you want it to be seem even more intelligent...
You could have the game work differently depending on whether it's multiplayer or single player but that adds to the complexity.
Intelligent NPC, now there's an Oxymoron, if I ever saw one.