Der technische Appell eines Anukari-Entwicklers an Apple

• Anukari, ein GPU-Echtzeit-Audiosimulator, erläutert das Problem, dass auf Apple-Silicon-macOS-Geräten keine vorhersehbare Leistung garantiert werden kann, und bittet darum, direkt mit dem Apple-Metal-Team in Kontakt gebracht zu werden
• Anukari ist ein physikbasierter Audiosynthesizer, der für jeden Audiopufferblock Hunderte von Objekten auf der GPU integrieren muss und vollständig von der GPU-ALU-Leistung abhängt
• Da die automatische Energie-/Leistungsregelung von macOS diese spezielle Audio-Workload nicht gut erkennt, bleibt der GPU-Takt niedrig, was zu Leistungseinbußen und Aussetzern führt
• Um das zu umgehen, wurde mit der Strategie „waste makes haste“ ein Spin-Kernel eingeführt, der eine künstliche Last erzeugt und so die GPU täuscht, doch auf leistungsstarken Macs seit dem M1 steigt die Wahrscheinlichkeit des Scheiterns
• Als Lösungen werden unter anderem die Einführung einer Echtzeiterkennung für GPU-Befehlsqueues oder die Erweiterung des Audio-Workgroup-Konzepts auf Metal vorgeschlagen

---

Was ist Anukari?

• Anukari ist ein 3D-Echtzeit-Audiosynthesizer auf physikalischer Basis, der Audio erzeugt, indem große Feder-Masse-Modelle auf der GPU berechnet werden
• Es wird in Audio-Workstations (DAWs) als AudioUnit/VST3 verwendet und fordert Berechnungen von der GPU in Einheiten von Audiopuffern an
• Die Berechnung ist eher rechen- als speicherlastig (= ALU-zentriert) und nutzt den threadgroup memory der GPU, um Hochgeschwindigkeitsverarbeitung auf L1-Cache-Niveau zu erreichen

Das Wesen des Leistungsproblems

• macOS regelt den GPU-Takt automatisch mit Fokus auf Energieeffizienz und senkt ihn, wenn eine geringe GPU-Last erkannt wird
• Anukari wiederholt kurze, hochdichte Echtzeitaufgaben, wodurch macOS die GPU-Last nicht korrekt erkennt
• Dadurch lässt sich die zur Einhaltung der Echtzeitbedingungen erforderliche Leistung nicht sicherstellen

Nachweise und Tests

• Mit dem Metal Profiler in Apple Xcode wurden Taktunterschiede je nach Leistungszustand direkt überprüft
• Im Zustand Maximum performance läuft alles reibungslos, im Zustand Minimum kommt es zu Audioaussetzern

Die Strategie „waste makes haste“

• Um den GPU-Takt zwangsweise anzuheben, führt Anukari parallel GPU-Arbeit zur Erzeugung einer Spin-Loop-Last aus
• Diese Strategie ist auf dem M1 wirksam, kann aber bei Pro-/Max-Chips scheitern, weil die Last stattdessen auf andere GPU-Kerne verteilt wird

Vorgeschlagene Lösungen

1. Audio Workgroup bis zur GPU erweitern, damit die Workload als echtzeitkritisch erkannt wird
2. Der Metal API ein Flag für Echtzeit-Sensitivität hinzufügen
3. (Hoffnungsvoll) Hinweise erbitten, falls es bereits eine bestehende Lösung gibt

Prüfung weiterer Alternativen und Grenzen

• Game Mode arbeitet auf Basis des Gesamtprozesses und ist daher für Anukari in Plugin-Form nicht nutzbar
• Unter Windows gibt es dieses Problem nicht, vermutlich wegen lockerer Taktsteuerung oder möglicher Kontrolle über die Einstellungen
• Multi-Kernel-Ausführung als Hedging-Ansatz ist wegen höherer Audiolatenz und Problemen bei der Zustandssynchronisation ungeeignet
• Der GPU-Code ist bereits bis ans Limit optimiert (FP16-Nutzung, SIMD-Gruppenausrichtung, ALU-Optimierung usw.)

Warum die GPU und nicht die CPU?

• Anukari führt physikalische Berechnungen für 768 bis 1024 Objekte 48.000-mal pro Sekunde aus und unterstützt bis zu 16-fache Polyphonie
• Die CPU kann das weder bei der Rechenmenge noch bei der Parallelität bewältigen
• Die Fähigkeiten der GPU bei ALU, L1-Cache-Kontrolle und paralleler Steuerung über threadgroup_barrier sind absolut notwendig

Warum sollte Apple sich darum kümmern?

• Anukari ist zwar ein Nischenprodukt eines kleinen Startups, hat aber eine leidenschaftliche Nutzerschaft und weckt Interesse bekannter Künstler
• Apple Silicon verfügt über genügend Leistung für diese Workload, doch eine Änderung der Taktregelungsrichtlinie allein könnte das Problem lösen

