Oxide: NVIDIA-GPUs unterstützen Asynchronous Compute/Shaders unter DX12 nicht

[fdsonne]

Nvidia versucht dies jetzt über den Treiber zu erschlagen, sprich einen Scheduler einzubauen, der die Last auf der GPU steuern soll.

Bis hier hin stimme ich dir durchaus zu, allerdings stellen sich mir hier weitgehend andere Fragen als die vielfach angesprochene, NV hat mal wieder die Kunden verarscht, Propaganda...

Mal ein paar Sachen zum Anregen:
- wer sagt, dass eine GPU immer und in jeder Lebenslage auch so viel Luft auf ihren Einheiten hat, dass es sich überhaupt auszahlt, asyncron Berechnungen auszuführen? -> nimm dein Beispiel von oben, wenn du 10ms für die Berechnung brauchst um den Grafikpart abzudecken und dies die ALUs an ihre Grenzen bringt, wie sollen die selben ALUs dann zur selben Zeit nochmal geschätzt knapp 50% der Last abfangen können? -> was ist, wenn du bei gleichzeitiger Berechnung von Compute und Grafik für letzteres sagen wir 15ms brauchst (was 50% drauf wären) und dann inkl. Compute in Summe auf 15-17ms kommst?
- wer sagt, dass AMD und NV GPUs mit ihren doch schon teils ziemlich unterschiedlichen Implementationen (gerade im Frontend und dem Threadscheduler) hier direkt vergleichbar sind? Sprich, wenn AMD auf ihrer Hardware Leistungssteigerungen im mittleren zweistelligen Prozentbereich bestätigt, wer sagt, dass dies auch analog auf NV anzuwenden ist?
- unter welchen Voraussetzungen sind diese Werte überhaupt ermittelt wurden? Wie realitätsnah sind diese "Messungen" mit praxisrelevanten Workloads vergleichbar?
- wo stehen Fakten zu den Parallelen zwischen den Messungen auf Konsolen (AMD APUs mit "lahmen", dafür breitem CPU Part) und den endgültigen Konsolenports auf dem PC?
- wo sind in der Betrachtung die möglicherweise (bei verschiedenen Klassen allerdings definitiv vorhandenen) Leistungsunterschiede zwischen den Modellen? Sprich wer sagt, dass überhaupt jede GPU Leistungsklasse davon profitieren kann? Tonga mit dem "vierfach" Frontend und unter 2000 ALUs vs. Fiji mit nem quasi relativ gleichen Frontend bei mehr als 4000 ALUs sind schon ziemlich eklatante Unterschiede, um mal ein Beispiel zu nennen.
- wo steht festgeschrieben, dass eine Softwareemulation zwingend langsamer sein muss, als eine Abarbeitung in Hardware? Vor allem, wenn nichts, aber auch gar nichts über die direkte Leistungsfähigkeit der Hardware, wie auch der Softwarelösung bekannt ist?


Ich weis nicht, aber irgendwie zieht man hier (und auch in vielen anderen Foren) Rückschlüsse über ziemlich unsichere Sachlagen. Von NV gibt es nahezu gar keine Infos zu dem Thema, sprich was läuft wie und wo genau. Bei AMD gibt es deutlich mehr zu dem Thema. Aber eben klar auf AMD Hardware bezogen... Dass das für ihre Hardware passt, dürfte wohl ziemlich außer Frage stehen. Nur wie passt das mit Maxwell und möglicherweise Kepler unter einen Hut?

Was ich aber definitiv weis, diese Kritik an der Argumentationweise hier wird mir ziemlich sicher wieder als pro NV ausgelegt werden... Mal schauen wer auf die genannten Punkte stichhaltige Fakten bringen kann. -> denn ohne das ist die ganze Diskussion hier reichlich für den Hintern. Da wir einfach so gut wie gar nix über den Background kennen...

PS: hier mal ein paar Vergleiche zwischen AMD und NV:
Ashes of the Singularity Bench - Overclockers UK Forums
Sieht definitiv nicht so schwarz aus, wie man es hier macht... Oder ich hab irgendwie was auf den Augen
Wenn jetzt NV den DX12 Part noch Minimum auf das DX11 Leistungsniveau bringt, dann reicht es imho für diesen Titel wohl aus um weiterhin NV ganz oben stehen zu sehen. Wie viel man davon auf andere Titel übertragen kann, siehe oben, steht völlig in den Sternen...

