Skrivet av mpat:
Här gör du det misstag som så många gör när de diskuterar spel - allt är inte shooters släppta igår. Det går alldeles utmärkt att spela Civilization på en gammal Intel-GPU. Det går utmärkt att spela indies, det går att spela konsollportar på Medium, det går utmärkt att spela gamla spel…eller det gick, tills Apple kapade den biten. Att man inte kan spela nya spel innebär inte att man inte kan spela alls. Man spelar det man kan.
Ingen ska förvänta sig att spel som Cyberpunk, Hogwarts Legacy eller Last of Us kommer fungera speciellt bra på instegsmodellen av iGPUer. Såg ett test av Hogwarts på 6900HX (680M) där man trots 1920x1080 (uppskalat från 640x360(!)) och "lowest" inte fixar mer än ~50 FPS (med 1 % lows på 5 FPS).
Nu använde Apple rätt ofta "Intel Iris Graphics", men även den är långt ifrån prestandan hos M1 (som i sin tur är det långsammaste idag, M2 är 30-40 % snabbare och M1Pro är 80-100 % snabbare).
Huvudproblemet med iGPU i spel är att det inte finns i närheten av tillräckligt med bandbredd mot RAM. Tiled based rendering löser halva den ekvationen då frame-buffer och Z-buffer hanteringen i praktiken sker i on-chip cache.
Men TBDR löser fortfarande inte bandbredden som också behövs för texturer. Det är orsaken att i de fall man trots allt lyckas köra på Intel/AMD iGPUer så är det typiskt med "lowest" för att minimera storleken på texturer. Apple "löser" detta på samma sätt som konsolerna: väldigt hög bandbredd mot "vanligt" RAM.
De senaste Intel baserade Mac:arna utan dGPU stödjer inte officiellt ett spel som Baldurs Gate 3, de som ändå testat verkar få runt 15-20 FPS i 720p "lowest". Stora vinsten med "Apple Silicon" är att man dels kan köra "medium" redan med M1 ("ultra" fungerar på M1 Pro och uppåt) i 1440p (TBDR verkar hantera hög upplösning mer effektiv, är hög geometrikomplexitet som är akilleshälen).
Civ VI är inte precis grafisk krävande, men inte heller det verkar gå speciellt väl på Intel GPUer då man ligger på ~20-25 FPS i lägsta möjliga inställningar. Med Apple Silicon är prestandan på en helt annan nivå, framförallt kan man realistiskt köra något bättre än 1280x720...
Det finns självklart ännu enklare spel som fungerar på Intel iGPU, men vill bestämt hävda att Intel baserade Mac:ar med endast iGPU är/var i praktiken helt irrelevanta för speltillverkarna. Även om "Apple Silicon" iGPUer inte är något RTX4090 är det stora skillnaden att även instegsmodellen fixar "rimliga" inställningar i aktuella spel som t.ex. Baldurs Gate (och även spel som Diablo 4 och liknande som folk testat m.h.a. Game Porting Toolkit).
Specifikt för strategispel så kan man köra dessa i vettiga upplösningar. Kör en del spel på M1, de är inte superkrävande men det riktigt trevliga är att spel på Apple Arcade är fullt rimliga att köra i 4k upplösning i 30-60 FPS beroende på komplexitet (vilket inte ens är att tänka på med Intel iGPU).
Skrivet av mpat:
1 är ju där man hamnar när man ger upp. Vad gäller 2 har jag väldigt svårt att tro på att man använder Mac App Store. Den kom efter Steam och har aldrig reor, och är därför dyr. Apple har flera gånger signalerat att Mac App Store går mycket sämre än vad de trodde. ”Rena” MacOS användare använder aldrig den, IME.
Vi kommer "aldrig" få statistik från Apple här, så allt är spekulation. Och är sant att MacOS App Store inte har i närheten omsättning som iOS har. Finns trots allt ~5k speltitlar där (de flesta är väldigt enkla). Men folk har fiskat ut att det bara publiceras ett par hundra titlar per år, publiceras fler appar per dag till iOS App Store.
Kan inte uttala mig om reor på spel, däremot händer det att "vanliga" applikationer finns på rea. Har köpt Pixelmator Pro på en "rea" (ungefär halva priset).
Skrivet av mpat:
Vad har det med saken att göra? Intel kapade ju inte det stödet i sina processorer. Nej, Apple kapade stödet för att de gör så - de vill inte ligga kvar och supporta något annat än sin senaste API. De rev ur gamla Rosetta när de inte hade list att supporta den, de slängde ut Classic när det blev jobbigt. Det har säkert funkat för dem i alla andra delar, men det har definitivt skadat dem vad gäller spelen nu senast. Tidigare övergångar har det funnits en drivkraft att byta eftersom prestandan blev lidande, men skillnaden mellan 32-bits and 64-bits Intel är mycket mindre, så ingen har brytt sig om nya spel var skrivna mot 32-bits APIn.
Det är en sak att "ha kvar stödet" och ett annat att säkerställa att stödet för legacy fortfarande är av vettig kvalité.
I praktiken är det mer jobb att underhålla 32-bit och 64-bit versioner av program på samma arkitekturer än det är att underhålla rena 64-bit versioner på två arkitekturer som x86_64 och ARM64 då ARM64 (likt RISC-V) explicit valt att ha samma endian och alignment-krav som x86_64 (just detta var annars, med bred marginal, största orsaken till buggar när x86/x86_64 kod portades till tidigare RISC:ar).
ABI för x86_64, ARM64 (och även RISC-V) har samma storlekar på alla primitiva C/C++. Att dessa har olika storlekar lär vara det efter endian/alignment som är nästa stora orsak till buggar om man stödjer flera arkitekturer.
Då iOS och MacOS sedan länge delar väldig mycket av kärnan och grundläggande bibliotek är det en signifikant kostnad associerad med att hålla något som en 32-bit x86 port levande så fort man släppte det på iOS-sidan. Om man bara låter det "finnas kvar" blir det snabbt ett säkerhetshål alt. potentiellt buggigt (kod som ändras men i praktiken aldrig testas kommer snabbt se bit-rot).
Just detta har noteras i Linux-världen där, trots att nästan allt är öppen källkod, visat sig att x86 koden börjar uppvisa en hel del bit-rot då "ingen" i praktiken använder den. Bl.a. har man hittat rätt rejäla grodor i kärnan som i vissa fall visat sig varit där över ett år (var Meltdown-fixar som i praktiken var "broken" på 32-bit x86 som hittades först 1,5 år senare!).
Arch har släppt stödet för 32-bit distros baserat på statistik, "ingen" använder det längre. Man har dock fortfarande kvar stöd för 32-bit userland på 64-bit OS, men som jag förstår det hela är stödet numera avstängt som förval.
Ubuntu droppade stödet först 32-bit userland helt från 19.04, men de backade delvis då de blev uppmärksammade på att det bl.a. helt dödade stödet för Steam på Linux. Är samma orsak här: statistik visar att nästan ingen använder 32-bit userland, det stöd man numera har är i praktiken vad som behövs för att köra Wine-funktioner samt Steam.
Valve är kanske stora nog att lägga resurser på att säkerställa att de 32-bit bibliotek som krävs testas tillräckligt mycket för att bibehålla stödet.
Men här ligger den stora stötte-stenen för "vettigt spelstöd" på Linux: det kommer aldrig bli bra så länge som enda realistiska sättet att köra spel på Linux via emuleringslager mot DX11/DX12 (i.e. propretära Windows APIer).
Tror Apple fattar att de måste säkerställa att inte detta händer på MacOS om det ska bli en vettig spelplattform. Man är ju väldigt tydligt med att poängen med Game Porting Kit är att se potentialen för ett spel på MacOS.
Game Porting Kit är i praktiken Proton för MacOS, d.v.s. man kör forfarande med DX11/DX12 APIet och Windows-binärer. Det man pushar är att när en spelutvecklare sett potentialen kan de avgöra om det är värt att göra en "riktig" port, d.v.s. använda Metal (Game Porting Kit har även verktyg för att underlätta översättning av shaders etc från HLSL till MSL).
Ska Linux bli relevant för spel måste man få till något liknande, det måste bli relevant att göra en Vulkan variant byggt som en Linux-native applikation (vilket idag är fullt möjligt i spelmotorer som Unity och Unreal Engine).