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

[Rollora]

Es ist eben nicht die Aufgabe einer API, (eher/mehr) eine Bibliothek/Middleware darzustellen.
Ich mache es mal ganz krass, AMD bringt einen neuen und technisch modernen Treiber heraus und ich denke mir, netter Ansatz, aber das geht mir nicht weit genug.
Ich hätte bei meinem Treiber gerne ein Spiel dabei, damit der tolle Treiber gleich ausgenutzt wird.

Aha Dann mach ichs auch mal krass:
Damnach sind APIs sowieso völlig irrelevant, denn das eigentliche muss sowieso immer die Engine können.
Stimmt zwar, aber warum sich dann über DX, OpenGL, Vulcan, Glide, Mantle usw die Münder zerreißen.
APIs vereinfachen vieles, standardisieren vieles. Und darauf kann man dann eben aufbauen.
Wenn man sagt der Ansatz ist schon weit genug, dann back to Direct X 1 (ja EINS) und den rest machen die Entwickler schon, es kann schon alles.
Sorry, aber Entwickler sind halt oft faul, es muss halt doch irgendwo schonmal alles leicht verfügbar sein.

 

[Locuza]

APIs vereinfachen vieles, standardisieren vieles. Und darauf kann man dann eben aufbauen.
Wenn man sagt der Ansatz ist schon weit genug, dann back to Direct X 1 (ja EINS) und den rest machen die Entwickler schon, es kann schon alles.
Sorry, aber Entwickler sind halt oft faul, es muss halt doch irgendwo schonmal alles leicht verfügbar sein.

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.

 

[Pu244]

Sagen wir mal in 2, 3 Jahren, in ausgewählten Games, haben dann die kleinen i7 und i5 einen (kleinen)großen Vorteil ggü den großen Serverprozies, weil endlich seit Jahren vorhandene Power eingsetzt wird. Zugleich aber, lt Locuza, alle iGPUs vor Haswell/Kabini ausgeschlossen werden, weil die Architektur sich noch nicht dafür eignet?

Endlich wieder ein Grund doch die CPU aufzurüsten. Dachte schon DX12 lässt mich mit meinem i5 auf ewig vergammeln

Die große Frage ist wie gesagt ob dieses Feature überhaupt unterstützt wird oder ob es um sich eine nette Spielerei handelt die in der Versenkung verschwindet. Die Liste davon ist lang: PhysX Karten (nicht die GeForce, die Dinger davor), extra Videobescheunigerkarten, Lucid Virtu, der Soundram der X-Fi, Disketten mit hoher Speicherkapazität (Zip) usw.. Abgesehen davon bekommt man hier einen Leistungsvorteil von 12%, für den sie garantiert keine TitanX mit einem i5 mit schlechter iGPU gepaart haben und für den wohl einiges an Optimierungsaufwand besteht. Ich denke kein Entwickler wird sich die mühe machen für die paar Heinis (man muß die iGPU ja nichtnur haben sondern auch anschalten und konfigurieren, was wohl für 95% der Kandidaten zu komplex ist) wertvolle Kapazitäten abzustellen um so eine Sonderlösung zu unterstützen.

 

[majinvegeta20]

Schön und gut, aber ihr denkt auch daran, das nicht jeder der eine fixe CPU besitzt auch automatisch eine iGPU integriert hat?

Von Chipsätzen wie beispielsweise P67 usw. ganz abgesehen ^^

Daher sehr unwahrscheinlich das sich die einzelnen Entwickler die Mühe machen werden, bestimmten Arbeiten wie Physik oder KI per API auf die iGPU zu legen.
Während das Ganze auf dem normalen Weg auch noch klappen muss.

An sich finde ich zumindest die Idee dahinter nicht schlecht.

 

[Brehministrator]

Es geht doch nicht darum, die Physik "auf die iGPU zu legen". Es geht darum, eine Physik-Engine zu haben, die auf OpenCL aufbaut, so dass jeder Anwender selber entscheiden kann, ob er die Physik auf seine Haupt-GPU oder Physik-Beschleuniger-Karte (egal ob von AMD oder von Nvidia) oder auf seine iGPU oder auf die CPU oder worauf auch immer legt. Das wäre nämlich echt mal ein Fortschritt

 

[Locuza]

Schön und gut, aber ihr denkt auch daran, das nicht jeder der eine fixe CPU besitzt auch automatisch eine iGPU integriert hat?
[...]
Daher sehr unwahrscheinlich das sich die einzelnen Entwickler die Mühe machen werden, bestimmten Arbeiten wie Physik oder KI per API auf die iGPU zu legen.
Während das Ganze auf dem normalen Weg auch noch klappen muss.