........... Viel wichtiger: lernt den gamedevs mal coding .... effizienzes coding ... nicht 0815 geht schon irgendwie emulating

Hier sehe ich eine noch extrem ungewisse Schattenseite von DX12... Der Entwickler hat hier eine gewisse Verantwortung. Ob er dieser nachkommen wird und auch vor allem über mehrere Monate nach Spielerelease überhaupt nachkommen kann/will, steht ebenso noch lange nicht in Stein gemeißelt.
Man stelle sich nur einfach mal vor, mit der nächsten oder übernächsten Generation ändert sich irgendwas ziemlich gravierend an der Hardware im Vergleich zu den Konsolen. Was wird wohl passieren? Wird der Entwickler darauf reagieren? Wird er sich dem stellen?
Mal ganz platt angenommen. Man treibt das Thema hier auf die Spitze und baut stark darauf. Sprich NV und AMD würden GPUs bringen, die die ASync Compute Fähigkeiten der APUs stark übersteigen und schlimmer noch, die es notwendig machen (für optimale Leistung), dass man sich von Entwicklerseite dahingehend anpasst? Meinst du das wird man tun? -> ich sehe da noch sehr sehr viele Probleme. Die Abstraktion von DX11 von der Hardware hat nicht nur Nachteile... Vor allem unter solchen generationsübergreifenden Gesichtspunkten

 

[Pickebuh]

Wir wollen einfach nur hoffen, das die Spieleentwickler mal wieder nicht extra auf NVIDIA Rücksicht nehmen müssen (siehe die Geschichte mit DX10.1 und DX11.2) und dadurch das volle Potenzial von DX12 hinter dem Berg halten bis NVIDIA endlich einmal dazu in der Lage ist es auch zu nutzen.

 

[fdsonne]

Naja, das ist aber auch nur die halbe Wahrheit... Die Spieleentwickler haben eine erhöhte Verantwortung im Vergleich zu DX11. Das gilt also auch von der Entwicklerseite abzudecken. Bei zwei, ja eigentlich sogar drei, wenn man Intel mit ins Boot holt, Herstellern, welche aktiv im DX11/12 Bereich mitspielen wollen, muss also entsprechend auch "optimiert" werden... Das beinhaltet sowohl deine angesprochene Rücksichtnahme als auch eine Nutzung von speziellen Herstellereigenschaften.

Eine Lösung wie es in DX11 bis dato offenbar mehr oder weniger gut lief, sprich der GPU Hersteller wird's schon richten, kann man sich damit nicht mehr direkt verlassen... Ob das aufgeht oder für sehr böses Erwachen sorgt, wird sich noch rausstellen müssen.
Bis dato hat AMD aber klar einen Vorteil. Ob das mit der nächsten/übernächsten Generation noch so sein wird? Abwarten... Man wird auch bei AMD nicht ewig 1:1 GCN wie auf den Konsolen APUs bauen (können) -> nur was wird dann mit der Argumentation? Dann muss man schon vier Anlaufstellen berücksichtigen. (alt AMD Konsole, NV, neu AMD Desktop und Intel). zzgl. dann noch den DX9/10/11 Fallback für alt Hardware...
Ich stelle mir das gerade bei Titel wie einem jährlichen Abklatsch von CoD oder so was vor, wie "gut" das aufgehen wird...

 

[unl34shed]

Bis hier hin stimme ich dir durchaus zu, allerdings stellen sich mir hier weitgehend andere Fragen als die vielfach angesprochene, NV hat mal wieder die Kunden verarscht, Propaganda...

na wenigstens etwas
Eigentlich wollte ich mit meinem Post Cibo nur erklären, dass es nicht um 32 vs 64 queues geht

