Benchmarking: Was hinter FCAT steckt und die Konsequenzen für Hardwareluxx

[Maximusprime]

Ich versteh den Zusammenhang zwischen Frage und Zitat nicht, aber vielleicht meintest du ja das mit dem Delta_t zwischen ingame und Anzeige-time.

Das kannst du nur klein halten, wenn deine Renderzeit kleiner als dein Zeitintervall für die Ausagbe ist. Also Minimum-FPS von >60 FPS. Dann kannst! du das so machen, dass du eben immer genau das gleiche Zeitintervall von 1/60s renderst. Jedes mal wenn du aber länger als 1/60s für das Rendern eines Bildes brauchen würdest, müsstest du den Rendervorgang abbrechen und dein Glück aufs neue Versuchen. Sprich du plättest das "Problem" einfach durch ne Worstcase-Abschätzung, und da die Worstcase-Situationen eben mal locker 50% unter dem AVG-FPS liegen, brüchtest du also Situationen, wo du im AVG-FPS sicherlich mit >120FPS rumrennen würdest. Für nen 120Hz Monitor müssten es dann natürlich 240 FPS sein, wenn man von den 50% ausgeht :ugly:

Nein sehe ich nicht so, zum einen haben wir keine Vergleichswerte für T-Game sondern nur zu T-present und hier könnte man ja schon eingreifen von Seite des Grafiktreibers weil man einfach den Call verzögern könnte, wie willst Du das messen? Als Referenzwert hat man ja nur T -present , an der Stelle an der auch FRAPS misst. Und du gehst von einem fixen Zeitinterval aus, was aber nicht zwingend sein muss, oder?

Ok, etwas blöd ausgerügt. Ich hatte Output-Lag sagen müssen, das triffts besser. Ich wüsste aber nicht, wie man das in der Form wie FCAT es macht, messen will. Du willst ja keinen Relativen Lag messen, sondern einen absoluten, da die Ausgabe, jetzt völlig unabhängig von dem, was der Bildschirm nochmals dazu generiert erfolgt. Du musst also ein Bild mit ner Timemark versehen. Bedenkt man, wie FCAT es Misst, solltest du sogar alle 10 Zeilen oder so die Timemark sogar erneuern, damit du die Information auch wirklich immer hast. Alles nicht so wirklich einfach. Deswegen sollte man sich auch nen synthetischen Bench überlegen, der theoretisch auch 1k FPS oder mehr schaffen kann, damit man gezielt die Frames verzögern/beschleunigen kann, um zu sehen, wie das System darauf reagiert.

Z.B. einfach eine Bitmap rendern, die sich fortlaufend wiederholt, und eben die Zeitmarke alle 20/10 Zeilen enthält. Am Anfang wird einfach durchgerendert. Da solltest du so um die 1k+ FPS erreichen. Dann tastest du dich mal an die 60 FPS ran, indem du einfach nen Sleep(x) reinpackst. Wenn du den Wert hast, machst du einfach folgendes. Du alternierst immer zwischen Sleep(x) und Sleep(x*0.25). Damit generierst du also sehr unsymmetrische Frames. Diese Ungleichverteilung muss sich dann auch in FCAT zeigen. Tut Sie es nicht, dann wird das bereits fertig gerenderte Bild [Sleep(x*0.25)] zurückgehalten. Wenn das passt, sollte man noch alle 5/10/20/30/60/120/240/600 Frames einen schnellen [Sleep(x*0.25)] Frame einwerfen. Da kann man dann testen, ob man sich an irgendwelchen Medianwerten orientiert.

Um das auf zuzeigen was du vorhast wäre es aber wohl besser Sleepsequenzen einzubauen um dann zu sehen wo der Schwellenwert liegt, ich bin sicher das hier mit Medianwerten gearbeitet wird alles andere wäre Wahnsinn.aber auch hier würde eine Verzögerung des Calls die Meßbarkeit zumindest mit den uns zur Verfügung stehenden Mitteln faktisch unmöglich machen oder übersehe ich da was? Du müsstest in diesem Fall ja zuerst mal ermitteln wie groß die Latenz zwischen T-game und T-present ist und auch hier ist eine Abhängigkeit zum Call gegeben wie man wiederum bei Fraps Messungen sehr gut sehen kann, leider ist das nicht so einfach.
Sonst währ es ja so, dass FRAPS Messungen auf beiden Karten gleich aussehen würden nur hinten was anderes rauskommt. Dem ist jedoch nicht so, Es besteht schon eine gewisse Abhängigkeit zwischen dem was Fraps vermessen tut und den Ergebnissen die FCAT ausgibt um hier mal Pest aus dem 3DC zu zitieren, " Nen Variationskoeffizient von 50% wird sich auch durch Framepacing nicht magisch in Luft auflösen" Gemeint sind hier die Werte die sich aus einer Fraps-Messung ergeben und mit Frapo das Tool von Pest aufbereitet werden.

