Ashes of the Singularity & Asynchronous Shader [Archiv] - Seite 6

Gorkon

2016-02-24, 20:50:18

Strange. :freak:

Edit:
Argh... vorsicht. Hier dürfte schon die Grundlast "einschlagen" da unter DX11 die Frames sehr tief sind. Aussagekräftiger sind auf jeden Fall die avg.fps.

Edit 2:
Auch interessant... der FX-8370 rendert unter DX12 bei Nvidia bis zu 45% schneller gegenüber DX11. Schönen Gruß an dildo "Nvidia braucht kein DX12". ;)

Auf alle Fälle rückt Bulldozer hier mit DX12 teilweise massiv näher an Intel ran:

FX-8370 zu i7-6700K - 980TI - avg. FPS:
720P = 48% > 27% langsamer
1080P = 39% > 12% langsamer
2160P = 14% > 3% langsamer

FX-8370 zu i7-6700K - FuryX - avg. FPS:
720P = 88% > 46% langsamer
1080P = 82% > 31% langsamer
2160P = 67% > 13% langsamer

Und das wars auch mit Threadhijacking von mir :freak: DX11 gehört sowas von in die Tonne, wenn das hier kein Einzelfall bleiben sollte...

Troyan

2016-02-24, 20:53:25

Wo ist denn das Problem wenn die Hardware es nicht anders (besser) kann? Nvidianer können immer noch den DX11 Renderpfad nutzen. Richtig interessant wird es erst wenn only DX12 Games kommen, die ja bereits angekündigt sind.

Gut. Dann können wir The Witcher 3 in Zukunft auch wieder mit Hairworks testen. Ich meine, was kann nVidia dafür, dass AMD Hardware so schlecht mit Tessellation ist. :freak:

Nochmal: Der Entwickler ist verantwortlich zur Optimierung der Hardware. Dies ist nicht mehr in Händen der Treiberentwickler. Wenn absichtlich keine Optimierung auf andere Hardware stattfindet, muss dies ausdrücklich erwähnt werden. Ansonsten kommen solche Leute wie du um die Ecke, die hier was von "Überlegenheit" reden.

(del)

2016-02-24, 20:55:25

Übrigens profitiert die GTX 980 Ti messbar, wenn man HT deaktiviert, weil man da eher von hohen IPC-Werten als von breiter Skalierung profiiert. Die Karte saugt sich geradezu am Takt fest und bei 4,8 GHz kommt dann der Überholvorgang mit 5km Anlauf :P

Das schreibt einer, der privat bis auf den HTPC nur NV-Karten verbaut hat ;)

Eines muss man AMD aber neidlos zugestehen: seit Kurzem landen die mal wieder Marketing-Treffer. Ein völlig neues Feeling :)

blaidd

2016-02-24, 20:57:16

Gut. Dann können wir The Witcher 3 in Zukunft auch wieder mit Hairworks testen. Ich meine, was kann nVidia dafür, dass AMD Hardware so schlecht mit Tessellation ist. :freak:

Nochmal: Der Entwickler ist verantwortlich zur Optimierung der Hardware. Dies ist nicht mehr in Händen der Treiberentwickler. Wenn absichtlich keine Optimierung auf andere Hardware stattfindet, muss dies ausdrücklich erwähnt werden. Ansonsten kommen solche Leute wie du um die Ecke, die hier was von "Überlegenheit" reden.

Wir richten uns nach dem Standard, einverstanden? Wenn beispielsweise in Fallout 4 auch auf den Konsolen Gameworks zum Einsatz kommt, dann kommt es auch in den PC-Benchmarks zum Einsatz... das halte ich für fair. Einen Vergleich mit Async On/Off müsste man natürlich zusätzlich machen (ähnlich GW), sofern das möglich ist.

dargo

2016-02-24, 20:57:54

Achja, selbst in 1280x800 und "hohen" Draw-Calls ist DX12 kaum schneller auf nVidia-Hardware und erreicht überragende 55FPS: http://www.computerbase.de/2016-02/ashes-of-the-singularity-directx-12-amd-nvidia/5/#diagramm-cpu-skalierung-1280-800-gtx-980-ti
Für mich sieht das eher danach aus, dass bei den hohen Drawcalls sowohl eine GTX980TI als auch Fury X für die schnelleren CPUs zu langsam sind. Gewissheit haben wir erst mit SLI/CF oder neuen High-End GPUs.

Gut. Dann können wir The Witcher 3 in Zukunft auch wieder mit Hairworks testen. Ich meine, was kann nVidia dafür, dass AMD Hardware so schlecht mit Tessellation ist. :freak:

In Zukunft kommt Witcher 4 (womöglich mit TressFX 3.0), da interessiert Witcher 3 keine Sau mehr. ;)

Wenn absichtlich keine Optimierung auf andere Hardware stattfindet, muss dies ausdrücklich erwähnt werden.
Das ist erstmal reine Spekulation deinerseits. Wir werden sehen wie sich die Geschichte weiter entwickelt.

Nakai

2016-02-24, 20:58:40

Nebenbei bemerkt sind die Frametimes für MGPU ziemlich gut. Es gibt kaum Unterschiede zwischen MGPU und SGPU.

dildo4u

2016-02-24, 20:59:01

Auf alle Fälle rückt Bulldozer hier mit DX12 teilweise massiv näher an Intel ran:

FX-8370 zu i7-6700K - 980TI - avg. FPS:
720P = 48% > 27% langsamer
1080P = 39% > 12% langsamer
2160P = 14% > 3% langsamer

FX-8370 zu i7-6700K - FuryX - avg. FPS:
720P = 88% > 46% langsamer
1080P = 82% > 31% langsamer
2160P = 67% > 13% langsamer

Und das wars auch mit Threadhijacking von mir :freak: DX11 gehört sowas von in die Tonne, wenn das hier kein Einzelfall bleiben sollte...
Komisches Fazit natürlich kommt der Bulldozer näher,da die GPU unter DX12 mehr limitiert,der Abstand ist der Selbe taucht aber halt nur noch mit einem Crossfire oder einer Next-Gen GPU auf.

Achill

2016-02-24, 21:01:43

@Format_C - sehr schöner Artikel!

@captain_drink, M4xw0lf (, Format_C) - man braucht den Verbrauch von GPU und Gesamtsystem und der Wert des Gesamtsystems ist mMn höher zu Werten, da die Betrachtung immer ist: Eingesetzte Leistung zu Erreichtes Ergebnis

Gehört hier zwar eigentlich nicht so wirklich rein, aber hat noch niemand auf die CPU-Tests bei CBase geschaut :confused: DAS ist der eigentliche Hammer. 4M/8T Piledriver auf ner FuryX bis zu 161% schneller :ulol:

http://www.computerbase.de/2016-02/ashes-of-the-singularity-directx-12-amd-nvidia/5/

Der ganze Kram kommt für AMD echt zu spät ;(

Zum glück habe ich hier noch mein FX in einer golden Schachtel - wenn das so weiter geht wird der noch Goldstaub und kommt wieder in den Rechner ... ;)

---
Edit: Oder ich tausche den FX dann gegen die Canopus oder Sirius GPU ... ;)

dargo

2016-02-24, 21:03:30

Nebenbei bemerkt sind die Frametimes für MGPU ziemlich gut. Es gibt kaum Unterschiede zwischen MGPU und SGPU.
Link? Das wäre ne Sensation. :eek:

Troyan

2016-02-24, 21:03:57

Für mich sieht das eher danach aus, dass bei den hohen Drawcalls sowohl eine GTX980TI als auch Fury X für die schnelleren CPUs zu langsam sind. Gewissheit haben wir erst mit SLI/CF oder neuen High-End GPUs.

Kein GPU-Limit. Es limitiert die miserable Programmierung. Der Leistungsverlust von 800p auf 2160p beträgt nur 25%.

dildo4u

2016-02-24, 21:08:02

Die CPU Skalierung ist enttäuschend der 6 Core sollte vor dem Skylake sitzen.
Aber man muss sich immer in Erinnerung rufen das ist die erste Welle der DX12 Games,das sollte später deutlich besser werden.

aufkrawall

2016-02-24, 21:08:54

Link? Das wäre ne Sensation. :eek:
Gibts mit Frame Pacing bei AFR mit Nvidia schon lange...
Das funktioniert nur nicht immer gleich gut und es gibt halt noch den Lag, der fast nie gemessen wird.

Gorkon

2016-02-24, 21:14:57

Komisches Fazit natürlich kommt der Bulldozer näher,da die GPU unter DX12 mehr limitiert,der Abstand ist der Selbe taucht aber halt nur noch mit einem Crossfire oder einer Next-Gen GPU auf.

Bitte wie:confused: Diagramme lesen kannst du aber oder? Schau nochmal genau hin und sag mir wo der Abstand bitte gleich bleibt, wenn Bulldozer überall prozentual von DX11 > DX12 mehr profitiert als Skylake, egal ob mit GM200 oder Fiji ;)

EDIT: Für mich jedenfalls der 1. richtige Test der auch mal die CPUs bei DX11 und 12 vergleicht und endlich mal die Bestätigung, dass es auch auf dieser Seite was bringt...

(Letzer Beitrag hier von mir, da CPU-Stuff im GPU-Forum, nochmals sry)

mfg

dargo

2016-02-24, 21:15:46

Kein GPU-Limit. Es limitiert die miserable Programmierung. Der Leistungsverlust von 800p auf 2160p beträgt nur 25%.
Öhm... dir ist aber schon aufgefallen, dass auch die Fury X bei hohen Drawcalls mit einer schnelleren CPU nicht schneller wird? Für mich sieht das wie gesagt nach einem Drawcall-Limit der GPUs aus, im Prinzip also GPU-Limit. Schau dir mal die Drawcalls unterschiedlicher GPUs an.
http://www.anandtech.com/show/9112/exploring-dx12-3dmark-api-overhead-feature-test/3

(del)

2016-02-24, 21:17:27

Link? Das wäre ne Sensation. :eek:

http://media.bestofmicro.com/2/3/561243/gallery/03-Frame-Time_w_600.png

http://media.bestofmicro.com/1/L/561225/original/03-MGPU-Frame-Time-Detail.png

http://media.bestofmicro.com/2/1/561241/original/04-Smoothness.png

http://media.bestofmicro.com/1/M/561226/original/04-MGOU-Smoothness-Detail.png

M4xw0lf

2016-02-24, 21:20:51

Übrigens - Anandtech schreibt ernsthaft nicht mehr AMD wenns um Radeons geht, sondern RTG. Neue Marketingstrategie am Start offenbar.

Troyan

2016-02-24, 21:24:26

Öhm... dir ist aber schon aufgefallen, dass auch die Fury X bei hohen Drawcalls mit einer schnelleren CPU nicht schneller wird? Für mich sieht das wie gesagt nach einem Drawcall-Limit der GPUs aus, im Prinzip also GPU-Limit. Schau dir mal die Drawcalls unterschiedlicher GPUs an.
http://www.anandtech.com/show/9112/exploring-dx12-3dmark-api-overhead-feature-test/3

Nein, es ist kein GPU-Limit. Es ist ein Programmierlimit, dass zu einer Limitierung im Chipbereich führt, wodurch die Karten ihre vollständige Leistung nicht ausbreiten können.

dargo

2016-02-24, 21:32:21

Die CPU Skalierung ist enttäuschend der 6 Core sollte vor dem Skylake sitzen.

Woran erkennst du das? Ich sehe bei CB durchaus eine gute Skalierung bei 6 Cores, der Fury X und wenigen Drawcalls. Bei avg. sieht es nicht viel anders aus.
http://www.computerbase.de/2016-02/ashes-of-the-singularity-directx-12-amd-nvidia/5/#diagramm-cpu-skalierung-1280-800-gtx-980-ti

i7-5820 (3,3Ghz) erreicht quasi identische Werte vom i7-6700K (4,0Ghz). Möglich wären auch 3,4Ghz vs. 4,1Ghz, keine Ahnung wie hoch der Turbo taktet wenn alle Cores bzw. Threads beschäftigt sind. Wenn man jetzt noch die höhere IPC vom Skylake beachtet geht das imo in Ordnung. Und wer weiß... bei über 90fps könnte die Graka wieder etwas limitieren. Egal ob bei der Rechenleistung oder den Drawcalls. Jetzt verstehe ich glaube ich was fondness meinte mit DX12 wäre bereits bei hohen Drawcalls am Limit. Nicht die API ist am Limit sondern die GPUs.

PS: man sieht sogar, dass die Skalierung unter DX12 mit dem Sixcore einiges besser als unter DX11 ist. Unter DX11 ist der i7-Skylake schon gutes Stück schneller (avg. +14%).

Nakai

2016-02-24, 21:43:50

Übrigens - Anandtech schreibt ernsthaft nicht mehr AMD wenns um Radeons geht, sondern RTG. Neue Marketingstrategie am Start offenbar.

Haha, stimmt. ;D

Mir kommen böse Gedanken.

Bzgl. MGPU: Man wird mit DX12 definitiv mehr gezwungen sein, die einzelnen GPUs gezielter anzusprechen. DX12 ist sehr interessant, da Aspekte aus dem GPGPU-Bereich hinzuzieht.

€: Auf langer Sicht wird DX12 sehr nett werden. Da können jetzt jegliche NVidianer erstmal frotzeln, da ihre geliebten GPUs gegenüber der Konkurrenz (fürs Erste) schlechter dastehen. DX12 bringt definitiv einige Vorteile.

(del)

2016-02-24, 21:46:15

Bzgl. MGPU: Man wird mit DX12 definitiv mehr gezwungen sein, die einzelnen GPUs gezielter anzusprechen. DX12 ist sehr interessant, da Aspekte aus dem GPGPU-Bereich hinzuzieht.ich warte auf den Moment, wo PhysX und DirectX12 bei SFR kollidieren. PhysX lässt sich ja nur auf einer GPU ausführen. :D

fondness

2016-02-24, 21:47:19

DX12/Vulkan ist für AMD zweifellos sehr gut, gerade im long run. Es ist exakt die API die man wollte, um die Hardware in den Vordergrund zu rücken.

Schnoesel

2016-02-24, 23:01:29

Schlammschlacht nächste Runde:

https://twitter.com/PellyNV/status/702556025816125440

Also wenn man ihm Glauben schenkt verpennt Nvidia die Gelegenheit um AMD in die Parade zu fahren obwohl sie seit mindestens einer Woche wussten was auf Sie zukommt?! Das ist doch kein Nvidia Marketing.

Troyan

2016-02-24, 23:03:13

Habe ich (hier im Thread?) schonmal geschrieben. Der angebliche "Oxide"-Mann hat einfach gelogen. Die verfügbaren Treiber unterstützen kein Async Compute/Shader.

Schnoesel

2016-02-24, 23:05:54

Ist doch nicht deren Schuld wenn Sie keinen Treiber zur Verfügung stellen. Fakt ist in AoS ist es on, wenn der Treiber nicht mitspielt... Pech gehabt. Abgesehen davon kündigen sie es seit Monaten an also was ist los Nvidia?

Troyan

2016-02-24, 23:07:29

Darum ging es in dem Tweet doch garnicht. :lol:

deekey777

2016-02-24, 23:08:18

Allen bisher gemachten Erfahrungen nach und laut Aussagen von verschiedenen Entwicklern unterstützen sowohl Kepler als auch Maxwell kein Async Compute auf Hardwarebasis. Nvidia selbst will sich zu dem Thema derzeit nicht äußern – auch auf eine erneute Anfrage seitens ComputerBase nicht

http://www.computerbase.de/2016-02/ashes-of-the-singularity-directx-12-amd-nvidia/

Mal sehen, was von dem Tweet übrigbleibt.

Schnoesel

2016-02-24, 23:10:50

Wahrscheinlich kommt der nie ist seit September angekündigt... passiert is nix:

http://www.computerbase.de/2015-09/directx-12-nvidia-treiber-soll-async-compute-nachreichen/

Nakai

2016-02-24, 23:11:12

deekey777

2016-02-24, 23:17:55

Mal im Ernst?! So wie NV sich beim GTX970 3,5GB Gate geäußert hat und die Kunden willentlich verarscht hat indem man mehrmals versucht hat mit falschen Erklärungen die Kunden zu besänftigen, sollte man NV bei solchen Aussagen erstmal nicht mehr glauben. Und meine Ehre als Informatiker zwingt mich, dass ich mich auf die Seite eines Entwicklers stelle, anstatt eines Senior Product Manager. :freak:

Ahja...
Müssen wir das hier fortsetzen? Wenn Zwei sich streiten freut sich der Dritte definitiv nicht. Fakt ist, NV unterstützt es nicht. Punkt.
Ist doch nicht schlimm, wenn AS nicht unterstützt wird. Und wenn der größte Spieler AS nicht (zufriedenstellend) unterstützt, dann wird niemand extra für die Radeons AS implementieren. Und wenn der größte Spieler auf dem Markt von DirectX 12 nicht profitiert, wozu dann noch Kapazitäten dafür verschwenden. Und wenn ein Entwickler doch meint, DX12 zu verwenden, dann wird das Spiel schnell zu einem TWIMTP-Titel und bei DX11 bleiben.

Und was sind das bloß für dumme Entwickler, wenn das Spiel eine Option anzeigt, die die Hardware gar nicht unterstützt?

Achill

2016-02-24, 23:18:33

Eben hat d2kx gepostet, der AMD Radeon Crimson 16.2 Hotfix (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=571201) ist raus ... wenn heute auch noch der Beta2-Stand von AotS per Steam ausgerollt wird kann ich morgen ggf. ein paar FPS und Verbrauchwerte mit DX11 sowie DX12 AC:on/off liefern - ist aber nur grob per einfachen Wattmeter.

Wünsche für Settings?

Nakai

2016-02-24, 23:25:31

Ist doch nicht schlimm, wenn AS nicht unterstützt wird. Und wenn der größte Spieler AS nicht (zufriedenstellend) unterstützt, dann wird niemand extra für die Radeons AS implementieren. Und wenn der größte Spieler auf dem Markt von DirectX 12 nicht profitiert, wozu dann noch Kapazitäten dafür verschwenden. Und wenn ein Entwickler doch meint, DX12 zu verwenden, dann wird das Spiel schnell zu einem TWIMTP-Titel und bei DX11 bleiben.

Und was sind das bloß für dumme Entwickler, wenn das Spiel eine Option anzeigt, die die Hardware gar nicht unterstützt?

Ja, und die Entwickler massakrieren absichtlich/fahrlässig die DX12-Performance. Man erlaubt sich den großen Spieler nicht extra zu bevorzugen, indem man nur einen DX12-Path anbietet. Und dann skaliert der große Spieler deutlich schlechter unter DX12 mit schwacher CPU.
Eine Sauerei ist das...dieses Spiel ist nur ein DX12-Showcase-Benchmark und hat keinen richtigen Wert.

Wisst ihr was...ich bin jetzt frustriert, ich spiel jetzt Anno 2205.

Datarecovery09

2016-02-24, 23:25:35

Unterstützen nicht auch die Konsolen AC? Die meisten Spiele werden doch ohnehin primär für die Konsolen entwickelt und dann portiert. Gibt es da irgendeinen Grund, AC wieder abzuschalten wenn man schon auf DX12 setzt? Oder sehe ich da irgendwas falsch? o.O

Achill

2016-02-24, 23:25:36

Habe ich (hier im Thread?) schonmal geschrieben. Der angebliche "Oxide"-Mann hat einfach gelogen. Die verfügbaren Treiber unterstützen kein Async Compute/Shader.

Der Treiber meldet es aber - und darauf muss sich ein Entwickler verlassen. Wenn NV per Treiber dies nicht umsetzt, dann hat der Entwickler von Oxide trotzdem nicht gelogen.

