MediaTek Dimensity 9200 is eerste soc zonder ondersteuning voor 32bit-apps

Chipontwerper MediaTek heeft zijn Dimensity 9200- soc aangekondigd. Het gaat om de eerste soc voor smartphones zonder ondersteuning voor 32bit-apps. De soc kan alleen 64bit-software draaien, zegt de fabrikant.

Daarmee vervalt de ondersteuning voor vooral oudere apps en games die geen 64bit-ondersteuning hebben. De Google Pixel 7 heeft softwarematig geen ondersteuning voor 32bit-software, maar de Tensor G2-soc heeft dat wel. Socs voor smartphones ondersteunen 64bit al jaren, maar tot nu toe konden socs ook 32bit-software blijven draaien.

De Dimensity 9200 is bovendien de eerste soc met een Arm Cortex X3-kern, die draait op 3,05GHz. Daarnaast heeft het cpu-cluster drie Cortex A715-kernen op 2,85GHz en vier zuinige Cortex A510-kernen op 1,8GHz. De gpu is een Arm Immortalis G715, een upgrade ten opzichte van de Mali G710 van de Dimensity 9000.

De soc ondersteunt bovendien UFS 4.0, waar de Dimensity 9000 tot UFS 3.1 komt. Beide socs ondersteunen Lpddr5x-geheugen, maar de 9200 komt daarbij tot 8533Mbit/s, waar de 9000 tot 7500Mbit/s komt.

Op cameragebied kan de Dimensity 9200 8k-video's verwerken tot 30fps, iets wat de 9000 niet kan. Veel dure Android-smartphones bieden die mogelijkheid aan, zeker nu vrijwel alle fabrikanten camera's met hoge resolutie gebruiken. Voor 8k-video's is een camera van minimaal 33 megapixel vereist.

MediaTek laat de soc maken bij TSMC op de tweede generatie van zijn 4nm-procedé. De Dimensity 9200 moet eind dit jaar in telefoons verschijnen, zegt de chipontwerper. Concurrent Qualcomm zal zijn concurrerende Snapdragon 8 Gen 2 vermoedelijk volgende week aankondigen.

MediaTek	Dimensity 9200	Dimensity 9000
Cpu	1x Cortex X3 @ 3,05GHz 3x Cortex A715 @ 2,85GHz 4x Cortex A510 @ 1,8GHz	1x Cortex X2 @ 3,05GHz 3x Cortex A710 @ 2,85GHz 4x Cortex A510 @ 1,8GHz
Gpu	Arm Immortalis G715	Arm Mali G710MC10
AI	Apu 690	Apu 590
Geheugen	Lpddr5x, 8533Mbit/s	Lpddr5x, 7500Mbit/s
Opslag	UFS 4.0 + MCQ	UFS 3.1
Wifi	Wi-Fi 7 (2x2 antennes)	Wi-Fi 6E (2x2 antennes)
Bluetooth	5.3	5.3
5G	Dualsim, dualactive, Sub-6, mmWave	Dualsim, dualactive, Sub-6
Video-opname	8k30, 4k60	'4k'
Scherm	1440p op 144Hz, 1080p op 240Hz	1440p op 144Hz, 1080p op 180Hz

Reacties (30)

[Balance]

Met de ARMv9 is 32-bits Aarch-support end-of-life gegaan. De Cortex-A710 was een enkele uitzondering met nog wel 32-bits ondersteuning, maar de A500 en X series (Cortex-A510 en X2) ondersteunden vanaf het begin van ARMv9 al geen 32-bits ondersteuning meer. Nu de A710 door de A715 is vervangen zitten er dus enkel AArch64 kernen in de ARMv9 lineup (en nu de Dimensity 9200).

Dit zat er overigens al heel lang aan te komen: In december 2017 werd al aangekondigd dat 64-bit ondersteuning een verplichting zou worden vanaf augustus 2019. In januari 2019 kwam daar bij dat vanaf augustus 2021 32-bits ondersteuning stopgezet ging worden voor telefoons die 64-bits apps konden draaien.

Het grootste voordeel is dat je straks geen dubbele binaries meer hebt en apps kleiner worden, en dat RAM verbruik afneemt. Verder zijn er hier en daar wat specifieke optimalisaties mogelijk omdat je geen rekening meer hoeft te houden met 32-bits apparaten. Verder is het voor ontwikkelaars makkelijk om een platform minder te hoeven ondersteunen.

[Reactie gewijzigd door Balance op 22 juli 2024 14:08]

[P_Tingen]

Zijn er dan nu ook apps die niet meer kunnen draaien op deze soc? Dat zullen er dan toch heel weinig zijn en dan ook nog apps die al een hele tijd niet zijn bijgewerkt?

[RoestVrijStaal]

Nou is het in tegenstelling tot het applicatie-ecosysteem van Windows en Linux, die van Android "walled garden" genoeg dat gebruikers zich erbij (moeten) neerleggen dat hun ooit gekochte maar verouderde apps niet meer werken.

Maar wat gaan gebruikers met deze functionaliteitsvermindering winnen?

[psychicist]

Het is niet een echte functionaliteitsvermindering. De AArch64 instructieset is een echte 64-bit instructieset zonder legacy. Dat is heel anders dan bij x86_64, wat een 64-bit uitbreiding is op een 32/16-bit instructieset. Als je nu nieuwe software schrijft, wil je dat deze voor een moderne instructieset zonder onnodige legacy gecompileerd wordt.

Dat zorgt er ook voor dat de decoder veel kleiner en sneller gemaakt kan worden, wat weer tot betere prestaties van de chips kan leiden. Android applicaties worden over het algemeen in Java of Kotlin geschreven, dus die moeten eenvoudig aan de praat te krijgen zijn.

Als applicaties in C of C++ geschreven zijn met eventueel ARM assembly, dan is verstandig deze laatste om te zetten naar AArch64. Zelf ken ik eigenlijk alleen maar AArch64 assembly. Oudere binaries zullen dan desnoods maar geëmuleerd moeten worden. Ook onder Linux en BSD heb ik altijd alleen maar ARM64 versies van distributies gedraaid.

[kabelmannetje]

Onzin. Er zijn genoeg oude architecturen die Linux na verloop van tijd dropt. Domweg omdat bijna niemand deze gebruikt. Zeer begrijpelijk, het kost veel extra tijd, developers en testers met kennis worden schaars en uiteindelijk houdt het nieuwe ontwikkelingen op.

[heuveltje]

Ja. af en toe faseert linux ook wel iets uit. Maar als ze nu nog aan het discusieren zijn of i486 niet meer ondersteund hoeft te worden, dan weet je dat dat proces een HEEL stuk trager gaat dan dit !

[kabelmannetje]

Dus Linux faseert wel degelijk wat uit. Ten eerste zit achter Linux geen verdienmodel. Ten tweede, zolang er ontwikkelaars en testers zijn, blijft de architectuur in Linux. Ten derde, 32bit op Android ondersteunen levert niks op. Ten derde, oude apps moeten alleen even recompiled worden. CPUs hebben overbodige ballast, software ook. Als het nauwelijks wat oplevert, uitfaseren. Zo werkt dat al decennia in techland.

[Klaus_1250]

Is men niet wat voorbarig om hier WiFi 7 neer te zetten? Men is nog zeker 2 jaar van de defintieve specificaties.

En waarom staart bij de 9000 Wifi 6E? Het is gewoon WiFi 6, de E gaat over de frequentie, maar daar heeft de SoC niks mee te maken.

[Floris4970]

Implementeren ze in het begin niet iets waarvan ze denken dat het het wordt in de hoop dat het een soort van compatible is als de standaard daadwerkelijk klaar is?

[Verwijderd]

--- Weggehaald

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:08]

[Gr4mpyC3t]

Jawel hoor!

https://tweakers.net/nieu...an-32bit-apps-op-ios.html
https://clearbridgemobile...-support-will-impact-app/

Edit: Tweakers nieuwsbericht toegevoegd.

[Reactie gewijzigd door Gr4mpyC3t op 22 juli 2024 14:08]

[Verwijderd]

Sinds de iPhone 5s (A7 chip) is hij volgens mij volledig 64 bit en draait geen 32 bit apps meer.
(de A4/5/6 deden dit kennelijk wel)

[Verwijderd]

Nope, zoals het nieuwsbericht aangeeft draait iOS geen 32-bit apps meer. Hetzelfde wat je dus hebt met de Pixel 7, softwarematig gelocked maar hardwarematig zouden ze het prima aankunnen. Het verschil met deze MediaTek is dus dat deze het ook hardwarematig niet kan, zelfs als ze het zouden toestaan in software.

[JBVisual]

Klopt, dit is ook goed terug te zien aan de Apple M-cpu's die qua architectuur nauw verbonden zijn met de Apple A-cpu's. De M-cpu is nog in staat om via emulatie de oude x86 32-bit applicaties de draaien.
Iets wat technisch best moeilijk wordt als er geen hardware matige ondersteuning is voor 32-bit architectuur.

uiteraard is via emulatie veel mogelijk, net zoals we nog 8-bit en 16-bit applicaties op pc's kunnen draaien via emulatie, maar omdat de hardware matige support (grotendeels) ontbreekt zal de prestatie daar onder lijden. De Apple cpu's zouden daar prestatie technisch zelfs nog aan kunnen voldoen, alleen zal dat dan weer teveel invloed hebben op de batterijduur van hun macbooks.
Iets wat niet in het straatje van Apple past.

Mijn vermoeden is dat dit over 2-3 jaar ook bij apple wel gedropt gaat worden. Het is toch weer een stukje microcode dat onderhouden moet worden (tegen misbruik, op functionaliteit etc...)

[Aaargh!]

De M-cpu is nog in staat om via emulatie de oude x86 32-bit applicaties de draaien.
Iets wat technisch best moeilijk wordt als er geen hardware matige ondersteuning is voor 32-bit architectuur.

Hoezo wordt dat moeilijk ? De code wordt al vertaald naar ARM instructies, lijkt me sterk dat ze vertalen naar 32-bit ARM.

