Caches bei der 69x0 und viel andere GPGPU Fragen

Skysnake

Lötkolbengott/-göttin
1. Mich würde mal interessieren, wie groß die einzelnen Caches bei der 69x0 Serie sind.

2. Auch wurde bei Luxx glaub gesagt, das die SP Berechnungen beschleunigt wurden. Könnt ihr dazu was sagen?

3. Auch würde mich interessieren, ob die Caches wie bei nVidia nun variabel zuteilbar sind.

4. Auch würde mich brennend interessieren, wie jetzt genau der Wegfall der T Unit sich auswirkt und dies nun umgesetzt wird.

5. Wie sieht es mit Neuerungen bezüglich OpenCL bei den Karten aus?

6. Wird es 4GB Karten geben?

7. Gibt es Neuerungen für die FirePro Karten mit der neuen Generation, welche sich eventuell auch auf die Radeon Karten durchschlagen?

8. Ich habe gelesen, das die Art und Weise wie Kernels ausgeführt wurden nun geändert wurden. WIE sieht das genau nun aus?????
 
1.) 8 kiB Texturcache, 32 kiB Local Memory, 64 kiB Global Memory, 4x 128 kiB Level 2 Cache zwischen ROP und Speichercontroller, AFAIK.
2.) Meinst du wirklich die SP-Berechnungen? Bei DP: „Marketing-beschleunigt” würde ich sagen. Vorher arbeiteten 4/5 Einheiten an DP, also 20% des SP-Durchsatzes, jetzt arbeiten 4/4 Einheiten an SP, also 25% des SP-Durchsatzes.
3.) Soweit ich weiß nicht.
4.) Das ist ein ziemlich umfangreiches Thema. In Kürze: Die vier restlichen Einheiten wurden so erweitert, dass sie - spätestens im Teamwork - alle Aufgaben der T-Unit mit übernehmen können. Was allerdings an Transcendental-Funktionen vorher "nur" den T-Slot belegte, verbraucht nun 3/4 Slots der WXYZ-Einheiten. Ob parallel dazu noch ein (M)ADD, MUL oder FMA geschedult werden kann, ist mir derzeit nicht bekannt.
5.) Zurzeit noch schlecht. Offiziell werden Sie erst später unterstützt. Die Performance der Rumpf-Unterstützung der Catalyst 10.11-Treiber ist teils schlecht.
6.) Zurzeit gibt es keine offiziellen Ankündigungen. Genaueres weiß ich leider auch nicht.
7.) Zu kommenden FirePros hält AMD sich derzeit bedeckt.
8.) Da verstehe ich die Fragestellung nicht. Die Engines in Cayman können wohl Kernels von mehreren CPU-Threads annehmen - falls es das ist, was du meinst.
 
Zu 8.:

Ja genau das meinte ich. Das hab ich bisher noch nicht so recht verstanden. Bei luxx glaub wars, hies es das jede SIMD (Die meinten wohl jede OpenCl ComputeUnit) jetzt eine eigene Queue für Befehle und Kernels hat. Was die Folgen daraus sind würde mich mal interessieren.

Bisher wars ja auch so, das jede ComputeUnit einen seperaten Code ausführen konnte, nur halt jedes Device (GPU) eben nur einen Kernel ausführen kann.

Wenn wirklich jede CU einen eingenen Kernel ausführen könnte, wäre das für die Auslastung schon recht geil O_O

Auch wäre gut zu wissen, ob man immer noch 80 Tackte für nen Global Mem Zugriff brauch oder ob sie das etwas drücken konnten.

Zu 1.:

Du hast nicht grad die Werte zur 5870 parat? :D

Zu 2.:

Also die bei Luxx glaub wars hatten sich ja als einzigste minimal über Rechnen auf GPUs ausgelassen mit den Neuen, aber halt total schwammig -.-

Ich hab selbst keine Ahnung ob die DAS meinten, daher meine Frage. Ich hab auch vermutet, das Sie das meinten, eventuell hat sich ja aber auch was an der Berechnung von MAD/MUL etc geändert, bzw brauchen EXP Sin etc weniger Tackte um das Ergebnis auszuspucken.
 
6. Wird es 4GB Karten geben?

Ich glaub das wir da mit Antilles die 4gb bekommen werden seitens nvidia wird darauf sicher auch schon was in der mache sein .....
 
Wieviele Kernels genau nun parallel ausgeführt werden können, kann ich dir leider nicht sagen.

zu 1: Diese Werte haben sich nicht geändert: 32k Shared Mem schreibt zum Beispiel DX11 vor.

zu 2: Die Transcendentals haben sich geändert, auch was die maximalen und durchschnittlichen Fehler angeht, da die LUTs überarbeitet worden sind. Der Durchsatz bestimmt sich an der Menge der VLIW-Einheiten.
 
Naja, auf der Rückseite des PCB sind ja 8 Slots frei für Ram-Chips, welche bei der 5870 ja für das zweite GB Ram genutzt wurden. Bei der 6970 sind die ersten zwei GB ja auf der Front, also wären die Rückseite frei für weitere 2 GB :evil:
 
zu 2: Die Transcendentals haben sich geändert, auch was die maximalen und durchschnittlichen Fehler angeht, da die LUTs überarbeitet worden sind. Der Durchsatz bestimmt sich an der Menge der VLIW-Einheiten.

Ich mein nicht den Durchsatz für den Chip, sondern sozusagen die Latenz bis das Ergebnis einer komplexen Berechnung da ist auf einen 4D Shader.

Da die ja nun allgemeiner ausgelegt sind, ist es ja durchaus möglich, das die Berechnung beschleunigt wurde, halt weniger Tackte brauch, das einfach mehr Teile des 4D Shaders mit an der Berechnung arbeiten können.
 
In Linux kann ich aber die Zeitmessung per auslesen des Taktcounters der CPU machen. Auf Windows ist mir die Möglichkeit nicht bekannt. Da kann ich nur die Systemclock nehmen, und 1ms ist halt ne verdammt schlechte Zeitauflösung. Linux ist da einfach für die Zeitmessung deutlich genauer.

Vielleicht find ich ja noch einen Weg den auch unter Windows auf das CPU Register zuzugreifen. Eigentlich sollte meine Headerdatei das richten, aber irgendwie funktioniert die unter windows nicht :wall:
 
1.) 8 kiB Texturcache, 32 kiB Local Memory, 64 kiB Global Memory, 4x 128 kiB Level 2 Cache zwischen ROP und Speichercontroller, AFAIK.
Das stimmt so nicht, die 8 KiB L1-Cache (Texturcache in deiner Nomenklatur?) und die 32 KiB LDS (Local Memory in deiner Nomenklatur?) gelten pro SIMD.
Insgesamt also:
24*8 KiB = 192 KiB L1-Cache
4*128 KiB = 512 KiB L2-Cache
24*32 KiB = 768 KiB LDS (Local Data Share)
64 KiB GDS (Global Data Share)
 
In Linux kann ich aber die Zeitmessung per auslesen des Taktcounters der CPU machen. Auf Windows ist mir die Möglichkeit nicht bekannt. Da kann ich nur die Systemclock nehmen, und 1ms ist halt ne verdammt schlechte Zeitauflösung. Linux ist da einfach für die Zeitmessung deutlich genauer.
Hast du es mal mit QueryPerformanceCounter probiert? Die Funktion hat zwar ein paar Tücken falls die HW rumzickt aber sonst ist die ganz brauchbar. Alternative wäre vllt noch mittels RDTSC direkt zuzugreifen, das kann aber noch schlimmer enden :devil:
 
Das stimmt so nicht, die 8 KiB L1-Cache (Texturcache in deiner Nomenklatur?) und die 32 KiB LDS (Local Memory in deiner Nomenklatur?) gelten pro SIMD.
Übrigens:
Der 8-KiB-Cache (mal ganz neutral) wird nicht nur von mir so bezeichnet. Ich finde den Namen auch zutreffend, für einen Read-Only-Cache, den lediglich die TMUs anzapfen können. LDS oder Local-Memory - da können wir gern drüber streiten, ob ich da unbedingt dieselben Marketingnamen wie AMD nutzen muss.
 
In Linux kann ich aber die Zeitmessung per auslesen des Taktcounters der CPU machen. Auf Windows ist mir die Möglichkeit nicht bekannt. Da kann ich nur die Systemclock nehmen, und 1ms ist halt ne verdammt schlechte Zeitauflösung.

Die Systemclock ist aber deutlich genauer als 1ms. Soweit ich weiss kann die bis 0.1 Mikrosekunden genau sein.;)
 
Wenn ichs richtig im Kopf hab kannste aber nur auf 1 ms genau auslesen.

Bei nem 1GHz Prozessor haste aber ne Auflösung von 1 ns. Also sechs Zehnerpotenzen genauer. Das ist schon nen Unterschied. Vorallem wenn deine Berechnungen nur nen paar ms dauern. Da kommste mit nichts anderem hin in der Genauigkeit.
 
Zurück