DE102019132001A1

DE102019132001A1 - Vorrichtung und verfahren für einen hierarchischen beamtracer

Info

Publication number: DE102019132001A1
Application number: DE102019132001.1A
Authority: DE
Inventors: Scott Janus; Prasoonkumar Surti; Karthik Vaidyanathan; Alexey Supikov; Gabor Liktor; Carsten Benthin; Philip Laws; Michael Doyle
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-12-28
Filing date: 2019-11-26
Publication date: 2020-07-02
Also published as: CN111383318A; US11315304B2; US11880928B2; US20200211263A1; US10762686B2; US20210049808A1; US20220327763A1

Abstract

Vorrichtung und Verfahren für einen hierarchischen Beamtracer. Eine Ausführungsform einer Vorrichtung umfasst zum Beispiel: einen Beam-Erzeuger zum Erzeugen von Beam-Daten, die einem in eine Grafikszene projizierten Beam zugeordnet sind; einen Bounding-Volume-Hierarchie (BVH) -Erzeuger zum Erzeugen von BVH-Daten, die mehrere hierarchisch angeordnete BVH-Knoten umfassen; eine hierarchische Beam-basierte Durchquerungseinheit, um zu bestimmen, ob der Beam einen aktuellen BVH-Knoten kreuzt, und, falls dies der Fall ist, den Beam reaktiv in N Child-Beams zu unterteilen, um ihn gegen den aktuellen BVH-Knoten zu prüfen, und/oder die BVH-Hierarchie weiter nach unten zu durchqueren, um einen neuen BVH-Knoten auszuwählen, wobei die hierarchische Beam-basierte Durchquerungseinheit aufeinanderfolgende kreuzende Child-Beams iterativ unterteilen und/oder fortfahren soll, die BVH-Hierarchie nach unten zu durchqueren, bis ein Blattknoten erreicht wird, mit dem sich mindestens ein endgültiger Child-Beam kreuzen soll; die hierarchische Beam-basierte Durchquerungseinheit mehrere Rays innerhalb des endgültigen Child-Beam erzeugen soll; und Kreuzungs-Hardware-Logik Kreuzungsprüfung für jegliche Rays ausführen soll, die den Blattknoten kreuzen, wobei die Kreuzungsprüfung Kreuzungen zwischen den Rays, die den Blattknoten kreuzen, und Grundelementen, die durch den Blattknoten begrenzt sind, bestimmen soll.

Description

HINTERGRUND
Gebiet der Erfindung
Diese Erfindung bezieht sich im Allgemeinen auf das Gebiet von Grafikprozessoren. Insbesondere bezieht sich die Erfindung auf eine Vorrichtung und ein Verfahren zum Ausführen effizienterer Raytracing-Operationen.
Beschreibung der artverwandten Technik
Raytracing ist eine Technik, bei der ein Lichttransport durch physikalisch-basiertes Rendern simuliert wird. Häufig verwendet in filmischem Rendern, wurde es bis vor wenigen Jahren als zu ressourcenintensiv für Echtzeit-Performance betrachtet. Eine der Schlüsseloperationen bei Raytracing ist die Verarbeitung einer Sichtbarkeitsabfrage für Ray-Szenen-Kreuzungen, bekannt als „Ray-Durchquerung“, wobei Ray-Szenen-Kreuzungen berechnet werden, indem Knoten in einer Hüllvolumenhierarchie (Bounding-Volume-Hierarchie - BVH) durchquert und gekreuzt werden.
Rauschunterdrückung ist zu einem kritischen Merkmal für Echtzeit-Raytracing mit gleichmäßigen, rauschfreien Bildern geworden. Rendern kann über ein verteiltes System auf mehreren Geräten hinweg ausgeführt werden, bisher arbeiten jedoch die existierenden Rauschunterdrückungs-Frameworks alle auf einer einzelnen Instanz auf einer einzelnen Maschine. Wenn Rendern über mehrere Geräte erfolgt, können nicht alle gerenderten Pixel für die Berechnung eines rauschunterdrückten Abschnitts des Bildes zugänglich sein.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung kann von der folgenden detaillierten Beschreibung in Verbindung mit den folgenden Zeichnungen erhalten werden, in denen gilt:

