The Backwards Compatibility Research Poll 2020 Edition

[Deleted member 11852]

What would your vote be if you could chose your own poll option? Sounds like you want BC and would thus pick one of those options based on what you're willing to sacrifice in the next-gen experience to get it.

This bit is what makes it impossible to vote. What is the sacrifice? What is 'slightly', 'notably' and 'moderately'? What do these tiers tangibly mean and how do I know could have been possible without b/c? The decision to make any device/ecosystem backwards compatibility with what came before when fundamentally the hardware is incompatible is going to result in unmeasurable compromise because what could you have you have done were that time, resource and money be used for something else - like better performance through more optimised APIs.

Maintaining compatibility is both an ongoing cost and effort - the fact that Microsoft make it look effortless is testament to their engineering expetise and experience.

What I can say is if Sony scarified 2Tf of theoretical maximum performance to achieve PS4 backwards compatibility with game enhancements (what folks are getting), that was a good decision in my book. But unless Sony or Mark Cerny tell us we won't know. Certainly enough hints have been dropped about 18 vs 36 CUs and layout from PS4 Pro (and PS5) but whether this resulted reducing maximum theoretical performance or whether this was related to cost, we will never know. If the latter (cost), does that count as a compromise?

 

[BRiT]

Where did this concept of having to sacrifice anything on next-gen experience to get BC come from? Is it the way Sony PS5 implemented PS4 BC? I don't see any sacrifice needed on the Microsoft Xbox ecosystem.

 

[Shifty Geezer]

This bit is what makes it impossible to vote. What is the sacrifice? What is 'slightly', 'notably' and 'moderately'?

I roughly spelled it out. 'None' means the next-gen experience is exactly the same as it would have been even without BC. Effectively design a clean-slate next-gen system and then get BC on it. 'Slight' means you don't mind a small impact such as a fatter API reducing maximum utilisation of the next-gen hardware but enabling BC. 'Moderate' means designing a system with BC in mind and making choices that aren't what you'd make if just designing a next-gen system without that requirement.

So basically pick what you personally are happy with, without it being specifically qualified. Are you happy to have the next-gen platform performance impacted in favour of support for the BC library? If not, pick from the top options. If so, how much? A little, or a lot? Pick from the other two options.

 

[Shifty Geezer]

Where did this concept of having to sacrifice anything on next-gen experience to get BC come from?

It's hypothetical, but we've known and discussed for years about the impacts of BC.

I don't see any sacrifice needed on the Microsoft Xbox ecosystem.

Fatter APIs where the hardware can't be used to the maximum. It's the difference between devs going to town poking to specific memory addresses and using every fifteenth cycle of the audio processor to DMA a state change into the GPU, and not. It's the sort of thing that meant Naughty Dog could get more out of the PS1 then the official hardware APIs allowed by repurposing hardware and hijacking RAM.

These days, we assume it's mostly hypothetical and devs won't hit the hardware that low. But PS4 showed that's still not the case with devs using specific hardware architectural references and making it harder to emulate. This has seen AMD include specific GCN support in RDNA - a clean-slate design with zero regard for running old code wouldn't have to worry about this.

 

[BRiT]

Fatter APIs where the hardware can't be used to the maximum.

Fatter than what? SeriesX APIs are no fatter than XBox One APIs which are no fatter than OG XBox APIs. They're even likely skinnier than the actual API implementation on PCs because certain aspects can be guaranteed that can't be done on PCs.

So it's all a matter of perspective.

And we've seen the rash of developers not being able to cope with having more control, just look at all the DX12 vs DX11 implementations. The devs were doing far better being further removed from the hardware layers than having more access to it, at least for the first few years.

 

[MrFox]

If whatever method they need for BC reduces performance by 10%, and they beef up the SoC by 10% to compensate, there's no compromise other than price. In fact there's never any compromise other than price because nothing that's been proposed is preventing putting money into the problem, permanently for the whole gen or temporarily just at launch.

How much is 10% more perf on a $100 SoC? If we talking about only a $480 versus a $500 console being the difference between BC and no BC, it's a no brainer. And the manufacturer would absorb that virtual cost anyway if it helps adoption rate.

 

[Shifty Geezer]

Fatter than what?

No APIs and writing directly the hardware.

So it's all a matter of perspective.

Not particularly. XBox has 'fat' APIs that enable BC and reduce peak hardware utilisation versus devs hitting the hardware. That counts as BC with a small impact.

If whatever method they need for BC reduces performance by 10%, and they beef up the SoC by 10% to compensate...

If you can't use that extra 10% to achieve '110%' in next-gen games then it's compromised. The impact is impact on utilisation of the hardware in the box. A 40 CU console with no BC achieves 40 CUs of power and no BC compromise. A 44 CU console that achieves 40 CUs of power because the API used to enable BC (for past and/or future products) impacts the hardware 10% would be a console with a small impact on performance. It's means some of the hardware you bought for next-gen gaming isn't getting used for driving next-gen games but for 'processing the API' as it were. If that fat API wasn't there, the next-gen games would be 10% better.

 

[iroboto]

No APIs and writing directly the hardware.

diminishing returns. Takes too long for everyone to build their own library, fix errors etc. Coding is much fast on a high level language than a low level one. Some lines of python will extract to many lines of C, which will become hundreds of lines of ASM.

If we had a console with say DX9 vs a console with ASM, the library of games for the one with DX9 would be ten fold over ASM.

We take the trade offs. I'd rather have games to play than no games to play. I'm pretty sure the DX9 ones will look better to given the same amount of labour time for both.

 

[BRiT]

No APIs and writing directly the hardware.

Not particularly. XBox has 'fat' APIs that enable BC and reduce peak hardware utilisation versus devs hitting the hardware. That counts as BC with a small impact.

I entirely disagree with your assessments. There hasn't been extremely low level hardware access in ages. Everything since the days of Atari 2600 has been further abstracting things, hence a matter of perspective.

The XBox APIs are thinner than PC APIs and enable developers to get better utilization than on PC.

 

[Shifty Geezer]

diminishing returns.

I agree. I never proposed it as a realistic option, but a measure of people's sentiments.

I entirely disagree with your assessments. There hasn't been extremely low level hardware access in ages.

See above. In the context of this discussion, it's whether the next-gen experience is compromised to fit BC or not. If it doesn't impact it, if the APIs are no different supporting generation compatibility than they would be otherwise, then it counts as zero impact.

Please note the question isn't 'what should the console companies do' but 'what would I like'. There's no prerequisite that one's preference should be realistic or a sensible business model. So far, a look at the results shows people are willing to accommodate only a small impact for BC, with almost half wanting their next-gen experience to be unaffected by BC. We also see that enhanced BC is quite important when it comes to BC.

 

[BRiT]

Well then it's as I said earlier, this poll has no exact answer that matches the Microsoft Xbox ecosystem. Its very much compromised from the start, so I wouldnt take the results as evidence of anything.

"We want BC and we know next-gen experience won't be compromised one bit and the BC experience will be enhanced!"

 

[Deleted member 11852]

See above. In the context of this discussion, it's whether the next-gen experience is compromised to fit BC or not. If it doesn't impact it, if the APIs are no different supporting generation compatibility than they would be otherwise, then it counts as zero impact.

This is not what dictates the design of an API or why it might change - nor does that really have any bearing on hardware design or backwards compatibility. Microsoft and Apple change the APIs of their OS's on the same hardware routinely, it's not some measure of nextgen'ness or progression. I'm really struggling here with the suggestion of APIs being a relevant metric.

edit: typo.