Vulkan: Nintendo Switch setzt auf Khronos-APIs

[PCGH-Redaktion]

Jetzt ist Ihre Meinung gefragt zu Vulkan: Nintendo Switch setzt auf Khronos-APIs

Nintendo setzt bei der Switch mit seinem Tegra X1 auf APIs der Khronos-Gruppe. Spiele-Entwickler können demnach auf Vulkan, OpenGL 4.6 und Open GL ES zurückgreifen. Letzteres wird laut Datenblatt von Nvidia bis Version 3.1 vom Tegra unterstützt.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Thread zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: Vulkan: Nintendo Switch setzt auf Khronos-APIs

 

[Sonmace]

400 GF hmmm wenn ich mir ZELDA ansehe dann gefält mir was ich sehe aber ich sehe auch eine sehr steriele welt, da bewegt sich kaum etwas.
Das bedeuted also das die Normalen spiele auf PS3 level laufen werden.

 

[aloha84]

400 GF hmmm wenn ich mir ZELDA ansehe dann gefält mir was ich sehe aber ich sehe auch eine sehr steriele welt, da bewegt sich kaum etwas.
Das bedeuted also das die Normalen spiele auf PS3 level laufen werden.

Was verstehst du unter steril?
Das nächste Zelda soll zumindest voller Physik-Spielereien sein, etwas was in Skyrim nicht vorhanden war.

 

[IronAngel]

ich hätte jetzt im mobilen Zustand 300 - 400 Gflops und im docking Modus so 600 - 800 Gflops erwartet. Das wäre jedenfalls was ich an einen Soc aus dem Jahre 2017 erwarten würde. Aber gut ist ja noch nicht alles in steingemeißelt und Grafik spielt bei Nintendo Games ja auch kaum eine Rollen. Bleibt halt alles wie es ist.

 

[Casurin]

Ich finde is irgendwie lustig wie voreingenommen hier berichtet wurde.
Warum ist es kalr, das auf vulkan gesetzt wird? Wurde doch voher noch so schön erwähnt das auch openGl 4.5 unterstüzt wird.
Und nein, mit ogl 4 wurde die Performanz im vergleich zu Ogl 3 nochmal deutlich erhöht und es braucht sich icht vor anderen APIs verstecken.

Es gibt schon lange möglichkeiten mit OpenGL (Auch schon mit 4.2) mit beinahe 0 overhead die hardware auf direkteste weise anzusprechen. Das problem ist eher das sich keiner mit OpenGl ausseinander setzt.




Wäre schön wenn die Leute OpenGL etwas mehr beachten würden - ist recht einfach, und läuft überall.

 

[Gelöschtes Mitglied 130761]

Bei einer Architektur, die von den Konsolen und PCs erheblich abweicht, war es im Grunde genommen logisch, dass sie Vulkan als API nutzen werden. DX12 würde man wegen der indirekten Unterstützung für Microsoft (also eines Mitbewerbers) nicht verwenden und eine eigene API kann man sich ganz einfach nicht erlauben, wenn man die Third-Party-Entwickler nicht (wieder) verlieren möchte.

Die Leistung (sofern die Gerüchte stimmen) macht mir allerdings Sorgen. Dann wäre die Switch ja CPU-seitig langsamer als das Shield-Tablet? Gut, man hat im portablen Modus auch nur die 720p, aber dennoch klingt das arg schwach.

Habe ja leistungstechnisch kein Aufschließen zu Sony und Microsoft erwartet, aber wie gesagt: So wäre die Switch doch arg schwach auf der Brust. Was würde das für zukünftige AAA-Spiele von Third-Party-Entwicklern bedeuten? Da können die Engines ja noch so gut skalieren, es müssten für die Switch einfach immense Kompromisse eingegangen werden...

 

[spawa93]

DX12 + Vulkan stehen ja noch ganz am Anfang ihrer "Karriere", wobei Vulkan eben den Vorteil hat, plattformunabhängig zu sein. Deshalb wird sich Vulkan mittelfristig und langfristig neben DX12 als "Must-Have-Renderer-Support" in den Big-Gaming-Engines etablieren und DX12 sogar langfristig ausstechen, denn auch andere BS-Plattformen wie etwa Linux werden in einem langjährigen Zeitraum performancemäßig gegenüber Windows 10 aufholen. Und dann ist da eben noch Valve, das Vulkan und Linux mit seinen nächsten (noch unangekündigten) AAA-Titeln enorm pushen dürfte.

 

