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

Daedal schrieb:

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.

Zum Vergrößern anklicken....

Locuza schrieb:

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.

Zum Vergrößern anklicken....

Ich habe das jetzt auch so verstanden, dass DX12 hier gerade heterogene GPUs gut zusammenbringen kann. Dabei ist heterogen nicht nur auf die Leistungsfähigkeit bezogen, sondern auch die Chip-Hersteller (sofern diese aus (Arroganz-)Gründen es nicht boykottieren).

Faust2011 schrieb:

Ich habe das jetzt auch so verstanden, dass DX12 hier gerade heterogene GPUs gut zusammenbringen kann. Dabei ist heterogen nicht nur auf die Leistungsfähigkeit bezogen, sondern auch die Chip-Hersteller (sofern diese aus (Arroganz-)Gründen es nicht boykottieren).

Zum Vergrößern anklicken....

Naja, leider wäre genau dies von zumindest einem zu befürchten. Welcher? Na, schaut mal in meine Sig. ...

Nicht schlecht die Technik, solange keine mikroruckler auftreten. Auch lustig, die 0815 WLP Intel CPUs werden schön vor sich hinglühen, vor allem die OC wenn die GPU auch noch rödeln darf. Fazit: Tests braucht das Land.

Ich finde die IGP ist viel sinnvoller genützt wenn man in einem Strategiespiel zum Beispiel die Ki von Figuren verbessern könnte. Ich denke da besonders an Wegpunkte und ähnliches.
Es gibt nichts ärgerliches, als wenn man Einheiten zu einem Punkt schickt und diese dann an einer Stelle "stecken" bleiben weil die Figuren gleichzeitig durch eine Enge wollen.


unter dem Link mehrere Beispiele :
http://de.slideshare.net/zlatan4177/gpgpu-algorithms-in-games

Für mich ist das hier nur eine der Anwendungen, die mit DX12 und anderen low level API möglich werden. Also werden Entwickler wesentlich mehr Methoden haben um Games "besser" zu machen. Es muss nicht unbedingt immer nur um FPS gehen.

Faust2011 schrieb:

Ich habe das jetzt auch so verstanden, dass DX12 hier gerade heterogene GPUs gut zusammenbringen kann. Dabei ist heterogen nicht nur auf die Leistungsfähigkeit bezogen, sondern auch die Chip-Hersteller (sofern diese aus (Arroganz-)Gründen es nicht boykottieren).

Zum Vergrößern anklicken....

Da es zum API Standard gehört, wird sich da vermutlich kein Widerstand auftun.
Das Beispiel in der News funktioniert ja mit Nvidia + Intel.

G3cko schrieb:

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

Zum Vergrößern anklicken....

Das stimmt so nicht ganz.

Beispiel 1: Spiel @60 fps mit Inputlag von x
(Extrem-)Beispiel 2: Spiel @1000fps, aber ein 5km langes Monitorkabel. Trotz mehr Bilder pro Sekunde kommen diese deutlich später am Bildschirm am (--> Inputlag)

Es ist schon richtig, dass höhere fps durchaus die Zeit von der Eingabe bis zum Bild auf dem Bildschirm verringern - das heißt aber nicht, dass die Ausgabe an irgendeiner Stelle nochmal etwas in der Zeit versetzt werden kann. Wenn sich jetzt z.B. ein fertig gerendertes Bild noch unnötig lange zwecks Post-Processing "in der iGPU befindet" (einfach gesagt), dann addiert sich die "Verweilzeit" dort auf den Inputlag, in dem Fall der Grafik von Microsoft um knapp 20ms.

falls jemand das witch video in guter quali sehen will (zumindest zeigt bei mir der cb player auch in hd noch deutliche artefakte), hier kann mans runterladen:
http://www.chip.de/downloads/DirectX-12-Demo-Witch-Chapter-0-Cry_78888929.html

cbtestarossa schrieb:

Muss das eigentlich die Spiele Engine können oder kann man Tesselation/Truform auch erzwingen?

Zum Vergrößern anklicken....

Truform konnte man damals erzwingen was dann in cs zu bananenwaffen führte und eine ganze generation von autoentwicklern inspiriert hat


Die idee die igp zu nutzen ja toll, nur leider nicht umsetzbar in schnellen games wegen dem inputag.

SoilentGruen schrieb:

Seit 10 Jahren spricht man davon, schon 1000 Mal gehört... HybridSLI oder HybridCrossfire... lief nichts von stabil.

Ich bin da ziemlich skeptisch, aber wenns klapp, wäre es ne super Sache.

Verlieren die K-Prozessoren von Intel dann an Attraktivität?
Auf jeden Fall würde das eine Menge Auftrieb für AMD bieten, denn deren CPU-Grafik ist schon ziemlich potent und könnte bei einer Mittelklassenkarte durchaus eine Verdopplung bewirken.

Zum Vergrößern anklicken....

