Could Next-Generation consoles use Nvidia, and still keep BC?

[invictis]

Background.
When Sony went with the PS4 Pro over the PS4, they used a butterfly GPU system that allowed them to switch off half the GPU when running a PS4 game while allowing the full 36CU to be used when running a Pro game.
However when MS went for the One X, they wernt held to the same hardware restrictions as Sony. Not only did they have a CU number that held no regard to the One S, but they also were able to increase the RAM amount to 12 GB without an issue.

Again with the PS5, Sony had to stick with the same CU number to keep BC with the PS4 and PS4 Pro while MS didn't have the same issue and wernt held to a particular amount of CUs etc.

I have had it explained that this is because MS games are wrapped in a software API while Sony's games arnt and are tied to the hardware mote. Now this may be wrong or right, or I may have arsed up the explanation.

So does this mean that MS could change to Nvidia GPUs for the next gen and be able to have BC with their AMD hardware?

 

[cheapchips]

The MS back compatible team have pulled absolute miracles. They could probably uses an Arm CPU with Intel GPU for their next console if they wanted.

 

[Deleted member 11852]

This is an interesting question indeed, but there are some misconceptions here already.

When Sony went with the PS4 Pro over the PS4, they used a butterfly GPU system that allowed them to switch off half the GPU when running a PS4 game while allowing the full 36CU to be used when running a Pro game. However when MS went for the One X, they wernt held to the same hardware restrictions as Sony. Not only did they have a CU number that held no regard to the One S, but they also were able to increase the RAM amount to 12 GB without an issue.

I see this posted from time to time but have never found a source for it. Digital Foundry spoke with Mark Cerny after the PS4 Pro released and words used to describe the butterfly GPU design is "simple" and I don't see any suggestion of there being some kind of limitation.

As an engineer myself, when I approached designing anything, you never want to over complicate the design unnecessarily so if the butterfly design works for Sony, they would be foolish to redesign their APU to be totally different - notwithstanding the Pro was going to appeal to a much smaller audience so cost considerations are way more important. Also, Sony did increase the amount of RAM in PS4 Pro. Source: DF interview.

The MS back compatible team have pulled absolute miracles. They could probably uses an Arm CPU with Intel GPU for their next console if they wanted.

It's worth remembering that the Xbox One / Xbox Series are not hardware backwards compatible with the Xbox 360. This is what Microsoft said in their interview with Digital Foundry:

Basically, we have a VGPU - or an Xbox 360 GPU that we've recompiled into x86 - and we run the entire 360 OS stack. We take each game, we recompile it so that it runs, but basically we're running it still in a 360, and the team goes through the game with multiple passes."

That's not to take anything away from the effort Microsoft put in, but changing hardware is not simple and the 360 games that run on modern Xbox hardware have been individually produced. They could do this again, so it depends on what people think of as "backwards compatible". Do we mean run the original game code unmodified, or running it with some manual effort on a per-title basis?

 

[cheapchips]

It's worth remembering that the Xbox One / Xbox Series are not hardware backwards compatible with the Xbox 360.

I couldn't help but think that since One/Series games run in a hypervisor anyway, future hardware 'simply' needs to emulate/run it in a performant way.

Back compatibility is VMs all the way down!

 

[Clukos]

Nvidia are a notoriously bad hardware partner in the industry, they pissed off pretty much most companies they worked with (Apple, Sony, MS). They'd also have to unveil some of the black box secret sauce (behind NDAs of course) which I'm not sure they'd be willing to do.

BC is doable but it'll probably need a bit of work, if anyone can figure it out it's MS though, they've really done a great job with the Xbox One and the Series consoles.

 

[Deleted member 11852]

I couldn't help but think that since One/Series games run in a hypervisor anyway, future hardware 'simply' needs to emulate/run it in a performant way. Back compatibility is VMs all the way down!

Until the last six or so years I was a server guy and almost everything running on servers is virtualised so I'm familiar with what virtualisation technologies can deliver and it's not nearly as magical at solving problems as some people ascribe.

Since Xbox 360 Microsoft have run the software environment for their hardware within a hypervisor, abstracting access to some of the hardware through a virtualisation layer and APIs. Microsoft were way ahead of the curve in terms of using technologies now common in modern desktop operating systems and browsers (sandboxing websites is a variation on virtualisation) but in terms of games, if a game needs access to a particular hardware capability that no longer exists because you've swapped it for a different piece of hardware (or just works completely differently that requires code changes), even if it is 99% functionally capable as to what you've replaced, you still have to manage that issue.

Virtualisation isn't a magic bullet for these problems. Abstracting the way software (games) accesses hardware is why APIs and drivers exist. The Xbox model is different but isn't immune to the same problems. From the DF interview:

But fundamentally, Xbox 360 back-compat works on the principle of an emulation layer. There is some hardware assistance and - yes - some 'secret sauce' (Microsoft didn't want to be drawn on how the emulator supports Xbox 360's VMX128 vector units, for example), but the team is now at the point now where everything an Xbox 360 can do, its emulator can mirror in software. And that's impressive - by the end of the 360 era, developers had leeway to bypass the DirectX API and address the GPU more directly, potentially making transcompilation of code more challenging. Stillwell confirms that this isn't a problem for the emulation layer and in fact, the only thing that isn't supported is XNA.

