AW: Ein Gerücht und nicht mehr: Nvidia soll Release der GTX 680 auf Februar vorziehen
Skysnake studiert ja so etwas in der Richtung. Der hat da mehr als genug Brain
Wenn ich von den Redis niemanden fragen könnte, würde ich Skysnake fragen.
Mir ist im Forum, dass ich seit 3 Jahren begleite, nur Skysnake aufgefallen. ( Mods außen vorgelassen, wovon einer auch meinen vollen Respekt verdient )
Danke für die Blumen, und natürlich kann man mich immer fragen, man muss halt nur darauf gefasst sein, eine ausführliche Antwort zu bekommen, und eventuell etwas zu warten
Da Skysnake unser GPGPU-Fetischist ist und AMD- und Nvidia-Karten gerne zum "Spielen" missbraucht, gibt es wie schon einige Antworten hier, ganz Interessante Dinge zu lesen.
Zur Zeit komm ich leider weder zu dem einen noch zu dem anderen groß
Einfach zu viel zu tun... Ich hab in den letzten 4 Monaten vielleicht 3-4 mal gezockt, und etwa genau so oft mein Windows angeworfen. Aktuell läuft eigentlich nur mein Linux und das auch meist nur um per ssh auf den Rechnern in der Uni rum zu hirschen.
Selbst Musik hör ich zur Zeit öfters als das ich zock. So alle 2-3 Tage gönn ich mir mal ne Stunde bis zwei.
[/quote]
Mhh z.B:
Magischer Skysnake, soweit mir bekannt unterstützt Fermi kein präemptives Verfahren. Wie wahrscheinlich hälst du solches für Kepler, wie wahrscheinlich das man einen Virtuellen Adressraum für X-86 bereit stellt und wenn ich einwerfen dürfte, hat Nvidia es überhaupt nötig so etwas für die Konkurrenz bereit zu stellen, wenn man sich mit zukünftigen Projekten vllt selbständiger engagieren will?[/QUOTE]
Nix magisch
Bin doch kein Fabelwesen oder etwa doch?
Ok, nu aber wieder ernst.
Präemtivesheduling hat keine aktuelle GPU, ob GCN es nu kann oder nicht weiß ich nicht, da AMD ja meint den Software Developer Guide nicht online zu stellen
. Ob Kepler das kann ist schwer zu sagen. Es wäre aber auf jeden Fall SEHR geschickt für so manche Sachen. Aktuell muss man sich, da es eben kein präemtivesheduling gibt, bei manchen Problemen echt das Hirn verrenken, um ne Lösung zu finden, bei der es keine Deadlocks gibt
Man würde halt komplett neue Möglichkeiten erhalten um gewisse Probleme zu lösen. Ich glaub aber eher nicht, dass das mit Kepler kommt. Bei GCN wars eine verdammte überraschung, und so was macht man nicht "mal eben". x86 Adressraum halte ich für sehr sehr sehr wahrscheinlich. Ein gemeinsamer Adressraum spart dir halt das hässliche hin und her kopieren in Buffern. Das kostet 1. Programmieraufwand, 2. haste jedes mal nen OS-Trap (wenn ich mich recht erinnere) und 3. dauert so ne Kopierorgie auch wieder Zeit. Da ist der gemeinsame Adressrau einfach sehr angenehm für den Programmierer. Wie sich das im Einzelfall positiv/negativ auf die Performance auswirkt muss man eben im Einzelfall sehen. Daher wird es wohl weiterhin beides geben. Explizietes kopieren, quasi als prefetch und eben das impliziete kopieren.
Das Heft mit GCN seit vorletzter Woche draußen, zu Kepler sage ich nicht mehr als das, was an Leaks oder Speku herum geistert. Btw ist Skysnake völlig auf GGPU geeicht, der träumt da nachts sicher auch von
Das stimmt sogar fast schon
Unter der Dusche oder auch im Halbschlaf morgends, sind mir teils schon Lösungen für parallele Algorithmen eingefallen.
Ja, ich frage mich immer noch beim GCN, wieso er sich so ähnlich wie die alten VLIW-GPUs verhält? Da wo die VLIW-Architektur stark war, ist es GCN auch, da wo sie schwach war, ist GCN es auch.
Ich habe dort eig. eher Nachteile bei bestimmten Spielen oder Bitcoin erwartet.
Nicht wirklich. Da wo VLIW extrem stark war, hält GCN mit, was nicht unbedingt zu erwarten war, in anderen Bereich, wo VLIW gegen Fermi im Hintertreffen war, hat GCN jetzt aufgeschlossen. Zumindest wenn du Gamin mal außen vor lässt. Die GPGPU-Leistungssteigerungen sind außer in den VLIW Paradedisziplinen deutlich höher als im Gaming. Es wurde aber auch vor allem viel drum rum gemacht. ECC für Caches und RAM z.B. Das war teils für die bisherigen HD-Serien einfach ein KO-Kriterium. Das fällt nun weg. Man sieht ja aber an GCN, das sich bzgl Frontend, also dem ganzen FFU gedönze der Graphikberechnungen, wenig getan hat. Das ist Evolution, keine Revolution
Marc kannst du eig. so nebenbei eine Sache erklären?
Bei AMD werden doch Threads zu einer 64 Threads großen Wavefront gebündelt? 4x16 Vec Breite Einheiten.
Bei Nvidias Fermi waren es doch 2x 16 Vec zu 32 Threads/Warp. War die Aufteilung beim G104 nicht 3x 16 Vec? Wieso hat sich da eig. nichts am Warp verändert?
Wenn Kepler jetzt mit 1x32 Vec kommt was hätte das eigentlich für Vorteile/Nachteile?
Oh je, das alte Problem mit nVidia und OpenCL. Die gehören echt erschossen, dass die in OpenCL Docus CUDA Sprech verwenden -.-
Wer das verbrochen hat gehört echt sofort gefeuert...
Also.. Das ist historisch bedingt von CUDA 1.0 Da hatte ein warp eben 32 Threads. Das ist die kleinste Unterteilung, die du haben kannst. Daran wird sich in absehbarer Zeit auch nichts ändern, weil du dann die ganzen grundlegenden Optimierungen für die ganze CUDA-Software neu machen muss. Nicht gut
Also früher hatten die Karten 8 ALUs in einem SIMD Block, wenn ich mich recht erinnere, und die haben eben immer 4 Takte lan einen Warp ausgeführt. 4*8=32. Damit hat man halt erreicht, das man nur alle 4 Takte einen neuen Befehl an die SIMD Unit austeilen muss. Bei Fermi kann man jetzt gleich 2 warps starten auf einer SIMD unit. Einen sogenannten Doublewarp (glaub hies so). Das sind dann also 64 "Threads", die man beackern muss. GF1x0 sollte das mit seinen 2x16 Vec ALUs in 2 Takten machen, bevor ein neuer Befehl vom Sheduler kommt. Das passt auch gut zum ALU/Uncore Takt von 2:1, würde ich jetz sagen. Beim GF104, siehts jetzt wieder etwas anders aus. Da sind es glaub ich gleich 3 Warps, die man startet, welche natürlich alle aus dem gleichen Programm kommen müssen (!) und arbeitet die eben auch in 2 Takten ab. Man sollte also 3 Warp-Sheduler haben. nVidia lässt sich darüber glaub aber auch nicht groß aus, da man GF104 erst spätr brachte. Im Software Developer Guide wird glaub nur GF1x0 betrachtet.
PS: Ich hab mal kurz gegoogelt. Gipsel ausm 3D-Center.org hat sich glaub dazu auch mal ausgelassen. Kannst ja mal schauen ob das auch passst:
GF104 - Architektur-Diskussion [Archiv] - 3DCenter Forum
So nun zu AMD.
Die haben nie Warps gehabt, weil das CUDA-Sprech ist
Die haben Wavefronts, wie es in OpenCL-Sprech richtig heißt (sollte sich nVidia mal merken.....).
Die hatten ja sehr lange VLIW. Ergo war/ist eine Wavefront auf jeden Fall schon mal ein Vielfaches von 5. Da man wie bei nVidia auch wenige Instructionen decoden will, hat man einfach mehr VLIWs auch zu Gruppen zusammengefasst. Das warn bei VLIW5 eben 80er ALU Gruppen (5[VLIW]*16=80) und bei VLIW4 sind es eben 64 ALUs in einem Block (4[VLIW]*16=64). Naja und bei GCN sind es 4*16VecSIMD=64. Man ist also von 5/4er Granularität bei VLIW für eine Instruction auf 16 runter, was vorher 16 mal multipliziert wurde und nun noch 4 mal.
Hoffe das ist klar
Warum fragst du eigentlich, wenn du die Antwort kennst?
(Kommt eigentlich aufs gleiche raus, was wir erzählt haben oder? Wobei ich deiner Erklärung nicht 100% folgen kann mit den 4x32. Ist aber auch nicht wichtig, wie das jetzt genau im Detail gemacht wird. Man brauch 64 Threads und gut ist
)
AMD erledigt das etwas anders. Die haben pro Compute Unit 4 SM, jeweils 16 Vektorbreit. Also 1x4x16= 64. Diese 64 stellen bei AMD das Bündel dar.
Warp und Wavefront ist das gleiche. Nvidia nennt es Warp, AMD Wavefront. Bei Nvidia ist der Warp 32 Vecs/Threads what ever breit/lang
Bei AMD 64.
Jetzt ist es auch scheinbar kein Zufall wieso 32 ein Teiler von 64 ist. Scheinbar müssen die Threads so verpackt werden, dass es bei diesen "klassischen" Zahlen und ihren gemeinsamen Vielfachen bleibt.(Kompatibilitätsgründe)
Kurz weiter--> 32 CUs x 4 x 16 = 2048 = 32 Wavefronts, weil jede CU eine Wavefront bündelt.
Aufgrund dieser Rechnung, war es damals klar wieso manche spekulierten Zahlen über die SIMD-Einheiten von Barts Müll waren, weil sie die Wavefront von 64 verändert hätten. Also das Bündel wäre dann glaube ich aus 48 Threads gewesen? Hätte man theoretisch machen können, aber dann wäre das aus welchem Grund auch immer ( Skysnake/Marc?) eine zu große eigene Wurst gewesen und hätte das Feld unnötig gesplittet.
Guckst du oben. Die 64 sind klar, weil man jeweils 16 VLIW ALUs zusammen fasst.
Es hat scheinbar auch technische Vorteile/Nachteile es so zu machen. 32 Warps sind scheinbar für kleine Auflösungen performant, während eine Wavefrontgröße von 64 für hohe Auflösungen von Vorteil sein kann.
Beim G104 wurden die SMs aber umgestellt, soweit ich noch in Erinnerung habe, von 2x16 Vec zu 3x16 Vecs. Das würde ja ein Bündel von 48 ergeben, tut es aber nicht. Ich verstehe jetzt nicht wieso oder wo der Denkfehler bei mir ist.
Das hat eher rein historische Gründe, die eben Gründe im HArdwaredesing haben.
Du musst immer bedenken, das man schöne Zahlen haben will, und das sind im PC Bereich alle Zahlen für die 2^n gilt, da man in einem binären System ist.
Ich würde ein paar Tage verstehen, aber mein Gott ich brauch doch nicht 2 Wochen um von DE nach IT zu kommen. 