Was haben die K CPUs von Intel damit zu tun? Denkst nur weil es das gibt will niemand mehr übertakten?
Wenn dann würde es CPUs ohne IGP betreffen und die sind im consumer Bereich sowieso rar gesäht.
Ich denke eher das es, wie du auch gesagt hast, nicht gscheit funktionieren wird wie damals Hybrid CF und GeForce Boost.
Und die meisten die ich kenne haben die IGP auch deaktiviert da sie gar kein Mainboard haben das die IGP nutzen kann (also Grafikausgänge hat) und deshalb deaktivieren es die meisten die ich kenne da es nichts bringt außer einer zusätzlichen Fehlerquelle.

h00bi schrieb:

Nicht schlecht, ich würde mir aber immer noch die Lösung wünschen dass die CPU Grafik die Ausgabe übernimmt und die Graka als reines Rechenmonster arbeitet.

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

Zum Vergrößern anklicken....

Das wäre ja dann extrem lahm da die IGP die Daten via PCIe erst zur GPU schieben muss und dann die GPU die Daten via PCIe Bus wieder zur IGP zurück schieben muss für die Bildausgabe und da hat man ein enormes BB Problem. Das würde mit der momentanen Technik langsamer werden als es jetzt läuft. Damit das gut funktioniert müsste man die "richtige" GPU direkt via eines BUS mit enormer Speicherbandbreite mit der IGP verbinden, dafür reicht der normale PCIe bei weitem nicht aus.

Chesterfield schrieb:

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

Zum Vergrößern anklicken....

Ja es findet sich in sehr vielen Mainboards wieder nur wird es nicht mehr explizit vermarktet! Aber es ist bei weitem nicht weg vom Fenster sondern es steht nicht mehr so in der Öffentlichkeit. Du findest es auf Mainboards von Intel oder von MSI, ASUS, Asrock und Gigabyte. Es wird aber nicht mehr explizit beworben.

schön wäre es ja wenn man die igpu für physix berechnungen einsetzen könnte ...

blöd nur das nvidia auf so nem egotrip ist

Da es zum API Standard gehört, wird sich da vermutlich kein Widerstand auftun.

Zum Vergrößern anklicken....

Die Frage ist, ob das Feature irgendwie explizit ins API eingebaut wurde oder ob Microsoft hier einfach nur eine gute Idee hatte, was man mit der neuen Schnittstelle so alles machen kann. Denn prinzipiell möglich sein wird soetwas mit jeder Schnittstelle, die einen explizit verschiedene GPUs ansprechen lässt.

moshkopp schrieb:

schön wäre es ja wenn man die igpu für physix berechnungen einsetzen könnte ...

blöd nur das nvidia auf so nem egotrip ist

Zum Vergrößern anklicken....

Wie ist denn nun der konkrete Stand bei PhysX? Da hieß es doch vor kurzem, dass der Source frei zugänglich sei. Ist es nun noch proprietär oder nicht? Kann es auch auf einem System laufen lassen, das keine Nvidia-Komponeten enthält?

terraconz schrieb:

(...)
Das wäre ja dann extrem lahm da die IGP die Daten via PCIe erst zur GPU schieben muss und dann die GPU die Daten via PCIe Bus wieder zur IGP zurück schieben muss für die Bildausgabe und da hat man ein enormes BB Problem. Das würde mit der momentanen Technik langsamer werden als es jetzt läuft. Damit das gut funktioniert müsste man die "richtige" GPU direkt via eines BUS mit enormer Speicherbandbreite mit der IGP verbinden, dafür reicht der normale PCIe bei weitem nicht aus.

Zum Vergrößern anklicken....

Nicht zwingend. Sofern die dedizierte GPU die IGP bei Spielen komplett ablöst müssen die ganzen Daten wie bisher auch nur 1x bzw. bei Bedarf in den Grafikkartenspeicher geladen werden, die GPU kann anschließend unabhängig vom Hostsystem damit rechnen. Und am Ende muss man einfach den Framebuffer zurück zum Hostsystem kopieren.

Bei Full-HD ist ein Frame ca. 6 Mbyte groß, bei 60 fps sprechen wir also von 360 MByte/s bzw. 2.88 GBit/s. Bereits PCIe x16 in Version 2.0 hat eine Bandbreite von 16 GBit/s, wovon wir noch entfernt sind. Natürlich müssen da noch andere Daten durch, also den Framebuffer 60x pro Sekunde zurück zum Board zu kopieren würde schon etwas Bandbreite kosten - andererseits ist PCIe voll duplex-fähig, dh der Transfer zum Board beeinflusst den Transfer zur Grafikkarte in keinster Weise (und wenn man nicht gerade zwei Grafikkarten im System hat dann gehen die Daten gewöhnlich nur in eine Richtung, nämlich zur Grafikkarte hin).