A tremendous amount of work and a multitude of technical approaches were required for any of this to work - and it is indeed impressive work - but it's also why only around 650 Xbox 360 titles were ported to work on Xbox One and only around 60 from the original Xbox. Going forward (from say last generation titles), things should be much better. Last generational paved the implementation of technologies from launch that allowed both consoles to have mid-generation updates and the experience of delivering that no doubt was hugely useful in architecting current generation hardware.

Simply, if games rely on a piece of hardware, or specific hardware functionality that exists in AMD chips but not tomorrow's Nvidia chip on Xbox, you would to work around that. And the words "work around" really do not emphasise strongly enough how complicated this type of problem is.

 

[Deleted member 11852]

Nvidia are a notoriously bad hardware partner in the industry, they pissed off pretty much most companies they worked with (Apple, Sony, MS).

What evidence is there that Nvidia pissed off Sony? This is news to me. Nvidia obviously didn't have a solution suitable for PS4 and AMD did. I don't seen any more to it than that.

I know Apple dropped Nvidia (because Apple heavily hinted) that the failure rates of Nvidia 8xxxM chops that Apple used in 2012-era MacBook Pros was the reason they dropped them - I recall, I had one that failed! As for Microsoft - wasn't that about IP? I feel that's on Microsoft for entering into the initial partnership not understanding what Microsoft would own, versus what Nvidia was own.

 

[Clukos]

What evidence is there that Nvidia pissed off Sony? This is news to me.

The RSX GPU was less powerful than what was originally promised afaik, it put them in a really bad spot versus the 360 at the start of the generation apart from shipping it with Cell. There's more to it than just the hardware but companies rarely go public with stuff like this, they just avoid doing business

TSMC is also not very happy with Nvidia after the stunt they tried to pull with Ampere but perhaps things have calmed down now (all leaks point to Nvidia moving back to TSMC for Ada Lovelace).

 

[Shortbread]

What evidence is there that Nvidia pissed off Sony?

There was some bad blood or at least some strain surrounding Nvidia's later statements on why the RSX didn't perform as well ATI's Xenos XB360 GPU solution. IIRC, Nvidia simply pointed to the CELL as being the problem, or hampering RSX performance. Later-later statements became that Sony approached them too late on creating a more custom solution for PS3.

 

[Shortbread]

Again with the PS5, Sony had to stick with the same CU number to keep BC with the PS4 and PS4 Pro

I still have a hard time believing this. Does this mean PS6, PS7, and so-on will have to stick permanently to a 36CU configuration on keeping BC with prior generations, and simply depend on IPC/logic improvements (vs higher CU counts)?

I'm just more inclined to believe that Sony made more concessions on the PS5 GPU design for a more robust SSD/NVMe solution.

 

[Riddlewire]

I still have a hard time believing this. Does this mean PS6, PS7, and so-on will have to stick permanently to a 36CU configuration...

No, not at all.
They can go with 72CU and simply disable half of them.

 

[Shortbread]

They can go with 72CU and simply disable half of them.

BC purposes, sure. 64CU PS5 Pro here we come.

 

[Deleted member 11852]

Nvidia simply pointed to the CELL as being the problem, or hampering RSX performance. Later-later statements became that Sony approached them too late on creating a more custom solution for PS3.

This was always my understanding. I recall some narrative about Cell driving the graphics directly which always sounded mental.

I still have a hard time believing this. Does this mean PS6, PS7, and so-on will have to stick permanently to a 36CU configuration on keeping BC with prior generations, and simply depend on IPC/logic improvements (vs higher CU counts)?

The notion that PlayStation GPUs are locked into using multiples of 18 compute units ad infinitum is bizarre and makes no sense. With PS4 Pro, Sony did the clean and safe thing by just mirroring the existing GPU with a bunch of enhancements. It seems clear from Mark Cerny's comments that Sony were not 100% on how far they could change the hardware in Pro without breaking some PS4 games:

But what about deploying the additional Pro GPU power in base PS4 mode, similar to the Xbox One S? Or even just retaining the 111MHz GPU frequency boost? For Sony, it's all about playing it safe, to ensure that the existing 700 titles just work.

"I've done a number of experiments looking for issues when frequencies vary and... well... [laughs] I think first and foremost, we need everything to work flawlessly. We don't want people to be conscious of any issues that may arise when they move from the standard model to the PS4 Pro."

PS4 Pro was Sony's first move into backwards compatibility without shoving the last chips into the new box. It was also likely done on a fairly tight R&D budget and timetable. When you're only going to sell a quarter of the regular product, you can't go overboard with R&D if you want to recoup those investments down the line. PS5 would have been heavily in the silicon roadmap design stage when Pro finally launched.

 

[AzBat]

A tremendous amount of work and a multitude of technical approaches were required for any of this to work - and it is indeed impressive work - but it's also why only around 650 Xbox 360 titles were ported to work on Xbox One and only around 60 from the original Xbox.

Their technical approach wasn't the major obstacle behind less than full library support. They required licensing approval from publishers & developers. Some of the publishers & developers providing that approval had legal issues or may no longer be in business. Microsoft learned from this and supposedly changed contracts going forward. The business side shouldn't be as much of a barrier for future backward compatibility.

Tommy McClain

 

[BRiT]

Since the discussion had already expanded to involve Sony, the thread title was adjusted.

 

[BRiT]

I still have a hard time believing this. Does this mean PS6, PS7, and so-on will have to stick permanently to a 36CU configuration on keeping BC with prior generations, and simply depend on IPC/logic improvements (vs higher CU counts)?

I think most of this is from a software API level perspective. Like with the 4Pro APIs they expanded the software structures and ranges only enough to allow for slightly larger but not boundless counts. In particular, what I'm remembering from glancing through the SDK API is some portions where the CU identifier is passed around and it's limited to 0-31 or where the SA identifier is passed around and it's limited to 0-4. If the hardware has any more than those API limits then it won't be used.

Disclaimer: my memory is fuzzy and it's been a few years since I've look at it, so the details may be off, but the general premise is conveyed.

 

[Remij]

Could they? Yea I believe so. Where there's a will, there's a way after all.

At this point though, if I'm Microsoft.. I'd be looking into a way of building an emulation layer (something like proton or whatever) to emulate the console environment on PC, and then transition the console device from bespoke hardware to that of a generic PC (essentially what the Xbox was in the beginning) and allow customers to build their own, or buy custom built from Xbox approved vendors.. just like PCs.

Then from that point, you can focus on only building for one platform which will cover the PC, Server, and console/handheld markets.

I know there's a million reasons why this isn't practical or whatever.. but I think going into the future it doesn't make much sense to spend tons of R&D developing multiple consoles per generation just to keep up and constantly having to rebuild a userbase and continue compatibility. Companies don't like being locked down and dependent on others when they can help it.. and MS is the kind of company that can afford to brute force their way past these situations through software. They're well suited to it, and I think it makes a lot of sense here.

 

[Shortbread]

At this point though, if I'm Microsoft.. I'd be looking into a way of building an emulation layer (something like proton or whatever) to emulate the console environment on PC, and then transition the console device from bespoke hardware to that of a generic PC (essentially what the Xbox was in the beginning) and allow customers to build their own, or buy custom built from Xbox approved vendors.. just like PCs.

Even if MS comes up with a particular game configuration/emulation for each new generation, the cost for Xbox IHV partners on producing such systems would be fruitless, or not very profitable. The main reason for consoles (or what makes them attractive to the masses) is that Sony/Microsoft/Nintendo are willing to eat the cost on mid-end hardware, and recoup cost/profits through software and peripheral sales. If Microsoft is willing to share software/peripheral sales with their IHV partners on reducing cost of these generic boxes, then more power to them.

 

[Silent_Buddha]

A tremendous amount of work and a multitude of technical approaches were required for any of this to work - and it is indeed impressive work - but it's also why only around 650 Xbox 360 titles were ported to work on Xbox One and only around 60 from the original Xbox. Going forward (from say last generation titles), things should be much better. Last generational paved the implementation of technologies from launch that allowed both consoles to have mid-generation updates and the experience of delivering that no doubt was hugely useful in architecting current generation hardware.

That isn't the only or even main reason. Getting the around IP rights for early titles (redistribution of code [not the same as resell], music, actor likenesses, voice actors, creator rights, developer's rights, etc.) is a nightmare and most, if not all, titles that aren't available via BC is due to this.

It's the same reason that even though BC is dead simple on PC in comparison many titles (like NOLF) can't be legally redistributed (not the same as re-sell). Although there are some sites that are doing that as they believe all the rights related to the game have expired. However, while it's easy for a small website to do that and not become a target of any rights holders, it's a different story for a large corporation such as MS where there's significant money to be made by a rights holder if MS is found to have violated any IP holder's rights. For example, the rights to music lasts 70 years or more.

Since the BC work for Xbox and X360 require a download of the BC package, that means that MS are in effect redistributing the game even if the end user owns a physical copy of the game. Because MS needs to redistribute the game, they require permission from rights holders WRT the redistribution of said game. That's usually easy with publisher catalogs, although it gets more difficult with Xbox and X360 era titles where even the original publishers or developers of a game may not have all the rights to everything that the game contains.

Your own quote even mentions that hardware compatibility/emulation isn't a problem for even non-standard (outside of API) useage of the X360. XNA isn't supported because that's even more of a nightmare WRT rights holders, so they likely didn't even bother attempting to see whether there are any XNA titles that wouldn't work.

Regards,
SB

 

[Lurkmass]

If hobbyists couldn't get their Mantle translation layer to run on other vendors then there's no hope to achieve better results with modern console APIs ...