The Tech Report: HighSpeed-Videos zeigen Micro-Stuttering [Archiv] - Seite 3

samm

2013-03-27, 22:00:50

GpuView macht die Hooks über die komplette Pipeline, nicht nur an den Anfang. Es wird auch der Bufferswap angezeigt (auch wenn der Artikel auf Anandtech das Gegenteil behauptet). Es stimmt aber schon dass es sehr unübersichtlich ist, eben nicht für End-User gedacht.Naja, der eigentliche Anfang, t_game wie's bei PCPer heisst, fehlt ja leider. GpuView ist aber nicht das Tool / die Tools, die PCPer verwenden, sondern ein anderes Analystetool, das Gipsel und Anandtech erwähnt haben, oder?

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Dissected-Full-Details-Capture-based-Graphics-Performance-Testin

PCPer ist ja sogar (mit-)Urheber der ganzen Geschichte. Bin etwas enttäuscht von Anandtech, sie bei die nicht nennen.

Es gibt noch ein Problem, dropped frames aus den Farben zu extrahieren, ist auch spannend, wird bei hoher framrate sicher merklicher (da nur 16 Farben für's Overlay verwendet werden).

Wird cool, wenn die ganzen Review-Seiten/-Hefte ihre Hardware drastisch aufrüsten müssen, damit das Capture funktioniert^^

Was meine aktuelle Hardware angeht: Ich kann nur sagen, dass ich auch mit der PCPer-Methode bestätigt mit der 7970 zufrieden sein kann - zeigt durchweg gute Varianz (bis auf FC3) in den bisher gezeigten Game-Messungen :)

Vielleicht interessant für Pest, Zitat von http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Dissected-Full-Details-Capture-based-Graphics-Performance-Test-2 :
Our current running theory for a stutter evaluation is this: find the current frame time variance by comparing the current frame time to the running average of the frame times of the previous 20 frames.

[letzter Edit für heute] Was immer noch fehlt, ist "Latenz" im Sinne von: Was wird verschenkt durch die Smootherei / VSync. Also nichts mit timestamps / Rekonstruktion der Zeit zwischen t_present und t_display.

Marty98

2013-03-27, 22:16:44

@samm

Finde ich auch ganz schwach! Sie wissen über PCPer bescheid, siehe Comment von Ryan Smith:

"On a practical level we've been over this with a fine-toothed comb. So have PCPerspective and others."

http://www.anandtech.com/show/6862/fcat-the-evolution-of-frame-interval-benchmarking-part-1

@All

Crossfire-Performance bei Tombraider ist ja ein Desaster! Dabei ist es doch Quasi ein AMD-Spiel. :/

http://www.tomshardware.com/reviews/graphics-card-benchmarking-frame-rate,3466-12.html

edit:

PcPer brachte heute auch einen neuen Artikel zu dem Thema:

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Dissected-Full-Details-Capture-based-Graphics-Performance-Testin

Was hier neu ist: Anscheinend gibt es ein Problem mit CrossFire + Eyefinity. Hier scheinen die Frames der zweiten GPU gar nicht auf dem Monitor anzukommen.

Bin etwas geschockt vom dem Crysis 3 Test. Eine Single 7970 GE ist deutlich schneller als 2 davon in Crossfire:

http://www.pcper.com/files/imagecache/article_max_width/review/2013-03-25/Crysis3_1920x1080_OFPS.png

Bei FarCry3 hat SLI jedoch ein ähnliches Problem!

http://www.pcper.com/files/imagecache/article_max_width/review/2013-03-25/FarCry3_1920x1080_OFPS.png

Blaire

2013-03-28, 00:18:11

PcPer brachte heute auch einen neuen Artikel zu dem Thema:

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Dissected-Full-Details-Capture-based-Graphics-Performance-Testin

"In half of our tested games, the pair of Radeon HD 7970s in CrossFire showed no appreciable measured or observed increase in performance compared to a single HD 7970. I cannot overstate that point more precisely: our results showed that in Battlefield 3, Crysis 3 and Sleeping Dogs, adding in another $400+ Radeon HD 7970 did nothing to improve your gaming experience, and in some cases made it worse by introducing frame time variances that lead to stutter."

Genickschuss für Crossfire^^ Für Kenner eigentlich keine Überraschung, schlimm daran lediglich, daß es viele Jahre brauchte, bevor Bewegung in die Sache kam. Malsehn was der angekündigte AMD-Hack da noch herausholen kann, bin gespannt auf weitere Ergebnisse.

Marty98

2013-03-28, 00:21:20

Hier ist ein sehr gut gemachtes Video wo Ryan von PcPer erklärt wie das ganze neue Messverfahren funktioniert:

http://www.youtube.com/watch?feature=player_embedded&v=CsHuPxX8ZzQ#hd=1

Marty98

2013-03-28, 00:26:56

Genickschuss für Crossfire^^ Für Kenner eigentlich keine Überraschung, schlimm daran lediglich, daß es viele Jahre brauchte, bevor Bewegung in die Sache kam. Malsehn was der angekündigte AMD-Hack da noch herausholen kann, bin gespannt auf weitere Ergebnisse.

Was ich hier besonders schlimm finde ist dass sogar renommierte Tester wie z.B. die bei PCGH es bisher nicht richtig wahr haben wollten. Erst vor paar Wochen gab es ein PCGH Video wo (ich glaube Raff) ein Crossfire System filmte wo auf dem Monitor fette 90 Fraps FPS zu sehen waren, diese aber reine Phantasie sind. In Wirklichkeit waren dort 50 FPS zu sehen, was eine einzelne 7970 auch schafft. Wird mal Zeit dass PCGH aufwacht!

Ronny145

2013-03-28, 00:35:59

Was ich hier besonders schlimm finde ist dass sogar renomierte Tester wie z.B. die bei PCGH es bisher nicht richtig wahr haben wollten. Erst vor paar Wochen gab es ein PCGH Video wo (ich glaube Raff) ein Crossfire System filmte wo auf dem Monitor fette 90 Fraps FPS zu sehen waren, diese aber reine Phantasie sind. In Wirklichkeit waren dort 50 FPS zu sehen, was eine einzelne 7970 auch schafft. Wird mal Zeit dass PCGH aufwacht!

Erwarte von der PCGH in der Richtung nichts solange es zu Lasten von AMD gehen könnte. Das hat sich in der jüngeren Vergangenheit immer wieder gezeigt. Die PCGH war vielleicht früher mal der Vorreiter, heute aber mit der starken AMD-Lastigkeit ist das nicht mehr drin. Die meisten checken das gar nicht.

Marty98

2013-03-28, 01:25:21

Erwarte von der PCGH in der Richtung nichts solange es zu Lasten von AMD gehen könnte. Das hat sich in der jüngeren Vergangenheit immer wieder gezeigt. Die PCGH war vielleicht früher mal der Vorreiter, heute aber mit der starken AMD-Lastigkeit ist das nicht mehr drin. Die meisten checken das gar nicht.

Ich glaube nicht dass PCGH parteisch oder pro AMD ist. Sie verschlafen einfach nur Innovationen.

Iruwen

2013-03-28, 09:33:08

PCGH war und ist bei solchen Berichten immer noch weit vor dem Gros der restlichen Seiten, die haben aber nunmal auch ein bzw. zwei Magazine zu publishen. Bzw. komisch wie sich das wendet, sonst hieß es doch immer die seien pro NV :freak:

boxleitnerb

2013-03-28, 09:39:43

N0Thing

2013-03-28, 10:06:47

Naja, es wird z.B. beim Titan-Test eine übertaktete 6GB 7970 mitgetestet, aber eine übertaktete 4GB 680 hab ich bei denen eigentlich noch nicht gesehen in den Benchmarks. Das mutet schon komisch an.

Bei der Onlineausgabe des Titantests gab es keine 6GB HD 7970 im Test und auch keine übertaktete Version der HD 7970.
Beim Test Titan (SLI) gegen Radeon HD 7970 Toxic (Crossfire) hat man die einzige 6GB Karte der HD 7970 Reihe genommen und dort sowohl mit deren Standardtaktraten als auch mit denen OC-BIOS getestet.

Dieses Vorgehen komisch zu finden, kann ich nicht nachvollziehen. Da hat die Kritik für mich eher einen faden Beigeschmack. Oder sieht das Bild im Heft ganz anders aus?

Marty98

2013-03-28, 10:15:06

PCGH war und ist bei solchen Berichten immer noch weit vor dem Gros der restlichen Seiten, die haben aber nunmal auch ein bzw. zwei Magazine zu publishen.

Das ist doch gerade ein Grund um #1 bei Innovationen zu sein! Wieso sollte ich mir eine Printausgabe der PCGH kaufen wenn ich weiß dass Ihre SLI/Crossfire Tests absolut falsch sind, und es auf Seiten wie PCPer, Techreport, Anandtech oder Tomshardware die richtigen Benchmarks gibt, dazu noch kostenlos?

Angiesan

2013-03-28, 10:16:02

Bitte nicht den Thread schreddern mit "Die sind Grün oder Rot!!!"

BTT muss ich das so verstehen,dass die Grafikkarten zwar die Frames berechnet, aber so schnell hintereinander ausgegeben werden das dieses wieder verworfen werden weil sie nicht angezeigt werden können???
Wenn dem so ist, sind ja eigentliche alle Messungen bezüglich der Leistungsfähigkeit von MGPU Systemen egal ob AMD oder NV neu zu vermessen.

Bin geschockt, das Problem scheint größer zu sein wie zuerst angenommen und nimmt bedrohliche Ausmaße an, wenn sich das bestätigen sollte, ist MGPU schneller tot wie es wiederbelebt wurde.Vielleicht sind die Techniken auch flexibel genug um hier AFR durch alternativen zu ersetzen die vielleicht nicht nur auf die maximalen FPS abzielen sondern die es einem erlauben maximale Qualität ohne FPS Verlust zu fahren:wink:
Bin gespannt wie sich das entwickelt.

Edit: Ohh man habe den Artikel jetzt gelesen und das ein oder andere Video auf deren Seite angeschaut, solltet ihr mal machen ist interessant.
Die AMD User können die 2 Karte ausbauen, bringt bis auf sehr wenige Ausnahmen nichts außer eine hohe Fraps-Anzeige und einen hohen Stromverbrauch, dass ist Verarsche auf einem vollkommen neuen Niveau, das was man hier sieht, sind die gefühlten FPS der PCGH und wie man sehen kann lagen die Jungs da komplett falsch die sind noch niedriger! Sehr oft nur aus SGPU Niveau NV hat weniger Probleme aber auch da ist noch viel zu tun.

Wie will AMD die 7990 vertreten mit diesen Ergebnissen im Hintergrund?

Iruwen

2013-03-28, 10:39:19

Das ist doch gerade ein Grund um #1 bei Innovationen zu sein! Wieso sollte ich mir eine Printausgabe der PCGH kaufen wenn ich weiß dass Ihre SLI/Crossfire Tests absolut falsch sind, und es auf Seiten wie PCPer, Techreport, Anandtech oder Tomshardware die richtigen Benchmarks gibt, dazu noch kostenlos?
PCGH hat länger als alle anderen auf die Mikrorucklerproblematik hingewiesen und die hatten auch schon länger Frametimegraphen, jetzt hat jemand anders mal eine bessere Messmethode aus dem Ärmel geschüttelt und sie sind kacke weil sie nicht gleich auf den Zug aufspringen, wobei offenbar noch nichtmal ganz klar ist ob die Messmethode optimal und praxisnah ist? Die Frametimegraphen finden sich iirc auch nur in der Printausgabe, neben anderen Details.

Marty98

2013-03-28, 10:49:29

Bitte nicht den Thread schreddern mit "Die sind Grün oder Rot!!!"

BTT muss ich das so verstehen,dass die Grafikkarten zwar die Frames berechnet, aber so schnell hintereinander ausgegeben werden das dieses wieder verworfen werden weil sie nicht angezeigt werden können???
Wenn dem so ist, sind ja eigentliche alle Messungen bezüglich der Leistungsfähigkeit von MGPU Systemen egal ob AMD oder NV neu zu vermessen

Ja, das ist der Fall. Manchmal stellt ein ganzes Frame nur wenige Zeilen im MonitorBild da. Schau Dir das Video an, hier wird es sehr gut gezeigt (die einzelnen Frames etc). Bei Minute 11 ist genau dieses Problem zu sehen:

http://www.youtube.com/watch?feature=player_embedded&v=CsHuPxX8ZzQ#hd=1

PCGH hat länger als alle anderen auf die Mikrorucklerproblematik hingewiesen und die hatten auch schon länger Frametimegraphen, jetzt hat jemand anders mal eine bessere Messmethode aus dem Ärmel geschüttelt und sie sind kacke weil sie nicht gleich auf den Zug aufspringen, wobei offenbar noch nichtmal ganz klar ist ob die Messmethode optimal und praxisnah ist? Die Frametimegraphen finden sich iirc auch nur in der Printausgabe, neben anderen Details.

Diese kamen aber immer von Fraps, obwohl seit MONATEN klar ist dass Fraps nicht das anzeigt was der User sieht. Nach PcPer sind nun 10 andere Seiten auf die neue Messmethode gestern aufgesprungen, PCGH ist aber nicht dabei. Imho keine einzige(r) deutsche Seite/Magazin.

Angiesan

2013-03-28, 10:58:09

Danke Marty, ich habe den Artikel jetzt auch gelesen und es ist erschreckend Crossfire hat überhaupt keine Effekt, im Gegenteil das verschlimmert in den meisten Fällen den Spielablauf.

Jetzt ist es wirklich noch interessant ob ein Framelimiter das beheben kann!? Ansonsten ist das ein Skandal und zeigt mal wieder sehr sehr gut was ein Placeboeffekt so alles bewirken kann, ein Blick auf die FRAPS Anzeige und 25 wirkliche FPS sind auf einmal genug zum spielen:biggrin:

Marty98

2013-03-28, 11:01:23

Jetzt ist es wirklich noch interessant ob ein Framelimiter das beheben kann!? Ansonsten ist das ein Skandal und zeigt mal wieder sehr sehr gut was ein Placeboeffekt so alles bewirken kann, ein Blick auf die FRAPS Anzeige und 25 wirkliche FPS sind auf einmal genug zum spielen:biggrin:

Ich nehme mal an ja, weil VSync Crossfire DRASTISCH verbessert (ist extra Abschnitt dazu im PCPer Artikel), also die Micro-Ruckler. Allerdings hast du bei VSYNC mehr Lag, und auch beim Framelimiter.

dargo

2013-03-28, 11:36:49

Ich nehme mal an ja, weil VSync Crossfire DRASTISCH verbessert (ist extra Abschnitt dazu im PCPer Artikel), also die Micro-Ruckler. Allerdings hast du bei VSYNC mehr Lag, und auch beim Framelimiter.
Lag beim Framelimiter? Halte ich für ein Gerücht. ;)

Rente

2013-03-28, 12:20:22

Lag beim Framelimiter? Halte ich für ein Gerücht. ;)
Es kann mehr Lag geben, zumindestens ergibt sich das indirekt auch aus dem Anand-Artikel mit den Erklärungen von AMD.

dargo

2013-03-28, 12:45:25

Es kann mehr Lag geben, zumindestens ergibt sich das indirekt auch aus dem Anand-Artikel mit den Erklärungen von AMD.
Reden wir gerade vom Lag bei Multi-GPU oder Single-GPU? Beim ersteren kann ich nicht mitsprechen. Beim zweiteren muss der aber verdammt gering sein, denn ich nehme keinen wahr. Ganz im Gegensatz zu Vsync.

N0Thing

2013-03-28, 13:50:00

PcPer brachte heute auch einen neuen Artikel zu dem Thema:

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Dissected-Full-Details-Capture-based-Graphics-Performance-Testin

Hatte jetzt auch endlich Zeit, den Beitrag von PC Perspective komplett zu lesen.
Toller Artikel, gut geschrieben und sowohl die Thematik als auch die Hintergründe gut beschrieben. Ich würde mich freuen, wenn mit der Zeit alle bekannten Seiten auf diese Testvariante umsteigen, auch wenn es bei einzelnen GPUs keinen großen Unterschied zwischen den Ergebnissen von Fraps und der observed frame rate zu sehen gibt. Dennoch sagt der Frameverlauf in einem Spiel mehr aus, als die üblichen min/max/avg fps.

Marty98

2013-03-28, 13:58:58

Jede kann es nicht tun, weil das Setup an die 2000 Euro kostet, aber die großen Seiten haben es ja bereits getan (hab auf die schnelle 6 gezählt). Leider noch keine deutsche dabei.

OC_Burner

2013-03-28, 14:59:14

Das Setup von PC Perspective wird aber ein bißchen mehr als 2000Euro gekostet haben. Allein die DVI-DualLink-Capturecard wird um die 1500€ teuer sein. Dann der externe Rechner mit Thunderbolt-Raid-Verbund.

Der Preis läßt sich dennoch auf ca. 1000€ drücken. DVI-SingleLink-Capturekarten gibt es ab ca. 800€ (natürlich auf 1080p60 beschränkt). Externer Rechner ist auch nicht zwangsweise nötig (vereinfacht aber das Handling enorm). Ein großes Raid-System mit Thunderbolt ist natürlich traumhaft aber eine aktuelle SATA 3 SSD langt dafür auch (archivieren läßt sich auf HDD). Platzsparende und verlustlose Codecs die in RGB aufzeichnen gibt es ebenso.

Marty98

2013-03-28, 15:01:12

Ich finde ein zweiter PC ist zwingend nötig. Sonst könnten Mikroruckler wegen des Capture-Prozesses entstehen.

Rente

2013-03-28, 15:08:48

Ich finde ein zweiter PC ist zwingend nötig. Sonst könnten Mikroruckler wegen des Capture-Prozesses entstehen.
Genau das nutzen sie doch, oder hab ich den Artikel falsch gelesen?

€: Achso, es bezog sich auf die Aufstellung von OC....

MadManniMan

2013-03-28, 15:55:07

Was mir im Moment fehlt: eine detaillierte Auflistung der Einstellungen bei den Spielen! Ich gehe von maximalen Details aus, aber wird AA/AF genutzt oder erzwungen?

Ich hoffe, da folgt eine Meeenge neuer Artikel mit diesem Setup. Allein die Problematik Hypethreading oder CPU-Limits oder you name it birgt noch so viel Potential! Wo bleibt die 3DCenter-News :D

Marty98

2013-03-28, 16:01:45

Anandtech will nächste Woche einen sehr ausführlichen Artikel zu dem Thema bringen.

MadManniMan

2013-03-28, 16:15:11

Akkarin

2013-03-28, 17:10:33

Nachdem ich den pcp articel überflogen hab: Sehe ich das richtig das es bei AMD doch keine single-gpu-microruckler Problematik gibt ? Die frametimes sehen sehr stabil aus.

Knuddelbearli

2013-03-28, 17:11:49

nicht wirklich größere Probleme als NV so wies aussieht

auch NV hat ja mit bestimmten CPU ( Stichwort HT ) und in manchen Spielen sehr unregelmäßige Frames

PHuV

2013-03-28, 18:06:58

Jede kann es nicht tun, weil das Setup an die 2000 Euro kostet, aber die großen Seiten haben es ja bereits getan (hab auf die schnelle 6 gezählt). Leider noch keine deutsche dabei.

Das Setup von PC Perspective wird aber ein bißchen mehr als 2000Euro gekostet haben. Allein die DVI-DualLink-Capturecard wird um die 1500€ teuer sein. Dann der externe Rechner mit Thunderbolt-Raid-Verbund..
1895 $

http://www.rsnmedical.com/Datapath-VisionDVI-DL.html

pest

2013-03-28, 19:14:17

man sollte bei der capture-methode mehrere dinge bedenken

1. nvidia profitiert massiv von dieser methode weil sie die ausgabe der berechneten frames verzögern

2. es stellt sich die frage ob man da nicht den teufel mit dem belzebub austreibt, weil die ausgabezeiten zu einem anderen systemzeitpunkt gehören

Godmode

2013-03-28, 19:17:27

OC_Burner

2013-03-28, 19:21:41

1895 $

http://www.rsnmedical.com/Datapath-VisionDVI-DL.html

Das ist interessant bzw. fällt mir erst jetzt auf.

Die gleiche Karte wird mehrmals aber unter anderen Namen vertrieben.

