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

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

DruckenE-Mail
Erstellt am: von

nvidia 2013Mit Ashes of Singularity hat Oxide Games ein Spiel kreiert, mit dem man sehr gut die Auswirkungen von DirectX 12 auf die Leistung der Grafikkarten nachstellen kann. Nun soll ein Mitarbeiter im Guru3D-Forum gepostet haben, dass der Grafikchipspezialist NVIDIA unter Führung von Jen-Hsun Huang an das Entwicklerstudio mit der Bitte herangetreten sei, das DirectX 12 Feature „Asynchronus Shader“ für GeForce-Grafikkarten zu deaktivieren, obwohl der Treiber eindeutig zu verstehen gebe, dass die Grafikkarten aus dem grünen Lager dies unterstützen würden.

untitled 1

Demnach habe die Maxwell-Architektur einen gravierenden Nachteil im Vergleich zu AMDs seit 2011 auf dem Markt befindlichen Graphics Core-Next-Architektur. Ein ähnliches Verhalten zeigte NVIDIA bereits zur Einführung von DirectX 11.2, welches bis heute nicht unterstützt wird.

Mit asynchronen Shadern wäre es Grafikkarten unter anderem möglich, GPGPU-Befehle und Render-Befehle gleichzeitig abzuarbeiten. Ohne asynchrone Shader müssten die Befehle nacheinander abgearbeitet werden.

Async Aces 575px

Im Posting des Mitarbeiters betont er nochmal, dass Maxwell nach seinem Kenntnisstand Async. Shader nicht unterstützt oder zumindest nicht in Hardware unterstützt. Ob NVIDIA später mittels des Treibers noch einen Workaround schreiben kann, ist fraglich. Zudem zeigt er sich erfreut, dass AMD trotz eines Marketingdeals über Ashes of Singularity keinerlei Anstalten machte als die Entwickler anfingen mit NVIDIA zusammenzuarbeiten.

Der komplette Post lautet im Wortlaut:

The interest in this subject is higher then we thought. The primary evolution of the benchmark is for our own internal testing, so it's pretty important that it be representative of the gameplay. To keep things clean, I'm not going to make very many comments on the concept of bias and fairness, as it can completely go down a rat hole.

Certainly I could see how one might see that we are working closer with one hardware vendor then the other, but the numbers don't really bare that out. Since we've started, I think we've had about 3 site visits from NVidia, 3 from AMD, and 2 from Intel ( and 0 from Microsoft, but they never come visit anyone ;(). Nvidia was actually a far more active collaborator over the summer then AMD was, If you judged from email traffic and code-checkins, you'd draw the conclusion we were working closer with Nvidia rather than AMD wink.gif As you've pointed out, there does exist a marketing agreement between Stardock (our publisher) for Ashes with AMD. But this is typical of almost every major PC game I've ever worked on (Civ 5 had a marketing agreement with NVidia, for example). Without getting into the specifics, I believe the primary goal of AMD is to promote D3D12 titles as they have also lined up a few other D3D12 games.

