Sony's Mark Cerny Has Worked on "Big Chunks of RDNA 5" with AMD

Here's a summary of the themes from the Hacker News discussion, presented in Markdown format:

AMD GPU Architecture and Sony Collaboration

A significant portion of the discussion revolves around AMD's GPU architecture, specifically the relationship between RDNA and the potential "RDNA 5" which is now referred to as UDNA1. There's also a strong focus on the collaboration between AMD and Sony for PlayStation hardware.

• "It looks like all of your comments are low-effort summaries like this. What’s going on here? Or is this a bot…" commented smcl, highlighting questions about the nature of submissions.
• "They're summarizing the submissions they're making. All of the summary comments are on their own submissions," diggan clarified.
• "If the Playstation contributions are good enough, maybe RDNA4 -> RDNA5 will be just as good as RDNA3 -> RDNA4. As long as they get the pricing right, anyway," stated LorenDB, connecting Sony's input to future RDNA development.
• "There isn't an RDNA5 on the roadmap, though. It's been confirmed 4 is the last (and was really meant to be 3.5, but grew into what is assumed to be the PS5/XSX mid-gen refresh architecture)." DiabloD3 noted the apparent shift in naming and architectural direction.
• "Next is UDNA1, a converged architecture with it's older sibling, CDNA (formerly GCN)," DiabloD3 continued, explaining the new architectural direction.
• "Like, the article actually states this, but runs an RDNA 5 headline anyways," DiabloD3 pointed out a potential misrepresentation in the article's framing.
• "It's just a name. I'm sure this is all pretty iterative work," cubefox offered a more pragmatic view on the naming.
• "UDNA isn't a name but instead a big shift in strategy," dragontamer corrected, emphasizing the strategic implications.
• "CDNA was for HPC / Supercomputers and Data center. GCN always was a better architecture than RDNA for that. RDNA itself was trying to be more NVidia like. Fewer FLOPs but better latency," dragontamer detailed the architectural philosophies.
• "Someone is getting the axe. Only one of these architectures will win out in the long run, and the teams will also converge allowing AMD to consolidate engineers to improving the same architecture. We won't know what the consolidated team will release yet. But it's a big organizational shift that surely will affect AMDs architectural decisions," dragontamer predicted organizational changes and their impact.
• "My understanding was that CDNA and RDNA shared much if not most of their underlying architecture, and that the fundamental differences had more to do with CDNA supporting a greater variety of numeric representations to aid in scientific computing. Whereas RDNA really only needed fp32 for games," timschmidt shared his understanding of the architectural similarities.
• "CDNA is 64 wide per work item. And CDNA1 I believe was even 16 lanes executed over 4 clock ticks repeatedly (ie: minimum latency of all operations, even add or xor, was 4 clock ticks). It looks like CDNA3 might not do that anymore but that's still a lot of differences... RDNA actually executes 32-at-a-time and per clock tick. It's a grossly different architecture," dragontamer countered timschmidt with specific architectural details.
• "That doesn't even get to Infinity Cache, 64-bit support, AI instructions, Raytracing, or any of the other differences...." dragontamer continued to highlight the divergences.
• "CDNA is based on the older gcn arch so they share the same as pre RDNA ones and RDNA ones," sharpneli stated, linking CDNA to GCN.
• "AMD does do semi-custom work. Whats to stop sony being like we dont want UDNA 1, we want a iteration of RDNA 4. For all we know, it IS RDNA 5... it just wont be available to the public," greenknight mused on Sony's potential custom requirements.
• "And their half step/semi-custom work can find their way back to APUs. RDNA 3.5 (the version marketed as such) is in the Zen 5 APUs with Mobile oriented improvements. It wouldn’t surprise me if a future APU gets RDNA 5. GCN had this sort of APU/Console relationship as well," Moto7451 connected semi-custom work to APUs and consoles.
• "Because if they write their own they get to own the political/bureaucratic portion of the problem. For better or worse, they don't have to deal with the Kronos Group. They get to optimize their APIs directly against their research with AMD," departure4885 explained Sony's rationale for using proprietary APIs.
• "That still doesn't make NIH a better approach. NIH is dinosaur idea really when it comes to technology like this," shmerl argued against the "Not Invented Here" approach.
• "Sony's low level APIs for PS4 and PS5 (it doesn't use GNM) is almost a direct mapping to the hardware with very little abstraction compared to Vulkan/DX12. Vulkan is still very high level compared to what's going on inside the driver. There's no point paying the cost of Vulkan's abstractions when half the point of a game console is to have a fixed hardware target, hence GNM," MindSpunk provided insight into Sony's API design philosophy for consoles.

