Ashes of the Singularity & Asynchronous Shader

[iuno]

Das Programm lastet die GPU aus, nicht der Hersteller.
Korrigiere: die Software. Es ist ja nicht nur ein Programm beteiligt.
Und ohne LL API geht da eben viel (fuer AMD zu viel) ueber die Treiber. Du willst ja wohl die offensichtlichen Unterschiede zw. AMD und Nvidia unter DX11 nicht abstreiten oder kleinreden?
"Entscheidend ist, was hinten rauskommt"
Da sind wir uns ja einig. Und das ist bei AMD die letzten Jahre eben trotz mehr Rohleistung oft zu wenig gewesen.

Fakt ist, dass Grenada (das leite ich von meiner Karte ab) in Idle keine Probleme mit Undervolting mehr hat.
Voellig falsch. Das ist kein Fakt, das ist eine Behauptung, die keiner hier beweisen kann.
Ich will dir aber nicht unterstellen, dass du das ohne Grundlage behauptest. Es mag ja sein, dass es bei dir so funktioniert. Es mag aber genauso auch 290er geben, die keine Probleme mit -50 mV im idle haben. Das ist voellig normal und hat einfach mit den Schwankungen der Qualitaet ueber alle Chips zu tun. Wenn dir bisher keine Probleme aufgefallen sind, muss das auch nicht heissen, dass es keine geben kann. Du sagst selber, dass in manchen Spielen -100 mV drin sind und in manchen nur -50. Das mag schlicht mit Lastwechseln und power states zu tun haben. Irgendwo droppt die Spannung dann halt mal zu tief. Wenn unter Volllast -100 mV gehen, bist du halt nicht am Limit ;)
Du willst wohl nicht verstehen, dass ein einzelnes Produkt nicht repraesentativ fuer eine ganze Palette sein kann.

[dargo]

Voellig falsch. Das ist kein Fakt, das ist eine Behauptung, die keiner hier beweisen kann.
Ich will dir aber nicht unterstellen, dass du das ohne Grundlage behauptest. Es mag ja sein, dass es bei dir so funktioniert. Es mag aber genauso auch 290er geben, die keine Probleme mit -50 mV im idle haben. Das ist voellig normal und hat einfach mit den Schwankungen der Qualitaet ueber alle Chips zu tun. Wenn dir bisher keine Probleme aufgefallen sind, muss das auch nicht heissen, dass es keine geben kann. Du sagst selber, dass in manchen Spielen -100 mV drin sind und in manchen nur -50. Das mag schlicht mit Lastwechseln und power states zu tun haben. Irgendwo droppt die Spannung dann halt mal zu tief. Wenn unter Volllast -100 mV gehen, bist du halt nicht am Limit ;)
Du willst wohl nicht verstehen, dass ein einzelnes Produkt nicht repraesentativ fuer eine ganze Palette sein kann.
Was hat jetzt nochmal die Idlespannung mit der Lastspannung im Zusammenhang zu tun? Ich habe gesagt, dass ich in Idle mit -100mV (was in ~800mV resultiert, genauen Wert kann ich dir sagen wenn ich wieder zu Hause bin) überhaupt keine Probleme habe. Mehr als -100mV gibt der Afterburner dann nicht mehr her.

[Achill]

Evtl. auch nochmal für alle die jetzt demnächt mit 375W bei Hawaii argumentieren. Anscheinen! gehen:
- 1040MHz mit 235-250W
- 1100MHz mit ~375W

Für +60MHZ (+7,8% OC zu 1040MHz) argumentieren wir, dass +~150W (+50% zu 250W) mehr ok ist - 7,8% zu 50% wo es schlussendlich dann nicht einmal 7,8% mehr FPS sind? Das dies nicht sinnvoll ist, für so wenig mehr an Performance so viel mehr an Leistung zu "zahlen", sollte allen klar sein.

@Format_C, danke für das Update mit den Stromverbrauchsmessungen - ich finde es super weil es zeigt, dass:
1. Die Fuji, wenn diese Ausgelastet werden kann, sehr gut darsteht
2. Die Maxwell immer ihr Power-Target ausschöpfen (220W MSI 970 Gaming ahoi)
3. Hawaii mit 1100MHz und/oder offenen PowerTarget (oder was auch immer) zu 375W führt, einfach nicht geht.

[iuno]

@dargo: du weisst aber auch, dass es mehr als 2 power states gibt?
Auch gut, dass du auf den Rest gar nicht eingegangen bist.

Ich verstehe sowieso nicht, warum du so auf dem Thema herumreitest. Was juckt es mich, ob meine karte 30 Watt mehr oder weniger verbraucht, wenn ich mit Leistung und Lautstaerke zufrieden bin. Ich freue mich auch, wenn ich eine gute Karte habe, schreibe aber nicht jeden Thread damit voll wie viel UV oder OC sie macht und schon gar nicht uebertrage ich das auf eine ganze Produktreihe, weil das bs ist.
Das nimmt ja inzwischen schon fast hornsche Zuege an, der auch in jedem Thread seinen Fiji abfeiert. Das ist auf Dauer einfach nervtoetend und langweilig und vor allem bringt es nichts.

Und jetzt ist es genug ot

@Achill: du misst ja 'nur' an der Steckdose oder? Wie hoch laesst du denn deine Hawaii normal takten?
Soweit ich weiss hast du Crossfire? Willst du das ganze mal noch mit mGPU vermessen? Mich wuerde interessieren, wie viel beide Karten ziehen, wenn die Skalierungsfaktor ja 'nur' bei 1,5 oder so liegt. Klar, mit DX12 sind Leistung und Verbrauch hoeher aber wenn sie dauernd auf die CPU oder die jeweils andere GPU warten muessen, sollten sie ja wieder etwas weniger verbrauchen. Das ist ja auch im Hinblick auf eine X2 interessant, falls denn noch eine kommen sollte.

[blaidd]

Ohmsches Gesetz:

U = R * I

Da der Widerstand mehr oder minder gleich bleibt, hast du bei doppelter Spannung auch den doppelten Strom, ergo geht die Spannung quadratisch ein.

Wobei Halbleiter (aka Silizium) hier wieder ein bisschen aus der Reihe tanzen und wie fast alles andere auch besser im Zusammenhang mit der Relativitästheorie betrachtet werden sollten ;)

[(del)]

Du willst ja wohl die offensichtlichen Unterschiede zw. AMD und Nvidia unter DX11 nicht abstreiten oder kleinreden?Zeige mir eine Zeile, wo ich das hätte. Der Overhead ist ja nicht neu, den gibts seit DirextX 5.
ATI hat ja, auch bevor es Unified-Shader gab, meist gern lange Wege bevorzugt.
Ich habe jahrelang so ein Zeug programmiert, mir sind die Unterschiede über die Jahre nicht entgangen.

Da wir das alles aber bereits wie ein Rudel Schlittenhunde bis zum Erbrechen der Früchstücksfische durchgehechelt haben
und es hier primär um DirectX 12 geht, ist DirectX 11 an dieser Stelle so interessant wie ein Eimer weißer Plakatfarbe am Norpol.

[captain_drink]

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.

Gerade der Umstand, dass Grenada (das lässt sich tatsächlich verallgemeinern) von Undervolting hinsichtlich der Effizienz profitiert, ist ein Beleg dafür, dass sich sowohl deine HiS wie auch die MSI oberhalb des Sweetspots befinden, so dass sich die Ergebnisse hinsichtlich der Überproportionalität von Leistungsaufnahme gg. Leistung für die letztere von Igor auf die erstere (mutatis mutandis) übertragen lassen, mithin auch die HiS die Effizienz einer 970 unter einer LL-API nicht erreichen kann. Was zu beweisen war.

[iuno]

Das sollte ja kein Angriff werden, sondern eine Frage
11 habe ich genannt, weil es schlicht zu 12 noch keine ernstzunehmenden Daten gibt, ausser eben von dem einen Spiel. Und da sehen wir schonmal, dass dadurch, die API zu wechseln, eben nicht ploetzlich *alles* besser wird. Da ist ja nichts neues. Und wenn die AMDs keine Reserven mehr haetten, wuerde der Wechsel auf 12 nichts bringen. Und haetten sie dann nicht immer noch Reserven, wuerde auch AC nichts mehr bringen.
Du hast aber unterstellt, dass Nvidias diese Reserven genauso haben, indem du die "Darm-Metapher" gebracht hast. Da aber schonmal der Wechsel auf die neue API mit schmalerem Treiber *hier* nichts bringt, ausser mehr Leistungsaufnahme, wollte ich das nur relativieren. Da Maxwell halt keine ACEs oder etwas vergleichbares hat, werden wir das wohl auch nicht herausfinden. Dennoch ist es imho falsch, grundlegend davon auszugehen, dass es noch Reserven gibt.

[(del)]

Ich bin mir sicher, Nvidia wird es gelingen, softwareseitig lange Befehlsketten "aufzuschneiden".
Die Freunde in Austin sind da recht fix. Und wenn es nur spielebezogen ist. So lange die Calls
unter 1ms bleiben, ist eh alles im Lot :)

Und bis wir nicht wissen, was und wie Maxwell diese Aufgaben tatsächlich handeln kann,
so lange diskutieren wir auch über fremdes Essen, das keiner bestellt hat und bezahlen will.

[Achill]

[...]
@Achill: du misst ja 'nur' an der Steckdose oder? Wie hoch laesst du denn deine Hawaii normal takten?
Soweit ich weiss hast du Crossfire? Willst du das ganze mal noch mit mGPU vermessen? Mich wuerde interessieren, wie viel beide Karten ziehen, wenn die Skalierungsfaktor ja 'nur' bei 1,5 oder so liegt. Klar, mit DX12 sind Leistung und Verbrauch hoeher aber wenn sie dauernd auf die CPU oder die jeweils andere GPU warten muessen, sollten sie ja wieder etwas weniger verbrauchen. Das ist ja auch im Hinblick auf eine X2 interessant, falls denn noch eine kommen sollte.

Steckdose? => Ja, ich nutzt ein einfaches "BaseTech 3000" was laut Stiftung Wahrentest gut misst aber nicht sicher ist bei großen Strömen da es zu heiß wird und sich dann verform inkl. aller Gefahren die daraus entstehen - wird am Rechner bzw. der abgenommen Leistung von diesem nicht einmal etwas warm.

Um das Problem mit der Punktmessung an der Steckdose etwas besser aufzudröseln hatte ich wie geschrieben verschiedene Zustände ohne GPU gemessen (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10953870#post10953870), damit man (natürlich ungenau) mittels Delta schätzen kann, was eine / zwei Hawaiis bei mir ziehen.

OC meiner Hawaiis?
=> Ist aus dem Gedächtnis weil ich die zwei Karten nicht übertakte bzw. bei CFX sogar runter gehe wenn ich den Takt nicht voll brauche => wg. Lautstärke, ich kühle den ganzen Rechner (Gehäuse ist zu) mit Luft, irgend was macht da immer Krach und ich kann mir nur aussuchen wo xD.
- 1080 ohne Spannungserhöhung aber mit Anpassung der Lüfterkurve (muss unter ~82° bleiben sonst gab es Artefakte) sowie PT
- 1150 mit Spannungserhöhung (+50mV) und mit Anpassung der Lüfterkurve (war auch was um die ~82°) sowie PT

Ohne PT-Anpassung verhält sich die 290X bei 1080 etwas wie der Boost bei NV, es gibt je nach Szene runter Richtung 1040 oder weiter (passiert dann auch bei 1040).

Kann ich gern mal mit AotS testen bzw. eine MSI Simulieren - was würde man analysieren wollen?

AotS CFX?
=> Geht leider noch nicht (über 1h probiert) bei mir - es gibt leider nicht mal ein Log oder ein Windows-Ereignis zum CTD - MS VS wieder zu installieren um mit dem Debugger ran zu gehen - kein Bock ... kann also gar nichts sagen ... :/

[Schnoesel]

Ist doch völlig egal was Nvidia macht solange es AMD gelingt Ihre Rohleistung endlich mal auf die Straße zu bekommen können sie nur davon profitieren.

[iuno]

Ich bin mir sicher, Nvidia wird es gelingen, softwareseitig lange Befehlsketten "aufzuschneiden".
Die Freunde in Austin sind da recht fix. Und wenn es nur spielebezogen ist.
Ja das mag ja sein.
Hast du denn konkrete Hinweise darauf, dass noch Einheiten brach liegen, dass es noch irgendwo laengere Wartezeiten gibt, die "gefuellt" weren koennen, wo noch mehr parallelisiert werden kann o.Ae.?
Alleine durch Aufteilen wird ja nichts schneller, wenn man die Stueckchen danach wieder alle in das selbe Rohr steckt. Der scheduler muss es ja dann auch gleichzeitig auf vorhandene freie Einheiten verteilen koennen.
AotS CFX?
=> Geht leider noch nicht (über 1h probiert) bei mir - es gibt leider nicht mal ein Log oder ein Windows-Ereignis zum CTD ... kann also gar nichts sagen ... :/
OK, schade. Dennoch danke fuer die Infos

[(del)]

Das Problem liegt im Context Switching. Es läuft schon deutlich smarter, wenn Calls von Haus aus eingekürzt ankommen. NV hatte es ja den VR-Entwicklern nicht umsonst mit auf den Weg gegeben, Draws nicht ausufern zu lassen. :)

[dargo]

@dargo: du weisst aber auch, dass es mehr als 2 power states gibt?

Und? Warum sollten mich diese interessieren wenn es da auch keine Probleme gibt? Übrigens bin ich jetzt zu Hause und mit -100mV habe ich in Idle exakt 789mV (da ich ja für alles -50mV verwende sind es halt 844mV). Bei einer 290X die ich hier mal hatte war bereits der Bereich um die 850mV kritisch... Stichwort Blackscreens auf dem Desktop.


Ich verstehe sowieso nicht, warum du so auf dem Thema herumreitest. Was juckt es mich, ob meine karte 30 Watt mehr oder weniger verbraucht, wenn ich mit Leistung und Lautstaerke zufrieden bin.

Der Stromverbrauch juckt mich in erster Linie auch nicht. Das hatte ich bereits im anderen Thread erwähnt, musst mal etwas querbeet hier lesen. Für mich persönlich ist bsw. nicht Watt/fps sondern eher Lautstärke/fps wichtig. Erreiche ich eine angenehme Lüfterlautstärke und akzeptable Temperatur, was natürlich von der Verlustleistung abhängig ist passt es für mich. Diese ganzen Watt-Diskussionen langweiligen mich zu Tode. Meine Stromrechnung von 2015 betrug 246€ im Jahr bei 1276kW/h. 2014 sah ähnlich aus.


Ich freue mich auch, wenn ich eine gute Karte habe, schreibe aber nicht jeden Thread damit voll wie viel UV oder OC sie macht und schon gar nicht uebertrage ich das auf eine ganze Produktreihe, weil das bs ist.
Das nimmt ja inzwischen schon fast hornsche Zuege an, der auch in jedem Thread seinen Fiji abfeiert. Das ist auf Dauer einfach nervtoetend und langweilig und vor allem bringt es nichts.

Es geht hier nicht ums freuen oder nicht. Oder liest du von mir irgendwo "täglich" wie toll doch meine Karte ist? Wenn du schon den Vergleich zu horn anstellst? Mir gehen nur diese ganzen NV-Fanboys auf den Senkel die ständig alle Grenadas in die Säuferschublade stecken. Dabei ist es längst bekannt, dass diese GPUs bei >~1000Mhz immer stärker ineffizienter werden und bei solchen Beispielen wie 1100+Mhz mit einem PT von 375+W ein schöner Heizofen. Ich hatte schon im anderen Thread gesagt... Grenadas bieten eine breite Palette an Standard-PTs, je nach Hersteller die man noch zusätzlich über den Treiber mit +/-50% beeinflussen kann, wenn man denn möchte. Diese allgemeine TDP-Angabe von 275W von AMD ist total irreführend. Je nach Hersteller kann man auch deutlich drunter oder deutlich drüber liegen.

[HisN]

Wo deine Erwartung herkommt kann ich also nicht im geringsten nachvollziehen.

Och, als die wundervolle DX12-Diskussion aufgekommen ist, haben doch die verschiedenen Publikationen ein Beispiel an einer frühen Beta gebracht wo der Intel IGPU das Post-Prozessing übernommen hatte, und so ein paar FPS rauskitzeln konnte.
Schon vergessen?


BTW


Der Umkehrschluss ist übrigens sehr interessant.
Wenn die AsyncShader dafür sorgen, dass die Graka ihre "Lücken" in den Abläufen vernünftig füllen kann,
dann besteht bei AMD unter DX11 der Arbeitsablauf aus einer einzigen großen Lücke. Anders kann man sich ja das ganze gar nicht erklären.

Ist das jetzt Peinlich oder Krass?

[iuno]

Schon vergessen?
Ja, das muss ich wohl vergessen haben. Deshalb steht das auch in dem Teil meines Beitrags, den du weggeschnitten hast. :rolleyes:
Wie gesagt, nichts dergleichen wird bei AotS gemacht, nicht mal annaehernd. Und zu glauben, dass alleine die Umstellung auf DX12 automatisch fuer so einen Ablauf sorgen soll, ist wie gesagt mehr als naiv.


Wenn die AsyncShader dafür sorgen, dass die Graka ihre "Lücken" in den Abläufen vernünftig füllen kann,
dann besteht bei AMD unter DX11 der Arbeitsablauf aus einer einzigen großen Lücke. Anders kann man sich ja das ganze gar nicht erklären.

Ist das jetzt Peinlich oder Krass?
Weder noch, das ist normal und altbekannt. Deine Formulierung ist aber Quatsch (einzige grosse Luecke) und faelschlicherweise auch eindimensional.
Es geht dabei nicht um Luecken in der Zeitleiste, weil einfach gerne zwischendurch mal Pause macht, sondern um Luecken, die auftreten dass die GPU sehr breit gebaut ist, aber nicht immer alle Rechenwerke gleichzeitig arbeiten koennen.

[Achill]

[...]

BTW

Der Umkehrschluss ist übrigens sehr interessant.
Wenn die AsyncShader dafür sorgen, dass die Graka ihre "Lücken" in den Abläufen vernünftig füllen kann,
dann besteht bei AMD unter DX11 der Arbeitsablauf aus einer einzigen großen Lücke. Anders kann man sich ja das ganze gar nicht erklären.

Ist das jetzt Peinlich oder Krass?


Vielleicht nicht im Vorbeigehen etwas schreiben?