Den ganzen VRAM-Inhalt ständig zwischen Host und Grafikkarte hin und her zu kopieren würde dagegen natürlich nicht funktionieren (bzw. das ganze System ausbremsen, deswegen versucht man das in der Praxis zB bei CUDA Berechnungen so gut es geht zu vermeiden*), ist aber gleichermaßen auch unnötig. Die Grafikkarte macht einfach ihr Ding und schickt das fertig gerenderte Frame zurück zum Board, wo es einfach nur noch in den Framebuffer gepackt wird. Die IGP macht in diesem Szenario allerdings nichts anderes als die Bildausgabe an den Bildschirm. Selbst was zu rechnen hat sie dagegen nicht.


*Generell lohnt es sich auch erst, auf der dedizierten Grafikkarte zu rechnen wenn die theoretische Rechenzeit auf der CPU die benötigte Transferzeit der Daten vom Host zur Grafikkarte und anschließenden Rücktransfer zum Host überschreitet.

Haldi schrieb:

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.

Zum Vergrößern anklicken....

DrToxic schrieb:

Das stimmt so nicht ganz.

Beispiel 1: Spiel @60 fps mit Inputlag von x
(Extrem-)Beispiel 2: Spiel @1000fps, aber ein 5km langes Monitorkabel. Trotz mehr Bilder pro Sekunde kommen diese deutlich später am Bildschirm am (--> Inputlag)

Es ist schon richtig, dass höhere fps durchaus die Zeit von der Eingabe bis zum Bild auf dem Bildschirm verringern - das heißt aber nicht, dass die Ausgabe an irgendeiner Stelle nochmal etwas in der Zeit versetzt werden kann. Wenn sich jetzt z.B. ein fertig gerendertes Bild noch unnötig lange zwecks Post-Processing "in der iGPU befindet" (einfach gesagt), dann addiert sich die "Verweilzeit" dort auf den Inputlag, in dem Fall der Grafik von Microsoft um knapp 20ms.

Anhang anzeigen 491197

Zum Vergrößern anklicken....

Eben...auch ganz einfach in der Grafik zu sehen. Die Frametime wird kürzer, doch dafür kommt die Kopierzeit dazu. Nun muss man erst mal die alte Frametime vergleichen mit der neuen Frametime+Kopierlatenz+Postprocessing. Erst wenn diese Zahlen zusammen länger sind als die ursprüngliche Frametime bei 30 FPS, dann entsteht ein ZUSÄTZLICHER Lag. Dieser ist aber bei weiten nicht so hoch wie nur die Zeit für das Kopieren und das Postprocessing, da ja auch Zeit eingespart wird auf der GPU und eben der Frame früher fertig ist und zur iGPU kopiert wird. Diese muss man wieder abziehen um auf den tatsächliche Inputlag zu kommen.

Dies führt logischerweise dazu, dass je schneller die diskrete GPU rendert im Verhältnis zur iGPU, desto höher wird der Inputlag. Je näher die beiden GPUs in der Leistung sich kommen und einen Sweetspot finden, wo das Kopieren und Postprocessing so schnell arbeitet, wie Zeit auf der dGPU eingespart wird, desto geringer der Inputlag.

Was bedeutet das für AMDs APU? Diese haben ja zusätzliche ACE um diese Art von Postprocessing zu beschleunigen, ebenso wie die diskreten AMD GPUs und die PS4. Sprich hier kann man davon ausgehen, dass der Inputlag auf AMD APUs deutlich nieriger wird Aufgrund ihrer Leistungsfähigkeit bei Postprocessing und auch ihrer allgemein höheren Leistung-plötzlich wird die iGPU ein wichtiger Faktor und hier vor allem das Leistungsdelta der beiden GPUs - Ausgewogenheit ist hier der Schlüssel.

denke auch daß das auf die Latenzeiten geht. ich habe lieber sehr direktes verhalten mit 36fps, anstatt schwammiges verhalten bei 40fps

Ich sehe keine Vorteile weil IGP sehr wenig Leistung hat.

Viel besser ist zwei verschiedene Grafikkarten zu betreiben,
Zb. GTX 970 und GTX 570 zusammen.

Das wird aber nie passieren, weil man dann nicht mehr so viele Grafikkarten verkauft.

Interessant wären die FPS-Steigerungen, hoffe das meine r9 290 noch nen schönen Schub bekommt.

whesker schrieb:

Ich sehe keine Vorteile weil IGP sehr wenig Leistung hat.

Zum Vergrößern anklicken....

iGPU ist ein Bereich, wo die Leistungssteigerungen noch deutlich sind. Da könnten sich folglich noch interessante, neue Einssatzszenarien auftun.

Schade das ich auf eine CPU ohne onboardgrafikeinheit gesetzt habe.

Schade? Nicht den Kopf hängen lassen Ich würde dieses Feature Multiadapter in Form von dedizierter Graka + iGPU eher als nice-to-have sehen. Extra jedoch ein System dahingehend auszurichten, da würde ich erstmal Praxistests abwarten.