NVM, 13e8 was the LPC bridge for ariel.
Baseless Next Generation Rumors with no Technical Merits [post E3 2019, pre GDC 2020] [XBSX, PS5]
- Thread starter BRiT
- Start date
- Status
AbsoluteBeginner
Regular
Are you implying that FF16 is also online?
No, pretty sure it's gonna be a mainline title. Just saying he showed enough to warrant leading the team developing ff116. Plus, the guys working on ff7r already have ff7r2 and whatever is next on their plate so them doing ff16 is unlikely.
Here's a trick to dismiss BS leaks: it includes a price this early. Another is the fanboyish comparisons to the competitor.
If the press conf is february 5, they will send the invites in the next 4 days at the latest. They need three weeks to allow journalists planning the trip, plane tickets, and accomodations.
Also the fact that it says compaitbility for every PS system(including PSP??)....definetly skeptical of that. If it reads like an ultimate fanboy wishlist it's probably fake.
Oh how I wished we could access all of the playstation games on one Playstation device. But yes everything sounds way too good to be true.
I mean given that these consoles are basically PC's now Sony could just use some of the emulators found online technically. PS5 hardware probably has the power to run PS3 emulation.
But would be a nice idea. Seems PS3 emulation works pretty well.
An interesting strategy would be to exclude BC always for the prev gen but emulate all others. This could motivate people to upgrade faster, and no need to spend work on HW BC.
But nowadays with games like Destiny / Frotnite etc., you would need to ensure they are ported to nextgen on time additionally.
Speculation is fine, chest beating and insisting a leak is correct is another.
You've made good arguments for why you think you're right but I still don't think there's enough evidence to say PS5 is a 2ghz or even 40 CUs with some disabled. The decision just doesn't make sense to me and that has nothing to do with MS, I think very little of Sony's hardware planning is a reaction to MS or vice versa.
The areas of functionality that were covered have a significant volume, but still look incomplete. If there were added functionality, it wouldn't show for tests evaluating shared functionality that existed prior. A test evaluating features that were known to not exist seems so trivial that its inclusion would be communicating more by its inclusion than what it can say about the hardware.
There are wide subsets of specific functionality not covered, although I have some questions about some values like the latency ones. Navi 10 specifically seems to have a faster L0 than the others, but strangely enough a copy error from cells above might lead to what was given.
I didn't recall seeing backwards compatibility scenarios for the known architectural changes done to the PS4 and PS4 Pro, which would be one thing I'd expect needs evaluation at some point. Just using CU counts and clock speeds is superficially specific to Sony's hardware line, but can also be generically applied to a GPU regardless of its maker. Testing the PS4's volatile flag or ID buffer might stand out as being clearly dedicated to testing BC or testing whether some of them could be dropped on more performant hardware.
That seems odd to me, since it seems to be at odds with how PCI ID values have been used. The PCI ID page for AMD's products has dozens of chips with many die revisions, and they didn't assign a new ID for each respin.
It's not really the point of a value that should differentiate an entity in a system's PCIe configuration. The IO space shouldn't be affected by a stepping number, and even if there were effects there are indications that cancelled or superseded products get overwritten rather than final products putting their key ID values in strange places. There are held-over PCI ID values for Griffin functions, which was cancelled, but the remaining ones look to be end of list entries that may have been left because their prior entries were overwritten by a product that was released.
Perhaps there's some scenario where the alleged Ariel and Oberon chips might have coexisted in some way, rather than the later chip completely replacing it during the dev period, but that would only go to explain two different IDs.
I can't rule out the possibility that things can look more chaotic during internal testing, and that some final SOC would take over the Ariel ID space. It would seem odd in that instance that if Oberon is the final product that its GPU is tossed on the end of the ID list. There seems to be only several ways the IDs are laid out for SOC components, and tossing the GPU at the end when there's already an earlier slot doesn't match.
There are AMD products that have PCI IDs for the same architecture, but they are applied to different products in different contexts, which isn't the theory here.
This doesn't rule out deliberate obfuscation by AMD, as letting confidential hardware show up in benchmark leaderboards with oddly revealing ID strings over so many products and years implies significantly more intent to the timing and values concerned.
The information being debated didn't have any reference, so I'm not really sure there's any clear evidence of a difference from what we have currently.
Even if we give credence to 2/3 of something going to Sony, it lacks some needed context. There are a lot of engineers in RTG, but can we say that 2/3 of them are dedicated to any given phase in a chip's design cycle?
This allegation is also focused on how this specifically starved Navi of resources, but would Navi and Sony's product be hitting the same phase? If their time frames didn't align, then the engineers one would need would come from a different section of RTG.
Perhaps there is a mixture of the passage of time causing some to drift in other directions, or maybe it's also because this is bigger business than before. Maybe some of it could be neglected by the big corporations involved, but some of the topics like patents or proprietary solutions are minefield if you're part of a competitor organization or might be associated with them now or in the future.
It does seem like people who are revealed to be insiders or have connections do have a higher hassle factor to deal with.
I would say the first two make me ask why they would change the name. A different stepping isn't much, unless the "revision" under discussion is much more significant. Different memory modules seems like a minor detail, unless you mean different and incompatible memory types. There could readily be test rigs with the full range of current or near-future speed grades, and there are also chips that have controllers supporting multiple standards, so it would need to be a significant difference in type leading to a physically very distinct chip.
The physical distinction usually matters when giving a new name, unless we revert to deliberate obfuscation as the reason.
I was addressing values for internal caches the the L0. Those bandwidth figures scale with graphics clock speed, the external DRAM bandwidth would not.
One potentially off element for these supposed BC modes is that it's not entirely clear what happens with cache bandwidth being significantly higher at the CU level. Perhaps it can be ignored, but if the focus is on the hardware mirroring the old hardware, that's an area of significant difference that isn't really touched on.
The problem with going by these ID values is that they're not really about tracking chip steppings.
As already noted, the sequence should be in numeric order for the hex values, so 13e9 to 13f8 to 13f9.
However, if we're going by the PCI ID page for AMD, the more important reason for the jump is that the Ariel SOC's device range has a ton of other functions that ends with 13f7.
That has nothing to do with the chip revision, but also doesn't fully make sense since the original IGP slot at 13e9 is still there and why would two GPUs get tossed on the end of the list?
We're not debating 3 GPUs in the SOC.
Last edited:
The decsision makes sense from the prespective of their compaitbility method on PS4 Pro. It lets the keep the same method but with a PS5 mode. Which then makes sense of why it would be such a high clock.
Now whether you think it's feasible for a console chip to achieve such a high clock is another thing. From that perspective it's harder to grasp.
I don't fully understand by compatibility with the PS4 Pro would limit the CU count to 36. The original PS4's CU count didn't limit the Pro to 18, and it's straightforward to inactivate extra CUs if a larger CU is trying to be compatible with the Pro.
I've asked about that and it's been suggested devs could directly control CU scheduling. But like you, I don't see why that couldn't be handled in a firmware virtualisation of the CU counts. I also don't understand how a dev could target specific CUs - is that a feature of GCN?
I commented on this, but the scenario is going in the other direction as to why the hardware won't reveal the additional CUs to software for the original PS4. The hardware is free to not expose the additional resources if the software has issues with addressing them.
I do not see the mechanism for it working in the other direction. The PS5 wouldn't have much trouble hiding extra CUs from PS4 or PS4 Pro software, so I don't see a mechanism for why the hardware would be constrained from having a higher CU count.
There could be possible synchronization or latency concerns if the PS5 had fewer CUs, and somehow wavefronts sharing a synchronization point are being swapped out of a virtualized CU, particularly since GPUs tend to be pretty poor with switching. I haven't seen claims the PS5 would be smaller. A larger GPU wouldn't have that problem since it could trivially contain the same mappings.
Ohhh now I see how Proelite is taking advantage of that as basis for his narrative . Unless he got that figure from a trusted dev of course.
Can you explain why the Pro needed 64 ROPs.
- Status
Similar threads
- Locked