Die Kontraposition/Umkehrschluss (https://de.wikipedia.org/wiki/Kontraposition) ist durch die Aussagenlogik (https://de.wikipedia.org/wiki/Aussagenlogik#Materiale_Implikation) (die du hier verwenden willst) definiert:

"Aus A folgt B" - dann ist die Kontraposition dazu - "Aus nicht B folgt nicht A".

mit A := DX12
und B := keine Lücke

Leider ist diese einfache Implikation nicht allein durch AotS gegeben noch partiell durch Versuche allein mit AotS bestätigt, da AotS nur ein Element aus A ist.

Wie willst du Aussage "Aus nicht A folgt nicht B" ableiten aus "Aus A folgt B"?

---
Edit: Ein Beispiel aus der Wiki

A => B - Wenn es regent (A) ist die Straße nass (B).
!A => !B - Wenn es nicht regent (!A) ist die Straße nicht nass (!B).

Das klingt im ersten Moment plausible, ist aber eine falsche Folgerung, da die Straße auch aus anderen Gründen nass werden kann (Rohrbruch, Übung der Feuerwehr …).

„Ex falso sequitur quodlibet“ – „Aus Falschem folgt Beliebiges“ - hat man auch so im 1. Semester Lineare Algebra I gleich am Anfang im Mathematik-Studium und wird halt oft umgangssprachlich falsch verwendet (weil es vermeintlich oft schön passt).

[Megamember]

Und? Warum sollten mich diese interessieren wenn es da auch keine Probleme gibt? Übrigens bin ich jetzt zu Hause und mit -100mV habe ich in Idle exakt 789mV (da ich ja für alles -50mV verwende sind es halt 844mV). Bei einer 290X die ich hier mal hatte war bereits der Bereich um die 850mV kritisch... Stichwort Blackscreens auf dem Desktop.




Die 390 benutzt etwas andere Speicherchips als die 290er Reihe, daher auch besseres oc und undervolting.

[Hübie]

Wundert sich eigentlich niemand, dass Ryan Shrout noch kein Review gepostet hat? :|
@HisN: Jetzt musst du mir mal erklären wie das mit AFR funktionieren soll :P

[dildo4u]

Wundert sich eigentlich niemand, dass Ryan Shrout noch kein Review gepostet hat? :|

Er war in Barcelona.

https://youtu.be/GYi6ocBGEUg

[Hübie]

Ich spiele auf einen tweet (https://twitter.com/ryanshrout/status/703073567919972353) von gestern an. ;)

Everyone still has the Ashes benchmark stuff wrong IMO. Back in the office tomorrow to explain, stay tuned!

Und weiter: Ryan Smith erhielt eine Nachricht von nVidia dass AC aktuell nicht aktiviert sei.

[Schnoesel]

Das weiß seit gestern so ziemlich jeder der es nicht wissen will:

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

Das muss der Treiber sein nachdem Nvidia seit September verzweifelt sucht ;D

[Blediator16]

PCPER wird das Haar in der Suppe sicher noch suchen und evtl. finden:uup:

[dildo4u]

Warum sollte sie jetzt ein Treiber bringen wenn sie noch ein Monat zu optimieren haben?Ich schätze eher das sie jetzt an einem Treiber für Hitman und Division sitzen,gerade das letztere dürfte deutlich vorrang haben wenn man das liest.


http://www.destructoid.com/division-decimates-destiny-s-record-for-biggest-beta-of-a-new-ip-343790.phtml

[Loeschzwerg]

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.

Ich habe jetzt ebenfalls meinen billigen Leistungsmesser angeschlossen.

DX11: Schwankt extrem zwischen ~195-300 Watt. Bei "Heavy Batch" Szenen sind es die ~195 Watt.
DX12 AC off: Nur leichte Schwankungen, das Gesamtsystem bewegt sich meistens zwischen 280-305 Watt.
DX12 AC on: Selbes Spiel wie mit AC off nur ca. 10 Watt höher.

Peak lag bei allen drei Tests bei ~ 325 Watt.

Letztendlich langweilt sich das System (Grafikkarte ausgenommen) :D

Edit: Und mit dem 16.2 Treiber und der aktuellsten Version von AotS sieht DX11 richtig bescheiden aus... ordentlich Grafikfehler in Form von flackernden Texturen am Boden.

[Hübie]

Laut Aussage können beide IHV tiefe Einblicke in den Quellcode nutzen um Lösungen zu implementieren, aber es fiel kein Sterbenswörtchen dass nVidia dies auch täte. Von AMD weiß man das ja.
Ich sag: wartet doch alle einfach mal ab und fertig. Ich weiß dass gerade eine total triste Phase im PC Sektor herrscht, aber deshalb muss man sich ja nicht wahllos auf jeden Scheiß stürzen. Unsere üblichen Verdächtigen auf beiden Seiten betonen sonst viel öfter dass es noch Beta ist... :rolleyes:

[HisN]

@HisN: Jetzt musst du mir mal erklären wie das mit AFR funktionieren soll :P
Hab ja gehofft, dass es kein simples AFR ist. In den ganz frühen Meldungen hat eine iGPU das Post-Prozessing übernommen. Das wäre der ideale Job für die 750 gewesen. Nix iss.

[aufkrawall]

Sicher, dass es um AoS ging, und nicht um UE4?

[dargo]

@HisN

Du verwechselst da was. Da ging es um die UE4 Demo.
http://www.pcgameshardware.de/screenshots/original/2015/05/DX_12_Multiadapter__1_-pcgh.png

[HisN]

*kreisch* Du hast absolut recht. Da war ich ja übel auf dem Holzweg.

[Unicous]

Ist Sean Pelletier eigentlich das RoyTaylor Pendant bei Nvidia?:confused:


Sean Pelletier
‏@PellyNV

@ryanshrout @guru_3d found out " Radeon Software 16.1 / 16.2 does not support a DX12 feature called DirectFlip". Interesting... ;)

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

http://www.extremetech.com/extreme/223654-instrument-error-amd-fcat-and-ashes-of-the-singularity

First, some basics. FCAT is a system NVIDIA pioneered that can be used to record, playback, and analyze the output that a game sends to the display. This captures a game at a different point than FRAPS does, and it offers fine-grained analysis of the entire captured session. Guru3D argues that FCAT’s results are intrinsically correct because “Where we measure with FCAT is definitive though, it’s what your eyes will see and observe.” Guru3D is wrong. FCAT records output data, but its analysis of that data is based on assumptions it makes about the output — assumptions that don’t reflect what users experience in this case.

AMD’s driver follows Microsoft’s recommendations for DX12 and composites using the Desktop Windows Manager to increase smoothness and reduce tearing. FCAT, in contrast, assumes that the GPU is using DirectFlip. According to Oxide, the problem is that FCAT assumes so-called intermediate frames make it into the data stream and depends on these frames for its data analysis. If V-Sync is implemented differently than FCAT expects, the FCAT tools cannot properly analyze the final output. The application’s accuracy is only as reliable as its assumptions, after all.

An Oxide representative told us that the only real negative from AMD’s switch to DWM compositing from DirectFlip “[I]s that it throws off FCAT.”

[...]

edit:

AMD has told us that it recognizes the value of FCAT in performance analysis and fully intends to support the feature in a future driver update. In this case, however, what FCAT shows is happening simply doesn’t match the experience of the actual output — and it misrepresents AMD in the process.

[fondness]

Schöner Artikel, der die Unterschiede zwischen AMD und NV bei DX12 Multi Engine aufzeigt:

http://s21.postimg.org/tlcnjs6t3/Capture.png (http://postimage.org/)

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

Ist Sean Pelletier eigentlich das RoyTaylor Pendant bei Nvidia?:confused:


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

http://www.extremetech.com/extreme/223654-instrument-error-amd-fcat-and-ashes-of-the-singularity



edit:

Wer ein NV-Tool zum Frametime-Messen verwendet, ist ohnehin nicht ernst zu nehmen.

[aufkrawall]

Verwendet Dice in Frostbite...

[DarknessFalls]

Du meinst DirectFlip?

[Locuza]

Du meinst DirectFlip?
FCAT für Frametime-Messungen.

[Hübie]

DWM compositing hat mehr input lag. Und wo bitte empfiehlt MS das in D3D12? Also langsam gehts los.

[Godmode]

Aufgeräumt. Für den nächsten OT-, Flame-, etc. Post gibt es rot.

[Achill]

So ... man sollte schon richtig schauen wenn man ein Treiber installiert. Leider war nicht der Crimson v16.2 Hotfix installiert sondern der Vulkan Beta Feb25.

Jetzt geht natürlich auch AFR:

CPU: 5820k@4.4GHz
GPU: 2x290x (1040/1375)

1080p / Low:
- Verbrauch: 384 - 441 W (mehrmals geprüft)
- Avg.GPU: 97fps
- Avg.CPU: 97fps

Wie man gut sieht ist liegt unter 1080p und dem Low Preset eine komplette CPU-Limitierung vor. Ich habe das Diagramm von AB mit angehängt - man sieht dort u.a. folgende interessante Details:
- Frametime ist sehr gut
- AFR erzeugt Overhead (Vergleich hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10955393#post10955393))
- Takt wird reduziert "ohne Probleme zu machen"

High / Extrem kommen gleich ...

[dargo]

So ... man sollte schon richtig schauen wenn man ein Treiber installiert. Leider war nicht der Crimson v16.2 Hotfix installiert sondern der Vulkan Beta Feb25.

Jetzt geht natürlich auch AFR:

CPU: 5820k@4.4GHz
GPU: 2x290x (1040/1375)

1080p / Low:
- Verbrauch: 384 - 441 W (mehrmals geprüft)
- Avg.GPU: 97fps
- Avg.CPU: 97fps

Wie man gut sieht ist liegt unter 1080p und dem Low Preset eine komplette CPU-Limitierung vor. Ich habe das Diagramm von AB mit angehängt - man sieht dort u.a. folgende interessante Details:
- Frametime ist sehr gut

Sehr gut ist glatt untertrieben, die sind perfekt. Du hast da ne Varianz von 0,x-2ms. Sag bloß das ist sogar mit AFR? :eek:

[Achill]

Es scheint ich habe ein Problem mit dem Setting Textur:High - daher musste ich bei allen Presets immer Textur auf Med setzen - hoffe es ist nicht der VRam auf der Sec.GPU - werde dann später Karten tauschen / einzeln testen :/

1080p / High / Textures:Med:
- Verbrauch: 537-568W (mehrmals beim Lauf geprüft, schwankte in diesem Bereich)
- Avg.GPU: 92.8fps
- Avg.CPU: 93.7fps

Interessante Details:
- Wir sind noch im CPU-Limit
- Takt ist bei fast 1040MHz

[Achill]

1080p / Extrem/ Textures:Med:
- Verbrauch: 581-612W
- Avg.GPU: 92.8fps
- Avg.CPU: 93.7fps

Interessante Details:
- Weiterhin im CPU-Limit
- Takt ähnlich wie bei High

Stichproben des Verbrauchs mit ~1s menschlicher Latenzen und ~3s durch Wattmeter in Relation des Zeitcounters:
2:55 - 372W
1:59 - 507W
1:10 - 612W
0:35 - 629W
-0:03 - 201W (Stabil, Benchmark Ergebnisbild)

[Achill]

VSR will leider nicht (Fullscreen / Borderless Window), daher kann ich keine höher Auflösung testen. Ihr müsst also mit CPU-Limitierten Werten vorlieb nehmen.

[Ex3cut3r]

Verstehe die Aufregung hier nicht, wenn interessieren hier noch Maxwells und Grenadas und noch mehr alte Schinken, viel interessanter wäre es doch, wie Pascal mit DX12 "umgeht" Polaris wird wohl sowieso sehr gut mit DX12 auskommen. Ich verstehe ja das momentan micht viel los ist im PC Markt (kauft euch doch einen neuen Monitor mit 144hz, 4K, oder 21:9 ) Aber in ein paar Monaten interessiert das eh niemanden mehr wie Maxwell unter DX12 läuft, da er eh schon wieder zu langsam ist.

[Digidi]

Verstehe die Aufregung hier nicht, wenn interessieren hier noch Maxwells und Grenadas und noch mehr alte Schinken, viel interessanter wäre es doch, wie Pascal mit DX12 "umgeht" Polaris wird wohl sowieso sehr gut mit DX12 auskommen. Ich verstehe ja das momentan micht viel los ist im PC Markt (kauft euch doch einen neuen Monitor mit 144hz, 4K, oder 21:9 ) Aber in ein paar Monaten interessiert das eh niemanden mehr wie Maxwell unter DX12 läuft, da er eh schon wieder zu langsam ist.

Es interessiert jeden der sich entscheidet länger eine GPU zu nutzen. (Also Zukunftsfähigkeit) Da hat Nvidia jetzt schon zum 2x mal so richtig daneben gegriffen. Ich sag nur DX11.1
Wie kann Nvidia mit so uninspirierten Karten die kaum technische Finesse besitzen so erfolgreich sein?


Oh man mit Extrem im CPU Bound lol

== Hardware Configuration ================================================
GPU 0: AMD Radeon R9 200 Series
CPU: GenuineIntel
Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
Physical Cores: 4
Logical Cores: 8
Physical Memory: 8140 MB
Allocatable Memory: 134217727 MB
==========================================================================


== Configuration =========================================================
API: DirectX 12
==========================================================================
Quality Preset: Crazy
==========================================================================

Resolution: 1920x1080
Fullscreen: True
Bloom Quality: High
PointLight Quality: High
Glare Quality: High
Shading Samples: 16 million
Terrain Shading Samples: 16 million
Shadow Quality: High
Temporal AA Duration: 0
Temporal AA Time Slice: 0
Multisample Anti-Aliasing: 4x
Texture Rank : 1


== Total Avg Results =================================================
Total Time: 60.001213 ms per frame
Avg Framerate: 38.923683 FPS (25.691301 ms)
Weighted Framerate: 38.276978 FPS (26.125364 ms)
CPU frame rate (estimated if not GPU bound): 71.572266 FPS (13.971893 ms)
Percent GPU Bound: 59.049206 %
Driver throughput (Batches per ms): 4950.105469 Batches
Average Batches per frame: 16330.924805 Batches
==========================================================================


== Results ===============================================================
BenchMark 0
TestType: Full System Test
== Sub Mark Normal Batch =================================================
Total Time: 71.026306 ms per frame
Avg Framerate: 41.533909 FPS (24.076714 ms)
Weighted Framerate: 40.298409 FPS (24.814877 ms)
CPU frame rate (estimated if not GPU bound): 84.636078 FPS (11.815291 ms)
Percent GPU Bound: 67.266953 %
Driver throughput (Batches per ms): 3777.808350 Batches
Average Batches per frame: 6513.910645 Batches
== Sub Mark Medium Batch =================================================
Total Time: 55.957882 ms per frame
Avg Framerate: 40.208813 FPS (24.870171 ms)
Weighted Framerate: 39.623550 FPS (25.237516 ms)
CPU frame rate (estimated if not GPU bound): 74.177551 FPS (13.481168 ms)
Percent GPU Bound: 75.917778 %
Driver throughput (Batches per ms): 4621.352539 Batches
Average Batches per frame: 13246.325195 Batches
== Sub Mark Heavy Batch =================================================
Total Time: 53.019432 ms per frame
Avg Framerate: 35.553001 FPS (28.127020 ms)
Weighted Framerate: 35.306118 FPS (28.323704 ms)
CPU frame rate (estimated if not GPU bound): 60.171314 FPS (16.619215 ms)
Percent GPU Bound: 33.962883 %
Driver throughput (Batches per ms): 5801.070801 Batches
Average Batches per frame: 29232.535156 Batches
=========================================================================
=========================================================================

[dargo]

VSR will leider nicht (Fullscreen / Borderless Window), daher kann ich keine höher Auflösung testen. Ihr müsst also mit CPU-Limitierten Werten vorlieb nehmen.
Öhm... takte doch beide GPUs runter. ;)

Verstehe die Aufregung hier nicht, wenn interessieren hier noch Maxwells und Grenadas und noch mehr alte Schinken...
Es interessiert Millionen von Spielern außerhalb "Freak"foren wie 3DC & Co die nicht bei jeder Generation wechseln. Ich weiß, ist für so manchen Member hier befremdlich.

[Atma]

Es interessiert Millionen von Spielern außerhalb "Freak"foren wie 3DC & Co die nicht bei jeder Generation wechseln. Ich weiß, ist für so manchen Member hier befremdlich.
So sieht's aus. Als ob in ein paar Monaten sofort alle zum Release von Pascal umsteigen würden ...

Parallelwelten sind schon was feines :)

[aufkrawall]

Es interessiert jeden der sich entscheidet länger eine GPU zu nutzen. (Also Zukunftsfähigkeit) Da hat Nvidia jetzt schon zum 2x mal so richtig daneben gegriffen. Ich sag nur DX11.1
Wie kann Nvidia mit so uninspirierten Karten die kaum technische Finesse besitzen so erfolgreich sein?

Weil sie in der Realität mit hohem Takt AMD häufig windelweich prügeln?
Meine 980 ist bei Garden Warfare 2 offenbar ca. auf Fury X Niveau in WQHD:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10955132&postcount=22
Übrigens bei ca. 205W Verbrauch.

[dargo]

Genieße noch die alte API solange du kannst. :tongue:

[aufkrawall]

Eben das ist der Punkt, bisher war der Genuss der wichtigsten API DX11 mit NV häufig deutlich höher.
Wenn ich eine Karte kaufe, soll sie sofort ihre Leistung möglichst ausschöpfen, und nicht erst vier Jahre später wie bei der 7970 durch AC.

AMD hat jetzt eine einmalige Chance, die sie nicht versemmeln dürfen.

[dargo]

Bei dir ist das Hauptproblem dein Monitor. Deshalb die verzweifelte Jagd nach fps. ;) Ich kann dir jetzt schon sagen, dass ich mit der R9 390 wesentlich mehr Spielspaß in kürzerer Zeit habe als mit der GTX970 davor. Dank Freesync. ;)

[aufkrawall]

Wer argumentiert denn immer, dass er trotz A-Sync hohe fps für MP-Spiele will und deshalb die Details reduziert?
Abgesehen davon hab ich The Division mit Drops auf 30fps gespielt und kam gut klar. So verzweifelt ist ist meine Jagd nach fps gar nicht...

[fondness]

Weil sie in der Realität mit hohem Takt AMD häufig windelweich prügeln?
Meine 980 ist bei Garden Warfare 2 offenbar ca. auf Fury X Niveau in WQHD:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10955132&postcount=22
Übrigens bei ca. 205W Verbrauch.

Vielleicht in der Szene bei PCGH:
http://www.computerbase.de/2016-02/plants-vs-zombies-benchmarks-garden-warfare-2/2/#diagramm-pvz-garden-warfare-2-2560-1440

[aufkrawall]

Sorry, aber wer von "gutem Anti-Aliasing" sogar in der Überschrift spricht, aber nicht checkt, dass es nur billigstes FXAA ist, kann einfach nicht ernstgenommen werden.
Im Gegensatz zu PCGH gibts auch überhaupt keine Transparenz, was für eine Szene getestet wurde.
Ich traue Wolfgang gar nichts mehr zu, er schreibt viel zu häufig kompletten Müll.

[dargo]

Wer argumentiert denn immer, dass er trotz A-Sync hohe fps für MP-Spiele will und deshalb die Details reduziert?

Da gehts mir um ein einziges Spiel... nämlich BF4 im MP. :uconf3: Zudem liegt das Game bei mir eh schon länger auf Eis. Irgendwann hat man sich satt gezockt. Hinzu kommt noch, dass ich im Gegensatz zu manch anderem kein Problem damit habe das eine oder andere Detail zu reduzieren.

Sorry, aber wer von "gutem Anti-Aliasing" sogar in der Übersschrift spricht, aber nicht checkt, dass es nur billigstes FXAA ist, kann einfach nicht ernstgenommen werden.
Im Gegensatz zu PCGH gibts auch überhaupt keine Transparenz, was für eine Szene getestet wurde.
Ich traue Wolfgang gar nichts mehr zu, er schreibt viel zu häufig kompletten Müll.
Und ich amüsiere mich immer wieder köstlich über deine Beschuldigungen auf andere Personen wo das Ergebnis stärker zugunsten AMD ausfällt. Ist dir eigentlich schon mal aufgefallen, dass die PCGH durchgehend mit HQAF testet (was NVs besser schmeckt) obwohl das bei beiden IHVs kein Standardsetting ist? Zudem nimmt die PCGH eine 980TI mit ~1330Mhz wo Wolfgang offenbar eine Standard 980TI verwendet. Und wie fondness schon sagt können die Verhältnisse zwischen den jeweiligen IHVs in zwei verschiedenen Szenen unterschiedlich ausfallen, wäre nun auch keine wirklich neue Erkenntnis.

[aufkrawall]

Und ich amüsiere mich immer wieder köstlich über deine Beschuldigungen auf andere Personen wo das Ergebnis stärker zugunsten AMD ausfällt.

Und ich dachte, du hättest überhaupt keinen Humor.


Ist dir eigentlich schon mal aufgefallen, dass die PCGH durchgehend mit HQAF testet (was NVs besser schmeckt) obwohl das bei beiden IHVs kein Standardsetting ist?

Ist dir eigentlich schon mal aufgefallen, dass Frostbite Megatexture fürs Terrain verwendet, wo maximal 4xAF genutzt wird...
Abgesehen davon hat PCGH bei Battlefront auch HQ getestet, was eine Unsinnsannahme.


Zudem nimmt die PCGH eine 980TI mit ~1330Mhz wo Wolfgang offenbar eine Standard 980TI verwendet.

Trotzdem passt die Skalierung zwischen 970 and 980 Ti bei CB nicht, bei PCGH schon.


Und wie fondness schon sagt können die Verhältnisse zwischen den jeweiligen IHVs in zwei verschiedenen Szenen unterschiedlich ausfallen, wäre nun auch keine wirklich neue Erkenntnis.
Wir wissen ja gar nicht, was für eine Szene CB getestet hat, weil der gute Wolfgang überhaupt keine Angaben macht.

Von mir aus können wir jede andere Szene testen, die Relationen werden sich nicht ändern. Im Gegensatz zu dir hab ich das Spiel schon ein paar Stunden gespielt...

[Hübie]

Vielleicht in der Szene bei PCGH:
http://www.computerbase.de/2016-02/plants-vs-zombies-benchmarks-garden-warfare-2/2/#diagramm-pvz-garden-warfare-2-2560-1440

Vergleich doch mal die Taktraten. Eine 980 Ti mit custom cooler boostet im Schnitt 1300 MHz. Computerbase.de liegt weit darunter, mit ihrer Referenzkarte. Also stellt das worst case dar.

@dargo: Freesync bindet genau wie G-Sync an einen IHV. Das will nicht jeder. Dazu kommt noch erhöhtes Input-lag. Also nur partiell valide Argumentation.

Ansonsten ist das alles brav OT und ich bitte um Rückkehr zum Thema.
Ryan Shrout sagt über Twitter dass wohl vieles falsch verstanden wurde, was über DX12 bekannt ist. Na ich bleib mal gespannt.
Es ist nach wie vor kein AC per Treiber aktiviert und es ist fraglich ob es nVidia's Aufgabe ist die Arbeit der Entwickler vollständig zu übernehmen (Quellcode modifizieren / erweitern).

[fondness]

Ryan Shrout sagt über Twitter dass wohl vieles falsch verstanden wurde, was über DX12 bekannt ist. Na ich bleib mal gespannt.

Eine Plattitüde die alles oder nicht bedeuten kann.


Es ist nach wie vor kein AC per Treiber aktiviert und es ist fraglich ob es nVidia's Aufgabe ist die Arbeit der Entwickler vollständig zu übernehmen (Quellcode modifizieren / erweitern).

Ersteres ist wohl klar NVs Problem/Schuld (und vermutlich wird da auch nicht mehr viel kommen) und letzteres ergibt für mich keinen Sinn. Warum sollte NV die "Arbeit der Entwickler übernehmen"? NV hat schlicht das Problem, dass ihre Pipeline starr ist bzw. stark an DX11 angelehnt. Dementsprechend ist das unter DX11 wohl auch der sinnvollere Weg, wenn die Entwickler die vielen Multi-Engine-Möglichkeiten von AMDs Hardware nutzen, was jetzt dank DX12/Vulkan zumindest größtenteils möglich ist, sieht die Sache dann allerdings womöglich anders aus.

[Schnoesel]

Es ist nach wie vor kein AC per Treiber aktiviert und es ist fraglich ob es nVidia's Aufgabe ist die Arbeit der Entwickler vollständig zu übernehmen (Quellcode modifizieren / erweitern).

Also wenn der Treiber nicht Nvidias Aufgabe ist dann weiß ich auch nicht mehr. Die müssen doch AC irgendwie per Softwaremulation zum Laufen bekommen per Hardware funzt es ja offenbar nicht, ist doch nicht AMDs/Oxides Aufgabe.

[dargo]

Also wenn der Treiber nicht Nvidias Aufgabe ist dann weiß ich auch nicht mehr. Die müssen doch AC irgendwie per Softwaremulation zum Laufen bekommen per Hardware funzt es ja offenbar nicht, ist doch nicht AMDs/Oxides Aufgabe.
Ich verstehe ehrlich gesagt nicht wo das Problem liegt. Wenn NV in Hardware AC nicht performant genug (nicht schneller als ohne AC) bewerkstelligen kann dann kann und sollte auch der Entwickler AC für Nvidia Karten deaktivieren. Das kann doch kein großer Aufwand sein. Oder von mir aus es dem Spieler selbst überlassen indem man eine entsprechende Option ins Spiel intergriert.

[Kartenlehrling]

Ryan Shrout sagt über Twitter dass wohl vieles falsch verstanden wurde, was über DX12 bekannt ist. Na ich bleib mal gespannt.
Es ist nach wie vor kein AC per Treiber aktiviert und es ist fraglich ob es nVidia's Aufgabe ist die Arbeit der Entwickler vollständig zu übernehmen (Quellcode modifizieren / erweitern).

Naja aber die Compute command lists von DX12 ist ja schliesslich nicht von AMD oder Oxides vorgegeben sondern das Endergebnis der DX12 Specification.
Und wenn Oxid Gameengine eine command zeile abfragen und ein "richtige" Antwort bekommt kann man doch eigentlich davon ausgehen das die Hardware und der Treiber damit umgehen kann.

