microruckeln - wieso ist eine lösung so schwer?

[DarkMo]

microruckeln - wieso ist eine lösung so schwer?

also das thema gibts ja nun schon etwas länger. nv hats wohl einigermaßen im griff, ati schwächelt hier. aber wieso gibts da keine guten lösungen?

das kernproblem liegt ja darin begraben, das mehrere karten mehrere bilder parallel berechnen und eben nicht gleichmäßig ausgeben. selbst wenn man einigermaßen synchron starten könnte, kann diese synchronität schlecht bis garnicht aufrecht erhalten werden.

aber wieso berechnen nich einfach beide das selbe bild? ihr kennt och sicher dieses cinebench, wo die cpu das motorad bild rendert. jeder kern startet an einer anderen position (x=0, y=CoreNr*YMax/CoreZahl) undb erechnet zeile für zeile. hat einer seinen bereich beendet, so wird der größte restbereich gesucht, und in desen mitte angefangen und somit der andere kern unterstützt.

wieso geht das bei en gpu's nich? ich denke mal, wenn es ginge, würden sies schon so machen ^^ sinds die verteilten ressourcen? also eben das jede gpu ihren eignen ram hat? aber die haben ja auch jetz schon die selben daten im ram - also gleiche ausgangslage, nur eben bei 2en nur halb soviel zu berechnen damit. an den ausgangsdaten sollte sich ja eigentlich nix ändern, womit für mein verständnis dieses problem hinfällig wäre. also auch wenn die ressourcen verteilt sind, so haben alle karten das selbe grundlagen material um ihren jeweiligen part zu machen.

bliebe höchstens die kommunikation, wo die berechnung grad steckt. also dass man die restbereiche da ermitteln kann, um diese mit zu bearbeiten. aber das sollten ja minimale größen sein, im byte bereich oder wenige bits. das sollte doch auch kein problem darstellen oder?

aber vllt weis ja einer von euch nen bissl mehr über die thematik, wieso sie diesen quark mit "jede ihr eigenes bild" un ned "alle an einem" nutzen. bin gespannt auf die diskussion

 

[axel25]

AW: microruckeln - wieso ist eine lösung so schwer?

Das gibt es ja! Das meistgenutze MGPU-V/erfahren) heißt AlternateFrameRendering! Wie der Name bereits sagt, brechnet jede GPU ein Bild! Dannn gibt es noch ein Verfahren, bei dem eine GPU den unteren und eine den oberen Teil brechnet, ein anderes teilt das Bild in ein Karomuster (Schachbrett!) ein, jede GraKa berechnet quasi Schwarze oder Wieiße Kästchen! Bei den beiden letzten Verfahren gibt es keine Mikroruckler! Allerdings verspricht nur AFR mehr Perfomance als eine Single-GPU, daher wird es von ATI/nVidia verwendet! Allerdings kannst du bei nVidia die MGPU-Render-Methode selbst bestimmen über den nHancer!

 

[Two-Face]

AW: microruckeln - wieso ist eine lösung so schwer?

Der Hund liegt halt woanders begraben - eine hardwareseitige Lösung ist da recht schwierig, auch wenn ein ehemaliger ATI-Mitarbeiter vor längerer Zeit behauptet hat, man könne dies mit einer speziellen Mechanik beheben - treiberseitig lässt sich aber momentan mehr machen.
Das Problem ist, ATI weiß ganz genau, wie ihr CrossFire teilweise krankt, macht aber nix dagegen, solange es Leute gibt, die'sich's kaufen.

 

[-SkiDroW-]

AW: microruckeln - wieso ist eine lösung so schwer?

Der Hund liegt halt woanders begraben - eine hardwareseitige Lösung ist da recht schwierig, auch wenn ein ehemaliger ATI-Mitarbeiter vor längerer Zeit behauptet hat, man könne dies mit einer speziellen Mechanik beheben - treiberseitig lässt sich aber momentan mehr machen.
Das Problem ist, ATI weiß ganz genau, wie ihr CrossFire teilweise krankt, macht aber nix dagegen, solange es Leute gibt, die'sich's kaufen.

tja - beide grafikkartenhersteller haben ihre leichen im keller...

treiberseitig etwas zu ändern wäre garnicht sooo schwer - nur hat keiner bock dazu, weil die meisten single-gpus kaufen und es dem anderen rest kaum was ausmacht...

 

[INU.ID]

AW: microruckeln - wieso ist eine lösung so schwer?

das kernproblem liegt ja darin begraben, das mehrere karten mehrere bilder parallel berechnen und eben nicht gleichmäßig ausgeben. selbst wenn man einigermaßen synchron starten könnte, kann diese synchronität schlecht bis garnicht aufrecht erhalten werden.

Ich bin diesbezüglich zwar kein Fachman, aber jemand der sich auskennt meinte mal zu mir das es eigentlich kein wirkliches Problem wäre, aber auf Kosten der Leistung gehen würde. Zumindest wenn jede GPU immer ein kompettes Bild rendert. Denn eine GPU von beiden GPUs wird immer eher fertig sein, weil die Bilder sich vom Aufwand her immer etwas unterscheiden, daher müsste diese dann mit der Ausgabe auf die andere GPU warten. Dies würde zwangsweise die FPS künstlich reduzieren. Läßt man aber beide fröhlich drauf los rendern, und stört sich nicht am MR, dann hat man dafür höhere/mehr FPS. Und FPS verkaufen sich nunmal besser als (kein) MR.

Das Optimum wäre daher das gleichzeitige Rechnen an einem Bild. Eigentlich sollte auch das kein wirkliches Problem sein, denn aktuell besteht eine GPU ja auch aus mehreren Rechenkernen. Daher sollte man meinen das es keine Rolle spielt ob nun eine GPU mit (nur mal als Beispiel) 800 Kernen oder zwei mit 1600 Kernen an einem Bild rechnen - wenn man sie logisch zu einer GPU zusammenfassen würde. Aber genau das scheint (angeblich) nicht so einfach möglich zu sein. Warum auch immer.

Ich bin jedenfalls davon überzeugt das es MR eigentlich nicht mehr geben müsste... zumindest (bei AFR) wenn beide GPUs auf einer Platine arbeiten (bei zwei getrennten Karten sieht die Sache noch etwas anders aus, das es (das Berechnen unterschiedlicher Bilder, also AFR) dort nicht ganz so einfach ist - aufgrund der Kommunikation über den Bus usw - kann ich noch irgendwo nachvollziehen)

 

[Two-Face]

AW: microruckeln - wieso ist eine lösung so schwer?

Früher, zur Zeiten von DX9-Karten, war dieses Problem auf jeden Fall weitaus weniger vertreten - da wurde nie ein Wort über Mikroruckler verloren. Stattdessen wurden immer nur andere Probleme, wie schlechte Skalierung, genannt.
Ich hab mit meinem Gespann nie wirklich was von Mikrorucklern mitbekommen, auch nicht bei <30fps...

 

[DarkMo]

AW: microruckeln - wieso ist eine lösung so schwer?

hmm, zumindest scheinen wir alle der gleichen meinung zu sein ^^ würden alle gpu's das selbe bild berechnen (wie gesagt, die arbeitsweise von cinebench find ich ganz gut, da arbeiten alle bis zum schluss am bild. sprich die schnellsten helfen der schwächsten. damit wären sogar 4870/5870 gespanne denkbar (mit dx10 dann halt nur)), gäbs das problem nich. bleibt eben nur ie frage: wieso gehts ned?

 

[axel25]

AW: microruckeln - wieso ist eine lösung so schwer?

@Two-Face: Ich glaube ATI hat bis zur HD200-Serie kein AlternateFrameRendering verwendet, sondern das Muster oder halbe-halbe-Verfahren.

 

[Two-Face]

AW: microruckeln - wieso ist eine lösung so schwer?

Nö, das wurde soweit ich informiert bin schon immer unter anderem bei CrossFire verwendet - nur dass damals eben nicht ausschließlich auf AFR gesetzt wurde.

 

[netheral]

AW: microruckeln - wieso ist eine lösung so schwer?

Es gibt ja jetzt diesen Lucid Hydra Chip, der das Problem wohl in den Griff bekommen hat, ohne auch wirklich an Performance zu verlieren.

Ansonsten ist imho Multi-GPU nicht benutzbar. Ich habe mal an einem SLI System gezockt (und AMD Karten sollen ja noch anders abgehen) und hatte Anfälle von Augenkrebs und Kopfschmerzen.
Wie man sich das freiwillig geben kann... ich kann es nicht nachvollziehen. Aber ich scheine wohl einfach zu den Probanten zu gehören, die es extrem stark wahrnehmen. Mein Bekannter fragte mich z.B., was für ein Ruckeln ich meinen würde.

Aber naja, Mikroruckeln + doppelter Preis + vielleicht 40 - 50 % mehr Leistung = ohne mich. Lieber eine starke Single-GPU-Karte. Ist außerdem stromsparender als so ein SLI/CF Verbund.
Dazu diese Logik, 2 schwache Karten zu koppeln... Es waren bei ihm 2x 9800 GT... Und die hat er sich zu zeiten gekauft, wo es die 2xxer Reihe schon gab.

Und da ich eh fast nur Budget Titel kaufe, die alle auf meiner HD4870 wie geschnitten Brot gehen, habe ich eh kaum Probleme damit.

Ansonsten verzichte ich lieber aufs 4xMSAA / 16:1 AF.
Lieber nur 2xAA / 4x AF oder gar nicht als diese Augenfolter.

 

[-_Elvis_-]

AW: microruckeln - wieso ist eine lösung so schwer?

Ich denke mal, dass es Treibermäßig viel schwieriger umzusetzen ist, (und performancemäßig schlechter, wenn man die MR außer acht lässt) dass die GPUs am selben Bild rechnen.

Und ich denke die meisten Kunden kümmern sich nicht um MR sondern schauen sich das FPS Diagramm an. Dann ist es ja wohl logisch dass sie sich nicht um die MR kümmern, sondern darum große FPS Balken zu produzieren

Vermutlich ist das verteilte Rechnen an einem Bild auch ungünstig wenn ein Blur Effekt, AA o.Ä drüberliegt.

 

[Jan565]

AW: microruckeln - wieso ist eine lösung so schwer?

Das mit 2 Seperaten Karten kann ich mir etwas Problemematisch vorstellen, bezüglich des beseitigen der Mikroruckler. Schließlich müssen alle daten wieder von der einen zur anderen und dann auf den Monitor. Dann kommt noch die Zeit dazu, die die daten von A nach B brauchen. Zumindest ist das meine vermutung dazu.

Was mich eher frage ist, warum haben 2GPU karten Probleme damit. Die Chips liegen direkt neben ein ander, haben eigenständigen ram und sind an sich zu 100% gleich. Da sollte es doch eigentlich kein Problem sein die da zu beseitigen.

Aber die Idee, dann die Karten das selbe bild berechnen finde ich nicht so pralle, weil wo bleibt da der sinn. Beide berechnen das gleiche bild und geben es wieder. Das ist doch eigentlich sinnlos, weil man dadurch keine Leistungssteigerung egal in welchem bereich hat. Oder verstehe ich da was falsch?

 

[Two-Face]

AW: microruckeln - wieso ist eine lösung so schwer?

Was mich eher frage ist, warum haben 2GPU karten Probleme damit. Die Chips liegen direkt neben ein ander, haben eigenständigen ram und sind an sich zu 100% gleich. Da sollte es doch eigentlich kein Problem sein die da zu beseitigen.