Mal ein ganz anderer Ansatz ;-) PRAD | Reportage: Inputlag der auf Seite 9 und 10 durchaus auch bei dem Meßverfahren mit FCAT Fragen aufwerfen könnte, denn wer von uns kann schon mit absoluter Sicherheit sagen ob hier selbst bei VSync nicht Abweichungen vorliegen die wir nicht auf dem Schirm haben interessant währe in diesem Zusammenhang auch mal eine Vermessung von zwei Fire Pro Karten. Denn die Messung (Aufzeichnung) und die Ausgabe auf den Monitor erfolgt bei PCper nicht am gleichen Ausgang das wird zumindest mal so beschrieben in der Erklärung des Testverfahrens. Bitte nicht von dem Titel abschrecken lassen ich habe das schon geschnallt mit dem Outputlag aber wenn ein Monitor ein Inputlag von 0 hat ist dies auch gleichzeitig das Outputlag der Grafikkarte Mach Dir mal die Mühe und lese das mal komplett.

 

[scully1234]

SLI hat eine höhere input lag wenn du das immer noch nicht verstehst dann solltest du hier nicht andere groß kritisieren wenn du selbst die technische Hintergründe nicht verstehst. Es ist technisch unmöglich frames zu buffern, eine passende durchschnittsframetime zu ermitteln und es dann mit der Zeit auszugeben ohne dass man ein paar frames zurückhält.
i.

For input lag reduction in the general case, we recommend disabling vsync. For NVIDIA card owners running OpenGL games, forcing triple buffering in the driver will provide a better visual experience with no tearing and will always start rendering the same frame that would start rendering with vsync disabled. Only input latency after the time we would see a tear in the frame would be longer, and this by less than a full frame of latency

.

 

[LD]

.

Ich denke es sollte klar sein dass man beim frametime optimierung von sli oder cf nicht einfach irgendein buffering zum Vergleich ziehen kann. Bei triple buffering werden einfach alle überflüssige frames gedroppt das funktioniert natürlich mit minimalen input lag aber bei sli passiert das nicht.

 

[Bunghole Beavis]

Hi, da muss ich gleich mal wieder den Wind aus den Segel nehmen, oder bricht jetzt erst recht ein Sturm auf?
3DCenter Forum - Einzelnen Beitrag anzeigen - The Tech Report: HighSpeed-Videos zeigen Micro-Stuttering

So lang FCAT nur auf einer Plattform statt findet, schenke ich den Tests von PCPer keine Aufmerksamkeit.

HT von Intel beißt sich anscheinend mit der Grafikkarte.

Bist Du als NVIDIA Information Ministrant mit der irakischen Flachpfeife irgendwie verwandt?

Was erwartest du vom grünen Troll, beide tragen zumindest die gleiche Uniform.

 

[sontin]

SLI hat eine höhere input lag wenn du das immer noch nicht verstehst dann solltest du hier nicht andere groß kritisieren wenn du selbst die technische Hintergründe nicht verstehst. Es ist technisch unmöglich frames zu buffern, eine passende durchschnittsframetime zu ermitteln und es dann mit der Zeit auszugeben ohne dass man ein paar frames zurückhält.

Beide Verfahren haben ihre vor und nachteile, frame buffering scheint immer noch der subjektiv geringere nachteil zu sein daran zweifelt niemand aber man sollte auch nicht so verblendet sein dass man meint alles was der bevorzugte Hersteller macht ist perfekt und fehlerfrei.

Und du denkst dir Dinge aus und projektzierst sie auf nVidia. Die Wahrheit ist, dass nVidia eben nicht mit Buffern arbeitet, sondern die Ausgabe weiterhin in "Echtzeit" geschieht.

Ist dir überhaupt bewusst, was AFR ist und wie es arbeitet? Dann würdest du erkennen, dass es für den Input-Lag vollkommen egal ist, wann die Frames ausgegeben werden.

Die einzige Möglichkeit den Input-Lag zu reduzieren, ist die Wirksamkeit von AFR zu verringern, indem die Zeit zum Starten reduziert wird. Das bedeutet dann, dass man eben nur minimal etwas vom zweiten+ Bild sieht. Das, was man in der Vergangenheit als "Mikroruckler" beschrieben hat.

Und da stellt sich dann die Frage, wieso jemand überhaupt auf AFR gehen sollte, wenn er das zweite+ Bild nichtmal richtig erhält.

 

[LD]

Und du denkst dir Dinge aus und projektzierst sie auf nVidia. Die Wahrheit ist, dass nVidia eben nicht mit Buffern arbeitet, sondern die Ausgabe weiterhin in "Echtzeit" geschieht.

