NVIDIA GF100 wird konkreter

Veröffentlicht am: von

Fermi_DieIn der aktuellen Hardwareluxx [printed] schauen wir uns die Fermi-Architektur etwas genauer an. Auf einem Termin mit NVIDIA auf der CES lies man verlauten, dass sich Fermi und GF100, also die Desktop-Version der neu erwarteten Architektur, teilweise deutlich unterscheiden würden. Nun hat NVIDIA neue Details zur GF100 bekannt gegeben. NVIDIA hatte zu diesem Zweck zu einem Deep Dive Briefing eingeladen, aufgrund der begrenzten Anzahl an Teilnehmern konnte aber nicht jede Redaktion anwesend sein. Zumindest aber hätte man mit ausreichendem Vorlauf die nötigen Informationen auch denjenigen bereitstellen können, die nicht anwesend sein konnten. Letztendlich können wir euch nun mit einiger Verspätung eine Zusammenfassung dessen präsentieren, was NVIDIA mit dem GF100 plant.

Kurz nachdem AMD seine 5800er-Serie veröffentlichte, präsentierte NVIDIA auf einer Computing-Messe erste Details zur Fermi-Architektur. Danach ist es sehr still geworden und nur einzig der Codename der Desktop-Version "GF100" wurde von NVIDIA bekannt gegeben. Natürlich sind auch wir als Hardware-Redakteure sehr gespannt, was NVIDIA für seine nächste GPU-Generation plant und so ist es auch nicht verwunderlich, dass über Wochen und Monate Spekulationen darüber durch das Internet geistern. NVIDIA selbst hat erst zur CES zur Ruhe aufgerufen. Die ersten GF100-Grafikkarten seihen erst für das 1. Quartal 2010 geplant gewesen und an diesem Zeitplan hält man auch weiterhin fest. So war auf der CES auch recht wenig zu diesem Thema zu hören, auf dem Stand von NVIDIA waren allerdings zwei Systeme mit GF100-Karten zu sehen, zum einen um 3D Vision Surround zu demonstrieren und zum anderen, um zu beweisen, dass GF100-Karten nicht nur im Labor existieren.

Zu technischen Details hält sich NVIDIA auch weiterhin bedeckt, doch immerhin will man nun zeigen, zu was die neue Architektur auf dem Desktop im Stande ist. Was noch immer unbekannt bleiben wird, sind Fakten zu DIE-Größe, welche Modelle mit GF100 ausgestattet sein werden, Taktraten, Performance, Stromverbrauch und letztendlich natürlich auch der Preis.

NVIDIA
GF100 
NVIDIA
GeForce GTX 295 
NVIDIA
GeForce GTX 285 
ATI
Radeon HD 5970 
ATI
Radeon HD 5870 
Shader-Prozessoren 512 2x 240 (1D) 240 (1D) 2x 320 (5D) 320 (5D)
ROPs 48 2x 28 32 2x 32 32
GPU-Takt - 576 MHz 648 MHz 2x 725 MHz 850 MHz
Shader-Takt - 1242 MHz 1476 MHz 725 MHz 850 MHz
Speicher-Takt - 999 MHz 1242 MHz 1000 MHz 1200 MHz
Speicherbandbreite 384 Bit 2x 448 Bit 512 Bit 2x 256 Bit 256 Bit
Speichergröße - 2x 896 MB 1 GB 2 GB 1 GB
Fertigungsgröße 40 nm 55 nm 55 nm 40 nm 40 nm
Anzahl Transistoren 3 Milliarden 2x 1,4 Milliarden 1,4 Milliarden 2x 2,15 Milliarden 2,15 Milliarden
Preis-Segment

Zusammengefasst ergibt sich Folgendes: Die GF100 besitzt 512 Shader-Prozessoren oder CUDA-Cores, wie NVIDIA sie nennt. Diese sind in Blöcken mit jeweils 32 Shader-Prozessoren in Streaming-Multiprozessoren (SM) zusammengefasst. Wiederum vier dieser Streaming-Multiprozessoren sind zu einem Graphics-Processing-Cluster (GPC) zusammengeschlossen. Bei vier Graphics Processing Clustern ergibt sich die Gesamtzahl von 512 Shader-Prozessoren (32x4x4).