[aloha84]

DX12 + Vulkan stehen ja noch ganz am Anfang ihrer "Karriere", wobei Vulkan eben den Vorteil hat, plattformunabhängig zu sein. Deshalb wird sich Vulkan mittelfristig und langfristig neben DX12 als "Must-Have-Renderer-Support" in den Big-Gaming-Engines etablieren und DX12 sogar langfristig ausstechen, denn auch andere BS-Plattformen wie etwa Linux werden in einem langjährigen Zeitraum performancemäßig gegenüber Windows 10 aufholen. Und dann ist da eben noch Valve, das Vulkan und Linux mit seinen nächsten (noch unangekündigten) AAA-Titeln enorm pushen dürfte.

Ersetze mal das Wort Vulkan mit OpenGL.
OpenGL war/ist ebenfalls plattformunabhängig und Valve hat ebenfalls AAA-Titel dafür gebracht, mit dem Ergebnis --> es hat sich nicht durchgesetzt.

 

[Herbststurm]

Finde ich gut, so besteht die Möglichkeit, dass bei Multiplattform-Titeln auch Windows7 /8.1 & vielleicht sogar Linux zum Zuge kommen.

 

[Mephisto_xD]

Ersetze mal das Wort Vulkan mit OpenGL.
OpenGL war/ist ebenfalls plattformunabhängig und Valve hat ebenfalls AAA-Titel dafür gebracht, mit dem Ergebnis --> es hat sich nicht durchgesetzt.

Und nein, mit ogl 4 wurde die Performanz im vergleich zu Ogl 3 nochmal deutlich erhöht und es braucht sich icht vor anderen APIs verstecken.

Es gibt schon lange möglichkeiten mit OpenGL (Auch schon mit 4.2) mit beinahe 0 overhead die hardware auf direkteste weise anzusprechen. Das problem ist eher das sich keiner mit OpenGl ausseinander setzt.

Wäre schön wenn die Leute OpenGL etwas mehr beachten würden - ist recht einfach, und läuft überall.

Und es ist in puncto Dokumentation und Bedienbarkeit der API Meilen hinter DirectX. Und es schleppt Altlasten der letzten 15 Jahre mit, sodass alles doppelt und dreifach implementiert ist - auch wenn nicht alle Methoden untereinander funktionieren. Und es hat einen Haufen Herstellereigene Erweiterungen. Und OpenGL allein nutzt nix, denn im Gegensatz zu DirectX braucht man noch zusätzliche APIs für Fenstermanagment, Netzwerk, Input und Audio. Ein auf OpenGL basiertes Spiel läuft eben nicht überall, der Portierungsaufwand ist nur ein wenig geringer. Dazu kommen historische Gründe, OpenGL war eben in der Bereitstellung von neuen Features immer hinten dran.

Es hat gute Gründe warum Spiele heutzutage in der Regel auf DirectX bzw. Direct3D setzten und nicht auf OpenGL, und der Grund ist nicht der M$-Geldkoffer.

 

[evilmane666]

Nintendo sollte lieber an Akkus forschen bzw an Kürzungen, Dan könnten so Konzepte wie die Switch Fruchten . So müssen zuviele kompromisse gemacht werden. Man stelle sich ne ungedrosselte ryzen APU vor, statt dem nvidia soc

 

[VikingGe]

Und es ist in puncto Dokumentation [...] Meilen hinter DirectX.

OpenGL Wiki

und Bedienbarkeit der API

Schonmal damit programmiert?

Und es schleppt Altlasten der letzten 15 Jahre mit, sodass alles doppelt und dreifach implementiert ist - auch wenn nicht alle Methoden untereinander funktionieren.

Teilweise richtig, wobei durch das Core Profile und hierdurch ein recht überschaubarer Satz an Funktionen vorgegeben ist. Ab davon wurden die 15 Jahre alten Altlasten mit der Definition des Core Profiles entfernt, die schlimmsten Altlasten sind vielleicht 7 Jahre alt, und keiner wird gezwungen, diese zu benutzen.

enn im Gegensatz zu DirectX braucht man noch zusätzliche APIs für Fenstermanagment, Netzwerk, Input und Audio

Auch wenn man Direct3D verwendet, braucht man noch andere APIs für Fenstermanagement, Netzwerk, Input und Audio. Dass sie irgendwas mit Direct und X heißen, ändert nichts daran, dass die alle nicht viel miteinander zu tun haben. Oder glaubst du, Input-Handling implementiert bei Microsoft sich von alleine, wenn man Dreiecke zur Grafikkarte schickt?

