Nachtrag zu 3DMark Time Spy: Async Compute bei Maxwell-Karten nicht möglich

Don

[printed]-Redakteur, Tweety
Thread Starter
Mitglied seit
15.11.2002
Beiträge
27.016
<p><img src="/images/stories/logos/futuremark.gif" style="margin: 10px; float: left;" />In der vergangenen Woche veröffentlichte Futuremark einen neuen Test der 3DMark-Suite, der explizit dazu ausgelegt sein sollte, der DirectX-12-Leistung auf den Zahn zu fühlen. Wir hatten bereits einige <a href="index.php/news/software/benchmarks/39793-futuremark-3dmark-time-spy-als-directx-12-benchmark-verfuegbar.html" target="_self">eigene Benchmarks durchgeführt und veröffentlicht</a>, die zumindest die beiden letzten GPU-Generation von AMD und NVIDIA abbilden und dabei äußerst kontroverse Ergebnisse zeigen.</p>
<p>AMD wirbt gerne mit der Fähigkeit die Asynchronous Shaders für das Async Compute nutzen zu können und in Spielen wie Ashes of the Singularity und nun auch im 3DMark Time Spy...<br /><br /><a href="/index.php/news/hardware/grafikkarten/39823-nachtrag-zu-3dmark-time-spy-async-compute-bei-maxwell-karten-nicht-moeglich.html" style="font-weight:bold;">... weiterlesen</a></p>
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das nVidia immer noch behauptet Maxwell hätte Async Compute und es dann aber immer für alles deaktiviert ist schon "komisch".
Bleiben eigentlich nur die 2 Schlussfolgerungen:
- Maxwell hat doch kein Async Compute und nVidia hat mal wieder gelogen.....
- Maxwell hat Async Compute, jedoch hat die Einheit einen Bug in der Chiparchitektur (ist AMD und intel ja auch schon hin und wieder passiert) und kann deswegen nicht genutzt werden / nVidia hat noch keinen workaround via Treiber gefunden.
Für diesen Fall, würde ich aber fast davon ausgehen, das nVidia hier auch nicht mehr viele Ressourcen darauf verschwenden wird, es doch noch zum laufen zu bekommen (Nachfolger gibt es ja schon).

Aber egal welche der beiden Möglichkeiten zutrifft, die Kommunikation zum Kunden ist mal wieder unter aller Sau.

PS: Wenn es "nur" im Treiber deaktiviert ist, könnte man das dann nicht via Hack freischalten?
 
Zuletzt bearbeitet:
@Betabrot wenn es nicht deaktiviert wird, fällt die Leistung in dem Fall. So ein Hack wäre also nicht sehr lohnenswert^^
 
Nein, Maxwell hat einfach keine in Hardware gegossenen Async Shaders. Somit kann es asynchrone Datenströme nur per Software in sequentielle umwandeln, was Leistung kostet anstatt bringt.
Maxwells können also kein Async Compute, aber der Treiber kann Async Compute, allerdings mit Performanceeinbußen.
 
Und da soll man noch weiter behaupten NVIDIA bremst ihre alte Serie nicht absichtlich aus...

Sollen sie es doch endlich einmal ganz offen zugeben und technisch begründen warum bei Maxwell per Treiber A-Shaders deaktiviert wird. Das wäre zumindest mal ehrlich und der Maxwell-Käufer weiß nun woran er ist.
Aber das kann man wohl als zahlender Kunden nicht verlangen, der für eine Titan-X damals 1300 Euro auf den Tisch gelegt hat...

Egal, Pascal ist ja jetzt da und damit funktioniert es nun besser. Wie ist ebenfalls ein Geheimnis. Ja "NVIDIA is magic"... ;)
 
Und da soll man noch weiter behaupten NVIDIA bremst ihre alte Serie nicht absichtlich aus...

Sollen sie es doch endlich einmal ganz offen zugeben und technisch begründen warum bei Maxwell per Treiber A-Shaders deaktiviert wird. Das wäre zumindest mal ehrlich und der Maxwell-Käufer weiß nun woran er ist.
Aber das kann man wohl als zahlender Kunden nicht verlangen, der für eine Titan-X damals 1300 Euro auf den Tisch gelegt hat...

