News DirectX 12: Nvidia-Treiber soll Async Compute nachreichen

[Dai6oro]

PCGH hat weitere Karten gestestet:

http://www.pcgameshardware.de/DirectX-12-Software-255525/Specials/Spiele-Benchmark-1172196/

 

[ampre]

Scheint wohl wirklich zu sein das die alten Karten von AMD einen guten boost durch DX12 bekommen. eine 290 tri-XOC hängt eine 780 ti Phantom um gut 12% ab in HD und in UHD sie auf Augenhöhe. Das ist schon herb da beide ungefähr den gleichen Takt haben aber die 290 weniger Shader hat.

 

[Dai6oro]

Ein R9 290 ohne X liegt vor einer gut getakteten Phantom. Die nicht getestete R9 290X liegt in Form einer R9 390X noch mal ein gutes Stück drüber. In diesem Bench wohlgemerkt.

 

[ampre]

Oh stimmt das ist nur eine 290 das tri-x oc verwirrt immer etwas Danke für die Aufklärung. Das ist dann wirklich herb 390x gut 26% vor einer 780ti und gut 9% vor einer gtx 980. Das tut weh.

 

[Andy1978]

Also ich hab mir die neune Benchmarks mal angesehen .
Also so groß ist der Unterschied jetzt nicht zwischen AMD und Nvidia . Gut bei 720p ist der unterschied schon grösser aber wenn interessiert die Auflösung . Bei denn hören Auflösungen die sie Unterschiede so gering das es vernachlässigbar ist .
Mal schauen wie es dann ausschaut wenn Nvidia die Treiber optimiert hat . Ich hab mir das alles schlimmer vorgestellt !!!

LG
Andy

 

[BookerDeWitt]

Man darf sich auch nicht die Fiji- basierten Karten vs Titan X/980Ti ansehen. Bemerkenswert ist eher die Stärke der Hawaiis gegenüber des GM200. Fiji ist nur 8-10% schneller als Hawaii bei deutlich mehr Shadern.
Da AMD mittlerweile einen angepassten Treiber für die Fijis veröffentlicht hat, der noch nicht gebencht wurde sollte sich Fiji vielleicht sogar die vollständige Leistungskrone holen, schliesslich sind es von Hawaii (2816 Shader) zu Fiji (4096 Shader) ca. 45% theoretische Mehrperformance, die obwohl sie natürlich nicht vollständig linear skalieren, wohl noch einen deutlichen Sprung geben wird.

 

[Ext3h]

Der Punkt kommt mir massiv komisch vor, da Schlangen ja zunächst sequentiell sind und die GPU für die Korrektheit des Programmes die Schlangen auch sequentiall abarbeiten muss. Deshalb könnte die GPU maximal pro Schlange nur ein aktives Grid berechnen. Diese Sequentialität liesse sich zwar nocheinmal durch Dependency-Bars in der Schlange vermeiden; alles zwischen zwei Dependency-Bars könnte parallel berechnet werden. Da moderne APIs Bindless sind, kann weder die GPU noch der Treiber diese Abhängigkeiten feststellen und automatisch Dependency-Bars einfügen. Deshalb wäre es die Aufgabe der Anwendung für das Einfügen der Dependency-Bars zu sorgen; aber weder in Mantle noch in DX12 gibt es afaik solche Dependency-Bars.

Dachte ich zuerst auch. Stimmt aber nicht.

Die Dependency-Bars gibt es in DX12 sehr wohl - sind sogar absolut notwendig und vorgeschrieben. Dafür gibt es ID3D12GraphicsCommandList::ResourceBarrier

Alles was nicht explizit durch Barrieren getrennt ist, darf vom Treiber und der Hardware umsortiert, nebenläufig ausgeführt, oder wie auch sonst immer verdreht werden. Dabei dürfen sowohl komplette CommandList-Blöcke vertauscht werden, als auch die Commands innerhalb einer Liste umgedreht.

Rein prinzipiell dürften Karten mit DX12 also sogar Drawcalls nebenläufig berechnen - und das tun sie z.T. sogar, insofern dass bereits die VS eines neuen Drawcalls zur Ausführung kommen während noch die FS des vorherigen laufen. Rein technisch würde aber AFAIK nichts dagegen sprechen sogar noch einen zweiten Graphics Command Processor mit auf die gleiche GPU zu setzen, um auch dort den Parallelismus noch mal weiter zu erhöhen.

