News Nvidia SLI: 3 oder 4 Karten geht bei Pascal nur für Benchmarks

Chismon schrieb:
Nicht weil es bei dem Video so steht, sondern weil es zum damaligen Zeitpunkt (2015, erste große DX12 Demo) Square Enix sicherlich noch nicht so weit gewesen wäre, das in DX12 umzusetzen und zum anderen (wichtigerem Argument), weil es wesentlich einfacher/kostengünstiger durch weniger Aufwand sein dürfte es per SLI anzusteuern als in DX12 alles per Rendering aufzuteilen. Letzteres ist doch erst kürzlich überhaupt (seit AotS) publik gemacht worden.

Die Frage ist aber was mehr Aufwand ist und ob nVidia bereit ist freiwillig AMD einen Teil vom Kuchen abzugeben (wenn Verbraucher Karten beider Hersteller kaufen/nutzen werden zwecks Dual-GPU Systemoptimierung unter DX12) ... nVidias proprietäre Produktpolitik (Gameworks, G-Sync, etc.) spricht wohl eher dagegen ;).

Deshalb habe ich ja auf die Hersteller und normale Entwicklungsprozesse hingewiesen. Als die Demo heraus kam, hat Microsoft diese Technik entwickelt. Da wird Nvidia und bestimmt auch Square Enix im Boot gewesen sein. Man entwickelt sowas nicht im Labor ohne die Hersteller. Vergessen wir nicht das es eine DX12 Demo war und keine Demo für eine neue Engine von Square Enix oder neue Grakas von Nvidia. Aber selbst wenn hier nur "klassisches" SLI verwendet wurde, hat man sich bestimmt schon Gedanken darüber gemacht wie man es in der Zukunft besser lösen könnte.

Es ändert nichts an den proprietären Standards wenn Nvidia das Multi-GPU Feld Microsoft überlässt. Früher hat man SLI auch nur auf ausgewählten Mainboards zugelassen, mit dem Wegfall dieser Einschränkung ist man auch nicht Pleite gegangen. Die Frage ist wie immer eine reine Kosten/Nutzen Entscheidung. Die Anzahl der Quad-SLI Nutzer halte ich für überschaubar. Dagegen wäre eine weite Verbreitung der neuen DX12 Technik für Nvidia sogar vom Vorteil weil man dann in der Zukunft die Möglichkeit bekäme eine aktuelle Grafikkarte zu kaufen und diese gemeinsam mit der bestehenden zu nutzen.

Wenn die Technik funktioniert, verkleinert man damit sogar den Markt für gebrauchte Grafikkarten.

Die wenigsten werden sich Grafikkarten mehrere Hersteller kaufen. Diese Gefahr sehe ich persönlich recht gering weil man dann auch noch die Software beider Hersteller installieren und pflegen müsste. Das ist heutzutage schon bei einem Hersteller oft schwierig. Zudem läuft G-Sync oder Freesync noch immer nur mit der Grafikkarte vom jeweiligen Hersteller, die zusätzlichen Grafikkarten können hier nur zuarbeiten.

Denken wir hier mal einen Schritt weiter.... Denken wir an Notebooks bei denen man eine Grafikkarte zustecken kann und trotzdem dem internen Bildschirm weiter benutzen kann.... Denken wir an Spielekonsolen die man beliebig mit zusätzlichen Grafikmodulen erweitern kann. Die Technik die mit DX12 möglich wurde hat potenzial und die Möglichkeiten diese Technik zu monetarisieren sind wesentlich höher als die Entwicklung von Quad-SLI nach dem bisherigen System.
 
Zuletzt bearbeitet:
xexex schrieb:
Deshalb habe ich ja auf die Hersteller und normale Entwicklungsprozesse hingewiesen. Als die Demo heraus kam, hat Microsoft diese Technik entwickelt. Da wird Nvidia und bestimmt auch Square Enix im Boot gewesen sein. Man entwickelt sowas nicht im Labor ohne die Hersteller. Vergessen wir nicht das es eine DX12 Demo war und keine Demo für eine neue Engine von Square Enix oder neue Grakas von Nvidia. Aber selbst wenn hier nur "klassisches" SLI verwendet wurde, hat man sich bestimmt schon Gedanken darüber gemacht wie man es in der Zukunft besser lösen könnte.

Möglich, aber ich kann mir nicht vorstellen, das Square Enix direkt alle DX12 Features ausgereizt hat mit dieser Demo, irgendwo ist man da sicherlich auch Kompromisse eingegangen und dazu hat sich aufgrund weniger Aufwand "klassisches" SLI sicherlich angeboten, zumal der Fokus dieser Grafik-Demo eben nicht auf DX12 Multi-GPU Einbindung lag, sondern darin die grafischen Vorteile von DX12 gegenüber DX11 hervor zu heben. Beim (deutlich später als dieses Demo erschienenem) Rise of the Tomb Raider von Square Enix wurde auch nur nachträglich DX12 hinein gepatched, wobei ich nicht weiss, ob direkte DX12 Multi-GPU Ansteuerung dort überhaupt möglich ist, ich glaube eher nicht (lasse mich aber gerne eines besseren belehren).

Dass die Technik von Microsoft entwickelt worden ist, bezweifle ich auch nicht, aber wie viel von DX12 wird denn selbst jetzt schon genutzt, m.E. nur Bruchteil und in dem Maße in dem das bei AotS geschehen ist das sicherlich vorbildlich, aber wohl eher noch eine Ausnahme bisher.

xexex schrieb:
Früher hat man SLI auch nur auf ausgewählten Mainboards zugelassen, mit dem Wegfall dieser Einschränkung ist man auch nicht Pleite gegangen. Die Frage ist wie immer eine reine Kosten/Nutzen Entscheidung. Die Anzahl der Quad-SLI Nutzer halte ich für überschaubar. Dagegen wäre eine weite Verbreitung der neuen DX12 Technik für Nvidia sogar vom Vorteil weil man dann in der Zukunft die Möglichkeit bekäme eine aktuelle Grafikkarte zu kaufen und diese gemeinsam mit der bestehenden zu nutzen.

Man hat Quad-SLI auch von Anfang an nur für einen kleinen Kundenkreis (ein paar Enthusiasten) schmackhaft gemacht, hätte aber die Möglichkeit gehabt, dieses viel mehr zu fördern, optimieren und auch für den gemeinen Kunden durch zu setzen, sich seitens nVidia aber irgendwann dagegen entschieden um jetzt endgültig die Ressourcen zu streichen ... leider nicht das erste Mal eine unausgegorene Strategie seitens nVidia.

xexex schrieb:
Wenn die Technik funktioniert, verkleinert man damit sogar den Markt für gebrauchte Grafikkarten.

Momentan halte ich die alten (und jetzigen) nVidia Karten nur für bedingt unter DX12 geeignet, weil deren DX12 Features (nicht vorhandene bzw. mangelhafte Unterstützung von wichtigem AsyncCompute und Shader Intrinsics) leider noch viel zu limitiert sind und man zu proprietär handelt und dem Kunden damit (und im Endeffekt sich selbst) keinen Gefallen tun wird.

xexex schrieb:
Die wenigsten werden sich Grafikkarten mehrere Hersteller kaufen. Diese Gefahr sehe ich persönlich recht gering weil man dann auch noch die Software beider Hersteller installieren und pflegen müsste. Zudem läuft G-Sync oder Freesync noch immer nur mit der Grafikkarte vom jeweiligen Hersteller, die zusätzlichen Grafikkarten können hier nur zuarbeiten.

Dahingehend haben sich aber einige hier im Forum enthusiastisch geäußert und angemerkt, sie würden sich mittel- bis langfristig dann wohl je eine GPU von beiden Herstellern ins Dual GPU System einbauen zwecks Optimierung. Die doppelte Treiber Installation dürfte nicht das Problem sein und wie lange nVidia noch den offenen A-/Free-Sync Standard ihren Kunden durch deutlichen G-Sync Aufpreis vorenthalten wird können, bleibt abzuwarten. Außerdem hat der Großteil aller Spieler immer noch keinen Sync Monitor (mich eingeschlossen) zumal es kein "Must-Have" darstellt (insbesondere außerhalb schnell bewegter, frametime-lastiger FPS, Autorennspiele, u.ä.) und für viele Leute sind andere (Qualitäts-)Parameter beim Monitorkauf weitaus wichtiger (die mit Ihrem PC auch noch etwas anderes machen als nur zu spielen).

xexex schrieb:
Denken wir hier mal einen Schritt weiter.... Denken wir an Notebooks bei denen man eine Grafikkarte zustecken kann und trotzdem dem internen Bildschirm weiter benutzen kann.... Denken wir an Spielekonsolen die man beliebig mit zusätzlichen Grafikmodulen erweitern kann. Die Technik die mit DX12 möglich wurde hat potenzial und die Möglichkeiten diese Technik zu monetarisieren sind wesentlich höher als die Entwicklung von Quad-SLI nach dem bisherigen System.

Wieso sollte dieses jetzt passieren, wenn man das auch schon mit "klassischem" SLI oder CF hätte längst möglich machen bzw. durchsetzen können? Ich wüsste nicht wieso nVidia jetzt auf einmal die Spieleentwickler dazu anhalten würde bzw. die Entwickler freiwillig Mehrarbeit dort hinein stecken würden, wenn der Großteil keine Dual GPU Systeme fährt? Das könnte sich zwar irgendwann mit VR ändern, aber der Dual-SLI Support wird ja inkonsequenter Weise anscheinend von nVidia beibehalten, welches dann in VR Works zum Einsatz kommen könnte.

Letzteres würde auch dazu führen, dass man dann eine teilweise Abwanderung bzw. Gewinneinbußen nicht zu befürchten hätte durch Leute die wegen DX12 Multi-GPU Ansteuerung je eine nVidia und eine AMD GPU im System haben möchten (als deutlicher Marktführer ist das wohl kaum im eigenen Interesse und man wird versuchen den Einfluß bei den Entwicklern zu nutzen bzw. DX12 Multi-GPU Nutzung wie bei AotS geschehen idealerweise zu verhindern, zumal man trotz neuer Pascal Chips unter DX12 insgesamt immer noch ganz klar schwächer dasteht als bei älteren AMD Chips).
 
Zuletzt bearbeitet:
Dual GPU oder SLI-/CF-Lösungen sind sicherlich die Zukunft - unter Berücksichtigung von DX12 und VR - und könnten irgendwann Single-GPU Lösungen komplett ersetzen
Jo, ne ist klar. Da kann ja AMD jetzt zum Quad CF Marktführer aufsteigen und die Lücke schließen und NV endlich zeigen wie der Hase läuft auf dem Gebiet.

Um was wetten wir wenn der Entwickler unter DX 12 in der Verantwortung steht alles perfekt zu optimieren um SLI/CF anstatt die Hersteller der Karten, das alles noch viel schlimmer wird. Ich wette mit euch das es eine einzige Katastrophe wird, in fast jedem Game in dem ein Entwickler sich um SLI und CF Support zu kümmern hat. Für eine solche Nische hat fast kein Entwickler auch nur einen Cent übrig. Und das zu recht! Die sollen auf keinen Fall ihr knappes Budget(Zeit und Geld) in so eine Nische stecken die nur 0,0x%(weil absoluter Schrott Fakt) nutzen und sich gefälligst um das Spiel kümmern. Das hat garantiert genug Bugs und fehlenden Kontent der ausgebessert gehört. Aber auf keinen Fall SLI!

Das würde NV und AMD so passen, den CF und SLI Support auf die Entwickler abzuwälzen. Die reiben sich schon die Hände Stichwort: Gewinnmaximierung. NV macht gleich mal den Anfang und streicht Tri und Quad SLI Support und wälzt es komplett auf die Entwickler ab. Nicht mit mir! Da gibts einen ordentlichen Shitstorm, sollte es ein Entwickler auch nur wagen an SLI rum zu pfuschen, wenn das eigentliche Spiel noch in Trümmern liegt. Ich zahle garantiert nicht für SLI. Dann gibts eben kein Geld von mir, so einfach geht das. Hauptzielgruppe verlieren weil man unnötig Ressourcen in die SLI Nische steckt, mal schaun ob die Taktik dann auf geht für den Entwickler.
 
Zuletzt bearbeitet:
Pict schrieb:
Bitte ,erklärt mir mal warum Nvidia heute noch 3 oder 4 Way SLI weiterentwickeln und unterstützen sollte. Welche Spiele profitieren bitte in solch einem Umfang von 3/4 Way SLI das sich der Arbeitsaufwand von Nvidia lohnt ?
Euch ist klar das es nicht um 2 way SLI geht oder ? D.h. ihr wart alle mit einem 3 oder 4 Way SLI unterwegs?

darum geht es nicht. wenn ich benchmakrs anbiete bzw. damit herumpose, dann muß das gezeigte auch ofiziell unterstützt werden. alles andere ist ja sowas von daneben. ich habe früher nur nvidia gekauft, aber die zeiten sind vorbei!!
 
Kasmopaya schrieb:
Jo, ne ist klar. Da kann ja AMD jetzt zum Quad CF Marktführer aufsteigen und die Lücke schließen und NV endlich zeigen wie der Hase läuft auf dem Gebiet.

Nur fehlt es AMD dazu leider an Finanzen und Einfluss im Gegensatz zu nVidia und außerdem wäre das kontra-produktiv, zumal AMD in gewisser Weise mit Mantle die Vorarbeit für den Multi-GPU Support in DX12 geleistet hat und in DX12 immer noch deutlich besser dasteht und hoffen kann beim Marktführer Anteile abzugreifen (wenn Leute "Mixed Systems" mit Karten beider Hersteller betreiben) ;). Ich denke bei AMD wird sich nichts großartiges ändern (wer Quad-CF-Verbund weiterhin will, wird das auch machen können), aber wir werden sehen.

Kasmopaya schrieb:
Um was wetten wir wenn der Entwickler unter DX 12 in der Verantwortung steht alles perfekt zu optimieren um SLI/CF anstatt die Hersteller der Karten, das alles noch viel schlimmer wird. Ich wette mit euch das es eine einzige Katastrophe wird, in fast jedem Game in dem ein Entwickler sich um SLI und CF Support zu kümmern hat. Die sollen auf keinen Fall ihr knappes Budget in so eine Nische stecken die nur 0,0x%(weil absoluter Schrott Fakt) nutzen und sich gefälligst um das Spiel kümmern. Das hat garantiert genug Bugs und fehlenden Kontent der ausgebessert gehört. Aber auf keinen Fall SLI!

Deshalb schrieb ich ja auch, dass die AotS Entwickler eine rühmliche Ausnahme gewesen sein dürften dort Ressourcen hinein gesteckt zu haben und wenn das Ganze ordentlich passiert, finde ich das auch nicht kritikwürdig. Mir käme beim Gedanken an Remedy (bestes Beispiel ist das verhunzte Quantum Break) oder irgendwelchen Ubisoft und WB Entwicklern da auch schon das Grausen, denn die bekommen z.T. Ihre Spiele schon jetzt nicht mehr gebacken/vernünftig programmiert.

Mit anständigem PC VR für den Massenmarkt (hoffentlich möglich in der 2., mit Sicherheit aber der 3. Generation) wird im Falle eines Booms aber ein Umdenken statt finden müssen und da gibt es dann die Wahl zwischen Dual GPU Support per Multi-GPU in DX12 oder den klassischen Dual-SLI und -CF Varianten ... 'mal sehen was daraus wird (es ist ja noch ein Weilchen hin).
 
Als jahrelanger Nutzer von 3 Way SLi find ich diesen Schritt sehr schade, 3-Way SLi war immer sehr intressant.
Hatte 3 Way SLi mit folgenden Grafikkarten über Jahre hinweg:

3x EVGA 8800 Ultra SC (welches ich noch habe als Errinnerung)
3x PNY GTX 480
3x EVGA GTX Titan SC Sig. (aktiv in Benutzung)

Hatte immer sehr viel Freude mit vielen Tools den Treiber so umzubauen bis es mit dem jeweiligen Spiel einwandfrei lief. Auch von der Hardware her wars immer sehr intressant das ganze Stabil und ohne Überhitzung zum laufen zu bringen. Mit dem Schritt ist die Nutzung sehr eingeschränkt und die Anschaffung ist es nicht mehr Wert.

Grüße XFC
 
Zuletzt bearbeitet: (Rechtschreibung)
GHad schrieb:
Seltsam, gerade mit DX12 lohnen sich doch 3-4 Karten erst richtig!

Oder wird für DX12 AFR keine SLI Bridge benötigt?
Funktioniert ja auch. nVidia hat nichts anderes gesagt, als das sie treiberseitig nicht mehr für 3 oder mehr Karten optimieren sondern das dies zukünfig von den Entwicklern der Spiele über DX12 bzw Vulcan gemacht werden soll, damit es auch effizient umgesetzt werden kann. Es geht hier lediglich um die Standard Allround Profile die nVidia automatisch für Spiele mitliefert. Unter DX12 sollten die eh nicht mehr nötig bzw sinnvoll sein.

Pict schrieb:
Der Mehraufwand um 4 way sli zu unterstützen in relation zum Nutzen steht im totalen Widerspruch zur Vernunft.
Das sehe selbst ich als Enthusiast so. Die werden genau hingeschaut haben wie hoch die Kosten und wie hoch der Nutzen.

Milchwagen schrieb:
Der Mehraufwand um einen Bugatti Veyron/Chiron schneller als alles andere zu machen steht auch außer Frage. Trotzdem gibt es Leute die für diese paar Prozente Geld ausgeben um das schnellstmögliche System zu haben.

Ja, aber Deine Sportwägen brauchen spezielle Straßen und Rennstrecken um ihre maximale Performance zu bringen. Ansonsten ist es nur Bling-Bling wenn man damit zum Bäcker fährt. Und für die Rennstrecke gibt es nach wie vor Support, wichtige Benchmarks sind nämlich davon ausgenommen. Aber für normale Spiele sehe ich da auch keinen Sinn für den Aufwand, denn die Leistung bekommt man eh nicht vernünftig umgesetzt. Die sind sozusagen normale Straßen für normale Autos. Incl. Schlaglöchern und allem. Da macht der Sportwagen keinen Sinn.

Je mehr Karten ich habe, desto höher ist die Fehlerwahrscheinlichekit und desto genauer muss ich auf die einzelnen Gegebenheiten einer Engine/eines Spiels optimieren. Da kann ich gut verstehen, daß nVidia das nicht für einen winzigen Teil der User machen will, denn ein SLI-Profil ist nicht einfach Copy&Paste, das muss ausführlich getestet werden und diese Test werden eben aufwändiger mit steigender Anzahl der Karten.

Chismon schrieb:
Dual GPU oder SLI-/CF-Lösungen sind sicherlich die Zukunft - unter Berücksichtigung von DX12 und VR - und könnten irgendwann Single-GPU Lösungen komplett ersetzen, ähnlich wie das bei den CPUs schon geschehen ist. Da scheint AMD weitaus visionärer zu denken (was man auch an der Polaris 10 Präsentation mit Dual-CF-Verbund (RX 480) gesehen hat) und weitsichtiger zu planen als nVidia für die sich scheinbar alles um kurzfristige Gewinnoptimierung dreht.

Moment, bei den CPUs arbeiten wir immer noch mehrheitlich mit einem Sockel. SLI bedeutet für mich mehrere Sockel zu haben. Und genau das sehe ich für die Zukunft im Grafikkartenbereich eben nicht, ich halte es für äußerst unwahrscheinlich, daß sich eine Mehrheit künftig mehrere Grafikkarten in den Rechner stecken werden, das ist immer noch aufwändiger und fehleranfälliger als alles auf einer Karte unterzubringen und das wird sich auch nicht ändern, weil mehr Komponenten immer die Fehlerwahrscheinlichkeit erhöhen.
Immer mehr Leute in meinem Bekanntenkreis setzen auf Mini-PCs, die hätten gar keinen Platz für 2 Karten. Und zwei Karten suggerieren auftomatisch, daß eine einzelne scheinbar nicht schnell genug ist, weswegen ich zwei brauche. Das ist psychologisch ungünstig für die breite Masse. Selbst bei mir hat der kürzlich vorgestellte CF-Verbund von AMD genau das ausgelöst, mein erster Gedanke war "Aha, zu schwach um mitzuhalten, daher nehmen wir zwei ?", ich hielt das nicht für schlau. Und einer meiner Kollegen mit seinem ITX Gaming PC sagte gleich: "Schade, zwei passen bei mir nicht rein, ich brauche eine schnelle Einzelkarte".

Wenn geht meiner Meinung nach der Trend eher dahin, mehr Kerne auf einer Karte unterzubringen oder unterschiedliche Recheneinheiten für Grafikbeleunigung zu nutzen. Und das hat mit SLI eben nichts zu tun, denn SLI ist die Monokultur von nVidia.
Und die SLI-Profile brauchst Du eh nur noch bis DX11. Selbst wenn sich der Trend den Du Dir vorstellst durchsetzt, dann spielt das eine Rolle für DX12 aufwärst und dort müssen jetzt die Entwickler sich die Mühe machen (was auch meiner Meinung nach mehr Sinn macht). Dann sind nämnlich Mischbestückungen zuverlässig möglich und das gibt einem wirklich mehr Flexibilität, ohne sich an einen Hersteller binden zu müssen. Ich sehe in nVidias Schritt daher überhaupt keine Probleme.

tm0975 schrieb:
darum geht es nicht. wenn ich benchmakrs anbiete bzw. damit herumpose, dann muß das gezeigte auch ofiziell unterstützt werden. alles andere ist ja sowas von daneben. ich habe früher nur nvidia gekauft, aber die zeiten sind vorbei!!
Wird es ja auch. In den herumgezeigten Benchmarks wird es nach wie vor unterstützt. Aber niemand hat gesagt, daß Du das auf jede beliebige Anwendung übertragen darfst.
 
Zuletzt bearbeitet:
In der Realität sind es sicherlich nicht sehr viele hier, welches sich ein GTX 1070 oder sogar ein GTX 1080 holen, unter denen sind es nochmals weniger, welches sich ein SLI Verbund daraus machen (Mich inkl.), bei 3- oder 4-Way SLI sind wir sicherlich schon im Promille bereich der CB Usern.
Also sollte dies wirklich nicht stören. Aber wie auch immer, frage ich mich "warum" dies so eingeschränkt wurde?
 
Aber wie auch immer, frage ich mich "warum" dies so eingeschränkt wurde?
Gewinnmaximierung. Die Spiele Entwickler sollen Geld und Zeit löhnen für den Support. NV macht nix mehr und lacht sich wie üblich ins Fäustchen.

Stichwort: Founders Edition und 970 3,5GB und allgemein Vram Krüppel für teuer Geld.
 
@ MADman_One
Moment, bei den CPUs arbeiten wir immer noch mehrheitlich mit einem Sockel.
Von der Programmierbarkeit würde ich multi GPU am ehesten mit mehreren (CPU-)Rechnern vergleichen, die über ein Netzwerk miteinander verbunden sind. Und da fällt mir so spontan keine Software im Privatbereich ein, die solche verteilten Berechnungen unterstützt, unter anderem weil es zu kompliziert ist das zu programmieren.

@ Chismon
Quelle für die mangelhafte Unterstützung von Intrinsics bei NVIDIA?
 
Zuletzt bearbeitet:
Nai schrieb:
@ MADman_One
Von der Programmierbarkeit würde ich multi GPU am ehesten mit mehreren (CPU-)Rechnern vergleichen, die über ein Netzwerk miteinander verbunden sind. Und da fällt mir so spontan keine Software im Privatbereich ein, die solche verteilten Berechnungen unterstützt, unter anderem weil es zu kompliziert ist das zu programmieren.

Von der Programmierbarkeit entspricht Multi-GPU aber eher Multi-CPU.

That said, developers do have a few options for implementing multiple GPUs under DX12. Implicit Multi Adapter (IMA) is the easiest, and is essentially like a DX12 version of Crossfire or SLI, with the driver doing most of the work to distribute tasks between GPUs (a feature not part of the Ashes benchmark). Then there's EMA, which has two modes: linked or unlinked mode. Linked mode requires GPUs to be close to the same hardware, while unlinked—which is what Ashes uses—allows any mix of GPUs to be used. The whole point of this, and why this works at all under DX12, is to make use of Split Frame Rendering (SFR). This breaks down each frame of a game into several tiles, which are then rendered in parallel by the GPUs. This is different to the Alternate Frame Rendering (AFR) used in DX12, where each GPU renders an entire frame each, duplicating data across each GPU.
http://arstechnica.com/gaming/2016/...lly-work-together-but-amd-still-has-the-lead/

Der Aufwand im IMA Modus dürfte marginal sein, der Treiber übernimmt hier die Aufteilung. Aber auch die komplexeren EMA Modes sind keine Zauberei. Eine Demo mit einer Grafikkarte + Onboard Unterstützung wurde bereits vor einem Jahr mit der Unreal Engine gezeigt.
http://www.redgamingtech.com/amd-discuss-directx-12-explicit-multiadapter/
unreal-engine-race-to-635-1024x562.jpg


Egal im welchen Modus. DX12 ist hier auf jeden Fall flexibler verwendbar. Man kann im IMA Modus praktisch das gleiche wie mit proprietären SLI/Crossfire erledigen, man kann im EMA Modus mit Split-Frame Rendering Teile der Anzeige auf verschiedene Grafikkarten aufteilen oder schlichtweg Aufgaben wie Beleuchtungsberechnung auf eine zusätzliche GPU auslagern.

Now, with DirectX 12’s Asymmetric Multi-GPU, this is no longer the case: instead, the weaker GPU can be tasked for physics or lighting. During Microsoft’s Build 2015 DX12 conference, the team used an Intel processor to handle the post processing of the scene after the 3d card (an Nvidia GeForce) finished rendering the bulk of the scene – such as the 3d Geometry and performing complex calculations such as realistic lighting and shadows. Now the Intel processor could add blurs, perform anti-aliasing or perhaps warping if you’re going to use it for a virtual reality display. To do this, DX12 tells the dedicated GPU to copy finished’ frame buffer from its own memory, and the system them writes it across to the other card.

Letztlich macht es für NVidia wenig Sinn weiterhin an eigenen proprietären Lösungen wie SLI oder PhysX zu arbeiten und für die Entwickler bedeutet nur EIN System unterstützen zu müssen auch eine Erleichterung.
 
Zuletzt bearbeitet:
@ xexex
Ein Multi GPU System zeichnet sich (ohne Abstraktionen/Wrapper) durch folgendes aus:
-GPUs müssen explizit angesteuert werden
-Es gibt keine automatische Lastbalancierung/Aufgabenverteilung zwischen den GPUs
-Es gibt keinen direkten Zugriff auf den Speicher von anderen GPUs.
-Für Datenaustausch bzw. Synchronisation sind explizite Kopieroperationen nötig

All diese Punkte sind auch bei Rechnern erfüllt, die über ein Netzwerk verbunden sind. Dementsprechend programmiert beides sich sehr ähnlich und stellt einen Programmierer vor die selben Probleme:
-Wie teile ich die Rechenlast zwischen den GPUs möglichst gleich auf, so dass ich Synchronisation vermeide? Insbesondere können zwei GPUs nicht gleichzeitig ins selbe bild zeichnen.
-Wie teile ich meine Daten zwischen den GPUs auf, dass ich Kopieroperationen vermeide und zudem möglichst wenig Daten redudant vorhalten muss? Diese Aufteilung muss auch zur balancierung der Rechenlast passen.
-Wie Synchronisiere ich am besten meine Zwischenergebnisse?
-Wie kann ich das ganze so Designen, dass die GPUs rechnen können, während sie dabei sind Daten zu kopieren?
 
Zuletzt bearbeitet:
Nai schrieb:
Und da fällt mir so spontan keine Software im Privatbereich ein, die solche verteilten Berechnungen unterstützt
distcc oder GNU Parallel fallen mir da ein. Sind insofern schöne Beispiele, als dass das zwar relativ simple Programme sind, die aber auch nur für sehr simple (trivial parallele) Einsatzzwecke funktionieren - denn alles, was darüber hinaus geht, wird wirklich ziemlich schwierig zu verwalten.

Load Balancing bei mehreren GPUs ist eine Sache, bei der mich auch mal interessieren würde, wie man sowas sinnvoll umsetzt - selbst wenn man mal davon ausgeht, dass jede GPU schon alle Daten hat, die sie potentiell gebrauchen könnte. Bei CPUs ist sowas mit Per-Core-Queues und Work Stealing fast schon trivial performant umsetzbar, bei GPUs müsste man für nen ähnlichen Ansatz schon bei quasi jeder Command Buffer-Submission mit Fences um sich werfen, um überhaupt feststellen zu können, was welche GPU noch zu tun hat - in den Vulkan-Specs rät man allerdings aus Performance-Gründen dazu, generell nicht mehr als ein Mal pro Frame Fences zu verwenden, weil das ganze wohl extrem ineffizient sein soll.
 
Mit der Ankündigung schön gewartet bis das Klientel sich 3/4 Karten geholt hat.
 
Nai schrieb:
@ xexex
Ein Multi GPU System zeichnet sich (ohne Abstraktionen/Wrapper) durch folgendes aus:
-GPUs müssen explizit angesteuert werden
-Es gibt keine automatische Lastbalancierung/Aufgabenverteilung zwischen den GPUs
-Es gibt keinen direkten Zugriff auf den Speicher von anderen GPUs.
-Für Datenaustausch bzw. Synchronisation sind explizite Kopieroperationen nötig

Hast du dir EINEN der von mir verlinkten Artikel angesehen?

Das was du beschreibst trifft genauso auch Multi-CPU Systeme zu wenn man die Software absolut Hardwarenah programmiert und Sachen wie NUMA berücksichtigen will. Nur muss sich Standardsoftware nicht darum kümmern.

Genauso sehe ich es am Beispiel von DX12. Hier werden explizit 3 Modis genannt bei denen die Entwickler selbst festlegen können was sie nutzen und wie gut sie optimieren wollen. Im IMA Modus trifft NICHTS von dem was du schreibst zu. Mit SLI gab es praktisch NUR diesen Modus, nun gibt es noch zwei weitere um Sachen wie Onboard Grafik nutzen zu können.

Vor allem bei deinen letzten beiden Punkten weiß ich nicht auf was du damit anspielen willst. Unter DirectX12 landet der Speicher aller Grafikkarten in einen Pool der durchaus direkt angesteuert aber auch von der jeweils anderen Grafikkarte genutzt werden kann. Im Gegensatz dazu wird bei SLI der Speicher gespiegelt und kann so nicht effektiv genutzt werden. Den Artikel dazu habe ich bereits verlinkt.

ikLwjPC.jpg


Das trifft natürlich nur auf die unabhängigen Modis zu. Ist auch logisch wenn ich zum Beispiel mit der zweiten GPU nur die Physik oder Beleuchtung berechnen lassen möchte.
 
Zuletzt bearbeitet:
@ xexex
Ich habe doch extra "ohne Abstraktionen/Wrapper" geschrieben um IMA/SLI/Crossfire abzuhaken. Natürlich kannst du überall, sei es bei Multi-GPU oder Multi-CPU, Abstraktionen verwenden, die dir die "unangenehmen" Eigenschaften deiner Hardware hinweg abstrahieren. Dafür haben solche Abstraktionen aber in der Regel viele andere Nachteile, siehe zum Beispiel die bisherigen Probleme bei SLI/Crossfire.


Vor allem bei deinen letzten beiden Punkten weiß ich nicht auf was du damit anspielen willst. Unter DirectX12 landet der Speicher aller Grafikkarten in einen Pool der durchaus direkt angesteuert aber auch von der jeweils anderen Grafikkarte genutzt werden kann. Im Gegensatz dazu wird bei SLI der Speicher gespiegelt und kann so nicht effektiv genutzt werden. Den Artikel dazu habe ich bereits verlinkt.

Multi-GPUs haben idr keinen direkten Zugriff auf ihren Speicher untereinander, sie sind also Systeme mit verteiltem Speicher. Das heißt ein Shader, der auf GPU A läuft, kann nicht auf eine Textur zugreifen, die im Speicher von GPU B liegt. Wenn ein solcher Zugriff gewünscht ist muss der Programmierer dementsprechend vor dem Drawcall/Computecall sicher stellen, dass die Textur (oder auch nur die benötigten Teile davon) sich im Speicher vom GPU A befindet indem er eine entsprechende Kopieroperation der DX12-API aufruft.


Seit Fermi sind NVIDIA GPUs sogar de facto für herkömmliche Buffer (nicht für Texturen!) NUMA systeme, was aber noch viele andere Nachteile hat, zudem bei Geforce Karten gesperrt ist und afaik auch nur unter Compute/CUDA funktioniert. Bei GCN ist in dieser Hinsicht afaik überhaupt kein NUMA möglich - nur ein direktes Kopieren zwischen zwei GPUs.

@ VikingGE
Diejenige Art von Lastbalancierung, die ich für Multi-GPU immer so gesehen habe, war in der Regel komplett reaktiv bezüglich der Laufzeit der letzten Frames und hat dementsprechend die Aufteilung angepasst.
 
Zuletzt bearbeitet:
Nai schrieb:
@ xexex
Ich habe doch extra "ohne Abstraktionen/Wrapper" geschrieben um IMA/SLI/Crossfire abzuhaken. Natürlich kannst du überall, sei es bei Multi-GPU oder Multi-CPU, Abstraktionen verwenden, die dir die "unangenehmen" Eigenschaften deiner Hardware hinweg abstrahieren. Dafür haben solche Abstraktionen aber in der Regel viele andere Nachteile, siehe zum Beispiel die bisherigen Probleme bei SLI/Crossfire.

Der Punkt ist doch aber - mit den angedachten Änderungen seitens Nvidia ändert sich daran nichts. Anstatt zweier konkurrierender Systeme, gibt es halt in der Zukunft nur noch DX12 (jetzt mal Vulkan außen vor, falls dort auch sowas geplant sein sollte). Der Status Quo bleibt also erhalten oder verbessert sich sogar.

Zusätzlich können die Entwickler sich ihr "SLI" nach belieben selbst zusammen bauen. Niemand zwingt sie dazu und eine großer Teil aktueller Spiele greift eh auf eine Engine zurück die solche Möglichkeiten bereits anbieten wird.

Worüber also den Kopf zerbrechen?

Am Ende ist der Vergleich, zwischen Multi-GPU und Multi-CPU wie ich finde richtig. Ein einfaches Programm muss sich darüber keine Sorgen machen und überlässt es dem System. Eine systemnahe Software, wie ein Hypervisor, muss sich hingegen vermutlich damit befassen.... Von der Komplexität eines verteilten Rechnernetzerkes ist sowas noch weit entfernt.

Letztlich zählt in meinen Augen nur eines. Die Einstellung der SLI Entwicklung seitens Nvidia (zumindest für 3-4 Fach Systeme) ist richtig weil sie so oder so weniger Möglichkeiten bietet wie DX12 und genauso wie nach DX10 kein Hahn sich mehr für PhysX interessiert hat, dürfte bald auch SLI/Crossfire verschwinden. Für den Anwender kann es nur vom Vorteil sein, denken wir nur an die unzähligen Notebooks mit 2 Grafikkarten bei denen bisher immer nur eine Einheit genutzt werden konnte oder die üblichen Systeme mit einer dedizierten Grafikkarte und einer APU, bei denen die APU bisher die ganze Zeit brach liegt. Hier könnte AMD gar einen Zahn zulegen, da sie bisher eine vergleichbar starke GPU Einheit mitgeliefert haben.

Ob die Entwickler am Ende davon gebraucht machen werden, ist wieder eine andere Sache. Allerdings ist IMA letztlich vermutlich ein Haken der gesetzt werden muss und bei den anderen Systemen waren auch bereits jetzt unterschiedliche Ansätze zu sehen. Intel hat ja bereits für F1-2015 Optimierungen durchgeführt, die den von DX12 mit einer dedizierten + einer integrierten Grafikkarte entsprechen indem sie die Aufgaben entsprechend aufgeteilt haben.
https://software.intel.com/en-us/articles/f1-2015-goes-to-the-next-level-of-realism-on-the-pc
 
Zuletzt bearbeitet:
@ xexex
Soweit wie ich das eben beim überfliegen verstehe, geht der link nur darum wie Intel Aufgaben statisch zwischen CPU und GPU aufgeteilt hat. Und die Beschreibungen lesen sich auch nicht danach, dass diese Anpassung nur wenig Aufwand war.
 
Nai schrieb:
@ xexex
Soweit wie ich das eben beim überfliegen verstehe, geht der link nur darum wie Intel Aufgaben statisch zwischen CPU und GPU aufgeteilt hat. Und die Beschreibungen lesen sich auch nicht danach, dass diese Anpassung nur wenig Aufwand war.

Richtig!

Intel hat gezielt Aufgaben von der GPU weggenommen und hat sie durch die CPU ersetzt. Speziell zum Beispiel die Partikeleffekte. Damit hat man im Grunde genommen das gleiche gemacht, was man mit DX12 und einer integrierten APU und oder einer zweiten GPU machen könnte.

The GPU load control was achieved in two ways. First, vertex work was moved from the vertex shader to the CPU. This reduced the amount of work done per vertex on the GPU. It did not completely remove the GPU workload, but it was reduced by a factor of two. So rendering ten times as many particles only resulted in a five-fold increase in the vertex processing cost. The second large change was to reduce fill rate costs, such as with rain. A ten times increase in raindrops resulted in an increase of only 1.65x in actual rendered pixels. In the case of the vortex trails behind the cars the changes were even more pronounced. An increase in vertices from 3K to 70K actually resulted in a pixel drop of 5800K to 2500k, effectively halving the fill rate cost of the effect. The end result was an effect made up of 20 times the number of particles with no significant increase in GPU rendering cost.

Für Intel war das vermutlich eine Art "proof of concept". Man portiert ein Spiel von der Konsole. Hat auf dem PC brachliegende CPU Kerne. Wie schaffe ich es damit ein besseres Spielerlebniss zu erzeugen. Die Anpassung war ein Patch für die PC Version - vermutlich finanziert von Intel. Zeigt jedoch auch, dass sich der Aufwand eher in Grenzen gehalten hat.
 
Zuletzt bearbeitet:
Zurück
Oben