OBS Studio führt einen neuen Renderer ein: Wie OBS Metal übernommen hat

• Ab OBS Studio 32.0.0 für macOS wurde experimentell ein Apple-Metal-basierter Renderer-Backend hinzugefügt, mit dem Ziel, Leistung und Effizienz gegenüber dem bisherigen OpenGL zu verbessern
• Metal ist eine API, die für geringen Overhead und moderne GPU-Architekturen entwickelt wurde; um sie zu unterstützen, musste OBS die Art der GPU-Interaktion grundlegend überarbeiten
• Da der bisherige Renderer von OBS auf eine Direct3D-zentrierte Struktur ausgerichtet war, erforderte das Metal-Backend umfangreiche Kompatibilitätsarbeiten bei Shader-Umwandlung, Ressourcenverwaltung und mehr
• Insbesondere umfasst es eine komplexe Implementierung, die HLSL-Shader in Echtzeit in MSL umwandelt und das Verhalten von Direct3D-map/unmap innerhalb von Metal simuliert
• Das Metal-Backend befindet sich noch im „experimentellen“ Stadium, markiert aber mit schnellerer Leistung als OpenGL, einer sicheren Swift-basierten Code-Struktur und EDR-Preview-Unterstützung einen wichtigen Wendepunkt für die macOS-Entwicklungsumgebung

---

Überblick über die Einführung des Metal-Renderers

• Seit OBS Studio 32.0.0 wird unter macOS experimentell ein auf der Metal-Grafik-API basierender Renderer angeboten
  • Als Alternative zum bisherigen OpenGL-Backend soll er Leistung und Effizienz verbessern
  • Metal ist eine moderne API, die die Interaktion mit der GPU grundlegend verändert; OBS hat seine interne Struktur entsprechend angepasst
• Das Metal-Backend ist als „Experimental“ gekennzeichnet und weist einige bekannte Probleme und Einschränkungen auf
  • Der OpenGL-Renderer bleibt weiterhin die Voreinstellung, Nutzer können die Metal-Version aber direkt ausprobieren
  • Entwickler mit Metal-Erfahrung werden ausdrücklich um Feedback und Pull Requests gebeten

Hintergrund und Designphilosophie von Metal

• Apple stellte Metal 2014 zunächst für das iPhone vor und erweiterte es 2015 auf den Mac
  • Damals war Metal eine der ersten Grafikschnittstellen der nächsten Generation, die Intel-, AMD- und NVIDIA-GPUs unterstützte
• Metal kombiniert Konzepte aus AMDs Mantle sowie bestehendem OpenGL und Direct3D, wurde aber ohne Legacy-Elemente neu entworfen
  • Als Objective-C- und Swift-basierte API bietet es iOS- und macOS-Entwicklern eine vertraute Struktur
  • In Xcode werden Shader-Debugging und GPU-Analysefunktionen integriert unterstützt

Unterschiede im API-Design und die Anpassung des OBS-Renderers

• Bei herkömmlichem OpenGL und Direct3D wurden Ressourcenverwaltung und Synchronisierung automatisch von der API erledigt,
  moderne APIs wie Metal verlangen dies jedoch direkt vom Entwickler
• Neue APIs behandeln die GPU als Verarbeitungseinheit auf Basis paralleler Command Queues und verwalten Pipeline-Zustände als unveränderliche Objekte
• Der bisherige Renderer von OBS war auf die Arbeitsweise von Direct3D ausgelegt,
  daher wurde für die Metal-Unterstützung eine Kompatibilitätsschicht auf Backend-Ebene implementiert

Struktur des OBS-Renderers und Kompatibilitätsprobleme mit Metal

• OBS verwendet je nach Plattform die Backends Direct3D (Windows) und OpenGL (Linux/macOS)
  • Der Renderer-Kern ist zwar API-unabhängig, enthält aber einige Direct3D-zentrierte Annahmen
• Wichtige Einschränkungen
  • Shader sind auf HLSL-Basis geschrieben und müssen zur Laufzeit umgewandelt werden
  • Verwendung globaler Variablen, Annahmen über sequentielle Ausführung und Direct3D-artige Texturverarbeitung
  • Das Preview-Rendering hängt vom „discard model“ von DXGI ab

Shader-Umwandlung (Transpiling Shaders)

• Die Effektdateien von OBS sind in HLSL geschrieben und werden für die jeweilige API konvertiert
  • Für die Metal-Unterstützung wurde ein HLSL→MSL-Konverter hinzugefügt
