Was Sie über die Vulkan API wissen sollten.

Was ist das Besondere an der Vulkan API und warum sollten wir uns damit beschäftigen?

In dem folgenden Beitrag möchten wir die Vulkan API etwas näher beschreiben. Es handelt sich um eine Low-Overhead- und Metal-nahe API für 3D-Grafik- und Compute-Anwendungen. Vulkan ist im Grunde genommen eine Fortsetzung von OpenGL. Sie wurde ursprünglich als „Next Generation OpenGL-Initiative“ bezeichnet und enthält einige Teile der AMD Mantle API. Vulkan soll zahlreiche Vorteile gegenüber anderen GPU-APIs bieten, die eine überlegenen plattformübergreifenden Support, einen besseren Support für Multithread-Prozessoren, eine geringere CPU-Auslastung und eine Prise Betriebssystem-Agnostik ermöglichen. Es sollte auch die Treiberentwicklung erleichtern und die Vorkompilierung von Treibern ermöglichen, einschließlich der Verwendung von Shadern in verschiedenen Sprachen.

Wie ist die Vulkan API entstanden?

Vulkan wurde ursprünglich von der Khronos Group im März 2015 angekündigt, wobei ein vorläufiger Starttermin für Ende 2015 festgelegt wurde. Bei Khronos handelt es sich um ein gemeinnütziges Industriekonsortium, das vor fünfzehn Jahren von einigen der größten Namen der grafischen Industrie gegründet wurde, darunter ATI (heute Teil von AMD), Nvidia, Intel, Silicon Graphics, Discrete und Sun Microsystems. Wenn Sie noch nicht von Khronos gehört haben, kennen Sie wahrscheinlich einige ihrer Standards, wie z.B. OpenGL, OpenGL ES, WebGL, OpenGL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES, StreamInput, COLLADA und glTF.

Im Gegensazt zu seinem Vorgänger oder seinen Vorgängern ist Vulkan von Grund auf so konzipiert, dass es auf verschiedenen Plattformen läuft, von Smartphone und Tablets über Spielekonsolen bis hin zu High-End-Desktops. Das zugrunde liegende Design der API ist mehrschichtig oder besser gesagt modular, so dass es die Schaffung einer gemeinsamen, aber erweiterbaren Architektur für Code-Validierung, Debugging und Profiling ermöglicht, ohne die Leistung zu beeinträchtigen. Khronos behauptet, dass der mehrschichtige Ansatz viel mehr Flexibilität bietet, eine starke Innovation bei herstellerübergreifenden GPU-Tools katalysiert und eine direktere GPU-Steuerung ermöglicht, die von anspruchsvollen Game-Engines gefordert wird.

Es ist verständlich, dass viele Technophile ihre Vorbehalte gegenüber Marketingbegriffen wie „flexibel“, „erweiterbar“ und „modular“ haben. Tatsächlich ist das die Grundidee hinter Vulkan: Es ist als API für die Masse gedacht, von Kinderspielen auf Smartphones bis hin zu ihren Eltern, die Gebäude und Spiele auf Workstations entwerfen.

Theoretisch könnte Vulkan in paralleler Computerhardware eingesetzt werden, um Dutzende von Milliarden GPU-Kerne zu steuern, in winzigen Wearables und Spielzeugdrohnen, in 3D-Druckern, Autos, VR-Kits und so ziemlich allem anderen, was einen kompatiblen GPU enthält.

Für weitere Details empfehlen wir Ihnen, einen Blick auf die offizielle Vulkanübersicht im PDF-Format zu werfen.

AMD Mantle DNA.