Das geht sogar noch mal einen Schritt weiter:
Gelingt es dem Treiber tatsächlich Interferenz zwischen zwei Command Lists auszuschließen, obwohl eigentlich explizit angegeben, dann gelingt es zu mindestens AMD aktuell sogar die Dependency-Bars zu ignorieren.
Frag mich bloß nicht wie die das machen, ich habe absolut keine Ahnung. Ich weiß nur dass sie es tun, und dass es funktioniert.

 

[Andy1978]

Man darf sich auch nicht die Fiji- basierten Karten vs Titan X/980Ti ansehen. Bemerkenswert ist eher die Stärke der Hawaiis gegenüber des GM200. Fiji ist nur 8-10% schneller als Hawaii bei deutlich mehr Shadern.
Da AMD mittlerweile einen angepassten Treiber für die Fijis veröffentlicht hat, der noch nicht gebencht wurde sollte sich Fiji vielleicht sogar die vollständige Leistungskrone holen, schliesslich sind es von Hawaii (2816 Shader) zu Fiji (4096 Shader) ca. 45% theoretische Mehrperformance, die obwohl sie natürlich nicht vollständig linear skalieren, wohl noch einen deutlichen Sprung geben wird.

Ja hast ja recht aber das ich mir eine Asus 980ti Strix OC bestellt habe interessiert mich auch nur das .
Aber ja es ist schon erstauntlich was die alten Karten für eine Schub bekommen . Hat AMD Ja auch mal verdient .
Ich hoffe sogar das sie wieder eine Rosige Zukunft haben wäre echt Schade ohne AMD wäre die Gaming Welt nicht die
Selbe.

LG
Andy

 

[Nai]

@Ext3h
Ok interessant wusste ich so nicht.

Rein prinzipiell dürften Karten mit DX12 also sogar Drawcalls nebenläufig berechnen - und das tun sie z.T. sogar, insofern dass bereits die VS eines neuen Drawcalls zur Ausführung kommen während noch die FS des vorherigen laufen.

Das ging afaik schon vor DX12 so lange keine UAVs verwendet wurden, weil die ROPs die Zugriffe (auch von mehreren Drawcalls) auf den Framebuffer so reordern, als ob der Zeichenvorgang sequentiell Dreieck für Dreieck stattfinden würde. Dementsprechend sollte man in DX12 nicht einmal Resource Barriers für die "Korrektheit" des Framebuffers benötigen.

 

[Anteru]

Dachte ich zuerst auch. Stimmt aber nicht.

Die Dependency-Bars gibt es in DX12 sehr wohl - sind sogar absolut notwendig und vorgeschrieben. Dafür gibt es ID3D12GraphicsCommandList::ResourceBarrier

Alles was nicht explizit durch Barrieren getrennt ist, darf vom Treiber und der Hardware umsortiert, nebenläufig ausgeführt, oder wie auch sonst immer verdreht werden. Dabei dürfen sowohl komplette CommandList-Blöcke vertauscht werden, als auch die Commands innerhalb einer Liste umgedreht.

Barriers haben erst mal nichts mit "umsortieren" zu tun. Eine Barrier ist eine "Transition" - z.B. wenn ein Render-Target nun gelesen werden soll, braucht es eine Transition um sicherzustellen dass das Target fertig geschrieben wurde und nun "lesebereit" ist (Cache-Flush, etc.). Das hat erst mal nichts mit "umsortieren" verhindern zu tun.

Nehmen wir folgende Kette an Befehlen an: Setze RT0, Draw D0, Draw D1, Barrier RT0->Read, Setze RT1, Draw D2, Draw D3, Read RT0. Prinzipiell könnte eine GPU das auch so abarbeiten: Setze RT1, Draw D2, Draw D3, Setze RT0, Draw D0, Draw D1, Barrier, Read RT0. Von außen kann man das nicht beobachten, dass die Reihenfolge unterschiedlich ist.

