DirectX 12 Multiadapter vorgestellt: Grafikkarte und integrierte Grafikeinheit berechnen das Bild gemeinsam

Das ganze ist doch nur für die untere Mittelklasse interessant. Eine GTX 750 oder eine R7-260 ein bisschen anzuschubsen sollte man durchaus in FPS wiederfinden.
Bei schnelleren GPU ist das meiner Meinung nach unnötig. Dann lieber einen Xeon oder einen FX ohne IGPU und das gesparte Geld in eine bessere GPU stecken.
Dafür gibt es doch extra die CPUs OHNE IGPU oder APU
 

ich möchte an Punkt hinweisen, das der i5 ca 260 Euro kostet. während du bei AMD nur 130 zahlst, stimmt aber ich den i5 übersehen
 
DirectX 12 Multiadapter vorgestellt: Grafikkarte und integrierte Grafikeinhei...

Das ganze ist doch nur für die untere Mittelklasse interessant. Eine GTX 750 oder eine R7-260 ein bisschen anzuschubsen sollte man durchaus in FPS wiederfinden.
Bei schnelleren GPU ist das meiner Meinung nach unnötig. Dann lieber einen Xeon oder einen FX ohne IGPU und das gesparte Geld in eine bessere GPU stecken.
Dafür gibt es doch extra die CPUs OHNE IGPU oder APU

Das sehe ich anders. Ein Core i5/i7 in Kombination mit einer High-End Grafikkarte, wo dann auch die integrierte GPU sinnvoll genutzt wird, finde ich durchaus reizvoll.
 
Zuletzt bearbeitet:
AW: DirectX 12 Multiadapter vorgestellt: Grafikkarte und integrierte Grafikeinhei...

Da sehe ich anders. Ein Core i5/i7 in Kombination mit einer High-End Grafikkarte, wo dann auch die integrierte GPU sinnvoll genutzt wird, finde ich durchaus reizvoll.
Reizvoller fände ich eine CPU mit integrierter GPU, die eine zusätzliche Grafikkarte überflüssig macht. FX und R9-270 oder i5 und GTX 960 in einem Chip oder als Doppelchip auf einer Karte mit einem Kühler wäre soviel Platzsparender.
 
AW: DirectX 12 Multiadapter vorgestellt: Grafikkarte und integrierte Grafikeinhei...

Reizvoller fände ich eine CPU mit integrierter GPU, die eine zusätzliche Grafikkarte überflüssig macht. FX und R9-270 oder i5 und GTX 960 in einem Chip oder als Doppelchip auf einer Karte mit einem Kühler wäre soviel Platzsparender.

Problem: Wärmeabfuhr ;) Schon einzeln sind ja eine potente GPU und eine Highend-CPU schwer leise zu kühlen. Wenn die Verlustleistung beider auf engstem Raum anfällt, hilft nur noch eine Wasserkühlung. Oder ein Luftkühler, der bläst wie ein Föhn :ugly:
 
Vielleicht kann man euch beide, Rollora und Locuza ja doch zusammenbringen? DX 12 ist keine reine API, sondern eine umfangreiche Bibliothek mit Befehlen, der reine API-Part ist D3D12 ^^
Somit könntet ihr beide Recht haben, die Bibliotheken von DX 12 ließen sich sicherlich um eine grundliegende, nicht proprietäre Physik-/KI-Engine erweitern. Ob Microsoft allerdings Interesse an einem solchen Aufwand hätte und ob das nicht viel mehr Probleme nach sich zieht, die dann MS wieder für alle Spieler verbrochen hätte, steht auf einem anderen Blatt...
 
AW: DirectX 12 Multiadapter vorgestellt: Grafikkarte und integrierte Grafikeinhei...

Problem: Wärmeabfuhr ;) Schon einzeln sind ja eine potente GPU und eine Highend-CPU schwer leise zu kühlen. Wenn die Verlustleistung beider auf engstem Raum anfällt, hilft nur noch eine Wasserkühlung. Oder ein Luftkühler, der bläst wie ein Föhn :ugly:
Sicher wäre es unter dem Aspekt sinnvoll, wenn ich Leistungen von CPU und GPU vergleiche, wieder etwas mehr Berechnung von der GPU an die CPU zurückzugeben, damit man zwei ähnlich belastete System bekommt. Aber mit zunehmender Effizienz kann auch eine Zusammenführung der Einheiten Ziel sein. Ich finde die Entwicklung jedenfalls extrem spannend und freue mich über jede neue Generation leistungsstärkerer Prozessoren.

Wenn ich an die ersten Anfänge zurückdenke, immerhin besaß ich als Kind eine Telefunken Spielekonsole, mit dem man über ein Drehpoti einen weißen Balken auf schwarzem HIntergrund eindimensional bewegen konnte und man alleine oder, Achtung, Multiuser, mit zwei Spielern einen wenige Pixel großen Ball hin und her spielen konnte, dann sind heutige Simulationen unerträglich klasse. Wir sind so dicht vor gut wirkenden "Hologrammrealitäten". Ich seh schon die Brille und das Herumlaufen wo auch immer mit realistisch wirkender Simulation unter Einbeziehung der realen Umgebung in die Simulation. Sowas haben wir vor zehn Jahren schon in der Automobilforschung zum Entwickeln von Bedienkonzepten gemacht. Die Verknüpfung von wenigen realen Elementen mit simulierter VR. Und man taucht ein, faßt reales an, sieht es mit Handtracking in der Simulation und kann ganz real mit Haptik bewegen. GTA VI mit einem Autositz, Lenkrad, und Pedalerie im Beschleunigungskräfte simulierendem Käfig rückt immer näher.

Träumend, phantasierend, freuend...... DirectX 12 ist ein kleiner aber wichtiger Schritt dahin.
 
AW: DirectX 12 Multiadapter vorgestellt: Grafikkarte und integrierte Grafikeinhei...

@ Bevier

Also eine middleware unter DX12.
Aus gewissen Gründen, würde ich das aber lieber trennen.

Und yeah, ich glaube nicht das MS Lust darauf hat kostenlos für alle zu programmieren.
 
Also ich weiß wiederum nicht, was es so schwer macht meinen Standpunkt zu verstehen.

Meine Aussage ist letztendlich nicht, dass ich keine coole Physik/KI-Bibliothek mit einfacher Lastenverteilung und Device Zuteilung haben möchte, sondern einfach, dass dies nicht die Aufgabe bei der Spezifizierung einer API ist.
Eine API spezifiziert in erster Linie nur die Kommunikation und damit letztendlich die Möglichkeiten.
Das ist eine klare und logische Aufgabe.
Das bläht man dann natürlich nicht zu einer Middleware auf bzw. so einem Zwitter aus API/Library.
Meine Frau gibt dir recht: ich kapiere heute gar nix.

Dann sag' ich mal, ich hab dich falsch verstanden und mich selbst nicht gut ausgedrückt: Ich meinte, dass die API das ganze ordentlich vereinfachen könnte, wenn diese Dinge ordentlich spezifiziert sind (KI, Physik). Natürlich ist die Verteilung dann Aufgabe der Engine (etc).
Sorry, wenn ich mich ungeschickt ausgedrückt hab oder dies weiterhin sollte. Bist nicht der einzige der davon heut' genervt ist ;)
@ Bevier

Also eine middleware unter DX12.
Aus gewissen Gründen, würde ich das aber lieber trennen.

Und yeah, ich glaube nicht das MS Lust darauf hat kostenlos für alle zu programmieren.


