Aber selbst wenn man hier irgendetwas macht, entscheidend ist doch trotzdem wie die Frames beim User ankommen?
Wenn Nvidia hier etwas anpasst, dann ist das doch eigentlich positiv. Schummelei kann also nochmal wie geschehen?
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.
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?
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... -.-
Und um die Verschwörungstheoretiker mal abzufangen, glaubt wirklich jemand daran, dass man mit so einem Tool schummelt, der Schaden wenn das rauskommen würde ist viel größer wie der Gewinn den man aktuell daraus ziehen kann.
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
" 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...
Ich denke eher das sich NV hier sehr sicher ist, dass das Problem unvorbereitet nicht ohne weiteres zu lösen ist, sonst würden sie nicht so absolut offen damit umgehen den FCAT zeigt ja auch die Probleme die NV hat, es ist ja nicht so das dort keine vorhanden sind nur deutlich weniger eben wie aktuell bei CF Systemen, das AMD ja auch angekündigt hat, dass man mit der kommenden Generation eine wesentlich feinere Boostfunktion einbauen möchte macht den Vorteil dann sicherlich zu nichte, also macht man das Problem publik solange man daraus ein Vorteil für die eigenen HW ableiten kann, AMD wird es aufgrund der relativ hohen Akzeptanz von Online-Magazinen, schwer haben das wieder gerade zu rücken, auch wenn das Problem dann vielleicht gar nicht mehr vorhanden ist, das ist so wie mit den Treibern, die sind schon lange nicht mehr schlechter wie die von NV das hält sich aber trotzdem hartnäckig in den Köpfen der Spieler.
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.
und können in HW nicht gegen steuern. Mal zum Vorgang, GPU Rendert ein Bild und Haut es raus, GPU hat in der Zwischenzeit auch an einem Bild gearbeitet und schickt die Anfrage an GPU 1 biste fertig, kann ich, während dies passiert, arbeitet GPU1 aber auch schon wieder an einem Bild, was dann kommt ist 1--- 23---45--67--89 usw. 
