News DirectX 12: Disput zwischen Oxide und Nvidia geht weiter

[Prozessor Knox]

Ursprunglich ging die Sache von Nvidia aus:

http://wccftech.com/nvidia-we-dont-believe-aots-benchmark-a-good-indicator-of-dx12-performance/

Oxide hat darauf dann reagiert. Sovíel zum "anpissen".

@Krautmaster

Es sollen ja angeblich 20-30% Mehrperformance mit XBox und DX12 zu erzielen sein. Und man sollte nicht vergessen, dass die Konsolen einen erheblichen Marktanteil besitzen.

@Herdware

DX12 ist für Nvidia möglicherweise ohne größeren Vorteil. Absolut möglich.

 

[Moon_Knight]

Was widerspricht da dem "Anpissen"? Um zurückzuschießen, braucht es noch immer die Erlaubnis der Oberetage.
Wenn ich nur ein schlechtes Wort über einen Kunden in der Öffentlichkeit ohne Rückendeckung abgeben würde, wäre ich in der Informatik dauerhaft beschädigte Ware.

 

[xeonking]

Eigentlich ist es egal wodurch genau AMD hier profitiert, wichtig ist nur das sie davon wohl profitieren. Und das ist auch gut so, das sollte jedem klar sein, egal auf welcher Seite er sich befindet.

Das für mich doch mehr als erstaunliche, wie gut sich die AMD-Hardware auf die Jahre gesehen hält. Mit einer "alten" AMD Karte kann man also hier und da mal einige Jahre zocken, gibt es nicht so oft. Vor allem nicht wenn neue DX Versionen einzug halten.

gruß

 

[Krautmaster]

Die Engine muss nur entscheiden welcher Architekturtyp vorhanden ist und die native Anzahl an Queues ansteuern und die entsprechende Compute Tasks mit Graphics Tasks abstimmen. Dann ist nvidia deutlich schneller fertig.

Sieht ma ja schön hier: https://www.reddit.com/r/pcmasterra..._to_conclusions_and_crucify/cumlmwv?context=1

wobei man sagen muss dass hier ein Großteil der Latenz vom System kommt, der eigentliche GPU Thread is in <2 ms fertig. Also absolut hat der Benchmark wohl weniger Performance Charakter, geht wohl eher darum wie die Systeme generell reagieren.

 

[Ice-Lord]

Ist ja nicht das erste mal das nVidia mit den Treibern "schummelt"

DX12 ist eben einfach mehr als nur inspiriert von Mantle.
Die ganze Idee der Paralellisierung und umverteilung stammt ja praktisch aus der AMD API.

Mich wundert es nicht dass das den AMD Karten deutlich besser liegt.

Nur ist das mal wieder das perfekte Beispiel für die subjektive Art wie solche Dinge
aufgenommen werden.

nVidia hat Probleme mit einem Spiel oder Technologie > Der Entwickler ist schuld!
AMD hat Probleme mit einem Spiel oder Technologie > AMD ist unfähig Treiber zu programmieren!

Das selbe Spiel wie bei der Hardware unter Linux.

Sollte das komplette Feature aber mal wieder fehlen halte ich das doch für einen
recht groben Einschnitt in die DX12 fähigkeiten der nVidia GPUs.

 

[Krautmaster]

Eigentlich ist es egal wodurch genau AMD hier profitiert, wichtig ist nur das sie davon wohl profitieren. Und das ist auch gut so, das sollte jedem klar sein, egal auf welcher Seite er sich befindet.

das seh ich auch so. Ich gönne jedem das letzte Quäntchen aus seiner Hardware rauszuholen, is mir egal ob der rot der blau oder grün fährt. Für wilde Theorien und Flamewar ist es aber zum einen viel zu früh, zum anderen entscheidet nachher eh das was beim Anwender am Schirm ankommt, vollkommen egal ob das dann durch Magie oder Asynchrone Shader gelöst wurde. Zumal die API , Treiber usw auch einfach noch recht neu sind.

