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

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

DruckenE-Mail
Erstellt am: von

AMD Logo 2013Mit der Mantle-API konnte AMD beweisen, dass die Grafik-Schnittstelle einen großen Einfluss auf die Performance haben kann. Eine Reduzierung überschüssiger Befehle kann Leistungsschübe bis in den zweistelligen Prozentbereich bringen. Diese Vorteile macht sich auch Microsoft mit DirectX 12 zu Nutze. In Kürze also wird jeder Spieler vermutlich in den Genuss einer deutlich besseren Nutzung der zur Verfügung stehenden Ressourcen kommen.

Zwei AMD Radeon R9 290X
Zwei AMD Radeon R9 290X

Doch mit der Mantle-API will AMD noch weiter gehen und auch Probleme in Angriff nehmen, an die bisher noch niemand so recht gedacht hat. So mag ein Multi-GPU-System den zur Verfügung stehenden Speicher verdoppeln, davon ist in der Praxis aber meist wenig zu spüren, da Zuteilungen von Texturen und weiteren Daten jeder GPU gegenüber gemacht werden. Zwei AMD Radeon R9 290X mit jeweils 4.096 MB an Grafikspeicher müssen in Sachen Speicher also weiterhin wie eine Grafikkarte mit 4.096 MB Speicher behandelt werden. Grund hierfür ist die verwendete Technik zur Aufteilung der Render-Aufgaben namens Alternate Frame Rendering (AFR). Beim AFR rendern zwei oder mehr GPUs jeweils im Wechsel einen kompletten Frame, was auch erklärt, warum alle notwenigen Daten jeder GPU zur Verfügung stehen müssen und damit eventuell doppelt im Multi-GPU-System vorhanden sind. Hier unterscheiden sich CrossFire und SLI nicht. Weitere Nachteile von AFR sind das Entstehen von Mikrorucklern und einem Input-Lag.

Eine überarbeitete Version des dazugehörigen SDKs für Mantle wurde den Spieleentwicklern bereits zugänglich gemacht. Darin kann für ein CrossFire-System auch das Split Frame Rendering (SFR) verwendet werden, was nicht neu ist, nun aber von einigen Tricks profitierien soll. Zwei gleichstarke GPUs können sich im SFR einen ebenso in allen Bereichen ähnlich kompakte Renderszene entsprechend aufteilen. Bei zwei GPUs rendert die erste beispielsweise den oberen Bereich des Frames und die zweite GPU den unteren. Am Ende werden beide Teile zusammengesetzt und der fertige Frame ist im Idealfall in der Hälfte der Zeit berechnet worden. SFR reduziert ein eventuell vorhandenes Input-Lag deutlich. Auch Mikroruckler sind damit weniger ein Problem.

AMD GPU14 Tech Day: Mantle
AMD GPU14 Tech Day: Mantle

Beim aufgeteilten Rendering eines Frames kommt nun auch die Mantle-API ins Spiel, die jeder GPU und dem dazugehörigen Speicher nun nur noch die Daten zukommen lässt, die auch benötigt werden. Theoretisch kann damit der zur Verfügung stehende Grafikspeicher verdoppelt werden. Wird eine Textur aber beispielsweise von beiden GPUs benötigt, muss sie natürlich auch in den jeweils verwendeten Grafikspeicher dieser beiden GPUs geladen werden. Aber selbst wenn der Idealfall nicht eintritt, bedeutet diese Zuteilung der Daten eine wesentliche Vergrößerung des zur Verfügung stehenden Grafikspeichers.

Spieleprogrammierer müssen ihre Spiele aber auf diesen neuen Modus anpassen. Sowohl das Split Frame Rendering als auch das neue SDK müssen verwendet werden, damit die Methodik funktionieren kann. Derzeit ist nicht bekannt, welches Entwicklerstudio bereits an einer konkreten Umsetzung arbeitet. Erwähnt wird auch eine eventuelle Umsetzung der Technik für DirectX 12.

Update:

John Kloetzli, Grafik-Programmierer bei Firaxis Games und bei Civilization Beyond Earth für die Grafik-Engine verantwortlich, hat sich in einem Blogpost ausführlicher zum Thema Speichernutzung und Mantle-Support geäußert. An dieser Stelle wollen wir noch einmal auf einen Grafik-Vergleich verweisen, in dem auch erste Mantle-Benchmarks zu Civilization Beyond Earth enthalten sind. Laut Kloetzli eines der Hauptargumente für die Verwendung von Split Screen Rendering war demnach der Input-Lag. Dier geringere Framerate im Vergleich zu AFR habe man in Kauf genommen. 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.

Um Civilization Beyond Earth im SFR zu verwenden, muss das Spiel in seiner Mantle-Version gestartet und im "Graphics Initialization File" der Wert "Enable MGPU" auf 1 gesetzt werden.

Social Links

Ihre Bewertung

Ø Bewertungen: 4.5

Tags

Kommentare (71)

#62
customavatars/avatar117663_1.gif
Registriert seit: 04.08.2009

Bootsmann
Beiträge: 651
Zitat
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.
#63
customavatars/avatar48631_1.gif
Registriert seit: 03.10.2006
WOB
Admiral
Beiträge: 8676
@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.
#64
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31938
Zitat Thunderburne;23157949
@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 ;)
#65
customavatars/avatar64398_1.gif
Registriert seit: 21.05.2007
Wien
Kapitän zur See
Beiträge: 3408
Es sind 3 Dimensionale Transistoren möglich, also auch technologien die in diese Richtung gehen!
#66
Registriert seit: 05.08.2012

Hauptgefreiter
Beiträge: 242
Zitat fdsonne;23158073
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).
#67
customavatars/avatar48631_1.gif
Registriert seit: 03.10.2006
WOB
Admiral
Beiträge: 8676
@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.
#68
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31938
Zitat Thunderburne;23159823
@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.
#69
customavatars/avatar131975_1.gif
Registriert seit: 24.03.2010
Freistaat Sachsen
Leutnant zur See
Beiträge: 1030
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.)
#70
customavatars/avatar202850_1.gif
Registriert seit: 06.02.2014
Im sonnigen Süden
Admiral
Beiträge: 9448
Zitat CryptonNite;23163067
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.
#71
customavatars/avatar131975_1.gif
Registriert seit: 24.03.2010
Freistaat Sachsen
Leutnant zur See
Beiträge: 1030
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.
Um Kommentare schreiben zu können, musst Du eingeloggt sein!

Das könnte Sie auch interessieren:

Roundup: 5x GeForce GTX 1070 mit Custom-Design im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/5X-GTX1070/GTX1070_CUSTOM_ROUNDUP-TEASER

Nachdem wir bereits eine Reihe von Boardpartner-Karten der NVIDIA GeForce GTX 1080 ausführlich getestet haben, holen wir gleiches nun für das kleinere Schwestermodell nach, denn auch von der NVIDIA GeForce GTX 1070 gibt es viele Custom-Modelle mit höheren Taktraten, eigenen Kühlsystemen und... [mehr]

Drei Custom-Modelle der GeForce GTX 1060 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/3X-GTX1060/GTX1060_ROUNDUP_TEST-TEASER

Anders als bei der GeForce GTX 1080 und GeForce GTX 1070 trudelten wenige Stunden nach unserem Test zur Founders Edition der NVIDIA GeForce GTX 1060 schon die ersten Boardpartner-Karten mit teils höheren Taktraten, eigenem Kühlsystem und überarbeitetem Platinenlayout ein. Sie dürften... [mehr]

NVIDIA GeForce GTX 1080 mit Pascal-Architektur im XXL-Test

Logo von IMAGES/STORIES/LOGOS-2016/GEFORCE-GTX-1080

Heute ist es soweit: NVIDIA läutet mit der GeForce GTX 1080 und GTX 1070 auf Basis der Pascal-Architektur den diesjährigen Neustart bei den Grafikkarten ein. In Kürze wird wohl auch AMD seinen Beitrag zu diesem Thema leisten. Vor zehn Tagen lud NVIDIA die gesammelte Fachpresse nach Austin ein... [mehr]

Roundup: 5x GeForce GTX 1080 im Custom-Design im Test

Logo von IMAGES/STORIES/LOGOS-2016/GEFORCE-GTX-1080

Nachdem wir uns die Founders Edition der GeForce GTX 1080 und GeForce GTX 1070 bereits angeschaut haben, folgen nun fünf Retail-Modelle, die wir in aller Ausführlichkeit unter die Lupe nehmen wollen. Aus den vielen Boardpartnern und unterschiedlichen Modellen haben wir uns solche von ASUS, EVGA,... [mehr]

AMD Radeon RX 480 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/RADEON-RX480/RADEON-RX480-REFERENCE-LOGO

Es ist also soweit: AMD startet die großangelegte Zurückeroberung des Grafikkartenmarktes mit der Radeon RX 480, die als erste Grafikkarte der Polaris-Generation mit gleichnamiger Architektur erscheint und die wir uns genauer anschauen können. Dabei versucht sich AMD an einem anderen Ansatz im... [mehr]

PowerColor Radeon RX 480 Red Devil im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/POWERCOLOR-RX480/POWERCOLOR-RX480REDDEVIL-LOGO

Mit der Radeon RX 480 will AMD zurück zu alter Stärke und hat daher über Monate hinweg die PR-Trommel geschlagen. Letztendlich dabei herausgekommen ist eine sehr gute Karte für einen niedrigen Preis, die aber nicht in allen Bereichen zu überzeugen weiß. Wohl größtes Manko der Karte sollte... [mehr]