Ab davon: SDL.

Es hat gute Gründe warum Spiele heutzutage in der Regel auf DirectX bzw. Direct3D

Und du hast nicht einen aufgezählt. Nicht einmal "bessere Werkzeuge/Debugger" oder "vergeigtes OpenGL 3.0", was man als Argumente ja durchaus gelten lassen kann. Und auch die Gründe sind in Zeiten von RenderDoc und GL 4.5 eher historisch.

Nur ist der das Cross Platform-Argument auch mehr oder weniger hinfällig. Apple unterstützt de facto kein OpenGL mehr, und Linux war mit einem Prozent Marktanteil lange nicht interessant genug. Und mangels anderer wirklicher Vorteile bleibt dann eben jeder bei der Schnittstelle, die vor ~7 Jahren mal wirklich deutlich besser war.

Deshalb wird sich Vulkan mittelfristig und langfristig neben DX12 als "Must-Have-Renderer-Support" in den Big-Gaming-Engines etablieren und DX12 sogar langfristig ausstechen

Ich wette dagegen. Vulkan ist auf dem (Windows-)Desktop praktisch genau so gescheitert wie OpenGL - Apple geht lieber einen eigenen Weg, mit Linux dürfen sich Studios wie Feral auseinandersetzen, die nichts anderes machen als Windows-only-Software irgendwie mit grauenhafter Performance auf Linux zu portieren, und unter Windows <10 gibt es Dx11. Und da nunmal jeder schon irgendwo nen Dx11-Renderpfad rumfliegen hat und Microsoft so geschickt war, inkrementelle Portierung auf Dx12 zu ermöglichen, sollte klar sein, wer den Kampf für sich entscheidet. Vulkan wird dann eher wie bei der UE4 auf mobile Plattformen verbannt.

 

[Rollora]

Ersetze mal das Wort Vulkan mit OpenGL.
OpenGL war/ist ebenfalls plattformunabhängig und Valve hat ebenfalls AAA-Titel dafür gebracht, mit dem Ergebnis --> es hat sich nicht durchgesetzt.

nicht zu Vergessen ID Software zu ihren Glanzzeiten

 

[spawa93]

Ersetze mal das Wort Vulkan mit OpenGL.
OpenGL war/ist ebenfalls plattformunabhängig und Valve hat ebenfalls AAA-Titel dafür gebracht, mit dem Ergebnis --> es hat sich nicht durchgesetzt.

Wie so oft alles relativ zu betrachten: OpenGL war defacto der Ruler, als die Leistung noch gestimmt hat im Vergleich zu DX. Siehe idTech 3.

In Bezug auf Vulkan gibt es keine Feature- und Leistungsunterschiede zu DX12. Schätze eh, daß DX12 ein Fork von Mantle ist, auch wenn MS es nicht zugeben wird.

Vulkan wird die Standard-API für Android, das sagt alles bzgl der Behauptung der Windows-Fanboys, Vulkan sei/wird scheitern. Und auch MS kann nicht davon ausgehen, sich nochmal ein Jahrzehnt auf dem Quasi-Monopol bei Betriebssystemen ausruhen zu können.

Je länger eine kritische Masse von Konsumenten bei Windows 7/8 verharrt, desto besser sind die Aussichten für Vulkan auf dem PC. Denn auch Windows 7/8 Benutzer wollen spielen.

 

[Rollora]

Wie so oft alles relativ zu betrachten: OpenGL war defacto der Ruler, als die Leistung noch gestimmt hat im Vergleich zu DX. Siehe idTech 3.

Das lag nicht an OpenGL, das lag an der Engine

In Bezug auf Vulkan gibt es keine Feature- und Leistungsunterschiede zu DX12. Schätze eh, daß DX12 ein Fork von Mantle ist, auch wenn MS es nicht zugeben wird.

Direct 3D ein Fork von Mantle? Das wage ich jetzt mal zu bezweifeln.

Vulkan wird die Standard-API für Android, das sagt alles bzgl der Behauptung der Windows-Fanboys, Vulkan sei/wird scheitern. Und auch MS kann nicht davon ausgehen, sich nochmal ein Jahrzehnt auf dem Quasi-Monopol bei Betriebssystemen ausruhen zu können.

