Ein kurzer Überblick über die Vulkan-API

Also, was ist überhaupt die große Sache mit dieser neuen Vulkan-API, und warum sollte uns das interessieren?

Hier ist die Vulkan-API in höchstens hundert Worten: Es handelt sich um eine Low-Overhead-, Near-to-Metal-API für 3D-Grafik- und Rechenanwendungen. Vulkan ist im Grunde ein Nachfolger von OpenGL. Es wurde ursprünglich als „OpenGL-Initiative der nächsten Generation“ bezeichnet und enthält einige Bits und Teile von AMDs Mantle-API. Vulkan soll zahlreiche Vorteile gegenüber anderen GPU-APIs bieten, die eine überlegene plattformübergreifende Unterstützung, eine bessere Unterstützung für Multithread-Prozessoren, eine geringere CPU-Last und eine Prise OS-Agnostizismus ermöglichen. Es sollte auch die Treiberentwicklung vereinfachen und die Vorkompilierung von Treibern ermöglichen, einschließlich der Verwendung von Shadern, die in verschiedenen Sprachen geschrieben sind.

Das sind 93 Wörter. Wenn Sie also nicht interessiert sind, können Sie die nächsten 3.500 überspringen. Wenn Sie andererseits mehr über die kommende Grafik-API erfahren möchten, die uns noch Jahre begleiten wird, beginne ich mit den Grundlagen.

Wie die Vulkan-API entstand

Vulkan wurde ursprünglich von der Khronos Group im März 2015 angekündigt, mit einem vorläufigen Starttermin für Ende 2015. Falls Sie mit Khronos nicht vertraut sind, handelt es sich um ein gemeinnütziges Industriekonsortium, das vor fünfzehn Jahren von einigen der größten Namen der Branche gegründet wurde Grafikindustrie, einschließlich ATI (jetzt ein Teil von AMD), Nvidia, Intel, Silicon Graphics, Discrete und Sun Microsystems. Auch wenn Sie noch nie von Khronos gehört haben, haben Sie wahrscheinlich schon von einigen ihrer Standards gehört, wie zum Beispiel: OpenGL, OpenGL ES, WebGL, OpenCL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES, StreamInput, COLLADA und glTF.

Inzwischen denken Sie wahrscheinlich „Ah, das sind diese Typen“, also kann ich den Rest der Einführung überspringen und mich auf die API selbst konzentrieren.

Im Gegensatz zu seinem Vorgänger oder seinen Vorgängern ist Vulkan von Grund auf so konzipiert, dass es auf verschiedenen Plattformen läuft, von Handys und Tablets bis hin zu Spielekonsolen und High-End-Desktops. Das zugrunde liegende Design der API ist mehrschichtig oder sollten wir sagen modular, sodass es die Erstellung einer gemeinsamen, aber erweiterbaren Architektur für die Codevalidierung, das Debugging und die Profilerstellung ermöglicht, ohne die Leistung zu beeinträchtigen. Krhonos behauptet, dass der mehrschichtige Ansatz viel mehr Flexibilität bieten, starke Innovationen bei herstellerübergreifenden GPU-Tools katalysieren und eine direktere GPU-Steuerung bieten wird, die von ausgeklügelten Spiele-Engines gefordert wird.

Nun verstehe ich, dass viele Technikbegeisterte Vorbehalte gegenüber Marketingbegriffen wie „flexibel“, „erweiterbar“ und „modular“ haben, aber dieses Mal haben wir es mit dem echten McCoy zu tun. Tatsächlich ist das die Grundidee hinter Vulkan: Es ist als API für die breite Masse gedacht, von Kindern, die auf Smartphones spielen, bis hin zu ihren Eltern, die Gebäude und Spiele auf Workstations entwerfen.

Theoretisch könnte Vulkan in Parallel-Computing-Hardware verwendet werden, um zig Milliarden GPU-Kerne zu steuern, in winzigen Wearables und Spielzeugdrohnen, in 3D-Druckern, Autos, VR-Kits und so ziemlich allem anderen mit einer kompatiblen GPU im Inneren.

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

AMD Mantel-DNA

