AMD Graphics Core Next - neue GPU Architektur für Ende 2011

[AwesomeSauce]

Hier leider auch keine Erleuchtung, also alles schwarz. Schade.

[Jake Dunn]

Läuft ohne jeden Fehler einwandfrei auf einer HIS HD 6950 IceQ XTurboX (880Mhz) und auch schön ruckelfrei:-)

Auch ohne Fehler hier :)

HD5850 @850/1250 > 12-22FPS in 1080p

[mironicus]

Die Demo läuft selbst auf einer Radeon 5570 fehlerfrei. :D (4-5 Frames/Sek.)

[Skysnake]

Also auf der 5870 läuft die Demo auch "ohne" Fehler.

Hab aber nur 7-10 FPS, da die GPU nicht aus dem IDLE-Takt hoch taktet -.-

Läuft also nur mit 400/900 MHz statt 850/1200 MHz

[deekey777]

Welchen Treiber nutzt ihr? Es empfiehlt ich den 12.2 Preview-Treiber zu nutzen.

[HarryHirsch]

Welchen Treiber nutzt ihr? Es empfiehlt ich den 12.2 Preview-Treiber zu nutzen.

der unterstützt die 79xx doch gar nicht :confused:

[M4xw0lf]

der unterstützt die 79xx doch gar nicht :confused:

Ich denke das ging an die Leute mit den HD5000/6000-Karten.

[HarryHirsch]

mit 8x msaa komme ich bei 1680x1050 auf ~14fps :freak:

[HarryHirsch]

Ich setz mich später mal ran.

Was meint ihr, sieht man hier, und mit SSAA die ersten Ergebnisse der neuen Führung?

nö. siehe ladybug oder whiteout oder ... oder ...
die demos waren schon immer gut ;)

[mapel110]

Jetzt mit dem 295.51 crasht die Demo zumindest nicht mehr bei mir, aber das Bild ist weitestgehend schwarz. Nur das Menü via ESC und das Logo wird korrekt dargestellt.

[Knuddelbearli]

ob sich Nv den spass macht die demo doch für nv zu optimieren um am ende sogar schneller zu sein? ^^

klappt ja bei so manchem AMD Titel ( ok vermutlich schleimt sich AMD nur weniger als NV bei den Herstellern ein ^^ )

[Hübie]

Welch unqualifiziertes Kommentar :rolleyes:

btw: Die Demo läuft auf meiner GTX 580 nicht richtig. Schwarzer Bildschirm mit ein paar Prefabs und dem AMD-Logo. Mehr sieht man nicht.

[DrFreaK666]

Welch unqualifiziertes Kommentar :rolleyes:

btw: Die Demo läuft auf meiner GTX 580 nicht richtig. Schwarzer Bildschirm mit ein paar Prefabs und dem AMD-Logo. Mehr sieht man nicht.

Was soll der :rolleyes: ?

[Plasmo]

mit 8x msaa komme ich bei 1680x1050 auf ~14fps :freak:

Hattest du nicht 2x 7970?
Ich hab mit 2x 6970 (930/1450) bei 1920x1200 und 8xMSAA 38 (29-48) fps im Schnitt.

[HarryHirsch]

ja sorry, der super sampling regler klemmt.

[w0mbat]

http://ht4u.net/reviews/2012/amd_radeon_hd_7700_test/index4.php

Hier sieht man, dass GCN doch ein sehr guter Schritt in Richtung mehr Effizienz ist. Hätte nicht gedacht, dass GCN so viel besser mit der Rohleistung umgeht.

[AnarchX]

Fragt sich nur ob es die ~40% mehr Transistoren auch wert ist.

[Botcruscher]

Die Frage ist halt ob man VLIW5 hätte ein ordentliches Frontend verpassen können ohne zu viel Verwaltungsaufwand. Insgesamt hinterlassen die zwei Architektursprünge von AMD einen sehr durchwachsenen Eindruck. Schön wenn man etwas besser mit der Rohleistung umgeht, dafür hat man ja auch viel weniger.:(

[AnarchX]

Mit geringem oder keinem Culling (Verwerfen von Geometrie) tesselliert Tahiti nur auf dem Niveau von Cape Verde?
(http://www.hardware.fr/articles/855-8/performances-theoriques-geometrie.html)

[robbitop]

Fragt sich nur ob es die ~40% mehr Transistoren auch wert ist.
Naja die 40 % sind ja nicht nur in der Effizienzsteigerung der ALUs gelandet, sondern sicher auch im Frontend und für GPGPU Fähigkeiten (die dem Spieler nichts bringen).

[AnarchX]

Im Test wird aber auch nicht die reine ALU-Leistung getestet.
Aber natürlich sind die direkt gemessenen Steigerungen wohl deutlich höher, wie man auch bei HW.fr sieht, wo mit Tessellation CV pro Takt wohl doppelt soviele Dreiecke erzeugen kann wie Juniper.

Trotz allem scheint die Spiele-Leistung pro Transitor für eine Mischung aus D3D10/11 auf Juniper höher zu sein.

[Spasstiger]

Trotz allem scheint die Spiele-Leistung pro Transitor für eine Mischung aus D3D10/11 auf Juniper höher zu sein.
Das hast du langfristig immer. Letzlich ist die Herausforderung für die GPU-Designer, aus mehr verfügbaren Transistoren neben mehr Features auch mehr Performance rauszuholen. Dazu muss man von Zeit zu Zeit zusätzliche Transistoren aufwenden, um höhere Taktraten oder eine bessere Skalierbarkeit zu erreichen.

Ein bischen übertrieben dargestellt sieht die Entwicklung so aus:

http://www.abload.de/img/gpu_entwicklung2ljog.png

Die Architekturverbesserung ist zwar kurzfristig recht teuer, aber mittelfristig zahlt sie sich aus.

[AnarchX]

Auch interessant, dass Cape Verde teilweise doch deutlich mehr als 1/2 Tahiti ist:
http://img407.imageshack.us/img407/9423/13292578330y0tl9frwk13l.gif (http://imageshack.us/photo/my-images/407/13292578330y0tl9frwk13l.gif/) http://img846.imageshack.us/img846/2746/1324209130cz7mwgcqjr111.gif (http://imageshack.us/photo/my-images/846/1324209130cz7mwgcqjr111.gif/)



http://hardocp.com/image.html?image=MTMyOTI1NzgzMzB5MFRsOUZSV2tfMV8zX2wuZ2lm

http://www.hardocp.com/image.html?image=MTMyNDIwOTEzMENaN213Z0NRalJfMV8xMV9sLmdpZg==

512KiB von 768KiB L2-Cache. Ebenso zwei ACEs (http://www.computerbase.de/bildstrecke/38677/13/)wie Tahiti.

Mit dem Cache hat man wohl geringe Bandbreite des IMCs aufgefangen. Denkbar dass Pitcairn hier vielleicht mit 1MiB gar Tahiti überbieten wird.

[Skysnake]

Je nach workload definitiv!

Der L2 hat noch eine recht niedrige Latenz im Vergleich zum RAM. Wenn der wirklich mit 1MB kommt, dann wird das sogar so sein.

[Coda]

Latenz ist für eine GPU jetzt aber auch nicht so entscheidend.

[AnarchX]

Irgendetwas wird man sich mit dem Cache schon gedacht haben, ansonsten hätte man da wohl auch 1-2 CUs mehr verbauen können.

[Coda]

Spart halt Bandbreite wenn du viel Datenlokalität hast.

[PCGH_Carsten]

Jeder gesparte externe Transfer ist für mobile Geräte überdies doppelt wertvoll - insbesondere, wenn das PCIe-Interface im System ebenfalls schlafen gehen kann.

[Coda]

Ich denke nicht, dass da der L2-Cache wirklich hilft.

[Gipsel]

Irgendetwas wird man sich mit dem Cache schon gedacht haben, ansonsten hätte man da wohl auch 1-2 CUs mehr verbauen können.
512kB SRAM fallen flächenmäßig gegenüber 2 CUs nicht wirklich in's Gewicht, 2 CUs haben ja schon allein 512kB Vektor-Register. ;)
Der L2 wirkt nur bandbreitenentlastend bei GPGPU (als Read-Write-Cache) oder für Texturing. Die ROPs haben ja sowieso eigene Caches. Es kostet nicht übermäßig viel Fläche, diese Caches ein wenig zu vergrößern. SRAM ist in 28nm ziemlich klein.

[Skysnake]

Oh doch, der L2 hilft schon sehr!

Ist halt ein cache. Da kann jeder zusätzliche Zugriff in den Cache ein zichfaches an Zugriffen in den RAM sparen. Das weißt du ja. Es kommt immer auf die Datenlokalität drauf an. Je nach dem ist das nur 1 Zugriff oder tausende/Millionen Zugriffe, die man sich spart. Im Normalfall kannste aber sicherlich von einem Faktor 2-50 ausgehen. Hängt halt absolut vom jeweiligen Workload und dessen Datenzugriffsschema ab.

Ganz abgesehen davon muss man aber auch die viel höhere Bandbreite des L2 berücksichtigen. Das ist wohl sogar der entscheidendere Faktor, welchen ich jetzt aber nicht explizit genannt hatte, da dies eigentlich klar ist.

Gerade bei XGEMM etc. sind größere Caches halt echt ein Segen, weil man durch das SI limitiert ist bei GPUs. Um genauer zu sein, bei allen Problemen, bei denen man nicht ALU und/oder I/O limitiert ist, helfen größere caches sowohl durch die steigende Hit Anzahl, der dadurch gestiegenen effektiven Bandbreite für die ALUs und eben auch die niedrigeren Latenzen, weil man bereits mit weniger Warps/Wavefronts die Latenzen des RAM überbrücken kann, weil jeder einzelne mehr rechnen kann, das dann auch wieder die Datenlokalität erhöht, da man mehr shared Memory pro Warp/Wavefront hat.

[Coda]

Oh doch, der L2 hilft schon sehr!
Das war auf das abschalten des PCIe-Interfaces bezogen :rolleyes:

Danke für die Lehrstunde, aber ich weiß was ein Cache tut, kthxbye.

[Spasstiger]

Evtl. hat man den Cache bei Cape Verde auch nur so groß gewählt, um Redundanzfläche zu haben für den Fall, dass die Yields eher bescheiden sind. Ist bei der Radeon HD 7750 der volle Cache verfügbar?

[PCGH_Carsten]

Ich denke nicht, dass da der L2-Cache wirklich hilft.
Defniere "wirklich". :) Ein System von 45 auf 35 Watt bekommst du damit ganz sicher nicht runter, das ist klar.

[Coda]

Zum zweiten Mal: Ich meinte damit, dass der L2-Cache nicht dazu beiträgt, dass das PCIe abgeschaltet werden kann.

[Skysnake]

Wird er doch sowieso nie oder?

[Coda]

Ne, aber es gibt Energiespar-Levels.

[AnarchX]

Note, with Tahiti there is not a full RB to memory channel Crossbar - each RB can access just 3 memory channels.
http://forum.beyond3d.com/showpost.php?p=1626549&postcount=190

[Gipsel]

http://forum.beyond3d.com/showpost.php?p=1626549&postcount=190
Na das ist doch mal eine interessante Information, zu der er sich hat hinreißen lassen hat. Ich war ja recht skeptisch, was diese Entkopplung angeht, gerade wegen dem Aufwand mit der zusätzlichen Crossbar. Aber so wie Dave Baumann sagt, haben sie keine 8x6 Crossbar verbaut, sondern zwei 4x3 Crossbars, um den Aufwand klein zu halten (die zwei kleineren sind zusammen nur halb so viel Aufwand wie die volle).

[Knuddelbearli]

und das bedeutet jetzt was genau ? bringt das irgendwo licht ins dunkel ? ^^

[Gipsel]

und das bedeutet jetzt was genau ? bringt das irgendwo licht ins dunkel ? ^^
Es erklärt vielleicht, warum es vom Aufwand her vertretbar war gegenüber nVidias Lösung, die diese Entkopplung zumindest bis Fermi nicht beherrscht. Dort verpuffen ja die 48 ROPs bei GF100/110 zumeist ziemlich sinnlos (bei GF104 oder gar GF106 ist es noch schlimmer). Aber nVidia hat wohl festgestellt, daß so ein voller Crossbar mehr Aufwand wäre als die zusätzlichen ROPs in Anbetracht der (je nach Situation) kleinen bis nichtvorhandenen Mehrperformance durch die zusätzlichen ROPs. Mit den halbierten Crossbars, verliert man zwar etwas Flexibilität (man kann aber trotzdem z.B. eine HD7930 Version von Tahiti mit den vollen 32ROPs und einem 256Bit-Interface rausbringen, ohne Performanceeinbußen abseits der Bandbreiteneffekte befürchten zu müssen), halbiert aber auch den Aufwand dafür, was die Kosten-Nutzen-Rechnung verschiebt.

Außerdem legen beide Hersteller nicht wirklich offen, wie genau die Framebufferformate im Speicher liegen und damit zusammenhängend (weil das aufeinander abgestimmt ist, z.B. auch mit dem Muster, mit dem die Rasterizer Dreiecke abtasten) wie bestimmte Screentiles auf die ROP-Partitionen und die Speichercontroller gemappt werden. Die Aussage von Dave Baumann bringt jetzt für den Normalanwender herzlich wenig, fördert aber vielleicht so ein bißchen das bessere Verständnis der Interna der Architekturen, weil es bestimmte Mappings ausschließt.

Edit2:
Im B3D-Forum hat gerade jemand ein Experiment verlinkt (http://www.geeks3d.com/20120309/opengl-4-2-atomic-counter-demo-rendering-order-of-fragments/), was versucht, Teilaspekte davon sichtbar zu machen. Hier erkennt man z.B gut die grobe Rasterreihenfolge bzw. die am Stück bearbeiten Pixelmengen (entspricht 16 Wavefronts) bei einer HD6970:

http://www.ozone3d.net/public/jegx/201112/geexlab-opengl-atomic-counter-demo-hd6970.jpg

Meiner Meinung nach stimmt es übrigens nicht unbedingt, daß das wirklich die reine Rasterreihenfolge ist. Das Scheduling und die Workdistribution spielt da ebenso eine entscheidende Rolle. Deswegen sieht das auf den Fermis auch chaotischer aus (weil die Workdistribution viel feinkörniger arbeitet), genauso wie auf der HD7770 (der hätte das mal lieber mit einem Tahiti machen sollen :rolleyes:).
Eine Analyse der Rasterreihenfolge für den G80 gibt es hier (http://www.icare3d.org/GPU/CN08). Wie gesagt beeinflußt sich das gegenseitig, da es zu den ROP-Caches (die ebenfalls auf Basis von Screen-Tiles zugewiesen werden, genau wie heutzutage die Rastertiles bei mehreren parallen Rastereinheiten) passen muß. Z.B. enthält die G80-Raster-Analyse bereits etwas versteckt die Erklärung für die 8x Z-Test-Rate der nV-ROPs gegenüber 4x bei AMD, obwohl die ROPs gar nicht angesprochen werden ;).

[AnarchX]

Aber man ist dann wohl auch nicht so flexibel wie Nvidia, die ihren IMC in 64-Bit-Schritten skalieren können.
Das ist dann auch die Erklärung warum Dave von der Untersuchung einer 256-Bit Variante sprach, 320-Bit sind für Tahiti nicht möglich.

[Knuddelbearli]

Danke für die Erklärung für doofies ^^

Mich interessiert die Materie ja sehr, aber sehr aber leider fehlt es öfters mal an Fachwissen ^^

[Skysnake]

hm..

Und was bedeutet das jetzt für Speicherzugriffe bei GPGPU?

Da müsste es dann doch einschränkungen geben.

[Coda]

Für RBEs ja, für den Rest nicht. Der geht ja durch den L2.

[Gipsel]

Aber man ist dann wohl auch nicht so flexibel wie Nvidia, die ihren IMC in 64-Bit-Schritten skalieren können.
Das ist dann auch die Erklärung warum Dave von der Untersuchung einer 256-Bit Variante sprach, 320-Bit sind für Tahiti nicht möglich.
NVidia ist da nur "flexibel", weil die gar keinen Crossbar dazwischen haben. Deaktivieren die einen 64Bit-Speichercontroller, wird die dazugehörige L2-Cache-Tile mitsamt der dazugehörigen ROP-Partition mit deaktiviert. Bei AMD hängt nur eine L2-Cachetile mit am Speichercontroller (ein Tahiti mit 256Bit hätte also nur 512kB L2 statt 768kB), die ROPs mit ihren spezialisierten ROP-Caches (Color + Z) eben nicht, da die Crossbar zwischen den ROP-Partitionen und den Speichercontrollern das entkoppelt. Durch die nicht vollständige Verdrahtung zwar nicht perfekt (sprich nur in 128Bit-Schritten, nicht 64 Bit [oder unterschiedliche ROP-Partitionen hätten unterschiedlich breite Anbindungen, geht im Prinzip zwar, macht das Load-Balancing nur recht suboptimal]), aber dafür kann AMD damit die Anzahl der ROPs und die Speicherinterfacebreite im Prinzip unabhängig festlegen, nVidia nicht. Das fällt bei mir auch unter "Flexibilität". ;)

Edit:
Ein Tahiti mit 320Bit Speicherinterface hätte 640kB L2. Vier der insgesamt acht ROP-Partitionen wären mit jeweils drei der jetzt nur noch fünf Speichercontroller verbunden, die anderen vier mit nur zwei Controllern. Die eine Hälfte der ROPs würde sich also genau so verhalten, wie bei einem Tahiti mit vollem 384Bit-Interface, die ander Hälfte wie bei einem Tahiti mit 256Bit-Interface. Bei ganzen 128Bit-Schritten verhalten sich jeweils alle ROP-Partitionen untereinander identisch. 320Bit wären also sehr wohl möglich, nur suboptimal (Performance vermutlich näher an der 256Bit-Variante als an der 384Bit-Variante und damit aus Kosten/Nutzen-Gründen uninteressant).

[AnarchX]

Muss aber auch das Front-End mit 16 + 12 ROPs klar kommen.

[Gipsel]

Muss aber auch das Front-End mit 16 + 12 ROPs klar kommen.
Nö, ein Tahiti mit 320Bit Speicherinterface hätte immer noch die vollen 32 ROPs.

Aber bei der Deaktivierung von ROPs ohne Deaktivierung von Speichercontrollern gilt praktisch das Gleiche. Es kommt zu unterschiedlichen Belastungen der Speichercontroller. ROP-Partitionen (RBEs) kann man bei Tahiti im Prinzip alle einzeln ausknipsen. So wie Dave-Bauman das geschrieben hat (er erwähnte vorhandene Redundanz bei den ROPs), hat ein Tahiti eventuell 9 RBEs (36 ROPs) oder gar 10 statt den nominellen 8 auf dem Die.

Die ROP-Partitionen werden wie gesagt ebenfalls auf Basis der Screen-Space-Tiles zugewiesen. Das ist eigentlich ziemlich einfach, das Mapping auf unterschiedliche Anzahlen der ROP-Partitionen anzupassen. Man muß nur aufpassen, daß es keine unschönen Aliasing-Effekte des Mappings zwischen Raster-Tiles, ROP-Tiles bzw. Speichercontrollern kommt, weshalb man wahrscheinlich besser immer 2 ROP-Partitionen/RBEs also 8 ROPs zusammen ausknipst. Das ist eine ähnliche Argumentation wie gegen den 320Bit Tahiti, es ist nicht unbedingt die technische Unmöglichkeit.

[Coda]

Muss aber auch das Front-End mit 16 + 12 ROPs klar kommen.
Das Frontend weiß von den RBEs doch überhaupt nichts. Da wird höchstens das Rastermuster darauf optimiert.

[AnarchX]

Welchen Vorteil stellt man eigentlich hier heraus: http://www.anandtech.com/Gallery/Album/2104#6 ?

[Spasstiger]

Welchen Vorteil stellt man eigentlich hier heraus: http://www.anandtech.com/Gallery/Album/2104#6 ?
Wohl die Kompression der MSAA-Buffer. Der Zusammenhang mit Tessellation ist mir auch nicht klar, da dem MSAA egal sein sollte, woher die Dreiecke kommen.
Ich wüsste auch nicht, warum Kepler im ganz rechten Bild nicht komprimieren können sollte.

[Gipsel]

Wohl die Kompression der MSAA-Buffer. Der Zusammenhang mit Tessellation ist mir auch nicht klar, da dem MSAA egal sein sollte, woher die Dreiecke kommen.
Ich wüsste auch nicht, warum Kepler im ganz rechten Bild nicht komprimieren können sollte.
Weil nV laut AMD immer nur ganze 4x4 Pixel Tiles komprimieren kann oder eben nicht. AMDs Kompressionsalgorithmus ist angeblich flexibler. Das spart Bandbreite, verkompliziert aber die Anforderungen an die ROP-Caches bzw. auch das Speicherinterface (weil die Größe der Tiles bei AMD stark variabel ist, bei nV kommen nur 2 Zustände vor: voll komprimiert oder gar nicht, bei AMD gibt es alle möglichen Zwischenstufen und -größen).

[Spasstiger]

Weil nV laut AMD immer nur ganze 4x4 Pixel Tiles komprimieren kann oder eben nicht. AMDs Kompressionsalgorithmus ist angeblich flexibler.
Hm, ok, ich bin bisher davon ausgegangen, dass die MSAA-Buffer-Kompression so ein alter Hut ist, dass mittlerweile alle GPUs maximal komprimieren. Aber klar, wenn man nur große Dreiecke hat, kann die Implementierung ohne große Abstriche bei der Bandbreitenersparnis vereinfachen und z.B. die Granularität erhöhen.
Die AMD-Implementierung komprimiert nach der Folie auch nicht optimal, im mittleren Bild sollten 72 Fragments reichen (AMD: 80 Fragments, Nvidia: 160 Fragments), im rechten Bild 80 Fragments (AMD: 96 Fragments, Nvidia: 256 Fragments).

AMD komprimiert offenbar in 2x2 Tiles und kann dort zumindest zwischen je 1, 2 und 4 Fragments pro Pixel unterscheiden, während Nvidia nach der Folie in 4x4 Tiles komprimiert und 1 oder 4 Fragments pro Pixel unterscheidet.

P.S.: Der Edge-Detect-Filter von AMD nutzt ja afaik die Kompressionsinformation aus den MSAA-Buffern. Bei NV würde das wohl wegen der groben Granularität wenig Sinn ergeben.

/EDIT: Vielleicht sollte man den Teil der Diskussion in den GCN-Architekturthread (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=506061) verschieben.

[Gipsel]

Hm, ok, ich bin bisher davon ausgegangen, dass die MSAA-Buffer-Kompression so ein alter Hut ist, dass mittlerweile alle GPUs maximal komprimieren. Aber klar, wenn man nur große Dreiecke hat, kann die Implementierung ohne große Abstriche bei der Bandbreitenersparnis vereinfachen und z.B. die Granularität erhöhen.
Die AMD-Implementierung komprimiert nach der Folie auch nicht optimal, im mittleren Bild sollten 72 Fragments reichen (AMD: 80 Fragments, Nvidia: 160 Fragments), im rechten Bild 80 Fragments (AMD: 96 Fragments, Nvidia: 256 Fragments).

AMD komprimiert offenbar in 2x2 Tiles und kann dort zumindest zwischen je 1, 2 und 4 Fragments pro Pixel unterscheiden, während Nvidia nach der Folie in 4x4 Tiles komprimiert und 1 oder 4 Fragments pro Pixel unterscheidet.Hmm, was ist eine "optimale" Kompression? Wie schon gesagt, erhältst Du durch die zusätzliche Flexibilität im Algorithmus von AMD deutlich variierende Tilegrößen. Dir hilft es ja nicht wirklich, daß ein 4x4 Tile jetzt statt 256 Byte nur noch 248 Byte groß ist, wenn Du bei jedem Speichertransfer sowieso z.B. 64 Byte am Stück lesen oder schreiben willst. Mal ganz abgesehen davon, daß die Adressierung eines bestimmten Samples dann auch alles andere als trivial wird zumal sich die Größe des komprimierten Puffers ja während des Schreiben darin ständig ändert (man startet ja mit maximal komprimiertem Buffer). Also welche Bytes muß man z.B. lesen, damit man das 3. Sample des Pixels bei x=547, y=914 erhält?!?

[Spasstiger]

Wenn Transfers anfallen, nur um die Speicheradresse zu ermitteln, ist meine "optimale" Kompression natürlich nicht mehr optimal.
Anhand von Spielebenchmarks lässt sich der scheinbare Bandbreitenvorteil von AMD bei MSAA leider nicht nachweisen, weil dafür die Architekturen zu unterschiedlich sind und Tahiti XT2 eh mit 50% mehr Speicherbandbreite gesegnet ist als der GK104. Und wenn es passende theoretische Benchmarks gäbe, hätte AMD die sicherlich mit hübschen Balken auf die Folie gepackt.

[Nakai]

Ohne jetzt auf Technische Details einzugehen, aber ich finde auf diesew Folie den letzten Punkt zur Deferred Rendering Advantages ganz interessant.

http://www.anandtech.com/Gallery/Album/2104#4

Nachtigall ich hör dir trapsen. ;)

Mittlerweile ist klar, dass AMD alle DesignWins im Konsolenbereich eingefahrn hat.

Wenn Transfers anfallen, nur um die Speicheradresse zu ermitteln, ist meine "optimale" Kompression natürlich nicht mehr optimal.
Anhand von Spielebenchmarks lässt sich der scheinbare Bandbreitenvorteil von AMD bei MSAA leider nicht nachweisen, weil dafür die Architekturen zu unterschiedlich sind und Tahiti XT2 eh mit 50% mehr Speicherbandbreite gesegnet ist als der GK104. Und wenn es passende theoretische Benchmarks gäbe, hätte AMD die sicherlich mit hübschen Balken auf die Folie gepackt.

Naja jedenfalls ist es soweit lohnenswert gewesen, dass es auf ner Folie draufgepackt wird. Im Bezug auf Oberes könnte ich mir vorstellen, dass es nicht ganz unwichtig ist.

[Spasstiger]

Ohne jetzt auf Technische Details einzugehen, aber ich finde auf diesew Folie den letzten Punkt zur Deferred Rendering Advantages ganz interessant.

http://www.anandtech.com/Gallery/Album/2104#4.
Das ist jetzt aber keine Eigenschaft der Hardware, sondern soll nur die Besonderheit der HD-7900-Techdemo herausstellen, oder?

[Nakai]

Das ist jetzt aber keine Eigenschaft der Hardware, sondern soll nur die Besonderheit der HD-7900-Techdemo herausstellen, oder?

Ka, irgendwie kommt das auf den Folien nicht ganz so rüber. Natürlich würde es viel besser auf die Grafikdemo zutreffen.

[Gipsel]

Es gibt übrigens jetzt das ISA-Manual für SI (http://developer.amd.com/sdks/AMDAPPSDK/assets/AMD_Southern_Islands_Instruction_Set_Architecture.pdf). Gelesen habe ich es noch nicht. Mal sehen, ob man außer ein paar Details noch Neues lernen kann.

[Skysnake]

also wenn ich es jetzt richtig verstanden habe, dann ermoeglicht der GDS (global data share) es eine globale barrier auf zu bauen. Sprich ich kann ueber Workgroups hinweg eine barrier erstellen (GWS), was eigentlich bis jetzt nur innerhalb einer workgroup funktioniert hat. OpenCL bietet dazu auch gar keine API-Funktion! Etwas fuer OpenCL 1.2?

Ansonsten siehts mit dem GDS so aus, das man Variablen hoch und runter zahlen kann. Da man ja im schlechtesten Fall pro workitem einfach eine Variable nehmen kann, kann man damit dann wohl auch wieder ein Sznc bauen, bzw eben auch ein reduce damit bauen, indem man ueber Workgroupegrenzen hinweg die Daten austauscht. Das ist schon ziemlich cool. Gerade wenn ich an nen grosses Reduce denke, dann kann jede Workgroup fuer sich durch renen und eben immer seine GDS Variable hoch zaehlen, und am Ende schreibt man das in den Mainmemory und macht mit der CPU dann die letzten paar reduces.

Die GDS Zugriffe scheinen aber leider nicht in atomaren Versionen vor zu liegen. DAS waere natuerlich richtig geil.

Ansonsten ist mir die Sache mit den Branches ausgefallen. So wie das aussieht, kann man Branches innerhalb einer Workgroup machen, so ganz verstehe ich die ganze Sache allerdings nicht :(

[Gipsel]

also wenn ich es jetzt richtig verstanden habe, dann ermoeglicht der GDS (global data share) es eine globale barrier auf zu bauen. Sprich ich kann ueber Workgroups hinweg eine barrier erstellen (GWS), was eigentlich bis jetzt nur innerhalb einer workgroup funktioniert hat. OpenCL bietet dazu auch gar keine API-Funktion! Etwas fuer OpenCL 1.2?Eher eine herstellerspezifische Extension. Das konnten übrigens frühere AMD-GPUs auch schon.
Die GDS Zugriffe scheinen aber leider nicht in atomaren Versionen vor zu liegen. DAS waere natuerlich richtig geil.Lies Dir mal den Anfang von Abschnitt 9.3.3 ("Both LDS and GDS can perform indexed and atomic data share operations. For brevity, “LDS” is used in the text below and, except where noted, also applies to GDS.") oder die Tabelle 9.2 (den zweiten Eintrag) da durch. Fast alle LDS-Instruktionen funktionieren offenbar auch mit dem GDS.
Ansonsten ist mir die Sache mit den Branches ausgefallen. So wie das aussieht, kann man Branches innerhalb einer Workgroup machen, so ganz verstehe ich die ganze Sache allerdings nicht :(Meinst Du Abschnitt 4.6 ("Arbitrary divergent control flow") mit dem fork und join? Das ist wohl ziemlich lahm ("The performance of this method is lower than that for S_CBRANCH on simple flow control; use it only when necessary.") und lindert anscheinend das Problem, daß mit SIMD-Maschinen prinzipiell kein beliebiger "irreducible control flow" möglich ist (wenn man die einzelnen work items als Threads auffassen will). Genau durchgelesen habe ich es mir auch noch nicht (und außer Pseudocode des Ablaufes ist ja auch keine Beschreibung drin :rolleyes:), aber vermutlich schiebt man die Grenze etwas hinaus.

Der Grund dafür (das Problem mit irreducible control flow) ist, daß alle work items in einer wavefront in lockstep ausgeführt werden, es gibt nur einen einzigen instruction pointer zusammen für alle Elemente (es sind eben keine Threads). Mit SI kann man jetzt einen Fork machen, sprich eine Wavefront logisch gesehen aufteilen (und sie später mit join wieder zusammenfügen). Wenn ich das richtig sehe, wird aber nicht wirklich eine neue Wavefront erzeugt. Dafür werden SGPRs und ein Stack benutzt, um den PC (so heißt bei GCN der Instruction pointer) und die Ausführungsmasken zwischenzuspeichern, so daß man im Prinzip innerhalb einer Wavefront die verschiedenen Arme der Branches abarbeiten kann. Der wesentliche Unterschied zu dem normalen Kontrollfluß (über simple Maskierung und Nacheinanderausführen der Arme) besteht darin, daß man jetzt im Prinzip zu einem Zeitpunkt verschiedene Instruction pointer in den verschiedenen Armen haben kann und damit kompliziertere Kontrollstrukturen basteln kann. Ein Limit ist durch die Anzahl der SGPRs gegeben, es ist also keine wirklich fundamentale Lösung des Problems, aber vermutlich erstmal gut genug (wenn man von der vermutlich geringen Performance absieht) für die, die unbedingt damit rumspielen wollen.

[Skysnake]

Eher eine herstellerspezifische Extension. Das konnten übrigens frühere AMD-GPUs auch schon.

Und warum nutzt dass dann bitte keine Sau? :ugly:

Kann ich daher irgendwie nicht so recht glauben, dass man schon länger ne global Barrier bauen kann, die bei Threads>ALUs funktioniert. Danach schreien doch die Leute schon ne ganze Weile, und deswegen ist ja HyperQ ja auch mit ganz nett, weil man eben zum Syncen keinen Kernelstart mehr braucht.

Mein Dozent vom GPU-Computing, der auch einiges mit AMD GPUs gemacht hat, hat auch nichts davon gesagt/gewusst, dass das mit AMD GPUs bisher schon geht.



Lies Dir mal den Anfang von Abschnitt 9.3.3 ("Both LDS and GDS can perform indexed and atomic data share operations. For brevity, “LDS” is used in the text below and, except where noted, also applies to GDS.") oder die Tabelle 9.2 (den zweiten Eintrag) da durch. Fast alle LDS-Instruktionen funktionieren offenbar auch mit dem GDS.

Ich hab mir nur mal die ISA angeschaut, was es da so an Befehlen gibt, also ohne die WOT zu lesen. Da stand halt nichts von Atomic dran, daher bin ich mal davon ausgegangen, dass das auch keine Atomics sind. Wenn ja, ist das natürlich SEHR geil.

Die Sache mit den "Leertackten" ist auch interessant. Meinst du, dass man damit praktisch Workitems parken kann, um so zu verhindern, dass die Threads bussy waiting machen, wenn man auf ein Ergebnis warten will?


Meinst Du Abschnitt 4.6 ("Arbitrary divergent control flow") mit dem fork und join? Das ist wohl ziemlich lahm ("The performance of this method is lower than that for S_CBRANCH on simple flow control; use it only when necessary.") und lindert anscheinend das Problem, daß mit SIMD-Maschinen prinzipiell kein beliebiger "irreducible control flow" möglich ist (wenn man die einzelnen work items als Threads auffassen will). Genau durchgelesen habe ich es mir auch noch nicht (und außer Pseudocode des Ablaufes ist ja auch keine Beschreibung drin :rolleyes:), aber vermutlich schiebt man die Grenze etwas hinaus.

Genau das hab ich gemeint. Das mit den "Threads" weiß ich, aber ich sag lieber Threads als Workitems, schreibt sich einfach schneller (ein Zeichen weniger ;D)
Ich hab das auch so verstanden, das man praktisch für eine gewisse Auswahl an Workitems in einer Workgroup einen zusätzlichen Programmpointer bekommt. Die Unterscheidung zwischen echter Workgroup und so einer aufgeteilten ist dann wohl auch nicht mehr sonderlich groß, in der Handhabung für den Entwickler, außer das man halt limitiert ist, und es langsamer geht.

Für manche Sachen aber wahrscheinlich doch ganz interessant. Man muss abe rmal noch schauen, ob die Ausführung dann auch über Maskierung erfolgt, oder ob die Zusammenstellung dann neu erfolgt.

Bsp.: Aufteilung im Workflow zwischen geraden und ungeraden Workids. Dann würden alle Workgroups komplett 2 mal durchrattern müssen, weil immer nur die Hälfte weg maskiert wird. Wenn mit dem Branch aber die neu strukturiert werden, dann hätte man jeden Zweig nur einmal am durchlaufen. Aber keine Ahnung, ob das so funktioniert.


Der Grund dafür (das Problem mit irreducible control flow) ist, daß alle work items in einer wavefront in lockstep ausgeführt werden, es gibt nur einen einzigen instruction pointer zusammen für alle Elemente (es sind eben keine Threads). Mit SI kann man jetzt einen Fork machen, sprich eine Wavefront logisch gesehen aufteilen (und sie später mit join wieder zusammenfügen). Wenn ich das richtig sehe, wird aber nicht wirklich eine neue Wavefront erzeugt. Dafür werden SGPRs und ein Stack benutzt, um den PC (so heißt bei GCN der Instruction pointer) und die Ausführungsmasken zwischenzuspeichern, so daß man im Prinzip innerhalb einer Wavefront die verschiedenen Arme der Branches abarbeiten kann. Der wesentliche Unterschied zu dem normalen Kontrollfluß (über simple Maskierung und Nacheinanderausführen der Arme) besteht darin, daß man jetzt im Prinzip zu einem Zeitpunkt verschiedene Instruction pointer in den verschiedenen Armen haben kann und damit kompliziertere Kontrollstrukturen basteln kann. Ein Limit ist durch die Anzahl der SGPRs gegeben, es ist also keine wirklich fundamentale Lösung des Problems, aber vermutlich erstmal gut genug (wenn man von der vermutlich geringen Performance absieht) für die, die unbedingt damit rumspielen wollen.
Ähm ja siehe oben :biggrin:

Eine richtig gute Lösung sieht anders aus, aber ein SChritt in die richtige Richtung meiner Meinung nach.

Ich werd mir das Dokument wohl mal im Urlaub so richtig rein ziehen, wenn ich dazu kommen :(

[Gipsel]

Und warum nutzt dass dann bitte keine Sau? :ugly:

Kann ich daher irgendwie nicht so recht glauben, dass man schon länger ne global Barrier bauen kann, die bei Threads>ALUs funktioniert. Danach schreien doch die Leute schon ne ganze Weile, und deswegen ist ja HyperQ ja auch mit ganz nett, weil man eben zum Syncen keinen Kernelstart mehr braucht.

Mein Dozent vom GPU-Computing, der auch einiges mit AMD GPUs gemacht hat, hat auch nichts davon gesagt/gewusst, dass das mit AMD GPUs bisher schon geht.Evergreen ISA Manual (http://developer.amd.com/sdks/amdappsdk/assets/amd_evergreen-family_instruction_set_architecture.pdf), Kapitel 2.7 nennt die atomic units (GDS unterstützt bis zu 32 integer atomics pro Takt, jede Bank hat eine atomic unit), Kapitel 3.8 handelt vom global wave sync (GWS). Das wurde bereits mit der HD5000er-Serie eingeführt. Die HD4000er hatten zwar auch schon einen GDS, aber die Synchronisation darüber war nicht dokumentiert und wurde allerhöchstens von treiberinternem Code genutzt und Atomics gingen wohl nicht. Aber ab der HD5000 kann der GDS schon so ziemlich das Gleiche wie heute bei GCN (also Atomics, globale Semaphoren/Barriers und den Kram). SI hat nur einen einzigen GWS-Befehl (DS_GWS_SEMA_BR, keine Ahnung was der genau macht, ist praktisch undokumentiert) mehr als schon die Evergreens, der Rest (GWS_INIT, GWS_SEMA_V, GWS_SEMA_P, GWS_BARRIER) ist identisch.

Edit:
Achja, nutzen tut es keiner, weil es verflucht schwierig ist, direkt ISA-Code für die VLIW-Architekturen zu schreiben (für GCN würde ich mir das zutrauen, wenn die Doku noch etwas besser wäre) und es kaum Support für die GWS-Features in high level Sprachen (OpenCL) gibt.
Global Atomics bzw. die AMD-OpenCL-Erweiterung mit dem increment/decrement Countern (eine etwas eingeschränkte atomic operation) laufen über den GDS, genau wie das Management von append/consume Buffern. Und wenn ich mich recht erinnere, versägt schon ein Cypress Fermi/Kepler in den beiden letzteren Disziplinen.

[Skysnake]

Ja gut, VLIW ISA-Code will ich auch nicht komplett schreiben müssen (:ugly:), aber jetzt einfach die synchronisation hätte doch sicherlich jemand mal gemacht. Genau danach schreien die Leute doch schon ne halbe Ewigkeit :ugly:

Sorry, aber DUMM?

Wenn das wirklich schon so lange da ist, und es auch funktioniert!, dann muss man sich schon an den Kopf fassen, warum AMD das nicht mal gepushed hat....

So ganz glauben kann ich es noch nicht, dass da kein böser Hacken im Detail steckt, aber es ist durchaus möglich... Halt "typisch" AMD dann...

Bomben Hardware, aber bei den Treibern/Software ist das Geld ausgegangen -.-

EDIT:

3.8 Synchronizing Across Threadgroups (Global Wave Sync)
Each compute device (1 or 2 per GPU) contains 16 global wave sync (GWS)
resources for implement barriers, semaphores, and other synchronization
primitives. GWS resources can be shared by multiple wavefronts running on
different SIMDs and on different compute devices (if multiple devices are
present). This makes them more powerful than threadgroup barriers, which allow
only for basic barrier-style synchronization between a set of wavefronts running
on an individual SIMD.


Ähm damit sind jetzt schon CU gemeint und nicht echte devices oder? :ugly:

Wenn da echt devices im Sinne von KARTEN gemeint sind, dann wäre das ja mal nen epic fail, das man das nicht schon lange an die große Glocke gehängt hat...

[Gipsel]

Ähm damit sind jetzt schon CU gemeint und nicht echte devices oder? :ugly:Das sind die 2 Shader-Arrays in einer GPU bei Cypress, Barts und Cayman (die anderen haben nur jeweils eins). Da überschneidet sich die Terminologie ein wenig mit OpenCL (wo es dann ja ganze GPUs bzw. CPUs bedeutet).

[Skysnake]

AHHHHHHHHHH!!!!!!!!!!!

Danke, ich hab mir doch schon gedacht, dass das nicht sein kann ;D

Trotzdem, absolut unverständlich, warum Sie die Möglichkeiten nicht für den Entwickler vernünftig nutzbar machen. Auch jetzt hört man ja praktisch nichts darüber....

[deekey777]

Kriege ich die goldene Schaufel?

AMD will neben der CPU auch die GPU besser auslasten (http://www.computerbase.de/2015-03/next-gen-apis-amd-will-neben-der-cpu-auch-die-gpu-auslastung-verbessern/)

[Nakai]

Bessere Auslastung wäre sehr nett. Aber mal abwarten.

€:
http://www.computerbase.de/2015-03/directx-12-im-test-vor-mantle-und-amd-vor-nvidia/

Nur so als Denkanstoß. Wenn das kein Driver-Problem ist und es die Hardware ist, dann...

[Locuza]

Ich denke nicht, dass die Draw-Call Anzahl die dort rausgehauen wird, direkt mit dem Durchsatz vom Command-Processor der GPU zusammenhängt.

Unter Star-Swarm hat Oxide beim Mantle Renderer eine small batch Optimierung vorgenommen, um den Command-Processor der GPU zu schonen und das bringt auch 16% bei einer 290X.
Und der Benchmark ist nun sehr weit entfernt von der Draw-Call Anzahl vom 3DMark.

Ich denke die Warnung, dass die Resultate nicht absolut vergleichbar sind, ist wirklich nicht umsonst.

[Troyan]

Bessere Auslastung wäre sehr nett. Aber mal abwarten.

€:
http://www.computerbase.de/2015-03/directx-12-im-test-vor-mantle-und-amd-vor-nvidia/

Nur so als Denkanstoß. Wenn das kein Driver-Problem ist und es die Hardware ist, dann...

Siehe das Ergebnis bei Anandtech: http://www.anandtech.com/show/9112/exploring-dx12-3dmark-api-overhead-feature-test/3

Eine GTX980 ist nur zwischen 24 und 48% schneller als die GTX680. Und die GTX680 unterstützt kein Hyper-Q, noch kann sie Graphics + Compute Streams gleichzeitig verarbeiten und hat nur eine aktive DMA Engine.

Computerbases Ergebnisse zeigen eben nicht das ganze Bild.