Was hat das den bitte mit dem Übertragungsweg zu tun?
Das Problem ist, dass jedes zweite Frame länger berechnet wird, da können die GPUs noch so dicht aneinander liegen.
Das was du meinst, sind Input-Lags.

 

[Jan565]

AW: microruckeln - wieso ist eine lösung so schwer?

Aso.

Könnte man nicht so was mit hilfe eines "Dual-Core" GPU´s in den griff bekommen? Dann kann man es doch so lösen, das einfach die aufgaben aufgeteilt werden. Die eine GPU macht die Physix die andere die Texturen beispielsweise. Das dürfte dann doch das Problem lösen. Ich kenne mich da auch nicht so aus, und vermute mal das da eine ganze mänge mehr hinter steckt.

 

[Two-Face]

AW: microruckeln - wieso ist eine lösung so schwer?

Dual-Core-GPUs?
Öhm......die gibt's doch schon seit über 10 Jahren....sogar, 128-Core, 240-Core und sogar 1600-Core-GPUs.

 

[Superwip]

AW: microruckeln - wieso ist eine lösung so schwer?

Man könnte die GPUs sicher für Multi- GPU Systeme optimieren (bessere Vernetzung, gemeinsamer RAM,...) und so die meisten Probleme aus der Welt schaffen aber die GPUs würden dadurch teurer- da es zu aufwendig ist für den kleinen Markt der Multi- GPU Systeme eigene GPUs herzustellen würde das auch die Singelchip Karten teurer machen (die davon natürlich nicht profitieren würden) und das will natürlich niemand

 

[DarkMo]

AW: microruckeln - wieso ist eine lösung so schwer?

Aber die Idee, dann die Karten das selbe bild berechnen finde ich nicht so pralle, weil wo bleibt da der sinn. Beide berechnen das gleiche bild und geben es wieder. Das ist doch eigentlich sinnlos, weil man dadurch keine Leistungssteigerung egal in welchem bereich hat. Oder verstehe ich da was falsch?

die solln ja ned beide das gleiche bil vollständig berechnen, sondern jede karte eben nur ihren part. und die die schneller fertig is mit ihrem stück, unterstützt die andere beim rest ihres stückes. eben so wie es der cinebench da auch macht. bei nem quad sieht man da ja auch schön, wie da bild an 4 stellen gleichzeitig berechnet wird.

aber das argument mit blur zum bsp ist gut. also generell so post-rendering effekte. sprich, das bild ist berechnet und wird mit nachträglichen filtern bearbeitet. diese filter greifen ja meist (immer? ^^) auch auf die umliegenden pixel zu. hmm, aber solange die berechnung des folgepixels nicht auf der berechnung des aktuellen pixels beruht, sollte das keinerlei probleme verursachen. nagut, doch - wenn das erste rendering ohne jegliche filter abgeschlossen ist, müssten die karten ihre ergebnisse wieder synchronisieren, so das beide das komplette bild als ausgangsbild für den/die folgenden filter wieder zur verfügung haben. also auch hier wieder erhöhter kommunikationsaufwand. nu weis ich ned, wie effizient diese crossfire/sli brücken da bei der datenübertragung sin. aber an sich müssen die ja maximal je bild eben das bild an sich (zum bsp halt in 1920x1080) übertragen. hmm hmm.

