I have read creative 22fdx soi bd excavator ideas weekly for 5 years plus. That's all good. But history have shown next to nothing happened. It went the excact other way. I think it's time to depart from it.True, but you and I have no clue about how to manage these costs for AMD, and if there's one thing that's really bad for business it's saving as much as possible. If you want to grow and seize market opportunities, you need to spend money. There's no way around it.
AMD has a very good place to get money from: about $6.5B revenue in 2018. And it has a very good idea what to do with it: spend it on R&D. As I said before: "most arguments against it are only speculations based on what people think AMD should do". And if your only argument is that cost cutting is important, well, that's really bad business if it leaves a company short of a competitive product in a specific market.
In the end, AMD has a lot more data for making that decision. The only point I'm trying to make is that what makes sense to you isn't necessarily the right decision, because your speculation isn't based on any facts, and the fact that your arguments get more vague underlines that.
The only way BD survives is to add L3 cache on the APU
The total investment for a 22FDX CPU, a 22FDX GPU, and a 22FDX APU. Would ultimately fit within a single 14-nm project.
In most cases, the 22FDX CPU can re-use 14-nm Matisse I/O die and re-use a modified Orochi floorplan. Orochi didn't have a Northbridge or Southbridge, just HT links and DDR.
Orochi L3+uncore - 192.4 mm squared => There is no need for on-die L3/DRAM and needed HT links would be converted to Infinity Fabric links.
Orochi modules - 123.6 mm squared => (28nm) 78 mm square mm
https://blog.globalfoundries.com/wp-content/uploads/2018/12/AI_blog_2.jpg
While, the 7LP 3D SRAM project is switched to FDX 3D SRAM project.
2 x >78 mm squared CPU dies with each CPU having a 1x >36 square mm SRAM stack. With 1H-4H SRAM being 8(4@min) to 32(16@min) Megabyte high
The only way BD survives is to add L3 cache on the APU
Even with a big L3, Bulldozer sucked.
BR and Stoney are nothing more then reheated 28nm Carrizo.
$40M is not a trivial amount of money, and in the past they've been very disciplined about such bets. Almost all of their projects were either: (a.) doubled up with server (or higher volume embedded) or/and pretty long lived products (b.) ~ 3 to 6 years. For example Vishera (bigtime: a+b), Kaveri (barely: b), Carizzo/BR (a+b), Stoney (barely a+b), RR/Picasso (b), Summit (a), Pinnacles (b), and all of their GPU projects (a).
Excavator shows over 30% IPC improvement in some tasks over previous construction core architectures (see Anandtech's comparison for example, but it was also shown in other tests, IIRC at Notebookcheck). Excavator has a very small cache, so a bigger cache should help that IPC improvement shine in more cases.
It also showed some regressions compared to Kaveri here and there.
The regressions are likely because of its smaller cache size (1MB per module vs. 2MB for previous architectures). That was the point of my post, that Excavator with a larger cache would likely be a decent performer.
True, it would still be slower than Zen, but I think it would be closer to Zen than to Piledriver (which is what the 52% faster figure refers to).
And while increasing the L2 cache size would improve hit rate, it would also make L2 latency worse.
Good point, but considering that faster L2 cache wasn't part of the architecture advancements discussed for Excavator, I'm not sure there's a significant difference there.
Lower latency was mentioned in the marketing slides.
That s latency of the cache..
A comparison clock/clock of Piledriver/Kaveri/Excavator :
http://www.planet3dnow.de/cms/18564...cavator-leistungsvergleich-der-architekturen/
And among others IMC latency :
Obviously there s a big difference between PD and XV, the AIDA tests display much improved theorical max throughput and it s not entIrely due to AVX2.
Lower latency was mentioned in the marketing slides.
But in the context of the L1 cache (which got larger). It's possible that it does refer to L2, but I see no particular reason to interpret it that way.
True, it would still be slower than Zen, but I think it would be closer to Zen than to Piledriver (which is what the 52% faster figure refers to).
I know, I was discussing the latency of the L2, that's why I posted that image But yes, overall memory latency got worse for some reason. Different memory controller, perhaps? Didn't AMD move to some generic IP on Carrizo, instead of their in house IMC on Kaveri?
The article i linked has a relevant slide, actually latency is the same as Kaveri at the L1 level, nothing is said about the L2 but considerig the clock gating implementation it s likely slower latency wise.
Besides the smaller L2 will increase reliance on main memory pool, at some point this will be a limiting factor for IPC vs frequency, indeed increasing substancialy the CPU throughput/Hz but halving the L2 was contradictory and undoubtly dictated by the economics...
https://www.planet3dnow.de/cms/wp-content/gallery/amd-carrizo-techday/11-Carrizo-Architecture.png
I do suspect there is a lot more Excavator in Zen then commonly realised. But that is pure speculation on my part.
If Windows could handle the scheduling, I wouldn't mind a BIG.little hybrid of those two.XV ~ 115M transistors inclusive caches.
jaguar ~ 30M per core inclusive caches
On the topic of production cost- take a look at the actual layout of the Raven Ridge die:
Notice the large amounts of space that are devoted to neither the GPU nor the CPU. Now imagine that the GPU was cut down by 8/11ths (from 11CU to 3CU), and the CPU was cut down by half (from 4 core to 2 core). You still need all the other stuff in place to manage IO, decode video, etc. At that point the two CPU cores really aren't that big a part of the remaining die area- the non-CPU, non-GPU part is a much bigger proportion of that cut down die.
Now compare that theoretical die with one that replaces the two Zen cores with a (shrunk and tweaked) Excavator module. Is the die smaller? Sure, but not that much smaller. All the non-CPU stuff hasn't shrunk. Is the dramatic loss in system responsiveness worth that small tradeoff in die area? Is the slight saving in production costs worth the millions in up-front costs to port Excavator to 12nm FinFET, instead of reusing Zen?
If Windows could handle the scheduling, I wouldn't mind a BIG.little hybrid of those two.
Even with all those improvements, it still lags behind a Core i3 Sandy Bridge from 2011. And while increasing the L2 cache size would improve hit rate, it would also make L2 latency worse. There's a good reason why Zen has a small L2, backed up by a large L3.
At least as far as Integer (or mixed int-fpu) it's no contest. 2c/4t Sandy is outclassed by 4c/4t XV in multithread.
https://browser.geekbench.com/geekbench3/compare/8705545?baseline=7350750
The only win for Sandy is memory performance, and a few limited single thread int and fpu tests.