News Low-Level-API: Unity Engine mit DirectX 12 schneller auf der Xbox One

[ampre]

Hätte AMD nicht den massiven Fehler gemacht und Mantle in Kooperation mit EA/Dice auf den Markt geworfen, dann hätte Mantle tatsächlich was werden können. Aber da Battlefield 4 der große Hit werden sollte und Mantle so krass darstellen sollte ... war es einfach eine Totgeburt! Ich kann mich noch erinnern wie 50% aller AMD Systeme im 30 Minutentakt einen schönen Redscreen produzierten und ein hartes Trennen vom Strom benötigten. Macht Nvidias Dummheit Raytracing mit EA/Dice in Battlefield 5 groß auf den Markt zu werfen umso trauriger.

Wer nicht hören will muss leider fühlen ...

Was erzählst du da? Ich hatte keine Redscreen Quellen für deine Anschuldigungen?

 

[xexex]

Quatsch, wer von den vielen Entwicklern nutzt denn die neuesten Features derart, dass der Spieler etwas davon merkt. Und wegen ein paar Features die API wechseln und sich neu einarbeiten? Da lache ich mich doch ein wenig schlapp.

Ein Feature hier ein Feature dort, im Moment nutzt so gut wie niemand Vulkan und daran wird sich nichts ändern wenn die Entwicklung so langsam voranschreitet. Du sagst es ja selbst, dass niemand wegen ein paar Features die API wechselt, also bleibt man einfach bei DX12.

Alle Firmen die RT oder DLSS Unterstützung angekündigt haben werden dies jetzt und auch in Zukunft mangels Unterstützung seitens Vulkan mit DX12 als API umsetzen. Kommendes Jahr kommen neue Chips von AMD, darauf folgendes Jahr stellt Intel seine Grafikkarten vor, womöglich bringen auch diese wieder neue Features und Vulkan bleibt auch dort außen vor.

Damit ist das Schicksal von Vulkan letztlich besiegelt und es wird ein Nischendasein für ein paar Linux Portierungen und auf Android Smartphones führen. Niemand interessiert sich für eine API die 1-2 Jahre benötigt um aktuelle GPU Generationen vollständig zu unterstützen.

 

[noxon]

Mit dem großen Unterschied, dass OpenGL nie bedeutend effizienter war als DirectX und afaik auch noch nie ähnlich einfach benutzbar war.

Und wer sagt dir, dass es jetzt so sein wird?
Man sollte außerdem bedenken, dass bei der Wahl der API nicht nur wichtig, wie einfach sie benutzbar ist oder was für Features sie bietet.
Viel wichtiger ist eigentlich, wie gut das Tooling ist, dass dafür bereit steht und wie gut es sich in vorhandene Entwicklungstools integrieren lässt.
Hersteller wie Nvidia oder AMD bieten ihre Profiling und Debugging-Tools und diverse Plugins für Entwicklungsumgebungen in vollem Umfang hauptsächlich für DirectX an. Zum Beispiel so etwas wie Nsight.
Vulkan wird zwar unterstützt, aber oftmals nur im reduziertem Umfang.
Das kann man fast mit der Treibersituation zwischen Linux und Windows vergleichen. DirectX wird von den Herstellern unterstützt und gepflegt, während sich bei Vulkan die Community selbst um die Sachen kümmern muss, was dementsprechende Ergebnisse hervorbringt.

Solche Tools sind wichtiger als alle kleinen Vor- und Nachteile der beiden APIs und von daher fällt die Entscheidung auch oft auf DirectX weil das Tooling dort einfach besser ist.

Eine gute Dokumentation ist übrigens auch nicht zu vernachlässigen, wenn es um die Wahl der API geht und gerade da stinkt die Vukan-Doku total ab. Da braucht man eine GBit Leitung um die durchlesen zu können.
Klick dich da mal durch: Vulkan
und dann vergleich das mal mit Microsofts Doku: DX12

All solche Dinge fließen auch mit in die Entscheidung ein und das sind alles Gründe, warum Entwickler immer wieder zu DirectX greifen anstatt zu Vulkan.

 