Es kann natürlich "einfach" auch beides funktionieren.
Abfragen welche GPUs es im System gibt, bei zwei GPUs wird entsprechend die Arbeit verteilt, kommt nur eine GPU als Rückgabewert, muss die halt alles berechnen.
PhysX funktioniert schließlich auch auf nur einer GPU oder auf einer zweiten exklusiv.

Es geht darum, eine Physik-Engine zu haben, die auf OpenCL aufbaut, so dass jeder Anwender selber entscheiden kann, ob er die Physik auf seine Haupt-GPU oder Physik-Beschleuniger-Karte (egal ob von AMD oder von Nvidia) oder auf seine iGPU oder auf die CPU oder worauf auch immer legt. Das wäre nämlich echt mal ein Fortschritt

OpenCL oder DirectCompute oder sonst was.

Teile davon werden eh schon Angeboten, TressFX, HairWorks, VGXI etc.

 

[majinvegeta20]

Es kann natürlich "einfach" auch beides funktionieren.
Abfragen welche GPUs es im System gibt, bei zwei GPUs wird entsprechend die Arbeit verteilt, kommt nur eine GPU als Rückgabewert, muss die halt alles berechnen.
PhysX funktioniert schließlich auch auf nur einer GPU oder auf einer zweiten exklusiv.

Wenn das so simpel funktioniert, hab ich nichts gesagt. ^^

 

[Locuza]

Es kann so simpel funktionieren, es kann auch viel komplizierter funktionieren.
Wie immer kommt darauf an, was der Entwickler vorhat.

Max meinte bei seinem UE4 Beispiel, PP ist relativ unabhängig vom Rest und man kann es entsprechend simpel an die iGPU auslagern.
Laut eigener Aussage haben sie es auch relativ simpel umgesetzt.

Also ich denke, man sollte sich hier nicht vorstellen, das da 300 Leute wie Schweine 2 Monate gearbeitet haben, damit man am ende gerade mal 10% schneller wird.
Das war eine Demo, nur um zu zeigen, wie es grob funktionieren könnte.

 

[crys_]

Könnte man das Prinzip eigentlich theoretisch auch auf mehrere dedizierte GPUs anwenden? Damit wären ja Mikroruckler beseitigt...

 

[Locuza]

Kann man machen, muss man nicht machen.
Entsprechend sollte man da vorsichtig bei seinen Erwartungen sein.

 

[Cross-Flow]

Das wird eh nichts, wenn eine iGPU und eine dGPU werkeln ( in meinem angenommen Fall eine Geforce ), glaubt ihr wirklich g-Sync wird mit diesem Kuddelmuddel funzen? Das selbe bei AVsync. Kann ich mir schwer vorstellen das die da mitspielen ... Bei AMD iGPU und dGPu könnte es ja eventuell möglich sein ...

 

[Locuza]

Das ist ein guter Einwand.
Das verkompliziert natürlich Sachen.
Theoretisch könnte man es dennoch hinbekommen.

Der Monitor wird an die dGPU angeschlossen, die iGPU ist als Slave definiert und es gibt ein Copy-Back der Daten an die dGPU.
Die kann dann natürlich weiterhin mit ihrem Treiber und der Display-Engine dynamisch den Monitor bedienen.

 

[Cross-Flow]

Dieser "Copy-Back" an die dGPU findet ja eh statt, zuerst wird das Bild in der dGPu berechnet -> Daten zur iGPU -> PP drauf -> zurück zur dGPU und von da raus an den Moni. Aber wie gesagt, glaube kaum das NV da mitspielt

 

[burnbabyburn2]

Aha Dann mach ichs auch mal krass:
Damnach sind APIs sowieso völlig irrelevant, denn das eigentliche muss sowieso immer die Engine können.
Stimmt zwar, aber warum sich dann über DX, OpenGL, Vulcan, Glide, Mantle usw die Münder zerreißen.
APIs vereinfachen vieles, standardisieren vieles. Und darauf kann man dann eben aufbauen.
Wenn man sagt der Ansatz ist schon weit genug, dann back to Direct X 1 (ja EINS) und den rest machen die Entwickler schon, es kann schon alles.
Sorry, aber Entwickler sind halt oft faul, es muss halt doch irgendwo schonmal alles leicht verfügbar sein.

Ich hab mit den Ausdruck Middleware sowieso Probleme, dabei ist der Unterschied zwischen API und Engine schon deutlich klar, eine API könnte man auch als Wrapper verstehen also Python auf C Code , obwohl Python eigentlich wiederum auch ein Framework sein kann, Engine ist da viel deutlich, einfach der Code/Programm welches Physik/KI/etc. berechnet.

 

[burnbabyburn2]

was die reine Leistung betrifft wohl noch nicht so bald:
AMD hat hier schon noch Vorsprung was die Spiele-Treiber (alles andere nicht) betrifft. Und auch wenns um reine FPS geht ist Intel hinterher. Aber die Effizienz wiederum steht auf einem völlig anderen Blatt. Mich wundert immer die erbrachte Leistung im Bezug auf den Verbrauch
1. bei welchem Aufwand: die Leistung der GPU wird halt auch über einiges an Merverbrauch geholt
2. ist da sicher einiges im Treiber verpufft
3. bestreitet niemand, dass AMD NOCH die Führung bei der Leistung hat. Die Intel iGPU würde ich eh nicht zum Spielen verwenden btw. Umgekehrt würde ich AMD Lösungen für nix mehr außerhalb von Spielen verwenden, hab mich da schon viel zu oft verbrannt: die 780G Causa, das Llano Debakel was 3D Bluray betrifft...

Also noch hat man die Führung bei iGPUs/APUs bei AMD und drum hoffe ich auf solche Lösungen wie die von DX12 angestrebten, damit AMD bei Spielern wieder eine Alternative wird und die brach liegenden GPU EInheiten genutzt werden

so ganz einfach ist ja auch nicht, die Benchmarks die vorher erwähnt wurden mit DX10 und 3D-Mark 2012. gemacht in DX10 führt der Iris Pro , in jeden 3D-Mark 2012 führt AMD, AMD deklassiert sogar Iris Pro, an Stelle ist hinzufügen das es wahrscheinlich auf das Feature Set ankommt. Was AMD aber auszeichnet ist das Verhältnis von Flops/Preis selbst wenn die Dinger mehr brauchen für 100 Euro mehr müsste das Ding schon sehr lange untervollast laufen und wesentlich mehr Energie verbrauchen damit Iris Pro wiederum kosteneffizient wird, die Karten werden dann nochmals gemischt wenn AMD Carrizo bringt , 40 % weniger Energieaufnahme , 5 % mehr IPC

 

[Locuza]

Aber wie gesagt, glaube kaum das NV da mitspielt

Wieso sollten sie nicht?

so ganz einfach ist ja auch nicht, die Benchmarks die vorher erwähnt wurden mit DX10 und 3D-Mark 2012. gemacht in DX10 führt der Iris Pro , in jeden 3D-Mark 2012 führt AMD, AMD deklassiert sogar Iris Pro, an Stelle ist hinzufügen das es wahrscheinlich auf das Feature Set ankommt.

Also du guckst dir nur 3D Mark an, die Spiele, die sind egal.
Weil da ist Intel gleich gut oder hier und da sogar vorne.
Wir gucken uns nur 3D Mark an, wo eine Iris Pro GT3e Lösung weniger Punkte hat, als eine GT2 ohne eDRAM.

 

[burnbabyburn2]

Mein Gehirn versucht deine Antwort zu verarbeiten, ein 3D Mark Score hervorzuheben, aus einer Liste von Spielen und einem Index, aber ich scheitere daran.


Eine API ist natürlich keine Middleware. Right?

AMD führt einfach nach Punkten im 3D-Mark 2012, in jeden Spiel

bei DX10 liegen Iris Pro und AMD gleich auf

 

[burnbabyburn2]

Wieso sollten sie nicht?


Also du guckst dir nur 3D Mark an, die Spiele, die sind egal.
Weil da ist Intel gleich gut oder hier und da sogar vorne.
Wir gucken uns nur 3D Mark an, wo eine Iris Pro GT3e Lösung weniger Punkte hat, als eine GT2 ohne eDRAM.

nein aber was ist den 3D Mark ? es simuliert ein Spiel aber ohne KI, etc. wie gesagt man muss da bisschen Unterscheiden, AMD führt so oder so weil bei einen Test beide gleichauf sind und beim 3D Mark AMD wesentlich schneller ist

 

[Locuza]

Du hast aber schon da paar Bilder angeschaut, außer die ersten Benches?

So wie das hier:
http://cdn4.wccftech.com/wp-content/uploads/2014/02/AMD-Kaveri-APU-A10-7850k-Crysis-3-Benchmark.gif

Oder das:
http://i.imgur.com/bAWeoNO.png
http://i.imgur.com/IcTFK8r.png

Oder insgesamt den Index:
http://i.imgur.com/YQrIp5y.png

 

[DKK007]

Mal sehen, wie es mit AMD APU + AMD GPU aussieht. Dann kann man die iGPU vielleicht auch bald mit verbauter GPU noch richtig nutzen.

Mich würde mal interessieren, hing der Monitor jetzt eigentlich an der iGPU oder an der Geforce? Wenn die iGPU das Postprozessing macht wäre es ja sinnvoll, die Bilddaten nicht erst über die Geforce zurück an den Monitor zu schicken, sondern direkt.