Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Jetzt ist Ihre Meinung gefragt zu Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Mit einem speziell auf DirectX 12 optimierten Treiber will Nvidia bald auf Geforce-Grafikkarten für ein merkliches Leistungsplus bei Spielen mit dem aktuellen Renderpfad sorgen. Zudem soll es mit dem unter dem Namen "Gameworks DX12" angekündigten Paket viele Verbesserungen für die hauseigenen Entwicklerwerkzeuge geben.

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

Zurück zum Artikel: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Also es ist ja wirklich schön wenn man die Einstellungen so wählt dass man den größtmöglichen Zuwachs an Performance ins Werbeblätchen schreiben kann.
Persönlich hätte ich aber mehr von der Aussage, dass es vielleicht "nur" 10% mehr Leistung sind wenn man RoTR in 4K/Ultra mit ~35fps spielt (da das noch machbar ist) statt nur um mit Gewalt auf 30% Leistungszuwachs zu kommen noch 2xSSAA auflegt (also effektiv in 8K spielt) was mit 20 fps unspielbar ist. Selbst auf ner TXP ist das nicht feierlich.

Aber immerhin, zumindest die Entwicklung von DX12 geht voran.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Naja, wenn sie aber die DX12 Performance verbessert haben, ist das doch gut. DX12 lief ja nicht soo gut. Finde die Entwicklung dennoch die richtige Entscheidung.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Freiheraus schrieb:

Sry Nv, juckt grad net, Ryzen is dran.

Zum Vergrößern anklicken....

Ich finds by the Way interessant ob eine GTX 1060 dann in Directx12 eine RX 480 überholen kann.
Wieso nicht zu Ryzen eine passende Grafikkarte, eine GTX 1060 mit 9GBps Ram?

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Incredible Alk schrieb:

Also es ist ja wirklich schön wenn man die Einstellungen so wählt dass man den größtmöglichen Zuwachs an Performance ins Werbeblätchen schreiben kann.
Persönlich hätte ich aber mehr von der Aussage, dass es vielleicht "nur" 10% mehr Leistung sind wenn man RoTR in 4K/Ultra mit ~35fps spielt (da das noch machbar ist) statt nur um mit Gewalt auf 30% Leistungszuwachs zu kommen noch 2xSSAA auflegt (also effektiv in 8K spielt) was mit 20 fps unspielbar ist. Selbst auf ner TXP ist das nicht feierlich.

Aber immerhin, zumindest die Entwicklung von DX12 geht voran.

Zum Vergrößern anklicken....

Tendenziell ist es doch eher so, dass Treiberoptimierungen nur bei relativ geringer Grundlast größere auswirkungen zeigen, weil man die Grafikkarte eben trotz geringer Last besser ausgelastet bekommt und so mehr FPS umsetzen kann.

Wenn die Grundlast bei 4K z.B. schon sehr hoch ist, dann sollten Treiberoptimierungen doch eigentlich vergleichsweise wenig Wirkung zeigen, da hier die Rohleistung in den Fokus rückt. Das optimierungspotential ist bei geringerer Last bzw. Auflösung doch viel höher. Das hat auch AMD immer wieder gezeigt.

Grundsätzlich würden also gute Performancegewinne bei extremen Auflösung darauf schließen lassen, dass die Zuwächse bei geringer Auflösung umso höher ausfallen. Wäre für mich zumindest plausibel.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Irgendwie lustig - was Nvidia da macht geht eigentlich gegen den Grundgedanken der Low-level API.
Denn eigentlich sollte der <Treiber fast garkeinen Einfluss haben bei lowlevel,w enn denn die Spieleentwickler alles richtig gemacht haben.

Aber das sieht genau so aus wie auch schon mit Dx10/11 - die Entwickler liefern halbgaren Code, AMD/Nvidia müssen es per Treiber richten.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Naja mit dem Hersteller zusammenarbeiten musst du ja trotzdem.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Ich muss schon sagen NVidia ist echt gerissen.

Sie haben nicht geschrieben für welche Grafikkarten. /
Und ich wiederhole es gerne immer wieder, NV verspricht DX12.1 schon seit gtx980 und bis jetzt lieferten Sie nicht einmal dx12.