Warum ist eine GPU-Audio-API keine Lösung?

• Anukari ist kein klassisches DSP, sondern ein Integrator numerischer Differentialgleichungen, also eher mit einer Game-Physics-Engine vergleichbar; deshalb passt es nicht zum Abstraktionsniveau von GPU Audio
• Es verwendet die Metal API direkt, und extreme, domänenspezifische Optimierung ist unverzichtbar

Zusammenfassung der Bitte: Es wird auf eine Antwort von Apple-Ingenieuren gewartet, die für GPU-Audio im Metal API oder in der macOS-Leistungsregelung eine Erkennung von Echtzeitverarbeitung hinzufügen können

[GN⁺]

Hacker-News-Kommentar

• Hallo zusammen, ich hatte ein sehr produktives Gespräch mit der richtigen Person aus dem Metal-Team. Danke, dass ihr geholfen habt, Apples Aufmerksamkeit zu gewinnen. Ich hätte nie erwartet, so viel Unterstützung zu bekommen.

  • Manche von euch haben vielleicht den Show-HN-Post zu Anukari gesehen.
  • In diesem Thread kam das Thema macOS-Performance auf. Grundsätzlich läuft Anukari auf Apple Silicon, insbesondere auf der M1-Basiskonfiguration, größtenteils gut. Alle Tests wurden auf einem Basis-M1 durchgeführt, und es funktioniert hervorragend. Die Hardware ist erstaunlich.
  • Um das zum Laufen zu bringen, musste ich jedoch einen ungewöhnlichen Workaround implementieren, damit macOS die GPU-Taktrate erhöht und die Audioverarbeitung schnell genug wird. Die üblichen Heuristiken von macOS für GPU-Leistungszustände verstehen die ungewöhnliche Workload von Anukari nicht.
  • Jedenfalls hatte ich nun Zeit, die gesamte Situation ausführlich zu dokumentieren, damit ich um Hilfe bitten kann, Kontakt mit der richtigen Person bei Apple aufzunehmen, vermutlich jemandem, der an der Metal API arbeitet.
  • Ich bitte um Hilfe :)

• Ich bin neugierig auf die Herkunft des Namens Anukari.

• Ich habe bei zwei bekannten Unternehmen gearbeitet, die sehr bekannte Apps im Apple App Store haben.

  • Die Teams bei Apple, mit denen wir gesprochen haben, interessierten sich überhaupt nicht für unsere Probleme. Stattdessen wurden wir oft in ihre Büros eingeladen, um die neuesten Features zu besprechen, die sie auf der WWDC vorstellen wollten. So begann und endete die Zusammenarbeit mit ihnen immer. Wir mussten Support-Tickets verschwenden, nur um Einblicke zu bekommen, warum ihre fehlerhafte Software nicht funktionierte.
  • Apples Developer Relations besteht nicht aus ernsthaften Leuten.

• Der Metal-Profiler hat eine sehr nützliche Funktion: Während man eine Anwendung profiliert, kann man den Metal-"Leistungszustand" auswählen. Außerhalb des Profilers lässt sich das nicht konfigurieren.

  • Wahrscheinlich gibt es dafür eine private API. Vielleicht wäre der Weg über Reverse Engineering einfacher. Falls dafür keine besonderen Berechtigungen nötig sind.

• Das Problem dabei, für dieses Thema eine API offenzulegen, ist, dass zu viele Entwickler dann ständig den höchsten Leistungszustand erzwingen würden. Ich weiß nicht, ob es einen guten Weg gibt, das zu verhindern und die API trotzdem beizubehalten.

• Der beste Weg, dieses Problem zu lösen:

  • Über WWDC-Videos den Engineer finden, der das Problem am besten kennt
  • Ihm direkt in diesem Format eine E-Mail schicken: [e-mail] (Michael Thomson)

• Verpasst nicht den Link, der im vorletzten Absatz eingestreut ist. Er verweist auf eine Demo von Mick Gordon. @anukarimusic antwortet darauf.

  • Schon am zweiten Tag hat es sämtliche Demos, die ich bis dahin gemacht hatte, komplett zerstört, und ich nutze es seitdem jeden Tag.

• Zusätzlich sollte Anukari ein Mick-Gordon-Sound-Pack veröffentlichen und die Einnahmen mit ihm teilen. Der Mann erschafft unglaubliche Dinge. Seine Demo ist großartig. Mit Künstlern zusammenzuarbeiten, wenn man ein mächtiges Werkzeug hat, ist gutes Business und gut für die Welt. Falls ihr Mick Gordon mögt. Ich mag ihn.

• Ich brauche diese App nicht, aber sie ist wirklich cool. Solche Apps bringen den "Spaß" zurück ins Computing. Nicht, dass es heute keinen Spaß gäbe, aber sie erinnert an früher, als mehr grafische und experimentelle Programme unterwegs waren. Sogar an die Demoszene.