Vulkan: Nintendo Switch setzt auf Khronos-APIs

[VikingGe]

Das alte Problem von OGL sind doch die nicht fix geforderten Features [...]

OGL hat doch fix geforderte Features. Ab davon sehe ich nicht, was dadurch besser wird - wenn deine Anwendung zwingend Tessellation Shader braucht, läuft sie eben nicht auf Smartphone-GPUs, egal ob die Schnittstelle das nun zwingend fordert oder nicht.

Ab davon - wenn Flexibilität ein Nachteil ist, hat Dx12 den auch mit den ganzen Feature Levels und Tiers. Wenn man natürlich in 30 Jahren Code schreiben will, der sowohl auf GCN 1.0 als auch den bis dahin aktuellen GPUs läuft und jeweils alle Vorteile der Hardware ausnutzt... gute Nacht, aber das macht niemand.

[...] 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.

Das ist ein Märchen. Einerseits fällt mir jetzt aus dem Stegreif z.B. keine Nvidia-Extension ein, für die AMD oder Intel ein eigenes Äquivalent hätten, andererseits - was spricht dagegen, sich auf ARB-, KHR- und ggf. EXT-Extensions zu beschränken? Die Vendor-Extensions sind bis auf wenige Ausnahme dafür da, irgendwann als herstellerunabhängige ARB-Extension in den Standard einzufließen, nicht für den produktiven Einsatz für die nächsten 10 Jahre.

Eine Ausnahme wäre sowas wie AMD_gcn_shader. Da steckt die Begründung auch gleich im Namen.

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.

Das Design ist aber insofern schlecht, als dass a) wir von Zuständen auf der GPU reden und nicht (nur) innerhalb der Software-Ebene, b) das Design kaum Multithreading zulässt und c) das ganze auch keine wirklich gute Abstraktion ist. Wenn man einen Framebuffer mit vier Color Targets fürs G-Buffer-Rendering aktiviert und gleichzeitig noch der Shader fürs Generieren von Shadow Maps aktiv ist, hat man zwangsläufig einen Zustandsvektor, mit dem man nichts anfangen kann.

Die neuen APIs haben auch ihren Satz an Zuständen, aber a) deutlich stärker gebündelt, b) nicht global verwaltet, sondern pro Command Buffer. Damit wäre dann auch das Multithreading-Problem gelöst, wenn man seine Command Buffer in jedem Frame neu generieren muss.

 

[Rollora]

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.

Es spricht und sprach immer vieles gegen Direct X.
Aber die Marktmacht von Microsoft ist nunmal groß.
Auch beim schrumpfenden PC Markt: der Spielermarkt wächst sogar.

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

Kannst du diese "ähnlichkeit" näher erläutern. Microsoft benutzt seit der Xbox eine Low-Level Variante von Direct X. Es ist wohl eher wahrscheinlich, dass man die API der Xbox 360 und One weiterentwickelt hat, als dass man Mantle (das sicher auch einen EInfluss hatte, keine Frage, aber sicher nicht "übernommen" wurde) übernommen hat.

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.

Ja das wird es auch. Zwar nicht in dem Ausmaß, aber dennoch: Win7 werden wir lange in den Charts der am meisten verbreiteten Betriebssysteme.
Bei XP lags daran:

-ewig lange Updates
-ressourcenschonend
-5 Jahre kein Nachfolger
- als der Nachfolger dann kam, war vieles nicht kompatibel (hardwaremäßig)
- der Nachfolger hatte einen für damalige Zeit hohen Hardwarehunge (20 GB installation, hohe Anforderungen an CPU und RAM)
- genau zu der Zeit kamen auch Netbooks auf, die mit XP um Welten schneller liefen als mit Vista (Atom Singlecore CPU und 1 GB RAM sei dank...)
- Vista hatte am Anfang auch viele Softwarekompatibiltätsprobleme. Deshalb kam mit 7 auch die Virtuelle Maschine für vollständige XP Emulation
- mein Grund: Vista und 7 hatten einen schlechteren Sound, weil EAX und Co "rausgepatcht" wurden. Ältere Spiele klingen auf XP bis heute besser, als moderne Spiele auf Win 7,8,10 wenn man eine dementsprechende Soundhardware hat. Außerdem lief und läuft bis heute manche Software nicht auf 7/8/10 und sogar mein Plotter
- XP hatte eigentlich keinen ernstzunehmenden Kopierschutz.

der Sprung von 7 auf 10 wird sich dennoch noch hinziehen. Unternehmen sind wegen der Privatsphäreoptionen und anderen Datenübermittlungen sicher noch nicht so schnell bereit umzusteigen. Das Sysem muss noch etwas reifen. Außerdem bietet 10 kaum einen Mehrwert für viele.
Es weckt dann auch nicht gerade Vertrauen, dass nach dem letzten Update plötzlich auf vielen PCs kein Internet geht... (das hatte ich bei insgesamt 3 Computern von 8).
Kurzum: Wenn der Support von W7 und 8 ausläuft werden wohl auch Firmen auf W10 umsteigen, vorher nur zögerlich.

 

[VikingGe]