Nvidia war ja so klug eine ToDO Liste zu veröffentlich was die Entwicker Dürfen!! (https://developer.nvidia.com/dx12-dos-and-donts)


https://msdn.microsoft.com/de-de/library/windows/desktop/dn899217%28v=vs.85%29.aspx
Synchronization and Multi-Engine

[dildo4u]

Ich verstehe ehrlich gesagt nicht wo das Problem liegt. Wenn NV in Hardware AC nicht performant genug (nicht schneller als ohne AC) bewerkstelligen kann dann kann und sollte auch der Entwickler AC für Nvidia Karten deaktivieren. Das kann doch kein großer Aufwand sein. Oder von mir aus es dem Spieler selbst überlassen indem man eine entsprechende Option ins Spiel intergriert.
NV hat Treiber support in Aussicht gestellt daher wird es drin bleiben.
Es gibt nur keine Support im aktuellen Game Ready Treiber.


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

[fondness]

Ach komm. Bei AMD ist nicht mehr D3D12 drin als bei nVidia. Rede doch nicht immer alles nach dem Munde deines Arbeitgebers.
Und wenn nVidia sich hinsetzen muss um deren Implementation für compute shader über context switches zu programmieren ist es eben verpennte Arbeit der einfältigen Personen dieses Spiels.

Sorry, aber wie lange wartest du jetzt bereits auf ein Statement von Nvidia bezüglich AsycCompute? Ich denke 6 Monate sollte hin kommen, schon damals meinstest du man sollte warten, was NV zu sagen hat. Was ist gekommen? Nichts, sie haben es erwartungsgemäß totgeschwiegen, sie haben die Aussagen von AMD wonach NV kein AsyncCompute in HW beherrscht eben NICHT widersprochen. Du glaubst doch nicht wirklich, dass da noch großartig was kommen wird.

Und nein, sie haben die entsprechenden Capabilities eben nicht in Hardware, NV empfiehlt den Devs sogar ausdrücklich Dinge wie Context Switches wann immer möglich zu vermeiden. Dein zweiter Absatz setzt dem ganzen dann die Krone auf, AMD und NV führen den selben Code aus, wenn NV nicht in der Lage ist von einer modernen Mutil-Engine App zu profitieren, ist das sicher nicht die Schuld der Entwickler. Die Performace ansich ist im übrigen ja nicht mal schlecht, schon gar nicht für die Optik. Zu den HW Caps siehe auch: http://ext3h.makegames.de/DX12_Compute.html

[captain_drink]

Dein zweiter Absatz setzt dem ganzen dann die Krone auf, AMD und NV führen den selben Code aus, wenn NV nicht in der Lage ist von einer modernen Mutil-Engine App zu profitieren, ist das sicher nicht die Schuld der Entwickler.

Bei einer LL-API ist es ganz im Gegenteil Aufgabe der Entwickler, sicherzustellen, dass ihre Engine auf allen Systemen ähnlich performant läuft (im Verhältnis zu den vorhandenen HW-Möglichkeiten).
Es ist nicht auszuschließen (vielmehr sogar wahrscheinlich), dass AotS spezifisch auf die Fähigkeiten von GCN 1.x zugeschnitten ist, ggf. sogar gegen die Fähigkeiten von Maxwell.
Das entwertet zwar nicht die Ergebnisse von AMD (die HW-Fähigkeiten sind schließlich vorhanden), sollte aber nicht als Goldstandard zum Schluss auf jede beliebige andere Engine mit LL-API genommen werden.

Interessant finde ich übrigens, dass sonst genau umgekehrt argumentiert wird: Hohe Levels von Tessellation seien die Schuld der Entwickler/NV, man bremse AMD absichtlich aus. Wenn aber etwas, das anscheinend an NV vorbeientwickelt wurde, AMD beschleunigt, dann ist das plötzlich i.O.

[Kriton]

Verstehe die Aufregung hier nicht, wenn interessieren hier noch Maxwells und Grenadas und noch mehr alte Schinken, viel interessanter wäre es doch, wie Pascal mit DX12 "umgeht" Polaris wird wohl sowieso sehr gut mit DX12 auskommen. Ich verstehe ja das momentan micht viel los ist im PC Markt (kauft euch doch einen neuen Monitor mit 144hz, 4K, oder 21:9 ) Aber in ein paar Monaten interessiert das eh niemanden mehr wie Maxwell unter DX12 läuft, da er eh schon wieder zu langsam ist.

Nicht jeder kauft seine Grafikkarte jedes 1/2 oder 1 Jahr neu.

@dargo: Freesync bindet genau wie G-Sync an einen IHV. Das will nicht jeder. Dazu kommt noch erhöhtes Input-lag. Also nur partiell valide Argumentation.

Das ist falsch. Bei AMD ist es ein offener Standard, den Nvidia nicht unterstützt, aber könnte, und der von Intel künftig auch unterstützt wird. G-Sync kann nicht von einem anderen IHV unterstützt werden, weil es proprietär ist.

[captain_drink]

Das ist falsch. Bei AMD ist es ein offener Standard, den Nvidia nicht unterstützt, aber könnte, und der von Intel künftig auch unterstützt wird. G-Sync kann nicht von einem anderen IHV unterstützt werden, weil es proprietär ist.

Das ist allenfalls ein hypothetisches "könnte", denn NV wird sicherlich weiterhin an der eigenen proprietären Technolgie festhalten, so dass der nominell freie Standard von AMD in einem Duopol (denn Intel ist für dedizierte Karten irrelevant, wofür Async hauptsächlich Verwendung findet) faktisch proprietär, d.h. an einen IHV bindend ist.

[fondness]

Bei einer LL-API ist es ganz im Gegenteil Aufgabe der Entwickler, sicherzustellen, dass ihre Engine auf allen Systemen ähnlich performant läuft (im Verhältnis zu den vorhandenen HW-Möglichkeiten).
Es ist nicht auszuschließen (vielmehr sogar wahrscheinlich), dass AotS spezifisch auf die Fähigkeiten von GCN 1.x zugeschnitten ist, ggf. sogar gegen die Fähigkeiten von Maxwell.
Das entwertet zwar nicht die Ergebnisse von AMD (die HW-Fähigkeiten sind schließlich vorhanden), sollte aber nicht als Goldstandard zum Schluss auf jede beliebige andere Engine mit LL-API genommen werden.


Da widerspreche ich dir nicht mal, natürlich werden andere Spiele, die vielleicht mehr auf NV zugeschnitten sind und von Dinge wie AsyncCompute keine Gebrauch machen in Relation besser auf NV laufen.


Interessant finde ich übrigens, dass sonst genau umgekehrt argumentiert wird: Hohe Levels von Tessellation seien die Schuld der Entwickler/NV, man bremse AMD absichtlich aus. Wenn aber etwas, das anscheinend an NV vorbeientwickelt wurde, AMD beschleunigt, dann ist das plötzlich i.O.

Ähm, nicht alles was hinkt ist ein Vergleich. Es ist ein gewaltiger Unterschied ob ich jemanden ausbremse, oder ob ich Fähigkeiten einer HW nutze, um diese zu beschleunigen. NV würde ja schließelich nicht besser oder schlechter laufen, wenn bei AMD kein AC Verwendung findet.

Und obwohl NV offenbar noch immer zu beweisen versucht, dass DX12 unnötig ist, und enorm in DX11-Optimierungen investiert, während man bei DX12 laut eigenen Aussagen noch immer keinen AsycCompute "Workaround" hat, läuft ja der DX12-Pfad nicht mehr langsamer.

[N0Thing]

DWM compositing hat mehr input lag. Und wo bitte empfiehlt MS das in D3D12? Also langsam gehts los.

Da das Thema input lag in dem Zusammenhang immer wieder mal aufkommt, gibt es dazu ein ordentliches Review, wie groß der zusätzliche input lag wird?


@dargo: Freesync bindet genau wie G-Sync an einen IHV. Das will nicht jeder. Dazu kommt noch erhöhtes Input-lag. Also nur partiell valide Argumentation.

Ich dachte in allen Reviews zu g-sync und free-sync wurde gezeigt, dass es keinen zusätzlichen input lag gibt. :confused:

[Kriton]

Das ist allenfalls ein hypothetisches "könnte", denn NV wird sicherlich weiterhin an der eigenen proprietären Technolgie festhalten, so dass der nominell freie Standard von AMD in einem Duopol (denn Intel ist für dedizierte Karten irrelevant, wofür Async hauptsächlich Verwendung findet) faktisch proprietär, d.h. an einen IHV bindend ist.

Sorry, aber das ist bullshit. Offener Standard ist offener Standard. Wenn den jemand nicht unterstützen will ist das deren Sache; in dem Kontext auch nur ansatzweise den Begriff proprietär zu verwenden ist schlicht FUD.
Und Nvidia wird auch auf den Standard gehen - die Frage ist nur wann.

[dargo]

Bei einer LL-API ist es ganz im Gegenteil Aufgabe der Entwickler, sicherzustellen, dass ihre Engine auf allen Systemen ähnlich performant läuft (im Verhältnis zu den vorhandenen HW-Möglichkeiten).
Es ist nicht auszuschließen (vielmehr sogar wahrscheinlich), dass AotS spezifisch auf die Fähigkeiten von GCN 1.x zugeschnitten ist, ggf. sogar gegen die Fähigkeiten von Maxwell.
Das entwertet zwar nicht die Ergebnisse von AMD (die HW-Fähigkeiten sind schließlich vorhanden), sollte aber nicht als Goldstandard zum Schluss auf jede beliebige andere Engine mit LL-API genommen werden.

Wo bremst der Entwickler Nvidia?
http://media.bestofmicro.com/D/G/561652/gallery/AsyncCompute_On_Off_w_600.png

http://www.tomshardware.de/ashes-of-the-singularity-beta-2-directx-12-dx12-gaming,testberichte-242049.html

Ich sehe nirgendwo, dass Nvidia in DX12 langsamer als in DX11 ist. Nur beim Einsatz von AC, die Gründe dafür sind bekannt.

Das ist allenfalls ein hypothetisches "könnte", denn NV wird sicherlich weiterhin an der eigenen proprietären Technolgie festhalten, so dass der nominell freie Standard von AMD in einem Duopol (denn Intel ist für dedizierte Karten irrelevant, wofür Async hauptsächlich Verwendung findet) faktisch proprietär, d.h. an einen IHV bindend ist.
Intel wird schneller im Gaming Markt aufschließen als du glaubst. Sobald HBM Speicher massentauglich ist spricht bei Intel nichts mehr gegen schnelle APUs. Gleiches gilt für AMD natürlich auch in Bezug auf APUs. Es wird nicht mehr lange dauern und das gesamte Performancesegment wird mit APUs abgedeckt.

[DarknessFalls]

Das ist allenfalls ein hypothetisches "könnte", denn NV wird sicherlich weiterhin an der eigenen proprietären Technolgie festhalten, so dass der nominell freie Standard von AMD in einem Duopol (denn Intel ist für dedizierte Karten irrelevant, wofür Async hauptsächlich Verwendung findet) faktisch proprietär, d.h. an einen IHV bindend ist.

Weil Hersteller A an seiner proprietären Technik festhält, während Hersteller B und der "irrelevante" Hersteller C den offenen Standard Adaptive Sync (mit in AMDs Fall dem Label "Freesync") nutzen, wird aufgrund der Weigerung von Hersteller A der offene Standard noch immer nicht proprietär.

[Lurtz]

Bei einer LL-API ist es ganz im Gegenteil Aufgabe der Entwickler, sicherzustellen, dass ihre Engine auf allen Systemen ähnlich performant läuft (im Verhältnis zu den vorhandenen HW-Möglichkeiten).
Dann Gnade jemand AMD wenn die ersten Gameworkstitel mit DX12 kommen :ugly:

Das ist allenfalls ein hypothetisches "könnte", denn NV wird sicherlich weiterhin an der eigenen proprietären Technolgie festhalten, so dass der nominell freie Standard von AMD in einem Duopol (denn Intel ist für dedizierte Karten irrelevant, wofür Async hauptsächlich Verwendung findet) faktisch proprietär, d.h. an einen IHV bindend ist.
Es ist bereits ein Industriestandard. Proprietär ist daran mal gar nichts, egal was nVidia wieder treibt.

[captain_drink]

Ich sehe nirgendwo, dass Nvidia in DX12 langsamer als in DX11 ist. Nur beim Einsatz von AC, die Gründe dafür sind bekannt.

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

Sofern AC treiberseitig wirklich nicht aktiv sein sollte, ist der entsprechende Vergleich allerdings ohnehin nicht aussagekräftig.

Und noch was zum Thema "Bremsen" gg. "Beschleunigen": Das Leistungsdelta ist bei beiden identisch. Wenn IHV A X leistet, B hingegen Y, und A um C beschleunigt wird, dann ist A um C schneller als B. Wird B hingegen um C ausgebremst, ist A ebenso um C schneller als B. Der Idealzustand wäre, dass sowohl A als auch B um C beschleunigt werden.

Weil Hersteller A an seiner proprietären Technik festhält, während Hersteller B und der "irrelevante" Hersteller C den offenen Standard Adaptive Sync (mit in AMDs Fall dem Label "Freesync") nutzen, wird aufgrund der Weigerung von Hersteller A der offene Standard noch immer nicht proprietär.


Es ist bereits ein Industriestandard. Proprietär ist daran mal gar nichts, egal was nVidia wieder treibt.

Deswegen schreibe ich ja "nominell" und "faktisch". Natürlich ist Freesync ein offener Standard, Stand jetzt binde ich mich aber an einen IHV, mit der Aussicht auf einen zweiten, der bezüglich dGPU keine Rolle spielt.
In der Hinsicht (und nur in der Hinsicht) besteht kein Unterschied zu der Situation mit G-Sync.

[aufkrawall]

Beim Durchschnitt durch alle Tests scheint mir die Aussage schon haltbar, dass DX12 ohne AC bei NV nicht mehr langsamer ist als DX11.

[Achill]

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

Sofern AC treiberseitig wirklich nicht aktiv sein sollte, ist der entsprechende Vergleich allerdings ohnehin nicht aussagekräftig.

Und noch was zum Thema "Bremsen" gg. "Beschleunigen": Das Leistungsdelta ist bei beiden identisch. Wenn IHV A X leistet, B hingegen Y, und A um C beschleunigt wird, dann ist A um C schneller als B. Wird B hingegen um C ausgebremst, ist A ebenso um C schneller als B. Der Idealzustand wäre, dass sowohl A als auch B um C beschleunigt werden.





Deswegen schreibe ich ja "nominell" und "faktisch". Natürlich ist Freesync ein offener Standard, Stand jetzt binde ich mich aber an einen IHV, mit der Aussicht auf einen zweiten, der bezüglich dGPU keine Rolle spielt.
In der Hinsicht (und nur in der Hinsicht) besteht kein Unterschied zu der Situation mit G-Sync.

Einfach einen NV-Treiber vor dem berühmten 337.50 Beta nehmen und DX11 laufen lassen.

Wenn ein IHV bei 99% der Leistungsfähigkeit seiner HW (Vermutung) erreicht hat, dann kann man das nicht mehr weiter beschleunigen. Laut der Rohleistung der HW ist doch klar, dass AMD GPUs ähnlich schnelle zu bestimmten NV GPUs ist.

---
Edit: Wenn wir jetzt ein Spiel haben, was stark auf Compute setzt und durch AC die verfügbare Leistung bei CGN genutzt werden kann, dann ist dies nichts anderes als wenn wir ein Spiel haben, wo sehr viel/stark (egal wie sinnvoll das dem einzelnen ist) Tessellation genutzt wird. Oder PhysX (Mafai ahoi), oder Füllrate, oder oder oder ...

[aufkrawall]

Bei sehr lahmen CPUs bringt ja auch DX12 bei NV noch 40% im CPU-Limit.

[dargo]

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

Sofern AC treiberseitig wirklich nicht aktiv sein sollte, ist der entsprechende Vergleich allerdings ohnehin nicht aussagekräftig.

Ich sehe da nur ein Problem @4k bei GM200 zwischen DX11 und DX12 non AC. Warum? Keine Ahnung. Bei GM204 und GM206 sind die Einzelergebnisse quasi identisch mit ner Abweichung hinter dem Komma.

Bei sehr lahmen CPUs bringt ja auch DX12 bei NV noch 40% im CPU-Limit.
Logisch... schließlich wird der Treiberoverhead weiter reduziert und unter DX12 kann man mit einer ganz anderen Drawcallmenge rumhantieren.

[Hübie]

Schade dass hier so etwas immer ausartet. Hardware hat immer seine Restriktionen und wenn man sich daran hält, bekommt man maximale Performance. Genau wie es mehrere Lösungen für bestimmte Aufgaben und Operationen gibt. Oxide entscheidet sich eben für einen Ansatz der auf GCN 1.2 besonders gut läuft, da hier die Limits ausgenutzt werden.
Keine Ahnung wieso man da jetzt mit Call Funktionen von Command Lists kommt.
Und nVidia wird AotS sicher nicht weit oben auf der Liste haben. Mal sehen wer das Teil am Ende überhaupt spielt, statt als Hardwarevergewaltiger in die Argumentationskette zu implementieren.

Tesselation ist oftmals wieder eine andere Geschichte. Das nutzt nVidia doch immer wieder gezielt aus. Das ist Entwickler- und IHV-Sache...

[-/\-CruNcher-/\-]

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

Naja es kommt drauf an für was es eingesetzt wird und letztendlich wie effizient es überhaupt für den PC als Platform auch von nutzen ist da dir ja schon aufgefallen ist das timing alles ist ;)

Und für Pascal wird es keine weltbewegenden AC Hardware veränderungen geben das ist faktisch im GameWorks VR talk von Nathan Reed bestätigt worden das Nvidia dahingehend nichts für die nahe Zukunft plant umzustellen.

Wie gesagt der Hauptnutzen für Ashes of the Singularity liegt momentan nur in der Trennung des Postprocessing vom Render Thread und das ist auch anders lösbar vor alle mit der zuhilfename der IGPU unter DX 12 deine 4 bis 5 frames gewinnst du so auch und vermeindlich sogar weitaus effizienter ;)

Es gibt einige nützliche Anwendungen aber die sind für den PC bis jetzt von noch keinem wirklich realisiert worden da überall das Timing die Pros wieder auffrisst vor allem unter Windows ;)

Auf den Konsolen spielt sich da weitaus mehr ab ;)

[dildo4u]

Schade dass hier so etwas immer ausartet. Hardware hat immer seine Restriktionen und wenn man sich daran hält, bekommt man maximale Performance. Genau wie es mehrere Lösungen für bestimmte Aufgaben und Operationen gibt. Oxide entscheidet sich eben für einen Ansatz der auf GCN 1.2 besonders gut läuft, da hier die Limits ausgenutzt werden.
Keine Ahnung wieso man da jetzt mit Call Funktionen von Command Lists kommt.
Und nVidia wird AotS sicher nicht weit oben auf der Liste haben. Mal sehen wer das Teil am Ende überhaupt spielt, statt als Hardwarevergewaltiger in die Argumentationskette zu implementieren.

Tesselation ist oftmals wieder eine andere Geschichte. Das nutzt nVidia doch immer wieder gezielt aus. Das ist Entwickler- und IHV-Sache...

Es geht nicht nur um Ashes NV muss eine allgemeine Lösung finden,da viele Konsolenport's diese Technik verwenden werden um mehr Power aus der PS4/XBox One zu locken.

[Exxtreme]

So Leute, jetzt mal bitte wieder zurück zum Thema "Ashes of the Singularity & Asynchronous Shader". Ob Grafikkarte X bei Fallout xy fps schafft gehört nicht zum Thema.

[spotz]

Gibt es eigentlich schon Tests wie Explicit Multiadapter in normalen Laptops mit bspw. AMDs R330M, Nvidias 820M oder 930M mit Intel IGPs performt? Wahrscheinlich sind derartig konfigurierte Computer am weitesten verbreitet.

[Kriton]

Und noch was zum Thema "Bremsen" gg. "Beschleunigen": Das Leistungsdelta ist bei beiden identisch. Wenn IHV A X leistet, B hingegen Y, und A um C beschleunigt wird, dann ist A um C schneller als B. Wird B hingegen um C ausgebremst, ist A ebenso um C schneller als B. Der Idealzustand wäre, dass sowohl A als auch B um C beschleunigt werden.

Das ist zu vereinfachend. Unterschiedliche HW-Architekturen performen unterschiedlich mit unterschiedlichen SW-Architekturen. Da ist es "verwegen" gleich Absicht zu unterstellen, wenn ein IHV mal langsamer läuft, wenn ein 3. Code schreibt. Im Zweifelsfall sind beide eben nicht optimal füreinander (siehe auch Hübies Post).


Deswegen schreibe ich ja "nominell" und "faktisch". Natürlich ist Freesync ein offener Standard, Stand jetzt binde ich mich aber an einen IHV, mit der Aussicht auf einen zweiten, der bezüglich dGPU keine Rolle spielt.
In der Hinsicht (und nur in der Hinsicht) besteht kein Unterschied zu der Situation mit G-Sync.

Die künftige Möglichkeit ist auch insoweit ein (wichtiger) Unterschied. Die meisten behalten ihren Monitor ja ein paar Jahre.

Aber bei diesem Thema sind wir reichlich OT.

[-/\-CruNcher-/\-]

Es geht nicht nur um Ashes NV muss eine allgemeine Lösung finden,da viele Konsolenport's diese Technik verwenden werden um mehr Power aus der PS4/XBox One zu locken.

Mehr Power aus der PS4 und Xbox One heist nicht automatisch mehr Power aus dem PC du verlgleichst hier 2 komplett unterschiedliche Ökosysteme und deren Anforderungen ;)
Nicht viele sachen die AC auf den Konsolen sind werden es überhaupt auf den PC Schaffen, Igor versucht dir das auch mit der Parallelisierbarkeit zu erklären in seinem Artikel und warauf es ankommt das sich die Effizienz und der Aufwand überhaupt lohnt es so umzusetzen. ;)

Igor du übertriffst dich mal wieder selbst Top Artikel deine Noise Filter Methode aus den Frametimes ist nice, jetzt Kühl dich aber mal ordentlich runter verdammt du wachst andauernd aus dem idle auf ;)

[Ätznatron]

Mehr Power aus der PS4 und Xbox One heist nicht automatisch mehr Power aus dem PC du verlgleichst hier 2 komplett unterschiedliche Ökosysteme und deren Anforderungen ;)
Nicht viele sachen die AC auf den Konsolen sind werden es überhaupt auf den PC Schaffen, Igor versucht dir das auch mit der Parallelisierbarkeit zu erklären in seinem Artikel und warauf es ankommt das sich die Effizienz und der Aufwand überhaupt lohnt es so umzusetzen. ;)

Igor du übertriffst dich mal wieder selbst Top Artikel deine Noise Filter Methode aus den Frametimes ist nice, jetzt Kühl dich aber mal ordentlich runter verdammt du wachst andauernd aus dem idle auf ;)

