News DirectX 12: Disput zwischen Oxide und Nvidia geht weiter

[Sebbi]

jaja nvidiatypische Kommunikation:

Ist ein game auf der eigenen Karte schlecht, wird versucht es zu verreden, das es doch soo schlecht sei.
Wird ein Betrug am Kunden durch "Kommunikationsfehler" begangen, ist das doch alles nicht so tragisch.
Wird man des Betruges überführt sag man schlicht "Its not a Bug, its a Feature"
Und natürlich bremst Gamework, PhysX und konsorten die Konkurenten natürlich absolut nicht absichtlich auf, nei überhaupt nicht.

Ich find es lustig ... ich hab immer mehr leute, die nun auf die Grakas von AMD wechseln P/L und das Karma einfach besser.
Frag mich, warum man nix mehr von den Klagen wegen Täuchung aus den USA hört .... außergrichtlich geeinigt und Schweigegeld gezahlt? Eigentlich müsste man Nvidia eh immer wieder wegen jeder GW spiel verklagen, weil das absichtliche Behinderung der Konkurenz oder unlauterer Wettbewerb (was laut Gesetz in Deutschland ja untersagt ist) ist



Apropos:
Letztes ne Nvidiakarte installiert ... Treiber verweigerte 15 mal eine Installation mit der Meldung: Installieren sie einen Treiber, bevor sie die Treiberinstallation fortsetzen können. Beim 16x ging alles. Und das auf einen frischen Windowssystem, wo alle Treiber von der Herstellerseite heruntergeladen und aktuallisiert wurden, so das bis auf die Nvidiakarte alles da war und funktionierte.

 

[r4yn3]

Zum brüllen. Nvidia als kleines angepisstes Kind, welches man schon wieder bloßstellt. Sollte sich das als wahr heraustellen, dass Nvidia Async Shader nur sehr mäßig über Software realisiert, kann ich nur hoffen dass die Community denen endlich mal die Quittung präsentiert. So von wegen tolles DX12.1 Featureset.

Erinnert mich an Assassins Creed DX10.1 Pfad. Ein Schelm wer böses denkt.

 

[Lukas-Arts]

Also ich muss schon sagen, als Linux-Nutzer amüsiert mich diese ganze Disskussion schon sehr Meine Hoffnung ist eh, dass DirectX mit Vulkan(/OpenGL) an Bedeutung verliert - vor allem weil Valve Interesse daran hat dass zukünftige Spiele unter SteamOS/Linux laufen und der Port mit Vulkan schlicht einfacher für die Entwickler ist.

Weil hier einige sagen sie hoffen, dass nVidia das Problem per Treiber-Update angeht:
ich finde es schon lange ein Unding, wie (vor allem) nVidia das macht. Da kauft man sich ein Spiel und dann läuft das ganze die ersten Tage richtig scheiße weil die erst noch per Treiber-update alles zurecht pfuschen müssen. Vor allem die Leute im ländlichen Raum tun mir da richtig leid, die erst ein zig GB großes Spiel mit ner max. 2000er Leitung laden und dann enttäuscht vorm Rechner sitzen weil sie danach noch ein riesen Treiber runterladen müssen. Und ich will auch gar nicht wissen wie der Code vom nVidia Treiber aussieht mit Spezialfällen für jedes größere Spiel - vllt haben die auch desshalb so eine Angst vor der OpenSource/Linux-Community

 

[SimsP]

Ich bin mir sicher NVidia ist an der Situation jetzt mindestens genauso schuld wie an der "guten" Performance der AMD Karten bei Project Cars, oder diversen Early Access Spielen ...
Irgendwie zeichnet sich da ein Muster ab.
Wer ist für das schlechte Wetter verantwortlich ... NVidia.
Wer ist an der Wirtschaftskrise schuld ... NVidia.
Wer hat Sadam seine Massenvernichtungswaffen geliefert ... NVidia.
Aber, dass die Sonne jeden Morgen aufgeht hat AMD gemacht.
Das weiß ich alles von Richard Huddy.

