Microsoft sneglar på ARM och AMD för nästa Xbox

Hårdvaruaccelaration för ray tracing och uppskalad upplösning med maskininlärning borde vara ett vinnande koncept för konsoler. Precis som Nvidias nuvarande grafikkort. Fast med konsolen så vet du alltid vad du har för hårdvara när du utvecklar spelet, så all silikon kan utnyttjas till fullo.

Eller så försöker Microsoft inte göra en hemlighet av att de funderar på två olika alternativ - i syfte att kunna pressa AMD till att leverera ett kanonerbjudande.

Det är väl inte så mycket silikon i en konsol

Kanske vi får se mer ARM till Windows även...

Så nästa generation Xbox kommer vara en tingest som påminner om Steam link som kopplar upp dig mot ditt Win11 konto hos Microsoft och streamar allt därifrån för runt 20$ i månaden?

Eller avslöjade jag just Microsofts planer?

Det är skillnad mellan silikon pattar och kisel pattar!

Kan ju också vara så att de överväger ARM för en tunn klient så.. XBOX S-varianten nästa generation streamar från molnet medan premium-varianten kan göra båda delar.

Det börjar bli svårt att försvara x86 nu när arm kräver 1/3 av kislet och har en IPC som är 50% högre.
Det kluriga är att få till bakåtkompatibilitet med ny arch, speciellt spel har en tendens att göra många mystiska hack som att emitta egen exekverbar kod.

I Windows är det utan tvivel ett problem, men är övertygad att det är långt mindre än de flesta kanske tror.
I Linux och MacOS går det utmärkt att köra med ARM64 t.ex. på serversidan. De problem vi historiskt sett har man undvikt både på ARM64 och även RISC-V genom att vara "x86_64" kompatibel på punkter som endian och alignmentkrav.

Dessa två var de överlägset vanligaste problemen när man tidigare portade till RISC, detta då de flesta tidigare RISC:ar körde annan endian och hade betydligt hårdare krav på "vettig" alignment än x86. Gjorde man fel här fick man effekter som beräkningar som gick fel eller (i bästa fall) krascher.

I spelkonsol har jag väldigt svårt att se hur det överhuvudtaget skulle vara ett problem att köra ARM64 i stället för x86_64, "ingen" skriver assembler idag och bara de som vill ha kass prestanda skulle köra självmodiferade kod på en modern CPU!

Ser bara fördelar med att köra ARM64 över x86_64 i en konsol.

1. En konsol har inte strömbudget för att realistiskt kunna köra en CPU, oavsett ISA, i >5 GHz eller ens >4 GHz. Även om AMDs CPUer idag är snabbare än Arms bästa är det enbart p.g.a. att Arm Cortex X3 inte går att klocka över ~3,5 GHz. Perf/MHz är dock redan nu högre hos Cortex X3 jämfört med Zen4/Raptor Cove.

2. Ovanpå det tenderar spel ha rätt kass "IPC". Har gjorts en del analyser om varför, det som skiljer spel mot mycket annat är att moderna spel tendera ha väldigt mycket kod (så relativt låg L1I$ hit-rate) och relativt stort "working-set" (så även relativt låg data-cache hit-rate) jämför med mycket annat. Det ger också mer TLB-cache misses.

ARM64 har fördelar i flera dimensioner här!

Dels kan ARM använda 16 kB och 64 kB "page-size", utöver den 4 kB som också stöds och som x86_64 använder (och som är det enda "vanliga" Windows i nuläget stödjer). Större page-size ger färre TLB-cache missar och bättre utnyttjande av den TLB-cache som faktiskt finns. (MacOS kör med 16 kB page size med "Apple Silicon", Linux har stöd för alla 3 storlekar men de flesta distros kör ändå 4 kB för bäst kompat med x86_64).

Då ARM64 tenderar ha bättre perf/MHz är det vettigt att designa för lägre maxfrekvens. Med lägre maxfrekvens blir det tekniskt rimligt att ha större cache-storlek. Apple kör ju med 128 kB L1I$, mot 32 kB för Intel/AMD. Arm Cortex X3 har 64 kB L1$ och 64 kB L1D$ (AMD har 32 kB L1D$ och Intel har precis ökat till 48 kB L1D$).

Slutligen är det trivialt att avkoda ARM64 jämfört med x86_64. Moderna x86_64 förlitar sig på massa tricks som "micro-op cache" och liknande, vilket fungerar bra i program med relativt litet kodsegment och hög grad av lokalitet. D.v.s. inte spel! High-end ARM64 CPUer har väsentligt högre avkodningshastighet, Apple kan ta minst (senaste "deep-dive" är den AnandTech gjorde för M1) 8 instruktioner per cykel (AMD 4 st och Intel 6 st).

3. Konsoler är systemkretsar, dessa kan inte göras hur stora som helst om de ska ha vettigt pris. Då ARM64 tar mindre plats (och mindre effekt) för motsvarande prestanda som x86_64 blir det mer plats (och effekt) som istället kan läggas på t.ex. GPU!

Så hoppas verkligen nästa Xbox kör ARM64, gör inte Sony det kommer Microsoft ha en teknisk edge. GPU-mässigt fungerar det ju hur bra som helst med AMD, är i praktiken bara AMD och Nvidia som har lämplig teknik och Nvidia verkar vara "sådär" intresserade av den här marknaden.

Edit: angående "decode width", kommande Cortex X4 drar tydligen till med 10 instruktioner per cykel, upp från 6 st i Cortex X3

Visa innehåll

Zen4

Golden/Raptor Cove

Cortex X4, notera att AGU/LD/ST inte är med här

Apple M1

Diagram på front/backend, x86_64 börjar se lite 'smala' ut mot high-end ARM64....

Endast designval i mikroarkitektur, skulle vara fullt möjligt att designa en ARM64 som likt Zen6 / Raptor Lake klockar ~6 GHz.

Finns flera anledningar varför det inte är en jätte-interesant väg, men den viktigaste är att ju högre man klockar ju mindre (relativt sett) kommer fördelen i perf/W bli för ARM64 jämfört med x86_64 hög frekvens kommer leda till hög effekt oavsett ISA.

Den stora fördelen med ARM64 (och i teorin RISC-V, men ska upp till bevis i praktiken också) är att dessa två är de första ISA som designats mot bakgrund av: all programvara går idag genom en kompilator, låt oss designa en ISA som gör det så enkelt som möjligt att skriva effektiva kompilatorer.

32-bit Arm må vara kompakt, men den är faktiskt horribel om man vill bygga en mikroarkitektur med väldigt hög "IPC". Även här tänkte Arm till med ARM64 (som är en helt annan ISA än 32-bit Arm, det är inte bara en utökning som x86_64 är av x86), man har explicit designat en ISA där det är enkelt att få till rejält med "instruction level parallellism".

Vare sig Intel eller AMD har brytt sig om att bredda deras "back-ends" speciellt mycket på slutet, det är helt enkelt inte en relevant flaskhals i de flesta fall. Både Cortex X och framförallt "Apple Silicon" har "bredare" back-ends, och uppenbarligen kan de dra nytta av dessa (Arm började bredda rejält först när de droppade stödet för 32-bit Arm...).

Intel är medveten om detta, vissa av de saker man lagt in i ARM64 ISA är saker Intel "kopierat" i deras kommande APX. Men finns en rad saker man inte kan ändra utan att bryta bakåtkompatibilitet, så man kommer alltid ligga efter (givet en viss transistorbudget).

GB6 ST resultatet för 13900KS är det något galet med, rätt märkligt att man inte fångat det i artikeln.
Ett rimligt resultat ligger på 3100-3200 poäng.

Sen är finns det flera dimensioner kring denna jämförelse. Just CB23 är något x86_64 bör stå sig väldigt bra mot ARM64 då det är AVX2/AVX-512 optimerat av Intel (via deras Embree ramverk). SIMD optimeringarna kommer sedan från ett väldigt cool projekt från Intel som heter ISPC.

Att ISPC ens har Arm NEON stöd är en speciell historia. Den personen som startade ISPC jobbade tidigare på Intel, efter han slutat jobbade han på något ARM64 projekt och insåg att det vore rätt trivialt att lägga in NEON stöd i ISPC. Sagt och gjort, han pushade in det (Intel hade missat att ta bort hans commit-rights till ISPC...).

Var tydligen rätt många turer internt hos Intel, men valde till slut att lämna kvar Arm NEON stödet (men man drog in personens commit-rights...). Det fungerar helt OK, men är inte alls lika optimerat som för x86!

Rent generellt presterar x86 relativt sett bättre i saker som kan utnyttja SIMD jämfört med saker som inte kan det ställt mot ARM64. Framåt kan det eventuellt ändras då Arm gjort en ny SIMD teknik (NEON kan bäst jämföras mot AVX med 128-bitars bredd, AVX stödjer 256 bitar på x86) som kallas SVE. Cortex X2 och framåt har det, Apple har ännu inte fått det i M2 (får se om M3 har stödet).

Vidare är saker som Cinebench något som M1/M2 gör långt mer effektivt via deras iGPU än deras CPU. Redan en iGPU M1Pro är ju långt snabbare än 13900K/7950X om man testar senaste Cinebench (som på MacOS stödjer Metal Compute). En iGPU har ju inte de begränsningar en dGPU har i form av begränsad mängd RAM, så där finns ingen anledning att någonsin använda CPU om det finns stöd för iGPU i rendering.

Tittar man sedan på deltesterna i GB6 ser man att det är rätt stor varians i relativ prestanda mellan M2 och i9-13900KS, ingen är konsekvent snabbare. T.ex. är M2 rätt mycket snabbare i kompilering (som likt spel tenderar vara väldigt "elak" mot CPUn och därför leda till låg "IPC", framförallt i högt klockade CPUer med lång pipeline -> högre "straff" vid felspekulering).

Att en CPU klockad ~60 % av Intel/AMD i vissa fall är snabbare känns som det borde vara omöjligt. Men det finns ett par sådana fall, de är typiskt "elaka" mot cache och består primärt heltals beräkningar (kompilering, visa typer av sökningar, vissa typer av beräkningar med stora data set etc).

Inte nödvändigtvis, kolla hur väl Rosetta 2 fungerade för Apple

Det handlar inte så mycket om vad som är "snyggt" utan mer om att får ner personalkostnader. Vid RT så kan du skippa många jobbiga moment vid utvecklingen. Kräver lite omskolning av de som designar banor, men när det är klart så gör de jobbet mycket snabbare/färre personer behövs.

Detta för att ljuset kommer "gratis" vid RT. Behöver inte jobba med texturer som ska fejka reflektioner, baka ljuskartor, placera ut osynliga ljuskällor etc etc. Listan är lång på moment som kan hoppas över.

Och finns det pengar att tjäna så är det dit branschen kommer gå. Förr eller senare.