Nvidia und die Asynchronous Shader

Das ist mir hier schon fast zu dumm.

Ich habe nach der Performance bzw Verwendung der Asynchronous Shader bei nvidia gefragt bzw. ob es was neues seitens nvidias bzgl der Umsetzung gibt und du erzählst was "bei mir aber sind es 150fps (mit einer 1000€ GPU), was interessiert mich da AS?" :rolleyes:

Da darf angezweifelt werden das du den Eingangspost überhaupt gelesen hast. Da muss ich mit max_1234 konform gehen.
 
Meine Frage an Dich ist: Wo fehlen Dir bei 150FPS die "Performance" der Shader?

Nehmen wir mal an, es würden 20% durch die Art der Shader-Programmierung gewonnen werden können.
Dann hätten wir (an meinem Beispiel) im besten Fall 180 FPS (AS funktionieren nicht, es fehlen also 20% Leistung) und im schlechtesten Fall 120 FPS (AS funktionieren wie sie sollen, würde man sie abschalten verliert man die Performance).

Jetzt würde ich kleines Dummchen gerne von Dir wissen was das im Grunde genommen ausmacht, dass man darauf rumreiten muss. Denn es soll ja ein "Performance" Feature sein. Und ihr dreht es (hab ich jedenfalls das Gefühl) so hin, als würde Nvidia dabei grausam versagen.
Ich habe aber das Gefühl dass 150 FPS bei zigtausend Einheiten und unglaublich viel geballern ein durchaus respektabler Wert ist, wofür man NV nicht verdammen sollte. Das muss man erst mal nachmachen.
Ich meine ... man schaue sich z.b. COH2 an. Da brechen die FPS auf 30 zusammen wenn erst mal 8 Ki-Gegner Einheiten spammen.

Nur deshalb frage ich. Und ich würde mich sehr freuen wenn Du auch die Dummen bitte über den Hintergrund Deiner Frage aufklären würdest.
 
HisN schrieb:
Die Frage ist also: Was interessiert mich eine CPU-Entlastung, wenn meine CPU schon 150 FPS stemmen kann bei diesem Spiel?
Der Satz sagt eigentlich alles & nein, bisher gibt es keine neuen Infos. Mal schauen, wie es beim kommenden Fable aussehen wird ...:-)


edit:
*herzhaft lach* ...^^
 
Zuletzt bearbeitet:
Ich frag mich echt warum Du der einzige bis der mich versteht Sudden :-)
Aber vielleicht sind wir ja beide gleich Dumm (das soll jetzt keine Beleidigung sein^^).
 
Du möchtest also den Hintergrund wissen? Weil es mich interessiert.

Nvidia hat gesagt ihre Karten beherrschen AS in Hardware, nur die eigentliche Funktion sei im Treiber noch nicht hinterlegt. Es würden "demnächst" neue Treiber kommen.

Ich habe das Gefühl das du den Thread einfach nur schreddern willst.
Selbst wenn eine GTX950 2000fps bringen würde ist immer noch die Frage nach der Umsetzung von AS nicht geklärt. Worum es geht, und nicht darum das es eine CPU GPU Kombi gibt die 150fps liefert.
Daher habe ich dich auch bei den Mods gemeldet. Du versuchst offenbar hier Sand zu streuen, vom eigentlichen Thema abzulenken.
 
Gib alles :-)
Scheint bei Dir nur Schwarz und Weiß zu geben.
Sorry, wenn Du in einem öffentlichen Forum schreibst, musst Du damit klar kommen dass nicht alle Antworten so aussehen wie Du es gerne hättest.
Aber Du tutst auch NIX um eine Diskussion zu führen. Du erklärst alle die nicht sagen
Ja funktioniert
Nein funktioniert nicht
für blöd.
SUPER.
 
Zuletzt bearbeitet:
Conceptions schrieb:
Nvidia hat gesagt ihre Karten beherrschen AS in Hardware,

Nein, das hat Nvidia nicht gesagt.
Es macht auch keinen Sinn, so etwas zu sagen, weil AS lediglich eine Möglichkeit der Programmierung ist, die von der DX12 API geboten wird.
Und nein, die Nvidia GPUs haben keine Hardware, die aus der Programmierung durch AS Nutzen ziehen kann.
 
Deine Antworten sind am Thema vorbei. So einfach ist das.
Meine Frage lautet: Hat nvidia ihre Ankündigung bzgl der Asynchronous Shader umgesetzt oder wird dies noch umgesetzt.

Wenn dir das nicht passt dann schreib einfach gar nichts. Danke fürs Thread Schreddern.
 
@HisN
Ich hab mir die Auslastung nochmals näher angesehen & das ist doch recht ordentlich, entsprechende CPU + Takt natürlich vorausgesetzt & auch eine GPU, welche solch hohe Frames stemmen kann.^^
 

Anhänge

  • Auslastung bei ~150FPS.PNG
    Auslastung bei ~150FPS.PNG
    16,4 KB · Aufrufe: 167
Ich hab versucht ein vollständiges CPU-Limit für einen CPU-Bench zu erzeugen. Geht aber einfach nicht^^
 
Bitte zurück zum Thema, falls jemand etwas genaueres zur Ausgangsfrage des TEs weiß.
 
Bin ich der einzige, der noch in Erinnerung hat, dass Async-Shaders gar nicht die CPU entlasten, sondern eher die GPU auslasten sollen?

DX12 setzt stark auf einen Wechsel zwischen Compute und Graphics, den dann GPUs durch Async-Shader gleichzeitig abarbeiten können, damit Teile der GPU möglichst nicht ins Idlen kommen. Wie von Oxide verlautet wurde diese Funktion im nVidia-Treiber als funktionsfähig ausgewiesen, stellte sich aber als fehlerhaft heraus.