If you use this metric, however, given Nvidia's promotions with Unreal (and integration with Gameworks) you'd have to say that every Unreal game is biased, not to mention virtually every game that's commonly used as a benchmark since most of them have a promotion agreement with someone. Certainly, one might argue that Unreal being an engine with many titles should give it particular weight, and I wouldn't disagree. However, Ashes is not the only game being developed with Nitrous. It is also being used in several additional titles right now, the only announced one being the Star Control reboot. (Which I am super excited about! But that's a completely other topic wink.gif).

Personally, I think one could just as easily make the claim that we were biased toward Nvidia as the only 'vendor' specific code is for Nvidia where we had to shutdown async compute. By vendor specific, I mean a case where we look at the Vendor ID and make changes to our rendering path. Curiously, their driver reported this feature was functional but attempting to use it was an unmitigated disaster in terms of performance and conformance so we shut it down on their hardware. As far as I know, Maxwell doesn't really have Async Compute so I don't know why their driver was trying to expose that. The only other thing that is different between them is that Nvidia does fall into Tier 2 class binding hardware instead of Tier 3 like AMD which requires a little bit more CPU overhead in D3D12, but I don't think it ended up being very significant. This isn't a vendor specific path, as it's responding to capabilities the driver reports.

From our perspective, one of the surprising things about the results is just how good Nvidia's DX11 perf is. But that's a very recent development, with huge CPU perf improvements over the last month. Still, DX12 CPU overhead is still far far better on Nvidia, and we haven't even tuned it as much as DX11. The other surprise is that of the min frame times having the 290X beat out the 980 Ti (as reported on Ars Techinica). Unlike DX11, minimum frame times are mostly an application controlled feature so I was expecting it to be close to identical. This would appear to be GPU side variance, rather then software variance. We'll have to dig into this one.

I suspect that one thing that is helping AMD on GPU performance is D3D12 exposes Async Compute, which D3D11 did not. Ashes uses a modest amount of it, which gave us a noticeable perf improvement. It was mostly opportunistic where we just took a few compute tasks we were already doing and made them asynchronous, Ashes really isn't a poster-child for advanced GCN features.

Our use of Async Compute, however, pales with comparisons to some of the things which the console guys are starting to do. Most of those haven't made their way to the PC yet, but I've heard of developers getting 30% GPU performance by using Async Compute. Too early to tell, of course, but it could end being pretty disruptive in a year or so as these GCN built and optimized engines start coming to the PC. I don't think Unreal titles will show this very much though, so likely we'll have to wait to see. Has anyone profiled Ark yet?

In the end, I think everyone has to give AMD alot of credit for not objecting to our collaborative effort with Nvidia even though the game had a marketing deal with them. They never once complained about it, and it certainly would have been within their right to do so. (Complain, anyway, we would have still done it, wink.gif)

--
P.S. There is no war of words between us and Nvidia. Nvidia made some incorrect statements, and at this point they will not dispute our position if you ask their PR. That is, they are not disputing anything in our blog. I believe the initial confusion was because Nvidia PR was putting pressure on us to disable certain settings in the benchmark, when we refused, I think they took it a little too personally.

AFAIK, Maxwell doesn't support Async Compute, at least not natively. We disabled it at the request of Nvidia, as it was much slower to try to use it then to not. Weather or not Async Compute is better or not is subjective, but it definitely does buy some performance on AMD's hardware. Whether it is the right architectural decision for Maxwell, or is even relevant to it's scheduler is hard to say.

Social Links

Kommentare (222)

#213
Registriert seit: 05.11.2007
Neckar-Odenwald Kreis
Fregattenkapitän
Beiträge: 2896
Zitat fdsonne;23841694
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 :fresse:
Eigentlich wollte ich mit meinem Post Cibo nur erklären, dass es nicht um 32 vs 64 queues geht

Zitat fdsonne;23841694

- 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.

Zitat fdsonne;23841694

- 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.

Zitat fdsonne;23841694

- 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, ...

Zitat fdsonne;23841694

- 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.

Zitat fdsonne;23841694

- 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.

Zitat fdsonne;23841694

- 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.

Zitat fdsonne;23841694

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.
#214
customavatars/avatar43872_1.gif
Registriert seit: 31.07.2006

Fregattenkapitän
Beiträge: 2859
Zitat Pickebuh;23841891
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.
#215
customavatars/avatar145021_1.gif
Registriert seit: 12.12.2010

Banned
Beiträge: 5646
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.
#216
customavatars/avatar3709_1.gif
Registriert seit: 13.12.2002
Bayern
Vizeadmiral
Beiträge: 6808
Zitat Pickebuh;23841891
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)
#217
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31948
@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 :fresse:

"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!
#218
customavatars/avatar145021_1.gif
Registriert seit: 12.12.2010

