microruckler vs. 3dfx - umso mehr leistung gefragt wird..

[ZilD]

hallo

hier ein thema von der pc games hardware über microruckler
http://www.pcgameshardware.de/aid,641923/Test/Benchmark/3DMark_Vantage_Die_Rueckkehr_des_Mikroruckelns/

für mich hat es den anschein das sli und cf genau dann am meisten versagt wenn man es brauchen würde - also in allen titeln die viel grafikleistung brauchen.

wird das problem jemals durch einen treiber halbwegs gelöst werden können, oder muss eine neue technologie her?
komisch!

wie war das bei 3dfx ? mir sind nie microruckler aufgefallen.

beste grüsse
zild

[robbitop]

wie war das bei 3dfx ? mir sind nie microruckler aufgefallen.

beste grüsse
zild
Weil 3dfx kein AFR eingesetzt hat, sondern SLi. Bei ersterem rendern beide GPUs unabhängig voneinander 2 aufeinanderfolgende Bilder, deren zeitliche Differenz von der CPU abhängt.
Beim SLi-Verfahren arbeiten beide GPUs an einem Bild und die zeitliche Differenz zwischen zwei aufeinanderfolgende Bilder bleibt homogen.
Natürlich ist das vereinfacht dargestellt, da um es besser zu erklären, von konstanter Framerate ausgegangen wird.

[HOT]

Die Voodoos rechneten pro Zeile AFAIK und setzten so das Bild zusammen. Das geht mit neueren Render-Verfahren nicht mehr, deshalb wird heute AFR genutzt.

[Coda]

Woa in dem Video sieht man's ja sofort. Ist das ätzend...

[Raff]

Woa in dem Video sieht man's ja sofort. Ist das ätzend...

Sag das mal den vielen Zweiflern in den Kommentaren darunter. X-D

MfG,
Raff

PS: Woa, ja! Ende Juli. :D

[Wolfram]

Das Video ist super. Fragt sich nur, ob man da wirklich noch von "Mikrorucklern" sprechen sollte... :biggrin:

Damit ist für mich SLI/CF absolut keine Option mehr.

[frix]

ist ja echt furchtbar. Da setze ich doch lieber auf eine grafikkarte und habe ehrliches geruckel :biggrin:
Finds traurig, dass dagegen nichts unternommen wird.

[mapel110]

Was ich so traurig finde, überall wurde erstmal jahrelang SLI gehypt bis es dann Mitte letzten Jahres(?!) einem User mal auffällt. Da fragt man sich doch haben gerade High End User und Tester Tomaten auf den Augen?!
Stur benchen und gamen ohne hinzuschauen, was da eigentlich passiert?
Oder ist das neben dem Inputlag schon gar nicht mehr aufgefallen? :ugly:
i
Finds traurig, dass dagegen nichts unternommen wird.
es gibt ja den fpslimiter.
nvidia und ATI haben ja auch vor einigen Monaten Abhilfe versprochen. ^^

btw eigentlich wäre es nur konsequent, wenn alle Testseiten, die was auf sich halten, SLI/CF nicht mehr benchen würden.

[(del)]

Was ich so traurig finde, überall wurde erstmal jahrelang SLI gehypt bis es dann Mitte letzten Jahres(?!) einem User mal auffällt. Da fragt man sich doch haben gerade High End User und Tester Tomaten auf den Augen?!Frag mal in die Runde welcher "High End USer" Tearing sieht... :conf:

[Gast]

Oha das sollen über 30fps sein?

Naja SLi/CF Fans stört so ein Video nicht. Ist ja alles nur Hetze der Unwissenden. :ugly:

[Coda]

Was ich so traurig finde, überall wurde erstmal jahrelang SLI gehypt bis es dann Mitte letzten Jahres(?!) einem User mal auffällt. Da fragt man sich doch haben gerade High End User und Tester Tomaten auf den Augen?!
Stur benchen und gamen ohne hinzuschauen, was da eigentlich passiert?
Oder ist das neben dem Inputlag schon gar nicht mehr aufgefallen? :ugly:
Ich denke es liegt daran dass für User von SLI gar nicht sein durfte. Sie haben schließlich jede Menge hingeblättert dafür und die Frames sind ja hoch. Schau doch auf den Counter!

NVIDIA kann bloß froh sein dass ich mir das nie angetan hab. Ich bin bei Ruckeln ziemlich empfindlich...

[mapel110]

Frag mal in die Runde welcher "High End USer" Tearing sieht... :conf:
hm, da fällt mir auf Tearing könnte auch diese Microruckler versteckt haben. Aber das sollte nur Bencher betreffen. Wobei ... Vsync lief doch noch bis vor einigen Monaten mit SLI nicht einwandfrei? Da war doch was?!

[Gast]

Da fragt man sich doch haben gerade High End User und Tester Tomaten auf den Augen?!
Mag sein oder man versucht es zu übersehen.

Oder die High-End User spielen halt mit 80fps statt 50fps. Dann fällts auch nicht so auf. :ugly: Naja dann ist der Multi GPU Vorteil so aufgefressen bleibt der längere Balken.

[(del)]