Ist dir überhaupt bewusst, was AFR ist und wie es arbeitet? Dann würdest du erkennen, dass es für den Input-Lag vollkommen egal ist, wann die Frames ausgegeben werden.

Die einzige Möglichkeit den Input-Lag zu reduzieren, ist die Wirksamkeit von AFR zu verringern, indem die Zeit zum Starten reduziert wird. Das bedeutet dann, dass man eben nur minimal etwas vom zweiten+ Bild sieht. Das, was man in der Vergangenheit als "Mikroruckler" beschrieben hat.

Und da stellt sich dann die Frage, wieso jemand überhaupt auf AFR gehen sollte, wenn er das zweite+ Bild nichtmal richtig erhält.

Ich weiß was AFR ist. Hierbei interessiert es einem wann das Ergebnis der Eingabe am Bildschirm erscheint und dann ist es sehr wohl relevant wann die Frames ausgegeben werden. Zwar ist es eher ein output lag was man hat aber insgesamt ist es dennoch ein Verzögerung zwischen input und effekt.

Und jetzt zu deinem Einwand, ja die Frameausgabe muss etwas verzögert werden damit man nicht diese abwechselnd schnelle und langsame Frameausgaben hat aber damit man es machen kann muss der Durchschnittszeit der Frames bekannt sein sonst weiß man gar nicht wohin man die Ausgabe verzögern muss. Dafür müssen erstmal die Frametimes einige Frames vorhanden sein damit man ein Mittelwert bilden kann und dazu passend die Frames aus einem Buffer ausgegeben werden. In Echtzeit kann die Frameausgabe aus dem grund schonmal gar nicht geschehen denn erhält man wie gewohnt die ungleichmäßige Frames. Oder wenn du meinst die können einfach die Gpu-s etwas verzögert rechnen lassen damit man gleichmäßige frames hat, das würde gehen aber dann hat man das Problem dass man wieder nicht weiß auf welchen Wert man verzögern muss denn man hat keine Information über die aktuelle durchschnittsframetimes die man erzielen wird. Das System kann also nicht komplett in Echtzeit funktionieren weil man erstmal wissen muss auf welche Durchschnittframes man überhaupt kommen muss.

 

[Skysnake]

Nein sehe ich nicht so, zum einen haben wir keine Vergleichswerte für T-Game sondern nur zu T-present und hier könnte man ja schon eingreifen von Seite des Grafiktreibers weil man einfach den Call verzögern könnte, wie willst Du das messen? Als Referenzwert hat man ja nur T -present , an der Stelle an der auch FRAPS misst. Und du gehst von einem fixen Zeitinterval aus, was aber nicht zwingend sein muss, oder?

Indem man wirklich die echte Ingametime ermittelt. Das geht aber eben NUR (100% richtig) unter Mithilfe der Game-Developer. Alternativ muss man eben wie gesagt einen synthetischen Benchmark schreiben. Was man aber noch immer machen kann ist über das RDTSC Register die Zeit zu ermitteln, und dann entweder am Anfang, oder eben am Ende des Rendervorgangs zu ermitteln, und eben dementsprechend den Balken ein zu färben. Ist immer noch besser, als wenn man einfach nur statisch die Farben durchiteriert, weil man dann eben noch eine Information über einen bestimmten Zeitpunkt erhält.

Damit könnte man zumindest sehen, in wie weit die Frames divergieren, insbesondere wenn man es vor dem Present call ausführt.

Um das auf zuzeigen was du vorhast wäre es aber wohl besser Sleepsequenzen einzubauen um dann zu sehen wo der Schwellenwert liegt, ich bin sicher das hier mit Medianwerten gearbeitet wird alles andere wäre Wahnsinn.aber auch hier würde eine Verzögerung des Calls die Meßbarkeit zumindest mit den uns zur Verfügung stehenden Mitteln faktisch unmöglich machen oder übersehe ich da was?

Ja übersiehst du. Die Sleep werte sind so groß, dass sie der bestimmende Faktor ist

Ich sagte ja, am Besten mit nem synthetischen Tool, bei dem man normal >1k FPS generieren kann. Da kannst du dann in erster Näherung die Variation der Renderzeit komplett vernachlässigen. Die Zeit die ein Frame braucht, wird da praktisch komplett durch das Sleep(x) bestimmt. Eine bessere Idee habe ich nicht.

Du müsstest in diesem Fall ja zuerst mal ermitteln wie groß die Latenz zwischen T-game und T-present ist und auch hier ist eine Abhängigkeit zum Call gegeben wie man wiederum bei Fraps Messungen sehr gut sehen kann, leider ist das nicht so einfach.

Ne, das ist nicht zwingend nötig, da man sich nur darauf beschränken will, inwieweit die Streuung der Zeitspanne ist, aber nicht die absolute Zeitspanne. Und diese differenzielle Betrachtung kannst du eben über das Abzählen der dargestellten Linien und der mit einer echten Timemark versehenen Balken bestimmen.