Wenn Ihnen der Close-to-Metal-Ansatz unheimlich bekannt vorkommt, haben Sie vielleicht die GPU-Ankündigungen von AMD in den letzten zwei Jahren oder so verfolgt. AMD überraschte Branchenbeobachter, als es 2013 seine Mantle-API ankündigte, und es überraschte sie erneut, als es beschloss, den Stecker aus der API zu ziehen, und im März 2015 ankündigte, Mantle 1.0 nicht als öffentliches SDK zu veröffentlichen. Kurz gesagt, Mantle versprach, in einigen Situationen erhebliche Leistungs- und Effizienzverbesserungen zu erzielen, insbesondere an der CPU-Front, da dies den Verarbeitungsaufwand reduzieren würde. Es klang nach einer guten Idee, da Gamer eigene PCs mit etwas langsameren Prozessoren zusammenstellen und mehr Geld in erstklassige Grafikkarten investieren konnten. Auch für AMD klang das sehr günstig, denn das Unternehmen hat seit Jahren keine konkurrenzfähige High-End-CPU mehr, obwohl es immer noch gute GPU-Produkte hat.

Als sich weinende AMD-Fanboys versammelten, um den Tod ihres Retters zu betrauern, wurde Mantle auf wundersame Weise wiederbelebt. Die gute Nachricht kam in Form eines Blogbeitrags, verfasst von AMD VP of Visual and Perceptual Computing, Raja Koduri. Zufälligerweise hielt Koduri im Einklang mit dem religiösen Thema einmal eine Bergpredigt während AMDs Hawaii-Auftaktveranstaltung im Jahr 2013, aber ich schweife ab.

Spaß beiseite, Koduris Team hat gute Arbeit geleistet. Obwohl Mantle kein neuer Industriestandard wurde, wurde es zu einer Grundlage für Vulkan. Der größte Unterschied besteht darin, dass Vulkan nicht auf AMD GCN-Hardware beschränkt ist; Es wird auf viel mehr GPUs von verschiedenen Anbietern funktionieren. Sie können wahrscheinlich sehen, wohin ich damit gehe; Es ist etwas besser, eine einzige Grafik-API mit geringem Overhead zu haben, die auf verschiedenen Betriebssystemen und Hardwareplattformen funktioniert, als proprietäre APIs für verschiedene GPU-Architekturen, Betriebssysteme usw. zu haben.

Die Vulkan-API nimmt einfach einen guten Teil des Mantle-Kuchens und teilt ihn mit allen, unabhängig von Betriebssystem, Hardware, Rasse oder Religion.

Oh, und da ist noch etwas: Mantle hat Microsoft und Khronos schließlich gezwungen, endlich etwas gegen die Aufblähung und Ineffizienz von DirectX und OpenGL zu unternehmen. Es war ein sanfter, freundlicher Tritt ins Gesäß oder „badonkadonk“, wie es ein anderer Toptaler gerne ausdrückt.

Wie vergleicht sich Vulkan mit OpenGL?

Natürlich muss ich die grundlegenden Unterschiede zwischen Vulkan und OpenGL skizzieren. Khronos hat eine einfache Illustration entwickelt, die zeigt, wie viel Treiberaufblähung mit der neuen API eliminiert werden kann.

Vulkan ermöglicht es Anwendungen, näher an Metal heranzukommen, wodurch viel Speicher und Fehlerverwaltung sowie viel Shading-Sprachquelle überflüssig werden. Die Fahrer werden leichter, schlanker und gemeiner. Vulkan wird sich nur auf die SPIR-V-Zwischensprache verlassen, und da es eine einheitliche API für den Mobil-, Desktop- und Konsolenmarkt hat, sollte es auch von den Entwicklern zärtlicher und liebevoller betreut werden.

Aber Moment mal, entlastet das nicht einfach mehr Arbeit für Spieleentwickler? Sicher, sie werden Hardware effizienter nutzen können, aber was ist mit ihren eigenen Arbeitsstunden? Hier kommt der mehrschichtige Ökosystemansatz ins Spiel.

Entwickler können drei verschiedene Ebenen oder Tiers des Vulkan-Ökosystems auswählen.

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

Die erste Option wird sicherlich nicht jedermanns Sache sein, aber ich vermute, dass sie für eine nette Benchmarking-Software sorgen würde. Khronos erwartet, dass die zweite Option ein „reicher Bereich für Innovationen“ sein wird, da viele Dienstprogramme und Ebenen in Open Source sein werden und den Übergang von OpenGL erleichtern werden. Wenn ein Herausgeber einige OpenGL-Titel hat, die optimiert und aktualisiert werden müssen, würde er dies verwenden.