Egal, Pascal ist ja jetzt da und damit funktioniert es nun besser. Wie ist ebenfalls ein Geheimnis. Ja "NVIDIA is magic"... ;)

Bist du bei AMD auch so kritisch was das WIE angeht? Ist es echt so verwunderlich, dass eine riesen Firma etwas umsetzt, was der kleine Hans Wurst vor Jahren umgesetzt hat? Fühlst du dich nach dem Post von oooverclocker wenigstens ein wenig dämlich? Angebracht wäre es ...

Aber bei dem Benutzerbild weiß man auch direkt bescheid!

"AMD zieht zu viel Strom über die PCI-E-Lanes" ... "DAS IST EINE VERSCHWÖRUNG VON NVIDIA!" :stupid:

Kannst du nicht einfach hinnehmen, dass Pascal jetzt auch AC kann?
 
@Pickelbuh: Genau, nVidia hat Maxwell schon bei release ausgebremst damit Pascall jetzt besser da steht :wall:, denkst du eigentlich nach bevor du so etwas schreibst (retorische Frage)? Darüber hinaus war der Straßenpreis der Titan-X 1000-1100 € und wer schon damals eine Titan-X brauchen konnte (welche AMD hat den für "kleines" Geld 12 GB VRam? - ups die hatte ja nur 4 GB....) hat auch heute noch vorteile von der Titan-X. Du vergisst wohl, das die Titan Serie ein Zwischending zwischen proffessioneller (Quadro / FireGL) und gamer Karte ist. Die Titan ist gerade für Selbständige und Indie Entwickler ideal. Wer sich so eine nur zum Gamen kauft ist selber Schuld, bzw. hat zu diesem Zeitpunkt auch das bekommen wofür er bezahlt hat (AMD ist nicht wirklich billiger gewesen mit der Furry im Verhältnis).

@oooverclocker: Das wäre auch noch eine gute Erklärung, womit dann aber nVidia immer noch nicht richtig mit dem Kunden kommuniziert.
 
Aber ist es nicht einfach so, dass NV kein AC in Hardware kann, auch mit Pascal nicht :confused:

Vielleicht bei Volta dann ...
 
Bei Pascal ist es ja nicht 100% sicher ob natives A-Shaders funktioniert oder wie weit es klappt, weil NVIDIA da nicht ganz offen Kommuniziert.
Könnte auch sein, dass der Benchmark eben dies berücksichtigt. Aber andere Programme das eben nicht tun.

Um das auf zu klären müssten sie erst mal die Sache mit Maxwell offen darlegen und erläutern was nun genau Pascal in diesem Punkt verbessert.
Aber das bleibt eben wiedermal aus und der Pascal-Käufer kann hoffen, dass seine Hardware auch in Zukunft keine Überraschung parat hält.

Kann ja auch positiv enden. ;)
 
Zuletzt bearbeitet:
ja stimmt, muss man ehrlich sein, es ist nicht bekannt, ob Pascal AC unterstützt ....
 
Eigentlich ist es sehr wohl bekannt und wurde von Nvidia auch kommuniziert ... Aber wenn man selbst ein Troll ist überliest man sowas wohl (ausversehen) ...
 
Hier mal etwas Lesestoff dazu:
The GeForce GTX 1080 8GB Founders Edition Review - GP104 Brings Pascal to Gamers | Asynchronous Compute: Let the debate continue

Kurzes Fazit: Die Implementation seitens AMD und NV gehen in zwei verschiedene Richtungen...
Die Frage ist, gibt es eine Spezifikation, was "Async Compute" am Ende genau ist/sein muss?
Im Moment scheint sich die Community eher daran aufzuhängen, welcher Hersteller wie viel Leistungsgewinn dadurch zieht... Aber ist das wirklich das entscheidende? Aus meiner Sicht ist das entscheidene eher, was am Ende bei rum kommt. Wenn AMD durhc ASync Compute 5-15% im Schnitt (nach aktuellen Titeln) mit Hawaii und Fiji bspw. erreicht, Polaris 10 allerdings durch weitere Hardwareoptimierungen schon etwas drunter liegt (vor allem in niedrigeren Auflösungen) und NV mit Pascal am Ende in den gleichen Titeln eher bei 5-10% liegt, dann zeigt es eigentlich nur, dass ASync Compute Skalierung schlicht mindestens mal in Verbindung zur verbauten Hardware betrachtet werden muss.
-> letzteres wird man aber hier nicht finden. Vor allem nicht von den üblichen Verdächtigen :wink:
 