Natürlich nicht. Aber wenn prinzipiell schon mal definiert ist, wie eine Sache funktionieren sollte, ist es für Entwickler leichter, diese einzusetzen (prinzipiell schon mal die Idee von APIs...) und mir geht DX seit Jahren zu wenig weit: dachte schon in DX10 kommt eine Physik/KI API hinzu.
Wo jetzt genau definiert ist, wie die Lasten verteilt werden (WDDM?), also ob man das nun auf die CPU, iGPU oder GPU (etwa bei OpenCL) berechnen lässt, weiß ich leider nicht (hab' zuletzt 2000 mit einer API für Grafikkarten gearbeitet und das war GLIDE) - ist nicht mein Metier. Ich dachte es war ungefähr klar, was ich gemeint hab, aber wie oben schon erwähnt, heute quäle ich mich durch halb-Exaktheiten weil mein Hirn nach einer weiteren 80h Woche wohl etwas kaputt ist und ich mal Urlaub brauch'
 
Zuletzt bearbeitet:
Ich denke was du willst ist einfach eine Middleware (Zwischenschicht) wie PhysX von Nvidia.

APIs sollen im Grunde nur Dinge ermöglichen, indem sie natürlich paar Sachen abstrahieren und vereinfachen.
Bei einer API geht es doch nur darum, dass du leicht und effizient das ausdrücken kannst, was du möchtest.

Da verstehe ich vielleicht dein Problem mit DX10.
Ältere OGL und DX-Versionen haben es dem Programmierer nicht leicht gemacht GPGPU auf der GPU zu betreiben, weil das ganze Layout an 3D-Rendering ausgerichtet war.
Du hattest praktisch ein Korsett, wo du dich nicht frei ausdrücken konntest und dumme Umwege und Daten-Layouts verwenden musstest, damit du das Zeug berechnen kannst, welches du willst.

DX11 würde ich hier aber als eine GPGPU-API bezeichnen, worunter eben auch Physik/KI fallen.
Dank der DirectCompute-API kannst du dich jetzt viel freier ausdrücken und direkter die Daten berechnen die du möchtest.
In die gleiche Kerbe schlagen CUDA und OpenCL.

Die Lasten verteilt der Programmierer selber, indem er die entsprechenden Routinen in seiner Engine schreibt.

WDDM ist ein Teil vom ganzen Prozess.
Es ist ein integraler Teil von der Funktionsweise zwischen Treiber und der DX-Runtime.
Z.B. wie wird der Speicher verwaltet.

Um es mal wieder zusammen zu fassen.
PhysX ist eine Physik-Middleware, wo Nvidia für die GPU-Beschleunigung einfach die API CUDA verwendet, um eben das zu erhalten was man so will.
Rauch-Simulation, Partikel-Effekte usw.
 
Ich denke was du willst ist einfach eine Middleware (Zwischenschicht) wie PhysX von Nvidia.

APIs sollen im Grunde nur Dinge ermöglichen, indem sie natürlich paar Sachen abstrahieren und vereinfachen.
Bei einer API geht es doch nur darum, dass du leicht und effizient das ausdrücken kannst, was du möchtest. .
Dann ergibt es halt doch wenig sinn, dass DX10 bei gleichen Befehlen wie DX9 schneller ist. Oder halt DX12 zu 11.
Da muss dann ja auch schon Middleware mit drin sein, der MÖGLICHE zusätzliche Hardwarezugriff wars bei 9-> 10 ja nicht, oder?
Oder war da "noch" eine Abstraktionsschicht drüber, die bei DX10 entfernt wurde?

Da verstehe ich vielleicht dein Problem mit DX10.
Ältere OGL und DX-Versionen haben es dem Programmierer nicht leicht gemacht GPGPU auf der GPU zu betreiben, weil das ganze Layout an 3D-Rendering ausgerichtet war.
Du hattest praktisch ein Korsett, wo du dich nicht frei ausdrücken konntest und dumme Umwege und Daten-Layouts verwenden musstest, damit du das Zeug berechnen kannst, welches du willst.

DX11 würde ich hier aber als eine GPGPU-API bezeichnen, worunter eben auch Physik/KI fallen. .
Demnach war schon immer alles möglich, mit DX12 wirds halt dann "leichter" möglich. Ähnlich wie DX9 -> 10?
Dank der DirectCompute-API kannst du dich jetzt viel freier ausdrücken und direkter die Daten berechnen die du möchtest.
In die gleiche Kerbe schlagen CUDA und OpenCL.
.
ja, so habe ich es immer verstanden. Und das meinte ich eben mit "mir geht der DX12 Ansatz noch nicht weit genug"
Ich meinte damit, diverse Dinge sollten schon "vorgekaut" werden. Ähnlich einer Middleware - ja.
Aber wenn es nur Tür und Tor öffnet, für weiter verbesserte Middlewares, solls mir recht sein.
Es soll halt dann auch überall laufen, sprich nicht proprietär sein. Der Grund warum in Spielephysik seit 10 Jahren quasi nix passiert, ist doch zum Großteil der proprietäre Ansatz eines PhysX und weil Havok nie deren GPGPU Ansatz "Havok FX" released haben (das ginge jetzt mit Compute Shader bzw Open CL ja aber doch und man wäre direkte Konkurrenz zu GPU PhysX).
Die Lasten verteilt der Programmierer selber, indem er die entsprechenden Routinen in seiner Engine schreibt.
.
Oder eben middleware verwendet, soweit ich das nun verstehe
WDDM ist ein Teil vom ganzen Prozess.
Es ist ein integraler Teil von der Funktionsweise zwischen Treiber und der DX-Runtime.
Z.B. wie wird der Speicher verwaltet.
.
Eben und somit auch, welche Hardware auf welchen Speicher zugriff hat. Wenn also CPU und GPU Physik gemeinsam berechnet werden soll und das eventuell über die iGPU läuft oder eben GPU kann dies durchaus von WDDM und DX12 beeinflusst sein bzw vereinfacht werden. Das hab' ich zum Teil gemeint. Das muss deppeneinfach und sicher werden, dass es in Zukunft jede Engine verwendet.
Ich will mehr Physik als Spielelement sehen (etwa im Half Life 2 Ansatz, nur halt... naja weiter) sowie mehr mögliche bzw einfacher zu implementierende KI.
Die Fortschritte auf diesem Gebiet sind in den letzten 10 Jahren nicht sichtbar: 2004 war ich über KI in Far Cry erstaung (Gegner haben dich entdeckt, sich leise gegenseitig alarmiert und dich dann heimlich umzingelt usw usf). Und auch bei Fahrer-KI in Rennspielen (Gummiband :( ) könnte man wieder mal "intelligenter" agieren, da gabs auch vor 10 Jahren schon besseres.
Um es mal wieder zusammen zu fassen. .
Ich mag Conclusios
PhysX ist eine Physik-Middleware, wo Nvidia für die GPU-Beschleunigung einfach die API CUDA verwendet, um eben das zu erhalten was man so will.
Rauch-Simulation, Partikel-Effekte usw.
Jepp soweit hab ich das verstanden ;)
Ok ich will dann halt keine Middleware, aber irgendwie doch schon einiges an Vordefiniertem in DX.
Oder, wenn das nicht will, dann halt, dass "Bullet" oder eine andere Open Source Physikengine den Durchbruch schafft und die Lasten dynamisch zwischen CPU und iGPU verteilt, damit die hohe Leistung letzterer endlich genutzt wird.

Btw andere Frage: ist es möglich OpenCL und DX gleichzeitig zu verwenden oder schließt es sich aus praktischen Gründen aus (wie OpenGL und gleichzetitig Direct 3D?
 
Btw andere Frage: ist es möglich OpenCL und DX gleichzeitig zu verwenden oder schließt es sich aus praktischen Gründen aus (wie OpenGL und gleichzetitig Direct 3D?

Habe da grad weder eine Quelle noch ein Detailwissen, aber meines Wissens sollte das im Prinzip gehen. Es gibt ja zumindest Bestrebungen/Überlegungen, Physik-Effekte und solche Sachen per OpenCL auf der GPU berechnen zu lassen. Das darf im Prinzip die gleiche GPU sein, die gerade das eigentliche Bild berechnet, so lange sie genügend Leistung für beide Aufgaben gleichzeitig hat. DX und OpenCL können sich also zeitgleich in eine GPU "reinteilen", wenn ich das richtig verstehe. Denn zwischen DX/OpenCL und der GPU sitzt ja noch immer der Treiber, und der ist wohl in der Lage, das zu managen.

Korrigiert mich, falls es nicht stimmt :)
 
Dann ergibt es halt doch wenig sinn, dass DX10 bei gleichen Befehlen wie DX9 schneller ist. Oder halt DX12 zu 11.
Da muss dann ja auch schon Middleware mit drin sein, der MÖGLICHE zusätzliche Hardwarezugriff wars bei 9-> 10 ja nicht, oder?
Oder war da "noch" eine Abstraktionsschicht drüber, die bei DX10 entfernt wurde?
DX9 --> DX10 hatte eine Reihe von Veränderungen.

Die API ist letztendlich auch nur Software, welches Konstrukte und Konzepte definiert, mit der dazu passenden Shader-Sprache.
Je nachdem wie die API aufgebaut wird, wird mal mehr oder weniger abstrahiert und eine Abstraktion ist immer das verbergen von spezifischen Details und alles selber machen.
Aber die Sachen verschwinden nicht, dass erledigt dann jemand anderes.
Sei es der Treiber und da gibt es User-Mode-Drivers, Kernel-Driver, WDDM welches da irgendwo dazwischen alles steuert, übergreifend das Betriebssystem.
Und die API-Runtime selber.
Mit einer neuen Version kann man vieles updaten und etwas anders definieren.

DX10 hat z.B. das Treiber-Modell vollkommen geändert, Vista war die Geburtsstunde von WDDM.
http://www.beyond3d.com/images/articles/D3D10XP/D3D10onXP2-big.png

Toller Artikel:
Beyond3D - Will Direct3D 10 ever come to Windows XP?

Was DX10 mitunter auch effizienter macht, ist eine andere Abstraktionsform.
State-Objects wurden eingeführt, welche wenn ich das richtig verstehe, die Zustände bündeln und jedes mal wenn du etwas änderst, du insgesamt nur die objekte ändern musst, aber nicht jeden einzelnen Zustand.
Dann muss die CPU weniger ackern.

So eine Übersicht an Features und Veränderungen findest du bei MS selber:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb172268(v=vs.85).aspx

Demnach war schon immer alles möglich, mit DX12 wirds halt dann "leichter" möglich. Ähnlich wie DX9 -> 10?
Kommt natürlich darauf an, was du mit "alles möglich" meinst, aber allgemein heißt die Antwort nein.
Wir haben mittlerweile moderne APUs, die sich Speicher teilen, dass Konzept von shared-memory kennt DX11 und früher gar nicht.
Wie du später selber sagst, dass ist natürlich ein sehr wichtiger Teil.
Das ist ein Teilgrund warum unser Traum von iGPUs einsetzen überhaupt ermöglicht wird.
Dieser ganze copy-overhead der früher definiert wurde, weil er musste es dank der Hardware auch, ist nun Vergangenheit.
Wobei natürlich nur theoretisch, irgendjemand muss es umsetzen und erst Kaveri und Haswell (Broadwell eher und Skylake erst recht) sind modern genug.

DX12 ist eine kleine Bibel an sich, da ändern sich viele Dinge, sehr krass.
Also da gibt es viele Sachen die nun deutlich effizienter laufen und erst dadurch Sinn machen.
Egal ob Rendering, ROVs, Conservative Rasterization, Tiled Resources for Volumes oder Computing, mit expliziter Speicherverwaltung, Multi-Engine für mehrere Befehlsschlangen auf einmal oder für die CPU mit echtem Multi-Threading Konzept.
WDDM2.0 gibt es auch noch, was den Overhead für vieles senkt.

Es soll halt dann auch überall laufen, sprich nicht proprietär sein. Der Grund warum in Spielephysik seit 10 Jahren quasi nix passiert, ist doch zum Großteil der proprietäre Ansatz eines PhysX und weil Havok nie deren GPGPU Ansatz "Havok FX" released haben (das ginge jetzt mit Compute Shader bzw Open CL ja aber doch und man wäre direkte Konkurrenz zu GPU PhysX).
Seit DX11 ginge vieles theoretisch auch.
Wird letztendlich auch gemacht.
HairWorks, DirectCompute, VGXI (Diese Globale Beleuchtung mit Voxeln) DirectCompute, GodRays, DirectCompute.
AMD hat TressFX, DirectCompute, sie haben so ein Partikel-Sample und Rauch Zeug, DirectCompute.
Und mit OpenCL könnte man da noch mehr machen, als mit DX11.
(Bei OCL 2.1 vs. DX12 Compute, ich glaube da ist OCL leider weiterhin vorne.)

Bloß das ist halt verdammt aufwendig, so eine Physik-Bibliothek zu erstellen. Außer Havok, PhysX und Bullet und so Kriechzeug kenne ich nicht viel.
Enlighten ist eine Middleware für Beleuchtung, setzt die Frostbite-Engine ein, ich glaube sogar auch die UE4.
Da sieht man einfach, dass Zeug haben wir nicht, weil es nicht möglich wäre, sondern weil es "niemand" macht, wegen Aufwand/Kosten oder sonstigem.

Oder eben middleware verwendet, soweit ich das nun verstehe
Oder das. Aus Browser-Sicht könnte man zu einer Middleware ja auch Plugin sagen.
Du steckst etwas rein, was du haben möchtest.

Das muss deppeneinfach und sicher werden, dass es in Zukunft jede Engine verwendet.
Deppeneinfach ist explizite Kontrolle sicher nicht.
Deswegen läuft DX11 und OpenGL weiter, weil DX12 und Vulkan nichts für "Amateure" sind.
Mal sehen, wie mutig und wie gut die Umsetzungen sein werden.

Ich will mehr Physik als Spielelement sehen (etwa im Half Life 2 Ansatz, nur halt... naja weiter) sowie mehr mögliche bzw einfacher zu implementierende KI.
Ich bin da ehrlich gesagt auch schockiert. Havok ist ja nicht weg vom Fenster und PhysX entwickelt sich auch immer weiter.
Mir fehlt aber das Gefühl, eine Mauer überwunden zu haben, wo man denkt, endlich kann ich wenigstens paar Mauern explodieren lassen oder endlich läuft die K.I. nicht in einer Routine.
Ich erinnere mich da nur an PS1/PS2 Spiele mit Red-Faction, wo man fast alles kaputt machen konnte oder Vigilante 8, wo der ganze Boden mit den Vertex-Meshes geformt wurde.
Das sehe ich in modernen Spielen nicht mehr, sogar Rückschritte auf gewissen Gebieten.
Aber hey, die Grafik ist besser geworden...

Btw andere Frage: ist es möglich OpenCL und DX gleichzeitig zu verwenden oder schließt es sich aus praktischen Gründen aus (wie OpenGL und gleichzetitig Direct 3D?
Möglich ist es, aber ich vermute es gibt dort Gründe, weswegen man es lieber vermeidet.
Es sind unterschiedliche APIs, entsprechend sieht auch beides unterschiedlich aus und generiert spezifische API-Objekte und Ressourcen.
Zusätzlich ist der Support ein Problem
*hust* Nvidia *hust*

Nvidia stellt aber natürlich auch ein Gegenbeispiel dar, CUDA für PhysX.
Aber da macht es Nvidia es einem natürlich einfacher, PhysX ist eine fertige Middleware, rein damit und das läuft dann irgendwie.
Nvidia hat sich darum gekümmert.
Außerhalb davon, haben wir aber ebenso CUDA fast nie für Spiele gesehen.
RAGE hat CUDA mal für GPU-Transcodierung benützt, Just Cause 2 glaube ich für Wasser und dann fällt mir nicht viel mehr ein. (Noch so ein Zweite Weltkrieg FlugzeugSpiel, was erst(?) kommt, auch glaub für Wasser)
 
Zuletzt bearbeitet:
Ich bin ja gespannt wie das Ganze in Sachen Mikrorucklern aussieht...
Wenn das da die Probleme hinter sich lässt wäre das auch eine Lösung für SLI und Crossfire Systeme
(Oder halt Split Frame Rendering einsetzen, Notfalls auch das alte Scan Line Interleave von 3dfx) Das heutige AFR wird ja nurt genutzt, um Tearing zu verringern und wegen der einfachen Umsetzung (Da müssen die Karten wie auch im Einzelbetrieb einfach abwechselnd ein Bild rendern.

Und der komische Lusid Virtu Kram läuft auch nicht richtig, manchmal wird die Performance sogar reduziert. Von Kompatibilitäts- und Stabilitätsproblemen mal ganz abgesehen.
 
DirectX 12 Multiadapter vorgestellt: Grafikkarte und integrierte Grafikeinhei...

Ich bin ja gespannt wie das Ganze in Sachen Mikrorucklern aussieht...
Wenn das da die Probleme hinter sich lässt wäre das auch eine Lösung für SLI und Crossfire Systeme

Da beide GPUs dasselbe Bild berechnen, wird es keine Mikroruckler geben.
 
Für paar Sekunden war es auf jeden Fall nicht da, aber nach F5 ging es wieder. :ugly:

Ich glaube, ich habe hier ein Beispiel was viele nicht kennen:
https://www.youtube.com/watch?v=2ktG7QX2BH4

http://www.extremetech.com/wp-content/uploads/2014/07/GrassFX-640x262.jpg

Eine GrassFX Demo von AMD, wo die iGPU das Computing übernimmt.
Bringt selbst bei der 290 ganze 9%. %-)

Im Video 5770 + 7800 (OpenCL Compute).
5770 = 16 FPS
dGPU + iGPU = 23 FPS. (+43%)
Doch das kenn' ich noch.
Drum würds mich freuen, wenn das mehr genutzt wird
Ich bin ja gespannt wie das Ganze in Sachen Mikrorucklern aussieht...
Wenn das da die Probleme hinter sich lässt wäre das auch eine Lösung für SLI und Crossfire Systeme
(Oder halt Split Frame Rendering einsetzen, Notfalls auch das alte Scan Line Interleave von 3dfx) Das heutige AFR wird ja nurt genutzt, um Tearing zu verringern und wegen der einfachen Umsetzung (Da müssen die Karten wie auch im Einzelbetrieb einfach abwechselnd ein Bild rendern.

Und der komische Lusid Virtu Kram läuft auch nicht richtig, manchmal wird die Performance sogar reduziert. Von Kompatibilitäts- und Stabilitätsproblemen mal ganz abgesehen.
Hmm also SLI im 3dfx Sinne ist heute nicht mehr wirklich möglich.

Ein guter Artikel bezüglich aktueller Lage zu Microlags ist hier zu finden:
Nvidia's SLI Technology In 2015: What You Need To Know - Introduction

Also gibt nur noch wenige Szenarios wo es laggt. Ist halt bei Multi-GPU immer eine Frage des Herstellersupports.
In Mantle waren die Frameraten auch 100% stabil. Bleibt zu hoffen, dass sich das auch bei Vulkan so verhält. Und natürlich DX12.
Da die her verwendete Methode aber so aussieht, dass die iGPU dasselbe Bild berechnet, wirds wohl deutlich weniger "Framerateininstabil" sein.
 
Zurück