Maxwell GM1xx Architektur-Thread

[AnarchX]

NVCC -arch sm_50 and a test program reveal:

64K of shared memory
64K 32-bit registers
max threads per block remains at 1024
max blocks per SM remains at 64
max threads per SM remains at 2048
https://devtalk.nvidia.com/default/topic/690631/cuda-programming-and-performance/so-whats-new-about-maxwell-/post/4125451/#4125451

Diagramme zu SMX und SMM von Damien Triolet @ Hardware.fr (http://www.hardware.fr/news/13568/nvidia-lance-geforce-gtx-750-ti-750-maxwell.html), die wohl eher der Realität entsprechen als was man zum Kepler Launch gezeigt hat.

Diverse Direktmessungen:
Speicherlatenz GM107: http://media.bestofmicro.com/C/Q/422954/original/latency-2-.png (Quelle (http://www.tomshardware.com/reviews/geforce-gtx-750-ti-review,3750.html)); http://www.extremetech.com/wp-content/uploads/2014/02/SiSoftSandra.png
SHA2: http://media.bestofmicro.com/B/M/422914/original/crypto.png (Quelle (http://www.tomshardware.com/reviews/geforce-gtx-750-ti-review,3750-17.html))
Vec2-Performance: " In unseren Messungen haben wir besonders beim Absetzen von Vec2-Anweisungen eine rund 50 % höhere Effiizenz gegenüber Kepler feststellen können. " (http://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/Tests/Geforce-GTX-750-Ti-im-Test-Maxwell-1109814/)

[Gipsel]

https://devtalk.nvidia.com/default/topic/690631/cuda-programming-and-performance/so-whats-new-about-maxwell-/post/4125451/#4125451
Maximale Anzahl von Blöcken ("Thread"-/Workgroups) pro SM ist bisher nur 16 gewesen (und irgendwo habe ich gelesen, daß das jetzt 32 sein sollen). Was gleich bleibt, ist die maximale Anzahl Warps pro SM, das sind die 64. Auf die kommt man bisher nur mit 128er Workgroups (4 Warps), mit Maxwell dann wohl auch mit 64ern (2 Warps).
Zum Vergleich: GCN unterstützt bis zu 16 Workgroups pro (nur halb so großer) CU. Das gilt offenbar aber nur für Workgroups >64 Workitems (also konkret 128er Workgroups [eigentlich alle mit >64 und <129 Workitems], noch größere sind dann durch die maximale Anzahl der Workitems/Wavefronts limitiert). Für Workgroups mit 64 (oder weniger) Workitems nutzt AMD den Fakt, daß die Ausführung dann inhärent synchronisiert ist (weil das dann nur eine Wavefront ist), so daß die vollen 40 Wavefronts (2560 Workitems oder "Threads"), die maximal auf einer GCN-CU laufen können, genutzt werden können (bei 128er Workgroups sind es durch die Limitierung auf 16 Gruppen nur 32 Wavefronts). Eventuell nutzt nV diesen Trick jetzt auch, könnte aber tricky werden wegen dem vermutlich doch noch etwas dynamischerem Scheduling.

Die Registerzahl bleibt bei Maxwell praktisch konstant, man hat im Prinzip nur die praktisch redundanten ALUs entfernt (Registerbandbreite zu deren effektiven Nutzung fehlte), wie ich schon im Maxwell-Thread schrieb. Im Übrigen bin ich gar nicht so überzeugt, daß es bei Kepler wirklich diese Zweier-Gruppen mit einer geteilten vec32-ALU gab. Das wäre nämlich wirklich hirnverbrannt gewesen. Mein Tipp wäre beinahe, daß jeder Scheduler drei private vec16-ALUs hatte (im Prinzip einen GF104 style SM). Dagegen spricht auch nicht, daß der Scheduler jeden Takt 2 Instruktionen absetzen kann. Das kann man auch non-blocking gestalten (Issue dauert ein Takt, die vec16-ALUs hätten dann einen Throughput von 2 Zyklen, stehen also beim nächsten Issue nicht zur Verfügung). Dies paßt prinzipiell gar nicht so schlecht mit dem ansonsten doch etwas mysteriösen Int32-Durchsatz, der nämlich genau 10/12 des float32-Durchsatzes beträgt (Int-Anweisungen erzeugen regelmäßig eine Pipeline-Bubble in den ALUs von 2 Takten) genau im Bereich der offiziellen Latenz (~11 Takte, mein Tipp wäre float32 hat 10 Takte, int32 aber 12 Takte mit 10/12 Durchsatz, müßte mal einer genau nachmessen).

[Ailuros]

* Nach wie vor DX11.0.
* 16 pixels/clock/GPC fuer Maxwell gegen 8 pixels/clock/GPC bei Kepler.
* 4xFP64 SPs/SMM auf GM107.

http://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/Tests/Geforce-GTX-750-Ti-im-Test-Maxwell-1109814/

[Gipsel]

4xFP64 SPs/SMM auf GM107.

http://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/Tests/Geforce-GTX-750-Ti-im-Test-Maxwell-1109814/
1:32 DP? Da kann man dann ja auch bald den Taschenrechner nehmen :freak:. Okay, ist nicht ganz der Zielmarkt.

[Skysnake]

Wenn man jetzt wirklich 32 Blöcke starten könnte, wäre das eine feine Sache.

Zu den dedizierten FP-Units:
Ja ne is klar....

Bei dem geringen Durchsatz hätte man sich die auch gleich sparen können, wenn es Sie denn wirklich gibt... Und meine Meinung kennt dazu ja wohl jeder...

[Coda]

Sie wollen halt das gleiche Featureset über alle Chips und keine Abwärtskompatibilität brechen. Finde ich ok.

[Ailuros]

Wenn man jetzt wirklich 32 Blöcke starten könnte, wäre das eine feine Sache.

Zu den dedizierten FP-Units:
Ja ne is klar....

Bei dem geringen Durchsatz hätte man sich die auch gleich sparen können, wenn es Sie denn wirklich gibt... Und meine Meinung kennt dazu ja wohl jeder...

Na wenigstens hab ich versucht Dich zu bremsen, ist aber auch verdammt schwer mit Dir wenn Du Gas gibst :freak:

[Skysnake]

Ja, wenn ich von was überzeugt bin, hab ich mir mehr als 1-2 Minuten dazu gedanken gemacht, und um mich davon wieder ab zu bekommen brauchts halt echte Argumente/Beweise.

Die Erfahrung gibt mir dabei aber Recht. In geschätzt >90% der Fälle, liege ich mit meinem "Bauchgefühl" richtig. Wobei es sogar so ist, das ich meistens sogar gern falsch liegen würde...

[Ailuros]

Ryan Smith@Anandtech bestaetigte bei B3D dass GM107 @28HP direkt von NV kommt.

http://forum.beyond3d.com/showpost.php?p=1828652&postcount=1120

Kann jemand das obrige von Damien entziffern? Die DP unit ausserhalb der partition fuer Maxwell was was bedeuten soll? :confused:

[Skysnake]

Autsch.

12kB L1+Texturcache sind echt nicht viel für 64 ALUs. Vor allem sind es halt wirklich immer nur diese 12kB. Das ist doch deutlich weniger als bei Kepler oder gar Fermi noch möglich war, und gerade sehr irreguläre Programmabläufe haben schon teils gut vom großen L1 Cache profitiert.

Ansonsten, hat das gerade jemand im Kopf, wohin der Const-Memory von OpenCL/CUDA gemapped wurde? Das landete doch wenn ich mich recht erinnere eben im Texturcache oder nicht???

Wenn ja, ist das für die Anwendungen bei denen man das als Optimierung genutzt hat nen richtiger Schuss in den Ofen. :(

@Ailuros:
Ich versuchs mal. ;)

Wenn du wirklich 2 FP64 Units zwischen den SMM Partitionen aufgeteilt hättest, wäre das vom Sheduling wie gesagt wurde einfach total bekloppt, weil du die Sheduler nicht mehr unabhängig laufen lassen kannst. Es wäre also keine gute Idee das wirklich so zu machen.

Ansonsten mal ne kleines Gedankenspiel.

Was bedeutet es denn nach dem Ausführunsmodell von nVidia, wenn man nur 2/4 FP-Units pro Block hätte?

Richtig, um einen einzelnen Warp auszuführen brüchte man 8/4 Takte. Das klingt doch gar nicht so schlecht oder?

Was das "außerhalb der Parition" betrifft, so kann das zweierlei bedeuten.

1. Man hat einen FP64 SMM, was ich eher nicht glaube, da man auf 20 kommen würde, und eben das Sheduling auch anders handhaben müsste, bzw eben bei SP+DP keinen oder kaum Einbrüche bei SP sehen müsste.

2. Man hat die 4 DP-Units zwar im SMM, aber als eigene Partition, die nur die Ressourcen mitnutzt. Das würde durchaus gehen. Für den SharedMem ist es egal, ob da nochmal nen Block dazu kommt oder nicht, weil er eh schon vier bearbeiten muss, und für den L1 sollte es auch egal sein, da ja immer expliziet gesynct werden muss.

Ich tendiere eher in Richtung 2., wobei ich nach ein bischen Überlegung auch 1. nicht ausschließen würde. Wäre wohl sogar die elegantere Lösung. Die Logik um 6 Blöcke an zu sprechen muss im Prinzip eh da sein, weil man bereits 5 hat. Eventuell hängt man noch andere Sachen dran, aber ich vermute mal es sollte ohne Mehraufwand möglich sein.

Dann könnte man auch die SP-SMM eventuell clock-gaten oder sonst was, wenn man DP benutzt, oder es einfach laufen lassen. Kann man ja mal testen, wie die SP-Performance aussieht, wenn DP-Instructionen dazwischen wirft ;)

Ganz ohne DP in den SMM könnte man das Design auf jeden Fall maximal schlank halten. Die Frage ist nur, wie man die Energieeffizienz bei DP oben halten will. Klar wenn man clock oder gar powergaten könnte, würde sich das sicherlich rechnen, da man nur noch nen kleinen CHipteil versorgen müsste, aber ich bezweifle, das man das machen kann. Die Latenzen wären sicherlich zu hoch.

Innerhalb eines SMM die DP-Units zu separieren, wäre da durchaus Sinnvoller. Man skaliert gut und man kann eben auf SP im Fokus der Effizienz designen. DP ist dann halt entsprechend schlecht, da deutlich längere Signallaufwege usw usw.

Wie gesagt, man sollte sich mal Code mit SP-DP Mischung anschauen, wie das Skaliert, dann kann man eventuell was herausfinden, was da nun wirklich abläuft.

[PCGH_Carsten]

Kepler hatte 16, 32 oder 48 kiB L1 - für alle vier Scheduler-Partitionen samt 192 ALUs/6 FMA32-Blocks. Da sind 12 kiB auf einmal doch richtig viel - naja, oder zumindest gar nicht so furchtbar wenig.

DP außerhalb: Der Verdacht liegt nahe, dass Nvidia die Hölle aus den einzelnen Parititionen handoptimieren wollte, sie dafür aber möglichst über alle Chips konstant halten muss, damit die Arbeit nicht wieder anfällt. Für größere/andere Modelle brauchen sie "nur" das Inter-Partition-Zeugs verändern.

[Ailuros]

DP außerhalb: Der Verdacht liegt nahe, dass Nvidia die Hölle aus den einzelnen Parititionen handoptimieren wollte, sie dafür aber möglichst über alle Chips konstant halten muss, damit die Arbeit nicht wieder anfällt. Für größere/andere Modelle brauchen sie "nur" das Inter-Partition-Zeugs verändern.

Dumme Frage: spart es Strom?

[PCGH_Carsten]

Dumme Fragen hab ich selbst genug. ;)
Aber ich könnte mir vorstellen, dass Power-Gating außerhalb der Scheduler-Partitionen (SP) sich zumindest positiv auf die SP-Fläche auswirkt, da man "innerhalb" eben keine Power-Inseln bauen muss.

