Switch 2 kör Switch-spel ”halvemulerat”

Permalänk
Skrivet av Yoshman:

Du verkar hitta svårigheter precis överallt, även där de inte borde finnas!

Har du testat nes och snes emulatorer för i tiden? Det var runt pentium 100 man behövde för att få flyt, man kan argumentera på olika sätt att en 386a borde kunna köra nes spel fint, men det gick i praktiken segt. Detsamma har det varit med de emiulatorer jag har testat, det borde flyta på, men i praktiken av olika anledningar som har det krävt rejält mycket bättre prestanda för att det ska flyta på lika bra.

Skrivet av Yoshman:

Den M4 du nämner kör, i genomsnitt, x86_64 program snabbare än någon annan mobil/laptop CPU med TDP under 50 W (vilket på så många sätt är "bonkers")

Verkligheten Windows x86/x64 gåt segt som bara tusan på en Apple M4. Man kan argumentera för att det borde flyta på, men det går ändå segt. Windows Arm är inte Windows x86 och den flyter men ha dåligt programstöd.

Permalänk

För mig blir det helt fast på SteamDeck. Bojkotta Sh*tendo! 🤘🤘!

Permalänk
Datavetare
Skrivet av lillaankan_i_dammen:

Har du testat nes och snes emulatorer för i tiden? Det var runt pentium 100 man behövde för att få flyt, man kan argumentera på olika sätt att en 386a borde kunna köra nes spel fint, men det gick i praktiken segt. Detsamma har det varit med de emiulatorer jag har testat, det borde flyta på, men i praktiken av olika anledningar som har det krävt rejält mycket bättre prestanda för att det ska flyta på lika bra.

Som sagt, teknikutvecklingen på CPU-emulering har gått otroligt mycket framåt senaste tiden.

Sen om man ska göra en konsolemulator kvarstår potentiellt problematik kring att hantera andra kretsar, som t.ex. GPU. Men givet att alla dagens konsoler använder GPUer från AMD och Nvidia så är även det rätt mycket ett icke-problem.

Skrivet av lillaankan_i_dammen:

Verkligheten Windows x86/x64 gåt segt som bara tusan på en Apple M4. Man kan argumentera för att det borde flyta på, men det går ändå segt. Windows Arm är inte Windows x86 och den flyter men har kass programstöd.

Ah, så du har lyckats hitta det use-case "ingen bryr sig om". I det läget är det inte konstigt att det går långsamt, Rosetta 2 och Prims har båda fokuserat på att emulering av applikationer, d.v.s. sådant som kör i "user-space". De fungerar inte ihop med sådant som körs i kernel-space.

Har inte använt FEX-Emu, men beskrivningen man gör är "som QEMU-user" vilket då betyder att man har samma begränsning som de andra.

Teoretiskt går även det fallet att hantera med samma grundläggande teknik, men det är ett use-case som är så smalt så tvivlar att någon kommer lägga speciellt mycket jobb bakom.

Vad man i praktiken gör är mer likt den "emulering" Nintendo gör med Switch 2 (och även Sony gör med Playstation 5), "kernel-delarna" översätts inte alls utan man har istället ett lager i "user-space" som översätter Switch 1 anrop till motsvarande Switch 2 (och PS4 spels anrop blir översatta till motsvarande PS5 anrop i Playstation).

I.e. vill man köra x86_64 Windows-applikationer effektivt på ARM64 kör man ARM64 versionen av Windows (eller en ARM64/Linux med Wine+FEX). Kort och gott: det löser inte drivrutiner, de måste vara "native", men emulering av applikationer är idag ett "löst problem".

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 pacc:

Begränsad lagring och att allt laddas ner är största nackdelen med switch 2.

Lite som med Xbox Series,
Alla one-spel fungerar och du kan bara flytta över din gamla externa HD och spela,
men ett efter ett "uppdateras" och blir plötsligt series-kompatibelt vilket kräver att det installeras på den redan fulla intera ssdn.

Med koder måste du ju ladda ner spelet istället för att ha det på cartridge, kanske ändå ett problem för online och gaas spel, Nintendos styrka är ändå solida offline spel. Men tar du sedan ett annat AAA spel har de väl aldrig klarat av att leverera buggfritt utan förstadagsnedladdningar och de verkar nu kunna välja att leverera billigare cartridge som inte ens rymmer hela spelen eller bara koder.

Det värsta som de kan göra nu är att alla Switch spel uppgraderas och man istället för att spela dessa från cartridge laddar ner en helt ny version, det som hände på Xbox series.

Fast lagringen verkar inte bli ett lika stort problem denna gång åtminstone. Om hela CP2077 inkl expansion går in på 60G så måste rimligen allt annat som kommer var relevant för Switch2 också göra det. På nuvarande Switchen så fanns det snart spel som knappt gick in på en i övrigt helt tom lagring.

Ja upplägget med Daft Delivery och i praktiken ingen överförelse av fysiska spel har lustigt nog blivit väldigt likt XB One och Series. Men som sagt, lite oklart (lite ledordet för den här introduktionen) i vilken omfattning och hur länge detta kommer gälla.

Skrivet av Yoshman:

Fast är det någon som egentligen inte begriper varför Nintendo m.fl. inte gillar emulatorer.