Ansonsten "lügt" auch wccftech.com bzgl. AC in Fable Legends (http://wccftech.com/asynchronous-compute-investigated-in-fable-legends-dx12-benchmark/2/).

Ich gehe davon aus, dass NV bald einräumt und aufklärt, dass beim Marketing etwas missverstanden wurde und nicht AC sondern SC (Sync.Computing - das kann man auch leicht verwechseln) gemeint war - was überhaupt viel besser ist wie wir bald per GameWorks sehen werden. Es ist ja nicht so, dass dies nie mal passieren kann. Wir sind ja alle nur Menschen.

Troyan

2016-02-24, 23:37:32

blaidd

2016-02-24, 23:51:51

Nein, der Treiber meldet es nicht. Dies wurde von dem selben Typen veröffentlicht. War auch gelogen.

Es gibt kein "Melden" unter DX12. Im Gegensatz zu Vulkan - und auch hier ist es eigentlich falsch - ist das ganze ein logisches, API Konzept.

Wir richten uns nach dem Standard, einverstanden? Wenn beispielsweise in Fallout 4 auch auf den Konsolen Gameworks zum Einsatz kommt, dann kommt es auch in den PC-Benchmarks zum Einsatz... das halte ich für fair. Einen Vergleich mit Async On/Off müsste man natürlich zusätzlich machen (ähnlich GW), sofern das möglich ist.

Ehrlich, es tut mir aufrichtig leid; Ich habe alles versucht, was ich zu versuchen bereit bin - es hat keinen Zweck: Selbst ein Entgegenkommen kannst du nicht erkennen und es als solches honorieren. Ich bin eigentlich ein Idealist, aber ich muss ganz ehrlich mal kommentieren, dass ich dich auf die Menschheit bezogen für reichlich enttäuschend einschätzen würde... Bist du dir sicher, dass du dich hier rumtreiben sollest?

Troyan

2016-02-25, 00:05:22

Bist du besoffen? Erklärt dann auch die Fake-Benchmarks bei The Division...

Tessellation ist auch ein Standard. Mit welcher Begründung sollte man einen Standard in einem Spiel deaktivieren. :rolleyes:

Und wieso sollte das Vergleichen von Grafikkarten in PC-Spielen in Relevanz zu Konsolenversionen stehen?!

Nakai

2016-02-25, 00:11:43

Also ich bin besoffen. ;D

https://msdn.microsoft.com/de-de/library/windows/desktop/dn899217(v=vs.85).aspx#asynchronous_compute_and_graphics_example

Hier mal ein Link, den man gerne lesen kann.

Und dann noch einen, den man auch lesen kann.

http://ext3h.makegames.de/DX12_Compute.html

So? Gelesen?

Gut.

Tschüüühüüsss! :freak:

€: Ich wollte jetzt ins Anandtech-Forum gehen, aber da hat Sontin schon den Thread schließen lassen. Schade...was mach ich jetzt...ahja, trinken...stimmt

Fusion_Power

2016-02-25, 00:15:18

€: Auf langer Sicht wird DX12 sehr nett werden. Da können jetzt jegliche NVidianer erstmal frotzeln, da ihre geliebten GPUs gegenüber der Konkurrenz (fürs Erste) schlechter dastehen. DX12 bringt definitiv einige Vorteile.
Wie wird das dann mit der nächsten NVidia Generation, also Pascal im speziellen, ist das dann dort alles "gefixt" und funzt wie es soll oder hat man da auch gespart an DX12 Features?

Troyan

2016-02-25, 00:15:37

Locuza

2016-02-25, 00:20:47

Bist du dir sicher, dass du dich hier rumtreiben sollest?
Bist du dir sicher, dass du ihn füttern solltest?

Wie wird das dann mit der nächsten NVidia Generation, also Pascal im speziellen, ist das dann dort alles "gefixt" und funzt wie es soll oder hat man da auch gespart an DX12 Features?
Dazu haben wir keine gesicherten Informationen.
"Sparen" ist vielleicht auch das falsche Wort für Async Compute.
Es ist nicht unbedingt so, dass es der Königsweg ist und eine solche Implementierung sich für jede Architektur lohnt.
Ich denke bei Pascal wird sich im Prinzip nichts ändern, aber das context-switching wird schneller ablaufen, heißt wenn Kepler/Maxwell bei AsyncCompute-On noch ein wenig Performance verlieren, wird das vielleicht noch weniger oder gar nicht mehr auffallen.

Ich hätte gerne noch Intel-Ergebnisse an der Stelle, weil die haben auch keine parallele 3D + Compute Implementierung, dass Context-Switching soll aber angeblich sehr schnell funktionieren.

Nightspider

2016-02-25, 00:29:56

Falls Pascal auch keine ACEs haben wird, wird das eine Schlammschlacht biblischen Ausmaßes werden. ;D

Locuza

2016-02-25, 00:41:11

ACE ist ein AMD-Term.
Und praktisch interessiert es auch nicht, ob sie es supporten oder nicht, sondern was am Ende herauskommt.

Nakai

2016-02-25, 00:46:53

Und wie frage ich es in DX12 ab?!
Selbst mit Vulkan (http://vulkan.gpuinfo.org/displayreport.php?id=6) ist es nicht richtig, da dort zwar nur "eine" Familie gemeldet wird, aber von denen bis zu 16 Queues erzeugt werden können...

Wie das ganze dann auf die Hardware gemappt wird, ist doch für den Entwickler überhaupt nicht ersichtlich.

/edit: Hier von SashaW: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10948357&postcount=678

Selbstverständlich kann man bei NV mehrere Queues anlegen und selbstverständlich kann man bei NV auch AsyncCompute ausführen. DX12 hat nur Queues (3 Typen: Load/Store, Graphics und Compute), welche eben Commands annehmen. Man kann mehrere Queues erzeugen. Der Sinn hinter AsyncCompute ist, dass man parallel auf mehrere Queues Commands schedulen kann und diese nicht sequentiell ausführt und wartet (Fences, WaitEvents, Signals, etc.). Oftmals muss man eben warten, weil ein Shader eben auf Daten oder Ergebnisse eines anderen warten muss. AsyncCompute erlaubt nur, dass eben unabhängige Commands auch parallel ausgeführt werden können.

Wie das intern läuft, ist nochmal ein Stück anders. NV unterstützt nach Außen hin AsyncCompute, sonst würde es ja nicht funktionieren. Intern wird es wohl doch sequentiell (in NV Manier sub-optimal bzgl AsyncCompute) abgearbeitet werden. Für den Entwickler ist es eben nicht wirklich ersichtlich, bzw. er kann es schwer unterscheiden. Das Anwenden von AsyncCompute auf NV-Hardware erzeugt einen größeren Overhead (zweiter Link von vorhin).

-----------------

Ich glaube nicht, dass Pascal hier viel Erleichterung bringt. Es wird wohl definitiv einiges geändert und einige Probleme gefixt werden. Das Problem ist eher, dass NV seine Hardware bereits GUT auslastet. AMD braucht AsyncCompute, um seine Hardware GUT auszulasten.
Außerdem kommt es drauf an, wie man die GPUs eben füttern wird. AOS macht es sehr dynamisch und das schmeckt anscheinend GCN sehr gut. Bei NV muss man die Arbeit eher in Batches einteiln und dann auf die GPU schmeißen. Wenn man das GCN-Prinzip durchführt, tut es NV weh, und wir haben AOS-Symptome. Aber ich denke, man könnte noch mehr AsyncCompute verwenden und dann hat NV noch mehr Wehwehchen. Wenn man die Software eben dann auf NV eher auslegt, freut sich das NV-Mainzelmännchen und AMD kann seine Rohleistung wieder nicht ausspielen.

Tja...

€:
ACE ist ein AMD-Term.
Und praktisch interessiert es auch nicht, ob sie es supporten oder nicht, sondern was am Ende herauskommt.

Das Wort zum Donnerstag:

Wenn es eben auf der CommandoPipe sehr zähflüssig wird, dann kommt eben am Ende was...heraus
https://www.youtube.com/watch?v=B1aPeY4fLA8

horn 12

2016-02-25, 00:54:37

Statement meinerseits und bin schon wieder weg :-)

AMD war Ihrer Zeit eben Jahre Voraus und nun, nach langem Bangen und Beschimpfungen, des zu hohen Stromverbrauchs, des immer Lasternden 2-ten im GPU Sektor tragen die ersten Bäume die Früchte endlich nach Hause

Die nächsten Jahre werden spannend und Pascal wird wohl klein beigeben müssen!
Jener überarbeitete Maxwell wird dies nicht ausgebügelt bekommen!

Mal den Spieß umgekehrt, Bravo AMD!
Sie haben es sich ausnahmsweise auch mal redlich verdient, Mantle sei Dank!

War immer schon hinter AMD, auch und dies geben ich offen zu vielmal einfach zu extrem
Aber nun hoffe und glaube ich in die RICHTIGE und EFFIZIENTE DX12 - Vulkan (EX Mantle) Hardware investiert zu haben.
Preisenkungen bei NV wird es wohl in Bälde bei gewissene Grafikkarten geben und AMD sollte nun endlich IHR Marketing betreiben.

Raff

2016-02-25, 00:59:05

Man könnte auch sagen, dass die Scheduler in AMDs GCN-Hardware seit vier Jahren an der Software vorbeientwickelt werden. All die ACEs bringen erst unter Mantle, DX12 und Vulkan etwas. Nvidia bekommt es hingegen von Generation zu Generation besser und vor allem flächendeckender hin, die eigenen Rechenwerke auszulasten. Wie viel Treiber-Voodoo dafür notwendig ist und wieviel die Command-Prozessoren der GPUs davon stemmen, können wir nur erahnen.

Nichtsdestotrotz ist die Entwicklung sehr spannend und positiv für AMD. Das Jahr hält gewiss noch einige Überraschungen bereit. =)

Nebenbei bemerkt und durchaus interessant: In diesem Video sieht man (am Ende), dass Radeon und Geforce unterschiedliche Frames berechnen: http://www.pcgameshardware.de/Ashes-of-the-Singularity-Spiel-55338/Videos/Ashes-of-the-Singularity-Explicit-Multi-GPU-Video-1187231/ (alternativer Youtube-Link (https://www.youtube.com/watch?v=e2CwlY4B9-A))

MfG,
Raff

Troyan

2016-02-25, 01:05:15

Der Sinn hinter AsyncCompute ist, dass man parallel auf mehrere Queues Commands schedulen kann und diese nicht sequentiell ausführt und wartet (Fences, WaitEvents, Signals, etc.). Oftmals muss man eben warten, weil ein Shader eben auf Daten oder Ergebnisse eines anderen warten muss. AsyncCompute erlaubt nur, dass eben unabhängige Commands auch parallel ausgeführt werden können.

Async Compute funktioniert nur mit Synchronisierung richtig. Die muss also so oder so immer implementiert werden, um das richtige Ergebnis zu gewährleisten.

Das Anwenden von AsyncCompute auf NV-Hardware erzeugt einen größeren Overhead (zweiter Link von vorhin).

Das verstehe ich nicht und macht auch irgendwie kein Sinn. AMD kann laut Vulkan nur eine Grafik + Compute Queue. Der Overhead ist also minimal. Ich habe auch weder in den Beyond3d.com Benchmarks noch im Microsoft-Beispiel (AMDs Anpassung) eine Verschlechterung der Leistung feststellen können.

Nakai

2016-02-25, 01:10:11

Man könnte auch sagen, dass die Scheduler in AMDs GCN-Hardware seit vier Jahren an der Software vorbeientwickelt werden. All die ACEs bringen erst unter Mantle, DX12 und Vulkan etwas. Nvidia bekommt es hingegen von Generation zu Generation besser und vor allem flächendeckender hin, die eigenen Rechenwerke auszulasten. Wie viel Treiber-Voodoo dafür notwendig ist und wieviel die Command-Prozessoren der GPUs davon stemmen, können wir nur erahnen.

Nichtsdestotrotz ist die Entwicklung sehr spannend und positiv für AMD. Das Jahr hält gewiss noch einige Überraschungen bereit. =)

MfG,
Raff

Im Grunde sind die ACEs AMDs Pendant zu NVs CUDA Hyper-Q.
http://docs.nvidia.com/cuda/samples/6_Advanced/simpleHyperQ/doc/HyperQ.pdf

Aber Hyper-Q ist wohl nur für CUDA-Streams. Und die CUDA-Streams sind wohl nicht mit Vulkan oder DX12 kompatibel. Womöglich würde es doch funktionieren irgendwie, aber der Treiber hat wohl derzeit keine Funktionalität diesbezüglich. Falls es nicht geht => Pech.

spotz

2016-02-25, 01:10:38

Funktioniert bei DX12 das Multi GPU Verfahren mit auch IGPs? Wenn ja, wäre das für alle interessant, weil es ja kaum CPUs ohne IGP gibt. Gerade Laptops und All-in-Ones könnten davon profitieren, da sie in der Regel eher mit schwächeren GPUs ausgerüstet werden.

Ist es zu erwarten das die als "DX12 Featurekönig" gefeierte Skylake IGP dann besser abschneidet als AMDs APUs?

Troyan

2016-02-25, 01:13:51

Aber Hyper-Q ist wohl nur für CUDA-Streams. Und die CUDA-Streams sind wohl nicht mit Vulkan oder DX12 kompatibel. Womöglich würde es doch funktionieren irgendwie, aber der Treiber hat wohl derzeit keine Funktionalität diesbezüglich. Falls es nicht geht => Pech.

Doch, "Hyper-Q" ist es. Siehe den Thread im Beyond3d.com Forum. Computeworkload kann auf bis zu 32 Kernels ohne Leistungsverlust ausgeführt werden.

dildo4u

2016-02-25, 01:15:52

Funktioniert bei DX12 das Multi GPU Verfahren mit auch IGPs? Wenn ja, wäre das für alle interessant, weil es ja kaum CPUs ohne IGP gibt. Gerade Laptops und All-in-Ones könnten davon profitieren, da sie in der Regel eher mit schwächeren GPUs ausgerüstet werden.

Ja geht.

http://www.computerbase.de/2015-05/directx-12-mit-multiadapter-rendern-grafikkarte-und-igp-zusammen/

aufkrawall

2016-02-25, 01:19:24

Was da nicht steht ist, dass sich auch dabei, also nicht nur bei AFR, der Input Lag erhöht.

Nakai

2016-02-25, 01:54:55

Async Compute funktioniert nur mit Synchronisierung richtig. Die muss also so oder so immer implementiert werden, um das richtige Ergebnis zu gewährleisten.

AsyncCompute heißt nicht umsonst Async. Und klar muss man das Schedulen der einzelnen Commands synchronisieren und steuern.
Bei CUDA/OpenCL baut man Eventtrees der einzelnen Kernels auf und wenn eben was parallel ausgeführt werden, dann kann das die GPU auch tun. Man kann dementsprechend noch die CommandQueue mit "OutofOrder" konfigurieren, was ich bei DX12 jetzt nicht so gesehen habe.

Das verstehe ich nicht und macht auch irgendwie kein Sinn. AMD kann laut Vulkan nur eine Grafik + Compute Queue. Der Overhead ist also minimal. Ich habe auch weder in den Beyond3d.com Benchmarks noch im Microsoft-Beispiel (AMDs Anpassung) eine Verschlechterung der Leistung feststellen können.

Doch, "Hyper-Q" ist es. Siehe den Thread im Beyond3d.com Forum. Computeworkload kann auf bis zu 32 Kernels ohne Leistungsverlust ausgeführt werden.

Ich beantworte das zusammen.

Der GraphicsCommandProcessor und Hyper-Q-Block von NV sind nicht zusammen ansprechbar. Der GraphicsCommandProcessor und die ACEs von AMD anscheinend schon. Die CUs bei AMD können Wavefronts von den ACEs und dem CP gleichzeitig ausführen. Die SMs bei NV wohl eher nicht.
Wie das intern läuft, kA. Aber es scheint so, dass es einen getrennten Scheduler für den GraphicsCommandProcessor und dem CUDA-Block gibt.

SMX/SMM units can only execute either type of wavefront. A full L1, local shared memory and scheduler flush is required to switch mode. This is most likely due to using a single shard memory block to provide L1 and LSHM in compute mode.

dargo

2016-02-25, 07:39:15

Ist doch nicht schlimm, wenn AS nicht unterstützt wird. Und wenn der größte Spieler AS nicht (zufriedenstellend) unterstützt, dann wird niemand extra für die Radeons AS implementieren. Und wenn der größte Spieler auf dem Markt von DirectX 12 nicht profitiert, wozu dann noch Kapazitäten dafür verschwenden. Und wenn ein Entwickler doch meint, DX12 zu verwenden, dann wird das Spiel schnell zu einem TWIMTP-Titel und bei DX11 bleiben.

Du hast da einen kleinen Denkfehler. Erstens vergisst du dabei, dass mittlerweile über 40 Millionen (hab die genaue Zahl gerade nicht im Kopf) Konsolen AC-fähig sind. Und zweitens sind bereits ein paar AC Titel für den PC angekündigt, soviel zum Big Player. ;)

Man könnte auch sagen, dass die Scheduler in AMDs GCN-Hardware seit vier Jahren an der Software vorbeientwickelt werden. All die ACEs bringen erst unter Mantle, DX12 und Vulkan etwas. Nvidia bekommt es hingegen von Generation zu Generation besser und vor allem flächendeckender hin, die eigenen Rechenwerke auszulasten.
Man könnte den Spieß auch umdrehen und sagen Nvidia tut nur das Nötigste und optimiert eigene Hardware auf eine Steinzeit-API. ;)

SpielerZwei

2016-02-25, 08:09:48

http://www.computerbase.de/2016-02/ashes-of-the-singularity-directx-12-amd-nvidia/
Begeistern kann am Ende dieses Mammutartikels auch das Zusammenspiel aus zwei Grafikkarten von verschiedenen Herstellern. Alle getesteten Kombinationen liefen auf Anhieb einwandfrei und ohne Fehler, störende Mikroruckler traten nicht auf.

(del)

2016-02-25, 08:10:37

Machen wir uns doch heute mal den Spaß und messen DX11 gegen DX12 (async on/off) als echte Leistungsaufnahme für die Grafikkarten und die CPU. Dann wissen wir mehr. Mein Chef spielt mit :)

Achill

2016-02-25, 08:22:45

Machen wir uns doch heute mal den Spaß und messen DX11 gegen DX12 (async on/off) als echte Leistungsaufnahme für die Grafikkarten und die CPU. Dann wissen wir mehr. Mein Chef spielt mit :)

:up:

Korvaun

2016-02-25, 08:35:23

Async compute sehe ich aktuell so:

NV Karten können das nicht in Hardware, der Treiber "kann" es aber. Befehle werden abgefangen und entsprechend umgesetzt das NV-Karten auch laufen. Bestenfalls ist die Performance dadurch wenig negativ beeinflusst.

AMD Karten können das in Hardware (und sind darauf hin designed). Performance steigt bestenfalls massiv an bei Benutztung von Async compute.

Für die aktuelle Generation wird bei NV wohl nicht mehr viel passieren bzgl. DX12/Async compute. Da wird halt Beschwichtigungs-PR gemacht bis Pascal kommt und dann ist wieder alles gut... Ganz abgesehen davon betrifft das 99.999% der Spiele nicht, bis sich das einigermaßen durchsetzt sind wir schon 1-2 HW-Generationen weiter.

HOT

2016-02-25, 08:40:02

Du hast da einen kleinen Denkfehler. Erstens vergisst du dabei, dass mittlerweile über 40 Millionen (hab die genaue Zahl gerade nicht im Kopf) Konsolen AC-fähig sind. Und zweitens sind bereits ein paar AC Titel für den PC angekündigt, soviel zum Big Player. ;)

Der größte Denkfehler ist, dass es lt. Computerbase kaum Leistung kostet, Ergo in künftigen Treiberversionen dieser "Abstand" dann auch verschwindet und AC schlicht kein Nachteil für NV ist, aber ein gewaltiger Vorteil für AMD. Ich bin mir sicher, dass AC ein Feature sein wird, was exzessiv genutzt werden wird, man darf da ja nicht mit Maxwell rechnen sondern muss künftige Grafikgenerationen mit einbeziehen - spätestens Volta dürfte von AC dann auch stark profitieren. Man baut doch ein sehr nützliches Feature nicht ein, nur weil ein Hersteller es verschlafen hat, daraus einen Vorteil ziehen zu können, das ist absurd.
Spannend wird, was QuantumBreak und GoW daraus machen (sowie Hitman und DeusEx).

Zudem möchte ich nochmals auf den CB-Test hinweisen und auf eine Tabelle verweisen, bei der AC deaktiviert wurde. Auch hier profitieren die Radeons mehr von DX12 als die Geforces. Es liegt also nicht nur an AC, sondern auch an Maxwell.

Man könnte den Spieß auch umdrehen und sagen Nvidia tut nur das Nötigste und optimiert eigene Hardware auf eine Steinzeit-API. ;)
Ich sags immer wieder, Maxwell ist eigentlich eine 11_0-Architektur, die mit heißer Nadel umgestrickt wurde. Features sind da, Leistung aber nicht. Irgendwo muss man halt Abstriche machen, nichts ist umsonst.

dargo

2016-02-25, 08:47:07