Einmal von Datapath unter der Bezeichnung VisionDVI-DL (http://www.datapath.co.uk/products/video-capture-cards/visiondvi-dl)

und von EMS-Imaging als XtremeDVI-DualLink (http://ems-imaging.com/index.php/products-by-function/1-ch-dual-link-dvi-capture)

Die XtremeDVI-DualLink gibt es billiger wenn direkt aus UK importiert (£999 (http://www.videowallsolutions.net/xtremedvi-duallink-pcie-input-up-to-4kx4k-video-capture-card.html) --> aktuell 1181€).
Die XtremeRGB-Ex1 als kleinere Schwester ist breits für den halben Preis zu haben (£495 (http://www.videowallsolutions.net/xtremergb-ex1-pcie-hdmidvivga-capture.html)).

Marty98

2013-03-28, 19:24:49

Falls es noch jemand nicht mitbekommen hat, AMD hat sich zu dem Problem diese Woche auch geäußert:

http://www.anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps

Zusammenfassend sagen sie aus dass sie lange Zeit angenommen haben die Stutter-Problematik ist nicht durch Treiber zu fixen, sondern ein Engine/Windows Problem. Nun haben sie das Problem aber voll erkannt und arbeiten intensiv daran.

"Ultimately AMD’s message has been one of information, explanation, and admission of oversight. AMD has been clear with us from the start that the primary reason they even ended up in this situation is because they weren’t doing sufficient competitive analysis, and that they have revised their driver development process so that they now do this analysis to prevent future problems. The fact that NVIDIA seemed to have figured all of this out much earlier was a point of frustration for AMD. The company likely left non-negligable amounts of performance on the table over the years, which could've definitely helped in close races."

Sie raten auch ausdrücklich von Fraps ab:

"AMD’s concern – and one that NVIDIA has shared with them in the past – is that measuring the rendering pipeline at the beginning of the pipeline like FRAPS goes about it does not accurately represent what the end user is seeing, due to the various buffers in the Pipeline and how the Present mechanism works."

http://images.anandtech.com/doci/6857/Heartbeat_575px.png
http://images.anandtech.com/doci/6857/Microstutter_575px.png

pest

2013-03-28, 19:44:45

@1. Hast du dazu eine Quelle?

war ein interview von pcper mit nvidia, link hier aus dem thread

dieses frame-pacing will ja amd jetzt auch einsetzen, ein schelm wer böses dabei denkt

ich muss aber zugeben:

ich verstehe das problem an fraps immer noch nicht richtig.

-nvidia verlängert die latency und schiebt zeit zwischen present und display (frame-pacing).
-es ist auch klar das fraps kein tool ist um die latency zu messen, aber m.M. nach ist doch entscheident was ich auf dem bildschirm sehe und nicht wann und das misst fraps auch

Godmode

2013-03-28, 20:15:20

war ein interview von pcper mit nvidia, link hier aus dem thread

dieses frame-pacing will ja amd jetzt auch einsetzen, ein schelm wer böses dabei denkt

ich muss aber zugeben:

ich verstehe das problem an fraps immer noch nicht richtig.

-nvidia verlängert die latency und schiebt zeit zwischen present und display (frame-pacing).
-es ist auch klar das fraps kein tool ist um die latency zu messen, aber m.M. nach ist doch entscheident was ich auf dem bildschirm sehe und nicht wann und das misst fraps auch

Ok danke.

Das Problem ist das die Zeit zwischen t_present und t_display bei Crossfire total aus dem Ruder läuft. Es macht einfach keinen Sinn, wenn ich Frames berechne, die dann aber nicht angezeigt werden. Beim frame-pacing liegt das Problem IMO darin, dass ich nicht zuviel Zeit einschieben darf, weil dann passiert das, was du gesagt hast. IMO geht es bei frame-pacing auch darum den nächsten t_present Call zu verzögern. frame-pacing wirkt sich also auch auf die Engine aus, IMHO. Ich glaube das schrieb er sogar im Artikel.

pest

2013-03-28, 20:38:14

Das Problem ist das die Zeit zwischen t_present und t_display bei Crossfire total aus dem Ruder läuft.

das verstehe ich nicht

Godmode

2013-03-28, 22:24:42

das verstehe ich nicht

Wenn die Game Engine mit der Berechnung aller ihrer Arbeiten fertig ist, wird ein Present Call gemacht, was nichts anderes heißt, als dass jetzt gerendert werden soll. PCPer bezeichnet diesen Zeitpunkt mit T_present und diese Zeit misst auch Fraps.

T_display ist der Zeitpunkt an dem das Bild am Monitor angezeigt wird. Egal ob ein ganzes Bild mit VSync oder nur ein Teilbild ohne VSync. Im Optimalfall ist T_present + T_render irgendwo bei 16,6 ms was 60 FPS entspricht.

Beim Crossfire ist aber die Zeit, die zwischen T_present und T_display liegt, total unterschiedlich. Wenn diese Zeitspanne aber immer stark wechselt, rückkoppelt das auch auf die Gameengine, im negativen Sinne.

http://www.pcper.com/files/imagecache/article_max_width/review/2013-03-25/howgameswork.jpg

samm

2013-03-29, 00:57:33

dieses frame-pacing will ja amd jetzt auch einsetzen, ein schelm wer böses dabei denkt
(...)
-es ist auch klar das fraps kein tool ist um die latency zu messen, aber m.M. nach ist doch entscheident was ich auf dem bildschirm sehe und nicht wann und das misst fraps auchAber ich würde wirklich gern die Differenz zwischen t_present und t_display wissen, wie's auf Godmode's Grafik heisst. Denn das ist eben auch eine unangenehme Latenz-, d.h. Gummibandeffekt-, quelle, vermute ich, und wie du schreibst, ist es wohl das, was nVidias Ausgleichsmethode schon verursacht und AMDs wohl noch verursachen wird. Konkret interessant wäre zudem nicht nur die zusätzliche Latenz per se, sondern die Varianz davon, weil das ja wiederum eine Stotterquelle ist.
Allerdings sind die SLi-Frames ja schon zum Zeitpunkt t_present gleichmässiger als die Crossfire-Frames, da muss also bereits früher etwas (was? und wie?) eingreifen.

Darf ich dich, da du nun im Thread bist, noch bezüglich deines frappo-Tools auf folgendes Posting hinweisen? http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9710907#post9710907

Beim Crossfire ist aber die Zeit, die zwischen T_present und T_display liegt, total unterschiedlich.Das ist nur ein zusätzliches Problem. Die Schwankungen bei Crossfire sind schon zu t_present sehr stark, und durch die restliche Pipeline entstehen dann die Effekte mit den "runt frames" und den "dropped frames" (ohne Limiter, ohne VSync). Die dropped frames sind übrigens wohl der Grund, weshalb das "heartbeat stuttering" von der AMD-Folie zwar hässlich aussieht auf Fraps-Frametimes, aber vom User dennoch flüssig empfunden wird - nämlich der hässliche Fall, den PCPer aufzeigt, wo die resultierende Bildausgabe bei Crossfire zwar flüssig ist, aber von der letztlich sichtbaren Framerate her kaum schneller als eine einzelne Karte agiert.

Marty98

2013-03-29, 09:59:53

Unwinder : "I've already received hex reference colors from NV. MSI Afterburner with FCAT overlay support (3.0.0 beta 8) is expected to be released on Monday, EVGA Precsion 4.1.0 with FCAT overlay support will be available on the next week too".

OC_Burner

2013-03-29, 11:30:11

Soll FCAT nicht auch dem gemeinen Consumer verfügbar gemacht werden? Wenn Tools wie MSI-Afterburner oder EVGA-Precision und vielleicht sogar auch Fraps diesen Farboverlaycode eingebaut bekommen läßt sich doch prima festellen welches der Tools an der falschen Stelle den Hook einfügt oder misst.

Marty98

2013-03-29, 11:40:17

FCAT sind zwei Tools. Das erste ist der Overlay Hook, das zweite ein Auswertungstool für AVI Videos. Nvidia hofft dass beide Tools von anderen nachprogrammiert werden. Beim Overlay wird es ab Montag der Fall sein. Beim Auswertungstool wird es sicher länger dauern, aber man kann die Ergebnisse mit beliebigen Video-Editor (z.b. Virtual Dub) nachprüfen.

OC_Burner

2013-03-29, 12:21:26

Naja FCAT ist noch ein bißchen mehr als nur zwei Tools. Da gehören auch noch ein paar Scripte dazu die den Datensalat der Exceltabellen vom Analysetool aufbereiten soweit ich das verstanden habe. Das man mit VirtualDub händisch und zeitaufwendig analysieren kann sollte klar sein.

FCAT ist doch in Zusammenarbeit mit PC Perspective und Nvidia entstanden und wurde nun den Reviewerseiten zur Verfügung gestellt. Irgendwo war aber auch zu lesen das Consumer später auch Zugriff erhalten sollen. Wäre doch blöd wenn alles nochmal programmiert werden müsste.

Marty98

2013-03-29, 12:34:14

Imho hat PCPer noch ein eigenes Tool, welches jedoch nicht zu FCAT gehört. Dieses wertet den Datensalat aus.

Godmode

2013-03-29, 13:00:09

Das ist nur ein zusätzliches Problem. Die Schwankungen bei Crossfire sind schon zu t_present sehr stark, und durch die restliche Pipeline entstehen dann die Effekte mit den "runt frames" und den "dropped frames" (ohne Limiter, ohne VSync). Die dropped frames sind übrigens wohl der Grund, weshalb das "heartbeat stuttering" von der AMD-Folie zwar hässlich aussieht auf Fraps-Frametimes, aber vom User dennoch flüssig empfunden wird - nämlich der hässliche Fall, den PCPer aufzeigt, wo die resultierende Bildausgabe bei Crossfire zwar flüssig ist, aber von der letztlich sichtbaren Framerate her kaum schneller als eine einzelne Karte agiert.

Ich bin der Meinung, dass sich dieser Umstand rückwirkend auf T_present auswirkt.

OC_Burner

2013-03-29, 13:38:39

Imho hat PCPer noch ein eigenes Tool, welches jedoch nicht zu FCAT gehört. Dieses wertet den Datensalat aus.

Im Hardwareluxx (http://www.hardwareluxx.de/community/f14/frametimemessungen-amd-vs-nvidia-944341-4.html#post20396272) wurde der Downloadlink zu FCAT rev1.2 gepostest. Zeit zum Testen.:cool:

Godmode

2013-03-29, 18:04:41

Im Hardwareluxx (http://www.hardwareluxx.de/community/f14/frametimemessungen-amd-vs-nvidia-944341-4.html#post20396272) wurde der Downloadlink zu FCAT rev1.2 gepostest. Zeit zum Testen.:cool:

Aber das bringt ja nur was, wenn man den Output als Video aufzeichnet?

Marty98

2013-03-29, 18:36:00

Aber das bringt ja nur was, wenn man den Output als Video aufzeichnet?

genau.

Godmode

2013-03-29, 18:40:23

genau.

Schade, weil ich hätte gerne ein paar interessante Werte mit meinem Quad beigesteuert.

OC_Burner

2013-03-29, 18:58:12

Also auf die schnelle probiert funktioniert das ganze wirklich gut. Die vom Extractor erstellte Exceltabelle enthält alle notwendigen Werte für die Erstellung eines Diagramms. Die Scripte bekomme ich leider nicht richtig zum laufen. OpenOffice muss das nun erledigen. Ich werde mal ein paar Vergleiche zwischen Fraps und FCAT anstellen, mangels zweiten Rechner zum Aufnehmen wird das aber nicht unbedingt representativ sein.

Marty98

2013-03-29, 19:07:44

Für die Scripte brauchst du Pearl: http://www.perl.org/get.html#win32

OC_Burner

2013-03-29, 19:28:22

Für die Scripte brauchst du Pearl: http://www.perl.org/get.html#win32

Schon längst installiert genauso wie gnuplot;) Die Scripte wollen trotzdem nicht.

Im Anhang mal auf die schnelle eine vom Extractor erstellte Excel-Datei.

Marty98

2013-03-29, 19:39:22

Falls es jmd interessiert, hier sind die 16 Farbwerte die beim Overlay verwendet werden:

my @ref_colors = (
{ r => 0xff, g=> 0xff, b=>0xff, cname => "White",},
{ r => 0x00, g=> 0xff, b=>0x00, cname => "Lime",},
{ r => 0x00, g=> 0x00, b=>0xff, cname => "Blue",},
{ r => 0xff, g=> 0x00, b=>0x00, cname => "Red",},
{ r => 0x00, g=> 0x99, b=>0x99, cname => "Teal",},
{ r => 0x00, g=> 0x00, b=>0x80, cname => "Navy",},
{ r => 0x00, g=> 0x99, b=>0x00, cname => "Green",},
{ r => 0x00, g=> 0xff, b=>0xff, cname => "Aqua",},
{ r => 0x80, g=> 0x00, b=>0x00, cname => "Marron",},
{ r => 0xdc, g=> 0xdc, b=>0xdc, cname => "Silver",},
{ r => 0x80, g=> 0x00, b=>0x80, cname => "Purple",},
{ r => 0x80, g=> 0x80, b=>0x00, cname => "Olive",},
{ r => 0xa0, g=> 0xa0, b=>0xa0, cname => "Gray",},
{ r => 0xff, g=> 0x00, b=>0xff, cname => "Fuchsia",},
{ r => 0xff, g=> 0xff, b=>0x00, cname => "Yellow",},
{ r => 0xff, g=> 0xd0, b=>0x00, cname => "Orange",},
{ r => 0x00, g=> 0x00, b=>0x00, cname => "---vblank",}, #vblank
);

Marty98

2013-03-29, 22:12:20

Ich hab Leo erstmal auf die aktuellen Entwicklungen hingewiesen. Wenn er es nicht sowieso schon auf dem Schirm hatte, weiß er es jetzt!

Man darf die Leuchtturmfunktion vom 3DCenter nicht vergessen! Es mag nicht die meisten Leser haben, aber was hier berichtet wurde, wird auch von den Redakteuren der leserstarken Sites bemerkt ;)

Imho hat nicht eine deutsche Seite irgendwelche News zu dem Thema gebracht. Sie scheinen alle das Thema zu boykottieren. Früher war es ja komplett anders rum. Da wollten englischsprachige Medien nichts von Mikrorucklern oder AF Qualität wissen. So ändern sich die Zeiten.

aufkrawall

2013-03-29, 22:14:47

In der Tat, bezüglich etwaiger Bildqualitätsschwächen beider IHVs herrscht auch Flaute.
Wenigstens hat CB noch die LOD-Verschiebung für DX11 etwas im Fokus gehabt, "investigativ" war das jedoch auch nicht gerade.

Godmode

2013-03-29, 23:49:24

Imho hat nicht eine deutsche Seite irgendwelche News zu dem Thema gebracht. Sie scheinen alle das Thema zu boykottieren. Früher war es ja komplett anders rum. Da wollten englischsprachige Medien nichts von Mikrorucklern oder AF Qualität wissen. So ändern sich die Zeiten.

Es ist aufwendig und meistens sind sie sowieso sehr überlastet. Aber nicht mal einen Link auf die anderen Seiten finde ich auch schwach...
Andererseits ist das Interesse nicht sehr groß für solche Hardcore Messungen. Je genauer es wird, desto weniger Leute interessiert es.

In den anderen Foren wird gerade diskutiert, wie sinnlos das neue Verfahren ist. :freak:

Ich kann das alles nur begrüßen, schließlich tut sich endlich was und AMD arbeitet ja schon aktiv an dem Problem. Für uns Kunden ist es immer begrüßenswert, wenn die Messtechnik verbessert wird. Das war früher schon so. Erst als man die Filterqualität gemessen hat und das dann kritisiert hat, sind AMD und NV zur Tat geschritten und haben das verbessert.

samm

2013-03-30, 00:36:30

Imho hat nicht eine deutsche Seite irgendwelche News zu dem Thema gebracht. Sie scheinen alle das Thema zu boykottieren. Früher war es ja komplett anders rum. Da wollten englischsprachige Medien nichts von Mikrorucklern oder AF Qualität wissen. So ändern sich die Zeiten.Naja, so kritisch sehe ich das nicht: Ist erst wenige Tage her, dass die Tool-Kette an's Licht kommt, und es gibt viel zu überlegen, wie man das überhaupt nutzen soll. Es gibt Scripts, die anzupassen sind, und Hardware zum für das capture-n. Es gilt zu überlegen, was man mit den neuen Ergebnissen genau anfangen soll, worauf man achten soll, wie man Zusatznutzen erzeugen kann. Es sind Feiertage und Wochenenden und neue Hardware-Releases der Mittelklasse-Grafikkarten sind eben durch und Intels stehen an. Also: Nur Geduld, da kommt bestimmt noch Einiges :)

PCPerspective als Vorreiter hat ja schon einige Ergebnisse präsentiert, aber auch diese sind zugegebenermassen noch unter händischer Auswertung entstanden (sie arbeiten ja nach wie vor an den Scripts) und die Testmethodik ist nicht gerade wissenschaftlich (welche Treiber, welche Settings in Treibern und Spielen, welche Hardware, diverse Einflüsse diverser Einstellungen und auch den Einfluss der neuen Tools selbst gezielt untersuchen etc pp...). Wie gesagt: Es gibt noch viel zu tun, und es kommt bestimmt noch Einiges :)

TRob

2013-03-30, 01:22:34

Es ist aufwendig und meistens sind sie sowieso sehr überlastet.
......
In den anderen Foren wird gerade diskutiert, wie sinnlos das neue Verfahren ist. :freak:

Sehe ich auch so. Wenn man als Redakteur gerade mal zwei Tage Zeit bekommt eine neue Karte zu testen und dann einen Review dazu raus hauen muss, die meisten nicht mal die Zeit haben normale FPS-Benchmarks der direkten Vergleichsmodelle zu machen ...

macht es da überhaupt noch Sinn sich mit so einer komplexen Methode intensiver zu befassen? Vor allem wo nicht mal die "Aussage" richtig klar ist, was man nun davon hat.

Dass Multi-GPU ruckelt wissen wir doch alle schon ewig (CF mehr als SLI). Das man dieses Ruckeln los wird, wenn man die Performance weit über 60 fps steigert und dann vsync aktiviert, ist doch fast jedem Gamer bekannt.

Das sind die Aussagen, die ich aus der Sache heraushole...

Marty98

2013-03-30, 03:39:47

Eine Aussage ist auch dass das Mikroruckeln bei einer einzelnen 7970 GE in Wirklichkeit nicht so schlimm ist wie durch Fraps vermutet.

http://techreport.com/r.x/frame-capture/bl2-beyond-50.gif

aufkrawall

2013-03-30, 12:00:01

Sollte das Mikroruckeln mit sGPU dort nicht von AMD behoben sein?

Marty98

2013-03-30, 12:27:56

Der Borderlands Screenshot oben ist von Tech Report, getestet mit Catalyst 13.3 beta 2. Sie fixen es ja pro Spiel, und noch nicht global. Ist wohl noch kein Fix für Borderlands 2 drin. Im finalen 13.3 wird bestimmt viel mehr gefixt sein.

aufkrawall

2013-03-30, 13:35:25

Borderlands 2 sollte eigentlich schon mit 13.2 gefixt worden sein:
http://techreport.com/review/24218/a-driver-update-to-reduce-radeon-frame-times/5

Na ja, mal den ultimativen Fix abwarten, der mit 13.4 kommen soll. In zwei Tagen ist April. ;)

Butterfly

2013-03-30, 16:27:39

Eine Aussage ist auch dass das Mikroruckeln bei einer einzelnen 7970 GE in Wirklichkeit nicht so schlimm ist wie durch Fraps vermutet.

http://techreport.com/r.x/frame-capture/bl2-beyond-50.gif
Irgendwie vermisse ich die Anzahl der Frames bei dem Diagramm.
Wenn die CfX Lösung mehr FPS generiert, sind die über 50ms Werte relativ zu sehen. :rolleyes:

Coda

2013-03-30, 17:34:06

War das schon verlinkt?
http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-GeForce-GTX-Titan-GeForce-GTX-690-Radeon-HD-7990-HD-7970-CrossFi

Grestorn

2013-03-30, 19:20:53

Das ist eine unglaubliche Pleite für Crossfire. So krass hatte ich das nicht erwartet.

aufkrawall

2013-03-30, 19:24:36

Das ist eine unglaubliche Pleite für Crossfire. So krass hatte ich das nicht erwartet.
Hat irgendein vorangegangener Test etwas anderes verlautbart?

fondness

2013-03-30, 19:43:03

Was man halt nicht messen kann ist der Input-Lag, mit dem sich Nv das Frame-Metering mit SLI erkauft. AMD wird mit zukünftigen Treibern eine ähnliche Lösung optional anbieten.

Blaire

2013-03-30, 19:57:50

Das ist eine unglaubliche Pleite für Crossfire. So krass hatte ich das nicht erwartet.

Doch so war es schon immer. Jetzt sind wir zum Glück soweit , das dies nicht mehr so einfach durchgeht und nachgewiesen werden kann. Crossfire ist aktuell eine einzige Lüge.

boxleitnerb

2013-03-30, 19:58:52

Der Inputlag durch das Frame-Metering ist ein Tropfen auf den heißen Stein im Vergleich zum Inputlag durch VSync. Ich behaupte mal, die allermeisten würden den Unterschied beim Inputlag durch FM gar nicht spüren.

Knuddelbearli

2013-03-30, 20:12:31

nur hat man bei vsynch die wahl ;-)
und gerade die mögen die NV Jünger doch, die Wahl

Grestorn

2013-03-30, 20:23:07

nur hat man bei vsynch die wahl ;-)
und gerade die mögen die NV Jünger doch, die Wahl

Man hat die Wahl. Man kann SLI ausschalten.

Ohne Framemetering ist mGPU - wie man sieht - eh nur auf dem selben Level wie sGPU. Dann kann man auch gleich ganz darauf verzichten, zumal mGPU selbst ja auch immer zusätzliche Latenz bedeutet.

fondness

2013-03-30, 20:29:06

Man hat die Wahl. Man kann SLI ausschalten.

Ohne Framemetering ist mGPU - wie man sieht - eh nur auf dem selben Level wie sGPU. Dann kann man auch gleich ganz darauf verzichten, zumal mGPU selbst ja auch immer zusätzliche Latenz bedeutet.

Hm, wie lange hat es gedauert bis die Multi-GPU-µRuckler überhaupt entdeckt wurden? Seit wann geht NV aktiv dagegen vor? Jetzt auf einmal ist Multi-GPU nutzlos oder eine einzige Lüge wenn man dieses Frame-Metering nicht hat. Dieselben Leute haben freilich vor Jahren ihr Multi-GPU-System trotz dieser Ruckler verteidigt. :)

Godmode

2013-03-30, 20:49:04

Hm, wie lange hat es gedauert bis die Multi-GPU-µRuckler überhaupt entdeckt wurden? Seit wann geht NV aktiv dagegen vor? Jetzt auf einmal ist Multi-GPU nutzlos oder eine einzige Lüge wenn man dieses Frame-Metering nicht hat. Dieselben Leute haben freilich vor Jahren ihr Multi-GPU-System trotz dieser Ruckler verteidigt. :)

Also ich habe seit der Geforce 500 Serie SLI und hab das damals nicht für gut genug befunden, daher ist es wieder raus geflogen. Mit der 600 Serie wurde es dann deutlich besser und mit der 690 war ich - bis auch den geringen Speicher - recht zufrieden. Die Experimente mit zwei 690ern waren natürlich was anderes. Bei Titan funktioniert das SLI bisher auch gut. TombRaider hab ich mit 4-Way durchgespielt. IMO muss man entscheiden was einem wichtiger ist: Ultra flüssiges Gameplay oder Top Bildqualität. Wenn ich einen Clan-War in einem Shooter hätte, dann nehme ich ein Setting wo der 120hz Monitor immer mit 120 Fps versorgt wird. Wenn ich hingegen einfach im Singleplayer was spielen will, sind auch 60 Fps in Ordnung bzw. sogar noch viel weniger, wenn es das Spiel zulässt.

Was mir manchmal auffällt ist, das je höher die GPU Last wird, desto schlechter das Spielgefühl. Das ist aber nicht bei jedem Spiel so. Die Materie ist mittlerweile so komplex, das kein Mensch mehr durchblickt. Hardware, OS, Treiber, Spiel, Settings ergeben Myriaden von Möglichkeiten wie man testen kann.

pest

2013-03-30, 20:59:19

Ohne Framemetering ist mGPU - wie man sieht - eh nur auf dem selben Level wie sGPU.

Doch so war es schon immer. Jetzt sind wir zum Glück soweit , das dies nicht mehr so einfach durchgeht und nachgewiesen werden kann. Crossfire ist aktuell eine einzige Lüge.

Differenzierung ist keine eurer Stärken oder?

Außerdem wäre es interessant zu wissen, wann sie anfangen Framtimes auszulassen? Und warum lassen sie die Frametimes nicht auch einfach bei den Fraps-Messungen weg?

Ich verstehe den ganzen Aufriss ehrlich gesagt nicht

Godmode

2013-03-30, 21:05:44

Außerdem wäre es interessant zu wissen, wann sie anfangen Framtimes auszulassen? Und warum lassen sie die Frametimes nicht auch einfach bei den Fraps-Messungen weg?

Ich verstehe den ganzen Aufriss ehrlich gesagt nicht

FRAPS misst ja nichts anderes als die Present Calls der Game Engine. Da kann der Treiber überhaupt nichts beeinflussen. Alles was dann nach Present passiert, macht das OS bzw. etwas weiter hinten in der Pipeline, der Grafikktreiber. Warum das beim CF so ist werden wir sicher in den nächsten Wochen erfahren. Ob nun Messfehler oder wirklicher Fehler, es wird ans Tageslicht kommen.

schreiber

2013-03-30, 21:18:06

Blaire

2013-03-30, 21:20:17

