-
Interessant
Autor: Neko-chan 16.07.08 - 12:46
Das darf man wohl dann so verstehen, das mein PC dann denkt es wäre ein und dieselbe Grafikkarte. Rein von der Logok her würde das bedeuten wenn ich zwei 512 MB Grakas darüber kopple, habe ich im Prinzip eine 1Gb Graka. Würde natürlich voraussetzen, dass dieser Treiber es auch korrekt und mit entsprechender geschwindikeit weiterleitet.
Auf jedenfall wird das Aufteilen der anfragen auf mehrer Grakas auf den Treiber verlegt.
Ich bin gespannt. -
Re: Interessant
Autor: Pandaber 16.07.08 - 12:54
Oder es ist so, wie bei den X2 Karten, bei denen dann alle Texturen doppelt vorhanden sind (in jeder Karte einmal) Ich könnte mir vorstellen, dass das die Sache enorm vereinfacht ;)
> Rein von der Logok her würde das bedeuten wenn ich
> zwei 512 MB Grakas darüber kopple, habe ich im
> Prinzip eine 1Gb Graka. Würde natürlich
> voraussetzen, dass dieser Treiber es auch korrekt
> und mit entsprechender geschwindikeit
> weiterleitet.
> Auf jedenfall wird das Aufteilen der anfragen auf
> mehrer Grakas auf den Treiber verlegt.
> Ich bin gespannt.
-
Re: Interessant
Autor: Neko-chan 16.07.08 - 12:58
ich stell mir das eher so vor, dass die aufteilung auf die GPUs dann besser und vielleicht auch einfacher wird. Auf beiden GPUs die selben Texturen zu haben würde eigentlich nur den Vorteil schnelleren Zugriffs bringen nicht aber eine erhöhung der Errechnungsgeschwindigkeit. Von daher denke ich nicht dass dies das Ziel von hydra ist.
-
Re: Interessant
Autor: __tom 16.07.08 - 13:00
> Auf beiden GPUs die selben
> Texturen zu haben würde eigentlich nur den Vorteil
> schnelleren Zugriffs bringen nicht aber eine
> erhöhung der Errechnungsgeschwindigkeit.
doch, eine gpu kann den oberen, eine den unteren bildschirmbereich berechnen. bzw kann man das verhältnis auch verschieben, die leistungsschwächere karte muss 1/3 rechnen, die stärkere karte 2/3
-
Re: Interessant
Autor: Neko-chan 16.07.08 - 13:02
__tom schrieb:
-------------------------------------------------------
> doch, eine gpu kann den oberen, eine den unteren
> bildschirmbereich berechnen. bzw kann man das
> verhältnis auch verschieben, die
> leistungsschwächere karte muss 1/3 rechnen, die
> stärkere karte 2/3
>
Bedeutet aber, dass nicht diesselbe texturen in beiden Chips vorahnden sind.
----------------------------------
Kopf -> Tisch -> Bumms -
Re: Interessant
Autor: dfsfds 16.07.08 - 13:13
Neko-chan schrieb:
-------------------------------------------------------
> __tom schrieb:
> --------------------------------------------------
> -----
> > doch, eine gpu kann den oberen, eine den
> unteren
> bildschirmbereich berechnen. bzw kann
> man das
> verhältnis auch verschieben, die
>
> leistungsschwächere karte muss 1/3 rechnen,
> die
> stärkere karte 2/3
>
> Bedeutet aber, dass nicht diesselbe texturen in
> beiden Chips vorahnden sind.
>
Doch, wenn der Spieler z.b. nach oben kuckt müssten die Daten ja wieder zur anderen GPU, das würde viel zu lange dauern.
-
Re: Interessant
Autor: Kai_ 16.07.08 - 13:15
Neko-chan schrieb:
-------------------------------------------------------
> __tom schrieb:
> --------------------------------------------------
> -----
> > doch, eine gpu kann den oberen, eine den
> unteren
> bildschirmbereich berechnen. bzw kann
> man das
> verhältnis auch verschieben, die
>
> leistungsschwächere karte muss 1/3 rechnen,
> die
> stärkere karte 2/3
>
> Bedeutet aber, dass nicht diesselbe texturen in
> beiden Chips vorahnden sind.
Doch das bedeutet es. Selbst wenn mal im oberen bereich andere Texturen benoetigt werden als im unteren, muss man die texturen trotzdem auf beiden graphikkarten halten, damit schnelle bewegungen von oben nach unten moeglich sind. texturen nachzuladen (aus dem ram) dauert naemlich immer noch recht lange. Mal davon abgesehen waere es hoechstens fuer die anwendung moeglich so etwas zu steuern, aber fuer die soll das ganze ja transparent sein.
>
> ----------------------------------
> Nicht wissen, aber Wissen
> vortäuschen, ist eine Untugend.
> Wissen, aber sich dem Unwissenden
> gegenüber ebenbürtig verhalten,
> ist Weisheit
>
> Wenn der Wind
> der Erneuerung weht,
> dann bauen die einen
> Menschen Mauern und
> die anderen Windmühlen.
-
Re: Interessant
Autor: Neko-chan 16.07.08 - 13:16
Meines wissens nach, würde es mehr bringen wenn man beiden GPUs veschiedene Texturen zu berechnen gibt und sich auch nicht auf den aktuellen Bildschirmausschnitt fixiert. Wenn man geschätze +20% des nächsten ausschnitts gleich mitschickt, würde keine wirklich bemerkbare Verzögerung auftreten.
Was mich aber wirklich interessiert ist, ob es irgendwelche belge gibt, das doppelt vorhanden texturen die Leistung effizient steigern.
Ich hätt in demfall ja zweimal dasselbe Bild berrechnet. -
Re: Interessant
Autor: Neko-chan 16.07.08 - 13:23
Persöhnlich würd ich behaupten dass die beste Leistung erzielt wird wenn ein GPU den aktuellen Frame berechnet und ausgiebt währen die andere GPU den kommenden Frame bearbeitet.
Aktuelle ist allerdings nicht vorgesehen, zwei verschieden Starke GPUs zusammen zu betreiben.
----------------------------------
Kopf -> Tisch -> Bumms -
Re: Interessant
Autor: Kai_ 16.07.08 - 13:28
Neko-chan schrieb:
-------------------------------------------------------
> Persöhnlich würd ich behaupten dass die beste
> Leistung erzielt wird wenn ein GPU den aktuellen
> Frame berechnet und ausgiebt währen die andere GPU
> den kommenden Frame bearbeitet.
>
> Aktuelle ist allerdings nicht vorgesehen, zwei
> verschieden Starke GPUs zusammen zu betreiben.
>
Ist auch eine Moeglichkeit. Dann benoetigt man aber erst recht auf beiden Graphikkarten die gleichen Texturen. Das funktioniert dann aber auch im besten Fall mit bis zu drei Graphikkarten (triple-buffering) und nicht mit mehr. -
Re: Interessant
Autor: DuNixBlick 16.07.08 - 13:30
Blah Blah.
Woher sollen den bitte die Karten wissen welche Texturen in ihrem Renderbereich im nächsten Frame verwendet werden?
Texture Prediction oder was?
Und erklär mir mal bitte wie ein Treiber erkennen soll was +20% des nächsten Ausschnitts sind...
Doppelt vorhandene Texturen = Texturen im Cache, doh! Ist ja wohl allemal schneller als die Texturen über die Bridge von einer Karte zu anderen zu schaufeln / ...
Neko-chan schrieb:
-------------------------------------------------------
> Meines wissens nach, würde es mehr bringen wenn
> man beiden GPUs veschiedene Texturen zu berechnen
> gibt und sich auch nicht auf den aktuellen
> Bildschirmausschnitt fixiert. Wenn man geschätze
> +20% des nächsten ausschnitts gleich mitschickt,
> würde keine wirklich bemerkbare Verzögerung
> auftreten.
> Was mich aber wirklich interessiert ist, ob es
> irgendwelche belge gibt, das doppelt vorhanden
> texturen die Leistung effizient steigern.
> Ich hätt in demfall ja zweimal dasselbe Bild
> berrechnet.
-
Re: Interessant
Autor: Neko-chan 16.07.08 - 13:31
ich brauche eigentlich diesselbe Texturen nur dort, wo sie sich auch überschneiden. Ist eigentlich wie mit einer Kulisse. Die wird auch erst geändert wenn sie nicht mehr in die Szene passt.
Vielleicht sollte man einfach mal darauf vertrauen, dass die Kerle wissen was sie tun. Ansonsten seh ich ohnehin reichlich schwarze Bildschirme. -
Re: Interessant
Autor: Hellseher 16.07.08 - 13:31
Kai_ schrieb:
-------------------------------------------------------
> Neko-chan schrieb:
> --------------------------------------------------
> -----
> > Persöhnlich würd ich behaupten dass die
> beste
> Leistung erzielt wird wenn ein GPU den
> aktuellen
> Frame berechnet und ausgiebt währen
> die andere GPU
> den kommenden Frame
> bearbeitet.
>
> Aktuelle ist allerdings
> nicht vorgesehen, zwei
> verschieden Starke
> GPUs zusammen zu betreiben.
>
> Ist auch eine Moeglichkeit. Dann benoetigt man
> aber erst recht auf beiden Graphikkarten die
> gleichen Texturen. Das funktioniert dann aber auch
> im besten Fall mit bis zu drei Graphikkarten
> (triple-buffering) und nicht mit mehr.
Den kommenden Frame? Woher weiss die Graka denn bitte, was als nächstes geschieht, bevor der User dies entscheidet?
-
Re: Interessant
Autor: Neko-chan 16.07.08 - 13:33
wahrscheinlichkeits prinzip und die Tatsache das Strom schneller als das Auge ist.
-
Re: Interessant
Autor: Neko-chan 16.07.08 - 13:37
das schöne an den heutigen rechnern ist, dass sie verdammt schnell sind und große Speicherkapazitäten haben. Mal daran gedacht, dass der nächste Frame gar nicht vom Spieler vorgegeben werden könnte?
Beispiel Egoshooter. Anstatt dass nur der Aktuelle ausschnitt berechnet wird. wird im Prinzip einmal die ganze Umgebun geladen welche ja statisch ist. Als nächstes werden mal die gegner und Prohjektile usw geladen. Das verhalten von gegner wird aber vom PC gesteuert und daher mit logoschem Algorythmos vorhersehbar. Im Prinzip ist dann der Nächste Frame die Bewegung einer Kugel oder eines Pixelgegners. Was ist daran nicht vorhersehbar?
Und einen schuss ganz plötzlich zu berrechnen ist wirklich nicht arg resspurcenfressend, da die animation schon geladen ist und nur noch eingespielt werden muss. -
Re: Interessant
Autor: Kai_ 16.07.08 - 13:44
-
> > Persöhnlich würd ich
> behaupten dass die
> beste
> Leistung
> erzielt wird wenn ein GPU den
> aktuellen
>
> Frame berechnet und ausgiebt währen
> die
> andere GPU
> den kommenden Frame
>
> bearbeitet.
>
> Aktuelle ist
> allerdings
> nicht vorgesehen, zwei
>
> verschieden Starke
> GPUs zusammen zu
> betreiben.
>
> Ist auch eine
> Moeglichkeit. Dann benoetigt man
> aber erst
> recht auf beiden Graphikkarten die
> gleichen
> Texturen. Das funktioniert dann aber auch
> im
> besten Fall mit bis zu drei Graphikkarten
>
> (triple-buffering) und nicht mit mehr.
>
> Den kommenden Frame? Woher weiss die Graka denn
> bitte, was als nächstes geschieht, bevor der User
> dies entscheidet?
ist natuerlich ein problem. aber bei tripple buffering sollte sich da was parallelisieren lassen.
-
Re: Interessant
Autor: ichse 16.07.08 - 13:49
Das geht nicht, auf keinen fall.
Szenario: Ein Spiegelnder Boden beispielsweise. Woher soll GraKa2 denn wissen, WAS GraKa1 im oberen Bereich darstellt? Anderes Beispiel bei dem es ganz schnell klar sein solte: Umgebungstexturen! Die Texturen müssen auf beiden Grafikkarten vorhanden sein, geht nicht anders. Aber nicht nur die Texturen, auch alle 3D-Objekte. -
Re: Interessant
Autor: Kai_ 16.07.08 - 13:50
Neko-chan schrieb:
-------------------------------------------------------
> ich brauche eigentlich diesselbe Texturen nur
> dort, wo sie sich auch überschneiden. Ist
> eigentlich wie mit einer Kulisse. Die wird auch
> erst geändert wenn sie nicht mehr in die Szene
> passt.
die wahrscheinlickeit, dass in zwei aufeinanderfolgenden bildern dieselbe kulisse verwendet wird ist allerdings doch meistens recht hoch ;) das ist so mit den texturen: die werden am anfang vom level einmal *alle* auf die graphikkarte geladen (oder halt nun auf die graphikkarten) und koennen dann effizient genutzt werden. neuere spiele wie crysis streamen zwar auch zwischendurch texturen nach, aber das aendert nichts am grundprinzip.
-
Re: Interessant
Autor: Neko-chan 16.07.08 - 13:53
Hat ich in ner anderen abzweigung auch erwähnt. Frame != Bildschirmausschnitt.
Man merkts bei manchen spielen wenn sie kurz ruckeln um neue Texturen zu laden. Man kann also sagen, ich nehm eine GPU für die Umgebung und die andere für Aktive Figuren. Wäre eine möglichkeit.
Allerdings seh ich es so, dass ein Frame eigentlich nur sich bewegende Objekte beinhaltet. -
Re: Interessant
Autor: Kai_ 16.07.08 - 14:01
Neko-chan schrieb:
-------------------------------------------------------
> Hat ich in ner anderen abzweigung auch erwähnt.
> Frame != Bildschirmausschnitt.
> Man merkts bei manchen spielen wenn sie kurz
> ruckeln um neue Texturen zu laden. Man kann also
> sagen, ich nehm eine GPU für die Umgebung und die
> andere für Aktive Figuren. Wäre eine möglichkeit.
das kann aber kein treiber wissen - und selbst wenn man irgendwie eine unterscheidung zwischen dynamischen und statischen objekten machen wuerde, kann das niemals linear skalieren, weil das zu sehr von der speziellen anwendung abhaengen wuerde. bei einem flugsimulator z.B. ist ja der mit abstand groeßte teil statisch.
>
> Allerdings seh ich es so, dass ein Frame
> eigentlich nur sich bewegende Objekte beinhaltet.
ein frame beinhaltet ein vollstaendig gerendertes bild.