För varje person som faktiskt köper de spel de kör i sin emulator finns 100 som använder det för piratkopiering. Att försöka stödja en marknad med <=1% andel är väldigt sällan ekonomiskt vettigt, det fungerar bara om man kan ta extrema marginaler.

Det handlar nog egentligen mer om att inte devalvera det mer abstrakta värdet av IP och därigenom plattformen än de faktiska förlusterna till piratmarknaden på andra platformar.

Särskilt som även Nintendo nu verkar mer intresserade att använde dem som utfyllnad eller mervärde för tjänster än att sälja individuella spel.

Visa signatur

Operativsystemet som löser nästan alla problem: Mint

Permalänk
Medlem
Skrivet av Yoshman:

Har inte använt FEX-Emu, men beskrivningen man gör är "som QEMU-user" vilket då betyder att man har samma begränsning som de andra.

FEX (och Box86/Box64) använder bara JIT för ISA där det verkligen behövs, biblioteksanrop länkas om till bibliotek kompilerade för den underliggande arkitekturen.

Ta till exempel ett enkelt x86-spel på ARMv8; anrop till SDL, ALSA, glibc, etc. går till ARMv8-versioner av biblioteken medan x86-opcodes översätts till ARMv8-opcodes (om jag inte minns fel appliceras även viss grad av mönsterigenkänning i ett av projekten). Eftersom det inte finns perfekta översättningar av alla opcodes så tappar man naturligtvis prestanda när de behöver emuleras och hur mycket beror på hur mycket av x86-beteendet man kan tumma på, men som det ser ut redan nu är både FEX och Box86/Box64 betydligt snabbare än QEMU-user.

Helt enkelt snabbare emulering genom att bara emulera vad som faktiskt behöver emuleras, när det går att kompilera om bibliotek med öppen källkod på traditionellt vis.

Visa signatur

Mjölnir: Ryzen 9 3900X | X570-I | Ballistix Sport 32GB | Powercolor RX 5500XT 4GB ITX | Kolink Sattelite
Server: Ryzen 5 1400 | X470-F | Ballistix Sport 24GB | ASUS HD 7790 2GB | Sapphire RX 470 8GB ME | NZXT Switch 810

Permalänk
Medlem
Skrivet av Yoshman:

Läser man intervju och tittar på vad verkar gå fel ser det primärt ut att handla om timing-relaterade problem.

Det lär i sin tur ha sina rötter i att det finns race-condition buggar och andra timing-relaterade tanke-vurpor i koden som bara "råkar fungera" när man kör på Switch, men som på Switch 2 får helt annat timing som då triggar buggarna. Även PS5 och XSX har ju haft den här typen av problem med att köra spel från föregående generation.

Gissar att väldigt nära 100 % av de spel som har problem i uppstarten lider av just detta.

Inte helt oväntat att Switch 2 skulle få dessa problem när GPU-delen verkar vara "upp till x10" snabbare och CPU-delen lär vara i alla fall 3x snabbare (i genomsnitt). D.v.s. potentiellt väldigt annorlunda timing i de fall det bara "råkade bli rätt" p.g.a. att Switch HW hastighet råkade diktera timing.

Denna typ av problem kan hanteras på lite olika sätt. Bästa sättet är att rätta buggen/buggarna. Men går ju också att göra en "emuleringslager" var mål är att minska prestanda så att timing matchar originalet "tillräckligt bra". Fördelen är att det går att göra utan tillgång till källkod, nackdelen är att det måste göras specifikt för varje fall (en del av jobbet att få emulatorer att fungera är denna typ av jobb).

Sen fanns ju en del spel som använde fysiska funktioner som inte finns på Switch 2. De lär ju aldrig fixas, om man nu inte på något sätt även emulerar dessa fysiska funktioner på något sätt.

Du verkar hitta svårigheter precis överallt, även där de inte borde finnas!

Vet inte vad du försökt emulerat, den teknik som i stort sätt alla använder idag för att översätta mellan ISA har en akilleshäl. Det tar väsentligt längre tid att starta programmet då det händer en del rätt dyra beräkningar när man översätter mellan ISA.

Så program som körs i stora antal under relativt begränsad tid, typexempel kompilator, fungerar illa med tekniken Rosetta 2, Prism och FEX-Emu använder. Det fungerar däremot utmärkt med just spel då de typiskt kör relativt länge.

Och för program som kör "relativt länge" har vi idag prestanda som bara för 10 år sedan kändes otänkbart. Den M4 du nämner kör, i genomsnitt, x86_64 program snabbare än någon annan mobil/laptop CPU med TDP under 50 W (vilket på så många sätt är "bonkers"). Så vad pratar vi om, kanske 500-1000 gånger snabbare än en 486DX2@66MHz?

Fast är det någon som egentligen inte begriper varför Nintendo m.fl. inte gillar emulatorer.

För varje person som faktiskt köper de spel de kör i sin emulator finns 100 som använder det för piratkopiering. Att försöka stödja en marknad med <=1% andel är väldigt sällan ekonomiskt vettigt, det fungerar bara om man kan ta extrema marginaler.

Dom för väl stoppa in fem NOP mellan varje instruktion och multiplicera alla adresser med lika mycket

Visa signatur

- 5090