AMD hat mehr Potential auch allein dadurch, dass mehr Rohleistung heute ungenutzt scheint. Bei DX11 ja teils massiv.
Zudem haben sie den Konsolenvorteil.

 

[poi]

Das bedeutet nur, das ein Switch zwischen Compute Mode und Graphics Mode durchführt. Beides nicht gleichzeitig berechnet, jedoch Compute Tasks asynchron bearbeitet - eben nur nicht unterschiedliche Art der Modes. Je Mode kommt es dann zu einem Sync so, dass die Tasks eines Modes komplett abgeschlossen werden müssen, bevor Tasks des anderen Modes beginnt. Sprich, nvidia arbeitet jedoch die Queues (Compute Tasks) auch asynchron ab entscheidet jedoch beim Typ des Tasks und dies in nativer Form deutlich effizienter als AMD.

Lies dir mal den von dir verlinkten Post durch. Besonders das fett gedruckte. Mehr habe ich auch nicht klarstellen wollen.

Sieht ma ja schön hier: https://www.reddit.com/r/pcmasterra..._to_conclusions_and_crucify/cumlmwv?context=1

 

[Prozessor Knox]

Was widerspricht da dem "Anpissen"? Um zurückzuschießen, braucht es noch immer die Erlaubnis der Oberetage.
Wenn ich nur ein schlechtes Wort über einen Kunden in der Öffentlichkeit ohne Rückendeckung abgeben würde, wäre ich in der Informatik dauerhaft beschädigte Ware.

Und? Selbst wenn, was wäre daran tragisch?

 

[berkeley]

Was widerspricht da dem "Anpissen"? Um zurückzuschießen, braucht es noch immer die Erlaubnis der Oberetage.
Wenn ich nur ein schlechtes Wort über einen Kunden in der Öffentlichkeit ohne Rückendeckung abgeben würde, wäre ich in der Informatik dauerhaft beschädigte Ware.

Er wird sich wohl vorher informiert haben bzw. ist es bereits auf Anweisung der "Oberetage" passiert. Sonst würde Oxide wohl nicht hinter dem Statement stehen. Er schreibt ja auch, dass es Nvidia bewusst war und Nvidia es auch deshalb nicht abstreiten wird. Ist ja alles bis heute von Nvidia nicht abgestritten worden. Fakt.

 

[strex]

wobei man sagen muss dass hier ein Großteil der Latenz vom System kommt, der eigentliche GPU Thread is in <2 ms fertig.

Das zeigt ja nur das GCN 50ms braucht um den Overhead zu bearbeiten. Ob der Overhead da ist, um vorher erst alles vorzubereiten oder zu warten bis vorher als fertig ist - das weiß man nicht, gehört aber so dazu. Der ist aber da egal wie groß die Queue-Anzahl ist. Das drückt natürlich die Performance. Nvidia braucht auch Zeit, nämlich dann wenn die Queue-Anzahl über 31 steigt. Dann wird der Overhead auch größer weil gewartet werden muss - ist ja dann auch System Overhead.

Lies dir mal den von dir verlinkten Post durch. Besonders das fett gedruckte. Mehr habe ich auch nicht klarstellen wollen.

Hier geht es ja um die Diskussion ob Asynchronous Compute überhaupt vorhanden ist, denn Compute Tasks können asynchron verarbeitet werden. Das ist es, unterscheidet aber zwischen zwei Modi was einen sync benötigt. Ob das nicht auch AMD benötigt, jedenfalls benötigt es ~50ms für einen Sync, um Asynchronous Compute zu aktivieren egal wie viel Queues angesprochen werden müssen - bietet aber oben raus mehr Luft mit mehr Queues.

 

[Krautmaster]

Lies dir mal den von dir verlinkten Post durch. Besonders das fett gedruckte. Mehr habe ich auch nicht klarstellen wollen.