So und jetzt weichenwir mal für 5 Sekunden vom Bildzeitungs-Niveau ab und schauen uns die Fakten an. Was sehen wir?
Es gibt bisher eine einzige DX12 Demo, die befindet sich im Beta-Stadium und da schneiden NVidia Karten relativ schlecht ab.
Dass Kepler und Maxwell keine Asynchronen Shader haben ist Blödsinn. Nennt sich bei NVidia Hyper-Q und gibts seit GK110, also seit etwa zwei Jahren. Wenn das nicht korrekt funktionieren würde, sollte das schon vorher mal jemandem aufgefallen sein.

Somit lässt das ganze nur zwei Schlussfolgerungen zu.
1. Oxide ist zu inkompetent, um die angesprochenen Funktionen korrekt umzusetzen und schiebt den schwarzen Peter zu NVidia.
Davon gehe ich eher weniger aus, weil DX eigentlich vereinheitlichte Funktionen bietet und bei AMD läuft es ja offenbar.
2. Der NVidia DX12 Treiber ist unausgereift und hat ein paar Funktionen der neuen Schnittstelle noch nicht 100% korrekt implementiert. Das könnte unter Umständen auch daran liegen, dass MS bei der Umsetzung des Features sehr eng mit AMD und deren Async Shader Technologie zusammengearbeitet hat, die etwas anders funktioniert als NVidias Hyper-Q. Evtl. muss sich NVidia da nochmal mit MS an einen Tisch setzen.

Egal weshalb ich bin zuversichtlich, dass das Problem bis zum Release erster DX12 Games behoben sein wird. Und bevor jemand fragt, nein für mich lohnt sich das Ganze so oder so nicht, weil meine GTX 680 kein Hyper-Q hat und meine HD7970 ist trotz async Shader nicht wesentlich schneller.
Außerdem ist euch schon mal aufgefallen, dass die R9 Fury X unter DX11 kaum schneller ist als eine GTX770 ... spricht nicht gerade für einen vertrauenswürdigen Benchmark, oder?

 

[KenshiHH]

Ganz lustig die ganze Entwicklung,
erst wird das höhere DX12 Feature level von den NV Jüngern gepredigt, nun kommt von den gleichen die ausrede bis DX12 Relevant ist, ist eh die Neue Nvidia Generation raus.

Bin ich froh die 970 aufgrund der VRam lüge zurück gegeben hab.

 

[Nai]

Dass Kepler und Maxwell keine Asynchronen Shader haben ist Blödsinn. Nennt sich bei NVidia Hyper-Q und gibts seit GK110, also seit etwa zwei Jahren. Wenn das nicht korrekt funktionieren würde, sollte das schon vorher mal jemandem aufgefallen sein.

In NVIDIAs Whitepaper ist aber nur davon die Rede, dass die GPU mit HyperQ nur mehrere unterschiedliche Compute-Shader/CUDA-Kernel gleichzeitig berechnen kann. Ich habe diese Gleichzeitigkeit vor etwas längerer Zeit aus einem komplett anderen Anlass mal an einem CUDA-Kernel überprüft und da funktionierte sie auch tatsächlich so wie im White-Paper beschrieben (ich kann auch wieder Benchmark liefern, falls selbst das jemand anzweifeln sollte). Im Whitepaper steht jedoch nichts davon drinnen, dass die GPU mit HyperQ Draw-Calls/Draw-Shader und Compute-Shader gleichzeitig berechnen kann, das was die "Allgemeinheit" unter Asynchronous Shaders versteht. Interessanterweise finde ich gerade überhaupt keine offizielle Aussage von NVIDIA, dass diese Gleichzeitigkeit auf ihren GPUs überhaupt möglich sei.

 

[xamoel]

Spart euch doch euer Kopfzerbrechen, wir werden in den finalen Tests sehen wer die Nase vorn hat. Und nicht nur in einem beliebigen Titel, sondern mehreren DX12 Games. Dann kann man was definitives dazu sagen.

 

[rentex]

War schon immer skeptisch, das DX 12 Features, ausser bei neuesten AMD Karten schon auf älteren Architekturen, ohne weiteres funzeln soll.

 

