I've always wondered about what the CPU needs - is the worst case scenario for CPU when fully utilizing the FP/INT units? (I don't know if simultaneously for either Jaguar or Zen)
@3dilettante help
CPUs have cache hierarchies that amplify bandwidth. Zen2's L1 can handle 2 32 byte reads and a store per cycle (may be some limitations on the sustained write rate, not sure). The FPU is wide enough to generate that traffic on its own in a peak scenario.
The L1 to L2 is 32 bytes in both directions, and the L2 to L3 has 32 bytes in both directions (the L3 theoretically able to absorb the traffic of its 4 cores).
The CCX to the data fabric/memory is 32 bytes in both directions per cycle, so the limit may be in the fabric's clock or the limits of the memory controller.
The cores themselves can very readily exceed the CCX's ability to generate traffic, but that's why they have such expansive caches. For non-streaming loads the CPUs can get by rather well. Something with streaming stores or very linear access patterns that have limited reuse would be where the bandwidth might come up as an issue.
.
Might be interesting to see how 2SE@2Ghz+ vs 3SE@1675 performs -- faster front-ends vs more front-ends.
But does 3 SEs seem right, since that's not a number AMD's GPUs have used? It's not a number that can be as easily balanced in terms of screen tiling, for example.
Now that we know 2 GHz is definitely possible it really comes down to whether the gpu is wider than 36 CUs.
Is there a full quote on that? There are instances where RDNA can be briefly pushed about that high, so did AMD plant its flag on multi-GHz operation on a sustained or base-clock level, or could the consoles be wavering on their desire for consistent performance?
And Gonzalo contains iGPU named Ariel, PCI ID
13E9.
AMD 2G16002CE8JA2_32/10/10_
13E9
View attachment 3638
So, as I said
Ariel - 13E9/13F8 (Gonzalo platform). Navi 10 Lite (RDNA1)
Oberon - 13F9 (Flute platform). RDNA2
There's that jump in the hex values that seems odd, especially since the jump for some reason occurred on the same chip/platform.
I'm not able to give a good reason why that should happen, not since we last discussed this point. There is the fact that the web page that tracks PCI IDs for AMD's devices happened to have the next free ID at 13E9, but that doesn't seem like a well-grounded justification.
And why continue to do so much steeping after at least C0, D0 and E0 and maybe much more intermediate stepping if we believe what AMD told in the last talk at financial meeting(46 minutes of the video) by AMD where they said now they are able to test in hours or week, not months.
I wonder if Navi was subject to that testing method. For one thing, I'm sure that there's some history of software-based validation/verification of upcoming silicon. I think I recall some time ago that chip makers like Intel would scrounge for free cycles on many of their internal systems to get the work units processed. Perhaps with the advent of the more dense cloud systems there's less need for that in particular?
On the topic of Navi's validation, there are some things that seemed like notable misses. While errata are unavoidable, something like a whole memory addressing mode malfunctioning seems like it should have been caught.
On the topic of steppings, a high count like that can also require careful attention to the supposed timeline. On prior nodes, several months to a full quarter were possibilities for a base layer bug revision, after including testing, fast-tracked design changes, validation, masks, and the fabbing of the next revision. 7nm (non-EUV) isn't an improvement.
https://semiengineering.com/battling-fab-cycle-times/
Something like E0, if the letter means a base-layer spin at a minimum, speaks to possibly a full year in manufacturing--assuming that all you were doing was tossing the revision in favor of the next stepping the instant it exited the fab (and there were no *1+, steppings). That's not taking into account that TSMC's lead times due to there being other customers getting wafer starts are long.
When is the assumed arrival date for Oberon A0 that supposedly surfaced in spring-summer 2019, and the claimed E0 occurred when?
Again, they had to have APU ready by summer, given that they sent development kits to developers (+ Flute leaked in July). Why did they go all the way to E0 stepping? Perhaps to make sure every chip clocks at 2.0GHz, which might still be tall order even for RDNA2.
It seems quite unusual to hit E0 in pre-production. It's not considered a good sign to have that many revisions, and if it were because of clocks it reinforces the expectation that steppings are not a good way to push clocks.
Its also question how Sony disables CUs. Do they disable them at Shader Engine level, which should be straightforward or they can do fine grain disabling of CUs on fly. Because for 44-48CUs, they would probably require more SEs, which makes entire design inefficient compared to higher clocked 36CU one (as you will pay price on die size in this case vs minimal performance gain).
I'm not sure about it happening strictly on the fly, but we already have precedent for activations occurring on mode switches--as is done with the PS4 Pro's various modes. Something along those lines, or the initial enumeration of resources and active CU mask setting that occurs after a GPU reset, would only need to happen at specific points in time.
As far as SE counts go, the PS4 Pro was architecturally predisposed to needing more SEs since the original PS4's 20 CUs wouldn't have sustained a doubling for the Pro without additional SEs. Both Sony and Microsoft skipped over any 3 SE solutions, however.
So now with the PS5 the Life of Black Tiger can actually have textures?
Texture
s?
It's a next-gen console, not a miracle worker.
