Friday, March 6th 2020

AMD Announces the CDNA and CDNA2 Compute GPU Architectures

AMD at its 2020 Financial Analyst Day event unveiled its upcoming CDNA GPU-based compute accelerator architecture. CDNA will complement the company's graphics-oriented RDNA architecture. While RDNA powers the company's Radeon Pro and Radeon RX client- and enterprise graphics products, CDNA will power compute accelerators such as Radeon Instinct, etc. AMD is having to fork its graphics IP to RDNA and CDNA due to what it described as market-based product differentiation.

Data centers and HPCs using Radeon Instinct accelerators have no use for the GPU's actual graphics rendering capabilities. And so, at a silicon level, AMD is removing the raster graphics hardware, the display and multimedia engines, and other associated components that otherwise take up significant amounts of die area. In their place, AMD is adding fixed-function tensor compute hardware, similar to the tensor cores on certain NVIDIA GPUs.
AMD Datacenter GPU Roadmap CDNA CDNA2 AMD CDNA Architecture AMD Exascale Supercomputer
AMD also talked about giving its compute GPUs advanced HBM2e memory interfaces, Infinity Fabric interconnect in addition to PCIe, etc. The company detailed a brief roadmap of CDNA looking as far into the future as 2021-22. The company's current-generation compute accelerators are based on the dated "Vega" architectures, and are essentially reconfigured "Vega 20" GPUs that lack tensor hardware.

Later this year, the company will introduce its first CDNA GPU based on "7 nm" process, compute unit IPC rivaling RDNA, and tensor hardware that accelerates AI DNN building and training.

Somewhere between 2021 and 2022, AMD will introduce its updated CDNA2 architecture based on an "advanced process" that AMD hasn't finalized yet. The company is fairly confident that "Zen4" CPU microarchitecture will leverage 5 nm, but hasn't been clear about the same for CDNA2 (both launch around the same time). Besides ramping up IPC, compute units, and other things, the design focus with CDNA2 will be hyper-scalability (the ability to scale GPUs across vast memory pools spanning thousands of nodes). AMD will leverage its 3rd generation Infinity Fabric interconnect and cache-coherent unified memory to accomplish this.

