DE102019102009A1

DE102019102009A1 - Reduzierung des rauschens während des renderings durch parallele path-space-filterung unter verwendung von hashing

Info

Publication number: DE102019102009A1
Application number: DE102019102009.3A
Authority: DE
Inventors: Sascha Fricke; Nikolaus Binder; Alexander Keller
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2017-07-28
Filing date: 2019-01-28
Publication date: 2020-01-30
Also published as: CN110766778A; US20190035140A1; US10614613B2; CN110766778B

Abstract

Ein Verfahren, ein computerlesbares Medium und ein System werden offenbart, um das Rauschen während des Renderns einer Szene zu reduzieren, indem Informationen, die räumlich nahe beieinander liegen, durch Path-Space-Filterung gemeinsam genutzt werden. Ein Vertex eines Lichttransportpfades wird ausgewählt, und ein oder mehrere Merkmale des ausgewählten Vertex werden quantisiert. Ein erster Hashwert wird basierend auf einem oder mehreren quantisierten Merkmalen des ausgewählten Vertex berechnet, und eine Kollisionsauflösung wird innerhalb einer Hash-Tabelle durchgeführt. Ein Beitrag des Lichttransportpfades an dem ausgewählten Vertex wird in der Hash-Tabelle akkumuliert, und ein Zähler wird inkrementiert, wenn der Beitrag des Lichttransportpfades an dem ausgewählten Vertex zur Hash-Tabelle hinzugefügt wird. Anschließend wird unter Verwendung des Zählers ein durchschnittlicher Beitrag des Lichttransportpfades berechnet.

Description

BEREICH DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf Raytracing und insbesondere auf die Durchführung von Path-Space-Filtern (Pfadraumfiltern) unter Verwendung von Hashing.
HINTERGRUND
Die Beschränkung des Path Tracing (der Pfadverfolgung) auf eine geringe Anzahl von Pfaden pro Pixel aus Performance-Gründen erreicht in den seltensten Fällen eine zufriedenstellende Bildqualität für interessante Szenen. Die Path-Space-Filterung kann jedoch die visuelle Qualität drastisch verbessern, indem Informationen über Vertices von Pfaden, die als nahe gelegen eingestuft werden, gemeinsam benutzt werden. Die derzeitigen Techniken zur Suche nach benachbarten Vertices, um die Path-Space-Filterung zu implementieren, sind jedoch zeitaufwändig und ressourcenintensiv. Es besteht daher die Notwendigkeit, diese Fragen und/oder andere Fragen im Zusammenhang mit dem Stand der Technik zu behandeln.
ZUSAMMENFASSUNG
Ein Verfahren, ein computerlesbares Medium und ein System werden offenbart, um das Rauschen während des Renderns einer Szene zu reduzieren, indem durch die Path-Space-Filterung Informationen gemeinsam genutzt werden, die räumlich nahe beieinander liegen. Ein Vertex eines Lichttransportpfads wird ausgewählt, und ein oder mehrere Merkmale des ausgewählten Vertex werden quantisiert. Ein erster Hashwert wird basierend auf einem oder mehreren quantisierten Merkmalen des ausgewählten Vertex berechnet, und eine Kollisionsauflösung wird innerhalb einer Hash-Tabelle durchgeführt. Ein Beitrag des Lichttransportpfads bei dem ausgewählten Vertex wird in der Hash-Tabelle akkumuliert, und ein Zähler wird inkrementiert, wenn der Beitrag des Lichttransportpfads an dem ausgewählten Vertex zur Hash-Tabelle hinzugefügt wird. Anschließend wird unter Verwendung des Zählers ein durchschnittlicher Beitrag des Lichttransportpfads berechnet.
Figurenliste

1 stellt ein Flussdiagramm eines Verfahrens zum Durchführen einer parallelen Path-Space-Filterung durch Hashing gemäß einer Ausführungsform dar.
2 stellt eine Parallelverarbeitungseinheit gemäß einer Ausführungsform dar.
3A stellt ein allgemeines Verarbeitungscluster innerhalb der Parallelverarbeitungseinheit von 2 gemäß einer Ausführungsform dar.
3B stellt eine Speicherpartitionseinheit der Parallelverarbeitungseinheit von 2 gemäß einer Ausführungsform dar.
4A stellt den Streaming-Multiprozessor von 3A gemäß einer Ausführungsform dar.
4B ist ein konzeptionelles Diagramm eines Verarbeitungssystems, das unter Verwendung der PPU von 2 gemäß einer Ausführungsform implementiert wurde.
4C veranschaulicht ein exemplarisches System, in dem die unterschiedlichen Architekturen und/oder Funktionalitäten der verschiedenen vorherigen Ausführungsformen implementiert werden können.
5 ist ein konzeptionelles Diagramm einer Grafikverarbeitungspipeline, die von der PPU von 2 gemäß einer Ausführungsform implementiert wurde.
6A stellt einen ersten Schritt zur Durchführung einer parallelen Path-Space-Filterung durch Hashing gemäß einer Ausführungsform dar.
6B stellt einen zweiten Schritt zur Durchführung einer parallelen Path-Space-Filterung durch Hashing, bei dem die einem Jittering unterzogenen Vertices dargestellt sind, gemäß einer Ausführungsform dar.
6C stellt einen dritten Schritt zur Durchführung einer parallelen Path-Space-Filterung durch Hashing gemäß einer Ausführungsform dar, bei dem alle Beiträge, deren Hashwert mit dem Hashwert des interessierenden Vertex identisch sind, gemittelt werden.
7 stellt die Ergebnisse der Akkumulation der Beiträge aller Lichttransportpfade mit identischen Hashwerten gemäß einer Ausführungsform dar.
8 stellt gemäß einer Ausführungsform die Verwendung von linearem Suchen dar, um Attribute eines Lichttransportpfads auf einem feineren Detaillierungsgrad zu unterscheiden.
9 stellt gemäß einer Ausführungsform dar, dass der Detaillierungsgrad einer mittels Jittering erzeugten Position von dem Detaillierungsgrad einer ursprünglichen Position abweichen kann.

