Stell Dir vor es ist Revolution und keiner schaut hin. Täglich kämpfen die Protagonisten der werbefinanzierten Gaming und Hardware-News um Sensationen mit Klickbaits und dennoch bleiben wirklich revolutionäre Entwicklungen über Wochen hinweg unberichtet:
Anlässlich der
Siggraph 2021 am 10. August 21 gab
Brian Karis, Engineering Fellow at Epic Games eine ausführliche Präsentation
"Nanite a Deep Dive" zur Entwicklung der Arbeitsweise der kommenden Unreal Engine 5.
I spent a very long time exploring other options and for our requirements have found no higher quality or faster solution than triangles.
Bislang versetzte das
Demomaterial zu Nanite und Lumen die Betrachter in ungläubiges Staunen, die Erklärung wie das möglich ist liegt nunmehr
als PDF auf dem Tisch: Bei UE5 verzichtet man weitgehend auf Hardwarebeschleunigung der herkömmlichen Grafik-Pipeline und rendert schneller im
Rasterizing-Verfahren in Software, um Faktor 3.
Why should we draw more triangles than pixels?
Der Trick bei der Sache ist, dass nicht mehr in der Z-Ebene beliebig viele Polygone für den Bildaufbau durch die klassische Pipeline geschoben werden. An deren Stelle tritt ein Abstraktionsmodell, das ausgehend vom jeweils darzustellenden Bildausschnitt im Idealfall nur 1 Polygon je Pixel berechnet. Der Bildausschnitt wird durch die sichtbare Oberfläche als Mesh repräsentiert, das sich aus einer Vielzahl kleinerer Mesh-Cluster zu je 128 Dreiecken zusammensetzt. Dabei werden mehrere LOD Stufen der 3D-Objekte vorgehalten und mittels gerichtetem azyklischem Graph (DAG) abgebildet.
Von Frame zu Frame wird das gesamte Mesh anhand des Graphen nur in den notwendigen Mesh-Cluster gemäss den LOD Anforderungen von maximal einem Dreieck je Pixel aktualisiert.
Der Wechsel zwischen den LOD Stufen ist dabei entscheidend, die Details müssen stets hoch genug gehalten werden, dabei hilft TAA bei der Kaschierung der Wechsel.
But if we only draw clusters that are less than 1 pixel of error they are imperceptibly different and temporal antialiasing smoothes out any change.
Um die jeweils sichtbaren Cluster für das Rasterizing zu selektieren bedient man sich einer
Block Volume Hierarchy wie man solche auch für Echtzeit-Raytracing verwendet.
Die Aufgabe beim Rastern dieser
Micro-Polygone ohne Z-Sortierung passt dann nicht mehr zu den üblichen fixen Funktionen der GPUs. Cluster von Dreiecken von bis zu 32 Pixel Umlauf liessen sich schneller per generischem Compute berechnen.
Tiny triangles are terrible for a typical rasterizer, HW rasterizers included. They are designed to be highly parallel in pixels not triangles since that’s the typical workload.
Modern GPUs setup 4 tris/clock max and outputting primitive ID needed for vis buffer makes this even worse.
Primitive shaders or mesh shaders can be faster but are still bottlenecked and not designed for this.
...our micropoly software rasterizer. All the fancy hierarchical tiling and stamps gets thrown out the window. We are left with a super basic half space rasterizer that has been instruction level micro-optimized.
It is kind of similar in structure to mesh shaders. It shares vertex work without any need for a post transform cache. Threadgroup size is 128.
In the first phase a thread is mapped to a vertex from the cluster’s vertex buffer. Fetch the vertex position, transform it, and store in groupshared.
If there are more than 128 verts fetch and transform another to support up to 256 per cluster.
Then in the 2nd phase switch to a thread mapped to each triangle with a max of 128 triangles per cluster. Fetch the indexes for this triangle. Use those to fetch the transformed positions from groupshared. Calculate the edge equations and depth gradient for the triangle. Then for all pixels inside the rect bounding the triangle. Test if inside the triangle and if so write the pixel.
Durch die Optimierung des Meshes werden wenige
grössere Polygone mittels üblicher Pipeline berechnet, denn der Hardware-Rasterizer ist effizienter bei grösseren Polygonen. Die Unterscheidung Hardware vs. Software wird per Cluster getroffen,
DirectX erlaubt diesen Mischbetrieb ohne Ausgabefehler zuzulassen.
Der Vortrag beschreibt noch weitere Entwicklungen von Technologien zur Engine betreffend Materialien bzw. Oberflächeneigenschaften, Schattendarstellung, dem Streaming von Assets und deren Komprimierung.
Hier sei nur die Schattenberechnung und Streaming näher erwähnt: Bei Schatten nutzt man die Vorteile der Abstraktion und verwendet
16k Shadowmaps, ebenso mit der Zielsetzung der Auflösung von einem Pixel. Dafür werden
virtuelle Shadow Mip Maps per Pixel per Lichtquelle parallel in ein Array of Views berechnet. Diese werden im Cache gehalten und nur Änderungen je Frame aktualisiert.
The Nanite pipeline gets an array of views to render into instead of just one.
Now not only can Nanite draw the entire scene with a single chain of dependent dispatch indirects. It can render all shadow maps for every light in the scene, to all of their virtualized mipmaps at once.
Anhand des LOD-Modells können einzelne Cluster optimal in den Speicher der GPU gestreamt werden. Spätestens hier zeigen sich die Ähnlichkeiten in den grundlegenden Konzepten zu virtuellen Texturen.
Microsoft hat mit
Sampler Feedback Streaming ein ähnliches Verfahren inclusive HW-Unterstützung für Texturen entwickelt. Nanite sucht für Geometrie bzw. Mehes gleichermassen eine Softwarelösung um
nur die tatsächlich relevanten Daten zu berücksichtigen und diese vom Datenspeicher in passenden Chunks in den GPU-Speicher zu laden und zu verarbeiten. Entsprechend dem DAG werden nun bei Nanite nur die aktuell relevanten Cluster mittels Streaming im VRAM vorgehalten.
Für die UE5 Engine lässt sich das
Zwischenfazit ziehen, dass diese neue Herangehensweise für viele Anforderungen des Renderns keine offensichtliche Lösungen bietet. Der Einsatz von TAA mit Skalierung scheint konzeptuell gewollt zu sein. Feingliedrige dynamische oder transparente Objekte wie Haare, Flüssigkeiten oder animierte Bewegungen von Lebewesen lassen sich nicht einfach mit dieser Herangehensweise umsetzen. Es braucht alternative Ansätze, die dennoch hinter der Qualität für
photorealistische – eher statische – Oberflächen nicht zurück bleiben. Ebenso bleibt unklar wie prozedurale bzw. fraktale Strukturen behandelt werden sollen, wie diese heute bei Terrain genutzt werden, oder wie man komplexe Szenen mit vielen Verdeckungen im Raytracing behandelt. Man darf daher auf weitere Präsentationen zum Fortschritt gespannt sein.
Software Rasterizing kommt nicht urplötzlich, schon Dan Baker hatte einmal in den Raum gestellt er könne sich eine Engine ohne die übliche GPU Pipeline durchaus vorstellen. Auch sind die referenzierten Arbeiten als Grundlagen von Nanite teils Jahrzehnte alt.
Das besondere Momentum - die Revolution - allerdings ist, dass ein so kommerziell erfolgreiches Produkt die herkömmliche Grafik-Pipeline derart radikal hinter sich lässt um neue Wege zu gehen. Die Entwicklungen bei der Hardware werden hierauf sicherlich reagieren.
Bei der künftigen Hardware könnten GPUs profitieren, die eine 128 Wave bzw. 128 Warp Size nativ unterstützen. Die Auslastung von Shadern sollte durchweg sehr hoch sein, ein Problem, unter dem GCN mit Vega bei üblichen 32 Threads pro Wave unter DX11 noch zu leiden hatte was durch RDNA behoben wurde.
Für die BVH Berechnungen könnten RT-Beschleuniger wie beim Raytracing gleichermassen genutzt werden.
Für die Anpassung von Games auf bestimmte Hardware wird interessant werden, ob man die Anzahl der Dreiecke pro Cluster oder den Schwellenwert der Pixelanzahl für HW-Rasterung anpassen können wird um die Eigenheiten der jeweiligen GPU und Cache-Hierarchien zu berücksichtigen.
Ob die neue UE5 Engine tatsächlich einen Paradigmenwechsel einleitet ist heute noch offen. Gerade das erwähnte Sampler Feedback Streaming und das Variable Rate Shading für Dreiecke in Kombination mit Direct Storage könnten in fortentwickelten Engines der herkömmlichen Grafik-Pipeline ähnliche spektakuläre Ergebnisse ermöglichen.
Das
besonders wertvolle an der Präsentation insgesamt ist, dass sie eine
ausführliche Referenzierung von wissenschaftlichen Quellen aufweist und im Kommentar teils Bezug auf diese Grundlagenarbeiten nimmt. Dadurch werden die Zusammenhänge transparent und nachvollziehbar. Damit öffnet EPIC die Möglichkeit der raschen Adaption und Anpassung der Technologien für andere Engine-Entwickler.
(Überarbeitung mit mehr Links folgt später...)