Daraufhin wurde extra für nVidia ein eigener Fallback-Renderpfad, der nicht auf Async-Shaders setzt entwickelt. nVidia hingegen hat Besserung und eine funktionsfähige Implementierung von Async-Shadern gelobt.
Weshalb man jetzt CPU-Benchmarks, die mEn gar nichts mit dem Thema GPU-Auslastung zu tun haben als "Beweise" in diesem Thread anführt erschließt sich mir nicht. Vor allem ist nach jetzigem Wissensstand kein Renderpfad, der Async-Shader auf nVidia-Karten nutzt öffentlich verfügbar.

Bisher wurde die Fragestellung des TE mMn eigentlich komplett missachtet und durch den Dreck gezogen.
 
BookerDeWitt schrieb:
Bin ich der einzige, der noch in Erinnerung hat, dass Async-Shaders gar nicht die CPU entlasten, sondern eher die GPU auslasten sollen?

Das habe ich mir auch die ganze Zeit gedacht. DX12 soll den Overhead von Drawcalls reduzieren und damit die CPU entlasten, ASync Shaders soll helfen, die GPU optimal(-er) zu belasten (AMD Video hier).
 
Well, can it really do Asynchronous Shading?
Yes. Both the GCN and Maxwell architectures are capable of Asynchronous Shading via their shader engines.
GCN uses 1 graphics engine and 8 shader engines with 8-deep command queues, for a total of 64 queues.
Maxwell uses 1 graphics engine and 1 shader engine with a 32-deep command queue, for a total of 32 queues (31 usable in graphics/compute mode)
Both GCN and Maxwell architectures claim to use context switching/priority at the shader engine to support Asynchronous Shader commands.

Prove it
Well, some guy on Beyond3d's forums made a small DX12 benchmark. He wrote some simple code to fill up the graphics and compute queues to judge if GPU architecture could execute them asynchronously.

He generates 128 command queues and 128 command lists to send to the cards, and then executes 1-128 simultaneous command queues sequentially. If running increasing amounts of command queues causes a linear increase in time, this indicates the card doesn't process multiple queues simultaneously (doesn't support Async Shaders).

He then released an updated version with 2 command queues and 128 command lists, many users submitted their results.

On the Maxwell architecture, up to 31 simultaneous command lists (the limit of Maxwell in graphics/compute workload) run at nearly the exact same speed - indicating Async Shader capability. Every 32 lists added would cause increasing render times, indicating the scheduler was being overloaded.

On the GCN architecture, 128 simultaneous command lists ran roughly the same, with very minor increased speeds past 64 command lists (GCN's limit) - indicating Async Shader capability. This shows the strength of AMD's ACE architecture and their scheduler.
Interestingly enough, the GTX 960 ended up having higher compute capability in this homebrew benchmark than both the R9 390x and the Fury X - but only when it was under 31 simultaneous command lists. The 980 TI had double the compute performance of either, yet only below 31 command lists. It performed roughly equal to the Fury X at up to 128 command lists.

Furthermore, the new beta of GameworksVR has real results showing nearly halved render times in SLI, even on the old GTX 680. 980's are reportedly lag-free now.

lower is better:
ac_980ti_vs_fury_x.png

Conclusion / TL;DR
Maxwell is capable of Async compute (and Async Shaders), and is actually faster when it can stay within its work order limit (1+31 queues). Though, it evens out with GCN parts toward 96-128 simultaneous command lists (3-4 work order loads). Additionally, it exposes how differently Async Shaders can perform on either architecture due to how they're compiled.
These preliminary benchmarks are NOT the end-all-be-all of GPU performance in DX12, and are interesting data points in an emerging DX12 landscape.

Quelle: www.reddit.com
 
Zuletzt bearbeitet:
Ein Super-konstruierter Spezielfall von ultra-kurzen Queues.
Wie Oxide Games bereits richtig argumentierte (und Nvidia es 1. dementierte 2. versucht hatte zu leugnen 3. Besserung versprach): Async Shader sind eine Katastrophe auf Nvidia GPUs.

mfg,
Max
 
@ gesperrter_User
Das Benchmark hat mehr oder weniger die Ausführungszeit bzw. die Latenz bei einem gegebenen Kernel mit einem Thread pro Schlange auf der GPU gemessen. Dies hat aber in der Praxis keine Bedeutung, da GPUs auf hohen Durchsatz bei der Ausführung 100 000den von Threads gleichzeitig und nicht auf Latenz bei der Ausführung von einem einzigen Thread hin optimiert sind.
 
HisN schrieb:
Es interessiert mich einfach bei 150 FPS nicht.
Das wäre bei 30 FPS relevant, da wo irgendwas zu holen ist.

Darauf will ich hinaus.
Die Diskussion ist müßig, weil es sich in Regionen abspielt wo es völlig egal ist ob AS nun "gut" oder "schlecht" funktionieren. Selbst wenn sie gar nicht funktionieren bin ich mit 150 FPS völlig zufrieden. Da brauch ich kein FASS aufmachen, das es mit funktionierenden AS eventuell 160 FPS wären.


Es ist im grunde egal was für ein System jemand hat,und auf er damit 150 FPS hat.Es geht darum,das wenn ein Hersteller fehlende Funktionen nachreichen will. Dann soll er das auch tun, und es nicht einfach sagen damit wir die Klappe halten.


Wenn man sich mit allem zufrieden gibt,dann darf man auch nichts erwarten.
 
Pascal67 schrieb:
Es geht darum,das wenn ein Hersteller fehlende Funktionen nachreichen will.

Die Funktion hat aber nie gefehlt. Jeder Treiber, der DX12-Unterstützung meldet, unterstützt auch dieses API-Feature.
 
Zurück
Oben