Dit kan ook helemaal niet want de M1 ondersteund geen AArch32

[Reactie gewijzigd door Aaargh! op 22 juli 2024 14:08]

[Soru]

Vanaf MacOS 10.15 Catalina (2019) worden er geen 32-bit processen meer ondersteund vanuit het OS. In MacOS 10.15 heeft Apple echter wel support toegevoegd voor het aanmaken van 32-bit code segments vanuit een 64-bit process. Er wordt een far jump uitgevoerd om de processor naar 32-bit mode over te schakelen om na het uitvoeren van de code terug te schakelen naar 64-bit mode, Rosetta 2 ondersteunt deze 32-bit code segments waardoor dit kan werken.

Linux werkt native op eenzelfde wijze met 32-bit code segments. Dit hele concept is dan ook een belangrijk onderdeel van Wine op MacOS. Wine draait een 32-bit (x86) Windows EXE binnen een 32-bit Unix process.

Brendan Shanks van CodeWeavers heeft vorige maand een presentatie gegeven over het bovenstaande.
https://youtu.be/XnBK0M711-Q?t=10498

De spreker verwijst naar onderstaande mailinglists van Ken Thomases.
https://www.winehq.org/pi...2019-December/156602.html

[Reactie gewijzigd door Soru op 22 juli 2024 14:08]

[Aaargh!]

Dat is misschien zo op x86, maar Rosetta vertaalt 32-bit x86 code niet naar 32-bit ARM.

[Verwijderd]

Op mijn pi400 met aarch64 OS, heb ik, om 32bits x86 applicaties te kunnen draaien, een schroot de lucht in moeten gooien voor armhf om box86 te kunnen gebruiken. Dat kon niet op 64bit. Kennelijk is het toch lastig om naast arch emulatie ook nog te gaan zitten klooien met hoeveel bitjes je addressering kan zijn. Wellicht performance penalty? Al heeft zo'n m1 natuurlijk wel wat meer prik.

[Aaargh!]

Volgens de website is er gewoon een 64-bit versie genaamd box64

[Psycho_Mantis]

Ik dacht dat MacOS ook al jaren geen 32 bit meer ondersteuning had.

[Aaargh!]

Hetzelfde wat je dus hebt met de Pixel 7, softwarematig gelocked maar hardwarematig zouden ze het prima aankunnen.

Nee de Apple SoC's ondersteunen geen AArch32 meer. Sinds de Apple A11 is er geen 32-bit support meer. Niet alleen op OS niveau, maar ook op hardware niveau niet.

Het zou ook nergens op slaan, iOS ondersteund sinds iOS 11 geen 32-bit meer en Apple's CPU design is volledig zelf ontwikkelt, waarom zouden ze ruimte in de SoC opofferen voor 32-bit support ?

[Verwijderd]

Dat doen ze ook niet, zeker sinds de A11 niet meer, mist heel de A32 instructieset.

[Sebazzz]

Ik zou het niet noemen als "locken". Dat impliciteert dat het een simpel vlaggetje is wat je uitzet als softwareontwikkelaar, net zoals het activeren van een nieuwe cameramodule "gelocked" is.

Dat is hier niet het geval, als het op iOS of Android vergelijkbaar werkt als op Windows, betekent dat je compleet apart subsysteem in je besturingssysteem moet hebben om 32-bit software te ondersteunen - waaronder 32-bit libraries en een vertalingslaag om met de kernel te kunnen praten.

[D0ubleD0uble]

Jawel, de A4 (eerste in-house SoC van Apple) was 32-bits. Met de iPhone 5S in 2013 kwamen ze met de A7 die 64-bits was. Apple heeft 32-bit toen nog wel ondersteund maar sinds iOS 11 is het verplicht om apps 64-bits te maken om ze te kunnen updaten en 32-bits is er toen uitgesloopt. Daarvoor kon je nog wel 32-bits software draaien op een 64-bits iPhone, maar krijg je een waarschuwing in beeld dat de app mogelijk traag of niet goed draait en de ontwikkelaar deze moet updaten.

[f4b14n]

De A4 - A6 chips van Apple waren 32-bits.

[Aaargh!]

Het gaat om de eerste soc voor smartphones zonder ondersteuning voor 32bit-apps.

De eerste smartphone SoC zonder ondersteuning voor AArch32 was de Apple A11 uit 2017.

[vedercy]

Beide socs ondersteunen Lpddr5x-geheugen, maar de 9200 komt daarbij tot 8533Mbit/s, waar de 9000 tot 7500Mbit/s komt.

Dat is toch MT/s?

[kondamin]

Wat is het voordeel van MCQ in de plaats van gewoon een nieuwe te spawnen en de oude te verwijderen?

[IssY_I]

Dus de Google chromecast met Google TV 4K en de Nvidia Shield Android TV worden straks obselete want die draaien op 32 bit O.S en kunnen geen 64bit apps installeren/draaien terwijl de Soc's wel een 64 bit architectuur hebben... Is dit doormiddel van een software update op te lossen ?