DETAILLIERTE BESCHREIBUNG
1 stellt ein Flussdiagramm eines Verfahrens 100 zum Durchführen einer parallelen Path-Space-Filterung durch Hashing gemäß einer Ausführungsform dar. Obwohl das Verfahren 100 im Zusammenhang mit einer Verarbeitungseinheit beschrieben wird, kann das Verfahren 100 auch durch ein Programm, eine benutzerdefinierte Schaltung oder durch eine Kombination aus einer benutzerdefinierten Schaltung und einem Programm durchgeführt werden. So kann beispielsweise das Verfahren 100 von einer GPU (Grafikprozessoreinheit), einer CPU (Zentraleinheit) oder einem beliebigen Prozessor ausgeführt werden, der in der Lage ist, durch Hashing eine parallele Path-Space-Filterung durchzuführen. Darüber hinaus versteht der Fachmann, dass jedes System, das das Verfahren 100 durchführt, im Rahmen und Geist der Ausführungsformen der vorliegenden Erfindung liegt.
Wie es in Schritt 102 dargestellt ist, wird ein Vertex eines Lichttransportwegs bzw. Lichttransportpfads ausgewählt. In einer Ausführungsform kann der Lichttransportpfad durch einen Path Tracer erzeugt werden. In einer weiteren Ausführungsform kann der Lichttransportpfad einer von mehreren Lichttransportpfaden sein. In noch einer weiteren Ausführungsform kann sich der Vertex an einem Schnittpunkt zwischen dem Lichttransportpfad und einem Objekt (z.B. einer geometrischen Instanz usw.) innerhalb einer Szene befinden.
Zusätzlich kann der Vertex in einer Ausführungsform einer von mehreren Vertices für den Lichttransportpfad innerhalb der Szene sein. In einer weiteren Ausführungsform kann der Lichttransportpfad an einer Stelle von Auge/Kamera beginnen und an einer Lichtquelle enden.
Weiterhin werden, wie es in Schritt 104 dargestellt ist, ein oder mehrere Merkmale des ausgewählten Vertex quantisiert. So können beispielsweise die Worldspace-Koordinaten des ausgewählten Vertex skaliert und ihre gebrochenen Anteile weggelassen werden. In einer Ausführungsform können das eine oder die mehreren Merkmale eine Position des ausgewählten Vertex innerhalb der Szene beinhalten. So kann beispielsweise das eine oder die mehreren Merkmale eine Worldspace-Position des ausgewählten Vertex beinhalten. In einer weiteren Ausführungsform kann das Erstellen eines Schlüssels für den ausgewählten Vertex das Quantisieren eines oder mehrerer Merkmale des ausgewählten Vertex beinhalten.
Weiterhin wird, wie es in Schritt 106 dargestellt ist, ein erster Hashwert basierend auf einem oder mehreren quantisierten Merkmalen des ausgewählten Vertex berechnet. In einer Ausführungsform kann das Berechnen des ersten Hashwerts auch das Anwenden einer Hash-Funktion auf den für den ausgewählten Vertex konstruierten Schlüssel beinhalten. In einer weiteren Ausführungsform können die Ergebnisse des ersten Hashwerts eine Position in einer Hash-Tabelle (z.B. einen Hash-Tabellenindex) beinhalten.
Darüber hinaus wird, wie es in Schritt 108 dargestellt ist, die Kollisionsauflösung innerhalb der Hash-Tabelle durchgeführt. Auf diese Weise kann eine Akkumulierung von Beiträgen von Vertices mit unterschiedlichen quantisierten Merkmalen vermieden werden.
Außerdem wird, wie es in Schritt 110 dargestellt ist, ein Beitrag des Lichttransportpfads am ausgewählten Vertex in einer Hash-Tabelle akkumuliert. In einer Ausführungsform kann der Beitrag einen Farbwert beinhalten, der von einer Lichtquelle auf den Vertex übertragen wird. In einer weiteren Ausführungsform kann der Beitrag zu einer Position in der Hash-Tabelle hinzugefügt werden, die mit dem ersten Hashwert berechnet wurde.
Darüber hinaus wird, wie es in Schritt 112 dargestellt ist, ein Zähler inkrementiert, wenn der Beitrag des Lichttransportpfads an dem ausgewählten Vertex zur Hash-Tabelle hinzugefügt wird. In einer Ausführungsform kann der Zähler einen AtomicCounter beinhalten. Weiterhin wird in einem sechsten Schritt unter Verwendung des Zählers, wie es in Schritt 114 dargestellt ist, ein durchschnittlicher Beitrag des Lichttransportpfads berechnet. In einer Ausführungsform kann die Berechnung des Durchschnittsbeitrags das Akkumulieren der Beiträge aller Lichttransportpfade mit dem ersten Hashwert beinhalten. In einer weiteren Ausführungsform kann die Berechnung des durchschnittlichen Beitrags auch die Skalierung der akkumulierten Beiträge beinhalten. So kann beispielsweise die Skalierung der akkumulierten Beiträge die Division der akkumulierten Beiträge durch einen Wert des Zählers beinhalten.
Darüber hinaus kann der ausgewählte Vertex in einer Ausführungsform einem Jittering unterzogen werden, bevor ein oder mehrere Merkmale des ausgewählten Vertex quantisiert werden. Das Jittering kann beispielsweise entsprechend einer ausgewählten Verteilung durchgeführt werden. In einem weiteren Beispiel kann das Jittering in einer Tangentialebene einer Oberfläche durchgeführt werden, auf der sich der Vertex befindet. In einem weiteren Beispiel kann der ausgewählte Vertex mit einer Vielzahl von weiteren Vertices in einem Volumen gespeichert werden, und die im Volumen gespeicherten Vertices können einem Jittering unterzogen werden.
Darüber hinaus kann in einer Ausführungsform die Quantisierung des einen oder der mehreren Merkmale des ausgewählten Vertex einheitlich bzw. gleich durchgeführt werden. In einer weiteren Ausführungsform kann die Quantisierung des einen oder der mehreren Merkmale des ausgewählten Vertex abhängig von der Entfernung des ausgewählten Vertex von der Kamera durchgeführt werden. In noch einer weiteren Ausführungsform kann die Quantisierung des einen oder der mehreren Merkmale des ausgewählten Vertex abhängig von der Länge eines Pfadsegments (z.B. eines Pfades von der Lichtquelle oder von der Kamera/Auge, etc.) durchgeführt werden. In noch einer weiteren Ausführungsform kann das Quantisieren des einen oder der mehreren Merkmale des ausgewählten Vertex abhängig von einer Heuristik durchgeführt werden, die auf einer Verteilung und einer lokalen Dichte einer Vielzahl von Vertices basiert.
Darüber hinaus kann das Durchführen einer Kollisionsauflösung innerhalb der Hash-Tabelle in einer Ausführungsform das Erkennen einer oder mehrerer Kollisionen durch Vergleichen der einen oder mehreren quantisierten Merkmale des ausgewählten Vertex mit einem oder mehreren quantisierten Merkmalen weiterer Vertices beinhalten. In einer weiteren Ausführungsform kann das Durchführen der Kollisionsauflösung innerhalb der Hash-Tabelle das Erfassen einer oder mehrerer Kollisionen durch Quantisieren eines zweiten Satzes von Merkmalen des ausgewählten Vertex, das Berechnen eines zweiten Hashwerts basierend auf dem zweiten Satz von quantisierten Merkmalen und das Vergleichen des zweiten Hashwerts des ausgewählten Vertex mit einem oder mehreren zweiten Hashwerten von weiteren Vertices beinhalten.
Weiterhin können in einer Ausführungsform ein oder mehrere akkumulierte Beiträge und Null oder mehrere Zähler für Vertices von Pfaden innerhalb einer Szene während einer Simulation nachgeschlagen werden. In einer weiteren Ausführungsform kann die Quantisierung des einen oder der mehreren Merkmale des ausgewählten Vertex lokal bestimmt werden. So kann beispielsweise eine lokale Quantisierungsauflösung bestimmt werden, indem die gegenseitige Sichtbarkeit ausgewählter Vertices verschiedener Lichttransportpfade innerhalb einer Szene überprüft wird.
Weiterhin können in einer Ausführungsform ein oder mehrere Merkmale des ausgewählten Vertex bei der Berechnung des ersten Hashwerts ausgeschlossen werden. In einer weiteren Ausführungsform können die ausgeschlossenen Merkmale in eine Berechnung eines zweiten Hashwerts einbezogen werden. In noch einer weiteren Ausführungsform kann eine zusätzliche Suche durch die Kollisionsauflösung ermöglicht werden.
Darüber hinaus kann in einer Ausführungsform ein exponentieller gleitender Durchschnitt implementiert werden, um Beiträge für den Lichttransportpfad über der Zeit zu akkumulieren. So kann beispielsweise eine Summe von Beiträgen aller Lichttransportpfade mit dem ersten Hashwert sowie der Zähler über eine bestimmte Zeitperiode gehalten und mit einem durchschnittlichen Beitrag der Lichttransportpfade für einen aktuellen Zeitraum kombiniert werden.
Darüber hinaus kann in einer Ausführungsform ein vorgegebener Parameter eines exponentiellen gleitenden Durchschnitts eingestellt werden, so dass der exponentielle gleitende Durchschnitt zu einem kumulativen gleitenden Durchschnitt wird. In einer weiteren Ausführungsform kann der vorgegebene Parameter basierend auf den Ergebnissen einer Path-Tracing-Simulation ausgewählt werden. In noch einer weiteren Ausführungsform kann der vorgegebene Parameter basierend auf einer Auswertung weiterer Lichttransportpfade ausgewählt werden. In noch einer weiteren Ausführungsform kann der exponentielle gleitende Mittelwert basierend auf Informationen aus der Path-Tracing-Simulation gesteuert werden.
Darüber hinaus kann in einer Ausführungsform ein zusätzliches Filter verwendet werden, um Rauschen durch Jittering zu filtern. So kann beispielsweise das zusätzliche Filter in einer zeitlichen Domäne arbeiten. In einem weiteren Beispiel kann das zusätzliche Filter einen exponentiellen gleitenden Durchschnitt verwenden. In noch einem weiteren Beispiel kann ein Parameter des exponentiellen gleitenden Durchschnitts so eingestellt werden, dass der exponentielle gleitende Durchschnitt zu einem kumulativen gleitenden Durchschnittswert wird. In noch einer weiteren Ausführungsform kann der exponentielle gleitende Mittelwert basierend auf Informationen aus der Path-Tracing-Simulation gesteuert werden.
Weiterhin kann der Vertex in einer Ausführungsform von einem Pfad einer Lichtquelle ausgewählt werden. Zusätzlich können ein oder mehrere zusätzliche Vertices von einem Pfad von einer Augen-/Kamera-Position ausgewählt werden. Darüber hinaus kann die Skalierung durch eine entsprechende Flächenmessung im Rahmen einer Photon-Mapping-Operation durchgeführt werden.
Auf diese Weise können benachbarte Vertices durch Quantisierungsdeskriptoren für Lichttransportpfadvertices in Cluster aufgeteilt werden. Zusätzlich können Beiträge von Vertices durch Hashing quantisierter Deskriptoren in einer Hash-Tabelle akkumuliert werden. Weiterhin kann die Hash-Tabelle verwendet werden, um Path-Space-Filterungen durchzuführen (anstatt eine allgemeine Suche nach benachbarten Vertices durchzuführen). Weiterhin können Diskretisierungsartefakte, die sich aus der Quantisierung der Deskriptoren ergeben, durch Jittering von Vertices aufgelöst werden. Außerdem können die Hash-Tabelle und die akkumulierten Beiträge verwendet werden, um ein Photon-Mapping durchzuführen.
Es werden nun weitere veranschaulichende Informationen zu verschiedenen optionalen Architekturen und Funktionen gegeben, mit denen das vorgenannte Framework nach den Wünschen des Benutzers implementiert werden kann. Es sei ausdrücklich darauf hingewiesen, dass die folgenden Informationen zur Veranschaulichung aufgeführt sind und nicht als einschränkend ausgelegt werden sollten. Jedes der folgenden Merkmale kann optional mit oder ohne andere beschriebene Merkmale aufgenommen werden.
Parallele Verarbeitungsarchitektur
2 stellt eine Parallelverarbeitungseinheit (PPU) 200 gemäß einer Ausführungsform dar. In einer Ausführungsform ist die PPU 200 ein Multithread-Prozessor, der auf einer oder mehreren integrierten Schaltungsvorrichtungen implementiert ist. In einer Ausführungsform kann die PPU 200 oder Teile davon auf rekonfigurierbaren Logikbauteilen implementiert werden. Die PPU 200 ist eine latenzverbergende Architektur, die entwickelt wurde, um viele Threads parallel zu verarbeiten. Ein Thread (d.h. ein Thread der Ausführung) ist eine Instanziierung einer Reihe von Anweisungen, die für die Ausführung durch die PPU 200 konfiguriert sind. In einer Ausführungsform ist die PPU 200 eine Grafikverarbeitungseinheit (GPU), die konfiguriert ist, um eine Grafik-Rendering-Pipeline zum Verarbeiten von dreidimensionalen (3D) Bilddaten zu implementieren, um zweidimensionale (2D) Bilddaten zur Anzeige auf einer Anzeigevorrichtung, wie beispielsweise einer Flüssigkristallanzeigevorrichtung (LCD), zu erzeugen. In anderen Ausführungsformen kann die PPU 200 zur Durchführung von Universalberechnungen verwendet werden. Obwohl hierin ein exemplarischer Parallelprozessor zu veranschaulichenden Zwecken vorgesehen ist, ist dringend darauf hinzuweisen, dass dieser Prozessor nur zu veranschaulichenden Zwecken vorgesehen ist und dass jeder Prozessor als Ergänzung und/oder Ersatz für diesen eingesetzt werden kann.
Eine oder mehrere PPUs 200 können konfiguriert werden, um Tausende von High Performance Computing- (HPC-) Anwendungen, Rechenzentrums-Anwendungen und Anwendungen zum maschinellen Lernen zu beschleunigen. Die PPU 200 kann konfiguriert werden, um zahlreiche Systeme und Anwendungen für das Deep Learning zu beschleunigen, darunter autonome Fahrzeugplattformen, Deep Learning, hochpräzise Sprach-, Bild- und Texterkennungssysteme, intelligente Videoanalytik, molekulare Simulationen, Medikamentenentdeckung, Krankheitsdiagnose, Wettervorhersage, Big Data Analytik, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotik, Fabrikautomatisierung, Echtzeit-Sprachübersetzung, Online-Suchoptimierung und personalisierte Benutzerempfehlungen und dergleichen.
Wie in 2 dargestellt ist, beinhaltet die PPU 200 eine Input/Output (I/O)-Einheit 205, eine Frontend-Einheit 215, eine Schedulereinheit 220, eine Arbeitsverteilungseinheit 225, einen Netzwerkknoten 230, ein Koppelfeld (Xbar) 270, einen oder mehrere General Processing Cluster (GPCs) 250 und eine oder mehrere Partitionseinheiten 280. Die PPU 200 kann über eine oder mehrere Hochgeschwindigkeits-NVLink 210-Verbindungen mit einem Host-Prozessor oder anderen PPUs 200 verbunden werden. Die PPU 200 kann über eine Verbindung 202 mit einem Host-Prozessor oder anderen Peripheriegeräten verbunden werden. Die PPU 200 kann auch mit einem lokalen Speicher verbunden werden, der eine Anzahl von Speichervorrichtungen 204 umfasst. In einer Ausführungsform kann der lokale Speicher eine Anzahl von dynamischen DRAM-Vorrichtungen (Dynamic Random Access Memory) umfassen. Die DRAM-Vorrichtungen können als HBM-Subsystem (High-Bandwidth Memory) konfiguriert werden, wobei mehrere DRAM-Dies in jeder Vorrichtung gestapelt sind.
Die NVLink-210 Verbindung ermöglicht es Systemen, eine oder mehrere PPUs 200 in Kombination mit einer oder mehreren CPUs zu skalieren und zu integrieren, unterstützt die Cache-Kohärenz zwischen den PPUs 200 und CPUs und das CPU-Mastering. Daten und/oder Befehle können vom NVLink 210 über den Netzwerkknoten 230 zu/von anderen Einheiten der PPU 200 übertragen werden, wie z.B. einer oder mehreren Kopiermaschinen, einem Video-Encoder, einem Videodecoder, einer Power-Management-Einheit usw. (nicht explizit dargestellt). Der NVLink 210 wird in Verbindung mit 4B näher beschrieben.
Die I/O-Einheit 205 ist konfiguriert, um Kommunikation (d.h. Befehle, Daten usw.) von einem Host-Prozessor (nicht dargestellt) über die Verbindung 202 zu senden und zu empfangen. Die I/O-Einheit 205 kann mit dem Host-Prozessor direkt über die Verbindung 202 oder über eine oder mehrere Zwischenvorrichtungen, wie beispielsweise eine Speicherbrücke, kommunizieren. In einer Ausführungsform kann die I/O-Einheit 205 mit einem oder mehreren anderen Prozessoren kommunizieren, wie beispielsweise einer oder mehreren der PPUs 200 über die Verbindung 202. In einer Ausführungsform implementiert die I/O-Einheit 205 eine Peripheral Component Interconnect Express (PCIe)-Schnittstelle für die Kommunikation über einen PCIe-Bus und die Verbindung 202 ist ein PCIe-Bus. In alternativen Ausführungsformen kann die I/O-Einheit 205 andere Arten von bekannten Schnittstellen zur Kommunikation mit externen Geräten implementieren.
Die I/O-Einheit 205 dekodiert Pakete, die über die Verbindung 202 empfangen werden. In einer Ausführungsform stellen die Pakete Befehle dar, die konfiguriert sind, um die PPU 200 zu veranlassen, verschiedene Operationen durchzuführen. Die I/O-Einheit 205 überträgt die dekodierten Befehle an verschiedene andere Einheiten der PPU 200, wie in den Befehlen angegeben. So können beispielsweise einige Befehle an die Frontend-Einheit 215 übertragen werden. Andere Befehle können an den Netzwerkknoten 230 oder andere Einheiten der PPU 200 übertragen werden, wie z.B. eine oder mehrere Kopiermaschinen, einen Video-Encoder, einen Videodecoder, eine Power-Management-Einheit, etc. (nicht explizit dargestellt). Mit anderen Worten, die I/O-Einheit 205 ist konfiguriert, um die Kommunikation zwischen den verschiedenen logischen Einheiten der PPU 200 und zwischen diesen zu leiten.
In einer Ausführungsform kodiert ein vom Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einem Puffer, der der PPU 200 Arbeit zur Verarbeitung bereitstellt. Eine Arbeit bzw. Workload kann mehrere Anweisungen und Daten umfassen, die durch diese Anweisungen verarbeitet werden sollen. Der Puffer ist ein Bereich in einem Speicher, der sowohl vom Host-Prozessor als auch von der PPU 200 zugänglich ist (d.h. lesen/schreiben). So kann beispielsweise die I/O-Einheit 205 konfiguriert werden, um über Speicheranforderungen, die über die Verbindung 202 übertragen werden, auf den Puffer in einem mit der Verbindung 202 verbundenen Systemspeicher zuzugreifen. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und sendet dann einen Zeiger auf den Anfang des Befehlsstroms an die PPU 200. Die Frontend-Einheit 215 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Frontend-Einheit 215 verwaltet einen oder mehrere Ströme, liest Befehle aus den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 200 weiter.
Die Front-End-Einheit 215 ist mit einer Scheduler-Einheit 220 gekoppelt, die die verschiedenen GPCs 250 konfiguriert, um Tasks zu verarbeiten, die durch einen oder mehrere Ströme definiert sind. Die Scheduler-Einheit 220 ist konfiguriert, um Zustandsinformationen in Bezug auf die verschiedenen Tasks zu verfolgen, die von der Scheduler-Einheit 220 verwaltet werden. Der Zustand kann anzeigen, welchem GPC 250 eine Task zugeordnet ist, ob die Task aktiv oder inaktiv ist, eine der Task zugeordnete Prioritätsstufe usw. Die Scheduler-Einheit 220 verwaltet die Ausführung einer Vielzahl von Tasks auf einem oder mehreren GPCs 250.
Die Scheduler-Einheit 220 ist mit einer Arbeitsverteilungseinheit 225 gekoppelt, die konfiguriert ist, um Tasks zur Ausführung auf den GPCs 250 zu verteilen. Die Arbeitsverteilungseinheit 225 kann eine Anzahl von geplanten Tasks verfolgen, die von der Scheduler-Einheit 220 empfangen wurden. In einer Ausführungsform verwaltet die Arbeitsverteilungseinheit 225 für jeden der GPCs 250 einen Pool bevorstehender Tasks und einen Pool aktiver Tasks. Der Pool bevorstehender Tasks kann eine Anzahl von Slots (z.B. 32 Slots) umfassen, die Tasks enthalten, die von einem bestimmten GPC 250 bearbeitet werden sollen. Der Pool aktiver Tasks kann eine Anzahl von Slots (z.B. 4 Slots) für Tasks umfassen, die von den GPCs 250 aktiv bearbeitet werden. Wenn ein GPC 250 die Ausführung einer Task beendet, wird diese Task aus dem Pool aktiver Tasks für den GPC 250 geworfen und eine der anderen Tasks aus dem Pool der bevorstehenden Tasks ausgewählt und zur Ausführung auf dem GPC 250 eingeplant. Wenn eine aktive Task auf dem GPC 250 im Leerlauf war, z. B. während des Wartens auf die Auflösung einer Datenabhängigkeit, kann die aktive Task aus dem GPC 250 geworfen und in den Pool der bevorstehenden Tasks zurückgeführt werden, während eine andere Task im Pool der bevorstehenden Tasks ausgewählt und für die Ausführung auf dem GPC 250 eingeplant wird.
Die Arbeitsverteilungseinheit 225 kommuniziert mit einem oder mehreren GPCs 250 über die XBar 270. Die XBar 270 ist ein Verbindungsnetz, das viele der Einheiten der PPU 200 mit anderen Einheiten der PPU 200 koppelt. So kann beispielsweise die XBar 270 konfiguriert werden, um die Arbeitsverteilungseinheit 225 mit einem bestimmten GPC 250 zu koppeln. Obwohl es nicht ausdrücklich angegeben ist, können eine oder mehrere andere Einheiten der PPU 200 auch über den Netzwerkknoten 230 mit der XBar 270 verbunden sein.
Die Tasks werden von der Scheduler-Einheit 220 verwaltet und von der Arbeitsverteilungseinheit 225 an ein GPC 250 geschickt. Das GPC 250 ist konfiguriert, um die Task zu bearbeiten und Ergebnisse zu generieren. Die Ergebnisse können von anderen Tasks innerhalb des GPC 250 übernommen, über die XBar 270 an ein anderes GPC 250 weitergeleitet oder im Speicher 204 gespeichert werden. Die Ergebnisse können über die Partitionseinheiten 280 in den Speicher 204 geschrieben werden, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/aus dem Speicher 204 implementieren. Die Ergebnisse können über den NVLink 210 an eine andere PPU 200 oder CPU übertragen werden. In einer Ausführungsform beinhaltet die PPU 200 eine Anzahl U von Partitionseinheiten 280, die gleich der Anzahl der separaten und unterschiedlichen Speichervorrichtungen 204 ist, die mit der PPU 200 gekoppelt sind. Eine Partitionseinheit 280 wird im Folgenden in Verbindung mit 3B näher beschrieben.
In einer Ausführungsform führt ein Host-Prozessor einen Treiberkern aus, der eine Anwendungsprogrammierschnittstelle (API) implementiert, die es einer oder mehreren auf dem Host-Prozessor ausgeführten Anwendungen ermöglicht, Operationen zur Ausführung auf der PPU 200 einzuplanen. In einer Ausführungsform werden mehrere Rechenanwendungen gleichzeitig von der PPU 200 ausgeführt, und die PPU 200 bietet Isolation, Quality of Service (QoS) und unabhängige Adressräume für die mehreren Rechenanwendungen. Eine Anwendung kann Anweisungen (z.B. API-Aufrufe) erzeugen, die den Treiberkern veranlassen, einen oder mehrere Tasks zur Ausführung durch die PPU 200 zu erzeugen. Der Treiberkem gibt Tasks an einen oder mehrere Ströme aus, die von der PPU 200 verarbeitet werden. Jede Task kann eine oder mehrere Gruppen von verwandten Threads umfassen, die hierin als Warp bezeichnet werden. In einer Ausführungsform umfasst ein Warp 32 verwandte Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Vielzahl von Threads beziehen, einschließlich Anweisungen zur Ausführung der Tasks, die Daten über einen gemeinsamen Speicher austauschen können. Threads und zusammenwirkende Threads werden in Verbindung mit 4A näher beschrieben.
3A stellt ein GPC 250 der PPU 200 von 2 gemäß einer Ausführungsform dar. Wie in 3A dargestellt ist, beinhaltet jedes GPC 250 eine Reihe von Hardwareeinheiten zur Verarbeitung von Tasks. In einer Ausführungsform beinhaltet jedes GPC 250 einen Pipeline-Manager 310, eine Pre-Raster Operations Unit (PROP) 315, eine Raster-Engine 325, eine Work Distribution Crossbar (WDX) 380, eine Memory Management Unit (MMU) 390 und einen oder mehrere Data Processing Cluster (DPCs) 320. Es ist zu beachten, dass das GPC 250 von 3A anstelle oder zusätzlich zu den in 3A dargestellten Einheiten weitere Hardwareeinheiten beinhalten kann.
In einer Ausführungsform wird der Betrieb des GPC 250 durch den Pipelinemanager 310 gesteuert. Der Pipelinemanager 310 verwaltet die Konfiguration eines oder mehrerer DPCs 320 für die Bearbeitung von Tasks, die dem GPC 250 zugeordnet sind. In einer Ausführungsform kann der Pipelinemanager 310 mindestens einen der einen oder mehreren DPCs 320 konfigurieren, um mindestens einen Teil einer Grafik-Rendering-Pipeline zu implementieren. So kann beispielsweise ein DPC 320 konfiguriert werden, um ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 340 auszuführen. Der Pipelinemanager 310 kann auch konfiguriert werden, um von der Arbeitsverteilungseinheit 225 empfangene Pakete an die entsprechenden logischen Einheiten innerhalb des GPC 250 weiterzuleiten. So können beispielsweise einige Pakete an Hardwareeinheiten mit fester Funktion im PROP 315 und/oder in der Raster-Engine 325 weitergeleitet werden, während andere Pakete an die DPCs 320 zur Verarbeitung durch die Primitiv-Engine 335 oder den SM 340 weitergeleitet werden können. In einer Ausführungsform kann der Pipelinemanager 310 mindestens ein des einen oder mehreren DPCs 320 konfigurieren, um ein Modell eines neuronalen Netzes und/oder eine Rechen-Pipeline zu implementieren.
Die PROP-Einheit 315 ist konfiguriert, um die von der Raster-Engine 325 und den DPCs 320 erzeugten Daten an eine Raster Operations (ROP)-Einheit weiterzuleiten, die in Verbindung mit 3B näher beschrieben wird. Die PROP-Einheit 315 kann auch konfiguriert werden, um Optimierungen für den Farbverlauf durchzuführen, Pixeldaten zu organisieren, Adressenübersetzungen durchzuführen und dergleichen.
Die Raster-Engine 325 beinhaltet eine Reihe von Hardwareeinheiten mit fester Funktion, die für die Durchführung verschiedener Rasteroperationen konfiguriert sind. In einer Ausführungsform beinhaltet die Raster-Engine 325 eine Setup-Engine, eine Grobraster-Engine, eine Culling-Engine, eine Clipping-Engine, eine Feinraster-Engine und eine Kachelvereinigungs-Engine. Die Setup-Engine empfängt transformierte Vertices und erzeugt Ebenengleichungen, die dem durch die Vertices definierten geometrischen Primitiv zugeordnet sind. Die Ebenengleichungen werden an die Grobraster-Engine übertragen, um Abdeckungsinformationen (z.B. eine x,y-Abdeckungsmaske für eine Kachel) für das Primitiv zu erzeugen. Die Ausgabe der Grobraster-Engine wird an die Culling-Engine übertragen, wo Fragmente, die dem Primitiv zugeordnet sind und einen z-Test nicht bestehen, aussortiert werden, und an eine Clipping-Engine übertragen, wo Fragmente, die außerhalb eines Sichtvolumens liegen, abgeschnitten werden. Die Fragmente, die das Clipping und Culling überleben, können an die Feinraster-Engine übergeben werden, um Attribute für die Pixelfragmente basierend auf den von der Setup-Engine erzeugten Ebenengleichungen zu erzeugen. Die Ausgabe der Raster-Engine 325 umfasst Fragmente, die beispielsweise von einem in einem DPC 320 implementierten Fragment-Shader verarbeitet werden sollen.
Jedes im GPC 250 enthaltene DPC 320 beinhaltet einen M-Pipe Controller (MPC) 330, eine Primitiv-Engine 335 und einen oder mehrere SMs 340. Der MPC 330 steuert den Betrieb des DPC 320 und leitet die vom Pipelinemanager 310 empfangenen Pakete an die entsprechenden Einheiten des DPC 320 weiter. So können beispielsweise Pakete, die einem Vertex zugeordnet sind, an die Primitiv-Engine 335 weitergeleitet werden, die konfiguriert ist, um die dem Vertex zugeordneten Vertex-Attribute aus dem Speicher 204 zu holen. Im Gegensatz dazu können Pakete, die einem Shaderprogramm zugeordnet sind, an den SM 340 übertragen werden.
Der SM 340 umfasst einen programmierbaren Streaming-Prozessor, der konfiguriert ist, um Tasks zu verarbeiten, die durch eine Reihe von Threads repräsentiert werden. Jeder SM 340 ist multi-threaded und konfiguriert, um eine Vielzahl von Threads (z.B. 32 Threads) aus einer bestimmten Gruppe von Threads gleichzeitig auszuführen. In einer Ausführungsform implementiert der SM 340 eine SIMD-Architektur (Single-Instruction, Multiple-Data), bei der jeder Thread in einer Gruppe von Threads (d.h. ein Warp) konfiguriert ist, um einen anderen Datensatz basierend auf demselben Befehlssatz zu verarbeiten. Alle Threads in der Gruppe der Threads führen die gleichen Anweisungen aus. In einer weiteren Ausführungsform implementiert der SM 340 eine SIMT-Architektur (Single-Instruction, Multiple Thread), bei der jeder Thread in einer Gruppe von Threads konfiguriert ist, um einen anderen Datensatz zu verarbeiten, der auf demselben Befehlssatz basiert, wobei jedoch einzelne Threads in der Gruppe von Threads während der Ausführung divergieren dürfen. In einer Ausführungsform wird für jeden Warp ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand gehalten, was die Gleichzeitigkeit zwischen Warps und die serielle Ausführung innerhalb von Warps ermöglicht, wenn Threads innerhalb des Warps divergieren. In einer weiteren Ausführungsform wird für jeden einzelnen Thread ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand gehalten, wodurch eine gleiche Nebenläufigkeit zwischen allen Threads, innerhalb und zwischen den Warps, ermöglicht wird. Wenn der Ausführungszustand für jeden einzelnen Thread gehalten wird, können Threads, die dieselben Anweisungen ausführen, konvergieren und parallel ausgeführt werden, um eine maximale Effizienz zu erreichen. Der SM 340 wird im Folgenden in Verbindung mit 4A näher beschrieben.
Die MMU 390 bietet eine Schnittstelle zwischen dem GPC 250 und der Partitionseinheit 280. Die MMU 390 kann die Übersetzung virtueller Adressen in physikalische Adressen, den Speicherschutz und die Konkurrenzbereinigung von Speicheranforderungen ermöglichen. In einer Ausführungsform stellt die MMU 390 einen oder mehrere Translation Lookaside Buffer (TLBs) zur Verfügung, um die Übersetzung von virtuellen Adressen in physikalische Adressen im Speicher 204 durchzuführen.
3B veranschaulicht eine Speicherpartitionseinheit 280 der PPU 200 von 2 gemäß einer Ausführungsform. Wie in 3B dargestellt ist, beinhaltet die Speicherpartitionseinheit 280 eine Raster Operations (ROP)-Einheit 350, einen Level-2 (L2)-Cache 360 und eine Speicherschnittstelle 370. Die Speicherschnittstelle 370 ist mit dem Speicher 204 gekoppelt. Die Speicherschnittstelle 370 kann 32, 64, 128, 1024-Bit-Datenbusse oder dergleichen für die Hochgeschwindigkeits-Datenübertragung implementieren. In einer Ausführungsform beinhaltet die PPU 200 U Speicherschnittstellen 370, eine Speicherschnittstelle 370 pro Paar von Partitionseinheiten 280, wobei jedes Paar von Partitionseinheiten 280 mit einer entsprechenden Speichervorrichtung 204 verbunden ist. So kann beispielsweise die PPU 200 mit bis zu Y Speichervorrichtungen 204 verbunden werden, wie beispielsweise mit Speicherstapeln mit hoher Bandbreite oder Grafiken mit doppelter Datenrate, Version 5, synchronem dynamischem Direktzugriffsspeicher oder anderen Arten von persistentem Speicher.
In einer Ausführungsform implementiert die Speicherschnittstelle 370 eine HBM2-Speicherschnittstelle und Y entspricht der Hälfte von U. In einer Ausführungsform befinden sich die HBM2-Speicherstapel auf der gleichen physikalischen Baugruppe wie die PPU 200, was im Vergleich zu herkömmlichen GDDR5-SDRAM-Systemen zu erheblichen Strom- und Flächeneinsparungen führt. In einer Ausführungsform beinhaltet jeder HBM2-Stapel vier Speicherchips und Y ist gleich 4, wobei der HBM2-Stapel zwei 128-Bit-Kanäle pro Chip für insgesamt 8 Kanäle und eine Datenbusbreite von 1024 Bit beinhaltet.
In einer Ausführungsform unterstützt der Speicher 204 den Single-Error Correcting Double-Error Detecting (SECDED) Error Correction Code (ECC) zum Schutz der Daten. ECC bietet eine höhere Zuverlässigkeit für Rechenanwendungen, die empfindlich auf Datenverluste reagieren. Zuverlässigkeit ist besonders wichtig in großen Cluster-Computerumgebungen, in denen PPUs 200 sehr große Datensätze verarbeiten und/oder Anwendungen über einen längeren Zeitraum betreiben.
In einer Ausführungsform implementiert die PPU 200 eine mehrstufige Speicherhierarchie. In einer Ausführungsform unterstützt die Speicherpartitionseinheit 280 einen vereinheitlichten Speicher, um einen einzigen vereinheitlichten virtuellen Adressraum für CPU- und PPU 200-Speicher bereitzustellen, der den Datenaustausch zwischen virtuellen Speichersystemen ermöglicht. In einer Ausführungsform wird die Häufigkeit der Zugriffe einer PPU 200 auf Speicher auf anderen Prozessoren verfolgt, um sicherzustellen, dass Speicherseiten in den physikalischen Speicher der PPU 200 verschoben werden, die häufiger auf die Seiten zugreift. In einer Ausführungsform unterstützt der NVLink 210 Adressübersetzungsdienste, die es der PPU 200 ermöglichen, direkt auf die Seitentabellen einer CPU zuzugreifen, und den vollen Zugriff auf den CPU-Speicher der PPU 200 ermöglichen.
In einer Ausführungsform übertragen Kopiermaschinen Daten zwischen mehreren PPUs 200 oder zwischen PPUs 200 und CPUs. Die Kopiermaschinen können Seitenfehler für Adressen erzeugen, die nicht in den Seitentabellen abgebildet sind. Die Speicherpartitionseinheit 280 kann dann die Seitenfehler beheben und die Adressen in die Seitentabelle eintragen, woraufhin die Kopiermaschine den Transfer durchführen kann. In einem konventionellen System ist der Speicher für mehrere Kopiervorgänge zwischen mehreren Prozessoren fest zugeordnet (d.h. nicht auslagerbar), wodurch die Anzahl der Kopien erheblich reduziert wird. Mit Hardware-Seitenfehlern können Adressen an die Kopiermaschinen weitergegeben werden, ohne sich Sorgen zu machen, ob die Speicherseiten resident sind, und der Kopiervorgang ist transparent.
Daten aus dem Speicher 204 oder einem anderen Systemspeicher können von der Speicherpartitionseinheit 280 abgerufen und im L2-Cache 360 gespeichert werden, der sich auf dem Chip befindet und von den verschiedenen GPCs 250 gemeinsam genutzt wird. Wie dargestellt ist, beinhaltet jede Speicherpartitionseinheit 280 einen Abschnitt des L2-Cache 360, der einer entsprechenden Speichervorrichtung 204 zugeordnet ist. Untergeordnete Caches können dann in verschiedenen Einheiten innerhalb der GPCs 250 implementiert werden. So kann beispielsweise jeder der SMs 340 einen Level One (L1)-Cache implementieren. Der L1 -Cache ist ein privater Speicher, der für einen bestimmten SM 340 reserviert ist. Daten aus dem L2-Cache 360 können abgerufen und in jedem der L1 -Caches zur Verarbeitung in den Funktionseinheiten des SMs 340 gespeichert werden. Der L2-Cache 360 ist mit der Speicherschnittstelle 370 und der XBar 270 gekoppelt.
Die ROP-Einheit 350 führt grafische Rasteroperationen im Zusammenhang mit Pixelfarben durch, wie z.B. Farbkompression, Pixelblending und dergleichen. Die ROP-Einheit 350 führt auch Tiefenprüfungen in Verbindung mit der Raster-Engine 325 durch, wobei sie eine Tiefe für eine Sampleposition empfängt, die einem Pixelfragment von der Culling-Engine der Raster-Engine 325 zugeordnet ist. Die Tiefe wird gegen eine entsprechende Tiefe in einem Tiefenpuffer für eine dem Fragment zugeordnete Sampleposition getestet. Wenn das Fragment die Tiefenprüfung für die Sampleposition besteht, aktualisiert die ROP-Einheit 350 den Tiefenpuffer und sendet ein Ergebnis der Tiefenprüfung an die Raster-Engine 325. Es ist zu beachten, dass die Anzahl der Partitionseinheiten 280 von der Anzahl der GPCs 250 abweichen kann und daher jede ROP-Einheit 350 mit jeder der GPCs 250 gekoppelt werden kann. Die ROP-Einheit 350 verfolgt die von den verschiedenen GPCs 250 empfangenen Pakete und bestimmt, zu welchem GPC 250 ein von der ROP-Einheit 350 erzeugtes Ergebnis durch die Xbar 270 geleitet wird. Obwohl die ROP-Einheit 350 in 3B innerhalb der Speicherpartitionseinheit 280 enthalten ist, kann sich die ROP-Einheit 350 in anderen Ausführungsformen außerhalb der Speicherpartitionseinheit 280 befinden. So kann sich beispielsweise die ROP-Einheit 350 im GPC 250 oder einer anderen Einheit befinden.
4A veranschaulicht den Streaming-Multiprozessor 340 von 3A gemäß einer Ausführungsform. Wie in 4A dargestellt ist, beinhaltet der SM 340 einen Befehls-Cache 405, eine oder mehrere Schedulereinheiten 410(K), eine Registerdatei 420, einen oder mehrere Rechenkerne 450, eine oder mehrere Spezialfunktionseinheiten (SFUs) 452, eine oder mehrere Lade-/Speichereinheiten (LSUs) 454, ein Verbindungsnetzwerk 480, einen gemeinsamen Speicher/L1-Cache 470.
Wie vorstehend beschrieben ist, plant die Arbeitsverteilungseinheit 225 Tasks zur Ausführung auf den GPCs 250 der PPU 200 ein. Die Tasks werden einem bestimmten DPC 320 innerhalb eines GPC 250 zugeordnet und, wenn die Task einem Shaderprogramm zugeordnet ist, kann die Task einem SM 340 zugeordnet werden. Die Schedulereinheit 410(K) empfängt die Tasks von der Arbeitsverteilungseinheit 225 und verwaltet die Befehlsplanung für einen oder mehrere dem SM 340 zugeordnete Thread-Blöcke. Die Schedulereinheit 410(K) plant Thread-Blöcke zur Ausführung als Warps paralleler Threads, wobei jedem Thread-Block mindestens ein Warp zugeordnet ist. In einer Ausführungsform führt jeder Warp 32 Threads aus. Die Schedulereinheit 410(K) kann eine Vielzahl von verschiedenen Thread-Blöcken verwalten, indem sie die Warps den verschiedenen Thread-Blöcken zuordnet und dann während jedes Taktzyklus Anweisungen von der Vielzahl von verschiedenen kooperativen Gruppen an die verschiedenen Funktionseinheiten (d.h. Kerne 450, SFUs 452 und LSUs 454) sendet.
Kooperative Gruppen (Cooperative Groups) ist ein Programmiermodell zum Organisieren von Gruppen von kommunizierenden Threads, das es Entwicklern ermöglicht, die Granularität auszudrücken, mit der Threads kommunizieren, was den Ausdruck von reichhaltigeren, effizienteren parallelen Zerlegungen ermöglicht. Kooperative Start-APIs unterstützen die Synchronisation zwischen Thread-Blöcken zur Ausführung paralleler Algorithmen. Herkömmliche Programmiermodelle bieten ein einziges, einfaches Konstrukt zur Synchronisation kooperierender Threads: eine Barriere über alle Threads eines Thread-Blocks (d.h. die syncthreads() Funktion). Programmierer möchten jedoch oft Gruppen von Threads definieren, die kleiner als die Granularität von Threads sind, und innerhalb der definierten Gruppen synchronisieren, um mehr Leistung, Designflexibilität und Softwarewiederverwendung in Form von gemeinsamen gruppenweiten Funktionsschnittstellen zu ermöglichen.
Kooperative Gruppen ermöglichen es Programmierern, Gruppen von Threads explizit am Sub-Block (d.h. bis zu einem einzelnen Thread) und Multiblock-Granularitäten zu definieren und gemeinsame Operationen wie die Synchronisation der Threads in einer kooperativen Gruppe durchzuführen. Das Programmiermodell unterstützt eine saubere Zusammensetzung über Softwaregrenzen hinweg, so dass Bibliotheken und Utility-Funktionen sicher in ihrem lokalen Kontext synchronisieren können, ohne Annahmen über die Konvergenz treffen zu müssen. Primitives von kooperativen Gruppen ermöglichen neue Muster der kooperativen Parallelität, einschließlich Produzenten-Verbraucher-Parallelität, opportunistischer Parallelität und globaler Synchronisation über ein ganzes Netz von Thread-Blöcken.
Eine Schedulereinheit 415 ist konfiguriert, um Anweisungen an eine oder mehrere der Funktionseinheiten zu senden. In der Ausführungsform beinhaltet die Schedulereinheit 410(K) zwei Dispatchereinheiten 415, die es ermöglichen, während jedes Taktzyklus zwei verschiedene Anweisungen von demselben Warp zu senden. In alternativen Ausführungsformen kann jede Schedulereinheit 410(K) eine einzelne Dispatchereinheit 415 oder zusätzliche Dispatchereinheiten 415 beinhalten.
Jeder SM 340 enthält eine Registerdatei 420, die einen Satz von Registern für die Funktionseinheiten des SM 340 bereitstellt. In einer Ausführungsform ist die Registerdatei 420 auf jede der Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein bestimmter Abschnitt der Registerdatei 420 zugeordnet ist. In einer weiteren Ausführungsform wird die Registerdatei 420 auf die verschiedenen Warps aufgeteilt, die von dem SM 340 ausgeführt werden. Die Registerdatei 420 bietet Zwischenspeicher für Operanden, die mit den Datenpfaden der Funktionseinheiten verbunden sind.
Jeder SM 340 umfasst L Verarbeitungskerne 450. In einer Ausführungsform beinhaltet der SM 340 eine große Anzahl (z.B. 128, etc.) von verschiedenen Verarbeitungskernen 450. Jeder Kern 450 kann eine Verarbeitungseinheit mit vollständiger Pipeline, einfacher Genauigkeit, doppelter Genauigkeit und/oder gemischte Genauigkeit beinhalten, die eine Logikeinheit mit Gleitkommaarithmetik und eine Logikeinheit mit ganzzahliger Arithmetik beinhaltet. In einer Ausführungsform implementieren die Logikeinheiten mit Gleitkommaarithmetik den Standard IEEE 754-2008 für Gleitkommaarithmetik. In einer Ausführungsform beinhalten die Kerne 450 64 Single-Precision (32-Bit) Gleitkomma-Kerne, 64 Ganzzahlkerne, 32 Double-Precision (64-Bit) Gleitkomma-Kerne und 8 Tensorkerne.
Tensorkerne sind konfiguriert, um Matrixoperationen durchzuführen, und in einer Ausführungsform sind ein oder mehrere Tensorkerne in den Kernen 450 enthalten. Insbesondere sind die Tensorkerne konfiguriert, um Deep-Leaming-Matrixarithmetik durchzuführen, wie z.B. Faltungsoperationen für das Training und das logische Schließen von neuronalen Netzen. In einer Ausführungsform arbeitet jeder Tensorkern auf einer 4x4-Matrix und führt eine Matrixmultiplikations- und Akkumulations-Operation D=AB+C durch, wobei A, B, C und D 4x4-Matrizen sind.
In einer Ausführungsform sind die Matrix-Multiplikatoreingänge A und B 16-Bit-Fließkomma-Matrizen, während die Summierungsmatrizen C und D 16-Bit-Fließkomma- oder 32-Bit-Fließkomma-Matrizen sein können. Tensorkerne arbeiten mit 16-Bit Gleitkomma-Eingangsdaten mit 32-Bit Gleitkommaakkumulation. Die 16-Bit-Fließkomma-Multiplikation erfordert 64 Operationen und führt zu einem hochpräzisen Produkt, das dann unter Verwendung der 32-Bit-Fließkommaaddition mit den anderen Zwischenprodukten für eine 4x4x4x4-Matrix-Multiplikation akkumuliert wird. In der Praxis werden Tensorkerne verwendet, um viel größere zweidimensionale oder höher dimensionale Matrixoperationen durchzuführen, die sich aus diesen kleineren Elementen zusammensetzen. Eine API, wie die CUDA 9 C++ API, stellt spezielle Matrixlade-, Matrixmultiplikations- und -akkumulationssowie Matrixspeicher-Operationen zur Verfügung, um Tensor-Kerne aus einem CUDA-C++-Programm effizient zu nutzen. Auf der CUDA-Ebene geht das Warp-Level-Interface von Matrizen der Größe 16x16 aus, die alle 32 Threads des Warps umfassen.
Jeder SM 340 umfasst auch M SFUs 452, die spezielle Funktionen ausführen (z.B. Attributbewertung, reziproke Quadratwurzel und dergleichen). In einer Ausführungsform können die SFUs 452 eine Baumdurchlaufeinheit beinhalten, die konfiguriert ist, um eine hierarchische Baumdatenstruktur zu durchlaufen. In einer Ausführungsform können die SFUs 452 eine Textureinheit beinhalten, die konfiguriert ist, um Texturkartenfilteroperationen durchzuführen. In einer Ausführungsform sind die Textureinheiten konfiguriert, um Texturkarten (z.B. ein 2D-Array von Texturen) aus dem Speicher 204 zu laden und die Texturkarten abzutasten, um abgetastete Texturwerte für die Verwendung in Shaderprogrammen zu erzeugen, die von dem SM 340 ausgeführt werden. In einer Ausführungsform werden die Texturkarten im gemeinsamen Speicher / L1-Cache 370 gespeichert. Die Textureinheiten implementieren Texturoperationen wie z.B. Filteroperationen mit Hilfe von Mip-Maps (d.h. Texturkarten mit unterschiedlichem Detaillierungsgrad). In einer Ausführungsform beinhaltet jeder SM 240 zwei Textureinheiten.
Jeder SM 340 umfasst auch N LSUs 454, die Lade- und Speicheroperationen zwischen dem gemeinsamen Speicher / L1-Cache 470 und der Registerdatei 420 implementieren. Jeder SM 340 beinhaltet ein Verbindungsnetzwerk 480, das jede der Funktionseinheiten mit der Registerdatei 420 und die LSU 454 mit der Registerdatei 420, gemeinsamen Speicher / L1-Cache 470 verbindet. In einer Ausführungsform ist das Verbindungsnetzwerk 480 ein Koppelfeld, das konfiguriert werden kann, um eine der Funktionseinheiten mit einem der Register in der Registerdatei 420 zu verbinden und die LSUs 454 mit der Registerdatei und den Speicherplätzen im gemeinsamen Speicher / L1-Cache 470 zu verbinden.
Der gemeinsame Speicher / L1 Cache 470 ist ein Array von On-Chip-Speicher, das die Datenspeicherung und Kommunikation zwischen dem SM 340 und der Primitiv-Engine 335 sowie zwischen den Threads im SM 340 ermöglicht. In einer Ausführungsform umfasst der gemeinsame Speicher / L1-Cache 470 128KB Speicherkapazität und befindet sich in dem Pfad von dem SM 340 zur Partitionseinheit 280. Der gemeinsame Speicher / L1-Cache 470 kann zum Cachen von Lese- und Schreib-Zugriffen verwendet werden. Einer oder mehrere von dem gemeinsamen Speicher / L1-Cache 470, L2-Cache 360 und Speicher 204 sind Backup-Speicher.
Die Kombination von Daten-Cache und Funktionalität eines gemeinsamen Speichers in einem einzigen Speicherblock bietet die beste Gesamtleistung für beide Arten von Speicherzugriffen. Die Kapazität ist als Cache für Programme nutzbar, die keinen gemeinsamen Speicher verwenden. Wenn beispielsweise der gemeinsame Speicher so konfiguriert ist, dass er die Hälfte der Kapazität nutzt, können Textur- und Lade-/Speicheroperationen die verbleibende Kapazität nutzen. Die Integration in den gemeinsamen Speicher / L1-Cache 470 ermöglicht es dem gemeinsamer Speicher / L1-Cache 470, als Hochdurchsatzleitung für das Streaming von Daten zu fungieren und gleichzeitig einen latenzarmen Zugriff mit hoher Bandbreite auf häufig wiederverwendeten Daten zu ermöglichen.
Bei der Konfiguration für allgemeine parallele Berechnungen kann eine einfachere Konfiguration im Vergleich zur Grafikverarbeitung verwendet werden. Insbesondere werden die in 2 dargestellten Grafikverarbeitungseinheiten mit fester Funktion umgangen, wodurch ein wesentlich einfacheres Programmiermodell entsteht. In der universellen Konfiguration der parallelen Berechnung weist die Arbeitsverteilungseinheit 225 Threads direkt den DPCs 320 zu und verteilt sie. Die Threads in einem Block führen das gleiche Programm aus, wobei eine eindeutige Thread-ID in der Berechnung verwendet wird, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, wobei der SM 340 verwendet wird, um das Programm auszuführen und Berechnungen durchzuführen, der gemeinsame Speicher / L1-Cache 470 verwendet wird, um zwischen Threads zu kommunizieren, und die LSU 454 verwendet wird, um den globalen Speicher über den gemeinsamen Speicher / L1 -Cache 470 und die Speicherpartitionseinheit 280 zu lesen und zu schreiben. Wenn der SM 340 für die allgemeine parallele Berechnung konfiguriert ist, kann er auch Befehle schreiben, mit denen die Schedulereinheit 220 neue Arbeiten bei den DPCs 320 starten kann.
Die PPU 200 kann in einem Desktop-Computer, einem Laptop-Computer, einem Tablet-Computer, Servern, Supercomputern, einem Smartphone (z.B. einem drahtlosen, tragbaren Gerät), einem Personal Digital Assistant (PDA), einer Digitalkamera, einem Fahrzeug, einem am Kopf montierten Display, einem tragbaren elektronischen Gerät und dergleichen enthalten sein. In einer Ausführungsform ist die PPU 200 auf einem einzelnen Halbleitersubstrat ausgeführt. In einer weiteren Ausführungsform ist die PPU 200 zusammen mit einer oder mehreren anderen Vorrichtungen, wie zusätzlichen PPUs 200, dem Speicher 204, einer CPU mit reduziertem Befehlssatz (RISC), einer Speicherverwaltungseinheit (MMU), einem Digital-Analog-Wandler (DAC) und dergleichen, in einem System auf einem Chip (SoC) enthalten.
In einer Ausführungsform kann die PPU 200 auf einer Grafikkarte mit einer oder mehreren Speicherbauelementen 204 enthalten sein. Die Grafikkarte kann so konfiguriert werden, dass sie mit einem PCIe-Steckplatz auf einem Motherboard eines Desktop-Computers verbunden ist. In noch einer weiteren Ausführungsform kann die PPU 200 eine integrierte Grafikverarbeitungseinheit (iGPU) oder ein paralleler Prozessor sein, der im Chipsatz des Motherboards enthalten ist.
Beispielhaftes Rechensystem
Systeme mit mehreren GPUs und CPUs werden in einer Vielzahl von Branchen eingesetzt, da Entwickler mehr Parallelität in Anwendungen wie Berechnungen bei künstlicher Intelligenz ausführen und nutzen. Leistungsstarke GPU-beschleunigte Systeme mit Zehntausenden von Rechenknoten werden in Rechenzentren, Forschungseinrichtungen und Supercomputern eingesetzt, um immer größere Probleme zu lösen. Mit zunehmender Anzahl von Verarbeitungsgeräten innerhalb der Hochleistungssysteme müssen die Kommunikations- und Datenübertragungsmechanismen skaliert werden, um die erhöhte Bandbreite zu unterstützen.
4B ist eine konzeptionelle Darstellung eines Verarbeitungssystems 400, das unter Verwendung der PPU 200 von 2 gemäß einer Ausführungsform implementiert wurde. Das exemplarische System 465 kann konfiguriert werden, um das in 1 dargestellte Verfahren 100 zu implementieren. Das Verarbeitungssystem 400 beinhaltet eine CPU 430, einen Switch 410 und jeweils mehrere PPUs 200 und entsprechende Speicher 204. Der NVLink 210 bietet Hochgeschwindigkeitskommunikationsverbindungen zwischen jeder der PPUs 200. Obwohl eine bestimmte Anzahl von NVLink 210- und 202-Verbindungen in 4B dargestellt ist, kann die Anzahl der Verbindungen zu jeder PPU 200 und der CPU 430 variieren. Der Switch 410 verbindet die Verbindung 202 mit der CPU 430. Die PPUs 200, 204 und NVLinks 210 können sich auf einer einzigen Halbleiterplattform befinden, um ein Parallelverarbeitungsmodul 425 zu bilden. In einer Ausführungsform unterstützt der Switch 410 zwei oder mehr Protokolle zur Schnittstelle zwischen unterschiedlichen verschiedenen Verbindungen und/oder Anschlüssen.
In einer weiteren Ausführungsform (nicht dargestellt) stellt der NVLink 210 eine oder mehrere Hochgeschwindigkeitskommunikationsverbindungen zwischen jeder der PPUs 200 und der CPU 430 sowie den Switch 410-Schnittstellen zwischen der Verbindung 202 und jeder der PPUs 200 bereit. Die PPUs 200, 204 und 202 können auf einer einzigen Halbleiterplattform angeordnet sein, um ein Parallelverarbeitungsmodul 425 zu bilden. In noch einer weiteren Ausführungsform (nicht dargestellt) stellt die Verbindung 202 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 200 und der CPU 430 bereit, und der Switch 410 verbindet zwischen jeder der PPUs 200 mittels des NVLink 210, um eine oder mehrere Hochgeschwindigkeitskommunikationsverbindungen zwischen den PPUs 200 bereitzustellen. In einer weiteren Ausführungsform (nicht dargestellt) stellt der NVLink 210 eine oder mehrere Hochgeschwindigkeitskommunikationsverbindungen zwischen den PPUs 200 und der CPU 430 über den Switch 410 bereit. In noch einer weiteren Ausführungsform (nicht dargestellt) stellt die Verbindung 202 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 200 direkt zur Verfügung. Eine oder mehrere der Hochgeschwindigkeitskommunikationsverbindungen NVLink 210 können als physische NVLink-Verbindung oder als On-Chip- oder On-Die-Verbindung unter Verwendung des gleichen Protokolls wie NVLink 210 implementiert werden.
Im Rahmen der vorliegenden Beschreibung kann sich eine einzelne Halbleiterplattform auf eine einzige einheitliche halbleiterbasierte integrierte Schaltung beziehen, die auf einem Die oder einem Chip hergestellt wird. Es ist zu beachten, dass sich der Begriff Single-Halbleiterplattform auch auf Multichip-Module mit erhöhter Konnektivität beziehen kann, die den On-Chip-Betrieb simulieren und wesentliche Verbesserungen gegenüber einer herkömmlichen Busimplementierung aufweisen. Natürlich können die verschiedenen Schaltungen oder Vorrichtungen auch einzeln oder in verschiedenen Kombinationen von Halbleiterplattformen nach den Wünschen des Benutzers angeordnet sein. Alternativ kann das Parallelverarbeitungsmodul 425 als Leiterplattensubstrat implementiert werden und jede der PPUs 200 und/oder Speicher 204 kann als kompaktes Bauelement ausgeführt werden. In einer Ausführungsform befinden sich die CPU 430, der Switch 410 und das Parallelverarbeitungsmodul 425 auf einer einzigen Halbleiterplattform.
In einer Ausführungsform beträgt die Signalübertragungsrate jedes NVLink 210 20 bis 25 Gigabit/Sekunde und jede PPU 200 beinhaltet sechs NVLink 210-Schnittstellen (wie es in 4B dargestellt ist, sind fünf NVLink 210-Schnittstellen für jede PPU 200 enthalten). Jeder NVLink 210 bietet eine Datenübertragungsrate von 25 Gigabyte/Sekunde in jede Richtung, sechs Links liefern 300 Gigabyte/Sekunde. Die NVLinks 210 können ausschließlich für die PPU-zu-PPU-Kommunikation verwendet werden, wie es in 4B dargestellt ist, oder für eine Kombination aus PPU-zu-PPU und PPU-zu-CPU, wenn die CPU 430 auch eine oder mehrere NVLink 210-Schnittstellen aufweist.
In einer Ausführungsform ermöglicht der NVLink 210 den direkten Lade-/Speicher-/atomaren Zugriff von der CPU 430 auf den 200 Speicher 204 jeder PPU. In einer Ausführungsform unterstützt der NVLink 210 Kohärenzoperationen, so dass aus den Speichern 204 gelesene Daten in der Cache-Hierarchie der CPU 430 gespeichert werden können, wodurch die Cache-Zugriffslatenz für die CPU 430 reduziert wird. In einer Ausführungsform beinhaltet der NVLink 210 die Unterstützung von Address Translation Services (ATS), so dass die PPU 200 direkt auf Seitentabellen innerhalb der CPU 430 zugreifen kann. Einer oder mehrere der NVLinks 210 können auch für den Betrieb in einem Low-Power-Modus konfiguriert werden.
4C stellt ein exemplarisches System 465 dar, in dem die unterschiedlichen Architekturen und/oder Funktionalitäten der verschiedenen vorherigen Ausführungsformen implementiert werden können. Das exemplarische System 465 kann konfiguriert werden, um das in 1 dargestellte Verfahren 100 zu implementieren.
Wie dargestellt, ist ein System 465 vorgesehen, das mindestens eine Zentraleinheit 430 beinhaltet, die an einen Kommunikationsbus 475 angeschlossen ist. Der Kommunikationsbus 475 kann mit jedem geeigneten Protokoll implementiert werden, wie z.B. PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), Hyper-Transport oder jedem anderen Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll(en). Das System 465 beinhaltet auch einen Hauptspeicher 440. Die Steuerlogik (Software) und die Daten werden im Hauptspeicher 440 gespeichert, der als Direktzugriffsspeicher (RAM) ausgeführt sein kann.
Das System 465 beinhaltet auch die Eingabevorrichtungen 460, das Parallelverarbeitungssystem 425 und die Anzeigevorrichtungen 445, d.h. ein herkömmliches CRT (Kathodenstrahlröhre), LCD (Flüssigkristallanzeige), LED (Leuchtdiode), eine Plasmaanzeige oder dergleichen. Benutzereingaben können von den Eingabegeräten 460 empfangen werden, z.B. Tastatur, Maus, Touchpad, Mikrofon und dergleichen. Jedes der vorgenannten Module und/oder Vorrichtungen kann sich sogar auf einer einzigen Halbleiterplattform befinden, um das System 465 zu bilden. Alternativ können die verschiedenen Module auch einzeln oder in verschiedenen Kombinationen von Halbleiterplattformen nach den Wünschen des Anwenders angeordnet werden.
Weiterhin kann das System 465 über eine Netzwerkschnittstelle 435 zu Kommunikationszwecken mit einem Netzwerk (z.B. Telekommunikationsnetzwerk, Local Area Network (LAN), Wireless Network, Wide Area Network (WAN) wie Internet, Peer-to-Peer-Netzwerk, Kabelnetzwerk oder dergleichen) gekoppelt sein.
Das System 465 kann auch einen Sekundärspeicher beinhalten (nicht dargestellt). Der Sekundärspeicher beinhaltet beispielsweise ein Festplattenlaufwerk und/oder ein Wechselspeicherlaufwerk, das ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein Compact-Disk-Laufwerk, ein digitales vielseitiges Disketten-(DVD)-Laufwerk, ein Aufnahmegerät, einen universellen seriellen Bus-(USB)-Flashspeicher darstellt. Das Wechselspeicherlaufwerk liest und/oder schreibt in bekannter Weise von einer Wechselspeichereinheit.
Computerprogramme oder Algorithmen der Computersteuerungslogik können im Hauptspeicher 440 und/oder im Sekundärspeicher gespeichert werden. Solche Computerprogramme ermöglichen es dem System 465, verschiedene Funktionen auszuführen, wenn sie ausgeführt werden. Der Speicher 440, der Speicher und/oder jeder andere Speicher sind mögliche Beispiele für computerlesbare Medien.
Die Architekturen und/oder Funktionalitäten der verschiedenen vorherigen Figuren können im Rahmen eines allgemeinen Computersystems, eines Platinensystems, eines Spielkonsolensystems für Unterhaltungszwecke, eines anwendungsspezifischen Systems und/oder eines anderen gewünschten Systems implementiert werden. Das System 465 kann beispielsweise in Form eines Desktop-Computers, eines Laptops, eines Tablet-Computers, von Servern, Supercomputern, eines Smartphones (z.B. eines drahtlosen, tragbaren Geräts), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, eines am Kopf montierten Displays, einer tragbaren elektronischen Vorrichtung, einer mobilen Telefonvorrichtung, eines Fernsehers, einer Workstation, einer Spielkonsole, eines eingebetteten Systems und/oder einer anderen Art von Logik ausgeführt sein.
Obwohl verschiedene Ausführungsformen vorstehend beschrieben wurden, sollte man verstehen, dass sie nur als Beispiel und nicht als Einschränkung dargestellt wurden. Daher sollte die Breite und der Umfang einer bevorzugten Ausführungsform nicht durch eine der oben beschriebenen exemplarischen Ausführungsformen eingeschränkt werden, sondern nur in Übereinstimmung mit den folgenden Ansprüchen und ihren Entsprechungen definiert werden.
Grafikverarbeitungs-Pipeline
In einer Ausführungsform umfasst die PPU 200 eine Grafikverarbeitungseinheit (GPU). Die PPU 200 ist konfiguriert, um Befehle zu empfangen, die Shaderprogramme zur Verarbeitung von Bilddaten spezifizieren. Grafikdaten können als eine Reihe von Primitives wie Punkte, Linien, Dreiecke, Vierecken, Triangle Strips und dergleichen definiert werden. Typischerweise beinhaltet ein Primitiv Daten, die eine Anzahl von Vertices für das Primitiv angeben (z.B. in einem Modell-Raum-Koordinatensystem) sowie Attribute, die jedem Vertex des Primitives zugeordnet sind. Die PPU 200 kann konfiguriert werden, um die Grafik-Primitives zu verarbeiten, um einen Frame-Puffer (d.h. Pixeldaten für jedes der Pixel der Anzeige) zu erzeugen.
Eine Anwendung schreibt Modelldaten für eine Szene (d.h. eine Sammlung von Vertices und Attributen) in einen Speicher, wie beispielsweise einen Systemspeicher oder Speicher 204. Die Modelldaten definieren jedes der Objekte, die auf einer Anzeige sichtbar sein können. Die Anwendung führt dann einen API-Aufruf an den Treiberkern durch, welcher anfordert, dass die Modelldaten gerendert und angezeigt werden. Der Treiberkern liest die Modelldaten und schreibt Befehle in einen oder mehrere Streams, um Operationen zur Verarbeitung der Modelldaten durchzuführen. Die Befehle können auf verschiedene Shaderprogramme verweisen, die auf den SMs 340 der PPU 200 implementiert werden sollen, einschließlich eines oder mehrerer Vertex-Shader, Hull-Shader, Domain-Shader, Geometrie-Shader und Pixel-Shader. So kann beispielsweise einer oder mehrere der SMs 340 konfiguriert werden, um ein Vertex-Shader-Programm auszuführen, das eine Anzahl von durch die Modelldaten definierten Vertices verarbeitet. In einer Ausführungsform können die verschiedenen SMs 340 konfiguriert werden, um verschiedene Shaderprogramme gleichzeitig auszuführen. So kann beispielsweise eine erste Teilmenge von SMs 340 konfiguriert werden, um ein Vertex-Shader-Programm auszuführen, während eine zweite Teilmenge von SMs 340 konfiguriert werden kann, um ein Pixel-Shader-Programm auszuführen. Die erste Teilmenge des SMs 340 verarbeitet Vertex-Daten, um verarbeitete Vertex-Daten zu erzeugen, und schreibt die verarbeiteten Vertex-Daten in den L2-Cache 360 und/oder den Speicher 204. Nachdem die verarbeiteten Vertexdaten gerastert wurden (d.h. von dreidimensionalen Daten in zweidimensionale Daten im Screenspace umgewandelt wurden), um Fragmentdaten zu erzeugen, führt die zweite Teilmenge der SMs 340 einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, die dann mit anderen verarbeiteten Fragmentdaten gemischt und in den Frame-Puffer im Speicher 204 geschrieben werden. Das Vertex-Shader-Programm und das Pixel-Shader-Programm können gleichzeitig ausgeführt werden und verschiedene Daten aus derselben Szene in einer Pipeline verarbeiten, bis alle Modelldaten für die Szene in den Frame-Puffer übertragen wurden. Anschließend wird der Inhalt des Frame-Puffers an eine Anzeigesteuerung zur Anzeige auf einer Anzeigevorrichtung übertragen.
5 ist ein konzeptionelles Diagramm einer Grafikverarbeitungspipeline 500, die von der PPU 200 aus 2 gemäß einer Ausführungsform implementiert wurde. Die Grafikverarbeitungspipeline 500 ist ein abstraktes Flussdiagramm der implementierten Verarbeitungsschritte zur Erzeugung von 2D-Computerbildern aus 3D-Geometriedaten. Wie bekannt ist, können Pipeline-Architekturen Operationen mit einer langen Latenz effizienter durchführen, indem sie die Operation in eine Vielzahl von Schritten bzw. Stufen aufteilen, wobei der Ausgang jeder Stufe mit dem Eingang der nächsten nachfolgenden Stufe gekoppelt ist. Somit empfängt die Grafikverarbeitungspipeline 500 Eingangsdaten 501, die von einer Stufe zur nächsten Stufe der Grafikverarbeitungspipeline 500 übertragen werden, um Ausgangsdaten 502 zu erzeugen. In einer Ausführungsform kann die Grafikverarbeitungspipeline 500 eine durch die OpenGL®-API definierte Grafikverarbeitungspipeline darstellen. Optional kann die Grafikverarbeitungspipeline 500 im Rahmen der Funktionalitäten und Architekturen der vorherigen Figuren und/oder jeder nachfolgenden Figur(en) implementiert werden.
Wie in 5 dargestellt ist, umfasst die Grafikverarbeitungspipeline 500 eine Pipelinearchitektur, die mehrere Stufen umfasst. Die Stufen beinhalten, sind aber nicht beschränkt auf, eine Datenmontagestufe 510, eine Vertex-Shading-Stufe 520, eine Primitiv-Montagestufe 530, eine Geometrie-Shading-Stufe 540, eine Viewport-Scale-, Cull- und Clip- (VSCC-)Stufe 550, eine Rasterungsstufe 560, eine Fragment-Shading-Stufe 570 und eine Rasteroperationsstufe 580. In einer Ausführungsform umfassen die Eingabedaten 501 Befehle, die die Verarbeitungseinheiten konfigurieren, um die Stufen der Grafikverarbeitungspipeline 500 und geometrische Primitive (z.B. Punkte, Linien, Dreiecke, Vierecke, Triangle Strips oder Dreiecksfächer, etc.) zu implementieren, die von den Stufen verarbeitet werden sollen. Die Ausgabedaten 502 können Pixeldaten (d.h. Farbdaten) umfassen, die in einen Frame-Puffer oder eine andere Art von Oberflächendatenstruktur in einem Speicher kopiert werden.
Die Datenmontagestufe 510 empfängt die Eingangsdaten 501, die Vertexdaten für Oberflächen hoher Ordnung, Primitive oder dergleichen spezifizieren. Die Datenmontagestufe 510 sammelt die Vertexdaten in einem Zwischenspeicher oder einer Warteschlange, beispielsweise durch Empfangen eines Befehls vom Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher enthält, und Lesen der Vertexdaten aus dem Puffer. Die Vertexdaten werden dann zur Verarbeitung an die Vertex-Shading-Stufe 520 übertragen.
Die Vertex-Shading-Stufe 520 verarbeitet Vertexdaten, indem sie eine Reihe von Operationen (z.B. einen Vertex-Shader oder ein Vertex-Programm) einmal für jeden der Vertices durchführt. Vertices können z.B. als 4-Koordinaten-Vektor (d.h. <x, y, z, w>) angegeben werden, der einem oder mehreren Vertexattributen (z.B. Farbe, Texturkoordinaten, Oberflächennormale, etc.) zugeordnet ist. Die Vertex-Shading-Stufe 520 kann einzelne Vertexattribute wie Position, Farbe, Texturkoordinaten und dergleichen verarbeiten. Mit anderen Worten, die Vertex-Shading-Stufe 520 führt Operationen an den Vertexkoordinaten oder anderen Vertexattributen durch, die einem Vertex zugeordnet sind. Solche Operationen beinhalten üblicherweise Beleuchtungsoperationen (d.h. das Ändern von Farbattributen für einen Vertex) und Transformationsoperationen (d.h. das Ändern des Koordinatenraums für einen Vertex). So können beispielsweise Vertices durch Koordinaten in einem Objektkoordinatenraum spezifiziert werden, die durch Multiplikation der Koordinaten mit einer Matrix transformiert werden, die die Koordinaten aus dem Objektkoordinatenraum in einen Wor-Idspace oder einen Raum normalisierter Gerätekoordinaten (Normalized Device Coordinate (NDC)) übersetzt. Die Vertex-Shading-Stufe 520 erzeugt transformierte Vertex-Daten, die an die Primitiv-Montage-Stufe 530 übertragen werden.
Die Primitiv-Montage-Stufe 530 sammelt die von der Vertex-Shading-Stufe 520 ausgegebenen Vertices und gruppiert die Vertices zu geometrischen Primitiven für die Verarbeitung durch die Geometrie-Shading-Stufe 540. So kann beispielsweise die Primitiv-Montage-Stufe 530 konfiguriert werden, um alle drei aufeinanderfolgenden Vertices als geometrisches Primitiv (d.h. ein Dreieck) zur Übertragung auf die Geometrie-Shading-Sstufe 540 zu gruppieren. In einigen Ausführungsformen können bestimmte Vertices für aufeinanderfolgende geometrische Primitive wiederverwendet werden (z.B. können zwei aufeinanderfolgende Dreiecke in einem Dreieckstreifen bzw. Triangle Strip zwei Vertices teilen). Die Primitiv-Montage-Stufe 530 überträgt geometrische Primitive (d.h. eine Sammlung von zugehörigen Vertices) an die Geometrie-Shading-Stufe 540.
Die Geometrie-Shading-Stufe 540 verarbeitet geometrische Primitive, indem sie eine Reihe von Operationen (d.h. einen Geometrie-Shader oder -Programm) auf den geometrischen Primitiven durchführt. Tessellierungsoperationen können aus jedem geometrischen Primitiv ein oder mehrere geometrische Primitive erzeugen. Mit anderen Worten, die Geometrie-Shading-Stufe 540 kann jedes geometrische Primitiv in ein feineres Netz von zwei oder mehr geometrischen Primitiven unterteilen, die zur Verarbeitung durch den Rest der Grafikverarbeitungspipeline 500 vorgesehen sind. Die Geometrie-Shading-Stufe 540 überträgt geometrische Primitive an die Viewport-SCC-Stufe 550.
In einer Ausführungsform kann die Grafikverarbeitungspipeline 500 innerhalb eines Streaming-Multiprozessors arbeiten und die Vertex-Shading-Stufe 520, die Primitiv-Montage-Stufe 530, die Geometrie-Shading-Stufe 540, die Fragment-Shading-Stufe 570 und/oder die damit verbundene Hard- und Software können sequentiell Verarbeitungsvorgänge durchführen. Sobald die sequentiellen Verarbeitungsvorgänge in einer Ausführungsform abgeschlossen sind, kann die Viewport-SCC-Stufe 550 die Daten verwenden. In einer Ausführungsform können Primitivdaten, die von einer oder mehreren Stufen der Grafikverarbeitungspipeline 500 verarbeitet werden, in einen Cache geschrieben werden (z.B. LI-Cache, Vertex-Cache, etc.). In diesem Fall kann die Viewport-SCC-Stufe 550 in einer Ausführungsform auf die Daten im Cache zugreifen. In einer Ausführungsform sind die Viewport-SCC-Stufe 550 und die Rasterungsstufe 560 als Schaltung fester Funktions implementiert.
Die Viewport-SCC-Stufe 550 führt die Skalierung, das Culling und das Clipping der geometrischen Primitive durch. Jede Oberfläche, auf die gerendert wird, ist mit einer abstrakten Kameraposition verbunden. Die Kameraposition stellt eine Position eines Betrachters dar, der die Szene betrachtet, und definiert ein Sichtvolumen, das die Objekte der Szene umschließt. Das Sichtvolumen kann eine Betrachtungsebene, eine hintere Ebene und vier Clipping-Ebenen beinhalten. Jedes geometrische Primitiv, das sich vollständig außerhalb des Sichtvolumens befindet, kann aussortiert (d.h. verworfen) werden, da das geometrische Primitiv nicht Teil der endgültigen gerenderten Szene ist. Jedes geometrische Primitiv, das sich teilweise innerhalb des Sichtvolumens und teilweise außerhalb des Sichtvolumens befindet, kann abgeschnitten werden (d.h. in ein neues geometrisches Primitiv umgewandelt werden, das innerhalb des Sichtvolumens eingeschlossen ist). Darüber hinaus können geometrische Primitive jeweils auf der Grundlage einer Tiefe des Sichtvolumens skaliert werden. Alle potenziell sichtbaren geometrischen Primitive werden dann an die Rasterstufe 560 übertragen.
Die Rasterstufe 560 wandelt die geometrischen 3D-Primitive in 2D-Fragmente um (z.B. darstellbar, etc.). Die Rasterungsstufe 560 kann konfiguriert werden, um die Vertices der geometrischen Primitive zu nutzen, um einen Satz von Ebenengleichungen aufzubauen, aus denen verschiedene Attribute interpoliert werden können. Die Rasterungsstufe 560 kann auch eine Abdeckungsmaske für eine Vielzahl von Pixeln berechnen, die angibt, ob eine oder mehrere Samplepositionen für das Pixel das geometrische Primitiv schneidet. In einer Ausführungsform kann auch ein Z-Test durchgeführt werden, um zu bestimmen, ob das geometrische Primitiv durch andere geometrische Primitive, die bereits gerastert wurden, verdeckt wird. Die Rasterstufe 560 erzeugt Fragmentdaten (d.h. interpolierte Vertexattribute, die einem bestimmten Sample-Standort für jedes abgedeckte Pixel zugeordnet sind), die an die Fragment-Shading-Stufe 570 übertragen werden.
Die Fragment-Shading-Stufe 570 verarbeitet Fragment-Daten, indem sie eine Reihe von Operationen (d.h. einen Fragment-Shader oder ein -Programm) auf jedem der Fragmente durchführt. Die Fragment-Shading-Stufe 570 kann Pixeldaten (d.h. Farbwerte) für das Fragment erzeugen, z.B. durch Beleuchtungsoperationen oder Abtasten von Texturkarten unter Verwendung interpolierter Texturkoordinaten für das Fragment. Die Fragment-Shading-Stufe 570 erzeugt Pixeldaten, die an die Rasteroperations-Stufe 580 übertragen werden.
Die Rasteroperations-Stufe 580 kann verschiedene Operationen mit den Pixeldaten durchführen, wie z.B. Alpha-Tests, Schablonentests und das Mischen der Pixeldaten mit anderen Pixeldaten, die anderen dem Pixel zugeordneten Fragmenten entsprechen. Wenn die Rasteroperations-Stufe 580 die Verarbeitung der Pixeldaten (d.h. der Ausgabedaten 502) abgeschlossen hat, können die Pixeldaten in ein Render-Target, wie einen Frame-Puffer, einen Farbpuffer oder dergleichen, geschrieben werden.
Es wird darauf hingewiesen, dass neben oder anstelle einer oder mehrerer der oben beschriebenen Stufen eine oder mehrere zusätzliche Stufen in die Grafikverarbeitungspipeline 500 aufgenommen werden können. Verschiedene Implementierungen der abstrakten Grafikverarbeitungspipeline können verschiedene Phasen implementieren. Darüber hinaus kann in einigen Ausführungsformen (z. B. der Geometrie-Shading-Stufe 540) eine oder mehrere der vorstehend beschriebenen Stufen von der Grafikverarbeitungspipeline ausgeschlossen werden. Andere Arten von Grafikverarbeitungspipelines werden als im Rahmen der vorliegenden Offenbarung betrachtet. Darüber hinaus kann jede der Stufen der Grafikverarbeitungspipeline 500 durch eine oder mehrere dedizierte Hardwareeinheiten innerhalb eines Grafikprozessors wie der PPU 200 implementiert werden. Weitere Stufen der Grafikverarbeitungspipeline 500 können durch programmierbare Hardwareeinheiten wie den SM 340 der PPU 200 realisiert werden.
Die Grafikverarbeitungspipeline 500 kann über eine Anwendung implementiert werden, die von einem Host-Prozessor, wie beispielsweise einer CPU, ausgeführt wird. In einer Ausführungsform kann ein Gerätetreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, die verschiedene Funktionen definiert, die von einer Anwendung verwendet werden können, um grafische Daten für die Anzeige zu erzeugen. Der Gerätetreiber ist ein Softwareprogramm, das eine Vielzahl von Anweisungen enthält, die den Betrieb der PPU 200 steuern. Die API bietet eine Abstraktion für einen Programmierer, die es einem Programmierer ermöglicht, spezielle Grafikhardware wie die PPU 200 zu verwenden, um die grafischen Daten zu erzeugen, ohne dass der Programmierer den spezifischen Befehlssatz für die PPU 200 verwenden muss. Die Anwendung kann einen API-Aufruf beinhalten, der an den Gerätetreiber für die PPU 200 weitergeleitet wird. Der Gerätetreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu reagieren. In einigen Fällen kann der Gerätetreiber Operationen ausführen, indem er Anweisungen auf der CPU ausführt. In anderen Fällen kann der Gerätetreiber zumindest teilweise Operationen durchführen, indem er Operationen auf der PPU 200 über eine Ein-/Ausgabeschnittstelle zwischen der CPU und der PPU 200 startet. In einer Ausführungsform ist der Gerätetreiber konfiguriert, um die Grafikverarbeitungspipeline 500 unter Verwendung der Hardware der PPU 200 zu implementieren.
Innerhalb der PPU 200 können verschiedene Programme ausgeführt werden, um die verschiedenen Stufen der Grafikverarbeitungspipeline 500 zu realisieren. So kann beispielsweise der Gerätetreiber einen Kernel auf der PPU 200 starten, um die Vertex-Shading-Stufe 520 auf einem SM 340 (oder mehreren SMs 340) durchzuführen. Der Gerätetreiber (oder der Ausgangskernel (initial kernel), der von der PPU 300 ausgeführt wird) kann auch andere Kernel auf der PPU 300 starten, um andere Stufen der Grafikverarbeitungspipeline 500 auszuführen, wie z.B. die Geometrie-Shading-Stufe 540 und die Fragment-Shading-Stufe 570. Darüber hinaus können einige der Stufen der Grafikverarbeitungspipeline 500 auf Einheiten mit fester Hardware wie einem Rasterizer oder einem innerhalb der PPU 300 implementierten Datenassembler implementiert werden. Es ist zu beachten, dass die Ergebnisse eines Kernels von einer oder mehreren dazwischenliegenden Hardwareeinheiten mit fester Funktion verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einem SM 340 verarbeitet werden.
Maschinelles Lernen
Tiefe neuronale Netze (DNNs), die auf Prozessoren wie der PPU 200 entwickelt wurden, wurden für verschiedene Anwendungsfälle eingesetzt, von selbstfahrenden Autos bis hin zu schnellerer Medikamentenentwicklung, von einem automatisch mit einer Bildüberschrift versehenen Bild in Online-Bilddatenbanken bis hin zur intelligenten Echtzeit-Sprachübersetzung in Video-Chat-Anwendungen. Deep Learning ist eine Technik, die den neuronalen Lernprozess des menschlichen Gehirns modelliert, kontinuierlich lernt, kontinuierlich intelligenter wird und im Laufe der Zeit schnellere und genauere Ergebnisse liefert. Ein Kind wird zunächst von einem Erwachsenen gelehrt, verschiedene Formen richtig zu identifizieren und zu klassifizieren, um schließlich ohne Coaching Formen identifizieren zu können. Ebenso muss ein System eines Deep Learning oder eines neuronalen Lernens in der ObjektErkennung und -Klassifizierung trainiert werden, damit es intelligenter und effizienter grundlegende Objekte, abgedeckte Objekte usw. identifizieren und gleichzeitig den Objekten Kontext zuweisen kann.
Auf dem einfachsten Niveau betrachten Neuronen im menschlichen Gehirn verschiedene Eingaben, die empfangen werden, wobei jedem dieser Eingaben Wichtigkeitsstufen zugewiesen werden, und wobei die Ausgabe an andere Neuronen weitergeleitet wird, damit diese darauf zu reagieren. Ein künstliches Neuron oder Perzeptron ist das grundlegendste Modell eines neuronalen Netzes. In einem Beispiel kann ein Perzeptron eine oder mehrere Eingaben empfangen, die verschiedene Merkmale eines Objekts darstellen, für die das Perzeptron trainiert wird, um sie zu erkennen und zu klassifizieren, und jedem dieser Merkmale wird ein bestimmtes Gewicht zugewiesen, das auf der Bedeutung dieses Merkmals für die Definition der Form eines Objekts basiert.
Ein DNN-Modell (Deep Neural Network) beinhaltet mehrere Schichten vieler verbundener Perzeptronen (z.B. Knoten), die mit enormen Mengen an Eingabedaten trainiert werden können, um komplexe Probleme schnell und mit hoher Genauigkeit zu lösen. In einem Beispiel zerlegt eine erste Schicht des DLL-Modells ein Eingabebild eines Autos in verschiedene Abschnitte und sucht nach Grundmustern wie Linien und Winkeln. Die zweite Schicht setzt die Linien zusammen, um nach Mustern höherer Ebene wie Rädern, Windschutzscheiben und Spiegeln zu suchen. Die nächste Schicht identifiziert den Fahrzeugtyp, und die letzten paar Schichten erzeugen ein Label für das Eingangsbild, das das Modell einer bestimmten Automobilmarke identifiziert.
Sobald das DNN trainiert ist, kann das DNN eingesetzt und verwendet werden, um Objekte oder Muster in einem Prozess zu identifizieren und zu klassifizieren, was als Folgerung bezeichnet wird. Beispiele für Folgerungen (der Prozess, durch den ein DNN nützliche Informationen aus einer gegebenen Eingabe extrahiert) beinhalten das Identifizieren von handschriftlichen Zahlen bei Schecks, die in Geldautomaten hinterlegt sind, das Identifizieren von Bildern von Freunden auf Fotos, das Liefern von Filmempfehlungen an über fünfzig Millionen Benutzer, das Identifizieren und Klassifizieren verschiedener Arten von Autos, Fußgängern und Straßengefahren in fahrerlosen Autos oder das Übersetzen menschlicher Sprache in Echtzeit.
Während des Trainings fließen die Daten in einer Vorwärtsausbreitungsphase durch das DNN, bis eine Vorhersage erstellt wird, die auf ein Label hinweist, das der Eingabe entspricht. Wenn das neuronale Netz die Eingabe nicht korrekt kennzeichnet, werden Fehler zwischen der richtigen Bezeichnung und der vorhergesagten Kennzeichnung analysiert und die Gewichte für jedes Merkmal während einer Rückwärtsausbreitungsphase angepasst, bis das DNN die Eingabe und andere Eingaben in einem Trainingsdatensatz korrekt kennzeichnet. Das Training komplexer neuronaler Netze erfordert enorme Mengen an paralleler Rechenleistung, einschließlich Gleitkomma-Multiplikationen und Additionen, die von der PPU 200 unterstützt werden. Die Folgerung ist weniger rechenintensiv als das Training, da es sich um einen latenzsensitiven Prozess handelt, bei dem ein trainiertes neuronales Netz auf neue Eingaben angewendet wird, die es bisher noch nicht gegeben hat, um Bilder zu klassifizieren, Sprache zu übersetzen und generell neue Informationen abzuleiten.
Neuronale Netze sind stark auf mathematische Matrixoperationen angewiesen, und komplexe mehrschichtige Netze erfordern enorme Mengen an Gleitkommaleistung und Bandbreite für Effizienz und Geschwindigkeit. Mit Tausenden von Rechenkernen, optimiert für Matrix-Mathematik-Operationen, und Hunderten von TFLOPS an Leistung, ist die PPU 200 eine Computerplattform, die in der Lage ist, die für auf tiefe neuronale Netze basierende künstliche Intelligenz und maschinelle Lernanwendungen erforderliche Leistung zu liefern.
Massiv parallele Path-Space-Filterung
Während die Suche nach benachbarten Vertices teurer ist als die Filterung im Screenspace, werden diese Leistungseinbußen erheblich verbessert, indem die benötigten Informationen in einer Hash-Tabelle gespeichert und nachgeschlagen werden. Die Schlüssel sind aus durch Jittering erzeugten und quantisierten Informationen aufgebaut, so dass nur eine einzige Abfrage sehr wahrscheinlich kostspielige Nachbarschaftssuchen ersetzt. Eine massiv parallele Implementierung des Algorithmus wird auf einer GPU demonstriert.
Einführung
Eine realistische Bildsynthese besteht aus einer hochdimensionalen numerischen Integration von Funktionen mit potenziell hoher Varianz. Die Beschränkung der Anzahl der Samples führt daher oft zu sichtbarem Rauschen, das durch die Path-Space-Filterung effizient reduziert werden kann.
Die Leistung der Path-Space-Filterung wird verbessert, indem die teure Nachbarschaftssuche durch Durchschnittswerte von Clustern ersetzt wird, die sich aus der Quantisierung ergeben. Der neue Algorithmus eignet sich für ein interaktives Rendering und sogar für Echtzeit-Rendering und ermöglicht vielen Anwendungen, eine steuerbare Verzerrung (Bias) gegen eine dramatische Beschleunigung und Rauschunterdrückung einzutauschen.
Algorithmus
Das neue Schema kann drei Schritte umfassen: Nachdem eine Reihe von Lichttransportpfaden erzeugt wurde, z.B. von einem Path-Tracer, wird für jeden ausgewählten Vertex eines jeden Pfades ein Schlüssel konstruiert. Dieser Schlüssel enthält alle Informationen, die benötigt werden, um benachbarte Vertices in einem Cluster zu gruppieren: Alle Beiträge mit identischen Hashwerten werden atomar addiert. Die Anzahl der Beiträge pro Hashwert wird ebenfalls von einem AtomicCounter gehalten und zur endgültigen Berechnung des durchschnittlichen Beitrags verwendet. Für jeden Pfad wird der zugehörige Mittelwert mit seinem Durchsatz multipliziert und in seinem jeweiligen Pixel akkumuliert. Der Durchsatz ist die Dämpfung von der Kamera entlang des Lichttransportpfads bis zum ausgewählten Vertex, z.B. dem ersten ausreichend diffusen Vertex.
6A veranschaulicht einen ersten Schritt 610 zum Durchführen einer parallelen Path-Space-Filterung durch Hashing gemäß einer Ausführungsform. Wie es in 6A dargestellt ist, werden zur Bestimmung des gefilterten Beitrags für einen exemplarischen Vertex 602 entlang eines Pfadsegments 604 alle ausgewählten Vertices durch Vektoren einem Jittering unterzogen, die proportional zu einer Filterkerndichte abgetastet werden. 6B veranschaulicht einen zweiten Schritt 620 zum Durchführen einer parallelen Path-Space-Filterung durch Hashing, wobei die einem Jittering unterzogenen Vertices dargestellt sind. Die verschobenen Vertices können entsprechend dem darunter liegenden Gitter 606 quantisiert werden. 6C veranschaulicht einen dritten Schritt 630 zur Durchführung einer parallelen Path-Space-Filterung durch Hashing, bei dem alle Beiträge mit einem Hashwert, der mit dem Hashwert des interessierenden Vertex identisch ist, gemittelt werden. In einer Ausführungsform kann das Gitter nicht zu der Ebene der Jitter- bzw. Zitter-Richtungen ausgerichtet sein.
Hashing quantisierter Deskriptoren
Anders als die Nachbarschaftssuche ermöglicht das Hashing das Sortieren und Suchen in linearer Zeit. Es wird daher eine schnelle Hash-Funktion auf einen Schlüssel angewendet, der der Deskriptor eines Pfades ist, und die Beiträge aller Lichttransportpfade mit identischen Hashwerten werden aufgesammelt.
7 veranschaulicht die Ergebnisse 702 des Akkumulierens der Beiträge aller Lichttransportpfade mit identischen Hashwerten nach einer exemplarischen Ausführungsform. Wie in 7 dargestellt ist, wird anstelle der Suche in einer n³-Nachbarschaft 704 die aus der Quantisierung resultierende Clustergruppierung verwendet, um Beiträge zu akkumulieren, was ein einmaliges Nachschlagen ermöglicht.