[Hardware_Hoshi]

Genau so habe ich das auch gesehen.
Mitlerweile frage ich mich warum gibt Oxide diese Infos raus? Und wichtiger warum in so einem kritischen Ton?
Liegt es daran, dass Nvidia behauptet hat Oxide hätte Fehler beim Programmieren gemacht? Mich überzeugt das irgendwie nicht.

Oxide ist in der Sache sicher nicht neutral. Noch ende 2013 haben sie mit AMD zusammen auf der Bühne gestanden und für Mantle getrommelt. Kein Mensch weiß wie lange die Entwickler zusammen mit und für AMD optimiert haben. Da ist auf jeden Fall Geld geflossen. Freiwillig macht das keiner!

DX12 legt viel Fokus auf die Implementierung der Programmierer. Ich bin mir absolut sicher, dass die Entwickler den Code sehr auf GCN ausgelegt haben. Viele dieser Implementierungen schmecken den Geforces unter Umständen nicht. Nvidia möchte das sicher ändern, aber da ist noch die Frage in wiefern Oxide kooperiert. Da geht sicher mehr hinter den Kulissen vor als uns bewusst ist.

Sich mit der Architektur beißender Code ist vorstellbar. Für Nvidia ist das dann ein Bug während für Oxide alles wie "geplant" funktioniert. Insofern ist da viel Konfliktpotential. Ich kann mir nicht helfen, aber irgendwie kommt mir das wie eine Retourkutsche für die angebliche Gameworks Manipulationsunterstellungen. Diesmal nur von einem AMD-Partner. Das das für Oxida mal nicht nach hinten losgeht.

Edith ergänzt, Oxide ist jetzt wirklich in aller Munde. Vielleicht reicht ihnen das.

Das wird nur nicht viel nützen! AshesOS ist nach wie vor ein unbeständiger Benchmark. Das Spiel wurde mit dem Ziel "Inflation der DRAWCALLS" entwickelt. Damit bekommt man kein gutes Gameplay hin. Die Ergebnisse werden alle erzwungen sein. Wer viele Einheiten strategisch gleichzeitig befehligen will, soll bei den guten alten "TOTAL WAR" Titeln bleiben. Demnächst sogar mit Total War: Warhammer ein großer Stern am Strategiehimmel. Mehr Strategie geht fast nicht! [Als Alternative ist das noch Warhammer mit Dawn of War II (WH 40k).]

Oxide kann diesen Studios nicht einmal die Zuckerstange reichen!

 

[KenshiHH]

Das ziel ist es möglichst viele Dynamische Einheiten zu haben damit es Lebendiger wirkt, nicht um künstlich die DrawCalls hoch zu hauen....
Das ganze Instancing und DrawCall gebatche ist doch einfach nur nervig und nimmt entwicklern die Freiheit beim Spieldesign.

Denen Pro AMD vorzuwerfen ist auch nicht richtig, die haben doch selbst gesagt die haben sogar mehr mit Nvidia als wie AMD zusammen gearbeitet.
Kaum gibts bei Nvidia probleme haben alle anderen schuld und die Engine sind eh scheisse und deren Programmierer unfähig....
Kommt mal runter

 

[Iapetos]

Also ich muss schon sagen, als Linux-Nutzer amüsiert mich diese ganze Disskussion schon sehr Meine Hoffnung ist eh, dass DirectX mit Vulkan(/OpenGL) an Bedeutung verliert - vor allem weil Valve Interesse daran hat dass zukünftige Spiele unter SteamOS/Linux laufen und der Port mit Vulkan schlicht einfacher für die Entwickler ist.

Das unterschreibe ich so.

Mir geht allerdings die auf DX12 verengte Weltsicht der Entwickler auf die Nerven, wenn sie mit Vulkan für ein ebenso leistungsfähiges und genau so kompliziert zu implementierendes API entwickeln könnten, ohne die vielleicht noch unentschlossenen Spieler ohne Not zu Windows 10 zu treiben. Ich werde jedenfalls keine DX12-Spiele kaufen, diese Arroganz kann ich mir glücklicherweise leisten.

 

