@ZeroStrat,
@Lurtz ,
Wenn man sich eine CPU oder GPU-Architektur anschaut, dann gibt es hunderte von Hardware-Einheiten, die sich um eine Art von Scheduling kümmern.
Wenn man von Soft- oder Hardwarescheduling spricht, dann muss man schon sehr präzise ausdrücken was man eigentlich meint und wo ein vermeintlicher Unterschied bestehen soll.
Was HardwareUnboxed ungeprüft wiedergibt ist ein Video von NerdTechGasm, welches viele Sachen falsch eingeordnet hat in Bezug auf den DX11/12-"Overhead" und das Treibermodell.
Seit Kepler verwendet Nvidia für das Instruction-Scheduling keine Hardware mehr, welche Abhängigkeiten von Instruktionen überprüft und schaut welche Register man verwenden könnte.
Man kann dank fester Latenzen ganz genau sagen, wie das Scheduling ablaufen kann, ohne Konflikte zu erzeugen.
Diese Information wird seit Kepler in Software encodiert, was einige komplexe Schaltungen in der Hardware spart.
Das hat aber nichts mit DX11 oder DX12 zu tun, welche auf einer viel höheren Abstraktionsschicht agieren.
Egal ob Fermi ("Hardware" Instruction Scheduling) oder >=Kepler ("Software" Encoded Scheduling), Nvidia's Treiber splittet die Arbeit unter DX11 auf mehrere Worker-Threads auf Seiten der CPU.
Bei AMD's GCN Hardware, welche angeblich auf Hardware-Scheduling setzt, gibt es beim Instruction-Scheduling in diesem konkreten Punkt überhaupt kein Hardware-Scheduling, es gibt auch gar kein Software-Scheduling, weil GCN prinzipbedingt anders arbeitet.
Anders als Fermi, Kepler oder nun auch AMD's eigene RDNA-HW, ist GCN eine Non-Pipelined Architecture.
Das heißt in der Pipeline wird stets nur eine Instruktion ausgeführt, alle 4 Takte kommt ein neuer Befehl und die Ausführung selber dauert 4 Takte.
GCN muss niemals arithmetische Abhängigkeiten von Instruktionen überprüfen, entsprechend gibt es weder Software, noch Hardware, die sich darum kümmert.
Bei RDNA ist das anders, die Ausführung einer Instruktion dauert 5 Zyklen, allerdings kann RDNA jeden Takt eine neue Instruktion in die Pipeline einfügen, es könnten also maximal 5 Instruktionen in der Pipeline gleichzeitig aktiv sein.
Jetzt muss man aber nach Abhängigkeiten schauen, vielleicht benötigt Instruktion B die Ergebnisse von Instruction A, dann kann man nicht die Instruktion B ausführen und es gibt Pipeline-Bubbles, als weiße Kästchen unten dargestellt.
RDNA verwendet für die Abhängigkeitsprüfungen tatsächlich Hardware, im Gegensatz zu Nvidia oder jetzt auch Intel mit Xe.
Das hat aber erneut keinen direkten Bezug auf die Art und Weise, wie DX11 und DX12 arbeiten.
Auch für AMD wäre es möglich mehrere Worker-Threads unter DX11 zu erzeugen.
Es ist überhaupt nicht so, dass bei AMD der Treiber nur die Arbeitsanweisungen weiter leitet und dann "Hardware-Scheduling" sich angeblich um alles kümmert, weswegen AMD das nicht vorher parallelisieren kann.
Ebenso hat Nvidia in dem Aspekt gar kein Problem mit dem DX12 Modell, sie richten sich nach der gleichen Spezifikation wie AMD und beide Hersteller haben unter DX12 in der Hinsicht deutlich weniger Spielraum was die Command-Buffer-Generation angeht.
Das muss der Treiber unter DX11 erledigen, während unter DX12 das die Entwickler selber explizit vorgeben.
Was tatsächlich stimmt an der Stelle ist, dass AMD "ACE"-HW hat, welche sich um die Compute-Queues kümmern, welche optional bei DX12 verwendet werden können.
Optional ist aber das Stichwort, es gibt viele DX12 Spiele, die kein Asynchronous Compute verwenden und wo die "ACEs" brach liegen.
Die sind nur nützlich, wenn auch zusätzlich Compute-Queues verwendet werden.
Nvidia's Hardware, zumindest bis Pascal, hat die Einschränkung das nur GFX oder Compute-Befehle auf einem Shader Multiprocessor laufen können, nicht Beide gleichzeitig.
Maxwell musste vor der Ausführung die Ressourcen statisch partitionieren und getrennt für GFX und Compute einteilen.
Aufgrund der Arbeitsdynamik kann diese statische Partitionierung suboptimal ausfallen und einige SM an Leerlauf leiden, weswegen Nvidia bis Maxwell eigentlich niemals zusätzliche Compute-Queues ausnutzen sollte und alle Befehle in eine Arbeitsschlange steckt.
Seit Pascal gibt es Hardware Load Balancing, was die belegten Ressourcen dynamisch anpassen kann und somit potentiellen Leerlauf reduziert, seit Pascal sieht man auch im GPUView-Profiler Compute-Queues auf Nvidia's Hardware, dabei hat der Hersteller aber nichts in Bezug auf das Software Encoded Instruction Scheduling verändert.
Und beide Unternehmen haben Hardware-Command-Processors, Hardware wie die ACEs oder GigaThread-Engine, welche sich um Draw- (3D) und Dispatch-Befehle (Compute) bis zu einem gewissen Grad kümmern und auch selber verteilen.
Ebenso sind die Wavefront/Warp-Scheduler bei AMD und Nvidia Hardwareeinheiten, auch wenn bei Nvidia die Control-Flow Informationen über die Software encodiert wurde, muss der Warp-Scheduler nach wie vor bei Load/Texture-Operations Register-Usage überprüfen und die besten Warp-Instructions auswählen, die Software gibt nicht alles vor.