• Wichtige Unterschiede
  • MSL verlangt getrennte Ein-/Ausgabe-Structs und unterstützt keine globalen Variablen
  • Alle Uniform-Daten werden über GPU-Buffer übergeben und müssen explizit als Funktionsargumente übergeben werden
  • Bei Funktionsaufrufen werden Typübereinstimmung und Signaturprüfung strikt erzwungen
• Der Konverter schreibt Shader-Code zur Laufzeit teilweise um, damit er den MSL-Regeln entspricht
  • Beispielsweise werden HLSL-uniform-Variablen in MSL-constant buffer umgewandelt
  • Auch Typumwandlungslogik wie int3 → uint2 + uint wird automatisch eingefügt

Simulation des Direct3D-Verhaltens

• Der OBS-Renderer ist unter der Annahme des Direct3D-map/unmap-Verhaltens entworfen
  • Da Metal diese automatische Synchronisierung nicht bereitstellt, wird sie im Backend direkt implementiert
• Verarbeitungsweise des Metal-Backends
  • Beim Schreiben wird ein GPU-Buffer erzeugt und direkt mit dem CPU-Speicher geteilt
  • Bei unmap wird ein GPU-Blit-Befehl eingeplant, um in die Textur zu kopieren
  • Beim Lesen wird der GPU-Buffer ebenfalls geteilt, Kollisionen werden jedoch durch explizite Synchronisierung vermieden
• Damit werden die Ressourcenverfolgung und Synchronisierungsfunktionen von Direct3D innerhalb von Metal nachgebildet

Probleme beim Preview-Rendering und temporäre Lösung

• Anders als DXGI kann die Metal Layer unter macOS nicht beliebig Frames durch die App anzeigen lassen
  • Das System steuert die Framerate abhängig von ProMotion und Stromsparmodus
• Da die eigene Render-Schleife von OBS nicht mit dem Anzeigezyklus von macOS übereinstimmt, kommt es zu Preview-Verzögerungen
• Temporäre Lösung
  • OBS rendert zunächst in eine virtuelle Textur, die anschließend von einem separaten Thread auf die Screen Surface kopiert wird
  • Dabei ist GPU-Synchronisierung erforderlich, und es kann zu Frame-Abweichungen kommen
• Seit macOS 14 werden durch fensterweise unabhängige Timer zusätzliche Herausforderungen erwartet

Die versteckten Kosten moderner Grafik-APIs

• Die Entwicklung des Metal-Backends erforderte mehrere Monate Forschung und iteratives Design
  • Das bestätigt, warum es bei Übergängen wie OpenGL→Vulkan oder D3D11→D3D12 zu Leistungseinbußen kommen kann
• Bei modernen APIs muss die Anwendung Aufgaben selbst übernehmen, die früher der Treiber erledigte
  • Dafür ist ein tiefes Verständnis der GPU-Arbeitsweise und der Befehlsabhängigkeiten nötig
• Das Metal-Backend führt zwar teilweise wieder Overhead ein, bietet aber folgende Vorteile
  • Leistung auf dem Niveau von OpenGL oder besser
  • Leistungsstarke Analysefunktionen wie Shader- und Textur-Debugging
  • Sichere Swift-basierte Code-Struktur
  • EDR-Preview-Unterstützung für hochwertige Videoverarbeitung
• Durch die in Xcode integrierten Analysefunktionen verbessert sich die Effizienz bei der Wartung von OBS unter macOS,
  zugleich wird Entwickler-Feedback für einen künftigen Wechsel von Metal zum Standard-Renderer erbeten

[GN⁺]

Hacker-News-Kommentare

• Wirklich ein sehr guter Artikel. Die Erklärung der Shader-Verarbeitung war besonders beeindruckend.
  Ich habe mich gefragt, ob man für Shader von Drittanbieter-Plugins wirklich so einen Prozess durchlaufen muss, damit sie auf mehreren Backends laufen, oder ob das eher wegen der Abwärtskompatibilität so gelöst wurde.
  Externen Entwicklern zu sagen: „Schreibt alles einfach in jeder Shader-Sprache separat“, wäre aus Sicht des Core-Teams zwar bequem, ist in der Praxis aber nicht wünschenswert.

  • Die meisten Game-Engines betreiben schon seit über 10 Jahren Shader-Transpiling.
    Alle halten es für ineffizient, aber realistisch gesehen gibt es keine Alternative.

• Der Artikeltitel versteckt den eigentlichen Kern.
  Etwas wie „OBS Studio führt einen neuen Renderer ein: der Weg zur Einführung von Metal“ wäre passender.

  • Allerdings ist das ein Mac-spezifisches Thema, daher wissen Leute ohne Mac womöglich gar nicht, was Metal ist.

