SLI / CF Microruckler bewiesen
- Ersteller Bernieserver
- Erstellt am
Bernieserver
Fleet Captain Special
Hallo,
ich bin beim surfen auf eine neue News bei PCGH gestossen, die ich Euch natürlich nicht vorenthalten moechte. Denn: Die Microrucklergeschichte bei Multi-GPU Rendering (ja auch die 3870 X2) ist leider wahr, zumindest bei einigen Spielen:
PCGH Microrucklerbeweis
Auch ATI hat sich schon dazu geäussert und das auch auf die Spielehersteller geschoben.
Das Video kann ich mir mit meiner derzeitigen Anbindung nicht ansehen. Es soll zeigen wie es bei UT3 mit CF bei einer hoeheren Framerate mehr ruckelt als ohne CF. Der Grund dafuer ist, dass die Frames nicht in gleichen Abstaenden zueinander ausgegeben werden, sondern ein Versatz herrscht. Hier ein Beispiel:
10ms dauert es bis Frame 1 angezeigt wierd, dann 40ms spaeter kommt erst Frame 2 und dann 10ms spaeter zu Frame 3 schon Frame 4, dann ewig weiter: 40ms, 10ms, 40ms,10ms.... etc.
So ist zwar die Framerate bei Benchmarks hoch, aber die gefuehlte Framerate niedriger, fast so wie bei nur einer Grafikkarte. Die wuerde dann zwar nur alle 10ms+40ms ein Bild ausgeben, aber es ist gleichmaessiger.
Um das zu beheben wäre eine komplett andere Aufteilung des Bildes auf die Grakas und eine andere Synchronisation nötig. Schaut nicht gut aus für die aktuelle Multi GPU Generation, das wird sich wohl treiberseitig nur schwer aendern lassen, ohne dass da die Performance massiv einbricht. Wenn man z.B. quasi die SLI Methode der Voodo2 verwenden wuerde ( interlaced ) muesste jede Grafikkarte trotzdem ALLE Pixelshader fuer sich berechnen. Aber liest einfach selber den Bericht und die dazu passenden Comments.
Gruß
Bernhard
ich bin beim surfen auf eine neue News bei PCGH gestossen, die ich Euch natürlich nicht vorenthalten moechte. Denn: Die Microrucklergeschichte bei Multi-GPU Rendering (ja auch die 3870 X2) ist leider wahr, zumindest bei einigen Spielen:
PCGH Microrucklerbeweis
Auch ATI hat sich schon dazu geäussert und das auch auf die Spielehersteller geschoben.
Das Video kann ich mir mit meiner derzeitigen Anbindung nicht ansehen. Es soll zeigen wie es bei UT3 mit CF bei einer hoeheren Framerate mehr ruckelt als ohne CF. Der Grund dafuer ist, dass die Frames nicht in gleichen Abstaenden zueinander ausgegeben werden, sondern ein Versatz herrscht. Hier ein Beispiel:
10ms dauert es bis Frame 1 angezeigt wierd, dann 40ms spaeter kommt erst Frame 2 und dann 10ms spaeter zu Frame 3 schon Frame 4, dann ewig weiter: 40ms, 10ms, 40ms,10ms.... etc.
So ist zwar die Framerate bei Benchmarks hoch, aber die gefuehlte Framerate niedriger, fast so wie bei nur einer Grafikkarte. Die wuerde dann zwar nur alle 10ms+40ms ein Bild ausgeben, aber es ist gleichmaessiger.
Um das zu beheben wäre eine komplett andere Aufteilung des Bildes auf die Grakas und eine andere Synchronisation nötig. Schaut nicht gut aus für die aktuelle Multi GPU Generation, das wird sich wohl treiberseitig nur schwer aendern lassen, ohne dass da die Performance massiv einbricht. Wenn man z.B. quasi die SLI Methode der Voodo2 verwenden wuerde ( interlaced ) muesste jede Grafikkarte trotzdem ALLE Pixelshader fuer sich berechnen. Aber liest einfach selber den Bericht und die dazu passenden Comments.
Gruß
Bernhard
Zuletzt bearbeitet:
Bernieserver
Fleet Captain Special
"schieb"
Ich habe noch ein bisschen was ergaenzt. Vielleicht ist es so interessanter.
Gruss
Bernhard
Ich habe noch ein bisschen was ergaenzt. Vielleicht ist es so interessanter.
Gruss
Bernhard
Andy06
Grand Admiral Special
ja ist es 
aber mir fallen bei NFS nur die dollen ruckler auf. und die sind ja mit und ohne crossfire... hmm
bei dem shooter (oder was das sein soll) fällt es mehr auf. wobei ich es ohne crossfire auch nicht viel besser finde
vielleicht würde es was bringen, wenn die sich mal nen PC kaufen
aber mir fallen bei NFS nur die dollen ruckler auf. und die sind ja mit und ohne crossfire... hmm
bei dem shooter (oder was das sein soll) fällt es mehr auf. wobei ich es ohne crossfire auch nicht viel besser finde
vielleicht würde es was bringen, wenn die sich mal nen PC kaufen
Zuletzt bearbeitet:
Bernieserver
Fleet Captain Special
Hallo,
also NFS:C scheint wohl ein eher schlecht programmierter Consolen-Port zu sein, wenn man den Comments dort Glauben schenken kann. (ich selber habe es nie gespielt) Aber bei UT3 ist das schon gravierender. Das ist ja eine Engine, auf der sicherlich in Zukunft weitere, komplexe Spiele aufbauen werden, wo sich eine SLI Lösung rentieren würde.
Aber jetzt das ganze Problem nochmal, um das noch ein bisschen besser auszudrücken:
Wenn man mal krasserweise davon ausgeht, dass die Framereihenfolge wie folgt wäre: (der zeitliche Versatz, ich nenne es mal Jitter, ist das Problem, dass die MultiGPU Karten ja gerade haben)
F1 -> F2: 60ms, F2 -> F3: 5ms, F3 -> F4: 60ms, ... 5ms,... 60ms ... 5ms,... 60ms ... etc. wäre die zweite Karte total unnötig.
Denn das was man allgemein als "Ruckeln" empfindet ist ja eine zu hohe maximale Zeit zwischen zwei Einzelbildern, die ja hier max. 60ms beträgt. Die 5ms zwischen den kurz aufeinanderfolgenden Frames gehen da im gesamten "Ruckeleindruck" unter, die 60ms Lücke sticht hier hervor und der Eindruck des Spiels ist daher nicht flüssig. Es fühlt sich so eher nach 8fps an, obwohl 15fps im framecounter stehen.
Wenn man jetzt statt zwei nur einen Chip verwendet, der eine konstante Framerate mit konstanten Bildabständen hat ( weil ja hier keine Synchronisationsprobleme auftreten können ), so ist der Verlust der Hälfte der Framerate überhaupt nicht tragisch, da dann der max. Abstand zwischen zwei Frames 65ms, also nur 5ms mehr betragen würde. ( einfach jeden zweiten Frame weglassen und die Zeiten addieren). Also prozentual gesehen ist das vernachlässigbar, nur bei PenisMark [TM] hat man dann halt am Ende eine höhere Zahl stehen.
Insgesamt lohnt sich daher der Aufpreis einer NVidia SLI oder ATI CF Lösung oder halt der 3870 X2 bei diesen Problemen überhaupt nicht, da können die benchen soviel die wollen.
Daher ist der ganze Fehler ja so kritisch, daran muss auf jeden Fall dran gearbeitet werden. Komisch nur, dass diese Sache nicht schon lange vorher bekannt ist. Denn SLI gibt es jetzt schon seit längerem.
Zocken die Hardwareseiten beim Benchen niemals mal irgendein Spiel an? Dann hätte das den Testern ja auffallen müssen.... aber so?
Aber ich finde, das sollte mal in den News erwähnt werden.( vor Allem wg. dem ATI Comment. )
Gruß
Bernhard
also NFS:C scheint wohl ein eher schlecht programmierter Consolen-Port zu sein, wenn man den Comments dort Glauben schenken kann. (ich selber habe es nie gespielt) Aber bei UT3 ist das schon gravierender. Das ist ja eine Engine, auf der sicherlich in Zukunft weitere, komplexe Spiele aufbauen werden, wo sich eine SLI Lösung rentieren würde.
Aber jetzt das ganze Problem nochmal, um das noch ein bisschen besser auszudrücken:
Wenn man mal krasserweise davon ausgeht, dass die Framereihenfolge wie folgt wäre: (der zeitliche Versatz, ich nenne es mal Jitter, ist das Problem, dass die MultiGPU Karten ja gerade haben)
F1 -> F2: 60ms, F2 -> F3: 5ms, F3 -> F4: 60ms, ... 5ms,... 60ms ... 5ms,... 60ms ... etc. wäre die zweite Karte total unnötig.
Denn das was man allgemein als "Ruckeln" empfindet ist ja eine zu hohe maximale Zeit zwischen zwei Einzelbildern, die ja hier max. 60ms beträgt. Die 5ms zwischen den kurz aufeinanderfolgenden Frames gehen da im gesamten "Ruckeleindruck" unter, die 60ms Lücke sticht hier hervor und der Eindruck des Spiels ist daher nicht flüssig. Es fühlt sich so eher nach 8fps an, obwohl 15fps im framecounter stehen.
Wenn man jetzt statt zwei nur einen Chip verwendet, der eine konstante Framerate mit konstanten Bildabständen hat ( weil ja hier keine Synchronisationsprobleme auftreten können ), so ist der Verlust der Hälfte der Framerate überhaupt nicht tragisch, da dann der max. Abstand zwischen zwei Frames 65ms, also nur 5ms mehr betragen würde. ( einfach jeden zweiten Frame weglassen und die Zeiten addieren). Also prozentual gesehen ist das vernachlässigbar, nur bei PenisMark [TM] hat man dann halt am Ende eine höhere Zahl stehen.
Insgesamt lohnt sich daher der Aufpreis einer NVidia SLI oder ATI CF Lösung oder halt der 3870 X2 bei diesen Problemen überhaupt nicht, da können die benchen soviel die wollen.
Daher ist der ganze Fehler ja so kritisch, daran muss auf jeden Fall dran gearbeitet werden. Komisch nur, dass diese Sache nicht schon lange vorher bekannt ist. Denn SLI gibt es jetzt schon seit längerem.
Zocken die Hardwareseiten beim Benchen niemals mal irgendein Spiel an? Dann hätte das den Testern ja auffallen müssen.... aber so?
Aber ich finde, das sollte mal in den News erwähnt werden.( vor Allem wg. dem ATI Comment. )
Gruß
Bernhard
Zuletzt bearbeitet:
Da wurde im 3DCenter auch schon einiges drüber geschrieben.
Naja, ich finds eigentlich ganz gut so, vielleicht hindert das einiges Leute daran sich so unnötige Doppel-/Dreifach-/Vierfachgrafikkartenmonstersysteme zu kaufen.
Naja, ich finds eigentlich ganz gut so, vielleicht hindert das einiges Leute daran sich so unnötige Doppel-/Dreifach-/Vierfachgrafikkartenmonstersysteme zu kaufen.
wadenbeisser
Vice Admiral Special
- Mitglied seit
- 03.12.2007
- Beiträge
- 825
- Renomée
- 2
Existiert das Problem auch mit Vsync?
Bernieserver
Fleet Captain Special
Hallo,
ich denke vsync maskiert das Problem wenn ueberhaupt nur. Ich denke, wenn das Grafikkartengespann ohne vsync eine sehr hohe framerate schaffen wuerde, wuerde vsync das "beheben".
Aber was ist bei zukuenfigen Spielen, die Du noch bei 40fps spielen wirst ? Das wird sich dann im schlechtestem Falle wie 20fps anfuehlen.
@ Kommando: Ich denke in Zukunft wird mehr auf MultiGPU gesetzt. Daher ist das KEIN Freak - Problem.
Gruss
Bernhard
ich denke vsync maskiert das Problem wenn ueberhaupt nur. Ich denke, wenn das Grafikkartengespann ohne vsync eine sehr hohe framerate schaffen wuerde, wuerde vsync das "beheben".
Aber was ist bei zukuenfigen Spielen, die Du noch bei 40fps spielen wirst ? Das wird sich dann im schlechtestem Falle wie 20fps anfuehlen.
@ Kommando: Ich denke in Zukunft wird mehr auf MultiGPU gesetzt. Daher ist das KEIN Freak - Problem.
Gruss
Bernhard
Dann müsste eigentlich logisch gesehen ein Quad-CrossfireX mit 4 Radeon HD 3850 eigentlich diese Microruckler nicht so ausgeprägt haben; vorausgesetzt das spiel skaliert relativ schön mit jeder weiteren GPU.
das stell ich jetzt einfach mal so in den raum zur diskussion.
das stell ich jetzt einfach mal so in den raum zur diskussion.
Es ist egal wie viel Grafikkarten ob SLI oder CF sie sind immer vorhanden, da es ein Timing Problem bei des Synchronisation der Frames gibt.
Bernieserver
Fleet Captain Special
Das sehe ich genauso.
Man muss in Zukunft garantieren können, dass die Frames immer mit gleichem Abstand zueinander folgen, dann kann man ruhig auf dem Multi GPU Zug aufspingen.
Und auch wenn man derzeitig 4, 8, 16 etc. Cores verwendet, das Problem wird bestehen. Nur verschiebt sich dann das Problem zeitlich nach "hinten".
Aber dann ist es egal ob die Framefolge
10 -> 50 -> 10 -> 50 ... ms
bei 2 Cores oder
10 -> 30 -> 5 -> 75 -> 10 -> 30 -> 5 -> 75 ... ms
bei 4 Cores ( bei doppelt so hoher Grafikkomplexibilität in einem zukünftigem Spiel) beträgt. In diesem Beispiel wäre das dann ja noch schlimmer.
Gut, bei gleicher Grafikkomplexität wäre dass dan
5 -> 15 -> 2,5 -> 37,5 -> 5 -> 15 -> 2,5 -> 37,5 ... ms
ok, wie immer gesagt ein krasses Beispiel zur Veranschaulichung.
Aber: Jitter is Evil !
Gruß
Bernhard
Zuletzt bearbeitet:
![[³dgamer]](/data/avatars/m/25/25369.jpg?1596828194){kind=avatar}
[³dgamer]
Grand Admiral Special
- Mitglied seit
- 08.02.2005
- Beiträge
- 2.018
- Renomée
- 38
Man wird das Gefühl nicht los das diese ganze SLI-Geschichte insgesamt einfach falsch aufgezogen wurde.
Anwendungen die für mehrere Kerne optimiert werden, teilen anfallene Threads "einfach" auf die Kerne auf. Die Bildberechnung aber aufteilen ist (wenn ich mir das in Gedanken rufe was ich darüber bisher gelesen habe) ungleich schwieriger. Wenn man z.B. Cinebench auf nem Quad sich anschaut fällt sofort auf, das der eine Kern bereits fertig mit seiner Teilaufgabe ist (Fußboden rendern), ein andere aber grad mal 60% hat. Die verbleibenen (unfertigen) Bereiche werden dann nach einer sehr kurzen Pause neu vergeben usw.
Die Grundlage aktueller GPUs wurde aber eigentlich für die alleine Bildberechnung gebaut.
Bei den damaligen du-ein-Bild-ich-ein-Bild-Voodoo-SLI-Systemen wären solche Mikroruckler eigentlich nicht vorstellbar. Ein Bild durch mehrere GPUs berechnen zu lassen ist in der Praxis aber bisher nicht wirklich von Erfolg gekrönt
Anwendungen die für mehrere Kerne optimiert werden, teilen anfallene Threads "einfach" auf die Kerne auf. Die Bildberechnung aber aufteilen ist (wenn ich mir das in Gedanken rufe was ich darüber bisher gelesen habe) ungleich schwieriger. Wenn man z.B. Cinebench auf nem Quad sich anschaut fällt sofort auf, das der eine Kern bereits fertig mit seiner Teilaufgabe ist (Fußboden rendern), ein andere aber grad mal 60% hat. Die verbleibenen (unfertigen) Bereiche werden dann nach einer sehr kurzen Pause neu vergeben usw.
Die Grundlage aktueller GPUs wurde aber eigentlich für die alleine Bildberechnung gebaut.
Bei den damaligen du-ein-Bild-ich-ein-Bild-Voodoo-SLI-Systemen wären solche Mikroruckler eigentlich nicht vorstellbar. Ein Bild durch mehrere GPUs berechnen zu lassen ist in der Praxis aber bisher nicht wirklich von Erfolg gekrönt
Bernieserver
Fleet Captain Special
Und das mit dem "ein Frame du und ein Frame ich" geht wohl leider heute nicht mehr so wie damals, als es noch keine Shader gab.
Denn wie will man die Pixelshader synchronisieren? Die hängen ja oftmals vom Frame vorher ab. Also müsste jede Grafikkarte jeden Frame in seinem Speicher haben und dann für jeden Frame die Pixelshader ( also die AfterEffects ) berechnen, aber dann am Ende jedes zweite Frame verwerfen, da ja zwischen den Cores abgewechselt werden soll... irgendwie sinnlos, und der Performancegewinn eher 20%, da nur die Füllrate und andere konventionelle nichtshadersachen verdoppelt wird...
EDIT: Damn, massiver Denkfehler! So macht man aus einer Parallelabarbeitung eine serielle mit Wartezyklen
Da ist es besser, wenn man nur einen gemeinsamen Framebuffer für beide verwendet, am Besten sogar gemeinsamen Video Speicher ( also umgekehrtes Memory Interleaving quasi, also 1 Frame darf GPU 1 den RAM haben, danach 1 Frame GPU 2. ). Dann kann man das Vorbild vom anderem Prozessor quasi direkt bearbeiten und man kann dann die 3dfx Methode wieder verwenden.
Aber selbst dann ist das sicher eine sehr komplexe Angelegenheit. Und nicht gerade mal eben mit Treiber - Patches zu beheben. Auch wäre das dann mehr wie eine Single Karte, denn die Grafikkerne sind ja eh schon parallelisiert und 2x parallelisiert ist dann immer noch parallelisiert
Ich vermute, dass es ja derzeitig bei SLI / CF so abläuft: jede Grafikkarte bekommt ein Bildteilstück zugewiesen. Also berechnet jede Grafikkern bei jedem Frame den gleichen Bereich. Dann wird das Bild in einem der beiden Framebuffer wieder zusammengesetzt und am Moni ausgegeben. Natürlich sind die Teile recht klein, damit sich die Belastung besser verteilt.
So kann man Pixelshader gut auf die Karten verteilen, da jede Grafikkarte nur das Teilbild berechnet und die Frames im Teilstück aufeinander folgen. Aber wie Du schon angedeutet hast, ist das bei Grafik schwierig, wenn die Komplexität der einen Graka nicht die der anderen Graka entspricht. Vielleicht liegt da der Hund begraben. Es ist nicht vorhersehbar, wann die jeweils andere Grafikkarte fertig ist. Man könnte höchstens sowas wie ein Puffer einfügen, der zwei Frames zwischenspeichert um sie dann mit gleichem Abstand rauszugeben. Das wiederrum macht bei niedrigen FPS einen massiven Imput Lag, der wiederrum genauso ist, wie der OHNE SLI /CF (eine Karte ohne Buffer). Das ist für Shooter nicht tragbar. Die Hand - Auge Koordination ist schon schneller als 25 fps wie beim passivem Fernsehen mit Bewegungsunschärfe
Ach, wie werden eigentlich letztendlich die Bilderstücke bei Multi GPU abgearbeitet? Seriell oder Parallel?
Gruß
Bernhard
Denn wie will man die Pixelshader synchronisieren? Die hängen ja oftmals vom Frame vorher ab. Also müsste jede Grafikkarte jeden Frame in seinem Speicher haben und dann für jeden Frame die Pixelshader ( also die AfterEffects ) berechnen, aber dann am Ende jedes zweite Frame verwerfen, da ja zwischen den Cores abgewechselt werden soll... irgendwie sinnlos, und der Performancegewinn eher 20%, da nur die Füllrate und andere konventionelle nichtshadersachen verdoppelt wird...
EDIT: Damn, massiver Denkfehler! So macht man aus einer Parallelabarbeitung eine serielle mit Wartezyklen
Da ist es besser, wenn man nur einen gemeinsamen Framebuffer für beide verwendet, am Besten sogar gemeinsamen Video Speicher ( also umgekehrtes Memory Interleaving quasi, also 1 Frame darf GPU 1 den RAM haben, danach 1 Frame GPU 2. ). Dann kann man das Vorbild vom anderem Prozessor quasi direkt bearbeiten und man kann dann die 3dfx Methode wieder verwenden.
Aber selbst dann ist das sicher eine sehr komplexe Angelegenheit. Und nicht gerade mal eben mit Treiber - Patches zu beheben. Auch wäre das dann mehr wie eine Single Karte, denn die Grafikkerne sind ja eh schon parallelisiert und 2x parallelisiert ist dann immer noch parallelisiert
Ich vermute, dass es ja derzeitig bei SLI / CF so abläuft: jede Grafikkarte bekommt ein Bildteilstück zugewiesen. Also berechnet jede Grafikkern bei jedem Frame den gleichen Bereich. Dann wird das Bild in einem der beiden Framebuffer wieder zusammengesetzt und am Moni ausgegeben. Natürlich sind die Teile recht klein, damit sich die Belastung besser verteilt.
So kann man Pixelshader gut auf die Karten verteilen, da jede Grafikkarte nur das Teilbild berechnet und die Frames im Teilstück aufeinander folgen. Aber wie Du schon angedeutet hast, ist das bei Grafik schwierig, wenn die Komplexität der einen Graka nicht die der anderen Graka entspricht. Vielleicht liegt da der Hund begraben. Es ist nicht vorhersehbar, wann die jeweils andere Grafikkarte fertig ist. Man könnte höchstens sowas wie ein Puffer einfügen, der zwei Frames zwischenspeichert um sie dann mit gleichem Abstand rauszugeben. Das wiederrum macht bei niedrigen FPS einen massiven Imput Lag, der wiederrum genauso ist, wie der OHNE SLI /CF (eine Karte ohne Buffer). Das ist für Shooter nicht tragbar. Die Hand - Auge Koordination ist schon schneller als 25 fps wie beim passivem Fernsehen mit Bewegungsunschärfe
Ach, wie werden eigentlich letztendlich die Bilderstücke bei Multi GPU abgearbeitet? Seriell oder Parallel?
Gruß
Bernhard
Zuletzt bearbeitet:
G
Gast29012019_2
Guest
Kann man den PCI-E Bus als Fehlerquelle ausschließen, da der in den Latenzen langsamer ist als der PCI-Bus ! - und so oder so die Karten sich über den BUS und der internen Verbindung der Brücken zeitlich koordinieren müssen. Vielleicht ist das technisch nicht möglich, oder man müßte den Karten eine Art schnellen Bildzwischen-Speicher verpassen, damit trotzdem immer ein Bild in gleicher Zeit erzeugt werden kann, auch wenn es zeitlich Probleme gibt.
Full HD-Fernseher, haben speziell dafür Rechneneinheiten drin die beim hochrechnen der Bilder sehr schnell müssen, damit eben solche Probleme nicht gibt. Wäre fatal wenn erforderlichen Berechnungen zeitlich nicht koordiniert werden können. Wenn diese Art der Berechnung vgl. mit denen einer Grafikkarte bezogen auf diese Thematik vergleichbar ist.
Aber das wäre leicht zu beweisen, ob der PCIe Express hier Probleme macht, indem man den Test mit einer Dual-GPU Karte macht. Die arbeiten ja ebenfalls in SLI wenngleich alles auf einer Karte steckt und hier nur volle Performance erreicht wird, wenn die Karten in einem Mobo mit NV-Chipsatz gesteckt werden.
Wenn der Fehler hier nicht auftritt, ist der PCIe Express Bus ein mitwirkender Problemfaktor !
Full HD-Fernseher, haben speziell dafür Rechneneinheiten drin die beim hochrechnen der Bilder sehr schnell müssen, damit eben solche Probleme nicht gibt. Wäre fatal wenn erforderlichen Berechnungen zeitlich nicht koordiniert werden können. Wenn diese Art der Berechnung vgl. mit denen einer Grafikkarte bezogen auf diese Thematik vergleichbar ist.
Aber das wäre leicht zu beweisen, ob der PCIe Express hier Probleme macht, indem man den Test mit einer Dual-GPU Karte macht. Die arbeiten ja ebenfalls in SLI wenngleich alles auf einer Karte steckt und hier nur volle Performance erreicht wird, wenn die Karten in einem Mobo mit NV-Chipsatz gesteckt werden.
Wenn der Fehler hier nicht auftritt, ist der PCIe Express Bus ein mitwirkender Problemfaktor !
Zuletzt bearbeitet:
Bernieserver
Fleet Captain Special
Hallo,
ich denke die Upscaler in Fernseher haben das Problem nicht, da die quasi wie Filter arbeiten, also dessen Leistung nicht oder nur sehr gering vom Bildmaterial abhängt.
Falls Du mal Zeit hast, teste mal folgendes als Benchmark: hole verschiedene Bilder und versuche die mal mit irfanview auf einem altem Rechner (300Mhz )mal auf eine 4x so hohe Auflösung hochzuskalieren ( mit dem dickstem Filter , dem Lanczos, denke ich mal ) und miss dann mal die Zeit. Nimm auch mal ein weißes Bild. Ich vermute die Berechnung dauert immer gleich lang, wenn die Ursprungsbilder alle gleich aufgelöst sind.
Oder nimm mal ne 30s. lange "stumme" Wav Datei (44kHz / 16bit) und versuche die mal mit nem Audioeditor auf 24bit /96 kHz hochzuskalieren. Dann das Selbe mit einem 30s. langem Musikausschnitt.Miss auch hier die Zeit. Ich denke da ist das eindeutiger und so sicherlich upscalertheorieen nicht auf grafikkarten anwendbar.
Aber genau weiß ich das auch nicht, sind nur Vermutungen.
Gruß
Bernhard
ich denke die Upscaler in Fernseher haben das Problem nicht, da die quasi wie Filter arbeiten, also dessen Leistung nicht oder nur sehr gering vom Bildmaterial abhängt.
Falls Du mal Zeit hast, teste mal folgendes als Benchmark: hole verschiedene Bilder und versuche die mal mit irfanview auf einem altem Rechner (300Mhz
)mal auf eine 4x so hohe Auflösung hochzuskalieren ( mit dem dickstem Filter , dem Lanczos, denke ich mal ) und miss dann mal die Zeit. Nimm auch mal ein weißes Bild. Ich vermute die Berechnung dauert immer gleich lang, wenn die Ursprungsbilder alle gleich aufgelöst sind.Oder nimm mal ne 30s. lange "stumme" Wav Datei (44kHz / 16bit) und versuche die mal mit nem Audioeditor auf 24bit /96 kHz hochzuskalieren. Dann das Selbe mit einem 30s. langem Musikausschnitt.Miss auch hier die Zeit. Ich denke da ist das eindeutiger und so sicherlich upscalertheorieen nicht auf grafikkarten anwendbar.
Aber genau weiß ich das auch nicht, sind nur Vermutungen.
Gruß
Bernhard
Andy06
Grand Admiral Special
[³dgamer];3512931 schrieb:Bei den damaligen du-ein-Bild-ich-ein-Bild-Voodoo-SLI-Systemen wären solche Mikroruckler eigentlich nicht vorstellbar. Ein Bild durch mehrere GPUs berechnen zu lassen ist in der Praxis aber bisher nicht wirklich von Erfolg gekrönt
haben die damals nicht jeweils ein halbes bild berechnet?? eine die obere-, die andere die untere Hälfte??
G
Gast29012019_2
Guest
Hallo,
ich denke die Upscaler in Fernseher haben das Problem nicht, da die quasi wie Filter arbeiten, also dessen Leistung nicht oder nur sehr gering vom Bildmaterial abhängt.
Falls Du mal Zeit hast, teste mal folgendes als Benchmark: hole verschiedene Bilder und versuche die mal mit irfanview auf einem altem Rechner (300Mhz
Oder nimm mal ne 30s. lange "stumme" Wav Datei (44kHz / 16bit) und versuche die mal mit nem Audioeditor auf 24bit /96 kHz hochzuskalieren. Dann das Selbe mit einem 30s. langem Musikausschnitt.Miss auch hier die Zeit. Ich denke da ist das eindeutiger und so sicherlich upscalertheorieen nicht auf grafikkarten anwendbar.
Aber genau weiß ich das auch nicht, sind nur Vermutungen.
Gruß
Bernhard
Gut, leider kenne ich mich selbst damit auch nicht wirklich aus, ebend nur das die Fernseher halt scheinbar diese schnellen Rechner nötig hat. Leider habe ich keinen 300Mhz Rechner. Das langsamste sind hier 800/1,2GHz mit nem P3 Läppi.
Bernieserver
Fleet Captain Special
Hmm, das mit der Audio File kannste aber auch mit jedem Rechner versuchen, indem du einfach längere Ausschnitte nimmst. Am Besten arbeitest Du auf einer RAM Disk, damit die Platten nicht zum Flaschenhals werden.
Aber das wird jetzt zu offtopic jetzt.
Gruß
Bernhard
[³dgamer]
Grand Admiral Special
- Mitglied seit
- 08.02.2005
- Beiträge
- 2.018
- Renomée
- 38
Ja, ich glaube genau das ist das Kernproblem. Wenn man das Bild in sehr sehr sehr kleine Stücke zerteilen würde, könnte man es hinbekommen, dass die GPUs in praktisch derselben Zeit fertig sind. Nur das erfordert natürlich wieder Koordinierungsaufwand/zeit und der Perfomancevorteil gegenüber SingleChip würde wieder geringer werden...schwierig.
Ich dachte das wäre so gewesen, aber ich habe folgendes gefunden:
Das ist doch eher genau das Gegenteil von dem was wir vermutet haben, oder
foenfrisur
Grand Admiral Special
- Mitglied seit
- 19.02.2002
- Beiträge
- 4.791
- Renomée
- 77
aber ist es nicht so, das diese ruckler nur bei kleiner 30fps auftreten, bzw. bemerkbar sind?
da spielt man doch ohnehin so gut wie nie oder?
insofern kann man das problem ja vorerst vernachlässigen.
mfg
da spielt man doch ohnehin so gut wie nie oder?
insofern kann man das problem ja vorerst vernachlässigen.
mfg
G
Gast29012019_2
Guest
Da es ja um Zeitprobleme geht, und dies nur bei Dual-GPU oder SLI/CF Situationen vorkommt, kombiniere ich meinen Gedanken mal mit dieser 2 Verknüpfung.
Klick -> http://www.planet3dnow.de/vbulletin/showthread.php?t=292361
Die Logik sagt mir daraufhin, das das Problem was Nvidia und ATI hier haben, eine ähnliches ist was AMD mit seinen Dual-Cores hat.
Intel hat diese Probleme nicht, bei seinen Dual-Core CPUs. AMD brachte als Lösung den AMD Dual Core Optimizer raus, der das Problem mit den Programmen und Spielen lösen sollte.
Nun meine Frage, liege ich mit meiner Vermutung richtig ?
Falls ja, braucht ATI(AMD) oder NV eine Software bringen die das ausgleichen kann oder muß versuchen, das gleiche zu machen wie bei Intel und schon sind Microruckler passe.
Klick -> http://www.planet3dnow.de/vbulletin/showthread.php?t=292361
Die Logik sagt mir daraufhin, das das Problem was Nvidia und ATI hier haben, eine ähnliches ist was AMD mit seinen Dual-Cores hat.
Intel hat diese Probleme nicht, bei seinen Dual-Core CPUs. AMD brachte als Lösung den AMD Dual Core Optimizer raus, der das Problem mit den Programmen und Spielen lösen sollte.
Nun meine Frage, liege ich mit meiner Vermutung richtig ?
Falls ja, braucht ATI(AMD) oder NV eine Software bringen die das ausgleichen kann oder muß versuchen, das gleiche zu machen wie bei Intel und schon sind Microruckler passe.
G
Gast29012019_2
Guest
Hi..
Hier noch ein Link, ...
http://www.pcgameshardware.de:80/ai...oruckler_Erste_Statements_von_AMD_und_Nvidia/
Hier noch ein Link, ...
http://www.pcgameshardware.de:80/ai...oruckler_Erste_Statements_von_AMD_und_Nvidia/
[³dgamer]
Grand Admiral Special
- Mitglied seit
- 08.02.2005
- Beiträge
- 2.018
- Renomée
- 38
Erstaunlicherweise gibt es (bezogen auf Kommentare & Beiträge) kaum Leute, die solche "Ruckler"gesehen bzw. gespürt haben.
Die Frage dabei ist, wieviel würde ein Patch optisch oder gefühlt bringen?
Evtl. fällt den meisten SLI/CF Besitzern dann erst auf das es dadurch besser wurde?
Die Frage dabei ist, wieviel würde ein Patch optisch oder gefühlt bringen?
Evtl. fällt den meisten SLI/CF Besitzern dann erst auf das es dadurch besser wurde?
foenfrisur
Grand Admiral Special
- Mitglied seit
- 19.02.2002
- Beiträge
- 4.791
- Renomée
- 77
das dürfte wohl daran liegen, das es eben unter 30 fps erst stark bemerkbar ist 
und da spielt eben fast niemand
mfg
und da spielt eben fast niemand
mfg
Zuletzt bearbeitet:
[³dgamer]
Grand Admiral Special
- Mitglied seit
- 08.02.2005
- Beiträge
- 2.018
- Renomée
- 38
Da könnte man natürlich mit Crysis dagegenhalten, aber ich meinte auch etwas anderes. Unterbewußt hat man bei vielen Dingen ja schonmal das Gefühl "da stimmt was nicht", wenn z.B. etwas nur minimal schief ist, oder die Farben nicht 100%ig stimmen o.ä., ohne dass man aber auf Anhieb sagen kann was es ist.das dürfte wohl daran liegen, das es eben unter 30 fps erst stark bemerkbar ist
und da spielt eben fast niemand
Daher würde mich interessieren, ob jemand der z.B. etwas mit ~45fps spielt den Unterschied zwischen Mikrorucklern und keinen Mikrorucklern fühlen kann (wenn es denn eine Lösung dafür gibt).
Ähnliche Themen