The Stagnation of Gaming Performance and Visuals

A prominent theme is the perceived slowdown in the rate of improvement in gaming performance and graphics compared to earlier console generations. Discussions touch on the reasons behind this, including game engine bloat, the complexity of modern graphics, and the changing priorities in game development.

• "PS5 was almost twice as fast as the PS4 pro, yet we did not see the generational leap we saw with the previous major releases," whatever1 observed a perceived lack of generational leap.
• "It seems that we are the stage where incremental improvements in graphics will require exponentially more computing capability. Or the game engines have become super bloated," whatever1 offered potential explanations.
• "Edit: I stand corrected in previous cycles we had orders of magnitude improvement in FLOPS," whatever1 revised his previous statement.
• "> Or the game engines have become super bloated. 'Bloated' might be the wrong word to describe it, but there's some reason to believe that the dominance of Unreal is holding performance back. I've seen several discussions about Unreal's default rendering pipeline being optimized for dynamic realtime photorealistic-ish lighting with complex moving scenes, since that's much of what Epic needs for Fortnite. But most games are not that and don't make remotely effective use of the compute available to them because Unreal hasn't been designed around those goals. TAA (temporal anti-aliasing) is an example of the kind of postprocessing effect that gamedevs are relying on to recover performance lost in unoptimized rendering pipelines, at the cost of introducing ghosting and loss of visual fidelity," treyd elaborated on the impact of game engines like Unreal and TAA.
• "In principle, Epic's priorities for Unreal should be aligned to a lot of what we've seen in the PS3/4/5 generation as far as over-the-shoulder 3rd person action adventure games," mikepurvis countered, suggesting alignment between Unreal and popular game genres.
• "I've seen a lot of 'tech' YouTubers try to claim TAA is a product of lazy developers, but not one of them has been able to demonstrate a viable alternative antialiasing solution that solves the same problem set with the same or better performance. Meanwhile TAA and its various derivatives like DLAA have only gotten better in the last 5 years, alleviating many of the problems TAA became notorious for in the latter '10s," babypuncher defended TAA as a necessary optimization.
• "> solves the same problem set with the same or better performance. The games industry has spent the last decade adopting techniques that misleadingly inflate the simple, easily-quantified metrics of FPS and resolution, by sacrificing quality in ways that are harder to quantify. Until you have good metrics for quantifying the motion artifacts and blurring introduced by post-processing AA, upscaling, and temporal AA or frame generation, it's dishonest to claim that those techniques solve the same problem with better performance. They're giving you a worse image, and pointing to the FPS numbers as evidence that they're adequate is focusing on entirely the wrong side of the problem. That's not to say those techniques aren't sometimes the best available tradeoff, but it's wrong to straight-up ignore the downsides because they're hard to measure," wtallis critically assessed the trade-offs of modern rendering techniques.
• "Yeah. Only problem is that overly aggressive TAA implementations blur the whole frame during camera rotation. The thing that is even better than standard TAA is a combination of TAA and temporal upscaling, called TSR in Unreal. Still better is the same system but performed by an ML model, e.g. DLSS. Though this requires special inference hardware inside the GPU," cubefox discussed limitations of TAA and advancements like TSR and DLSS.
• "This hits the nail pretty close to the head. I work on an in-house AAA engine used by a number of different games. It's very expensive to produce art assets at the quality expected now. Many AAA engine's number one focus isn't 'performance at all costs', it's 'how do we most efficiently let artists build their vision'. And efficiency isn't runtime performance, efficiency is how much time it takes for an artist to create something. Performance is only a goal insofar as to free artists from being limited by it," MindSpunk explained the focus on artist efficiency in AAA engines.
• "So I wonder if games studios are more just art studios with a bit of programming bolted on. Not quite, but the ratio is very in favor of artists compared to 'the old days'. Programming is still a huge part of what we do. It's still a deeply technical field, but often "programming workflows" are lower priority than "artist workflows" in AAA engines because art time is more expensive than programmer time from the huge number of artists working on any one project compared to programmers. Just go look at the credits for any recent AAA game. Look at how many artists positions there are compared to programmer positions and it becomes pretty clear," MindSpunk elaborated on the shift in studio priorities towards art.
• "It is not just GPU performance, it is that visually things are already very refined. A ten times leap in performance doesn't really show as ten times the visual spectical like it used to," SlowTao observed that visual improvements are becoming less dramatic with performance increases.
• "Like all this path tracing/ray tracing stuff, yes it is very cool and can add to a scene but most people can barely tell it is there unless you show it side by side. And that takes a lot of compute to do. We are polishing an already very polished rock," SlowTao felt that advanced rendering techniques offer diminishing returns for the average player.
• "Yes but in the PS1 days we were doing a 1000x compute performance a decade. I agree that 10x doesn't move much, but that's sort of my point - what could be done with 1000x?" martinald highlighted the historical rate of compute improvement.
• "Consoles/games got hit hard by first crypto and now AI needing GPUs. I "(I) suspect if it wasn't for that we'd have vastly cheaper and vastly faster gaming GPUs, but when you were making boatloads of cash off crypto miners and then AI I suspect the rate of progress fell dramatically for gaming at least (most of the the innovation I suspect went more into high VRAM/memory controllers and datacentre scale interconnects)," martinald posited that crypto and AI demand have impacted GPU development for gaming.
• "Because optimized games aren’t completely extinct and there’s titles with similar levels of size, fidelity, and feature utilization with dramatically differing performance profiles," cosmic_cheese argued that optimization differences still exist and impact performance.
• "That's why the rate of improvement has fallen dramatically. For instance, CPU clock speeds haven't increased substantially for over a decade, though architectures have improved. Similarly, GPU improvements, while still significant, are no longer on the same exponential curve as they were in the early 2000s." martinald provided a historical comparison of performance improvements when the conversation touched on the PS1 vs. PS3 era.
• "There have been a few decent sized games, but nothing at grand scale I can think of, until GTA6 next year," silisili commented on the perceived lack of large-scale games in the current console generation.
• "Less effort going into optimization also plays a factor. On average games are a lot less optimized than they used to be. The expectation seems to be that hardware advances will fix deficiencies in performance. This doesn’t affect me too much since my backlog is long and by the time I play games, they’re old enough that current hardware trivializes them, but it’s disappointing nonetheless. It almost makes me wish for a good decade or so of performance stagnation to curb this behavior. Graphical fidelity is well past the point of diminishing returns at this point anyway," cosmic_cheese criticized the trend of unoptimized games relying on hardware improvements.
• "This is a result of an industry wide problem where technology just is not moving forward as quickly as it used to move. Dennard scaling is dead. Moore’s law is also dead for SRAM and IO logic. It is barely clinging to life for compute logic, but the costs are skyrocketing as each die shrink happens. The result is that we are getting anemic improvements. This issue is visible in Nvidia’s graphics offerings too. They are not improving from generation to generation like they did in the past, despite Nvidia turning as many knobs as they could to higher values to keep the party going (e.g. power, die area, price, etcetera)," vrilian attributed the slowdown to fundamental issues with scaling in semiconductor technology.
• "When given a choice, most users prefer performance over higher fidelity," adamwk stated a common user preference.
• "Yes PS5 can output 120hz on hdmi. A perfect linear output to direct your more compute at," jayd16 pointed out an aspect of console output that could leverage more compute.
• "And loading times. I think people already forgot how long you had to wait on loading screens or how many faked loading (moving through a brush while the next area loads) there was on PS4," adamwk also highlighted the improvements in loading times as a key generational leap.
• The N64 cartridge-based system's near-instantaneous loading times were brought up by ryao contrasting with modern systems.
• "If only we could just ship a 256GB NVMe SSD with every game and memory map the entire drive like you could with cartridges back then. Never have loading times again," MindSpunk envisioned a future with seamless loading.
• "They were certainly hand optimizing models and the 3D pipeline (with some assembler tuning), but C and SDKs were well in use by that point. Even Naughty Dog went with their own LISP engine for optimization versus ASM," deaddodo corrected the notion of widespread hand-optimized assembly in the PSX era.
• "PS4 wasnt too terrible but jumping back to PS3... wow I completely forgot how memory starved that machine was. Working on it, we knew at the time but in retro spect it was just horrible. Small RAM space with the hard CPU/GPU split (so no reallocation) feeding off a slow HDD which is being fed by an even slower Bluray disc, you are sitting around for a while," SlowTao recalled the memory and storage limitations of the PS3.
• "A lot of the difference went into FPS rather than improved graphics," cwbriscoe suggested that performance gains were prioritized over graphical enhancements.
• "This is correct. Also, it speaks to what players actually value," bentt agreed, linking performance to player value.
• "Also FPS just requires throwing more compute at it. Excessively high detail models require extra artist time too," LikesPwsh noted the compute and artist time costs associated with FPS and detail.
• "A child doesn't care if Zelda runs with low FPS. The only thing I value is a consistent stream of frames on a console," ThatMedicIsASpy stated a personal preference for consistent frame rates on consoles.
• "When asked to decide on a mode, players typically choose performance mode about three-quarters of the time," jayd16 cited a statistic supporting the preference for performance modes.

The Role of Game Engines and Art in Development

The discussion delves into the impact of game engines, particularly Unreal Engine, on game development and performance. The increasing cost and complexity of creating art assets for modern games are also highlighted as a major factor influencing development.

• "Or the game engines have become super bloated," whatever1 suggested game engines as a potential cause for performance issues.
• "I've seen several discussions about Unreal's default rendering pipeline being optimized for dynamic realtime photorealistic-ish lighting with complex moving scenes, since that's much of what Epic needs for Fortnite. But most games are _not_ that and don't make remotely effective use of the compute available to them because Unreal hasn't been designed around those goals," treyd argued that Unreal's optimizations are tailored to specific needs, potentially at the expense of general game performance.
• "I've seen several discussions about Unreal's default rendering pipeline being optimized for dynamic realtime photorealistic-ish lighting with complex moving scenes, since that's much of what Epic needs for Fortnite. But most games are _not_ that and don't make remotely effective use of the compute available to them because Unreal hasn't been designed around those goals," treyd pointed out that Unreal's design priorities might not align with all game types.
• "UE3 was made for Gears of War (pretty much) and as a result the components were there to make Mass Effect," kridsdale1 noted the historical development of UE3 with a specific game in mind.
• "Personally I think it’s probably better to avoid art styles that age like milk, though, or to go for a pseudo-realistic direction that is reasonably true to life while mixing in just enough stylization to scale well and not look dated at record speeds. Japanese studios seem pretty good at this," cosmic_cheese advocated for art styles that age well over hyper-realism.
• "It's very expensive to produce art assets at the quality expected now," MindSpunk stated the high cost of creating modern art assets.
• "Many AAA engine's number one focus isn't 'performance at all costs', it's 'how do we most efficiently let artists build their vision'. And efficiency isn't runtime performance, efficiency is how much time it takes for an artist to create something," MindSpunk explained AAA engine design priorities.
• "So I wonder if games studios are more just art studios with a bit of programming bolted on. Not quite, but the ratio is very in favor of artists compared to 'the old days'," MindSpunk confirmed the increased ratio of artists to programmers.
• "The programming is still a huge part of what we do. It's still a deeply technical field, but often "programming workflows" are lower priority than "artist workflows" in AAA engines because art time is more expensive than programmer time from the huge number of artists working on any one project compared to programmers," MindSpunk further detailed the hierarchy of priorities.
• "Because art time is more expensive than programmer time from the huge number of artists working on any one project compared to programmers," MindSpunk elaborated on why artist workflows take precedence.
• "I get the perhaps mistaken impression the biggest problem games developers have is making & managing absolutely enormous amounts of art assets at high resolution (textures, models, etc). Each time you increase resolution from 576p, to 720p to 1080p and now 4k+ you need a huge step up in visual fidelity of all your assets, otherwise it looks poor. And given most of these assets are human made (well, until very recently) this requires more and more artists. So I wonder if games studios are more just art studios with a bit of programming bolted on, vs before with lower res graphics where you maybe had one artist for 10 programmers, now it is more flipped the other way. I feel that at some point over the past ~decade we hit a "organisational" wall with this and very very few studios can successfully manage teams of hundreds (thousands?) of artists effectively?" martinald theorized about the challenges of managing large art teams.

Console API Design and Standardization

The discussion touches upon the use of proprietary graphics APIs on consoles versus adopting industry standards like Vulkan.

• "Why would they? They have their own (two actually) proprietary graphics APIs: GNM and GNMX," departure4885 explained why Sony doesn't use Vulkan.
• "I'd ask why wouldn't they. Not a fan of NIH and wheel reinvention proponents," shmerl advocated for standardization.
• "Because if they write their own they get to own the political/bureaucratic portion of the problem. For better or worse, they don't have to deal with the Kronos Group. They get to optimize their APIs directly against their research with AMD," departure4885 reiterated the benefits of proprietary APIs for Sony.
• "That still doesn't make NIH a better approach. NIH is dinosaur idea really when it comes to technology like this," shmerl strongly criticized the "Not Invented Here" approach.
• "Why would Vulkan, as opposed to a custom solution designed to target that hardware and games specifically, be a better solution? If you’re making a PS game you’re already doing tons of bespoke PS stuff. If you don’t want to deal with it there are plenty of pieces of middleware out there to help. Honestly these “where’s Vulkan” posts on every bit of 3D capable hardware feel like a stupid meme at this point as opposed to a rational question. Maybe they should just ship DX12. That’s multi-platform too," MBCook questioned the practical need for Vulkan on consoles.
• "Because it won't tax developers with the need to learn yet another NIH. Same reason any standard exists and makes things easier for those who use it. Honestly any idea that defends NIH like this belongs with dinosaurs. NIH is a stupid meme, not the opposite of it," shmerl defended the use of standards.
• "And most of the standard we have now starts with something similar to NIH. Vulkan itself is an offshoot of mantel from AMD. There are valid reason to have a custom api. Especially in domain like game console with hardware with long release cycle, tight performance requirement and legacy (ps4) code to support," soulbadguy provided a nuanced view on the origins of standards and the validity of custom APIs.
• "Vulkan is a mess as bad as OpenGL, to the point Khronos has been forced to public admit it didn't went out as planned, is yet again an extension spaghetti, and they are now trying to clean the house with the Vulkan Roadmap introduced at Vulkanised 2025. That is how good Khronos 'design by commitee APIs' end up being," pjmlp expressed strong criticism for Vulkan's development and design.
• "Sony's low level APIs for PS4 and PS5 (it doesn't use GNM) is almost a direct mapping to the hardware with very little abstraction compared to Vulkan/DX12. Vulkan is still very high level compared to what's going on inside the driver. There's no point paying the cost of Vulkan's abstractions when half the point of a game console is to have a fixed hardware target, hence GNM," MindSpunk articulated the argument for low-level, custom APIs on consoles for direct hardware control.
• "What will use it when there are so few games on the platform in the current PS generation?" lofaszvanitt questioned the adoption of new technologies given the limited game releases.