[VikingGe]

Eine gute Dokumentation ist übrigens auch nicht zu vernachlässigen, wenn es um die Wahl der API geht und gerade da stinkt die Vukan-Doku total ab.

Also das ist wirklich mit Abstand die falscheste Aussage, die ich seit langem gelesen habe.

Erstmal gibts die Vulkan-Docs auch offiziell als PDF auf der Khronos-Seite oder auch chunked, wenn man sich am Format stört, und zweitens ist der Inhalt der Dokumentation (größtenteils) hervorragend, Verbesserungsbedarf gibt es vor allem bei dem WSI-Kram (und GLSL, aber das ist nicht direkt Teil der Vulkan-Spec und auch nicht zwingend nötig).

Wenn es nach Dokumentation ginge, dürfte eigentlich niemand D3D11 verwenden, sehr häufig fehlten Informationen, welche Interfaces man von welchen Objekten abrufen kann oder sind zumindest sehr gut versteckt (z.B. ID3D10Multithread von ID3D11DeviceContext, Nioh verwendet das), hier wird nicht erklärt, was passiert, wenn man D3D11_INPUT_PER_INSTANCE_DATA mit InstanceDataStepRate=0 kombiniert (ja, das geht und wird fröhlich von GTA V genutzt), hier steht nirgendwo, dass Render Targets auch unterschiedliche Größe haben können und als Render-Area das kleinste Target genommen wird, bei DrawAuto ist mir bis heute nicht klar, ob vom Anfang des Buffers oder nur ab dem letzten SOSetTargets-Offset gerendert werden soll. Wie genau sich StartVertexLocation und StartInstanceLocation in DrawInstanced etc. auf SV_VertexID und SV_InstanceID im Vertex Shader auswirken, steht hier nicht. Wie genau die Invariance-Regeln für Shader-Outputs aussehen, erzählt einem auch niemand.

Und Teile der API selbst sind einfach nur furchtbar (es gibt insgesamt 31 verschiedene Structs, die beschreiben, welchen Teil einer Ressource man nun in seinen Views haben will, hier sind allein 11 davon...), von Bugs in der Runtime ganz zu schweigen (immerhin sind die dokumentiert).

Und dann gibt es noch haufenweise komplett undokumentierte Treiber-Quirks, auf die sich viel zu viele Spiele inzwischen einfach verlassen, z.B. dass alle GPU-Ressourcen standardmäßig mit Nullen initialisiert werden, weil sonst Blödsinn gerendert wird (hust Nier), dass man problemlos SRVs mit D3D11_SRV_DIMENSION_TEXTURE2DARRAY an Texture2D-Slots binden kann (hust wieder Nier) oder ähnliches mit Cube Map-Views und Texture2DArray-Slots (Diablo 3), und dass TGSM in Compute Shadern ebenfalls mit Nullen initialisiert wird, weil Quantum Break sonst undefinierte Daten liest.

Und noch mal zurück zum Format, viele der Links der D3D11-Docs führen auch mal zur falschen Seite, seitdem Microsoft die ganze Seite umgestaltet hat, und manche Seiten haben auch Formatierungsprobleme.

Vulkan wird zwar unterstützt, aber oftmals nur im reduziertem Umfang.

Das ist aber auch wieder so eine Nvidia-Spezialität, AMDs Profiler unterstützt Vulkan problemlos.

 

[noxon]

Wenn es nach Dokumentation ginge, dürfte eigentlich niemand D3D11 verwenden, sehr häufig fehlten Informationen, welche Interfaces man von welchen Objekten abrufen kann oder sind zumindest sehr gut versteckt (z.B. ID3D10Multithread von ID3D11DeviceContext, Nioh verwendet das)

Das ist ja auch nicht so einfach, da man für D3D10Multithread auf die D3D10 Emulation zurückgreifen muss und ständig zwischen zwei Devices wechseln muss. Siehe Remarks