Und das meint Nai, u.a. bekannt als Programmierer von "Nai's benchmark", zur Problematik: (http://www.computerbase.de/forum/showthread.php?t=1563013&page=30&p=18529684#post18529684)

NVIDIAs Aussage kommt mir persönlich auch etwas komisch vor. Nicht nur weil es so lange dauert, sondern weil Async Compute nicht besonders schwer im Treiber zu implementieren sein sollte. Async Compute künstlich zu deaktivieren sollte sogar deutlich schwerer programmieren zu sein, anstatt es einfach aktiviert zu lassen. Denn wenn ein Treiber Async-Compute künstlich deaktiviert, so muss der Treiber zusätzliche Synchronisationspunkte für Graphik und Compute einbauen. Eben diese zusätzliche Synchronisation würde bei aktivierten Async-Compute wegfallen. Die einzige erklärung die mir dazu einfällt wäre, dass dieser Teil des Treibers für alle Geforce-GPUs (also auch für die ohne Async Compute) noch gleich ist, wodurch eben auch die künstliche Beschränkung nötig ist.

Wie plausibel das jetzt ist, kann ich nicht beurteilen, aber ich glaube kaum, das Nai seine Reputation aufs Spiel setzt mit haltlosen Behauptungen.

[dildo4u]

Was soll daran simpel sein wenn man Hardware Fähigkeiten mit Software emulieren muss?Wenn das am Ende in Echtzeit Vorteile bringen soll erscheint mir das als sehr aufwendig.

[Ätznatron]

Was soll daran simpel sein wenn man Hardware Fähigkeiten mit Software emulieren muss?Wenn das am Ende in Echtzeit Vorteile bringen soll erscheint mir das als sehr aufwendig.

Nai wundert sich doch nur über nVidia.

Und bietet am Ende einen möglichen Grund für eine künstliche Treiber-Beschränkung. Diese setzt aber voraus, dass entsprechende Hardwareeinheiten auf Maxwell verfügbar sein müssen, um letztlich keine lahme Softwareemulation zu benötigen.

Wunder gibts ja angeblich immer wieder...;)

[Achill]

Mehr Power aus der PS4 und Xbox One heist nicht automatisch mehr Power aus dem PC du verlgleichst hier 2 komplett unterschiedliche Ökosysteme und deren Anforderungen ;)
Nicht viele sachen die AC auf den Konsolen sind werden es überhaupt auf den PC Schaffen, Igor versucht dir das auch mit der Parallelisierbarkeit zu erklären in seinem Artikel und warauf es ankommt das sich die Effizienz und der Aufwand überhaupt lohnt es so umzusetzen. ;)


Das konnte man vielleicht noch bei den alten Konsolen zu recht sagen, bei den Neuen Konsolen ist dies so (verallgemeinert) nicht gültig.

PS4 und XBox One bauen bei auf der CPU- und GPU-Hardware von PCs auf, damit kann es zwar unterschiedliche BS+APIs geben, der Kern bleibt aber sehr ähnlich zwischen Konsolen und PC:
- 2x4-x64-Cores (CPU Teil)
- GCN 1.0 (GPU Teil)
- 256bit DDR3 bzw. GDDR5 RAM

D.h. das sämtliche Algorithmic (natürlich angepasst an die jeweilige API) ohne weiteres Portiert werden kann, da es keine "wirklichen" Hardware-Unterschiede gibt. Problematisch kann es werden, wenn eine API die entsprechende Funktionalität nicht bietet. Mit zwei LL-APIs (DX12/Vulkan) - die m.W. auch jeweils auf einer Konsole kommen wird - ist dieses Problem/Hürde dann auch abgeschafft.

Der wirkliche Unterschied ist m.E. der Shared-Memory da man einfach das Spiel für 7.5GB RAM (vereinfacht) designed (k.a. was das BS von der P4 / X1 so haben will).
Portiert man sowas, dann ist der einfachste Ansatz (Spekulation) die 7.5GB - mehr oder Weniger - auf dem PC im RAM und VRAM zu halten. Natürlich braucht man weniger, wenn ab auf der Konsole ein einer Szene 6GB Texturen + Daten (willkürliche Annahme) zu sehen sind, dann muss man auf dem PC bei weniger als 6GB VRam schon ein bisschen Arbeiten - und wir kennen ja die Streuung der Ergebnisse.

Sprich, da die CPU und GPU sehr ähnlich ist, spricht nichts gegen Parallelisierung, AC, Wiederverwendung von Shadern, Texturen, Daten - was Probleme (Richtung PC) in vielfältiger Hinsicht machen kann, ist der Shared RAM und die geringe (nicht existente) Latenz wischen klassischen RAM und VRAM sowie keine Daten schupsen über einen PCIe-Bus (aka Streamen).

---
Edit: Noch ein Gedanke, evtl. sehen wir ja auch schon ein paar Auswirkungen bei den neusten Spielen (k.a. ob das Portierungen waren), wo CPUs deutlich von mehr Bandbreite zum RAM profitieren.

[Knuddelbearli]

Verstehe die Aufregung hier nicht, wenn interessieren hier noch Maxwells und Grenadas und noch mehr alte Schinken, viel interessanter wäre es doch, wie Pascal mit DX12 "umgeht" Polaris wird wohl sowieso sehr gut mit DX12 auskommen. Ich verstehe ja das momentan micht viel los ist im PC Markt (kauft euch doch einen neuen Monitor mit 144hz, 4K, oder 21:9 ) Aber in ein paar Monaten interessiert das eh niemanden mehr wie Maxwell unter DX12 läuft, da er eh schon wieder zu langsam ist.


Die meisten Leute ( auch viele von hier ) Nutzen die Grafikkarten aber deutlich länger ...

Wenn die 970 nicht so verküppelt* wäre würde ich wohl auch bis 10nm warten.

*3,5Gb, dann wird zusätzlich "4"gb langsam schon knapp, dazu eben kein asyncron shader.

[aufkrawall]

Kleine spekulative Vorausschau:
-Bei Hitman wird mit AC AMD NV ähnlich abziehen wie bei AoS.
-Mit DX12 wird Quantum Break wohl zu den XB1-Ports gehören, die ähnlich wie Ryse ebenfalls sehr schnell auf GCN laufen werden. Spätestens, wenn AC genutzt wird.
-Bei Fable early beta war Hawaii mit DX12 schon extrem stark.

Imho gibt es wenig Grund daran zu zweifeln, dass auch die kommenden DX12-Spiele sehr schnell auf AMD laufen werden.
Dazu kommen noch Frostbite-Spiele mit DX11. Wenn Need for Speed mit KI-Fahrern nicht CPU-limitiert auf AMD ist, wird es Mirror's Edge höchstwahrscheinlich auch nicht sein.
Das wird hier oder in anderen Threads noch lustig abgehen. :D

[dargo]

Wann wollte DICE eigentlich die Frostbite komplett auf DX12 umsatteln? Erst Ende 2016?

[aufkrawall]

Es gibt kein konkretes Versprechen für eine Garantie für ein bestimmtes Datum.
Andersson meinte, er hoffe für Ende 2016 auf DX12 only, aber das würd ich rückblickend eher als PR-Aussage einstufen. Außerdem wollte man ja Mantle durch Vulkan ersetzen.

Edit: 12 latürnich...

[dargo]

Dem guten Johan Andersson kann es nicht schnell genug gehen. :D
http://www.pcgameshardware.de/DirectX-12-Software-255525/News/Frostbite-Mass-Effect-Andromeda-Mirrors-Edge-Catalyst-1175052/

Der entsprechende DX12 Renderpfad ist also schon seit Oktober 2015 in Frostbite drin. Das lässt mich hoffen, dass das neue NfS eventuell schon mit DX12 kommt. Würde auch die Verschiebung um die paar Monate erklären (ja, ich weiß auch, dass die an der Physik arbeiten um das 30fps Limit für den PC zu beseitigen). Schauen wir mal.

[aufkrawall]

Diese Hoffnungs-Diskussion hatten wir schon ein paar Mal...

[Ex3cut3r]

Öhm... takte doch beide GPUs runter. ;)


Es interessiert Millionen von Spielern außerhalb "Freak"foren wie 3DC & Co die nicht bei jeder Generation wechseln. Ich weiß, ist für so manchen Member hier befremdlich.

Ja klar, und dann wechseln hier im Forum doch schon wieder alle spätestens dann es wieder Titan X Leistung mit verkrüppelten Speicher Interface und sagenhaften 7,5 GB Vram aber für 330€ gibt.

Die Geschichte höre ich seit Jahren, die "ne ich wechsel nicht Leute, sind meistens die Leute die an Day1 schon wieder den bestellknopf drücken.

[dargo]

Mich kannst du damit nicht meinen. ;) Zudem meinte ich die Spieler außerhalb von 3DC & Co. Natürlich würde ich auch wechseln wenn mich Polaris in jeder Hinsicht überzeugt und das Angebot verlockend ist. Mein letzter Wechsel von Tahiti hatte mich afaik 180€ gekostet. Die Mehrleistung hält sich zwar in Grenzen (normalerweise möchte ich um die +100% haben), aber Freesync war es mir auf jeden Fall wert. Und jetzt dank DX12 + AC steigt nochmal die Leistung gegenüber Tahiti. Passt also in etwa. :)

[Knuddelbearli]

mich auch nicht vor der 970 hatte ich immer noch ne 480 ^^

[Gipsel]

Mal exemplarisch dieses Zitat:
NV hat Treiber support in Aussicht gestellt daher wird es drin bleiben.
Es gibt nur keine Support im aktuellen Game Ready Treiber.

https://twitter.com/PellyNV/status/702556025816125440
Die entsprechenden Aussagen von nV klingen für mich ziemlich nach Bullshit. AC ist ja eigentlich kein Feature, das im Treiber an- oder ausgeschaltet wird. Mit DX12 kann eine Anwendung schlicht Queues verschiedener Typen "erzeugen" (das ist erstmal die Softwaresicht) und benutzen (direct [frißt alles], compute [nur compute + copy], copy), zusätzlich kann noch hohe oder niedrige Priorität für die jeweilige Queue angefordert werden. Das wird von der DX12-API so gefordert und jeder DX12 kompatible Treiber muß damit auch klarkommen. Auch bei nV funktioniert das natürlich. Insofern kommt auch nV mit AC klar und es ist aktiviert (der Treiber schmiert ja nicht ab, wenn es benutzt wird, oder? ;)).

Was Microsoft nicht festgelegt hat, ist, wie das dann genau abgearbeitet wird. Lediglich die entsprechenden Barrieren und explizit definierten Synchronisationspunkte müssen eingehalten werden. Die Idee ist im Prinzip, daß ein Entwickler die zu erledigenden Aufgaben über die API dem Treiber/der GPU gewissermaßen strukturierter anbieten kann, so daß mehr Parallelität einfacher nutzbar wird. Es ist aber von MS nicht gefordert, daß diese Parallelität auch immer durch die Treiber-/GPU-Kombo vollständig genutzt wird. Dies ist natürlich die Hoffnung des Entwicklers, der sich davon Performancezuwächse verspricht (z.B. für viele kleinere Compute-Jobs, die eventuell irgendwie über den Frame verteilt abgearbeitet werden müssen). Der Entwickler kann also z.B. darauf hoffen, daß mehrere seiner Queues auch wirklich parallel und gleichzeitig auf der Hardware zur Ausführung kommen. Für die korrekte (auch asynchrone) Ausführung erforderlich ist das aber nicht. Eine komplette Serialisierung ist ein erlaubtes Vorgehen.

Bei AMD klappt das Mapping dieses Konzepts auf die Hardware offenbar relativ unproblematisch. Es gibt nicht nur einen GCP sondern auch noch mehrere Compute-Queues in Hardware, die auch tatsächlich parallel arbeiten und Wavefronts an die Shader absetzen können und zudem verschiedene Prioritäten unterstützen. Dabei können im Shaderarray alle Shadertypen gleichzeitg laufen und dynamisch gemischt werden. Sogar auf einer einzelnen CU können gegebenenfalls verschiedene Grafik- und Computeshader gleichzeitig laufen. Es existiert praktisch kaum ein Penalty für einen Kontextswitch. Ob nach Beendigung einer Wavefront eines Shaders die nächste Wavefront des gleichen oder eine Wavefront eines anderen zur Ausführung kommt, interessiert eine CU nicht sonderlich. Die Granularität von Kontextswitches ist eine einzelne Wavefront (bzw. Work-/Threadgroup bei Compute). Preemption ist dafür nicht nötig (wäre es nur, wenn die komplette GPU mit einem extrem lange laufendem Shader voll wäre und da gibt es die Möglichkeit, ein paar Ressourcen für wichtige Dinge zum Zwischenschieben freizuhalten [was kaum Performance kostet]).

NVidia dagegen hat offenbar Probleme mit diesem direkten Mapping auf die Hardware. So existieren Aussagen von nV, daß die Kontextswitch-Granularität immer ein kompletter Drawcall sei. Dies ist laut nVidia selber eine Einschränkung der Hardware, die erst mit (unspezifizierten) zukünftigen Hardwaregenerationen gelöst werden soll. Das Mischen von Grafik- und Computeshadern auf dem Level einzelner SMs ist offenbar nicht möglich. Der Switch eines SMs zwischen Grafik und Compute verursacht offenbar eine deutliche Penalty. NV empfiehlt daher, Compute zu Bundeln und gerade nicht immer kleinere Computejobs parallel abzusetzen, wie das bei echt konkurrenter Ausführung wohl meist optimal wäre.
Für bestimmte Situationen erscheint es möglich, daß nV in Zukunft das HyperQ-Feature nutzt, um den momentanen Nachteil etwas auszugleichen (aber offenbar kann HyperQ nicht alles Erforderliche [gerüchteweise hängt es an den Synchronisationsmöglichkeiten], sonst hätten wir das schon längst gesehen bzw. entsprechende Hinweise an Entwickler nicht gesehen). Diese Umsetzung ist also vermutlich nicht trivial. Es gibt also eventuell irgendwann mal Treiber-Magie und entsprechende Spielprofile, mit denen die Compute-Jobs soweit wie möglich gesammelt und gebundelt werden und teilweise über die HyperQ abgesetzt werden, falls das geht. Eine allgemeine Lösung ist das aber nicht. Diese heißt dann hoffentlich Pascal (mit Pech erst Pascal v2 oder Volta).

TLDR:
Der aktuelle nV-Treiber unterstützt natürlich Asynchronuous Compute. Grafik und Compute können aber wohl aufgrund von Hardwarelimitierungen nicht wirklich konkurrent ausgeführt werden und im Zweifelsfall kann die GPU von der Kontext-Switch-Penalty ausgebremst werden. Wirkliche Abhilfe bringt erst neue Hardware, per Treiber kann das Defizit vielleicht punktuell gelindert werden.

[Hübie]

Die Fence und Barriers werden aber auf beiden IHV anders behandelt (bei nV immer am Ende einer Batch). Und das ist es was ich meine. Man kann sich ja die Arbeit für beide aufhalsen. Ebenso das batchen (wird vielleicht gemacht - k.A.).
Standardmäßig ist der Treiber für GeForce auf Durchsatz eingestellt (TOC). Würde das auf Latenz gestellt (LOC), dann hätte man - zumindest via CUDA - doch grundlegend schon mal den Fall dass AC in dem o.g. Sinne funktioniert.
Blöd ist halt dass immer der L1 vollständig geleert werden muss und wenn da jetzt durch preemption ein Job kurz vor Beendigung gecancelt wird frisst das einfach derbe Performance. Oxide könnte sich wie gesagt hinsetzen und beides implementieren. Per DX12 ist nämlich gar nicht explizit festgelegt, dass die Hardware so und so viel Queues schedulen kann, muss, darf, soll (und auch nicht das wie).

[Gipsel]

Nur mal nebenbei: Heutige GPUs machen keine Preemption von laufenden Wavefronts/Warps. Das kommt erst irgendwann in Zukunft. Daß nV von Preemption an Drawcall-Grenzen spricht, zeigt nur mal wieder die typische Begriffsverwirrung in dem Feld. Daß nach einem Drawcall ein anderer abgesetzt werden kann, sollte man schon irgendwie erwarten können oder? Für die Shadereinheiten ist das keine Preemption. Nur mit gutem Willen kann man das aus einer extrem high level Sicht vielleicht für den Commandprozessor so nennen (falls es kein paralleles Issue mehrerer Queues gibt und auch kein barrel processing mehrerer Queues über einen einzelnen Issue-Port des Commandprocessors).

Und was soll das heißen, daß bei nV (im Gegensatz zu AMD) Barriers/Fences immer erst am Ende eines Batches behandelt werden? Wie soll das denn gehen? Das Verhalten ist von der API vorgegeben. Gleicher Code liefert auf GPUs beider Hersteller das gleiche Ergebnis. Da muß Nichts (und sollte auch nicht!) für jeden IHV groß anders gemacht werden.

Und was hier die latency optimized cores (LOCs) und throughput optimzed cores (TOCs) aus nVs HPC-Präsentationen damit zu tun haben, weiß ich jetzt auch nicht. :rolleyes:

Btw., daß nicht spezifiziert ist, wie AC genau ausgeführt wird (Hauptsache das Ergebnis stimmt, Serialisierung ist aus dieser Sicht okay, die Performance leidet dann aber), hatte ich ja schon geschrieben. Aber die Möglichkeit der konkurrenten Ausführung wie bei AMD ist prinzipiell besser (und es ist völlig klar, daß dies mit dem Design der API einfach ermöglicht werden soll). Geht das nicht, gehen einem gewisse potentielle Performancevorteile verloren, egal wie viel ich batche und adaptiere. Und es sind bestimmt auch Fälle denkbar, wo das Batchen schwieriger ist, man verliert also Flexibilität bei seinen Algorithmen, will man keine Performance auf der Strecke lassen. Das könnte man im Ansatz fast schon mit der Diskussion um Codeoptimierung bei in-order und out-of-order CPUs vergleichen ;).

[dargo]

Hat eigentlich jemand eine Erklärung warum die MSI 390X mit AC so stark (+~22%) zulegt? Ich meine die legt sich dann ja schon mit einer übertakteten GTX980TI an. :freak:

http://media.bestofmicro.com/D/G/561652/gallery/AsyncCompute_On_Off_w_600.png

Grenada Pro und Fury X bewegen sich bei +11-12%. Tonga XT liegt zwar auch recht hoch mit +25%. Dieses Ergebnis lasse ich aber außen vor da die Frames schon dermaßen niedrig sind, dass es irrelevant ist. Vielleicht gibts hier auch eine Art Grundlast wie bei CPUs. Wo der Zuwachs dann überproportional steigt.

[Digidi]

Ich vermute mal es liegt an der relative hohen Shaderanzahl von Hawaii. Die können dank AC nun richtig gut belastet werden und deshalb holt Hawaii hier mächtig was raus.

[dargo]

Ja... ok, Grenada XT hat ja immerhin 10% mehr Shader als Grenada Pro und die MSI 390X hat mit 1100Mhz auch einen recht hohen Takt. Keine Ahnung ob hier AC mit höheren Taktraten ebenfalls besser skaliert. Aber nur an den Shadern kannts ja nicht liegen, da müsste Fiji viel mehr zulegen. Ok, bei zwei verschiedenen Architekturen ist das wieder so ne Sache.

btw.
Die GTX960 wird in den "spielbaren" Auflösungen von Tonga XT (Tonga Pro ist nicht so viel langsamer) aber so richtig überrollt. :usweet:
54973 54974

Ist mir bisher noch gar nicht aufgefallen. Bin gespannt ob NV hier noch was richten kann.

PS: bei so einem großen Unterschied wäre mal ein Effizienzvergleich (fps/W) interessant. ;)

[Knuddelbearli]

Wieso sollte sie das auch nicht? Rohleistung hat sie ja weit mehr als die 980 bekam sie bisher nur nicht ausgelastet. AC erhöht eben die Auslastung der Recheneinheiten.

[dargo]

Wenns nur die Shader sind passt mir halt die Skalierung von Fiji nicht so ganz. Fiji XT skaliert mit AC "nur" wie Grenada Pro. Möglich wäre natürlich auch, dass Fiji noch mehr "Pflege" vom Entwickler braucht. Da müssen wir wohl die finale Spielversion abwarten.

Edit:
Am besten wäre es wenn Igor die MSI 390X auf den Takt der Powercolor 390 non X bringen könnte und nochmal benchen. Das würde mehr Klarheit ins Bild bringen. Es wäre schon ziemlich strange wenn 10% mehr Shader doppelt von AC profitieren würde.

[dildo4u]

Ja... ok, Grenada XT hat ja immerhin 10% mehr Shader als Grenada Pro und die MSI 390X hat mit 1100Mhz auch einen recht hohen Takt. Keine Ahnung ob hier AC mit höheren Taktraten ebenfalls besser skaliert. Aber nur an den Shadern kannts ja nicht liegen, da müsste Fiji viel mehr zulegen. Ok, bei zwei verschiedenen Architekturen ist das wieder so ne Sache.

btw.
Die GTX960 wird in den "spielbaren" Auflösungen von Tonga XT (Tonga Pro ist nicht so viel langsamer) aber so richtig überrollt. :usweet:
54973 54974

Ist mir bisher noch gar nicht aufgefallen. Bin gespannt ob NV hier noch was richten kann.

PS: bei so einem großen Unterschied wäre mal ein Effizienzvergleich (fps/W) interessant. ;)
Vieleicht hat die 960 nur 2GB?Und warum sind unter 1080p die min fps bei großen Nvidia Karten besser?

[(del)]

Vieleicht hat die 960 nur 2GB?Und warum sind unter 1080p die min fps bei großen Nvidia Karten besser?ich habe die 2GB- und die 4GB-Variante hier. Bei 1080p ist die 2GB sogar einen Tick schneller, da das knickrige Interface nicht so zugeballert wird. :)

[dargo]

Vieleicht hat die 960 nur 2GB?
Keine Ahnung, ist nicht angegeben. Müsste sich Igor zu äußern. Aber selbst in 1080p reichen die 2GB nicht mehr?

Edit:
Ups... zu langsam. X-D

[fondness]

Mal exemplarisch dieses Zitat:

Die entsprechenden Aussagen von nV klingen für mich ziemlich nach Bullshit. AC ist ja eigentlich kein Feature, das im Treiber an- oder ausgeschaltet wird. Mit DX12 kann eine Anwendung schlicht Queues verschiedener Typen "erzeugen" (das ist erstmal die Softwaresicht) und benutzen (direct [frißt alles], compute [nur compute + copy], copy), zusätzlich kann noch hohe oder niedrige Priorität für die jeweilige Queue angefordert werden. Das wird von der DX12-API so gefordert und jeder DX12 kompatible Treiber muß damit auch klarkommen. Auch bei nV funktioniert das natürlich. Insofern kommt auch nV mit AC klar und es ist aktiviert (der Treiber schmiert ja nicht ab, wenn es benutzt wird, oder? ;)).


Wichtiger Punkt den du hier ansprichst, Nvidia unterstützt natürlich AsycCompute im Treiber, ansonsten wäre sie nämlich gar nicht DX12 kompatibel. Das der Treiber dann im Hintergrund das ganze wohl weitgehend serialisiert, ist eine andere Geschichte. Die Aussage man habe noch gar kein AC im Treiber ist also schlicht falsch. Und es mag auch sein, dass man hier durch aufwändige Analysen in Software noch besser optimieren kann als zurzeit, aber man wird nie fehlende HW-Fähigkeiten ausgleichen können.

[AnarchX]

GK104 profitiert wohl sehr gut: http://www.anandtech.com/show/10067/ashes-of-the-singularity-revisited-beta/5 ... GPCs mit 2 SMX sind wohl eine bessere Ausgangsbasis als GPCs mit 3SMX/4SMM? Ein Nachtest mit einer 4GiB Version wäre wohl noch sinnvoll.

