Erste Detail-Berichte zu nVidias Turing-Architektur erschienen

Wir erwartet, sind Freitag Nachmittag die Architektur-Artikel zu nVidia Turing-Architektur erschienen (untenstehend verlinkt). Selbige erklären die Feinheiten jener neuen Grafikchip-Architektur, welche sich eben nicht nur auf das Thema RayTracing beschränken, sondern vor allem auch beim konventionellen Grafikrendering erhebliche Vorteile bieten – siehe schon die neuen Shader-Cluster bei Turing [1]. Zu selbigen klären sich nun auch einige noch offene Fragen: So lassen sich die extra Integer-Einheiten zeitgleich mit den konventionellen FP32-Einheiten nutzen, was für einen erheblichen Performance-Boost sorgen soll. Denn laut nVidia kommen in modernen Spielen auf 100 FP32-Berechnungen auch schon ca. 36 Integer-Berechnungen (bei Battlefield 1 dagegen sogar 100:50) – welche bisher in den FP32-Einheiten früherer Grafikchip-Architekturen mit ausgeführt wurden, dafür aber die jeweiligen Shader-Einheiten für andere FP32-Berechnungen blockiert haben. Nun kann alles nebeneinanderher ausgeführt werden, blockieren die verschiedenen Rechenoperationen sich also nicht mehr gegenseitig. So gesehen haben die Shader-Cluster von Turing dann also doch wieder 128 Ausführungseinheiten – die stärker genutzten 64x FP32- sowie die etwas weniger genutzten 64x INT32-Einheiten (Nutzungsverhältnis grob 74:26%).

Korrigiert werden muß hingegen die Anzahl der Special Functions Units (SFUs) – jene sind auf den bisherigen Blockdiagrammen schlicht nur zusammengefasst dargestellt, woraus eine falsche Anzahl geschlossen wurde. Real sind es allerdings 16 Stück pro Shader-Cluster, was die Hälfte gegenüber Pascal darstellt, aber weiterhin dieselbe Anzahl an SFUs pro Shader-Einheit ergibt. Ergänzt werden kann zudem die Anzahl der FP64-Einheiten mit 2 pro Shader-Cluster (halbiert gegenüber Pascal, aber weiterhin gleich pro Shader-Einheit), das weiterhin 256 kByte große Register-File (wie bei Pascal, damit verdoppelt pro Shader-Einheit) sowie der umgestaltete Level1- und Daten-Cache, welcher insgesamt 96 kByte groß ist (Pascal: zusammen 144 kByte für die doppelte Anzahl an Shader-Einheiten). Damit geht nVidia weiter den Weg, auf den gesamten Grafikchip bezogen zwar die gleiche Anzahl an Recheneinheiten zur Verfügung zu stellen, die Verwaltungslogik sowie die Caches allerdings jeweils nahezu (pro Shader-Einheit) zu verdoppeln. Zusammen mit den dedizierten Integer-Einheiten liegt hier wie gesagt das große Potential der Turing-Architektur unter ganz konventionellen Spielen ohne jeden RayTracing-Einsatz.

Zugleich klärt sich nun auch endlich auf, wie nVidia seine neue "Deep Learning Super Sample [2]" (DLSS) Kantenglättung rein technisch löst. Wie bekannt, liegt der Clou von DLSS in der Hinzufügung von Glättungsinformationen aus der Cloud, in welcher das jeweilige Spiel (vorab) seitens nVidia mittels Vergleichsbildern auf 64x Supersampling trainiert wurde. Für DLSS gibt es dann zwei Modi, das normale DLSS sowie ein "DLSS 2X" – mit sehr voneinander abweichendem Ansatz. Denn das normale DLSS arbeitet nun tatsächlich schlicht mit einer intern reduzierten Renderauflösung – der ganze Trick besteht also in einem klassischen Upscale-Filter, wenngleich jener sicherlich mit einer hochqualitativen Kantenglättungs-Datenquelle aus der Cloud gefüttert wird. Die interne Renderauflösung von DLSS ist dabei nicht auf einen bestimmten Wert festgesetzt, sondern unterscheidet sich von Spiel zu Spiel – hier liegt jedoch in jedem Fall der Grund für die mit DLSS bisher präsentierten erheblichen Performancegewinne [3]. Ob diese technische Herangehensweise Begeisterungsstürme auslöst, wäre zu bezweifeln – gerade da nVidia in aller Regel seine Benchmarks [4] unter dem normalen DLSS erstellt, die allermeisten Bildqualitätsvergleiche jedoch vom höherwertigen DLSS 2X stammen.

Bei jenem DLSS 2X wird die interne Renderauflösung dann eben nicht verändert, sondern entspricht dem, was der Spieler eingestellt hat. Demzufolge kommt auch nur in DLSS 2X garantiert eine höhere Bildqualität heraus – während dies beim normalen DLSS sicherlich einen Streitpunkt darstellt. Technisch gesehen stellt das normale DLSS schlicht ein Rendering in einer niedrigen Auflösung mit dann sicherlich sehr guter Kantenglättung oben drauf dar – aber es würde verwundern, wenn da kein beachtbarer Informationsverlust innerhalb von Texturen & Geometrie etc. auftritt. Leider liefern die diversen Architektur-Berichte hierzu noch keine wirklich guten Informationen, sondern zu allermeist nur nVidias Marketingmaterial, nicht jedoch eigene Screenshot-Vergleiche. Womöglich sind jene derzeit aber auch einfach noch nicht zulässig, das NDA für die einzelnen Grafikkarten GeForce RTX 2080 & GeForce RTX 2080 Ti läuft bekannterweise erst am 19. September aus. Dann wird es in jedem Fall unabhänige Benchmarks zu diesen Grafikkarten geben – und hoffentlich auch die sicherlich notwendigen Screenshot-Vergleiche zur Beurteilung der Bildqualität des normalen DLSS.