Man hat die Wahl. Man kann SLI ausschalten.

Dann wäre viele Titel nicht mehr spielbar. Ohne Kompromisse gehts nicht...sowohl mit, als auch ohne SLI...

Ohne Framemetering ist mGPU - wie man sieht - eh nur auf dem selben Level wie sGPU. Dann kann man auch gleich ganz darauf verzichten, zumal mGPU selbst ja auch immer zusätzliche Latenz bedeutet.

Ich sehe das Crossfire in der Entwicklung stehen geblieben, NV in den letzten Jahren viel mehr Ressourcen in SLI gesteckt, mehr dazu gelernt und verbessert hat. Da muss AMD erstmal hinkommen... SLI ist gewiss nicht perfekt, kann aber doch einen echten Mehrwert liefern, wenn richtig getestet werden würde , nicht immer nur alles an Mikrorucklern *gääähn* festgemacht würde.
Es wird viel Mist verbreitet, viele MultiGPU Tests sind einfach nur schlecht, da sie nur stur alles herunter benchen, das Wichtigste -> die Spielbarkeit aus den Augen verlieren. HardOCP ist da vorbildlich, berichtet schon sehr lange Zeit nach subjektiven Maßstäben, was ist spielbar und was nicht. So stelle ich mir das vor und kein sich dauernd wiederholendes und unsachliches Gelaber von wegen MultiGPU= MR= Unspielbar oder es sei nur etwas für Balken-Freaks, sondern was kann ein potentieller Käufer als Mehrwert erwarten.

Die Ruckler treten ja auch nicht immer auf. Besonders schlimm sind sie ja nur, wenn die GPUs im unteren fps-Bereich laufen.
Und diverse Abhilfe gabs ja auch. Vsync, Framelimiter usw.

FPS-Limiter kann bei einigen Games helfen, aber nicht bei allen Titeln wie die weitläufige Meinung ist. Deshalb ist das gewiss keine Lösung. Auch müssen die CF-Profile erstmal gut genug sein, die Minimumfps entsprechend mitskalieren usw.

boxleitnerb

2013-03-30, 21:22:47

Framemetering gibt es seit G80. Es hat sich sicherlich weiterentwickelt und wurde immer verbessert, aber Nvidia hat nicht erst mit Kepler damit begonnen.

pest

2013-03-30, 21:38:10

Ob nun Messfehler oder wirklicher Fehler, es wird ans Tageslicht kommen.

Es ist schon verwunderlich warum die "Observed-FPS" bei NV exakt denselben wie bei den von Fraps gemessenen aussehen. Was das Frame-pacing jetzt an der generellen Mikroruckler-Problematik ändern soll, ist mir schleierhaft. So erkauft man sich halt stärkeren Lag durch bessere Zahlen...

gnahr

2013-03-30, 21:42:15

So erkauft man sich halt stärkeren Lag durch bessere Zahlen...lag in welcher größenordnung nochmal?
richtig, ein viertel ameisenhäufchen, darauf kann man pfeifen weil permanent nur ein viertel ameisenhäufchen.

Godmode

2013-03-30, 21:54:26

Es ist schon verwunderlich warum die "Observed-FPS" bei NV exakt denselben wie bei den von Fraps gemessenen aussehen. Was das Frame-pacing jetzt an der generellen Mikroruckler-Problematik ändern soll, ist mir schleierhaft. So erkauft man sich halt stärkeren Lag durch bessere Zahlen...

Wenn hinten das selbe rauskommt wie vorne rein, dann ist alles korrekt. Was ist daran verwunderlich?

Wie ich schon mehrmals sagte, aber was immer wieder unterging: Ich denke dass sich das Frame-Pacing im nächsten Frame auf den Render Cycle der Game Engine auswirken kann.

pest

2013-03-30, 22:10:48

lag in welcher größenordnung nochmal?
richtig, ein viertel ameisenhäufchen, darauf kann man pfeifen weil permanent nur ein viertel ameisenhäufchen.

wenn das lag nicht stört, dann stört auch das mikroruckeln nicht.

mir kann ja jmd. mal vernünftig erklären warum frame-pacing jetzt die lösung sein soll

Wenn hinten das selbe rauskommt wie vorne rein, dann ist alles korrekt. Was ist daran verwunderlich?

ne so einfach ist das nicht. warum gibt es dann unterschiede bei AMD? Das liegt dann einzig und allein an deren (Pcper) Framedropping-Methode. Die absoluten Zeitdistanzen bleiben doch die gleichen.

Knuddelbearli

2013-03-30, 22:22:42

mir kann ja jmd. mal vernünftig erklären warum frame-pacing jetzt die lösung sein soll

a.) es ist von NV
b.) AMD hat es nicht

:biggrin:

aufkrawall

2013-03-30, 22:28:06

Wie oft denn noch: Wenn man kurzzeitig unters Limit kommt, ist es mit Frame Pacing (hoffentlich) erträglich, ohne garantiert nicht.

Godmode

2013-03-30, 22:30:16

wenn das lag nicht stört, dann stört auch das mikroruckeln nicht.

mir kann ja jmd. mal vernünftig erklären warum frame-pacing jetzt die lösung sein soll

ne so einfach ist das nicht. warum gibt es dann unterschiede bei AMD? Das liegt dann einzig und allein an deren (Pcper) Framedropping-Methode. Die absoluten Zeitdistanzen bleiben doch die gleichen.

Also wenn du eine Karte langsamer machst, könntest du die Sägezahnkurve etwas glätten:

http://images.anandtech.com/doci/6857/Microstutter.png

Das ginge natürlich auf die Performance, aber die Bildausgabe wäre flüssiger. Es ist keine Lösung aber ein Kompromiss.

@Knuddelbearli: Wenn du sonst nichts beitragen kannst bleibe dem Thread fern. Es ist schon selten genug, dass eine interessante Diskussion nicht sofort in Flames und OT mündet.

pest

2013-03-30, 22:40:42

Wie oft denn noch: Wenn man kurzzeitig unters Limit kommt, ist es mit Frame Pacing (hoffentlich) erträglich, ohne garantiert nicht.

:confused:

Also wenn du eine Karte langsamer machst, könntest du die Sägezahnkurve etwas glätten:

Ja schon klar das ist der Sinn des Ganzen. Aber PCPer tun so als wären diese Sägezahnkurven in jedem Game. Ich habe recht wenige Samples wo das so auftritt.
Außerdem werden die kurzen Frames ja gemessen. Es ist kein Problem, dass z.B. mit Frappo rauszurechnen.

Schaffe89

2013-03-30, 22:40:55

Doch so war es schon immer. Jetzt sind wir zum Glück soweit , das dies nicht mehr so einfach durchgeht und nachgewiesen werden kann. Crossfire ist aktuell eine einzige Lüge.

Wie gut dass jeder weiß, dass du nicht fähig bist überhaupt Ansatzweise zu differenzieren, wenn es um AMD geht.
Crossfire ist sicherlich keine Lüge, ich habe es lange genug genutzt ohne Framelimiter und habe trotzdem ein deutlich besseres Spielerlebnis gehabt als nur mit einer GPU.

Wie oft denn noch: Wenn man kurzzeitig unters Limit kommt, ist es mit Frame Pacing (hoffentlich) erträglich, ohne garantiert nicht.

Erklär das bitte mal etwas genauer, ich versteh das grade nicht.

Godmode

2013-03-30, 22:49:27

:confused:

Ja schon klar das ist der Sinn des Ganzen. Aber PCPer tun so als wären diese Sägezahnkurven in jedem Game. Ich habe recht wenige Samples wo das so auftritt.
Außerdem werden die kurzen Frames ja gemessen. Es ist kein Problem, dass z.B. mit Frappo rauszurechnen.

Die Sägezähne kommen IMO nur bei CF/SLI vor.

Die kurzen Frames sind meistens nur mehr 1-10 Zeilen hoch, daher sagt Ryan die tragen nicht mehr bei eine Animation besser darzustellen, daher zählt er sie nicht.

aufkrawall

2013-03-30, 22:49:57

:confused:

Was ist so seltsam daran?
Wie die letzten hier verlinkten Artikel belegen, ist doch AFR ohne Frame Pacing unterhalb von fps-Limits/Vsync völlig unbrauchbar.

Btw: Gäbe doch eine ganz einfache Lösung:
AFR in die Tonne und stattdessen mGPU-AA verbessern (bessere Sampleverteilung, erzwingbar bei DX11).
Keine Mikroruckler, kein Lag, die Mehrleistung lässt sich in bessere BQ investieren.

Blaire

2013-03-30, 22:58:10

Wie gut dass jeder weiß, dass du nicht fähig bist überhaupt Ansatzweise zu differenzieren, wenn es um AMD geht.

Was willst du? Lüg dir mal schön weiter die Taschen voll...

Crossfire ist sicherlich keine Lüge, ich habe es lange genug genutzt ohne Framelimiter und habe trotzdem ein deutlich besseres Spielerlebnis gehabt als nur mit einer GPU.

You made my Day... ;D

pest

2013-03-30, 23:02:04

Was ist so seltsam daran?
Wie die letzten hier verlinkten Artikel belegen, ist doch AFR ohne Frame Pacing unterhalb von fps-Limits/Vsync völlig unbrauchbar.

Drück' dich doch bitte verständlich(er) aus. Was ist "unterm Limit". Und nein die letzten hier verlinkten Artikel belegen nicht, dass AFR irgendwie total unbrauchbar ist. Es gibt Problemfälle, aber das ist nichts Neues. Spiel mal Crysis3 auf 3xTitan.

Die Sägezähne kommen IMO nur bei CF/SLI vor.

Ich meinte natürlich meine CF/SLI Samples. Ich habe da ein recht durchwachsenes Bild. Die Ergebnisse von PCPer implizieren es gibt kein Mikroruckeln auf SLI.

Die kurzen Frames sind meistens nur mehr 1-10 Zeilen hoch, daher sagt Ryan die tragen nicht mehr bei eine Animation besser darzustellen, daher zählt er sie nicht.

ja, das verstehe ich. aber warum macht er das bei den Fraps-Sachen nicht auch?

Godmode

2013-03-30, 23:09:15

Ich meinte natürlich meine CF/SLI Samples. Ich habe da ein recht durchwachsenes Bild. Die Ergebnisse von PCPer implizieren es gibt kein Mikroruckeln auf SLI.

ja, das verstehe ich. aber warum macht er das bei den Fraps-Sachen nicht auch?

Also ich sehe in dem Artikel von PCPer ganz klar bei SLI mehr Stuttering als ohne: http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-GeForce-GTX-Titan-GeForce-GTX-690-Radeon-HD-7990-HD-7970-Cross-0

Du meinst warum filtert er bei Fraps die 0ms Frames nicht weg oder was genau?

aufkrawall

2013-03-30, 23:12:57

Drück' dich doch bitte verständlich(er) aus. Was ist "unterm Limit".

Ein manuell gesetztes natürlich (fps-Limiter/Vsync), was denn sonst?

Und nein die letzten hier verlinkten Artikel belegen nicht, dass AFR irgendwie total unbrauchbar ist.

Genau lesen: Ich sagte AFR ohne Frame Pacing.

Es gibt Problemfälle, aber das ist nichts Neues. Spiel mal Crysis3 auf 3xTitan.

Das wird mit Sicherheit besser laufen als die allermeisten Spiele mit 2-Way Crossfire.

pest

2013-03-30, 23:15:38

Also ich sehe in dem Artikel von PCPer ganz klar bei SLI mehr Stuttering als ohne: http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-GeForce-GTX-Titan-GeForce-GTX-690-Radeon-HD-7990-HD-7970-Cross-0

Du hast Recht. Ich bezog mich jetzt auf den FPS-Graphen, der bei FRAPS/Observed bei NV ja exakt der Selbe ist. Wenn Crossfire so viel schlechter wäre (was bei PCPer auch nur Crysis3 und BF3 sind) würden das ja auch die Fraps Werte zeigen. Und da habe ich eben ein anderes Bild.

Also ich verstehe den ganzen Aufwand immernoch nicht :redface:

Du meinst warum filtert er bei Fraps die 0ms Frames nicht weg oder was genau?

jep

Das wird mit Sicherheit besser laufen als die allermeisten Spiele mit 2-Way Crossfire.

erzähl keine Quatsch

1-GPU: Avg: 18,64 fps, VarK: 15,12%, I-VarK: 7,76%, 90% der Zeit [13,50 fps; 22,61 fps]
2-GPU: Avg: 27,37 fps, VarK: 22,97%, I-VarK: 29,02%, 90% der Zeit [17,53 fps; 33,66 fps]
3-GPU: Avg: 40,84 fps, VarK: 29,74%, I-VarK: 40,09%, 90% der Zeit [21,91 fps; 52,98 fps]
4-GPU: Avg: 50,99 fps, VarK: 45,33%, I-VarK: 55,03%, 90% der Zeit [19,64 fps; 97,25 fps]

aufkrawall

2013-03-30, 23:19:18

erzähl keine Quatsch
Ah ja, du hast sicherlich Crossfire ausgieber getestet als PCPer, ich vergaß...

Edit: Von wann sind die Werte?
Abgesehen davon sind die nur gefrapst.

TRob

2013-03-30, 23:19:42

Wie sieht das wohl mit 120 Hz aus?

Ob die Probleme da noch schlimmer sind oder vielleicht alles besser ist....

Zu dumm, dass es keine Capture-Karten mit 120 Hz gibt ;)

Genau lesen: Ich sagte AFR ohne Frame Pacing.

ich hab mich schon immer gefragt wieso alles auf AFR setzt.
Ich kann mich noch erinnern, dass in den Anfängen gesagt wurde, dass AFR aufgrund der Latenzen usw. für Gaming ungeeignet sei xD

pest

2013-03-30, 23:24:16

Ah ja, du hast sicherlich Crossfire ausgieber getestet als PCPer, ich vergaß...

ich habe zumindest Werte von verschiedenen Gesamtsystemen.

Abgesehen davon sind die nur gefrapst.

So und jetzt erzähl mir nochmal klar und in verständlichen Worten warum die Frametimes durchs Capturen anders werden sollten.

aufkrawall

2013-03-30, 23:26:00

ich hab mich schon immer gefragt wieso alles auf AFR setzt.
Ich kann mich noch erinnern, dass in den Anfängen gesagt wurde, dass AFR aufgrund der Latenzen usw. für Gaming ungeeignet sei xD
Die Latenzen lassen sich softwareseitig verringern, Nvidia arbeitet (hoffentlich) an einem intelligenteren Vsync für AFR.
Skalierung ist halt etwas schlechter, dafür gibts dann auch überhaupt keine Mikroruckler mehr.

Godmode

2013-03-30, 23:26:04

Mit 120hz wird es nach meiner subjektiven Meinung besser, es löst aber das Problem nicht.

@Pest: Die Erklärung finde ich gut und verständlich:

AnandTech: (http://www.anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps/4) "So to use FRAPS in this method as a way of measuring frame intervals is problematic. Considering in particular that the application can only pass off a new frame when the context queue is ready for it, what FRAPS is actually measuring is the very start of the rendering pipeline, which not unlike a true pipe is limited by what comes after it. If the pipeline is backed up for whatever reason (context queue, drivers, etc), then FRAPS is essentially reporting on what the pipeline is doing, and not the frame interval on the final displayed frames. Simply put, FRAPS cannot tell you the frame interval at the end of the pipeline, it can only infer it from what it’s seeing."

Und hier nochmal für alle Streithähne:
AnandTech: (http://www.anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps/4)"But in the meantime what we will tell you is the same thing AMD and NVIDIA will tell you: FRAPS is not the best way to measure frame intervals. There is a better way."

TRob

2013-03-30, 23:31:13

Die Latenzen lassen sich softwareseitig verringern, Nvidia arbeitet (hoffentlich) an einem intelligenteren Vsync für AFR.
Skalierung ist halt etwas schlechter, dafür gibts dann auch überhaupt keine Mikroruckler mehr.

Für mich wäre dennoch SFR mit Load-Balance eine bessere Option. Wenn sich mehrere GPUs die Berechnung des gleichen Bilds teilen, dass dann fertig auf die reise geschickt wird, dürfte das vieles einfacher machen.

gnahr

2013-03-30, 23:32:32

wenn das lag nicht stört, dann stört auch das mikroruckeln nicht.
nein. das eine ist ein konstanter versatz und das andere ein hin und herspringen. du siehst viel eher ne änderung als dir 2ms konstanter versatz auffallen. probier das mal mit bildern samt asyncronen ton. eine laufzeit ist i.o., aber wenn die silbe mal vor, mal wärend und mal nach der lippenbewegung startet... :mad:

TRob

2013-03-30, 23:35:05

Mit 120hz wird es nach meiner subjektiven Meinung besser, es löst aber das Problem nicht.

Jo, es wird zeit das endlich einer Monitore und entsprechende Anschlüsse baut, die nicht mehr nach dem "analogen" Prinzip Hz/Scanlines usw. funktionieren, sondern die Bilder direkt ausgeben, wenn sie von der VGA Karte berechnet wurden.

Dann dürfte man doch die meisten Probleme los sein.

aufkrawall

2013-03-30, 23:39:08

Dann dürfte man doch die meisten Probleme los sein.
Na ja, dann würde es doch auch nicht gleichmäßig flüssig laufen, wobei der Input Lag auch immer noch schwankt.
Einen Film zu schauen, bei dem die fps ständig schwanken (mal hypothetisch ohne Judder & Tearing), stelle ich mir jedenfalls ziemlich unangenehm vor.

pest

2013-03-30, 23:47:18

@Pest: Die Erklärung finde ich gut und verständlich:

Das habe ich mir schon ein paar mal durchgelesen. Ich habe auch keine Ahnung von Grafikhw, deswegen auch meine Fragen.

-Warum gibt es dann bei PCPer keinen Unterschied zwischen Fraps/Observed bei NV? Ich meine damit würde die Latenz ja absolut konstant sein.

The amount of time between present calls is not the amount of time it took a frame to move through the pipeline, especially if the next Present call was delayed for any reason.

Wieso ist das so? Irgendwas verstehe ich da nicht richtig.

Wir haben: T_present1 (lag1) T_display1 ... T_present2 (lag2) T_display2

Ist das kein serieller Prozess? Kann sich da was überlappen. Warum sollte lag1!=lag2 sein?

Godmode

2013-03-31, 00:10:20

Das habe ich mir schon ein paar mal durchgelesen. Ich habe auch keine Ahnung von Grafikhw, deswegen auch meine Fragen.

-Warum gibt es dann bei PCPer keinen Unterschied zwischen Fraps/Observed bei NV? Ich meine damit würde die Latenz ja absolut konstant sein.

Beziehst du dich auf diesen Chart:
http://www.pcper.com/image/view/21763?return=node%2F56832

Dann ist die Erklärung, dass es bei Nvidia keine Dropped oder Runt Frames gibt.

Wieso ist das so? Irgendwas verstehe ich da nicht richtig.

Wir haben: T_present1 (lag1) T_display1 ... T_present2 (lag2) T_display2

Ist das kein serieller Prozess? Kann sich da was überlappen. Warum sollte lag1!=lag2 sein?

Es ist ein serieller Prozess, und da Windows kein Echtzeit Betriebssystem ist, kann zwischen T_present und T_display viel passieren. Und ja lag1 und lag2 können unterschiedlich groß sein.

Im Artikel von AnandTech (http://www.anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps) wird teilweise darauf eingegangen. Bitte im Detail lesen, sehr guter Artikel, auch für alle anderen. Nemt euch die Zeit, und lest das, sonst bringt es überhaupt nichts hier weiter mitzureden. Wenn ihr es nicht versteht, dann lest ihr nochmal und nochmal, bis ihr es kapiert habt.

Und diese Stelle möchte ich auch nocheinmal hervorheben:

AnandTech: (http://www.anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps/7)
"Ultimately AMD’s message has been one of information, explanation, and admission of oversight. AMD has been clear with us from the start that the primary reason they even ended up in this situation is because they weren’t doing sufficient competitive analysis, and that they have revised their driver development process so that they now do this analysis to prevent future problems. The fact that NVIDIA seemed to have figured all of this out much earlier was a point of frustration for AMD. The company likely left non-negligable amounts of performance on the table over the years, which could've definitely helped in close races."

Also auf Deutsch: AMD war sich bisher nicht bewusst und es wurden daher auch keine Analysen bzgl Frametiming gemacht. AMD ist etwas frustriert darüber, das sie nicht selber darauf gekommen sind, weil sie dadurch auch Performance liegen gelassen haben.

@OT Spamer: Jeder Beitrag wird ab jetzt gemeldet.

Butterfly

2013-03-31, 00:14:04

Ich sehe das Crossfire in der Entwicklung stehen geblieben, NV in den letzten Jahren viel mehr Ressourcen in SLI gesteckt, mehr dazu gelernt und verbessert hat. Da muss AMD erstmal hinkommen... SLI ist gewiss nicht perfekt, kann aber doch einen echten Mehrwert liefern, wenn richtig getestet werden würde , nicht immer nur alles an Mikrorucklern *gääähn* festgemacht würde.
Es wird viel Mist verbreitet, viele MultiGPU Tests sind einfach nur schlecht, da sie nur stur alles herunter benchen, das Wichtigste -> die Spielbarkeit aus den Augen verlieren. HardOCP ist da vorbildlich, berichtet schon sehr lange Zeit nach subjektiven Maßstäben, was ist spielbar und was nicht. So stelle ich mir das vor und kein sich dauernd wiederholendes und unsachliches Gelaber von wegen MultiGPU= MR= Unspielbar oder es sei nur etwas für Balken-Freaks, sondern was kann ein potentieller Käufer als Mehrwert erwarten.

Ich sehe das SLI in der Entwicklung stehen geblieben ist, es gibt keine Bemühungen den idle Verbrauch zu senken und somit auch die Lärmbelästigung wenn man mal nur Surfen möchten.
Zudem "erlaubt" nvidia SLI nur mit Baugleichen Karten bei AMD kann man die ganze Modell Reihe koppeln.
Die Bildqualität hat auch ein wenig nachgelassen wenn man da nicht mit 2 Titan ankommt wirkt es doch sehr verwaschen, von wegen Blink Blink....:cool:

Da wir aber gerade Ostern haben will ich mal nicht so sein, hat jeder mal ein schlechten Abend, meiner war jedenfalls klasse! ;)

Rente

2013-03-31, 00:19:03

Ich sehe das SLI in der Entwicklung stehen geblieben ist, es gibt keine Bemühungen den idle Verbrauch zu senken und somit auch die Lärmbelästigung wenn man mal nur Surfen möchten.
Zudem "erlaubt" nvidia SLI nur mit Baugleichen Karten bei AMD kann man die ganze Modell Reihe koppeln.
Die Bildqualität hat auch ein wenig nachgelassen wenn man da nicht mit 2 Titan ankommt wirkt es doch sehr verwaschen, von wegen Blink Blink....:cool:

Da wir aber gerade Ostern haben will ich mal nicht so sein, hat jeder mal ein schlechten Abend, meiner war jedenfalls klasse! ;)
SLI nur mit baugleichen Karten ist eigentlich sogar ein Vorteil, unterschiedliche Karten dürften umso mehr zu Problemen mit Mikrorucklern führen.

Bildqualität nachgelassen? Srysly? Damit hast du dich dann schon ins Aus manövriert...
Und wo soll es ein Lautstärke-Problem mit SLi im Idle geben? Am Stromverbrauch könnten sie in der Tat noch arbeiten, aber laut ist Titan nun wirklich nicht beim Surfen...

Wenn du schon jemanden bzw. nVidia "bashen" willst, dann bitte mit belegten Fakten und nicht mit Nebelkerzen.
€: Davon mal abgesehen passt das auch überhaupt nicht in diesen Thread, sorry für OT meinerseits...

Marty98

2013-03-31, 00:42:55

Was man halt nicht messen kann ist der Input-Lag, mit dem sich Nv das Frame-Metering mit SLI erkauft. AMD wird mit zukünftigen Treibern eine ähnliche Lösung optional anbieten.

Die Option gibt es jetzt schon! Einfach eine 7970 raus aus dem PC, und schon hat man die gleichen reellen Framerates wie mit zwei, und der Lag hält sich in Grenzen!

Hm, wie lange hat es gedauert bis die Multi-GPU-µRuckler überhaupt entdeckt wurden? Seit wann geht NV aktiv dagegen vor? Jetzt auf einmal ist Multi-GPU nutzlos oder eine einzige Lüge wenn man dieses Frame-Metering nicht hat. Dieselben Leute haben freilich vor Jahren ihr Multi-GPU-System trotz dieser Ruckler verteidigt. :)

Ja, das ist die Definition von Religion!

pest

2013-03-31, 06:53:14

Beziehst du dich auf diesen Chart:
http://www.pcper.com/image/view/21763?return=node%2F56832

Dann ist die Erklärung, dass es bei Nvidia keine Dropped oder Runt Frames gibt.

nein ich meine diese beiden, warum gibt es bei NV keinen minimalen Unterschied?

http://www.pcper.com/image/view/21648?return=node%2F56832

http://www.pcper.com/image/view/21649?return=node%2F56832

Und ja lag1 und lag2 können unterschiedlich groß sein.

die frage ist, wann das außer bei frame-pacing noch regelmäßig passieren sollte.

fondness

2013-03-31, 08:47:01

FPS-Limiter kann bei einigen Games helfen, aber nicht bei allen Titeln wie die weitläufige Meinung ist. Deshalb ist das gewiss keine Lösung.

"Weitläufige Meinung" = Deine Meinung um CF zu denunzieren? :)
Ein FPS-Limiter hilft garantiert immer, denn er ist faktisch Frame-Metering XXL. Er sorgt dafür das die Frames in konstanten Abständen ausgegeben werden, sofern eine Karte zu schnell ist wird sie ausgebremst. Die einzige Voraussetzung sind genügend fps um nicht unter den Limiter zu kommen.

