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

Permalänk
Melding Plague

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

I en stor Microsoft-läcka framgår att bolaget velar mellan två helt olika plattformar för nästa generations spelkonsoler.

Läs hela artikeln här

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk

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.

Permalänk
Medlem

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.

Permalänk
Medlem
Skrivet av Rödskägg d ä:

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.

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

Permalänk
Medlem

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

Visa signatur

42? Seven and a half million years and all you can come up with is 42?!
► FD Define R2 | Win10Pro | i7-3770K | Hyper212+ SP120PWM | P8P67 PRO | CML8GX3M2A1600C9 | 1080 Ti | AX750 | Asus VG27WQ | Eizo S2100 |► Raspberry Pi 3B | Osmc |► OnePlus 6 |

Permalänk
Medlem

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?

Permalänk
Medlem
Skrivet av alpha:

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.

Skrivet av doomas:

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

Det är skillnad mellan silikon pattar och kisel pattar!

Visa signatur

Laptop: Ja
Mobil: Ja
Internet: Ja

Permalänk
Medlem

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.

Visa signatur

🛜🫀: HP ProDesk 400 G3, i5 6500, 8GB DDR4, Intel X520-DA2
🐳🐧: AMD R5 3600 | Google Coral.ai | ASRock X570D4U-2L2T | Silverstone CS381 | 80GB DDR4 | 8 HDD BTRFS RAID1
⌨️🎮: R9 3900X | RTX 2080 LC | Acer XF270HUA | 96GB @ 3200 | Prime B350-plus | Carbide 270R
🎞🎶: LG OLED55C8 | Epson TW3200 | Onkyo TX-NR646 | Infinity Reference 61/51 mk2 | Shield TV V2 | minhembio.com

Permalänk

Antar att Microsoft med assistans av AMD kommer utveckla bättre stöd för raytracing i DirectX. Då det är trist att AMD meddelat att RDNA4 inte kommer konkurrera i toppsegmentet om detta skulle vara det lyftet AMD behöver på just den kategorin.

Visa signatur

Spelburk: R7 5700X | RX 580 | 32GB RAM | MSI B350M PRO-VDH

Permalänk
Skrivet av doomas:

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

*faceslap* såklart!

Permalänk
Medlem

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.

Visa signatur

How do 'Do Not Walk on the Grass' signs get there ?

Permalänk
Medlem
Skrivet av Dyluck:

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.

Ser det dock inte lite svårt ut att få upp frekvensen på arm?
x86 lär nog hänga kvar ett tag till innan dom slagit i taket för vad som går att pressa ur arkitekturen.

Permalänk
Medlem

AMD hade ju ARM på gång samtidigt som Zen, hoppas de återupplivat det projektet

Permalänk
Medlem
Skrivet av Dyluck:

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.

Vad jag vet så har ARM problem att slå JUST NU x86 i single thread prestanda för att ARM inte kan få upp frekvensen. Så x86 har bättre IPS än vad har, även om ARM har högre IPC.

Vet inte om dessa benchmarket är bra, men:

Passmark
https://www.cpubenchmark.net/singleThread.html

Cinebench

Geekbench

Citat:

The 24-core i9-13900KS is even faster, with a 42% and 35% lead in the single and multi-threaded benchmarks, respectively. Remember that the x86 CPUs ran with the XMP 3.0 memory profile, as Geekbench is quite memory-bound.

https://www.hardwaretimes.com/apples-m2-ultra-is-slower-than-...

Visa signatur

Hur många datorer är för många?

Permalänk
Datavetare
Skrivet av Dyluck:

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

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....
Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

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 8 instruktioner per cykel (AMD 5 st och Intel 6 st, det vara 4 st för båda bara för en generation sedan).

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.

För mobiler, bärbara och servrar vill man primärt optimera för prestanda/watt, så fattar det finns en sweet spot man vill hålla sig inom.
Vad är det som gör att ARM inte klockar högre än 3.5? Om ARM kör samma processnode som Zen4, imo så borde x86-64 vara betydligt svårare att få upp i hastighet då chipet är större och har stor instruktionsavkodare.

Visa signatur

How do 'Do Not Walk on the Grass' signs get there ?

Permalänk
Datavetare
Skrivet av Dyluck:

För mobiler, bärbara och servrar vill man primärt optimera för prestanda/watt, så fattar det finns en sweet spot man vill hålla sig inom.
Vad är det som gör att ARM inte klockar högre än 3.5? Om ARM kör samma processnode som Zen4, imo så borde x86-64 vara betydligt svårare att få upp i hastighet då chipet är större och har stor instruktionsavkodare.

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).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

Blir de arm så försvinner väl bakåtkompatibiliteten? Eller tänker jag helt galet då?

Visa signatur

Tjo & tjim
Nzxt H7 Flow || ASUS ROG Strix B650E-F Gaming WIFI || Gigabyte GeForce RTX 4080 16GB Gaming OC || AMD Ryzen 7 7800X3D || Corsair 32GB DDR5 5200MHz CL40 Vengeance RGB AMD EXPO || NZXT Kraken Elite RGB 360 || Samsung 990 PRO M.2 NVMe SSD 1TB & 2TB || ASUS ROG Strix Aura 850W

Permalänk
Datavetare

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).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av mrkhaglund:

Blir de arm så försvinner väl bakåtkompatibiliteten? Eller tänker jag helt galet då?

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

Permalänk
Medlem
Skrivet av medbor:

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

Så sant 👍🏼👍🏼

Visa signatur

Tjo & tjim
Nzxt H7 Flow || ASUS ROG Strix B650E-F Gaming WIFI || Gigabyte GeForce RTX 4080 16GB Gaming OC || AMD Ryzen 7 7800X3D || Corsair 32GB DDR5 5200MHz CL40 Vengeance RGB AMD EXPO || NZXT Kraken Elite RGB 360 || Samsung 990 PRO M.2 NVMe SSD 1TB & 2TB || ASUS ROG Strix Aura 850W

Permalänk
Skrivet av Rödskägg d ä:

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.

Bättre att dom fokuserar på 1440p-4k i 60fps, RT är knappast relevant för konsoler

Permalänk
Medlem
Skrivet av Makkangbg:

Bättre att dom fokuserar på 1440p-4k i 60fps, RT är knappast relevant för konsoler

Insomniac games säger annat:
https://www.eurogamer.net/ray-tracing-the-standard-baseline-a...
Sen får vi se hur snyggt det blir i 60fps performance läget såklart.

Permalänk
Medlem
Skrivet av Makkangbg:

Bättre att dom fokuserar på 1440p-4k i 60fps, RT är knappast relevant för konsoler

För next-gen [exklusiva spel] skulle jag snarare säga att RT blir en självklarhet.

Permalänk
Medlem
Skrivet av RashLeaf:

Insomniac games säger annat:
https://www.eurogamer.net/ray-tracing-the-standard-baseline-a...
Sen får vi se hur snyggt det blir i 60fps performance läget såklart.

Jo men de är inte den genomsnittliga utvecklaren direkt. Insomniac är ett under i effektivitet.

Blir intressant att se vad de hittar på till PS5 Pro.

Permalänk
Medlem
Skrivet av Makkangbg:

Bättre att dom fokuserar på 1440p-4k i 60fps, RT är knappast relevant för konsoler

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.

Visa signatur

Processor: Motorola 68000 | Klockfrekvens: 7,09 Mhz (PAL) | Minne: 256 kB ROM / 512 kB RAM | Bussbredd: 24 bit | Joystick: Tac2 | Operativsystem: Amiga OS 1.3