Stimmt. Danke für die Richtigstellung. Bleibt die Frage nach den Auswirkungen und ob auf diese Weise wirklich das Async Shader verhalten nachgestellt werden kann.

@strex

joa, naja schaun wir mal wie sich die Sache entwickelt. Wenn man den Thread so durchliest dann wirds schon etwas sehr technisch da bei beyond3d. Mal sehn was Nai noch dazu meint

Rein von den Queue-Anzahl her ist selbst die sequenzielle Bearbeitung bei Nvidia deutlich im Vorteil, bis eben die Queue-Anzahl über einen gewissen Wert steigt.

 

[Minutourus]

Das zeigt ja nur das GCN 50ms braucht um den Overhead zu bearbeiten. Ob der Overhead da ist, um vorher erst alles vorzubereiten oder zu warten bis vorher als fertig ist - das weiß man nicht, gehört aber so dazu. Der ist aber da egal wie groß die Queue-Anzahl ist. Das drückt natürlich die Performance. Nvidia braucht auch Zeit, nämlich dann wenn die Queue-Anzahl über 31 steigt. Dann wird der Overhead auch größer weil gewartet werden muss.

Ähh ne AMD braucht so lange um die Queue 1 - 128 abzuarbeiten, während NV sich immer nur einen Block nach dem anderen vornimmt, so habe ich das verstanden, oder sehe ich das jetzt falsch?....

 

[Limit]

Ob und welche Nachteile die Deaktivierung von "Async Compute" für das Spielerlebnis hat, wissen wir nicht.

Async Compute ist ein reines Performance-Feature. Im Normalfall sollte eine Aktivierung die Abarbeitung effizienter und damit schneller machen. Potentiell könnte es auch die Latenzen verringern was aber vermutlich nur sehr selten feststellbar sein wird. Fehlt es oder deaktiviert man es, sollte das bis auf eine verringerte Leistung keine Auswirkungen haben.

Wir wissen auch nicht, ob eine komplette Deaktivierung wirklich nötig ist, oder ob es nicht reichen würde, es für Nvidia etwas anders zu implementieren (z.B. weniger Threads).

Im Moment scheint die nVidia-Empfehlung zu sein es abzuschalten. Natürlich kann sich das noch ändern. Da wird man einfach abwarten müssen.

Und ich gebe offen zu, ich weiß nicht mal wirklich wofür "Async Compute" gut ist. (Da muss ich mich erst noch einlesen.)

Ich bin da auch kein Experte, aber soweit ich das verstanden habe, können die GPUs ohne Async Compute nicht gleichzeitig Graphic und Compute-Berechungen durchführen, sondern müssen beides abwechselnd erledigen. Das führt zu Ineffizienzen. Während Graphic-Berechnungen können dann keine Compute-Berechnungen durchgeführt werden und umgekehrt, selbst wenn Resourcen verfügbar wären.

Soll es nur die GPU-Leistung optimieren? Oder vielleicht die CPU entlasten?

ja, nein

Wenn ja, dann wäre es ja kein Beinbruch es bei Nvidia wegzulassen, wenn es da einen kontraproduktiven Effekt hat.

Wie gesagt, ist es ein reines Performance-Feature. Hat man eine funktionierende Implementierung verbessert es die Effizienz der Architektur. Hat man es nicht, dann eben nicht. Wenn man es hat, die Performance dadurch aber nicht steigt, dann ist es genau so nützlich wie ein fünftes Rad am Wagen. Ich vermute, dass nVidia entweder den Feature keine große Bedeutung zugemessen hat und es deshalb nur pro forma implementiert hat oder dass die Implementierung ein Bug hatte und sie sie deshalb "deaktiviert" wurde / werden soll.

Oder kann es wirklich genutzt werden, um grafische Effekte zu realisieren, die ohne nicht (oder nur mit viel Leistungsverlust) möglich wären, ahnlich wie Tessellation.

