Depends on the level of hardware access. If the GPU access is through a relatively "thick" API like DX/Vulkan and shaders stored in an intermediate representat

Depends on the level of hardware access. If the GPU access is through a relatively "thick" API like DX/Vulkan and shaders stored in an intermediate representation like DXIL or SPIR-V, sure, swapping out the hardware implementation is relatively easy. But if they're shipping GPU ISA binaries as the shaders, you'll have a much harder time ensuring compatibility. Same with things like synchronization, on both the CPU and GPU (and any other offload devices like DSPs or future NPUs). If they use API-provided mechanisms, and those are used /correctly/, then the implementation can likely be changed. But if they cycle-count and rely on specific device timing, again all bets are off. Things like DX12 and Vulkan have a large number of sync points and state transition metadata to allow different implementations to be "correct" in things like cache or format conversions (like compression). Not all those transitions are required for every vendor's hardware, and we regularly see issues caused by apps not "correctly" using them when the spec says it's required, as the vendor's hardware they happened to test on didn't require that one specific transition that another implementation might, or they happened across some timing that didn't happen to hit issues. I guess my point is Compatibility is hard even if the APIs are intentionally designed to allow it. I have no idea how much the idea of such compatibility has been baked into console APIs in the first place. One of the primary advantages of consoles is to allow simplifications allowed by targeting limited hardware, so I can only assume they're less compatibility focused than the PC APIs we already have Big Problems with.