Die letzte Option ist vielleicht die verlockendste, da Schwergewichte der Branche wie Unity, Oxide, Blizzard, Epic, EA, Valve und andere die Schwergewichte übernommen haben.

Hier ist eine kurze OpenGL vs. Vulkan-Tabelle:

Um ehrlich zu sein, finde ich es nicht einmal fair, die beiden zu vergleichen. Vulkan ist ein Mantle-Derivat, während OpenGL ein Mastodon mit 20 Jahren Gepäck ist. Vulkan soll jede Menge Altlasten loswerden; das ist der springende Punkt. Vulkan soll Tests und Implementierung rationalisieren, Treiber schlanker machen und die Portabilität von Shader-Programmen über die SPIR-V-Zwischensprache verbessern.

Das bringt uns zur nächsten Frage. Was bedeutet Vulkan wirklich für Entwickler?

SPIR-V soll das Sprachökosystem verändern

Wo also kommt SPIR-V ins Spiel und was passiert mit der guten alten GLSL?

GSLS wird vorerst am Leben bleiben und die erste von Vulkan unterstützte Shading-Sprache sein. Ein GLSL-zu-SPIR-V-Übersetzer wird die schwere Arbeit erledigen, und voila!, Sie werden SPIR-V bereit machen, um die hungrige Vulkan-Laufzeit zu füttern. Spieleentwickler können SPIR-V- und Vulkan-Back-Ends verwenden und sich wahrscheinlich auf Open-Source-Compiler-Front-Ends verlassen. Zusätzlich zu GLSL kann Vulkan OpenCL-C-Kernel unterstützen, während die Arbeit an der Unterstützung für C++ voranschreitet. Zukünftige domänenspezifische Sprachen, Frameworks und Tools sind eine weitere Option. Khronos erwähnt sogar die Möglichkeit, neue experimentelle Sprachen zu entwickeln.

Wofür sich Entwickler auch entscheiden, alle Wege führen über SPIR-V zu Vulkan und dann zu einer Vielzahl unterschiedlicher Geräte.

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

• Geteilte Werkzeuge
• Einzelnes Tool-Set für einen einzelnen ISV
• Einfachheit

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

Ein einzelner ISV kann SPIR-V mit einem einzigen Toolset generieren, wodurch Portabilitätsprobleme der Hochsprache beseitigt werden.

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

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

• Kein Compiler-Frontend mehr, viel Verarbeitung kann offline erfolgen
• Optimierungsdurchläufe können schneller abgewickelt, Optimierungen offline ausgeführt werden
• Mehrere Quell-Shader reduzieren sich auf denselben Zwischensprachen-Anweisungsstrom

Khronos gibt keine Leistungszahlen an und stellt fest, dass „die Laufleistung definitiv variieren wird“. Es hängt alles davon ab, wie Vulkan verwendet wird. Wenn Sie sich die groben Details ansehen möchten, lesen Sie unbedingt das SPIR-V-Whitepaper.

Vulkan sieht aus Entwicklersicht vielversprechend aus

Ich habe eine Reihe von Funktionen skizziert, die Vulkan und SPIR-V in der Entwickler-Community populär machen sollten, und Khronos ist sehr daran interessiert, diesen Punkt ebenfalls zu vermitteln. Die Aussicht, die gleichen Tools und Fähigkeiten zur Entwicklung für mehrere Plattformen zu verwenden, erscheint faszinierend, insbesondere jetzt, da sich die Leistungslücke zwischen verschiedenen Plattformen schließt.

Natürlich bleibt die Entwicklung eines AAA-Spiels mit großem Budget für PCs ein äußerst komplexer und zeitaufwändiger Prozess, der haufenweise Geld und Personal erfordert, aber mobile Plattformen und integrierte GPUs, die in den neuesten Intel- und AMD-Prozessoren eingesetzt werden, liefern bereits eine Menge davon GPU-Leistung für Gelegenheitsspieler. Außerdem arbeiten kleine, unabhängige Entwickler oder Freiberufler eher an plattformübergreifenden Gelegenheitsspielen als an AAA-Titeln, die von großen Verlagen am laufenden Band produziert werden.

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