hm, da fällt mir auf Tearing könnte auch diese Microruckler versteckt haben.Tut es auch. Verstecken vielleicht nicht, aber es schwächt den Eindruck ab. Verstärkt dafür den anderen ;)
Schon als der dicke Schiff vorbeifliegt hast du mehr Tearing als genehm und dann nimmt man die Ruckler selbst auch nicht so wahr. Stimmt schon. Es bricht ja eh das ganze Bild kurz...

Wißt ihr was? Wenn ich für zwei 8800GT latze um sie in einem Rechner zu betreiben, dann will ich mich für Ruckler oder Tearing einen scheiß interessieren. DAS BILD MUß PERFEKT SEIN. Ich will dafür nichtmal im Treiber rumkonfigurieren. Höhstens um die Quali ABZUSETEZN, falls von mir gewünscht.
Das einzige was mich interessiert sind die FPS und die Einstellungen, damit ich gucken kann aus welchen 2 Karten ich mir das baue.

Das was bis jetzt geboten wird ist eine absolute Kinderkakce. Das fing mit AFR an und hörte eben mit dem Ruckeln auf. Mir stinkt schon selbst, daß sowas wie nHancer nötig ist. Jetzt ist der Faß halt übergelaufen. Bei euch. Mir stank das alles schon immer. No fuck way for CX/SLI hier.

Wobei ich mich wirklich frage, wenn ich mir das Video von PCGH ansehe, wo hier noch die Rede von "Mikro" sein kann. Mikro sind da nur die Abstände zwischen den Rucklern.
Noch 5ms dazu und das sieht wie Stop Motion (http://de.wikipedia.org/wiki/Stop_motion) aus :mad:

Aber das sollte nur Bencher betreffen. Wobei ... Vsync lief doch noch bis vor einigen Monaten mit SLI nicht einwandfrei? Da war doch was?!hmm...

@Coda
NVIDIA kann bloß froh sein dass ich mir das nie angetan hab. Ich bin bei Ruckeln ziemlich empfindlich...Wärest du vor BGH gezogen? ;)

[Grestorn]

Kirche im Dorf lassen, bitte.

Erst wenn die CPU der GPU massiv überlegen ist oder das Spiel kaum CPU Last verursacht, ist das Problem derart eklatant. 3DM rendert ja eine vorbereitete Szene, damit ist die CPU Last praktisch nicht vorhanden.

Das Problem ist ohne Zweifel vorhanden und oft auch sehr störend. Aber es ist auch nicht ok, alle SLI User jetzt als blind hinzustellen!

[Gast]

Wann waren Tombmans CPUs seinen Grafiklösungen massiv überlegen?

[K4mPFwUr$t]

manche leute sind halt etwas träge wenn es ums sehen geht, ist bei jedem unterschiedlich.
:biggrin:

[(del)]

