3 Jahre Metal - Roblox-Blog

Vor drei Jahren haben wir unseren Renderer auf Metal portiert. Es dauerte nicht lange, es war großartig und es funktionierte großartig auf iOS. Also haben wir einen Artikel geschrieben, in dem wir erklären, wie wir unsere Entscheidung getroffen haben und wie sie ausgegangen ist (Spoiler: wirklich gut!). Der größte Teil dieser ursprünglichen Retrospektive gilt immer noch, aber heute ist Metal in besserer Form als je zuvor – also haben wir uns entschieden, es mit unserem Dreijahres-Update neu zu veröffentlichen.

Gehen wir also in der Zeit zurück, stellen wir uns vor, es wäre Dezember 2016 und wir hätten gerade eine Version unseres Metal-Renderers für iOS veröffentlicht.

Warum das Metall?

Als Apple 2014 auf der WWDC Metal ankündigte, war meine erste Reaktion, es zu ignorieren. Es war nur auf der neuesten Hardware verfügbar, die die meisten unserer Benutzer nicht hatten, und obwohl Apple sagte, dass es Probleme mit der CPU-Leistung behebt, würde die Optimierung für den kleineren Markt bedeuten, dass sich die Kluft zwischen den schnellsten und langsamsten Geräten noch weiter vergrößern würde. Zu dieser Zeit liefen wir OpenGL ES 2 nur auf Apple und begannen auch mit der Portierung auf Android.

Spulen wir zweieinhalb Jahre vor, so sieht der Metallmarktanteil für unsere Benutzer aus:

Es ist viel attraktiver als zuvor. Es stimmt immer noch, dass die Metal-Implementierung älteren Geräten nicht hilft, aber der GL-Markt auf iOS schrumpft weiter, und die Inhalte, die wir auf diesen älteren Geräten ausführen, unterscheiden sich oft von den Inhalten, die auf neueren Geräten ausgeführt werden, daher ist es sinnvoll, dies zu tun Bemühen Sie sich, es schneller zu machen. Da Ihr iOS-Metal-Code auf dem Mac mit sehr geringen Änderungen funktioniert, ist es möglicherweise eine gute Idee, ihn auch auf dem Mac zu verwenden, selbst wenn Sie sich auf Mobilgeräte konzentrieren (wir liefern derzeit nur Metal-Versionen für iOS).

Ich denke, es lohnt sich, den Marktanteil etwas genauer zu analysieren. Unter iOS unterstützen wir Metal für iOS 8.3+; Obwohl einige Benutzer Metal aufgrund von Einschränkungen der Betriebssystemversion nicht ausführen können, verwenden die meisten der 25 %, die noch GL ausführen, nur ältere Geräte mit SGX-Hardware. Sie haben auch keine OpenGL ES 3-Funktionen, und wir betreiben dort nur einen Low-End-Rendering-Pfad (obwohl wir es lieben, dass alle Geräte auf Metal gehen – zum Glück wird die GL/Metal-Aufteilung nicht nur besser). Auf dem Mac ist die Metal-API neuer und das Betriebssystem spielt eine ziemlich große Rolle - Sie müssen OSX 10.11+ verwenden, um Metal zu verwenden, und die Hälfte unserer Benutzer hat nur ein veraltetes Betriebssystem - das ist weniger Hardware als Software (95 % unserer Mac-Benutzer verwenden OpenGL 3.2+).