Für die aktuelle Generation wird bei NV wohl nicht mehr viel passieren bzgl. DX12/Async compute. Da wird halt Beschwichtigungs-PR gemacht bis Pascal kommt und dann ist wieder alles gut... Ganz abgesehen davon betrifft das 99.999% der Spiele nicht, bis sich das einigermaßen durchsetzt sind wir schon 1-2 HW-Generationen weiter.
Naja... ich würde eher davon ausgehen, dass die Masse eine Grafikkarte mindestens 3 Jahre behält. Ich kenne genug "08/15" User die das System 5 Jahre unberührt lassen. Die ganzen "Freak-Foren" sind da nicht wirklich repräsentativ. Zudem ist noch gar nicht bekannt ob Pascal AC in Hardware unterstützt. Schauen wir mal. :)

Hübie

2016-02-25, 08:47:34

Bullshit, HOT! Man kann jetzt genau so auf fehlende Hardware-Features von AMD herum reiten und behaupten es wäre nur für 11_0 gebaut worden. Wäre genau so falsch. :rolleyes: AC braucht man nicht zwangsläufig und bringt nicht immer einen echten Vorteil.

dargo

2016-02-25, 08:51:54

@Hübie.

Es geht ja bei low level nicht nur um AC. Mit LL gibt es kein Loch mehr im CPU-Limit bei AMD. Das war mir das wichtigste überhaupt endlich von der high level Seuche wegzukommen. Die AC-Vorteile sind erst später aufgefallen, ich sehe das als einen netten Bonus für GPU-Limits.

Hübie

2016-02-25, 09:00:10

Erzähl das manchen Experten hier :rolleyes: Manche denken dass DX12 aus AC besteht und es automatisch überall besser laufen muss.
Context switch wird vom Treiber initiiert. Was soll da groß "abgefangen" werden? :| Kommt jetzt die These dass compute shader auf der CPU ausgeführt werden? X-D

dargo

2016-02-25, 09:03:22

Erzähl das manchen Experten hier :rolleyes: Manche denken dass DX12 aus AC besteht und es automatisch überall besser laufen muss.

Naja... wenn ein Entwickler AC implementiert, warum sollte es auf GCN nicht besser laufen (das Design wurde darauf hin ausgelegt, besonders ab GCN 1.1)? Dann kann man sich den Aufwand doch gleich sparen.

Hübie

2016-02-25, 09:08:11

Es muss genug compute shader geben und da kann man eben nicht alles realisieren. Bei AotS wird u.a. die Einschlagskraft von Geschossen damit berechnet. Perfektes Szenario also, da viel parallele Rechenlast ohne Grafik aufkommt. Das sieht bei einem Shooter schon anders aus. Hier kann es genau so gut sein, dass es keinen Unterschied macht oder sogar mehr Zeit kostet da eine CU afaik nicht compute und graphics gleichzeitig ausführen kann und am Ende gesynct werden muss.

M4xw0lf

2016-02-25, 09:39:15

Machen wir uns doch heute mal den Spaß und messen DX11 gegen DX12 (async on/off) als echte Leistungsaufnahme für die Grafikkarten und die CPU. Dann wissen wir mehr. Mein Chef spielt mit :)
Sehr cool.

(del)

2016-02-25, 09:44:32

Sehr cool.
Ich messe sicherheitshalber nochmal nach, aber ihr werdet Euch durchaus wundern :P

iuno

2016-02-25, 09:53:30

Der größte Denkfehler ist, dass es lt. Computerbase kaum Leistung kostet, Ergo in künftigen Treiberversionen dieser "Abstand" dann auch verschwindet und AC schlicht kein Nachteil für NV ist, aber ein gewaltiger Vorteil für AMD. Ich bin mir sicher, dass AC ein Feature sein wird, was exzessiv genutzt werden wird, man darf da ja nicht mit Maxwell rechnen sondern muss künftige Grafikgenerationen mit einbeziehen - spätestens Volta dürfte von AC dann auch stark profitieren. Man baut doch ein sehr nützliches Feature nicht ein, nur weil ein Hersteller es verschlafen hat, daraus einen Vorteil ziehen zu können, das ist absurd.
Das ist nicht absurd, das ist der Markt. Es muss den Aufwand schon auch rechtfertigen und wenn nur ein kleiner Bruchteil aller Karten ueberhaupt profitieren koennen, tut es das wohl nicht.
Ich bin mir nichtmal sicher, ob bei den Konsolen mit ihren kleinen GPUs exzessiv AC genutzt (werden) wird.
Wie du sagst, muss man auch zukuenftige Karten einbeziehen. Wenn AMD ab Polaris den 'normalen' CP besser hinbekommt, 'braucht' man vielleicht gar kein AC mehr.
AotS sollte auch eher ein best-case Szenario fuer die Technik sein. Man muss da erstmal abwarten, bevor man sich ueberschwaenglich freut.

Machen wir uns doch heute mal den Spaß und messen DX11 gegen DX12 (async on/off) als echte Leistungsaufnahme für die Grafikkarten und die CPU. Dann wissen wir mehr. Mein Chef spielt mit :)
:up::up:

M4xw0lf

2016-02-25, 10:09:51

Ich messe sicherheitshalber nochmal nach, aber ihr werdet Euch durchaus wundern :P
Alter Teaserer. :freak:

Lurtz

2016-02-25, 10:11:09

Da Radeons und Geforces unter DX12 ja offensichtlich perfekt miteinander harmonieren:
Wäre es theoretisch denkbar eine Radeon mit Freesync-Display zu nutzen und ihr eine Geforce zur Seite zu stellen? :confused:
Oder funktioniert A-Sync unter den Bedingungen prinzipiell nicht?

Bist du besoffen? Erklärt dann auch die Fake-Benchmarks bei The Division...
Hilfe, nVidia ist im Rückstand ja noch ätzender als wenn sie vorne liegen.

(del)

2016-02-25, 10:11:24

Alter Teaserer. :freak:

Mein Name ist Igor T. Wallossek. Keiner wusste bisher, wofür dass T in meinem Namen steht. Aber Theo ist es schon mal nicht :D

Aber ich habe zumindest einen neuen Power-Virus entdeckt. So viel kann man schon mal verraten. Ich update meinen Artikel heute abend oder morgen früh. :)

Michalito

2016-02-25, 10:13:38

Man könnte den Spieß auch umdrehen und sagen Nvidia tut nur das Nötigste und optimiert eigene Hardware auf eine Steinzeit-API. ;)

Der Gaul springt halt nur so weit und hoch wie er muss...:frown: Aber da war NV ja nicht alleine, MS postulierte ja laut: Nejt, nix DX 12.. DX 11 perfekt für alle Zeiten. Und NV war noch nie Inovationstreiber. Umsomehr darf man AMD danken für Mut (Mantel) und Weitsicht (AS), trotz wirtschaftlicher Bedrängnis (wegen?). Egal, es gab hier im Thread diesen tollen Chessboard Artikel, ich finde ihn nur grade nicht..:redface:

Raff

2016-02-25, 10:20:00

Wen's interessiert, bei der PCGH gibt's nun eine Handvoll Werte mit einer Fury X + Anhängsel: http://www.pcgameshardware.de/Ashes-of-the-Singularity-Spiel-55338/Specials/Benchmark-Test-DirectX-12-1187073/#a2

Das endet nicht immer positiv – Physx lässt grüßen.

MfG,
Raff

iuno

2016-02-25, 10:20:16

Wäre es theoretisch denkbar eine Radeon mit Freesync-Display zu nutzen und ihr eine Geforce zur Seite zu stellen? :confused:
Oder funktioniert A-Sync unter den Bedingungen prinzipiell nicht?
Sehe keinen Grund, der das verhindern wuerde. Andersherum vielleicht, falls Nvidia es gleich wie mit PhysX macht (Radeon wird erkannt, G-Sync deaktiviert). So ein Vorgehen ist aber (nur mir?) noch nicht bekannt.

@Igor: Wie wurden eigentlich die mGPU Tests gemacht? Kann man im Spiel selbst einstellen, ob man SFR oder AFR will?
Dazu waere auch eine DX11 AFR Messung noch nett gewesen, gerade was die Frametimes betrifft

fondness

2016-02-25, 10:26:58

Nebenbei bemerkt, sind die 10% Leistungsgewinn in Ashes of the Singularity mit AsyncCompute eh noch bescheiden. PS4 Entwickler sprechen von 20-30%, die dadurch möglich waren.

Zettabit

2016-02-25, 10:27:58

M4xw0lf

2016-02-25, 10:28:22

Nebenbei bemerkt, sind die 10% Leistungsgewinn in Ashes of the Singularity mit AsyncCompute eh noch bescheiden. PS4 Entwickler sprechen von 20-30%, die dadurch möglich waren.
Bei einer Lighting-Berechnung, nicht insgesamt. ;)

dargo

2016-02-25, 10:29:12

Es muss genug compute shader geben und da kann man eben nicht alles realisieren. Bei AotS wird u.a. die Einschlagskraft von Geschossen damit berechnet. Perfektes Szenario also, da viel parallele Rechenlast ohne Grafik aufkommt. Das sieht bei einem Shooter schon anders aus.
Ich als Laie verstehe die eine AMD-Folie wo es um AC-Vorteile von bis zu +46% ging anders. Dort ging es um Post-Processing. Somit könnte man theoretisch in jedem Spiel AC nutzen.

M4xw0lf

2016-02-25, 10:29:35

Mein Name ist Igor T. Wallossek. Keiner wusste bisher, wofür dass T in meinem Namen steht. Aber Theo ist es schon mal nicht :D

Aber ich habe zumindest einen neuen Power-Virus entdeckt. So viel kann man schon mal verraten. Ich update meinen Artikel heute abend oder morgen früh. :)
Grarr :usad:

Menace

2016-02-25, 10:31:42

Naja, "Steinzeit"-API hin oder her - sie ist eben immer noch in >99% der in den letzten Jahren und aktuell erscheinenden Spielen verwendet.

Von daher ist die NVIDIA-Taktik sicherlich nicht die innovativste, aber eben die für den Kunden unterm Strich bessere.

Kommt wohl auf den Kunden an. Ich kaufte die Nano doch nicht für 1 Jahr. Als Supreme Commander Spieler wird wohl AotS bei mir eine höhere Gewichtung haben. Auch schon von Mantle habe ich profitiert (noch mit meiner alten Grafikkarte). Nein, ich sehe unterm Strich momentan kein Nachteil auf AMD gesetzt zu haben. Allerdings verallgemeinere ich auch nicht. :rolleyes:

AffenJack

2016-02-25, 10:33:03

dargo

2016-02-25, 10:34:41

Das ist nicht absurd, das ist der Markt. Es muss den Aufwand schon auch rechtfertigen und wenn nur ein kleiner Bruchteil aller Karten ueberhaupt profitieren koennen, tut es das wohl nicht.
Ich bin mir nichtmal sicher, ob bei den Konsolen mit ihren kleinen GPUs exzessiv AC genutzt (werden) wird.

Wenn ich mich gerade nicht ganz vertue haben die Konsolen 8 ACEs. Ein Tahiiti nur 2. Erst Hawaii/Grenada und Fiji haben 8 ACEs. Bitte korrigieren falls ich hier völlig wilde Zahlen in den Raum werfe. Ich müsste die wieder raussuchen. :redface:

iuno

2016-02-25, 10:42:13

Betonung auf genutzt :wink:
Dass sie es koennen, weiss ich auch. Ja, ich glaube sie haben mehr als Tahiti, wie viel genau weiss ich auch nicht auswendig*. Fiji hat aber tatsaechlich nur 4, also halb so viele wie Hawaii. Dafuer 2 HWS, wobei man (oder nur ich?)** nicht genau weiss, ob die jeweils aequivalent zu zwei ACEs sind oder was die sonst noch so koennen...

*edit: sollen wohl 2 bei der X1, 8 bei der PS4 sein
**edit2: das ist ganz neu, kenne die Seite nicht, aber bin immerhin nicht allein:
Each HWS can perform the work of two ACEs and they appear to be capable of additional (but as-yet unknown) work as well.
http://www.extremetech.com/gaming/223567-amd-clobbers-nvidia-in-updated-ashes-of-the-singularity-directx-12-benchmark

edit3: HWS, wofuer steht das ueberhaupt? hardware scheduler? Dazu habe ich mal was bzgl. amdgpu gelesen, hardware scheduling wird da glaube ich ab 4.4 oder 4.5 genutzt. Ob das damit zu tun hat, weiss ich allerdings nicht. Ehrlich gesagt weiss ich nicht, worum es da ueberhaupt geht, 3D oder OpenCL oder HSA? Muesste das mal raussuchen.

edit4 (:rolleyes:): bridgman und alex haben das im phoronix Forum kommentiert, offenbar geht es da um 3D und non-HSA compute. Wie gesagt weiss ich nicht, ob das mit HWS zu tun hat, thematisch passen wuerde es aber ja.

(del)

2016-02-25, 10:46:28

iuno

2016-02-25, 10:50:15

Naja, Stresstest = alle Threads komplett voll, Spiel = ? Ist die Angabe 56 Watt das Mittel ueber die Zeit von x Sekunden? Wie fallen die hoechsten peaks aus?

M4xw0lf

2016-02-25, 10:53:43

Zettabit

2016-02-25, 10:54:03

Kommt wohl auf den Kunden an. Ich kaufte die Nano doch nicht für 1 Jahr. Als Supreme Commander Spieler wird wohl AotS bei mir eine höhere Gewichtung haben. Auch schon von Mantle habe ich profitiert (noch mit meiner alten Grafikkarte). Nein, ich sehe unterm Strich momentan kein Nachteil auf AMD gesetzt zu haben. Allerdings verallgemeinere ich auch nicht. :rolleyes:
Natürlich gibt es Kunden, die davon profitieren, keine Frage. Aber sind das 5% der Kunden oder 90%? Und das ist der entscheidende Punkt.

Achill

2016-02-25, 10:55:20

Denkanstoß:
Eine CPU, die im Stresstest im gleichen Messaufbau mal eben so 174 Watt verkonsumiert, nimmt im UHD-Run mit Karte A nur schmale 56 Watt auf und soll laut Logs diese Karte zumindest ansatzweise trotzdem schon limitieren. Ein bisschen lustig, oder?

*kippelt auf den Stuhl nervös hin und her* ... ich hoffe das wird eher etwas heute abend als morgen früh ... ;)

Aber 174W bei der CPU ist doch gar nichts, mit dem bösen Prime95 möchte mein Hasi-E 334W (System) haben - und da sagt nochmal jemand nur meine 290X wären Kostverächter... Vun nix kütt nix.

(del)

2016-02-25, 11:02:11

dargo

2016-02-25, 11:06:00

iuno

2016-02-25, 11:06:13

Misst du oefters den CPU Verbrauch in Spielen mit? Was ist denn so das Max. was ein Spiel gezogen hat und welches war das?

(del)

2016-02-25, 11:08:23

Auf dieser CPU gehts schon mal locker über 100 Watt, aber sehr selten. 50-80 Watt im Durchschnitt sind normal. UHD ist meist etwas sparsamer, weil dann schon die GPUs richtig dicht machen.

Trotzdem ist die Leistungsaufnahme der CPU verglichen mit dem, was hier als so tolle CPU-Auslastung propagiert wird, irgendwie ein Witz. Messfehler schließe ich aus, weil die VR-Sensoren sehr ähnliche Werte ausgeben, leider aber nur in gröberen Interalklen. Deckt sich in der Summe aber fast auf +/- 2 Watt.

Godmode

2016-02-25, 11:17:09

174 Watt am i7 5930K @4.2 GHz (ohne Spannungswandlerverluste) bei Prime 95
30 Watt für die CPU bei einer GTX 980 und DirectX 11, das Spiel narrt uns doch irgendwo gewaltig. Dreimal gemessen. Toleranz immer <2%

In Prime 95 (der bösen Version) schaffte ich kurzzeitig mal über 400w auf dem 5960x. Ich habe das aber schnell wieder abgestellt, um das gute Stück nicht sofort zu verheizen.

Ich weiß nicht ob ich deine Teaser richtig interpretiere, aber mit DX12 und Async steigt bei AMD wohl der Stromverbrauch weiter an, inkl. der CPU, da beide Komponenten besser ausgelastet werden?

(del)

2016-02-25, 11:18:59

Also mein 5960X frisst bei 4.8 GHz und Prime keine 270 Watt (nur CPU). Die 400 Watt sind auch theoretisch kaum möglich :)

Godmode

2016-02-25, 11:21:23

Also mein 5960X frisst bei 4.8 GHz und Prime keine 270 Watt (nur CPU). Die 400 Watt sind auch theoretisch kaum möglich :)

Deiner braucht aber wohl auch keine 1,44v. ;D

(del)

2016-02-25, 11:22:47

Deiner braucht aber wohl auch keine 1,44v. ;D
Gott bewahre, solche CPUs gebe ich freiwillig zurück :P

Aber selbst bei 1,4 Volt komme ich nie an die 300er Marke. Nicht mal in die Nähe. Wie messt Ihr die 400 Watt?
Spannungswandler natürlich extra.

Achill

2016-02-25, 11:29:44

Ich glaube es kommt darauf an, wie viele Kerne und welche Rechenoperationen und Befehlssätze genutzt werden.

Ein paar Werte - nur grob am Stecker und inkl. NT Wirkungsgrad Abweichung - also nur Indizen:
- Super Pi mod1.5 XS im Balanced Power Mode: ~111W
- Super Pi mod1.5 XS im Highes Performance Mode: ~127W
- Prime95 Inplace-FFT, 1xCore: ~144-151W (schwankt)
- Prime95 Inplace-FFT, 6xCores: ~274W (stabil)
- Prime95 Small-FFT, 6xCores: ~314-334W (schwankt)

---
Edit: Ich nutze Prime95 in v28.5 - dort werden AVX Instruction auf allen Cores parallel abgesetzt, das ist der Worst-Case und man sollte bestimmt auch keine 24/7 damit testen lassen (Sichwort: Electromigration (https://en.wikipedia.org/wiki/Electromigration)).

(del)

2016-02-25, 11:35:52

Ziehe netzteilverluste, Mainboard und Gedöns + Spannungswandler für die CPU ab und du landest bei ca. 250 Watt (und weit weniger) :)

dargo

2016-02-25, 11:41:31

In Prime 95 (der bösen Version) schaffte ich kurzzeitig mal über 400w auf dem 5960x. Ich habe das aber schnell wieder abgestellt, um das gute Stück nicht sofort zu verheizen.

Was habt ihr für Heizöfen? :uconf3: Ich komme mit meinem Hassi 4C/8T @3,7Ghz gerade mal so über 70W mit AVX2. :freak:

(del)

2016-02-25, 11:48:15

Naja, ein Golf GTI braucht ja auch weniger als ein AMG S65 ;)

Achill

2016-02-25, 11:50:40

Was habt ihr für Heizöfen? :uconf3: Ich komme mit meinem Hassi 4C/8T @3,7Ghz gerade mal so über 70W mit AVX2. :freak:

Wie haben ja mehr 2 bzw. 4 Cores mehr. und die CPUs verhalten sich nicht anders als die GPUs wenn man sich vom Sweet-Spot entfernt / Spannung noch erhöht.

Mit 5820k@Defaults und den Small-FFT war bei mir irgendwas um die 160W für das System (mit einen kleineren NT).

Hübie

2016-02-25, 11:50:51

Ich als Laie verstehe die eine AMD-Folie wo es um AC-Vorteile von bis zu +46% ging anders. Dort ging es um Post-Processing. Somit könnte man theoretisch in jedem Spiel AC nutzen.

bis zu schließt eine große Menge ein ;) Aber ja. Man kann es grundlegend für eine ganze Menge PP verwenden. Wie geschrieben muss sich dies jedoch nicht in weniger Renderzeit niederschlagen. Dafür fehlt es aber eh noch an Praxiserfahrung.

Achill

2016-02-25, 11:53:12

AotS will hier in v0.82 mit 1x290X (Default) und den 5820k@4.4GHz unter 1080p@High ~311W im DX12-Benchmark haben.

dargo

2016-02-25, 11:55:55

bis zu schließt eine große Menge ein ;)
Schon klar, deshalb schreibe ich ja auch "bis zu", macht AMD übrigens auch. :)
http://2a6b40693c0c06c5a8e2-2c4d42d5d35878ad78a4c213fddee02c.r52.cf1.rackcdn.com/images/BIF22EISH_P8.878x0.Z-Z96KYq.jpg

