Technical Implications of Backwards Compatibility for CPU and GPU? *spawn*

  • Thread starter Deleted member 11852
  • Start date
D

Deleted member 11852

Guest
As a consuner I never want a hard-reset on the ability to play all the games I own.
At some point, this is inevitable unless Microsoft are going to devote the kind of resource at maintaining compatibility they used to do previously for Windows applications. Now that may happen as a consequence of Xbox becoming a 'WindowsBox' in-all-but-name but, would you want Microsoft to pass over exciting new technology for a future Xbox if it meant they couldn't maintain backwards compatibility?

That may happen. I'm with you in principle and spirit, but absolutes often come back to bite you in the arse! :yes:
 
At some point, this is inevitable unless Microsoft are going to devote the kind of resource at maintaining compatibility they used to do previously for Windows applications. Now that may happen as a consequence of Xbox becoming a 'WindowsBox' in-all-but-name but, would you want Microsoft to pass over exciting new technology for a future Xbox if it meant they couldn't maintain backwards compatibility?

That may happen. I'm with you in principle and spirit, but absolutes often come back to bite you in the arse! :yes:

Like Cell 2 rebirth? :runaway:

Onto a more serious note...

That likely will never happen. What do you expect to be invented that wouldn't be able to run x86 / 64bit code in the future? I'm willing to bet that by the time something as disruptive from a hardware perspective is invented, the new hardware will be beast-enough to have BC. Or well before that point, we'll be able to play our existing games library streamed from the internet. Perpetual BC with Perpetual games library. *shrug*
 
That likely will never happen. What do you expect to be invented that wouldn't be able to run x86 / 64bit code in the future?

Nothing on the CPU front, but the GPU? Those things reinvent themselves on a regular basis. Backwards compatibility works because the enormous effort on the part of AMD, Nvidia and the DirectX/OpenGL API teams.
 
Nothing on the CPU front, but the GPU? Those things reinvent themselves on a regular basis. Backwards compatibility works because the enormous effort on the part of AMD, Nvidia and the DirectX/OpenGL API teams.

Okay, that makes sense. Just playing out that situation or logic below...

So for XBox.Next then backwards compatibility would or could be an issue if the new GPU hardware wouldnt have DX11 or DX12 drivers as needed for Xbox One titles. Assuming Xbox.Next would have DX13 - DX14 then for Xbox.NextNext to have backwards compatibility the GPU would require those drivers too in addition to whatever drivers it runs natively like DX15 - DX16. So for Xbox.NextNext to support back to the original Xbox One games they would effectively need drivers for DX11 and DX12 upto the latest and greatest DX version.

I could see somewhere down the road for there to be another big redefining moment of graphic APIs on Microsoft's side.

If the older BC drivers aren't supported by the new GPU hardware provider then it would fall onto Microsoft to provide the bridge driver layer to translate the older DX calls to newer DX calls. While MS could likely do it, the easiest and best approach would be support directly from the hardware manufacturer.

Likewise similiar reasoning applies on the other side for Sony with whatever graphics APIs they provide and would need.
 
Okay, that makes sense. Just playing out that situation or logic below...

So for XBox.Next then backwards compatibility would or could be an issue if the new GPU hardware wouldnt have DX11 or DX12 drivers as needed for Xbox One titles. Assuming Xbox.Next would have DX13 - DX14 then for Xbox.NextNext to have backwards compatibility the GPU would require those drivers too in addition to whatever drivers it runs natively like DX15 - DX16. So for Xbox.NextNext to support back to the original Xbox One games they would effectively need drivers for DX11 and DX12 upto the latest and greatest DX version.

I could see somewhere down the road for there to be another big redefining moment of graphic APIs on Microsoft's side.

If the older BC drivers aren't supported by the new GPU hardware provider then it would fall onto Microsoft to provide the bridge driver layer to translate the older DX calls to newer DX calls. While MS could likely do it, the easiest and best approach would be support directly from the hardware manufacturer.

Likewise similiar reasoning applies on the other side for Sony with whatever graphics APIs they provide and would need.
There's quite a few features packed into DX12 to be honest. I see it as being around for at least a solid decade from today, if not longer.
We'll continue to see an evolution of feature set, sure, but I think the API is pretty much the last one for a long time. I think we'll see tighter integration between DX12 API and the hardware, not less.

DX12 will continue to be developed going forward, I think much like Windows 10 is the last windows.
Latest blog post on new DX12 features:

https://blogs.msdn.microsoft.com/directx/2017/11/07/announcing-new-directx-12-features/

friendly reminder: When we talk about DX12, we're talking about a completely new and infant API for developers. DX9-11 are a family. But DX12 is a ground up different API.
 
I was thinking that DX12 would be a long lasting API, but even rolling out 2 entirely new DX APIs in the lifetime of a console and then the next console doesn't seem too insurmountable from the aspect of offering BC support. I'm predicating that on the basis that at least a couple to a handful of them would be evolutionary as opposed to another new revolutionary rebase. However, if some entirely new means of rendering does happen within the next 10 years that completely throws out the current rendering concepts, then that could pose problems from a Backwards Compatibility level. I'm sure then it would be a question of how much work would it take to engineer the shim layer to provide for Backwards Compatibility.

