threadripper has 4 dies

It seems like you missed the entire point.

>>61706484
only 2 are in use. the other ones are either dead or just diabled.
AMD has been doing this for some time as I heard

>>61706484
they are cut down epyc cpu's, probably out of spec dies or ones that have fucked mem controllers or cache

>>61706497
>>61706569
if 2 cores are disabled why solder all 4 of them

>>61706819
You mean put 4 of them on the package? wafer tests only get you so far, voltage leak binning and cache miss freq get tested when they are in package.

if they fall outwith spec they can just be disabled

If you are talking about soldering the dies to the IHS then its for heat soak/better thermals

G L U E D T O G E T H E R

L

U

E

D

T

O

G

E

T

H

E

R

>>61706919
U M A D E L I C I A

M

A

D

E

L

I

C

I

A

>inb4 somebody finds a way to re-enable them

>>61707193
We're going back to the Phenom 3-core days

>>61706484
They're spacers unless one of the original 2 turned out to be duds.

>>61706484
Apparently that's only the case for the engineering samples, retail product will have 2 dies but yet to be seen unless he delids a retail one

>>61706819
>if 2 cores are disabled why solder all 4 of them

They share the same production line.

>>61706819
>>61706497
The only active dies are two on the diagonal. The other two are just spacers, not failed components.

>>61706484
>>61707193
I thought 2 of these are just slabs of metal, not actual cores

>>61706484

32 core ThreadRippers on Zen2 5nm IBM wizardry for 5GHz peak efficiency clocks

mark my fucking words.

Meanwhile, Intel is stuck on 14nm+++++ for the fourth generation in a row

>>61707179
A L B E R T O B A R B O S S A

L

B

E

R

T

O

B

A

R

B

O

S

S

A

>>61707259
>>61707261
Oh, I didn't know what spacers were.

>>61707283
It's so the heat spreader applies even pressure to the actual CPU dies when there is some heatsink or water block mounted.

File: 1496054075333.jpg (510KB, 1315x794px) Image search: [Google]

510KB, 1315x794px

>>61707270

POOP IN YOUR FIST

>>61706484
Listen here
In Manufacturing, making the same part that fits multiple applications; is drastically cheaper than 3+ separate products.

Any epic chip that fails can be 50% disabled and sold as thread ripper.

>>61707270
>5GHz peak efficiency clocks
I want to believe this.
But 5.0ghz on high core count Chips isn't gonna happen.

File: current zen node vs zen2 node.png (129KB, 1562x332px) Image search: [Google]

129KB, 1562x332px

>>61707669
It'll hit 5ghz on overdrive voltage (which is also lower for 7nm LP compared to 14nm LPP).

>>61707259
>on the diagonal

source? They could want them to be closer for easier communication.

>>61707693
A PowerPoint slide doesn't mean anything senpai.

I've been hearing the 5.0ghz meme for a long ass time.

>>61707802
It means everything when it's a PowerPoint slide directly from GloFo themselves.

>>61707819
gloflo have a record of overpromising and underdelivering

>>61707841
Obviously, but 7nm LP was acquired with IBM's semiconductor business.

>>61707819
Oh and Intel's slides are super accurate as well......

>>61707745
Having them on opposing corners would spread heat more evenly across the spreader.

>>61706484
1. Every extra step in production is considerably more expensive than material waste, one line, one product = cheap.
2. Epycs that didn't pass binning can become TRs.
3. Even if an entire die is bad, the chip is still usable, but if it had two chips total and a die went bad, it would be in the garbage bin.
4. Cores are deactivated on a per-CCX basis to maintain the full featureset of the CPU, so with a bad die you would actually lose PCI lanes, RAM adressability, and cache. Since TR has half of Epycs' features, it can afford to lose a die or two and still work, even though yields should be so good that it shouldn't happen.

Long story short - AMD has a way of making sure every singe piece of silicon makes its way to market no matter how bad it's fucked up in the factory.

>>61706484
So they can release 24 and 32 core versions in the future without any effort or changing the socket every 6 months like Intel is currently doing. It's called planning ahead.

>>61708099
First point is right, rest is bullshit considering they test and bin the dies before they put them on the pcbs, anything else would be retarded.

>>61708109
I wouldn't count on 24-32c threadrippers anytime soon. They'd be competing with their own server chips if they did that.

>>61709700
They already do in terms of performance. People get EPYC for the support, 128 lanes and enterprise features like RAM encryption

>>61708109
Intel is planning ahead. Selling a new platform every year squeezes more money out of the market. Want a new CPU? Better buy a new mainboard with our chipset, with all the new features we offer there was no way we could make it backwards compatible :^)

>>61707802
Keep dreaming. I really don't believe this shit will happen the same way amdrones think. They will surely reap better clocks, but reaching 5 GHz as a feasible frequency for 8+ cores will need a ton of power.
This don't even counting yields.
>Muh amd cores are small and will be even smaller

Process on a new node always begin with shitty yields. Also smaller feature scale make dies even worse to produce.

The magic you expect will turn to a new 14nm node as zen2. Screen cap this.

>>61711112
t. Brian "JUST FUCK MY FOUNDRIES UP" JUSTnich

>>61708077
That is not the meaning.
The thing is advancing node to 10/7nm will be a bitch and Intel is already dealing for a time with shitty yields, even on smaller dies.

>>61711145
You do remember how much time it took to gpus to arrive on 14nm?
Intel had significant delays on 14nm. It took rven more time to make it better.

Advancing to 7/10nm isn't child play. Intel has an endless coffer and it's still stalling
Glofo tsmc needed a long time for 14nm. Samsung too.

It's not like magic will happen out of thin air.

>>61709700
Didn't say soon. Eventually we'll see 7 nm dies with 6 cores per CCX but maybe in between the current generation and then we'll see 24c/48t Threadripper v2. Not guaranteed but the option is there.

>>61711329
Intel's 10nm is pure, unrelenting, shit.
That mask count is something beyond redemption.
Cald down Brian, your foundries fucked up.

>>61711329
>Advancing to 7/10nm isn't child play.
It becomes easier once you get access to IBM's IPs

>>61706484

Capacitor are missing around 2 "dies".

Probably they are just dummy dies.

Why? I have no idea.