hier wird nicht erklärt, was passiert, wenn man D3D11_INPUT_PER_INSTANCE_DATA mit InstanceDataStepRate=0 kombiniert (ja, das geht und wird fröhlich von GTA V genutzt),

Weil es wahrscheinlich nicht der Spezifikation entspricht es so zu nutzen, wenn ich mir das hier so durchlese.

"The number of instances to draw using the same per-instance data before advancing in the buffer by one element. This value must be 0 for an element that contains per-vertex data (the slot class is set to D3D11_INPUT_PER_VERTEX_DATA). "

Entweder man nutzt input_per_instance_data oder input_per_vertex_data und nur im zweiten Fall ist eine DataStepRate von 0 erlaubt, was auch logisch erscheint.
Wenn GTA da etwas anderes macht, dann halten die sich nicht an die Spezifikation, was auch der Grund dafür ist, warum jedes Spiel mittlerweile seine eigenen speziellen Treiberoptimierungen benötigt bevor es überhaupt released werden kann.

hier steht nirgendwo, dass Render Targets auch unterschiedliche Größe haben können und als Render-Area das kleinste Target genommen wird

Natürlich steht das da.

"All render targets must have the same size in all dimensions (width and height, and depth for 3D or array size for *Array types). "

Bedeutet also, dass du keine unterschiedlichen Größen haben darfst. Wenn du unterschiedliche Größen verwendest, dann hälst du dich wieder nicht an die Spezifikation der API. Das hast du einfach nicht zu tun und wenn du es doch machst, dann musst du halt selber rauszufinden, was passiert. Das kannst du nicht der Dokumentation anlasten.

bei DrawAuto ist mir bis heute nicht klar, ob vom Anfang des Buffers oder nur ab dem letzten SOSetTargets-Offset gerendert werden soll. Wie genau sich StartVertexLocation und StartInstanceLocation in DrawInstanced etc. auf SV_VertexID und SV_InstanceID im Vertex Shader auswirken, steht hier nicht. Wie genau die Invariance-Regeln für Shader-Outputs aussehen, erzählt einem auch niemand.

Sorry, aber das gucke ich mir jetzt nicht auch noch alles an, aber ich nehme an, dass das jeder normale Entwickler auch alles aufklären kann.

Und noch mal zurück zum Format, viele der Links der D3D11-Docs führen auch mal zur falschen Seite, seitdem Microsoft die ganze Seite umgestaltet hat, und manche Seiten haben auch Formatierungsprobleme.

Also bei mir wird es schon angezeigt, obwohl sich die eigentliche Seite tatsächlich in einem anderen Dokumentation-Set befindet. MS erkennt das aber und zeigt sie trotzdem an und bietet eine Möglichkeit zum Umschalten des Dokumentation-Sets an. Kein Beinbruch, wie ich finde.

Aber wir werden ja sehen. Wenn D3D12 so buggy, komplex und schlecht dokumentiert ist und Vulkan alles besser macht, dann steht der offenen API ja nichts mehr im Wege.

 

[tek9]

Da wird ein Artikel zu einer API für die XBOX veröffentlicht und die Kommentare sind größtenteils das übliche DX vs OpenGL vs Vulkan Gebrabbel von API Fanboys

Das ganze wird mit den alternativen Fakten von irgendwelchen selbsternannten Experten aufgehübscht. Der vorläufige Tiefpunkt :

Da Konsolen meist an TVs ohne Adaptive Sync (G-Sync, Freesync) betrieben werden und ihr Signal mit 60 Hz ausgeben, sind 60 und 30 FPS die einzigen Framerates, die an solchen Displays ruckelfrei darstellbar sind.

Du solltest zumindest mal von Triple Buffering gehört haben bevor du Beiträge in Fachdiskussionem schreibst. Dann wäre Dir klar warum Dein Beitrag peinlich ist

 

[acc]

Schöne Entwicklung. Nachdem Pascal endlich Geschichte ist, kann DX12 im großen Umfang kommen.

weil pascal ja auch kein dx12 kann.

 

[Laggy.NET]