Nein, Async Compute erhöht einfach nur die allgemeine Effizienz der Architektur bei parallelen Graphic- und Compute-Berechnungen. Natürlich kann man die gesteigerte Leistung in zusätzliche Effekte investieren, aber Wunder würde ich nicht erwarten.

Für Tessellation wird inzwischen ja auch bei vielen Spielen ein spezieller "AMD-Modus" genutzt, der Rücksicht auf die Beschränkungen der GPUs nimmt und trotzdem ein gutes Ergebins liefert.

Die hohen Tesselation-Stufen waren ein Pseudo-Feature, das außer der nVidia-Marketing-Abteilungen keinem einen Nutzen gebracht hat. AMD hat an der Stelle gespart. Das kann man ihnen natürlich vorwerfen, aber da die hohen Stufen praktisch keinen visuellen Vorteil bringen wäre das überhaupt kein Problem, wenn nicht nVidia durch Gameworks dafür gesorgt hätte, dass in entsprechenden Spielen unsinnig hohe Stufen genutzt werden.

Insgesamt will ich jedenfalls erstmal nicht sagen, dass das Tessellation-Thema zu Unrecht ein Aufreger war und das hier zu Recht. Dafür wissen wir längst noch nicht genug.

Abgeschließend geklärt ist die Sache sicherlich noch nicht. Sollte sich das Verhalten aber auch bei anderen Spielen nachvollziehen lassen, wäre das ein weiteres Mal, dass nVidia eine Sache vergurkt und der Kunde deswegen Nachteile hat.

Wie gesagt, für Tessellation haben sich inzwischen einige Entwickler diese Mühe gemacht und das Thema ist weitgehend in Vergessenheit geraten. Vielleicht läuft es hier ja ähnlich?

Darauf wird es sicherlich hinauslaufen. Im Prinzip ist es doch so wie so oft bisher. Ältere AMD-Karten können länger mithalten als gleichalte nVIdia-Karten. Die Performance-Verhältnisse zwischen GCN- und Maxwell-Karten dürfte sich bei DX12-Spielen zu Gunsten von AMD verschieben. nVidia dürfte das egal sein, da die Maxwell-Karten bereits verkauft sind und sie mit Pascal die Chance haben die Probleme auszubügeln.

 

[Zerbich]

Habe ich dann das Recht meine GTX 980 Ti bei Amazon zurückzuschicken, da sie gar nicht volles DX12 kann?

 

[strex]

Ähh ne AMD braucht so lange um die Queue 1 - 128 abzuarbeiten, während NV sich immer nur einen Block nach dem anderen vornimmt, so habe ich das verstanden, oder sehe ich das jetzt falsch?....

Laut den Benches nicht, es braucht 50ms System Overhead bei einer Queue und bei 128 Queues. Der Overhead ist immer gleich egal wie viel Queues belegt sind. Ich vermute daher, dass immer alle Queues iterativ geprüft werden egal ob etwas vorhanden ist und benötigt eben Zeit.

Rein von den Queue-Anzahl her ist selbst die sequenzielle Bearbeitung bei Nvidia deutlich im Vorteil, bis eben die Queue-Anzahl über einen gewissen Wert steigt.

Sequentiell ist der Teil zwischen den Switch von Graphics Mode zu Compute Mode, folgen ständig Graphics Tasks auf Compute Tasks erfordert es ständig einen Sync und ist dann sequentiell. Kommen viele Compute Tasks hintereinander ohne in den Graphics Mode zu wechseln, können diese Tasks asynchron verarbeitet werden.

In der Tat geht dies ziemlich schnell, sprich der Wechsel zwischen beiden Modi. Irgendwann stehen aber nicht mehr zur Verfügung und es geht in die Knie.

Also muss man schauen, dass man immer schön lange Schlangen and Compute Tasks hat die nicht ständig von Graphics Tasks unterbrochen werden und die Queue-Anzahl niedrig zu halten. Wenn man das nicht gemacht und eine Engine gebaut hat, ist es klar das man sich dann ärgert.

 

