News DirectX 12: Mit „Multiadapter“ rendern Grafikkarte und IGP zusammen

Der_Gekko · 4. Mai 2015

Mensch,super: sehr schön, dass dieser längs überfällige Entwicklung nun endlich in grüßerem Umfang in Schwung kommt! Alle, die eine etwas potentere iGPU haben, können diese endlich auch in ihrem Spiele-PC gewinnbringend einsetzen. Es wird sehr spannend zu sehen sein was mit AMD's A10 möglich sein wird, aber auch mit den stärkeren Intel iGPUs. Hoffentlich wird es einigermaßen schnell und breit implementiert.

CD · 4. Mai 2015

Shririnovski schrieb:
(...)
Naja aber davon abgesehen, wirklich beeindruckt bin ich davon jetzt auch nicht, um einen größeren Unterschied zu machen sind die aktuelle iGPUs praktisch alle zu lahm.

Kommt halt drauf an, was da als diskrete Karte(n) noch so im Rechner steckt. Ein absolutes Monster wird selbst von der schnellsten IGP nicht sonderlich profitieren. Im Bericht wird auch nicht erwähnt, unter welchen Bedingungen diese 11% Leistungssteigerung gemessen wurden. Zu sagen, es handle sich um eine Nvidia GPU zusammen mit einer Intel IGP, nun ja das heißt erstmal noch nicht viel.

Andererseits, Fortschritt ist gut und vielleicht lernt man daraus auch wie man unter DX12 die Last in einem "richtigen" Multi-GPU-Gespann besser verteilt. AFR als Dauerlösung ist nämlich nicht so ideal.

Chesterfield · 4. Mai 2015

war das kein "ähnlicher" Ansatz Lucid Hydra ? und jeder weiss was damit passiert ist ...

Blade0479 · 4. Mai 2015

das ist wieder nur etwas vermutlich, was bei 2 von 30 Spielen funktioniert und die restlichen durch Treiberprobleme abstürzen lässt. Lucid Virtu MVP 3.0

Yuuri · 4. Mai 2015

Chesterfield schrieb:
war das kein "ähnlicher" Ansatz Lucid Hydra ?

Nein, auch da teilen sich alle GPUs alle Bilder. Der Ansatz hier ist das Selbe, wie wenn eine Soundkarte oder Grafikkarte hinzukommen würde. Statt alles softwareseitig auf der CPU/einer GPU zu berechnen, wird die Berechnung nun mal auf die iGPU ausgelagert.

der_infant · 4. Mai 2015

Da macht die GPU im i7 endlich Sinn. Oder ist minimal weniger sinnlos als bisher ; ).

Daedal · 4. Mai 2015

Locuza schrieb:
Jep, eine Kopie ist notwendig.
Aufgrund der expliziten Kontrolle und Multi-Engine kann der Entwickler das aber parallel steuern, im Gegensatz zu DX11.

Gilt das für die DX12 API oder gilt das für die Hardware von Nvidia und Intel? Hast du eine Quelle die zeigt, dass bei AMD hier nicht mit Zerocopy und hUMA direkten Zugriff auf den GPU Speicher besteht? Vor allem da AMD für diese Postprocessing Effekte seine ACEs verwendet die in der GPU verbaut sind und mit dem GPU Speicher arbeiten - keine Kopie für die selbe Funktion nötig. Siehe:
http://www.gamestar.de/hardware/gra...r_gpu_leistung_in_directx_12,709,3084467.html
Dies unterstützen alle GCN GPUs. und GCN APUs.

Benutzt wird es von Sonys PS4 und dem Mantle Spiel Thief auch schon längst.

Vor allem wird hier die Latenz kürzer:
http://www.extremetech.com/gaming/2...-into-amd-gpus-thanks-to-asynchronous-compute

DaDare schrieb:
@Vitec,

ein weiteres Problem wird sein, dass DX12 nur für Windows 10 kommen wird. Sprich die Entwickler werden DX10/DX11 als Minimum nehmen müssen.

Das ganze wird auch unter Windows 7/8 durch Mantle unterstützt (das seit jetzt fast anderthalb Jahren) und durch den nachfolger Vulkan. DX ist dafür gar nicht notwendig.

