DE102019109757A1

DE102019109757A1 - Hinzufügen von mehr realismus zu einem von einem computergenerierten bild durch glätten von gezackten kanten

Info

Publication number: DE102019109757A1
Application number: DE102019109757.6A
Authority: DE
Inventors: Morgan McGuire; Josef B. Spjut; Adam Christopher Marrs; Holger Heinrich Gruen; Rahul Sathe
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2018-04-12
Filing date: 2019-04-12
Publication date: 2019-10-17
Also published as: US20210398253A1

Abstract

Während des Rendern eines Bildes werden bestimmte Pixel in dem Bild identifiziert, bei welchen Anti-Aliasing hilfreich wäre. Ein Anti-Aliasing wird dann auf diesen identifizierten Pixeln ausgeführt, wobei das Anti-Aliasing eine Technik ist, welche eingesetzt wird, um einen größeren Realismus einem digitalen Bild hinzuzufügen, indem gezackte Kanten geglättet werden. Dies reduziert Kosten der Durchführung des Anti-Aliasing, indem eine Anzahl von Pixeln innerhalb eines Bildes reduziert wird, auf welchen das Anti-Aliasing ausgeführt wird.

Description

BEREICH DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf das Rendern von Bildern, und insbesondere auf die Durchführung von Anti-Aliasing während des Rendern von Bildern.
HINTERGRUND
Anti-Aliasing wird häufig während des Renderns einer Szene verwendet, um Bildartefakte zu entfernen, die durch unzureichende Abtastraten entstehen. Die derzeitigen Verfahren zur Durchführung von Anti-Aliasing verursachen jedoch hohe Speicherkosten und können in bestimmten Situationen unter hohen Bandbreiten leiden. Darüber hinaus können die aktuellen Techniken zur Durchführung von Anti-Aliasing mit verzögertem Rendern von komplexen Geometrien mit Grafikhardware kompliziert sein und mehrere Rendering-Durchläufe über eine Szene erfordern.
Figurenliste

1 stellt ein Flussdiagramm eines Verfahrens zum Durchführen einer komplexen Pixelidentifikation zur Verbesserung des Anti-Aliasing von von einem Computer generierten Bildern 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 der 3A gemäß einer Ausführungsform dar.
4B ist eine konzeptionelle Darstellung eines Verarbeitungssystems, das unter Verwendung der PPU der 2 gemäß einer Ausführungsform implementiert wurde.
4C stellt ein exemplarisches System dar, in dem die unterschiedlichen Architekturen und/oder Funktionalitäten der verschiedenen vorherigen Ausführungsformen implementiert werden können.
5 ist eine konzeptionelle Darstellung einer Grafikverarbeitungspipeline, die von der PPU der 2 gemäß einer Ausführungsform implementiert wurde.
6 stellt ein Flussdiagramm eines Verfahrens zum Durchführen von hybridem Anti-Aliasing mit verzögertem Raytracing gemäß einer Ausführungsform dar.
7 stellt ein Flussdiagramm eines Verfahrens zum Durchführen eines adaptiven Raytracings für temporales Anti-Aliasing gemäß einer Ausführungsform dar.
8 stellt einen beispielhaften adaptiven temporalen Anti-Aliasing-Algorithmus im Kontext einer DXR-Raytracing-API gemäß einer Ausführungsform dar.