• Entwickler können den gleichen Front-End-Compiler auf mehreren Plattformen verwenden, um herstellerübergreifende Portabilitätsprobleme zu beseitigen
• Laufzeit-Shader/Kernel-Kompilierungszeit wird reduziert, da der Treiber nur SPIR-V verarbeiten muss
• Entwickler müssen keinen Shader-/Kernel-Quellcode verteilen, sodass sie ein zusätzliches Maß an IP-Schutz genießen
• Treiber sind einfacher und zuverlässiger, da keine Front-End-Compiler eingebunden werden müssen
• Entwickler haben ein besseres Bild der Speicherzuweisung und können ihren Speicherzuweisungsansatz entsprechend optimieren

Ich bin sicher, Sie werden zustimmen, dass das gut klingt, aber es ist noch ein langer Weg zu gehen.

Vulkan: Es funktioniert, aber es ist noch in Arbeit

Wie gesagt, Vulkan ist noch ziemlich in Arbeit, und wir sollten die vollständige Spezifikation bis Ende des Jahres haben. Nach allem, was wir bisher gesehen haben, kann die neue API jedoch auch mit Hardware der aktuellen Generation viel Leistung freisetzen.

Die beste Illustration von Vulkan, die ich bisher gesehen habe, stammt von Imagination Technologies, einem der führenden mobilen GPU-Outfits da draußen. GPU-IP von Imagination Technologies wird in allen iOS-Gadgets zusammen mit zahlreichen anderen ARM-basierten System-on-Chip-Designs und sogar in einigen x86-Chips von Intel mit niedriger Spannung verwendet.

Letzte Woche veröffentlichte Imagination einen Blogbeitrag, in dem die durch Vulkan ermöglichten Leistungssteigerungen detailliert beschrieben werden. Etwas ungewöhnlich war die Wahl der Hardware: ein Google Nexus Player, basierend auf einem selten genutzten Intel Quad-Core-Prozessor mit PowerVR G6430 GPU. Das Gerät wurde mit dem neuesten Vulkan-API-Treiber für PowerVR-GPUs getestet, während der Referenzlauf auf OpenGL ES 3.0 durchgeführt wurde. Der Leistungsunterschied war geradezu überwältigend.

Die Szene umfasst insgesamt 400.000 Objekte mit unterschiedlichen Detaillierungsgraden, die von 13.000 bis 300 Scheitelpunkten reichen. Die Totale 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 Gnome sind nicht instanziiert, jeder Zeichenaufruf könnte ein völlig anderes Objekt mit unterschiedlichen Materialien sein, aber das Endergebnis wäre ähnlich.

Dennoch gibt es einen großen Vorbehalt: Dies ist nicht die Art von Leistungssteigerung, die Sie im wirklichen Leben erwarten können. Das Team von Imagination Technologies verwendete ein übertriebenes Szenario, um die Überlegenheit von Vulkan hervorzuheben und es an seine Grenzen zu bringen, und in diesem speziellen Szenario spricht die Grenze für Vulkan vs. OpenGL ES. Denken Sie auch daran, 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 vs. Vulkan-Tabelle, die wir zuvor hatten, oder genauer gesagt an dieses gekachelte Rendering- Bit? Wahrscheinlich nicht, also hier ist es auf den Punkt gebracht: Imagination verwendete Vulkan, um Aufrufe stapelweise in Kacheln zu zeichnen und jeweils eine Kachel zu rendern. Je nachdem, wo sich die Kachel zum Zeitpunkt des Renderns des Rahmens befindet, kann sie sichtbar werden oder verschwinden, ihre Detailgenauigkeit ändern und so weiter. In OpenGL ES sind alle Zeichenaufrufe dynamisch, sie werden mit jedem Frame gesendet, je nachdem, was sich im Sichtfeld befindet. Bereits ausgeführte Draw Calls können nicht zwischengespeichert werden.

Infolgedessen benötigt OpenGL ES viele Aufrufe in den Kernelmodus, um den Status des Treibers zu ändern und zu validieren. Vulkan tut dies nicht, weil es auf vorgenerierte Befehle (Befehlspuffer) angewiesen ist, um den CPU-Overhead zu reduzieren und die Notwendigkeit einer Validierung oder Kompilierung während der Renderschleife zu beseitigen. Das Imagination-Team beschrieb die Möglichkeit, Befehlspuffer wiederzuverwenden, als „unter bestimmten Umständen nützlich“ und in vielen Spielen und Anwendungen „weitgehend“ nutzbar.

