News DirectX 12: Nvidia-Treiber soll Async Compute nachreichen

[HisN]

Ist doch das Game, um das es geht.
Das einzige was es bis jetzt benutzt, was man auch testen kann. Deshalb frag ich.

 

[Ext3h]

Und deshalb hab ich in der Nähe vom CPU-Limit 150 FPS?

Ist nicht mehr nachvollziehbar bzw. reproduzierbar da AotS für Nvidia und AMD-Karten da unterschiedliche Renderpfade verwendet. Bei Nvidia kommt so weit ich weiß überhaupt keine separate Compute-Queue zum Einsatz und die Anzahl der Dispatch-Calls sind aufs absolute Minimum reduziert.

 

[EXTREM]

Ist doch das Game, um das es geht.

Es geht um Async Compute nicht um das Game, durch das Game ist das Problem bekannt geworden was aber nicht bedeutet das du deshalb wenig FPS hast.

 

[HisN]

Warum die Diskussion wenn ich nicht wenig FPS habe? *g*

 

[Sontin]

@Ext3h,
das hat Oxide nach meinem Wissen nirgendwo geschrieben. Und es ist widerspricht dem, was der Forumsteilnehmer im Beyond3d.com Forum mit seinem Tool aufgezeigt hat: Es gibt keine Probleme in der Compute-Queue.

Natürlich ist es möglich Draw-Calls und Dispatch-Befehle in der Graphics-Queue zu mischen. Diese umfasst alle anderen Queues. Es ist dann aber kein Multi-Engine Konzept mehr. Und damit ist es falsch von Asynchronous Compute zu sprechen, da dies im Kontext von Microsoft nicht benutzt wird: https://msdn.microsoft.com/de-de/library/windows/desktop/dn899217(v=vs.85).aspx

 

[Ext3h]

@Ext3h,
das hat Oxide nach meinem Wissen nirgendwo geschrieben. Und es ist widerspricht dem, was der Forumsteilnehmer im Beyond3d.com Forum mit seinem Tool aufgezeigt hat: Es gibt keine Probleme in der Compute-Queue.

Ob Oxide das schon öffentlich gemacht hat weiß ich nicht. Und nein, es widerspricht den Messergebnissen von Beyond3D nicht. Die Race-Conditions traten bei Oxide erst bei >= 3 synchronisierten Queues auf während gleichzeitig die CPU zu 100% ausgelastet war und somit auch der Treiber höhere Latenzen hatte als normal. Erst das hat die Bugs im Treiber ausgelöst, und den Oxide-Entwickler damals zu der Aussage verleitet, dass Nvidia es überhaupt nicht richtig unterstützen würde.

Allgemein scheint beim Nvidia-Treiber, zu mindestens Stand vor 6 Monaten, bei Semaphoren und Barrieren die CPU ziemlich stark involviert zu sein, insofern waren die Raceconditions im Nachhinein nicht ganz unerwartet. Interessanter Weise nicht bei CUDA, da funktioniert die Synchronisation zwischen Queues ohne Roundtrip zur CPU, aber bei DX12 ist der zuständige Befehlsprozessor auf der GPU scheinbar nicht darauf ausgelegt.

Nachdem das Multiengine-Konzept jetzt allerdings mit Rücksicht auf Nvidia eh kaum jemand ausreizt, ist das Thema so ziemlich tot, und lediglich noch einmal zur Revision vorgemerkt wenn mit Pascal eventuell auch was funktionsfähiges von Nvidia nachkommt.

 

[Nai]

Nachdem das Multiengine-Konzept jetzt allerdings mit Rücksicht auf Nvidia eh kaum jemand ausreizt, ist das Thema so ziemlich tot, und lediglich noch einmal zur Revision vorgemerkt wenn mit Pascal eventuell auch was funktionsfähiges von Nvidia nachkommt.

Ich denke mal es auch daran liegt, dass diese Art der Asynchronität bzw der Parallelität sehr schnell sehr hässlich zu programmieren wird.

 

[o0Julia0o]