Auch müssen die CF-Profile erstmal gut genug sein, die Minimumfps entsprechend mitskalieren usw.

Willst du behaupten das die CF-Profile schlechter skalieren oder die Min-fps nicht mit skalieren? Also es gibt genügend Tests die was anderes zeigen, nämlich das die Skalierung bei AMD längst kein Problem mehr ist.

OC_Burner

2013-03-31, 12:10:13

Wie sieht das wohl mit 120 Hz aus?

Ob die Probleme da noch schlimmer sind oder vielleicht alles besser ist....

Zu dumm, dass es keine Capture-Karten mit 120 Hz gibt ;)

ich hab mich schon immer gefragt wieso alles auf AFR setzt.
Ich kann mich noch erinnern, dass in den Anfängen gesagt wurde, dass AFR aufgrund der Latenzen usw. für Gaming ungeeignet sei xD

Ich bin mir zu 100% sicher das die DualLink-Capturekarte bei PCPer auch 120hz Capturen kann. Meine ist zwar die SingleLink-Version aber auch diese schafft 120hz, wenn auch bei reduzierter Auflösung (max. 1402x792).

Godmode

2013-03-31, 13:21:13

nein ich meine diese beiden, warum gibt es bei NV keinen minimalen Unterschied?

http://www.pcper.com/image/view/21648?return=node%2F56832

http://www.pcper.com/image/view/21649?return=node%2F56832

die frage ist, wann das außer bei frame-pacing noch regelmäßig passieren sollte.

Er rechnet bei den Observed FPS die Runt und Dropped Frames raus. Bei SLI gibt es keine Runt oder Dropped Frames, daher sieht man auch keinen Unterschied zwischen Fraps und Observed. Wenn du dir eine Single 7970 ansiehst, gibt es dort das Problem nicht. Es ist ein CF Problem, das aber spätestens im Juli gelöst sein sollte.

http://www.pcper.com/files/imagecache/article_max_width/review/2013-03-25/BF3_1920x1080_FRAPSFPS.png

http://www.pcper.com/files/imagecache/article_max_width/review/2013-03-25/BF3_1920x1080_OFPS.png

die frage ist, wann das außer bei frame-pacing noch regelmäßig passieren sollte.

IMO kann das nur am GPU-Treiber liegen, weil sonst haben AMD und NV ja die selben Ausgangsbedingungen.

Godmode

2013-03-31, 13:26:39

Ein FPS-Limiter hilft garantiert immer, denn er ist faktisch Frame-Metering XXL. Er sorgt dafür das die Frames in konstanten Abständen ausgegeben werden, sofern eine Karte zu schnell ist wird sie ausgebremst. Die einzige Voraussetzung sind genügend fps um nicht unter den Limiter zu kommen.

Wenn ich mir den Unterschied zwischen minimaler und maximaler Framerate in aktuellen Spielen ansehe, würde ich mich wirklich schwer tun den richtigen Wert für den Limiter zu finden. Ich kann ihn sehr tief setzen, verzichte dann aber auf die Mehrleistung von CF/SLI. Wenn ich ihn zu hoch ansetze, hilft er wieder nicht gegen das Stuttering. Ein Beispiel ist das aktuelle TombRaider, dort sehe ich Schwankkungen von 30-200 FPS. Auf welchen Wert setze ich in diesem konkreten Beispiel den Limiter?

Es wäre interessant zu probieren, was passiert, wenn man den GPUs nur 90% Last erlauben würde. Ich hätte dann nämlich einen Limiter der dynamisch agiert und nicht auf einen bestimmten Wert fest getackert ist. Meine persönlichen Erfahrungen zeigen, dass je näher ich an die 100% Lastgrenze der GPU gehe, das Stuttering schlimmer wird.

pest

2013-03-31, 13:31:50

Er rechnet bei den Observed FPS die Runt und Dropped Frames raus. Bei SLI gibt es keine Runt oder Dropped Frames, daher sieht man auch keinen Unterschied zwischen Fraps und Observed. Wenn du dir eine Single 7970 ansiehst, gibt es dort das Problem nicht. Es ist ein CF Problem, das aber spätestens im Juli gelöst sein sollte.

http://www.pcper.com/files/imagecache/article_max_width/review/2013-03-25/BF3_1920x1080_FRAPSFPS.png

http://www.pcper.com/files/imagecache/article_max_width/review/2013-03-25/BF3_1920x1080_OFPS.png

IMO kann das nur am GPU-Treiber liegen, weil sonst haben AMD und NV ja die selben Ausgangsbedingungen.

Ok, nochmal langsam, ich glaube du verstehst mein Problem nicht

- Du sagst, entgegen der Annahme von Fraps, dass lag1!=lag2 sein kann.
Sehe ich ein. Dann ist aber T_display2-T_display1 anders als T_present2-T_present1 - DAS Argument warum wir Fraps in die Tonne kloppen sollen.

- Jetzt sieht man aber auf den Graphen keinen Unterschied, wenn man alle Frames drinlässt (also lag1=lag2)?! Was soll das Ganze dann?! Wo sind die Auswirkungen von Frame-pacing?
Die zu schnellen Frames kann man auch so rausrechnen.

boxleitnerb

2013-03-31, 13:35:10

Wenn ich mir den Unterschied zwischen minimaler und maximaler Framerate in aktuellen Spielen ansehe, würde ich mich wirklich schwer tun den richtigen Wert für den Limiter zu finden. Ich kann ihn sehr tief setzen, verzichte dann aber auf die Mehrleistung von CF/SLI. Wenn ich ihn zu hoch ansetze, hilft er wieder nicht gegen das Stuttering. Ein Beispiel ist das aktuelle TombRaider, dort sehe ich Schwankkungen von 30-200 FPS. Auf welchen Wert setze ich in diesem konkreten Beispiel den Limiter?

Es wäre interessant zu probieren, was passiert, wenn man den GPUs nur 90% Last erlauben würde. Ich hätte dann nämlich einen Limiter der dynamisch agiert und nicht auf einen bestimmten Wert fest getackert ist. Meine persönlichen Erfahrungen zeigen, dass je näher ich an die 100% Lastgrenze der GPU gehe, das Stuttering schlimmer wird.

Exakt das ist das Problem. Ich dachte ursprünglich auch, ein Limiter wäre toll. Kann er unter gewissen Umständen auch sein (wenn man eh VSync benutzt und/oder die Framerate nicht so sehr schwankt). Aber er ist keine allgemeine Lösung und sicherlich keine Ausrede für die CF-Probleme.

Godmode

2013-03-31, 14:47:18

Ok, nochmal langsam, ich glaube du verstehst mein Problem nicht

- Du sagst, entgegen der Annahme von Fraps, dass lag1!=lag2 sein kann.
Sehe ich ein. Dann ist aber T_display2-T_display1 anders als T_present2-T_present1 - DAS Argument warum wir Fraps in die Tonne kloppen sollen.

Ja T_display2-T_display1 kann natürlich anders als T_present2-T_present1 sein.

- Jetzt sieht man aber auf den Graphen keinen Unterschied, wenn man alle Frames drinlässt (also lag1=lag2)?! Was soll das Ganze dann?! Wo sind die Auswirkungen von Frame-pacing?
Die zu schnellen Frames kann man auch so rausrechnen.

Einen super Beitrag was ein Frame-pacing wirklich bewirken kann, habe ich gerade gefunden:
http://forum.beyond3d.com/showpost.php?p=1723309&postcount=222

So ähnlich hab ich mir das schon gedacht, aber bisher nicht so schön in Worte und Bilder fassen können.

dargo

2013-03-31, 14:54:17

aufkrawall

2013-03-31, 14:55:53

Mal eine Frage am Rande. Wäre es möglich einen variablen Framelimiter zu entwickeln?
Gibts doch schon bei Nvidia: Adaptives Vsync + AFR-Flag.

dargo

2013-03-31, 14:58:12

Gibts doch schon bei Nvidia: Adaptives Vsync + AFR-Flag.
Und das funktioniert lagfrei und problemlos in jedem Spiel?

aufkrawall

2013-03-31, 15:00:57

Und das funktioniert lagfrei und problemlos in jedem Spiel?
Eigentlich schon.
Bei etwa Crysis 1 DX9 und Crysis 3 DX11 funzt es wohl schon perfekt.

dargo

2013-03-31, 15:03:42

Na dann müsste sowas für alle GPUs kommen. :)

Godmode

2013-03-31, 15:05:22

Und das funktioniert lagfrei und problemlos in jedem Spiel?

Momentan gibt es da Feature nur für mGPU, es wird aber überlegt das auch für sGPU zu bringen.

dildo4u

2013-03-31, 15:11:08

PCGH zieht wohl nach

Wir arbeiten derzeit am Aufbau eines entsprechenden Systems sowie der entsprechenden Darstellung der erzeugten Daten und würden uns für Ihre Meinung zu dieser Art von Messung interessieren? Gute Ergänzung zu herkömmlichen Methoden? Das einzig Wahre? Oder zu kompliziert für den Hausgebrauch?

http://www.pcgameshardware.de/Grafikkarten-Hardware-97980/Tests/Nvidia-FCAT-1062701/

Godmode

2013-03-31, 15:34:40

Ich finde das eine gute Sache, auch wenn es aufwendig ist. Wir wollen schließlich wissen ob etwas flüssig läuft und nicht wer den längsten hat.

Man könnte das ganze noch steigern, indem man die ausgespuckten Bilder mittels optischen Fluss analysiert.

pest

2013-03-31, 16:52:24

Einen super Beitrag was ein Frame-pacing wirklich bewirken kann, habe ich gerade gefunden:
http://forum.beyond3d.com/showpost.php?p=1723309&postcount=222

So ähnlich hab ich mir das schon gedacht, aber bisher nicht so schön in Worte und Bilder fassen können.

ok, danke, dann scheint der einfluss doch geringer zu sein und imo müssten sich dann auch die t_present zeiten verschieben

Match-Maker

2013-03-31, 17:05:29

Marty98

2013-03-31, 17:28:38

Einen super Beitrag was ein Frame-pacing wirklich bewirken kann, habe ich gerade gefunden:
http://forum.beyond3d.com/showpost.php?p=1723309&postcount=222

So ähnlich hab ich mir das schon gedacht, aber bisher nicht so schön in Worte und Bilder fassen können.

Stimmt, ein Bild sagt mehr als 1000 Worte!

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

Godmode

2013-03-31, 17:32:00

Tach.
Erstmal muss ich sagen, dass es natürlich gut ist, dass sich bei diesem Thema endlich mal was tut.
Nun habe ich allerdings zwei Fragen:
1. Warum verwendet man bei Multi-GPU eigentlich kein SFR? Das hätte doch mehrere Vorteile. Zum einen hätte man keine Mikro-Ruckler mehr und auch der Inputlag wäre geringer las mit AFR. Zudem hätte man dann mehr nutzbaren VRAM.
2. Was hat es mit diesem Multi-GPU-AA auf sich? Wann kann man das nutzen?

1. SFR ist mit den heutigen Engines nicht mehr praktikabel. Da es viele Fullscene-Effekte gibt, müsste du du ständig viel Information von GPU1 zu GPU oder umgekehrt schicken. Da diese Anbindungen aber viel zu schmal sind, skaliert SFR sehr schlecht. Wenn mehere GPUs auf einer Platine mittels Interposer verbunden werden, könnte SFR eine Wiederauferstehung erleben.

2. SLI-AA könnte eine Lösung sein, aber damit hab ich mich noch nicht wirklich auseinander gesetzt. Bin mir gar nicht sicher ob das bei DX11 überhaupt noch funktioniert. Gouvernator hat damit eine Zeit lang rumgespielt und es für gut befunden.

aufkrawall

2013-03-31, 17:38:57

2. SLI-AA könnte eine Lösung sein, aber damit hab ich mich noch nicht wirklich auseinander gesetzt. Bin mir gar nicht sicher ob das bei DX11 überhaupt noch funktioniert. Gouvernator hat damit eine Zeit lang rumgespielt und es für gut befunden.
Natürlich funktioniert das auch mit DX11, kannst etwa in BF3 von 4 auf 8 Samples aufwerten. Hatte ich btw. wieder ausgegraben. ;)
Nur ist die Sample-Verteilung Mist.

Match-Maker

2013-03-31, 17:47:30

Aber für (sehr) alte Spiele wäre das doch was, da diese ja Post-Processing nicht oder nur sehr sparsam verwenden. Kann man es denn dafür über den Treiber aktivieren?
Und SLI-AA oder Crossfire-AA (gibts nämlich auch, wie ich gerade gesehen habe!) scheint ja dann auch nicht so das Wahre zu sein.

Godmode

2013-03-31, 17:49:59

aufkrawall

2013-03-31, 17:50:41

Und SLI-AA oder Crossfire-AA (gibts nämlich auch, wie ich gerade gesehen habe!) scheint ja dann auch nicht so das Wahre zu sein.
Wobei sich die Nachteile vielleicht auch in Software lösen ließen, immerhin sind die Modi schon ziemlich alt. Oder spräche technisch etwas dagegen, bessere Samplepositionen zu verwenden?
AA erzwingbar über den Treiber bei DX11 sollte auch gehen, wenn Nvidia wollte.

Gouvernator

2013-03-31, 17:53:02

Match-Maker

2013-03-31, 18:06:50

Für sehr alte Spiele brauche ich aber kein SLI, das läuft auch mit 4x4 SS gut und auf einer Karte.
Stimmt eigentlich. Aber was wäre, wenn man 128xSSAA (4xOGSSAA + 8xMSAA --> 8xSGSSAA + 2x2 Downsampling) mit 120 fps und (falls möglich) auf drei Monitoren in 3D zocken möchte? :freak: Dann könnte es doch von Vorteil sein. :biggrin:

aufkrawall

2013-03-31, 18:08:24

Für alten Kram ist AFR bei 32xSSAA (das ja über den Nvidia-Treiber geht) durchaus nützlich.

Blaire

2013-03-31, 18:15:36

Exakt das ist das Problem. Ich dachte ursprünglich auch, ein Limiter wäre toll. Kann er unter gewissen Umständen auch sein (wenn man eh VSync benutzt und/oder die Framerate nicht so sehr schwankt). Aber er ist keine allgemeine Lösung und sicherlich keine Ausrede für die CF-Probleme.

So ist es. Die Trägheit bekommt man mit FPS-Limiter auch nicht heraus, das kapieren einige Leute aber nicht. Letzter Strohhalm usw.

Angiesan

2013-03-31, 18:30:02

SFR lässt sich doch per Inspector nach wie vor forcen, nur ist es halt kein Unterschied zu einer einzelnen Karte im Spiel, mann sieht aber das beide GPU´s arbeiten ;-)

Ich habe mal eine Bitte an die MGPU User mit NV HW 600er oder Titan, Fermi geht nicht.

Wenn nicht eh installiert bitte die letzte Beta des AB installieren und unter allgemeine Einstellungen- Restore settings after suspendet mode- einen Hacken setzen wenn nicht schon passiert. Nun mit den Standard-Taktraten ein Profil erstellen und dies mit einem Hotkey verknüpfen.
Dann im Inspector im globalen Profil Vertical Sync Smooth AFR behavior auf on und ebenso Adaptiv auf on setzen, Vertical Sync aber bitte auf use the 3D application setting lassen.

Nun mal ein Spiel starten ohne Vsync in game und die GPU`s munter boosten lassen, FPS ablesen.
Nun in Game den Hotkey für das Standard-Profil betätigen, die GPU´s werden nun synchronisiert und arbeiten nur mit dem Mindesttakt, also z.B. bei mir mit 915 MHz bei Usern mit Titan SLi müssten es dann nur die 837 MHz sein, nun bitte noch mal die FPS ablesen. Es sollte eine Veränderung feststellbar sein die überrascht. Vielleicht hat ja jemand Lust das mal gegen zu testen.
Ach und wenn es funktioniert, bitte mal ein wenig rumlaufen und darauf achten ob es eine Veränderung gibt die man spüren kann bezüglich Spielgefühl.

Vielen dank und Grüße.

samm

2013-03-31, 22:03:07

Gibts doch schon bei Nvidia: Adaptives Vsync + AFR-Flag.Könntest du einem nicht-nVidia-Nutzer noch erklären, was genau das bewirkt (dargo hat etwas von einem "variablen framelimiter" geschrieben), und weshalb das gut ist? :)

aufkrawall

2013-03-31, 22:20:25

Könntest du einem nicht-nVidia-Nutzer noch erklären, was genau das bewirkt (dargo hat etwas von einem "variablen framelimiter" geschrieben), und weshalb das gut ist? :)
Ich weiß nicht wie es technisch funktioniert. Man kann bei der Nutzung von Vsync & AFR im Nvidia-Treiber per Inspector eine neue Art von Vsync aktivieren.
-fps werden mit Refreshrate gesynct
-Input Lag ist geringer
-kein AFR-Mikroruckeln mehr (auch nicht unerhalb der Refreshrate, "dynamischer fps-Limiter")
-kostet im derzeitigen Zustand ~15%fps (auch im Refreshratelimit)
-geht derzeit nur mit adaptivem Vsync richtig, sonst gibts ein Double Buffer-Phänomen

Funzt bei BF3 übrigens ganz hervorragend. Ich kann das via Blindtests von adaptivem Vsync mit Single-GPU unterscheiden, und zwar zum Vorteil von AFR. :D
Ja, jetzt kommen sie gleich wieder angeunkt, das wäre nicht möglich und bla...
Momentan ist eine meiner Karten defekt, hab also nur sGPU. Macht definitiv weniger Spaß.

Blaire

2013-03-31, 22:52:34

-geht derzeit nur mit adaptivem Vsync richtig, sonst gibts ein Double Buffer-Phänomen

Wobei jenes Verhalten 2-Way SLI+ Vsync Smooth genau so gewünscht war, wenn ich das richtig verstanden hatte. Bei 3-Way aufwärts scheint dann TripleBuffer aktiv zu sein, so wie man das eigentlich von SLI her kennt. Leider darf ich nicht weiter ins Detail gehn...

Marty98

2013-03-31, 23:23:38

Ich weiß nicht wie es technisch funktioniert. Man kann bei der Nutzung von Vsync & AFR im Nvidia-Treiber per Inspector eine neue Art von Vsync aktivieren.

Kannst du bitte sagen wie die Einstellung genau heisst.

OC_Burner

2013-03-31, 23:27:33

Hier mal ein paar Direktvergleiche zwischen FCAT, FRAPS, GTXTitan und einer GTX690. Auffallend vor allem das die Frameverteilung mit der FCAT-Methode deutlich gleichmäßiger ist, was wohl daran liegen sollte das hier im µs Bereich gemessen wird. Was mich aber stutzig macht sind die einzelnen und extremen FPS Ausreißer im SLI bei der GTX690. Diese sieht man nicht unbedingt in den Bildern, sondern nur in den generierten Exceldateien von FCAT. Da kann ja gerne mal jemand einen Blick drauf werfen. Vsync war währenddessen immer aus.

http://www.oc-burner.de/ftp/3D-Center/1.FCAT+FRAPS_Vergleich(Vsync-off)/Pics/nebeneinander/S.T.A.L.K.E.R%20Call%20of%20Pripyat%20Benchmark%20-%20max%20settings%20-%20defaultSLI-bits_GTX690_FCAT+FRAPS.png

http://www.oc-burner.de/ftp/3D-Center/1.FCAT+FRAPS_Vergleich(Vsync-off)/Pics/nebeneinander/Heaven%20Benchmark%204.0%20-%20Scene%202-4%20-%20max%20settings%20-%20defaultSLI-bits_GTX690_FCAT+FRAPS.png

http://www.oc-burner.de/ftp/3D-Center/1.FCAT+FRAPS_Vergleich(Vsync-off)/Pics/nebeneinander/Need%20for%20Speed%20Most%20Wanted%20-%20max%20settings%20-%202xSSAA%20-%20defaultSLI-bits_GTX690_FCAT+FRAPS.png

http://www.oc-burner.de/ftp/3D-Center/1.FCAT+FRAPS_Vergleich(Vsync-off)/Pics/nebeneinander/The%20Witcher%202%20-%20max%20settings%20-%20defaultSLI-bits%20(gpu%20usage%2050%25)_GTX690_FCAT+FRAPS.png

http://www.oc-burner.de/ftp/3D-Center/1.FCAT+FRAPS_Vergleich(Vsync-off)/Pics/nebeneinander/The%20Witcher%202%20-%20max%20settings%20-%20userSLI-bits%20(0x02C04205)%20(gpu%20usage%2095%25)_GTX690_FCAT+FRAPS.png

http://www.oc-burner.de/ftp/3D-Center/1.FCAT+FRAPS_Vergleich(Vsync-off)/Pics/nebeneinander/S.T.A.L.K.E.R%20Call%20of%20Pripyat%20Benchmark%20-%20max%20settings_GTXTitan_FCAT+FRAPS.png

http://www.oc-burner.de/ftp/3D-Center/1.FCAT+FRAPS_Vergleich(Vsync-off)/Pics/nebeneinander/Heaven%20Benchmark%204.0%20-%20Scene%202-4%20-%20max%20settings_GTXTitan_FCAT+FRAPS.png

http://www.oc-burner.de/ftp/3D-Center/1.FCAT+FRAPS_Vergleich(Vsync-off)/Pics/nebeneinander/Need%20for%20Speed%20Most%20Wanted%20-%20max%20settings%20-%202xSSAA_GTXTitan_FCAT+FRAPS.png

http://www.oc-burner.de/ftp/3D-Center/1.FCAT+FRAPS_Vergleich(Vsync-off)/Pics/nebeneinander/The%20Witcher%202%20-%20max%20settings_GTXTitan_FCAT+FRAPS.png

FCAT+FRAPS_Vergleich(Vsync-off).zip (http://www.oc-burner.de/ftp/3D-Center/1.FCAT+FRAPS_Vergleich(Vsync-off)/1.FCAT+FRAPS_Vergleich(Vsync-off).zip)

aufkrawall

2013-03-31, 23:52:36

Kannst du bitte sagen wie die Einstellung genau heisst.
http://img.techpowerup.org/130331/nvidia_20130331_235215.png

Schaffe89

2013-04-01, 00:35:19

Die Trägheit bekommt man mit FPS-Limiter auch nicht heraus, das kapieren einige Leute aber nicht.

Die Verteilung der Frames ist mit SLI auch nicht gut, trotz Gegenmaßnahmen, da brauchts auch oft einen Framelimiter, aber das ignorierst du wohl? Besonders bei 3 Karten...:upicard: Und natürlich bekommt man de Trägheitdraus, die wenigsten Spiele droppen extrem runter.
Bei meinem HD 7870 Myth trippe CF habe ich in Assassins Creed, Crysis 3, Crysis 2 und Battelfield 3 jedenfalls keine drops unter 60 FPS, mein FX @ 4,7 NB 2.6 kann das locker packen, anders natürlich in Far Cry 3.
Bitte mal das ganze etwas differenzierter und nicht so einseitig betrachten, sowas nervt einfach nur.

Schau dir halt mal die Messwerte von OC_Burner an.

Godmode

2013-04-01, 00:54:17

Die Verteilung der Frames ist mit SLI auch nicht gut, trotz Gegenmaßnahmen, da brauchts auch oft einen Framelimiter, aber das ignorierst du wohl? Besonders bei 3 Karten...:upicard: Und natürlich bekommt man de Trägheitdraus, die wenigsten Spiele droppen extrem runter.
Bei meinem HD 7870 Myth trippe CF habe ich in Assassins Creed, Crysis 3, Crysis 2 und Battelfield 3 jedenfalls keine drops unter 60 FPS, mein FX @ 4,7 NB 2.6 kann das locker packen, anders natürlich in Far Cry 3.
Bitte mal das ganze etwas differenzierter und nicht so einseitig betrachten, sowas nervt einfach nur.

Schau dir halt mal die Messwerte von OC_Burner an.

Aber die Verteilung ist deutlich besser als bei CF:
http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-GeForce-GTX-Titan-GeForce-GTX-690-Radeon-HD-7990-HD-7970-Cross-0

Ein Framelimiter ist keine Lösung, solange er auf einen festen Wert gesetzt ist. Die Frameraten schwanken viel zu sehr. Du kannst ihn natürlich auf 30fps setzen, aber wozu dann noch ein mGPU System, das schafft ne sGPU auch, mit weniger Nachteilen.

Blaire

2013-04-01, 01:03:07

-Bitte löschen-

Schaffe89

2013-04-01, 12:11:48

@ Godmode

Ja klar ist sie das, ich sage ja auch nicht das Gegenteil, aber die Aussage man könne mit einer Single GPU besser Spielen, ist bei adaptiven V-sync jetzt wirklich nicht wahr.
Ich kapiers halt ehrlich gesagt nicht, warum man jetzt so übertreibt.

"Ein Framelimiter ist keine Lösung, solange er auf einen festen Wert gesetzt ist. Die Frameraten schwanken viel zu sehr. Du kannst ihn natürlich auf 30fps setzen, aber wozu dann noch ein mGPU System, das schafft ne sGPU auch, mit weniger Nachteilen."

Das ist eine Argumentation die mir zu stark in eine Richtung geht, mämlich CF bringt gar nichts, das gleich kannst du da über SLI sagen, dann die rameverteilung bei 3 GPU´s und ~50 FPS ist dann immer als moderates stuttering zu empfinden, schau dir bitte mal den PCGH test HD 7990 Ares vs GTX 690 an.

Besonders bei 3 Karten brauchst du dann spätestens einen Framelimiter, oder du aktivierst adaptive Vsync per Inspector oder Radeon Pro.
Ich habe mit Multi GPU zu jederzeit und zu jedem Zeitpunkt ein flüssigeres empfinden als mit einer Single GPU, besonders wenn eine Single GPu bei 30 FPs rumdünpeln würde, selbst ohne irgendwelch eingriffe mit v-sync oder Limitern, wer hat denn schonmal das Gegenteil erlebt oder einen Test gesehen, wo gesagt wurde dass CF das Flüssigkeitsempfinden nicht beeinflusst?
Also ich versteh Blaire da ehrlichgesagt überhaupt nicht. So eine penetrante Doppelmoral ist mir bisher kaum untergekommen.

Marty98

2013-04-01, 12:47:24

http://img.techpowerup.org/130331/nvidia_20130331_235215.png

Muss hinzu noch eine andere Option aktiv sein?

Marty98

2013-04-01, 12:52:32

@Schaffe

Es gibt durchaus Fälle wo es ohne CF deutlich besser geht als mit, d.h. CF deaktivieren ist eine "Optimierung" des Spiels.

http://www.pcper.com/files/imagecache/article_max_width/review/2013-03-25/Crysis3_1920x1080_OFPS.png

aufkrawall

2013-04-01, 13:11:15

Muss hinzu noch eine andere Option aktiv sein?
(Adaptives) Vsync halt.

pest

2013-04-01, 13:12:12

Hier mal ein paar Direktvergleiche zwischen FCAT, FRAPS, GTXTitan und einer GTX690.

Ah sehr schön danke, wie bekommst du aus den FCAT Daten die Frametimes raus? Würde gern Frappo damit füttern!

OC_Burner

2013-04-01, 13:52:44

Ah sehr schön danke, wie bekommst du aus den FCAT Daten die Frametimes raus? Würde gern Frappo damit füttern!

Das wäre schön wenn dein Tool damit fütterbar wäre. Die Frameabfolge von Fraps.csv in Spalte B, befindet sich in FCAT.xls in Spalte E. Die Einheit ist aber in Sekunden angegeben. In Spalte C stehen allerdings schon die richtigen Werte für die Frametimes.

Fraps.csv -->
SpalteA = Frame
SpalteB = Time

FCAT.xls -->
SpalteA = Frame
SpalteE = Time

pest

2013-04-01, 19:45:55

Ja Spalte E wäre sowas wie bei Fraps, aber was ist Spalte C? Auf welchen Zeitpunkt bezieht sich "Time" beim ersten Frame?

edit: achso das sind schon die Frametimes :>, versteh ich aber noch nicht, dann ist die "time" bei Frame 0 die Zeit von Frame 0 bis Frame 1?!

Peter Gräber

2013-04-01, 23:27:38

SLI AA macht nur ab Quad-SLI Sinn. Hatte zuerst SLI --> Müll, dann Tri-Sli -->Müll und dann Quad SLI ---> Bang! 32xSGSSAA, 16x geht auch noch. Man muss nur aufpassen das gewünschte Auflösung in 4x oder besser 8xSGSAA auf Single GPU läuft. Die GPU's werden mit SLI-AA alle 100% ausgelastet, wo ich das ausprobiert habe anfing mein Kühlwasser zu kochen... ^^
Man bekommt außerdem VRAM nicht mehr so voll dadurch werden 2160p@32xSLI-SSAA locker möglich.

Helft mir doch mal schnell. Wie ich es verstehe, sprechen wir gerade um einen angetretenen Beweis, dass Multi-GPU-Spieleerfahrungen durchaus scheiße sein können (wussten wir noch gar nicht)? Mehr noch, durch die neuen Messmethoden wird klargestellt (versucht), dass AMD CF in der Praxis kaum besser ist als eine Single-GPU von AMD, dafür aber NV SLI eben ein Stückchen besser (oder mehr) klarkommt.

Mit dem angeführten Zitat, haben wir es mit einer gewissen Schicht (Randgruppe) von Multi-GPU-Usern zu tun, für welche nun ein aufwändiges Messverfahren (ca. 2000 Euro <-- korrekt??) aufgebracht und Tools entwickelt wurden um zu zeigen, dass SLI besser ist als CF? Stimmt das so, oder hab ich jetzt bei den vielen Oster-Eiern den Faden verloren?

Ich für meinen Teil war überrascht. Da scheint viel Marketing im Spiel und auch eine volle Breitseite in Richtung AMD. Ich empfinde es als gut, dass man Messmethoden aufzeigt, welche den lästigen Marketingversprechen der MGPU-Systemen nun auch technisch etwas nachweisen können. Der Zeitpunkt und die Art der Kommunikation ist (für mein Empfinden) ungewöhnlich. Mit den deutschen Magazinen hatte man hier im Vorfeld definitiv nicht gesprochen.

HT4U wird sich an diesem Punkt definitiv erst einmal abwartend verhalten. Auf einen solchen Zug mag ich aktuell nicht aufspringen. Eine Nische? Ein Fass? Marketing-Strategie vs. Aufklärungspolitik? Malta? Das muss sich erst einmal setzen.

Marty98

2013-04-01, 23:56:32

Blaire

2013-04-01, 23:59:26

Match-Maker

2013-04-01, 23:59:36

@ Peter Gräber: Nein, dein angeführtes Zitat bezog sich nur auf SLI-AA, nicht auf Multi-GPU generell.
Dem ersten und dritten Abschnitt deines Posts stimme ich aber zu.

Peter Gräber

2013-04-02, 00:26:16

@Peter hast du dir die Artikel der letzten Woche bei PcPer, Tech Report, Anand und Tomshardware komplett durchgelesen? Die erklären eigentlich alles sehr gut. Es gibt bei Anand auch einen ausführlichen Artikel mit Stellungnahmen von AMD zum Thema.

Falls du nicht alles lesen willst, dieses Video erklärt das Messverfahren genau (inkl der Hardware die zum Messen benötigt wird):

http://www.youtube.com/watch?feature=player_embedded&v=CsHuPxX8ZzQ#hd=1

Ähm - was erklären die mir jetzt sehr gut? Das was ich angefragt habe? Das was ich hinterfragt habe? Was genau ist der aktuelle Stein des Anstoß? Meine Fragen habe ich gestellt. Ihr wisst ja offenbar mehr als ich ?!!

@ Blaire: The same ;)

Hübie

2013-04-02, 02:30:04

Helft mir doch mal schnell. Wie ich es verstehe, sprechen wir gerade um einen angetretenen Beweis, dass Multi-GPU-Spieleerfahrungen durchaus scheiße sein können (wussten wir noch gar nicht)? Mehr noch, durch die neuen Messmethoden wird klargestellt (versucht), dass AMD CF in der Praxis kaum besser ist als eine Single-GPU von AMD, dafür aber NV SLI eben ein Stückchen besser (oder mehr) klarkommt.

Mit dem angeführten Zitat, haben wir es mit einer gewissen Schicht (Randgruppe) von Multi-GPU-Usern zu tun, für welche nun ein aufwändiges Messverfahren (ca. 2000 Euro <-- korrekt??) aufgebracht und Tools entwickelt wurden um zu zeigen, dass SLI besser ist als CF? Stimmt das so, oder hab ich jetzt bei den vielen Oster-Eiern den Faden verloren?

Ich für meinen Teil war überrascht. Da scheint viel Marketing im Spiel und auch eine volle Breitseite in Richtung AMD. Ich empfinde es als gut, dass man Messmethoden aufzeigt, welche den lästigen Marketingversprechen der MGPU-Systemen nun auch technisch etwas nachweisen können. Der Zeitpunkt und die Art der Kommunikation ist (für mein Empfinden) ungewöhnlich. Mit den deutschen Magazinen hatte man hier im Vorfeld definitiv nicht gesprochen.

HT4U wird sich an diesem Punkt definitiv erst einmal abwartend verhalten. Auf einen solchen Zug mag ich aktuell nicht aufspringen. Eine Nische? Ein Fass? Marketing-Strategie vs. Aufklärungspolitik? Malta? Das muss sich erst einmal setzen.

Hallo Peter.

Es geht nicht nur um Multi-GPU-Lösungen sondern auch um einzelne Karten. Scott Wasson (Techreport.com) stieß letztes Jahr in einigen Spielen wie Skyrim oder Borderlands 2 auf stotternde HD 7950 (nicht CFX), worauf hin er eins zwei Folge-Artikel schrieb (u.a. wegen Win 8). AMD stellte einen Treiberfehler in der Speicherverwaltung fest, welcher sich mit GCN ergab. Der lässt sich jedoch nicht global beheben sondern größtenteils Engine für Engine, Spiel für Spiel. Um das zukünftig auch technisch zu erfassen suchte er nach Messmethoden. Scott wollte schon lange die gängigen Messverfahren verbessern / verändern, wusste jedoch nicht wie er die zuverlässig (*) nachweisen sollte und hielt mit diversen Kontakten Rücksprache. Das wurde schnell publik und stieß eine Lawine der "unabhängigen" Seiten, abseits von ZDNET & Co., in den USA los. Ryan Shrout (pcper.com) hat darauf hin eben seine Kontakte und Kenntnisse spielen lassen um nun ein neues Verfahren zu präsentieren welches sich nicht nur an Peformance orientiert sondern eben auch an "gaming smoothness" bzw. des flüssigen Spielens.
Insgesamt keine schlechte Methode, jedoch sollte man das eher den Herstellern aufbrummen und nicht den Redakteuren "aufzwingen". Insgesamt ist die Umstellung positiv zu bewerten, wenn man mal den anfänglichen (finanziellen) Aufwand beiseite lässt.
Manche (Redakteure wie auch Leser!) wittern bei jeder Neuigkeit gleich Verschwörungen. Fakt ist jedoch dass sowohl bei AMD als auch bei nVidia nur Menschen arbeiten. Den Rest kann sich jeder zurecht philosophieren.

btw: Mit 2000 Euro kannst du vielleicht deren RAID-System bezahlen, mehr nicht ;D

*FRAPS und auch andere tools messen je nach Engine bzw. API-Level nicht zuverlässig! Beispiel:
The above is what AMD is calling the heartbeat pattern, and it’s something FRAPS is reporting even in some of the games they’ve fixed. This highlights one of the problems with trying to monitor frame intervals based on Present calls, as the context queue is absorbing the uneven frame dispatch, but FRAPS doesn’t realize it. Quelle (http://www.anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps/5)

MadManniMan

2013-04-02, 02:47:31

HT4U wird sich an diesem Punkt definitiv erst einmal abwartend verhalten.

Dann bearbeitet die Frameratenverteilung bei allen möglichen Karten halt auf herkömmliche Weise, aber diese Passivität wie zuletzt ist ein bisschen deprimierend. Von den deutschen Mags ist so gut wie gar nichts gekommen, was mich irritiert hat. Aber ich will nicht weinen, eher hoffen: diese grundlegende Methodik beinhaltet die Möglichkeit, die eigentliche Wertigkeit der ausgegebenen Frames tatsächlich zu beurteilen. Es wird noch zu ermitteln sein, inwiefern ein Höchstmaß an Gleichmäßigkeit tatsächlich wünschenswert und ideal ist, vielleicht gibt es ja größere Lags? Oder vielleicht sinken Frameraten zu sehr? Alles Sachen, die noch nachvollzogen werden können.

Vor allem aber: Mikroruckeln tritt auch bei Single-GPU-Systemen auf. Zum ersten Mal habe ich es persönlich 2005(!) bei meiner Geforce 6600 Go beim 3DMark 06 beobachtet, aber noch nicht zuordnen können.

Zum konkreten PC-Perspective-Artikel: mir persönlich fehlt irgendwie bei den "observed FPS" noch der Einbezug von schlechten Timings, die aber nicht gleich als "Runt" einzustufen sind.

Und: es gibt diverse Indizien, dass Hyperthreading-Systeme besonders anfällig sind.

Soooviel Raum für sooo viele Artikel! Gerade weil in letzter Zeit auf der reinen Leistungsseite so wenig passiert ist, wäre eine qualitative Betrachtung der vorhandenen umso wünschenswerter.

Hübie

2013-04-02, 02:52:19

Manni, schau mal auf anandtech.com. Dort wird die Kausalität zwischen GPU <-> CPU erklärt und warum es eben mit HT noch verschlimmbessert werden kann.
Soviel ich weiß stellt CB bpsw. doch auch langsam um. Und die anderen sind weder blind noch ignorant. Veränderungen brauchen aber nun mal ihre Zeit. Erfahrung lässt sich durch nichts ersetzen - das ist ein Gesetz. ;)

Angiesan

2013-04-02, 03:00:21

Helft mir doch mal schnell. Wie ich es verstehe, sprechen wir gerade um einen angetretenen Beweis, dass Multi-GPU-Spieleerfahrungen durchaus scheiße sein können (wussten wir noch gar nicht)? Mehr noch, durch die neuen Messmethoden wird klargestellt (versucht), dass AMD CF in der Praxis kaum besser ist als eine Single-GPU von AMD, dafür aber NV SLI eben ein Stückchen besser (oder mehr) klarkommt.

Mit dem angeführten Zitat, haben wir es mit einer gewissen Schicht (Randgruppe) von Multi-GPU-Usern zu tun, für welche nun ein aufwändiges Messverfahren (ca. 2000 Euro <-- korrekt??) aufgebracht und Tools entwickelt wurden um zu zeigen, dass SLI besser ist als CF? Stimmt das so, oder hab ich jetzt bei den vielen Oster-Eiern den Faden verloren?

Ich für meinen Teil war überrascht. Da scheint viel Marketing im Spiel und auch eine volle Breitseite in Richtung AMD. Ich empfinde es als gut, dass man Messmethoden aufzeigt, welche den lästigen Marketingversprechen der MGPU-Systemen nun auch technisch etwas nachweisen können. Der Zeitpunkt und die Art der Kommunikation ist (für mein Empfinden) ungewöhnlich. Mit den deutschen Magazinen hatte man hier im Vorfeld definitiv nicht gesprochen.

HT4U wird sich an diesem Punkt definitiv erst einmal abwartend verhalten. Auf einen solchen Zug mag ich aktuell nicht aufspringen. Eine Nische? Ein Fass? Marketing-Strategie vs. Aufklärungspolitik? Malta? Das muss sich erst einmal setzen.

Hmmm so kenne ich den Mann ja gar nicht? Aber vielleicht leide ich zu dieser Uhrzeit nur unter einer Leseschwäche, was ist eigentlich genau deine Frage?

Ich versuche es trotzdem mal, soweit ich das mit bekommen habe, suchte man einen Weg der das Problem der Microruckler besser aufzeigen soll, dabei ist man dann per Zufall oder per Hinweis auf die extreme Probleme von Crossfire aufmerksam geworden und wie es der Zufall so will hat NV ein Tool parat, das genau zeigt wie Scheiße das ganze doch eigentlich immer ist und nicht nur ab und an.

Was wundert dich jetzt so an der ganzen Sache???

Es ist vollkommen normal, dass man die Schwächen seiner Mitbewerber aufzeigt wenn man in diesem Bereich besser da steht. Die Presse nimmt diese Sachen doch auch gerne an und ich finde das auch richtig, denn ich gehöre zu der Randgruppe die du o.a. hast.
Das ganze gewinnt und da gebe ich dir Recht an Relevanz, da die 7990 nun doch offiziell kommen soll und sie wird halt die schnellste Karte sein wenn man mit Fraps messen wird und wohl auch deutlich günstiger wie die GTX 690 und die Titan aus dem Hause NV sein.

Aber das man sich darüber so aufregen kann verstehe ich jetzt nicht, man muss als Online-Mag ja nicht auf den Zug aufspringen wenn man denkt, dass es keine Relevanz hat und ein Bericht und die damit verbundenen finanziellen Aufwendungen nicht lohnen da die Randgruppe zu klein ist.

Ich bin dankbar und wäre es auch wenn ich ein CF System hätte da ich dann weiß was ich habe und sorry aber zur Zeit ist CF wenn man es out of the box nutzt einfach nur eine teure Heizung die keiner braucht.
Die Zielgruppe für CF sind doch die 7970/50 User die darüber nachdenken vielleicht eine zweite Karte reinzuhängen um für 700 Euro einen Titan und GTX 690 Killer im System hängen zu haben jetzt könnte man vortrefflich streiten ob der Placeboeffekt reicht um Menschen glücklich zu machen.

Das ganze erinnert mich an die Zeit als die mobilen Navigationsgeräte auf den Markt gekommen sind, damals bin ich noch leidenschaftlich Moped gefahren und wenn wir uns Abends getroffen haben hörte man schon mal, man eben auf der A5 gerade die 300 Km/H geknackt. Wie wir anfingen mit den Navs zu messen mussten wir alle feststellen, dass das leider aufgrund von Schlupf und Messungenauigkeit nur 250-265 KM/h waren, geweint hat deswegen aber keiner.

Aber abschließend zum Thema, gerade eine kritische Redaktion wie Ihr sollte sich neuen Sachen , wenn sie belegbar sind nicht verschließen, ich würde es Schade finden wenn man bei euch einen Test der 7970 oder zukünftigen GTX790 lesen würde und dieser die Problematik von MGPU Systemen egal von welchem Hersteller nicht berücksichtigen oder eben die Technik bestätigen würde. Gerade MGPU User geben relativ viel Geld für ihr Hobby aus, da soll es auch lohnen und da soll die gekaufte Leistung auch nutzbar sein!
Ich für meinen Teil würde es in diesem Zusammenhang dann nur als konsequent empfinden wenn man überhaupt keine MGPU System testet bis die Sache final geklärt ist.

Hübie

2013-04-02, 03:17:06

Schaffe89

2013-04-02, 03:45:27

aber zur Zeit ist CF wenn man es out of the box nutzt einfach nur eine teure Heizung die keiner braucht.

Tendenziell mag das zwar stimmen, aber Peter hat schon recht mit der Breitseite gegen AMD.
Jahrelang wurde berichtet, dass CF und SLI subjektiv deutlich flüssigeres Gameplay erlauben und das wúrde auch von jedem so gesehen.
Jedes Review das ich kenne hat´seit Tombman die µruckler aufgedeckt hat auch darüber berichtet und Nvidia zumindest ab Kepler die im Schnitt eundeutig stuttering ärmere Darstellung zugeschrieben, was denke ich auch korrekt ist, trotzdem war und ist ( auch bei mir) das Empfinden Single vs. dual ohne Zusatzmaßnahmen ( solange SLI/CF funzt) immer pro Dual gewesen.

Jetzt wird aber aktuell wieder sehr stark übertrieben ( meiner Meinung nach), denn der Tenor ist jetzt CF ist ein Placebo effekt und bringt gar nichts, SLI ist laut einigen Usern der Gral obwohl dort auch teils massive Probleme bestehen und téils auch CF Frametimes besser sind, sogar mit FCAT.

Hier sollte man doch bitte etwas differenzieren bevor man die nächste Sau durchs Dorf treibt.
Ich hab mir im Hardwareluxx mal die Mühe gemacht und verschiedene Szenen mit Fraps gemessen, und das auch subjektiv versucht zu bewerten.

Von den deutschen Mags ist so gut wie gar nichts gekommen, was mich irritiert hat.

Naja, schauen wir uns doch mal den ersten Test von CB an.
Man hat das ganze Frametimeanalyse genannt hat erstmal Titan mit HD 7970ghz vergleichen. Im Mittel gigen 6 Spiele an NV, die anderen mit zwei zugedrückten Hühneraugen an AMD ( eher gleichauf).

So dann hat man die gleichen Szenen noch mit langsameren Pendants zur HD 7790 Release gemessen.
Hm.. Nvidia wird tendenziell schlechter, Frametimes relativ ausgeglichen, etwas besser noch bei nvidia. Und das alleine weil andere Karten eingebaut waren und vielleicht das System mal nen besseren Tag hatte.
Keine Ahnung woran es liegt auch keine Kommentare dazu, ob evtl.. Abhängigkeit von SMT, System.. Treiber.. Windows? K.A

Dann FCAT Messungen, der erst kürzlich veröffentlichte test bescheinigt AMD bei 3 von 8 Spielen bessere Werte, einmal gleichauf und dann bei anderen Spielen plötzlich riesen Unterschiede, aber subjektiv sagt der Tester dass er da nicht so viel sieht.

Was sagen denn die Werte nun konkret und wie muss ich sie bewerten? Das ist alles so komplex, dass man auch schnell mal einfach nur käse messen oder käse schlussfolgern kann, oder sich überhaupt nicht sicher ist was man da jetzt da letztenlich gemessen hat.

Ich zitiere mal Skysnake bei der PCGH:

Und das weißt du woher genau? Quellcode etwa schon eingesehen?

Ich finde es prinzipiell sehr gut, das sich PCGH der Thematik annimmt, denn das Thema FCAT ist schon ein SEHR diffizieles Thema, dessen sich die meisten Leute überhaupt nicht bewusst sind...

Es gibt gleich eine ganze Reihe von Problemen:

•Wie wird die Zeitmarke gesetzt?
•Wie wirkt sich dies auf die Leistung aus?
•Gibt es möglichkeiten eine Verzögerung/Eingriff des Treibers zu erkennen?
•usw usw
Wenn man sich an die "Cheatschlachten" der Vergangenheit zwischen ATI und nVidia anschaut, dann sollte man mit ALLER! größter Vorsicht solche Sachen betrachten!

Als erstes müsste man erstmal klären, was FCAT denn wirklich macht, und wo Sie das Bild manipulieren, wie Sie es machen, ob es irgendwelche Abhängigkeiten gibt usw usw. Also sprich, zumindest von FCAT MUSS! der Quellcode offengelegt werden. Davor brauchen wir gar nicht anfangen über die Ergebnisse zu reden. Wir wissen nämlich gar nicht, was wir da wirklich im Detail angezeigt bekommen, und wie man die Daten zu interpretieren hat! Wir bekommen halt IRGENDWELCHE Daten, mit denen man dann wilde Sachen macht, aber wir wissen eben die ganzen Randbedingungen eben noch nicht!

Und selbst wenn wir den Quellcode einsehen dürfen, dann dann gibt es dort noch immer den Treiber, der die wildesten Sachen machen kann... Von uns kann KEINER! ausschließen, dass die Farben nicht manipuliert werden, oder das Bilder eben künstlich verzögert werden, um ein scheinbar "flüssigeres" Spielerlebnis zu bekommen. Eventuell schmeist man auch im Treiber bewusst Bilder weg, wenn man erkennt, das Sie zu lange brauchen, oder zu früh kommen oder what ever. Kurz um, eigentlich müssten auch noch die Treiber offengelegt werden, und am Besten! noch von einem selbst compiliert werden, damit man wirklich sicher sein kann, dass da kein Schindluder getrieben wird... In der Vergangenheit haben einfach BEIDE schon viel zu krasse Sachen abgezogen, als das man ihnen da auch nur einen Millimeter über den Weg trauen dürfte... Genau das wird aber NIEMALS passieren. Vor allem nicht bei nVidia. Da können wir warten, bis es nVidia nicht mehr gibt. Vorher bekommen wir niemals den Quellcode ihres Treibers zu sehen...

Und selbst WENN wir das alles schaffen würden, bleibt noch ein wesentlicher Punkt übrig. Es werden nur einzelne Drawcalls analysiert. Dabei wird die Ingamezeit allerdings völlig vernachlässigt, soweit ich das verstanden habe, da man eben reihum die Bilder in einem zyklus einfärbt. Es ist aber eben aprio nicht so, dass die Drawcalls immer nach der selben ingame Zeitspanne erfolgen. Da gibt es durchaus große Unterschiede. Allein wenn mal irgendwo im Hintergrund ein Interrupt oder was weiß ich was angeht, und damit eben die ingame Latenz zwischen zwei Bildern länger ist als normal, wird eben nicht berücksichtigt. Genau in so einem Fall müsste aber eben ein Bild nur teilweise angezeigt werden im Optimalfall, und nicht voll wie sonst....

Genau die Problematik, und ihre "Schlupflöcher", lässt in mir die Befürchtung aufkommen, das nVidia eben ihre Treiber darauf optimiert hat, die Bilder in gewissen Zeitintervallen auszugeben, und dabei verzögerungen bewusst in Kauf nimmt. Mit FCAT sieht man die Differenz zwischen Ingametime und Outputtime aber nicht.... Ergo gewinnt man dadurch scheinbar

Kurz um, so wie FCAT aktuell aufgebaut ist vom Konzept her, ist es einfach unbrauchbar, und zwar von vorne bis hinten.

Man kann damit einfach nichts wirklich anfangen....

Mir schwirrt da immer der Leitspruch eines Experimentalphysik Profs im Kopf rum: "Wer viel misst, misst meist Mist"

Damit ist gemeint, das man nicht einfach drauflos messen soll, sondern sich VORHER genau überlegen soll, was man da eigentlich macht, wo die Fehlerquellen sind, wie groß die Fehler sind usw usw usw.

Ich hoffe ihr habt bemerkt, WIE kompliziert die Sache ist, und da einem Tool, was sich mal einfach so in die Runtime reinhackt, auf gut Glück vertrauen ist einfach ziemlich fahrlässig in meinen Augen....

Meiner Meinung ist es insgesamt ein stärkeres AMD Problem bei Single GPu, vor allem in Hitman und the Witcher.

Es gibt aber auch Probleme bei Nvidia bezgl. ungleichmäßiger Bildausgabe, siehe Sleeping Dogs und auch subjektiv deutlichens empfinden von µrucklern, wenn man lang genug sucht und bohrt findet man sicher bei jedem Hersteller seine Probleme, deswegen werd ich auch alle Spiele die ich daheim hab mal bisschen testen, alleine schon damit ich weiß welche Karte ich nun für welches Spiel einbaue :D.
die HD 7970? die GTX 670? Oder das Tripple CF?^^

Und das waren eh schon die Titel wo ich wirklich Unterschiede sehe oder messe.
Be Crysis 3, Tombraider ( nach dem neuen Treiber) Black Ops 2, Battlefield 3 uswusw.. beiden allermeisten Spielen, ist mir eher nichts aufgefallen was präsentierbar wäre, ich hab sogar schon Szenen gesucht wo das mal der Fall sein könnte.

Mehr noch, durch die neuen Messmethoden wird klargestellt (versucht), dass AMD CF in der Praxis kaum besser ist als eine Single-GPU von AMD, dafür aber NV SLI eben ein Stückchen besser (oder mehr) klarkommt.

Naja die Tendenz hat man vorher schon subjektiv ausmachen können, ich finde es vielmehr gut, dass man jetzt endlich vermehrt dies auch theoretisch belegen kann.

Es ist aber ein ähnliches Thema bei dem gewollte Neutralität mal schnell auf die eine oder andere Seite ausschlagen können, drum sollte man vielleicht pauschalisierungen vermeiden.

Ich fänds jedenfalls toll wenn ihr zumindest ein paar Fraps Werte veröffentlicht, sind zwar laut den Anforderungen von AMD und Nvidia nicht der Gral, taugen aber für die erkennung von Problemen.

Abschließend würde mich mal brennend interessieren was nun AMD zum FCAT Tool sagt oder was AMD derzeit zu der Sachlage überhaupt kommuniziert, da müsste halt jemand mal nachhaken und gegebenenfalls auch mit NV und AMD zusammenarbeiten.

Wenn AMD sagt, das Tool ist gut, dann wärs natürlich klasse und man könnte das immer verwenden, ohne befürchten zu müssen dass sich Fanboys oder Kritiker die Köpfe einwschlagen.

Bei der Komplexheit der Sache kann ich jedenfalls verstehen, dass man sich da bedeckt hält und erstmal abwartet, die Frametimetests und Schlussfolgerungen von Cb waren naja, auch nicht gerade sehr sinnvoll, da hat man sich auch aufgrund eines Asureißers, der an sonst was liegen kann aufgehängt und von Problemen gesprochen, inwieweit das Probleme sind oder nicht, wird man sich nicht klar.

kruemelmonster

2013-04-02, 04:44:52

Das nächste Mal skysnakes NV-Paranoia bitte da lassen wo du sie findest, das ist schon lange nicht mehr zum aushalten auch wenn er noch so oft BEIDE schreiben mag.

Man kann auch skeptisch sein ohne zum treiberselbstkompilierenden Zottelbart mit Silberfolienhut und roter Bettwäsche zu werden.

Schaffe89

2013-04-02, 04:49:04

Man sollte aber zumindest auch Kritiker zitieren und nicht nur die Leute die sagen, Hey Geil nehmen wir!.

Es wär jedenfalls schön wenn AMd noch ne Stellungnahme raushauen würde, könnte aber auch sein, dass die sich jetzt verkriechen, weils Probläme gibt.

Hübie

2013-04-02, 04:51:54

Dann lies bitte auch mal meinen post, lieber schaffe... FRAPS ist eben nicht geeignet. Da muss schon was von den Herstellern kommen. Gipsel hatte mir das vor einiger Zeit mal per PN erklärt aber nun gibts das halt auch noch schwarz auf weiß bei anandtech.com.

Ich mache mir dennoch lieber selber ein Bild und besorge mir von beiden jeweils eine in betracht kommende Karte. Da ich jedoch noch keinen konktreten upgrade-Plan habe steht das aus.

Schaffe89

2013-04-02, 04:55:36

Und wieso ist Fraps nicht geeignet um Probleme zu zeigen? ( Vielleicht mal Gispel´s Beitrag hier reinpflanzen, mit seiner erlaubnis natürlich)
Im Prinzip decken sich schwankende Frametimes in Fraps mit dem subjektiven µrucklern auf dem Schirm, ich hab mir zwar die Tests durchgelesen und auch grob verstanden, warum Fraps nicht alles aufzeichnet, aber ungeeignet? Kapier ich nicht.

treiberselbstkompilierenden Zottelbart mit Silberfolienhut und roter Bettwäsche zu werden.

Und wer sagt mir, dass die Werte die ich da messe taugen für eine Bewertung was letztendlich am Schirm ankommt?

Gibts da ne FAQ von Nvidia?^^

Gouvernator

2013-04-02, 06:44:32

Also ich steige demnächst überall wo ich kann auf SLI-AA um. Jetzt eine zeitlang damit gespielt, mir geht AFR Lag soo auf den Sack. Ab Quad-SLI ist es so heftig ich treffe in Chivalry gar nix. Das merkt man SO sehr wenn man hin und her springt. Ich hab BQ verglichen und 32xSLI AA (SSAA) ist genau so schnell und sieht genau so gut aus wie 2x2 Downsampling+2xSGSAA. Es ist offensichtlich das 32xSLI AA natürlich besser aussieht für verbrauchte Leistung, weil eben alle 4 Karten immer zu 100% ausgelastet werden.

Marty98

2013-04-02, 07:52:08

Ähm - was erklären die mir jetzt sehr gut? Das was ich angefragt habe? Das was ich hinterfragt habe? Was genau ist der aktuelle Stein des Anstoß? Meine Fragen habe ich gestellt. Ihr wisst ja offenbar mehr als ich ?!!

@ Blaire: The same ;)

Ja, das Video erklärt wieso ein neues erfahren Nötig war, wie es funktioniert, und welche Hardware/Software man dazu benötigt.

Dazu ist noch der AMD Artikel bei Anand interessant, in dem AMD auch zugibt dass ein neues Messverfahren nötig ist, weil Fraps suckt: http://www.anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps

Marty98

2013-04-02, 07:58:50

Jahrelang wurde berichtet, dass CF und SLI subjektiv deutlich flüssigeres Gameplay erlauben und das wúrde auch von jedem so gesehen.

Das ist blanker Unsinn. Seit Jahren wird über Mirkroruckler berichtet, nur nicht im Mainstream. NVidia hat vor längerer Zeit angekündigt dagegen vorzugehen. AMD schwieg bis vor paar Monaten, wo sie erstmals Probleme zugegeben haben. Dass CF flüssiges Gameplay erlaubt (ohne Framelimiter, der andere Probleme verursacht) haben höchstens Fanboys behauptet, sonst niemand!

Angiesan

2013-04-02, 09:35:32

@Angiesan: Um es noch einmal herauszustellen: Es geht allgemein um flüssiges gameplay. Nicht nur in mGPU-Konfigurationen. Dort hat AMD ein großes Leck zu stopfen aber auch im sGPU-Bereich gibts Lecks. Alles halb so wild denn die Millionen AMD-Karten-Besitzer laufen ja nicht sturm. Also wirds sicherlich auch nur heißer gekocht als gegessen (...klicks pro Minute und so).

Übrigens müssen beide IHVs sich daran beteiligen weil deren Treiber nicht open source sind. nVidia hatte nur schon ein tool-set parat (vermutlich weil die intern schon länger frame-metering betreiben). AMD hat zwar GPU View was jedoch - soweit mir bekannt ist - keine tabellarischen Ausgaben erstellen kann (*.CSV o.ä.).
Hubie, das weiß ich doch steht doch auch in meinem ersten Satz ich zitiere mich mal selbst "soweit ich das mit bekommen habe, suchte man einen Weg der das Problem der Microruckler besser aufzeigen soll". Da das Problem von MR ja nicht auf MGPU System beschränkt ist und auch NVidia betroffen ist ist das Ganze um so wichtiger, ich muss aber sagen, das ich diese weder mit AMD HW noch mit NV HW bemerkt habe außer bei sehr wenigen Spielen. FC3 ruckelte immer auf allem. Und Skyrim irgendwann auf AMD ich kann mich noch erinnern, dass das nicht immer so war.Trotzdem und da geht es nicht um AMD oder NV wenn die Testergebnisse stimmen, ist das ein dicker Hund mit CF, dass NV da schon länger Zeit und Ressourcen investiert ist mir bekannt und sie machen es nicht nur in Software wenn ich richtig informiert bin.

Tendenziell mag das zwar stimmen, aber Peter hat schon recht mit der Breitseite gegen AMD.
Jahrelang wurde berichtet, dass CF und SLI subjektiv deutlich flüssigeres Gameplay erlauben und das wúrde auch von jedem so gesehen.
Jedes Review das ich kenne hat´seit Tombman die µruckler aufgedeckt hat auch darüber berichtet und Nvidia zumindest ab Kepler die im Schnitt eundeutig stuttering ärmere Darstellung zugeschrieben, was denke ich auch korrekt ist, trotzdem war und ist ( auch bei mir) das Empfinden Single vs. dual ohne Zusatzmaßnahmen ( solange SLI/CF funzt) immer pro Dual gewesen.

Jetzt wird aber aktuell wieder sehr stark übertrieben ( meiner Meinung nach), denn der Tenor ist jetzt CF ist ein Placebo effekt und bringt gar nichts, SLI ist laut einigen Usern der Gral obwohl dort auch teils massive Probleme bestehen und téils auch CF Frametimes besser sind, sogar mit FCAT.

Hier sollte man doch bitte etwas differenzieren bevor man die nächste Sau durchs Dorf treibt.
Ich hab mir im Hardwareluxx mal die Mühe gemacht und verschiedene Szenen mit Fraps gemessen, und das auch subjektiv versucht zu bewerten.

Siehe oben zu dem Problem der MR in SGPU, zu MGPU die Wirtschaft ist kein Pony Hof und natürlich wird hier mit allen Mitteln gekämpft, solange das aber so ist, dass nicht ohne Fakten gearbeitet wird empfinde ich das legitim, oder steht AMD aufgrund ihrer wirtschaftlichen Lage unter Welpenschutz??? Und natürlich SLI hat auch Probleme und zum Teil sehr große, ich hatte mit das ganz anders vorgestellt wie ich mir die GTX 690 reingehängt hatte, aber man kann sich arrangieren, wenn man will und es gibt halt verschiedene Lösungsmöglichkeiten bei SLI die man zumindest ausprobieren kann SLI Profile mit dem Inspector bearbeiten oder vSync (Flüssig) das erreicht man auch ohne Zusatztool im Treiber und ist wenn man so will ein dynamischer Framelimiter der zumindest unter 120 Hz Monitoren eine sehr gute Figur macht da er dort 4 Stufen zur Verfügung hat wobei meiner Meinung nach nur 3 im spielbaren Bereich liegen 120,60 und 40 FPS. die 4. Stufe 30 FPS betrachte ich als grenzwertig spielbar.
Wenn es das nicht geben würde wäre die GTX 690 wohl schon gegen ein SGPU getauscht worden.
Es wurde von meiner Seite auch nur ein MGPU Lösung gekauft da meine verwendete Auflösung öfter nicht mehr von einer Karte gestemmt werden konnte und wenn man 30-35 SGPU - FPS gegen 50-60 MGPU-FPS vergleicht fühlen sich i.d.R: die 50-60 MGPU FPS besser und direkter an, das ist der Vorteil für mich! SLi AA und solche Sachen habe ich noch nicht probiert sehe ich zumindest wenig Zukunft drin denn AA wird immer teurer und seltener in "heutigen Spielen".

MadManniMan

2013-04-02, 13:21:16

Und wieso ist Fraps nicht geeignet um Probleme zu zeigen?

Du hast den PC-Perspective-Artikel nicht gelesen?

pest

2013-04-02, 13:53:45

Fraps ist immernoch "genausogut" geeignet (allgemeine) Probleme zu entdecken. Nen Variationskoeffizient von 50% wird sich auch durch Framepacing nicht magisch in Luft auflösen.
Vielleicht habe ich heute nach der Arbeit noch ein wenig Zeit um Frappo FCAT-tauglich zu machen.

Aber das Argument gefällt mir. Solange du keine 1k € für Capture-HW ausgibst sind alle Messungen für den Popo

MadManniMan

2013-04-02, 13:59:15

AMD behauptet, sie hätten Mikroruckler bei einigen Sachen behoben, was sich aber nicht in FRAPS darstelle, weil es an der falschen Stelle misst. Ist das so unglaubwürdig?

pest

2013-04-02, 14:02:16

wir werden sehen

aufkrawall

2013-04-02, 14:05:20

Fraps-Messungen kann man dann gelten lassen, wenn sie einen negativen subjektiven Eindruck bestätigen.
Wobei ich Reviewern keinen glaubhaften subjektiven Eindruck zutraue, wenn gebencht wird wie am Fließband. Deshalb sind diese Frame-Messungen schon sehr wichtig, man hat maximale Objektivität und Genauigkeit.

Grestorn

2013-04-02, 14:06:29

AMD behauptet, sie hätten Mikroruckler bei einigen Sachen behoben, was sich aber nicht in FRAPS darstelle, weil es an der falschen Stelle misst. Ist das so unglaubwürdig?

Nein, es wäre unglaubwürdig, wenn sie behaupten würden, dass man es in FRAPS sieht. Denn das ist ja das Problem: "runts" und "drops" sieht man eben in FRAPS nicht, entsprechend kann man auch ihre Eliminierung in FRAPS nicht sehen.

MadManniMan

2013-04-02, 14:33:12

Fraps-Messungen kann man dann gelten lassen, wenn sie einen negativen subjektiven Eindruck bestätigen.

Bzw. sind sie mit unserem aktuellen Wissensstand ein Hinweis auf Probleme bereits an der FRAPS-Messstelle.

Wobei ich Reviewern keinen glaubhaften subjektiven Eindruck zutraue, wenn gebencht wird wie am Fließband. Deshalb sind diese Frame-Messungen schon sehr wichtig, man hat maximale Objektivität und Genauigkeit.

Genau das denke ich nämlich auch. Und: egal wie kritisch ein Tester auch sein mag, er wird bei Crossfire-Setups wohl in den allermeisten Fällen auch dann Vorteile zu spüren gemeint haben, wenn es sich komplett um Runts und Drops handelt. Weil: FRAPS zeigte ja, dass zumindest ein bisschen was passiert und GAR keinen Vorteil bei 2 x Grafikkarte? No way! ;)

Nein, es wäre unglaubwürdig, wenn sie behaupten würden, dass man es in FRAPS sieht. Denn das ist ja das Problem: "runts" und "drops" sieht man eben in FRAPS nicht, entsprechend kann man auch ihre Eliminierung in FRAPS nicht sehen.

Genau das ist das, was ich meinte, als ich den von Dir zitierten Teil pest entgegnete.

pest

2013-04-02, 19:30:08

Ich habe in Frappo mal schnell rudimentären FCAT Support eingebaut

Hier mal ein paar Statistiken

GTX690
Heaven Fraps: Avg: 63,89 fps, 90% Time [17 fps, 156 fps], Vark: 83%
Heaven FCAT: Avg: 63,13 fps, 90% Time [24 fps, 129 fps], Vark: 64%, 1% Frames < 1ms

NFS Fraps: Avg: 38,56 fps, 90% Time [9 fps, 182 fps], Vark: 85%
NFS FCAT: Avg: 39,67 fps, 90% Time [26 fps, 59 fps], Vark: 37%, 0,8% Frames < 1ms

Stalker Fraps: Avg: 119,77 fps, 90% Time [70 fps, 178 fps], Vark: 36%
Stalker FCAT: Avg: 121,15 fps, 90% Time [76 fps, 184 fps], Vark: 38%, 0,1% Frames < 1 ms

Witcher 50% Fraps: Avg: 30,70 fps, 90% Time [30 fps, 31 fps], Vark: 1,4%
Witcher 50% FCAT: Avg: 31,40 fps, 90% Time [31 fps, 32 fps], Vark: 11,3%

Witcher 95% Fraps: Avg: 55,89 fps, 90% Time [41 fps, 75 fps], Vark: 25%
Witcher 95% FCAT: Avg: 55,50 fps, 90% Time [47 fps, 65 fps], Vark: 13%

samm

2013-04-02, 21:45:34

Spannend, wie die Avg-fps auch steigen können und die Abweichung erhöht sein kann... Woher stammen denn die Beispieldaten?

Match-Maker

2013-04-03, 00:07:01

@ pest: Was ist Frappo? :redface:

Godmode

2013-04-03, 00:08:31

@ pest: Was ist Frappo? :redface:

Das Tool was er geschrieben hat um die Fraps-Daten auszuwerten.

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=537679&highlight=frappo

Match-Maker

2013-04-03, 00:16:08

Ah, ok. Sieht aber interessant aus, was er da zusammengezimmert hat, muss ich sagen. :O

gedi

2013-04-03, 01:19:53

Also für mich sind die Messungen in Bezug auf Testumgebung (Treiber, Hardware, Ausgabegerät ...) viel zu rudimentär und nicht transparent.

Marty98

2013-04-03, 02:13:32

Also für mich sind die Messungen in Bezug auf Testumgebung (Treiber, Hardware, Ausgabegerät ...) viel zu rudimentär und nicht transparent.

Die beiden letzten Artikel von PCPer und Tech Report, geben die genaue HW, Treiber und Spieleinstellungen an. Wenn das nicht transparent ist, dann verstehen wir beide was anderes unter dem Wort.

Hübie

2013-04-03, 02:56:49

Also für mich sind die Messungen in Bezug auf Testumgebung (Treiber, Hardware, Ausgabegerät ...) viel zu rudimentär und nicht transparent.

Wo und was meinst du denn? :confused:

DrumDub

2013-04-03, 11:24:54

Wo und was meinst du denn? :confused:

Inside the second with Nvidia's frame capture tools
(http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools)

Marty98

2013-04-03, 14:03:36

Inside the second with Nvidia's frame capture tools
(http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools)

Ist doch 100% an allen relevanten Daten (Hardware, Treiber, Spieleinstellungen) angegeben.

DrumDub

2013-04-03, 14:16:40

Ist doch 100% an allen relevanten Daten (Hardware, Treiber, Spieleinstellungen) angegeben. ich habe auch nix anderes behauptet. :)

MadManniMan

2013-04-03, 17:57:25

Hier mal ein paar Statistiken

GTX690
Heaven Fraps: Avg: 63,89 fps, 90% Time [17 fps, 156 fps], Vark: 83%
Heaven FCAT: Avg: 63,13 fps, 90% Time [24 fps, 129 fps], Vark: 64%, 1% Frames < 1ms

NFS Fraps: Avg: 38,56 fps, 90% Time [9 fps, 182 fps], Vark: 85%
NFS FCAT: Avg: 39,67 fps, 90% Time [26 fps, 59 fps], Vark: 37%, 0,8% Frames < 1ms

Stalker Fraps: Avg: 119,77 fps, 90% Time [70 fps, 178 fps], Vark: 36%
Stalker FCAT: Avg: 121,15 fps, 90% Time [76 fps, 184 fps], Vark: 38%, 0,1% Frames < 1 ms

Witcher 50% Fraps: Avg: 30,70 fps, 90% Time [30 fps, 31 fps], Vark: 1,4%
Witcher 50% FCAT: Avg: 31,40 fps, 90% Time [31 fps, 32 fps], Vark: 11,3%

Witcher 95% Fraps: Avg: 55,89 fps, 90% Time [41 fps, 75 fps], Vark: 25%
Witcher 95% FCAT: Avg: 55,50 fps, 90% Time [47 fps, 65 fps], Vark: 13%

Könntest Du die einzelnen Werte bitte mal erklären? Dankeschön!

Hübie

2013-04-03, 18:11:01

ich habe auch nix anderes behauptet. :)

Wir warten ja auch auf eine Antwort von gedi. Weiß gar nicht warum du dich meldest ;)

pest

2013-04-03, 19:50:58

Spannend, wie die Avg-fps auch steigen können

Ich würde nicht sagen, dass das Signifikant ist. Der 95% Konfidenz-Intervall des Mittels beinhaltet jeweils den Wert des anderen Mittels. Das heißt wir sind uns (aufgrund der begrenzten Stichprobe) sicher, dass das wahre Mittel in einem bestimmten Bereich liegt.

Woher stammen denn die Beispieldaten?

von OCBurner, eine Seite vorher.

Könntest Du die einzelnen Werte bitte mal erklären? Dankeschön!

Avg ist der Durchschnittswert

90% Time ist der Interquantils-Intervall in dem 90% der Zeit (nicht der Frames!) verbracht wird. Sehr langsame Frames haben also einen starken Einfluss, wärend schnellere Frames diesen nicht haben.

VarK ist der Variationskoeffizient als Maß für die generelle Streuung (Standardabweichung durch Mittel)

pest

2013-04-03, 20:38:23

Marty98

2013-04-04, 02:01:34

Frame Rating: GeForce GTX 660 Ti and Radeon HD 7950

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-GeForce-GTX-660-Ti-and-Radeon-HD-7950

Ätznatron

2013-04-04, 09:15:15

Frame Rating: GeForce GTX 660 Ti and Radeon HD 7950

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-GeForce-GTX-660-Ti-and-Radeon-HD-7950

Sorry, falls ich da irgendwas verpasst haben sollte, aber was genau haben die CF- und Sli-Beobachtungen eigentlich noch mit dem Thema des Threads zu tun?

So wie ich das verstanden habe, bezieht sich die hier zu Beginn des Threads angesprochene Microstutterproblematik doch ausschließlich auf Single GPUs.

Wenn dafür die Framevarianz ein Indikator sein soll, sehe ich keine (bzw. vernachlässigbare) Unterschiede zwischen AMD und nVidia beim Einzelkartenbetrieb.

Und das schreibt ja auch der Autor in seinem Fazit:

In a very similar result to the HD 7970 and GTX 680 results we launched Frame Rating with, the AMD card here has done well when compared to the GTX 660 Ti in terms of single GPU performance. Both NVIDIA and AMD are doing great with single GPU frame rates, frame times and frame variances,...

MadManniMan

2013-04-04, 09:59:32

Die Ergebnisse von PC Perspective sind ja auch eigene Schlussfolgerungen, nachdem durch den Techreport-Artikel auf die generelle Problematik hingewiesen wurde. Was auch immer dazu geführt hat, aber bei PC Perspective schneiden bisher mit dem vorhandenen Setup alle SGPU-Systeme mustergültig ab; ein paar Ausnahmen (Far Cry 3) mal ein wenig außen vor.

Aber: es ist nur eine Artikelserie, die generell eine andere Vorgehensweise vorschlägt und sich gleichsam auf die Crossfire-Problematik stürzt.
Es gab und gibt jedoch genügend Hinweise darauf, dass vielleicht schon eine andere Spieleauswahl ausreicht, um auch bei Single-GPUs wieder übles Mikroruckeln zu zeigen.

Warten wir es also ein wenig ab!

Ätznatron

2013-04-04, 10:07:48

Es gab und gibt jedoch genügend Hinweise darauf, dass vielleicht schon eine andere Spieleauswahl ausreicht, um auch bei Single-GPUs wieder übles Mikroruckeln zu zeigen.

Also gibt's diesbezüglich nur Vermutungen?

Na ja, dann...

Emploi

2013-04-04, 11:18:07

Ein selbstkritischer Artikel von THG...http://www.tomshardware.de/grafikkarten-framerate-messen,testberichte-241246.html

Iruwen

2013-04-04, 11:43:35

Frame Rating: GeForce GTX 660 Ti and Radeon HD 7950

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-GeForce-GTX-660-Ti-and-Radeon-HD-7950

Alter, :uclap: AMD.

Gipsel

2013-04-04, 12:03:48

Alter, :uclap: AMD.
Man kann jetzt natürlich weiter auf's tote Crossfire-Pferd einschlagen, aber interessant ist auch, daß bei den Einzelkarten AMD typischerweise das etwas bessere Verhalten bei MinFPS und Frametime-Varianz zeigt. Insofern haben sich die Treiberänderungen gegen das Stottern mit Einzelkarten bereits gut bewährt. Jetzt heißt es abwarten, ob in ein paar Monaten bei Crossfire die Änderungen ebenso durchschlagen. Bis dahin wissen wir doch bereits, wie ein Crossfire-SLI-Vergleich ohne VSYNC, Framelimiter oder einer darauf ausgelegten Engine ausgeht.

Ätznatron

2013-04-04, 12:11:39

Ein selbstkritischer Artikel von THG...http://www.tomshardware.de/grafikkarten-framerate-messen,testberichte-241246.html

Als Messtool ausgerechnet das eines Marktteilnehmers und damit Mitbewerbers und Konkurrenten zu nehmen, verbietet sich von selbst.

Emploi

2013-04-04, 12:21:20

Ich finde des Tool nun nicht "so" schlecht. Allerdings ist die 21 Zeilengrenze Quatsch, da fehlen mir persönlich noch 1059 (zu meinem vollständigen Bild) oder mindestens die Hälfte.

Um festzustellen was wirklich raus kommt, muss man die Bilder aufnehmen und auf Veränderungen testen, klingt erst mal logisch. Natürlich kann man hier auch wieder schummeln, indem man ein paar geänderte Punkte einbaut. :hammer:

Skysnake

2013-04-04, 13:07:20

Ein selbstkritischer Artikel von THG...http://www.tomshardware.de/grafikkarten-framerate-messen,testberichte-241246.html
Was ist denn daran bitte "selbstkritisch" da wird FCAT wieder beweihräuchert...

Und dann muss man so was lesen:

wissenschaftlich untermauerten Methoden
DAS ICH NICHT LACHE :down:

Und kurz zuvor schreibt man

Diese Tools sind immer noch nicht völlig ausgereift – beispielsweise konnte das FCAT-Tool mit den Aufzeichnungsdaten einer X79 Express-Plattform nicht korrekt umgehen. Ein Wechsel auf die Z77-Plattform kurz vor Redaktionsschluss rettete aber diesen Benchmark.

Hallo gehts noch?

Da müssten selbst bei jedem LAIEN sofort die Alarmglocken aufschreien, und dazu führen, das man das näher betrachtet. Es gibt nämlich absolut keine rationalen Gründe, warum das passieren sollte. Aber nein, man haut völlig unreflektiert die Ergebnisse raus, und schreibt dann noch was von "wissenschaftlich untermauerten Methoden" :down:

Das ist der blanke Hohn und nicht mehr!

Man weiß einfach viel zu wenig über FCAT, wie es funktioniert, und was wirklich gemacht wird, und je mehr man erfährt, desto mehr Fragezeichen gibt es, statt weniger...

Was soll man den mit solchen Daten anfangen, die nicht interpretierbar/nachvollziehbar sind? Eben rein gar nichts.

Hübie

2013-04-04, 13:14:14

Na es ist wie ich sagte. Wenns wirklich so schlimm wäre, warum sind dann die Foren nicht voll von Threads ala "Es ruckelt trotz hoher fps" etc... ;D
Nichts wird so heiß gegessen wie es gekocht wird. Also warum bitte sollen Alarmglocken schrillen? Wenn ich ein Spiel spiele und hohe fps habe welche sich wie kacke anfühlen DANN schrillen meine Alarmglocken. Kommt manchmal bei fetten AA-Settings in bestimmten Engines vor (trotz 50+ fps).

Akkarin

2013-04-04, 13:18:58

Gibt es eigentlich schon mGPU Tests mit RadeonPro ? TH hatte damit doch (im Gegensatzt zu adaptiv oder normalem VSync) gute Erfolge erziehlt.

Skysnake

2013-04-04, 13:23:16

Weil es keinen rationalen Grund gibt (mir fällt zumindest keiner ein), warum ne X79 Platform zu nicht verwertbaren Daten führt. Und was sind überhaupt nicht verwertbare Daten?

Meint man nur Sie seien nicht verwertbar, und am Ende richtig? Oder sieht man hier einen Fehler im Tool?

Damit hat man sich gar nicht beschäftigt, sondern schlicht unter den Tisch fallen lassen, und so was ist sträflich... So was muss ich IMMER! nachgehen, ansonsten mache ich mich unseriös.

Es zeigt aber mal wieder schon das Problem von FCAT. Völlige Informationslosigkeit, was wirklich abgeht.... :down:

aufkrawall

2013-04-04, 13:24:46

Es zeigt aber mal wieder schon das Problem von FCAT. Völlige Informationslosigkeit, was wirklich abgeht.... :down:
Die Frameabfolge wird markiert. Wieso tust du so, als ob da was nicht ganz koscher wär?

pest

2013-04-04, 13:33:08

Warum stimmen die Frametime Daten nicht immer mit den Frame-Daten? Si ganz koscher scheint das noch nicht zu sein.

Grestorn

2013-04-04, 13:33:44

Man weiß einfach viel zu wenig über FCAT, wie es funktioniert, und was wirklich gemacht wird, und je mehr man erfährt, desto mehr Fragezeichen gibt es, statt weniger...

Man weiß eigentlich sehr genau, wie FACT funktioniert, insbesondere wie die Daten ermittelt werden. Das hat techreport alles haarklein beschrieben.

Eigentlich recht wasserdicht.

Der Code, der die Frames mit dem farbigen Rahmen versieht, ist die einzige Stelle an der die Messung theoretisch verfälscht werden könnte. Genau das wurde aber durch techreport experimentell als unproblematisch festgestellt. Außerdem wird dieser Teil in Bälde auch von Tools wie Precision X erledigt werden können, die nicht von nV kommen.

Alles was danach passiert ist einfach eine nachvollziehbare Auswertung der Messergebnisse. FACT ist ja - abgesehen von dem Einfärben - nichts anderes als eine Sammlung von Scripten, die die Rohdaten aufbereiten. Und es ist alles offengelegt.

Du kannst Dir Deine Paranoia also sonst wo hinstecken. Lies lieber erst mal, bevor Du solchen Unsinn behauptest.

Skysnake

2013-04-04, 13:34:34

Weil eben nur durch eine Farbtabelle iteriert wird, obwohl es ein leichtes wäre, das mit der CPU-time zu syncen....

Man lässt einfach unnötigerweise Information über das System ungenutzt. Und so nen Zeitabfrage über RDTSC ist VERDAMMT schnell. Das sind nur einige 10 oder 100 Takte. Mehr ist das nicht. Also quasi nichts.

@Grestorn:
Da ist absolut GAR NICHTS klar. Man hat ne groben Testaufbau skiziert, aber das wars auch schon.

Es gibt unmengen an Fragen:

Wo ist der Quellcode
Warum gibt es mit X79 Probleme
Wie wirken sich die Taktraten der CPU aus
Wie wirken sich die Taktraten des Speichers aus
Wie wirkt sich die Kernanzahl der CPU aus
Wie wirkt sich die Cachegröße der CPU aus
Welche Hintergrundprogramme laufen
Welche Treiberversionen werden verwendet
Gibt es unterschiede zwischen diesen?
Wie stark streuen die Einzelmessungen der gleichen Szene
Wie erfolgt das Aufteilen der Frames im Splitter? Bei THG wird ja wohl etwas aktiver verwendet und nicht nur eine Kabelpeitsche
Warum iteriert man nur über eine statische Farbtabelle
Was passiert, wenn ich ne Dual-GPU-Karte verwende, statt zwei Single-GPUs
Was ist wenn ich unterschiedliche Hostsysteme verwende (Ganz neu wegen der X79 Problematik)
Warum gibt es da teils Probleme
Werden Frames nun absichtlich verzögert oder nicht
Wie wird genau das Overlay eingefügt
Wie performant ist das Einfügen
Erfolgt es wirklich an der selben Stelle für beide Hersteller, oder funken einem da die Treiber dazwischen
Was passiert wirklich dann in den Treibern, kann ich verifizieren, dass diese nicht nochmals etwas manipulieren? verzögern oder what ever
Wie sieht es z.B. mit den letzten 2-3 Generationen (also alle DX11 Karten) aus, gibt es hier Unterschiede?

Das ist jetzt nur mal eine "kurze" Auflistung, der brennendsten Fragen, die mir in den Sinn gekommen ist. Darauf gibt es aber keine echten Antworten.

Insbesondere der Quellcode muss halt veröffentlich werden, und das X79 Problem gelöst werden. Vorher braucht man sich die Daten gar nicht weiter ansehen. Da kann ja der Teufel was für Effekte auftreten.

Iruwen

2013-04-04, 13:35:19

Ich weiß jetzt zwar nicht welche geheimen Voodootricks es da noch geben soll die so unverständlich und intransparent sind, wundere mich aber an der Stelle auch dass es Probleme mit der X79 Plattform gibt - vor allem verwendet PC Per auch ein ASUS P9X79 Deluxe Board.

Grestorn

2013-04-04, 13:35:48

Warum stimmen die Frametime Daten nicht immer mit den Frame-Daten? Si ganz koscher scheint das noch nicht zu sein.

Welche Daten meinst Du genau? Dass die Zeiten an den veschiedenen Messpunkten nicht immer exakt übereinstimmen ist doch der Witz und der Grund für das Verfahren. Sonst hätte man ja gleich bei FRAPS bleiben können.

Grestorn

2013-04-04, 13:37:46

N0Thing

2013-04-04, 13:52:01

Sorry, falls ich da irgendwas verpasst haben sollte, aber was genau haben die CF- und Sli-Beobachtungen eigentlich noch mit dem Thema des Threads zu tun?

So wie ich das verstanden habe, bezieht sich die hier zu Beginn des Threads angesprochene Microstutterproblematik doch ausschließlich auf Single GPUs.

Ruckler bei einzelnen Karten sind z.B. auch bei den PCPER Tests unter Skyrim weiterhin zu sehen. Sowohl bei Nvidia als auch AMD. Allerdings handelt es sich nicht um durchgehende Ruckler, sondern es liegen Pausen von mehreren Sekunden dazwischen.
Bei Far Cry 3 zeigen die Graphen eher das, was man µRuckler nennen könnte. Erstaunlich dabei ist, daß GTX 680, HD 7950 und GTX 660TI keine Probleme haben, eine HD 7970 dagegen deutliche und auch eine GTX Titan sieht etwas schlechter aus als die drei erstgenannten Karten.

Skysnake

2013-04-04, 14:06:57

Du hast überhaupt nicht verstanden, was hier gemacht wird. Nur über die farbliche Markierung und die AUFNAHME der erzeugten Bildfolge über einen EXTERNEN PC kann man überhaupt nachweisen, was der Anwender letztlich tatsächlich zu sehen bekommt.

Über eine Messung am TestPC selbst kriegt man das derzeit überhaupt nicht hin, und wenn dann nur durch einen Eingriff in den Treiber selbst, der Messpunkte bei jedem Framewechsel erzeugen müsste.
DU verstehst mich hier gerade nicht ;)

Mir ist absolut klar, wie das Verfahren funktioniert.

Du solltest aber nochmals nachlesen, dass ich die statische Farbtabelle kritisiere, die nur 16(?) Farbwerte kennt, und bei der man jedem neuen Frame einen neue Farbe gibt. Dabei spielt es keine Rolle, ob der Frame 1µs oder 1Jahr nach dem letzten kommt. Er bekommt immer die selbe Farbe.

Es wäre aber, wie schon mehfach gesagt, ein leichtes die zur Verfügung stehenden 2^32 Werte (32 Bit Farbwerte halt) zu nutzen, um eine zeitliche Skalierung zu erhalten. Man bestimmt die Zeit eines Frames, setzt ihn z.B. Schwarz (Binär nur 0er) und misst beim nächsten Frame wieder die Zeit, und für alle x µs zählt man halt um 1 hoch. Damit kann man dann eben die Farbwerte für eine Farbcodierung nutzen. Wenn man jetzt noch nur Binär 1er (Weiß) ausschließt, dann kann man damit ja sogar noch triggern, wenn zwei Frames länger als eben zu lange auseinander liegen, und man so einen überlauf erhält.

Tut man aber nicht, dabei ist es SCHEIS egal! für die Auswertung. Man sollte ja Digitaldaten loggen und keine Analogdaten (Meines wissens nach). Und wenn nicht, muss man halt HDMI oder DP verwenden, die sind auf jeden Fall digital.

Damit könnte man dann eben auch sehen, ob Frames unterschiedlich lange in der Pipeline brauchen. Sprich ob Sie eventuell verzögert werden, aus welchen Gründen auch immer! Das wäre SEHR interessant. Macht man aber nicht.

Warum nur? :rolleyes:

Und auch an dich, wie erklärst du mir dann bitte die Probleme mit dem X79 System, und wie sehen die überhaupt genau aus?
Und ist das jetzt ein Problem der X79 Platform, oder ist es ein Problem von FCAT? Oder ist es ein Problem der Aufzeichnung, oder oder oder.

pest

2013-04-04, 14:08:58

Welche Daten meinst Du genau? Dass die Zeiten an den veschiedenen Messpunkten nicht immer exakt übereinstimmen ist doch der Witz und der Grund für das Verfahren. Sonst hätte man ja gleich bei FRAPS bleiben können.

entspann dich, ich rede davon, dass die Daten die die FCAT Skripte ausspucken nicht konsistent sind.

Gipsel

2013-04-04, 14:12:34

@Skysnake:
Yup, das wäre eine direkte Messung der Varianz der Zeiten zwischen dem present() und dem eigentlichen Bufferflip, also den Teil, für den die Treiber und das OS verantwortlich sind. Und man hätte dann praktisch die Fraps-Daten framegenau synchronisiert dazu. Verstehe ich auch nicht, warum man das nicht macht.

Skysnake

2013-04-04, 14:19:16

Jetzt meine rein subjektive Vermutung dazu:

Ich vermute mal, das man dadurch einfach offenlegen würde, das nVidia hier eben auch nur mit Wasser kocht, und "einfach" die Frames verzögert ausgibt.

Und in der Situation müsstest du eben nur warten, bis die ersten aus ihren Löchern gekrochen kommen, die meinen, Sie würden das selbst an nem 120Hz Monitor noch bemerken :rolleyes:

Das ist leider so. Egal ob es wirklich so ist, es wird genug Leute geben, die sich einreden werden, Sie würden es merken, und den Shitstorm will man sich gar nicht überlegen.

nVidia hat hier meiner Meinung nach daher wirklich mal wieder perfektes Marketing praktiziert, und die ganzen Redaktionen vor ihren Karren gespannt, ohne dass diese das überhaupt gemerkt haben :(

Ansonsten THX Gipsel, dass du das nachvollziehen kannst was ich meine. Ich hab so langsam wirklich angefangen an mir zu zweifeln, dass ich wirklich einen EXTREMEN Denkfehler habe. Denn das ist mir binnen weniger Minuten aufgefallen, als ich mich dann doch mal ernsthaft mit FCAT beschäftigt habe, da die "Sau" einfach von jedem durchs Dorf getrieben wurde.

HarryHirsch

2013-04-04, 14:23:49

ich versteh zwar nur bahnhof, aber der code ist doch offen.
kann man den nicht anpassen?

Skysnake

2013-04-04, 14:26:08

Wo ist er offen?

Ich hab selbst nach intensiver Suche noch immer keinen Quellcode gefunden, nur bei THG die Aussage "alles" wäre offen. Nur blöd, wenn man es eben nicht bekommt :ugly:

Emploi

2013-04-04, 14:30:19

Was ist denn daran bitte "selbstkritisch" da wird FCAT wieder beweihräuchert...
...
Ich habe die erste Seite gelesen und dann den Hyperlink hier beigetragen. Im Nachhinein tauchen dann doch mehr Fragen als Antworten auf. :biggrin:

Mach dich mal locker, was quelloffenes habe ich auch noch nicht gefunden. Vielleicht liegt es offen ausgedruckt auf dem Schreibtisch eines THG Mitarbeiters.. :cool:

Skysnake

2013-04-04, 14:32:37

Mich kotzen halt einfach dieses ganze Behauptungsgerüst um FCAT so langsam ziemlich an.

Besonders der THG Artikel mit seinem "wissenschaftlich untermauerten Methoden" bringt mich halt echt zur Weißglut! Das hat nämlich nichts aber auch wirklich rein gar nichts mit Wissenschaft und deren Methoden zu tun...

Als jemand, der in der Wissenschaft tätig ist, und auch dort bleiben will, ist das schon fast eine Beleidigung...

Emploi

2013-04-04, 14:35:59

Wissen vor Acht suggeriert auch Wissenschaft. Da regt sich auch keiner auf. Du bist sehr dünnhäutig Skysnake.

kruemelmonster

2013-04-04, 14:36:32

@skysnake:

Wissenschaftliche Methoden gut und schön, aber du übertreibst imho maßlos. Keine der Redaktionen die mit dem Tool arbeiten haben Zweifel an seiner Validität gebracht. Es wäre für NV auch selten dämlich zwei Jahre lang an dem Programm zu arbeiten und dann bei den Ergebnissen zu cheaten. Sofern das rauskommen würde nutzt es kein Mensch mehr, zwei Jahre Arbeit fürn Lokus obwohl beide IHVs mit Fraps nicht glücklich sind.
Desweiteren hat NV seit dem NV40/G70-AF technisch nicht mehr gecheatet (Namenskuddelmuddel zählt nicht, da nehmen sich beide nix) und sich sogar öffentlich dazu bekannt (http://blogs.nvidia.com/2010/11/testing-nvidia-vs-amd-image-quality/) auf die AMD 5k/6k BQ-Abwärtsspirale nicht einzugehen auch wenn es dadurch mit der Performance nicht weiter bergauf gehen sollte.
Bzgl. X79 würde ich nicht so ein Fass aufmachen, dass Exotenhardware nicht auf jeder Plattform läuft ist nichts neues, gerade bei den X-Chipsätzen (hab den X38 immer noch in schmerzlicher Erinnerung)...evtl wurde die Capture-Karte in einen per PLX angebundenen PCIe-Slot gesteckt und mag die entstehende zusätzliche Latenz nicht...wer weiß, die Capture Card kommt ja nunmal nicht von NV, das kannst du ihnen nicht anlasten.
Davon ab, wie Grestorn schon schrieb wird das DX-Overlayhook in künftigen Version von Fraps sowie MSI AB/EVGA PX Einzug halten, so dass das einzige NV-Programm dann noch der Extractor ist welcher das Video analysiert und die Farbverteilung der Frames auswertet.
Woher das Programm nun wissen soll ob das zu analysierende Video mit einer Radeon oder einer GeForce gemacht wurde darfst du mir gern erklären.
Man ist solange unschuldig bis seine Schuld bewiesen ist - und hier sehe ich ganz ohne Paranoia oder Fanboy-Brille keine Indizien das da was faul sein soll...auch wenn's von NV kommt. ;)

Grestorn

2013-04-04, 14:39:15

Dass Du weiß glühst ist offensichtlich.

Aber was Du schreibst macht wenig Sinn.

Ziel der Messung ist nicht festzustellen, wo die Zeit genau verloren geht. nVidia weiß das sicher selbst (die haben Messpunkte im Treiber). AMD scheint da eher ahnungslos zu sein (ihrer eigenen Aussagen nach).

Das Ziel der Messung ist klar festzustellen, wie viele Frames beim Anwender letztlich sichtbar werden und wie groß der zeitliche Abstand zwischen den sichtbar gewordenen Frame ist. Unterhalb einer gewissen Grenze (ziemlich willkürlich auf "21 Zeilen" festgelegt) gilt das Frame als wertlos.

Aber selbst wenn man diese Grenze außer acht lässt, kann man immer noch die regelmäßigkeit der Frames feststellen, dazu reicht der statische Farbvorrat absolut aus. Man kann Messen, wie lange ein Frame auf dem Monitor dargestellt wird, und das ist das einzige, was zählt.

Im besten Falle ist die Zeit, die jedes Frame stehen bleibt, exakt genau gleich. Dass das nicht geht, ist klar. Aber es sollten keine zu großen Abweichungen passieren, weder nach oben (Stottern) als auch nach unten (unnütze, nicht sichtbare Frames).

Nicht mehr und nicht weniger sagt die Messmethode aus. Dein Gezetere dagegen wirkt ehrlich gesagt nicht wirklich echt sondern ziemlich aufgesetzt.

N0Thing

2013-04-04, 14:46:26

Wo ist er offen?

Ich hab selbst nach intensiver Suche noch immer keinen Quellcode gefunden, nur bei THG die Aussage "alles" wäre offen. Nur blöd, wenn man es eben nicht bekommt :ugly:

Ich glaube im ersten PCPER-Artikel oder in dem 20 Minuten Video wird erklärt, daß Nvidia den Redaktionen den Quelltext offen gelegt hat und von Ryan Shrout über das letzte Jahr mehrmal durchgesehen wurde und keine Anzeichen für Cheaten oder ähnliches gefunden wurden.
Daß der Quellcode nicht für die Öffentlichkeit zugänglich ist liegt daran, daß Nvidia in ihrer Version lizenzierte Patente benutzt. Also vergleichbar mit den proprietären Grafiktreiber unter Linux und deren quelloffenen Ablegern.
Deshalb müssen die Entwickler von Afterburner, Fraps & co auch ihre eigenen Hooks für die Farbcodierung programmieren.

Skysnake

2013-04-04, 15:32:39

@skysnake:

Wissenschaftliche Methoden gut und schön, aber du übertreibst imho maßlos
Nö, es gibt aber gewisse Mindestandards für wissenschaftliches Arbeiten, und wenn sich Leute damit schmücken, Sie würden wissenschaftlich arbeiten, dann sollten Sie WENIGSTENS diese einhalten...
Das ist wie nen geklauter Doktortitel...
Einfach nur um mehr Eindruck zu schinden, mehr nicht...

Keine der Redaktionen die mit dem Tool arbeiten haben Zweifel an seiner Validität gebracht. Es wäre für NV auch selten dämlich zwei Jahre lang an dem Programm zu arbeiten und dann bei den Ergebnissen zu cheaten. Sofern das rauskommen würde nutzt es kein Mensch mehr, zwei Jahre Arbeit fürn Lokus obwohl beide IHVs mit Fraps nicht glücklich sind.

Wieviele davon haben denn nur im Ansatz überhaupt die Leute mit dem entsprechenden know-how um das zu prüfen und zu verstehen?

Ich hab echt VIEL Ahnung in dem Bereich, aber ich weiß, dass ich bei WEITEM NICHT genug Ahnung habe, um da wirklich akkurat drüber zu schauen. Überhaupt einen Einzelnen zu finden, der alle Aspekte, die es zu berücksichtigen gibt überblicken kann wird wohl ziemlich schwierig. Das Zeug ist halt echt HARTER Tobak. Deswegen sollte man so etwas auch wirklich komplett offen legen. Wenn da 20, 30, 100 oder auch 1000 Leute drüber schauen, dann kann man sich halbwegs sicher sein, dass das vernünftig ist, was da gemacht wird, und keine Brainfarts drin stecken.

Desweiteren hat NV seit dem NV40/G70-AF technisch nicht mehr gecheatet (Namenskuddelmuddel zählt nicht, da nehmen sich beide nix) und sich sogar öffentlich dazu bekannt (http://blogs.nvidia.com/2010/11/testing-nvidia-vs-amd-image-quality/) auf die AMD 5k/6k BQ-Abwärtsspirale nicht einzugehen auch wenn es dadurch mit der Performance nicht weiter bergauf gehen sollte.

Nochmal, ist ein zurückhalten eines fertigen Frames "cheaten"? Sie thematisieren es nicht, und die Leute tun so, als ob nVidia zaubern könnten, und dieser Aspekt wird VÖLLIG ausgeklammert, bzw von genug Leuten verneint. Das suggeriert ein eventuell völlig falsches Bild. nVidia cheatet oder belügt da bei nicht direkt, aber an gewissen Punkten einfach nichts zu sagen, und das Mäntelchen des Schweigens drüber zu legen kommt manchmal auf das Selbe raus am Ende...

Bzgl. X79 würde ich nicht so ein Fass aufmachen, dass Exotenhardware nicht auf jeder Plattform läuft ist nichts neues, gerade bei den X-Chipsätzen (hab den X38 immer noch in schmerzlicher Erinnerung)...evtl wurde die Capture-Karte in einen per PLX angebundenen PCIe-Slot gesteckt und mag die entstehende zusätzliche Latenz nicht...wer weiß, die Capture Card kommt ja nunmal nicht von NV, das kannst du ihnen nicht anlasten.

Nochmal, so wie es aussieht, ist das TEST-System, nicht das Capture-System gemeint. TGH drückt sich hier leider nicht 100% klar aus, aber zu >90% kann man davon ausgehen, dass das X79 einfach die Ausgabe machen sollte, und NICHT die Bildern aufzeichnen sollte. Es gibt also wirklich absolut keinen Grund, warum es zu Problemen kommen sollte.

Und wenn doch, bedeutet das etwa, das ein X79 System völlig ungeeignet ist für Multi-GPU??? DAS wäre doch eine OMFG-WTF DIE WELT GEHT UNTER!!!!111einself Nachricht wert. Gerade High-End-Multi-GPU user setzen ja eher auf S2011.

Hast du ne Ahnung, was das für ne OMFG-Story werden könnte, und THG macht daraus nicht mehr als einen Halbsatz?
Und gleichzeitig trauen wir ihnen aber zu Programmcode zu analysieren und bewerten? Na ne ist klar :freak:

Davon ab, wie Grestorn schon schrieb wird das DX-Overlayhook in künftigen Version von Fraps sowie MSI AB/EVGA PX Einzug halten, so dass das einzige NV-Programm dann noch der Extractor ist welcher das Video analysiert und die Farbverteilung der Frames auswertet.

Und das ändert jetzt was daran, das man keine Ahnung hat, wie das wirklich schon statten geht, und welche NEGATIVEN Seiteneffekte damit eventuell ausgelöst werden?

Kleines Beispiel:
Für GPU-Direct kannst du die Latenzen teils MASSIV! dadurch reduzieren, dass du ne 10€ GPU für die Bildausgabe des Systems verwendest, mit dem du die Messdaten darstellst....

Ich hatte das Glück, an einem GPU-Direct Projekt etwas mitarbeiten zu dürfen, bei dem man sehr tief in den nVidia Treiber einsteigt. Und ich kann dir sagen, das Zeug ist echt harter Stoff...

Woher das Programm nun wissen soll ob das zu analysierende Video mit einer Radeon oder einer GeForce gemacht wurde darfst du mir gern erklären.
Man ist solange unschuldig bis seine Schuld bewiesen ist - und hier sehe ich ganz ohne Paranoia oder Fanboy-Brille keine Indizien das da was faul sein soll...auch wenn's von NV kommt. ;)
Muss es das?
Nö, für was gibt es den Treiber? :ugly:

Aber was Du schreibst macht wenig Sinn.

Für Gipsel offenbar schon...

Ziel der Messung ist nicht festzustellen, wo die Zeit genau verloren geht. nVidia weiß das sicher selbst (die haben Messpunkte im Treiber). AMD scheint da eher ahnungslos zu sein (ihrer eigenen Aussagen nach).

Das würdest du damit auch nicht. Du würdest nur sehen, ob eben gravierende Unterschiede auftauchen, die mit sauberen Frametiemes korrelieren. Du hast es scheinbar noch immer nicht verstanden, ich weiß allerdings nicht mehr, wie ich es noch erklären soll :(

Gipsel kannst du es mal versuchen? Du schaffst es deutlich besser derartige Sachen leicht verständlich darzustellen als ich. Ich bin in sowas total untallentiert leider ;D

Das Ziel der Messung ist klar festzustellen, wie viele Frames beim Anwender letztlich sichtbar werden und wie groß der zeitliche Abstand zwischen den sichtbar gewordenen Frame ist. Unterhalb einer gewissen Grenze (ziemlich willkürlich auf "21 Zeilen" festgelegt) gilt das Frame als wertlos.

Richtig, aber ist es nicht etwas scheinheilig, die Methode, wie das erreicht wird (bewusst?) auszuklammern und nicht zu untersuchen? Ein Schelm wer böses dabei denkt :rolleyes:

Und die womöglich komplett falschen Aussage bzgl Latenz lässt man eben unkommentiert. Was kann man denn dafür, dass die Leute nicht lesen können, und anfangen sich irgendwelchen "Scheis" zusammen zu fantasieren? :rolleyes:

Das man aber durch seine absolut bescheidene Art und Weise der Kommunikation und Offenheit genau das provoziert, blenden wir mal lieber aus...

Aber selbst wenn man diese Grenze außer acht lässt, kann man immer noch die regelmäßigkeit der Frames feststellen, dazu reicht der statische Farbvorrat absolut aus. Man kann Messen, wie lange ein Frame auf dem Monitor dargestellt wird, und das ist das einzige, was zählt.

Und durch was werden diese erreicht? Und erkauft man sich das nicht eventuell durch andere Nachteile? Und wenn ja, warum merkt man davon nichts? Oder merkt man es doch teils, man stellt aber nur nicht die Verbindung dazwischen her bisher?

Im besten Falle ist die Zeit, die jedes Frame stehen bleibt, exakt genau gleich. Dass das nicht geht, ist klar. Aber es sollten keine zu großen Abweichungen passieren, weder nach oben (Stottern) als auch nach unten (unnütze, nicht sichtbare Frames).

Nicht mehr und nicht weniger sagt die Messmethode aus. Dein Gezetere dagegen wirkt ehrlich gesagt nicht wirklich echt sondern ziemlich aufgesetzt.
Die Messmethode ist eben völlig unzulänglich für die Genauigkeit der Messung.

Das ist als ob man die VMax eines Autos messen will mit Laserschranken, und super duper Messinstrumenten, die auf ein Millionstel km/h messen können, dabei aber völlig vergisst nach zu schauen, ob ich jetzt 30% Steigung/Gefälle oder ne Ebene habe. Ganz zu schweigen vom Wind...

Ich glaube im ersten PCPER-Artikel oder in dem 20 Minuten Video wird erklärt, daß Nvidia den Redaktionen den Quelltext offen gelegt hat und von Ryan Shrout über das letzte Jahr mehrmal durchgesehen wurde und keine Anzeichen für Cheaten oder ähnliches gefunden wurden.
Daß der Quellcode nicht für die Öffentlichkeit zugänglich ist liegt daran, daß Nvidia in ihrer Version lizenzierte Patente benutzt. Also vergleichbar mit den proprietären Grafiktreiber unter Linux und deren quelloffenen Ablegern.
Deshalb müssen die Entwickler von Afterburner, Fraps & co auch ihre eigenen Hooks für die Farbcodierung programmieren.
Dann kann man aber nicht von "quelloffen" reden. Das ist alles nur nicht offen... :down:

In dem Fall ist es eine Frechheit damit zu werben, denn nichts anderes ist es, denn (quell)offen suggeriert eine Unabhängigkeit und Überprüfbarkeit, die eben hier wohl nicht gegeben ist. Man schmückt sich also mit falschen Federn.

Wohin muss ich mich also wenden, um selbst den Quellcode einzusehen? So ist das einfach EXTREM unseriös. Das muss von unabhängiger stelle geprüft werden, und nicht von Leuten, die wohl weder das Know-how noch die Zeit dafür haben, um das anständig zu prüfen. Ganz zu schweigen, das man da auch aufpassen muss, was man macht. Immerhin hat nVidia auch schon Redaktionen von der Sample-liste gestrichen in der Vergangenheit...

Ich hoffe du verstehst was ich meine.

M4xw0lf

2013-04-04, 15:45:08

Die FCAT-Tests die auf den letzten Seiten verlinkt wurden, zeigen alle so gut wie überhaupt kein Single-GPU microstuttering. Witzig, wo das doch das ursprüngliche Thema dieses Threads war.

Iruwen

2013-04-04, 15:54:38

Um das nochmal kurz aufzugreifen - PC Per verwendet ebenfalls eine X79 Plattform. Sind deren Werte dann korrekt? Das passt ja nicht mit der Aussage von THG zusammen dass damit falsche Werte ausgegeben werden.

Skysnake

2013-04-04, 16:12:54

Ja, das passt absolut nicht zusammen. :ugly:

Aber hey, ich gewisse Leute versuchen mir ja immer paranoidität vorzuwerfen :ugly:

Is klar ne...

Und jetzt bekommt man um die Ohren geworfen, dass der eine super duper tolle Messergebnisse mit System A hat, und FRAPS ja der letzte "Dreck" ist, der nichts taugt, und einige Zeit später sagt der nächste, ach übrigends, System A produziert nur Müll.. :ugly:

Aber hey, wir glauben mal irgendwelchen Werten, die man gar nicht validieren kann blind ;D

HarryHirsch

2013-04-04, 16:15:50

ich find das ganze gar nicht so übel, immerhin hat amd dank nv festgestellt das sie irgendwo leistung liegen lassen.
next horny incoming. :freak:

Skysnake

2013-04-04, 16:19:01

Oder Sie verschlimmbessern etwas, nur um in dem Test gut da zu stehen :ugly:

OC_Burner

2013-04-04, 16:24:56

Vielleicht sollte man die Werte noch nicht so für voll nehmen, irgendwas stimmt hier noch nicht - oder ich verstehe die Bedeutung nicht

@OCBurner
Ich berechne gerade die Frametimes aus der "framestart" Spalte
bei Titan@Heaven steht bei
Frame 125: time: 17,08ms, framestart: 2,097s
Frame 126: time: 17,14ms, framestart: 2,183s

Wenn ich jetzt aber die frametime mit Hilfe von framestart berechne kommt (2,183-2,097)*1000=86ms raus???

Bei den meisten anderen Frames stimmt die Rechnung mit den Tabellenwerten überein?!

Ganz klar ist mir auch nicht warum die Werte bei genau diesen beiden Frames nicht stimmen.

Ganz klar ist mir außerdem auch nicht, warum z.B. in den SLI Benchmarks der 690 teils extreme Ausreißer auftreten. Manche Frames haben da eine Dauer von gerade mal 0.01ms. Leider sind die Originalvideos nicht mehr vorhanden um genauer nachschauen zu können. Morgen oder Übermorgen probiere ich nochmal ein paar neue aufzunehmen. Es gab übrigens tatsächlich verlorene Frames während der Aufnahme, allerdings nur im Stalkerbench. Das externe Aufnahmesystem arbeitet so ziemlich an der Kotzgrenze. Besteht eigentlich von irgendwem Interesse an ein verlustloses und eingefärbtes Video zum selber analysieren?

N0Thing

2013-04-04, 16:27:45

Ich hab echt VIEL Ahnung in dem Bereich, aber ich weiß, dass ich bei WEITEM NICHT genug Ahnung habe, um da wirklich akkurat drüber zu schauen. Überhaupt einen Einzelnen zu finden, der alle Aspekte, die es zu berücksichtigen gibt überblicken kann wird wohl ziemlich schwierig. Das Zeug ist halt echt HARTER Tobak. Deswegen sollte man so etwas auch wirklich komplett offen legen. Wenn da 20, 30, 100 oder auch 1000 Leute drüber schauen, dann kann man sich halbwegs sicher sein, dass das vernünftig ist, was da gemacht wird, und keine Brainfarts drin stecken.

Wenn du keinen Einblick in den Quellcode hast, kannst du auch nicht behaupten wie groß der Aufwand für dessen Überprüfung sein würde, oder?
Auch wenn du mal tief in den Nvidiatreiber eingestiegen bist und das ganz harter Tobak war, reden wir hier nicht über Modifikationen am Treiber, sondern über ein overlay samt hook.

Dann kann man aber nicht von "quelloffen" reden. Das ist alles nur nicht offen... :down:

In dem Fall ist es eine Frechheit damit zu werben, denn nichts anderes ist es, denn (quell)offen suggeriert eine Unabhängigkeit und Überprüfbarkeit, die eben hier wohl nicht gegeben ist. Man schmückt sich also mit falschen Federn.

Wohin muss ich mich also wenden, um selbst den Quellcode einzusehen? So ist das einfach EXTREM unseriös. Das muss von unabhängiger stelle geprüft werden, und nicht von Leuten, die wohl weder das Know-how noch die Zeit dafür haben, um das anständig zu prüfen. Ganz zu schweigen, das man da auch aufpassen muss, was man macht. Immerhin hat nVidia auch schon Redaktionen von der Sample-liste gestrichen in der Vergangenheit...

Ich hoffe du verstehst was ich meine.

Dafür, daß du aus der Position des Wissenschaftlers argumentierst, gehst du sehr sorglos mit den vorhandenen Quellen um. Daß FCAT open source wäre, wurde nirgendwo behauptet, sondern nur gesagt, daß der Quelltext für bestimmte Personen zur Einsicht vorliegt, unter anderem den Redaktionen, die an der Entwicklung des Versuchsaufbaus beteiligt waren.
Des weiteren wurde gesagt, daß man für die Zukunft auf die open source community für das overlay setzen will, eben weil Nvidia den Quellcode nicht der Öffentlichkeit zugänglich machen kann. Daneben will PCPER alle Scripte die zur Auswertung verwendet werden offen legen (haben sie das schon gemacht?).

Zum nachlesen:
http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Dissected-Full-Details-Capture-based-Graphics-Performance-Testin
die letzten beiden Absätze.

Du könntest, anstatt hier basierend auf reinen Vermutungen deine Behauptungen und Thesen zu verbreiten, ja dich mit PCPER in Verbindung setzen und deine Ideen zur genauen Messung der Frametimes übermitteln, damit die Untersuchung noch tiefer gehen kann.
Das wäre doch mal ein Handeln im wissenschaftlichen Sinne und eine Bereicherung für die Leser und Tester.