GTC 2014: NVIDIA spricht über DirectX 12 und kommenden Wundertreiber

[Pätterrich]

Meinst du mit dem neuen Treiber in Vergleich zum alten oder generell? Denn generell läuft es unter Win 8.1 besser.


Gesendet vom ApfelPod

 

[slot108]

Laut Test laufen mit Ausnahme von BF4 die Spiele unter Win 7 besser !

BF4 MP läuft übrigens besser

 

[sontin]

Mit meinem 2500K@1600MHz legt Sniper Elite 2 im Schnitt 17% zu.
Wobei das ganze von 5% bis zu 40% geht.

Sleeping Dogs liegt irgendwo bei 16-19%.

 

[Schaffe89]

Laut Test laufen mit Ausnahme von BF4 die Spiele unter Win 7 besser !

Welche Spiele sind das denn alles?
Wenn du schreibst mit Ausnahme von BF4 müssten das ja alle Spiele sein.

 

[sontin]

Mit meinem 2500K@1600MHz legt Sniper Elite 2 im Schnitt 17% zu.
Wobei das ganze von 5% bis zu 40% geht.

Sleeping Dogs liegt irgendwo bei 16-19%.

So, mal Sniper Elite 2 mit FPS-Verlauf:

1080p, alles Maximum ohne SSAA. 2500K@1600MHz und GTX780TI@1200MHz.

Mit dem neuen Treiber gibt es also eine Leistungssteigerung von 40% in CPU-limitierenden Stellen in Sniper Elite 2.

 

[aeugle]

Geiler Treiber !! NV Daumen hoch !!!

 

[Gelöschtes Mitglied 101197]

sontin

das ist mit 8.1 oder?

 

[sontin]

Oh, ja Windows 8.1 + Update.

 

[Gelöschtes Mitglied 101197]

ok danke.

- - - Updated - - -

wo ich es bei meinem Lappi besonders gemerkt habe war bei Dirt 2. Auch wenn es schon alt ist

Vorher alles auf hoch und 4 x aa und 16 x af. min 43 avg 56
jetzt mit dem neuen Treiber alles auf max 4 x aa und 16 x af min 53 avg 66

 

[fdsonne]

1080p, alles Maximum ohne SSAA. 2500K@1600MHz und GTX780TI@1200MHz.

Mit dem neuen Treiber gibt es also eine Leistungssteigerung von 40% in CPU-limitierenden Stellen in Sniper Elite 2.

Kannst du als Gegentest mal das gleiche mit vollem CPU Takt machen?
Mich würde mal interessieren, wie stark die Leistung generell zusammen bricht.
Ob neuer oder alter Treiber ist wurscht...

 

[sontin]

Mit 4500MHz gibt es kaum eine Steigerung. Was auch verständlich ist, wenn meine Grafikkarte bei 160FPS+ limitiert.

337.50 mit 2500K@4500MHz

Average FPS:	172.9
      Minimum FPS:	41.1
      Maximum FPS:	517.8

337.50 mit 2500K@1600MHz

Average FPS:	148.4
      Minimum FPS:	11.1
      Maximum FPS:	239.4

 

[DragonTear]

Mit 4500MHz gibt es kaum eine Steigerung. Was auch verständlich ist, wenn meine Grafikkarte bei 160FPS+ limitiert.

337.50 mit 2500K@4500MHz

Average FPS:	172.9
      Minimum FPS:	41.1
      Maximum FPS:	517.8

337.50 mit 2500K@1600MHz

Average FPS:	148.4
      Minimum FPS:	11.1
      Maximum FPS:	239.4

Deine Werte sind allerdings ein perfektes Beispiel wieso so viele Leute auf die Min-FPS schauen...

 

[Unrockstar]

Geiler Treiber !! NV Daumen hoch !!!