Angesichts des Marktanteils haben wir also immer noch Optionen, die keine Portierung auf Metal beinhalten. Eine davon ist, einfach MoltenGL zu verwenden, das den OpenGL-Code verwenden würde, den wir bereits haben, der aber schneller sein soll; eine andere ist die Portierung auf Vulkan (für eine bessere Leistung auf PC und möglicherweise Android) und die Verwendung von MoltenVK. Ich habe MoltenGL kurz evaluiert und war von den Ergebnissen nicht besonders begeistert - es hat einige Mühe gekostet, unseren Code zum Laufen zu bringen, und obwohl die Leistung im Vergleich zu Standard-OpenGL etwas besser war, hatte ich auf mehr gehofft. Was MoltenVK angeht, denke ich, dass es falsch ist, zu versuchen, eine Low-Level-API als Schicht über einer anderen zu implementieren – Sie riskieren eine Impedanz-Fehlanpassung, die zu einer suboptimalen Leistung führt – vielleicht ist es besser als die High-Level-API API, die Sie zuvor verwendet haben, aber es ist unwahrscheinlich, dass sie so schnell wie möglich ist, deshalb wählen Sie zuerst eine Low-Level-API! Ein weiterer wichtiger Aspekt ist, dass die Metal-Implementierung viel einfacher ist als Vulkan - dazu später mehr - also würde ich in gewisser Weise einen Metal -> Vulkan-Wrapper anstelle eines Vulkan -> Metal bevorzugen.

Es sollte auch beachtet werden, dass es anscheinend unter iOS 10 auf den neuesten iPhones keinen GL-Treiber gibt – GL ist auf Metal implementiert. Das bedeutet, dass die Verwendung von OpenGL Ihnen nur ein wenig Entwicklungsaufwand erspart - nicht so viel, wenn man bedenkt, dass das Versprechen "Einmal schreiben, überall ausführen", dass OpenGL auf Mobilgeräten nicht wirklich funktioniert.

Portage

Insgesamt war der Anschluss an Metal ein Kinderspiel. Wir haben viel Erfahrung mit verschiedenen Grafik-APIs, von High-Level-APIs wie Direct3D 9/11 bis zu Low-Level-APIs wie PS4 GNM. Dies bietet den einzigartigen Vorteil, dass eine API wie Metal bequem verwendet werden kann, die gleichzeitig auf einem relativ hohen Niveau ist, aber auch einige Aufgaben wie die CPU-GPU-Synchronisierung dem Anwendungsentwickler überlässt.

Die einzige Hürde war wirklich das Kompilieren unserer Shader – als das erledigt war und es an der Zeit war, den Code zu schreiben, stellte sich heraus, dass die API so einfach und selbsterklärend ist, dass sich der Code praktisch von selbst schrieb. Ich habe den Port, der die meisten Dinge suboptimal gerendert hat, in etwa 10 Stunden an einem einzigen Tag bekommen und zwei weitere Wochen damit verbracht, den Code zu bereinigen, Validierungsprobleme zu beheben, die Profilerstellung zu beheben und zu optimieren und allgemein zu polieren. Eine API-Implementierung in dieser Zeit zu bekommen, sagt viel über die Qualität der API und des Toolsets aus. Ich glaube, es gibt mehrere Aspekte, die dazu beitragen:

• Sie können den Code inkrementell entwickeln, mit gutem Feedback bei jedem Schritt. Unser Code begann damit, alle CPU-GPU-Synchronisierungen zu ignorieren, war in einigen Teilen der Zustandskonfiguration wirklich suboptimal, verwendete die integrierte Referenzverfolgung für Ressourcen und führte niemals CPU und GPU parallel aus, um Erfahrungsprobleme zu vermeiden. Die Optimierungs-/Politurphase wandelte das dann in etwas um, das wir versenden konnten, ohne dabei die Renderbarkeit zu verlieren.
• Die Tools sind für Sie da, sie funktionieren und sie funktionieren gut. Das ist keine große Überraschung für Leute, die an Direct3D 11 gewöhnt sind – aber dies ist das erste Mal, dass ich auf Mobilgeräten einen CPU-Profiler, einen GPU-Profiler, einen GPU-Debugger und eine GPU-API-Validierungsschicht hatte, die alle gut zusammenarbeiteten und die meisten erfassten Probleme während der Entwicklung und hilft bei der Optimierung des Codes.
• Obwohl die API eine etwas niedrigere Ebene als Direct3D 11 ist und einige wichtige Entscheidungen auf niedriger Ebene dem Entwickler überlässt (z. Es wurde mit Pipeline-Barrieren oder Layoutübergängen erstellt, erfordert aber keine, und ein traditionelles Bindungsmodell, bei dem jede Shader-Stufe mehrere Slots hat, denen Sie Ressourcen frei zuweisen können. Beide sind vertraut, leicht verständlich und erfordern eine sehr begrenzte Menge an Code, um schnell loszulegen.

Eine andere Sache, die geholfen hat, war, dass unsere API-Schnittstelle für Metal-ähnliche APIs bereit war – sie ist sehr leicht, aber sie stellt genügend Details (wie Renderdurchläufe) bereit, um problemlos eine Hochleistungsimplementierung zu schreiben. Zu keinem Zeitpunkt in unserer Implementierung musste ich den Status speichern/wiederherstellen (viele APIs leiden darunter, insbesondere aufgrund der Behandlung der Renderzielkonfiguration als Statusänderungen und Ressourcen/persistente Statusbindung) oder komplizierte Entscheidungen über die Lebensdauer/das Timing von Ressourcen treffen. Der einzige „komplizierte“ Code, der für das Rendern benötigt wird, ist der, der den Status der Renderpipeline erstellt, indem die Bits gehasht werden, die zum Erstellen eines solchen erforderlich sind – Pipeline-Statusobjekte sind nicht Teil unserer API-Abstraktion. Auch das geht ganz einfach und schnell. Mehr über unsere API-Schnittstelle werde ich in einem separaten Artikel schreiben.

Also eine Woche, um die Shader zu kompilieren, zwei Wochen, um eine optimierte und ausgefeilte Implementierung1 zu erhalten – was sind die Ergebnisse? Die Ergebnisse sind hervorragend – Metal hält absolut, was es verspricht. Zum einen ist die Dispatch-Performance auf einem einzelnen Thread merklich besser als mit OpenGL (wodurch der Draw-Dispatch-Teil unseres Rendering-Frameworks je nach Arbeitslast um das 2-3-fache reduziert wird), und das angesichts der Tatsache, dass unsere OpenGL-Implementierung in Bezug darauf ziemlich gut abgestimmt ist Redundante Zustandskonfiguration zu reduzieren und mit dem Treiber mit schnellen Pfaden herumzuspielen. Aber das ist noch nicht alles – Multithreading in Metal ist einfach zu verwenden, vorausgesetzt, Ihr Rendering-Code ist dafür bereit. Wir sind noch nicht zur Threaded-Print-Distribution übergegangen, konvertieren aber bereits andere Teile, die Assets darauf vorbereiten, außerhalb des Render-Threads zu passieren, was im Gegensatz zu OpenGL ziemlich mühelos ist.

Darüber hinaus ermöglicht uns Metal, andere Leistungsprobleme anzugehen, indem wir leicht zugängliche und zuverlässige Tools bereitstellen. Einer der zentralen Teile unseres Rendering-Codes ist das System, das Beleuchtungsdaten auf der CPU im Weltraum berechnet und sie in Regionen einer 3D-Textur hochlädt (die wir auf OpenGL ES-Hardware 2 emulieren müssen). Die Aktualisierungen sind teilweise, sodass wir nicht die gesamte Textur duplizieren können und uns darauf verlassen müssen, der Treiber implementiert jedoch glTexSubImage3D. An einem Punkt haben wir versucht, PBO zu verwenden, um die Update-Leistung zu verbessern, stießen jedoch sowohl auf Android als auch auf iOS auf erhebliche Stabilitätsprobleme. Auf Metal gibt es zwei integrierte Möglichkeiten, eine Region herunterzuladen – MTLTexture.replaceRegion, die Sie verwenden können, wenn die GPU die Textur derzeit nicht liest, oder MTLBlitCommandEncoder (copyFromBufferToTexture oder copyFromTextureToTexture), der die Region asynchron rechtzeitig für die herunterladen kann Die GPU beginnt mit der Verwendung der Textur-GPU.

Beide Methoden waren langsamer, als ich es mir wünsche – die erste war nicht wirklich verfügbar, da wir effiziente Teilaktualisierungen unterstützen mussten, und sie funktionierte nur auf der CPU, indem sie eine Übersetzungsimplementierung mit sehr langsamer Adresse verwendete. Das zweite funktionierte, schien aber eine Reihe von 2D-Blits zu verwenden, um die 3D-Textur zu füllen, die beide ziemlich teuer waren, um CPU-seitige Steuerungen einzurichten, und aus irgendeinem Grund auch einen sehr hohen GPU-Overhead hatten. Wenn es OpenGL wäre, wäre das zu viel – tatsächlich entsprach die Leistung beider Methoden ungefähr den beobachteten Kosten eines ähnlichen Updates in OpenGL. Da es sich um Metal handelt, hat es zum Glück einfachen Zugriff auf Compute-Shader – und ein supereinfacher Compute-Shader gab uns die Möglichkeit, Buffer -> 3D Texture Download durchzuführen, was auf der CPU und GPU sehr schnell war und unsere Leistungsprobleme in diesem Teil des Codes im Grunde behob für gut2:

Als abschließende allgemeine Bemerkung ist die Wartung von Metal-Code ungefähr so ​​einfach - alle zusätzlichen Funktionen, die wir bisher hinzufügen mussten, waren einfacher hinzuzufügen als bei jeder anderen von uns unterstützten API, und ich gehe davon aus, dass sich dieser Trend fortsetzen wird. Es gab ein bisschen Bedenken, dass das Hinzufügen einer zusätzlichen API eine ständige Wartung erfordern würde, aber im Vergleich zu OpenGL erfordert es nicht wirklich viel Arbeit; Da wir OpenGL ES 3 unter iOS nicht mehr unterstützen müssen, bedeutet dies, dass wir auch den vorhandenen OpenGL-Code vereinfachen können.

Stabilität

Heute fühlt sich Metal auf iOS sehr stabil an. Ich weiß nicht, wie es beim Start im Jahr 2014 war oder wie es heute auf dem Mac aussieht, aber die Treiber und Tools für iOS scheinen ziemlich solide zu sein.

Wir hatten ein Treiberproblem auf iOS 10 im Zusammenhang mit dem Laden von Shadern, die mit Xcode 7 kompiliert wurden (was wir durch ein Upgrade auf Xcode 8 behoben haben), und einen Treiberabsturz auf iOS 9, der sich als Ergebnis einer unsachgemäßen Verwendung der NextDrawable-API herausstellte. Abgesehen davon haben wir keine Verhaltensfehler oder Abstürze gesehen – für eine relativ neue Metal-API war sie auf ganzer Linie sehr solide.

Darüber hinaus sind die Werkzeuge, die Sie mit Metal erhalten, vielfältig und reichhaltig; insbesondere können Sie verwenden:

• Eine ziemlich umfassende Validierungsschicht, die häufige Probleme bei der Verwendung der API identifiziert. Es ist im Grunde wie Direct3D-Debugging - das Direct3D vertraut, aber im OpenGL-Terrain ziemlich unbekannt ist (theoretisch soll ARB_debug_callback dieses Problem beheben, in der Praxis ist es meistens nicht verfügbar und wenn nicht sehr nützlich).
• Ein funktionaler GPU-Debugger, der alle von Ihnen gesendeten Befehle mit ihrem Status, Renderzielinhalt, Texturinhalt usw. anzeigt. Ich weiß nicht, ob es einen funktionierenden Shader-Debugger hat, weil ich noch nie einen gebraucht habe, und das Untersuchen des Puffers ist vielleicht etwas einfacher, aber meistens erledigt es den Job.
• Ein funktionaler GPU-Profiler, der Leistungsstatistiken pro Durchgang (Zeit, Bandbreite) und auch Laufzeit pro Shader anzeigt. Da die GPU ein Tiler ist, kann man natürlich keine Zero-Call-Timings erwarten. Dieses Maß an Transparenz zu haben – insbesondere angesichts des völligen Fehlens von GPU-Timing-Informationen in den Grafik-APIs unter iOS – ist großartig.
• Ein funktionaler CPU/GPU-Timeline-Trace (Metal System Trace), der die CPU- und GPU-Rendering-Workload-Planung zeigt, ähnlich wie GPUView, aber tatsächlich einfach zu verwenden, modulo einige UI-Eigenheiten.
• Ein Offline-Shader-Compiler, der Ihre Shader-Syntax validiert, Ihnen manchmal nützliche Warnungen ausgibt, Ihren Shader in einen binären Blob konvertiert, der zur Laufzeit ziemlich schnell geladen werden kann und außerdem vorher ziemlich gut optimiert ist, wodurch die Ladezeit verkürzt wird, da der Treiber-Compiler schneller sein kann.

Wenn Sie von Direct3D oder der Konsolenwelt kommen, können Sie sie alle als selbstverständlich ansehen – glauben Sie mir, in OpenGL ist jede von ihnen ungewöhnlich und aufregend, besonders auf Mobilgeräten, wo Sie es gewohnt sind, mit gelegentlichen Treiberunterbrechungen umzugehen, nein Validierung, kein GPU-Debugger, kein nützlicher GPU-Profiler, keine Möglichkeit, GPU-Planungsdaten zu sammeln und gezwungen zu sein, mit einer Shader-Sprache zu arbeiten, die auf Text basiert, für den jeder Anbieter einen etwas anderen Parser hat.

Metal ist eine großartige API zum Schreiben von Code und zum Versenden von Apps. Es ist einfach zu bedienen, hat eine vorhersehbare Leistung, robuste Treiber und ein solides Toolset. Es schlägt OpenGL in jeder Hinsicht außer der Portabilität, aber die Realität mit OpenGL ist, dass Sie es wirklich nur auf drei Plattformen (iOS, Android und Mac) hätten verwenden sollen, und zwei von ihnen unterstützen jetzt Metal; Darüber hinaus wird das Versprechen von OpenGL zur Portabilität im Allgemeinen nicht erfüllt, da der Code, den Sie auf einer Plattform schreiben, aus verschiedenen Gründen sehr oft auf einer anderen nicht funktioniert.

Wenn Sie eine Drittanbieter-Engine wie Unity oder UE4 verwenden, wird Metal dort bereits unterstützt; Wenn Sie es nicht sind und grafische Programmierung lieben oder sich sehr um Leistung kümmern und iOS oder Mac ernst nehmen, empfehle ich Ihnen dringend, Metal auszuprobieren. Du wirst nicht enttäuscht sein.

Metall jetzt

Die größten Veränderungen, die Metal aus unserer Sicht in den letzten drei Jahren erlebt hat, sind die breite Akzeptanz.

Vor drei Jahren musste noch ein Viertel der Geräte OpenGL verwenden. Heute liegt diese Zahl für unser Publikum bei etwa 2 % – was bedeutet, dass unser OpenGL-Backend nicht mehr wirklich wichtig ist. Wir pflegen es immer noch, aber es wird nicht lange dauern.

Die Treiber sind auch besser als je zuvor – im Allgemeinen sehen wir keine Treiberprobleme auf iOS, und wenn, treten sie oft bei frühen Prototypen auf, und bis die Prototypen in Produktion gehen, sind die Probleme normalerweise behoben.

Wir haben auch Zeit damit verbracht, unser Metal-Backend zu verbessern, wobei wir uns auf drei Bereiche konzentriert haben:

Überarbeiten Sie die Toolchain für die Shader-Kompilierung

Eine andere Sache, die in den letzten drei Jahren passiert ist, ist die Veröffentlichung und Entwicklung von Vulkan. Obwohl es so aussieht, als wären die APIs völlig unterschiedlich (und das sind sie auch), hat das Vulkan-Ökosystem der Rendering-Community eine fantastische Reihe von Open-Source-Tools zur Verfügung gestellt, die in Kombination zu einer Reihe von einfach zu verwendenden Build-Tools in Produktionsqualität führen.

Wir haben die Bibliotheken verwendet, um eine Kompilierungs-Toolchain zu erstellen, die HLSL-Quellcode (unter Verwendung verschiedener DX11-Funktionen, einschließlich Compute-Shader) zu SPIRV kompilieren, diesen SPIRV optimieren und den resultierenden SPIRV in MSL (Metal Shading Language) konvertieren kann. Es ersetzt unsere vorherige Toolchain, die nur DX9-HLSL-Quellen als Eingabe verwenden konnte und verschiedene Korrekturprobleme für komplexe Shader hatte.

Es ist etwas ironisch, dass Apple nichts damit zu tun hatte, aber hier sind wir. Vielen Dank an die Mitwirkenden und Betreuer von glslang (https://github.com/KhronosGroup/glslang), spirv-opt (https://github.com/KhronosGroup/SPIRV-Tools) und SPIRV-Cross (https: / / github.com/KhronosGroup/SPIRV-Cross). Wir haben eine Reihe von Korrekturen für diese Bibliotheken bereitgestellt, um uns dabei zu helfen, auch die neue Toolchain auszuliefern und sie zu verwenden, um unsere Shader auf die Vulkan-, Metal- und OpenGL-APIs neu auszurichten.

macOS-Unterstützung

Eine macOS-Portierung war immer eine Möglichkeit, war aber für uns kein großes Problem, bis wir anfingen, einige Funktionen zu vermissen. Also haben wir uns entschieden, in Metal auf macOS zu investieren, um schneller zu rendern und einige Möglichkeiten für die Zukunft freizuschalten.

Aus Sicht der Umsetzung war es überhaupt nicht sehr schwierig. Der größte Teil der API ist genau gleich; Abgesehen von der Fensterverwaltung war der einzige Bereich, der größere Optimierungen benötigte, die Speicherzuweisung. Auf Mobilgeräten gibt es einen gemeinsam genutzten Speicherplatz für Puffer und Texturen, während auf dem Desktop die API von einer dedizierten GPU mit eigenem Videospeicher ausgeht.

Es gibt einen schnellen Weg, dies zu umgehen, indem Sie verwaltete Ressourcen verwenden, bei denen die Metal-Laufzeit sich um das Kopieren der Daten für Sie kümmert. Auf diese Weise haben wir unsere erste Version ausgeliefert, aber dann haben wir die Implementierung überarbeitet, um Ressourcendaten mithilfe von Scratch-Puffer expliziter zu kopieren, um den Overhead des Systemspeichers zu minimieren.

Der größte Unterschied zwischen macOS und iOS war die Stabilität. Bei iOS hatten wir es mit einem einzigen Treiberanbieter auf einer Architektur zu tun, während wir bei macOS alle drei Anbieter (Intel, AMD, NVidia) unterstützen mussten. Plus, auf iOS, wir – zum Glück! – ignorierte die *erste* Version von iOS, in der Metal verfügbar war, iOS 8, und auf macOS war dies unpraktisch, da wir zu dieser Zeit zu wenige Benutzer hatten, um Metal zu verwenden. Aufgrund der Kombination dieser Probleme sind wir auf viel mehr Treiberprobleme in den relativ harmlosen und relativ obskuren Bereichen der API unter macOS gestoßen.

Wir unterstützen immer noch alle Versionen von macOS Metal (10.11+), obwohl wir damit begonnen haben, die Unterstützung zu entfernen und für einige Versionen mit bekannten Shader-Compiler-Fehlern, die schwer zu umgehen sind, zum alten OpenGL-Backend überzugehen, zum Beispiel für 10.11, brauchen wir jetzt macOS 10.11.6 damit Metal funktioniert.

Die Leistungsvorteile entsprachen unseren Erwartungen; In Bezug auf den Marktanteil sind wir jetzt ~25 % OpenGL- und ~75 % Metal-Benutzer auf der macOS-Plattform, was eine ziemlich gesunde Aufteilung ist. Das bedeutet, dass es für uns irgendwann in der Zukunft praktisch sein könnte, die Unterstützung von Desktop-OpenGL einzustellen, da keine andere von uns unterstützte Plattform es verwendet, was großartig ist, um sich auf einfacher zu unterstützende APIs zu konzentrieren und eine gute Leistung zu erzielen es.

Iterieren Sie die Leistung und den Speicherverbrauch

Wir waren in der Vergangenheit ziemlich konservativ mit den Grafik-API-Funktionen, die wir verwenden, und Metal ist keine Ausnahme. Es gibt mehrere große Feature-Updates, die Metal im Laufe der Jahre erworben hat, darunter verbesserte Ressourcenzuweisungs-APIs mit expliziten Heaps, Kachel-Shader mit Metal 2, Argumentpuffer und GPU-Seite zur Befehlsgenerierung usw.

Meistens nutzen wir keine der neuen Funktionen. Die Leistung war bisher angemessen, und wir möchten uns auf Verbesserungen konzentrieren, die allgemein gelten, daher sind Dinge wie Kachel-Shader, die von uns eine sehr spezielle Unterstützung während des Renderings erfordern und nur auf neuerer Hardware verfügbar sind, weniger interessant.

Allerdings verbringen wir einige Zeit damit, verschiedene Teile des Backends so abzustimmen, dass sie *schneller* laufen – indem wir vollständig asynchrone Textur-Downloads verwenden, um das Stottern bei Level-Ladevorgängen zu reduzieren, was völlig schmerzlos war, die oben genannten Speicheroptimierungen unter macOS durchführen und die CPU-Spreizung optimieren an verschiedenen Stellen im Backend zur Reduzierung von Cache-Fehlern usw. und – eines der wenigen neueren Features, für das wir ausdrücklich Unterstützung haben – durch die Verwendung von speicherlosem Texturspeicher, wenn verfügbar, um den für unser neues Schattensystem erforderlichen Speicher erheblich zu reduzieren.

L'avenir

Insgesamt ist die Tatsache, dass wir nicht zu viel Zeit mit Metal-Verbesserungen verbracht haben, eigentlich eine gute Sache – der Code, der vor 3 Jahren geschrieben wurde, funktioniert grundsätzlich und ist schnell und stabil, was ein großartiges Zeichen für eine ausgereifte API ist. Der Port to Metal war eine großartige Investition, wenn man bedenkt, wie lange es gedauert hat und welche anhaltenden Vorteile es uns und unseren Benutzern bringt.

Wir bewerten ständig das Gleichgewicht zwischen dem Arbeitsaufwand, den wir für verschiedene APIs leisten, neu – es ist sehr wahrscheinlich, dass wir uns für einige der zukünftigen Rendering-Projekte tiefer in die moderneren Teile der Metal-API vertiefen müssen; Wenn das passiert, werden wir sicher einen weiteren Artikel darüber schreiben!

1. Ja, okay, und vielleicht eine Woche, um einige Fehler zu beheben, die beim Testen entdeckt wurden ↩
2. Die Zahlen entsprechen 128 KB aktualisierter Daten pro Frame (zwei 32x16x32 RGBA8-Regionen) auf A10 ↩