Archiv verlassen und diese Seite im Standarddesign anzeigen : Gründe gegen SFR???
_DrillSarge]I[
2008-03-15, 13:35:17
nun geistert dieses afr-frametime problem ja schon eine ganze weile durch die welt. noch immer gibt es keine lösung. warum nutzt man nicht sfr? sicher geht kein zeilenweises berechnen wie bei voodoos mehr, aber was ist mit bspw. quadweise (oder halt gröber)? was gibt es (technisches) dagegen einzuwenden? das die effizienz von multi-gpu abnimmt (höchstwahrscheinlich) ist dabei egal.
bitte um aufklärung :)
€: ja, sfr wird heute auch angeboten, geht aber meistens nicht (richtig).
Die Effizienz nimmt aber zu drastisch ab. Da lohnt sich das ganze kaum noch..
reunion
2008-03-15, 14:10:01
Schau dir doch Supertiling an, welches das Bild quadweise aufgeteilt hat. Die Effizienz war gelinde gesagt nicht vorhanden.
_DrillSarge]I[
2008-03-15, 14:11:53
Schau dir doch Supertiling an, welches das Bild quadweise aufgeteilt hat. Die Effizienz war gelinde gesagt nicht vorhanden.
man kann es ja auch grober wählen. es kann ja nicht so arg sein, das bild zu viertel (so in etwa ;)).
Schau dir doch Supertiling an, welches das Bild quadweise aufgeteilt hat. Die Effizienz war gelinde gesagt nicht vorhanden.
Wodran liegts? Doppelte Geometrieberechnungen? Kommunikation zwischen den GPUs für berechnete Texturen?
_DrillSarge]I[
2008-03-15, 14:17:00
Wodran liegts? Doppelte Geometrieberechnungen? Kommunikation zwischen den GPUs für berechnete Texturen?
davon mal abgesehen, machts in den punkten afr auch nicht großartig anders ;)
Wodran liegts? Doppelte Geometrieberechnungen? Kommunikation zwischen den GPUs für berechnete Texturen?
weder noch, SFR mit load-balancing könnte durchaus einigermaßen effizient sein und auch das supertiling sollte in den meisten fällen die last recht gut verteilen (die tiles sind übrigens deutlich größer als quads, ich glaube es waren 16x16 pixel)
schwierig wird es allerdings das ganze mit heutigen rendertechniken zu machen. kaum ein spiel, welches technisch anspruchsvoll ist, kommt heute ohne post-processing aus, verwendet das spiel HDRR ist es sogar zwingend notwendig.
diese PP-effekte machen heute auch einen nicht unerheblichen teil des gesamten rechenleistungsbedarfs aus.
damit SFR überhaupt funktioniert sind deshalb jede menge spielespezifische kompatibilitätssettings notwendig und es muss jede menge zwischen dein einzelnen karten hin und hergeschaufelt werden.
zusätzlich wird der eigentliche parallelisierbare teil der grafikberechnung relativ gering, da viele dinge nicht mehr parallell gerechnet werden können (geometrie, PP etc.)
SFR ist in modernen spielen deshalb weder von der performance noch von der kompatibilität zufriedenstellen.
AFR läuft dagegen in den meisten fällen mehr oder weniger automatisch und bringt gleichzeitig eine gute leistungssteigerung und geringe kompatibilitätsprobleme.
wie ist das eigentlich wenn man 3 grakas an 3 monitore anschließt? also ne art triplehead aber eben wo jede graka das bild für einen monitor berechnet, geht sowas?
wie ist das eigentlich wenn man 3 grakas an 3 monitore anschließt? also ne art triplehead aber eben wo jede graka das bild für einen monitor berechnet, geht sowas?
Das ist auch SFR.
wie ist das eigentlich wenn man 3 grakas an 3 monitore anschließt? also ne art triplehead aber eben wo jede graka das bild für einen monitor berechnet, geht sowas?
prinzipiell ja, allerdings muss das die software erledigen.
_DrillSarge]I[
2008-03-16, 12:46:24
SFR ist in modernen spielen deshalb weder von der performance noch von der kompatibilität zufriedenstellen.
AFR läuft dagegen in den meisten fällen mehr oder weniger automatisch und bringt gleichzeitig eine gute leistungssteigerung und geringe kompatibilitätsprobleme.
trotzdem ist das ja weiterhin unbefriedigend, was afr (größtenteils) verzapft.
anscheinend, sind die ihvs auch nicht in der lage das problem zu beseitigen. es wird gesagt "uns ist das problem bekannt" oder "kauf dir noch 2 grakas, damit es nicht so sehr auffällt" :ugly:
I[;6358447']trotzdem ist das ja weiterhin unbefriedigend, was afr (größtenteils) verzapft.
es wäre wohl wesentlich einfacher bei AFR die frametimes halbwegs synchron zu halten als die ganzen spiele für SFR kompatibel zu bekommen. auch die performance wäre wahrscheinlich besser.
Exxtreme
2008-05-02, 15:03:56
Die Schwierigkeit hier ist die Daten auf den Grafikkarten synchron zu halten. Was passiert wenn man Daten aus einem Bildbereich braucht, welcher von der anderen Grafikkarte berechnet wurde? Sei es für Spiegelungen/whatever. Man kommt an dauernder Datenschauflerei nicht vorbei.
_DrillSarge]I[
2008-05-02, 19:49:30
Man kommt an dauernder Datenschauflerei nicht vorbei.
wozu hat man pciE (2.0) (€: oder sli-brücken)? kann sowas nicht direkt zwischen den karten passieren? das muss doch nicht alles über die cpu/ fsb (intel)/ chipsatz, wahtever. :confused:
I[;6475322']wozu hat man pciE (2.0) (€: oder sli-brücken)? kann sowas nicht direkt zwischen den karten passieren? das muss doch nicht alles über die cpu/ fsb (intel)/ chipsatz, wahtever. :confused:
Natürlich geht das theoretisch, und wenn die Verbindung zwischen den Chips/Karten annähernd so schnell wäre wie die Speicheranbindung gäbe es auch deutlich weniger Effizienzprobleme. Nur wäre eine solch breite Verbindung schlicht zu teuer und würde auch für Single-Chip die Kosten steigern.
Exxtreme
2008-05-02, 22:00:10
I[;6475322']wozu hat man pciE (2.0) (€: oder sli-brücken)? kann sowas nicht direkt zwischen den karten passieren? das muss doch nicht alles über die cpu/ fsb (intel)/ chipsatz, wahtever. :confused:
Ganz einfach. Die Verbindung müsste genauso schnell sein wie der Speicher selbst. Und bevor man so eine (sehr teure) Verbindung baut, packt man lieber einen fetteren Grafikchip und schnelleren Speicher drauf weil das mehr bringt und trotzdem billiger zu produzieren ist.
Eine Möglichkeit sehe ich aber: 2 Grafikchips und gemeinsamer Framebuffer. Da würde der Synchronisierungsaufwand entfallen und jeder Grafikchip hätte sofortigen Zugriff auf die berechneten Daten des anderen Grafikchips. Nur bräuchte man hier wiederum ein fetteres Speicherinterface.
Zum geteilten Framebuffer:
Da sind in Situationen, in denen SLI/CF sinnvoll ist, doch gar nicht so viel zu übertragen. Wenn jede Karte die Hälfte rendert braucht man je Richtung auch nur die Hälfte übertragen.
Bei 50 fps würden 1 GB/s (von möglichen 8 GB/s bei PCIe2.0 x16) für 40 MB Framebuffer reichen. Wie viel Byte speichert man mittlerweile pro Pixel?
Bei 100+ fps limitiert die Bandbreite natürlich, aber da braucht man auch nicht unbedingt SLI ;)
RavenTS
2008-05-04, 01:13:50
...
Eine Möglichkeit sehe ich aber: 2 Grafikchips und gemeinsamer Framebuffer. Da würde der Synchronisierungsaufwand entfallen und jeder Grafikchip hätte sofortigen Zugriff auf die berechneten Daten des anderen Grafikchips. Nur bräuchte man hier wiederum ein fetteres Speicherinterface.
ATi hatte doch schon ein 512er Interface und kommt jetzt auch recht gut mit nem 256er zurande...nur in zukünftigen Generationen würde das Interface wohl nicht mehr weiter gesteigert werden können oder?! Irgendwann gibt so ein begrenztes GraKaPCB wohl auch nimmer mehr Raum her...:confused:
PatkIllA
2008-05-04, 10:05:59
Das will aber auch alles synchronisiert werden, wenn zwei GPUs in den gleichen Bereich schreiben.
Die Latenzen steigen und man kann ja mittlerweile in mehrere Buffer rendern.
Mit dem Geometry Shadern kann man doch auch sogar Vertex Daten zurück in den Speicher schreiben oder?
Bei excessivem Render to Texture Einsatz müsste letztlich der gesamte Grafikspeicher geteilt sein.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.