[dildo4u]

Könnte auch besseres Vram Management unter DX12 sein,die anderen Karten haben alle 3GB+.

[(del)]

Keine Ahnung, ist nicht angegeben. Müsste sich Igor zu äußern. Aber selbst in 1080p reichen die 2GB nicht mehr?

Edit:
Ups... zu langsam. X-D

Di 960er ist einfach zu schwach. So sehr mir sie für die Einsteiger-Mittelklasse gefällt, da fehlt einfach was. :)

[AnarchX]

Wird Zeit das Polaris 10 sie in die Richtung von 100€ drückt, wo sie gemäß ihren Materialkosten hingehört. :D

[Achill]

Ja... ok, Grenada XT hat ja immerhin 10% mehr Shader als Grenada Pro und die MSI 390X hat mit 1100Mhz auch einen recht hohen Takt. Keine Ahnung ob hier AC mit höheren Taktraten ebenfalls besser skaliert. Aber nur an den Shadern kannts ja nicht liegen, da müsste Fiji viel mehr zulegen. Ok, bei zwei verschiedenen Architekturen ist das wieder so ne Sache.

btw.
Die GTX960 wird in den "spielbaren" Auflösungen von Tonga XT (Tonga Pro ist nicht so viel langsamer) aber so richtig überrollt. :usweet:
54973 54974

Ist mir bisher noch gar nicht aufgefallen. Bin gespannt ob NV hier noch was richten kann.

PS: bei so einem großen Unterschied wäre mal ein Effizienzvergleich (fps/W) interessant. ;)

Die Werte passen doch wenn man sich überlegt, dass die MSI 390X mit 1100/1500 läuft. Im Vergleich dazu die 'alte' 290X mit 1040/1300 (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10954385#post10954385) - die ist nicht so weit weg ~6fps von der MSI.

[dargo]

Di 960er ist einfach zu schwach. So sehr mir sie für die Einsteiger-Mittelklasse gefällt, da fehlt einfach was. :)
Naja... mir gehts eher um die krasse Leistungsklassen-Verschiebung zwischen GM206 und Tonga bei DX12 + AC. Hast du zufällig Tonga Pro da? In 1440p dürfte Tonga Pro immer noch 80-100% vor GM206 liegen. Solche Ergebnisse kenne ich aus keinem DX11 Spiel. Im High-End Bereich gibt es solche krassen Leistungsklassen-Verschiebungen auch nicht.

Die Werte passen doch wenn man sich überlegt, dass die MSI 390X mit 1100/1500 läuft. Im Vergleich dazu die 'alte' 290X mit 1040/1300 (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10954385#post10954385) - die ist nicht so weit weg ~6fps von der MSI.
Ich glaube mich versteht keiner. :freak:

Es geht mir um die Relation zwischen DX12 AC On/Off bei der jeweiligen Karte. Und da sieht es so aus, dass die MSI doppelt so stark von AC profitiert als die Powercolor obwohl sie nur 10% mehr Shader hat. Klingt für mich erstmal merkwürdig, oder ich bin noch nicht ausgeschlafen. :D

PS: du benchst in 1080p, ich beziehe mich hierbei hauptsächlich auf den 4k Test.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10956079&postcount=1569

[Achill]

GK104 profitiert wohl sehr gut: http://www.anandtech.com/show/10067/ashes-of-the-singularity-revisited-beta/5 ... GPCs mit 2 SMX sind wohl eine bessere Ausgangsbasis als GPCs mit 3SMX/4SMM? Ein Nachtest mit einer 4GiB Version wäre wohl noch sinnvoll.

Das ist doch sehr interessantere Messung:

http://images.anandtech.com/graphs/graph10067/80319.png

Der Erklärungsversuch ist m.E. natürlich sehr naiv:
Finally, right in the middle of all of this is the GTX 680. Given what happens to the architecturally similar GTX 780 Ti, this may be a case of GPU memory limitations (this is the only 2GB NVIDIA card in this set), as there’s otherwise no reason to expect the weakest NVIDIA GPU to benefit the most from DX12.


Ein möglich Lösung wäre, dass die Karte nicht von den DX11 Optimierungen profitiert oder ... *hust* ausgeschlossen ist *hust*.

[dargo]

Die hätten für den Vergleich vielleicht besser eine GTX770 nehmen sollen. Ich meine ok... die 600-er Reihe ist auch Kepler. Aber wer weiß schon wie die NV-Treiber da ticken. ;)

[Unicous]

Wird Zeit das Polaris 10 sie in die Richtung von 100€ drückt, wo sie gemäß ihren Materialkosten hingehört. :D

Brauchst du eine günstige PhysX-Karte oder was?:confused:

:tongue:

[Knuddelbearli]

Die hätten für den Vergleich vielleicht besser eine GTX770 nehmen sollen. Ich meine ok... die 600-er Reihe ist auch Kepler. Aber wer weiß schon wie die NV-Treiber da ticken. ;)

Naja dann sieht man halt umsobesser wie es 970 Usern gehen wird ;-)

[dildo4u]

Ich ziehe daraus das Kepler wohl doch nicht so veraltet ist wie oft behauptet wird und es gibt auch keine Benachteiligung per Treiber.Die 780 Ti ist auch stark besser als die 970.AMD versagt wie unter Mantle wenn nicht genug Vram da ist.(285 2GB)


http://abload.de/img/80357b0rl2.png

http://www.anandtech.com/show/10067/ashes-of-the-singularity-revisited-beta/3

CB hat die 970 im Schnitt vor der 780 Ti.

http://www.computerbase.de/thema/grafikkarte/rangliste/#abschnitt_aktuelle_ranglisten

[dargo]

Naja dann sieht man halt umsobesser wie es 970 Usern gehen wird ;-)
Du bist so gemein. :D

[ChaosTM]

Nach über 12 Jahren kauft man sich wieder einmal eine Nvidia Karte und dann "versemmeln" sie es gerade bei dieser Generation. :P ;)

Bereuen tue ich den Kauf (edit: 980ti) aber trotzdem nicht, denn für aktuelle Spiele gibt es nix besseres und wir wissen auch noch nicht, ob sich dieser Trend durch alle DX12 Spiele ziehen wird.
Das wird davon abhängen wie wichtig diese Implementierung allgemein sein wird und ob NV es schafft die Entwickler zu überzeugen, das Teufelszeug AC nicht zu verwenden. ;)

Hoffentlich wurde das AS -Versäumnis bei Pascal ausgebügelt, sonst bin ich sehr schnell wieder bei der Konkurrenz.

Neben der leichten Enttäuschung überwiegt aber dennoch die Vernunft-Freude.
Für uns Kunden ist es extrem wichtig, dass AMD überlebt und konkurrenzfähig bleibt, ansonsten würden die Kartenpreise völlig durch die Decke gehen.

[dildo4u]

Naja dann sieht man halt umsobesser wie es 970 Usern gehen wird ;-)

Die 680 mit wenig Vram läuft gut soll ein schlechtes Zeichen für die 970 sein?Eure Post's machen immer weniger Sinn.

[dargo]

AMD versagt wie unter Mantle wenn nicht genug Vram da ist.(285 2GB)

Aha...
http://www.planet3dnow.de/cms/9983-thief-patch-1-5-bringt-crossfire-fuer-mantle-api-und-senkt-vram-verbrauch/

[dildo4u]

Zu dem Fazit kommt Anandtech.

The one outlier here is the Radeon R9 285, which is the only 2GB RTG card in our collection. At this point we suspect it’s VRAM limited, but it would require further investigation.

Mantle hatte immer Probleme so lange die Karte keine 4GB hatte die 7970/280 liefen nie gut.

[Kartenlehrling]

@ChaosTM
Ja, die Einstellung ist gut ..."AMD darf nicht sterben, meine nächste Nvidia gtx1080 muss ja noch bezahlbar sein."

[kruemelmonster]

GK104 profitiert wohl sehr gut: http://www.anandtech.com/show/10067/ashes-of-the-singularity-revisited-beta/5 ... GPCs mit 2 SMX sind wohl eine bessere Ausgangsbasis als GPCs mit 3SMX/4SMM? Ein Nachtest mit einer 4GiB Version wäre wohl noch sinnvoll.

Auf meinem GK104 kostet AC ~10%: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10956637&postcount=22 statt laut AT 20% zu bringen. Für Hintergrundinformationen ist die Seite mit die Beste, nur benchen können sie leider nicht. nur richtig lesen kann ich manchmal nicht, siehe Post #1637.

[ChaosTM]

@ChaosTM
Ja, die Einstellung ist gut ..."AMD darf nicht sterben, meine nächste Nvidia gtx1080 muss ja noch bezahlbar sein."

Das höre ich sehr oft von Hardcore NV Fanboys ;)

[fondness]

Nach über 12 Jahren kauft man sich wieder einmal eine Nvidia Karte und dann "versemmeln" sie es gerade bei dieser Generation. :P ;)


Als ob das nicht schon lange üblich wäre. Die GTX680 liegt heute deutlich schlechter als zum Launch, die 780Ti ebenfalls, und für die GTX970/980 wird dasselbe gelten. Hawaii wird nicht nur die 780Ti überleben, sondern auch GM204.

[dargo]

Auf meinem GK104 kostet AC ~10%: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10956637&postcount=22 statt laut AT 20% zu bringen. Für Hintergrundinformationen ist die Seite mit die Beste, nur benchen können sie leider nicht.
Interessant... dann würde ich vermuten, dass anandtech die Werte bei der GTX680 im Diagramm einfach nur vertauscht haben. Kann passieren im Eifer des Gefechts.

[Achill]

Die 680 mit wenig Vram läuft gut soll ein schlechtes Zeichen für die 970 sein?Eure Post's machen immer weniger Sinn.

Nein es geht darum, dass die älteren 600er Karten nicht die DX11 Optimierung von NV bekommen haben bzw. dies zumindest nicht in AotS / es so zumindest aussieht.

Auf die 970 wird nur angespielt, weil es sein kann, dass diese immer ein 'gewisses extra Tuning' für bestimmte Spiele braucht, immer dann wenn diese mehr als 3.5GB VRam haben wollen.
=> Achtung! ich sage nicht, dass >3.5GB VRam Verbrauch nicht geht oder Probleme verursachen muss.

Nochmal im kompletten Überblick (die 2GB limitieren bzgl. Auflösung) von anandtech.com (http://www.anandtech.com/show/10067/ashes-of-the-singularity-revisited-beta/5):

http://images.anandtech.com/graphs/graph10067/80318.png

Ich freu mich auch für die Kepler-Besitzer, dass die von DX12 profitieren.

[dildo4u]

Als ob das nicht schon lange üblich wäre. Die GTX680 liegt heute deutlich schlechter als zum Launch, die 780Ti ebenfalls, und für die GTX970/980 wird dasselbe gelten. Hawaii wird nicht nur die 780Ti überleben, sondern auch GM204.
Wie kommst du zu dem Schluss wenn die 680 unter DX12 dicht an der 7970 ist,die mehr Vram und deutlich mehr Compute Leistung hat.

http://abload.de/img/80357b0rl2.png

Kepler sieht für mich hier fertig optimiert aus eher braucht Maxwell noch Treiber arbeit und das sind NV's aktuelle Karten.

[ChaosTM]

Als ob das nicht schon lange üblich wäre. Die GTX680 liegt heute deutlich schlechter als zum Launch, die 780Ti ebenfalls, und für die GTX970/980 wird dasselbe gelten. Hawaii wird nicht nur die 780Ti überleben, sondern auch GM204.

Ganz extrem war es damals bei 7900 vs 1900XT. Anfangs war die NV Karte minimal schneller aber nach 2 Jahren gab es Titel, wo die AMD Lösung fast doppelt so schnell war...

Das soll aber jetzt bitte nicht wieder in einen Fanboy War ausarten.. PLS!

[PHuV]

Wieso wird mir im Benchmark nur DX11 angeboten, obwohl ich beim ersten Spielstart DX12 angegeben habe? Kann ich das irgendwie umstellen?

[Gipsel]

Wie kommst du zu dem Schluss wenn die 680 unter DX12 dicht an der 7970 istVermutlich weil sie 10% dahinter ist, statt 5-10% davor, wie zum Launch oftmals getestet?

[Der_Korken]

Man sieht in dem Diagramm oben, dass die 780Ti doppelt so schnell wie die 680 ist. Normalerweise ist der Unterschied vielleicht 50%, wenn nicht gerade der VRAM limitiert. Unter DX12 wird das Verhältnis wieder etwas gerade gerückt. Aber eigentlich muss einem sowas doch beim Testen auffallen, dass die DX11 Ergebnisse nicht zusammenpassen.

[dildo4u]

Wieso wird mir im Benchmark nur DX11 angeboten, obwohl ich beim ersten Spielstart DX12 angegeben habe? Kann ich das irgendwie umstellen?
Du musst immer DX12 extra auswählen das merkt er sich nicht,oder du machst ne Verknüpfung zur DX12 exe.

Vermutlich weil sie 10% dahinter ist, statt 5-10% davor, wie zum Launch oftmals getestet?
Weil AMD ihre GPU's unter DX11 nicht ausgelastet hat,von den Spces her muss die 7970 doch schneller sein.

[Gipsel]

Auf meinem GK104 kostet AC ~10%: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10956637&postcount=22 statt laut AT 20% zu bringen. Für Hintergrundinformationen ist die Seite mit die Beste, nur benchen können sie leider nicht.Richtig lesen! DX12 bringt laut AT 20%, AC kostet 3% in deren Test (1080p).

[PHuV]

Du musst immer DX12 extra auswählen das merkt er sich nicht,oder du machst ne Verknüpfung zur DX12 exe.
Und wo mache ich das genau? Im Benchmark selbst kann ich das nicht umstellen. Muß ich das wieder per console als Parameter extra mitgeben?

[dildo4u]

Wenn du über die steam Bibliothek geht's zeigt er bei mir vor jedem Start die Auswahl an.

[kruemelmonster]

Nein es geht darum, dass die älteren 600er Karten nicht die DX11 Optimierung von NV bekommen haben bzw. dies zumindest nicht in AotS / es so zumindest aussieht.

600/700er Serie ist nur Marketing aber Kepler ist Kepler, natürlich profitiert die 680 genauso wie die 770 von Optimierungen.
Als ob (unabhängig des IHV) anhand des Kartennamen im Gerätemanager und nicht anhand des verbauten Chips optimiert werden würde. :rolleyes:

Richtig lesen! DX12 bringt laut AT 20%, AC kostet 3% in deren Test (1080p).

Ups, mein Fehler, hatte deinen Post mit der laufenden AC-Diskussion verbunden.

[Knuddelbearli]

Die 680 mit wenig Vram läuft gut soll ein schlechtes Zeichen für die 970 sein?Eure Post's machen immer weniger Sinn.


du kapierst es einfach nicht ...

Es ist ein Riesen unterschied ob eine Karte einfach nur weniger Speicher hat oder ob es die einzige Karte mit 3,5+0,5 ist

Sieht man doch aktuell öfters Spiele wo die 970 ihre Problemchen hat bis ein angepasster Patch kommt. 3 mal darfste rate wie lange es sowas geben wird wenn pascal kommt ...

Und das NV scheinbar älteren Karten weniger Liebe schenkt sieht man da eventuell an der 680. Dort wird dx11 nicht so gepimpt wie die aktuellen Karten weshalb sie dann auch von dx12 profitiert

[dildo4u]

Wo bekommt die 970 angepasste Treiber?Die Game Ready Treiber sind für alle Karten und müssen schon kommen damit z.b SLI Läuft.

[Knuddelbearli]

Auch wen das ein Trollversuch ist gehe ich mal trotzdem drauf ein. Das ist natürlich im normalen Gameready Treiber integriert.

Wie gesagt in letzter Zeit kam es bei einigen betas und Early Acess spielen vor das die 970 richtig abkackte, weit mehr als es der Rohleistungsunterschied zur 980 erwarten lassen würde. Glaube es war The Division bei PCGH wo sie auf das Level einer 2gb 960 zurück fiehl eben weill die 3,5+0,5 sowas exotisches sind. Kann mich aber über das Spiel auch täuschen und es war ein anderes ist jetzt nur aus Erinnerung.

[dildo4u]

Da täuschst du dich solche Beispiele wo die 970 hinter der 960 liegt gibt es nicht,die 970 lag hinter der 390 so lange die CPU nich belastet wird.Was normal ist da diese Engine in erster Linie auf GCN gut laufen muss,da die Konsolen den Großteil der Verkäufe ausmachen.

https://youtu.be/Jne8VWuE2a4

Eine 390 hat 5.1 TFlops,die 970 kommt auf 3.5 TFlops dafür läuft sie erstaunlich gut.
Der Test ist mit Ultra wo laut PCGH die 970 Probleme haben sollte ich sehe aber nix besonderes wenn man auf die Frametimes guckt.

[Kriton]

Ja klar, und dann wechseln hier im Forum doch schon wieder alle spätestens dann es wieder Titan X Leistung mit verkrüppelten Speicher Interface und sagenhaften 7,5 GB Vram aber für 330€ gibt.

Die Geschichte höre ich seit Jahren, die "ne ich wechsel nicht Leute, sind meistens die Leute die an Day1 schon wieder den bestellknopf drücken.

Die lautstarke Minderheit (auch in diesem Forum) verzerrt IMHO Deine Wahrnehmung.

[Achill]

Da täuschst du dich solche Beispiele wo die 970 hinter der 960 liegt gibt es nicht,die 970 lag hinter der 390 so lange die CPU nich belastet wird.Was normal ist da diese Engine in erster Linie auf GCN gut laufen muss,da die Konsolen den Großteil der Verkäufe ausmachen.

https://youtu.be/Jne8VWuE2a4

Eine 390 hat 5.1 TFlops,die 970 kommt auf 3.5 TFlops dafür läuft sie erstaunlich gut.
Der Test ist mit Ultra wo laut PCGH die 970 Probleme haben sollte ich sehe aber nix besonderes wenn man auf die Frametimes guckt.

Ich nehme DF nicht mehr ernst bzw. man kann begrenzt die Intel-Ram-Scaling (bedarf weiterer Quellen) als Aspekt für eine neue Plattform nehmen.

Alle Video von denen, die irgendwie eine NV mit einer AMD Karte vergleichen, sind einfach nicht zu gebrauchen. Nur sehr selten sind die Szenen synchron, es werden nicht ähnliche Kämpfe geführt, der Kamera-Winkel ist bei niedrigeren FPS-Werten schnell bei bei den NV-Karten um ein paar Grad mehr nach unten gerichtet und damit wird mehr "einfacher" Boden im Bild gerendert, oder man Spricht über FPS wenn plötzlich (u.a. wegen den genannten Punkten) die Frames deutlich höher als bei der Konkurrenz ausfallen.

In Hitman, wie die 390 fast immer über 50fps bleibt und auch mal längere Strecken bei +60fps hat, steht in der Beschreibung auf YT:
A clear AMD advantage here - just like The Division's beta - as we run at 1080p resolution with everything ramped up to the max. In truth, both GPUs struggle here. It's much the same story as we scale down settings - in truth, this game needs a lot of optimisation before launch.


Im Division-Video, was nun auch keine geschmeidige 60fps zeigt, steht im Text nur: "[...] Well, it takes settings tweaks and overclocking..." - Ja nee ist klar!

Bitte nicht als Aussage zu Karten von NV verstehen sondern nur als meine Kritik an DigitalFoundry, deren Videos und damit an der Korrektheit der dort ermittelten Werte.

---
Edit: Das fällt alles unter Kommunikationstheorie (konkret Argumentationsstrategien) und damit kann man u.a. erreichen, das etwas gut Klingt aber nicht so hängen bleibt:
- Loben (Performed gut)
- Relativieren (Eigentlich reicht die Performance nicht)
- Negieren (Sind noch Optimierungen nötig)

Was bleibt von der ersten Aussage übrig? Es performed nicht gut.

[Kriton]

Mal exemplarisch dieses Zitat:

Die entsprechenden Aussagen von nV klingen für mich ziemlich nach Bullshit. AC ist ja eigentlich kein Feature, das im Treiber an- oder ausgeschaltet wird. Mit DX12 kann eine Anwendung schlicht Queues verschiedener Typen "erzeugen" (das ist erstmal die Softwaresicht) und benutzen (direct [frißt alles], compute [nur compute + copy], copy), zusätzlich kann noch hohe oder niedrige Priorität für die jeweilige Queue angefordert werden. Das wird von der DX12-API so gefordert und jeder DX12 kompatible Treiber muß damit auch klarkommen. Auch bei nV funktioniert das natürlich. Insofern kommt auch nV mit AC klar und es ist aktiviert (der Treiber schmiert ja nicht ab, wenn es benutzt wird, oder? ;)).

Was Microsoft nicht festgelegt hat, ist, wie das dann genau abgearbeitet wird. Lediglich die entsprechenden Barrieren und explizit definierten Synchronisationspunkte müssen eingehalten werden. Die Idee ist im Prinzip, daß ein Entwickler die zu erledigenden Aufgaben über die API dem Treiber/der GPU gewissermaßen strukturierter anbieten kann, so daß mehr Parallelität einfacher nutzbar wird. Es ist aber von MS nicht gefordert, daß diese Parallelität auch immer durch die Treiber-/GPU-Kombo vollständig genutzt wird. Dies ist natürlich die Hoffnung des Entwicklers, der sich davon Performancezuwächse verspricht (z.B. für viele kleinere Compute-Jobs, die eventuell irgendwie über den Frame verteilt abgearbeitet werden müssen). Der Entwickler kann also z.B. darauf hoffen, daß mehrere seiner Queues auch wirklich parallel und gleichzeitig auf der Hardware zur Ausführung kommen. Für die korrekte (auch asynchrone) Ausführung erforderlich ist das aber nicht. Eine komplette Serialisierung ist ein erlaubtes Vorgehen.

Bei AMD klappt das Mapping dieses Konzepts auf die Hardware offenbar relativ unproblematisch. Es gibt nicht nur einen GCP sondern auch noch mehrere Compute-Queues in Hardware, die auch tatsächlich parallel arbeiten und Wavefronts an die Shader absetzen können und zudem verschiedene Prioritäten unterstützen. Dabei können im Shaderarray alle Shadertypen gleichzeitg laufen und dynamisch gemischt werden. Sogar auf einer einzelnen CU können gegebenenfalls verschiedene Grafik- und Computeshader gleichzeitig laufen. Es existiert praktisch kaum ein Penalty für einen Kontextswitch. Ob nach Beendigung einer Wavefront eines Shaders die nächste Wavefront des gleichen oder eine Wavefront eines anderen zur Ausführung kommt, interessiert eine CU nicht sonderlich. Die Granularität von Kontextswitches ist eine einzelne Wavefront (bzw. Work-/Threadgroup bei Compute). Preemption ist dafür nicht nötig (wäre es nur, wenn die komplette GPU mit einem extrem lange laufendem Shader voll wäre und da gibt es die Möglichkeit, ein paar Ressourcen für wichtige Dinge zum Zwischenschieben freizuhalten [was kaum Performance kostet]).