Sonst währ es ja so, dass FRAPS Messungen auf beiden Karten gleich aussehen würden nur hinten was anderes rauskommt. Dem ist jedoch nicht so, Es besteht schon eine gewisse Abhängigkeit zwischen dem was Fraps vermessen tut und den Ergebnissen die FCAT ausgibt um hier mal Pest aus dem 3DC zu zitieren, " Nen Variationskoeffizient von 50% wird sich auch durch Framepacing nicht magisch in Luft auflösen" Gemeint sind hier die Werte die sich aus einer Fraps-Messung ergeben und mit Frapo das Tool von Pest aufbereitet werden.

versteh gerade nicht, was du hier meinst.

Mal ein ganz anderer Ansatz ;-) PRAD | Reportage: Inputlag der auf Seite 9 und 10 durchaus auch bei dem Meßverfahren mit FCAT Fragen aufwerfen könnte, denn wer von uns kann schon mit absoluter Sicherheit sagen ob hier selbst bei VSync nicht Abweichungen vorliegen die wir nicht auf dem Schirm haben interessant währe in diesem Zusammenhang auch mal eine Vermessung von zwei Fire Pro Karten. Denn die Messung (Aufzeichnung) und die Ausgabe auf den Monitor erfolgt bei PCper nicht am gleichen Ausgang das wird zumindest mal so beschrieben in der Erklärung des Testverfahrens. Bitte nicht von dem Titel abschrecken lassen ich habe das schon geschnallt mit dem Outputlag aber wenn ein Monitor ein Inputlag von 0 hat ist dies auch gleichzeitig das Outputlag der Grafikkarte Mach Dir mal die Mühe und lese das mal komplett.

Meinst du das Problem, dass die Frequenzgeneratoren leicht jittern können? Wenn ja, das sollte eigentlich nicht ins Gewicht fallen.

Vor allem nicht bei der Methode von FCAT. Hier wird, soweit ICH das verstanden habe, eine Kabelpeitsche benutzt. Ich seh da jetzt kein Problem in dem Bereich.
@Sotin:
Nimm gefälligst diese Beleidigung sofort raus. Ich glaub bei dir hakts echt!
Entweder du nimmst das jetzt sofort raus, und entschuldigst dich für diese Schlag unter die Gürtellinie, oder du musst mit den Konsequenzen leben...
Das lass ich mir von dir nämlich nicht mehr bieten!

 

[sontin]

Ich weiß was AFR ist. Hierbei interessiert es einem wann das Ergebnis der Eingabe am Bildschirm erscheint und dann ist es sehr wohl relevant wann die Frames ausgegeben werden. Zwar ist es eher ein output lag was man hat aber insgesamt ist es dennoch ein Verzögerung zwischen input und effekt.

Die Ausgabe der Frames - also frame times - ist vollkommen unbedeutend für den Input-Lag.

Und jetzt zu deinem Einwand, ja die Frameausgabe muss etwas verzögert werden damit man nicht diese abwechselnd schnelle und langsame Frameausgaben hat aber damit man es machen kann muss der Durchschnittszeit der Frames bekannt sein sonst weiß man gar nicht wohin man die Ausgabe verzögern muss. Dafür müssen erstmal die Frametimes einige Frames vorhanden sein damit man ein Mittelwert bilden kann und dazu passend die Frames aus einem Buffer ausgegeben werden. In Echtzeit kann die Frameausgabe aus dem grund schonmal gar nicht geschehen denn erhält man wie gewohnt die ungleichmäßige Frames. Oder wenn du meinst die können einfach die Gpu-s etwas verzögert rechnen lassen damit man gleichmäßige frames hat, das würde gehen aber dann hat man das Problem dass man wieder nicht weiß auf welchen Wert man verzögern muss denn man hat keine Information über die aktuelle durchschnittsframetimes die man erzielen wird. Das System kann also nicht komplett in Echtzeit funktionieren weil man erstmal wissen muss auf welche Durchschnittframes man überhaupt kommen muss.

Das normale Verfahren wird eher den Stream analysieren und dann entsprechend die Parameter setzen. Laut nVidia soll es auch hardwarebasierend sein, wodurch abseits des Treibers Maßnahmen getroffen werden können.

 

[LD]

Die Ausgabe der Frames - also frame times - ist vollkommen unbedeutend für den Input-Lag.



Das normale Verfahren wird eher den Stream analysieren und dann entsprechend die Parameter setzen. Laut nVidia soll es auch hardwarebasierend sein, wodurch abseits des Treibers Maßnahmen getroffen werden können.

Input lag ist die zeit zwischen betätigung der Taste und erscheinen des Effekts auf dem Bildschirm also ist die Zeit Frameausgabe sehr wohl relevant.