- wer sagt, dass eine GPU immer und in jeder Lebenslage auch so viel Luft auf ihren Einheiten hat, dass es sich überhaupt auszahlt, asyncron Berechnungen auszuführen? -> nimm dein Beispiel von oben, wenn du 10ms für die Berechnung brauchst um den Grafikpart abzudecken und dies die ALUs an ihre Grenzen bringt, wie sollen die selben ALUs dann zur selben Zeit nochmal geschätzt knapp 50% der Last abfangen können? -> was ist, wenn du bei gleichzeitiger Berechnung von Compute und Grafik für letzteres sagen wir 15ms brauchst (was 50% drauf wären) und dann inkl. Compute in Summe auf 15-17ms kommst?

Das ist die Auslastung aus The Tomorrow Children auf der PS4, da könnten schon 50% Luft sein würde ich meinen.
http://cdn3.dualshockers.com/wp-content/uploads/2014/09/TomorrowChildren33.jpg

Aber ja, das sagt niemand und hab ich auch nicht! Durch die Spanne von 10-12ms ist eine Leerlauf von 30-50% abgedeckt.
Klar bei weniger Berechnungen auf der Grafikkarte spielt es weniger rein, ist logisch bzw. einfache Mathematik. Die Zahlen waren einfach nur aus der Luft gegriffen und sollte man eigentlich an den doch glatten Zahlen und dem Wörtchen Beispiel erkennen. Ich habs mir sogar kurz überlegt dazu zu schreiben weil irgendeiner es wohl nicht raffen wird hinterher ist man immer schlauer.

Das eine GPU aber zu durch den Grafik-Shader die ganze Zeit zu 100% ausgelastet ist und async Shader nicht bringt bezweifel ich auf jeden fall. Zum einen werden verschiedene Filter über das Bild gejagt und die erzeugen allein schon unterschiedliche Lasten, dann noch Wartezeiten bei Speicherzugriffen usw.

- wer sagt, dass AMD und NV GPUs mit ihren doch schon teils ziemlich unterschiedlichen Implementationen (gerade im Frontend und dem Threadscheduler) hier direkt vergleichbar sind? Sprich, wenn AMD auf ihrer Hardware Leistungssteigerungen im mittleren zweistelligen Prozentbereich bestätigt, wer sagt, dass dies auch analog auf NV anzuwenden ist?

Wenn Nvidia Async Shader nicht unterstützt, müssten sie Compute- und Grafik-Shader nach einander berechnen. Und die zeiten addieren sich entsprechend auf. Wie oben beschrieben wird eine GPU nie zu 100% ausgelastet sein, also wird es auch bei Nvidia etwas bringen.

- unter welchen Voraussetzungen sind diese Werte überhaupt ermittelt wurden? Wie realitätsnah sind diese "Messungen" mit praxisrelevanten Workloads vergleichbar?

keine Ahnung, sind wie gesagt nur erfundene Zahlen.
Mit Async Compute dürften sich aber in Zukunft einige Dinge auf der GPU berechnen lassen, an die heute / unter DX11 nicht zu denken wäre, da durch den Context switch die Rechenzeit zu lang ist.

Physik, Haare (Hairworks/TressFX), KI, pathfinding, ...

- wo stehen Fakten zu den Parallelen zwischen den Messungen auf Konsolen (AMD APUs mit "lahmen", dafür breitem CPU Part) und den endgültigen Konsolenports auf dem PC?

Das es noch keine DX12 Konsolen Ports gibt, kann man da auch keine Parallelen ziehen.
Hardware seitig skalierst du am PC aber idr. sowohl die CPU als auch GPU, durfte sich also ausgleichen.

- wo sind in der Betrachtung die möglicherweise (bei verschiedenen Klassen allerdings definitiv vorhandenen) Leistungsunterschiede zwischen den Modellen? Sprich wer sagt, dass überhaupt jede GPU Leistungsklasse davon profitieren kann? Tonga mit dem "vierfach" Frontend und unter 2000 ALUs vs. Fiji mit nem quasi relativ gleichen Frontend bei mehr als 4000 ALUs sind schon ziemlich eklatante Unterschiede, um mal ein Beispiel zu nennen.

Ist für die Betrachtung des ganzen erstmal vollkommen irrelevant.

- wo steht festgeschrieben, dass eine Softwareemulation zwingend langsamer sein muss, als eine Abarbeitung in Hardware? Vor allem, wenn nichts, aber auch gar nichts über die direkte Leistungsfähigkeit der Hardware, wie auch der Softwarelösung bekannt ist?

