makes for an interesting backward compatibility discussion I guess. I now question whether not having the same number of available concurrent threads (ie 4 Ryzen + HT makes 8 threads, but only 4 are active) may not play well with ND engine.
Next Generation Hardware Speculation with a Technical Spin [2018]
- Thread starter Tkumpathenurple
- Start date
-
- Tags
- 5 bytes
- Status
HBRU
Regular
ok... But how many are they going to sell? It may be a necessity. I remember a time when Sony developed Cell... Improving an existing Architecture with maybe adding more cache, adding AVX512 while shriking to 7nm is sure much simpler than Cell development... Also costs may be shared between Sony and Ms
I don't know if they are totally positive on that this time...
Clustered multithreading sounds like Bulldozer or its ilk, with shared front ends and FPU.
A Jaguar cluster is 4 separate cores and shared L2.
The Jaguar module and Zen CCX have some correlations. A CCX gives the same or more L1 cache, and while not shared their L2 capacities match. Zen's L3 is extra capacity, and the shadow tags serve a purpose close to the shared L2 of Jaguar.
At least the first revision of Zen, the quad-core module and mostly equivalent poor memory and cross-module latency also carries through.
One thing I was wondering about was if there were benefits from SMT in maintaining data locality. For example, is there any benefit to assigning multiple tasks that use the same data to a pair of virtual cores that run on the same physical core?
@mrcorbo
I'd hazard a guess and say "probably no, or not very much", as if you have the data you need in cache, then the thread will be working on that data, so having two threads working on the same data using the same hardware resources likely isn't going to bring much, if any benefit.
The way I understood multithreading is it helps when threads stall on memory accesses, because the other thread might have data loaded into cache already which it can process while the first thread's data start trickling in from memory...
I'd hazard a guess and say "probably no, or not very much", as if you have the data you need in cache, then the thread will be working on that data, so having two threads working on the same data using the same hardware resources likely isn't going to bring much, if any benefit.
The way I understood multithreading is it helps when threads stall on memory accesses, because the other thread might have data loaded into cache already which it can process while the first thread's data start trickling in from memory...
Yop that is a lot of transistors though lots of cache so it turns out that both ZEN powered Chip we've seen are around 5 billions transistors and 210mm2. Density ain't bad, according the same data (wiki) a cpu cluster and its 8MB of L3 is around 44mm2.
Say you remove a cluster, you are around 170mm2 with a 11/16 GPU and a dual memory controller, so some room to go before you reach the size of the PS4 Pro and XBX SOCs (325mm2 and 360mm2).
Not a great issue if at all looking at the massive increase in CPU perfs.
Price for one thing. Performance per dollar is more important for a console than performance per watt.
monstercameron
Newcomer
Maybe I’m the only one with this dream but why not a snapdragon soc (or something similar) connected to a fixed function (task specific) hardware raytracer. The raytracer would only do the heavy lighting passes(raytraced shadows, global illumination, etc) and the gpu on the soc would do everything else. So the only R&D would be custom raytracing hardware, that only traces rays.
I don't think very many mainstream devs are interested in a platform with hugely different performance characteristics and method of function compared to what is tradition. Maybe such a setup would be a big hit with the Jeff Minter-type indie crowd, but when middleware and content production software are all geared towards 3D rasterizers, and especially, when a blockbuster-type game costs $100+ million to produce, you don't want to fuck around.
monstercameron
Newcomer
You’re probably right, I’m just looking forward to the next gen...
This seems like the route to go https://github.com/justingallagher/fpga-trace
I remember reading the Amiga CD32 used a 256 bit FPGA for its planar <> bitplane conversion. Can't back that up though.
Hm, I thought it was built into one of the system chips used in that device... It seems overkill to use a FPGA just for that, but I'm not dismissing the possibility... The CD32 always was a 2-bit device, and Commodore basically had very little to no money at that stage due to the incredibly inept company "leadership" (read: corporate thieves!) which was more interested in reaching into company coffers and helping themselves to all the money and benefits they could stuff into their big greedy pockets, than doing anything even approaching even a decent, much less good job. Maybe they simply couldn't spare the expense to make a proper ASIC for the task.
Gods, it still boils my blood to this day how those fuckers crashed and burned my favorite of all time computer company. I was such an Amiga fanboy, you wouldn't believe. ...Well, maybe you would! lol *runs and hides in shame*
Sidenote: the Super Magicom which I certainly never owned for my SNES did absolutely use a FPGA for its core functionality
The Akiko chip is what I'm seeing everywhere, but I recall a magazine at the time (back then there wasn't much internet!) saying a 256 bit FGPA, and explicitly stating it could be reprogrammed/repurposed. May have been bollocks, but it was a proper magazine and not some brainless trendy gaming one (Amiga User International?), and back then journalism was actually a real profession and they could be expected to do a little research instead of parroting stuff from Twitter and reddit.
Possibly the prototype used an FPGA and eventually they went with a fixed function ASIC? Or I'm hallucinating memories? Searching is made harder by lots of mention of Amiga's emulated on FPGA hardware.
Possibly the prototype used an FPGA and eventually they went with a fixed function ASIC? Or I'm hallucinating memories? Searching is made harder by lots of mention of Amiga's emulated on FPGA hardware.
I don't think that can be answered without an idea of what density we'll get at the production node used. It's more about mm^2 silicon than number of transistors.
https://forum.beyond3d.com/threads/console-die-sizes.53343/
Die sizes mm^2
Xbox ~230
360 ~360
XBO ~360
XBOX ~360
GameCube ~150
PS2 >500
PS3 ~500
PS4 ~350
Interesting observations there about efficiency of the silicon, and how much more Xbox achieves per mm^2 than PS. Taking the sane mid-ground, 350 mm^2 seems a good spot for a console. So the estimate would be however many transistors fit into 350 mm^2 on whatever process is used. Consoles using more area than that have been loss-leaders.
https://forum.beyond3d.com/threads/console-die-sizes.53343/
Die sizes mm^2
Xbox ~230
360 ~360
XBO ~360
XBOX ~360
GameCube ~150
PS2 >500
PS3 ~500
PS4 ~350
Interesting observations there about efficiency of the silicon, and how much more Xbox achieves per mm^2 than PS. Taking the sane mid-ground, 350 mm^2 seems a good spot for a console. So the estimate would be however many transistors fit into 350 mm^2 on whatever process is used. Consoles using more area than that have been loss-leaders.
- Status