Den höchsten Zugewinn erreicht man höchstwahrscheinlich dann eh nur im Worst Case für eine kurze Zeit. Wenn du dann einen Benchmark über längere Zeit fährst wird entsprechend durch Glättung der avgs. weniger rauskommen.

Godmode

2016-02-25, 12:54:23

Hat hier jemand eigentlich eine Idee, wie NV unter DX11 soviel mehr Durchsatz schafft?

M4xw0lf

2016-02-25, 12:59:23

Hat hier jemand eigentlich eine Idee, wie NV unter DX11 soviel mehr Durchsatz schafft?
Als AMD? Oder relativ zu was?

AnnoDADDY

2016-02-25, 13:02:21

In 4k wundert mich die dx12 schwäche von nvidia schon. In 1080p ist die ti bei pcgh ja noch bissl schneller mit dx12 im Vergleich zu dx11

Aber warum dieser Einbruch in höheren Auflösungen?!

Nakai

2016-02-25, 13:11:42

Wenn AMD mehr Leistung durch AsyncCompute schafft, weil Ressourcen nutzbar gemacht werden, dann wird es bei NV ziemlich umgekehrt sein.
Im Endeffekt werden bei AsyncCompute mehr parallele Commands auf dem GCP oder der ACE ausgelagert.

Beispiel mit AMDs ACEs:
Eine ACE kann pro Takt eine Workgroup erzeugen und eine Wavefront auf eine CU schedulen. Benutzt man zwei ACEs, dann wir das verdoppelt. Bei 3 ACEs dann verdreifacht. Der GCP wird wohl ähnlich arbeiten, aber natürlich für die unterschiedlichen Shadertypen. Wieviele Wavefronts der GCP pro Takt auf die CUs schmeißen kann, weiß ich nicht.

Ich vermute, dass NV pro Takt deutlich mehr von ihrem GCP aus schedulen kann. Vll hat NV hier eine skalierbare Lösung implementiert, welche mit den GCPs skaliert. Das kostet definitiv Ressourcen und zeigt schon auf, wieso NV deutlich weniger SPs in ihren Designs hat. NV benutzt deswegen wohl nur eine einzige Pipe zum Schedulen, in diesem Fall. NV hat wohl eine große Multiengine, welche die Daten von allen CommandQueues aus verwaltet. Womöglich muss man deutlich mehr Treiberarbeit hineinstecken, um die große Multiengine gezielt zu füttern.

Godmode

2016-02-25, 13:22:57

Als AMD? Oder relativ zu was?

Natürlich im Vergleich zu AMD, was sonst?

Wenn AMD mehr Leistung durch AsyncCompute schafft, weil Ressourcen nutzbar gemacht werden, dann wird es bei NV ziemlich umgekehrt sein.
Im Endeffekt werden bei AsyncCompute mehr parallele Commands auf dem GCP oder der ACE ausgelagert.

Beispiel mit AMDs ACEs:
Eine ACE kann pro Takt eine Workgroup erzeugen und eine Wavefront auf eine CU schedulen. Benutzt man zwei ACEs, dann wir das verdoppelt. Bei 3 ACEs dann verdreifacht. Der GCP wird wohl ähnlich arbeiten, aber natürlich für die unterschiedlichen Shadertypen. Wieviele Wavefronts der GCP pro Takt auf die CUs schmeißen kann, weiß ich nicht.

Ich vermute, dass NV pro Takt deutlich mehr von ihrem GCP aus schedulen kann. Vll hat NV hier eine skalierbare Lösung implementiert, welche mit den GCPs skaliert. Das kostet definitiv Ressourcen und zeigt schon auf, wieso NV deutlich weniger SPs in ihren Designs hat. NV benutzt deswegen wohl nur eine einzige Pipe zum Schedulen, in diesem Fall. NV hat wohl eine große Multiengine, welche die Daten von allen CommandQueues aus verwaltet. Womöglich muss man deutlich mehr Treiberarbeit hineinstecken, um die große Multiengine gezielt zu füttern.

OK, mein Gedanke war, dass NV die DX11 Calls abfängt und dann dafür mehrere CPU-Threads anlegt und diese eben parallel laufen lässt. Ich habe allerdings keine Ahnung, ob so etwas möglich ist und es hört sich auch ziemlich "hackig" an.

(del)

2016-02-25, 13:29:18

OK, mein Gedanke war, dass NV die DX11 Calls abfängt und dann dafür mehrere CPU-Threads anlegt und diese eben parallel laufen lässt. Ich habe allerdings keine Ahnung, ob so etwas möglich ist und es hört sich auch ziemlich "hackig" an.
Warum? Es ist sogar sehr wahrscheinlich. Ich habe das schon länger vermutet. So absurd ist das gar nicht :)
Es ist eigentlich das, was ich im Artikel immer als "Software-Emulation" bezeichnet habe. ;)

Godmode

2016-02-25, 13:32:17

http://media.redgamingtech.com/rgt-website/2015/05/cmd_buffer_behavior-dx11.jpg

Ich weiß eben nicht, ob man den Teil DirectX Driver einfach so zerhäckseln kann. Oder ist damit eh schon der Grafiktreiber gemeint, dann wäre das ganze kein Problem?

Du hast übrigens meine Frage nicht beantwortet: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10953857&postcount=1343

(del)

2016-02-25, 13:43:53

AffenJack

2016-02-25, 13:59:57

Die beantworte ich im Artikel :)

Ich habe bei der GTX 980 noch eine sehr merkwürdige Anomalie und bevor ich nichts mehrfach gegengetestet habe, sage ich schon mal gar nichts :)
Frage: Was ist effizienter? Mehrere teilausgelastete Kerne oder einige wenige, die am Anschlag laufen?

Teillast sollte effizienter sein, da dann der Takt und die Voltage runter kann und eine Steigerung dieser sich sehr stark auswirkt.

Godmode

2016-02-25, 14:11:23

iuno

2016-02-25, 14:12:28

Ich habe allerdings keine Ahnung, ob so etwas möglich ist und es hört sich auch ziemlich "hackig" an.
Ist 3D nicht immer "hacky"!? :P

@Igor: danke fuer die weiteren Tests! Was gestern schon angesprochen wurde mit dem Layout der Seite, sollte man bei euch aber echt mal zum Thema machen ;)

(del)

2016-02-25, 14:22:38

Ist 3D nicht immer "hacky"!? :P

@Igor: danke fuer die weiteren Tests! Was gestern schon angesprochen wurde mit dem Layout der Seite, sollte man bei euch aber echt mal zum Thema machen ;)

Tja.... bei Einzelgrafiken kann ich ja per Klick notfalls noch HiRes zwangsverlinken, aber aus den Galerien heraus geht leider nichts. Amis können manchmal echt gaga sein :D

So, jetzt muss ich doch noch mal den Interpreter umprogrammieren und die Leistungsaufnahme jeweils frameweise kumulieren und dann den einzelnen FPS der Verlaufskurve gegenüberstellen. Der Aufwand sollte sich wirklich lohnen. AffenJack bekommt außerdem ein Bienchen ;)

W4RO_DE

2016-02-25, 15:31:36

Kommt der Artikel noch heute? :)

Achill

2016-02-25, 15:34:20

Natürlich im Vergleich zu AMD, was sonst?

OK, mein Gedanke war, dass NV die DX11 Calls abfängt und dann dafür mehrere CPU-Threads anlegt und diese eben parallel laufen lässt. Ich habe allerdings keine Ahnung, ob so etwas möglich ist und es hört sich auch ziemlich "hackig" an.

Ich hatte darüber auch schon nachgedacht. Meine Überlegung ging in eine etwas andere Richtung und gehen davon aus, das sich Funktionsaufrufe gegen die DX11 API i.d.R. synchron sind (keine Funktoren, Callbacks, ...) - man hat "einfachen" prozeduralen Code.

Folgende vereinfachte Annahme im Vorfeld: Ohne Optimierung kann eine GPU in einem bestimmten Szenario alle 16.6ms (~60fps) ein Bild komplett berechnen. Wird eine irgendwie geartete SW-Logik dazwischen gepackt, die Daten (deren Reinfolge oder Struktur) auf irgend eine Art und Weise optimiert, so erzeugt dies selbst erst einmal zusätzliche Latenz. Die Optimierung der Aufrufe/Daten selbst sollte aber die benötigte Zeit zum Rendern des Bildes reduzieren, damit entsteht ein einfaches Optimierungsproblem welches adaptiv an Lastszenarien anpassen lässt / sich selbst anpasst.

Unter dieser Annahme könnte ich mir folgende Ansätze vorstellen:

= Multi-Buffer / Pipeline-Architektur =
- Die spezifische Implementierung der DX11 Schnittstelle im Treiber wird entkoppelt.
- Es werden min. 3 oder mehr Puffer eingeführt (vereinfacht) und es wird eine akzeptable Latenz angenommen 1-2ms (wird später wieder raus geholt).
- Die Anwendung ruft über die Dx11 API Funktionen auf und übergibt Daten / Referenzen / Pointer auf diese. Diese Aufrufe laufen nicht "direkt" gegen die GPU sondern in einen ersten Puffer A. Bei einen bestimmten Kriterium (Zeit, Puffer voll, ...) wird das schreiben in den Puffer A gestoppt und der nächste Puffer B verwendet.
- Der Puffer A mit den Daten wird jetzt durch einen zweiten O-Thread (Optimize-Thread) optimiert / Treiberzeugs wird gemachte / ... bis wieder eine Grenze erreicht wird. In der Zwischenzeit wird Puffer B schon wieder mit Daten gefüllt.
- Puffer A mit den optimierten Daten wird jetzt an den 3. P-Thread (Prozess-Thread) "übergeben", Puffer B geht an den 0-Thread, Puffer C wird genutzt um Daten und Befehle von der Anwendung entgegen zu nehmen. Der P-Thread ruft jetzt interne Treiberlogik auf / sendet die Befehle an die GPU.

=> Das Ziel muss jetzt sein, dass die Kosten der Optimierungen dem Gewinn durch die bessere / kontinuierlichere Auslastung der GPU überwiegt:
1. Durch die Entkopplung der GPU läuft die Anwendung "schneller" bzw. es kommt nicht zur Situation das die GPU auf die Anwendung warten muss, falls etwas zwischen Render-Calls berechnet/vorbereitet wird.
2. Der O-Thread kann man nicht nur Daten anders Strukturieren/Zusammenfassen, man kann theor. auch Befehlsaufrufe um sortieren oder zurück halten - z.B. ist eine Textur noch nicht geladen / optimal verfügbar. Es ermöglicht auch ein gewissen vorschauendes Arbeiten (Shader compilieren, Texturen vorbereiten) - der PCIe Bus hat ja mehrere Lanes über die parallel mit der GPU kommuniziert werden kann... usw. usw.
3. Der P-Thread hat immer ein optimum an Arbeit vor sich und im Idealfall ist diese auch schon in optimaler Größe / Struktur vorliegend und das Werkzeug (GPU) ist auch schon Vorbereitet (z.B. Textur wurde parallel schon geladen)

Der O-Teil lässt sich natürlich beliebig vergrößern, dies kann man abhängig von den verfügbaren Ressourcen machen (RAM, Cores, Bandbreite).

Das ganze ist natürlich nur ganz Grob und ich bin nur Leihe auf dem Gebiet ... aber so würde ich anfangen. Hat man solche eine Pipeline-Archtiektur, dann kann man natürlich auch Stücke für bestimmte Engines/Speiel optimieren oder auch deaktivieren, wenn diese nichts bringen.

Ist mir auch nicht gerade eingefallen, Pipelines bzw. Event-Streams gibt es schon lange in der Enterprise-Welt.

Nightspider

2016-02-25, 16:18:30

Frage: Was ist effizienter? Mehrere teilausgelastete Kerne oder einige wenige, die am Anschlag laufen?

Diese Frage von dir. :O
Ich bin enttäuscht.

(del)

2016-02-25, 16:23:15

Diese Frage von dir. :O
Ich bin enttäuscht.
Es war eine rhetorische Frage, kein Nichtwissen :P
Nachdem mich alle wegen der Messungen löchern... Ich habe ja auch die CPU einzeln mit gemessen

Loeschzwerg

2016-02-25, 16:34:03

Wann wird denn die Beta 2 endlich für alle freigeschaltet? Async Compute wirkt sich sicherlich positiv auf den VIA Quadcore aus :D

Edit: Ok, scheint so als wird die "Beta 2" mit den ganzen Features aus den Presseberichten nicht öffentlich verfügbar sein... Ich könnte kotzen :(

Godmode

2016-02-25, 16:38:15

Ich hatte darüber auch schon nachgedacht....

Ja so in der Art hätte ich mir das auch vorgestellt.

Die Frage ist dann, warum hat das AMD bisher nicht gemacht? Zu wenig Manpower in der Softwareabteilung?

dargo

2016-02-25, 16:56:50

Die Frage ist dann, warum hast das AMD bisher nicht gemacht? Zu wenig Manpower in der Softwareabteilung?
Ich sag nur Mantle/Vulkan/DX12, AMD GPU Open. Da wurden sicherlich jede Menge Resourcen investiert. Verglichen mit NV was die Finanzen angeht, und somit sicherlich auch die Manpower hat AMD einiges auf die Beine gestellt. Wenn ich die jüngsten Zuwächse von DX12 inkl. AC so sehe kann ich die höchste Priorität bei low level durchaus nachvollziehen.

aufkrawall

2016-02-25, 17:01:04

Baker meinte ja auch, AoS wär nicht das Vorzeigespiel für Async Compute. :D
Wenn etwas technisch vergleichbares wie Uncharted 4 für den PC mit DX12/Vulkan kommt, kann AC in einigen Szenarien sicher noch mehr bringen.
Langfristig wird sich das für AMD ziemlich auszahlen.

dargo

2016-02-25, 17:02:57

Baker meinte ja auch, AoS wär nicht das Vorzeigespiel für Async Compute. :D

Das bestätigen auch die Benchmarks AC Off vs. AC On, wie schon fondness gesagt hat. :)

blaidd

2016-02-25, 17:03:42

Ok, scheint so als wird die "Beta 2" mit den ganzen Features aus den Presseberichten nicht öffentlich verfügbar sein... Ich könnte kotzen :(

Nope, sorry - ich kann nicht ganz nachvollziehen warum, aber eine ganze Reihe Features werden nicht veröffentlicht.

On February 25, 2016, we will be releasing Benchmark 2. Here’s what’s new: 1) Explicit Multi-GPU. You can now insert an additional video card into your PC and increase performance by up to 2x. Explicit Multi-GPU allows gamers to use an AMD card and an Nvidia card in the same system.
2) Significant general performance optimizations. 3) The addition of the game’s Substrate faction in the benchmark. 4) Increased the benchmark's overall load to test expanded gameplay features. 5) New graphics effects. 6) Advanced use of D3D12 multi queue and signaling mechanisms. This is often referred to as asynchronous compute.
The highlighted items are features not available in any public version. You are the first to see them.

Aus der Pressemitteilung.

Achill

2016-02-25, 17:07:04

Ja so in der Art hätte ich mir das auch vorgestellt.

Die Frage ist dann, warum hat das AMD bisher nicht gemacht? Zu wenig Manpower in der Softwareabteilung?

Zu wenig Manpower in der Softwareabteilung? Bestimmt, es gibt ja schon Unterschiede beim Budget und AMD beschäftigt sich nicht nur mit GPUs + Treiber - von daher ein Ressourcen-Problem im Sinne, was kann man sich aktuell Leisten und auch ein Recruiting-Problem, man bekommt ja keine SW-Engineers mit HW Wissen überall und sofort.

Ich weiß wie gesagt nicht wie nah / fern die Pipe-Idee von der Wirklichkeit ist. Fakt ist aber, dass ist eine Vereinfachung einer Vereinfachung einer Vereinfachung.

Ich denke das Handling des HW- und SW-Stacks, die Verarbeitung von Tausenden von Befehlen in wenigen Millisekunden, das Management der Hardware, die Implementierung der ganzen verschiedenen APIs, die Workarounds für Spiele - das ist einfach so Komplex, da kann man nicht schnell Optimieren sondern es bedarf geplanter Vorbereitung und Manpower für die Umsetzung.
Ich glaube sogar, dass NV bei der Übernahme von 3Dfx nicht nur auf der HW-Seite etwas gelernt hat (z.B. Rotated-Grid Super-Sampling) sondern meines Wissen war Glide ja schon ein abgespecktes und optimiertes OpenGL. Den Einblick wie "OpenGL in Schnell" oder ein anderer Treiber-Stack aussieht, dass können sehr wichtige Einsichten sein und ggf. schon damals bestimmte Wichen gestellt haben, die ohne dass man so weit planen konnte, sich durch Zufall viel später Auszahlen.

---
Edit: Im Endeffekt kann man es auch wie eine Wette sehen (Aufgrund der Komplexität) und jeder Herstelle setzt auf unterschiedliche Richtungen. Dann gibt es noch das liebe Geld für Marketing-Zwecke was definitiv in vielfacher und unterschiedlicher Weise eingesetzt wird - das passiert aber überall in der Industrie - wie haben hier als Spieler nur eine größere (subjektive) Wahrnehmung.

Loeschzwerg

2016-02-25, 17:09:29

Ich hab mir das Spiel nur wegen "Testerei" gekauft und dann so eine Aktion... Hätte heute gerne meine 750Ti zur Nano verfrachtet und danach die Nano zum VIA Quadcore :(

Achill

2016-02-25, 17:24:36

Ich hab mir das Spiel nur wegen "Testerei" gekauft und dann so eine Aktion... Hätte heute gerne meine 750Ti zur Nano verfrachtet und danach die Nano zum VIA Quadcore :(

Bezogen auf unsere Zeitzone UTC+1 können noch +15h vergehen (UTC-11) bis auch dort der 26.Feb beginnt - wenn ich nicht gerade etwas durch einander gebracht habe.

Gobale Presse-Infos ohne Zeitzone ist eigentlich ein NoGO ... ;)

Godmode

2016-02-25, 17:24:43

Ich sag nur Mantle/Vulkan/DX12, AMD GPU Open. Da wurden sicherlich jede Menge Resourcen investiert. Verglichen mit NV was die Finanzen angeht, und somit sicherlich auch die Manpower hat AMD einiges auf die Beine gestellt. Wenn ich die jüngsten Zuwächse von DX12 inkl. AC so sehe kann ich die höchste Priorität bei low level durchaus nachvollziehen.

Das waren definitiv einige Brocken, die sicherlich ordentlich Manpower gekostet haben. Die Früchte können sie leider erst jetzt mit Mantle/Vulkan/DX12 ernten. Wenn die Fury die selben DX11 Optimierungen hätte wie die Maxwell Karten, hätten die Reviews wohl deutlich anders ausgesehen. Im Nachhinein sehr schade für AMD, aber eventuell war das auch ihre Strategie, einfach alles auf die Zukunft zu setzen.

Zu wenig Manpower in der Softwareabteilung? Bestimmt, es gibt ja schon Unterschiede beim Budget und AMD beschäftigt sich nicht nur mit GPUs + Treiber - von daher ein Ressourcen-Problem im Sinne, was kann man sich aktuell Leisten und auch ein Recruiting-Problem, man bekommt ja keine SW-Engineers mit HW Wissen überall und sofort.

Ich weiß wie gesagt nicht wie nah / fern die Pipe-Idee von der Wirklichkeit ist. Fakt ist aber, dass ist eine Vereinfachung einer Vereinfachung einer Vereinfachung.

Ich denke das Handling des HW- und SW-Stacks, die Verarbeitung von Tausenden von Befehlen in wenigen Millisekunden, das Management der Hardware, die Implementierung der ganzen verschiedenen APIs, die Workarounds für Spiele - das ist einfach so Komplex, da kann man nicht schnell Optimieren sondern es bedarf geplanter Vorbereitung und Manpower für die Umsetzung.
Ich glaube sogar, dass NV bei der Übernahme von 3Dfx nicht nur auf der HW-Seite etwas gelernt hat (z.B. Rotated-Grid Super-Sampling) sondern meines Wissen war Glide ja schon ein abgespecktes und optimiertes OpenGL. Den Einblick wie "OpenGL in Schnell" oder ein anderer Treiber-Stack aussieht, dass können sehr wichtige Einsichten sein und ggf. schon damals bestimmte Wichen gestellt haben, die ohne dass man so weit planen konnte, sich durch Zufall viel später Auszahlen.

---
Edit: Im Endeffekt kann man es auch wie eine Wette sehen (Aufgrund der Komplexität) und jeder Herstelle setzt auf unterschiedliche Richtungen. Dann gibt es noch das liebe Geld für Marketing-Zwecke was definitiv in vielfacher und unterschiedlicher Weise eingesetzt wird - das passiert aber überall in der Industrie - wie haben hier als Spieler nur eine größere (subjektive) Wahrnehmung.

Ich sehe hier ebenfalls sehr viele Variablen und Abhängigkeiten und möchte wirklich nicht an einem Grafiktreiber arbeiten müssen. Dein Einwurf mit 3dfx ist interessant, allerdings würde ich mich es schon wundern, wenn Glide damals schon so fortschlich gewesen wäre?

Lowkey

2016-02-25, 17:32:46

AMD ist leider zu "zukunftssicher" ;)