[Envoy]

Sehr unschön, ich hoffe ich werde meinen 980 Ti kauf nicht bereuen in einem Jahr... Finde es super dass die AMD Karten beschleunigt werden und mit NVIDIA gleich bzw sogar ein paar prozent davonziehen. Fall das so bleibt und die Fury X von mir aus 10-15% schneller arbeitet kann ich damit leben ohne mich zu nerven. Wütend auf Nvidia bin ich allemal, aber mal schauen was die nächsten Spiele so aufzeigen werden. Ich hoffe mal dass bei der nächsten Gen AMD wieder die Nase vorn hat, dann "darf" ich wieder AMD kaufen. Marken sind mir eigentlich egal, wenn ich kaufe gibt es für mich immer nur die Karte mit der meisten Leistung... Da ich sowieso immer übertakte kam vor 1 1/2 Monaten nur die 980 Ti in frage. Auch wenn mir AMD eigentlich sympatischer ist.

 

[Herdware]

DX12 ist eben einfach mehr als nur inspiriert von Mantle.
Die ganze Idee der Paralellisierung und umverteilung stammt ja praktisch aus der AMD API.

Naja. Mantle ist (höchstwahrscheinlich/in weiten Teilen) letzlich eine Übertragung der XBoxOne-API auf PCs. Das stimmt.
Aber AMD hat garantiert nicht allein die XBoxOne-API entwickelt. Im Wesentlichen ist das ja eine DirectX-Variante. (Und deswegen ist auch Mantel D3D sehr ähnlich.) Die XBox-API wurde in Zusammenarbeit von AMD (als Hersteller der GPU und deren Treibern) und Microsoft entwickelt, nicht von AMD allein. Wer den größeren Beitrag geleistet hat, wissen wir nicht, aber ich würde eher auf MS tippen, weil DirectX ja letztlich ihr Baby ist und sie auch nicht das erste Mal eine hardwarenahe DX-Variante für ihre Konsolen entwickelt haben.

Deshalb sind auch Microsofts Aussagen richtig, dass DirectX12 keine (reine) Reaktion auf Mantle ist und dass die Grundlagen dafür schon gelegt wurden, bevor es Mantle gab. Mantle und DX12 sind im Prinzip Geschwister und Kinder der selben Mutter (XBoxOne-API). Aber Mantle gab für MS den Ausschlag, diese DX-Optimierungen auch für PCs zu bringen.

Nvidia ist halt etwas außen vor. Trotzdem wird MS die nicht ganz hängen gelassen haben. Schließlich hat Nvidia inzwischen über 80% Marktanteil bei dedizierten PC-Grafikkarten und auch Intel wird ein Wörtchen bei DX12 mitgeredet haben. Die sind ja der größte GPU-Hersteller überhaupt. Demgegenüber ist AMD nur ein kleiner Fisch.

 

[xeonking]

Habe ich dann das Recht meine GTX 980 Ti bei Amazon zurückzuschicken, da sie gar nicht volles DX12 kann?

Wohl eher nein. Aber Amazon ist mehr als Kulant.

gruß

 

[Moon_Knight]

Und? Selbst wenn, was wäre daran tragisch?

Wer hat von Tragik geredet? Du hast in den Raum gestellt, dass die sich dort vielleicht nur Anschweigen, ich habe es begründet. Reicht die Aufmerksamkeitsspanne heutzutage nicht mal mehr für 3-4 Posts?

 

[Minutourus]

NV erfüllt die DX Spezifikationen ja generell, sie werden nur anders abgearbeitet bzw umgesetzt, korrekt?

Würde mich nicht wundern wenn NV alles daran setzt das dieses Feature in ihrer GW Umgebung nicht zum tragen kommen wird, vermutlich wieder so eine Lobbyisten Aktivität wo einige Summen ihren Besitzer wechseln....