Der zweite Game Changer ist die parallele Puffergenerierung , die es Vulkan ermöglicht, die Leistung aller CPU-Kerne zu nutzen. OpenGL ES wurde vor dem Aufkommen von Mehrkern-Mobilchips entwickelt, aber in den letzten drei Jahren hat sich die Branche von zwei über vier zu acht und zehn CPU-Kernen entwickelt, mit Apples SoCs der A-Serie und Nvidia Tegra aus Denver Chips als einzige bemerkenswerte Ausnahmen. Ich habe in einem meiner vorherigen Blogartikel über mobile SoC-Trends gesprochen, in denen es um den kommenden Optimizing Android Compiler ging, sodass Sie ihn für zusätzliche Informationen überprüfen können.

Versuchen wir es mit einer Analogie: Wenn Vulkan ein Verbrennungsmotor wäre, würde er einen Teil seiner Leistung speichern und wiederverwenden, ähnlich wie es ein Turbolader und ein Ladeluftkühler tun würden (Befehlspuffer), und er könnte vier, sechs, acht oder sogar zehn Zylinder ohne Wirkungsgradverlust (parallele Puffererzeugung). Der Vergleich von Vulkan mit OpenGL ES klingt ein bisschen so, als würde man einen neuen, verkleinerten Turbomotor mit einem alten Einzylindermotor auf der Triumph Trophy Ihres Großvaters vergleichen.

Immerhin war Opa ein richtiger Rocker, kein Mod.

Das Endergebnis ist eine wesentlich effizientere Umgebung, die im Gegensatz zu OpenGL ES, das in den meisten Szenarien CPU-gebunden ist, in der Lage ist, die gesamte verfügbare Hardware sinnvoll zu nutzen. Das bedeutet, dass Vulkan ein ähnliches Leistungsniveau liefern kann, während die CPU auf niedrigeren Takten gehalten wird, wodurch der Stromverbrauch und die Drosselung reduziert werden.

Mögliche Nachteile der Vulkan-API (Spoiler-Alarm: Es gibt nicht so viele)

Ich bin nicht pingelig; Ich finde es auch wichtig, die Vor- und Nachteile der Vulkan-API aufzulisten. Glücklicherweise gibt es nicht so viele Nachteile außer ein paar kleineren und möglicherweise ein oder zwei großen Nachteilen. Wenn Sie der Meinung sind, dass Vulkan das Beste seit geschnittenem Brot ist, und Sie es unbedingt bei Ihrem nächsten Projekt ausprobieren möchten, sollten Sie einige dieser Punkte berücksichtigen:

• Codekomplexität in bestimmten Szenarien hinzugefügt
• Time-to-Market
• Grad der Unterstützung durch die Industrie
• Vulkan ist auf einigen Plattformen (Desktops) möglicherweise nicht so relevant oder effektiv.
• Überzeugen Sie Entwickler, Vulkan auf einigen Plattformen zu verwenden
• Eingeschränkte Kompatibilität mit Legacy-Hardware

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

Time-to-Market ist ein weiteres Anliegen, ebenso wie die Implementierung von Vulkan in älteren Apps und Spielen. Vulkan ist immer noch eine technische Vorschau; erste Spezifikationen und Implementierungen werden bis Ende 2015 erwartet, sodass wir realistisch gesehen wahrscheinlich nicht viele reale Anwendungen vor Mitte 2016 sehen werden.

Die Unterstützung durch die Industrie sollte kein Problem sein; Immerhin ist dies ein Khronos-Standard, aber es kann eine Weile dauern. Das ist einer der Gründe, warum ich mich in diesem Beitrag auf das mobile Segment konzentriert habe. Mobile Software und Hardware entwickeln sich schneller, und es kann noch einige Quartale dauern, bis wir sehen, dass Vulkan Auswirkungen auf Desktop-Plattformen hat. So funktioniert die Industrie einfach, es gibt viel mehr Dinge, um die man sich in der Desktop-Nische kümmern muss: Unterstützung für professionelle Anwendungen, Horden von Heugabel-schwingenden Spielern, die über jeden zerrissenen Frame nachäffen, und so weiter. Die Tatsache, dass Vulkan von AMDs Mantle abgeleitet ist, ist jedoch ermutigend.

Während Vulkan in einer CPU-gebundenen Umgebung Wunder bewirken kann, insbesondere bei mobilen Mehrkern-SoCs, sind diese Leistungssteigerungen auf Desktop-Plattformen begrenzt. Desktops verarbeiten Mehrkernprozessoren mit einem höheren Maß an Effizienz, und die meisten grafisch anspruchsvollen Anwendungen sind GPU-gebunden.

Bis alle Teile des Puzzles zusammenpassen, zögern einige Entwickler möglicherweise, den Sprung zu wagen und mit Vulkan herumzuspielen. Viele Menschen haben einfach keine Zeit zum Experimentieren und lernen neue Fähigkeiten nur dann, wenn es absolut notwendig ist. Viel Geld zu verbrennen und Arbeitsstunden zu verschwenden, um bestehende Handyspiele für die Verwendung von Vulkan in diesem frühen Stadium zu optimieren, wird für viele Entwickler und Publisher keine Option sein.

Die Kompatibilität mit älterer Hardware könnte ein weiterer Anlass zur Sorge sein. Vulkan benötigt OpenGL ES 3.1- oder OpenGL 4.1-Hardware, begleitet von neuen Treibern. Beispielsweise können die GPUs der PowerVR-Serie 6 von Imagination Technologies dies unterstützen, Serie 5 jedoch nicht. Qualcomms Adreno 400-Serie unterstützt OpenGL ES 3.1, die 300er-Serie jedoch nicht. Die Mali T600- und T700-Serien von ARM unterstützen OpenGL ES 3.1, aber ältere Designs der T400-Serie werden nicht unterstützt. Glücklicherweise werden die meisten Geräte mit nicht unterstützten GPUs zu dem Zeitpunkt, an dem Vulkan relevant wird, aus dem Bild sein. Dazu gehören das iPhone 5/5C, das iPad der vierten Generation und Samsung-Geräte, die auf bestimmten Exynos-Chips der 5000er-Serie basieren. Qualcomm-basierte Geräte haben möglicherweise nicht so viel Glück, da GPUs der Adreno 300-Serie in relativ neuen und produktiven Designs wie dem Snapdragon 410, Snapdragon 600, Snapdragon 800 und 801 verwendet werden. Ich vermute jedoch, dass die meisten von ihnen mit der Zeit verschwunden sein werden Vulkan wird wirklich relevant.

Lebe lang und übertrage

Es ist noch zu früh, um zu sagen, ob Vulkan ein Game-Changer sein wird oder nicht, aber ich denke, Sie werden mir zustimmen, dass es viel Potenzial hat. Ich denke, es wird eine große Sache sein, und ich stütze diese Annahme auf ein Jahrzehnt Erfahrung in der GPU-Industrie. Es wird jedoch einige Zeit dauern, und ich vermute, Vulkan wird sich auf Mobilgeräten bemerkbar machen, bevor es beginnt, die Desktop-Landschaft zu verändern.

Etwa zur gleichen Zeit werden wir mit Vulkan-optimierten Treibern, Spiel-Engines und Spielen neue Hardware bekommen, mit der wir herumspielen können, und ich meine nicht nur geringfügige Hardware-Optimierungen. Die Entwicklung mobiler SoCs ist aus einer Reihe von Gründen ins Stocken geraten, auf die ich jetzt nicht näher eingehen werde, aber 2016 wird ein großes Jahr für die Branche, da 14/16-nm-FinFET-Knoten für mehr Hersteller verfügbar werden und eher für Mainstream-Hardware wirtschaftlich rentabel werden Flaggschiff-Chips.

Entwickler werden eine weitaus leistungsfähigere und effizientere Hardware haben, mit der sie herumspielen können, und eine neue Grafik-API mit geringem Overhead wird das i-Tüpfelchen sein. Ich hoffe aufrichtig, dass Hardwarehersteller aufhören, die Bildschirmauflösung als Marketing-Gimmick zu verwenden, da sinnlos hohe Auflösungen nichts für die visuelle Qualität tun, aber immer noch Energie verschwenden. Da der durchschnittliche Verbraucher dies leider nicht versteht und größere Zahlen auf der Verpackung sehen möchte, vermute ich, dass dies in absehbarer Zeit nicht passieren wird. Ich beabsichtige, dieses seltsame Problem in einem meiner nächsten Beiträge zu untersuchen. Wenn Sie sich also darüber ärgern, bleiben Sie dran und fühlen Sie sich frei, im Kommentarbereich Luft zu machen.