Wenn Ihnen der Close to Metal-Ansatz unheimlich vertraut vorkommt, haben Sie vielleicht in den letzten zwei Jahren die GPU-Ankündigungen von AMD verfolgt. AMD überraschte die Branchenbeobachter bei der Ankündigung Ihrer Mantle-API im Jahr 2013 und überraschte sie erneut, als das Unternehmen begann, den Stecker für die API zu ziehen, und kündigte im März 2015 an, dass sie Mantle 1.0 nicht als öffentliche SDK veröffentlichen wird. Kurz gesagt, Mantle versprach, in einigen Situationen deutliche Leistungs- und Effizienzsteigerungen zu erzielen, insbesondere auf der CPU-Seite, da dies den Verarbeitungsaufwand reduzieren würde. Es klang nach einer guten Idee, denn Spieler konnten sich eigene PCs mit etwas langsameren Prozessoren zusammenstellen und mehr Geld in hochwertige Grafikkarten investieren. Auch für AMD klang es sehr angenehm, denn das Unternehmen hatte seit Jahren keine wettbewerbsfähige High-End-CPU mehr, obwohl es immer noch gute GPU-Produkte hat.

AMD gab in einem Blogpost bekannt, dass Mantle auch in Zukunft weitergeführt werden wird. Der größte Unterschied besteht darin, dass Vulkan nicht auf AMD GCN-Hardware beschränkt bleibt, sondern auch auf GPUs vieler anderer Hersteller funktioniert. Sie werden erahnen können, in welche Richtung es geht. Es ist eindeutig besser, eine einzige Low-Overhead-Grafik-API zu haben, die auf verschiedenen Betriebssystemen und Hardwareplattformen funktioniert, als proprietäre APIs für verschiedene GPU-Architekturen, Betriebssysteme und so weiter.

Die Vulkan API nimmt einen guten Teil des Mantle Pie und teilt ihn mit alles, unabhängig von Betriebssystem oder Hardware.

Und da ist noch eine Sache: Mantle hat Microsoft und Khronos schließlich gezwungen, endlich etwas gegen DirectX und OpenGL zu unternehmen.

Wie ist Vulkan im Vergleich zu OpenGL zu sehen?

Natürlich müssen wir die grundlegenden Unterschiede zwischen Vulkan und OpenGL aufzeigen. Khronos hat eine einfache Illustration erarbeitet, die zeigt, wie viel Treiberkapazität mit der neuen API beseitigt werden kann.

Vulkan ermöglicht es Anwendungen, näher an das Metall heranzukommen, wodurch viel Speicher und Fehlermanagement sowie eine Vielzahl von Shading-Sprachquellen entfallen. Die Treiber werden leichter und schlanker. Vulkan stützt sich auf die Zwischensprache SPIR-V verlassen, und da es über eine einheitliche API für Mobil-, Desktop- und Konsolenmärkte verfügt, sollte es auch von den Entwicklern mehr Sorgfalt und Liebe erfahren.

Wird dadurch einfach mehr Arbeit an die Gamedeveloper weitergegeben? Sie werden sicher dadurch die Hardware effizienter nutzen können, aber was ist mit ihren Arbeitszeiten? Hier gewinnt der historische Ökosystem-Ansatz an Bedeutung.

Die Entwickler können zwischen drei verschiedenen Ebenen des vulkanischen Ökosystems wählen.

• Verwenden Sie Vulkan direkt für maximale Flexibilität und Kontrolle.
• Verwenden Sie Vulkan-Libraries und -Layer, um die Entwicklung zu beschleunigen.
• Nutzen Sie Vulkan über handelsübliche Game-Engines, die über die neue API vollständig optimiert sind.

Die erste Option wird natürlich nicht für jeden etwas sein, aber es bildet eine gute Grundlage für nützliche Benchmarking-Software. Khronos erwartet, dass die zweite Option ein „reichhaltiges Gebiet für Innovationen“ sein wird, da viele Dienstprogramme und Layer in Open Source verfügbar sein werden und damit den Übergang von OpenGL erleichtern werden. Wenn ein Publisher einige OpenGL-Titel hat, die optimiert und aktualisiert werden müssen, ist dies das, was verwendet werden sollte.

Die letzte Option ist vielleicht die verlockenste, denn das schwere Heben wurde von Branchenschwergewichten wie Unity, Oxide, Blizzard, Epic, EA, Valve und anderen durchgeführt.

Um ehrlich zu sein, glauben wir nicht, dass es fair ist, die beiden Lösungen miteinander zu vergleichen. Vulkan ist ein Derivat von Mantle, während OpenGL schon auf eine 20-jährige Vergangenheit zurückblicken kann. Vulkan soll jede Menge Altlasten loswerden, das ist der springende Punkt. Vulkan soll Tests und Implementierungen rationalisieren, Treiber schlanker machen und die Portabilität von Shader-Programmen über die Zwischensprache SPIR-V verbessern.

Damit kommen wir zur nächsten Frage. Welche Bedeutung hat Vulkan für Entwickler?

Es wird erwartet, dass SPIR-V das Sprach-Ökosystem verändern wird.

Wo kommt also SPIR-VR ins Spiel und was passiert mit GLSL?

GLSL wird vorerst am Leben bleiben und es wird die erste Shading-Sprache sein, die von Vulkan unterstützt wird. Ein GLSL zu SPIR-V Übersetzer wird gute Arbeit leisten. Game-Developer werden in der Lage sein, SPIR-V und Vulkan Backends zu verwenden, welche wahrscheinlich auf Open-Source-Compiler-Frontends verlassen. Zusätzlich zu GLSL kann Vulkan OpenCL C-Kernel unterstützen, während weiter am Support für C++ gearbeitet wird. Zukünftige domainspezifische Sprachen, Frameworks und Tools sind eine weitere Option. Khronos erwähnt sogar die Möglichkeit, neue experimentielle Sprachen zu entwickeln.

Was auch immer die Entwickler tun, alle Wege führen zu Vulkan, über SPIR-V und anschließend zu einer Vielzahl von verschiedenen Geräten.

SPIR-V soll die Portabilität auf drei Arten verbessern:

• Gemeinsame Tools
• Einzelnes Toolset für einen einzigen ISV
• Einfachheit

Da nicht jede Hardwareplattform über einen Hochsprachenübersetzer verfügen muss, werden sich die Entwickler mit weniger davon befassen.

Ein individueller ISV kann SPIR-V mit einem einzigen Toolset generieren, wodurch Probleme mit der Portabilität der Hochsprache entfallen.

SPIR-V ist einfacher als eine typische Hochsprache, was die Implementierung und Verarbeitung erleichtert.

Die Leistung wird auf verschiedene Weise verbessert, je nachdem, wie Vulkan implementiert wird:

• Kein Compiler-Frontend mehr, dadurch kann mehr offline verarbeitet werden.
• Optimierungsläufe können schneller abgerechnet werden.
• Optimierungen werden offline durchgeführt.

Khronos gibt keine Leistungszahlen an und weist darauf hin, dass „die Kilometerzahl definitiv variieren wird“. Es hängt alles davon ab, wie Vulkan verwendet wird. Wenn Sie sich über die Details informieren möchten, sollten Sie sich das SPIR-V Whitepaper durchlesen.

Vulkan sieht aus Entwicklersicht vielversprechend aus.

Es wurden eine Reihe von Features skizziert, die Vulkan und SPIR-V in der Entwicklergemeinde populär machen sollten, und Khronos ist bestrebt, diesen Aspekt ebenfalls zu vermitteln. Die Aussicht, die gleichen Tools und Skills zu verwenden, um für mehrere Plattformen zu entwickeln, erscheint faszinierend, besonders zum aktuellen Zeitpunkt, da sich die Leistungslücke zwischen verschiedenen Plattformen immer weiter schließt.

Natürlich wird die Entwicklung eines Big-Budget-AAA-Spiels für den PC ein äußerst komplexer und zeitaufwendiger Prozess bleiben, welcher viel Geld und Personal erfordert, aber mobile Plattformen und integrierte GPUs, die in den neuesten Intel- und AMD-Prozessoren eingesetzt werden, liefern bereits eine Menge GPU-Leistung für den Gelegenheitsspieler. Außerdem arbeiten kleine, unabhängige Entwickler oder Freelancer eher an plattformübergreifenden Casual Games als AAA-Titel, die von großen Verlagen herausgegeben werden.

Khronos beschreibt die folgenden Vorteile, die durch SPIR-V ermöglicht werden:

• Entwickler können denselben Front-End-Compiler auf mehreren Plattformen verwenden, um Probleme mit der Portabilität zwischen Anbietern zu vermeiden.
• Die Kompilierungszeit für Shader/Kernel wird verkürzt, da der Treiber nur SPIR-V verarbeiten muss.
• Entwickler müssen keinen Shader/Kernel-Quellcode verteilen, so dass sie ein zusätzliches Maß an IP-Schutz genießen.
• Die Treiber sind einfacher und zuverlässiger, da keine Frontend-Compiler integriert werden müssen.
• Entwickler haben ein besseres Bild der Speicherzuordnung und können ihren Memory Allocation Ansatz entsprechend anpassen.

Wir sind uns sicher, dass Sie uns zustimmen werden, dass das gut klingt, aber es ist noch ein langer Weg.

Vulkan: Es funktioniert, aber es muss noch viel gearbeitet werden.

Wie gesagt, an Vulkan wird noch eine ganze Zeit weitergearbeitet werden, und wir sollten bis Ende des Jahres die volle Spezifikation haben. Die neue API kann jedoch auch mit Hardware der aktuellen Generation schon viel leisten.

Die beste Illustration von Vulkan, die wir bisher gesehen haben, stammt von Imagination Technologies, einem der führenden mobilen GPU-Outfits auf dem Markt. Imagination Technologies GPU IP wird in allen iOS-Gadgets verwendet, zusammen mit zahlreichen anderen ARM-basierten System-on-Chip-Designs und sogar in einigen Low-Voltage Intel x86-Chips.

Letzte Woche veröffentlichte Imagination einen Blog-Post, in dem die von Vulkan ermöglichten Leistungssteigerungen beschrieben wurden. Die Wahl der Hardware war etwas ungewöhnlich: ein Google Nexus Player, basierend auf einem selten verwendeten Intel Quad-Core-Prozessor mit PowerVR G6430 GPU. Das Gerät wurde mit den neuesten Vulkan-API-Treiber für PowerVR-GPUs getestet, während der Referenzlauf mit OpenGL ES 3.0 durchgeführt wurde. Die Leistungslücke war einfach gravierend.

Sehen Sie sich diese Vulkan API-Demo an: Smooth Games vs. Choppy Gnomes.

Die Szene umfasst insgesamt 400.000 Objekte mit unterschiedlichen Detaillierungsgraden, die von 13.000 bis 300 Nodes reichen. Die Weitwinkelaufnahme zeigt schätzungsweise eine Million Dreiecke, etwas Alpha auf den Pflanzen und etwa zehn verschiedene Texturen für die Gnome und Pflanzen. Jeder Objekttyp verwendet einen anderen Shader und die Zwerge sind nicht instanziert, jeder Draw-Call könnte ein völlig anderes Objekt mit unterschiedlichen Materialien sein, aber das Endergebnis wäre ähnlich.

Dennoch gibt es einen großen Vorbehalt: Das ist nicht die Art von Leistungssteigerung, die man im wirklichen Leben erwarten kann. Das Team von Imagination Technologies nutzte ein übertriebenes Szenario, um die Überlegenheit von Vulkan hervorzuheben und an ihre Grenzen zu bringen, und in diesem speziellen Szenario spricht sich das Limit für Vulkan gegenüber OpenGL ES aus. Beachten Sie auch, dass dieser Test GPU-gebunden ist, aber er ist immer noch ein gutes Beispiel für die überlegene CPU-Auslastung von Vulkan.

Wie reduziert Vulkan die CPU-Auslastung?

Erinnern Sie sich an die OpenGL-Vulkan-Tabelle? Dort verwendete Vulkan Imagination, um Draw-Calls in Kacheln zu stapeln und eine Kachel nach der anderen zu rendern. Je nachdem, wo sich die Kachel zum Zeitpunkt des Renderns des Frames befindet, kann sie in den Blickfeld gelangen oder aus dem Blickfeld geraten, ihren Detaillierungsgrad ändern und so weiter. In OpenGL ES sind alle Draw-Calls dynamisch, sie werden mit jedem Frame übermittelt, je nachdem, was sich im Sichtfeld befindet. Bereits ausgeführte Draw-Calls können nicht zwischengespeichert werden.

Infolgedessen benötigt OpenGL ES viele Aufrufe im Kernelmodus, um den Zustand des Treibers zu ändern und zu validieren. Vulkan nicht, weil es auf vorgenerierte Befehle angewiesen ist, um den CPU-Overhead zu reduzieren und die Notwendigkeit der Validierung oder Kompilierung während der Render-Schleife zu eliminieren. Das Imagination-Team beschrieb die Fähigkeit, Command Buffer wiederzuverwenden, als „unter bestimmten Umständen nützlich“ und als „weitgehend“ in vielen Spielen und Anwendungen verwendbar.

Der zweite Spielwechsler ist die parallele Buffer Generation, die es Vulkan ermöglicht, die Leistung aller CPU-Kerne zu nutzen. OpenGL ES wurde vor dem Aufkommen von Multi-Core-Mobilchips entwickelt, aber in den letzten 3 Jahren hat sich die Branche von zwei, über vier, acht und zehn CPU-Kernen entwickelt, wobei die SoCs der A-Serie von Apple und die in Denver basierten Nvidia Tegra-Chips die einzigen nennenswerten Ausnahmen bilden.

Versuchen wir eine Analogie: Wäre Vulkan ein Verbrennungsmotor, würde dieser einen Teil seiner Leistung speichern und wiederverwenden, ähnlich wie ein Turbolader und Ladeluftkühler (Command Buffer), und dieser könnte vier, sechs, acht oder sogar zehn Zylinder ohne Effizienzverlust nutzen. Der Vergleich von Vulkan mit OpenGL ES klingt ein wenig nach dem Vergleich eines neuen, verkleinerten Turbomotors mit einem alten Einzylindermotor.

Das Endergebnis ist eine wesentlich effizientere Umgebung, die in der Lage ist, alle verfügbaren Hardwarekomponenten sinnvoll zu nutzen, im Gegensatz zu OpenGL ES, das in den meisten Szenarien GPU-gebunden ist. Dies bedeutet, dass Vulkan eine ähnliche Leistung erbringen kann, während die CPU auf niedrigerem Takt gehalten wird, was den Stromverbrauch und die Drosselung reduziert.

Potentielle Nachteile der Vulkan-API.

Glücklicherweise hat die Vulkan-API nicht so viele Nachteile. Dazu gehören:

• Zusätzliche Codekomplexität in bestimmten Szenarien.
• Time-to-Market.
• Umfang des Supports durch die Industrie.
• Vulkan ist auf einigen Plattformen (Desktops) möglicherweise nicht so relevant oder effektiv.
• Wenig überzeugte Entwickler, die Vulkan auf verschiedenen Plattformen einsetzen.
• Eingeschränkte Kompatibilität mit älterer Hardware.

Wenn ein Entwickler einige der in diesem Beitrag beschriebenen Funktionen implementieren möchte, ist dies mit erheblichem Aufwand verbunden. Jeder muss im Code implementiert werden, aber die gute Nachricht ist, dass Branchenführer den Prozess mit neuen Treiber-Updates vereinfachen werden.

Es gibt nicht allzu viele Nachteile der Vulkan API, aber es wird eine Weile dauern, bis sich diese Technologie durchsetzt.

Time-to-Market ist ein weiteres Thema, ebenso wie die Implementierung von Vulkan in älteren Apps und Spielen. Vulkan ist immer noch recht neu. Erste Spezifikationen und Implementierungen wurden Ende 2015 realisiert, so dass wir realistischerweise wahrscheinlich nicht viele Anwendungen aus der Praxis bis Mitte 2020 sehen werden.

Der Support der Industrie sollte kein so großes Thema sein. Schließlich handelt es sich um einen Khronos-Standard. Das ist einer der Gründe, warum wir diesen Beitrag verstärkt auf Mobile ausgerichtet haben. Mobile Soft- und Hardware entwickeln sich schneller und es kann noch ein paar Quartale dauern, bis wir sehen, wie Vulkan Einfluss auf Desktop-Plattformen nimmt. So funktioniert die Branche, es gibt noch viel mehr Dinge, um die man sich in der Desktop-Nische kümmern muss wie z.B. Support für professionelle Anwendungen. Die Tatsache, dass Vulkan aus dem Mantle von AMD stammt, ist jedoch ermutigend.

Während Vulkan in einer CPU-gebundenen Umgebung, insbesondere bei mobilen Multicore-SoCs, Wunder vollbringen kann, werden diese Leistungssteigerungen auf Desktop-Plattformen begrenzt sein. Desktops verarbeiten Multicore-Prozessoren mit einer höheren Effizienz und die meisten grafisch anspruchsvollen Anwendungen sind GPU-gebunden.

Bis alle Teile des Puzzle zusammengefügt wurden, mögen einige Entwickler zögern, den Sprung zu wagen und mit Vulkan herumzuspielen. Vielen Menschen haben einfach keine Zeit zum Experimentieren, und sie erlernen nur neue Skills, wenn es absolut notwendig ist. Viel Geld zu verdienen und Arbeitsstunden zu verschwenden, um bestehende Handyspiele zu optimieren, um Vulkan in diesem frühen Stadium zu nutzen, wird für viele Entwickler und Publisher keine Option sein.

Die Kompatibilität mit älterer Hardware könnte ein weiterer Grund zur Sorge sein. Vulkan benötigt OpenGL ES 3.1 oder OpenGL 4.1 Hardware, begleitet von neuen Treibern. Beispielsweise können die PowerVR-Grafikprozessoren der Serie 6 von Imagination Technologies sie unterstützen, die Serie 5 jedoch nicht. Die Mali T600- und T700-Serie von ARM unterstützt OpenGL ES 3.1, aber bei älteren Designs der T400-Serie fehlt der Support. Glücklicherweise sind die meisten Geräte mit nicht unterstützten GPUs bis zur Relevanz von Vulkan nicht mehr im Bild. Dazu gehören das iPhone 5/5c, iPad der vierten Generation und Samsung-Geräte, die auf bestimmten Exynos-Chips der 5000er-Serie basieren. Qualcomm-basierte Geräte haben vielleicht nicht so viel Glück, da die GPUs der Adreno 300-Serie bei relativ neuen und produktiven Designs wie dem Snapdragon 410, Snapdragon 600, Snapdragon 800 und 801 eingesetzt werden. Wir vermuten jedoch, dass die meisten von ihnen verschwunden sein werden, wenn Vulkan wirklich relevant wird.

Schlußfolgerungen.

Es ist noch zu früh, um zu sagen, ob Vulkan ein Wendepunkt sein wird oder nicht, aber wir denken, Sie werden mir zustimmen, dass es viel Potenzial hat und sich langfristig durchsetzen wird. Es wird jedoch einige Zeit dauern und es wird vermutet, dass Vulkan seine Präsenz im Mobilfunkbereich spürbar machen wird, bevor es beginnt, die Desktop-Landschaft zu verändern.

Etwa zur gleichen Zeit wie Vulkan-optimierte Treiber, Game-Engines und Spiele werden wir neue Hardware zum Spielen bekommen, und wir meinen nicht nur kleine Hardware-Optimierungen. Die mobile SoC-Entwicklung ist aus einer Reihe von Gründen ins Stocken geraten, auf die wir jetzt nicht näher eingehen werden, aber das Jahr 2016 wird ein großes Jahr für die Branche sein, da 14/16nm-FinFET-Nodes für mehr Hersteller verfügbar werden und für Mainstream-Hardware und nicht für Flaggschiff-Chips wirtschaftlich werden.

Entwickler werden über eine wesentlich leistungsfähigere und effizientere Hardware verfügen, mit der sie spielen können, und eine neue Grafik-API mit geringem Overhead wird das Tüpfelchen auf dem i sein.

Vielen Dank für Ihren Besuch.