Naja das beantwortet immer noch nicht ganz wie man an die Framezeiten kommt bevor die überhaupt berechnet werden. Ich weiß auch nicht wieso es so unmöglich sein soll dass sli mehr input lag hat, die 2 Frame zusätzliche Verzögerung fällt unter normale umständen eh sehr wirklich auf. Ab Kepler gibt es eine Hardwaremaßnahme wobei ich es bisher nur bei der gtx 690 bestätigt gesehen habe, aber auch das kann das Problem nicht umgehen dass man nicht von vornerein weiß wie viel Zeit die einzelnen frames brauchen werden es zu berechnen und wie unterschiedlich diese Zeit zwischen die GPU-s ausfallen wird, das alles braucht man um effektiv die Framezeiten anzupassen.

 

[SeniorChef]

Edit mein Fehler

Wie Ich bereits schrieb, halte ich den Test auf PCperspective für nicht repräsentativ.
Es wird nur Rohleistung gemessen ohne AA/AF, offensichtlich. Ebenfalls ein bereits veralteter AMD Treiber wurde benutzt.
Zudem kommt das System von nvidia, das ist def nicht neutral.

 

[Schaffe89]

So lang FCAT nur auf einer Plattform statt findet, schenke ich den Tests von PCPer keine Aufmerksamkeit.

Naja, dann ist es aber zumindest klar, dass Nvidia SLI mit HT besser zurechtkommt als AMD mit HT.
Die Wahrscheinlichkeit dass es nur am HT liegt dass AMD hier schlecht aussieht, ist sehr sehr unwahrscheinlich.

Das normale Verfahren wird eher den Stream analysieren und dann entsprechend die Parameter setzen. Laut nVidia soll es auch hardwarebasierend sein, wodurch abseits des Treibers Maßnahmen getroffen werden können.

Was trotzdem keinesfalls ein Argument dafür ist, dass es keine Zeit kostet und den Input respektive Outputlag verhindert.
Du suchst jetzt verkrampft nach irgendwelchen Ausreden.
Den Käse mit Hardwarebasierend kauf ich Nvidia sowieso nicht ab, wie kann es dann dann sein, dass manche Spiele teils schlechtere Frametimes mit SLI haben wie Crossfire? Übrigens auch mit den FCAT Messungen?

 

[W4RO_DE]

Edit mein Fehler

Wie Ich bereits schrieb, halte ich den Test auf PCperspective für nicht repräsentativ.
Es wird nur Rohleistung gemessen ohne AA/AF, offensichtlich. Ebenfalls ein bereits veralteter AMD Treiber wurde benutzt.
Zudem kommt das System von nvidia, das ist def nicht neutral.

Der Treiber ist nur veraltet, weil man seit geraumer Zeit testet und er damals als man begann aktuell war. Man wechselt natürlich nicht mitten in einer Serie Tests den Treiber, das würde die Ergebnisse ihrer Vergleichbarkeit berauben. Außerdem kommt das die beleuchtete Problematik betreffende Update laut AMD erst in einigen Monaten.

 

[SeniorChef]

Der Treiber ist nur veraltet, weil man seit geraumer Zeit testet und er damals als man begann aktuell war. Man wechselt natürlich nicht mitten in einer Serie Tests den Treiber, das würde die Ergebnisse ihrer Vergleichbarkeit berauben. Außerdem kommt das die beleuchtete Problematik betreffende Update laut AMD erst in einigen Monaten.

Möglich oder auch nicht, kann jemand GARANTIEREN, dass das Ergebniss mit 13.3beta3 nicht besser gewesen wäre?

 

[dochurt]

Nun bleibt mal ruhig hier, demnächst erscheinen wieder Wundertreiber und die Sache ist gefakt... ähmmm gefixt ^^

 

[Don]

AMD spricht zu FCAT und der Radeon HD 7990

 

[Skysnake]

Yeah ha....

Absolute Nullaussage. Die hätte man auch mit FRAPS haben können. Zu FCAT und der Genauigkeit/Interpretation der Werte wird halt genau 0 gesagt. Schade, aber habe ich erwartet. Bei solchen Themen bekommste egal von welchem Hersteller eigentlich nur off record ne Antwort, wenn überhaupt.

 

[Phantomias88]

Und der nächste Artikel ist bei PC-Per erschienen, diesmal 7950/CF vers. GTX66ti/SLI : Frame Rating: GeForce GTX 660 Ti and Radeon HD 7950 | PC Perspective

Autsch !!