Allerdings ist das mit dem umsortieren recht tricky (wann hilft es überhaupt etwas?) und viel Sinn macht das nicht, sprich man wird versuchen alles in der Reihenfolge wie vom Entwickler gedacht auf die GPU zu werfen und höchstens die GPU HW selber ein wenig scheduling machen lassen. Das sieht man z.B. an den "UAV-Overlap" extensions, da kann die GPU selbst entscheiden wie die Kernel abgearbeitet werden weil der Entwickler garantiert, dass hier Überlapp/Umsortierung ok ist. Oder eben auf GCN mit async compute, da entscheidet auch die GPU selber welcher Compute-Kernel gleichzeitig mit einem Draw-Call abgearbeitet wird auf welcher CU.

 

[Dai6oro]

Sieht so aus als würde der Fable Bench Async Compute kaum nutzen: http://wccftech.com/asynchronous-compute-investigated-in-fable-legends-dx12-benchmark/

Könnte also sein dass sich die Ergebnisse im fertigen Spiel also nochmal verschieben.

 

[o0Julia0o]

ist denn Async inzwischen nachgereicht, oder war das nur eine Marketingbehauptung?

 

[EXTREM]

Äh wenn du dich auf den polygonendurchsatz vom 3dmark dx12 drawcalltest beziehst, der ist höher. Eine 290x hat 16.000.000 drawcalls/Sekunde Jeder call hat laut Spezifikation 112-127 Polygonen. Wenn ich mit 112 rechne sind das gut 1.800.000.000, also 1,8 Milliarden Polygonen/Sekunde die die Fury da raus haut. Nvidi liegt trotz 2 rasterizer mehr und doppelter Performance der Rasterizer gut 10-20% hinter AMD.

Ich warte auch noch auf eine Antwort von Suddendeath zum 8k Test. Ich glaube nämlich das hier die Gtx970 hier noch Mals einbricht. Von 720p auf 4k waren es gut 15% drawcallverlust. Merkwürdig ist das es bei AMD zwischen 8k und 720p konstant bei 16.Millionen bleibt. Die Gtx 970 bricht hier von 20 Millionen Drawcalls unter 720p auf 16. Millionen Drawcalls unter 4k ein!

Habe meine R9 380 + I5 4460 mal getestet und die hat egal ob 720p oder 4K immer ~ 13 Millionen Drawcalls erst ab 8K fällt die Sie auf ~ 11 Millionen und bei 8k ist Mantel sogar schneller als DX12 warum auch immer.

 

[RayKrebs]

Tja, meistens wie immer, große Schlagzeilen, große Ankündigungen. Dann kommen neue Schlagzeilen, die Alte geraten in Vergessenheit.
Ich habe von NVIDIA bisher kein Statement dazu gehört. Zumindest bei Ashes of the Singularity hat sich die Performance mittlerweile wohl deutlich gebessert, ob es an Treiberoptimierungen oder am weiter entwickelten Spiel liegt. Wer weiß.

 

[Ext3h]

ist denn Async inzwischen nachgereicht, oder war das nur eine Marketingbehauptung?

Nein, zu mindestens nicht wenn man "Async" als "dynamisches Umschalten zwischen Command-Buffern je nach Auslastung" oder "parallele Abarbeitung von Command-Buffern" interpretiert. Das war und ist bei allen Nvidia-Generationen bis einschließlich Maxwell technisch von der Hardware her nicht möglich. Die Karten können Dispatch- und Render-Calls nicht effizient mischen, was eine Voraussetzung gewesen wäre, und Buffer können ganz allgemein nicht parallel zur Ausführung kommen.

Was Nvidia inzwischen AFAIK geschafft hat, ist die Logikfehler aus der Emulation raus zu bekommen, die damals bei AotS neben dem furchtbaren Leistungseinbruch oben drein noch für Darstellungsfehler und Abstürze gesorgt hatten. Damit funktioniert "async compute" nach der Definition von Microsoft zu mindestens schon mal fehlerfrei.

Es gibt Ausnahmefälle wo selbst das CPU-seitig emulierte Verhalten (sprich die CPU entscheidet in welcher Reihenfolge welcher Command-Buffer ausgeführt wird, anstatt dass die Karte selber auswählt bzw. zu mindestens Semaphoren überwacht) immer noch einen Performancezuwachs gibt weil damit ein noch größerer Stall auf der in der Renderpipeline vermieden werden kann, aber es lässt sich nicht nutzen um Leistungsreserven auf der GPU zu erschließen.

Effektiv ist es auf Nvidia-Karten langsamer als direkt per Hand alle Dispatch-Calls in Drawcalls um zu schreiben und dann mit einem handgestrickten Ausführungsplan über die 3D-Engine auszuführen. Vom Scheduling durch die GPU selber kann man dann natürlich nicht mehr profitieren, nur von einem rudimentären Pipelining.

Was die Ansteuerung angeht, muss man Nvidias Karten aus Entwicklersicht damit immer noch wie gehabt nach DX11-Manier mit einem möglichst lückenlosen Befehls-Strom fester Reihenfolge versorgen.

 

[Sontin]

Soll das mehr als Fanfiction sein?

Multi-Engine oder auch Asynchronous Compute nach Microsoft hat eine eindeutige Definition:
Das Verwenden von mindesten zwei Engines (Queues).

Und das funktioniert einwandfrei auf nVidia Hardware:
Copy + Graphics/Compute - Parallel
Graphics + Compute - Seriell mit Priorisierung der Graphics Queue

Oxide hat etwas programmiert, was überhaupt nicht im Sinne der Definition von Microsoft war:
Das Verwenden der Graphics-Queue und innerhalb dieser wurden Draw-Call und mehrere Dispatch-Befehle abgesetzt.

DX12 als Low-Level API erlaubt dies. Es ist die Aufgabe des Programmieres in diesem Fall sicherzustellen, dass solche eine Vorgehensweise überall funktioniert. Das hat man bei Oxide eben nicht getan und den schwarzen Peter nVidia zugeschoben.

Der Treiber entscheidet überhaupt nichts. In der Compute-Queue können mehrere Dispatch-Befehle sein, die von der Hardware verteilt wird.

Hält man sich an Microsofts Definition und Hinweise, funktioniert Asynchronous Compute einwandfrei.

 

[EXTREM]

Es funktioniert bei Nvidia aber eben wesentlich langsamer als bei AMD und das ist nun mal Fakt.

 

[Ext3h]

Oxide hat etwas programmiert, was überhaupt nicht im Sinne der Definition von Microsoft war:
Das Verwenden der Graphics-Queue und innerhalb dieser wurden Draw-Call und mehrere Dispatch-Befehle abgesetzt.

Stimmt so absolut nicht. Die Dispatch-Calls wurden über eine eigene Compute-Queue abgesetzt. Darüber hinaus ist das mixen von Draw- und Dispatch-Calls in der Graphics-Queue von Microsoft aus definitiv vorgesehen.

Genauso wie Parallelität zwischen 3D und Compute-Engine, auch wenn da die Spezifikation nur ein "shall" und kein "must" drinnen steht hat.

Die Performanceeinbrüche durch die Sequentialisierung und den Pipeline-/Cache-Flush zwischen Draw- und Dispatch-Call mal außen vor gelassen, war der Treiber von Nvidia bei einer ausreichend hohen Auslastung der CPU anfällig für Race-Conditions bei der Synchronisation zwischen Queues, AFAIK is bei Oxide bis heute nicht bekannt was genau die Speicherkorruption ausgelöst hat. Aufgetreten ist das, als man versucht hat einen Postprocessing-Shader von Proxygeometrie auf Dispatch-Call umzuschreiben und von der 3D-Queue in eine Compute-Queue verschoben hat. Danach war die Performance im Arsch und es sind Artefakte aufgetreten. Die Signale und Semaphoren waren fehlerfrei.

Auf jeden Fall hat Nvidia den Bug inzwischen behoben bekommen. Die Performance bei gemischter Arbeitslast ist immer noch mies.

 

[HisN]

Es funktioniert bei Nvidia aber eben wesentlich langsamer als bei AMD und das ist nun mal Fakt.

Und deshalb hab ich in der Nähe vom CPU-Limit 150 FPS?
Ist es da überhaupt relevant? Dein FAKT?
Bzw. wo wird der FAKT relevant? Für mich als Nixblicker^^

 

[EXTREM]

Ich spreche von Async Compute!