Du solltest zumindest mal von Triple Buffering gehört haben bevor du Beiträge in Fachdiskussionem schreibst. Dann wäre Dir klar warum Dein Beitrag peinlich ist

LoL, bevor du hier einen auf Besserwisser machst, erklär doch mal ganz genau, was bei meinem Beitrag nicht korrekt war. Ich bin gespannt. Ich möchte behaupten, dass ich mich mit dem Thema mehr als ausreichend lange beschäftigt habe...

Ich weiß sehr wohl, was triple buffering ist, wie kommst du darauf, dass ich nicht weiß, was das ist?. Ohne Triple Buffering würden die FPS ja auch direkt auf 30 Fallen, sobald man knapp unter 60 FPS kommt bzw. direkt auf 20 FPS, wenn 30 nicht mehr gehalten werden können. Wies aussieht, verstehst du einfach nicht, wovon ich rede, da du dich anscheinend nie im Detail mit der Problematik der Bildsynchronisation und der Verfahren beschäftigt hast.

Fast alle Konsolenspiele arbeiten mit Tripple Buffering, auch am PC ist bei aktivem Vsync heutzutage quasi immer Triple Buffering (oder eine Form davon, wie z.B double buffering mit render ahead queue, was praktisch das selbe ergebnis wie richtiges Triple Buffering liefert) aktiv.

Das ganze ändert trotzdem nichts daran, dass Microruckeln entsteht bzw. aus dem TV Bereich auch als Pull-down-judder bekannt.

Sobald Framerates dargestellt werden, dessen Frametime nicht exakt ein Vielfaches der Periodendauer der Bildwiederholfrequenz ist, gibt es Ruckeln.

Mal ein Beispiel: 45 FPS werden auf einem 60 Hz Display bei aktivem TripleBuffering dargestellt, indem Frame 1 für 16,66 ms sichtbar ist, Frame 2 für 33,33 ms (doppelt so lange), Frame 3 für 16,66 ms, Frame 4 für 33,33 ms usw. (wenn du mir nicht glaubst, dann miss mit einer HighSpeed Cam z.B. 240 FPS slow mo am Smartphone nach)
Man hat also nicht mehr diesen Hard-lock auf 30 oder gar 20 FPS, trotzdem kommt man nicht darum herum, entweder einen, zwei oder drei KOMPLETTE Display Refreshes abzuwarten. Je nach Framerate ändert sich der Anteil der 16,66 ms Frames im Verhältnis zu den 33,33 ms Frames. So kann man innerhalb einer Sekunde im Schnitt jede beliebige Framerate (in dem fall zwischen 30 und 60) darstellen. Würde man das nicht tun bzw. Nicht auf einen kompletten Refresh warten, gäbs schließlich wieder Tearing.

Im TV Bereich ist das ganze wie gesagt als Pull-Down Judder bekannt und beschreibt des selbe Problem. Wenn ein TV mit 60 Hz läuft, bzw. ein 60 Hz HDMI Signal erhält, aber die Framerate des Filmes bei 24 oder 25 FPS liegt, dann gibts Microruckeln. Entweder man schaltet den HDMI stream auf 24 Hz, (das muss der TV unterstützen) oder man beschleunigt das Video auf 25 FPS, was perfekt mit einer 50 Hz Ausgabe harmonieren würde. Und 50 Hz kann jeder TV mit HD Ready logo....

Du siehst also, dass das ein gängiges Problem ist. Wenn du behauptest, Triple Buffering würde dieses Problem lösen, dann hast du absolut keine Ahnung.

Triple Buffering löst das Problem des hard locks auf eine gewisse Framerate, die ein Teiler der Displayfrequenz ist.
Um aber das Microruckeln loß zu werden wurde Adaptive Sync, aktuell in Form von G-Sync und Freesync eingeführt. Deren EINZIGER zweck ist es, genau dieses Microruckeln zu beheben, das mit TripleBuffering bei beliebigen Framerates entsteht, indem die Displayfrequenz stets der Framerate entspricht. Bzw. umgekehrt, die Grafikkarte stößt mit der Ausgabe eines Frames den Display refresh an. Vsync ist somit nicht mehr nötig.