Zuletzt bearbeitet:
Naja, bei AMD ist es halt immer so eine Sache und man weiß nicht so recht, was man bekommt.
Bei nvidia hingegen kann man sich wenigstens sicher sein, dass man beschissen wird.

Das ist nicht nur modern, sondern auch verlässlich!
 
Zuletzt bearbeitet:
Pascal muss AC implementiert haben. Wen AC an ist, könnte man sonst nur Nachteile davon tragen, weil das Umwandeln in für die Grafikkarte verarbeitbare Datenströme overhead produzieren würde.
Pascal profitiert aber davon, folglich muss die Hardware es supporten und erfahrungsgemäß profitiert die GTX 1080 mit den vielen ALUs auch am meisten davon, bei Nvidia. Allerdings ist das Steigerungspotential nicht so groß, wie bei den AMD- Karten, die gegenüber ihrem DX11- Pendant meistens fast doppelt so viele ALUs bei weniger Takt haben und in DX11 bisher nicht gut ausgelastet wurden. Falls Vulkan/DX12 das, was sie tun sollen, perfekt lösen würden, müsste man (rein logisch gesehen) künftig die tatsächliche Leistung der Karten fast 1:1 mit den FLOPS bestimmen können. Das ist aber nur die Theorie und müsste dazu absolut perfekt umgesetzt werden...
 
Zuletzt bearbeitet:
Also können nvidia 10xx karten kein DX 12.
 
Naja, bei AMD ist es halt immer so eine Sache und man weiß nicht so recht, was man bekommt.
Bei nvidia hingegen kann man sich wenigstens sicher sein, dass man beschissen wird.

Das ist nicht nur modern, sondern auch verlässlich!

made my day :fresse:
 
Falls Vulkan/DX12 das, was sie tun sollen, perfekt lösen würden, müsste man (rein logisch gesehen) künftig die tatsächliche Leistung der Karten fast 1:1 mit den FLOPS bestimmen können. Das ist aber nur die Theorie und müsste dazu absolut perfekt umgesetzt werden...

Nein, nicht wirklich... Denn es gibt eine Menge mehr Faktoren, die dafür zuständig sind, die Skalierung zu verändern...
Es kommt schlicht und ergreifend drauf an, was der Programmierer am Ende will. Reine Shaderlast geht quasi 1:1 mit der Rohpower zu skalieren, das stimmt wohl. Aber der Rest? Je nach Aufbau der Szenen können da mal ROPs, TMUs, Tesselation Units usw. zum Limit werden. Da ändert DX12 schlicht gar nix an der Situation. Denn eine GPU besteht nicht nur aus ALUs, sondern aus vielen Teilen, die quasi fast unabhängig voneinander ihre Arbeit verrichten.

Was meinst du bspw., warum AMD GPUs zum Teil unter massivster Tesselation Last viel stärker wegbrechen als die NV Pedanten? -> weil ihre Tesselation Leistung, vor allem in höheren Stufen deutlich geringer ausfällt. Wird nun aber sehr sehr viel Tesselation Leistung seitens der Software angefordert, dann skaliert natürlich auch die Shaderrohpower keineswegs mehr nach oben... Zumindest nicht, solange man starre Konstrukte verwendet. (wie es AMD bis einschließlich dem Polaris wohl nach wie vor tut)
Entscheidend ist eher, was der Programmierer am Ende für Anforderungen setzt... Setzt er auf etwas, was bei mancher Hardware nicht in Übermaßen vorhanden ist, dann wird es dort einen Skalierungsknick geben... Und das völlig ohne Einfluss der genutzten API -> denn es ist eher ein Hardwarelimit.
 
Die Tesselation Leistung wurde bei der RX480 deutlich erhöht. Daher kann sie sich auch oft gegen die R9 390X durchsetzen, vor allem in Games, wo viel Tess verlangt wird.
 