DETAILLIERTE BESCHREIBUNG
In der Computergrafik ist Anti-Aliasing eine Technik, die verwendet wird, um einem digitalen Bild mehr Realismus zu verleihen, indem gezackte Kanten geglättet werden (z.B. auf gekrümmten Linien und Diagonalen, etc.). Diese gezackten Kanten können durch niedrige Abtastraten während der Wiedergabe des Bildes entstehen. Es erfordert jedoch viel Verarbeitungsressourcen und Zeit, um Anti-Aliasing durchzuführen. Daher werden spezifische Pixel im digitalen Bild, bei denen eine Anti-Aliasing-Funktion hilfreich wäre, speziell identifiziert, und die Anti-Aliasing-Funktion wird dann für diese identifizierten Pixel durchgeführt. Dies reduziert die Kosten für die Durchführung von Anti-Aliasing, indem eine Anzahl von Pixeln innerhalb eines Bildes verkleinert wird, bei denen Anti-Aliasing durchgeführt wird.
1 stellt ein Flussdiagramm eines Verfahrens 100 zum Durchführen einer komplexen Pixelidentifikation zur Verbesserung des Anti-Aliasing von von einem Computer generierten Bildern 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 Pfadraumfilterung 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 in Schritt 102 dargestellt ist, werden komplexe Pixel innerhalb einer zu rendernden Szene identifiziert. In einer Ausführungsform können die komplexen Pixel jeweils ein Pixel beinhalten, das eine oder mehrere Sprünge bei Attributen des Pixels (z.B. Abdeckung, Tiefe, Material usw.) aufweist, was zu Aliasing führt. In einer weiteren Ausführungsform können die komplexen Pixel jeweils sichtbare Pixel beinhalten, die teilweise durch eine oder mehrere Instanzen der Geometrie (z.B. ein oder mehrere Polygone usw.) innerhalb der Szene verdeckt sind.
Zusätzlich können in einer Ausführungsform die komplexen Pixel unter Verwendung einer konservativen Rasterung identifiziert werden. So kann beispielsweise eine konservative Rasterung einen Schnittpunkt einer oder mehrerer Instanzen der Geometrie mit einem beliebigen Teil eines Pixels innerhalb der Szene identifizieren, auch wenn die Geometrie nicht auf ein Pixelzentrum oder eines der Samples innerhalb des Pixels trifft (bei Verwendung mehrerer Samples). In einem anderen Beispiel kann die konservative Rasterung eine oder mehrere Überschneidungen mit einem Ergebnis ungleich Null zwischen einer Instanz der Geometrie und einem Pixel identifizieren und kann das Pixel rastern.
Weiterhin kann in einer Ausführungsform die konservative Rasterung über eine Vielzahl von Durchgängen der einen oder mehreren Instanzen der Geometrie innerhalb der Szene implementiert werden. So kann beispielsweise ein erster Durchgang der konservativen Rasterung einen vorherigen Durchgang bezüglich der Tiefe beinhalten. So kann beispielsweise der vorherige Durchgang bezüglich der Tiefe einen Tiefenpuffer erzeugen, der die Tiefen für die nächsten vollständig überdeckten Pixel speichert.
Weiterhin kann in einer Ausführungsform ein zweiter Durchgang der konservativen Rasterung einen Pixelidentifikationsdurchgang beinhalten. So kann beispielsweise der Pixelidentifikationsvorgang die komplexen Pixel identifizieren und markieren (z.B. die sichtbaren Pixel innerhalb der Szene, die teilweise durch eine oder mehrere Geometrien abgedeckt sind). In einem weiteren Beispiel können die Pixel mit einem implementierten Pixel-Shader markiert werden. Bei noch einem weiteren Beispiel kann der Pixelidentifizierungsdurchgang auch einen Zähler erhöhen
Außerdem kann der Pixelidentifizierungsdurchgang in einer Ausführungsform für jedes Pixel auch eine Anzahl von Instanzen der Geometrie zählen, die das Pixel berühren. Dies kann als eine Primitiv-Anzahl für das Pixel gespeichert werden. In einer weiteren Ausführungsform kann der Pixelidentifikationsdurchgang zu einer 2D-Oberfläche führen, die Werte ungleich Null für die komplexen Pixel enthält, wobei die Werte ungleich Null eine Reihe von Primitives anzeigen können, die möglicherweise bei dem Pixel sichtbar sind.
Auf diese Weise können Pixel innerhalb einer Szene, die eine höhere Abtastrate verdienen (z.B. teilweise abgedeckte Pixel, etc.), während des Anti-Aliasing unter Verwendung einer konservativen Rasterung identifiziert werden.
Darüber hinaus kann die konservative Rasterung in einer Ausführungsform auch eine innere konservative Rasterung beinhalten. So kann beispielsweise die innere konservative Rasterung die eine oder die mehreren Instanzen der Geometrie innerhalb der Szene analysieren und für jedes Pixel der Szene anzeigen, ob die eine oder die mehreren Instanzen der Geometrie mindestens einen Teil des Pixels abdecken und ob das Pixel vollständig abgedeckt ist. In einem weiteren Beispiel kann die vollständige Abdeckung eines Pixels durch ein dem Pixel zugeordnetes Flag angezeigt werden. So kann beispielsweise ein binärer Flagwert von 0 anzeigen, dass das zugehörige Pixel teilweise abgedeckt ist, und ein binärer Flagwert von 1 kann anzeigen, dass das zugehörige Pixel vollständig abgedeckt ist.
Darüber hinaus wird, wie in Schritt 104 gezeigt, Anti-Aliasing für jedes der komplexen Pixel innerhalb der Szene unter Verwendung von Raytracing durchgeführt. In einer Ausführungsform kann das Durchführen des Anti-Aliasing das Durchführen von Raytracing auf die komplexen Pixel innerhalb der Szene beinhalten. So kann beispielsweise die Durchführung der Anti-Aliasing-Funktion das Bestimmen der Sichtbarkeit der Punktabtastung für einen Sub-Pixel-Bereich innerhalb jedes der komplexen Pixel beinhalten, wobei das GPU-Raytracing verwendet wird. Dies kann das Abtasten eines Bereichs des komplexen Pixels mittels Raytracing und das Approximieren einer Geometrieabdeckung des komplexen Pixels beinhalten.
Zum Beispiel können die Strahlen bzw. Rays über die komplexen Pixel abhängig von der Primitivanzahl für jedes komplexe Pixel verteilt sein. Bei einem weiteren Beispiel können mehr Strahlen durch ein komplexes Pixel verfolgt werden, das eine größere Pixelanzahl hat, als durch ein komplexes Pixel mit einer kleineren Pixelanzahl. Dies kann unter Verwendung eines Raytracing-Frameworks / einer Raytracing-Engine erfolgen.
Weiterhin kann die Durchführung des Anti-Aliasing in einer Ausführungsform für jedes der komplexen Pixel das analytische Auflösen einer Geometrieoberfläche und deren Abdeckung des komplexen Pixels beinhalten. So kann beispielsweise die Durchführung des Anti-Aliasings das Speichern zusätzlicher Daten über die Geometrie, die das komplexe Pixel schneidet, beinhalten. Beispielsweise können die zusätzlichen Daten eine oder mehrere Kantengleichungen beinhalten. In einem weiteren Beispiel kann die Durchführung des Anti-Aliasings auch die Verwendung der zusätzlichen Daten zum Berechnen von Schnittpunkten mit Kanten und Strahlen beinhalten. Dies kann von einer GPU durchgeführt werden, ohne ein Raytracing-Framework oder eine Raytracing-Engine zu verwenden.
In einer Ausführungsform kann die Durchführung des Anti-Aliasing auch die analytische Bewertung der Sichtbarkeit beinhalten. So kann beispielsweise die analytische Sichtbarkeit anzeigen, wie viel von einem Bereich eines komplexen Pixels mit einem bestimmten Primitiv belegt ist (z.B. durch Lösen eines Oberflächenintegrals, etc.).
Auf diese Weise können Pixel innerhalb einer Szene, die eine höhere Abtastrate verdienen (z.B. teilweise abgedeckte Pixel, etc.) während des Anti-Aliasings identifiziert werden. Infolgedessen können die Abtastkosten während des Anti-Aliasing reduziert werden, indem die Abtastung innerhalb von Pixeln fokussiert wird, die ein Primitiv haben, das das Pixel nur teilweise abdeckt. Darüber hinaus können beim Anti-Aliasing eine Reihe von Samples, die an jedes Pixel gesendet werden, pro Pixel angepasst werden, wobei das Raytracing verwendet wird.
In noch einer weiteren Ausführungsform wird das Anti-Aliasing für jedes der komplexen Pixel innerhalb der Szene unter Verwendung einer Parallelverarbeitungseinheit (PPU), wie der in 2 dargestellten PPU 200, durchgeführt.
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. Eine der folgenden Eigenschaften kann wahlweise mit oder ohne Ausnahme anderer beschriebener 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. 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, wird dringend darauf hingewiesen, 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 sein, um Tausende von High Performance Computing (HPC), Rechenzentren und maschinelle Lernanwendungen zu beschleunigen. Die PPU 200 kann konfiguriert sein, 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 Netzwerkkonten 230, ein Koppelfeld (Xbar) 270, ein 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 sein. Die PPU 200 kann über eine Verbindung 202 mit einem Host-Prozessor oder anderen Peripheriegeräten verbunden sein. Die PPU 200 kann auch mit einem lokalen Speicher verbunden sein, 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 sein, wobei mehrere DRAM-Dies in jeder Vorrichtung gestapelt sind.
Die Verbindung NVLink 210 ermöglicht es Systemen, eine oder mehrere PPUs 200 in Kombination mit einer oder mehreren CPUs zu skalieren und einzubinden, 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). Die 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 es in den Befehlen angegeben ist. So können beispielsweise einige Befehle an die Frontend-Einheit 215 übertragen werden. Andere Befehle können an den Netzknoten 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 unter diesen zu routen.
In einer Ausführungsform kodiert ein vom Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einem Puffer, der der PPU 200 Workloads zur Verarbeitung bereitstellt. Ein 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 Stömen und leitet Befehle an die verschiedenen Einheiten der PPU 200 weiter.
Die Front-End-Einheit 215 ist mit einer Schedulereinheit 220 gekoppelt, die die verschiedenen GPCs 250 konfiguriert, um Tasks zu verarbeiten, die durch einen oder mehrere Sröme definiert sind. Die Schedulereinheit 220 ist konfiguriert, um Zustandsinformationen in Bezug auf die verschiedenen Tasks zu verfolgen, die von der Schedulereinheit 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 Schedulereinheit 220 verwaltet die Ausführung einer Vielzahl von Tasks auf einem oder mehreren GPCs 250.
Die Schedulereinheit 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 eingeplanten Tasks verfolgen, die von der Schedulereinheit 220 empfangen wurden. In einer Ausführungsform verwaltet die Arbeitsverteilungseinheit 225 für jeden der GPCs 250 einen Pool für bevorstehende Tasks und einen Pool für aktive Tasks. Der Pool für bevorstehende 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 für aktive 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 Tasks beendet, wird diese Task aus dem Pool für aktive Tasks für das GPC 250 ausgeworfen und eine der anderen Tasks aus dem Pool für bevorstehende 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 entfernt 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 Verbindungsnetzwerk, das viele der Einheiten der PPU 200 mit anderen Einheiten der PPU 200 koppelt. So kann beispielsweise die XBar 270 konfiguriert sein, 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 Schedulereinheit 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 Treiberkern gibt Tasks an einen oder mehrere Streams bzw. 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 zugehörige 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 veranschaulicht einen GPC 250 der PPU 200 von 2 gemäß einer Ausführungsform. 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 des einen oder der 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 der mehreren DPCs 320 konfigurieren, um ein neuronales Netzwerkmodell 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 die Farbmischung 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 Rastervorgänge 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 Kachel-Zusammenfügungs-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-Eingine übertragen, wo Fragmente, die außerhalb eines Sichtvolumens liegen, weggeschnitten 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 enthaltenes 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 Vertexattribute 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. einem 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 auf aktuellem Stand gehalten, was die Nebenläufigkeit 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 auf aktuellem Stand gehalten, wodurch eine gleichwertige Nebenläufigkeit zwischen allen Threads, innerhalb und zwischen den Warps ermöglicht wird. Wenn der Ausführungszustand für jeden einzelnen Thread auf aktuellem Stand 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 stellt eine Speicher-Partitionseinheit 280 der PPU 200 von 2 gemäß einer Ausführungsform dar. Wie in 3B dargestellt ist, beinhaltet die Speicher-Partitionseinheit 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 Baueinheit 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 Computer-Anwendungen, 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 Speicher-Partitionseinheit 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, wenn sie 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 der PPU 200 den vollen Zugriff auf den CPU-Speicher 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 Speicher-Partitionseinheit 280 kann dann die Seitenfehler beheben und die Adressen in die Seitentabelle eintragen, woraufhin die Kopiermaschine die Übertragung durchführen kann. In einem herkömmlichen System ist der Speicher für Mehrfachkopiermaschinenoperationen zwischen mehreren Prozessoren angeheftet (d.h. nicht auslagerbar), was den verfügbaren Speicher erheblich reduziert. 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 Speicher-Partitionseinheit 280 abgerufen und im L2-Cache 360 gespeichert werden, der sich auf dem Chip befindet und zwischen den verschiedenen GPCs 250 geteilt wird. Wie dargestellt ist, beinhaltet jede Speicher-Partitionseinheit 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 jede 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 der 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 Tiefentests in Verbindung mit der Raster-Engine 325 durch, wobei sie eine Tiefe für eine Sample-Position 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 Sample-Position getestet. Wenn das Fragment den Tiefentest für die Sample-Position besteht, aktualisiert die ROP-Einheit 350 den Tiefenpuffer und sendet ein Ergebnis des Tiefentests an die Raster-Engine 325. Es ist zu beachten, dass die Anzahl der Partitions-Einheiten 280 von der Anzahl der GPCs 250 abweichen kann und daher jede ROP-Einheit 350 mit jeder der GPCs 250 gekoppelt sein 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 Speicher-Partitionseinheit 280 enthalten ist, kann sich die ROP-Einheit 350 in anderer Ausführungsform außerhalb der Speicher-Partitionseinheit 280 befinden. So kann sich beispielsweise die ROP-Einheit 350 im GPC 250 oder einer anderen Einheit befinden.
4A stellt den Streaming-Multiprozessor 340 von 3A gemäß einer Ausführungsform dar. Wie in 4A dargestellt ist, beinhaltet der SM 340 einen Befehls-Cache 405, eine oder mehrere Scheduler-Einheiten 410(K), eine Registerdatei 420, einen oder mehrere Rechenkerne 450, eine oder mehrere Spezialfunktionseinheiten (SFUs) 452, eine oder mehrere Lade-/Speichereinheiten (LSUs) 454, ein Verbindungsnetz 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 Shader-Programm zugeordnet ist, kann die Task einem SM 340 zugeordnet werden. Die Scheduler-Einheit 410(K) empfängt die Tasks von der Arbeitsverteilungseinheit 225 und verwaltet die Befehlsplanung für einen oder mehrere der SM 340 zugeordneten Thread-Blöcke. Die Scheduler-Einheit 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 Scheduler-Einheit 410(K) kann eine Vielzahl von verschiedenen Thread-Blöcken verwalten, ordnet die Threads den verschiedenen Thread-Blöcken zu und sendet 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).
Kooperative Gruppen sind ein Programmiermodell zum Organisieren von Gruppen von kommunizierenden Threads, das es Entwicklern ermöglicht, die Granularität auszudrücken, mit der Threads kommunizieren, was das Formulieren 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 Funktion syncthreads()). Programmierer möchten jedoch oft Gruppen von Threads mit einer geringeren als der Tread-Block-Granularität definieren 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 synchronisiert werden können, ohne Annahmen über die Konvergenz treffen zu müssen. Primitives von kooperierenden Gruppen ermöglichen neue Formen kooperativer Parallelität, einschließlich Produzenten-Verbraucher-Parallelität, opportunistischer Parallelität und globaler Synchronisation über ein ganzes Netz von Thread-Blöcken.
Eine Dispatcher-Einheit 415 ist konfiguriert, um Anweisungen an eine oder mehrere der Funktionseinheiten zu senden. In der Ausführungsform beinhaltet die Scheduler-Einheit 410(K) zwei Dispatcher-Einheiten 415, was ermöglicht, dass während jedes Taktzyklus zwei verschiedene Anweisungen von demselben Warp abgefertigt werden. In alternativen Ausführungsformen kann jede Scheduler-Einheit 410(K) eine einzelne Dispatcher-Einheit 415 oder zusätzliche Dispatcher-Einheiten 415 aufweisen.
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 mit einer vollständigen Pipeline ausgestattete Verarbeitungseinheit mit einfacher, doppelter und/oder gemischter Präzision beinhalten, die eine arithmetische Logikeinheit für Fließkommazahlen und eine arithmetische Logikeinheit für ganze Zahlen beinhaltet. In einer Ausführungsform implementieren die arithmetischen Logikeinheiten für Fließkommazahlen den Standard IEEE 754-2008 für Gleitkommaarithmetik. In einer Ausführungsform beinhalten die Kerne 450 64 Gleitkomma-Kerne mit einfacher Präzision (32 Bit), 64 Ganzzahlkerne, 32 Gleitkomma-Kerne mit doppelter Präzision (64 Bit) 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-Learning-Matrixarithmetik durchzuführen, wie z.B. Faltungsoperationen für das Training und die Inferenzierung neuronaler Netze. In einer Ausführungsform arbeitet jeder Tensorkern auf einer 4×4-Matrix und führt eine Matrix-Multiplikations- und Summations-Operation D=A×B+C durch, wobei A, B, C und D 4×4-Matrizen sind.
In einer Ausführungsform sind die Matrix-Multiplikationseingä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 Gleitkomma-Summation. 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 summiert 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-, Matrix-Multiplikations- und Summations sowie Matrix-SpeicherOperationen zur Verfügung, um Tensorkerne 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 Shader-Programmen 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, gemeinsamem 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-Speichern, 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 eine 128 KB Speicherkapazität und befindet sich auf dem Pfad von dem SM 340 zur Partitionseinheit 280. Der gemeinsame Speicher / L1-Cache 470 kann zum Cache-Lesen und Schreiben verwendet werden. Einer oder mehrere der gemeinsamen Speicher / L1-Cache 470, L2-Cache 360 und Speicher 204 sind Backup-Speicher.
Die Kombination der Funktionalität von Daten-Cache und gemeinsamen Speicher 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-/Speicher-Operationen die verbleibende Kapazität nutzen. Die Integration in den gemeinsamen Speicher / L1-Cache 470 ermöglicht es dem gemeinsamen Speicher / L1-Cache 470, als Hochdurchsatzleitung für das Streaming von Daten zu fungieren und gleichzeitig einen Zugriff mit hoher Bandbreite und geringer Latenz auf häufig wiederverwendeten Daten zu ermöglichen.
Bei der Konfiguration für die allgemeine parallele Berechnung 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 Thread-Blöcke 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, um zwischen Threads zu kommunizieren, und die LSU 454, 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 Scheduler-Einheit 220 neue Arbeiten an 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 Speichervorrichtungen 204 enthalten sein. Die Grafikkarte kann so konfiguriert sein, 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 bei Anwendungen wie künstlicher Intelligenz bereitstellen 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 400 kann konfiguriert sein, 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 an. 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 verschiedenen unterschiedlichen Verknüpfungen und/oder Verbindungen.
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 der 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 koppelt zwischen jeder der PPUs 200 mittels des NVLinks 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 des NVLinks 210 können als physische NVLink-Verbindung oder als On-Chip- oder On-Die-Verbindung unter Verwendung des gleichen Protokolls wie der 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 ist. 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 sein und jede der PPUs 200 und/oder jeder Speicher 204 kann als kompakte Vorrichtung ausgeführt sein. 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 NVLinks 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 vorhanden). 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 atomaren Lade-/Speicher-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 sein.
4C stellt ein exemplarisches System 465 dar, in dem die unterschiedlichen Architekturen und/oder Funktionalitäten der verschiedenen vorherigen Ausführungsformen implementiert werden kann. Das exemplarische System 465 kann konfiguriert werden, um das in 1 dargestellte Verfahren 100 zu implementieren.
Wie dargestellt ist, ist ein System 465 vorgesehen, das mindestens eine Zentraleinheit 430 beinhaltet, die mit einem Kommunikationsbus 475 verbunden ist. Der Kommunikationsbus 475 kann mit jedem geeigneten Protokoll implementiert werden, wie z.B. PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), HyperTransport 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. eine herkömmliche CRT (Kathodenstrahlröhre), LCD (Flüssigkristallanzeige), LED (Leuchtdiode), Plasmaanzeige oder dergleichen. Benutzereingaben können von den Eingabevorrichtungen 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 sein.
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äre Speicher 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 sein. 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 Architektur und/oder Funktionalität der verschiedenen vorherigen Figuren kann im Rahmen eines allgemeinen Computersystems, eines Platinensystems, eines Spielkonsolensystems für Unterhaltungszwecke, eines anwendungsspezifischen Systems und/oder eines anderen gewünschten Systems implementiert sein. 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 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.
Grafikbearbeitungspipeline
In einer Ausführungsform umfasst die PPU 200 eine Grafikprozessoreinheit (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, Quads, Dreiecksstreifen 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 zu erzeugen (d.h. Pixeldaten für jedes der Pixel des Displays).
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, damit 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 sind, einschließlich eines oder mehrerer Vertex-Shader, Rumpf-Shader, Domain-Shader, Geometrie-Shader und Pixel-Shader. So kann beispielsweise einer oder mehrere der SMs 340 konfiguriert sein, 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 sein, 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 der 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 Vertex-Daten gerastert wurden (d.h. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum 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 langen Latenzzeiten effizienter durchführen, indem sie die Operation in eine Vielzahl von 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 O-penGL®-API definierte Grafikverarbeitungspipeline darstellen. Optional kann die Grafikverarbeitungspipeline 500 im Rahmen der Funktionalität und Architektur der vorherigen Figuren und/oder jeder der nachfolgenden Figur(en) implementiert sein.
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-Montage-Stufe 530, eine Geometrie-Shading-Stufe 540, eine Darstellungsbereichs-Skalierungs-, Culling- und Clipping- (VSCC)-Stufe 550, eine Rasterungsstufe 560, eine Fragment-Shading-Stufe 570 und eine Rasteroperationsstufe 580. In einer Ausführungsform umfassen die Eingangsdaten 501 Befehle, die die Verarbeitungseinheiten konfigurieren, um die Stufen der Grafikverarbeitungspipeline 500 und geometrische Primitives (z.B. Punkte, Linien, Dreiecke, Quads, Dreiecksstreifen oder Dreiecksfächer, etc.) zu implementieren, die von den Stufen verarbeitet werden sollen. Die Ausgangsdaten 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 Vertex-Daten für Oberflächen hoher Ordnung, Primitives oder dergleichen spezifizieren. Die Datenmontagestufe 510 sammelt die Vertex-Daten 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 liest die Vertex-Daten aus dem Puffer. Die Vertex-Daten werden dann zur Verarbeitung an die Vertex-Shading-Stufe 520 übertragen.
Die Vertex-Shading-Stufe 520 verarbeitet Vertex-Daten, indem sie eine Reihe von Operationen (z.B. einen Vertex-Shader oder ein 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 Vertex-Attributen (z.B. Farbe, Texturkoordinaten, Oberflächennormale, etc.) zugeordnet ist. Die Vertex-Shading-Stufe 520 kann einzelne Vertex-Attribute wie Position, Farbe, Texturkoordinaten und dergleichen manipulieren. Mit anderen Worten, die Vertex-Shading-Stufe 520 führt Operationen an den Vertex-Koordinaten oder anderen Vertex-Attributen durch, die einem Vertex zugeordnet sind. Solche Operationen beinhalten üblicherweise Ausleuchtungsoperationen (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 Worldspace oder einen normalisierten Gerätekoordinatenraum (NDC) übersetzt. Die Vertex-Shading-Stufe 520 erzeugt transformierte Vertex-Daten, die an die Primitiv-Montagestufe 530 übertragen werden.
Die Primitiv-Montage-Stufe 530 sammelt die von der Vertex-Shading-Stufe 520 ausgegebenen Vertices und gruppiert die Vertices zu geometrischen Vertices für die Verarbeitung durch die Geometrie-Shading-Stufe 540. So kann beispielsweise die Primitiv-Montage-Stufe 530 konfiguriert werden, um jeweils drei aufeinanderfolgende Vertices als geometrisches Primitiv (d.h. ein Dreieck) zur Übertragung an die Geometrie-Shading-Stufe 540 zu gruppieren. In einigen Ausführungsformen können bestimmte Vertices für aufeinanderfolgende geometrische Primitives wiederverwendet werden (z.B. können zwei aufeinanderfolgende Dreiecke in einem Dreieckstreifen zwei Vertices teilen). Die Primitiv-Montage-Stufe 530 überträgt geometrische Primitives (d.h. eine Sammlung von zugehörigen Vertices) an die Geometrie-Shading-Stufe 540.
Die Geometrie-Shading-Stufe 540 verarbeitet geometrische Primitives, indem sie eine Reihe von Operationen (d.h. einen Geometrie-Shader oder ein Programm) auf den geometrischen Primitives durchführt. Tessellierungsoperationen können aus jedem geometrischen Primitiv ein oder mehrere geometrische Primitives erzeugen. Mit anderen Worten, die Geometrie-Shading-Stufe 540 kann jedes geometrische Primitiv in ein feineres Netz von zwei oder mehr geometrischen Primitives unterteilen, die zur Verarbeitung durch den Rest der Grafikverarbeitungspipeline 500 vorgesehen sind. Die Geometrie-Shading-Stufe 540 überträgt geometrische Primitives an die Darstellungsbereichs-SCC-Stufe 550.
In einer Ausführungsform kann die Grafikverarbeitungspipeline 500 innerhalb eines Streaming-Multiprozessors arbeiten und die Vertex-Shading-Stufe 520, die Primitiv-Montagestufe 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 Darstellungsbereichs-SCC-Stufe 550 die Daten verwenden. In einer Ausführungsform können Primitiv-Daten, die von einer oder mehreren Stufen der Grafikverarbeitungspipeline 500 verarbeitet werden, in einen Cache geschrieben werden (z.B. L1-Cache, Vertex-Cache, etc.). In diesem Fall kann die Darstellungsbereichs-SCC-Stufe 550 in einer Ausführungsform auf die Daten im Cache zugreifen. In einer Ausführungsform sind die Darstellungsbereichs-SCC-Stufe 550 und die Rasterungsstufe 560 als Schaltung mit fester Funktion implementiert.
Die Darstellungsbereichs-SCC-Stufe 550 führt die Skalierung, das Culling und das Clipping der geometrischen Primitives 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 Betrachtungs-Sichtvolumen, das die Objekte der Szene einschließt. Das Betrachtungs-Sichtvolumen kann eine Betrachtungsebene, eine hintere Ebene und vier Clipping-Ebenen beinhalten. Jedes geometrische Primitiv, das sich vollständig außerhalb des Betrachtungs-Sichtvolumens befindet, kann nicht ausgewählt (d.h. verworfen) werden, da das geometrische Primitiv nicht zur endgültigen gerenderten Szene beiträgt. Jedes geometrische Primitiv, das sich teilweise innerhalb des Darstellungsbereichs-Sichtvolumens und teilweise außerhalb des Darstellungsbereichs-Sichtvolumens befindet, kann geschnitten werden (d.h. in ein neues geometrisches Primitiv umgewandelt werden, das innerhalb des Darstellungsbereichs-Sichtvolumens vorhanden ist). Darüber hinaus können geometrische Primitives jeweils auf der Grundlage einer Tiefe des Darstellungsbereichs-Sichtvolumens skaliert werden. Alle potenziell sichtbaren geometrischen Primitives werden dann an die Rasterstufe 560 übertragen.
Die Rasterstufe 560 wandelt die geometrischen 3D-Primitives in 2D-Fragmente um (z.B. geeignet, um zur Anzeige eingesetzt zu werden, etc.). Die Rasterstufe 560 kann konfiguriert werden, um die Vertices der geometrischen Primitives zu nutzen, um einen Satz von Ebenengleichungen aufzubauen, aus denen verschiedene Attribute interpoliert werden können. Die Rasterstufe 560 kann auch eine Abdeckungsmaske für eine Vielzahl von Pixeln berechnen, die angibt, ob eine oder mehrere Sample-Positionen für das Pixel das geometrische Primitiv schneiden. In einer Ausführungsform kann auch ein Z-Test durchgeführt werden, um zu bestimmen, ob das geometrische Primitiv durch andere geometrische Primitives, die bereits gerastert wurden, verdeckt wird. Die Rasterstufe 560 erzeugt Fragmentdaten (d.h. interpolierte Vertex-Attribute, die einer bestimmten Sample-Position 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) an jedem der Fragmente durchführt. Die Fragment-Shading-Stufe 570 kann Pixeldaten (d.h. Farbwerte) für das Fragment erzeugen, z.B. durch Ausleuchtungsoperationen 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 Rasteroperationen-Stufe 580 kann verschiedene Operationen an 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 Rasteroperationen 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 eine oder mehrere der vorstehend beschriebenen Stufen von der Grafikverarbeitungspipeline ausgeschlossen werden (z. B. die Geometrie-Shading-Stufe 540). 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 die 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 Phasen 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 ursprüngliche 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 fester Hardware wie einem Rasterisierer 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 Netzwerke (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 der automatischen Bildunterschrift 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 Nachhilfe Formen identifizieren zu können. Ebenso muss ein tief lernendes oder neuronales Lernsystem in der Objekterkennung und -klassifizierung trainiert werden, damit es intelligenter und effizienter grundlegende Objekte, verdeckte Objekte usw. identifizieren und gleichzeitig den Objekten Kontext zuweisen kann.
Auf der einfachsten Ebene betrachten Neuronen im menschlichen Gehirn verschiedene Eingaben, die empfangen werden, wobei jeder dieser Eingaben Wichtigkeitsstufen zugewiesen werden, und die Ausgabe wird an andere Neuronen weitergeleitet, um darauf zu reagieren. Ein künstliches Neuron oder Perzeptron ist das grundlegendste Modell eines neuronalen Netzwerks. 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 Eingangsdaten 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 Kennzeichen 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 Inferenz bzw. 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 bei 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 eine Bezeichnung hinweist, das der Eingabe entspricht. Wenn das neuronale Netzwerk die Eingabe nicht korrekt kennzeichnet, werden Fehler zwischen der richtigen Bezeichnung und der vorhergesagten Bezeichnung 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 bezeichnet. 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 Netzwerk 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 Netzwerke 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 tief neuronale netzbasierte künstliche Intelligenz und maschinelle Lernanwendungen erforderliche Leistung zu liefern.
Hybrides Anti-Aliasing-System mit verzögertem Raytracing
In einer Ausführungsform kann Anti-Aliasing an identifizierten komplexen Pixeln als Teil des Anti-Aliasing mit verzögertem Rendering für eine Szene durchgeführt werden. Dies kann durch die Implementierung eines hybriden Anti-Aliasing mit verzögertem Raytracing für die Szene erfolgen.
6 stellt ein Flussdiagramm eines Verfahrens 600 zur Durchführung von hybridem Anti-Aliasing mit verzögertem Raytracing gemäß einer Ausführungsform dar. Obwohl das Verfahren 600 im Zusammenhang mit einer Verarbeitungseinheit beschrieben wird, kann das Verfahren 600 auch durch ein Programm, eine benutzerdefinierte Schaltung oder durch eine Kombination aus einer benutzerdefinierten Schaltung und einem Programm durchgeführt werden. Das Verfahren 600 kann beispielsweise von einer GPU (Grafikprozessor), einer CPU (Zentraleinheit) oder einem beliebigen Prozessor ausgeführt werden, der in der Lage ist, durch Hashing eine parallele Pfadraumfilterung durchzuführen. Darüber hinaus versteht der Fachmann, dass jedes System, das das Verfahren 600 durchführt, im Rahmen und Geist der Ausführungsformen der vorliegenden Erfindung liegt.
Wie in Schritt 602 gezeigt ist, wird für eine Szene ein Nicht-Anti-Aliasing-G-Puffer gerendert. So kann beispielsweise der G-Puffer einen Puffer beinhalten, der Informationen über die Szenengeometrie bei jedem Pixel speichert. In einem weiteren Beispiel kann ein Multi-Sample-Anti-Aliasing (MSAA)-Tiefenpuffer mit Hilfe der vom Target unabhängigen Rasterung ((„Target Independent Rasterization“), TIR) gerendert werden. In noch einem weiteren Beispiel können MSAA-Normale mit TIR gerendert werden.
Weiterhin werden, wie in Schritt 604 gezeigt ist, komplexe Pixel innerhalb der Szene identifiziert. So können beispielsweise die komplexen Pixel Pixel beinhalten, die eine oder mehrere Diskontinuitäten (z.B. bzgl. Tiefe, Helligkeit, etc.) innerhalb der Szene umgeben. In einem weiteren Beispiel kann die Identifizierung komplexer Pixel innerhalb der Szene die gerenderte MSAA-Tiefe und/oder MSAA-Normalen verwenden.
Weiterhin werden, wie in Schritt 606 gezeigt ist, Strahlen durch die komplexen Pixel verfolgt, um Samples für den G-Puffer zu erzeugen. So kann beispielsweise ein Speicher für eine vorgegebene Anzahl von G-Buffer-Daten für die komplexen Pixel zugewiesen sein. In einem weiteren Beispiel kann eine vorgegebene Anzahl von Strahlen durch jedes komplexe Pixel verfolgt werden. In noch einem weiteren Beispiel können G-Puffer-Daten für die nächsten Treffer aufgezeichnet werden. In noch einem weiteren Beispiel können zusätzliche Strahlen nach dem Empfangen von Ergebnissen iterativ verfolgt werden. In einem weiteren Beispiel können Lichtstrahltreffer für komplexe Pixel während einer verzögerten Ausleuchtung berechnet werden.
In noch einer weiteren Ausführungsform können die Strahlen unter Verwendung einer Parallelverarbeitungseinheit (PPU) wie der in 2 dargestellten PPU 200 verfolgt werden.
Auf diese Weise kann mit einem einzigen Rasterdurchgang über die Szene ein Anti-Aliasing mit verzögertem Raytracing durchgeführt werden. Darüber hinaus kann Anti-Aliasing daher durch die Kombination von verzögerter GPU-Rasterisierung und GPU-Raytracing in einem einzigen Durchgang durchgeführt werden.
Adaptives Raytracing für temporales Anti-Aliasing
Temporale Anti-Alialiasing- (TAA)-Algorithmen sind heute in Videospielen weit verbreitet. Aktuelle TAA-Implementierungen sind jedoch insofern eingeschränkt, als es, wenn festgestellt wird, dass ein bestimmtes Pixel während der TAA vom richtigen Wert abgewichen ist, keinen effizienten und effektiven Ansatz gibt, um dieses Pixel genau zu färben (nur Heuristiken, die oft je nach Grundursache von Sampling-Problemen fehlerhaft sind).
7 stellt ein Flussdiagramm eines Verfahrens 700 zum Durchführen eines adaptiven Raytracings für temporales Anti-Aliasing gemäß einer Ausführungsform dar. Obwohl das Verfahren 700 im Zusammenhang mit einer Verarbeitungseinheit beschrieben wird, kann das Verfahren 700 auch durch ein Programm, eine benutzerdefinierte Schaltung oder durch eine Kombination aus einer benutzerdefinierten Schaltung und einem Programm durchgeführt werden. Das Verfahren 700 kann beispielsweise von einer GPU (einem Grafikprozessor), einer CPU (Zentraleinheit) oder einem beliebigen Prozessor ausgeführt werden, der in der Lage ist, durch Hashing eine parallele Pfadraumfilterung durchzuführen. Darüber hinaus versteht der Fachmann, dass jedes System, das das Verfahren 700 durchführt, im Rahmen und Geist der Ausführungsformen der vorliegenden Erfindung liegt.
Wie in Schritt 702 dargestellt ist, wird das temporale bzw. zeitliche Anti-Aliasing (TAA) auf ein Bild angewendet. In einer Ausführungsform kann das Bild eines aus einer Reihe von gerasterten Bildern sein. In einer weiteren Ausführungsform kann das Bild unter Verwendung einer oder mehrerer Rendering-Techniken erstellt werden. So kann beispielsweise das Bild unter Verwendung von vorwärts gerastertem oder verzögertem Rastern, Raytracing, punktbasiertem Rendering, bildbasiertem Rendering usw. erstellt werden.
Zusätzlich kann in einer Ausführungsform TAA auf das Bild angewendet werden, um die Auswirkungen von Aliasing (z.B. geometrisches Aliasing, temporales Aliasing, Spiegel-Aliasing, etc.) innerhalb des gerasterten Bildes zu entfernen. Beispielsweise kann TAA versuchen, das Aliasing von primären sichtbaren Oberflächen innerhalb des gerasterten Bildes zu korrigieren. In einer weiteren Ausführungsform können die Ergebnisse der Anwendung von TAA auf das gerasterte Bild einen Farbpuffer für Pixel innerhalb des gerasterten Bildes beinhalten.
Weiterhin werden, wie in Schritt 704 dargestellt ist, Fehlerpixel identifiziert, die sich aus der Anwendung der TAA auf das Bild ergeben. In einer Ausführungsform können die Fehlerpixel Pixel innerhalb des Bildes beinhalten, bei denen die TAA versagt hat. In einer weiteren Ausführungsform können die Fehlerpixel während der TAA identifiziert werden. So kann beispielsweise die TAA einen historischen Wert für ein Pixel in einem vorherigen Frame mit aktuellen Werten benachbarter Pixel in einem aktuellen Frame vergleichen. In einem weiteren Beispiel können Pixel mit einem historischen Wert, der sich von den aktuellen Werten benachbarter Pixel um mehr als einen vorgegebenen Betrag unterscheidet, als Fehlerpixel identifiziert werden. Auf diese Weise kann das Pixel als komplex identifiziert und als Fehlerpixel bezeichnet werden.
Weiterhin können in einer Ausführungsform die Fehlerpixel durch Vergleichen eines Tiefenwerts für ein Pixel mit Tiefenwerten für benachbarte Pixel identifiziert werden. So kann beispielsweise das Pixel als Fehlerpixel identifiziert werden, wenn bestimmt wird, dass sich der Tiefenwert für das Pixel um mehr als einen vorbestimmten Betrag von den Tiefenwerten für benachbarte Pixel unterscheidet. Auf diese Weise kann das Pixel als mit einer Tiefenkante verbunden identifiziert und als Fehlerpixel bezeichnet werden.
Auch können in einer Ausführungsform die Fehlerpixel identifiziert werden, indem ein Helligkeitswert für ein Pixel mit Helligkeitswerten für benachbarte Pixel verglichen wird. So kann beispielsweise das Pixel als Fehlerpixel identifiziert werden, wenn bestimmt wird, dass sich der Helligkeitswert für das Pixel um mehr als einen vorbestimmten Betrag von den Helligkeitswerten für benachbarte Pixel unterscheidet. In einer weiteren Ausführungsform können die Fehlerpixel markiert werden (z.B. mit einem Hinweiswert, etc.). In noch einer weiteren Ausführungsform können die Fehlerpixel in eine Segmentierungsmaske aufgenommen werden.
Darüber hinaus wird, wie es in Schritt 706 gezeigt ist, Anti-Aliasing auf jedem der Fehlerpixel durchgeführt, wobei eine Kombination aus Raytracing (z.B. GPUoptimiertes Raytracing) und schnellem approximativem Anti-Aliasing (FXAA) verwendet wird. In einer Ausführungsform kann das Raytracing ein Supersampling durchführen. In einer weiteren Ausführungsform kann das Durchführen des Anti-Aliasing ein Verfolgen bzw. Tracing von mehreren Strahlen durch jedes der Fehlerpixel beinhalten. So kann beispielsweise die Durchführung des Anti-Aliasing ein Bestimmen der Sichtbarkeit der Punktabtastung für einen Sub-Pixel-Bereich innerhalb jedes der Fehlerpixel aufweisen, wobei das GPU-Raytracing verwendet wird.
Darüber hinaus kann das Durchführen des Anti-Aliasing in einer Ausführungsform für jedes der Fehlerpixel das analytische Lösen einer Geometrieoberfläche und deren Abdeckung des Fehlerpixels beinhalten. In einer weiteren Ausführungsform kann die Durchführung des Anti-Aliasing auch eine analytische Bewertung der Sichtbarkeit beinhalten. In noch einer weiteren Ausführungsform kann die Durchführung des Anti-Aliasing zu einer Raytracing-Anti-Aliasing-Textur für jedes der Fehlerpixel führen.
Weiterhin können die Ergebnisse der Durchführung des Anti-Aliasing auf den Fehlerpixeln (z.B. Texturen für einen ersten Satz von mittels Anti-Aliasing bearbeiteten Pixeln) mit den Ergebnissen der Anwendung der TAA auf das Bild (z.B. ein Farbpuffer für einen zweiten Satz von mittels Anti-Aliasing bearbeiteten Pixeln) kombiniert werden, um ein Ausgabebild zu erzeugen. So können beispielsweise die Textur-Ergebnisse des Anti-Aliasing, die bei der Durchführung des Anti-Aliasing auf den Fehlerpixeln entstehen, mit einem Farbpuffer gemischt werden, der sich aus der Anwendung des TAA auf das Bild ergibt.
Auf diese Weise können Pixel in einem Bild, bei dem die Anti-Aliasing mit TAA fehlgeschlagen ist, unter Verwendung eines GPU-Raytracing einem Anti-Aliasing unterzogen werden, und die Ergebnisse können kombiniert werden. Dies kann Probleme mit TAA (z.B. Unschärfe, Ghosting, etc.) vollständig lösen und gleichzeitig die Kosten für das Raytracing innerhalb des gerasterten Bildes amortisieren.
Außerdem können in einer Ausführungsform ein oder mehrere Pixel, die im Originalbild verdeckt sind und sichtbar zu machen sind, identifiziert werden. So können beispielsweise die identifizierten Pixel Pixel beinhalten, für die keine temporale Informationen vorliegen (z.B. sind Daten im aktuellen Frame aufgrund von Verdeckung nicht verfügbar und/oder temporale Daten für die Pixel sind in einem vorherigen Bild nicht verfügbar). In einer Ausführungsform können diese Pixel identifiziert werden, indem ein oder mehrere mit den Pixeln verbundene Bewegungsvektorfehler identifiziert werden. In einer weiteren Ausführungsform kann Anti-Aliasing für diese Pixel unter Verwendung von schnellem, approximativem Anti-Aliasing ((Fast Approximate Anti-Aliasing) FXAA) durchgeführt werden. So kann beispielsweise FXAA Farbbildwerte für diese Pixel basierend auf dem Grad, mit dem die Pixel als Kante markiert sind, filtern.
Zusätzlich können in einer Ausführungsform die Pixel, die verdeckt sind und sichtbar zu machen sind, in eine Segmentierungsmaske aufgenommen werden. In einer weiteren Ausführungsform kann die Segmentierungsmaske mit diesen Pixeln von der Segmentierungsmaske mit den Fehlerpixeln getrennt sein. In noch einer weiteren Ausführungsform können die Ergebnisse der Durchführung des Anti-Aliasing auf den Fehlerpixeln (z.B. ein erster Satz von mittels Anti-Aliasing bearbeiteten Pixeln) mit den Ergebnissen der Anwendung der TAA auf das Originalbild (z.B. ein zweiter Satz von mit Anti-Aliasing bearbeiteten Pixeln) und den Ergebnissen der Durchführung des Anti-Aliasing auf den Pixeln, die verdeckt sind und sichtbar zu machen sind, (z.B. ein dritter Satz von mit Anti-Aliasing bearbeiteten Pixeln), kombiniert werden, um ein Ausgabebild zu erzeugen.
In einer Ausführungsform kann ein Renderer verwendet werden, um ein gerastertes Bild zu erzeugen. Zusätzlich kann Anti-Aliasing auf das gerasterte Bild unter Verwendung von TAA angewendet werden. Weiterhin können Pixel, bei denen Anti-Aliasing mit TAA fehlgeschlagen ist, identifiziert und markiert werden, und TAA-Ergebnisse können für diese Pixel verworfen werden. Weiterhin kann Anti-Aliasing auf die markierten Pixel angewendet werden, indem Supersampling-GPU-Raytracing verwendet wird, um Raytracing-Anti-Aliasing-Textur-Ergebnisse zu erzeugen. Außerdem können die Ergebnisse der Raytracing-Anti-Aliasing-Textur mit dem mit TAA erstellten Farbpuffer gemischt werden.
In noch einer weiteren Ausführungsform kann das Anti-Aliasing unter Verwendung einer Parallelverarbeitungseinheit (PPU), wie der in 2 dargestellten PPU 200, durchgeführt werden.
Auf diese Weise können Pixel identifiziert werden, bei denen TAA fehlgeschlagen ist, und AA kann auf diesen Pixeln durchgeführt werden, wobei eine Kombination aus Raytracing und FXAA verwendet wird, um die AA-Ergebnisse zu verbessern. Zusätzlich können Kosten für das Raytracing durch selektive Anwendung auf fehlgeschlagene Ergebnisse von TAA amortisiert werden. Darüber hinaus kann unter Verwendung von FXAA eine kostengünstigere und effizientere AA für Pixel durchgeführt werden, bei denen keine temporalen Informationen vorhanden sind. Weiterhin kann AA innerhalb eines einzelnen Bildes selektiv und intelligent unter Verwendung von TAA, Raytracing und FXAA durchgeführt werden.
Adaptives temporales und hybrides verzögertes Anti-Aliasing für GPU-Raytracing
Anti-Aliasing gehört zu einer Kategorie von Techniken, um Bildartefakte zu entfernen, die sich aus unzureichenden Abtastraten ergeben. Multi-Sample Anti-Aliasing (MSAA) ist eine beliebte Anti-Aliasing-Technik, die die Sichtbarkeit mit einer anderen Rate als der typischen Shading-Rate von einmal pro Pixel pro Primitiv abtastet. Obwohl MSAA im geometrischen Anti-Aliasing etwas effektiv ist, verursacht es höhere Speicherkosten, da Tiefen- und Farbmuster mit der Abtastrate gespeichert werden. Darüber hinaus kann es unter einer höheren Bandbreite leiden, wenn die Farbkompression die Farbdaten nicht gut komprimiert. Die durch den Einsatz von MSAA erzeugte hohe Bildqualität verursacht daher relativ hohe Kosten.
Die Bildqualität von MSAA ist wünschenswert, ohne die damit verbundenen hohen Kosten zu tragen. Wenn ein Primitiv ein Pixel vollständig verdeckt, ist es nicht notwendig, weitere Sichtbarkeitsberechnungen durchzuführen. Wenn ein Pixel teilweise von Primitives verdeckt ist, muss bestimmt werden, wie viel von dem Pixel von jedem schneidenden Primitiv verdeckt ist, um die richtige Sichtbarkeit zu berechnen. Unter Ausnutzung dieses Wissens beinhalten die Ausführungsformen der vorliegenden Erfindung einen Ansatz, der „komplexe“ Pixel identifiziert - Pixel, die von einer genaueren Berechnung der Sichtbarkeit mehr profitieren würden als mit einem einzelnen Raster-Sample und/oder Pixel, die Tiefen- oder andere Diskontinuitäten aufweisen, welche zu Aliasing führen. Zusätzliche Ausführungsformen der Erfindung stellen Verfahren zur Berechnung der Sichtbarkeit für die identifizierten Pixel mit verbesserter Genauigkeit bereit.
Pixelklassifizierung mittels konservativer Rasterung
Komplexe Pixel, wie sie hierin beschrieben sind, können durch Analyse der Tiefen- und/oder Primitiv-ID-Puffer identifiziert werden; dieser Ansatz kann jedoch dünne geometrische Merkmale übersehen. Häufige Problemfälle sind Kabelleitungen oder Zäune in einem Abstand, die durch die Standard-Rasterung nicht ausreichend abgetastet werden. Ausführungsformen der vorliegenden Erfindung können durch die konservative Rasterung die Verwendung mehrerer Subpixel-Samples bei der Pixelklassifizierung vermeiden.
Die GPU-Hardwareunterstützung für die konservative Rasterung bezieht sich typischerweise auf einen Rasterisierungsmodus, in dem Pixel, die teilweise vom Primitiv abgedeckt sind, gerastert werden. Es gibt verschiedene Stufen dieser Funktion. Auf der Stufe 3 bzw. Tier 3 level kann man (optional) eine Systemvariable namens SV_InnerCoverage übergeben, deren niederwertigstes Bit (LSB) auf 1 gesetzt ist, wenn dieses Pixel garantiert vollständig vom Primitiv übergedeckt wird.
Beispielhafter Algorithmus
Mit einem konservativen Tier 3 (oder ähnlichen) Rasterisierer implementieren bevorzugte Ausführungsformen den folgenden Prozess zur Identifizierung von Pixeln, die von einer genaueren Sichtbarkeitsberechnung profitieren können.
Durchlauf 1: vorheriger Durchlauf bezüglich Tiefe
Mit diesem Durchlauf wird ein Tiefenpuffer erzeugt, der die Tiefen für die nächsten vollständig abgedeckten Pixel speichert. Gemäß den bevorzugten Ausführungsformen kann der vorherige Durchlauf bezüglich Tiefe gemäß den folgenden Schritten durchgeführt werden:

1. Konservative Rasterung aktivieren und den Tiefen-Test für Lesen und Schreiben aktivieren.
2. Ein Pixel-Shader akzeptiert SV_InnerCoverage als Eingabe. Er prüft diesen Wert, um herauszufinden, welche Pixel vollständig vom Primitiv abgedeckt sind, und verwirft die nicht vollständig abgedeckten Pixel. Infolgedessen wird der Tiefenwert nur für die vollständig abgedeckte Pixel geschrieben, und da sie vollständig abgedeckt sind, ist es die tatsächliche Tiefe (und nicht eine extrapolierte/festgehaltene Tiefe). Die Pixel, die nur teilweise verdeckt sind, werden verworfen und es wird kein Tiefenwert für diese Pixel aktualisiert.

Durchlauf 2: Pixel-Identifikationsdurchlauf
Nach diesem Durchlauf erhält man eine 2D-Oberfläche, die Werte ungleich Null für die Pixel enthält, die einige teilweise sichtbare Primitive aufweisen und für die Sichtbarkeit eine weitere Behandlung erfordern. Die Werte an diesen Stellen geben die Anzahl der Primitives an, die bei diesen Pixeln möglicherweise sichtbar sein können. Man kann die Gesamtzahl der Primitives verfolgen, die alle interessierenden Pixel abdecken, indem man den Zähler für die ungeordnete Zugriffsansicht ((Unordered Access View) UAV) für dieselbe UAV erhöht. Es ist zu beachten, dass dies eine approximative Heuristik ist, da die tatsächliche Sichtbarkeit innerhalb dieser Pixel komplizierter sein kann als nur die Anzahl der Primitives, die diese Pixel berühren.
Gemäß den bevorzugten Ausführungsformen kann der Pixel-Identifizierungsdurchlauf gemäß den folgenden Schritten durchgeführt werden:

1. Aktivieren der konservativen Rasterung und des Tiefen-Tests, um zu lesen, wobei aber die Schreibvorgänge ausgeschaltet werden.
2. Binden des in Durchgang 1 erzeugten Tiefenpuffers als Tiefenpuffer.
3. Binden einer ungeordnete Zugriffsansicht als Größe des Rendertargets und des Formats UINT_8/16/32 und Löschen dieser UAV mit allen Nullen. Die Größe bestimmt, die maximale Anzahl von Primitives, die das Pixel berühren können (256, 64K bzw. 4G).
4. Binden eines Pixel-Shaders, der SV_InnerCoverage als Eingabe akzeptiert, aber dieser Durchlauf überspringt die Verarbeitung vollständig abgedeckter Pixel. Stattdessen markiert der Shader für die Pixel, die teilweise abgedeckt sind und den Tiefen-Test bestehen, diese Pixel als interessante Pixel, indem er die UAV an dieser Stelle jedes Mal inkrementiert, wenn sie aufgerufen wird.

Verbesserte Sichtbarkeitsberechnung
Sobald komplexe Pixel identifiziert sind, können genauere Verfahren angewendet werden, um die Sichtbarkeit für diese Pixel zu berechnen. Dies kann entweder durch 1) Erhöhung der Subpixel-Abtastrate mit GPU-Raytracing oder durch 2) analytisches Lösen für die Sichtbarkeit erreicht werden.
GPU-Raytracing mit DXR
Gemäß den bevorzugten Ausführungsformen wird für komplexe Pixel eine verbesserte Sichtbarkeitsschätzung berechnet, indem der Sub-Pixel-Bereich mittels GPU-Raytracing punktuell abgetastet wird. Vor kurzem kündigte Microsoft die DirectX Raytracing (DXR)-API an, die die RTX-Raytracing-Technologie von NVIDIA nutzt und das GPU-Raytracing für Echtzeitanwendungen praktikabel macht. GPU-Raytracing beseitigt auch die Hardware-Grenzen für die Anzahl und Positionierung von Samples in einem Pixel in der konventionellen rasterbasierten Pipeline.
Das mehrfache punktuelle Abtasten der Sichtbarkeit innerhalb eines Pixels bietet eine angemessene Annäherung (aber keine genaue Lösung) mit einer ausreichend großen Anzahl von Samples. Raytracing (z.B. mit einem DXR Ray Generation Shader), kann die oben genannten Primitivanzahlen als Richtlinie verwenden, wie man Strahlen über den Sub-Pixel-Bereich verteilt. Es können mehr Strahlen auf Pixel gerichtet sein, die von einer größeren Anzahl von Primitives berührt werden, oder es können eine dynamische Anzahl von Sichtbarkeiten oder Farbuntersamples für jedes komplexe Pixel aufgenommen werden.
Sichtbarkeit mit nicht DXR-basiertem Raytracing
Es ist möglicherweise möglich, die samplebasierten Techniken zur Sichtbarkeitsbestimmung mit analytischen Methoden zu verbessern. Ein exemplarischer Prozess kann wie folgt durchgeführt werden:

1. Vorbereiten eines Puffers mit genügend Platz für N (Anzahl der Strahl-Samples) 64 Bit Einträge pro Pixel durch 0xffffffffffffffff.
2. Für die komplexen Pixel (einfache Pixel, die z.B. mit einer Schablone ausgewählt werden können) wird ein erneutes Rendern mit konservativem Raster durchgeführt.
3. Verwenden eines schnellen GS, um die Worldspace-Vertices des Dreiecks an den Pixel-Shader zu übergeben.
4. Im Pixel-Shader - für jedes Sample s (1..N)
1. a. Einrichten eines Strahls vom Auge bis zur WS-Position des Samples s bei den Pixeln.
2. b. Berechnen des Schnittpunkts des aktuellen Dreiecks mit dem Strahl - er trifft auf das Dreieck.
  1. i. Konstruieren eines 64-Bit-Worts (32:32) wie folgt (DepthValue:ID) 1. ID ist ein 32-Bit-Wort, das das Objekt plus das Primitiv im Objekt identifiziert.
  2. ii. Aktualisieren von Sample s des aktuellen Pixels mit AtomicMin64(old, (DepthValue:ID))
  3. iii. Wenn 32 mal eine 32bit ID nicht ausreicht, muss ROVs verwendet werden.
5. Über alle komplexen Pixel
1. a. Über alle N Samples
  1. i. ID extrahieren und Strahlenschnittpunkt mit Dreieck neu berechnen
  2. ii. Lichtschnittpunkt
  3. iii. Akkumulieren der Ausleuchtung
2. b. Teilen der akkumulierten Beleuchtung durch N
3. c. Schreiben des Ergebnisses

Zusätzliche Pixel-Klassifizierungsverfahren
Weitere Ausführungsformen zum Klassifizieren von Pixeln und zum Bestimmen, wie viele Strahlen bei der Verwendung von GPU-Raytracing ausgestrahlt werden müssen, können Folgendes beinhalten:

1. Berechnen von Unterschieden in der Helligkeit benachbarter Pixel
2. Berechnen von Unterschieden im 3-Tupel (primitivelD, instanzlDs, drawCalllD) von benachbarten Pixeln. Wenn die Tessellierung aktiviert ist, kann für jedes Dreieck, das die Tessellierung erzeugt, eine eindeutige ID erzeugt werden, die ein atomares Inkrement im GS verwendet, und diese anstelle einer primitivelD verwendet werden. Bei aktivierter Tessellierung entspricht die primitivelD der patchlD.
3. Berechnen von Unterschieden in Material-IDs oder Materialparametern benachbarter Pixel.
4. Berechnung von Tiefenunterschieden oder Oberflächennormalen benachbarter Pixel.
5. Kombinieren von 1-4.
6. Zeitliche Varianten von Kombinationen aus 1-4.

Hybrides Anti-Aliasing-System mit verzögertem Raytracing
Normalerweise wird Anti-Aliasing mit einem temporalen Bildschirmraumfilter oder mit Techniken wie Aggregate G-Buffer Anti-Aliasing (AGAA) durchgeführt. AGAA ist eine Technik für das Anti-Aliased Deferred Rendering komplexer Geometrien mit Grafikhardware. AGAA verwendet die Rasterungspipeline, um eine kompakte, vorgefilterte geometrische Darstellung bei jedem Pixel zu erzeugen. Shading erfolgt dann mit einer festen Rate, unabhängig von der geometrischen Komplexität. Durch die Entkopplung der Shading-Rate von der geometrischen Abtastrate reduziert der Algorithmus die Speicher- und Bandbreitenkosten eines Geometriepuffers und ermöglicht die Skalierung auf hohe Abtastraten bezüglich der Sichtbarkeit für Anti-Aliasing. Herkömmliche AGAA-Techniken adressieren jedoch komplexe Pixel nicht ausreichend, und AGAA-Techniken allein sind möglicherweise nicht ausreichend, um adaptiv neue Informationen pro Sub-Sample für komplexe Pixel zu erzeugen, was ein komplizierter Prozess ist, der typischerweise mehrere Rendering-Durchläufe über die Szene erfordert.
Weitere Ausführungsformen der vorliegenden Erfindung sind auf einen neuartigen alternativen Ansatz ausgerichtet, der nur bei Bedarf zusätzliche „Sub-Samples“ erzeugt. Die Qualität ist skalierbar, da beliebig viele Strahlen ausgegeben werden können. Die Lösung ist orthogonal zur temporalen Filterung. Gemäß solchen Ausführungsformen ist es nicht mehr notwendig, mehrere Rendering-/Rasterisierungs-Durchläufe über die Szene durchzuführen. Man kann selektiv nur für bestimmte Geometrietypen (z.B. Baumblätter etc.) mehr Samples erzeugen.
Gemäß einer oder mehreren Ausführungsformen wird eine vollständig skalierbare Anti-Aliasing-Lösung bereitgestellt, die das Beste aus Rasterung und beschleunigtem Raytracing durch Co-Verarbeitung (z.B. mittels einer Einheit zur Traversierung eines Baumes („Tree Traversal Unit“ TTU)) perfekt kombiniert, um einen Bedarf an GPUs zu erzeugen, die ein schnelles und hardwarebeschleunigtes Raytracing durchführen können.
Eine exemplarische Implementierung ist wie folgt:

1. Rendern eines Nicht-Anti-Aliasing G-Puffers (siehe unten für weitere Details).
2. Auffinden von Pixeln, die Diskontinuitäten in Tiefe, Helligkeit usw. umgeben.
3. Ausgeben einer Anzahl von Strahlen (z.B. beim Raytracing) durch die in Schritt 2 gefundenen Pixel, um G-Puffer-Samples zu erzeugen.

Eine weitere exemplarische Implementierung ist wie folgt:

1. Rendern eines Nicht-Anti-Aliasing-G-Puffers
1. a. Optional wird der MSAA-Tiefenpuffer nur mit zielunabhängiger Rasterung („Target Independent Rasterization“ TIR) gerendert.
2. b. Optionales Rendern von MSAA-Normalen mit TIR
2. Erkennen komplexer Pixel
1. a. Suche nach Tiefen-/Helligkeits- und anderen Unstimmigkeiten/Diskontinuitäten
2. b. Verwenden von MSAA-Tiefe und/oder MSAA-Normalen bei Bedarf
3. Zuweisen von Speicher für N-Sample von G-Puffer-Daten für komplexe Pixel
1. a. Es kann auch eine Liste von Sub-Samples pro komplexem Pixel verwendet werden.
4. Ausgeben von N Strahlen pro komplexem Pixel (dabei kann ein temporales Filter verwendet werden).
1. a. Aufzeichnen von G-Puffer-Daten für die nächstgelegenen Treffer
2. b. Optional kann beim Ergebnis iteriert werden, um adaptiv mehr Strahlen auszugeben.
5. Während verzögerter Ausleuchtung - Lichtstrahlentreffer werden auch für komplexe Pixel berechnet.

Adaptives Raytracing für temporales Anti-Aliasing
Bestehende temporale Anti-Aliasing-Algorithmen (TAA) sind heute in Videospielen weit verbreitet. Eine der größten Einschränkungen solcher Algorithmen ist, dass, wenn festgestellt wird, dass ein bestimmtes Pixel vom richtigen Wert abweicht, es keinen guten Ansatz gibt, um das Pixel korrekt zu färben, und dass nur eine Reihe von Heuristiken existiert, die je nach der Grundursache von Sampling-Problemen unterschiedlich arbeiten.
Typischerweise wählen die Heuristiken Sample-Farben aus, wenn die Bewegungsvektoren und Farben zwischen den Frames anzeigen, dass der normale Algorithmus nicht das Richtige tut. Anstatt eine Heuristik zur Farbwahl zu verwenden, werfen eine oder mehrere Ausführungsformen der vorliegenden Erfindung direkt zusätzliche Samples in die Szene und sammeln die Informationen, die zur Wahl der richtigen Farbe erforderlich sind.
Je nach bevorzugter Ausführungsform kann das temporale Anti-Aliasing nach dem nachfolgend beschriebenen Verfahren durchgeführt werden:

1. Verwenden von vorhandenen Rendereren (vorwärts oder verzögert....oder sogar Raytracing von primären Strahlen), um wie gewohnt gerasterte Bilder zu erzeugen. Wahrscheinlich mit einer MIP-Neigung in Richtung überscharf.
2. TAA-Durchlauf ausführen
1. a. *Erkennen, wenn TAA-Daten „schlecht“ sind / Farben wahrscheinlich nicht Teil des Pixels sind (dies zeigt sich als der Punkt, an dem ein „Farbenfesthalten/Clip“ benötigt wird; dabei kann auch ein intelligenterer historischer EMW-Varianz-Wert beibehalten werden).
2. b. TAA-Ergebnisse für dieses Pixel werden nicht verwendet, sondern stattdessen wird das Pixel für das Supersampling-Raytracing markiert. Dies kann mit einem Markierungswert oder einem Alphakanal erfolgen.
3. Versenden von AA-Strahlen für die Pixel, die während des TAA-Passes markiert wurden, Schreiben der Ausgabe in eine ZWEITE Textur.
- a. *MSAA Tap-Positionen + das temporale Subpixel-Offset, aber nie das zentrale Pixel, das bereits durch den Rasterdurchlauf erzeugt wurde.
- b. *Ausführen genau desgleichen „Pixel“-Shader-HLSL-Codes aus dem Rasterdurchlauf für die Strahlentreffer.
- c.*....einschließlich der Verwendung von beliebigen AO/SSRT/subsurface/shadow map etc. Bildschirm-Raum-Eingaben, deren Pixel für den regulären Rasterdurchlauf verwendet wurden. Das Raster-Shading sollte auf Konsistenz abgestimmt sein.
- d. Gemäß den Ausführungsformen kann das Verfahren auf undurchsichtige Oberflächen angewendet werden, unter der Annahme, dass Transparenz / Partikel / etc. ein eigenes Verfahren haben, um als separater Durchlauf durch die Pipeline zu gehen und mit AA zu arbeiten, genau wie in den heutigen Spiele-Engines.
4. Mischen der Raytracing-Anti-Aliasing-Textur-Ergebnisse mit dem Farbpuffer.
- a. *Verwenden einer Raster-Operation, da die Verwendung von Atomen im Raytracing-Durchlauf mit Atomen langsam wäre.

Adaptives temporales Anti-Aliasing
In einer Ausführungsform wird ein pragmatischer Algorithmus für das adaptive Echtzeit-Super-Sampling in Spielen bereitgestellt. Es erweitert das temporale Anti-Aliasing von gerasterten Bildern mit adaptivem Raytracing und entspricht den Einschränkungen einer kommerziellen Spiele-Engine und den heutigen GPU-Raytracing-APIs. Der Algorithmus entfernt Unschärfe- und Ghosting-Artefakte, die mit dem standardisierten temporalen Anti-Aliasing verbunden sind, und erreicht eine Qualität, die sich der 8-fachen Abtastung von Geometrie, Schattierung und Materialien annähert, während es sich innerhalb des von den meisten Spielen geforderten Budgets von Frames alle 33 ms bewegt.
Einführung
Das Aliasing von primär sichtbaren Oberflächen ist eine der grundlegendsten und anspruchsvollsten Einschränkungen der Computergrafik. Fast jedes Rendering tastet eine Oberfläche an Punkten innerhalb von Pixeln ab und erzeugt somit Fehler, wenn die abgetasteten Punkte nicht repräsentativ für das Pixel als Ganzes sind, d.h. wenn primäre Oberflächen unterabgetastet werden. Dies gilt unabhängig davon, ob die Punkte durch das Erzeugen eines Strahls oder mit dem amortisierten Raycasting der Rasterung getestet werden, und unabhängig davon, welcher Shading-Algorithmus verwendet wird. Natürlich könnten analytische Renderer, wie die perfekte Strahlverfolgung in Raum und Zeit, das Strahl(unter)abtastungs-Problem vollständig vermeiden; trotz einiger analytischer Lösungen für begrenzte Fälle bleiben Punkt-Samples von Strahl- oder Rasterschnittpunkten der einzige ausgereifte Ansatz für das effiziente Rendern komplexer Geometrien, Materialien und Schattierungen. Selbst „punktbasierte“ Renderer verfolgen oder platzieren Strahlen durch Rasterung.
Dieses Aliasing aufgrund von Unterabtastung manifestiert sich als gezackte Kanten, räumliches Rauschen und Flackern (zeitliches Rauschen). Versuche, diese Fehler durch breitere und ausgefeiltere Rekonstruktionsfilter im Raum (z.B. MLAA und FXAA) und in der Zeit (z.B. SMAA, TAA) zu verdecken, können diese Artefakte in Unschärfe (im Raum) oder Geisterbilder (Unschärfe in der Zeit) verwandeln.
Mit einer festen Abtastanzahl pro Pixel über ein Bild hinweg besteht die einzig wahre Lösung für Aliasing darin, die Abtastdichte zu erhöhen und damit das Frequenzband des abzutastenden Signals zu begrenzen. Die zunehmende Dichte hilft, löst das Problem aber nicht bei in Echtzeit notwendigen Raten: Supersampling (SSAA) verursacht einen linearen Anteil der Kosten proportional zu der Anzahl der Samples, während die Qualität nur mit der Quadratwurzel steigt; Multisampling (MSAA, CSAA, SBAA, SBAA, SRAA) tastet die Geometrie und die Materialien und Schattierungen mit unterschiedlichen Raten ab, um heuristisch die Kosten zu senken, wobei aber auch die Qualität gesenkt wird; und die Aggregation reduziert die Kosten noch aggressiver, begrenzt aber immer noch die Qualität bei praktischen Raten. Zur Bandbegrenzung der Szene verbessern die Materialvorfilterung durch MIP-Mapping und Varianten (z.B. LEAN), der Detaillierungsgrad der Geometrie und der Shader-Detailierungsgrad das Unterabtasten. Sie führen auch andere Probleme der Überblendung oder Popping (zeitliche und räumliche Diskontinuitäten) ein, während sie die Rendering-Systeme verkomplizieren und letztendlich das Problem nicht vollständig lösen.
Der Standard beim Echtzeit-Rendering ist es, viele der oben genannten Strategien gleichzeitig anzuwenden. Im besten Fall kann dies die Wahrnehmung von Aliasing-Artefakten durch den Betrachter nahezu ausschließen. Obwohl diese Erfolge bewundernswert sind, bleibt die primäre Aliasing-Anforderung für die Echtzeit offen, da es sich um spielspezifische Lösungen handelt, die eine hohe technische Komplexität und eine sorgfältige manuelle Anpassung der Szenen durch Künstler erfordern.
Diese Probleme mit unterabgetasteten Strahlen für Echtzeit und die unerwünschten Kosten oder Einschränkungen von Lösungen sind alle auf die feste Abtastanzahl pro Pixel zurückzuführen. Man kann immer Material-, Geometrie- oder Schattierungsmerkmale zwischen den Samples platzieren, um unbegrenzt Fehler zu erzeugen, wie z.B. eine sehr helle, sehr kleine Lichtquelle, die nur selten durch das Zentrum eines Pixels abgetastet wird.
Offline-Renderer mit Raytracing setzen seit langem hohe und adaptive Abtastanzahlen ein, um das Aliasing-Problem einfach und elegant zu lösen, wobei der Renderer eine hohe Mindestanzahl (z.B. 64) von Samples pro Pixel verfolgt und dann zusätzliche Samples innerhalb dieses Pixels verfolgt, bis eine maximale Schwelle oder stabile Verteilung erreicht ist. Bisher gab es keine praktische Möglichkeit, adaptiv in Echtzeit abzutasten, da fast jedes Echtzeit-Rendering auf den regulären Abtastraten der Rasterung basierte. Selbst der naive Ansatz, potenziell von Aliasing betroffene Pixel mittels einer Stenciting-Funktion zu bearbeiten und einen zweiten Durchgang mit hoher Dichte für sie durchzuführen, ist ineffizient: Die Rasterung erfordert die Verarbeitung der gesamten Geometrie, auch wenn nur wenige Pixel betroffen sind. So können beispielsweise Pixel, die ein Anti-Aliasing benötigen, basierend auf Course-Shading und hochauflösenden Geometriedurchläufen aggressiv identifiziert werden, und nahezu identische Ergebnisse zu SSAA können erzielt werden, wobei die Framezeit um 10% reduziert ist, obwohl die Anzahl der Shading-Samples halbiert ist.
Es wird ein Verfahren zur praktischen adaptiven Abtastung in Echtzeit unter Verwendung eines Hybrids aus Raytracing und Rasterung bereitgestellt. Dieses Verfahrenkann durch die kürzlich veröffentlichte DirectX Ray Tracing API (DXR) aktiviert werden. DXR ermöglicht die volle Interoperabilität zwischen Datenstrukturen und Shadern für beide Arten des Renderings über die gesamte Spiele-Engine hinweg, wodurch die bisherige Unmöglichkeit der Duplizierung zwischen Ray- und Raster-APIs für hybride Ansätze eliminiert wird.
Adaptives Abtasten baut darauf auf, dass gezeigt wird, wie man diese Techniken effizient für moderne Grafikhardware kombiniert, und wie man adaptives Abtasten im Rahmen von temporalem Anti-Aliasing nutzt, um die Kosten für gerasterte Samples dennoch rechtzeitig zu amortisieren, ohne Unschärfe oder Ghosting zu erzeugen.
Temporales Anti-Aliasing
Temporales Anti-Aliasing (TAA) ist schnell und recht gut in den Fällen, in denen es anwendbar ist. TAA wendet eine Subpixel-Verschiebung auf die Bildebenenverschiebung jedes Frames an und summiert dann einen exponentiell gewichteten gleitenden Mittelwert über vorherige Frames, die jeweils mit nur einem Sample pro Pixel gerendert wurden. In statischen Szenen nähert sich dies der Qualität des Vollbild-Supersamplings an.
Für dynamische Szenen werden mit TAA Samples aus dem akkumulierten Historien-Puffer „erneut projiziert“, indem Textur-Fetches entlang von Bewegungsvektoren pro Pixel versetzt werden, die zuvor durch den Rasterungsdurchlauf erzeugt wurden.
TAA schlägt in mehreren Fällen fehl. Wenn neue Bildschirmbereiche durch Objektbewegungen sichtbar (enthüllt) werden, sind diese nicht im Historien-Puffer vorhanden oder werden durch die Bewegungsvektoren falsch dargestellt. Eine Kameradrehung und eine Rückwärtsbewegung sorgen ebenfalls für ein deutliches Sichtbarmachen verdeckter Objekte an den Rändern des Bildschirms. Subpixel-Merkmale, wie Drähte und feine Materialdetails, können zwischen aufeinanderfolgenden Offset-Samples rutschen und werden daher im nächsten Bild nicht durch Bewegungsvektoren dargestellt. Transparente Oberflächen erzeugen Pixel, bei denen die Bewegungsvektoren von undurchsichtigen Objekten nicht mit der Gesamtbewegung der dargestellten Objekte übereinstimmen. Schließlich bewegen sich Schatten und Reflexionen nicht in Richtung der Bewegungsvektoren der von ihnen beschatteten Oberflächen.
Wenn TAA fehlerhaft arbeitet, erzeugt es entweder Geisterbilder (Unschärfen durch Integration falscher Werte) oder zeigt das ursprüngliche Aliasing als Zacken, Flackern und Rauschen an. Standard-TAA-Ansätze erkennen diese Fälle, indem sie die Historien-Samples mit der lokalen Nachbarschaft des entsprechenden Pixels im neuen Frame vergleichen. Wenn sie zu unterschiedlich erscheinen, verwendet TAA eine Vielzahl von Heuristiken, um im Farbraum abzuschneiden, zu halten oder zu interpolieren. Die besten Ansätze für diese Heuristiken ändern sich häufig, und es wurde bisher keine Allzweck-Lösung gefunden.
Beispielhafter Algorithmus
Ein beispielhaftes Verfahren ist auf eine Kompatibilität mit herkömmlichen Spiele-Engines ausgelegt, um die Stärken von TAA zu nutzen und gleichzeitig seine Fehler eindeutig und einfach anzugehen.
Eine beispielhafte Idee ist es, den Basisfall von TAA auf den meisten Pixeln laufen zu lassen und dann, anstatt zu versuchen, seine Fehler mit Heuristiken zu bekämpfen, stattdessen ein konservatives Segmentierungsbild auszugeben, wo und warum es versagen wird. Die komplexen Heuristiken von TAA bei Fehler-Pixeln können durch robuste Alternativen ersetzt werden, die sich an den Bildinhalt anpassen.
8 zeigt einen beispielhaften adaptiven temporalen Anti-Aliasing-Algorithmus 800 im Kontext einer DXR-Raytracing-API gemäß einer beispielhaften Ausführungsform. In der Figur stellen rechteckige Bilder 802A-F Visualisierungen von Puffern und abgerundete Rechtecke 804-812 Shader-Durchläufe dar. Es sind nicht alle Zwischenpuffer dargestellt. Wenn beispielsweise die Ausgabe des vorherigen Frames als Eingang zu TAA zurückgespeist wird, sind die zugehörigen Ping-Pong-Puffer nicht angezeigt.
In einer Ausführungsform wird in der Praxis ein Segmentierungsbild im Alpha-Kanal des TAA-Ausgangs gespeichert. Innerhalb des Bildes wird ein Raytracing-Supersampling auf einen ersten Satz von Pixeln angewendet. Der erste Satz von Pixeln stellt Fälle dar, in denen das Historien-Sample signifikant von der entsprechenden Nachbarschaft im neuen Frame abweicht (die bei TAA übliche Metrik für Farb-Clipping und Rauscherzeugung), sowie Pixel, die als Tiefenränder oder hohe Materialgradienten identifiziert werden. Das Hinzufügen der zusätzlichen Bedingungen stellt sicher, dass konservatives Raytracing allein auf potenzielle Aliasingquellen angewendet wird, die nicht von der Historie erkannt wurden. Ein zweiter Satz von Pixeln innerhalb des Bildes beinhaltet sichtbare bisher verdeckte Objekte. Für diese wäre Raytracing teuer, da sie groß sein können und oft nur für ein einzelnes Frame vorhanden sind, z.B. am Bildschirmrand während einer Drehung. Der zweite Satz von Pixeln kann durch Fehler im Bewegungsvektor identifiziert werden, und FXAA wird nur auf diesen Pixeln ausgeführt. Im Sonderfall des ersten Frames nach einem Kameraschnitt oder einer Szenenladung können alle Pixel innerhalb des zweiten Satzes liegend klassifiziert werden. Ein dritter Satz von Pixeln innerhalb des Segmentierungsbildes sind solche, bei denen TAA in seinem Basisfall erfolgreich war.
Da der Frame fast immer von TAA-Pixeln in dem dritten Satz dominiert wird, sind die Kosten für das Raytracing schnell amortisiert und erfordern ein Ray-Budget von weit weniger als einem Sample pro Pixel. Wenn beispielsweise sechs Prozent der Segmentierung innerhalb des ersten Satzes liegen, kann ein 8x-Raytracing-Supersampling adaptiv zu Kosten von weniger als 0,5 Strahlen pro Pixel eingesetzt werden. Dennoch ist die Qualität vergleichbar mit einem 8x-Supersampling insgesamt; wäre dies nicht der Fall, würden die Grenzen zwischen den segmentierten Regionen im Endergebnis flackern, da unterschiedliche Algorithmen verwendet werden. Dass es nicht notwendig ist, den Übergang an diesen Grenzen zu betrachten, zeigt, dass alle drei integrierten Strategien zu ähnlichen Ergebnissen unter diesem Segmentierungsansatz konvergieren.
In einer anderen Ausführungsform kann der erste Satz mittels Raytracing bearbeitet werden. Zum Beispiel können Strahlen bei den 8x-MSAA-n-rooks-Subpixel-Abtastmustern erzeugt werden, wobei die gleichen Samples wie bei 8x-TAA verwendet werden. Es darf kein zeitlicher Jitter verwendet werden. Das Raycasting ist als Shader der DXR-Strahlengeneration implementiert. Bei einem Strahlentreffer kann der gesamte UE4-Knoten-basierte Materialgraph und die Shading-Pipeline direkt ausgeführt werden, wobei der identische HLSL-Code mit der Raster-Pipeline verwendet wird. Da in Shadern zur Strahlerzeugung keine Vorwärtsdifferenzderivate verfügbar sind, können sie als unendlich angesetzt werden, um die höchste Auflösung von Texturen zu erzwingen. So kann man sich allein auf das Supersampling verlassen, um das Material-Aliasing zu behandeln (so arbeiten die meisten Film-Renderer für höchste Qualität); eine Alternative wäre es, Abstand und Orientierung zu nutzen, um analytisch ein MIP-Niveau auszuwählen, oder Strahlenunterschiede als Ersatz für Rasterunterschiede einzusetzen.
Die mit FXAA verarbeiteten Pixel kosten weniger als die innerhalb des dritten Satzes, bei dem TAA erfolgreich war, aber viel weniger als mit Supersampling-Raytracing bearbeitete Pixel. FXAA funktioniert hier gut, da es keine historischen Daten benötigt, und es läuft auf der Post-Tone-Mappping-Ausgabe mit niedrigem Dynamikbereich, um Speicherbandbreite einzusparen. Durch den Einsatz von FXAA nur bei sichtbar gemachten, vorher verdeckten Pixeln werden die Kosten im Vergleich zu typischen Vollbildanwendungen reduziert; typischerweise auf weniger als 15%, selbst bei schnellen Objekt- und Kamerabewegungen.
Fazit
Das Aliasing der primären Flächen ist ein Grundproblem in der Computergrafik. Eine beispielhafte Lösung für das Offline-Rendering ist das adaptive Supersampling. Dies war bisher für Raster-Renderer im Kontext komplexer Materialien und Szenen unpraktisch, da es keine Möglichkeit gab, wenige verstreut liegende Pixel effizient zu rastern. Selbst das effizienteste GPU-Raytracing benötigt duplizierte Shader- und Szenendaten. Während DXR die technische Herausforderung der Kombination von Rasterung und Raytracing löst, war die Anwendung von Raytracing zur Lösung von Aliasing durch Supersampling nicht trivial: zu wissen, welche Pixel mittels Supersampling zu bearbeiten sind, wenn nur 1 spp Input gegeben wird, und die Kosten auf etwas zu reduzieren, das skaliert werden soll, kann nicht durch naives Raytracing gelöst werden. Eine praktische Lösung für dieses Problem wird demonstriert, so praktisch, dass sie innerhalb einer kommerziellen Spiele-Engine läuft, in Echtzeit arbeitet, selbst mit der Hard- und Software der ersten Generation von Echtzeit-Raytracing-Hardware und Software, und sich mit der gesamten Shader-Pipeline verbindet. Wenn Film-Renderer Pixel für ein adaptives Supersample wählen, indem sie zuerst mehrfaches Raycasting pro Pixel durchführen, amortisieren sich diese Kosten stattdessen über viele Einzelbilder, indem der Historien-Puffer von TAA genutzt wird, um Aliasing zu erkennen. Zusätzlich werden große, transiente Bereiche des Aliasings aufgrund von vorher verdeckten und nun sichtbaren Objekten identifiziert und nachbearbeitete FXAA wird dort anstelle von aufwendigen Strahlen eingesetzt. Diese hybride Strategie nutzt die Vorteile der fortschrittlichsten Echtzeit-Anti-Aliasing-Strategien, vermeidet aber deren Grenzen. Durch die Rückführung von Supersampling-Ergebnissen in den TAA-Puffer wird die Wahrscheinlichkeit erhöht, dass diese Pixel kein Supersampling auf nachfolgenden Frames auslösen, was die Kosten weiter reduziert.
Obwohl verschiedene Ausführungsformen vorstehend beschrieben wurden, sollte klar sein, 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 sein.

Claims

Verfahren umfassend: Anwenden eines temporalen Anti-Aliasing, TAA, auf ein Bild; Identifizieren von Fehlerpixeln, welche sich von dem Anwenden des TAA auf das Bild ergeben; und Durchführen eines Anti-Aliasing auf jedes der Fehlerpixel, wobei eine Kombination von Raytracing und schnellem approximativen Anti-Aliasing, FXAA, eingesetzt wird.
Verfahren nach Anspruch 1, wobei die Fehlerpixel identifiziert werden, indem Ergebnisse des Anwendens des TAA auf das Bild eingesetzt werden, indem Zwischendaten eingesetzt werden oder indem eine Quellgeometrie eingesetzt wird.
Verfahren nach Anspruch 1 oder 2, wobei das Bild erzeugt wird, wobei ein Vorwärts-Rendering oder ein verzögertes Rendering eingesetzt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Fehlerpixel während des TAA identifiziert werden, wobei: das TAA einen historischen Wert für ein Pixel in einem vorherigen Frame mit aktuellen Werten von Nachbarpixeln in einem aktuellen Frame vergleicht, und das Pixel mit dem historischen Wert, welcher sich von den aktuellen Werten der Nachbarpixel um mehr als einen vorbestimmten Betrag unterscheidet, als ein Fehlerpixel identifiziert wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Fehlerpixel identifiziert werden, indem ein Tiefenwert für ein Pixel mit Tiefenwerten für Nachbarpixel verglichen wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Fehlerpixel identifiziert werden, indem ein Helligkeitswert für ein Pixel mit Helligkeitswerten für Nachbarpixel verglichen wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Fehlerpixel mittels eines Hinweiswertes markiert werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Fehlerpixel in eine Segmentierungsmaske einbezogen werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Durchführen des Anti-Aliasings ein Bestimmen einer Punkt-Abtast-Sichtbarkeit für einen Sub-Pixel-Bereich innerhalb jedes der Fehlerpixel aufweist, wobei ein GPU-Raytracing eingesetzt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei Ergebnisse des Durchführens des Anti-Aliasings auf den Fehlerpixeln mit den Ergebnissen des Anwendens des TAA auf das Bild kombiniert werden, um ein Ausgangsbild zu erzeugen.
Verfahren nach einem der vorhergehenden Ansprüche, darüber hinaus aufweisend: Identifizieren von einem oder von mehreren Pixeln, wo Daten in einem ursprünglichen Bild aufgrund einer Verdeckung oder eines Fehlens von temporalen Daten aus einem vorherigen Frame nicht existieren; und Durchführen von Anti-Aliasing auf den identifizierten Pixeln, wobei ein schnelles approximatives Anti-Aliasing, FXAA, eingesetzt wird.
System umfassend: einen Prozessor, welcher konfiguriert ist, um: ein temporales Anti-Aliasing, TAA, auf ein Bild anzuwenden; Fehlerpixel zu identifizieren, welche sich von dem Anwenden des TAA auf das Bild ergeben; und ein Anti-Aliasing auf jedes der Fehlerpixel auszuführen, wobei eine Kombination aus einem Raytracing und einem schnellen approximativen Anti-Aliasing, FXAA, eingesetzt wird; und einen Speicher, welcher konfiguriert ist, um Ergebnisse des Anti-Aliasing zu speichern.
System nach Anspruch 12, darüber hinaus konfiguriert, um ein Verfahren nach einem der Ansprüche 2 bis 11 auszuführen.
Computer lesbares Speichermedium, welches Anweisungen speichert, welche, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor Schritte eines Verfahrens nach einem der Ansprüche 1 bis 11 ausführt.