Lol, mir ist gerade was aufgefallen, bei dem "Rohdaten(rawdata) Diagramm": Inline | PC Perspective
Da kann man unten entlang der orangenen Balken eine schöne Linie ziehen, d.h. die besten FPS gibts mit Crossfire,
Die langen Peaks nach oben, werden vom Monitor nicht mehr Angezeigt, da sie zu spät sind und somit vom Monitor verworfen werden.
Nachteil ganz klar ein höheren Verbrauch, Vorteil kein Limiter oder vsync wird benötigt und man hat ein sehr direktes Spielgefühl.

 

[Skysnake]

Aus dem Artikel von THG:

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.

LOL?

Das ist doch ein schlechter Scherz oder? DA ist man also nicht mal in der Lage auf allen x86 Systemen zu laufen? Sorry, aber wie lächerlich ist das denn bitte???

Das DARF gar nicht sein, da die Sachen ja eigentlich Hardwareunabhängig funktionieren sollte.... Für was habe ich denn bitte die Hardwareabstraktion??? So kann ich die Werte doch komplett in die Tonne treten, zumal ich ja gar nicht weiß was ich da überhaupt mache. Es gibt ja absolut keinen Grund, warum das auf einen X79 System nicht gehen sollte. Man greift ja nur die Daten am DVI-Ausgang ab...

Und ansonsten ist ne x86 CPU eine x86 CPU :ugly:

 

[Powerplay]

Ich finde den test von THG sehr gut und auch da schreibt man ja das sich AMD der lage bewußt ist und es zugibt.
Also was soll man dazu noch sagen auser es ist wie es ist. Genau deswegen zocke ich mit meinem CF sys fast nur mit vsync und limiter weil anders nicht richtig flüssig ist.

Naja mal schauen was AMD noch unternimmt oder ob ich auch zur grünen zeite der macht wechseln werden
Dann kann ich wenigsten auch auf die roten runter spucken "scherz"

 

[Skysnake]

Was findest du an dem Test gut?

Es wird mal wieder völlig unreflektiert das Tool verwendet, und das Marketinggewäsch von nVidia runtergebetet...

Allein das man auf die Probleme mit dem X79 System nicht eingeht ist ein HOHN!

 

[scully1234]

Das sind zwei verschiedene paar Schuhe, welche du jetzt insgesamt auf ein Thema beziehst.
AMD hat gewisse Fehler zugegeben die man jetzt bearbeitet und verbessern will, wie da jetzt der Zusammenhang zwischen der Methode FCAT und AMD´s Aussage ist ist ein anderer Sachverhalt, oder haben sie sich dazu auch geäußert.?

Aber gut dass du scheinbar absichtlich das wieder so darstellst. Spar dir doch diese unehrlichen Aussagen.

Melonenkatze du solltest wohl auch ab u an deinem Konzern auch mal unangenehme Dinge glauben

nämlich dass zwei Nvidia-Boards im SLI-Modus ein flüssigeres Spielerlebnis bieten als zwei AMD Radeon-Karten im CrossFire-Modus. AMD gesteht das Problem ein und versucht, der Situation durch Weiterentwicklung der Grafiktreiber Herr zu werden

Das Tool ändert daran gar nix sondern untermauert das Ganze nur!

Zwar erkenne man bei AMD an, dass FCAT andere Ergebnisse erreiche, als mit den üblichen Messmethoden (z.B. via FRAPS), die Unterschiede seihen aber nur sehr gering, so dass sich der Aufwand wohl kaum lohnen würde

 

[boxleitnerb]

Und wir vergessen mal ganz schnell alle Lebensbereiche, wo man mit neuen doppelt Blindtests dann plötzlich rausgefunden hat, dass man sich selbst getäuscht hat. Ich sag nur Placeboeffekt....

Selbst anerkannte Krebs und Blutdruckmedikamente haben sich teils bei erneuten Tests als wirkungslos herausgestellt....

Man sollte wirklich NIE die selbsttäuschungskraft des Menschlichen Geistes unterschätzen. Da sind schon verdammt viele Leute drauf rein gefallen. Man muss bei so etwas daher sehr sehr sehr vorsichtig sein. Wobei ich auch klar stellen will, das man die ungleichmäßige Frameverteilung warnehmen kann, ohne davon zu wissen. Die Frage ist nur, wie lange müssen wir warten, bis die Leute eventuell verzögerte Frames wahrnehmen? Sollte sich das Bewahrheiten, kannst du aber einen darauf lassen, das es genug Leute geben wird, die das dann plötzlich bewusst wahrnehmen und als störende Brandmarken....

Ich hoffe du weißt worauf ich hinaus will.

Natürlich weiß ich das. Du suchst jetzt krampfhaft etwas, um Nvidias Framemetering schlechtzureden. Ich werde dich daran erinnern, wenn AMD ihre Lösung präsentiert und bin gespannt, wie sich das Fähnchen dann im Wind dreht. Es gibt zu viele Reviews und Userberichte, die über die Jahre hinweg tendenziell immer dasselbe gezeigt haben. Zu viele, um es mit "Selbsttäuschungskraft" wegzureden.

 