1 ist ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor, der einen oder mehrere Prozessorkerne und Grafikprozessoren hat;
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors mit einem oder mehreren Prozessorkernen, einer integrierten Speichersteuerung und einem integrierten Grafikprozessor;
3 ist ein Blockdiagramm einer Ausführungsform eines Grafikprozessors, der eine spezielle Grafikverarbeitungseinheit sein kann, oder ein Grafikprozessor sein kann, der in mehrere Verarbeitungskerne integriert ist;
4 ist ein Blockdiagramm einer Ausführungsform einer Grafikverarbeitungsmaschine für einen Grafikprozessor;
5 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors;
Die 6A-B veranschaulichen Beispiele von Ausführungsschaltungen und Logik;
7 veranschaulicht ein Grafikprozessor-Ausführungseinheits-Anweisungsformat gemäß einer Ausführungsform;
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors, der eine Grafik-Pipeline, eine Medien-Pipeline, eine Anzeigemaschine, eine Thread-Ausführungslogik und eine Render-Ausgabe-Pipeline beinhaltet;
9A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat gemäß einer Ausführungsform veranschaulicht;
9B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlssequenz gemäß einer Ausführungsform veranschaulicht;
10 veranschaulicht eine beispielhafte Grafik-Software-Architektur für ein Datenverarbeitungssystem gemäß einer Ausführungsform;
Die 11A-B veranschaulichen ein beispielhaftes IP-Kernentwicklungssystem, das verwendet werden kann, um eine integrierte Schaltung und eine beispielhafte Paketanordnung zu produzieren;
12 veranschaulicht eine beispielhafte integrierte System-ona-Chip-Schaltung, die durch Verwenden eines oder mehrerer IP-Kerne gemäß einer Ausführungsform hergestellt werden kann;
Die 13A-B veranschaulichen einen beispielhaften Grafikprozessor einer integrierten System-on-a-Chip-Schaltung, der durch Verwenden eines oder mehrerer IP-Kerne hergestellt werden kann;
Die 14A-B veranschaulichen beispielhafte Grafikprozessorarchitekturen;
15 veranschaulicht eine Ausführungsform einer Architektur zum Ausführen eines ursprünglichen Trainings einer Architektur zum maschinellen Lernen;
16 veranschaulicht eine Ausführungsform, in der eine maschinell lernende Maschine während der Laufzeit kontinuierlich trainiert und aktualisiert wird;
17 veranschaulicht eine andere Ausführungsform, in der eine maschinell lernende Maschine während der Laufzeit kontinuierlich trainiert und aktualisiert wird;
Die 18A-B veranschaulichen Ausführungsformen, in denen Daten zum maschinellen Lernen in einem Netzwerk geteilt werden; und
19 veranschaulicht eine Ausführungsform eines Verfahrens zum Trainieren einer maschinell lernenden Maschine;
20 veranschaulicht eine Ausführungsform, bei der Knoten Geisterbereichsdaten austauschen, um verteilte Rauschunterdrückungsoperationen auszuführen;
21 veranschaulicht eine Ausführungsform einer Architektur, bei der Bildrender- und Rauschunterdrückungsoperationen über mehrere Knoten hinweg verteilt sind;
22 veranschaulicht zusätzliche Details einer Architektur zum verteilten Rendern und zur Rauschunterdrückung;
23 veranschaulicht ein Verfahren gemäß einer Ausführungsform der Erfindung;
24 veranschaulicht eine Ausführungsform eines Verfahrens zum maschinellen Lernen;
25 veranschaulicht mehrere verbundene Mehrzweck-Grafikprozessoren;
26 veranschaulicht einen Satz von Faltungsschichten und vollständig verbundenen Schichten zur Implementierung von maschinellem Lernen;
27 veranschaulicht eine Ausführungsform einer Faltungsschicht;
28 veranschaulicht ein Beispiel eines Satzes verbundener Knoten in einer Implementierung von maschinellem Lernen;
29 veranschaulicht eine Ausführungsform eines Trainings-Frameworks, innerhalb dessen ein neuronales Netzwerk durch Verwenden eines Trainingsdatensatzes lernt;
30A veranschaulicht Beispiele für Modellparallelität und Datenparallelität;
30B veranschaulicht ein Beispiel eines System-on-a-Chip (SoC);
31 veranschaulicht ein Beispiel einer Verarbeitungsarchitektur, die Raytracing-Kerne und Tensorkerne beinhaltet;
32 Veranschaulicht ein Beispiel eines Beam;
33 veranschaulicht eine Ausführungsform einer Vorrichtung zum Ausführen von Beamtracing;
34 Veranschaulicht ein Beispiel einer Beam-Hierarchie;
35 veranschaulicht ein Verfahren zum Ausführen von Beamtracing;
36 veranschaulicht ein Beispiel einer verteilten Bea mtraci ng-Masch i ne;
Die 37-38 veranschaulichen ein Beispiel einer Komprimierung, die in einem Raytracing-System ausgeführt wird;
39 veranschaulicht ein Verfahren gemäß einer Ausführungsform der Erfindung;
40 veranschaulicht eine beispielhafte Hybrid-Raytracing-Vorrichtung;
41 veranschaulicht Beispiele von Stapeln, die für Raytracing-Operationen verwendet werden;
42 veranschaulicht zusätzliche Details für eine Ausführungsform einer Hybrid-Raytracing-Vorrichtung;
43 Veranschaulicht ein Beispiel einer Hüllvolumenhierarchie;
44 veranschaulicht ein Beispiel eines Aufrufstapels und einer Durchquerungsstatusspeicherung;
45 veranschaulicht eine beispielhafte BVH und einen Satz von unterschiedlichen Volumentypen;
46 veranschaulicht eine Vorrichtung zum Ausführen von Multiform-Durchquerungs-/Kreuzungsoperationen;
47 Veranschaulicht ein Ausführungsform einer Hüllvolumenhierarchie;
48 veranschaulicht, wie Child-Beams in einer Ausführungsform erzeugt werden;
49 veranschaulicht eine Ausführungsform einer Architektur zum Ausführen von Beamtracing-Operationen; und
50 veranschaulicht ein Verfahren gemäß einer Ausführungsform der Erfindung.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zu Zwecken der Erläuterung zahlreiche spezifische Details dargelegt, um ein sorgfältiges Verständnis der unten beschriebenen Ausführungsformen der Erfindung bereitzustellen. Es ist jedoch für den Fachmann offensichtlich, dass die Ausführungsformen der Erfindung ohne einige dieser spezifischen Details praktiziert werden können. In anderen Fällen sind gut bekannte Strukturen und Geräte in Blockdiagrammform gezeigt, um zu vermeiden, dass die zugrunde liegenden Prinzipien der Ausführungsformen der Erfindung verdeckt werden.
BEISPIELHAFTE GRAFIKPROZESSORARCHITEKTUREN UND DATENTYPEN
Systemübersicht
1 ist ein Blockdiagramm von Verarbeitungssystem 100 gemäß einer Ausführungsform. In verschiedenen Ausführungsformen beinhaltet das System 100 einen oder mehrere Prozessoren 102 und einen oder mehrere Grafikprozessoren 108 und kann ein Einzelprozessor-Desktop-System, ein Multiprozessor-Workstation-System oder ein Server-System mit einer großen Anzahl von Prozessoren 102 oder Prozessorkernen 107 sein. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in einer integrierten System-on-a-Chip (SoC) -Schaltung zur Verwendung in mobilen, tragbaren oder eingebetteten Geräten enthalten ist.
In einer Ausführungsform kann das System 100 eine Serverbasierte Spieleplattform, eine Spielekonsole, einschließlich einer Spiele- und Medienkonsole, einer mobilen Spielekonsole, einer tragbaren Spielekonsole oder einer Online-Spielekonsole beinhalten oder darin enthalten sein. In einigen Ausführungsformen ist das System 100 ein Mobiltelefon, ein Smartphone, ein Tablet-Computergerät oder ein mobiles Internetgerät. Das Verarbeitungssystem 100 kann auch ein am Körper tragbares Gerät, wie zum Beispiel ein am Körper tragbares Smartwatch-Gerät, Smart-Eyewear-Gerät, Augmented-Reality-Gerät oder Virtual-Reality-Gerät, beinhalten, damit gekoppelt oder darin integriert sein. In einigen Ausführungsformen ist das Verarbeitungssystem 100 ein Fernseh- oder Set-Top-Box-Gerät mit einem oder mehreren Prozessoren 102 und einer Grafikschnittstelle, die durch einen oder mehrere Grafikprozessoren 108 erzeugt wird.
In einigen Ausführungsformen beinhalten der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107, um Anweisungen zu verarbeiten, die, wenn ausgeführt, Operationen für System- und Benutzersoftware ausführen. In einigen Ausführungsformen ist jeder der einen oder mehreren Prozessorkerne 107 dazu ausgelegt, spezifischen Anweisungssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Anweisungssatz 109 das Complex-Instruction-Set-Computing (CISC), das Reduced-Instruction-Set-Computing (RISC) oder das Computing über ein Very-Long-Instruction-Word (VLIW) erleichtern. Mehrere Prozessorkerne 107 können jeweils einen unterschiedlichen Anweisungssatz 109 verarbeiten, der Anweisungen beinhalten kann, um die Emulation anderer Anweisungssätze zu erleichtern. Der Prozessorkern 107 kann auch andere Verarbeitungsgeräte, wie zum Beispiel einen digitalen Signalprozessor (DSP), beinhalten.
In einigen Ausführungsformen beinhaltet der Prozessor 102 Cache-Speicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Ebenen von internen Caches haben. In einigen Ausführungsformen wird der Cache-Speicher unter verschiedenen Komponenten des Prozessors 102 geteilt. In einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (zum Beispiel einen Level-3 (L3) -Cache oder einen Last-Level-Cache (LLC)) (nicht gezeigt), der durch Verwenden bekannter Cache-Kohärenztechniken unter den Prozessorkernen 107 geteilt werden kann. Zusätzlich ist in dem Prozessor 102 Registerdatei 106 enthalten, die unterschiedliche Typen von Registern zur Speicherung unterschiedlicher Typen von Daten (zum Beispiel Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister) beinhalten kann. Einige Register können Mehrzweckregister sein, während andere Register spezifisch für das Design des Prozessors 102 sein können.
In einigen Ausführungsformen sind ein oder mehrere Prozessoren 102 mit einem oder mehreren Schnittstellenbussen 110 gekoppelt, um Kommunikationssignale, wie zum Beispiel Adressen, Daten oder Steuersignale, zwischen dem Prozessor 102 und anderen Komponenten in dem System 100 zu übertragen. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus, wie zum Beispiel eine Version des Direct-Media-Interface (DMI) -Busses sein. Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral-Component-Interconnect-Busse (zum Beispiel PCI, PCI Express), Speicherbusse oder andere Typen von Schnittstellenbussen beinhalten. In einer Ausführungsform beinhalten der/die Prozessor(en) 102 integrierte Speichersteuerung 116 und Platform-Controller-Hub 130. Der Speichercontroller 116 erleichtert Kommunikation zwischen einem Speichergerät und anderen Komponenten des Systems 100, während der Platform-Controller-Hub (PCH) 130 Verbindungen zu I/O-Geräten über einen lokalen I/O-Bus bereitstellt.
Speichergerät 120 kann ein Dynamic-Random-Access-Memory (DRAM) -Gerät, ein Static-Random-Access-Memory (SRAM) -Gerät, ein Flash-Speichergerät, ein Phasenänderungsspeichergerät oder ein anderes Speichergerät sein, das eine geeignete Leistung hat, um als Prozessspeicher zu dienen. In einer Ausführungsform kann das Speichergerät 120 als Systemspeicher für das System 100 arbeiten, um Daten 122 und Anweisungen 121 zur Verwendung zu speichern, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Die Speichersteuerung 116 ist auch mit optionalem externen Grafikprozessor 112 gekoppelt, der mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen auszuführen. In einigen Ausführungsformen kann Anzeigegerät 111 mit dem/den Prozessor(en) 102 verbunden sein. Das Anzeigegerät 111 kann eine oder mehrere eines internen Anzeigegeräts, wie zum Beispiel ein mobiles elektronisches Gerät oder ein Laptop-Gerät oder ein externes Anzeigegerät sein, die über eine Anzeigeschnittstelle (zum Beispiel DisplayPort, usw.) angeschlossen sind. In einer Ausführungsform kann das Anzeigegerät 111 ein Head-Mounted-Display (HMD), wie zum Beispiel ein stereoskopisches Anzeigegerät zur Verwendung in Virtual-Reality (VR) -Anwendungen oder Augmented-Reality (AR) -Anwendungen, sein.
In einigen Ausführungsformen ermöglicht es der Plattform-Controller-Hub 130 Peripheriegeräten über einen Hochgeschwindigkeits-I/O-Bus mit dem Speichergerät 120 und dem Prozessor 102 verbunden zu sein. Die I/O-Peripheriegeräte beinhalten, sind jedoch nicht beschränkt auf, Audiosteuerung 146, Netzwerksteuerung 134, Firmware-Schnittstelle 128, drahtlosen Transceiver 126, Berührungssensoren 125, Datenspeicherungsgerät 124 (zum Beispiel Festplattenlaufwerk, Flash-Speicher, usw.). Das Datenspeicherungsgerät 124 kann über eine Speicherungsschnittstelle (zum Beispiel SATA) oder über einen Peripheriebus, wie zum Beispiel einen Peripheral-Component-Interconnect-Bus (zum Beispiel PCI, PCI Express), verbunden sein. Die Berührungssensoren 125 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren beinhalten. Der drahtlose Transceiver 126 kann ein Wi-Fi-Transceiver, ein Bluetooth-Transceiver oder ein Mobilfunknetzwerk-Transceiver, wie zum Beispiel ein 3G-, 4G- oder Long-Term-Evolution (LTE) -Transceiver, sein. Die Firmware-Schnittstelle 128 ermöglicht Kommunikation mit System-Firmware und kann zum Beispiel ein Unified-Extensible-Firmware-Interface (UEFI) sein. Die Netzwerksteuerung 134 kann eine Netzwerkverbindung zu einem verdrahteten Netzwerk ermöglichen. In einigen Ausführungsformen ist eine Hochleistungsnetzwerksteuerung (nicht gezeigt) mit dem Schnittstellenbus 110 gekoppelt. Die Audiosteuerung 146 ist in einer Ausführungsform eine Multikanal-Hochauflösungs-Audiosteuerung. In einer Ausführungsform umfasst das System 100 eine optionale Legacy-I/O-Steuerung 140 zum Koppeln von Legacy-Geräten (zum Beispiel Personal System 2 (PS/2)) an das System. Der Platform-Controller-Hub 130 kann auch mit einer oder mehreren Universal-Serial-Bus (USB) -Steuerungen 142 verbunden sein, die mit Eingabegeräten, wie zum Beispiel Tastatur- und Mauskombinationen 143, Kamera 144 oder anderen USB-Eingabegeräte verbunden sind.
Es ist darauf hinzuweisen, dass das gezeigte System 100 beispielhaft und nicht beschränkend ist, da auch andere Typen von Datenverarbeitungssystemen verwendet werden können, die unterschiedlich konfiguriert sind. Zum Beispiel kann eine Instanz der Speichersteuerung 116 und des Platform-Controller-Hubs 130 in einen speziellen externen Grafikprozessor, wie zum Beispiel den externen Grafikprozessor 112, integriert sein. In einer Ausführungsform können der Platform-Controller-Hub 130 und/oder die Speichersteuerung 1160 außerhalb des einen oder der mehreren Prozessoren 102 sein. Zum Beispiel kann das System 100 eine externe Speichersteuerung 116 und einen Platform-Controller-Hub 130 beinhalten, die als ein Speichersteuerungs-Hub und Peripheriesteuerungs-Hub innerhalb eines mit dem/den Prozessor(en) 102 in Kommunikation stehenden System-Chipsatzes konfiguriert sein können.
2 ist ein Blockdiagramm einer Ausführungsform von Prozessor 200 mit einem oder mehreren Prozessorkernen 202A-202N, integrierter Speichersteuerung 214 und integriertem Grafikprozessor 208. Diese Elemente von 2 mit den gleichen Bezugszeichen (oder Namen) wie die Elemente jeglicher anderen Figur hierin können auf jegliche ähnliche Weise wie die anderswo hierin beschriebenen arbeiten oder funktionieren, sind jedoch nicht auf solche beschränkt. Der Prozessor 200 kann zusätzliche Kerne bis zu dem und einschließlich des zusätzlichen Kerns 202N, der durch die Kästchen mit gestrichelten Linien dargestellt wird, beinhalten. Jeder der Prozessorkerne 202A-202N beinhaltet eine oder mehrere interne Cache-Einheiten 204A-204N. In einigen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf eine oder mehrere geteilte Cache-Einheiten 206.
Die internen Cache-Einheiten 204A-204N und die geteilten Cache-Einheiten 206 stellen eine Cache-Speicherhierarchie innerhalb des Prozessors 200 dar. Die Cache-Speicherhierarchie kann mindestens einen Anweisungs- und Daten-Cache-Level innerhalb jedes Prozessorkerns und einen oder mehrere Level eines geteilten Caches auf mittlerem Level, wie zum Beispiel einen Level 2 (L2), Level 3 (L3), Level 4 (L4), oder andere Cache-Level, beinhalten, wobei der höchste Cache-Level vor dem externen Speicher als der LLC klassifiziert wird. In einigen Ausführungsformen erhält die Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A-204N aufrecht.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von einer oder mehreren Bussteuerungseinheiten 216 und Systemagentenkern 210 beinhalten. Die eine oder mehreren Bussteuerungseinheiten 216 verwalten einen Satz von Peripheriebussen, wie zum Beispiel einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 210 stellt Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. In einigen Ausführungsformen umfasst der Systemagentenkern 210 einen oder mehrere integrierte Speichersteuerungen 214, um den Zugriff auf verschiedene externe Speichergeräte (nicht gezeigt) zu verwalten.
In einigen Ausführungsformen beinhalten einer oder mehrere der Prozessorkerne 202A-202N Unterstützung für gleichzeitiges Multi-Threading. In einer solchen Ausführungsform beinhaltet der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A-202N während der Multi-Thread-Verarbeitung. Der Systemagentenkern 210 kann zusätzlich eine Power-Control-Unit (PCU) beinhalten, die Logik und Komponenten zum Regeln des Leistungsstatus der Prozessorkerne 202A-202N und des Grafikprozessors 208 beinhaltet.
In einigen Ausführungsformen beinhaltet der Prozessor 200 zusätzlich einen Grafikprozessor 208, um Grafikverarbeitungsoperationen auszuführen. In einigen Ausführungsformen ist der Grafikprozessor 208 mit dem Satz von geteilten Cache-Einheiten 206 und dem Systemagentenkern 210 einschließlich der einen oder mehreren integrierten Speichersteuerungen 214 gekoppelt. In einigen Ausführungsformen beinhaltet der Systemagentenkern 210 auch Anzeigesteuerung 211, um die Grafikprozessorausgabe an eine oder mehrere gekoppelte Anzeigen anzusteuern. In einigen Ausführungsformen kann die Anzeigesteuerung 211 auch ein separates Modul sein, das über mindestens eine Verbindung mit dem Grafikprozessor gekoppelt ist, oder sie kann in den Grafikprozessor 208 integriert sein.
In einigen Ausführungsformen wird ringbasierte Verbindungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch eine alternative Verbindungseinheit verwendet werden, wie zum Beispiel eine Punkt-zu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Techniken, einschließlich Techniken, die in dem Fachgebiet gut bekannt sind. In einigen Ausführungsformen ist der Grafikprozessor 208 über I/O-Verbindung 213 mit der Ringverbindung 212 gekoppelt.
Die beispielhafte I/O-Verbindung 213 stellt mindestens eine von mehreren Variationen von I/O-Verbindungen dar, einschließlich einer On-Package-I/O-Verbindung, die die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsspeichermodul 218, wie zum Beispiel einem eDRAM-Modul, erleichtert. In einigen Ausführungsformen verwenden jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als einen geteilten Last-Level-Cache.
In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, die dieselbe Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Anweisungssatzarchitektur (Instruction-Set-Architecture - ISA) heterogen, wobei einer oder mehrere der Prozessorkerne 202A-202N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne einen Untersatz des ersten Anweisungssatzes oder einen unterschiedlichen Anweisungssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Mikroarchitektur heterogen, wobei ein oder mehrere Kerne mit einem relativ höheren Stromverbrauch mit einem oder mehreren Kernen mit einem niedrigerem Stromverbrauch gekoppelt sind. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte SoC-Schaltung mit den veranschaulichten Komponenten zusätzlich zu anderen Komponenten implementiert werden.
3 ist ein Blockdiagramm von Grafikprozessor 300, der eine spezielle Grafikverarbeitungseinheit sein kann, oder ein in mehrere Verarbeitungskerne integrierter Grafikprozessor sein kann. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete I/O-Schnittstelle mit Registern in dem Grafikprozessor und mit in dem Prozessorspeicher platzierten Befehlen. In einigen Ausführungsformen beinhaltet der Grafikprozessor 300 Speicherschnittstelle 314, um auf Speicher zuzugreifen. Die Speicherschnittstelle 314 kann eine Schnittstelle zu lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren geteilten externen Caches und/oder zu Systemspeicher sein.
In einigen Ausführungsformen beinhaltet der Grafikprozessor 300 auch Anzeigesteuerung 302, um Anzeigeausgabedaten an Anzeigegerät 320 anzusteuern. Die Anzeigesteuerung 302 beinhaltet Hardware für eine oder mehrere Überlagerungsebenen zur Anzeige und Zusammensetzung mehrerer Schichten von Video- oder Benutzerschnittstellenelementen. Das Anzeigegerät 320 kann ein internes oder externes Anzeigegerät sein. In einer Ausführungsform ist das Anzeigegerät 320 ein Head-Mounted-Display-Gerät, wie zum Beispiel ein Virtual-Reality (VR) -Anzeigegerät oder ein Augmented-Reality (AR) -Anzeigegerät. In einigen Ausführungsformen beinhaltet der Grafikprozessor 300 Videocodec-Engine 306 zum Codieren, Decodieren oder Transcodieren von Medien in, von oder zwischen einem oder mehreren Mediencodierungsformaten, einschließlich, aber nicht beschränkt auf, Moving-Picture-Experts-Group (MPEG) -Formate, wie zum Beispiel MPEG-2, Advanced-Video-Coding (AVC) -Formate, wie zum Beispiel H.264/MPEG-4 AVC, sowie die Society-of-Motion-Picture & Television-Engineers (SMPTE) 421M/VC-1 und Joint-Photographic-Experts-Group (JPEG) -Formate, wie zum Beispiel JPEG und Motion JPEG (MJPEG) -Formate.
In einigen Ausführungsformen beinhaltet der Grafikprozessor 300 Block-Image-Transfer (BLIT) -Engine 304, um zweidimensionale (2D) Rasteroperationen auszuführen, die zum Beispiel Bitgrenzenblockübertragungen beinhalten. In einer Ausführungsform werden jedoch 2D-Grafikoperationen durch Verwenden einer oder mehrerer Komponenten von Graphics-Processing-Engine (GPE) 310 ausgeführt. In einigen Ausführungsformen ist die GPE 310 eine Rechenmaschine zum Ausführen von Grafikoperationen, einschließlich dreidimensionaler (3D) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen beinhaltet die GPE 310 3D-Pipeline 312 zum Ausführen von 3D-Operationen, wie zum Beispiel zum Rendern dreidimensionaler Bilder und Szenen durch Verwenden von Verarbeitungsfunktionen, die auf 3D-Grundelementformen (zum Beispiel Rechteck, Dreieck, usw.) einwirken. Die 3D-Pipeline 312 beinhaltet programmierbare und Festfunktionselemente, die verschiedene Aufgaben innerhalb des Element- und/oder Spawn-Ausführungs-Threads für 3D/Media-Subsystem 315 ausführen. Während die 3D-Pipeline 312 zum Ausführen von Medienoperationen verwendet werden kann, beinhaltet eine Ausführungsform der GPE 310 auch Medien-Pipeline 316, die spezifisch zum Ausführen von Medienoperationen, wie zum Beispiel Videonachverarbeitung und Bildverbesserung, verwendet wird.
In einigen Ausführungsformen beinhaltet die Medien-Pipeline 316 Festfunktions- oder programmierbare Logikeinheiten, um eine oder mehrere spezialisierte Medienoperationen, wie zum Beispiel Videodecodierbeschleunigung, Video-De-Interlacing und Videocodierbeschleunigung anstelle oder im Auftrag der Videocodec-Engine 306 auszuführen. In einigen Ausführungsformen beinhaltet die Medien-Pipeline 316 zusätzlich eine Thread-Spawn-Einheit, um Threads zur Ausführung auf dem 3D/Media-Subsystem 315 hervorzubringen. Die hervorgebrachten Threads führen Berechnungen für die Medienoperationen an einer oder mehreren in dem 3D/Media-Subsystem 315 enthaltenen Grafikausführungseinheiten aus.
In einigen Ausführungsformen beinhaltet das 3D/Media-Subsystem 315 eine Logik zum Ausführen von Threads, die durch die 3D-Pipeline 312 und die Medien-Pipeline 316 hervorgebracht wurden. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanforderungen an das 3D/Media-Subsystem 315, das eine Thread-Versendelogik zum Vermitteln und Versenden der verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen beinhaltet. Die Ausführungsressourcen beinhalten ein Array von Grafikausführungseinheiten, um die 3D- und Medien-Threads zu verarbeiten. In einigen Ausführungsformen beinhaltet das 3D/Media-Subsystem 315 einen oder mehrere interne Caches für Thread-Anweisungen und Daten. In einigen Ausführungsformen beinhaltet das Subsystem auch geteilten Speicher, der Register und adressierbaren Speicher beinhaltet, um Daten zwischen Threads zu teilen und Ausgabedaten zu speichern.
Graphics-Processing-Engine
4 ist ein Blockdiagramm von Graphics-Processing-Engine 410 eines Grafikprozessors gemäß einigen Ausführungsformen. In einer Ausführungsform ist die Graphics-Processing-Engine (GPE) 410 eine Version der in 3 gezeigten GPE 310. Elemente von 4 mit den gleichen Bezugszeichen (oder Namen) wie die Elemente jeglicher anderen Figur hierin können auf jegliche ähnliche Weise wie die anderswo hierin beschriebenen arbeiten oder funktionieren, sind jedoch nicht auf solche beschränkt. Zum Beispiel sind die 3D-Pipeline 312 und die Medien-Pipeline 316 von 3 veranschaulicht. Die Medien-Pipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und kann nicht explizit in der GPE 410 enthalten sein. Zum Beispiel und in mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
In einigen Ausführungsformen ist die GPE 410 mit Befehls-Streamer 403, der der 3D-Pipeline 312 und/oder den Medien-Pipelines 316 einen Befehls-Stream bereitstellt, gekoppelt oder beinhaltet diesen. In einigen Ausführungsformen ist der Befehls-Streamer 403 mit Speicher gekoppelt, der ein Systemspeicher oder einer oder mehrere von internem Cache-Speicher und geteiltem Cache-Speicher sein kann. In einigen Ausführungsformen empfängt der Befehls-Streamer 403 Befehle von dem Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medien-Pipeline 316. Die Befehle sind Richtlinien, die von einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 312 und die Medien-Pipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Batch-Befehlspuffer beinhalten, die Batches von mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Verweise auf in Speicher gespeicherte Daten beinhalten, wie zum Beispiel, aber nicht beschränkt auf Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 312 und die Medien-Pipeline 316 verarbeiten die Befehle und Daten durch Ausführen von Operationen über Logik innerhalb der jeweiligen Pipelines oder durch Versenden eines oder mehrerer Ausführungs-Threads an Grafikkern-Array 414. In einer Ausführungsform beinhaltet das Grafikkern-Array 414 einen oder mehrere Blöcke von Grafikkernen (zum Beispiel Grafikkern(e) 415A, Grafikkern(e) 415B), wobei jeder Block einen oder mehrere Grafikkerne beinhaltet. Jeder Grafikkern beinhaltet einen Satz von Grafikausführungsressourcen, die allgemeine und grafikspezifische Ausführungslogik zum Ausführen von Grafik- und Rechenoperationen, sowie Festfunktions-Texturverarbeitungslogik und/oder Logik für maschinelles Lernen und Beschleunigungslogik für künstliche Intelligenz beinhalten.
In verschiedenen Ausführungsformen beinhaltet die 3D-Pipeline 312 Festfunktions- und programmierbare Logik, um ein oder mehrere Shader-Programme, wie zum Beispiel Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Berechnungs-Shader oder andere Shader-Programme zu verarbeiten, indem die Anweisungen verarbeitet und Ausführungs-Threads zu dem Grafikkern-Array 414 versendet werden. Das Grafikkern-Array 414 stellt einen einheitlichen Block von Ausführungsressourcen zur Verwendung bei dem Verarbeiten dieser Shader-Programme bereit. Die Mehrzweckausführungslogik (zum Beispiel Ausführungseinheiten) innerhalb des Grafikkerns/der Grafikkerne 415A-414B des Grafikkern-Arrays 414 beinhaltet Unterstützung für verschiedene 3D-API-Shader-Sprachen und kann mehrere gleichzeitige Ausführungs-Threads ausführen, die mehreren Shadern zugeordnet sind.
In einigen Ausführungsformen beinhaltet das Grafikkern-Array 414 auch eine Ausführungslogik zum Ausführen von Medienfunktionen, wie zum Beispiel Video- und/oder Bildverarbeitung. In einer Ausführungsform beinhalten die Ausführungseinheiten zusätzlich Mehrzwecklogik, die programmierbar ist, um parallele Mehrzweck-Berechnungsoperationen zusätzlich zu Grafikverarbeitungsoperationen auszuführen. Die Mehrzwecklogik kann Verarbeitungsoperationen parallel oder in Verbindung mit Mehrzwecklogik innerhalb des Prozessorkerns/der Prozessorkerne 107 von 1 oder des Kerns 202A-202N wie in 2 ausführen.
Ausgabedaten, die durch Threads erzeugt werden, die auf dem Grafikkern-Array 414 ausgeführt werden, können Daten an einen Speicher in Unified-Return-Buffer (URB) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen unterschiedlichen Threads zu senden, die auf dem Grafikkern-Array 414 ausgeführt werden. In einigen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisation zwischen Threads auf dem Grafikkern-Array und der Festfunktions-Logik innerhalb geteilter Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist das Grafikkern-Array 414 skalierbar, sodass das Array eine variable Anzahl von Grafikkernen beinhaltet, die jeweils eine variable Anzahl von Ausführungseinheiten haben, basierend auf der Zielleistung und dem Leistungsniveau der GPE 410. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, sodass Ausführungsressourcen nach Bedarf aktiviert oder deaktiviert werden können.
Das Grafikkern-Array 414 ist mit der geteilten Funktionslogik 420 gekoppelt, die mehrere Ressourcen beinhaltet, die zwischen den Grafikkernen in dem Grafikkern-Array geteilt werden. Die geteilten Funktionen innerhalb der geteilten Funktionslogik 420 sind Hardware-Logikeinheiten, die dem Grafikkern-Array 414 spezialisierte Zusatzfunktionalität bereitstellen. In verschiedenen Ausführungsformen beinhaltet die geteilte Funktionslogik 420 Sampler-Logik 421, Mathematiklogik 422 und Inter-Thread-Communikation (ITC) -Logik 423, ist jedoch nicht darauf beschränkt. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Caches 425 innerhalb der geteilten Funktionslogik 420.
Eine geteilte Funktion wird implementiert, wenn die Anforderung für eine gegebene spezialisierte Funktion nicht ausreicht, um in das Grafikkern-Array 414 aufgenommen zu werden. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eine eigenständige Entität in der geteilten Funktionslogik 420 implementiert und zwischen den Ausführungsressourcen innerhalb des Grafikkern-Arrays 414 geteilt. Der genaue Satz von Funktionen, die zwischen dem Grafikkern-Array 414 geteilt werden und innerhalb des Grafikkern-Arrays 414 enthalten sind, variiert über Ausführungsformen hinweg. In einigen Ausführungsformen können spezifische geteilte Funktionen in der geteilten Funktionslogik 420, die ausgiebig durch das Grafikkern-Array 414 verwendet werden, in geteilter Funktionslogik 416 innerhalb des Grafikkern-Array 414 enthalten sein. In verschiedenen Ausführungsformen kann die geteilte Funktionslogik 416 in dem Grafikkern-Array 414 einige oder alle Logik innerhalb der geteilten Funktionslogik 420 beinhalten. In einer Ausführungsform können alle Logikelemente innerhalb der geteilten Funktionslogik 420 innerhalb der geteilten Funktionslogik 416 des Grafikkern-Arrays 414 dupliziert werden. In einer Ausführungsform ist die geteilte Funktionslogik 420 zugunsten der geteilten Funktionslogik 416 innerhalb des Grafikkern-Arrays 414 ausgeschlossen.
5 ist ein Blockdiagramm einer Hardwarelogik von Grafikprozessorkern 500 gemäß einigen hierin beschriebenen Ausführungsformen. Elemente von 5 mit den gleichen Bezugszeichen (oder Namen) wie die Elemente jeglicher anderen Figur hierin können auf jegliche ähnliche Weise wie die anderswo hierin beschriebenen arbeiten oder funktionieren, sind jedoch nicht auf solche beschränkt. Der veranschaulichte Grafikprozessorkern 500 ist in einigen Ausführungsformen innerhalb des Grafikkern-Arrays 414 von 4 enthalten. Der Grafikprozessorkern 500, manchmal als ein Kern-Slice bezeichnet, kann ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 500 ist beispielhaft für ein Grafikkern-Slice, und ein Grafikprozessor wie hierin beschrieben kann mehrere Grafikkern-Slices basierend auf Leistungszielen und Leistungshüllkurven beinhalten. Jeder Grafikprozessorkern 500 kann Festfunktionsblock 530 beinhalten, der mit mehreren Subkernen 501A-501F, auch als Sub-Slices bezeichnet, die modulare Blöcke von Mehrzweck- und Festfunktionslogik beinhalten, gekoppelt ist.
In einigen Ausführungsformen beinhaltet der Festfunktionsblock 530 Geometrie-/Festfunktions-Pipeline 536, die durch alle Subkerne in dem Grafikprozessorkern 500 geteilt werden kann, zum Beispiel in Implementierungen von Grafikprozessoren mit niedrigerer Leistung und/oder niedrigerer Energie. In verschiedenen Ausführungsformen umfasst die Geometrie-/Festfunktions-Pipeline 536 eine 3D-Festfunktions-Pipeline (zum Beispiel 3D-Pipeline 312 wie in 3 und 4), eine Video-Front-End-Einheit, einen Thread-Spawner und Thread-Dispatcher und einen Unified-Return-Buffer-Manager, der Unified-Return-Buffer, wie zum Beispiel den Unified-Return-Buffer 418 von 4, verwaltet.
In einer Ausführungsform beinhaltet der Festfunktionsblock 530 auch Grafik-SoC-Schnittstelle 537, Grafik-Mikrocontroller 538 und Medien-Pipeline 539. Die Grafik-SoC-Schnittstelle 537 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 500 und anderen Prozessorkernen innerhalb einer integrierten System-on-a-Chip-Schaltung bereit. Der Grafik-Mikrocontroller 538 ist ein programmierbarer Sub-Prozessor, der zum Verwalten verschiedener Funktionen des Grafikprozessorkerns 500 einschließlich Thread-Versand, Zeitplanung und Vorabnahme konfigurierbar ist. Die Medien-Pipeline 539 (zum Beispiel die Medien-Pipeline 316 von 3 und 4) beinhaltet Logik, um das Decodieren, Codieren, Vorverarbeiten und/oder Nachverarbeiten von Multimediadaten, einschließlich Bild- und Videodaten, zu erleichtern. Die Medien-Pipeline 539 implementiert Medienoperationen über Anforderungen zum Berechnen oder Abtasten von Logik in den Sub-Kernen 501-501F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537, dass der Grafikprozessorkern 500 mit Mehrzweck-Anwendungsprozessorkernen (zum Beispiel CPU) und/oder anderen Komponenten innerhalb eines SoC, einschließlich Speicherhierarchieelementen, wie zum Beispiel einem geteilten Last-Level-Cache-Speicher, dem System-RAM und/oder eingebettetem On-Chip- oder On-Package-DRAM, kommuniziert. Die SoC-Schnittstelle 537 kann auch Kommunikation mit Festfunktionsgeräten innerhalb des SoC, wie zum Beispiel Kamera-Imaging-Pipelines, ermöglichen, und ermöglicht die Verwendung und/oder Implementierung von globaler Speicher-Atomik, die zwischen dem Grafikprozessorkern 500 und den CPU innerhalb des SoC geteilt werden kann. Die SoC-Schnittstelle 537 kann auch Energieverwaltungssteuerungen für den Grafikprozessorkern 500 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 500 und anderen Taktdomänen innerhalb des SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 den Empfang von Befehlspuffern von einem Befehls-Streamer und einem globalen Thread-Dispatcher, die dazu ausgelegt sind, Befehle und Anweisungen an jeden von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors bereitzustellen. Die Befehle und Anweisungen können an die Medien-Pipeline 539 versendet werden, wenn Medienoperationen ausgeführt werden sollen, oder an eine Geometrie- und Festfunktions-Pipeline (zum Beispiel Geometrie- und Festfunktions-Pipeline 536, Geometrie- und Festfunktions-Pipeline 514), wenn Grafikverarbeitungsoperationen ausgeführt werden sollen.
Der Grafik-Mikrocontroller 538 kann dazu ausgelegt sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 500 auszuführen. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 eine Grafik- und/oder Rechen-Arbeitsaufwand-Planung auf den verschiedenen Grafik-Parallel-Engines in Ausführungseinheits (EU) -Arrays 502A-502F, 504A-504F innerhalb der Sub-Kerne 501A-501F ausführen. In diesem Planungsmodell kann Host-Software, die auf einem CPU-Kern eines SoC einschließlich des Grafikprozessorkerns 500 ausgeführt wird, Arbeitslasten einer von mehreren Grafikprozessor-Doorbells übermitteln, wodurch eine Planungsoperation auf der geeigneten Grafikmaschine aufgerufen wird. Planen von Vorgängen beinhaltet Bestimmen der als Nächstes auszuführenden Arbeitslast, Übermitteln einer Arbeitslast an einen Befehls-Streamer, Vorabnehmen vorhandener Arbeitslasten, die auf einer Maschine ausgeführt werden, Überwachen des Fortschritts einer Arbeitslast und Benachrichtigen von Host-Software, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 auch Niedrigleistungs- oder Leerlaufzustände für den Grafikprozessorkern 500 erleichtern, wodurch dem Grafikprozessorkern 500 die Möglichkeit bereitgestellt wird, Register innerhalb des Grafikprozessorkerns 500 über Niedrigleistungsstatusübergänge hinweg unabhängig von dem Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu sichern und wiederherzustellen.
Der Grafikprozessorkern 500 kann mehr oder weniger als die veranschaulichten Sub-Kerne 501A-501F, bis zu N modulare Sub-Kerne haben. Für jeden Satz von N Sub-Kernen kann der Grafikprozessorkern 500 auch geteilte Funktionslogik 510, geteilten und/oder Cache-Speicher 512, Geometrie-/Festfunktions-Pipeline 514 sowie zusätzliche Festfunktionslogik 516 zum Beschleunigen verschiedener Grafiken und Rechenverarbeitungsoperationen beinhalten. Die geteilte Funktionslogik 510 kann der geteilten Funktionslogik 420 von 4 zugeordnete Logikeinheiten (zum Beispiel Sampler-, Mathematik- und/oder Inter-Thread-Kommunikationslogik) beinhalten, die durch jede N Sub-Kerne innerhalb des Grafikprozessorkerns 500 geteilt werden können. Der geteilte und/oder Cache-Speicher 512 kann ein Last-Level-Cache für den Satz von N Sub-Kernen 501A-501F innerhalb des Grafikprozessorkerns 500 sein, und kann auch als geteilter Speicher dienen, auf den mehrere Sub-Kerne zugreifen können. Die Geometrie-/Festfunktions-Pipeline 514 kann anstelle der Geometrie-/Festfunktions-Pipeline 536 in dem Festfunktionsblock 530 enthalten sein und kann die gleichen oder ähnliche Logikeinheiten beinhalten.
In einer Ausführungsform beinhaltet der Grafikprozessorkern 500 eine zusätzliche Festfunktionslogik 516, die verschiedene Festfunktionsbeschleunigungslogik zur Verwendung durch den Grafikprozessorkern 500 beinhalten kann. In einer Ausführungsform beinhaltet die zusätzliche Festfunktionslogik 516 eine zusätzliche Geometrie-Pipeline zur Verwendung nur in Position-Only-Shading. Bei Position-Only-Shading existieren zwei Geometrie-Pipelines, die Vollgeometrie-Pipeline innerhalb der Geometrie-/Festfunktions-Pipeline 516, 536 und eine Cull-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Festfunktionslogik 516 enthalten sein kann. In einer Ausführungsform ist die Cull-Pipeline eine reduzierte Version der Vollgeometrie-Pipeline. Die vollständige Pipeline und die Cull-Pipeline können unterschiedliche Instanzen derselben Anwendung ausführen, wobei jede Instanz einen separaten Kontext hat. Durch Position-Only-Shading können lange Cull-Läufe verworfener Dreiecke ausgeblendet werden, sodass das Shading in einigen Fällen früher abgeschlossen werden kann. Zum Beispiel und in einer Ausführungsform kann die Cull-Pipeline-Logik innerhalb der zusätzlichen Festfunktionslogik 516 Positions-Shader parallel zu der Hauptanwendung ausführen, und erzeugt im Allgemeinen kritische Ergebnisse schneller als die vollständige Pipeline, da die Cull-Pipeline nur das Positionsattribut der Vertexe abruft und shadet, ohne eine Rasterung und ein Rendern der Pixel an den Frame-Puffern auszuführen. Die Cull-Pipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, unabhängig davon, ob diese Dreiecke gecullt werden. Die vollständige Pipeline (die in diesem Fall als eine Wiedergabe-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verwenden, um die gecullten Dreiecke zu überspringen und nur die sichtbaren Dreiecke zu shaden, die schließlich an die Rasterungsphase übergeben werden.
In einer Ausführungsform kann die zusätzliche Festfunktionslogik 516 auch Beschleunigungslogik für maschinelles Lernen, wie zum Beispiel Festfunktionsmatrix-Multiplikationslogik, beinhalten, für Implementierungen einschließlich Optimierungen für Training oder Inferenzierung von maschinellem Lernen.
Innerhalb jedes Grafik-Sub-Kerns 501A-501F ist ein Satz von Ausführungsressourcen enthalten, die verwendet werden können, um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen durch Grafik-Pipeline-, Medien-Pipeline- oder Shader-Programme auszuführen. Die Grafik-Sub-Kerne 501A-501F beinhalten mehrere EU-Arrays 502A-502F, 504A-504F, Thread-Dispatch- und Inter-Thread-Kommunikations- (TD/IC) - Logik 503A-503F, 3D (zum Beispiel Textur) -Sampler 505A-505F, Medien-Sampler 506A-506F, Shader-Prozessor 507A-507F und geteilten lokalen Speicher (Shared-Local-Memory - SLM) 508A-508F. Die EU-Arrays 502A-502F, 504A-504F beinhalten jeweils mehrere Ausführungseinheiten, die Mehrzweck-Grafikverarbeitungseinheiten sind, die Gleitkomma- und Ganzzahl-/Festkomma-Logikoperationen im Dienst einer Grafik-, Medien-oder Rechenoperation, einschließlich Grafik-, Medien- oder Berechnungs-Shader-Programmen, ausführen können. Die TD/IC-Logik 503A-503F führt lokale Thread-Dispatch- und Thread-Steueroperationen für die Ausführungseinheiten innerhalb eines Sub-Kerns aus und erleichtert Kommunikation zwischen auf den Ausführungseinheiten des Sub-Kerns ausgeführten Threads. Der 3D-Sampler 505A-505F kann Textur- oder andere sich auf 3D-Grafik beziehende Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten basierend auf einem konfigurierten Abtaststatus und dem einer gegebenen Textur zugeordneten Texturformat unterschiedlich lesen. Der Medien-Sampler 506A-506F kann ähnliche Leseoperationen basierend auf dem den Mediendaten zugeordneten Typ und Format ausführen. In einer Ausführungsform kann jeder Grafik-Sub-Kern 501A-501F alternativ einen vereinheitlichten 3D- und Medien-Sampler beinhalten. Threads, die auf den Ausführungseinheiten innerhalb jedes der Sub-Kerne 501A-501F ausgeführt werden, können den geteilten lokalen Speicher 508A-508F innerhalb jedes Sub-Kerns verwenden, um zu ermöglichen, dass Threads, die innerhalb einer Thread-Gruppe ausgeführt werden, durch Verwenden eines gemeinsamen Pools von On-Chip-Speicher ausgeführt werden.
Ausführungseinheiten
Die 6A-6B veranschaulichen Thread-Ausführungslogik 600, die ein Array von Verarbeitungselementen beinhaltet, die in einem Grafikprozessorkern gemäß hierin beschriebenen Ausführungsformen eingesetzt werden. Elemente der 6A-6B mit den gleichen Bezugszeichen (oder Namen) wie die Elemente jeglicher anderen Figur hierin können auf jegliche ähnliche Weise wie die anderswo hierin beschriebenen arbeiten oder funktionieren, sind jedoch nicht auf solche beschränkt. 6A beinhaltet eine Übersicht über die Thread-Ausführungslogik 600, die eine Variante der mit jedem Sub-Kern 501A-501F von 5 veranschaulichten Hardwarelogik beinhalten kann. 6B veranschaulicht beispielhafte interne Details einer Ausführungseinheit.
Wie in 6A veranschaulicht, beinhaltet in einigen Ausführungsformen die Thread-Ausführungslogik 600 Shader-Prozessor 602, Thread-Dispatcher 604, Anweisungs-Cache 606, ein skalierbares Ausführungseinheits-Array einschließlich mehrerer Ausführungseinheiten 608A-608N, Sampler 610, Daten-Cache 612 und Datenport 614. In einer Ausführungsform kann das skalierbare Ausführungseinheits-Array dynamisch skaliert werden, indem eine oder mehrere Ausführungseinheiten (zum Beispiel eine der Ausführungseinheiten 608A, 608B, 608C, 608D bis 608N-1 und 608N) basierend auf den Berechnungsanforderungen einer Arbeitslast aktiviert oder deaktiviert werden. In einer Ausführungsform sind die enthaltenen Komponenten über eine Verbindungsstruktur, die mit jeder der Komponenten verbunden ist, miteinander verbunden. In einigen Ausführungsformen beinhaltet die Thread-Ausführungslogik 600 eine oder mehrere Verbindungen zu Speicher, wie zum Beispiel zu Systemspeicher oder Cache-Speicher, über einen oder mehrere Anweisungs-Cache-Speicher 606, den Datenport 614, den Sampler 610 und die Ausführungseinheiten 608A-608N. In einigen Ausführungsformen ist jede Ausführungseinheit (zum Beispiel 608A) eine eigenständige programmierbare Mehrzweck-Berechnungseinheit, die mehrere gleichzeitige Hardware-Threads ausführen kann, während mehrere Datenelemente für jeden Thread parallel verarbeitet werden. In verschiedenen Ausführungsformen ist das Array der Ausführungseinheiten 608A-608N skalierbar, um eine beliebige Anzahl einzelner Ausführungseinheiten zu beinhalten.
In einigen Ausführungsformen werden die Ausführungseinheiten 608A-608N hauptsächlich zum Ausführen von Shader-Programmen verwendet. Ein Shader-Prozessor 602 kann die verschiedenen Shader-Programme verarbeiten und den Shader-Programmen zugeordnete Ausführungs-Threads über einen Thread-Dispatcher 604 versenden. In einer Ausführungsform beinhaltet der Thread-Dispatcher Logik zum Vermitteln von Thread-Initiierungsanforderungen von den Grafik- und Medien-Pipelines und zum Instanziieren der angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 608A-608N. Zum Beispiel kann eine Geometrie-Pipeline Vertex-, Tessellierungs- oder Geometrie-Shader zur Verarbeitung an die Thread-Ausführungslogik versenden. In einigen Ausführungsformen kann der Thread-Dispatcher 604 auch Laufzeit-Thread-Spawning-Anforderungen von den ausführenden Shader-Programmen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N einen Anweisungssatz, der native Unterstützung für viele Standard-3D-Grafik-Shader-Anweisungen beinhaltet, sodass Shader-Programme von Grafikbibliotheken (zum Beispiel Direct 3D und OpenGL) mit einer minimalen Umwandlung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (zum Beispiel Vertex-Programme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (zum Beispiel Pixel-Shader, Fragment-Shader) und Mehrzweckverarbeitung (zum Beispiel Berechnungs- und Media-Shader). Jede der Ausführungseinheiten 608A-608N ist in der Lage, eine Mehrbereichs-Single-Instruction-Multiple-Data (SIMD) -Ausführung auszuführen, und eine Multi-Thread-Operation ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit hat eine fest zugeordnete Registerdatei mit hoher Bandbreite und einen zugeordneten unabhängigen Thread-Status. Die Ausführung erfolgt mit mehreren Ausgaben pro Takt für Pipelines, die Gleitkommaoperationen mit ganzzahliger, einfacher und doppelter Genauigkeit, SIMD-Verzweigungseignung, logische Operationen, transzendentale Operationen und andere verschiedene Operationen ausführen können. Während auf Daten von Speicher oder einer der geteilten Funktionen gewartet wird, bewirkt die Abhängigkeitslogik innerhalb der Ausführungseinheiten 608A-608N, dass ein wartender Thread in den Ruhezustand versetzt wird, bis die angeforderten Daten zurückgegeben worden sind. Während der wartende Thread im Ruhezustand ist, können Hardware-Ressourcen für die Verarbeitung anderer Threads verwendet werden. Zum Beispiel kann während einer Verzögerung, die einer Vertex-Shader-Operation zugeordnet ist, eine Ausführungseinheit Operationen für einen Pixel-Shader, Fragment-Shader oder einen anderen Typ von Shader-Programm, einschließlich eines unterschiedlichen Vertex-Shaders, ausführen.
Jede Ausführungseinheit in den Ausführungseinheiten 608A-608N arbeitet auf Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ oder Anzahl der Kanäle für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für den Zugriff auf Datenelemente, Maskierung und Flusssteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann unabhängig von der Anzahl der physikalischen Arithmetic-Logic-Units (ALU) oder Floating-Point-Units (FPU) für einen bestimmten Grafikprozessor sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N Ganzzahl- und Gleitkomma-Datentypen.
Der Anweisungssatz der Ausführungseinheit beinhaltet SIMD-Anweisungen. Die verschiedenen Datenelemente können als gepackter Datentyp in einem Register gespeichert werden, und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Wenn zum Beispiel auf einem 256 Bit breiten Vektor gearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert, und die Ausführungseinheit arbeitet auf dem Vektor als vier separate 64-Bit-gepackte Datenelemente (Datenelemente mit Quad-Word (QW) -Größe), acht separate 32-Bit-gepackte Datenelemente (Datenelemente mit Double Word (DW) -Größe), sechzehn separate 16-Bit-gepackte Datenelemente (Datenelemente mit Word (W) -Größe) oder zweiunddreißig separate 8-Bit-gepackte Datenelemente (Datenelemente mit Byte (B) -Größe). Es sind jedoch unterschiedliche Vektorbreiten und Registergrößen möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten zu zusammengeschlossener Ausführungseinheit 609A-609N mit zusammengeschlossener Thread-Steuerlogik (607A-607N), die den zusammengeschlossenen EU gemeinsam ist, kombiniert werden. Mehrere EU können zu einer EU-Gruppe zusammengeschlossen werden. Jede EU in der zusammengeschlossenen EU-Gruppe kann dazu ausgelegt sein, einen separaten SIMD-Hardware-Thread auszuführen. Die Anzahl von EU in einer zusammengeschlossenen EU-Gruppe kann gemäß Ausführungsformen variieren. Zusätzlich können verschiedene SIMD-Breiten pro EU ausgeführt werden, einschließlich, aber nicht beschränkt auf SIMD8, SIMD16 und SIMD32. Jede zusammengeschlossene Grafikausführungseinheit 609A-609N beinhaltet mindestens zwei Ausführungseinheiten. Zum Beispiel beinhaltet die zusammengeschlossene Ausführungseinheit 609A eine erste EU 608A, eine zweite EU 608B und eine Thread-Steuerlogik 607A, die der ersten EU 608A und der zweiten EU 608B gemeinsam ist. Die Thread-Steuerlogik 607A steuert Threads, die auf der zusammengeschlossenen Ausführungseinheit 609A ausgeführt werden, sodass jede EU innerhalb der zusammengeschlossenen Ausführungseinheit 609A-609N durch Verwenden eines gemeinsamen Anweisungszeigerregisters ausgeführt werden kann.
Ein oder mehrere interne Anweisungs-Caches (zum Beispiel 606) sind in der Thread-Ausführungslogik 600 enthalten, um Thread-Anweisungen für die Ausführungseinheiten zwischenzuspeichern. In einigen Ausführungsformen sind ein oder mehrere Daten-Caches (zum Beispiel 612) enthalten, um Thread-Daten während Thread-Ausführung zwischenzuspeichern. In einigen Ausführungsformen ist ein Sampler 610 enthalten, um Texturabtastung für 3D-Operationen und Medienabtastung für Medienoperationen bereitzustellen. In einigen Ausführungsformen beinhaltet der Sampler 610 spezialisierte Textur- oder Medienabtastfunktionalität, um Textur- oder Mediendaten während des Abtastprozesses zu verarbeiten, bevor die abgetasteten Daten einer Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und Medien-Pipelines Thread-Initiierungsanforderungen an die Thread-Ausführungslogik 600 über die Thread-Spawning- und Dispatch-Logik. Sobald eine Gruppe von geometrischen Objekten verarbeitet und in Pixeldaten gerastert wurde, wird die Pixelprozessorlogik (zum Beispiel Pixel-Shader-Logik, Fragment-Shader-Logik, usw.) innerhalb des Shader-Prozessors 602 aufgerufen, um die Ausgabeinformationen weiter zu berechnen und das Schreiben der Ergebnisse an Ausgabeoberflächen (zum Beispiel Farbpuffer, Tiefenpuffer, Schablonenpuffer, usw.) zu veranlassen. In einigen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertex-Attribute, die über das gerasterte Objekt hinweg interpoliert werden sollen. In einigen Ausführungsformen führt die Pixelprozessorlogik innerhalb des Shader-Prozessors 602 dann ein von der Anwendungsprogrammierungsschnittstelle (Application-Programming-Interface - API) geliefertes Pixel- oder Fragment-Shader-Programm aus. Um das Shader-Programm auszuführen, versendet der Shader-Prozessor 602 Threads über den Thread-Dispatcher 604 an eine Ausführungseinheit (zum Beispiel 608A). In einigen Ausführungsformen verwendet der Shader-Prozessor 602 eine Texturabtastlogik in dem Sampler 610, um auf Texturdaten in Texturabbildungen, die in Speicher gespeichert sind, zuzugreifen. Arithmetische Operationen an den Texturdaten und den eingegebenen Geometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel von weiterer Verarbeitung.
In einigen Ausführungsformen stellt der Datenport 614 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 600 bereit, um verarbeitete Daten zur weiteren Verarbeitung in einer GrafikprozessorAusgabe-Pipeline an den Speicher auszugeben. In einigen Ausführungsformen umfasst der Datenport 614 einen oder mehrere Cache-Speicher (zum Beispiel Daten-Cache 612) oder ist mit diesen gekoppelt, um Daten für Speicherzugriff über den Datenport zwischenzuspeichern.
Wie in 6B veranschaulicht, kann eine Grafikausführungseinheit 608 Anweisungsabrufeinheit 637, allgemeines Registerdatei (General-Register-File - GRF) -Array 624, Architekturregister (Architectural-Register-File - ARF) -Array 626, Thread-Arbiter 622, Sendeeinheit 630, Verzweigungseinheit 632, Satz von SIMD-Floating-Point-Units (FPU) 634 und in einer Ausführungsform Satz von fest zugeordneten Ganzzahl-SIMD-ALU 635 beinhalten. Die GRF 624 und die ARF 626 beinhalten den Satz von allgemeinen Registerdateien und Architekturregisterdateien, die jedem simultanen Hardware-Thread zugeordnet sind, der in der Grafikausführungseinheit 608 aktiv sein kann. In einer Ausführungsform wird der Architekturstatus pro Thread in der ARF 626 aufrechterhalten, während Daten, die während der Thread-Ausführung verwendet werden, in der GRF 624 gespeichert werden. Der Ausführungsstatus jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in Thread-spezifischen Registern in der ARF 626 gehalten werden.
In einer Ausführungsform hat die Grafikausführungseinheit 608 eine Architektur, die eine Kombination aus Simultaneous-Multi-Threading (SMT) und feinkörnigem Interleaved-Multi-Threading (IMT) ist. Die Architektur hat eine modulare Konfiguration, die zur Entwurfszeit basierend auf einer Zielanzahl von gleichzeitigen Threads und Anzahl von Registern pro Ausführungseinheit fein abgestimmt werden kann, wobei die Ressourcen der Ausführungseinheit über die zum Ausführen mehrerer gleichzeitiger Threads verwendete Logik hinweg aufgeteilt sind.
In einer Ausführungsform kann die Grafikausführungseinheit 608 mehrere Anweisungen, die jeweils unterschiedliche Anweisungen sein können, mit ausgeben. Der Thread-Arbiter 622 des Grafikausführungseinheits-Threads 608 kann die Anweisungen zur Ausführung an eine der Sendeeinheiten 630, die Verzweigungseinheit 6342 oder die SIMD-FPU 634 versenden. Jeder Ausführungs-Thread kann auf 128 Mehrzweckregister innerhalb der GRF 624 zugreifen, wobei jedes Register 32 Bytes speichern kann, auf die als SIMD-8-Element-Vektor von 32-Bit-Datenelementen zugegriffen werden kann. In einer Ausführungsform hat jeder Ausführungseinheits-Thread Zugriff auf 4 kByte innerhalb der GRF 624, obwohl Ausführungsformen nicht darauf beschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt werden können. In einer Ausführungsform können bis zu sieben Threads gleichzeitig ausgeführt werden, obwohl die Anzahl von Threads pro Ausführungseinheit gemäß Ausführungsformen auch variieren kann. In einer Ausführungsform, in der sieben Threads auf 4 kByte zugreifen können, kann die GRF 624 insgesamt 28 kByte speichern. Flexible Adressierungsmodi können ermöglichen, dass Register zusammen adressiert werden, um effektiv breitere Register aufzubauen oder gestufte rechteckige Blockdatenstrukturen darzustellen.
In einer Ausführungsform werden Speicheroperationen, Abtastoperationen und andere Systemkommunikationen mit längerer Latenz über „Send“-Anweisungen, die durch die Nachrichtenübergabe-Sendeeinheit 630 ausgeführt werden, versendet. In einer Ausführungsform werden Verzweigungsanweisungen an eine fest zugeordnete Verzweigungseinheit 632 versendet, um die SIMD-Divergenz und eventuelle Konvergenz zu erleichtern.
In einer Ausführungsform beinhaltet die Grafikausführungseinheit 608 eine oder mehrere SIMD-Floating-Point-Units (FPU) 634, um Gleitkomma-Operationen auszuführen. In einer Ausführungsform unterstützen die FPU 634 auch Ganzzahlberechnung. In einer Ausführungsform können die FPU 634 SIMD bis zur Anzahl M von 32-Bit-Gleitkomma (oder Ganzzahl) -Operationen ausführen, oder SIMD führen bis zu 2M 16-Bit-Ganzzahl oder 16-Bit-Gleitkomma-Operationen aus. In einer Ausführungsform stellt mindestens eine der FPU erweiterte mathematische Funktionen bereit, um transzendentale mathematische Funktionen mit hohem Durchsatz und 64-Bit-Gleitkomma mit doppelter Genauigkeit zu unterstützen. In einigen Ausführungsformen ist auch ein Satz von 8-Bit-Ganzzahl-SIMD-ALU 635 vorhanden, und kann speziell optimiert werden, um Operationen auszuführen, die Berechnungen zum maschinellen Lernen zugeordnet sind.
In einer Ausführungsform können Arrays von mehreren Instanzen der Grafikausführungseinheit 608 in einer Grafik-Sub-Kerngruppierung (zum Beispiel einem Sub-Slice) instanziiert werden. Für Skalierbarkeit können Produktarchitekten die genaue Anzahl von Ausführungseinheiten pro Sub-Kerngruppierung auswählen. In einer Ausführungsform kann die Ausführungseinheit 608 Anweisungen über mehrere Ausführungskanäle hinweg ausführen. In einer weiteren Ausführungsform wird jeder auf der Grafikausführungseinheit 608 ausgeführte Thread auf einem unterschiedlichen Kanal ausgeführt.
7 ist ein Blockdiagramm, das Grafikprozessor-Anweisungsformate 700 gemäß einiger Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die Kästchen mit durchgezogenen Linien veranschaulichen die Komponenten, die im Allgemeinen in einer Ausführungseinheitsanweisung enthalten sind, während die gestrichelten Linien Komponenten beinhalten, die optional sind oder nur in einem Untersatz der Anweisungen enthalten sind. In einigen Ausführungsformen sind das beschriebene und veranschaulichte Anweisungsformat 700 Makroanweisungen, insofern, als sie Anweisungen sind, die an die Ausführungseinheit geliefert werden, im Gegensatz zu Mikrooperationen, die sich aus Anweisungsdecodierung ergeben, sobald die Anweisung verarbeitet ist.
In einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten nativ Anweisungen in einem 128-Bit-Anweisungsformat 710. Komprimiertes 64-Bit-Anweisungsformat 730 ist für einige Anweisungen verfügbar, basierend auf der ausgewählten Anweisung, den Anweisungsoptionen und der Anzahl von Operanden. Das native 128-Bit-Anweisungsformat 710 bietet Zugriff auf alle Anweisungsoptionen, während einige Optionen und Operationen in dem 64-Bit-Format 730 beschränkt sind. Die in dem 64-Bit-Format 730 verfügbaren nativen Anweisungen variieren je nach Ausführungsform. In einigen Ausführungsformen wird die Anweisung teilweise durch Verwenden eines Satzes von Indexwerten in Indexfeld 713 komprimiert. Die Hardware der Ausführungseinheit referenziert einen Satz von Komprimierungstabellen basierend auf den Indexwerten und verwendet die Komprimierungstabellenausgaben, um eine native Anweisung in dem 128-Bit-Anweisungsformat 710 zu rekonstruieren.
Für jedes Format definiert Anweisungs-Opcode 712 die Operation, die die Ausführungseinheit ausführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden hinweg aus. Zum Beispiel führt die Ausführungseinheit in Reaktion auf eine Additionsanweisung eine gleichzeitige Additionsoperation über jeden ein Texturelement oder ein Bildelement darstellenden Farbkanal hinweg aus. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden hinweg aus. In einigen Ausführungsformen ermöglicht Anweisungssteuerfeld 714 die Steuerung bestimmter Ausführungsoptionen, wie zum Beispiel Kanalauswahl (zum Beispiel Prädikation) und Datenkanalreihenfolge (zum Beispiel Swizzle). Für Anweisungen in dem 128-Bit-Anweisungsformat 710 begrenzt Ausführungsgrößefeld 716 die Anzahl der Datenkanäle, die parallel ausgeführt werden. In einigen Ausführungsformen ist das Ausführungsgrößefeld 716 nicht zur Verwendung in dem 64-Bit-Kompaktanweisungsformat 730 verfügbar.
Einige Ausführungseinheitsanweisungen haben bis zu drei Operanden, einschließlich zwei Quelloperanden, src0 720, src1 722 und Ziel 718. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Anweisungen mit zwei Zielen, wobei eines der Ziele impliziert ist. Datenmanipulationsaweisungen können einen dritten Quelloperanden (zum Beispiel SRC2 724) haben, wobei der Anweisungs-Opcode 712 die Anzahl der Quelloperanden bestimmt. Der letzte Quelloperand einer Anweisung kann ein unmittelbarer (zum Beispiel hart-codierter) Wert sein, der mit der Anweisung übergeben wird.
In einigen Ausführungsformen beinhaltet das 128-Bit-Anweisungsformat 710 Zugriffs-/Adressmodusfeld 726, das zum Beispiel spezifiziert, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn der direkte Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
In einigen Ausführungsformen beinhaltet das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung spezifiziert. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Einige Ausführungsformen unterstützen Zugriffsmodi, einschließlich eines 16-Byte-ausgerichteten Zugriffsmodus und eines 1-Byte-ausgerichteten Zugriffsmodus, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Wenn sie sich zum Beispiel in einem ersten Modus befindet, kann die Anweisung Byteausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und wenn sie sich in einem zweiten Modus befindet, kann die Anweisung 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressmodusabschnitt des Zugriffs-/Adressmodusfelds 726, ob die Anweisung direkte oder indirekte Adressierung verwenden soll. Wenn direkter Registeradressierungsmodus verwendet wird, stellen die Bits in der Anweisung direkt die Registeradresse eines oder mehrerer Operanden bereit. Wenn indirekter Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem Adressdirektfeld in der Anweisung berechnet werden.
In einigen Ausführungsformen werden Anweisungen basierend auf Opcode-712-Bitfeldern gruppiert, um Opcode-Decodierung 740 zu vereinfachen. Bei einem 8-Bit-Opcode ermöglichen es die Bits 4, 5 und 6 der Ausführungseinheit, den Typ des Opcodes zu bestimmen. Die gezeigte genaue Opcode-Gruppierung ist nur ein Beispiel. In einigen Ausführungsformen beinhaltet Bewegungs- und Logik-Opcode-Gruppe 742 Datenbewegungs- und Logikanweisungen (zum Beispiel Bewegen (mov), Vergleichen (cmp)). In einigen Ausführungsformen teilt sich die Bewegungs- und Logikgruppe 742 die fünf höchstwertigen Bits (Most-Significant-Bits - MSB), wobei die Bewegungs (mov) -Anweisungen die Form von 0000xxxxb haben, und die Logikanweisungen die Form von 0001xxxxb haben. Flusssteuerungsanweisungsgruppe 744 (zum Beispiel Aufruf (call), Sprung (jmp)) beinhaltet Anweisungen in der Form von 0010xxxxb (zum Beispiel 0x20). Sonstige Anweisungsgruppe 746 beinhaltet eine Mischung von Anweisungen, einschließlich Synchronisationsanweisungen (zum Beispiel Warten (wait), Senden (send)) in der Form von 0011xxxxb (zum Beispiel 0x30). Parallele mathematische Anweisungsgruppe 748 beinhaltet komponentenweise arithmetische Anweisungen (zum Beispiel Addieren (add), Multiplizieren (mul)) in der Form von 0100xxxxb (zum Beispiel 0x40). Die parallele mathematische Gruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle hinweg aus. Vektormathematische Gruppe 750 beinhaltet arithmetische Anweisungen (zum Beispiel dp4) in der Form von 0101xxxxb (zum Beispiel 0x50). Die Vektormathematische Gruppe führt Arithmetik, wie zum Beispiel Skalarproduktberechnungen auf Vektoroperanden, aus.
Grafik-Pipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform von Grafikprozessor 800. Elemente von 8 mit den gleichen Bezugszeichen (oder Namen) wie die Elemente jeglicher anderen Figur hierin können auf jegliche ähnliche Weise wie die anderswo hierin beschriebenen arbeiten oder funktionieren, sind jedoch nicht auf solche beschränkt.
In einigen Ausführungsformen beinhaltet der Grafikprozessor 800 Geometrie-Pipeline 820, Medien-Pipeline 830, Anzeige-Engine 840, Thread-Ausführungslogik 850 und Render-Ausgabe-Pipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Multikernverarbeitungssystems, das einen oder mehrere Mehrzweckverarbeitungskerne beinhaltet. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle gesteuert, die über Ringverbindung 802 an den Grafikprozessor 800 ausgegeben werden. In einigen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 mit anderen Verarbeitungskomponenten, wie zum Beispiel anderen Grafikprozessoren oder Mehrzweckprozessoren. Befehle von der Ringverbindung 802 werden durch Befehls-Streamer 803, der Anweisungen an einzelne Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 liefert, umgewandelt.
In einigen Ausführungsformen lenkt der Befehls-Streamer 803 die Operation von Vertex-Abrufer 805, der Vertex-Daten von dem Speicher liest und durch den Befehls-Streamer 803 bereitgestellte Vertex-Verarbeitungsbefehle ausführt. In einigen Ausführungsformen stellt der Vertex-Abrufer 805 Vertex-Daten an Vertex-Shader 807 bereit, der für jeden Vertex Koordinatenraumtransformations- und Beleuchtungsoperationen ausführt. In einigen Ausführungsformen führen der Vertex-Abrufer 805 und der Vertex-Shader 807 Vertex-Verarbeitungsanweisungen aus, indem sie Ausführungs-Threads an Ausführungseinheiten 852A-852B über Thread-Dispatcher 831 versenden.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B ein Array von Vektorprozessoren mit einem Anweisungssatz zum Ausführen von Grafik- und Medienoperationen. In einigen Ausführungsformen haben die Ausführungseinheiten 852A-852B angehängten L1-Cache 851, der für jedes Array spezifisch ist oder zwischen den Arrays geteilt wird. Der Cache kann als ein Daten-Cache, ein Anweisungs-Cache oder als ein einzelner Cache konfiguriert werden, der partitioniert ist, um Daten und Anweisungen in unterschiedlichen Partitionen zu enthalten.
In einigen Ausführungsformen umfasst die Geometrie-Pipeline 820 Tessellierungskomponenten, um eine Hardware-beschleunigte Tessellierung von 3D-Objekten auszuführen. In einigen Ausführungsformen konfiguriert programmierbarer Hüll-Shader 811 die Tessellierungsoperationen. Programmierbarer Domain-Shader 817 stellt eine Back-End-Bewertung der Tessellierungsausgabe bereit. Tessellierer 813 arbeitet in der Richtung des Hüll-Shaders 811 und enthält eine Speziallogik zum Erzeugen eines Satzes von detaillierten geometrischen Objekten basierend auf einem groben geometrischen Modell, das als Eingabe für die Geometrie-Pipeline 820 bereitgestellt wird. In einigen Ausführungsformen können, wenn keine Tessellierung verwendet wird, Tessellierungskomponenten (zum Beispiel Hull-Shader 811, Tessellierer 813 und Domain-Shader 817) umgangen werden.
In einigen Ausführungsformen können vollständige geometrische Objekte durch Geometrie-Shader 819 über einen oder mehrere an die Ausführungseinheiten 852A-852B gesendete Threads verarbeitet werden, oder können direkt zu Clipper 829 weitergehen. In einigen Ausführungsformen bearbeitet der Geometrie-Shader ganze geometrische Objekte anstelle von Vertexen oder Patches von Vertexen wie in vorherigen Stufen der Grafik-Pipeline. Wenn die Tessellierung deaktiviert ist, empfängt der Geometrie-Shader 819 eine Eingabe von dem Vertex-Shader 807. In einigen Ausführungsformen ist der Geometrie-Shader 819 durch ein Geometrie-Shader-Programm programmierbar, um eine Geometrie-Tessellierung auszuführen, wenn die Tessellierungseinheiten deaktiviert sind.
Vor der Rasterung verarbeitet ein Clipper 829 Vertex-Daten. Der Clipper 829 kann ein Festfunktions-Clipper oder ein programmierbarer Clipper mit Clipping- und Geometrie-Shader-Funktionen sein. In einigen Ausführungsformen versendet Raster- und Tiefentestkomponente 873 in der Render-Ausgabe-Pipeline 870 Pixel-Shader, um die geometrischen Objekte in Darstellungen pro Pixel umzuwandeln. In einigen Ausführungsformen ist die Pixel-Shader-Logik in der Thread-Ausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung die Raster- und Tiefentestkomponente 873 umgehen und über Stream-Out-Einheit 823 auf nicht gerasterte Vertex-Daten zugreifen.
Der Grafikprozessor 800 hat einen Verbindungsbus, eine Verbindungsstruktur oder einen anderen Verbindungsmechanismus, der das Weiterleiten von Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors ermöglicht. In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B und die zugeordneten Logikeinheiten (zum Beispiel der L1-Cache 851, Sampler 854, Textur-Cache 858, usw.) über Datenport 856 miteinander verbunden, um Speicherzugriff auszuführen und mit den Render-Ausgabe-Pipeline-Komponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen haben der Sampler 854, die Caches 851, 858 und die Ausführungseinheiten 852A-852B jeweils separate Speicherzugriffspfade. In einer Ausführungsform kann der Textur-Cache 858 auch als ein Sampler-Cache konfiguriert sein.
In einigen Ausführungsformen enthält die Render-Ausgabe-Pipeline 870 eine Raster- und Tiefentestkomponente 873, die Vertexbasierte Objekte in eine zugeordnete Pixel-basierte Darstellung umwandelt. In einigen Ausführungsformen beinhaltet die Rasterlogik eine Windower/Masker-Einheit, um Festfunktions-Dreiecks- und Linienrasterung auszuführen. In einigen Ausführungsformen sind auch zugeordneter Render-Cache 878 und Tiefen-Cache 879 verfügbar. Pixeloperationskomponente 877 führt Pixel-basierte Operationen an den Daten aus, obwohl in einigen Fällen Pixeloperationen, die 2D-Operationen zugeordnet sind (zum Beispiel Bitblock-Bildübertragungen mit Durchmischung), durch 2D-Maschine 841 ausgeführt werden, oder zur Anzeigezeit durch die Anzeigesteuerung 843 durch Verwenden von Überlagerungsanzeigeebenen ersetzt werden. In einigen Ausführungsformen ist für alle Grafikkomponenten ein geteilter L3-Cache 875 verfügbar, der das Teilen von Daten ohne die Verwendung von Hauptsystemspeicher ermöglicht.
In einigen Ausführungsformen beinhaltet die Grafikprozessor-Medien-Pipeline 830 Medien-Engine 837 und Video-Front-End 834. In einigen Ausführungsformen empfängt das Video-Front-End 834 Pipeline-Befehle von dem Befehls-Streamer 803. In einigen Ausführungsformen beinhaltet die Medien-Pipeline 830 einen separaten Befehls-Streamer. In einigen Ausführungsformen verarbeitet das Video-Front-End 834 Medienbefehle, bevor der Befehl an die Medien-Engine 837 gesendet wird. In einigen Ausführungsformen beinhaltet die Medien-Engine 837 eine Thread-Spawning-Funktionalität zum Hervorbringen von Threads zum Versenden an die Thread-Ausführungslogik 850 über den Thread-Dispatcher 831.
In einigen Ausführungsformen beinhaltet der Grafikprozessor 800 eine Anzeige-Engine 840. In einigen Ausführungsformen befindet sich die Anzeige-Engine 840 außerhalb des Prozessors 800 und ist über die Ringverbindung 802 oder einen anderen Verbindungsbus oder eine Verbindungsstruktur mit dem Grafikprozessor gekoppelt. In einigen Ausführungsformen beinhaltet die Anzeige-Engine 840 eine 2D-Engine 841 und eine Anzeigesteuerung 843. In einigen Ausführungsformen enthält die Anzeige-Engine 840 eine Speziallogik, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen ist die Anzeigesteuerung 843 mit einem Anzeigegerät (nicht gezeigt) gekoppelt, das ein systemintegriertes Anzeigegerät, wie in einem Laptop-Computer, oder ein über einen Anzeigegeräteverbinder angeschlossenes externes Anzeigegerät sein kann.
In einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 konfigurierbar, um Operationen basierend auf mehreren Grafik- und Medienprogrammierungsschnittstellen auszuführen, und sind nicht spezifisch für irgendeine Anwendungsprogrammierungsschnittstelle (Application-Programming-Interface - API). In einigen Ausführungsformen wandelt Treibersoftware für den Grafikprozessor API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle um, die durch den Grafikprozessor verarbeitet werden können. In einigen Ausführungsformen wird Unterstützung für die Open-Graphics-Library (OpenGL), Open-Computing-Language (OpenCL) und/oder Vulkan-Grafik- und Berechnungs-API, alle von der Khronos Group, bereitgestellt. In einigen Ausführungsformen kann Unterstützung auch für die Direct3D-Bibliothek von der Microsoft Corporation bereitgestellt werden. In einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Unterstützung kann auch für die Open-Source-Computer-Vision-Library (OpenCV) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde auch unterstützt, wenn eine Abbildung von der Pipeline der zukünftigen API zu der Pipeline des Grafikprozessors gemacht werden kann.
Grafik-Pipeline-Programmierung
9A ist ein Blockdiagramm, das Grafikprozessor-Befehlsformat 900 gemäß einiger Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das Grafikprozessor-Befehlssequenz 910 gemäß einer Ausführungsform veranschaulicht. Die Kästchen mit durchgezogenen Linien in 9A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten beinhalten, die optional sind, oder die nur in einem Untersatz der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 von 9A beinhaltet Datenfelder zum Identifizieren von Client 902, Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl. Sub-Opcode 905 und Befehlsgröße 908 sind ebenfalls in einigen Befehlen enthalten.
In einigen Ausführungsformen spezifiziert der Client 902 die Client-Einheit des Grafikgeräts, das die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessor-Befehlsanalysierer das Client-Feld jedes Befehls, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten an die geeignete Client-Einheit zu leiten. In einigen Ausführungsformen beinhalten die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Client-Einheit hat eine entsprechende Verarbeitungs-Pipeline, die die Befehle verarbeitet. Sobald der Befehl durch die Client-Einheit empfangen wurde, liest die Client-Einheit den Opcode 904 und, falls vorhanden, den Sub-Opcode 905, um die auszuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl durch Verwenden von Informationen in dem Datenfeld 906 aus. Für einige Befehle wird eine explizite Befehlsgröße 908 erwartet, um die Größe des Befehls zu spezifizieren. In einigen Ausführungsformen bestimmt der Befehlsanalysierer automatisch die Größe von mindestens einigen der Befehle basierend auf dem Befehls-Opcode. In einigen Ausführungsformen werden Befehle über Vielfache eines Double-Word ausgerichtet.
Das Flussdiagramm in 9B veranschaulicht eine beispielhafte Grafikprozessor-Befehlssequenz 910. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors darstellt, eine Version der gezeigten Befehlssequenz, um einen Satz von Grafikoperationen einzurichten, auszuführen und zu beenden. Eine Abtastbefehlssequenz wird nur zu Beispielzwecken gezeigt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlssequenz beschränkt sind. Darüber hinaus können die Befehle als Batch von Befehlen in einer Befehlssequenz ausgegeben werden, sodass der Grafikprozessor die Befehlssequenz zumindest teilweise gleichzeitig verarbeitet.
In einigen Ausführungsformen kann die Grafikprozessor-Befehlssequenz 910 mit Pipeline-Flush-Befehl 912 beginnen, um jegliche aktive Grafik-Pipeline dazu zu veranlassen, die aktuell anstehenden Befehle für die Pipeline zu vervollständigen. In einigen Ausführungsformen arbeiten 3D-Pipeline 922 und Medien-Pipeline 924 nicht gleichzeitig. Der Pipeline-Flush wird ausgeführt, um die aktive Grafik-Pipeline dazu zu veranlassen, jegliche anstehenden Befehle zu vervollständigen. In Reaktion auf einen Pipeline-Flush pausiert der Befehlsanalysierer für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichnungs-Engines anstehende Operationen abschließen und die relevanten Lese-Caches für ungültig erklärt werden. Optional können jegliche Daten in dem Render-Cache, die als „dirty“ gekennzeichnet sind, in den Speicher geleert werden. In einigen Ausführungsformen kann der Pipeline-Flush-Befehl 912 zur Pipeline-Synchronisation oder vor dem Versetzen des Grafikprozessors in einen Niedrigleistungsstatus verwendet werden.
In einigen Ausführungsformen wird Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschalten soll. In einigen Ausführungsformen ist ein Pipeline-Auswahlbefehl 913 in einem Ausführungskontext nur einmal erforderlich, bevor Pipeline-Befehle ausgegeben werden, außer, der Kontext ist, Befehle für beide Pipelines auszugeben. In einigen Ausführungsformen ist ein Pipeline-Flush-Befehl 912 unmittelbar vor einem Pipeline-Wechsel über den Pipeline-Auswahlbefehl 913 erforderlich.
In einigen Ausführungsformen konfiguriert Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für den Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medien-Pipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Pipeline-Steuerbefehl 914 den Pipeline-Status für die aktive Pipeline. In einer Ausführungsform wird der Pipeline-Steuerbefehl 914 zur Pipeline-Synchronisation und zum Löschen von Daten von einem oder mehreren Cache-Speichern innerhalb der aktiven Pipeline vor der Verarbeitung eines Befehlsbatches verwendet.
In einigen Ausführungsformen werden Rückgabepuffer-Statusbefehle 916 verwendet, um einen Satz von Rückgabepuffern für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen während der Verarbeitung Zwischendaten schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und eine Kreuz-Thread-Kommunikation auszuführen. In einigen Ausführungsformen beinhaltet der Rückgabepufferstatus 916 das Auswählen der Größe und Anzahl von Rückgabepuffern, die für einen Satz von Pipeline-Operationen verwendet werden.
Die verbleibenden Befehle in der Befehlssequenz unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf Pipeline-Bestimmung 920 wird die Befehlssequenz auf die 3D-Pipeline 922, beginnend bei 3D-Pipeline-Status 930, oder auf die Medien-Pipeline 924, beginnend bei Medien-Pipeline-Status 940, zugeschnitten.
Die Befehle zum Konfigurieren des 3D-Pipeline-Status 930 beinhalten 3D-Statuseinstellbefehle für den Vertex-Pufferstatus, Vertex-Elementstatus, konstanten Farbstatus, Tiefenpufferstatus und andere Statusvariablen, die konfiguriert werden sollen, bevor 3D-Grundelementbefehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise basierend auf der bestimmten verwendeten 3D-API bestimmt. In einigen Ausführungsformen können 3D-Pipeline-Status-930-Befehle auch bestimmte Pipeline-Elemente gezielt deaktivieren oder umgehen, wenn diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird 3D-Grundelement 932 - Befehl verwendet, um 3D-Grundelemente zu übertragen, die durch die 3D-Pipeline verarbeitet werden sollen. Befehle und zugeordnete Parameter, die über den 3D-Grundelement 932 -Befehl an den Grafikprozessor übergeben werden, werden an die Vertex-Abruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die 3D-Grundelement 932 -Befehlsdaten, um Vertex-Datenstrukturen zu erzeugen. Die Vertex-Datenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der 3D-Grundelement 932 - Befehl verwendet, um Vertex-Operationen an 3D-Grundelementen über Vertex-Shader auszuführen. Um Vertex-Shader zu verarbeiten, sendet die 3D-Pipeline 922 Shader-Ausführungs-Threads an Grafikprozessor-Ausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über Ausführungs 934 -Befehl oder -Ereignis ausgelöst. In einigen Ausführungsformen löst ein Registerschreiben eine Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über einen Befehl „go“ oder „kick“ in der Befehlssequenz ausgelöst. In einer Ausführungsform wird die Befehlsausführung durch Verwenden eines Pipeline-Synchronisationsbefehls ausgelöst, um die Befehlssequenz durch die Grafikpipeline zu leeren. Die 3D-Pipeline führt die Geometrieverarbeitung für die 3D-Grundelemente aus. Sobald die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixel-Engine färbt die resultierenden Pixel. Für diese Operationen können auch zusätzliche Befehle zum Steuern von Pixel-Shading und Pixel-Back-End-Operationen enthalten sein.
In einigen Ausführungsformen folgt die Grafikprozessor-Befehlssequenz 910 dem Pfad der Medien-Pipeline 924, wenn Medienoperationen ausgeführt werden. Im Allgemeinen hängt die spezifische Verwendung und Art der Programmierung für die Medien-Pipeline 924 von den auszuführenden Medien- oder Rechenoperationen ab. Spezifische Datenträgerdecodierungsoperationen können während Mediencodierung in die Medien-Pipeline ausgelagert werden. In einigen Ausführungsformen kann die Medien-Pipeline auch umgangen werden, und die Mediendecodierung kann ganz oder teilweise durch Verwenden von Ressourcen, die durch einen oder mehrere Mehrzweckverarbeitungskerne bereitgestellt werden, ausgeführt werden. In einer Ausführungsform beinhaltet die Medien-Pipeline auch Elemente für General-Purpose-Graphics-Processor-Unit (GPGPU) - Operationen, wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen durch Verwenden von Berechnungs-Shader-Programmen, die nicht explizit mit dem Rendern von Grafikgrundelementen zusammenhängen, auszuführen.
In einigen Ausführungsformen ist die Medienpipeline 924 auf eine ähnliche Weise wie die 3D-Pipeline 922 konfiguriert. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipeline-Status 940 wird vor Medienobjektbefehlen 942 versendet oder in einer Befehlswarteschlange angebracht. In einigen Ausführungsformen beinhalten Befehle für den Medien-Pipeline-Status 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medienobjekte verwendet werden. Dies beinhaltet Daten zum Konfigurieren der Videodecodierungs- und Videocodierungslogik innerhalb der Medien-Pipeline, wie zum Beispiel Codierungs- oder Decodierungsformat. In einigen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Status 940 auch die Verwendung eines oder mehrerer Zeiger auf „indirekte“ Statuselemente, die einen Batch von Statuseinstellungen enthalten.
In einigen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger an Medienobjekte zur Verarbeitung durch die Medien-Pipeline. Die Medienobjekte beinhalten Speicherpuffer, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medien-Pipeline-Stati gültig sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Sobald der Pipeline-Status konfiguriert ist und Medienobjektbefehle 942 in die Warteschlange gestellt sind, wird die Medien-Pipeline 924 über Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (zum Beispiel Registerschreiben) ausgelöst. Ausgabe von der Medien-Pipeline 924 kann dann durch Operationen, die durch die 3D-Pipeline 922 oder die Medien-Pipeline 924 bereitgestellt werden, nachverarbeitet werden. In einigen Ausführungsformen werden GPGPU-Operationen auf eine ähnliche Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafik-Software-Architektur
10 veranschaulicht eine beispielhafte Grafik-Software-Architektur für Datenverarbeitungssystem 1000 gemäß einigen Ausführungsformen. In einigen Ausführungsformen beinhaltet die Software-Architektur 3D-Grafikanwendung 1010, Betriebssystem 1020 und mindestens einen Prozessor 1030. In einigen Ausführungsformen beinhaltet der Prozessor 1030 Grafikprozessor 1032 und einen oder mehrere Mehrzweckprozessorkerne 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils in Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programme, die Shader-Anweisungen 1012 beinhalten. Die Shader-Sprachanweisungen für die Shader-Sprache können in einer höheren Shader-Sprache, wie zum Beispiel der High-Level-Shader-Language (HLSL) oder der OpenGL-Shader-Language (GLSL), sein. Die Anwendung beinhaltet auch ausführbare Anweisungen 1014 in einer Maschinensprache, die zur Ausführung durch den Mehrzweckprozessorkern 1034 geeignet ist. Die Anwendung beinhaltet auch durch Vertex-Daten definierte Grafikobjekte 1016.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows®-Betriebssystem von der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein Open-Source-UNIX-ähnliches Betriebssystem, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann Grafik-API 1022, wie zum Beispiel die Direct3D-API, die OpenGL-API oder die Vulkan-API, unterstützen. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 1020 Front-End-Shader-Compiler 1024, um jegliche Shader-Anweisungen 1012 in HLSL in eine Low-Level-Shader-Sprache zu kompilieren. Die Kompilierung kann eine Just-in-Time (JIT) -Kompilierung sein oder die Anwendung kann eine Shader-Vorkompilierung ausführen. In einigen Ausführungsformen werden High-Level-Shader während der Kompilierung der 3D-Grafikanwendung 1010 zu Low-Level-Shadern kompiliert. In einigen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform, wie zum Beispiel einer Version der durch die Vulkan-API verwendete Standard-Portable-Intermediate-Representation (SPIR), bereitgestellt.
In einigen Ausführungsformen enthält Benutzermodus-Grafiktreiber 1026 Back-End-Shader-Compiler 1027, um die Shader-Anweisungen 1012 in eine hardwarespezifische Darstellung umzuwandeln. Wenn die OpenGL-API verwendet wird, werden die Shader-Anweisungen 1012 in der GLSL-High-Level-Sprache an einen Benutzermodus-Grafiktreiber 1026 zur Kompilierung übergeben. In einigen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystem-Kernelmodus-Funktionen 1028, um mit Kernelmodus-Grafiktreiber 1029 zu kommunizieren. In einigen Ausführungsformen kommuniziert der Kernelmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen zu versenden.
IP-Kern-Implementierungen
Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik innerhalb einer integrierten Schaltung, wie zum Beispiel einem Prozessor, darstellt und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Anweisungen beinhalten, die verschiedene Logik innerhalb des Prozessors darstellen. Wenn sie durch eine Maschine gelesen werden, können die Anweisungen die Maschine dazu veranlassen, die Logik zum Ausführen der hierin beschriebenen Techniken herzustellen. Solche als „IP-Kerne“ bezeichneten Darstellungen sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem materiellen, maschinenlesbaren Medium als ein Hardware-Modell, das die Struktur der integrierten Schaltung beschreibt, gespeichert werden können. Das Hardware-Modell kann an verschiedene Kunden oder Fertigungsstätten geliefert werden, die das Hardware-Modell auf Herstellungsmaschinen, die die integrierte Schaltung herstellen, laden. Die integrierte Schaltung kann so hergestellt sein, dass die Schaltung Operationen ausführt, die in Verbindung mit jeglicher der hierin beschriebenen Ausführungsformen beschrieben wurden.
11A ist ein Blockdiagramm, das IP-Kern-Entwicklungssystem 1100 veranschaulicht, das zum Herstellen einer integrierten Schaltung zum Ausführen von Operationen gemäß einer Ausführungsform verwendet werden kann. Das IP-Kern-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs zu erzeugen, die in ein größeres Design integriert werden können oder zum Aufbau einer gesamten integrierten Schaltung (zum Beispiel einer integrierten SOC-Schaltung) verwendet werden. Eine Design-Einrichtung 1130 kann Software-Simulation 1110 eines IP-Kern-Designs in einer höheren Programmiersprache (zum Beispiel C/C ++) erzeugen. Die Software-Simulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns durch Verwenden von Simulationsmodell 1112 zu entwerfen, zu testen und zu verifizieren. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Zeitablaufsimulationen beinhalten. Register-Transfer-Level (RTL) -Design 1115 kann dann von dem Simulationsmodell 1112 erstellt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Signale zwischen Hardware-Registern modelliert, einschließlich der zugeordneten Logik, die durch Verwenden der modellierten digitalen Signale ausgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs niedrigerer Ebenen auf der Logikebene oder der Transistorebene erzeugt, entworfen oder synthetisiert werden. Somit können die bestimmten Details des anfänglichen Designs und der Simulation variieren.
Das RTL-Design 1115 oder ein Äquivalent kann von der Design-Einrichtung ferner zu Hardware-Modell 1120 synthetisiert werden, das in einer Hardware-Description-Language (HDL) oder einer anderen Darstellung physikalischer Design-Daten sein kann. Die HDL kann ferner simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann zur Lieferung an Herstellungseinrichtung 1165 eines Drittanbieters durch Verwenden von nichtflüchtigem Speicher 1140 (zum Beispiel Festplatte, Flash-Speicher oder jeglichem nichtflüchtigem Speicherungsmedium) gespeichert werden. Alternativ kann das IP-Kern-Design über drahtgebundene Verbindung 1150 oder drahtlose Verbindung 1160 übertragen werden (zum Beispiel über das Internet). Die Herstellungseinrichtung 1165 kann dann eine integrierte Schaltung herstellen, die zumindest teilweise auf dem IP-Kern-Design basiert. Die hergestellte integrierte Schaltung kann dazu ausgelegt sein, Operationen gemäß mindestens einer hierin beschriebenen Ausführungsform auszuführen.
11B veranschaulicht eine seitliche Querschnittansicht von integrierter Schaltungspaketanordnung 1170 gemäß einigen hierin beschriebenen Ausführungsformen. Die integrierte Schaltungspaketanordnung 1170 veranschaulicht eine Implementierung von einem oder mehreren Prozessor- oder Beschleunigergeräte wie hierin beschrieben. Die Paketanordnung 1170 beinhaltet mehrere Einheiten von Hardwarelogik 1172, 1174, die mit Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann zumindest teilweise in konfigurierbarer Logik oder Logikhardware mit fester Funktionalität implementiert sein, und kann einen oder mehrere Abschnitte eines oder mehrerer der hierin beschriebenen Prozessorkerne, Grafikprozessoren oder anderer Beschleunigergeräte beinhalten. Jede Logikeinheit 1172, 1174 kann in einem Halbleiterchip implementiert und über Verbindungsstruktur 1173 mit dem Substrat 1180 gekoppelt werden. Die Verbindungsstruktur 1173 kann dazu ausgelegt sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten, und kann Verbindungen, wie zum Beispiel, aber nicht beschränkt auf Höcker oder Säulen, beinhalten. In einigen Ausführungsformen kann die Verbindungsstruktur 1173 dazu ausgelegt sein, elektrische Signale, wie zum Beispiel Eingabe-/Ausgabe (I/O) -Signale und/oder Leistungs- oder Erdungssignale, die der Operation der Logik 1172, 1174 zugeordnet sind, zu leiten. In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidbasis. Das Paketsubstrat 1180 kann in anderen Ausführungsformen andere geeignete Typen von Substraten beinhalten. Die Paketanordnung 1170 kann über Paketverbindung 1183 mit anderen elektrischen Geräten verbunden werden. Die Paketverbindung 1183 kann mit einer Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale an andere elektrische Geräte, wie zum Beispiel eine Hauptplatine, einen anderen Chipsatz oder ein Multi-Chip-Modul, zu leiten.
In einigen Ausführungsformen sind die Logikeinheiten 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die dazu ausgelegt ist, elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Brücke 1182 kann eine dichte Verbindungsstruktur sein, die einen Leitweg für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat beinhalten, das aus Glas oder einem geeigneten Halbleitermaterial zusammengesetzt ist. Auf dem Brückensubstrat können elektrische Leitwegmerkmale ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Obwohl zwei Logikeinheiten 1172, 1174 und eine Brücke 1182 veranschaulicht sind, können die hierin beschriebenen Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Chips beinhalten. Der eine oder die mehreren Chips können durch null oder mehrere Brücken verbunden sein, da die Brücke 1182 ausgeschlossen sein kann, wenn die Logik auf einem einzelnen Chip enthalten ist. Alternativ können mehrere Chips oder Logikeinheiten durch eine oder mehrere Brücken verbunden werden. Zusätzlich können mehrere Logikeinheiten, Chips und Brücken in anderen möglichen Konfigurationen, einschließlich dreidimensionaler Konfigurationen, miteinander verbunden werden.
Beispielhafte integrierte System-on a-Chip-Schaltung
Die 12-14 veranschaulichten beispielhafte integrierte Schaltungen und zugeordnete Grafikprozessoren, die durch Verwenden eines oder mehrerer IP-Kerne hergestellt werden können, gemäß verschiedenen hierin beschriebenen Ausführungsformen. Zusätzlich zu dem Veranschaulichten können andere Logik und Schaltungen enthalten sein, einschließlich zusätzlicher Grafikprozessoren/-Kerne, peripherer Schnittstellensteuerungen oder Mehrzweckprozessorkernen.
12 ist ein Blockdiagramm, das beispielhafte integrierte System-on-a-Chip-Schaltung 1200 veranschaulicht, die durch Verwenden eines oder mehrerer IP-Kerne gemäß einer Ausführungsform hergestellt werden kann. Die beispielhafte integrierte Schaltung 1200 beinhaltet einen oder mehrere Anwendungsprozessoren 1205 (zum Beispiel CPU), mindestens einen Grafikprozessor 1210 und kann zusätzlich Bildprozessor 1215 und/oder Videoprozessor 1220 beinhalten, von denen jeder ein modularer IP-Kern von derselben oder mehreren unterschiedlichen Design-Einrichtungen sein kann. Die integrierte Schaltung 1200 beinhaltet Peripherie- oder Buslogik, die USB-Steuerung 1225, UART-Steuerung 1230, SPI/SDIO-Steuerung 1235 und I2S/I2C-Steuerung 1240 beinhaltet. Zusätzlich kann die integrierte Schaltung Anzeigegerät 1245 beinhalten, das mit einer oder mehreren von High-Definition-Multimedia-Interface (HDMI) - Steuerungen 1250 und Mobile-Industry-Processor-Interface (MIPI) - Anzeigeschnittstelle 1255 gekoppelt ist. Speicherung kann durch Flash-Speichersubsystem 1260, das einen Flash-Speicher und eine Flash-Speichersteuerung beinhaltet, bereitgestellt werden. Speicherschnittstelle kann über Speichersteuerung 1265 für Zugriff auf SDRAM- oder SRAM-Speichergeräte bereitgestellt werden. Einige integrierte Schaltungen beinhalten zusätzlich eine eingebettete Sicherheits-Engine 1270.
Die 13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung innerhalb eines SoC gemäß hierin beschriebenen Ausführungsformen veranschaulichen. 13A veranschaulicht beispielhaften Grafikprozessor 1310 einer integrierten System-on-a-Chip-Schaltung, der durch Verwenden eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. 13B veranschaulicht zusätzlichen beispielhaften Grafikprozessor 1340 einer integrierten System-on-a-Chip-Schaltung, der durch Verwenden eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. Der Grafikprozessor 1310 von 13A ist ein Beispiel eines Grafikprozessorkerns mit niedriger Leistung. Der Grafikprozessor 1340 von 13B ist ein Beispiel eines Grafikprozessorkerns mit höherer Leistung. Jeder der Grafikprozessoren 1310, 1340 kann Varianten des Grafikprozessors 1210 von 12 sein.
Wie in 13A gezeigt, beinhaltet der Grafikprozessor 1310 Vertex-Prozessor 1305 und einen oder mehrere Fragment-Prozessoren 1315A-1315N (zum Beispiel 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N). Der Grafikprozessor 1310 kann verschiedene Shader-Programme über separate Logik ausführen, sodass der Vertex-Prozessor 1305 für die Ausführung von Operationen für Vertex-Shader-Programme optimiert ist, während der eine oder die mehreren Fragment-Prozessoren 1315A-1315N Fragment (zum Beispiel Pixel) -Shading-Operationen für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertex-Prozessor 1305 führt die Vertex-Verarbeitungsstufe der 3D-Grafik-Pipeline aus und erzeugt Grundelemente und Vertex-Daten. Der/die Fragment-Prozessoren) 1315A-1315N verwenden die durch den Vertex-Prozessor 1305 erzeugten Grundelement- und Vertex-Daten, um einen Frame-Puffer zu erzeugen, der auf einem Anzeigegerät angezeigt wird. In einer Ausführungsform sind der/die Fragment-Prozessoren) 1315A-1315N optimiert, um Fragment-Shader-Programme auszuführen, wie sie in der OpenGL-API vorgesehen sind, die verwendet werden können, um ähnliche Operationen wie ein Pixel-Shader-Programm, wie für in der Direct 3D-API bereitgestellt, auszuführen.
Der Grafikprozessor 1310 beinhaltet zusätzlich eine oder mehrere Speicherverwaltungseinheiten (Memory-Management-Units - MMU) 1320A-1320B, Cache(s) 1325A-1325B und Schaltungsverbindung(en) 1330A-1330B. Die eine oder die mehreren MMU 1320A-1320B stellen eine Abbildung von virtueller zu physikalischer Adresse für den Grafikprozessor 1310 bereit, einschließlich für den Vertex-Prozessor 1305 und/oder Fragmentprozessor(en) 1315A-1315N, die auf in Speicher gespeicherten Vertex- oder Bild-/Texturdaten, zusätzlich zu in einem oder mehreren Cache(s) 1325A-1325B gespeicherten Vertex- oder Bild-/Texturdaten, verweisen können. In einer Ausführungsform können die eine oder die mehreren MMU 1320A-1320B mit anderen MMU innerhalb des Systems, einschließlich einer oder mehrerer MMU, die dem einen oder den mehreren Anwendungsprozessoren 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 von 12 zugeordnet sind, synchronisiert sein, sodass jeder Prozessor 1205-1220 an einem geteilten oder einheitlichen virtuellen Speichersystem teilnehmen kann. Die eine oder die mehreren Schaltungsverbindungen 1330A-1330B ermöglichen es dem Grafikprozessor 1310, mit anderen IP-Kernen innerhalb des SoC entweder über einen internen Bus des SoC oder über eine direkte Verbindung gemäß Ausführungsformen eine Schnittstelle zu bilden.
Wie in 13B gezeigt, beinhaltet der Grafikprozessor 1340 eine oder mehrere MMU 1320A-1320B, Caches 1325A-1325B und Schaltungsverbindungen 1330A-1330B des Grafikprozessors 1310 von 13A. Der Grafikprozessor 1340 beinhaltet einen oder mehrere Shader-Kerne 1355A-1355N (zum Beispiel 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), die eine einheitliche Shader-Kernarchitektur bereitstellen, in der ein einzelner Kern oder Typ von Kern alle Typen von programmierbarem Shader-Code, einschließlich Shader-Programmcode zum Implementieren von Vertex-Shadern, Fragment-Shadern und/oder Berechnungs-Shadern, ausführen kann. Die genaue Anzahl von vorhandenen Shader-Kernen kann zwischen Ausführungsformen und Implementierungen variieren. Zusätzlich beinhaltet der Grafikprozessor 1340 Inter-Core-Task-Manager 1345, der als ein Thread-Dispatcher fungiert, um Ausführungs-Threads an einen oder mehrere Shader-Kerne 1355A-1355N zu versenden, und Kacheleinheit 1358, um Kacheloperationen für kachelbasiertes Rendern zu beschleunigen, in denen Renderoperationen für eine Szene in Bildbereiche unterteilt werden, um zum Beispiel lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder die Verwendung interner Caches zu optimieren.
Die 14A-14B veranschaulichen zusätzliche beispielhafte Grafikprozessorlogik gemäß hierin beschriebenen Ausführungsformen. 14A veranschaulicht Grafikkern 1400, der in dem Grafikprozessor 1210 von 12 enthalten sein kann, und ein vereinheitlichter Shader-Kern 1355A-1355N wie in 13B sein kann. 14B zeigt zusätzliche hochparallele Mehrzweck-Grafikverarbeitungseinheit 1430, die eine für den Einsatz in einem Multi-Chip-Modul geeignete hochparallele Mehrzweck-Grafikverarbeitungseinheit ist.
Wie in 14A gezeigt, beinhaltet der Grafikkern 1400 geteilten Anweisungs-Cache 1402, Textureinheit 1418 und Cache/geteilten Speicher 1420, die den Ausführungsressourcen innerhalb des Grafikkerns 1400 gemeinsam sind. Der Grafikkern 1400 kann mehrere Slices 1401A-1401N oder Partitionen für jeden Kern beinhalten, und ein Grafikprozessor kann mehrere Instanzen des Grafikkerns 1400 beinhalten. Die Slices 1401A-1401N können Unterstützungslogik einschließlich lokalem Anweisungs-Cache 1404A-1404N, Thread-Planer 1406A-1406N, Thread-Dispatcher 1408A-1408N und Registersatz 1410A-1440N beinhalten. Um Logikoperationen auszuführen, können die Slices 1401A-1401N einen Satz von Additional-Function-Units (AFU 1412A-1412N), Floating-Point-Units (FPU 1414A-1414N), ganzzahlige Arithmetic-Logic-Units (ALU 1416-1416N), Address-Computational-Units (ACU 1413A-1413N), Double-Precision-Floating-Point-Units (DPFPU 1415A-1415N) und Matrix-Processing-Units (MPU 1417A-1417N) beinhalten.
Einige der Berechnungseinheiten arbeiten mit einer spezifischen Genauigkeit. Zum Beispiel können die FPU 1414A-1414N Gleitkommaoperationen mit einfacher Genauigkeit (32 Bit) und halber Genauigkeit (16 Bit) ausführen, während die DPFPU 1415A-1415N Gleitkommaoperationen mit doppelter Genauigkeit (64 Bit) ausführen. Die ALU 1416A-1416N können Ganzzahloperationen mit variabler Genauigkeit mit 8-Bit-, 16-Bit- und 32-Bit-Genauigkeit ausführen, und können für Operationen mit gemischter Genauigkeit konfiguriert werden. Die MPU 1417A-1417N können auch für Matrixoperationen mit gemischter Genauigkeit, einschließlich Gleitkomma- und 8-Bit-Ganzzahloperationen mit halber Genauigkeit, konfiguriert werden. Die MPU 1417-1417N können eine Vielzahl von Matrixoperationen ausführen, um die Anwendungs-Frameworks für maschinelles Lernen zu beschleunigen, einschließlich der Unterstützung der beschleunigten allgemeinen Matrix-zu-Matrix-Multiplikation (General-Matrix-to-Matrix-Multiplication - GEMM). Die AFU 1412A-1412N können zusätzliche Logikoperationen ausführen, die von den Gleitkomma- oder Ganzzahl-Einheiten nicht unterstützt werden, einschließlich trigonometrischer Operationen (zum Beispiel Sinus, Cosinus, usw.).
Wie in 14B gezeigt, kann General-Purpose-Processing-Unit (GPGPU) 1430 dazu ausgelegt sein, dass hochparallele Rechenoperationen durch ein Array von Grafikverarbeitungseinheiten ausgeführt werden können. Zusätzlich kann die GPGPU 1430 direkt mit anderen Instanzen der GPGPU verbunden werden, um einen Multi-GPU-Cluster zu erzeugen, um die Trainingsgeschwindigkeit für besonders tiefe neuronale Netze zu verbessern. Die GPGPU 1430 beinhaltet Host-Schnittstelle 1432, um eine Verbindung mit einem Host-Prozessor zu ermöglichen. In einer Ausführungsform ist die Host-Schnittstelle 1432 eine PCI-Express-Schnittstelle. Die Host-Schnittstelle kann jedoch auch eine anbieterspezifische Kommunikationsschnittstelle oder Kommunikationsstruktur sein. Die GPGPU 1430 empfängt Befehle von dem Host-Prozessor und verwendet globalen Planer 1434, um diesen Befehlen zugeordnete Ausführungs-Threads an einen Satz von Rechen-Clustern 1436A-1436H zu verteilen. Die Rechen-Cluster 1436A-1436H teilen sich Cache-Speicher 1438. Der Cache-Speicher 1438 kann als ein Cache höherer Ebene für Cache-Speicher innerhalb der Rechen-Cluster 1436A-1436H dienen.
Die GPGPU 1430 beinhaltet Speicher 14434A-14434B, der über einen Satz von Speichersteuerungen 1442A-1442B mit den Rechen-Clustern 1436A-1436H gekoppelt ist. In verschiedenen Ausführungsformen kann der Speicher 1434A-1434B verschiedene Typen von Speichergeräten beinhalten, einschließlich Dynamic-Random-Access-Memory (DRAM) oder Grafik-Direktzugriffsspeicher, wie zum Beispiel Synchronous-Graphics-Random-Access-Memory (SGRAM), einschließlich Graphics-Double-Data-Rate (GDDR) -Speicher.
In einer Ausführungsform beinhalten die Rechen-Cluster 1436A-1436H jeweils einen Satz von Grafikkernen, wie zum Beispiel den Grafikkern 1400 von 14A, die mehrere Arten von Ganzzahl- und Gleitkomma-Logikeinheiten beinhalten können, die Berechnungsoperationen in einem Bereich von Genauigkeiten, einschließlich der für maschinelles Lernen geeigneten Berechnungen, ausführen können. Zum Beispiel und in einer Ausführungsform kann mindestens ein Untersatz der Floating-Point-Units in jedem der Rechen-Cluster 1436A-1436H dazu ausgelegt sein, 16-Bit- oder 32-Bit-Gleitkommaoperationen auszuführen, während ein unterschiedlicher Untersatz der Floating-Point-Units dazu ausgelegt sein kann, 64-Bit-Gleitkommaoperationen auszuführen.
Es können mehrere Instanzen der GPGPU 1430 dazu ausgelegt sein, als Rechen-Cluster zu arbeiten. Der Kommunikationsmechanismus, der durch das Rechen-Cluster für Synchronisation und Datenaustausch verwendet wird, variiert über Ausführungsformen hinweg. In einer Ausführungsform kommunizieren die mehreren Instanzen der GPGPU 1430 über die Host-Schnittstelle 1432. In einer Ausführungsform beinhaltet die GPGPU 1430 I/O-Hub 1439, der die GPGPU 1430 mit GPU-Verbindung 1440 koppelt, die eine direkte Verbindung zu anderen Instanzen der GPGPU ermöglicht. In einer Ausführungsform ist die GPU-Verbindung 1440 mit einer fest zugeordneten GPU-zu-GPU-Brücke gekoppelt, die die Kommunikation und Synchronisation zwischen mehreren Instanzen der GPGPU 1430 ermöglicht. In einer Ausführungsform ist die GPU-Verbindung 1440 mit einer Hochgeschwindigkeitsverbindung gekoppelt, um Daten an andere GPGPU oder parallele Prozessoren zu übertragen und zu empfangen. In einer Ausführungsform befinden sich die mehreren Instanzen der GPGPU 1430 in separaten Datenverarbeitungssystemen und kommunizieren über ein Netzwerkgerät, auf das über die Host-Schnittstelle 1432 zugegriffen werden kann. In einer Ausführungsform kann die GPU-Verbindung 1440 dazu ausgelegt sein, eine Verbindung zu einem Host-Prozessor zusätzlich zu oder als eine Alternative zu der Host-Schnittstelle 1432 zu ermöglichen.
Während die veranschaulichte Konfiguration der GPGPU 1430 dazu ausgelegt sein kann, neuronale Netzwerke zu trainieren, stellt eine Ausführungsform eine alternative Konfiguration der GPGPU 1430 bereit, die für den Einsatz innerhalb einer Hochleistungs- oder Niedrigleistungs-Inferenzplattform konfiguriert werden kann. In einer Inferenzkonfiguration beinhaltet die GPGPU 1430 relativ zu der Trainingskonfiguration weniger der Rechen-Cluster 1436A-1436H. Zusätzlich kann sich die dem Speicher 1434A-1434B zugeordnete Speichertechnologie zwischen Inferenz- und Trainingskonfigurationen unterscheiden, wobei Speichertechnologien mit höherer Bandbreite Trainingskonfigurationen gewidmet sind. In einer Ausführungsform kann die Inferenzkonfiguration der GPGPU 1430 die Inferenz spezifischer Anweisungen unterstützen. Zum Beispiel kann eine Inferenzkonfiguration Unterstützung für eine oder mehrere 8-Bit-Ganzzahl-Skalarprodukt-Anweisungen bereitstellen, die üblicherweise während Inferenzoperationen für eingesetzte neuronale Netzwerke verwendet werden.
RAYTRACING MIT MASCHINELLEM LERNEN
Wie oben erwähnt, ist Raytracing eine Grafikverarbeitungstechnik, bei der ein Lichttransport durch physikalischbasiertes Rendern simuliert wird. Eine der Schlüsseloperationen bei Raytracing ist die Verarbeitung einer Sichtbarkeitsabfrage, die das Durchqueren und Kreuzen von Knoten in einer Hüllvolumenhierarchie (Bounding-Volume-Hierarchie - BVH) erfordert.
Auf Ray- und Path-Tracing basierende Techniken berechnen Bilder, indem sie Rays und Pfade durch jedes Pixel verfolgen und durch Verwenden von Zufallsabtastungen fortgeschrittene Effekte, wie zum Beispiel Schatten, Glanz, indirekte Beleuchtung usw., berechnen. Die Verwendung von nur wenigen Abtastungen ist schnell, erzeugt jedoch verrauschte Bilder, während die Verwendung vieler Abtastungen Bilder von hoher Qualität erzeugt, jedoch kostenintensiv ist.
In den letzten Jahren wurde eine bahnbrechende Lösung für die Ray-/Path-Tracing-Funktion zur Echtzeit-Verwendung in der Form von „Rauschunterdrückung“ entwickelt - dem Prozess des Verwendens von Bildverarbeitungstechniken, um gefilterte/rauschunterdrückte Bilder von hoher Qualität aus verrauschten Eingaben mit niedriger Abtastzahl zu erzeugen. Die effektivsten Rauschunterdrückungstechniken verlassen sich auf Techniken zum maschinellen Lernen, wobei eine maschinell lernende Maschine lernt, wie ein verrauschtes Bild wahrscheinlich aussehen würde, wenn es mit mehr Abtastungen berechnet worden wäre. In einer bestimmten Implementierung wird das maschinelle Lernen durch ein neuronales Faltungsnetzwerk (Convolutional-Neural-Network - CNN) ausgeführt; die der Erfindung zugrunde liegenden Prinzipien sind jedoch nicht auf eine CNN-Implementierung beschränkt. Bei einer solchen Implementierung werden Trainingsdaten mit Eingaben mit niedriger Abtastzahl und Grundwahrheit hergestellt. Das CNN wird trainiert, um das konvergierte Pixel von einer Nachbarschaft von verrauschten Pixeleingaben um das fragliche Pixel herum vorherzusagen.
Obwohl nicht perfekt, hat sich diese AI-basierte Rauschunterdrückungstechnik als überraschend effektiv erwiesen. Der Vorbehalt ist jedoch, dass gute Trainingsdaten erforderlich sind, da das Netzwerk ansonsten die falschen Ergebnisse vorhersagen kann. Wenn ein Animationsfilmstudio zum Beispiel eine Rauschunterdrückungs-CNN für frühere Filme mit Szenen an Land trainieren würde und dann versuchen würde, die trainierte CNN zur Rauschunterdrückung von Bildern von einem neuen Filmset auf Wasser zu verwenden, wird die Rauschunterdrückungsoperation nicht optimal ausgeführt.
Um dieses Problem anzugehen, sammelt eine Ausführungsform der Erfindung Lerndaten dynamisch während des Renderns und trainiert kontinuierlich eine maschinell lernende Maschine, wie zum Beispiel eine CNN, basierend auf den Daten, auf denen sie aktuell ausgeführt wird, wodurch die maschinell lernende Maschine für die anstehende Aufgabe kontinuierlich verbessert wird. Diese Ausführungsform kann immer noch eine Trainingsphase vor der Laufzeit ausführen, setzt jedoch die Anpassung der maschinellen Lerngewichte nach Bedarf während der Laufzeit fort. Zusätzlich vermeidet diese Ausführungsform die hohen Kosten der Berechnung der Referenzdaten, die für das Training erforderlich sind, indem die Erzeugung von Lerndaten auf einen Unterbereich des Bildes für jeden Frame oder für alle N Frames beschränkt wird. Insbesondere werden die verrauschten Eingänge eines Frames erzeugt, um den gesamten Frame mit dem aktuellen Netzwerk zu entrauschen. Zusätzlich wird ein kleiner Bereich von Referenzpixeln erzeugt und für ein kontinuierliches Training verwendet, wie unten beschrieben.
Während eine CNN-Implementierung in Bezug auf bestimmte Ausführungsformen beschrieben wird, kann jegliche Form einer maschinell lernenden Maschine verwendet werden, einschließlich, aber nicht beschränkt auf Systeme, die beaufsichtigtes Lernen ausführen (zum Beispiel Erstellen eines mathematischen Modells eines Datensatzes, der sowohl die Eingaben als auch die gewünschten Ergebnisse enthält), unbeaufsichtigtes Lernen (zum Beispiel das Auswerten der Eingabedaten für bestimmte Strukturtypen) und/oder eine Kombination aus beaufsichtigtem und unbeaufsichtigtem Lernen.
Bestehende Rauschunterdrückungsimplementierungen arbeiten in einer Trainingsphase und einer Laufzeitphase. Während der Trainingsphase wird eine Netzwerktopologie definiert, die einen Bereich von NxN Pixeln mit verschiedenen Datenkanälen pro Pixel, wie zum Beispiel Pixelfarbe, Tiefe, Normal, Normalabweichung, Grundelement-ID und Albedo, empfängt und eine endgültige Pixelfarbe erzeugt. Ein Satz von „repräsentativen“ Trainingsdaten wird durch Verwenden von Eingaben mit niedriger Abtastzahl im Wert von einem Frame und unter Bezugnahme auf die „gewünschten“ Pixelfarben, die mit einer sehr hohen Abtastzahl berechnet wurden, erzeugt. Das Netzwerk wird auf diese Eingaben hin trainiert und erzeugt einen Satz von „idealen“ Gewichten für das Netzwerk. In diesen Implementierungen werden die Referenzdaten verwendet, um die Netzwerkgewichte so zu trainieren, dass sie der Netzwerkausgabe am besten entsprechen, um das gewünschte Ergebnis zu erreichen.
Zur Laufzeit werden die gegebenen, vorberechneten idealen Netzwerkgewichte geladen, und das Netzwerk wird initialisiert. Für jeden Frame wird ein Bild mit niedriger Abtastzahl von Rauschunterdrückungseingaben (das heißt dieselbe, wie für das Training verwendet) erzeugt. Für jedes Pixel wird die gegebene Nachbarschaft von Pixeleingaben durch das Netzwerk geleitet, um die „rauschunterdrückte“ Pixelfarbe vorherzusagen, wodurch ein rauschunterdrückter Frame erzeugt wird.
15 zeigt eine Ausführungsform einer anfänglichen Trainingsimplementierung. Maschinell lernende Maschine 1500 (zum Beispiel eine CNN) empfängt einen Bereich von NxN Pixeln als Bilddaten mit hoher Abtastzahl 1702 mit verschiedenen Datenkanälen pro Pixel, wie zum Beispiel Pixelfarbe, Tiefe, Normal, Normalabweichung, Grundelement-ID und Albedo, und erzeugt endgültige Pixelfarben. Repräsentative Trainingsdaten werden durch Verwenden von Eingaben mit niedriger Abtastzahl 1501 im Wert von einem Frame erzeugt. Das Netzwerk wird auf diese Eingaben hin trainiert, wobei ein Satz von „idealen“ Gewichten 1505 erzeugt wird, die die maschinell lernende Maschine 1500 anschließend verwendet, um Bilder mit niedriger Abtastzahl zur Laufzeit zu entrauschen.
Um die obigen Techniken zu verbessern, erweitert eine Ausführungsform der Erfindung die Rauschunterdrückungsphase, um für jeden Frame oder einen Untersatz von Frames (zum Beispiel für alle N Frames mit N = 2, 3, 4, 10, 25, usw.) neue Trainingsdaten zu erzeugen. Insbesondere, wie in 16 veranschaulicht, wählt diese Ausführungsform einen oder mehrere Bereiche in jedem Frame, die hier als „neue Referenzbereiche“ 1602 bezeichnet werden, die mit einer hohen Abtastzahl in separaten Puffer mit hoher Abtastzahl 1604 gerendert werden. Puffer mit niedriger Abtastzahl 1603 speichert Eingabe-Frame mit niedriger Abtastzahl 1601 (einschließlich Bereich niedriger Abtastung 1604, der dem neuen Referenzbereich 1602 entspricht).
In einer Ausführungsform wird der Ort des neuen Referenzbereichs 1602 zufällig ausgewählt. Alternativ kann der Ort des neuen Referenzbereichs 1602 für jeden neuen Frame auf eine vorab spezifizierte Weise eingestellt werden (zum Beispiel durch Verwenden einer vordefinierten Bewegung des Bereichs zwischen Frames, die auf einen spezifizierten Bereich in der Mitte des Frames begrenzt ist, usw.).
Unabhängig davon, wie der neue Referenzbereich ausgewählt wird, wird er durch die maschinell lernende Maschine 1600 verwendet, um zur Rauschunterdrückung verwendete trainierte Gewichte 1605 kontinuierlich zu verfeinern und zu aktualisieren. Insbesondere werden Referenzpixelfarben von jedem neuen Referenzbereich 1602 und verrauschte Referenzpixeleingaben von entsprechendem Bereich mit niedriger Abtastzahl 1607 gerendert. Zusätzliches Training wird dann an der maschinell lernenden Maschine 1600 durch Verwenden des Referenzbereichs mit hoher Abtastzahl 1602 und entsprechenden Bereichs mit niedriger Abtastzahl 1607 ausgeführt. Im Gegensatz zu dem anfänglichen Training wird dieses Training kontinuierlich während der Laufzeit für jeden neuen Referenzbereich 1602 ausgeführt - wodurch sichergestellt wird, dass die maschinell lernende Maschine 1600 präzise trainiert wird. Zum Beispiel können Datenkanäle pro Pixel (zum Beispiel Pixelfarbe, Tiefe, Normal, Normalabweichung, usw.) beurteilt werden, die die maschinell lernende Maschine 1600 verwendet, um Anpassungen an den trainierten Gewichten 1605 zu machen. Wie in dem Trainingsfall (15) wird die maschinell lernende Maschine 1600 auf einen Satz von Idealgewichten 1605 hin zum Entfernen von Rauschen von dem Eingabe-Frame mit niedriger Abtastzahl 1601 trainiert, um rauschunterdrückten Frame 1620 zu erzeugen. In dieser Ausführungsform werden die trainierten Gewichte 1605 jedoch basierend auf neuen Bildeigenschaften neuer Typen von Eingabe-Frames mit niedriger Abtastzahl 1601 kontinuierlich aktualisiert.
In einer Ausführungsform werden die durch die maschinell lernende Maschine 1600 ausgeführten Neutrainingsoperationen gleichzeitig in einem Hintergrundprozess auf der Grafikprozessoreinheit (GPU) oder dem Host-Prozessor ausgeführt. Die Render-Schleife, die als eine Treiberkomponente und/oder eine GPU-Hardwarekomponente implementiert sein kann, erzeugt kontinuierlich neue Trainingsdaten (zum Beispiel in der Form neuer Referenzbereiche 1602), die sie in eine Warteschlange stellt. Der auf der GPU oder dem Host-Prozessor ausgeführte Hintergrundtrainingsprozess liest kontinuierlich die neuen Trainingsdaten von dieser Warteschlange, trainiert die maschinell lernende Maschine 1600 neu und aktualisiert sie in geeigneten Intervallen mit neuen Gewichten 1605.
17 veranschaulicht ein Beispiel einer solchen Implementierung, bei der Hintergrundtrainingsprozess 1700 durch Host-CPU 1710 implementiert wird. Insbesondere verwendet in dieser Ausführungsform der Hintergrundtrainingsprozess 1700 den neuen Referenzbereich mit hoher Abtastzahl 1602 und den entsprechenden Bereich mit niedriger Abtastzahl 1604, um die trainierten Gewichte 1605 kontinuierlich zu aktualisieren, wodurch die maschinell lernende Maschine 1600 aktualisiert wird.
Wie in 18A veranschaulicht, erzeugen in einer Implementierung, wie zum Beispiel in einem Online-Spiel für mehrere Spieler, unterschiedliche Host-Maschinen 1820-1822 individuell Referenzbereiche, die ein Hintergrundtrainingsprozess 1700A-C an Server 1800 (wie zum Beispiel einen Spieleserver) überträgt. Der Server 1800 führt dann ein Training auf maschinell lernender Maschine 1810 durch Verwenden der neuen Referenzbereiche aus, die von jedem der Hosts 1821-1822 empfangen wurden, wobei Gewichte 1805 wie zuvor beschrieben aktualisiert werden. Er überträgt diese Gewichte 1805 an die Host-Maschinen 1820, die die Gewichte 1605A-C speichern, wodurch jede einzelne maschinell lernende Maschine (nicht gezeigt) aktualisiert wird. Da dem Server 1800 in einer kurzen Zeit eine große Anzahl von Referenzbereichen bereitgestellt werden kann, kann er die Gewichte für jegliche gegebene durch die Benutzer ausgeführte Anwendung (zum Beispiel ein Online-Spiel) effizient und präzise aktualisieren.
Wie in 18B veranschaulicht, können die unterschiedlichen Host-Maschinen neue trainierte Gewichte erzeugen (zum Beispiel basierend auf den Trainings-/Referenzbereichen 1602, wie zuvor beschrieben), und die neuen trainierten Gewichte mit einem Server 1800 (zum Beispiel einem Spieleserver) teilen, oder alternativ ein Peer-to-Peer-Freigabeprotokoll verwenden. Eine Verwaltungskomponente für maschinelles Lernen 1810 auf dem Server erzeugt einen Satz kombinierter Gewichte 1805 durch Verwenden der von jedem der Host-Maschinen empfangenen neuen Gewichte. Die kombinierten Gewichte 1805 können zum Beispiel ein von den neuen Gewichten wie hierin beschriebener erzeugter und kontinuierlich aktualisierter Durchschnitt sein. Einmal erzeugt, können Kopien der kombinierten Gewichte 1605A-C übertragen und auf jeder der Host-Maschinen 1820-1821 gespeichert werden, die dann die hierin beschriebenen kombinierten Gewichte verwenden können, um Rauschunterdrückungsoperationen auszuführen.
In einer Ausführungsform kann dieser Aktualisierungsmechanismus mit halbgeschlossener Schleife durch den Hardware-Hersteller verwendet werden. Zum Beispiel kann das Referenznetzwerk als Teil des durch den Hardware-Hersteller vertriebenen Treibers enthalten sein. Während der Treiber durch Verwenden der hierin beschriebenen Techniken neue Trainingsdaten erzeugt und diese kontinuierlich an den Hardware-Hersteller zurücksendet, verwendet der Hardware-Hersteller diese Informationen, um seine Implementierungen für maschinelles Lernen für die nächste Treiberaktualisierung weiter zu verbessern.
In einer Implementierung (zum Beispiel beim Batch-Rendern von Filmen in einer Renderfarm) überträgt der Renderer die neu erzeugten Trainingsbereiche an einen fest zugeordneten Server oder eine Datenbank (in der Renderfarm dieses Studios), die diese Daten von mehreren Renderknoten über einen Zeitraum hinweg sammelt. Ein separater Prozess auf einer separaten Maschine verbessert kontinuierlich das fest zugeordnete Rauschunterdrückungsnetzwerk des Studios, und neue Renderaufträge verwenden immer das aktuellste trainierte Netzwerk.
Ein Verfahren gemäß einer Ausführungsform der Erfindung wird in 19 veranschaulicht. Das Verfahren kann auf den hierin beschriebenen Architekturen implementiert werden, ist jedoch nicht auf irgendeine bestimmte System- oder Grafikverarbeitungsarchitektur beschränkt.
Bei 1901 werden als Teil der anfänglichen Trainingsphase Bilddaten mit niedriger Abtastzahl und Bilddaten mit hoher Abtastzahl für mehrere Bild-Frames erzeugt. Bei 1902 wird eine maschinell lernende Rauschunterdrückungsmaschine durch Verwenden der Bilddaten mit hoher/niedriger Abtastzahl trainiert. In einer Ausführungsform kann zum Beispiel ein Satz von Gewichten neuronaler Faltungsnetzwerke, die Pixelmerkmalen zugeordnet sind, gemäß dem Training aktualisiert werden. Es kann jedoch jegliche Architektur zum maschinellen Lernen verwendet werden.
Bei 1903 werden zur Laufzeit Bilder mit niedriger Abtastzahl zusammen mit mindestens einem Referenzbereich mit hoher Abtastzahl erzeugt. Bei 1904 wird der Referenzbereich mit hoher Abtastzahl durch die maschinell lernende Maschine und/oder eine separate Trainingslogik (zum Beispiel Hintergrundtrainingsmodul 1700) verwendet, um das Training der maschinell lernenden Maschine kontinuierlich zu verfeinern. Zum Beispiel wird in einer Ausführungsform der Referenzbereich mit hoher Abtastzahl in Kombination mit einem entsprechenden Abschnitt des Bildes mit niedriger Abtastzahl verwendet, um der maschinell lernenden Maschine bei 1904 weiterhin beizubringen, wie sie Rauschunterdrückung am effektivsten durchführt. In einer CNN-Implementierung kann dies beispielsweise das Aktualisieren der dem CNN zugeordneten Gewichte einbeziehen.
Es können mehrere Variationen der oben beschriebenen Ausführungsformen implementiert werden, wie zum Beispiel die Art und Weise, in der die Rückmeldungsschleife zu der maschinell lernenden Maschine konfiguriert ist, die Einheiten, die die Trainingsdaten erzeugen, die Art und Weise, in der die Trainingsdaten zu der Trainingsmaschine zurückgeführt werden, und wie das verbesserte Netzwerk für die Rendering-Engines bereitgestellt wird. Zusätzlich kann, während die oben beschriebenen Ausführungsformen kontinuierliches Training durch Verwenden eines einzelnen Referenzbereichs ausführen, jegliche Anzahl von Referenzbereichen verwendet werden. Darüber hinaus können, wie zuvor erwähnt, die Referenzbereiche von unterschiedlicher Größe sein, auf unterschiedlichen Anzahlen von Bild-Frames verwendet werden, und an unterschiedlichen Orten innerhalb der Bild-Frames durch Verwenden unterschiedlicher Techniken (zum Beispiel zufällig, gemäß einem vorgegebenen Muster, usw.) positioniert werden.
Während ein neuronales Faltungsnetzwerk (CNN) als ein Beispiel einer maschinell lernenden Maschine 1600 beschrieben ist, können die der Erfindung zugrunde liegenden Prinzipien durch Verwenden jeglicher Form einer maschinell lernenden Maschine implementiert werden, die dazu geeignet ist, ihre Ergebnisse durch Verwenden neuer Trainingsdaten kontinuierlich zu verfeinern. Beispielhaft und nicht beschränkend beinhalten andere Implementierungen von maschinellem Lernen die Group-Method-of-Data-Handling (GMDH), Long-Short-Term-Memory, Deep-Reservoir-Computing, Deep-Believe-Networks, Tensor-Deep-Stacking-Networks und Deep-Predictive-Coding-Networks, um ein paar zu nennen.
VORRICHTUNG UND VERFAHREN ZUR EFFIZIENTEN VERTEILTEN RAUSCHUNTERDRÜCKUNG
Wie oben beschrieben, ist Rauschunterdrückung zu einem kritischen Merkmal für Echtzeit-Raytracing mit gleichmäßigen, rauschfreien Bildern geworden. Rendern kann über ein verteiltes System auf mehreren Geräten hinweg ausgeführt werden, bisher arbeiten jedoch die existierenden Rauschunterdrückungs-Frameworks alle auf einer einzelnen Instanz auf einer einzelnen Maschine. Wenn Rendern über mehrere Geräte erfolgt, können nicht alle gerenderten Pixel für die Berechnung eines rauschunterdrückten Abschnitts des Bildes zugänglich sein.
Eine Ausführungsform der Erfindung beinhaltet einen Algorithmus zur verteilten Rauschunterdrückung, der sowohl mit künstlicher Intelligenz (Artificial-Intelligence - AI) als auch mit nicht auf AI basierenden Rauschunterdrückungstechniken arbeitet. Bereiche des Bildes sind entweder bereits von einer verteilten Renderoperation über Knoten hinweg verteilt, oder sie werden von einem einzelnen Frame-Puffer aufgeteilt und verteilt. Geisterbereiche benachbarter Bereiche, die zum Berechnen einer ausreichenden Rauschunterdrückung benötigt werden, werden bei Bedarf von benachbarten Knoten gesammelt, und die endgültigen resultierenden Kacheln werden zu einem endgültigen Bild zusammengesetzt.
VERTEILTE VERARBEITUNG
20 veranschaulicht eine Ausführungsform der Erfindung, bei der mehrere Knoten 2021-2023 ein Rendern ausführen. Während der Einfachheit halber nur drei Knoten dargestellt sind, sind die der Erfindung zugrunde liegenden Prinzipien nicht auf jegliche bestimmte Anzahl von Knoten beschränkt. Tatsächlich kann ein einzelner Knoten verwendet werden, um bestimmte Ausführungsformen der Erfindung zu implementieren.
Die Knoten 2021-2023 rendern jeweils einen Teil eines Bildes, was in diesem Beispiel zu Bereichen 2011-2013 führt. Während in 20 rechteckige Bereiche 2011-2013 dargestellt sind, können Bereiche jeglicher Form verwendet werden, und jegliches Gerät kann jegliche Anzahl von Bereichen verarbeiten. Die Bereiche, die durch einen Knoten benötigt werden, um eine ausreichend gleichmäßige Rauschunterdrückungsoperation auszuführen, werden als Geisterbereiche 2011-2013 bezeichnet. Mit anderen Worten, Geisterbereiche 2001-2003 repräsentieren die Gesamtheit der Daten, die erforderlich sind, um eine Rauschunterdrückung mit einem bestimmten Qualitätsniveau auszuführen. Durch Verringern des Qualitätsniveaus wird die Größe des Geisterbereichs verringert, und daher erhöhen die erforderliche Datenmenge und ein Erhöhen des Qualitätsniveaus den Geisterbereich und die entsprechenden erforderlichen Daten.
In einer Ausführungsform, wenn ein Knoten, wie zum Beispiel der Knoten 2021 eine lokale Kopie eines Abschnitts des Geisterbereichs 2001 hat, die erforderlich ist, um seinen Bereich 2011 mit einem spezifischen Qualitätsniveau zu entrauschen, ruft der Knoten die erforderlichen Daten von einem oder mehreren „angrenzenden“ Knoten, wie zum Beispiel dem Knoten 2022, der einen Abschnitt des Geisterbereichs 2001 wie dargestellt besitzt, ab. In ähnlicher Weise, wenn der Knoten 2022 eine lokale Kopie eines Abschnitts des Geisterbereichs 2002 hat, die erforderlich ist, um den Bereich 2012 auf dem spezifischen Qualitätsniveau zu entrauschen, ruft der Knoten 2022 die erforderlichen Geisterbereichsdaten 2032 von dem Knoten 2021 ab. Das Abrufen kann über einen Bus, eine Verbindung, eine Hochgeschwindigkeitsspeicherstruktur, ein Netzwerk (zum Beispiel Hochgeschwindigkeits-Ethernet) oder sogar eine On-Chip-Verbindung in einem Multicore-Chip ausgeführt werden, der in der Lage ist, Rendering-Arbeit zwischen mehreren Kernen zu verteilen (zum Beispiel verwendet zum Rendern großer Bilder mit entweder extremen Auflösungen oder zeitlichen Variationen). In einer Ausführungsform umfasst jeder Knoten 2021-2023 eine einzelne Ausführungseinheit oder einen spezifizierten Satz von Ausführungseinheiten innerhalb eines Grafikprozessors.
Die spezifische zu sendende Datenmenge ist abhängig von den verwendeten Rauschunterdrückungstechniken. Darüber hinaus können die Daten von dem Geisterbereich jegliche Daten beinhalten, die zur Verbesserung der Rauschunterdrückung für jeden jeweiligen Bereich benötigt werden. In einer Ausführungsform beinhalten die Geisterbereichsdaten zum Beispiel Bildfarben/Wellenlängen, Intensitäts-/Alphadaten und/oder Normale. Die der Erfindung zugrunde liegenden Prinzipien sind jedoch nicht auf jeglichen bestimmten Satz von Geisterbereichsdaten beschränkt.
ZUSÄTZLICHE DETAILS EINER AUSFÜHRUNGSFORM
Bei langsameren Netzwerken oder Verbindungen kann die Komprimierung dieser Daten durch Verwenden vorhandener verlustfreier oder verlustbehafteter Mehrzweckkomprimierung verwendet werden. Beispiele hierfür beinhalten, sind aber nicht beschränkt auf zlib, gzip und Lempel-Ziv-Markov-Chain-Algorithm (LZMA). Ferner kann inhaltsspezifische Komprimierung verwendet werden, indem angemerkt wird, dass das Delta in den Ray-Trefferinformationen zwischen Frames ziemlich spärlich sein kann, und nur die Abtastungen, die zu diesem Delta beitragen, gesendet werden müssen, wenn der Knoten bereits die gesammelten Deltas von vorherigen Frames hat. Diese können selektiv zu Knoten geschoben werden, die diese Abtastungen sammeln, i, oder Knoten i kann Abtastungen von anderen Knoten anfordern. In einer Ausführungsform wird die verlustfreie Komprimierung für bestimmte Typen von Daten und Programmcode verwendet, während verlustbehaftete Daten für andere Typen von Daten verwendet werden.
21 veranschaulicht zusätzliche Details der Wechselwirkungen zwischen den Knoten 2021-2022 gemäß einer Ausführungsform der Erfindung. Jeder Knoten 2021-2022 beinhaltet Raytracing-Rendering-Schaltung 2081-2082 zum Rendern der jeweiligen Bildbereiche 2011-2012 und der Geisterbereiche 2001-2002. Rauschunterdrücker 2100-2111 führen jeweils Rauschunterdrückungsoperationen in den Bereichen 2011-2012 aus, wobei jeder Knoten 2021-2022 für das Rendern und die Rauschunterdrückung verantwortlich ist. Die Rauschunterdrücker 2021-2022 können zum Beispiel eine Schaltung, Software oder jegliche Kombination davon umfassen, um rauschunterdrückte Bereiche 2121-2122 zu erzeugen. Wie erwähnt, können sich die Rauschunterdrücker 2021-2022 beim Erzeugen von rauschunterdrückten Bereichen auf Daten innerhalb eines Geisterbereichs stützen müssen, die einem anderen Knoten gehören (zum Beispiel kann der Rauschunterdrücker 2100 Daten von dem Geisterbereich 2002, der dem Knoten 2022 gehört, benötigen).
Somit erzeugen in einer Ausführungsform die Rauschunterdrücker 2100-2111 die rauschunterdrückten Bereiche 2121-2122 durch Verwenden von Daten aus den Bereichen 2011-2012 bzw. den Geisterbereichen 2001-2002, von denen mindestens ein Teil von einem anderen Knoten empfangen werden kann. Bereichsdatenmanager 2101-2102 verwalten die Datenübertragungen von den Geisterbereichen 2001-2002 wie hierin beschrieben. In einer Ausführungsform führen Komprimierungs-/Dekomprimierungs-Einheiten 2131-2132 Komprimierung bzw. Dekomprimierung der zwischen den Knoten 2021-2022 ausgetauschten Geisterbereichsdaten aus.
Zum Beispiel kann der Bereichsdatenmanager 2101 des Knotens 2021 auf Anforderung des Knotens 2022 Daten von dem Geisterbereich 2001 an den Komprimierer/Dekomprimierer 2131 senden, der die Daten komprimiert, um komprimierte Daten 2106 zu erzeugen, die er an den Knoten 2022 überträgt, wodurch die Bandbreite über die Verbindung, das Netzwerk, den Bus oder eine andere Datenkommunikationsverbindung verringert wird. Der Komprimierer/Dekomprimierer 2132 des Knotens 2022 dekomprimiert dann die komprimierten Daten 2106 und der Rauschunterdrücker 2111 verwendet die dekomprimierten Geisterdaten, um einen rauschunterdrückten Bereich 2012 mit höherer Qualität zu erzeugen, als dies nur mit Daten von dem Bereich 2012 möglich wäre. Der Bereichsdatenmanager 2102 kann die dekomprimierten Daten von dem Geisterbereich 2001 in einem Cache, Speicher, einer Registerdatei oder einer anderen Speicherung speichern, um sie für den Rauschunterdrücker 2111 verfügbar zu machen, wenn der rauschunterdrückte Bereich 2122 erzeugt wird. Ein ähnlicher Satz von Operationen kann ausgeführt werden, um die Daten von dem Geisterbereich 2002 an den Rauschunterdrücker 2100 auf dem Knoten 2021 bereitzustellen, der die Daten in Kombination mit Daten von dem Bereich 2011 verwendet, um einen rauschunterdrückten Bereich 2121 von höherer Qualität zu erzeugen.
DATEN GREIFEN ODER RENDERN
Wenn die Verbindung zwischen Geräten, wie zum Beispiel den Knoten 2021-2022 langsam ist (das heißt niedriger als eine Schwellenlatenz und/oder eine Schwellenbandbreite), kann es schneller sein, Geisterbereiche lokal zu rendern, als die Ergebnisse von anderen Geräten anzufordern. Dies kann zur Laufzeit bestimmt werden, indem die Netzwerktransaktionsgeschwindigkeit und die linear extrapolierten Render-Zeiten für die Größe des Geisterbereichs verfolgt werden. In solchen Fällen, in denen das Rendern des gesamten Geisterbereichs schneller ist, können mehrere Geräte schließlich dieselben Abschnitte des Bildes rendern. Die Auflösung des gerenderten Abschnitts der Geisterbereiche kann basierend auf der Varianz des Basisbereichs und dem bestimmten Unschärfegrad angepasst werden.
LASTVERTEILUNG
In einer Ausführungsform können statische und/oder dynamische Lastverteilungsschemas verwendet werden, um die Verarbeitungslast zwischen den verschiedenen Knoten 2021-2023 zu verteilen. Für dynamische Lastverteilung kann die durch den Rauschunterdrückungsfilter bestimmte Varianz sowohl mehr Zeit für die Rauschunterdrückung erfordern als auch die Menge der zum Rendern eines bestimmten Bereichs der Szene verwendeten Abtastungen steuern, wobei eine niedrige Varianz und unscharfe Bereiche des Bildes weniger Abtastungen erfordern. Die spezifischen Bereiche, die bestimmten Knoten zugeordnet sind, können dynamisch angepasst werden, basierend auf Daten von vorherigen Frames, oder dynamisch über Geräte hinweg kommuniziert werden, während diese rendern, sodass alle Geräte den gleichen Arbeitsaufwand haben.
22 veranschaulicht eine Ausführungsform, bei der auf jedem jeweiligen Knoten 2021-2022 laufender Überwacher 2201-2202 Leistungsmetrikdaten sammelt, einschließlich, aber nicht beschränkt auf die Zeit, die zum Übertragen von Daten über Netzwerkschnittstelle 2211-2212 benötigt wird, die Zeit, die für Rauschunterdrückung eines Bereichs benötigt wird (mit und ohne Geisterbereichsdaten) und die Zeit, die zum Rendern jedes Bereichs/Geisterbereichs benötigt wird. Die Überwacher 2201-2202 berichten diese Leistungsmetriken an Manager- oder Lastausgleichsknoten 2201 zurück, der die Daten analysiert, um die aktuelle Arbeitslast auf jedem Knoten 2021-2022 zu identifizieren und möglicherweise einen effizienteren Verarbeitungsmodus für verschiedene rauschunterdrückte Bereiche 2121-2122 bestimmt. Der Managerknoten 2201 verteilt dann neue Arbeitslasten für neue Bereiche an die Knoten 2021-2022 gemäß der erkannten Last. Zum Beispiel kann der Managerknoten 2201 mehr Arbeit an diejenigen Knoten übertragen, die nicht stark belastet sind, und/oder Arbeit von den Knoten, die überlastet sind, neu zuweisen. Zusätzlich kann der Lastausgleichsknoten 2201 einen Rekonfigurationsbefehl übertragen, um die spezifische Art und Weise anzupassen, in der das Rendern und/oder die Rauschunterdrückung durch jeden der Knoten ausgeführt wird (wovon einige Beispiele oben beschrieben sind).
BESTIMMUNG VON GEISTERBEREICHEN
In einer Ausführungsform werden die Größen und Formen der Geisterbereiche 2001-2002 basierend auf dem durch die Rauschunterdrücker 2100-2111 implementierten Rauschunterdrückungs-Algorithmus bestimmt. Ihre jeweiligen Größen können dann basierend auf der erkannten Varianz der rauschunterdrückten Abtastungen modifiziert werden. Der Lernalgorithmus, der für die AI-Rauschunterdrückung selbst verwendet wird, kann zum Bestimmen geeigneter Bereichsgrößen verwendet werden, oder in anderen Fällen, wie zum Beispiel einer bilateralen Unschärfe, bestimmt die vorgegebene Filterbreite die Größe der Geisterbereiche 2001-2002. In einer Implementierung, die einen Lernalgorithmus verwendet, kann die maschinell lernende Maschine auf dem Managerknoten 2201 ausgeführt werden und/oder Abschnitte des maschinellen Lernens können auf jedem der einzelnen Knoten 2021-2023 ausgeführt werden (siehe zum Beispiel 18A-B und zugehörigen Text oben).
ERFASSEN DES ENDGÜLTIGEN BILDS
In einer Ausführungsform wird das endgültige Bild erzeugt, indem die gerenderten und rauschunterdrückten Bereiche von jedem der Knoten 2021-2023 gesammelt werden, ohne dass die Geisterbereiche oder Normalen benötigt werden. In 22 werden zum Beispiel die rauschunterdrückten Bereiche 2121-2122 an Bereichsprozessor 2280 des Managerknotens 2201 übertragen, der die Bereiche kombiniert, um endgültiges rauschunterdrücktes Bild 2290 zu erzeugen, das dann auf Anzeige 2290 angezeigt wird. Der Bereichsprozessor 2280 kann die Bereiche durch Verwenden einer Vielzahl von 2D-Zusammensetzungstechniken kombinieren. Obwohl als separate Komponenten veranschaulicht, können der Bereichsprozessor 2280 und das rauschunterdrückte Bild 2290 integral zu der Anzeige 2290 sein. In dieser Ausführungsform können die verschiedenen Knoten 2021-2022 eine Direktsendetechnik verwenden, um die rauschunterdrückten Bereiche 2121-2122 zu übertragen, und möglicherweise verschiedene verlustbehaftete oder verlustfreie Komprimierungen der Bereichsdaten verwenden.
AI-Rauschunterdrückung ist immer noch eine kostspielige Operation, und wird beim Spielen in die Cloud verlagert. Als solches kann das Verteilen der Rauschunterdrückung über mehrere Knoten 2021-2022 hinweg erforderlich werden, um Echtzeit-Frame-Raten für traditionelles Spielen oder virtuelle Realität (VR), was höhere Frame-Raten erfordert, zu erreichen. Filmstudios rendern häufig auch in großen Renderfarmen, die zur schnelleren Rauschunterdrückung verwendet werden können.
Eine Ausführungsform eines Verfahrens zum Ausführen von verteiltem Rendern und Rauschunterdrückung ist in 23 veranschaulicht. Das Verfahren kann innerhalb des Kontext der oben beschriebenen Systemarchitekturen implementiert werden, ist jedoch nicht auf jegliche bestimmte Systemarchitektur beschränkt.
Bei 2301 wird Grafikarbeit an mehrere Knoten, die Raytracing-Operationen ausführen, versendet, um einen Bereich eines Bild-Frames zu rendern. In einer Ausführungsform kann jeder Knoten bereits Daten haben, die erforderlich sind, um die Operationen in Speicher auszuführen. Zum Beispiel können zwei oder mehr der Knoten einen gemeinsamen Speicher teilen, oder die lokalen Speicher der Knoten können bereits Daten von früheren Raytracing-Operationen gespeichert haben. Alternativ oder zusätzlich können bestimmte Daten zu jedem Knoten übertragen werden.
Bei 2302 wird der „Geisterbereich“ bestimmt, der für ein bestimmtes Rauschunterdrückungsniveau (das heißt bei einem akzeptablen Leistungsniveau) erforderlich ist. Der Geisterbereich umfasst jegliche Daten, die zur Ausführung des spezifizierten Rauschunterdrückungsniveaus erforderlich sind, einschließlich Daten, die einem oder mehreren anderen Knoten gehören.
Bei 2303 werden Daten, die sich auf die Geisterbereiche (oder Abschnitte davon) beziehen, zwischen Knoten ausgetauscht. Bei 2304 führt jeder Knoten eine Rauschunterdrückung in seinem jeweiligen Bereich aus (zum Beispiel durch Verwenden der ausgetauschten Daten), und bei 2305 werden die Ergebnisse kombiniert, um den endgültigen rauschunterdrückten Bild-Frame zu erzeugen.
In einer Ausführungsform versendet ein Managerknoten oder Primärknoten, wie zum Beispiel in 22 gezeigt, die Arbeit an die Knoten und kombiniert dann die durch die Knoten ausgeführte Arbeit, um den endgültigen Bild-Frame zu erzeugen. In einer anderen Ausführungsform wird eine Peer-basierte Architektur verwendet, bei der die Knoten Peers sind, die Daten austauschen, um den endgültigen Bild-Frame zu rendern und zu entra uschen.
Die hierin beschriebenen Knoten (zum Beispiel die Knoten 2021-2023) können Grafikverarbeitungs-Computersysteme sein, die über ein Hochgeschwindigkeitsnetzwerk miteinander verbunden sind. Alternativ können die Knoten einzelne Verarbeitungselemente sein, die mit einer Hochgeschwindigkeitsspeicherstruktur gekoppelt sind. In dieser Ausführungsform können sich alle Knoten einen gemeinsamen virtuellen Speicherplatz und/oder einen gemeinsamen physikalischen Speicher teilen. In einer anderen Ausführungsform können die Knoten eine Kombination von CPU und GPU sein. Zum Beispiel kann der oben beschriebene Managerknoten 2201 eine CPU und/oder auf der CPU ausgeführte Software sein, und die Knoten 2021-2022 können GPU und/oder auf den GPU ausgeführte Software sein. Es können verschiedene unterschiedliche Typen von Knoten verwendet werden, während die der Erfindung zugrunde liegenden Prinzipien immer noch erfüllt werden.
BEISPIELHAFTE IMPLEMENTIERUNGEN NEURONALER NETZWERKE
Es gibt viele Typen neuronaler Netzwerke; Ein einfacher Typ eines neuronalen Netzwerks ist ein Feedforward-Netzwerk. Ein Feedforward-Netzwerk kann als ein azyklischer Graph implementiert werden, in dem die Knoten in Schichten angeordnet sind. Typischerweise beinhaltet eine Feedforward-Netzwerktopologie eine Eingabe- und eine Ausgabeschicht, die durch mindestens eine verborgene Schicht getrennt sind. Die verborgene Schicht wandelt von der Eingabeschicht empfangene Eingaben in eine Darstellung um, die zum Erzeugen von Ausgaben in der Ausgabeschicht hilfreich ist. Die Netzwerkknoten sind vollständig über Kanten mit den Knoten in angrenzenden Schichten verbunden, es gibt jedoch keine Kanten zwischen Knoten innerhalb jeder Schicht. An den Knoten einer Eingabeschicht eines Feedforward-Netzwerks empfangene Daten werden über eine Aktivierungsfunktion, die die Stati der Knoten jeder aufeinanderfolgenden Schicht in dem Netzwerk basierend auf Koeffizienten („Gewichten“), die jeweils jeder der Kanten zugeordnet sind, die die Schichten verbinden, berechnet, an die Knoten der Ausgabeschicht verbreitet (das heißt „weitergeleitet“). Abhängig von dem spezifischen Modell, das durch den ausgeführten Algorithmus dargestellt wird, kann die Ausgabe des neuronalen Netzwerkalgorithmus verschiedene Formen annehmen.
Bevor ein Algorithmus für maschinelles Lernen verwendet werden kann, um ein bestimmtes Problem zu modellieren, wird der Algorithmus durch Verwenden eines Trainingsdatensatzes trainiert. Trainieren eines neuronalen Netzwerks beinhaltet Auswählen einer Netzwerktopologie, Verwenden eines Satzes von Trainingsdaten, die ein durch das Netzwerk modelliertes Problem darstellen, und Anpassen der Gewichte, bis das Netzwerkmodell für alle Instanzen des Trainingsdatensatzes mit einem minimalen Fehler ausgeführt wird. Zum Beispiel wird während eines beaufsichtigten Lerntrainingsprozesses für ein neuronales Netzwerk die Ausgabe, die durch das Netzwerk als Reaktion auf die Eingabe, die eine Instanz in einem Trainingsdatensatz darstellt, erzeugt wird, mit der als „korrekt“ gekennzeichneten Ausgabe für diese Instanz verglichen, ein Fehlersignal, das die Differenz zwischen der Ausgabe und der gekennzeichneten Ausgabe darstellt, wird berechnet, und die den Verbindungen zugeordneten Gewichte werden angepasst, um diesen Fehler zu minimieren, wenn das Fehlersignal rückwärts durch die Schichten des Netzwerks verbreitet wird. Das Netzwerk wird als „trainiert“ betrachtet, wenn die Fehler für jede der Ausgaben, die von den Instanzen des Trainingsdatensatzes erzeugt werden, minimiert sind.
Die Genauigkeit eines Algorithmus für maschinelles Lernen kann erheblich durch die Qualität des zum Trainieren des Algorithmus verwendeten Datensatzes beeinflusst werden. Der Trainingsprozess kann berechnungsintensiv sein, und kann auf einem herkömmlichen Mehrzweckprozessor viel Zeit in Anspruch nehmen. Dementsprechend wird Parallelverarbeitungs-Hardware verwendet, um viele Typen von Algorithmen für maschinelles Lernen zu trainieren. Dies ist besonders nützlich zur Optimierung des Trainings von neuronalen Netzwerken, da sich die beim Einstellen der Koeffizienten in neuronalen Netzwerken ausgeführten Berechnungen natürlich für parallele Implementierungen anbieten. Insbesondere wurden viele Algorithmen für maschinelles Lernen und Softwareanwendungen angepasst, um die Parallelverarbeitungs-Hardware innerhalb von Mehrzweck-Grafikverarbeitungsgeräten zu nutzen.
24 ist ein verallgemeinertes Diagramm von Software-Stapel zum maschinellen Lernen 2400. Anwendung für maschinelles Lernen 2402 kann dazu ausgelegt sein, ein neuronales Netzwerk durch Verwenden eines Trainingsdatensatzes zu trainieren, oder ein trainiertes tiefes neuronales Netzwerk zu verwenden, um maschinelle Intelligenz zu implementieren. Die Anwendung für maschinelles Lernen 2402 kann Trainings- und Inferenzfunktionalität für ein neuronales Netzwerk und/oder spezialisierte Software beinhalten, die verwendet werden kann, um ein neuronales Netzwerk vor dem Einsatz zu trainieren. Die Anwendung für maschinelles Lernen 2402 kann jeglichen Typ von maschineller Intelligenz implementieren, einschließlich, aber nicht beschränkt auf Bilderkennung, Abbildung und Lokalisierung, autonome Navigation, Sprachsynthese, medizinische Bildgebung oder Sprachübersetzung.
Die Hardwarebeschleunigung für die Anwendung für maschinelles Lernen 2402 kann über Framework für maschinelles Lernen 2404 aktiviert werden. Der Framework für maschinelles Lernen 2404 kann eine Bibliothek von Grundelementen für maschinelles Lernen bereitstellen. Grundelemente für maschinelles Lernen sind Basisoperationen, die üblicherweise durch Algorithmen für maschinelles Lernen ausgeführt werden. Ohne den Framework für maschinelles Lernen 2404 müssten Entwickler von Algorithmen für maschinelles Lernen die dem Algorithmus für maschinelles Lernen zugeordnete Hauptberechnungslogik erstellen und optimieren, und dann die Berechnungslogik erneut optimieren, wenn neue Parallelprozessoren entwickelt werden. Stattdessen kann die Anwendung für maschinelles Lernen dazu ausgelegt werden, die erforderlichen Berechnungen durch Verwenden der durch den Framework für maschinelles Lernen 2404 bereitgestellten Grundelemente auszuführen. Beispielhafte Grundelemente beinhalten Tensorfaltungen, Aktivierungsfunktionen und Pooling, was Rechenoperationen sind, die während des Trainierens eines neuronalen Faltungsnetzwerks (CNN) ausgeführt werden. Der Framework für maschinelles Lernen 2404 kann auch Grundelemente bereitstellen, um grundlegende lineare Algebra-Unterprogramme zu implementieren, die durch viele Algorithmen für maschinelles Lernen, wie zum Beispiel Matrix- und Vektoroperationen, ausgeführt werden.
Der Framework für maschinelles Lernen 2404 kann von der Anwendung für maschinelles Lernen 2402 empfangene Eingabedaten verarbeiten und die entsprechende Eingabe an Berechnungs-Framework 2406 erzeugen. Der Berechnungs-Framework 2406 kann die dem GPGPU-Treiber 2408 bereitgestellten zugrunde liegenden Anweisungen abstrahieren, um es dem Framework für maschinelles Lernen 2404 zu ermöglichen, sich Hardwarebeschleunigung über GPGPU-Hardware 2410 zu Nutze zu machen, ohne dass der Framework für maschinelles Lernen 2404 genaue Kenntnisse über die Architektur der GPGPU-Hardware 2410 haben muss. Zusätzlich kann der Berechnungs-Framework 2406 eine Hardwarebeschleunigung für den Framework für maschinelles Lernen 2404 über eine Vielzahl von Typen und Generationen der GPGPU-Hardware 2410 ermöglichen.
GPGPU Beschleunigung für maschinelles Lernen
25 veranschaulicht Multi-GPU-Computersystem 2500 gemäß einer Ausführungsform. Das Multi-GPU-Computersystem 2500 kann Prozessor 2502 beinhalten, der über Host-Schnittstellenschalter 2504 mit mehreren GPGPU 2506A-D gekoppelt ist. Der Host-Schnittstellenschalter 2504 ist in einer Ausführungsform ein PCI-Express-Schaltergerät, das den Prozessor 2502 mit einem PCI-Express-Bus koppelt, über den der Prozessor 2502 mit dem Satz von GPGPU 2506A-D kommunizieren kann. Jede der mehreren GPGPU 2506A-D kann eine Instanz der oben beschriebenen GPGPU sein. Die GPGPU 2506A-D können über einen Satz von Hochgeschwindigkeits-Punkt-zu-Punkt-GPU mit GPU-Verbindungen 2516 verbunden sein. Die Hochgeschwindigkeits-GPU-zu-GPU-Verbindungen können über eine fest zugeordnete GPU-Verbindung mit jeder der GPGPU 2506A-D verbunden sein. Die P2P-GPU-Verbindungen 2516 ermöglichen direkte Kommunikation zwischen jeder der GPGPU 2506A-D, ohne dass eine Kommunikation über den Host-Schnittstellenbus, mit dem der Prozessor 2502 verbunden ist, erforderlich ist. Mit GPU-zu-GPU-Verkehr, der zu den P2P-GPU-Verbindungen geleitet wird, bleibt der Host-Schnittstellenbus für Systemspeicherzugriff oder für Kommunikation mit anderen Instanzen des Multi-GPU-Computersystems 2500 verfügbar, zum Beispiel über ein oder mehrere Netzwerkgeräte. Während in der dargestellten Ausführungsform die GPGPU 2506A-D über den Host-Schnittstellenschalter 2504 mit dem Prozessor 2502 verbunden sind, beinhaltet der Prozessor 2502 in einer Ausführungsform eine direkte Unterstützung für die P2P-GPU-Verbindungen 2516 und kann direkt mit den GPGPU 2506A-D verbunden sein.
Implementierungen von neuronalen Netzwerken für maschinelles Lernen
Die durch die hierin beschriebenen Ausführungsformen bereitgestellte Computerarchitektur kann dazu ausgelegt sein, die Typen der Parallelverarbeitung auszuführen, die besonders zum Trainieren und Einsetzen neuronaler Netzwerke für maschinelles Lernen geeignet sind. Ein neuronales Netzwerk kann als ein Netzwerk von Funktionen mit einer graphischen Beziehung verallgemeinert werden. Wie in der Technik gut bekannt ist, gibt es eine Vielzahl von Typen von Implementierungen neuronaler Netzwerke, die beim maschinellen Lernen verwendet werden. Ein beispielhafter Typ eines neuronalen Netzwerks ist das zuvor beschriebene Feedforward-Netzwerk.
Ein zweiter beispielhafter Typ eines neuronalen Netzwerks ist das neuronale Faltungsnetzwerk (CNN). Ein CNN ist ein spezialisiertes neuronales Feedforward-Netzwerk zum Verarbeiten von Daten mit einer bekannten, gitterartigen Topologie, wie zum Beispiel Bilddaten. Dementsprechend werden CNN üblicherweise für Bildverarbeitungs- und Bilderkennungsanwendungen verwendet, sie können jedoch auch für andere Typen der Mustererkennung, wie zum Beispiel Sprachverarbeitung verwendet werden. Die Knoten in der CNN-Eingabeschicht sind in einen Satz von „Filtern“ (Merkmaldetektoren, die von den in der Netzhaut gefundenen Empfangsfeldern inspiriert sind) organisiert, und die Ausgabe jedes Filtersatzes wird an Knoten in aufeinanderfolgenden Schichten des Netzwerks verbreitet. Die Berechnungen für ein CNN beinhalten Anwenden der mathematischen Faltungsoperation auf jeden Filter, um die Ausgabe dieses Filters zu erzeugen. Faltung ist eine spezielle mathematische Operation, die durch zwei Funktionen ausgeführt wird, um eine dritte Funktion zu erzeugen, die eine modifizierte Version einer der beiden ursprünglichen Funktionen ist. In der Faltungsnetzwerkterminologie kann die erste Funktion der Faltung als die Eingabe bezeichnet werden, während die zweite Funktion als der Faltungs-Kernel bezeichnet werden kann. Die Ausgabe kann als die Merkmalabbildung bezeichnet werden. Zum Beispiel kann die Eingabe in eine Faltungsschicht ein mehrdimensionales Array von Daten sein, das die verschiedenen Farbkomponenten eines Eingabebildes definiert. Der Faltungs-Kernel kann ein mehrdimensionales Array von Parametern sein, wobei die Parameter durch den Trainingsprozess für das neuronale Netzwerk angepasst werden.
Rekurrente neuronale Netze (RNN) sind eine Familie von neuronalen Feedforward-Netzwerken, die Rückmeldungsverbindungen zwischen Schichten beinhalten. RNN ermöglichen die Modellierung sequentieller Daten durch Teilen von Parameterdaten über unterschiedliche Teile des neuronalen Netzwerks hinweg. Die Architektur für ein RNN beinhaltet Zyklen. Die Zyklen stellen den Einfluss eines gegenwärtigen Werts einer Variablen auf ihren eigenen Wert zu einem zukünftigen Zeitpunkt dar, da mindestens ein Abschnitt der Ausgabedaten von dem RNN als Rückmeldung zur Verarbeitung nachfolgender Eingaben in einer Sequenz verwendet wird. Dieses Merkmal macht RNN aufgrund der variablen Natur, in der Sprachdaten zusammengesetzt werden können, besonders nützlich für Sprachverarbeitung.
Die unten beschriebenen Figuren stellen beispielhafte Feedforward-, CNN- und RNN-Netzwerke dar und beschreiben einen allgemeinen Prozess zum jeweiligen Trainieren und Einsetzen jedes dieser Netzwerktypen. Es versteht sich, dass diese Beschreibungen beispielhaft und nicht beschränkend für jegliche hierin beschriebene spezifische Ausführungsform sind, und die veranschaulichten Konzepte allgemein auf tiefe neuronale Netzwerke und Techniken zum maschinellen Lernen im Allgemeinen angewendet werden können.
Die oben beschriebenen beispielhaften neuronalen Netzwerke können verwendet werden, um tiefes Lernen auszuführen. Tiefes Lernen ist maschinelles Lernen durch Verwenden tiefer neuronaler Netzwerke. Die beim tiefen Lernen verwendeten tiefen neuronalen Netzwerke sind aus mehreren verborgenen Schichten zusammengesetzte künstliche neuronale Netzwerke, im Gegensatz zu flachen neuronalen Netzwerken, die nur eine einzige verborgene Schicht beinhalten. Tiefere neuronale Netzwerke sind im Allgemeinen berechnungsintensiver zu trainieren. Die zusätzlichen verborgenen Schichten des Netzwerks ermöglichen jedoch eine Mehrschrittmustererkennung, die einen verringerten Ausgabefehler im Verhältnis zu flachen Techniken für maschinelles Lernen zur Folge hat.
Beim tiefen Lernen verwendete tiefe neuronale Netzwerke beinhalten typischerweise ein Front-End-Netzwerk zum Ausführen einer Merkmalserkennung, das mit einem Back-End-Netzwerk gekoppelt ist, das ein mathematisches Modell darstellt, das Operationen (zum Beispiel Objektklassifizierung, Spracherkennung, usw.) basierend auf der dem Modell bereitgestellten Merkmalsdarstellung ausführen kann. Tiefes Lernen ermöglicht das Ausführen maschinellen Lernens, ohne dass handgefertigte Merkmalskonstruktion für das Modell ausgeführt werden muss. Stattdessen können tiefe neuronale Netzwerke Merkmale basierend auf der statistischen Struktur oder Korrelation innerhalb der Eingabedaten lernen. Die gelernten Merkmale können einem mathematischen Modell bereitgestellt werden, das erkannte Merkmale an eine Ausgabe abbilden kann. Das durch das Netzwerk verwendete mathematische Modell ist im Allgemeinen auf die spezifische auszuführende Aufgabe spezialisiert, und unterschiedliche Modelle werden verwendet, um unterschiedliche Aufgaben auszuführen.
Sobald das neuronale Netzwerk strukturiert ist, kann ein Lernmodell auf das Netzwerk angewendet werden, um das Netzwerk für die Ausführung spezifischer Aufgaben zu trainieren. Das Lernmodell beschreibt, wie die Gewichte innerhalb des Modells angepasst werden, um den Ausgabefehler des Netzwerks zu verringern. Die Rückverbreitung von Fehlern ist ein übliches Verfahren, das zum Trainieren neuronaler Netzwerke verwendet wird. Ein Eingabevektor wird dem Netzwerk zur Verarbeitung präsentiert. Die Ausgabe des Netzwerks wird durch Verwenden einer Verlustfunktion mit der gewünschten Ausgabe verglichen, und für jedes der Neuronen in der Ausgabeschicht wird ein Fehlerwert berechnet. Die Fehlerwerte werden dann rückwärts verbreitet, bis jedem Neuron ein Fehlerwert zugeordnet ist, der ungefähr seinen Beitrag zu der ursprünglichen Ausgabe darstellt. Das Netzwerk kann dann aus diesen Fehlern lernen, indem es einen Algorithmus, wie zum Beispiel den Algorithmus für den stochastischen Gradientenabstieg, verwendet, um die Gewichte des neuronalen Netzwerks zu aktualisieren.
Die 26-27 veranschaulichen ein beispielhaftes neuronales Faltungsnetzwerk. 26 veranschaulicht verschiedene Schichten innerhalb eines CNN. Wie in 26 gezeigt, kann ein beispielhaftes CNN, das zum Modellieren von Bildverarbeitung verwendet wird, Eingabe 2602 empfangen, die die Rot-, Grün- und Blau- (RGB-) Komponenten eines Eingabebildes beschreibt. Die Eingabe 2602 kann durch mehrere Faltungsschichten (zum Beispiel Faltungsschicht 2604, Faltungsschicht 2606) verarbeitet werden. Die Ausgabe von den mehreren Faltungsschichten kann optional durch einen Satz vollständig verbundener Schichten 2608 verarbeitet werden. Neuronen in einer vollständig verbundenen Schicht haben vollständige Verbindungen zu allen Aktivierungen in der vorherigen Schicht, wie zuvor für ein Feedforward-Netzwerk beschrieben. Die Ausgabe von den vollständig verbundenen Schichten 2608 kann verwendet werden, um ein Ausgabeergebnis von dem Netzwerk zu erzeugen. Die Aktivierungen innerhalb der vollständig verbundenen Schichten 2608 können durch Verwenden von Matrixmultiplikation anstelle von Faltung berechnet werden. Nicht alle CNN-Implementierungen verwenden vollständig verbundene Schichten. Zum Beispiel kann in einigen Implementierungen die Faltungsschicht 2606 eine Ausgabe für das CNN erzeugen.
Die Faltungsschichten sind spärlich miteinander verbunden, was sich von der herkömmlichen Konfiguration von neuronalen Netzwerken, die in den vollständig verbundenen Schichten 2608 zu finden ist, unterscheidet. Herkömmliche neuronale Netzwerkschichten sind vollständig verbunden, sodass jede Ausgabeeinheit mit jeder Eingabeeinheit interagiert. Die Faltungsschichten sind jedoch spärlich verbunden, da die Ausgabe der Faltung eines Feldes (anstelle des jeweiligen Statuswerts jedes der Knoten in dem Feld) in die Knoten der nachfolgenden Schicht eingegeben wird, wie veranschaulicht. Die den Faltungsschichten zugeordneten Kernel führen Faltungsoperationen aus, deren Ausgabe an die nächste Schicht gesendet wird. Die in den Faltungsschichten ausgeführte Dimensionalitätsreduzierung ist ein Aspekt, der es dem CNN ermöglicht, zu skalieren, um große Bilder zu verarbeiten.
27 veranschaulicht beispielhafte Berechnungsstufen innerhalb einer Faltungsschicht eines CNN. Eingaben in Faltungsschicht 2712 eines CNN können in drei Stufen von Faltungsschicht 2714 verarbeitet werden. Die drei Stufen können Faltungsstufe 2716, Erkennungsstufe 2718 und Pooling-Stufe 2720 beinhalten. Die Faltungsschicht 2714 kann dann Daten an eine nachfolgende Faltungsschicht ausgeben. Die letzte Faltungsschicht des Netzwerks kann Ausgangsmerkmalsabbildungsdaten erzeugen oder einer vollständig verbundenen Schicht eine Eingabe bereitstellen, um zum Beispiel einen Klassifizierungswert für die Eingabe in das CNN zu erzeugen.
In der Faltungsstufe 2716 werden mehrere Faltungen parallel ausgeführt, um einen Satz linearer Aktivierungen zu erzeugen. Die Faltungsstufe 2716 kann eine affine Transformation beinhalten, die jegliche Transformation ist, die als eine lineare Transformation plus eine Umwandlung spezifiziert werden kann. Affine Transformationen beinhalten Rotationen, Umwandlungen, Skalierungen und Kombinationen dieser Transformationen. Die Faltungsstufe berechnet die Ausgabe von Funktionen (zum Beispiel Neuronen), die mit spezifischen Bereichen in der Eingabe verbunden sind, die als die dem Neuron zugeordneter lokaler Bereich bestimmt werden können. Die Neuronen berechnen ein Skalarprodukt zwischen den Gewichten der Neuronen und dem Bereich in der lokalen Eingabe, mit dem die Neuronen verbunden sind. Die Ausgabe von der Faltungsstufe 2716 definiert einen Satz von linearen Aktivierungen, die durch aufeinanderfolgende Stufen der Faltungsschicht 2714 verarbeitet werden.
Die linearen Aktivierungen können durch eine Erkennungsstufe 2718 verarbeitet werden. In der Erkennungsstufe 2718 wird jede lineare Aktivierung durch eine nicht lineare Aktivierungsfunktion verarbeitet. Die nichtlineare Aktivierungsfunktion erhöht die nichtlinearen Eigenschaften des gesamten Netzwerks, ohne die Empfangsfelder der Faltungsschicht zu beeinflussen. Es können verschiedene Typen von nichtlinearen Aktivierungsfunktionen verwendet werden. Ein besonderer Typ ist die gleichgerichtete Lineareinheit (Rectified-Linear-Unit - ReLU), die eine Aktivierungsfunktion verwendet, die als f(x)=max (0,x) definiert ist, sodass die Schwelle der Aktivierung Null ist.
Die Pooling-Stufe 2720 verwendet eine Pooling-Funktion, die die Ausgabe der Faltungsschicht 2706 durch eine zusammenfassende Statistik der nahegelegenen Ausgaben ersetzt. Die Pooling-Funktion kann verwendet werden, um eine Umwandlungsinvarianz in das neuronale Netzwerk einzuführen, sodass kleine Umwandlungen der Eingabe die gepoolten Ausgaben nicht verändern. Die Invarianz der lokalen Umwandlung kann in Szenarien hilfreich sein, in denen das Vorhandensein eines Merkmals in den Eingabedaten wichtiger ist als die genaue Position des Merkmals. Während der Pooling-Stufe 2720 können verschiedene Typen von Pooling-Funktionen verwendet werden, einschließlich Max-Pooling, Average-Pooling und L2-Norm-Pooling. Zusätzlich beinhalten einige CNN-Implementierungen keine Pooling-Stufe. Stattdessen ersetzen solche Implementierungen eine zusätzliche Faltungsstufe mit einem erhöhten Schritt im Vergleich zu früheren Faltungsstufen.
Die Ausgabe von der Faltungsschicht 2714 kann dann durch nächste Schicht 2722 verarbeitet werden. Die nächste Schicht 2722 kann eine zusätzliche Faltungsschicht oder eine der vollständig verbundenen Schichten 2708 sein. Zum Beispiel kann die erste Faltungsschicht 2704 von 27 an die zweite Faltungsschicht 2706 ausgeben, während die zweite Faltungsschicht an eine erste Schicht der vollständig verbundenen Schichten 2808 ausgeben kann.
28 veranschaulicht beispielhaftes rekurrentes neuronales Netzwerk 2800. In einem rekurrenten neuronalen Netzwerk (RNN) beeinflusst der vorherige Status des Netzwerks die Ausgabe des aktuellen Status des Netzwerks. RNN können auf verschiedene Weisen durch Verwenden verschiedener Funktionen aufgebaut werden. Die Verwendung von RNN dreht sich im Allgemeinen um die Verwendung mathematischer Modelle zur Vorhersage der Zukunft basierend auf einer vorherigen Sequenz von Eingaben. Zum Beispiel kann ein RNN verwendet werden, um eine statistische Sprachmodellierung auszuführen, um ein bevorstehendes Wort bei einer gegebenen vorherigen Sequenz von Wörtern vorherzusagen. Das veranschaulichte RNN 2800 kann so beschrieben werden, dass es Eingabeschicht 2802, die einen Eingabevektor empfängt, versteckte Schichten 2804 zum Implementieren einer rekurrenten Funktion, Rückmeldungsmechanismus 2805 zum Ermöglichen eines „Speichers“ früherer Stati, und Ausgabeschicht 2806 zum Ausgeben eines Ergebnisses hat. Das RNN 2800 arbeitet basierend auf Zeitschritten. Der Status des RNN zu einem gegebenen Zeitschritt wird basierend auf dem vorherigen Zeitschritt über den Rückmeldungsmechanismus 2805 beeinflusst. Für einen gegebenen Zeitschritt wird der Status der verborgenen Schichten 2804 durch den vorherigen Status und die Eingabe zu dem gegenwärtigen Zeitschritt definiert. Eine anfängliche Eingabe (x1) in einem ersten Zeitschritt kann durch die verborgene Schicht 2804 verarbeitet werden. Eine zweite Eingabe (x2) kann durch die verborgene Schicht 2804 durch Verwenden von während der Verarbeitung der anfänglichen Eingabe (x1) bestimmten Statusinformationen verarbeitet werden. Ein gegebener Status kann berechnet werden als s_t=f(Ux_t+Ws_(t-1)), wobei U und W Parametermatrizen sind. Die Funktion f ist im Allgemeinen eine Nichtlinearität, wie zum Beispiel die hyperbolische Tangensfunktion (Tanh) oder eine Variante der Gleichrichterfunktion f(x) = max (0,x). Die in den verborgenen Schichten 2804 verwendete spezifische mathematische Funktion kann jedoch abhängig von den spezifischen Implementierungsdetails des RNN 2800 variieren.
Zusätzlich zu den beschriebenen grundlegenden CNN- und RNN-Netzwerken können Variationen dieser Netzwerke ermöglicht werden. Eine beispielhafte RNN-Variante ist das Long-Short-Term-Memory (LSTM) -RNN. LSTM-RNN sind in der Lage, langfristige Abhängigkeiten zu lernen, die für die Verarbeitung längerer Sprachsequenzen erforderlich sein können. Eine Variante des CNN ist ein Deep-Believe-Faltungs-Netzwerk, das eine ähnliche Struktur wie ein CNN hat und auf eine ähnliche Weise wie ein Deep-Believe-Netzwerk trainiert wird. Ein Deep-Believe-Network (DBN) ist ein erzeugendes neuronales Netzwerk, das aus mehreren Schichten stochastischer (zufälliger) Variablen zusammensetzt ist. DBN können durch Verwenden von anspruchsvollem unbeaufsichtigtem Lernen Schicht für Schicht trainiert werden. Die gelernten Gewichte des DBN können dann verwendet werden, um vor dem Training stehende neuronale Netzwerke bereitzustellen, indem ein optimaler ursprünglicher Satz von Gewichten für das neuronale Netzwerk bestimmt wird.
29 veranschaulicht Training und Einsatz eines tiefen neuronalen Netzwerks. Sobald ein gegebenes Netzwerk für eine Aufgabe strukturiert worden ist, wird das neuronale Netzwerk durch Verwenden von Trainingsdatensatz 2902 trainiert. Verschiedene Trainings-Frameworks 2904 sind entwickelt worden, um Hardware-Beschleunigung des Trainingsprozesses zu ermöglichen. Zum Beispiel kann das oben beschriebene Framework für maschinelles Lernen als ein Trainings-Framework konfiguriert sein. Das Trainings-Framework 2904 kann sich in untrainiertes neuronales Netzwerk 2906 einhängen und ermöglichen, dass das untrainierte neuronale Netzwerk durch Verwenden der hierin beschriebenen Parallelverarbeitungsressourcen trainiert wird, um trainiertes neuronales Netzwerk 2908 zu erzeugen.
Um den Trainingsprozess zu starten, können die Anfangsgewichte zufällig oder durch Vorabtraining durch Verwenden eines Deep-Believe-Networks ausgewählt werden. Der Trainingszyklus kann dann entweder in einer beaufsichtigten oder unbeaufsichtigten Art und Weise ausgeführt werden.
Beaufsichtigtes Lernen ist ein Lernverfahren, bei dem das Training als vermittelte Operation ausgeführt wird, wie zum Beispiel, wenn der Trainingsdatensatz 2902 eine mit der gewünschten Ausgabe für die Eingabe gepaarte Eingabe beinhaltet, oder wenn der Trainingsdatensatz eine Eingabe mit bekannter Ausgabe beinhaltet, und die Ausgabe des neuronalen Netzwerks manuell bewertet wird. Das Netzwerk verarbeitet die Eingaben und vergleicht die resultierenden Ausgaben mit einem Satz von erwarteten oder gewünschten Ausgaben. Fehler werden dann durch das System zurück verbreitet. Das Trainings-Framework 2904 kann sich anpassen, um die Gewichte, die das untrainierte neuronale Netzwerk 2906 steuern, anzupassen. Das Trainings-Framework 2904 kann Werkzeuge bereitstellen, um zu überwachen, wie gut das untrainierte neuronale Netzwerk 2906 in Richtung eines Modells konvergiert, das geeignet ist, korrekte Antworten basierend auf bekannten Eingabedaten zu erzeugen. Der Trainingsprozess tritt wiederholt auf, wenn die Gewichte des Netzwerks angepasst werden, um die durch das neuronale Netzwerk erzeugte Ausgabe zu verfeinern. Der Trainingsprozess kann fortgesetzt werden, bis das neuronale Netzwerk eine einem trainierten neuronalen Netzwerk 2908 zugeordnete statistisch gewünschte Genauigkeit erreicht. Das trainierte neuronale Netzwerk 2908 kann dann eingesetzt werden, um jegliche Anzahl von maschinellen Lernoperationen auszuführen.
Unbeaufsichtigtes Lernen ist eine Lernmethode, bei der das Netzwerk versucht, sich mit nicht etikettierten Daten zu trainieren. Somit beinhaltet der Trainingsdatensatz 2902 für unbeaufsichtigtes Lernen Eingabedaten ohne zugeordnete Ausgabedaten. Das untrainierte neuronale Netzwerk 2906 kann Gruppierungen innerhalb der nicht etikettierten Eingabe lernen, und kann bestimmen, wie einzelne Eingaben mit dem Gesamtdatensatz in Beziehung stehen. Unbeaufsichtigtes Training kann verwendet werden, um eine selbstorganisierende Abbildung zu erzeugen, die ein Typ eines trainierten neuronalen Netzwerks 2907 ist, das Operationen ausführen kann, die zum Reduzieren der Dimensionalität von Daten nützlich sind. Unbeaufsichtigtes Training kann auch zur Erkennung von Anomalien verwendet werden, wodurch Datenpunkte in einem Eingabedatensatz identifiziert werden können, die von den normalen Mustern der Daten abweichen.
Variationen von beaufsichtigtem und unbeaufsichtigtem Training können ebenfalls eingesetzt werden. Halbbeaufsichtigtes Lernen ist eine Technik, bei der der Trainingsdatensatz 2902 eine Mischung aus etikettierten und nicht etikettierten Daten derselben Verteilung beinhaltet. Inkrementelles Lernen ist eine Variante des beaufsichtigten Lernens, bei der Eingabedaten kontinuierlich zum weiteren Trainieren des Modells verwendet werden. Inkrementelles Lernen ermöglicht es dem trainierten neuronalen Netzwerk 2908, sich an neue Daten 2912 anzupassen, ohne das im Netzwerk während des anfänglichen Trainings beigebrachte Wissen zu vergessen.
Unabhängig davon, ob beaufsichtigt oder unbeaufsichtigt, kann der Trainingsprozess für besonders tiefe neuronale Netzwerke für einen einzelnen Rechenknoten zu berechnungsintensiv sein. Anstelle eines einzelnen Rechenknotens kann ein verteiltes Netzwerk von Rechenknoten verwendet werden, um den Trainingsprozess zu beschleunigen.
30A ist ein Blockdiagramm, das verteiltes Lernen veranschaulicht. Verteiltes Lernen ist ein Trainingsmodell, das mehrere verteilte Rechenknoten, wie zum Beispiel die oben beschriebenen Knoten, verwendet, um ein beaufsichtigtes oder unbeaufsichtigtes Training eines neuronalen Netzwerks auszuführen. Die verteilten Rechenknoten können jeweils einen oder mehrere Host-Prozessoren und einen oder mehrere der Mehrzweck-Verarbeitungsknoten, wie zum Beispiel eine hochparallele Mehrzweck-Grafikverarbeitungseinheit, beinhalten. Wie veranschaulicht, kann verteiltes Lernen mit Modellparallelität 3002, Datenparallelität 3004 oder einer Kombination von Modell- und Datenparallelität ausgeführt werden.
Bei der Modellparallelität 3002 können unterschiedliche Rechenknoten in einem verteilten System Trainingsberechnungen für unterschiedliche Teile eines einzelnen Netzwerks ausführen. Zum Beispiel kann jede Schicht eines neuronalen Netzwerks durch einen unterschiedlichen Verarbeitungsknoten des verteilten Systems trainiert werden. Die Vorteile von Modellparallelität beinhalten die Fähigkeit, auf besonders große Modelle zu skalieren. Aufteilen der unterschiedlichen Schichten des neuronalen Netzwerks zugeordneten Berechnungen ermöglicht das Training sehr großer neuronaler Netzwerke, bei denen die Gewichte aller Schichten nicht in den Speicher eines einzelnen Rechenknotens passen würden. In einigen Fällen kann Modellparallelität insbesondere nützlich sein, um ein unbeaufsichtigtes Training großer neuronaler Netzwerke auszuführen.
Bei der Datenparallelität 3004 haben die unterschiedlichen Knoten des verteilten Netzwerks eine vollständige Instanz des Modells, und jeder Knoten empfängt einen unterschiedlichen Abschnitt der Daten. Die Ergebnisse der unterschiedlichen Knoten werden dann kombiniert. Während unterschiedliche Ansätze zu Datenparallelität möglich sind, erfordern alle Ansätze zum datenparallelen Training eine Technik zum Kombinieren von Ergebnissen und zum Synchronisieren der Modellparameter zwischen jedem Knoten. Beispielhafte Ansätze zum Kombinieren von Daten beinhalten eine Parametermittelwertbildung und eine aktualisierungsbasierte Datenparallelität. Parametermittelwertbildung trainiert jeden Knoten in einem Untersatz der Trainingsdaten und setzt die globalen Parameter (zum Beispiel Gewichte, Vorspannungen) auf den Durchschnitt der Parameter von jedem Knoten. Parametermittelwertbildung verwendet einen zentralen Parameterserver, der die Parameterdaten aufrechterhält. Aktualisierungsbasierte Datenparallelität ist ähnlich der Parametermittelwertbildung, außer, dass anstelle der Übertragung von Parametern von den Knoten an den Parameterserver die Aktualisierungen an das Modell übertragen werden. Zusätzlich kann eine aktualisierungsbasierte Datenparallelität in dezentraler Weise ausgeführt werden, wobei die Aktualisierungen komprimiert und zwischen Knoten übertragen werden.
Kombinierte Modell- und Datenparallelität 3006 kann zum Beispiel in einem verteilten System, in dem jeder Rechenknoten mehrere GPU beinhaltet, implementiert werden. Jeder Knoten kann eine vollständige Instanz des Modells haben, wobei separate GPU innerhalb jedes Knotens verwendet werden, um unterschiedliche Abschnitte des Modells zu trainieren.
Verteiltes Training hat den Mehraufwand im Vergleich zu Training auf einer einzelnen Maschine erhöht. Die hierin beschriebenen Parallelprozessoren und GPGPU können jedoch jeweils verschiedene Techniken implementieren, um den Mehraufwand für verteiltes Training zu reduzieren, einschließlich Techniken, um eine GPU-zu-GPU-Datenübertragung mit hoher Bandbreite und eine beschleunigte Datenfernsynchronisation zu ermöglichen.
Beispielhafte Anwendungen für maschinelles Lernen
Maschinelles Lernen kann angewendet werden, um eine Vielzahl von technologischen Problemen zu lösen, einschließlich, aber nicht beschränkt auf Bilderkennung, autonomes Fahren und Navigieren, Spracherkennung und Sprachverarbeitung. Bilderkennung ist traditionell eines der aktivsten Forschungsgebiete für Anwendungen des maschinellen Lernens. Anwendungen der Bilderkennung reichen von Reproduktion menschlicher Sehfähigkeiten, wie zum Beispiel der Erkennung von Gesichtern, bis zur Erzeugung neuer Kategorien visueller Fähigkeiten. Beispielsweise können Bilderkennungsanwendungen dazu ausgelegt sein, Schallwellen von den Schwingungen zu erkennen, die in Objekten induziert sind, die in einem Video sichtbar sind. Beschleunigtes maschinelles Lernen mit Parallelprozessoren ermöglicht es, Bilderkennungsanwendungen durch Verwenden eines erheblich größeren Trainingsdatensatzes als vorher praktikabel zu trainieren, und ermöglicht es, Inferenzsysteme durch Verwenden von Niedrigleistungs-Parallelprozessoren einzusetzen.
Parallelprozessorbeschleunigtes maschinelles Lernen hat autonome Fahranwendungen, einschließlich Spur- und Verkehrszeichenerkennung, Hindernisvermeidung, Navigation und Fahrsteuerung. Beschleunigte Techniken des maschinellen Lernens können verwendet werden, um Fahrmodelle basierend auf Datensätzen zu trainieren, die die geeigneten Reaktionen auf spezifische Trainingseingaben definieren. Die hierin beschriebenen Parallelprozessoren können ein schnelles Training der zunehmend komplexen für autonome Fahrlösungen verwendeten neuronalen Netzwerke ermöglichen, und ermöglichen den Einsatz von Niedrigleistungs-Inferenzprozessoren in einer mobilen Plattform, die zur Integration in autonome Fahrzeuge geeignet ist.
Parallelprozessorbeschleunigte tiefe neuronale Netzwerke haben maschinelle Lernansätze für die automatische Spracherkennung (Automatic-Speech-Recognition - ASR) ermöglicht. ASR beinhaltet die Erzeugung einer Funktion, die die wahrscheinlichste Sprachsequenz bei einer gegebenen akustischen Eingabesequenz berechnet. Beschleunigtes maschinelles Lernen durch Verwenden tiefer neuronaler Netzwerke hat es ermöglicht, die bisher für ASR verwendeten Hidden-Markov-Models (HMM) und Gaussian-Mixture-Models (GMM) zu ersetzen.
Parallelprozessorbeschleunigtes maschinelles Lernen kann auch verwendet werden, um natürliche Sprachverarbeitung zu beschleunigen. Automatische Lernprozeduren können statistische Inferenzalgorithmen verwenden, um Modelle herzustellen, die robust gegen fehlerhafte oder unbekannte Eingaben sind. Beispielhafte natürliche Sprachverarbeitungsanwendungen beinhalten automatische maschinelle Übersetzung zwischen menschlichen Sprachen.
Die für maschinelles Lernen verwendeten Parallelverarbeitungsplattformen können in Trainingsplattformen und Einsatzplattformen unterteilt werden. Trainingsplattformen sind im Allgemeinen hoch parallel und beinhalten Optimierungen zur Beschleunigung des Trainings mit mehreren GPU für einen einzelnen Knoten und des Trainings mit mehreren Knoten und mehreren GPU. Beispielhafte für Training geeignete Parallelprozessoren beinhalten die hoch parallele Mehrzweck-Grafikverarbeitungseinheit und/oder die hierin beschriebenen Multi-GPU-Computersysteme. Im Gegensatz dazu beinhalten eingesetzte Plattformen für maschinelles Lernen im Allgemeinen Niedrigleistungs-Parallelprozessoren, die zur Verwendung in Produkten, wie zum Beispiel Kameras, autonomen Robotern und autonomen Fahrzeugen, geeignet sind.
30B veranschaulicht beispielhaftes Inferenz-System-on-a-Chip (SOC) 3100, das zum Ausführen einer Inferenz durch Verwenden eines trainierten Modells geeignet ist. Das SOC 3100 kann Verarbeitungskomponenten, einschließlich Medienprozessor 3102, Bilderkennungsprozessor 3104, GPGPU 3106 und Multikernprozessor 3108, integrieren. Das SOC 3100 kann zusätzlich On-Chip-Speicher 3105 beinhalten, der einen geteilten On-Chip-Datenpool ermöglichen kann, auf den durch jede der Verarbeitungskomponenten zugegriffen werden kann. Die Verarbeitungskomponenten können für den Niedrigleistungsbetrieb optimiert werden, um den Einsatz auf einer Vielzahl von Plattformen für maschinelles Lernen, einschließlich autonomer Fahrzeuge und autonomer Roboter, zu ermöglichen. Zum Beispiel kann eine Implementierung des SOC 3100 als ein Abschnitt des Hauptsteuerungssystems für ein autonomes Fahrzeug verwendet werden. Wo das SOC 3100 für die Verwendung in autonomen Fahrzeugen konfiguriert ist, ist das SOC so konzipiert und konfiguriert, dass die relevanten funktionalen Sicherheitsstandards der Einsatzrechtssprechung eingehalten werden.
Während des Betriebs können der Medienprozessor 3102 und der Bilderkennungsprozessor 3104 im Verbund arbeiten, um die Bilderkennungsoperationen zu beschleunigen. Der Medienprozessor 3102 kann eine Decodierung mit niedriger Latenz von mehreren hochauflösenden (zum Beispiel 4K, 8K) Video-Streams ermöglichen. Die decodierten Video-Streams können in einen Puffer in dem On-Chip-Speicher 3105 geschrieben werden. Der Bilderkennungsprozessor 3104 kann dann das decodierte Video analysieren und vorab Verarbeitungsoperationen an den Frames des decodierten Videos ausführen, in Vorbereitung darauf, die Frames durch Verwenden eines trainierten Bilderkennungsmodells zu verarbeiten. Zum Beispiel kann der Bilderkennungsprozessor 3104 Faltungsoperationen für ein CNN, das zum Ausführen einer Bilderkennung an den hochauflösenden Videodaten verwendet wird, beschleunigen, während Back-End-Modellberechnungen durch die GPGPU 3106 ausgeführt werden.
Der Multikernprozessor 3108 kann Steuerlogik beinhalten, um die Sequenzierung und Synchronisierung von Datenübertragungen und geteilten Speicheroperationen, die durch den Medienprozessor 3102 und den Bilderkennungsprozessor 3104 ausgeführt werden, zu unterstützen. Der Multikernprozessor 3108 kann auch als ein Anwendungsprozessor funktionieren, um Softwareanwendungen auszuführen, die die Inferenzberechnungsfähigkeit der GPGPU 3106 nutzen können. Zum Beispiel kann mindestens ein Abschnitt der Navigations- und Treiberlogik in auf dem Multikernprozessor 3108 ausgeführte Software implementiert werden. Solche Software kann direkt Berechnungsarbeitslasten an die GPGPU 3106 ausgeben, oder die Berechnungsarbeitslasten können an den Multikernprozessor 3108 ausgegeben werden, der mindestens einen Abschnitt dieser Operationen an die GPGPU 3106 auslagern kann.
Die GPGPU 3106 kann Rechen-Cluster, wie zum Beispiel eine Niedrigenergie-Konfiguration der Rechen-Cluster DPLAB06A-DPLAB06H innerhalb der hoch parallelen Mehrzweck-Grafikverarbeitungseinheit DPLAB00 beinhalten. Die Rechen-Cluster innerhalb der GPGPU 3106 können Anweisungen unterstützen, die speziell für die Ausführung von Inferenzberechnungen in einem trainierten neuronalen Netzwerk optimiert sind. Zum Beispiel kann die GPGPU 3106 Anweisungen zum Ausführen von Berechnungen mit geringer Genauigkeit, wie zum Beispiel 8-Bit- und 4-Bit-Ganzzahlvektoroperationen unterstützen.
RAYTRACING-ARCHITEKTUR
In einer Implementierung beinhaltet der Grafikprozessor eine Schaltung und/oder Programmcode zum Ausführen von Echtzeit-Raytracing. In einigen Ausführungsformen ist ein fest zugeordneter Satz von Raytracing-Kernen in dem Grafikprozessor enthalten, um die verschiedenen hierin beschriebenen Raytracing-Operationen, einschließlich Ray-Durchquerungs- und/oder Ray-Kreuzungsoperationen, auszuführen. Zusätzlich zu den Raytracing-Kernen beinhaltet eine Ausführungsform mehrere Sätze von Grafikverarbeitungskernen zum Ausführen programmierbarer Shading-Operationen, und mehrere Sätze von Tensorkernen zum Ausführen von Matrixoperationen an Tensordaten.
31 veranschaulicht einen beispielhaften Abschnitt einer solchen Grafikverarbeitungseinheit (GPU) 3105, die fest zugeordnete Sätze von Grafikverarbeitungsressourcen beinhaltet, die in Multikerngruppen 3100A-N angeordnet sind. Während die Details nur einer einzelnen Multikerngruppe 3100A bereitgestellt werden, versteht es sich, dass die anderen Multikerngruppen 3100B-N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können.
Wie veranschaulicht, kann eine Multikerngruppe 3100A Grafikkernsatz 3130, Tensorkernsatz 3140 und Raytracing-Kernsatz 3150 beinhalten. Planer/Dispatcher 3110 plant und versendet die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 3130, 3140, 3150. Registerdateisatz 3120 speichert Operandenwerte, die durch die Kerne 3130, 3140, 3150 beim Ausführen der Grafik-Threads verwendet werden. Diese können zum Beispiel Ganzzahlregister zur Speicherung von Ganzzahlwerten, Gleitkommaregister zur Speicherung von Gleitkommawerten, Vektorregister zur Speicherung von gepackten Datenelementen (Ganzzahl- und/oder Gleitkommadatenelemente) und Kachelregister zur Speicherung von Tensor-/Matrixwerten beinhalten. In einer Ausführungsform sind die Kachelregister als kombinierte Sätze von Vektorregistern implementiert.
Ein oder mehrere Level 1 (L1) -Caches und Textureinheiten 3160 speichern Grafikdaten, wie zum Beispiel Texturdaten, Vertexdaten, Pixeldaten, Ray-Daten, Hüllvolumendaten, usw., lokal innerhalb jeder Multikerngruppe 3100A. Level 2 (L2) -Cache 3180, der durch alle oder einen Untersatz der Multikerngruppen 3100A-N geteilt wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafik-Threads. Wie veranschaulicht, kann der L2-Cache 3180 über mehrere Multikerngruppen 3100A-N hinweg geteilt werden. Eine oder mehrere Speichersteuerungen 3170 koppeln die GPU 3105 mit Speicher 3198, der ein Systemspeicher (zum Beispiel DRAM) und/oder ein fest zugeordneter Grafikspeicher (zum Beispiel GDDR6-Speicher) sein kann.
Eingabe-/Ausgabe (I/O) -Schaltung 3195 koppelt die GPU 3105 mit einem oder mehreren I/O-Geräten 3195, wie zum Beispiel digitalen Signalprozessoren (DSP), Netzwerksteuerungen oder Benutzereingabegeräten. Eine On-Chip-Verbindung kann verwendet werden, um I/O-Geräte 3190 mit der GPU 3105 und dem Speicher 3198 zu koppeln. Eine oder mehrere I/O-Speicherverwaltungseinheiten (IO-Memory-Management-Units - IOMMU) 3170 der I/O-Schaltung 3195 koppeln die I/O-Geräte 3190 direkt mit dem Systemspeicher 3198. In einer Ausführungsform verwaltet die IOMMU 3170 mehrere Sätze von Seitentabellen, um virtuelle Adressen zu physikalischen Adressen in dem Systemspeicher 3198 abzubilden. In dieser Ausführungsform können sich die I/O-Geräte 3190, CPU 3199 und die GPU 3105 den gleichen virtuellen Adressraum teilen.
In einer Implementierung unterstützt die IOMMU 3170 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen verwalten, um virtuelle Gast-/Grafikadressen zu physikalischen Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen, um die physikalischen Gast-/Grafikadressen zu physikalischen System-/Host-Adressen abzubilden (zum Beispiel innerhalb des Systemspeichers 3198). Die Basisadressen von jedem der ersten und zweiten Sätze von Seitentabellen können in Steuerregistern gespeichert und an einem Kontextschalter ausgetauscht werden (zum Beispiel, damit der neue Kontext mit Zugriff auf den relevanten Satz von Seitentabellen bereitgestellt wird). Während in 31 nicht veranschaulicht, kann jeder der Kerne 3130, 3140, 3150 und/oder der Multikerngruppen 3100A-N Translation-Lookaside-Buffer (TLB) beinhalten, um virtuelle Gast- zu physikalischen Gastumwandlungen, physikalische Gast- zu physikalischen Host-Umwandlungen und virtuelle Gast- zu physikalischen Host-Umwandlungen zwischenzuspeichern.
In einer Ausführungsform sind die CPU 3199, GPU 3105 und I/O-Geräte 3190 auf einem einzelnen Halbleiterchip und/oder Chip-Paket integriert. Der veranschaulichte Speicher 3198 kann auf demselben Chip integriert sein, oder kann über eine Chip-externe Schnittstelle mit den Speichersteuerungen 3170 gekoppelt sein. In einer Implementierung umfasst der Speicher 3198 einen GDDR6-Speicher, der denselben virtuellen Adressraum wie andere physikalische Speicher auf Systemebene teilt, obwohl die zugrunde liegenden Prinzipien der Erfindung nicht auf diese spezifische Implementierung beschränkt sind.
In einer Ausführungsform Beinhalten die Tensorkerne 3140 mehrere Ausführungseinheiten, die spezifisch zum Ausführen von Matrixoperationen ausgelegt sind, die die zum Ausführen von Operationen zum tiefen Lernen verwendeten grundlegenden Rechenoperationen sind. Zum Beispiel können simultane Matrixmultiplikationsoperationen zum Trainieren und Inferenzieren von neuronalen Netzwerken verwendet werden. Die Tensorkerne 3140 können eine Matrixverarbeitung durch Verwenden einer Vielzahl von Operandengenauigkeiten ausführen, einschließlich Gleitkommazahlen mit einfacher Genauigkeit (zum Beispiel 32 Bits), Gleitkommazahlen mit halber Genauigkeit (zum Beispiel 16 Bits), Ganzzahlwörter (16 Bits), Bytes (8 Bits) und Halbbytes (4 Bits). In einer Ausführungsform extrahiert eine neuronale Netzwerkimplementierung Merkmale jeder gerenderten Szene, wobei potenziell Details von mehreren Frames kombiniert werden, um ein qualitativ hochwertiges endgültiges Bild aufzubauen.
In Implementierungen von tiefem Lernen kann parallele Matrixmultiplikationsarbeit zur Ausführung auf den Tensorkernen 3140 geplant werden. Insbesondere das Training neuronaler Netzwerke erfordert eine erhebliche Anzahl von Matrix-Skalarproduktoperationen. Um eine Innenproduktformulierung einer NxNxN-Matrixmultiplikation zu verarbeiten, können die Tensorkerne 3140 mindestens N Skalarproduktverarbeitungselemente beinhalten. Bevor die Matrixmultiplikation beginnt, wird eine gesamte Matrix in Kachelregister geladen, und mindestens eine Spalte einer zweiten Matrix wird für N Zyklen in jedem Zyklus geladen. In jedem Zyklus gibt es N Skalarprodukte, die verarbeitet werden.
Matrixelemente können abhängig von der bestimmten Implementierung mit unterschiedlichen Genauigkeiten gespeichert werden, einschließlich 16-Bit-Wörtern, 8-Bit-Bytes (zum Beispiel INT8) und 4-Bit-Halbbytes (zum Beispiel INT4). Für die Tensorkerne 3140 können verschiedene Genauigkeitsmodi spezifiziert werden, um zu gewährleisten, dass die effizienteste Genauigkeit für unterschiedliche Arbeitslasten verwendet wird (zum Beispiel zum Inferenzieren von Arbeitslasten, die eine Quantisierung in Bytes und Halbbytes tolerieren können).
In einer Ausführungsform beschleunigen die Raytracing-Kerne 3150 Raytracing-Operationen sowohl für Echtzeit-Raytracing- als auch Nicht-Echtzeit-Raytracing-Implementierungen. Insbesondere beinhalten die Raytracing-Kerne 3150 Ray-Durchquerungs-/Kreuzungsschaltungen zum Ausführen einer Ray-Durchquerung durch Verwenden von Hüllvolumenhierarchien (Bounding-Volume-Hierarchies - BVH) und zum Identifizieren von Kreuzungen zwischen Rays und Grundelementen, die in den BVH-Volumina eingeschlossen sind. Die Raytracing-Kerne 3150 können auch Schaltungen zum Ausführen von Tiefenprüfungen und Culling (zum Beispiel durch Verwenden eines Z-Puffers oder einer ähnlichen Anordnung) beinhalten. In einer Implementierung führen die Raytracing-Kerne 3150 Durchquerungs- und Kreuzungsoperationen in Übereinstimmung mit den hierin beschriebenen Bild-Rauschunterdrückungstechniken aus, von denen mindestens ein Abschnitt auf den Tensorkernen 3140 ausgeführt werden kann. Zum Beispiel implementieren in einer Ausführungsform die Tensorkerne 3140 ein neuronales Netzwerk zum tiefen Lernen, um Rauschunterdrückung von durch die Raytracing-Kerne 3150 erzeugten Frames auszuführen. Die CPU 3199, die Grafikkerne 3130 und/oder die Raytracing-Kerne 3150 können jedoch auch alle oder einen Abschnitt der Rauschunterdrückungsalgorithmen und/oder der Algorithmen zum tiefen Lernen implementieren.
Zusätzlich kann, wie oben beschrieben, ein verteilter Ansatz zur Rauschunterdrückung verwendet werden, bei dem sich die GPU 3105 in einem Berechnungsgerät befindet, das über ein Netzwerk oder eine Hochgeschwindigkeitsverbindung mit anderen Berechnungsgeräten gekoppelt ist. In dieser Ausführungsform teilen sich die verbundenen Berechnungsgeräte Lern-/Trainingsdaten für ein neuronales Netzwerk, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, Rauschunterdrückung für unterschiedliche Typen von Bild-Frames und/oder unterschiedliche Grafikanwendungen auszuführen.
In einer Ausführungsform verarbeiten die Raytracing-Kerne 3150 alle BVH-Durchquerungs- und Ray-Grundelement-Kreuzungen, wodurch verhindert wird, dass die Grafikkerne 3130 mit Tausenden von Anweisungen pro Ray überladen werden. In einer Ausführungsform beinhaltet jeder Raytracing-Kern 3150 einen ersten Satz von spezialisierten Schaltungen zum Ausführen von Bounding-Box-Tests (zum Beispiel für Durchquerungsoperationen) und einen zweiten Satz von spezialisierten Schaltungen zum Ausführen der Ray-Dreieck-Kreuzungsprüfungen (zum Beispiel kreuzende Rays, die durchquert worden sind). Somit kann in einer Ausführungsform die Multikerngruppe 3100A einfach eine Ray-Sondierung starten, und die Raytracing-Kerne 3150 führen unabhängig eine Ray-Durchquerung und -Kreuzung aus und geben Trefferdaten (zum Beispiel einen Treffer, keinen Treffer, mehrfache Treffer, usw.) an den Thread-Kontext zurück. Die anderen Kerne 3130, 3140 werden zur Ausführung anderer Grafik- oder Rechenarbeit freigegeben, während die Raytracing-Kerne 3150 die Durchquerungs- und Kreuzungsoperationen ausführen.
In einer Ausführungsform beinhaltet jeder Raytracing-Kern 3150 eine Durchquerungseinheit zum Ausführen von BVH-Prüfungsoperationen und eine Kreuzungseinheit, die Ray-Grundelement-Kreuzungsprüfungen ausführt. Die Kreuzungseinheit erzeugt eine Antwort „Treffer“, „Kein Treffer“ oder „Mehrfacher Treffer“, die sie dem geeigneten Thread bereitstellt. Während der Durchquerungs- und Kreuzungsoperationen werden die Ausführungsressourcen der anderen Kerne (zum Beispiel der Grafikkerne 3130 und der Tensorkerne 3140) freigegeben, um andere Formen von Grafikarbeit auszuführen.
In einer bestimmten unten beschriebenen Ausführungsform wird ein hybrider Ansatz für Rasterung/Raytracing verwendet, bei dem die Arbeit zwischen den Grafikkernen 3130 und den Raytracing-Kernen 3150 verteilt wird.
In einer Ausführungsform beinhalten die Raytracing-Kerne 3150 (und/oder die anderen Kerne 3130, 3140) eine Hardware-Unterstützung für einen Raytracing-Anweisungssatz, wie zum Beispiel Microsoft DirectX-RayTracing (DXR), der einen DispatchRays-Befehl sowie Ray-Erzeugung, nächstgelegener Treffer, jeglicher Treffer und Shader verfehlt, die die Zuordnung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglichen, beinhaltet. Eine andere Raytracing-Plattform, die durch die Raytracing-Kerne 3150, Grafikkerne 3130 und Tensorkerne 3140 unterstützt werden kann, ist Vulkan 1.1.85. Es ist jedoch zu beachten, dass die der Erfindung zugrunde liegenden Prinzipien nicht auf eine bestimmte Raytracing-ISA beschränkt sind.
Im Allgemeinen können die verschiedenen Kerne 3150, 3140, 3130 einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen zur Ray-Erzeugung, zu nächstgelegenem Treffer, jeglichem Treffer, zu einer Ray-Grundelement-Kreuzung, zu pro-Grundelement- und hierarchischen Bounding-Box-Aufbau, verfehlen, besuchen und Ausnahmen beinhaltet. Insbesondere beinhaltet eine Ausführungsform Raytracing-Anweisungen, um die folgenden Funktionen auszuführen:
Ray-Erzeugung - Ray-Erzeugungsanweisungen können für jedes Pixel, jede Abtastung oder jede andere benutzerdefinierte Arbeitszuordnung ausgeführt werden.
Nächstgelegener Treffer - Eine nächstgelegener-Treffer-Anweisung kann ausgeführt werden, um den nächstgelegenen Kreuzungspunkt eines Rays mit Grundelementen innerhalb einer Szene zu lokalisieren.
Jeglicher Treffer - Eine jeglicher-Treffer-Anweisung identifiziert mehrere Kreuzungen zwischen einem Ray und Grundelementen innerhalb einer Szene, um potenziell einen neuen nächstgelegenen Kreuzungspunkt zu identifizieren.
Kreuzung - Eine Kreuzungsanweisung führt eine Ray-Grundelement-Kreuzungsprüfung aus und gibt ein Ergebnis aus.
Pro-Grundelement-Bounding-Box-Aufbau - Diese Anweisung errichtet eine Bounding-Box rund um ein gegebenes Grundelement oder eine Gruppe von Grundelementen (zum Beispiel beim Aufbauen einer neuen BVH oder anderen Beschleunigungsdatenstruktur).
Verfehlen - Gibt an, dass ein Ray die gesamte Geometrie innerhalb einer Szene oder eines spezifizierten Bereichs einer Szene verfehlt.
Besuchen - Zeigt die Child-Volumina an, die ein Ray durchqueren wird.
Ausnahmen - Beinhaltet verschiedene Typen von Ausnahmebehandlern (zum Beispiel aufgerufen für verschiedene Fehlerbedingungen).
HIERARCHISCHES BEAMTRACING
Hüllvolumenhierarchien werden üblicherweise verwendet, um die Effizienz zu verbessern, mit der Operationen an Grafikgrundelementen und anderen Grafikobjekten ausgeführt werden. Eine BVH ist eine hierarchische Baumstruktur, die basierend auf einem Satz von geometrischen Objekten aufgebaut ist. An der Spitze der Baumstruktur ist der Wurzelknoten, der alle geometrischen Objekte in einer gegebenen Szene umschließt. Die einzelnen geometrischen Objekte werden in Hüllvolumina verpackt, die die Blattknoten des Baums bilden. Diese Knoten werden dann als kleine Sätze gruppiert und innerhalb größerer Hüllvolumina umschlossen. Diese wiederum werden in rekursiver Art gruppiert und innerhalb anderer größerer Hüllvolumina umschlossen, was schließlich in einer Baumstruktur mit einem einzelnen Hüllvolumen, das durch den Wurzelknoten an der Spitze des Baums dargestellt wird, resultiert. Hüllvolumenhierarchien werden verwendet, um eine Vielzahl von Operationen an Sätzen von geometrischen Objekten effizient zu unterstützen, wie zum Beispiel Kollisionserkennung, Grundelement-Culling und Ray-Durchquerungs-/Kreuzungsoperationen, die bei Raytracing verwendet werden.
In Raytracing-Architekturen werden Rays quer durch eine BVH geleitet, um Ray-Grundelement-Kreuzungen zu bestimmen. Wenn zum Beispiel ein Ray nicht durch den Wurzelknoten der BVH läuft, dann kreuzt der Ray keines der durch die BVH umschlossenen Grundelemente, und es ist keine weitere Verarbeitung für den Ray in Bezug auf diesen Satz von Grundelementen erforderlich. Wenn ein Ray durch einen ersten Child-Knoten der BVH, aber nicht durch den zweiten Child-Knoten läuft, dann muss der Ray nicht gegen jegliche durch den zweiten Child-Knoten umschlossenen Grundelemente geprüft werden. Auf diese Weise stellt eine BVH einen effizienten Mechanismus zum Prüfen auf Ray-Grundelement-Kreuzungen bereit.
In einer Ausführungsform der Erfindung werden Gruppen von zusammenhängenden Rays, die als „Beams“ bezeichnet werden, gegen die BVH anstatt gegen einzelne Rays geprüft. 32 zeigt beispielhaften Beam 3201, der durch vier unterschiedliche Rays umschrieben ist. Jegliche Rays, die durch die vier Rays definiertes Feld 3200 kreuzen, werden als innerhalb desselben Beam liegend betrachtet. Während der Beam 3201 in 32 durch eine rechteckige Anordnung von Rays definiert ist, können Beams auf verschiedene andere Arten definiert werden, während immer noch die zugrunde liegenden Prinzipien der Erfindung (zum Beispiel Kreise, Ellipsen, usw.) eingehalten werden.
33 veranschaulicht eine beispielhafte Ausführungsform, in der Raytracing-Engine 3310 von GPU 3320 die hierin beschriebenen Beamtracing-Techniken implementiert. Insbesondere erzeugt die Ray-Erzeugungsschaltung 3304 mehrere Rays, für die Durchquerungs- und Kreuzungsoperationen ausgeführt werden sollen. Anstatt jedoch Durchquerungs- und Kreuzungsoperationen an einzelnen Rays auszuführen, führt die veranschaulichte Ausführungsform Durchquerungs- und Kreuzungsoperationen durch Verwenden einer Hierarchie von Beams 3307 aus, die durch Beam-Hierarchieerrichtungsschaltung 3305 erzeugt wird. In einer Ausführungsform ist die Beam-Hierarchie analog zu der Hüllvolumenhierarchie (BVH). Zum Beispiel stellt 34 ein Beispiel von primärem Beam 3400 bereit, der in mehrere unterschiedliche Komponenten unterteilt sein kann. Insbesondere kann der primäre Beam 3400 in Quadranten 3401-3404 unterteilt werden, und jeder Quadrant kann selbst in Unterquadranten, wie zum Beispiel die Unterquadranten A-D, innerhalb des Quadranten 3404 unterteilt werden. Der primäre Beam kann auf eine Vielzahl von Arten unterteilt werden. Zum Beispiel kann in einer Ausführungsform der primäre Beam in Hälften (anstelle von Quadranten) unterteilt werden, und jede Hälfte kann in Hälften geteilt werden, und so weiter. Unabhängig davon, wie die Unterteilungen vorgenommen werden, wird in einer Ausführungsform eine hierarchische Struktur auf eine ähnliche Weise wie eine BVH erzeugt, zum Beispiel mit einem Wurzelknoten, der den primären Beam 3400 darstellt, einer ersten Ebene von Child-Knoten, die jeweils durch einen Quadranten 3401-3404 dargestellt werden, Child-Knoten der zweiten Ebene für jeden Unterquadranten A-D, und so weiter.
In einer Ausführungsform führt Durchquerungs-/Kreuzungsschaltung 3306, sobald die Beam-Hierarchie 3307 aufgebaut ist, Durchquerungs-/Kreuzungsoperationen durch Verwenden der Beam-Hierarchie 3307 und von BVH 3308 aus. Insbesondere kann sie den Beam gegen die BVH prüfen und Abschnitte des Beams cullen, die keinerlei Abschnitte der BVH kreuzen. Durch Verwenden der in 34 gezeigten Daten können zum Beispiel, wenn sich die Sub-Beams, die Unterbereichen 3402 und 3403 zugeordnet sind, nicht mit der BVH oder einem bestimmten Zweig der BVH kreuzen, sie in Bezug auf die BVH oder den Zweig gecullt werden. Verbleibende Abschnitte 3401, 3404 können gegen die BVH geprüft werden, indem eine Tiefensuche oder ein anderer Suchalgorithmus ausgeführt wird.
Ein Verfahren gemäß einer Ausführungsform der Erfindung wird in 35 veranschaulicht. Das Verfahren kann innerhalb des Kontext der oben beschriebenen Grafikverarbeitungsarchitekturen implementiert werden, ist jedoch nicht auf jegliche bestimmte Architektur beschränkt.
Bei 3500 wird ein mehrere Rays umfassender primärer Beam aufgebaut, und bei 3501 wird der Beam unterteilt und hierarchische Datenstrukturen werden erzeugt, um eine Beam-Hierarchie zu erzeugen. In einer Ausführungsform werden die Operationen 3500-3501 als eine einzige integrierte Operation ausgeführt, die eine Beam-Hierarchie von mehreren Rays aufbaut. Bei 3502 wird die Beam-Hierarchie mit einer BVH verwendet, um Rays (von der Beam-Hierarchie) und/oder Knoten/Grundelemente von der BVH zu cullen. Bei 3503 werden Ray-Grundelement-Kreuzungen für die verbleibenden Rays und Grundelemente bestimmt.
VERLUSTBEHAFTETE UND VERLUSTFREIE PAKETKOMPRIMIERUNG IN EINEM VERTEILTEN RAYTRACING-SYSTEM
In einer Ausführungsform sind Raytracing-Operationen über mehrere über ein Netzwerk gekoppelte Rechenknoten hinweg verteilt. 36 veranschaulicht zum Beispiel Raytracing-Cluster 3600, das mehrere Raytracing-Knoten 3610-3613 umfasst, die Raytracing-Operationen parallel ausführen und potenziell die Ergebnisse an einem der Knoten kombinieren. In der veranschaulichten Architektur sind die Raytracing-Knoten 3610-3613 über ein Portal kommunikativ mit Client-seitiger Raytracing-Anwendung 3630 gekoppelt.
Eine der Schwierigkeiten bei einer verteilten Architektur ist die große Menge paketierter Daten, die zwischen jedem der Raytracing-Knoten 3610-3613 übertragen werden müssen. In einer Ausführungsform werden sowohl verlustfreie Komprimierungstechniken als auch verlustbehaftete Komprimierungstechniken verwendet, um die zwischen den Raytracing-Knoten 3610-3613 übertragenen Daten zu reduzieren.
Um verlustfreie Komprimierung zu implementieren, anstatt mit den Ergebnissen bestimmter Typen von Operationen gefüllte Pakete zu senden, werden Daten oder Befehle gesendet, die es dem empfangenden Knoten ermöglichen, die Ergebnisse zu rekonstruieren. Zum Beispiel benötigen stochastisch abgetastete Flächenlichter und Umgebungsokklusions (Ambient-Occlusion - AO) -Operationen nicht notwendigerweise Weisungen. Infolgedessen sendet in einer Ausführungsform ein übertragender Knoten einfach einen Zufallsausgangswert, der dann durch den empfangenden Knoten verwendet wird, um Zufallsabtastung auszuführen. Wenn zum Beispiel eine Szene über die Knoten 3610-3612 hinweg verteilt ist, um Licht 1 an den Punkten p1-p3 abzutasten, müssen nur die Licht-ID und Ursprünge an die Knoten 3610-3612 gesendet werden. Jeder der Knoten kann dann selbstständig das Licht stochastisch abtasten. In einer Ausführungsform wird der Zufallsausgangswert durch den empfangenden Knoten erzeugt. In ähnlicher Weise können für Primär-Ray-Trefferpunkte Umgebungsokklusion (AO) und weiche Shadow-Abtastung auf den Knoten 3610-3612 berechnet werden, ohne auf die ursprünglichen Punkte für aufeinanderfolgende Frames zu warten. Zusätzlich können, wenn es bekannt ist, dass ein Satz von Rays zur selben Punktlichtquelle geht, Anweisungen gesendet werden, die die Lichtquelle an den empfangenden Knoten identifizieren, der sie auf den Satz von Rays anwendet. Als ein anderes Beispiel kann, wenn N Umgebungsokklusions-Rays an einem einzelnen Punkt übertragen werden, ein Befehl gesendet werden, um N Abtastwerte von diesem Punkt zu erzeugen.
Verschiedene zusätzliche Techniken können zur verlustbehafteten Komprimierung angewendet werden. Zum Beispiel kann in einer Ausführungsform ein Quantisierungsfaktor eingesetzt werden, um alle Koordinatenwerte zu quantisieren, die der BVH, den Grundelementen und Rays zugeordnet sind. Zusätzlich können 32-Bit-Gleitkommawerte, die für Daten, wie zum Beispiel BVH-Knoten und Grundelemente, verwendet werden, in 8-Bit-Ganzzahlwerte konvertiert werden. In einer bestimmten Implementierung werden die Rahmen von Ray-Paketen in voller Genauigkeit gespeichert, aber einzelne Ray-Punkte P1-P3 werden als indexierte Versatze zu den Grenzen übertragen. In ähnlicher Weise können mehrere lokale Koordinatensysteme erzeugt werden, die 8-Bit-Ganzzahlwerte als lokale Koordinaten verwenden. Der Ort des Ursprungs jedes dieser lokalen Koordinatensysteme kann durch Verwenden der vollen Genauigkeits (zum Beispiel 32-Bit-Gleitkomma) -Werte codiert werden, wodurch das globale und das lokale Koordinatensystem effektiv verbunden werden.
Das Folgende ist ein Beispiel für verlustfreie Komprimierung, die in einer Ausführungsform der Erfindung eingesetzt wird. Ein Beispiel für ein Ray-Datenformat, das intern in einem Raytracing-Programm verwendet wird, ist wie folgt:

     struct Ray
     { 
       uint32 pixid;
       uint32 materialID;
       uint32 instanceID;
       uint64 primitiveID;
       uint32 geometryID;
       uint32 lightID;
       float origin[3];
       float direction[3];
       float t0; 





       float t;
       float time;
       float normal[3]; //used for geometry intersections
       float u;
       float v;

float wavelength;
       float phase; //Interferometry
       float refractedOffset; //Schlieren-esque
       float amplitude;
       float weight;

      };

