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

Cool Story, Skytroll.

Achja, nVidia bedient sich natürlich keines "Schlupfloches der Verzögerung". Das nennt man AFR und hat immer schon Verzögerungen zu folge.
Höre doch bitte auf hier Lügen zu erzählen. Es ist bei nVidia und AMD exakt das selbe. Der einzige Unterschied ist, dass die Frame-Ausgabe bei nVidia halbwegs gleichmäßig und bei AMD vollkommen ungleichmäßig erfolgt.

Ehrlich, kommst du dir nicht selbst komisch vor dauernd diesen Quatsch zu schreiben? :hmm:
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Jup, das ist entscheidend, aber man kann halt nur eins von beidem haben, entweder ein möglichst kleines Delta_t zwischen Ingame-zeit und Realer-Zeit (Anzeige auf dem Monitor), oder eben einen möglichst gleichbleibenden Frameverlauf. Beides zusammen geht nicht, wenn man im GPU-Limit hängt, und nicht viel viel viel mehr Frames generieren kann, als man tatsächlich braucht.
Aus deiner Erfahrung mit solchen Sachen heraus was ist vielviel mehr?
Naja, das ist relativ, was man "positiv" findet.
Wie sieht es bei nem 3D-Shooter aus? willst du da lieber das du das neuste Bild ein Frame, oder auch nur einen halben Frame später angezeigt bekommst, und daür den einen gerenderten Frame nicht quasi wegwirfst, oder willst du möglichst früh die Ausgabe haben, um einen Reaktionsvorteil zu haben?
Das ist doch einfach messbar, in der Vergangenheit sind hier aber SLI Systeme nicht negativ aufgefallen gegenüber CF Systemen oder gibt es darüber irgendwelche Erkenntnisse die bei SLi eine größeres Inpulag ausweisen wie bei CF Systemen?
Und "Schummelei" ist es nicht, wenn man es genau nimmt. Man betrachtet ja nicht ALLES, sondern nur einen Teilaspeckt, und über den Rest legt man das "Mäntelchen des Schweigens". Das ist ein ganz normales vorgehen, bei dem man sich zu Nutze macht, dass die Leute sich eben "gewisse Dinge" denken, und sich "gewisse Schlüsse" überlegen, die aber so überhaupt nicht zutreffend sind. Das ist die gleiche Schose wie mit dem "Transferspeed upto equivalent to PCI-E 3.0 transferrate". Der Hersteller/Verkäufer sagt A, der Kunde versteht B, und der Hersteller/Verkäufer lacht sich ins Fäustchen und hält die Schnauze...

Das nVidia sich des Schlupfloches der Verzögerung bedient liegt ziemlich nahe. Das gesamte Testsystem schreit praktisch in Neonleuchtreklame dieses Schlupfloch in die Welt hinaus. Bei AMD sieht man ja auch, das auf einen sehr kurzem Frame meist ein längerer Frame kommt. Ich würde mir dabei aber keine Aussage dazu zutrauen, ob der "kurze" Frame von der Main-GPU oder von der Second-GPU kommt. Gibt Argumente/Gründe für beide Varianten.

Was leider noch überhaupt nicht beachtet wird ist, wie sich die Ingamezeit ergibt. Wird da einfach ein starres Zeitintervall genommen (war früher so, heute gibts das eigentlich gar nicht mehr meines Wissens nach, bei manchen Konsolenports würde ich aber keine Wette abschließen), oder nimmt man die Zeitpunkte, die ermittelt werden, wenn ein Frame angestoßen wird?

Wenns letzteres ist, dann stellt sich sofort weiter die Frage, wie denn die CPU die Frames verarbeitet, für die beiden GPUs. Läuft das parallel, oder wie oder was? Das sind einfach unglaublich viele Unbekannte noch mit dazu, die man gar nicht wissen kann... Sie spielen aber noch mit rein, ob man eine womögliche Verzögerung eher positiver sehen kann, oder noch negativer.

Was mir leider NOCH IMMER! nicht klar ist, ist wie nun genau die Manipulation erfolgt?....

Funktioniert das auch mit OpenGL-Anwendungen? Wenn ja, könnte man sich ja eventuell mal daran machen, einen Test zu schreiben, der aufzeigt, ob eine Verzögerung stattfindet oder eben nicht. Hätte da auch schon eine ganze Reihe an Ideen, wie man das sehr schön aufzeigen könnte. Aktuell fehlt mir aber einfach die Zeit dafür so etwas zu implementieren, und es müsste eben AUCH mit OpenGL funktionieren, wobei man es da glaub expliziet programmieren muss, um mehrere GPUs zu verwenden... Also erstmal viel lesen, bevor ich so nen Test wirklich implementieren könnte... -.-



Naja, wie definierst du "Schummeln"? Hier hat man halt gewisse Randbedingungen, an die man sich hält, und dreht wohl an einem Schräubchen, das man ausgesspart hat. Das ist apriori ja auch völlig legitim. Wenn man dann aber nen Tool raus bringt, und genau dieses eine Stellschräubchen unbetrachtet lässt, aber SUGGERIERT! man würde es durchaus berücksichtigen, dann ist das schon ein wenig "Cheaten", aber nicht unbedingt "Schummeln". Man ist halt nicht ganz ehrlich, und auf dieses "Wir haben uns doch genau an das gehalten, was wir gesagt haben, und der Punkt war uns halt unbekannt :rolleyes:" kann man sich dann immer zurückfallen lassen. nVidia hat das schon SEHR geshickt angestellt. Da muss man schon den Hut ziehen. Auf die Idee muss man ja erstmal kommen, wie die das machen, und welche Randbedingungen überhaupt gelten.

Von nem "normalem" Hardwareredakteur kann man in keinster Weise erwarten, dass er das durchschaut, oder eben dieses Schlupfloch erkennt. Ich hab auch einige Zeit gebraucht, bis mir ein Licht aufgegangen ist, und ich hatte das Glück, das ich einfach schon viel mit Zeitmessungen auf Computersystemen gemacht habe, und daher WEISS wie schwierig das ist, und daher dieser scheinbar ach so "trivialen" Lösung sehr verwundert gegenüber stand. Zeitspannen im µs Bereich zu messen ist nämlich gar nicht so trivial auf dem PC...
.

Das muss ich jetzt nicht verstehen, oder, du wirfst hier verschiedene Sachen durcheinander und wenn ich das richtig interpretiere stecken da noch ein paar andere Sachen quer die aber mit dem Thema hier gerade gar nichts zu tun haben. Aber was bringt es dir und allen anderen, wenn man das was du vorschlägst machen würde, wenn das Ergebnis das hinten rauskommt passt, da kann die GPU intern machen was sie will solange hinten was Gescheites rausfällt oder siehst du das anders??? Ich bin mir auch sicher das verantwortungsvolle Redaktionen da mal an geeigneter Stelle nachhacken wenn sie in ihren Reihen nicht die Kompetenz sitzen haben. Zumindest hoffe ich dass ;-)
Und vielleicht fällte es mir einfacher wenn du die Stellschraube die alle übersehen haben könnten genauer eingrenzen könntest zumindest ich kann dir hier nicht richtig folgen.

*
Ja, nVidia war/ist definitiv sehr gut darauf vorbereitet gewesen. Sie haben halt eine Lücke erkannt, und diese jetzt schön ausgeschlachtet. Ob man aber dafür zwingend Hardware braucht, würde ich keine Aussage darüber treffen wollen. Dafür kenne ich mich mit dem Detail! der Displayausgabe leider viel zu wenig aus. Am Ende wird man wohl FlipFlops haben, die die Datenpakete raus hauen, aber wo jetzt die Daten dafür liegen weiß ich ehrlich gesagt nicht, also ob man dafür wirklich nochmal dedizierten Speicher hat, um die Performance zu steigern, oder ob das im GPU-Hauptspeicher liegt, weiß ich nicht. Beim xserver (linux) ist es glaub ich sogar im Hauptspeicher der CPU, wobei, wenn ich mich da genau erinnere, das nur I/O-mapped Memmory ist :ugly: (bin mir sogar ziemlich sicher, dass das I/O-mapped Memmory war/ist, aber eben nicht 100%). Auf jeden Fall, was ich sagen will ist, es kommt wirklich darauf an, wie das am Ende WIRKLICH in Hardware implementiert ist. Je nachdem kann es sein, das man "nur" Software/Treiber anpassen muss, oder aber wirklich etwas Hardware dafür investieren muss. Sicher sagen können dir das aber wohl nur die Chipentwickler von AMD und nVidia. Das ist wirklich extremstes lowlvl Zeug. Mit viel Glück wissen Konsolenentwickler etwas darüber, aber in öffentlich zugänglichen Quellen wirst du wohl darüber eher nichts finden. Sagt mir zumindest meine Intuition bzgl. anderweitiger Erfahrungen mit solchen lowlvl-Sachen.
Hier habe ich keine Ahnung
 
Naja es sollte schn klar sein dass man durch frame buffern garantiert nicht auf das selbe input lag kommt wie ohne also ist es ganz klar dass ein nv sli ein paar frames nachhängt gegenüber ein cf system. Was jetzt schlimmer ist hängt auch von der Situation ab aber scheinbar ist es meistens besser gleichmäßige frames zu haben.
 
Aus deiner Erfahrung mit solchen Sachen heraus was ist vielviel mehr?
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:

Das ist doch einfach messbar, in der Vergangenheit sind hier aber SLI Systeme nicht negativ aufgefallen gegenüber CF Systemen oder gibt es darüber irgendwelche Erkenntnisse die bei SLi eine größeres Inpulag ausweisen wie bei CF Systemen?
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.