• Das zeigt ziemlich deutlich den Preis dafür, dass Apple zum Schutz seines eigenen Ökosystems eine API statt Vulkan entwickelt hat.
  OBS Studio hat im März 2020 mit Version 25.0 Vulkan-Unterstützung hinzugefügt. Das ist inzwischen schon fünfeinhalb Jahre her.

  • Vulkan wird auf Konsolen außer der Switch nicht unterstützt. Auch unter Windows ist es keine offiziell integrierte Unterstützung, sondern funktioniert über Treiber-Stacks der GPU-Hersteller.
    In Embedded-Umgebungen dominiert weiterhin OpenGL ES.
  • Metal kam vor Vulkan heraus, und manche halten Metal für einfacher zu benutzen.
  • Allerdings haben auch Microsoft mit DirectX und die meisten Konsolenhersteller solche Strategien mit eigenen Ökosystemen verfolgt.

• Ich bin kein Experte für das Thema. Ich habe vielleicht 5 % von dem verstanden, was ich gelesen habe, aber ich wünschte, es gäbe mehr Artikel mit solchen technischen Details.
  Reine Ankündigungstexte wirken wie Marketing.

• Persönlich freue ich mich mehr auf die kommende VST3-Unterstützung, aber auch diese Nachricht ist willkommen.
  Es ist jedenfalls deutlich einfacher, als Hardware-Encoding auf einem Rockchip-SoC einzurichten.

• Ich fand die Erklärung interessant, dass Metal den objektorientierten Ansatz von Direct3D noch einen Schritt weitergeführt und mit dem „geschwätzigen“ API-Design von Objective-C und Swift kombiniert hat.
  Überraschend ist, dass eine 3D-Grafik-API auf OS-Ebene überhaupt auf diese Weise auf Basis dynamischer Sprachen gestaltet werden konnte.
  Ich vermute, das ist den Optimierungen von objc_msgSend() zu verdanken.

  • Moderne Grafik-APIs verwenden viel weniger Aufrufe als OpenGL.
    Vulkan/Metal/DirectX 12 übergeben viele Befehle gesammelt in Command Buffers statt per Einzelaufruf.
  • Eigentlich war so ein Ansatz schon lange möglich.
    Anfang der 2000er gab es Bücher über Direct3D mit C#, die das Bild davon verändert haben, ob High-Performance-Grafik auch mit GC-Sprachen möglich ist.
    Der Kern ist eine Batch-Verarbeitungsstruktur, die auf vorallokierte Buffer verweist und so Runtime-Overhead minimiert.
  • Dazu passend: LLVM Review D69991
  • Allerdings wird Objective-C in den unteren Ebenen des OS in der Praxis kaum verwendet.
    Seit Cocoa wird das meiste in einem eingeschränkten C++-Subset geschrieben, etwa IOKit.
  • Metal bietet zwar eine Obj-C-API, aber die Implementierung selbst ist in C++ geschrieben.

• Ich hoffe, dass moderne GPU-APIs nur eine Übergangsphase hin zu etwas Einfacherem sind.
  OpenGL ist eine Hassliebe, aber nachdem ich die neuen APIs benutzt habe, vermisse ich fast schon wieder die Einfachheit von OpenGL.

• Ich frage mich, ob Metal die Leistung auch auf älteren Intel-Macs verbessert oder ob die Optimierungen nur für die M-Serie gedacht sind.

  • Dem Artikel zufolge wird das „Metal-Backend nur auf Apple Silicon unterstützt und GPU und CPU teilen sich den Speicher“.
    Metal 3 wird aber weiterhin auch auf mehreren Intel-Macs unterstützt, daher ist unklar, warum es eingeschränkt wurde.

• Ich habe darüber nachgedacht, mit einem Mac Mini ein Streaming-Setup aufzubauen.
  Ich frage mich, ob die Leistungsverbesserungen dafür jetzt ausreichen.

  • Das hängt vom Streaming-Inhalt ab.
    Für 2D-Arcade-Spiele oder Entwicklungsbildschirme ist das kein Problem.
    Bei aktuellen AAA-Spielen ist es besser, das PC-Bild über eine Capture Card einzuspeisen.
    Um 2017 herum war Streaming unter macOS schwierig, aber heute reicht ein Gerät der M-Serie völlig aus.
  • Für das Streamen von Kamerabildern ist ein Mac Mini der M-Serie schon jetzt schnell genug.
    Mit dieser Verbesserung dürfte vor allem die Effizienz weiter steigen.

• Ich wünschte, Apple würde mehr Ressourcen investieren, um die externen Erfolgsgeschichten von Metal zu vermehren.
  Außerhalb von Apple selbst war Metal bisher noch kein großer Erfolg.

  • Blender wäre zum Beispiel so ein guter Fall.