Wann waren Tombmans CPUs seinen Grafiklösungen massiv überlegen?Das war ich :(
Und vor allem, es gibt Spiele die zwar eher GPU- als CPU-limitiert sind, aber welche verursachen "kaum" CPU-Last? Bomberman?

[Grestorn]

Wann waren Tombmans CPUs seinen Grafiklösungen massiv überlegen?

In den Beispielen bei denen er es reproduzieren konnte: Ja.

Alleine durch den technischen Hintergrund, warum diese Varianzen entstehen, ergibt sich dass die auftreten, je ungleicher das Verhältnis zwischen CPU und GPU ist.

Im Extremfall - die CPU braucht gar keine Zeit zum berechnen eines Bildes - würden immer zwei Bilder quasi gleichzeitig berechnet. Im optimalen Fall - die CPU braucht genau halb so lange wie eine der beiden GPUs um ein Bild zu berechnen - gäbe es gar keine Micro-Ruckler.

Und wenn die CPU noch langsamer ist, wird die Szene letztlich CPU limitiert und die SLI Kombination bringt immer weniger an zusätzlicher Leistung ggü. einer einzelnen GPU.

[Grestorn]

Das war ich :(
Und vor allem, es gibt Spiele die zwar eher GPU- als CPU-limitiert sind, aber welche verursachen "kaum" CPU-Last? Bomberman?

Deswegen sind die Varianzen im Normalfall ja auch nicht so ausgeprägt. Ein Benchmark ist da eine Ausnahmesituation, weil es da keine KI usw. zu berechnen gibt.

[(del)]

In den Beispielen bei denen er es reproduzieren konnte: Ja.Echt? Was war das denn nochmal...?... :|

[Grestorn]

Echt? Was war das denn nochmal...?... :|

3DM 06

[tombman]

Das Problem ist nur, daß gerade Multi-Gpu-User eben auch sehr schnelle Mehrkerncpus im System haben. 4Ghz sind da keine Seltenheit. Dh, genau bei der Situation, der Enthusiasten am häufigsten begegnen, also "Über-CPU" + haufenweise GPUs + abartig hohe Gpu-Last + 30fps tritt das Problem am stärksten auf- also genau dann wann man SLI am dringendsten braucht.

Das ist ja das Krasse an der Geschichte :eek:

[frix]

tombman hattest du nicht mal eine email an nvidia geschrieben? Würd mich mal interessieren was da zurück kam, falls was zurück kam.

[Exxtreme]

Ich fürchte, AMD und Nvidia werden das Problem gar nie lösen können, zumindest bei jetziger Hardware nicht. Denn um es zu lösen, müsste man schon vorher wissen wie lange das System braucht um ein Bild zu rendern. :D Und das bekommt man nicht raus da man schlecht in die Zukunft blicken kann. Abschwächen geht evtl. schon wenn man annimmt, daß das neue Bild nicht viel mehr/weniger Zeit braucht um gerendert zu werden als das Bild vorher. Dürfte in sehr vielen Fällen sogar hinkommen.

[Giraffengustav75]

Anfangs fand ich SLI und Crossfire noch interessant, weil es halt neu war. Mittlerweile halte ich es aber eher für ineffiziente Stromfresser. 2x8800 GTX...:eek: Zusammen mit dem Rest könnte ich ja stattdessen fast eine Waschmaschine laufen lassen.
Wie Hardware aussehen muss, zeigen für mich die CPU-Hersteller - vor allem Intel derzeit! Auch wenn ich weiß, dass GPUs für die gebotene Leistung sogar extrem effizient sind, finde ich den Verbrauch für sich genommen nicht gerade berauschend.

Von diesem Microruckel-Problem lese ich gerade zum ersten Mal.....und das wäre erst recht ein KO für mich, denn diese Art von Ruckler finde ich fast noch nerviger als echtes und richtiges Ruckeln! Es ist dann immer so eine Zuckelei, die einen irgendwie nervös macht...

[Wolfram]

Was ich so traurig finde, überall wurde erstmal jahrelang SLI gehypt bis es dann Mitte letzten Jahres(?!) einem User mal auffällt. Da fragt man sich doch haben gerade High End User und Tester Tomaten auf den Augen?!
Stur benchen und gamen ohne hinzuschauen, was da eigentlich passiert?
Oder ist das neben dem Inputlag schon gar nicht mehr aufgefallen? :ugly:

Man könnte ja auch meinen, die Kamera wird nicht flüssig bewegt und es ruckelt deswegen. Oder es liegt am Benchmark selbst. Vielleicht nutzen auch mehr High-End-User für mehr Performance als Bildqualität, und wenn die Sache tendenziell bei hohen fps weniger auffällt... Würde mich auch weniger stören, wenn ich die Ruckler bei einem 30-fps-Benchmark sehe, sie mir beim Spielen mit 60fps aber nicht mehr auffallen.

[Unyu]

Vielleicht nutzen auch mehr High-End-User für mehr Performance als Bildqualität
Aber wo liegt dann der Sinn am SLi, wenn man einfach nur mehr FPS hat?
Mit weniger Single Karten FPS wärs ja genauso flüssig.

Das ist kein Argument.

[InsaneDruid]

Man könnte ja auch meinen, die Kamera wird nicht flüssig bewegt und es ruckelt deswegen. Oder es liegt am Benchmark selbst. Vielleicht nutzen auch mehr High-End-User für mehr Performance als Bildqualität, und wenn die Sache tendenziell bei hohen fps weniger auffällt... Würde mich auch weniger stören, wenn ich die Ruckler bei einem 30-fps-Benchmark sehe, sie mir beim Spielen mit 60fps aber nicht mehr auffallen.

Es ist auch bei hohen FPS da. SLI/CF FPS sind halt nicht genauso viel "wert" wie Single Karten FPS.

[robbitop]

Es ist auch bei hohen FPS da. SLI/CF FPS sind halt nicht genauso viel "wert" wie Single Karten FPS.
Besser zusammenfassen kann man es kaum. :up:
Sofern die CPU deutlich weniger Zeit für die Vorberechnungen eines Frames braucht als die GPU zum Rendern, tritt dieser Effekt auf. Die Frames werden ungleich auf der Zeitachse verteilt. Je schneller die CPU, desto ungleichmäßiger und desto wertloser die FPS.

[Wolfram]

Aber wo liegt dann der Sinn am SLi, wenn man einfach nur mehr FPS hat?
Mit weniger Single Karten FPS wärs ja genauso flüssig.

Das ist kein Argument.
Das sollte eine mögliche Erklärung dafür sein, daß die Sache nicht vorher publik geworden ist, keine Rechtfertigung für SLI an sich.

[(del)]

@Exxtreme
Für mich als Laien wäre die Sache einfach. Ich opfer 5% der FPS um per Hardware (!) zwiwchen den beiden Chips eine Syncronität zu erzielen.

Die Systeme sind momentan auf die maximale Leistung getrimmt. Auf die maximale Leistung die mit einfachen FPS-Countern angezeigt wird. Das hat mit Qualität leider wenig zu tun.

@xxx1983
Die Ansätze sind ja die gleichen wie bei den CPUs. Sie werden leider nur anders realisiert. CX/SLI sind ein stinklangweiliger Cluster. Was meinst du was zB. 2x Einkern Wolfdale jeweils auf eigenem Board aus der Steckdose ziehen würde, wenn man es mit einem normalen E8400-System verlgeichen würde?
Die klar besseren Mehrkernalternativen sind die Lösungen von AMD/Intel. Das stimmt schon. Die GX2 ist es ja auch nicht, da man da qusi 2 Board aufeinander pappt. Es ist der gleiche Mist.

CX/SLI sind momentan weder auf Effizienz noch auf Leistung noch auf Qualität getrimmt. Sie sind darauf getrimmt vor allem größtmögliche Kosten zu verursachen. In der Anschaffung wie auch in der Benutzung.

[frix]

Besser zusammenfassen kann man es kaum. :up:
Sofern die CPU deutlich weniger Zeit für die Vorberechnungen eines Frames braucht als die GPU zum Rendern, tritt dieser Effekt auf. Die Frames werden ungleich auf der Zeitachse verteilt. Je schneller die CPU, desto ungleichmäßiger und desto wertloser die FPS.

Nvidia/Ati sollten also ein tool entwickelt, dass die cpu dymanisch ausbremst :biggrin:

[Psychopat]

Wenn die CPU zu schnell ist, sollte man doch durch runtertakten eine Verbesserung erzielen können. Hat jemand lust das mal zu testen? (am besten mit Frametime-Protokoll)

Mittlerweile wird mir klar, woher dieses "unter 60 FPS isses nicht flüssig" kommt. Klar, für nen SLI Nutzer ist's auch erst ab 60 FPS flüssig :D
Was Ruckler angeht bin ich eigentlich nicht so empfindlich. Ich hab Crysis mit etwa 13-17 min FPS durchgespielt (ok, die Endschlacht auf dem Träger gegen das Schlachtschiff ging gar nicht mehr, da hatte ich nur noch ca 3 FPS), fand ich eigentlich gut spielbar (is aber auch singleplayer). Aber dieses Video vom 3DMark, da stören mich sogar die Ruckler.

[Exxtreme]

@Exxtreme
Für mich als Laien wäre die Sache einfach. Ich opfer 5% der FPS um per Hardware (!) zwiwchen den beiden Chips eine Syncronität zu erzielen.

Die Systeme sind momentan auf die maximale Leistung getrimmt. Auf die maximale Leistung die mit einfachen FPS-Countern angezeigt wird. Das hat mit Qualität leider wenig zu tun.

Das Problem ist, daß man die Grafikkarten wohl nie richtig synchron betreiben können wird. Da reichen auf 5% FPS-Opferung nicht und ich glaube auch nicht, daß zusätzliche Schaltkreise auf zukünftiger Hardware helfen werden. Es ist ein konzeptionelles Problem von AFR, daß jede Grafikkarte eben für sich rechnet ohne Rücksicht auf die andere. Jegliche Versuche das synchronisieren zu wollen sind mehr oder weniger ein Schuss ins Blaue vergleichbar mit Pi mal Daumen. Kann sein, daß es eine Glättungswirkung geben wird aber nie eine gute 100%'ige.

[_DrillSarge]I[]

dann möcht ich mich mal hier einklimken und will mal eine fundierte antwort :)
http://forum-3dcenter.org/vbulletin/showthread.php?t=408102

[K4mPFwUr$t]

wie kann man 13-17FPS als flüssig gebrachten?
da muss man schon sehr träge augen haben.
zumal sich crysis auch bei 20-30FPS sehr unflüssig anfühlt, das gameplay flühlt sich bei sollchen FPS einfach nur unrund an.

[Grestorn]

Das Problem ist, daß man die Grafikkarten wohl nie richtig synchron betreiben können wird. Da reichen auf 5% FPS-Opferung nicht und ich glaube auch nicht, daß zusätzliche Schaltkreise auf zukünftiger Hardware helfen werden. Es ist ein konzeptionelles Problem von AFR, daß jede Grafikkarte eben für sich rechnet ohne Rücksicht auf die andere. Jegliche Versuche das synchronisieren zu wollen sind mehr oder weniger ein Schuss ins Blaue vergleichbar mit Pi mal Daumen. Kann sein, daß es eine Glättungswirkung geben wird aber nie eine gute 100%'ige.

Da bin ich ganz anderer Ansicht. Man muss nur vereinzelt hier und da ein Delay einbauen, um Differenzen auszugleichen.

Ich mag das hier nicht alles erneut erläutern, das habe ich alles in diesem Thread (auch Folgepostings beachten, sorry englisch) getan:

http://forums.anandtech.com/messageview.aspx?catid=31&threadid=2178762&FTVAR_STKEYWORDFRM=&STARTPAGE=5&FTVAR_FORUMVIEWTMP=Linear

Hier die entscheidenden Postings, weil das Forum leider keine direkten Links auf die Beiträge zulässt:


The point is that the primary cause of the micro stutters is the fact that the CPU need significantly less time to prepare a frame than the GPU needs to render it. The more even the load distribution is shared by the CPU and GPU, the less micro stuttering will be noticeable.

If the game is primarily GPU limited, the second GPU gets the data so fast that the actual point of time of the frame is placed at is just a few milliseconds behind the frame rendered by the first GPU, like this for example (the line representing the flow of time and the x representing a rendered frame):

x-x--------x-x--------x-x--------x-x--------x-x--------x-x--------x-x--------

If you delay the CPU for about half the time it takes the GPU to render the frame (a little less actually), the frame rate wont be affected much, but the frames are spread out much more regularly (^ representing the added delay):

x------x------x------x------x------x------x------x------x------x------x------
....^^^

The difficult part is, that this must be highly dynamic, usually the delay needs to be added for one frame only (because the following frames will always follow the rhythm) until the scene changes and the frames get uneven once again.


Da es Rückfragen gab, hab ich das noch mal etwas detaillierter erklärt:


You can see it like this (each frame takes the same time to be rendered):
First GPU:
x--------x--------x--------x--------x--------x--------x--------
Second GPU, started to render slightly later, because of the time the CPU took to prepare the second frame:
--x--------x--------x--------x--------x--------x--------x--------

Both GPUs used together you'll get what I already illustrated before:
x-x------x-x------x-x------x-x------x-x------x-x------x-x------


So, now add a delay to the rendering of the second GPU only ONCE, so it starts a little later:
-----x--------x--------x--------x--------x--------x--------x--------

The combination of both GPUs would now look like this:
x----x----x----x----x----x----x----x----x----x----x----x----


In the case that the rendering times of the frames would stay constant, you'd never have to add another delay.

But since that's not realistic, the driver has to keep track of the frame times and if the time difference between the two GPUs start to differ too much, it just has to calculate and add another delay ONCE again to fix that, until it gets out of alignment again.


Eigentlich alles nicht sooo kompliziert.

[=Floi=]

es hat ja mit dem limiter schon super funktioniert. Ich denke das problem kann schon behoben werden und ein kleiner verlust an fps ist bei sli doch sowieso egal.
1. skaliert sli sowieso nicht zu 100% (eher 70-95%)
2. war nv auch weit genug vor amd um das zu glätten und trotzdem vorne zu bleiben. Ja selbst bei amd könnte man hier die CF-Systeme durch einen fix leicht einbremsen und trotzdem wäre man noch vor den singlekarten und in dem bereich, in dem man sich positionieren will.

[Exxtreme]

Da bin ich ganz anderer Ansicht. Man muss nur vereinzelt hier und da ein Delay einbauen, um Differenzen auszugleichen.

Ich mag das hier nicht alles erneut erläutern, das habe ich alles in diesem Thread (auch Folgepostings beachten, sorry englisch) getan:

Daß man das mit einer Verzögerung theoretisch glätten kann, das ist mir durchaus bewusst. :D

Nur in der Praxis wird's halt hapern. Denn der Treiber muss im Voraus(!) wissen wie lange Grafikkarte B für das Bild brauchen wird um die Verzögerung für Grafikkarte A zu setzen und vice versa. Und das kann der Treiber einfach nicht wissen wegen fehlender funktionierender Glaskugel und so. Denn wie lange die Grafikkarten für ihre Frames brauchen das ist erst dann offensichtlich wenn die Grafikkarten die Bilder berechnet haben. Nur dann ist es zu spät. :) Klar könnte man jetzt diese Zeiten nehmen nur wird das Microruckeln nicht mehr zu 100% geglättet und es kann u.U. leichtes Stottern auftretten wenn die Szenen dauernd unterschiedliche Auslastungen produzieren.

Ich gehe zwar davon aus, daß diese Art von Glättung zwar immer noch angenehmer ist als gar keine Glättung aber 100%'ige Glättung wird es IMHO nicht geben. Zumindest bei AFR nicht.

[InsaneDruid]

Seh ich ähnlich. AFR ist das Übel, was mir brauchen ist kein AFR mit angeflanschtem "wenn alles optimal ist kanns ganz ok aussehen Limiter", sondern einen Rendermode, bei dem das Problem garnicht erst auftritt. Übel sollten an der Wurzel erledigt werden, an den Symptomen rumdoktern ist suboptimal.

Ist ja nicht das einzige Problem welches AFR auffährt.. schon die zunehmende Ausgabelatenz ist grenzwertig bis kriminell. Die teuerste und auf dem Papier leistungsfähigste Lösung hat den größten Output Lag und dazu auch noch Framelatenzen jenseits von Gut und Böse? Ist doch kein wirklicher Zustand.

[Die gelbe Eule]

Mal in die Runde gefragt, ist das Problem softwaretechnisch zu lösen? Es ist wichtig ob ich dann SLi behalte oder erst dann wieder kaufe wenn es ausgebessert ist.

[InsaneDruid]

Klar ist es softwaretechnisch zu lösen. Auf die eine (nachgestellter Limiter) oder andere (anderer Rendermode).. die Frage ist nur.. wird es zu Lebzeiten eines aktuellen SLI Systems erscheinen, was ich schon fast verneinen würde. Zu groß der Schar derer, die blind den Balkenlängen glauben. Solange sich SLI verkauft und ein paar "jaja wird schon" Versprechungen sogar für Lob statt alleszerfetzendem Tadel es überhaupt soweit kommen zu lassen sorgen, solange wird sich da nichts ändern.

[san.salvador]

Mich würde es interessieren, wieviele der SLI-User sich der Problematik überhaupt bewusst sind. Ich tippe da mal auf <1%. DA ist es auch nachvollziehbar, wenn sich Ati und Nvidia nicht deswegen die Haxen ausreißen.

[Gast]

@Exxtreme
Wenn es bis jetzt nur 1% auffiel :| dann könnte eine "Glättungswirkung" bewirken, daß es nur noch 0.1% stört. Ich würde das für einen Fortschritt halten .
Wenn Coda dann von "boah ist das ätzend" nur noch "ist noch gelegentlich merkbar" meinen würde, dann wäre das für mich schon eine beachtenswerte Steigerung ;)