Bin schon sehr gespannt!

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

NV verspricht DX12.1 schon seit gtx980 und bis jetzt lieferten Sie nicht einmal dx12.

Zum Vergrößern anklicken....

Hä? Wieso soll Dx12 auf einer GTX 980 nicht funktionieren? Oder ist das jetzt wieder ein Trollversuch bezüglich Asynchronous Compute?

Denn eigentlich sollte der <Treiber fast garkeinen Einfluss haben bei lowlevel,w enn denn die Spieleentwickler alles richtig gemacht haben.

Zum Vergrößern anklicken....

Gewaltiges Missverständnis auf deiner Seite. Es ist zwar richtig, dass der Treiber nicht mehr erraten soll, was das Spiel machen will, und das Spiel nicht erraten sollte, was der Treiber macht, um irgendwie die Heuristiken des Treibers zu triggern, mögliche Performance-Probleme gibt es aber haufenweise. Sei es schlechtes Scheduling von Jobs, die an die GPU gesendet werden, nicht optimierte Clear-Funktionen von Bildern, unsinnige Compute Shader-Invocations zum Kopieren von Daten aus der DMA-Queue in den VRAM, zu strenge Memory Barriers oder was auch immer - die Funktionen, die die APIs bieten, wollen ja auch irgendwo implementiert werden.

Sieht man aktuell auch schön am Open Source-Vulkan-Treiber RADV für AMD, der noch nicht fertig ist und im Moment insgesamt ziemlich lahmarschig ist, aber durch Optimierungen an allen möglichen Stellen profitiert, die teilweise nicht einmal etwas mit Vulkan selbst zu tun haben.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Laggy.NET schrieb:

Tendenziell ist es doch eher so, dass Treiberoptimierungen nur bei relativ geringer Grundlast größere auswirkungen zeigen, weil man die Grafikkarte eben trotz geringer Last besser ausgelastet bekommt und so mehr FPS umsetzen kann.

Wenn die Grundlast bei 4K z.B. schon sehr hoch ist, dann sollten Treiberoptimierungen doch eigentlich vergleichsweise wenig Wirkung zeigen, da hier die Rohleistung in den Fokus rückt. Das optimierungspotential ist bei geringerer Last bzw. Auflösung doch viel höher. Das hat auch AMD immer wieder gezeigt.

Grundsätzlich würden also gute Performancegewinne bei extremen Auflösung darauf schließen lassen, dass die Zuwächse bei geringer Auflösung umso höher ausfallen. Wäre für mich zumindest plausibel.

Zum Vergrößern anklicken....

Ich kann dir durchaus folgen, jedoch glaube ich nicht dass das hier greift.

Beispiel:
Keine DX12 Verbesserung GTX1070 vs GTX1070 = 0%
DX12 Verbesserung GTX1070 vs GTX1070 = +% (sicher irgend eine Verbesserung)

So weit denke ich sind wir einverstanden.
Jetzt war das Problem nie die CPU Auslastung sondern das was Grafikkarten auf die Sprünge helfen würde, also Async Compute. Asynchronous Shader: Nvidias Grafikkarten soll eine wichtige DX12-Funktion fehlen - Golem.de
(Es gab da noch ein zwei andere Dinge kann mich aber nicht mehr genau daran erinnern also lasse ich es.)

Geringere Grafikauslastung resp. niedrigere Einstellwerte würde die CPU relevants erhöhen. Hier gehen höhere Einstellungen/Anforderungen auf lasten der Grafikkarte.
Für mich sind dies schon die maximalen Werte die zu erwarten sind.


ps: AMD Karten kratzt es im allgemeinen weniger wenn die GPU Anforderungen steigen, hier kann ich ganz klar zustimmen.
Das untermauert auch wieder klar Ihre Langlebigkeit. Treiber Optimierungen kommen dann auch noch dazu.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Kollege welcher Troll versuch?? Nein mit nichten!