Zwingend langsamer muss sie nicht sein, aber bitte nen mir mal Gründe, die dafür sprechen, dass es schneller wird?
- Es muss jedes mal vom Scheduler über den PCIe Bus gepollt werden, ob nur eine Queue frei ist oder nicht.
- erst dann kann er arbeiten

- Bei AMDs Lösung kann man die Daten an die GPU schicken und bekommt direkt das "geht" oder "geht nicht" zurück. -> so habe ich es zumindest verstanden

Ein weiterer Punkt ist die Vorhersehbarkeit einer Hardwarelösung. Die Hardware löst Ihre Aufgabe in der Regel immer in einer definierten Zeit, während bei einer Softwarelösung gerade auf einem OS nicht mal genau gesagt werden kann wann der Task aufgerufen wird.

Ich weis nicht, aber irgendwie zieht man hier (und auch in vielen anderen Foren) Rückschlüsse über ziemlich unsichere Sachlagen. Von NV gibt es nahezu gar keine Infos zu dem Thema, sprich was läuft wie und wo genau. Bei AMD gibt es deutlich mehr zu dem Thema. Aber eben klar auf AMD Hardware bezogen... Dass das für ihre Hardware passt, dürfte wohl ziemlich außer Frage stehen. Nur wie passt das mit Maxwell und möglicherweise Kepler unter einen Hut?

Das ist ja eigentlich das verwunderliche, dass von Nvidia gar nichts kommt. Könnte Maxwell Async Shader hätten sie ja direkt das Dementi gebracht.
Auch die Tatsache, dass man direkt einen Scheduler auf der CPU geschrieben hat zeigt dass es die Hardware nicht kann.

PS: Sorry fürs zerpflücken des Posts.

 

[[HOT]]

Wir wollen einfach nur hoffen, das die Spieleentwickler mal wieder nicht extra auf NVIDIA Rücksicht nehmen müssen (siehe die Geschichte mit DX10.1 und DX11.2) und dadurch das volle Potenzial von DX12 hinter dem Berg halten bis NVIDIA endlich einmal dazu in der Lage ist es auch zu nutzen.

Tun sie nicht. Sie coden das entsprechende Featurelevel und NV muss dafür sorgen, dass es läuft.

 

[Schaffe89]

Async Compute ist Teil der Directx12 API und wird eben genau aufgrund dessen genutzt werden.
AMD stellt alle Konsolen. Nintendo ( bald ), PS4 und XboX.
Zudem wird AMD wohl auch mit Nachdruck versuchen, dass das überall genutzt wird.

PCGH hat es offenbar in ihrem Benchmark leider deaktiviert.

 

[pumuckel]

Wir wollen einfach nur hoffen, das die Spieleentwickler mal wieder nicht extra auf NVIDIA Rücksicht nehmen müssen (siehe die Geschichte mit DX10.1 und DX11.2) und dadurch das volle Potenzial von DX12 hinter dem Berg halten bis NVIDIA endlich einmal dazu in der Lage ist es auch zu nutzen.

die "entwickler" nutzen schon lange kaum PC Envs ... es geht da eher um Port Schnitstellen zu X1/Ps4/PC ... (PC Markt ist viel zu klein)
teils sogar jetzt ports auf Qualcom/MT im SOC mArkt

one dev and port to ...

und da kommt amd mit PS4 und x1 ins spiel


PC Gaming Masterrace .... yes but not .... pc gaming not much reward

Konsolentitel und deren "genuine drm" ist für Entwickler attraktiver (PC games gehen teils in aaa zu 15-20€ per global weg, Konsolen Titel 45-60€) .. die Grau/Raubkopien mal weggelassen
darum gibt es ja auch Konsolen ... die wurden für native DRM seit den ersten Atari Modulen gebaut (aka z.B. Frogger)

Indi Games sind auch nur "heatpoints" = wollen fix geld und danach kommt nix mehr


vergleich: das ESo kostete mich preorder aus Brasilien 45€ in der Eu waren es 79,90 (gleiches Game, aber mal schnell fast 40% weniger)

 

[fdsonne]