Yuuri schrieb:
Wo stiehlt MS hier wem die Show? Hybrid CF funktioniert wie CF nun mal funktioniert - die Bilder werden absechselnd von je einer GPU berechnet (AFR).

AMD nutzt jetzt schon SFR (Split Frame Rendering) z.B. bei Civ , wo jede GPU ihren eigenen Teil des Bildes rendert unter Mantle.
http://www.extremetech.com/gaming/1...ulti-gpu-scaling-in-civilization-beyond-earth

Auch etwas unklar was nun DX12 mit dem DualGPU Feature anders macht als das was AMD bisher seit Jahren mit mehr FPS-Zugewinn gemacht hat. Dazu steht absolut gar nichts in der News.

Nai · 4. Mai 2015

Warum hat NVIDIA nach der 3Dfx Übernahme SLI eigentlich von der Berechnung einzelner Zeilen auf AFR umgestellt?

Ich nehme an, da gerade damals noch die kosten für den "Vertexshader" deutlich höher waren als für den "Fragmentshader". Außerdem muss die GPU im Fragmentshader den Gradienten einer Größe zwischen benachbarten Pixeln berechnen können, zum Beispiel für das anisotrope Filtering. Diese Gradientenberechnung ist beim Aufteilen in Zeilen auch problematisch.

Wenn es richtig umgesetzt wird, kann das ein Game Changer werden. Mit Vorteilen für AMD. Ich denke da nicht so an Grafikberech ungen, weil das unnötig die Latenzen versaut aber Sachen, die momentan auf der CPU berechnet werden, könnten damit einen Sprung machen. Da wären die Physikeffekte aber was sich mir viel mehr aufdrängt ist KI oder reaktive Umgebungen. Man stelle sich mal vor, beispielsweise in etwas wie Cities Skylines wird der Verkehr auf der GPU berechnet statt auf der CPU (davon gehe ich mal aus) oder die KI von Gegnern in Shootern oder Strategiespielen.

Naja, du brauchst Aufgaben die zu 100 000 mal parallelisierbar und weitestgehend datenparallel sind. Da gibt es relativ wenige auch in der KI.

Ich sehe das Auslagern auf die IGPU durch eine asynchrone Pipeline etwas problematischer:
-Post Processing-Pässe sind oft DRAM-Bandbreiten limitiert; dadurch kostet einem dieser Effekt beim Auslagern auf die IGPU indirekt CPU-Leistung. Die benötigte DRAM-Bandbreite kann man zwar bei diesen Post-Processing-Stencils meist auch irgendwie Blocken (Last-Level-Cache oder Scratchpad-Memory) reduzieren. Ein solches Blocking ist auf der GPU bei Stencils fallabhängig recht umständlich zu programmieren. Und bei Last-Level-Cache-Blocking, kostet einem das Blocking wiederum Last-Level-Cache-Platz und Bandbreite.
-Post Processing ist teuer: Man muss irgendwie evaluieren, welche der Post-Processing-Pässe man auf die IGPU auslagern kann, ohne dass diese limitiert. Denn wenn die IGPU limitiert hat man durch diese Optimierung eventuell sogar eine schlechtere Performance als ohne.
-Eine solche asyonchrone Pipeline zu programmieren ist nicht so trivial. Je nachdem wie komplex und effizient man eine solche Pipeline gestalten möchte, wird dies wiederum sehr schnell sehr hässlich.

Locuza · 4. Mai 2015

Daedal schrieb:
Gilt das für die DX12 API oder gilt das für die Hardware von Nvidia und Intel? Hast du eine Quelle die zeigt, dass bei AMD hier nicht mit Zerocopy und hUMA direkten Zugriff auf den GPU Speicher besteht? Vor allem da AMD für diese Postprocessing Effekte seine ACEs verwendet die in der GPU verbaut sind und mit dem GPU Speicher arbeiten - keine Kopie für die selbe Funktion nötig.

Das gilt für die DX12 API, je nach Hardware gibt es aber praktische Einschränkungen.
Bei dem Beispiel wird dank Multiengine eine 3D-Queue für die Nvidia GPU erstellt und parallel dazu eine Copy-Queue.
Vorher musste jeder Abschnitt in eine queue gepackt werden.

