Maxwell - GM204 -Architektur-Thread

[AnarchX]

http://devblogs.nvidia.com/parallelforall/maxwell-most-advanced-cuda-gpu-ever-made/
http://www.pcgameshardware.de/Geforce-GTX-980-Grafikkarte-259282/Tests/Test-Geforce-GTX-980-970-GM204-Maxwell-1136157/

In den SMM ist sowohl der Shared Memory auf 96KiB(64 @GM1xx) und der L1/Texture-Cache auf 24KiB (12 @GM1xx) gewachsen.
DP-Rate liegt bei GeForce GM204 wie erwartet bei 1:32.

CC ist 5.2.

[AnarchX]

Detail-Test bei HW.fr: http://www.hardware.fr/articles/928-3/performances-theoriques-pixels.html

Die TMUs filtern das D32F Format deutlich schneller.

Die GTX 970 verhält sich etwa eigenartig bei der ROP-Leistung. Es sind wohl nur 52 ROPs messbar. Offenbar hat hier nun auch die Zahl der SMM Auswirkung auf die Blending-Füllrate, was bei Kepler noch nicht der Fall war. Dazu passt vielleicht auch, dass SiSoft auf der GTX 970 nur 1,8MiB L2 Cache ermitteln konnte (http://www.sisoftware.eu/rank2011d/show_device.php?q=c9a598d680c98dc485a5e287c1aedcbfdafabde9b191a89faf89eed3fecfe9 9ba696b0d9e4d5f39ba693b5cdf0c1e782e7daeaccbf82ba&l=en).

[aufkrawall]

Gibt es eigentlich ein Äquivalent zu GCN Asynchronous Compute?

[Rooter]

Ich mag Maxwell. Würde meine Zotac GTX 550 Ti OC heute verrecken würde ich mir eine GTX 750 OC kaufen. Bevorzugen würde ich natürlich eine GTX 950 OC, aber die gibt's ja noch nicht... :biggrin:

Ich will eine VXGI-Techdemo! =)

MfG
Rooter

[Locuza]

Gibt es eigentlich ein Äquivalent zu GCN Asynchronous Compute?
Soweit ich es verstanden habe sollte es Hyper-Q sein, ein Feature welches erst ab GK110 erhältlich ist.
Bei Consumer GK110 ist das aber vermutlich deaktiviert, jedenfalls war es beim erscheinen der Titan deaktiviert.
Anandtech hat daneben noch behauptet im Tegra K1 findet sich die selbe Technologie wieder, wie beim GK110.

Wie es bei Maxwell aussieht, dazu hat es leider kein Wort gegeben.

[AnarchX]

Dynamic Parallelism und HyperQ gehören zum Grundumfang aller Maxwell, also auch schon GM10x. Mit GK208 und GK20A(K1) gab es schon zwei kleine Kepler, welche diese Features boten, auch als GeForce.

Wobei es da wohl gewisse Einschränkungen gibt/geben kann:
https://twitter.com/harrism/status/436702470765432832

[Coda]

Gibt es eigentlich ein Äquivalent zu GCN Asynchronous Compute?
Ja, seit GK110 (Hyper-Q). Das sollte Maxwell auch haben.

[kruemelmonster]

Here's another reason the GeForce GTX 970 is slower than the GTX 980 (http://techreport.com/blog/27143/here-another-reason-the-geforce-gtx-970-is-slower-than-the-gtx-980)
Peak pixel fill rate (Gpixels/s)

GeForce GTX 970 75
Asus Strix GTX 970 80
GeForce GTX 980 78

3DMark Vantage Color fill (Gpixels/s)

Asus Strix GTX 970 23,1
GeForce GTX 980 30,6

Extra ROPs are still useful to get better efficiency with MSAA and so. But they don’t participate in the peak pixel fillrate.

That’s in part what explains the significant fillrate delta between the GTX 980 and the GTX 970 (as you measured it in 3DMark Vantage). There is another reason which seem to be that unevenly configured GPCs are less efficient with huge triangles splitting (as it’s usually the case with fillrate tests).

[Gipsel]

Nach Hinweis von Ailuros, via B3D (http://forum.beyond3d.com/showthread.php?p=1880061#post1880061) lassen sich hier ein paar interessante Informationen über die internen Abläufe bei Maxwell finden (https://code.google.com/p/maxas/w/list), also insbesondere in dieser Beschreibung (https://code.google.com/p/maxas/wiki/ControlCodes).

[M4xw0lf]

Nach Hinweis von Ailuros, via B3D (http://forum.beyond3d.com/showthread.php?p=1880061#post1880061) lassen sich hier ein paar interessante Informationen über die internen Abläufe bei Maxwell finden (https://code.google.com/p/maxas/w/list), also insbesondere in dieser Beschreibung (https://code.google.com/p/maxas/wiki/ControlCodes).
tc;du
(too complicated, didn't understand :freak:)

Kleine Erläuterung für Dummies? :)

[Gipsel]

Ganz kurz:
Da ist beschrieben, wie bei Maxwell Abhängigkeiten im Instruktionsstrom enkodiert werden. Es gibt immer Gruppen aus Steuerungsinformationen (dort "control codes" genannt) und 3 Instruktionen. Diese control codes geben für die nachfolgenden drei Instruktionen explizit an, wie viele Takte später die nächste Instruktion folgen darf (z.B. wegen Abhängigkeiten). Diese Anzahl an Takten wird dann vom Scheduler mit Instruktionen aus anderen Threads gefüllt (wenn verfügbar natürlich). Der Scheduler spart sich also diese Abhängigkeitsprüfungen, das wird vom Compiler erledigt. Die Pipelinelatenz von Maxwell ist offenbar für die meisten einfachen Operationen 6 Takte (GCN 4).
Abhängigkeit von Speicheroperationen erfolgen mithilfe von Barriers, also etwas anders als bei GCN (dependency counters). Dies ermöglicht eine Art limitierte OoO-Abarbeitung von Speicheroperationen (bei GCN werden vector memory Zugriffe immer in-order fertiggestellt, skalare Speicherzugriffe zwar OoO [vermutlich, weil die Skalareinheit von 4 SIMDs geteilt wird und man so nicht von einem SIMD/Scheduler die anderen blockieren kann], man kann es wegen den einfachen dependency counters aber nicht nutzen [bzw. nur implizit wegen den vier getrennten SIMDs, aber nicht innerhalb eines Schedulers/SIMDs]).

[AnarchX]

Die GTX 970 verhält sich etwa eigenartig bei der ROP-Leistung. Es sind wohl nur 52 ROPs messbar. Offenbar hat hier nun auch die Zahl der SMM Auswirkung auf die Blending-Füllrate, was bei Kepler noch nicht der Fall war. Dazu passt vielleicht auch, dass SiSoft auf der GTX 970 nur 1,8MiB L2 Cache ermitteln konnte (http://www.sisoftware.eu/rank2011d/show_device.php?q=c9a598d680c98dc485a5e287c1aedcbfdafabde9b191a89faf89eed3fecfe9 9ba696b0d9e4d5f39ba693b5cdf0c1e782e7daeaccbf82ba&l=en).
http://forums.guru3d.com/showthread.php?t=396064
... kann die 970 nicht ihre vollen 4GiB adressieren? :ulol:

Split des Themas: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10481771#post10481771

[Troyan]

Gibt es eine technische Erklärung, wieso Maxwell so hoch getaktet werden kann?
GM200 erreicht 1400MHz+ mit +-1,2V, AMD erreicht mit 1,2V igendwas zwischen 1100-1150Mhz.

Bei AMD gibt es keinen Fortschritt in diese Richtung, Hawaii war auch schon in der Lage 1100Mhz zu erreichen. Kepler schaffte 1200Mhz mit GK110.

[kruemelmonster]

Die Packdichte wird ein gewichtiger Faktor sein, NV baut gern "luftitger":

Chip Fiji Hawaii GM200
Transistoren ca. 8,9 Mrd. ca. 6,2 Mrd. ca. 8,0 Mrd.
Fertigung 28 nm HP TSMC 28 nm HP TSMC 28 nm HP TSMC
Chipgröße 596 mm² 438 mm² 601 mm²
Packdichte* 14,9 14,1 13,3

Chip GM204 GM107 GK104 GK110 Hawaii
Transistoren ca. 5,2 Mrd. ca. 1,9 Mrd. ca. 3,5 Mrd. ca. 7,1 Mrd. ca. 6,2 Mrd.
Fertigung 28 nm HP TSMC 28 nm HP TSMC 28 nm HP TSMC 28 nm HP TSMC 28 nm HP TSMC
Chipgröße 398 mm² 148 mm² 294 mm² 550 mm² 438 mm²
Packdichte* 13,1 12,8 11,9 12,9 14,2
(Quelle ComputerBase)

[Troyan]

Gegenüber Kepler hat man sich auch verbessert. Zwischen 200 - 300Mhz sind möglich. Das sind 16% - 25% mehr Takt.

[-/\-CruNcher-/\-]

Nvidia hat auch keinen TrueAudio DSP dessen logik nimmt sicher auch etwas platz ein sicher vernachlässigbar aber platz ist platz ;)
Bei VR werden wir sicher mehr von ihm hehe "Hören" ;)

[Dural]

Das war doch schon immer so, NV hat halt das bessere OC potential.

[aufkrawall]

"Weil es schon immer so war." :facepalm:

[Dural]

Was hast du den für ein Problem?

Fakt ist das NV schon seit Jahren weniger Spannung für den gleichen Takt benötigt. Und NV ist auch bekannt dafür das sie hier und da auch gerne mal von "Hand" optimieren.

Und überhaupt ist es ziemlich doof unterschiedliche Architekturen mit MHz/Spannung zu vergleichen. Eine Diskussion ist somit ziemlich sinnlos. Zudem ich Maxwell für deutlich neuer halte als GCN.

[=Floi=]

Was hast du den für ein Problem?

Fakt ist das NV schon seit Jahren weniger Spannung für den gleichen Takt benötigt. Und NV ist auch bekannt dafür das sie hier und da auch gerne mal von "Hand" optimieren.

weil sie auch immer mehr transistoren verbauten und sonst das power budget nicht einhalten könnten.

[Dural]

Dies ist sicher eine Möglichkeit.

Der RV670 konnte man ziemlich gut Takten, OK war auch ein sehr kleiner Chip. Ich habe so 1300MHz bei 1,7Volt in Erinnerung, weis es aber leider nicht mehr so genau, ist auch schon
lange her. Ich müsste mal in meinen Unterlagen nachschauen ;)

Wie auch immer, es gibt auch von AMD "gute" Beispiele.

[Troyan]

Und überhaupt ist es ziemlich doof unterschiedliche Architekturen mit MHz/Spannung zu vergleichen. Eine Diskussion ist somit ziemlich sinnlos.

Was soll man sonst vergleichen? :D

Um auf die Taktbarkeit zurückzukommen:
Die AIO Karte von Inno3d rennt mit >1400Mhz als Standard und verbraucht leicht mehr Strom als die Fury X. Ist in 1440p knapp 30% schneller!
http://www.hardware.fr/focus/113/gtx-980-ti-evga-sc-inno3d-ichill-black-test.html

Das sind ca. 35% mehr Takt als die Fury X. Mit Maxwell erreicht man Taktraten, die hat man früher nur bei den Karten mit getrennten ALU-Takt gesehen...

[Locuza]

Andrew Lauritzen Vor 20 Stunden

@aras_p Yeah Maxwell already has one foot towards TBDR and I imagine everyone will do more of that in the future. Should be interesting!
They do a quasi-tiling/buffering/reordering of triangles (up to ~2k or so IIRC) within a draw call and play games with the ROPs/mem.
But shhhh, it's a big secret ;)
https://twitter.com/AndrewLauritzen/status/664513680374034432

[Godmode]

Jede Generation die TBDR Geschichte. ;D

[robbitop]

Es ist kein Geheimnis, dass moderne GPUs immer weiter vom klassischen IMR Konzept entfernt sind. Zumal moderne Engines eh defered Renderer sind - so wahnsinnig viel Overdraw, der auch richtig Takte kostet, sollte es nicht mehr geben.
Ein TBDR hat heute (sieht man ja auch bei Serie 6XT/7 vs ULP Modelle von Kepler und Maxwell) Rohleistungs- und taktnormiert kaum noch Vorteile. Einer der größten Vorteile war der Tile Cache, der viel vom fragmentierten Framebufferverkehr gespart hat, weil erst das fertige Tile in den VRAM geschrieben wird. Das tun moderne GPUs/ULP-GPUs zu einem gewissen Grad auch schon eine Weile.

Wobei ich bei Maxwell vor einer Ganzen Weile auch einen ähnlichen Hinweis mal gelesen habe. Auffällig war es schon, dass Maxwell deutlich weniger Bandbreite brauchte. Die Erklärung dafür war ja zunächst die Deltacompression - allerdings hatte auch Fermi und Kepler schon so etwas - nur noch nicht ganz so ausgereizt. Aber gemäß des Gesetz des sinkenden Grenzertrags war der Sprung damals für die dritte Iteration (hier erwartet man eigentlich Optimierungen, die kleinere Sprünge bringen) schon auffällig hoch. Bei AMD brachte die DDC auch vergleichsweise wenig.

Es kann also schon sein, dass Maxwell gerade in Bezug auf Tilebuffering deutlich konsequenter als seine Vorgänger ist.

[deekey777]

http://www.realworldtech.com/tile-based-rasterization-nvidia-gpus/

Starting with the Maxwell architecture, Nvidia high-performance GPUs have borrowed techniques from low-power mobile graphics architectures. Specifically, Maxwell and Pascal use tile-based immediate-mode rasterizers that buffer pixel output, instead of conventional full-screen immediate-mode rasterizers. Using simple DirectX shaders, we demonstrate the tile-based rasterization in Nvidia’s Maxwell and Pascal GPUs and contrast this behavior to the immediate-mode rasterizer used by AMD.


Aha!

[Foobar2001]

Das muss aber irgendwie auf dem Chip passieren.

Traditionelle Tiler haben grosse Probleme mit Tesselation, wenn der Tile-Buffer ueberlaeuft. Und NVIDIA hat das ja offensichtlich nicht.

[Gipsel]

http://www.realworldtech.com/tile-based-rasterization-nvidia-gpus/

Aha!
Der nimmt eine HD6670 als Test für eine AMD-Karte? Das Teil ist ein VLIW-Chip mit nur einem einzigen Rasterizer. :rolleyes:
Es gab bereits vorher Tests, die versucht haben, Licht in die Rasterordnung der verschiedenen Chips zu bringen. Und die sehen einen Unterschied zwischen den alten VLIW-Teilen und GCN. Es ist sicher anders als bei nV, aber sicher auch anders als bei der HD6670. AMD weist die Rasterizer gemäß Screentiles zu (zumindest wenn es anders als bei der HD6670 mehr als einen gibt :rolleyes:), genau so wie die ROPs und cached zumindest im Backend (ROPs) Screentiles (allerdings andere Zuordnung als beim Rastern, um Aliasing der Zuordnungen zu minimieren, also ein wenig stochastisches Load-Balancing zu betreiben), die abhängig vom Pixelformat unterschiedlich groß sein dürften (alternativ werden abhängig vom Pixelformat unterschiedlich viele Tiles im Cache gehalten). Der Unterschied ist, daß bei nV die Dreiecke schon beim Rasterizer nicht nur an einen bestimmten Rasterizer zugewiesen, sondern offensichtlich (bis zu einer von verschiedenen Parametern abhängigen Obergrenze [damit es in on-chip-Caches paßt]) auch gesammelt werden, bei AMD nicht (weswegen es bei AMD deutlich weniger ausgeprägt ist, daß ein Screentile dem benachbarten "vorausläuft"). Bei AMD geht es nach dem "coarse raster" bzw. binning in Screentiles wohl mehr oder weniger direkt zu dem jeweils zugeordneten Rasterizer wobei jeder davon eine eigene Queue besitzt (Größe unbekannt). Dreiecke, die mehrere Tiles überstreichen (wie in dem verlinkten Beispiel), werden dupliziert. Kleinere Dreiecke, die in nur ein Tile passen, können parallel zu denen in anderen Tiles gerastert werden und diese dementsprechend auch überholen. Bei nV werden wohl zuerst Dreiecke gesammelt (nicht alle, sondern maximal eine bestimmte Anzahl) und dann jeweils so ein ganzer Batch gebinnt und gerastert (was das effizientere Verwerfen verdeckter Geometrie ermöglicht), nicht mehr oder weniger strikt in-order wie bei AMD.

NVidia hat sicher die fortschrittlichste Architektur des Setup/Raster-Teils des Chips. Aber GCN packt zumindest auch eine Evolutionsstufe gegenüber der von ihm gezeigten HD6670 drauf.

Edit:
Anderer Test (von einem anderen Menschen, bereits über 2 Jahre alt und mit Fullscreen nicht Halfscreen-Dreiecken, die Färbung funktioniert auch etwas anders, daher nicht 1:1 vergleichbar) mit GCN:

https://michaldrobot.files.wordpress.com/2014/04/ps_pattern.jpg

Und hier mit zwei Half-Screen-Dreiecken:

https://michaldrobot.files.wordpress.com/2014/04/quad.jpg

Wie gesagt, HD6670 macht das anders als die neueren GCN-Karten. Bei denen kann man auch Screentiles beobachten, die Basis für die Zuordnung zu den Rasterizern sind.

[StefanV]

Auch AMD weist die Rasterizer gemäß Screentiles zu
Macht AMD das ganze nicht schon seit der Radeon X1 Generation??
AFAIR gabs da doch 'nen entsprechenden Crossfire Modus, oder?

Gut, das ganze hat man immer wieder mal verbessert, aber dass die AMD Chips keine "Tiler" sein sollen, ist nicht anzunehmen...

[Foobar2001]

AMDs GPUs sind definitiv keine Tiler. Es gibt kein Binning.

[Gipsel]

AMDs GPUs sind definitiv keine Tiler. Es gibt kein Binning.Du hast vollkommen recht, da man eigentlich nur von Binning sprechen kann, wenn irgendwas in diesen Bins gesammelt wird und es über die reine Zuordnung hinausgeht. Bei AMD gibt es nur ein wenig Queuing vor den einzelnen Rasterizern. Die Screentiles werden bei AMD bisher im Wesentlichen nur dazu genutzt, um die ROP-Caches etwas effizienter zu gestalten und die Rasterisierung nach dem Coarse Raster zu parallelisieren. Also im Endeffekt wohl, um die GPU über mehrere Shader-Engines skalierbar zu machen. Von einem Tiler ist das recht weit weg (aber sicher ausbaubar, was wir hoffentlich mal bald sehen).

[Foobar2001]

Laut Andrew Lauritzen gibt es wohl ein ziemlich kleines Poly-Limit fuer die Bins bei NVIDIA (2k vertices oder so). Das heisst es kommt darauf an wie viele Dreiecke und wo sie gerendert werden, ansonsten muss halt rausgeschrieben werden.

Wo es viel bringt ist wohl bei Fullscreen-Blend-Passes. Anscheinend kann NVIDIA da komplett vermeiden durch die ROPs zu gehen, sie blenden einfach direkt in den Tile-Cache. Ziemlich cool.

[Mancko]

Hier bei Beyond3D wird dazu auch schon kräftig diskutiert.

https://forum.beyond3d.com/threads/tile-based-rasterization-in-nvidia-gpus.58296/

[Ailuros]

Und so alt ist die Debatte wie der relevante Kommentar von Arun hier: https://forum.beyond3d.com/posts/1934105/

Nur wurde ich damals nahezu gelyncht hier im Forum als ich es damals erwaehnte. Es war schon damals die Rede davon dass es sich nur auf eine begrenzte Menge von Geometrie handelt. Kurz: man benutzt stellenweise tiling nur da wo es wirklich noetig ist ohne dass die insgesamte rendering Philosophie je von einem IMR wirklich abweicht.