@unl34shed
Meine zugegeben teils etwas provokant formulierten Fragen sollten nicht ausschließlich auf deinen Beitrag abzielen. Sondern eher war dein Beitrag nur der allgemeine Aufhänger um mal ein paar blöde Frage in den Raum zu stellen.

Deine Zahlen waren natürlich aus der Luft gegriffen im Vergleich, das ist mir durchaus bewusst, weswegen meine "Gegenzahlen" ja ebenso aus der Luft waren
Was mich allerdings halt in den Foren, ja sogar in den News zu diesem Thema sehr verwundert, dass die "Meute" so eine Welle um einen so unklaren Fakt aufzieht. Gerade das Thema mit der Auslastung ist doch etwas, was so gar nicht überblickbar ohne konkrete Zahlen ist...
Was wir mittlerweile wissen, je nach Spiel und je nach Setting/Auflösung ist der Stromverbrauch der GPU teils drastisch verschieden -> das lässt klar auf andere Auslastungen schließen.
Auch wird das Feature ansich definitiv eine Bereicherung werden. Was mich dabei allerdings stört ist eben das einseitige Ranziehen der AMD Folien und dessen "Fakten" sowie das gleichzeitige umdrehen und ruminterprätieren auf die NV Seite. Kann aufgehen, muss aber nicht.
Der Part mit den FPS Messungen dieses Alpha Spielebenches zeigen mir klar, dass hier trotz offenbaren Schwäche bei NV das Endergebnis nicht so schlecht ist, wie man es hier teils in den Beiträgen macht. Es gibt leider nur wenige kritische Stimmen mit der notwendigen Weitsichtigkeit auf so ein Thema. (zumindest im deutschsprachigen Raum)

Bspw. scheint mir der Bench bei den AMD Ergebnissen eher stark vom CPU Overheadvorteil von DX12 zu profitieren. Was die AMD Modelle deutlich nach vorn bringt (maue DX11 Umsetzung). Der Sprung bei NV ist klar gering(er) oder sogar negativ. Offensichtlich aber auch noch mit Problemen behaftet. Dennoch reicht's am Ende für ne NV an der Spitze... Wie passt das zusammen?
Laut den Entwicklern des Benches hat man nicht konkret auf ASync hin entwickelt... Das kann nun pro NV oder pro AMD ausgegangen sein, auch hier kennen wir keine stichhaltigen Zahlen

Mal konkret zur Diskussion:
"Das eine GPU aber zu durch den Grafik-Shader die ganze Zeit zu 100% ausgelastet ist und async Shader nicht bringt bezweifel ich auf jeden fall. Zum einen werden verschiedene Filter über das Bild gejagt und die erzeugen allein schon unterschiedliche Lasten, dann noch Wartezeiten bei Speicherzugriffen usw."
-> für mich ist hier die Frage, wie das im Vergleich AMD vs. NV ausschaut. Da ja zu der Arbeitsweise der GPUs intern nur wenig bekannt ist, müsste man schon ziemlich stark spekulieren... Die wie oben angesprochen, teils drastischen Unterschiede im Verbrauch bestätigen, dass die Load stark schwankt. Soweit so klar... Nur lässt sich das mit Async Computer nun dediziert abfedern? Und was macht das dann bspw. aus der Effizienz in Sachen FPS/Watt oder im absoluten Verbrauch?
Auch müssen natürlich klar auch Compute Aufgaben anstehen damit das überhaupt aufgeht...

"Wenn Nvidia Async Shader nicht unterstützt, müssten sie Compute- und Grafik-Shader nach einander berechnen. Und die zeiten addieren sich entsprechend auf. Wie oben beschrieben wird eine GPU nie zu 100% ausgelastet sein, also wird es auch bei Nvidia etwas bringen."
-> das Thema ist halt so ne Sache... Sequenziell bearbeitet muss ja nicht automatisch langsamer sein als gleichzeitig... Es kommt auf die Gesamtzeit hintenraus an.
Dieser kleine Minibench da von dem einen Typen zeigt zwar, dass es bei NV sequenziell zu laufen scheint, dafür sind die Zeiten faktisch aber auch krass niedrig im Vergleich.

