Jungs, ich hab gestern abend vorm Einschlafen über etwas nachgedacht, was ich nicht so recht beantworten konnte.
Und zwar geht es um die in aktuellen GPU-ALUs enthaltene MUL-Funktionalität. Soweit wir wissen, wird dort eine Multiplikation in einem Takt durchgeführt. Die einzige mir bekannte Möglichkeit, die Multiplikation soweit zu parallelisieren, dass das möglich ist, ist per PLA-Decoder-Multiplikationseinheit. Das erfordert aber für 2 32 Bit breite Datenworte schon 2^64 * 64 Bit Speicher und das haben aktuelle ALUs definitiv nicht. Die normale bitserielle Multiplikationslogik braucht pro Stelle des Multiplikanden einen Takt plus einen Takt für die Addition der temporären Ergebnisse - das kann es also auch nicht sein. Aber sogar, wenn man das ähnlich wie beim Carry-Save-Addierer mit großem Logikaufwand zu parallelisieren versucht, sehe ich noch nicht, wie man ohne MIMD-ALUs die gesamte Multiplikation in einen Takt kriegen soll - ich komme bestenfalls auf einen Takt für den multiplikativen Anteil und (je nach ADD-Logik) entsprechend viel für den Rest. Einfach jedes alternative Verfahren, ob auf 2K-Zahlen (wo mir übrigens mal einer sagen könnte, ob Booth Recoding das effizienteste aktuell genutzte Verfahren ist) oder Gleitkommaarithmetik, dauert mehr als einen Takt.
Jemand Ahnung, wie das laufen soll?
Ich hab vor längerer Zeit mal eine ALU aus Transistoren gebaut, sie war 32bit breit und konnte pro Takt: 2Operanten Multiplizieren(MUL); Addieren (ADD); Multiplizieren mit folgendender Addition (MADD); Subtrahieren (SUB); Negieren(NEG) und vergleichen( >= ). Es war möglich ein Integer-Wert sowie ein FP-Wert als Operant zu verwenden. Die ganze Alu fraß 4356 npn-Transis. Zum vergleich ist hier mal ein 8086 (16-bit CPU mit cache und registern) mit 29 000 Transitoren. Das einzige Problem war eine Taktbegrezung durch die Schaltzeiten der Transistoren. Fertigt man diese allerdings in kleineren Strukturen, veringert man die Schaltzeit
- Programm war ein kleines Freeware-Tool dessen Name ich nichtmehr kenne. Die Datei ist auch seit einem HDD-Crash vor 2Jahren weg, ich erinnere mich aber lustigerweise noch an den Aufbau und könnte die ALU entsprechend neubauen *happy*
@Multi-GPU:
das Problem ist wie einige male Angedeutet der Syncronisationsaufwand. Es sit nötig eine Steuereinheit der GPU-Cores überzuordnen, die sehrschnellen Zugriff auf die Cores sowie den Inhalt des VRAMS besitzt. Wenn man das weiterführt ist es tatsächlich einfacher die Recheneinheiten zu vervielfachen und Effizenter zu Organisieren, um extreme Latenzen zu vermeiden.
EDIT: Es wäre viell möglich am Thread-Dispatcher einen Komunikationslink nach außen (oder vier ;D) anzubringen, der dann zusammen mit den Anderen in GPU1; GPU2; GPU3 die Instructionen auf die 2-4 GPU-Cores verteilt. Der TD bekommt schließlich die fertig compilierten Vertex/Pixel/Compute Anweisungen die nurnoch verteilt werden müssen. Problem ist das trotzdem zwei- bis vierfach die selben Anweisungen Compiliert werden müssen. Viell ist es besser dann schon am Command-Prozessor anzusetzten, den der saugt sich die Anweisungen aus dem Speicher und schickt sie zum compilen (mit Compilen ist hier das Transformieren der Daten zu ALU-Verständlichen Daten gemeint). Der Sideport ist am Hub angeschlossen und hat indirect zugang zum Command Prozessor und zum Speicherinterface der GPU, es wäre also durchaus schon möglich gewesen, wenn man diesen benutzt hätte, die GPUs bei einer 4870X2 auf nahe zu die doppelte Leistung zu beschleunigen und das AFR hinter sich zu lassen. Woran es genau scheitert ist ungewiss.
@5D-ALUs bzw. SIMDs in der R600-RV870:
"Ich versuchs auch mal zu erklären.
Architektur:
- Der RV870-Chip(Stream-Prozessor) besteht aus 20 SIMD-Engines, die unabhängig voneinander arbeiten
- Jede SIMD-Engine ist in 16 ThreadProzessoren unterteilt, die stets die gleiche Instruktion ausführen(ein VLIW).
- Jeder Thread-Prozessor hat 5 skalare Alus(Stream-Cores), die von einem VLIW gesteuert werden
Ablauf:
- Alle 4 Takte führt eine SIMD-Engine ein identisches VLIW für eine Wavefront(=Bündel aus 64 Threads) aus
- In Takt0 wird das VLIW für die Threads 0-15 ausgeführt, Takt2: Threads 16-31, Takt3: Threads 32-47, Takt4: Threads 48-63. Jeweils von den 16 Threadprozessoren.
- In jedem VLIW sind 5 skalare Instruktionen kodiert, die keine Abhängigkeit untereinander haben. Eine Instruktion davon kann komplex sein(sin/cos), die anderen 4 MAD.
=> Dieses 5D-VLIW wurde vom Compiler erzeugt und ist danach fix.
Wenn der (Shader-)-Sourcecode nicht genug unabhängige Instruktionen ermöglicht, wird das VLIW mit bis zu 4 NOPs aufgefüllt, und die Effizienz sinkt entsprechend auf bis zu 20%.
Zusammenfassend: Je SIMD-Engine und Taktzyklus werden also bis zu 16x5=80 skalare Instruktionen abgearbeitet. Auf dem gesamten Chip also 20x80=1600. " - Nighthawk13 @3DCenter
Anhang:
ich denke das bei ca. 10-12nm für unsere herkömmliche Bauweise ersteinmal schluss ist, dann nach geht das Effizenz-Rennen los.
Es wird endlich ein Weg gefunden der Overhead beseitigt, der entsteht wenn ein Dreieck ein Anderes überzeichnet.
Viell macht man sich sogar die Mühe von Handoptimierung^^ NAND+NAND=>NAND+NOT=>AND und solche Scherze x)
Es könnten die Schaltwege der Transistor Ein-/Ausgänge angepasst werden, die Gates mit Materialien erstellt werden, die geringere Schaltzeiten ermöglichen, um eine Taktsteigerung zu ermöglichen.
LG