- Honeykrisp ist noch nicht für Endnutzer veröffentlicht; derzeit ist nur der source code für Entwickler verfügbar
- Honeykrisp für den M1 ist die erste konforme Vulkan-Implementierung auf Apple-Hardware und implementiert ohne
portabilityWaiver die vollständige Vulkan-1.3-Spezifikation - Honeykrisp basiert nicht auf der bisherigen Vulkan-Arbeit für den M1, sondern auf dem Open-Source-NVK driver für NVIDIA-GPUs; der Start erfolgte, indem M1-Code hinzugefügt und NVIDIA-spezifische Teile entfernt wurden
- Das Endergebnis der Vulkan 1.3 conformance test suite wurde mit Pass 686930, Fail 0 protokolliert
- Die Implementierung geht in Richtung full dynamic state und
EXT_shader_object: Alle Zustände werden als dynamische Zustände behandelt, und Code zum Bauen, Kompilieren und Cachen von Prolog und Epilog wurde hinzugefügt - Für zero-copy rendering wurde
EXT_image_drm_format_modifierimplementiert - Für Direct3D-Kompatibilität wird das von DXVK und vkd3d-proton benötigte
EXT_custom_border_colorunterstützt; die Korrektur der border colour wird emuliert, indem Code in den Shader injiziert wird - Die Emulation von custom border colour wird als „simple, correct, and slow“ beschrieben; später soll sie mit driver tricks beschleunigt werden
- Als Nächstes sollen die von DXVK und vkd3d-proton für Direct3D-Layering benötigten Punkte implementiert werden; als Beispiel wird transform feedback genannt
1 Kommentare
Meinungen auf Hacker News
Wirklich beeindruckende Arbeit, und sie zeigt sehr gut den Wert von offenen Komponenten, die geteilt und iterativ verbessert werden.
Ich frage mich, wie lange es dauern wird, bis Proton portiert ist; selbst wenn die Vulkan-Implementierung optimal ist, dürften viele Spiele wegen der Unterschiede in der GPU-Architektur, des ARM-Übersetzungs-Overheads und der Kosten von Proton selbst schlecht performen.
Trotzdem bin ich optimistisch, dass künftig mehr Spiele Unified Memory und ARM ins Visier nehmen werden, wenn SoCs wie Snapdragon auf dem Desktop üblicher werden.
Es zeigt, was für ein großer Fehler es war, dass Apple Vulkan ignoriert hat — aber ich glaube nicht, dass sie das je zugeben werden, bevor es zu spät ist.
Alyssa arbeitet derzeit außerdem an Performance-Verbesserungen für FEX.
Ich frage mich, ob diese Arbeit, Vulkan zu Linux hinzuzufügen und DirectX unter Asahi Linux zu übersetzen, Apples Traum beeinflussen wird, AAA-Spiele auf Apple Silicon zu holen.
Apple dürfte wollen, dass AAA-Entwickler ihre Spiele auf Metal portieren, damit sie mit einer Codebasis auf iPhone, iPad, Mac und Vision Pro laufen.
Vielleicht installieren Mac-Gamer irgendwann Asahi Linux, um AAA-PC-Titel zu spielen.
Was sie wirklich wollen, sind AAA-Spiele im App Store, nicht auf Steam oder im Epic Games Store; deshalb ist GPTK meiner Ansicht nach nur halbherzig und die Lizenz verhindert zudem, dass Valve es direkt in Steam integriert.
Ich habe Diablo II Resurrected mit Whiskey auf einem M1 ausprobiert, und es war ziemlich beeindruckend, dass ein natives Windows-Spiel einfach so läuft. Im Moment verhindert nur ein dummes Update des Blizzard-Launchers durch einen Crash den Spielstart.
Es ist zwar ein altes DX9-Spiel, aber auch EverQuest II lief auf einem M1 Mac mini in 1440p sehr gut; Asahi Linux könnte auch bei älteren 32-Bit-Titeln wie Guild Wars helfen.
Wer Vulkan 1.3 nicht gut kennt, sich aber für Low-Level-Grafik-API-Arbeit interessiert, sollte es sich unbedingt ansehen. Es ist ein völlig anderes Niveau als Vulkan 1.0 und verändert die Spielregeln.
Sobald man die Anfangshürde genommen hat, macht die Arbeit Spaß; durch all den dynamischen Zustand und den Wegfall der vorab festgelegten Render-Pass-Konfiguration ist es viel leichter zu handhaben. Es ist sogar einfacher geworden als OpenGL, das ich seit 20 Jahren nutze, und Grafikprogrammierung macht wieder Spaß.
Mit aktuellen Treibern kann man die meisten Funktionen auf praktisch allen Desktop-Plattformen mit GPUs der letzten etwa zehn Jahre nutzen.
Leider gibt es kein Framework mit „vernünftigen Defaults“, mit dem man sofort loslegen kann, aber es gibt viele nützliche Helper-Libraries für verschiedene Sprachen.
Für den Umstieg auf Vulkan hatte ich nie Zeit, aber am Ende scheint es vor allem darum zu gehen, die Hürde bei Initialisierung und Setup zu nehmen. Danach werde ich wohl nicht mehr zu OpenGL zurückkehren.
Dieser Artikel motiviert mich ein wenig, es tatsächlich auszuprobieren.
Bei OpenGL war das ursprünglich auch so, vielleicht ist es also gar nicht so anders — aber man hat schon das Gefühl, dass Khronos das wirklich „gut“ hinbekommen hat.
Wegen der ES-3.2-Unterstützung habe ich gerade aktualisiert und bin schon jetzt beeindruckt. Mein M1 fühlt sich an, als wäre er für Asahi gemacht.
Ehrlich gesagt ist es sehr wahrscheinlich, dass macOS gerade nur installiert ist oder ich es einmal versehentlich gebootet habe. Schön, dass es solche detaillierten Updates gibt.
Ich frage mich, ob irgendein Browser Zero-Copy-Rendering unterstützt, oder ob immer noch mehrere Compositor-Schichten dazwischenliegen. Ich erinnere mich auch, dass WebGL2-Transform-Feedback blockiert war, weil es Readbacks ausgelöst hat.
Wenn etwas crasht, dachte ich immer, dass es auf keinen Fall ein Compiler-Bug sein kann — aber am 16. April war es tatsächlich ein Compiler-Bug.
Ich kann mit Überzeugung sagen, dass mir so etwas in meiner Karriere noch nie passiert ist, aber je niedriger die Abstraktionsebene wird, desto weniger selten ist es vielleicht.
Es sei denn, man ist Low-Level-Kernel-Entwickler — dann kann beides stimmen.
Spaß beiseite: In der Praxis ist es viel häufiger etwas anderes, aber es kommt definitiv vor.
Wenn es ein in Arbeit befindlicher Compiler ist, also die eigene Software, die man gerade testet, passt die Maxime „Es kann kein Compiler-Bug sein“ nicht so gut.
Im Shader steckt eine ungewöhnliche Struktur:
if (condition) { while (true) { } }conditionist immer falsch, aber der Compiler weiß das nicht.Ich frage mich, welchen Zweck diese Struktur hat – außer als Giftpille, um Autoren standardkonformer Shader-Compiler zu quälen.
Der Code selbst ist in der Praxis vielleicht nicht nützlich, aber wenn ein Teil eines Shaders sich unter bestimmten Umständen funktional in so eine Form vereinfachen lässt, muss der Compiler damit korrekt umgehen.
Falls das Konzept nicht vertraut ist, siehe diese Funktionen in C++, LLVM und Rust:
https://en.cppreference.com/w/cpp/utility/unreachable
https://en.cppreference.com/w/cpp/language/attributes/assume
https://en.cppreference.com/w/cpp/memory/assume_aligned
https://llvm.org/docs/LangRef.html#unreachable-instruction
https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic
https://doc.rust-lang.org/std/hint/fn.unreachable_unchecked....
https://doc.rust-lang.org/std/hint/fn.assert_unchecked.html
Eine Endlosschleife ist praktisch eine unerreichbare Anweisung, und eine unerreichbare Anweisung nach einer Verzweigung wird praktisch zu einer assume-Anweisung.
Ich frage mich, ob man das in einer VM nutzen kann. Ich entwickle auf macOS und bin im Großen und Ganzen zufrieden, lasse aber zu Testzwecken ein Ubuntu-Image in VMware laufen.
Ich entwickle eine 3D-Grafik-App und weiß nicht genau, wie weit das Passthrough von VMware geht. Ich frage mich, ob die Apple-Silicon-GPU in der VM virtualisiert wird und ob die Grafikleistung besser werden könnte, wenn man diese Distribution ausführt.
Kann jemand erklären, in welchem Verhältnis das zu MoltenVK steht? Da es ein nativer Treiber ist, braucht man MoltenVK dann nicht mehr?
Asahi Linux ist eine in Entwicklung befindliche Distribution, die Linux auf Prozessoren der Apple-M-Serie kompatibel machen soll, und in diesem Beitrag geht es darum, GPU-beschleunigtes Vulkan unter Asahi zum Laufen zu bringen.
So steht es auch im Artikel. Das kann nicht direkt unter OS X laufen und macht MoltenVK daher nicht überflüssig.