Das muss ich jetzt nicht verstehen, oder, du wirfst hier verschiedene Sachen durcheinander und wenn ich das richtig interpretiere stecken da noch ein paar andere Sachen quer die aber mit dem Thema hier gerade gar nichts zu tun haben. Aber was bringt es dir und allen anderen, wenn man das was du vorschlägst machen würde, wenn das Ergebnis das hinten rauskommt passt, da kann die GPU intern machen was sie will solange hinten was Gescheites rausfällt oder siehst du das anders??? Ich bin mir auch sicher das verantwortungsvolle Redaktionen da mal an geeigneter Stelle nachhacken wenn sie in ihren Reihen nicht die Kompetenz sitzen haben. Zumindest hoffe ich dass ;-)
Und vielleicht fällte es mir einfacher wenn du die Stellschraube die alle übersehen haben könnten genauer eingrenzen könntest zumindest ich kann dir hier nicht richtig folgen.
Das ist doch die Frage ;) Was ist denn "passen" Ist passen nur eine gleichmäßige Ausgabe, wobei Frames auch mal ruhig um <=1 Frame verzögert werden könnten bei der Ausgabe, oder ist "passen" dass die Ingame-Zeit möglichst wenig von der Anzeigezeitpunkten abweicht? Also quasi der "output"-lagg zwischen Renderzeitpunkt und Darstellung auf dem Schirm möglichst gering sein soll.

Hier habe ich keine Ahnung
Da dreht sichs drum, wie die Daten, die ne GPU generiert denn verarbeitet werden, um dann durchs Kabel in den Monitor zu kommen ;)

Also eigentlich ganz "einfach" :ugly:

Mit der Thematik der Ausgabe von Daten über Memory-Mapped-I/O wie bei x86 beschäftige ich mich aktuell beruflich, daher bin ich in diesem SEHR speziellen Punkt gerade ziemlich gut drin, auch wenn es keine Grafikausgabe ist, was ich aktuell behandle. Die Problematiken und vorgehensweisen sind da aber relativ ähnlich, weil man sich eigentlich immer den gleichen grundlegenden Techniken bedient, und eben nur unterschiedlich weit abstrahiert. Und das ist auch ein Segen! ich programmier aktuell teilwese den Interruptcontroller (IOAPIC) in ner CPU teilweise selbst. Das ist nen riesen Spaß! Man merkt auch erst, wenn man mal selbst in diese Untiefen des Linuxkernels und der Hardware abgestiegen ist, wie unglaublich abstrahiert die Hardware heutzutage vom Programmierer ist. Wenn man sich da dann teils überlegt, was für ein Overhead da abläuft, dann wird einem oft ganz anders ;D Man kann dadurch aber auch verdammt! viel Schindluder treiben. Und wenn man sich eines sicher sein kann, dann desssen, dass die Softwareleute von AMD und nVidia wissen, wie man Treiber schreibt und tweakt, und man kann verdammt viel in Treibern tricksen und drehen...
 
die Softwareleute von AMD und nVidia wissen, wie man Treiber schreibt und tweakt, und man kann verdammt viel in Treibern tricksen und drehen...
Na das ist aber keine Neuheit. ;)
Wenn sich schon per Software zB SLI auf So775 deaktivieren lässt und nur auf nVidia Chipsätzen frei gibt. Dann natürlich die Treibercheats vor wenigen Jahren um die Benchmarkcharts zu gewinnen.
Manchmal bei erscheinen einer neuen Grafikgeneration hatte man den Eindruck, das mit neuen Treibern die ältere Generation wundersamerweise langsamer wurde. ;)
 
Und was bringts einem? Es gibt ganz grundsätzliche ungelöste Fragen/Probleme zu der Art und Weise, wie gemessen wird. Da kann man noch 10k "Tests" bringen, so lange die nicht geklärt sind, kann man damit einfach nichts anfangen.
 
Es ist immerhin schon mal ein gutes Zeichen, dass die Framerates bei AMD auf einer Single GPU auf Nvidia Niveau legen, ergo scheints wirklich nur ein Crossfireproblem zu sein und wahrscheinlich ist die Vermutung, dass Nvidia hier etwas "dreht" eher unwahrscheinlich.

Softwareleute von AMD und nVidia wissen, wie man Treiber schreibt und tweakt, und man kann verdammt viel in Treibern tricksen und drehen...

Ich denke mittlerweile nicht mehr dass da was getrickst ist, Crossfire ist wohl ohne Limiter einfach nicht so gut wie SLI.
Sieht man auch an den subjektiven Bewertungen wo SLI immer etwas besser abschneidet.

Skysnake schrieb:
Es gibt ganz grundsätzliche ungelöste Fragen/Probleme zu der Art und Weise, wie gemessen wird. Da kann man noch 10k "Tests" bringen, so lange die nicht geklärt sind, kann man damit einfach nichts anfangen.

Warum schneidet dann AMD bei Single GPU sehr gut ab?
Klar vielleicht hat Nvidia es durch Treiber nochmal etwas beeinflusst, aber das subjektive Empfinden ist ohne Limiter bei Nvidia ohnehin im Schnitt besser, das kann oder könnte genau diese Differenz bei diesen Werten sein.