"Physik, Haare (Hairworks/TressFX), KI, pathfinding, ..."
-> die klassische Grundsatzfrage... Hat man dafür Luft, speziell im Mittelfeld der Grafikkarten und Blockbustertiteln? Ich persönlich bin nicht primär Freund davon muss ich sagen

"Das es noch keine DX12 Konsolen Ports gibt, kann man da auch keine Parallelen ziehen.
Hardware seitig skalierst du am PC aber idr. sowohl die CPU als auch GPU, durfte sich also ausgleichen."
-> meine Rede... Nur warum wird dann immer mit den Konsolen argumentiert?

"Ist für die Betrachtung des ganzen erstmal vollkommen irrelevant."
-> naja, nicht direkt, das stimmt wohl. Aber da die GPU Ausführungen stark unterschiedlich sind, stellt sich halt die Frage, wie man einen "guten" Mittelweg findet um alle Modelle (oder wenigstens alle vom gleichen Hersteller) da anständig unter einen Hut zu bringen...

"Zwingend langsamer muss sie nicht sein, aber bitte nen mir mal Gründe, die dafür sprechen, dass es schneller wird?
- Es muss jedes mal vom Scheduler über den PCIe Bus gepollt werden, ob nur eine Queue frei ist oder nicht.
- erst dann kann er arbeiten

- Bei AMDs Lösung kann man die Daten an die GPU schicken und bekommt direkt das "geht" oder "geht nicht" zurück. -> so habe ich es zumindest verstanden

Ein weiterer Punkt ist die Vorhersehbarkeit einer Hardwarelösung. Die Hardware löst Ihre Aufgabe in der Regel immer in einer definierten Zeit, während bei einer Softwarelösung gerade auf einem OS nicht mal genau gesagt werden kann wann der Task aufgerufen wird."
-> ich sag mal so, entscheiden ist doch der Speed des Ganzen... Eine Hardwarelösung muss nicht schneller als eine Softwarelösung sein. Es kommt auf das Wie drauf an und vor allem, auf die Leistungsfähigkeit der Hardware, welche die Berechnungen ausführt.
Geht man nach einer klassischen Programmierung, wo man mit quasi unbekanntem Leistungsbedarf oder unbekannter Zeit arbeiten muss, würde man wohl eine art Queue einführen, welche vorn (seq. oder par.) gefüllt werden kann und dann hinten einfach abgearbeitet wird... Stellt man sicher, dass die Queue so schnell gefüllt wird, wie hinten raus gelassen wird, dann gibt's ne optimale Leistung für die Softwarelösung.
Wir wissen nur nicht, was man dem Hardwarescheduler bei NV geben muss, damit die Einheiten optimal arbeiten können. Möglicherweise ist das ganze auch genau dafür gebaut (Maxwell), so zu arbeiten? Wenn 1x Grafik + nx Compute sequenziell so schnell durchlaufen, dass es immer noch im zeitlichen Rahmen liegt, ist die Lösung doch ideal?
Die Frage ist halt, wer schreibt vor, was wann wo wie schnell sein muss?
Irgendwo stand geschrieben, dass Maxwell scheinbar auch gut davon in der Effizienz profitiert...

Rein von der technischen Seite müsste NVs Umsetzung bei der Berechnung für Compute und Grafik einfach xx% schneller laufen als die AMD Umsetzung und es gibt nen "Gleichstand" trotz Contextswitching im Endergebnis...
Ob das machbar ist? Keine Ahnung. Denkbar ist es allerdings.

"Das ist ja eigentlich das verwunderliche, dass von Nvidia gar nichts kommt. Könnte Maxwell Async Shader hätten sie ja direkt das Dementi gebracht.
Auch die Tatsache, dass man direkt einen Scheduler auf der CPU geschrieben hat zeigt dass es die Hardware nicht kann."
-> Neja, wie gesagt, das Endergebnis zählt. Wenn das so nicht läuft, wie bei AMD (wonach es aktuell klar ausschaut), muss man irgendwie anders punkten. Sprich den Speed erhöhen oder weis der Geier was... Der Drops ist da definitiv noch nicht gelutscht würde ich meinen.
Nur fehlt es halt eben an besagten Infos für einen sinnvollen Schluss. Einseitig argumentiert würde ich jetzt sagen, NV hat auf absehbare Zeit ein Problem, vor allem, wenn Pascal das nicht anders können soll (angeblich). Allerdings sehe ich halt klar hier die Entwickler in der Pflicht, eine anständige Lösung einzustellen. Denn diesen "mehr Freiraum" wollte man von Entwicklerseiten. Nun soll man es auch nutzen... Allerdings sehe ich da dann die Pferde vor die Apotheke kotzen, wenn das in mehr Arbeit ausarten -> und das wird es. Das steht wohl faktisch fest!

 