Ohne Adaptive Sync ist und bleibt der einzige Weg, eine 100% ruckelfreie Bildausgabe auf 60 Hz hinzukriegen der, dass man sich auf 30 oder 60 FPS beschränkt. Klar kann man weiterhin Triple Buffering nutzen, um z.B. Bei Konsolentypischen 30 FPS den Hard-lock auf 20 FPS zu vermeiden, wenn man 30 nicht halten kann. Trotzdem will man, um das Microruckeln zu vermeiden möglichst exakt bei 30 oder 60 FPS bleiben. Und da können 8% mehr Leistug sehr viel ausmachen.

Aber nichts für ungut. Gefühlt 99% der Leute hier fühlen sich komplett vor dem Kopf gestoßen, wenn man vom Thema Display Synchronisation anfängt. Das Thema findet im PC bereich fast keine Erwähnung, obwohl immer alle von Gsync und Freesync schwärmen. Aber wie man ohne Adative Sync und nur mit Vsync eine korrekte Bildausgabe erreicht, da kommen dann nur Fragezeichen oder Abwehrhaltung von wegen, man hätte keine Ahnung... Aber dann über konsolen lustig machen, die mit 30 FPS laufen, während der PC ler womöglich sogar das ein oder andere Spiel mit 45-55 Vsync auf einem 60 Hz Display spielt und sich einbildet, er hätte ne ruckelfreiere Bildausgabe, als mit 30 FPS auf Konsole... .

Aber ich lass es an der Stelle auch gut sein, da das sonst ne komplette off-topic Diskussion wird...

 

[DerKonfigurator]

@Cohen @Zero_Point

Tatsächlich, ergibt 23FPS+8%= 24,8 FPS
Ändert nichts am Punkt den ich bringen wollte.
Der Unterschied könnte auch bei 56 FPS, 8%, dann werden die 60 gehalten und man könnte Vsync verwenden. Dank Freesync und co. aber eher irrelevant.
Zwischen 56 und 60 FPS merke ich zwar keinen Unterschied, aber rein messtechnisch ist es einer.

 

[VikingGe]

Das ist ja auch nicht so einfach, da man für D3D10Multithread auf die D3D10 Emulation zurückgreifen muss und ständig zwischen zwei Devices wechseln muss. Siehe Remarks

Nein, muss man in diesem Fall eben nicht, das Interface steht jedem D3D11-Context mindestens seit D3D11.1 zur Verfügung. Allerdings hat erst D3D11.4 einen Alias bekommen, D3D11Multithread - selbes Interface, selbe GUID, ging aber auch schon vorher.

Entweder man nutzt input_per_instance_data oder input_per_vertex_data und nur im zweiten Fall ist eine DataStepRate von 0 erlaubt, was auch logisch erscheint.

Eine DataStepRate von 0 in Verbindung mit Per-Instance-Attributen bedeutet, dass das Attribut für alle Instanzen denselben Wert hat und lediglich mit StartInstanceLocation ausgewählt wird. Die Definition ist sinnvoll und dürfte auch so gewollt sein, in der Vulkan-Extenstion VK_EXT_vertex_attribute_divisor funktioniert es genau so.

Sorry, aber das gucke ich mir jetzt nicht auch noch alles an, aber ich nehme an, dass das jeder normale Entwickler auch alles aufklären kann.

Klar, kann man. Die Dokumentation sollte aber eigentlich dafür da sein, dass man das eben alles nicht selber mühsam herausfinden muss. Ich könnte noch zehn Seiten weiter über fehlende oder teilweise schlicht und ergreifend falsche Informationen in den Docs ranten, vor allem über DXGI, da ist es eher noch schlimmer.

Wenn man mit der API einfach nur arbeitet, mag man zumindest über einige der Probleme vielleicht nicht stolpern, wenn man den Mist implementiert, nervt es umso mehr.

