GK110 - HPC-Kepler - Architektur-Thread

[Ailuros]

http://www.nvidia.com/content/PDF/kepler/NV_DS_Tesla_KCompute_Arch_May_2012_LR.pdf

Kann jemand freundlicherweise etwas das HyperQ bzw. Dynamic parallelism Zeug einfach erlaeutern?

[Skysnake]

Die Wavefronts können jetzt einfach aus unterschiedlichen Kernels kommen. Man hat also schlicht die ganze Sache aufgebohrt mit den Queues.

Der Nutzen ist halt zwiespältig. Es bringt eigentlich nur dann etwas, wenn man zu wenig Threads hat, um die GPU auszulasten, was halt auch der "normalfall" ist :ugly:

Ne Spaß beiseite. Das bringt eigentlich nur etwas für die Visualisierung von Desktops usw. wo man einfach mit einer Aufgabe keine Last aufs System bekommt. Da kann man jetzt einfach mehrere parallel laufen lassen. Mehr steckt da nicht dahinter.

Für HPC meiner Meinung nach total witzlos.

[Coda]

Für HPC meiner Meinung nach total witzlos.
Wenn man die GPU als Applikations-Beschleuniger benutzt via. AMP etc. ist das rein gar nicht nutzlos.

Dynamic Parallelism erlaubt das erzeugen von Kerneln auf der GPU von anderen Kerneln aus. Das ist ziemlich cool und würde ich mir auch für Direct3D wünschen. Dann könnte man das Occlusion-Culling komplett auf der GPU machen ohne über die CPU gehen zu müssen.

[Gipsel]

Etwas abgespeckt kann Tahiti das übrigens auch. NVidia hat halt nette Marketingnamen, wahrscheinlich eine Software-Umgebung, mit der man das (besser) nutzen kann und geht wahrscheinlich auch über die Funktionalität bei GCN hinaus.

Sowas wie HyperQ ermöglichen bei AMD die ACEs (Asynchronous Compute Engines), die unabhängige work queues in Hardware bereitstellen. Ich habe aber keine Ahnung, wie viele Kontexte bei AMD so laufen können (es sind notgedrungen mindestens so viele wie es ACEs gibt [bei momentanen GPUs zwei], jede ACE könnte aber auch mehrere queues unterstützen, k.A.) um das mit den maximal 32 bei GK110 zu vergleichen. Und bei der GCN-Vorstellung vor einem knappen Jahr, wurde iirc auch gesagt, daß es GCN ermöglicht, aus einem Kernel heraus andere zu starten (self scheduling, dynamic parallelism, edit: bei AMD lief das unter "Compute Generated Task Graph Processing", die Abbildung 3 zum "Dynamic Parallelism" in dem von Ailuros verlinkten nVidia-pdf stellt übrigens gerade einen Task-Graphen dar ;)). Aber mit den bisherigen SDKs geht das auch nicht, dafür müßte AMD wahrscheinlich irgendeine OpenCL Extension anbieten.

[Skysnake]

coda das starten von tasks aus kernel heraus ist cool, das hab ich auch nicht bestritten. Ich bezog mich nur auf HyperQ

[Gaestle]

Ist es zu banal bzw. falsch, wenn man sagt, dass es grundsätzlich die Auslastung steigert?
Wenn ja: in welchem Rahmen können Verbesserungen erwartet werden? Kann mn das in Prozenten beziffern?

Kann es eine Einheit mit zusätzlichen Aufgaben versorgen, während diese aus irgendeinem Grund innerhalb eines Prozesses auf (das Ergebnis) eine(r) andere(n) Einheit wartet?

Kann es Aufgaben selbständig starten/generieren?

[KiBa]

Dynamic Parallelism erlaubt das erzeugen von Kerneln auf der GPU von anderen Kerneln aus. Das ist ziemlich cool und würde ich mir auch für Direct3D wünschen. Dann könnte man das Occlusion-Culling komplett auf der GPU machen ohne über die CPU gehen zu müssen.
Auch hierarchisches OC? Also ganze Teilbäume weglassen, falls ein innerer Knoten schon nicht sichtbar ist... das wäre in der Tat cool, dann hätte man überhaupt keine pipeline-stalls mehr unter Einsatz von OC. Und Conditional-Rendering zählt nicht, da das bei großen Szenen ja nun garnicht gut skaliert.

[AffenJack]

Kepler whitepaper:
http://www.nvidia.com/content/PDF/kepler/NVIDIA-Kepler-GK110-Architecture-Whitepaper.pdf

Was mich hierran völlig verwirrt ist das DP, schon GK104 soll 192 Sp + 8 DP Shader inner SMX haben, GK110 sollens nun 192 SP + 64 DP sein. Also 3:1 DP-Rate, aber in dedizierten einheiten? Wieso sollte man sowas machen?

[Coda]

coda das starten von tasks aus kernel heraus ist cool, das hab ich auch nicht bestritten. Ich bezog mich nur auf HyperQ
Ich habe mich auch auf HyperQ bezogen.

Nicht jeder Task auf einer Node muss die GPU zwangsläufig 100% auslasten.

[Ailuros]

Kepler whitepaper:
http://www.nvidia.com/content/PDF/kepler/NVIDIA-Kepler-GK110-Architecture-Whitepaper.pdf

Was mich hierran völlig verwirrt ist das DP, schon GK104 soll 192 Sp + 8 DP Shader inner SMX haben, GK110 sollens nun 192 SP + 64 DP sein. Also 3:1 DP-Rate, aber in dedizierten einheiten? Wieso sollte man sowas machen?

Wie ich schon auf B3D und im Spekulations-thread sagte: ich will ernsthaft bezweifeln dass es sowohl fuer GK104 als auch fuer GK110 etwas anderes ist als eine schematische Darstellung die nur Verwirrung stiftet. Am Ende vergiss bitte nicht dass whitepapers und co. leider NICHT von engineers erstellt werden sondern vom Marketing.

Waeren es auf GK110 physikalisch 192+64 haettest Du am Ende 3840 SPs. Ich lass mich gerne eines besseren belehren, aber es sitzt mir einfach nicht als moeglich und natuerlich auch nicht auf GK104 mit seinen relativ mageren 294mm2.

***edit: ich hab es uebrigens auf B3D zur Frage gestellt eben weil Damien Triolet nichts von physikalischen Einheiten auf GK104 behauptet. Schoen Anand hat es so behauptet, aber dass sollte nicht heissen dass er auch wirklich recht hat. Damien ist normalerweise ziemlich vorsichtig mit seinen Behauptungen und auch um einiges mehr erfahren als viele andere Authoren dort draussen.

[Skysnake]

Ist es zu banal bzw. falsch, wenn man sagt, dass es grundsätzlich die Auslastung steigert?
Wenn ja: in welchem Rahmen können Verbesserungen erwartet werden? Kann mn das in Prozenten beziffern?

Kann es eine Einheit mit zusätzlichen Aufgaben versorgen, während diese aus irgendeinem Grund innerhalb eines Prozesses auf (das Ergebnis) eine(r) andere(n) Einheit wartet?

Kann es Aufgaben selbständig starten/generieren?
Kommt halt auf die Aufgabe drauf an, je geringer die Auslastung deines Tasks ist, desto besser ist HyperQ. IM HPC-Bereich hast du diese Situation aber im Normalfall nicht. Für das ganze Streaming/Virtualisierungs Gedönze natürlich SEHR wichtig.

Ich habe mich auch auf HyperQ bezogen.

Nicht jeder Task auf einer Node muss die GPU zwangsläufig 100% auslasten.
Muss er ja auch nicht im zeitlichen Verlauf, sondern nur, so lange er läuft. Erst wenn ein einzelner Task es gar nicht schafft WÄHREND er läuft die GPU aus zu lasten, dann greift HyperQ.

Bei HPC-Anwendungen wirst du das aber nie haben, und auch sonst kaum, denn irgendwas macht dir dicht. Entweder das SI, dann bringts dir auch nicht viel, was anderes laufen zu lassen, außer es ist halt absolut Compute bound, und kann die freien Ressourcen nutzen, oder du bist ALU-Bound, dann haste SI-Bandbreite über, aber eben keine ALUs frei, mit denen du das für einen anderen Task nutzen kannst.

Wenn macht es halt nur Sinn, Tasks auf GPUs zu mischen. Sprich wir nehmen eine GPU und schieben nen halben ALU und nen halben SI-Bound Task drauf, und lassen die einfach parallel, aber dafür länger laufen.

Dafür musst du aber die Tasks an bestimmte SMXs "pinnen" können, sonst kommt sich das alles wieder ins Gehege. Ganz abgesehen davon, dass du ja auch solche Tasks erst mal brauchst. Zudem gewinnst du dann nur SI-Bandbreite, was natürlich die ALUs dann auch beim SI-Bound Task besser auslasten lässt.

Für ALU Bound Tasks hilft es dir aber gar nichts. Da musste eher aufpassen, dass du durch zusätzliches sheduling, dirty caches usw usw. nicht massiv an Leistung verlierst.

So etwas ist hochgradig komplex! Selbst auf CPUs ist es ja deutlich angenehmer, wenn man allein auf der Maschine arbeiten kann. Sobald da noch andere rum "pfuschen" bekommt man graue Haare, weil die Caches nicht mehr zuverlässig funktionieren usw. Klar, es wird oft geshudeld in so großen Anlagen, und auch so manches parallel berechnet, aber man hat während man rechnet, zumindest im HPC-Bereich die Rechner so lange man rechnet für sich.

Bei Virtualisierung usw. sieht das natürlich ganz anders aus. Da ist es ein absoluter Segen, was da kommt. Die Workloads sehen da aber eben auch komplett anders aus.

So BTT:

Auf PCGH ist nen update zu GK110 da.

Demnach hat GK110 1,5MB L2 Cache, was sehr schön ist, und von mir ja auch gewünscht/erwartet/gefordert wurde.

Man kann auch den Texturecache nun als Read-Only nutzen.

L1/Shared ist leider noch immer nur 64kB groß -.-

[deekey777]

Kepler whitepaper:
http://www.nvidia.com/content/PDF/kepler/NVIDIA-Kepler-GK110-Architecture-Whitepaper.pdf

Was mich hierran völlig verwirrt ist das DP, schon GK104 soll 192 Sp + 8 DP Shader inner SMX haben, GK110 sollens nun 192 SP + 64 DP sein. Also 3:1 DP-Rate, aber in dedizierten einheiten? Wieso sollte man sowas machen?
Man darf aber nicht vergessen, dass es schon eine Nvidia-GPU mit dedizierten DP-Einheiten gab, die GT200-GPU.

Auf der anderen Seite:
Als der RV670 kam, ließ sich kein Mitarbeiter von AMD die Möglichkeit entgehen, auf den Mixed-Mode hinzuweisen, wo die ersten vier SPs sich um DP kümmerten und die fette T-Unit zusätzlich eine FP32-Instruction ausführen konnte.

Jetzt kommt der GK110 und soll pro SMX 64 dedizierte DP-Einheiten haben. Da würde ich doch voll auf die Kacke hauen und jedem einen Mixed-Mode unter die Nase reiben (192 FP32-MADDs plus 64 DP-MADDs). Aber das passiert nicht. Entweder ist so ein krasser Mixed-Mode nicht möglich, oder es gibt gar keine dedizierten FP64-Einheiten, sondern dieses Schema ist nur ein Highlevel-Overview, wie ein Programm den GK110 sieht: Als eine Maschine mit 192 FP32-Einheiten und 64 DP-Einheiten.

Aus dem Whitepaper:
Unlike Fermi, which did not permit double precision instructions to be paired with other instructions, Kepler GK110 allows double precision instructions to be paired with certain other instructions that have no register file reads, including load/store, texture, and some integer instructions.

[Skysnake]

Ja, du bist dabei aber wie schon gesagt beschränkt.

Du hast einfach X Ports, welche für 192 SP-Ops langen, oder eben 64 DP-Ops. Daraus kannste dir jetzt jede beliebige Mischung aussuchen, bis du eben deine X Ports belegt hast, wobei 1 DP Op eben genau so viele Ports wie 3 SP-Ops belegt.

Ich frage mich allerdings wirklich, wie man SP und DP-Ops mischen will. Man hat doch nur immer ganze Wave-Fronts am laufen, welche immer die gleiche Instruktion ausführen :ugly:

[deekey777]

GTC 2012: Die GK110-Schöpfer über Performance und zukünftige Herausforderungen (http://www.heise.de/newsticker/meldung/GTC-2012-Die-GK110-Schoepfer-ueber-Performance-und-zukuenftige-Herausforderungen-1578605.html)
c't:Setzt Nvidia bei GK110 auf dedizierte Double-Precision-Einheiten oder arbeiten dafür mehrere Single-Precision-Kerne zusammen?

Danksin: Es gibt eigenständige Double-Precision-Einheiten.

c't: Nehmen diese viel Platz in Anspruch?

Alben: Zumindest nicht wenig. Dadurch belegt eine GK110-SMX deutlich mehr Die-Fläche als jene von GK104. Ein weiterer Platzfresser ist die Implementation der ECC-Funktionen.

[Gipsel]

Da fragt man sich doch, warum die ganze restliche Welt normalerweise multiple precision units verbaut, zumindest in SIMD-Einheiten (die Shadereinehiten der GPUs sind solche). Ich glaube es immer noch nicht. Aber das kann man unter Umständen mit gezielten low-level-Tests herausfinden (für die man aber offenbar noch bis nächstes Jahr warten muß).

[Mancko]

GTC 2012: Die GK110-Schöpfer über Performance und zukünftige Herausforderungen (http://www.heise.de/newsticker/meldung/GTC-2012-Die-GK110-Schoepfer-ueber-Performance-und-zukuenftige-Herausforderungen-1578605.html)

Hey das Interview war ja mal richtig gut und die Jungs sehen auch ganz witzig aus :)

[Skysnake]

Da fragt man sich doch, warum die ganze restliche Welt normalerweise multiple precision units verbaut, zumindest in SIMD-Einheiten (die Shadereinehiten der GPUs sind solche). Ich glaube es immer noch nicht. Aber das kann man unter Umständen mit gezielten low-level-Tests herausfinden (für die man aber offenbar noch bis nächstes Jahr warten muß).

Naja, nicht wirklich, wenn das wirklich an Ports hängt, und entweder oder nur läuft, wirste davon zu 99% Wahrscheinlichkeit rein gar nichts sehen. Warum sollte man auch?

Ist ja in dem Fall einfach eine 3:1 Beziehung mit dedizierten Einheiten, und mit Multiprecision Unis haste halt 3 belegte Units für DP. Nach außen wirste das nicht sehen. Nicht mal über die ISA sollte man das sehen können.

Wenn, könnte man sich die Temperaturverteilung auf dem Chip anschauen, aber das funktioniert halt nicht, wenn der Kühler drauf ist :ugly:
Ganz abgesehen davon, dass die Transistoren ja eh recht wild verteilt sind für die ALUs.

Also ich seh da absolut keine Chance, von außen feststellen zu können, ob das stimmt, oder nicht. Ich kanns mir aber auch nicht vorstellen.

Man kann einfach zu viel der SP-Units wiederverwenden, bzw. mit deutlich weniger Aufwand aufbohre, als wenn man komplette dedizierte Units verwendet.

[Spasstiger]

Die c't hat leider falsch rum gefragt. Die richtige Frage wäre gewesen, ob die DP-Einheiten auch SP-Ops ausführen können und wenn ja, in welchem Verhältnis.
Meine Vermutung: Es sind 64 ALUs vorhanden, die jeweils ein DP-FMA oder drei SP-FMA ausführen können.