Qualcomm on tuomassa kesän aikana myyntiin uuden Snapdragon X Elite -järjestelmäpiiriin Windows-kannettaviin. Järjestelmäpiirissä on pääosassa viime vuosien Cortex-ydinten sijasta uudet yhtiön omat Oryon-ytimet.
Qualcomm on pitänyt GDC 2024 -messuilla ”Windows on Snapdragon, a Platform Ready for your PC Games” -esityksen, jossa on käyty läpi tulevaa alustaa pelinkehittäjien näkökulmasta. Samalla se antoi katsauksen myös kuluttajille siitä, mitä AMD:n ja Intelin prosessoreihin tottuneet PC-pelaajat voivat odottaa yhtiön Arm-uutuudelta.
Uusi Snapdragon X Elite tulee pyörittämään yhtiön pelipuolen johtavan insinöörin Issam Khalilin mukaan x86(-64)-prosessoreille suunniteltuja pelejä lähes täydellä nopeudella huolimatta emuloinnista. Khalilin mukaan pelien pitäisi oletuksena toimia suoraan sellaisenaan niin kauan, kuin ne eivät käytä kernelitason ajureita, kuten huijauksenestotekniikat. Emulointi tukee x86-64:n laajennoksia SSE4-tasoon asti ja yhtiön mukaan erilaisten skriptien kanssa on syytä olla varuillaan. Yhtiön mukaan välimuistien hyödyntäminen koodin ensimmäisen kääntämisen jälkeen tekee emuloinnista erittäin tehokasta ja GPU-puoli ei välitä tuon taivaallista emuloidaanko jotain vai ei.
Täysin emuloinnin varassa Qualcommin uutuusjärjestelmäpiiri ei tule kuitenkaan olemaan. Yhtiön mukaan kehittäjillä on kolme tapaa tukea Snapdragon X Eliteä: pelin kääntäminen natiiviksi ARM64-koodiksi, pelin kääntäminen lähes natiivin nopeuden tarjoavaksi ARM64EC-koodiksi, tai olla tekemättä yhtään mitään, jolloin pelin pitäisi toimia edellisen kappaleen rajoitteet huomioiden. ARM64EC-tapauksessa Windows kirjastoineen sekä Qualcommin ajurit pyörivät natiivisti Armilla ja loput emuloidaan, minkä pitäisi yhtiön mukaan tuottaa lähes natiivia vastaava nopeus. Myös ARM64EC:n tapauksessa kernelitason kikkailut ovat pannassa.
Integroitun Adreno-näytönohjaimen suorituskyvyn osalta ennakkotiedot povaavat suurin piirtein AMD:n integroidun Radeon 780M:n tasoa, mutta luonnollisesti vasta kolmansien osapuolten varmistetut testit tulevat kertomaan koko totuuden. Qualcommilta löytyy ajurit DirectX 11 ja 12- sekä Vulkan- ja OpenCL-rajapinnoille, joiden lisäksi DirectX 9:iä ja OpenGL:ää versioon 4.6 asti tuetaan käännöskerrosten kautta. Yhtiön tuotehallinnon johtoon kuuluvan Micah Knappin mukaan hän on nähnyt Arm-prosessorin, viitaten oletettavasti Snapdragon X Eliteen, pyörittävän pelejä vastaavaa x86-prosessoria nopeammin tai pienemmällä tehonkulutuksella, mutta ei kertaakaan sekä että.
Lähde: The Verge
Nyt kun otin selvää mikä tuo ARM64EC on niin olisin ehkä onnellisempi jos en olisi siitä koskaan kuullutkaan.
Se on vaan vaihtoehtoinen ABI (tapa miten kääntäjä sijoittelee funktiokutsujen parametrit yms.) joka tekee helpommaksi funktiokutsut natiivin ARM64-koodin ja x86-64-koodin välillä. Että esim. x86lle alun perin käännettyä peliä peliä binäärikäännöksellä ajaessa se voi esim. ladata jonkun ARMille natiivisti käännetyn DLL:n ja kutsua sen natiivia ARM-koodia, mikäli se ARM-natiivikoodi on käännetty ARM64EC-ABI:lle.
Eli hyöty tuosta ARM64EC:stä on se, että ilman sitä kaikki sen pelin omassa prosessissaan suorittama koodi pitäisi ajaa binäärikäännettynä x86-koodina, mutta ARM64EC:n kanssa esim pelin lataamien directX:n DLL:ien yms sisältämä koodi voidaan ajaa natiivina ARM-koodina.
Mutta verrattuna normaaliin ARM64n ABI:iin, se ARM64EC tekee myös siitä natiivista ARM64-koodista hiukan hitaampaa koska poistaa käytöstä muutaman rekisterin ja vaatii funktiokutsuihin muutenkin hiukan overheadia.
Ja sille itse binäärikäännetyn koodin suurimmalle suoritusongelmalle, muistin konsistenttiudelle, ei ole vieläkään tehty mitään, koska se vaatii rautamuutoksia, joita ARMilla ilmeisesti ei ole kiinnostusta speksata/virallistaa.
Jotain benchmarkkeja binäärikäännöksen suoritusnopeudsta ja ARM64ECn hidastavasta vaikutuksesta, ajettu M1:llä
Macos X native ARM64: 33s
Macos X x86 rosetta emulation (Applen binäärikääntäjä hyödyntää Applen tiukempia konsistenttiussääntöjä) 44s (75% suorituskyky /1.33x hidastus natiivista)
Windows native ARM64: 37s
Windows x86 emulation (Microsoftin binäärikääntäjä ei hyödynnä Applen tiukempia konsistenttiussääntöjä) 106s (35% suorituskyky / 2.86x hidastus natiiviin verrattuna)
Windows native ARM64EC: 38s (97% suorituskyky normaaliin ABIin verrattuna)
Sinänsä tuo 3% hidastus tuosta x86-yhteensopivasta ABIsta ei ole paha, mutta se, että binäärikäännetty koodi windowsissa ajautuu melkein 3x hidastuksella on hyvin paha kun vertaa Applen binäärikääntäjän vain 1.33x hidastumiseen.
Ero macos X:n ja windowsin välillä natiivin ARM64-koodin nopeudessa taas todennäköisesti johtuu virtuaalimuistisivujen koosta ja sen vaikutuksesta L1D-välimuistin toimintaan, windows ARM64llakin todennäköisesti käyttää 4 kiB virtuaalimuistisivuja (jotka on ongelmallisia Applen ison L1D-välimuistin kanssa) mutta Macos X käyttää ARMilla 16 kiB virtuaalimuistisivuja.
Lähde tälle benchmarkille:
https://fosdem.org/2024/events/attachments/fosdem-2024-1762-arm64ec-microsoft-s-emulation-frankenstein/slides/22690/Arm64EC_with_notes_7gqE5cH.pdf
Baldur's Gate 3 Up and Running on Snapdragon X Elite Reference Platform
http://www.techpowerup.com
Siellä on Baldur’s Gate 3:sta esitelty
Mikä tuossa teki niin onnettomaksi? En oikein äkkiä keksi mitään muutakaan lähestymistapaa jos yritetään saada aikaiseksi paravirtualisointi kahden eri arkkitehtuurin välillä. ARM interworking ABI toimii vähän samaan tapaan ARMv7:ssa.
"30% prosessorinkäyttö" ei yleensä tarkoita, että riittäisi paljon heikompi prossu. Vaan se tarkoittaa, että suurin osa prossuytimimistä osa idlaa, kun softa ei osaa kovin hyvin hyödyntää montaa ydintä.
Siellä voi olla yksi ydin täydellä kuormituksella, pari ydintä porskuttaa neljäsosan ajasta ja loput ytimet idlaa.
Tällaisessa tilanteessa yhden säikeen suoritusnopeudella on hyvin suuri vaikutus softan suorituskykyyn.
Ei ole, vaan se on natiivisoftalla todella paljon nopeampi kuin mikään 10 vuotta vanha x86-prossu. Se on natiivisoftilla melko kilpailukykyinen modernien x86-prossujen kanssa.