Erster M1-GPU-Treiber mit OpenGL-ES-Konformitätszertifizierung
(rosenzweig.io)- Für GPUs der M1- und M2-Familie ist ein Linux-Treiber verfügbar, der OpenGL-ES-3.1-Anwendungen standardkonform ausführen kann
- Der kostenlose Open-Source-Treiber von Asahi Linux auf Basis von Reverse Engineering ist die einzige OpenGL-ES-3.1-Implementierung für M1- und M2-Grafikhardware, die die Khronos-Konformitätstests bestanden hat
- Die Zertifizierung umfasst das Bestehen der offiziellen Tests, die Einreichung bei Khronos und eine 30-tägige Prüfphase; registriert sind M1, M1 Pro/Max/Ultra, M2 und M2 Pro/Max
- OpenGL ES 3.1 aktualisiert die experimentelle Unterstützung für OpenGL ES 3.0 und OpenGL 3.1 vom Juni und ergänzt Compute Shader sowie atomare Bildoperationen
- Da M1 keine speziellen Befehle für atomare Bildoperationen besitzt, wurde dies zunächst über Adressberechnung umgangen; später wurde ein Bit-Interleave-Befehl gefunden, der 10 Befehle auf 1 reduziert
OpenGL-ES-3.1-Konformitätszertifizierung für M1 und M2
- Für GPUs der M1- und M2-Familie ist ein Treiber mit OpenGL-ES-3.1-Konformitätszertifizierung verfügbar
- Kompatibel mit OpenGL-ES-3.1-Anwendungen
- Nutzbar mit einer Linux-Installation
- Bestehende Nutzer von Asahi Linux können den neuesten Treiber über die jeweiligen Upgrade-Befehle ihrer Distribution erhalten
- Fedora:
dnf upgrade - Arch:
pacman -Syu
- Fedora:
- Der kostenlose Open-Source-Grafiktreiber auf Basis von Reverse Engineering ist unter asahi/mesa veröffentlicht
- Dieser Treiber ist weltweit die einzige OpenGL-ES-3.1-konforme Implementierung für Grafikhardware der M1- und M2-Familie
- Er hat Zehntausende Tests bestanden und damit seine Korrektheit belegt
- Er ist von einem Branchenstandardisierungsgremium anerkannt
Khronos-Verfahren und registrierte Chipfamilien
- Um eine Konformitätszertifizierung zu erhalten, muss eine Implementierung die offizielle Conformance Test Suite bestehen
- Die Testsuite ist darauf ausgelegt, alle Funktionen der Spezifikation zu prüfen
- Die Testergebnisse werden bei der Standardisierungsorganisation Khronos eingereicht
- Wenn während der 30-tägigen Prüfphase keine Probleme auftreten, wird sie zu einer konformen Implementierung
- Auf der Khronos-Website sind die folgenden Treiber als konforme Implementierungen registriert
- Dieser Erfolg bleibt nicht auf OpenGL ES beschränkt
- Es handelt sich um die erste konforme Implementierung im gesamten Bereich der Grafikstandards für M1
Die Lücke zwischen Herstellertreibern und Standard-APIs
- Die M1-Treiber des Herstellers sind für keine standardisierte Grafik-API, einschließlich Vulkan, OpenGL und OpenGL ES, konformitätszertifiziert
- In M1- und M2-Umgebungen ohne Linux gibt es keine Garantie, dass standardbasierte Anwendungen funktionieren
- Im Fall von Vulkan legt MoltenVK Teile von Vulkan als Schicht über proprietäre Treiber
- Diesen proprietären Treibern fehlen zentrale Funktionen
- Gültige Vulkan-Anwendungen können dadurch kaputtgehen
- Das ist ein Hindernis sowohl für Entwickler als auch Nutzer, die ihre M1- oder M2-Computer nicht auf Linux umgestellt haben
- Die Entwicklung der Asahi-Linux-Treiber zielt darauf ab, Standardsoftware ohne M1-spezifische Hacks oder Portierungen auszuführen
- Man gibt sich nicht mit proprietären Treibern, proprietären APIs und der Verweigerung von Standardimplementierungen zufrieden
- Offene Standardimplementierungen nach Spezifikation werden als wünschenswerte Richtung für das Ökosystem gesehen
Zentrale Neuerungen in OpenGL ES 3.1
- OpenGL ES 3.1 aktualisiert die im Juni bereitgestellte experimentelle Unterstützung für OpenGL ES 3.0 und OpenGL 3.1
- Die wichtigste Ergänzung sind Compute Shader
- Sie werden vor allem verwendet, um allgemeine Berechnungen innerhalb von Grafikanwendungen zu beschleunigen
- 3D-Spiele können Physiksimulationen in Compute Shadern ausführen
- Wenn die Simulationsergebnisse direkt fürs Rendering genutzt werden, lassen sich Pausen durch Synchronisierung zwischen GPU- und CPU-Physiksimulation verringern
- Dadurch können Spiele schneller laufen
Warum atomare Bildoperationen nötig sind
- Frühere Versionen von OpenGL ES ermöglichten Anwendungen, Bilder zur Anzeige auf dem Bildschirm zu lesen
- ES 3.1 ermöglicht Anwendungen, üblicherweise in Compute Shadern, in Bilder zu schreiben
- Dadurch sinkt die Einschränkung, Bildverarbeitungsalgorithmen an eine Fixed-Function-3D-Pipeline anpassen zu müssen
- Eine GPU ist eine massiv parallele Architektur, die Tausende Threads gleichzeitig ausführt
- Wenn zwei Threads an dieselbe Stelle schreiben, hängt das Ergebnis von der Ausführungsreihenfolge ab
- Diese Situation ist eine Race Condition
- Atomarer Speicherzugriff ist die grundlegende Lösung für Race Conditions
- Spezielle Hardware im Speichersubsystem garantiert für ausgewählte Operationen konsistente Ergebnisse unabhängig von der Thread-Reihenfolge
- Moderne Grafikhardware unterstützt mehrere atomare Operationen wie etwa Addition
- Die OpenGL-ES-Erweiterung OES_shader_image_atomic ergänzt atomare Operationen auf Bildpixeln
- Diese Erweiterung ist in ES 3.2 verpflichtend
- Ein Compute Shader kann zum Beispiel den Wert des Pixels
(10, 20)atomar erhöhen
Wie atomare Bildoperationen auf M1 implementiert wurden
- Andere GPUs stellen spezielle Befehle für atomare Bildoperationen bereit, was die Treiberimplementierung vereinfacht
- M1 besitzt keine dedizierten Hardwarebefehle für atomare Bildoperationen
- Atomare Operationen außerhalb von Bildern gibt es
- Nicht-atomare Bildfunktionen gibt es ebenfalls
- Daher wird die atomare Operation nicht direkt auf einem Pixel ausgeführt; stattdessen wird die Speicheradresse des Pixels berechnet und an dieser Adresse eine gewöhnliche atomare Operation ausgeführt
- Wenn ein Bild linear im Speicher abgelegt ist, ist die Adressberechnung einfach
- Die Y-Koordinate wird mit dem Stride multipliziert, also der Anzahl Bytes pro Zeile
- Die X-Koordinate wird mit der Anzahl Bytes pro Pixel multipliziert
- Die beiden Werte werden addiert, um den Byte-Offset relativ zum ersten Pixel zu erhalten
- Der Offset wird zur Adresse des ersten Pixels addiert, um die endgültige Adresse zu erhalten
- Reale Bilder sind meist nicht linear abgelegt
- Moderne Grafikhardware interleaved X- und Y-Koordinaten, um die Cache-Effizienz zu erhöhen
- Die Pixelanordnung im Speicher folgt nicht zeilenweise, sondern einer nahezu spiralförmigen Kurve
Bit-Interleave-Optimierung und Suche nach versteckten Befehlen
- Beim Interleaving von X- und Y-Koordinaten ist es ineffizient, Bits einzeln zu maskieren und zu verschieben
- Ein bekannter Bit-Manipulationsalgorithmus parallelisiert das Problem, indem er Bitgruppen mischt
- Wenn dieser Algorithmus im Shader-Code implementiert wird, verbessert sich die Performance
- Tatsächlich werden nur die unteren 7 Bits oder weniger jeder Koordinate interleaved
- X- und Y-Koordinaten können in die unteren bzw. oberen 16 Bits eines 32-Bit-Registers gelegt und mit 32-Bit-Befehlen gleichzeitig verarbeitet werden
- Dadurch lässt sich die Zahl der Befehle halbieren
- Auch kombinierte Shift-and-Add-Befehle der GPU werden genutzt
- Durch die Kombination dieser Techniken konnte das Interleaving mit 10 M1-GPU-Assembly-Befehlen durchgeführt werden
- Anschließend wurde die Möglichkeit eines speziellen Bit-Interleave-Befehls geprüft
- PowerVR besitzt einen
shfl-Shuffle-Befehl - Da die M1-GPU Elemente von PowerVR übernommen hat, wurde die Möglichkeit eines ähnlichen Befehls geprüft
- Da der proprietäre Compiler diesen Befehl beim Kompilieren von Test-Shadern nicht verwendete, war Reverse Engineering allein durch Beobachtung der Compiler-Ausgabe schwierig
- PowerVR besitzt einen
Durch Vermutung und Prüfung bestätigter Interleave-Befehl
- Dougall Johnson leitete Kandidaten auf Basis bereits bekannter Befehlscodierungen ab
- Der Bit-Reversal-Befehl hat ein 2-Bit-Feld zur Auswahl der Operation, dessen Wert
01ist- Der Befehl zum Zählen gesetzter Bits ist
10 - Der Befehl zum Finden des ersten gesetzten Bits ist
11 - Die bekannten komplexen Bit-Manipulationsbefehle verwenden diese drei Werte
- Der Befehl zum Zählen gesetzter Bits ist
- Der verbleibende Wert
00war ein nicht beobachteter, unbekannter Wert- Falls ein Interleave-Befehl existiert, wurde geprüft, ob er dem Bit-Reversal-Befehl ähnelt, aber den Opcode
00verwendet
- Falls ein Interleave-Befehl existiert, wurde geprüft, ob er dem Bit-Reversal-Befehl ähnelt, aber den Opcode
- Die drei bekannten Befehle haben nur eine Eingabequelle, ein Interleave-Befehl benötigt jedoch zwei Quellen
- M1-GPU-Befehle codieren Quellpositionen in der Regel konsistent
- An der Stelle, an der bei arithmetischen Zwei-Quellen-Befehlen die zweite Quelle liegen würde, gab es freien Platz; diese Position wurde daher als zweite Quelle vermutet
- Die Prüfung erfolgte, indem der Compiler so geändert wurde, dass eine 2-Quellen-Integer-Operation wie Multiplikation durch die vermutete Interleave-Codierung ersetzt wurde
- Diese Operation wurde in einem Compute Shader verwendet
- Der Test-Shader prüft für alle möglichen Eingaben, ob der unbekannte Befehl das Interleave-Ergebnis zurückgibt
- Da der Befehl zwei 16-Bit-Quellen erhält, gibt es etwa 4 Milliarden Eingaben
- Mit der neuen Compute-Unterstützung des Treibers prüfte die M1-GPU alle Eingaben in weniger als einer Sekunde
- Am Ende wurde die vektorisierte Assembly aus 10 Befehlen durch einen Interleave-Befehl ersetzt
- Dieser Ansatz ist schnell und besteht auch die Konformitätstests
1 Kommentare
Meinungen auf Hacker News
Da Apple bei OpenUSD, einem Format für Rendering/Animation/CAD/3D-Szenen, mit nVidia, Adobe, Autodesk, Microsoft und anderen zusammenarbeitet, frage ich mich, ob sich die OpenGL-/Vulkan-Unterstützung verbessern wird.
Wenn der Kern von OpenUSD „ein einziges Dateiformat, das überall konsistent gerendert wird“ ist, könnte Apple es als Mittel nutzen, mehr Anbieter von 3D-Software zu macOS zu holen.
Für die Zukunft scheinen sich zwei Wege abzuzeichnen: Entweder Apple folgt den bestehenden OpenGL-/Vulkan-Standards, die in Film- und Spieleproduktions-Pipelines an Bedeutung gewinnen, oder Apple drückt Metal noch stärker durch und versucht, die Welt in Richtung Metal + macOS zu ziehen.
Mein Herz hofft auf Ersteres, aber mein Bauchgefühl sagt, dass Apple mit voller Kraft Letzteres verfolgen wird; und nicht nur Apple, auch nVidia, Autodesk, Adobe und Microsoft mögen Standards, die sie nicht kontrollieren, eher nicht.
Beim iMac und dem frühen OS X wurden Standards wie USB, JPEG, MPEG, mp3, PostScript, integriertes TCP/IP und .rtf stark herausgestellt, und Jobs betonte das ebenfalls.
Nachdem Apple sich vom Abgrund erholt hatte, begann das Unternehmen wieder, „Mehrwert“ hinzuzufügen; auch das iPhone wurde anfangs als HTML-Gerät betont, statt auf das proprietäre und miserable Flash oder das unreife „mobile HTML“ zu setzen.
Auch heute unterstützt Apple in Bereichen, in denen seine Marktmacht gering ist, Standards, die es nicht kontrolliert, wie H.264 und Matter/Thread.
Da Apple Hardware und Software stark koppelt, um die beabsichtigte User Experience zu schaffen, ist es nachvollziehbar, dass das Unternehmen Standards implementieren möchte, die es bis zu einem gewissen Grad kontrollieren kann, damit diese Erfahrung nicht von anderen abhängt.
Auch Industriestandards wie USB-C, deren Richtung noch nicht festgelegt ist, übernimmt Apple manchmal, weil es durch frühes Handeln die Richtung beeinflussen kann.
Die meisten, darunter Adobe, Autodesk und Blender, unterstützen ohnehin bereits je nach Betriebssystem unterschiedliche Backends, unter macOS einschließlich Metal.
OpenGL ist viel zu alt, gute Treiber dafür zu bekommen ist nahezu ein Albtraum, und selbst performanten Anwendungscode dafür zu schreiben ist schwierig; deshalb trauere ich dem nicht nach.
Allerdings hätte ich mir gewünscht, dass Apple statt Metal Vulkan vorangetrieben hätte. Außerhalb von Linux ist Vulkan allerdings meist eher ein Bürger zweiter Klasse, wenn auch ein ziemlich brauchbarer Bürger zweiter Klasse als Zielplattform.
Aus Sicht von Spielen oder Steam-Unterstützung überlassen viele Spiele die API-Behandlung der Engine, und wenn ein Team die Ressourcen hat, direkt mit der API zu arbeiten, dürfte MoltenVK wahrscheinlich ausreichen, solange es keine sehr fortgeschrittenen Funktionen nutzt.
Ich habe mein Leben lang viel OpenGL für Cross-Platform genutzt, aber wegen globalem Zustand, Funktionen, die man nicht verwenden sollte, Fallstricken, riesigen Extension-Headern und schwierigem Debugging war es wirklich eine furchtbare API; Vulkan ist zwar wortreich, aber in vielerlei Hinsicht sogar einfacher.
Aber der Mac, den ich derzeit nutze, ist allein über USB-C-Ports per Standardprotokollen mit mehreren Peripheriegeräten und einem großen Monitor verbunden.
Insgesamt scheint Apple offene Standards zu bevorzugen, wenn der Standard gut genug ist. Als USB2 vieles von dem, was Lightning leistete, noch nicht konnte, entwickelte Apple Lightning; als USB-C kam, wurde es bei Mac und iPad sofort übernommen, während Apple beim iPhone leider trödelt.
Asahi und Alyssa sind Giganten des Reverse Engineering, und ihre Arbeit ist kaum zu glauben.
Ich halte es für sehr wahrscheinlich, dass Apple versucht hat, sie einzustellen, oder es bereits versucht hat und abgelehnt wurde.
Man könnte auch sagen, dass Valve mehr geschäftliche Gründe hat als Apple, diese Fähigkeiten zu nutzen.
Normale Angestellte werden im Vergleich zu dem Gewinn, den sie erzeugen, meist niedrig bezahlt, und in der IT gilt das besonders.
Talentierte Leute sind besser dran, eine Firma zu gründen und ihre Dienste zu einem fairen Preis zu verkaufen, aber in manchen Ländern haben Großunternehmen bei der Regierung Lobbyarbeit betrieben, um diesen Weg zu versperren.
Der Trick mit atomaren Operationen war sehr befriedigend, und besonders beeindruckend war, wie die Swizzle-Instruktion aus der PowerVR-Abstammung hergeleitet wurde.
Ich denke, auch Apples Ingenieure werden daraus lernen oder zumindest die Cleverness dahinter sehr schätzen.
Das erinnert mich daran, wie Ingenieure bei Accolade früher beim Reverse Engineering der Sega-Genesis-Video-Hardware die veröffentlichten Unterlagen zum Texas Instruments TMS9918 VDP als Ausgangspunkt nahmen, um den vom 9918 abgeleiteten VDP des Genesis (Mega Drive) herzuleiten.
Zur Klarstellung: Das ist nicht einfach der erste konformitätszertifizierte Linux-Treiber, sondern hat eine größere Bedeutung.
Da Apple selbst nicht OpenGL ES 3.1-konform ist, ist dies im Wortsinn der erste konformitätszertifizierte OpenGL-ES-3.1-Treiber für die M-Serie auf irgendeinem Betriebssystem.
Deshalb kommt auch die Bitte, an das Team zu spenden.
https://asahilinux.org/support/
Falls es dafür eine Option gibt, würde ich gern wissen, wo; wenn nicht, nutze ich später einfach diesen Link.
Wenn man heute macOS-OpenGL-Apps debuggt, die inzwischen nicht mehr empfohlen werden, wird dieses Problem sehr deutlich
Denn die Abstraktionsschicht legt den tatsächlichen OpenGL-Zustand nicht so offen, dass der alte Apple-OpenGL-Debugger ihn lesen könnte
Hat man keinen älteren Mac mit einer alten macOS-Version, auf der OpenGL intern noch nicht auf Metal lief, kann man OpenGL unter macOS mit dem Standard-Debugger praktisch nicht debuggen
Der Debugger oder die App stürzt einfach ab
Das scheint vor allem Spielen zu helfen und für Deep Learning nicht besonders viel zu bringen
Der größte Reiz des Mac M1 ist die große Speicherkapazität; fürs Training ist das vielleicht weniger geeignet, weil man es nicht über mehrere Karten verteilen kann, aber als Inferenz-Engine für große Modelle wie Stable Diffusion oder LLaMA ist es gut
SYCL ist ein herstellerneutrales High-Level-Programmierframework der Khronos Group, wird von Anwendungen aber nur begrenzt unterstützt; mit Intels Unterstützung hofft man auf allmähliche Besserung
Vulkan Compute umgeht das Problem über Compute-Shader, aber wie es dort mit der Anwendungsunterstützung aussieht, weiß ich nicht genau
SYCL kann auf OpenCL und der SPIR-V-Erweiterung von OpenCL implementiert werden, doch wegen der starken Herstellerbindung wurde dieser Weg außerhalb von Intel und Mesa weitgehend aufgegeben; heute wird es oft als Backend für die jeweiligen GPU-Hersteller-APIs wie ROCm, HIP oder CUDA umgesetzt
Denselben Ansatz auf Metal anzuwenden wäre sehr schwierig; Mesa hat experimentelle OpenCL+SPIR-V-Unterstützung für Intel und AMDGPU, die sich theoretisch auf Apple Silicon erweitern ließe, aber OpenCL auf Apple Silicon wird derzeit überhaupt nicht unterstützt und stand höchstens auf der Roadmap
Für Deep Learning braucht man Backends wie CUDA, ROCm, MPS
Es war vergleichsweise einfach, ein PyTorch-Modell auf einem großen CUDA-Server zu trainieren und die Inferenz auf einem MacBook Air laufen zu lassen
Allerdings hat eiln einen Treiber für die Apple Neural Engine geschrieben, sodass dedizierte Hardware statt der GPU genutzt werden kann; er soll künftig in linux-asahi gemergt werden
Die Formulierung, dass Asahi Lina und zwei Leute mit minimaler Finanzierung einen Großkonzern geschlagen hätten, klingt gut, aber tatsächlich war es weniger ein Sieg als vielmehr etwas, worum Apple sich nicht gekümmert hat
Apple ist in diesem Rennen von Anfang an gar nicht angetreten
Mir gefällt die beschönigende Formulierung „zwei Leute haben mit minimaler Finanzierung einen Großkonzern geschlagen“
Das ist für Apple offensichtlich peinlich, und Apple interessiert sich nicht für Standards oder Konformität, sondern will, dass die Leute in seinem eigenen Walled Garden gefangen bleiben
Wäre ich kein iOS-Entwickler, hätte ich das Apple-Ökosystem schon vor langer Zeit verlassen
Ich mag die Hardware, und ich mochte auch die Marke, die wie Apple in den 80ern und 90ern Kreativität und Menschenzentrierung betonte, aber das heutige Unternehmen wirkt hinter politisch korrekten Marketingvideos von Gier zerfressen
Beim letzten Upgrade habe ich nach Alternativen gesucht, aber um Apple zu verlassen, hätte ich endlose Kompromisse akzeptieren müssen
Als Ersatz für das iPhone habe ich mir wegen Stock Android und langer Unterstützung das Pixel angesehen, aber es gab ständig Berichte über Akkuprobleme, und auch Software-Polish, App-Ökosystem und Stabilität waren Hindernisse
Es war auch schwer, ein Produkt mit ähnlich gutem Preis-Leistungs-Verhältnis wie das MacBook Air M1 in der Basisversion zu finden, was Verarbeitungsqualität, Akku und Stabilität angeht
Auf dem iPad lese ich auch Comics und Magazine, aber beim Tablet-Markt weiß ich seit Jahren nicht, was die Alternative sein soll; auf die Apple Watch könnte ich vielleicht verzichten, aber sie funktioniert einfach gut und es gibt reichlich Zubehör von Drittanbietern
Die Zeiten, in denen ich täglich neue ROMs geflasht habe, sind vorbei, und es ist schade, weil Apple bei Stabilität und Bedienkomfort offenbar schwer zu schlagen ist
Der einzige Grund, warum alle Jobs sicher sind, ist, dass niemand genau herausfinden kann, wer diese zwei Leute sind
Apple hat sein eigenes Silizium entwickelt und die gesamte Plattform aufgebaut; es ist schwer zu glauben, dass es ein bloßes Versehen war, die Ausführung anderer Betriebssysteme möglich zu lassen
Es ist offensichtlich, dass Apple diese Tür bewusst für Drittentwicklungen offen gelassen hat, und deshalb finde ich die Stimmung, Apple dafür zu kritisieren, enttäuschend
Um zum Beispiel eine fortlaufende Vulkan-Implementierung zu unterstützen, bräuchte es erhebliche Ressourcen und würde Release-Zeitpläne belasten; dafür braucht es geschäftliche Gründe
„Um Peinlichkeit zu vermeiden“ reicht wahrscheinlich nicht aus
Man könnte mit Goodwill gegenüber der Community argumentieren, aber ich glaube nicht, dass Apple um die Sympathie von Leuten buhlen wird, die das Unternehmen als „von Gier zerfressen hinter politisch korrekten Marketingvideos“ bezeichnen
Die Konformitätstests sind nicht Open Source, und die separate „conformance suite“ auf GitHub basiert auf Googles dEQP, nicht auf dem internen Testpaket von Khronos
Man kann eine „standardkonforme Zertifizierung“ bekommen, selbst wenn die Implementierung ziemlich große Bugs und Lücken hat
Apple hat nur Unterstützung für OpenGL 3.1 zugesagt und den OpenGL-Treiber für den M1 als Emulationsschicht über Metal neu geschrieben, damit bestehende Apps weiter funktionieren; neuere OpenGL-Versionen wird Apple aber nicht implementieren, und das muss es auch nicht
Es gibt viel Kritik an Apple, und es gibt viel Raum, die Metal-API und die Tools zu verbessern, aber sich nicht um OpenGL zu kümmern ist hier eine völlig nachvollziehbare Entscheidung
Interessant ist, dass im Original das Wort „Apple“ kein einziges Mal vorkommt und nur von „Hersteller“ und „Großkonzern“ die Rede ist
Falls das Absicht ist, frage ich mich, ob es rechtliche Gründe hat
Im Fokus steht nicht Apple, sondern Linux auf der M1/M2-Architektur ordentlich zum Laufen zu bringen; wären Microsoft, Amazon oder Google das Ziel gewesen, wäre man wohl genauso vorgegangen
Es war spannend, die Livestreams zum Entwicklungsprozess dieses Treibers zu verfolgen, und die Arbeit ist wirklich beeindruckend
Das gehört zu den erstaunlichsten Arbeiten im Bereich Low-Level-Programmierung, die ich bisher gesehen habe