Sonst gibt InsaneDruid schon alles so wieder wie ich es bereits geschrieben haben. Bis jetzt einfach nur ätzend.

BH (grad gemerkt, nicht eingeloggt)

[Exxtreme]

Mal in die Runde gefragt, ist das Problem softwaretechnisch zu lösen? Es ist wichtig ob ich dann SLi behalte oder erst dann wieder kaufe wenn es ausgebessert ist.
Das Problem bekommt man nicht aus der Welt. Man kann es aber evtl. so abmildern, daß es nicht stört bzw. nicht jeden stört.

Wenn man es "richtig" machen will dann kein AFR einsetzen. Dummerweise sind andere Lösungen nicht ganz so brauchbar.

[=Floi=]

auch schrecken so mehr kunden vor dem kauf eines sli systems zurück.
würde nv auchsli auf den anderen chipsätzen freischalten und dies misstand fixen, hätten wohl locker 10-20% mehr der gamer sli bei den preisen.

[ZilD]

ich würd als nividia technologie boss mal bei silicon graphics (sgi) anleuten und denen in auftrag geben das problem zu beheben.
irgendwie muss das per superformel/gleichung lösbar sein :D

[Gast]

auch schrecken so mehr kunden vor dem kauf eines sli systems zurück.
würde nv auchsli auf den anderen chipsätzen freischalten und dies misstand fixen, hätten wohl locker 10-20% mehr der gamer sli bei den preisen.
Wollen wir's mal hoffen. Allerdings gibt es sehr viele Deppen, die trotzdem weiter zugreifen oder ihnen die Sinne für die Wahrnehmung des Ruckelgezuppels fehlen.
Siehe z.B. Posting eines GX2 Owners hier aus dem Forum:
"gerade mal 8x...,bei CM7,Schwätzer,
da hab ich ja Glück das es "richtige" 26 FPS sind und das "ich" den "Frame Lag" nicht merke,vieleicht spiele ich auch mehr,anstatt irgendwas zu suchen.