dann steht der offenen API ja nichts mehr im Wege.

Tut es im Grunde auch nicht, im Gegensatz zu OpenGL hat Vulkan ein durchaus gutes Ökosystem mit Debugging-Werkzeugen, kleinen Helfer-Libraries etc., inzwischen recht guten Treibersupport und een guter Dokumentation.

 

[kriegor]

Was erzählst du da? Ich hatte keine Redscreen Quellen für deine Anschuldigungen?

Eigene Erfahrung und ein Allgemeiner Aufschrei in der ganzen Community?

https://www.google.com/search?q=bat...2.69i57j0l5.6855j1j7&sourceid=chrome&ie=UTF-8

Sorry, dass DU davon nicht betroffen warst ...

 

[Ymi_Yugy]

Schade ich hätte mir auch gehofft, dass Vulkan etwas beliebter wird.
Ich denke diesmal war es vor allem der Zeitnachteil. Nicht so sehr, dass Vulkan später rauskam, sondern dass das Ökosystem noch in den Kinderschuhen steckt. RenderDoc wird als einziger funktionierender GPU-Debugger erst jetzt so wirklich nützlich. Soblad man die Einsteigertutorials durch hat, sieht es auch ziemlich düster aus, wenn man nach etwas komplexeren Sachen sucht. Es gibt zwar ein paar Bücher, aber die sollen auch nicht so der Bringer sein. Da hat DX12, dessen Vorgänger ja schon außerordentlich beliebt war natürlich einen riesigen Vorsprung. Was auch so manchen abgeschreckt haben dürfte ist, dass Vulkan nur eine C-API ist. Das merkt man selbst den Abstraktionen, die gerade erst jetzt stabil werden leider auch an.

 

[Flaimbot]

Bei Hirneinschalten der Entwickler auf jeden Fall, sonst nicht.
Erfahrungsgemäß laufen Spiele mit Vulkan schneller, als mit DirectX.

die aussage "hirneinschalten" und vulkan überhaupt benutzen korellieren witzigerweise immer miteinander. ob ein kausaler zusammenhang besteht...¯\_(ツ)_/¯

 

[Mr_Tee]

Vulkan ist weder "besser" noch gleichwertig und unterliegt der gleichen Problematik, die es bei OpenGL schon gab. Neue Features werden wenn überhaupt erst mit einer Verzögerung eingeführt und ein Unternehmen der wirklich hinter dieser API steht, diese bewirbt oder um die Unterstützung seitens Grafikkarten-, Software- und Betriebssystemherstellern wirbt gibt es nicht.

Man sieht es am besten an RTX, was von Microsoft seit dem März dieses Jahren implementiert wurde (DXR). Bis Vulkan es unterstützt, vergehen vermutlich noch ein paar Monate, dann ist dieses Feature um ein "schlappes" Jahr später als bei der Konkurrenz implementiert.

Das haben wir schon alles bei OpenGL gesehen. Am Anfang war die API noch gleichwertig und zum Schluss wurden viele Features entweder gar nicht unterstützt oder nur teilweise durch unzählige Erweiterungen implementiert. Da nun die gleichen Leute hinter Vulkan sitzen, kann man die Entwicklung jetzt schon wunderbar vorhersehen.

Ohne eine treibende Kraft, kann eine API nichts werden. Google ist nur an mobilen Systemen interessiert, Apple bastelt lieber an der eigenen API, Sony ebenso und die Linuxentwickler sind sowieso immer mehr mit sich selbst und täglichen Forks beschäftigt, statt Kompromisse einzugehen und gemeinsam etwas auf die Beine zu stellen.

Man merkt, du hast wenig Ahnung. Nvidia hätte Extensions spezifizieren können. Das geht relativ unkompliziert. So gesehen bei DXVK, wenn da was fehlt um DirectX 11 optimal zu wrappen gab es paar Tage später eine neue Extension, ein Antrag dazu war ganz aufschlussreich, ist eine Textdatei die mittels git übertragen wird. Anfänglich ist das eine prototypische Extension die später auch Teil des offiziellen Standards werden kann.