Ja du hast recht der Treiber wurde mal nachgereicht.
NV sagt sie hätten das Feature drauf , ich selbst habe es nicht nach kontrolliert aber vielleicht sollte das einer nach der Thematik mit der GTX970 tun der Ahnung und ein Electronenmicroskop hat.

Fakt: Was ich sagen kann ist, dass Asynchronous compute von NV ständig nach möglichkeit umgangen wird, teils wird versucht Absprachen mit Entwicklern von DX12 Games zu treffen.
Tatsächlich war es per Treiber nicht von Anfang an vorhanden/aktiviert, aber wir nehmen jetzt einfach mal an, dass in HW genügend vorhanden ist um sich DX12 auf die Karte zu kleben und wir hier keine "SoftwareEmulation" haben was aber den zum Teil entstehenden Perf. verlust erklären könnte :-O?

Wie geschrieben ich bin sehr gespannt ob sich hier noch was ergibt. NVidia sind echt Zauberer was Softwareprogrammierung an geht, respekt!


ps: Hat denn überhaupt jemand mal mit gekriegt, dass die 970 per Treiber künstlich max. auf 3.5GB gehalten wird.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Aktuell ist der 378.66 WHQL, lange kann es bis zum 378.74 also nicht mehr dauern

Wahrscheinlich ist es nächste Woche zum GTX 1080 Ti Launch schon soweit.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

VikingGe schrieb:

Sei es schlechtes Scheduling von Jobs, die an die GPU gesendet werden, nicht optimierte Clear-Funktionen von Bildern, unsinnige Compute Shader-Invocations zum Kopieren von Daten aus der DMA-Queue in den VRAM, zu strenge Memory Barriers oder was auch immer - die Funktionen, die die APIs bieten, wollen ja auch irgendwo implementiert werden.

Zum Vergrößern anklicken....

Dies sind alles aufgaben die dem Spiele-Entwickler zufallen wenn er eben eine Low-level api nutzen will - und NICHT teil des Treibers.
Deshalb finde ich es ja auch so eigenartig das überheupt jemand Dx12/Vulkan für eine gute Entwicklung hält. low-level Api ist eben genau der Schritt weg von Treibereingriffen. Es soll jaj jetzt alles von den Entwicklern slebst gemanaged werden, bis runter zum korrekten Qeue-Scheduling.

Bei Dx11 hat Nvidia noch per Treiber die ganzen Compute-Tasks reinschedulen können, mit Dx12 muss das jetzt eben per Hand gemacht werden - und jetzt brignt dann Nvidia doch wieder Treiber raus die das umgehen. zeigt doch ziemlich eindeutig was für ein Griff ins Klo das ganze ist. Die meisten Spiele sind ein wandelnder Zombie-Bug, unzählige Fehler die nur durch viel geflicke iorgendwie noch am laufen sind, bis dann AMD/Nvidia daherkommen und das ganze durch teils sogar eigene Shader ausbügeln.


Ja, die Api-Funktionen wollen implementiert werden - aber bei Dx12 eben ohne Sicherheit. Wenn man es richtig bedient dann funktioniert alles. Wenn aber (so wie gewöhnlich) die Spezifikationen nicht eingehalten weden muss sich jetzt der Entwickler darum kümmern.
Und von seitend er hardwarehersteller ist jetzt weit weniger zu tun - denn die Apis sind eben low-level - ein fast direkter Zugriff auf die Hardware. Da sind keine zwischenschichten mehr.

openGl hats vorgemacht, Mantel/Vulkan/Dx12 haben nachgezogen - nur bissher wird eben genau der so hochgelobte Lowlevelzugriff schön gemieden.




@Pleasedontkillme
Tja - nvidia hat auch gehalten was sie versprochen haben - auch mit einer 970er hast du das volle Dx12 packet.
Async-Compute inclusive. Nur eben ist Async keine Wundewafe sonder das große heftplfaster mit dem AMD versucht das abgetrennte bein dran zu halten.