NVidia dagegen hat offenbar Probleme mit diesem direkten Mapping auf die Hardware. So existieren Aussagen von nV, daß die Kontextswitch-Granularität immer ein kompletter Drawcall sei. Dies ist laut nVidia selber eine Einschränkung der Hardware, die erst mit (unspezifizierten) zukünftigen Hardwaregenerationen gelöst werden soll. Das Mischen von Grafik- und Computeshadern auf dem Level einzelner SMs ist offenbar nicht möglich. Der Switch eines SMs zwischen Grafik und Compute verursacht offenbar eine deutliche Penalty. NV empfiehlt daher, Compute zu Bundeln und gerade nicht immer kleinere Computejobs parallel abzusetzen, wie das bei echt konkurrenter Ausführung wohl meist optimal wäre.
Für bestimmte Situationen erscheint es möglich, daß nV in Zukunft das HyperQ-Feature nutzt, um den momentanen Nachteil etwas auszugleichen (aber offenbar kann HyperQ nicht alles Erforderliche [gerüchteweise hängt es an den Synchronisationsmöglichkeiten], sonst hätten wir das schon längst gesehen bzw. entsprechende Hinweise an Entwickler nicht gesehen). Diese Umsetzung ist also vermutlich nicht trivial. Es gibt also eventuell irgendwann mal Treiber-Magie und entsprechende Spielprofile, mit denen die Compute-Jobs soweit wie möglich gesammelt und gebundelt werden und teilweise über die HyperQ abgesetzt werden, falls das geht. Eine allgemeine Lösung ist das aber nicht. Diese heißt dann hoffentlich Pascal (mit Pech erst Pascal v2 oder Volta).

TLDR:
Der aktuelle nV-Treiber unterstützt natürlich Asynchronuous Compute. Grafik und Compute können aber wohl aufgrund von Hardwarelimitierungen nicht wirklich konkurrent ausgeführt werden und im Zweifelsfall kann die GPU von der Kontext-Switch-Penalty ausgebremst werden. Wirkliche Abhilfe bringt erst neue Hardware, per Treiber kann das Defizit vielleicht punktuell gelindert werden.

Danke. Das habe sogar ich als Nichttechniker verstanden.

Ja... ok, Grenada XT hat ja immerhin 10% mehr Shader als Grenada Pro und die MSI 390X hat mit 1100Mhz auch einen recht hohen Takt. Keine Ahnung ob hier AC mit höheren Taktraten ebenfalls besser skaliert. Aber nur an den Shadern kannts ja nicht liegen, da müsste Fiji viel mehr zulegen. Ok, bei zwei verschiedenen Architekturen ist das wieder so ne Sache.

btw.
Die GTX960 wird in den "spielbaren" Auflösungen von Tonga XT (Tonga Pro ist nicht so viel langsamer) aber so richtig überrollt. :usweet:
54973 54974

Ist mir bisher noch gar nicht aufgefallen. Bin gespannt ob NV hier noch was richten kann.

PS: bei so einem großen Unterschied wäre mal ein Effizienzvergleich (fps/W) interessant. ;)

Da bin ich froh mir Tonga statt GM204 gekauft zu haben... Erschreckend, wenn man bedenkt, wie die ganzen Magazine Tonga XT mit der 960 verglichen haben (wobei IMHO schon damals klar war, dass das eigentlich das Feld von Tonga Pro war).

Zu dem Fazit kommt Anandtech.

Hast Du den Quote überhaupt gelesen, den Du als Beleg bringst? :rolleyes:
Sie sprechen von einer Vermutung, und die hat offenbar auch nur als einzigen Hinweis, dass das der offensichtlichste (nicht der einzige!) Unterschied zwischen den Karten ist - sie sagen ja selbst, das müsste man genauer untersuchen.

[r-or]

Die 680 mit wenig Vram läuft gut soll ein schlechtes Zeichen für die 970 sein?Eure Post's machen immer weniger Sinn.
Sicher.

Unabhängig davon, was ich am wahrscheinlichsten halte ist eben das, was auch in der Quelle (anandtech) als Vermutung geäußert ist: DX12 hat aus welchen Gründen auch immer einen leicht geringeren VRAM-Verbrauch als DX11 bei nVidia. Somit: 680 unter DX11 VRAM-Limit vs. kein Limit unter DX12.

Wieso auch sollte Kepler profitieren?

[Hübie]

Nur mal nebenbei: Heutige GPUs machen keine Preemption von laufenden Wavefronts/Warps. Das kommt erst irgendwann in Zukunft. Daß nV von Preemption an Drawcall-Grenzen spricht, zeigt nur mal wieder die typische Begriffsverwirrung in dem Feld. Daß nach einem Drawcall ein anderer abgesetzt werden kann, sollte man schon irgendwie erwarten können oder? Für die Shadereinheiten ist das keine Preemption. Nur mit gutem Willen kann man das aus einer extrem high level Sicht vielleicht für den Commandprozessor so nennen (falls es kein paralleles Issue mehrerer Queues gibt und auch kein barrel processing mehrerer Queues über einen einzelnen Issue-Port des Commandprocessors).

Und was soll das heißen, daß bei nV (im Gegensatz zu AMD) Barriers/Fences immer erst am Ende eines Batches behandelt werden? Wie soll das denn gehen? Das Verhalten ist von der API vorgegeben. Gleicher Code liefert auf GPUs beider Hersteller das gleiche Ergebnis. Da muß Nichts (und sollte auch nicht!) für jeden IHV groß anders gemacht werden.

Und was hier die latency optimized cores (LOCs) und throughput optimzed cores (TOCs) aus nVs HPC-Präsentationen damit zu tun haben, weiß ich jetzt auch nicht. :rolleyes:

Btw., daß nicht spezifiziert ist, wie AC genau ausgeführt wird (Hauptsache das Ergebnis stimmt, Serialisierung ist aus dieser Sicht okay, die Performance leidet dann aber), hatte ich ja schon geschrieben. Aber die Möglichkeit der konkurrenten Ausführung wie bei AMD ist prinzipiell besser (und es ist völlig klar, daß dies mit dem Design der API einfach ermöglicht werden soll). Geht das nicht, gehen einem gewisse potentielle Performancevorteile verloren, egal wie viel ich batche und adaptiere. Und es sind bestimmt auch Fälle denkbar, wo das Batchen schwieriger ist, man verliert also Flexibilität bei seinen Algorithmen, will man keine Performance auf der Strecke lassen. Das könnte man im Ansatz fast schon mit der Diskussion um Codeoptimierung bei in-order und out-of-order CPUs vergleichen ;).

Ich meinte TCC und WDDM. Wie ich auf TOC und LOC im Kopf komme weiß ich gerade nicht. War wohl schon zu spät. Hatte mich schon gewundert was du mit der Präsentation meintest. :freak: Entschuldige die Verwirrung. Mit TCC Treibern ist es via CUDA deutlich effektiver Compute-Tasks abzusetzen (weniger Overhead), aber dann hast kein Display scanout mehr. Es ist also nicht so dass die Hardware es nicht kann, nur kann die es eben nicht so wie über Direct3D spezifiziert. Warum, wieso, weshalb bleibt wohl ein Geheimnis.
Ich will übrigens nicht so verstanden werden dass AC Mist ist. Es gibt einfach nur mehrere Möglichkeiten ein Problem zu lösen.
Die Fences werden doch nicht von der API gesteckt sondern vom Code. :| API stellt die grundlegende Funktion zur Verfügung. Oder habe ich das falsch verstanden?

PS: Du wirkst leicht gereizt. ;)

Edit: Preemption ist ja per se einfach leeren einer Pipeline und das muss noch explizit vom Code ausgelöst werden, die Logik erkennt das nicht. Meinst du das?

[-/\-CruNcher-/\-]

Wichtiger Punkt den du hier ansprichst, Nvidia unterstützt natürlich AsycCompute im Treiber, ansonsten wäre sie nämlich gar nicht DX12 kompatibel. Das der Treiber dann im Hintergrund das ganze wohl weitgehend serialisiert, ist eine andere Geschichte. Die Aussage man habe noch gar kein AC im Treiber ist also schlicht falsch. Und es mag auch sein, dass man hier durch aufwändige Analysen in Software noch besser optimieren kann als zurzeit, aber man wird nie fehlende HW-Fähigkeiten ausgleichen können.

Richtig zum Schluss bleibt ihnen nur übrig an der Qualität des eigentlichen AC Algos den AOS verwendet herum zu doktoren, vielen würde das wahrscheinlich nicht mal auffallen wenn sie eine Stuiffe die Qualität nach unten anpassen vor allem wenn das ganze Clever in Motion passiert, und wer weiss vieleicht wäre es sogar gerechtfertigt für Nvidia user "rennt vor allen Graphics Programmern von AOS davon" ;)

[aufkrawall]

Tippe eher, die werden einfach möglichst jedem Dev sagen, für ihren Renderpfad AC nicht zu nutzen und fertig.

[-/\-CruNcher-/\-]

Das haben sie schon längst CUDA und GameWorks to the Rescue und ich frage mich ob die AC Emulation nicht ein AC->CUDA Wrapper ist so wie sie ihren OpenCL->CUDA Wrapper haben ;)

Ati/AMD hat halt einen Mega Vorteil sie kamen später in das Superscalar Geschäft und haben verdammt schnell mit GCN aufgeholt nun versuchen sie ordentlich Salz in die Wunde Nvidias zu streuen für ihre Power Efficiency Entscheidungen die man nicht von heute auf Morgen Ad Acta legen kann ;)

ihre eigene Balance haben sie Klever mit HBM verbessert im Overall Design ;)

Bin vor allem gespannt was auf den Laptops passieren wird wenn Nvidia die verliert dann sollte man ernsthaft übers wechseln nachdenken ;)

[aufkrawall]

Wenn sie mit Pascal es nicht nachholen, werden sie es diesmal schwer haben mit vergleichbar großen GPUs.
Wenn AMD GCN mit AI Maxwell-mäßig überarbeitet und durch 16nm FF+ dabei auch noch mehr Platz haben für weitere Verbesserungen (z.B. mehr ACEs?), wird das für NV nicht leicht sein, dagegen anzukommen.

[fondness]

NV hat inzwischen eine Softwareabteilung, die sich übertrieben formuliert mit der von Microsoft messen kann. Wenns sein muss schrieben sie wohl das halbe Spiel neu, ich würde mir um NV keine Sorgen machen. Viele unterschätzen glaube ich, wievielt NV wegen der Software raus holt.

[aufkrawall]

Es gibt eh in jeder wichtigen Engine Pfade für AMD & NV. Jeder halbwegs gescheite Entwickler sollte von sich aus AC für NV deaktivieren (und es für AMD natürlich im Umkehrschluss nutzen).

[-/\-CruNcher-/\-]

Das Unterschätze ich ganz und garnicht immerhin wurden die meisten Entwickler über Jahre auf Superscalar Nvidia geschult aber durch den Total Konsolenverlust sieht das alles ganz anders aus und so schwer von Superscalar zu Superscalar ist es nicht als wie noch von Superscalar zu VLIW und umgekehrt zu denken ;)

[Pirx]

Vllt ist nV auch teilweise bisher "effizienter" gewesen, WEIL ihre Architektur keine async Shader kann.

[-/\-CruNcher-/\-]

Ja es war eine bewusste entscheidung der Hardware part kostet Strom AMD/ATi hat dagegen viele Entscheidungen getroffen die eben Strom verbrauchen ohne wirklichen Nutzen bis jetzt und mit HBM kompensiert man.

Wir sind jetzt genau an diesem Punkt wo beide ineinander clashen mit Polaris und Pascal, das wird sozusagen der vorläufige Showdown ;)

Und ich sage es nochmal ohne Grund hat AMD von Hollywood nicht den Lumiere Award für LiquidVR erhalten ;)

Mann kann jetzt natürlich sagen so what den haben Blu-Ray (Sony) und 3D Kino/Fernseh auch erhalten ;)

Wenn AMD danach die Resourcen wieder aufbaut und auch noch Tegra angreift aber vorher müssen sie erstmal die Laptop hoheit von Nvidia + Intel brechen ;)

[AnarchX]

Wenn sie mit Pascal es nicht nachholen, werden sie es diesmal schwer haben mit vergleichbar großen GPUs.

Zusammen mit der Frage ob AMD auch den FP16-Durchsatz mit Polaris verdoppelt, wird das ein sehr spannender Schlagabtausch unter 16/14nm werden. Im Endeffekt kann nur der Kunde profitieren...

[-/\-CruNcher-/\-]

Jo einer von beiden wird mit dem Preis Argument kommen denke mal es wird wieder Nvidia sein wenn AMD alles auf Risiko setzt sind sie es aber diesmal vorher da sie schon gedemoed haben was schon ungewöhnlich ist immerhin waren sie die letzen im Release Zyklus und dann Demoen sie schon kurz danach wieder nun sollte Nvidia ja eigentlich als erstes Releasen *g*

Was wäre das für Reviewer hart wenn beide diesmal Zeitgleich Releasen würden sehr kurz hintereinander ;)

[Gipsel]

Ich meinte TCC und WDDM. Wie ich auf TOC und LOC im Kopf komme weiß ich gerade nicht. War wohl schon zu spät. Hatte mich schon gewundert was du mit der Präsentation meintest. :freak: Entschuldige die Verwirrung. Mit TCC Treibern ist es via CUDA deutlich effektiver Compute-Tasks abzusetzen (weniger Overhead), aber dann hast kein Display scanout mehr. Es ist also nicht so dass die Hardware es nicht kann, nur kann die es eben nicht so wie über Direct3D spezifiziert. Warum, wieso, weshalb bleibt wohl ein Geheimnis.AFAIK hast Du nicht nur kein Display mehr. Im Tesla Compute Mode wird jegliche Grafikfunktionalität deaktiviert. Die GPU verliert auch die Fähigkeit, normale Grafikshader auszuführen, nur noch Compute geht. Die Funktionen zum gemeinsamen Nutzen von Ressourcen zwischen CUDA-Compute-Kerneln und Direct3D bzw. OpenGL (D3D/OpenGL Interop) fehlen im TCC-Modus. Genau die bräuchte man aber und genau deswegen gibt es so eine Lösung wohl auch nicht. Wäre jetzt zumindest meine naive Vermutung.
Ich will übrigens nicht so verstanden werden dass AC Mist ist. Es gibt einfach nur mehrere Möglichkeiten ein Problem zu lösen.Und man muß auch keine Autos mit Rädern benutzen, Schlitten gehen auch, bei Schnee sogar ganz gut! ;)
im Die Fences werden doch nicht von der API gesteckt sondern vom Code. :| API stellt die grundlegende Funktion zur Verfügung. Oder habe ich das falsch verstanden?Es wird aber definiert, was so ein Fence tun soll und was für Auswirkungen er hat. Bei der Interpretation haben nV und AMD wenig Freiheiten. Vor dem Hintergrund macht Deine Aussage, daß bei nV (anders als bei AMD) Fences angeblich immer erst am Ende eines Batches ausgewertet würden, nicht so recht Sinn.
Edit: Preemption ist ja per se einfach leeren einer Pipeline und das muss noch explizit vom Code ausgelöst werden, die Logik erkennt das nicht. Meinst du das?Eher daß Preemption eigentlich bedeutet, daß ein laufendes Programm (eine Instanz/Wavefront/Warp eines laufenden Shaders) ohne seine eigene Mitwirkung z.B. per Interruptsignal unterbrochen werden kann, seine Daten (im Cache/Speicher) gesichert werden und die vom ihm genutzten Resourcen danach für etwas Anderes zur Verfügung stehen, bevor dann irgendwann später der Originalzustand wiederhergestellt wird und das so weiterläuft, als wäre nichts geschehen. Also so, wie heutzutage Kontextswitches auf einer CPU ablaufen.

====================================

Richtig zum Schluss bleibt ihnen nur übrig an der Qualität des eigentlichen AC Algos den AOS verwendet herum zu doktoren, vielen würde das wahrscheinlich nicht mal auffallen wenn sie eine Stuiffe die Qualität nach unten anpassen vor allem wenn das ganze Clever in Motion passiert, und wer weiss vieleicht wäre es sogar gerechtfertigt für Nvidia user "rennt vor allen Graphics Programmern von AOS davon" ;)Das wäre Cheaten, das werden sie nicht tun. Man wird sich wohl darauf beschränken, die Computegeschichten mehr oder weniger umfangreich umzusortieren bzw. zu bündeln, damit sich z.B. die Grafik/Compute-Kontextswitches über eine längere individuelle Laufzeit besser amortisieren und am Ende etwas rauskommt, was den eigenen GPUs etwas besser schmeckt. Man minimiert also den Performanceverlust.

[Nakai]

Zusammen mit der Frage ob AMD auch den FP16-Durchsatz mit Polaris verdoppelt, wird das ein sehr spannender Schlagabtausch unter 16/14nm werden. Im Endeffekt kann nur der Kunde profitieren...

Solange man kein Vec2-FP16 in Software nutzt, ist eh zu vernachlässigen.

Warum NV von AC nicht profitiert, wurde schon des öfteren erörtert. Warum AMD davon profitiert, ist auch aufgeklärt worden.

Aber wieso kann AMD bei pre-DX12 seine CUs nicht gut genug auslasten?
Und wieso macht NV das deutlich besser?

Wieviele Pixel Pipes/Primitive Pipes hat eine konkrete Implementierung von GCN? Wieviele Wavefronts eines Shadertyps können gleichzeitig vom GCP erzeugt und geschedult werden?

[aufkrawall]

Aber wieso kann AMD bei pre-DX12 seine CUs nicht gut genug auslasten?

So ganz allgemein ist das auch nicht ganz zutreffend, siehe Battlefront.
Dort skaliert auch die Fury X recht gut.

[Nakai]

So ganz allgemein ist das auch nicht ganz zutreffend, siehe Battlefront.
Dort skaliert auch die Fury X recht gut.

Ja, es gibt noch andere Beispiele.
GCN kann auch in höheren Auflösungen meistens etwas zulegen. Womöglich liegt es am größeren Backpressure, der durch mehr Pixel entsteht.

Es gibt jedenfalls starke Gründe, GCN keine gute Skalierung zu bescheinigen.

[Knuddelbearli]

Da täuschst du dich solche Beispiele wo die 970 hinter der 960 liegt gibt es nicht,die 970 lag hinter der 390 so lange die CPU nich belastet wird.Was normal ist da diese Engine in erster Linie auf GCN gut laufen muss,da die Konsolen den Großteil der Verkäufe ausmachen.

https://youtu.be/Jne8VWuE2a4

Eine 390 hat 5.1 TFlops,die 970 kommt auf 3.5 TFlops dafür läuft sie erstaunlich gut.


ich sagte ja nicht hinter sondern auf das Level, Und TF Vergleiche über komplett verschiedene Architekturen sind komplett sinnlos ...

[Bizi]

Hat eigentlich jemand eine Erklärung warum die MSI 390X mit AC so stark (+~22%) zulegt? Ich meine die legt sich dann ja schon mit einer übertakteten GTX980TI an. :freak:

http://media.bestofmicro.com/D/G/561652/gallery/AsyncCompute_On_Off_w_600.png

Grenada Pro und Fury X bewegen sich bei +11-12%. Tonga XT liegt zwar auch recht hoch mit +25%. Dieses Ergebnis lasse ich aber außen vor da die Frames schon dermaßen niedrig sind, dass es irrelevant ist. Vielleicht gibts hier auch eine Art Grundlast wie bei CPUs. Wo der Zuwachs dann überproportional steigt.

Ich vermute die MSI nutzt einfach nur ihr Powertarget sinnvoll aus. Alle anderen Karten werden mehr oder weniger stark gedrosselt und die MSI zeigt wie es ohne diese Limitierung aussehen würde.

[aufkrawall]

Deshalb braucht es ein Architektur-Update ähnlich Maxwell, damit der Stromverbrauch bei starker Auslastung nicht so explodiert.

[M4xw0lf]

Deshalb braucht es ein Architektur-Update ähnlich Maxwell, damit der Stromverbrauch bei starker Auslastung nicht so explodiert.
Engere Powerlimits erfüllen diesen Zweck. Sieht man ja bei Igors AotS-Benches. (Fury X kommt bei 4k mit DX12+AC auf 0,22 FPS/W, 980Ti auf 0.23 und 980 auf 0.25)

[aufkrawall]

Die Effizienz der Fury X ist durch Async Compute ja eben nicht gestiegen: Stromverbrauch: +16,5%, fps +12,3%.

[M4xw0lf]

Die Effizienz der Fury X ist durch Async Compute ja eben nicht gestiegen: Stromverbrauch: +16,5%, fps +12,3%.
Das sage ich auch nicht. Ich sage, dass die Effizienz konkurrenzfähig zu Maxwell ist. 5% schlechter als die 980Ti, 15% schlechter als die 980. Das ist kaum der Rede wert, wenn man bei der absoluten Performance auch noch deutlich vorne liegt. Dafür braucht GCN halt DX12, erlebt dadurch aber auf die alten Tage noch neue Höhen.

[aufkrawall]

Das sage ich auch nicht. Ich sage, dass die Effizienz konkurrenzfähig zu Maxwell ist.
Ist allerdings auch WK + HBM + Drosselung, während die von Igor getesteten Maxwells ungedrosselt liefen. Würde man das PT leicht absenken, wären auch die Maxwells noch ein Stück effizienter.
AMD braucht trotzdem eine Generalüberholung für den GPU-Aufbau ansich.

Hab ich eigentlich irgendwas nicht mitgekriegt? Warum drosselt die Fury X bei dem Spiel bei 255W, während sie bei Risen 3 330W zieht?

[M4xw0lf]

Ist allerdings auch WK + HBM + Drosselung, während die von Igor getesteten Maxwells ungedrosselt liefen.
Maxwell läuft doch nie ungedrosselt.
Hab ich eigentlich irgendwas nicht mitgekriegt? Warum drosselt die Fury X bei dem Spiel bei 255W, während sie bei Risen 3 330W zieht?
Waren die 330W auch mit dem Setup von tomshwardware gemessen, oder ist das der PCGH-Wert?

Ich wundere mich aber auch etwas, dass die Fury X nicht ihre TDP von 275W(?) ausschöpft in AotS mit AC.

[aufkrawall]

Maxwell läuft doch nie ungedrosselt.

Internet-Mythen über Maxwell, es wird garantiert nie langweilig... :cool:
Der drosselt natürlich auch nicht, wenn seine PT-Grenze nicht erreicht wird, was bei dem Custom Designs, die Igor getestet hat, bei den angegebenen Verbrauchswerten nicht der Fall ist.


Waren die 330W auch mit dem Setup von tomshwardware gemessen, oder ist das der PCGH-Wert?

PCGH. Bei Torture hat die Fury X aber auch bei TH >300W verbraucht.

