Archiv verlassen und diese Seite im Standarddesign anzeigen : Multi-GPU: Gibt es Grenzen?
Und wenn ja,ab wie vielen "Kernen"?
Zusatz:Wann ist Schluß?Sind auch Octacoregpus denkbar?
So lange es nur AFR gibt, ist alles über eine GPU unakzeptabel.
user77
2009-01-21, 16:02:26
Es wird sich zeigen, wie gut intels Larabee sein wird. der hat ja 32 (?) rechenkerne
Es wird sich zeigen, wie gut intels Larabee sein wird. der hat ja 32 (?) rechenkerne
Ach so. Dann ist ja alles klar :rolleyes:
Als ob diese Zahlen irgendwas zu sagen hätten. Lasst euch nicht von NVIDIA verarschen, die haben keine "240 Prozessoren" in G200 und ATI auch keine 800 in RV770.
Überhaupt, was hat das bitte mit dem Thema zu tun? :|
sputnik1969
2009-01-21, 16:04:33
Es wird sich zeigen, wie gut intels Larabee sein wird. der hat ja 32 (?) rechenkerne
Wenn du das SO rechnest hat meine 9600GT bereits 64 Kerne oO...
Die 32 "Kerne" des Larabee kannst du eher mit Shaderpipes bei anderen Herstellern vergleichen, nicht mit Multi-GPU-Lösungen
Spasstiger
2009-01-21, 16:04:58
Mit dem heutigen Standard-Renderverfahren AFR sind 4 GPUs schon das sinnvolle Limit. Jede zusätzliche GPU erhöht den Input-Lag um einen weiteren Frame. Und mit 4 GPUs merkt man den Lag bei unter 30 fps. Mit 4 GPUs kann man heute eigentlich nur ordentlich zocken, wenn man permanent 60 fps und mehr hat.
Wenn du das SO rechnest hat meine 9600GT bereits 64 Kerne oO...
Nein, sie hat 4. Aber irgendwas aussagen tut das trotzdem nicht.
Mit dem heutigen Standard-Renderverfahren AFR sind 4 GPUs schon das sinnvolle Limit.
Gibt es denn bessere Renderverfahren(zumindest in der Theorie)?
Und Ati soll ja an einer Lösung arbeiten(gemeinsamer Speicherzugriff????)
AnarchX
2009-01-21, 16:23:55
Mit dem heutigen Standard-Renderverfahren AFR sind 4 GPUs schon das sinnvolle Limit.
Wenn es sinnvolle MGPU-AA-Modi geben würde, dann könnte man das imo auch noch steigern, da man ja durch die gleichzeitige Berechnung der dann zusammengeführten Bilder das AFR-Problem teilweise bzw. ganz umgehen kann.
loewe
2009-01-21, 17:31:56
AFAIK ist mit PowerVRs SGX543 eine echte Multi-GPU Lösung möglich. Die Kerne arbeiten bis auf den gemeinsamen Zugriff auf die Displayliste unabhängig von einander.
Demirug
2009-01-21, 19:11:35
Der gemeinsame synchronisierte Speicherzugriff kann dabei aber ganz schnell der Flaschenhals werden. Genau genommen verhindert das ja auch das man bei CPU kerne unendlich skalieren kann.
loewe
2009-01-21, 20:08:06
Genau so sehe ich das auch!
Sie müssen aber auch nicht unbedingt eine gemeinsame Liste benutzen. Da die Kerne ähnlich wie beim Macro-Tilling die komplette Szene untereinander aufteilen, kann natürlich auch für jeden Core eine eigene Liste geführt werden. Nachteil dann, Objekte, die in mehreren Macro-Tilles vorhanden sind, müssen mehrfach gespeichert werden. Da die Listen aber nicht so groß sind, sollte das in der Regel bei solchen Systemen verschmerzbar sein.
Ich denke wir erfahren da bald mehr.
Das wäre ja ähnlich wie Supertiling bei ATI. Problem daran ist, dass man immer mehr gerenderte Daten wiederverwendet (z.B. braucht man für jedes Licht heute eine Shadowmap).
Das heißt jedes Mal wenn die Shadowmap dann verwendet wird muss die andere Hälfte davon zwischen den GPUs ausgetauscht werden. Das ist nicht nur ein Problem der Bandbreite, sondern vor allem der Latenz.
Das sind synchrone Operationen und das macht einem schnell die Parallelität komplett zunichte (Amdahl).
loewe
2009-01-21, 21:55:50
Das wäre ja ähnlich wie Supertiling bei ATI. Problem daran ist, dass man immer mehr gerenderte Daten wiederverwendet (z.B. braucht man für jedes Licht heute eine Shadowmap).
Das Wiederverwenden ist sicher notwendig, aber nur innerhalb der Tile!
Hier muss ich vorsichtig sein, ich weiß zwar grob was Shadowmaps sind und wie es funktioniert, aber nur grob! :)
Das heißt jedes Mal wenn die Shadowmap dann verwendet wird muss die andere Hälfte davon zwischen den GPUs ausgetauscht werden. Das ist nicht nur ein Problem der Bandbreite, sondern vor allem der Latenz.
Das sind synchrone Operationen und das macht einem schnell die Parallelität komplett zunichte (Amdahl).
Nein, die Shadowmap wird sicher nicht zwischen den GPUs getauscht, jede GPU macht alles für ihren Bildschirmbereich selbst, erzeugt sich auch ihr Shadowmap für ihre Pixel selbst und nur die für ihre Pixel.
Beide GPUs wissen überhaupt nichts von einander. Jede sammelt nur die Daten über den TA, die für ihren Bildschirmbereich notwendig sind, der Rest wird einfach ignoriert!
Das Wiederverwenden ist sicher notwendig, aber nur innerhalb der Tile!
Du verstehst es nicht. Das ergibt überhaupt keinen Sinn.
Nein, die Shadowmap wird sicher nicht zwischen den GPUs getauscht, jede GPU macht alles für ihren Bildschirmbereich selbst, erzeugt sich auch ihr Shadowmap für ihre Pixel selbst und nur die für ihre Pixel.
Das ist absoluter Blödsinn. Das machen sie mit an Sicherheit grenzender Wahrscheinlichkeit nicht, sonst hätten sie schon im Vorfeld bei den meisten Applikationen praktisch keine Skalierung mehr.
Bei einer Deferred Engine hätten würden sie damit alles außer dem Zusammenfügen des Bildes am Ende auf beiden GPUs berechnen müssen.
loewe
2009-01-21, 22:17:52
Du verstehst es nicht. Das ergibt überhaupt keinen Sinn..
Das kann schon sein, dann erklär es mir. :)
Das ist absoluter Blödsinn. Das machen sie mit an Sicherheit grenzender Wahrscheinlichkeit nicht, sonst hätten sie schon im Vorfeld bei den meisten Applikationen praktisch keine Skalierung mehr.
Bei einer Deferred Engine hätten würden sie damit alles außer dem Zusammenfügen des Bildes am Ende auf beiden GPUs berechnen müssen.
Genau das denke ich werden sie tun!
Sie machen sowohl alle Operationen mit den Dreiecken des zur GPU gehörenden Bildschirmbereiches als auch alle Pixelopertionen völlig unabhängig von einander.
Im anderen Fall müßten sie wie damals bei Naomi2 eien ELAN haben, der das tut und dann erst teilen. So funktioniert das hier nicht, denke ich.
Sie opfern erst einmal etwa je 10% Transistoren je GPU, womit sie dann bei theoretisch 10 GPUs 200% der Transitoren brauchen, die eine Single-Chip Lösung hätte.
Weiterhin wird natürlich auch ein gewisser Teil Mehrarbeit der GPU in Kauf genommen.
Das kann schon sein, dann erklär es mir. :)
Die Shadowmap ist ein Off-Screen-Rendertarget. Die wird nicht für jeden Pixel neu erzeugt.
Die wird zuerst gerendert und dann dafür verwendet beim Zeichnen des Lichts, um zu bestimmen welche Pixel im Schatten liegen und welche nicht.
Genau das denke ich werden sie tun!
Nein werden sie nicht. Sonst können sie es gleich lassen.
Bei einem Deferred Renderer hätten sie damit vielleicht 10% mehr Geschwindigkeit - wenn überhaupt. Dann doch lieber gleich AFR.
loewe
2009-01-21, 22:36:01
Die Shadowmap ist ein Off-Screen-Rendertarget. Die wird nicht für jeden Pixel neu erzeugt.
Die wird zuerst gerendert und dann dafür verwendet beim Zeichnen des Lichts, um zu bestimmen welche Pixel im Schatten liegen und welche nicht.
Ja, das ist mir klar!
Aber warum kann ich diese Shadowmap nicht nur z.B. für die linke Hälfte des Bildschirms auf der einen GPU und für die rechte Hälfte auf der anderen GPU erzeugen und verwenden?
Aber wie Du schon sagst, ich verstehe das nicht. :(
Nein werden sie nicht. Sonst können sie es gleich lassen.
Bei einem Deferred Shader hätten sie damit vielleicht 10% mehr Geschwindigkeit - wenn überhaupt. Dann doch lieber gleich AFR.
Denke ich nicht. :)
Aber warum kann ich diese Shadowmap nicht nur z.B. für die linke Hälfte des Bildschirms auf der einen GPU und für die rechte Hälfte auf der anderen GPU erzeugen und verwenden?
Die Shadowmap wird aus der "Sicht" des Lichts berechnet, da gibt es keine "linke" und "rechte" Bildschirmhälfte. Die GPU kann nicht wissen welche Teile der Shadowmap für welche Pixel letztendlich gebraucht werden. Sie weiß ja nicht mal dass sie überhaupt eine Shadowmap rendert.
Das ist eben das Problem mit freier Programmierbarkeit: Hardware und Treiber sind blöd wie Stroh, und die APIs erlauben keine zusätzlichen Informationen in dieser Richtung. Das ist aber auch gut so.
Denke ich nicht. :)
Was denkst du nicht?
loewe
2009-01-21, 23:04:10
Die Shadowmap wird aus der "Sicht" des Lichts berechnet, da gibt es keine "linke" und "rechte" Bildschirmhälfte. Die GPU kann nicht wissen welche Teile der Shadowmap für welche Pixel letztendlich gebraucht werden. Sie weiß ja nicht mal dass sie überhaupt eine Shadowmap rendert.
Ja wird von der Lichtquelle aus berechnet, ist klar.
Ich stelle mir die Shadowmap wie eine zusätzliche Textur vor, die über die Szene gelegt wird, um zu entscheiden ob ein Pixel im Schatten liegt oder nicht. Wenn der Bildschirm alos sagen wir mal 1600x1200 Pixel hat, muss diese Map eigentlich auch so groß sein!? Bei meiner zwei GPU Lösung muss aber jede GPU nur ihre jeweils 800x1200 Pixel große Shadowmap erzeugen, was sie bei PowerVR doch sicher on Tile machen?!
Das ist eben das Problem mit freier Programmierbarkeit: Hardware und Treiber sind blöd wie Stroh, und die APIs erlauben keine zusätzlichen Informationen in dieser Richtung. Das ist aber auch gut so.
Innerhalb der GPU kann ich soviel zusätzliche Information dazu geben wie ich will, ansonsten stimme ich Dir absolut zu.
Was denkst du nicht?
Ich denke nicht, dass sie nur wegen der maximal doppelten Arbeit der TAs so massiv an Effiziens verlieren. Die Pixelarbeit wird sicher nur für die innerhalb des Bereiches liegenden Pixel durchgeführt, für den die GPU zuständig ist.
Der TA hat natürlich mit seiner Liste und den notwendigen Vertex Opps den Kopf voll, aber AFAIK kann er das schaffen, für die Objekte, die in seinem Bereich sichtbar sind.
Ja wird von der Lichtquelle aus berechnet, ist klar.
Ich stelle mir die Shadowmap wie eine zusätzliche Textur vor, die über die Szene gelegt wird, um zu entscheiden ob ein Pixel im Schatten liegt oder nicht.
Sie wird nicht "über die Szene gelegt". Es wird für jeden Pixel die Shadowmap in den Viewspace transformiert und dann der Z-Wert des derzeitig zu rendernden Dreieckspixels mit dem der Shadowmap verglichen.
Wenn der Bildschirm alos sagen wir mal 1600x1200 Pixel hat, muss diese Map eigentlich auch so groß sein!?
Nein, das ist völlig unabhängig. Das kommt rein darauf an wie gut die Schatten nachher sein sollen. 512x512, 1024x1024, 2048x2048 oder sogar noch höher (für das Sonnenlicht) sind üblich.
Bei meiner zwei GPU Lösung muss aber jede GPU nur ihre jeweils 800x1200 Pixel große Shadowmap erzeugen, was sie bei PowerVR doch sicher on Tile machen?!
Du verstehst es immer noch nicht. Jede GPU braucht für ihre Bildschirmhälfte potentiell alle Pixel der Shadowmap.
Innerhalb der GPU kann ich soviel zusätzliche Information dazu geben wie ich will
Sie hat sie aber nicht, und der Treiber kann auch den Shader nicht "verstehen".
Ich denke nicht, dass sie nur wegen der maximal doppelten Arbeit der TAs
Was sind "TAs"? Es muss nicht nur ein Teil der Arbeit doppelt getan werden, sondern alles doppelt bis zu dem Punkt an dem wieder in den Framebuffer geschrieben wird. Das ist einfach völlig unrealistisch.
Überhaupt ist das ja nur ein Beispiel. Ich wollte es dir etwas einfacher machen.
Im Allgemeinen kann man nicht deterministisch bestimmen welche Positionen in einem Off-Screen-Rendertarget ein Shader später lesen wird. Deshalb ist es unmöglich dies vorher aufzuteilen.
Was man machen kann ist Copy-On-Read, d.h. erst kopieren von der anderen GPU, wenn diese Teile auch wirklich benötigt werden.
loewe
2009-01-22, 21:27:09
Danke!
Ich denke das mit der Shadowmap hab ich jetzt weitgehend verstanden. Die Shadowmap ist faktisch eine 2D Textur des Tiefenbuffers des Szene von der Lichtquelle aus gesehen. Sie gibt also die Abstände der Objekte der Szene zur Lichtquelle wider.
Nach Transformation in den Viewspace wird diese mit dem Tiefenbuffer der Szene aus Betrachtersicht verglichen, ist jetzt der Wert in der Shadowmap kleiner, liegt der Pixel dort also dichter an der Lichtquelle, liegt der Pixel in der Szene aus Betrachtersicht im Schatten des Objektes und wird dann entsprechend abgeschattet.
Du hast völlig recht, für die Erzeugung dieser Shadowmap braucht man natürlich immer die gesamte Szene. Was spricht aber dagegen die Erzeugung selbst zu teilen und sie dann zusammen zu setzen, oder auch die Shadowmap für Lichtquelle 1 von GPU 1 und für Lq2 von GPU 2 berechen zu lassen?
Auf jeden Fall werden sie Dinge wie die Shadowmap nicht zweimal berechnen, das wäre blöd!
Wie auch immer, es gibt Aufgaben, die nicht wirklich teilbar sind und somit nur von einer GPU bearbeitet werden können. Diese werden dann auch nur von einer getätigt werden, entweder die andere langweilt sich so lange oder die Aufgaben werden intelligent verteilt.
Das dieser Anteil aber so groß ist, dass wie Du oben sagtest die Effizienz der zweiten GPU auf 10% sinkt, glaube ich nicht.
Danke!
PS: Ich wollte aber diesen Thread hier nicht völlig vom Thema abbringen.
Was spricht aber dagegen die Erzeugung selbst zu teilen und sie dann zusammen zu setzen
Davon rede ich doch die ganze Zeit :|
Zusammensetzen = Kopieren der jeweils anderen Teile von der jeweils anderen GPU.
oder auch die Shadowmap für Lichtquelle 1 von GPU 1 und für Lq2 von GPU 2 berechen zu lassen?
Das geht eigentlich nur wenn die Applikation die Shadowmap nicht sofort danach verwendet, was sie praktisch immer tun wird, da sie den Speicherplatz für das nächste Licht wiederverwenden will.
Aber ich denke da könnte man noch am ehesten im Treiber ein Reordering machen, ähnlich der Out-Of-Order-Execution von CPU-Anweisungen. Dafür braucht man dann aber auch "Schattenregister", d.h. zusätzlicher VRAM. Evtl. kann man damit auch die Latenz der Umkopiererei verstecken und man spart sich den Vertex-Workload zweimal zu berechnen.
Das Ergebnis brauchen wieder beide GPUs, denn Operationen auf den Framebuffer kann man nicht umsortieren.
Das dieser Anteil aber so groß ist, dass wie Du oben sagtest die Effizienz der zweiten GPU auf 10% sinkt, glaube ich nicht.
Ich sagte, es wäre so schlecht von der Skalierung wenn man alle Offscreen-Teile doppelt berechnen würde anstatt sie zu teilen.
RavenTS
2009-01-24, 19:14:46
...
PS: Ich wollte aber diesen Thread hier nicht völlig vom Thema abbringen.
Für aktuelle Techniken war die Frage ja auch schon beantworter :wink:
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.