[Skysnake]

Kepler hatte 16, 32 oder 48 kiB L1 - für alle vier Scheduler-Partitionen samt 192 ALUs/6 FMA32-Blocks. Da sind 12 kiB auf einmal doch richtig viel - naja, oder zumindest gar nicht so furchtbar wenig.

Ja da ist wenig, weil es eben jetzt nur noch maximal 24kB sind und nicht mehr maximal 48kB. Klar hat man insgesamt mehr SharedMemory+L1, aber der L1 war dahingehend wirklich schick, das man halt nichts optimieren musste.

Der SharedMemory bringt einem halt echt nur was, wenn man ihn auch wirklich expliziet nutzt.

Ich hab jetzt nochmal ne Folie gefunden bzgl ConstMemory. Das waren bisher immer 8kB pro SM. Und dann nochmal 6-8kB an Textur-Cache dazu.

Der L1 wäre damit dann wohl nur 6-4kB groß, wenn das unterteilt ist. Hoffen wir mal, dass der Textur-Cache komplett im L1 aufgeht, und nur eben dementsprechend genutzt werden kann.

Das wäre dann auch gar nicht so blöd. Bei Compute hat man 12kB L1 und bei Graphics 12kB TExturcache. Bei Graphics soll der L1 ja nicht soo viel bringen meines Wissens nach oder?

Auf jeden Fall etwas strange, was die da mit den Caches gemacht haben. :freak:

Dritte Generation drittes Cache/Memory-System. Das ist echt unschön. Ich hoffe, die haben sich jetzt grundlegend auf was geeinigt und bringen mit Volta dann nicht schon wieder nen neues Cache/Memory-System, abseits von reinen Größenskalierungen.

[AnarchX]

AIDA64 OpenCL GPGPU benchmark results for GTX750:

Single-Precision FLOPS (FP32): 1190 GFLOPS
Double-Precision FLOPS (FP64): 37.72 GFLOPS
24-bit Integer IOPS: 399.3 GIOPS
32-bit Integer IOPS: 399.3 GIOPS
64-bit Integer IOPS: 82.76 GIOPS
https://devtalk.nvidia.com/default/topic/690631/cuda-programming-and-performance/so-whats-new-about-maxwell-/post/4126639/#4126639

[PCGH_Carsten]

Die Folie interessiert mich. Hast du einen Link?

Kepler:
Sechs FMA32-Blöcke (und L/S, SFUs sowie DP) teilen sich 16 kiB (in der Standard-Konfig), dazu gibt's max. 48 kiB Shared Memory für alle.

Maxwell:
Je zwei FMA32-Blöcke teilen sich je 12 kiB (unveränderlich und die sind nicht unterteilt, weil TMU und Cache geshared sind). Dazu gibt's 64 kiB kiB Shared Memory für alle vier Scheduler inkl. Anhang.

Einen Vorteil für Kepler gibt's dabei wohl nur unter ziemlich speziellen Voraussetzungen: Ultra-niedrige Occupancy von nur einer Scheduler-Partition (oder SMK-Hälfte meinetwegen), sodass der gesamte L1 einem Thread-Block zur Verfügung steht.

Ich kenne keine Programme, die auf eine bestimmte L1-Größe optimiert sind - soweit ich weiß (und frag nicht nach Quellen), werden darin bei Kepler im Gegensatz zu Fermi auch hauptsächlich Register Spills abgefangen.

[Skysnake]

Ich denke du meinst mich.

Hab ich aus folgendem Vortrag raus. Da gibts auf Seite 31 gibts ne nVidia-Folie, die alles zusammenfasst. Ich hatte das Orginal von nVidia leider auf die Schnelle nicht gefunden.

http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=0CGEQFjAG&url=http%3A%2F%2Fcoitweb.uncc.edu%2F~abw%2FITCS4010S13%2FGPUMemories.ppt&ei=18MEU8mIMoPPtAbpkoH4BQ&usg=AFQjCNHLZQnkQuvjvJC7PDkmFk3EivnlpA&bvm=bv.61535280,d.Yms&cad=rja

EDIT:
Bei Fermi und Kepler haste nicht nur 16kB für 128/192 ALUs, sondern bis zu 48kB für 128/192 ALUs. Du kannst dir ja aussuchen, ob es 16/48 32/32 (nur Kepler) oder 48/16 kB L1/SharedMemory sein soll. Es passiert durchaus mal, das man den SharedMemory nicht sinnvoll nutzen kann. Dann macht man bisher einfach den L1 maximal groß, bzw andersrum. Zumindest ich fange normal immer mit nem maximal großen L1 an und schau dann, was ich durch den SharedMemory noch rauskitzeln lässt.

Kepler kann an sich einem Thread mehr REgister zur Verfügung stellen, halt maximal 255. Das wird aber laut einigen Leuten die sich sehr sehr sehr intensiv mit GPGPU beschäftigen praktisch nie im realen Einsatz gebraucht.

Der L1 ist halt ganz schick, wenn man auf ähnliche Daten lesend zugreifen muss, oder allgemein halt nicht apriori klar ist, was man nun lesen/schreiben muss.

[PCGH_Carsten]

Danke - eine Nvidia-Folie ist's aber nicht, nur weil sie grün ist. Drunter steht als Quellenangabe Wikipedia. Und deren Angabe zum Texturcache zweifle ich jetzt ganz einfach mal an. Da gibt es zig-fache Aussagen, Infografiken usw. die durchweg von 12 kiB per Quad-TMU sprechen, dass ich davon erst einmal ausgehe, bevor etwas anderes nachgewiesen ist.

Was L1 angeht: Das hier ist halt primär erstmal eine Geforce, keine Quadro oder Tesla. Wenn du sowas brauchst, müsstest du auch sowas kaufen (oder eben das Pendant von AMD, wenn dir das mehr zusagt wegen OpenCL). Standardmäßig sind die Karten eben auf 16 kiB L1 eingestellt und mir sind bisher keine Consumer-Programme bekannt, die daran was drehen.

Ich kann mir als Nicht-Programmierer ehrlich auch nur schwer Probleme vorstellen, die nicht von Shared Memory profitieren, aber von einem gemeinsam genutzten L1-Cache. Lesend, also als Broadcast-Source für alle sehe ich keinen Grund, warum das nicht mit Shared-Memory gehen sollte.

Schreibend - Hm. Wenn ich das komplette SMX auf den L1-Teil des Shared-Memory schreibend loslasse, sehe ich nur riesengroße Konfusion.

Nach meinem Verständnis sollte so ein gemeinsamer L1-Cache besonders vorteilhaft arbeiten, wenn zufällige Werte gelesen und geschrieben werden. Wenn die aber zufällig sind, musst du die Kapazität unter den beteiligten Verbrauchern aufteilen - im statistischen Mittel dann wohl etwa gleichmäßig. Dann hast du max. 48/4= 12 kiB pro Scheduler+Anhang - oder schlimmer: 48/6=8 kiB pro FMA32-Block.

Aber wie gesagt, das sind die Überlegeungen eines Nicht-Programmierers, da wird es in der akademischen Welt sicherlich viel theoretischen Gegenwind geben. :)

[Skysnake]

Danke - eine Nvidia-Folie ist's aber nicht, nur weil sie grün ist. Drunter steht als Quellenangabe Wikipedia. Und deren Angabe zum Texturcache zweifle ich jetzt ganz einfach mal an. Da gibt es zig-fache Aussagen, Infografiken usw. die durchweg von 12 kiB per Quad-TMU sprechen, dass ich davon erst einmal ausgehe, bevor etwas anderes nachgewiesen ist.

Stimmt, ;D

Mir kam die Zusammenstellung nur so ungemein bekannt vor. Genau die gleich Aufteilung gibts nämlich auch von nVidia. Dann muss ich wohl doch nochmals suchen, ob ich das von nVidia finde. :(


Was L1 angeht: Das hier ist halt primär erstmal eine Geforce, keine Quadro oder Tesla. Wenn du sowas brauchst, müsstest du auch sowas kaufen (oder eben das Pendant von AMD, wenn dir das mehr zusagt wegen OpenCL). Standardmäßig sind die Karten eben auf 16 kiB L1 eingestellt und mir sind bisher keine Consumer-Programme bekannt, die daran was drehen.

Das hat an sich gar nichts mit Consumer<->HPC oder sonst was zu tun, sondern rein mit dem Problem, das man bearbeitet, wobei eigentlich gerade bei Consumer-Software eher zu erwarten ist, das man die 48kB-Einstellung für den L1 nutzt. Dann kann man sich nämlich die SharedMemory-Optimierung einfach komplett sparen.


Ich kann mir als Nicht-Programmierer ehrlich auch nur schwer Probleme vorstellen, die nicht von Shared Memory profitieren, aber von einem gemeinsam genutzten L1-Cache. Lesend, also als Broadcast-Source für alle sehe ich keinen Grund, warum das nicht mit Shared-Memory gehen sollte.

Du schreibst es doch später selbst ;)

"zufällige" Werte, die man liest/schreibt z.B.



Schreibend - Hm. Wenn ich das komplette SMX auf den L1-Teil des Shared-Memory schreibend loslasse, sehe ich nur riesengroße Konfusion.

Nö, du hast ja keine Cachecohärenz/ordering zwischen den Threads, wenn du nicht expliziet syncst. Die Gedanken musste dir eh machen, wie wann wo was zu laufen hat. Das ist an sich kein Problem.

Mit dem L1 sparste dir halt nur das expliziete hin und her kopieren, das du mit dem SharedMemory eben machen musst.

Zudem hat mir meine Erfahrung gezeigt, dass der SharedMemory auch erst was bringt, wenn man die Daten auch wirklich oft genug wiederverwendet. Greift man nur wenige male drauf zu, wird man kaum schneller, und man hat nen haufen Zeit in ne Optimierung versenkt, die nichts bringt, teilweise das Programm sogar langsamer macht :(



Nach meinem Verständnis sollte so ein gemeinsamer L1-Cache besonders vorteilhaft arbeiten, wenn zufällige Werte gelesen und geschrieben werden. Wenn die aber zufällig sind, musst du die Kapazität unter den beteiligten Verbrauchern aufteilen - im statistischen Mittel dann wohl etwa gleichmäßig. Dann hast du max. 48/4= 12 kiB pro Scheduler+Anhang - oder schlimmer: 48/6=8 kiB pro FMA32-Block.

Aber wie gesagt, das sind die Überlegeungen eines Nicht-Programmierers, da wird es in der akademischen Welt sicherlich viel theoretischen Gegenwind geben. :)
Jaein, wenn du lesend die Daten nur brauchst, quasi wie bei ner Lookuptable, dann musste das nicht aufteilen. Kommt halt immer drauf an, was man genau machen will. Genau aus dem Grund war die Möglichkeit der Größeneinstellung zwischen L1<->SharedMemory eigentlich ziemlich schick :up: Man hatte halt mehr Freiheiten als Programmierer, und hat sich halt immer genau das genommen was einem am Besten reingelaufen ist ;)

Da bin ich schon traurig, dass das Feature weg fällt.

[PCGH_Carsten]

Das hat an sich gar nichts mit Consumer<->HPC oder sonst was zu tun, sondern rein mit dem Problem, das man bearbeitet, wobei eigentlich gerade bei Consumer-Software eher zu erwarten ist, das man die 48kB-Einstellung für den L1 nutzt. Dann kann man sich nämlich die SharedMemory-Optimierung einfach komplett sparen.
Die Geforces stehen standardmäßig aber auf 48 kiB SM, und als User kann man das auch nicht verändern. Daher mein Einwand. Das ist deine Aufgabe als Programmierer.


Du schreibst es doch später selbst ;)

"zufällige" Werte, die man liest/schreibt z.B.

Ich schrieb aber auch, dass sich damit die zufälligen Zugriffe der zusätzlichen Clients als nicht besonders hilfreich heraustellen dürften, da du dann die Kapazität wirklich unter die beteiligten Clients aufteilen musst und der Vorteil quasi verschwunden ist.



Nö, du hast ja keine Cachecohärenz/ordering zwischen den Threads, wenn du nicht expliziet syncst. Die Gedanken musste dir eh machen, wie wann wo was zu laufen hat. Das ist an sich kein Problem.

Mit dem L1 sparste dir halt nur das expliziete hin und her kopieren, das du mit dem SharedMemory eben machen musst.

Zudem hat mir meine Erfahrung gezeigt, dass der SharedMemory auch erst was bringt, wenn man die Daten auch wirklich oft genug wiederverwendet. Greift man nur wenige male drauf zu, wird man kaum schneller, und man hat nen haufen Zeit in ne Optimierung versenkt, die nichts bringt, teilweise das Programm sogar langsamer macht :(
Aha, dann dürfte der RFC dann ja bald Abhilfe schaffen.


Jaein, wenn du lesend die Daten nur brauchst, quasi wie bei ner Lookuptable, dann musste das nicht aufteilen. Kommt halt immer drauf an, was man genau machen will. Genau aus dem Grund war die Möglichkeit der Größeneinstellung zwischen L1<->SharedMemory eigentlich ziemlich schick :up: Man hatte halt mehr Freiheiten als Programmierer, und hat sich halt immer genau das genommen was einem am Besten reingelaufen ist ;)
Aber das ist es ja eben: Als Look-Up-Table habe ich strukturierte, zu lesende Daten - Optimalfall für Shared Memory.


(Komisch - oben beschwerst du dich, einen Haufen Zeit in Optimierungen zu versenken und nun kommt eine Architektur um die Ecke, bei der du diese Zeit direkt sparst und du beschwerst dich immer noch. :D)

[Skysnake]

Die Geforces stehen standardmäßig aber auf 48 kiB SM, und als User kann man das auch nicht verändern. Daher mein Einwand. Das ist deine Aufgabe als Programmierer.

Ich versteh gerade nicht, was du mir sagen willst. Es ist immer Aufgabe des Entwicklers das zu setzen. Das kannst du immer nur zur Compilezeit festlegen. Zumindest wüsste ich jetzt nicht, dass man das ändern könnte zur Laufzeit.


Ich schrieb aber auch, dass sich damit die zufälligen Zugriffe der zusätzlichen Clients als nicht besonders hilfreich heraustellen dürften, da du dann die Kapazität wirklich unter die beteiligten Clients aufteilen musst und der Vorteil quasi verschwunden ist.

Kommt darauf an, ob die "zufälligen" Zugriffe auf die gleichen Daten gehen, oder auf andere "zufällige" Daten.

Wenn jeder Thread was anderes liest klar, dann bringt das nichts, wenn man sich aber in einem gewissen Subset bewegt, das nicht zu groß wird, dann schon.


Aha, dann dürfte der RFC dann ja bald Abhilfe schaffen.

RFC :confused:


Aber das ist es ja eben: Als Look-Up-Table habe ich strukturierte, zu lesende Daten - Optimalfall für Shared Memory.

Wenn der Datenreuse aber zu gering ist von einzelnen Daten, dann bricht dir das schnell zusammen, weil du eben jeweils expliziet die Daten reinkopieren musst. Gerade wenn du aber eben nicht die ganzen Daten, sondern "nur" ein verstreutes Subset brauchst, bringt dir der SharedMemory halt nichts. Du kannst nicht alles rein laden, weißt aber nicht, was du brauchst. Mit dem SharedMemory biste da gekniffen. Der L1 hilft dir da ungemein.

Wie gesagt, der SharedMemory ist schön und toll, aber wenn man ihn dann einsetzen will, ist es auch nicht sooo selten, das man es einfach nicht schafft, ohn so einzusetzen, das er mehr Performance liefert. Das Problem muss halt "gutartig" genug sein. Dem L1 ist es scheis egal. Der funktioniert im Prinzip immer, so lange man sich nicht den Cache trashed.


(Komisch - oben beschwerst du dich, einen Haufen Zeit in Optimierungen zu versenken und nun kommt eine Architektur um die Ecke, bei der du diese Zeit direkt sparst und du beschwerst dich immer noch. :D)
Es gibt zwei Varianten

Haufen Zeit reinstecken -> aber keine Garantie, das es etwas bringt, und sogar "öfters" gar keinen Performancegewinn

vs.

Nen Compileflag umsetzen -> schauen was es bringt und eventuell über mehr Performance freuen.

Die Wahlmöglichkeit des L1/SharedMemory war/ist halt praktisch kein "optmierungs" Aufwand. Es ist eher die Quick&Dirty variante. Sowas gebe ich nur ungern aus der Hand.

[Gipsel]

Das wäre dann auch gar nicht so blöd. Bei Compute hat man 12kB L1 und bei Graphics 12kB TExturcache. Bei Graphics soll der L1 ja nicht soo viel bringen meines Wissens nach oder?Na klar bringt der was, aber man benötigt dafür meist sehr hohe Assoziativitäten. Es ist also schwierig, den gleichzeitig groß und schnell hinzubekommen.
Danke - eine Nvidia-Folie ist's aber nicht, nur weil sie grün ist. Drunter steht als Quellenangabe Wikipedia. Und deren Angabe zum Texturcache zweifle ich jetzt ganz einfach mal an. Da gibt es zig-fache Aussagen, Infografiken usw. die durchweg von 12 kiB per Quad-TMU sprechen, dass ich davon erst einmal ausgehe, bevor etwas anderes nachgewiesen ist.Direkt von nV (http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#compute-capabilities). Nur entweder GK110 oder GK208 haben 12kB pro Quad-TMU (angeblich je nach Chip 12kB oder 48kB für 16 oder 8 TMUs, hmm, wenig aufschlußreich), die anderen Keplers haben nur 12kB Texturcaches für alle TMUs eines SMx zusammen. Insofern sind die 2x12kB jetzt schon eine gewisse Verbesserung, auch wenn die Daten zumeist in beiden dupliziert vorliegen dürften, was die effektive Cachegröße also nur wenig über 12kB anhebt (aber es erhöht die Bandbreite [oder vermindert den Strombedarf für eine bestimmte Bandbreite]).
Ich kann mir als Nicht-Programmierer ehrlich auch nur schwer Probleme vorstellen, die nicht von Shared Memory profitieren, aber von einem gemeinsam genutzten L1-Cache. Lesend, also als Broadcast-Source für alle sehe ich keinen Grund, warum das nicht mit Shared-Memory gehen sollte.Shared memory Nutzung muß man als Programmierer explizit vorsehen, was je nach Algo sinnvoll sein kann oder auch nicht und erstmal Mehraufwand bedeutet, wenn man es nachträglich einbauen will. Ein L1 wird dagegen automatisch genutzt und benötigt keine Intervention des Entwicklers.
Nach meinem Verständnis sollte so ein gemeinsamer L1-Cache besonders vorteilhaft arbeiten, wenn zufällige Werte gelesen und geschrieben werden.Eher wenn Du in verschiedenen Partitionen des SMs die gleichen Werte benötigst. Bei getrennten L1-Caches, müssen die dann in jeden L1 getrennt aus dem L2 geladen werden (Belastung des L2 steigt) und die effektive L1-Größe sinkt.

========================

https://devtalk.nvidia.com/default/topic/690631/cuda-programming-and-performance/so-whats-new-about-maxwell-/post/4126639/#4126639
Achja, das hätte ich fast vergessen. Ich hatte ja schon auf den etwas eigenartigen Integerdurchsatz bei Kepler hingewiesen (10/12 des float-Durchsatzes), bei Maxwell scheinen das jetzt 2/3 zu sein, wenn das kein Benchmarkartefakt ist (also Integer ist im Vergleich zu float mit Maxwell etwas langsamer geworden [von 5/6 auf 4/6]). Ist vielleicht ganz interessant, daß mit meiner möglichen Interpretation mit den Latenzen und Pipelinebubbles nochmal abzugleichen. Entweder erzeugt Maxwell größere Bubbles oder die Ausführungslatenz der ALUs ist um 50% gesunken, was dann ein Hinweis auf die Einführung von result forwarding bei Maxwell wäre (erschlägt je nach Code schon einiges des möglichen Vorteils eines Registerfilecaches, ist praktisch ein Registerfilecache mit nur einem Eintrag ;)).
Edit: Sehe gerade, daß das so ein blöder AIDA-Test ist, der oft nicht wirklich die Peakwerte ausspuckt (Kepler ist z.B. ziemlich mies mit den getesteten Integeroperationen [ein paar Shifts dabei?]). Ist nicht ganz klar, was die da genau machen. Also kann man das Argument anhand der Werte erstmal vergessen.

[PCGH_Carsten]

Joa, ich weiß schon dass man als Programmierer den Shared Memory selbst nutzen muss, das schrieb ich ja schon an Skysnake. Es ging um den Zusammenhang, in dem er das schrieb.

Danke für den erneuten Link zu den Cuda-Docs. Da stehen aber prinzipiell die Dinge etwas genauer - nicht aber immer fehlerfrei drin. Zum Beispiel geht's bei den älteren Compute-Devices (namentlich denen aus der DX10-Generation) noch mit geteilten Texturcaches zu - aber das steht ja auch dort (nur eben nicht in der Tabelle).

Alles seit Fermi (ohne jetzt eine konkrete Aussage zur Hand zu haben, meine ich sogar mindestens bis GT200) hat 12 kiB pro Quad-TMU - und die sind alle gekapselt, sprich die Quad-TMU arbeitet für sich genommen mit ihren 12 kiB Texturcache. Das gilt auch für Kepler.

"Between 12 and 48 kiB" hängt halt nur von den Daten ab. Sind sie redundant vorzuhalten, sind es 12, kannst du sie managen, sodass in jedem Cache verschiedene stehen, sind es effektiv 48 kiB. Meistens als wohl irgendwas dazwischen.

Btw: auch direkt von nv:
http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=48054&stc=1&d=1392849226

[Skysnake]

Ja Carsten, das ist bei nVidia immer so eine Sache mit den Docs. Bei AMD sind zwar auch immer wieder Fehler drin, aber Sie sagen im Normalfall schon, was denn jetzt wirklich Sache ist, und wenn Sies nicht wollen, sagen Sie halt einfach gar nichts dazu.

Bei nVidia wird immer mal wieder einfach falsches Erzählt. Jüngstes Beispiel ist ja dynamic Parallelism, was ja super duper funktionieren soll. Auf der SC war wohl der einhellige Tonus, dass es einfach nichts bringt, und keinen Deut schneller ist, als wenn man einfach neue Kernels vom Host aus startetn. Daher wird auch inzwischen vermutet, das nVidia mit dynamic Parallelism auch nichts anderes macht, und nur ne Softwareabstraktion ist.

Die Leute waren da ziemlich ernüchtert, und soweit ich das verstanden haben auch durchaus etwas angesäuert.

[Coda]

Das ist doch wieder mal so hörensagen. Ich bin mir sicher, dass Dynamic Parallelism keine Software-Emulation ist, das wäre ja völliger Gesichtsverlust.

Zwei Minuten Google: http://gcl.cis.udel.edu/publications/conferences/2013_SPIE.pdf 1,8 - 3x Speedup.

Wenn die Leute nicht verstehen was es macht und zu blöd sind es zu in den richtigen Fällen zu benutzen, dann ist es nicht NVIDIAs Schuld.

[Skysnake]

Wie gesagt, ich war nicht selbst da, und hab mir nicht selbst die Vorträge angehört, kann also nur aus zweiter/dritter Hand berichten.

In dem von dir verlinkten Paper gibt es aber auch zwei Seiten.

1.

We observe a combined performance loss of 7.7% averaged across all cases

Wenns rein darum geht, Kernels nacheinander zu starten.

2.

Our experiments for divisive hierarchical clustering were timed and averaged over five runs; the observed results are shown in Tables 1 and 2. Each run used a uniquely generated data set that was used for the implementations both with and without dynamic parallelism.

Die Runtimes sind aber > Faktor 10 langsamer.

Wird da Äpfel mit Birnen verglichen, oder wie oder was?

Da ist überhaupt nicht klar, was die wirklich machen. Wenn beides mal das gleiche Ergebnis bei rumkommt, ist es zwar schön, das dynamicParalelism in dem besonderen Fall was bringt, aber wenns am Ende langsamer ist, geschenkt.

Ansonsten bestätigt das Paper genau das, was mir zugetragen wurde. DynamicParallelism ist nicht schneller, als wenn man den Kernel einfach normal von der CPU aus startet.

Was da bei ihrer zweiten Implementierung gelaufen ist weiß ich nicht. Soweit ich das verstanden habe, was mir erzählt wurde, war das Fazit daraus, das dynamic Parallelism einem die Arbeit leichter macht, aber nicht mehr Performance bringt, wenn man eben die entsprechenden Kopfstände ohne es macht.

Wenn sowas auf der SC erzählt wird, dann glaube ich das auch einfach mal. Die Leute die da rumrennen, haben "ein bischen" mehr Plan als ich und erzählen normal auch nicht einfach nen Scheis.

[PCGH_Carsten]

Ja Carsten, das ist bei nVidia immer so eine Sache mit den Docs. Bei AMD sind zwar auch immer wieder Fehler drin, aber Sie sagen im Normalfall schon, was denn jetzt wirklich Sache ist, und wenn Sies nicht wollen, sagen Sie halt einfach gar nichts dazu.

Hüben wie drüben gibt's Kommunikationspannen - die Schwierigkeit liegt darin, die Fehler zu erkennen.

[Skysnake]

Klar, das muss man immer in Betracht ziehen, daher hab ich auch nie was erwähnt. Inzwischen habe ich aber von drei verschiedenen Leuten mehr oder weniger das gleiche Fazit bekommen, und das oben verlinkte Paper sagt ja zumindest für nen normalen Kernellaunch auch nichts anderes aus.

Die Frage sit jetzt "nur" noch, was haben die noch gemacht, damits in der letzten Version doch schneller ist, und ist es wirklich nen Performancegewinn, oder halt nur schneller, als die Version ohne DynamicParalelism. Das gibt das Ding leider nicht her.

[AnarchX]

5 Things You Should Know About the New Maxwell GPU Architecture (https://devblogs.nvidia.com/parallelforall/5-things-you-should-know-about-new-maxwell-gpu-architecture/)

5. Learn More about Programming Maxwell

For more architecture details and guidance on optimizing your code for Maxwell, I encourage you to check out the Maxwell Tuning Guide and Maxwell Compatibility Guide, which are available now to CUDA Registered Developers. Log in or sign up for free today.

[-/\-CruNcher-/\-]

Hat schon jemand getestet ob es visuelle Verbesserungen im DSP Bitstream output gibt ?

[hell_bird]

Ich betrachte gerade das Diagramm hier: http://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/Tests/Geforce-GTX-750-Ti-im-Test-Maxwell-1109814/

Dort sieht es aus als wären die TMUs jetzt einfach wie SFUs angeordnet und würden vom dispatcher mit Arbeit versorgt? Kann man das so ausdrücken? Im Gegensatz dazu war bei Kepler noch ein eigenständiger Datenfluss und Cache. Warum war das so?

Was rechtfertigt eigentlich generell, dass man spezialisierte Textureinheiten baut? Eigentlich sind Texturen doch nur geschickt angeordnete Daten, die linear interpoliert werden oder?