Also die Aussage es bringe nichts, ist wohl doch etwas weit weg von der Realität.
 
Zuletzt bearbeitet:
Naja, ist schließlich Nvidias Tool. Vielleicht wird AMD Crossfire nicht richtig erfasst. Schelm wer Böses dabei denkt.
 
Zuletzt bearbeitet:
Warum schneidet dann AMD bei Single GPU sehr gut ab?
Weil das etwas gänzlich anderes ist? Hier gehts ja wahrscheinlich um das syncen von der Bildausgabe von mehreren GPUs.

Das gezeigte Phenomen kann bei Single-GPU eigentlich gar nicht auftauchen, und wenn doch, dann ist was aber richtig gewaltig am Arsch.

Klar vielleicht hat Nvidia es durch Treiber nochmal etwas beeinflusst, aber das subjektive Empfinden ist ohne Limiter bei Nvidia ohnehin im Schnitt besser, das kann oder könnte genau diese Differenz bei diesen Werten sein.
Subjektive Werte sind schön und gut, aber Sie sind eben eins: Subjektiv!
Ohne doppelten Blindtest gebe ich auf subjektive Eindrücke, die sich auf derart diffiziele Sachen beziehen genau so viel: _ (NULL)

Der Mensch ist einfach verdammt schlecht darin, wie er die reale Welt wahrnimmt. Emotionen, Tagesform usw usw beeinflussen die Art und Weise, wie wir die Welt wahrnehmen. Sich darauf zu verlassen ist ziemlich... Naja... Man muss das immer mit berücksichtigen, vor allem aber nicht mehr als einge grobe qualitative Betrachtung versuchen. Mehr macht einfach keinen Sinn.

Der Knackpunkt ist aber eben, dass wir einfach viel zu viel nicht wissen, und damit kann man die Werte einfach nicht gebrauchen. Ich habe schon bei FRAPS arge Probleme, da sich die Messungen nach meinem Empfinden teils stark auf die Performance auswirkt. Man greift halt ein, und holt sich Daten, und am PC kann man eben nichts machen, was ohne Beeinflussung des Systems ist.

Also die Aussage es bringe nichts, ist wohl doch etwas weit weg von der Realität.
Doch genau das, weil eben etwas suggeriert wird, was überhaupt nicht eingehalten wird durch den Test, und darauf springen die Leute an wie verrückt. Man weiß aber eben so vieles nicht, das man die Werte gar nicht richtig interpretieren kann. Allein schon das man ~600 Messwerte auf vielleicht nicht mal 100 Pixel darstellt ist ein Hohn... Die sollen wenigstens die Rohdaten bereitstellen, also nicht die Videos an sich, sondern die Auswertungen selbiger, damit man sich das mal im Detail anschauen kann.

Es ist einfach verdammt unseriös, einem derartigen Test zu huldigen, bei dem man so viele Fragezeichen hat.
 
Zuletzt bearbeitet:
Irgendetwas läuft da schief bei PC Perspective:

Eigentlich müsste es doch Unterschiede geben zwischen "FRAPS FPS" und "Observed FPS". Schaut man hingegen in die Einzeltests, passen die beiden Graphen exakt (!) übereinander, nur für Crossfire nicht. Zumindest leichte Abweichungen müsste man doch auch bei Einzelkarten messen.

Das gibt zu denken. Für mich sieht es so aus, als würde bei PC Perspective gleichzeitig FRAPS laufen, während die Messungen mit der Capture Card durchgeführt werden. Das würde das FCAT-Ergebnis verfälschen.
Dass die Graphen so exakt übereinanderpassen, stimmt mich besonders nachdenklich.
 
War ja klar, dass subjektive Eindrücke angezweifelt werden, wenn sie nicht ins eigene Weltbild fassen. Ich habe schon viele Reviews (Online- und User-) gelesen zu SLI und CF und die Tendenz ging immer dahin, dass SLI flüssiger wie CF ist. Die Tests bei PCPER bestätigen das nun auch mit Messwerten. Ist ja nicht so, dass hier neue noch nie gesehene Erkenntnisse zu Tage treten, sondern sie passen wunderbar in das bisherige Bild.

Wenn Nvidia so ein Tool bereitstellt, wird gleich Cheaten vorgeworfen, ein Schelm, wer da Böses dabei denkt. Solche Gedanken kommen eh immer von denselben Leuten, die zu Nvidia nur Negatives, Gehässiges und Hysterisches schreiben. Solche Leute kann man nicht ernst nehmen.
 
Ich bin auch skeptisch, das hat aber bestimmt nichts damit zu tun, dass ich AMD-Fanboy oder Nvidia-Hasser bin - auch das Gegenteil nicht.

Die Marke ist mir wirklich sowas von egal, aber wenn man das ständige Geflame liest, gewinnt man den Eindruck, dass das eine Ausnahme hier im Forum ist...
 