Loeschzwerg

2016-02-25, 17:33:23

Bezogen auf unsere Zeitzone UTC+1 können noch +15h vergehen (UTC-11) bis auch dort der 26.Feb beginnt - wenn ich nicht gerade etwas durch einander gebracht habe.

Gobale Presse-Infos ohne Zeitzone ist eigentlich ein NoGO ... ;)

Es scheint doch noch was zu kommen :)

http://steamcommunity.com/app/228880/discussions/1/412448158142899134/
http://steamcommunity.com/app/228880/discussions/1/412448158146239200/

Achill

2016-02-25, 18:00:47

Dein Einwurf mit 3dfx ist interessant, allerdings würde ich mich es schon wundern, wenn Glide damals schon so fortschlich gewesen wäre?

Zitiert von der EN-Wiki:

Originally developed for arcade games that included non-Intel architectures, Glide was created to handle error prone tasks like chip initialization for the programmer, but implemented nothing more than what the Voodoo hardware was directly capable of. This strategy differed from that of other 3D APIs of the era (Direct3D, OpenGL, and QuickDraw 3D), which hid low-level hardware details behind an "abstraction layer", with the goal of providing application developers a standard, hardware-neutral interface.

The advantage of an abstraction layer is that game developers save programming effort and gain flexibility by writing their 3D rendering code once, for a single API, and the abstraction layer allows it to run on hardware from multiple manufacturers. This advantage is still in place today. However, in the early days of the 3D graphics card, Direct3D and OpenGL implementations were either non-existent or, at minimum, substantially less mature than today, and computers were much slower and had less memory. The abstraction layers' overhead crippled performance in practice. 3dfx had therefore created a strong advantage for itself by aggressively promoting Glide, which was designed specifically around the Voodoo hardware, and therefore did not suffer from the performance hit of a higher level abstraction layer.

While there were many games that used Glide, the killer application for Voodoo Graphics was the MiniGL driver developed to allow hardware acceleration of the game Quake by id Software. MiniGL implemented only the subset of OpenGL used by Quake.

By 2000, the improved performance of Direct3D and OpenGL on the average personal computer, coupled with the huge variety of new 3D cards on the market, the widespread support of these standard APIs by the game developer community and the closure of 3dfx, made Glide obsolete.

In wie fern es fortschrittlich war, dass kann ich gar nicht beurteilen, es war aber auf jeden Fall anders. Damit dann auch viel wichtiger der Einblick wie ein anderes Team / Firma ein Problem gelöst hat (SW+HW) und ggf. wurde dort eine bessere Strategie für bestimmte Aspekte gefunden.

Ist schon länger her, aber Ableitend von zeckensack's Aussagen hier im Forum (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=72690&highlight=3dfx) und auf seine Seite war der Glide-Wrapper (http://www.zeckensack.de/glide/) Aufgrund der 'Chroma Keying' Funktionalität bei der 3dfx HW erst mit PS (1.1?) auf ATI/NV HW möglich. Da ging bei 3dfx eine weile lang mehr als mit NV/ATI ... sie hatten nur (viel zu spät) 2D & HWTL bzw. war zu lange reine Beschleuniger-Karte geblieben.

Hübie

2016-02-25, 18:06:34

Ich denke nVidia bedient sich einfachen Tricks wie priority Scheduling, UMS und Manipulation vom dispatching. Hexen werden die nicht, aber wenn man den Aufwand entsprechend zielgerichtet betreibt (Spiel für Spiel, Engine für Engine), dann kann man damit schon einiges erreichen.

dildo4u

2016-02-25, 18:15:14

Wenn man's hart ausdrückt ist es nur ein Problem wenn Pascal das selbe Problem hat,die 970 ist eigentlich schon Asbach und dürfte im Sommer ersetzt werden.Meiner Meinung nach spielt das NV eher in die Hände,von der GPU Power her gibt es wenig Gründe aufzurüsten so lange man sein 1080p Screen nich ersetzt.Wie man ja bei der 3.5GB Geschichte gesehen hat ändern schlechte Nachrichten für NV wenig am Erfolg.Das ist alles in allem also gut für AMD und NV.

dargo

2016-02-25, 18:30:47

Ich sehe hier ebenfalls sehr viele Variablen und Abhängigkeiten und möchte wirklich nicht an einem Grafiktreiber arbeiten müssen.
Ich auch nicht. Vor allem wenn man an Windows 7/8.1 und 10 denkt. Dann hast du noch den ganzen Mist mit DX9 (mittlerweile relativ tot), DX10 (auch tot), DX11, Mantle (Wegweiser für Vulcan und DX12), jetzt Vulcan und DX12. Hier sind wir erstmal nur bei Windows. :crazy: Dann schreien einige nach Linux. Da wirst du kirre im Kopf. :usweet:

Achill

2016-02-25, 18:31:26

Ich konnte nicht widerstehen (Werte von Maxwell wären interessant): http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10954204#post10954204

Nakai

2016-02-25, 18:38:16

Wenn die Pascal-Entwicklung nicht zu früh abgeschlossen war.

Im Grunde gibt es kein Problem mit NV. NV macht es schon seit jeher gut genug. Ihre Architekturen sind deutlich effizienter bzgl Auslastung der SMs, sei es wegen Treiber oder Hardware.

-------------------
NV braucht DX12 deutlich weniger, weil...

...der Treiber eh schon deutlich effizienter ist, auch unter DX11.
...die Hardware eh schon besser ausgelastet wird, als es bei AMD der Fall ist.
-------------------
AMD profitiert doppelt von DX12, weil...

...der Treiberoverhead effektiv bekämpft wird.
...die Hardware durch AsyncC deutlich besser ausgelastet werden kann.
-------------------

Ich verstehe auch nicht, wieso jetzt soviele AMD hochjubeln und NV verschreien, bzw. wieso NV-Fanboys so rumschnattern. Die Karten die sie damals gekauft haben, waren damals auch gut. Dass NV ihre Hardware schnell fallen lässt, sollte eigentlich schon klar gewesen sein. Und falls AOS den DX12-Vorteil für AMD darlegt oder suggeriert, was noch lange nicht für jegliche DX12 Software gelten muss, dann können sich jegliche AMD-GPU-Besitzer freuen. Für DX12+AsyncC werden die SP-Zahlen deutlich vergleichbarer und ein Hawaii wird einem GM200 deutlich näher kommen, als bei DX11. Das macht einen GM200 nicht schlechter...nur bzgl der Preis-Leistung gegenüber der Konkurrenz.

Aber das gilt nur, falls DX12 für AMD ein Glücksgriff wird...

...ich erwarte, dass NV bei Pascal ihre DX12-Treiber ordentlich pimpt und mittels Gameworks sich mehr Vorteile erkauft. Ergo AMDler freut euch nicht zu früh. Womöglich sehen wir bald mehr Anno2205s.

€: Ahja, es ist dennoch ein ziemlicher guter Marketing-Zug für AMD geworden.

AffenJack

2016-02-25, 19:20:13

Scheint als wäre AMDs DX12 Treiber auch noch nicht völlig Bugfrei:
http://www.guru3d.com/articles-pages/ashes-of-singularity-directx-12-benchmark-ii-review,10.html

Die Engine rendert sonstwieviele FPS, aber ausgegeben wird bei AMD immer mit Vsync. Angeblich weil AMD "Direct Flip" noch nicht im Treiber aktiviert hat.

dargo

2016-02-25, 19:27:42

@Nakai

Ich kann mich nur wiederholen. Reine TFLOPs zwischen zwei verschiedenen Architekturen zu vergleichen war noch nie sinnvoll. Deine These kippt schon mit dem Vergleich GM200 vs. GK100. Hier stehen 5,6TFLOPs mit 2816SPs gegenüber 5TFLOPs mit 2880SPs. Das würde nach den TFLOP-Angaben bedeuten, dass GM200 nur 12% schneller wäre. Schau dir Benchmarks an. Wären es tatsächlich bloß 12% hätte sich NV Maxwell gleich sparen können. Nach den reinen Shadereinheiten zu gehen ist noch bekloppter. Zur einer gut ausbalancierten GPU gehört viel mehr als nur die Anzahl der SPs. Und wie man bei GCN sieht spielt eine moderne API auch eine sehr große Rolle.

Achill

2016-02-25, 19:44:02

Das AotS update auf Beta 2 ist auf Steam raus und wird gerade verteilt. ~1GB

---
Edit:

Scheint als wäre AMDs DX12 Treiber auch noch nicht völlig Bugfrei:
http://www.guru3d.com/articles-pages/ashes-of-singularity-directx-12-benchmark-ii-review,10.html

Die Engine rendert sonstwieviele FPS, aber ausgegeben wird bei AMD immer mit Vsync. Angeblich weil AMD "Direct Flip" noch nicht im Treiber aktiviert hat.

Das ist nicht OK aber klingt auch nicht weiter schlimm, ich würde das sogar als Feature haben wollen. Klingt nach VSync=Off Vorteil wie kleineren InputLag aber ohne Tearing ... ;)

(del)

2016-02-25, 19:48:25

Artikel kommt morgen früh, ich habe alle Ausreißer auf zwei anderen Systemen noch einmal getestet. Geändert hat sich jedoch an den Werten dann nichts, es ist eben so :D

Fieser Teaser (die restlichen Werte gibts kostenfrei morgen im Artikelupdate).
Die Werte ergeben sich aus der Summe der durchschnittlichen Leistungsaufnahme der Grafikkarte und der reinen CPU, geteilt durch die durchschnittlichen FPS pro Konstellation. Alles in fünf Durchläufen gemessen und gemittelt:

http://media.bestofmicro.com/X/5/562361/gallery/03-Efficiency-Watts-Per-FPS_w_600.png

Für die wenigen Abweichungen vom Schema-F zweier Karten gibt es morgen auch die Ursachenforschung :)

dargo

2016-02-25, 19:56:56

Dein Diagramm wird captain_drink nicht gefallen. ;)

(del)

2016-02-25, 19:59:15

Ich verrats mal:
Die 390X geht bis über 333 Watt. Ist wie Furmark, nur in echt (heiß) :P
Die Fury X klebt am Power Limit, ich habs in den Leistungsaufnahmekurven mal über die Frameratenverläufe gelegt.

Den ganzen Tag hatte ich die Heizung zu, die Dinger heizen wirklich wie die Pest :D

captain_drink

2016-02-25, 19:59:50

Dein Diagramm wird captain_drink nicht gefallen. ;)

Durchschnittliche Leistungsaufnahme der GPU und CPU.

Sollte sich die Effizienz der GPU tatsächlich steigern, werde ich allerdings in großes Lettern eingestehen: I stand corrected.

(del)

2016-02-25, 20:04:21

Durchschnittliche Leistungsaufnahme der GPU und CPU.
Sollte sich die Effizienz der GPU tatsächlich steigern, werde ich allerdings in großes Lettern eingestehen: I stand corrected.

Du kannst beides aber nicht trennen. Was nützt dir die auf den ersten Blick effizientere Karte, wenn es die CPU dann wieder verbollert?
Ihr bekommt die Leistungsaufnahmen auch als Diagramm, getrennt in CPU und GPU. In die Effizienz gehört aber nun mal die Summe :)
Zu deiner Beruhigung: wenn ich die CPU rausnehmen würde, wären die Reihenfolge und die Kernausaussagen immer noch gleich.

dildo4u

2016-02-25, 20:05:41

Das High Preset scheint den Geforce noch zu schmecken daher die relativ guten Werte.

Mit Crazy Settings läuft die 980 Ti besonders schlecht kaum vor der 980.

http://www.guru3d.com/articles_pages/ashes_of_singularity_directx_12_benchmark_ii_review,7.html

(del)

2016-02-25, 20:08:44

Mit Crazy Settings läuft die 980 Ti besonders schlecht kaum vor der 980.

WQHD ist doch Unfug. Was willst Du dann mit unspielbaren UHD-Frameraten anfangen? Das ist doch nur noch Standfußball. Irrelevant und extrem anfällig für Messfehler. Zumal ihr nicht vergessen dürft, dass es ein nicht-exklusives Fenster ist. Da reicht ein Pups auf dem Desktop und man misst was völlig anderes :D
Dass die GeForces gerade in WQHD ein Problem haben, steht auch in meinem Artikel. Denke mal an die Frametimes :)

M4xw0lf

2016-02-25, 20:09:21

dargo

2016-02-25, 20:11:07

Ich verrats mal:
Die 390X geht bis über 333 Watt. Ist wie Furmark, nur in echt (heiß) :P

Das die bei MSI und Grenada(XT) nicht alle Tassen im Schrank haben war mir schon länger klar. :D Was hat die 390X bei denen eigentlich für ein PT? 375W? :usweet:

Den ganzen Tag hatte ich die Heizung zu, die Dinger heizen wirklich wie die Pest :D
Dann hast du aber ne kalte Budde. Bei mir muss es draußen schon über -10°C sein, damit ich die Heizung leicht aufdrehen muss. :tongue:

Zumal ihr nicht vergessen dürft, dass es ein nicht-exklusives Fenster ist. Da reicht ein Pups auf dem Desktop und man misst was völlig anderes :D

Ei, ei, ei... immer diese verdammten, möglichen Fehlerquellen. X-D

(del)

2016-02-25, 20:11:41

Hmm, das Ergebnis der 390X ist schon eher unsexy :freak:
Gerade unter DX12, schade.KotzBrechstange eben

Das die bei MSI und Grenada(XT) nicht alle Tassen im Schrank haben war mir schon länger klar. :D Was hat die 390X bei denen eigentlich für ein PT? 375W? :usweet:
Dann hast du aber ne kalte Budde. Bei mir muss es draußen schon über -10°C sein, damit ich die Heizung leicht aufdrehen muss. :tongue:
Draußen sind hier gerade 0-1°C, es ist ein schönes Gründerzeithaus und die Decken sind nun mal nicht so niedrig wie in einer Betonhamsterbude. :)

(del)

2016-02-25, 20:14:15

Doppelpost, sorry :(

captain_drink

2016-02-25, 20:15:04

Du kannst beides aber nicht trennen. Was nützt dir die auf den ersten Blick effizientere Karte, wenn es die CPU dann wieder verbollert?
Ihr bekommt die Leistungsaufnahmen auch als Diagramm, getrennt in CPU und GPU. In die Effizienz gehört aber nun mal die Summe :)
Zu deiner Beruhigung: wenn ich die CPU rausnehmen würde, wären die Reihenfolge und die Kernausaussagen immer noch gleich.

Schon klar. Dargo bezog sich auf eine Diskussion zwischen mir und ihm, bei der er behauptete, dass Grenada bezüglich der Effizienz zur 970 mittels einer LL-API aufschließen könne, was ich bestritten habe, weil (so meine Argumentation) oberhalb des Sweetspots einer GPU die Leistungsaufnahme gegenüber der Leistung prozentual überproportional steigen müsse; und da Grenada ohnehin schon über dem Sweetspot liegt, müsse eine um x% erhöhte Leistung in einer höheren Leistungsaufnahme von x%+y% resultieren.

Knuddelbearli

2016-02-25, 20:22:59

Naja ist ja klar das die 390X da volle Kanne rausballert. Alle anderen Karten werden ja gedrosselt ( NV sowieso immer und Fury in dem Fall auch mal ) was automatisch bessere Effizienz bedeutet.

Denke mal mit Polaris wird AMD auch alle Karten auf Dauerdrossel bauen so wie NV, lohnt aus Effizienzsicht einfach, auch wenn es mir als Nutzer immer noch nicht gefällt. Dort wo ich die Leistung am meisten benötige ( Viele Effekte hohe Last und damit niedrige FPS ) wird dann auch noch der Takt reduziert. Klar kann man das dann mit einem FPS Limiter wieder gerade biegen aber das alles deutlicher Mehraufwand vorm Spielen ...

AffenJack

2016-02-25, 20:31:34

Für die wenigen Abweichungen vom Schema-F zweier Karten gibt es morgen auch die Ursachenforschung :)

Ich bin gespannt wie du die 390X und GTX980TI erklärst, denn die Werte sind schon etwas merkwürdig, insofern wir die gleichen Karten strange finden;-)

captain_drink

2016-02-25, 20:36:52

Alle anderen Karten werden ja gedrosselt ( NV sowieso immer und Fury in dem Fall auch mal ) was automatisch bessere Effizienz bedeutet

Mal wieder Zeit für urban legends i.V.m. Pauschalisierungen?
Zur Erinnerung: Die Referenz-Hawaiis haben kräftig gedrosselt, waren aber dennoch enorm ineffizient.
Powertune arbeitet bei Fury/Fury X und Grenada zudem sehr ähnlich, die höhere Effizienz der ersteren ist also keineswegs auf ein Runtertakten zurückzuführen.
Dass irgendeine Karte im Bench runtertaktet, wurde übrigens auch an keiner Stelle erwähnt, das sind allenfalls Vermutungen.

(del)

2016-02-25, 20:37:23

Schon klar. Dargo bezog sich auf eine Diskussion zwischen mir und ihm, bei der er behauptete, dass Grenada bezüglich der Effizienz zur 970 mittels einer LL-API aufschließen könne, was ich bestritten habe, weil (so meine Argumentation) oberhalb des Sweetspots einer GPU die Leistungsaufnahme gegenüber der Leistung prozentual überproportional steigen müsse; und da Grenada ohnehin schon über dem Sweetspot liegt, müsse eine um x% erhöhte Leistung in einer höheren Leistungsaufnahme von x%+y% resultieren.

Hawaii hat einen sehr merkwürdigen Hotspot, den man fast schon nicht mehr so nennen kann.
Selbst die deutlich niedriger getakteten Workstation-Karten verblasen im Verhältnis zur Performance noch extrem viel.
Man müsste deutlich mit der Spannung runter, was aber die Ausbeute sicher extrem einschränken würde.
Hawaii ist ein brutaler Grobmotoriker, da ist Fiji im Vergleich geradezu eine filigrane Elfe.
Wenn auch mit ordentlich Speckröllchen :P

Dass irgendeine Karte im Bench runtertaktet, wurde übrigens auch an keiner Stelle erwähnt, das sind allenfalls Vermutungen.
Dui wirst es morgen anhand der Leistungsaufnahmeverläufe sehen ;)

Ich bin gespannt wie du die 390X und GTX980TI erklärst, denn die Werte sind schon etwas merkwürdig, insofern wir die gleichen Karten strange finden;-)
Die 390X performt unter DirectX 11 ja schon mies, aber unter DirectX 12 ohne Async läuft sie kaum schneller, säuft dafür aber wie ein Bierkutscher
Dass die 980 Ti mit aktiviertem Async mehr aufnimmt, aber etwas langsamer läuft, ist die Regel. Die 980 non-Ti ist die eigentliche Ausnahme, aber die limitiert auch schon deutlich, so dass sich hier die Werte annähern.

Loeschzwerg

2016-02-25, 20:45:11

Wo befindet sich denn die Config von dem Spiel?

(del)

2016-02-25, 20:48:34

Wo befindet sich denn die Config von dem Spiel?

C:\Users\***deinname***\Documents\My Games\Ashes of the Singularity

Loeschzwerg

2016-02-25, 20:49:35

Dankscheee :)

Edit: Da liegt aber nix -.-*
Edit2: Geil, die Settings wird erst angelegt wenn man das Spiel normal gestartet hat, also nicht die DX12 Version ^^

(del)

2016-02-25, 20:55:09

Dankscheee :)
Edit: Da liegt aber nix -.-*
Du musst es mindestens einmal gestartet haben. Ist eine INI :)

AffenJack

2016-02-25, 20:58:22

Die 390X performt unter DirectX 11 ja schon mies, aber unter DirectX 12 ohne Async läuft sie kaum schneller, säuft dafür aber wie ein Bierkutscher
Dass die 980 Ti mit aktiviertem Async mehr aufnimmt, aber etwas langsamer läuft, ist die Regel. Die 980 non-Ti ist die eigentliche Ausnahme, aber die limitiert auch schon deutlich, so dass sich hier die Werte annähern.

Inwiefern kann man bei einem Bench von einer Regel sprechen?:wink:
Ich finde die 980 TI eher merkwürdig. Zumindest, dass sie unter DX12 ohne Async an Effizienz verliert finde ich komisch. Da ist die GTX980 für mich mehr nachvollziehbar. Die 390X schiesst natürlich den Vogel ab. Aber auch bei Fiji hätte ich erwartet, dass die Effizienz durch Async etwas steigt und nicht genau gleich bleibt.

(del)

2016-02-25, 21:09:38

Inwiefern kann man bei einem Bench von einer Regel sprechen?:wink:
Ich finde die 980 TI eher merkwürdig. Zumindest, dass sie unter DX12 ohne Async an Effizienz verliert finde ich komisch. Da ist die GTX980 für mich mehr nachvollziehbar. Die 390X schiesst natürlich den Vogel ab. Aber auch bei Fiji hätte ich erwartet, dass die Effizienz durch Async etwas steigt und nicht genau gleich bleibt.
Kürzerer Balken = höhere Effizienz :)

Die 980 Ti ist zwar ohne Asnyc etwas schneller, dafür ist die Leistungsaufnahme in beiden Fällen aber ähnlich.
Sie verhält sich also eher wie eine Fury X, profitiert aber nicht vom Asnyc-Feature, auch wenn sie dafür bezahlt.
Alles ab 980 abwärts rammelt dann eh ins Versagen, deshalb limitiert der Spaß ja auch. :)

Ätznatron

2016-02-25, 21:21:19

Die 390X geht bis über 333 Watt. Ist wie Furmark, nur in echt (heiß)

Dauerhaft, also ähnlich Furmark, oder nur als Spitzenwert?

Loeschzwerg

2016-02-25, 21:22:18

So schaut's mit dem Xeon und meiner Nano aus:
54928 AC on
54929 AC off

Radeon Software 16.2

Das Terrain flackert an ein paar Stellen bei den Kamerafahrten im Bench.

AffenJack

2016-02-25, 21:31:30

Kürzerer Balken = höhere Effizienz :)

Die 980 Ti ist zwar ohne Asnyc etwas schneller, dafür ist die Leistungsaufnahme in beiden Fällen aber ähnlich.
Sie verhält sich also eher wie eine Fury X, profitiert aber nicht vom Asnyc-Feature, auch wenn sie dafür bezahlt.
Alles ab 980 abwärts rammelt dann eh ins Versagen, deshalb limitiert der Spaß ja auch. :)

Ich rede auch erstmal vom DX11 zu DX12 Vergleich bei der 980TI. Meine Erwartung da war, weniger CPU Verbrauch, GPU Verbrauch gleichmäßig zu FPS hoch. Insgesamt etwas effizienter also. Bei der Fury sieht man den DX12 Vorteil leicht.

Achill

2016-02-25, 21:35:22

Ich habe eine ganze Weile versucht meine zwei 290X ans Laufen zu bekommen - leider geht es nicht. Sobald ich auf Benchmark klicke kommt kurz der schwarze Bildschirm für das Laden der Szene und dann ab auf den Desktop. Ich kann also nur etwas zum Verbrauch mit einer 290X sagen...

AotS v0.90 / 1080p / High
5820k@4.4GHz
290X@Default(1040/1300)

Avg.FPS: 59.9 fps
Verbrauch: 409 W (System)

@Format_C, habt ihr nur die 390X von MSI? Ausgehend von 88W Idle und ~130W Single-Core-Last sollte bei Multi-Core-Last (außer das wäre weniger als Single-Core) meine 290X bei 225-250W raus kommen. Oder das einfache Wattmeter misst totalen Mist ... :D

dargo

2016-02-25, 21:45:24

Hawaii hat einen sehr merkwürdigen Hotspot, den man fast schon nicht mehr so nennen kann.
Selbst die deutlich niedriger getakteten Workstation-Karten verblasen im Verhältnis zur Performance noch extrem viel.
Man müsste deutlich mit der Spannung runter, was aber die Ausbeute sicher extrem einschränken würde.
Hawaii ist ein brutaler Grobmotoriker, da ist Fiji im Vergleich geradezu eine filigrane Elfe.
Wenn auch mit ordentlich Speckröllchen :P

Machst du das wirklich gerade an einer MSI 390X die als Ziel 1100Mhz hat fest? Wie hoch ist die Defaultspannung der MSI?

(del)

2016-02-25, 21:49:43

Machst du das wirklich gerade an einer MSI 390X die als Ziel 1100Mhz hat fest? Wie hoch ist die Defaultspannung der MSI?Ich habe auch die entsprechenden FirePro. Die Effizienz ist nicht signifikant höher. Und ich liege jetzt im Bett. Fieber.

Achill

2016-02-25, 21:50:35

Machst du das wirklich gerade an einer MSI 390X die als Ziel 1100Mhz hat fest? Wie hoch ist die Defaultspannung der MSI?

Ich wollte das auch gerade schreiben - 1100 MHz ist viel zu weit weg vom SweetSpot und damit ist die Effizienz natürlich im Eimer.

---
Edit:
Ich habe auch die entsprechenden FirePro. Die Effizienz ist nicht signifikant höher. Und ich liege jetzt im Bett. Fieber.

;( ... dann mal gut Besserung!

M4xw0lf

2016-02-25, 21:54:26

Und ich liege jetzt im Bett. Fieber.
So schlimm hats geheizt, hmm? :freak:

Gute Besserung :)

dargo

2016-02-25, 21:55:16

Ich habe auch die entsprechenden FirePro. Die Effizienz ist nicht signifikant höher. Und ich liege jetzt im Bett. Fieber.
Ich kenne leider keine FirePros und mit welchen Defaultspannungen AMD dort hantiert. Gute Besserung auch von mir.

captain_drink

2016-02-25, 21:56:42

Ich wollte das auch gerade schreiben - 1100 MHz ist viel zu weit weg vom SweetSpot und damit ist die Effizienz natürlich im Eimer.

Auch 950 Mhz wären noch darüber. An der Proportionalität von Leistung und Leistungsaufnahme ändert sich durch den hohen Takt nichts, sie wird nur sichtbarer.

dargo

2016-02-25, 22:11:09

Auch 950 Mhz wären noch darüber. An der Proportionalität von Leistung und Leistungsaufnahme ändert sich durch den hohen Takt nichts, sie wird nur sichtbarer.
Was bitte? :freak:

Wenn ein Hawaii/Grenada als Ziel 1100Mhz hat, nicht durch sein PT gebremst wird und für diese 1100Mhz 1,25V braucht (rein fiktive Zahl) ist die Spannung bei 950Mhz um ein vielfaches niedriger. Das ist Powertune. Wie kann man da von gleicher Proportionalität zwischen Leistung und Leistungsaufnahme sprechen? Ich habe schon selbst mit meiner Karte gezeigt, dass 9% mehr Leistung in 22% mehr Leistungsaufnahme resultiert.

captain_drink

2016-02-25, 22:16:38

Was bitte? :freak:

Wenn ein Hawaii/Grenada als Ziel 1100Mhz hat, nicht durch sein PT gebremst wird und für diese 1100Mhz 1,25V braucht (rein fiktive Zahl) ist die Spannung bei 950Mhz um ein vielfaches niedriger. Das ist Powertune. Wie kann man da von gleicher Proportionalität zwischen Leistung und Leistungsaufnahme sprechen? Ich habe schon selbst mit meiner Karte gezeigt, dass 9% mehr Leistung in 22% mehr Leistungsaufnahme resultiert.

Mit "Proportionalität" meine ich, dass die Leistungsaufnahme stärker als die Leistung steigt.
Ausgehend von 900 Mhz (fiktive Werte ab jetzt) braucht man für +5% Leistung +6% Strom, für 10% dann 15% usw.
Die Leistungsaufnahme steigt oberhalb des Sweetspots überproportional, ganz gleich ob wir über 950 Mhz oder 1100 Mhz reden (sind beide darüber).

Achill

2016-02-25, 22:17:19

Ich kenne leider keine FirePros und mit welchen Defaultspannungen AMD dort hantiert. Gute Besserung auch von mir.

Die MSI Gaming zieht im Stresstest wirklich fast 400W (tomshardware.de) (http://www.tomshardware.de/amd-radeon-r9-390x-r9-380-r7-370-grafikkarten,testberichte-241836-11.html). Die MSI ist also für Effizienzbetrachtung nicht gut geeignet.

Die org. 290X genehmigt sich im Stresstest 225W (tomshardware.de) (http://www.tomshardware.de/radeon-r9-290x-hawaii-gpu-review-test,testberichte-241413-29.html) wenn nicht das PT erhöht wird (und dann das Temp.Target mit).

Auch 950 Mhz wären noch darüber. An der Proportionalität von Leistung und Leistungsaufnahme ändert sich durch den hohen Takt nichts, sie wird nur sichtbarer.

Nein es ist eben nicht linear, wie bei OC von CPUs, muss jedes Stückchen MHz mit immer mehr Verlustleistung bezahlt werden. Warum sonst braucht mein 5820k bei 3.3-3.6GHz max. 160W und bei 4.4GHz über 300W - wäre es Linear und die CPU würde mitspielen, dann müsste ich 6.6-7.2 GHz schaffen um mehr als 300W zu brauchen.

---
Edit:
Mit "Proportionalität" meine ich, dass die Leistungsaufnahme stärker als die Leistung steigt.
Ausgehend von 900 Mhz (fiktive Werte ab jetzt) braucht man für +5% Leistung +6% Strom, für 10% dann 15% usw.
Die Leistungsaufnahme steigt oberhalb des Sweetspots überproportional, ganz gleich ob wir über 950 Mhz oder 1100 Mhz reden (sind beide darüber).

Der richtige Terminus ist "Exponentielles Wachstum (https://de.wikipedia.org/wiki/Exponentielles_Wachstum)" - bitte nicht math. Begriffe neu definieren ;)

captain_drink

2016-02-25, 22:19:29

Proportionalität=/=Korrelation, siehe einen Post über dir.

Der richtige Terminus ist "Exponentielles Wachstum (https://de.wikipedia.org/wiki/Exponentielles_Wachstum)" - bitte nicht math. Begriffe neu definieren ;)

Die Terminologie stimmt schon. Die Proportionalität bleibt dieselbe, nämlich eine Überproportionalität oder eben eine exponentielle Zunahme.
"Proportionalität" ist das Hyperonym zu den drei Hyponymen: Über-, Unter- und Proportionalität.
Von Proportionalität noch mal zu unterscheiden ist wie gesagt die Korrelation, siehe: https://de.wikipedia.org/wiki/Korrelation#Mathematische_Darstellung

dargo

2016-02-25, 22:29:17

Mit "Proportionalität" meine ich, dass die Leistungsaufnahme stärker als die Leistung steigt.
Ausgehend von 900 Mhz (fiktive Werte ab jetzt) braucht man für +5% Leistung +6% Strom, für 10% dann 15% usw.
Die Leistungsaufnahme steigt oberhalb des Sweetspots überproportional, ganz gleich ob wir über 950 Mhz oder 1100 Mhz reden (sind beide darüber).
Das stimmt so nicht wenn wir unter Proportionalität (https://de.wikipedia.org/wiki/Proportionalit%C3%A4t) das gleiche verstehen.

Die MSI Gaming zieht im Stresstest wirklich fast 400W (tomshardware.de) (http://www.tomshardware.de/amd-radeon-r9-390x-r9-380-r7-370-grafikkarten,testberichte-241836-11.html). Die MSI ist also für Effizienzbetrachtung nicht gut geeignet.

Ah, danke. Da sind auch die Spannungen ersichtlich. Ich sehe zwar im Stresstest 368W. Dennoch erstaunlich was MSI bei der Karte so zulässt. :tongue: Wenn die Karte selbst im Stresstest die 1100Mhz hält müsste sie mindestens ein PT von 375W haben. :crazy:

dildo4u

2016-02-25, 22:47:30

Das Game wird übrigens grad bei Steam für 25€ angeboten.

HisN

2016-02-25, 23:04:59

Ah, heute war ja die Version auch endlich für die "breite Masse" verfügbar.
Ich hab mal den Test gemacht mit einer Titan X, der ich eine GTX750TI zur Seite gestellt habe.

Also irgendwie programmiert Stardock da ein Scheiss zusammen. Anstatt das Game zu beschleunigen hängt die 750TI bei 100% Last und bremst die Titan X auf 30% Auslastung runter. Die FPS sinken von 35-50 auf sieben.
Tolles Programm. Und das soll irgendwas über die Leistungsfähigkeit der Grafikkarten sagen? *g*
Ich dachte selbst eine IGPU beschleunigt das ganze?

http://abload.de/img/ashesqbkzp.jpg (http://abload.de/image.php?img=ashesqbkzp.jpg)

Na ich bin gespannt was die bis zum Release noch drann löten.

dildo4u

2016-02-25, 23:20:22

Könnte sein das der Vram der 750 vollläuft,solche einbrüche gibt auch mit der 260X.

http://www.pcgameshardware.de/Ashes-of-the-Singularity-Spiel-55338/Specials/Benchmark-Test-DirectX-12-1187073/#a2

Ätznatron

2016-02-25, 23:22:33

Ich hab mal den Test gemacht mit einer Titan X, der ich eine GTX750TI zur Seite gestellt habe.
....
Ich dachte selbst eine IGPU beschleunigt das ganze?

PCGH (http://www.pcgameshardware.de/Ashes-of-the-Singularity-Spiel-55338/Specials/Benchmark-Test-DirectX-12-1187073/) hat was zur Kombi starke + schwache GPU geschrieben:

Ergänzend zu den oben stehenden Werten haben wir einige Grafikkarten-Paarungen durch den Ashes-Benchmark gescheucht. Die Basis bildet eine Radeon R9 Fury X als schnellste Single-Karte in Ashes of the Singularity unter Direct 3D 12, welcher wir verschiedene Render-Partner zur Seite stellen. Wenig überraschend sind sowohl eine Radeon R9 390X als auch eine Geforce GTX Titan X in der Lage, der Fury X unter die Arme zu greifen und die Bildrate signifikant zu steigern - obwohl wir die Messungen lediglich in Full HD durchgeführt haben. Eine Radeon R7 260X hat neben dem AMD-Flaggschiff hingegen eine stark bremsende Wirkung. Doch sehen Sie selbst:

Dein Ergebnis sollte also nicht verwundern.

Knuddelbearli

2016-02-25, 23:31:00

Dass irgendeine Karte im Bench runtertaktet, wurde übrigens auch an keiner Stelle erwähnt, das sind allenfalls Vermutungen.

Ich verrats mal:
Die 390X geht bis über 333 Watt. Ist wie Furmark, nur in echt (heiß) :P
Die Fury X klebt am Power Limit, ich habs in den Leistungsaufnahmekurven mal über die Frameratenverläufe gelegt.

Und Referenz NV Karte kleben in 99% der Spiele am Powerlimit. Nur hat es NV geschickt gemacht und nennt es nicht drossel sondern boosten ... ist am ende aber nix anderes.

iuno

2016-02-25, 23:32:32

Also irgendwie programmiert Stardock da ein Scheiss zusammen. Anstatt das Game zu beschleunigen hängt die 750TI bei 100% Last und bremst die Titan X auf 30% Auslastung runter. Die FPS sinken von 35-50 auf sieben.
Tolles Programm. Und das soll irgendwas über die Leistungsfähigkeit der Grafikkarten sagen? *g*
Ich dachte selbst eine IGPU beschleunigt das ganze?
Bleib mal auf dem Teppich.
Alleine das zu glauben ist doch mehr als naiv. Wie soll bitte eine 750 oder gar eine iGPU bei so einem relativ konventionellen mGPU Verhalten eine Titan X beschleunigen?
Das ist theoretisch denkbar, wenn man den kleinen 'Krueppel' explizit auch Kleinkram zum Frass vorwirft, die die grosse GPU dann nicht machen muss und der dann auch garantiert rechtzeitig fertig wird. z.B. ein bisschen Post Processing, etwas physik/compute oder so.
Aber das ist Zukunftsmusik und natuerlich auch ungleich schwerer zu implementieren. Bei AotS wird nichts davon genannt und schon gar nicht versprochen. Da sind beide GPUs gleichberechtigte Arbeiter. Ob die kleine nun jeden 2. Frame machen muss oder von jedem Frame die Haelfte ist voellig egal*. Kannst du mir mal erklaeren wie in so einer Konstellation eine 750 immer zeitgleich mit einer Titan fertig werden soll? Nur weil man jetzt beliebige Karten mischen kann, hebt das doch nicht alles ausser Kraft was fuer mGPU gilt.

Igor ist uebrigens der Ansicht, dass gar kein SFR zum Einsatz kommt:
Das wird sich auch mit SFR nicht ändern, zumal ich fast glaube, dass man uns bei Ashes gerollt hat, und nur ein optimiertes AFR zum Einsatz kommt. Zumindest anhand der Log-Files sieht das fast so aus.

Peinlich ist, dass du den selben Kommentar unter den Test von PCGH packst, obwohl dort steht:
Wenig überraschend sind sowohl eine Radeon R9 390X als auch eine Geforce GTX Titan X in der Lage, der Fury X unter die Arme zu greifen und die Bildrate signifikant zu steigern - obwohl wir die Messungen lediglich in Full HD durchgeführt haben. Eine Radeon R7 260X hat neben dem AMD-Flaggschiff hingegen eine stark bremsende Wirkung.
Wo deine Erwartung herkommt kann ich also nicht im geringsten nachvollziehen.

dildo4u

2016-02-25, 23:37:15

Und Referenz NV Karte kleben in 99% der Spiele am Powerlimit. Nur hat es NV geschickt gemacht und nennt es nicht drossel sondern boosten ... ist am ende aber nix anderes.
Was ändert das an der absolut Miesen Effizienz der 390X?Gerade für AMD Fanboy's wird's brenzlig Bulldozer und 390X unter DX12 heißt maximale Auslastung und zerschossene Netzteile.Ein 8 Core + 390X kommt locker über 500 Watt.

Kartenlehrling

2016-02-25, 23:37:31

@HisN

Ist das nicht AFR was moment in der DX12 beta2 gezeigt wird und nicht SFR,
ausserdem gibts noch mutliGPU wo der APU bzw. iGPU bestimmte Aufgaben berechnen?!
Was wir hier im moment sehen ist doch nur SLI/Crossfire AFR mit gemischten Karten, somit zieht dein gtx750ti deine Titan runter.
Momentan wird nur zwischen Implicit Multiadapter und Explicit Multiadapter unterschieden, so habe ich das wenigsten verstanden.

Wenn sie SFR eingesetzt hätten wär kein >80% skalierung möglich, maximal 50-60%.

PCGH.de hat doch auch schon eine Fury+R7260x geteste und zum selben schlechten Ergebniss gekommen.
(http://www.pcgameshardware.de/Ashes-of-the-Singularity-Spiel-55338/Specials/Benchmark-Test-DirectX-12-1187073/)

Mortalvision

2016-02-26, 05:53:23

@dildo4u
Keine zerschossenen NTs. Solange kein OC gemacht wird, halten die Bauteile die atx spec ein.

dargo

2016-02-26, 06:40:41

(del)

2016-02-26, 07:19:10

Nur mal am Rande:
Wenn mir AMD und alle angeschlossenen Rundfunkanstalten (samt treuen Hörern) ständig in den Ohren liegen, die besseren der Werks-OC-Karten zu verwenden und aus dem grünen Nvidia-Privatfunk sehr ähnliches ziemlich laut tönt, dann sei es eben so. Mein Bildungsauftrag muss eben auch als Kompromiss die Befindlichkeiten des nichtzahlenden Publikums berücksichtigen, sonst gehen die dann womöglich Montags auch noch auf die Straße. Wer in Benchmarks den längsten Pimmel haben möchte, muss dann eben aber auch mit den Folgen leben können. Balken treffen sich immer mindestens zweimal im Leben :D

Hier mal als Happen Nummer Zwei für nachher die Leistungsaufnahme. Die Leistungsexplosion der R9 390X, die fraglich unter DX12 mit Async da ist, wird jedoch am Spannungsversorgungsanschluss teuer erkauft. Benchmark topp, Dose Flopp. War aber zu erwarten. Das meinte ich übrigens mit Powervirus, denn sogar eine W9100, die ja nun wirklich nach unten getrimmt ist (950 MHz), nuckelt genüsslich ca. 260 Watt weg. Mehr geht nicht, weil sie schon bei 93°C ist und zumacht (Referenzkühler). Das Folgende sind alles Durchschnittswerte, gemessen über die kompletten 180 Sekunden Benchmark (Datenhaufen per excellence):

http://media.bestofmicro.com/X/4/562360/original/01-GPU-Power-Consumption.png

Man beachte die Furx X (grün), die hektisch runter regelt und die R9 390X, die voll durchzieht, als gelte es, die Antarktis komplett abzutauen. Und ja, die Fury X kann den Takt NICHT halten, die 390X schon:

http://media.bestofmicro.com/W/S/562348/original/05-Performance-vs-GPU-Power-Consumption.png

Den Rest + CPU gibts dann gegen Klick :P

Übrigens:
Ich schriebs ja auch im Artikel und hattee die MGPU-Diagramme entsprechend auch (bewusst) so beschriftet: AFR. Das ist nie im Leben echtes SFR, denn Stardock ist ja noch so nett, im Log auszugeben, welche Karte welchen Frame gerendert hat. Je nachdem, welche bei unterschiedlich schnellen Karten die primäre ist, fällt auch das Ergebnis differnziert aus. Wird der Unterschied dann zu groß, kann gar nichts mehr ausgeglichen werden. Das ganze SFR-Gebrabbel im Vorfeld und den Marketingfolien ist meines Erachtens eher ein Fake und ein großer Bluff.

Nvidia setzt in Boost auf ein restriktives Power Target, das nicht überschritten werden kann, AMD bei Power Tune auf ein Power Limit, das erreicht werden kann, jedoch nicht so restriktiv ausfällt, dass es nicht stellenweise überschritten werden könnte. Was manche glauben, aus dem AMD-BIOS herauslesen zu können, ist eine Zielvorgabe, kein Limit. Die Firmware kann die VR nicht so schlagartig knebeln, wie es bei NV der Fall ist. Dazu müsste die Funktionalität des Arbitrators grundlegend geändert werden (siehe Nano), denn die VR lässt sich nur in Verbindung mit allen Sensoren und der Power Estimation Engine crashfrei auf Diät setzen. Das heißt also nicht nur anders, sondern funktioniert auch nicht gleich. :)

woodsdog

2016-02-26, 07:28:14

danke für die super Arbyte!

Locuza

2016-02-26, 08:18:30

Man beachte die Furx X (grün), die hektisch runter regelt und die R9 390X, die voll durchzieht, als gelte es, die Antarktis komplett abzutauen.
Ich liebe deine Ausdrucksweise. ;D

Übrigens:
Ich schriebs ja auch im Artikel und hattee die MGPU-Diagramme entsprechend auch (bewusst) so beschriftet: AFR. Das ist nie im Leben echtes SFR, denn Stardock ist ja noch so nett, im Log auszugeben, welche Karte welchen Frame gerendert hat. Je nachdem, welche bei unterschiedlich schnellen Karten die primäre ist, fällt auch das Ergebnis differnziert aus. Wird der Unterschied dann zu groß, kann gar nichts mehr ausgeglichen werden. Das ganze SFR-Gebrabbel im Vorfeld und den Marketingfolien ist meines Erachtens eher ein Fake und ein großer Bluff.

Ich denke es waren allgemeine Marketing-Folien zu SFR und anderen Möglichkeiten.

Robert Hallock als Marketing-Guy bei AMD sagt selber, dass Ashes AFR verwendet:
https://twitter.com/Thracks/status/702971430950932480

Und auch das bei SFR Speicher dupliziert werden muss:
https://twitter.com/Thracks/status/702971722006265856

Natürlich ist alles so grob, wie möglich gehalten.

(del)

2016-02-26, 08:46:02

Der Reviewers-Guide wurde mit SFR nur so vollgeballert. Wer keine Zeit hatte (die meisten), hat erst mal dran geglaubt :D

Volkstümlich:
SFR nutzt, auch wenn nur Tiles gerendert werden, sehr oft gemeinsame Ressourcen, denn Texturen. Matrialien und Meshs sind viele Paar Schuhe. Um etwas in Tiles zu zerlegen, kann man nicht einfach auch die (globalen) Ressourcen mit separieren und oft kopiert man dann lieber gleich mehr (oder alles), weil (a) das Aussortieren sinnlos lange dauert (sowie Fehler ermöglicht) und es (b) beim nächsten Tile sowieso gleich wieder gebraucht werden könnte.

Raytracer machen am Ende nichts anderes, da werden auch erst alle Ressourcen vorausgeladen und angelegt, um später einfach darauf verweisen zu können. Wenn ich ein Mesh rendere, brauche ich auch erst mal die Vertices samt den Materialverweisen (Textur, Oberflächeneigenschaften usw., die als Objekt auch extra vorher angelegt werden müssen), sowie die Texturkoordinaten. Dann erst wirfst Du das das eigentliche Mesh als Vertexlisten (nur Ressourcen-Verweise) hinterher und lässt es rendern.

Ätznatron

2016-02-26, 09:07:08

Bei bspw. der Fury korrelieren Leistung und Leistungsaufnahme, das Mehr an Leistung gibt's nicht für umsonst. Das kann ich irgendwie noch nachvollziehen.

Nvidia-Karten dagegen verlieren in DX12 (Async on) nicht nur an Leistung (CB-Test (http://www.computerbase.de/2016-02/ashes-of-the-singularity-directx-12-amd-nvidia/3/)), gleichzeitig sinkt deren Leistungsaufnahme.

Wie kann ich mir das als Laie vorstellen, werden da Teile der GPU lahmgelegt oder wie sonst kommt das zustande?

(del)

2016-02-26, 09:13:50

Da wird nichts "lahmgelegt" sondern nur nicht so ausgelastet. Schau doch mal auf meine Benchmarks (http://www.tomshardware.de/ashes-of-the-singularity-beta-2-directx-12-dx12-gaming,testberichte-242049.html) (schon veröffentlicht, gleich auf Seite 1 unten) und die Leistungsaufnahme (kommt noch, hier als Vorabgrafik auf Seite 72 (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10954595&postcount=1439)). CB misst nur Steckdose (bei NV mit gehandicapten Referenzkarten), da ist die CPU auch noch mit drin. Genau das habe ich allerdings in der Effizienbetrachtung auch, weil sich einiges nämlich wieder ausgleicht. Nur habe ich halt auch GPU und CPU der besseren Verständlichkeit wegen noch einmal getrennt, weil es zudem viel interessanter ist Warum sich sonst keiner die Mühe macht, werde ich wohl nie verstehen. :(

Ätznatron

2016-02-26, 09:23:20

Und woraus resultiert diese Nichtauslastung?

Denn gerade mit Async on erwarte ich doch eine bessere Auslastung und damit eine verbesserte Leistung.

edit:

Bei euch auf der Website (http://www.tomshardware.de/ashes-of-the-singularity-beta-2-directx-12-dx12-gaming,testberichte-242049.html) in den Kommentaren unter dem ausführlichen Test schreibt Tyler654:

Das Blatt wendet wendet sich unter DX12 scheinbar komplett, da Nvidia das Asynchronous Shading auf die CPU in Form einer Emulation auslagern muss.

Liegt er damit richtig?

iuno

2016-02-26, 09:36:08

Naja, so erschreckend finde ich die Ergebnisse nun nicht. Die MSI 390 ist mit einem PT jenseits von Gut und Boese ja als Stromfresser bekannt.
Es ist auch bekannt, dass das power gating prinzipiell funktioniert. Gut, bei Hawaii vielleicht noch nicht ganz so gut wie bei Fiji, aber dennoch. Dass dann bei besserer Auslastung die Leistungsaufnahme steigt, ist ja voellig klar.

Die MSI als 'schnellste' Karte zu testen, steht dir natuerlich frei. Ich denke aber dass eine andere Karte interessanter gewesen waere. Eben aus dem Grund, weil die MSI total aus dem Rahmen faellt. Dann waere die Leistung vielleicht etwas weniger gestiegen, die Leistungsaufnahme aber definitiv auch nicht in diesem Ausmasse. So bringt der Test imho nur die (alte) Erkenntnis, dass MSI der Karte zu viel goennt.
Sind FirePROs eigentlich was die Spannung ausgeht NOCH vorsichtiger eingestellt, als die Radeons? Bei nur 930 MHz ein PT von 275 Watt erscheint mir etwas viel. Und dass die Karte am Anschlag (Temp) arbeitet, macht sie auch nicht besonders effizient.

Was mich aber auch eher verwundert, ist dass die 980 Ti mit DX12 so viel zulegt, obwohl sie ja ueberhaupt nicht profitieren kann.

Test ist natuerlich sehr schoen, danke dafuer.
Und natuerlich gute Besserung :)

(del)

2016-02-26, 09:38:45

Und woraus resultiert diese Nichtauslastung?
Denn gerade mit Async on erwarte ich doch eine bessere Auslastung und damit eine verbesserte Leistung.
Genau das haben wir auf den letzten 72 Seiten doch bis zum Abkotzen ausdikutiert. NV kann es (aktuell) einfach nicht richtig nutzen.

So, der Artikel ist nun (vorerst komplett), ich verlinke noch mal drauf (gleich auf Seite 5):
[UPDATE] Ashes of the Singularity Beta 2: Acht Grafikkarten im DX12-Shootout (http://www.tomshardware.de/ashes-of-the-singularity-beta-2-directx-12-dx12-gaming,testberichte-242049.html#p5)

Edit:
Ich antworte nachher gern noch mal, aber sicher nur sporadisch.
Aktuell liege ich mit fast 40 Fieber und einer fiesen Grippe im Bett.
Das Surface neben mir, Tabletten in mir, Matratze unter mir und die Decke über mir.
Das Schafzimmer funktioniert als Boundary und ich brauche eine effizientere Kühlung.
Also mal einen Tag runtertakten und etwas ideln. :)

Ätznatron

2016-02-26, 09:45:32

Genau das haben wir auf den letzten 72 Seiten doch bis zum Abkotzen ausdikutiert. NV kann es (aktuell) einfach nicht richtig nutzen.

Erstmal gute Besserung und gute Erholung.

Und richtig, es ist lang und breit diskutiert worden, allerdings kontrovers und irgendwie ein bisschen ins Blaue hinein.

Jetzt endlich dank der Messergebnisse lichtet sich der Nebel.

dargo

2016-02-26, 09:48:22

Nur mal am Rande:
Wenn mir AMD und alle angeschlossenen Rundfunkanstalten (samt treuen Hörern) ständig in den Ohren liegen, die besseren der Werks-OC-Karten zu verwenden und aus dem grünen Nvidia-Privatfunk sehr ähnliches ziemlich laut tönt, dann sei es eben so. Mein Bildungsauftrag muss eben auch als Kompromiss die Befindlichkeiten des nichtzahlenden Publikums berücksichtigen, sonst gehen die dann womöglich Montags auch noch auf die Straße. Wer in Benchmarks den längsten Pimmel haben möchte, muss dann eben aber auch mit den Folgen leben können. Balken treffen sich immer mindestens zweimal im Leben :D

Hier mal als Happen Nummer Zwei für nachher die Leistungsaufnahme. Die Leistungsexplosion der R9 390X, die fraglich unter DX12 mit Async da ist, wird jedoch am Spannungsversorgungsanschluss teuer erkauft. Benchmark topp, Dose Flopp. War aber zu erwarten. Das meinte ich übrigens mit Powervirus, denn sogar eine W9100, die ja nun wirklich nach unten getrimmt ist (950 MHz), nuckelt genüsslich ca. 260 Watt weg. Mehr geht nicht, weil sie schon bei 93°C ist und zumacht (Referenzkühler). Das Folgende sind alles Durchschnittswerte, gemessen über die kompletten 180 Sekunden Benchmark (Datenhaufen per excellence):

http://media.bestofmicro.com/X/4/562360/original/01-GPU-Power-Consumption.png

Man beachte die Furx X (grün), die hektisch runter regelt und die R9 390X, die voll durchzieht, als gelte es, die Antarktis komplett abzutauen. Und ja, die Fury X kann den Takt NICHT halten, die 390X schon:

http://media.bestofmicro.com/W/S/562348/original/05-Performance-vs-GPU-Power-Consumption.png

Echt interesannte Ergebnisse zum Teil. Wenn ich die Frames in Relation zum Verbrauch unter DX12 +AC setze dann erreicht Fiji nahezu die Effizienz von GM200.

Nvidia setzt in Boost auf ein restriktives Power Target, das nicht überschritten werden kann, AMD bei Power Tune auf ein Power Limit, das erreicht werden kann, jedoch nicht so restriktiv ausfällt, dass es nicht stellenweise überschritten werden könnte. Was manche glauben, aus dem AMD-BIOS herauslesen zu können, ist eine Zielvorgabe, kein Limit. Die Firmware kann die VR nicht so schlagartig knebeln, wie es bei NV der Fall ist. Dazu müsste die Funktionalität des Arbitrators grundlegend geändert werden (siehe Nano), denn die VR lässt sich nur in Verbindung mit allen Sensoren und der Power Estimation Engine crashfrei auf Diät setzen. Das heißt also nicht nur anders, sondern funktioniert auch nicht gleich. :)
Jupp, das beobachte ich auch ständig bei meiner R9 R390. Im Schnitt bewegt sich die Karte bei 200W (Schwankungen zwischen ~185 und 220W) und selten wird dann auch eine kurze Spitze von 230W erreicht.

aufkrawall

2016-02-26, 09:50:09

Ich möcht mal dargos per PT gedrosselten Hawaii mit AC sehen, auf was für Taktraten der dann runtergeht.. ;D

dargo

2016-02-26, 09:58:54

Ich möcht mal dargos per PT gedrosselten Hawaii mit AC sehen, auf was für Taktraten der dann runtergeht.. ;D
Ich kann dir jetzt schon sagen mit -50mV >900Mhz, <950Mhz. Es wird für eine 970 OC oder eine Standard 980 bei den Frames reichen. ;) Du machst den gleichen Fehler wie manch anderer hier und leitest die Effizienz von Grenada von einem Heizofen @MSI 390X ab.

@Igor
Hast du noch eine Fury non X und Nano im Programm für deine Messungen?

iuno

2016-02-26, 10:02:03

Das solte er ja leicht liefern koennen ;)

edit: -50 mV zaehlt in dem Fall nicht. Ich auch haette gerne eine 'normale' Hawaii vermessen gehabt

aufkrawall

2016-02-26, 10:02:15

Ich kann dir jetzt schon sagen mit -50mV >900Mhz, <950Mhz. Es wird für eine 970 OC oder eine Standard 980 bei den Frames reichen. ;) Du machst den gleichen Fehler wie manch anderer hier und leitest die Effizienz von Grenada von einem Heizofen @MSI 390X ab.Was du nicht alles glaubst zu wissen...
Würdest du mit 1000rpm auskommen, würdest du ja auch nichts undervolten. Schon mal so rum betrachtet?

Igor, du lieferst wieder mal die interessantesten Ergebnisse. Thx.

Hübie

2016-02-26, 10:03:26

Im Gegenzug interessiert mich mal eine 980 Ti mit offenem PT und etwas Übertaktung (1450-1500) :D

aufkrawall

2016-02-26, 10:04:49

Du kannst den Mehrverbrauch bei guter Kühlung ja ziemlich linear mit dem Mehrtakt ausrechnen.

(del)

2016-02-26, 10:05:06

Grenada ist nur ein kosmetischer Tarnbegriff für Hawaii :P

Ich schrieb es glaube ich früher schon mal: meine MSI lässt sich fast um 100mV runterprügeln, dann sind 50 Watt weniger drin. Aber mein Bekannter im R&D meinte, dann müsste man alles selektieren, was aufwands- und damit auch kostenmäßig nicht mal im Ansatz drin ist. Das schwanke bezüglich der Qualitäten einfach wie die Pest. Die im finalen Produkt festgelegte Spannung ist in langen Testreihen ermittelt worden, um Grenada Hawaii überhaupt vom 200er Modell abheben zu können.

aufkrawall

2016-02-26, 10:07:36

Endlich springt mir mal jemand mit Hawaii = Grenada zur Seite. Sogar einer, der sich auskennt. :D

dargo

2016-02-26, 10:09:58

Was du nicht alles glaubst zu wissen...
Würdest du mit 1000rpm auskommen, würdest du ja auch nichts undervolten. Schon mal so rum betrachtet?

Natürlich würde ich undervolten, wozu soll die paar Megahertzchen verschenken? Im übrigen lies mal zwischen den Zeilen von Igor. Der hat schon einen kleinen Hinweis mit seiner W9100 mit schrottigen Kühler (950Mhz, 2816 Shader, 16GB Speicher) gegeben. ;)

Ich schrieb es glaube ich früher schon mal: meine MSI lässt sich fast um 100mV runterprügeln, dann sind 50 Watt weniger drin.
Dann schau mal nochmal nach wieviel weniger es mit -100mV und 950 oder 1000Mhz sind. ;) Sofern natürlich keine Grafikfehler auftauchen. Mit niedrigerem Takt verschiebt man etwas die nötige Spannung.

(del)

2016-02-26, 10:13:05

Endlich springt mir mal jemand mit Hawaii = Grenada zur Seite. Sogar einer, der sich auskennt. :D

Laut R&D ist kein Unterschied zwischen Grenada und Hawaii, man hätte den Trennstrich wohl ab einer bestimmten Batch gezogen, aber es wäre am Anfang nie sichergestellt gewesen, dass nicht auch "alte" Chips auf den 300ern landen. Verbesserte Produktion hin und her, es lägen so viele Chips auf Halde, dass man den Spannungs-Bogen sehr weit spannen muss, um möglichst alles loszuwerden. Der Unterschied zur 200er liegt neben dem höheren GPU-Takt vorrangig im höher getakteten RAM und dessen doppeltem Ausbau, was die Karten aber etwas teurer macht. Mit dem Chip selbst hat das nichts zu tun. Man kann ja sogar die Firmware problemlos hin und her flashen.

Gigabyte hat z.B. die AMD-Karten voll zurückgefahren und bemustert die 300er schon gar nicht mehr. Der Aufwand überstiege den Nutzen deutlich. Da hat der gute Mr. Eddie (der VGA Boss von GB) klare Regeln an Sales und PR ausgegeben.

horn 12

2016-02-26, 10:14:17

Bin auf den Test mit einer Fury, Fury Nitro oder Fury TRi-X gespannt.

(del)

2016-02-26, 10:17:30

Fury Tri-X und Nitro liegen knapp unter der FuryX, die Nano unter der 980 Ti und deutlich hinter der 390X (UHD). :)

aufkrawall

2016-02-26, 10:17:58

Der hat schon einen kleinen Hinweis mit seiner W9100 mit schrottigen Kühler (950Mhz, 2816 Shader, 16GB Speicher) gegeben. ;)

Du hältst dich ja mal wieder sehr wage. Was soll man Ergebnissen mit einer Karte entnehmen, deren Kühler einfach zu schwach ist?
Auf der MSI sitzt immerhin ordentlich Gewicht und die Lüfter können im Vergleich sicher auch wesentlich mehr Luft bewegen als so ein schäbiges DHE-Standarddesign, falls du da jetzt irgendeine Parallele herstellen wolltest.

Dann schau mal nochmal nach wieviel weniger es mit -100mV und 1000Mhz sind. ;) Sofern natürlich keine Grafikfehler auftauchen. Mit niedrigerem Takt verschiebt man etwas die nötige Spannung.
Wir wollten ja Kombustor testen, aber da hast du mich ja als ahnungsloser Depp hingestellt und dich dann entzogen...

Edit: Hab btw. erstmal Adblocker auf TomsHardware ausgemacht und ein bisschen Werbung geklickt.
Seitdem ich die Erweiterung FlashDisable nutze und Cookies blocke, spricht imho nichts mehr gegen so etwas.

(del)

2016-02-26, 10:23:09

...Was soll man Ergebnissen mit einer Karte entnehmen, deren Kühler einfach zu schwach ist?...

Das Einstellen der Lüfter auf 90% (voll ertrage ich auch mit meinen T90-Sofakissen nicht) lässt die W9100 auf 70-75°C runtergehen, was maximal 10 Watt spart und ca. 30-50 MHz mehr Takt im Mittelwert über alles ermöglicht. Bringt also nix Weltbewegendes. Um die Leckströme wirkungsvoll zu begrenzen, bräuchte man schon Temperaturen von deutlich unter 60°C.

dargo

2016-02-26, 10:24:35

Du hältst dich ja mal wieder sehr wage. Was soll man Ergebnissen mit einer Karte entnehmen, deren Kühler einfach zu schwach ist?

Sogar einiges... meine Karte operiert mit über 20°C weniger was paar Wattchen einspart, dann hat meine Karte den halben Speicher (W9100 1,5-1,6V, Grenada Pro 1,35V) was wieder ein paar Wattchen einspart, auch wenn nicht die vollen 16GB belegt sind. Meine Karte hat 9% weniger SPs. Dann undervoltet Igor nicht.

Wir wollten ja Kombustor testen, aber da hast du mich ja als ahnungsloser Depp hingestellt und dich dann entzogen...
Da gings hauptsächlich um deinen hirnrissigen Äpfel/Birnen-Vergleich mit 225W vs. 160W. Unglaublich, dass du das immer noch nicht gecheckt hast.

aufkrawall

2016-02-26, 10:25:31

Das Einstellen der Lüfter auf 90% (voll ertrage ich auch mit meinen T90-Sofakissen nicht) lässt die W9100 auf 70-75°C runtergehen, was maximal 10 Watt spart und ca. 30-50 MHz mehr Takt im Mittelwert über alles ermöglicht. Bringt also nix Weltbewegendes. Um die Leckströme wirkungsvoll zu begrenzen, bräuchte man schon Temperaturen von deutlich unter 60°C.
Ach so. Macht Sinn, da die TDP unterhalb der Consumer-Karten ist. Kleiner Denkfehler. :redface:

dargo, wir können im entsprechenden Thread testen, was du willst...

deekey777

2016-02-26, 10:39:37

Genau das haben wir auf den letzten 72 Seiten doch bis zum Abkotzen ausdikutiert. NV kann es (aktuell) einfach nicht richtig nutzen.

So, der Artikel ist nun (vorerst komplett), ich verlinke noch mal drauf (gleich auf Seite 5):
[UPDATE] Ashes of the Singularity Beta 2: Acht Grafikkarten im DX12-Shootout (http://www.tomshardware.de/ashes-of-the-singularity-beta-2-directx-12-dx12-gaming,testberichte-242049.html#p5)

Edit:
Ich antworte nachher gern noch mal, aber sicher nur sporadisch.
Aktuell liege ich mit fast 40 Fieber und einer fiesen Grippe im Bett.
Das Surface neben mir, Tabletten in mir, Matratze unter mir und die Decke über mir.
Das Schafzimmer funktioniert als Boundary und ich brauche eine effizientere Kühlung.
Also mal einen Tag runtertakten und etwas ideln. :)
Also...
Bei den "Beschwerden" kann man immer noch auf Tasten drücken und messen. ;D

Warum steigt die Leistungsaufnahme der Geforces bzw. der einen Geforce beim Wechsel auf DX12?

iuno

2016-02-26, 10:41:34

Endlich springt mir mal jemand mit Hawaii = Grenada zur Seite.
Wem ist das noch nicht seit der Vorstellung klar?

Was du nicht alles glaubst zu wissen...
Würdest du mit 1000rpm auskommen, würdest du ja auch nichts undervolten. Schon mal so rum betrachtet?
Naja, vielleicht schon. Ich habe inzwischen eine WaKue und habe es trotzdem bei -75 mV belassen. Warum? Warum nicht :D OC brauche ich momentan nicht, so ueberproportional wie die Leistungsaufnahme dann ansteigt.

Das Einstellen der Lüfter auf 90% (voll ertrage ich auch mit meinen T90-Sofakissen nicht) lässt die W9100 auf 70-75°C runtergehen, was maximal 10 Watt spart und ca. 30-50 MHz mehr Takt im Mittelwert über alles ermöglicht.
D.h. sie geht mit auto. Luefter < 900 MHz?!

Ach so. Macht Sinn, da die TDP unterhalb der Consumer-Karten ist. Kleiner Denkfehler. :redface:
Sicher? Ich finde 275 W PT sehr hoch bemessen fuer 930 MHz.

(del)

2016-02-26, 10:45:26

Also...
Bei den "Beschwerden" kann man immer noch auf Tasten drücken und messen. ;D
Die Konzentration leidet, man muss umbauen und am Ende ja auch noch Tonnen von Daten auswerten und in Charts pressen. FPS und Steckdose wären einfacher, stimmt. ich arbeite ja nicht zu Hause, da kann man nicht einfach mal Päuschen machen. Oder ich stelle hier mein besucherbett auf :P

Also...
Warum steigt die Leistungsaufnahme der Geforces bzw. der einen Geforce beim Wechsel auf DX12?

Weil der DX12 Renderpfad generell andere Features nutzt. AC ist doch nur eine Facette davon. Die 980 legt deshalb nicht zu, weil sie schon limitiert. Deshalb sind die kleineren Karten ja auch nicht mit dabei. Steht alles im Artikel. :)

aufkrawall

2016-02-26, 10:45:59

Sicher? Ich finde 275 W PT sehr hoch bemessen fuer 930 MHz.
Ich hatte noch keinen Kaffee...
Ist ja auch egal, war eh nur eine Randnotiz und man sollte sich hüten, vorschnelle Annahmen einfach so zu übertragen.

Undervolten ist wie OC ein Glücksspiel. Wenn dargo seine undervoltete Karte für allgemeine Vergleiche heranzieht, kann man auch übertaktete Maxwells hernehmen.
Die kann man btw. auch quasi ohne Bios undervolten, wenn man den Takt erhöht und das PT gleich lässt oder es weiter absenkt.

(del)

2016-02-26, 10:52:37

D.h. sie geht mit auto. Luefter < 900 MHz?!Bei entsprechender Shaderlast durchaus.

Ich habe längere Monte-Carlo-Berechnungen (Photovoltaik) laufen lassen, weil ich in meinem ersten Leben vor TH sowas programmiert habe. Da hat man z.B. die Einstrahlungsprognosen über 12 Monate und eine stundenweise Analyse mit Verschattungsberechnung, alles basierend auf NASA-Wetterdaten (langjähriges Mittel) und Referenzanlagen vor Ort (mehrjäjriges Mittel), sowie der 3D-Konstruktion einschließlich näherer Umgebung als Modell. Am Ende werden dann die passenden Module (Temperaturkoeffizienten, sonstige Kennlinien) noch zur Verschattung passend verstringt (bei Aufständerung auch Selbstverschattung berücksichtig) und die Wechselrichter ausgesucht/optimiert. Auf der 8-Kern CPU dauert eine Berechnung mehrere Stunden bis zu einem Tag. Die Karte ist schneller :P

M4xw0lf

2016-02-26, 10:57:18

Fury Tri-X und Nitro liegen knapp unter der FuryX, die Nano unter der 980 Ti und deutlich hinter der 390X (UHD). :)
Öha. Auch uncool. :(

Ätznatron

2016-02-26, 11:01:03

Öha. Auch uncool. :(

Wieso uncool?

iuno

2016-02-26, 11:01:10

Undervolten ist wie OC ein Glücksspiel. Wenn dargo seine undervoltete Karte für allgemeine Vergleiche heranzieht, kann man auch übertaktete Maxwells hernehmen.
Die kann man btw. auch quasi ohne Bios undervolten, wenn man den Takt erhöht und das PT gleich lässt oder es weiter absenkt.
Das ist klar und habe ich ja auch so gesagt.
Wenn das PT niedriger ist, regelt Maxwell bei gleichem Takt (!) und gleicher Last die Spannung runter?
Eine AMD laesst sich auch ohne BIOS Modding untervolten, allerdings ist das wegen der Idle-Spannung kritischer (bekommt den offset auch mit und faellt dann zu niedrig).

Bei entsprechender Shaderlast durchaus
Gut, das ist bei der Kuehlung klar. Ich meinte das jetzt eher auf das Spiel bezogen ;)

Loeschzwerg

2016-02-26, 11:02:10

Bei der Nano geht einfach nicht mehr, die läuft da vermutlich absolut im Limit. Muss man sich nur meine gestrigen Werte mit Async on/off anschauen. (Edit: Der Takt meines Xeon lag bei 2.5GHz)

StefanV

2016-02-26, 11:05:49

dargo

2016-02-26, 11:06:44

Eine AMD laesst sich auch ohne BIOS Modding untervolten, allerdings ist das wegen der Idle-Spannung kritischer (bekommt den offset auch mit und faellt dann zu niedrig).

Das ist nur bei Hawaii der Fall. Bei Grenada nicht mehr, oder ich habe ein ganz besonderes Exemplar. :tongue: Zumindest bei mir sind ~800mV kein Problem. Das könnte eventuell an dem überarbeiteten Speichercontroller liegen.

iuno

2016-02-26, 11:10:38

M4xw0lf

2016-02-26, 11:11:08

Wieso uncool?
Unter der Annahme, dass die Nano ein Stück effizienter ist als die Fury X, hätte ich mit mehr Leistung gerechnet.

Achill

2016-02-26, 11:13:23

Also bei 1080p und Extrem will das ganze System mit einer 290X Tri-X (1040/1300) bei mir am Stecker: 384-394W (Schwankt immer mal)

Die 290X hält den Takt die ganze Zeit, laut Ergebnis ist sie besser als die PowerColor 390 bei CB - kommt aber natürlich nicht an die 390X von MSI ran.

http://i.imgur.com/kmUBMkh.jpg

http://i.imgur.com/mjmrAr1.png

---
Edit: Falls es ggf. noch hilf sich ein besseres Bild zu machen, die ASCI-Qualität ist 79.4 (getestet) und 80.9.

Edit2: Es fehlt die GPU Spannung ... ich mach mal nochmal neu.
Edit3: AB kann ja gar keine Spannung Aufzeichnen - zumindest habe ich nicht die Option ... mach nochmal ein Lauf mit GPU-Z.

iuno

2016-02-26, 11:14:05

"ein Stueck" effizienter heisst aber nicht, dass bei einer gut 100 Watt niedrigerer angesetzten Schranke mal eben mehr Leistung rausspringen muss

woodsdog

2016-02-26, 11:14:42

krawall & dargo, könnt ihr bitte aufhören jetzt den 2. Thread (siehe 970er Problem Thread) mit der selben schwachsinnigen Diskussion vollzuschmieren?

nervt!

Ätznatron

2016-02-26, 11:14:56

Unter der Annahme, dass die Nano ein Stück effizienter ist als die Fury X, hätte ich mit mehr Leistung gerechnet.

Bist du sicher, dass da die Leistung gemeint war und nicht die Leistungsaufnahme?

dargo

2016-02-26, 11:24:59

Ja, womoeglich hat dein SC einfach prinzipiell mehr Spannung bekommen, bei Grenada ist der Speichertakt ja hoeher. Oder aber sie taktet im Idle den Speicher einfach nicht runter :P
Das ist in Grenada genauso der Fall. Es haengt halt von der Guete des Chips ab
Nö, das wäre mir schon längst aufgefallen. Natürlich taktet der Speicher mit 150Mhz.

Die 290X hält den Takt die ganze Zeit, laut Ergebnis ist sie besser als die PowerColor 390 bei CB - kommt aber natürlich nicht an die 390X von MSI ran.

Läuft die Powercolor bei CB ins PT-Limit oder hält sie den Takt ebenfalls?

(del)

2016-02-26, 11:27:38

krawall & dargo, könnt ihr bitte aufhören jetzt den 2. Thread (siehe 970er Problem Thread) mit der selben schwachsinnigen Diskussion vollzuschmieren?
nervt!

Ja, bitte mal in einen separaten Fred auslagern :)

dargo

2016-02-26, 11:53:03

krawall & dargo, könnt ihr bitte aufhören jetzt den 2. Thread (siehe 970er Problem Thread) mit der selben schwachsinnigen Diskussion vollzuschmieren?

nervt!
Gerne, aber manche Sachen kann ich nicht unkommentiert lassen. Er versteht einfach nicht, dass ein Grenada Pro auch "sparsam" sein kann. Die HiS R9 390 ist mehr oder weniger (SPs mal ausgeblendet) die Nano unter Fiji, zumindest wenn man die Karte mit einer MSI 390X vergleicht. Stattdessen werden einfach alle 390(X)-er in einen Topf geworfen und fertig.

aufkrawall

2016-02-26, 11:56:37

Das ist nur bei Hawaii der Fall. Bei Grenada nicht mehr, oder ich habe ein ganz besonderes Exemplar. :tongue: Zumindest bei mir sind ~800mV kein Problem. Das könnte eventuell an dem überarbeiteten Speichercontroller liegen.
Der Speichercontroller sitzt in der GPU und Igor hat hier doch gerade nochmal bestätigt, dass sich an dieser gar nichts geändert.
Wie kannst du trotzdem weiterhin so einen Müll behaupten?
Wenn sich etwas geändert hat, dann wahrscheinlich an der Timing-Konfiguration, weil die einfach, insbesondere bei Custom Designs, arschinstabil war.

Und jetzt geht das "Grenada"-Gefasel schon wieder los...

iuno

2016-02-26, 12:05:44

Die Timings stehen mit im BIOS und sind eher noch etwas schaerfer geworden. Deshalb gibt es auch Berichte von geflashten "Hawaii" auf "Grenada", die dadurch schneller geworden sein sollen.
Aber genug OT

aufkrawall

2016-02-26, 12:07:29

Ich bin auch gerne dafür, dass jeglicher Unfug über manuelle GPU-Optimierungen Einzelner hier nicht weiter diskutiert wird.

(del)

2016-02-26, 12:09:38

Man verbaut besseren, schnelleren und sogar sparsameren Speicher, that's all.

Kein Mensch hat so viel Geld (AMD schon mal gar nicht), um nochmal einen echten Refresh zu bringen. Klar kann man den Custom-Chip ("ASIC") auch im Nachhinein
nochmal ändern (Semi Custom Design), ist ja mit EDA einfach möglich und man muss nicht den gesamten Design-Flow noch einmal durchlaufen.
Aber um eine Layoutverification (ERC, DRC) wird man nicht drumrumkommen und ein erstes Tape-Out mit den neu anzufertigenden Masken produziert anfangs
meist auch erst einmal mehrheitlich Müll, obwohl man den Prozess ja schon kennt.

Grenada dürfte eine vom Marketing sehr erfolgreich (wie man hier ja so mitliest) gestreute urban legend sein und deshalb reicht es jetzt wirklich damit :P
(Und ja, auch ich habe Karten mit Nicht-Elpida RAM drauf selbst erfolgreich umgeflasht und nur die Speicherclocks etwas runtergedreht)

dargo

2016-02-26, 12:21:04

Der Speichercontroller sitzt in der GPU und Igor hat hier doch gerade nochmal bestätigt, dass sich an dieser gar nichts geändert.
Wie kannst du trotzdem weiterhin so einen Müll behaupten?

Und Igor hat die letzte Weißheit gefressen oder was? Du bist manchmal so ein Troll, dass es schon weh tut.
Auf Grund der fortgeschrittenen Fertigung, wenngleich in identischer Strukturbreite, und der Überarbeitungen am Speicher-Controller hat sich AMD für die neue Bezeichnung entschieden, kommuniziert diesen Umstand aber kaum in der Öffentlichkeit.
http://ht4u.net/reviews/2015/amd_radeon_r9_390x_-_hawaii_in_neuen_gewaendern/index6.php

aufkrawall

2016-02-26, 12:29:50

Na, wenn Peterle unkritisch aus PR-Folien abschreibt, ist sicher alles tip top...

Andron

2016-02-26, 12:37:07

Ich finde die Diskussion ziemlich lächerlich. Weder ist eine durchschnittliche 390 (X) so sparsam wie dargos stark optimierte His, noch so ineffizient wie die MSI aus dem THG Test. Die Wahrheit liegt irgendwo dazwischen.
Damit ist sie ineffizienter als die aktuellen Maxwells, kann aber auch auf 8 GB Vram zurückgreifen und profitiert unter DX12 (im Moment noch) stärker als die Nvidias.
Meine 390 Nitro läuft mit konstant 1050 MHz bei 1,1 Volt und Standard PT. Dabei wird sie in Spielen nie heißer als 70°C, ist nur leicht hörbar und im idle lautlos und sparsam.
Sobald AMD irgendwo mal glänzen kann wird die lächerliche "Verbrauchskeule" ausgepackt, selbst wenn die eigenen Komponenten bis zum Anschlag übertaktet sind.
Ich freue mich über die AMD-Ergebnisse in diesem Bench und hoffe, dass Nvidia treiberseitig noch etwas aufholen kann und wir demnächst einige Spiele mit den neuen APIs sehen werden.
Aber spätestens wenn die ersten FL12_1 Spiele kommen, werden wir von den üblichen Verdächtigen erzählt bekommen, wie schlecht AMD doch ist.

edit: Und unabhängig ob der Speichercontroller überarbeitet wurde oder nicht hat sich dass undervolting Verhalten zwischen Hawaii und Grenada zum positiven hin verändert.
Warum dass so ist macht ja für den Kunden keinen Unterschied,solange er Vorteile dadurch hat.

(del)

2016-02-26, 12:42:05

Und Igor hat die letzte Weißheit gefressen oder was?
Ich fresse weder Weisheiten, noch weiße Farbe, höre aber bei guten Gesprächspartner gern aufmerksam zu.
Ich bin heute allerdings im Gesicht sehr naturblass belassen, sieht irgendwie fürchterlich aus. Ich bin trotzdem nicht Igor, der Weiße. :)

Einer der R&D Guys meinte zur betreffenden Marketingfolie, man könne ja auch schlecht kommunizieren, was es so gar nicht nicht gäbe.
Der verfeinerte Prozess ließe mittlerweile aber per se auch höhere Taktraten und auch Spannungen zu, so dass man es einfach als was Neues verkauft.
Side-effects as typical PR food

Interessant ist nämlich auch, dass vorher nichts zum Testen kam (ES), sondern mit allem, was in den Factories noch da war,
einfach lustig weiter produziert und nur neu geflasht wurde. Mit den 8GB-Modellen hatte man ja vorher schon Erfahrungen gesammelt.

Screemer

2016-02-26, 12:47:23

In anderen threads wird ja schon bezweifelt ob sich ASC überhaupt "durchsetzen" wird, im gleichen Atemzug werden aber rovs und CR als sicherer Standard gesetzt. ist doch immer das gleiche. Sollten die neuen polaris letzteres nicht unterstützten, dann bin ich mir recht sicher wird es auch kein ASC auf pascal geben. Lassen wir uns überraschen

(del)

2016-02-26, 12:49:38

Es handelt sich um Asynchronous Shading UND Asynchronous Computing.
Und bei beiden hat Maxwell aktuell eine leichte Fistel im Dickdarm, so dass hinten weniger rauskommt und es den Fans etwas weh tut. :D
Ist aber sicher irgendwie lösbar. Operativ oder mittels Therapie. Doktor Jen-Hsun Huang wirds schon richten. Wenn nicht, dann die Lügenpresse :P
AMD hat es präventiv gleich ganz vermieden und von vornherein für mehr Durchfluss gesorgt :)

Kapiert doch endlich, dass es eine Machbarkeitsstudie und ein besserer Benchmark ist und nicht das Tagesangebot auf Steam & Co.
Bevor DirectX12 in allen Betriebskantinen angekommen ist, hat Deutschland 120 Millionen Einwohner :D

dargo

2016-02-26, 12:58:32

Einer der R&D Guys meinte zur betreffenden Marketingfolie, man könne ja auch schlecht kommunizieren, was es so gar nicht nicht gäbe.
Der verfeinerte Prozess ließe mittlerweile aber per se auch höhere Taktraten und auch Spannungen zu, so dass man es einfach als was Neues verkauft.
Side-effects as typical PR food

Egal was im Detail dort verändert wurde. Fakt ist, dass Grenada (das leite ich von meiner Karte ab) in Idle keine Probleme mit Undervolting mehr hat. Fakt ist auch, dass schärfere Timings gefahren werden. Für mich als User ist beides positiv zu bewerten.

iuno

2016-02-26, 12:59:29

Damit unterstellst du Nvidia aber, die GPUs nicht vollstaendig auslasten zu koennen. Es sieht aber doch genau nach dem Gegenteil aus.
Um auf deine Metapher einzugehen hat AMD eine verengte Oeffnung, aber praeventiv noch fuer mehrere kleinere Auslaesse gesorgt, sodass am Ende gleich viel im Topf landet wie mit einer ausreichend gross dimensionierten Oeffnung.

Achill

2016-02-26, 13:03:32