[Schaffe89]

Offensichtlich aber auch noch mit Problemen behaftet. Dennoch reicht's am Ende für ne NV an der Spitze... Wie passt das zusammen?

Wo reicht es für Nvidia abgesehen vom falsch ausgeführten Nvidia Benchmark an die Spitze?

 

[coldfingers]

Wo reicht es für Nvidia abgesehen vom falsch ausgeführten Nvidia Benchmark an die Spitze?

Kommt noch

Gesendet von meinem SM-G900F mit der Hardwareluxx App

 

[derneuemann]

Jetzt verstehe ich es auch nicht mehr. Der Bench bei PCGH wurde auf Nvidia GPUs, mit deaktivierten Async Compute durchgeführt, aber ohne das Details reduziert wurden. Oder habe ich das falsch verstanden?
Der Bench zeigt die schon von DX11 bekannte Reihenfolge im Bench. 980ti/Titan X vor Fury X usw.
Wenn dann am Ende die Leistung wie immer ist, ist doch egal wer wie dahin gekommen ist.

 

[[HOT]]

Einige Webseiten haben "Glare" deaktiviert, was massiv auf AsyncCompute setzt. Sie identifizierten dieses Feature aufgrund seiner Langsamkeit auf NV-Hardware als Bug in AoS - heute wissen wir, dass es keiner ist.
PCGH hat es zudem mit TAA übertrieben, was total absurde Ergebnisse bringt.

 

[Cippoli]

Ich frage mich, ob Async Compute, so wie es in der GCN-Architektur implementiert ist, auch in der Form genau so von der DX12-API vorgeschrieben wird. Denn anscheinend gibt es da mehrere Wege Async Compute zu implementieren, die sich am Ende aber in der Leistung/Effizienz unterscheiden. Wenn die DX12-API das nicht näher spezifiziert, dann kann man Async Compute auch durch ein ineffizienteres Verfahren, als das welches AMD in der GCN-Architektur verwendet realisieren, z.B. durch PreEmption (siehe YT-Video), was dann auch die DX12-API Spezifikation erfüllen würde. AMDs Ansatz mit den ACEs wäre dann einfach nur eine effizientere Umsetzung von Async Compute. Am Ende müsste man da also aufpassen, denn AMDs Async Compute in der GCN-Architektur wäre dann nur bedingt das Async Compute was die DX12-API meint. Ich glaube, das genau dieser Punkt für viel Verwirrung sorgt, wenn allgemein über Async Compute gesprochen wird.

Datenschutzhinweis für Youtube

An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.

Youtube Videos ab jetzt direkt anzeigen

Video anzeigen

In dem Video sieht man, dass es eine Umsetzung durch Multi-Threaded, eine weitere durch Priorisierung (PreEmption) und den Ansatz in der GCN-Architektur gibt. Sofern ich das richtig verstanden habe, könnte man jedes dieser Verfahren als Async Compute bezeichnen. Die DX12-API Spezifikation ließe sich somit schon mit einer (ineffizienten) Multi-Threaded oder PreEmption Umsetzung erreichen. Da NVIDIA mit Maxwell 2 eines dieser Verfahren sicher erfüllen dürfte, darf man auch eine Async Compute Unterstüzung angeben, sollte aber nicht zwangsläufig an AMDs GCN-Umsetzung dabei denken. Das würde auch erklären warum es nicht an ein bestimmtes Feature-Level gebunden ist, sondern als Grundvoraussetzung für die DX12-API gilt und nicht explizit erwähnt wird, da es quasi doppelt gemoppelt und somit irgendwo unsinnig wäre.