Ich bin auch skeptisch, das hat aber bestimmt nichts damit zu tun, dass ich AMD-Fanboy oder Nvidia-Hasser bin - auch das Gegenteil nicht.

Die Marke ist mir wirklich sowas von egal, aber wenn man das ständige Geflame liest, gewinnt man den Eindruck, dass das eine Ausnahme hier im Forum ist...

Ich bin mir zu 99% sicher, dass sich sein Post nicht an dich, sondern Skysnake richtete. Bei dir ist doch garnicht von den angesprochenen subjektiven Eindrücken die Rede.
 
Und was bringts einem? Es gibt ganz grundsätzliche ungelöste Fragen/Probleme zu der Art und Weise, wie gemessen wird. Da kann man noch 10k "Tests" bringen, so lange die nicht geklärt sind, kann man damit einfach nichts anfangen.

AMD hat doch bereits klipp u klar eröffnet,das sie daran arbeiten.

Was gibts da noch zu hinterfragen,wenn sich der Konzern bereits im Klaren darüber ist,das ungelöste Probleme in der Form bestehen?
An dem Umstand wird sich auch mit unparteiischer Capturing Techniik nichts ändern.Natürlich war es hintertrieben u nicht ganz uneigennützig von Nvidia die erkannten Probleme der Weltöffentlichkeit so auf die Nase zu binden.
Das wäre aber im Umkehrschluss ganz genau so gewesen

Letztendlich bringts aber dem Konsumenten der Multi GPU einsetzt nur Vorteile,denn ab nun an können beide Konzerne ihr sprichwörtliches Hinterteil nicht mehr schleifen lassen,was das betrifft!
 
Zuletzt bearbeitet:
War ja klar, dass subjektive Eindrücke angezweifelt werden, wenn sie nicht ins eigene Weltbild fassen. Ich habe schon viele Reviews (Online- und User-) gelesen zu SLI und CF und die Tendenz ging immer dahin, dass SLI flüssiger wie CF ist. Die Tests bei PCPER bestätigen das nun auch mit Messwerten. Ist ja nicht so, dass hier neue noch nie gesehene Erkenntnisse zu Tage treten, sondern sie passen wunderbar in das bisherige Bild.

Wenn Nvidia so ein Tool bereitstellt, wird gleich Cheaten vorgeworfen, ein Schelm, wer da Böses dabei denkt. Solche Gedanken kommen eh immer von denselben Leuten, die zu Nvidia nur Negatives, Gehässiges und Hysterisches schreiben. Solche Leute kann man nicht ernst nehmen.
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.

EDIT:
@Scully:
Gibts eigentlich einen Link zu der Aussage? Hab ich bisher noch nichts gesehen.

Und ich weiß auch gar nicht, ob ich da so positiv gestimmt bin, dass sich AMD dieses "Problems", sofern Sie es als solches betittelt haben, und auch die Ursachen kund getan haben, annimmt, weil die triviale Lösung eben auch mit Nachteilen verbunden ist. Du hast da die Wahl zwischen Pest und Cholera....

Es ist daher blauäugig, die Ergebnisse so unreflektiert zu schlucken, wie das aktuell usus ist. Das schreit nämlich danach, direkt wieder verarscht zu werden....

Ne differgierende Zeit zwischen Rendering und Ausgabe ist nämlich auch nicht wirklich das Gelbe vom Ei...

Ich sag nur Inputlag von Fernsehern usw usw. Für mich ist das absolut kein Thema, aber da gibt es ja richtig Glaubenskriege deswegen. Ich kann nicht abschätzen, wie groß die Verhältnisse da sind, aber ich vermute mal,dass das in der selben Größenordnung abläuft. Warum soll es dann also an der einen Stelle Teufelszeug sein, dass das Spielen "unmöglich" macht, und auf der anderen Seite ist es dann ok, und gar kein Thema?

Das ist für mich Doppelzüngigkeit....

Und genau damit habe ich eben ein großes Problem. Wenn man derart ins Detail geht, oder vorgibt ins Detail zu gehen, sollte man halt auch wirklich die ganze Wahrheit auf den Tisch legen, und nicht wieder anfangen gewisse Bereiche "aus zu sparen" weils einem halt gerade in den Kram passt...

AMD will ja angeblich eine Lösung mit Schieberegler bringen, wo man, so vermute ich, den Rahmen in dem Frames verzögert werden, beeinflussen kann. Hört sich doch super an oder? Ist dann nVidias Lösung in dem Moment kacke, weil man die Wahl nicht hätte? Und was ist, wenn die das selbst nachschieben? Ist dann alles Super?

Nö, man hat dann wieder nur die Wahl zwischen Pest und Cholera.... Der Kunde wird aber schon "zufrieden" sein, und die Schnauze halten... Dabei übersieht man, dass man das drecks gefrickel hat, und am Ende wohl nie ganz zufrieden sein wird. So Schieberegler haben psychologisch den Nachteil, das man meint, es ginge immer noch einen ticken besser. Vor allem, wenn er frei verschiebbar ist. Besser sind da ganz grobe Schritte, also z.B. nur 5 Stück und das wars.

Wird aber garantiert nicht kommen, und wenn nicht dauerhaft bleiben, wiel einer der beiden meint dem Kunden etwas "gutes" zu tun.

Genau mit dem Mist haut man aber wieder Entwicklungsgelder raus, die an den Symthomen rumdoktorn, statt wirklich die Ursache mal an zu gehen... Und dass das hier als goldene Kral (Made in China?) verkauft wird, ist nen Schuss ins eigene Bein....
 
Zuletzt bearbeitet:
Ich wollte nur zum Ausdruck bringen, dass man eben auch skeptisch sein kann ohne in eine bestimmte Fanboy-Ecke zu gehören. ;)

"Skepsis ist, was die Opposition im Parlament. Sie ist ebenso wohltätig wie notwendig." - Arthur Schopenhauer


In diesem Sinne: Was haltet ihr davon, dass "FRAPS FPS" und "Observed FPS" so perfekt zueinanderpassen? Wie erklären sich das diejenigen, die den Messungen ohne Skepsis gegenüberstehen?
 
Ich wollte nur zum Ausdruck bringen, dass man eben auch skeptisch sein kann ohne in eine bestimmte Fanboy-Ecke zu gehören. ;)




In diesem Sinne: Was haltet ihr davon, dass "FRAPS FPS" und "Observed FPS" so perfekt zueinanderpassen? Wie erklären sich das diejenigen, die den Messungen ohne Skepsis gegenüberstehen?

So sollte das normalerweiße auch sein wenn das was hinten rein geht in die Karte unverworfen vorne auch wieder raus kommt
 
Irgendetwas läuft da schief bei PC Perspective:

Eigentlich müsste es doch Unterschiede geben zwischen "FRAPS FPS" und "Observed FPS". Schaut man hingegen in die Einzeltests, passen die beiden Graphen exakt (!) übereinander, nur für Crossfire nicht. Zumindest leichte Abweichungen müsste man doch auch bei Einzelkarten messen.

Das gibt zu denken. Für mich sieht es so aus, als würde bei PC Perspective gleichzeitig FRAPS laufen, während die Messungen mit der Capture Card durchgeführt werden. Das würde das FCAT-Ergebnis verfälschen.
Dass die Graphen so exakt übereinanderpassen, stimmt mich besonders nachdenklich.

Ich habe mir zwar keine der Beispiele angeschaut, könnte mir jedoch vorstellen, dass beides gleichzeitig läuft. Denn sofern man nicht eine Timedemo hat, das nach Schema F immer und immer wieder das gleiche berechnet, hat man zwischen den Benchmarkdurchläufen immer (kleine) Abweichungen, sodass man überspitzt gesprochen unterschiedleiche Daten versucht miteinander zu vergleichen. Als einzige Lösung bliebe da lediglich die gleichzeitige Nutzung beider "Systeme". Dass man sich damit die erhobenen Daten möglicherweise selbst manipuliert, steht auf einem anderen Blatt.

Im Gegensatz zu vielen anderen Meinungen hier habe ich es bisher so verstanden, dass FCAT gedanklich von PC Perspective ins Leben gerufen wurde und in Zusammenarbeit mit NVIDIA (die vermutlich sehr gern auf diesen Zug aufgesprungen sind) zur "Marktreife" entwickelt wurde. Ich würde deshalb nicht so weit gehen und sagen, dass FCAT "von NVIDIA kommt".

Mich stören an FCAT noch ein paar Sachen:

1. Zur Auswertung der Frames benötigt man ein Overlay, welches in den normalen Renderprozess "eingeschleust" wird. Wenn ich das in den verschiedenen Artikeln richtig verstanden habe, dann funktioniert dieses Overlay genauso wie die Anzeigen von FRAPS/Afterburner. Allerdings wird immer mal wieder davon gesprochen, dass diese Overlays Inputlags hervorrufen können - ergo müssen sie die Bildberechnung irgendwie verzögern. Wenn man nun aber genau die Unterschiede in der Bildausgabe messen will, dann ist es meiner Meinung nach so ziemlich das Schlechteste was man machen kann, ein Overlay hinzuzufügen, welches möglicherweise für Verzögerungen sorgt. Man würde also nie wissen, ob kleine Unregelmäßigkeiten vom Overlay kommen oder aber von real existierenden Unregelmäßigkeiten im Renderprozess.

Grundsätzlich finde ich den Ansatz, die Bildausgabe am Grafikkartenausgang zu messen, hervorragend. Solange man dazu jedoch ein Overlay benötigt, um die gerenderten Frames auseinanderhalten zu können, habe ich Bauchschmerzen.

