DirectX 12 vereinheitlicht die Verwendung mehrerer Grafikkarten - Seite 2

Seite 2 von 5 - Forum: Spiele auf overclockers.at

URL: https://www.overclockers.at/spiele/directx-12-vereinheitlicht-die-verwendung-mehrerer-grafikkarten_242204/page_2 - zur Vollversion wechseln!


Nico schrieb am 25.02.2015 um 17:50


mat schrieb am 25.02.2015 um 18:32

Dafür wird es dann wahrscheinlich einen Load Balancer/Scheduler geben, der die Grafikkarten füttert. Ich habe es bei GPUPI auch so implementiert, allerdings in einer eher primitiven Variante. :( ;)

Schwierig sind bei so etwas immer die Themen Caching - welche Karte cached was und könnte dadurch schneller sein als eine Karte des Verbunds - und Prediction. Prediction ist besonders so eine Sache, weil das darüber entscheidet, ob die Kombination von langsamer und schneller Grafikkarte (bzw. stark abweichenden Architekturen) effizient genug ablaufen lässt, um einen Performance-Vorteil zu ergeben.

Ein Beispiel: Die schnelle Grafikkarte ist gerade beschäftigt, es kommt aber ein neues Paket rein, das abgearbeitet werden muss. Soll das jetzt die aktuell freie, langsame Grafikkarte übernehmen oder ist die schnelle Grafikkarte trotzdem schneller, weil sie das aktuelle Paket und das folgende Paket in kürzerer Zeit abarbeiten kann, als es die unausgelastete schwache Grafikkarte könnte. Got it? :p


Nico schrieb am 25.02.2015 um 18:37

dann gibt es im grunde keinen split wie zb 50/50, sondern einfach multithreading across devices. scheduling bringts nur dann, oder es gibt keine flüssige ausgabe bei zu schwacher gpu afaik.


chap schrieb am 03.03.2015 um 13:30

Nach ewtas Denkpause, ein Mainboard mit 2x 16Fach wird ja trotzdem nötig sein?
Das wird der 0815-Anwender nicht kaufen um am Markt sich durch zu setzten?


noejo schrieb am 03.03.2015 um 15:54

Eigentlich müsste man mit SFR dann den doppelten VRAM erreichen können. Oder habe ich das falsch verstanden?


daisho schrieb am 03.03.2015 um 16:09

Ich bezweifle dass sich das in der Praxis aber so gut umsetzen lässt, vor allem werden Entwickler nicht viel Zeit auf solche Features verschwenden die kaum jemand nutzen kann.

Also VRAM verdoppeln wird es nicht spielen, vielleicht ein wenig Speicher gewinnen ja. Die Frage ist wie viele Probleme man sich mit dem Feature einhandelt.

Ich vermute es wird in etwa gleich enden wie Crossfire und SLI ... jedoch mit weniger Beschränkungen (was ja schon ein großer Vorteil ist).
Technologische Wunder würde ich mir davon keine erhoffen.


Master99 schrieb am 03.03.2015 um 16:09

Zitat von chap
Nach ewtas Denkpause, ein Mainboard mit 2x 16Fach wird ja trotzdem nötig sein?
Das wird der 0815-Anwender nicht kaufen um am Markt sich durch zu setzten?

nein, denn eigentlich müssten die bandbreitenanforderungen an den bus ja sinken, weil zb weniger texturen geladen werden müssen.

das ist wie ein raid0 wo zwei 'langsamere' links dann einen flotteren virtuellen ergibt.


chap schrieb am 04.03.2015 um 07:37

Zitat von Master99
nein, denn eigentlich müssten die bandbreitenanforderungen an den bus ja sinken, weil zb weniger texturen geladen werden müssen.
Achja, die "langen" sind ja nicht nur 16Fach.
Es ging mir um die Möglichkeit zwei lange Bänke für die Grafikkarten zu haben. nicht nur 1Fach


mr.nice. schrieb am 04.03.2015 um 20:50

Für die in weiter Zukunft geplante Auflösung von 8K pro Auge wird man ein gut funktionierendes SFR schon brauchen, zumal die Imersion von VR so leicht durch Latenz zu nichte gemacht wird. Ich denke darauf wird es früher oder später hinauslaufen, für jedes Auge eine Graka. Mein linkes bevorzugt Nvidia, mein rechtes AMD :D


Mr. Zet schrieb am 04.03.2015 um 22:05

Zitat von mr.nice.
Mein linkes bevorzugt Nvidia, mein rechtes AMD :D
:cordless: :D


mat schrieb am 11.03.2015 um 09:23

Auf GameDev.net, eine alte Heimat von mir, gibt es derzeit einen regen Diskussionsthread zum Thema DirectX 12, Mantle und Vulcan (das nächste OpenGL). Dabei hat sich ein ehemaliger NVIDIA-Mitarbeiter aus dem Driver-Team zu Wort gemeldet und einige interessante Fakten zu Tageslicht gebracht:

Zitat
The first lesson is: Nearly every game ships broken. We're talking major AAA titles from vendors who are everyday names in the industry. In some cases, we're talking about blatant violations of API rules - one D3D9 game never even called BeginFrame/EndFrame. Some are mistakes or oversights - one shipped bad shaders that heavily impacted performance on NV drivers. These things were day to day occurrences that went into a bug tracker. Then somebody would go in, find out what the game screwed up, and patch the driver to deal with it. There are lots of optional patches already in the driver that are simply toggled on or off as per-game settings, and then hacks that are more specific to games - up to and including total replacement of the shipping shaders with custom versions by the driver team. Ever wondered why nearly every major game release is accompanied by a matching driver release from AMD and/or NVIDIA? There you go.

The second lesson: The driver is gigantic. Think 1-2 million lines of code dealing with the hardware abstraction layers, plus another million per API supported.

[...]

The fourth lesson: Multi GPU (SLI/CrossfireX) is fucking complicated. You cannot begin to conceive of the number of failure cases that are involved until you see them in person. I suspect that more than half of the total software effort within the IHVs is dedicated strictly to making multi-GPU setups work with existing games.

Abschließend meint er allerdings, dass die neuen Grafikschnittstellen einige dieser Probleme lösen können. Speziell das Thema Multithreading und Multi-GPU werden durch die neue Abstraktion deutlich vereinfacht. Abgesehen davon soll auch ältere Hardware einen guten Leistungsschub bekommen können. Außerdem darf man mit den neuen APIs jetzt wirklich die Spielehersteller für langsame Games verantwortlich machen:

Zitat
What has finally been made clear is that it's okay to have difficult to code APIs, if the end result just works. And that's been my experience so far in retooling: it's a pain in the ass, requires widespread revisions to engine code, forces you to revisit a lot of assumptions, and generally requires a lot of infrastructure before anything works. But once it's up and running, there's no surprises. It works smoothly, you're always on the fast path, anything that IS slow is in your OWN code which can be analyzed by common tools. It's worth it.

Quelle: Post auf GameDev.net


daisho schrieb am 11.03.2015 um 09:40

Well ... ist kein Geheimnis das die meisten Programmierer leider einfach nur unfähige Programmierer sind und keine Entwickler mit Grips im Kopf.

Bin in der Arbeit damit selbst konfrontiert (nachdem man R&D schön ausgelagert hat).

Ich habe erst letztens (weil ich wieder Gothic 1 + 2 spiele) mit dem Windows Application Compatibility Toolkit z.B. den Fensterrahmen für Fullscreen-Windowed-Mode (den man eigentlich gar nicht einstellen soll, weil ab und zu Crashes oder sonstige Probleme) wegbügeln müssen.
Und ja ... gerade AAA-Titel haben auch oft die am schlechtesten laufenden/optimierten Codes :bash:


Mr. Zet schrieb am 11.03.2015 um 10:01

Der Pfusch von Programmierern macht halt leider auch nicht vor der Spielebranche halt. Gute Developer/Publisher kümmern sich dann wenigstens auch darum Probleme die durch Pfusch/"dirty shortcuts" entstehen zu korrigieren, auch für ältere Games. Schlechte Teams/Publisher kümmern sich halt einen feuchten Dreck darum.

Beispiele aus der Vergangenheit:
*) Ein älteres Win9x Game (ich kann mich leider nicht mehr an den Titel erinnern) lies sich anfangs nicht unter Windows 2000 installieren. Warum? Weil anstatt die installierte DirectX Version zu prüfen, hat der Installer einfach die Windows Version abgefragt, hat Windows 2k als Windows NT "erkannt" und gesagt "DirectX ist nicht in der notwendigen Version verfügbar"...
Innerhalb kürzester Zeit gab es da dann entweder einen modifizierten Installer oder ein Windowsupdate hat das Problem behoben.

*) Bei Industriegigant 2 wurden offenbar High-Level API Funktionen umgangen und weiter unten direkt auf Hardwarefunktionen zugegriffen. Ergebnis? Das Spiel lief nicht auf PCI Express Grafikkarten, weil es direkt auf AGP Funktionen zugreifen wollte :bash:. Da gab es Jahrelang keinen Patch dafür, ich weiß nicht mal, ob es jemals einen (offiziellen) Patch dafür gab.


mat schrieb am 19.03.2015 um 09:26

In folgendem Video sieht man zum ersten Mal sehr schön, was DirectX 12 und Mantle jetzt aus einer Multi-Core-CPU herausholen können. Bis dato war das Befüllen der Grafikkarten Single-threaded und dadurch ein Bottleneck beim Rendering. Die restlichen Kerne wurden für AI, Preloading usw. verwendet. Jetzt nutzt die Grafik-Pipeline auch wirklich alle verfügbaren Kerne:


Mr. Zet schrieb am 19.03.2015 um 10:08

Nice! :eek:




overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2024