[M4xw0lf]

Internet-Mythen über Maxwell, es wird garantiert nie langweilig... :cool:
Der drosselt natürlich auch nicht, wenn seine PT-Grenze nicht erreicht wird, was bei dem Custom Designs, die Igor getestet hat, bei den angegebenen Verbrauchswerten nicht der Fall ist.

Aha, aber Fiji lief gedrosselt, obwohl er sein PT ebenfalls nicht erreicht laut Messwert? Full of sense.

[dargo]

Die Effizienz der Fury X ist durch Async Compute ja eben nicht gestiegen: Stromverbrauch: +16,5%, fps +12,3%.
Hmm... ich sehe da eher in 4k 21% mehr Stromverbrauch vs. 17% mehr Leistung (DX12 AC vs. DX11). Ist aber nicht weiter tragisch, da mit DX12 die Effizienz bei der CPU steigt wodurch das gesamte Paket aus CPU + Fury X effizienter ist.

[aufkrawall]

Aha, aber Fiji lief gedrosselt, obwohl er sein PT ebenfalls nicht erreicht laut Messwert? Full of sense.
Das sagt ja Igor, der den Test durchgeführt hat.

[(del)]

Der Arbitrator bei Fiji reagiert ja nicht nur auf die Sensoren (Temperaturen, aktueller Stromfluss, Lüfterdrehzahlen usw.) sondern auch auf die Power Estimation Engine, die die kommende Lasten intelligend "vorausahnen" kann, sowie im Vergleich auch auf das, was in der Firmware an Grenzwerten für alle relevanten Bereiche jeweils hinterlegt ist. Man kann die Fury X sicherlich auch auf über 300 Watt prügeln, was mit einigen der Powerviren gut möglich ist, weil vor allem die Power Estimation Engine bei OpenGL grandios zu versagen scheint. Allerdings ist mir dies bei Spielen, solange man in Bewegung bleibt und nicht an einem besondern tollen Punkt einfach verharrt, in diesem Maße nie passiert. Ich vermute mal stark, dass in solchen Extremfällen einfach Power Tune versagt und das Power Limit (nicht Power Target, das gibts nur bei NV!) nicht so greift, wie angedacht.

[aufkrawall]

Interessant. Ist ja blöd, wenn man sich nicht auf die Einstellung verlassen kann. afair hatte ich so etwas nie mit Hawaii.
Kann aber auch ein Treiber-Bug sein, bei Crimson ist ja immer noch etwas kaputt, was die Taktanpassung oder was auch immer angeht.

[(del)]

Crimson ist eine Krankheit. Patchwork-Treiber aus alt, neu und fehlt. :P

[HOT]

Man gewinnt immer mehr den Eindruck, dass Crimson vor allem ein Lückenbüsser ist - neue Software, Treibergrundlage eigentlich 15.15 (also im Prinzip Omega+) mit Flickenteppich und Workarounds (die immer mehr CPU-Ressoucen fressen, die Auslastungbenchmarks werden mit jedem Hotfix schlechter) und nem exklusivem DX12-Treiber dran. Bleibt nur zu hoffen, dass die einen komplett neuen DX11-Treiber im Hintergrund aufziehen und deshalb keine Ressourcen in den alten stecken. Die Software war halt schon vorher fertig.
Die kommen ja auch nicht drumherum einen DX11.3-Treiber zu Verfügung zu stellen, denn nicht jedes Studio will sich mit den neuen APIs beschäftigen, was ich auch gut verstehen kann. Bei vielen Spielen ist es ja aufgrund nicht-fordernder Grafik oder auch begrenztem KnowHow und/oder Budget auch gar nicht nötig/möglich. Und man kann es sich einfach nicht leisten, dass Polaris bei DX11-Benchmarks weiterhin so abstinkt. Das wird aber nur durch ein grundsätzliches Neuschreiben weiter Bereiche möglich sein und deshalb viel Zeit kosten - oder sie machen einfach gar nix und kassieren auch mit Polaris schlechte Presse...

Ach so, kleine Frage: Liegts eigentlich am zu restrikivem Powermanagement, dass Tonga gegen Tahiti so abstinkt und auch so unverhältnismäßig wenig gewinnt ggü. Tonga Pro oder ist es doch das kastrierte Speicherinterface? Mir kommt das langsam so vor, dass Tonga signifikant mehr Saft braucht als Tahiti und das trotz fehlenden 128Bit. Das Ding muss ja ne noch katastrophalere Bilanz aufweisen als Hawaii, wenn man den entfesselt...

[Hübie]

AFAIK hast Du nicht nur kein Display mehr. Im Tesla Compute Mode wird jegliche Grafikfunktionalität deaktiviert. Die GPU verliert auch die Fähigkeit, normale Grafikshader auszuführen, nur noch Compute geht. Die Funktionen zum gemeinsamen Nutzen von Ressourcen zwischen CUDA-Compute-Kerneln und Direct3D bzw. OpenGL (D3D/OpenGL Interop) fehlen im TCC-Modus. Genau die bräuchte man aber und genau deswegen gibt es so eine Lösung wohl auch nicht. Wäre jetzt zumindest meine naive Vermutung.

Hm, ja ich habe da noch mal nachgelesen und es ist wohl reines compute. Über remote renderten wir damit zwar, aber die Ausgabe / Komposition kommt dann wohl von der Quadro.

Und man muß auch keine Autos mit Rädern benutzen, Schlitten gehen auch, bei Schnee sogar ganz gut! ;)

Man muss das nicht gleich ins Lächerliche ziehen. Ich vermute dass nVidia einfach den Code neu ordnet und größere Batches überträgt, da feingranulare Daten mit graphics- und compute-shader ja offenbar die Pest für Kepler+ sind. Werden diese eigentlich in die command lists gelegt und dann aufgerufen oder wie läuft das danach weiter?
Bei AotS laufen durch simulierte balistische Geschoße und Einschläge massiv parallelisierte Prozesse ab. Perfektes Szenario. Aber ob es jetzt in Crysis 3 bei der Flora etwas gebracht hätte würde mich dann auch mal interessieren (afaik waren die Bäume etc. nicht tesseliert, sondern wirkten per compute-shader organischer).

Es wird aber definiert, was so ein Fence tun soll und was für Auswirkungen er hat. Bei der Interpretation haben nV und AMD wenig Freiheiten. Vor dem Hintergrund macht Deine Aussage, daß bei nV (anders als bei AMD) Fences angeblich immer erst am Ende eines Batches ausgewertet würden, nicht so recht Sinn.

Es mag sein dass ich etwas falsch verstanden habe. Ich lese da gerne noch mal drüber. Hatte das nur aus dem Hinterkopf.

Eher daß Preemption eigentlich bedeutet, daß ein laufendes Programm (eine Instanz/Wavefront/Warp eines laufenden Shaders) ohne seine eigene Mitwirkung z.B. per Interruptsignal unterbrochen werden kann, seine Daten (im Cache/Speicher) gesichert werden und die vom ihm genutzten Resourcen danach für etwas Anderes zur Verfügung stehen, bevor dann irgendwann später der Originalzustand wiederhergestellt wird und das so weiterläuft, als wäre nichts geschehen. Also so, wie heutzutage Kontextswitches auf einer CPU ablaufen.

Ich denke das ist ein etwas zu komplexes Thema wenn es um die Implementierung in Hardware geht. Ähnlich der branch-prediction über die man seit Jahren philosophiert, kann man auch hier wohl einen Doktortitel machen, wenn man den Bogen raus hat. Übersteigt jedenfalls meine Kompetenzen und mein Wissen. Preemption in jeder stage der pipe wäre jedenfalls ein Wahnsinns-Unterfangen.

[dildo4u]

PCPER hat den Artikel jetzt fertigt,es gibt wohl allgemeine Probleme mit der Erstellung/Aufzeichnung von unabhängigen Benchmark's von DX12 Games,Ashes verhält sich wie eine Windows Store App.
Z.b kann man keine Frametimes mit FCAT messen.


Benchmarking is likely going to see a dramatic shift with move to these app-style games on Windows 10, as the sandboxed nature will keep anything from “hooking” into executable as we have seen in the past. This means that overlays, like Fraps, EVGA Precision X, MSI Afterburner and even the FCAT overlay we would like to use for our capture-based Frame Rating testing, are kind of at a standstill. Measuring the performance of each game will necessitate the game developer writing an in-game benchmark mode that exports the kind of information that we want to see measured, and that we trust them to do it correctly, and that it will properly represent the experience the user sees. To its credit, the team at Oxide have done an excellent job of this with the Ashes benchmark, though I still have concerns over how the in-game data output matches up with the experience of watching the benchmark play thanks to those uncapped frame rates and dropped frames we detailed.

Probleme mit Vsync off unter DX12

Back on topic to our specific testing scenario, the AMD platform is more closely emulating what Microsoft would like to see done as DX12 gaming progresses. They never want applications to enter into anything that resembles a “Vsync off” state, which front buffer flips that lead to horizontal tearing. Instead, the “Vsync” option in the Ashes settings switches the game engine between two states:

Vsync on: Render rate is capped at the refresh rate of the monitor (60Hz is where we’ll discuss this at today) and thus the maximum benchmarked result is 60 FPS.

Vsync off: Render rate is uncapped, able to go as high as the hardware will allow. The draw rate to the monitor however is capped at the maximum refresh rate of the monitor. Only the most recent frame rendered is shown at the Vsync interval – all other frames dropped from the pipeline.
In fact, this is exactly what Frame Rating and FCAT told us was happening, we just didn’t know why at the time.

Nvidia bietet weiterhin Vsync off


Another viewpoint suggests a different direction.This person suggests that AMD’s driver is behaving as Microsoft has laid out DX12 to work in general, not just for universal apps, and that NVIDIA is implementing a workaround of sorts, to get Vsync off status to function as it has in the past, claiming exclusive fullscreen status in DX12.



http://www.pcper.com/reviews/General-Tech/PC-Gaming-Shakeup-Ashes-Singularity-DX12-and-Microsoft-Store

[N0Thing]

Nvidia bietet weiterhin Vsync off

Another viewpoint suggests a different direction.This person suggests that AMD’s driver is behaving as Microsoft has laid out DX12 to work in general, not just for universal apps, and that NVIDIA is implementing a workaround of sorts, to get Vsync off status to function as it has in the past, claiming exclusive fullscreen status in DX12.



http://www.pcper.com/reviews/General-Tech/PC-Gaming-Shakeup-Ashes-Singularity-DX12-and-Microsoft-Store

Das Thema ist definitiv interessant und sollte auch von der Fachpresse im Auge behalten werden. Zudem stellt sich mir die Frage, ob dies auf DX12 beschränkt ist, oder auch bei Vulkan ein Thema ist.

[(del)]

Ich habe das mit dem nichtexklusiven Fenster von AotS in meinem Artikel ebenso kritisiert,
allerdings gibt es aus meiner Sicht keine Restriktionen seitens Microsofts, um DX12-Apps nicht als echtes Vollbild laufen zu lassen.
Ich empfinde den Artikel eher als Clickbaiting. FCAT ist ja gut und schön, aber solche proprietären Geschichten,
vor allem wenn sie von einem der beiden Hersteller kommen, haben immer ein gewisses G'schmäckle :D

[Hübie]

Hm. Also im MSDN steht es zwar nicht explizit, aber wenn man es dem Treiber überlassen möchte soll man wohl DXGI_SWAP_EFFECT_DISCARD für die Bufferswap-Funktion nutzen.
Das präsentieren von Bildraten sollte dann möglich sein, wenn der IHV einen counter zur Verfügung stellt (gilt jetzt nur für D3D12). Damit könnte man wahrscheinlich auch wieder eine Färbung benutzen um Frames zu differenzieren.
Als Laie kann ich mir das jedoch nur zurecht lesen...

[M4xw0lf]

Der Anfang von dem Artikel schon ;D

Earlier this week, the team behind Ashes of the Singularity released an updated version of its early access game, which updated its features and capabilities. With support for DirectX 11 and DirectX 12, and adding in multiple graphics card support, the game featured a benchmark mode that got quite a lot of attention. We saw stories based on that software posted by Anandtech, Guru3D and ExtremeTech, all of which had varying views on the advantages of one GPU or another.

That isn’t the focus of my editorial here today, though.

Und am Schluss:
This is clearly a discussion that is just at its beginning. My gut tells me that Ashes of the Singularity is just the tip of the iceberg, even if the AMD exclusive fullscreen issue gets ironed out with another driver update or game patch.
Da erklärt er vorher ausführlich, dass AMDs output wohl genau das ist, was MS von Spiele- und Hardwareentwicklern verlangt, aber im Fazit schreibt er von einem AMD-Problem, hmja.

[Digidi]

@Format_C

Habt Ihr eigentlich mal bei den Tests auf das CPU Bound und GPU Bound geachtet?

Ich bin mit meiner 290x CPU Bound in Full HD und Crazy Settings. Um zu sehen was die GPU eigentlich packt müsste ich meinen 4 Ender gegen einen 6 Ender tauschen. Das müsste man nochmals testen wie es da zwischen Nvidia und AMD aussieht. Vielleicht braucht Nvidia nur eine starke CPU um die Leistung abzurufen. Vielleicht reicht da auch kein 6 Ender :D

[Schaffe89]

Ich blick da jetzt nicht ganz durch, aber prinzipiell wäre es ja eher begrüßenswert wenn eine proprietäre Messmethode ala FCAT nicht mehr funktioniert, sondern eine neutrale zusammen mit MIcrosoft entwickelte, dann den Dienst verrichtet.

Letztendlich hört sich der Artikel aber nach click-baiting an.

Edit:

Keinen 12ender am Start oder was?:D

[Zettabit]

Microsoft möchte mit DX12 VSync-off defakto abschaffen und nur noch 60 fps anzeigen?

:facepalm:

[dargo]

Microsoft möchte mit DX12 VSync-off defakto abschaffen und nur noch 60 fps anzeigen?

:facepalm:
Es gibt aktuell bis zu 165Hz Geräte. Mit DP1.3 geht da auch viel mehr. ;)

[iuno]

Aber nicht jeder hat das und schon gar nicht hat jeder ein Display mit vrr.
imho sollte man schon noch die Wahl haben, dass Vsync immer an war wurde bei den ersten Steam Machines auch zu recht bemaengelt

[M4xw0lf]

Ist eigentlich dieser Artikel weit und breit bekannt? http://ext3h.makegames.de/DX12_Compute.html
Schon von Anfang 2015 oder so, aber sehr sehr informativ, und darüber hinaus fliegen Stücke davon schon lange im Netz herum (Die Tabelle mit dem Feature-Support Vergleich!).

[dargo]

imho sollte man schon noch die Wahl haben, dass Vsync immer an war wurde bei den ersten Steam Machines auch zu recht bemaengelt
Da bin ich bei dir. Schon alleine wegen Freesync würde ich kein Game kaufen ohne exklusiven Vollbild.

[Blediator16]

Entweder wird das noch gebracht oder es gibt einen riesen shitstorm.

[HOT]

Offenbar arbeitet M$ grad ziemlich an den Sync-Problematiken. Auch bei Multi-GPU-Getöse soll es bald eine Lösung geben. Die 60Hz momentan sind ein Workaround, mehr nicht. Scheint als wollen die die Kontrolle darüber standardmäßig dem OS hinzufügen und den Wildwuchs beenden. Anscheinend will man den Exclusive-Mode auch ingesamt loswerden. Ob das für OpenGL/Vulkan dann auch gilt, ist da schon wieder ne andere Frage.

[(del)]

@Format_C
Vielleicht braucht Nvidia nur eine starke CPU um die Leistung abzurufen. Vielleicht reicht da auch kein 6 Ender :D

Mehr als sechs echte Kerne (nicht Threads) bringen kaum was. Ein i7 5960X @4.8 GHz limitiert eine 980 Ti natürlich nicht im mindesten, nur in MPGU-Settings. Trotzdem werden die Resultate nicht besser (logisch, wie sollten sie auch?) Ein i7 5930K @4,2 GHz ohne SMT ist aber fast genau so schnell, d.h. 12 oder gar 16 Threads bringen nullkommanichts, denn der gleiche i7 5930K ist mit SMT sogar noch einen Tick langsamer. Außerdem habe ich zum GPU-Bound im Artikel Stellung bezogen und sogar Charts zur GPU Time mit drin.

[Michalito]

...
Wieder betriebsfähig ? Oder noch Idle Time?

[-/\-CruNcher-/\-]

PCPER hat den Artikel jetzt fertigt,es gibt wohl allgemeine Probleme mit der Erstellung/Aufzeichnung von unabhängigen Benchmark's von DX12 Games,Ashes verhält sich wie eine Windows Store App.
Z.b kann man keine Frametimes mit FCAT messen.




Probleme mit Vsync off unter DX12



Nvidia bietet weiterhin Vsync off




http://www.pcper.com/reviews/General-Tech/PC-Gaming-Shakeup-Ashes-Singularity-DX12-and-Microsoft-Store

Wir sehen hier nur wie weiter Trusted Computing umgesetzt wird mit Windows 10 ;)

Eben der nächste Schritt ist die Totale Abschottung der Applikation von 3rd Partiy Applikationen auf dem Client die keine Berechtigung haben auf allen Levels der Render und Presentation Pipeline vorher hat Microsoft versucht die Memory ebene zu sichern (Patchguard).

Die Anfänge dieser Sandboxed Application Rechteverwaltung wurde mit den Smartphones eingeführt.

Es wird uns in eine sichere Computing Era unter Windows begleiten ;) *sarcasm*

[Achill]

Mehr als sechs echte Kerne (nicht Threads) bringen kaum was. Ein i7 5960X @4.8 GHz limitiert eine 980 Ti natürlich nicht im mindesten, nur in MPGU-Settings. Trotzdem werden die Resultate nicht besser (logisch, wie sollten sie auch?) Ein i7 5930K @4,2 GHz ohne SMT ist aber fast genau so schnell, d.h. 12 oder gar 16 Threads bringen nullkommanichts, denn der gleiche i7 5930K ist mit SMT sogar noch einen Tick langsamer. Außerdem habe ich zum GPU-Bound im Artikel Stellung bezogen und sogar Charts zur GPU Time mit drin.

Mir war so, dass z.B. im 3dMark zu DX12 und Mantle zu sehen war, dass bei mehr als 6 Kernen keine weitere Skalierung bei AMD und NV Karten eintritt. Bei Mantle war dies nicht der Fall - ggf. gibt es da noch eine Bremse:

http://www.gamespot.com/forums/pc-mac-linux-society-1000004/3dmark-api-overhead-feature-test-early-dx12-perfor-31936719/ - der erst beste Test mit mehr als 8 Kernen den Google ausgespuckt hat. Man sieht, dass DX12 und Mantle mehr oder weniger gleich skalieren (290x) und auch fast den gleichen Durchsatz an DrawCalls schaffen. Bei 8 Kernen stagniert DX12 auf den Wert von 6 Kernen, bei Mantle geht es weiter. Evtl. ist es ein AMD Ding oder etwas bzgl. DX12 limitiert (weiß aber auch nicht, ob das noch aktuell so ist).


Wir sehen hier nur wie weiter Trusted Computing umgesetzt wird mit Windows 10 ;)

Eben der nächste Schritt ist die Totale Abschottung der Applikation von 3rd Partiy Applikationen auf dem Client die keine Berechtigung haben auf allen Levels der Render und Presentation Pipeline vorher hat Microsoft versucht die Memory ebene zu sichern (Patchguard).

Die Anfänge dieser Sandboxed Application Rechteverwaltung wurde mit den Smartphones eingeführt.

Es wird uns in eine sichere Computing Era unter Windows begleiten ;) *sarcasm*

Das sehe ich ähnlich, das richtet sich wahrscheinlich gegen das WebRipping wo m.W. mit Tools ähnlich AF und Co. ein Video inkl. Sound im Browser mitgeschnitten wird...
Wenn man das alles nicht will, dann hilft nur:
1. Vertriebsmodell nicht unterstützen
2. Offenes OS mit offenen Treibern

[-/\-CruNcher-/\-]

Eh die Wirtschaft zu schützen liegt in unser aller interesse ich halte es für Richtig Rechte zu entziehen es gibt zu viele Schwarze Scharfe in der ITC, da muss gehandelt werden und diese vor allem Organisierte Computerkriminalität abgeschottet werden zum wohle des Users.

Das sich Content Provider freuen ist doch nur ein Nebeneffekt für die Gute Sache endlich Recht und Ordnung in den Windows PC Client zu bekommen mit Windows 10 sind wir einen Schritt näher dieses Ziel zu erreichen und aus der Gesellschaft eine bessere zu machen und wir nehmen dann Windows 10 als Vorbild für unser eigenes Gesellschaftliches OS und Sandboxen jeden noch mehr ein :)

Merken tut es doch eh keiner sie gewöhnen sich ja durch ihre Appliances schon alle daran, und wenn sie es tun so what bis dahin ist das Wissen vernichtet bzw ordentlich Sandboxed ;)

[Isen]

Ist eigentlich dieser Artikel weit und breit bekannt?

Jo, fondness hat die Grafik und Seite hierher verlinkt gehabt (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10955287&postcount=1532).

[Nakai]

Ist eigentlich dieser Artikel weit und breit bekannt? http://ext3h.makegames.de/DX12_Compute.html
Schon von Anfang 2015 oder so, aber sehr sehr informativ, und darüber hinaus fliegen Stücke davon schon lange im Netz herum (Die Tabelle mit dem Feature-Support Vergleich!).

Nein, der Artikel ist relativ neu. 24.02.2015 sollte eher 2016 sein.

[Gipsel]

Probleme mit Vsync off unter DX12
Back on topic to our specific testing scenario, the AMD platform is more closely emulating what Microsoft would like to see done as DX12 gaming progresses. They never want applications to enter into anything that resembles a “Vsync off” state, which front buffer flips that lead to horizontal tearing. Instead, the “Vsync” option in the Ashes settings switches the game engine between two states:

Vsync on: Render rate is capped at the refresh rate of the monitor (60Hz is where we’ll discuss this at today) and thus the maximum benchmarked result is 60 FPS.

Vsync off: Render rate is uncapped, able to go as high as the hardware will allow. The draw rate to the monitor however is capped at the maximum refresh rate of the monitor. Only the most recent frame rendered is shown at the Vsync interval – all other frames dropped from the pipeline.
In fact, this is exactly what Frame Rating and FCAT told us was happening, we just didn’t know why at the time.Also ist es nicht VSync on/off sondern eigentlich ein Switch zwischen double und triple Buffering (mit verworfenen Frames, also das "klassische", was auch den Input-Lag nicht ueber Gebuehr erhoeht). :rolleyes:

[-/\-CruNcher-/\-]

Nein, der Artikel ist relativ neu. 24.02.2015 sollte eher 2016 sein.

Frag mich woher seine Daten Stammen die er nicht veröffentlichen kann aus seiner Continental Web Anwendungszeit sicher nicht ;)