2. Soweit ich das verstanden habe, sind die Tools, die letztendlich die Werte in den Ergebnisdateien zu Diagrammen aufbereiten, Open source und können angepasst werden. Sofern irgendeine Redaktion hier Hand anlegt, sind die Ergebnisse zwischen den Redaktionen noch weniger vergleichbar als jetzt schon. Und wenn ich mich nicht total irre, stand in dem PCPer-Artikel auch etwas davon, dass man ein angepasstes Script verwendet hat. Der Grund dafür mag sicherlich immer gegeben sein, allerdings kann ich die Ergebnisse dann noch weniger in Relation zu meinem eigenen System sehen als jetzt schon.

3. Zwar bekommt man mit FCAT Auflösungen bis 3x 1440p hin (theoretisch bis 1600p, was aber scheinbar überall Probleme gemacht hat), höhere Auflösungen (z.B. DS oder 4K) sind damit bisher scheinbar nicht "abgreifbar". FCAT könnte also ein relativ kurzes Leben haben, wenn sich höhere Auflösungen schnell durchsetzen. Oder aber, es gibt kurzfristig Capture-Cards, die 4K unterstützen - die dann wieder gekauft werden müssen und die noch mehr Datenmengen produzieren.

Ich halte dieses Konzept für nicht sehr zukunftssicher.

Zudem sehe ich bisher nur einen Mehrwert für Multi-GPU-Setups. Für Single-GPU-Tests finde ich FCAT schlichtweg übertrieben. Schön, dass es FCAT gibt und ich werde mir mit Sicherheit auch Reviews durchlesen, wo das zukünftig genutzt wird. Doch mehr als eine Zusatzinformation wird das für mich im derzeitigen Zustand nicht werden.
 
Das Tool kommt von Nvidia, mit seiner Entwicklung hat PC Perspective nichts zu tun.
Das Overlay wird nicht in den Renderprozess "eingeschleust". FCAT befindet sich gar nicht auf dem System, mit dem getestet wird, sondern auf dem auswertenden System. Dieses auswertende System ist über eine Capture Card angeschlossen wie ein Monitor. Das auswertende System nimmt die Testsequenz auf, und erst danach findet eine Auswertung statt.
Also sollten die Messungen auch nicht durch FCAT verfälscht sein. Wenn man jetzt allerdings gleichzeitig FRAPS laufen lässt, wird es dadurch verfälscht.
 
Wenn man jetzt allerdings gleichzeitig FRAPS laufen lässt, wird es dadurch verfälscht

Sagt ja niemand das dieses simultan abgelaufen ist man kann auch Benchmarkszenarios kreieren die immer dem selben Muster folgen ohne beides auf einmal einzumessen

Der Umstand ist den Leuten sicherlich auch in den Sinn gekommen
 
Zuletzt bearbeitet:
2. Soweit ich das verstanden habe, sind die Tools, die letztendlich die Werte in den Ergebnisdateien zu Diagrammen aufbereiten, Open source und können angepasst werden. Sofern irgendeine Redaktion hier Hand anlegt, sind die Ergebnisse zwischen den Redaktionen noch weniger vergleichbar als jetzt schon. Und wenn ich mich nicht total irre, stand in dem PCPer-Artikel auch etwas davon, dass man ein angepasstes Script verwendet hat. Der Grund dafür mag sicherlich immer gegeben sein, allerdings kann ich die Ergebnisse dann noch weniger in Relation zu meinem eigenen System sehen als jetzt schon.
Dann besorg mir bitte den Quellcode, ich bin sehr! interessiert an diesem.

Das Tool kommt von Nvidia, mit seiner Entwicklung hat PC Perspective nichts zu tun.
Das Overlay wird nicht in den Renderprozess "eingeschleust". FCAT befindet sich gar nicht auf dem System, mit dem getestet wird, sondern auf dem auswertenden System. Dieses auswertende System ist über eine Capture Card angeschlossen wie ein Monitor. Das auswertende System nimmt die Testsequenz auf, und erst danach findet eine Auswertung statt.
Also sollten die Messungen auch nicht durch FCAT verfälscht sein. Wenn man jetzt allerdings gleichzeitig FRAPS laufen lässt, wird es dadurch verfälscht.
Und wie bekommt man die farbigen Balken auf die Bilder, anhand deren FCAT diese auswertet? ;)

@Scully:
Sicher?
Ich würde darauf nicht wetten. Man weiß es halt MAL WIEDER! schlicht nicht...

Und das ist ein Punkt, der für mich eben das größte Problem darstellt. Es werden SEHR diffiziele Daten erhoben/gemessen, man rückt aber nahezu 0 Informationen dazu heraus, wie denn das abgelaufen ist, und wie man es genau macht. Das ist einfach bullshit. Wenn man so was in der Form machen will, dann muss man auch die Hosen runter lassen...
 
Zuletzt bearbeitet:
@ scully1234:
Das habe ich ja noch nie gesehen, dass zwei Messungen, die derart komplex sind, exakt das gleiche Ergebnis ausspucken!
Selbst wenn man eine reproduzierbare Szene zwei Mal mit Fraps vermisst, werden Abweichungen festzustellen sein.
Und jetzt spucken FCAT und FRAPS bei zwei getrennten Messungen exakt die gleichen Ergebnisse aus? Das glaubst Du doch wohl selbst nicht.


@ Skysnake:
Oh, stimmt, die farbigen Balken... Es ist schon schwierig: Die Messung selbst verfälscht das Ergebnis.


@MusicIsMyLife:
Da habe ich wohl etwas überlesen. Dieser ganze Test scheint mir mittlerweile etwas suspekt.
 
Zuletzt bearbeitet:
Das Tool kommt von Nvidia, mit seiner Entwicklung hat PC Perspective nichts zu tun.

Mmh, wie darf man denn dieses Statement verstehen:

PCPerspective schrieb:
You may notice that there is a lot of “my” and “our” in this story while also seeing similar results from other websites being released today. While we have done more than a year’s worth of the testing and development on our own tools to help expedite a lot of this time consuming testing, some of the code base and applications were developed with NVIDIA and thus were distributed to other editors recently.

NVIDIA was responsible for developing the color overlay that sits between the game and DirectX (in the same location of the pipeline as FRAPS essentially) as well as the software extractor that reads the captured video file to generate raw information about the lengths of those bars in an XLS file.

Das bedeutet für mich, dass NVIDIA nicht die komplette Arbeit gemacht hat, sondern PCPer damit sehr wohl etwas zu tun hat/hatte.


Das Overlay wird nicht in den Renderprozess "eingeschleust".

Und wie kommt es dann dahin? Das Overlay muss auf dem Testsystem mitlaufen. Denn nachträglich kann man es ja nicht mehr einfügen, da man ja eben nicht mehr erkennen kann, wo der Framewechsel erfolgt. Es muss definitiv in den Renderprozess des Testrechners eingegriffen werden, damit man den Farbbalken pro Bild einbauen kann.

PC Perspective schrieb:
The overlay is really a very simple idea: take a solid color bar and apply it to the left hand side of every frame as it leaves the game engine, but before it gets into the graphics abstraction. By changing the color that is applied to the frame in a pre-determined, consecutive pattern, you can then produce of data from the result.



FCAT befindet sich gar nicht auf dem System, mit dem getestet wird, sondern auf dem auswertenden System. Dieses auswertende System ist über eine Capture Card angeschlossen wie ein Monitor. Das auswertende System nimmt die Testsequenz auf, und erst danach findet eine Auswertung statt.

Das ist mir schon klar. Allerdings wird aus dem ausgewerteten Video eine XLS-Datei, die dann mit verschiedenen Scripten bearbeitet werden kann. Und diese Scripte kann man offensichtlich anpassen:

PC Perspective schrieb:
While there are literally dozens of file created for each “run” of benchmarks, there are several resulting graphs that FCAT produces, as well as several more that we are generating with additional code of our own.

PC Perspective nutzt also noch eigene Scripts, die andere Redaktionen nicht nutzen. Ergo sind die Ergebnisse von vornherein nicht mehr direkt vergleichbar.



Also sollten die Messungen auch nicht durch FCAT verfälscht sein. Wenn man jetzt allerdings gleichzeitig FRAPS laufen lässt, wird es dadurch verfälscht.

Wenn man Fraps + Overlay gleichzeitig laufen lässt, können die Werte leicht verfälscht werden. Wenn man das FCAT-Overlay aber allein laufen lässt, dann bin ich nach wie vor der Meinung, dass es auch dadurch zu Unregelmäßigkeiten kommen kann. Ich sage bewusst kann. Und dadurch habe ich halt Bauchschmerzen mit dieser Methode.
 
scully1234 schrieb:
AMD hat doch bereits klipp u klar eröffnet,das sie daran arbeiten.

Was gibts da noch zu hinterfragen,wenn sich der Konzern bereits im Klaren darüber ist,das ungelöste Probleme in der Form bestehen?

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.
 
Zuletzt bearbeitet:
Werden wir ja sehen, wenn es einen entsprechenden Link dazu gibt.

Ansonsten kann man die Aussage getrost vergessen.

Die ganze Thematik wird eh etwas überhypt, und dabei völlig die Randbedingungen vergessen.
 
Tja, SLI hat die Probleme nicht. Kein höhrerer Input-Lag und eine halbwegs vernünftige Frameausgabe. Wenn AMD das nicht schafft, sollten sie wenigsten kein Geld ins virale Marketing stecken, um existierende Probleme zu verschleiern. Das ist asozial den eigenen Kunden gegenüber.
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.
 
Es ist immerhin schon mal ein gutes Zeichen, dass die Framerates bei AMD auf einer Single GPU auf Nvidia Niveau legen, ergo scheints wirklich nur ein Crossfireproblem zu sein und wahrscheinlich ist die Vermutung, dass Nvidia hier etwas "dreht" eher unwahrscheinlich.
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. ;)
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh