AMD ZEN 3 SPECULATION

wccftech.com/amd-milan-cpu-has-15-dies/
>It would appear that AMD is working on something very interesting. According to sources familiar with the matter they are actively working on a 15 tile design for AMD Milan. Considering 1 of these tiles need to be an IO die, this implies that there will be at least one Milan variant with 14 dies/tiles compared to Rome’s 8. Now all of these cannot be CPU tiles due to hardware limitations, according to an engineer I talked to and this is where things get exciting I might add, so some of these 14 tiles are bound to be HBM memory.

THANK YOU BASED AMD

Attached: D6dU6YQWsAI8R_A.jpg (1024x849, 107K)

Other urls found in this thread:

overclock.net/forum/10-amd-cpus/1728758-strictly-technical-matisse-not-really.html
twitter.com/NSFWRedditGif

Don't care about your speculation until an actual product is shown

Nobody needs more than dual cores...

Are all the comments on this site made by bots? Almost all of them have nothing to do with the article and the semantics looks procedurally generated.

This is the most anti-semitic post I've ever seen. Please delete it promptly.

oy vey

>HBM memory
>high bandwidth memory memory

>about the mother and the eye .well I lied , we all were waiting for that to happen but she died very young and it did not eventuate .What was sad was his mother dying or that he has to spend the rest of his life with one eye .
kek the fuck

Attached: fd51f42f53ac99f2fea832ee4b81893b868792c0992fad0c493c041b2a090c5c.jpg (1237x711, 197K)

That wont happen for a very long time because the system wont recognise all those chiplets as one gpu and you will have to deal with 8-way sli madness.

Call me when they remove the Platform Security Processor. At least people developed an application that wipes the first 4k of the ME and renders it unusable. Intel it is for me. There is no such development for AMD systems. Also the open source P9 arch will probably grow a lot in the coming years.

larp more

Attached: level map.jpg (1237x711, 192K)

>Intel it is for me
enjoy your management engine bro

Im interested to see this integrated into modern consumer cpu's

Thread should've ended here. The state of this board.

>Fuck you goy

Attached: 1544625511059.png (552x661, 288K)

Anudda shoa!

That goes for any product regardless of the brand you mongoloid.

>im not an intel shill i swear!

Attached: 1511458695816.png (672x794, 422K)

npc management engine, best irl game

>king of chiplets

>*crack* siiiiiiiiiiiiiiiiip
>intel management engine, now THAT was a good botnet

Attached: rRSfYWS.png (373x338, 96K)

So, 112C/224T Ryzen 3 server chips in the future?

Attached: mother of god.jpg (640x352, 29K)

This is bullshit. If you can create a cache-coherent CPU across multiple physical dies using Infinity Fabric, you sure as fuck could use the same approach to create a multi-die GPU that looks like a single logical device to the OS. If you look at the bandwidth figures, it works out really well because most of the bandwidth is typically between CPU and GPU (DMA) for purposes of streaming texture + geometry data from main memory. Infinity Fabric is faster than PCIe, so I see no reason a 2nd I/O die, or even a CPU-GPU integrated die with single I/O die couldn't be an approach used in future gen products. The topologies that can be enabled as a result of infinity fabric simply existing are beyond what most 'tech' people can imagine today. HBM only makes sense on-package if you need to feed a monster shader pipeline. CPUs cannot realize the same benefits a GPU can with HBM due to the OOO nature of their architecture and related memory access patterns.

and 7GHz clocks
HOLY SHIT LISA DID IT

That is quite literally why AMD developed the Infinity Fabric, brainlet.

Not a single company, whether it be Nvidia/Intel/AMD are confident that multi-die gpu's (exact same concept as gpu chiplets) will ever be recognised as one gpu unless of course there is some revolutionary breakthrough that one of them discovered that i do not know about. If thats the case, by all means post evidence, you cant just magic everything using meme fabric.

Is there actually any reason to think they will shrink the I/O die with Zen 3? 14/12nm ensures they can employ GloFo, and I'm pretty sure they still don't have anything smaller on the horizon.

AMD has to use GloFo until at least 2024 so I'd expect I/O die will remain 12nm.

>meme fabric
>actually successfully creates 1 logical cache-coherent CPU out of many physical dies
>multiple dies per package, sometimes multiple packages per system
>all 1 cache coherent cpu
>holy shit its all magic.exe
I really don't understand you kids anymore. Perhaps you just don't understand what "cache coherent" means and you are taking your retardation out on us as a result of that. Go look into it on your own time and stop shitting up this board. We don't have time to teach you basic computer architecture.

>cpu
>cpu
>CPU
Holy fucking shit, i have said "gpu" on both posts. Yes Mr durga, on cpu's it works magic but one letter makes alot of difference.

Wow! That’s a neat idea; it looks like AMD is trying really hard to close the massive performance gap between its CPUs and equivalent Intel® offerings. Unfortunately, Zen 3-based processors will still be outperformed by their Intel® counterparts in real-world performance tasks like gaming and productivity.

What is so fundamentally different about a GPU that makes sharing its state impossible over an 80GB/s link, when a CPU which is capable of far more internal memory bandwidth than said GPU has no issues with keeping its state consistent? Consider that question carefully before you type another word into your keyboard.

>What is so fundamentally different about a GPU
Just the sheer number of cores we're talking about. Thousands of shader cores clustered into tens of various kinds of execution units.

holy BASED

Latency. GPUs do real time computing. Any latency is a barrier towards that. Sure on the face 30ns may not look like much but over thousands or tens of thousands of cache operations across the cores and suddenly it becomes a big delay

7nm+ or 6nm for Zen3?

Attached: AMD-Zen_3.jpg (800x450, 31K)

you are retarded and should kys, CPUs are the ones that are very sensitive to memory latency, not GPUs, GPUs benefit from having a lot of bandwidth, not latency, because they can just do other work while waiting for memory contents to be read, there's plenty more of it to fucking do!

Fuck you goy

>because they can just do other work while waiting for memory contents to be read
It's not memory it's cache you retard. Every time you cross a die it's a penalty on cache access. That automatically makes it a weakness for real time processing.

>CPUs are the ones that are very sensitive to memory
You have 0 clue what you're talking about. Most CPU loads are virtually latency independent because they don't have a strict time limit. Only games come close and only for draw calls and sure enough in games where draw calls are a bottleneck zen 2 still loses to intel counterparts despite having higher IPC

Somehow, none of the gpu companies has managed to solve this.

Zen1 and Zen2 are 17h family.
Zen3 however is not. That means the architecture is distinct enough to be in its own family. Mark Papermaster has mentioned that Zen3's focus will be on energy efficiency as well.

Will be interesting to see how it plays out. They're definitely not going for higher clocks if they're targeting better perf/watt.

>HBM on die
Basically Intel is dead.

>They're definitely not going for higher clocks if they're targeting better perf/watt.

n7+ (EUV) was stated to have 10% higher performance over n7 (DUV). Or 15% lower power. They can totally go for higher clocks on desktop

The power density of the chiplets is already ungodly high, and any increase in density at all will compound the situation. Staying at the same thermal density for an actually laughable 10% clock increase isn't a winning situation.
Improving IPC enough to facilitate equal or better performance at lower clocks is.

>According to sources familiar with the matter
[citation needed]

4.7 + 10% = 5.2GHz

You'd see a marginal improvement in base clocks, not peak XFR.

5GHZ!

You forgot the car park around the outside.

>The power density of the chiplets is already ungodly high
It's not though.

>and any increase in density at all will compound the situation
Density of a node is adjustable by the layout library. Neitehr Zen 2 nor Navi are anywhere close to the max density the node can achieve.