Der Treiber ist Augenwischerei und nicht mehr :/ Diverse Seiten haben ein Plus von vllt 10% erreicht. Auf meiner GTX 470 läuft der Treiber garnicht, bzw die Graka steigt mit Fragmenten aus. (beim Vorgänger habe ich das Problem nicht) Sontins Werte sehen mir trotz 1,6GHZ CPU arg merkwürdig aus. Alles in allem ist es KEIN Wundertreiber, AMD verbessert seine GPU Leistung auch ohne ein Riesen Fass aufzumachen. Nunja vllt wirds ja mit DX12 besser, sonst muss ich mich echt selber Überreden mir Ende des Jahres eine NV zu holen

 

[BrennPolster]

keine Ahnung was dein Problem ist, vielleicht liegt es daran das du mit deiner poligen 470 sowieso durchgehend im GPU Limit steckst.

Ich bin vom Treiber überzeugt, BF3 und 4 laufen unglaublich gut, keine FPS Einbrüche mehr, keine CPU Spikes mehr.
BF fühlt sich jetzt extrem gut an, und die maps laden schneller.

Und ja ich weiß wovon ich rede, habe bereits über 40 bf4 Stunden mit dem alten Treiber gespielt.

Und nicht zu vergessen das der Treiber stabil läuft, habe noch keine fehler eindeckt.
Außerdem ist das optimieren noch nicht abgeschlossen.

10% können auch leicht mal 20% werden.

AMD will nichts mehr optimieren da sie jetzt mantle haben.
Wären auch fail wenn AMD's dx11 treiber schneller wäre als mantle in bf.

 

[Tankman]

AMD will nichts mehr optimieren da sie jetzt mantle haben.
Wären auch fail wenn AMD's dx11 treiber schneller wäre als mantle in bf.

Trotzdem wird AMD versuchen auch die DX Geschichten zu optimieren.
Das könnten sich sich nur dann sparen, wenn jedes Game Mantle nutzen würde.
Aber bei BF, da bin ich bei dir, liegt der Fokus mit Sicherheit auf Mantle.

 

[slot108]

... AMD verbessert seine GPU Leistung auch ohne ein Riesen Fass aufzumachen. Nunja vllt wirds ja mit DX12 besser...

AMDs Fass war nicht so dolle wie Nvidias?
mir war so als hätte AMD die Trommel schon 1, 2 Monate vor Mantle-Release getrommelt.

...sonst muss ich mich echt selber Überreden mir Ende des Jahres eine NV zu holen

nimm doch ne AMD, deren Mantle bringt viel mehr, unterstützt viel mehr Spiele und es werden noch viel, viel mehr.
zudem macht AMD niemals TamTam, is´n richtig fairer Hersteller und und und ...

 

[fdsonne]

Der Treiber ist Augenwischerei und nicht mehr :/ Diverse Seiten haben ein Plus von vllt 10% erreicht. Auf meiner GTX 470 läuft der Treiber garnicht, bzw die Graka steigt mit Fragmenten aus. (beim Vorgänger habe ich das Problem nicht) Sontins Werte sehen mir trotz 1,6GHZ CPU arg merkwürdig aus. Alles in allem ist es KEIN Wundertreiber, AMD verbessert seine GPU Leistung auch ohne ein Riesen Fass aufzumachen. Nunja vllt wirds ja mit DX12 besser, sonst muss ich mich echt selber Überreden mir Ende des Jahres eine NV zu holen

Also wenn mich nicht alles täuscht, sollte man hier auch klar Differenzieren. Ich könnte mich irren, aber von Wundertreiber sprach NV selbst NIE!
Das Wörtchen wurde von den Medien dort reingeschmuggelt. NV kündigte nur den Treiber mit diesen und jenen Performancesteigerungen an und sagte, man arbeite am Overheadverhalten bei DX11 Titeln.
Aber berichtige mich, wenn ich falsch liege!

