- Der Kernel-Grafiktreiber für Apple-M1/M2-GPUs ist nicht nur Rust-basiert, sondern erreicht inzwischen auch Konformität mit OpenGL 4.6 und Vulkan 1.3 und erweitert damit die Breite der unterstützten Standards
- Tessellation, ein Kernbestandteil von OpenGL 4.0, lässt sich mit den Hardware-Funktionen von Apple-GPUs allein nur schwer standardkonform umsetzen; daher wurde der Microsoft-Referenz-Tessellator nach OpenCL C portiert und auf der GPU ausgeführt
- In einer Vulkan-Demo auf einem M2 Mac erreichte die OpenCL-basierte Tessellation 265fps, deutlich schneller als eine reine Software-Implementierung mit unter 1fps, aber langsamer als ein Hardware-Tessellator mit 820fps
- Für die Ausführung von AAA-Spielen müssen DirectX-, Windows-, x86- und 4KB-Seiten-Umgebungen auf Apple Silicon mit Linux, Arm64 und 16KB-Seiten angepasst werden; dafür kommen mehrere Übersetzungsschichten und eine VM-Konfiguration gemeinsam zum Einsatz
- Spiele wie Portal, The Witcher 3 und Cyberpunk 2077 liefen tatsächlich, aber Speicheranforderungen und der Umfang der ray tracing-Unterstützung bleiben weiterhin wichtige Einschränkungen
Apple-GPU-Treiber jetzt bei OpenGL 4.6
- Der Kernel-Grafiktreiber für Apple-M1/M2-GPUs wurde in Rust geschrieben und hat Konformität mit mehreren Grafikstandards erreicht
- Alyssa Rosenzweig gab auf der X.Org Developers Conference 2024 ein Update zum Stand des Treibers und zu den unterstützten Spielen
- Die Präsentation ist als YouTube-Video und als Folien verfügbar
- Auf der XDC des Vorjahres erreichte der Treiber Konformität mit OpenGL ES 3.1 und inzwischen auch mit OpenGL 4.6
- Für OpenGL 4.0 notwendige Tessellation) ist eine Technik, mit der sich der Detailgrad einer Szene dynamisch erhöhen oder verringern lässt
Grenzen des Hardware-Tessellators der Apple-GPU
- Apple-GPUs besitzen zwar einen Hardware-Tessellator, aber ihm fehlen Funktionen, die für eine standardkonforme OpenGL-Implementierung nötig sind, weshalb der Treiber ihn nicht direkt verwenden kann
- Die Hardware unterstützt offenbar weder point mode noch isoline; beide Funktionen lassen sich emulieren
- Das größere Problem sind transform feedback und der geometry shader
- Die Hardware unterstützt beides nicht
- Der Treiber emuliert dies mit compute shadern
- Unterschiede zwischen dem Tessellationsalgorithmus des Hardware-Tessellators und der Emulation können zu Fehlschlägen bei der Invarianz führen, daher sollte diese Kombination vermieden werden
- Apple unterstützt OpenGL 4.1, erreicht damit aber keine Konformität, und nicht von der Hardware unterstützte Funktionen werden durch Software ersetzt
- Rosenzweig erklärte, dass nicht Metal implementiert werde und man deshalb diesen Weg nicht einschlagen wolle
Referenz-Tessellator nach OpenCL C portiert
- Der Treiber nutzt den Referenz-Tessellator, den Microsoft vor mehr als zehn Jahren veröffentlicht hat
- Ursprünglich war dies Code, der zeigen sollte, welches Verhalten Hardware-Hersteller bei der Einführung von Tessellation implementieren mussten
- Es handelt sich um etwa 2000 Zeilen C++-Code, der einen einzelnen patch tesselliert
- Da ein GPU-Treiber nicht einfach 2000 Zeilen C++ direkt ausführen kann, wurde dieser Code nach OpenCL C portiert
- OpenCL C ist normalem CPU-C sehr ähnlich, besitzt aber GPU-spezifische Einschränkungen und Erweiterungen
- Das Ziel war nicht, den Code vollständig zu verstehen, sondern sein Verhalten beim Portieren nicht zu beschädigen
- Der CPU-Tessellator verarbeitet jeweils nur einen patch, aber eine Szene kann 10.000 Patches enthalten
- Die massive Parallelität der GPU wird genutzt, damit viele Threads die Tessellation ausführen
- Die Zuweisung der Ausgabepuffer während der Parallelverarbeitung wird über atomare GPU-Befehle verwaltet
- Die Ausgabe des Tessellators muss als draw-Befehle im von der GPU geforderten packed data structure-Format gerendert werden
- Normalerweise übernehmen im C-Treibercode Funktionen, die vom GenXML tool erzeugt wurden, diese Aufgabe
- Da der Tessellator dank OpenCL in Form von C-Code vorliegt, können die generierten Funktionen in den auf der GPU laufenden Code eingebunden werden
Tessellationsleistung
- Die OpenCL-basierte Tessellation wird genutzt, um in einer Vulkan-Demo auf einem M2 Mac terrain tessellation auszuführen
- Der Leistungsvergleich sieht wie folgt aus
- Reine Software-terrain tessellation: unter 1fps
- OpenCL-basierte Tessellation: 265fps
- Gemessener Wert mit angebundenem Hardware-Tessellator: 820fps
- Rosenzweig bewertete die Leistung des OpenCL-Ansatzes als „okay“ und geht davon aus, dass sie in echten Spielen eher kein Flaschenhals sein wird
- Bei der Treiberleistung gibt es weiterhin Verbesserungspotenzial
Vulkan 1.3 und Honeykrisp
- Der Honeykrisp-M1/M2-GPU-Treiber hat Vulkan-1.3-Konformität erreicht
- Ausgangspunkt war eine Kopie des NVK Vulkan driver for NVIDIA GPUs, kombiniert mit dem OpenGL-4.6-Treiber
- Nach etwa einem Monat begann der Treiber, die Konformitäts-Testsuite zu bestehen
- Das war zum Zeitpunkt des Vortrags sechs Monate her
- Danach kamen folgende Funktionen hinzu
- geometry shader
- tessellation shader
- transform feedback
- shader object
- Der Treiber unterstützt inzwischen alle Funktionen, die für mehrere DirectX-Versionen benötigt werden
Übersetzungsschichten für AAA-Spiele
- Um AAA-Spiele auf Apple Silicon auszuführen, müssen mehrere Umgebungsunterschiede gleichzeitig behandelt werden
- Zielumgebung der Spiele: DirectX, Windows, x86-CPU, 4KB-Seiten
- Tatsächliche Zielhardware: Apple Silicon mit Linux, Arm64 und 16KB-Seiten
- Die Übersetzung von DirectX nach Vulkan sowie die Ausführung von Windows unter Linux übernehmen jeweils DXVK und Wine
- Für die Übersetzung von x86 nach Arm64 gibt es bestehende Optionen wie FEX-Emu oder Box64
- Das größte Hindernis ist der Unterschied bei der Seitengröße
- FEX-Emu benötigt 4KB-Seiten
- Für Box64 gibt es einen Hack für 16KB-Seiten, der aber mit Wine nicht funktioniert und hier daher nicht hilft
- macOS kann für die x86-Emulation 4KB-Seiten verwenden, benötigt dafür aber sehr invasive Kernel-Unterstützung
- Asahi Linux hat bereits rund 1000 Patches auf dem Weg in den Mainline-Kernel, daher ist ein Ansatz, den Linux-Speicherverwalter neu zu schreiben, nicht vernünftig
VM-Konfiguration mit 4KB-Gastkernel
- Linux unterstützt keine heterogenen Seitengrößen zwischen verschiedenen Prozessen, aber zwischen verschiedenen Kerneln ist das möglich, und das wird per Virtualisierung gelöst
- Ein KVM-Gastkernel kann eine andere Seitengröße als der Hostkernel haben
- Verwendet wird eine Struktur, bei der FEX-Emu, Wine, DXVK, Honeykrisp, Steam und das gesamte Spiel in eine virtuelle Maschine gepackt werden, die einen 4KB-Gastkernel ausführt
- Der CPU-Overhead wurde dank Hardware-Virtualisierung als gering erwartet, und die tatsächliche Belastung liegt eher auf der Peripherieseite
- Honeykrisp läuft dabei nicht im Hostkernel, sondern im Gast über virtgpu native contexts
- Die Erzeugung des finalen GPU-command buffer erfolgt im Gast
- Statt dass jeder einzelne Vulkan-Aufruf die VM-Grenze überschreitet, wird der fertige command buffer an den Host übergeben
- Der VirGL-Renderer des Hosts reicht ihn an die GPU weiter
- Rosenzweig sagte, dass dieser Ansatz zwar nicht 100 % native Geschwindigkeit erreiche, aber sicher über 90 % liege
- CPU- und GPU-Overhead laufen parallel, sodass sich ihre Kosten nicht einfach addieren
Tatsächlich ausgeführte Spiele und Veröffentlichung
- Diese Konfiguration hat tatsächlich mehrere Spiele ausgeführt
- Portal
- Portal 2
- Castle Crashers
- The Witcher 3
- Fallout 4
- Control
- Ghostrunner
- Cyberpunk 2077
- Die zugehörigen Komponenten wurden am Tag des Vortrags, also am 10. Oktober, veröffentlicht
- Nutzer von Fedora Asahi Remix können sofort aktualisieren, um diese Komponenten zu erhalten
- Während des Vortrags dauerte der Start von Steam wegen der VM und der x86-Emulation etwas länger; anschließend lief Control auf einem M1 MAX-System mit 45fps
Einschränkungen bei Speicher und ray tracing
- Einige Spiele laufen auch auf Macs mit 8GB RAM
- Rosenzweig spielte während der Konferenz Castle Crashers auf einem 8GB-System
- Auch Portal läuft auf einem 8GB-System
- Anspruchsvollere Spieltitel dürften wahrscheinlich nur auf Systemen mit 16GB oder mehr laufen
- Rosenzweig hofft, dass der Ressourcenbedarf mit der Zeit sinken wird
- Unterstützung für ray tracing hat keine hohe Priorität
- Control kann diese Funktion nutzen
- Apple-Hardware unterstützt ray tracing erst ab M3
- Der aktuelle Treiber ist für M1- und M2-GPUs gedacht
- Rosenzweig plant, in absehbarer Zeit mit Arbeiten an M3 zu beginnen
1 Kommentare
Hacker-News-Kommentare
Der Einsatz, die M1/M2-Unterstützung bis zum Ende fertigzustellen, ist wirklich bewundernswert
Zu viele Projekte werden fallen gelassen, sobald ein neues glänzendes Raytracing-Spielzeug auftaucht, und solche Arbeit ist wegen schlecht dokumentierter Hardware schmerzhaft, aber sehr lohnend, wenn sie funktioniert
Ich habe mein M1 auch wegen dieses Projekts und Alyssas OpenGL+ES-Arbeit gekauft und boote nur Asahi Linux
Solche Geräte sind dafür gebaut, lange zu halten, und der langfristige Support sowohl von Apple selbst als auch von der Linux-Community ist lobenswert
Da es Open Source ist, schaut Apple wahrscheinlich auch zu, und im Artikel ging es auch um Arbeit an Umgehungen für fehlende Funktionen im Chip
Ich programmiere seit über 20 Jahren, aber sowohl die glücklichsten als auch die deprimierendsten Momente meiner Karriere stammen aus genau dem Hardware-Projekt, an dem ich vier Monate lang beteiligt war
Alyssas Ansatz, alles in einer virtuellen Maschine laufen zu lassen, um den Unterschied zwischen 4-KB- und 16-KB-Seitengrößen zu lösen, wirkt wie ein cleverer Hack, aber auch wie ein potenzieller Performance-Flaschenhals
Ich frage mich, was solche Workarounds langfristig bedeuten
Haben wir nicht einen Punkt erreicht, an dem die Komplexität, die Lücken proprietärer Hardware zu überbrücken, die für geschlossene Ökosysteme entworfen wurde, größer ist als der Nutzen
Dass Control auf einem M1 MAX mit Open-Source-Treibern mit 45 fps läuft, ist ermutigend, aber ich frage mich, ob die Community weiterhin so viele Ressourcen investieren sollte, um geschlossene Systeme offener zu machen, oder ob man eher offenere Hardware-Standards vorantreiben sollte
Apple schafft mit GPU-Beschränkungen, die Standardfunktionen wie Tessellation-Shader erschweren, und mit nicht standardmäßigen Seitengrößen unnötige Hürden für Entwickler, und solche geschlossenen Ökosysteme machen nicht nur Open-Source-Beitragenden das Leben schwer, sondern bremsen auch Innovationen aus, von denen alle Nutzer profitieren würden
Dass das das geschlossene Geschäftsmodell stützt, ist offensichtlich, und für Apple funktioniert das tatsächlich sehr gut
Sie bauen hervorragende Hardware, und auch wenn die Software zuletzt etwas instabil war, haben normale Nutzer mit der Kombination aus Hardware und Software meist eine gute Erfahrung
Daher legt Apple durch sein aktuelles Hardware-Design Entwicklern keine „unnötigen Hürden“ in den Weg, sondern konzentriert sich einfach auf Hardware-Design nach den eigenen Anforderungen
Außerdem wäre das Interesse, sie auf von Apple nicht vorgesehene Weise zu nutzen, kaum so groß, wenn die Hardware nicht so gut wäre
Es ist ein ziemlich großer Unterschied, ob man Standards ignoriert und das Rad besser neu erfindet, oder ob man absichtlich von Standards abweicht, um Kompatibilität zu verhindern
Entscheidend ist, ob man einfach keine Ressourcen darauf verwendet, Standardverhalten zu erhalten, oder aktiv Ressourcen dafür einsetzt, vom Standard abzuweichen; im ersten Fall persönlich finde ich, dass man das kaum vorwerfen kann
In diesem Ökosystem wird Apple sich vor allem um native App-Kompatibilität und ein vergleichbares AI-Inferenz-Erlebnis kümmern, und beides scheint gelegentlich durch gemeinsame Anstrengungen gelöst zu werden
Ansonsten bevorzugt Apple es, möglichst viel abzuschotten, und die Community fühlt sich leider stärker von der Gesamtattraktivität angezogen als von guten offenen Initiativen
Man kann beides tun
Zuerst wollte ich sagen, Alyssa solle bei Valve arbeiten und helfen, Steam unter Linux auf dem Mac zum Laufen zu bringen, aber offenbar tut sie das bereits [1]
[1] https://en.wikipedia.org/wiki/Alyssa_Rosenzweig#Career
Das wirft die ziemlich interessante Frage auf, was Valve hier plant
Es wäre schwierig, aber Steam/Proton auf dem Mac zum Laufen zu bringen, ergibt für Valve sehr viel Sinn, und wenn Leute zum Spielen Linux auf ihrem Mac booten, wäre Apple darüber vermutlich ziemlich verärgert
Die Arbeit von Alyssa R und Asahi Lina ist großartig
Wenn man mit Treiber-Code nicht vertraut ist, ist das meiste davon allerdings wirklich schwer zu verstehen, und die Hardware-Seite hat so viele Eigenheiten, dass es schön wäre, wenn sich solcher Code viel leichter schreiben ließe
Auch der Oldschool-Spieltrieb mit dem Hexenkostüm war ziemlich unterhaltsam
Ich frage mich, ob es dafür bekannte Hardware gibt
Ich habe gesucht, aber zwischen all dem Blog-Spam zu PowerPoint war es schwer, die gewünschten Ergebnisse zu finden, und Googles AI war auch keine Hilfe
Fragt sich noch jemand, wie erstaunlich viel in der Hardware fehlt und wie viel davon emuliert wird
Eigentlich kann man fast alles als Emulation betrachten
Einer der Gründe, warum GPU-Hersteller ihre Treiber nicht als Open Source veröffentlichen wollen, ist, dass ein großer Teil der geheimen Soße in der Treibersoftware über einer massiv parallelen Rechenarchitektur steckt
Geometrie-Shader gelten weithin als Fehler, der nie hätte standardisiert werden sollen, und Metal hat sie nie unterstützt, daher können sie eigentlich nur aus altem OpenGL-Code unter macOS stammen; Apple dafür zu kritisieren, dass sie das nicht in Hardware unterstützen, ist schwer
https://x.com/pointinpolygon/status/1270695113967181827
Alyssa ist beeindruckend
Ich erinnere mich an den ersten Beitrag über ihre GPU-Arbeit, und als ich danach erfuhr, dass sie damals erst 17 war, hat es mir fast den Kopf weggehauen
Schon dass überhaupt jemand so etwas geschafft hat, ist erstaunlich, aber dass es ein Teenager war, ist wirklich verblüffend
Wenn es ohnehin unmöglich ist, aktuelles OpenGL und Vulkan ohne Emulationsschicht auf Apple Silicon zu bringen, könnte man dann theoretisch eine native Metal-API für Linux bauen?
Oder steckt Metal zu tief im macOS-SDK?
MoltenVK versucht ebenfalls, dasselbe Problem zu lösen, von dem Alyssa in ihrem Vortrag gesprochen hat [1, der letzte Kommentar im Issue ist von Alyssa]
[1] https://github.com/KhronosGroup/MoltenVK/issues/1524
Das war im Grunde das Fazit von Alyssa Rosenzweigs Vortrag
Apple kennt die internen Dokumente und ist daher am besten positioniert, eine bessere Low-Level-Implementierung zu bauen
Das Haupthindernis ist derzeit die stur verfolgte Haltung, dass ein Metal-Port der einzige offiziell unterstützte Weg sei
Wenn Valve ohne Unterstützung von Apple einen Hexentrick findet, um AAA-Spiele auf dem Mac zum Laufen zu bringen, könnte das die Lage interessant verändern und Apple womöglich dazu bringen, den eigenen Ansatz zu überdenken, falls man auf der eigenen Plattform nicht in die Enge getrieben werden will
Es gibt auch DirectX-Implementierungen für Linux, und Proton funktioniert ebenfalls so
Die Frage ist nur, ob man diese API als Schicht über Vulkan baut, ob man sie wie bei MoltenVK oder dxvk vollständig clientseitig umsetzt oder ob man sie tiefer in Mesa integriert
Für den Einstieg wäre Ersteres sicher deutlich einfacher
Bei Artikeln mit solchen Überschriften bin ich inzwischen darauf konditioniert, etwas wie „stellt den Support ein und wird acqui-hired“ zu erwarten
Alyssa Rosenzweig verdient einen Turing Award
Ich habe mich immer über solche /SubscriberLink/-Links gewundert
Ist es unethisch, sie zu teilen?
Private E-Mails, Nachrichten auf Projekt-Mailinglisten und Blogposts seien allesamt in Ordnung, solange sie nicht dazu benutzt werden, den Versuch zu umgehen, neue Abonnenten zu gewinnen, und man freue sich darüber, wenn sie geteilt werden
Sie haben nur höflich darum gebeten, es nicht zu exzessiv zu verbreiten, weil ja die Seite sowie Autoren und Editoren finanziert werden müssen, und nach meinem Verständnis kommen diese Mittel nur aus Abonnements
Der Preis für ein LWN-Abo ist ziemlich erschwinglich und unterstützt die beste tiefgehende technische Berichterstattung zu Linux und verwandten Themen
Ich habe keine Verbindung zu LWN, bin nur ein zufriedener Abonnent, und ich denke, dass das Wissen aus LWN-Artikeln auch zu einem Teil zu meinem beruflichen Erfolg beigetragen hat
Die Leute müssen schließlich erst einmal von LWN erfahren, bevor sie ein Abo abschließen können
Siehe die FAQ: https://lwn.net/op/FAQ.lwn#slinks
Die Paywall von LWN ist ungewöhnlich, weil alle Inhalte nach einer Woche kostenlos freigeschaltet werden
Subscriber-Links gibt es, um dazu zu ermutigen, ein Abo abzuschließen, wenn man es sich leisten kann
Ich kann mich irren, aber für mich liest sich das so, als gäbe es womöglich eine Art Finanzierung dafür, ehemals kostenpflichtige Inhalte artikelweise freizugeben
Mich würde interessieren, ob jemand weiß, ob das tatsächlich so ist