[dragontamer]

PS5 is an x86 CPU + AMD RDNA GPU.

PS4 was an x86 CPU + AMD GCN GPU.

A huge amount of games will be portable from the get-go. GCN and RDNA have extremely similar assembly languages.

The only major assembly language change from GCN -> RDNA is DPP / cross-lane operations (kinda like pshufb from x86). But I'm not even sure if the PS4 had those instructions.

[monocasa]

It's deeper than that, the shaders are _binary_ compatible.

> The only major assembly language change from GCN -> RDNA is DPP / cross-lane operations (kinda like pshufb from x86). But I'm not even sure if the PS4 had those instructions.

Yeah, it didn't. AFAIK, they were added in GCN 3, while the PS4 is GCN 1.1.

[dragontamer]

> It's deeper than that, the shaders are _binary_ compatible.

I'd be surprised if this fact was true.

GCN 1.0 and GCN 1.2 aren't even binary compatible. Opcode 0x1 is "ReadLane" in GCN 1.0, but is "Add F32" in GCN 1.2.

https://github.com/CLRX/CLRX-mirror/wiki/GcnInstrsVop2

Vop2 are the "2-source / 1-destination" instruction format. You can see from the table that GCN 1.0 and GCN 1.2 don't even line up at all.

It wouldn't be hard to compile GCN 1.0 into GCN 1.2 instructions, but it wouldn't be binary-compatible, just assembly-language compatible (like 8080 -> 8086).

--------

Some other facts:

* RDNA is Wave32 native. Wave64 compatibility is available though, so that should mostly work for backwards compatibility (aside from DPP, which you do point out may not exist in PS4)

* S_WAITCNT ("wait for memory" instruction) has grossly changed in RDNA. In GCN, waiting for VM_CNT(0) will wait on loads and stores. But VM_CNT(0) only waits for loads on RDNA.

You need to change every S_WAITCNT VM_CNT(0) (GCN) into S_WAITCNT VM_CNT(0), followed by a new S_WAITCNT_VSCNT 0 instruction (wait for 0 outstanding loads, THEN wait for 0 outstanding stores).

This isn't "binary compatible", but if you just inserted one instruction on every GCN S_WAITCNT, you'd get the proper behavior in RDNA.

-----

I'm seeing GCN -> RDNA as a "mostly easy compile" between the assembly languages. But it doesn't seem binary compatible to me. I wouldn't be surprised if there were one or two issues that popped up however.

[NikolaeVarius]

That isn't the original point. The PS4 is not natively backward compatible, the base game needs to be ported.

Native BC would be

1. It runs native hardware (PS2 EE on Early PS3) 2. It runs without updates required (PS2 running inside emulator on later PS3)

This requires actual updates by the dev for individual games to work

[monocasa]

Or it's _really_ close, but the systems are complex enough that they feel they need to QA/cert the games again even if the vast majority of games require no changes.

[chungus_khan]

Do shaders on PS4 games ship precompiled? If so, they'll at least need to either recompile those or create some sort of translator (which certainly isn't impossible). Either way, I'm sure even in an ideal situation, Sony wouldn't want to make outlandishly absolute claims like "perfect backwards-compatibility".