Hört sich recht komplex an. Mal für den einfachen User. Wenn man vor dem Kauf einer Grafikkarte steht. Wird Nvida Probleme haben mit DX12-Performance, weil einige Spielehersteller bestimmt so programmieren, dass die AMD-Karten damit deutlich besser zurecht kommen werden - weil es z.B. einfacher ist so zu programmieren? Oder wird das keine große Rolle spielen, wie bislang zu DX11-Zeiten.

 

[RayKrebs]

Tja, jetzt wäre eine gute Glaskugel hilfreich und ich dachte mit DX12 sollte alles einfacher und weniger vom Treiber abhängig werden. Ist wohl doch nicht so. Dafür jetzt gibt es wohl im Game zwei Renderpfade, oder war das schon immer so?

 

[Zotac2012]

Hört sich recht komplex an. Mal für den einfachen User. Wenn man vor dem Kauf einer Grafikkarte steht. Wird Nvida Probleme haben mit DX12-Performance, weil einige Spielehersteller bestimmt so programmieren, dass die AMD-Karten damit deutlich besser zurecht kommen werden - weil es z.B. einfacher ist so zu programmieren?

Klar klingt logisch, das man den Grafikkarten Hersteller der deutlich weniger Grafikkarten verkauft bei der Programmierung von Spielen bevorzugt

Bis jetzt ist noch überhaupt nicht bewiesen, das die AMD Grafikkarten unter DX12 besser sind und mehr Leistung in Form von FPS bringen. Man sollte erstmal abwarten bis es genügend Spiele gibt mit DX12 und dann wird man sehen, wer die bessere Performance abliefert.

 

[o0Julia0o]

Und die Spiele kommen wann heraus? Kann man im März feststellen, wie es sich nun mit der DX12-Prolbematik bei Nvidea verhält? Es ist ja so, wenn Spiele gut auf AMD-Karten laufen, dann werden mehr AMD-Karten verkauft.

 

[Dai6oro]

Klar klingt logisch, das man den Grafikkarten Hersteller der deutlich weniger Grafikkarten verkauft bei der Programmierung von Spielen bevorzugt

Der aber fast 100% des Konsolenmarktes bedient. Man wird abwarten müssen ob Entwickler das auf Rücksicht zu Nvidia eventuell nicht nutzen oder eben versuchen alles aus den Konsolen herauszuholen inklusive Async Compute.

 

[Ext3h]

Ich denke mal es auch daran liegt, dass diese Art der Asynchronität bzw der Parallelität sehr schnell sehr hässlich zu programmieren wird.

Ansichtssache. Eigentlich unterscheidet sich das nicht von der klassischen MT-Programmierung mit Semaphoren, nur dass die Queues halt auf einem anderen Gerät ausgeführt werden. Das lässt sich auf dem Papier eigentlich immer recht schön fehlerfrei konzeptionieren.

Und genauso wie bei MT-Programmierung muss man es nicht zwingend verwenden, solange man nur eine GPU ansprechen möchte reicht "zur Not" auch nur die 3D-Queue. Dann halt mit den Nachteilen dass man um so sorgfältiger bei der Synchronisation mit dem Host und bei der Auslastung der GPU per Hand nach steuern muss.

Bis jetzt ist noch überhaupt nicht bewiesen, das die AMD Grafikkarten unter DX12 besser sind und mehr Leistung in Form von FPS bringen.

Das ist bereits ziemlich deutlich bewiesen. Zu mindestens wenn man AMD-Karten wahlweise mit DX11 und DX12 anspricht, dass ist zu mindestens der Treiber-Overhead mit DX12 messbar deutlich niedriger. Nutzt man die echte Parallelität zwischen den Queues aus, dann gibt es auch dafür mittlerweile verschiedene Praxisbeispiele in denen sich damit die Auslastung (und damit auch die abrufbare Leistung) der GPU mit sehr geringem Aufwand (<10 Arbeitsstunden) signifikant steigern lies.

Je schlechter der Spieletitel optimiert war, desto größer sind da die Leistungsreserven die auf die Weise abgegriffen werden können. Bei einem AAA-Titel der schon unter DX11 bis zum Erbrechen unter Einsatz tausender Mannstunden auf die aktuellen Architekturen angepasst wurde ist da natürlich nichts mehr zu gewinnen. Im Endeffekt ist nur ein einfacherer Weg zu optimieren, nicht der einzige,

 

