Funktionsweise von GPU-Hardware (Rasterization, Texturzugriff ...)

[pixeljetstream]

(weiß nicht obs besser in nen anderen thread soll)

Nützliche Links vorweg (erstmal NVIDIA lastig):

GTC 2016
http://on-demand.gputechconf.com/gtc/2016/presentation/s6138-christoph-kubisch-pierre-boudier-gpu-driven-rendering.pdf
http://on-demand.gputechconf.com/gtc/2016/video/S6138.html

Blog post
https://developer.nvidia.com/content/life-triangle-nvidias-logical-pipeline

Misc:
http://www.highperformancegraphics.org/previous/www_2010/media/Hot3D/HPG2010_Hot3D_NVIDIA.pdf

http://graphics.stanford.edu/papers/pomegranate/

[Hübie]

Muchas Gracias :up: Ist ein noch recht frisches Thema und für den ein oder anderen sicher interessant.

[pixeljetstream]

Extrapoliert aus paar slides zu Pascal/Maxwell, und dem vorherigen Material, muss nicht genau so ablaufen.

Immediate Rendering:
Ein transformierter batch lebt in L2 so lange bis er von allen Rasterizern (über die GPU verteilt) abgearbeitet wurde (nur über L2 kann man cross-chip Daten austauschen). Diese arbeiten an allen Rasterisierungstiles (über gesamten bildschirm). Mehrere batches sind in-flight.

Pro:
* geometrie nur einmal transformiert, relativ kleine kurzlebige allokationen im L2
Con:
* die pixelshader, die ja auch parallel an verschiedene jobs aus unterschiedlichen tiles arbeiten, sind in ihren Texturanfragen relativ unterschiedlich. Auf der gleichen SM könnte ein pixelshader warp/wave eines tiles von rechts oben am Bildschirm und links unten laufen. Das heißt der Texturecache ist mit hoher Wahrscheinlichkeit nicht besonders dolle genutzt.
* ROP muss mehrfach das gleiche tile zurück in DRAM schreiben, weil die pixelshader outputs auch von verschiedenen tiles kommen etc. Auch blending wird dann teurer weil wir evtl von DRAM zurücklesen müssen...

Die tiles die nun hier beschrieben sind, sind nicht die kleinen Rasterisierungstiles die in dem Material im ersten Beitrag erwähnt sind. Es sind größere Ausschnitte.

Tiled Caching:
Viele transformierte batches werden nun in L2 gehalten. Statt alle Tiles zu rastern, hält man einen kleineren Bereich am Bildschirm fest. Durch den pumpt man nun alle passenden geometrie batches im cache. Springt dann zu den nächsten Ausschnitt, pumpt sie da durch usw.

Pro:
* Man erhöht die Lokalität der Daten welche im Pixelshader abgegriffen werden.
* ROP brauch im Grunde mehr oder weniger nur einmal zurück zum framebuffer schreiben. Weil das tile ja "fertig" ist und lange die Pixel in L2 bearbeitet werden können. Auch wenn blending aktiv ist sind die Werte dafür auch alle sehr lokal (Einer der Hauptgründe warum mobile chips binner sind, das ganze UI Zeug hat sehr viel blending, hatte also Maxwell/Tegra X1 Relevanz), bzw. msaa die Framebuffer bandbreite sonst stark erhöht.
Con:
* Mehr speicher muss lange im L2 gehalten werden (cached geometry + tile pixels), weniger L2 für den Rest.
* State machine wird nun öfters durchlaufen, da jedes tile ROP mäßig die original Geometriereihenfolge einhalten muss. Statt nen pixelshader samt bindings einmal zu setzen, muss es nun potentiell tile x sein.
* (edit) was tun wenn mehr geometrie da ist, wie unten von Gipsel erwähnt: um das neu transformieren sich zu sparen, werden die restlichen Arbeitsausschnitte abgefertigt. Am Ende ist dann ein tile zwar wieder mehrfach (je nach anzahl der gesamt flushes über alle Geometrie), aber immer noch weniger als ohne das caching.
* klassisches tile rendering würde die Geometrie komplett durch transformieren und im dram speichern und dann von dort zurücklesen oder mehrfach transformieren (was auch die Ausgangsdaten wieder von dram zieht).

Wie genau das verwalten der Geometrie geht, was man sonst noch mit der Information machen kann beim Binning, Tilegrößen... bietet viel Implementationsspielraum.

[pixeljetstream]

Eine sehr nett animierte/illustrierte Darstellung der Grafikpipeline
https://simonschreibt.de/gat/renderhell/

[Gipsel]

* Wenn die geometrie batches nicht in den Cache passen, müssen sie erneut transformiert werden, wenn sich der Arbeitsausschnitt ändert.
Irgendwer hat mal bei B3D behauptet, daß wenn der Platz für die Geometrie im L2 ausgeht, mit den weiteren Arbeitsschritten in der Pipeline angefangen wird, also Alles was bis dahin gekommen ist wird dann erstmal abgearbeitet. Ein Drawcall mit sehr viel Geometrie wird also sozusagen in mehrere Batches aufgeteilt, aber nicht mehrfach transformiert. Aber derjenige hat das auch nur versucht aus ein paar gezielten Benchmarks abzuleiten (ich glaube, er gab sogar die maximale Menge an Daten pro Batch an), hatte also kein Insiderwissen.

[pixeljetstream]

Ja das ist plausibel, dann spart man sich das neu transformieren, und hat einfach halt dann manche tiles wieder N fach. Wobei das N halt immer noch kleiner ist als ohne das Caching.

Ich finde leider kein öffentliches Material von NVIDIA wo mehr Details erwähnt werden, und kann aus rechtlichen Gründen nicht sagen, so oder so sieht's aus ;)
Das was du geschrieben hast hat weniger Nebeneffekte bei den shadern.

[Gipsel]

Das was du geschrieben hast hat weniger Nebeneffekte.Also ja. Danke. ;)

[pixeljetstream]

Texturzugriffe:

Nein, ja, ja. Das erste Nein gilt absolut immer, die beiden Ja im Schnitt bzw. meistens.
Texturen werden im L2 gecached, seit es GPUs mit L2 gibt.

Als allerstes kommen die Texturkoordinaten. Die stammen entweder bereits aus der Interpolation der Vertexattribute (jedem Vertex wird schon bei Erstellung des Modells eine Texturkoordinate zugeordnet) oder werden im Pixelshader irgendwie generiert (gegebenenfalls inklusive Gradienten für die Filterung). Für diese Texturkoordinate+Gradienten fordert dann der Pixelshader irgendwie gefilterte Daten (meist bestimmt durch einen Sampler-Descriptor) einer bestimmten Textur an (welche genau wird durch einen Resourcedescriptor festgelegt, der vereinfacht gesagt sowas wie ein Zeiger auf den entsprechenden Speicherbereich darstellt und auch Informationen über Typ und Größe enthält). Je nach gewählter Kombination erzeugt die Texture-Address-Einheit (praktisch Teil der TMU) dann die eigentlichen Speicheradressen, die für diese Operation nötig ist und fetched diese Daten. Diese können entweder aus dem L1 (bei GCN dem Vektor-L1), dem L2 oder auch dem VRAM selber kommen (bei Vega offenbar auch aus dem kompletten virtuellen Speicher des Systems). Bei nVidia hatten mal GPUs einen getrennten Textur- und allgemeinen L1 (Fermi/Kepler separat, ab Maxwell unified wie bei GCN), aber auch bei einem getrennten Textur-L1 werden Texturen auch im L2 gecached. Der komplette Transfer bis zur TMU findet dabei mit komprimierten Daten statt (meist verwendet man ja irgendeine Form der Texturkompression). Erst vor dem Filtern werden die Daten entpackt (auch der L1 enthält komprimierte Texturdaten [bei de VLIW-GPUs wurde noch beim Transfer vom L2 in den L1 entpackt]). Entsprechend der gewählten Filteroperation werden dann die Daten entsprechend miteinander verrechnet und das Ergebnis dann schlußendlich in ein (Vektor-)Register übertragen, so daß der Shader damit weiterarbeiten kann.

1+

die LOD mipmap stufe ergibt sich aus der Rasterisierung in quads (immer 2x2 pixel, selbst wenn nur 1 pixel coverage hat), da man so die Differenzen bilden kann, und weiß wie stark sich die Texturkoordinate in screenspace ändert. Große Änderung, hohe Mipmap. Mipmappig ist nicht nur ein anti-aliasing Effekt sondern vor allem eine cache optimierung. In der höchsten Auflösung wäre zwei entfernte Texturkoordinaten in unterschiedlichen Teilen der Textur gespeichert, in der Mipmap (welche ja gefilertet pyramide ist) sind sie dann wieder im Speicher näher zusammen.

Bei NVIDIA bekommt deshalb auch die Texturunit Anfragen von 4 Threads auf einmal.
http://on-demand.gputechconf.com/gtc...chitecture.pdf (ab slide 57, wenn auch wie Gipsel sagte kein dedizierter cache parallel zu L1 mehr wie in den Kepler slides)

Ausserdem ist es dem system (compiler/hardware) möglich, Texturanfragen zu batchen, um so die Latenz zu reduzieren. (slide 37 http://on-demand.gputechconf.com/gtc...-rendering.pdf).

Ein gängiges Problem ist auch wenn die Leute von pixelshader auf compute umstellen, dass sie nun die threads ja vollständig selbst verwalten und damit die Texturkoordinaten suboptimal verteilen im Verhältnis zum Fullscreen Pixelshader wo die Erstellung der quads und die Lokalität der threads durch die Hardware vorgenommen wird. Je nach Hardware gibts hier andere Zugriffspatterns die mal besser mal schlechter sind, weswegen compute nicht so "portabel" ist. In Grafik wurden ja klassische gesehen die meisten Memoryzugriffe implizit von der Hardware/Compiler gemanaged, Vertexdatenzugriff, und dann eben die Threadverteilung beim Pixelshader, und auch die Ausgabe durch ROP erfolgt ja sehr "diszipliniert" Bei Compute muss man zwangsläufig schon mehr über die Architektur wissen, sonst lässt man Performance liegen, weil man alle inputs/outputs ja selbst verwaltet.
Natürlich sind auch komplexere Pixelshader möglich (Stichwort OIT usw.), aber die Hauptarbeit beim Szenenpass ist immer noch relativ "einfach".

[Gipsel]

die LOD mipmap stufe ergibt sich aus der Rasterisierung in quads (immer 2x2 pixel, selbst wenn nur 1 pixel coverage hat), da man so die Differenzen bilden kann, und weiß wie stark sich die Texturkoordinate in screenspace ändert.Aus den Gradienten bestimmt sich gegebenenfalls auch der AF-Grad. Man kann übrigens im Shader die Gradienten auch selbst festlegen (bzw. mit manuell festgelegten Koordinaten [müssen nicht die Texturkoordinaten sein] berechnen lassen) und somit die automatisch generierten überschreiben.
Bei NVIDIA bekommt deshalb auch die Texturunit Anfragen von 4 Threads auf einmal.Nicht nur bei nV. Quads gibt es überall. Es hat schon seinen Grund, warum praktisch alle GPUs Quad-TMUs verbauen (also Vierergruppen, die ein paar Daten teilen). ;)

[Hübie]

Texturen werden im L2 gecached, seit es GPUs mit L2 gibt.

Habe ich mittlerweile auch noch mal nachgelesen. Danke für deine Erklärung. :up: Das wusste ich nicht. Wenn man dann so recherchiert stellt man fest, dass doch alles komplexer ist, als man es sich vorstellt. Bisher ging ich davon aus, dass eben der zu bearbeitende Teil der Textur nur im Texture-Cache bzw. unified Cache liegt und die TMU/TAU darauf zugreift und die up-/downloads handelt.
Durch den HBCC könnte man sich ja den Kopiervorgang sparen und direkt das jeweilige Tile laden. Wie ist denn bisher der Ablauf, wenn eine Textur im DRAM liegt? Wird die vollständig in den VRAM kopiert oder gibt es da kein generelles Prozedere (bzw. ist API oder Entwickler-Sache)? :confused:

[pixeljetstream]

Wie ist denn bisher der Ablauf, wenn eine Textur im DRAM liegt? Wird die vollständig in den VRAM kopiert oder gibt es da kein generelles Prozedere (bzw. ist API oder Entwickler-Sache)? :confused:

Es ist Entwicklersache. Die APIs haben die passenden Befehle. Das Texture streaming was viele Spiele betreiben ist ja dass sie selbst analysieren welche mips sie von was brauchen und dann kopieren sie das async rüber.

(Mit DRAM meinst Du System Speicher der CPU?)

[Hübie]

Und das wiederum wird von der DMA-Copy Engine gehandhabt, richtig? Was genau ist das für eine Einheit? Teil des IMC oder sitzt diese im PCIE Phy auf der GPU?
Meine Vorstellung ist, dass die Daten vom PCIE herein gestreamt werden und dann über das OCN in den VRAM geschoben werden. Die DMA Engines sind dabei die Controller. Irgendwo müssen dann ja die neuen Adressen hinterlegt werden oder wird da automatisch die page table aktualisiert?

(Wahrscheinlich sind da einige dumme Fragen dabei, aber wir dürfen nicht vergessen das ich Laie bin :D)

[Rooter]

Eine sehr nett animierte/illustrierte Darstellung der Grafikpipeline
https://simonschreibt.de/gat/renderhell/Das ist ja mal klasse gemacht und erklärt, danke für den Link! :uup:

MfG
Rooter

[Gast]

Hier ein Link zu AMD's GCN "out of order" rasterization
http://gpuopen.com/unlock-the-rasterizer-with-out-of-order-rasterization/

Sehr interessant weil die Rasterizer normalerweise (primitiverweise) gleichgestellt sind (strict order) während GCN die Ordnung flexibler gestalten kann.

[pixeljetstream]

Schade dass sie keine benchmarks oder details angeben auf welcher hardware für welche Szenarien das wieviel bringt. Ist natürlich Szenen abhängig, aber so grob für paar standard Szenen wäre nett.

[Gast]

Kann mir jmd in einfachen Worten erklären, warum es bei GPUs nicht die Entwicklung in Richtung "Mehrkern" gibt?

[crux2005]

Kann mir jmd in einfachen Worten erklären, warum es bei GPUs nicht die Entwicklung in Richtung "Mehrkern" gibt?

https://www.pcper.com/reviews/Graphics-Cards/NVIDIA-Discusses-Multi-Die-GPUs

[Gast]

https://www.pcper.com/reviews/Graphics-Cards/NVIDIA-Discusses-Multi-Die-GPUs

Vielen Dank!

Scheint also "wohl nur" eine finanzielle Hürde zu geben.

[pixeljetstream]

https://devblogs.nvidia.com/the-peak-performance-analysis-method-for-optimizing-any-gpu-workload/

Artikel zum Profiling von Pascal der auch ein wenig Rückschlüsse auf die Funktionsweise zulässt.

[Gast]

https://www.pcgamesn.com/amd-navi-monolithic-gpu-design

- “We haven't mentioned any multi GPU designs on a single ASIC, like Epyc, but the capability is possible with Infinity Fabric."

- “We’re going down that path on the CPU side, and I think on the GPU we’re always looking at new ideas. But the GPU has unique constraints with this type of NUMA [non-uniform memory access] architecture, and how you combine features... The multithreaded CPU is a bit easier to scale the workload. The NUMA is part of the OS support so it’s much easier to handle this multi-die thing relative to the graphics type of workload.”

[Hübie]

Falscher Thread? :|

[pixeljetstream]

Wenn auch etwas alt ;) nette Beschreibung der frühen 3d Karten
http://fabiensanglard.net/vquake/
http://fabiensanglard.net/3dfx_sst1/

[pixeljetstream]

https://gpuopen.com/presentations/2019/nordic-game-2019-triangles-are-precious.pdf

AMD Präsentation zum life of triangle.