Anyways, should probably spin this onto it's own thread to draw better attention to the more technical aspects.
 
When has a AMD/nvidia gpu ever been released that broke compatibility with older pc titles.

The benefit of going AMD/intel/nvidia is that u aren't the only one where backward compatibility matters.
 
When has a AMD/nvidia gpu ever been released that broke compatibility with older pc titles.

The benefit of going AMD/intel/nvidia is that u aren't the only one where backward compatibility matters.
Backward compatibility for a console is completely different than for a PC. For PC the IHV maintains the driver and the application doesn't have low level access to the hardware. It doesn't work the same way for consoles so 100% backward compatibility is much more difficult.
 
Backward compatibility for a console is completely different than for a PC. For PC the IHV maintains the driver and the application doesn't have low level access to the hardware. It doesn't work the same way for consoles so 100% backward compatibility is much more difficult.

Uhm, maybe you should look again, in particular the Xbox One consoles because what you're saying doesnt align with MS consoles since 2013. They still dont have as low of access on PS4 as they did in the past too. It doesnt seem like developers really have had as low level access since last gen with X360/PS3.
 
Uhm, maybe you should look again, in particular the Xbox One consoles because what you're saying doesnt align with MS consoles since 2013. They still dont have as low of access on PS4 as they did in the past too. It doesnt seem like developers really have had as low level access since last gen with X360/PS3.
Developers have low level access if they want it but you can ignore that because the lack of a modifiable driver is the main difference between PC and console. It's why there are no global driver updates to break or improve existing games.
 
When has a AMD/nvidia gpu ever been released that broke compatibility with older pc titles.

Constantly. Registers on graphics hardware change frequently - this is the purpose of drivers which abstract the hardware changes for the API stack, which change less frequently. Want an example? Try running a modern GPU architecture using a set of drivers that predate that GPU by 6+ months. That's a solid test of how compatible hardware is compared to just it's predecessor. :yep2:

The only instances where this will work is where the new chip is its renamed old predecessor on a new process, so functionally identical.
 
Developers have low level access if they want it but you can ignore that because the lack of a modifiable driver is the main difference between PC and console. It's why there are no global driver updates to break or improve existing games.
I'm confused on this point. I thought the reason why Xbox didn't have compatibility issues was because they were packing everything together into the Virtual Machine for the game, so major SDK revisions wouldn't break older titles. And this is also a reason why the xbox is able to support so many different formats of backwards compatibility today.
 
I was thinking that DX12 would be a long lasting API, but even rolling out 2 entirely new DX APIs in the lifetime of a console and then the next console doesn't seem too insurmountable from the aspect of offering BC support. I'm predicating that on the basis that at least a couple to a handful of them would be evolutionary as opposed to another new revolutionary rebase. However, if some entirely new means of rendering does happen within the next 10 years that completely throws out the current rendering concepts, then that could pose problems from a Backwards Compatibility level. I'm sure then it would be a question of how much work would it take to engineer the shim layer to provide for Backwards Compatibility.

Anyways, should probably spin this onto it's own thread to draw better attention to the more technical aspects.
=P
Looking forward (titan V) for instance, the best we could get is the usage of those tensor cores ;)
I don't think consoles will ever be leading the pack when it comes to cutting edge technology.
 
Would a graphics driver be something MS could create and maintain themselves? Assuming all the software is suitably abstracted, why can't an XB1 title run on XBN through a completely different driver that maps DX12 to its DX13 GPU? While XBN titles run on the DX13 driver.
 
Thats what I was calling the bridge or shim layer. It translates calls from older APIs to the newer APIs. The largest difficulty would be emulating an older api that has state machines while the newer apis don't. That would entirely fall into the shim/bridge layer. In the past MS have done their own graphics drivers when they had CPU renderers in earlier DirectX apis.
 
I'm confused on this point. I thought the reason why Xbox didn't have compatibility issues was because they were packing everything together into the Virtual Machine for the game, so major SDK revisions wouldn't break older titles. And this is also a reason why the xbox is able to support so many different formats of backwards compatibility today.
It depends on what you mean by compatibility issues. Xbox 360 games are not 100% backwards compatible so Microsoft had a large software task to make them work on Xbox One. Xbox One X runs all Xbox One games because hardware work was done to enable this. Same for PS4 and PS4 Pro. It's also easier for the later cases because they were all GCN based. You're correct that newer version of SDKs don't break older titles. That benefit is what makes it difficult to support old hardware. I don't know how much of the details about the driver models are public so I'll have to err on not saying more.
 
Uhm, maybe you should look again, in particular the Xbox One consoles because what you're saying doesnt align with MS consoles since 2013. They still dont have as low of access on PS4 as they did in the past too. It doesnt seem like developers really have had as low level access since last gen with X360/PS3.
Xbox doesn't have stock DirectX. Microsoft publicly annouced sometime after launch that they added DX11.x fast semantics graphics driver, which requires custom resource management to reduce API overhead. This API is pretty low level. If you look at various GDC presentations, you also know that they exposed various GCN specific shader intrinsics. This Frostbite presentation describes some of these: https://frostbite-wp-prd.s3.amazonaws.com/wp-content/uploads/2016/03/29204330/GDC_2016_Compute.pdf. Console forwards compatibility is not as straightforward as PC.
 
Back
Top