Der Frontend - Geometry- Rasterizer - Backend Thread

[Digidi]

Viele reden nur noch über Shaderanzahl, Shadereffizienze etc.

Teile wie Frontend und Backend sind aus unseren Diskussionen total verschwunden.

Deshalb eröffne ich hier mal einen Thread der dem Frontend und dem Backend huldigt. Hier bitte alle Infos und Informationen Posten die Ihr zu neuen Frontend und Backends findet.

Vielleht kann jemand mal mir Informationen von Turing und Navi lievern wie hier der Stand der Dinge ist und was zu den vorgängern verändert wurde.

[Rampage 2]

Ich wüsste erstmal gerne, welche Konsequenzen für die (Roh-)Leistung die Verdopplung der GPCs/Raster-Engines von TU106 (RTX 2070, 2060 Super, 2060) zu TU104 (RTX 2080, 2080 Super) hat?

Rein theoretisch bedeutet doppeltes Front-End (GPCs/Raster-Engines) auch doppelten Polygondurchsatz bei gleichem Takt, korrekt?

In welchen Szenarien (z.B. Auflösung oder bestimmte Grafikeffekte/-workloads) wären die Konsequenzen am sichtbarsten?

R2

[Gast]

In welchen Szenarien (z.B. Auflösung oder bestimmte Grafikeffekte/-workloads) wären die Konsequenzen am sichtbarsten?

Extrem hohe Tesselationsfaktoren.

[pixeljetstream]

so zur Auffrischung, sorry fuer die Augenkrebsfarben war damals zu faul schoene Diagramme neu zu machen und hatte aus anderen Praesentationen als bild copy pasted ;)

blog (2015)
https://developer.nvidia.com/content/life-triangle-nvidias-logical-pipeline

praesentation (2016)
https://on-demand.gputechconf.com/gtc/2016/presentation/s6138-christoph-kubisch-pierre-boudier-gpu-driven-rendering.pdf

front-end ist bei NV eher als der teil definiert der die Arbeitspakete/commands verarbeitet. Also die befehle die aus der Grafik API ueber den Treiber an die GPU geschickt werden. Hier passiert so die grundsaetzliche Arbeitsverteilung. Das ist imo nicht ganz so spannend was da passiert (abgesehen von Spezialfaellen).

Front-end bound ist man wenn zum Beispiel in der API zu viele drawcalls generiert die kaum Arbeit machen. Frueher waren die APIs dann eher CPU bound wegen der ganzen API/Treiber Validierung, heute ist das bei den neuen APIs aber flott und man kann dann in der GPU front-end bound werden. Sagen wir mal man rendert jeden low-poly Baum einzeln. Oder viele shader wechsel (was im front-end mehrere befehle zur Folge hat) die kaum Arbeit erzeugen.

Zwar hilft sowas wie instancing aber oft ist der Einsprung der Arbeitsverteilung eben durch das front-end was nicht direkt skaliert ist. Das war zum Beispiel eine Motivation fuer die task-shader die dann mesh shader skalierbar generieren koennen, so wie tessellation skalierbar die dreiecke der patches generiert ohne durch das front-end zu muessen.

Das front-end haengt also stark am clock der GPU. So kann es sogar sein das manche bottlenecks dann auf den kleinen GPUs die mehr clock haben, weniger auffallen als auf den grossen die weniger clock haben und mehr darunter leiden dass die Arbeit den Rest der GPU kaum aulastet.

Was GPC raster etc. angeht, so ist das nicht so oft in Spielen ein bottleneck, meist da wo viel Geometrie fuer shadow maps verarbeitet wird (weil dann shading praktisch aus ist und nur Geometrie pipeline gestresst wird). Ich darf leider nicht sagen wie sich welche Titel genau bei uns verhalten, auch wenn wir diese Daten erheben. Aber man kann selbst mit nsight ein gpu-trace erzeugen und dann gucken was die counter so sagen.
https://developer.nvidia.com/blog/the-peak-performance-analysis-method-for-optimizing-any-gpu-workload/

Bei CAD Programmen oder DCC Applikationen (3dsmax, maya, blender etc.) ist man schon eher geometry-bound, weil hier oft viel Geoemtrie anfaellt, und weil es ein Editor ist, die engines selten LoD generieren.

[Rampage 2]

Front-end bound ist man wenn zum Beispiel eine API zu viele drawcalls generiert die kaum Arbeit machen. Frueher waren die APIs dann eher CPU bound wegen der ganzen API/Treiber Validierung, heute ist das bei den neuen APIs aber flott und man kann dann in der GPU front-end bound werden.


Also DX11- (oder DX10) Spiele? Crysis 2 (2011) war zwar auch ein DX11-Spiel, aber AFAIR skalierte es dennoch gut mit mehr CPU-Kernen (bis zu Quad-Cores) und Crysis 3 war immernoch DX11, legte aber sogar eine Schippe drauf (noch besseres Multithreading, HT brachte einen dramatischen Performance-Boost). Ebenso die Frostbite-Engines mit DX11: BF3 - BF1 konnten auch mehr als 4 Kerne/Threads gut auslasten, obwohl sie noch DX11 waren.

Wenn ich an ein DX10/11-Spiel denke, was schlechtes Multithreading aber gleichzeitig hohe CPU-Last und vor allem sehr hohe Polygon-Last hat (ganz abseits des extrem hohen Shader- und Grafiklasts), dann fällt mir auf die Schnelle nur das Ur-Crysis (2007) ein - in den ersten Jahren nach Release machte es sich aber nicht bemerkbar, weil damalige GPUs mit der Grafiklast brutal überfordert waren. Erst mit späteren GPU-Generationen (Fermi, Kepler, Maxwell) wurde das zunehmend relevant.

Oder sind CPU-Last/Auslastung und Drawcalls zwei paar Schuhe:|


Was GPC raster etc. angeht, so ist das nicht so oft in Spielen ein bottleneck, meist da wo viel Geometrie fuer shadow maps verarbeitet wird (weil dann shading praktisch aus ist und nur Geometrie pipeline gestresst wird).


Warum sollte eine Shadowmap (also eine Textur, korrekt?) soviel Geometrie brauchen? Ist doch letztendlich nur eine Textur... :|

R2

[pixeljetstream]

Zu den APIs, ich hatte mich vertippt: wenn man _in_ einer API zu viele drawcalls generiert...
Die neuen APIs bringen ja in erster Linie die Einsparung auf der CPU Seite, deswegen muss die GPU diese Befehle im front-end immer noch abarbeiten.

Pro Befehl den du in der API machst, muss der Treiber diesen umwandeln in das was die gpu versteht. Da die GPUs nicht immer 1:1 eine api abbilden muss teilweise eine validierung und Umformung der Befehle passieren in das native Format der GPU. Die neue APIs haben gemein dass viel über den Zustand (shader, render target format...) Vom Entwickler vorher definiert und als Objekt gespeichert wird. Dieses vor-validierte Objekt kann dann bei der Nutzung der api direkt verwendet werden. So kommt die CPU Ersparnis zustande.

Alt: setze Zustand X auf a, setze Zustand Y auf b, drawcall (Treiber validiert die Kombination von X und Y)

Neu: setze ZustandsObjekt o (was Xa und Yb enthält), drawcall

Das Objekt o wird vorher vom Entwickler erzeugt und kann wieder verwendet werden. Man kann es leicht auf verschiedenen threads erzeugen etc. Der Entwickler weiß also eher wann kosten auf der CPU entstehen.

ShadowMap
Die werden ja dynamisch generiert, du musst alles was Schatten wirft da rein rendern. Viele Lichtquellen oder Sonnenlicht das viel abdeckt heißt viel Geometrie Arbeit.

[Digidi]

:up: Danke Pixeljetstream.

Wenn ich mir die Nanite Engine so ansehe mit den Pixelsize Polygonene. Das sieht schon Hammer aus. RLZ hat ja gesagt das es da noch andere verfahren gibt. Ich frage mich warum man eigentlich nie so kleine Polygonen wollte und man das schon früher dahin entwickelt hat mit entsprechendem Rasterizer. Nanite sieht wirklich bahnbrechend aus, warum springt da kein NVIDIA oder AMD als Vorreiter auf?

NVIDIA ist ja auch mit RTX vorangegangen.

[pixeljetstream]

Das Problem der kleinen Polygone ist alt im proviz Bereich, das ist etwas mit dem ich mich viel beschäftigt habe. Ich kann leider nicht genau auf Dinge eingehen die erforscht wurden oder werden. Guck einfach wie das früher vor 20-10 Jahren schon gelöst wurde... damals musste man noch mehr Logik auf der CPU oder in clustern haben, heute gehen diese Algorithmen auch auf der GPU. Sorry dass ich da nicht mehr sagen darf.

Ich sehe es als positiv was epic machen kann, das zeigt IMO die Stärke der Flexibilität der Features in den APIs und der hw, sowie deren Performance. Diese Firmen haben es leichter sowas umzusetzen, weil sie die content Pipeline mit ihren Editoren/Tools auch haben und auch beim rendern sich nicht an Standards halten müssen (das was fixed function rasterizer machen muss). Sie können durch die programmierbaren Lösungen eben eigene „cleverness, tricks“ einbringen. Aber es sollte auch klar sein, dass es nie magische Lösungen gibt, sie haben sich etwas ausgedacht was sehr gut für sie funktioniert, aber jeder Ansatz hat Stärken und Schwächen, irgendwann werden sie das sicher mal deutlicher erklären bei siggraph oder gdc.

[Dampf]

Bei Nanite find ichs nur schade, dass die neue Hardware nicht genutzt wird. Zumindest zum Beschleunigen.

So wird die neue Hardware die sich in RDNA2/Turing/Ampere und den Next Gen Konsolen befindet, die Mesh Shading möglich macht, halt nicht ausgenutzt.

[][immy]

:up: Danke Pixeljetstream.

Wenn ich mir die Nanite Engine so ansehe mit den Pixelsize Polygonene. Das sieht schon Hammer aus. RLZ hat ja gesagt das es da noch andere verfahren gibt. Ich frage mich warum man eigentlich nie so kleine Polygonen wollte und man das schon früher dahin entwickelt hat mit entsprechendem Rasterizer. Nanite sieht wirklich bahnbrechend aus, warum springt da kein NVIDIA oder AMD als Vorreiter auf?

NVIDIA ist ja auch mit RTX vorangegangen.
Dazu hatte das 3dcenter mal nen Artikel vor ewigen Jahren. Da ging es glaube ich um RT das die Rechenlast mit traditionellen verfahren rein theoretisch höher wäre, wenn die Polygone kleiner werden als Pixel.

Insgesamt haben aber die ganzen Polygone noch andere Probleme, z.B. brauchst du mehr Platz um die ganzen Koordinaten zu speichern. Hier setzt ja eigentlich Tesslation an, was allerdings auf der kleinen Ebene (für mini-Details) eher dann nicht so gut geeignet wäre (wenn ich das richtig verstanden habe). Du kannst damit zwar gut Daten einsparen wenn du aus etwas Eckigen etwas rundes machen möchtest, aber schwierig wird es halt, wenn das Eckige auf bestimmte Art verformt etc sein und dann noch Details enthalten soll.


Die Rohleistungsdaten sind seit ner gefühlten Ewigkeit nicht mehr sonderlich wichtig. Die sind höchstens mit gestiegener Auflösung skaliert. Die allgemein verfügbare Rechenleistung (Shader) mit der du alles mögliche machen kannst (und nicht nur eine Sache) ist hingegen etwas wovon man quasi nie genug bekommen kann (solange nichts anderes bremst).

[pixeljetstream]

Die Größe der Daten ist auch der Grund warum quadros lange 2x Speicher hatten. Geometrie in spielen wird durch normal Mapping, instancing, Artist Control gedrückt. Wenn du die Boeing, Kreuzfahrtschiff mit Verkabelung, Hydraulik etc. willst, Sind die auch fix bei GBs nur index und vertex buffer.
Und auch da muss man zum Teil auf Streaming zurückgreifen, wobei heute zum Glück seltener. Sowas wie epic s Lösung brauch halt auch streaming.

[Digidi]

Ein Grund warum Nanite dann wohl auf PS5 präsentiert wurde. Mit dem Streaming kann man recht viele Polygonen recht schnell nachladen.

Meine Vermutung Nanite wird so wie wir es sehen wohl nur auf den beiden Konsolen so fuktionieren, weil nur hier die Bandbreite der SSD für das Stereming hoch genug ist und auch garantiert werden kann.

[pixeljetstream]

Das wäre sehr untypisch für eine Multiplatform engine. Außerdem sehen wir diese Details ja auch deswegen weil Epic seine Nutzung im Profimarkt (Film&TV) stark ausbaut. Nicht umsonst betonen sie dass es Film quality assets sind.

Du hast ja bestimmt diese neue LED Stage von ILM für The Mandalorian gesehen. https://www.ilm.com/hatsrabbits/virtual-production-on-the-mandalorian/

[Digidi]

Ja Sie nutzen es für Filme weil sie ja gerade jetzt bei einer Leistung angekommen sind die für Filme tauglich ist.

Laut aussagen einiger Zeitschriften läuft ja die Nanite Demo auf der PS5 mit genau diesem hohen Polygonencount und das ist nur deshalb möglich weil die PS5 voll auf Streaming ausgelegt ist:
https://www.heise.de/newsticker/meldung/Unreal-Engine-5-Epic-Games-zeigt-beeindruckende-Demo-auf-Playstation-5-4720832.html

[Gast]

Praktisch jede moderne engine hat Geometry-Streaming. Das ist nichts neues.

[Digidi]

Es sieht immer mehr danach aus, also ob Entwickler auf micropolygons umsteigen :D
https://twitter.com/SebAaltonen/status/1300372993659592704

[pixeljetstream]

Es sieht immer mehr danach aus, also ob Entwickler auf micropolygons umsteigen :D
https://twitter.com/SebAaltonen/status/1300372993659592704
SDF : signed distance field. Das ist eine Volumetrische Repräsentation, ohne Polygone. Es gibt einen Vortrag von dem Entwickler zu Dreams.

[Digidi]

@Pixeljetstream Danke für den Hinweis


Ps. Es scheint wohl eine Änderung zwischen Maxwell/ Pascal und Turing was den Rasterizer angeht geben zu haben. Es gibt hier keinen Tiled Base ansatz mehr wenn ich das richtig deute:

Gab es seit Turing eigentlich eine Änderungen am Rasterizer hin zu immediate Rasterizer, sieh Bild Triangle Bin? Das sieht jetzt eher wie bei Vega aus als noch vorher bei Maxwell / Pascal.

Rechts bei Relase kann man die zip datei runterladen mit der exe datei als inhalt.

https://github.com/nlguillemot/trianglebin

So sieht das bei Maxwell und Pascal aus:
https://www.realworldtech.com/tile-based-rasterization-nvidia-gpus/

[pixeljetstream]

Das Prinzip der Rasterizer ist seit fermi unverändert (wie im Artikel von mir beschrieben). Mit Maxwell kam die Möglichkeit des Tile Caching dazu, das ist auch immer noch so.
Don’t fix what ain’t broke. Was passiert sind halt „kleinere“ Optimierungen. AFAIK hat sich Navi dem genährt was NV schon länger hatte, um die Skalierung zu verbessern.

[Digidi]

@Pixeljetstream

Ich frag mich halt warum man bei Turing die tiels nicht mehr erkennen kann.

[pixeljetstream]

Das tile caching ist ziemlich flexibel konfigurierbar, war es auch schon immer. Die alten Bilder zeigen nur dass genau in der test Applikation, mit genau dem Treiber und der Karte es zu dem pattern führt. Das load balancing wird sich ja auch dynamisch anpassen.