TR Forums

So Der8auer has apparently taken issue with the circulated claim that Threadrippers are two die and two dummy placeholders. He not only delidded a second Threadripper, but popped the dies off it for good measure. https://www.youtube.com/watch?v=N-uKQ6RfUdk

After I got done crying over the wasted hardware he did have some cool photos of the die circuitry he's posted here: http://www.mediafire.com/file/7l8nyi1q43tm3ab/TRDie.zip

And, both of his TR chips had four Ryzen die on them.

After looking at the pictures with my untrained eyes, I agree that the dies certainly appear to be "etched dies" that may or may not be "functional" (meaning: "they might work") and "may be" actual processor chips. To prove that each die truly is (or was) a functional processor chip, each die would have to be individually tested. Sadly I suspect the "delidding" process actually destroys the "viability" of the dies.

Additionally, simply proving the package had 4 dies that were actually "etched" does not prove to me that any given die was either "operational" (powered up & processing instructions) within the package, or just there and "non-operational" to spread out the load of the external heatsink-fan assembly within the package.

Therefore, I think the argument still exists that 1 or 2 dies in each package of 4 could still be a "QC failed" die. So as far as I am concerned, "the jury is still out on this matter".

It does bring back the hope of a 32 core HEDT chip.

Waco wrote:

It does bring back the hope of a 32 core HEDT chip.

I see no technical reason why they couldn't do that, but you still wouldn't be able to run more than quad-channel RAM. Wouldn't Epyc make more sense if you want more capability than Threadripper provides?

Long term I see AMD going the interposer route for their entire line up once real mass production has started. The difference between TR and Epyc is of course the IO which AMD will through in an extra IO die for Epyc. The number of CPU cores is basically limited by the size of the interposer they can make or fit into that package. Alternatively, TR could simply be Epyc with a full compliment of IO dies but some disabled due to defects or bonding issues in this scenario.

Between interposers and Intel's EMIB, the market is primed for a massive increase in how much silicon is put into a socket. I've been meaning to put something together about this to help illustrate the idea of how each company could scale their designs (and nVidia too who has done a bit of saber rattling around this principle).

just brew it! wrote:

Waco wrote:

It does bring back the hope of a 32 core HEDT chip.

I see no technical reason why they couldn't do that, but you still wouldn't be able to run more than quad-channel RAM. Wouldn't Epyc make more sense if you want more capability than Threadripper provides?

Absolutely, but many folks won't run a server board in a multipurpose build...even if the "desktop" version of the same board is identical under the hood.

All the noise about Threadripper going to 32 cores because AMD put some non-functional dies in the dummy slots of the Threadripper package is amusing, although AMD basically lied to the press when they claimed that those dummy dies are blanks.

The funny part about it is all the breathless speculation that AMD can suddenly wave a wand and turn Threadripper into a 32 core product when it's actually substantially more difficult for AMD to pull off that feat from a technology perspective than it would be for Intel to simply take a 28-core Xeon die and drop it into the LGA-2066 package.

chuckula wrote:

The funny part about it is all the breathless speculation that AMD can suddenly wave a wand and turn Threadripper into a 32 core product when it's actually substantially more difficult for AMD to pull off that feat from a technology perspective than it would be for Intel to simply take a 28-core Xeon die and drop it into the LGA-2066 package.

I think you're overstating the difficulty of enabling a few dies and understating the simplicity of dropping an entirely new Xeon onto a new (for it) socket/chipset ecosystem.

All AMD has to do is package and enable 2 extra dies. It would be best if they had a single memory channel each (total 4) but I could see them simply enabling the two extra dies and forcing them to run as remote NUMA domains from main memory. The former would take *maybe* some work, depending in implementation. The latter? It would be trivial.

Waco wrote:

chuckula wrote:

The funny part about it is all the breathless speculation that AMD can suddenly wave a wand and turn Threadripper into a 32 core product when it's actually substantially more difficult for AMD to pull off that feat from a technology perspective than it would be for Intel to simply take a 28-core Xeon die and drop it into the LGA-2066 package.

I think you're overstating the difficulty of enabling a few dies and understating the simplicity of dropping an entirely new Xeon onto a new (for it) socket/chipset ecosystem.

All AMD has to do is package and enable 2 extra dies. It would be best if they had a single memory channel each (total 4) but I could see them simply enabling the two extra dies and forcing them to run as remote NUMA domains from main memory. The former would take *maybe* some work, depending in implementation. The latter? It would be trivial.

Uh, there's nothing trivial about cramming two extra functional dies into a platform that was intentionally designed to never hook up the two non-functional dies to anything whatsoever. Hooking up a 28-core Xeon to LGA-2066 basically means routing power to the correct pins and using exactly the same pinouts for memory & PCIe that are already shipping in products right now. It's not even in the same ballpark in the level of complexity and the potential performance trainwrecks you are heading for when you cripple the connections to those "32 core" threadrippers and try to do a real benchmark that's harder than Cinebench.

TL;DR version: If you want an Epyc server, buy one. Don't pretend that the cut-down Threadripper platform is magically designed to be equivalent to an Epyc platform, because it clearly isn't.

chuckula wrote:

TL;DR version: If you want an Epyc server, buy one. Don't pretend that the cut-down Threadripper platform is magically designed to be equivalent to an Epyc platform, because it clearly isn't.

I never claimed otherwise.

I claimed that enabling two dies on an interposer that already has inter-die connections is trivial if you're willing to take the tradeoff of remote memory access for those two extra dies.

That's just it, why would AMD go through all the trouble and cost of creating a 4-die package in the first place if it didn't intend to make use of it later? It is doubling the cost of diffusing the chips since all four die/dice receive the same indium/gold plating and soldering to the IHS (and also wouldn't require the use of two non-functional die which could bite them later when yields improve).

The TR4 socket is physically identical to the Epyc's SPRv3 socket, but they aren't compatible. But if AMD had no plans to ever ship a 4-dice enabled Threadripper then why create the TR4 socket in the first place? They could've designed something smaller with a design that made Threadrippers cheaper to produce.

Kougar wrote:

It is doubling the cost of diffusing the chips since all four die/dice receive the same indium/gold plating and soldering to the IHS (and also wouldn't require the use of two non-functional die which could bite them later when yields improve).

If yields improve to the point where they don't have enough defective dies, they can start using blanks. I doubt this will be necessary though; Threadripper is a niche product, and even if yields on Ryzen are very good they will probably have a steady supply of bad ones to use as spacers. Heck, they've probably got a huge pile of them already from the initial Ryzen production ramp-up.

Kougar wrote:

The TR4 socket is physically identical to the Epyc's SPRv3 socket, but they aren't compatible.

I'm willing to be the physical differences are nonexistent, though. Firmware locked, perhaps, but it wouldn't make a lot of financial sense to stick with the huge packaging while also creating a physically different package.

Waco wrote:

Kougar wrote:

The TR4 socket is physically identical to the Epyc's SPRv3 socket, but they aren't compatible.

I'm willing to be the physical differences are nonexistent, though. Firmware locked, perhaps, but it wouldn't make a lot of financial sense to stick with the huge packaging while also creating a physically different package.

At minimum the tracing for memory would be different as it has more and they would route to the now-confirmed-dead dies (or dice if you prefer).

DragonDaddyBear wrote:

Waco wrote:

Kougar wrote:

The TR4 socket is physically identical to the Epyc's SPRv3 socket, but they aren't compatible.

I'm willing to be the physical differences are nonexistent, though. Firmware locked, perhaps, but it wouldn't make a lot of financial sense to stick with the huge packaging while also creating a physically different package.

At minimum the tracing for memory would be different as it has more and they would route to the now-confirmed-dead dies (or dice if you prefer).

On the motherboard, sure, but there's no real reason to change the package itself for that.

Waco wrote:

I'm willing to be the physical differences are nonexistent, though. Firmware locked, perhaps, but it wouldn't make a lot of financial sense to stick with the huge packaging while also creating a physically different package.

It might if it allows you to remove or simply blank out a few pesky layers from your package substrate.

Perhaps. I'm not an expert on what it costs to produce the substrates. I'd be surprised if it was worth keeping two separate parts running through two fab lines, though.