ach ja ich will hier die GX2 nicht schönreden,das Ding tut es einfach und ich werde wohl einer der ersten sein die eine GT200 haben oder 2,trotz deiner so heiß geliebten Mikroruckler."

Solange da nicht wirklich signifikante Rückgänge bei den nächsten Dual Karten, bei dem Verkauf von High End karten und SLi-Mainboards zu verzeichnen ist, wird nV einen Teufel tun. Auf Amd braucht man erst recht nicht hoffen. Also kurz gesagt, es bleibt alles beim alten.

[Grestorn]

Daß man das mit einer Verzögerung theoretisch glätten kann, das ist mir durchaus bewusst. :D

Nur in der Praxis wird's halt hapern. Denn der Treiber muss im Voraus(!) wissen wie lange Grafikkarte B für das Bild brauchen wird um die Verzögerung für Grafikkarte A zu setzen und vice versa.

Nein nein.

Die Grafikkarten bleiben von alleine im Rythmus wenn sie einmal den richtigen Abstand haben. D.h. der Delay muss nur ein einziges Mal eingefügt werden (basierend auf den Daten der letzten 5-10 Frames z.B.) und danach stimmen die Abstände zwischen den Karten für ne Weile wieder von alleine.

Nur wenn sich die Szene ständig massiv ändert und vorallem die Rechenzeiten von GPU und CPU ständig ändern ist es problematisch. Aber auch wieder nicht, denn dann ist die Framerate ohnehin instabil auch bei single GPU Systemen.

Das Microruckeln fällt nur dann wirklich auf, wenn die Framerate über einen gewissen Zeitraum konstant bleibt. Und genau da kann ein Eingriff sehr leicht eine deutliche Besserung bringen.

[(del)]

ich würd als nividia technologie boss mal bei silicon graphics (sgi) anleuten und denen in auftrag geben das problem zu beheben.
irgendwie muss das per superformel/gleichung lösbar sein :DDu kannst dir mehr als sicher sein, daß diese Kisten (http://www.sgi.com/products/visualization/virtu/index.html) das Problem nicht haben. Auch wenn sie MultiGPU-Lösungen auf Basis des Quadro sind. Tja...

[ZilD]

ich sehe das auch so - wenn sich weiterhin sli und cf verkauft, werden die hersteller an den microrucklern nichts ändern.

finde die gpu technik der letzten jahre sowieso blöd.
erstens - warum braucht die gpu unter windows so viel strom? wo bleibt die sparsame primär 2d lösung? der 3d teil wird nur bei bedarf eingeschalten.

zweitens - noch immer fragwürdige kühlerkonstruktionen
warum nicht irgendwas sinniges von nem guten kühlerhersteller entwickeln lassen .. in der masse kostet die karte für den endverbraucher vielleicht 5-10€ mehr.

drittens - weg mit d3d & open gl - irgendwas glide mässiges muss wieder her dies jedoch auf allen plattformen funktioniert.
von der playstation 3 bis hin zum handy 3d chip.

[tombman]

u.U. leichtes Stottern auftretten wenn die Szenen dauernd unterschiedliche Auslastungen produzieren.

Aber genau das passiert ja nicht. Wo hast du einem Spiel ständig starke Schwankungen bei den fps? Meistens kommt man in eine Gegend oder schaut in eine Blickrichtung und dann bleibt es erstmal ein paar hundert frames auf einem gewissen fps Niveau. Wenn dann die Korrektur einen oder 2 frames braucht, dann ist das vielleicht für einen Augenblick ein sehr kurzes *zuck* und das wars- sollte man gar nicht bis kaum wahrnehmen. Auf jeden Fall ists 100x besser als die jetzigen "Mikro"ruckler.
Ich gehe zwar davon aus, daß diese Art von Glättung zwar immer noch angenehmer ist als gar keine Glättung aber 100%'ige Glättung wird es IMHO nicht geben. Zumindest bei AFR nicht.
100% wäre schön, braucht man aber nicht unbedingt :)

[Piffan]

Was ist eigentlich aus dem Framelimiter geworden?

Einerseits ist das tool begrüßenswert aus der pragmatischen Sicht eines "spielenden Users", andererseits bedeutet es, dass die Interessenten aufmerksam werden und man die Sinnlosigkeit von SLI bermerken könnte. Daher wird NV NICHTS gegen das Mikroruckeln tun im Sinne eines Limiters. Dann höchsten in Form eines dynamischen Systems, dass mit Hysterese arbeitet. Scheinbar ist man noch nicht soweit....

[looking glass]

Naja, soweit ich das mitbekommen habe, haben sie ja schon versucht am Sheduler dahingehend dem Problem zu begegnen, nur hat das wohl nicht viel gebracht (wen ich mich recht entsinne, hat es das Problem sogar verschärft).

[Exxtreme]

Nein nein.

Die Grafikkarten bleiben von alleine im Rythmus wenn sie einmal den richtigen Abstand haben. D.h. der Delay muss nur ein einziges Mal eingefügt werden (basierend auf den Daten der letzten 5-10 Frames z.B.) und danach stimmen die Abstände zwischen den Karten für ne Weile wieder von alleine.

Nur wenn sich die Szene ständig massiv ändert und vorallem die Rechenzeiten von GPU und CPU ständig ändern ist es problematisch. Aber auch wieder nicht, denn dann ist die Framerate ohnehin instabil auch bei single GPU Systemen.

Das Microruckeln fällt nur dann wirklich auf, wenn die Framerate über einen gewissen Zeitraum konstant bleibt. Und genau da kann ein Eingriff sehr leicht eine deutliche Besserung bringen.
Jein. Jede noch so kleine Änderung an der Bildwiederholrate kann das Mikroruckeln wieder auslösen selbst mit künstlichen Wartezeiten. Da kannst du keine Mittelwerte aus den letzten 10 Frames nehmen. Höchstens den letzten gemessenen Wert. Das dürfte zwar für die meisten Fälle passen, man könnte aber locker weiterhin Microruckler provozieren. Ich denke da z.B. an eine Situation wo die Bildwiederholrate kontinuierlich abnimmt. Hier passen weder Mittelwerte aus mehreren Frames, noch der letzte gemessene Wert.
Aber genau das passiert ja nicht. Wo hast du einem Spiel ständig starke Schwankungen bei den fps? Meistens kommt man in eine Gegend oder schaut in eine Blickrichtung und dann bleibt es erstmal ein paar hundert frames auf einem gewissen fps Niveau. Wenn dann die Korrektur einen oder 2 frames braucht, dann ist das vielleicht für einen Augenblick ein sehr kurzes *zuck* und das wars- sollte man gar nicht bis kaum wahrnehmen. Auf jeden Fall ists 100x besser als die jetzigen "Mikro"ruckler.
Siehe oben. Provozieren lässt sich das wohl weiterhin, in der Praxis dürfte das aber schon eine Milderung bringen.

Wobei mir wieder was Neues eingefallen ist. :) Der Treiber könnte die "Schwankungen" analysieren und anhand der letzten Frames eine Prognose treffen in wie hoch die Wartezeit für den nächsten Frame sein könnte. Ist wohl besser als Mittelwerte bilden oder den letzten Wert nehmen.

Jetzt stellt sich die Frage wieviel zusätzliche Rechenleistung das benötigt die nötigen Wartezeiten zu errechnen.

[Die gelbe Eule]

Was ist eigentlich aus dem Framelimiter geworden?

Einerseits ist das tool begrüßenswert aus der pragmatischen Sicht eines "spielenden Users", andererseits bedeutet es, dass die Interessenten aufmerksam werden und man die Sinnlosigkeit von SLI bermerken könnte. Daher wird NV NICHTS gegen das Mikroruckeln tun im Sinne eines Limiters. Dann höchsten in Form eines dynamischen Systems, dass mit Hysterese arbeitet. Scheinbar ist man noch nicht soweit....

Du weißt was man mit Autos macht die nicht richtig funktionieren? Richtig, Rückrufaktion. Stell Dir mal vor alle SLi/CF User geben Ihre Karten wieder zurück, währe ja innerhalb der Gewährleistung und möchten gerne Karten haben die nicht mircoruckeln. NV oder ATi müsste dann erstmal den Herstellern gegenüber erklären, daß diese Mircoruckler they way its designed ist und nicht nur ein Bug. ERgo würde niemand mehr ein SLi/CF Brett, geschweige denn die Karten kaufen. Die Formel 1 der Technologieträger im GPU Markt wäre sofort tot und Einzelkarten müssten deutlich schneller werden.

[Grestorn]