[Skysnake]

Kann ich dir jetzt schon sagen. Wenn nen Schieberegler mit mehr als 5-7 Einstellungen kommt, dann ist das ne Mistimplementierung. Wenn sollte so etwas ohne Eingriffe des Nutzers erfolgen!

Und am eigentlichen Problem ändert sich daran rein gar nichts.... nVidia und AMD sollten mal lieber gefälligst Interposer einsetzen, um Multi-GPU zu realisieren, damit kann man die ganzen Probleme von Multi-GPU dann auch wirklich effektiv umgehen, einfach weil man SEHR fette Datenpfade realisieren kann, und auch viel feingranularer arbeiten kann...

Das wäre wenigstens mal sinnvoll, und nicht in so was wie hier, wo man wohl wieder nur trickst, unnötig Ressourcen rein zu buttern...

EDIT:
Und was sagst du eigentlich dazu, dass FCAT mit nem X79 System bei THG anscheinend nicht funktioniert?

Das ist doch lächerlich, und lässt die Zweifel an dem was da gemacht wird noch viel viel stärker steigen. Oder kennst du einen rationalen Grund, warum es da zu Problemen kommt? Ich nämlich nicht...

 

[scully1234]

Das ist doch lächerlich, und lässt die Zweifel an dem was da gemacht wird noch viel viel stärker steigen. Oder kennst du einen rationalen Grund, warum es da zu Problemen kommt? Ich nämlich nicht...

Kennst du den Testaufbau genau?

Datenrate/verwendete Festplatte/Controllerchip wenn eines der 3 Variablen die nötigen Fähigkeiten nicht einräumt oder Spezifikationen übersteigt wird da wohl nur Datenmüll aufkommen beim Aufzeichnen

 

[Powerplay]

Was findest du an dem Test gut?

Es wird mal wieder völlig unreflektiert das Tool verwendet, und das Marketinggewäsch von nVidia runtergebetet...

Allein das man auf die Probleme mit dem X79 System nicht eingeht ist ein HOHN!

Weil das was ich hier fühle ohne einen limiter zu nutzen dem test nahe kommt und zwar das da was nicht stimmt!

Ich habe damit allerdings kein problem weil ich ja grade weiß was ich machen muss und zwar vsync und limiter und das ist für mich schon pflicht wegen tearing und flüssiger darstellung weil max fps sind mir eh egal brauche gute min fps die ich so auch habe aber wenn es ein problem bei der ausgabe gibt soll das auch bitte korregiert werden weil das gehört für mich genauso zum spielerlebnis wie ein gutes AA oder nahezu flimmerfreies AF

Nicht jeder kennt die thematik mit den rucklern und weiß sich mit vsync und limiter zu helfen...

 

[Skysnake]

Geile logik :ugly:

Kleines Beispiel:
Die Straße ist nass -> es regnet
Es regnet -> die Straße ist nass

Kleiner Unterschied nur, aber einmal richtig, und das andere mal absolut falsch.

Kennst du den Testaufbau genau?

Datenrate/verwendete Festplatte/Controllerchip wenn eines der 3 Variablen die nötigen Fähigkeiten nicht einräumt oder Spezifikationen übersteigt wird da wohl nur Datenmüll aufkommen beim Aufzeichnen

Nein, und das ist zu kritisieren, das man den Testaufbau nicht genau kennt.

Es ist aber nicht anzunehmen, dass die Aufzeichnung schuld ist. Die wird ja mit dem anderen System gemacht. Das X79 System sollte ja wohl das Game ausführen, und nicht aufzeichnen. Da spielt I/O also gar keine Rolle, und selbst wenn, wäre es ja ein leichtes einfach die Festplatten bzw hier ja SSDs um zu bauen. So viel trau ich den Jungs von THG schon zu

Und bei I/O ist ein X79 System aber leistungsstärker als ein Z77 System.

Also nochmals, was für rationale Gründe gibt es dafür? Die von dir genannten sind keine, da X79 hier besser dasteht (meines Wissens nach zumindest).

Es ist der blanke Hohn, das THG hier dann von "wissenschaftlich untermauerten Methoden" redet, aber so ein eklatantes Problem, was alle Alarmglocken schirllen lässt, das hier was gewaltig schief läuft, einfach unter den Tisch fallen lässt :ugly:

 

[scully1234]

Und bei I/O ist ein X79 System aber leistungsstärker als ein Z77 System.

Das kommt doch ganz auf den Controllerchip an die sind nunmal nicht alle gleich u funktionieren auch nicht mit jeder Festplatte/SSD gleich gut

Da jetzt alleine von Highend X79 ausgehend zu sagen die I/O Performance ist generell besser wie beim kleinen Z77 halte ich für gewagt

 