Mal abgesehen von der absolut besch*** Namensgebung (der name bezeichnet eigentlich einen ganzen bereich nicht ein feature) - stark vereinfacht ausgedrückt erlaubt es einen Teilweisen context-switch wen der aktuelle Grafik-Thread am idlen ist.
Für AMD ist das schick, denn die haben ja bissher das problem die Pipelines ohne blasen zu füllen. da gibt es oft genug Zeiten wo die hälfte der vector-Units nichts tun. Dehalb hat AMD auch einen extra cache eingebaut um diesen COntext-switch zu beschleuningen.
Jetzt ist es aber schon so das intel das längst per Treiber geregelt hat und damit eine Core-Auslastung von deutlich über 95% erreicht hat. Da gibt es ncihtmehr viel zu holen. Wenn dann jetzt aber noch extra mit Async-befehlen reingepfuscht wird dann kann die Leistung eben noch sinken die die Cores bereits ausgelastet waren und jetzt dann trozdem stopen müssen um einen neuen Queue zu bekommen.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Dies sind alles aufgaben die dem Spiele-Entwickler zufallen wenn er eben eine Low-level api nutzen will - und NICHT teil des Treibers.

Zum Vergrößern anklicken....

Natürlich ist es Sache des Treibers, Clears, Kopien etc. zu implementieren, die vom Entwickler veranlassten Speicherlayout-Transformationen durchzuführen etc., denn das ist der Teil, der wirklich hardwarespezifisch ist. Vulkan und Dx12 sind schließlich immer noch Abstraktionsschichten. Die Aufgabe des Entwicklers ist es, Jobs zu starten (Drawcalls etc.) und dem Treiber die Datenabhängigkeiten mitzuteilen, damit der die nicht mehr erraten muss wie bei Dx11, die Aufgabe des Treibers ist es, dafür zu sorgen, dass das irgendwie das macht, was der Entwickler will.

Worauf ich hinaus will, ist, dass man nur sagt, was getan werden soll, das wie genau und die Performance davon hängt aber nach wie vor vom Treiber ab. Das was ist dabei eben deutlich expliziter als bei Dx11 und erspart dem Treiber sehr viel Raterei, lädt aber natürlich auch zu ineffizientem Code ein, wenn die Entwickler nicht wissen, was sie tun.

Wenn aber (so wie gewöhnlich) die Spezifikationen nicht eingehalten weden muss sich jetzt der Entwickler darum kümmern.

Zum Vergrößern anklicken....

Das ist ja auch der Sinn von Spezifikationen, und deswegen gibt es auch Debug-Layer, damit der Entwickler überhaupt eine Chance hat, auf Fehler aufmerksam zu werden. Auch wenn da sicherlich noch so einige Probleme unentdeckt durchflutschen. Aber eigentlich ging es doch gerade um Treiberoptimierung und nicht um Fehlererkennung.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Casurin schrieb:

Dies sind alles aufgaben die dem Spiele-Entwickler zufallen wenn er eben eine Low-level api nutzen will - und NICHT teil des Treibers.
Deshalb finde ich es ja auch so eigenartig das überheupt jemand Dx12/Vulkan für eine gute Entwicklung hält. low-level Api ist eben genau der Schritt weg von Treibereingriffen. Es soll jaj jetzt alles von den Entwicklern slebst gemanaged werden, bis runter zum korrekten Qeue-Scheduling.

Bei Dx11 hat Nvidia noch per Treiber die ganzen Compute-Tasks reinschedulen können, mit Dx12 muss das jetzt eben per Hand gemacht werden - und jetzt brignt dann Nvidia doch wieder Treiber raus die das umgehen. zeigt doch ziemlich eindeutig was für ein Griff ins Klo das ganze ist. Die meisten Spiele sind ein wandelnder Zombie-Bug, unzählige Fehler die nur durch viel geflicke iorgendwie noch am laufen sind, bis dann AMD/Nvidia daherkommen und das ganze durch teils sogar eigene Shader ausbügeln.


Ja, die Api-Funktionen wollen implementiert werden - aber bei Dx12 eben ohne Sicherheit. Wenn man es richtig bedient dann funktioniert alles. Wenn aber (so wie gewöhnlich) die Spezifikationen nicht eingehalten weden muss sich jetzt der Entwickler darum kümmern.
Und von seitend er hardwarehersteller ist jetzt weit weniger zu tun - denn die Apis sind eben low-level - ein fast direkter Zugriff auf die Hardware. Da sind keine zwischenschichten mehr.

openGl hats vorgemacht, Mantel/Vulkan/Dx12 haben nachgezogen - nur bissher wird eben genau der so hochgelobte Lowlevelzugriff schön gemieden.




@Pleasedontkillme
Tja - nvidia hat auch gehalten was sie versprochen haben - auch mit einer 970er hast du das volle Dx12 packet.
Async-Compute inclusive. Nur eben ist Async keine Wundewafe sonder das große heftplfaster mit dem AMD versucht das abgetrennte bein dran zu halten.

Mal abgesehen von der absolut besch*** Namensgebung (der name bezeichnet eigentlich einen ganzen bereich nicht ein feature) - stark vereinfacht ausgedrückt erlaubt es einen Teilweisen context-switch wen der aktuelle Grafik-Thread am idlen ist.
Für AMD ist das schick, denn die haben ja bissher das problem die Pipelines ohne blasen zu füllen. da gibt es oft genug Zeiten wo die hälfte der vector-Units nichts tun. Dehalb hat AMD auch einen extra cache eingebaut um diesen COntext-switch zu beschleuningen.
Jetzt ist es aber schon so das intel das längst per Treiber geregelt hat und damit eine Core-Auslastung von deutlich über 95% erreicht hat. Da gibt es ncihtmehr viel zu holen. Wenn dann jetzt aber noch extra mit Async-befehlen reingepfuscht wird dann kann die Leistung eben noch sinken die die Cores bereits ausgelastet waren und jetzt dann trozdem stopen müssen um einen neuen Queue zu bekommen.

Zum Vergrößern anklicken....

Nur das Geforce-Karten vor Pascal allesamt Leistung verlieren sobald Async Compute zum Einsatz kommt.
Das liegt daran das die Karten das nicht in Hardware können sondern kurz komplett stoppen müssen bevor der Compute Befehl dazwischen geschoben werden kann.
Bei Pascal wurde es verbessert in dem nicht der gesamte Chip stoppt sondern nur ein betroffener Cluster. Sprich es wurde ein wenig verbessert aber immer noch nicht zu 100% in Hardware umsetzbar.
Wenn die Karten Async Compute in Hardware könnten würde selbst bei einer 100% ausgelasteten Karte keine Performance Verschlechterung auftreten.

Und der Treiber ist immer dazwischen. DX12 hat den Vorteil nicht so viele Abstraktionsschichten zu haben wie DX11 , was nötig war um die Vielfalt an PC-Hardware zu unterstützen.
Der Kelch wird mit DX12 an die Entwickler gereicht und die müssen sich darum kümmern.
Der Treiber wird dadurch nicht Mundtot gemacht^^

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Die Treiber machen eben weniger - und genau die sind es aber bei Nvidia die bissher die Karten zu beinahe 100% ausgelastet haben.
Denn bisher war es aufgabe des Treibers zu sagen, wann wo was ausgeführt wird. Nun mit den Lowlevel Apis ist es Aufgabe der Entwickler explizit zu sagen wenn welcher Queue bearbeitet werden soll. Und dies sind Befehle die eigentlich direkt an die Hardware gehen - Ohne treiber interaktion.

Wie zB auch mit barriers - unter Dx11 greift hier der Treiber ein - dem ist nichtmehr so unter Dx12. Dass gilt auch zB für flags.
Nvidia hat hervorangede Dx11 treiber die viele probleme Vorab erkennen und somit die Leistung erhöhen. und eben genau dies wird durch einen low-level Zugriff unterwandert.
klar hat man damit noch nicht direkten zugriff auf die Resourcen, aber die layer sind nurmehr sehr dünn gestreut, da bleiben wenige Eingriffsmöglichkeiten.

scorplord schrieb:

Wenn die Karten Async Compute in Hardware könnten würde selbst bei einer 100% ausgelasteten Karte keine Performance Verschlechterung auftreten.

Zum Vergrößern anklicken....

Falsch. Async Compute ist ein vom Entwickler angesetzter Stop der Befehlskette. In jedem Szenario in dem die Cores bereits am arbeiten sind und dann zu einem context-switch gezwungen werden kommt es zwansgweise zu Leistungsverlust.
Async ist kein Feature das die allgemeine Leistungsfähigkeit steigert sondern Auslastungsprobleme bekämpft.

AMD hat da ja diese nette Analogie mit der Straße mit Kreuzung gemacht - eignet sihc in diesem falle doch recht gut dafür.
Bei Nvidia wurde bisher die Kreuzung schon so gut geregelt das die Straße voll gefüllt ist, keine freien Stellen mehr. AsyncCompute ist dann wie eine extra Kreuzung die manuell vom Entwickler geschalten wird. Egal wie gut man eine Kreuzung schaltet, beim Schalten entstehen leerstellen.
für AMD ist dies natürliche eine verbesserung, denn wie geasgt (sie haben es auch oft genug offen gesagt) hatten die das Problem bei GCN die 'straße' voll zu füllen - da gibt es große leere Blasen - und genau dort hilft dann Async Compute.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

hoffe dass der SLI support für dx12 endlich mal optimiert wird

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Casurin schrieb:

...
Falsch. Async Compute ist ein vom Entwickler angesetzter Stop der Befehlskette. In jedem Szenario in dem die Cores bereits am arbeiten sind und dann zu einem context-switch gezwungen werden kommt es zwansgweise zu Leistungsverlust.
Async ist kein Feature das die allgemeine Leistungsfähigkeit steigert sondern Auslastungsprobleme bekämpft.

AMD hat da ja diese nette Analogie mit der Straße mit Kreuzung gemacht - eignet sihc in diesem falle doch recht gut dafür.
Bei Nvidia wurde bisher die Kreuzung schon so gut geregelt das die Straße voll gefüllt ist, keine freien Stellen mehr. AsyncCompute ist dann wie eine extra Kreuzung die manuell vom Entwickler geschalten wird. Egal wie gut man eine Kreuzung schaltet, beim Schalten entstehen leerstellen.
für AMD ist dies natürliche eine verbesserung, denn wie geasgt (sie haben es auch oft genug offen gesagt) hatten die das Problem bei GCN die 'straße' voll zu füllen - da gibt es große leere Blasen - und genau dort hilft dann Async Compute.

Zum Vergrößern anklicken....

Also frei interpretiert darf ich deiner Aussage entnehmen, dass was einst als DX12(.1) angepriesen wurde ein Schrotthaufen an DX12 ist der dann bei Pascal in eine Schadensbegrenzung mündete?

Bei welcher Hardware und was genau sind deine Erwartungen für den neuen "heilbringenden" Treiber für DX12?
Soll Er Krüpel das Laufen beibringen?

An alle :
Ist sonst einem schon aufgefallen, dass NV`s Versprechen immer frühestens bei der zweiten Generation nutzbar sind?
*T&L* ab GeForce2, *pixel and vertex shaders DX8* erst bei GeForce4, *DX12* "Pascal" ??
(Physics ist auch so eine naja Sache, zweite Karte nutzen? ups 9800GT ist zu alt und bleibt meine letzte NVKarte!)

Vieleicht bilde ich mir das all die Jahre nur ein und es war reiner Zufall. Auch hier ist es sicher kein schebiger Trick um die Neuesten Karten besser da stehen zu lassen resp. um zum nachrüsten zu bewegen.


Ich nehme die Chips nicht in jedem Ihrer Vorgänge ausseinander und beurteile Umsetzungen. Ich schreite lieber einen Schrit zurück und beurteile das Schauspiel
Ich bin soooowas von gespannt was die Zeit bringen wird!!

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

Casurin schrieb:

Falsch. Async Compute ist ein vom Entwickler angesetzter Stop der Befehlskette. In jedem Szenario in dem die Cores bereits am arbeiten sind und dann zu einem context-switch gezwungen werden kommt es zwansgweise zu Leistungsverlust.
Async ist kein Feature das die allgemeine Leistungsfähigkeit steigert sondern Auslastungsprobleme bekämpft.

AMD hat da ja diese nette Analogie mit der Straße mit Kreuzung gemacht - eignet sihc in diesem falle doch recht gut dafür.
Bei Nvidia wurde bisher die Kreuzung schon so gut geregelt das die Straße voll gefüllt ist, keine freien Stellen mehr. AsyncCompute ist dann wie eine extra Kreuzung die manuell vom Entwickler geschalten wird. Egal wie gut man eine Kreuzung schaltet, beim Schalten entstehen leerstellen.
für AMD ist dies natürliche eine verbesserung, denn wie geasgt (sie haben es auch oft genug offen gesagt) hatten die das Problem bei GCN die 'straße' voll zu füllen - da gibt es große leere Blasen - und genau dort hilft dann Async Compute.

Zum Vergrößern anklicken....

Nix Falsch... Das ist kein gesetzter Stop sondern ein intelligent geregelt Vorgang der nur vollführt wird wenn Platz dafür da ist. Ansonsten macht der Entwickler was falsch.
Wäre es ein festgesetzter Stop würde es IMMER Leistungsverschlechterung geben weil ja immer die Karte bzw mindestens die Pipeline kurz stoppen müsste um die Arbeit zu verteilen.
Dies ist aber nicht der Fall.
Und ohne das nVidia Leistung eingebüßt hat haben sie bei Pascal es ja wenigstens geschafft dafür zu sorgen keine bis weniger Verlust zu haben dadurch das es in Clustern nur stoppen muss.
Das Stoppen kommt nur von den alten NV-Karten da diese Komplett anhalten.
Bei AMD ist das alles in Hardware und daher muss nix stoppen, sondern wird !WENN! einige Recheneinheiten im Idle sind dazwischen geschoben. In Hardware geht das ohne Leistungsverlust, aber wenn Software (Treiber) das regeln muss kommt es eben zu Verzögerung.
Ähnlich mit SMT.
Wenn die Software dafür richtig und auf die Nutzung hin programmiert ist bringt es zusätzliche Leistung weil der Kern besser ausgelastet wird.
Natürlich muss aber auch berücksichtigt werden das der Kern schon ohne SMT 100% ausgelastet sein kann. Dann muss es halt (Hardwarenahprogrammiert) vom Entwickler angepasst werden das dann kein Befehl dazwischen erzwungen wird.
Will nicht gegen NV hetzen oder so jetzt falls es so rüber kommt, aber die haben aktuell das Problem AC nicht in Hardware zu unterstützen.

Async Compute ist eine super Sache. Je mehr Shader es geben wird umso schwerer wird es alle auszulasten (Parallelisierung). Also warum nicht jetzt starten damit die Software darauf angepasst wird bevor wir dasselbe Spiel wie bei den CPUs haben und Mehrleistung über Takt kaum noch möglich ist, weil wir schon extrem hoch takten.
Lieber jetzt dafür Sorgen das die Software das ausnutzen kann um nicht in paar Jahren jedes Jahr 3% Leistung zu bekommen...

MatimaDE schrieb:

hoffe dass der SLI support für dx12 endlich mal optimiert wird

Zum Vergrößern anklicken....

Ist Sache der Entwickler bei DX12.

AW: Nvidia Gameworks DX12: Optimierter Game-Ready-Treiber & verbesserte Entwicklerwerkzeuge

ich frag mich ja, wie mans hinbekommt, auf NV wegen fehlender async shader abzuätzen, wobei die Verfasser solcher Schmähkritiken vollkommen ausblenden, dass weder NV noch AMD sämtliche DX12-features bieten. dazu gesellt sich die fehlende Differenzierung von DX12 und DX12.1. ganz zu schweigen vom Abpöbeln auf NVs Treiberarbeit (von wegen low-level bräuchte das ja gar nich, "was schummelt NV da wieder?"), während gleichzeitg andernthreads AMDs Treiberarbeit als güldenes Kalb gehuldigt wird (inkl jahrelangem drauf warten).
diese paradoxe Doppelmoral stinkt zum Himmel.

NV arbeitet an Treibern und an der DX-Fähigkeit, wie AMD auch. is doch super.