>Staying at the same thermal density for an actually laughable 10% clock increase isn't a winning situation
It is because Zen 2 is perfectly fine.

>Improving IPC enough to facilitate equal or better performance at lower clocks is.
There's a not a lot of room for improvement. Intel's idea was to basically just count vector workloads and average it out to say they got higher IPC. AMD isn't much different which is why even with close to 10% higher multi-core clocks and 15% IPC improvement you barely see like 10% improvement in workloads like games

WE LIVE IN A SOCIETY

/thread

>It's not though.
Why even bother posting when you're going to deny an object fact? I can instantly discount you as an 80IQ black retard.
overclock.net/forum/10-amd-cpus/1728758-strictly-technical-matisse-not-really.html

>The biggest limit is the intensity (heat per area), secondly the voltage you can safely feed to the silicon.
>For example, the 9900K which has a reputation of being an inferno, has theoretical intensity of ~1.15W/mm2 when operating at 5.0GHz (200W @ 174mm2).
>Meanwhile Matisse can easily reach intensity of > 1.5W/mm2 (120W+ @ 74mm2)

Dipshit.

>posts some garbage about overclocking which by design breaks the thermal limits of a node
>HURRR IT'S A PROBLEM
Delusional

>get BTFO for being a retard
>makes an unironic loq IQ retard post to try and save face somehow

LMAO, stay black.

>T-THEY CAN'T INCREASE FREQ ON A NEW NODE THAT ALLOWS FOR 10% HIGHER CLOCKS AT THE SAME POWER REEEEE
>that's wrong retard
>B-BUT MUH OVERCLOCKING THAT BREAKS NODE PARAMETERS YEYEYEYEYEYEYE

kys retard. Overclocking has 0 bearing on improvements of n7+, you revealed yourself to be a retard so you started trying to shift goalposts to overclocking because you can't even understand what anyone's talking about like some sort of mentally retarded dog.

You're sitting here trying to claim thermal density on the chiplet isn't an issue. It is. Theres nothing else to this.
Very marginally increasing clocks at iso power and keeping thermal density the same is a losing move.

Antisemitism

So.... 6nm or 5nm for Zen 4?

Zen 3 (ryzen 4000 series) is already taped out. The Zen 4 design is nearing the finalized stage.

Watch what tsmc is pitching. They are already working on their EUV process 5-3nm.

6nm is for ARM SoCs, vendors can directly port over 7nm designs. It isn't compatible with the 7nm HPC track.
Zen4 will be a 5nm part.

What about what says though? Will we have 5nm or even smaller chiplets with a fuckin' 12nm I/O die?

Power draw of the Bridge Chip is pretty low, though it can pull up to 22w~ peak. They'll probably have to offer a smaller version of the Bridge Chip as a matter of necessity.
We already know that 5nm Genoa will be offering 10 channel memory. Its likely that the Bridge Chip used by Genoa will be on another process.

I pretty sure they will switch to 7nm but they still may use glofo for system board chips or other things. Idk the may still use glofo but I don't know for what. There were still on going talks between glofo using Samsung's euv upcoming process.

Uncore is up to 30w~ on the 3900X

>There were still on going talks between glofo using Samsung's euv upcoming process.
Hmm I see, I guess they could just license another Samsung process again, but then again they may not want to do that. One of main reasons they dropped their 7nm that they stated was too high equipment cost to refit even one of their fabs for 7nm, and licensing soemone else's process doesn't change that at all.

Global Foundries isn't going to start running a 7nm EUV line just for AMD. They're quite comfortable with how they've diversified.

>10 channel memoery?
Have a snack to back that up?
Also I think it's more just a case of cost. The current IO chip is pretty big as it is. A 450mm^2 14nm die is probably cheaper than 250ish 7nm right now, might explain why it was economical to go for the more expensive 12nm for the ryzen3000. Thinking about it I hope the 12nm io isn't the main factor in faster memory support, threadripper 3 will be using the same controllers as epyc which are not tailored for desktop use.