Banned
Beiträge: 5646
Zitat
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?
#219
customavatars/avatar25027_1.gif
Registriert seit: 16.07.2005

Fregattenkapitän
Beiträge: 2606
Zitat Schaffe89;23842165
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
#220
Registriert seit: 07.03.2013

Fregattenkapitän
Beiträge: 2953
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.
#221
customavatars/avatar43872_1.gif
Registriert seit: 31.07.2006

Fregattenkapitän
Beiträge: 2859
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.
#222
Registriert seit: 09.08.2006

Flottillenadmiral
Beiträge: 4149
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.

[video=youtube;v3dUhep0rBs]https://www.youtube.com/watch?v=v3dUhep0rBs[/video]

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.
Um Kommentare schreiben zu können, musst Du eingeloggt sein!

Das könnte Sie auch interessieren:

Roundup: 5x GeForce GTX 1070 mit Custom-Design im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/5X-GTX1070/GTX1070_CUSTOM_ROUNDUP-TEASER

Nachdem wir bereits eine Reihe von Boardpartner-Karten der NVIDIA GeForce GTX 1080 ausführlich getestet haben, holen wir gleiches nun für das kleinere Schwestermodell nach, denn auch von der NVIDIA GeForce GTX 1070 gibt es viele Custom-Modelle mit höheren Taktraten, eigenen Kühlsystemen und... [mehr]

Drei Custom-Modelle der GeForce GTX 1060 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/3X-GTX1060/GTX1060_ROUNDUP_TEST-TEASER

Anders als bei der GeForce GTX 1080 und GeForce GTX 1070 trudelten wenige Stunden nach unserem Test zur Founders Edition der NVIDIA GeForce GTX 1060 schon die ersten Boardpartner-Karten mit teils höheren Taktraten, eigenem Kühlsystem und überarbeitetem Platinenlayout ein. Sie dürften... [mehr]

NVIDIA GeForce GTX 1080 mit Pascal-Architektur im XXL-Test

Logo von IMAGES/STORIES/LOGOS-2016/GEFORCE-GTX-1080

Heute ist es soweit: NVIDIA läutet mit der GeForce GTX 1080 und GTX 1070 auf Basis der Pascal-Architektur den diesjährigen Neustart bei den Grafikkarten ein. In Kürze wird wohl auch AMD seinen Beitrag zu diesem Thema leisten. Vor zehn Tagen lud NVIDIA die gesammelte Fachpresse nach Austin ein... [mehr]

Roundup: 5x GeForce GTX 1080 im Custom-Design im Test

Logo von IMAGES/STORIES/LOGOS-2016/GEFORCE-GTX-1080

Nachdem wir uns die Founders Edition der GeForce GTX 1080 und GeForce GTX 1070 bereits angeschaut haben, folgen nun fünf Retail-Modelle, die wir in aller Ausführlichkeit unter die Lupe nehmen wollen. Aus den vielen Boardpartnern und unterschiedlichen Modellen haben wir uns solche von ASUS, EVGA,... [mehr]

AMD Radeon RX 480 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/RADEON-RX480/RADEON-RX480-REFERENCE-LOGO

Es ist also soweit: AMD startet die großangelegte Zurückeroberung des Grafikkartenmarktes mit der Radeon RX 480, die als erste Grafikkarte der Polaris-Generation mit gleichnamiger Architektur erscheint und die wir uns genauer anschauen können. Dabei versucht sich AMD an einem anderen Ansatz im... [mehr]

PowerColor Radeon RX 480 Red Devil im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/POWERCOLOR-RX480/POWERCOLOR-RX480REDDEVIL-LOGO

Mit der Radeon RX 480 will AMD zurück zu alter Stärke und hat daher über Monate hinweg die PR-Trommel geschlagen. Letztendlich dabei herausgekommen ist eine sehr gute Karte für einen niedrigen Preis, die aber nicht in allen Bereichen zu überzeugen weiß. Wohl größtes Manko der Karte sollte... [mehr]