Mal ganz davon ab, ich verstehe auch gar nicht, warum an sich jetzt hier darüber beschwert, das es hier und dort nur 5 oder 10% sind, oder auch mal gar nicht.
Der Treiber wurde seitens NV dahingehend optimiert, nicht mehr unnötig Ressourcen in Sachen CPU Power zu verschwenden. Und genau das kann er wie versprochen. Es mag sein, das die von NVs Marketingabteilung besagten 64% für SGPU respektive 71% für MGPU im MAX! nicht überall nachstellbar sind. Aber das war schlicht schon immer so und es sind schlicht MAXIMAL Angaben. Bis zu nennt man das auch... Keinesfalls die Regel!
Dennoch sehen wir gehörige Leistungssteigerungen in den Bereichen, wo auch Mantle ansetzen will. Nämlich, wenn man viel viel GPU Power hat, aber die CPU aus welchen Gründen auch immer zu deckeln scheint. Was bravourös im MP von BF3 und 4 zu funktionieren scheint. Aber auch andere Titel zeigen bei schwacher CPU weit mehr als nur 10%...

Wenn man jetzt hier von Beschwerden ließt, das der Treiber nur ein paar Prozent schneller ist als der Vorgänger (wenn überhaupt), geht man also faktisch von einem GPU Limit aus -> und dort soll der Treiber nach Ankündigung nicht zulegen. Macht man das aber hier bei diesem Treiber wäre es folgerichtig nur konsequent, die gleiche Kritik auch bei Mantle anzusetzen. Sehe ich diese von den gleichen Personen? Nööö... Das Gegenteil ist eher der Fall.

Nüchtern betrachtet legt der Treiber genau dort zu, wo es zu erwarten war nach der Aussage von NV. Man optimiert das Overheadverhalten in DX11 Titeln. Das klappt je nach CPU Limit mal mehr mal weniger stark und steigert entsprechend die FPS mal mehr mal weniger stark. Nichts anderes wurde verkündet...

 

[MikelMolto]

Unterschreibe ich 100%. Ich bin zufriedener mit dem neuen Treiber als mit dem altem. Ziel erreicht.
Das beide Firmen kräftig die Werbetrommel rühren und zum Teil übertreiben liegt in der Natur der Dinge. So ist das Heute nun mal.

 

[DragonTear]

Da bin ich mal gespannt was man noch mit DX 12 zusätzlich rausholen kann... schliesslich ging es laut MS da auch hauptsächlich um den CPU-Overhead den man verringern will, sowie um bessere Multithread-Auslastung!
Wo bei mich letzteres doch etwas wundert, denn welcher Game-Thread die DX-Befehle ausführt, bestimmt immernoch der Entwickler des Games, bzw. dessen Engine. Wäre seltsam wenn DX jetzt selbst die Befehle nach belieben auf die Threads verteilen kann... so funktioniert multithreaded Software nicht da ja nicht vorhersagbar ist, in welcher Reihenfolge die einzelnen Threads dann ausgeführt werden.
Die Ergebnisse waren aber zumindest vielversprechend.

 

[aeugle]

Der Treiber ist Augenwischerei und nicht mehr :/ Diverse Seiten haben ein Plus von vllt 10% erreicht. Auf meiner GTX 470 läuft der Treiber garnicht, bzw die Graka steigt mit Fragmenten aus. (beim Vorgänger habe ich das Problem nicht) Sontins Werte sehen mir trotz 1,6GHZ CPU arg merkwürdig aus. Alles in allem ist es KEIN Wundertreiber, AMD verbessert seine GPU Leistung auch ohne ein Riesen Fass aufzumachen. Nunja vllt wirds ja mit DX12 besser, sonst muss ich mich echt selber Überreden mir Ende des Jahres eine NV zu holen

Wäre eine gute Entscheidung !!!

 

[Mick_Foley]

so funktioniert multithreaded Software nicht da ja nicht vorhersagbar ist, in welcher Reihenfolge die einzelnen Threads dann ausgeführt werden.

Wenn das nicht möglich wäre, könnte man den PC gleich auslassen. Dafür gibt es Priorisierung und Verteilungs-Algorithmen usw. Multihtreading ist nicht die Definition von Zufallsabläufen.

 

[fdsonne]

schliesslich ging es laut MS da auch hauptsächlich um den CPU-Overhead den man verringern will, sowie um bessere Multithread-Auslastung!
Wo bei mich letzteres doch etwas wundert, denn welcher Game-Thread die DX-Befehle ausführt, bestimmt immernoch der Entwickler des Games, bzw. dessen Engine. Wäre seltsam wenn DX jetzt selbst die Befehle nach belieben auf die Threads verteilen kann... so funktioniert multithreaded Software nicht da ja nicht vorhersagbar ist, in welcher Reihenfolge die einzelnen Threads dann ausgeführt werden.

Moment... So einfach ist das nicht.

Es gibt minimum drei Stellen, wo man mit Multithreading ansetzt.
1. Das Programm selbst kann Berechnungen threadbasiert gleichzeitig ausführen
2. Die Schnittstelle kann Sachen gleichzeitig annehmen/ausführen/weitergeben
3. Das Treiberbackend der Grafikkarte kann threadbasiert gleichzeitig Sachen abarbeiten

Du sprichst klar von ersterem. Was auch richtig so ist und auch gut so. Der Programmierer selbst hat die Wahl, wie er seine Berechnungen in Threads verpackt und hat sich an der Stelle auch zu kümmern, wie diese Threads laufen. Hier spielen Komplexität der Aufgaben und deren Laufzeiten massiv in die Skalierung. Einfach weil nicht alle Sachen gleich schnell bewerkstelligt werden können. Aber das ist rein Software... Und hat nix mit Hardware zu tun.

MS will mit DX12 aktuell bestehende Limitierungen im Multithreading bei DX11 angehen. So existieren an der Stelle diverse Sachen, die einfach nicht gleichzeitig ausführ/absetzbar sind, sondern nur sequenziell. Da kann man noch so viele CPU Cores haben, wenn die Schnittstelle vorsieht, die Aufgaben sequenziell hintereinander einzukippen, dann muss man das so tun!
Mit DX12 will MS das scheinbar stark verbessern und auf MT auslegen.

Das was NV hier aktuell mit dem neuen Treiber macht, setzt an der dritten Stelle an.

Das Problem ist, das die meisten schlicht nicht verstehen (oder wissen), das das eine zusammenhängende Kette ist. Du kannst (1) Optimieren und es wird schneller, du kannst (3) optimieren und es wird ebenso schneller. Usw. usf.
Die Geschwindigkeit, von Anfang bis Ende hängt in einer Reihe zusammen... und jedwede Mitglieder dieser Reihe addieren die Abarbeitungszeit nach oben hin!




Wenn man sich das ganze mal bildlich ansieht, könnten wir mal wieder Kaffee kochen
Du hast als Programmierer sagen wir mehr wie zwei Hände.
Mit diesen Händen kannst du also auch diverse Sachen gleichzeitig ausführen. So ist es möglich die komplette Kaffeekochvorbereitungen bis der Arzt kommt zu parallelisieren und so das Optimum an Speed für diesen Part rauszuholen.
Also gehst du nun hin und sagst in deinem Vorhaben, das du gleichzeitig beispielsweise Wasser und Kaffee in die Maschine füllst usw. Was die Abarbeitungszeit entsprechend verkürzt, da beides benötigt wird, damit du Kaffee kochen kannst.

Das was MS mit der DX Schnittstelle bietet, ist beispielsweise der Startknopf für den Brühvorgang. Betätigt man diesen, wird das Wasser und der Kaffee, der eingefüllt ist, direkt an den Brühautomaten weitergereicht. Aber in einem Zug! Nicht gleichzeitig aufgeteilt in viele kleine Häppchen.
Es besteht also die Limitierung der Schnittstelle darauf, dass du genau nur mit einer Hand bei einer Kaffeemaschine diesen Vorgang auslösen kannst, ist das klar SingleThread limitiert.
Die GPU Hersteller hintendran (also im Beispiel die Kaffeemaschine) hat streckenweise das gleiche Problem. -> man bekommt genau einen Einschaltvorgang von der Schnittstelle (nebst Kaffee und Wasser usw.) und richtet sich weitestgehend in dieser sequenziellen Kette aus bzw. führt sie fort. Was auch nicht ganz abwägig ist, da ja die Aufgabe sequenziell über die Schnittstelle reinkommt anstatt gleichzeitig!

NV ist nun beispielsweise aber hergegangen und sagte, OK wir erkennen, das der Einschaltvorgang zwar nur SingleThread ist. Aber die Abarbeitungsgeschwindigkeit unseres Kaffeeautomaten lässt sich steigern, wenn wir da den Kochvorgang parallel ausführen. (das funktioniert bekanntlich völlig unabhängig der Vorbereitungen für das Kochen! Sofern alle Vorbereitungen abgeschlossen sind -> also quasi völlig unabhängig der Sachen, die du als Programmierer vorn MT ausgeführt hast)
So könnte bspw. NV den initial Einschalter über DX genommen haben um gleichzeitig eine Reihe von Mini Kaffeemaschinen zu starten. Diese Kaffeemaschinen nehmen sich zu gleichen Teilen Informationen (wie Wasser, Kaffeepulver usw.) von der Schnittstelle und brühen den Kaffee dann gleichzeitig über mehrere Threads -> mit entsprechend verkürzter Abarbeitungszeit. So kann man mit (1) und (3) den Speed stark steigern, obwohl (2) als Schnittstelle immernoch fix ist!

Um den Schluss zu ziehen. Du als Programmierer kannst oben in den Vorbereitungen deinen Teil zur Abarbeitungsgeschwindigkeit leisten, die GPU Hersteller können für DX hinten ihren Teil leisten.
Nur steht in der Mitte immernoch die Schnittstelle.
Mit Mantle setzt AMD dort an und strikt das Konstrukt um. -> so existiert dort das hier skizzierte Limit nur eines Einschaltvorgangs gleichzeitig nicht. Da man eben die Maschine bspw. über mehrere gleichzeitige Öffnungen gleichzeitig mit Wasser befüllen kann, man kann über mehrere Öffnungen Kaffeepulver einfüllen und man kann für diese Teile der großen Maschine jeweils mehrere Einschalter initieren. Die große Kaffeemaschine besteht also intern aus vielen vielen kleinen, die auch gleichzeitig laufen können (wenn jeweils die insich geschlossenden Vorbereitungen abgeschlossen sind)
Ähnliches soll DX12 machen können. Man wird also die Schnittstelle weiter auf MT trimmen. Um somit dem Programmierer vorn nicht künstliche Limits in den Weg zu werfen.
Der Hersteller der Hardware kann über seine Treiber dann diese kleinen Maschinen abgreifen und gleichzeitig das Brühen ausführen... -> es wird also einfacher.
Das einzige, was problematisch ist, der Programmierer ganz vorn darf nicht schlampen. Denn wenn er schlampt und nicht die Threads gleichzeitig bedient, ergibt sich effektiv kein Speedvorteil!

Wenn das nicht möglich wäre, könnte man den PC gleich auslassen. Dafür gibt es Priorisierung und Verteilungs-Algorithmen usw. Multihtreading ist nicht die Definition von Zufallsabläufen.

Neja... Doch schon irgendwie.
Das Problem ist schlicht, das die Zeit, die die Threads für die Berechnung haben, durch das OS gesteuert werden. Und für das OS ist das Programm eine Latte von Threads. Zwar lassen sich Threadbasiert Prioritäten setzen, aber das gilt dann nur für das eigene Programm! Höher Priorisierte Threads anderer Programme können sich immernoch vordrängeln.
Heist also, hast du Phasenweise weitere Last auf der CPU (die nicht von dir selbst kommt) kann es dir schlicht passieren, dass Teile deines Programms aus dem Zeitfenster laufen und somit die Skalierung stark abfällt.
Das ist ziemlich unschön und für sowas gibt es Mittel und Wege um einzelnen Threadteile gegenseitig auf sich warten zu lassen. Eben wenn mal irgendwo etwas länger dauert als geplant.

Arbeitest du Multithreaded, ist dein Einfluss auf das Geschehen zwar vorhanden, aber das ganze ist extremst Komplex! Da eben nicht nur reiner Rechenspeed reinzählen, sondern die Zeit sich wieder über eine Kette von Elementen addiert. Zugriffe auf die HDD können mal schnell, mal langsamer sein um ein Beispiel zu nennen. Ergo kann dein Thread, der die Daten holt mal schnell, mal langsamer fertig sein. Bleiben wir bei diesem Beispiel, könnte das OS dir knallhart das Zeitfenster zudrehen, wenn du zu lange für den Zugriff brauchst. Und somit pausiert der Thread und dauert nochmals länger. (als er hätte ggf. gebraucht, wenn du ihn hättest nicht in einem eigenen Thread ausgeführt)

Wenn man so will, es sind viele viele externe Einflussfaktoren dabei, die stark vom Zufall abhängen können. Bzw. für das Programm als Zufall aussehen und was sich nicht vorher irgendwie bemessen lässt.

 

[Mick_Foley]

Neja... Doch schon irgendwie.
Das Problem ist schlicht, das die Zeit, die die Threads für die Berechnung haben, durch das OS gesteuert werden. Und für das OS ist das Programm eine Latte von Threads. Zwar lassen sich Threadbasiert Prioritäten setzen, aber das gilt dann nur für das eigene Programm! Höher Priorisierte Threads anderer Programme können sich immernoch vordrängeln.
Heist also, hast du Phasenweise weitere Last auf der CPU (die nicht von dir selbst kommt) kann es dir schlicht passieren, dass Teile deines Programms aus dem Zeitfenster laufen und somit die Skalierung stark abfällt.
Das ist ziemlich unschön und für sowas gibt es Mittel und Wege um einzelnen Threadteile gegenseitig auf sich warten zu lassen. Eben wenn mal irgendwo etwas länger dauert als geplant.

Arbeitest du Multithreaded, ist dein Einfluss auf das Geschehen zwar vorhanden, aber das ganze ist extremst Komplex! Da eben nicht nur reiner Rechenspeed reinzählen, sondern die Zeit sich wieder über eine Kette von Elementen addiert. Zugriffe auf die HDD können mal schnell, mal langsamer sein um ein Beispiel zu nennen. Ergo kann dein Thread, der die Daten holt mal schnell, mal langsamer fertig sein. Bleiben wir bei diesem Beispiel, könnte das OS dir knallhart das Zeitfenster zudrehen, wenn du zu lange für den Zugriff brauchst. Und somit pausiert der Thread und dauert nochmals länger. (als er hätte ggf. gebraucht, wenn du ihn hättest nicht in einem eigenen Thread ausgeführt)

Wenn man so will, es sind viele viele externe Einflussfaktoren dabei, die stark vom Zufall abhängen können. Bzw. für das Programm als Zufall aussehen und was sich nicht vorher irgendwie bemessen lässt.

Mir ging es ja nur darum, dass da Ablauf aber nicht zufällig ist, das klingt bei DragonTear so. Natürlich hast du zig Faktoren, die es dynamisch machen, aber es ist "organisiertes" Chaos. Hab mich vielleicht etwas krum ausgedrückt. Mea Culpa.

 

[fdsonne]

is ja kein Ding

Hab mal zu obigen nochmal ein Bild gemalt.
Nicht auf die Zahlen primär schauen, die sind Wild aus den Fingern gesaugt und sollen nur als Beispiel zur Veranschaulichung dienen.

In ganz abstrakter Form könnte man dies so Bildlich darstellen.
Mantle und DX12 wären quasi ganz unten im grauen Teil.

 

[Mick_Foley]

Irgendwie muss ich bei deiner Grafik an meine "Betriebssysteme"-Klausur an der Uni denken...

 

[BrennPolster]

fdsonne ich liebe deine beitrage die sind immer so schön zu lesen

Trotzdem wird AMD versuchen auch die DX Geschichten zu optimieren.
Das könnten sich sich nur dann sparen, wenn jedes Game Mantle nutzen würde.
Aber bei BF, da bin ich bei dir, liegt der Fokus mit Sicherheit auf Mantle.

jo genau so meine ich das .

 

[aeugle]

AMD wird immer den kürzeren ziehen.
Ist halt der ALDI im Vergleich zu NV.
Aber vom P/L ist AMD top.
Wer weniger Luxus liebt ist dort der richtige Kunde !!!
Finde es gut dass AMD Produkte für diese Käufer entwickelt.

 

[Tankman]

Du tust ja bald so, als wenn AMD für die Unterschicht wäre

 

[ONE_FOR_ALL]

Ich glaube er tut nicht nur so.Das ist die Kundschaft von AMD sind ja selber schuld.

 

[DragonTear]

Neja... Doch schon irgendwie.
Das Problem ist schlicht, das die Zeit, die die Threads für die Berechnung haben, durch das OS gesteuert werden. Und für das OS ist das Programm eine Latte von Threads. Zwar lassen sich Threadbasiert Prioritäten setzen, aber das gilt dann nur für das eigene Programm! Höher Priorisierte Threads anderer Programme können sich immernoch vordrängeln.
Heist also, hast du Phasenweise weitere Last auf der CPU (die nicht von dir selbst kommt) kann es dir schlicht passieren, dass Teile deines Programms aus dem Zeitfenster laufen und somit die Skalierung stark abfällt.
Das ist ziemlich unschön und für sowas gibt es Mittel und Wege um einzelnen Threadteile gegenseitig auf sich warten zu lassen. Eben wenn mal irgendwo etwas länger dauert als geplant.

In etwa darauf hatte ich mich bezogen. Hab allerdings nur genau ein einziges mal bisher mit Multithreading in C++ gearbeitet.. und meine Erinnerung daran ist nur noch "Urgh, diese doofen Threads tun nie das was ich will ><"
Daher hatte ich das etwas unkontrolierter in Erinnerung und mein Wissen üebr DX bezieht sich allein auf die Nutzung, d.h. Draw Befehle und bei denen ist die Reihenfolge ja relativ wichtig.
Hab allerdings keine Ahnung davon wie DX im Hintergrund funktioniert...

Irgendwie muss ich bei deiner Grafik an meine "Betriebssysteme"-Klausur an der Uni denken...

Mein Beileid... genau diesen Kurs hab ich auch grad seit 3 Wochen


@fdsonne
Grossen dank für die sehr ausführliche Erklärung o.o Glaube mit deinem Wissen könntest du ein Buch schreiben!

Btw.

So könnte bspw. NV den initial Einschalter über DX genommen haben um gleichzeitig eine Reihe von Mini Kaffeemaschinen zu starten. Diese Kaffeemaschinen nehmen sich zu gleichen Teilen Informationen (wie Wasser, Kaffeepulver usw.) von der Schnittstelle und brühen den Kaffee dann gleichzeitig über mehrere Threads

Dies sollte unbedingt jemand in seine Signatur aufnehmen