Ob es sich dabei nicht um ein speziell angepasstes Vulkan handelt wissen wir nicht. Auch OpenGL (ES) war auf Handys der Standard. Durchgesetzt hat es sich am Desktop trotzdem nicht.

Je länger eine kritische Masse von Konsumenten bei Windows 7/8 verharrt, desto besser sind die Aussichten für Vulkan auf dem PC. Denn auch Windows 7/8 Benutzer wollen spielen.

Stimmt natürlich. Aber ich wage es zu bezweifeln, dass Spieler ewig bei W7/8 bleiben, wenn/falls DX12 ordentliche Vorteile bringen wird.

 

[Mephisto_xD]

OpenGL Wiki

Hehe, guter Witz. Vergleich das mal mit der mitgelieferten Dokumentation aus dem DirectX SDK.

Schonmal damit programmiert?

Um genau zu sein habe ich eine mehr oder weniger komplette Engine in OpenGL als Hobbyprojekt geschrieben. "Nur" OpenGL 3 anstatt 4.5, aber immerhin.

Teilweise richtig, wobei durch das Core Profile und hierdurch ein recht überschaubarer Satz an Funktionen vorgegeben ist. Ab davon wurden die 15 Jahre alten Altlasten mit der Definition des Core Profiles entfernt, die schlimmsten Altlasten sind vielleicht 7 Jahre alt, und keiner wird gezwungen, diese zu benutzen.

Ändert aber nichts daran, dass OpenGL im wesentlichen eine Stackmachine mit globalen Variablen und Funktionen ist. DirectX hingegen ist seit Version 10 eine moderne, objektorientierte API, ist also wesentlich weniger anfällig für Spagetticode.

Nur ist der das Cross Platform-Argument auch mehr oder weniger hinfällig. Apple unterstützt de facto kein OpenGL mehr, und Linux war mit einem Prozent Marktanteil lange nicht interessant genug. Und mangels anderer wirklicher Vorteile bleibt dann eben jeder bei der Schnittstelle, die vor ~7 Jahren mal wirklich deutlich besser war.

Eben. Es hat keine Vorteile OpenGL zu nutzen, also warum wechseln? Kostet nur Zeit und damit Geld.

 

[spawa93]

Das lag nicht an OpenGL, das lag an der Engine

Direct 3D ein Fork von Mantle? Das wage ich jetzt mal zu bezweifeln.

Ob es sich dabei nicht um ein speziell angepasstes Vulkan handelt wissen wir nicht. Auch OpenGL (ES) war auf Handys der Standard. Durchgesetzt hat es sich am Desktop trotzdem nicht.

Stimmt natürlich. Aber ich wage es zu bezweifeln, dass Spieler ewig bei W7/8 bleiben, wenn/falls DX12 ordentliche Vorteile bringen wird.

Ist dir schon aufgefallen, daß auch DX12 genau wie Vulkan nur ein Renderpfad ist, genau wie OpenGL damals bei idTech nur ein Renderpfad war neben DX. Dasselbe Argument, das du selbst gegen Vulkan anführst, spricht dann demnach gegen DX12.

Bei DX12 fällt schon die extreme Ähnlichkeit zu Vulkan auf, das ja ebenso im Kern ein verbessertes Mantle ist.

Windows XP hat sich extrem lange gehalten, bei einer nicht zu vernachlässigbaren Anzahl von Windows-Nutzern. Dasselbe könnte MS mit Windows 7 ebenfalls drohen.

 

[VikingGe]

Ob es sich dabei nicht um ein speziell angepasstes Vulkan handelt wissen wir nicht.

Doch, wissen wir, siehe Hardware-Datenbank mit diversen Einträgen von Mobil-GPUs, oder einen Blog-Eintrag von Imagination, die nebenbei auch schon Extensions für Vulkan eingereicht haben. Der Grund, warum das funktioniert, ist, dass Vulkan kaum Features zwingend voraussetzt - selbst Geometry Shader, die jede Desktop-GPU seit Dx10-Zeiten hat, sind optional. OpenGL verlangt dagegen alles mögliche für 4.5-Konformität, genau deshalb existiert OpenGL ES.

Hehe, guter Witz. Vergleich das mal mit der mitgelieferten Dokumentation aus dem DirectX SDK.