Much like Intel's Compute eXpress Link (CXL) and PCI-Express gen 5.0, Infinity Fabric 3.0 will support shared memory pools between CPUs and GPUs, enabling scalability of the kind required by exascale supercomputers such as the US-DoE's upcoming "El Capitan" and "Frontier." Cache coherent unified memory reduces unnecessary data-transfers between the CPU-attached DRAM memory and the GPU-attached HBM. CPU cores will be able to directly process various serial-compute stages of a GPU compute operation by directly talking to the GPU-attached HBM and not pulling data to its own main memory. This greatly reduces I/O stress. "El Capitan" is an "all-AMD" supercomputer with up to 2 exaflops (that's 2,000 petaflops or 2 million TFLOPs) peak throughput. It combines AMD EPYC "Genoa" CPUs based on the "Zen4" microarchitecture, with GPUs likely based on CDNA2, and Infinity Fabric 3.0 handling I/O.

Oh the software side of things, AMD's latest ROCm open-source software infrastructure will bring CDNA and CPUs together, by providing a unified programming model rivaling Intel's OneAPI and NVIDIA CUDA. A platform-agnostic API compatible with any GPU will be combined with a CUDA to HIP translation layer.
Add your own comment

30 Comments on AMD Announces the CDNA and CDNA2 Compute GPU Architectures

#1
R0H1T
AMD haven't specified which version of 7nm they'll use or if they'll even use 7nm EUV at all, btw TSMC 7nm has 3 variants.
Posted on Reply
#2
Assimilator
When NVIDIA did it, the cry from the red fanboys was "ngreedia is ripping you off!!!!!!111one". I very much look forward to seeing the mental gymnastics they'll put themselves through to justify "their" team doing the same.
Posted on Reply
#3
R0H1T
Doing what exactly? Nvidia, besides being rightly slapped with multiple class action lawsuits over the GTX 970, was involved with screw-gate, BIOS (drivers?) updates killing GPUs, then killing OCing on notebook(?) GPU but then backtracking after user backlash among many others. You really have to be "specific" what you think AMD will do to screw their user base!
Posted on Reply
#4
IceShroom
R0H1T
Doing what exactly? Nvidia, besides being rightly slapped with multiple class action lawsuits over the GTX 970, was involved with screw-gate, BIOS (drivers?) updates killing GPUs, then killing OCing on notebook(?) GPU but then backtracking after user backlash among many others. You really have to be "specific" what you think AMD will do to screw their user base!
What problem you are talking about?? Aren't those are AMD's problem??
/s
Posted on Reply
#5
Frick
Fishfaced Nincompoop
Assimilator
When NVIDIA did it, the cry from the red fanboys was "ngreedia is ripping you off!!!!!!111one". I very much look forward to seeing the mental gymnastics they'll put themselves through to justify "their" team doing the same.
Why would anyone say that?
Posted on Reply
#6
medi01
R0H1T
AMD haven't specified which version of 7nm they'll use or if they'll even use 7nm EUV at all, btw TSMC 7nm has 3 variants.
7N and 7NP are compatible.
7N+, on the other hand, looks like a waste, if what TSMC is promisnig about 5nm is true.
Assimilator
When NVIDIA did it, the cry from the red fanboys was "ngreedia is ripping you off!!!!!!111one". I very much look forward to seeing the mental gymnastics they'll put themselves through to justify "their" team doing the same.
I thought AMD having enough money to have separate line of compute oriented products was good news for gamers.
Posted on Reply
#7
FordGT90Concept
"I go fast!1!11!1!"
I wonder if CDNA is a rebrand of GCN with render hardware chopped off and some features (like Infinity Fabric between GPUs) added.
Posted on Reply
#8
r.h.p
Isnt it good for AMD to win a contract like this ??? Arnt they a US company ….WhO gives A damn about fanbois .
Posted on Reply
#9
john_
Assimilator
When NVIDIA did it, the cry from the red fanboys was "ngreedia is ripping you off!!!!!!111one". I very much look forward to seeing the mental gymnastics they'll put themselves through to justify "their" team doing the same.
It must be a great feeling when there is ONCE in a lifetime the chance to imagine, just imagine, another company coming close to Nvidia's greediness(well, close as looking from a telescope).
Posted on Reply
#10
medi01
john_
coming close to Nvidia's greediness
Well, 43-45% margins are to stay in GPU area, short of 60%+.
Posted on Reply
#11
Vya Domus
Assimilator
When NVIDIA did it
Genuinely have no clue what you are talking about. This a first as far as I know and it's product that will never reach the hands of the average consumer.
FordGT90Concept
I wonder if CDNA is a rebrand of GCN
Not a rebrand but probably an evolution of GCN, I doubt they can add in those tensor units without revamping the architecture in some way. That being said cutting all raster hardware is going to save a considerable amount of space.
Posted on Reply
#12
mtcn77
FordGT90Concept
I wonder if CDNA is a rebrand of GCN with render hardware chopped off and some features (like Infinity Fabric between GPUs) added.
The addition is tensors, so AMD is making rapid packed math enter launch status, imo.
Posted on Reply
#13
theoneandonlymrk
Assimilator
When NVIDIA did it, the cry from the red fanboys was "ngreedia is ripping you off!!!!!!111one". I very much look forward to seeing the mental gymnastics they'll put themselves through to justify "their" team doing the same.
Wondering what your on about?.


Did what?
Posted on Reply
#14
mtcn77
theoneandonlymrk
Wondering what your on about?.


Did what?
He is one of the derail squad who sent ocn into the abyss. Exhibits like these normally frame you into a troll stereotype and try to maintain the upperhand in playing tag.
Posted on Reply
#15
theoneandonlymrk
mtcn77
He is one of the derail squad who sent ocn into the abyss. Exhibits like these normally frame you into a troll stereotype and try to maintain the upperhand in playing tag.
So random though.


Looking forward though consider, Any benchmark or rumour on a video output enabled big Navi is not CDNA.


Spec sheet rumours could be either too.
Posted on Reply
#16
mtcn77
theoneandonlymrk
Looking forward though consider, Any benchmark or rumour on a video output enabled big Navi is not CDNA.
Correct. Display versions are rapid packed math enabled all the while compute versions are tensor enabled. I wonder how good they work in exercise. They have Timothy Lottes as a superpower at every turn. Navi had compiler optimisations to improve opcode traffic. I wonder how far these can do the same. After all, aren't tensors about bigger vector flows to reduce opcode traffic? All to the extent of scalarization imo.
Posted on Reply
#17
gamefoo21
Assimilator
When NVIDIA did it, the cry from the red fanboys was "ngreedia is ripping you off!!!!!!111one". I very much look forward to seeing the mental gymnastics they'll put themselves through to justify "their" team doing the same.
I got in trouble for making a similar post hammering NV fanboys.

Key differences...

NV locks you into an eco system. AMD hasn't made a CUDA or done everything they can to force you to only use Radeons for things like 'Physx' and threatened to sue people who dare to undo their locks.

AMD is actually trying to make this easy to use and support open standards while trying to ease the pain of moving from the green tax team.

I also very muchly doubt we'll see the end of products like the Vega 2s, because there's a purpose for render/compute beast cards.

Though who knows, Quadros are nothing but really expensive GeForce cards with 'pro' drivers in most cases.

AMD on the other hand lets you use their Pro drivers on their normal Radeons. The difference is the real pro cards tend to have better FP64 dividers.

Sooooo...

How's AMD being greedy again?
Posted on Reply
#18
Cheeseball
Not a Potato
Guys... :shadedshu:
Oh the software side of things, AMD's latest ROCm open-source software infrastructure will bring CDNA and CPUs together, by providing a unified programming model rivaling Intel's OneAPI and NVIDIA CUDA. A platform-agnostic API compatible with any GPU will be combined with a CUDA to HIP translation layer.
CUDA is technically an open-source framework. It is basically C++ code and can run on any GPGPU, however there are extensions that are optimized for NVIDIA hardware to use them. There are also compilers (cuDNN and NVCC) which are optimized for NVIDIA hardware. This is where the advantage of CUDA lies and why its one of the superior solutions at the moment.

ROCm is also an open-source framework. It is also C++ code that can run on any hardware too. There are some AMD-only extensions that are specific to GCN5 (and RDNA as of 3.0 now) but they are mostly raw OpenCL, which can be run on NVIDIA GPUs, Intel IGPs and even x86/ARM CPUs using standard LLVM compilers. They are also Metal (Apple) compatible, considering that Macs are using AMD GPUs for the Pro products.

Whats the problem? There isn't any! What it is is that it's more of a limitation because coding pure (without extensions and optimizations) OpenCL is not as robust as CUDA on NVIDIA GPGPUs. It's great for initial learning and early development, but eventually once you get to optimization, you'd want a framework that can handle complex loads and support for optimizing further.

HIP makes it easy to use CUDA, HC, OpenCL, etc. code as it translates quite cleanly. So any code compiled with HIP enabled (using HCC on AMD, NVCC on NVIDIA) will work on any GPGPU.

NVIDIA has not made CUDA proprietary. It is only a "walled garden" because CUDA-optimized code runs better on NVIDIA hardware, and this is obviously sensible. If you translate CUDA code using HIP, you can run it on AMD GPUGPUs, but don't expect it to be optimized since the underlying architecture is different. OpenCL runs fine on any hardware, hence being open, only being limited by the hardware.
Posted on Reply
#19
gamefoo21
Cheeseball
Guys... :shadedshu:



CUDA is technically an open-source framework. It is basically C++ code and can run on any GPGPU, however there are extensions that are optimized for NVIDIA hardware to use them. There are also compilers (cuDNN and NVCC) which are optimized for NVIDIA hardware. This is where the advantage of CUDA lies and why its one of the superior solutions at the moment.

ROCm is also an open-source framework. It is also C++ code that can run on any hardware too. There are some AMD-only extensions that are specific to GCN5 (and RDNA as of 3.0 now) but they are mostly raw OpenCL, which can be run on NVIDIA GPUs, Intel IGPs and even x86/ARM CPUs using standard LLVM compilers. They are also Metal (Apple) compatible, considering that Macs are using AMD GPUs for the Pro products.

Whats the problem? There isn't any! What it is is that it's more of a limitation because coding pure (without extensions and optimizations) OpenCL is not as robust as CUDA on NVIDIA GPGPUs. It's great for initial learning and early development, but eventually once you get to optimization, you'd want a framework that can handle complex loads and support for optimizing further.

HIP makes it easy to use CUDA, HC, OpenCL, etc. code as it translates quite cleanly. So any code compiled with HIP enabled (using HCC on AMD, NVCC on NVIDIA) will work on any GPGPU.

NVIDIA has not made CUDA proprietary. It is only a "walled garden" because CUDA-optimized code runs better on NVIDIA hardware, and this is obviously sensible. If you translate CUDA code using HIP, you can run it on AMD GPUGPUs, but don't expect it to be optimized since the underlying architecture is different. OpenCL runs fine on any hardware, hence being open, only being limited by the hardware.
We gets it Cheeseball, you will defend NV to your dying breath.

I actually went digging. AMD can only partially emulate some CUDA code. They can only do it on Linux. They are also versions behind.

NV did offer an emulator for a bit, but then killed it and locked the CUDA dev tools to only run on certified hardware.

If AMD ever did try to actually license CUDA, NV would have to change the license. You require Nvidia hardware, you require Nvidia drivers, and God help you if you try to modify their software.

So basically AMD can't even look at CUDA while trying to port it.

Open and free as long as you only use our hardware. Oh you could use OpenCL but it's badly supported and very limited, but here use our 'Free' and superior 'open' alternative.

Saying it's not a walled garden is like saying OSX isn't because it's based on FreeBSD. Apple keeps making it harder and harder to run on non-Apple hardware.

NV has a stack of clauses forbidding people from reverse engineering anything they provide in terms of CUDA or it's required software it seems.

Just because people have managed to hack support for some CUDA calls to work in OpenCL or One API, doesn't mean it's open. Oh and you are completely screwed on Windows.

This is what I gathered in a few minutes of Google searches.

Nvidia won't even let you decompile the CUDA stuff on Linux. The license actually says you are only allowed to decompress the downloaded file, and distribute the unzipped contents. Any other modification or tampering or unpacking will be viewed most dimly.

So it's impressive that people have managed to get any CUDA porting to work. Though I'm sure if NV could prove that they looked at actual CUDA stuff they'd sue their asses into non-existance.

Edit: from what I gathered...

ROCm is an attempt by AMD to emulate CUDA hardware.

HIPM is software that translates CUDA code into OpenCL code.

Neither offers full support for even older versions of CUDA and they don't support the latest versions at all.

Also no CUDA emulators on Windows or NV will sue you into bankruptcy. Guess they really don't want PhysX on anything but NV hardware that is also rendering. No slave NV GPUs with Radeons doing the drawing.

Open like iOS... LoL
Posted on Reply
#20
Psinet
Watching the NVIDIA/AMD fanbois fight it out is hilarious and entertaining.

Hot tip: never listen to fanbois. They have no real information due to their inherent cognitive bias.
Cheeseball
Guys... :shadedshu:



CUDA is technically an open-source framework. It is basically C++ code and can run on any GPGPU, however there are extensions that are optimized for NVIDIA hardware to use them. There are also compilers (cuDNN and NVCC) which are optimized for NVIDIA hardware. This is where the advantage of CUDA lies and why its one of the superior solutions at the moment.

ROCm is also an open-source framework. It is also C++ code that can run on any hardware too. There are some AMD-only extensions that are specific to GCN5 (and RDNA as of 3.0 now) but they are mostly raw OpenCL, which can be run on NVIDIA GPUs, Intel IGPs and even x86/ARM CPUs using standard LLVM compilers. They are also Metal (Apple) compatible, considering that Macs are using AMD GPUs for the Pro products.

Whats the problem? There isn't any! What it is is that it's more of a limitation because coding pure (without extensions and optimizations) OpenCL is not as robust as CUDA on NVIDIA GPGPUs. It's great for initial learning and early development, but eventually once you get to optimization, you'd want a framework that can handle complex loads and support for optimizing further.

HIP makes it easy to use CUDA, HC, OpenCL, etc. code as it translates quite cleanly. So any code compiled with HIP enabled (using HCC on AMD, NVCC on NVIDIA) will work on any GPGPU.

NVIDIA has not made CUDA proprietary. It is only a "walled garden" because CUDA-optimized code runs better on NVIDIA hardware, and this is obviously sensible. If you translate CUDA code using HIP, you can run it on AMD GPUGPUs, but don't expect it to be optimized since the underlying architecture is different. OpenCL runs fine on any hardware, hence being open, only being limited by the hardware.
Wow that is plain uninformed, if not disingenuous.
Posted on Reply
#21
Cheeseball
Not a Potato
Psinet
Watching the NVIDIA/AMD fanbois fight it out is hilarious and entertaining.

Hot tip: never listen to fanbois. They have no real information due to their inherent cognitive bias.



Wow that is plain uninformed, if not disingenuous.
Uninformed? What part of what I said is wrong? :laugh:
gamefoo21
We gets it Cheeseball, you will defend NV to your dying breath.

I actually went digging. AMD can only partially emulate some CUDA code. They can only do it on Linux. They are also versions behind.

NV did offer an emulator for a bit, but then killed it and locked the CUDA dev tools to only run on certified hardware.

If AMD ever did try to actually license CUDA, NV would have to change the license. You require Nvidia hardware, you require Nvidia drivers, and God help you if you try to modify their software.

So basically AMD can't even look at CUDA while trying to port it.

Open and free as long as you only use our hardware. Oh you could use OpenCL but it's badly supported and very limited, but here use our 'Free' and superior 'open' alternative.

Saying it's not a walled garden is like saying OSX isn't because it's based on FreeBSD. Apple keeps making it harder and harder to run on non-Apple hardware.

NV has a stack of clauses forbidding people from reverse engineering anything they provide in terms of CUDA or it's required software it seems.

Just because people have managed to hack support for some CUDA calls to work in OpenCL or One API, doesn't mean it's open. Oh and you are completely screwed on Windows.

This is what I gathered in a few minutes of Google searches.

Nvidia won't even let you decompile the CUDA stuff on Linux. The license actually says you are only allowed to decompress the downloaded file, and distribute the unzipped contents. Any other modification or tampering or unpacking will be viewed most dimly.

So it's impressive that people have managed to get any CUDA porting to work. Though I'm sure if NV could prove that they looked at actual CUDA stuff they'd sue their asses into non-existance.

Edit: from what I gathered...

ROCm is an attempt by AMD to emulate CUDA hardware.

HIPM is software that translates CUDA code into OpenCL code.

Neither offers full support for even older versions of CUDA and they don't support the latest versions at all.

Also no CUDA emulators on Windows or NV will sue you into bankruptcy. Guess they really don't want PhysX on anything but NV hardware that is also rendering. No slave NV GPUs with Radeons doing the drawing.

Open like iOS... LoL
You technically agreed with me with everything you wrote here. The majority of projects using CUDA today are not on 7.5 and under (which is when it was still mostly proprietary), as that would be inefficient.

CUDA was locked down prior to 2012 and could only run on NVIDIA GPGPUs as there was practically no competition. OpenCL at the time (1.2) was not as useful for compute until 2.0 (due to C11 and piping support). This is why CUDA has a lead in deep learning implementation today.

OpenCL is definitely not badly supported by NVIDIA. In fact most implementations of it run fine on both NVIDIA and AMD GPGPUs. It's just that implementations that use CUDA code have a specific use case and have proven to be more efficient than trying to implement it in vanilla OpenCL.

Are you arguing about open-source solutions or the superiority of one API over another? Because despite CUDA being proprietary (in terms of hardware efficiency), NVIDIA hasn't done anything wrong since it is their product.

ROCm is a very new (as in less than 2 years old) framework that I very much want to succeed, but direct support (from AMD) is lacking. This is expected as it is an open-source solution and AMD is a smaller company that most likely doesn't have enough resources to send help out. This is where NVIDIA (and Intel apparently) shines. Hopefully the funding from the US DOE will accelerate its development as a viable framework.
Posted on Reply
#22
eidairaman1
The Exiled Airman
gamefoo21
I got in trouble for making a similar post hammering NV fanboys.

Key differences...

NV locks you into an eco system. AMD hasn't made a CUDA or done everything they can to force you to only use Radeons for things like 'Physx' and threatened to sue people who dare to undo their locks.

AMD is actually trying to make this easy to use and support open standards while trying to ease the pain of moving from the green tax team.

I also very muchly doubt we'll see the end of products like the Vega 2s, because there's a purpose for render/compute beast cards.

Though who knows, Quadros are nothing but really expensive GeForce cards with 'pro' drivers in most cases.

AMD on the other hand lets you use their Pro drivers on their normal Radeons. The difference is the real pro cards tend to have better FP64 dividers.

Sooooo...

How's AMD being greedy again?
Pro drivers can be used on HD 7000 series

Dedicated hardware vs a jack all trades and a master of none. Makes more sense.
Posted on Reply
#23
gamefoo21
eidairaman1
Pro drivers can be used on HD 7000 series

Dedicated hardware vs a jack all trades and a master of none. Makes more sense.
I installed the Pro drivers on a RX 560.

Seems they are available for all GCN cards. Which is really kind of cool. Those certified drivers aren't cheap to produce and have certified.
Posted on Reply
#24
DeathtoGnomes
Splitting the architecture and removing useless hardware, who could have guessed that would be an improvement...
Posted on Reply
#25
r.h.p
gamefoo21
I installed the Pro drivers on a RX 560.

Seems they are available for all GCN cards. Which is really kind of cool. Those certified drivers aren't cheap to produce and have certified.
whats the difference btween PRO DRIVERS and ADRENALLIN , for a 5700xt ?? :confused:
Posted on Reply
Add your own comment