also je weiter ich drüber nachdenke, desto mehr probleme werden mir bewusst ^^ das schlimste wäre wirklich die zusätzliche kommunikation zur gegenseitigen synchronisation. vllt wäre es da am effektivsten, wenn die cf/sli brücken mehr als nur ein datenkabel wären - nämlich noch nen kleinen chip mit mini ram hätten - oder eben sowas wie der l3 da von amd als brückenpendant (brauch ja ned mal nen chip - nur was, das alle teilergebnisse immer aktuell zusammenfasst. jede karte bekommt alle daten für das bild - so wie auch bei einzel berechnung. hmm, nen chip wär vllt doch gut ^^. der würde dann die bereiche für jede karte berechnen (diese mehr als simple formel da) und ihnen diese zuweisen. ist die karte damit fertig, wird ihr ergebnis in den gpu-brücken-l3 geschrieben ^^ und der chip gibt ggf anweisung, in restbereichen, welche die anderen langsameren gpu's noch nicht berechnet haben, mitzuhelfen. wurden alle bereiche bearbeitet und gerendert, hat ja jede karte das l3-ergebnisbild da ja aktualisiert und das ist nun das ergebnisbild. für darauffolgende filter (aa, blur, af auch? kA wie und ann das berechnet wird ^^) lät jede karte das ergebnisbild als neues source bild ausm brücken-l3 und berechnet wieder seinen part. ginge wie gesagt nur bei filtern, die rein auf grundlage des src-bildes operieren und nicht auf schon berechneten, durchn filter veränderten, bereiche basieren. um da ne effiziensansage machen zu können, müsst man aber wissen, wie das alles funzt ^^

aber faktisch sollte es so möglich sein, die berechnung eines bildes auf mehrere gpu's auszulagern, die sogar unterschiedlich schnell sein können. nur der ram müsste nach wie vor auf dem kleinsten gemeinsamen basieren (da ja alle imernoch den selben krams erstmal brauchen). der kommunikationsaufwand sollte auch nicht soooo wild sein. nur bei solchen effekten, die sich nicht paralellisieren lassen (da sie serieller natur sind) müsste man dann halt die arbeit wieder eine gpu verrichten lassen, aber das is mit bissl glück kein allzugroßer teil der berechnung eines bildes und würde somit vllt bei dual gpu berechnung nur 10% geschwindigkeitsverlust ausmachen. also mal aus der luft gegriffen brauch die einzelne gpu 20 sekunden fürs bild , zu zweit werden aber keine glatten 10sekunden draus, sondern nur 12 sekunden, da sich nich alles paralellisieren lässt und kommunikationsaufwand ensteht.

auch wäre der single gpu markt davon verschont, wenn dieser brücken-l3 da eben auf der brücke hockt. dann sind die karten allein für sich immernoch vollkommen unabhängig davon. nur wer sli oder cf will, müsste dann halt etwas tiefer in die tasche greifen und den chip un cache da mitbezahln.

hmm, zumindest ein recht interessantes gedanken experiment ^^

 

[axel25]

AW: microruckeln - wieso ist eine lösung so schwer?

Das was du sagst mit dem gemeinsamen RAM wäre schlecht zu realisieren, da z.B. GPU2 andere Daten braucht als GPU1! Das mit dem gemeinsam ein Bild rendern ist ja bei Nvidia möglich, man kann Render-Verfahren über den nHancer wählen!

Grundsätzlich hat nVidia MR bei Dual-GPU-Systemen weitgehend im Griff! Wie ein Lucid Hydra die Frames synchroniesiert ist unbekannt!

Bezügöich des M-GPU-Problems Eingabeverzögerung hatte ich die Idee (was auch MR einschränken könnte) (und was jetzt mit Fermi/Cypress logisch erschein) ein Spiel mit einem Patch auf das jeweilige M-GPU-Gespann zu optimieren!

Fermi1 rechnet Bild 1 in 360°. GPU schickt Bild an Monitor und Daten an Fermi zwei und 3!
Diese berechnen wiederum 360° Bilder un schicken die Daten weiter an die anderen GPus!
Mit diesem städnigen Datenaustauschen und 360°-Grobrendern (erst die endgültige Ansicht wird detailliert gerendert!) dürfte es doch nur noch zu einer geringen Eingabe-Verzögerung kommen, oder? Und die Leistung wäre vllt. etwas unter dem normalen Skalierungs-Niveau.