Predict: Next gen console tech (9th iteration and 10th iteration edition) [2014 - 2017]
- Thread starter Shifty Geezer
- Start date
- Status
what do you mean by "separate". Windows 10 should support dual-CPU systems (server versions much more) with multiple cores on each.
Or do you mean different CPU types?
At least it supports multi-core-CPUs that are clocked differently (thanks to the power-saving mechanisms)
Current versions support (up to? home could be more limited) 2 CPUs and up to 32 (32-bit) or 256 cores (64-bit), but with Fall Creators Update they're introducing "Pro for Workstation" which includes support for 4 CPUs
looking for Kaotik's answer.
So yes the next console could have more than 1 CPU if windows supports it.
Whenever I think about next gen, and MS. You just gotta think about windows first, before any and all else. If it could support asymmetrical CPUs, that would be interesting.
Maybe not a completely separate chip, but it would be great to have a low power core that can still get context switch. Idle power consumtion has been a joke despite promises.
Maybe they could just shove in a couple jaguar cores hanging off the interconnect bus for that sort of thing (big.LITTLE-esque).
Otherwise, a separate chip/die + interconnect + memory space seems more trouble than its worth if it's supposed to be integrated with normal game operation as well.
Otherwise, a separate chip/die + interconnect + memory space seems more trouble than its worth if it's supposed to be integrated with normal game operation as well.
Are Zen cores more power efficient than Jaguar cores? Why not just have them all as Zen? Jaguar imo is insufficient for UWP apps and OS operations today (at least imo), and will be insufficient for OS operation in 3-4 years time I think. They should have a low powered core for standby/offline mode; I do agree with this, but I think customized Zen would probably be better at this task as well.
That's the case usage, but it does certainly depend on how they can customize Zen to shut off individual cores or how it compares to just needing a single operational Jaguar core to do what we do in current gen.
One thing we do know now since the EPYC launch is that the cache protocol has changed from AMD's preferred MOESI to a new MDOEFSI protocol.
Details are a bit light on the behaviors of the new states or possible alterations on the existing ones.
There are papers on integrating disparate protocols, usually with certain rules of transfer or residency that convert/invalidate certain states if a line migrates into the simpler domain. A simpler, if hackish, direction would be to treat coherence more weakly, with invalidation-heavy interactions similar to how the CPU domain meshes with a rather primitive GPU cache protocol.
Getting Jaguar to plug into that may be an interesting exercise as well, since it's not clear if its behaviors line up with the new fabric or some of the MMU and TLB changes.
One current or upcoming direction that seems like it might be in current cores (or based on patent dates potentially future ones) is a method of setting a lease time for TLB entries in individual cores to minimize the costs incurred when one core updates a TLB entry that might have copies in other TLBs. I'm not sure if Zen has it now, or if a future version would have that. Unless Jaguar is updated to match, sharing the same virtual memory space may not be workable if the cores do not agree on the same rules.
Part of the problem with the power levels may have been the number of disparate interconnects and internal system subdivisions, which might be where the new fabric could help create more granularity between full-power and complete power gating. Or it might someday, the balancing act from the latest chips like Vega's fabric implementation still seems a bit off.
Maybe Raven Ridge could indicate if the hardware management can be made tractable for a system resembling a console.
Getting the lowest-power state with standby functions might still be too far below the range of Zen's typical range, though. Even mobile chips might still defer to a simpler subsection of the whole SOC.
btw, that is no technical limitation. Just a licensing limit. After all, windows server & Pro/home versions use the same code since NT/2000/XP. They are just always more or less up to date, dependening on when the OS was released.
What I wonder is, do you guys think that same chip should be the one running the OS during gameplay too? I think it should, as if you are gonna have the extra chip in there anyway, might as well beefy it up enough so that you can liberate the game-chip completely from having to worry about the OS, thus simplifying the chip's operation to some extent.
On the other hand, one may think since you are sticking two apus in there, you might instead prefer to use it for a big discrete gpu and a big discrete cpu with Big-Little cores for standby, and just share that cpu and gpu for game and OS stuff much like done right now. Could be a better banf for the buck, but loses some of the simplicity gained by separating OS and game simulation on the hardware level.
I think this depends mainly on the hypervisor for Windows 10. Somewhere you want a secure console, and the idea of separating the functions from OS and game, could create a potential security breach, one in which an add-on debugger board could potentially override or provide additional entry nodes for piracy. I know we don't often talk about security when we do the dream team talk, but I'm sure security is a big part of how these systems are designed as well; they do have to uphold their licensing model from piracy, as well as their ability to subterfuge attempts at hacks etc.
(Lobs grenade...)
Just reserve one of the SPUs for the OS so it’s not guaranteed available during gameplay and you’re all set.
(Ducks and runs for cover.)
This scheme would have to consider what functions are considered the OS. It's not just another application that runs alongside the game, rather it is a layer whose various components may be called upon by software inside the game partition and from the outside.
There can be functions that could more readily run on another chip, if they aren't too demanding or not tightly integrated. Some functions actually might do better in a dedicated processor or chip, like platform security.
Some OS elements would be subject be trade-offs based on how often parts of the OS would be called upon and how important it is that those functions get done quickly. Some fundamental system or platform functions may need to be near the threads that need them, if the game is not allowed to directly access them.
That would break back compat with the PS4 Pro.
With the exception of of PS4 all Sony consoles were backwards compatible. When consoles moved to x86 the promise was that newer machines would not break older games going forward.
I don't think there was any such promise made or even implied, only people thinking that.
you could argue that after all the times they've done BC they've come to the realization it doesn't matter too much when all's said and done.
I'm not putting that forward personally, just saying it's a valid view, even if landscape is changing with digital content.
I think backwards compatibility matters even more now than ever with the growth of indies and digital download games.
Hopefully Nintendo will use the iOS model for Switch. With regular incremental updates that increase CPU and GPU power without breaking Software. They used to do that with the old Gameboy line, the pocket colour was twice as powerful as the original Gameboy. Although Apple seem to be doubling iPhone GPU power on an annual basis.
Potentially. Hopefully Sony has the foresight to work on a solution to backwards compatibility concurrently with the development of PS5 if BC is one of their goals. If they go with AMD again there should be less hurdles than when going from one PPC to x86. BC should be more feasible for PS5 I would imagine.
Yes, which is why the 4Pro is what it is, a Frankenstein of the original PS4 APU with some new instructions bolted on. (MM FP16 and Gradients).
- Status