[Krautmaster]

Wen interessiert DX12 denn jetzt schon? Jeder der hier ne GPU im 200+ Euro Bereich hat wird doch eh umsteigen bevor DX12 relevant wird.

DX12 interessiert mich schon, aber weniger in Form eines Titels wie der hier genannte. Klar, wenn ein Game sehr API Lastig ist, was man hier natürlich provoziert, dann fallen Unterschiede auf - genau gleich wie wenn man nun Tessellation exzessiv nutzen würde um zwischen rot und grün Unterschiede aufzuzeigen. Das Game is zum selben Zweck wie schon Swarm entstanden, Marketing von AMD - was ja auch vollkommen okay ist und wenn man hier so liest ja auch funktioniert , daraus aber viel Schlüsse halte ich für gewagt. Es wird immer einzelne Techniken wie Tessellation geben die Unterschiede aufzeigen die mit den Unterschieden bei Games wenig zu tun haben, auch wenn mans hier nach Game aussehen lassen will ...

Edit:
AS wird vielleicht auch AMD helfen mehr der hohen Rohleisting umzusetzen. Das hat Nvidia bisher schlicht besser geschafft, mit vorhandenen Techniken. Ich habe ja schon mehrfach geschriebene dass AMD hier sicher profitieren wird, vielleicht nicht durch die Bank aber einigen Titeln. Muss sich zeigen.

 

[Benji18]

Fakt ist das Nvidia keine asyc Shaders HW seitig Implementiert hat, diese Aussage würde nicht kommen und nicht in dieser weise wenn da nichts dran wäre.
Fakt ist NV hält es nicht so besonders genau mit Tech Specs das haben Sie in der Vergangenheit oft genug bewiesen ....

Daher ist diese Aussage durchaus Glaubwürdig aber es war ja klar das die Fanboys gleich wieder alles totreden und AMD die schuld geben ?! aha .....

selbst wenn der Hersteller mit AMD zusammen das Spiel optimiert hat kann man den Fakt nicht wegdiskutieren das esentielle DX12 Features nicht Implementiert sind und wenn jetzt wer kommt mit jaja wird dann halt SW emuliert .... Emulation ist immer langsamer als echte HW implementation.

als Maxwell Käufer würde ich mir jetzt sehr verarscht vorkommen

 

[yummycandy]

Ich sehe das nicht so heikel. Gameworks finde ich dagegen viel schlimmer, weil es ähnlich wie der Intel Compiler arbeitet. Ansonsten ists doch gut, daß AMD mal wieder die Nase bei ein paar Sachen vorn hat, dann muß eben nVidia nachziehen.

 

[Hardware_Hoshi]

Das ziel ist es möglichst viele Dynamische Einheiten zu haben damit es Lebendiger wirkt, nicht um künstlich die DrawCalls hoch zu hauen....
Das ganze Instancing und DrawCall gebatche ist doch einfach nur nervig und nimmt entwicklern die Freiheit beim Spieldesign.

Doch, genau darum ging es! Abgesehen vom gesenkten Overhead sind die DrawCalls das Hauptaugenmerk der neuen Low-Level APIs. Nur weil man es jetzt kann, muss man noch lange nicht übertreiben. Ashes of the Singularity stammt von der StarSwarm Demo ab. Die verwendete Engine ist die Nitrous Engine. Außer massig kleinen Einheiten mit Lichtspielen hat man noch nichts wirkliches gezeigt. Detailierte Großaufnahmen kann die Engine möglicherweise nicht.

Denen Pro AMD vorzuwerfen ist auch nicht richtig, die haben doch selbst gesagt die haben sogar mehr mit Nvidia als wie AMD zusammen gearbeitet.

Was sie sagen, könnte sicherlich auch nur PR-geschwängert sein. Nvidia verlässt sich bekannterweise auf ihr Treiber- und Supportteam vor Ort was die Zusammenarbeit mit den Studios anbelangt. Oxide erzählt also nichts neues, wenn sie sagen mit Nvidia war die Zusammenarbeit anbelangt.