ZeroCopy, hUMA und ACEs sind Spieleentwickler gesteuert.
Das läuft nicht automatisch.

Mit DX12 lässt sich das aber ausnutzen.
Shared-memory kann definiert werden und das Multiengine Feature wird dann durch die DMA-Engines, ACEs/Hyper-Q oder wie auch immer die Hersteller die technische Lösung in ihrer Hardware nennen, unterstützt.

AMD nutzt jetzt schon SFR (Split Frame Rendering) z.B. bei Civ , wo jede GPU ihren eigenen Teil des Bildes rendert unter Mantle.

AMD nutzt es nicht, die Entwickler tun es.

Auch etwas unklar was nun DX12 mit dem DualGPU Feature anders macht als das was AMD bisher seit Jahren mit mehr FPS-Zugewinn gemacht hat. Dazu steht absolut gar nichts in der News.

Du meinst gegenüber Mantle?

Sebbi · 4. Mai 2015

für mich wäre interessanter, wenn man es schafft, das im Desktopbetrieb nur die CPU intigierte GPU arbeiten würde und die Grafikkarte fast vollständig abschalten könnte. Sozusagen nur noch passthrough für die Bilddaten bereitstellt.

damit würde sich viele Energie sparen lassen und auch der geräuchpegel erheblich reduzieren, wenn die graka abschaltet.

Daedal · 4. Mai 2015

Nun AMDs Hardware nutzt es. Wie sollten es sonst die Entwickler nutzen?

Nein ich meine was ist daran nun anders als bei AMDs DualGPU unter DX11?
Das ist doch ein alter Hut und nichts neues bei DX12, dass man mit der iGPU zusätzliche Performance bekommt.

Locuza · 4. Mai 2015

Daedal schrieb:
Nun AMDs Hardware nutzt es. Wie sollten es sonst die Entwickler nutzen?

Ich bin jetzt mal kleinlich.
AMDs Hardware bietet es an, ob es genutzt wird, ist Entwickler-Sache.

Nein ich meine was ist daran nun anders als bei AMDs DualGPU unter DX11?
Das ist doch ein alter Hut und nichts neues bei DX12, dass man mit der iGPU zusätzliche Performance bekommt.

Bei DX11 war es immer das Teilen vom Rendering-Process (AFR).
Und CrossFire mit der iGPU war auch darauf beschränkt, dass die GPUs alternierend die Frames berechnen.

Unter DX12 gibt es mehrere Modis, implicit Multi-GPU, dann läuft es wie unter DX11 mehr oder weniger automatisch, der Treiber muss es erledigen.
Neu hinzu kommt explicit Multi-GPU mit linked oder unlinked GPUs.
Und hier kann man sich dann alles mögliche einfallen lassen und es gilt theoretisch Hersteller übergreifend.

Daedal · 4. Mai 2015

Locuza schrieb:
Ich bin jetzt mal kleinlich.
AMDs Hardware bietet es an, ob es genutzt wird, ist Entwickler-Sache.

Kannst du gerne sein, doch nutzen denn andere GPU Hersteller das Feature in Hardware, welches die Entwickler in Software programmiert haben?

Ich denke am Ende kommt es immer darauf an ob eine Hardware ein Software Feature nutzt oder nicht. Man kann es gerne auch umdrehen, doch sehe ich wenig zielführendes in dieser semantischen Wortklauberei.

Zu den anderen Äusserungen würde ich gerne mal eine Quelle sehen, da dies bisher nicht plausibel für mich war wie du es bisher erklärt hast.

Ich seh in dem Artikel absolut gar nichts das sich von Hybrid-Crossfire mit AFR unterscheidet. Es wird noch nicht mal gesagt, dass kein AFR genutzt wird. Das einzige das anders ist, ist dass es nun Nvidia und Intel Hardware sind die funktionieren auf diese Weise. Alter Hut der spät nachgeliefert wird mit schlechteren FPS Zuwächsen.

G3cko · 4. Mai 2015

Ich glaube nicht, dass unbedingt der Delay spürbar höher ist. Mehr fps deutet auch zwangsweise kürzere Zeiten zwischen den Frames. Es wird ja ohnehin alles in Echtzeit berechnet. Bitte korigiert mich wenn ich einen Denkfehler habe.

Zumindest finde ich die Technologie sehr interessant. Besonders wenn man seine alte Grafikkarte zum Teilrendern weiterverwenden könnte. Dies sollte doch deutlich mehr Perfomance bringen als mit der iGPU. Wenn dann noch die zweite GPU bei Nichtnutzung aller ZeroCore im Idle 0 Watt verbraucht wäre es perfekt.

Nai · 4. Mai 2015

Ich glaube nicht, dass unbedingt der Delay spürbar höher ist. Mehr fps deutet auch zwangsweise kürzere Zeiten zwischen den Frames. Es wird ja ohnehin alles in Echtzeit berechnet. Bitte korigiert mich wenn ich einen Denkfehler habe.

Wenn du dir das Diagramm anschaust, dann ist es in dem Beispiel kaum mehr FPS als ohne IGPU aber etwas mehr als ein halber Frame mehr Latenz. Ist die IGPU sehr langsam und die DGPU sehr schnell, so sind es wohl im Worst-Case in etwa einen Frame verspätung.
Den Frame musst du aber noch in Relation dazu setzen, dass der Zeichenvorgang der Spiellogik ebenfalls um circa noch einmal einen Frame interherhinkt, der GPU-Treiber ein paar Frames zwischenspeichert und die nacheinander und verspätet ausgibt, und der Fenster-Mananger von Windows afaik ebenfalls zusätzlich einen Frame hinterherhinkt. Dann geht das Bild ersteinmal an deinen TFT, der es dann noch einmal etwas verspäteter darstellt. Deswegen ist es fraglich, ob man so einen Frame zusätzlich merkt.

Locuza · 4. Mai 2015

Daedal schrieb:
Kannst du gerne sein, doch nutzen denn andere GPU Hersteller das Feature in Hardware, welches die Entwickler in Software programmiert haben?

Ich nehme mal an du redest über async-compute/ACEs?

Nvidias GPUs sollen erst ab Maxwell Gen 2 parallel mehrere Compute-Queues neben der 3D-queue verwalten können.
http://www.anandtech.com/show/9124/amd-dives-deep-on-asynchronous-shading

Eine Copy-Queue sollten aber auch GPUs zuvor haben.

Intels GPUs können bisher nicht mehrere Compute-Queues verwalten.
3D und Compute wird wie bisher nacheinander abgearbeitet.
Eine Copy-Engine gibt es, die soll aber langsam sein. (Seite 23)
https://software.intel.com/sites/default/files/managed/4a/38/Efficient-Rendering-with-DirectX-12-on-Intel-Graphics.pdf

Zu den anderen Äusserungen würde ich gerne mal eine Quelle sehen, da dies bisher nicht plausibel für mich war wie du es bisher erklärt hast.

Ich seh in dem Artikel absolut gar nichts das sich von Hybrid-Crossfire mit AFR unterscheidet. Es wird noch nicht mal gesagt, dass kein AFR genutzt wird. Das einzige das anders ist, ist dass es nun Nvidia und Intel Hardware sind die funktionieren auf diese Weise. Alter Hut der spät nachgeliefert wird mit schlechteren FPS Zuwächsen.

In dieser News liest du, dass die iGPU Post-Processing berechnet. (Teile davon)
Das tut Crossfire nicht, Crossfire berechnet abwechselnd ganze Frames auf beiden GPUs.

Aber die News ist da zu kurz gefasst, wenn du Lust hast, kannst du die ganze Präsentation von der Build anschauen:
http://channel9.msdn.com/Events/Build/2015/3-673

Ab Minute 27 geht es um explicit Multi-GPU.

G3cko · 4. Mai 2015

Nai schrieb:
Wenn du dir das Diagramm anschaust, dann ist es in dem Beispiel kaum mehr FPS als ohne IGPU aber etwas mehr als ein halber Frame mehr Latenz. Ist die IGPU sehr langsam und die DGPU sehr schnell, so sind es wohl im Worst-Case in etwa einen Frame verspätung.
Den Frame musst du aber noch in Relation dazu setzen, dass der Zeichenvorgang der Spiellogik ebenfalls um circa noch einmal einen Frame interherhinkt, der GPU-Treiber ein paar Frames zwischenspeichert und die nacheinander und verspätet ausgibt, und der Fenster-Mananger von Windows afaik ebenfalls zusätzlich einen Frame hinterherhinkt. Dann geht das Bild ersteinmal an deinen TFT, der es dann noch einmal etwas verspäteter darstellt. Deswegen ist es fraglich, ob man so einen Frame zusätzlich merkt.

Das stimmt. Je höher die fps jedoch sind, desto geringer müsste der Inputlag sein.

Hagen_67 · 4. Mai 2015

Hmm,
liest sich erstmal sehr schön.
Toll wäre, wenn die iGPU dann z.B. PhysX berechnen könnte, aber ob da nVDIA mitspielt ist auch eine fragliche Geschichte.

Aber ich fänd' es schon mal toll (ja, man wird bescheiden), wenn die Zusammenarbeit zwischen dezidierter GraKa und iGPU so gut wäre, dass es mir bei Vollbilddarstellung auf dem Monitor der dezidierten GraKa nicht immer den Inhalt der Darstellung auf dem Monitor der iGPU so arg verschieben würde.

UNDERESTIMATED · 4. Mai 2015

der_infant schrieb:
Da macht die GPU im i7 endlich Sinn. Oder ist minimal weniger sinnlos als bisher ; ).

Also wenn ich einen Tag NUR arbeiten und surfen will deaktiviere ich die dedizierte GPU und freue mich dass das System komplett lautlos ist und eben billiger arbeitet, angeschlossen ist eh beides am Monitor.

Nur zum Zocken einen i7 zu benutzen bringt immer noch fast nix, verstehe aber den Gedankengang.

Was ich mich aber frage: Was genau macht DirectX nun anders als AMD vor über 5Jahren mit HybridGraphics? WIRKLICH toll wäre, wenn es die dedizierte GPU wie im Notebook auch am Desktop KOMPLETT abschalten kann, also so richtig voll und ganz und nicht per Pseudo-0rpm-Lüftermod. Auch der Ausgang auf dem Board sollt mMn. 2015 in der Lage sein die paar Bildchen (2MP@+60HZ) noch mit auszugeben. Dann braucht es auch keine zusätzliche Strippe mehr nur weil man die GPU's aus zb. Effizienzgründen wechseln möchte.

Haldi · 4. Mai 2015

G3cko schrieb:
Ich glaube nicht, dass unbedingt der Delay spürbar höher ist. Mehr fps deutet auch zwangsweise kürzere Zeiten zwischen den Frames. Es wird ja ohnehin alles in Echtzeit berechnet. Bitte korigiert mich wenn ich einen Denkfehler habe.

Sieht man doch so wunderschön in der Grafik, du hast rund 20ms zusätzlicher inputLag, den du ohne diesen Modus nicht hättest, dafür hast du 40 anstatt 36 FPS.

G3cko schrieb:
Das stimmt. Je höher die fps jedoch sind, desto geringer müsste der Inputlag sein.

die FPS? die FPS von was?
Die beiden GPU's berechnen das unabhängig voneinander!
Einzig wenn du die Auflösung änderst ist die Performance von beiden betroffen, wenn du hingegen die Details oder Texuten änderst ist blos die nVidia GPU betroffen und die intel iGPU rechnet immer noch genau gleich schnell, wenn du nun über 27ms (aka 36 FPS) kommst dann bremst dich die iGPU plötzlich aus, und dann musst du zwangsläufig auch PostProcessing filter wie AA herunter schrauben.
Wenn du nun nur PostProcessing filter reduzierst wird damit auch der Input Lag kleiner, ja.

News DirectX 12: Mit „Multiadapter“ rendern Grafikkarte und IGP zusammen

Lieutenant

Rear Admiral

Fleet Admiral

Lt. Commander

Fleet Admiral

Lieutenant

Banned

Lt. Commander

Lieutenant

Admiral

Banned

Lieutenant

Banned

Lt. Commander

Lt. Commander

Lieutenant

Lt. Commander

Captain

Banned

Admiral

Ähnliche Themen