Tabelle 1 enthält einen exemplarischen Algorithmus für die Berechnung der beiden für ein Nachschlagen verwendeten Hashwerte gemäß einer Ausführungsform. Es ist natürlich zu beachten, dass der in Tabelle 1 dargestellte Algorithmus nur zur Veranschaulichung dargelegt ist und daher nicht als Einschränkung ausgelegt werden sollte. Es ist zu beachten, dass die Argumente einer Hash-Funktion, die den Deskriptor bilden, erweitert werden können, um die Clustergruppierung zu verfeinern. Tabelle 1

Input: Location x ofthe vertex, the normal n, the position of the camera p_cam, and the scale s.

Output: Hash i to determine the position in the hash table and hash υ for verification.

l ← level_of_detail (|p_cam -x|)

x' ← x+ jitter(n) · s · 2^l

l' ← level_of_detail(|p_cam - x'|)

\tilde{x} \leftarrow ⌊ \frac{x'}{s \cdot 2^{l'}} ⌋

i ← hash(x̃, ...)

v ← hash2 (x̃, n,...)

Ein Deskriptor enthält mindestens die quantisierte Worldspace-Position eines ausgewählten Vertex eines Lichttransportpfades. Wie in Tabelle 1 dargestellt ist, kann der Detaillierungsgrad auch vom Deskriptor effizient behandelt werden: Eine Heuristik, die so einfach ist wie die Entfernung d entlang des Pfades, reicht aus, um einen Detaillierungsgrad für das Akkumulieren auszuwählen. Das Hinzufügen von Informationen über die Normale an dieser Stelle vermeidet eine verschwommene Beleuchtung an den Kanten. Darüber hinaus können die Einfallsrichtung für nicht-diffuse Materialien und die Schichtkennung für geschichtete Materialien in den Deskriptor aufgenommen werden.
Anstatt die ziemlich langen Deskriptoren für die Hash-Verifikation zu speichern und zu vergleichen, wird eine zweite, andere Hash-Funktion auf denselben Deskriptor angewendet und ein Beitrag nur akkumuliert, wenn die zweiten Hashwerte v übereinstimmen, siehe Tabelle 1. Um die Belegung in der Hash-Tabelle zu erhöhen, kann bei einer Hashwert-Kollision ein lineares Suchen mit sehr wenigen Schritten eingesetzt werden. Da das lineare Suchen darauf beschränkt ist, innerhalb einer Cache-Zeile zu bleiben, ist die Kollisionsauflösung bei modernen Architekturen nahezu vernachlässigbar. Sofern eine Hash-Kollision nicht gelöst werden kann, wird auf den ungefilterten ursprünglichen Beitrag des Pfades zurückgegriffen.
Darüber hinaus kann das lineare Suchen verwendet werden, um Attribute des Lichttransportpfades in einem feineren Detaillierungsgrad zu unterscheiden: So kann beispielsweise eine Normaleninformation in dem Deskriptor vorhanden sein, der an die Verifizierungs-Hash-Funktion übergeben wird, anstatt diese bereits in den Haupt-Deskriptor aufzunehmen. Dies ermöglicht die Suche nach ähnlichen Normalen durch das lineare Suchen.
8 veranschaulicht die Verwendung des linearen Suchens, um die Attribute eines Lichttransportpfades auf einem feineren Detaillierungsgrad nach einer exemplarischen Ausführungsform zu unterscheiden. Wie in 8 dargestellt ist, kann die Verifikations-Hash-Funktion, anstatt die Normalen 802A-C in den Deskriptor aufzunehmen, wie in 804 dargestellt, um Beiträge zu differenzieren, deren Vertices in das gleiche Cluster fallen würden, wie in 806 gezeigt, auf einen Deskriptor angewendet werden, der die Normalen-Informationen enthält. Dies ermöglicht es, die Normalen-Informationen bei dem linearen Suchen zu unterscheiden, wie es in 808 dargestellt ist. Als Referenz enthält 8 auch eine Darstellung der Normalen 802A-C, die sich aus einem Voxel 810 ergeben, das sich aus der Quantisierung ergibt.
Filterkernapproximierung durch Jittering
Die Diskontinuitäten der Quantisierung können durch Jittering von Schlüsselparametern im Pfaddeskriptor beseitigt werden, was in der Tat einer Annäherung an einen Filterkern durch Abtasten gleichkommen kann. Das Jittering hängt von der Art des Deskriptorparameters ab, z.B. können Positionen in der Tangentialebene eines Schnittpunktes einem Jittering unterzogen worden sein, siehe Tabelle 1. Das resultierende Rauschen wird gegenüber den sichtbaren Diskretisierungsartefakten aus der Quantisierung bevorzugt. Im Gegensatz zu Diskretisierungsartefakten ist das durch Jittering erzeugte Rauschen einfach zu filtern.
9 veranschaulicht, dass der Detaillierungsgrad einer mittels Jittering erzeugten Position 902A-B von dem Detaillierungsgrad einer ursprünglichen Position 904 abweichen kann.
Akkumulation über der Zeit
Das Akkumulieren von Beiträgen über der Zeit erhöht die Effizienz drastisch. Bei statischen Szenen konvergieren die Mittelwerte. In dynamischen Umgebungen ist das aktuell Halten von zwei gemittelten Beitragssätzen und deren Kombination mit einem exponentiellen gleitenden Mittelwert c = α·c_old+(1-α)·c_new ein üblicher Kompromiss zwischen Konvergenz und zeitlicher Anpassungsfähigkeit. Große Änderungen auch bei Hashwerten mit einer großen Anzahl von alten Beiträgen können über den Parameter α gesteuert werden.
Die Kombination der Mittelwerte c_old und c_neu durch einen exponentiellen Mittelwert kann jedoch nicht mit einer zeitlichen Integration gleichgesetzt werden. Insbesondere Mittelwerte von Hashwerten mit relativ wenigen Samples können nicht konvergieren. In diesem Fall kann es vorteilhaft sein, Samples über der Zeit bis zu einem gewissen Grad zu akkumulieren. Dies kann mit einem festen Schwellenwert für die Anzahl der Samples und mit einem Akkumulieren der Samples über der Zeit, bis dieser erreicht wird, erfolgen. Im gleichen Sinne kann α von der Anzahl der Samples abhängen, wiederum mit einer oberen Grenze, um eine zeitliche Reaktionsfähigkeit zu gewährleisten.
Verdrängungsstrategie
Das Verdrängen von Beiträgen von Hashwerten, die über einen bestimmten Zeitraum nicht abgefragt wurden, kann bei größeren Szenen- und Kamerawechseln notwendig sein. Neben der Verdrängungsstrategie (LRU (Least Recently Used)), dass derjenige verdrängt wird, dessen Verwendung am längsten zurückliegt, können Heuristiken, die auf längerfristigen Beobachtungen basieren, effizient sein.
Eine sehr einfache Implementierung kann sich darauf verlassen, dass die höchstwertigsten Bits des Verifikationshashwertes durch eine Priorität ersetzt werden, die sich beispielsweise aus der Vertexdichte und der Zeit des letzten Zugriffs während der zeitlichen Filterung zusammensetzt. So garantieren die pseudozufällig gehashten niederwertigsten Bits, dass fehlende Beiträge gleichmäßig über die Szene verteilt sind, während die höchstwertigsten Bits dafür sorgen, dass Beiträge nach Priorität verdrängt werden. Dies ermöglicht es, die Kollisionsbehandlung und die Verdrängung durch eine einzige atomicMin-Operation zu realisieren.
Aufgrund von Kamerabewegungen oder anderen Parametern, die im Laufe der Zeit Hashwerte ändern, kann es vorkommen, dass eine kleine Anzahl von alten Beiträgen nicht mehr gefunden wird. Auch wenn Jittering Diskontinuitäten aufgrund dieser Änderungen verbergen kann, kompensiert es nicht den erheblichen Qualitätsverlust aufgrund der reduzierten Anzahl gemittelter Samples. Daher kann in diesen seltenen Fällen eine zusätzliche Nachbarschaftssuche durchgeführt werden. Ein ähnliches Problem kann für Teile der Szene auftreten, die nicht viele andere Beiträge mit identischen Hashwerten aufweisen.
Ergebnisse und Diskussion
Während das Filtern von Beiträgen an primären Schnittpunkten mit dem vorgeschlagenen Algorithmus recht schnell ist, entfernt es nur einige Artefakte des Filterns im Screenspace. Die gehashte Path-Space-Filterung ist jedoch so konzipiert, dass sie auf eine Echtzeit-Lichttransportsimulation abzielt: Es ist der einzige effiziente Fallback, wenn die Screenspace-Filterung fehlschlägt oder nicht verfügbar ist, z.B. für spiegelnde oder transparente Objekte. Die Filterung von nicht-diffusen Oberflächen erfordert die Aufnahme zusätzlicher Parameter in den Pfaddeskriptor und die Heuristiken, wie z.B. die Erhöhung der Quantisierungsauflösung in Bereichen mit nicht-diffusen Materialien, um die sichtbaren Artefakte zu minimieren.
In einer Ausführungsform können Artefakte durch den Einsatz einer oder mehrerer Heuristiken verbessert werden. Das Filtern von primären Schnittpunkten verdoppelt die Leistungsfähigkeit aufgrund der kohärenteren Speicherzugriffsmuster.
Die Bildqualität kann durch die Filtergröße bestimmt werden, die Rauschen und Unschärfe ausgleicht. Sowohl die Anzahl der Kollisionen in der Hash-Tabelle als auch die Performance der Filterung können von der Größe der Voxel abhängen. So kann beispielsweise die Voxelgröße mit dem s-fachen der projizierten Größe eines Pixels angegeben sein. Es sei angemerkt, dass die maximale Leistungsfähigkeit nicht unbedingt mit der besten Bildqualität übereinstimmen muss. Die Größe der Hash-Tabelle kann proportional zur Anzahl der Pixel bei Zielauflösung gewählt werden, so dass potenziell ein Vertex pro Pixel gespeichert werden kann.
Anstatt den ersten ausreichend diffusen Vertex entlang eines Pfades von der Kamera auszuwählen, kann die Path-Space-Filterung an jedem Vertex angewendet werden. So kann beispielsweise das Filtern am zweiten ausreichend diffusen Vertex der Endfassung oder lokale Durchläufen gleichen. Tatsächlich kann die Path-Space-Filterung eine Varianzreduzierung mit einem gesteuerten Bias bewirken und ist orthogonal zu anderen Filtertechniken. Temporäres Antialiasing und ergänzende Rauschfilter im Screenspace können das Rauschen weiter reduzieren. Ein lokaler Glättungsfilter kann helfen, den Fehler in der Approximation zu reduzieren.
Fazit
Die Path-Space-Filterung kann auf der Grundlage weniger Synchronisierungen während der Akkumulation auf Hash-Skalen auf massiv paralleler Hardware basieren. Abfragen können in konstanter Zeit ausgeführt werden, und es ist dafür weder die Traversierung noch der Aufbau einer hierarchischen räumlichen Datenstruktur zur Beschleunigung erforderlich. Daher wird der Algorithmus nur durch die Leistungsfähigkeit des Raytracings eingeschränkt.
Der vereinfachte Algorithmus überwindet viele Einschränkungen der Screenspace-Filterung, benötigt keine Bewegungsvektoren und ermöglicht die Rauschunterdrückung über den ersten Schnittpunkt hinaus, wobei spiegelnde und transparente Oberflächen eingeschlossen sind.
In einer Ausführungsform können wichtige Hashwerte von der Verdrängung ausgeschlossen werden, indem der Detaillierungsgrad reduziert wird, d.h. ihre Beiträge auf einem gröberen Niveau akkumuliert werden. Das Gleiche würde für Zellen mit nur wenigen Beiträgen funktionieren. Abgesehen von der Auswahl eines Detaillierungsgrades anhand der Länge des Pfades können Pfaddifferenzen und Varianz verwendet werden, um die geeignete Auflösung zu bestimmen.
Dieses adaptive Hashing-Schema kann für Path-Space-Filterung, Multiview-Rendering, Spektral-Rendering, partizipierende Medien, Entkopplung von Anti-Aliasing und Shading, Photonen-Mapping, Strahlungsproben zur Verstärkung bei der Probennahme bei erlernter Wichtigkeit, unter Umständen in Kombination mit dem Endaufsammeln zur Speicherung von Strahlungsproben, usw. verwendet werden.
Obwohl verschiedene Ausführungsformen vorstehend beschrieben wurden, sollte man verstehen, dass sie nur als Beispiel und nicht als Einschränkung dargestellt werden. Daher sollte die Breite und der Umfang einer bevorzugten Ausführungsform nicht durch eine der oben beschriebenen exemplarischen Ausführungsformen eingeschränkt werden, sondern nur in Übereinstimmung mit den folgenden Ansprüchen und ihren Entsprechungen definiert werden.

Claims

Verfahren umfassend: Auswählen eines Vertex eines Lichttransportpfades; Quantisieren von einem oder von mehreren Merkmalen des ausgewählten Vertex; Berechnen eines ersten Hashwerts abhängig von dem einen oder von den mehreren quantisierten Merkmalen des ausgewählten Vertex; Ausführen einer Kollisionsauflösung in einer Hash-Tabelle; Akkumulieren eines Beitrags des Lichttransportpfades bei dem ausgewählten Vertex zu der Hash-Tabelle; Inkrementieren eines Zählers abhängig von einem Hinzufügen des Beitrags des Lichttransportpfads bei dem ausgewählten Vertex zu der Hash-Tabelle; und Berechnen eines mittleren Beitrags des Lichttransportpfades unter Verwendung des Zählers.
Verfahren nach Anspruch 1, wobei der ausgewählte Vertex einem Jittering unterzogen wird, bevor das eine oder die mehreren Merkmale des ausgewählten Vertex quantisiert werden, und wobei das Jittering gemäß einer ausgewählten Verteilung ausgeführt wird.
Verfahren nach Anspruch 2, wobei das Jittering in einer Tangentialebene einer Oberfläche ausgeführt wird, auf welcher der Vertex angeordnet ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der ausgewählte Vertex mit einer Mehrzahl von weiteren Vertices in einem Volumen gespeichert wird, und wobei alle Vertices, welche in dem Volumen gespeichert sind, einem Jittering unterzogen sein können.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Quantisieren des einen oder der mehreren Merkmale des ausgewählten Vertex gleich ausgeführt wird, wobei das Quantisieren des einen oder der mehreren Merkmale des ausgewählten Vertex abhängig von einem Abstand des ausgewählten Vertex von einer Kamera ausgeführt wird, wobei das Quantisieren des einen oder der mehreren Merkmale des ausgewählten Vertex abhängig von einer Länge eines Pfadsegments ausgeführt wird, oder wobei das Quantisieren des einen oder der mehreren Merkmale des ausgewählten Vertex abhängig von einer Heuristik ausgeführt wird, welche auf einer Verteilung und einer lokalen Dichte von mehreren Vertices basiert.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Ausführen der Kollisionsauflösung in der Hash-Tabelle aufweist: Erfassen von einer oder von mehreren Kollisionen, indem das eine oder die mehreren quantisierten Merkmale des ausgewählten Vertex mit einem oder mit mehreren quantisierten Merkmalen von weiteren Vertices verglichen werden, oder Erfassen von einer oder von mehreren Kollisionen, indem ein zweiter Satz von Merkmalen des ausgewählten Vertex quantisiert wird, ein zweiter Hashwert abhängig von dem zweiten Satz der quantisierten Merkmale berechnet wird, und der zweite Hashwert des ausgewählten Vertex mit einem oder mit mehreren zweiten Hashwerten der weiteren Vertices verglichen wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der eine oder die mehreren akkumulierten Beiträge und kein oder mehrere Zähler für Vertices von Pfaden innerhalb einer Szene während einer Simulation nachgeschlagen werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Quantisieren des einen oder der mehreren Merkmale des ausgewählten Vertex lokal bestimmt wird, und wobei eine lokale Quantisierungsauflösung bestimmt wird, indem die wechselseitige Sichtbarkeit von ausgewählten Vertices von verschiedenen Lichttransportpfaden in einer Szene überprüft wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das eine oder die mehreren Merkmale des ausgewählten Vertex während der Berechnung des ersten Hashwerts ausgeschlossen werden, wobei die ausgeschlossenen Merkmale bei einer Berechnung eines zweiten Hashwerts eingeschlossen werden, und wobei eine weitere Suche ermöglicht wird, indem eine Kollisionsauflösung durchgeführt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei ein exponentieller gleitender Mittelwert implementiert wird, um Beiträge für den Lichttransportpfad über der Zeit zu akkumulieren, wobei eine Summe von Beiträgen von allen Lichttransportpfaden mit dem ersten Hashwert wie auch der Zähler über eine Zeitperiode gehalten werden und mit einem mittleren Beitrag des Lichttransportpfades für eine aktuelle Zeitperiode kombiniert werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei ein vorbestimmter Parameter eines exponentiellen gleitenden Mittelwerts gesetzt wird, so dass der exponentielle gleitende Mittelwert ein kumulativer gleitender Mittelwert wird.
Verfahren nach Anspruch 11, wobei der vorbestimmte Parameter ausgewählt wird abhängig von: Ergebnissen einer Pathtracing-Simulation, oder einer Auswertung weiterer Lichttransportpfade.
Verfahren nach Anspruch 12, wobei der exponentielle gleitende Mittelwert abhängig von einer Information von der Pathtracing-Simulation gesteuert wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei ein zusätzliches Filter eingesetzt wird, um ein Rauschen, welches sich von dem Jittering ergibt, zu filtern.
Verfahren nach Anspruch 14, wobei das zusätzliche Filter in einem Zeitbereich arbeitet, und wobei das zusätzliche Filter einen exponentiellen gleitenden Mittelwert einsetzt.
Verfahren nach Anspruch 15, wobei ein Parameter des exponentiellen gleitenden Mittelwerts gesetzt wird, so dass der exponentielle gleitende Mittelwert ein kumulativer gleitender Mittelwert wird.
Verfahren nach Anspruch 15, wobei der exponentielle gleitende Mittelwert abhängig von einer Information von einer Pathtracing-Simulation gesteuert wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Vertex von einem Pfad von einer Lichtquelle ausgewählt wird, wobei weitere Vertices von einem Pfad von einer Kamera- / Augen-Position ausgewählt werden, und wobei ein Skalieren durch ein entsprechendes Flächenmaß als Teil einer Photon-Mapping-Operation ausgeführt wird.
System umfassend: einen Prozessor, welcher ausgestaltet ist, um ein Verfahren nach einem der Ansprüche 1 bis 18 auszuführen.
Von einem Computer lesbares Speichermedium, welches Instruktionen speichert, welche, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor Schritte eines Verfahrens nach einem der Ansprüche 1 bis 18 ausführt.