[Powerplay]

Die sagen doch selber auch das es noch nicht optimiert ist. Das ist erst der anfang und sie wollen auch an den settings experimentieren.
Es zeigt halt nur auf was auch viele schon subjektiv wahrgenommen haben.

Sie haben ja auch geschrieben das sie mit AMD und NV im kontakt sind und einige spiele sauber liefen wärend das capture toll sagt es sollte ruckeln!

Wenn da an allem nix dran wäre würde AMD das doch sofort wiederlegen und nicht sagen das sie dran arbeiten?

Es kann ja sein das sie garnicht wußten woher das kommt und nun wurde ihnen gezeigt woher das kommt und sie können das problem angehen. Das ist genauso wie damals mit der HD6000 welche stark geflimmert hatte und nun flimmert die HD7000 absolut null

 

[Skysnake]

Das kommt doch ganz auf den Controllerchip an die sind nunmal nicht alle gleich u funktionieren auch nicht mit jeder Festplatte/SSD gleich gut

Da jetzt alleine von Highend X79 ausgehend zu sagen die I/O Performance ist generell besser wie beim kleinen Z77 halte ich für gewagt

Die Anbindung vom X79 Chip ist nicht schlechter, als die vom Z77. Da gibt es eigentlich keine vernünftigen Gründe. Wie gesagt, soweit ich das verstanden habe, wurde das X79 System aber auch nicht zum Captering verwendet, sondern um die Frames zu generieren, also zu zocken, und da spielt der Chipsatz gar keine Rolle.

Wir wissen einfach VIEL zu wenig, stoßen aber am laufenden Band auf große Fragezeichen, die absolut keinen Sinn machen. Daher kann man den Ergebnissen auch nicht trauen. DA kann weiß der Teufel was passieren... Dem muss natürlich nicht so sein, aber wir wissen es einfach NICHT! und ich werfe ungern Münzen, um zu entscheiden, ob ich etwas für voll nehmen kann oder nicht...

Die sagen doch selber auch das es noch nicht optimiert ist. Das ist erst der anfang und sie wollen auch an den settings experimentieren.
Es zeigt halt nur auf was auch viele schon subjektiv wahrgenommen haben.

Sie haben ja auch geschrieben das sie mit AMD und NV im kontakt sind und einige spiele sauber liefen wärend das capture toll sagt es sollte ruckeln!

Wenn da an allem nix dran wäre würde AMD das doch sofort wiederlegen und nicht sagen das sie dran arbeiten?

Es kann ja sein das sie garnicht wußten woher das kommt und nun wurde ihnen gezeigt woher das kommt und sie können das problem angehen. Das ist genauso wie damals mit der HD6000 welche stark geflimmert hatte und nun flimmert die HD7000 absolut null

Und warum traue ich den Werten dann überhaupt, wenn das alles noch stark in der Entwicklung ist, und ich vor allem nicht rein schauen kann, um mir selbst ein Bild zu machen?

So in der Form macht es einfach nicht den Eindruck, das es schon verwendet werden kann. Dafür gibt es einfach noch viel zu viele ungeklärte Probleme/Fragen.

Und genau deswegen kann auch z.B. AMD gar nichts dementieren. Die müssen ja auch erstmal schauen, ob da was dran ist, oder nicht. Ich glaub viele hier unterschätzen völlig! wie komplex die ganze Thematik ist! Zudem kann man sich als Hersteller da auch keine Schnellschüsse erlauben. Die kommen sonst wie ein Bummerang zurück...

EDIT:
Auf was mich Iruwen aus dem 3DCenter gerade aufmerksam gemacht hat:

THG sagt: x79 produziert unbrauchbare Daten
PCper.com: Wir verwendet ein ASUS P9X79 Deluxe

:ugly:

Ähm.... Sieht jemand den Fehler?

Aber hey, die wissen alle genau was Sie machen, und man soll den Werten, die die da publizieren blind vertrauen....

Ja ne ist klar...

Ich bin jetzt ja mal gespannt, welche Erklärung gewisse Leute hierfür abliefern.

EDIT2:
Die Sache mit X79 bei THG wird am Freitag oder Montag geklärt. Heute ist leider der Redakteur nicht mehr im Büro.

 

[Schaffe89]

Kann ich dir jetzt schon sagen. Wenn nen Schieberegler mit mehr als 5-7 Einstellungen kommt, dann ist das ne Mistimplementierung. Wenn sollte so etwas ohne Eingriffe des Nutzers erfolgen!

Ich würde es nicht schlecht finden, wenn man dem Nutzer soviel Einstellungsmöglichkeiten lässt wie nur möglich.
Wenn die Funktion ähnlich dem Framemetering von Nvidia ist, dann kann man sich ja entscheiden und den Regler je nach Engine verschieben, wird halt dann sau kompliziert.