Hat mich in Kombination mit den Spezifikationen für diverse Extensions bisher nicht im Stich gelassen, um ehrlich zu sein. Das Wiki enthält genug Material, um die Zusammenhänge zu verstehen, für die Dokumentation von Einzelfunktionen gibt es Manpages oder eben das hier, und abgesehen von dem DSA-Kram stehen auch die alle im Wiki.

Microsoft macht das ganze (sofern die Dokumentation, von der du redest, der Online-Version entspricht) wohl etwas schöner mit einer Art Guide, um den Leuten einen Überblick zu geben, ab davon sehe ich jetzt keinen "meilenweiten" Vorsprung.

DirectX hingegen ist seit Version 10 eine moderne, objektorientierte API, ist also wesentlich weniger anfällig für Spagetticode.

Also wenn ich mir sowas wie ID3D11DeviceContext mal genauer anschaue, sehe ich da haufenweise Setter-Methoden wie OMSetBlendState, GSSetShader, DSSetConstantBuffers und eigentlich genau den gleichen Mist, den man auch von OpenGL kennt. Das ist nicht modern, das ist letztenendes nichts anderes als eine State Machine, die sich hinter ein paar C++-Interfaces versteckt. Die teils bescheuerte Benennung der Methoden (wofür zum Henker steht "OM"?) kommt noch dazu.

Falls du auf Bind-to-Edit anspielst: Ja, das war *******, gehört dank Direct State Access aber inzwischen auch der Vergangenheit an. Auch die Bindung von VAOs an spezifische Vertex-Buffer gibt es so nicht mehr, bzw. es gibt eine bessere Alternative dazu. OpenGL 4.4 und 4.5 wurden ganz gut aufgeräumt, und man kann inzwischen hervorragend C++-Klassen drum herum bauen, ohne globale Zustände zu verändern - wir sind uns aber einig, dass GL3 keine wirkliche Meisterleistung war vom API-Design her.

Anyway, wenn man irgendwas mit wirklich modernem Design haben will, kommt man um Vulkan oder eben D3D12, wobei mir bei letzterem der Überblick fehlt, nicht herum. Auch wenn der Arbeitsaufwand bis zum ersten Dreieck um einige Größenordnungen höher liegt als bei OpenGL.

 

[Kukuruz]

Als Alternative bliebe nur DirectX 12, was für Sony und Nintendo aus politischen Gründen eher nicht in Frage kommt, oder eine Eigenentwicklung. Letzteres sehen Entwickler aber gar nicht gerne, aus logischen Gründen. Schon am PC-Markt wurde in der Vergangenheit immer wieder schnell deutlich, dass API-Alleingänge in der Regel nicht fruchten.

Als das dürfte sich noch nicht bis zu Sony durchgesprochen haben die ja bei der PS4 zwei APIs (GNM und GNMX) als Eigenentwicklung im Einsatz haben. Und die Entwickler dürfte das zumindest bei der PS4 auch nicht stören bei den Verkaufszahlen.

Aber gut, Nintendo hätte da wieder ein eigenen schweren Stand. Abweichende Architektur zur Konkurrenz und dann eventuell auch noch eine eigene API? Hätte vermutlich gleich verschreckt.

 

[Olstyle]

Doch, wissen wir, siehe Hardware-Datenbank mit diversen Einträgen von Mobil-GPUs, oder einen Blog-Eintrag von Imagination, die nebenbei auch schon Extensions für Vulkan eingereicht haben. Der Grund, warum das funktioniert, ist, dass Vulkan kaum Features zwingend voraussetzt - selbst Geometry Shader, die jede Desktop-GPU seit Dx10-Zeiten hat, sind optional.

Und damit hätte man genau die alt bekannten Schwächen wie OGL3. Das alte Problem von OGL sind doch die nicht fix geforderten Features und Vendor spezifische Extensions, die im Endeffekt dafür sorgen dass man quasi einen Renderpfad pro GPU-Hersteller (und unter Umständen noch Generation) braucht.

Zum API Design:
Ich kenne jetzt das konkrete Design der Grafikapis nicht, mache aber beruflich auch SW-Design. Und dabei ist immer das wichtigste nicht den "golden Hammer" anzusetzen. Sprich wenn etwas im Endeffekt ein paar Zustände verwalten soll ist es eine Zustands Maschine, wenn es definierte Operationen ohne Nebenbedingungen umsetzen soll dann nicht. Ergo wenn der 3D Render feste Zustände braucht dann darf er auch eine Statemashine sein, das ist ansich erst mal kein schlechtes oder gutes Design.