Jetzt ist aber wie bereits von mir erwähnt die Performance abhängiger von der entsprechenden Architektur. Die Umsetzung und Ziele der Entwickler rückt also mehr in den Vordergrund. Dass sich Oxide mit AMD für die Mantle-Kampagne zusammen geschlossen hat, darf man nicht vergessen. Zumindest darf man es nicht ausschließen!

Wenn sich zum Beispiel die Engine grundsätzlich an AMD bevorzugt oder grundsätzlich eher auf GCN lehnt, kann Nvidia im Treiber wenig ausrichten. Alles was sie tun können ist die Wogen zu glätten. Ich würde auch nicht sagen, Nvidia hätte grundsätzlich Probleme.

Ashes of the Singularity ist nur eines von vielen Spielen. Es wird Engines geben, die eher in die eine oder andere Richtung tendieren.

Kaum gibts bei Nvidia probleme haben alle anderen schuld und die Engine sind eh scheisse und deren Programmierer unfähig....
Kommt mal runter

Die ganze Geschichte ist noch eine extrem frühe Alphaversion. Man kann sich ja an PROJECT Cars und ähnlichen Titeln orientieren. Da lief für AMD auch nicht alles rund. Neuerdings fällt aber die steigende Abneigung gegen Nvidia im AMD Lager auf. Selbst Kleinigkeiten werden sofort als kritisches Problem eingestuft. Das Thema ist sowieso viel zu hoch gekocht!

Die Spieleprogrammierer haben jetzt mehr Verantwortung. Was diese Knilche diverser Studios für Bockmist liefern, haben wir in der Vergangenheit schon zu oft gesehen. Wegen der Low-level Philosophie können weder AMD noch Nvidia in zukunft gegensteuern. Die Programmierer müssen jetzt erst einmal beweisen wie fähig sie sind.

Anschuldigungen gegen die Programmierer wird also unabhängig vom Hersteller zunehmen. Das Dumme daran ist, dass wir Gamer nie wissen können wer jetzt wirklich "schuld" ist. Aus der Verantwortung nehmen darf man diesen Aspekt allerdings nicht.

 

[frkazid]

Nur mal ne Frage am Rande:

Sollte DX12 nicht auch dazu führen, dass keine bzw. kaum Anpassungen am Treiber durchgeführt werden müssen weil die Verarbeitung der API-Calls eh Low-Level erfolgt? (hab ich das jetzt richtig ausgedrückt?)

Sehe dann ehrlich gesagt nicht wirklich Optimierungserfolge am Treiber. Zumindestens nicht in dem Ausmaß wie manch Hersteller zurückhängt.

 

[Krautmaster]

Fakt ist das Nvidia keine asyc Shaders HW seitig Implementiert hat, diese Aussage würde nicht kommen und nicht in dieser weise wenn da nichts dran wäre.
Fakt ist NV hält es nicht so besonders genau mit Tech Specs das haben Sie in der Vergangenheit oft genug bewiesen ....

das kann durchaus sein ja, genauso könnte man Tessellation/ Computing usw. vielleicht komplett weglassen oder nur über CPU berechnen. Unterstützt wird Async Shaders sicherlich, wie gut oder schlecht obliegt dem Hersteller. Wenn Nvidia vorhandene HW schon auf klassischen Weg so gut nutzt, dass der Vorteil durch Async Shader unwirtschaftlich zu implementieren ist, dann ist es vollkommen legitim hier nur rudimentären Support zu bieten. Klar kann Nvidia schlecht vorschreiben wie die Engine auszusehen hat, aber es ist auch vollkommen legitim eine Guideline für die eigenen Karten zu erlassen mit dem Hinweis auf Async Shadern nach Möglichkeit zu verzichten.

Mag sein dass hier beide GPU Typen verschieden angesprochen werden sollten wenn es darum geht das beste Erlebnis zu schaffen. Wird sicher auch kein Einzelfall sein und wenn sich der Engine Entwickler nicht dran hält und die Nvidia Karten massiv einbrechen ist das Nvidias Bier, aber auch des des Publishers und Entwicklers weil es sicher auch nicht in seinem Interesse ist ein einseitig schlecht performendes Game zu releasen - je nach dem wie krass es ausfallen würde.

Was AMD natürlich versuchen wird, und Oxide hier natürlich an einem Strang mit AMD zieht, ist die Werbung für den Einsatz von Asynchronen Shadern - logisch wenn es auf der eigenen Hardware vielleicht Verbesserungen mit sich bringt. Bringt ja alles nichts wenn es nachher keiner einsetzt, und genau deswegen sind Marktanteile auch so wichtig. Kaum ein Publisher würde seine Engine großartig auf Techniken bauen welche die Performance in Relation Hardware untypisch stark verzerren würde, 80% des Marktes (Nvidia) schlecht laufen würden - weil es auf das Spiel und die Engine zurückfallen würde. Sofern also Asynchrone Shader bei AMD Vorteile bringen und bei Nvidia kaum oder eher das Gegenteil wäre es natürlich am besten wenn die Engine das je nach GPU Typ zuschält. Die Frage ist ob der AMD Marktanteil nicht vielleicht schon zu klein ist...

Der Heilige Gral wird es kaum sein da ich mir nicht vorstellen kann, dass jetzige GPUs nur zu 70% ausgelastet sind. Bei Nvidia würde eine höhere GPU Last sich vielleicht sogar wieder selbst terminieren indem zB der Turbo bei den normalen Karten weniger hoch zündet, das System ist ja bereits extrem dynamisch. Klar wäre auch hier eine höhere % Last auf der GPU besser, die Frage ist wie viel Spielraum da man heute noch nach oben hat. Ich denke die AMD Architektur ist heute deutlich schlechter ausgelastet, siehe Rohleistung zu FPS, ergo bringt es da natürlich auch mehr.

@ Asyc Shader

http://www.anandtech.com/show/9124/amd-dives-deep-on-asynchronous-shading

vielleicht interessant in diesem Zusammenhang.

 

[Faust2011]

Wo bleiben die Rufe das AMDs Architektur ja so dermaßen veraltet sei?

Das war in den letzten paar Monaten kaum noch zu ertragen, wie hier im Forum viele sowas gerufen hatten. Ja, der Hawaii-Chip, das ehemalige Top-Modell von AMD, ist vom Oktober 2013. Und? Er performt kräftig! Und ja, AMD hat bereits vor Jahren erkannt, dass GDDR5 bzw. das Speicherinterface am meisten Energie schluckt und genau deshalb ist es beim Fiji nun auch HBM-Speicher geworden. Wenn man den Hawaii-Chip unter Wasser setzt, dann hat man ausreichende Performance und Ruhe im Karton.

Es is ne Gameengine die wie bei Mantle (von und mit AMD als Partner) mit Fokus auf Draw Fall overload gecoded wurde.

Die DrawCalls waren bisher der Hemmschuh, dass man Szenen in Spielen nicht so detailreich gestalten konnte, wie man das gerne hätte. Auf einer vor kurzem stattgefundenen Spieleentwickler-Konferenz wurde ein bisschen aus dem Nähkästchen der Macher von AC:Unity gesprochen und welche Probleme sie eben hatten, detailreiche Szenen (Paris mit all seinen Gebäuden und den Menschenmassen) performant zu rendern.

 

[deo]

Wenn das Feature bei Geforce nicht genutzt werden kann, dann müsste doch die DirectX12 Kompatibilität Nvidia entzogen werden.
Man darf nicht mit etwas werben, was man nicht hat. Entweder es wird richtig unterstützt oder gar nicht. Halbe Unterstützung bringt dem Spieler nichts.

 

[frkazid]

Sie unterstützen es ja voll (lt deren Aussage). Ist halt nur nicht so performant. ^^

Habe aus dem 3,5+0,5 Desaster auf jeden Fall meine Schlüsse gezogen und werde mir diesen Sachverhalt auch genauer anschauen und beim nächsten Kauf berücksichtigen.