DICE hat an Mantel mit entwickelt und nun soll alles doof sein? DirectX 12 ist wohl komfortabler, aber da Spiele ich den Mist eben nicht. Win 10 kommt nicht auf meiner Platte. Und btw, ich entwickel selber unter Linux und cross compile für Windows, wer heutzutage nicht plattformunabhängig entwickelt ist einfach beschränkt. Bei uns in der Firma gesehen, da werkelt einer mit Windows Forms, klar geht das schnell (sein Stand macht auf anderen PC aber Probleme, da ist z.B alles verschoben ..). Aber mit QML geht das genauso und es würde sogar auf Android und iOS laufen. Anstatt C++/Qt könnte man auch Kotlin nehmen.

Ergänzung (29. Dezember 2018)

Was auch so manchen abgeschreckt haben dürfte ist, dass Vulkan nur eine C-API ist. Das merkt man selbst den Abstraktionen, die gerade erst jetzt stabil werden leider auch an.

Und was ist so Schlimm daran? C ist nun eben schnell und man kann seine Anwendung ja in C++ whatever schreiben. Falls man mag kann man auch OOP Ansätze in C verwenden, mancher symantischer Sugar fehlt halt. Einfache Vererbungen sind in C kein Problem, Basic Pattern gehen auch (Strategy Pattern z.B. mittels Function- Pointer). Also ich brauche bei meinen C Code nie globale Variablen, habe aber dafür etwas mehr Indirektionen, wer volle Performance will macht das eben nicht. Dem Anwender einer API kann es aber recht egal sein wie es "innen" aussieht. Das einzige was mich nervt sind die Header- Dateien. Hab beruflich viel mit C# entwickelt.

 

[xexex]

DICE hat an Mantel mit entwickelt und nun soll alles doof sein?

Das war vor 5 Jahren und es sind "damals" mehr Spiele mit Mantle Unterstützung herausgekommen, als es bisher mit Vulkan gibt. Man hat also knapp 5 Jahre Vorsprung und viele Möglichkeiten, die sich möglicherweise mit dieser herstellereigenen Schnittstelle hätten ergeben können verschenkt.

Unter Windows interessiert Vulkan nun nicht mehr wirklich, da Windows 7 größtenteils abgelöst wurde, auch diesen Vorteil hat man nicht nutzen können. Grundsätzlich hätte AMD einiges erreichen können, hätten sie diese API proprietär gelassen und versucht hätten sie im Konsolenbereich durchzusetzen. Letztendlich soll es mir aber auch egal sein, man sieht ja wie sich Vulkan entwickelt und man kennt die Entwicklung von OpenGL. Mehr muss man eigentlich nicht dazu sagen.

 

[VikingGe]

So gesehen bei DXVK, wenn da was fehlt um DirectX 11 optimal zu wrappen gab es paar Tage später eine neue Extension

Naja, fairerweise muss man dazu sagen, dass Transform Feedback gut 5 Monate von den ersten Diskussionen bis zur fertigen Extension gebraucht hat. Dafür wurde aber auch sichergestellt, dass sie a) von allen interessierten IHVs implementiert werden kann und b) nicht nur für D3D11- und OpenGL ES-Emulation taugt, sondern auch für D3D12, da gibt es ein paar Unterschiede.

Ansonsten hast du natürlich völlig recht, der von dir zitierte Beitrag zeugt von einer gewissen Ahnungslosigkeit. Für Vendor-übergreifende Extensions müsste es erst einmal mindestens zwei Hersteller geben, die ein Feature überhaupt implementieren, und Nvidia ist bislang der einzige, der Raytracing in Hardware unterstützt.

Zumal DXR auch eher eine Ausnahme ist. Wo ist z.B. "offizieller" Mesh Shader-Support für D3D12?

 

[Zero_Point]

Ein Feature hier ein Feature dort, im Moment nutzt so gut wie niemand Vulkan und daran wird sich nichts ändern wenn die Entwicklung so langsam voranschreitet. Du sagst es ja selbst, dass niemand wegen ein paar Features die API wechselt, also bleibt man einfach bei DX12.

Mit Vulkan ist ein Entwickler wesentlich flexibler. Momentan sind allenfalls eine handvoll Entwickler bei DX12. Die können dort bleiben. Die restlichen 99% entscheiden dann wo ihr Weg langführt.

Alle Firmen die RT oder DLSS Unterstützung angekündigt haben werden dies jetzt und auch in Zukunft mangels Unterstützung seitens Vulkan mit DX12 als API umsetzen. Kommendes Jahr kommen neue Chips von AMD, darauf folgendes Jahr stellt Intel seine Grafikkarten vor, womöglich bringen auch diese wieder neue Features und Vulkan bleibt auch dort außen vor.

Auch hier reden wir von ein paar Firmen. Und ist DLSS überhaupt DX12 exklusiv? Selbst wenn, der Nutzen von DLSS ist ja praktisch bei Null, da UHD zwingend vorausgesetzt wird. Da ist die Zielgruppe doch mehr als überschaubar.

 

[Beitrag]

Grundsätzlich hätte AMD einiges erreichen können, hätten sie diese API proprietär gelassen und versucht hätten sie im Konsolenbereich durchzusetzen.

Klar, wenn man der Underdog auf dem Markt ist, kann man eigene propietäre, nicht konkurrenzlose Lösungen schließlich prima durchdrücken und die Konsolen würden sich natürlich freuen, wenn die API "Mantle" hieß und AMD-only wäre statt "Vulcan" und offen.

 

[tek9]

Aber ich lass es an der Stelle auch gut sein, da das sonst ne komplette off-topic Diskussion wird...

Wenn du im ersten Beitrag ein klein bißchen genauer gewesen wärst, hättest du den Rest weglassen können. Den so wie du es geschrieben hast, hat es sich nunmal wie diese dümmlichen Master Racer Posts gelesen die hier reichlich zu finden sind

Btw hast du eine Quelle auf der sich dein Beitrag begründet?

 

[xexex]

Mit Vulkan ist ein Entwickler wesentlich flexibler. Momentan sind allenfalls eine handvoll Entwickler bei DX12. Die können dort bleiben. Die restlichen 99% entscheiden dann wo ihr Weg langführt.

Eine Handvoll.... Du bist lustig! Das ist alleine die Liste der Spiele die mit RTX/DLSS kommen, was so viel heißt, dass die Entwickler allesamt mit DX12 entwickeln.
https://www.computerbase.de/2018-09/nvidia-geforce-rtx-dlss-support-weitere-spiele/

Dazu kommen natürlich alle Titel und Studios die schon bisher DX12 Spiele entwickelt haben oder es auf dem PC oder der Xbox tun werden.

Dagegen ist die Anzahl der Entwickler, die sich mit Vulkan beschäftigen vermutlich wirklich "eine Handvoll".

Klar, wenn man der Underdog auf dem Markt ist, kann man eigene propietäre, nicht konkurrenzlose Lösungen schließlich prima durchdrücken

Man ist führend im Konsolenmarkt und hätte mit etwas Verhandlungsgeschick mit Sicherheit etwas erreichen können, Unterstützer im PC Sektor hatte man ja bereits vor 5 Jahren. Nun entwickeln DICE, Eidos und vermutlich auch Bioware aber keine Mantle Spiele mehr sondern DX12, oder hast du von Battlefield oder Tomb Raider eine Vulkan Version gesehen?

Klar, wenn man der Underdog auf dem Markt ist, kann man eigene propietäre, nicht konkurrenzlose Lösungen schließlich prima durchdrücken

Offen bedeutet in diesem Fall, niemand fühlt sich zuständig, niemand kümmert sich mit Nachdruck um die Verbreitung und niemand interessiert es wirklich ob es jemand nutzt. Letztendlich kümmert es auch AMD anscheinend nicht, denn solange die Entwickler nun DX12 nutzen kann es denen egal sein.