>speculation
Intel taught us through spectre and meltdown that speculation is a bad thing.

>Have a snack to back that up?
Just thinking about it, we're talking 64+ (128? Who knows) fast cores, you gotta feed that somehow.

Samsung 3nm

Charlie from SA claimed to have seen samples and they were 10 channel memory

I'd have though that more memory channels becomes a problem, even the physical layout of 2p 8c 1dpc is the same width as a rack mount case.
2021 should bring more options with ddr5, on package memory and potentially gen-Z serial memory interfaces.

kek

will zen3 use am4 ?

>it looks like AMD is trying really hard to close the massive performance gap between its CPUs and equivalent Intel® offerings.
> AMD nerfing their performance, so Intel can catch up

Attached: the fat controller laughed.jpg (600x480, 38K)

>There is no such development for AMD systems.
Ryzenfall literally lets you replace the PSP firmware with whatever you want. Including nothing but a bootstrap stub to initialize the processor.
Though nobody bothers because unlike the IME, the PSP in its default configuration doesn't send or react to anything on the network port.

heard that before zen2 dropped and look where we are now

There are two main things:
1: There's not just memory accesses that are hiding behind one GPU command processor, but also thread and fragment distribution. The thread manager needs extremely low latency to its subordinate SIMDs, so if you were to distribute a GPU over several dies, you'd need a thread manager per die, but distributing work across the SIMDs also requires low-latency access to their current state in order to have efficient load balancing. It's very important that, for instance, nearby fragments get processed by the same SIMD, not just for data locality, but also to order early fragment tests like Z testing.
2. GPUs use an absolute asston more bandwidth than CPUs, especially as measured outside the CPU L3 cache. Running all that bandwidth on one shared fabric would be an utter bottleneck; with anything less than n^2 full-bandwidth transceivers in the system.

>HBM
How the heck do you do an IHS then?

3nm

GAAs will not be volume production in 2021.

>They're quite comfortable with how they've diversified.
Are they? The recent lawsuit against TSMC bears all the signs of a dying company.

>Neitehr Zen 2 nor Navi are anywhere close to the max density the node can achieve.
Citation needed.

ill doubt that, something like 5ghz or maybe 5.5ghz would be nice

holy fucking latency
and of course instead of addressing the problem AMD just goes "MOAR CACHE!!"

what's the point of HBM when IF is slow af?

how are you supposed to adress it w/o increasing cache size mr. chipdesigner?

>Ryzenfall
wasn't that a mostly fud/made up thing from that one "research firm" that found "vulnerabilities" and gave AMD a whole 24hrs before going public on it?

yea im gonna believe those guys

None of it sounds too farfetched, but it's wccftech, so who knows.

there's that hardware level ai shit people are working on that can make non multithreaded workloads multithreaded.

>server CPUs

i'm literally an AMD fangay and i don't give a shit about this, tbqh

Threadrippers are cut-down EPYCs, user.
Trust me, you care.

people have been trying to do that forever, i don't think sugar coating it with ai / meme learning buzzwords will help much

Ryzenfall is an actual thing. You can exploit a vulnerability in the PSP to overwrite the firmware with whatever you want and have it actually work instead of bricking the machine, without needing it to be signed by AMD. The reason it's considered FUD is because you need physical access to the machine to do it, which is pretty much game over from a security standpoint anyway.

Has anyone used this to load a small ARM OS on it? Maybe to run ARM code natively?

It was 'real' as in it was a real thing in the processor, but it was a very minor issue. Basically, once you'd already owned a system, gotten root and physical access, and you stole a manufacturer signing key, and the stars align, you can add your own code to their security sub processor and add a backdoor in the hardware that will be persistent.

Those conditions though are basically like someone can break into your house, steal everything you have, steal your identity, and once they've done all that, they can copy your keys.