Developer portal, so information they are relaying directly to everyone using the dev kit. I doubt Sony would state any of this in marketing material. The clock speeds, VRS, mesh shaders, and new cache configuration is all from Sony directly.
Well the clock speeds and VRS seems pretty self explanatory. As for Mesh Shaders, the article states the following:
www.eurogamer.net
The only performance metric we got was for the AI engine and FP16 numbers,so only we have that for a reference point was only those things.
You said Sony stated this though.
Well the clock speeds and VRS seems pretty self explanatory. As for Mesh Shaders, the article states the following:
DF Weekly: New PS5 Pro GPU details emerge - including a 2.35GHz max boost clock
Digital Foundry has new details on the PS5 Pro GPU - including its maximum boost clock and new features.
"The primitive shader features found in RDNA 1 and the vanilla PS5 are augmented with full support for mesh shaders, which should hopefully see more widespread adoption of a very useful feature. Sony points out how the stricter requirements of this feature up against PC APIs are no longer an issue."
Yes, in the development portal. DF is not going to make this stuff up and risk getting backlash for it. Any developer or Sony themselves can correct them if they are making up all the claims they have made so far. Besides, the VRS/Mesh Shaders line up with what we know of the PS5 and the cache configuration is similar to RDNA 3.
So you don't have anything showing Sony saying anything.
I'd assume it means Mesh shaders are simply more programmatic and thus easier to use. So the difference lies in flexibility of the feature and not any performance improvements.
arstechnica.com
OoO Execution is about maximising ILP as much as SMT is about TLP. Covering stalls, data dependencies, etc… (including and not in small part allowing to overcome the relatively tiny x86 register file limitations) is part of how the the back end will keep the execution units fed extracting as much parallelism from the instruction stream. How do you think they feed these monsters (incredibly wide backends otherwise?):
. No SMT at all, so a single thread need to keep them fed.I think we get that
.Nobody is disputing that, nobody is saying it is not a good tool to have, not suggesting we try Itanium again… not today haha.
Haha, sure breaking an NDA to correct them? Not worth it at the moment.
We don't have anything about the PS5 Pro directly from Sony. Guess it doesn't exist then. PSSR was just something somebody made up.
Well obviously not right now, but when it is officially unveiled.
The Pentium: An Architectural History of the World's Most Famous Desktop Processor (Part II)
John "Hannibal" Stokes concludes his series on the growth and development of …
Pentium 4’s branch predictor was estimated to be well above 95% too yet general purpose branchy code hurt its performance quite a bit (due to its very very deeply pipelined design too), the point was not about branch prediction rates, in the paper they talk about memory load/store instructions reordering and conflicts that may arise (as well as decreasing instruction cache hit rate).
Again, the miss rate we were talking about before was data cache misses and how much can the OOOE front end hide (10-20 cycles sure, 60-80 cycles … it depends… going further out to RAM, which is what Fafalada was saying it is miles off of that, no it is not designed to cover that… even very aggressive designs).
OoO Execution is about maximising ILP as much as SMT is about TLP. Covering stalls, data dependencies, etc… (including and not in small part allowing to overcome the relatively tiny x86 register file limitations) is part of how the the back end will keep the execution units fed extracting as much parallelism from the instruction stream. How do you think they feed these monsters (incredibly wide backends otherwise?):
… and the modern M3 is based on even fatter cores
Purely compiler based approach to single threaded ILP maximisation can be seen in Transmeta’s Crusoe line and famously in Intel and HP’s Itanium processors line.
Again, I think we are discussing semantics. Because what keeps you from exploiting all this parallel execution potential? Misprediction, cache misses, other stalls, etc…
I think we get that
Nobody is disputing that, nobody is saying it is not a good tool to have, not suggesting we try Itanium again… not today haha.
It is not. Sony is saying the same thing (just watched the section in the video) as they did with PS5 boost clock. That it is the maximum it can run, anything else is speculation by DF and they mention it as such.
As far as the underlying RDNA2 HW they are the same thing as an AMD exec interview clarified. Mesh Shaders get compiled to primitive shaders, but that may have changed in RDNA4.
We have nothing from Sony this is the only correct thing you said.
It's great that you believe that, but Sony claims the opposite. Nobody has reported that any of these features will be backported to the original PS5. Not that it really matter in the end as hardware VRS and the difference between primitive and mesh shaders are minor.
The fact that Sony needs to clarify the difference between peak clocks, average TFLOP numbers, and they have stated it is the maximum clock speed but is usually power limited. Sony also said it is obtainable "on a limited subset of games". Not that is really matters, 2.18Ghz vs 2.35Ghz is basically unnoticeable by anyone.
Sure, if you want to be extra pedantic about things, I'll change my statement below:
Again you are claiming things to be said by Sony without showing Sony saying a single thing.
gpuopen.com
The implication for anyone following the conversation is that the Sony claims are being reported by DF. I'm not going to preface every single discussion with the Verge reported, or DF reported, or as per the leak from MLiD. In this context the Sony claims are what are being reported by DF (and others) on the official developer portal. As is everything being discussed in this thread.
So no statement from Sony(like you clearly stated)
That wasn't the information DF had when MLID posted that screen shot a while back.
Good for you. I'll continue to discuss the leaks as I please.
There won't be any statements from Sony until the Pro officially launches. But other sources will be able to confirm the information listed on the developer portal.
Continue to lie about Sony saying things with no proof as well.
He clearly said Sony said things.
If you want proof of anything then I'm not sure what you are doing in a speculation and leak thread. Obviously the implication of anything being discussed here is through the lens of it being leaked by gaming websites and media.
He said that the information listed comes directly from Sony. Which would be true if it is on their developer portal. (And other sources should be able to confirm this).
Also curious that the PS5 performs similarly to the Series X in this game even though the latter uses Mesh Shaders as opposed to the PS5 which has some sort of "RDNA 1 Primitive Shader feature".That is true. But there has top be something more to it.
Remember that RDNA1 on PC has trouble running a game like Alan Wake, with Mesh Shaders. But RDNA2 runs it just fine.
So why is the primitive Shaders in RDNA1 not good enough to be used with Mesh Shaders? Is it just drivers? Some hardware feature missing?
In this article AMD talks about they integrate AMDs Primitive Shaders into the Mesh Shader pipeline.
From vertex shader to mesh shader - Mesh shaders on AMD RDNA™ graphics cards
This post is the start of a new series which aims to demystify mesh shaders through examples and tutorials.
The hoops are real.
No need to jump through any hoops. We just need independent confirmation of the contents of the developer portal.
But you are as he quoted Sony and Sony saying what he said is nowhere to be found.
His original quote was missing a "DF claims" in reference to the developer portal information, since it has not been independently verified. So yes, that's his terrible crime, for which he must be punished by the forum gods. But my point is simply that the DF article may turn out to be perfectly accurate representation of what is on the portal.
how exactly are their customers being screwed over
I worry about this too but from the latest DF thread it seems like the SEs have been beefed up to accommodate the extra CUs