Du hast es wohl nicht verstanden... Es ging nicht um die Tesselation Leistung. Sondern es ging darum, dass neben der Rohleistung in Form von ALU Power andere Faktoren über eine Leistungsskalierung entscheiden können. Und damit ein pauschales, mit DX12/Vulcan skalliert die Leistung 1:1 anhand der Rohleistung in GFlops nicht zutreffend ist.
 
Also können nvidia 10xx karten kein DX 12.

hä ? Weiste welche Kartengeneration Maxwell war ? Pascal kann durchaus DX12. Aber ich verstehe garnicht das man darüber diskutiert, DX12 ist sowieso unwichtig im Moment und noch lange nicht Standart. Und da es von AMD nix in Leistung ab GTX 980TI gibt ist es sowieso keine Frage ob man wechseln sollte.
 
Damit ist der Traum von Async Compute für Maxwell-Karten endgültig geplatzt. nVidia hat die Leute also seit über einem Jahr an der Nase rumgeführt.

Und bei Pascal ist die ganze Sache also auch noch zweifelhaft. Na ja, nVidias schlechter Ruf kommt nicht von ungefähr...
 
hä ? Weiste welche Kartengeneration Maxwell war ? Pascal kann durchaus DX12. Aber ich verstehe garnicht das man darüber diskutiert, DX12 ist sowieso unwichtig im Moment und noch lange nicht Standart. Und da es von AMD nix in Leistung ab GTX 980TI gibt ist es sowieso keine Frage ob man wechseln sollte.

Unwichtig? Hmm ok sehe ich aber zb. anders.....
 
dx12 ist so lange "unwichtig", wie es bei nvidia nicht gescheit läuft.
sobald das anders ist, ist vollständiger und einwandfreier dx12 support natürlich standard.

gleiches spiel beim stromverbrauch.
der interessiert immer nur in den generationen, in denen die "richtige" firma dort besonders gut darsteht.
 
Je nach Aufbau der Szenen können da mal ROPs, TMUs, Tesselation Units usw. zum Limit werden. Da ändert DX12 schlicht gar nix an der Situation. Denn eine GPU besteht nicht nur aus ALUs, sondern aus vielen Teilen, die quasi fast unabhängig voneinander ihre Arbeit verrichten.
Wenn man sich das in der Praxis mal anschaut, sind die Nvidia- Karten im groben Vergleich aber verhältnismäßig ähnlich proportioniert zu den AMD- Karten. Nur bei den ALUs und deren Takt gibt es signifikante Unterschiede.

Bei der Tesselation hat Nvidia ja bekanntlich mit GameWorks den Finger mitten in die Wunde gelegt. Die RX 480 hat damit offensichtlich kein Problem mehr und schneidet deutlich besser ab als ihre Vorgänger.
 
Noch mal bei Maxwell wird die DX 12 Funktion Async Compute in Treiber deaktiviert. Obwohl NVidia sagt das die Maxwell Chip´s DX 12 voll in Software können soll. Das ist ******.

Und bei Pascal ist die Funktion Async Compute fraglich obwohl NVidia mit DX 12.1 in Hardware wirbt. Das erinnert am 4 GB Beschiss bei der GTX970.
 
Was soll dieses async compute Debatte. Hardware von verschiedenen Herstellern hat sich schon immer in deren Architektur unterschieden, ein Intel Prozessor kann auch einiges besser als ein AMD oder ARM und bei Grafikkarten ist es eben genauso. Niemand kann ein Spiel nicht spielen, weil async schlecht oder gar nicht unterstützt wird. Und warum sollte das am Ende die Grünen kümmern, ihre Hardware ist auch ohne perfektes async compute Platzhirsch.

Gibt es endlich gute Software, die wirklich alle Register zieht, sind wir schon längst bei Volta und dem AMD äquivalent oder sogar noch weiter in der Zukunft.

Das ist doch nun wirklich reines Marketing, welches von AMD zusammen mit den Entwicklern von Ashes angestoßen wurde, damit sie wenigstens einen unangefochtenen Trumpf haben, würde ich auch so machen und ist doch auch OK. Die Welt geht deshalb nicht unter.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh