Mantle-API soll Videospeicher im Multi-GPU-System verdoppeln (Update)

[Thunderburne]

Ich schrieb ja auch nicht das AFR abgelöst wird durch SFR nur das man diesen Modi über Jahre hinweg besser zur Verfügung gestellt bekommt.

 

[fdsonne]

Aber warum? Mir erschließt sich der Aufwand eines alternativen Rendermodi nicht, wenn man den im Grunde besser skalierenden Modi mit "Techniken" so hinbiegt, dass die Nachteile eben keien Nachteile mehr sind...

Das SFR ein Skalierungsproblem hat, brauchen wir ja nicht hervorheben. Das wissen ja alle, die sich mit der Materie etwas beschäftigen. Selbst die Jungs von Civ. erwähnen das mehrfach.

Übrigens, sehr putzig ist, dass man bei den Tests zu Civ. mal wieder AMDs AFR CF vs. AMDs Mantle SFR CF stellt um "Vorteile" hervorzuheben... Warum nicht SLI von NV? Hat man analog zu Mantle vielleicht mal wieder einfach keine Optimierungen in das DX AFR Profil einfließen lassen um Mantle (und SFR) besser aussehen zu lassen?

 

[YB0b]

Außerdem sei die SFR-Implementation derzeit auf die Verwendung von zwei GPUs limitiert. Die deutlich komplexere Methodik ein SFR sinnvoll auf zwei GPUs zu verteilen, sei aber ein Teil der Mantle-Umsetzung und daher immer im Hinterkopf gewesen.

Ergibt keinen Sinn. Bitte neu formulieren. Im 2. Satz war wohl AFR gemeint.

 

[Thunderburne]

@fdsonne
Vielleicht geht es ja in Zukunft dahin das 2GPUs auf einen Sockel gehen ähnlich wie es bei CPUs mal der Fall war und derzeit auch noch zu finden ist CPU Die und GPU die nebeneinander auf einem Sockel tronnnen die auf einen Speicher zu greifen können.

 

[fdsonne]

@fdsonne
Vielleicht geht es ja in Zukunft dahin das 2GPUs auf einen Sockel gehen ähnlich wie es bei CPUs mal der Fall war und derzeit auch noch zu finden ist CPU Die und GPU die nebeneinander auf einem Sockel tronnnen die auf einen Speicher zu greifen können.

Das macht doch aber das "Problem" des Rendermodi nicht besser? Worauf willst du hinaus?

Und sicher, Möglichkeiten, mehr Compute Power auf gewissem Raum unterzubringen, als nativ "fette" DIEs zu produzieren gibts da schon... Das Problem was hintenraus bleibt ist einfach die Zusammenarbeit dieser GPUs.
AMD hatte mal seinerzeit auf irgendwelchen Folien (das war zur HD4870 Zeit) was von shared Memory bei Dual GPU Modellen gesprochen. Scheint aber nie was draus geworden zu sein. Oder es war ein Fake... Kann auch sein.
Denkbar wäre bspw. bei einem HBM Ansatz von AMD, den Speicher selbst als shared Memory beiden GPUs bereit zu stellen... Geht man aber so einen Schritt, dann sollte viel eher das ganze mindestens eine Ebene weiter vorn als in Software ansatzen. Denn AFR oder SFR ist halt einfach nur die "Software" oben drauf... Hier wäre bspw. vorstellbar, dass ein zentraler Memory Controller mit genügend Bumms von beiden GPUs angesprochen wird. Und ggf. sogar die Logik aufweist, dass Daten, die sich doppelt (also pro GPU jeweils 1x vorhanden wären) vom MC mit einer Art Dedublizierung eliminiert werden... Das müsste aber halt alles VOR der Software geschehen...
Nachteil bei sowas bleibt halt, dass das bestenfalls auf MGPU Karten anwendbar ist/wäre. Ein herkömmliches SLI/CF Gespann aus zwei einzelnen Karten hat immernoch das Anbindungsproblem. PCIe ist einfach "lahm"... Da müssten dann Alternativen her.


Bleibt halt immer so eine Aufwand/Nutzen Frage... Deutlich mehr Power als heute, da brauchen wir nicht drüber streiten, ist spielend drin. Nur überwiegen einfach die Nachteile. Entsprechend geht man andere Wege...
Und MGPU ist da nach wie vor eine Option, die im Grunde für den gut betuchten potentiellen Käufer von Interesse ist. Denn egal wierum man es dreht oder wendet, es bleiben Nachteile über. Und das ist nicht nur das reine Verhältnis zwischen FPS pro Euro bei nicht perfekter Skalierung

 

[DerGoldeneMesia]

Es sind 3 Dimensionale Transistoren möglich, also auch technologien die in diese Richtung gehen!

 

[dimi0815]

Das macht doch aber das "Problem" des Rendermodi nicht besser? Worauf willst du hinaus?

Weil du's inzwischen mehrfach geschrieben hast... Korrekturmodus an:

"das Problem des Rendermodi" gibt es nicht. Entweder "des Modus" (Einzahl) oder "der Modi" (Mehrzahl).

 

[Thunderburne]

@fdsonne
Wenn die Grafikkarten Hersteller das Problem haben 2GPUs alls eine anzusprechen wären sie aber vielleicht in der Lage über das SFR 2GPUs anzusprechen auf einem Sockel .
Wie es scheint wird es ja immer schwieriger kleinere Prozesse zu bringen so hätte man die möglichkeit die Leistung zu steigern jedoch Material einzusparen z.b doppelten RAM usw.auch wenn es dann vielleicht nur zu einem Leistungszuwachs von 50 -70 Prozent führen würde denke schon das dort auch noch etwas Leistung durch nicht optimale Programmierung brach liegt.
Da lag jetzt mein Gedanke .
Alles nur rein Hypothetisch.

 

[fdsonne]

@fdsonne
Wenn die Grafikkarten Hersteller das Problem haben 2GPUs alls eine anzusprechen wären sie aber vielleicht in der Lage über das SFR 2GPUs anzusprechen auf einem Sockel .

Das wird aber so nicht funktionieren... Hardware ist eben Hardware und Software ist/bleibt Software.
Wie du die Hardware organisierst, ist an der Stelle erstmal zweitrangig. Entscheidend ist eher, dass die Software entsprechend mit der Hardware kann. Zumal wir, rein was die Hardware angeht, ja kein Limit von der technischen Performance haben, sondern uns limitiert eher der Verbrauch/die Fertigung.
Ob du nun xxMrd Transistoren in einem Chip bringst, der dann sagen wir 300W verballert. Oder 2x xxMrd Transistoren in zwei Chips -> zusammen arbeitend, die dann 2x 150W verballern -> nebensächlich. Du deckelst oben an den 300W an. Entweder man geht den Weg und hebt diese Grenze an -> was ich faktisch nicht gut heißen möchte. Oder man sucht sich Alternativen.


MGPU hat im Grunde das gleiche Problem wie Multithreading auf CPUs. Du hast eine sequenzielle Abfolge von Einzelbildern. Jedes für sich, unabhängig von einander und was viel schlimmer ist, es ist NICHT vorhersagbar, da im Rahmen des Einflusses von Maus/Tastatureingaben schlicht und ergreifend das Ergebnis mit (unter Umständen) jedem Bild völlig anders ausfallen kann.

SFR ist im Grunde die denkbar schlechtere Möglichkeit, MGPU zu betreiben. Einfach weil es ein heiden Aufwand ist, ein und das selbe Bild, was auf der CPU vorbereitet wird (also wo Eingaben des Spielers, mögliche externe Ereignisse -> MP Spiele, allgemeine Berechnungen wie KI usw. mit einfließen) in mehrere Teile zu zerhackstückeln.
Sowas würde vielleicht funktionieren, wenn du sagen wir Pixelgenau deinen Code hättest um diesen dann auf verschiedene GPUs zu verteilen. Das ist aber lange nicht die Gegebenheit. Dort hast du eher Objektcode, heist also, verschiedene Objekte haben ihre Codezeilen und dort drin steht, wie sich das Objekt am Ende sichtbar auf dem Bild zeigt.
SFR hat dabei die Schwierigkeit, dass eben eine Aufteilung des Bildes auf mehrere GPUs notwendig ist. Was wiederum das Problem hervorruft, eben jenen Code, der die Objekte ausspuckt so zu manipulieren, dass am Ende möglichst zu gleichen Teilen Last auf den GPUs entsteht. -> dazu MUSS die Hardware/Software im Grunde aber schon vorher wissen, wie schnell die Berechnung erfolgt um entsprechend auch eine möglichst exakte Verteilung hinzubekommen. Und genau hier liegt der Knackpunkt an der Geschichte, was einer der Skalierungsprobleme ist.

Nach üblicher Verteilung wird entweder horizontal oder vertikal das Bild geteilt. Nun sehen Titel heute lange nicht mehr überall gleich aus. Wo man damals bspw. noch davon sprach, dass Berechnungen vom Himmel bspw. weniger aufwändig sind als die Spielwelt (also zu Anfangszeiten von MGPU), ist dies heute noch viel viel mehr ausgeprägt. Da können heute kleinste Objekte (anteilig) riesig viel Zeit für die Berechnung benötigen, wärend andere, größere Areale eben durch weniger komplexe Berechnungen weit schneller fertig sind. Das zieht also eine Logik nach sich, die entsprechend das Bild intelligent zerhackstückelt um am Ende möglichst gleiche Last zu erzeugen pro GPU.
Damals konnte man soweit ich das in Erinnerung hatte eine Art Linie über dem Bild einblenden lassen, wo man absehen konnte, wie die Verteilung pro GPU ausschaut. (im SFR Mode)

Eine andere Option wäre das Karomuster als Verteilung... Mit dem Vorteil, dass die Verteillogik nicht mehr so ausgefeilt sein müsste, da aufgrund der Masse der Teile es schon relativ warscheinlich ist, dass alle GPUs relativ gleich schnell fertig werden. Oder auch ein Karomuster in Verbindung mit einer Queue, die es abzuarbeiten gilt. Sprich keine 1:1 Zuordnung zwischen GPU A und "weißen Kacheln" und GPU B und "schwarzen Kacheln", sondern jede GPU, die fertig ist mit der Berechnung nimmt sich eine Kachel -> und am Ende wird das Bild zusammen gesetzt.
Das klappt in etwa schon. Könnte sogar halbwegs anständige MGPU Skalierung hervorrufen... Aber es gibt halt noch Post Prozessing Effekte. Die sich teils über das ganze Bild erstrecken. Und du hast bspw. auch Ereignisse, wo Randomwerte einfließen... Letzteres könnte bspw. Rauchentwicklung sein. Wo man via Randomwerten für immer neue Formen sorgt. Sowas geht aber nicht ohne weiteres mit SFR -> weil über die Bildgrenze hinweg unterschiedliche Ergebnise rauskommen würden, die nicht mehr zusammen passen. -> entsprechend entweder doppelte Berechnung (das gleiche pro GPU) oder es skaliert eben nicht...


Ich bin nach aktuellem Technikstand nach wie vor guter Dinge, dass wir auf absehbare Zeit immer schnellere GPUs erhalten werden. Und solange das so ist, sehe ich auch keinen Grund, sich massiv Gedanken über MGPU Problematiken machen zu müssen Vor allem auch, da man mit AFR eben eine Möglichkeit gefunden hat, das relativ entspannt mit guter Skalierung hinzubekommen. Und auch, da man sich mittlerweile durchaus bewusst ist, was AFR für Nachteile bringt und diese sogar aktiv angeht und versucht zu vermeiden/verringern.
Zumal MGPU NIEMALS fortschritte im Prozess/der Effizienz von GPUs usw. kompensieren kann. Denn spinn einfach mal den Faden weiter. Irgendwann mag der Punkt kommen, wo man am technischen Limit angelagt ist, sprich Verbrauch deckelt an, Fertigung geht nicht kleiner, Transistorcount deckelt an und Chipfläche ebenso. Vielleicht mag man mit einem MGPU Konstrukt diesen Umstand um vielleicht eine einzige Generation hinauszögern können... Nur was ist danach? Das bringt einem Hersteller vielleicht 1-2 Jahre, höchstens... Und er steht vor dem gleichen Problem.
Mit MGPU kannst du den Umstand bestenfalls versuchen zu verzögern. Deckelst du ans Limit von irgendwas in Sachen GPU oder auch CPU, dann MUSS dir was einfallen. Mit MGPU Lösungen behebst du schlicht das Problem nicht.

 

[CryptonNite]

LOL? AMD konnte mit Mantle beweisen, daß die API Einfluß auf die Performance hat? Das hat schon ein Hersteller mit einer anderen API bewiesen, bevor einige von euch hier überhaupt auf die Welt gekommen sind!
Ehre dem Erfinder, nicht dem Nachmacher!

(Aber der Rest vom Artikel ist brauchbar.)

 

[DragonTear]

LOL? AMD konnte mit Mantle beweisen, daß die API Einfluß auf die Performance hat? Das hat schon ein Hersteller mit einer anderen API bewiesen, bevor einige von euch hier überhaupt auf die Welt gekommen sind!
Ehre dem Erfinder, nicht dem Nachmacher!

(Aber der Rest vom Artikel ist brauchbar.)

Damit war wohl eher gemeint dass AMD gezeigt hat dass man mit einer neuen (low level) API teils deutlich mehr rausholen kann als bisher - eben mehr als DirectX.

 

[CryptonNite]

Und genau das konnten 3dfx (Glide) und S3 (MeTaL) auch schon lange vorher zeigen. Warum lief denn UT auf ner Voodoo am schnellsten und hübschesten? Weil es auf Glide renderte und damit den Voodoos auf dem Leib geschneidert war. Bei Mantle ist das heute nicht anders, quasi das Gleiche, nur von AMD.
Die Idee von Mantle ist zwar gut, wenn das aber irgendwann alle unterstützen, so wie sich das sogenannte "Fans" (also blinde Fanatiker) in Träumen wünschen, wird es sich ähnlich wie DirectX aufblähen.