News AMD: Dual-GPU-Fiji kommt mit Cooler-Master-Wakü

Nai schrieb:

@ Wadenbeisser und max_1234
Das galt eigentlich auch für SFR was ich da schrieb; habe das bewusst etwas abstrakter gehalten. Im Speziellen kann ich euch noch ein paar anschauliche Beispiele liefern. Annahme: Wir verwenden ein SFR-Verfahren, so so wie es auf der Folie gezeigt ist und wo der Bildschirm horizontal auf die beiden GPUs aufgeteilt wird.

Der Speicher für die (Zwischen-)Framebuffer lässt sich da zunächst leicht verteilen, da jede GPU nur in ihren Teil des Bildes zeichnet. Aber auch hier gibt es Probleme. Falls auf der linken seite mehr los ist als auf der rechten muss man die die Unterteilungslinie für die Lastbalancierung und gute Ausnutzung der Rechenleistung verschieben. Das führt wieder dazu, dass eine GPU einen größeren Teil des Framebuffers abspeichern muss als die andere GPU somit die Speicherverteilung verschlechtert wird.

Ok wie verhält es sich mit den Texturdaten und Vertexdaten der Objekte? Im einfachsten Fall mit nur einer Kamera kann man in der Tat die Objekte nach Bildschirmseite sortieren und nur auf der enstprechenden GPU abspeichern um Speicherplatz zu sparen. Speicherplatz wird nur verschwendet wenn das gleiche Objekt einmal in der linken und der rechten Seite gezeichnet werden soll oder in der mitte auf beiden Bildschirmseiten liegt. Allerdings treten hier auch zusätzliche Probleme auf:
-Bewegt sich die Kamera oder die Objekte schnell so müssen die Daten vieler Objekte zwischen den GPUs kopiert werden was wiederum Performance kosten kann.
-Moderne Engines zeichnen für diverse Spezialeffekte (Schattenwurf, Reflexionen) die Szene mehrmals mit Kameras, die andere Positionen und andere Blickwinkel besitzen, als die eigentliche Kamera. Verwendet man für jede dieser Kameras wieder ein SFR-Verfahren, so ist die Wahrscheinlichkeit hoch, dass innerhalb eines Frames nahezu jedes Objekt von jeder GPU durch irgendeine der vielen Kamera gezeichnet werden muss. Ergo muss nahezu jedes Objekt im Speicher von beiden GPUs vorrätig sein.

Zum Vergrößern anklicken....

Du vergißt entscheidene Teile.
Texturen die nur bei einem Teilbild benötigt werden müssen nicht in den Speicher der anderen Karte geladen werden, der Speicher- und Bandbreitenbedarf vom FSAA verteilt sich auch auf beide Karten und du sprachst von zuerst von der Addierung des Speichers und dann auf einmal von der Performance was letztendlich 2 verschiedene paar Schuhe sind.

Zudem müssten nicht zwangsläufig die Objekte von Karte zu Karte kopiert werden aber man könnte es um deren erneute Berechnung und Texturierung zu sparen, sie könnten aber auch einfach für jede Karte separat berechnet werden denn letztendlich wird auch nicht die komplette Welt gerendert sondern wohl eher der Bildaussschnitt den du siehst. Objekte zu rendern die nicht sichtbar sind sind schließlich nichts anderes als Ressourcenverschwendung.

Genau das meinte ich auch das du AFR nicht aus dem Kopf bekommst denn du gehst bei deiner Argumentation von Vollbildern aus, kommst aber nicht auf die Idee das die Teilbilder separat gerendert und dann wieder zusammengefügt werden könnten. Die von dir angesprochenen zusätzliche "Kamerapositionen" sind vermutlich die Testpositionen um zu checken ob Objekte sichtbar sind oder nicht damit sie eben nicht unnötig gerendert werden. Dafür reicht dann auch das einfache Grundmodell ohne Texturen, Shader Effekte und der gleichen.
Man muss auch nicht zwangsläufig die von dir angesprochene Lastverschiebung durchführen. Dann leidet an der Stelle eben die Skalierung etwas weil die eine Karte auf die andere warten muss.
Die größte Hürde dafür dürfte wohl die Präzision des Kamerablickwinkels der jeweiligen Karte, sowie die Helligkeit und der großflächigen Shader Effekte sein. Mit anderen Worten die Synchronisation der Teilbilder.

Wadenbeisser schrieb:

Du vergißt entscheidene Teile.
Texturen die nur bei einem Teilbild benötigt werden müssen nicht in den Speicher der anderen Karte geladen werden, der Speicher- und Bandbreitenbedarf vom FSAA verteilt sich auch auf beide Karten und du sprachst von zuerst von der Addierung des Speichers und dann auf einmal von der Performance was letztendlich 2 verschiedene paar Schuhe sind.

Zum Vergrößern anklicken....

Das hat er schon bedacht aber wenn man ein einfaches Beispiel nimmt, ein Bild mit den Texturen Baum, Haus, Himmel und Boden.
Dann müsste man es erst einmal so hinbekommen, dass eine GPU nur Baum und Himmel (z.B.) berechnet und die andere Haus und Boden (bei zwei Karten natürlich).
Dann dreht der Spieler sich auf einmal und Haus ist nicht mehr zu sehen aber viel mehr Bäume. Jetzt ist entweder die Lastverteilung bei den GPUs ungleichmäßig oder man gleicht die Leistung wieder an indem man auf der weniger belasteten GPU eben mehr Texturen hinterlegt als im optimalfall nötig.

Also entweder verliert man Leistung oder addiert den Speicher nur zum Teil. Dazu kommt der höhere Programmieraufwand. Daten in den VRAM laden sobald man weiß welche Teile berechnet und angezeigt werden müssen ist zu spät. Das muss bereits vorher geschehen.

Eher uninteressant wegen der alten Architektur aber wer brachiale Power will für 4k der wird um diese Karte schwer herumkommen

Hier liegt ein generelles Verständnisproblem vor, die entsprechenden Shader können problemlos zum verarbeiten unter mehreren GPUs aufgeteilt werden, im Grunde ist es egal auf welcher Seite was ist - dass alle Daten für beide Karten zur Verfügung stehen ist ebenso bereits der Fall.

So könnn anstehende Berechnungen problemlos auf beide Karten aufgeteilt werden.
DX12 Techniken zum "ergänzenden Speicher" sind etwas komplex, ich glaube hier geht es darum dass verschiedene Teilprozesse auf bestimmten Karten bleiben, d.h. GPU0 berechnet z.b. immer die schönen Wölklein, GPU1 das Gras, etc. - was in einer dedizierten Vergabe des damit in Verbindung stehenden VRAM-Verbrauchs resultiert.

Ich glaube Nai meint "what if" GPU0 jetzt auch noch die Sterne, Regenbögen, Asteroiden, etc. rendern soll, die alle mit dem Himmel selbst in Verbindung stehen. Eine Aufteilung hier würde die Prozesskommunikation dauerhaft auf beide Karten erweitern, wodurch eine intransparente Abhängigkeitskette entstehen kann.

mfg,
Max

Könnte die Karte für VR werden. Bin mir jetzt beim Speicher nicht sicher, aber wenn eine GPU pro Auge rendert sollte das wunderbar passen.

http://www.pcgameshardware.de/Virtual-Reality-Hardware-258542/News/LiquidVR-AMD-1152459/

Könnte sein dass AMD hier mit dem Marketing ansetzt. FÜr normales Gaming denke ich werden Dual GPUs auch nach wie vor nicht sonderlich geeignet sein.

Ich glaube ihr verwechselt etwas zum Teil. Es gibt bei Multi-GPU SFR- und Compositing-Techniken.

SFR: Das Verfahren teilt das zu zeichnende Bild zum Beispiel horizontal in zwei Teilbilder auf. Jede GPU bekommt ein Teilbild und zeichnet diejenigen Objekte, die sich in ihrem Teilbild befinden. Anschließend werden die beiden Bilder wieder an ihrer horizontalen Unterteilungslinie zusammengefügt.

Compositing: Das Verfahren teilt die zu zeichnenden Objekte auf die GPUs auf. Jede GPU zeichnet nur einen Teil der Objekte, zum Beispiel bei einem RTS zeichnet GPU0 die Panzer und GPU1 die Flugzeuge. Dadurch entstehen wiederum zwei unterschiedliche Versionen bzw Zwischenergebnisse des Bildes - ein Zwischenergebnis auf dem nur die Flugzeuge zu sehen sind und ein Zwischenergebnis auf dem nur die Panzer zu sehen sind. Abschließend werden die beiden Zwischenergebnisbilder zum Endergebnis zusammengesetzt bzw reduziert, indem das Compositing-Verfahren für jeden Pixel mit Hilfe der Tiefenbuffers immer den vordersten Farbwert der Zwischenergebnisbilder bestimmt. Beispielhaft kann man den Compositing im folgenden Link auf Seite 37 bis 39 nocheinmal veranschaulicht sehen:
http://www.nvidia.com/content/nvisi...zation/NVISION08-Does_Your_Software_Scale.pdf
Compositing hat auch seine eigenen Nachteile sogar wenn ich darauf jetzt nicht im Speziellen eingegangen bin.