Microsoft benutzt seit der Xbox eine Low-Level Variante von Direct X. Es ist wohl eher wahrscheinlich, dass man die API der Xbox 360 und One weiterentwickelt hat, als dass man Mantle (das sicher auch einen EInfluss hatte, keine Frage, aber sicher nicht "übernommen" wurde) übernommen hat.

Sollte nicht Mantle eine gewisse Ähnlichkeit zu den Konsolen-APIs gehabt haben? Damit schließt sich doch letztenendes der Kreis.

Ist auch eigentlich egal, wer von wem abgeschrieben hat, Fakt ist jedenfalls, dass sich die beiden Desktop-APIs stark ähneln, auch wenn Microsoft kein Äquivalent zu Renderpasses in Vulkan hat und Vulkan im Moment nicht in der Lage ist, sowas wie Conservative Rasterization anzusprechen.

 

[Olstyle]

Das Grundsätzliche Ziel war bei allen das Selbe, also werden die Umsetzungen auch nicht Kilometer auseinander liegen.

OGL hat doch fix geforderte Features. Ab davon sehe ich nicht, was dadurch besser wird - wenn deine Anwendung zwingend Tessellation Shader braucht, läuft sie eben nicht auf Smartphone-GPUs, egal ob die Schnittstelle das nun zwingend fordert oder nicht.

Wenn die Schnittstelle den "Tier" definiert und die HW diesen eben erfüllt oder nicht habe ich eine echte Hardware Abstraktion. Wenn dagegen jeder Hersteller den "Tier" selbst definiert ist die Abstraktion Geschichte.
Das Selbe gilt für Extentions. Um einen "GNC Shader" anzusprechen braucht man keine HAL-API, da kann man auch direkt den Treiber ansprechen.

 

[spawa93]

Sollte nicht Mantle eine gewisse Ähnlichkeit zu den Konsolen-APIs gehabt haben? Damit schließt sich doch letztenendes der Kreis.

Ist auch eigentlich egal, wer von wem abgeschrieben hat, Fakt ist jedenfalls, dass sich die beiden Desktop-APIs stark ähneln, auch wenn Microsoft kein Äquivalent zu Renderpasses in Vulkan hat und Vulkan im Moment nicht in der Lage ist, sowas wie Conservative Rasterization anzusprechen.

Nein, Mantle war ein Verkaufsargument für Microsoft und Sony, sich für die AMD-Plattform zu entscheiden. Hardware-Plattform und die darauf abgestimmte Low-Level API Mantle waren ein rundes Paket für die Konsolenhersteller.

Natürlich hatten beide Firmen bereits in den Jahren der Verkaufsverhandlungen mit AMD Zugang zu Hardware-Prototypen und Mantle. Daraus folgt, daß MS sehr genau im Bilde über den Funktionsumfang und die Leistungsfähigkeit von Mantle war. Höchstwahcrscheinlich verfügte MS auch all die Jahre über den Sourcecode von Mantle. Das ist so üblich bei besonderen Kunden. Dasselbe bietet MS auch Kunden von Windows an: Einblick in dessen Sourcecode.

Das legt die große Ähnlichkeit von DX12 zu Mantle nahe.

 

[VikingGe]

Wenn die Schnittstelle den "Tier" definiert und die HW diesen eben erfüllt oder nicht habe ich eine echte Hardware Abstraktion. Wenn dagegen jeder Hersteller den "Tier" selbst definiert ist die Abstraktion Geschichte.

Was meinst du damit? Ob eine Grafikkarte z.B. Tessellation unterstützt oder nicht, kann man einfach abfragen, siehe hier (Chapter 31). Dafür sind doch gerade Features und Limits definiert, damit die Anwendung eben weiß, was die Hardware unterstützt und was nicht. Ich sehe da jetzt nichts herstellerabhängiges.

Was Microsoft bei Feature Levels und Tiers macht, ist letztenendes auch nichts anderes als einen Haufen davon zu gruppieren und dem einen Namen zu geben.

Edit: Bevor sich jetzt irgendjemand über die HTML-Dokumentation lustig macht: Es gibt davon auch ne PDF-Version, die ist um einiges praktischer.

Das Selbe gilt für Extentions. Um einen "GCN Shader" anzusprechen braucht man keine HAL-API, da kann man auch direkt den Treiber ansprechen.

Dafür müsste der Treiber aber erst einmal eine Schnittstelle bereitstellen, die mit dem Userspace-Treiber für die jeweilige Schnittstelle harmoniert. Ich weiß gerade nicht einmal, wofür die Extension im Detail gut ist, hat allerdings nur Auswirkungen auf Shader -sind AFAIK aber nicht die aus Doom bekannten Shader Intrinsics.

Khronos bietet nun aber diesen Extension-Mechanismus, also wird er entsprechend genutzt. Und nochmal, es gibt keine Pflicht und auch keinen Grund, irgendwas davon produktiv zu benutzen, und keinen Grund, Vendor-Extensions generell zu verteufeln, die dürften - bis auf solche wirklich spezifischen Sachen - wie bei OpenGL eher zur Weiterentwicklung der Schnittstelle beitragen - wenn die Khronos Group ihre Arbeit macht.