# AMD Advancing AI 2026: Talking CDNA5 with AMD’s Alan Smith > Source: > Published: 2026-07-27 19:43:53+00:00 # AMD Advancing AI 2026: Talking CDNA5 with AMD’s Alan Smith Hello you fine Internet folks, Today we are over AMD's Advancing AI 2026 event to chit chat on their newly revealed CDNA5 architecture with Alan Smith! AMD's Corporate Fellow and Chief Architect for Datacenter GPUs. Hope y'all enjoy! The transcript below has been edited for conciseness, readability, and clarifications. **George:** So, what do you do here at AMD? **Alan:** Yeah. So, I’m a Corporate Fellow of Graphics Architecture at AMD and responsible for Instinct GPU architecture, which we launched today in MI455 and Helios. **George:** Starting off, all the way down into the grunt of the engine of MI455. Prior CDNA architectures were based on the GCN architecture, which dates all the way back to Tahiti from I believe 2012, if memory serves, but with CDNA 5, you have now rebased to RDNA. What were some of the considerations for that rebasing of the architecture? **Alan:** Yeah, that's a great question. I think there were many, many considerations for making that transition, right? First of all, you know, we wanted to move onto a modern architecture. There were some of the things that we were carrying from the previous GCN architecture, as you mentioned, that we wanted to enhance, including the cache system and also just the execution engine itself, right? So in terms of work scheduling, sequencing of the waves, and even instruction issue and things like this. So there were many things that we wanted to improve. And so, we knew we wanted to make a big change in the architecture. We wanted to get significant gains in efficiency, and we felt like the opportunity was there for us to bring together what we had done for RDNA, what we wanted to do with CDNA, in order to bring the AMD GPU roadmap more closely together, which gives us then the opportunity for additional optimization in the future that can benefit both. And one of the reasons we think that’s really important is because AI is everywhere, as you saw in the keynote today. And so, even from gaming and neural rendering and upscaling and all of these things that are now leaning into AI for GPU, even for rendering on the RDNA side, and the things that we’re doing with AI for data center, there’s an opportunity to really bring that together and leverage them on both product lines. So that’s why we wanted to do that. **George:** Speaking of two different product lines, I believe last week we published an article on what is effectively MI430. What are the differences in terms of design for HPC versus AI, what design considerations do you have to make at sort of the WGP level for those two different product lines? **Alan:** Yeah, great question. I mean, I think not just the WGP level, but the entire SOC level, how do we think about HPC workloads versus AI workloads? They have a lot of similarities, right? They both thrive on high-bandwidth memory, they both need cluster interconnects, they both really enjoy having a high-performance CPU connected to them with a CPU memory system, cache coherency, and all these things. So all of that is already common, right? And the only thing that's different is the type of numerics that you need for the codes that you're running. And so, the way that we looked at this is we could have included double-precision floating point in the GPU like we've done in the past, or, you know, we could do even better for both if we took advantage of our chiplet architecture and optimized two versions of the compute chiplet: one for traditional simulation with high-precision formats like double-precision floating point, where we really need all of the full IEEE compliance with 64-bit; and then the same thing for the AI workloads, leveraging as highest throughput that we can achieve for both vector operations and the tensor operations for AI. So having said that, even within the workgroup processor, still many things are in common, right? We need similar bandwidth out of the register file, out of the VGPR. So we're able to leverage all of that, and also all the scheduling, etc. So all of the support hardware within the workgroup processor from the LDS, the caching, the front-end sequencers, all those things, and the SIMDs themselves for the vector ALUs are all shared. And all we really need to do is modulate the number of double-precision units that we implement within the SIMD. **George:** Speaking of the SIMDs, previously, a feature or one of the fundamental building blocks of how GCN worked and prior CDNA architectures was that there were four SIMD16 units that were being issued a Wave64 instruction with one instruction per four cycles. With CDNA 5, you have now moved to four SIMD32 units that are being issued one Wave32 per cycle and you have said that you have deprecated Wave64 support. Why did you choose to deprecate Wave64 support considering that RDNA with a similar SIMD setup has Wave64 capabilities? **Alan:** Yeah, great question. I think, you know, the way we were looking at it is there’s some additional overhead that we need to carry for Wave64. There are some opportunities to leverage that in some special cases where you can get a little bit of additional efficiency out of issuing a Wave64 on SIMD32. But we felt like the tradeoffs of branch divergence and register pressure and so forth for continuing to keep that capability in most cases, or the common cases from our traces and workload profiling that we’ve done, we think that running in Wave32 almost all the time is a better solution. And so we were able to, you know, maybe reduce the overhead that you need to carry for Wave64 and deploy that in order to get better common-case performance, and make up for the little bit of optimization that you can get from Wave64 on SIMD32. **George:** Okay. So in RDNA 3 and 4, they have four SIMD32 units, but there’s also an extra bank of ALUs per SIMD. Does CDNA 5 have that extra bank of 32 ALUs basically, or is it just 32 ALUs per SIMD? **Alan:** Yeah, I think in our SIMDs we have, it’s not always exactly 32 units per lane, right, because in some cases we have more throughput than can be achieved. So we have things like VOP2 instructions... **George:** Where you need dual issue? **Alan:** Yeah, where you’re effectively doubling the rate, if you will. So you need effectively multiple units per lane in order to get that higher throughput. **George:** Speaking of higher throughputs and specifically the register file, with CDNA 5, you have massively increased the amount of VGPRs that a single wave can access: from 256 VGPRs to 1024 VGPRs. Why was that change made? **Alan: **The reason we increased the addressing was just to give the waves less register pressure effectively because more of the waves are better able to share more VGPRs. **George: **And in terms of the capacity of the register file, it is also 1024 VGPRs in terms of the physical number of registers, which is less than RDNA has. Why fewer in this bigger compute architecture? **Alan: **I'll need to go check that. *In a follow-up email, Alan clarified that the VGPR register file size on CDNA5 is sized for the programs that CDNA5 will be used for which has different register file behaviors to what RDNA3/4 will usually run into.* **George:** On the diagrams it shows a WGP cache of 384 kilobytes and it splits it as 320 and 64 for the LDS and data cache/vector cache whereas some of your LLVM commits show that that number is fungible. So can you change the capacities of the LDS and the vector on the fly, or is that set? **Alan:** Yeah. So the architecture was designed to support it to be programmable, but on MI455, we're going to have it as a fixed ratio. We find that for the MI455 deployments, having the larger LDS is almost always the balance that you need for the high tensor throughputs. And so we'll have it always fixed at 320 kilobytes and 64 kilobytes, as you mentioned, for the vector data cache. **George:** So then, would MI430 potentially have a different split, or would it be, again, that sort of being able to change on the fly for different workloads? **Alan:** It may have a different split. **George:** Speaking of caches, that’s a big change specifically at the XCD level. Whereas for CDNA 3 and 4, we had sort of the L1 that was private per CU, then you had the L2 that was per XCD, and then you had the MALL AKA Infinity Cache that acted as sort of the glue to everything, that has changed. Why was that change made? **Alan:** Yeah. So there were a couple of reasons that we were addressing with these changes. One of the things that we really wanted to do for MI450 series beyond what we had in 300 and 350 series was die-scope atomics or global atomics. So we wanted to move that back into the L2 cache, where we could get a higher throughput implementation, so that was one of our design goals. We also wanted to eliminate the kernel boundary flush that we had on the L2 cache that was implemented in the XCD for global visibility on MI350 series. And then we also just wanted to increase the bandwidth for global L2 beyond what would be capable to go across the chip boundaries between the two cache fabric dies. And so, the way that we did that is we effectively implemented a client-side cache instead of a memory-side cache. So we have these two client-side caches. We used the area that would have been implemented, or would have implemented an Infinity Cache on MI355 on the base die, built a large global L2 cache on each of them, and now all of the shader engines that are in the accelerator complex dies situated on one of those base dies, they all share that L2 cache. So the last thing that you get the benefit of is from L2 cache data reuse: we get more sharing across more shader engines. So we have eight shader engines now that share a common L2 cache versus what we had on MI300 and 350 series. And then what we do with those two caches: now each one of them is able to cache all of the memory. So all of the global addresses within the whole GPU, each of them can cache locally. And so those cache accesses don’t have to traverse across the chiplet boundary on the base die, versus on MI300 and 350, where in order to access the capacity of the MALL, the transactions would have to go across longer latency and higher power to go across all of the base die chiplets on the I/O dies. **George:** So then, can a WGP on FCD0 access the cache in FCD1? **Alan:** They do not. **George:** Okay. So what is the bandwidth between the two FCDs? **Alan: **We sized the interface between the two FCDs so that we can achieve full memory bandwidth in what we call NPS1. So if you look at the bisectional bandwidth of the two dies, it’s effectively sized relative to the total HBM bandwidth of the device, such that 50% of the bandwidth when you’re sharing from one side to the other... each side needs to access 50% of their accesses on their side and 50% on the other side. And so that interface is sized so that both sides can do that simultaneously and achieve the full bandwidth of the memory system across the two, plus, as you alluded to, we have some coherency traffic because the Infinity Fabric is maintaining cache coherency between those two GL2 caches. So it’s sized appropriately to handle that traffic in addition to the memory traffic, and then also the I/O traffic that we have coming in from the scale-up and scale-out networks. *In a follow-up email, Alan clarified that the die to die bandwidth is 14 TB/s bi-directional.* **George:** A way to think of this is like sort of the way that EPYC does its cache coherency, I guess? **Alan:** It is very similar. From their L3s. So if you think about the L3 cache implementation on EPYC and the way that that’s implemented, it’s very similar here. **George:** Cool. And so we come to the ultimate question. While I usually ask “What is your favorite cheese?”, we already know your favorite cheese! So have you tried any new cheeses as of late? **Alan:** *(Laughs)* Um, yeah, I’m still a fan of cheddar, right? **George:** I believe your favorite’s Cabot? **Alan:** Cabot is, yeah, what we talked about. But you know what? Since I know that you’re a Tillamook fan... I just want to say that I have been eating a lot of Tillamook ice cream lately! **George:** Oh yes! Anyway, thank you so much for sitting down with me. **Alan:** Absolutely, George.