Diskussion zu: SLI- und CrossFire-Eignung aktueller Spieletitel auf schwachem Niveau

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/sli-und-crossfire-eignung-aktueller-spieletitel-auf-schwachem-niveau

[Gast Ritis]

SLI und CF Support ist zunächst nicht das Problem der Spieleentwickler. Das ist ein ganz typisches Problem bzw. eine Aufgabe die in den Engines gelöst werden muss.

Dass ausgerechnet Unreal, Unity und Frostbyte komplett durchfallen ist das eigentliche Ärgernis. Die Marktführer sollten das Problem lösen und den Lizenznehmern den nötigen Support für die Implementierung geben.

Solange die Presse und Community nicht auf die Engine-Entwickler einhackt wird sich da leider nichts ändern, auch wenn Oxide mit der Nitro-Engine bewiesen hat, dass Vieles und vor allem gute Skalierung möglich ist.

[Gast]

Wäre es denn 'einfacher' eine zweite VGA zur Physik Berechnung einzusetzen als zwei VGAS für die Bildberechnung? Unabhängig von NVIDIAs Bibliotheken.

[tEd]

Ein Grund warum nach vielen Jahren jetzt SLI afgegeben habe.

[CD-LABS]

SLI und CF Support ist zunächst nicht das Problem der Spieleentwickler. Das ist ein ganz typisches Problem bzw. eine Aufgabe die in den Engines gelöst werden muss.

Dass ausgerechnet Unreal, Unity und Frostbyte komplett durchfallen ist das eigentliche Ärgernis. Die Marktführer sollten das Problem lösen und den Lizenznehmern den nötigen Support für die Implementierung geben.

Solange die Presse und Community nicht auf die Engine-Entwickler einhackt wird sich da leider nichts ändern, auch wenn Oxide mit der Nitro-Engine bewiesen hat, dass Vieles und vor allem gute Skalierung möglich ist.
Und wieso sollten sie auf die Engine-Entwickler einhacken?
Sinnvolles MultiGPU ist doch eine ganz, ganz kleine Nische, da STETS enorm teuer. Das ist was anderes, als Optimierung auf unfassbar viele Threads, hohe Auflösungen, schnelle SSDs oder Tonnen an RAM: Diese Leistungsniveaus werden auch irgendwann in den Mainstream kommen. Bei (AFR-) MultiGPU handelt es sich aber um eine METHODE! Und eine, die momentan keine Aussichten hat in der heutigen Form jemals Mainstream zu werden.

MultiGPU aus Mainstream-Karten ist schließlich konzeptuell Schwachsinn, selbst MultiGPU mit den stärksten SingleGPU-Karten ohne OC ist immer noch hochgradig zweifelhaft! Ohne starke CPU und Massen an Lanes ist es auch zumindest noch etwas zweifelhaft!

Von daher: Wieso sollte es irgendein breites Interesse geben MultiGPU zu pushen? Klar, es ist besser es in die Mainstream-Engines zu integrieren als dass es irgendein Dev dann nachpatched. Aber ob man (AFR-) MultiGPU überhaupt in die Engines bringen sollte, das steht noch zur Debatte.

Edit: Das MCM-Thema, das vor ein paar Tagen mal in den News war, besteht kein wirklicher Zusammenhang. Siehe dazu auch Leos Update: https://www.3dcenter.org/news/nvidia-forscht-mcm-basierten-grafikchips

[Gast Ritis]

Und wieso sollten sie auf die Engine-Entwickler einhacken?
Sinnvolles MultiGPU ist doch eine ganz, ganz kleine Nische, da STETS enorm teuer. Das ist was anderes, als Optimierung auf unfassbar viele Threads, hohe Auflösungen, schnelle SSDs oder Tonnen an RAM: Diese Leistungsniveaus werden auch irgendwann in den Mainstream kommen. Bei (AFR-) MultiGPU ...
Von daher: Wieso sollte es irgendein breites Interesse geben MultiGPU zu pushen? Klar, es ist besser es in die Mainstream-Engines zu integrieren als dass es irgendein Dev dann nachpatched. Aber ob man (AFR-) MultiGPU überhaupt in die Engines bringen sollte, das steht noch zur Debatte.

AFR? Wieso denn AFR? Das war gar nicht das Thema. AFR wird im Treiber am Game und Engine mehr oder weniger vorbei umgesetzt und funktioniert entsprechend schlecht.
Das was Oxide vormachte und was Engines leisten können ist kein AFR, auch bei Microsofts DX12 oder Vulkan mGPU Support geht es nicht um AFR, bitte selbst googeln.

mGPU Support benötigt man um mit dem Fortschritt bei den Displays mithalten zu können. Zwar hat FP16 das Potential die aktuelle Leistung zu verdoppeln, aber wir benötigen in den nächsten zwei bis drei Jahren die 8 bis 16-fache Leistung des aktuellen HD Bereichs um die High-End Lösungen für Monitore und VR/AR Headsets befeuern zu können.
Am unteren Ende hilft es brach liegende GPUs zu nutzen oder vor dem Müll zu bewahren.

Nur die Engine-Entwickler können das Henne-Ei Problem lösen, kein anderer im Markt blockiert das. Die Hardware ist da, die APIs sind da und die Kunden waren schon immer interessiert... bei jedem größeren Upgrade bei den Displays stellt sich die mGPU Frage aufs Neue.

Aber offensichtlich regieren bei den großen Platzhirschen die Erbsenzähler und die hocken immer noch auf ihrem alten Code obwohl bereits erste DX12 kompatible HW schon längst wieder in den Müll wandert.

[//differentRob]

SLI/CF wird langsam aber sicher einfach aussterben. Seitens der GPU-Hersteller bietet man noch Support und das Feature aufrecht...Balkenlänge und so.

Aber wirklich sinnvoll, nach dem nun auch die breite Gamer-Masse die Bedeutung von Frametimes kennt, ist dieses Gespann nicht mehr.

Interessant dürften die aktuellen Entwicklungen in Richtung MCM Design bei GPU's gehen.

[MiamiNice]

Ich bin der Meinung das Multi GPU erst wieder interessant wird mit der nächsten VR Generation. Multi GPU ist geradezu prädestiniert für diesen Einsatzzweck (1 GPU pro Auge).

Grüße

[Gast]

Die Spieleauswahl ist aber auch sehr komisch gewählt. EA Titel wie Pubg oder uralt Asia Ports wie vanquish.

[Gast]

Ich bin der Meinung das Multi GPU erst wieder interessant wird mit der nächsten VR Generation. Multi GPU ist geradezu prädestiniert für diesen Einsatzzweck (1 GPU pro Auge).

Grüße

Für jedes Auge komplett unabhängig ein Bild zu berechnen ist zwar möglich aber ziemlich ineffizient.
Multi GPU ist für VR zwar durchaus interessant, allerdings weniger um die Framerate zu erhöhen, sondern um die Anzahl berechneter Pixel und damit effektiv die Qualität zu erhöhen.
Ich denke auf lange Sicht werde wir für die großen Engines explizites Multi GPU über DX12 sehen, weshalb die Unterstützung über den Treiber auch immer stärker abnimmt.

[CD-LABS]

AFR? Wieso denn AFR? Das war gar nicht das Thema. AFR wird im Treiber am Game und Engine mehr oder weniger vorbei umgesetzt und funktioniert entsprechend schlecht.
Das was Oxide vormachte und was Engines leisten können ist kein AFR, auch bei Microsofts DX12 oder Vulkan mGPU Support geht es nicht um AFR, bitte selbst googeln.

mGPU Support benötigt man um mit dem Fortschritt bei den Displays mithalten zu können. Zwar hat FP16 das Potential die aktuelle Leistung zu verdoppeln, aber wir benötigen in den nächsten zwei bis drei Jahren die 8 bis 16-fache Leistung des aktuellen HD Bereichs um die High-End Lösungen für Monitore und VR/AR Headsets befeuern zu können.
Am unteren Ende hilft es brach liegende GPUs zu nutzen oder vor dem Müll zu bewahren.

Nur die Engine-Entwickler können das Henne-Ei Problem lösen, kein anderer im Markt blockiert das. Die Hardware ist da, die APIs sind da und die Kunden waren schon immer interessiert... bei jedem größeren Upgrade bei den Displays stellt sich die mGPU Frage aufs Neue.

Aber offensichtlich regieren bei den großen Platzhirschen die Erbsenzähler und die hocken immer noch auf ihrem alten Code obwohl bereits erste DX12 kompatible HW schon längst wieder in den Müll wandert.
Bis zu dem letzten Satz war MultiGPU (und damit auch AFR) generell dein Thema.

Aber gut, ich rede auch gerne nur über nicht AFR-MultiGPU:
Selbst die von dir gelobte Oxide-Skalierung befindet sich in keinem Bereich, indem Midrange-MultiGPU eine sinnvolle Option darstellen würde. Es bleibt ausschließlich beim Ultra-HighEnd ein interessanter Schritt bzw. würde dann wieder zu einem interessanten Schritt. Denn dein Szenario mit den brach liegenden GPUs im Mainstream zu nutzen ist unrealistisch: Dadurch wird es kaum Performancevorteile geben, die Leistungsaufnahme wird aber durch die Decke schießen. Die Karten zu verkaufen ist sinnvoller---vor allen Dingen, da sich jener Effekt auch noch verstärkt, je älter die zweite Karte ist.

Um die kommenden Displays standesgemäß zu befeuern sind vor allen Dingen grundlegende Verbesserungen beim Speicher (weniger Chipflächeneinsatz auf dem GPU-DIE, geringere Boardkosten, geringere Speicherkosten & mehr Geschwindigkeit zugleich!) und generell größere DIEs in allen Performanceklassen von Nöten. Fortschritte im Bereich der Kühlung wären auch ganz schick, aber sehr unwahrscheinlich. Das sind aber alles Dinge, die in eine einzelne GPU einfließen würden.
Ausschließlich für VR ist MultiGPU wirklich auch für eine breitere Nutzergruppe interessant, allerdings entwickeln sich auch dort Techniken, die einer SingleGPU-Lösung zu Gute kämen und mit MultiGPU nicht gut funktionieren würden.

Auf Softwareseite in VR- wie NonVR könnten einen noch bedeutend bessere Tricks bzgl. dynamischer Auflösung einfallen.


Bzgl. Engineentwickler: Die sind doch noch nicht einmal bei tollen SingleGPU-Varianten ihrer Engines für DX12 und Vulkan angekommen.

[Gast Ritis]

Bis zu dem letzten Satz war MultiGPU (und damit auch AFR) generell dein Thema.
Wenn man Multi GPU mit DX12 und Vulkan in den Engines fordert ist das nunmal kein AFR. Ganz einfach eigentlich. Das Thema ist zu komplex um das hier zu erklären, sorry, selbst googeln.

Dadurch wird es kaum Performancevorteile geben, die Leistungsaufnahme wird aber durch die Decke schießen. Die Karten zu verkaufen ist sinnvoller---vor allen Dingen, da sich jener Effekt auch noch verstärkt, je älter die zweite Karte ist.
Vorteile sind Vorteile und "kaum" ist erwiesener massen falsch. Die Leistungsaufnahme juckt nicht, die Wärmeabfuhr wird auch kaum schwieriger. Karten 2nd Hand zu verkaufen ist sinnvoll wenn der Preis stimmt. Deshalb kein mGPU in Engines zu fordern macht keinen Sinn.

Um die kommenden Displays standesgemäß zu befeuern sind vor allen Dingen grundlegende Verbesserungen beim Speicher (weniger Chipflächeneinsatz auf dem GPU-DIE, geringere Boardkosten, geringere Speicherkosten & mehr Geschwindigkeit zugleich!) und generell größere DIEs in allen Performanceklassen von Nöten. Fortschritte im Bereich der Kühlung wären auch ganz schick, aber sehr unwahrscheinlich. Das sind aber alles Dinge, die in eine einzelne GPU einfließen würden. Interessante Ansätze, realistisch in keinem Punkt. ;D Die Anforderungen bei den Displays wachsen viel schneller - das war und ist mein Argument.

Auf Softwareseite in VR- wie NonVR könnten einen noch bedeutend bessere Tricks bzgl. dynamischer Auflösung einfallen.
Gute Ideen sind immer Gold wert, nur zu mit der Umsetzung. ;D

Bzgl. Engineentwickler: Die sind doch noch nicht einmal bei tollen SingleGPU-Varianten ihrer Engines für DX12 und Vulkan angekommen.
Der Grund dafür ist die Erbsenzählerei, denn mit genug Budget und Manpower geht das. Nur solange der Druck nicht da ist wird es das Budget nicht geben. Scheinbar haben die Platzhirsche zu wenig Druck und machen nur Sequels mit so viel technischer Innovation wie gerade nötig. Nachdem die Frostbite Jungs und EA aus Mantel und den Vorarbeiten für die neuen APIs keinen Vorteil ziehen konnten ist es dort auch sehr still geworden und DX12 und Vulkan Adaption eher schleppend. Dort haben deshalb wohl die Erbsenzähler wieder Oberwasser bekommen.

[Gast]

Wenn man Multi GPU mit DX12 und Vulkan in den Engines fordert ist das nunmal kein AFR.

Multi-GPU mit DX12 kann genauso AFR sein, und wird es in vielen Fällen auch sein, weil es einfach das höchste Skalierungspotential hat.

[Gast Ritis]

Multi-GPU mit DX12 kann genauso AFR sein, und wird es in vielen Fällen auch sein, weil es einfach das höchste Skalierungspotential hat.
AFR könnte auch bei DX12 gemacht werden, es würde aber überhaupt keinen Sinn ergeben, weil die bekannten Nachteile beibehalten blieben. Es würde alles so schlecht bleiben wie es ist.
AFR hat übrigens das schlechteste Skalierungspotential, weil alle HW-Ressourcen gleichermassen doppelt vorhanden sein müssen und weil damit unterschiedliche Latenzen und Microstutering von Frame2Frame kaum in den Griff zu bekommen sind. Deshalb gibt es in DX12 und Vulkan entsprechende andere mGPU Ansätze. Die Renderpipeline und Compute wird verteilt, nicht einzelne Frames im Ganzen.... aber ich wiederhole mich, bitte selbst googlen.