Nai
Lt. Commander
- Registriert
- Aug. 2012
- Beiträge
- 1.579
@ Pipip
@ max_1234
Die Erklärung aus Post #266 ist leider falsch; auch der Wiki-Text liest sich komisch. Da hier oft falsche Vorstellungen zwischen den API-Unterschieden herrschen erkläre ich das mal im Folgenden etwas genauer.
Die Befehle werden im Falle von DirectX 11 und OpenGL einzeln an die API übergeben. Dabei müssen die Befehle von der API ersteinmal genau in der Reihenfolge ausgeführt werden, in der sie an die API übergeben wurden. Aus dem Grund ist auch das Übergeben an die API ein rein sequentieller Vorgang, wo ein Programm hier auch effektiv nur einen Thread verwenden kann. Innerlich reiht die API bzw. der Treiber die Befehle dann in die Schlangen für die der unterschiedlichen Engines (Copy, Compute, Graphik) ein, wie man sie aus DirectX 12 kennt. Sind die Schlangen voll so werden sie mit sämtlichen darinnen enthaltenen Befehlen zur GPU an die entsprechenden Engines geschickt. Beim Einreihen der Befehle in die Schlangen muss der Treiber zunächst wieder darauf achten, dass die Reihenfolge der Befehle durch Synchronisation der unterschiedlichen Schlangen erhalten bleibt. Dadurch müssen die Engines der GPU die Befehle auch weitestgehend sequentiell ausführen.
Aber: DirectX11 und OpenGL sind APIs die auf Resource-Binding basieren. Deshalb kann ein Shader auch nur aus denjenigen Resourcen lesen und in diejenigen Resourcen schreiben, die zuvor an ihm gebunden wurden. Da Lese- und Schreibzugriffe im voraus bekannt sind, kann der Treiber prinzipiell eine Abhängigkeitsanalyse (https://de.wikipedia.org/wiki/Abhängigkeitsanalyse) verwenden, um die Befehle zu parallelisieren. Dadurch könnten die verschiedenen Engines der GPU die Befehle sofern es die Abhängigkeiten erlauben auch gleichzeitig bzw. parallel ausführen, wodurch der Treiber wiederum die Async-Compute-Fähigkeit der GPU selbst unter DirectX 11 und OpenGL verwenden könnte. Ich weiß nicht 100 prozentig ob die aktuellen Treiber diese Optimierung verwenden, nehme es aber stark an. Zumindest von OpenCL weiß ich es sicher.
Im Gegensatz dazu versteckt DirectX 12 die unterschiedlichen Schlangen für die verschiedenen Engines nicht innerhalb des Treibers, sondern macht sie für die Anwendung direkt zugänglich. Dadurch kann die Anwendung die einzelnen Schlangen selbst manuell befüllen. Da die Schlangen asynchron zueinander abgearbeitet werden ist die Anwendung dafür verantwortlich die Befehlsabhängigkeiten zwischen unterschiedlichen Schlangen zu modellieren. Über das Modellieren der Abhängigkeiten kann die Anwendung erreichen, dass die GPU die Befehle parallel abarbeiten kann. Zudem kann die Anwendung das Einfügen in die Schlangen prinzipiell mit mehreren Threads vornehmen. Um die Parallelität in der Anwendung weiter zu erhöhen und um den Overhead des Einfügens zu veringern werden zusätzlich Befehle nicht einzeln sondern in die Schlangen eingereiht, sondern zunächst zu Gruppen (Command Buffer) zusammengefasst und danach als komplette Gruppe in die Schlange eingereiht.
@Ampre
Ja, da für den API Support nur das Ergebnis eine Rolle spielt; nicht wie die GPU letztendlich zum Ergebnis kommt. Interessanterweise sind ROV meines Wissensstands auch sehr leicht durch SW-Emulation zu emulieren (Mutex pro Pixel), aber auch sehr langsam dann (Busy-Wait auf Mutex), so dass die klassische Implementierung für Verfahren, die sich mit ROV beschleunigen lassen, deutlich schneller wäre. Dementsprechend finde ich auch die Betrugsvorwürfe in dieser Hinsicht etwas deplatziert. Eine gute Analogie hierfür wäre, wenn Intel für einen Xeon-PHI einen DX 12 Treiber schreiben würde und sie als DX 12 fähige GPU verkaufen würde. Mangels Hardware-Beschleunigung wäre die Karte vermutlich nicht schnell; sie würde jedoch dennoch jedes DX 12 Programm ausführen können. Hier würde sicher auch kaum jemand sagen "Beschiss, ist ja gar nicht DX 12 fähig; alles nur Software", sondern die meisten würden meinen "Scheiss Architektur; viel zu langsam für aktuelle Spiele".
@ max_1234
Die Erklärung aus Post #266 ist leider falsch; auch der Wiki-Text liest sich komisch. Da hier oft falsche Vorstellungen zwischen den API-Unterschieden herrschen erkläre ich das mal im Folgenden etwas genauer.
Die Befehle werden im Falle von DirectX 11 und OpenGL einzeln an die API übergeben. Dabei müssen die Befehle von der API ersteinmal genau in der Reihenfolge ausgeführt werden, in der sie an die API übergeben wurden. Aus dem Grund ist auch das Übergeben an die API ein rein sequentieller Vorgang, wo ein Programm hier auch effektiv nur einen Thread verwenden kann. Innerlich reiht die API bzw. der Treiber die Befehle dann in die Schlangen für die der unterschiedlichen Engines (Copy, Compute, Graphik) ein, wie man sie aus DirectX 12 kennt. Sind die Schlangen voll so werden sie mit sämtlichen darinnen enthaltenen Befehlen zur GPU an die entsprechenden Engines geschickt. Beim Einreihen der Befehle in die Schlangen muss der Treiber zunächst wieder darauf achten, dass die Reihenfolge der Befehle durch Synchronisation der unterschiedlichen Schlangen erhalten bleibt. Dadurch müssen die Engines der GPU die Befehle auch weitestgehend sequentiell ausführen.
Aber: DirectX11 und OpenGL sind APIs die auf Resource-Binding basieren. Deshalb kann ein Shader auch nur aus denjenigen Resourcen lesen und in diejenigen Resourcen schreiben, die zuvor an ihm gebunden wurden. Da Lese- und Schreibzugriffe im voraus bekannt sind, kann der Treiber prinzipiell eine Abhängigkeitsanalyse (https://de.wikipedia.org/wiki/Abhängigkeitsanalyse) verwenden, um die Befehle zu parallelisieren. Dadurch könnten die verschiedenen Engines der GPU die Befehle sofern es die Abhängigkeiten erlauben auch gleichzeitig bzw. parallel ausführen, wodurch der Treiber wiederum die Async-Compute-Fähigkeit der GPU selbst unter DirectX 11 und OpenGL verwenden könnte. Ich weiß nicht 100 prozentig ob die aktuellen Treiber diese Optimierung verwenden, nehme es aber stark an. Zumindest von OpenCL weiß ich es sicher.
Im Gegensatz dazu versteckt DirectX 12 die unterschiedlichen Schlangen für die verschiedenen Engines nicht innerhalb des Treibers, sondern macht sie für die Anwendung direkt zugänglich. Dadurch kann die Anwendung die einzelnen Schlangen selbst manuell befüllen. Da die Schlangen asynchron zueinander abgearbeitet werden ist die Anwendung dafür verantwortlich die Befehlsabhängigkeiten zwischen unterschiedlichen Schlangen zu modellieren. Über das Modellieren der Abhängigkeiten kann die Anwendung erreichen, dass die GPU die Befehle parallel abarbeiten kann. Zudem kann die Anwendung das Einfügen in die Schlangen prinzipiell mit mehreren Threads vornehmen. Um die Parallelität in der Anwendung weiter zu erhöhen und um den Overhead des Einfügens zu veringern werden zusätzlich Befehle nicht einzeln sondern in die Schlangen eingereiht, sondern zunächst zu Gruppen (Command Buffer) zusammengefasst und danach als komplette Gruppe in die Schlange eingereiht.
@Ampre
Wie genau meinen?
Zuletzt bearbeitet:
.