I also had access to non-synthetic results which I can't disclose.

Zum 1. Oktober 2000 wurde an der Ostbayerischen Technischen Hochschule Regensburg das Institut für Angewandte Forschung und Wirtschaftskooperationen (IAFW) gegründet. Als zentrale Einrichtung stellt das IAFW die fachbereichsübergreifende Dachorganisation für alle Forschungsaktivitäten der Hochschule Regensburg dar. Ziel hinter dieser hochschulweiten Einrichtung ist es, die Brücke zwischen der anwendungsbezogenen Wissenschaft und der industriellen Praxis zu schlagen und im Rahmen von Veranstaltungen zum Wissens- und Technologietransfer die Zusammenarbeit mit der Wirtschaft zu ermöglichen. Dabei erhalten die Unternehmen nicht nur direkten Zugriff auf neueste Erkenntnisse und Ergebnisse, sondern sie haben durch den gezielten Wissensaustausch mit Spezialisten der Hochschule auch die Möglichkeit, Antworten auf konkrete Problemstellungen zu erhalten. Die Zusammenarbeit mit dem IAFW bietet dabei nicht nur Großunternehmen, sondern verstärkt auch kleinen und mittleren Unternehmen, die häufig über keine oder nur geringe Kapazitäten im Bereich Forschung und Entwicklung verfügen, die Chance, ihre Innovationsfähigkeit deutlich zu steigern.


Bachelor über Robotik hmm

Aktuell bin ich dabei im Rahmen meiner Bachelorarbeit den Robonova mit einem neuen Prozessor aus zu statten, für diesen eine neue Firmware zu entwickeln sowie einen Simulator incl. Physik zu schreiben welcher es erlaubt Software für den Robonova am PC zu testen.

Compute Physics Simulation wäre wohl eine Möglichkeit.

https://docs.google.com/file/d/0BzdVJtRk0nZpekVUdGdMa2pvenM

[Lowkey]

Mit dem neuen Nvidia Treiber samt AotS Support wurden die Benchmarkergebnisse letztlich in Zement gegossen. Sind aktuelle Nvidia Karten quasi über Nacht für DX12 wertlos geworden?


Neuer Patch:

Vsync now defaults to off - in DX12 it can lead to some camera jitter on certain GPUs

[Godmode]

Ist eigentlich dieser Artikel weit und breit bekannt? http://ext3h.makegames.de/DX12_Compute.html
Schon von Anfang 2015 oder so, aber sehr sehr informativ, und darüber hinaus fliegen Stücke davon schon lange im Netz herum (Die Tabelle mit dem Feature-Support Vergleich!).

Ich kannte ihn nicht, danke für die Link! Sehr aufschlussreich.

Mit dem neuen Nvidia Treiber samt AotS Support wurden die Benchmarkergebnisse letztlich in Zement gegossen. Sind aktuelle Nvidia Karten quasi über Nacht für DX12 wertlos geworden?


Die NV-Karten können trotz des Fehlens von Async-Compute ja immer noch gut mit dem AMD-Karten mithalten, daher würde ich nicht von wertlos sprechen. Für die Entwickler ist das aber wieder eine richtig miese Sache. Vor allem das man Compute-Queues die 3D-Queues blockieren und umgekehrt, ist schon ein starkes Stück.

[iuno]

Klar, wertlos :ugly:
Es ist ja nun nicht so, dass GM200 ploetzlich auf Iceland Niveau liegt.
Davon ab positioniert sich Nvidia schon neu. AMD fehlt aktuell z.B. die HW Unterstuetzung fuer CR, was ebenso Teil von DX12 ist wie AC. CR wird offenbar schon fuer die neuen Gameworks Schatten in The Division (DX11) genutzt. Eine Softwareimplementierung gibt es scheinbar nicht, also kann AMD diese Schatten einfach nicht darstellen. Wenn Nvidia den GW Kram so unter die Entwickler bringt, viel Spass...

[dildo4u]

Mit dem neuen Nvidia Treiber samt AotS Support wurden die Benchmarkergebnisse letztlich in Zement gegossen. Sind aktuelle Nvidia Karten quasi über Nacht für DX12 wertlos geworden?


Neuer Patch:

Vsync now defaults to off - in DX12 it can lead to some camera jitter on certain GPUs
Hitman kommt am Freitag dann hat man das erste große Finale DX12 mit Asynchron Compute für Ashes hat Nvdia noch bis Ende März.NV bringt öfter extra Treiber für die Beta und dann noch mal für die Retail z.b für Division.

[dargo]

Klar, wertlos :ugly:
Es ist ja nun nicht so, dass GM200 ploetzlich auf Iceland Niveau liegt.
Davon ab positioniert sich Nvidia schon neu. AMD fehlt aktuell z.B. die HW Unterstuetzung fuer CR, was ebenso Teil von DX12 ist wie AC. CR wird offenbar schon fuer die neuen Gameworks Schatten in The Division (DX11) genutzt. Eine Softwareimplementierung gibt es scheinbar nicht, also kann AMD diese Schatten einfach nicht darstellen. Wenn Nvidia den GW Kram so unter die Entwickler bringt, viel Spass...
Der Quatsch ist eh viel zu ineffizient. Wenn das unter DX12 deutlich effizienter ist können wir gerne nochmal drüber reden.

[dildo4u]

Die Schatten sind für die 980 Ti schnell genug 55fps ohne OC.

http://images.nvidia.com/geforce-com/international/images/tom-clancys-the-division/tom-clancys-the-division-shadow-quality-performance.png

Also schafft die Masse der verkauften Custom 980 TI 60fps.

[dargo]

Achso... Verzeihung. Hab vergessen, dass ne 980TI mittlerweile auf 1080p abgestuft wurde. 23% Einbruch für nur bessere Schatten von High auf HFTS bei bloß 1080p. :ucrazy:

PS: hier war dildo noch der Meinung ne 980TI wäre für 1440p. :D
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10966219&postcount=5678

Ok... ist "nur" High. ;)

[LDNV]

:freak: da ist was dran ^^ :freak:

Wobei die Schatten jetzt nicht wirklich das Argument sind... wovon man in Bewegung kaum was sieht, aber unverhältnismäßig viel Performance zieht...

Bestätigt aber wieder meine These es keine Grafikkarten gibt die überdimensioniert für irgendeine Auflösung sind. Man kriegt jede in jeder Auflösung platt ;)

Und wenn eine Karte auf Maxed Out in FHD oder QHD gerade so 60 FPS stemmt, und im umkehrschluss UHD nur mit reduzierten Details, ist sie sicher nicht für FHD oder der gleichen überdimensioniert.

Von 120 FPS fangen wir lieber erst gar nicht an ;)

[iuno]

Der Quatsch ist eh viel zu ineffizient. Wenn das unter DX12 deutlich effizienter ist können wir gerne nochmal drüber reden.
Das bleibt halt abzuwarten. Erstmal sehen die Schatten gut aus und setzen angeblich CR voraus. Wenn Leistung da ist, kann man sie also verwenden.
Dass das das Ende ist und sich nicht noch (stark) optimieren laesst, ist ja ueberhaupt nicht gegeben. Vielleicht laeuft das ganze unter Pascal auch ploetzlich viel besser oder halt auch nicht. Wie gesagt da muss man halt abwarten, so ist das halt bei GameWorks...

Und ob es insgesamt viel Leistung kostet war bei GW auch nie so wichtig. Wenn dann nebenher noch eine Softwareimplementierung fuer die Konkurrenz nachkommt, die nochmal 3x langsamer ist und NV den Kram bezahlt, wird es gemacht.

[Knuddelbearli]

Klar, wertlos :ugly:
Es ist ja nun nicht so, dass GM200 ploetzlich auf Iceland Niveau liegt.
Davon ab positioniert sich Nvidia schon neu. AMD fehlt aktuell z.B. die HW Unterstuetzung fuer CR, was ebenso Teil von DX12 ist wie AC. CR wird offenbar schon fuer die neuen Gameworks Schatten in The Division (DX11) genutzt. Eine Softwareimplementierung gibt es scheinbar nicht, also kann AMD diese Schatten einfach nicht darstellen. Wenn Nvidia den GW Kram so unter die Entwickler bringt, viel Spass...

CR ist doch 12.1 oder? bzw optional in 12.0

Und naja das eine bringt ordentlich fps das andere kostet fps da ist die Wahl einfach was ich bevorzuge

[Locuza]

Nvidia bietet CR über ihre eigene NVAPI für DX11 an.

[iuno]

Und naja das eine bringt ordentlich fps das andere kostet fps da ist die Wahl einfach was ich bevorzuge
CR an sich kostet selbstverstaendlich keine FPS, im Gegenteil. Bestimmte Probleme lassen sich dadurch deutlich effizienter loesen. NV hat halt gleich den Riesenhammer ausgepackt und die Vorteile 'versteckt' indem man diese Technologie fuer die Schatten implementiert hat der an sich viel rechenintensiver ist als die anderen. Deswegen muss man CR nicht schlechtreden.
Natuerlich ist klar, dass es seinen sinnvollen Einsatz erst noch beweisen muss, das gilt aber fuer AC genauso.

Dein Vergleich ist unfair. Um das nochmal zu verdeutlichen: man muesste bei AotS alles was im Zusammenhang mit AC steht, deaktivieren, also alle Effekte auf die aktiviertes AC einen Einfluss hat. Und das Ergebnis dann gegen AC+alle Effekte an stellen.

[fondness]

Game gibt es mit Tonga gratis:
http://amd4u.eu/files/AshesOfTheSingularity_Terms&Conditions.pdf

[Schaffe89]

Das riecht nach einem Abverkauf der aktuellen GPU´s.

[Schnoesel]

Falscher Fred

[Achill]

Nachdem ich jetzt mein Multi-GPU-Problem mit AotS gelöst habe (es war die Pagefile-Größe, AotS möcht gern ~20GB Pagefile haben - WTH!), es somit nicht am Speicher und Timings lag, gibt es noch kurz eine Info wie sehr Timings bei AotS durchschlagen:

5820k@4.4GHz und 16GB DDR4-2400 / High Preset & 1080p
15-15-15-35: ~94fps
18-17-17-39: ~89fps

[Tamagothi]

Sehe ich das Falsch oder bist überall im CPU Limit?

[Achill]

Sehe ich das Falsch oder bist überall im CPU Limit?

Ja volles CPU-Limit. Der i7 5820k schafft nicht mehr, wird Zeit das Zen kommt ... :wink:

[dargo]

Sehe ich das Falsch oder bist überall im CPU Limit?
Er hat auch Grenada XT CF.

[Tamagothi]

Das er CF hat sehe ich auch :wink:

Trotzdem hätte ich nicht gedacht das ein 6 Kerner so dermaßen überfordert ist :(

Wird langsam zeit für DX13 :biggrin:

[dildo4u]

Es ist ein RTS und kein Shooter 90fps sind da schon recht üppig,das Gimick vom Game ist ja,das erst die Low Level API's flüssig zocken ermöglicht,es erzeugt also bewusst massive CPU Last durch viele Einheiten.
DX12 Konsolen Ports werden wohl immer ins GPU Limit rennen mit der Config.

[Achill]

Ist natürlich Richtig, da ich eh generell mit VSync:on spiele und nur noch auf einen passenden FreeSync Monitor warte brauche ich die ~90fps nicht in AotS nicht wirklich.

Mir ging es eher um den Fakt, dass die Timings solche Auswirkungen haben. Ich werde am Sa./So. mal schauen wie AotS auf weitere Timings und andere Bandbreite reagiert (wenn ich Quad.Channel im Bios aus bekomme, will nicht schrauben) bzw. ich weit genug mit dem Takt runter komme. Ist in die Richtung "Was bringt besserer RAM bei AMD/Intel" zu verstehen.

[aufkrawall]

Die fps sind irgendwie seltsam, mein 2500k@4,6Ghz schafft 74 fps:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10956839&postcount=25
Es scheint wohl einfach nicht mit so vielen Threads gut zu skalieren?

[Hübie]

Nachdem ich jetzt mein Multi-GPU-Problem mit AotS gelöst habe (es war die Pagefile-Größe, AotS möcht gern ~20GB Pagefile haben - WTH!), es somit nicht am Speicher und Timings lag, gibt es noch kurz eine Info wie sehr Timings bei AotS durchschlagen:

5820k@4.4GHz und 16GB DDR4-2400 / High Preset & 1080p
15-15-15-35: ~94fps
18-17-17-39: ~89fps

Mach mal Glare und Shadow höher. ;) Glare läuft massiv über ac. High preset und dann seh ich da low settings X-D

[Achill]

Die fps sind irgendwie seltsam, mein 2500k@4,6Ghz schafft 74 fps:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10956839&postcount=25
Es scheint wohl einfach nicht mit so vielen Threads gut zu skalieren?

Die Werte waren von 1080p in high, mit 1280x800 in Low sind es ~98fps im CFX. Ich schau gleich mal ob und wie viel Overhead durch MGPU erzeugt wird. Evtl. ist es auch HT was hier negativ Skaliert.

Was am AB-Bild auch nochmal gut zu sehen ist, sind die ~10GB RAM und ~17GB Pagefile!!! Ich habe schon in meinen besten Eng. den Leuten bei Stardock geschrieben, dass das mal Geprüft werden sollte / ein Check bim Start passieren sollte, dass das System entsprechend Konfiguriert ist.

---
Edit: Mit nur einer GPU gibt es zwar höher max. FPS, dafür sind die Frametimes nicht mehr so gut und auch die Avg.FPS sinken. Die genannte CPU-FPS schätze ich jetzt auf eine Hochrechnung bzgl. CPU-Auslastung ein, und hier "cheated" HT natürlich - ein echter und ein virtuellen Core mit jeweils ~10% Reserve machen keine 20% reale Leistungsreserve.

[Achill]

Mach mal Glare und Shadow höher. ;) Glare läuft massiv über ac. High preset und dann seh ich da low settings X-D

:P ... nur für dich das Extrem Preset: ~82fps

[HisN]

AotS möcht gern ~20GB Pagefile haben - WTH!

WUS? Mein Pagefile ist auf 1GB gestellt ...

[Hübie]

:P ... nur für dich das Extrem Preset: ~82fps

Siehste. Schon biste mehr im GPU-Limit. :naughty: Ich nehme mal an, dass die Frametimes durch die wechselnde Kameraposition so hässlich sind, oder? :confused:

WUS? Mein Pagefile ist auf 1GB gestellt ...

Und du hast noch mal wieviel RAM...? :|

[Achill]

Ich nehme mal an, dass die Frametimes durch die wechselnde Kameraposition so hässlich sind, oder? :confused:


Ja, die erste und letzte Markierung im Screenshot definiert den Lauf vom Benchmark, die zwei anderen Punkte ein Minima/Maxima um besser die Werte im Graphen interpretieren zu können. Die Frametime-Scala geht nur von 0-50 ms, damit sind diese gar nicht so schlecht.

WUS? Mein Pagefile ist auf 1GB gestellt ...
Ja, man kann diese bestimmt reduzieren. Deaktivieren geht nicht für MGPU und 16GB Ram. Habe auch Eintäge auf Steam / AotS Forum dazu gefunden, betrifft AMD und NV Karten gemeinsam. Hoffe StarDock macht da nochmal etwas bzw. konkretisiert etwas die Anforderungen.

Bei RotTR wird die Pagefile auch schnell >10GB groß ... evtl. ein Win10 Bug (System ist frisch installiert).

[Achill]

AotS will anscheinend Bandbreite bzw. Zugriffszeiten bei RAM.

Mit DDR4-2000 15-15-15-35 sind die Avg.FPS unter High+1080p: ~84 fps
Mit DDR4-2000 12-12-12-29 sind die Avg.FPS unter High+1080p: ~91 fps

=> Timings scheinen gut durch zu schlagen.

[Hübie]

Dann probiere doch auch mal 2666 & 3000, sofern möglich. Das ist ja mal interessant. Wie ist doch gleich die VRAM Auslastung? 3500 MB bei extreme seh ich da. DRAM liegt bei satten 10 GB (dennoch sollte kein swap file nötig sein :|).

[Achill]

Dann probiere doch auch mal 2666 & 3000, sofern möglich. Das ist ja mal interessant. Wie ist doch gleich die VRAM Auslastung? 3500 MB bei extreme seh ich da. DRAM liegt bei satten 10 GB (dennoch sollte kein swap file nötig sein :|).

Ich schau mal was bei meinen RAM geht, hätte nicht gedacht das Timings so viel ausmacht. Das der Takt dann auch merklichen Einfluss bei Quad-Channel hat, AotS scheint hier neue Maßstäbe bzgl. Anforderung zu setzen.

Ja, VRAM ist bei:
- High+1080p bei ~3.1GB
- Extrem+1080p ~3.5GB
Kann man jetzt nicht sagen, dass nicht an die GTX 970 gedacht wurde ... ;)

Evtl. sehen wir neben der besseren Multi-Core-Auslastung in aktuellen Spielen jetzt auch den Effekt bei RAM, da mehr Cores die wirklich Rechnen (also kein Single-/Dual-Core-Spiele) natürlich auch mehr Bandbreite brauchen, und nicht nur gute Timings.

[dildo4u]

Kann das bestätigen das Coresklaing ist grottig hab 52 statt 49fps im CPU Limit AMDX6@ 3.5GHZ vs FX 8320 mit 4Ghz.Bei Tomb Raider bringt mir der FX 10fps.
Ich hätte gedacht das gerade ein RTS mit DX12 deutlich besser mit Cores skaliert.

[Achill]

Dann probiere doch auch mal 2666 & 3000, sofern möglich. Das ist ja mal interessant. Wie ist doch gleich die VRAM Auslastung? 3500 MB bei extreme seh ich da. DRAM liegt bei satten 10 GB (dennoch sollte kein swap file nötig sein :|).

Ram mit 2666/3000 geht leider nicht, habe eine Weile probiert, das beste war ein Win10 Boot bei 2666 und 1.35V ... :D

Kann das bestätigen das Coresklaing ist grottig hab 52 statt 49fps im CPU Limit AMDX6@ 3.5GHZ vs FX 8320 mit 4Ghz.Bei Tomb Raider bringt mir der FX 10fps.
Ich hätte gedacht das gerade ein RTS mit DX12 deutlich besser mit Cores skaliert.


Der FX könnte an der Bandbreite / Timings verhungern, siehe die Werte beim Hasi-E, der Unterschied von 2400 -> 2000 MHz ist rund -11% in den Avg.FPS. Auch wenn der FX/X6 eine andere Leistungsklasse ist, so können doch die gleichen Effekte eintreten wenn die Daten nicht schnell genug aus dem RAM kommen.
Das Ergebnis von "Verhungern" kann dann auch wie "nicht Skalieren" aussehen - vorausgesetzt es ist kein SW-Problem.

[dildo4u]

Die Final ist raus Performance hat sich bei mir nich mehr Verbessert.

FX 8320e@4.2Ghz GTX 970 1.3Ghz

1080p High Preset leicht CPU Limitiert nicht immer volle GPU Auslastung.

Asynchron Compute on 43.5fps

http://abload.de/img/ashescomputeontjscl.png

Asynchron Compute off 45.8fps

http://abload.de/img/ahesasynhronhighyikr9.png

1080p Extreme

Asynchron Compute on 33.6

http://abload.de/img/ashescomputeonextremew8uoy.png

Asynchron Compute off 34.4

http://abload.de/img/ashescomputeoffextremewujs.png

[aufkrawall]

Mit Hawaii Pro (maximal 1040Mhz) ist die Performance hier auch wie immer, ~53fps in WQHD High Preset mit Async Compute vs. ~55fps auf der 980 1,4Ghz ohne AC.
Das Spiel heizt auch ohne AC hier ziemlich. Mal sehen, ob mit oder ohne AC stärker gedrosselt wird.

[dildo4u]

Was bringt denn nun Compute bei einer 390 z.b beim Extreme Preset?

[aufkrawall]

Bei max Details ohne MSAA bringt es ca. 11,5% in WQHD.

off:
http://abload.de/thumb/acoffeys3f.png (http://abload.de/image.php?img=acoffeys3f.png)

on:
http://abload.de/thumb/aconoqs54.png (http://abload.de/image.php?img=aconoqs54.png)

[dildo4u]

Danke für den Test schätze mal für die versprochenen 20% muss das noch implementiert werden.

https://twitter.com/dankbaker/status/714616909434630144

[Kartenlehrling]

Hat das Spiel überhaupt seine spielerische Daseinsberechtigung oder
wird es in 10 Jahren nur als eins der vielen Mantle und DX12 Benchmark in Erinnerung bleiben?

[aufkrawall]

Danke für den Test schätze mal für die versprochenen 20% muss das noch implementiert werden.

https://twitter.com/dankbaker/status/714616909434630144
Evtl. wärens mit der X noch ein paar % mehr, ist aber Speku.
Lief übrigens komplett ungedrosselt, Trine 2 in 4k oder 5k zieht mehr Strom. Etwas mehr Pixel könnte ich mit VSR bei kümmerlichen 60Hz noch hinbekommen.

[dildo4u]

Hat das Spiel überhaupt seine spielerische Daseinsberechtigung oder
wird es in 10 Jahren nur als eins der vielen Mantle und DX12 Benchmark in Erinnerung bleiben?
Singleplayer soll dürftig sein ansonsten ist es Kompetent.

https://youtu.be/crPoyVGbNfQ

[Hübie]

Hat das Spiel überhaupt seine spielerische Daseinsberechtigung oder
wird es in 10 Jahren nur als eins der vielen Mantle und DX12 Benchmark in Erinnerung bleiben?

Also wenn du so fragst: Das ist ein Spiel? :confused: :freak: Ich fress n Besen wenn es ausgefeilten Singleplayer wie Starcraft oder auch dessen Vielfalt bietet. Ist wohl eher Supreme Commander mit Raumschiffen am Boden (oh ja das Setting turnt echt ab).

[N0Thing]

Also wenn du so fragst: Das ist ein Spiel? :confused: :freak: Ich fress n Besen wenn es ausgefeilten Singleplayer wie Starcraft oder auch dessen Vielfalt bietet. Ist wohl eher Supreme Commander mit Raumschiffen am Boden (oh ja das Setting turnt echt ab).

Wie viele andere Spiele dieses Genres kennst du denn, die einen ausgefeilten Singleplayer wie StarCraft haben? Nach dem Maßstab sind alle anderen RTS-Spiele keine Spiele. :freak:

[dildo4u]

Ashes Of The Singularity: DX11 vs DX12 Tech Analysis

https://youtu.be/mUlHRyz_GmY

[aufkrawall]

In 3200x1800 per VSR drosselt die GPU auch nicht. Ich würde sagen, auch mit AC ist das Spiel recht harmlos im Vergleich zu Trine 2 mit SSAA, das übrigens nur DX9 ist.
Mein undervolteter Hawaii Pro dürfte bei Ashes ca. GM204 OC Effizienz haben. :D