Jein. Jede noch so kleine Änderung an der Bildwiederholrate kann das Mikroruckeln wieder auslösen selbst mit künstlichen Wartezeiten. Da kannst du keine Mittelwerte aus den letzten 10 Frames nehmen. Höchstens den letzten gemessenen Wert. Das dürfte zwar für die meisten Fälle passen, man könnte aber locker weiterhin Microruckler provozieren. Ich denke da z.B. an eine Situation wo die Bildwiederholrate kontinuierlich abnimmt. Hier passen weder Mittelwerte aus mehreren Frames, noch der letzte gemessene Wert.

Wenn die Framerate kontinuierlich abnimmt, ist es auch kein Problem, da beide Karten immer mehr am rechnen sind wird der Versatz nur sehr sehr langsam zunehmen, wenn sie vorher im Gleichschritt waren.

Die Berechnungen dazu sind wirklich nicht schwer. Ich würde mir zutrauen, einen passenden Algo in ein bis zwei Tagen zu entwickeln.

[Psychopat]

wie kann man 13-17FPS als flüssig gebrachten?
da muss man schon sehr träge augen haben.
zumal sich crysis auch bei 20-30FPS sehr unflüssig anfühlt, das gameplay flühlt sich bei sollchen FPS einfach nur unrund an.

Liegt vielleicht an meiner Spielweise (wenig action, mehr rumschleichen). Träge Augen hab ich eigentlich nicht. Aber wie gesagt, min FPS, nicht average. Is schon ein Unterschied.
Kann man halt schlecht messen, das mit dem flüssig. Ich kann nur sagen, unrund hat es sich nicht angefühlt. Ab und zu gabs Nachladeruckler, aber kein störendes Dauergeruckel.

Gegenbeispiel: Neverwinternights 2 läuft bei mir nicht gescheit (2900pro). Da stört mich das Ruckeln extrem (kann leider gerade keine FPS sagen). Aber vielleicht merk ich es da mehr, weil ich da grössere Kameraschwenks habe.

[Liszca]

Ich finde das sieht nicht nach mikrorucklern aus, sondern eher nach vsync & triplebuffering, anders kann ich mir auch nicht die gleichmässig unterschiedlichen frametimes erklären.

[RavenTS]

Was ist eigentlich aus dem Framelimiter geworden?

Einerseits ist das tool begrüßenswert aus der pragmatischen Sicht eines "spielenden Users", andererseits bedeutet es, dass die Interessenten aufmerksam werden und man die Sinnlosigkeit von SLI bermerken könnte. Daher wird NV NICHTS gegen das Mikroruckeln tun im Sinne eines Limiters. Dann höchsten in Form eines dynamischen Systems, dass mit Hysterese arbeitet. Scheinbar ist man noch nicht soweit....

Da gabs doch irgendwelche Probleme mit Bibliotheken von MS, die man nicht so ohne weiteres nutzen darf glaub...

Ansonst würd ich sagen soll nVIDIA halt einfach mal wieder die "echte" SLI-Technik auspacken..! :rolleyes:

[aths]

Wobei mir wieder was Neues eingefallen ist. :) Der Treiber könnte die "Schwankungen" analysieren und anhand der letzten Frames eine Prognose treffen in wie hoch die Wartezeit für den nächsten Frame sein könnte. Ist wohl besser als Mittelwerte bilden oder den letzten Wert nehmen.

Jetzt stellt sich die Frage wieviel zusätzliche Rechenleistung das benötigt die nötigen Wartezeiten zu errechnen.Wieso das Wort "Schwankungen" in Anführungszeichen?

Wie soll der Treiber zukünftige Schwankungen erkennen können? Man kann nur die Annahme treffen, dass das nächste Frame in der Berechnung genauso lange dauert wie das aktuelle. Das heißt, GPU_0 rendert ein Bild und der Treiber misst die Zeit. GPU_1 wird dann aktiviert, wenn nach dem Loslegen von GPU_0 50% der Zeit rum ist, die vorhin GPU_1 zum Rendern ihres Bildes gebraucht hat. Die für GPU_0 gemessene Zeit wird als Maßstab dafür genommen das neue Bild zu berechnen, wenn GPU_1 gerade loslegen will – nach 50% der Zeit die GPU_0 für das letzte Bild benötigt hat, wird fängt sie mit dem Rendern an.

Darauf müssen allerdings auch die User-Eingaben und der Timer vom Spiel abgestimmt werden.

[Piffan]

Ich habe den Eindruck, dass das ganze viel zu verkniffen betrachtet wird. Ich meine, wie viele Frames braucht es denn, bis sich die Belastungsverteilung zwischen GPU und CPU verschiebt? Eigentlich sind es schon einge Frames, schnelle Drehungen in einem Ego- Shooter sind vielleicht so ein Härtefall......

Das Video vom 3dMark zeigt übrigens kein Mikroruckeln, sondern Makroruckeln. Teilweise läuft es aalglatt, dann wiederum stockt es für Sekundenbruchteile. Derartiges kennt man eher von Vsync. Problemen oder wenn der Grafikkartenspeicher nicht reicht, alle Texturen komplett aufzunehmen....

Echtes Mikroruckeln ist anders, da besteht ein Missverhältnis zwischen "gefühlter" und gemessener Performance. Im Extremfall erscheint einem die Performance nur halb so hoch.
Dann noch die Lags wegen SLI und damit ist für mich SLI/Crossfire kein Thema mehr.....zumindest bis NV/Ati das Problem öffentlich zugeben und wirklich was dagegen tun.