[HN Gopher] Sony's Mark Cerny Has Worked on "Big Chunks of RDNA ...
___________________________________________________________________
Sony's Mark Cerny Has Worked on "Big Chunks of RDNA 5" with AMD
Author : ZenithExtreme
Score : 100 points
Date : 2025-07-02 16:10 UTC (1 days ago)
(HTM) web link (overclock3d.net)
(TXT) w3m dump (overclock3d.net)
| ZenithExtreme wrote:
| AMD's next-gen GPUs may have some PlayStation tech inside.
| stanac wrote:
| I don't think he is employed by Sony, but work as a consultant
| for them. So both Sony PS 4/5 and AMD GPUs have his tech
| inside.
| mikepurvis wrote:
| So you're right, though I would never have guessed-- in the
| PS5 hype cycle he gave that deep dive architecture
| presentation that for all the world looked like he was a Sony
| spokesperson.
| smcl wrote:
| It looks like all of your comments are low-effort summaries
| like this. What's going on here? Or is this a bot...
| diggan wrote:
| They're summarizing the submissions they're making. All of
| the summary comments are on their own submissions.
| LorenDB wrote:
| 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.
| DiabloD3 wrote:
| 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).
|
| Next is UDNA1, a converged architecture with it's older sibling,
| CDNA (formerly GCN).
|
| Like, the article actually states this, but runs an RDNA 5
| headline anyways.
| cubefox wrote:
| It's just a name. I'm sure this is all pretty iterative work.
| dragontamer wrote:
| UDNA isn't a name but instead a big shift in strategy.
|
| 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.
|
| 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.
| timschmidt wrote:
| 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.
| dragontamer wrote:
| Who told ya that??
|
| 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.
|
| That doesn't even get to Infinity Cache, 64-bit support,
| AI instructions, Raytracing, or any of the other
| differences....
| sharpneli wrote:
| CDNA is based on the older gcn arch so they share the
| same as pre RDNA ones and RDNA ones.
| greenknight wrote:
| 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.
| Moto7451 wrote:
| 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.
| cma wrote:
| Also steamdeck before the OLED version and magic leap 2
| shared a custom chip, with some vision processing parts
| fused off for steamdeck.
| blasphemers wrote:
| Maybe read the article before commenting on it, it's not that
| long.
|
| "Big chunks of RDNA 5, or whatever AMD ends up calling it, are
| coming out of engineering I am doing on the project"
| whatever1 wrote:
| 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.
|
| 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.
|
| Edit: I stand corrected in previous cycles we had orders of
| magnitude improvement in FLOPS.
| treyd wrote:
| > 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.
| mikepurvis wrote:
| 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.
|
| I mean, look at Uncharted, Tomb Raider, Spider-Man, God of
| War, TLOU, HZD, Ghost of Tsushima, Control, Assassins Creed,
| Jedi Fallen Order / Survivor. Many of those games were not
| made in Unreal, but they're all stylistically well suited to
| what Unreal is doing.
| kridsdale1 wrote:
| I agree. UE3 was made for Gears of War (pretty much) and as
| a result the components were there to make Mass Effect.
| babypuncher wrote:
| TAA isn't a crutch being used to hold up poor performance,
| it's an optimization to give games anti-aliasing that doesn't
| suck.
|
| Your other options for AA are
|
| * Supersampling. Rendering the game at a higher resolution
| than the display and downscaling it. This is incredibly
| expensive.
|
| * MSAA. This samples ~~vertices~~surfaces more than once per
| pixel, smoothing over jaggies. This worked really well back
| before we started covering every surface with pixel shaders.
| Nowadays it just makes pushing triangles more expensive with
| very little visual benefit, because the pixel shaders are
| still done at 1x scale and thus still aliased.
|
| * Post-process AA (FXAA,SMAA, etc). These are a post-process
| shader applied to the whole screen after the scene has been
| fully rendered. They often just use a cheap edge detection
| algorithm and try to blur them. I've never seen one that was
| actually effective at producing a clean image, as they rarely
| catch all the edges and do almost nothing to alleviate
| shimmering.
|
| 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.
| flohofwoe wrote:
| Erm your description of MSAA isn't quite correct, it has
| nothing to do with vertices and doesn't increase vertex
| processing cost..
|
| It's more similar to supersampling, but without the higher
| pixel shader cost (the pixel shader still only runs once
| per "display pixel", not once per "sample" like in
| supersampling).
|
| A pixel shader's output is written to multiple (typically
| 2, 4 or 8) samples, with a coverage mask deciding which
| samples are written (this coverage mask is all 1s inside a
| triangle and a combo of 1s and 0s along triangle edges).
| After rendering to the MSAA render target is complete, an
| MSAA resolve operation is performed which merges samples
| into pixels (and this gives you the smoothed triangle
| edges).
| wtallis wrote:
| > 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.
| cubefox wrote:
| 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.
|
| In the past, MSAA worked reasonably well, but it was
| relatively expensive, doesn't apply to all forms of high
| frequency aliasing, and it doesn't work anymore with the
| modern rendering paradigm anyway.
| Stevvo wrote:
| ThreatInteractive is an anti-TAA developer/YouTuber. They
| make a compelling argument against TAA and present an
| alternative they are working on for Unreal.
| gmueckl wrote:
| This is a very one-sided perspective on things. Any
| precomputed solution to lighting comes with enormous
| drawbacks across the board. The game needs to ship the
| precomputed data when storage is usually already tight. The
| iteration cycle for artists and level designers suchs when
| lighting is precomputed - they almost never see accurate
| graphics for their work while they are iterating because
| rebaking takes time away from their work. Game design become
| restricted to those limitations, too. Can't even think of
| having the player randomly rearranging big things in a level
| (e.g. building or tearing down a house) because the engine
| can't do it. Who knows what clever game mechanics are never
| thought of because of these types of limitations?
|
| Fully dynamic interactive environments are liberating.
| Pursuing them in is the right thing to do.
| andrekandre wrote:
| > Fully dynamic interactive environments are liberating.
| Pursuing them in is the right thing to do.
|
| great video from digital foundry that goes into that (for
| doom: the dark ages)
|
| https://www.youtube.com/watch?v=Ed4vNNQwCDU
| cwbriscoe wrote:
| A lot of the difference went into FPS rather than improved
| graphics.
| bentt wrote:
| This is correct. Also, it speaks to what players actually
| value.
| LikesPwsh wrote:
| Also FPS just requires throwing more compute at it.
|
| Excessively high detail models require extra artist time
| too.
| ThatMedicIsASpy wrote:
| I have played through CP2077 with 40, 30 and 25 fps. 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.
| adamwk wrote:
| When given a choice, most users prefer performance over
| higher fidelity
| teamonkey wrote:
| I would like to see the stats for that.
| jayd16 wrote:
| > "When asked to decide on a mode, players typically
| choose performance mode about three-quarters of the time,
|
| From PS5 Pro reveal https://youtu.be/X24BzyzQQ-8?t=172
| bzzzt wrote:
| Seems like an overgeneralization. I get it when FPS
| players want the best performance: players have FOMO of
| the best reaction time and the games are more built for
| fast action than contemplative scenery watching.
|
| I wonder if players of single player action/adventure
| games make the same choice. Those games are played less
| (can be finished in 10-30 hours instead of endlessly) so
| the statistics might be skewed to favor performance mode.
| jayd16 wrote:
| Children eat dirt. I'm not sure "children don't care" is
| a good benchmark.
| cubefox wrote:
| Yeah. Case in point: "Zelda: Ocarina of Time" was at the
| time and several years afterward often labeled as one of
| the best games ever made, despite the fact that it ran
| with 20 FPS on NTSC consoles and with 16.67 FPS on PAL
| machines.
|
| I'm sure it would have been even more successful with
| modern 60 FPS, but that difference couldn't have been
| very large, because other 60 FPS games did exist back
| then as well, mostly without being nearly as popular.
| kridsdale1 wrote:
| Yes PS5 can output 120hz on hdmi. A perfect linear output to
| direct your more compute at.
| adamwk wrote:
| 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
| ryao wrote:
| Did you forget that on the N64, load times were near
| instantaneous?
| derrasterpunkt wrote:
| The N64 was cartridge based.
| MindSpunk wrote:
| 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.
| cubefox wrote:
| Also: I think it got less common on the N64, but games on
| SNES and NES and other old home consoles routinely
| accessed static game data, like graphic tiles, directly
| from the cartridge ROM. Without loading it into system
| RAM at all.
|
| So there literally were no "loading" times for these
| assets. This might not even be realistically possible
| with NAND flash based SSDs, e.g. because of
| considerations like latency.
|
| Though directly accessing ROM memory would also prevent
| things like texture block compression I believe.
| SlowTao wrote:
| 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.
| Izikiel43 wrote:
| Bloodborne when it came out was around 1 minute between
| deaths.
| silisili wrote:
| AFAIK, this generation has been widely slammed as a failure due
| to lack of new blockbuster games. Most things that came out
| were either for PS4, or remasters of said games.
|
| There have been a few decent sized games, but nothing at grand
| scale I can think of, until GTA6 next year.
| jayd16 wrote:
| There were the little details of a global pandemic and
| interest rates tearing through timelines and budgets.
| pjmlp wrote:
| A reason was backwards compatibility, studios were already
| putting lots of money into PS4 and XBox One, thus PS5 and XBox
| X|S (two additional SKUs), were already too much.
|
| Don't forget one reason that studios tend to favour consoles
| has been regular hardware, and that is no longer the case.
|
| When middleware starts to be the option, it is relatively hard
| to have game features that are hardware specific.
| vrighter wrote:
| twice as fast, but asked to render 4x the pixels. Do the math
| SlowTao wrote:
| Well you see... I got nothing.
|
| The path nowadays is to use all kinds of upscaling and
| temporal detail junk that is actively recreating late 90s LCD
| blur. Cool. :(
| cosmic_cheese wrote:
| 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.
| martinald wrote:
| We have had a decade of performance stagnation.
|
| Compare PS1 with PS3 (just over 10 years apart).
|
| PS1: 0.03 GFLOPS (approx given it didn't really do FLOPS per
| se) PS3: 230 GFLOPS
|
| Nearly 1000x faster.
|
| Now compare PS4 with PS5 pro (also just over 10 years apart):
|
| PS4: ~2TFLOPS PS5 Pro: ~33.5TFLOPS
|
| Bit over 10x faster. So the speed of improvement has fallen
| dramatically.
|
| Arguably you could say the real drop in optimization happened
| in that PS1 -> PS3 era - everything went from hand optimized
| assembly code to running (generally) higher level languages
| and using abstrated graphics frameworks like DirectX and
| OpenGL. Just noone noticed because we had 1000x the compute
| to make up for it :)
|
| Consoles/games got hit hard by first crypto and now AI
| needing GPUs. 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).
| cosmic_cheese wrote:
| Yeah there's been a drop off for sure. Clearly it hasn't
| been steep enough for game studios to not lean on anyway,
| though.
|
| One potential forcing factor may be the rise of iGPUs,
| which have become powerful enough to play many titles well
| while remaining dramatically more affordable than their
| discrete counterparts (and sometimes not carrying crippling
| VRAM limits to boot), as well as the growing sector of PC
| handhelds like the Steam Deck. It's not difficult to
| imagine that iGPUs will come to dominate the PC gaming
| sphere, and if that happens it'll be financial suicide to
| not make sure your game plays reasonably well on such
| hardware.
| martinald wrote:
| 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?
| cosmic_cheese wrote:
| That depends a lot on art direction and stylization.
| Highly stylized games scale up to high resolutions
| shockingly well even with less detailed, lower resolution
| models and textures. Breath of the Wild is one good
| example that looks great by modern standards at high
| resolutions, and there's many others that manage to look
| a lot less dated than they are with similarly cartoony
| styles.
|
| If "realistic" graphics are the objective though, then
| yes, better displays pose serious problems. 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.
| spookie wrote:
| Yeah, its flipped. Overall, it has meant studios are more
| and more dependent on third party software (and thus
| license fees), it led to game engine consolidation, and
| serious attrition when attempting to make something those
| game engines werent built for (non-pbr pipelines come to
| mind).
|
| It's no wonder nothing comes out in a playable state.
| MindSpunk wrote:
| 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.
|
| > 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.
| kasool wrote:
| Just to add to this, from a former colleague of mine who
| currently works as a graphics programmer at a UE5 studio:
| most graphics programmers are essentially tech support
| for artists nowadays. In an age where much of AAA is
| about making the biggest, most cinematic, most beautiful
| game, your artists and game content designers are the
| center of your production pipeline.
|
| It used to be that the technology tended to drive the
| art. Nowadays the art drives the tech. We only need to
| look at all the advertised features of UE5 to see that.
| Nanite allows artists to spend less time tweaking LODs
| and optimizing meshes as well as flattening the cost of
| small triangle rendering. Lumen gives us realtime global
| illumination everywhere so artists don't have to spend a
| million hours baking multiple light maps. Megalights
| lifts restrictions on the number of dynamic lights and
| shadows a lighting artist can place in the scene. The new
| Nanite foliage shown off in the Witcher 4 allows foliage
| artists to go ham with modeling their trees
| SlowTao wrote:
| 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.
|
| 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.
| martinald wrote:
| 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?
| Dylan16807 wrote:
| You divided 230 by .03 wrong, which would be 10000-ish, but
| you underestimated the PS1 by a lot anyway. The CPU does 30
| MIPS, but also the geometry engine does another 60 MIPS and
| the GPU fills 30 or 60 million pixels per second with
| multiple calculations each.
| deaddodo wrote:
| Not to mention that few developers were doing hand
| optimized assembly by the time of PSX. 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.
| p_l wrote:
| Naughty Dog's GOAL was PS2 specific and essentially chock
| full of what would be called intrinsics these days that
| let you interleave individual assembly instructions
| particularly for the crazy coprocessor setup of Emotion
| Engine.
|
| My understanding is that the mental model of programming
| in PS2 era was originally still very assembly like
| outside of few places (like Naughty Dog) and that GTA3 on
| PS2 made possibly its biggest impact by showing it's not
| necessary.
| deaddodo wrote:
| If by "mental model" you mean "low-level" programming,
| sure. But you might as well conflate "religion" with
| "Southern Baptist protestantism" then. You're working
| with the same building blocks, but the programming style
| is drastically different.
|
| The vast majority of PSX games were done completely in C,
| period. Some had small bits of asm here and there, but so
| do the occasional modern C/C++ apps.
|
| To your last point, before there was GOAL there was GOOL
| (from the horse's mouth itself):
|
| https://all-things-andy-gavin.com/tag/lisp-programming/
|
| And it was used in all of Naughty Dog's PSX library.
| p_l wrote:
| The quote I recall reading about long ago summarized the
| semi-official guidance as "write C like you write ASM".
|
| Because outside of ports from PC, large amount of console
| game developers at the time were experienced a lot with
| with programming earlier consoles which had a lot more
| assembly level coding involved. GTA3 proved that "PC
| style" engine was good enough despite Emotion Engine
| design.
|
| Didn't help that PS2 was very much oriented towards
| assembly coding at pretty low level, because getting the
| most of the hardware involved writing code for the
| multiple coprocessors to work somewhat in-sync - which at
| least for GOAL was done by implementing special support
| for writing the assembly code in line with rest of the
| code (because IIRC not all assembly involved was executed
| from the same instruction stream)
|
| As for GOOL, it was the way more classic approach (used
| by ND on PS3 and newer consoles too) of core engine in C
| and "scripting" language on top to drive gameplay.
| deaddodo wrote:
| > The quote I recall reading about long ago summarized
| the semi-official guidance as "write C like you write
| ASM".
|
| You could read that in pretty much any book about C,
| until the mid-00s. C was called "portable assembler" for
| the longest time because it went against the grain of
| ALGOL, Fortran, Pascal, etc by encouraging use of
| pointers and being direct to the machine. Thus why it
| only holds a viability in embedded development these
| days.
|
| I've written C on the PSX, using contemporaneous SDKs and
| tooling, and I've reviewed source code from games at the
| time. There's nothing assembler about it, at least not
| more so than any systems development done then or today.
| If you don't believe me, there are plenty of retail PSX
| games that accidentally released their own source code
| that you can review yourself:
|
| https://www.retroreversing.com/source-code/retail-
| console-so...
|
| You're just arguing for the sake of arguing at this point
| and, I feel, being intellectually dishonest. Believe what
| you'd like to believe, or massage the facts how you like;
| I'm not interested in chasing goal (heh) posts.
| imtringued wrote:
| >I suspect if it wasn't for that we'd have vastly cheaper
| and vastly faster gaming GPUs
|
| This feels very out of touch since AMD's latest GPU series
| is specialized in gaming only, to the point where they sell
| variants with 8GB, which is becoming a bit tight if you
| want to play modern games.
| martinald wrote:
| Yes but AMD also has an enterprise line of AI cards to
| protect. And regardless, if NVidia wasn't also making
| bank selling AI GPUs then we'd have seen them add more
| performance on gaming, which would have forced AMD to,
| etc.
| jayd16 wrote:
| By what metric can you say this with any confidence when game
| scope and fidelity has ballooned?
| cosmic_cheese wrote:
| 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.
| rtpg wrote:
| Given the N64-PS1 era is filled with first party games
| that run at like 20 fps, I'm having a hard time saying
| things are worse now.
|
| I am a bit uncomfortable with the performance/quality
| stuff that people have set up but I personally feel that
| the quality floor for perf is way higher than it used to
| be. Though there seem to be less people parking
| themselves at "60fps locked", which felt like a thing for
| a while
| ErneX wrote:
| GTA VI is going to be a showcase on these consoles.
| teamonkey wrote:
| This article shows how great a leap there was between previous
| console generations.
|
| https://www.gamespot.com/gallery/console-gpu-power-compared-...
| CoolGuySteve wrote:
| The current generation has a massive leap in storage speed but
| games need to be architected to stream that much data into RAM.
|
| Cyberpunk is a good example of a game that straddled the in
| between, many of it's performance problems on the PS4 were due
| to constrained serialization speed.
|
| Nanite and games like FF16 and Death Stranding 2 do a good job
| of drawing complex geometry and textures that wouldn't be
| possible on the previous generation
| Vilian wrote:
| Nanite is actively hurting performance
| teamonkey wrote:
| Nanite has a performance overhead for simple scenes but
| will render large, complex scenes with high-quality models
| much more efficiently, providing a faster and more stable
| framerate.
|
| It's also completely optional in Unreal 5. You use it if
| it's better. Many published UE5 games don't use it.
| CoolGuySteve wrote:
| Well yeah, features that push the graphics card typically
| incur performance hits.
| ryao wrote:
| This is the 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).
| timschmidt wrote:
| Jim Keller disagrees:
| https://www.youtube.com/watch?v=oIG9ztQw2Gc
| pjmlp wrote:
| Hardware improvements only matter to the extent software is
| actually able to make use of them.
| timschmidt wrote:
| And? Software is getting more sophisticated and capable
| too. First time I switched an iter to a par_iter in Rust
| and saw the loop spawn as many threads as I have logical
| cores felt like magic. Writing multi-threaded code used
| to be challenging.
| pjmlp wrote:
| Now make that multi-threaded code exhaust a 32 core
| desktop system, all the time, not only at peak execution.
|
| As brownie points, keep the GPU busy as well, beyond
| twirling its fingers while keeping the GUI desktop going.
|
| Even more points if the CPU happens to have a NPU or
| integrated FPGA, and you manage to also keep them going
| alongside those 32 cores, and GPU.
| timschmidt wrote:
| > Now make that multi-threaded code exhaust a 32 core
| desktop system
|
| Switching an iter to par_iter does this. So long as there
| are enough iterations to work through, it'll exhaust 1024
| cores or more.
|
| > all the time, not only at peak execution.
|
| What are you doing that keeps a desktop or phone at 100%
| utilization? That kind of workload exists in datacenters,
| but end user devices are inherently bursty. Idle when not
| in use, race to idle while in use.
|
| > As brownie points, keep the GPU busy as well... Even
| more points if the CPU happens to have a NPU or
| integrated FPGA
|
| In a recent project I serve a WASM binary from an ESP32
| via Wifi / HTTP, which makes use of the GPU via WebGL to
| draw the GUI, perform CSG, calculate toolpaths, and drip
| feed motion control commands back to the ESP. This took
| about 12k lines of Rust including the multithreaded CAD
| library I wrote for the project, only a couple hundred
| lines of which are gated behind the "parallel" feature
| flag. It was way less work than the inferior C++ version
| I wrote as part of the RepRap project 20 years ago. Hence
| my stance that software has become increasingly
| sophisticated.
|
| https://github.com/timschmidt/alumina-firmware
|
| https://github.com/timschmidt/alumina-ui
|
| https://github.com/timschmidt/csgrs
|
| What's your point?
| pjmlp wrote:
| The point being those are very niche cases that still
| don't keep the hardware busy as it should 24h around the
| clock.
|
| Most consumer software even less, hence why anyone will
| hardly see a computer on the shopping mall with higher
| than 16 core count, and on average most shops will have
| something between 4 and 8.
|
| Also a reason why systems with built-in FPGAs failed in
| the consumer market, specialised tools without consumer
| software to help sell them.
| timschmidt wrote:
| > don't keep the hardware busy as it should 24h around
| the clock.
|
| If your workload demands 24/7 100% CPU usage, Epyc and
| Xeon are for you. There you can have multiple sockets
| with 256 or more cores each.
|
| > Most consumer software even less
|
| And yet, even in consumer gear which is built to a
| minimum spec budget, core counts, memory capacity, pcie
| lanes, bus bandwidth, IPC, cache sizes, GPU shaders, NPU
| TOPS, all increasing year over year.
|
| > systems with built-in FPGAs failed in the consumer
| market
|
| Talk about niche. I've never met an end user with a use
| for an FPGA or the willingness to learn what one is. I'd
| say that has more to do with it. Write a killer app that
| regular folks want to use that requires one, and they'll
| become popular. Rooting for you.
| ryao wrote:
| That talk predates the death of SRAM scaling. I will not
| bother wasting my time watching a video that is out of
| date.
|
| That said, you should read that I did not say Moore's Law
| was entirely dead. It is dead for SRAM and IO logic, but is
| still around for compute logic. However, pricing is
| shooting upward with each die shrink far faster than it did
| in the past.
| Izikiel43 wrote:
| The big jump between 4 and 5 was the NVME SSD and hardware
| decompression IMO. Load times in a regular PS5 are non existent
| compared to a PS4, that's the big generational jump.
|
| For graphics, I agree it looks like diminishing returns.
| erulabs wrote:
| Excited to see how the software support for UDNA1 works out. Very
| hopeful we'll see some real competition to Nvidia soon in the
| datacenter. Unfortunately I think the risk is quite high: if AMD
| burns developers again with poor drivers and poor support, it's
| hard to see how they'll be able to shake the current stigma.
| martinald wrote:
| Take this with a pinch of salt, but the most recent ROCm
| release installed out of the box on my WSL2 machine and worked
| first time with llama.cpp. I even compiled llama.cpp from
| source with 0 issues. That has never happened ever in my 5+
| years of having AMD GPUs. Every other time I've tried this it's
| either failed and required arcane workarounds, or just not
| worked entirely (including running on 'real' Linux).
|
| I feel like finally they are turning the corner on software and
| drivers.
| jakogut wrote:
| Llama.cpp also has a Vulkan backend that is portable and
| performant, you don't need to mess with ROCm at all.
| martinald wrote:
| Oh yes I know, but "can i compile llama.cpp with rocm" has
| been my yardstick for how good AMD drivers are for some
| time.
| phkahler wrote:
| Why not link to the original article here:
|
| https://www.tomsguide.com/gaming/playstation/sonys-mark-cern...
| rfl890 wrote:
| This was published after TFA, how is it the original?
| high_na_euv wrote:
| Wdym?
|
| 2 vs 1 days
| rfl890 wrote:
| Nevermind, I was confused.
| monster_truck wrote:
| We've known this for a while, it's an extension of the upscaling
| and frame generation AMD already worked on in conjunction with
| Sony for FSR 3 and to a much greater extent FSR 4. Previous
| articles also have highlighted their shared focus on BVH
| optimizations
| shmerl wrote:
| When will Sony support Vulkan on PS?
| departure4885 wrote:
| Why would they? They have their own (two actually) proprietary
| graphics APIs: GNM and GNMX.
| shmerl wrote:
| I'd ask why wouldn't they. Not a fan of NIH and wheel
| reinvention proponents.
| departure4885 wrote:
| 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.
| shmerl wrote:
| That still doesn't make NIH a better approach. NIH is
| dinosaur idea really when it comes to technology like
| this.
| MBCook wrote:
| 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.
| shmerl wrote:
| 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.
| soulbadguy wrote:
| 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.
| shmerl wrote:
| Good, but if it's actually a standard - that's the
| benefit. If it's not - it's just NIH as in lock-in.
| pjmlp wrote:
| 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.
| shmerl wrote:
| This comment is just a bunch of bunk, but regardless,
| Vulkan is the only thing that's a collaborative effort,
| whether it's a mess or not. NIH proponents have nothing
| to offer as an alternative.
| pjmlp wrote:
| Market and tooling, industry has usually ignored Khronos
| APIs when multiple APIs are available to chose from, e.g.
| Nintendo Switch.
| MindSpunk wrote:
| Vulkan's extension story is a mess. Not surprising from
| the people that brought you OpenGL.
|
| However please don't undersell what they got right.
| Because what they got right, they got _very_ right.
|
| Barriers. Vulkan got barriers so absolutely right that
| every competing API has now adopted a clone of Vulkan's
| barrier API. The API is cumbersome but brutally
| unambiguous compared to DirectX's resource states or
| Metal's hazard tracking. DirectX has a rats nest of
| special cases in the resource state API because of how
| inexpressive it is, and just straight up forgot to
| consider COPY->COPY barriers.
|
| We also have SPIR-V. Again, D3D12 plans to dump DXIL and
| adopt SPIR-V.
|
| The fundamentals Vulkan got very right IMO. It's a shame
| it gets shackled to the extension mess.
| pjmlp wrote:
| SPIR-V only exists to reaction of Khronos losing to CUDA
| and PTX, it is the evolution of SPIR, created when they
| realised industry didn't really want to write OpenCL in a
| textual form of C99 dialect, rather bytecode formats
| targeted by multiple compiler backends, including Fortran
| ignored by Khronos.
|
| Microsoft adopting SPIR-V as DXIL replacement is most
| likely a matter of convenience, the format got messy to
| maintain, is tied to an old fork of LLVM, and HLSL has
| gotten the industy weight, even favoured over GLSL for
| Vulkan (which Khronos acknowledge at Vulkanised 2024 not
| doing any work at all, zero, nada), so why redo DXIL from
| scratch, when they could capitalize on existing work to
| target SPIR-V from HLSL.
| MindSpunk wrote:
| DXIL has other issues beyond being an orphaned fork of
| LLVM-IR. LLVM is ill-equipped to represents shaders, and
| there have been real bugs in the wild because of how not-
| a-shader-language LLVM-IR is. See this [0] post under the
| 'The classic subgroup breakage - maximal convergence gone
| awry' section. Read the whole series really if you
| haven't, it's a fantastic dive into how awful this stuff
| is.
|
| DXIL is also a useless intermediate representation
| because parsing it is so bloody difficult nobody could
| actually do anything with it. DXIL was, and still is,
| functionally opaque bytes. You can't introspect it, you
| can't modify it or do anything of use with it. SPIR-V is
| dead-simple to parse and has an array of tools built
| around it because it's so easy to work with.
|
| I don't really see how the OpenCL history is relevant to
| Vulkan either. Khronos losing the OpenCL game to Nvidia,
| certainly no thanks to Nvidia's sabotage either, doesn't
| change that SPIR-V is a much more successful format.
|
| [0] https://themaister.net/blog/2022/04/24/my-personal-
| hell-of-t...
| pjmlp wrote:
| DXIL has the DirectX SDK tooling.
|
| OpenCL history is more than relevant, without SPIR, there
| would not exist SPIR-V.
|
| People love to blame NVidia for AMD and Intel failures
| pushing OpenCL into the industry, and Google completly
| ignoring it for mobile devices, pushing their own
| RenderScript dialect instead, even if Apple would have
| behave differently regarding their platforms, the other
| 80% market has completly ignored it.
| webdevver wrote:
| > Khronos losing the OpenCL game to Nvidia, certainly no
| thanks to Nvidia's sabotage either, doesn't change that
| SPIR-V is a much more successful format.
|
| could you elaborate more on this? sounds interesting
| Keyframe wrote:
| _Why would Vulkan, as opposed to a custom solution
| designed to target that hardware and games specifically,
| be a better solution?_
|
| Vulkan came to be as a low-overhead rendering API
| targeted at 3D video games made originally, as Mantle, by
| both AMD and DICE.
|
| If anything, I'd see any console or game people involved
| with this as a bad signal, considering what a travesty
| Vulkan came to be and that one originated from such a
| group.
| MindSpunk wrote:
| 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.
| lofaszvanitt wrote:
| Yes, but what will use it when there are so few games on the
| platform in the current PS generation?
| brcmthrowaway wrote:
| Who is a better computer architect, Mark Cerny or Anand Shimpi?
| wmf wrote:
| Did we ever hear what Anand does at Apple?
| brcmthrowaway wrote:
| Probably Vision Pro?
| georgeecollins wrote:
| I had the pleasure to spend some time with Mark Cerny many years
| ago. He was honestly one of the most impressive people I have
| ever met. Down to earth and so, so smart. I also think it speaks
| volumes for Sony as a company that an American born video game
| developer (engineer not mba) has such an influential position.
| They are not insular and respect the craft.
| Voultapher wrote:
| There are colleagues of mines that called me the smartest
| person they ever met and I feel so stupid, how do you make the
| most of what you are given?
___________________________________________________________________
(page generated 2025-07-03 23:02 UTC)