Anstatt die Rohdaten für jeden erzeugten Knoten zu senden, können diese Daten komprimiert werden, indem Werte gruppiert werden, und wo möglich implizite Rays durch Verwenden geeigneter Metadaten erstellt werden.

Bündeln und Gruppieren von Ray-Daten Eine Ausführungsform verwendet Flags für gemeinsame Daten oder Masken mit Modifikatoren.

     struct RayPacket
     {
       uint32 size;
       uint32 flags;

       list<Ray> rays;
     }

Zum Beispiel:

RayPacket. rays = ray_1 to ray_256

Ursprünge werden alle geteilt

Alle Ray-Daten werden gepackt, außer, dass nur ein einziger Ursprung über alle Rays hinweg gespeichert wird. RayPacket.flags wird eingestellt für RAYPACKET_COMMON_ORIGIN. Wenn RayPacket beim Empfang entpackt wird, werden die Ursprünge von dem einzelnen Ursprungswert eingefüllt.

Ursprünge werden nur zwischen einigen Rays geteilt

Alle Ray-Daten werden gepackt, außer für Rays, die Ursprünge teilen. Für jede Gruppe eindeutiger geteilter Ursprünge ist ein Operator aufgepackt, der die Operation identifiziert (geteilte Ursprünge), den Ursprung speichert, und maskiert, welche Rays die Informationen teilen. Eine solche Operation kann an jeglichen geteilten Werten zwischen Knoten, wie zum Beispiel Material-ID, Grundelement-ID, Ursprung, Richtung, Normalen, usw., gemacht werden.

     struct RayOperation

      {

       uint8 operationID;
       void* value;

       uint64 mask;
      }

Implizite Rays senden

Oft können Ray-Daten an dem empfangenden Ende mit minimalen Metainformationen, die verwendet werden, um sie zu erzeugen, abgeleitet werden. Ein sehr übliches Beispiel ist die Erzeugung mehrerer Sekundär-Rays, um einen Bereich stochastisch abzutasten. Anstatt dass der Absender einen Sekundär-Ray erzeugt, sendet und der Empfänger darauf arbeitet, kann der Absender einen Befehl senden, dass ein Ray mit jeglichen abhängigen Informationen erzeugt werden muss, und der Ray wird an dem empfangenden Ende erzeugt. In dem Fall, in dem der Ray zuerst durch den Absender erzeugt werden muss, um zu bestimmen, an welchen Empfänger er gesendet werden soll, wird der Ray erzeugt, und der Zufallsausgangswert kann gesendet werden, um den exakt gleichen Ray neu zu erzeugen.

Um zum Beispiel einen Trefferpunkt mit 64 Shadow-Rays abzutasten, die eine Flächenlichtquelle abtasten, kreuzen sich alle 64 Rays mit Bereichen von derselben Berechnung N4. Ein RayPacket mit herkömmlichem Ursprung und Normal wird erzeugt. Es könnten mehr Daten gesendet werden, wenn der Empfänger für den resultierenden Pixelbeitrag Shading ausführen möchte, aber für dieses Beispiel soll angenommen werden, es soll nur zurückgegeben werden, ob ein Ray Daten eines anderen Knotens trifft. Eine RayOperation wird für eine Operation zum Erzeugen von Shadow-Rays erzeugt und dem Wert der abzutastenden Licht-ID und dem Zufallszahlenausgangswert zugewiesen. Wenn N4 das Ray-Paket empfängt, erzeugt es die vollständig gefüllten Ray-Daten, indem es die geteilten Ursprungsdaten zu allen Rays einfüllt und die Richtung basierend auf der stochastisch mit dem Zufallszahlenausgangswert abgetasteten Licht-ID einstellt, um die gleichen Rays zu erzeugen, die der ursprüngliche Absender erzeugt hat. Wenn die Ergebnisse zurückgegeben werden, müssen nur binäre Ergebnisse für jeden Ray zurückgegeben werden, die durch eine Maske über die Rays überreicht werden können.

Senden der ursprünglichen 64 Rays in diesem Beispiel hätte 104 Bytes * 64 Rays = 6656 Bytes verwendet. Wenn die zurückkommenden Rays auch in ihrer Rohform gesendet wurden, wird dies auch auf 13312 Bytes verdoppelt. Durch Verwenden verlustfreier Komprimierung, bei der nur der herkömmliche Ray-Ursprung, das Normal und die Ray-Erzeugungsoperation mit Ausgangswert und ID gesendet werden, werden nur 29 Bytes gesendet, wobei 8 Bytes für die gekreuzte Maske zurückgegeben werden. Dies führt zu einer Datenkomprimierungsrate, die über das Netzwerk gesendet werden soll, von ~360:1. Dies beinhaltet nicht den Mehraufwand für die Verarbeitung der Nachricht selbst, der auf irgendeine Weise identifiziert werden müsste, sondern dies bleibt der Implementierung überlassen. Andere Operationen können durchgeführt werden, um den Ray-Ursprung und die Richtungen von der Pixel-ID für primäre Rays neu zu berechnen, Pixel-ID basierend auf den Bereichen in dem Ray-Paket neu zu berechnen, und viele andere mögliche Implementierungen, um Werte neu zu berechnen. Ähnliche Operationen können für einzelne oder Gruppen von gesendeten Rays verwendet werden, einschließlich Shadows, Reflexionen, Brechung, Umgebungsokklusion, Kreuzungen, Volumenschnittpunkte, Shading, abgeprallte Reflexionen beim Path-Tracing, usw.

37 veranschaulicht zusätzliche Details für zwei Raytracing-Knoten 3710-3711, die eine Komprimierung und Dekomprimierung von Raytracing-Paketen ausführen. Insbesondere in einer Ausführungsform, wenn erste Raytracing-Engine 3730 bereit ist, Daten an zweite Raytracing-Engine 3731 zu übertragen, führt Ray-Komprimierungsschaltung 3720 verlustbehaftete und/oder verlustfreie Komprimierung der Raytracing-Daten wie hierin beschrieben aus (zum Beispiel Konvertieren von 32-Bit-Werten zu 8-Bit-Werten, Ersetzen von Rohdaten für Anweisungen, um Daten zu rekonstruieren, usw.). Komprimierte Ray-Pakete 3701 werden von Netzwerkschnittstelle 3725 zu Netzwerkschnittstelle 3726 über ein lokales Netzwerk (zum Beispiel ein Ethernet-Netzwerk mit 10 Gbit/s, 100 Gbit/s) übertragen. Die Ray-Dekomprimierungsschaltung dekomprimiert dann die Ray-Pakete, wenn geeignet. Zum Beispiel kann sie Befehle ausführen, um die Raytracing-Daten zu rekonstruieren (zum Beispiel durch Verwenden eines Zufallsausgangswerts, um Zufallsabtastung für Beleuchtungsoperationen auszuführen). Die Raytracing-Engine 3731 verwendet dann die empfangenen Daten, um Raytracing-Operationen auszuführen.

In der umgekehrten Richtung komprimiert Ray-Komprimierungsschaltung 3741 Ray-Daten, die Netzwerkschnittstelle 3726 überträgt die komprimierten Ray-Daten über das Netzwerk (zum Beispiel durch Verwenden der hierin beschriebenen Techniken), Ray-Dekomprimierungsschaltung 3740 dekomprimiert die Ray-Daten, wenn erforderlich, und die Raytracing-Engine 3730 verwendet die Daten in Raytracing-Operationen. Obwohl in 37 als separate Einheit veranschaulicht, können die Ray-Dekomprimierungsschaltungen 3740-3741 jeweils in die Raytracing-Engines 3730-3731 integriert sein. Zum Beispiel können, sofern die komprimierten Ray-Daten Befehle zum Rekonstruieren der Ray-Daten umfassen, diese Befehle durch jede jeweilige Raytracing-Engine 3730-3731 ausgeführt werden.

Wie in 38 veranschaulicht, kann die Ray-Komprimierungsschaltung 3720 verlustbehaftete Komprimierungsschaltung 3801 zum Ausführen der hierin beschriebenen verlustbehafteten Komprimierungstechniken (zum Beispiel Konvertieren von 32-Bit-Gleitkommakoordinaten zu 8-Bit-Ganzzahlkoordinaten) und verlustfreie Komprimierungsschaltung 3803 zum Ausführen der verlustfreien Komprimierungstechniken (zum Beispiel Übertragen von Befehlen und Daten, damit die Ray-Dekomprimierungsschaltung 3821 die Daten rekonstruieren kann) beinhalten. Die Ray-Dekomprimierungsschaltung 3721 beinhaltet verlustbehaftete Dekomprimierungsschaltung 3802 und verlustfreie Dekomprimierungsschaltung 3804 zum Ausführen von verlustfreier Dekomprimierung.

Ein Verfahren gemäß einer Ausführungsform wird in 39 veranschaulicht. Das Verfahren kann auf den hierin beschriebenen Raytracing-Architekturen implementiert werden, ist jedoch nicht auf jegliche bestimmte Architektur beschränkt.

Bei 3900 werden Ray-Daten empfangen, die von einem ersten Raytracing-Knoten zu einem zweiten Raytracing-Knoten übertragen werden. Bei 3901 führt verlustbehaftete Komprimierungsschaltung verlustbehaftete Komprimierung an ersten Raytracing-Daten aus, und bei 3902 führt verlustfreie Komprimierungsschaltung verlustfreie Komprimierung an zweiten Raytracing-Daten aus. Bei 3903 werden die komprimierten Raytracing-Daten zu einem zweiten Raytracing-Knoten übertragen. Bei 3904 führt verlustbehaftete/verlustfreie Dekomprimierungsschaltung verlustbehaftete/verlustfreie Dekomprimierung der Raytracing-Daten aus, und bei 3905 führt der zweite Raytracing-Knoten Raytracing-Operationen durch Verwenden der dekomprimierten Daten aus.

GRAFIKPROZESSOR MIT HARDWARE-BESCHLEUNIGTEM HYBRID-RAYTRACING

Eine Ausführungsform der Erfindung beinhaltet eine Hybrid-Rendering-Pipeline, die eine Rasterung an den Grafikkernen 3130 und Raytracing-Operationen an den Raytracing-Kernen 3150, den Grafikkernen 3130 und/oder den CPU-Kernen 3199 ausführt. Zum Beispiel können Rasterungs- und Tiefenprüfungen an den Grafikkernen 3130 anstelle der primären Ray-Casting-Stufe ausgeführt werden. Die Raytracing-Kerne 3150 können dann sekundäre Rays für Ray-Reflexionen, Brechungen und Shadows erzeugen. Zusätzlich können bestimmte Ausführungsformen bestimmte Bereiche einer Szene auswählen, in denen die Raytracing-Kerne 3150 Raytracing-Operationen ausführen (zum Beispiel basierend auf Materialeigenschaftsschwellenwerten, wie zum Beispiel hohen Reflexionsgraden), während andere Bereiche der Szene mit Rasterung auf den Grafikkernen 3130 gerendert werden. In einer Ausführungsform wird diese Hybridimplementierung für Echtzeit-Raytracing-Anwendungen - wo Latenz ein kritisches Problem ist - verwendet.

Eine Ausführungsform der unten beschriebenen Ray-Durchquerungsarchitekturen führt programmierbares Shading und Steuerung der Ray-Durchquerung durch Verwenden vorhandener Single-Instruction-Multiple-Data (SIMD) und/oder Single-Instruction-Multiple-Thread (SIMT) -Grafikprozessoren aus, während kritische Funktionen, wie zum Beispiel BVH-Durchquerung und/oder Kreuzungen durch Verwenden fest zugeordneter Hardware beschleunigt werden. In dieser Ausführungsform wird die SIMD-Belegung für inkohärente Pfade verbessert, indem hervorgebrachte Shader an spezifischen Punkten während des Durchquerens und vor dem Shading neu gruppiert werden. Dies wird mit fest zugeordneter Hardware erreicht, die Shader dynamisch auf dem Chip sortiert. Die Rekursion wird verwaltet, indem eine Funktion in Fortsetzungen aufgeteilt wird, die beim Zurückgeben ausgeführt werden, und Fortsetzungen vor der Ausführung für verbesserte SIMD-Belegung neu gruppiert werden.

Programmierbare Steuerung der Ray-Durchquerung/-Kreuzung wird erreicht, indem die Durchquerung in eine innere Durchquerung, die als Festfunktions-Hardware implementiert werden kann, und eine äußere Durchquerung, die auf GPU-Prozessoren ausgeführt wird und eine programmierbare Steuerung durch benutzerdefinierte Durchquerungs-Shader ermöglicht, zerlegt wird. Die Kosten für Übertragung des Durchquerungskontexts zwischen Hardware und Software werden reduziert, indem der innere Durchquerungsstatus während des Übergangs zwischen innerer und äußerer Durchquerung konservativ abgeschnitten wird.

Programmierbare Steuerung von Raytracing kann durch die verschiedenen in Tabelle A unten aufgelisteten Shader-Typen ausgedrückt werden. Es können mehrere Shader für jeden Typ vorhanden sein. Zum Beispiel kann jedes Material einen unterschiedlichen Treffer-Shader haben. TABELLE A

Shader-Typ	Funktionalität
Primär	Primäre Rays starten
Treffer	Bidirectional-Reflectance-Distribution-Function (BRDF) -Abtastung, die sekundäre Rays startet
Jeglicher Treffer	Berechnungsdurchlässigkeit für alpha-strukturierte Geometrie
Verfehlung	Berechnen der Strahlung von einer Lichtquelle
Kreuzung	Sich kreuzende benutzerdefinierte Formen
Durchquerung	Instanzauswahl und -Transformation
Aufrufbar	Eine Mehrzweckfunktion

In einer Ausführungsform wird rekursives Raytracing durch eine API-Funktion initiiert, die dem Grafikprozessor befiehlt, einen Satz von primären Shadern oder Kreuzungsschaltungen zu starten, die Ray-Szenen-Kreuzungen für primäre Rays hervorbringen können. Dies wiederum erzeugt andere Shader wie Durchquerungs-, Treffer-Shader oder Verfehlungs-Shader. Ein Shader, der einen Child-Shader hervorbringt, kann auch einen Rückgabewert von diesem Child-Shader empfangen. Aufrufbare Shader sind Mehrzweckfunktionen, die direkt durch einen anderen Shader hervorgebracht werden können und auch Werte an den aufrufenden Shader zurückgeben können.

40 veranschaulicht eine Ausführungsform einer Grafikverarbeitungsarchitektur, die Shader-Ausführungsschaltung 4000 und Festfunktionsschaltung 4010 beinhaltet. Das Mehrzweckausführungs-Hardware-Subsystem beinhaltet mehrere Single-Instruction-Multiple-Data (SIMD) und/oder Single-Instruction-Multiple-Threads (SIMT) - Kerne/Ausführungseinheiten (EU) 4001 (das heißt jeder Kern kann mehrere Ausführungseinheiten umfassen), einen oder mehrere Sampler 4002 und Level 1 (L1) -Cache 4003 oder eine andere Form von lokalem Speicher. Das Festfunktions-Hardware-Subsystem 4010 beinhaltet Nachrichteneinheit 4004, Planer 4007, Ray-BVH-Durchquerungs-/Kreuzungsschaltung 4005, Sortierungsschaltung 4008 und lokalen L1-Cache 4006.

In Betrieb sendet primärer Dispatcher 4009 einen Satz primärer Rays an den Planer 4007, der die Arbeit an Shader plant, die auf den SIMD/SIMT-Kernen/EU 4001 ausgeführt werden. Die SIMD-Kerne/EU 4001 können die oben beschriebenen Raytracing-Kerne 3150 und/oder Grafikkerne 3130 sein. Ausführung der primären Shader bringt zusätzliche Arbeit hervor, die ausgeführt werden soll (zum Beispiel durch einen oder mehreren Child-Shader und/oder Festfunktions-Hardware ausgeführt werden soll). Die Nachrichteneinheit 4004 verteilt die durch die SIMD-Kerne/EU 4001 hervorgebrachte Arbeit an den Planer 4007 und greift nach Bedarf auf den freien Stapelpool, die Sortierungsschaltung 4008 oder die Ray-BVH-Kreuzungsschaltung 4005 zu. Wenn die zusätzliche Arbeit an den Planer 4007 gesendet wird, ist sie für die Verarbeitung auf den SIMD/SIMT-Kernen/EU 4001 geplant. Vor dem Planen kann die Sortierungsschaltung 4008 die Rays in Gruppen oder Behälter sortieren, wie hierin beschrieben (zum Beispiel Rays mit ähnlichen Eigenschaften gruppieren). Die Ray-BVH-Kreuzungsschaltung 4005 führt eine Kreuzungsprüfung von Rays durch Verwenden von BVH-Volumina durch. Zum Beispiel kann die Ray-BVH-Kreuzungsschaltung 4005 Ray-Koordinaten mit jeder Ebene der BVH vergleichen, um Volumina zu identifizieren, die durch den Ray gekreuzt werden.

Auf Shader kann durch Verwenden einer Shader-Aufnahme verwiesen werden, einer benutzerzugewiesenen Struktur, die einen Zeiger auf die Eingabefunktion, herstellerspezifische Metadaten und globale Argumente für den Shader beinhaltet, die durch die SIMD-Kerne/EU 4001 ausgeführt werden. Jede ausführende Instanz eines Shaders ist einem Aufrufstapel zugeordnet, der zum Speichern von Argumenten verwendet werden kann, die zwischen einem Parent-Shader und einem Child-Shader weitergegeben werden. Aufrufstapel können auch Verweise auf die Fortsetzungsfunktionen speichern, die ausgeführt werden, wenn ein Aufruf zurückkommt.

41 veranschaulicht einen beispielhaften Satz zugewiesener Stapel 4101, der einen primären Shader-Stapel, einen Treffer-Shader-Stapel, einen Durchquerungs-Shader-Stapel, einen Fortsetzungsfunktionsstapel und einen Ray-BVH-Kreuzungsstapel (der, wie beschrieben, durch die Festfunktionshardware 4010 ausgeführt werden kann) beinhaltet. Neue Shader-Aufrufe können neue Stapel von freiem Stapelpool 4102 implementieren. Die Aufrufstapel können in einem lokalen L1-Cache 4003, 4006 zwischengespeichert werden, um die Latenz von Zugriffen zu reduzieren.

In einer Ausführungsform gibt es eine begrenzte Anzahl von Aufrufstapeln, von denen jeder eine feste maximale Größe „SStapel“ hat, die in einem zusammenhängenden Speicherbereich zugewiesen sind. Daher kann die Basisadresse eines Stapels direkt von einem Stapelindex (SID) als Basisadresse = SID * SStapel berechnet werden. In einer Ausführungsform werden Stapel-ID durch den Planer 4007 zugewiesen und freigegeben, wenn Arbeit an den SIMD-Kernen/EU 4001 geplant wird.

In einer Ausführungsform umfasst der primäre Dispatcher 4009 einen Grafikprozessor-Befehlsprozessor, der primäre Shader als Reaktion auf einen Versendebefehl von dem Host (zum Beispiel einer CPU) versendet. Der Planer 4007 empfängt diese Versendeanforderungen und startet einen primären Shader auf einem SIMD-Prozessor-Thread, wenn er eine Stapel-ID für jede SIMD-Spur zuweisen kann. Stapel-ID werden von dem freien Stapelpool 4102 zugewiesen, der zu Beginn des Versendebefehls initialisiert wird.

Ein ausführender Shader kann einen Child-Shader durch Senden einer Spawn-Nachricht an die Nachrichteneinheit 4004 hervorbringen. Dieser Befehl beinhaltet die dem Shader zugeordneten Stack-ID, und beinhaltet auch einen Zeiger auf die Child-Shader-Aufnahme für jede aktive SIMD-Spur. Ein Parent-Shader kann diese Nachricht für eine aktive Spur nur einmal ausgeben. In einer Ausführungsform wird der Parent-Shader nach dem Senden von Spawn-Nachrichten für alle relevanten Spuren beendet.

Ein auf den SIMD-Kernen/EU 4001 ausgeführter Shader kann auch Festfunktionsaufgaben, wie zum Beispiel Ray-BVH-Kreuzungen, durch Verwenden einer Spawn-Nachricht mit einem für die Festfunktions-Hardware reservierten Shader-Aufnahmezeiger hervorbringen. Wie erwähnt, sendet die Nachrichtenübermittlungseinheit 4004 hervorgebrachte Ray-BVH-Kreuzungsarbeit an die Ray-BVH-Festfunktions-Kreuzungsschaltung 4005 und aufrufbare Shader direkt an die Sortierungsschaltung 4008. In einer Ausführungsform gruppiert die Sortierungsschaltung die Shader nach Shader-Aufnahmezeiger, um einen SIMD-Batch mit ähnlichen Eigenschaften abzuleiten. Dementsprechend können Stapel-ID von unterschiedlichen Parent-Shadern durch die Sortierungsschaltung 4008 in demselben Batch gruppiert werden. Die Sortierungsschaltung 4008 sendet gruppierte Batches an den Planer 4007, der auf die Shader-Aufnahme von dem Grafikspeicher 2511 oder dem Last-Level-Cache (LLC) 4020 zugreift und den Shader auf einem Prozessor-Thread startet.

In einer Ausführungsform werden Fortsetzungen als aufrufbare Shader behandelt und können auch durch Shader-Aufnahmen referenziert werden. Wenn ein Child-Shader erzeugt wird und Werte an den Parent-Shader zurückgibt, wird ein Zeiger auf die Fortsetzungs-Shader-Aufnahme auf den Aufrufstapel 4101 geschoben. Wenn ein Child-Shader zurückkehrt, wird die Fortsetzungs-Shader-Aufnahme von dem Aufrufstapel 4101 abgerufen und ein Fortsetzungs-Shader wird hervorgebracht. Hervorgebrachte Fortsetzungen durchlaufen die Sortierungseinheit ähnlich wie aufrufbare Shader und werden auf einem Prozessor-Thread gestartet.

Wie in 42 veranschaulicht, gruppiert eine Ausführungsform der Sortierungsschaltung 4008 hervorgebrachte Aufgaben durch Shader-Aufnahmezeiger 4201A, 4201B, 4201n, um SIMD-Batches für Shading zu erzeugen. Die Stapel-ID oder Kontext-ID in einem sortierten Batch können von unterschiedlichen Versendungen und unterschiedlichen Eingabe-SIMD-Spuren gruppiert werden. In einer Ausführungsform führt Gruppierungsschaltung 4210 das Sortieren durch Verwenden von Content-Addressable-Memory (CAM) -Struktur 4201 aus, die mehrere Einträge umfasst, wobei jeder Eintrag mit Tag 4201 identifiziert ist. Wie erwähnt, ist in einer Ausführungsform das Tag 4201 ein entsprechender Shader-Aufnahmezeiger 4201A, 4201B, 4201n. In einer Ausführungsform speichert die CAM-Struktur 4201 eine begrenzte Anzahl von Tags (zum Beispiel 32, 64, 128, usw.), die jedes einem unvollständigen SIMD-Batch, der einem Shader-Aufnahmezeiger entspricht, zugeordnet sind.

Für einen eingehenden Spawn-Befehl hat jede SIMD-Spur eine entsprechende Stapel-ID (gezeigt als 16 Kontext-ID 0-15 in jedem CAM-Eintrag) und einen Shader-Aufnahmezeiger 4201A-B,... n (der als ein Tag-Wert agiert). In einer Ausführungsform vergleicht die Gruppierungsschaltung 4210 den Shader-Aufnahmezeiger für jede Spur mit den Tags 4201 in der CAM-Struktur 4201, um einen passenden Batch zu finden. Wird ein passender Batch gefunden, wird die Stapel-ID/Kontext-ID zu dem Batch hinzugefügt. Andernfalls wird ein neuer Eintrag mit einem neuen Shader-Aufnahmezeiger-Tag erzeugt, der möglicherweise einen älteren Eintrag mit einem unvollständigen Batch entfernt.

Ein ausführender Shader kann den Aufrufstapel freigeben, wenn er leer ist, indem er eine Freigabenachricht an die Nachrichteneinheit sendet. Die Freigabenachricht wird an den Planer weitergeleitet, der Stack-ID/Kontext-ID für aktive SIMD-Spuren an den freien Pool zurückgibt.

Eine Ausführungsform der Erfindung implementiert einen hybriden Ansatz für Ray-Durchquerungsoperationen durch Verwenden einer Kombination von Festfunktions-Ray-Durchquerung und Software-Ray-Durchquerung. Infolgedessen stellt sie die Flexibilität von Software-Durchquerung bereit, während die Effizienz von Festfunktions-Durchquerung aufrechterhalten wird. 43 zeigt eine Beschleunigungsstruktur, die für eine hybride Durchquerung verwendet werden kann, bei der es sich um einen Baum mit zwei Ebenen mit einzelner BVH oberer Ebene 4300 und mehreren BVH unterer Ebene 4301 und 4302 handelt. Rechts sind grafische Elemente gezeigt, um innere Durchquerungspfade 4303, äußere Durchquerungspfade 4304, Durchquerungsknoten 4305, Blattknoten mit Dreiecken 4306 und Blattknoten mit benutzerdefinierten Grundelementen 4307 anzuzeigen.

Die Blattknoten mit Dreiecken 4306 in der BVH oberer Ebene 4300 können auf Dreiecke, Kreuzungs-Shader-Aufnahmen für benutzerdefinierte Grundelemente oder Durchquerungs-Shader-Aufnahmen verweisen. Die Blattknoten mit Dreiecken 4306 der BVH unterer Ebene 4301-4302 können nur auf Dreiecke und Kreuzungs-Shader-Aufnahmen für benutzerdefinierte Grundelemente verweisen. Der Typ der Verweisung ist innerhalb des Blattknotens 4306 codiert. Die innere Durchquerung 4303 bezieht sich auf Durchquerung innerhalb jeder BVH 4300-4302. Innere Durchquerungsoperationen umfassen Berechnung von Ray-BVH-Kreuzungen, und Durchquerung über die BVH-Strukturen 4300-4302 hinweg ist als äußere Durchquerung bekannt. Innere Durchquerungsoperationen können effizient in Festfunktions-Hardware implementiert werden, während äußere Durchquerungsoperationen mit akzeptabler Leistung mit programmierbaren Shadern ausgeführt werden können. Infolgedessen führt eine Ausführungsform der Erfindung innere Durchquerungsoperationen durch Verwenden einer Festfunktions-Schaltung 4010 aus, und führt äußere Durchquerungsoperationen durch Verwenden der Shader-Ausführungsschaltung 4000, die SIMD/SIMT-Kerne/EU 4001 zum Ausführen programmierbarer Shader beinhaltet, aus.

Es ist zu beachten, dass die SIMD/SIMT-Kerne/EU 4001 hierin der Einfachheit halber manchmal einfach als „Kerne“, „SIMD-Kerne“, „EU“ oder „SIMD-Prozessoren“ bezeichnet werden. In ähnlicher Weise wird die Ray-BVH-Durchquerungs-/Kreuzungsschaltung 4005 manchmal einfach als „Durchquerungseinheit“, „Durchquerungs-/Kreuzungseinheit“ oder „Durchquerungs-/Kreuzungsschaltung“ bezeichnet. Wenn ein alternativer Begriff verwendet wird, ändert der zum Bezeichnen der jeweiligen Schaltung/Logik verwendete bestimmte Name nicht die zugrunde liegenden Funktionen, die die Schaltung/Logik ausführt, wie hierin beschrieben.

Darüber hinaus kann, obwohl zu Erläuterungszwecken in 40 als einzelne Komponente dargestellt, die Durchquerungs-/Kreuzungseinheit 4005 eine spezifische Durchquerungseinheit und eine separate Kreuzungseinheit umfassen, von denen jede in einer Schaltung und/oder Logik wie hierin beschrieben implementiert sein kann.

In einer Ausführungsform wird, wenn ein Ray einen Durchquerungsknoten während einer inneren Durchquerung kreuzt, ein Durchquerungs-Shader hervorgebracht. Die Sortierungsschaltung 4008 gruppiert diese Shader nach Shader-Aufnahmezeigern 4201A-B, n, um einen SIMD-Batch zu erzeugen, der durch den Planer 4007 zur SIMD-Ausführung auf den Grafik-SIMD-Kernen/EU 4001 gestartet wird. Durchquerungs-Shader können Durchquerung auf verschiedene Arten modifizieren, wobei ein weiter Bereich von Anwendungen ermöglicht wird. Zum Beispiel kann der Durchquerungs-Shader eine BVH mit einer gröberen Detailebene (Level-Of-Detail - LOD) auswählen, oder den Ray transformieren, um Transformationen starrer Körper zu ermöglichen. Der Durchquerungs-Shader erzeugt dann die innere Durchquerung für die ausgewählte BVH.

Die innere Durchquerung berechnet die Ray-BVH-Kreuzungen, indem sie die BVH durchquert und die Ray-Box- und Ray-Dreieck-Kreuzungen berechnet. Die innere Durchquerung wird auf die gleiche Weise wie bei Shadern hervorgebracht, indem eine Nachricht an die Nachrichtenübermittlungsschaltung 4004 gesendet wird, die die entsprechende Spawn-Nachricht an die Ray-BVH-Kreuzungsschaltung 4005, die Ray-BVH-Kreuzungen berechnet, weiterleitet.

In einer Ausführungsform wird der Stapel für die innere Durchquerung lokal in der Festfunktionsschaltung 4010 (zum Beispiel innerhalb des L1-Cache 4006) gespeichert. Wenn ein Ray einen Blattknoten kreuzt, der einem Durchquerungs-Shader oder einem Kreuzungs-Shader entspricht, wird die innere Durchquerung beendet und der innere Stapel wird abgeschnitten. Der abgeschnittene Stapel wird zusammen mit einem Zeiger auf den Ray und die BVH an einem durch den aufrufenden Shader spezifizierten Ort in den Speicher geschrieben, und dann wird der entsprechende Durchquerungs-Shader oder Kreuzungs-Shader hervorgebracht. Wenn der Ray während der inneren Durchquerung jegliche Dreiecke kreuzt, werden die entsprechenden Trefferinformationen als Eingabeargumente für diese Shader bereitgestellt, wie in dem Code unten gezeigt. Diese hervorgebrachten Shader werden durch die Sortierungsschaltung 4008 gruppiert, um SIMD-Batches zur Ausführung zu erzeugen.

      struct HitInfo {
        float barycentrics[2];
        float tmax;
        bool innerTravComplete;
        uint primID;
        uint geomID;
       ShaderRecord* leafShaderRecord;
      }

Abschneiden des inneren Durchquerungs-Stapels verringert die Kosten für Umlagern in Speicher. Eine Ausführungsform der Erfindung verwendet den in Restart Trail for Stackless BVH Traversal, High Performance Graphics (2010), S. 107-111 beschriebenen Ansatz, um den Stapel auf eine kleine Anzahl von Einträgen an der Spitze des Stapels, einen 42-bit Neustartpfad und ein 6-Bit-Tiefenwert zuzuschneiden. Der Neustartpfad zeigt Verzweigungen an, die bereits innerhalb der BVH genommen worden sind, und der Tiefenwert zeigt die dem letzten Stapeleintrag entsprechende Durchquerungstiefe an. Dies ist genügend Information, um die innere Durchquerung zu einem späteren Zeitpunkt wieder aufzunehmen.

Die innere Durchquerung ist abgeschlossen, wenn der innere Stapel leer ist und es keine zu prüfenden BVH-Knoten mehr gibt. In diesem Fall wird ein Behandler für den äußeren Stapel hervorgebracht, der die Spitze des äußeren Stapels öffnet und die Durchquerung wieder aufnimmt, wenn der äußere Stapel nicht leer ist.

In einer Ausführungsform führt die äußere Durchquerung die Hauptdurchquerungsstatussmaschine aus und ist in Programmcode implementiert, der durch die Shader-Ausführungsschaltung 4000 ausgeführt wird. Es wird eine innere Durchquerungsabfrage unter den folgenden Bedingungen hervorgebracht: (1) wenn ein neuer Ray durch einen Treffer-Shader oder einen primären Shader hervorgebracht wird; (2) wenn ein Durchquerungs-Shader eine BVH zur Durchquerung auswählt; und (3) wenn ein Behandler für den äußeren Stapel die innere Durchquerung für eine BVH wieder aufnimmt.

Wie in 44 veranschaulicht, wird, bevor die innere Durchquerung hervorgebracht wird, auf Aufrufstapel 4405 Platz für die Festfunktionsschaltung 4010 zugewiesen, um abgeschnittenen inneren Stapel 4410 zu speichern. Die Versatze 4403-4404 zu der Spitze des Aufrufstapels und des inneren Stapels werden in Durchquerungsstatus 4400, der ebenfalls in dem Speicher 2511 gespeichert ist, aufrechterhalten. Der Durchquerungsstatus 4400 beinhaltet auch den Ray in Weltraum 4401 und Objektraum 4402, sowie Trefferinformationen für das nächstgelegene kreuzende Grundelement.

Der Durchquerungs-Shader, der Kreuzungs-Shader und der Behandler für den äußeren Stapel werden alle durch die Ray-BVH-Kreuzungsschaltung 4005 hervorgebracht. Der Durchquerungs-Shader weist den Aufrufstapel 4405 zu, bevor eine neue innere Durchquerung für die BVH der zweiten Ebene initiiert wird. Der Behandler für den äußeren Stapel ist ein Shader, der für die Aktualisierung der Trefferinformationen und die Wiederaufnahme aller anstehenden inneren Durchquerungsaufgaben verantwortlich ist. Der Behandler für den äußeren Stapel ist auch dafür verantwortlich, Treffer- oder Verfehlungs-Shader hervorzubringen, wenn die Durchquerung abgeschlossen ist. Die Durchquerung ist abgeschlossen, wenn es keine anstehenden inneren Durchquerungsabfragen zum Hervorbringen gibt. Wenn die Durchquerung abgeschlossen ist und eine Kreuzung gefunden wurde, wird ein Treffer-Shader hervorgebracht; andernfalls wird ein Verfehlungs-Shader hervorgebracht.

Während das oben beschriebene hybride Durchquerungsschema eine BVH-Hierarchie mit zwei Ebenen verwendet, können die hierin beschriebenen Ausführungsformen der Erfindung eine willkürliche Anzahl von BVH-Ebenen mit einer entsprechenden Änderung in der äußeren Durchquerungsimplementierung verwenden.

Zusätzlich können, während die Festfunktionsschaltung 4010 zum Ausführen von Ray-BVH-Kreuzungen in den Ausführungsformen oben beschrieben ist, andere Systemkomponenten auch in Festfunktionsschaltungen implementiert werden. Zum Beispiel kann der oben beschriebene Behandler für den äußeren Stapel ein interner (nicht vom Benutzer sichtbarer) Shader sein, der potenziell in der Festfunktions-BVH-Durchquerungs-/Kreuzungsschaltung 4005 implementiert sein könnte. Diese Implementierung kann verwendet werden, um die Anzahl von versendeten Shader-Stufen und Rundläufen zwischen der Festfunktionskreuzungs-Hardware 4005 und dem Prozessor zu reduzieren.

Die hier beschriebenen Ausführungsformen der Erfindung ermöglichen programmierbares Shading und Ray-Durchquerungssteuerung durch Verwenden benutzerdefinierter Funktionen, die mit größerer SIMD-Effizienz auf bestehenden und zukünftigen GPU-Prozessoren ausgeführt werden können. Programmierbare Steuerung von Ray-Durchquerung ermöglicht verschiedene wichtige Merkmale, wie zum Beispiel prozedurale Instanziierung, stochastische Detailebenenauswahl, benutzerdefinierte Grundelementkreuzung und träge BVH-Aktualisierungen.

HARDWARE-BASIERTE RAYTRACING-ABFRAGEN

Wie erwähnt, werden Hüllvolumenhierarchien (BVH) üblicherweise verwendet, um die Effizienz zu verbessern, mit der Operationen an Grafikgrundelementen und anderen Grafikobjekten ausgeführt werden. Eine BVH ist eine hierarchische Baumstruktur, die basierend auf einem Satz von geometrischen Objekten aufgebaut ist. An der Spitze der Baumstruktur ist der Wurzelknoten, der alle geometrischen Objekte in einer gegebenen Szene umschließt. Die einzelnen geometrischen Objekte werden in Hüllvolumina verpackt, die die Blattknoten des Baums bilden. Diese Knoten werden dann als kleine Sätze gruppiert und innerhalb größerer Hüllvolumina umschlossen. Diese wiederum werden in rekursiver Art gruppiert und innerhalb anderer größerer Hüllvolumina umschlossen, was schließlich in einer Baumstruktur mit einem einzelnen Hüllvolumen, das durch den Wurzelknoten an der Spitze des Baums dargestellt wird, resultiert. Hüllvolumenhierarchien werden verwendet, um eine Vielzahl von Operationen an Sätzen von geometrischen Objekten effizient zu unterstützen, wie zum Beispiel Kollisionserkennung, Grundelement-Culling und Ray-Durchquerungs-/Kreuzungsoperationen, die bei Raytracing verwendet werden.

Rays werden quer durch eine BVH geleitet, um die Anzahl der Ray-Grundelement-Kreuzungen zu reduzieren. Wenn zum Beispiel ein Ray nicht durch den Wurzelknoten der BVH läuft, dann kreuzt der Ray keines der durch die BVH umschlossenen Grundelemente, und es ist keine weitere Verarbeitung für den Ray in Bezug auf diesen Satz von Grundelementen erforderlich. Wenn ein Ray durch den ersten Child-Knoten der BVH, aber nicht durch den zweiten Child-Knoten läuft, dann muss der Ray nicht gegen jegliche durch den zweiten Child-Knoten umschlossenen Grundelemente geprüft werden. Auf diese Weise stellt eine BVH einen effizienten Mechanismus zum Reduzieren der Anzahl von Ray-Grundelement-Kreuzungen bereit.

In einer Ausführungsform der Erfindung beinhaltet die Durchquerungs-/Kreuzungsschaltung 4005 eine Schaltung und/oder Logik zum Ausführen mehr erweiterter Knoten-Kreuzungsvarianten, wenn eine BVH durchquert wird. Anstatt zum Beispiel Unterstützung zu Ray-Abfragen zu beschränken (zum Beispiel Prüfen eines einzelnen Ray gegen einen BVH-Knoten), unterstützt eine Ausführungsform der Durchquerungs-/Kreuzungsschaltung 4005 konfigurierbare Abfragen, einschließlich Abfragen, wie zum Beispiel Box versus BVH-Knoten (b), Kugel versus BVH-Knoten (c), Stumpf versus BVH-Knoten (d), Punkt versus BVH-Knoten (e).

Das Erweitern der Durchquerungs-/Kreuzungsschaltung 4005, um allgemeinere Abfragen auf diese Weise zu unterstützen, ist für eine Vielzahl von Funktionen nützlich. Zum Beispiel kann die allgemeine Abfragearchitektur dazu ausgelegt sein, dass sie alle Kreuzungen mit einem Ray-Stumpf findet, oder die n-nächstgelegenen Kreuzungen findet. Diese Art von Abfragen ist sehr nützlich für Filterung, Simulationen, Kollisionserkennung und selektive BVH-Aufbaue.

45 veranschaulicht unterschiedliche Beispiele, einschließlich herkömmlichen Falls 4501, Box-BVH-Knotenprüfung 4502, Kugel-BVH-Knotenprüfung 4503, Stumpf-BVH-Knotenprüfung 4504 und Punkt-BVH-Knotenprüfung 4505. Es können verschiedene andere Abfragen entworfen werden, um eine Überlappung zwischen den unterschiedlichen Formen und der BVH zu bestimmen. In dieser Ausführungsform werden Knoten der BVH 4500A-J durchquert, indem Koordinatendaten der verschiedenen Formen mit den Koordinaten und Grenzen jedes der BVH-Knoten verglichen werden und schließlich an dem Blattknoten 4500J ankommen. Die Durchquerung wird hier durch die gestrichelten Pfeile angezeigt, die sich durch den Knoten 4500A, den Knoten 4500B, den Knoten 4500E, den Knoten 45001 und den Blattknoten 4500J bewegen. Angenommen, dass diese Durchquerung/Abfrage mit einer Box durchgeführt wird, können die Koordinaten der Box (zum Beispiel Min/Max-Werte für x, y und z) mit den Begrenzungskoordinaten jedes der BVH-Knoten verglichen werden, um nach unten zu dem Knoten mit der kleinsten Größe, der durch die Box gekreuzt wird, zu filtern. Der gleiche Prozess kann für jede der anderen Formen, die unterschiedliche Sätze von Koordinaten haben können, ausgeführt werden. Der Punkt 4505 kann zum Beispiel eine einzelne x-, y-, z-Koordinate haben, während die Kugel eine Mittelkoordinate und einen Radius haben kann (der verwendet werden kann, um die Min/Max-Koordinaten zu bestimmen, die mit den BVH-Knoten verglichen werden sollen).

Wie in 46 veranschaulicht, beinhaltet Durchquerungs-/Kreuzungseinheit 4603 dieser Ausführungsform Multiform-Durchquerungs-/Kreuzungsschaltung 4600 zum Beurteilen der Koordinaten jeder Form, die durch Formverarbeitungsschaltung/-Logik 4601 in Bezug auf die Knoten von BVH 4609 bereitgestellt werden, um Kreuzungen zu identifizierenden. Die Formverarbeitungsschaltung/-Logik 4601 kann zum Beispiel unterschiedliche volumetrische (3D) oder 2D-Formen eingeben, indem Werte angezeigt werden, die diesen Formen zugeordnet sind. Zum Beispiel kann ein Kreis durch einen Mittelpunkt und einen Radius spezifiziert werden, und ein rechteckiger Quader oder eine Pyramide kann durch unterschiedliche Sätze von 3D-Koordinaten spezifiziert werden. Die Ausführungsformen der Erfindung können in Bezug auf jegliche 2D- oder 3D-Formen einschließlich Polygone und Polyeder (zum Beispiel Tetraeder, Voxel, Hexaeder, Keile, usw.) eingesetzt werden.

In einer Ausführungsform beinhaltet erweiterte Raytracing-Engine 4610 auch Abfrageverarbeitungsschaltung/-Logik 4604 zum Verarbeiten von Status-/Kreuzungsdaten 4620, einschließlich Daten, die den BVH-Knoten 4609 zugeordnet sind, um Abfragen auszuführen, die die Speicherung von Kreuzungsinformationen für N Kreuzungen erfordern (wie zum Beispiel Abfragen über N-nächstgelegene Nachbarn).

Zusätzlich lagert in einer Ausführungsform die Raytracing-Engine 4610 bestimmte Typen von Abfragen an programmierbare Ausführungseinheiten (EU) 4651-4653, N, aus. Insbesondere werden bestimmte Abfragen, die durch die EU effizient verarbeitet werden können, an Planer 4660 gesendet, der die Arbeit an den EU 4651-4653, N, plant. Dies kann zum Beispiel Abfragen beinhalten, um alle innerhalb einer Box/Kugel/einem Stumpf enthaltenen Grundelemente zurückzugeben, wann immer die Raytracing-Engine 4610 ein BVH-Blatt erreicht. Die EU 4651-4653, N können dann Programmcode ausführen, der die in der spezifizierten Form enthaltene Geometrie verarbeitet.

Die veranschaulichte Ausführungsform beinhaltet auch BVH-Verarbeitungsschaltung/-Logik 4607, die die BVH 4609 basierend auf Koordinaten und Abmessungen von einer Szene zugeordneten Eingabe-Grundelementen 4606 aufbaut. Nach dem Aufbau der BVH 4609 kann die BVH-Verarbeitungsschaltung/-Logik 4607 BVH-Ausbesserungsoperationen ausführen, um die Koordinaten und/oder Abmessungen der Knoten der BVH 4609 in Übereinstimmung mit Änderungen der Szene (zum Beispiel Änderungen der Koordinaten/Abmessungen der Eingabegrundelemente 4606) anzupassen.

HIERARCHISCHER BEAMTRACER

Eine Ausführungsform der Erfindung beinhaltet Schaltung/Logik zum Implementieren eines hierarchischen Beamtracers. Wie oben diskutiert, erreicht ein Beamtracer eine erheblich höhere Raytracing-Leistung für hochkohärente Ray-Verteilungen im Vergleich zum Tracing einzelner Rays. Zusätzlich ermöglicht Beamtracing die dynamische adaptive Erzeugung von Rays innerhalb des Beam, wodurch die Speicherung der Ray-Daten in Speicher überflüssig wird.

In einer Ausführungsform empfängt der hierarchische Beamtracer einen Beam als Eingabe und durchquert diesen Beam durch eine BVH. Verschiedene Darstellungen können verwendet werden, um den Beam darzustellen, einschließlich, aber nicht beschränkt auf Begrenzungsebenen und Intervallarithmetik.

Wenn der Beam einen gegebenen BVH-Knoten nicht kreuzt, dann kreuzen alle Rays innerhalb des Beam den entsprechenden BVH-Unterbaum nicht. Daher wird das Durchqueren dieser Unterbäume übersprungen. Eine beispielhafte BVH-Hierarchie, die mehrere BVH-Knoten 5300A-G umfasst, ist in 47 veranschaulicht. Knoten 4700D-G sind Blattknoten (unten in der Hierarchie) und Knoten 4700A-C sind innere Knoten.

48 veranschaulicht unterschiedliche potenzielle Ergebnisse, wenn Beam 4800 quer durch unterschiedliche Knoten 5300A-G geführt wird. Insbesondere wenn der Beam 4800 einen Knoten 5300C nicht kreuzt, wie bei 4801 angezeigt, kreuzen keine Rays innerhalb des Beam den entsprechenden BVH-Unterbaum, sodass das Durchqueren für diesen Unterbaum (zum Beispiel Knoten 5300C und seine Blattknoten 5300F-G) übersprungen wird.

Wie bei 4802 angezeigt, wird, wenn der Beam einen Knoten 5300B kreuzt, der Beam 4800 hierarchisch in N Child-Beams 4810 unterteilt, wobei in dem durch die vier Quadranten angezeigten Beispiel N=4 ist. In ähnlicher Weise können die Child-Beams 4810, die den Knoten 5300B kreuzen, weiter hierarchisch unterteilt werden. In diesem speziellen Beispiel kreuzt nur der obere linke Child-Beam den Knoten 5300B. Infolgedessen wird nur der eine kreuzende Child-Beam, wie bei 4803 gezeigt, in N Child-Beams 4811 weiter unterteilt.

Bei 4804 wird angenommen, dass der Knoten 5300E ein BVH-Blattknoten 5300E ist. In einer Ausführungsform werden, wenn ein Blattknoten erreicht wird oder nicht weiter unterteilt werden kann, Abtastorte adaptiv innerhalb der Beams erzeugt, die einzelnen Rays entsprechen, von denen drei veranschaulicht sind. Von den drei Rays sind zwei gezeigt, die den Blattknoten 5300E kreuzen, und einer, der den Blattknoten verfehlt. In einer Ausführungsform werden die zwei kreuzenden Rays dann gegen Grundelemente innerhalb des Blattknotens geprüft (zum Beispiel durch Verwenden einer Ray-Grundelement-Kreuzungsprüfung durch Verwenden dieser Rays und der Grundelemente, auf die in dem BVH-Blattknoten 5300E Bezug genommen wird).

Es ist zu beachten, dass die tatsächlichen Ray-Daten nicht gespeichert werden müssen, sondern im laufenden Betrieb durch Verwenden der Beam-Daten und der Abtastpunktorte innerhalb des Beam 4800 erzeugt werden können. In einer Ausführungsform werden die Abtastwerte innerhalb des Beam durch Verwenden von Quasi-Monte-Carlo (QMC) -Techniken erzeugt, die eine bessere Abtastungsverteilung ermöglichen. Zusätzlich verfolgt in einer Implementierung Durchquerungs-/Kreuzungs-Hardware 5003 ein minimales/maximales Intervall von Ray-Kreuzungsentfernungen pro Child-Beam, was BVH-Knoten-Culling basierend auf der Tiefe ermöglicht.

Wie in 49 veranschaulicht, beinhaltet in einer Ausführungsform die Durchquerungs-/Kreuzungs-Hardware 4603 hierarchische Beam-basierte Durchquerungsschaltung 4920 zum Ausführen der hierin beschriebenen hierarchischen Beam-Durchquerungstechniken. Beam-Erzeuger 5422 erzeugt Beams, die in Beam-Daten 4924 spezifiziert sind. Die hierarchische Beam-basierte Durchquerungsschaltung 4920 verwendet die Koordinaten der Rays, die einen Beam begrenzen (zum Beispiel Ursprung und Richtung), um den Beam quer durch die Knoten der BVH 4605 zu leiten.

Wie in vorherigen Ausführungsformen werden die Knoten der BVH 4605 durch die BVH-Verarbeitungsschaltung 5207 erzeugt. Es kann bestimmt werden, dass ein Beam einen Knoten der BVH kreuzt, wenn jeglicher der Rays des Beam diesen Knoten kreuzt. Sobald die hierarchische Beam-basierte Durchquerungsschaltung 4920 bestimmt, dass ein Beam einen BVH-Knoten kreuzt, kann der Beam in Child-Beams unterteilt werden, und jeglicher Child-Beam, der den Knoten kreuzt, kann weiter in Child-Beams des ursprünglichen Child-Beam unterteilt werden, und so weiter, bis ein „Blatt“-Beam erreicht wurde (zum Beispiel ein Beam, der nicht weiter unterteilt wird).

Zum Beispiel unterteilt, wie in Bezug auf 48 beschrieben, wenn ein Beam einen BVH-Knoten durchquert, die hierarchische Beam-basierte Durchquerungsschaltung 4920 den Beam in einen ersten Satz von Child-Beams. Der eine oder die mehreren Child-Beams, die den BVH-Knoten kreuzen, werden dann identifiziert und weiter in zusätzliche Child-Beams unterteilt. Die hierarchische Beam-basierte Durchquerungsschaltung 4920 fährt fort, aufeinanderfolgende kreuzende Child-Beams zu unterteilen, und/oder fährt fort, die BVH-Hierarchie nach unten zu durchqueren, bis ein BVH-Blattknoten und/oder ein Beam-Blattknoten erreicht ist. Wenn ein Blattknoten erreicht ist, werden einzelne Rays innerhalb des Child-Beam erzeugt, um auf Kreuzungen mit dem BVH-Blattknoten zu prüfen. Diejenigen, die den BVH-Blattknoten kreuzen, werden dann gegen Grundelemente in dem Blattknoten geprüft, und die Durchquerungs-/Kreuzungsschaltung erzeugt Kreuzungsergebnisse.

Ein Verfahren gemäß einer Ausführungsform wird in 50 veranschaulicht. Das Verfahren kann innerhalb des Kontext der oben beschriebenen Systemarchitekturen implementiert werden, ist jedoch nicht auf jegliche bestimmte System- oder Prozessorarchitektur beschränkt.

Bei 5051 werden Beam-Daten und BVH-Knotendaten erzeugt (oder bei nachfolgenden Iterationen aktualisiert). Wenn der erzeugte Beam den bei 5002 bestimmten aktuellen BVH-Knoten nicht kreuzt, wird bei 5006 die Durchquerung für diesen BVH-Knoten übersprungen und ein anderer BVH-Knoten in der Hierarchie wird ausgewählt (zum Beispiel ein anderer Child-Knoten, der den gleichen Parent-Knoten teilt).

Wenn der Beam bei 5002 den BVH-Knoten kreuzt, wird der Beam bei 5003 hierarchisch in N Child-Beams unterteilt, um ihn gegen den BVH-Knoten zu prüfen, und/oder die BVH-Hierarchie wird weiter durchquert, um einen neuen BVH-Knoten zu identifizieren. Jeder Child-Beam, von dem festgestellt wird, dass er den aktuellen BVH-Knoten kreuzt, kann weiter unterteilt werden, bis bei 5004 ein Blattknoten erreicht ist. Hier werden M Rays innerhalb des kreuzenden Child-Beams erzeugt, und bei 5005 werden Ray-Grundelement-Kreuzungsprüfungen für jeden der M Rays ausgeführt, die den Blattknoten kreuzen. Kreuzungsdaten werden dann für alle erkannten Ray-Grundelement-Kreuzungen erzeugt.

In Ausführungsformen, kann sich der Begriff „Engine/Maschine“ oder „Modul“ oder „Logik“ auf einen Application-Specific-Integrated-Circuit (ASIC), eine elektronische Schaltung, einen Prozessor (geteilt, fest zugeordnet oder gruppiert) und/oder Speicher (geteilt, fest zugeordnet oder gruppiert), die eines oder mehr Software- oder Firmware-Programme, eine kombinatorische Logikschaltung und/oder geeignete Komponenten, die die beschriebene Funktionalität bereitstellen, beziehen, ein Teil davon sein, oder diese beinhalten. In Ausführungsformen kann eine Maschine, ein Modul oder eine Logik in Firmware, Hardware, Software oder jeglicher Kombination von Firmware, Hardware und Software implementiert sein.

Ausführungsformen der Erfindung können verschiedene Schritte beinhalten, die oben beschrieben wurden. Die Schritte können in maschinenausführbaren Anweisungen verkörpert sein, die verwendet werden können, um einen Mehrzweck- oder Spezialprozessor dazu zu veranlassen, die Schritte auszuführen. Alternativ können diese Schritte durch spezifische Hardware-Komponenten, die eine festverdrahtete Logik zum Ausführen der Schritte enthalten, oder durch jegliche Kombination aus programmierten Computerkomponenten und benutzerdefinierten Hardware-Komponenten ausgeführt werden.

Wie hierin beschrieben, können sich Anweisungen auf spezifische Konfigurationen von Hardware beziehen, wie zum Beispiel Application-Specific-Integrated-Circuits (ASIC), die zum Ausführen bestimmter Operationen konfiguriert sind oder eine vorgegebene Funktionalität oder Software-Anweisungen haben, die in Speicher gespeichert sind, der in einem nichtflüchtigen computerlesbaren Medium verkörpert ist. Somit können die in den Figuren gezeigten Techniken durch Verwenden von Code und Daten implementiert werden, die auf einem oder mehreren elektronischen Geräten (zum Beispiel einer Endstation, einem Netzwerkelement, usw.) gespeichert und ausgeführt werden. Solche elektronischen Geräte speichern und kommunizieren (intern und/oder mit anderen elektronischen Geräten über ein Netzwerk) Code und Daten durch Verwenden computerlesbarer Medien, wie zum Beispiel nichtflüchtiger computerlesbarer Speicherungsmedien (zum Beispiel Magnetplatten; optische Platten; Random-Access-Memory; Read-Only-Memory; Flash-Speichergeräte; Phasenänderungsspeicher) und flüchtiger maschinenlesbarer Kommunikationsmedien (zum Beispiel elektrische, optische, akustische oder andere Formen von verbreiteten Signalen - wie zum Beispiel Trägerwellen, Infrarotsignale, digitale Signale, usw.).

Zusätzlich beinhalten solche elektronischen Geräte typischerweise einen Satz von einem oder mehreren Prozessoren, die mit einer oder mehreren anderen Komponenten gekoppelt sind, wie zum Beispiel einem oder mehreren Speichergeräten (nichtflüchtigen maschinenlesbaren Speicherungsmedien), Benutzereingabe-/Ausgabegeräten (zum Beispiel einer Tastatur, einem Touchscreen und/oder einer Anzeige) und Netzwerkverbindungen. Die Kopplung des Satzes von Prozessoren und anderer Komponenten erfolgt typischerweise durch einen oder mehrere Busse und Brücken (auch bezeichnet als Bussteuerungen). Das Speicherungsgerät und Signale, die den Netzwerkverkehr tragen, stellen jeweils ein oder mehrere maschinenlesbare Speicherungsmedien und maschinenlesbare Kommunikationsmedien dar. Somit speichert das Speicherungsgerät eines gegebenen elektronischen Geräts typischerweise Code und/oder Daten zur Ausführung auf dem Satz von einem oder mehreren Prozessoren dieses elektronischen Geräts. Selbstverständlich können ein oder mehrere Teile einer Ausführungsform der Erfindung durch Verwenden unterschiedlicher Kombinationen von Software, Firmware und/oder Hardware implementiert werden. über diese detaillierte Beschreibung hinweg wurden zu Zwecken der Erläuterung zahlreiche spezifische Details dargelegt, um ein sorgfältiges Verständnis der vorliegenden Erfindung bereitzustellen. Es ist jedoch für einen Fachmann offensichtlich, dass die Erfindung ohne einige dieser spezifischen Details praktiziert werden kann. In bestimmten Fällen wurden bekannte Strukturen und Funktionen nicht ausführlich beschrieben, um eine Verschleierung des Gegenstands der vorliegenden Erfindung zu vermeiden. Dementsprechend sollten der Umfang und Geist der Erfindung anhand der Ansprüche, die folgen, beurteilt werden.

Claims

Vorrichtung, die Folgendes umfasst: einen Beam-Erzeuger zum Erzeugen von Beam-Daten, die einem in eine Grafikszene projizierten Beam zugeordnet sind; einen Bounding-Volume-Hierarchie (BVH) -Erzeuger zum Erzeugen von BVH-Daten, die mehrere hierarchisch angeordnete BVH-Knoten umfassen; eine hierarchische Beam-basierte Durchquerungseinheit, um zu bestimmen, ob der Beam einen aktuellen BVH-Knoten kreuzt, und, falls dies der Fall ist, den Beam reaktiv in N Child-Beams zu unterteilen, um ihn gegen den aktuellen BVH-Knoten zu prüfen, und/oder um die BVH-Hierarchie weiter nach unten zu durchqueren, um einen neuen BVH-Knoten auszuwählen, wobei die hierarchische Beam-basierte Durchquerungseinheit aufeinanderfolgende kreuzende Child-Beams iterativ unterteilen und/oder fortfahren soll, die BVH-Hierarchie nach unten zu durchqueren, bis ein Blattknoten erreicht wird, mit dem sich mindestens ein endgültiger Child-Beam kreuzen soll; die hierarchische Beam-basierte Durchquerungseinheit mehrere Rays innerhalb des endgültigen Child-Beam erzeugen soll; und Kreuzungs-Hardware-Logik Kreuzungsprüfung für jegliche Rays ausführen soll, die den Blattknoten kreuzen, wobei die Kreuzungsprüfung Kreuzungen zwischen den Rays, die den Blattknoten kreuzen, und Grundelementen, die durch den Blattknoten begrenzt sind, bestimmen soll.
Vorrichtung nach Anspruch 1, wobei die hierarchische Beam-basierte Durchquerungseinheit die Durchquerung eines Unterbaums der BVH-Hierarchie beenden soll, nachdem erkannt wurde, dass ein erster Beam einen Parent-Knoten des Unterbaums nicht kreuzt.
Vorrichtung nach Anspruch 1 oder 2, wobei der BVH-Erzeuger die BVH-Daten erzeugen soll, die auf Beurteilung mehrerer Eingabegrundelemente der Grafikszene basieren sollen.
Vorrichtung nach Anspruch 1 oder 2, die ferner Folgendes umfasst: einen oder mehrere Grafikkerne, um einen oder mehrere Grafik-Shader auszuführen, die auf der Kreuzungs-Hardware-Logik, die die Kreuzungen zwischen den Rays und den Grundelementen erkennt, hervorgebracht wurden.
Vorrichtung nach Anspruch 4, wobei mindestens einer der Grafik-Shader einen Pixel-Shader umfasst, um Shader-Operationen an den Kreuzungen zugeordneten Pixeln auszuführen.
Vorrichtung nach Anspruch 5, wobei die Grafikkerne mehrere Ausführungseinheiten (Execution Units - EU) umfassen, um die Grafik-Shader auszuführen.
Vorrichtung nach Anspruch 6, die ferner Folgendes umfasst: einen Planer, der mit den EU gekoppelt ist, um Ausführung des einen oder der mehreren Grafik-Shader in den EU zu planen.
Vorrichtung nach Anspruch 1 oder 7, die ferner Folgendes umfasst: einen Cache lokal zu der hierarchischen Beam-basierten Durchquerungseinheit und Kreuzungs-Hardware-Logik, um relevante Abschnitte der BVH-Daten und Beam-Daten zu speichern.
Verfahren, das Folgendes umfasst: Erzeugen von Beam-Daten, die einem in eine Grafikszene projizierten Beam zugeordnet sind; Erzeugen von BVH-Daten, die mehrere hierarchisch angeordnete BVH-Knoten umfassen; Bestimmen, ob der Beam einen aktuellen BVH-Knoten kreuzt, und, falls dies der Fall ist, reaktives Unterteilen des Beam in N Child-Beams, um ihn gegen den aktuellen BVH-Knoten zu prüfen, und/oder Durchqueren der BVH-Hierarchie weiter nach unten, um einen neuen BVH-Knoten auszuwählen, iteratives Unterteilen aufeinanderfolgender kreuzender Child-Beams und/oder weiteres Durchqueren der BVH-Hierarchie nach unten, bis ein Blattknoten erreicht wird, mit dem sich mindestens ein endgültiger Child-Beam kreuzen soll; Erzeugen mehrerer Rays innerhalb des endgültigen Child-Beam; und Ausführen von Kreuzungsprüfung für jegliche Rays, die den Blattknoten kreuzen, wobei die Kreuzungsprüfung Kreuzungen zwischen den Rays, die den Blattknoten kreuzen, und Grundelementen, die durch den Blattknoten begrenzt sind, bestimmen soll.
Verfahren nach Anspruch 9, das ferner Folgendes umfasst: Beenden der Durchquerung eines Unterbaums der BVH-Hierarchie, nachdem erkannt wurde, dass ein erster Beam einen Parent-Knoten des Unterbaums nicht kreuzt.
Verfahren nach Anspruch 9 oder 10, das ferner Folgendes umfasst: Erzeugen der BVH-Daten basierend auf Beurteilung mehrerer Eingabegrundelemente der Grafikszene.
Verfahren nach Anspruch 9 oder 10, das ferner Folgendes umfasst: Ausführen eines oder mehrerer Grafik-Shader auf mindestens einem Grafikkern, wobei der eine oder die mehreren auf der Kreuzungs-Hardware-Logik hervorgebrachten Grafik-Shader die Kreuzungen zwischen den Rays und den Grundelementen erkennt.
Verfahren nach Anspruch 12, wobei mindestens einer der Grafik-Shader einen Pixel-Shader umfasst, um Shader-Operationen an den Kreuzungen zugeordneten Pixeln auszuführen.
Verfahren nach Anspruch 13, wobei die Grafikkerne mehrere Ausführungseinheiten (EU) umfassen, um die Grafik-Shader auszuführen.
Verfahren nach Anspruch 14, das ferner Folgendes umfasst: dynamisches Planen der Ausführung eines oder mehrerer Grafik-Shader in den EU.
Verfahren nach Anspruch 9 oder 15, das ferner Folgendes umfasst: Speichern relevanter Abschnitte der BVH-Daten und Beam-Daten in einem Cache lokal zu der hierarchischen Beam-basierten Durchquerungseinheit.
Maschinenlesbares Medium, auf dem Programmcode gespeichert ist, der, wenn er durch eine Maschine ausgeführt wird, die Maschine dazu veranlasst, folgende Operationen auszuführen: Erzeugen von Beam-Daten, die einem in eine Grafikszene projizierten Beam zugeordnet sind; Erzeugen von BVH-Daten, die mehrere hierarchisch angeordnete BVH-Knoten umfassen; Bestimmen, ob der Beam einen aktuellen BVH-Knoten kreuzt, und, falls dies der Fall ist, reaktives Unterteilen des Beam in N Child-Beams, um ihn gegen den aktuellen BVH-Knoten zu prüfen, und/oder Durchqueren der BVH-Hierarchie weiter nach unten, um einen neuen BVH-Knoten auszuwählen, iteratives Unterteilen aufeinanderfolgender kreuzender Child-Beams und/oder weiteres Durchqueren der BVH-Hierarchie nach unten, bis ein Blattknoten erreicht wird, mit dem sich mindestens ein endgültiger Child-Beam kreuzen soll; Erzeugen mehrerer Rays innerhalb des endgültigen Child-Beam; und Ausführen von Kreuzungsprüfung für jegliche Rays, die den Blattknoten kreuzen, wobei die Kreuzungsprüfung Kreuzungen zwischen den Rays, die den Blattknoten kreuzen, und Grundelementen, die durch den Blattknoten begrenzt sind, bestimmen soll.
Maschinenlesbares Medium nach Anspruch 17, das ferner Programmcode umfasst, um die Maschine dazu zu veranlassen, folgende Operationen auszuführen: Beenden der Durchquerung eines Unterbaums der BVH-Hierarchie, nachdem erkannt wurde, dass ein erster Beam einen Parent-Knoten des Unterbaums nicht kreuzt.
Maschinenlesbares Medium nach Anspruch 17 oder 18, das ferner Programmcode umfasst, um die Maschine dazu zu veranlassen, folgende Operationen auszuführen: Erzeugen der BVH-Daten basierend auf Beurteilung mehrerer Eingabegrundelemente der Grafikszene.
Maschinenlesbares Medium nach Anspruch 17 oder 18, das ferner Programmcode umfasst, um die Maschine dazu zu veranlassen, folgende Operationen auszuführen: Ausführen eines oder mehrerer Grafik-Shader auf mindestens einem Grafikkern, wobei der eine oder die mehreren auf der Kreuzungs-Hardware-Logik hervorgebrachten Grafik-Shader die Kreuzungen zwischen den Rays und den Grundelementen erkennt.
Maschinenlesbares Medium nach Anspruch 20, wobei mindestens einer der Grafik-Shader einen Pixel-Shader umfasst, um Shader-Operationen an den Kreuzungen zugeordneten Pixeln auszuführen.
Maschinenlesbares Medium nach Anspruch 21, wobei die Grafikkerne mehrere Ausführungseinheiten (EU) umfassen, um die Grafik-Shader auszuführen.
Maschinenlesbares Medium nach Anspruch 22, das ferner Programmcode umfasst, um die Maschine dazu zu veranlassen, folgende Operationen auszuführen: dynamisches Planen der Ausführung eines oder mehrerer Grafik-Shader in den EU.
Maschinenlesbares Medium nach Anspruch 17 oder 23, das ferner Programmcode umfasst, um die Maschine dazu zu veranlassen, folgende Operationen auszuführen: Speichern relevanter Abschnitte der BVH-Daten und Beam-Daten in einem Cache lokal zu der hierarchischen Beam-basierten Durchquerungseinheit.
Vorrichtung, die Folgendes umfasst: Mittel zum Erzeugen von Beam-Daten, die einem in eine Grafikszene projizierten Beam zugeordnet sind; Mittel zum Erzeugen von BVH-Daten, die mehrere hierarchisch angeordnete BVH-Knoten umfassen; Mittel zum Bestimmen, ob der Beam einen aktuellen BVH-Knoten kreuzt, und, falls dies der Fall ist, zum reaktiven Unterteilen des Beam in N Child-Beams, um ihn gegen den aktuellen BVH-Knoten zu prüfen, und/oder zum Durchqueren der BVH-Hierarchie weiter nach unten, um einen neuen BVH-Knoten auszuwählen, Mittel zum iterativen Unterteilen aufeinanderfolgender kreuzender Child-Beams und/oder zum weiteren Durchqueren der BVH-Hierarchie nach unten, bis ein Blattknoten erreicht wird, mit dem sich mindestens ein endgültiger Child-Beam kreuzen soll; Mittel zum Erzeugen mehrerer Rays innerhalb des endgültigen Child-Beam; und Mittel zum Ausführen von Kreuzungsprüfung für jegliche Rays, die den Blattknoten kreuzen, wobei die Kreuzungsprüfung Kreuzungen zwischen den Rays, die den Blattknoten kreuzen, und Grundelementen, die durch den Blattknoten begrenzt sind, bestimmen soll.