@ Wadenbeisser

Texturen die nur bei einem Teilbild benötigt werden müssen nicht in den Speicher der anderen Karte geladen werden, der Speicher- und Bandbreitenbedarf vom FSAA verteilt sich auch auf beide Karten und du sprachst von zuerst von der Addierung des Speichers und dann auf einmal von der Performance was letztendlich 2 verschiedene paar Schuhe sind.

Zum Vergrößern anklicken....

Ersteres mit den Texturen habe ich doch geschrieben? Zum Letzteren: Es ist in dem Sinne nicht zusammenhangslos, weil man ja immer die Performance maximieren möchte. Die Speicherbalancierung ist hierfür nur eins von mehreren "Hilfsmitteln" - nicht das Ziel. Eine Performancemaximierung erfordert beispielhaft jedoch wegen der Lastbalancierung, dass Read-Only-Daten -sofern der Speicherplatz ausreicht- immer in beiden GPUs vorrätig gehalten werden, weshalb sich die Speicher auch nicht addieren.

Beim zweiten Absatz verstehe ich leider nicht, was genau du meinst.

Die von dir angesprochenen zusätzliche "Kamerapositionen" sind vermutlich die Testpositionen um zu checken ob Objekte sichtbar sind oder nicht damit sie eben nicht unnötig gerendert werden.

Zum Vergrößern anklicken....

Ich meinte hier nicht Culling sondern im speziellen Shadowmaps (siehe https://de.wikipedia.org/wiki/Shadow_Mapping) oder Reflexionen (siehe http://trederia.blogspot.de/2014/09/water-in-opengl-and-gles-20-part3.html ) . Oder anschaulicher formuliert: Wenn dank einem Spiegel auf der linken Bildschirmseite Objekte sieht die auf der rechten Bildschirmseite liegen, dann muss man sie auch in beiden GPUs vorrätig halten. Analoges gilt beim Schattenwurf, wenn ein linkes Objekt auf die rechte Seite einen Schatten wirft. Als moderneres Beispiel lässt sich auch VXGI heranziehen.

@Nai
Ich glaube du misverstehst mich nach wie vor da du dich immer wieder auf das letztendliche vollständige Bild beziehst.
Bei deinem Compositing Beispiel geht es letztendlich auch nur wieder um Objekte die im gesammten Bild sind, der Punkt den ich meine dreht sich aber um die Objekte die im jeweiligen Teilbild liegen und dann auch nur von der jeweiligen Grafikkarte berechnet und dagestellt werden müssen, gerade weil es Ressourcenverschwendung wäre Objekte vollständig zu berechnen die im jeweiligen Bild nicht sichtbar sind und was man hier spart belastet auch nicht den Grafikspeicher. Für Schatten usw. reicht es auch zu wissen das sie ganz einfach nur da sind.

Und nein, Performancemaximierung und Speicherbelegung sind 2 verschiedene Paar Schuhe da der Speicherbedarf erst dann wirklich für die Performance relevant wird wenn der lokale Grafikspeicher aus geht und ausgelagert werden muss. Muss man Objekte nicht im Grafikspeicher lagern weil sie für den Bildausschnitt nicht benötigt werden und statt dessen im Grafikspeicher der anderen Karte liegen erweitert sich dadurch der effektive Grafikspeicher für die Berechnung des Gesammtbilds. Alles was für die aktuelle Berechnung nicht benötigt wird ist einfach nur Puffer für folgende Berechnungen um mögliche Nachladezeiten zu sparen aber ob sie dann wirklich benötigt werden und damit relevant für die Performance sind ist wieder ein anderes Thema.

Der Punkt mit der Lastbalancierung ist zwar für die Maximierung der Skalierung nett aber nicht zwingend erforderlich weil in der festen Form das langsamste Teilbild ganz einfach die Framerate bestimmt.
Natürlich, in bestimmten Situationen könnten flexible Bildausschnitte die Skaliergung deutlich verbessern, macht aber auch die Programmierung um so komplizierter weil alle Teilbilder ständig variieren müssen. Du würdest sogar eine gewissen Bildvorhersage oder Vorausberechnung benötigen um die Bilder überhaupt so berechnen zu können, wobei sich vor allem letzteres wieder negativ auf die Skalierung auswirken dürfte weil wieder zusätzliche Ressourcen gebunden werden.

Letztendlich kann man die Handhabung auch recht einfach gestalten und einfach nur 2 getrennte Bilder berechnen die dann zusammengefügt werden.
Wenn 2 an 2 gleichen Rechnern zocken und nebeneinander her rennen und die Bildausschnitte sich lediglich ergänzen ist die Berechnung schließlich auch nicht unmöglich aber unterm Strich ist der Bildausschnitt und die Auflösung doppelt so groß, die Framerate bricht durch die Verdoppelung nicht zusätzlich ein.

Ich glaube du misverstehst mich nach wie vor da du dich immer wieder auf das letztendliche vollständige Bild beziehst.

Zum Vergrößern anklicken....

An welcher Stelle tat ich das ?

der Punkt den ich meine dreht sich aber um die Objekte die im jeweiligen Teilbild liegen und dann auch nur von der jeweiligen Grafikkarte berechnet und dagestellt werden müssen, gerade weil es Ressourcenverschwendung wäre Objekte vollständig zu berechnen die im jeweiligen Bild nicht sichtbar sind und was man hier spart belastet auch nicht den Grafikspeicher.

Zum Vergrößern anklicken....

Genau das habe ich doch im Post #73 geschrieben und die konzeptionellen Probleme dabei erläutert?

Und nein, Performancemaximierung und Speicherbelegung sind 2 verschiedene Paar Schuhe da der Speicherbedarf erst dann wirklich für die Performance relevant wird wenn der lokale Grafikspeicher aus geht und ausgelagert werden muss

Zum Vergrößern anklicken....

Genau das meinte ich ja: Im Falle, dass der lokale Speicher ausgeht, muss man für die Performancemaximierung die Speicherbelegung berücksichtigen. Demnach hängt es (für mich) doch zusammen, gerade wenn es wie hier um die Addierungsproblematik des Speichers geht.

Muss man Objekte nicht im Grafikspeicher lagern weil sie für den Bildausschnitt nicht benötigt werden und statt dessen im Grafikspeicher der anderen Karte liegen erweitert sich dadurch der effektive Grafikspeicher für die Berechnung des Gesammtbilds.

Zum Vergrößern anklicken....

Das habe ich auch im Post #73 inklusive Problematik geschrieben?

Der Punkt mit der Lastbalancierung ist zwar für die Maximierung der Skalierung nett aber nicht zwingend erforderlich weil in der festen Form das langsamste Teilbild ganz einfach die Framerate bestimmt.
Natürlich, in bestimmten Situationen könnten flexible Bildausschnitte die Skaliergung deutlich verbessern, macht aber auch die Programmierung um so komplizierter weil alle Teilbilder ständig variieren müssen.

Zum Vergrößern anklicken....

Primitive Lastbalancierung ist bei SFR eigentlich ganz einfach machbar, wenn man sie nicht proaktiv (wie lange werde ich für den nächsten Frame brauchen) sondern reaktiv designt (wie lange habe ich für den letzten Frame gebraucht), und die größe der Teilbilder dementsprechend anpasst. Da sich die Rechenlast zwischen zwei Frames in der Regel nicht groß verändert funktioniert das ganz gut. NVIDIA scheint es bei seinen Treiber-Hack(?)-SFR bislang immer so gemacht zu haben.

Wenn 2 an 2 gleichen Rechnern zocken und nebeneinander her rennen und die Bildausschnitte sich lediglich ergänzen ist die Berechnung schließlich auch nicht unmöglich aber unterm Strich ist der Bildausschnitt und die Auflösung doppelt so groß, die Framerate bricht durch die Verdoppelung nicht zusätzlich ein.

Zum Vergrößern anklicken....

Da speichert man aber auch die Szene zwei mal auf jeden Rechner ab, wodurch sich in diesem Fall der Speicher nicht addiert; passt die Szene nicht mehr in dem Speicher einer GPU so bricht die Performance ein. Zudem wird keine Kommunikation für Zwischenergebnisse ausgeführt, wodurch das Spiel oft die selben Sachen mehrmals berechnet.

Nichts für ungut aber wenn jemand anfängt Postings komplett zu zerlegen und aus dem Zusammenhang zu reißen ist in meinen Augen die Messe gelaufen.

Und mein, in Posting 73 bist du nicht darauf eingegangen weil du offensichtlich der Meinung bist das alle Objekte komplett gerendert und mit allen Effekten belegt werden, egal ob sie sichtbar sind oder nicht. Zudem habe ich den Eindruck das du meist dass das komplette Map unabhängig des Blickwinkels auf einmal gerendert wird, egal ob der Rest sichtbar ist oder nicht und genau an der Stelle ist eine weitere Diskussion an dieser Stelle für mich ganz einfach witzlos und damit beendet.

Nichts für ungut aber wenn jemand anfängt Postings komplett zu zerlegen und aus dem Zusammenhang zu reißen ist in meinen Augen die Messe gelaufen.

Zum Vergrößern anklicken....

Es fällt mir leider schwer zusammenhängende Texte zu schreiben, wenn du Abschnitte schreibst, wo du dich auf meine Posts beziehst und was ich so nicht geschrieben habe bzw "Lösungen darlegst", deren Problematik ich bereits erläutert habe. Genau das haben andere hier bereits auch schon angemerkt.

Und mein, in Posting 73 bist du nicht darauf eingegangen weil du offensichtlich der Meinung bist das alle Objekte komplett gerendert und mit allen Effekten belegt werden, egal ob sie sichtbar sind oder nicht.

Zum Vergrößern anklicken....

Ich hab doch im Post 73, wo es um die Speicheraufteilung bezüglich SFR ging, geschrieben:

Ok wie verhält es sich mit den Texturdaten und Vertexdaten der Objekte? Im einfachsten Fall mit nur einer Kamera kann man in der Tat die Objekte nach Bildschirmseite sortieren und nur auf der enstprechenden GPU abspeichern um Speicherplatz zu sparen. Speicherplatz wird nur verschwendet wenn das gleiche Objekt einmal in der linken und der rechten Seite gezeichnet werden soll oder in der mitte auf beiden Bildschirmseiten liegt.

Zum Vergrößern anklicken....

Oder alternativ Post 86, wo ich das mit der Zeichenaufteilung klarer formuliert habe:

SFR: Das Verfahren teilt das zu zeichnende Bild zum Beispiel horizontal in zwei Teilbilder auf. Jede GPU bekommt ein Teilbild und zeichnet diejenigen Objekte, die sich in ihrem Teilbild befinden. Anschließend werden die beiden Bilder wieder an ihrer horizontalen Unterteilungslinie zusammengefügt.

Zum Vergrößern anklicken....

Zudem habe ich den Eindruck das du meist dass das komplette Map unabhängig des Blickwinkels auf einmal gerendert wird, egal ob der Rest sichtbar ist oder nicht

Zum Vergrößern anklicken....

Ich weiß nicht einmal, was du mit Map und unabhängig des Blickwinkels hier meinst.

Gpu's ohne kühler ausliefern ist echt eine geniale Idee in meinen augen, klar wirds auch dafür nur eine Handvoll Leute geben und die schon angesprochenen Probleme von Leuten die jetzt nicht sooo tief in der materie sind.

Wäre auch für tests viel aussagekräftiger z.b.:
Standard kühler Morpheus, Karten werden echt nur noch in Anschlussvielfalt/Stromverbrauch/Übertaktbarkeit/die effiziens dabei und vor allen halt was kommt hinten raus wenn es wirklich nur noch um das Silizium geht.

Find ich nach wie vor unnötig.
Bei High-End/Enthusiasten-CPUs ist es verständlich, hier reichen teilweise die eigenen Boxed Kühler nicht mehr aus.
CPUs halten sich allerdings an Sockel, wohingegen GPUs i.d.R. mit jeder Generation auf ein neues PCB aufbauen, wodurch keine Kompatibilität hergestellt werden kann.

D.h. jede Version jedes PCBs jeder Generation braucht einen extra hierfür angefertigten Kühler. Aktuell wird dieses "Problem" sehr Effektiv durch Partnerkarten gelöst, wofür wir dankbar sein können

Es gibt ja auch keine Sapphire i4790K Tri-X ... der Vergleich mit CPUs hinkt

mfg,
Max

Tobermory ist übrigens keine schottische Insel, sondern ein Städtchen (der einzige Ort, den man als Städtchen bezeichnen) auf der schottischen Insel Mull (innere Hebriden). In dem Städtchen gibt es auch eine Single Malt Destillerie, die zwei Whiskys herstellt: den ungetorften Tobermory und den leicht getorften Ledaig... ;-)