Archiv verlassen und diese Seite im Standarddesign anzeigen : AFR/SFR & Co. (war:GT300/GF100 - Q1/2010, DX11, CUDA 3.0)
Oha, von einem abgefilmten und dann mit Flash abgespielten Demo wollt ihr auf Ruckler oder nicht Ruckler schliessen? Gewagt...
pXe
uweskw
2010-01-26, 02:24:01
Kein Anstand mehr....
Egal ob es unter die technische Definition von MR fällt oder nicht!
Auch dem unbelesenem User fällt hier auf dass das Bild immer wieder kurz stockt, also ruckelt. Und das nicht zu knapp.
http://www.youtube.com/watch?v=YtO8JroFZuk
Wenn ich mir dann die Videos ansehe wegen derer ATIs Crossfire als "untragbar ruckelnd" abgestempelt wurde..... Da ist Fermi ein Erdbeben dagegen.
Wenns mal nicht gegen ATI geht, wo bleiben die Bildqualitäts-Fetischisten dann? Na lassen wir uns überraschen. Den features nach MUSS!! Fermi die AF Qualität beschränken um performance-mäßig auf der Höhe zu bleiben.
Greetz
U.S.
Kalmar
2010-01-26, 02:42:04
ich seh da irgendwie keinen unterschied zwischen PhysX an und aus bei den videos .. und ruckeln hin und her wissen tut man es erst wenn es unabhängige tests gibt
und zu dem betrieb wirtschaftlichen argumenten wenn amd die highend wo anderes fertigen lässt, dürfte das kaum was ausmachend as das größte volumen wohl bei den mainstreamzeugs und da drunter gemacht wird ..
Exxtreme
2010-01-26, 10:38:18
Wenn ich mir dann die Videos ansehe wegen derer ATIs Crossfire als "untragbar ruckelnd" abgestempelt wurde..... Da ist Fermi ein Erdbeben dagegen.
Das ist völliger Zufall ob man MR sieht oder nicht. Solche Multichip-Lösungen wird man nie MR-frei bekommen. Anhand solcher Videos würde ich nicht urteilen. =)
Ich lasse von Multichip-Lösungen generell die Finger.
Das ist völliger Zufall ob man MR sieht oder nicht. Solche Multichip-Lösungen wird man nie MR-frei bekommen. Anhand solcher Videos würde ich nicht urteilen. =)
Ich lasse von Multichip-Lösungen generell die Finger.
Wenn man ein anderes Konzept als AFR einsetzt hat man nicht mehr MR als eine einzelne Karte auch.
Wenn man ein anderes Konzept als AFR einsetzt hat man nicht mehr MR als eine einzelne Karte auch.
Und das Konzept liegt gutgehütet bei dir in der Schublade oder warum ist bis dato kein geeigneter Ansatz bekannt und umgesetzt? Egal, Fermi wird ja sowieso kein AFR-Puzzle.
Und das Konzept liegt gutgehütet bei dir in der Schublade oder warum ist bis dato kein geeigneter Ansatz bekannt und umgesetzt? Egal, Fermi wird ja sowieso kein AFR-Puzzle.
Ja, denn diese Konzept wird keine Skalierung um die 100% erlauben wie CF und SLI.
Bisher gilt ca.: Wie kürzere Balken bei Highendkarten, destso weniger verkaufte Karten insgesammt + "anderer IHV ist schneller" Image.
Woher sollte da die Motivation kommen Karten die nur für das FPS Image stehen zu verbessern?
y33H@
2010-01-26, 11:00:53
Es gibt Ansätze wie SFR und Tilling, nur reicht hier die Fps-Steigerung bisher nicht an AFR ran und es gibt Stress mit einigen Post-Effekten usw.
Exxtreme
2010-01-26, 11:03:15
Wenn man ein anderes Konzept als AFR einsetzt hat man nicht mehr MR als eine einzelne Karte auch.
AFR ist halt die beste Methode um höhere FPS zu bekommen was die Balkenlängen vergrössert. Andere Methoden haben mehr Einschränkungen.
mapel110
2010-01-26, 11:05:45
Und wenn MR auftreten, kann man immer noch hier und da ein Detail abschalten, um allgemein die fps anzuheben, sodass doch dann die MR nicht mehr auftreten?! Wurde das nicht immer gesagt, dass die MR in höheren fps-Bereichen nicht auftreten?!
Exxtreme
2010-01-26, 11:15:03
Und wenn MR auftreten, kann man immer noch hier und da ein Detail abschalten, um allgemein die fps anzuheben, sodass doch dann die MR nicht mehr auftreten?! Wurde das nicht immer gesagt, dass die MR in höheren fps-Bereichen nicht auftreten?!
Die Frage bleibt, wozu man so eine Multichip-Lösung braucht wenn man Details abschalten muss damit es nicht ruckelt. ;)
Theoretische MR treten die meiste Zeit auf unabhängig von der Framerate. Ob man sie dann merkt oder nicht das ist wieder individuell.
Und wenn MR auftreten, kann man immer noch hier und da ein Detail abschalten, um allgemein die fps anzuheben, sodass doch dann die MR nicht mehr auftreten?! Wurde das nicht immer gesagt, dass die MR in höheren fps-Bereichen nicht auftreten?!
So würde ich das nicht schreiben.
Sie senken in jeder Situation die "gefühlten FPS" gegenüber den angezeigten durch ungünstige (=ungleichmäßige) Bildausgabeabständen.
Um die 30 FPS wird Das am deutlichsten.
Aber es gibt durchaus Spiele (wie z.B UT3) bei denen man auch noch über 60 FPS spürbare Ruckler hat.
Aquaschaf
2010-01-26, 12:02:17
Wurde das nicht immer gesagt, dass die MR in höheren fps-Bereichen nicht auftreten?!
Das ist unabhängig von der Bildrate, aber bei mehr FPS sind die niedrigeren effektiven FPS eben immer noch im flüssigen Bereich. Was dann aber auch bedeutet dass man dann mit einer GPU auch schon genug FPS für eine flüssige Darstellung hätte.
Der theoretisch schlechteste Fall ist wenn zwei Bilder direkt hintereinender ausgegeben werden.
Dann hat man quasi nur die Hälfte der FPS zur Verfügung(insgesammt werden natürlich gleich viele Frames ausgegeben)
Noch schlimmer finde Ich aber wenn die Frametimes ständig stark varieren.
Da ist meines Erachtens nach der "Ruckelfaktor" am größten.
Die Frage bleibt, wozu man so eine Multichip-Lösung braucht wenn man Details abschalten muss damit es nicht ruckelt. ;)
Theoretische MR treten die meiste Zeit auf unabhängig von der Framerate. Ob man sie dann merkt oder nicht das ist wieder individuell.
Garkeine gibts nicht, da Frames nicht immer gleich lange brauchen um berechnet zu werden, also hat auch eine Singlechipkarte "Mikroruckler". Auf das Niveau von letzterer kann man mit AFR kommen, aber relativ Nahe, aber nur wenn die Treiber wirklich in Ruhe gelassen werden, sprich keine ATT und Co (auch keine Temp auslesen etc). Es braucht hier einfach eine höhere Framerate damit da Erlebnis eine Singlechipkarte nahe kommt. Beide IHVs haben entsprechenden Code schon länger in den Treibern. Besser gehts wohl kaum als bei Nvidia.
Garkeine gibts nicht, da Frames nicht immer gleich lange brauchen um berechnet zu werden, also hat auch eine Singlechipkarte "Mikroruckler". Auf das Niveau von letzterer kann man mit AFR kommen, aber relativ Nahe, aber nur wenn die Treiber wirklich in Ruhe gelassen werden, sprich keine ATT und Co (auch keine Temp auslesen etc). Es braucht hier einfach eine höhere Framerate damit da Erlebnis eine Singlechipkarte nahe kommt. Beide IHVs haben entsprechenden Code schon länger in den Treibern. Besser gehts wohl kaum als bei Nvidia.
Darum braucht man auch ein anderes Konzept, da Das von NV zwar besser ist, aber trotzdem nicht so dass man AFR für eine breite Produktpalette einsetzen kann.
Exxtreme
2010-01-26, 13:13:50
Garkeine gibts nicht, da Frames nicht immer gleich lange brauchen um berechnet zu werden, also hat auch eine Singlechipkarte "Mikroruckler". Auf das Niveau von letzterer kann man mit AFR kommen, aber relativ Nahe, aber nur wenn die Treiber wirklich in Ruhe gelassen werden, sprich keine ATT und Co (auch keine Temp auslesen etc). Es braucht hier einfach eine höhere Framerate damit da Erlebnis eine Singlechipkarte nahe kommt. Beide IHVs haben entsprechenden Code schon länger in den Treibern. Besser gehts wohl kaum als bei Nvidia.
Mit Code in den Treibern kann man die MR-Problematik nicht vollständig lösen. Ich kann mir zwar sicherlich eine Art Glättungsmechanismus vorstellen. Nur wird auch dieser niemals(!) die MR vollständig eliminieren können. Vielleicht lassen sie sich aber so abmildern, daß sie in vielen Fällen nicht wahrnehmbar sind. Messbar werden sie aber wohl oder übel sein.
Mikroruckler vollständig zu eliminieren geht nur mit einer Zeitmaschine/funktionierender Glaskugel/whatever.
Und ob die IHVs so einen Glättungsmechanismus in den Treibern haben oder nicht, das lässt sich wohl so nicht rausfinden.
Triskaine
2010-01-26, 13:54:22
Über einen guten Glättungsmechanismus ließen sich sehr wohl nahezu alle Mikroruckler eliminieren, aber das hätte einen ziehmlich großen FPS-Verlust zur Folge, was die Sinnhaftigkeit einer Multi GPU Lösung noch stärker in Frage stellen würde, da dann nichteinmal mehr die Balken schön lang wären.
Über einen guten Glättungsmechanismus ließen sich sehr wohl nahezu alle Mikroruckler eliminieren, aber das hätte einen ziehmlich großen FPS-Verlust zur Folge, was die Sinnhaftigkeit einer Multi GPU Lösung noch stärker in Frage stellen würde, da dann nichteinmal mehr die Balken schön lang wären.
Das wäre wohl kein Problem, würde die Technik bei beliebig vielen Chips funktionieren.
Dadurch könnte man GPUs aus Modulen zusammensetzen, Waferfläche sparen, Yield verbessern und hätte keine Begrenzung bei der Gesammtfläche der Chips (natürlich müsste man weiterhin die Signallaufzeiten beachten)
Das wäre wohl kein Problem, würde die Technik bei beliebig vielen Chips funktionieren.
Dadurch könnte man GPUs aus Modulen zusammensetzen, Waferfläche sparen, Yield verbessern und hätte keine Begrenzung bei der Gesammtfläche der Chips (natürlich müsste man weiterhin die Signallaufzeiten beachten)
Das ist der zukünftige Weg. Wurde auch vom Chefentwickler bei nVidia in Aussicht gestellt.
GF100 zeigt ja, wohin die Reise gehen könnte. Jetzt hat man vier "kleine" GPUs in einem riesigen Die - je mit einer Setup-Engine, vier eigenen Geometrieienheiten, 4SM und 64kb L1 Cache. Alle vier Prozessoren kommunizieren über den L2 Cache miteinander und erhalten die Informationen über den GigaThread Engine. Jedenfalls nVidia wird diesen Weg in Zukunft weiter voranschreiten.
Das ist der zukünftige Weg. Wurde auch vom Chefentwickler bei nVidia in Aussicht gestellt.
GF100 zeigt ja, wohin die Reise gehen könnte. Jetzt hat man vier "kleine" GPUs in einem riesigen Die - je mit einer Setup-Engine, vier eigenen Geometrieienheiten, 4SM und 64kb L1 Cache. Alle vier Prozessoren kommunizieren über den L2 Cache miteinander und erhalten die Informationen über den GigaThread Engine. Jedenfalls nVidia wird diesen Weg in Zukunft weiter voranschreiten.
Erinnert sehr aan das Konzept vom Intel/Larry.
Viele kleine GPU bzw. CPUs(Intel), mal schauen, ob es bei einem GPU-basiertem System besser funktioniert.
Sollte eigentlich.
tombman
2010-01-26, 14:41:18
Mit Code in den Treibern kann man die MR-Problematik nicht vollständig lösen. Ich kann mir zwar sicherlich eine Art Glättungsmechanismus vorstellen. Nur wird auch dieser niemals(!) die MR vollständig eliminieren können. Vielleicht lassen sie sich aber so abmildern, daß sie in vielen Fällen nicht wahrnehmbar sind. Messbar werden sie aber wohl oder übel sein.
Mikroruckler vollständig zu eliminieren geht nur mit einer Zeitmaschine/funktionierender Glaskugel/whatever.
Und ob die IHVs so einen Glättungsmechanismus in den Treibern haben oder nicht, das lässt sich wohl so nicht rausfinden.
Oder man läßt beide Gpus wirklich nur an einem frame rendern. Müssen eben neue Technologien erfunden werden um die Bandbreite für den Datenaustausch zu erzielen...
RAMs und Gpus per Lichtleiter verbunden- fertig. Beim Zusammenschalten gibts dann eben EINEN großen Rambereich für beide Gpus :cool:
Grestorn
2010-01-26, 14:43:27
AFR hat ja nicht nur das Problem der Mikroruckler, sondern auch der zunehmenden Latenz. Bei zwei Karten merkt man das nicht, bei 4 schon langsam.
Deswegen verstehe ich auch nicht wie man davon ausgehen kann, dass das die Zukunft ist. Es kann gar nicht die Zukunft sein.
Exxtreme
2010-01-26, 14:52:54
Oder man läßt beide Gpus wirklich nur an einem frame rendern. Müssen eben neue Technologien erfunden werden um die Bandbreite für den Datenaustausch zu erzielen...
RAMs und Gpus per Lichtleiter verbunden- fertig. Beim Zusammenschalten gibts dann eben EINEN großen Rambereich für beide Gpus :cool:
Da könnte es zu fiesen Locks kommen wenn Grafikkarte A die Daten von Grafikkarte B braucht um weiterrechnen zu können.
Gouvernator
2010-01-26, 14:54:22
Und wenn MR auftreten, kann man immer noch hier und da ein Detail abschalten, um allgemein die fps anzuheben, sodass doch dann die MR nicht mehr auftreten?! Wurde das nicht immer gesagt, dass die MR in höheren fps-Bereichen nicht auftreten?!
Ja man kann die FPS soweit heben das die MR nicht auftreten. Nach meinen Beobachtung damals braucht man um die 200FPS um die MR vollständig loszuwerden, dann schwankt es nur noch im Bereich von 1ms.
Ein Entwickler von Multicorechips wird immer Versuchen seine Chips modular zu gestalten- allein schon wegen der einfachen skalierbarkeit.
Ich glaube nicht, dass AFR die Zukunft ist.
Dazu gibt es zu viele Fragezeichen. (Latenzen?, Skalierbarkeit über n-Chips?)
Vielleicht werden ja Tile Based Renderer die Probleme lösen können.
Ja man kann die FPS soweit heben das die MR nicht auftreten. Nach meinen Beobachtung damals braucht man um die 200FPS um die MR vollständig loszuwerden, dann schwankt es nur noch im Bereich von 1ms.
Das kann dann daran liegen, dass das Tool nur in ganzen ms misst.
tombman
2010-01-26, 14:57:58
Da könnte es zu fiesen Locks kommen wenn Grafikkarte A die Daten von Grafikkarte B braucht um weiterrechnen zu können.
Wieso locked sich dann eine hochkomplexe Gpu wie zb Fermi nicht selbst? Kann man die Konzepte zur internen Lockvermeidung nicht extern weiterführen; sozusagen die anderen Gpus nur als "externe SMs"?
Exxtreme
2010-01-26, 15:05:25
Wieso locked sich dann eine hochkomplexe Gpu wie zb Fermi nicht selbst? Kann man die Konzepte zur internen Lockvermeidung nicht extern weiterführen; sozusagen die anderen Gpus nur als "externe SMs"?
Ob sich Fermi locked das weisst du eben nicht. :D
Und Fermi hat eben den Vorteil, daß die Kerne jederzeit auf die fertigen Daten zugreifen können da sie wohl gemeinsam auf den gleichen Speicher zugreifen. Alleine das entschärft eine mögliche Blockierungsproblematik beträchtlich.
Ob sich Fermi locked das weisst du eben nicht. :D
Und Fermi hat eben den Vorteil, daß die Kerne jederzeit auf die fertigen Daten zugreifen können da sie wohl gemeinsam auf den gleichen Speicher zugreifen. Alleine das entschärft eine mögliche Blockierungsproblematik beträchtlich.
Es könnten ja theoretisch auch mehrere GPUs auf einen gemeinsamen Speicher zugreifen.
Die Frage ist halt dann wie man das Hardwaretechnisch(Verdrahtung) und Logisch(hat jede GPU dann ihren eigenen Bereich? wie beim Power 7 lvl 3 Cache)
tombman
2010-01-26, 15:33:23
Ob sich Fermi locked das weisst du eben nicht. :D
Und Fermi hat eben den Vorteil, daß die Kerne jederzeit auf die fertigen Daten zugreifen können da sie wohl gemeinsam auf den gleichen Speicher zugreifen. Alleine das entschärft eine mögliche Blockierungsproblematik beträchtlich.
Deswegen meinte ich ja, daß ein zukünftiger Chip so intelligent ist, sich nicht mehr auf eine fixe Anzahl von Einheiten zu versteifen, sondern daß quasi ganze sets von Algos. verhanden sind, je nachdem wieviele Gpus erkannt werden, sprich: Vehaltensweisen abhängig von der Anzahl der Gpus. Wie gesagt: die Bandbreiten müssen da sein, also nicht nur ein kleines Käbelchen wie derzeit bei SLI, sondern richtige Überbrückungsplatinen mit abartig vielen Kontakten. Aus zb 2 einzelnen Grakas- wird dann eine :eek: :cool:
Deswegen meinte ich ja, daß ein zukünftiger Chip so intelligent ist, sich nicht mehr auf eine fixe Anzahl von Einheiten zu versteifen, sondern daß quasi ganze sets von Algos. verhanden sind, je nachdem wieviele Gpus erkannt werden, sprich: Vehaltensweisen abhängig von der Anzahl der Gpus. Wie gesagt: die Bandbreiten müssen da sein, also nicht nur ein kleines Käbelchen wie derzeit bei SLI, sondern richtige Überbrückungsplatinen mit abartig vielen Kontakten. Aus zb 2 einzelnen Grakas- wird dann eine :eek: :cool:
Eine komplette Überführung des Speichetinterfaces von einer Karte zur Anderen wäre extrem teuer und man könnte Probleme mit der Signallaufzeit bekommem-vom Boardlayout gar nicht zu sprechen das würde neue Rekorde in der Anzahl der Layer aufstellen:D
tombman
2010-01-26, 15:46:01
Eine komplette Überführung des Speichetinterfaces von einer Karte zur Anderen wäre extrem teuer und man könnte Probleme mit der Signallaufzeit bekommem-vom Boardlayout gar nicht zu sprechen das würde neue Rekorde in der Anzahl der Layer aufstellen:D
Oder ein externer Speicher+ Controlchip in einem 3.5" Slot, angebunden per Lichtleiter. Dieser externe Speicher hätte dann ports, wo sich die Gpus andocken können :cool:
Die Grakas hätten dann gar keinen Speicher mehr, nur einen port.
Den externen Speicher gibts dann in verschiedenen Ausführungen, je nach Anzahl der Ports etc :)
Mir fällt da noch genug ein :D
Exxtreme
2010-01-26, 16:28:10
Oder ein externer Speicher+ Controlchip in einem 3.5" Slot, angebunden per Lichtleiter. Dieser externe Speicher hätte dann ports, wo sich die Gpus andocken können :cool:
Die Grakas hätten dann gar keinen Speicher mehr, nur einen port.
Den externen Speicher gibts dann in verschiedenen Ausführungen, je nach Anzahl der Ports etc :)
Mir fällt da noch genug ein :D
Ist zu langsam.
mrt@gast
2010-01-26, 16:31:36
Mit Code in den Treibern kann man die MR-Problematik nicht vollständig lösen. Ich kann mir zwar sicherlich eine Art Glättungsmechanismus vorstellen. Nur wird auch dieser niemals(!) die MR vollständig eliminieren können. Vielleicht lassen sie sich aber so abmildern, daß sie in vielen Fällen nicht wahrnehmbar sind. Messbar werden sie aber wohl oder übel sein.[QUOTE=Exxtreme;7804355]
Das hab ich eigentlich eh geschrieben, gut es fehlt ein nicht zwischen "AFR" und "kommen".
[QUOTE=Exxtreme;7804355]Mikroruckler vollständig zu eliminieren geht nur mit einer Zeitmaschine/funktionierender Glaskugel/whatever.
Und ob die IHVs so einen Glättungsmechanismus in den Treibern haben oder nicht, das lässt sich wohl so nicht rausfinden.
Man kann sie sehr stark reduzieren indem man die Annahme von Frame n+1 verzögert. Dadurch verliert man keine Leistung, da sich das einpendelt (man überlege sich warum :)), außer bei stärkeren Framewechseln (zB 30 auf 60 Frames), da gibt es dann eine kleine Nachwirkzeit bis man bei 60 Frames ist, aber nur ein paar Frames lange bzw je nach Algorithmus. Man kann den Algorithmus auch ein wenig flexibler machen und sich immer anschaun wie lange die zweite GPU wirklich braucht und Steigung der Funktion (ist ja nichts anderes) ständig anpassen. Vorausgesetzt natürlich das Prerenderlimit ist nicht zu hoch bzw es sind nur zwei GPUs im System. Bei mehr wird es dann wieder tendentiell schlecht, dh mehr "Mikroruckler" und längere Nachlaufzeit bis volle Performance.
Ja beide haben dafür Code in den Treibern, ob der so ähnlich funktioniert wie meine Möglichkeit die ich gerade skizziert habe ist eine andere Frage.
Exxtreme
2010-01-26, 19:29:29
Man kann sie sehr stark reduzieren indem man die Annahme von Frame n+1 verzögert. Dadurch verliert man keine Leistung, da sich das einpendelt (man überlege sich warum :)), außer bei stärkeren Framewechseln (zB 30 auf 60 Frames), da gibt es dann eine kleine Nachwirkzeit bis man bei 60 Frames ist, aber nur ein paar Frames lange bzw je nach Algorithmus. Man kann den Algorithmus auch ein wenig flexibler machen und sich immer anschaun wie lange die zweite GPU wirklich braucht und Steigung der Funktion (ist ja nichts anderes) ständig anpassen. Vorausgesetzt natürlich das Prerenderlimit ist nicht zu hoch bzw es sind nur zwei GPUs im System. Bei mehr wird es dann wieder tendentiell schlecht, dh mehr "Mikroruckler" und längere Nachlaufzeit bis volle Performance.
Ja beide haben dafür Code in den Treibern, ob der so ähnlich funktioniert wie meine Möglichkeit die ich gerade skizziert habe ist eine andere Frage.
So ähnlich habe ich es mir auch vorgestellt. Messen wie lange Grafikkarte A braucht, davon ausgehen, daß Grafikkarte B ähnlich lange brauchen wird und dann die Annahme der Daten bei Grafikkarte B entsprechend verzögern. Und das gleiche Spielchen dann mit Grafikkarte A machen.
Diese Methode ist aber auch nicht ganz genau. Der Treiber müsste schon sehr genau ermitteln können wie lange die Grafikkarten für ein Frame brauchen. Dann wäre die "Nachlaufzeit" umso länger je niedriger die Bildwiederholrate ist. Und drittens, Spiele bei denen sich die Bildwiederholrate oft ändert würden dafür sorgen, daß man sich quasi permanent in der "Nachlaufzeit" befindet.
Richtig, deswegen sollte man mit Profilen und statistischen Methoden die Steigung der Funktion ständig ändern um die Nachlaufzeit zu minimieren. Den Nachteil, dass man höhere Frameraten braucht wird man nicht ganz wegbekommen. BTW für den Treiber ist es relativ einfach festzustellen wie lange ein Frame benötigt.
Meiner Meinung nach belibts trotzdem eine Krückenlösung.
reallord
2010-01-26, 19:57:59
Den Glättungsansatz haben wir doch sogar hier im Forum (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6636444#post6636444) schon mal besprochen. tb und später KiBa haben da auch Tools (Dlls?) geschrieben.
Könnte ATI/AMD nicht Hypertransport für eine neue Multi-Chip-Renderingmethode nutzen ?
Äh was soll das bringen? Hypertransport ist auf dem Level eher hinderlich.
@reallord
Das ist aber ein einfacherer Ansatz als der hier.
Ailuros
2010-01-27, 07:01:32
Ein Entwickler von Multicorechips wird immer Versuchen seine Chips modular zu gestalten- allein schon wegen der einfachen skalierbarkeit.
Ich glaube nicht, dass AFR die Zukunft ist.
Dazu gibt es zu viele Fragezeichen. (Latenzen?, Skalierbarkeit über n-Chips?)
Vielleicht werden ja Tile Based Renderer die Probleme lösen können.
Wie ich schon im originalen Thread sagte der einzige IHV der sich immer noch mit TBDR beschaeftigt ist PowerVR/IMG; da sich aber IMG schon seit Jahren auf den eingebetteten Markt konzentriert und es nicht danach aussieht dass sich daran etwas aendern wird, sehe ich keine Loesung diesbezueglich.
IMG benutzt SFR fuer ihre multi-core SGX543 IP und hw basierte Skalierung bzw. Datenverwaltung. Mit SFR skaliert Geometrie schlecht auf IMRs und AFR waere totaler Bloedsinn auf TBDRs.
Wenn Du jetzt meinen solltest dass ATI/NVIDIA irgendwann mal aufs DR Glatteis wagen sollte ist meine Antwort fuer ein solches Risiko nach wie vor nein so lange sie mit ihren IMRs das erreichen koennen was sie wollen. Mit den Erweiterungen die IMRs durch die letzten Jahre dazubekamen sind die Unterschiede zwischen IMR und TBDR auch nicht mehr so gross, ausser natuerlich Faellen wie extremes postprocessing.
Jetzt bleibt die Frage warum bis jetzt ATI/NVIDIA auf AFR fuer multi-chip basieren. Weil es nach wie vor ein Nischenmarkt ist und AFR eine ziemlich billige Loesung ist. Demirug hatte eine Idee wie man das Problem mit kleinem hw Zusatz loesen koennte; ob die IHVs aber darauf eingehen werden ist eine andere Frage.
Maorga
2010-01-27, 21:46:33
Hallo miteinander,
ich seh' das mit den MR bei dem Fermi Chip nicht so. Ich denke der Chip wird das komplette Bild berechnen bevor das nächste berechnet wird. Meiner Einschätzung nach wird Fermi nicht die Power haben um 2 Bilder seperat zu berechnen weil nVidia wird ja sicherlich höhere Auflösungen als auch mehr Leistung für bestimmte Shadereffekte bzw. Tesselation brauchen als dies heutige Karten müssen.
Wenn der Chip als ganzes zuerst ein Bild komplett ab arbeitet so wird es diese Mikroruckler nicht wirklich geben (so wie sie bei SLI vorkommen). Wenn's ruckelt dann reicht die Grakapower eben nicht mehr.
Ich denke nicht das nVidia eine Option mit einbaut mehrere Bilder auf verschiedenen bereichen des Chips rendern zu lassen. Man kann ja vorrausrendern lassen wenn genügend Zeit vorhanden ist, aber Leistung drosseln um 2 Bilder seperat berechnen zu lassen denke ich nicht.
Diese Problem betrifft doch mehr Grakas mit entfernten Einheiten (da dauert der Datenaustausch von GPU A zu B zu lange) da diese nur über diesen weg noch einiges an 'Performance' herausholen können. Bei Tiling, kann es sein dass eben eine GPU auf die andere wartet bis zum nächsten Bild.
Sicherlich ist der Chip sogesehen sehr modular aufgebaut zumindest was ich gesehen habe. Was zur Folge haben kann das man eben das Design bzw. die Maske auf einen halben Fermi machen kann ohne das 'Rad' neu zu erfinden.
Meine Glaskugel sagt mir Fermi wird keine Mikroruckler haben, entweder es ruckelt oder ruckelt nicht :)
Biba
Maorga
Hallo miteinander,
ich seh' das mit den MR bei dem Fermi Chip nicht so. Ich denke der Chip wird das komplette Bild berechnen bevor das nächste berechnet wird. Meiner Einschätzung nach wird Fermi nicht die Power haben um 2 Bilder seperat zu berechnen weil nVidia wird ja sicherlich höhere Auflösungen als auch mehr Leistung für bestimmte Shadereffekte bzw. Tesselation brauchen als dies heutige Karten müssen.
Wenn der Chip als ganzes zuerst ein Bild komplett ab arbeitet so wird es diese Mikroruckler nicht wirklich geben (so wie sie bei SLI vorkommen). Wenn's ruckelt dann reicht die Grakapower eben nicht mehr.
Ich denke nicht das nVidia eine Option mit einbaut mehrere Bilder auf verschiedenen bereichen des Chips rendern zu lassen. Man kann ja vorrausrendern lassen wenn genügend Zeit vorhanden ist, aber Leistung drosseln um 2 Bilder seperat berechnen zu lassen denke ich nicht.
Diese Problem betrifft doch mehr Grakas mit entfernten Einheiten (da dauert der Datenaustausch von GPU A zu B zu lange) da diese nur über diesen weg noch einiges an 'Performance' herausholen können. Bei Tiling, kann es sein dass eben eine GPU auf die andere wartet bis zum nächsten Bild.
Sicherlich ist der Chip sogesehen sehr modular aufgebaut zumindest was ich gesehen habe. Was zur Folge haben kann das man eben das Design bzw. die Maske auf einen halben Fermi machen kann ohne das 'Rad' neu zu erfinden.
Meine Glaskugel sagt mir Fermi wird keine Mikroruckler haben, entweder es ruckelt oder ruckelt nicht :)
Biba
Maorga
Fermi wird zu 99.99% kein AFR haben und daher keine MR.
Das ist aber auch nicht wirklich Thema des Threads;)
Exxtreme
2010-01-27, 22:12:00
Meine Glaskugel sagt mir Fermi wird keine Mikroruckler haben, entweder es ruckelt oder ruckelt nicht :)
Biba
Maorga
Solange man keine 2 Fermis betreibt, stimmt das. =)
Ailuros
2010-01-28, 07:22:14
Fermi wird zu 99.99% kein AFR haben und daher keine MR.
Das ist aber auch nicht wirklich Thema des Threads;)
Wofuer soll jetzt das uebrige 0.01% genau sein? Einer jeglichen single core GPU etwas wie alternate frame rendering zuzumuten waere metaphorisch gesehen die schoenste Beschreibung fuer hardware Schizophrenie.
Dabei frage ich mich sogar dass wenn ich mit mir selber plaudere ob ich dann irgendwann in einer Zelle untergebraucht werde oder ich und mein alter ego in getrennten Zellen ;D
MR-Diskussion ist bei PCGH+Co sinnfrei solange nicht von SSD gespielt wird.
min fps ist vollkommen wertlos, da nur frameverlauf aussagekräftig.
Über Latenzen von der 2.+3.+4. graka braucht man nicht reden solange Ram
und NB nicht vernünftig optimiert werden.
Es sollte mal jemand mit einem gut eingestellten Sys Frameverläufe erstellen.
NUR so kann festgestellt werden ob HD5xxx soo schlechte min fps hat, das es
unspielbar wird.
Meine Hawk-CF 950/1300 laufen bei Crysis auch unter 30fps smooth.
Die Ruckler sind eher streaming-lastig.(bei mir zur Zeit streaming=off)
Prinzipiell sind die HD5xxx absolut geil bei älteren Titeln+SSAA (NFSU2).
Es macht noch mal richtig Spass die älteren Games neu zu spielen.
Dafür wären Benchmarks interessant.
(PS:Vorteil mit vsync=an hat man fps-limit 60 = zur Kühlung der GPU wichtig!)
y33H@
2010-04-16, 11:22:02
Wieso sind Min-Fps sind "vollkommen wertlos", wenn es eindeutig CPU- oder GraKa-bedingt ist? :rolleyes:
Bei BC2 kacken die HD5k bei den Min-Fps im Vergleich zu den GTX 4x0 halt ab. Ist eben so.
Über Latenzen von der 2.+3.+4. graka braucht man nicht reden solange Ram
und NB nicht vernünftig optimiert werden.Was soll das wieder heißen?
boxleitnerb
2010-04-16, 11:53:54
Und warum nicht wenigstens mehrere min-Werte unter einer bestimmten Schwelle nehmen und mitteln? Oder irgendwas anderes, eben nicht nur eine einzige Zahl, die an und für sich sehr sehr wenig Aussagekraft hat. Ein einzelner Ausreißer nach unten (kann ja vorkommen in einer fordernden Szene) stört das Spielerlebnis jetzt nicht so als wenn es öfters passiert.
Grade ihr Benchprofis solltet doch wissen, dass es besser ist, mehr Informationen zu haben als weniger. Ob man sich dann aus einem Frameverlauf den niedrigsten Wert raussucht und sich daran auf- oder abgeilt, ist jedem selbst überlassen.
y33H@
2010-04-16, 12:03:32
Diese einzige Zahl hat sehr wohl Aussagekraft, sofern CPU- oder GraKa-limitiert. Und ob die nun in einem Balken oder in einem Verlauf abgebildet ist - an der Zahl ändert das nichts.
boxleitnerb
2010-04-16, 12:08:06
Ach? Und was, wenn dieses Minimum in einem 60 sec Bench genau 1x erreicht wird? Was sagt das dann über die Spielbarkeit aus?
Versteh ich echt nicht. Überall wird gesagt, Frameverläufe sind das Optimum, weil man eine komplexe Performancecharakteristik nicht in eine Zahl pressen kann. Und für die Minimalwerte soll das auf einmal nicht mehr gelten?
y33H@
2010-04-16, 12:34:20
Natürlich ist ein Verlauf das Optimum - aber die Art der Darstellung ändert an den Werten rein gar nichts.
Y33H Warum Ram +NB wichtig sind ?
für mich als Phenom II User schon!
Prinzipiell ist smoothes gameplay nur erreichbar, wenn ALLE Bandbreiten+Latenzen passen!
(da nehm ich lieber bei meinem Hawk-CF die gpu nicht auf 1100, solange der zug. Ram nur bei 1300 läuft; Experimente erst nach Ablauf der Garantie)
Was nützt die schnellste GRAKA mit DDR3-1066 CL7 ??? o.ä., sobald gestreamt
wird +CF/SLI.
Mouselags kenn ich bei vernünftigen Einstellungen gar nicht.
tombman
2010-04-16, 12:35:31
Man kann MR ganz leicht verhindern- indem man die Cpu so weit runterschraubt, daß sie knapp unter der Leistung der Gpus liegt. Dann gibts nämlich keine superschnellen frames mehr und in Folge auch keine superlangsamen ;)
10ms-50ms Kadenz kanns ja nur dann geben, wenn die cpu 100fps heraushauen kann. Wenn die Cpu aber nur 3x fps packt, dann gibts auch nur 3x ms frametime, also 30ms-30ms usw -> 30fps ohne MR ;)
Oder man holt sich so scheiße viel Leistung, daß man fast immer 60fps hat, dann ist man eh in der Wohlfühlzone -> das mache ich ;)
y33H@
2010-04-16, 12:39:11
@ Gast
NB und RAM haben aber einen schei0 mit µRucklern ["Latenzen von der 2.+3.+4. graka"] zu tun.
Was nützt die schnellste GRAKA mit DDR3-1066 CL7 ??? Du lebst in einer Traumwelt. Im GPU- oder CPU-Limit ist es schei0egal, ob du 1066er @ CL7 hast oder 2000er @ CL6. In der normalen Spielepraxis ist's auch vernachlässigbar.
Mouselags kenn ich bei vernünftigen Einstellungen gar nicht.Das bist du schlicht unempfindlich.
skampi
2010-04-16, 12:40:39
Und warum nicht wenigstens mehrere min-Werte unter einer bestimmten Schwelle nehmen und mitteln? Oder irgendwas anderes, eben nicht nur eine einzige Zahl, die an und für sich sehr sehr wenig Aussagekraft hat. Ein einzelner Ausreißer nach unten (kann ja vorkommen in einer fordernden Szene) stört das Spielerlebnis jetzt nicht so als wenn es öfters passiert.
Grade ihr Benchprofis solltet doch wissen, dass es besser ist, mehr Informationen zu haben als weniger. Ob man sich dann aus einem Frameverlauf den niedrigsten Wert raussucht und sich daran auf- oder abgeilt, ist jedem selbst überlassen.
Wesentlich aussagekräftiger wäre eine Angabe der Streuung mit einer Methode zur Kompensation der Gewichtung von Ausreissern.
boxleitnerb
2010-04-16, 12:42:02
Natürlich ist ein Verlauf das Optimum - aber die Art der Darstellung ändert an den Werten rein gar nichts.
Das hab ich auch nicht behauptet. Der niedrigste Wert in einem Bench ändert sich nicht, logisch. Ach was rede ich, du hast meinen Einwand schon verstanden. Mir dann sowas zu erzählen wie in dem Zitat...echt jetzt! Ich muss ja ziemlich blöde auf dich wirken, oder? Naja, EOD.
@skampi: Erzähl das y33H@, nicht mir. Wenn er es versteht/verstehen will.
skampi
2010-04-16, 12:47:10
Das hab ich auch nicht behauptet. Der niedrigste Wert in einem Bench ändert sich nicht, logisch. Ach was rede ich, du hast meinen Einwand schon verstanden. Mir dann sowas zu erzählen wie in dem Zitat...echt jetzt! Ich muss ja ziemlich blöde auf dich wirken, oder? Naja, EOD.
@skampi: Erzähl das y33H@, nicht mir. Wenn er es versteht/verstehen will.
Ja, war mehr eine Ergänzung deiner Aussage.
Y33H Ram egal???
Es kann doch nicht das Problem sein GUTEN RAM zu verwenden!
Wenn ich bei CF Wert auf PCIe-16 lege, dann werd ich mir doch nicht ne Bremse
in den Ram bauen!
DDR2 CL5@1150 OCZ REAPER 2x2GB für 45€ gebraucht.
(Bei neueren Boards +Phenom II dürft Ihr gerne mal scharfe Settings nehmen,
wenn Ihr MR untersucht; ala techPowerUp "cdawall" macht Euch einiges vor)
Mouselag-Diskussion errinnert mich an AQUANOX, damals mit Triplebuffer+fps-limit gelöst.
Wieso sind Min-Fps sind "vollkommen wertlos", wenn es eindeutig CPU- oder GraKa-bedingt ist? :rolleyes:
Da hat er schon recht, Min-FPS ist ein einziger Wert der überhaupt nichts aussagt.
Weder für Performancevergleiche, wieso man da überhaupt auf minimale FPS reduzieren will ist mir schleierhaft, noch für die Spielbarkeit.
Bei Performancevergleichen interessiert die Spielbarkeit praktisch überhaupt nicht und man sollte dafür so viele Messergebnisse wie möglich verwenden, AVG-FPS sind hier schon recht gut und je länger die Testszene dafür ist umso besser.
Für die Spielbarkeit ist das natürlich nicht besonders aussagekräftig, Min-FPS sind es aber noch viel weniger. Ein einzelner Ruckler unter eine bestimmte Schwelle im ganzen Spiel stört überhaupt nicht, selbst wenn dieser reproduzierbar ist und sich eventuell auch noch auf die Grafikkarte eingrenzen lässt, die MinFPS werden damit aber runtergedrückt.
Für die Beurteilung der Spielbarkeit ist es immer noch gut jemanden wirklich Spielen und das ganze beurteilen zu lassen. Natürlich ist das ganze dann stark subjektiv.
Wenn man die Spielbarkeit halbwegs Sinnvoll objektiv beurteilen will gibt es nur 2 Möglichkeiten.
Entweder Frameverläufe, die aber den Nachteil haben, dass sie sehr schnell unübersichtlich werden.
Die andere Möglichkeit wäre Frameratenbereiche zu definieren.
Man nimmt beispielsweise die Bereiche 0-15FPS, 15-30FPS und 30+FPS und ermittelt wieviel % der Frames in die jeweiligen Bereiche fallen. Wobei man über die Grenzen natürlich diskutieren kann, und diese wohl sinnvollerweise je nach Spiel anpassen sollte. (Bei schnellen Shootern sollte man die Obergrenze wohl auf 60+ setzen, und im kritischen Bereich zwischen 15 und 30fps wäre wohl eine feinere Unterteilung Sinnvoll)
Damit hätte man gleich mehrere Vorteile. Man reduziert die Messergebnisse pro Karte zwar nicht mehr auf ein einziges, aber doch auf eine überschaubare Anzahl, im Gegensatz zu den Frameverläufen. Zusätzlich erwischt man die Mirkoruckler von Multi-GPU voll und kann relativ Sinnvolle objektive Aussagen über die Spielbarkeit machen.
y33H@
2010-04-16, 15:00:28
Man nimmt beispielsweise die Bereiche 0-15FPS, 15-30FPS und 30+FPS und ermittelt wieviel % der Frames in die jeweiligen Bereiche fallen.Das ist eine geile Sache, ja. Wurde auch schon gemacht (etwa hier (http://www.pcgameshardware.de/aid,650880/Spielbarkeit-von-GT200-und-RV770-in-Crysis/Crysis/Test/?page=2)). Problem: Die meisten Leute checken nicht mal Balken ;(
boxleitnerb
2010-04-16, 15:04:33
Im Ernst? Grad die gewählten Farben (Ampelsystem) machen es doch mehr als deutlich.
Dazu noch für die schnellen Leser ein avg-Diagramm und gut ist. Sollte eigentlich Standard werden.
y33H@
2010-04-16, 15:21:36
Viele wollten die klassischen Avg-Balken. Denn wer den längsten hat ... das kapiert jeder [MGPU außen vor]. Wer etwas verbessern oder differenzierter darstellen möchte, muss immer daran denken, ob es "die da draußen" auch verstehen und auch annehmen. Ansonsten war in den Sand gesetzter Aufwand/Zeit.
Das ist eine geile Sache, ja. Wurde auch schon gemacht (etwa hier (http://www.pcgameshardware.de/aid,650880/Spielbarkeit-von-GT200-und-RV770-in-Crysis/Crysis/Test/?page=2)).
Sieht ja schon mal nicht schlecht aus, ich würde die graphische Darstellung aber etwas überarbeiten, in etwa so:
http://img89.imageshack.us/img89/9688/unbenannt1gi.png
Dann braucht man pro Karte immer nur 1 Balken, was das ganze wesentlich übersichtlicher macht. Man könnte es dann auch eventuell in 4 oder 5 Bereiche unterteilen ohne das die Lesbarkeit wesentlich leidet. Mit 5 Balken untereinander wird es schon recht unübersichtlich.
Problem: Die meisten Leute checken nicht mal Balken ;(
Für die ist es dann aber auch egal.
boxleitnerb
2010-04-16, 16:29:28
Das hat den Nachteil, dass bei sehr unterschiedlichen Balkenverteilungen untereinander die Lesbarkeit eben doch etwas leiden kann, weil man dann z.B. verschiedene Farben direkt untereinander hat. Auch fällt das Abschätzen der Prozentzahlen schwer, sofern diese nicht noch extra angegeben sind.
Die Darstellung von der PCGH fand ich schon ganz gut, aber man müsste mal beides gesehen haben, um gut vergleichen zu können.
Das hat den Nachteil, dass bei sehr unterschiedlichen Balkenverteilungen untereinander die Lesbarkeit eben doch etwas leiden kann, weil man dann z.B. verschiedene Farben direkt untereinander hat.
So lange man es nicht mit der Farbenanzahl übertreibt sollte das nicht wirklich ein Problem sein
Auch fällt das Abschätzen der Prozentzahlen schwer, sofern diese nicht noch extra angegeben sind.
Die sind ja auch nicht wirklich relevant, ob ein Feld jetzt 30 oder 35% breit ist, ist ziemlich uninteressant.
Sinnvoller wäre da schon daneben noch den AVG-FPS-Wert anzugeben. Dann könnte man alle Zufrieden stellen. Wer will vergleicht einfach die Zahlen und wer mehr Informationen kann sich die Diagramme genauer ansehen.
y33H@
2010-04-16, 17:45:15
Dann braucht man pro Karte immer nur 1 Balken, was das ganze wesentlich übersichtlicher macht. Diese Idee ist sehr gut - vor allem lassen sich diese Balken sehr schön sortieren, spricht, die Karte mit den meisten Avg-Fps, sollte auch am meisten Grün schaffen. Und wie erwähnt, könnte man die Avg- und Min-Fps dazu packen. We'll try =)
Kleiner Haken: Aufwendiger als stupide Balken oder Verläufe.
N0Thing
2010-04-16, 19:35:21
Dafür bietet ihr euren Lesern dadurch aber auch mehr Qualität als die Konkurrenz. Vielleicht setzt sich "euer" System nach 1-2 Jahren durch.
y33H@
2010-04-16, 19:41:15
Online ist es kein Problem, Print ist es auch eine Frage des Layouts. Wie gesagt - we'll try.
Kleiner Haken: Aufwendiger als stupide Balken oder Verläufe.
Aufwändiger als einfache AVG-Balken sicher, aber aufwändiger als Verläufe?
Doch nicht wirklich, in beiden Fällen muss man die Daten über die ganze Sequenz sammeln, ob man die nun aufaddiert oder daraus ein Verlaufsdiagramm macht ist doch eigentlich ein ähnlicher Aufwand.
Zumindest im Print sind einfache AVG-FPS-Diagramme eigentlich nur vergeudeter Platz. Man könnte genauso gut die Ergebnisse in einer Tabelle auflisten, was wesentlich weniger Platz benötigt und genau gleich viel Information übermittelt.
Wenn ich die Idee recht verstehe…
Online ist es kein Problem, Print ist es auch eine Frage des Layouts. Wie gesagt - we'll try.
Wir hatten sogar schonmal solche Benchmarks, die die Anteile an den erreichten Fps farblich dargestellt haben (so bis 2006 ab und zu mal, wenn ich mich richtig erinnere).
Es wurde aber eingestellt, weil es bei unserer Zielgruppe nicht ankam.
-Carsten
REVIEWER sind keine VERKÄUFER.
Was mich in vielen Reviews stört sind die unrealen Grafiksettings, da viele User kleinere Grakas für ein CF/SLi verwenden= keine Chancengleichheit.
Nur was auf der Einzelkarte mit 2xAA läuft kann ich im CF/SLI mit 4xAA benchen!(hardocp mit apples to apples ist ein guter Anfang)
Gute Reviews zeigen wie verheerend heutige Karten mit AF4/16 einbrechen.Für mich mit 28" ist 4*AA wichtiger,daher Grafik 100-->95% TWEAK .
Früher war 4AA+4AF!
Heute oft Reviews mit 16AF im TREIBER (=no go; vgl. DOOM 3 Diskussion nur ingamesettings sind akzeptabel)
Gerade bei crysis nutze ich persönlich dof+pom --> AF= off
Negative Bsp., wo EIN Setting für die Einzelkarte schon kritisch:
Heaven v.1.1 Occlusion Culling = on/off
WIC-Benchmark AF=16/4 bei BigBang +
Option Bildschirmauflösung=on/off im Bench kontraproduktiv.
Trümmerphysik nur mit INTEL im Bench an.
WIC kann auch jeder selber austesten, da integrierter Frameverlauf +fps-limiter+ Anzeige Physik+Partikel.
Warum nicht fps-limiter in allen games?(Lob an Massive)
Spiele im beta-Status gehören nicht in Hardware-Reviews, dafür gibt es Spiele-Reviews und Foren.(BC2 vor Cat.10.4 Preview, Metro2033 etc.,
Ich kaufe nur ausgereifte Spiele mit Patch+Treiber =100%, soo viel Geduld muß sein)
Y33H_Probs bei BC2
Mal inzwischen mit Cat10.4P gespielt?
Vermisse bei einigen Reviewern ein entspr. Update.
Bei meiner Lieblings_Website nicht mal unter Topdownload.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.