[oldmanhunting]

Ich will jetzt nicht in ein Wespennest treten aber ist es nicht so, dass AMD unter DX11 einfach schlechter gelaufen ist als die GPU's von NVidia und AMD es mit DX12 endlich geschafft hat dieses Manko zu beheben?
Die ganze Wahrheit werden wir wohl erste Ende 2016 mit den Neuen GPU's und den Neuen Spielen unter DX12 wissen.

 

[Ext3h]

Ich will jetzt nicht in ein Wespennest treten aber ist es nicht so, dass AMD unter DX11 einfach schlechter gelaufen ist als die GPU's von NVidia und AMD es mit DX12 endlich geschafft hat dieses Manko zu beheben?

Das stimmt schon, die Schwerpunkte lagen einfach unterschiedlich.

Nvidias GPUs und Treiber sind einfach in jeder Hinsicht auf DX11 zugeschnitten, was sich sowohl bei einem geringeren Overhead bzw. höherem Durchsatz im Treiber mit DX11 äußert, als auch einer reduzierten Leistungsaufnahme. Dazu ein ordentliches Budget, um sicher zu stelle das AAA-Titel auch immer gut auf Nvidia-Karten optimiert sind, und das jetzt völlig unabhängig davon ob der Titel jetzt offiziell von AMD oder Nvidia gesponsort ist.

Während bei AMD seit der Einführung von GCN große Teile der Steuerlogik auf den GPUs einfach ungenutzt brach lagen, mangels API über die man diese hätte ansprechen können. Für AMD ist DX12 jetzt zu mindestens was das geänderte Treiber- und Queue-Modell angeht tatsächlich hardwarenah, sprich es entspricht der Architektur der GPUs und erlaubt es damit die verfügbaren Leistungsreserven mit deutlich weniger Aufwand ab zu rufen.

Für Nvidia weniger, nicht zuletzt weil die Karten schon mit DX11 etwas länger am theoretischen Limit operiert haben, aber auch weil die Karten in Hardware niemals auf parallele Ausführung mehrerer Queues oder das mischen von 3D und Compute-Anwendungen ausgelegt waren. Etwas ärgerlich ist jetzt, dass Nvidias Karten weiterhin ziemlich limitiert sind, in Hinsicht darauf was die Karten nun effizient beherrschen, und was nicht. Bzw. was an Aufwand rein gesteckt werden muss, um auch weiterhin ganz klassisch auf die alten Nvidia-Architekturen zu optimieren.

 

[Nai]

Während bei AMD seit der Einführung von GCN große Teile der Steuerlogik auf den GPUs einfach ungenutzt brach lagen, mangels API über die man diese hätte ansprechen können

Bist du dir da eigentlich sicher? Da DX11 ja eine auf binding basierende API ist, kann der Treiber ja prinzipiell eine Dependency Analysis über die DX11-Calls drüberlaufen lassen und dementsrechend auf die unterschiedlichen Schlangen verteilen. Mich persönlich würde es überraschen, wenn AMD das nicht bereits gemacht hätte. Denn zumindest für das Swapping des GPU DRAMs wird eine solche Dependency Analysis ja sowieso bereits benötigt.

 

[Ext3h]

Ja, das dürfte höchstens per Anwendungsprofil erfolgen, und sich dann auch nur auf die Copy- und 3D-Queue beschränken. Mir ist spontan kein Fall bekannt wo DX11-Anwendungen extensiv Gebrauch von Compute-Shadern machen würden, und dann auch noch in so einem Rahmen dass es sich gelohnt hätte die vom GCP auf eine ACE aus zu lagern. Wobei man dazu sagen muss, dass bei AMD-Karten der GCP auch ziemlich gut mit Dispatch-Calls umgehen kann, sprich Compute-Shader in der 3D-Queue tun nicht direkt weh.

Und die 3D-Queue bekommst du auch nicht sinnvoll bzw. wirkungsvoll zerlegt, schlichtweg aus dem Grund dass da auch nur ein einzelner GCP zur Abarbeitung zur Verfügung steht und dementsprechend auch keine dynamische Out-Of-Order oder parallele Ausführung, sondern höchstens Umsortieren auf Blockebene, wofür es die Hardware auch wieder nicht braucht.

Wenn das erst mal in eine monolithische Pipeline gebacken wurde, kannst du im besten Fall noch per Profil Preloading betreiben, aber sonst ist da nicht mehr viel. Asynchron, bzw. besser gesagt auf eine partielle Ordnung reduziert, bekommst du das nicht mehr, nicht ohne die Anwendung halb um zu schreiben die ja gerade erst mühsam die ganzen Drawcalls explizit über eine nur rein sequentiell ansprechbare API übermittelt, und dabei auch alle in der Codebasis noch verwendeten Semaphoren längst eliminiert hat. Zumal die Anwendung ja auch wieder darauf wartet dass Semaphoren vom Treiber freigegeben werden bevor weitere Calls abgesetzt werden, womit die Ordnung fest vorgegeben ist.

 

[EXTREM]

Klar klingt logisch, das man den Grafikkarten Hersteller der deutlich weniger Grafikkarten verkauft bei der Programmierung von Spielen bevorzugt

Bis jetzt ist noch überhaupt nicht bewiesen, das die AMD Grafikkarten unter DX12 besser sind und mehr Leistung in Form von FPS bringen. Man sollte erstmal abwarten bis es genügend Spiele gibt mit DX12 und dann wird man sehen, wer die bessere Performance abliefert.

Dir ist aber schon klar das die mit Abstand meisten Spielen für Konsolen verkauft werden und sowohl die XBox One als auch die PS4 nutzen nun mal GCN GPUs von AMD.

 

[Sontin]

Ob Oxide das schon öffentlich gemacht hat weiß ich nicht. Und nein, es widerspricht den Messergebnissen von Beyond3D nicht. Die Race-Conditions traten bei Oxide erst bei >= 3 synchronisierten Queues auf während gleichzeitig die CPU zu 100% ausgelastet war und somit auch der Treiber höhere Latenzen hatte als normal. Erst das hat die Bugs im Treiber ausgelöst, und den Oxide-Entwickler damals zu der Aussage verleitet, dass Nvidia es überhaupt nicht richtig unterstützen würde.

Klingt wie ausgedacht und Buzzword-Bingo. Mehrere Queues sind kein Problem, da diese von der Hardware nacheinander abgearbeitet werden. Sie werden so in die Hardwarequeue der GPU eingestellt.

Allgemein scheint beim Nvidia-Treiber, zu mindestens Stand vor 6 Monaten, bei Semaphoren und Barrieren die CPU ziemlich stark involviert zu sein, insofern waren die Raceconditions im Nachhinein nicht ganz unerwartet. Interessanter Weise nicht bei CUDA, da funktioniert die Synchronisation zwischen Queues ohne Roundtrip zur CPU, aber bei DX12 ist der zuständige Befehlsprozessor auf der GPU scheinbar nicht darauf ausgelegt.

Na, nonsense. Es gibt kein Roundtrip zur CPU. Macht null Sinn. Die Anwendung weiß, wann was abgearbeitet sein muss. Da muss keine Logik dazwischenfunken. Das ist der Sinn von "Low-Level". Der Treiber macht nichts anderes als durch die Fences die Befehlsreihenfolge einzuhalten.

Nachdem das Multiengine-Konzept jetzt allerdings mit Rücksicht auf Nvidia eh kaum jemand ausreizt, ist das Thema so ziemlich tot, und lediglich noch einmal zur Revision vorgemerkt wenn mit Pascal eventuell auch was funktionsfähiges von Nvidia nachkommt.

Das Multiengine-Konzept ist ein logisches Konzept. Hat nichts mit der Hardwareunterstützung zu tun. Des Weiteren muss jede DX12 Karte auch die drei Engines - Copy, Compute, Graphics - unterstützen.

 

[Ext3h]

Mehrere Queues sind kein Problem, da diese von der Hardware nacheinander abgearbeitet werden. Sie werden so in die Hardwarequeue der GPU eingestellt.

Wenn du Compute- und 3D-Queues mischt, dann ist das für die Nvidia-GPUs zwischen Fermi und Maxwell ein Problem, schlichtweg weil Dispatch-Calls vom GCP in der Normalkonfiguration nicht effizient bearbeitet werden kann. Der kann Dispatch-Calls nur sequentiell (ohne Pipelining) ausführen.
Was die da genau beim Wechsel zwischen den "Engines" anstellen habe ich nicht raus finden können (wahrscheinlich wird der GCP neu initialisiert), aber auf jeden Fall ist der Wechsel zur Compute-Queue noch mal teurer als ein einzelner Dispatch-Call in der 3D-Queue, und das obwohl selbst das bereits einen Flush aller SMM-Einheiten bewirkt, davor und danach, zwecks Rekonfiguration des L1-Cache der bei den Architekturen allesamt auch als LDS für Compute-Shader herhalten muss.

Mal davon abgesehen dass selbst Speicherzugriffsbarrieren (die Teile zwischen Drawcalls, innerhalb eines Buffers, nicht die innerhalb eines Shaders und auch nicht die Signale die sowieso von der Anwendung überwacht werden könnnen) bei Nvidia ebenfalls über den Treiber gehen, der normale GCP kennt keine Monitore in Hardware, nur Signale an den Host.

Roundtrip zur CPU heißt nicht dass es in die Anwendungsschicht geht, wenn der Treiber Mist baut reicht das völlig aus.
Und wenn man dann für die Kommunikation zwischen GPU und Treiber sowie DMA fixe Latenzen angenommen hat die durch die Systemlast nicht mehr haltbar sind, sich aber im Treiber und in der Firmware die Semaphoren gespart hat unter der falschen Annahme dass bestimmte Operationen immer die Deadline erfüllen, dann geht das halt einfach schief.

Ja, die Copy-Engine ist tatsächlich eigenständig und funktioniert wie erwartet. Aber was Trennung von 3D- und Compute-Engine, den nebenläufigen Betrieb, sowie asynchrone Signale oder den Support für Monitore direkt auf der GPU zwecks Vermeidung der CPU-Roundtrips angeht da hat Nvidia bei der Hardware Mist gebaut. Umschalten zwischen den Queues nur an Buffer-Grenzen, so wie Nvidia das macht, war eigentlich auch nicht vorgesehen.

Und jetzt komm mir nicht damit dass es bei CUDA ja funktionieren würde. Ja, tut es. Aber da sitzt auch ein eigener Kontrollprozessor für auf der GPU, der dort fürs Scheduling zuständig ist (die GMU). Aber aus unbekannten Gründen nicht als Compute-Engine eingesetzt wird (obwohl scheinbar ursprünglich so geplant), was die Compute-Queues mit einem ziemlichen Overhead abstraft, verglichen zur Integration von CUDA in eine 3D-Anwendung.

Nur zu, schau dir das ruhig mal mit GPUView an bei einer Nvidia-GPU. Da siehst du so einige zusätzliche Signale die eigentlich rein intern auf der GPU bleiben sollten, die GMU als dezidierte Compute-Engine während per DX12 aber alles auf den als 3D-Engine sichtbaren GPC geht, und deutlich sichtbaren Overhead immer wenn die GPU den Modus wechseln muss.

Was meinst du denn warum Nvidia in ihrem "Do & Don't Do"-Dokument zu DX12 im Endeffekt gesagt hat "verlasst euch nicht auf das Timing bei Signalen", "Compute-Shader nur unter Aufsicht eines Nvidia-Entwicklers verwenden" und "bitte verwendet nicht zu viele Barrieren und Signale"?
Davon ist bei Nvidia nichts wirklich "hardwarenah", was wohl am ehesten die Übersetzung für "lowlevel" wäre.

Jetzt aber echt genug von dem Thema. Warten ob Pascal das besser macht, falls nicht, dann bleiben Compute-Engine bzw. auch allgemein der Einsatz von Dispatch-Calls unter DX12 halt weiterhin weitgehend für den AMD-Renderpfad reserviert.