GF100_08_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

Mit der GT200-GPU läutete NVIDIA das GPU-Computing-Zeitalter ein und optimierte seine Architektur in dieser Hinsicht. Der GF100 soll noch einen Schritt weiter gehen. So soll auch der letzte Teil Fixed-Function-Hardware verschwinden und die Architektur sozusagen komplett öffnen und flexibel gestalten. Zwei Fixed-Function-Units namens PolyMorph Engine und Raster Engine sind auch neu hinzu gekommen.


Doch wohin will NVIDIA mit seiner neuen Architektur?

NVIDIA hat die GF100-GPU konstruiert um folgende Ziele zu erreichen:

Um das erste Ziel zu erreichen, wurde die dritte Generation der Streaming-Multiprozessoren eingeführt und deren Anzahl verdoppelt. Ebenfalls verdoppelt hat sich die Anzahl der ROPs. Die Bildqualität will man mit 32xCSAA auf eine neue Ebene bringen. Für eine realistischere Geometrie zeichnen sich Tesselation und Displacement Mapping verantwortlich. Zu guter Letzt soll die effiziente GF100-GPU auch noch beim Computing einen deutlichen Schritt nach vorne gemacht haben.

GF100_01_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

Auf einige der erwähnten Technologien und DirectX-11-Features sind wir bereits im Rahmen des Launches der AMD-Radeon-HD-5800er-Serie genauer eingegangen. An dieser Stelle wollen wir uns aber auch den Eigenheiten der GT100-Architektur etwas genauer widmen.

 

 


Bereits nach der Vergleichstabelle behandelten wir die Anzahl der Shader-Prozessoren und andere Details in absoluten Zahlen. Nun aber soll es um die Zusammenarbeit aller Komponenten gehen. 

GF100_02_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

Grundsätzlich besteht die GF100-GPU aus vier Graphics Processing Clustern, 16 Streaming-Multiprozessoren und sechs Speichercontrollern. Zum Launch der ersten Karten werden sich diese anhand der Anzahl der Komponenten unterscheiden um die verschiedenen Preis-Segmente abdecken zu können.

Die CPU-Kommandos werden von der GPU über das Host-Interface gelesen. Die GigaFetch-Engine nimmt sich dann die notwendigen Daten aus dem Arbeitsspeicher und kopiert diese in den Grafikspeicher. Die Speicheranbindung setzt sich aus sechs 64-Bit-Speichercontrollern zusammen. Insgesamt ist das Speicherinterface somit 384-Bit breit und kann bis zu 6 GB GDDR5-Speicher anbinden. Je nach Ausbaustufen können also 1,5, 3 oder die vollen 6 GB verbaut werden. Die GigaThread-Engine erstellt und verteilt Thread-Blöcke und gibt diese an den Streaming-Multiprozessoren-Scheduler, wo alle anfallenden Operationen auf die Shader-Prozessoren  und andere Einheiten verteilt werden.

Graphics-Processing-Cluster:

Ein Graphics-Processing-Cluster besteht aus einer Raster-Engine und bis zu vier Streaming-Multiprozessoren. Die GPCs bilden den wichtigsten Block innerhalb der GF100-GPU, denn sie bilden die Basis für die wichtigsten Operationen. Das GPC arbeitet effizienter als vorangegangenen Architekturen, da es Vertex-, Geometrie-, Textur- und Pixel-Operationen vereint und gleichzeitig mit den Anforderungen skaliert.

GF100_03_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

 


PolyMorph-Engine:

Eine der zwei neue Fixed-Function-Units und auch die wichtigste ist die PolyMorph-Engine. Sie ist maßgeblich verantwortlich für Vertex-Fetch, Tessellation, Attribute-Setup, Viewport-Transform und den Stream-Output. Tesselation ist eines der wichtigsten Features in DirectX 11 und daher für die Performance und Darstellung entsprechender Inhalte besonders wichtig.

GF100_04

Jede SM-Einheit besitzt eine PolyMorph Engine, insgesamt kann die GF100 also auf 16 zurückgreifen. Sind die SM-Einheit und die PolyMorph Engine durchlaufen, wird das Ergebnis an die Raster Engine weitergeleitet. In einem zweiten Schritt beginnt dann der Tesselator mit der Berechnung der benötigten Oberflächen-Positionen, die dafür sorgen, dass je nach Abstand der nötige Detailgrad ausgewählt wird. Die korrigierten Werte werden wiederum an die SM-Einheit gesendet, wo der Domain-Shader und der Geometrie-Shader diese dann weiter ausführen. Der Domain-Shader berechnet die finale Position jedes Dreiecks indem er die Daten des Hull-Shaders und des Tesselators zusammensetzt. An diese Stelle wird dann auch das Displacement-Mapping durchgeführt. Der Geometrie-Shader vergleicht die errechneten Daten dann mit den letztendlich wirklich sichtbaren und sendet die Ergebnisse wieder an die Tesselation-Engine, für einen finalen Durchlauf.

GF100_07_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

Im letzten Schritt dann führt die PolyMorph-Engine die Viewport-Transformation und eine perspektivische Korrektur aus. Letztendlich werden die berechneten Daten über den Stream-Output ausgegeben, indem der Speicher diese für weitere Berechnungen freigibt. Während diese Schritte als Fixed-Function-Operationen bisher in einer Pipeline verarbeitet wurden, können sie auf der GF100 parallel berechnet werden, was die Geschwindigkeit der Berechnung deutlich erhöhen soll.

GF100_06

Raster-Engine:

Vier parallele Raster-Engines sorgen auf der GF100-GPU nach der PolyMorph-Engine für eine möglichst detailreiche Darstellung der errechneten Werte. Dazu ist die Raster-Engine in drei Stufen aufgeteilt.

GF100_05

Im Edge-Setup werden nicht sichtbare Dreiecke bestimmt und durch ein "Back Face Culling" entfernt. Jedes Edge-Setup kann pro Takt einen Punkt, eine Linie oder ein Dreieck pro Takt berechnen.

Der Rasterizer zeichnet sich für die Bestimmung der durch Antialiasing berechneten Werte verantwortlich. Jeder Rasterizer kann pro Takt acht Pixel berechnen, insgesamt ist die GF100-GPU also in der Lage 32 Pixel pro Takt zu berechnen.

Zum Abschluss vergleicht die Z-Cull-Unit die gerade errechneten Pixel mit bereits im Framebuffer existierenden. Liegen die gerade berechneten Pixel geometrisch hinter denen die sich bereits im Framebuffer befinden, werden sie verworfen.


Special-Function-Units:

Sogenannte Special-Function-Units (SFUs) übernehmen Berechnungen, die keiner Multiplikation oder Addition entsprechen. Vier dieser SFUs stehen in der GF100-GPU zur Verfügung. Jede SFU kann pro Takt und Thread eine Berechnung durchführen. Größere Befehle können über bis zu acht Takte ausgedehnt werden. Damit die Dispatch-Unit in dieser Zeit nicht auf die SFUs warten muss und weiterhin die übrigen Shader-Prozessoren versorgen kann, arbeiten die SFU-Pipelines getrennt von dieser.

16 Load/Store-Units:

Zu den SMs und SFUs gesellen sich noch Load/Store-Units. Jeder Streaming-Multiprozessor verfügt über 16 Load/Store Units, die für 16 Threads pro Takt die Quell- und Ziel-Adressierung im Speicher und Cache berechnen.

Dual-Warp-Scheduler:

Die Streaming-Multiprozessoren des GF100 verfügen über jeweils zwei Warp-Scheduler und Instruction-Dispatch-Units. Ein Warp ist eine Zusammenstellung von 32 parallelen Threads, die sich die gleiche Pipeline innerhalb der SIMT-Architektur (Single-Instruction, Multiple-Thread) teilen. Der Warp-Scheduler wählt sich zwei Warps und verteilt die zu berechnenden Funktionen auf bis zu 16 Shader-Prozessoren, 16 Load/Store-Units oder die vier SFUs.

GF100_09_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

Texture-Units:

Jede SM-Einheit verfügt über vier Texture-Units. Jede Texture-Unit berechnet Texture-Adressierungen und kann bis zu vier Texturen pro Takt verarbeiten. Das Ergebnis kann dann entweder gefiltert oder ungefiltert zurückgegeben werden. Bekannt sind hier die Filter-Modi Bilinear, Trilinear und das anisotropische Filtern. Soweit entspricht das Vorgehen aber noch dem  aus der bekannten GT200-Architektur. NVIDIA hat die Texture-Unit allerdings in die SM-Einheiten verpflanzt, um dort die Effizienz durch die Verwendung des Texture-Caches und den höheren Taktraten zu verbessern. Bei der GT200-Architektur mussten sich drei SM-Einheiten eine Texture-Einheit teilen. Nun verfügt jede SM-Einheit über ihre eigene Texture-Unit und auch über dedizierten L1-Texture-Cache. Zudem arbeiten sie nicht mehr auf den Taktraten der GPU, sondern auf denen der Shader-Prozessoren.

GF100_11_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

Neben dem dedizierten L1-Texture-Cache, sorgt auch der L2-Cache für eine bessere Performance, denn damit ist der Gesamtspeicher dreimal größer als bei der GT200-Architektur. Zusätzlich unterstützt die GF100-GPU auch noch die BC6H- und die BC7-Texture-Kompression aus der DirectX-11-Spezifikation. Ebenfalls in DirectX-11 vorgesehen ist ein Feature namens Jittered-Sampling durch "Four-Offset-Gather4". Hierbei können aus einem 128x128-Pixel-Feld vier Texel pro Instruction entnommen werden, was die Berechnung von Soft-Shadows, Ambient-Acclusion und dem weiteren Post-Processing erleichtert.

GF100_10

 


64kB shared-Memory und L1-Cache:

In der GF100-GPU stehen 64 kB shared-Memory pro Streaming-Multiprozessor zur Verfügung. 48 kB sind dabei frei konfigurierbar, 16 kB werden dann als L1-Cache verwendet. Es besteht aber ebenfalls die Möglichkeit 16 kB shared-Memory zu verwenden, dann sind 48 kB L1-Cache verfügbar.

GF100_12

Ein shared-Memory sorgt dafür, dass Daten, die von mehreren Threads verwendet werden, nicht mehr vom Speicher in die GPU und zurückgeschrieben werden müssen, sondern sozusagen auf der GPU verbleiben können. Dadurch können Berechnungen deutlich schneller ausgeführt werden.

L2-Cache:

Für den schnellen Datenaustausch innerhalb der GPU ebenfalls wichtig ist der L2-Cache. Dieser ist bei der GF100-GPU 768 kB groß. Er vereint Speicher-Systeme aus früheren Architekturen. So ersetzt er den L2-Texture-Cache, ROP-Cache und die On-Chip-FIFOs. Zudem ist er der zentrale Anlaufpunkt für alle Algorithmen, die auf Daten zurückgreifen müssen, die zu Beginn ihrer Berechnungen noch gar nicht vorlagen. Beispiele sind hier Physik-Berechnungen und Ray-Tracing. Zudem war es in früheren Architekturen üblich bestimmte Schreib- und Lesepfade einzupflegen. So gab es einen write-only ROP-Pfad oder aber einen read-only Texture-Pfad. Der L2-Cache besitzt so genannte "unified read/write" Pfade und ist damit deutlich flexibler, da gewisse Lese- oder Schreibzugriffe nicht mehr so oft blockiert sein können.

GF100_13_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

 


ROP-Units:

Die ROP-Units der GF100-GPU wurden entscheidend überarbeitet, um sowohl den Durchsatz als auch die Effizienz zu steigern. In der GF100-GPU sind acht ROP-Units zu einer ROP-Partition zusammengefasst. Jede ROP-Unit kann einen 32 Bit Integer-Pixel pro Takt ausgeben. Ebenfalls möglich ist ein FP16-Pixel über zwei Takte oder ein FP32-Pixel über vier Takte.

Die zusätzlichen ROP-Units sowie die verbesserte Kompression sollen die 8xMSAA-Performance des GF100 deutlich verbessert haben. Gleichzeitig ist man aber auch in der Lage deutlich genauer zu arbeiten, sodass man in beiden Bereichen, sowohl in der Qualität als auch in der Performance einen großen Sprung nach vorne gemacht haben will.

GF100_14

Neu hinzugekommen ist ein 32x Coverage-Sampling-Antialiasing (CSAA), das die derzeit beste darstellbare Bildqualität zutage fördern soll. Auch wenn die APIs vieler Engines derzeit Einschränkungen bei der maximalen Qualität machen, will NVIDIA mithilfe von "Alpha-to-Coverage" hier weiter für Verbesserungen sorgen. Dabei wird die Texture in noch kleinere Blöcke unterteilt, die dann durch die GPU neu berechnet werden. Schränkt die Engine die Texture also auf vier oder acht Samples ein, kann es besonders bei Texturen die sehr nah dargestellt werden, zu unschönen Effekten, wie einer Streifenbildung kommen. Mit 32x CSAA macht die GPU insgesamt 32 Texture-Samples verfügbar und mindert diesen Effekt deutlich ab.

GF100_15_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

Auch das Transparency-Multisampling (TMAA) profitiert vom Coverage-Sampling-Antialiasing. Betroffen sind hier DirectX-9-Spiele, die noch kein Alpha-to-Coverage ausführen können, da dies nicht in der API vorgesehen ist. Dort muss noch ein Alpha-Test durchgeführt werden, der bei transparenten Texturen allerdings zu unschönen Effekten führt. TMAA konvertiert den Shader-Code der DirectX-9-Engine und wendet darauf Alpha-to-Coverage an, was zusammen mit CSAA die Bildqualität dann deutlich verbessert.


Ray-Tracing:

NVIDIA sieht die Zukunft der Computer-Grafik im Ray-Tracing. Bisher war aber keine GPU in der Lage aufwendige Ray-Tracing-Szenen in Echtzeit darzustellen. Dies soll sich mit der GF100-GPU nun aber ändern. Die Herausforderungen dabei sind vor allem die Tatsache, dass Rays kaum vorhersehbare Richtungen einnehmen und zudem eine Menge an zufälligen Speicherzugriffen nach sich ziehen. GPUs sind bisher allerdings auf lineare Zugriffe im Speicher ausgelegt.

GF100_17_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

Der schon behandelte L1- und L2-Cache sind bei der GF100-GPU als maßgeblich für die verbesserte Ray-Tracing-Performance verantwortlich. Doch NVIDIA geht noch einen Schritt weiter und spricht bereits von Path-Tracing. Im Path-Tracing sind eine große Anzahl an Rays vonnöten, um Informationen zur Beleuchtung der darzustellenden Szene zu sammeln. Laut eigenen Angaben arbeitet Path-Tracing bis zu vier mal schneller auf der GF100-GPU als auf der GT200. Für die ideale Performance sieht NVIDIA aber derzeit eher einen Hybrid-Modus als realisierbar. So könnte das normale Ray-Tracing die Szene in ihrer Grundstruktur berechnen. Dann werden die Pixel identifiziert, die für Reflexionen sorgen. Diese können dann mit Path-Tracing weiter berechnet werden.

GF100_16

 


Smoothed Particle Hydrodynamics:

Noch immer eine Herausforderung für jede Engine ist die Darstellung von Flüssigkeiten. Auch in Filmen wird diese Anwendung immer öfter verwendet und stellt selbst heute bei Filmen wie 2012 noch eine große Herausforderung dar. 2003 wurde ein Algorithmus namens Smoothed Particle Hydrodynamics (SPH) entwickelt, der die interaktive Darstellung von Flüssigkeiten ermöglicht. Damals wurde eine Demo präsentiert, die aus 5.000 Partikeln bestand, die mit fünf Bildern pro Sekunde berechnet wurde. NVIDIA implementierte den Algorithmus in die PysX-API und so fand er auch in Cryostasis Verwendung. Dort konnten dann schon 30.000 Pixel bei 30 Bildern pro Sekunde dargestellt werden.

GF100_21_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

Auf der GF100-GPU sollen nun 128.000 SPH-Partikel pro Frame berechnet werden können. So ist es nun möglich nicht nur eine kleine Menge "Flüssigkeit" , sondern gleich eine komplette Szene mit Regentropfen, Pfützen und abfließenden Wassers darzustellen. Durch Veränderung der Parameter ist dann auch die Darstellung von flüssigen Metallen oder Blut möglich. Da sich alle Flüssigkeiten grundsätzlich gleich verhalten, sind zahlreiche Einsatzgebiete vorstellbar. Da der SPH-Algorithmus den shared-Memory nicht verwendet, kann auch keine Saturierung der Speicherbandbreite stattfinden, eine große Gefahr bei der Berechnung derart vieler Einzelkomponenten.

GF100_18_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

 


3D Vision Surround:

Bereits auf der CES stellte NVIDIA 3D Vision Surround vor. Dabei handelt es sich um eine Weiterentwicklung von 3D Vision um die Option, das Bild auf mehreren Monitoren darzustellen. Wie ebenfalls bereits auf der CES näher ergründet, ist dies in einer SLI-Konfiguration von zwei oder mehr GF100-Karten möglich. Bis zu 746 Millionen Pixel können so maximal dargestellt werden, was selbstverständlich nach einer potenten Grafikkarten verlangt, die NVIDIA mit der GF100 gefunden haben will.

GF100_19_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

GF100_20_rs

Durch Klick auf das Bild gelangt man zu einer vergrößerten Ansicht

 


Zum Abschluss:

Sowohl für uns als Redakteure, als auch für die Kunden dürfte die derzeitige Situation bei NVIDIA unbefriedigend sein. AMD ist sei sechs Monaten mit der DirectX-11-Hardware am Markt und dominiert diesen eindeutig. Dass NVIDIA immer wieder davon spricht, die GF100-Karten seien schon immer für das 1. Quartal 2010 geplant gewesen, kann nicht darüber hinwegtäuschen, dass das Warten inzwischen recht schmerzhaft wird, zumal NVIDIA immer wieder selbst mit Pseudo-Informationen auf sich aufmerksam macht. Dass sich die Präsentation der Fermi-Architektur hauptsächlich auf die Tesla-Karten bezogen haben soll, mag zwar NVIDIAs Anspruch gewesen sein, die Wirklichkeit aber zeigte sich heute ein anderes Bild. Die wesentlichen Architektur-Komponenten der GF100-GPU und der Tesla-Karten sind identisch. Unterschiede sind natürlich im Bereich der ECC-Speicherunterstützung oder später vielleicht im maximalen Speicherausbau zu finden.

Auch wenn NVIDIA heute einige Details zur GF100 zutage gebracht hat, sind essentielle Fakten noch immer nicht in Sichtweite. So können wir weder von Taktraten berichten, noch von Werten zum Stromverbrauch. Selbst mit hauseigenen Benchmarks hält sich NVIDIA noch zurück.

Wir sind gespannt wann NVIDIA nun endgültig mit den ersten Karten an den Markt geht. Die CeBIT könnte sich als eine Plattform für einen Launch bestens eignen, doch auch hier sind genaue Informationen weiterhin nicht zu erhalten.

Weitere Links: