DE102021118059A1

DE102021118059A1 - VORRICHTUNG UND VERFAHREN ZUR EFFIZIENTEN GRAFIKVERARBEITUNG EINSCHLIEßLICH STRAHLVERFOLGUNG

Info

Publication number: DE102021118059A1
Application number: DE102021118059.7A
Authority: DE
Inventors: Sven Woop; Michael J. Doyle; Sreenivas Kothandaraman; Karthik Vaidyanathan; Abhishek R. Appu; Carsten Benthin; Prasoonkumar Surti; Holger Gruen; Stephen Junkins; Adam Lake; Bret G. Alfieri; Gabor Liktor; Joshua Barczak; Won-Jong Lee
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-08-17
Filing date: 2021-07-13
Publication date: 2022-03-10
Also published as: CN114078076A; DE102021118444A1; US11995767B2; NL2028744B1; US20220051476A1; TW202209258A; WO2022039869A1; CN116075863A; US20220051466A1; EP4196961A1; NL2028744A

Abstract

Vorrichtung und Verfahren zur effizienten Grafikverarbeitung einschließlich Strahlverfolgung. Eine Ausführungsform eines Grafikprozessors umfasst zum Beispiel: Ausführungshardwarelogik zum Ausführen von Grafikbefehlen und Rendern von Bildern; eine Schnittstelle zum Koppeln von Funktionseinheiten der Ausführungshardwarelogik mit einer gekachelten Ressource; und einen gekachelten Ressourcenmanager zum Verwalten des Zugriffs der Funktionseinheiten auf die gekachelte Ressource, eine Funktionseinheit der Ausführungshardwarelogik, um eine Anforderung mit einer Hash-Kennung (ID) zu erzeugen, um Zugriff auf einen Teil der gekachelten Ressource anzufordern, wobei der Manager für gekachelte Ressourcen bestimmen soll, ob ein Teil der gekachelten Ressource existiert, der durch die Hash-Kennung identifiziert wird, und wenn nicht, einen neuen Teil der gekachelten Ressource zuzuweisen und den neuen Teil der Hash-Kennung zuzuordnen.

Description

HINTERGRUND
Querverweis auf verwandte Anmeldungen
Diese Anmeldung beansprucht den Vorteil der vorläufigen US-Patentanmeldung mit der Seriennummer 63/066,799 , eingereicht am 17. August 2020, die hierin durch Bezugnahme aufgenommen wird.
Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich allgemein auf das Gebiet der Grafikprozessoren. Insbesondere betrifft die Erfindung eine Vorrichtung und ein Verfahren zur effizienten Grafikverarbeitung einschließlich Strahlverfolgungsimplementierungen.
Beschreibung der verwandten Technik
Die Strahlverfolgung ist eine Technik, bei der ein Lichttransport durch physisch basiertes Rendern simuliert wird. Weit verbreitet beim kinematischen Rendern wurde sie bis vor wenigen Jahren als zu ressourcenintensiv für Echtzeitdurchführung angesehen. Eine der Schlüsseloperationen bei der Strahlverfolgung ist das Verarbeiten einer Sichtbarkeitsanfrage für Strahl-Szenen-Schnittpunkte, die als „StrahlTraversierung“ bekannt ist, die Strahl-Szenen-Schnittpunkte berechnet, indem sie Knoten in einer Bounding Volume Hierarchy (BVH) durchlaufen und schneiden.
Rasterisierung ist eine Technik, bei der Bildschirmobjekte aus 3D-Modellen von Objekten erzeugt werden, die aus einem Netz von Dreiecken erzeugt werden. Die Vertices jedes Dreiecks schneiden sich mit den Vertices anderer Dreiecke unterschiedlicher Form und Größe. Jeder Vertex weist eine Position im Raum sowie Informationen über Farbe, Textur und seine Normale auf, die verwendet werden, um zu bestimmen, wie die Oberfläche eines Objekts zeigt. Eine Rasterisierungseinheit wandelt die Dreiecke der 3D-Modelle in Pixel in einem 2D-Bildschirmraum um, wobei jedem Pixel ein Anfangsfarbwert basierend auf den Vertexdaten zugeordnet werden kann.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung kann aus der folgenden ausführlichen Beschreibung in Verbindung mit den folgenden Zeichnungen erlangt werden, wobei gilt:

1 ist ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor, der einen oder mehrere Prozessorkerne und Grafikprozessoren aufweist;
Die 2A-D veranschaulichen Rechensysteme und Grafikprozessoren, die durch Ausführungsformen der Erfindung bereitgestellt werden;
Die 3A-C veranschaulichen Blockdiagramme zusätzlicher Grafikprozessor- und Rechenbeschleunigerarchitekturen;
4 ist ein Blockdiagramm einer Ausführungsform einer Grafikverarbeitungsengine für einen Grafikprozessor;
Die 5A-B veranschaulichen eine Thread-Ausführungslogik einschließlich eines Arrays von Verarbeitungselementen;
6 ist ein Blockdiagramm einer Thread-Ausführungslogik einschließlich eines Arrays von Verarbeitungselementen;
7 veranschaulicht ein Grafikprozessorausführungseinheitanweisungsformat gemäß einer Ausführungsform;
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors, der eine Grafik-Pipeline, eine Medien-Pipeline, eine Anzeige-Engine, Thread-Ausführungslogik und eine Renderausgabe-Pipeline aufweist;
9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat gemäß einer Ausführungsform veranschaulicht;
9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz gemäß einer Ausführungsform veranschaulicht;
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einer Ausführungsform;
11A veranschaulicht beispielhafte IP-Kernentwicklungssysteme, die verwendet werden können, um eine integrierte Schaltung zum Durchführen von Operationen gemäß einer Ausführungsform herzustellen;
Die 11B-D veranschaulichen beispielhafte Gehäuseanordnungen einschließlich Chiplets und Interposersubstraten;
12 veranschaulicht eine beispielhafte integrierte System-on-Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform;
13 veranschaulicht einen beispielhaften Grafikprozessor einer integrierten System-on-Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann;
14 veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor einer integrierten System-on-Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann;
15 veranschaulicht eine Architektur zum Durchführen eines anfänglichen Trainings einer Maschinenlernarchitektur;
16 veranschaulicht, wie eine Maschinenlern-Engine während der Laufzeit kontinuierlich trainiert und aktualisiert wird;
17 veranschaulicht, wie eine Maschinenlern-Engine während der Laufzeit kontinuierlich trainiert und aktualisiert wird;
Die 18A-B veranschaulichen, wie Maschinenlerndaten in einem Netzwerk gemeinsam genutzt werden; und
19 veranschaulicht ein Verfahren zum Trainieren einer Maschinenlern-Engine;
20 veranschaulicht, wie Knoten Geisterregionsdaten austauschen, um verteilte Entrauschungsoperationen durchzuführen;
21 veranschaulicht eine Architektur, in der Bildwiedergabe- und Entrauschungsoperationen über mehrere Knoten verteilt sind;
22 veranschaulicht zusätzliche Einzelheiten einer Architektur zum verteilten Rendern und Entrauschen;
23 veranschaulicht ein Verfahren zum Durchführen eines verteilten Renderns und Entrauschens;
24 veranschaulicht ein Maschinenlernverfahren;
25 veranschaulicht mehrere miteinander verbundene Universalgrafikprozessoren;
26 veranschaulicht einen Satz von Faltungsschichten und vollständig verbundenen Schichten für eine Maschinenlernimplementierung;
27 veranschaulicht ein Beispiel für eine Faltungsschicht;
28 veranschaulicht ein Beispiel für einen Satz von miteinander verbundenen Knoten in einer Maschinenlernimplementierung;
29 veranschaulicht ein Trainingsgerüst, innerhalb dessen ein neuronales Netzwerk unter Verwendung eines Trainingsdatensatzes lernt;
30A veranschaulicht Beispiele für Modellparallelität und Datenparallelität;
30B veranschaulicht ein System auf einem Chip (SoC: System on a Chip);
31 veranschaulicht eine Verarbeitungsarchitektur, die Strahlverfolgungskerne und Tensorkerne aufweist;
32 veranschaulicht ein Beispiel für ein Strahlenbündel;
33 veranschaulicht eine Vorrichtung zum Durchführen einer Strahlverfolgung;
34 veranschaulicht ein Beispiel für eine Strahlhierarchie;
35 veranschaulicht ein Verfahren zum Durchführen von Strahlverfolgung;
36 veranschaulicht ein Beispiel für eine verteilte Strahlverfolgungsengine;
Die 37-38 veranschaulichen eine Komprimierung, die in einem Strahlverfolgungssystem durchgeführt wird;
39 veranschaulicht ein Verfahren, das auf einer Strahlverfolgungsarchitektur implementiert ist;
40 veranschaulicht eine beispielhafte hybride Strahlverfolgungsvorrichtung;
41 veranschaulicht Stapel, die für Strahlverfolgungsoperationen verwendet werden;
42 veranschaulicht zusätzliche Details für eine hybride Strahlverfolgungsvorrichtung;
43 veranschaulicht eine Bounding Volume Hierarchy;
44 veranschaulicht einen Aufrufstapel und einen Traversieru ng szu sta ndsspeicher;
45 veranschaulicht ein Verfahren zum Durchlaufen und Schneiden;
Die 46A-B veranschaulichen, wie mehrere Sendezyklen erforderlich sind, um gewisse Shader auszuführen;
47 veranschaulicht, wie ein einziger Sendezyklus mehrere Shader ausführt;
48 veranschaulicht, wie ein einziger Sendezyklus mehrere Shader ausführt;
49 veranschaulicht eine Architektur zum Ausführen von Strahlverfolgungsanweisungen;
50 veranschaulicht ein Verfahren zum Ausführen von Strahlverfolgungsanweisungen innerhalb eines Threads;
51 veranschaulicht eine Ausführungsform einer Architektur zur asynchronen Strahlverfolgung;
52A veranschaulicht eine Ausführungsform einer Strahltraversierungsschaltung;
52B veranschaulicht Prozesse, die in einer Ausführungsform ausgeführt werden, um Strahlenspeicherungsbänke zu verwalten;
53 veranschaulicht eine Ausführungsform einer Prioritätsauswahlschaltungsanordnung/-logik;
54 und 55A-B veranschaulichen verschiedene Arten von Strahlverfolgungsdaten einschließlich Flags, Ausnahmen und Aussortierungsdaten, die in einer Ausführungsform der Erfindung verwendet werden;
56 veranschaulicht eine Ausführungsform zur Frühermittlung aus der Strahlverfolgungspipeline;
57 veranschaulicht eine Ausführungsform einer Prioritätsauswahlschaltungsanordnung/-logik;
58 veranschaulicht eine beispielhafte Bounding Volume Hierarchy (BVH), die für Strahltraversieroperationen verwendet wird;
Die 59A-B veranschaulichen zusätzliche Traversieroperationen;
60 veranschaulicht eine Ausführungsform einer Stapelverwaltungsschaltungsanordnung zum Verwalten eines BVH-Stapels;
Die 61A-B veranschaulichen beispielhafte Datenstrukturen, Teilstrukturen und Operationen, die für Strahlen, Treffer und Stapel durchgeführt werden;
62 veranschaulicht eine Ausführungsform eines Detaillierlevelselektors mit einer N-Bit-Vergleichsoperationsmaske;
63 veranschaulicht eine Beschleunigungsdatenstruktur gemäß einer Ausführungsform der Erfindung;
64 veranschaulicht eine Ausführungsform eines Komprimierungsblocks, der Restwerte und Metadaten aufweist;
65 veranschaulicht ein Verfahren gemäß einer Ausführungsform der Erfindung;
66 veranschaulicht eine Ausführungsform eines Block-Offset-Indexkomprimierungsblocks;
67A veranschaulicht eine hierarchische Bit-Vektor-Indexierung (HBI) gemäß einer Ausführungsform der Erfindung;
67B veranschaulicht einen Indexkomprimierungsblock gemäß einer Ausführungsform der Erfindung; und
68 veranschaulicht eine beispielhafte Architektur einschließlich einer BVH-Komprimierungsschaltungsanordnung/-logik und einer Dekomprimierungsschaltungsanordnung/-logik;
69A veranschaulicht eine Verschiebungsfunktion, die auf ein Gitter angewendet wird;
69B veranschaulicht eine Ausführungsform einer Komprimierungsschaltungsanordnung zum Komprimieren eines Gitters oder Meshlets;
70A veranschaulicht eine Verschiebungsabbildung auf einer Basisunterteilungsfläche;
Die 70B-C veranschaulichen Differenzvektoren relativ zu einem groben Basisnetz;
71 veranschaulicht ein Verfahren gemäß einer Ausführungsform der Erfindung;
Die 72-74 veranschaulichen ein Netz, das mehrere miteinander verbundene Vertices aufweist;
75 veranschaulicht eine Ausführungsform eines Tesselators zum Erzeugen eines Netzes;
Die 76-77 veranschaulichen eine Ausführungsform, bei der Begrenzungsvolumina basierend auf einem Netz gebildet werden;
78 veranschaulicht eine Ausführungsform eines Netzes, das überlappende Vertices gemeinsam nutzt;
79 veranschaulicht ein Netz mit gemeinsam genutzten Kanten zwischen Dreiecken;
80 veranschaulicht eine Strahlverfolgungsengine gemäß einer Ausführungsform;
81 veranschaulicht einen BVH-Verdichter gemäß einer Ausführungsform;
Die 82A-C veranschaulichen beispielhafte Datenformate für ein 64-Bit-Register;
Die 83A-B veranschaulichen eine Ausführungsform eines Indexes für einen Ringpuffer;
Die 84A-B veranschaulichen beispielhafte Ringpufferatomik für Hersteller und Verbraucher;
85A veranschaulicht eine Ausführungsform einer gekachelten Ressource;
85B veranschaulicht ein Verfahren gemäß einer Ausführungsform der Erfindung;
86A veranschaulicht eine Ausführungsform einer BVH-Verarbeitungslogik einschließlich eines On-demand-Builders;
86B veranschaulicht eine Ausführungsform eines On-demand-Builders für eine Beschleunigungsstruktur;
86C veranschaulicht eine Ausführungsform einer sichtbaren Unterebene-Beschleunigungsstrukturkarte;
86D veranschaulicht verschiedene Arten von Instanzen und Traversierungsentscheidungen;
87 veranschaulicht eine Ausführungsform einer materialbasierten Aussonderungsmaske;
88 veranschaulicht eine Ausführungsform, bei der eine Vierfachbaumstruktur über einem Geometrienetz gebildet ist;
89A veranschaulicht eine Ausführungsform einer Strahlverfolgungsarchitektur;
89B veranschaulicht eine Ausführungsform, die eine Meshlet-Komprimierung aufweist;
90 veranschaulicht mehrere Threads einschließlich synchroner Threads, divergierender Erzeugungsthreads, regulärer Erzeugungsthreads und konvergierender Erzeugungsthreads;
91 veranschaulicht eine Ausführungsform einer Strahlverfolgungsarchitektur mit einem bindungslosen Thread-Dispatcher;
92 veranschaulicht einen Strahlverfolgungs-Cluster gemäß einer Ausführungsform;
Die 93-100 veranschaulichen Ausführungsformen des Verwendens von Proxydaten in einer Mehrfachknoten-Strahlverfolgungsimplementierung;
101 veranschaulicht ein Verfahren gemäß einer Ausführungsform der Erfindung.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zu Erläuterungszwecken zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der weiter unten beschriebenen Ausführungsformen der Erfindung bereitzustellen. Fachleuten ist jedoch offenkundig, dass die Ausführungsformen der Erfindung ohne einige dieser spezifischen Einzelheiten in die Praxis umgesetzt werden können. In anderen Fällen werden wohlbekannte Strukturen und Vorrichtungen in Blockdiagrammform gezeigt, um ein Verschleiern der zugrundeliegenden Prinzipien der Ausführungsformen der Erfindung zu vermeiden.
BEISPIELHAFTE GRAFIKPROZESSORARCHITEKTUREN UND DATENTYPEN
Systemübersicht
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. Das System 100 kann in einem Einzelprozessor-Desktop-System, einem Multiprozessor-Arbeitsplatzsystem oder einem Serversystem mit einer großen Anzahl von Prozessoren 102 oder Prozessorkernen 107 verwendet werden. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die innerhalb einer integrierten System-on-Chip(SoC)-Schaltung zur Verwendung in mobilen, handgehaltenen oder eingebetteten Vorrichtungen, wie etwa innerhalb von Internet-of-Things(IoT)-Vorrichtungen mit drahtgebundener oder drahtloser Konnektivität zu einem lokalen oder Weitverkehrsnetzwerk, integriert ist.
In einer Ausführungsform kann das System 100 eine serverbasierte Spielplattform; eine Spielkonsole, einschließlich einer Spiel- und Medienkonsole; eine mobile Spielkonsole, eine handgehaltene Spielkonsole oder eine Online-Spielkonsole aufweisen, mit dieser gekoppelt oder darin integriert sein. In einigen Ausführungsformen ist das System 100 Teil eines Mobiltelefons, Smartphones, Tablet-Rechengeräts oder eines mobilen internetverbundenen Geräts, wie etwa eines Laptops mit niedriger interner Speicherkapazität. Das Verarbeitungssystem 100 kann auch Folgendes aufweisen, damit koppeln oder darin integriert sein: eine tragbare Vorrichtung, wie etwa eine tragbare Smartwatch-Vorrichtung; eine intelligente Brille oder Kleidung, die mit Augmented-Reality(AR)- oder Virtual-Reality(VR)-Merkmalen verbessert ist, um visuelle, Audio- oder taktile Ausgaben bereitzustellen, um visuelle, Audio- oder taktile Reale-Welt-Erfahrungen zu ergänzen oder anderweitig Text, Audio, Grafiken, Video, holographische Bilder oder Video oder taktiles Feedback bereitzustellen; eine andere Augmented-Reality(AR)-Vorrichtung; oder eine andere Virtual-Reality(VR)-Vorrichtung. In einigen Ausführungsformen weist das Verarbeitungssystem 100 ein Fernseh- oder Set-Top-Box-Gerät auf oder ist Teil davon. In einer Ausführungsform kann das System 100 ein selbstfahrendes Fahrzeug, wie etwa einen Bus, einen Zugmaschinenanhänger, ein Auto, einen Motor oder ein elektrisches Leistungsrad, ein Flugzeug oder einen Gleiter (oder eine beliebige Kombination davon), aufweisen, mit diesem gekoppelt oder in diesem integriert sein. Das selbstfahrende Fahrzeug kann das System 100 verwenden, um die Umgebung zu verarbeiten, die um das Fahrzeug herum erfasst wird.
In einigen Ausführungsformen weisen der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 zum Verarbeiten von Anweisungen, die, wenn sie ausgeführt werden, Operationen für System- oder Benutzersoftware durchführen, auf. In einigen Ausführungsformen ist mindestens einer des einen oder der mehreren Prozessorkerne 107 dazu ausgelegt, einen spezifischen Anweisungssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Anweisungssatz 109 komplexes Anweisungssatzrechnen (CISC), reduziertes Anweisungssatzrechnen (RISC) oder Berechnen über ein sehr langes Anweisungswort (VLIW) ermöglichen. Ein oder mehrere Prozessorkerne 107 können einen anderen Anweisungssatz 109 verarbeiten, der Anweisungen zum Ermöglichen der Emulation anderer Anweisungssätze aufweisen kann. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen aufweisen, wie etwa einen digitalen Signalprozessor (DSP).
In einigen Ausführungsformen weist der Prozessor 102 einen Cache-Speicher 104 auf. In Abhängigkeit von der Architektur kann der Prozessor 102 einen einzigen internen Cache oder mehrere Ebenen von internem Cache aufweisen. In einigen Ausführungsformen wird der Cache-Speicher von verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z. B. einen Level-3(L3)-Cache oder Last-Level-Cache (LLC)) (nicht gezeigt), der unter Verwendung bekannter Cache-Kohärenztechniken von Prozessorkernen 107 gemeinsam genutzt werden kann. Eine Registerdatei 106 kann zusätzlich in dem Prozessor 102 enthalten sein und kann verschiedene Arten von Registern zum Speichern verschiedener Arten von Daten (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister) aufweisen. Manche Register können Universalregister 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 etwa Adress-, 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 sein, wie etwa eine Version des DMI-Busses (DMI: Direct Media Interface). Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral Component Interconnect Busse (z. B. PCI, PCI-Express), Speicherbusse oder andere Arten von Schnittstellenbussen umfassen. In einer Ausführungsform weisen der eine oder die mehreren Prozessoren 102 eine integrierte Speichersteuerung 116 und einen Plattformsteuerungs-Hub 130 auf. Die Speichersteuerung 116 ermöglicht eine Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der Plattformsteuerungshub (PCH: Plattform Controller Hub) 130 Verbindungen zu E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Speichervorrichtung 120 kann eine Dynamischer-Direktzugriffsspeicher(DRAM)-Vorrichtung, eine Statischer-Direktzugriffsspeicher(SRAM)-Vorrichtung, eine Flash-Speichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Speichervorrichtung sein, die eine geeignete Leistungsfähigkeit aufweist, um als ein Prozessspeicher zu dienen. In einer Ausführungsform kann die Speichervorrichtung 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 einem optionalen externen Grafikprozessor 118 gekoppelt, der mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen können Grafik-, Medien- und/oder Rechenoperationen durch einen Beschleuniger 112 unterstützt werden, der ein Coprozessor ist, der dazu konfiguriert sein kann, einen spezialisierten Satz von Grafik-, Medien- oder Rechenoperationen durchzuführen. In einer Ausführungsform ist der Beschleuniger 112 zum Beispiel ein Matrixmultiplikationsbeschleuniger, der verwendet wird, um Maschinenlern- oder Rechenoperationen zu optimieren. In einer Ausführungsform ist der Beschleuniger 112 ein Strahlverfolgungsbeschleuniger, der verwendet werden kann, um Strahlverfolgungsoperationen in Übereinstimmung mit dem Grafikprozessor 108 durchzuführen. In einer Ausführungsform kann ein externer Beschleuniger 119 anstelle des Beschleunigers 112 oder zusammen mit diesem verwendet werden.
In einigen Ausführungsformen kann eine Anzeigevorrichtung 111 mit dem einen oder den mehreren Prozessoren 102 verbunden sein. Die Anzeigevorrichtung 111 kann eine interne Anzeigevorrichtung, wie in einer mobilen elektronischen Vorrichtung oder einer Laptopvorrichtung, und/oder eine externe Anzeigevorrichtung sein, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angeschlossen ist. In einer Ausführungsform kann die Anzeigevorrichtung 111 eine am Kopf befestigte Anzeige (HMD: Head Mounted Display) sein, wie etwa eine stereoskopische Anzeigevorrichtung zur Verwendung bei Virtual-Reality(VR)-Anwendungen oder Augmented-Reality(AR)-Anwendungen.
In einigen Ausführungsformen ermöglicht der Plattformsteuerungshub 130, dass Peripheriegeräte über einen Hochgeschwindigkeits-E/A-Bus eine Verbindung mit der Speichervorrichtung 120 und dem Prozessor 102 herstellen. Die E/A-Peripheriegeräte umfassen unter anderem eine Audiosteuerung 146, eine Netzwerksteuerung 134, eine Firmwareschnittstelle 128, einen drahtlosen Sendeempfänger 126, Berührungssensoren 125, eine Datenspeicherungsvorrichtung 124 (z. B. nichtflüchtigen Speicher, flüchtigen Speicher, Festplattenlaufwerk, Flash-Speicher, NAND, 3D-NAND, 3D-XPoint usw.). Die Datenspeicherungsvorrichtung 124 kann über eine Speicherungsschnittstelle (z. B. SATA) oder über einen Peripheriebus, wie etwa einen Peripheral-Component-Interconnect-Bus (z. B. PCI, PCI Express), verbunden sein. Die Berührungssensoren 125 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren umfassen. Der drahtlose Sendeempfänger 126 kann ein WiFi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein Mobilnetz-Sendeempfänger sein, wie etwa ein 3G-, 4G-, 5G- oder Long-Term-Evolution(LTE)-Sendeempfänger. Die Firmwareschnittstelle 128 ermöglicht eine Kommunikation mit System-Firmware und kann zum Beispiel eine vereinheitlichte erweiterbare Firmwareschnittstelle (UEFI: Unified Extensible Firmware Interface) sein. Die Netzwerksteuerung 134 kann eine Netzwerkverbindung zu einem drahtgebundenen Netzwerk ermöglichen. In einigen Ausführungsformen ist eine (nicht gezeigte) Hochleistungsnetzwerksteuerung mit dem Schnittstellenbus 110 gekoppelt. Die Audio-Steuerung 146 ist in einer Ausführungsform eine Mehrkanal-High-Definition-Audio-Steuerung. In einer Ausführungsform weist das System 100 eine optionale Legacy-E/A-Steuerung 140 zum Koppeln von Legacy(z. B. Personal System 2 (PS/2))-Vorrichtungen mit dem System auf. Der Plattformsteuerungshub 130 kann auch mit einer oder mehreren USB(Universal-Serial-Bus)-Steuerungen 142 verbunden sein, welche Eingabevorrichtungen, wie etwa Kombinationen aus Tastatur und Maus 143, eine Kamera 144 oder andere USB-Eingabevorrichtungen, verbinden.
Es versteht sich, dass das gezeigte System 100 beispielhaft und nicht beschränkend ist, da auch andere Arten von Datenverarbeitungssystemen verwendet werden können, die unterschiedlich konfiguriert sind. Zum Beispiel kann eine Instanz der Speichersteuerung 116 und des Plattformsteuerungs-Hubs 130 in einen diskreten externen Grafikprozessor, wie etwa den externen Grafikprozessor 118, integriert sein. In einer Ausführungsform können sich der Plattformsteuerungs-Hub 130 und/oder die Speichersteuerung 116 außerhalb des einen oder der mehreren Prozessoren 102 befinden. Das System 100 kann zum Beispiel eine externe Speichersteuerung 116 und einen Plattformsteuerungs-Hub 130 aufweisen, die als ein Speichersteuerungs-Hub und ein Peripheriesteuerungs-Hub innerhalb eines System-Chipsatzes konfiguriert sein können, der mit dem einen oder den mehreren Prozessoren 102 in Kommunikation steht.
Zum Beispiel können Leiterplatten („Schlitten“) verwendet werden, auf denen Komponenten, wie etwa CPUs, Speicher und andere Komponenten, platziert sind, die für eine erhöhte thermische Leistungsfähigkeit gestaltet sind. Bei manchen Beispielen befinden sich Verarbeitungskomponenten, wie etwa die Prozessoren, auf einer Oberseite eines Schlittens, während sich Nahspeicher, wie etwa DIMMs, auf einer Unterseite des Schlittens befinden. Infolge des verbesserten Luftstroms, der durch diese Gestaltung bereitgestellt wird, können die Komponenten bei höheren Frequenzen und Leistungspegeln als in typischen Systemen arbeiten, wodurch die Leistungsfähigkeit erhöht wird. Ferner sind die Schlitten dazu konfiguriert, blind mit Strom- und Datenkommunikationskabeln in einem Rack zusammenzupassen, wodurch ihre Fähigkeit verbessert wird, schnell entfernt, aufgerüstet, wieder installiert und/oder ersetzt zu werden. Gleichermaßen sind einzelne Komponenten, die sich auf den Schlitten befinden, wie etwa Prozessoren, Beschleuniger, Speicher- und Datenspeicherungslaufwerke, dazu konfiguriert, aufgrund ihrer erhöhten Beabstandung voneinander leicht aufgerüstet zu werden. In der veranschaulichenden Ausführungsform umfassen die Komponenten zusätzlich Hardwarebescheinigungsmerkmale, um ihre Authentizität nachzuweisen.
Ein Datenzentrum kann eine einzelne Netzwerkarchitektur („Fabric“) nutzen, die mehrere andere Netzwerkarchitekturen einschließlich Ethernet und Omni-Pfad unterstützt. Die Schlitten können über optische Fasern mit Schaltern gekoppelt sein, die eine höhere Bandbreite und eine niedrigere Latenz als eine typische Twisted-Pair-Verkabelung (z. B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.) bereitstellen. Aufgrund der Verbindungen mit hoher Bandbreite, niedriger Latenz und Netzwerkarchitektur kann das Datenzentrum im Gebrauch Ressourcen, wie etwa Speicher, Beschleuniger (z. B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, neuronale Netzwerk- und/oder Beschleuniger mit künstlicher Intelligenz usw.) und Datenspeicherungslaufwerke, die physisch zerlegt sind, bündeln und sie Rechenressourcen (z. B. Prozessoren) nach Bedarf bereitstellen, wodurch ermöglicht wird, dass die Rechenressourcen auf die gebündelten Ressourcen zugreifen, als wären sie lokal.
Eine Leistungsversorgung oder -quelle kann Spannung und/oder Strom an das System 100 oder eine beliebige Komponente oder ein beliebiges hierin beschriebenes System liefern. Bei einem Beispiel umfasst die Stromversorgung einen AC/DC(Wechselstrom zu Gleichstrom)-Adapter zum Einstecken in eine Wandsteckdose. Einer solche AC-Strom kann eine Leistungsquelle mit erneuerbarer Energie (z. B. Solarstrom) sein. In einem Beispiel umfasst die Leistungsquelle eine DC-Stromquelle, wie etwa einen externen AC/DC-Wandler. In einem Beispiel umfasst eine Leistungsquelle oder eine Leistungsversorgung Drahtlosladehardware zum Laden über die Nähe zu einem Ladefeld. In einem Beispiel kann die Leistungsquelle eine interne Batterie, eine Wechselstromversorgung, eine bewegungsbasierte Leistungsversorgung, eine Solarenergieversorgung oder eine Brennstoffzellenquelle umfassen.
Die 2A-2D veranschaulichen Rechensysteme und Grafikprozessoren, die durch hier beschriebene Ausführungsformen bereitgestellt werden. Die Elemente aus den 2A-2D mit den gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin können auf eine beliebige ähnliche Weise wie jene arbeiten oder funktionieren, die an anderer Stelle hierin beschrieben ist, sind aber nicht darauf beschränkt.
2A ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200, der einen oder mehrere Prozessorkerne 202A-202N, eine integrierte Speichersteuerung 214 und einen integrierten Grafikprozessor 208 aufweist. Der Prozessor 200 kann zusätzliche Kerne bis zu und einschließlich des zusätzlichen Kerns 202N aufweisen, der durch die gestrichelten Kästchen repräsentiert ist. Jeder der Prozessorkerne 202A-202N weist eine oder mehrere interne Cacheeinheiten 204A-204N auf. In einigen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf eine oder mehrere gemeinsam genutzte zwischengespeicherte Einheiten 206. Die internen Cache-Einheiten 204A-204N und gemeinsam genutzten Cache-Einheiten 206 stellen eine Cache-Speicherhierarchie innerhalb des Prozessors 200 dar. Die Cache-Speicherhierarchie kann mindestens eine Ebene von Anweisungs- und Daten-Cache innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen von gemeinsam genutztem Mittelebenen-Cache, wie etwa eine Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder andere Cache-Ebenen, aufweisen, wobei die höchste Cache-Ebene vor dem externen Speicher als der LLC klassifiziert wird. In einigen Ausführungsformen bewahrt eine Cachekohärenzlogik die Kohärenz zwischen den verschiedenen Cacheeinheiten 206 und 204A-204N.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von einer oder mehreren Buscontrollereinheiten 216 und einen Systemagentenkern 210 aufweisen. Die eine oder die mehreren Buscontrollereinheiten 216 verwalten einen Satz von Peripheriebussen, wie etwa einen oder mehrere PCI- oder PCI-express-Busse. Der Systemagentenkern 210 stellt eine Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. In einigen Ausführungsformen weist der Systemagentenkern 210 eine oder mehrere integrierte Speichersteuerungen 214 auf, um den Zugriff auf verschiedene externe Speichervorrichtungen (nicht gezeigt) zu verwalten.
In einigen Ausführungsformen weisen einer oder mehrere der Prozessorkerne 202A-202N Unterstützung für simultanes Multithreading auf. In einer solchen Ausführungsform weist der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A-202N während der Multithreading-Verarbeitung auf. Der Systemagentenkern 210 kann zusätzlich eine Leistungssteuereinheit (PCU) aufweisen, die Logik und Komponenten zum Regeln des Leistungszustands der Prozessorkerne 202A-202N und des Grafikprozessors 208 aufweist.
In einigen Ausführungsformen weist der Prozessor 200 zusätzlich einen Grafikprozessor 208 auf, um Grafikverarbeitungsoperationen auszuführen. In einigen Ausführungsformen ist der Grafikprozessor 208 mit dem Satz gemeinsam genutzter Cache-Einheiten 206 und dem Systemagentenkern 210, der die eine oder die mehreren integrierten Speichersteuerungen 214 aufweist, gekoppelt. In einigen Ausführungsformen weist der Systemagentenkern 210 auch eine Anzeigesteuerung 211 zum Ansteuern einer Grafikprozessorausgabe zu einer oder mehreren gekoppelten Anzeigen auf. In einigen Ausführungsformen kann die Anzeigesteuerung 211 auch ein separates Modul sein, das über mindestens eine Verbindung mit dem Grafikprozessor 208 gekoppelt ist, oder kann in den Grafikprozessor 208 integriert sein.
In einigen Ausführungsformen wird eine ringbasierte Zwischenverbindungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Jedoch kann eine alternative Zwischenverbindungseinheit verwendet werden, wie etwa eine Punkt-zu-Punkt-Zwischenverbindung, eine geschaltete Zwischenverbindung oder andere Techniken, einschließlich Techniken, die in der Technik wohlbekannt sind. In einigen Ausführungsformen ist der Grafikprozessor 208 über eine E/A-Verbindung 213 mit einer E/A-Verknüpfung 212 gekoppelt.
Die beispielhafte E/A-Verknüpfung 213 repräsentiert mindestens eine von mehreren Varianten von E/A-Zwischenverbindungen, einschließlich einer Package-E/A-Zwischenverbindung, die eine Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsspeichermodul 218, wie etwa einem eDRAM-Modul, ermöglicht. In einigen Ausführungsformen kann jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als einen gemeinsam genutzten Last-Level-Cache verwenden.
In einigen Ausführungsformen handelt es sich bei den Prozessorkernen 202A-202N um homogene Kerne, die dieselbe Anweisungssatzarchitektur ausführen. In einer weiteren Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Anweisungssatzarchitektur (ISA: Instruction Set Architecture) heterogen, wobei einer oder mehrere der Prozessorkerne 202A-202N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Mikroarchitektur heterogen, wobei ein oder mehrere Kerne mit einer relativ höheren Leistungsaufnahme mit einem oder mehreren Leistungskernen mit einer geringeren Leistungsaufnahme gekoppelt sind. In einer Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Rechenleistung heterogen. 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 sein.
2B ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns 219 gemäß einigen hierin beschriebenen Ausführungsformen. Elemente aus 2B mit den gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin können auf eine beliebige ähnliche Weise wie jene arbeiten oder funktionieren, die an anderer Stelle hierin beschrieben ist, sind aber nicht darauf beschränkt. Der Grafikprozessorkern 219, manchmal als Kern-Slice bezeichnet, kann ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 219 ist beispielhaft für einen Grafikkern-Slice, und ein Grafikprozessor, wie hier beschrieben, kann mehrere Grafikkern-Slices basierend auf Zielleistungs- und Leistungsfähigkeitseinhüllenden aufweisen. Jeder Grafikprozessorkern 219 kann einen Festfunktionsblock 230 aufweisen, der mit mehreren Unterkernen 221A-221F, die auch als Unter-Slices bezeichnet werden, gekoppelt ist, die modulare Blöcke von Universal- und Festfunktionslogik aufweisen.
In einigen Ausführungsformen weist der Festfunktionsblock 230 eine Geometrie/Festfunktions-Pipeline 231 auf, die von allen Unterkernen in dem Grafikprozessorkern 219 gemeinsam genutzt werden kann, zum Beispiel bei Grafikprozessorimplementierungen mit niedrigerer Leistungsfähigkeit und/oder niedrigerer Leistung. In verschiedenen Ausführungsformen weist die Geometrie/Festfunktions-Pipeline 231 eine 3D-Festfunktions-Pipeline (z. B. 3D-Pipeline 312 wie in 3 und 4, unten beschrieben), eine Video-Frontend-Einheit, einen Thread-Spawner und Thread-Dispatcher und einen einheitlichen Rückkehrpuffer-Manager, der einheitliche Rückkehrpuffer (z. B. den einheitlichen Rückkehrpuffer 418 in 4, unten beschrieben) verwaltet.
In einer Ausführungsform weist der Festfunktionsblock 230 auch eine Grafik-SoC-Schnittstelle 232, einen Grafikmikrocontroller 233 und eine Medien-Pipeline 234 auf. Die Grafik-SoC-Schnittstelle 232 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 219 und anderen Prozessorkernen innerhalb einer integrierten System-on-Chip-Schaltung bereit. Der Grafikmikrocontroller 233 ist ein programmierbarer Subprozessor, der konfigurierbar ist, um verschiedene Funktionen des Grafikprozessorkerns 219 zu verwalten, einschließlich Threadversand, Planung und Präemption. Die Medien-Pipeline 234 (z. B. die Medien-Pipeline 316 von 3 und 4) weist Logik zum Ermöglichen des Decodierens, Codierens, Vorverarbeitens und/oder Nachverarbeitens von Multimediadaten, einschließlich Bild- und Videodaten auf. Die Medien-Pipeline 234 implementiert Medienoperationen über Anforderungen zum Berechnen oder Abtasten von Logik innerhalb der Unterkerne 221-221F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 dem Grafikprozessorkern 219, mit Universalanwendungsprozessorkernen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC zu kommunizieren, einschließlich Speicherhierarchieelementen, wie etwa einem gemeinsam genutzten Last-Level-Cache-Speicher, dem System-RAM und/oder eingebettetem On-Chip- oder On-Package-DRAM. Die SoC-Schnittstelle 232 kann auch eine Kommunikation mit Festfunktionsvorrichtungen innerhalb des SoC ermöglichen, wie etwa Kamerabildgebungspipelines, und ermöglicht die Verwendung und/oder implementiert globale Speicheratomik, die zwischen dem Grafikprozessorkern 219 und CPUs innerhalb des SoC gemeinsam genutzt werden kann. Die SoC-Schnittstelle 232 kann auch Leistungsverwaltungssteuerungen für den Grafikprozessorkern 219 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 219 und anderen Taktdomänen innerhalb des SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 den Empfang von Befehlspuffern von einem Befehlsstreamer und einem globalen Thread-Dispatcher, die dazu konfiguriert 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 234 gesendet werden, wenn Medienoperationen durchzuführen sind, oder eine Geometrie- und Festfunktions-Pipeline (z. B. die Geometrie- und Festfunktions-Pipeline 231, die Geometrie- und Festfunktions-Pipeline 237), wenn Grafikverarbeitungsoperationen durchzuführen sind.
Der Grafikmikrocontroller 233 kann dazu konfiguriert sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 219 durchzuführen. In einer Ausführungsform kann der Grafikmikrocontroller 233 Grafik- und/oder Rechenarbeitslastplanung auf den verschiedenen parallelen Grafik-Engines innerhalb von Ausführungseinheit(EU)-Arrays 222A-222F, 224A-224F innerhalb der Unterkerne 221A-221F durchführen. In diesem Planungsmodell kann Hostsoftware, die auf einem CPU-Kern eines SoC einschließlich des Grafikprozessorkerns 219 ausgeführt wird, Arbeitslasten einer von mehreren Grafikprozessortüren einreichen, was eine Planungsoperation auf der geeigneten Grafik-Engine aufruft. Planungsoperationen umfassen das Bestimmen, welche Arbeitslast als nächstes ausgeführt werden soll, das Einreichen einer Arbeitslast an einen Befehlsstreamer, das Präemptieren bestehender Arbeitslasten, die auf einer Engine ausgeführt werden, das Überwachen des Fortschritts einer Arbeitslast und das Benachrichtigen von Hostsoftware, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Grafikmikrocontroller 233 auch Niedrigleistungs- oder Ruhezustände für den Grafikprozessorkern 219 ermöglichen, wodurch dem Grafikprozessorkern 219 die Fähigkeit gegeben wird, Register innerhalb des Grafikprozessorkerns 219 über Niedrigleistungszustandsübergänge unabhängig von dem Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
Der Grafikprozessorkern 219 kann mehr als oder weniger als die veranschaulichten Unterkerne 221A-221F aufweisen, bis zu N modulare Unterkerne. Für jeden Satz von N Unterkernen kann der Grafikprozessorkern 219 auch Logik 235 mit gemeinsam genutzter Funktion, gemeinsam genutzten und/oder Cache-Speicher 236, eine Geometrie/Festfunktions-Pipeline 237 sowie zusätzliche Festfunktions-Logik 238 zum Beschleunigen verschiedener Grafik- und Rechenverarbeitungsoperationen aufweisen. Die Logik 235 mit gemeinsam genutzter Funktion kann Logikeinheiten aufweisen, die mit der Logik 420 mit gemeinsam genutzter Funktion aus 4 (z. B. Sampler-, Mathematik- und/oder Inter-Thread-Kommunikationslogik) assoziiert sind, die von jedem N Unterkern innerhalb des Grafikprozessorkerns 219 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 236 kann ein Last-Level-Cache für den Satz von N Unterkernen 221A-221F innerhalb des Grafikprozessorkerns 219 sein und kann auch als gemeinsam genutzter Speicher dienen, auf den mehrere Unterkerne zugreifen können. Die Geometrie-/Festfunktionspipeline 237 kann anstelle der Geometrie-/Festfunktionspipeline 231 innerhalb des Festfunktionsblocks 230 enthalten sein und die gleichen oder ähnliche Logikeinheiten aufweisen.
In einer Ausführungsform weist der Grafikprozessorkern 219 zusätzliche Festfunktionslogik 238 auf, die verschiedene Festfunktionsbeschleunigungslogik zur Verwendung durch den Grafikprozessorkern 219 aufweisen kann. In einer Ausführungsform weist die zusätzliche Festfunktionslogik 238 eine zusätzliche Geometrie-Pipeline zur Verwendung beim Nur-Positions-Shading auf. Beim Nur-Positions-Shading existieren zwei Geometrie-Pipelines, die vollständige Geometrie-Pipeline innerhalb der Geometrie-/Festfunktions-Pipeline 238, 231 und eine Aussonderungs-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Festfunktionslogik 238 enthalten sein kann. In einer Ausführungsform ist die Aussonderungs-Pipeline eine heruntergetrimmte Version der Vollgeometrie-Pipeline. Die vollständige Pipeline und die Aussonderungs-Pipeline können verschiedene Instanzen derselben Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Das Nur-Position-Shading kann lange Aussonderungsläufe von verworfenen Dreiecken verdecken, wodurch ermöglicht wird, dass das Shading in manchen Fällen früher abgeschlossen wird. Zum Beispiel kann in einer Ausführungsform die Aussonderungs-Pipeline-Logik innerhalb der zusätzlichen Festfunktionslogik 238 Positions-Shader parallel zu der Hauptanwendung ausführen und erzeugt im Allgemeinen kritische Ergebnisse schneller als die volle Pipeline, wenn die Aussonderungs-Pipeline nur das Positionsattribut der Vertices abruft und schattiert, ohne eine Rasterung und ein Rendern der Pixel in den Framepuffer durchzuführen. Die Aussonderungs-Pipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, ohne Rücksicht darauf, ob diese Dreiecke ausgesondert werden. Die volle Pipeline (die in diesem Fall als eine Wiedergabe-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verbrauchen, um die ausgesonderten Dreiecke zu überspringen, um nur die sichtbaren Dreiecke zu schattieren, die schließlich an die Rasterisierungsphase übergeben werden.
In einer Ausführungsform kann die zusätzliche Festfunktionslogik 238 auch Maschinenlernbeschleunigungslogik, wie etwa Festfunktionsmatrix-Multiplikationslogik, für Implementierungen, einschließlich Optimierungen für Maschinenlerntraining oder Inferenz, umfassen.
Innerhalb jedes Grafik-Unterkerns 221A-221F weist einen Satz von Ausführungsressourcen auf, die verwendet werden können, um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen durch Grafik-Pipeline, Medien-Pipeline oder Shader-Programme durchzuführen. Die Grafik-Unterkerne 221A-221F weisen mehrere EU-Arrazs 222A-222F, 224A-224F, Thread-Dispatch and Inter-Thread-Kommunikations(TD/IC)-logik 223A-223F, einen 3D-Sampler (z. B. Textur) 225A-225F, einen Mediensampler 206A-206F, einen Shader-Prozessor 227A-227F und gemeinsam genutzten lokalen Speicher (SLM) 228A-228F auf. Die EU-Arrays 222A-222F, 224A-224F weisen jeweils mehrere Ausführungseinheiten auf, die Universal-Grafikverarbeitungseinheiten sind, die in der Lage sind, Gleitkomma- und Ganzzahl-/Festkomma-Logikoperationen beim Dienst einer Grafik-, Medien- oder Rechenoperation, einschließlich Grafik-, Medien- oder Rechen-Shader-Programmen, durchzuführen. Die TD/IC-Logik 223A-223F führt lokale Thread-Dispatch- und Thread-Steueroperationen für die Ausführungseinheiten innerhalb eines Unterkerns durch und erleichtert die Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Unterkerns ausgeführt werden. Der 3D-Sampler 225A-225F kann Textur oder andere 3D-Grafik-bezogene Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten basierend auf einem konfigurierten Sample-Status und dem Texturformat, das mit einer gegebenen Textur assoziiert ist, unterschiedlich lesen. Der Mediensampler 206A-206F kann ähnliche Leseoperationen basierend auf dem Typ und Format, die mit Mediendaten assoziiert sind, durchführen. In einer Ausführungsform kann jeder Grafik-Unterkern 221A-221F abwechselnd einen einheitlichen 3D- und einen Medien-Sampler aufweisen. Threads, die auf den Ausführungseinheiten innerhalb jedes der Unterkerne 221A-221F ausgeführt werden, können gemeinsam genutzten lokalen Speicher 228A-228F innerhalb jedes Unterkerns verwenden, um Threads, die innerhalb einer Thread-Gruppe ausgeführt werden, zu ermöglichen, unter Verwendung eines gemeinsamen Pools von On-Chip-Speicher ausgeführt zu werden.
2C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 239, die dedizierte Sätze von Grafikverarbeitungsressourcen aufweist, die in Mehrkerngruppen 240A-240N angeordnet sind. Während die Einzelheiten lediglich einer einzigen Mehrkerngruppe 240A bereitgestellt sind, versteht es sich, dass die anderen Mehrkerngruppen 240B-240N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können.
Wie veranschaulicht, kann eine Mehrkerngruppe 240A einen Satz von Grafikkernen 243, einen Satz von Tensorkernen 244 und einen Satz von Strahlverfolgungskernen 245 aufweisen. Ein Scheduler/Dispatcher 241 plant und sendet die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 243, 244, 245 aus. Ein Satz von Registerdateien 242 speichert Operandenwerte, die von den Kernen 243, 244, 245 verwendet werden, wenn die Grafik-Threads ausgeführt werden. Diese können zum Beispiel Ganzzahlregister zum Speichern von Ganzzahlwerten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern von gepackten Datenelementen (Ganzzahl- und/oder Gleitkommadatenelementen) und Kachelregister zum Speichern von Tensor-/Matrixwerten umfassen. In einer Ausführungsform sind die Kachelregister als kombinierte Sätze von Vektorregistern implementiert.
Ein oder mehrere kombinierte Level-1(L1)-Caches und gemeinsam genutzte Speichereinheiten 247 speichern Grafikdaten, wie Texturdaten, Vertexdaten, Pixeldaten, Strahldaten, Hüllkörperdaten usw., lokal innerhalb jeder Mehrkerngruppe 240A. Eine oder mehrere Textureinheiten 247 können auch verwendet werden, um Texturierungsoperationen, wie etwa Texturabbildung und Abtastung, durchzuführen. Ein Level-2(L2)-Cache 253, der durch alle oder eine Teilmenge der Mehrkerngruppen 240A-240N gemeinsam genutzt wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafik-Threads. Wie veranschaulicht, kann der L2-Cache 253 über mehrere Mehrkerngruppen 240A-240N hinweg gemeinsam genutzt werden. Eine oder mehrere Speichersteuerungen 248 koppeln die GPU 239 mit einem Speicher 249, der ein Systemspeicher (z. B. DRAM) und/oder ein dedizierter Grafikspeicher (z. B. GDDR6-Speicher) sein kann.
Eine Eingabe/Ausgabe(E/A)-Schaltungsanordnung 250 koppelt die GPU 239 mit einer oder mehreren E/A-Vorrichtungen 252, wie etwa Digitalsignalprozessoren (DSPs), Netzwerksteuerungen oder Benutzereingabevorrichtungen. Eine On-Chip-Zwischenverbindung kann verwendet werden, um die E/A-Vorrichtungen 252 mit der GPU 239 und dem Speicher 249 zu koppeln. Eine oder mehrere E/A-Speicherverwaltungseinheiten (IOMMUs) 251 der E/A-Schaltungsanordnung 250 koppeln die E/A-Vorrichtungen 252 direkt mit dem Systemspeicher 249. In einer Ausführungsform verwaltet die IOMMU 251 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physische Adressen im Systemspeicher 249 abzubilden. In dieser Ausführungsform können die E/A-Vorrichtungen 252, die CPU(s) 246 und die GPU(s) 239 denselben virtuellen Adressraum gemeinsam nutzen.
In einer Implementierung unterstützt die IOMMU 251 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen dahingehend verwalten, virtuelle Gast-/Grafikadressen auf physische Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen dahingehend verwalten, die physischen Gast-/Grafikadressen auf physische System-/Hostadressen (z. B. innerhalb des Systemspeichers 249) abzubilden. Die Basisadressen sowohl des ersten als auch des zweiten Satzes von Seitentabellen können in Steuerregistern gespeichert werden und auf einem Kontextschalter (z. B., so dass dem neuen Kontext Zugriff auf den relevanten Satz von Seitentabellen bereitgestellt wird) ausgelagert werden. Obwohl dies in 2C nicht veranschaulicht ist, kann jeder der Kerne 243, 244, 245 und/oder die Mehrkerngruppen 240A-240N Übersetzungspuffer (TLBs: Translation Lookaside Buffer) aufweisen, um Gast-Virtuell-zu-Gast-Physisch-Übersetzungen, Gast-Physisch-zu-Host-Physisch-Übersetzungen und Gast-Virtuell-zu-Host-Physisch-Übersetzungen zwischenzuspeichern.
In einer Ausführungsform sind die CPUs 246, die GPUs 239 und die E/A-Vorrichtungen 252 auf einem einzigen Halbleiterchip und/oder Chip-Package integriert. Der veranschaulichte Speicher 249 kann auf demselben Chip integriert sein oder kann über eine chipexterne Schnittstelle mit den Speichersteuerungen 248 gekoppelt sein. Bei einer Implementierung umfasst der Speicher 249 einen GDDR6-Speicher, der denselben virtuellen Adressraum wie andere physische Systemebenenspeicher nutzt, obgleich die zugrundeliegenden Prinzipien der Erfindung nicht auf diese spezielle Implementierung beschränkt sind.
In einer Ausführungsform weisen die Tensorkerne 244 mehrere Ausführungseinheiten auf, die speziell zum Durchführen von Matrixoperationen, die die grundlegende Rechenoperation sind, die zum Durchführen von Deep-Learning-Operationen verwendet wird, ausgestaltet sind. Zum Beispiel können simultane Matrixmultiplikationsoperationen für neuronales Netzwerktraining und Inferenz verwendet werden. Die Tensorkerne 244 können eine Matrixverarbeitung unter Verwendung einer Vielzahl von Operandengenauigkeiten durchführen, einschließlich Gleitkomma mit einfacher Genauigkeit (z. B. 32 Bits), Gleitkomma mit halber Genauigkeit (z. B. 16 Bits), ganzzahligen Wörtern (16 Bits), Bytes (8 Bits) und Halbbytes (4 Bits). In einer Ausführungsform extrahiert eine Neuronalnetzwerk-Implementierung Merkmale jeder gerenderten Szene, wobei potentiell Details aus mehreren Frames kombiniert werden, um ein qualitativ hochwertiges Endbild zu konstruieren.
Bei Deep-Learning-Implementierungen kann eine Parallelmatrixmultiplikationsarbeit zur Ausführung auf den Tensorkernen 244 geplant werden. Insbesondere erfordert das Training neuronaler Netzwerke eine signifikante Anzahl an Matrixskalarproduktoperationen. Um eine Innenproduktformulierung einer N x N x N Matrixmultiplikation zu verarbeiten, können die Tensorkerne 244 mindestens N Skalarproduktverarbeitungselemente aufweisen. Bevor die Matrixmultiplikation beginnt, wird pro Zyklus für N Zyklen eine ganze Matrix in Kachelregister geladen und mindestens eine Spalte einer zweiten Matrix geladen. In jedem Zyklus gibt es N Skalarprodukte, die verarbeitet werden.
Matrixelemente können in Abhängigkeit von der speziellen Implementierung mit unterschiedlichen Genauigkeiten gespeichert werden, einschließlich 16-Bit-Wörtern, 8-Bit-Bytes (z. B. INT8) und 4-Bit-Halbbytes (z. B. INT4). Unterschiedliche Genauigkeitsmodi können für die Tensorkerne 244 spezifiziert werden, um sicherzustellen, dass die effizienteste Genauigkeit für unterschiedliche Arbeitslasten verwendet wird (z. B. wie etwa Inferenzieren von Arbeitslasten, die Quantisierung zu Bytes und Halbbytes tolerieren können).
In einer Ausführungsform beschleunigen die Strahlverfolgungskerne 245 Strahlverfolgungsoperationen sowohl für Echtzeit-Strahlverfolgungs- als auch für Nicht-Echtzeit-StrahlverfolgungsImplementierungen. Insbesondere weisen die Strahlverfolgungskerne 245 eine Strahltraversierungs-/Kreuzungsschaltungsanordnung zum Durchführen einer Strahltraversierung unter Verwendung von Bounding Volume Hierarchies (BVHs) und Identifizieren von Kreuzungen zwischen Strahlen und Primitiven, die innerhalb der BVH-Volumina eingeschlossen sind, auf. Die Strahlverfolgungskerne 245 können auch Schaltungen zum Durchführen von Tiefentest und -aussonderung (z. B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung) aufweisen. Bei einer Implementierung führen die Strahlverfolgungskerne 245 Traversierungs- und Schnittoperationen in Übereinstimmung mit den hier beschriebenen Bildentrauschungstechniken durch, von denen mindestens ein Teil auf den Tensorkernen 244 ausgeführt werden kann. In einer Ausführungsform implementieren die Tensorkerne 244 zum Beispiel ein neuronales Netzwerk mit tiefem Lernen, das durchzuführen ist, das einen lokalen Speicher 9010 (und/oder Systemspeicher) aufweist, der von den Strahlverfolgungskernen 245 erzeugte Frames entrauscht. Die CPU(s) 246, Grafikkerne 243 und/oder Strahlverfolgungskerne 245 können jedoch auch alle oder einen Teil der Entrauschungs- und/oder Tiefenlernalgorithmen implementieren.
Zusätzlich kann, wie oben beschrieben, ein verteilter Ansatz zum Entrauschen eingesetzt werden, bei dem sich die GPU 239 in einer Rechenvorrichtung befindet, die über ein Netzwerk oder eine Hochgeschwindigkeitsverbindung mit anderen Rechenvorrichtungen gekoppelt ist. In dieser Ausführungsform nutzen die miteinander verbundenen Rechenvorrichtungen gemeinsam neuronale Netzwerklern-/Trainingsdaten, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, eine Entrauschung für unterschiedliche Typen von Bildframes und/oder unterschiedliche Grafikanwendungen durchzuführen.
In einer Ausführungsform verarbeiten die Strahlverfolgungskerne 245 alle BVH-Traversierungen und Strahl-Primitiv-Schnittpunkte, was die Grafikkerne 243 daran hindert, mit tausenden Anweisungen pro Strahl überlastet zu werden. In einer Ausführungsform weist jeder Strahlverfolgungskern 245 einen ersten Satz spezialisierter Schaltungsanordnungen zum Durchführen von Begrenzungsrahmentests
(z. B. für Traversierungsoperationen) und einen zweiten Satz spezialisierter Schaltungsanordnungen zum Durchführen der Strahl-Dreieck-Schnittpunkttests (z. B. kreuzende Strahlen, die durchlaufen wurden) auf. Somit kann in einer Ausführungsform die Mehrkerngruppe 240A einfach eine Strahlsonde aussenden, und die Strahlverfolgungskerne 245 führen unabhängig Strahltraversierung und -schneidung durch und geben Trefferdaten (z. B. ein Treffer, kein Treffer, mehrere Treffer usw.) an den Thread-Kontext zurück. Die anderen Kerne 243, 244 werden freigegeben, um andere Grafik- oder Rechenarbeit durchzuführen, während die Strahlverfolgungskerne 245 die Traversierungs- und Schnittpunktoperationen durchführen.
In einer Ausführungsform weist jeder Strahlverfolgungskern 245 eine Traversiereinheit zum Durchführen von BVH-Prüfungsoperationen und eine Schnittpunkteinheit, die Strahl-Primitiv-Schnittpunkttests durchführt, auf. Die Schnittpunkteinheit erzeugt eine „Treffer“-, „Kein-Treffer“- oder „Mehrfachtreffer“-Antwort, die sie dem geeigneten Thread bereitstellt. Während der Traversierungs- und Kreuzungsoperationen werden die Ausführungsressourcen der anderen Kerne (z. B. Grafikkerne 243 und Tensorkerne 244) freigegeben, um andere Formen von Grafikarbeit durchzuführen.
In einer speziellen Ausführungsform, die unten beschrieben ist, wird ein hybrider Rasterung/Strahlverfolgungs-Ansatz verwendet, bei dem Arbeit zwischen den Grafikkernen 243 und Strahlverfolgungskernen 245 verteilt wird.
In einer Ausführungsform weisen die Strahlverfolgungskerne 245 (und/oder andere Kerne 243, 244) Hardwareunterstützung für einen Strahlverfolgungsanweisungssatz, wie etwa DirectX Ray Tracing (DXR) von Microsoft, der einen DispatchRays-Befehl aufweist, sowie Strahlerzeugung, Nächster-Treffer-, Beliebiger-Treffer- und Fehltreffer-Shader, die die Zuweisung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglichen, auf. Eine andere Strahlverfolgungsplattform, die durch die Strahlverfolgungskerne 245, Grafikkerne 243 und Tensorkerne 244 unterstützt werden kann, ist Vulkan 1.1.85. Es sei jedoch angemerkt, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf irgendeine spezielle Strahlverfolgungs-ISA beschränkt sind.
Im Allgemeinen können die verschiedenen Kerne 245, 244, 243 einen Strahlverfolgungsanweisungssatz unterstützen, der Anweisungen/Funktionen für Strahlerzeugung, Nächster-Treffer, Beliebiger-Treffer, Strahl-Primitiv-Schnittpunkt, Primitiv-weise und hierarchische Hüllquaderkonstruktion, Fehltreffer, Visit und Ausnahmen aufweist. Genauer gesagt umfasst eine Ausführungsform Strahlverfolgungsanweisungen zum Durchführen der folgenden Funktionen:

Strahlenerzeugung - Strahlenerzeugungsanweisungen können für jedes Pixel, jedes Sample oder jede andere benutzerdefinierte Arbeitszuweisung ausgeführt werden.
Nächster-Treffer - Eine Nächster-Treffer-Anweisung kann ausgeführt werden, um den nächstgelegenen Schnittpunkt eines Strahls mit Primitiven innerhalb einer Szene zu lokalisieren.
Beliebiger-Treffer - Eine Beliebiger-Treffer-Anweisung identifiziert mehrere Schnittpunkte zwischen einem Strahl und Primitiven innerhalb einer Szene, möglicherweise um einen neuen nächstgelegenen Schnittpunkt zu identifizieren.
Schnittpunkt - Eine Schnittpunktanweisung führt eine Strahl-Primitiv-Schnittpunktprüfung durch und gibt ein Ergebnis aus.
Pro-Primitiv-Bounding-Box-Konstruktion - Diese Anweisung baut einen Begrenzungsrahmen um ein gegebenes Primitiv oder eine gegebene Gruppe von Primitiven herum auf (z. B., wenn eine neue BVH- oder andere Beschleunigungsdatenstruktur aufgebaut wird).
Fehltreffer - gibt an, dass ein Strahl die gesamte Geometrie innerhalb einer Szene oder eine spezifizierte Region einer Szene verfehlt.
Visit - Gibt die Nachfolgevolumina an, die ein Strahl durchlaufen wird.
Ausnahmen - umfassen verschiedene Typen von Ausnahmehandhabern (z. B. aufgerufen für verschiedene Fehlerbedingungen).

2D ist ein Blockdiagramm einer Universal-Grafikverarbeitungseinheit (GPGPU) 270, die als ein Grafikprozessor und/oder Rechenbeschleuniger konfiguriert sein kann, gemäß hier beschriebenen Ausführungsformen. Die GPGPU 270 kann über einen oder mehrere System- und/oder Speicherbusse mit Hostprozessoren (z. B. einer oder mehreren CPUs 246) und Speicher 271, 272 verbunden sein. In einer Ausführungsform ist der Speicher 271 Systemspeicher, der mit der einen oder den mehreren CPU(n) 246 gemeinsam genutzt werden kann, während der Speicher 272 Vorrichtungsspeicher ist, der für die GPGPU 270 dediziert ist. In einer Ausführungsform können Komponenten innerhalb der GPGPU 270 und des Vorrichtungsspeichers 272 in Speicheradressen abgebildet werden, die für die eine oder die mehreren CPU(n) 246 zugänglich sind. Der Zugriff auf die Speicher 271 und 272 kann über eine Speichersteuerung 268 ermöglicht werden. In einer Ausführungsform weist die Speichersteuerung 268 eine interne Direktspeicherzugriff(DMA)-Steuerung 269 auf oder kann Logik zum Durchführen von Operationen aufweisen, die ansonsten durch eine DMA-Steuerung durchgeführt würden.
Die GPGPU 270 weist mehrere Cachespeicher, einschließlich eines L2-Caches 253, L1-Caches 254, eines Anweisungscaches 255 und eines gemeinsam genutzten Speichers 256, von dem mindestens ein Teil auch als Cachespeicher partitioniert werden kann, auf. Die GPGPU 270 weist außerdem mehrere Berechnungseinheiten 260A-260N auf. Jede Recheneinheit 260A-260N weist einen Satz von Vektorregistern 261, Skalarregistern 262, Vektorlogikeinheiten 263 und Skalarlogikeinheiten 264 auf. Die Recheneinheiten 260A-260N können auch einen lokalen gemeinsam genutzten Speicher 265 und einen Programmzähler 266 aufweisen. Die Recheneinheiten 260A-260N können mit einem konstanten Cache 267 gekoppelt werden, der zum Speichern von konstanten Daten verwendet werden kann, die Daten sind, die sich während der Ausführung eines Kernel- oder Shader-Programms, das auf der GPGPU 270 ausgeführt wird, nicht ändern. In einer Ausführungsform ist der konstante Cache 267 ein Skalardaten-Cache und zwischengespeicherte Daten können direkt in die Skalarregister 262 abgerufen werden.
Während des Betriebs können die eine oder die mehreren CPUs 246 Befehle in Register oder Speicher in der GPGPU 270 schreiben, die in einen zugänglichen Adressraum abgebildet wurde. Die Befehlsprozessoren 257 können die Befehle aus Registern oder dem Speicher lesen und bestimmen, wie diese Befehle innerhalb der GPGPU 270 verarbeitet werden.
Ein Thread-Dispatcher 258 kann dann verwendet werden, um Threads an die Recheneinheiten 260A-260N zu senden, um diese Befehle auszuführen. Jede Recheneinheit 260A-260N kann Threads unabhängig von den anderen Recheneinheiten ausführen. Zusätzlich dazu kann jede Recheneinheit 260A-260N unabhängig für eine bedingte Berechnung konfiguriert sein und kann die Ergebnisse der Berechnung bedingt an den Speicher ausgeben. Die Befehlsprozessoren 257 können die eine oder die mehreren CPUs 246 unterbrechen, wenn die übermittelten Befehle abgeschlossen sind.
Die 3A-3C veranschaulichen Blockdiagramme zusätzlicher Grafikprozessor- und Rechenbeschleunigerarchitekturen, die durch hier beschriebene Ausführungsformen bereitgestellt werden. Die Elemente aus den 3A-3C mit den gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin können auf eine beliebige ähnliche Weise wie jene arbeiten oder funktionieren, die an anderer Stelle hierin beschrieben ist, sind aber nicht darauf beschränkt.
3A ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen integriert ist, oder andere Halbleitervorrichtungen, wie etwa unter anderem Speichervorrichtungen oder Netzwerkschnittstellen. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die in dem Prozessorspeicher platziert sind. In einigen Ausführungsformen weist der Grafikprozessor 300 eine Speicherschnittstelle 314 auf, um auf Speicher zuzugreifen. Die Speicherschnittstelle 314 kann eine Schnittstelle zu lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam genutzten externen Caches und/oder zu Systemspeicher sein.
In einigen Ausführungsformen weist der Grafikprozessor 300 auch eine Anzeigesteuerung 302 auf, um Anzeigeausgabedaten zu einer Anzeigevorrichtung 318 zu steuern. Die Anzeigesteuerung 302 weist Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Zusammensetzung mehrerer Schichten von Video- oder Benutzeroberflächenelementen auf. Die Anzeigevorrichtung 318 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 318 eine am Kopf montierte Anzeigevorrichtung, wie etwa eine Virtual-Reality(VR)-Anzeigevorrichtung oder eine Augmented Reality(AR)-Anzeigevorrichtung. In einigen Ausführungsformen weist der Grafikprozessor 300 eine Video-Codec-Engine 306 zum Codieren, Decodieren oder Transcodieren von Medien zu, von oder zwischen einem oder mehreren Mediencodierformaten, einschließlich unter anderem MPEG(Moving Picture Experts Group)-Formaten, wie etwa MPEG-2, Advanced Video Coding(AVC)-Formaten wie H.264/MPEG-4 AVC, H.265/HEVC, Alliance for Open Media(AOMedia) VP8, VP9 sowie die Society of Motion Picture & Television Engineers (SMPTE) 421 M/VC-1 und Joint Photographic Experts Group(JPEG)-Formate wie JPEG und Motion JPEG(MJPEG)-Formate auf.
In einigen Ausführungsformen weist der Grafikprozessor 300 eine Blockbildübertragungs(BLIT)-Engine 304 auf, um zweidimensionale (2D) Rasterisiereroperationen durchzuführen, einschließlich zum Beispiel Bitgrenzblockübertragungen. In einer Ausführungsform werden jedoch 2D-Grafikoperationen unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungsengine (GPE) 310 durchgeführt. In einigen Ausführungsformen ist die GPE 310 eine Rechen-Engine zum Durchführen von Grafikoperationen, einschließlich dreidimensionaler (3D) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen weist die GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen, wie etwa Rendern dreidimensionaler Bilder und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen (z. B. Rechteck, Dreieck usw.) einwirken, auf. Die 3D-Pipeline 312 weist programmierbare und Festfunktionselemente, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungs-Threads an ein 3D-Medien-Subsystem 315 erzeugen, auf. Obwohl die 3D-Pipeline 312 verwendet werden kann, um Medienoperationen durchzuführen, umfasst eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316, die speziell verwendet wird, um Medienoperationen, wie etwa Video-Nachverarbeitung und Bildverbesserung, durchzuführen.
In einigen Ausführungsformen weist die Medien-Pipeline 316 Festfunktions- oder programmierbare Logikeinheiten auf, um eine oder mehrere spezialisierte Medienoperationen, wie etwa Videodecodierungsbeschleunigung, Videoentschachtelung und Videocodierungsbeschleunigung, anstelle oder im Auftrag der Video-Codec-Engine 306 durchzuführen. In einigen Ausführungsformen weist die Medien-Pipeline 316 zusätzlich eine Thread-Erzeugungseinheit auf, um Threads zur Ausführung auf dem 3D/Medien-Subsystem 315 zu erzeugen. Die erzeugten Threads führen Berechnungen für die Medienoperationen an einer oder mehreren Grafikausführungseinheiten durch, die in dem 3D/Medien-Subsystem 315 enthalten sind.
In einigen Ausführungsformen weist das 3D/Medien-Subsystem 315 Logik zum Ausführen von Threads auf, die durch die 3D-Pipeline 312 und die Medien-Pipeline 316 erzeugt werden. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanforderungen an das 3D/Medien-Subsystem 315, das Thread-Dispatch-Logik zum Arbitrieren und Dispatchen der verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen aufweist. Die Ausführungsressourcen weisen ein Array von Grafikausführungseinheiten zum Verarbeiten der 3D-Threads und Medien-Threads auf. In einigen Ausführungsformen weist das 3D/Media-Subsystem 315 einen oder mehrere interne Caches für Thread-Anweisungen und Daten auf. In einigen Ausführungsformen weist das Subsystem auch gemeinsam genutzten Speicher, einschließlich Registern und adressierbarem Speicher, um Daten zwischen Threads gemeinsam zu nutzen und Ausgangsdaten zu speichern, auf.
3B veranschaulicht einen Grafikprozessor 320 mit einer gekachelten Architektur gemäß hier beschriebenen Ausführungsformen. In einer Ausführungsform weist der Grafikprozessor 320 einen Grafikverarbeitungsengine-Cluster 322 auf, der mehrere Instanzen der Grafikverarbeitungsengine 310 von 3A innerhalb einer Grafik-Engine-Kachel 310A-310D aufweist. Jede Grafik-Engine-Kachel 310A-310D kann über einen Satz von Kachel-Interconnects 323A-323F verbunden sein. Jede Grafik-Engine-Kachel 310A-310D kann auch über Speicher-Interconnects 325A-325D mit einem Speichermodul oder einer Speichervorrichtung 326A-326D verbunden sein. Die Speichervorrichtungen 326A-326D können eine beliebige Grafikspeichertechnologie verwenden. Die Speichervorrichtungen 326A-326D können zum Beispiel Grafikspeicher mit doppelter Datenrate (GDDR: Graphics Double Data Rate) sein. Die Speichervorrichtungen 326A-326D sind in einer Ausführungsform Speicher(HBM)-Module mit hoher Bandbreite, die mit ihrer jeweiligen Grafik-Engine-Kachel 310A-310D on-Die sein können. In einer Ausführungsform sind die Speichervorrichtungen 326A-326D gestapelte Speichervorrichtungen, die auf ihrer jeweiligen Grafik-Engine-Kachel 310A-310D gestapelt werden können. In einer Ausführungsform befinden sich jede Grafik-Engine-Kachel 310A-310D und der assoziierte Speicher 326A-326D auf separaten Chiplets, die an einen Basis-Die oder ein Basissubstrat gebondet sind, wie ausführlicher in den 11B-11D beschrieben ist.
Der Grafikverarbeitungsengine-Cluster 322 kann mit einem On-Chip- oder On-Package-Fabric-Interconnect 324 verbunden sein. Das Fabric-Interconnect 324 kann die Kommunikation zwischen den Grafik-Engine-Kacheln 310A-310D und Komponenten wie dem Video-Codec 306 und einer oder mehreren Kopier-Engines 304 ermöglichen. Die Kopier-Engines 304 können verwendet werden, um Daten aus, in und zwischen den Speichervorrichtungen 326A-326D und dem Speicher, der sich außerhalb des Grafikprozessors 320 befindet (z. B. Systemspeicher), zu bewegen. Das Fabric-Interconnect 324 kann auch verwendet werden, um die Grafik-Engine-Kacheln 310A-310D miteinander zu verbinden. Der Grafikprozessor 320 kann optional eine Anzeigesteuerung 302 aufweisen, um eine Verbindung mit einer externen Anzeigevorrichtung 318 zu ermöglichen. Der Grafikprozessor kann auch als Grafik- oder Rechenbeschleuniger konfiguriert sein. In der Beschleunigerkonfiguration können die Anzeigesteuerung 302 und die Anzeigevorrichtung 318 weggelassen werden.
Der Grafikprozessor 320 kann über eine Host-Schnittstelle 328 mit einem Hostsystem verbunden sein. Die Host-Schnittstelle 328 kann eine Kommunikation zwischen dem Grafikprozessor 320, dem Systemspeicher und/oder anderen Systemkomponenten ermöglichen. Die Host-Schnittstelle 328 kann zum Beispiel ein PCI-Express-Bus oder eine andere Art von Hostsystemschnittstelle sein.
3C veranschaulicht einen Rechenbeschleuniger 330 gemäß hier beschriebenen Ausführungsformen. Der Rechenbeschleuniger 330 kann architektonische Ähnlichkeiten mit dem Grafikprozessor 320 aus 3B aufweisen und ist für die Rechenbeschleunigung optimiert. Ein Rechen-Engine-Cluster 332 kann einen Satz von Rechen-Engine-Kacheln 340A-340D aufweisen, die Ausführungslogik aufweisen, die für parallele oder vektorbasierte Universalrechenoperationen optimiert ist. In einigen Ausführungsformen weisen die Rechen-Engine-Kacheln 340A-340D keine Grafikverarbeitungslogik mit fester Funktion auf, obwohl in einer Ausführungsform eine oder mehrere der Rechen-Engine-Kacheln 340A-340D Logik zum Durchführen einer Medienbeschleunigung aufweisen können. Die Rechen-Engine-Kacheln 340A-340D können sich über Speicherverbindungen 325A-325D mit dem Speicher 326A-326D verbinden. Der Speicher 326A-326D und die Speicherverbindungen 325A-325D können eine ähnliche Technologie wie in dem Grafikprozessor 320 sein oder können unterschiedlich sein. Die Grafikrechen-Engine-Kacheln 340A-340D können auch über einen Satz von Kachelverbindungen 323A-323F miteinander verbunden sein und können mit einer Fabric-Verbindung 324 verbunden und/oder durch diese miteinander verbunden sein. In einer Ausführungsform weist der Rechenbeschleuniger 330 einen großen L3-Cache 336 auf, der als ein vorrichtungsumfassender Cache konfiguriert werden kann. Der Rechenbeschleuniger 330 kann auch über eine Host-Schnittstelle 328 auf ähnliche Weise wie der Grafikprozessor 320 aus 3B mit einem Host-Prozessor und einem Speicher verbunden sein.
Grafikverarbeitungsengine
4 ist ein Blockdiagramm einer Grafikverarbeitungsengine 410 eines Grafikprozessors gemäß einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungsengine (GPE) 410 eine Version der in 3A gezeigten GPE 310 und kann auch eine Grafik-Engine-Kachel 310A-310D aus 3B darstellen. Elemente aus 4 mit den gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin können auf eine beliebige ähnliche Weise wie jene arbeiten oder funktionieren, die an anderer Stelle hierin beschrieben ist, sind aber nicht darauf beschränkt. Zum Beispiel sind die 3D-Pipeline 312 und die Medien-Pipeline 316 von 3A veranschaulicht. Die Medien-Pipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und ist möglicherweise nicht explizit in der GPE 410 enthalten. 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 einem Befehlsstreamer 403 gekoppelt oder weist diesen auf, der der 3D-Pipeline 312 und/oder den Medien-Pipelines 316 einen Befehlsstrom bereitstellt. In einigen Ausführungsformen ist der Befehlsstreamer 403 mit Speicher gekoppelt, der Systemspeicher oder einer oder mehrere von internem Cache-Speicher und gemeinsam genutztem Cache-Speicher sein kann. In einigen Ausführungsformen empfängt der Befehlsstreamer 403 Befehle von dem Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medien-Pipeline 316. Die Befehle sind Direktiven, die aus 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 Stapelbefehlspuffer aufweisen, die Stapel mehrerer Befehle speichern. Die Befehle für die 3D-Pipeline 312 können auch Referenzen auf im Speicher gespeicherte Daten, wie etwa unter anderem Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316, umfassen. Die 3D-Pipeline 312 und die Medien-Pipeline 316 verarbeiten die Befehle und Daten durch Durchführen von Operationen über Logik innerhalb der jeweiligen Pipelines oder durch Senden eines oder mehrerer Ausführungs-Threads an ein Grafikkern-Array 414. In einer Ausführungsform weist das Grafikkern-Array 414 einen oder mehrere Blöcke von Grafikkernen (z. B. Grafikkern(en) 415A, Grafikkern(en) 415B) auf, wobei jeder Block einen oder mehrere Grafikkerne aufweist. Jeder Grafikkern weist einen Satz von Grafikausführungsressourcen auf, der Universal- und grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Rechenoperationen sowie Texturverarbeitung mit fester Funktion und/oder Maschinenlernen und Beschleunigungslogik mit künstlicher Intelligenz aufweist.
In verschiedenen Ausführungsformen kann die 3D-Pipeline 312 eine Festfunktions- und programmierbare Logik aufweisen, um ein oder mehrere Shader-Programme, wie etwa Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Rechen-Shader oder andere Shader-Programme, durch Verarbeiten der Anweisungen und Senden von Ausführungs-Threads an das Grafikkern-Array 414 zu verarbeiten. Das Grafikkern-Array 414 stellt einen einheitlichen Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shader-Programme bereit. Eine Mehrzweckausführungslogik (z. B. Ausführungseinheiten) innerhalb des Grafikkerns (der Grafikkerne) 415A-414B des Grafikkern-Arrays 414 weist Unterstützung für verschiedene 3D-API-Shader-Sprachen auf und kann mehrere gleichzeitige Ausführungs-Threads ausführen, die mehreren Shadern zugeordnet sind.
In einigen Ausführungsformen weist das Grafikkern-Array 414 Ausführungslogik zum Durchführen von Medienfunktionen, wie etwa Video- und/oder Bildverarbeitung, auf. In einer Ausführungsform weisen die Ausführungseinheiten Universallogik auf, die programmierbar ist, um parallele Universalrechenoperationen durchzuführen, zusätzlich zu Grafikverarbeitungsoperationen. Die Universallogik kann Verarbeitungsoperationen parallel oder in Verbindung mit Universallogik innerhalb des oder der Prozessorkerne 107 aus 1 oder des Kerns 202A-202N wie in 2A durchführen.
Ausgabedaten, die durch Threads erzeugt werden, die auf dem Grafikkern-Array 414 ausgeführt werden, können Daten in einen Speicher in einem einheitlichen Rückgabepuffer (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 verschiedenen 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 Festfunktionslogik innerhalb der gemeinsam genutzten Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist das Grafikkern-Array 414 skalierbar, so dass das Array eine variable Anzahl von Grafikkernen aufweist, die jeweils eine variable Anzahl von Ausführungseinheiten basierend auf der Zielleistung und dem Leistungsfähigkeitspegel der GPE 410 aufweisen. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, so dass Ausführungsressourcen nach Bedarf aktiviert oder deaktiviert werden können.
Das Grafikkern-Array 414 koppelt mit gemeinsam genutzter Funktionslogik 420, die mehrere Ressourcen aufweist, die zwischen den Grafikkernen in dem Grafikkern-Array gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen innerhalb der Logik 420 mit gemeinsam genutzter Funktion sind Hardwarelogikeinheiten, die dem Grafikkern-Array 414 spezialisierte Ergänzungsfunktionalität bereitstellen. In verschiedenen Ausführungsformen weist die Logik 420 mit gemeinsam genutzter Funktion, ohne darauf beschränkt zu sein, eine Sampler-Logik 421, eine Mathematik 422 und eine Inter-Thread-Kommunikation (ITC: Inter-Thread Communication) 423 auf. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Cache(s) 425 innerhalb der Logik 420 mit gemeinsam genutzter Funktion.
Eine gemeinsam genutzte Funktion wird zumindest in einem Fall implementiert, in dem die Anforderung für eine gegebene spezialisierte Funktion für die Aufnahme in das Grafikkern-Array 414 unzureichend ist. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eine eigenständige Entität in der gemeinsam genutzten Funktionslogik 420 implementiert und unter den Ausführungsressourcen innerhalb des Grafikkern-Arrays 414 gemeinsam genutzt. Der genaue Satz von Funktionen, die von dem Grafikkern-Array 414 gemeinsam genutzt werden und in dem Grafikkern-Array 414 enthalten sind, variiert über Ausführungsformen hinweg. In einigen Ausführungsformen können spezifische gemeinsam genutzte Funktionen innerhalb der Logik 420 mit gemeinsam genutzter Funktion, die umfangreich von dem Grafikkern-Array 414 verwendet werden, innerhalb der Logik 416 mit gemeinsam genutzter Funktion innerhalb des Grafikkern-Arrays 414 enthalten sein. In verschiedenen Ausführungsformen kann die Logik 416 mit gemeinsam genutzter Funktion innerhalb des Grafikkern-Arrays 414 die gesamte Logik oder einen Teil davon innerhalb der Logik 420 mit gemeinsam genutzter Funktion aufweisen. In einer Ausführungsform können alle Logikelemente innerhalb der Logik 420 mit gemeinsam genutzter Funktion innerhalb der Logik 416 mit gemeinsam genutzter Funktion des Grafikkern-Arrays 414 dupliziert werden. In einer Ausführungsform ist die gemeinsam genutzte Funktionslogik 420 zugunsten der gemeinsam genutzten Funktionslogik 416 innerhalb des Grafikkern-Arrays 414 ausgeschlossen.
Ausführungseinheiten
Die 5A-5B veranschaulichen Thread-Ausführungslogik 500 einschließlich eines Arrays von Verarbeitungselementen, die in einem Grafikprozessorkern gemäß hierin beschriebenen Ausführungsformen eingesetzt werden. Elemente aus den 5A-5B, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hier aufweisen, können auf eine beliebige ähnliche Weise wie jene arbeiten oder funktionieren, die an anderer Stelle hier beschrieben ist, sind aber nicht darauf beschränkt. Die 5A-5B veranschaulichen eine Übersicht über die Thread-Ausführungslogik 500, die Hardwarelogik repräsentieren kann, die mit jedem Unterkern 221A-221F von 2B veranschaulicht ist. 5A repräsentiert eine Ausführungseinheit innerhalb eines Universalgrafikprozessors, während 5B eine Ausführungseinheit repräsentiert, die innerhalb eines Rechenbeschleunigers verwendet werden kann.
Wie in 5A veranschaulicht, weist die Thread-Ausführungslogik 500 in einigen Ausführungsformen einen Shader-Prozessor 502, einen Thread-Dispatcher 504, einen Anweisungs-Cache 506, ein skalierbares Ausführungseinheitsarray, das mehrere Ausführungseinheiten 508A-508N aufweist, einen Sampler 510, einen gemeinsam genutzten lokalen Speicher 511, einen Daten-Cache 512 und einen Datenport 514 auf. In einer Ausführungsform kann das skalierbare Ausführungseinheitsarray dynamisch skalieren, indem eine oder mehrere Ausführungseinheiten (z. B. eine beliebige der Ausführungseinheiten 508A, 508B, 508C, 508D bis 508N-1 und 508N) basierend auf den Rechenanforderungen einer Arbeitslast aktiviert oder deaktiviert werden. In einer Ausführungsform sind die enthaltenen Komponenten über ein Interconnect-Fabric, das mit jeder der Komponenten verknüpft ist, miteinander verbunden. In einigen Ausführungsformen weist die Thread-Ausführungslogik 500 eine oder mehrere Verbindungen zum Speicher, wie etwa Systemspeicher oder Cache-Speicher, durch einen oder mehrere des Anweisungs-Caches 506, des Datenports 514, des Samplers 510 und der Ausführungseinheiten 508A-508N auf. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 508A) eine eigenständige programmierbare Universalrecheneinheit, die in der Lage ist, mehrere gleichzeitige Hardware-Threads auszuführen, während mehrere Datenelemente für jeden Thread parallel verarbeitet werden. In verschiedenen Ausführungsformen ist das Array von Ausführungseinheiten 508A-508N skalierbar, um eine beliebige Anzahl individueller Ausführungseinheiten aufzuweisen.
In einigen Ausführungsformen werden die Ausführungseinheiten 508A-508N hauptsächlich verwendet, um Shader-Programme auszuführen. Ein Shader-Prozessor 502 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads, die mit den Shader-Programmen assoziiert sind, über einen Thread-Dispatcher 504 versenden. In einer Ausführungsform weist der Thread-Dispatcher Logik zum Arbitrieren von Thread-Initiierungsanfragen von den Grafik- und Medien-Pipelines und Instanziieren der angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 508A-508N auf. Eine Geometrie-Pipeline kann zum Beispiel Vertex, Tessellation oder Geometrie-Shader an die Thread-Ausführungslogik zur Verarbeitung versenden. In einigen Ausführungsformen kann der Thread-Dispatcher 504 auch Laufzeit-Thread-Erzeugungsanforderungen von den ausgeführten Shader-Programmen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 508A-508N einen Anweisungssatz, der native Unterstützung für viele Standard-3D-Grafik-Shader-Anweisungen aufweist, so dass Shader-Programme aus Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertexprogramme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z. B. Pixel-Shader, Fragment-Shader) und Universalverarbeitung (z. B. Rechen- und Medien-Shader). Jede der Ausführungseinheiten 508A-508N ist zu einer Mehrfachausgabe von Einzelbefehl-Mehrfachdaten(SIMD)-Ausführung fähig und eine Multithread-Operation ermöglicht eine effiziente Ausführungsumgebung in Anbetracht von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit weist eine dedizierte Registerdatei mit hoher Bandbreite und einen assoziierten unabhängigen Thread-Zustand auf. Die Ausführung ist Mehrfachausgabe pro Takt an Pipelines, die zu ganzzahligen Gleitkommaoperationen mit einfacher und doppelter Genauigkeit, SIMD-Verzweigungsfähigkeit, logischen Operationen, transzendentalen Operationen und anderen sonstigen Operationen in der Lage sind. Während auf Daten aus dem Speicher oder einer der gemeinsam genutzten Funktionen gewartet wird, bewirkt die Abhängigkeitslogik innerhalb der Ausführungseinheiten 508A-508N, dass ein wartender Thread ruht, bis die angeforderten Daten zurückgegeben wurden. Während der wartende Thread ruht, können Hardwareressourcen der Verarbeitung anderer Threads zugeteilt werden. Während einer Verzögerung, die mit einer Vertex-Shader-Operation assoziiert ist, kann zum Beispiel eine Ausführungseinheit Operationen für einen Pixel-Shader, Fragment-Shader oder einen anderen Typ von Shader-Programm durchführen, einschließlich eines anderen Vertex-Shaders. Verschiedene Ausführungsformen können für die Verwendung einer Ausführung unter Verwendung von Single Instruction Multiple Thread (SIMT) als Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD gelten. Eine Bezugnahme auf einen SIMD-Kern oder eine SIMD-Operation kann auch für SIMT gelten oder für SIMD in Kombination mit SIMT gelten.
Jede Ausführungseinheit in den Ausführungseinheiten 508A-508N arbeitet auf Arrays von Datenelementen. Die Anzahl an Datenelementen ist die „Ausführungsgröße“ oder die Anzahl an Kanälen für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für Datenelementzugriff, Maskierung und Flusssteuerung innerhalb von Anweisungen. Die Anzahl von Kanälen kann unabhängig von der Anzahl von physikalischen arithmetischen logischen Einheiten (ALUs) oder Gleitkommaeinheiten (FPUs) für einen bestimmten Grafikprozessor sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 508A-508N Ganzzahl- und Gleitkomma-Datentypen.
Der Ausführungseinheitsanweisungssatz weist SIMD-Anweisungen auf. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert werden und die Ausführungseinheit wird die verschiedenen Elemente basierend auf der Datengröße der Elemente verarbeiten. Wenn zum Beispiel an einem 256-Bit breiten Vektor gearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert und die Ausführungseinheit arbeitet an dem Vektor als vier separate gepackte 54-Bit-Datenelemente (Datenelemente mit Quad-Word(QW)-Größe), acht separate gepackte 32-Bit-Datenelemente (Datenelemente mit Doppelwort(DW)-Größe), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente mit Wort(W)-Größe) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente mit Byte(B)-Größe). Unterschiedliche Vektorbreiten und Registergrößen sind jedoch möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten zu einer vereinigten Ausführungseinheit 509A-509N mit einer Thread-Steuerlogik (507A-507N) kombiniert werden, die den vereinigten EUs gemein ist. Mehrere EUs können zu einer EU-Gruppe vereinigt werden. Jede EU in der fusionierten EU-Gruppe kann dazu konfiguriert sein, einen separaten SIMD-Hardware-Thread auszuführen. Die Anzahl der EUs in einer fusionierten EU-Gruppe kann gemäß Ausführungsformen variieren. Zusätzlich dazu können verschiedene SIMD-Breiten pro EU durchgeführt werden, einschließlich unter anderem SIMD8, SIMD16 und SIMD32. Jede vereinigte Grafikausführungseinheit 509A-509N weist mindestens zwei Ausführungseinheiten auf. Zum Beispiel weist die fusionierte Ausführungseinheit 509A eine erste EU 508A, eine zweite EU 508B und eine Thread-Steuerlogik 507A, die der ersten EU 508A und der zweiten EU 508B gemeinsam ist, auf. Die Thread-Steuerlogik 507A steuert Threads, die auf der fusionierten Grafikausführungseinheit 509A ausgeführt werden, wodurch jeder EU innerhalb der fusionierten Ausführungseinheiten 509A-509N ermöglicht wird, unter Verwendung eines gemeinsamen Anweisungszeigerregisters ausgeführt zu werden.
Ein oder mehrere interne Anweisungs-Caches (z. B. 506) sind in der Thread-Ausführungslogik 500 enthalten, um Thread-Anweisungen für die Ausführungseinheiten zwischenzuspeichern. In einigen Ausführungsformen sind ein oder mehrere Daten-Caches (z. B. 512) enthalten, um Thread-Daten während der Thread-Ausführung zwischenzuspeichern. Threads, die auf der Ausführungslogik 500 ausgeführt werden, können auch explizit verwaltete Daten im gemeinsam genutzten lokalen Speicher 511 speichern. In einigen Ausführungsformen ist ein Sampler 510 enthalten, um Texturabtastung für 3D-Operationen und Medienabtastung für Medienoperationen bereitzustellen. In einigen Ausführungsformen weist der Sampler 510 spezialisierte Textur- oder Medienabtastfunktionalität auf, 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 500 über Thread-Erzeugungs- und Absendelogik. Sobald eine Gruppe geometrischer Objekte verarbeitet und zu Pixeldaten gerastert wurde, wird Pixelprozessorlogik (z. B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) innerhalb des Shader-Prozessors 502 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu bewirken, dass Ergebnisse auf Ausgabeoberflächen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In einigen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertexattribute, die über das gerasterte Objekt interpoliert werden sollen. In einigen Ausführungsformen führt die Pixelprozessorlogik innerhalb des Shader-Prozessors 502 dann ein von einer Anwendungsprogrammierungsschnittstelle (API) geliefertes Pixel- oder Fragment-Shader-Programm aus. Um das Shader-Programm auszuführen, sendet der Shader-Prozessor 502 Threads über den Thread-Dispatcher 504 an eine Ausführungseinheit (z. B. 508A). In einigen Ausführungsformen verwendet der Shader-Prozessor 502 Texturabtastlogik im Sampler 510, um auf Texturdaten in Texturabbildungen zuzugreifen, die im Speicher gespeichert sind. Arithmetische Operationen an den Texturdaten und den Eingabegeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel von der weiteren Verarbeitung.
In einigen Ausführungsformen stellt der Datenport 514 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 500 bereit, um verarbeitete Daten an den Speicher zur weiteren Verarbeitung auf einer Grafikprozessorausgabe-Pipeline auszugeben. In einigen Ausführungsformen weist der Datenport 514 einen oder mehrere Cache-Speicher (z. B. Daten-Cache 512) auf oder koppelt mit diesen, um Daten für einen Speicherzugriff über den Datenport zwischenzuspeichern.
In einer Ausführungsform kann die Ausführungslogik 500 auch einen Strahlverfolger 505 aufweisen, der eine Strahlverfolgungsbeschleunigungsfunktionalität bereitstellen kann. Der Strahlverfolger 505 kann einen Strahlverfolgungsanweisungssatz unterstützen, der Anweisungen/Funktionen zur Strahlerzeugung aufweist. Der Strahlverfolgungsanweisungssatz kann dem Strahlverfolgungsanweisungssatz, der durch die Strahlverfolgungskerne 245 in 2C unterstützt wird, ähnlich oder verschieden sein.
5B veranschaulicht beispielhafte interne Einzelheiten einer Ausführungseinheit 508 gemäß Ausführungsformen. Eine Grafikausführungseinheit 508 kann eine Anweisungsabrufeinheit 537, ein allgemeines Registerdateiarray (GRF) 524, ein Architekturregisterdateiarray (ARF) 526, einen Thread-Arbiter 522, eine Sendeeinheit 530, eine Verzweigungseinheit 532, einen Satz von SIMD-Gleitkommaeinheiten (FPUs) 534 und in einer Ausführungsform einen Satz von dedizierten ganzzahligen SIMD-ALUs 535 aufweisen. Die GRF 524 und ARF 526 weisen den Satz von allgemeinen Registerdateien und Architekturregisterdateien auf, die mit jedem gleichzeitigen Hardwarethread assoziiert sind, der in der Grafikausführungseinheit 508 aktiv sein kann. In einer Ausführungsform wird der Architekturzustand pro Thread in der ARF 526 beibehalten, während Daten, die während der Thread-Ausführung verwendet werden, in der GRF 524 gespeichert werden. Der Ausführungszustand jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in Threadspezifischen Registern im ARF 526 gehalten werden.
In einer Ausführungsform weist die Grafikausführungseinheit 508 eine Architektur auf, die eine Kombination von simultanem Multi-Threading (SMT) und feinkörnigem verschachteltem Multi-Threading (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zur Gestaltungszeit basierend auf einer Zielanzahl von gleichzeitigen Threads und einer Anzahl von Registern pro Ausführungseinheit fein abgestimmt werden kann, wobei Ressourcen der Ausführungseinheit über die Logik aufgeteilt werden, die zum Ausführen mehrerer gleichzeitiger Threads verwendet wird. Die Anzahl von logischen Threads, die durch die Grafikausführungseinheit 508 ausgeführt werden können, ist nicht auf die Anzahl von Hardware-Threads beschränkt, und jedem Hardware-Thread können mehrere logische Threads zugewiesen werden.
In einer Ausführungsform kann die Grafikausführungseinheit 508 mehrere Anweisungen gemeinsam ausgeben, die jeweils unterschiedliche Anweisungen sein können. Der Thread-Arbiter 522 des Grafikausführungseinheit-Threads 508 kann die Anweisungen an entweder die Sendeeinheit 530, die Verzweigungseinheit 532 oder die SIMD-FPU(s) 534 zur Ausführung versenden. Jeder Ausführungs-Thread kann auf 128 Universalregister innerhalb des GRF 524 zugreifen, wobei jedes Register 32 Bytes speichern kann, die als ein SIMD-8-Element-Vektor von 32-Bit-Datenelementen zugänglich sind. In einer Ausführungsform hat jeder Ausführungseinheit-Thread Zugriff auf 4 KBytes innerhalb der GRF 524, obwohl Ausführungsformen nicht so beschränkt sind und größere oder weniger Registerressourcen in anderen Ausführungsformen bereitgestellt werden können. In einer Ausführungsform ist die Grafikausführungseinheit 508 in sieben Hardware-Threads partitioniert, die unabhängig Rechenoperationen durchführen können, obwohl die Anzahl von Threads pro Ausführungseinheit auch gemäß Ausführungsformen variieren kann. Beispielsweise werden in einer Ausführungsform bis zu 16 Hardware-Threads unterstützt. In einer Ausführungsform, bei der sieben Threads auf 4 KBytes zugreifen können, kann die GRF 524 insgesamt 28 KBytes speichern. Wenn 16 Threads auf 4 KBytes zugreifen können, kann die GRF 524 insgesamt 64 Kbytes speichern. Flexible Adressierungsmodi können ermöglichen, dass Register zusammen adressiert werden, um effektiv breitere Register zu bilden oder um streifenförmige rechteckige Blockdatenstrukturen zu repräsentieren.
In einer Ausführungsform werden Speicheroperationen, Sampleroperationen und andere Systemkommunikationen mit längerer Latenz über „Senden“-Anweisungen versandt, die durch die Nachrichtenweiterleitungssendeeinheit 530 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 532 gesendet, um SIMD-Divergenz und eventuelle Konvergenz zu ermöglichen.
In einer Ausführungsform weist die Grafikausführungseinheit 508 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 534 auf, um Gleitkommaoperationen durchzuführen. In einer Ausführungsform unterstützen die FPU(s) 534 auch eine Ganzzahlberechnung. In einer Ausführungsform können die FPU(s) 534 SIMD bis zu einer Anzahl von M 32-Bit-Gleitkomma(oder ganzzahligen)-Operationen ausführen oder SIMD bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkommaoperationen ausführen. In einer Ausführungsform stellt mindestens eine der FPU(s) eine erweiterte Mathematikfähigkeit bereit, transzendentische Mathematikfunktionen mit hohem Durchsatz und 54-Bit-Gleitkomma mit doppelter Genauigkeit zu unterstützen. In einigen Ausführungsformen ist auch ein Satz von 8-Bit-Ganzzahl-SIMD-ALUs 535 vorhanden und kann spezifisch optimiert werden, um Operationen durchzuführen, die mit Maschinenlernberechnungen assoziiert sind.
In einer Ausführungsform können Arrays von mehreren Instanzen der Grafikausführungseinheit 508 in einer Grafik-Subkerngruppierung (z. B. einem Sub-Slice) instanziiert werden. Zur Skalierbarkeit können Produktarchitekten die genaue Anzahl an Ausführungseinheiten pro Unterkerngruppierung auswählen. In einer Ausführungsform kann die Ausführungseinheit 508 Anweisungen über mehrere Ausführungskanäle ausführen. In einer weiteren Ausführungsform wird jeder Thread, der auf der Grafikausführungseinheit 508 ausgeführt wird, auf einem anderen Kanal ausgeführt.
6 veranschaulicht eine zusätzliche Ausführungseinheit 600 gemäß einer Ausführungsform. Die Ausführungseinheit 600 kann eine rechenoptimierte Ausführungseinheit zur Verwendung in zum Beispiel einer Rechen-Engine-Kachel 340A-340D wie in 3C sein, ist aber nicht als solche beschränkt. Varianten der Ausführungseinheit 600 können auch in einer Grafik-Engine-Kachel 310A-310D wie in 3B verwendet werden. In einer Ausführungsform weist die Ausführungseinheit 600 eine Thread-Steuereinheit 601, eine Thread-Zustandseinheit 602, eine Anweisungsabruf-/Vorabrufeinheit 603 und eine Anweisungsdecodiereinheit 604 auf. Die Ausführungseinheit 600 weist zusätzlich eine Registerdatei 606 auf, die Register speichert, die Hardware-Threads innerhalb der Ausführungseinheit zugeordnet werden können. Die Ausführungseinheit 600 weist zusätzlich eine Sendeeinheit 607 und eine Verzweigungseinheit 608 auf. In einer Ausführungsform können die Sendeeinheit 607 und die Verzweigungseinheit 608 ähnlich wie die Sendeeinheit 530 und eine Verzweigungseinheit 532 der Grafikausführungseinheit 508 aus 5B arbeiten.
Die Ausführungseinheit 600 weist auch eine Recheneinheit 610 auf, die mehrere unterschiedliche Typen von Funktionseinheiten aufweist. In einer Ausführungsform weist die Recheneinheit 610 eine ALU-Einheit 611 auf, die ein Array von arithmetischen Logikeinheiten aufweist. Die ALU-Einheit 611 kann dazu konfiguriert sein, 64-Bit-, 32-Bit- und 16-Bit-Ganzzahl- und Gleitkommaoperationen durchzuführen. Ganzzahl- und Gleitkommaoperationen können gleichzeitig durchgeführt werden. Die Recheneinheit 610 kann auch ein systolisches Array 612 und eine Mathematik-Einheit 613 aufweisen. Das systolische Array 612 weist ein W-breites und D-tiefes Netzwerk von Datenverarbeitungseinheiten auf, die verwendet werden können, um Vektor- oder andere datenparallele Operationen auf eine systolische Art durchzuführen. In einer Ausführungsform kann das systolische Array 612 dazu konfiguriert sein, Matrixoperationen, wie etwa Matrix-Skalarproduktoperationen, durchzuführen. In einer Ausführungsform unterstützt das systolische Array 612 16-Bit-Gleitkommaoperationen sowie 8-Bit- und 4-Bit-Ganzzahloperationen. In einer Ausführungsform kann das systolische Array 612 dazu konfiguriert sein, Maschinenlernoperationen zu beschleunigen. In solchen Ausführungsformen kann das systolische Array 612 mit Unterstützung für das bfloat 16-Bit-Gleitkommaformat konfiguriert werden. In einer Ausführungsform kann eine Mathematik-Einheit 613 enthalten sein, um eine spezifische Teilmenge mathematischer Operationen auf effiziente und leistungsschwächere Weise als die ALU-Einheit 611 durchzuführen. Die Mathematik-Einheit 613 kann eine Variante einer Mathematik-Logik aufweisen, die in einer Logik mit gemeinsam genutzter Funktion einer Grafikverarbeitungsengine gefunden werden kann, die durch andere Ausführungsformen bereitgestellt wird (z. B. Mathematik-Logik 422 der Logik mit gemeinsam genutzter Funktion 420 von 4). In einer Ausführungsform kann die Mathematik-Einheit 613 dazu konfiguriert sein, 32-Bit- und 64-Bit-Gleitkommaoperationen durchzuführen.
Die Thread-Steuereinheit 601 weist Logik zum Steuern der Ausführung von Threads innerhalb der Ausführungseinheit auf. Die Thread-Steuereinheit 601 kann Thread-Arbitrierungslogik aufweisen, um die Ausführung von Threads innerhalb der Ausführungseinheit 600 zu starten, zu stoppen und zu präemptieren. Die Thread-Zustandseinheit 602 kann verwendet werden, um den Thread-Zustand für Threads zu speichern, die zur Ausführung auf der Ausführungseinheit 600 zugewiesen sind. Das Speichern des Thread-Zustands in der Ausführungseinheit 600 ermöglicht die schnelle Präemption von Threads, wenn diese Threads blockiert oder inaktiv werden. Die Anweisungsabruf-/-vorabrufeinheit 603 kann Anweisungen aus einem Anweisungs-Cache einer Ausführungslogik höherer Ebene abrufen (z. B. Anweisungs-Cache 506 wie in 5A). Die Anweisungssabruf-/-vorabrufeinheit 603 kann auch Vorabruf-Anforderungen für in den Anweisungscache zu ladende Anweisungen basierend auf einer Analyse aktuell ausgeführter Threads ausgeben. Die Anweisungsdecodiereinheit 604 kann verwendet werden, um von den Recheneinheiten auszuführende Anweisungen zu decodieren. In einer Ausführungsform kann die Anweisungsdecodiereinheit 604 als ein Sekundärdecodierer verwendet werden, um komplexe Anweisungen in konstituierende Mikrooperationen zu decodieren.
Die Ausführungseinheit 600 weist zusätzlich eine Registerdatei 606 auf, die durch Hardware-Threads verwendet werden kann, die auf der Ausführungseinheit 600 ausgeführt werden. Register in der Registerdatei 606 können über die Logik aufgeteilt werden, die verwendet wird, um mehrere simultane Threads innerhalb der Recheneinheit 610 der Ausführungseinheit 600 auszuführen. Die Anzahl von logischen Threads, die durch die Grafikausführungseinheit 600 ausgeführt werden können, ist nicht auf die Anzahl von Hardware-Threads beschränkt, und mehrere logische Threads können jedem Hardware-Thread zugewiesen werden. Die Größe der Registerdatei 606 kann zwischen Ausführungsformen basierend auf der Anzahl unterstützter Hardware-Threads variieren. In einer Ausführungsform kann Registerumbenennung verwendet werden, um Hardware-Threads dynamisch Register zuzuweisen.
7 ist ein Blockdiagramm, das ein Grafikprozessoranweisungsformat 700 gemäß einigen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die Kästchen mit durchgezogenen Linien veranschaulichen die Komponenten, die allgemein in einer Ausführungseinheitsanweisung enthalten sind, während die gestrichelten Linien Komponenten aufweisen, die optional sind oder die nur in einer Teilmenge der Anweisungen enthalten sind. In einigen Ausführungsformen handelt es sich bei dem beschriebenen und veranschaulichten Anweisungsformat 700 um Makroanweisungen, insofern es sich um Anweisungen handelt, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die sich aus der Anweisungsdecodierung ergeben, sobald die Anweisung verarbeitet wird.
In einigen Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten nativ Anweisungen in einem 128-Bit-Anweisungsformat 710. Ein kompaktiertes 64-Bit-Anweisungsformat 730 steht für manche Anweisungen basierend auf der ausgewählten Anweisung, Anweisungsoptionen und der Anzahl von Operanden zur Verfügung. Das native 128-Bit-Anweisungsformat 710 stellt Zugriff auf alle Anweisungsoptionen bereit, während manche Optionen und Operationen in dem 64-Bit-Format 730 beschränkt sind. Die nativen Anweisungen, die im 64-Bit-Format 730 verfügbar sind, variieren je nach Ausführungsform. In einigen Ausführungsformen wird die Anweisung teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 kompaktiert. Die Ausführungseinheit-Hardware referenziert einen Satz von Kompaktierungstabellen basierend auf den Indexwerten und verwendet die Kompaktierungstabellenausgaben, um eine native Anweisung im 128-Bit-Anweisungsformat 710 zu rekonstruieren. Es können andere Anweisungsgrößen und Anweisungsformate verwendet werden.
Für jedes Format definiert der Anweisungsopcode 712 die Operation, die die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden aus. Zum Beispiel führt die Ausführungseinheit als Reaktion auf eine Addieranweisung eine gleichzeitige Addieroperation über jeden Farbkanal durch, der ein Texturelement oder Bildelement repräsentiert. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden durch. In einigen Ausführungsformen ermöglicht das Anweisungssteuerfeld 714 die Steuerung über gewisse Ausführungsoptionen, wie etwa Kanalauswahl (z. B. Prädiktion) und Datenkanalreihenfolge (z. B. swizzle). Für Anweisngen im 128-Bit-Anweisungsformat 710 begrenzt ein Ausführungsgrößenfeld 716 die Anzahl von Datenkanälen, die parallel ausgeführt werden. In einigen Ausführungsformen steht das Ausführungsgrößenfeld 716 nicht zur Verwendung in dem kompakten 64-Bit-Anweisungsformat 730 zur Verfügung.
Einige Ausführungseinheitsanweisungen weisen bis zu drei Operanden einschließlich zwei Quelloperanden src0 720, src1 722 und einem Ziel 718 auf. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Doppelzielanweisungen, wobei eines der Ziele impliziert ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden (z. B. SRC2 724) aufweisen, wobei der Anweisungsopcode 712 die Anzahl von Quelloperanden bestimmt. Ein letzter Quelloperand einer Anweisung kann ein sofortiger (z. B. fest codierter) Wert sein, der mit der Anweisung weitergegeben wird.
In einigen Ausführungsformen weist das 128-Bit-Anweisungsformat 710 ein Zugriff/Adressmodusfeld 726 auf, 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 weist das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726 auf, 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 ausgerichteten 16-Byte-Zugriffsmodus und eines ausgerichteten 1-Byte-Zugriffsmodus, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Beispielsweise kann die Anweisung, wenn sie sich in einem ersten Modus befindet, eine byteausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und wenn sie sich in einem zweiten Modus befindet, kann die Anweisung eine 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressmodusabschnitt des Zugriffs-/Adressmodusfeldes 726, ob die Anweisung direktes oder indirektes Adressieren verwenden soll. Wenn der Direktregisteradressierungsmodus verwendet wird, liefern Bits in der Anweisung direkt die Registeradresse eines oder mehrerer Operanden. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem unmittelbaren Adressfeld in der Anweisung berechnet werden.
In einigen Ausführungsformen werden Anweisungen basierend auf Bitfeldern des Opcodes 712 gruppiert, um die Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit-Opcode ermöglichen die Bits 4, 5 und 6 der Ausführungseinheit, den Typ des Opcodes zu bestimmen. Die genau dargestellte Opcode-Gruppierung ist lediglich ein Beispiel. In einigen Ausführungsformen weist eine Bewegungs- und Logik-Opcode-Gruppe 742 Datenbewegungs- und Logikanweisungen (z. B. Bewegung (mov), Vergleich (cmp)) auf. In einigen Ausführungsformen nutzt die Bewegungs- und Logikgruppe 742 die fünf höchstwertigen Bits (MSB), wobei Anweisungs-Befehle (mov) in der Form von 0000xxxxb vorliegen und Logikanweisungen in der Form von 0001xxxxb vorliegen. Eine Flusssteueranweisungsgruppe 744 (z. B. Call, Jump (jmp)) weist Anweisungen in der Form von 0010xxxxb auf (z. B. 0x20). Eine andere Anweisungsgruppe 746 weist eine Mischung von Anweisungen auf, einschließlich Synchronisationsanweisungen (z. B. Warten, Senden) in der Form von 0011xxxxb (z. B. 0x30). Eine parallele Mathematik-Anweisungsgruppe 748 weist komponentenweise arithmetische Anweisungen (z. B. Add, Multiply (mul)) in der Form von 0100xxxxb (z. B. 0x40) auf. Die parallele Mathematikgruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle durch. Die Vektormathematikgruppe 750 weist arithmetische Anweisungen (z. B. dp4) in der Form von 0101xxxxb (z. B. 0x50) auf. Die Vektormathematikgruppe führt Arithmetik wie etwa Skalarproduktberechnungen an Vektoroperanden durch. Die veranschaulichte Opcode-Decodierung 740 kann in einer Ausführungsform verwendet werden, um zu bestimmen, welcher Abschnitt einer Ausführungseinheit verwendet wird, um eine decodierte Anweisung auszuführen. Zum Beispiel können einige Anweisungen als systolische Anweisungen bezeichnet werden, die durch ein systolisches Array ausgeführt werden. Andere Anweisungen, wie etwa (nicht gezeigte) Strahlverfolgungsanweisungen, können zu einem Strahlverfolgungskern oder einer Strahlverfolgungslogik innerhalb eines Slice oder einer Partition der Ausführungslogik geleitet werden.
Grafik-Pipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente aus 8 mit den gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin können auf eine beliebige ähnliche Weise wie jene arbeiten oder funktionieren, die an anderer Stelle hierin beschrieben ist, sind aber nicht darauf beschränkt.
In einigen Ausführungsformen weist der Grafikprozessor 800 eine Geometrie-Pipeline 820, eine Medien-Pipeline 830, eine Anzeige-Engine 840, eine Thread-Ausführungslogik 850 und eine Renderausgabe-Pipeline 870 auf. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkernverarbeitungssystems, das einen oder mehrere Universalverarbeitungskerne aufweist. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle gesteuert, die über eine Ringverbindung 802 an den Grafikprozessor 800 ausgegeben werden. In einigen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 mit anderen Verarbeitungskomponenten, wie etwa anderen Grafikprozessoren oder Universalprozessoren. Befehle von der Ringverbindung 802 werden durch einen Befehlsstreamer 803 interpretiert, der individuelle Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 mit Anweisungen versorgt.
In einigen Ausführungsformen leitet der Befehlstreamer 803 den Betrieb eines Vertex-Abrufers 805 an, der Vertex-Daten aus dem Speicher liest und Vertex-Verarbeitungsbefehle ausführt, die durch den Befehl-Streamer 803 bereitgestellt werden. In einigen Ausführungsformen stellt der Vertex-Abrufer 805 Vertex-Daten an einen Vertex-Shader 807 bereit, der Koordinatenraumtransformations- und Beleuchtungsoperationen an jedem Vertex durchführt. In einigen Ausführungsformen führen der Vertex-Abrufer 805 und der Vertex-Shader 807 Vertex-Verarbeitungsanweisungen aus, indem sie Ausführungs-Threads über einen Thread-Dispatcher 831 an die Ausführungseinheiten 852A-852B versenden.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B ein Array von Vektorprozessoren mit einem Anweisungssatz zum Durchführen von Grafik- und Medienoperationen. In einigen Ausführungsformen weisen die Ausführungseinheiten 852A-852B einen angehängten L1-Cache 851 auf, der für jedes Array spezifisch ist oder von den Arrays gemeinsam genutzt wird. Der Cache kann als ein Daten-Cache, ein Anweisungs-Cache oder ein einzelner Cache konfiguriert sein, der partitioniert ist, um Daten und Anweisungen in verschiedenen Partitionen zu enthalten.
In einigen Ausführungsformen weist die Geometrie-Pipeline 820 Tessellationskomponenten zum Durchführen einer hardwarebeschleunigten Tessellation von 3D-Objekten auf. In einigen Ausführungsformen konfiguriert ein programmierbarer Hüllenshader 811 die Tessellationsoperationen. Ein programmierbarer Domain-Shader 817 stellt eine Backend-Bewertung der Tessellationsausgabe bereit. Ein Tessellator 813 arbeitet in Richtung des Hüllen-Shaders 811 und enthält eine Spezialzwecklogik zum Erzeugen eines Satzes detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell, das als Eingabe in die Geometrie-Pipeline 820 bereitgestellt wird. Falls keine Tessellation verwendet wird, können in einigen Ausführungsformen Tessellationskomponenten (z. B. Hüllenshader 811, Tesselator 813 und Domänenshader 817) umgangen werden.
In einigen Ausführungsformen können vollständige geometrische Objekte durch einen Geometrie-Shader 819 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 852A-852B versendet werden, oder sie können direkt zu dem Clipper 829 weitergehen. In einigen Ausführungsformen arbeitet der Geometrie-Shader an gesamten geometrischen Objekten statt an Vertices oder Patches von Vertices wie in vorherigen Stufen der Grafik-Pipeline. Falls die Tessellation 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 Geometrie-Tessellation durchzuführen, falls die Tessellationseinheiten deaktiviert sind.
Vor der Rasterisierung verarbeitet ein Clipper 829 Vertexdaten. Der Clipper 829 kann ein Clipper mit fester Funktion oder ein programmierbarer Clipper mit Clipping- und Geometrie-Shader-Funktionen sein. In einigen Ausführungsformen sendet eine Rasterisierer- und-Tiefentest-Komponente 873 in der Renderausgabe-Pipeline 870 Pixel-Shader, um die geometrischen Objekte in Pro-Pixeldarstellungen 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 Rasterisierer- und Tiefentestkomponente 873 umgehen und über eine Stream-out-Einheit 823 auf ungerasterte Vertexdaten zugreifen.
Der Grafikprozessor 800 weist einen Verbindungsbus, eine Verbindungsstruktur oder einen anderen Verbindungsmechanismus auf, der eine Daten- und Nachrichtenweiterleitung zwischen den Hauptkomponenten des Prozessors ermöglicht. In einigen Ausführungsformen verbinden sich die Ausführungseinheiten 852A-852B und die assoziierten Logikeinheiten (z. B. der L1-Cache 851, der Sampler 854, der Textur-Cache 858 usw.) über einen Datenport 856, um Speicherzugriff durchzuführen und mit Renderausgabe-Pipeline-Komponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen weisen der Sampler 854, die Caches 851, 858 und die Ausführungseinheiten 852A-852B jeweils separate Speicherzugriffspfade auf. In einer Ausführungsform kann der Textur-Cache 858 auch als Sampler-Cache konfiguriert sein.
Inn einigen Ausführungsformen weist die Renderausgabe-Pipeline 870 eine Rasterisierer- und Tiefentestkomponente 873 auf, die vertexbasierte Objekte in eine assoziierte pixelbasierte Repräsentation umwandelt. In einigen Ausführungsformen weist die Rasterisierlogik eine Fenster-/Maskiereinheit zum Durchführen einer Dreiecks- und Linienrasterisierung mit fester Funktion auf. Ein zugehöriger Render-Cache 878 und Tiefen-Cache 879 sind in einigen Ausführungsformen ebenfalls verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten durch, obwohl in manchen Fällen Pixeloperationen, die mit 2D-Operationen assoziiert sind (z. B. Bitblockbildübertragungen mit Mischen), durch die 2D-Engine 841 durchgeführt werden oder zur Anzeigezeit durch die Anzeigesteuerung 843 unter Verwendung von Overlay-Anzeigeebenen ersetzt werden. In einigen Ausführungsformen steht ein gemeinsam genutzter L3-Cache 875 für alle Grafikkomponenten zur Verfügung, was das gemeinsame Nutzen von Daten ohne die Verwendung von Hauptsystemspeicher ermöglicht.
In einigen Ausführungsformen weist die Grafikprozessor-Medien-Pipeline 830 eine Medien-Engine 837 und ein Video-Frontend 834 auf. In einigen Ausführungsformen empfängt das Video-Frontend 834 Pipeline-Befehle von dem Befehl-Streamer 803. In einigen Ausführungsformen weist die Medien-Pipeline 830 einen separaten Befehlsstreamer auf. In einigen Ausführungsformen verarbeitet das Video-Frontend 834 Medienbefehle, bevor der Befehl an die Medien-Engine 837 gesendet wird. In einigen Ausführungsformen weist die Medien-Engine 837 eine Thread-Erzeugungsfunktionalität auf, um Threads zum Versenden an die Thread-Ausführungslogik 850 über den Thread-Dispatcher 831 zu erzeugen.
In einigen Ausführungsformen weist der Grafikprozessor 800 eine Anzeige-Engine 840 auf. In einigen Ausführungsformen befindet sich die Anzeige-Engine 840 außerhalb des Prozessors 800 und koppelt mit dem Grafikprozessor über die Ringverbindung 802 oder einen anderen Verbindungsbus oder eine andere Verbindungsstruktur. In einigen Ausführungsformen weist die Anzeige-Engine 840 eine 2D-Engine 841 und eine Anzeigesteuerung 843 auf. In einigen Ausführungsformen enthält die Anzeige-Engine 840 Speziallogik, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen koppelt die Anzeigesteuerung 843 mit einer Anzeigevorrichtung (nicht gezeigt), die eine systemintegrierte Anzeigevorrichtung, wie in einem Laptop-Computer, oder eine externe Anzeigevorrichtung, die über einen Anzeigevorrichtungsverbinder angebracht ist, sein kann.
In einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 konfigurierbar, um Operationen basierend auf mehreren Grafik- und Medienprogrammierschnittstellen durchzuführen, und sind nicht spezifisch für irgendeine Anwendungsprogrammierschnittstelle (API). In einigen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle, 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 Graphics and Computing API bereitgestellt, alle aus der Khronos Gruppe. 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 Bibliothek (OpenCV) bereitgestellt werden. Eine zukünftige API mit kompatibler 3D-Pipeline würde auch unterstützt werden, wenn eine Abbildung von der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors erfolgen kann.
Grafik-Pipeline-Programmierung
9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat 900 gemäß einigen Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 910 gemäß einer Ausführungsform veranschaulicht. Die Kästchen in durchgezogenen Linien in der 9A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten aufweisen, die optional sind oder die nur in einem Untersatz der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessorbefehlsformat 900 von 9A weist Datenfelder auf, um einen Client 902, einen Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl zu identifizieren. Ein Sub-Opcode 905 und eine Befehlsgröße 908 sind auch in einigen Befehlen enthalten.
In einigen Ausführungsformen spezifiziert der Client 902 die Client-Einheit der Grafikvorrichtung, die die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessorbefehlsparser das Clientfeld jedes Befehls, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten an die geeignete Client-Einheit weiterzuleiten. In einigen Ausführungsformen weisen die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit auf. Jede Client-Einheit weist eine entsprechende Verarbeitungs-Pipeline auf, die die Befehle verarbeitet. Sobald der Befehl durch die Client-Einheit empfangen wird, liest die Client-Einheit den Opcode 904 und, falls vorhanden, den Sub-Opcode 905, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Informationen in dem Datenfeld 906 aus. Für einige Befehle wird erwartet, dass eine explizite Befehlsgröße 908 die Größe des Befehls angibt. In einigen Ausführungsformen bestimmt der Befehlsparser automatisch die Größe von mindestens einigen der Befehle basierend auf dem Befehlsopcode. In einigen Ausführungsformen werden Befehle über Vielfache eines Doppelworts ausgerichtet. Es können andere Befehlsformate verwendet werden.
Das Flussdiagramm in 9B veranschaulicht eine beispielhafte Grafikprozessorbefehlssequenz 910. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors aufweist, eine Version der gezeigten Befehlssequenz, um einen Satz von Grafikoperationen einzurichten, auszuführen und zu beenden. Eine beispielhafte Befehlssequenz ist nur zu beispielhaften Zwecken 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 Stapel von Befehlen in einer Befehlssequenz ausgegeben werden, so dass der Grafikprozessor die Befehlssequenz mindestens teilweise gleichzeitig verarbeiten wird.
In einigen Ausführungsformen kann die Grafikprozessorbefehlssequenz 910 mit einem Pipeline-Entleerungsbefehl 912 beginnen, um zu bewirken, dass jede aktive Grafik-Pipeline die gegenwärtig ausstehenden Befehle für die Pipeline abschließt. In einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Die Pipeline-Leerung wird durchgeführt, um zu bewirken, dass die aktive Grafik-Pipeline jegliche ausstehende Befehle abschließt. Als Reaktion auf eine Pipeline-Leerung wird der Befehlsparser für den Grafikprozessor die Befehlsverarbeitung pausieren, bis die aktiven Zeichnungsengines ausstehende Operationen abschließen und die relevanten Lese-Caches ungültig gemacht sind. Optional können beliebige Daten in dem Render-Cache, die als „verschmutzt“ markiert sind, in den Speicher geleert werden. In einigen Ausführungsformen kann der Pipeline-Entleerungsbefehl 912 zur Pipeline-Synchronisation oder vor dem Versetzen des Grafikprozessors in einen Niedrigleistungszustand verwendet werden.
In einigen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen Pipelines wechselt. In einigen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 nur einmal innerhalb eines Ausführungskontextes benötigt, bevor Pipeline-Befehle ausgegeben werden, es sei denn, der Kontext soll Befehle für beide Pipelines ausgeben. In einigen Ausführungsformen wird ein Pipeline-Entleerungsbefehl 912 unmittelbar vor einem Pipeline-Umschalten über den Pipeline-Auswahlbefehl 913 benötigt.
In einigen Ausführungsformen konfiguriert ein 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-Zustand für die aktive Pipeline. In einer Ausführungsform wird der Pipeline-Steuerbefehl 914 zur Pipeline-Synchronisation und zum Löschen von Daten aus einem oder mehreren Cache-Speichern innerhalb der aktiven Pipeline verwendet, bevor ein Stapel von Befehlen verarbeitet wird.
In einigen Ausführungsformen werden Rückgabepufferzustandsbefehle 916 verwendet, um einen Satz von Rückgabepuffern für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Manche Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen Zwischendaten während der Verarbeitung schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und eine Cross-Thread-Kommunikation durchzuführen. In einigen Ausführungsformen umfasst der Rückgabepufferzustand 916 das Auswählen der Größe und Anzahl von Rückgabepuffern, die für einen Satz von Pipeline-Operationen zu verwenden sind.
Die übrigen Befehle in der Befehlssequenz unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipeline-Bestimmung 920 wird die Befehlssequenz auf die 3D-Pipeline 922 beginnend mit dem 3D-Pipeline-Zustand 930 oder die Medien-Pipeline 924 beginnend mit dem Medien-Pipeline-Zustand 940 zugeschnitten.
Die Befehle zum Konfigurieren des 3D-Pipeline-Zustands 930 umfassen 3D-Zustandseinstellbefehle für Vertexpufferzustand, Vertexelementzustand, Konstantfarbzustand, Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitivbefehle verarbeitet werden. Die Werte dieser Befehle werden mindestens teilweise basierend auf der bestimmten 3D-API in Verwendung bestimmt. In einigen Ausführungsformen sind die 3D-Pipeline-Status 930-Befehle auch in der Lage, bestimmte Pipeline-Elemente selektiv zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird der 3D-Primitiv-Befehl 932 verwendet, um 3D-Primitive zu übermitteln, die durch die 3D-Pipeline verarbeitet werden sollen. Befehle und assoziierte Parameter, die über den 3D-Primitiv-Befehl 932 an den Grafikprozessor weitergeleitet werden, werden an die Vertex-Abruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die 3D-Primitiv-Befehlsdaten 932, um Vertex-Datenstrukturen zu erzeugen. Die Vertex-Datenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der 3D-Primitiv-Befehl 932 verwendet, um Vertex-Operationen an 3D-Primitiven über Vertex-Shader durchzufü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 einen Ausführungsbefehl oder ein Ausführungsereignis 934 ausgelöst. In einigen Ausführungsformen löst ein Registerschreiben eine Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über einen „Go“- oder „Kick“-Befehl in der Befehlssequenz ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipeline-Synchronisationsbefehls ausgelöst, um die Befehlssequenz durch die Grafik-Pipeline zu leeren. Die 3D-Pipeline wird Geometrieverarbeitung für die 3D-Primitive durchführen. Sobald Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixel-Engine färbt die resultierenden Pixel. Zusätzliche Befehle zum Steuern von Pixelschattierungs- und Pixelbackend-Operationen können auch für diese Operationen enthalten sein.
In einigen Ausführungsformen folgt die Grafikprozessorbefehlssequenz 910 dem Pfad der Medien-Pipeline 924, wenn Medienoperationen durchgeführt werden. Allgemein hängt die spezifische Verwendung und Art der Programmierung für die Medien-Pipeline 924 von den durchzuführenden Medien oder Rechenoperationen ab. Spezifische Mediendecodieroperationen können während der Mediendecodierung auf die Medien-Pipeline abgeladen werden. In einigen Ausführungsformen kann die Medien-Pipeline auch umgangen werden und Mediendecodierung kann ganz oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die durch einen oder mehrere Universalverarbeitungskerne bereitgestellt werden. In einer Ausführungsform weist die Medien-Pipeline auch Elemente für GPGPU-Operationen (GPGPU: Universal-Grafikprozessoreinheit) auf, wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Rechen-Shader-Programmen durchzuführen, die sich nicht explizit auf das Rendern von Grafikprimitiven beziehen.
In einigen Ausführungsformen ist die Medien-Pipeline 924 auf eine ähnliche Weise wie die 3D-Pipeline 922 konfiguriert. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipeline-Zustands 940 wird vor den Medienobjektbefehlen 942 versendet oder in eine Befehlswarteschlange platziert. In einigen Ausführungsformen umfassen Befehle für den Medien-Pipeline-Zustand 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medienobjekte verwendet werden. Dies umfasst Daten zum Konfigurieren der Videodecodier- und Videocodierlogik innerhalb der Medien-Pipeline, wie etwa das Codier- oder das Decodierformat. In einigen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Zustand 940 auch die Verwendung eines oder mehrerer Zeiger auf „indirekte“ Zustandselemente, die einen Stapel von Zustandseinstellungen enthalten.
In einigen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger zu Medienobjekten zur Verarbeitung durch die Medien-Pipeline. Die Medienobjekte weisen Speicherpuffer auf, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medien-Pipeline-Zustände gültig sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Sobald der Pipeline-Zustand konfiguriert ist und Medienobjektbefehle 942 eingereiht sind, wird die Medien-Pipeline 924 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (z. B. Registerschreibvorgang) ausgelöst. Die Ausgabe von der Medien-Pipeline 924 kann dann durch Operationen nachverarbeitet werden, die durch die 3D-Pipeline 922 oder die Medien-Pipeline 924 bereitgestellt werden. In einigen Ausführungsformen werden GPGPU-Operationen auf ähnliche Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafiksoftwarearchitektur
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß manchen Ausführungsformen. In einigen Ausführungsformen weist die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030 auf. In einigen Ausführungsformen weist der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Universalprozessorkern(e) 1034 auf. Grafikapplikation 1010 und Betriebssystem 1020 laufen jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ab.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programme, die Shader-Anweisungen 1012 enthalten. Die Shader-Sprache-Anweisungen können in einer High-Level-Shader-Sprache sein, wie etwa der High-Level-Shader-Sprache (HLSL) von Direc3D, der OpenGL Shader-Sprache (GLSL) und so weiter. Die Anwendung weist auch ausführbare Anweisungen 1014 in einer Maschinensprache, die zur Ausführung durch den Universalprozessorkern 1034 geeignet ist, auf. Die Anwendung weist auch Grafikobjekte 1016 auf, die durch Vertexdaten definiert sind.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft ® Windows ®-Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein UNIX-ähnliches Betriebssystem mit offener Quelle, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022 unterstützen, wie etwa die Direct3D-API, die OpenGL API oder die Vulkan-API. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 1020 einen Frontend-Shader-Compiler 1024, um jegliche Shader-Anweisungen 1012 in HLSL in eine Shader-Sprache niedrigerer Ebene zu kompilieren. Die Kompilierung kann eine Just-in-time(JIT)-Kompilierung sein oder die Anwendung kann eine Shader-Vorkompilierung durchführen. In einigen Ausführungsformen werden High-Level-Shader während der Kompilierung der 3D-Grafikanwendung 1010 in Low-Level-Shader kompiliert. In einigen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform bereitgestellt, wie etwa einer Version der standardmäßigen tragbaren Zwischendarstellung (SPIR), die von der Vulkan API verwendet wird.
In einigen Ausführungsformen enthält der Benutzermodusgrafiktreiber 1026 einen Backend-Shader-Compiler xxx, um die Shaderanweisungen 1012 in eine hardwarespezifische Repräsentation umzuwandeln. Wenn die OpenGL API in Verwendung ist, werden Shader-Anweisungen 1012 in der GLSL-Hochsprache an einen Benutzermodusgrafiktreiber 1026 zur Kompilierung weitergeleitet. In einigen Ausführungsformen verwendet der Benutzermodusgrafiktreiber 1026 Betriebssystem-Kernel-Modus-Funktionen 1028, um mit einem Kernel-Modus-Grafiktreiber 1029 zu kommunizieren. In einigen Ausführungsformen kommuniziert der Kernmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen zu versenden.
IP-Kern-Implementierungen
Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch einen repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik innerhalb einer integrierten Schaltung, wie zum Beispiel einem Prozessor, repräsentiert und/oder definiert. Das maschinenlesbare Medium kann zum Beispiel Anweisungen aufweisen, die verschiedene Logik innerhalb des Prozessors repräsentieren. Wenn sie von einer Maschine gelesen werden, können die Anweisungen bewirken, dass die Maschine die Logik herstellt, um die hier beschriebenen Techniken durchzuführen. Solche Repräsentationen, die als „IP-Kerne“ bekannt sind, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium als ein Hardwaremodell gespeichert werden können, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann verschiedenen Kunden oder Herstellungsanlagen zugeführt werden, die das Hardwaremodell auf Herstellungsmaschinen laden, die die integrierte Schaltung herstellen. Die intergrierte Schaltung kann so gefertigt sein, dass die Schaltung Operationen durchführt, die in Verbindung mit einer beliebigen der hier beschriebenen Ausführungsformen beschrieben sind.
11A ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem 1100 veranschaulicht, das zum Herstellen einer integrierten Schaltung zum Durchführen von Operationen verwendet werden kann, gemäß einer Ausführungsform. Das IP-Kernentwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs zu erzeugen, die in ein größeres Design integriert werden können oder verwendet werden können, um eine gesamte integrierte Schaltung (z. B. eine integrierte SOC-Schaltung) zu konstruieren. Eine Designeinrichtung 1130 kann eine Softwaresimulation 1110 eines IP-Kern-Designs in einer höheren Programmiersprache (z. B. C/C ++) generieren. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu gestalten, zu testen und zu verifizieren. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Zeitsteuerungssimulationen umfassen. Aus dem Simulationsmodell 1112 kann dann ein Register Transfer Level (RTL) Design 1115 erstellt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Signale zwischen Hardwareregistern modelliert, einschließlich der assoziierten Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs niedrigerer Ebene auf dem Logikpegel oder Transistorpegel erzeugt, gestaltet oder synthetisiert werden. Dementsprechend können die speziellen Einzelheiten des anfänglichen Designs und der Simulation variieren.
Das RTL-Design 1115 oder Äquivalent kann ferner durch die Designeinrichtung zu einem Hardwaremodell 1120 synthetisiert werden, das in einer Hardwarebeschreibungssprache (HDL) oder einer anderen Repräsentation physischer Designdaten vorliegen kann. Die HDL kann ferner simuliert oder getestet werden, um das IP-Kerndesign zu verifizieren. Das IP-Kerndesign kann zur Lieferung an eine Fertigungseinrichtung 1165 der 3. Partei unter Verwendung eines nichtflüchtigen Speichers 1140 (z. B. Festplatte, Flash-Speicher oder ein beliebiges nichtflüchtiges Speichermedium) gespeichert werden. Alternativ dazu kann das IP-Kerndesign über eine drahtgebundene Verbindung 1150 oder eine drahtlose Verbindung 1160 (z. B. über das Internet) übertragen werden. Die Fertigungseinrichtung 1165 kann dann eine integrierte Schaltung fertigen, die mindestens teilweise auf dem IP-Kerndesign basiert. Die gefertigte integrierte Schaltung kann dazu konfiguriert sein, Operationen gemäß mindestens einer hier beschriebenen Ausführungsform durchzuführen.
11B veranschaulicht eine Querschnittsseitenansicht einer integrierten Schaltungs-Package-Baugruppe 1170 gemäß einigen hier beschriebenen Ausführungsformen. Die integrierte Schaltungs-Package-Baugruppe 1170 veranschaulicht eine Implementierung einer oder mehrerer Prozessor- oder Beschleunigervorrichtungen, wie hier beschrieben. Die Package-Baugruppe 1170 weist mehrere Hardwarelogikeinheiten 1172, 1174 auf, die mit einem 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 von beliebigen des einen oder der mehreren Prozessorkerne, des einen oder der mehreren Grafikprozessoren oder anderer hier beschriebener Beschleunigervorrichtungen aufweisen. Jede Logikeinheit 1172, 1174 kann innerhalb eines Halbleiter-Dies implementiert sein und über eine Zwischenverbindungsstruktur 1173 mit dem Substrat 1180 gekoppelt sein. Die Zwischenverbindungsstruktur 1173 kann dazu konfiguriert sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten, und kann Zwischenverbindungen aufweisen, wie etwa unter anderem Höcker oder Säulen. In einigen Ausführungsformen kann die Zwischenverbindungsstruktur 1173 dazu konfiguriert sein, elektrische Signale, wie etwa zum Beispiel Eingabe/Ausgabe(E/A)-Signale und/oder Leistungs- oder Massesignale, die mit dem Betrieb der Logik 1172, 1174 assoziiert sind, zu leiten. In einigen Ausführungsformen ist das Substrat 1180 ein epoxidbasiertes Laminatsubstrat. Das Substrat 1180 kann in anderen Ausführungsformen andere geeignete Typen von Substraten aufweisen. Die Package-Baugruppe 1170 kann über eine Package-Zwischenverbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Package-Zwischenverbindung 1183 kann mit einer Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie etwa einer Hauptplatine, einem anderen Chipsatz oder einem Mehrchipmodul, zu leiten.
In einigen Ausführungsformen sind die Logikeinheiten 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die dazu konfiguriert ist, elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Brücke 1182 kann eine dichte Interconnect-Struktur sein, die eine Route für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat aufweisen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Routing-Merkmale können auf dem Brückensubstrat 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 hier beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies aufweisen. Der eine oder die mehreren Dies können durch keine oder mehr Brücken verbunden sein, da die Brücke 1182 ausgelassen werden kann, wenn die Logik auf einem einzelnen Die enthalten ist. Alternativ dazu können mehrere Dies oder Logikeinheiten durch eine oder mehrere Brücken verbunden sein. Zusätzlich können mehrere Logikeinheiten, Dies und Brücken in anderen möglichen Konfigurationen, einschließlich dreidimensionaler Konfigurationen, miteinander verbunden sein.
11C veranschaulicht eine Package-Baugruppe 1190, die mehrere Einheiten von Hardwarelogik-Chiplets aufweist, die mit einem Substrat 1180 (z. B. Basis-Die) verbunden sind. Eine Grafikverarbeitungseinheit, ein Parallelprozessor und/oder ein Rechenbeschleuniger, wie hier beschrieben, können aus diversen Siliziumchiplets zusammengesetzt sein, die separat hergestellt werden. In diesem Zusammenhang ist ein Chiplet eine mindestens teilweise gepackte integrierte Schaltung, die unterschiedliche Logikeinheiten aufweist, die mit anderen Chiplets zu einem größeren Package zusammengesetzt werden können. Ein verschiedener Satz von Chiplets mit unterschiedlicher IP-Kernlogik kann zu einer einzigen Vorrichtung zusammengefasst werden. Zusätzlich können die Chiplets mittels aktiver Interposertechnologie in einen Basis-Die oder Basis-Chiplet integriert werden. Die hier beschriebenen Konzepte ermöglichen die Verschaltung und Kommunikation zwischen den verschiedenen Formen von IP innerhalb der GPU. IP-Kerne können mit unterschiedlichen Prozesstechnologien hergestellt und während der Herstellung zusammengesetzt werden, was die Komplexität des Zusammenführens mehrerer IPs, insbesondere an einem großen SoC mit mehreren Geschmacks-IPs, zu demselben Herstellungsprozess vermeidet. Die Ermöglichung der Verwendung mehrerer Prozesstechnologien verbessert die Marktzeit und stellt einen kostengünstigen Weg bereit, mehrere Produkt-SKUs zu erzeugen. Darüber hinaus sind die disaggregierten IPs für ein unabhängiges Ansteuern mit Leistung besser geeignet, Komponenten, die bei einer bestimmten Arbeitslast nicht verwendet werden, können ausgeschaltet werden, wodurch der Gesamtleistungsverbrauch reduziert wird.
Die Hardware-Logik-Chiplets können Spezialhardware-Logik-Chiplets 1172, Logik- oder E/A-Chiplets 1174 und/oder Speicher-Chiplets 1175 aufweisen. Die Hardware-Logik-Chiplets 1172 und die Logik- oder E/A-Chiplets 1174 können mindestens teilweise in konfigurierbarer Logik- oder Festfunktionalitätslogikhardware implementiert werden und können einen oder mehrere Teile beliebiger des einen oder der mehreren Prozessorkerne, des einen oder der mehreren Grafikprozessoren, der Parallelprozessoren oder anderer hierin beschriebener Beschleunigervorrichtungen aufweisen. Die Speicher-Chiplets 1175 können DRAM(z. B. GDDR, HBM)-Speicher oder Cache(SRAM)-Speicher sein.
Jedes Chiplet kann als separater Halbleiter-Die gefertigt und über eine Interconnect-Struktur 1173 mit dem Substrat 1180 gekoppelt werden. Die Interconnect-Struktur 1173 kann dazu konfiguriert sein, elektrische Signale zwischen den verschiedenen Chiplets und der Logik innerhalb des Substrats 1180 zu routen. Die Interconnect-Struktur 1173 kann Interconnects wie etwa unter anderem Kontakthügel oder Säulen aufweisen. In einigen Ausführungsformen kann die Interconnect-Struktur 1173 dazu konfiguriert sein, elektrische Signale, wie etwa zum Beispiel Eingabe/Ausgabe(E/A)-Signale und/oder Leistungs- oder Massesignale, zu routen, die mit dem Betrieb der Logik, E/A und Speicher-Chiplets assoziiert sind.
In einigen Ausführungsformen ist das Substrat 1180 ein epoxidbasiertes Laminatsubstrat. Das Substrat 1180 kann in anderen Ausführungsformen andere geeignete Typen von Substraten umfassen. Die Package-Baugruppe 1190 kann über eine Package-Zwischenverbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Package-Zwischenverbindung 1183 kann mit einer Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie etwa einer Hauptplatine, einem anderen Chipsatz oder einem Mehrchipmodul, zu leiten.
In einigen Ausführungsformen können eine Logik oder ein E/A-Chiplet 1174 und ein Speicher-Chiplet 1175 elektrisch über eine Brücke 1187 gekoppelt sein, die dazu konfiguriert ist, elektrische Signale zwischen der Logik oder dem E/A-Chiplet 1174 und einem Speicher-Chiplet 1175 zu leiten. Die Brücke 1187 kann eine dichte Interconnect-Struktur sein, die eine Route für elektrische Signale bereitstellt. Die Brücke 1187 kann ein Brückensubstrat aufweisen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Routing-Merkmale können auf dem Brückensubstrat ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen dem Logik- oder E/A-Chiplet 1174 und einem Speicher-Chiplet 1175 bereitzustellen. Die Brücke 1187 kann auch als Siliziumbrücke oder Interconnect-Brücke bezeichnet werden. Zum Beispiel ist die Brücke 1187 in einigen Ausführungsformen eine eingebettete Multi-Die-Interconnect-Brücke (EMIB: Embedded Multi-Die Interconnect Bridge). In einigen Ausführungsformen kann die Brücke 1187 einfach eine direkte Verbindung von einem Chiplet zu einem anderen Chiplet sein.
Das Substrat 1180 kann Hardwarekomponenten für die E/A 1191, den Cachespeicher 1192 und andere Hardwarelogik 1193 aufweisen. Ein Fabric 1185 kann in das Substrat 1180 eingebettet sein, um eine Kommunikation zwischen den verschiedenen Logik-Chiplets und der Logik 1191, 1193 innerhalb des Substrats 1180 zu ermöglichen. In einer Ausführungsform können die E/A 1191, das Fabric 1185, der Cache, die Brücke und andere Hardwarelogik 1193 in einen Basis-Die integriert sein, der auf dem Substrat 1180 geschichtet ist.
In diversen Ausführungsformen kann eine Package-Baugruppe 1190 weniger oder mehr Komponenten und Chiplets aufweisen, die durch ein Fabric 1185 oder eine oder mehrere Brücken 1187 miteinander verbunden sind. Die Chiplets innerhalb der Package-Baugruppe 1190 können in einer 3D- oder 2,5D-Anordnung angeordnet sein. Im Allgemeinen können Brückenstrukturen 1187 verwendet werden, um ein Punkt-zu-Punkt-Interconnect zwischen beispielsweise Logik- oder E/A-Chiplets und Speicher-Chiplets zu ermöglichen. Das Fabric 1185 kann verwendet werden, um die verschiedenen Logik- und/oder E/A-Chiplets (z. B. die Chiplets 1172, 1174, 1191, 1193) miteinander, mit anderen Logik- und/oder E/A-Chiplets zu verbinden. In einer Ausführungsform kann der Cache-Speicher 1192 innerhalb des Substrats als ein globaler Cache für die Package-Baugruppe 1190, Teil eines verteilten globalen Caches oder als ein dedizierter Cache für das Fabric 1185 fungieren.
11D veranschaulicht eine Package-Baugruppe 1194 einschließlich austauschbarer Chiplets 1195 gemäß einer Ausführungsform. Die austauschbaren Chiplets 1195 können in standardisierte Steckplätze auf einem oder mehreren Basis-Chiplets 1196, 1198 montiert werden. Die Basis-Chiplets 1196, 1198 können über ein Brücken-Interconnect 1197 gekoppelt sein, das den anderen hierin beschriebenen Brücken-Interconnects ähnlich sein kann und beispielsweise eine EMIB sein kann. Speicher-Chiplets können auch über ein Brücken-Interconnect mit Logik- oder E/A-Chiplets verbunden sein. E/A- und Logik-Chiplets können über ein Interconnect-Fabric kommunizieren. Die Basis-Chiplets können jeweils einen oder mehrere Steckplätze in einem standardisierten Format für Logik oder E/A oder Speicher/Cache unterstützen.
In einer Ausführungsform können SRAM- und Leistungslieferschaltungen in einem oder mehreren der Basis-Chiplets 1196, 1198 gefertigt werden, die unter Verwendung einer anderen Prozesstechnologie relativ zu den austauschbaren Chiplets 1195, die auf den Basischiplets gestapelt sind, gefertigt werden können. Beispielsweise können die Basis-Chiplets 1196, 1198 unter Verwendung einer größeren Prozesstechnologie hergestellt werden, während die austauschbaren Chiplets unter Verwendung einer kleineren Prozesstechnologie hergestellt werden können. Einer oder mehrere der austauschbaren Chiplets 1195 können Speicher(z. B. DRAM)-Chiplets sein. Für die Package-Baugruppe 1194 können unterschiedliche Speicherdichten basierend auf der Leistung und/oder Leistungsfähigkeit ausgewählt werden, die für das Produkt, das die Package-Baugruppe 1194 verwendet, angestrebt wird. Zusätzlich dazu können Logik-Chiplets mit einer anderen Anzahl von Typen von Funktionseinheiten zum Zeitpunkt des Zusammensetzens basierend auf der Leistung und/oder Leistungsfähigkeit, die für das Produkt angestrebt wird, ausgewählt werden. Zusätzlich können Chiplets, die IP-Logikkerne unterschiedlicher Typen aufweisen, in die austauschbaren Chiplet-Steckplätze eingefügt werden, wodurch Hybridprozessordesigns ermöglicht werden, die IP-Blöcke unterschiedlicher Technologie mittels Mix-and-Match kombinieren können.
Beispielhafte integrierte System-on-Chip-Schaltung
Die 12-13 veranschaulichen beispielhafte integrierte Schaltungen und assoziierte Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden können, gemäß verschiedenen hierin beschriebenen Ausführungsformen. Zusätzlich zu dem, was veranschaulicht ist, können andere Logik und Schaltungen enthalten sein, einschließlich zusätzlicher Grafikprozessoren/-kerne, Peripherieschnittstellensteuerungen oder Universalprozessorkerne.
12 ist ein Blockdiagramm, das eine beispielhafte integrierte System-on-Chip-Schaltung 1200 veranschaulicht, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. Die beispielhafte integrierte Schaltung 1200 weist einen oder mehrere Anwendungsprozessoren 1205 (z. B. CPUs), mindestens einen Grafikprozessor 1210 auf und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 aufweisen, von denen jeder ein modularer IP-Kern von derselben oder mehreren unterschiedlichen Gestaltungseinrichtungen sein kann. Die integrierte Schaltung 1200 weist Peripheriegerät- oder Buslogik einschließlich einer USB-Steuerung 1225, einer UART-Steuerung 1230, einer SPI/SDIO-Steuerung 1235 und einer I2S/I2C-Steuerung 1240 auf. Zusätzlich dazu kann die integrierte Schaltung eine Anzeigevorrichtung 1245 aufweisen, die mit einer High-Definition-Multimedia-Schnittstellen(HDMI)-steuerung 1250 und/oder einer Mobilindustrieprozessorschnittstellen(MIPI)-Anzeigeschnittstelle 1255 gekoppelt ist. Die Speicherung kann durch ein Flash-Speichersubsystem 1260 bereitgestellt werden, das Flash-Speicher und eine Flash-Speichersteuerung aufweist. Eine Speicherschnittstelle kann über eine Speichersteuerung 1265 zum Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt werden. Manche integrierte Schaltungen weisen zusätzlich eine eingebettete Sicherheits-Engine 1270 auf.
Die 13-14 sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung innerhalb eines SoC gemäß hier beschriebenen Ausführungsformen veranschaulichen. 13 veranschaulicht einen beispielhaften Grafikprozessor 1310 einer integrierten System-on-Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. 13B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 1340 einer integrierten System-on-Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. Der Grafikprozessor 1310 aus 13 ist ein Beispiel für einen Niedrigleistungsgrafikprozessorkern. Der Grafikprozessor 1340 von 13B ist ein Beispiel für einen Grafikprozessorkern höherer Leistung. Jeder der Grafikprozessoren 1310, 1340 kann Varianten des Grafikprozessors 1210 von 12 sein.
Wie in 13 gezeigt, weist der Grafikprozessor 1310 einen Vertexprozessor 1305 und einen oder mehrere Fragmentprozessor(en) 1315A-1315N (z. B. 1315A, 1315B, 1315C, 1315D bis 1315 N-1 und 1315N) auf. Der Grafikprozessor 1310 kann verschiedene Shader-Programme über separate Logik ausführen, so dass der Vertex-Prozessor 1305 zum Ausführen von Operationen für Vertex-Shader-Programme optimiert ist, während der eine oder die mehreren Fragment-Prozessor(en) 1315A-1315N
Fragment(z. B. Pixel)-Shading-Operationen für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertexprozessor 1305 führt die Vertexverarbeitungsstufe der 3D-Grafik-Pipeline durch und erzeugt Primitive und Vertexdaten. Der eine oder die mehreren Fragmentprozessoren 1315A-1315N verwenden die Primitiv- und Vertexdaten, die durch den Vertexprozessor 1305 erzeugt werden, um einen Framepuffer zu erzeugen, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform ist/sind der/die Fragment-Prozessor(en) 1315A-1315N dazu optimiert, Fragment-Shader-Programme, wie sie in der OpenGL-API bereitgestellt werden, auszuführen, die verwendet werden können, um ähnliche Operationen wie ein Pixel-Shader-Programm durchzuführen, wie es in der Direct-3D-API bereitgestellt wird.
Der Grafikprozessor 1310 weist zusätzlich eine oder mehrere Speicherverwaltungseinheiten (MMUs) 1320A-1320 B, einen oder mehrere Cache(s) 1325A-1325B und eine oder mehrere Schaltungsverbindungen 1330A-1330B auf. Die eine oder die mehreren MMU(s) 1320A-1320B stellen eine Abbildung von virtuellen auf physische Adressen für den Grafikprozessor 1310 bereit, einschließlich für den Vertex-Prozessor 1305 und/oder den/die Fragment-Prozessor(en) 1315A-1315N, die zusätzlich zu Vertex- oder Bild-/Texturdaten, die in dem einen oder den mehreren Caches 1325A-1325B gespeichert sind, Vertex- oder Bild-/Texturdaten referenzieren können, die im Speicher gespeichert sind. In einer Ausführungsform können die eine oder die mehreren MMU(s) 1320A-1320B mit anderen MMUs innerhalb des Systems synchronisiert sein, einschließlich einer oder mehrerer MMUs, die mit dem einen oder den mehreren Anwendungsprozessoren 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 von 12 assoziiert sind, so dass jeder Prozessor 1205-1220 an einem gemeinsam genutzten oder einheitlichen virtuellen Speichersystem teilnehmen kann. Die eine oder die mehreren Schaltungszwischenverbindungen 1330A-1330B ermöglichen gemäß Ausführungsformen, dass der Grafikprozessor 1310 mit anderen IP-Kernen innerhalb des SoC eine Schnittstelle bildet, entweder über einen internen Bus des SoC oder über eine direkte Verbindung.
Wie in 14 gezeigt, weist der Grafikprozessor 1340 die eine oder die mehreren MMU(s) 1320A-1320B, den/die Cache(s) 1325A-1325B und die Schaltungsverbindung(en) 1330A-1330B des Grafikprozessors 1310 von 13A auf. Der Grafikprozessor 1340 weist einen oder mehrere Shader-Kerne 1355A-1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N) auf, was für eine einheitliche Shader-Kernarchitektur sorgt, in der ein einzelner Kern oder Kerntyp alle Arten von programmierbarem Shader-Code ausführen kann, einschließlich Shader-Programmcode zum Implementieren von Vertex-Shadern, Fragment-Shadern und/oder Rechen-Shadern. Die genaue Anzahl der vorhandenen Shader-Kerne kann zwischen Ausführungsformen und Implementierungen variieren. Ferner weist der Grafikprozessor 1340 einen Inter-Kern-Aufgabenmanager 1345, der als ein Thread-Dispatcher zum Versenden von Ausführungs-Threads an einen oder mehrere Shader-Kerne 1355A-1355N fungiert, und eine Kachelungseinheit 1358 zum Beschleunigen von Kacheloperationen für kachelbasiertes Rendering auf, wobei die Rendering-Operationen für eine Szene in einen Bildraum unterteilt sind, um zum Beispiel lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder um die Verwendung von internen Caches zu optimieren.
STRAHLVERFOLGUNG MIT MASCHINELLEM LERNEN
Wie oben erwähnt, ist die Strahlverfolgung eine Grafikverarbeitungstechnik, bei der ein Lichttransport durch physisch basiertes Rendern simuliert wird. Eine der Schlüsseloperationen bei der Strahlverfolgung ist das Verarbeiten einer Sichtbarkeitsanfrage, die ein Traversierungs- und Schnittpunkttesten von Knoten in einer Bounding Volume Hierarchy (BVH) erfordert.
Strahl- und wegverfolgungsbasierte Techniken berechnen Bilder durch Verfolgen von Strahlen und Wegen durch jedes Pixel und Verwenden einer zufälligen Abtastung, um fortgeschrittene Effekte wie etwa Schatten, Glanz, indirekte Beleuchtung usw. zu berechnen. Das Verwenden von nur wenigen Proben ist schnell, produziert aber verrauschte Bilder, während das Verwenden vieler Proben Bilder hoher Qualität produziert, aber kostenprohibitiv ist.
Maschinelles Lernen umfasst eine beliebige Schaltungsanordnung, einen beliebigen Programmcode oder eine beliebige Kombination davon, die bzw. der in der Lage ist, die Leistungsfähigkeit einer spezifizierten Aufgabe progressiv zu verbessern oder progressiv genauere Vorhersagen oder Entscheidungen wiederzugeben. Manche Maschinenlern-Engines können diese Aufgaben durchführen oder diese Vorhersagen/Entscheidungen ergreifen, ohne explizit programmiert zu sein, um die Aufgaben durchzuführen oder die Vorhersagen/Entscheidungen zu ergreifen. Es gibt eine Vielzahl von maschinellen Lerntechniken, einschließlich (aber nicht beschränkt auf) überwachtes und halbüberwachtes Lernen, unüberwachtes Lernen und bestärkendes Lernen.
In den letzten Jahren ist eine Durchbruchslösung zum Strahl-/Wegverfolgen für Echtzeitverwendung in Form von „Entrauschen“ - dem Prozess des Verwendens von Bildverarbeitungstechniken, um qualitativ hochwertige gefilterte/entrauschte Bilder aus rauschbehafteten Eingaben mit niedriger Abtastzahl zu erzeugen - gekommen. Die effektivsten Entrauschungstechniken beruhen auf Maschinenlerntechniken, bei denen eine Maschinenlern-Engine lernt, wie ein verrauschtes Bild wahrscheinlich aussehen würde, als ob es mit mehr Abtastwerten berechnet würde. Bei einer bestimmten Implementierung wird das maschinelle Lernen durch ein neuronales Faltungsnetzwerk (CNN) durchgeführt; die zugrundeliegenden Prinzipien der Erfindung sind jedoch nicht auf eine CNN-Implementierung beschränkt. Bei einer solchen Implementierung werden Trainingsdaten mit Eingaben mit niedriger Abtastzahl und Ground-Wahrheit produziert. Das CNN ist trainiert, das konvergierte Pixel aus einer Nachbarschaft von rauschbehafteten Pixeleingaben um das betreffende Pixel herum vorherzusagen.
Obwohl nicht perfekt, hat sich diese AI-basierte Entrauschungstechnik als überraschend effektiv erwiesen. Es besteht jedoch der Vorbehalt, dass gute Trainingsdaten erforderlich sind, da das Netzwerk ansonsten die falschen Ergebnisse vorhersagen kann. Falls zum Beispiel ein animiertes Filmstudio ein entrauschendes CNN an vergangenen Filmen mit Szenen an Land trainiert hat und dann versucht hat, das trainierte CNN zu verwenden, um Frames von einem neuen Film, der auf Wasser festgelegt ist, zu entrauschen, wird die Entrauschungsoperation suboptimal durchgeführt.
Um dieses Problem zu adressieren, können Lerndaten dynamisch gesammelt werden, während sie wiedergegeben werden, und eine Maschinenlern-Engine, wie etwa ein CNN, kann basierend auf den Daten, auf denen sie gegenwärtig ausgeführt werden, kontinuierlich trainiert werden, wodurch die Maschinenlern-Engine für die vorliegende Aufgabe kontinuierlich verbessert wird. Daher kann eine Trainingsphase immer noch vor der Laufzeit durchgeführt werden, aber fortgesetzt werden, um die Maschinenlerngewichtungen nach Bedarf während der Laufzeit anzupassen. Dadurch werden die hohen Kosten des Berechnens der Referenzdaten, die für das Training benötigt werden, vermieden, indem die Erzeugung von Lerndaten auf eine Teilregion des Bildes in jedem Frame oder in allen N Frames beschränkt wird. Insbesondere werden die verrauschten Eingaben eines Frames zum Entrauschen des Vollframes mit dem aktuellen Netzwerk erzeugt. Zusätzlich wird ein kleiner Bereich von Referenzpixeln erzeugt und zum kontinuierlichen Training verwendet, wie nachfolgend beschrieben wird.
Obwohl hier eine CNN-Implementierung beschrieben ist, kann eine beliebige Form einer Maschinenlern-Engine verwendet werden, einschließlich unter anderem Systemen, die überwachtes Lernen (z. B. Aufbau eines mathematischen Modells eines Datensatzes, der sowohl die Eingaben als auch die gewünschten Ausgaben enthält), unüberwachtes Lernen (z. B. die die Eingabedaten für bestimmte Strukturtypen auswerten) und/oder eine Kombination aus überwachtem und unüberwachtem Lernen durchführen.
Bestehende Entrauschungsimplementierungen arbeiten in einer Trainingsphase und einer Laufzeitphase. Während der Trainingsphase wird eine Netzwerktopologie definiert, die eine Region von NxN Pixeln mit verschiedenen pixelweisen Datenkanälen, wie etwa Pixelfarbe, Tiefe, normal, normale Abweichung, Primitiv-IDs und Albedo, empfängt und eine finale Pixelfarbe erzeugt. Ein Satz von „repräsentativen“ Trainingsdaten wird unter Verwendung eines Frames von Eingaben mit niedriger Abtastzahl und Referenzieren der „gewünschten“ Pixelfarben, die mit einer sehr hohen Abtastzahl berechnet werden, erzeugt. Das Netzwerk wird auf diese Eingaben trainiert, wodurch ein Satz von „idealen“ Gewichtungen für das Netzwerk erzeugt wird. Bei diesen Implementierungen werden die Referenzdaten verwendet, um die Gewichtungen des Netzwerks zu trainieren, um die Ausgabe des Netzwerks am nächsten an das gewünschte Ergebnis anzupassen.
Zur Laufzeit werden die gegebenen, vorausberechneten idealen Netzwerkgewichtungen geladen und das Netzwerk initialisiert. Für jeden Frame wird ein Bild mit niedriger Abtastzahl von Entrauschungseingaben (d. h. das gleiche wie für das Training verwendet) erzeugt. Für jedes Pixel wird die gegebene Nachbarschaft von Eingaben der Pixel durch das Netzwerk geführt, um die „entrauschte“ Pixelfarbe vorherzusagen, wodurch ein entrauschter Rahmen erzeugt wird.
15 veranschaulicht eine anfängliche Trainingsimplementierung. Eine Maschinenlern-Engine 1500 (z. B. ein CNN) empfängt eine Region von N x N Pixeln als Bilddaten 1702 mit hoher Abtastzahl mit verschiedenen Pro-Pixel-Datenkanälen, wie etwa Pixelfarbe, Tiefe, normal, normale Abweichung, Primitiv-IDs und Albedo, und erzeugt finale Pixelfarben. Repräsentative Trainingsdaten werden unter Verwendung eines Rahmens von Eingaben 1501 mit niedriger Abtastzahl erzeugt. Das Netzwerk wird auf diese Eingaben trainiert, wodurch ein Satz von „idealen“ Gewichtungen 1505 erzeugt wird, die die Maschinenlern-Engine 1500 anschließend verwendet, um Bilder mit niedriger Abtastzahl zur Laufzeit zu entrauschen.
Um die obigen Techniken zu verbessern, wird die Entrauschungsphase zum Erzeugen neuer Trainingsdaten in jedem Frame oder einer Teilmenge von Frames (z. B. alle N Frames, wobei N = 2, 3, 4, 10, 25 usw.) erweitert. Insbesondere werden, wie in 16 veranschaulicht, eine oder mehrere Regionen in jedem Frame ausgewählt, hier als „neue Referenzregionen“ 1602 bezeichnet, die mit einer hohen Abtastzahl in einen separaten Puffer 1604 mit hoher Abtastzahl gerendert werden. Ein Puffer 1603 mit niedriger Abtastzahl speichert den Eingangsrahmen 1601 mit niedriger Abtastzahl (einschließlich der niedrigen Abtastregion 1604, das der neuen Referenzregion 1602 entspricht).
Die Lage der neuen Referenzregion 1602 kann zufällig gewählt werden. Alternativ dazu kann der Ort der neuen Referenzregion 1602 auf eine vorgegebene Weise für jedes neue Frame angepasst werden (z. B. unter Verwendung einer vorgegebenen Bewegung der Region zwischen Frames, beschränkt auf eine vorgegebene Region in der Mitte des Frames usw.).
Unabhängig davon, wie die neue Referenzregion ausgewählt wird, wird sie durch die Maschinenlern-Engine 1600 verwendet, um die trainierten Gewichtungen 1605, die zum Entrauschen verwendet werden, kontinuierlich zu verfeinern und zu aktualisieren. Insbesondere werden Referenzpixelfarben von jeder neuen Referenzregion 1602 und verrauschte Referenzpixeleingaben von einer entsprechenden Region 1607 mit niedriger Abtastzahl wiedergegeben. Ein ergänzendes Training wird dann auf der Maschinenlern-Engine 1600 unter Verwendung der Referenzregion 1602 mit hoher Abtastzahl und der entsprechenden Region 1607 mit niedriger Abtastzahl durchgeführt. Im Gegensatz zum anfänglichen Training wird dieses Training kontinuierlich während der Laufzeit für jede neue Referenzregion 1602 durchgeführt - wodurch sichergestellt wird, dass die Maschinenlern-Engine 1600 präzise trainiert wird. Zum Beispiel können pro Pixel Datenkanäle (z. B. Pixelfarbe, Tiefe, normal, normale Abweichung usw.) evaluiert werden, die die Maschinenlern-Engine 1600 verwendet, um Anpassungen an den trainierten Gewichtungen 1605 vorzunehmen. Wie im Trainingsfall (15), wird die Maschinenlern-Engine 1600 auf einen Satz idealer Gewichtungen 1605 zum Entfernen von Rauschen aus dem Eingangsrahmen 1601 mit niedriger Abtastzahl trainiert, um den entrauschten Rahmen 1620 zu erzeugen. Die trainierten Gewichtungen 1605 werden jedoch basierend auf neuen Bildeigenschaften neuer Typen von Eingangsframes 1601 mit niedriger Abtastzahl kontinuierlich aktualisiert.
Die Neutrainingsoperationen, die durch die Maschinenlern-Engine 1600 durchgeführt werden, können gleichzeitig in einem Hintergrundprozess auf der Grafikprozessoreinheit (GPU) oder dem Hostprozessor ausgeführt werden. Die Renderschleife, die als eine Treiberkomponente und/oder eine GPU-Hardwarekomponente implementiert sein kann, kann kontinuierlich neue Trainingsdaten (z. B. in der Form neuer Referenzregionen 1602) erzeugen, die sie in einer Warteschlange platziert. Der Hintergrundtrainierungsprozess, der auf der GPU oder dem Host-Prozessor ausgeführt wird, kann kontinuierlich die neuen Trainingsdaten aus dieser Warteschlange lesen, die Maschinenlern-Engine 1600 neu trainieren und sie mit neuen Gewichtungen 1605 in geeigneten Intervallen aktualisieren.
17 veranschaulicht ein Beispiel für eine solche Implementierung, bei der der Hintergrundtrainingprozess 1700 durch die Host-CPU 1710 implementiert wird. Insbesondere verwendet der Hintergrundtrainierungsprozess 1700 die neue Referenzregion 1602 mit hoher Abtastzahl und die entsprechende niedrige Abtastregion 1604, um die trainierten Gewichtungen 1605 kontinuierlich zu aktualisieren, wodurch die Maschinenlern-Engine 1600 aktualisiert wird.
Wie in 18A für das nicht beschränkende Beispiel für ein Online-Spiel mit mehreren Spielern veranschaulicht, erzeugen verschiedene Hostmaschinen 1820-1822 individuell Referenzregionen, die ein Hintergrundtrainingprozess 1700A-C an einen Server 1800 (wie etwa einen Spielserver) überträgt. Der Server 1800 führt dann ein Training auf einer Maschinenlern-Engine 1810 unter Verwendung der neuen Referenzregionen, die von jedem der Hosts 1821-1822 empfangen werden, durch, wobei die Gewichtungen 1805 aktualisiert werden, wie zuvor beschrieben. Sie überträgt diese Gewichtungen 1805 an die Host-Maschinen 1820, die die Gewichtungen 1605A-C speichern, wodurch jede einzelne Maschinenlern-Engine (nicht gezeigt) aktualisiert wird. Da dem Server 1800 eine große Anzahl von Referenzregionen in einem kurzen Zeitraum bereitgestellt werden kann, kann er die Gewichtungen für eine beliebige gegebene Anwendung (z. B. ein Online-Spiel), die durch die Benutzer ausgeführt wird, effizient und präzise aktualisieren.
Wie in 18B veranschaulicht, können die verschiedenen Hostmaschinen neue trainierte Gewichtungen (z. B. basierend auf Trainings-/Referenzregionen 1602, wie zuvor beschrieben) erzeugen und die neuen trainierten Gewichtungen gemeinsam mit einem Server 1800 (wie etwa einem Spielserver) nutzen oder alternativ dazu ein Peer-to-Peer-Teilungsprotokoll verwenden. Eine Maschinenlernverwaltungskomponente 1810 auf dem Server erzeugt einen Satz kombinierter Gewichtungen 1805 unter Verwendung der neuen Gewichtungen, die von jeder der Host-Maschinen empfangen werden. Die kombinierten Gewichtungen 1805 können zum Beispiel ein Durchschnitt sein, der aus den neuen Gewichtungen erzeugt und kontinuierlich aktualisiert wird, wie hier beschrieben. Sobald erzeugt, können Kopien der kombinierten Gewichtungen 1605A-C übertragen und auf jeder der Host-Maschinen 1820-1821 gespeichert werden, die dann die kombinierten Gewichtungen verwenden können, wie hier beschrieben, um Entrauschungsoperationen durchzuführen.
Der halbgeschlossene Schleifenaktualisierungsmechanismus kann auch vom Hardwarehersteller verwendet werden. Zum Beispiel kann das Referenznetzwerk als Teil des Treibers enthalten sein, der durch den Hardwarehersteller verteilt wird. Da der Treiber neue Trainingsdaten unter Verwendung der hier beschriebenen Techniken erzeugt und diese kontinuierlich an den Hardwarehersteller zurückgibt, verwendet der Hardwarehersteller diese Informationen, um seine Maschinenlernimplementierungen für die nächste Treiberaktualisierung weiter zu verbessern.
Bei einer beispielhaften Implementierung (z. B. in einer Stapelfilmrenderung auf einer Renderfarm) überträgt der Renderer die neu erzeugten Trainingsgebiete an einen dedizierten Server oder eine dedizierte Datenbank (in der Renderfarm dieses Studios), der/die diese Daten von mehreren Renderknoten im Laufe der Zeit aggregiert. Ein separater Prozess auf einer separaten Maschine verbessert kontinuierlich das dedizierte Entrauschungsnetzwerk des Studios und neue Renderaufgaben verwenden immer das neueste trainierte Netzwerk.
Ein maschinelles Lernverfahren ist in 19 veranschaulicht. Das Verfahren kann auf den hier beschriebenen Architekturen implementiert werden, ist aber 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 Bildframes erzeugt. Bei 1902 wird eine Maschinenlernentrauschungsengine unter Verwendung der Bilddaten mit hohem/niedrigen Abtastwert trainiert. Zum Beispiel kann ein Satz von Faltungs-Neuronalnetzwerkgewichtungen, die Pixelmerkmalen zugeordnet sind, gemäß dem Training aktualisiert werden. Es kann jedoch eine beliebige Maschinenlernarchitektur verwendet werden.
Bei 1903 werden zur Laufzeit Bildframes mit niedriger Abtastzahl zusammen mit mindestens einer Referenzregion mit einer hohen Abtastzahl erzeugt. Bei 1904 wird die Referenzregion mit hoher Abtastzahl durch die Maschinenlern-Engine und/oder separate Trainingslogik (z. B. Hintergrundtrainingsmodul 1700) verwendet, um das Training der Maschinenlern-Engine kontinuierlich zu verfeinern. Zum Beispiel kann die Referenzregion mit hoher Abtastzahl in Kombination mit einem entsprechenden Teil des Bildes mit niedriger Abtastzahl verwendet werden, um der Maschinenlern-Engine 1904 weiter zu lehren, wie am effektivsten eine Entrauschung durchzuführen ist. Bei einer CNN-Implementierung kann dies zum Beispiel das Aktualisieren der mit dem CNN assoziierten Gewichtungen umfassen.
Mehrere Variationen, die oben beschrieben sind, können implementiert werden, wie etwa die Art und Weise, auf die die Rückkopplungsschleife zu der Maschinenlern-Engine konfiguriert ist, die Entitäten, die die Trainingsdaten erzeugen, die Art und Weise, auf die die Trainingsdaten zu der Trainings-Engine zurückgekoppelt werden, und wie das verbesserte Netzwerk den Rendering-Engines bereitgestellt wird. Obwohl die oben beschriebenen Beispiele ein kontinuierliches Training unter Verwendung einer einzigen Referenzregion durchführen, kann zusätzlich eine beliebige Anzahl von Referenzregionen verwendet werden. Ferner können, wie zuvor erwähnt, die Referenzregionen unterschiedliche Größen aufweisen, auf unterschiedlichen Anzahlen von Bildframes verwendet werden und können unter Verwendung unterschiedlicher Techniken (z. B: zufällig, gemäß einem vorbestimmten Muster usw.) an unterschiedlichen Orten innerhalb der Bildframes positioniert werden.
Obwohl zusätzlich ein neuronales Faltungsnetzwerk (CNN) als ein Beispiel für eine Maschinenlern-Engine 1600 beschrieben ist, können die zugrundeliegenden Prinzipien der Erfindung unter Verwendung einer beliebigen Form einer Maschinenlern-Engine implementiert werden, die in der Lage ist, ihre Ergebnisse unter Verwendung neuer Trainingsdaten kontinuierlich zu verfeinern. Als Beispiel und nicht einschränkend umfassen andere Maschinenlernimplementierungen das Gruppenverfahren der Datenverarbeitung (GMDH), langer Kurzzeitspeicher, Deep-Reservoir-Computing, Deep-Belief-Netzwerke, Tensor-Deep-Stacking-Netzwerke und Deep-Prädiktionscodierungsnetzwerke, um einige zu nennen.
VORRICHTUNG UND VERFAHREN ZUR EFFIZIENTEN VERTEILTEN ENTRAUSCHUNG
Wie oben beschrieben, ist die Entrauschung zu einem kritischen Merkmal für Echtzeit-Strahlverfolgung mit glatten, rauschlosen Bildern geworden. Rendern kann über ein verteiltes System auf mehreren Vorrichtungen erfolgen, aber bisher arbeiten die existierenden Entrauschungsrahmen alle auf einer einzigen Instanz auf einer einzigen Maschine. Falls Rendern über mehrere Vorrichtungen durchgeführt wird, haben sie möglicherweise nicht alle gerenderten Pixel, die zum Berechnen eines entrauschten Teils des Bildes zugänglich sind.
Es wird ein verteilter Entrauschungsalgorithmus präsentiert, der sowohl mit künstlichen Intelligenz (AI) als auch Nicht-AI-basierten Entrauschungstechniken arbeitet. Regionen des Bildes werden entweder bereits über Knoten von einer verteilten Render-Operation verteilt oder von einem einzelnen Rahmenpuffer aufgeteilt und verteilt. Geisterregionen benachbarter Regionen, die zum Berechnen einer ausreichenden Entrauschung 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 mehrere Knoten 2021-2023, die ein Rendern durchführen. Obwohl der Einfachheit halber nur drei Knoten veranschaulicht sind, sind die zugrundeliegenden Prinzipien der Erfindung nicht auf eine bestimmte Anzahl von Knoten beschränkt. Tatsächlich kann ein einziger 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 Regionen 2011-2013 führt. Obwohl rechteckige Regionen 2011-2013 in 20 gezeigt sind, können Regionen mit einer beliebigen Form verwendet werden und eine beliebige Vorrichtung kann eine beliebige Anzahl von Regionen verarbeiten. Die Regionen, die ein Knoten benötigt, um eine ausreichend glatte Entrauschungsoperation durchzuführen, werden als Geisterregionen 2011-2013 bezeichnet. Mit anderen Worten repräsentieren die Geisterregionen 2001-2003 die Gesamtheit von Daten, die erforderlich sind, um eine Entrauschung mit einem spezifizierten Qualitätsniveau durchzuführen. Durch Absenken des Qualitätsniveaus wird die Größe der Geisterregion und damit die benötigte Datenmenge verringert und durch Anheben des Qualitätsniveaus wird die Geisterregion und entsprechende benötigte Daten erhöht.
Falls ein Knoten, wie etwa der Knoten 2021, eine lokale Kopie eines Teils der Geisterregion 2001 aufweist, die erforderlich ist, um seine Region 2011 mit einem spezifizierten Qualitätsniveau zu entrauschen, wird der Knoten die erforderlichen Daten von einem oder mehreren „benachbarten“ Knoten abrufen, wie etwa Knoten 2022, der einen Teil der Geisterregion 2001 besitzt, wie veranschaulicht. Gleichermaßen wird, falls der Knoten 2022 eine lokale Kopie eines Teils der Geisterregion 2002 aufweist, der erforderlich ist, um dessen Region 2012 auf dem spezifizierten Qualitätsniveau zu entrauschen, der Knoten 2022 die erforderlichen Geisterregionsdaten 2032 von dem Knoten 2021 abrufen. Der Abruf kann über einen Bus, eine Zwischenverbindung, eine Hochgeschwindigkeits-Speicherstruktur, ein Netzwerk (z. B. Hochgeschwindigkeits-Ethernet) durchgeführt werden oder kann sogar eine On-Chip-Zwischenverbindung in einem Mehrkern-Chip sein, die in der Lage ist, Rendering-Arbeit auf mehrere Kerne zu verteilen (z. B. die zum Rendern großer Bilder mit entweder extremen Auflösungen oder zeitlich variierend verwendet werden). Jeder Knoten 2021-2023 kann eine individuelle Ausführungseinheit oder einen spezifizierten Satz von Ausführungseinheiten innerhalb eines Grafikprozessors umfassen.
Die konkret zu sendende Datenmenge ist abhängig von den verwendeten Entrauschungstechniken. Ferner können die Daten aus der Geisterregion beliebige Daten umfassen, die zum Verbessern der Entrauschung jeder jeweiligen Region benötigt werden. Zum Beispiel können die Geisterregionsdaten Bildfarben/Wellenlängen, Intensität/Alphadaten und/oder Normale umfassen. Die zugrundeliegenden Prinzipien der Erfindung sind jedoch nicht auf einen bestimmten Satz von Geisterregionsdaten beschränkt.
ZUSÄTZLICHE DETAILS
Für langsamere Netzwerke oder Zwischenverbindungen kann eine Komprimierung dieser Daten unter Verwendung einer bestehenden verlustfreien oder verlustbehafteten Universalkomprimierung genutzt werden. Beispiele umfassen unter anderem zlib, gzip und Lempel-Ziv-Markov-Kettenalgorithmus (LZMA). Eine weitere inhaltsspezifische Komprimierung kann verwendet werden, indem angemerkt wird, dass die Delta-in-Ray-Trefferinformationen zwischen Frames recht dünn sein können und nur die Abtastungen, die zu diesem Delta beitragen, gesendet werden müssen, wenn der Knoten bereits die gesammelten Deltas von vorherigen Frames aufweist. Diese können selektiv zu Knoten geschoben werden, die diese Abtastwerte i sammeln, oder der Knoten i kann Abtastwerte von anderen Knoten anfordern. Für bestimmte Datentypen und Programmcode wird verlustfreie Komprimierung verwendet, während für andere Datentypen verlustbehaftete Daten verwendet werden.
21 veranschaulicht zusätzliche Einzelheiten der Interaktionen zwischen Knoten 2021-2022. Jeder Knoten 2021-2022 weist eine Strahlverfolgungs-Rendering-Schaltungsanordnung 2081-2082 zum Rendern der jeweiligen Bildregionen 2011-2012 und Geisterregionen 2001-2002 auf. Entrauscher 2100-2111 führen Entrauschungsoperationen jeweils an den Regionen 2011-2012 aus, die jeder Knoten 2021-2022 für das Rendern und Entrauschen verantwortlich ist. Die Entrauscher 2021-2022 können zum Beispiel eine Schaltungsanordnung, Software oder eine beliebige Kombination davon aufweisen, um die entrauschten Regionen 2121-2122 jeweils zu erzeugen. Wie erwähnt, müssen, wenn entrauschte Regionen erzeugt werden, die Entrauscher 2021-2022 möglicherweise auf Daten innerhalb einer Geisterregion angewiesen sein, die einem anderen Knoten gehört (z. B. der Entrauscher 2100 benötigt möglicherweise Daten aus der Geisterregion 2002, die dem Knoten 2022 gehört).
Dementsprechend können die Entrauscher 2100-2111 die entrauschten Regionen 2121-2122 unter Verwendung von Daten von Regionen 2011-2012 bzw. Geisterregionen 2001-2002 erzeugen, von denen mindestens ein Teil von einem anderen Knoten empfangen werden kann. Die Regionsdatenmanager 2101-2102 können Datentransfers von Geisterregionen 2001-2002 verwalten, wie hier beschrieben. Komprimierer/Dekomprimierereinheiten 2131-2132 können eine Komprimierung bzw. Dekomprimierung der Geisterregionsdaten durchführen, die zwischen den Knoten 2021-2022 ausgetauscht werden.
Beispielsweise kann der Regionsdatenmanager 2101 des Knotens 2021 auf Anforderung von Knoten 2022 Daten von der Geisterregion 2001 zu dem Komprimierer/Dekomprimierer 2131 senden, der die Daten komprimiert, um komprimierte Daten 2106 zu erzeugen, die er zu Knoten 2022 überträgt, wodurch Bandbreite über die Zwischenverbindung, das Netzwerk, den Bus oder eine andere Datenkommunikationsverbindung reduziert wird. Der Komprimierer/Dekomprimierer 2132 des Knotens 2022 dekomprimiert dann die komprimierten Daten 2106 und der Entrauscher 2111 verwendet die dekomprimierten Geisterdaten, um eine entrauschte Region 2012 höherer Qualität zu erzeugen, als dies nur mit Daten aus der Region 2012 möglich wäre. Der Regionendatenmanager 2102 kann die dekomprimierten Daten von der Geisterregion 2001 in einem Cache, einem Speicher, einer Registerdatei oder einem anderen Speicher speichern, um sie dem Entrauscher 2111 zur Verfügung zu stellen, wenn die entrauschte Region 2122 erzeugt wird. Ein ähnlicher Satz von Operationen kann durchgeführt werden, um die Daten von der Geisterregion 2002 an den Entrauscher 2100 auf dem Knoten 2021 bereitzustellen, der die Daten in Kombination mit Daten von der Region 2011 verwendet, um eine entrauschte Region 2121 mit höherer Qualität zu erzeugen.
ERFASSEN VON DATEN ODER RENDERN
Falls die Verbindung zwischen Vorrichtungen, wie etwa den Knoten 2021-2022, langsam ist (d. h. niedriger als eine Schwellenlatenz und/oder Schwellenbandbreite), kann es schneller sein, Geisterregionen lokal zu rendern, anstatt die Ergebnisse von anderen Vorrichtungen anzufordern. Dies kann zur Laufzeit durch Verfolgung von Netzwerktransaktionsgeschwindigkeiten und linear extrapolierten Renderzeiten für die Geisterregionsgröße bestimmt werden. In solchen Fällen, in denen es schneller ist, die gesamte Geisterregion herauszuführen, können mehrere Vorrichtungen das Rendern derselben Teile des Bildes enden. Die Auflösung des gerenderten Teils der Geisterregionen kann basierend auf der Varianz der Basisregion und dem bestimmten Unschärfegrad angepasst werden.
LASTAUSGLEICH
Statische und/oder dynamische Lastausgleichsschemata können verwendet werden, um die Verarbeitungslast unter den verschiedenen Knoten 2021-2023 zu verteilen. Zum dynamischen Lastausgleich kann die Varianz, die durch das Entrauschungsfilter bestimmt wird, sowohl mehr Zeit beim Entrauschen benötigen, als auch die Menge an Abtastwerten ansteuern, die zum Rendern einer speziellen Region der Szene verwendet werden, wobei geringe Varianz und unscharfe Regionen des Bilds weniger Abtastwerte erfordern. Die spezifischen Knoten zugewiesenen spezifischen Gebiete können dynamisch basierend auf Daten von vorherigen Frames angepasst werden oder dynamisch über Vorrichtungen kommuniziert werden, während sie rendern, so dass alle Vorrichtungen die gleiche Arbeitsmenge aufweisen.
22 veranschaulicht, wie ein Monitor 2201-2202, der auf jedem jeweiligen Knoten 2021-2022 läuft, Leistungsfähigkeitsmetrikdaten sammelt, einschließlich unter anderem der Zeit, die verbraucht wird, um Daten über die Netzwerkschnittstelle 2211-2212 zu übertragen, der Zeit, die verbraucht wird, wenn eine Region (mit und ohne Geisterregionsdaten) entrauscht wird, und der Zeit, die verbraucht wird, jede Region/Geisterregion wiederzugeben. Die Monitore 2201-2202 melden diese Leistungsfähigkeitsmetriken an einen Manager oder Lastausgleichsknoten 2201 zurück, der die Daten analysiert, um die aktuelle Arbeitslast an jedem Knoten 2021-2022 zu identifizieren, und potentiell einen effizienteren Modus des Verarbeitens der verschiedenen entrauschten Regionen 2121-2122 bestimmt. Der Managerknoten 2201 verteilt dann neue Arbeitslasten für neue Regionen an die Knoten 2021-2022 gemäß der detektierten Last. Zum Beispiel kann der Managerknoten 2201 mehr Arbeit zu jenen Knoten übertragen, die nicht stark belastet sind, und/oder Arbeit von jenen Knoten neu zuweisen, die überlastet sind. Zusätzlich dazu kann der Lastausgleichsknoten 2201 einen Rekonfigurationsbefehl übertragen, um die spezifische Weise anzupassen, auf die Rendern und/oder Entrauschen durch jeden der Knoten durchgeführt wird (von denen manche Beispiele oben beschrieben sind).
BESTIMMUNG VON GEISTERREGIONEN
Die Größen und Formen der Geisterregionen 2001-2002 können basierend auf dem durch die Entrauscher 2100-2111 implementierten Entrauschungsalgorithmus bestimmt werden. Ihre jeweiligen Größen können dann basierend auf der detektierten Varianz der zu entrauschenden Abtastwerte dynamisch modifiziert werden. Der Lernalgorithmus, der zum AI-Entrauschen selbst verwendet wird, kann zum Bestimmen geeigneter Regionsgrößen verwendet werden, oder in anderen Fällen, wie etwa einer bilateralen Unschärfe, wird die vorbestimmte Filterbreite die Größe der Geisterregionen 2001-2002 bestimmen. Bei einer beispielhaften Implementierung, die einen Lernalgorithmus verwendet, kann die Maschinenlern-Engine auf dem Managerknoten 2201 ausgeführt werden und/oder Teile des Maschinenlernens können auf jedem der einzelnen Knoten 2021-2023 ausgeführt werden (siehe z. B. 18A-B und assoziierter Text oben).
SAMMELN DES ENDGÜLTIGEN BILDS
Das endgültige Bild kann erzeugt werden, indem die gerenderten und entrauschten Regionen von jedem der Knoten 2021-2023 gesammelt werden, ohne dass die Geisterregionen oder Normalen benötigt werden. In 22 werden die entrauschten Regionen 2121-2122 zum Beispiel an den Regionsprozessor 2280 des Managerknotens 2201 übertragen, der die Regionen kombiniert, um das endgültige entrauschte Bild 2290 zu erzeugen, das dann auf einer Anzeige 2290 angezeigt wird. Der Regionsprozessor 2280 kann die Regionen unter Verwendung einer Vielfalt von 2D-Compositing-Techniken kombinieren. Obwohl sie als separate Komponenten veranschaulicht sind, können der Regionsprozessor 2280 und das entrauschte Bild 2290 integral mit der Anzeige 2290 sein. Die verschiedenen Knoten 2021-2022 können eine Direktsendetechnik verwenden, um die entrauschten Regionen 2121-2122 zu übertragen, und möglicherweise verschiedene verlustbehaftete oder verlustfreie Komprimierung der Regionsdaten verwenden.
Die AI-Entrauschung ist immer noch ein aufwendiger Vorgang und bewegt sich während des Spielens in die Wolke. Von daher kann eine Verteilungsverarbeitung des Entrauschens über mehrere Knoten 2021-2022 erforderlich werden, um Echtzeit-Frame-Raten für traditionelles Spielen oder virtuelle Realität (VR) zu erreichen, was höhere Frame-Raten erfordert. Filmstudios rendern häufig auch große Renderfarms, die zur schnelleren Entrauschung genutzt werden können.
Ein beispielhaftes Verfahren zum Durchführen eines verteilten Renderns und Entrauschens ist in 23 veranschaulicht. Das Verfahren kann im Kontext der oben beschriebenen Systemarchitekturen implementiert werden, ist aber nicht auf irgendeine spezielle Systemarchitektur beschränkt.
Bei 2301 wird Grafikarbeit an mehrere Knoten gesendet, die Strahlverfolgungsoperationen durchführen, um eine Region eines Frames zu rendern. Jeder Knoten kann bereits Daten aufweisen, die erforderlich sind, um die Operationen im Speicher durchzuführen. Beispielsweise können zwei oder mehr der Knoten einen gemeinsamen Speicher teilen oder die lokalen Speicher der Knoten können bereits Daten von früheren Strahlverfolgungsoperationen gespeichert haben. Alternativ oder zusätzlich können gewisse Daten an jeden Knoten übertragen werden.
Bei 2302 wird die „Geisterregion“ bestimmt, die für ein spezifiziertes Entrauschungsniveau (d. h. bei einem akzeptablen Leistungsniveau) benötigt wird. Die Geisterregion umfasst beliebige Daten, die zum Durchführen des spezifizierten Entrauschungspegels erforderlich sind, einschließlich Daten, die einem oder mehreren anderen Knoten gehören.
Bei 2303 werden Daten, die sich auf die Geisterregionen (oder Teile davon) beziehen, zwischen Knoten ausgetauscht. Bei 2304 führt jeder Knoten eine Entrauschung an seiner jeweiligen Region durch (z. B. unter Verwendung der ausgetauschten Daten) und bei 2305 werden die Ergebnisse kombiniert, um den endgültigen entrauschten Bildrahmen zu erzeugen.
Ein Managerknoten oder Primärknoten, wie in 22 gezeigt, kann die Arbeit an die Knoten absenden und dann die durch die Knoten durchgeführte Arbeit kombinieren, um das endgültige Bildframe zu erzeugen. Eine Peer-basierte Architektur kann verwendet werden, wobei die Knoten Peers sind, die Daten austauschen, um das endgültige Bildframe zu rendern und zu entrauschen.
Die hier beschriebenen Knoten (z. B. Knoten 2021-2023) können Grafikverarbeitungsrechensysteme sein, die über ein Hochgeschwindigkeitsnetzwerk miteinander verbunden sind. Alternativ dazu können die Knoten einzelne Verarbeitungselemente sein, die mit einer Hochgeschwindigkeits-Speicherstruktur gekoppelt sind. Alle Knoten können einen gemeinsamen virtuellen Speicherraum und/oder einen gemeinsamen physischen Speicher gemeinsam nutzen. Alternativ dazu können die Knoten eine Kombination von CPUs und GPUs sein. Zum Beispiel kann der oben beschriebene Managerknoten 2201 eine CPU und/oder Software, die auf der CPU ausgeführt wird, sein, und die Knoten 2021-2022 können GPUs und/oder Software, die auf den GPUs ausgeführt wird, sein. Es können verschiedene Arten von Knoten verwendet werden, die den zugrundeliegenden Prinzipien der Erfindung entsprechen.
BEISPIELHAFTE NEURONALE NETZWERKIMPLEMENTIERUNGEN
Es gibt viele Typen neuronaler Netzwerke; ein einfacher Typ neuronaler Netzwerke ist ein Feed-Forward-Netzwerke. Ein Vorwärtskopplungsnetzwerk kann als ein azyklischer Graph implementiert sein, in dem die Knoten in Schichten angeordnet sind. Typischerweise weist eine Vorwärtskopplungsnetzwerktopologie eine Eingabeschicht und eine Ausgabeschicht auf, die durch mindestens eine verborgene Schicht getrennt sind. Die verborgene Schicht transformiert eine durch die Eingabeschicht empfangene Eingabe in eine Repräsentation, die zum Erzeugen einer Ausgabe in der Ausgabeschicht nützlich ist. Die Netzwerkknoten sind vollständig über Kanten mit den Knoten in angrenzenden Schichten verbunden, es gibt aber keine Kanten zwischen Knoten innerhalb jeder Schicht. Daten, die an den Knoten einer Eingabeschicht eines Vorwärtskopplungsnetzwerks empfangen werden, werden zu den Knoten der Ausgabeschicht über eine Aktivierungsfunktion propagiert (d. h. „vorwärts gekoppelt“), die die Zustände der Knoten jeder nachfolgenden Schicht in dem Netzwerk basierend auf Koeffizienten („Gewichtungen“) berechnet, die jeweils mit jeder der Kanten assoziiert sind, die die Schichten verbinden. In Abhängigkeit von dem spezifischen Modell, das durch den Algorithmus repräsentiert wird, der ausgeführt wird, kann die Ausgabe von dem neuronalen Netzwerkalgorithmus verschiedene Formen annehmen.
Bevor ein Maschinenlernalgorithmus verwendet werden kann, um ein bestimmtes Problem zu modellieren, wird der Algorithmus unter Verwendung eines Trainingsdatensatzes trainiert. Das Trainieren eines neuronalen Netzwerks umfasst das Auswählen einer Netzwerktopologie, das Verwenden eines Satzes von Trainingsdaten, die ein Problem repräsentieren, das durch das Netzwerk modelliert wird, und das Anpassen der Gewichtungen, bis das Netzwerkmodell mit einem minimalen Fehler für alle Instanzen des Trainingsdatensatzes arbeitet. Während eines überwachten Lerntrainierungsprozesses für ein neuronales Netzwerk wird zum Beispiel die Ausgabe, die durch das Netzwerk als Reaktion auf die Eingabe erzeugt wird, die eine Instanz in einem Trainingsdatensatz repräsentiert, mit der „korrekten“ markierten Ausgabe für diese Instanz verglichen, wird ein Fehlersignal, das die Differenz zwischen der Ausgabe und der markierten Ausgabe darstellt, berechnet und werden die Gewichtungen, die mit den Verbindungen assoziiert sind, angepasst, um diesen Fehler zu minimieren, wenn das Fehlersignal rückwärts durch die Schichten des Netzwerks propagiert wird. Das Netzwerk wird als „trainiert“ angesehen, wenn die Fehler für jede der Ausgaben, die aus den Instanzen des Trainingsdatensatzes erzeugt werden, minimiert werden.
Die Genauigkeit eines Maschinenlernalgorithmus kann durch die Qualität des zum Trainieren des Algorithmus verwendeten Datensatzes erheblich beeinflusst werden. Der Trainingsprozess kann rechenintensiv sein und kann einen erheblichen Zeitaufwand auf einem herkömmlichen Universalprozessor erfordern. Dementsprechend wird eine Parallelverarbeitungshardware verwendet, um viele Arten von Maschinenlernalgorithmen zu trainieren. Dies ist besonders nützlich zum Optimieren des Trainings neuronaler Netzwerke, da sich die Berechnungen, die beim Anpassen der Koeffizienten in neuronalen Netzwerken durchgeführt werden, natürlich für parallele Implementierungen eignen. Insbesondere wurden viele Maschinenlernalgorithmen und Softwareanwendungen angepasst, um die Parallelverarbeitungshardware innerhalb von Universalgrafikverarbeitungsvorrichtungen zu nutzen.
24 ist ein verallgemeinertes Diagramm eines Maschinenlernsoftwarestapels 2400. Eine Maschinenlernanwendung 2402 kann dazu konfiguriert sein, ein neuronales Netzwerk unter Verwendung eines Trainingsdatensatzes zu trainieren oder ein trainiertes tiefes neuronales Netzwerk zu verwenden, um Maschinenintelligenz zu implementieren. Die Maschinenlernanwendung 2402 kann Trainings- und Inferenzfunktionalität für ein neuronales Netzwerk und/oder spezialisierte Software aufweisen, die verwendet werden kann, um ein neuronales Netzwerk vor dem Einsatz zu trainieren. Die Maschinenlernanwendung 2402 kann eine beliebige Art von Maschinenintelligenz implementieren, einschließlich unter anderem Bilderkennung, Kartierung und Lokalisierung, autonome Navigation, Sprachsynthese, medizinische Bildgebung oder Sprachübersetzung.
Die Hardwarebeschleunigung für die Maschinenlernanwendung 2402 kann über ein Maschinenlern-Framework 2404 aktiviert werden. Das Maschinenlern-Framework 2404 kann auf hier beschriebener Hardware implementiert werden, wie etwa dem Verarbeitungssystem 100, das die hier beschriebenen Prozessoren und Komponenten aufweist. Die für 24 beschriebenen Elemente mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt. Das Maschinenlern-Framework 2404 kann eine Bibliothek von Maschinenlernprimitiven bereitstellen. Maschinenlernprimitive sind Basisoperationen, die üblicherweise von Maschinenlernalgorithmen durchgeführt werden. Ohne das Maschinenlern-Framework 2404 wären Entwickler von Maschinenlernalgorithmen erforderlich, um die mit dem Maschinenlernalgorithmus assoziierte Hauptrechenlogik zu erzeugen und zu optimieren, dann die Rechenlogik erneut zu optimieren, wenn neue Parallelprozessoren entwickelt werden. Stattdessen kann die Maschinenlernanwendung dazu konfiguriert sein, die notwendigen Berechnungen unter Verwendung der Primitive durchzuführen, die durch das Maschinenlern-Framework 2404 bereitgestellt werden. Beispielhafte Primitive umfassen Tensorfaltungen, Aktivierungsfunktionen und Pooling, die Rechenoperationen sind, die durchgeführt werden, während ein neuronales Faltungsnetzwerk (CNN) trainiert wird. Das Maschinenlern-Framework 2404 kann auch Primitive bereitstellen, um grundlegende lineare Algebra-Unterprogramme zu implementieren, die durch viele Maschinenlernalgorithmen, wie etwa Matrix- und Vektoroperationen, durchgeführt werden.
Das Maschinenlern-Framework 2404 kann Eingabedaten verarbeiten, die von der Maschinenlernanwendung 2402 empfangen werden, und die angemessene Eingabe in ein Rechen-Framework 2406 erzeugen. Das Rechen-Framework 2406 kann die zugrundeliegenden Anweisungen abstrahieren, die dem GPGPU-Treiber 2408 bereitgestellt werden, um dem Maschinenlern-Framework 2404 zu ermöglichen, Hardwarebeschleunigung über die GPGPU-Hardware 2410 auszunutzen, ohne dass das Maschinenlern-Framework 2404 enge Kenntnis über die Architektur der GPGPU-Hardware 2410 haben muss. Zusätzlich kann das Rechen-Framework 2406 eine Hardwarebeschleunigung für das Maschinenlern-Framework 2404 über viele verschiedene Arten und Generationen der GPGPU-Hardware 2410 ermöglichen.
GPGPU-Maschinenlernbeschleunigung
25 veranschaulicht ein Multi-GPU-Rechensystem 2500, das eine Variante des Verarbeitungssystems 100 sein kann. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit dem Verarbeitungssystem 100 hier auch eine entsprechende Kombination mit dem Multi-GPU-Rechensystem 2500, ist aber nicht darauf beschränkt. Die Elemente von 25 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur beschreiben hier die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die hier an anderer Stelle beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt. Das Multi-GPU-Rechensystem 2500 kann einen Prozessor 2502 aufweisen, der über einen Host-Schnittstellenschalter 2504 mit mehreren GPGPUs 2506A-D gekoppelt ist. Der Host-Schnittstellenschalter 2504 kann zum Beispiel eine PCI-express-Schaltervorrichtung sein, die den Prozessor 2502 mit einem PCI-express-Bus koppelt, über den der Prozessor 2502 mit dem Satz von GPGPUs 2506A-D kommunizieren kann. Jede der mehreren GPGPUs 2506A-D kann eine Instanz der oben beschriebenen GPGPU sein.
Die GPGPUs 2506A-D können über einen Satz von Hochgeschwindigkeits-Punkt-zu-Punkt-GPU-zu-GPU-Verbindungen 2516 miteinander verbunden sein. Die Hochgeschwindigkeits-GPU-zu-GPU-Verbindungen können sich mit jeder der GPGPUs 2506A-D über eine dedizierte GPU-Verbindung verbinden. Die P2P-GPU-Verbindungen 2516 ermöglichen eine direkte Kommunikation zwischen jeder der GPGPUs 2506A-D, ohne dass eine Kommunikation über den Host-Schnittstellenbus erforderlich ist, mit dem der Prozessor 2502 verbunden ist. Mit GPU-zu-GPU-Verkehr, der zu den P2P-GPU-Verbindungen geleitet wird, bleibt der Host-Schnittstellenbus für den Systemspeicherzugriff verfügbar oder kommuniziert mit anderen Instanzen des Multi-GPU-Rechensystems 2500, beispielsweise über eine oder mehrere Netzwerkvorrichtungen. Anstatt die GPGPUs 2506A-D über den Host-Schnittstellenschalter 2504 mit dem Prozessor 2502 zu verbinden, kann der Prozessor 2502 eine direkte Unterstützung für die P2P-GPU-Verbindungen 2516 aufweisen und somit direkt mit den GPGPUs 2506A-D verbunden werden.
Implementierungen eines maschinellen Lernens neuronaler Netze
Die hierin beschriebene Rechenarchitektur kann dazu konfiguriert sein, die Arten von Parallelverarbeitung durchzuführen, die insbesondere zum Trainieren und Einsetzen von neuronalen Netzwerken für maschinelles Lernen geeignet sind. Ein neuronales Netzwerk kann als ein Netzwerk von Funktionen, die in einer Graphenbeziehung stehen, verallgemeinert werden. Wie im Stand der Technik wohlbekannt ist, gibt es eine Vielzahl von Typen von neuronalen Netzwerkimplementierungen, die beim maschinellen Lernen verwendet werden. Ein beispielhafter Typ eines neuronalen Netzwerks ist das Vorwärtskopplungsnetzwerk, wie zuvor beschrieben.
Ein zweiter beispielhafter Typ eines neuronalen Netzwerks ist das neuronale Faltungsnetzwerk (CNN: Convolutional Neural Network). Ein CNN ist ein spezialisiertes vorwärtsgekoppeltes neuronales Netzwerk zum Verarbeiten von Daten mit einer bekannten gitterartigen Topologie, wie etwa Bilddaten. Dementsprechend werden CNNs üblicherweise für Rechensicht- und Bilderkennungsanwendungen verwendet, können aber auch für andere Arten von Mustererkennung, wie etwa Sprache und Sprachverarbeitung, verwendet werden. Die Knoten in der CNN-Eingabeschicht werden in einen Satz von „Filtern“ organisiert (Merkmalsdetektoren, die von den in der Netzhaut gefundenen rezeptiven Feldern inspiriert werden), und die Ausgabe jedes Satzes von Filtern wird zu Knoten in aufeinanderfolgenden Schichten des Netzwerks propagiert. Die Berechnungen für ein CNN umfassen das Anwenden der mathematischen Faltungsoperation auf jedes Filter, um die Ausgabe dieses Filters zu erzeugen. Faltung ist eine spezialisierte Art von mathematischer Operation, die von zwei Funktionen durchgeführt wird, um eine dritte Funktion zu erzeugen, die eine modifizierte Version einer der zwei ursprünglichen Funktionen ist. In der Faltungsnetzwerkterminologie kann die erste Funktion zur Faltung als Eingabe bezeichnet werden, während die zweite Funktion als Faltungskern bezeichnet werden kann. Die Ausgabe kann als Merkmalskarte bezeichnet werden. Zum Beispiel kann die Eingabe in eine Faltungsschicht ein mehrdimensionales Array von Daten sein, das die verschiedenen Farbkomponenten eines Eingabebilds definiert. Der Faltungskern kann ein mehrdimensionales Array von Parametern sein, wobei die Parameter durch den Trainingsprozess für das neuronale Netzwerk angepasst werden.
Rekurrente neuronale Netzwerke (RNNs) sind eine Familie von vorwärtsgekoppelten neuronalen Netzwerken, die Rückkopplungsverbindungen zwischen Schichten aufweisen. RNNs ermöglichen das Modellieren sequenzieller Daten durch das gemeinsame Nutzen von Parameterdaten über verschiedene Teile des neuronalen Netzwerks. Die Architektur für ein RNN weist Zyklen auf. Die Zyklen stellen den Einfluss eines gegenwärtigen Werts einer Variablen auf ihren eigenen Wert zu einem zukünftigen Zeitpunkt dar, da zumindest ein Teil der Ausgangsdaten von dem RNN als eine Rückkopplung zum Verarbeiten einer nachfolgenden Eingabe in einer Sequenz verwendet wird. Dieses Merkmal macht RNNs wegen der variablen Natur, in der Sprachdaten zusammengesetzt werden können, besonders nützlich für Sprachverarbeitung.
Die unten beschriebenen Figuren präsentieren beispielhafte Vorwärtskopplungs-, CNN- und RNN-Netzwerke und beschreiben einen allgemeinen Prozess zum Trainieren bzw. Einsetzen jedes dieser Typen von Netzwerken. Es versteht sich, dass diese Beschreibungen beispielhaft und nicht einschränkend sind und die veranschaulichten Konzepte allgemein auf tiefe neuronale Netzwerke und Maschinenlerntechniken allgemein angewendet werden können.
Die oben beschriebenen beispielhaften neuronalen Netzwerke können verwendet werden, um Deep Learning durchzuführen. Deep Learning ist maschinelles Lernen unter Verwendung von tiefen neuronalen Netzwerken. Die tiefen neuronalen Netzwerke, die beim Deep Learning verwendet werden, sind künstliche neuronale Netzwerke, die aus mehreren verborgenen Schichten bestehen, im Gegensatz zu flachen neuronalen Netzwerken, die nur eine einzige verborgene Schicht aufweisen. Tiefere neuronale Netzwerke sind im Allgemeinen rechenintensiver zu trainieren. Die zusätzlichen verborgenen Schichten des Netzwerks ermöglichen jedoch eine mehrstufige Mustererkennung, die zu einem reduzierten Ausgabefehler relativ zu flachen Maschinenlerntechniken führt.
Tiefe neuronale Netzwerke, die beim Deep Learning verwendet werden, umfassen typischerweise ein Frontend-Netzwerk zum Durchführen einer Merkmalserkennung, das mit einem Backend-Netzwerk gekoppelt ist, das ein mathematisches Modell repräsentiert, das Operationen (z. B. Objektklassifikation, Spracherkennung usw.) basierend auf der Merkmalsdarstellung, die dem Modell bereitgestellt wird, durchführen kann. Deep Learning ermöglicht es, maschinelles Lernen durchzuführen, ohne dass eine handwerkliche Merkmalstechnologie für das Modell durchgeführt werden muss. Stattdessen können tiefe neuronale Netzwerke Merkmale basierend auf statistischer Struktur oder Korrelation innerhalb der Eingabedaten lernen. Die gelernten Merkmale können einem mathematischen Modell bereitgestellt werden, das detektierte Merkmale auf eine Ausgabe abbilden kann. Das mathematische Modell, das durch das Netzwerk verwendet wird, ist allgemein für die spezielle durchzuführende Aufgabe spezialisiert und unterschiedliche Modelle werden verwendet, um unterschiedliche Aufgaben durchzuführen.
Sobald das neuronale Netzwerk strukturiert ist, kann ein Lernmodell auf das Netzwerk angewandt werden, um das Netzwerk zu trainieren, um spezifische Aufgaben durchzuführen. Das Lernmodell beschreibt, wie die Gewichtungen innerhalb des Modells anzupassen sind, um den Ausgangsfehler des Netzwerks zu reduzieren. Eine Rückpropagation von Fehlern ist ein gängiges Verfahren, das zum Trainieren neuronaler Netzwerke verwendet wird. Ein Eingangsvektor wird dem Netzwerk zur Verarbeitung präsentiert. Die Ausgabe des Netzwerks wird mit der gewünschten Ausgabe unter Verwendung einer Verlustfunktion verglichen und für jedes der Neuronen in der Ausgabeschicht wird ein Fehlerwert berechnet. Die Fehlerwerte werden dann rückwärts propagiert, bis jedem Neuron ein Fehlerwert zugeordnet ist, der seinen Beitrag zur ursprünglichen Ausgabe grob repräsentiert. Das Netzwerk kann dann aus diesen Fehlern unter Verwendung eines Algorithmus, wie etwa des stochastischen Gradientenabstiegsalgorithmus, lernen, um die Gewichtungen 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 einer Bildverarbeitung verwendet wird, eine Eingabe 2602 empfangen, die die roten, grünen und blauen (RGB) Komponenten eines Eingabebilds beschreibt. Die Eingabe 2602 kann durch mehrere Faltungsschichten (z. B. 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 weisen vollständige Verbindungen zu allen Aktivierungen in der vorherigen Schicht auf, wie zuvor für ein Vorwärtskopplungsnetzwerk beschrieben wurde. Die Ausgabe der vollständig verbundenen Schichten 2608 kann verwendet werden, um ein Ausgabeergebnis aus dem Netzwerk zu erzeugen. Die Aktivierungen innerhalb der vollständig verbundenen Schichten 2608 können unter Verwendung einer Matrixmultiplikation anstelle einer Faltung berechnet werden. Nicht alle CNN-Implementierungen nutzen vollständig verbundene Schichten. Bei manchen Implementierungen kann die Faltungsschicht 2606 zum Beispiel eine Ausgabe für das CNN erzeugen.
Die Faltungsschichten sind kaum verbunden, was sich von einer herkömmlichen Neuronalnetzwerkkonfiguration unterscheidet, die in den vollständig verbundenen Schichten 2608 zu finden ist. Herkömmliche neuronale Netzwerkschichten sind vollständig verbunden, so dass jede Ausgabeeinheit mit jeder Eingabeeinheit interagiert. Die Faltungsschichten sind jedoch kaum verbunden, weil die Ausgabe der Faltung eines Felds (anstelle des jeweiligen Zustandswerts jedes der Knoten in dem Feld) in die Knoten der nachfolgenden Schicht eingegeben wird, wie veranschaulicht. Die Kerne, die den Faltungsschichten zugeordnet sind, führen Faltungsoperationen durch, deren Ausgabe an die nächste Schicht gesendet wird. Die innerhalb der Faltungsschichten durchgeführte Dimensionalitätsverringerung ist ein Aspekt, der es dem CNN ermöglicht, große Bilder zu verarbeiten.
27 veranschaulicht beispielhafte Berechnungsstufen innerhalb einer Faltungsschicht eines CNN. Eine Eingabe in eine Faltungsschicht 2712 eines CNN kann in drei Stufen einer Faltungsschicht 2714 verarbeitet werden. Die drei Stufen können eine Faltungsstufe 2716, eine Detektorstufe 2718 und eine Pooling-Stufe 2720 umfassen. Die Faltungsschicht 2714 kann dann Daten an eine nachfolgende Faltungsschicht ausgeben. Die letzte Faltungsschicht des Netzwerks kann Ausgabemerkmalskartendaten erzeugen oder eine Eingabe in eine vollständig verbundene Schicht bereitstellen, um zum Beispiel einen Klassifizierungswert für die Eingabe in das CNN zu erzeugen.
In der Faltungsstufe 2716 werden mehrere Faltungen parallel durchgeführt, um einen Satz linearer Aktivierungen zu erzeugen. Die Faltungsstufe 2716 kann eine affine Transformation aufweisen, die eine beliebige Transformation ist, die als eine lineare Transformation plus eine Übersetzung spezifiziert werden kann. Affine Transformationen umfassen Rotationen, Übersetzungen, Skalierung und Kombinationen dieser Transformationen. Die Faltungsstufe berechnet die Ausgabe von Funktionen (z. B. Neuronen), die mit bestimmten Regionen im Eingang verbunden sind, die als die dem Neuron zugeordnete lokale Region bestimmt werden können. Die Neuronen berechnen ein Skalarprodukt zwischen den Gewichtungen der Neuronen und der Region in der lokalen Eingabe, mit der die Neuronen verbunden sind. Die Ausgabe von der Faltungsstufe 2716 definiert einen Satz linearer Aktivierungen, die durch aufeinanderfolgende Stufen der Faltungsschicht 2714 verarbeitet werden.
Die linearen Aktivierungen können von einer Detektorstufe 2718 verarbeitet werden. In der Detektorstufe 2718 wird jede lineare Aktivierung durch eine nichtlineare Aktivierungsfunktion verarbeitet. Die nichtlineare Aktivierungsfunktion erhöht die nichtlinearen Eigenschaften des Gesamtenetzwerks, ohne die rezeptiven Felder der Faltungsschicht zu beeinflussen. Es können verschiedene Arten von nichtlinearen Aktivierungsfunktionen verwendet werden. Ein besonderer Typ ist die entzerrte Lineareinheit (ReLU), die eine Aktivierungsfunktion verwendet, die definiert ist als f(x)=max(0,x), so dass die Aktivierung zu Null schwellenwertbehaftet ist.
Die Pooling-Stufe 2720 verwendet eine Pooling-Funktion, die die Ausgabe der Faltungsschicht 2706 durch eine Zusammenfassungsstatistik der nahegelegenen Ausgaben ersetzt. Die Pooling-Funktion kann verwendet werden, um eine Übersetzungsinvarianz in das neuronale Netzwerk einzuführen, so dass kleine Übersetzungen zu der Eingabe die gebündelten Ausgaben nicht ändern. Invarianz gegenüber lokaler Übersetzung kann in Szenarien nützlich sein, bei denen das Vorhandensein eines Merkmals in den Eingabedaten wichtiger als der genaue Ort des Merkmals ist. Verschiedene Arten von Pooling-Funktionen können während der Pooling-Stufe 2720 verwendet werden, einschließlich Max-Pooling, Durchschnitts-Pooling und 12-Norm-Pooling. Außerdem weisen manche CNN-Implementierungen keine Pooling-Stufe auf. Stattdessen ersetzen solche Implementierungen eine zusätzliche Faltungsstufe mit einem erhöhten Schritt relativ zu vorherigen Faltungsstufen.
Die Ausgabe von der Faltungsschicht 2714 kann dann durch die 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 ausgegeben werden, während die zweite Faltungsschicht an eine erste Schicht der vollständig verbundenen Schichten 2808 ausgegeben werden kann.
28 veranschaulicht ein beispielhaftes rekurrentes neuronales Netzwerk 2800. In einem rekurrenten neuronalen Netzwerk (RNN) beeinflusst der vorherige Zustand des Netzwerks die Ausgabe des aktuellen Zustands des Netzwerks. RNNs können auf vielfältige Weise unter Verwendung vielfältiger Funktionen aufgebaut werden. Die Verwendung von RNNs dreht sich im Allgemeinen darum, mathematische Modelle zu verwenden, um die Zukunft basierend auf einer vorherigen Sequenz von Eingaben vorherzusagen. Zum Beispiel kann ein RNN verwendet werden, um eine statistische Sprachmodellierung durchzuführen, um ein bevorstehendes Wort in Anbetracht einer vorherigen Sequenz von Wörtern vorherzusagen. Das veranschaulichte RNN 2800 kann beschrieben werden, das eine Eingabeschicht 2802, die einen Eingabevektor empfängt, verborgene Schichten 2804 zum Implementieren einer wiederkehrenden Funktion, einen Rückkopplungsmechanismus 2805 zum Aktivieren eines „Speichers“ früherer Zustände und eine Ausgabeschicht 2806 zum Ausgeben eines Ergebnisses aufweist. Das RNN 2800 arbeitet basierend auf Zeitschritten. Der Zustand des RNN zu einem gegebenen Zeitschritt wird basierend auf dem vorherigen Zeitschritt über den Rückkopplungsmechanismus 2805 beeinflusst. Für einen gegebenen Zeitschritt wird der Zustand der verborgenen Schichten 2804 durch den vorherigen Zustand und die Eingabe bei dem aktuellen Zeitschritt definiert. Eine anfängliche Eingabe (x1) zu einem ersten Zeitschritt kann durch die verborgene Schicht 2804 verarbeitet werden. Eine zweite Eingabe (x2) kann durch die verborgene Schicht 2804 unter Verwendung von Zustandsinformationen verarbeitet werden, die während der Verarbeitung der anfänglichen Eingabe (x1) bestimmt werden. Ein gegebener Zustand kann als s_t=f(Ux_t+ Ws_(t-1)) berechnet werden, wobei U und W Parametermatrizen sind. Die Funktion f ist allgemein eine Nichtlinearität, wie die Tangens-Hyperbelfunktion (Tanh) oder eine Variante der Gleichrichterfunktion f(x)=max(0,x). Die spezifische mathematische Funktion, die in den verborgenen Schichten 2804 verwendet wird, kann jedoch in Abhängigkeit 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-RNNs sind in der Lage, Langzeitabhängigkeiten zu lernen, die zur Verarbeitung längerer Sprachsequenzen notwendig sein können. Eine Variante auf dem CNN ist ein Faltungsnetzwerk mit tiefer Wahrscheinlichkeit, das eine Struktur ähnlich einem CNN aufweist und auf eine Weise ähnlich einem Netzwerk mit tiefer Wahrscheinlichkeit trainiert wird. Ein Deep-Belief-Netzwerk (DBN) ist ein generatives neuronales Netzwerk, das aus mehreren Schichten stochastischer (zufälliger) Variablen besteht. DBNs können Schicht für Schicht unter Verwendung von gierigem unüberwachtem Lernen trainiert werden. Die erlernten Gewichtungen des DBN können dann verwendet werden, um neuronale Vortrainingsnetzwerke bereitzustellen, indem ein optimaler anfänglicher Satz von Gewichtungen für das neuronale Netzwerk bestimmt wird.
29 veranschaulicht das Training und den Einsatz eines tiefen neuronalen Netzwerks. Nachdem ein gegebenes Netzwerk für eine Aufgabe strukturiert wurde, wird das neuronale Netzwerk unter Verwendung eines Trainingsdatensatzes 2902 trainiert. Verschiedene Trainings-Frameworks 2904 wurden entwickelt, um eine Hardwarebeschleunigung des Trainingsprozesses zu ermöglichen. Beispielsweise kann das oben beschriebene Maschinenlern-Framework als Trainings-Framework konfiguriert sein. Das Trainings-Framework 2904 kann sich in ein untrainiertes neuronales Netzwerk 2906 einhängen und ermöglichen, dass das untrainierte neuronale Netzwerk unter Verwendung der hier beschriebenen Parallelverarbeitungsressourcen trainiert wird, um ein trainiertes neuronales Netzwerk 2908 zu erzeugen.
Zum Starten des Trainingsprozesses können die anfänglichen Gewichtungen zufällig oder durch Vortrainieren unter Verwendung eines Deep-Belief-Netzwerks ausgewählt werden. Der Trainingszyklus kann dann entweder überwacht oder unüberwacht durchgeführt werden.
Überwachtes Lernen ist ein Lernverfahren, bei dem Training als eine vermittelte Operation durchgeführt wird, wie etwa wenn der Trainingsdatensatz 2902 eine Eingabe aufweist, die mit der gewünschten Ausgabe für die Eingabe gepaart ist, oder wenn der Trainingsdatensatz eine Eingabe mit einer bekannten Ausgabe aufweist und die Ausgabe des neuronalen Netzwerks manuell eingestuft wird. Das Netzwerk verarbeitet die Eingaben und vergleicht die resultierenden Ausgaben mit einer Menge erwarteter oder gewünschter Ausgaben. Fehler werden dann durch das System zurück propagiert. Das Trainings-Framework 2904 kann angepasst werden, um die Gewichtungen anzupassen, die das untrainierte neuronale Netzwerk 2906 steuern. Das Trainings-Framework 2904 kann Werkzeuge bereitstellen, um zu überwachen, wie gut das untrainierte neuronale Netzwerk 2906 zu einem Modell konvergiert, das zum Erzeugen korrekter Antworten basierend auf bekannten Eingabedaten geeignet ist. Der Trainingsprozess findet wiederholt statt, wenn die Gewichtungen des Netzwerks angepasst werden, um die durch das neuronale Netzwerk erzeugte Ausgabe zu verfeinern. Der Trainingsprozess kann fortgesetzt werden, bis das neuronale Netzwerk eine statistisch gewünschte Genauigkeit erreicht, die mit einem trainierten neuronalen Netzwerk 2908 assoziiert ist. Das trainierte neuronale Netzwerk 2908 kann dann eingesetzt werden, um eine beliebige Anzahl von Maschinenlernoperationen zu implementieren.
Unüberwachtes Lernen ist ein Lernverfahren, bei dem das Netzwerk versucht, sich mit unmarkierten Daten zu trainieren. Somit wird der Trainingsdatensatz 2902 für unüberwachtes Lernen Eingabedaten ohne zugehörige Ausgabedaten aufweisen. Das untrainierte neuronale Netzwerk 2906 kann Gruppierungen innerhalb der unmarkierten Eingabe lernen und kann bestimmen, wie individuelle Eingaben mit dem Gesamtdatensatz in Beziehung stehen. Unüberwachtes Training kann verwendet werden, um eine selbstorganisierende Karte zu erzeugen, die ein Typ eines trainierten neuronalen Netzwerks 2907 ist, das in der Lage ist, Operationen durchzuführen, die beim Reduzieren der Dimensionalität von Daten nützlich sind. Mit unüberwachtem Training kann auch eine Anomaliedetektion durchgeführt werden, die die Identifikation von Datenpunkten in einem Eingangsdatensatz ermöglicht, die von den Normalmustern der Daten abweichen.
Variationen an überwachtem und unüberwachtem Training können ebenfalls eingesetzt werden. Halbüberwachtes Lernen ist eine Technik, bei der der Trainingsdatensatz 2902 eine Mischung aus markierten und unmarkierten Daten der gleichen Verteilung aufweist. Inkrementales Lernen ist eine Variante des überwachten Lernens, bei der Eingangsdaten kontinuierlich verwendet werden, um das Modell weiter zu trainieren. Inkrementelles Lernen ermöglicht es, dass sich das trainierte neuronale Netzwerk 2908 an die neuen Daten 2912 anpasst, ohne zu vergessen, dass das Wissen während des anfänglichen Trainings in das Netzwerk eingetreten ist.
Unabhängig davon, ob überwacht oder nicht überwacht, kann der Trainingsprozess für besonders tiefe neuronale Netzwerke für einen einzigen Rechenknoten zu rechenintensiv sein. Anstatt einen einzigen Rechenknoten zu verwenden, 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 verwendet, wie etwa die oben beschriebenen Knoten, um überwachtes oder unüberwachtes Training eines neuronalen Netzwerks durchzuführen. Die verteilten Rechenknoten können jeweils einen oder mehrere Hostprozessoren und einen oder mehrere der Universalverarbeitungsknoten, wie etwa eine hochparallele Universalgrafikverarbeitungseinheit, aufweisen. Wie veranschaulicht, kann verteiltes Lernen Modellparallelität 3002, Datenparallelität 3004 oder eine Kombination von Modell- und Datenparallelität durchgeführt werden.
Bei der Modellparallelität 3002 können unterschiedliche Rechenknoten in einem verteilten System Trainingsberechnungen für unterschiedliche Teile eines einzigen Netzwerks durchführen. Zum Beispiel kann jede Schicht eines neuronalen Netzwerks durch einen anderen Verarbeitungsknoten des verteilten Systems trainiert werden. Zu den Vorteilen der Modellparallelität gehört die Skalierbarkeit auf besonders große Modelle. Das Aufteilen der Berechnungen, die verschiedenen Schichten des neuronalen Netzwerks zugeordnet sind, ermöglicht das Trainieren sehr großer neuronaler Netzwerke, bei denen die Gewichtungen aller Schichten nicht in den Speicher eines einzigen Rechenknotens passen würden. In manchen Fällen kann Modellparallelität besonders nützlich bei der Durchführung eines unüberwachten Trainings großer neuronaler Netzwerke sein.
Bei der Datenparallelität 3004 weisen die verschiedenen Knoten des verteilten Netzwerks eine vollständige Instanz des Modells auf und jeder Knoten empfängt einen anderen Teil der Daten. Die Ergebnisse der verschiedenen Knoten werden dann kombiniert. Obwohl unterschiedliche Ansätze zur Datenparallelität möglich sind, erfordern Datenparalleltrainingsansätze alle eine Technik zum Kombinieren von Ergebnissen und Synchronisieren der Modellparameter zwischen jedem Knoten. Beispielhafte Ansätze zum Kombinieren von Daten umfassen Parametermittelung und aktualisierungsbasierte Datenparallelität. Parametermittelung trainiert jeden Knoten auf einer Teilmenge der Trainingsdaten und stellt die globalen Parameter (z. B. Gewichtungen, Bias) auf den Mittelwert der Parameter von jedem Knoten ein. Die Parametermittelung verwendet einen zentralen Parameterserver, der die Parameterdaten pflegt. Aktualisierungsbasierte Datenparallelität ähnelt einer Parametermittelung, außer dass anstelle des Übertragens von Parametern von den Knoten zu dem Parameterserver die Aktualisierungen an dem Modell übertragen werden. Zusätzlich dazu kann aktualisierungsbasierte Datenparallelität auf eine dezentrale Weise durchgeführt werden, wobei die Aktualisierungen komprimiert und zwischen Knoten übertragen werden.
Kombinierte Modell- und Datenparallelität 3006 kann zum Beispiel in einem verteilten System implementiert werden, in dem jeder Rechenknoten mehrere GPUs aufweist. Jeder Knoten kann eine vollständige Instanz des Modells aufweisen, wobei separate GPUs innerhalb jedes Knotens verwendet werden, um unterschiedliche Teile des Modells zu trainieren.
Verteiltes Training hat einen erhöhten Overhead im Vergleich zum Training auf einer einzigen Maschine. Die hier beschriebenen Parallelprozessoren und GPGPUs können jedoch jeweils verschiedene Techniken implementieren, um den Overhead des verteilten Trainings zu reduzieren, einschließlich Techniken, um GPU-zu-GPU-Datentransfer mit hoher Bandbreite und beschleunigte Ferndatensynchronisation zu ermöglichen.
Beispielhafte Maschinenlernanwendungen
Maschinelles Lernen kann angewendet werden, um eine Vielzahl von technologischen Problemen zu lösen, einschließlich unter anderem Computersicht, autonomes Fahren und Navigation, Spracherkennung und Sprachverarbeitung. Computersicht ist traditionell eines der aktivsten Forschungsgebiete für Maschinenlernanwendungen. Anwendungen von Computersicht reichen von der Wiedergabe menschlicher Sehfähigkeiten, wie etwa Erkennen von Gesichtern, bis zum Erzeugen neuer Kategorien von Sehfähigkeiten. Computervisionsanwendungen können zum Beispiel dazu konfiguriert sein, Schallwellen aus den Vibrationen zu erkennen, die in Objekten induziert werden, die in einem Video sichtbar sind. Parallelprozessorbeschleunigtes Maschinenlernen ermöglicht es, dass Computervisionsanwendungen unter Verwendung eines wesentlich größeren Trainingsdatensatzes als bisher möglich trainiert werden, und ermöglicht es, Inferenzsysteme unter Verwendung von Parallelprozessoren mit niedriger Leistung einzusetzen.
Beschleunigtes Maschinenlernen mit Parallelprozessor weist autonome Fahranwendungen auf, einschließlich Spur- und Verkehrszeichenerkennung, Hindernisvermeidung, Navigation und Fahrsteuerung. Beschleunigte Maschinenlerntechniken können verwendet werden, um Fahrmodelle basierend auf Datensätzen zu trainieren, die die geeigneten Antworten auf spezifische Trainingseingaben definieren. Die hier beschriebenen Parallelprozessoren können ein schnelles Training der zunehmend komplexeren neuronalen Netzwerke ermöglichen, die für Autonomfahrlösungen verwendet werden, und ermöglichen den Einsatz von Niederleistungs-Inferenzprozessoren in einer mobilen Plattform, die zur Integration in autonome Fahrzeuge geeignet ist.
Parallelprozessorbeschleunigte tiefe neuronale Netzwerke haben Maschinenlernansätze zur automatischen Spracherkennung (ASR) ermöglicht. Die ASR umfasst das Erstellen einer Funktion, die bei einer eingegebenen akustischen Sequenz die wahrscheinlichste linguistische Sequenz berechnet. Beschleunigtes Maschinenlernen unter Verwendung tiefer neuronaler Netzwerke ermöglichte den Ersatz der bisher für ASR verwendeten Hidden Markov-Modelle (HMMs) und Gauß-Mischmodelle (GMMs).
Parallelprozessorbeschleunigtes Maschinenlernen kann auch zur Beschleunigung der natürlichen Sprachverarbeitung verwendet werden. Automatische Lernverfahren können statistische Inferenzalgorithmen verwenden, um Modelle zu erzeugen, die robust gegenüber fehlerhaften oder unvertrauten Eingaben sind. Beispielhafte natürliche Sprachprozessoranwendungen umfassen die automatische Maschinenübersetzung zwischen menschlichen Sprachen.
Die zum Maschinenlernen verwendeten parallelen Verarbeitungsplattformen können in Trainingsplattformen und Einsatzplattformen unterteilt werden. Trainingsplattformen sind im Allgemeinen stark parallel und weisen Optimierungen zum Beschleunigen von Multi-GPU-Einzelknoten-Training und Multi-Knoten-Multi-GPU-Training auf. Beispielhafte Parallelprozessoren, die zum Trainieren geeignet sind, weisen die hier beschriebene hochparallele Universalgrafikverarbeitungseinheit und/oder die Multi-GPU-Rechensysteme auf. Dagegen weisen eingesetzte Maschinenlernplattformen im Allgemeinen Parallelprozessoren mit niedrigerer Leistung auf, die zur Verwendung in Produkten, wie etwa Kameras, autonomen Robotern und autonomen Fahrzeugen, geeignet sind.
30B veranschaulicht ein beispielhaftes Inferenzsystem auf einem Chip (SOC) 3100, das zum Durchführen eines Inferenzierens unter Verwendung eines trainierten Modells geeignet ist. Die Elemente von 30B mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur beschreiben hier die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die hier an anderer Stelle beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt. Das SOC 3100 kann Verarbeitungskomponenten einschließlich eines Medienprozessors 3102, eines Visionsprozessors 3104, einer GPGPU 3106 und eines Mehrkernprozessors 3108 integrieren. Das SOC 3100 kann zusätzlich einen On-Chip-Speicher 3105 aufweisen, der einen gemeinsam genutzten On-Chip-Datenpool ermöglichen kann, auf den jede der Verarbeitungskomponenten zugreifen kann. Die Verarbeitungskomponenten können für einen Niedrigleistungsbetrieb optimiert werden, um den Einsatz auf eine Vielzahl von Maschinenlernplattformen, einschließlich autonomer Fahrzeuge und autonomer Roboter, zu ermöglichen. Zum Beispiel kann eine Implementierung des SOC 3100 als ein Teil des Hauptsteuersystems für ein autonomes Fahrzeug verwendet werden. Wenn das SOC 3100 zur Verwendung in autonomen Fahrzeugen konfiguriert ist, ist das SOC zur Erfüllung der relevanten funktionalen Sicherheitsstandards der Einsatzrechtmäßigkeit gestaltet und konfiguriert.
Während des Betriebs können der Medienprozessor 3102 und der Visionsprozessor 3104 zusammenwirken, um Computervisionsoperationen zu beschleunigen. Der Medienprozessor 3102 kann eine Decodierung mehrerer Videoströme mit hoher Auflösung (z. B. 4K, 8K) mit niedriger Latenz ermöglichen. Die decodierten Videoströme können in einen Puffer in dem On-Chip-Speicher 3105 geschrieben werden. Der Visionsprozessor 3104 kann dann das decodierte Video analysieren und vorläufige Verarbeitungsoperationen an den Frames des decodierten Videos als Vorbereitung der Verarbeitung der Frames unter Verwendung eines trainierten Bilderkennungsmodells durchführen. Zum Beispiel kann der Visionsprozessor 3104 Faltungsoperationen für ein CNN beschleunigen, das zum Durchführen einer Bilderkennung an den Videodaten mit hoher Auflösung verwendet wird, während Backend-Modellberechnungen durch die GPGPU 3106 durchgeführt werden.
Der Mehrkernprozessor 3108 kann Steuerlogik aufweisen, um das Sequenzieren und Synchronisieren von Datentransfers und gemeinsam genutzten Speicheroperationen zu unterstützen, die durch den Medienprozessor 3102 und den Visionsprozessor 3104 durchgeführt werden. Der Mehrkernprozessor 3108 kann auch als ein Anwendungsprozessor fungieren, um Softwareanwendungen auszuführen, die die Inferenzberechnungsfähigkeit der GPGPU 3106 nutzen können. Zum Beispiel kann mindestens ein Teil der Navigations- und Fahrlogik in Software implementiert sein, die auf dem Mehrkernprozessor 3108 ausgeführt wird. Eine solche Software kann direkt Rechenarbeitslasten an die GPGPU 3106 ausgeben oder die Rechenarbeitslasten können an den Mehrkernprozessor 3108 ausgegeben werden, der mindestens einen Teil dieser Operationen an die GPGPU 3106 abladen kann.
Die GPGPU 3106 kann Verarbeitungs-Cluster, wie etwa eine Niedrigleistungskonfiguration der Verarbeitungs-Cluster DPLAB06A-DPLAB06H, innerhalb der hochparallelen Universalgrafikverarbeitungseinheit DPLAB00 aufweisen. Die Verarbeitungs-Cluster innerhalb der GPGPU 3106 können Anweisungen unterstützen, die speziell optimiert sind, um Inferenzberechnungen an einem trainierten neuronalen Netzwerk durchzuführen. Zum Beispiel kann die GPGPU 3106 Anweisungen zum Durchführen von Berechnungen mit niedriger Genauigkeit unterstützen, wie etwa 8-Bit- und 4-Bit-Ganzzahlvektoroperationen.
STRAH LVERFOLGU NGSARCHITEKTUR
Bei einer Implementierung weist der Grafikprozessor eine Schaltungsanordnung und/oder einen Programmcode zum Durchführen von Echtzeit-Strahlverfolgung auf. Ein dedizierter Satz von Strahlverfolgungskernen kann in dem Grafikprozessor enthalten sein, um die verschiedenen hier beschriebenen Strahlverfolgungsoperationen durchzuführen, einschließlich Strahltraversierungs- und/oder Strahlschnittoperationen. Zusätzlich zu den Strahlverfolgungskernen können auch mehrere Sätze von Grafikverarbeitungskernen zum Durchführen programmierbarer Schattierungsoperationen und mehrere Sätze von Tensorkernen zum Durchführen von Matrixoperationen an Tensordaten enthalten sein.
31 veranschaulicht einen beispielhaften Teil einer solchen Grafikverarbeitungseinheit (GPU) 3105, die dedizierte Sätze von Grafikverarbeitungsressourcen aufweist, die in Mehrkerngruppen 3100A-N angeordnet sind. Die Grafikverarbeitungseinheit (GPU) 3105 kann eine Variante des Grafikprozessors 300, der GPGPU 1340 und/oder eines beliebigen anderen hier beschriebenen Grafikprozessors sein. Daher offenbart die Offenbarung beliebiger Merkmale für Grafikprozessoren auch eine entsprechende Kombination mit der GPU 3105, ist aber nicht darauf beschränkt. Darüber hinaus beschreiben die Elemente aus 31 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hier die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die hier an anderer Stelle beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt. Während die Einzelheiten lediglich einer einzigen Mehrkerngruppe 3100A bereitgestellt sind, versteht es sich, dass die anderen Mehrkerngruppen 3100B-N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können.
Wie veranschaulicht, kann eine Mehrkerngruppe 3100A einen Satz von Grafikkernen 3130, einen Satz von Tensorkernen 3140 und einen Satz von Strahlverfolgungskernen 3150 aufweisen. Ein Scheduler/Dispatcher 3110 plant und sendet die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 3130, 3140, 3150 aus. Ein Satz von Registerdateien 3120 speichert Operandenwerte, die von den Kernen 3130, 3140, 3150 verwendet werden, wenn die Grafik-Threads ausgeführt werden. Diese können zum Beispiel Ganzzahlregister zum Speichern von Ganzzahlwerten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern von gepackten Datenelementen (Ganzzahl- und/oder Gleitkommadatenelementen) und Kachelregister zum Speichern von Tensor-/Matrixwerten umfassen. Die Kachelregister können als kombinierte Sätze von Vektorregistern implementiert werden.
Ein oder mehrere Level-1(L1)-Caches und Textureinheiten 3160 speichern Grafikdaten, wie etwa Texturdaten, Vertexdaten, Pixeldaten, Strahldaten, Begrenzungsvolumendaten usw., lokal innerhalb jeder Mehrkerngruppe 3100A. Ein Level-2(L2)-Cache 3180, der durch alle oder eine Teilmenge der Mehrkerngruppen 3100A-N gemeinsam genutzt wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafik-Threads. Wie veranschaulicht, kann der L2-Cache 3180 über mehrere Mehrkerngruppen 3100A-N gemeinsam genutzt werden. Eine oder mehrere Speichersteuerungen 3170 koppeln die GPU 3105 mit einem Speicher 3198, der ein Systemspeicher (z. B. DRAM) und/oder ein lokaler Grafikspeicher (z. B. GDDR6-Speicher) sein kann.
Eine Eingabe/Ausgabe(E/A)-Schaltungsanordnung 3195 koppelt die GPU 3105 mit einer oder mehreren E/A-Vorrichtungen 3195, wie etwa digitalen Signalprozessoren (DSPs), Netzwerksteuerungen oder Benutzereingabevorrichtungen. Eine On-Chip-Zwischenverbindung kann verwendet werden, um die E/A-Vorrichtungen 3190 mit der GPU 3105 und dem Speicher 3198 zu koppeln. Eine oder mehrere E/A-Speicherverwaltungseinheiten (IOMMUs) 3170 der E/A-Schaltungsanordnung 3195 koppeln die E/A-Vorrichtungen 3190 direkt mit dem Systemspeicher 3198. Die IOMMU 3170 kann mehrere Sätze von Seitentabellen verwalten, um virtuelle Adressen auf physische Adressen in dem Systemspeicher 3198 abzubilden. Zusätzlich dazu können die E/A-Vorrichtungen 3190, die CPU(s) 3199 und die GPU(s) 3105 denselben virtuellen Adressraum gemeinsam nutzen.
Die IOMMU 3170 kann auch Virtualisierung unterstützen. In diesem Fall kann sie einen ersten Satz von Seitentabellen verwalten, um virtuelle Gast-/Grafikadressen auf physische Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen, um die physischen Gast-/Grafikadressen auf physische System-/Host-Adressen abzubilden (z. B. innerhalb des Systemspeichers 3198). Die Basisadressen sowohl des ersten als auch des zweiten Satzes von Seitentabellen können in Steuerregistern gespeichert werden und auf einem Kontextschalter (z. B., so dass dem neuen Kontext Zugriff auf den relevanten Satz von Seitentabellen bereitgestellt wird) ausgelagert werden. Obwohl in 31 nicht veranschaulicht, können jeder der Kerne 3130, 3140, 3150 und/oder die Mehrkerngruppen 3100A-N Übersetzungspuffer (TLBs: Translation Lookasside Buffer) aufweisen, um Gast-Virtuell-zu-Gast-Physisch-Übersetzungen, Gast-Physisch-zu-Host-Physisch-Übersetzungen und Gast-Virtuell-zu-Host-Physisch-Übersetzungen zwischenzuspeichern.
Die CPUs 3199, GPUs 3105 und E/A-Vorrichtungen 3190 können auf einem einzigen Halbleiterchip und/oder Chipgehäuse integriert sein. Der veranschaulichte Speicher 3198 kann auf demselben Chip integriert sein oder kann über eine chipexterne Schnittstelle mit den Speichersteuerungen 3170 gekoppelt sein. Bei einer Implementierung umfasst der Speicher 3198 einen GDDR6-Speicher, der denselben virtuellen Adressraum wie andere physische Systemebenenspeicher nutzt, obgleich die zugrundeliegenden Prinzipien der Erfindung nicht auf diese spezielle Implementierung beschränkt sind.
Die Tensorkerne 3140 können mehrere Ausführungseinheiten aufweisen, die speziell dafür ausgelegt sind, Matrixoperationen durchzuführen, die die grundlegende Rechenoperation sind, die verwendet wird, um Deep-Learning-Operationen durchzuführen. Zum Beispiel können simultane Matrixmultiplikationsoperationen für neuronales Netzwerktraining und Inferenz verwendet werden. Die Tensorkerne 3140 können eine Matrixverarbeitung unter Verwendung einer Vielzahl von Operandengenauigkeiten durchführen, einschließlich Gleitkomma mit einfacher Genauigkeit (z. B. 32 Bits), Gleitkomma mit halber Genauigkeit (z. B. 16 Bits), ganzzahligen Wörtern (16 Bits), Bytes (8 Bits) und Halbbytes (4 Bits). Eine Neuronalnetzwerk-Implementierung kann auch Merkmale jeder gerenderten Szene extrahieren, potentiell Details aus mehreren Frames kombinieren, um ein finales Bild hoher Qualität zu konstruieren.
Bei Deep-Learning-Implementierungen kann Parallelmatrix-Multiplikationsarbeit zur Ausführung auf den Tensorkernen 3140 geplant werden. Insbesondere erfordert das Training neuronaler Netzwerke eine signifikante Anzahl an Matrixskalarproduktoperationen. Um eine Innenproduktformulierung einer N x N x N-Matrixmultiplikation zu verarbeiten, können die Tensorkerne 3140 mindestens N Skalarproduktverarbeitungselemente aufweisen. Bevor die Matrixmultiplikation beginnt, wird pro Zyklus für N Zyklen eine ganze Matrix in Kachelregister geladen und mindestens eine Spalte einer zweiten Matrix geladen. In jedem Zyklus gibt es N Skalarprodukte, die verarbeitet werden.
Matrixelemente können in Abhängigkeit von der speziellen Implementierung mit unterschiedlichen Genauigkeiten gespeichert werden, einschließlich 16-Bit-Wörtern, 8-Bit-Bytes (z. B. INT8) und 4-Bit-Halbbytes (z. B. INT4). Unterschiedliche Genauigkeitsmodi können für die Tensorkerne 3140 spezifiziert werden, um sicherzustellen, dass die effizienteste Genauigkeit für unterschiedliche Arbeitslasten verwendet wird (wie etwa Inferenzieren von Arbeitslasten, die Quantisierung zu Bytes und Halbbytes tolerieren können).
Die Strahlverfolgungskerne 3150 können verwendet werden, um Strahlverfolgungsoperationen sowohl für Echtzeit-Strahlverfolgungs- als auch für Nicht-Echtzeit-Strahlverfolgungs-Implementierungen zu beschleunigen. Insbesondere können die Strahlverfolgungskerne 3150 eine Strahltraversierungs-/-schnittpunktschaltungsanordnung zum Durchführen einer Strahltraversierung unter Verwendung von Begrenzungsvoluminahierarchien (BVHs: Bounding Volume Hierarchies) und Identifizieren von Schnittpunkten zwischen Strahlen und Primitiven, die in den BVH-Volumina enthalten sind, aufweisen. Die Strahlverfolgungskerne 3150 können auch eine Schaltungsanordnung zum Durchführen von Tiefentest und Aussonderung (z. B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung) aufweisen. Bei einer Implementierung führen die Strahlverfolgungskerne 3150 Traversierungs- und Schnittoperationen in Übereinstimmung mit den hier beschriebenen Bildentrauschungstechniken durch, von denen mindestens ein Teil auf den Tensorkernen 3140 ausgeführt werden kann. Die Tensorkerne 3140 können zum Beispiel ein neuronales Netzwerk mit tiefem Lernen implementieren, um eine Entrauschung von Frames durchzuführen, die durch die Strahlverfolgungskerne 3150 erzeugt werden. Die CPU(s) 3199, Grafikkerne 3130 und/oder Strahlverfolgungskerne 3150 können jedoch auch alle oder einen Teil der Entrauschungs- und/oder Tiefenlernalgorithmen implementieren.
Zusätzlich kann, wie oben beschrieben, ein verteilter Ansatz zum Entrauschen eingesetzt werden, bei dem sich die GPU 3105 in einer Rechenvorrichtung befindet, die über ein Netzwerk oder eine Hochgeschwindigkeitsverbindung mit anderen Rechenvorrichtungen gekoppelt ist. Die miteinander verbundenen Rechenvorrichtungen können zusätzlich neuronale Netzwerklern-/Trainingsdaten gemeinsam nutzen, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, eine Entrauschung für unterschiedliche Typen von Bildframes und/oder unterschiedliche Grafikanwendungen durchzuführen.
Die Strahlverfolgungskerne 3150 können alle BVH-Traversierung und Strahl-Primitiv-Schnittpunkte verarbeiten, was die Grafikkerne 3130 daran hindert, mit tausenden Anweisungen pro Strahl überlastet zu werden. Jeder Strahlverfolgungskern 3150 kann einen ersten Satz spezialisierter Schaltungen zum Durchführen von Bounding-Box-Tests (z. B. für Traversieroperationen) und einen zweiten Satz spezialisierter Schaltungen zum Durchführen der Strahl-Dreieck-Schnitttests (z. B. kreuzende Strahlen, die durchlaufen wurden) aufweisen. Somit kann die Mehrkerngruppe 3100A einfach eine Strahlsonde starten und die Strahlverfolgungskerne 3150 führen unabhängig Strahltraversierung und Kreuzung durch und geben Trefferdaten (z. B. ein Treffer, kein Treffer, mehrere Treffer usw.) in den Thread-Kontext zurück. Die anderen Kerne 3130, 3140 können freigegeben werden, um andere Grafik- oder Rechenarbeit durchzuführen, während die Strahlverfolgungskerne 3150 die Traversier- und Schnittoperationen durchführen.
Jeder Strahlverfolgungskern 3150 kann eine Traversiereinheit zum Durchführen von BVH-Testoperationen und eine Kreuzungseinheit, die Strahlen-Primitiv-Kreuzungstests durchführt, aufweisen. Die Kreuzungseinheit kann dann eine „Treffer“-, „kein Treffer“- oder „Mehrfachtreffer“-Antwort erzeugen, die sie dem geeigneten Thread bereitstellt. Während der Traversierungs- und Kreuzungsoperationen können die Ausführungsressourcen der anderen Kerne (z. B. Grafikkerne 3130 und Tensorkerne 3140) freigegeben werden, um andere Formen von Grafikarbeit durchzuführen.
Ein hybrider Rasterisierungs-/Strahlverfolgungs-Ansatz kann auch verwendet werden, bei dem Arbeit zwischen den Grafikkernen 3130 und Strahlverfolgungskernen 3150 verteilt wird.
Die Strahlverfolgungskerne 3150 (und/oder andere Kerne 3130, 3140) können Hardwareunterstützung für einen Strahlverfolgungsanweisungssatz, wie etwa Mikrosoft's DirectX Ray Tracing (DXR), der einen DispatchRays-Befehl aufweist, sowie Strahlerzeugungs-, Nahtreffer-, Any-Treffer- und Fehltreffer-Shader aufweisen, die die Zuweisung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglichen. Eine andere Strahlverfolgungsplattform, die durch die Strahlverfolgungskerne 3150, Grafikkerne 3130 und Tensorkerne 3140 unterstützt werden kann, ist Vulkan 1.1.85. Es sei jedoch angemerkt, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf irgendeine spezielle Strahlverfolgungs-ISA beschränkt sind.
Im Allgemeinen können die verschiedenen Kerne 3150, 3140, 3130 einen Strahlverfolgungsanweisungssatz unterstützen, der Anweisungen/Funktionen für Strahlerzeugung, Nächster-Treffer, Beliebiger-Treffer, Strahl-Primitiv-Schnittpunkt, Primitiv-weise und hierarchische Hüllquaderkonstruktion, Fehltreffer, Visit und Ausnahmen aufweist. Genauer gesagt können Strahlverfolgungsanweisungen enthalten sein, um die folgenden Funktionen durchzuführen:

Strahlerzeugung - Strahlerzeugungsanweisungen können für jedes Pixel, jede Abtastung oder jede andere benutzerdefinierte Arbeitszuweisung ausgeführt werden.
Nächster Treffer - Eine Nächster-Treffer-Anweisung kann ausgeführt werden, um den nächsten Schnittpunkt eines Strahls mit Primitiven innerhalb einer Szene zu lokalisieren.
Beliebiger Treffer - Eine Beliebiger-Treffer-Anweisung identifiziert mehrere Schnittpunkte zwischen einem Strahl und Primitiven innerhalb einer Szene, um potentiell einen neuen nächsten Schnittpunkt zu identifizieren.
Schnittpunkt - Eine Schnittpunktanweisung führt eine Strahl-Primitiv-Schnittpunktprüfung durch und gibt ein Ergebnis aus.
Primitiv-weise Hüllquaderkonstruktion - Diese Anweisung erstellt einen Hüllquader um ein gegebenes Primitiv oder eine gegebene Gruppe von Primitiven herum (z. B. wenn eine neue BVH- oder andere Beschleunigungsdatenstruktur erstellt wird).
Fehltreffer - gibt an, dass ein Strahl die gesamte Geometrie innerhalb einer Szene oder eine spezifizierte Region einer Szene verfehlt.
Visit - gibt die Kindervolumina an, die ein Strahl durchlaufen wird.
Ausnahmen - umfassen verschiedene Typen von Ausnahmehandhabern (z. B. aufgerufen für verschiedene Fehlerbedingungen).

HIERARCHISCHE STRAHLVERFOLGUNG
Bounding Volume Hierarchies werden üblicherweise verwendet, um die Effizienz zu verbessern, mit der Operationen an Grafikprimitiven und anderen Grafikobjekten durchgeführt werden. Ein BVH ist eine hierarchische Baumstruktur, die basierend auf einer Menge geometrischer Objekte aufgebaut wird. Am oberen Ende der Baumstruktur befindet sich der Wurzelknoten, der alle geometrischen Objekte in einer gegebenen Szene umschließt. Die einzelnen geometrischen Objekte sind in Begrenzungsvolumina eingewickelt, die die Blattknoten des Baums bilden. Diese Knoten werden dann als kleine Mengen gruppiert und innerhalb größerer Bounding Volumes eingeschlossen. Diese wiederum werden auch rekursiv in anderen größeren Begrenzungsvolumina gruppiert und eingeschlossen, was schließlich zu einer Baumstruktur mit einem einzigen Begrenzungsvolumen führt, das durch den Wurzelknoten repräsentiert wird, an der Oberseite des Baums. Bounding Volume Hierarchies werden verwendet, um eine Vielzahl von Operationen an Sätzen geometrischer Objekte effizient zu unterstützen, wie etwa Kollisionsdetektion, Primitive Aussonderung und Strahltraversierungs-/Schnittoperationen, die bei der Strahlverfolgung verwendet werden.
In Strahlverfolgungsarchitekturen werden Strahlen durch eine BVH durchlaufen, um Strahl-Primitiv-Schnittpunkte zu bestimmen. Falls zum Beispiel ein Strahl nicht durch den Wurzelknoten der BVH verläuft, dann schneidet der Strahl keines der Primitive, die durch die BVH eingeschlossen sind, und es ist keine weitere Verarbeitung für den Strahl mit Bezug auf diesen Satz von Primitiven erforderlich. Falls ein Strahl durch einen ersten Kind-Knoten der BVH verläuft, aber nicht durch den zweiten Kind-Knoten, dann muss der Strahl nicht gegen Primitive getestet werden, die durch den zweiten Kind-Knoten eingeschlossen sind. Auf diese Weise stellt eine BVH einen effizienten Mechanismus zum Testen auf strahlprimitive Schnittpunkte bereit.
Gruppen zusammenhängender Strahlen, die als „Strahlenbündeö“ bezeichnet werden, können anstelle einzelner Strahlen gegen die BVH getestet werden. 32 veranschaulicht ein beispielhaftes Strahlenbündel 3201, das durch vier verschiedene Strahlen umrissen wird. Jegliche Strahlen, die das durch die vier Strahlen definierte Patch 3200 schneiden, werden als innerhalb desselben Strahlenbündels liegend betrachtet. Während das Strahlenbündel 3201 in 32 durch eine rechteckige Anordnung von Strahlen definiert ist, können Strahlenbündel auf verschiedene andere Weisen definiert werden, während sie weiterhin die zugrundeliegenden Prinzipien der Erfindung erfüllen (z. B. Kreise, Ellipsen usw.).
33 veranschaulicht, wie eine Strahlverfolgungsengine 3310 einer GPU 3320 die hier beschriebenen Strahlverfolgungstechniken implementiert. Insbesondere erzeugt die Strahlerzeugungsschaltungsanordnung 3304 mehrere Strahlen, für die Traversier- und Schnittoperationen durchzuführen sind. Anstatt jedoch Traversier- und Schnittoperationen an einzelnen Strahlen durchzuführen, werden Traversier- und Schnittoperationen unter Verwendung einer Hierarchie von Strahlenbündel 3307 durchgeführt, die durch die Strahlhierarchiekonstruktionsschaltungsanordnung 3305 erzeugt werden. Die Strahlhierarchie ist analog zur Bounding Volume Hierarchy (BVH). Zum Beispiel stellt 34 ein Beispiel für einen Primärstrahl 3400 bereit, der in mehrere unterschiedliche Komponenten unterteilt sein kann. Insbesondere kann der Primärstrahl 3400 in Quadranten 3401-3404 unterteilt sein und jeder Quadrant kann selbst in Unterquadranten, wie etwa Unterquadranten A-D innerhalb des Quadranten 3404, unterteilt sein. Die Aufteilung des Primärstrahls kann auf verschiedene Weise erfolgen. Zum Beispiel kann der Primärstrahl hälftig (anstatt Quadranten) geteilt werden und jede Hälfte kann hälftig geteilt werden usw. Unabhängig davon, wie die Unterteilungen vorgenommen werden, wird eine hierarchische Struktur auf ähnliche Weise wie eine BVH erzeugt, z. B. mit einem Wurzelknoten, der den Primärstrahl 3400 repräsentiert, einer ersten Ebene von Kind-Knoten, die jeweils durch einen Quadranten 3401-3404 repräsentiert werden, Kind-Knoten der zweiten Ebene für jeden Unterquadranten A-D und so weiter.
Sobald die Strahlhierarchie 3307 konstruiert ist, kann die Traversierungs-/Schnittschaltungsanordnung 3306 Traversierungs-/Schnittoperationen unter Verwendung der Strahlhierarchie 3307 und der BVH 3308 durchführen. Insbesondere kann sie den Strahl gegen die BVH testen und Teile des Strahls, die keine Teile der BVH schneiden. Unter Verwendung der in 34 gezeigten Daten, falls zum Beispiel die mit den Teilregionen 3402 und 3403 assoziierten Teilstrahlen die BVH oder einen speziellen Zweig der BVH nicht schneiden, dann können sie mit Bezug auf die BVH oder den Zweig ausgesondert werden. Die verbleibenden Teile 3401, 3404 können gegen die BVH getestet werden, indem eine Tiefensuche oder ein anderer Suchalgorithmus durchgeführt wird.
Ein Verfahren zur Strahlverfolgung ist in 35 veranschaulicht. Das Verfahren kann im Kontext der oben beschriebenen Grafikverarbeitungsarchitekturen implementiert werden, ist aber nicht auf irgendeine bestimmte Architektur beschränkt.
Bei 3500 wird ein Primärstrahl konstruiert, der mehrere Strahlen aufweist, und bei 3501 wird der Strahl unterteilt und werden hierarchische Datenstrukturen erzeugt, um eine Strahlhierarchie zu erzeugen. Die Operationen 3500-3501 können als eine einzige integrierte Operation durchgeführt werden, die eine Strahl hierarchie aus mehreren Strahlen konstruiert. Bei 3502 wird die Strahlhierarchie mit einer BVH verwendet, um Strahlen (aus der Strahl hierarchie) und/oder Knoten/Primitive aus der BVH auszusondern. Bei 3503 werden Strahl-Primitiv-Schnittpunkte für die verbleibenden Strahlen und Primitive bestimmt.
VERLUSTBEHAFTETE UND VERLUSTFREIE PAKETKOMPRIMIERUNG IN EINEM VERTEILTEN STRAHLVERFOLGUNGSSYSTEM
Strahlverfolgungsoperationen können über mehrere Rechenknoten verteilt sein, die über ein Netzwerk miteinander gekoppelt sind. 36 veranschaulicht zum Beispiel einen Strahlverfolgungs-Cluster 3600, der mehrere Strahlverfolgungsknoten 3610-3613 aufweist, die Strahlverfolgungsoperationen parallel durchführen, wobei potentiell die Ergebnisse an einem der Knoten kombiniert werden. In der veranschaulichten Architektur sind die Strahlverfolgungsknoten 3610-3613 über ein Gateway kommunikativ mit einer clientseitigen Strahlverfolgungsanwendung 3630 gekoppelt.
Eine der Schwierigkeiten bei einer verteilten Architektur ist die große Menge an paketierten Daten, die zwischen jedem der Strahlverfolgungsknoten 3610-3613 übertragen werden müssen. Sowohl verlustfreie Komprimierungstechniken als auch verlustbehaftete Komprimierungstechniken können verwendet werden, um die zwischen den Strahlverfolgungsknoten 3610-3613 übertragenen Daten zu reduzieren.
Um verlustfreie Komprimierung zu implementieren, anstatt Pakete zu senden, die mit den Ergebnissen bestimmter Arten von Operationen gefüllt sind, werden Daten oder Befehle gesendet, die es dem empfangenden Knoten ermöglichen, die Ergebnisse zu rekonstruieren. Stochastisch abgetastete Flächenlichter und Umgebungsokklusions(AO)-Operationen benötigen zum Beispiel nicht notwendigerweise Anweisungen. Folglich kann ein Sendeknoten einfach einen zufälligen Keim senden, der dann durch den Empfangsknoten verwendet wird, um eine zufällige Abtastung durchzuführen. Falls zum Beispiel eine Szene über die Knoten 3610-3612 verteilt ist, müssen, um das Licht 1 an den Punkten p1-p3 abzutasten, nur die Licht-ID und Ursprünge an die Knoten 3610-3612 gesendet werden. Jeder der Knoten kann dann das Licht unabhängig stochastisch abtasten. Der zufällige Keim kann durch den Empfangsknoten erzeugt werden. Gleichermaßen können für Primärstrahl-Trefferpunkte Umgebungsokklusion (AO) und Weichschattenabtastung an den Knoten 3610-3612 berechnet werden, ohne auf die ursprünglichen Punkte für aufeinanderfolgende Frames zu warten. Falls zusätzlich bekannt ist, dass ein Strahlensatz zu derselben Punktlichtquelle gehen wird, können Anweisungen, die die Lichtquelle identifizieren, zu dem Empfangsknoten gesendet werden, der sie auf den Strahlensatz anwenden wird. Falls es N Umgebungsokklusionsstrahlen gibt, die einen einzelnen Punkt übertragen, kann als ein anderes Beispiel ein Befehl gesendet werden, um N Abtastungen von diesem Punkt zu erzeugen.
Verschiedene zusätzliche Techniken können zur verlustbehafteten Komprimierung angewendet werden. Zum Beispiel kann ein Quantisierungsfaktor eingesetzt werden, um alle Koordinatenwerte zu quantisieren, die mit der BVH, Primitiven und Strahlen assoziiert sind. Zusätzlich können 32-Bit-Gleitkommawerte, die für Daten verwendet werden, wie etwa BVH-Knoten und Primitive, in ganzzahlige 8-Bit-Werte umgewandelt werden. Bei einer beispielhaften Implementierung werden die Grenzen von Strahlenpaketen in voller Genauigkeit gespeichert, aber einzelne Strahlenpunkte P1-P3 werden als indizierte Offsets zu den Grenzen übertragen. Gleichermaßen können mehrere lokale Koordinatensysteme erzeugt werden, die ganzzahlige 8-Bit-Werte als lokale Koordinaten verwenden. Der Ursprungsort jedes dieser lokalen Koordinatensysteme kann unter Verwendung der Werte voller Genauigkeit (z. B. 32-Bit-Gleitkomma) codiert werden, die effektiv das globale und das lokale Koordinatensystem verbinden.
Ein Beispiel für verlustfreie Komprimierung ist das Folgende. Ein Beispiel für ein Strahldatenformat, das intern in einem Strahlverfolgungsprogramm 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]; //verwendet für Geometriekreuzungen
       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 durch Gruppieren von Werten und durch Erzeugen impliziter Strahlen unter Verwendung anwendbarer Metadaten, wo möglich.

Bündelung und Gruppierung von Strahldaten

Flags können für gemeinsame Daten oder Masken mit Modifikatoren verwendet werden.

      struct RayPacket
      {
       uint32 size;
       uint32 flags;
       list<Ray> rays; 
      }

Beispielsweise:

      RayPacket.rays = Ray_1 bis Ray_256

Ursprünge werden alle gemeinsam genutzt

Alle Strahldaten werden gepackt, außer dass nur ein einziger Ursprung über alle Strahlen hinweg gespeichert wird. RayPacket.flags ist für RAYPACKET_COMMON_ORIGIN eingestellt. Wenn RayPacket entpackt wird, wenn es empfangen wird, werden Ursprünge von dem einzigen Ursprungswert aufgefüllt.

Ursprünge werden nur unter einigen Strahlen gemeinsam genutzt

Alle Strahldaten werden gepackt, mit Ausnahme von Strahlen, die Ursprünge gemeinsam nutzen. Für jede Gruppe eindeutiger gemeinsam genutzter Ursprünge wird ein Operator aufgepackt, der die Operation (gemeinsam genutzte Ursprünge) identifiziert, den Ursprung speichert und maskiert, welche Strahlen die Informationen gemeinsam nutzen. Eine solche Operation kann an beliebigen gemeinsam genutzten Werten unter Knoten durchgeführt werden, wie etwa Material-IDs, Primitiv-IDs, Ursprung, Richtung, Normalen usw.

      struct RayOperation
      {
       uint8 operationID;
       void* value; 
      }uint64 mask;
     }

Senden impliziter Strahlen

Häufig können Strahldaten auf der Empfangsseite mit minimalen Metainformationen abgeleitet werden, die zu ihrer Erzeugung verwendet werden. Ein sehr häufiges Beispiel ist das Erzeugen mehrerer Sekundärstrahlen zum stochastischen Abtasten einer Fläche. Anstatt dass der Sender einen Sekundärstrahl erzeugt, ihn sendet und der Empfänger auf ihm arbeitet, kann der Sender einen Befehl senden, dass ein Strahl mit beliebigen abhängigen Informationen erzeugt werden muss, und der Strahl wird auf der Empfangsseite erzeugt. Falls der Strahl zuerst durch den Sender erzeugt werden muss, um zu bestimmen, an welchen Empfänger er gesendet werden soll, wird der Strahl erzeugt und der zufällige Keim kann gesendet werden, um den exakten gleichen Strahl zu regenerieren.

Um zum Beispiel einen Trefferpunkt mit 64 Schattenstrahlen abzutasten, die eine Flächenlichtquelle abtasten, schneiden sich alle 64 Strahlen mit Regionen von derselben Berechnung N4. Es entsteht Ein RayPacket mit gemeinsamem Ursprung und Normal. Es könnten mehr Daten gesendet werden, falls man wünscht, dass der Empfänger den resultierenden Pixelbeitrag schattiert, aber für dieses Beispiel sei angenommen, dass wir nur zurückgeben wollen, ob ein Strahl auf andere Knotendaten trifft. Ein RayOperation wird für eine Schattenstrahloperation erzeugt, dem der Wert des abzutastenden lightID und der Zufallszahlenkeim zugewiesen werden. Wenn N4 das Strahlenpaket empfängt, erzeugt es die vollständig gefüllten Strahldaten durch Füllen der gemeinsam genutzten Ursprungsdaten für alle Strahlen und Einstellen der Richtung basierend auf dem stochastisch mit dem Zufallszahlenkeim abgetasteten lightID, um die gleichen Strahlen zu erzeugen, wie der ursprüngliche Sender erzeugt hat. Wenn die Ergebnisse zurückgegeben werden, müssen nur binäre Ergebnisse für jeden Strahl zurückgegeben werden, was durch eine Maske über die Strahlen übergeben werden kann.

Das Senden der ursprünglichen 64 Strahlen in diesem Beispiel hätte 104 Bytes * 64 Strahlen = 6656 Bytes verwendet. Würden auch die zurückkehrenden Strahlen in ihrer Rohform gesendet, so verdoppelt sich dies ebenfalls auf 13312 Bytes. Unter Verwendung verlustfreier Komprimierung mit nur Senden der gemeinsamen Strahlenursprungs-, Normal- und Strahlerzeugungsoperation mit Keim und ID werden nur 29 Bytes gesendet, wobei 8 Bytes für die Schnittmaske zurückgegeben werden. Daraus resultiert eine über das Netzwerk zu sendende Datenkomprimierungsrate von ~ 360:1. Dies schließt keinen Overhead zum Verarbeiten der Nachricht selbst ein, der auf irgendeine Weise identifiziert werden müsste, der aber der Implementierung überlassen wird. Andere Operationen können zum Neuberechnen von Strahlenursprung und Richtungen von der pixelID für Primärstrahlen, Neuberechnen von pixelIDs basierend auf den Bereichen in dem Strahlenpaket und vielen anderen möglichen Implementierungen zum Neuberechnen von Werten durchgeführt werden. Ähnliche Operationen können für einen beliebigen einzelnen oder eine beliebige Gruppe von gesendeten Strahlen verwendet werden, einschließlich Schatten, Reflexionen, Brechung, Umgebungsokklusion, Kreuzungen, Volumenkreuzungen, Schattierung, geprellte Reflexionen bei der Pfadverfolgung usw.

37 veranschaulicht zusätzliche Details für zwei Strahlverfolgungsknoten 3710-3711, die eine Komprimierung und Dekomprimierung von Strahlverfolgungspaketen durchführen. Wenn insbesondere eine erste Strahlverfolgungsengine 3730 bereit ist, Daten an eine zweite Strahlverfolgungsengine 3731 zu übertragen, führt die Strahlenkomprimierungsschaltungsanordnung 3720 verlustbehaftete und/oder verlustfreie Komprimierung der Strahlverfolgungsdaten durch, wie hier beschrieben (z. B. Umwandeln von 32-Bit-Werten in 8-Bit-Werte, Ersetzen von Rohdaten für Anweisungen zum Rekonstruieren der Daten usw.). Die komprimierten Strahlenpakete 3701 werden von der Netzwerkschnittstelle 3725 zu der Netzwerkschnittstelle 3726 über ein lokales Netzwerk (z. B. ein 10 Gb/s-, 100 Gb/s-Ethernet-Netzwerk) übertragen. Eine Strahlendekomprimierungsschaltungsanordnung dekomprimiert dann die Strahlenpakete, falls angemessen. Sie kann zum Beispiel Befehle ausführen, um die Strahlverfolgungsdaten zu rekonstruieren (z. B. unter Verwendung eines Zufallskeims, um eine Zufallsabtastung für Beleuchtungsoperationen durchzuführen). Die Strahlverfolgungsengine 3731 verwendet dann die empfangenen Daten, um Strahlverfolgungsoperationen durchzuführen.

In der umgekehrten Richtung komprimiert die Strahlkomprimierungsschaltungsanordnung 3741 Strahldaten, die Netzwerkschnittstelle 3726 überträgt die komprimierten Strahldaten über das Netzwerk (z. B. unter Verwendung der hier beschriebenen Techniken), die Strahldekomprimierungsschaltungsanordnung 3740 dekomprimiert die Strahldaten, wenn nötig, und die Strahlverfolgungsengine 3730 verwendet die Daten in Strahlverfolgungsoperationen. Obwohl sie in 37 als eine separate Einheit veranschaulicht ist, kann die Strahlendekomprimierungsschaltungsanordnung 3740-3741 jeweils in die Strahlverfolgungsengines 3730-3731 integriert sein. In dem Maße, in dem die komprimierten Strahldaten Befehle zum Rekonstruieren der Strahldaten umfassen, können diese Befehle zum Beispiel durch jede jeweilige Strahlverfolgungsengine 3730-3731 ausgeführt werden.

Wie in 38 veranschaulicht, kann die Strahlenkomprimierungsschaltungsanordnung 3720 eine verlustbehaftete Komprimierungsschaltungsanordnung 3801 zum Durchführen der hier beschriebenen verlustbehafteten Komprimierungstechniken (z. B. Umwandeln von 32-Bit-Gleitkomma-Koordinaten in 8-Bit-Ganzzahlkoordinaten) und eine verlustfreie Komprimierungsschaltungsanordnung 3803 zum Durchführen der verlustfreien Komprimierungstechniken (z. B. Übertragen von Befehlen und Daten, um zu ermöglichen, dass die Strahlenrekomprimierungsschaltungsanordnung 3821 die Daten rekonstruiert). Die Strahlendekomprimierungsschaltungsanordnung 3721 weist eine verlustbehaftete Dekomprimierungsschaltungsanordnung 3802 und eine verlustfreie Dekomprimierungsschaltungsanordnung 3804 zum Durchführen einer verlustfreien Dekomprimierung auf.

Ein anderes beispielhaftes Verfahren ist in 39 veranschaulicht. Das Verfahren kann auf den hier beschriebenen Strahlverfolgungsarchitekturen oder anderen Architekturen implementiert werden, ist aber nicht auf irgendeine spezielle Architektur beschränkt.

Bei 3900 werden Strahldaten empfangen, die von einem ersten Strahlverfolgungsknoten zu einem zweiten Strahlverfolgungsknoten übertragen werden. Bei 3901 führt die verlustbehaftete Komprimierungsschaltungsanordnung verlustbehaftete Komprimierung an ersten Strahlverfolgungsdaten durch und bei 3902 führt die verlustfreie Komprimierungsschaltungsanordnung verlustfreie Komprimierung an zweiten Strahlverfolgungsdaten durch. Bei 3903 werden die komprimierten Strahlverfolgungsdaten zu einem zweiten Strahlverfolgungsknoten übertragen. Bei 3904 führt die verlustbehaftete/verlustfreie Dekomprimierungsschaltungsanordnung eine verlustbehaftete/verlustfreie Dekomprimierung der Strahlverfolgungsdaten durch und bei 3905 führt der zweite Strahlverfolgungsknoten Strahlverfolgungsoperationen durch, die die dekomprimierten Daten bedienen.

GRAFIKPROZESSOR MIT HARDWARE

BESCHLEUNIGTE HYBRIDSTRAHLVERFOLGUNG

Als Nächstes wird eine Hybrid-Rendering-Pipeline präsentiert, die eine Rasterisierung an Grafikkernen 3130 und Strahlverfolgungsoperationen an den Strahlverfolgungskernen 3150, Grafikkernen 3130 und/oder Kernen der CPU 3199 durchführt. Zum Beispiel können Rasterisierung und Tiefentest an den Grafikkernen 3130 anstelle der Primärstrahlenwurfstufe durchgeführt werden. Die Strahlverfolgungskerne 3150 können dann Sekundärstrahlen für Strahlreflexionen, -brechungen und -schatten erzeugen. Zusätzlich werden gewisse Regionen einer Szene, in denen die Strahlverfolgungskerne 3150 Strahlverfolgungsoperationen durchführen werden (z. B. basierend auf Materialeigenschaftsschwellen, wie etwa hohen Reflexionsgraden), ausgewählt, während andere Regionen der Szene mit Rasterisierung auf den Grafikkernen 3130 wiedergegeben werden. Diese hybride Implementierung kann für Echtzeit-Strahlverfolgungsanwendungen verwendet werden - wobei Latenz ein kritisches Problem ist.

Die unten beschriebene Strahltraversierarchitektur kann zum Beispiel eine programmierbare Schattierung und Steuerung der Strahltraversierung unter Verwendung vorhandener Single Instruction Multiple Data (SIMD)- und/oder Single Instruction Multiple Thread(SIMT)-Grafikprozessoren durchführen, während kritische Funktionen, wie etwa BVH-Traversierung und/oder Kreuzungen, unter Verwendung dedizierter Hardware beschleunigt werden. Die SIMD-Belegung für inkohärente Pfade kann durch Umgruppieren von erzeugten Shadern an spezifischen Punkten während des Traversierens und vor dem Schattieren verbessert werden. Dies wird unter Verwendung dedizierter Hardware erreicht, die Shader dynamisch, On-Chip, sortiert. Die Rekursion wird durch Aufteilen einer Funktion in Fortsetzungen verwaltet, die beim Zurückkehren ausgeführt werden, und Neugruppieren von Fortsetzungen vor der Ausführung für eine verbesserte SIMD-Belegung.

Eine programmierbare Steuerung der Strahltraversierung/Schnittmenge wird durch Zerlegen der Traversierungsfunktionalität in eine innere Traversierung, die als Hardware mit fester Funktion implementiert werden kann, und eine äußere Traversierung, die auf GPU-Prozessoren ausgeführt wird und eine programmierbare Steuerung durch benutzerdefinierte Traversierungs-Shader ermöglicht, erreicht. Der Aufwand für die Übertragung des Traversierungskontextes zwischen Hardware und Software wird reduziert, indem der innere Durchlaufzustand während des Übergangs zwischen innerem und äußerem Durchlauf konservativ abgeschnitten wird.

Die programmierbare Steuerung der Strahlverfolgung kann durch die verschiedenen in der folgenden Tabelle A aufgeführten Shader-Typen ausgedrückt werden. Für jeden Typ können mehrere Shader vorhanden sein. Beispielsweise kann jedes Material einen unterschiedlichen Treffer-Shader aufweisen. TABELLE A

Shader-Typ	Funktionalität
Primär	Einkoppeln von Primärstrahlen
Treffer	Bidirektionale Reflexionsverteilungsfunktions(BRDF)-Abtastung, Einkopplung sekundärer Strahlen
Beliebiger Treffer	Berechnung der Übertragung für alpha-texturierte Geometrie
Fehltreffer	Berechnung der Strahlung von einer Lichtquelle
Kreuzung	Sich schneidende kundenspezifische Formen
Traversierung	Instanzauswahl und Transformation
Aufrufbar	Eine Allzweckfunktion

Rekursives Strahlverfolgen kann durch eine API-Funktion initiiert werden, die den Grafikprozessor anweist, einen Satz von Primärshadern oder Kreuzungsschaltungen zu starten, die Strahl-Szenen-Kreuzungen für Primärstrahlen hervorrufen können. Dies wiederum erzeugt andere Shader, wie etwa Traversierungs-Shader, Treffer-Shader oder Miss-Shader. Ein Shader, der einen Kind-Shader erzeugt, kann auch einen Rückgabewert von diesem Kind-Shader empfangen. Aufrufbare Shader sind Universalfunktionen, die von einem anderen Shader direkt erzeugt werden können und auch Werte an den aufrufenden Shader zurückgeben können.

40 veranschaulicht eine Grafikverarbeitungsarchitektur, die eine Shader-Ausführungsschaltungsanordnung 4000 und eine Festfunktionsschaltungsanordnung 4010 aufweist. Das Universalausführungshardwaresubsystem weist mehrere SIMD(Single Instruction Multiple Data)- und/oder SIMT(Single Instruction Multiple Threads)-Kerne/Ausführungseinheiten (EUs) 4001 (d. h. jeder Kern kann mehrere Ausführungseinheiten aufweisen), einen oder mehrere Sampler 4002 und einen Level 1(L1)-Cache 4003 oder eine andere Form von lokalem Speicher auf. Das Festfunktionshardwaresubsystem 4010 weist eine Nachrichteneinheit 4004, einen Scheduler 4007, eine Strahl-BVH-Traversierungs-/Kreuzungsschaltungsanordnung 4005, eine Sortierschaltungsanordnung 4008 und einen lokalen L1-Cache 4006 auf.

Im Betrieb sendet der Primärdispatcher 4009 einen Satz von Primärstrahlen an den Scheduler 4007, der Arbeiten an Shadern plant, die auf den SIMD/SIMT-Kernen/EUs 4001 ausgeführt werden. Die SIMD-Kerne/EUs 4001 können Strahlverfolgungskerne 3150 und/oder Grafikkerne 3130 sein, die oben beschrieben sind. Die Ausführung der primären Shader erzeugt zusätzliche durchzuführende Arbeit (die z. B. durch einen oder mehrere Kind-Shader und/oder Hardware mit fester Funktion auszuführen ist). Die Nachrichteneinheit 4004 verteilt Arbeit, die durch die SIMD-Kerne/EUs 4001 erzeugt wird, an den Scheduler 4007, der nach Bedarf auf den freien Stapelpool, die Sortierschaltungsanordnung 4008 oder die Strahl-BVH-Kreuzungsschaltungsanordnung 4005 zugreift. Falls die zusätzliche Arbeit an den Scheduler 4007 gesendet wird, wird sie zur Verarbeitung auf den SIMD/SIMT-Kernen/EUs 4001 geplant. Vor dem Planen kann die Sortierschaltungsanordnung 4008 die Strahlen in Gruppen oder Bins sortieren, wie hier beschrieben (z. B. Gruppieren von Strahlen mit ähnlichen Charakteristiken). Die Strahl-BVH-Kreuzungsschaltungsanordnung 4005 führt eine Kreuzungsprüfung von Strahlen unter Verwendung von BVH-Volumina durch. Zum Beispiel kann die Strahl-BVH-Kreuzungsschaltungsanordnung 4005 Strahlenkoordinaten mit jeder Ebene der BVH vergleichen, um Volumina zu identifizieren, die von dem Strahl geschnitten werden.

Shader können unter Verwendung einer Shader-Aufzeichnung, einer benutzerzugewiesenen Struktur, die einen Zeiger auf die Eingangsfunktion, herstellerspezifische Metadaten und globale Argumente auf den Shader, der durch die SIMD-Kerne/EUs 4001 ausgeführt wird, aufweist, referenziert werden. Jede ausführende Instanz eines Shaders ist mit einem Aufrufstapel assoziiert, der verwendet werden kann, um Argumente zu speichern, die zwischen einem Eltern-Shader und einem Kind-Shader weitergeleitet werden. Aufrufstapel können auch Referenzen auf die Fortsetzungsfunktionen speichern, die ausgeführt werden, wenn ein Aufruf zurückkehrt.

41 veranschaulicht einen beispielhaften Satz von zugewiesenen Stapeln 4101, der einen Primär-Shader-Stapel, einen Treffer-Shader-Stapel, einen Traversier-Shader-Stapel, einen Fortsetzungsfunktionsstapel und einen Strahl-BVH-Kreuzungsstapel (der, wie beschrieben, durch Festfunktionshardware 4010 ausgeführt werden kann) aufweist. Neue Shader-Aufrufe können neue Stapel aus einem freien Stapelpool 4102 implementieren. Die Aufrufstapel, z. B. Stapel, die in dem Satz von zugewiesenen Stapeln enthalten sind, können in einem lokalen Ll-Cache 4003, 4006 zwischengespeichert werden, um die Latenz von Zugriffen zu reduzieren.

Es kann eine endliche Anzahl von Aufrufstapeln geben, die jeweils eine feste Maximalgröße „Sstack“ aufweisen, die in einem zusammenhängenden Speicherbereich zugewiesen ist. Daher kann die Basisadresse eines Stapels direkt aus einem Stapelindex (SID) als Basisadresse = SID * Sstack berechnet werden. Stapel-IDs können durch den Scheduler 4007 zugewiesen und freigegeben werden, wenn Arbeiten an den SIMD-Kernen/EUs 4001 geplant werden.

Der Primärdispatcher 4009 kann einen Grafikprozessorbefehlsprozessor aufweisen, der Primär-Shader als Reaktion auf einen Dispatch-Befehl von dem Host (z. B. einer CPU) aussendet. Der Scheduler 4007 kann diese Sendeanforderungen empfangen und startet einen Primärshader auf einem SIMD-Prozessor-Thread, falls er eine Stapel-ID für jede SIMD-Spur zuweisen kann. Stapel-IDs können aus dem freien Stapelpool 4102, der zu Beginn des Versandbefehls initialisiert wird, zugewiesen werden.

Ein ausführender Shader kann einen Kind-Shader erzeugen, indem er eine erzeugte Nachricht an die Nachrichtenübermittlungseinheit 4004 sendet. Dieser Befehl umfasst die Stapel-IDs, die mit dem Shader assoziiert sind, und umfasst auch einen Zeiger auf die Kind-Shader-Aufzeichnung für jede aktive SIMD-Spur. Ein Eltern-Shader kann diese Nachricht nur einmal für eine aktive Spur ausgeben. Nach dem Senden von Erzeugungsnachrichten für alle relevanten Spuren kann der Eltern-Shader enden.

Ein Shader, der auf den SIMD-Kernen/EUs 4001 ausgeführt wird, kann auch Aufgaben mit fester Funktion erzeugen, wie etwa Strahl-BVH-Kreuzungen unter Verwendung einer erzeugten Nachricht mit einem Shader-Aufzeichnungszeiger, der für die Festfunktionshardware reserviert ist. Wie erwähnt, sendet die Nachrichtenübermittlungseinheit 4004 erzeugte Strahl-BVH-Kreuzungsarbeit an die Strahl-BVH-Kreuzungsschaltungsanordnung 4005 mit fester Funktion und aufrufbare Shader direkt an die Sortierschaltungsanordnung 4008. Die Sortierschaltungsanordnung kann die Shader nach einem Shader-Aufzeichnungszeiger gruppieren, um einen SIMD-Stapel mit ähnlichen Charakteristiken abzuleiten. Dementsprechend können Stapel-IDs von unterschiedlichen Eltern-Shadern durch die Sortierschaltungsanordnung 4008 in demselben Stapel gruppiert werden. Die Sortierschaltungsanordnung 4008 sendet gruppierte Stapel an den Scheduler 4007, der auf die Shader-Aufzeichnung aus dem Grafikspeicher 2511 oder dem Last-Level-Cache (LLC) 4020 zugreift und den Shader auf einem Prozessorthread startet.

Fortsetzungen können als aufrufbare Shader behandelt werden und auch durch Shader-Aufzeichnungen referenziert werden. Wenn ein Kind-Shader erzeugt wird und Werte an den Eltern-Shader zurückgibt, kann ein Zeiger auf die Fortsetzungs-Shader-Aufzeichnung auf den Aufrufstapel 4101 geschoben werden. Wenn ein Kind-Shader zurückkehrt, kann die Fortsetzungs-Shader-Aufzeichnung dann von dem Aufrufstapel 4101 abgerufen werden und ein Fortsetzungs-Shader kann erzeugt werden. Optional können erzeugte Fortsetzungen die Sortiereinheit ähnlich aufrufbaren Shadern durchlaufen und auf einem Prozessorthread gestartet werden.

Wie in 42 veranschaulicht, gruppiert die Sortierschaltungsanordnung 4008 erzeugte Aufgaben durch Shader-Aufzeichnungszeiger 4201A, 4201B, 4201n, um SIMD-Stapel zur Schattierung zu erzeugen. Die Stapel-IDs oder Kontext-IDs in einem sortierten Stapel können aus unterschiedlichen Sendungen und unterschiedlichen Eingabe-SIMD-Spuren gruppiert werden. Eine Gruppierungsschaltungsanordnung 4210 kann das Sortieren unter Verwendung einer inhaltsadressierbaren Speicher(CAM)-Struktur 4201 durchführen, die mehrere Einträge aufweist, wobei jeder Eintrag mit einem Tag 4201 identifiziert ist. Wie erwähnt, kann das Tag 4201 ein entsprechender Shader-Aufzeichnungszeiger 4201A, 4201B, 4201n sein. Die CAM-Struktur 4201 kann eine begrenzte Anzahl von Tags (z. B. 32, 64, 128 usw.) speichern, die jeweils mit einem unvollständigen SIMD-Stapel assoziiert sind, der einem Shader-Aufzeichnungszeiger entspricht.

Für einen eingehenden Erzeugungsbefehl weist jede SIMD-Spur eine entsprechende Stapel-ID (gezeigt als 16 Kontext-IDs 0-15 in jedem CAM-Eintrag) und einen Shader-Aufzeichnungszeiger 4201A-B,... n (agierend als ein Tag-Wert) auf. Die Gruppierungsschaltungsanordnung 4210 kann den Shader-Aufzeichnungszeiger für jede Spur mit den Tags 4201 in der CAM-Struktur 4201 vergleichen, um einen übereinstimmenden Stapel zu finden. Wird ein übereinstimmender Stapel gefunden, kann die Stapel-ID/Kontext-ID dem Stapel hinzugefügt werden. Andernfalls kann ein neuer Eintrag mit einem neuen Shader-Aufzeichnungszeiger-Tag erzeugt werden, wodurch möglicherweise ein älterer Eintrag mit einem unvollständigen Stapel entfernt wird.

Ein ausführender Shader kann den Aufrufstapel aufheben, wenn er leer ist, indem er eine Aufhebungsnachricht an die Nachrichteneinheit sendet. Die Zuordnungsfreigabe-Nachricht wird an den Scheduler weitergeleitet, der Stapel-IDs/Kontext-IDs für aktive SIMD-Spuren an den freien Pool zurückgibt.

Es wird ein hybrider Ansatz für Strahltraversieroperationen unter Verwendung einer Kombination aus Strahltraversierung mit fester Funktion und Softwarestrahltraversierung präsentiert. Folglich stellt sie die Flexibilität des Softwaredurchlaufs bereit, während die Effizienz des Durchlaufs mit fester Funktion beibehalten wird. 43 zeigt eine Beschleunigungsstruktur, die für eine hybride Traversierung verwendet werden kann, die ein zweistufiger Baum mit einer einzigen oberen Ebene BVH 4300 und mehreren unteren Ebenen BVHs 4301 und 4302 ist. Grafische Elemente sind rechts gezeigt, um innere Traversierungspfade 4303, äußere Traversierungspfade 4304, Traversierungsknoten 4305, Blattknoten mit Dreiecken 4306 und Blattknoten mit angepassten Primitiven 4307 anzugeben.

Die Blattknoten mit Dreiecken 4306 in der oberen Ebene BVH 4300 können Dreiecke, Kreuzungs-Shader-Aufzeichnungen für angepasste Primitive oder Traversier-Shader-Aufzeichnungen referenzieren. Die Blattknoten mit Dreiecken 4306 der BVHs 4301-4302 der unteren Ebene können nur Dreiecke und Kreuzungs-Shader-Aufzeichnungen für angepasste Primitive referenzieren. Die Art der Referenz ist innerhalb des Blattknotens 4306 codiert. Die innere Traversierung 4303 bezieht sich auf eine Traversierung innerhalb jeder BVH 4300-4302. Innere Traversieroperationen umfassen die von Strahl-BVH-Kreuzungen und die Traversierung über die BVH-Strukturen 4300-4302 ist als äußere Traversierung bekannt. Innere Traversieroperationen können effizient in Festfunktionshardware implementiert werden, während äußere Traversieroperationen mit akzeptabler Leistung mit programmierbaren Shadern durchgeführt werden können. Folglich können innere Traversieroperationen unter Verwendung der Festfunktionsschaltungsanordnung 4010 durchgeführt werden und äußere Traversieroperationen können unter Verwendung der Shader-Ausführungsschaltungsanordnung 4000 einschließlich SIMD/SIMT-Kernen/EUs 4001 zum Ausführen programmierbarer Shader durchgeführt werden.

Es sei angemerkt, dass die SIMD/SIMT-Keerne/EUs 4001 hier der Einfachheit halber manchmal einfach als „Kerne“, „SIMD-Kerne“, „EUs“ oder „SIMD-Prozessoren“ bezeichnet werden. Gleichermaßen wird die Strahl-BVH-Traversierungs-/Kreuzungsschaltungsanordnung 4005 manchmal einfach als eine „Traversierungseinheit“, „Traversierungs-/Kreuzungseinheit“ oder „Traversierungs-/Kreuzungsschaltungsanordnung“ bezeichnet. Wenn ein alternativer Begriff verwendet wird, ändert der spezielle Name, der zum Bezeichnen der jeweiligen Schaltungsanordnung/Logik verwendet wird, die zugrundeliegenden Funktionen, die die Schaltungsanordnung/Logik ausführt, nicht, wie hier beschrieben.

Obwohl dies zu Erläuterungszwecken als eine einzige Komponente in 40 veranschaulicht ist, kann darüber hinaus die Traversier-/Kreuzungseinheit 4005 eine distinkte Traversiereinheit und eine separate Kreuzungseinheit umfassen, die jeweils in einer Schaltungsanordnung und/oder Logik, wie hier beschrieben, implementiert sein können.

Wenn ein Strahl einen Traversierungsknoten während einer inneren Traversierung schneidet, kann ein Traversierungs-Shader erzeugt werden. Die Sortierschaltungsanordnung 4008 kann diese Shader durch Shader-Aufzeichnungszeiger 4201A-B, n gruppieren, um einen SIMD-Stapel zu erzeugen, der durch den Scheduler 4007 zur SIMD-Ausführung auf den Grafik-SIMD-Kernen/EUs 4001 gestartet wird. Traversierungs-Shader können die Traversierung auf mehrere Weisen modifizieren, wodurch ein breites Spektrum von Anwendungen ermöglicht wird. Zum Beispiel kann der Traversierungs-Shader eine BVH mit einem gröberen Detailniveau (LOD) auswählen oder den Strahl transformieren, um starre Körpertransformationen zu ermöglichen. Der Traversierungs-Shader kann dann eine innere Traversierung für die ausgewählte BVH hervorrufen.

Die innere Traversierung berechnet Strahl-BVH-Kreuzungen durch Traversieren der BVH und Berechnen von Strahl-Box und Strahl-Dreieck-Kreuzungen. Die innere Traversierung wird auf die gleiche Weise wie Shader erzeugt, indem eine Nachricht an die Nachrichtenübermittlungsschaltungsanordnung 4004 gesendet wird, die die entsprechende erzeugte Nachricht an die Strahl-BVH-Kreuzungsschaltungsanordnung 4005 weiterleitet, die Strahl-BVH-Kreuzungen berechnet.

Der Stapel zum inneren Durchlaufen kann lokal in der Festfunktionsschaltungsanordnung 4010 (z. B. innerhalb des L1-Caches 4006) gespeichert sein. Wenn ein Strahl einen Blattknoten schneidet, der einem Traversierungs-Shader oder einem Schnitt-Shader entspricht, kann die innere Traversierung beendet werden und der innere Stapel trunkiert werden. Der trunkierte Stapel zusammen mit einem Zeiger auf den Strahl und die BVH kann an einer Stelle, die durch den aufrufenden Shader spezifiziert wird, in den Speicher geschrieben werden, und dann kann der entsprechende Traversierungs-Shader oder Kreuzungs-Shader erzeugt werden. Falls der Strahl beliebige Dreiecke während des inneren Traversierens schneidet, können die entsprechenden Trefferinformationen als Eingabeargumente an diese Shader geliefert werden, wie im unteren Code gezeigt ist. Diese erzeugten Shader können durch die Sortierschaltungsanordnung 4008 gruppiert werden, um SIMD-Stapel zur Ausführung zu erzeugen.

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

Das Abschneiden des inneren Traversierungsstapels reduziert die Kosten für das Überlaufen desselben in den Speicher. Der in Restart Trail for Stackless BVH Traversal, High Performance Graphics (2010), S. 107 - 111 beschriebene Ansatz zum Abschneiden des Stapels auf eine kleine Anzahl von Einträgen am oberen Ende des Stapels, ein 42-Bit-Neustartpfad und ein 6-Bit-Tiefenwert, kann angewendet werden. Der Neustartpfad gibt Verzweigungen an, die bereits innerhalb der BVH genommen wurden, und der Tiefenwert gibt die Tiefe des Traversierens an entsprechend dem letzten Stapeleintrag an. Dies ist ausreichend Information, um das innere Durchlaufen zu einem späteren Zeitpunkt wieder aufzunehmen.

Der innere Durchlauf ist abgeschlossen, wenn der innere Stapel leer ist und keine BVH-Knoten mehr zu testen sind. In diesem Fall ist ein Außenstapelhandler bereitgestellt, der die Oberseite des Außenstapels entnimmt und den Durchlauf wieder aufnimmt, wenn der Außenstapel nicht leer ist.

Die äußere Traversierung kann die Haupttraversierungszustandsmaschine ausführen und kann in Programmcode implementiert sein, der durch die Shader-Ausführungsschaltungsanordnung 4000 ausgeführt wird. Sie kann eine innere Traversieranfrage unter folgenden Bedingungen hervorrufen: (1) wenn ein neuer Strahl durch einen Treffer-Shader oder einen primären Shader erzeugt wird; (2) wenn ein Traversierungs-Shader eine BVH zur Traversierung auswählt; und (3) wenn ein Außenstapelhandler die innere Traversierung für eine BVH wiederaufnimmt.

Wie in 44 veranschaulicht, wird, bevor der innere Durchlauf erzeugt wird, Platz auf dem Aufrufstapel 4405 für die Festfunktionsschaltungsanordnung 4010 zugewiesen, um den trunkierten inneren Stapel 4410 zu speichern. Die Offsets 4403-4404 zur Oberseite des Aufrufstapels und des inneren Stapels werden im Durchlaufzustand 4400 gehalten, der ebenfalls im Speicher 2511 gespeichert ist. Der Traversierungszustand 4400 umfasst auch den Strahl im Weltraum 4401 und Objektraum 4402 sowie Trefferinformationen für das nächste schneidende Primitiv.

Der Traversierungs-Shader, der Kreuzungs-Shader und der Außenstapelhandler werden alle durch die Strahl-BVH-Kreuzungsschaltungsanordnung 4005 erzeugt. Der Traversierungs-Shader weist auf dem Aufrufstapel 4405 zu, bevor er eine neue innere Traversierung für die BVH zweiter Ebene initiiert. Der Außenstapelhandler ist ein Shader, der für die Aktualisierung der Trefferinformationen und die Wiederaufnahme anstehender innerer Traversieraufgaben zuständig ist. Der Außenstapelhandler ist auch für das Erzeugen von Treffer- oder Fehltreffer-Shadern zuständig, wenn der Durchlauf abgeschlossen ist. Die Traversierung ist abgeschlossen, wenn keine anstehenden inneren Traversierungsanfragen erzeugt werden. Wenn die Traversierung abgeschlossen ist und eine Kreuzung gefunden wird, wird ein Treffer-Shader erzeugt; andernfalls wird ein Fehltreffer-Shader erzeugt.

Während das oben beschriebene hybride Traversierungsschema eine zweistufige BVH-Hierarchie verwendet, kann auch eine beliebige Anzahl von BVH-Stufen mit einer entsprechenden Änderung in der äußeren Traversierungsimplementierung implementiert werden.

Obwohl die Festfunktionsschaltungsanordnung 4010 oben zum Durchführen von Strahl-BVH-Kreuzungen beschrieben ist, können zusätzlich andere Systemkomponenten auch in der Festfunktionsschaltungsanordnung implementiert werden. Zum Beispiel kann der oben beschriebene Außenstapelhandler ein interner (nicht benutzersichtbarer) Shader sein, der potentiell in der Festfunktions-BVH-Traversierungs-/Kreuzungsschaltungsanordnung 4005 implementiert werden könnte. Diese Implementierung kann verwendet werden, um die Anzahl an ausgesendeten Shader-Stufen und Rundläufen zwischen der Festfunktionsschnitthardware 4005 und dem Prozessor zu reduzieren.

Die hier beschriebenen Beispiele ermöglichen programmierbare Schattierung und Strahltraversierungssteuerung unter Verwendung benutzerdefinierter Funktionen, die mit größerer SIMD-Effizienz auf bestehenden und zukünftigen GPU-Prozessoren ausgeführt werden können.

Programmierbare Steuerung der Strahltraversierung ermöglicht mehrere wichtige Merkmale, wie etwa prozedurale Instanziierung, stochastische Detailebenenauswahl, benutzerdefinierte Primitivkreuzung und Lazy-BVH-Aktualisierungen.

Eine programmierbare MIMD(Multiple Instruction Multiple Data)-Strahlverfolgungsarchitektur, die spekulative Ausführung von Treffer- und Kreuzungsshadern unterstützt, ist auch bereitgestellt. Insbesondere fokussiert die Architektur auf das Reduzieren des Planungs- und Kommunikationsaufwandes zwischen den programmierbaren SIMD/SIMT-Kernen/Ausführungseinheiten 4001, die oben mit Bezug auf 40 beschrieben sind, und MIMD-Traversierungs-/Kreuzungseinheiten 4005 mit fester Funktion in einer hybriden Strahlverfolgungsarchitektur. Im Folgenden sind mehrere spekulative Ausführungsschemata von Treffer- und KreuzungsShadern beschrieben, die in einem einzigen Stapel von der TraversierungsHardware versandt werden können, wodurch mehrere Traversierungs- und Shading-Rundläufe vermieden werden. Es kann eine dedizierte Schaltungsanordnung zum Implementieren dieser Techniken verwendet werden.

Die Ausführungsformen der Erfindung sind besonders vorteilhaft in Anwendungsfällen, in denen die Ausführung mehrerer Treffer- oder Kreuzungs-Shader aus einer Strahltraversierungsanfrage gewünscht wird, die signifikanten Overhead auferlegen würde, wenn sie ohne dedizierte Hardwareunterstützung implementiert werden. Diese umfassen unter anderem die nächste k-Treffer-Abfrage (Starten eines Treffer-Shaders für die k nächsten Kreuzungen) und mehrere programmierbare Kreuzungs-Shader.

Die hier beschriebenen Techniken können als Erweiterungen der in 40 veranschaulichten (und mit Bezug auf die 40-44 beschriebenen) Architektur implementiert werden. Insbesondere bauen die vorliegenden Ausführungsformen der Erfindung auf dieser Architektur mit Verbesserungen auf, um die Leistungsfähigkeit der oben erwähnten Verwendungsfälle zu verbessern.

Eine Leistungsbegrenzung hybrider Strahlverfolgungs-Traversierarchitekturen ist der Overhead des Startens von Traversieranfragen von den Ausführungseinheiten und der Overhead des Aufrufs programmierbarer Shader von der Strahlverfolgungshardware. Wenn mehrere Treffer- oder Schnitt-Shader während des Traversierens desselben Strahls aufgerufen werden, erzeugt dieser Overhead „Ausführungsrundläufe“ zwischen den programmierbaren Kernen 4001 und der Traversier-/Schnitteinheit 4005. Dadurch wird auch die Sortiereinheit 4008 mit zusätzlichem Druck beaufschlagt, der die SIMD/SIMT-Kohärenz aus den einzelnen Shader-Aufrufen extrahieren muss.

Einige Aspekte der Strahlverfolgung erfordern programmierbare Steuerung, die durch die verschiedenen Shader-Typen ausgedrückt werden kann, die in obiger Tabelle A aufgelistet sind (d. h. primär, Treffer, beliebiger Treffer, Fehltreffer, Kreuzung, Traversierung und Aufruf). Für jeden Typ können mehrere Shader vorhanden sein. Beispielsweise kann jedes Material einen unterschiedlichen Treffer-Shader aufweisen. Einige dieser Shader-Typen sind in der derzeitigen Microsoft ^® Ray Tracing API definiert.

Als eine kurze Überprüfung wird rekursives Strahlverfolgen durch eine API-Funktion initiiert, die die GPU anweist, einen Satz von Primärshadern zu starten, die Strahl-Szenen-Schnittpunkte (implementiert in Hardware und/oder Software) für Primärstrahlen hervorrufen können. Dies kann wiederum andere Shader, wie etwa Traversierungs-, Treffer- oder Fehltreffer-Shader, erzeugen. Ein Shader, der einen Kind-Shader erzeugt, kann auch einen Rückgabewert von diesem Shader empfangen. Aufrufbare Shader sind Universalfunktionen, die von einem anderen Shader direkt erzeugt werden können und auch Werte an den aufrufenden Shader zurückgeben können.

Die Strahltraversierung berechnet Strahl-Szenen-Schnittpunkte durch Traversieren und Schneiden von Knoten in einer Bounding Volume Hierarchy (BVH). Neuere Forschungen haben gezeigt, dass die Effizienz des Berechnens von Strahlen-Szenen-Schnittpunkten um mehr als eine Größenordnung unter Verwendung von Techniken verbessert werden kann, die besser für Festfunktionshardware geeignet sind, wie etwa Arithmetik mit reduzierter Genauigkeit, BVH-Komprimierung, Pro-Strahl-Zustandsmaschinen, dedizierte Kreuzungspipelines und angepasste Caches.

Die in 40 gezeigte Architektur umfasst ein solches System, bei dem ein Array von SIMD/SIMT-Kernen/Ausführungseinheiten 4001 mit einer Strahlverfolgungs-/Kreuzungseinheit 4005 mit fester Funktion interagiert, um eine programmierbare Strahlverfolgung durchzuführen. Programmierbare Shader werden auf SIMD/SIMT-Threads auf den Ausführungseinheiten/Kernen 4001 abgebildet, wobei SIMD/SIMT-Nutzung, Ausführung und Datenkohärenz für optimale Leistungsfähigkeit kritisch sind. Strahlabfragen zerlegen häufig Kohärenz aus verschiedenen Gründen wie:

• Traversaldiveraenz: Die Dauer des BVH-Traversierens variiert stark
• unter Strahlen, die asynchrone Strahlenverarbeitung begünstigen.
• Ausführungsdivergenz: Strahlen, die aus unterschiedlichen Spuren desselben SIMD/SIMT-Threads erzeugt werden, können zu unterschiedlichen Shader-Aufrufen führen.
• Datenzugriffsdivergenz: Strahlen, die unterschiedliche Oberflächen treffen, tasten unterschiedliche BVH-Knoten und Primitive und Shader greifen zum Beispiel auf unterschiedliche Texturen zu. Eine Vielfalt anderer Szenarien kann Datenzugriffsdivergenz verursachen.

Die SIMD/SIMT-Kerne/Ausführungseinheiten 4001 können Varianten von hier beschriebenen Kernen/Ausführungseinheiten sein, einschließlich Grafikkern(en) 415A-415B, Shader-Kernen 1355A-N, Grafikkernen 3130, der Grafikausführungseinheit 608, Ausführungseinheiten 852A-B oder beliebigen anderen hier beschriebenen Kernen/Ausführungseinheiten. Die SIMD/SIMT-Kerne/Ausführungseinheiten 4001 können anstelle des bzw. der Grafikkerne 415A-415B, der Shader-Kerne 1355A-N, der Grafikkerne 3130, der Grafikausführungseinheit 608, der Ausführungseinheiten 852A-B oder beliebiger anderer hierin beschriebener Kerne/Ausführungseinheiten verwendet werden. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit dem/den Grafikkern(en) 415A-415B, Shader-Kernen 1355A-N, Grafikkernen 3130, der Grafikausführungseinheit 608, Ausführungseinheiten 852A-B oder beliebigen anderen hierin beschriebenen Kernen/Ausführungseinheiten auch eine entsprechende Kombination mit den SIMD/SIMT-Kernen/Ausführungseinheiten 4001 von 40, ist aber nicht darauf beschränkt.

Die Strahlverfolgungs-/Schnitteinheit 4005 mit fester Funktion kann die ersten zwei Herausforderungen überwinden, indem jeder Strahl einzeln und außer Ordnung verarbeitet wird. Dies zerlegt jedoch SIMD/SIMT-Gruppen. Die Sortiereinheit 4008 ist somit dafür verantwortlich, neue zusammenhängende SIMD/SIMT-Gruppen von Shader-Aufrufen zu bilden, die erneut an die Ausführungseinheiten zu versenden sind.

Die Vorteile einer solchen Architektur sind im Vergleich zu einer reinen softwarebasierten Strahlverfolgungsimplementierung direkt auf den SIMD/SIMT-Prozessoren leicht zu sehen. Es gibt jedoch einen Overhead, der mit der Nachrichtenübermittlung zwischen den SIMD/SIMT-Kernen/Ausführungseinheiten 4001 (hier manchmal einfach als SIMD/SIMT-Prozessoren oder Kerne/EUs bezeichnet) und der MIMD-Traversierungs-/Kreuzungseinheit 4005 assoziiert ist. Des Weiteren extrahiert die Sortiereinheit 4008 möglicherweise keine perfekte SIMD/SIMT-Nutzung aus inkohärenten Shader-Aufrufen.

Es können Verwendungsfälle identifiziert werden, bei denen Shader-Aufrufe während des Traversierens besonders häufig sein können. Verbesserungen sind für hybride MIMD-Strahlverfolgungsprozessoren beschrieben, um den Kommunikationsaufwand zwischen den Kernen/EUs 4001 und den Traversier-/Kreuzungseinheiten 4005 signifikant zu reduzieren. Dies kann insbesondere bei der Auffindung der k-nächsten Kreuzungen und der Implementierung programmierbarer Kreuzungs-Shader von Vorteil sein. Es sei jedoch angemerkt, dass die hier beschriebenen Techniken nicht auf irgendein spezielles Verarbeitungsszenario beschränkt sind.

Eine Zusammenfassung der Kosten hoher Ebene des Strahlverfolgungs-Kontextschalters zwischen den Kernen/EUs 4001 und der Festfunktions-Traversierungs-/Kreuzungseinheit 4005 ist unten bereitgestellt. Der größte Teil des Performance-Overheads wird durch diese beiden Kontextwechsel jedes mal verursacht, wenn der Shader-Aufruf während des Einstrahldurchlaufs erforderlich ist.

Jede SIMD/SIMT-Spur, die einen Strahl startet, erzeugt eine erzeugte Nachricht an die Traversier-/Kreuzungseinheit 4005, die mit einer BVH zum Traversieren assoziiert ist. Die Daten (Strahltraversierungskontext) werden über die erzeugte Nachricht und den (zwischengespeicherten) Speicher an die Traversierungs-/Kreuzungseinheit 4005 weitergeleitet. Wenn die Traversierungs-/Kreuzungseinheit 4005 bereit ist, der erzeugten Nachricht einen neuen Hardwarethread zuzuweisen, lädt sie den Traversierungszustand und führt eine Traversierung an der BVH durch. Es gibt auch Einrichtungskosten, die vor dem ersten Traversierungsschritt an der BVH durchgeführt werden müssen.

45 veranschaulicht einen Betriebsfluss einer programmierbaren Strahlverfolgungs-Pipeline. Die schattierten Elemente einschließlich des Traversierens 4502 und des Schnittpunkts 4503 können in einer Festfunktionsschaltungsanordnung implementiert werden, während die verbleibenden Elemente mit programmierbaren Kernen/Ausführungseinheiten implementiert werden können.

Ein Primärstrahl-Shader 4501 sendet bei 4502 Arbeit an die Traversierschaltungsanordnung, die den oder die Stromstrahlen durch die BVH (oder eine andere Beschleunigungsstruktur) durchläuft. Wenn ein Blattknoten erreicht ist, ruft die Traversierungsschaltungsanordnung bei 4503 die Kreuzungsschaltungsanordnung auf, die beim Identifizieren einer Strahl-Dreieck-Kreuzung einen Beliebiger-Treffer-Shader bei 4504 aufruft (der Ergebnisse zurück an die Traversierungsschaltungsanordnung liefern kann, wie angegeben).

Alternativ dazu kann das Durchlaufen beendet werden, bevor ein Blattknoten und ein bei 4507 aufgerufener Nächster-Treffer-Shader (falls ein Treffer aufgezeichnet wurde) oder ein Fehltreffer-Shader bei 4506 (im Fall eines Fehltreffers) erreicht werden.

Wie bei 4505 angegeben, kann ein Kreuzungs-Shader aufgerufen werden, falls die Traversierschaltungsanordnung einen kundenspezifischen Primitivblattknoten erreicht. Ein individuelles Primitiv kann ein beliebiges Nicht-Dreieck-Primitiv sein, wie etwa ein Polygon oder ein Polyeder (z. B. Tetraeder, Voxel, Hexaheder, Keile, Pyramiden oder ein anderes „unstrukturiertes“ Volumen). Der Kreuzungs-Shader 4505 identifiziert beliebige Schnittpunkte zwischen dem Strahl und dem kundenspezifischen Primitiv für den Beliebiger-Treffer-Shader 4504, der eine Beliebiger-Treffer-Verarbeitung implementiert.

Wenn die Hardwaretraversierung 4502 eine programmierbare Stufe erreicht, kann die Traversierungs-/Kreuzungseinheit 4005 eine Shader-Dispatch-Nachricht an einen relevanten Shader 4505-4507 erzeugen, die einer einzigen SIMD-Spur der Ausführungseinheit(en) entspricht, die zum Ausführen des Shaders verwendet wird(werden). Da Dispatches in einer beliebigen Reihenfolge von Strahlen auftreten und sie in den aufgerufenen Programmen divergent sind, kann die Sortiereinheit 4008 mehrere Dispatch-Aufrufe akkumulieren, um kohärente SIMD-Stapel zu extrahieren. Der aktualisierte Traversierungszustand und die optionalen Shader-Argumente können durch die Traversierungs-/Kreuzungseinheit 4005 in den Speicher 2511 geschrieben werden.

In dem k-nächsten Kreuzungsproblem wird ein Nächster-Treffer-Shader 4507 für die ersten k Schnittpunkte ausgeführt. Auf herkömmliche Weise würde dies ein Beenden der Strahltraversierung beim Finden des nächsten Schnittpunkts, Aufrufen eines Treffer-Shaders und Erzeugen eines neuen Strahls aus dem Treffer-Shader bedeuten, um den nächsten nächsten Schnittpunkt zu finden (mit dem Strahlursprungsversatz, so dass derselbe Schnittpunkt nicht erneut auftritt). Es ist leicht einzusehen, dass diese Implementierung k Strahlerzeugungen für einen einzigen Strahl erfordern würde. Eine andere Implementierung arbeitet mit Beliebiger-Treffer-Shadern 4504, die für alle Kreuzungen aufgerufen werden und eine globale Liste nächster Kreuzungen unter Verwendung einer Einfügungssortieroperation pflegen. Das Hauptproblem bei diesem Ansatz besteht darin, dass es keine Obergrenze von Beliebiger-Treffer-Shader-Aufrufen gibt.

Wie erwähnt, kann ein Kreuzungs-Shader 4505 auf Nicht-Dreieck(kundenspezifischen)-Primitiven aufgerufen werden. In Abhängigkeit von dem Ergebnis des Kreuzungstests und dem Traversierungszustand (anstehende Knoten- und Primitivschnittstellen) kann das Traversieren desselben Strahls nach der Ausführung des Kreuzungs-Shaders 4505 fortgesetzt werden. Daher kann das Auffinden des nächsten Treffers mehrere Rundläufe zu der Ausführungseinheit erfordern.

Ein Fokus kann auch auf die Reduktion von SIMD-MIMD-Kontextschaltern für Kreuzungs-Shader 4505 und Treffer-Shader 4504, 4507 durch Änderungen an der Traversierhardware und dem Shader-Planungsmodell gelegt werden. Zuerst verschiebt die Strahltraversierungsschaltungsanordnung 4005 Shader-Aufrufe durch Akkumulieren mehrerer potentieller Aufrufe und Versenden dieser in einem größeren Stapel. Außerdem können gewisse Aufrufe, die sich als unnötig erweisen, in diesem Stadium ausgesondert werden. Des Weiteren kann der Shader-Scheduler 4007 mehrere Shader-Aufrufe aus demselben Traversierungskontext zu einem einzigen SIMD-Stapel aggregieren, was zu einer einzigen Strahlerzeugungsnachricht führt. Bei einer beispielhaften Implementierung suspendiert die Traversierhardware 4005 den Traversierthread und wartet auf die Ergebnisse mehrerer Shader-Aufrufe. Dieser Betriebsmodus wird hier als „spekulative“ Shader-Ausführung bezeichnet, da er das Versenden mehrerer Shader ermöglicht, von denen manche möglicherweise nicht aufgerufen werden, wenn sequenzielle Aufrufe verwendet werden.

46A veranschaulicht ein Beispiel, bei dem die Traversieroperation auf mehrere angepasste Primitive 4650 in einem Unterbaum trifft, und 46B veranschaulicht, wie dies mit drei Kreuzungsversandzyklen C1-C3 aufgelöst werden kann. Insbesondere kann der Scheduler 4007 drei Zyklen erfordern, um die Arbeit an den SIMD-Prozessor 4001 zu übermitteln, und die Traversierungsschaltungsanordnung 4005 erfordert drei Zyklen, um die Ergebnisse an die Sortiereinheit 4008 zu liefern. Der Durchlaufzustand 4601, der von der Traversierungsschaltungsanordnung 4005 benötigt wird, kann in einem Speicher, wie etwa einem lokalen Cache (z. B. einem L1-Cache und/oder L2-Cache), gespeichert werden.

A. Verzögerte Strahlverfolgungsshaderaufrufe

Die Art und Weise, auf die der Hardwaredurchlaufzustand 4601 verwaltet wird, um die Akkumulation mehrerer potentieller Kreuzungs- oder Trefferaufrufe in einer Liste zu ermöglichen, kann auch modifiziert werden. Zu einer gegebenen Zeit während des Traversierens kann jeder Eintrag in der Liste verwendet werden, um einen Shader-Aufruf zu erzeugen. Zum Beispiel können die k-nächsten Schnittpunkte auf der Traversierungshardware 4005 und/oder im Traversierungszustand 4601 in dem Speicher akkumuliert werden und Treffer-Shader können für jedes Element aufgerufen werden, falls die Traversierung abgeschlossen ist. Für Treffer-Shader können mehrere potentielle Kreuzungen für einen Unterbaum in der BVH akkumuliert werden.

Für den Nächstes-k-Verwendungsfall besteht der Vorteil dieses Ansatzes darin, dass anstelle von k-1 Rundläufen zu dem SIMD-Kern/EU 4001 und k-1 neuen Strahlerzeugungsnachrichten alle Treffer-Shader von demselben Traversier-Thread während einer einzigen Traversieroperation auf der Traversierschaltungsanordnung 4005 aufgerufen werden. Eine Herausforderung für potentielle Implementierungen besteht darin, dass es nicht trivial ist, die Ausführungsreihenfolge von Treffer-Shadern zu garantieren (der standardmäßige „RoundTrip“-Ansatz garantiert, dass der Treffer-Shader der nächsten Kreuzung zuerst ausgeführt wird usw.). Dies kann entweder durch die Synchronisation der Treffer-Shader oder die Relaxation der Ordnung angesprochen werden.

Für den Kreuzungs-Shader-Verwendungsfall weiß die Traversierungsschaltungsanordnung 4005 nicht im Voraus, ob ein gegebener Shader einen positiven Kreuzungstest zurückgeben würde. Es ist jedoch möglich, mehrere Kreuzungs-Shader spekulativ auszuführen, und wenn mindestens einer ein positives Trefferergebnis zurückgibt, wird es in den globalen nächsten Treffer fusioniert. Spezielle Implementierungen müssen eine optimale Anzahl von zurückgestellten Kreuzungstests finden, um die Anzahl von Dispatch-Aufrufen zu reduzieren, aber zu viele redundante Kreuzungs-Shader nicht aufzurufen.

B. Aggregierte Shader-Aufrufe aus der Traversierschaltungsanordnung

Wenn mehrere Shader von demselben Strahl, der auf der Traversierschaltungsanordnung 4005 erzeugt wird, gesendet werden, können Verzweigungen in dem Fluss des Strahltraversieralgorithmus erzeugt werden. Dies kann für Kreuzungs-Shader problematisch sein, da der Rest des BVH-Traversierens von dem Ergebnis aller versandten Kreuzungstests abhängt. Dies bedeutet, dass eine Synchronisationsoperation notwendig ist, um auf das Ergebnis der Shader-Aufrufe zu warten, was auf asynchroner Hardware anspruchsvoll sein kann.

Zwei Punkte des Zusammenführens der Ergebnisse der Shader-Aufrufe können sein: der SIMD-Prozessor 4001 und die Traversierschaltungsanordnung 4005. In Bezug auf den SIMD-Prozessor 4001 können mehrere Shader ihre Ergebnisse unter Verwendung von Standardprogrammierungsmodellen synchronisieren und aggregieren. Eine relativ einfache Weise, dies zu tun, besteht darin, globale Atomik zu verwenden und Ergebnisse in einer gemeinsam genutzten Datenstruktur in dem Speicher zu aggregieren, wo Schnittergebnisse mehrerer Shader gespeichert werden könnten. Dann kann der letzte Shader die Datenstruktur auflösen und die Traversierschaltungsanordnung 4005 zurückrufen, um die Traversierung fortzusetzen.

Ein effizienterer Ansatz kann auch implementiert werden, der die Ausführung mehrerer Shader-Aufrufe auf Spuren desselben SIMD-Threads auf dem SIMD-Prozessor 4001 beschränkt. Die Kreuzungstests werden dann unter Verwendung von SIMD/SIMT-Reduktionsoperationen lokal reduziert (anstatt auf globale Atomik angewiesen). Diese Implementierung kann auf eine neue Schaltungsanordnung innerhalb der Sortiereinheit 4008 angewiesen sein, um einen kleinen Stapel von Shader-Aufrufen in demselben SIMD-Stapel verbleiben zu lassen.

Die Ausführung des Traversier-Threads kann ferner auf der Traversierschaltungsanordnung 4005 ausgesetzt werden. Unter Verwendung des herkömmlichen Ausführungsmodells wird, wenn ein Shader während des Traversierens versandt wird, der Traversierthread beendet und der Strahltraversierungszustand in dem Speicher gespeichert, um die Ausführung anderer Strahlerzeugungsbefehle zu ermöglichen, während die Ausführungseinheiten 4001 die Shader verarbeiten. Wird der Traversierungs-Thread lediglich ausgesetzt, muss der Traversierungszustand nicht gespeichert werden und kann auf jedes Shader-Ergebnis separat warten. Diese Implementierung kann eine Schaltungsanordnung zum Vermeiden von Blockierungen und zum Bereitstellen einer ausreichenden Hardwarenutzung umfassen.

Die 47-48 veranschaulichen Beispiele eines verschobenen Modells, das einen einzelnen Shader-Aufruf auf den SIMD-Kernen/Ausführungseinheiten 4001 mit drei Shadern 4701 aufruft. Wenn erhalten, werden alle Kreuzungstests innerhalb derselben SIMD/SIMT-Gruppe ausgewertet. Folglich kann der nächste Schnittpunkt auch auf den programmierbaren Kernen/Ausführungseinheiten 4001 berechnet werden.

Wie erwähnt, kann die gesamte oder ein Teil der Shader-Aggregation und/oder Verschiebung durch die Durchlauf-/Kreuzungsschaltungsanordnung 4005 und/oder den Kern/EU-Scheduler 4007 durchgeführt werden. 47 veranschaulicht, wie eine Shader-Deferral/Aggregator-Schaltungsanordnung 4706 innerhalb des Schedulers 4007 ein Planen von Shadern, die mit einem bestimmten SIMD/SIMT-Thread/-Spur assoziiert sind, verschieben kann, bis ein spezifiziertes Auslöseereignis aufgetreten ist. Beim Detektieren des Auslöseereignisses sendet der Scheduler 4007 die mehreren aggregierten Shader in einem einzigen SIMD/SIMT-Stapel an die Kerne/EUs 4001 aus.

48 veranschaulicht, wie die Shader-Deferral/Aggregator-Schaltungsanordnung 4805 innerhalb der Traversierungs-/Kreuzungsschaltungsanordnung 4005 eine Planung von Shadern, die mit einem speziellen SIMD-Thread/einer speziellen SIMD-Spur assoziiert sind, verschieben kann, bis ein spezifiziertes Auslöseereignis aufgetreten ist. Beim Detektieren des Auslöseereignisses übermittelt die Durchlauf-/Kreuzungsschaltungsanordnung 4005 die aggregierten Shader an die Sortiereinheit 4008 in einem einzigen SIMD/SIMT-Stapel.

Es wird jedoch angemerkt, dass die Shader-Aufschiebe- und Aggregationstechniken innerhalb verschiedener anderer Komponenten, wie etwa der Sortiereinheit 4008, implementiert sein können oder über mehrere Komponenten verteilt sein können. Zum Beispiel kann die Durchlauf-/Kreuzungsschaltungsanordnung 4005 einen ersten Satz von Shader-Aggregationsoperationen durchführen und der Scheduler 4007 kann einen zweiten Satz von Shader-Aggregationsoperationen durchführen, um sicherzustellen, dass Shader für einen SIMD-Thread effizient auf den Kernen/EUs 4001 geplant werden.

Das „Auslöseereignis“, um zu bewirken, dass die aggregierten Shader an die Kerne/EUs gesendet werden, kann ein Verarbeitungsereignis sein, wie etwa eine bestimmte Anzahl akkumulierter Shader oder eine minimale Latenz, die mit einem bestimmten Thread assoziiert ist. Alternativ oder zusätzlich kann das auslösende Ereignis ein zeitliches Ereignis sein, wie etwa eine gewisse Dauer ab der Verschiebung des ersten Shaders oder eine gewisse Anzahl von Prozessorzyklen. Andere Variablen, wie etwa die aktuelle Arbeitslast auf den Kernen/EUs 4001 und der Durchlauf-/Kreuzungseinheit 4005, können auch durch den Scheduler 4007 evaluiert werden, um zu bestimmen, wann der SIMD/SIMT-Stapel von Shadern zu versenden ist.

Unterschiedliche Ausführungsformen der Erfindung können unter Verwendung unterschiedlicher Kombinationen der obigen Ansätze implementiert werden, basierend auf der bestimmten Systemarchitektur, die verwendet wird, und den Anforderungen der Anwendung.

STRAHLENVERFOLGUNGSANWEISUNGEN

Die unten beschriebenen Strahlverfolgungsbefehle sind in einer Befehlssatzarchitektur (ISA) enthalten, die CPU 3199 und/oder die GPU 3105 unterstützt. Wenn sie durch die CPU ausgeführt werden, können die Einzelbefehl-Mehrfachdaten(SIMD)-Befehle Vektor/gepackte Quell- und Zielregister verwenden, um die beschriebenen Operationen durchzuführen, und können durch einen CPU-Kern decodiert und ausgeführt werden. Wenn sie von einer GPU 3105 ausgeführt werden, können die Anweisungen von Grafikkernen 3130 ausgeführt werden. Zum Beispiel können beliebige der oben beschriebenen Ausführungseinheiten (EUs) 4001 die Anweisungen ausführen. Alternativ oder zusätzlich können die Anweisungen durch Ausführungsschaltungen auf den Strahlverfolgungskernen 3150 und/oder den Tensorkernen Tensorkernen 3140 ausgeführt werden.

49 veranschaulicht eine Architektur zum Ausführen der unten beschriebenen Strahlverfolgungsbefehle. Die dargestellte Architektur kann in einem oder mehreren der oben beschriebenen Kerne 3130, 3140, 3150 (siehe z. B. 31 und assoziierter Text) von integriert sein und kann in einer anderen Prozessorarchitektur enthalten sein.

Im Betrieb holt eine Befehlsabrufeinheit 4903 Strahlverfolgungsbefehle 4900 aus dem Speicher 3198 ab und ein Decodierer 4995 decodiert die Befehle. Bei einer Implementierung decodiert der Decodierer 4995 Anweisungen zum Erzeugen ausführbarer Operationen (z. B. Mikrooperationen oder Uops in einem mikrocodierten Kern). Alternativ dazu können manche oder alle der Strahlverfolgungsbefehle 4900 ohne Decodierung ausgeführt werden und, da ein solcher Decodierer 4904 nicht erforderlich ist.

Bei jeder Implementierung plant und sendet ein Scheduler/Dispatcher 4905 die Anweisungen (oder Operationen) über einen Satz von Funktionseinheiten (FUs) 4910-4912 hinweg. Die veranschaulichte Implementierung umfasst eine Vektor-FU 4910 zum Ausführen von Einzelbefehl-Mehrfachdaten(SIMD)-Befehlen, die gleichzeitig an mehreren gepackten Datenelementen arbeiten, die in Vektorregistern 4915 gespeichert sind, und eine Skalar-FU 4911 zum Arbeiten an Skalarwerten, die in einem oder mehreren Skalarregistern 4916 gespeichert sind. Eine optionale Strahlverfolgungs-FU 4912 kann an gepackten Datenwerten, die in den Vektorregistern 4915 gespeichert sind, und/oder Skalarwerten, die in den Skalarregistern 4916 gespeichert sind, arbeiten. Bei einer Implementierung ohne eine dedizierte FU 4912 können die Vektor-FU 4910 und möglicherweise die Skalar-FU 4911 die unten beschriebenen Strahlverfolgungsanweisungen durchführen.

Die verschiedenen FUs 4910-4912 greifen auf Strahlverfolgungsdaten 4902 (z. B. Traversierungs-/Schnittdaten) zu, die benötigt werden, um die Strahlverfolgungsanweisungen 4900 von den Vektorregistern 4915, dem Skalarregister 4916 und/oder dem lokalen Cache-Subsystem 4908 (z. B. einem L1-Cache) auszuführen. Die FUs 4910-4912 können auch Zugriffe auf den Speicher 3198 über Lade- und Speicheroperationen durchführen, und das Cache-Subsystem 4908 kann unabhängig arbeiten, um die Daten lokal zwischenzuspeichern.

Obwohl die Strahlverfolgungsanweisungen verwendet werden können, um die Leistungsfähigkeit für Strahltraversierung/Kreuzung und BVH-Aufbauten zu erhöhen, können sie auch auf andere Bereiche anwendbar sein, wie etwa Hochleistungsberechnung (HPC) und Universal-GPU-Implementierungen (GPGPU-Implementierungen).

In den folgenden Beschreibungen wird der Begriff Doppelwort manchmal mit dw abgekürzt und das vorzeichenlose Byte mit ub abgekürzt.

Zusätzlich dazu können sich die Quell- und Zielregister, auf die unten Bezug genommen wird (z. B., src0, src1, dest usw.), auf Vektorregister 4915 oder in manchen Fällen auf eine Kombination von Vektorregistern 4915 und Skalarregistern 4916 beziehen. Falls typischerweise ein Quell- oder Zielwert, der durch einen Befehl verwendet wird, gepackte Datenelemente aufweist (wo z. B. eine Quelle oder ein Ziel N Datenelemente speichert), werden Vektorregister 4915 verwendet. Andere Werte können Skalarregister 4916 oder Vektorregister 4915 verwenden.

Dequantisierung

Ein Beispiel für die Dequantisierungsanweisung „dequantisiert“ zuvor quantisierte Werte. Beispielsweise können in einer Strahlverfolgungsimplementierung bestimmte BVH-Unterbäume quantisiert werden, um Speicherungs- und Bandbreitenanforderungen zu reduzieren. Der Dequantisierungsbefehl kann die Form Dequantisieren dest src0 src1 src2 annehmen, wobei das Quellregister src0 N vorzeichenlose Bytes speichert, das Quellregister src1 1 vorzeichenloses Byte speichert, das Quellregister src2 1 Gleitkommawert speichert und das Zielregister dest N Gleitkommawerte speichert. Alle diese Register können Vektorregister 4915 sein. Alternativ dazu können src0 und dest Vektorregister 4915 sein und src1 und src2 können Skalarregister 4916 sein.

Die folgende Codesequenz definiert eine besondere Implementierung der Dequantisierungsanweisung:

      for (int i = 0; i < SIMD_WIDTH) {
            if (execMask[i]) {
                dst[i] = src2[i] + Idexp(convert_to_float(src0[i]),src1);
            }
     }

In diesem Beispiel multipliziert Idexp einen Gleitkommawert mit doppelter Genauigkeit mit einer spezifizierten ganzzahligen Potenz von zwei (d. h. Idexp(x, exp) = x * 2^exp). Falls in dem obigen Code der Ausführungsmaskenwert, der mit dem aktuellen SIMD-Datenelement (execMask[i])) assoziiert ist, auf 1 gesetzt wird, dann wird das SIMD-Datenelement an der Stelle i in src0 in einen Gleitkommawert umgewandelt und mit der Integralleistung des Werts in src1 (2^src1-Wert) multipliziert und dieser Wert wird zu dem entsprechenden SIMD-Datenelement in src2 addiert.

Selektive Min oder Max

Ein selektiver Minimal- oder Maximalbefehl kann entweder eine Minimal- oder Maximaloperation pro Spur durchführen (d. h. das Minimum oder Maximum eines Satzes von Werten zurückgeben), wie durch ein Bit in einer Bitmaske angegeben. Die Bitmaske kann die Vektorregister 4915, Skalarregister 4916 oder einen separaten Satz von Maskenregistern nutzen (nicht gezeigt). Die folgende Codesequenz definiert eine bestimmte Implementierung des min/max-Befehls: sel_min_max dest src0 src1 src2, wobei src0 N Doppelwörter speichert, src1 N Doppelwörter speichert, src2 ein Doppelwort speichert und das Zielregister N Doppelwörter speichert.

Folgende Codefolge definiert eine besondere Implementierung des selektiven min/max Befehls:

      für (int i = 0; i < SIMD_WIDTH) {
            wenn (execMask[i]) {
            DST[i] = (1 << i) & src2? min(src0[i],src1[i]):
            max(src0[i],src1[i]);
            }
      }

Bei diesem Beispiel wird der Wert von (1 < < i) & src2 (a 1 linksverschoben um i UND-verknüpft mit src2) verwendet, um entweder das Minimum des i-ten Datenelements in src0 und src1 oder das Maximum des i-ten Datenelements in src0 und src1 auszuwählen. Die Operation für das i^-te Datenelement nur durchgeführt wird, wenn der Ausführungsmaskenwert, der mit dem aktuellen SIMD-Datenelement (execMask[i])) assoziiert ist, auf 1 gesetzt ist.

Shuffle-Index-Anweisuna

Ein Shuffle-Index-Befehl kann einen beliebigen Satz von Eingabeabläufen auf die Ausgabeabläufe kopieren. Für eine SIMD-Breite von 32 kann dieser Befehl mit einem niedrigeren Durchsatz ausgeführt werden. Dieser Befehl nimmt die Form an: shuffle_index dest src0 src1 <optionales Flag >, wobei src0 N Doppelwörter speichert, src1 N vorzeichenlose Bytes (d. h. den Indexwert) speichert und dest N Doppelwörter speichert.

Folgende Codefolge definiert eine besondere Implementierung des Shuffle-Index-Befehls:

       für (int i = 0; i < SIMD_WIDTH) {
         uint8_t srcLane = src1.index[i]; 
         wenn (execMask[i]) {
          Bool invalidLane = srcLane < 0|| srcLane > =
       SIMD_WIDTH | | !execMask[srcLaneMod]; 
          IF (FLAG) {
           invalidLane | = Flag[srcLaneMod];
          } 
          wenn (invalidLane) {
           DST[i] = src0[i];
          }
          andernfalls {
           DST[i] = srcO[srcLane];
         }
        }
       }

In dem obigen Code identifiziert der Index in src1 die aktuelle Spur. Falls der i^-te Wert in der Ausführungsmaske auf 1 gesetzt ist, dann wird eine Prüfung durchgeführt, um sicherzustellen, dass sich die Quellspur innerhalb des Bereichs von 0 bis zur SIMD-Breite befindet. Falls ja, dann wird das Flag gesetzt (srcLaneMod) und das Datenelement i des Ziels wird gleich dem Datenelement i von src0 gesetzt. Falls sich die Spur innerhalb der Reichweite befindet (d. h. gültig ist), dann wird der Indexwert von src1 (srcLane0) als ein Index in src0 verwendet (dst[i] = src0[srcLane]).

Sofortige Huffle Up/Dn/XOR-ANWEISUNG

Eine Direkt-Shuffle-Anweisung kann Eingabedatenelemente/- spuren basierend auf einem Direktoperanden der Anweisung mischen. Der Immediat kann Verschieben der Eingabespuren um 1, 2, 4, 8 oder 16 Positionen basierend auf dem Wert des Immediats spezifizieren. Optional kann ein zusätzliches skalares Quellregister als Füllwert spezifiziert werden. Wenn der Quellspurindex ungültig ist, wird der Füllwert (falls bereitgestellt) an dem Datenelementort in dem Ziel gespeichert. Falls kein Füllwert bereitgestellt wird, wird der Datenelementort auf alle 0 gesetzt.

Als Quellenmaske kann ein Flag-Register verwendet werden. Falls das Flag-Bit für eine Quellspur auf 1 gesetzt ist, kann die Quellspur als ungültig markiert werden und der Befehl kann fortfahren.

Beispiele für verschiedene Implementierungen des Sofort-Shuffle-Befehls sind:

shuffle_<up/dn/xor>_<1/2/4/8/16> dest src0 <optional src1> <optional Flag>
shuffle_<up/dn/xor>_<1/2/4/8/16> dest src0 <optional src1> <optional Flag>

Bei dieser Implementierung speichert src0 N Doppelwörter, src1 speichert ein Doppelwort für den Füllwert (falls vorhanden) und speichert dest N Doppelwörter, die das Ergebnis umfassen.

Folgende Codefolge definiert eine besondere Implementierung des sofortigen Shuffle-Befehls:

       für (int i = 0; i < SIMD_WIDTH) {
         Int8_t srcLane;
         Switch(SHUFFLE_TYPE) {
         Fall UP: 
          srcLane = i - SHIFT;
         Fall DN:
          srcLane = i + SHIFT;
         Fall XOR:
          srcLane = i^ SHIFT;
         }





         wenn (execMask[i]) {
          Bool invalidLane = srcLane < 0|| srcLane >=
       SIMD_WIDTH | | !execMask[srcLane];
         IF (FLAG) {
           invalidLane | = Flag[srcLane];
         }
         wenn (invalidLane) {
          wenn (SRV1)
           DST[i] = srcl;
          ansonsten
           DST[i] = 0;

         }
         andernfalls {
          DST[i] = srcO[srcLane];
         }
        }
       }

Hier werden die Eingabedatenelemente/Spuren um 1, 2, 4, 8 oder 16 Positionen basierend auf dem Wert des Direktoperanden verschoben. Das Register src1 ist ein zusätzliches skalares Quellregister, das als Füllwert verwendet wird, der an der Datenelementstelle im Ziel gespeichert wird, wenn der Quellspurindex ungültig ist. Falls kein Füllwert bereitgestellt wird und der Quellspurindex ungültig ist, wird der Datenelementort im Ziel auf 0 s gesetzt. Das Flagregister (FLAG) wird als Quellmaske verwendet. Falls das Flag-Bit für eine Source-Spur auf 1 gesetzt ist, wird die Source-Spur als ungültig markiert und der Befehl fährt wie oben beschrieben fort.

Indirekte Huffle Up/Dn/XOR-ANWEISUNG

Der indirekte Shuffle-Befehl weist einen Quelloperanden (srcl) auf, der die Abbildung von Quellenspuren auf Zielspuren steuert. Der indirekte Shuffle-Befehl kann die Form annehmen:

shuffle_<up/dn/xor> dest src0 src1 <optionales Flag>

wobei src0 N Doppelwörter speichert, src1 1 Doppelwort speichert und dest ▫N Doppelwörter speichert.

      für (int i = 0; i < SIMD_WIDTH) {
       Int8_t srcLane;
       Switch(SHUFFLE_TYPE) {
       Fall UP:
         srcLane = i - src1
       Fall DN:
         srcLane = i + src1
       Fall XOR:
        srcLane = i^ src1
       }

       wenn (execMask[i]) {
         Bool invalidLane = srcLane < 0|| srcLane > =
      SIMD_WIDTH | | !execMask[srcLane]; 

         IF (FLAG) {
         invalidLane| = Flag[srcLane];
         }

        wenn (invalidLane) {
          DST[i] = 0;
        }
         andernfalls {
          DST[i] = srcO[srcLane];
         }
        }
       }

Somit arbeitet der indirekte Shuffle-Befehl auf eine ähnliche Weise wie der oben beschriebene unmittelbare Shuffle-Befehl, aber die Abbildung von Quellspuren auf Zielspuren wird durch das Quellregister src1 anstatt durch den unmittelbaren gesteuert.

Kreuzspur-Min/Max Anweisung

Eine Kreuzspur-Minimum/Maximum-Anweisung kann für Gleit- und Ganzzahldatentypen unterstützt werden. Die Kreuzspur-Minium-Anweisung kann die Form Spur_min dest src0 annehmen und die Kreuzspur-Maximum-Anweisung kann die Form Spur_max dest src0 annehmen, wobei src0 N Doppelwörter speichert und dest 1 Doppelwort speichert.

Beispielsweise definiert folgende Codesequenz eine besondere Implementierung des Kreuzspurminimums:

      DST = src[0]; 

      für (int i = 1; i < SIMD_WIDTH) {
       wenn (execMask[i]) {
        DST = min(dst, src[i]);
       }
      }

Bei diesem Beispiel wird der Doppelwortwert in der Datenelementposition i des Quellregisters mit dem Datenelement in dem Zielregister verglichen und das Minimum der beiden Werte wird in das Zielregister kopiert. Die Spur über Greif Ende maximal Anweisung im Wesentlichen auf die gleiche Weise arbeitet, wobei der einzige Unterschied darin besteht, dass das Maximum des Daten Elements in Position i und der Ziel Wert ausgewählt wird.

Kreuzspur-Min/Max-Indexanweisung

Eine Kreuzspur-Minimum-Indexanweisung kann die Form Spur_min_index dest src0 annehmen und die Kreuzspur-Maximum-Indexanweisung kann die Form Spur_max_index dest src0 annehmen, wobei src0 N Doppelwörter speichert und dest 1 Doppelwort speichert.

Beispielsweise definiert folgende Codesequenz eine besondere Implementierung der Kreuzspur-Minimum-Indexanweisung:

      dst_Index = 0;
      tmp= src[0] 

      for (int i = 1; i < SIMD_WIDTH) {

       If (src[i] < tmp & & execMask[i])
       {
        tmp = src[i];
        dst_Index = i;
       }
      }

In diesem Beispiel wird der Zielindex von 0 auf eine SIMD-Breite inkrementiert, was das Zielregister überspannt. Falls das Ausführungsmaskenbit gesetzt ist, dann wird das Datenelement an Position i in dem Quellregister zu einem temporären Speicherort (tmp) kopiert und der Zielindex wird zu Datenelementposition i gesetzt.

Kreuzspursortiernetzwerkanweisung

Eine Kreuzspursortiernetzwerkanweisung kann alle N Eingabeelemente unter Verwendung eines N-breiten (stabilen) Sortiernetzwerks sortieren, entweder in aufsteigender Reihenfolge (sortnet_min) oder in absteigender Reihenfolge (sortnet_max). Die min/max Versionen des Befehls können die Formen sortnet_min dest src0 bzw. sortnet_max dest src0 annehmen. Bei einer Implementierung speichern src0 und dest N Doppelwörter. Die min/max Sortierung an den N Doppel Wörtern von src0 durchgeführt wird und die aufsteigenden geordneten Elemente (für min) oder absteigenden geordneten Elemente (für max) in ihren jeweiligen sortierten Reihen Folgen am weitesten gespeichert werden. Ein Beispiel für eine die Anweisung definierende Codesequenz ist: dst = application_N_wide_sorting_network_min/max(src0).

Kreuzspursortiernetzwerkindexanweisung

Eine Kreuzspursortiernetzwerkindexanweisung kann alle N Eingabeelemente unter Verwendung eines N-breiten (stabilen) Sortiernetzwerks sortieren, gibt aber den Permutationsindex entweder in aufsteigender Reihenfolge (sortnet_min) oder in absteigender Reihenfolge (sortnet_max) zurück. Die min/max Versionen des Befehls können die Formen sortnet_min_index dest src0 und sortnet_max_index dest src0 annehmen, wobei src0 und dest jeweils N Doppelwörter speichern. Ein Beispiel für eine die Anweisung definierende Codesequenz ist dst = application_N_wide_sorting_network_min/max_index(src0).

Ein Verfahren zum Ausführen eines beliebigen der obigen Befehle ist in 50 veranschaulicht. Das Verfahren kann auf den oben beschriebenen spezifischen Prozessorarchitekturen implementiert werden, ist aber nicht auf irgendeine spezielle Prozessor- oder Systemarchitektur beschränkt.

Bei 5001 werden Anweisungen eines primären Grafik-Threads auf Prozessorkernen ausgeführt. Dies kann zum Beispiel einen beliebigen der oben beschriebenen Kerne (z. B. Grafikkerne 3130) umfassen. Wenn eine Strahlverfolgungsarbeit innerhalb des primären Grafikthreads erreicht wird, bestimmt bei 5002, werden die Strahlverfolgungsanweisungen zu der Strahlverfolgungsausführungsschaltung abgeladen, die in der Form einer funktionalen Einheit (FU) vorliegen kann, wie oben mit Bezug auf 49 beschrieben, oder die sich in einem dedizierten Strahlverfolgungskern 3150 befinden kann, wie mit Bezug auf 31 beschrieben.

Bei 5003 werden die Strahlverfolgungsbefehle decodiert und aus dem Speicher abgerufen und bei 5005 werden die Befehle in ausführbare Operationen decodiert (z. B. in einer Ausführungsform, die einen Decodierer erfordert). Bei 5004 werden die Strahlverfolgungsbefehle geplant und zur Ausführung durch eine Strahlverfolgungsschaltungsanordnung versendet. Bei 5005 werden die Strahlverfolgungsbefehle durch die Strahlverfolgungsschaltungsanordnung ausgeführt. Die Anweisungen können zum Beispiel auf den oben beschriebenen FUs (z. B. Vektor-FU 4910, Strahlverfolgungs-FU 4912 usw.) und/oder den Grafikkernen 3130 oder Strahlverfolgungskernen 3150 versandt und ausgeführt werden.

Wenn die Ausführung für eine Strahlverfolgungsanweisung abgeschlossen ist, werden die Ergebnisse bei 5006 gespeichert (z. B. zurück in den Speicher 3198 gespeichert) und bei 5007 wird der primäre Grafikthread benachrichtigt. Bei 5008 werden die Strahlverfolgungsergebnisse innerhalb des Kontextes des primären Threads verarbeitet (z. B. aus dem Speicher gelesen und in Grafikrendergebnisse integriert).

Bei Ausführungsformen kann sich der Begriff „Engine“ oder „Modul“ oder „Logik“ auf eine anwendungsspezifische integrierte Schaltung (ASIC: Application Specific Integrated Circuit), eine elektronische Schaltung, einen Prozessor (gemeinsam genutzt, dediziert oder Gruppe) beziehen, Teil davon sein oder diese umfassen, und/oder Speicher (gemeinsam genutzt, dediziert oder Gruppe), die ein oder mehrere Software- oder Firmware Programme, eine kombinatorische Logik Schaltung und/oder andere geeignete Komponenten ausführen, die beschriebene Funktionalität bereitstellen. Bei Ausführungsformen kann eine Engine, ein Modul oder eine Logik in Firmware, Hardware, Software oder einer beliebigen Kombination von Firmware, Hardware und Software implementiert sein.

VORRICHTUNG UND VERFAHREN ZUR ASYNCHRONEN STRAHL VERFOLGUNG

Ausführungsformen der Erfindung umfassen eine Kombination einer Festfunktionsbeschleunigungsschaltungsanordnung und einer Universalverarbeitungsschaltungsanordnung zum Durchführen einer Strahlverfolgung. Beispielsweise können bestimmte Operationen in Bezug auf die Strahltraversierung einer Bounding Volume Hierarchy (BVH) und Kreuzungsprüfung durch die Festfunktionsbeschleunigungsschaltungsanordnung durchgeführt werden, während mehrere Ausführungsschaltungen verschiedene Formen von Strahlverfolgungs-Shadern (z. B. Beliebiger-Treffer-Shader, Kreuzungs-Shader, Fehltreffer-Shader usw.) ausführen. Eine Ausführungsform umfasst duale Speicherbänke mit hoher Bandbreite, die mehrere Einträge zum Speichern von Strahlen und entsprechende duale Stapel zum Speichern von BVH-Knoten umfassen. In dieser Ausführungsform wechselt die Traversierungsschaltungsanordnung zwischen den Doppelstrahlbänken und Stapeln, um einen Strahl bei jedem Taktzyklus zu verarbeiten. Außerdem umfasst eine Ausführungsform eine Prioritätsauswahlschaltungsanordnung/- logik, die zwischen internen Knoten, nichtinternen Knoten und Primitiven unterscheidet und diese Informationen verwendet, um die Verarbeitung der BVH-Knoten und der durch die BVH-Knoten begrenzten Primitive intelligent zu priorisieren.

Eine bestimmte Ausführungsform reduziert den Hochgeschwindigkeitsspeicher, der für die Traversierung benötigt wird, unter Verwendung eines kurzen Stapels, um eine begrenzte Anzahl von BVH-Knoten während Traversierungsoperationen zu speichern. Diese Ausführungsform umfasst eine Stapelverwaltungsschaltungsanordnung/- logik zum effizienten Push und Popen von Einträgen zu und von dem Kurzstapel, um sicherzustellen, dass die erforderlichen BVH-Knoten verfügbar sind. Außerdem werden Traversieroperationen verfolgt, indem Aktualisierungen an einer Tracking-Datenstruktur durchgeführt werden. Wenn die Traversierungsschaltungsanordnung/-logik pausiert wird, kann sie die Tracking-Datenstruktur dazu heranziehen, Traversierungsoperationen an derselben Stelle innerhalb des BVH zu beginnen, an der sie ausgeschaltet bleibt. und die Tracking-Daten, die in einer Datenstrukturverfolgung beibehalten werden, werden durchgeführt, so dass die Traversierungsschaltungsanordnung/-logik neu starten kann.

51 veranschaulicht eine Ausführungsform, die eine Shader-Ausführungsschaltungsanordnung 4000 zum Ausführen von Shader-Programmcode und Verarbeiten von assoziierten Strahlverfolgungsdaten 4902 (z. B. BVH-Knoten-Daten und Strahldaten) umfasst, eine Strahlverfolgungsbeschleunigungsschaltungsanordnung 5110 zum Durchführen von Traversier- und Kreuzungsoperationen und einen Speicher 3198 zum Speichern von Programmcode und assoziierten Daten, die durch die RT-Beschleunigungsschaltungsanordnung 5110 und die Shader-Ausführungsschaltungsanordnung 4000 verarbeitet werden.

In einer Ausführungsform weist die Shader-Ausführungsschaltungsanordnung 4000 mehrere Kerne/Ausführungseinheiten 4001 auf, die Shader-Programmcode ausführen, um verschiedene Formen von datenparallelen Operationen durchzuführen. In einer Ausführungsform können die Kerne/Ausführungseinheiten 4001 zum Beispiel einen einzelnen Befehl über mehrere Spuren ausführen, wobei jede Instanz des Befehls an Daten arbeitet, die in einer anderen Spur gespeichert sind. Bei einer SIMT-Implementierung ist zum Beispiel jede Instanz des Befehls mit einem anderen Thread assoziiert. Während der Ausführung speichert ein L1-Cache gewisse Strahlverfolgungsdaten für effizienten Zugriff (z. B. kürzlich oder häufig zugegriffene Daten).

Ein Satz von Primärstrahlen kann an den Scheduler 4007 gesendet werden, der Arbeiten an Shadern plant, die durch die Kerne/EUs 4001 ausgeführt werden. Die Kerne/EUs 4001 können Strahlverfolgungskerne 3150, Grafikkerne 3130, CPU-Kerne 3199 oder andere Arten von Schaltungen sein, die in der Lage sind, Shader-Programmcode auszuführen. Ein oder mehrere Primärstrahl-Shader 5101 verarbeiten die Primärstrahlen und erzeugen zusätzliche Arbeit, die durch die Strahlverfolgungsbeschleunigungsschaltungsanordnung 5110 und/oder die Kerne/EUs 4001 (die z. B. durch einen oder mehrere Kind-Shader auszuführen sind) durchzuführen sind. Neue Arbeiten, die durch den Primärstrahlen-Shader 5101 oder andere Shader erzeugt werden, die durch die Kerne/EUs 4001 ausgeführt werden, können an eine Sortierschaltungsanordnung 4008 verteilt werden, die Strahlen in Gruppen oder Bins sortiert, wie hier beschrieben (z. B. Gruppieren von Strahlen mit ähnlichen Charakteristiken). Der Scheduler 4007 plant dann die neue Arbeit an den Kernen/EUs 4001.

Andere Shader, die ausgeführt werden können, umfassen Beliebiger-Treffer-Shader 4514 und Nächster-Treffer-Shader 4507, die Trefferergebnisse verarbeiten, wie oben beschrieben (z. B. Identifizieren eines beliebigen Treffers bzw. des nächsten Treffers für einen gegebenen Strahl). Ein Miss-Shader 4506 verarbeitet Strahlenfehltreffer (z. B. wo ein Strahl den Knoten/die Primitive nicht schneidet). Wie erwähnt, können die verschiedenen Shader unter Verwendung einer Shader-Aufzeichnung referenziert werden, die einen oder mehrere Zeiger, herstellerspezifische Metadaten und globale Argumente aufweisen kann. In einer Ausführungsform werden Shader-Aufzeichnungen durch Shader-Aufzeichnungskennungen (SRI) identifiziert. In einer Ausführungsform ist jede ausführende Instanz eines Shaders mit einem Aufrufstapel 5203 assoziiert, der Argumente speichert, die zwischen einem Eltern-Shader und einem Kind-Shader weitergeleitet werden. Die Aufrufstapel 5121 können auch Referenzen auf Fortsetzungsfunktionen speichern, die ausgeführt werden, wenn ein Aufruf zurückkehrt.

Die Strahltraversierungsschaltungsanordnung 5102 durchläuft jeden Strahl durch Knoten eines BVH, wobei die Hierarchie des BVH (z. B. durch Elternknoten, Kind-Knoten und Blattknoten) herunterbearbeitet wird, um Knoten/Primitive zu identifizieren, die durch den Strahl durchlaufen werden. Die Ray-BVH-Kreuzungsschaltungsanordnung 5103 führt eine Kreuzungsprüfung von Strahlen durch, bestimmt Trefferpunkte auf Primitiven und erzeugt Ergebnisse als Reaktion auf die Treffer. Die Traversierungsschaltungsanordnung 5102 und die Kreuzungsschaltungsanordnung 5103 können Arbeit von dem einen oder den mehreren Aufrufstapeln 5121 abrufen. Innerhalb der Strahlverfolgungsbeschleunigungsschaltungsanordnung 5110 können Aufrufstapel 5121 und assoziierte Strahlverfolgungsdaten 4902 innerhalb eines lokalen Strahlverfolgungs-Caches (RTC: Local Ray Tracing Cache) 5107 oder einer anderen lokalen Speichereinrichtung für einen effizienten Zugriff durch die Traversierschaltungsanordnung 5102 und die Kreuzungsschaltungsanordnung 5103 gespeichert werden. Eine spezielle Ausführungsform, die unten beschrieben ist, umfasst Strahlenbänke mit hoher Bandbreite (siehe z. B. 52A).

Die Strahlverfolgungsbeschleunigungsschaltungsanordnung 5110 kann eine Variante der verschiedenen hier beschriebenen Traversierungs-/Kreuzungsschaltungen einschließlich der Strahl-BVH-Traversierungs-/Kreuzungsschaltung 4005, der Traversierungsschaltung 4502 und der Kreuzungsschaltung 4503 und der Strahlverfolgungskerne 3150 sein. Die Strahlverfolgungsbeschleunigungsschaltungsanordnung 5110 kann anstelle der Strahl-BVH-Traversierungs-/Kreuzungsschaltung 4005, der Traversierungsschaltung 4502 und der Kreuzungsschaltung 4503 und der Strahlverfolgungskerne 3150 oder einer beliebigen anderen Schaltungsanordnung/Logik zum Verarbeiten von BVH-STAPELN und/oder Durchführen einer Traversierung/Kreuzung verwendet werden. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit der Strahlen-BVH-Traversierungs-/Kreuzungsschaltung 4005, der Traversierungsschaltung 4502 und der Kreuzungsschaltung 4503 und den Strahlverfolgungskernen 3150, die hier beschrieben sind, auch eine entsprechende Kombination mit der Strahlverfolgungsbeschleunigungsschaltungsanordnung 5110, ist aber nicht darauf beschränkt.

Unter Bezugnahme auf 52A umfasst eine Ausführungsform der Strahltraversierungsschaltungsanordnung 5102 eine erste und eine zweite Strahlenspeicherbank 5201 bzw. 5202, wobei jede Bank mehrere Einträge zum Speichern entsprechender mehrerer eingehender Strahlen 5206, die aus dem Speicher geladen werden, umfasst. Entsprechende erste und zweite Stapel 5203 bzw. 5204 umfassen ausgewählte BVH-Knoten-Daten 5290-5291, die aus dem Speicher gelesen und lokal zur Verarbeitung gespeichert werden. Wie hier beschrieben, sind die Stapel 5203-5204 in einer Ausführungsform „kurze“ Stapel, die eine begrenzte Anzahl von Einträgen zum Speichern von BVH-Knoten-Daten umfassen (z. B. in einer Ausführungsform sechs Einträge). Obwohl getrennt von den Strahlenbänken 5201-5202 veranschaulicht, können die Stapel 5203-5204 auch innerhalb der entsprechenden Strahlenbänke 5201-5202 beibehalten werden. Alternativ dazu können die Stapel 5203-5204 in einem separaten lokalen Speicher oder Cache gespeichert sein.

Eine Ausführungsform der Traversierungsverarbeitungsschaltungsanordnung 5210 alterniert zwischen den zwei Bänken 5201-5202 und Stapeln 5203-5204, wenn der nächste Strahl und Knoten ausgewählt werden (z. B. auf eine Ping-Pong-Weise). Zum Beispiel kann die Traversierungsverarbeitungsschaltungsanordnung 5210 einen neuen Strahl/BVH-Knoten aus einer alternativen Strahlenbank/einem alternativen Strahlenstapel bei jedem Taktzyklus auswählen, wodurch ein hocheffizienter Betrieb sichergestellt wird. Es sei jedoch darauf hingewiesen, dass diese spezielle Anordnung nicht notwendig ist, um die der Erfindung zugrundeliegenden Prinzipien zu erfüllen.

In einer Ausführungsform gleicht ein Strahlenzuweiser 5205 den Eintritt von eingehenden Strahlen 5206 in die erste bzw. zweite Speicherbank 5201-5202 basierend auf aktuellen relativen Werten eines Satzes von Bankzuweisungszählern 5220 aus. In einer Ausführungsform halten die Bank-Zuordnungszähler 5220 eine Zählung der Anzahl von nicht durchlaufenen Strahlen in jeder der ersten und zweiten Speicherbank 5201-5202 aufrecht. Zum Beispiel kann ein erster Bank-Zuordnungszähler inkrementiert werden, wenn der Strahlenzuordner 5205 einen neuen Strahl zu der ersten Bank 5201 hinzufügt, und dekrementiert werden, wenn ein Strahl von der ersten Bank 5201 verarbeitet wird. Gleichermaßen kann der zweite Bank-Zuordnungszähler inkrementiert werden, wenn der Strahlenzuordner 5205 einen neuen Strahl zu der zweiten Bank 5201 hinzufügt, und dekrementiert werden, wenn ein Strahl von der zweiten Bank 5201 verarbeitet wird.

In einer Ausführungsform weist der Strahlzuordner 5205 den aktuellen Strahl einer Bank zu, die mit dem kleineren Zählerwert assoziiert ist. Falls die zwei Zähler gleich sind, kann der Strahlenzuweiser 5205 entweder eine Bank auswählen oder eine andere Bank auswählen als diejenige, die beim letzten Mal ausgewählt wurde, wenn die Zähler gleich wären. In einer Ausführungsform wird jeder Strahl in einem Eintrag einer der Bänke 5201-5202 gespeichert und jede Bank umfasst 32 Einträge zum Speichern von bis zu 32 Strahlen. Die der Erfindung zugrundeliegenden Prinzipien sind jedoch nicht auf diese Details beschränkt.

52B veranschaulicht vier Prozesse 5251-5254, die in einer Ausführungsform ausgeführt werden, um die Strahlenspeicherungsbänke 5201-5202 und Stapel 5203-5204 zu verwalten. In einer Ausführungsform sind die vier Prozesse 5251-5254 unterschiedliche Implementierungen oder Konfigurationen eines gemeinsamen Satzes von Programmcode (hier manchmal als „TraceRay“ bezeichnet). Der Anfangsprozess 5251 kann ausgeführt werden, um den Strahl 5261 zu lesen und eine neue Top-Down-Traversierung eines BVH ausgehend von dem Wurzelknoten durchzuführen. Die Alloc-Funktion modifiziert Steuerbits und startet entsprechende Leseanforderungen an den Strahlverfolgungsstapel. Um den neuen Eintrag zuzuweisen, setzt Alloc insbesondere das gültige (VLD) Bit und setzt das Räumbereitschafts(Evict_Rdy)-Bit zurück. In dem Bankeintrag für den Strahl werden das Datenpräsenz(DP)-Bit und das Dirty Bit zurückgesetzt. Das DP-Bit im entsprechenden Stapeleintrag wird gesetzt. Für das entsprechende Hitinfo wird das DP-Bit gesetzt und das Dirty Bit zurückgesetzt. Das DP-Bit und das SRI(Shader Record Identifier)-DP-Bit, die mit den Knotendaten assoziiert sind, werden zurückgesetzt.

Der Instanzprozess 5252 führt eine Traversierung innerhalb eines der Knoten des BVH (außer dem Wurzelknoten) durch und liest den Strahl und den zuvor festgeschriebenen Treffer 5262 aus. In einer Ausführungsform, wenn einer der Treffer-Shader einen Treffer zwischen dem Strahl und einem Primitiv identifiziert, dann wird der Festschreibungsprozess 5253 ausgeführt, um Ergebnisse festzuschreiben, den Strahl, den potentiellen Treffer und den Stapel 5263 zu lesen. Alternativ dazu wird der Fortsetzungsprozess 5254 ausgeführt, um das Durchlaufen des Strahls, das Lesen des Strahls, des festgeschriebenen Treffers und des Stapels 5264 fortzusetzen.

Unter verschiedenen Umständen muss die Traversierungsschaltungsanordnung 5002 Traversierungsoperationen pausieren und den aktuellen Strahl und assoziierte BVH-Knoten speichern, wie etwa wenn ein Shader benötigt wird, um eine Sequenz von Operationen durchzuführen. Falls zum Beispiel ein nichtopakes Objekt getroffen wird oder eine prozedurale Textur, speichert die Traversierungsschaltungsanordnung 5002 den Stapel 5203-5204 im Speicher und führt den erforderlichen Shader aus. Sobald der Shader die Verarbeitung des Treffers (oder anderer Daten) abgeschlossen hat, stellt die Traversierungsschaltungsanordnung 5002 den Zustand der Strahlenbänke 5201-5202 und Stapel 5203-5204 aus dem Speicher wieder her.

In einer Ausführungsform überwacht ein Durchlauf-/Stapelverfolger 5248 kontinuierlich Durchlauf- und Stapeloperationen und speichert Neustartdaten in einem Verfolgungsarray 5249. Falls zum Beispiel die Traversierungsschaltungsanordnung 5002 bereits die Knoten N, N0, N1, N2 und N00 durchlaufen hat und Ergebnisse erzeugt hat, dann aktualisiert die Durchlauf-/Stapelverfolgungseinrichtung 5248 das Verfolgungsarray, um anzugeben, dass das Durchlaufen dieser Knoten abgeschlossen ist, und/oder um den nächsten zu verarbeitenden Knoten aus dem Stapel anzugeben. Wenn die Traversierungsschaltungsanordnung 5002 neu gestartet wird, liest sie die Neustartdaten aus dem Tracking-Array 5249, so dass sie das Durchlaufen in der korrekten Phase neu starten kann, ohne einen der BVH-Knoten (und Makulaturzyklen) neu zu durchlaufen. Die in dem Verfolgungsarray 5249 gespeicherten Neustartdaten werden manchmal als der „Neustartpfad“ oder „RST“ bezeichnet.

Wie in 52B angegeben, verwalten die verschiedenen TraceRay Prozesse 5251-5254 die Zuweisung in die und aus den Strahlspeicherungsbänken 5201-5202 über eine oder mehrere Funktionen. Wie für den anfänglichen Prozess 5251 veranschaulicht, setzt eine Alloc-Funktion das gültige Bit (VLD) in einem Speicherbankeintrag (der angibt, dass der Eintrag nun einen gültigen Strahl enthält) und setzt das Räumungsbereitschaftsflag zurück (das angibt, dass die Strahldaten nicht geräumt werden sollten). Die Ray-Funktion speichert den Strahl in dem ausgewählten Eintrag und setzt das Datenpräsenz(DP)-Bit (das angibt, dass Strahldaten in dem Eintrag gespeichert sind) und das Dirty Bit (das angibt, dass die Daten nicht modifiziert wurden) zurück. Beim Lesen des Strahls aus der Speicherbank setzt die Stapelfunktion das DP-Bit und ruft den relevanten BVH-Knoten aus dem Stapel ab (z. B. der Wurzelknoten im Fall des Anfangsprozesses 5251 und ein anderer Knoten im Fall des Instanzprozesses 5252). Die Funktion Hitinfo setzt das Dirty Bit und das DP-Bit für die Anfangsfunktion 5251 oder für alle anderen Funktionen zurück. In einer Ausführungsform produziert Hitinfo Daten, die einen Strahlenauftreffpunkt widerspiegeln. Die Knotenfunktion setzt das DP-Bit und den SRI (Shader Record Identifier) DP zurück, der der DP für Shader Record Identifier ist. Eine Ausführungsform führt eine Kernstartzeiger(KSP)-suche durch, um sicherzustellen, dass KSP ungleich null ist. Falls dies der Fall ist, wird eine andere Handhabung für nicht opake Quads implementiert.

In einer Ausführungsform wird, sobald ein Strahleneintrag in einer der Speicherbänke 5201-5202 zugewiesen wurde, ein Abrufen durchgeführt, um die Knotendaten (und potentiell andere Daten) aus dem Stapel, der mit dem Strahl assoziiert ist, abzurufen. In einer Ausführungsform wird ein Stapel für jeden Strahl aufrechterhalten, der den Arbeitssatz von Daten für den aktuellen Knoten umfasst, durch den der Strahl durchlaufen wird.

Wenn sich auf die nächste Ebene in dem BVH bewegt (z. B. wenn bestimmt wird, dass der Strahl einen Elternknoten schneidet), werden die Kind-Knoten sortiert und auf den Stapel 5203-5204 geschoben. Die Kind-Knoten werden sequentiell vom Stapel abgerufen und einzeln verarbeitet, um Kind-Knoten zu identifizieren, die der Strahl durchläuft (Traversieren „Treffer“). In einer Ausführungsform wird der Stapel immer dann in einem Speicher oder einem lokalen Cache/Speicher gespeichert, wenn es einen Handoff zwischen der RT-Beschleunigungsschaltungsanordnung 5110 und den Shadern 4504, 4506, 4507, 5101, 5105 gibt.

Wenn ein Blattknoten, der ein Viereck oder Dreieck (oder einen anderen Primitivtyp) umfasst, durch die Traversierungsschaltungsanordnung 5102 identifiziert wird, gibt er diese Informationen an die Kreuzungsschaltungsanordnung 5103 weiter, die einen Kreuzungstest an dem Viereck bzw. Dreieck durchführt. Falls das Primitiv kein Viereck oder Dreieck ist, dann beendet die Traversierungsschaltungsanordnung bei einer Implementierung das Durchlaufen und gibt die Steuerung an den nächsten Treffer-Shader 4507 (falls ein Treffer detektiert wird) oder den Fehltreffer-Shader 4506 (falls kein Treffer detektiert wird) zurück. Bei einer Implementierung, bei der die Kreuzungsschaltungsanordnung 5103 dazu ausgelegt ist, Kreuzungen für eine Vielzahl von Primitiven zusätzlich zu Vierecken und Dreiecken (z. B. Linien, Bögen, Kreise usw.) durchzuführen, dann wird die Traversierschaltungsanordnung 5102 Blattknoten für diese Primitive an die Kreuzungsschaltungsanordnung 5103 weiterleiten.

In einer Ausführungsform wird, wenn eine Hardware- oder Softwarekomponente eine Leseanforderung an den Speicher 3198 oder den Cache erzeugt, ein 16-Bit-Tag verwendet, um Informationen über den Datentyp und den Anforderer bereitzustellen. Zum Beispiel kann ein Zweibitcode spezifizieren, ob die Anforderung für einen Strahl, Stapeldaten, Trefferdaten, Knotendaten von dem BVH oder einen beliebigen anderen Datentyp ist. Wenn der Strahl, Stapel und Hitinfo aus dem Speicher zurückgegeben wurden, wird der Strahl durch einen oder mehrere BVH-Knoten durchlaufen und Kreuzungstests wie oben beschrieben durchgeführt.

Ein oder mehrere Stapel 5203-5204 und Strahlen 5206 werden in unterschiedlichen Verarbeitungsstufen aus dem Speicher geladen. Zum Beispiel kann der anfängliche Prozess 5251 und/oder der Instanzprozess 5252 erfordern, dass ein neuer BVH zum Durchlaufen geladen wird. Unter diesen Umständen kann der Stapel 5203-5204 auf den oberen Knoten (oder „Wurzel“-Knoten) des BVH initialisiert werden. Für eine Strahlfortsetzung 5254 innerhalb eines BVH kann der Stapel 5203-5204 aus dem Speicher geladen und erweitert werden. Sobald der Stapel 5203-5204 vorbereitet wurde, werden Knotendaten aus dem Stapel abgerufen (eine Operation, die im Folgenden manchmal als Proc_Node_Abruf bezeichnet wird).

In einer Ausführungsform werden Knotendaten abgerufen, indem parallele Anforderungen für zwei nicht-interne (NI) Knoten und zwei interne Knoten gestartet werden. 53 veranschaulicht eine solche Ausführungsform, bei der NI-Knoten-Prioritätsauswahllogik (PRISEL) 5311 duale NI-Knoten anfordert: einen ersten NI-Knoten 5301 von Bank 0 und einen zweiten NI-Knoten 5302 von Bank 1. Gleichzeitig fordert die interne Knoten-PRISEL-Logik 5312 duale interne Knoten an: einen ersten Knoten 5303 von Bank 0 und einen zweiten Knoten 5304 von Bank 1.

In einer Ausführungsform priorisiert die NI-Knoten-Prioritätdauswahllogik (PRISEL) 5311 den ersten NI-Knoten 5301 oder den zweiten NI-Knoten 5302, wobei das priorisierte Ergebnis in dem Strahlverfolgungs-Cache (RTC) gespeichert wird. Gleichermaßen fordert die interne Knoten-PRISEL-Logik 5312 duale interne Knoten an und wählt ein priorisiertes Ergebnis aus einem ersten internen Knoten 5303 und einem zweiten internen Knoten 5304 aus.

Jede Instanz der Prioritätsauswahllogik 5311-5312 priorisiert einen der nicht-internen BVH-Knoten 5301-5302 und einen der internen BVH-Knoten 5303-5304 nach Möglichkeit aus einer anderen Bank. In einer Ausführungsform wird nur eine Anforderung aus jeder Bank ausgewählt (z. B. eine der Anforderungen 5302 und 5304 und eine der Anforderungen 5301 und 5303). Das Starten dieser Anforderungen kann auch das Stapeldatenpräsenz(DP)-Bit zurücksetzen, wie angegeben, so dass dieser Eintrag als Reaktion auf eine Knotenabrufoperation nicht abgerufen wird. In einer Ausführungsform wird für die Instanz-Abrufoperation das Daten-Präsenz(DP)-Bit des Strahls zurückgesetzt, wenn die Instanz-Anforderung gesendet wird, und schließlich gesetzt, wenn der Strahl nach dem Knotenabruf transformiert wird.

In einer Ausführungsform wird Node_info beim Start von Lesevorgängen geschrieben und die Adresse/Tag wird wie folgt für die Leseanfragen berechnet:

i. RTT_rtc_rd_addr[47:6] = rt_ray.rt_ray_ctrl.root_node_ptr[47: 6] + curr_stack.child_offset; (Anmerkung: Der Kind-Offset auf dem Knoten ist immer gegenüber aktuellem BVH-Wurzelknoten)
ii. RTT_rtc_rd_Tag[6:0] = {RTT_INST, rtt_alloc_entry[5:0]};
iii. node.node_info = curr_stack.node_info.

In einer Ausführungsform werden die zurückgegebenen Knotendaten das DP-Bit für den Knoten und den Stapel setzen.

Anhand des gelesenen Tags können folgende Fälle unterschieden werden:

A. Interner Knoten: Dies schreibt in den Knoten
B. Instanz: Dies wird den rt_ray.rt_ray_ctrl für BVH (1) der nächsten Ebene aktualisieren und die Knotenstruktur schreiben.
1. i. root_node_ptr = node_return.StartNodePtr
2. ii. hitgrp_srbase_ptr = rt_ray_ctrl.hitgrp_srbase_ptr + rt_ray_ctrl.srstride*node_return.instancecontributiontohitgrpindex
3. iii. hitgrp_sr_stride = rt_ray_ctrl.srstride* rt_ray_ctrl.shade_indx_mult
4. iv. inst_leaf_ptr = rt_ray.rt_ray_ctrl.root_node_ptr + stack.current_node.child_Offset nur Logische Ansicht, Greifen und Speichern der Knotenabrufadresse während der Instanzknotenabrufanforderung selbst→
5. v. {miss_sr_ptr, shader_indx_mult, mask} = {rt_ray[0].rt_ray_ctrl. miss_sr_ptr, rt_ray[0]. rt_ray_ctrl. shader_indx_mult, rt_ray[0].rt_ray_ctrl.mask} □ Preserve BVH[0]
6. vi. flag[0] = rt_ray[0].rt_ray_ctrl.flag[0]| (~ rt_ray[0].rt_ray_ctrl.flag[1] & Node_Return.flag[2]); entweder opak über Strahl oder über Instanzflag beibehalten (nur wenn Strahlflag nicht zwangsweise nicht-opak ist)
7. vii. flag[1] = (rt_ray[0].rt_ray_ctrl.flag[1])| (~ rt_ray[0].rt_ray_ctrl.flag[0] & Node_Return.flag[3]); entweder Nicht-Opak über Strahl oder über Instanz-Flag beibehalten (nur wenn Strahl-Flag nicht zwangsweise opak ist)
8. viii. flag[3:2] = rt_ray[0].rt_ray_ctrl.flag[3:2]; (ERSTEN TREFFER akzeptieren und Suche beenden oder Nächster-Treffer-Shader überspringen) BVH beibehalten [0]→
9. ix. flag[5:4] = Node_Return.flag[0]? 2 'd0:
  - rt_ray[0].rt_ray_ctrl.flag[5:4]; Dreiecksaussonderung wird über Instanz deaktiviert.→
10. x. flag[8:6] = rt_ray[0].rt_ray_ctrl.flag[8:6]; (Deaktivierung von Kreuzungs-Shader, Voll-Opak oder Voll-Nicht-Opak) BVH[0] beibehalten→
11. xi. node.node_ctrl = für Instanz nicht erforderlich
12. xii. node.node_data = { '0, node_rtn.obj2world_p, World2obj_vzyx};
C. Quad: Dies aktualisiert den Knoten wie folgt:
1. i. node.node_ctrl = {node_rtn.leafDesc.last, node_rtn.leafDesc.PrimIndex1Delta[15: 0], node_rtn.leafDesc.PrimIndexO[31: 0], node_rtn.shader_indx};
2. ii. node.node_data = { ‚0, Quad_mode, J[2:0], V[3:0]}; Quad_mode = node_rtn.leafDesc.PrimIndexlDelta[15:0]!=‘ 0;→

Basierend auf dem Strahlen-Flag, Instanz-Flag und dem Geometrie-Flag gibt die in 55A gezeigte Opak-/Nichtopak-Handhabungstabelle das resultierende Flag an, das verwendet werden soll, wenn die Knotendaten abgerufen werden (opak oder nicht opak). Wie in der Tabelle angegeben, haben Strahlflags immer Vorrang. Zusätzlich schließen sich manche der Zustände gegenseitig aus. In einer Ausführungsform werden diese in Hardware mit der Priorität exklusiver Bits behandelt. Bei einer Implementierung wird, falls cull_opaque und force_opaque beide eingestellt sind, die zugehörige Geometrie automatisch ausgesondert.

opaque = rt_ray.rt_ray_ctrl.flag[0]| quad.flag[0]; (Anmerkung, dass der pro BVH-Level gespeicherte Strahl bereits die Instanz-Flags berücksichtigt)
nopaque = rt_ray.rt_ray_ctrl.flag[1]|~ quad.flag[0];

55B ist eine Tabelle, die eine Strahlflag-Handhabung und Ausnahmen gemäß einer Ausführungsform zeigt. Hier basiert die Entscheidung, auszusondern auf einer Kombination des Strahlen-Flags, des Instanz-Flags und des Geometrie-Flags.

cull_opaque = rt_ray.rt_ray_ctrl.flag[6] & (rt_ray.rt_ray_ctrl.flag[0]| quad.flag[0]);
cull_nopaque = rt_ray.rt_ray_ctrl.flag[7] & (rt_ray.rt_ray_ctrl.flag[1]|~ quad.flag[0]);
cull = cull_opaquel cull_nopaque;

Eine maskenbasierte Aussonderung kann in einer Ausführungsform wie folgt implementiert werden:

mask_killl = ~|(rtc_rtt_rd_rtn.mask & rtc_rtt_rd_rtn.data.mask);

55C ist eine Tabelle, die abschließendes Kultivieren gemäß einer Ausführungsform zeigt. Das Strahl-Flag (cull_opaque und force_opaque) oder (cull_non_opaque und force_non_opaque) schließen sich gegenseitig aus. In dieser Gleichung berücksichtigt das Ray-Flag jedoch auch das Instanz-Flag, das opak/nicht-opak setzen kann. Es kann nur Geometrie ausgesondert werden, während Fall und Geometrie maskiert werden können.

Wie in 56 veranschaulicht, wird in einer Ausführungsform basierend auf der Auswertung der oben beschriebenen Cull und mask_kill-Einstellungen frühzeitig bei 5601 oder 5602 bestimmt und das Ergebnis entweder bei 5603 an die Knotenspeicherung und/oder bei 5604 an den Stapel gesendet.

Sobald die Knotendaten bereit sind, können Box/Kreuzungstests durchgeführt werden. Dies wird in einer Ausführungsform durch einen Prozess erreicht, der hier als Ray_Test_Proc bezeichnet wird, dem zwei konkurrente Prozesse zugrunde liegen, die laufen, einen zum Füllen des Vierecks/der Instanz (QI) und einen anderen zum Durchführen des Kästchens/Kreuzungstests. Bei einer in 57 veranschaulichten Implementierung startet Ray_Test_Proc zwei parallele Instanzen einer Prioritätsauswahllogik (PRISEL) 5701-5702: eine Viereck/Instanz-PRISEL 5701 zum Anfordern und Auswählen zwischen einer Viereck/Instanz 5711 von Bank 0 und einer zweiten Viereck/Instanz 5712 von Bank 1, und einer internen Knoten-PRISEL 5702 zum Anfordern und Auswählen zwischen einem internen Knoten aus der Bank 0 5713 und einem internen Knoten aus der Bank 1 5714.

In einer Ausführungsform priorisiert die Viereck-/Instanzprioritätsauswahllogik 5701 den ersten QI-Knoten 5711 oder den zweiten QI-Knoten 5712, wobei das priorisierte Ergebnis in der Strahlverfolgungswarteschlange (RTQ) zur weiteren Verarbeitung (z. B. Kreuzungsprüfung) gespeichert wird. Gleichermaßen priorisiert die interne Knoten-PRISEL-Logik 5702 einen der internen BVH-Knoten 5713-5714, an dem ein RTT-Box-Test (RTT: Ray Tracing Traversing) durchgeführt wird. In einer Ausführungsform wird nur eine Anforderung aus jeder Bank ausgewählt (z. B. eine der Anforderungen 5711 und 5712 und eine der Anforderungen 5713 und 5714). Das Starten dieser Anforderungen kann auch das Stapeldatenpräsenz(DP)-Bit zurücksetzen, wie angegeben, so dass dieser Eintrag als Reaktion auf eine Knotenabrufoperation nicht abgerufen wird. In einer Ausführungsform wird für die Instanz-Abrufoperation das Daten-Präsenz(DP)-Bit des Strahls zurückgesetzt, wenn die Instanz-Anforderung gesendet wird, und schließlich gesetzt, wenn der Strahl nach dem Knoten-Abruf transformiert wird.

Als Teil dieses Prozesses wird für jede vier Fach Test Dispatch, bei der Knotentyp nicht opak ist, die Shader Record Identifier Null Suche als ein Bindless Thread Dispatch (BTD) basierend auf der folgenden Shader Record Identifier Lookup adresse gesendet:

\begin{array}{l} sri_null_lookup_ptr [47 : 3] = 2 * (Ray .hitGroup SRBasePtr + \\ Node . leafDesc . ShaderIndex * ray . SrStride) + 1; \end{array}

sri_null_lookup_tag [7 : 0] = {1' d 0, RTT_INST, rtt_alloc_entry [5 : 0]};

In einer Ausführungsform ist ein Viereck-/Instanz-(QI)-Entkopplungs-FIFO enthalten, um volle Bedingungen des zeitlichen Stapel-FIFO aufzulösen und synchrone Aktualisierungen des Hitinfo/Strahls mit einem Push in das Stapel-FIFO zu implementieren (siehe z. B. Stapel-FIFO 6001 in 60). Dies geschieht so, dass das Strahl/hitinfo in nachfolgenden Prozessen ein garantiertes Datenpräsentationsbit (DP) gesetzt hat. Es wird angemerkt, dass Strahl/Hitinfo eine feste hohe Priorität zugewiesen werden kann, wenn es mit Speicherschreibungen kollidiert.

Die Rückkehr von RTQ kann zu einer Instanz (z. B. einer Instanztransformation) oder einem Viereck (d. h. Traversierungs-/Kreuzungstestergebnisse) auf zwei getrennten Schnittstellen führen. Im Folgenden werden in einer Ausführungsform die zwei Rückgabe-FIFOs zum Verarbeiten von Ergebnissen verwendet:

a. Instanzrückgabe-FIFO: Update rt_ray.rt_ray_data = rtq_rt_ray_data; ray_dirty=1;
b. Quad Return FIFO:
1. i. Falls das Viereck nicht opak ist und (Tfar < Prev_Tfar), Prüfen von SRI_NULL_DP, um das von Viereck/Instanz (QI) entkoppelte FIFO zu entnehmen (daraus zu lesen).→ Es ist zu beachten, dass in einer Ausführungsform das Hitinfo-Schreiben aus dem Strahlverfolgungswarteschlangen(RTQ)-FIFO eine höhere Priorität gegenüber MemHitInfo aufweist.
  1. 1. Falls (KSP_NULL = 1), wird das nichtopake Viereck so behandelt, als ob es opak wäre, und wird Tfar aktualisiert.→
  2. 2. Wenn (KSP_NULL!= 1)→
    - ♦ Schreiben der potentiellen Hitinfo in den Speicher mit dem auf 1 gesetzten gültigen Bit.
    - ♦ Lesen von T, U, V, Blatttyp, PrimLeafIndex und Vorderfläche aus der RTQ.
    - ♦ Lesen PrimIndexDelta, PrimleafPtr aus NodeData. Aktualisieren instanceLeafPtr aus Strahldaten.
    - ♦ hitGroupRecPtr, wie oben berechnet
2. ii. Wenn das Viereck nicht opak ist und (Tfar < P_rev_T_far)→
  - ♦ Aktualisieren des Committed Hitinfo mit Valid = 1.
  - ♦ Lesen von T,U,V, Blatttyp, PrimLeafIndex, Vorderfläche aus der RTQ.
  - ♦ Lesen PrimIndexDelta, PrimleafPtr aus NodeData.
  - ♦ Aktualisierung instanceLeafPtr von rt_ray.rt_ray_ctrl
  - ♦ hitGroupRecPtr, wie für oben berechnet,

In einer Ausführungsform kann die Rückkehr von dem RTT-Boxschnitttest (RTT: Ray Tracing Traversing) zur weiteren Verarbeitung in den Stapel 0/1 (5203/5204) FIFO 6001 geschoben werden.

58 und 59A-B veranschaulichen ein Beispiel für BVH-Strahlenverarbeitung unter Verwendung eines „kurzen“ Stapels (z. B. wie etwa Stapel 5203 oder 5204, die eine begrenzte Anzahl lokaler Stapeleinträge aufweisen). Ein kurzer Stapel wird verwendet, um eine Hochgeschwindigkeitsspeicherung in Kombination mit intelligenten Knotenverwaltungstechniken zu sparen, um eine hocheffiziente Sequenz von Traversieroperationen bereitzustellen. Bei dem veranschaulichten Beispiel weist der kurze Stapel 5203 Einträge für sechs BVH-Knoten auf. Die der Erfindung zugrundeliegenden Prinzipien können jedoch mit unterschiedlich großen kurzen Stapeln realisiert werden.

Die Operationen 5949-5972 schieben und holen Stapeleinträge während des BVH-Traversierens. In einer Ausführungsform werden die Operationen 5949-5972 an dem Stapel 5203 durch eine Stapelverarbeitungsschaltungsanordnung 5120 (siehe 51) durchgeführt. Eine spezifische Durchlaufsequenz ist beginnend mit dem Wurzel-BVH-Knoten N 5900 auf BVH-Ebene 0 gezeigt.

Bei 5949 wird der Stapel 5203 mit dem Knoten N initialisiert, der dann aus dem Stapel entnommen und verarbeitet wird, was zu Treffern H0-H2 führt, die Kind-Knoten NO-N2 5901-5903 auf der Ebene 1 des BVH umfassen (d. h. „Treffer“ bedeutet, dass der Strahl die drei Kind-Knoten NO-N2 5901-5903 durchläuft). Die drei Kind-Knoten-Treffer 5901-5902 werden basierend auf der Trefferdistanz sortiert und in der sortierten Reihenfolge auf den Stapel 5203 geschoben (Operation 5950). Dementsprechend werden in dieser Ausführungsform, wann immer ein neuer Satz von Kind-Knoten evaluiert wird, diese basierend auf der Trefferdistanz sortiert und in der sortierten Reihenfolge (d. h. mit den näher gelegenen Kind-Knoten oben auf dem Stapel) in den Stapel 5203 geschrieben.

Der erste Kind-Knoten N0 5901 (d. h. der nächstliegende Kind-Knoten) wird aus dem Stapel 5203 entnommen und verarbeitet, was zu drei weiteren Kind-Knoten-Treffern N00-N02 5911-5913 auf der Ebene 2 des BVH führt (die „Ebene“ wird manchmal als die „Tiefe“ der BVH-Knoten bezeichnet), die sortiert und zu dem Stapel 5203 geschoben werden (Operation 5951).

Der Kind-Knoten N00 5911 wird aus dem Stapel entnommen und verarbeitet, was zu einem einzelnen Treffer führt, der einen einzelnen Kind-Knoten N000 5920 auf Ebene 3 des BVH umfasst (Operation 5952). Dieser Knoten wird abgerufen und verarbeitet, was zu sechs Treffern N0000-N0005 5931-5936 auf Ebene 4 führt, die sortiert und zu dem Stapel 5203 geschoben werden (Operation 5953). Um Platz innerhalb des kurzen Stapels 5203 zu machen, werden die Knoten N1, N2, N02, N01 entfernt, wie angegeben (d. h. um den kurzen Stapel auf sechs Einträge zu beschränken). Der erste sortierte Knoten N0000 5931 wird abgerufen und verarbeitet, wodurch drei Treffer N00000-N00002 5931-5933 auf der Ebene 5 des BVH erzeugt werden (Operation 5954). Die Anmerkung N0005 wird entfernt, um Platz auf dem kurzen Stapel 5203 für die neuen Knoten zu schaffen.

In einer Ausführungsform wird jedes Mal, wenn ein Knoten aus dem kurzen Stapel 5203 entfernt wird, in den Speicher zurückgespeichert.

Er wird dann zu einer späteren Zeit (z. B., wenn es Zeit ist, den Knoten gemäß der Traversieroperation zu verarbeiten) in den kurzen Stapel 5203 neu geladen.

Die Verarbeitung fährt in 59A fort, in der die Knoten N00001 und N00002 auf der Ebene 5 des BVH abgerufen und verarbeitet werden (Operationen 5955-5956). Die Knoten N0001, N0002, N0003 und N0004 auf Ebene 4 werden dann abgerufen und verarbeitet (Operationen 5957-5960), was zu einem leeren kurzen Stapel 5203 führt.

Somit führt eine Pop-Operation zum Abrufen des Wurzel-BVH-Knotens, Knoten N, gemäß dem Neustartpfad (RST) (Operation 5961). Die drei Kind-Treffer N0, N1, N2 aus Ebene 1 werden wieder sortiert und in den kurzen Stapel geschoben (Operation 5962). Der Knoten N0 wird dann abgerufen und verarbeitet, gefolgt von den Knoten N00, N000 und N0005 (Operationen 5963-5965). Knoten N01 wird abgerufen und verarbeitet (Operation 5966), gefolgt von Knoten N02, Knoten N2 und Knoten N1 (Operationen 5967-5970), was wiederum zu einem leeren kurzen Stapel führt. Folglich wird der Knoten N11 der nächsten Ebene 2 von dem kurzen Stapel abgerufen und verarbeitet, wodurch der Durchlauf abgeschlossen wird (d. h. weil der Knoten N11 keinen Treffer zur Folge hat).

Wie erwähnt, aktualisiert eine Ausführungsform eines Durchlaufverfolgers 5248 das Verfolgungsfeld 5249, das den Kind-Knoten/Unterbaum in jeder Ebene der BVH-Hierarchie identifiziert, die gegenwärtig durchlaufen wird. Bei einer Implementierung ist die Länge des Verfolgungsarrays 5249 gleich der Tiefe der BVH (6 in dem veranschaulichten Beispiel) und jeder Eintrag in dem Verfolgungsarray 5249 weist einen Indexwert auf, der den Kind-Unterbaum identifiziert, der gegenwärtig durchlaufen wird. Bei einer spezifischen Implementierung weist jeder Eintrag in dem Tracking-Array 5249 für eine N-breite BVH (d. h., wo jeder interne Knoten Auf n Kind-Knoten verweist) einen Log2(N)-Bit-Wert auf, um die Kind-Knoten/Unterbäume zu identifizieren. In einer Ausführungsform wurden Kind-Knoten/Unterbäume, denen ein Index zugewiesen ist, der kleiner als der aktuelle Kind-Index ist, vollständig durchlaufen und werden daher im Falle eines Neustarts nicht revidiert. In einer Ausführungsform wird, wenn das zuletzt geschnittene Kind durchlaufen wird, der Kindindex auf den Maximalwert gesetzt, um anzugeben, dass es keine Einträge mehr auf dem Stapel gibt.

Der kurze Durchlaufstapel 5203 kann die obersten wenigen Einträge des Stapels in einem kreisförmigen Array speichern. Bei einer Implementierung weist jeder Stapeleintrag in dem Kurzdurchlaufstapel 5203 einen Versatz zu einem Knoten, sonstige Informationen, wie etwa den Knotentyp (intern, Primitiv, Instanz usw.) sowie ein Bit, das angibt, ob dieses Kind der letzte (am weitesten) geschnittene Kindknoten in einem Elternknoten ist, auf. Diese speziellen Details sind jedoch nicht erforderlich, um die der Erfindung zugrundeliegenden Prinzipien zu erfüllen.

60 veranschaulicht eine Ausführungsform der Stapelverarbeitungsschaltungsanordnung/-logik 5120 zum Durchführen von Stapelverwaltungs- und Traversierungsoperationen, wie oben beschrieben. Ein Stapel-FIFO 6001 wird mit beliebigen untergeordneten BVH-Knoten 6000 geladen, die eine Verarbeitung erfordern. Wenn zum Beispiel ein Box-Test oder Viereck-Test durch die Traversierungsverarbeitungsschaltungsanordnung 5210 abgeschlossen ist, werden die Ergebnisse in das STAPELFIFO 6001 geschoben und zum Aktualisieren des Stapels 5203 verwendet. Dies kann zum Beispiel Aktualisierungen an dem Trefferinfo, wie etwa dem Satz von Kind-Knoten 6000, die mit einem bestimmten Treffer assoziiert sind, umfassen.

Die Stapelverarbeitungsschaltungsanordnung/-logik 6003 liest Einträge aus dem Stapel 5203 mit Daten, die zum Verarbeiten jedes Eintrags erforderlich sind, einschließlich einer Angabe darüber, ob der BVH-Knoten ein interner Knoten oder ein Blattknoten ist, und assoziierten Indexdaten. Falls der Knoten ein Blattknoten/Viereck ist, dann können die Daten Viereck-Deskriptoren und Indizes sowie Shader-Index-Daten umfassen. Die Stapelverarbeitungsschaltungsanordnung/-logik 6003 führt dann die hier beschriebenen Stapelverarbeitungsoperationen durch, wie etwa Identifizieren neuer Knoten, die mit einem Treffer assoziiert sind, und Sortieren der Knoten basierend auf der Trefferentfernung. Obwohl dies als eine separate Entität veranschaulicht ist, kann die Stapelverarbeitungsschaltungsanordnung/Logik 6003 innerhalb der Traversierungsschaltungsanordnung 5102 integriert sein.

Wie angegeben, erzeugt die Stapelverarbeitungsschaltungsanordnung/Logik 6003 Stapelaktualisierungen 6011, wenn sie die Verarbeitung jedes BVH-Knotens aus dem Stapel 5203 abschließt. Nach dem Lesen eines Eintrags aus dem Stapel 5203 kann er zum Beispiel die verschiedenen Steuerbits aktualisieren, wie etwa das Datenpräsenz(DP)-Bit und das gültige (VLD) Bit. 60 veranschaulicht, dass die Räumbereitschafts- und Datenpräsenzbits 6010 gesetzt sind. Eine entsprechende Stapelaktualisierung 6011 kann auch an den Stapel 5203 gesendet werden (was z. B. ermöglicht, dass alte Einträge entfernt werden, um Platz für neue Kind-Knoten zu schaffen).

Stapelaktualisierungen können über eine Arbitrierungsschaltungsanordnung 6012 gesteuert werden, die zwischen Aktualisieren des Stapels 5203 mit den aktuellen Verarbeitungsaktualisierungen 6011, Füllen des Stapels 5203 aus dem Speicher mit einem oder mehreren neuen BVH-Kind-Knoten (Mem Fill) und Durchführen einer anfänglichen Zuweisung zu dem Stapel aus dem Speicher (z. B. beginnend mit dem Wurzelknoten und einem oder mehreren Kind-Knoten) auswählt.

In einer Ausführungsform können, wenn ein Viereck/Instanz/interner Knoten auf dem Stapel verarbeitet wird, eine oder mehrere der folgenden Operationen durchgeführt werden:

i. Entfernen des Stapeleintrags aufgrund mehrerer Bedingungen, wie etwa Herunterbewegen der Instanz für einen neuen BVH, Verarbeiten eines Trefferprozedurals, eines beliebigen Treffer-Shaders usw.
ii. Aufheben der Zuordnung des Ray-Eintrags, wenn der Stapel aufgrund eines Trefferverfahrens und/oder eines Treffer-Shaders entfernt wird.
iii. Aufheben der Zuordnung des Cache-Eintrags, wenn dieser Stapel aufgrund eines Trefferprozedurals und/oder eines Treffer-Shaders entfernt wird.
iv. Aktualisieren der Strahlsteuerung (nur BVH), falls der Strahl über das Instanzblatt zu der neuen BVH heruntergeleitet werden muss.

61A-B veranschaulichen Tabellen zum Konfigurieren von Lese-/Schreibports und Einstellen von Steuerbits für alle Strahlverfolgungstraversierstrukturen. Insbesondere sind beispielhafte Unterstrukturen, vertikale Strukturen und Lese/Schreib-Handlungen für Strahlen 6101, Treffer 6102 und Stapel 6103 gezeigt. Es ist jedoch anzumerken, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf diese spezifischen Datenstrukturen/Operationen beschränkt sind.

VORRICHTUNG UND VERFAHREN FÜR HOHE QUALITÄT STRAHLVERFOLGTE EBENE VON DETAILÜBERGÄNGEN

Bei Grafikverarbeitungsarchitekturen kann sich das „Detailniveau“ (LOD) auf die Auswahl von Netzauflösungen basierend auf Variablen, wie etwa dem Abstand von der Kamera, beziehen. LOD-Techniken werden verwendet, um Speicherverbrauch zu reduzieren und Grafikverarbeitungsfunktionen, wie etwa geometrisches Aliasing in Spielen, zu verbessern. Zum Beispiel werden die Details eines hochauflösenden Netzes möglicherweise nicht benötigt, wenn das Netz weit von der aktuellen Perspektive des Benutzers entfernt ist.

Bei rasterungsbasierten Implementierungen werden glatte Übergänge zwischen LODs unter Verwendung von „stochastischen LOD“ - Techniken ermöglicht, wie etwa in Lloyd et al., Implementing Stochytic Levels of Detail with Microsoft DirecX Raytracing (15 Juni 2020) beschrieben. Ohne diese stochastischen Techniken kann der Übergang zwischen LODs zu ablenkenden Artefakten führen, bei denen sich Objekte plötzlich im Erscheinungsbild ändern, wenn eine neue LOD ausgewählt wird. Unter Verwendung stochastischer LODs wird eine Querauflösung zwischen LOD-Pegeln durch eine zufällige Zuordnung von Pixeln zu einer der LODs durchgeführt, die am Übergang beteiligt sind (z. B. entweder die LOD mit höherer Auflösung oder die LOD mit niedrigerer Auflösung).

Die obige Lösung verwendet eine binäre Maske und einen binären Vergleichswert, um acht Übergangsschritte für stochastische LOD-Übergänge beim Überblenden von einem ersten LOD („LODO“) zu einem zweiten LOD („LOD1“) zu erreichen. Bei dieser Implementierung werden eine 8-Bit-Strahlenmaske und eine 8-Bit-Instanzmaske logisch UND-verknüpft, um zu bestimmen, ob eine Instanz durchlaufen werden muss. Diese 8-Bit-Masken und die zugehörigen bitweisen Verknüpfungen führen zu begrenzten LOD-Übergangsfähigkeiten. Wenn zum Beispiel zwischen LODO und LOD1 eines Objekts übergegangen wird, wobei LODO einen Bruchteil von 0,25 aufweist und LOD1 einen Bruchteil von 0,75 aufweist (basierend auf dem Kameraabstand), würde die Maske für die Instanz auf LODO gesetzt werden, um nur 2 Zufallsbits (0,25 von 8 Bits) zu aktivieren. Die Instanzmaske für LOD1 würde auf das Binärkomplement der Maske von LODO gesetzt, wobei 6 Bits aktiviert sind. Für einen beliebigen gegebenen Strahl wird ein Zufallsbit in der Strahlenmaske ausgewählt, um eine Zufallsauswahl von entweder LODO (mit einer Wahrscheinlichkeit von 0,25) und LOD1 (mit einer Wahrscheinlichkeit von 0,75) zu erreichen. Da jedoch nur eines von acht Bits ausgewählt wird, gibt es nur 8 Zwischenschritte zum Übergang zwischen LODO und LOD1.

Wie in 62 gezeigt, ist in einer Ausführungsform der Erfindung ein LOD-Selektor 6205 mit einer N-Bit-Vergleichsoperationsmaske 6220 versehen, die als ein Binärwert behandelt wird, um eine durchzuführende Vergleichsoperation zu bestimmen. Die ausgewählte Vergleichsoperation wird verwendet, um mit der Referenz zu vergleichen, um mehr Übergangs-LOD-Stufen zu berücksichtigen. In einer Ausführungsform ist die Vergleichsoperation ausgewählt aus kleiner als oder gleich (kleiner_gleich) und größer als (größer), obwohl die der Erfindung zugrundeliegenden Prinzipien nicht auf diese spezifischen Vergleichsoperationen beschränkt sind. Bei einer Implementierung werden 8
Bits verwendet (N=8), wobei 7 der Bits einen vorzeichenlosen ganzzahligen Wert im Bereich von [0..127] definieren, wodurch 128 Übergangsschritte für LOD-Überblendung ermöglicht werden und 1 Bit die Vergleichsoperation anzeigt (wenn z. B. auf 0 gesetzt, dann wird eine Operation kleiner_gleich durchgeführt und wenn auf 1 gesetzt, wird die größere Operation durchgeführt). In einer Ausführungsform kann dem LOD-Selektor 6205 in dem Bereich [0..127] auch eine Strahlenvergleichsmaske 6221 als ein zusätzlicher Strahlenparameter bereitgestellt werden.

Die folgende Codesequenz verdeutlicht, wie die Strahltraversierung auf diese neue Vergleichsmaske reagiert, in einer Ausführungsform:

 if(ray.InstanceMask & instance.InstanceMask)
 {
      if(
      (instance.ComparisonMode =less_equal & &
      instance.ComparisonMask < = ray.ComparisonMask)||
      (instance.ComparisonMode = greater & & instance.ComparisonMask >
      ray.ComparisonMask)
      )
      {
      traverseInstance(Instance);
      }
 }

In der obigen Codesequenz prüft die erste ZF-Aussage, ob die Binärmasken ein Durchlaufen in die aktuelle Instanz erlauben. Falls ja, prüft die zweite ZF-Anweisung dann die Vergleichsmoduseinstellung hinsichtlich der Werte für die Instanzvergleichsmaske (z. B. die Vergleichsoperationsmaske 6220) und die Strahlenvergleichsmaske 6221.

Zurückkehrend zu dem obigen LOD-Übergangsbeispiel werden für die Instanz von LODO mit einem Bruchteil von 0,25 die ersten 7 Bits auf einen Wert von 31 (=int(0,25*127)) gesetzt und das letzte Bit wird auf 0 gesetzt (was die Operation kleiner_gleich angibt). Für den Fall von LOD1 mit einem Bruchteil von 0,75 werden die ersten 7 Bits auf einen Wert von 31 (=int((1,0-0,75)*127)gesetzt und das letzte Bit wird auf 1 gesetzt (was die größere Operation angibt). Falls also für diese Implementierung eine gleichmäßig verteilte Zufallszahl in dem Bereich [0. 127] als eine Strahlenvergleichsmaske gibt es bis zu 127 Übergangsschritte, die durch den LOD-Selektor 6205 zum Übergang zwischen LODO und LOD1 ausgewählt werden können.

Obwohl die oben dargelegten spezifischen Einzelheiten zum Zweck der Erläuterung verwendet werden, können die zugrundeliegenden Prinzipien der Erfindung mit anderen Einzelheiten implementiert werden. Zum Beispiel können andere Vergleichsoperatoren anstelle von oder zusätzlich zu weniger_gleich und größer verwendet werden. Beispielsweise können auch Vergleichsoperatoren wie not_equal, equal, less und greater_equal (größer als oder gleich) verwendet werden. Eine Implementierung umfasst ein Strahlen-Flag und ein Instanz-Flag, das UNDverknüpfte Strahlenmasken deaktiviert und die Verwendung dieser Bits als Vergleichsmasken ermöglicht.

BESCHLEUNIGUNGSDATENSTRUKTURKOMPRIMIERUNG

Die Konstruktion von Beschleunigungsdatenstrukturen ist einer der wichtigsten Schritte bei dem effizienten strahlenverfolgten Rendern. In jüngster Zeit ist die hierin ausführlich beschriebene Bounding Volume Hierarchy(BVH)-Beschleunigungsstruktur die für diesen Zweck am weitesten verbreitete Struktur geworden. Die BVH ist eine hierarchische Baumstruktur, die dazu dient, Geometrie räumlich so zu indexieren und zu organisieren, dass Strahl/Primitiv-Schnittabfragen sehr effizient aufgelöst werden können. Die Fähigkeit, diese Anfragen aufzulösen, ist eine der kritischsten Operationen für das strahlenverfolgte Rendern. Obwohl die unten beschriebenen Ausführungsformen der Erfindung an einer BVH-Struktur arbeiten, sind die zugrundeliegenden Prinzipien der Erfindung nicht auf eine BVH beschränkt. Diese Ausführungsformen können auf eine beliebige andere Beschleunigungsdatenstruktur mit ähnlichen relevanten Merkmalen angewendet werden.

Das Produzieren einer BVH wird typischerweise als „Konstruieren“ oder „Konstruieren“ der BVH bezeichnet. Obwohl eine Reihe von BVH-Konstruktionsalgorithmen vorgeschlagen wurde, werden Top-Down-BVH-Builder vorwiegend verwendet, um eine hohe Rendering-Effizienz sowohl für Echtzeit-als auch Offline-Rendering-Anwendungen zu erreichen. Top-down BVH-Aufbaualgorithmen halten typischerweise ein oder mehrere temporäre Arrays während des Aufbaus aufrecht. Diese Arrays enthalten Daten, die notwendig sind, um die Geometrie zu sortieren/zu organisieren, um die BVH-Struktur zu erzeugen. Diese Arrays werden während des Builds mehrmals gelesen und/oder geschrieben (typischerweise 1-2 mal pro Ebene der BVH-Hierarchie). Da diese Arrays häufig von erheblicher Größe sind, ist dieser Prozess bandbreitenintensiv. Dementsprechend haben Verbesserungen der BVH-Aufbau-Rechenleistung, wie sie etwa von einem Hardware-BVH-Builder erwartet werden könnten, wahrscheinlich nur eine begrenzte Auswirkung, falls dieses Bandbreitenproblem nicht angesprochen wird.

Eine Ausführungsform der Erfindung umfasst ein Komprimierungsschema für die temporären Daten, die von vielen Top-Down-BVH-Buildern verwaltet werden. Zweck dieses Komprimierungsschemas ist es, die für die BVH-Konstruktion erforderliche Bandbreite zu reduzieren, wodurch eine schnellere und effizientere BVH-Konstruktion ermöglicht wird. Es wird jedoch angemerkt, dass die Ausführungsformen der Erfindung für andere Arten von BVH-Buildern und mit anderen Arten von Beschleunigungsdatenstrukturen, wie etwa kd-Bäumen, verwendet werden können.

Viele Top-down BVH-Builder pflegen zwei primäre Datentypen während des BVH-Builders: (1) eine Achsen ausgerichtete Begrenzung Box (AABB) für jedes Primitiv, das am BVH-AUFBAU beteiligt ist; und (2) einen jedem Primitiv zugeordneten vorzeichenlosen ganzzahligen Index, der auf eines dieser AABBs und/oder auf das ursprüngliche Primitiv, aus dem das AABB hergestellt wurde, zeigt.

Eine Ausführungsform der Erfindung nutzt ein Structure of Arrays(SOA)-Layout zum Kombinieren jedes AABB mit einem einzigen ganzzahligen Index. Die AABBs werden in einem Array gehalten und die ganzzahligen Indizes in einem zweiten Array. Lediglich das Indexfeld muss umgeordnet werden, um eine BVH-Konstruktion zu erreichen. Eine derartige Speicherung der Aufbaudaten führt zu einer Reihe von Vorteilen. In diesem Layoutschema sind die AABB-Daten größtenteils nur-lese und AABB-Schreibbandbreite fällt für den Großteil des Aufbauprozesses nicht an.

Durch die Verwendung einer SOA-Struktur müssen nur die AABBs selten während des Aufbaus komprimiert werden. Tatsächlich müssen die AABB-Daten in Abhängigkeit von der Implementierung möglicherweise nur einmal vor dem Aufbau als ein Vorprozess komprimiert werden. Da der Aufbau durch Partitionieren der Indexarrays durchgeführt wird, werden diese in einer Ausführungsform der Erfindung auf jeder Ebene des Aufbaus erneut komprimiert.

Durch Arbeiten mit komprimierten Versionen dieser Arrays anstelle ihrer herkömmlichen, unkomprimierten Gegenstücke wird die für den BVH-Aufbau benötigte Bandbreite reduziert. Die komprimierten Versionen der Arrays werden zwischengespeichert und nur zum Zweck des Aufbaus verwendet. Sie werden verworfen, sobald der Aufbau abgeschlossen ist, wobei ein BVH zurückbleibt, der auf die ursprüngliche Eingabeliste von Primitiven verweist.

Ein wichtiges Merkmal der hier beschriebenen Komprimierungstechniken ist, dass sie cache-zeilenbewusst sind. Beide der komprimierten Arrays werden als ein Array von Komprimierungsblöcken fester Größe gespeichert, wobei die Größe eine ganze Zahl von Cache-Zeilen ist. Diese Anzahl ist größer oder gleich eins. Die Komprimierungsblöcke jedes der beiden Arraytypen brauchen nicht gleich groß zu sein. Diese beiden Blocktypen werden hier als AABB-Komprimierungsblöcke und Indexkomprimierungsblöcke bezeichnet.

Es wird angemerkt, dass die zugrundeliegenden Prinzipien der Erfindung nicht erfordern, dass die Größe der Blöcke eine ganze Zahl von Cachelines ist. Vielmehr ist dies eines von mehreren hier beschriebenen optionalen Merkmalen. Bei einer unten beschriebenen Ausführungsform ist diese Funktionalität durch die Variablen AABBCompressionBlockSizeBytes und IndexCompressionBlockSizeBytes in Tabellen B bzw. D gesteuert.

Da die räumliche Ausdehnung und Anzahl von Primitiven, auf die durch jeden Knoten Bezug genommen wird, im Allgemeinen abnehmen wird, wenn der Top-Down-Aufbau von der Wurzel zu den Blättern der Baumstruktur fortschreitet, können unterschiedliche Repräsentationen der AABBs in unterschiedlichen Konstruktionsstadien angemessen sein. Zum Beispiel kann die Genauigkeit der komprimierten AABBs auf den oberen Ebenen des Baums weniger kritisch sein, wohingegen genauere Repräsentationen auf den unteren Ebenen erforderlich sein können, um eine angemessene Baumqualität beizubehalten. Es kann folglich ausreichend sein, verlustbehaftete Komprimierung nahe der Wurzel des Baums zu verwenden, um Bandbreiteneinsparungen zu maximieren, und zu einer unkomprimierten, verlustfreien Repräsentation der Primitive für die niedrigeren Ebenen umzuschalten. Dies unterteilt den BVH-Aufbau in mindestens zwei Phasen, die in 63 dargestellt sind: eine obere Phase 6301 für Knoten auf oder oberhalb einer spezifizierten Ebene der Hierarchie (Knoten 0, 1, 8) und eine untere Phase 6302 für Knoten unterhalb der spezifizierten Ebene (Knoten 2-7, 9-14). Ein mehrstufiger Aufbau kann auf eine solche Weise fortfahren, dass die Gesamtheit einer Hierarchie höherer Ebene (z. B. der „obere“ Teil in 63) aufgebaut wird, bevor irgendein Knoten in den unteren Ebenen aufgebaut wird, oder der Aufbau der Ebenen verschachtelt werden kann. Falls eine obere Ebene vollständig vor irgendwelchen unteren Ebenen aufgebaut wird, können Knoten, die auf einer unteren Ebene des Aufbaus aufgeteilt werden müssen, auf einer Struktur gespeichert werden, wie etwa einer Warteschlange, die in einem späteren Stadium zu partitionieren ist.

Alternativ zur Verwendung einer Kopie der AABBs mit voller Genauigkeit für die niedrigeren Ebenen 6302 besteht eine andere Variation des Schemas darin, die AABBs während des Aufbaus zur Verwendung beim Aufbau der niedrigeren Ebenen „neu zu komprimieren“. Dadurch kann Geometrie relativ zur Ausdehnung einzelner Teilbäume komprimiert werden. Da einzelne Teilbäume im Allgemeinen eine geringere räumliche Ausdehnung im Vergleich zum Wurzelknoten darstellen, kann dies der Genauigkeit der komprimierten Darstellung bzw. der Effizienz der Komprimierung zugute kommen. Ein ähnliches Muster für einen mehrstufigen komprimierten Aufbau wird in der aktuellen Forschung beobachtet. Die Aufteilung 6300 zwischen verschiedenen Bauphasen kann gemäß einer Vielzahl von Knotencharakteristiken definiert werden. Eine Ausführungsform verwendet eine feste Anzahl von Primitiven, um als Schwellenwert zu fungieren.

Eine Variation, die bei manchen Ausführungsformen der Erfindung verwendet wird, sieht stattdessen vor, nur einen einstufigen Aufbau einzusetzen. Beispielsweise könnte eine einzige komprimierte Repräsentation der Aufbaudaten verwendet werden, um den gesamten Baum aufzubauen.

I. AABB-Komprimierung

In einer Ausführungsform der Erfindung ist die Eingabe in die AABB-Komprimierungslogik (die in Hardware und/oder Software implementiert sein kann) ein Array von unkomprimierten Primitiven und die Ausgabe ist ein Array von AABB-Komprimierungsblöcken, die eine feste Größe aufweisen und mit einer gewissen Anzahl von Cache-Zeilen ausgerichtet sind. Da das effektive AABB-Komprimierungsverhältnis in einer beliebigen bestimmten Region des Netzes stark datenabhängig ist, packt eine Ausführungsform eine variable Anzahl von AABBs pro AABB-Komprimierungsblock.

Wie in 64 gezeigt, ist eine Ausführungsform des Komprimierungsblocks 6400 in zwei Hauptteilen organisiert: Metadaten 6401 und Vektorwiderstände 6402 auf. Die Metadaten 6401 liefern blockweise Informationen und Konstanten, die erforderlich sind, um die Vektorreste 6402 in eine Liste von AABBs zu decodieren. Die Vektorreste 6402 speichern den Großteil der komprimierten Informationen, die zum Darstellen der AABs verwendet werden. Jedes dieser Elemente wird nachfolgend näher beschrieben.

Kurz gesagt, wird in einer Ausführungsform Deltakomprimierung verwendet. Ein seedVector umfasst einen Basisliniensatz von AABB-WERTEN und die Vektorreste 6402 liefern Offsets zu diesen Basislinienwerten, um jeden AABB zu rekonstruieren. Der numResiduals-Wert gibt die Anzahl der Vektorresiduen 6402 an und der residualSizeVector gibt die Größe der Residuen 6402 an.

AABB-Globalkomprimierungskonstanten

Zusätzlich zu den blockweisen Konstanten, die in jedem Komprimierungsblock 6400 gespeichert sind, kann ein Satz von AABB-Globalkomprimierungskonstanten Informationen bezüglich aller Blöcke in dem gesamten Komprimierungsprozess speichern. Diese sind in Tabelle B für eine bestimmte Implementierung zusammengefasst. TABELLE B

Konstant	Beschreibung
NQ {X, Y, Z}	Drei Werte, die die Anzahl der Bits bezeichnen, die zur Quantisierung von Vertexkomponenten in jeder der drei Raumdimensionen verwendet werden.
AABBCompressionBlockSizeBytes	Größe in Bytes eines AABB-Komprimierungsblocks. Dieser Wert wird typischerweise auf eine bestimmte Anzahl von Cache-Zeilen ausgerichtet sein.
maxAABBsPerBlock	Die maximal erlaubte Anzahl von AABBs in einem AABB-Komprimierungsblocks. Diese Konstante wird zusammen mit der globalen Komprimierungskonstante num ResidualVectorsPerPrimitive verwendet, um die Anzahl von Bits zu bestimmen, die für den in 64 gezeigten numResiduals-Wert benötigt werden.
numResidualVectorsPerPrimitive	Dieser Wert verfolgt die Anzahl der Restvektoren, die zur Darstellung eines AABB in den komprimierten Blöcken verwendet werden. Eine reguläre AABB besteht normalerweise aus zwei 3D-Vektoren, min und max. Es ist jedoch möglich, dass die Repräsentation des AABB in eine Struktur mit einer anderen
	Anzahl von Vektoren transformiert werden kann. Ein Beispiel hierfür wird im späteren Abschnitt über Fehler! Referenzquelle nicht gefunden, erläutert, wobei ein Paar von 3D-Vektoren in einen einzelnen 6D-Vektor transformiert wird. Es ist erforderlich, dass der Komprimierungsalgorithmus diesen Wert nachverfolgt, um mehrere Kernoperationen korrekt durchzuführen.
residualNumDimensions	Diese Konstante wird verwendet, um zu verfolgen, wie viele Dimensionen die Restvektoren an dem Punkt haben werden, an dem sie zu den AABB-Komprimierungsblöcken addiert werden. Dieser Wert wird benötigt, da die 3D-AABB-Daten bei der Komprimierung in eine andere Anzahl von Dimensionen transformiert werden können.

AABB-Komprimierungsströmung

Eine Ausführungsform des AABB-Komprimierungsprozesses schließt wiederum Iterieren durch das Eingabearray von Primitiven und Ausgeben eines Arrays von AABB-Komprimierungsblöcken 6400 ein. Das Ausgangsfeld enthält eine minimale Anzahl von AABB-Komprimierungsblöcken 6400, die benötigt werden, um die AABBs der Primitive in komprimierter Form darzustellen.

65 veranschaulicht einen Prozess gemäß einer besonderen Ausführungsform. Wie erwähnt, ist der Komprimierungsprozess nicht auf eine bestimmte Architektur beschränkt und kann in Hardware, Software oder einer beliebigen Kombination davon implementiert werden.

Bei 6501 wird ein Array von Primitiven für einen BVH-AUFBAU bereitgestellt. Bei 6502 wird das nächste Primitiv in dem Array (z. B. das erste Primitiv zu Beginn des Prozesses) ausgewählt und seine AABB wird auf Komprimierung ausgewertet. Falls die AABB in den aktuellen Komprimierungsblock passt, bestimmt bei 6503 (z. B. basierend auf ihren Mix/MAX-Daten), dann wird die AABB bei 6504 zu dem aktuellen Komprimierungsblock hinzugefügt. Wie erwähnt, kann dies das Bestimmen von Restwerten für den AABB durch Berechnen der Abstände zu einem existierenden Basisvektor innerhalb des Komprimierungsblocks (z. B. seedVector) umfassen.

In einer Ausführungsform wird, falls die AABB des Primitivs nicht in den Komprimierungsblock passt, der aktuelle Komprimierungsblock bei 6510 abgeschlossen und im Speicher innerhalb des Ausgabearrays gespeichert. Bei 6511 wird ein neuer Komprimierungsblock unter Verwendung des AABB des Primitivs initialisiert. In einer Ausführungsform wird die primitive AABB als der Startvektor für den neuen Komprimierungsblock verwendet. Residuen können dann für nachfolgende AABBs von Primitiven basierend auf Abständen zu dem neuen Seed-Vektor erzeugt werden. Bei einer Implementierung wird das erste Residuum, das für den zweiten AABB erzeugt wird, basierend auf Abstandswerten zu den Seed-Vektorwerten bestimmt. Der zweite Residuum wird dann für den dritten AABB basierend auf Abständen zu dem ersten Residuum bestimmt. Es wird also eine Laufdifferenz gespeichert, wie nachfolgend näher beschrieben wird. Sobald das aktuelle Primitiv komprimiert ist, kehrt der Prozess zu 6502 zurück, wo das nächste Primitiv in dem Array zur Komprimierung ausgewählt wird.

Somit wird, besucht jedes Primitiv wiederum, seine AABB bestimmt (z. B. als ein Gleitwert). Dann wird Eine Reihe von Operationen an dem AABB durchgeführt, um eine Komprimierung zu erreichen, und das komprimierte Ergebnis wird zu dem aktuellen AABB-Komprimierungsblock in dem Ausgabefeld addiert. Wenn die komprimierte AABB passt, wird sie zu dem aktuellen Block hinzugefügt und der Prozess geht zu der nächsten AABB über. Wenn der AABB nicht passt, wird der aktuelle AABB-Komprimierungsblock abgeschlossen und ein neuer AABB-Komprimierungsblock wird in dem Ausgabefeld initialisiert. Auf diese Weise wird die Anzahl komprimierter Blöcke, die zum Speichern der AABBs benötigt werden, minimiert.

Der folgende Pseudocode in TABELLE C zeigt den Ablauf der AABB-Komprimierung gemäß einer besonderen Ausführungsform der Erfindung. Es ist jedoch anzumerken, dass die zugrundeliegenden Prinzipien der Erfindung nicht notwendigerweise auf diese Einzelheiten beschränkt sind.

Wie in der Pseudocodesequenz gezeigt, wird für jeden AABB-Komprimierungsblock eine ganze Zahl in ein separates Array (blockOffsets) geschrieben, das die Position in dem ursprünglichen Primitiv-Array aufzeichnet, an der jeder AABB-Komprimierungsblock startet (d. h. der erste Primitiv-AABB, der er enthält). Das blockOffsets-Array wird während des Aufbaus zum Auflösen der ursprünglichen Primitiv-IDs verwendet, die der komprimierte Block repräsentiert.

AABB-Restberechnung

In einer Ausführungsform durchläuft jeder EINGANGS-AABB einen Satz von Stufen, um ihn zu komprimieren, bevor er zu einem komprimierten Block hinzugefügt wird, was zu den in 64 gezeigten Vektorwiderständen führt. Der Prozess wird als der Code auf Zeile 26 von Tabelle C erfasst, wobei der Komprimierungskern verwendet wird, um die AABB in eine Liste komprimierter Vektoren umzuwandeln.

TABELLE C

In einer Ausführungsform findet die Komprimierung eines AABs in den folgenden Stufen statt: (1) Quantisierung, (2) Transformation und (3) Prädiktion/Delta-Codierung.

1. Quantisierung

In einer Ausführungsform werden die Gleitkomma-AABB-Werte zuerst unter Verwendung einer festen Anzahl von Bits pro Achse zu einer vorzeichenlosen ganzzahligen Darstellung quantisiert. Dieser Quantisierungsschritt kann auf vielfältige Weise durchgeführt werden. Beispielsweise werden in einer Implementierung für jede Achse i folgende Werte bestimmt:

\begin{array}{l} L_{i} = S_{m a x, i} - S_{m i n, i} \\ N_{B, i} = 2^{N Q_{i}} \\ V U_{m i n, i} = (V F_{m i n, i} - S_{m i n, i}) / L_{i} \times N_{B, i} \\ V U_{m a x, i} = (V F_{m a x, i} - S_{m i n, i}) / L_{i} \times N_{B, i} \end{array}

wobei S_min und S_max die Minimal- und maximal Koordinaten des gesamten Satzes von Geometrie sind, für die ein BVH aufgebaut werden soll, N_B,i die Anzahl von Zellen in dem quantisierten Gitter in der i-ten Achse ist, Nqi_i de Wert in Tabelle B entspricht, VU_min und VU_max die Minimal- und maximal Koordinaten des quantisierten AABB sind, VF_mm und VF_max die Minimal- und maximal Koordinaten des ursprünglichen Gleitkomma AABB sind und der Index i eine gegebene Achse (i □{x,y,z}) bezeichnet. Da eine Gleitkommaberechnung Fehler einführen kann, sollten die Zwischenwerte auf- oder abgerundet werden, um die Werte von VU_min zu minimieren und die Werte von VU_max, zu maximieren. Die Werte können auch in eine ganze Zahl umgewandelt und auf den gültigen Bereich beschränkt werden, um sicherzustellen, dass sich ein wasserdichter AABB innerhalb des AABB des gesamten Geometriesatzes befindet.

S_min und S_max könnten auch die Ausdehnung einer Teilmenge der Geometrie (z.B. eines Teilbaums innerhalb einer größeren BVH) repräsentieren. Dies könnte beispielsweise bei einem mehrstufigen komprimierten Aufbau gemäß 63 auftreten.

2. Transformation

In einer Ausführungsform wird eine Transformationsstufe implementiert, in der Daten in eine Form transformiert werden, die einer Komprimierung besser zugänglich ist. Obwohl eine Vielfalt von Transformationen verwendet werden kann, setzt eine Ausführungsform der Erfindung eine neuartige Transformation ein, die hier als Positions-Extent-Transformation bezeichnet wird, die VU_min und VU_max zu einem einzelnen 6-dimensionalen (6 D) Vektor pro Primitiv, VT, kombiniert, wie unten gezeigt ist:

\begin{array}{l} E_{x} = V U_{m a x, x} - V U_{m i n, x} E_{y} = V U_{m a x, y} - V U_{m i n, y} E_{z} = V U_{m a x, z} - V U_{m i n, z} \\ V_{T} = (V U_{m i n, x}, V U_{m i n, y}, V U_{m i n, z}, E_{x}, E_{y}, E_{z}) \end{array}

wobei VU_min{x,y,z} und VU_max{x,y,z} die Komponenten von VU_min bzw. VU_max sind. Im Wesentlichen erlaubt diese Transformation, die Lage und Ausdehnung/Größencharakteristik des AABB separat in den übrigen Komprimierungsstufen zu behandeln. Wie erwähnt, können auch andere Transformationen verwendet werden.

3. Prädiktion/Delta-Codierung

Bei einer Implementierung wird eine herkömmliche Delta-Codiertechnik verwendet, um eine gute Komprimierungleistung zu erreichen. In einer Ausführungsform wird der erste Vektor in jedem
Komprimierungsblock als ein „Seed“ -Vektor bezeichnet und in dem AABB-Komprimierungsblock 6400 verbatim gespeichert, wie in 64 gezeigt ist. Für nachfolgende Vektoren wird eine Laufdifferenz der Werte gespeichert (d. h. Residuen 6402). Dies entspricht einem Vorhersageschema, bei dem die Vorhersage für den nächsten Eingabevektor in der Sequenz immer der vorherige Eingabevektor ist und der Restwert die Differenz zwischen dem aktuellen und dem vorherigen Eingabevektor ist. Die Restwerte 6402 sind in dieser Ausführungsform also vorzeichenbehaftete Werte, was ein zusätzliches Vorzeichenbit erfordert. Verschiedene andere Prädiktions-/Delta-Codierungen können verwendet werden, wobei die der Erfindung zugrundeliegenden Prinzipien noch eingehalten werden.

Eine Ausführungsform speichert die Restwerte 6402 mit der Mindestanzahl an benötigten Bits, um die Komprimierung zu maximieren. Basierend auf der Größe der Restwerte am Ende der Restcodierungsschritte wird eine bestimmte Anzahl von Bits für jede der Vektor Dimensionen erforderlich sein, um den in dieser Dimension anzutreffenden Werte Bereich aufzunehmen.

Die Anzahl an benötigten Bits wird in einem Restgrößenvektor (RSV) gespeichert, wie in den Metadaten 6401 in 64 veranschaulicht ist. Der RSV ist für einen gegebenen Komprimierungsblock 6400 festgelegt, so dass alle Werte in einer gegebenen Dimension eines speziellen Blocks die gleiche Anzahl von Bits für ihre Residuen 6402 verwenden.

Der in jedem Element des RSV gespeicherte Wert ist einfach die minimale Anzahl von Bits, die benötigt wird, um den gesamten Bereich von Restwerten in der Dimension als eine vorzeichenbehaftete Zahl zu speichern. Während ein gegebener AABB-Komprimierungsblock (d. h. die Zeilen 18 - 37 von Tabelle C) komprimiert wird, wird ein laufendes Maximum der Anzahl von Bits beibehalten, die benötigt werden, um alle bisher betrachteten Vektoren aufzunehmen. Die RSV wird für jeden neu hinzugefügten AABB (d. h. CommitToBlock, Zeile 32 von Tabelle C) bestimmt und in den Metadaten der Komprimierungsblöcke gespeichert.

Um zu testen, ob ein neuer AABB in den aktuellen Block passen wird (d. h. TestAddToBlock, Zeile 28 von Tabelle C und Operation 6503 in 65), berechnen wir das erwartete neue RSV, das durch Addieren des neuen AABB auftreten würde, summieren des erwarteten RSV-Vektors und multiplizieren dann diesen Wert mit der Gesamtanzahl von Residuen, die in dem Block existieren würden, wenn der neue AABB addiert würde. Falls dieser Wert innerhalb des Budgets liegt, das zum Speichern von Residuen verfügbar ist (d. h. kleiner oder gleich der Gesamtblockgröße minus der Metadatengröße 6401), kann er zu dem aktuellen Block hinzugefügt werden. Falls nein, wird ein neuer Komprimierungsblock initialisiert.

Entropie-Kodierung

Eine Ausführungsform der Erfindung umfasst einen zusätzlichen Schritt zur AABB-Restberechnung, der eine Entropie-Codierung der Reste nach der Prädiktion/Delta-Codierung umfasst. Die der Erfindung zugrundeliegenden Prinzipien sind nicht auf diese spezielle Ausführung beschränkt.

Vorsortier-/Umordnungsfähiakeit

Als ein optionaler Vorprozess kann die Eingabegeometrie sortiert/umgeordnet werden, um räumliche Kohärenz zu verbessern, was die Komprimierungsleistung verbessern kann. Das Sortieren kann auf verschiedene Weisen durchgeführt werden. Eine Möglichkeit, dies zu erreichen, besteht in der Verwendung einer Morton-Code-Sortierung. Eine solche Art wird bereits als großer Schritt in anderen BVH-Buildern verwendet, um räumliche Kohärenz in der Geometrie vor Extraktion einer Hierarchie zu fördern.

Die komprimierten AABBs können in einer beliebigen gewünschten Reihenfolge geschrieben werden, aber falls die AABs umgeordnet/sortiert werden, dann ist es notwendig, ein zusätzliches Array von ganzen Zahlen zu speichern, das die sortierte Reihenfolge aufzeichnet. Das Array besteht aus einem einzigen ganzzahligen Index pro Primitiv. Der Aufbau kann mit dem primären Index fortfahren, der verwendet wird, um die umgeordnete Liste von Primitiven zu referenzieren. Wenn die ursprüngliche Primitiv-ID benötigt wird (wie etwa wenn die Inhalte eines Blattknotens geschrieben werden), müssen wir den primären Index verwenden, um die ursprüngliche Primitiv-ID in dem zusätzlichen Array nachzuschlagen, um sicherzustellen, dass der Baum korrekt auf die ursprüngliche Eingabegeometrieliste verweist.

II. AABB-Dekomprimierung

In einer Ausführungsform wird Dekomprimierung der AABBs für einen gesamten AABB-Komprimierungsblock 6400 zu einem Zeitpunkt durchgeführt. Die Restdaten werden zuerst rekonstruiert, indem die Metadaten 6401 des Komprimierungsblocks 6400 inspiziert werden und die gespeicherten Reste basierend auf diesen Informationen interpretiert werden (z. B. Addieren der Abstandswerte zu dem Startvektor und früherer Restwerte in der Sequenz). Die Inverse jeder der AABB-Komprimierungsstufen wird dann durchgeführt, um die durch den Komprimierungsblock repräsentierten Single-Präzisions-Gleitkomma-AABB zu dekomprimieren.

Eine Ausführungsform implementiert eine Variation des Dekomprimierungsschrittes bei BVH-Buildern, die präzisionsreduzierte Konstruktionstechniken einsetzen, die an eine komprimierte Hierarchieausgabe ausgerichtet sind. Solche Builder mit reduzierter Genauigkeit sind in der mitanhängigen Anmeldung mit dem Titel „An Architecture for Reduced Precision Bounding Volume Hierarchy Construction“, Seriennummer 16/746,636, eingereicht am 17. Januar 2020, die der Anmelderin der vorliegenden Anmeldung zugeordnet ist, beschrieben. Ein Builder mit reduzierter Genauigkeit führt viel seiner Berechnung in einem ganzzahligen Raum mit reduzierter Genauigkeit durch. Folglich richtet eine Ausführungsform der Erfindung den Quantisierungsschritt der hier beschriebenen AABB-RESTBERECHNUNG mit der Quantisierung aus, die in dem Builder mit reduzierter Genauigkeit eingesetzt wird. Die AABBs können dann nur auf eine ganze Zahl dekomprimiert werden, die mit dem Koordinatenraum irgendeines Knotens ausgerichtet ist, der gegenwärtig durch den Builder mit reduzierter Genauigkeit verarbeitet wird. Eine ähnliche Variation kann mit einem Builder implementiert werden, der keine komprimierte Hierarchie ausgibt, sondern eine Quantisierung von Vertices durchführt.

III. Indexkomprimierung

In einer Ausführungsform der Erfindung wird das Indexfeld in ein Feld von Indexkomprimierungsblöcken komprimiert. 66 veranschaulicht eine Ausführungsform eines Indexkomprimierungsblocks 6610, der Metadaten 6603 und Indexreste 6602 umfasst. Das Indexfeld unterscheidet sich von dem AABB-Feld, da es neu komprimiert werden muss, da die Indizes während des Aufbauprozesses partitioniert/neu geordnet werden.

In vielen herkömmlichen BVH-Buildern werden Indizes als vorzeichenlose ganze Zahlen repräsentiert, im Allgemeinen mit einem Index pro Primitiv. Das Indexfeld hat die Aufgabe, auf primitive AABBs hinweisen zu können. Jedem AABB/Primitiv kann eine feste Größe im Speicher zugewiesen werden. Es ist daher möglich, zufällig auf ein beliebiges Primitiv p oder AABB a in den Arrays zuzugreifen. Wenn AABB-KOMPRIMIERUNG jedoch zu einer variablen Anzahl von AABBs pro Cache-Zeile führt, wird der AABB-KOMPRIMIERUNGSBLOCK, der ein gegebenes Primitiv speichert, nach der Komprimierung nicht einfach bestimmt. Die Speicherung herkömmlicher Indizes ist daher nicht kompatibel mit den hierin beschriebenen AABB-Komprimierungsblöcken.

In einer Ausführungsform der Erfindung ermöglichen die Indexierungstechniken, die verwendet werden, um den Ort primitiver AABBs zu identifizieren, auch eine Komprimierung der Indizes selbst. Zwei neue Techniken werden im Folgenden als Block-Offset-Indizierung (BOI) und Hierarchische Bit-Vektor-Indizierung (HBI) bezeichnet. Diese Indexierungen können allein oder in Kombination bei den verschiedenen Ausführungsformen der Erfindung verwendet werden. Außerdem können beide Indexierungstechniken als Teil eines mehrstufigen Aufbaus gemäß 63 verwendet werden und beide Typen von Indizes können auch als Teil desselben BVH-AUFBAUS verwendet werden. Diese Indexierungstechniken ermöglichen, dass der BVH-AUFBAU auf eine ähnliche Weise wie ein herkömmlicher BVH-AUFBAU, aber mit komprimierten Repräsentationen sowohl des AABB als auch der entsprechenden Indexarrays fortfährt.

Globale Indexkomprimierungskonstanten

Indexkomprimierung verwendet einen Satz globaler Indexkomprimierungskonstanten, die für alle Indexkomprimierungsblöcke gelten. Beide der unten beschriebenen Indexkomprimierungsschemata teilen sich die gleichen globalen Konstanten, die in Tabelle D unten zusammengefasst sind. TABELLE D

Konstant	Beschreibung
IndexCompressionBlockSizeBytes	Größe in Bytes eines Indexkomprimierungsblocks. Dieser Wert wird typischerweise auf eine bestimmte Anzahl von Cache-Zeilen ausgerichtet sein.
maxIndicesPerBlock	Die maximale Anzahl der in einem Indexkomprimierungsblock erlaubten Indizes. Dieser Wert bestimmt die Anzahl von Bits, die benötigt werden, um die Anzahl von Indizes, die durch einen gegebenen Block repräsentiert werden, zu speichern.

Block-Offsetindexierung

Beim Block-Offsetindizieren (BOI: Block Offset Indexing) wird der regelmäßige Einzel-Ganzzahl-Index zu einer Struktur geändert, die zwei ganze Zahlen enthält, von denen eine den Komprimierungsblock 6400 identifiziert und eine einen Offset zum Identifizieren der Primitiv-AABB-Daten innerhalb des Komprimierungsblocks 6400 umfasst. Eine Ausführungsform der neuen Datenstruktur wird gemäß folgender Codefolge erzeugt:

      struct blockOffsetIndex
      {
            uint blockIdx;
            uint blockOffset;
      }

Hier speichert blockIdx einen Index zu einem AABB-Komprimierungsblock und blockOffset referenziert einen spezifischen Primitiv-AABB innerhalb des Blocks (d. h. blockIdx in Kombination mit blockOffset stellt die Adresse des Primitiv-AABB bereit). Diese Informationen reichen aus, um einen bestimmten AABB innerhalb seines Komprimierungsblocks während eines Aufbaus vollständig zu referenzieren.

In einer Ausführungsform wird eine dieser Strukturen für jedes Primitiv im BVH-Aufbau erzeugt, so dass die Größe der Liste vorhersagbar ist. Bei einer variablen Anzahl von AABBs pro AABB-Komprimierungsblock wird es jedoch eine variable Anzahl dieser Indexstrukturen für jeden dieser Komprimierungsblöcke geben (es werden z. B. nicht alle möglichen Werte von blockOffset für jeden AABB-Komprimierungsblock existieren). Um das Array von Block-Offsetindizes korrekt zu initialisieren, ist es daher notwendig, auf das blockOffsets-Array (siehe z. B. die Codesequenz in Tabelle C) zu verweisen, aus dem die Anzahl von Primitiven in jedem AABB-Komprimierungsblock entweder gleichzeitig mit oder als ein Nachprozess zu der AABB-Komprimierung bestimmt werden kann. Sobald initialisiert, können die Block-Offset-Indizes im Wesentlichen auf die gleiche Weise behandelt werden wie herkömmliche Indizes, die in herkömmlichen BVH-Buildern gefunden werden.

Einzelganzzahlige Indizes, die in herkömmlichen BVH-Buildern verwendet werden, sind typischerweise 4 Byte groß. In einer Ausführungsform werden 26 Bits für blockIdx und 6 Bits für blockOffset verwendet. In einer alternativen Ausführungsform werden kleinere Anzahlen von Bits für jede Variable verwendet, um die gesamte Speicherplatzfläche zu reduzieren. Da eine feste Größe für die blockOffset gewählt werden muss, setzt dies in einer Ausführungsform Grenzen für die maximale Anzahl an Primitiven pro AABB-Komprimierungsblock. Bei 6 Bit können pro AABB-Komprimierungsblock maximal 64 Primitive dargestellt werden.

Der verbleibende Adresspunkt für die Block-Offset-Indexierung ist, wie eine Komprimierung erreicht werden kann. Block-Offset-Indizes werden deltacodiert und der Reihe nach in Indexkomprimierungsblöcke verpackt. Jeder Block mit möglichst vielen Indizes gepackt wird und ein neuer Indexkomprimierungsblock jedes Mal gestartet wird, wenn der vorherige Kapazität erreicht. Dies wird auf sehr ähnliche Weise wie die AABB-Komprimierungsblöcke (wie in Tabelle C gezeigt) durchgeführt, was zu einer variablen Anzahl von Indizes pro Indexkomprimierungsblock führt.

66 veranschaulicht ein Beispiel für einen Block-Offset-Indexkomprimierungsblock 6610, der Metadaten 6603 umfasst, die Anzahl von Indizes zusätzlich zu einem Restgrößenvektor und einem Startvektor identifizieren. In einer Ausführungsform wird eine Zweikanalcodierung für die Indexresiduen 6602 verwendet, wobei die blockIdx- und blockOffset-Werte separat delta-komprimiert werden. Ähnlich den AABB-Komprimierungsblöcken speichert der Indexkomprimierungsblock 6610 eine Angabe der Anzahl von Indizes in dem Block, der Anzahl von Bits für die Residuen (als der Restgrößenvektor) und eines Startvektors, der einen ersten Startvektor für blockIdx und einen zweiten Startvektor für blockOffset umfasst. Die Indexrestwerte 6602 umfassen ein Paar Differenzwerte, die sich aus der Komprimierung ergeben. Beispielsweise kann ein Indexrestwert einen ersten Differenzwert, der eine Differenz zwischen dem Wert der aktuellen Eingabe blockIdx und einem Wert der vorherigen Eingabe blockIdx repräsentiert, und einen zweiten Differenzwert, der eine Differenz zwischen dem Wert der aktuellen Eingabe blockOffset und einem Wert der vorherigen Eingabe blockOffset repräsentiert, umfassen. Die ersten blockIdx- und blockOffset-Werte in der Sequenz sind in dem seedVector-Feld verbatim gespeichert, das den Vektor repräsentiert, aus dem der erste Restwert berechnet wird.

Hierarchische Bit-Vektor-Indexierung

Eine Ausführungsform der Erfindung verwendet eine andere Primitivindexkomprimierungstechnik, die als hierarchische Bit-Vektor-Indexierung (HBI) bezeichnet wird, die allein oder in Kombination mit Block-Offset-Indexierung (BOI) verwendet werden kann. HBI unterscheidet sich sowohl von herkömmlichen ganzzahligen Indizes als auch VON BOI darin, dass ein einziger HBI-Index mehrere Primitive auf einmal referenzieren kann. Tatsächlich kann sich ein HBI-Index bis zu einem gesamten AABB-Komprimierungsblock beziehen.

Eine erweiterte Struktur dieses Indextyps ist in den 67A-B gezeigt. Jeder HBI-Index 6700 besteht aus zwei Elementen. Die blockIdx 6708 zeigt auf einen gegebenen AABB-Komprimierungsblock, der dem gleichen Zweck wie das entsprechende Element in Block-Offset-Indizes dient. Die zweite Komponente ist ein Bitvektor 6701, der eine Anzahl von Bits aufweist, die gleich der maximalen Anzahl von AABBs ist, die in einem AABB-Komprimierungsblock (d. h. maxAABBsPerBlock) erlaubt sind. Jedes Bit im Bitvektor 6701 bedeutet, ob das entsprechende Element im AABB-Komprimierungsblock durch diesen Index referenziert wird. Falls zum Beispiel das dritte Bit in dem Bitvektor eine ‚1‘ ist, bedeutet dies, dass das dritte AABB/Primitiv des AABB-Komprimierungsblocks durch den HBI-Index referenziert wird. Falls das Bit ‚0‘ ist, dann wird dieses AABB/Primitiv nicht referenziert.

VORRICHTUNG UND VERFAHREN FÜR VERDRÄNGTE NETZKOMPRIMIERUNG

Eine Ausführungsform der Erfindung führt eine Pfadverfolgung durch, um photorealistische Bilder unter Verwendung einer Strahlverfolgung für Sichtbarkeitsabfragen zu rendern. Bei dieser Implementierung werden Strahlen von einer virtuellen Kamera geworfen und durch eine simulierte Szene verfolgt. Eine zufällige Abtastung wird dann durchgeführt, um inkrementell ein endgültiges Bild zu berechnen. Die zufällige Abtastung bei der Pfadverfolgung bewirkt, dass Rauschen in dem gerenderten Bild erscheint, das entfernt werden kann, indem ermöglicht wird, dass mehr Abtastungen erzeugt werden. Die Abtastwerte in dieser Implementierung können Farbwerte sein, die aus einem einzigen Strahl resultieren.

In einer Ausführungsform verlassen sich die für Sichtbarkeitsabfragen verwendeten Strahlverfolgungsoperationen auf Bounding Volume Hierarchies (BVHs) (oder eine andere hierarchische 3D-Anordnung), die über die Szenenprimitive (z. B. Dreiecke, Vierecke usw.) in einer Vorverarbeitungsphase erzeugt werden. Unter Verwendung einer BVH kann der Renderer schnell den nächsten Schnittpunkt zwischen einem Strahl und einem Primitiv bestimmen.

Beim Beschleunigen dieser Strahlenabfragen in Hardware (wie etwa mit der hier beschriebenen Traversierungs-/Kreuzungsschaltungsanordnung) können Speicherbandbreitenprobleme aufgrund der Menge abgerufener Dreiecksdaten auftreten. Leider wird viel der Komplexität in modellierten Szenen durch Verschiebungsabbildung erzeugt, bei der eine glatte Basisflächendarstellung, wie etwa eine Unterteilungsfläche, unter Verwendung von Unterteilungsregeln fein tesseliert wird, um ein tesseliertes Netz 6991 zu erzeugen, wie in 69A gezeigt. Auf jeden Vertex des fein mosaikartigen Gitters wird eine Verschiebungsfunktion 6992 angewendet, die typischerweise entweder nur entlang der geometrischen Normalen der Grundfläche oder in eine beliebige Richtung verschoben wird, um ein Verschiebungsnetz 6993 zu erzeugen. Der Betrag der Verschiebung, der der Oberfläche hinzugefügt wird, ist in der Reichweite begrenzt.

Eine Ausführungsform der Erfindung komprimiert verdrängungsabgebildete Netze effektiv unter Verwendung einer verlustbehafteten wasserdichten Komprimierung. Insbesondere quantisiert diese Implementierung die Verschiebung relativ zu einem groben Basisnetz, das mit dem Basisunterteilungsnetz übereinstimmen kann. In einer Ausführungsform können die ursprünglichen Vierecke des Basisunterteilungsnetzes unter Verwendung bilinearer Interpolation in ein Gitter mit der gleichen Genauigkeit wie die Verschiebungsabbildung unterteilt werden.

69B veranschaulicht eine Komprimierungsschaltungsanordnung/Logik 6900, die ein Verschiebungsabbildungsnetz 6902 gemäß den hier beschriebenen Ausführungsformen komprimiert, um ein komprimiertes Verschiebungsnetz 6910 zu erzeugen. Bei der veranschaulichten Ausführungsform erzeugt die Verschiebungsabbildungsschaltungsanordnung/Logik 6911 das Verschiebungsabbildungsnetz 6902 aus einer Basisunterteilungsoberfläche. 70A veranschaulicht ein Beispiel, bei dem eine primitive Oberfläche 7000 fein tesseliert ist, um die Basisunterteilungsoberfläche 7001 zu erzeugen. Eine Verschiebungsfunktion wird auf die Vertices der Basisunterteilungsfläche 7001 angewendet, um eine Verschiebungsabbildung 7002 zu erzeugen.

Zurückkehrend auf 69B quantisiert ein Quantisierer 6912 in einer Ausführungsform das verschiebungsabgebildete Netz 6902 relativ zu einem groben Basisnetz 6903, um ein komprimiertes verschobenes Netz 6910 zu erzeugen, das ein 3D-Verschiebungsarray 6904 und Basiskoordinaten 6905 umfasst, die mit dem groben Basisnetz 6903 assoziiert sind. Beispielhaft und nicht einschränkend veranschaulicht 70B einen Satz von Differenzvektoren d1-d4 7022, die jeweils mit einem anderen verschobenen Vertex v1-v4 assoziiert sind.

In einer Ausführungsform ist das grobe Grundnetz 7003 das Grundunterteilungsnetz 6301. Alternativ dazu unterteilt ein Interpolator 6921 die ursprünglichen Vierecke des Basisunterteilungsnetzes unter Verwendung bilinearer Interpolation in ein Gitter mit der gleichen Genauigkeit wie die Verschiebungsabbildung.

Der Quantisierer 6912 bestimmt die Differenzvektoren d1-d4 7022 von jedem groben Basisvertex zu einem entsprechenden verschobenen Vertex v1-v4 und kombiniert die Differenzvektoren 7022 in dem 3D-Verschiebungsarray 6904. Auf diese Weise wird das verschobene Gitter nur unter Verwendung der Koordinaten des Vierecks (Basiskoordinaten 6905) und des Arrays von 3D-Verschiebungsvektoren 6904 definiert. Es wird angemerkt, dass diese 3D-Verschiebungsvektoren 6904 nicht notwendigerweise mit den Verschiebungsvektoren übereinstimmen, die zum Berechnen der ursprünglichen Verschiebung 7002 verwendet werden, da ein Modellierungswerkzeug normalerweise das Viereck nicht unter Verwendung bilinearer Interpolation unterteilen würde und komplexere Unterteilungsregeln anwenden würde, um glatte Oberflächen zum Verschieben zu erzeugen.

Wie in 70C veranschaulicht, werden Gitter von zwei benachbarten Vierecken 7090-7091 nahtlos zusammennähen, da entlang der Umrandung 7092 beide Vierecke 7090-7091 exakt die gleichen Vertices v5-v8 bewerten werden. Da auch die entlang der Kante 7092 gespeicherten Verschiebungen für benachbarte Vierecke 7090-7091 identisch sind, wird die verschobene Oberfläche keine Risse aufweisen. Diese Eigenschaft ist von Bedeutung, da dies insbesondere bedeutet, dass die Genauigkeit der gespeicherten Verschiebungen für ein gesamtes Netz beliebig reduziert werden kann, so dass sich ein zusammenhängendes verschobenes Netz geringerer Qualität ergibt.

In einer Ausführungsform werden Gleitkommawerte mit halber Genauigkeit verwendet, um die Verschiebungen (z. B. 16-Bit-Gleitkommawerte) zu codieren. Alternativ oder zusätzlich wird eine gemeinsam genutzte Exponentendarstellung verwendet, die nur einen Exponenten für alle drei Vertexkomponenten und drei Mantissen speichert. Da das Ausmaß der Verschiebung normalerweise recht gut begrenzt ist, können ferner die Verschiebungen eines Netzes unter Verwendung von Festkommakoordinaten codiert werden, die durch eine Konstante skaliert sind, um einen ausreichenden Bereich zum Codieren aller Verschiebungen zu erhalten. Eine Ausführungsform der Erfindung verwendet bilineare Patches als Basisprimitive, die flache Dreiecke verwenden, während eine andere Ausführungsform Dreieckspaare verwendet, um jedes Viereck zu handhaben.

Ein Verfahren gemäß einer Ausführungsform der Erfindung ist in 71 dargestellt. Das Verfahren kann auf den hier beschriebenen Architekturen implementiert werden, ist aber nicht auf irgendeine spezielle Prozessor- oder Systemarchitektur beschränkt.

Bei 7101 wird aus einer Basisunterteilungsfläche ein verschiebungsabgebildetes Gitter erzeugt. Zum Beispiel kann eine primitive Oberfläche fein tesseliert sein, um die Basisunterteilungsoberfläche zu erzeugen. Bei 7102 wird ein Basisnetz erzeugt oder identifiziert (wie etwa das Basisunterteilungsnetz in einer Ausführungsform).

Bei 7103 wird eine Verschiebungsfunktion auf die Vertices der Basisunterteilungsfläche angewandt, um ein 3D-Verschiebungsarray von Differenzvektoren zu erzeugen. Bei 7104 werden die mit dem Basisnetz assoziierten Basiskoordinaten erzeugt. Wie erwähnt, können die Basiskoordinaten in Kombination mit den Differenzvektoren verwendet werden, um das verschobene Gitter zu rekonstruieren. Bei 7105 wird das komprimierte verschobene Gitter einschließlich des 3D-Verschiebungsarrays und der Basiskoordinaten gespeichert.

Das nächste Mal, wenn das Primitiv aus dem Speicher oder dem Speicher gelesen wird, bestimmt bei 6506, wird das verschobene Gitter aus dem komprimierten verschobenen Gitter bei 7103 erzeugt. Zum Beispiel kann das 3D-Verschiebungsarray auf die Basiskoordinaten angewandt werden, um das verschobene Gitter zu rekonstruieren.

VERBESSERTE VERLUSTBEHAFTETE NETZKOMPRIMIERUNG UND HARDWARE-BVH-TRAVERSIERUNG/KREUZUNG FÜR VERLUSTBEHAFTETE GITTER-PRIMITIVE

Komplexe dynamische Szenen sind für Echtzeit-Strahlverfolgungsimplementierungen herausfordernd. Prozedurale Oberflächen, Hautbildungsanimationen usw. erfordern Aktualisierungen von Triangulations- und Beschleunigungsstrukturen in jedem Frame, noch bevor der erste Strahl gestartet wird.

Anstatt nur ein bilineares Patch als Basisprimitiv zu verwenden, erweitert eine Ausführungsform der Erfindung den Ansatz, bikubische Viereck- oder Dreieckspatches zu unterstützen, die an den Patchrändern wasserdicht ausgewertet werden müssen. Bei einer Implementierung wird ein Bitfeld zu dem verlustbehafteten Gitter-Primitiv hinzugefügt, das angibt, ob ein implizites Dreieck gültig ist oder nicht. Eine Ausführungsform umfasst auch einen modifizierten Hardwareblock, der den existierenden Tesselator erweitert, um verlustbehaftete verschobene Netze (wie z. B. oben mit Bezug auf 69A-71 beschrieben) direkt zu erzeugen, die dann in dem Speicher gespeichert werden.

Bei einer Implementierung nimmt eine Hardwareerweiterung der BVH-Traversierungseinheit ein verlustbehaftetes Gitter-Primitive als Eingabe und extrahiert dynamisch Begrenzungsrahmen für Teilmengen von implizit referenzierten Dreiecken/Vierecken. Die extrahierten Begrenzungskästen befinden sich in einem Format, das mit der Strahlenkästchentestschaltungsanordnung der BVH-Traversierungseinheit (z. B. der unten beschriebenen Strahlen-/Kästchen-Traversierungseinheit 8930) kompatibel ist. Das Ergebnis der Strahlen-vs. dynamisch erzeugten Begrenzungsrahmen- Schnitttests wird an die Strahlen-Vierer-Dreieck-Schnitteinheit 8940 weitergeleitet, die die relevanten Dreiecke extrahiert, die in dem Begrenzungsrahmen enthalten sind, und diese schneidet. In einer Ausführungsform sind die „relevanten“ Dreiecke jene Dreiecke, die durch den Begrenzungsrahmen begrenzt sind.

Eine Implementierung umfasst auch eine Erweiterung des verlustbehafteten Netzprimitivs unter Verwendung von indirekt referenzierten Vertexdaten (ähnlich anderen Ausführungsformen), wodurch der Speicherverbrauch durch Teilen von Vertexdaten über benachbarte Netzprimitive reduziert wird. In einer Ausführungsform wird eine modifizierte Version des Hardware-BVH-Dreiecks-Intersektorblocks darauf aufmerksam gemacht, dass es sich bei der Eingabe um Dreiecke aus einem verlustbehafteten verschobenen Netz handelt, was es ihm ermöglicht, eine Kantenberechnung für benachbarte Dreiecke wiederzuverwenden. Eine Erweiterung wird auch zu der verlustbehafteten verschobenen Netzkomprimierung hinzugefügt, um eine Bewegungsunschärfegeometrie zu handhaben.

Wie oben beschrieben, wird unter der Annahme, dass der Eingang ein Gitternetz beliebiger Abmessungen ist, dieses Eingangsgitternetz zunächst in kleinere Teilgitter mit einer festen Auflösung unterteilt, wie etwa 4x4 Vertices, wie in 72 veranschaulicht.

Wie in 73 gezeigt, wird nun in einer Ausführungsform eine verlustbehaftete 4x4-Gitter-Primitivstruktur (GridPrim) basierend auf den 4x4-Eingangsvertices berechnet. Eine Implementierung arbeitet nach folgender Codefolge:

             {struct GridPrim
           {
             PrimLeafDesc leafDesc; // 4B
             uint32_t primIndex; // 4 B
             float3         vertex[4]; // 48B
             struct {
                 exp: 7; // shared exponent
                 disp_x: 5; 
                 disp_y: 5;
                 disp_z: 5;
             } disp_mag [16]; // 44 B
            }; // 64 Bytes insgesamt

Bei einer Implementierung verbrauchen diese Operationen 100 Bytes: 18 Bits von PrimLeafDesc können reserviert werden, um einzelne Dreiecke zu deaktivieren, z. B. eine Bitmaske von (in oben nach unten, Links-Rechts-Reihenfolge) 000000000100000000b würde das in 74 gezeigte hervorgehobene Dreieck 7401 deaktivieren.

Implizite Dreiecke können entweder 3x3 Vierecke (4x4 Vertices) oder mehr Dreiecke sein. Viele dieser impliziten Dreiecke und Vierecke sind zu einem Netz zusammengenäht. Die Maske gibt uns an, ob wir das Dreieck schneiden wollen. Wird ein Loch erreicht, Deaktivieren der einzelnen Dreiecke pro 4x4-Raster. Dies ermöglicht eine höhere Genauigkeit und einen deutlich reduzierten Speicherverbrauch: ~ 5,5 Byte/Dreieck, was eine sehr kompakte Darstellung ist. Im Vergleich dazu nimmt jedes Dreieck, falls ein lineares Array mit voller Genauigkeit gespeichert wird, 48 und 64 Bytes in Anspruch.

Wie in 75 veranschaulicht, tesseliert ein HardwareTesselator 7550 Patches zu Dreiecken in 4x4 Einheiten und speichert sie in einem Speicher, so dass BVHs über ihnen aufgebaut werden können und sie strahlenverfolgt werden können. In dieser Ausführungsform ist der Hardwaretesselator 7550 modifiziert, um verlustbehaftete versetzte Gitter-Primitive direkt zu unterstützen. Anstatt einzelne Dreiecke zu erzeugen und sie an die Rasterisierungseinheit weiterzuleiten, kann die Hardwaretessellationseinheit 7550 direkt verlustbehaftete Gitter-Primitive erzeugen und sie in einem Cache (z. B. einem LO/L1-Cache, einem dedizierten Strahlverfolgungs-Cache, einem gemeinsam genutzten Cache usw.), einem lokalen Speicher (z. B. einem lokalen Scratchpad-Speicher) und/oder Systemspeicher speichern.

Eine Erweiterung der Hardware-BVH-Traversiereinheit 7550, die ein verlustbehaftetes Gitter-Primitiv als Eingabe nimmt und im Flug Begrenzungsrahmen für Teilmengen implizit referenzierter Dreiecke/Vierecke extrahiert. In dem in 76 gezeigten Beispiel werden neun Begrenzungsrahmen 7601A bis 7601-1, eine für jedes Viereck, aus dem verlustbehafteten Gitter extrahiert und als ein spezieller neun breiter BVH-Knoten an die Hardware-BVH-Traversiereinheit 7550 weitergeleitet, um eine Strahlboxüberschneidung durchzuführen.

Die Prüfung aller 18 Dreiecke nacheinander ist sehr aufwendig. Unter Bezugnahme auf 77 extrahiert eine Ausführungsform einen Begrenzungsrahmen 7601A bis 76011 für jedes Viereck. Die neun in 77 gezeigten Begrenzungsrahmen 7601A bis 7601I entsprechen den neun in 76 gezeigten Vierecken 7601A bis 7601I, obwohl dies nur ein Beispiel ist; eine beliebige Anzahl von Dreiecken könnte extrahiert werden. Wenn eine Teilmenge von Dreiecken gelesen und Begrenzungsrahmen berechnet werden, wird ein N-breiter BVH-Knoten 7700 erzeugt - ein Kind-Knoten 7601A-I für jedes Viereck. Diese Struktur wird dann an die Hardware-Traversiereinheit 7710 weitergeleitet, die Strahlen durch die neu konstruierte BVH verlaufen lässt. Somit wird in dieser Ausführungsform das Gitter-Primitiv als ein impliziter BVH-Knoten verwendet, aus dem die Begrenzungskästen bestimmt werden können. Wenn ein Begrenzungsrahmen erzeugt wird, ist bekannt, dass er zwei Dreiecke enthält. Wenn die Hardware-Traversiereinheit 7710 bestimmt, dass ein Strahl einen der Begrenzungsrahmen 7601A-I durchläuft, wird dieselbe Struktur zu dem Strahl-Dreieck-Intersektor 7715 geleitet, um zu bestimmen, welches Objekt/welches Dreieck innerhalb des Begrenzungsrahmens getroffen wurde. Um zu bestimmen, ob ein Begrenzungsrahmen getroffen wurde, werden die Strahldaten, die einen Strahlenursprung und eine Strahlenrichtung umfassen, in Anbetracht der minimalen und maximalen Koordinatenwerte jedes Begrenzungsrahmens 7601A-I ausgewertet. Falls ein Begrenzungsrahmen von dem Strahl getroffen wurde, führt der Strahlen-Dreieck-Intersektor 7715 Schnitttests durch, indem die Strahldaten angesichts der Dreieckskoordinaten für Dreiecke, die in dem Begrenzungsrahmen enthalten sind, ausgewertet werden.

In einer Ausführungsform der Erfindung werden diese Techniken als ein Voraussonderungsschritt für die Strahl-Dreieck-Traversier- 7710 und Kreuzungseinheiten 7715 verwendet. Der Schnitttest ist wesentlich kostengünstiger, wenn nur mit der BVH-Knotenverarbeitungseinheit auf die Dreiecke geschlossen werden kann. Für jeden geschnittenen Begrenzungsrahmen 7601A-I werden die zwei jeweiligen Dreiecke an die Strahlverfolgungsdreieck/Viereck-Schnitteinheit 7715 weitergeleitet, um die Strahldreieck-Schnitttests durchzuführen.

Die oben beschriebenen Gitter-Primitiv- und impliziten BVH-Knoten-Verarbeitungstechniken können innerhalb einer beliebigen der hier beschriebenen Traversier-/Kreuzungseinheiten (wie etwa der unten beschriebenen Strahlen-/Box-Traversiereinheit 8930) integriert oder als ein Vorverarbeitungsschritt zu diesen verwendet werden.

In einer Ausführungsform werden Erweiterungen einer solchen verlustbehafteten 4x4-Gitter-Primitive verwendet, um eine Bewegungsunschärfeverarbeitung mit zwei Zeitschritten zu unterstützen. Ein Beispiel ist in der folgenden Codefolge vorgesehen:

       struct GridPrimMB
       {
        PrimLeafDesc leafDesc; // 4 B
        uint32_t primIndex; // 4 B
        float3 vertex_time0[4]; // 48 B
        float3 vertex_time1[4]; // 48 B 

        // total 32 bytes up to here 

        Struct {
         exp: 6; ///shared exponent
         disp_x: 6;
         disp_y: 6;
         disp_z: 6;
         } disp_mag_time0[16],disp_mag_time1[16]; // 2x48B

        }; // 8 + 96 + 96 bytes total

Bewegungsunschärfeoperationen sind analog zum Simulieren der Verschlusszeit in einer Kamera. Um diesen Effekt ray-verfolgen zu können, gibt es von t0 nach t1 zwei Darstellungen eines Dreiecks, eine für t0 und eine für t1. In einer Ausführungsform wird zwischen ihnen eine Interpolation durchgeführt (z. B. Interpolieren der Primitivdarstellungen zu jedem der beiden Zeitpunkte linear bei 0,5).

Beschleunigungsstrukturen wie Bounding Volume Hierarchies (BVHs) und k-d Bäume unterliegen darin, dass sie sowohl Zeit als auch Speicher benötigen, die aufgebaut und gespeichert werden müssen. Eine Möglichkeit, diesen Overhead zu reduzieren, besteht darin, irgendeine Art von Komprimierung und/oder Quantisierung der Beschleunigungsdatenstruktur einzusetzen, was besonders gut für BVHs funktioniert, die natürlich zu einer konservativen inkrementellen Codierung führen. Oben kann dies die Größe der Beschleunigungsstruktur, die häufig die Größe von BVH-Knoten halbiert, signifikant reduzieren. Auf der Unterseite entsteht beim Komprimieren der BVH-Knoten auch Overhead, der in unterschiedliche Kategorien fallen kann. Erstens gibt es die offensichtlichen Kosten des Dekomprimierens jedes BVH-Knotens während des Traversierens; zweitens, insbesondere für hierarchische Codier Schemata, die Notwendigkeit, Eltern Informationen zu verfolgen, die Stapel Operationen geringfügig kompliziert; und drittens, konservatives Quantisieren der Grenzen bedeutet, dass die Begrenzungskästen etwas weniger eng als unkomprimierte sind, wodurch eine messbare Zunahme der Anzahl von Knoten und Primitiven ausgelöst wird, die durchlaufen bzw. geschnitten werden müssen.

Lokale Quantisierung kann durchgeführt werden, um die Größe der BVH zu reduzieren. Ein n-breiter BVH-Knoten enthält die achsenausgerichteten Begrenzungsrahmen (AABBs) seiner „n“ Kinder in Single-Präzisions-Gleitkomma-Format. Lokale Quantisierung drückt die „n“ Kinder-AABBs relativ zu dem AABB des Elternteils aus und speichert diesen Wert in einem quantisierten z. B.· 8-Bit-Format, wodurch die Größe des BVH-Knotens reduziert wird.

Die lokale Quantisierung des gesamten BVH führt mehrere Overhead Faktoren ein, da (a) die dequantisierten AABBs gröber als die ursprünglichen Gleitkomma AABBs mit einfacher Genauigkeit sind, wodurch zusätzliche Traversierungs- und Schnitt schritte für jeden Strahl eingeführt werden und (b) die Dequantisierung Operation selbst teuer ist, was jeden Strahl Traversierung schritt addiert und Overhead. Komprimierte BVHs werden aufgrund dieser Nachteile nur in speziellen Anwendungsszenarien verwendet und nicht weit verbreitet.

Eine Ausführungsform der Erfindung setzt Techniken zum Komprimieren von Blattknoten für Haarprimitive in einer Bounding-Volumen-Hierarchie ein, wie in der gleichzeitig anhängigen Anmeldung mit dem Titel „Vorrichtung and Method for Compressing Leaf Nodes of Bounding Volume Hierarchies“, Seriennummer 16/236,185 , eingereicht am 28. Dezember 2018, die dem Anmelder der vorliegenden Anmeldung zugeordnet ist, beschrieben ist. Insbesondere werden, wie in der gleichzeitig anhängigen Anmeldung beschrieben, mehrere Gruppen orientierter Primitive zusammen mit einem Eltern-Begrenzungsrahmen gespeichert, wodurch eine Kind-Zeigerspeicherung in dem Blattknoten eliminiert wird. Ein orientierter Begrenzungsrahmen wird dann für jedes Primitiv unter Verwendung von 16-Bit-Koordinaten gespeichert, die bezüglich einer Ecke der Elternbox quantisiert sind. Schließlich wird eine quantisierte Normale für jede Primitivgruppe gespeichert, um die Orientierung anzugeben. Dieser Ansatz kann zu einer signifikanten Reduzierung der Bandbreite und des Speicherplatzabdrucks für BVH-Haarprimitive führen.

In einigen Ausführungsformen werden BVH-Knoten komprimiert (z. B. für eine 8-breite BVH), indem der Eltern-Begrenzungsrahmen gespeichert wird und N Kind-Begrenzungsrahmen (z. B. 8 Kinder) relativ zu diesem Eltern-Begrenzungsrahmen unter Verwendung einer geringeren Genauigkeit codiert werden. Ein Nachteil des Anwendens dieser Idee auf jeden Knoten eines BVH besteht darin, dass an jedem Knoten etwas Dekomprimierungs-Overhead eingeführt wird, wenn Strahlen durch diese Struktur durchlaufen werden, was die Leistungsfähigkeit reduzieren kann.

Um dieses Problem zu adressieren, verwendet eine Ausführungsform der Erfindung komprimierte Knoten nur auf der untersten Ebene des BVH. Folglich können die höheren BVH-Pegel, die nicht komprimiert sind, bei optimaler Leistungsfähigkeit genutzt werden (d. h. sie werden häufig berührt, weil sie groß sind, aber sehr wenige von ihnen vorhanden sind), und die Komprimierung auf den niedrigeren/niedrigsten Pegeln ist auch sehr effektiv, da die meisten Daten der BVH in den niedrigsten Pegeln sind.

Zusätzlich wird in einer Ausführungsform Quantisierung auch für BVH-Knoten angewendet, die orientierte Begrenzungsrahmen speichern. Wie unten besprochen, sind die Operationen etwas komplizierter als für achsausgerichtete Begrenzungsrahmen. Bei einer Implementierung wird die Verwendung von komprimierten BVH-Knoten mit orientierten Begrenzungsrahmen mit der Verwendung der komprimierten Knoten nur auf der niedrigsten Ebene (oder niedrigeren Ebenen) des BVH kombiniert.

Somit verbessert sich eine Ausführungsform an vollständig komprimierten BVHs durch Einführen einer einzelnen dedizierten Schicht komprimierter Blattknoten, während reguläre, unkomprimierte BVH-Knoten für Innenknoten verwendet werden. Eine Motivation hinter diesem Ansatz besteht darin, dass fast alle Einsparungen an Komprimierung von den niedrigsten Stufen einer BVH (die sich insbesondere für 4-breite und 8-breite BVH auf die überwiegende Mehrzahl aller Knoten ausmachen) stammen, während der größte Teil des Overhead von Innenknoten stammt. Folglich liefert das Einführen einer einzigen Schicht dedizierter „komprimierter Blattknoten“ nahezu die gleichen (und in manchen Fällen noch bessere) Komprimierungsgewinne wie eine vollständig komprimierte BVH, während nahezu die gleiche Traversierungsleistungsfähigkeit wie eine unkomprimierte beibehalten wird.

80 veranschaulicht eine beispielhafte Strahlverfolgungsengine 8000, die die hierin beschriebenen Blattknotenkomprimierungs- und -dekomprimierungsoperationen durchführt. In einer Ausführungsform umfasst die Strahlverfolgungsengine 8000 eine Schaltungsanordnung eines oder mehrerer der oben beschriebenen Strahlverfolgungskerne. Alternativ dazu kann die Strahlverfolgungsengine 8000 auf den Kernen der CPU oder auf anderen Typen von Grafikkernen (z. B. GFX-Kerne, Tensorkerne usw.) implementiert sein.

In einer Ausführungsform erzeugt ein Strahlerzeuger 8002 Strahlen, die eine Traversier-/Schnitteinheit 8003 durch eine Szene verfolgt, die mehrere Eingangsprimitive 8006 umfasst. Zum Beispiel kann eine App, wie etwa ein Virtual-Reality-Spiel, Ströme von Befehlen erzeugen, aus denen die Eingabeprimitive 8006 erzeugt werden. Die Durchlauf-/Schnitteinheit 8003 durchläuft die Strahlen durch einen BVH 8005, der durch einen BVH-Builder 8007 erzeugt wird, und identifiziert Trefferpunkte, an denen die Strahlen eines oder mehrere der Primitive 8006 schneiden. Obwohl dies als eine einzige Einheit veranschaulicht ist, kann die Durchlauf-/Kreuzungseinheit 8003 eine Durchlaufeinheit umfassen, die mit einer eindeutigen Kreuzungseinheit gekoppelt ist. Diese Einheiten können in einer Schaltungsanordnung, Software/Befehlen, die durch die GPU oder CPU ausgeführt werden, oder einer beliebigen Kombination davon implementiert sein.

In einer Ausführungsform weist die BVH-Verarbeitungsschaltungsanordnung/Logik 8004 einen BVH-Builder 8007 auf, der den BVH 8005, wie hier beschrieben, basierend auf den räumlichen Beziehungen zwischen Primitiven 8006 in der Szene erzeugt. Außerdem weist die BVH-Verarbeitungsschaltungsanordnung/Logik 8004 einen BVH-Komprimierer 8009 und einen BVH-Dekomprimierer 8009 zum Komprimieren bzw. Dekomprimieren der Blattknoten auf, wie hier beschrieben. Die nachfolgende Beschreibung soll sich zur Veranschaulichung auf 8-breite BVHs (BVH8) konzentrieren.

Wie in 81 veranschaulicht, enthält eine Ausführungsform eines einzelnen 8-breiten BVH-Knotens 8100A 8 Begrenzungsrahmen 8101-8108 und 8 (64bit) Kinderzeiger/verweise 8110, die auf die Begrenzungsrahmen/Blattdaten 8101-8108 zeigen. In einer Ausführungsform führt der BVH-Komprimierer 8025 eine Codierung durch, bei der die 8 Kind-Begrenzungsrahmen 8101A-8108A relativ zu dem Eltern-Begrenzungsrahmen 8100A ausgedrückt und zu einheitlichen 8-Bit-Werten quantisiert werden, die als Begrenzungsrahmen-Blattdaten 8101B-8108B gezeigt sind. Der quantisierte 8-breite BVH-, QBVH8-Knoten 8100B, wird durch BVH-Komprimierung 8125 unter Verwendung eines Start- und Erweiterungswerts codiert, der als zwei 3-dimensionale Einzelpräzisionsvektoren (2 x 12 Bytes) gespeichert ist. Die acht quantisierten Kind-Begrenzungsrahmen 8101B-8108B werden als 2 mal 8 Bytes für die Unter- und Obergrenzen der Begrenzungsrahmen pro Dimension gespeichert. Es wird angemerkt, dass sich dieses Layout von existierenden Implementierungen unterscheidet, da das Ausmaß in voller Genauigkeit gespeichert wird, was im Allgemeinen engere Grenzen bereitstellt, aber mehr Platz benötigt.

In einer Ausführungsform dekomprimiert der BVH-Dekomprimierer 8026 den QBVH8-Knoten 8100B wie folgt. Die dekomprimierten Untergrenzen in Dimension i können durch QBVH8.starti+(byte-to-float)QBVH8 .lower_i□QBVH8.extend_i berechnet werden, was auf der CPU 4099 fünf Befehle pro Dimension und Box erfordert: 2 Lasten (start,extend), Byte-to-int load + Aufwärtsumwandlung, Int-to-Floating-Umwandlung und eine Multiplikations-Addition. In einer Ausführungsform wird die Dekomprimierung für alle 8 quantisierten Kind-Begrenzungsrahmen 8101B-8108B parallel unter Verwendung von SIMD-Anweisungen durchgeführt, was einen Overhead von etwa 10 Anweisungen zu dem Ray-Knoten-Schnitttest hinzufügt, was ihn mindestens mehr als doppelt so teuer macht wie im unkomprimierten Standardknotenfall. In einer Ausführungsform werden diese Anweisungen auf den Kernen der CPU 4099 ausgeführt. Alternativ dazu wird ein vergleichbarer Satz von Anweisungen durch die Strahlverfolgungskerne 4050 ausgeführt.

Ohne Zeiger benötigt ein QBVH8-Knoten 72 Bytes, während ein unkomprimierter BVH8-Knoten 192 Bytes benötigt, was zu einem Reduktionsfaktor von 2,66x führt. Mit 8 (64bit) Zeigern reduziert sich der Reduktionsfaktor auf 1,88x, was es erforderlich macht, die Speicherkosten für die Handhabung von Blattzeigern zu adressieren.

In einer Ausführungsform, wenn nur die Blattschicht der BVH8-Knoten in QBVH8-Knoten komprimiert wird, beziehen sich alle Kinderzeiger der 8 Kinder 8101-8108 nur auf Blatt-Primitivdaten. Bei einer Implementierung wird diese Tatsache ausgenutzt, indem alle referenzierten Primitivdaten direkt nach dem QBVH8-Knoten 8100B selbst gespeichert werden, wie in 81 veranschaulicht ist. Dies ermöglicht es, die vollen 64bit-Kind-Zeiger 8110 der QBVH8 auf nur 8-Bit-Versätze 8122 zu reduzieren. Falls die Primitivdaten eine feste Größe aufweisen, werden In einer Ausführungsform die Offsets 8122 vollständig übersprungen, da sie direkt aus dem Index des geschnittenen Begrenzungsrahmens und dem Zeiger auf den QBVH8-Knoten 8100B selbst berechnet werden können.

Bei Verwendung eines Top-down BVH8-Builders erfordert das Komprimieren nur der BVH8-Blattebene nur geringe Modifikationen des Builderprozesses. In einer Ausführungsform werden diese Aufbaumodifikationen in dem BVH-Builder 8007 implementiert. Während der rekursiven Builderphase verfolgt der BVH-Builder 8007, ob die aktuelle Anzahl an Primitiven unter einer gewissen Schwelle liegt. Bei einer Implementierung ist N x M die Schwelle, wobei N sich auf die Breite des BVH bezieht und M die Anzahl an Primitiven innerhalb eines BVH-Blatts ist. Für einen BVH8-Knoten und zum Beispiel vier Dreiecke pro Blatt ist die Schwelle 32. Daher wird die BVH-Verarbeitungsschaltungsanordnung/-logik 8004 für alle Unterbäume mit weniger als 32 Primitiven in einen speziellen Codepfad eintreten, wo sie den oberflächenheuristischen (SAH)-basierten Aufspaltungsprozess fortsetzen wird, aber einen einzigen QBVH8-Knoten 8100B erzeugt. Wenn der QBVH8-Knoten 8100B schließlich erstellt wird, sammelt der BVH-Komprimierer 8009 dann alle referenzierten Primitivdaten und kopiert sie unmittelbar hinter dem QBVH8-Knoten.

Die tatsächliche BVH8-Traversierung, die durch den Strahlverfolgungskern 8150 oder die CPU 8199 durchgeführt wird, wird von der Blattstufen-Komprimierung nur geringfügig beeinflusst. Im Wesentlichen wird der QBVH8-Knoten 8100B auf Blattebene als erweiterter Blatttyp behandelt (er ist z. B. als Blatt markiert). Dies bedeutet, dass der reguläre BVH8-Top-Down-Durchlauf fortgesetzt wird, bis ein QBVH-Knoten 8100B erreicht ist. An diesem Punkt wird ein einziger Strahl-QBVH-Knoten-Schnittpunkt ausgeführt und für alle seine geschnittenen Kinder 8101B-8108B wird der jeweilige Blattzeiger rekonstruiert und reguläre Strahl-Primitiv-Schnittpunkte werden ausgeführt.

Eine Ausführungsform des Komprimierungsschemas auf Blattebene ermöglicht sogar eine verlustfreie Komprimierung der tatsächlichen Primitivblattdaten durch Extrahieren gemeinsamer Merkmale. Dreiecke innerhalb eines BVH(CLBVH)-Knotens mit komprimiertem Blatt teilen sich zum Beispiel sehr wahrscheinlich Vertices/Vertexindizes und Eigenschaften wie die gleichen objectID. Durch das Speichern dieser gemeinsam genutzten Eigenschaften nur einmal pro CLBVH-Knoten und das Verwenden kleiner lokaler Byte-großer Indizes in den Primitiven wird der Speicherverbrauch weiter reduziert.

In einer Ausführungsform werden die Techniken zum Nutzen gemeinsamer räumlich kohärenter geometrischer Merkmale innerhalb eines BVH-Blatts auch für andere komplexere Primitivtypen verwendet. Primitive wie Haarsegmente teilen sich wahrscheinlich eine gemeinsame Richtung pro -BVH-Blatt. In einer Ausführungsform implementiert der BVH-Komprimierer 8009 ein Komprimierungsschema, das diese gemeinsame Richtungseigenschaft berücksichtigt, um orientierte Begrenzungsrahmen (OBBs) effizient zu komprimieren, die sich als nützlich für das Begrenzen langer diagonaler Primitivtypen gezeigt haben.

Die hier beschriebenen komprimierten BVHs auf Blattebene führen BVH-Knotenquantisierung nur auf der niedrigsten BVH-Ebene ein und ermöglichen daher zusätzliche Speicherreduktionsoptimierungen, während die Traversierleistung einer unkomprimierten BVH bewahrt wird. Da nur BVH-Knoten auf der niedrigsten Ebene quantisiert werden, zeigen alle ihre Kinder auf Blattdaten 8101B-8108B, die zusammenhängend in einem Speicherblock oder einer oder mehreren Cache-Zeile(n) 8098 gespeichert sein können.

Die Idee kann auch auf Hierarchien angewendet werden, die orientierte Begrenzungsrahmen (OBB) verwenden, die typischerweise zur Beschleunigung des Renderns von Haarprimitiven verwendet werden. Um eine bestimmte Ausführungsform zu veranschaulichen, werden die Speicherreduzierungen in einem typischen Fall einer 8-breiten STANDARD-BVH über Dreiecke ausgewertet.

Das Layout eines 8-breiten BVH-Knotens 8100 ist in folgender Kernreihenfolge dargestellt:

      struct BVH8Node {
           float lowerX[8], upperX[8];
           // 8 x lower and upper bounds in the X dimension
           float lowerY[8], upperY[8];
           // 8 x lower and upper bounds in the Y dimension
           float lowerZ[8], upperZ[8];
           // 8 x lower and upper bounds in the Z dimension
           void *ptr[8];
           // 8 x 64bit pointers to the 8 child nodes or leaf data
     };

und benötigt 276 Byte Speicher. Das Layout eines 8-breiten quantisierten Standardknotens kann definiert sein als:

      struct QBVH8Node {
           Vec3f start, scale;
            char lowerX[8], upperX[8];
           // 8 x byte quantized lower/upper bounds in the X dimension
            char lowerY[8], upperY[8];
           // 8 x byte quantized lower/upper bounds in the Y dimension
            char lowerZ[8], upperZ[8];
           // 8 x byte quantized lower/upper bounds in the Z dimension
           void *ptr[8];
           // 8 x 64bit pointers to the 8 child nodes or leaf data
     };

und benötigt 136 Bytes.

Da nur quantisierte BVH-Knoten auf Blattebene verwendet werden, zeigen alle Kinderzeiger tatsächlich auf Blattdaten 8101A-8108A. In einer Ausführungsform werden durch Speichern des quantisierten Knotens 8100B und aller Blattdaten 8101B-8108B dessen Kinderzeiger in einem einzigen kontinuierlichen Block des Speichers 8098 entfernt, auf die 8 Kinderzeiger in dem quantisierten BVH-Knoten 8100 B. Das Speichern der Kinderzeiger reduziert das quantisierte Knoten-Layout auf:

      struct QBVH8NodeLeaf {
      Vec3f start, scale;
           // start position, extend vector of the parent AABB
            char lowerX[8], upperX[8];
           // 8 x byte quantized lower and upper bounds in the X dimension
            char lowerY[8], upperY[8];
           // 8 x byte quantized lower and upper bounds in the Y dimension
            char lowerZ[8], upperZ[8];
           // 8 x byte quantized lower and upper bounds in the Z dimension
      };

der nur 72 Byte benötigt. Aufgrund des kontinuierlichen Layouts in dem Speicher/Cache 8098 kann der Kinderzeiger des i-ten Kindes nun einfach berechnet werden durch: childPtr(i) = addr(QBVH8NodeLeaf) + sizeof(QBVH8NodeLeaf) + i * sizeof(LeafDataType).

Da die Knoten auf niedrigster Ebene des BVH mehr als die Hälfte der gesamten Größe des BVH ausmachen, stellt die hier beschriebene Nur-Blatt-Nur-Komprimierung eine Reduktion auf 0,5 + 0,5 * 72/256 = 0,64x der ursprünglichen Größe bereit.

Außerdem treten der Overhead, gröbere Grenzen aufzuweisen, und die Kosten des Dekomprimierens quantisierter BVH-Knoten selbst nur auf der BVH-Blattebene auf (im Gegensatz zu allen Ebenen, wenn die gesamte BVH quantisiert wird). Somit wird der oft recht signifikante Traversier- und Kreuzungsaufwand aufgrund gröberer Grenzen (eingeführt durch Quantisierung) weitgehend vermieden.

Ein weiterer Vorteil der Ausführungsformen der Erfindung ist eine verbesserte Hardware- und Software-Vorabrufeffizienz. Dies resultiert daraus, dass alle Blattdaten in einem relativ kleinen kontinuierlichen Block von Speicher- oder Cache-Zeile(n) gespeichert sind.

Da die Geometrie auf der BVH-Blattebene räumlich kohärent ist, ist es sehr wahrscheinlich, dass alle Primitive, die durch einen QBVH8NodeLeaf-Knoten referenziert werden, gemeinsame Eigenschaften/Merkmale teilen, wie etwa objectID, einen oder mehrere Vertices usw. Folglich reduziert eine Ausführungsform der Erfindung die Speicherung weiter durch Entfernen primitiver Datenduplizierung. Zum Beispiel können ein Primitiv und assoziierte Daten nur einmal pro QBVH8NodeLeaf Knoten gespeichert werden, wodurch der Speicherverbrauch für Blattdaten weiter reduziert wird.

Die effektive Begrenzung von Haarprimitiven wird im Folgenden als ein Beispiel für signifikante Gedächtnisreduktionen beschrieben, die durch Ausnutzung gemeinsamer Geometrieeigenschaften auf BVH-Blattebene realisiert werden. Um ein Haargrundelement, bei dem es sich um eine lange aber dünne Struktur handelt, die im Raum orientiert ist, genau zu begrenzen, besteht ein wohlbekannter Ansatz darin, einen orientierten Begrenzungsrahmen zu berechnen, um die Geometrie eng zu begrenzen. Zunächst wird ein Koordinatenraum berechnet, der auf die Haarrichtung ausgerichtet ist. Beispielsweise kann bestimmt werden, dass die z-Achse in die Haarrichtung zeigt, während die x- und y-Achse senkrecht auf der z-Achse stehen. Mit diesem orientierten Raum kann nun ein Standard-AABB verwendet werden, um das Haargrundelement fest zu binden. Das Schneiden eines Strahls mit einer solchen orientierten Grenze erfordert zunächst das Transformieren des Strahls in den orientierten Raum und dann das Durchführen eines Standard-Strahl/Box-Schnitttests.

Problematisch bei diesem Ansatz ist dessen Speicherverbrauch. Die Transformation in den orientierten Raum erfordert 9 Gleitkommawerte, während das Speichern des Begrenzungsrahmens zusätzliche 6 Gleitkommawerte erfordert, was insgesamt 60 Bytes ergibt.

In einer Ausführungsform der Erfindung komprimiert der BVH-Komprimierer 8025 diesen orientierten Raum und diesen Begrenzungsrahmen für mehrere Haarprimitive, die räumlich nahe beieinander liegen. Diese komprimierten Grenzen können dann innerhalb der komprimierten Blattebene gespeichert werden, um die im Blatt gespeicherten Haarprimitive fest zu binden. Zur Komprimierung der orientierten Grenzen wird in einer Ausführungsform folgender Ansatz verwendet. Der orientierte Raum kann durch die normierten Vektoren y und z ausgedrückt werden, die orthogonal zueinander sind. Die Transformation eines Punktes p in diesen Raum funktioniert durch Projektion auf diese Achsen: EPMATHMARKEREP

\begin{matrix} = (,) \\ y = (y,) \\ z = (z,) \end{matrix}

Da die Vektoren_y und_z normiert werden, liegen ihre Komponenten im Bereich [-1,1]. Diese Vektoren werden also mit 8 Bit vorzeichenbehafteten Festkommazahlen quantisiert und nicht mit 8 Bit vorzeichenbehafteten ganzen Zahlen und konstantem Maßstab. Auf diese Weise werden quantisierte',_y' und_y' erzeugt. Dieser Ansatz reduziert den zur Codierung des orientierten Raumes benötigten Speicher von 36 Byte (9 Gleitkommawerte) auf nur 9 Byte (9 Festkommazahlen mit je 1 Byte).

In einer Ausführungsform wird der Speicherverbrauch des orientierten Raums weiter reduziert, indem die Tatsache ausgenutzt wird, dass alle Vektoren orthogonal zueinander sind. Somit werden nur zwei Vektoren (z. B.,_y' und_z') gespeichert und' =(_y',_z') kann bestimmt werden, was die erforderliche Speicherung weiter auf nur sechs Bytes reduziert.

Übrig bleibt die Quantisierung des AABB innerhalb des quantisierten orientierten Raums. Problematisch hierbei ist, dass das Projizieren eines Punktes p auf eine komprimierte Koordinatenachse dieses Raumes (z. B. durch Berechnen (',)) Werte eines potentiell großen Bereichs liefert (da Werte p typischerweise als Gleitkommazahlen codiert sind). Aus diesem Grund würden Gleitkommazahlen zum Codieren der Grenzen verwendet werden, wodurch potentielle Einsparungen reduziert werden.

Zur Lösung dieses Problems transformiert eine Ausführungsform der Erfindung zunächst das Mehrfachhaar-Primitiv in einen Raum, wo seine Koordinaten im Bereich [0, 1/√3] liegen. Dies kann durch Bestimmen des weltraumachsenausgerichteten Begrenzungsrahmens b der mehreren Haarprimitive und Verwenden einer Transformation T erfolgen, die zuerst um b.lower nach links translatiert und dann um 1/max (..,...) in jeder Koordinate skaliert:

T (p) = \frac{1}{\sqrt{3}} (p - b . l o w e r) /max (b . s i z e . x, b . s i z e . y, b . s i z e . z)

Eine Ausführungsform stellt sicher, dass die Geometrie nach dieser Transformation im Bereich [0, 1/√3] verbleibt, da dann eine Projektion eines transformierten Punktes auf einen quantisierten Vektor p', p_y' oder p_z' im Bereich [- 1,1] verbleibt. Das heißt, die AABB der Kurvengeometrie kann bei Transformation mit T quantisiert und anschließend in den quantisierten orientierten Raum transformiert werden. In einer Ausführungsform wird 8-Bit-Festkomma-Arithmetik mit Vorzeichen verwendet. Aus Genauigkeitsgründen können jedoch 16-Bitvorzeichenbehaftete Festkommazahlen verwendet werden (z. B. codiert unter Verwendung von 16-Bit-vorzeichenbehafteten ganzen Zahlen und einer konstanten Skala). Dies reduziert den Speicherbedarf zum Codieren des achsausgerichteten Begrenzungsrahmens von 24 Bytes (6 Gleitkommawerten) auf nur 12 Bytes (6 Wörter) plus dem Offset b.lower (3 Gleitkomma) und der Skala (1 Gleitkomma), die für mehrere Haarprimitive gemeinsam genutzt werden.

Wenn zum Beispiel 8 Haarprimitive zu binden sind, reduziert diese Ausführungsform den Speicherverbrauch von 8*60 Bytes = 480 Bytes auf nur 8*(6+12)+3*4+4 = 160 Bytes, was eine Reduktion um das 3fache ist. Das Schneiden eines Strahls mit diesen quantisierten orientierten Grenzen funktioniert, indem zuerst der Strahl unter Verwendung der Transformation T transformiert wird, dann der Strahl unter Verwendung quantisierter', y ' und z ' projiziert wird. Schließlich wird der Strahl mit dem quantisierten AABB geschnitten.

Der oben beschriebene Ansatz an Fettblättern bietet eine Möglichkeit zu noch mehr Komprimierung. Unter der Annahme, dass es einen impliziten einzelnen Float3-Zeiger in dem fetten BVH-Blatt gibt, der auf die gemeinsam genutzten Vertexdaten mehrerer benachbarter GridPrims zeigt, kann der Vertex in jedem Gitter-Primitiv indirekt durch bytegroße Indizes („Vertex_Index_*“) adressiert werden, wodurch Vertex gemeinsam genutzt wird. In 78 werden die Vertices 7801-7802 gemeinsam genutzt - und in voller Genauigkeit gespeichert. In dieser Ausführungsform werden die gemeinsam genutzten Vertices 7801-7802 nur einmal gespeichert und Indizes werden gespeichert, die auf ein Array zeigen, das die eindeutigen Vertices enthält. Anstelle von 48 Bytes werden somit nur 4 Bytes pro Zeitstempel gespeichert. Die Indizes in der folgenden Codefolge werden zur Identifizierung der gemeinsamen Vertices verwendet.

            struct GridPrimMBIndexed
            {
                 PrimLeafDesc leafDesc; // 4B
                 uint32_t primIndex; // 4B
                 uint8_t tex_index_time 0[4]; // 4B
                 uint8_t vertex_index_time1[4]; // 4B
            // total 16 bytes up to here
                 struct {
                  exp: 5; /// shared exponent
                  disp_x : 5;
                  disp_y : 5;
                  disp_z : 5;
                 } disp_mag_time0[16],disp_mag_time1[16]; // 80
                bytes 

             }; // 96 bytes total

In einer Ausführungsform werden gemeinsam genutzte Kanten von Primitiven nur einmal evaluiert, um Verarbeitungsressourcen zu sparen. In 79 wird zum Beispiel angenommen, dass ein Begrenzungsrahmen aus den hervorgehobenen Vierecken besteht. Anstatt alle Dreiecke einzeln zu schneiden, führt eine Ausführungsform der Erfindung Strahlkantenberechnungen einmal für jede der drei gemeinsam genutzten Kanten durch. Die Ergebnisse der drei Strahlenkantenberechnungen werden somit über die vier Dreiecke geteilt (d. h. es wird nur eine Strahlenkantenberechnung für jede gemeinsam genutzte Kante durchgeführt). Außerdem werden in einer Ausführungsform die Ergebnisse in einem On-Chip-Speicher (z. B. einem Scratch-Speicher/Cache, auf den die Intersektoreinheit direkt zugreifen kann) gespeichert.

ATOMIK FÜR GRAPHIKEN UND DATENSTRUKTUREN

Ein „Atom“ ist ein Satz von Operationen, die als eine Einheit abgeschlossen werden müssen. Bestimmte Atomik wäre für die Grafikverarbeitungsleistung vorteilhaft, insbesondere wenn Rechen-Shader ausgeführt werden. Eine Ausführungsform der Erfindung umfasst eine Vielfalt neuer Atomika, um die Grafikverarbeitungsleistung zu verbessern, einschließlich:

• Atomika, die Klemmen
• „z-getestete“ Atomschreibung
• „z-gestetete“ Atomakkumulation
• Atomik für Ringpuffer

I. Atomics zum Klemmen

Eine Ausführungsform eines Klemmatoms spezifiziert ein Ziel, einen Typwert und minimale und maximale Klemmwerte. Ein Klemmatom kann beispielsweise wie folgt ausgebildet sein:

I n t e r l o c k e d A d d C l a m p (Z i e l, T y p w e r t, T y p m i n, T y p m a x)

Der obige Klemmvorgang fügt atomar einen Wert zum Ziel hinzu und klemmt dann auf die spezifizierten Minimal- und Maximalwerte (z. B. Einstellen auf das Maximum für beliebige Werte oberhalb des Maximums und Einstellen auf das Minimum für beliebige Werte unterhalb des Minimums).

Klemmatomwerte können 32 Bit, 64 Bit oder eine beliebige andere Datengröße sein. Darüber hinaus können Klemmatomik an verschiedenen Datentypen arbeiten, einschließlich unter anderem uint, float, 2xfp16, float2 und 4xfp16.

II. „Z-getestete“ Streuschreibvorgänge

Z-getestete Streuschreibvorgänge können für eine Vielzahl von Anwendungen verwendet werden, einschließlich zum Beispiel:

• gestreutes Würfelkartenrendern/Voxelisieren (z. B. für Umgebungssonden);
• gestreute unperfekte reflektierende Schattenkarten (RSMs) (ähnlich unperfekten Schattenkarten mit Ausnahme indirekter Beleuchtung); und
• dynamische diffuse globale Beleuchtungsstil globale Beleuchtung durch gestreute „Umgebungssonden“ Aktualisierungen.

„Ein Beispiel für eine Vergleichsaustauschanweisung, die in einer Ausführungsform der Erfindung ausgeführt werden kann, ist folgendes:”

 InterlockedCmpXChg_type_cmp_op()
      Type = int, uint, float
      cmp_op = less, greater, equal, less_equal, greater_equal, not_equal
      z.B.: InterlockedDepthCmpXChg_float_less_equal()

Ein beispielhaftes 64-Bit-Zielregister 8201 ist in 82A veranschaulicht, das einen 32-Bit-Tiefenwert 8202 und eine 32-Bit-Nutzlast 8203 speichert. Im Betrieb tauscht der obige Austauschvergleichsbefehl nur Nutzlast und Tiefe aus, falls der neue Gleitkommatiefenwert kleiner oder gleich dem gespeicherten Gleitkommawert ist. In einer Ausführungsform sind die cmpxchg -Atomika „entfernte“ Atomika, was bedeutet, dass der tatsächliche Vergleich und die atomare Aktualisierung nicht durch die EU, die den Befehl ausgegeben hat, sondern stattdessen durch einen Logikblock nahe der LLC- (oder Speichersteuerung), die Daten speichert, durchgeführt wird.

Beispiel: High Level Shading Language(HLSL)-Intrinsik für Schreib-Lese-Byte-Adressenpuffer (RWByteAddressBuffers)

In einer Ausführungsform ist nur der HighCompValue von dem Typ, der mit den High 32 Bits im 64bit-Ziel verglichen werden soll. Die übrigen werden als in vorzeichenlose 32-Bit-Ganzzahl umgewandelt angenommen (asuint()):

Beispiel HLSL Intrinsik für Ziel R

HighCompValue ist von der Art, die mit den hohen 32 Bit am tiefsten 64bit verglichen werden soll. Der Rest wird als umgerechnet mit asuint() angenommen

Alle diese Instrinsiken nehmen einen „Dest- ”Parameter des Typs” R ”” ein, der entweder eine Ressourcenvariable oder eine gemeinsam genutzte Speichervariable sein kann. Eine Ressourcenvariable ist eine skalare Referenz auf eine Ressource einschließlich Indexierung oder Feldreferenzen. Eine gemeinsam genutzte Speichervariable ist eine, die mit dem „gruppierten“ Schlüsselwort definiert ist. In jedem Fall muss der Typ Salbe 2 oder uint64 sein. Wenn „R“ ein Variablentyp mit gemeinsam genutztem Speicher ist, wird die Operation an dem „Wert“-Parameter und dem gemeinsam genutzten Speicherregister, auf das mit „dest“ Bezug genommen wird, durchgeführt. Wenn „R“ ein Ressourcenvariablentyp ist, wird die Operation an dem „Wert“-Parameter und dem Ressourcenort, auf den mit „dest“ verwiesen wird, durchgeführt. Das Ergebnis wird in dem gemeinsam genutzten Speicherregister oder Ressourcenort gespeichert, der mit „Ziel“ bezeichnet ist:

III. „Z-getestete“ Streuansammlung

Im Folgenden werden zwei Ausführungsformen mit Bezug auf 82B-C beschrieben. 82B veranschaulicht ein 64-Bit-Zielregister, das einen 32-Bit-Tiefenwert und einen 32-Bit-Nutzlastwert speichert. 82C veranschaulicht ein 64-Bit-Ziel, das einen 32-Bit-Tiefenwert und zwei 16-Bit-Gleitkommawerte speichert. Ein beispielhaftes Atom ist:

InterlockedCmpAdd_type1_type2_cMP_op()
- • type 1 = int, uint, float
- • type2= int, uint, float, 2xfp16
- • cmp_op = less, greater, equal, less_equal, greater_equal, not_equal
- • z. B.: InterlockedCmpAccum_float_2xfp16_less()
  - ▪ wenn der neue Schwimmtiefenwert < der gespeicherte Schwimmtiefenwert ist:
    1. 1. Austauschen des gespeicherten Tiefenwertes gegen den neuen
    2. 2. Dest.Payload.lowfp16 += InputPayload.lowfp16
    3. 3. Dest.Payload.highfp16 += InputPayload.highfp16

Neue HLSL intrinsische für RWByteAddressBuffers

Nur der HighCompValue ist von der Art, die mit den hohen 32 Bits am 64bit-Ziel verglichen werden soll. Die AddLowVal kann vom Typ ,float', ,int', ,uint' und ,min16float2' sein:

Vorgeschlagene neue HLSL Intrinsische für Ziel R

Lediglich der HighCompValue ist von der Art, die mit den hohen 32 Bit am weitesten 64bit verglichen werden soll. Die AddLowVal kann vom Typ ,float', ,int', ,uint' und min16float2' sein:

IV. Atomik für Ringpuffer

Ein Ringpuffer (oder Kreispuffer) ist eine Datenstruktur, die einen einzelnen Puffer fester Größe umfasst, der so arbeitet, als ob er Ende an Ende verbunden wäre. Zur Zwischenspeicherung von Datenströmen werden üblicherweise Ringpuffer verwendet. Eine Ausführungsform der Erfindung umfasst Atomik zum Anhängen und Abrufen von Einträgen an und von Ringpuffern.

Zunächst sind AppendIndex und PopFrontIndex 0. Um atomares Anhängen oder Popen zu ermöglichen, verwendet eine Ausführungsform spezielle 64-Bit-Atomik. Mit diesen Atomiken können GPU-Threads beispielsweise ein Hersteller-Verbraucherschema innerhalb der Grenzen der Kapazität des Ringpuffers implementieren. Ein Hardware-Watchdog kann Kerne aufwachen, die auf den Ringpuffer warten.

Die folgenden Codesequenzen veranschaulichen atomare Operation zum Anhängen und Abrufen von Einträgen aus einem Ringpuffer gemäß einer Ausführungsform der Erfindung:

a. Ringpufferanhängung

      InterlockedAppend(in dest64, in RingSize, out AppendIndexOut)
      atomically execute (
            if(((dest64.AppendIndex+1)% RingSize)!=(
            dest64.PopFrontIndex% RingSize))
            {
              AppendIndexOut = dest64.AppendIndex;
              ++dest64.AppendIndex;
            }
            else
            {
              AppendIndexOut = 0xffffffff; // error, ring-buffer full
            }
      )

b. Ringpuffer PopFront

      InterlockedPopFront(in dest64, in RingSize, out PopIndexOut)
      atomically execute ( 

            if(((dest64.PopFrontIndex) % RingSize) !=(
            dest64.AppendIndex % RingSize))
            {
              PopIndexOut = dest64.PopFrontIndex;
              ++dest64.PopFrontIndex;
            }
            else
            {
              PopIndexOut = 0xffffffff; // error ring buffer empty
            }
      )

c. Anwendungsbeispiele

i. Initialisieren des Ringpuffers mit verfügbarer Anzahl von Einträgen unter Verwendung von InterlockedAppend
ii. Mehrere Threads laufen ab und nehmen vorübergehend Einträge unter Verwendung von InterlockedPopFront auf/zu.
iii. Einträge gelangen über InterlockedAppend in den Ringpuffer zurück
iv. Threads können entscheiden, nicht auf Einträge zu warten und diesen Fall zu behandeln

Pseudocode für eine Mehrproduktorprobe und eine Mehrverbraucherprobe sind in den 84-85 dargestellt.

Ein Producer-Pseudocode-Sample ist in 84A veranschaulicht. Für dieses Beispiel sei angenommen, dass der job_entry_ready_buffer auf alle Nullen initialisiert wird und der ob_entry_consumed_buffer auf alle 1 s initialisiert wird:

Ein Verbraucherpseudocode-Sample ist in 84B veranschaulicht. Für dieses Beispiel wird angenommen, dass der job_entry_ready_buffer auf alle Nullen initialisiert wird und der job_entry_consumed_buffer auf alle 1 s initialisiert wird.

83A veranschaulicht einen beispielhaften Ringpuffer, der gemäß einer Ausführungsform implementiert ist. Es ist eine Ringpuffer-Popback-Operation gezeigt, bei der Einträge N, N+1 usw., wobei N ein ganzzahliger Wert ist, gepoppt und in Ringpuffereinträgen 0, 1 usw. gespeichert werden. 83B veranschaulicht ein 64-Bit-Zielregister 8211, das den Anhängeindex Wert 8212 und den Pop-Front-Index Wert 8213 speichert, gemäß der folgenden Codesequenz:

V. Atomare Multiplikationsoperationen

Eine Ausführungsform eines Mehrfach-Atoms spezifiziert ein Ziel und einen Typwert. Beispielsweise kann ein mehrfach atomares Atom wie folgt ausgebildet sein:

InterlockedMultiply(destination, type value)

In einer Ausführungsform multipliziert die Multiplikationsoperation atomar einen Wert eines spezifizierten Datentyps mit dem Wert im Ziel, der derselbe Datentyp oder ein anderer Datentyp sein kann.

Multiplizierte Atomwerte können beispielhaft und nicht einschränkend 4-Bit-, 8-Bit-, 16-Bit-, 32-Bit- und 64-Bit-Ganzzahlwerte und 16-Bit-, 32-Bit- und 64-Bit-Gleitkommawerte sein. Die Werte können vorzeichenbehaftet oder unvorzeichenbehaftet sein. Darüber hinaus kann eine Anzahl von parallelen Multiplikationsoperationen basierend auf der kleinsten Datenelementgröße durchgeführt werden. Die Gleitkomma-Multiplikationsschaltungsanordnung kann zum Beispiel dazu konfiguriert sein, eine einzige 32-Bit-Gleitkomma-Multiplikation oder duale 16-Bit-Gleitkomma-Multiplikationen durchzuführen. Formate wie etwa Bfloat16 oder TensorFloat16 können verwendet werden, um die parallelen Multiplikationen effizient durchzuführen. Gleichermaßen kann ein Ganzzahlmultiplizierer in der Lage sein, eine einzelne 32-Bit-Multiplikation, duale 16-Bit-Multiplikationen, vier 8-Bit-Multiplikationen oder acht 4-Biut-Multiplikationen durchzuführen. Verschiedene andere Arten von Datenformaten und Paralleloperationen können verwendet werden, während die zugrundeliegenden Prinzipien der Erfindung weiterhin erfüllt sind, einschließlich zum Beispiel 2 x FP16, Float2, 4 x FP16, 11_11_10FP und 2 x 11_11_10FP.

Diese Atomik kann für eine Vielzahl von Zwecken verwendet werden, einschließlich maschineller Lernoperationen, Weighted Blended Order Independent Transparence (OIT) oder Opacity Shadow Maps.

VORRICHTUNG UND VERFAHREN FÜR GRAPHIKEN PROZESSORVERWALTETE VERSCHMUTZTE RESSOURCEN

Eine Ausführungsform der Erfindung verbessert die Effizienz, mit der ein benutzergeschriebenes GPU-Programm Daten zwischenspeichern und wiederverwenden kann, die in einem Puffer oder einer Textur gespeichert sind. Diese Ausführungsform stellt auch eine logische Repräsentation großer prozedurberechneter Ressourcen bereit, die gleichzeitig physisch in den GPU-Speicher passen oder nicht.

In einer Ausführungsform der Erfindung wird eine neue gekachelte Ressource durch die GPU definiert und verwaltet, hier als GPU-verwaltete gekachelte Ressource oder GPU-Verwalter-Puffer bezeichnet. Bei einer Implementierung enthält der Puffer oder die andere gekachelte Speicherressource bis zu N Speicherblöcke fester Größe, wobei N ein ganzzahliger Wert ist. Unterschiedliche GPU-Architekturen können eine unterschiedliche maximale Anzahl von Blöcken (N) unterstützen.

In einer Ausführungsform wird die GPU-verwaltete gekachelte Ressource verwendet, um Daten effizient zwischen Shadern zu teilen-d. h. wobei ein Shader als ein „Produzent“ für einen oder mehrere „Konsumenten“ -Shader agiert. Zum Beispiel kann der Producer-Shader prozeduraktualisierten Inhalt erzeugen, den der Consumer-Shader verwenden kann, ohne eine Interaktion mit der CPU einzubeziehen. Als ein anderes Beispiel müssen bei Strahlverfolgungsmplementierungen möglicherweise verschiedene Formen einer Hautbildungsanimation beim Durchlaufen aktualisiert werden. Ein Shader kann einen kleinen Teil des Netzes umhüllen, wodurch Ergebnisse in der gekachelten Ressource ohne CPU-Eingriff gespeichert werden. Da andere Strahlen denselben Teil verfolgen, können sie lokal von der gekachelten Ressource auf die Daten zugreifen, ohne auf den Hauptspeicher zuzugreifen.

85A veranschaulicht eine Ausführungsform einer Architektur zum Implementieren von GPU-verwalteten Kachel-Ressourcen 8531. Ein Grafikprozessor 8521 weist einen Scheduler 8510 zum Schedulen von Shadern 8511A-B auf dem Satz von Ausführungseinheiten 4001 auf. Die Ausführung der Shader erfordert einen Zugriff auf gekachelte Ressourcen 8531, die von einem Ressourcenmanager 8512 verwaltet werden. In dem unten bereitgestellten Beispiel wird ein Shader 8511A als ein „Erzeuger“ bezeichnet, der seine Ergebnisse in der gekachelten Ressource 8531 speichert, und der andere Shader 8511B ist ein „Verbraucher“,der die durch den Erzeugershader 8511A erzeugten Ergebnisse verwendet. Folglich muss der Producer-Shader 8511A Zugriff haben, um in die gekachelte Ressource 8531 zu schreiben, und der Verbraucher-Shader 8511 B muss Lesezugriff auf die gekachelte Ressource 8531 haben. Es ist jedoch anzumerken, dass eine Erzeuger/Verbraucherarchitektur nicht erforderlich ist, um die zugrundeliegenden Prinzipien der Erfindung zu erfüllen.

Bei einer Implementierung umfasst die gekachelte Ressource 8531 einen On-Chip-Kachelspeicher oder Kachelpuffer, der kachelgroße Blöcke 0-(N-1) von Daten speichert. Die „Kachel“ -Größe kann basierend auf der Architektur des Grafikprozessors 8521 und der Konfiguration der Grafikverarbeitungs-Pipeline variabel sein. In einer Ausführungsform ist die Grafikverarbeitungs-Pipeline dazu konfiguriert, unter Verwendung der gekachelten Ressource 8531 kachelbasiertes Aufschieben, kachelbasiertes Sofort-Modus-Rendern und/oder eine andere Form von kachelbasierter Grafikverarbeitung durchzuführen.

In einer Ausführungsform fordert eine Ausführungseinheit (EU) 4001 oder eine andere Verarbeitungseinheit einen Block unter Verwendung eines Hashwerts oder einer anderen Form von ID 8501 an (z. B. in einer Ausführungsform ein 64-Bit-Hash). Ein Ressourcenmanager 8512 bestimmt, ob der Block innerhalb der gekachelten Ressource 8531 existiert, die N Blöcke fester Größe umfasst. Falls kein solcher Block gefunden wird, räumt der Puffermanager 8510 den LRU-Block (LRU: Least Recently Used) oder wählt einen unbenutzten Block aus, falls einer existiert. Die Antwort 8502 identifiziert den zugewiesenen Block, den der Puffermanager 8510 mit dem gegebenen Hashwert als „verwendet“ markiert. Bei einer Implementierung wird auch ein Flag zurückgegeben, das angibt, dass der Block neu ist. Ein zuletzt verwendeter Block, der ersetzt wird, verliert den alten Inhalt, den er gespeichert hat. Falls der Block bereits vorhanden ist, wird ein Flag zurückgegeben, das anzeigt, dass der Block bereits vorhanden ist und dennoch zurückgegeben wird.

Obwohl als eine Komponente innerhalb des Grafikprozessors 8521 veranschaulicht, kann die gekachelte Ressource 8531 innerhalb eines Speichers außerhalb des Grafikprozessors 8521 implementiert sein, wie etwa eines Systemspeichers oder eines Caches auf Systemebene.

Es ist bekannt, dass bestimmte Klassen von Shadern 8511A-B, die auf den EUs 4001 einer GPU ausgeführt werden, a priori einen Speicherblock benötigen. Zum Beispiel können diese Shader immer in den Spuren einer Welle ausgeführt werden. In einer Ausführungsform konstruiert der Scheduler 8510, der die Ausführung dieser Shader 8511A-B plant, einen 64bit ID/Hash aus systemgenerierten Werten. Zum Beispiel verwendet eine Ausführungsform im Kontext des Strahlverfolgens die Instanz-ID und die Geometrie-ID, um einen eindeutigen 64-Bit-Hash zu konstruieren. Jedoch kann eine Vielfalt anderer systemgenerierter Variablen verwendet werden.

In dieser Ausführungsform prüft der Scheduler 8510 über den Ressourcenmanager 8512, ob bereits ein Block der gekachelten Ressource 8531 für den 64bit-Hash zugewiesen ist. Falls ja, wird der Shader 8511A-B unter der Annahme ausgeführt, dass der Block bereits zwischengespeicherte Daten enthält und dass diese durch den Shader verbraucht werden können und der Shader auf den EUs 4001 geplant ist. Der Ressourcenmanager 8512 sperrt, dass der Speicherblock wiederverwendet wird, solange der Shader, der den datenzwischengespeicherten Lock-in-Block verwendet, ausgeführt wird. Wenn der Shader durch eine oder mehrere EUs 4001 ausgeführt wird, aktualisiert er den Block in der gekachelten Ressource 8531 unter Verwendung der Block-ID 8501 und empfängt für bestimmte Operationen Antworten 8502 von dem Ressourcenmanager 8512.

Falls der Scheduler 8510 anfänglich feststellt, dass es keinen Block mit dem gegebenen 64-Bit-Hash gibt, lokalisiert der Ressourcenmanager 8512 in einer Ausführungsform einen unbenutzten Block oder verwendet den zuletzt benutzten Block (oder anderen Block), der bereits zugewiesen hat und gerade nicht verwendet wird. Falls er einen solchen Block nicht lokalisieren kann, kann er eine Ausführung des Shaders verschieben, bis ein solcher Block verfügbar wird. Wenn ein Block verfügbar ist, sperrt der Kachelressourcenmanager 8512, dass der Kachelressourcenblock wiederverwendet wird, solange der Shader ausgeführt wird und den Shader plant. Ein Flag kann an den Shader übergeben werden, um anzuzeigen, dass der Block leer ist und dass der Shader ihn verwenden kann, um Daten zu erzeugen und zu speichern. Nach dem Schreiben von Daten in den gekachelten Ressourcenblock kann der Shader die Ausführung fortsetzen, als ob der gekachelte Ressourcenblock mit seinen Daten bereits verfügbar gewesen wäre.

Zurückkehrend zu dem Verbraucher/Erzeugerbeispiel oben kann ein Erzeuger-Shader 8511A geplant werden, einen neuen Block oder eine neue Kachel der prozeduralen Ressource 8531 zu erzeugen, falls der angeforderte Hash in dem Pool nicht gültig ist. Ein solcher angeforderter Hash kann durch einen oder mehrere Verbrauchershader 8511B erzeugt werden, die der Ressourcenmanager 8512 blockieren würde, bis ihre Anforderung gefüllt ist.

In einer Ausführungsform werden gekachelte Ressourcenblöcke zu einer Festkörpervorrichtung 8515 oder einem anderen Hochgeschwindigkeitsspeichermedium entfernt. Der SSD 8515 oder eine andere Speicherungsvorrichtung können lokal auf demselben Substrat und/oder derselben Karte wie der Grafikprozessor 8521 integriert sein und können dazu konfiguriert sein, gekachelte Ressourcenblöcke und andere Daten während interner Grafikprozessorkontextumschaltungen 8521 zu speichern.

Ein Verfahren gemäß einer Ausführungsform ist in 85B dargestellt. Das Verfahren kann im Kontext der oben beschriebenen Architekturen implementiert werden, ist aber nicht auf irgendeine spezielle Architektur beschränkt.

Bei 8551 bewertet der Scheduler den nächsten Shader, der zur Ausführung zu planen ist, und bestimmt bei 8552 eine HASH-ID, die verwendet werden soll, um den gekachelten Ressourcenblock zu identifizieren (z. B. unter Verwendung einer oder mehrerer der hierin beschriebenen Techniken). Bei 8553 fragt der Scheduler den Kachelressourcenmanager mit der HASH-ID ab.

Falls ein Block bereits für diese HASH-ID zugewiesen ist, bestimmt bei 8554, dann sperrt der gekachelte Ressourcenmanager den gekachelten Ressourcenblock bei 8555 und der Shader verwendet den gekachelten Ressourcenblock während der Ausführung bei 8556. Der gekachelte Ressourcenblock kann anschließend entriegelt werden, wenn der Shader abgeschlossen ist, es sei denn, er wird mit einer Hash-ID eines Verbrauchershaders verriegelt, der die Daten benötigen wird, nachdem der aktuelle (Erzeuger) Shader abgeschlossen ist. In jedem Fall kehrt der Prozess zu 8551 zum Planen des nächsten Shaders zurück.

Falls bei 8554 kein gekachelter Ressourcenblock mit der HASH-ID identifiziert wird, dann weist der gekachelte Ressourcenmanager der HASH-ID einen gekachelten Ressourcenblock zu und kann dem Shader ein Flag zuweisen, das angibt, dass er diesen gekachelten Ressourcenblock verwenden kann. Wie erwähnt, kann der gekachelte Ressourcenmanager existierende Daten aus einem gekachelten Ressourcenblock entfernen, um den gekachelten Ressourcenblock dem aktuellen Shader zuzuweisen. Der gekachelte Ressourcenblock wird bei 855 gesperrt und der Shader verwendet den gekachelten Ressourcenblock während der Ausführung bei 8556.

Der GPU-verwaltete Kachelpuffer 8531 kann auf eine Vielzahl von Weisen verwendet werden. Beispielsweise möchte eine SIMD-Welle von Spuren in denselben Kreuzungsshaderkasten eintreten, gebündelt durch einen bindungslosen Laufstreifendispatcher (unten beschrieben). Bevor der Kreuzungs-Shader ausgeführt wird, fordert die Hardware einen Block von dem Puffermanager 8510 an.

Der 64-Bit-Hash kann auf unterschiedliche Weise erzeugt werden. In einer Ausführungsform ist zum Beispiel der 64-Bit-Hash die Instanz-ID der aktuellen Strahltraversierungsinstanz kombiniert mit dem Rahmenzähler. Falls der Block neu ist, kann die Hardware einen Benutzerberechnungsshader starten, der innerhalb der Spuren der Welle läuft, der dann den Block füllt (z. B. mit Hautdreiecken). Falls der Block alt ist, dann kann der Shader nicht gestartet werden. Dann wird ein Kreuzungs-Shader ausgeführt, der mit dem Zeiger auf den Block versehen wird. Der Kreuzungs-Shader kann dann Strahl/Dreieck-Schnittpunkte durchführen und/oder eine Unterstützung kann für einen Hardwarebefehl für die Strahl/Dreieck-Schnittpunkte bereitgestellt werden (wie hier beschrieben). Alternativ kann der Block so ausgebildet sein, dass er nur Dreiecke enthält. In diesem Fall iteriert die Hardware über diese Dreiecke (ohne eine BVH über sie aufzubauen) und kann zum Beispiel nächste Treffer-Shader aktualisieren oder in beliebige Treffer-Shader aufrufen. Verschiedene andere Verwendungsfälle können die GPU-verwaltete Kachelressource 8531, wie oben beschrieben, nutzen.

VORRICHTUNG UND VERFAHREN ZUM EFFIZIENTEN LAZY BVH BUILD

Lazy-Builds bewerten Szenenelemente „on-demand“, wie durch Strahltraversierung getrieben. Das Rendern eines Frames beginnt mit einer groben Beschleunigungsstruktur, wie einem Szenengraphen oder Hierarchien des vorherigen Frames, und baut dann progressiv die neu benötigten Beschleunigungsstrukturen für die Objekte auf, die während des Traversierens von Strahlen getroffen werden. Unsichtbare Objekte können wirkungsvoll vom Bauprozess ausgeschlossen werden. Diese Techniken werden jedoch nicht einfach mit aktuellen Systemen und APIs implementiert, da die Programmierbarkeit höherer Ebene (d. h. pro Objekt), die für das Berechnen der Instanzsichtbarkeit wesentlich ist, nicht unterstützt wird.

Eine Ausführungsform der Erfindung unterstützt einen Multipass-Lazy-Build (MPLB) zur Echtzeit-Strahlverfolgung, der diese Probleme mit einem erweiterten Programmiermodell löst. Es ermöglicht, dass die Traversierung auf Instanz-Ebene während jeder Strahlenabgabe verfolgt wird, und baut selektiv Beschleunigungsstrukturen auf Bottom-Ebene (BLASs) nur für die potentiell sichtbare Geometrie zur Renderzeit auf. Bei manchen adaptiven Abtasttechniken kann MPLB, wie hier beschrieben, mehrere Strahlenabgaben über denselben Satz von Pixeln erfordern, um Strahlen zu zuvor nicht aufgebauten Teilen der Szene zu relativieren, aber bestimmte Ausführungsformen der Erfindung umfassen Techniken zum Minimieren dieses Overhead, wie etwa die Annahme von Frame-zu-Frame-Kohärenz und gerasterter Primärsichtbarkeit. Diese Techniken können eine signifikante Reduktion der Aufbaukomplexität im Vergleich zu Einmalaufbauten mit nur einer marginalen Zunahme der Traversierungskosten im Durchschnitt bereitstellen.

86A veranschaulicht eine Ausführungsform eines bedarfsgerechten (oder „lazy“) Builders 8607 zum Durchführen von lazy Builderoperationen, wie hier beschrieben. Außerdem umfasst diese Ausführungsform eine Traversieraussetzungsschaltungsanordnung/Logik 8620 zum Aussetzen der Strahldurchsetzung. Die Strahltraversierungsaussetzungsschaltungsanordnung/Logik 8620 kann in Hardware, Software oder einer beliebigen Kombination davon implementiert sein. Der Strahlenstapelspeicher 8605 speichert suspendierte Strahlenstapel 8610, wenn die Traversierung ausgesetzt ist (wie hier ausführlicher beschrieben). Zusätzlich dazu startet GPU-seitige Befehlsplanung bedarfsgesteuerte Aufbauaufgaben und Strahlfortsetzungen auf den Ausführungseinheiten 4001 ohne Überwachung durch die CPU. Traversalatomika werden auch verwendet, um den Shader-Overhead zu reduzieren.

Traversiersuspension bei fehlender Begegnung mit Beschleunigungsstruktur unterer Ebene (BLAS)

Bei einer Implementierung werden fehlende Instanzen (z. B. fehlende Beschleunigungsstrukturen der unteren Ebene des BVH 8005) unter Verwendung eines Programmiermodells mit einer Traversierungs-Shader-Erweiterung programmatisch markiert, so dass sie in einem separaten Durchlauf identifiziert und aktualisiert werden können. Dann wird entweder ein unvollständiger Durchlauf durchgeführt oder der Durchlauf abgebrochen.

Um die finalen Pixel zu rendern, muss der primäre Shader des entsprechenden Pixels möglicherweise neu gestartet werden, was zu mehreren wiederholten Traversier- und Shader-Ausführungsoperationen führt. In einer Ausführungsform sichert die Traversieraussetzungslogik 8620 den gesamten Strahlenkontext 8610 (Strahlenstapel, Fortsetzungen usw.) in den chipexternen Speicher 8605, wenn die Traversierung ausgesetzt wird. In einer Ausführungsform setzt diese Traversierung eine intrinsische Funktion aus, die durch den Treiber verwaltet wird (z. B. SuspendTraversal()); die der Erfindung zugrundeliegenden Prinzipien sind jedoch nicht auf diese Implementierung beschränkt. Zusätzlich dazu plant eine neue DispatchRay()-Variante auf der Host-Seite - ausgeführt durch die CPU 3199 - die suspendierten Strahlstapel aus dem Strahlkontext 8610 neu, um eine Traversier-Shader-Ausführung fortzusetzen.

GPU-seitige Befehlsplanung für Aufbau und Abbau

Ein weiterer signifikanter Overhead aktueller Lazy-Build-Implementierungen ist die kontinuierliche Anforderung des Zurücklesens der CPU 3199 und des bedingten Planens des BVH-Builders 8007 und des Strahlenabsendens auf der GPU 2505. Um die Effizienz zu verbessern, führt die BVH-Verarbeitungsschaltungsanordnung/-logik 8004 bei einer Implementierung den BVH-Aufbau asynchron mit der Strahltraversierung 8003 durch. Nach Abschluss der Aufbauaufgaben führt die Strahlverfolgungsengine 8000 die Strahlversendung aus, um die suspendierten Strahlstapel aus dem Strahlkontext 8610 fortzusetzen.

Traversieratomik zur Reduzierung von Traversierungs-Shader-Overhead

Ein Problem bei aktuellen Implementierungen besteht darin, dass, falls eine Instanz fehlt (nicht gebaut), mehrere Strahlen sie durchlaufen können und sie für den Lazy-Builder 8607 markieren können, um ihn zu aktualisieren. Eine einfache Aufgabe, die von nur einem Traversierungs-Shader-Aufruf durchgeführt werden könnte, wird von hundert oder mehr Aufrufen wiederholt. Der Traversierungs-Shader ist nicht ressourcenintensiv, er weist aber einen erheblichen Overhead zum Starten, Durchführen von Eingabe/Ausgabe-Funktionen und Speichern von Ergebnissen auf.

In einer Ausführungsform der Erfindung können ungebaute Instanzblätter als „atomare“ Knoten markiert werden. Atomknoten können von nur einem Strahl auf einmal durchlaufen werden. Ein atomarer Knoten wird verriegelt, sobald ein Strahl ihn durchläuft, und am Ende der Traversier-Shader-Ausführung entriegelt. In einer Ausführungsform setzt der Traversal-Shader den Status eines Knotens auf „ungültig“, was verhindert, dass Strahlen in ihn eintreten, selbst nachdem die Sperre gelöst wurde. Dies ermöglicht es der Traversierungshardware, entweder den Knoten zu überspringen oder die Traversierung des Strahls auszusetzen, ohne einen neuen Traversierungs-Shader auszuführen.

In einer Ausführungsform werden für Atomknoten anstelle regulärer atomarer Semantik bestimmte Mutex/Condition-Semantik verwendet. Falls zum Beispiel die Traversierungsschaltungsanordnung/Logik 8003 einen Strahl zu einem Proxyknoten durchläuft, versucht sie, den Knoten zu verriegeln. Scheitert dies, da der Knoten bereits verriegelt ist, führt er automatisch „suspendRay“ aus, ohne zur EU 4001 zurückzukehren. Falls das Sperren erfolgreich ausgeführt wird, verarbeitet die Traversierschaltungsanordnung/-logik 8003 den Proxyknoten.

Lazv Aufbau von Beschleunigungsstrukturen mit Traversierungs-Shader

Eine Ausführungsform der Erfindung arbeitet gemäß dem in 86B gezeigten Verarbeitungsfluss. Als Übersicht baut der on-demand Builder 8607 Beschleunigungsstrukturen über Geometrieinstanzen 8660 auf, von denen bestimmt wird, dass sie potentiell sichtbar sind. Die potentiell sichtbaren Instanzen 8660 werden durch einen Voraufbauer 8655 basierend auf primären Sichtbarkeitsdaten aus dem G-Puffer 8650 und Sichtbarkeitshistoriedaten 8651, die Sichtbarkeit in dem vorherigen Frame angeben, erzeugt. Die potentiell sichtbaren Instanzen 8660 können auch basierend auf einer sichtbaren Unterebene-Beschleunigungsstruktur(BLAS)-Map 8675 bestimmt werden, die die Unterebene-Knoten der Beschleunigungsstruktur angibt, die sichtbare Primitive aufweisen. In einer Ausführungsform wird die sichtbare BLAS-Map 8675 als Reaktion auf Traversieroperationen, die durch die Traversierlogik 8670 durchgeführt werden, die dedizierte Traversierschaltungsanordnung und/oder Traversierungs-Shader, die auf den Ausführungseinheiten des Grafikprozessors ausgeführt werden, aufweisen kann, kontinuierlich aktualisiert.

Der on-demand Builder 8607 erzeugt diejenigen Teile der Beschleunigungsstruktur, die mit den potentiell sichtbaren Instanzen 8660 assoziiert sind. Ein Strahlenerzeugungs-Shader 8678 erzeugt selektiv Strahlen basierend auf diesen Teilen der Beschleunigungsstruktur, die die Traversiereinheit 8670 durch die Beschleunigungsstrukturteile quert. Die Traversiereinheit 8670 benachrichtigt den Abfrage-Builder 8607 über zusätzliche Beschleunigungsstrukturknoten, die die Traversiereinheit 8670 zum Traversieren benötigt. Außerdem aktualisiert die Traversiereinheit 8670 die BLAS-Pixelmasken 8677, die durch den Strahlenerzeugungs-Shader 8678 (der z. B. nur Strahlen für unmaskierte Pixel erzeugt) und die sichtbare BLAS-Map 8675 verwendet werden.

Dementsprechend baut der on-demand Builder 8607 selektiv Beschleunigungsstrukturen der unteren Ebene über den potentiell sichtbaren Instanzen 8660 auf und die Instanzsichtbarkeit wird während des Strahldurchlaufs 8670 aktualisiert. Im Gegensatz zu den vorherigen Implementierungen arbeiten die Ausführungsformen der Erfindung in mehreren Durchgängen, um kompliziertes Strahlplanen zu vermeiden. Die Idee ist analog zu neueren Texturraum-Schattierungsansätzen, bei denen eine sichtbarkeitsgesteuerte Markierung von Texeln verwendet wird, um redundante Schattierung vor dem endgültigen Rendern zu vermeiden.

Im Betrieb werden zuerst die BLASs für leere Instanzen aufgebaut, die in dem vorherigen Durchlauf als potentiell sichtbar markiert wurden. Bei dem zweiten Durchgang schießt der Strahlenerzeugungs-Shader 8678 die Strahlen selektiv zu den unfertigen Pixeln zurück, wobei ein Traversier-Shader verwendet wird, um entweder potentiell sichtbare leere Instanzen aufzuzeichnen oder das Pixel abzuschließen. Die Anzahl unvollständiger Pixel nimmt nach jeder Iteration ab, bis keine Strahlen mehr vorhanden sind, die eine leere Instanz durchlaufen haben.

Eine Ausführungsform der Erfindung führt ein hybrides Rendern unter Verwendung des GPU-Rasterisierers und der Strahlverfolgungs-Hardware zusammen durch. Dies liegt daran, dass, wenn der G-Puffer 8650 erzeugt wird, die Primärsichtbarkeit aller Fälle in der Szene einfach erhalten wird. Daher nutzt der Voraufbauer 8655 in diesen Ausführungsformen hybrides Rendern durch effizientes Konstruieren der anfänglichen Beschleunigungsstruktur unter Verwendung dieser Daten. Vor der ersten Iteration werden potentiell sichtbare Instanzen 8660 in dieser Vorbauheuristik markiert (wie unten besprochen).

Die folgende Codesequenz ist eine abstrahierte High-Level-Shader-Sprache (HLSL), die eine Ausführungsform des beschriebenen Traversal-Shaders mit einigen intrinsischen und Benutzerfunktionen beschreibt:

Das SkipTraversal() intrinsisch ist definiert, um die aktuelle Instanz zu ignorieren und das Durchlaufen in der Beschleunigungsstruktur höherer Ebene fortzusetzen. Wie erwähnt, wird die sichtbare Niederebenenbeschleunigungsstruktur(BLAS)-karte 8675 verwendet, um Instanzsichtbarkeit aufzuzeichnen, die üblicherweise in Beschleunigungsstrukturaufbauern und Traversierungs-Shadern verwendet wird. Wie in 86C gezeigt, enthält eine Ausführungsform der sichtbaren BLAS-Karte 8675 ein Flag 8676, das mit jeder BLAS-ID 8674 assoziiert ist, das die BLAS-Sichtbarkeit angibt, auf die sich die Instanz bezieht, und zwei Flags Built_Full und Built_empty, die angeben, ob die BLAS bereits aufgebaut wurde. Zusätzlich wird ein boolesches Flag, trav_valid, zu den Strahlen-Nutzdaten hinzugefügt, um den Traversierungsstatus zu verfolgen, der zum Prüfen verwendet werden kann, ob der Strahl bisher auf eine leere Instanz aufgetroffen ist.

In einer Ausführungsform wird die Sichtbarkeit in dem Traversal-Shader konservativ aktualisiert, da alle durchlaufenen Instanzen potentiell für den aktuellen Strahl sichtbar sind. Daher besteht die erste Aufgabe darin, das Sichtbarkeitsflag als wahr für die entsprechende BLAS der aktuellen Instanz zu setzen. Es setzt auch das Flag der Sichtbarkeitshistorie (vis_history) als wahr zur Wiederverwendung im nächsten Rahmen (Zeile 9 der obigen Codesequenz). Als Nächstes wird das Traversierungsziel basierend auf dem Status der aktuellen Instanz (leer oder voll) und dem Strahlenstatus (d. h. dem trav_valid-Wert) bestimmt. Dies wird in drei Zustände 8690-8692 klassifiziert, wie in 86D gezeigt.

Für eine leere Instanz 8690 wird die entsprechende Pixelmaske zurückgesetzt (Zeile 15), um Strahlen im nächsten Durchgang wieder aufzunehmen. Die aktuelle Traversierung wird dann durch Setzen des trav_valid-Flags in der Strahlen-Nutzlast ungültig gemacht (Zeile 16). Schließlich setzt die TLAS-Traversierung fort, indem SkipTraversal() aufgerufen wird.

Für den Vollinstanz und den ungültigen Traversierungsfall 8691 hat die aktuelle Instanz eine aufgebaute BLAS, aber der Strahl hat bisher eine leere Instanz angetroffen (d. h. trav_valid ist falsch). Da der Strahl schließlich wieder auf das aktuelle Pixel geschossen wird, kann die BLAS-Traversierung übersprungen werden (Zeile 20).

Für eine volle Instanz und gültige Traversierung 8692 holt der Traversierungs-Shader, da der Strahl normalerweise die Beschleunigungsstruktur ohne leere Instanzen durchläuft, die BLAS der aktuellen Instanz und setzt die Traversierung fort. Falls der Strahl bis zum Ende der Traversierung Gültigkeit beibehält, wird der Strahl normalerweise den am nächsten getroffenen Shader oder Fehltreffshader aufrufen und ausführen.

Andernfalls wird der aktuelle Durchlauf beendet, was verhindert, dass die Overhead von Hardware-Strahltraversierung und Shader für Sekundärstrahlen starten. Beim nächsten Durchlauf werden die Strahlen wieder nur auf das Pixel mit der Maske „Falsch“ geschossen und ein gültiger Durchlauf für diese Pixel versucht.

Für die Beschleunigungsstrukturaufbauoperation werden die BLASs der Instanzen aufgebaut oder werden leere Instanzen in Abhängigkeit von dem Sichtbarkeitsflag der Sichtbarkeitsbitmaske erzeugt. Die potentiell sichtbare Instanz konstruiert normalerweise die BLAS (BUILD_FULL) und die unsichtbare Instanz berechnet nur den Begrenzungsrahmen der Geometrie und packt ihn in den Blattknoten von TLAS (BUILD_EMPTY). Es wird auch auf die anderen beiden Flags Bezug genommen, die angeben, ob eine BUILD_FULL- oder BUILD_EMPTY-Aktion bereits für das aktuelle Objekt im vorherigen Durchlauf durchgeführt wurde. Durch Überprüfen dieser Flags können doppelte Handlungen für dasselbe Objekt in den unterschiedlichen Iterationen der Bauquerschleife vermieden werden.

Sobald der BLAS-Aufbauprozess für die Objekte abgeschlossen ist, wird die endgültige Beschleunigungsstruktur konstruiert, indem die TLAS über diesen BLASs aufgebaut werden. Die TLAS werden erst im ersten Durchlauf und im übrigen Durchlauf neu aufgebaut, da die Begrenzungsrahmen aller Objekte bereits im ersten Durchlauf eingerichtet sein könnten.

Wie oben beschrieben, führt eine Ausführungsform der Erfindung mehrere Durchgänge durch, wodurch sie manchmal redundant Strahlen für dasselbe Pixel schießen lässt. Denn der aktuelle Durchlauf sollte den ungültigen Durchlauf im vorherigen Durchlauf ausmachen. Dies kann zu redundanten Hardware-Strahltraversierungen und Shader-Aufrufen führen. Eine Ausführungsform beschränkt diesen Overhead der Traversierungskosten jedoch nur auf die Pixel, die einer ungültigen Traversierung entsprechen, durch Anwenden einer Pixelmaske.

Zudem werden unterschiedliche Techniken verwendet, um potentiell sichtbare BLASs zu identifizieren (und sie aufzubauen), noch bevor der erste Strahl durchlaufen wird (z. B. durch den Voraufbauer 8655). Unter Verwendung des G-Puffers 8650 können direkt sichtbare Instanzen markiert werden, die wahrscheinlich von Primärstrahlen durchlaufen werden. Des Weiteren wird angenommen, dass es eine signifikante Menge an Frame-zu-Frame-Kohärenz gibt; dementsprechend werden die BLASs von Instanzen, die in dem vorherigen Frame durchlaufen werden, auch vorgefertigt. Durch die Kombination dieser beiden Techniken wird die Anzahl der Bauqueriterationen stark reduziert.

VORRICHTUNG UND VERFAHREN FÜR EINE MATERIALAUSSONDERUNGSMASKE

Existierende Strahlverfolgungs-APIs verwenden eine 8-Bit-Aussonderungsmaske, um die Strahltraversierung für bestimmte Geometrieinstanzen zu überspringen. Dies dient beispielsweise dazu, bestimmte Objekte am Schattenwurf zu hindern oder Objekte vor Reflexionen zu verbergen. Dieses Merkmal ermöglicht es, unterschiedliche Teilmengen der Geometrie innerhalb einer einzigen Beschleunigungsstruktur darzustellen, im Gegensatz zum Aufbau separater Beschleunigungsstrukturen für jede Teilmenge. Die Biteinstellungen in der 8-Bit-Maske können verwendet werden, um die Traversierleistung und den Ressourcenaufwand zum Beibehalten mehrerer Beschleunigungsstrukturen auszugleichen. Falls zum Beispiel ein Bit in der Maske auf 0 gesetzt ist, kann die entsprechende Instanz ignoriert werden.

Rendering-Engines können mehrere Geometrieinstanzen mit einem Asset assoziieren und jede Geometrieinstanz kann mehrere Materialien enthalten. Aktuelle Raytracing-APIs erlauben jedoch nur die Spezifikation der Aussonderungsmaske bei der Granularität einer Instanz. Dies bedeutet, dass Assets, die unterschiedliche Kulturmasken auf unterschiedlichen Materialien aufweisen, keine Standardkultur verwenden können. Als eine Workaround-Verarbeitung verwenden aktuelle Implementierungen beliebige Treffer-Shader, um Kreuzungen zu ignorieren, was teuer und kompliziert ist.

Wie in 87 veranschaulicht, legt eine Ausführungsform der Erfindung diese Maskierungssteuerungen auf einer pro-Material-Basis frei. Insbesondere umfasst eine Implementierung eine N-Bit-Material-basierte Aussonderungsmaske 8701 zum Überspringen einer Strahltraversierung für Teile von Geometrieinstanzen, die mit gewissen Materialien assoziiert sind. In einer Ausführungsform wird eine 8-Bit-Material-basierte Aussonderungsmaske verwendet, aber die zugrundeliegenden Prinzipien der Erfindung sind nicht auf diese Implementierung beschränkt. Im Gegensatz zu existierenden Implementierungen wird die materialbasierte Aussonderungsmaske 8701 freigelegt und kann durch die Traversierungsschaltungsanordnung/Logik 8003 zum Beispiel auf einer pro-Material-Basis sowie auf einer pro-Instanz-Basis genutzt werden.

Bei einer spezifischen Implementierung wird die N-Bit-Aussonderungsmaske 8701 innerhalb einer Treffergruppe 8700 gespeichert, was eine Aussonderung mit fester Funktion pro Material bereitstellt und die Notwendigkeit teurer irgendwelcher Treffer-Shader-Workarounds verringert. Eine „Treffergruppe“ 8700, wie hier verwendet, ist ein API-Objekt, das einen Satz von Shadern enthält, die zum Verarbeiten von Strahlen verwendet werden, die auf ein gegebenes Objekt in der Szene treffen. Der Satz von Shadern kann zum Beispiel einen Nächster-Treffer-Shader, einen Beliebieger-Treffer-Shader und (für prozedurale Geometrie) einen Kreuzungs-Shader aufweisen. In einer Implementierung wird die materialbasierte Aussonderungsmaske 8701 der Treffergruppe 8700 als zusätzliches Datum zugeordnet.

Um die Aussonderungsmaske 8701 mit der Treffergruppe 8700 zu assoziieren, kann die Aussonderungsmaske 8701 innerhalb der 32-Byte-Shader-Aufzeichnung gespeichert werden, den die API für die zu verwendende Implementierung bereitstellt (z. B. identifiziert über eine Aufzeichnungs-ID, wie hier beschrieben). Es wird jedoch angemerkt, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf irgendeine spezielle Technik zum Assoziieren einer Aussonderungsmaske mit einer Treffergruppe beschränkt sind.

In einer Ausführungsform sondert die Traversierungs-/Kreuzungsschaltungsanordnung 8003 potentielle Treffer basierend auf der materialbasierten Aussonderungsmaske 8701 direkt aus. Zum Beispiel kann ein Maskenwert von 0 angeben, dass Fälle mit einem entsprechenden Material ausgesondert werden sollten. Alternativ oder zusätzlich kann dieses Verhalten emuliert werden, indem irgendwelche Treffershader innerhalb des Treibers injiziert werden.

GEOMETRISCHER BILDBESCHLEUNIGER UND VERFAHREN

Ein Geometriebild ist eine Abbildung eines dreidimensionalen (3 D) Dreiecksnetzes auf eine zweidimensionale (2 D) Domäne. Insbesondere kann ein Geometriebild Geometrie als ein 2D-Array quantisierter Punkte repräsentieren. Entsprechende Bilddaten wie Farben und Normale können unter Verwendung der gleichen impliziten Oberflächenparametrisierung auch in 2D-Arrays gespeichert werden. Das durch das 2D-Array repräsentierte 2D-Dreiecksnetz ist durch ein regelmäßiges Gitter von Vertexpositionen mit impliziter Konnektivität definiert.

Ini einer Ausführungsform der Erfindung wird ein Geometriebild durch Abbilden eines 3D-Dreiecksnetzes in eine 2D-Ebene gebildet, was zu einer implizierten Dreieckskonnektivität führt, die durch ein regelmäßiges Gitter von Vertexpositionen definiert ist. Das resultierende 2D-Geometriebild kann auf verschiedene Weisen innerhalb der Grafikpipeline verarbeitet werden, einschließlich Downsampling und Upsampling unter Verwendung von Mipmaps.

Wie in 88 veranschaulicht, führt eine Ausführungsform der Erfindung eine Strahlverfolgung durch, indem eine Vierfachbaumstruktur 8855 über der Geometriebilddomäne erzeugt wird, wobei jeder Vierfachbaumknoten 8800, 8810-8813 einen achsenausgerichteten Begrenzungsrahmen (AABB) über den Vertexpositionen des 2D-Dreiecksnetzes 8820 speichert. Wie veranschaulicht, speichert jeder Knoten 8800, 8810-8813 die Minimal- und Maximalkoordinaten des assoziierten AABB, der eines oder mehrere der Dreiecke und/oder Vertices enthält. Dadurch ergibt sich eine äußerst regelmäßige und sehr einfach zu berechnende Struktur.

Sobald die AABBs über dem 2D-Dreiecksnetz konstruiert sind, können Raytracing-Operationen unter Verwendung der AABBs durchgeführt werden, wie hier mit Bezug auf die verschiedenen Ausführungsformen der Erfindung beschrieben. Zum Beispiel können Traversieroperationen durchgeführt werden, um zu bestimmen, dass ein Strahl einen der Knoten 8810-8813 der unteren Ebene des BVH quert. Der Strahl kann dann auf Schnittpunkte mit dem 2D-Gitter getestet werden und Trefferergebnisse (falls vorhanden), die wie hier beschrieben erzeugt und verarbeitet werden (z. B. gemäß einem Material, das mit dem 2D-Dreiecksgitter assoziiert ist).

Wie veranschaulicht, ist die Speicherungs-/Komprimierungslogik 8850 in einer Ausführungsform dazu konfiguriert, die AABBs als Doppelbildpyramiden 8855 zu komprimieren und/oder zu speichern, wobei eine die Minimalwerte speichert und eine die Maximalwerte speichert. In dieser Ausführungsform können unterschiedliche Komprimierungsschemata, die für Geometriebilder entwickelt wurden, verwendet werden, um die Minimal- und Maximalbildpyramiden zu komprimieren.

Die Vierfachbaum-Strukturen 8855, 8810-8813, die oben mit Bezug auf 88 beschrieben sind, können durch den BVH-Builder 8007 erzeugt werden. Alternativ dazu können die Vierfachbaum-Strukturen durch einen anderen Satz von Schaltungen und/oder Logik erzeugt werden.

VORRICHTUNG UND VERFAHREN ZUR Box-Box-PRÜFUNG UND BESCHLEUNIGTE KOLLISIONSDETEKTION ZUR STRAHLENVERFOLGUNG

89A-B veranschaulicht eine Strahlverfolgungsarchitektur gemäß einer Ausführungsform der Erfindung. Mehrere Ausführungseinheiten 8910 führen Shader und anderen Programmcode in Bezug auf Raytracing-Operationen aus. Eine „Traceray“-Funktion, die auf einer der Ausführungseinheiten (EUs) 8910 ausgeführt wird, löst einen Strahlenzustandsinitialisierer 8920 aus, den Zustand zu initialisieren, der erforderlich ist, um einen aktuellen Strahl (identifiziert über eine Strahl-ID/Deskriptor) durch eine Bounding Volume Hierarchy (BVH) zu verfolgen (z. B. gespeichert in einem in einem Stapel 5121 in einem Speicherpuffer 8918 oder einer anderen Datenstruktur in einem lokalen oder Systemspeicher 3198).

Falls die Traceray-Funktion einen Strahl identifiziert, für den eine vorherige Traversieroperation teilweise abgeschlossen wurde, dann verwendet der Zustandsinitialisierer 8920 in einer Ausführungsform die eindeutige Strahl-ID, um die assoziierten Strahlverfolgungsdaten 4902 und/oder Stapel 5121 aus einem oder mehreren Puffern 8918 in den Speicher 3198 zu laden. Wie erwähnt, kann der Speicher 3198 ein On-Chip/lokaler Speicher oder Cache und/oder eine Systemebene-Speichervorrichtung sein.

Wie mit Bezug auf andere Ausführungsformen besprochen, kann ein Tracking-Array 5249 beibehalten werden, um den Traversierungsfortschritt für jeden Strahl zu speichern. Falls der aktuelle Strahl teilweise eine BVH durchlaufen hat, dann kann der Zustandsinitialisierer 8920 das Tracking-Array 5249 verwenden, um den BVH-Pegel/Knoten zu bestimmen, bei dem neu gestartet werden soll.

Eine Traversierungs- und Raybox-Testeinheit 8930 durchläuft den Strahl durch die BVH. Wenn ein Primitiv innerhalb eines Blattknotens des BVH identifiziert wurde, testet der Instanz-/Viereck-Schnittprüfer 8940 den Strahl auf Schnittpunkt mit dem Primitiv (z. B. ein oder mehrere Primitiv-Vierecke), wobei eine assoziierter Strahl-/Shader-Aufzeichnung aus einem Strahlverfolgungs-Cache 8960 abgerufen wird, der innerhalb der Cache-Hierarchie des Grafikprozessors (hier mit einem L1-Cache 8970 gekoppelt gezeigt) integriert ist. Der Instanz-/Viereck-Schnittpunkt-Tester 8940 wird hier manchmal einfach als eine Kreuzungseinheit (z. B. Kreuzungseinheit 5103 in 51) bezeichnet.

Die Ray/Shader-Aufzeichnung wird einem Thread-Dispatcher 8950 bereitgestellt, der neue Threads an die Ausführungseinheiten 8910 zumindest teilweise unter Verwendung der hier beschriebenen bindungslosen Thread-Dispatching-Techniken sendet. In einer Ausführungsform weist die Strahl/Box-Traversiereinheit 8930 die oben beschriebene Traversier-/Stapelverfolgungslogik 5248 auf, die den Traversierungsfortschritt für jeden Strahl innerhalb des Verfolgungsarrays 5249 verfolgt und speichert.

Eine Klasse von Problemen beim Rendern kann auf Testboxkollisionen mit anderen Begrenzungsvolumina oder -boxen abgebildet werden (z. B. aufgrund von Überlappung). Solche Box-Anfragen können verwendet werden, um Geometrie innerhalb eines Anfrage-Begrenzungsrahmens für verschiedene Anwendungen aufzuzählen. Beispielsweise können Box-Anfragen verwendet werden, um Photonen während der Photonenkartierung zu sammeln, alle Lichtquellen aufzuzählen, die einen Abfragepunkt (oder ein Abfragegebiet) beeinflussen können, und/oder nach dem Oberflächenpunkt, der einem Abfragepunkt am nächsten liegt, zu suchen. In einer Ausführungsform arbeiten die Box-Abfragen an derselben BVH-Struktur wie die Strahlenabfragen; dementsprechend kann der Benutzer Strahlen durch eine Szene verfolgen und Box-Abfragen an derselben Szene durchführen.

In einer Ausführungsform der Erfindung werden Box-Anfragen ähnlich wie Ray-Anfragen in Bezug auf Strahlverfolgungshardware/-software behandelt, wobei die Ray/Box-Traversiereinheit 8930 eine Traversierung unter Verwendung von Box-Box-Operationen anstelle von Ray/Box-Operationen durchführt. In einer Ausführungsform kann die Traversiereinheit 8930 denselben Satz von Merkmalen für Box/Box-Operationen verwenden, wie sie für Ray/Box-Operationen verwendet werden, einschließlich unter anderem Bewegungsunschärfe, Masken, Flags, Shader mit nächstem Treffer, beliebige Treffershader, Fehltreffershader und Traversierungs-Shader. Eine Ausführungsform der Erfindung fügt zu jeder Strahlverfolgungsnachricht oder -anweisung (z. B. TraceRay, wie hier beschrieben) ein Bit hinzu, um anzugeben, dass die Nachricht/Anweisung mit einer BoxQuery-Operation assoziiert ist. Bei einer Implementierung wird BoxQuery sowohl im synchronen als auch im asynchronen Strahlverfolgungsmodus (z. B. unter Verwendung von Standard-Dispatch-bzw. bindungslosen Thread-Dispatchoperationen) aktiviert.

In einer Ausführungsform interpretiert die Strahlverfolgungshardware/-Software (z. B. Traversiereinheit 8930, Instanz-/Viererschnittsprüfer 8940 usw.), sobald sie über das Bit auf den BoxQuery-Modus eingestellt ist, die Daten, die mit der Strahlverfolgungsnachricht/Anweisung assoziiert sind, als Box-Daten (z. B. min/max Werte in drei Dimensionen). In einer Ausführungsform werden Querbeschleunigungsstrukturen erzeugt und beibehalten, wie zuvor beschrieben, aber eine Box wird anstelle eines Strahls für jede primäre Stapel-ID initialisiert.

In einer Ausführungsform wird Hardware-Instanzierung nicht für Box-Anfragen durchgeführt. Instanzierung kann jedoch in Software unter Verwendung von Traversal-Shadern emuliert werden. Wenn somit ein Instanzknoten während einer Box-Abfrage erreicht wird, kann die Hardware den Instanzknoten als prozeduralen Knoten verarbeiten. Da der Header beider Strukturen derselbe ist, bedeutet dies, dass die Hardware den in dem Header des Instanzknotens gespeicherten Shader aufrufen wird, der dann die Punktanfrage innerhalb der Instanz fortsetzen kann.

In einer Ausführungsform wird ein Strahlen-Flag gesetzt, um anzugeben, dass der Instanz-/Viereck-Schnittpunkt-Tester 8940 den ersten Treffer akzeptieren wird und die Suche beendet (z. B.
ACCEPT_FIRST_HIT AND_END_SEARCH-Flag). Wenn dieses Strahlen-Flag nicht gesetzt ist, werden die geschnittenen Kinder von vorne nach hinten gemäß ihrem Abstand zum Abfragefach eingegeben, ähnlich wie die Strahlenabfragen. Beim Suchen nach der Geometrie, die einem Punkt am nächsten liegt, verbessert diese Traversierungsreihenfolge die Leistungsfähigkeit signifikant, wie dies bei Strahlenabfragen der Fall ist.

Eine Ausführungsform der Erfindung filtert falsch positive Treffer mit beliebigen Treffer-Shadern aus. Obwohl Hardware zum Beispiel möglicherweise keinen genauen Box-/Dreieckstest auf Blattebene durchführt, wird sie konservativ alle Dreiecke eines Trefferblattknotens melden. Ferner kann Hardware, wenn die Suchbox durch einen beliebigen Treffer-Shader geschrumpft wird, Primitive eines gepoppten Blattknotens als Treffer zurückgeben, obwohl die Blattknotenbox möglicherweise nicht mehr mit der geschrumpften Abfragebox überlappt.

Wie in 89A angegeben, kann eine Box-Abfrage durch die Ausführungseinheit (EU) 8910 ausgegeben werden, die eine Nachricht/einen Befehl an die Hardware (d. h. Traceray) sendet. Die Verarbeitung läuft dann wie oben beschrieben - d. h. durch den Zustandsinitialisierer 8920, die Strahl/Box-Traversierlogik 8930, den Instanz-/Viereck-Schnittpunkt-Tester 8940 und den bindungslosen Thread-Dispatcher 8950 fort.

In einer Ausführungsform verwendet die Box-Abfrage das MemRay-Datenlayout, wie es für Strahlenabfragen verwendet wird, durch Speichern der Untergrenzen der Abfragebox in der gleichen Position wie der Strahlenursprung, der Obergrenzen in der gleichen Position wie die Strahlenrichtung und eines Abfrageradius in den Fernwert.

Unter Verwendung dieses MemBox-Layouts verwendet die Hardware die Box [unterer Radius, oberer+Radius], um die Abfrage durchzuführen. Daher werden die gespeicherten Grenzen in jeder Dimension um einen Radius in der L0-Norm erweitert. Dieser Anfrageradius kann nützlich sein, um den Suchbereich leicht zu verkleinern, z. B. für nächste Punktsuchen.

Da das MemBox-Layout gerade den Strahlenursprung, die Strahlenrichtung und die T_far-Mitglieder des MemRay-Layouts wiederverwendet, muss die Datenverwaltung in Hardware für Strahlenabfragen nicht geändert werden. Stattdessen werden die Daten in der internen Speicherung (z. B. dem Strahlverfolgungs-Cache 8960 und L1-Cache 8970) wie die Strahldaten gespeichert und werden nur für Box/Box-Tests anders interpretiert.

In einer Ausführungsform werden die folgenden Operationen durch die Strahl/Zustands-Initialisierungseinheit 8920 und die Strahl/Box-Traversiereinheit 8930 durchgeführt. Das zusätzliche Bit „BoxQueryEnable“ aus der TraceRay-Nachricht wird in dem Zustandsinitialisierer 8920 pipettiert (was seine Kompaktierung über Nachrichten hinweg beeinflusst), wodurch jeder Strahl/Box-Traversiereinheit 8930 eine Angabe der BoxQueryEnable-Einstellung bereitgestellt wird.

Die Strahl/Box-Traversiereinheit 8930 speichert „BoxQueryEnable“ mit jedem Strahl, wobei dieses Bit als ein Tag mit der anfänglichen Strahlenlastanforderung gesendet wird. Wenn die angeforderten Strahldaten von der Speicherschnittstelle zurückgegeben werden, wird bei eingestelltem BoxQueryEnable eine reziproke Berechnung umgangen und stattdessen eine andere Konfiguration für alle Komponenten in dem RayStore geladen (d. h. gemäß einer Box anstelle eines Strahls).

Die Strahl/Box-Traversiereinheit 8930 leitet das BoxQueryEnable Bit an die darunterliegende Testlogik weiter. In einer Ausführungsform wird der Raybox-Datenpfad gemäß den folgenden Konfigurationseinstellungen modifiziert. Falls BoxQueryEnable == 1, wird die Ebene des Kastens nicht geändert, da sie sich basierend auf dem Vorzeichen der x-, y- und z-Komponenten der Strahlrichtung ändert. Für den Strahl durchgeführte Prüfungen, die für die Raybox unnötig sind, werden umgangen. Zum Beispiel wird angenommen, dass die anfragende Box keine unendlichen (INF) oder Nicht-a-Number (NAN) Datentypen aufweist, so dass diese Prüfungen in dem Datenpfad umgangen werden.

In einer Ausführungsform wird vor der Verarbeitung durch die Trefferbestimmungslogik eine weitere Additionsoperation durchgeführt, um den Wert unterer + Radius (im Wesentlichen den t-Wert aus dem Treffer) und oberen - Radius zu bestimmen. Außerdem berechnet er beim Treffen eines „Instanzknotens“ (in einer Hardware-Instanziierungsimplementierung) keine Transformation, sondern startet stattdessen einen Kreuzungs-Shader unter Verwendung einer Shader-ID in dem Fallknoten.

In einer Ausführungsform führt, wenn BoxQueryEnable eingestellt ist, die Strahl/Box-Traversiereinheit 8930 die NULL-Shader-Suche für irgendeinen Treffer-Shader nicht durch. Außerdem ruft die Strahl/Box-Traversiereinheit 8930, wenn BoxQueryEnable gesetzt ist, wenn ein gültiger Knoten vom Viereck-Meshlet-Typ ist, einen Kreuzungs-Shader ebenso auf, wie er nach dem Aktualisieren der potentiellen Trefferinformationen im Speicher einen BELIEBIGER-TREFFER-SHADER aufrufen würde.

In einer Ausführungsform ist ein separater Satz der verschiedenen in 89A veranschaulichten Komponenten in jeder Mehrkerngruppe 3100A (z. B. innerhalb der Strahlverfolgungskerne 3150) bereitgestellt. Bei dieser Implementierung kann jede Mehrkerngruppe 3100A parallel an einem anderen Satz von Strahldaten und/oder Boxdaten arbeiten, um Traversier- und Schnittoperationen durchzuführen, wie hier beschrieben.

VORRICHTUNG UND VERFAHREN FÜR MESHLET-

KOMPRIMIERUNG UND DEKOMPRIMIERUNG FÜR STRAHLVERFOLGUNG

Wie oben beschrieben, ist ein „Meshlet“ eine Teilmenge eines Netzes, das durch Geometriepartitionierung erzeugt wird, die eine gewisse Anzahl von Vertices (z. B. 16, 32, 64, 256 usw.) basierend auf der Anzahl von assoziierten Attributen aufweist. Meshlets können so ausgelegt sein, dass sie möglichst viele Vertices teilen, um eine Vertexwiederverwendung während des Renderns zu ermöglichen. Diese Partitionierung kann vorberechnet werden, um eine Laufzeitverarbeitung zu vermeiden, oder kann jedes Mal, wenn ein Netz gezogen wird, dynamisch zur Laufzeit durchgeführt werden.

Eine Ausführungsform der Erfindung führt eine Meshletkomprimierung durch, um den Speicherbedarf für die Beschleunigungsstrukturen der unteren Ebene (BLASs) zu reduzieren. Diese Ausführungsform macht sich die Tatsache zunutze, dass ein Mesh ein kleines Stück eines größeren Netzes mit ähnlichen Vertices repräsentiert, um eine effiziente Komprimierung innerhalb eines 128B-Datenblocks zu ermöglichen. Es ist jedoch anzumerken, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf irgendeine spezielle Blockgröße beschränkt sind.

Meshlet-Komprimierung kann zu dem Zeitpunkt durchgeführt werden, zu dem die entsprechende Bounding Volume Hierarchy (BVH) aufgebaut und an dem BVH-Verbrauchspunkt dekomprimiert wird (z. B. durch den Strahlverfolgungshardwareblock). Bei bestimmten Ausführungsformen, die unten beschrieben sind, wird eine Meshlet-Dekomprimierung zwischen dem L1-Cache (manchmal „LSC Unit“) und dem Raytracing-Cache (manchmal „RTC Unit“) durchgeführt. Wie hier beschrieben, ist der Strahlverfolgungs-Cache ein lokaler Hochgeschwindigkeits-Cache, der durch die Strahltraversierungs-/Kreuzungshardware verwendet wird.

In einer Ausführungsform wird die Meshlet-Komprimierung in Hardware beschleunigt. Falls zum Beispiel der Ausführungseinheits(EU)-pfad eine Dekomprimierung unterstützt (z. B. potentiell eine Traversal-Shader-Ausführung zu unterstützen), kann eine Meshlet-Dekomprimierung in den gemeinsamen Pfad aus dem L1-Cache integriert werden.

In einer Ausführungsform wird eine Nachricht verwendet, um eine Meshlet-Komprimierung auf 128 B-Blöcke im Speicher zu initiieren. Zum Beispiel kann eine 4 X 64 B Nachrichteneingabe zu einer 128B-Blockausgabe an den Shader komprimiert werden. Bei dieser Implementierung wird ein zusätzlicher Knotentyp in der BVH hinzugefügt, um eine Assoziation mit einem komprimierten Meshlet anzugeben.

89B veranschaulicht eine spezielle Implementierung zur Meshlet-Komprimierung einschließlich eines Meshlet-Komprimierungsblocks (RTMC) 9030 und eines Meshlet-Dekomprimierungsblocks (RTMD) 9090, die innerhalb des Strahlverfolgungs-Clusters integriert sind. Meshlet-Komprimierung 9030 wird aufgerufen, wenn eine neue Nachricht von einer Ausführungseinheit 8910, die einen Shader ausführt, zu dem Strahlverfolgungscluster (z. B. innerhalb eines Strahlverfolgungskerns 3150) übertragen wird. In einer Ausführungsform weist die Nachricht vier 64B-Phasen und eine 128B-Schreibadresse auf. Die Nachricht von der EU 8910 weist den Meshlet-Komprimierungsblock 9030 an, wo die Vertices und zugehörigen Meshlet-Daten im lokalen Speicher 3198 (und/oder Systemspeicher je nach Implementierung) lokalisiert werden sollen. Der Meshlet-Komprimierungsblock 9030 führt dann eine Meshlet-Komprimierung durch, wie hier beschrieben. Die komprimierten Meshlet-Daten können dann über die Speicherschnittstelle 9095 in dem lokalen Speicher 3198 und/oder dem Strahlverfolgngs-Cache 8960 gespeichert werden und auf die der Instanz-/Viereck-Schnittpunkt-Tester 8940 und/oder ein Traversier-/Schnittpunkt-Shader zugreifen.

In 89B kann der Meshlet-Sammel- und - Dekomprimierungsblock 9090 die komprimierten Daten für ein Meshlet sammeln und die Daten in mehrere 64B-Blöcke dekomprimieren. Bei einer Implementierung werden nur dekomprimierte Meshlet-Daten innerhalb des L1-Caches 8970 gespeichert. In einer Ausführungsform wird die Meshlet-Dekomprimierung aktiviert, während die BVH-Knoten-Daten basierend auf dem Knotentyp (z. B. Blattknoten, komprimiert) und der Primitiv-ID abgerufen werden. Der Traversal-Shader kann auch unter Verwendung der gleichen Semantik wie der Rest der Raytracing-Implementierung auf das komprimierte Meshlet zugreifen.

In einer Ausführungsform nimmt der Meshlet-Komprimierungsblock 9030 ein Array von Eingangsdreiecken von einer EU 8910 an und erzeugt eine komprimierte 128B Meshlet-Blattstruktur. Ein Paar aufeinanderfolgender Dreiecke in dieser Struktur bildet ein Viereck. Bei einer Implementierung weist die EU-Nachricht bis zu 14 Vertices und Dreiecke auf, wie in der Codesequenz unten angegeben. Das komprimierte Meshlet wird über die Speicherschnittstelle 9095 an der in der Nachricht vorgesehenen Adresse in den Speicher geschrieben.

In einer Ausführungsform berechnet der Shader das Bit-Budget für den Satz von Meshlets und daher wird die Adresse so bereitgestellt, dass eine Fußabdruckkomprimierung möglich ist. Diese Nachrichten werden nur für komprimierbare Meshlets initiiert.

In einer Ausführungsform dekomprimiert der Meshlet-Dekomprimierungsblock 9090 zwei aufeinanderfolgende Vierecke (128B) von einem 128B-Meshlet und speichert die dekomprimierten Daten in dem L1-Cache 8970. Die Tags im L1-Cache 8970 verfolgen den Index jedes dekomprimierten Vierecks (einschließlich des Dreiecksindex) und die Meshlet-Adresse. Der Strahlverfolgungs-Cache 8960 sowie eine EU 8910 können ein 64B-dekomprimiertes Viereck aus dem L1-Cache 8970 holen. In einer Ausführungsform holt eine EU 8910 ein dekomprimiertes Viereck durch Ausgeben einer MeshletQuadFetch-Nachricht an den L1-Cache 8960, wie unten gezeigt. Separate Nachrichten können zum Abrufen der ersten 32 Bytes und der letzten 32 Bytes des Vierecks ausgegeben werden.

Shader können auf Dreiecksvertices von der Viereckstruktur zugreifen, wie unten gezeigt ist. In einer Ausführungsform werden die „IF“ - Anweisungen durch „sel“ -Anweisungen ersetzt.

In einer Ausführungsform kann der Strahlverfolgungs-Cache 8960 ein dekomprimiertes Viereck direkt aus der L1-Cache-Bank 8970 abrufen, indem die Meshlet-Adresse und der Viereck-Index bereitgestellt werden.

Meshlet-Komprimierungsverfahren

Nach dem Zuweisen von Bits für einen festen Overhead, wie etwa geometrische Eigenschaften (z. B. Flags und Masken), werden Daten des Netzes zu dem komprimierten Block hinzugefügt, während das verbleibende Bit-Budget basierend auf Deltas an (pos.x, pos.y, pos.z) im Vergleich zu (base.x, base.y, base.z), wo die Basiswerte die Position des ersten Vertex in der Liste umfassen, berechnet wird. Ebenso können auch Prim-ID-Deltas berechnet werden. Da das Delta mit dem ersten Vertex verglichen wird, ist es kostengünstiger, mit geringer Latenz zu dekomprimieren. Die Basisposition und primIDs sind Teil des konstanten Overhead in der Datenstruktur zusammen mit der Breite der Delta-Bits. Für verbleibende Vertices eines geradzahligen Dreiecks werden Positionsdeltas und Prim-ID-Deltas auf verschiedenen 64B-Blöcken gespeichert, um sie parallel zu packen.

Unter Verwendung dieser Techniken verbraucht die BVH-Aufbauoperation beim Herausschreiben der komprimierten Daten über die Speicherschnittstelle 9095 eine geringere Bandbreite in den Speicher. Außerdem ermöglicht das Speichern des komprimierten Meshlets in dem L3-Cache in einer Ausführungsform das Speichern von mehr BVH-Daten mit derselben L3-Cache-Größe. In einer Arbeitsausführung werden mehr als 50% Meshlets 2:1 komprimiert. Während eine BVH mit komprimierten Meshlets verwendet wird, führt eine Bandbreiteneinsparung im Speicher zu Energieeinsparungen.

VORRICHTUNG UND VERFAHREN ZUM BINDELOSEN THREAD-SENDEN UND ARBEITSGRUPPE/THREAD PRÄEMPTION IN EINER RECHEN- UND STRAHLENVERFOLGUNGS-PIPELINE

Wie oben beschrieben, ist bindungsloses Thread-Dispatch (BTD) ein Weg zum Lösen des SIMD-Divergenzproblems für Strahlverfolgung in Implementierungen, die gemeinsam genutzten lokalen Speicher (SLM) oder Speicherbarrieren nicht unterstützen. Ausführungsformen der Erfindung umfassen Unterstützung für verallgemeinerte BTD, die verwendet werden können, um SIMD-Divergenz für verschiedene Rechenmodelle zu adressieren. In einer Ausführungsform kann jede Rechenabfertigung mit einer Thread-Gruppenbarriere und SLM einen bindungslosen Kind-Thread hervorrufen und alle Threads können über BTD umgruppiert und abfertigt werden, um die Effizienz zu verbessern. Bei einer Implementierung ist ein bindungsloser Kind-Thread zu einer Zeit pro Eltern erlaubt und den Ursprungsthreads erlaubt, ihren SLM-Raum mit den bindungslosen Kind-Threads zu teilen. Sowohl SLM als auch Barrieren werden nur freigegeben, wenn schließlich konvergierte Eltern enden (d. h. EOTs durchführen). Eine bestimmte Ausführungsform ermöglicht eine Verstärkung innerhalb eines aufrufbaren Modus, der Baumdurchlauffälle mit mehr als einem Kind, das erzeugt wird, ermöglicht.

90 veranschaulicht graphisch einen anfänglichen Satz von Threads 9000, die synchron durch die SIMD-Pipeline verarbeitet werden können. Die Threads 9000 können zum Beispiel synchron als eine Arbeitsgruppe versandt und ausgeführt werden. In dieser Ausführungsform kann der anfängliche Satz synchroner Threads 9000 jedoch mehrere divergierende erzeugte Threads 9001 erzeugen, die andere Erzeugungsthreads 9011 innerhalb der hier beschriebenen asynchronen Strahlverfolgungsarchitekturen erzeugen können. Schließlich kehren konvergierende erzeugte Threads 9021 zu dem ursprünglichen Satz von Threads 9000 zurück, der dann die synchrone Ausführung fortsetzen kann, wobei der Kontext nach Bedarf gemäß dem Tracking-Array 5249 wiederhergestellt wird.

In einer Ausführungsform unterstützt eine BTD-Funktion (BTD: Bindless Thread Dispatch) SIMD16- und SIMD32-Modi, GPR-Nutzung (GPR: Variable Universal Register), gemeinsam genutzter lokaler Speicher (SLM: Shared Local Memory) und BTD-Barrieren durch Fortbestehen durch die Wiederaufnahme des Eltern-Threads nach Ausführung und Abschluss (Nachdivergieren und dann konvergieren lassen). Eine Ausführungsform der Erfindung umfasst eine hardwareverwaltete Implementierung zum Wiederaufnehmen der Eltern-Threads und eine softwareverwaltete Dereferenz der SLM- und Barriereressourcen.

In einer Ausführungsform der Erfindung haben die folgenden Begriffe die folgenden Bedeutungen:

Aufrufmodus: Threads, die durch bindungslosen Thread-Versand erzeugt werden, befinden sich im „Aufrufmodus“. Diese Threads können auf den vererbten gemeinsamen lokalen Speicherplatz zugreifen und im aufrufbaren Modus optional einen Thread pro Thread erzeugen. In diesem Modus haben Threads keinen Zugriff auf die Barriere auf Arbeitsgruppenebene.

Arbeitsgruppen(WG)-modus: Wenn Threads auf die gleiche Weise mit konstituierenden SIMD-Spuren ausgeführt werden, wie sie durch die Standardthreadversandung versandt werden, werden sie als in dem Arbeitsgruppenmodus befindlich definiert. In diesem Modus haben Threads Zugriff auf Barrieren auf Arbeitsgruppenebene sowie gemeinsam genutzten lokalen Speicher. In einer Ausführungsform wird der Thread-Dispatch als Reaktion auf einen „Computer-Walker“-Befehl initiiert, der einen Nur-Rechen-Kontext initiiert.

Gewöhnliche Erzeugung: Auch als reguläre erzeugte Threads 9011 (90) bezeichnet, werden gewöhnliche erzeugte Threads immer dann initiiert, wenn ein aufrufbarer anderer aufruft. Solche erzeugten Threads werden im aufrufbaren Modus betrachtet.

Divergierend Erzeugung: Wie in 90 gezeigt, werden divergierende erzeugte Threads 9001 ausgelöst, wenn ein Thread von dem Arbeitsgruppenmodus in den aufrufbaren Modus übergeht. Divergente Erzeugungsargumente sind die SIMD-Breite und Festfunktions-Thread-ID (FFTID: Fixed Function Thread), die untergruppeneinheitlich sind.

Konvergierend gespart: Konvergierende erzeugte Threads 9021 werden ausgeführt, wenn ein Thread vom aufrufbaren Modus zurück in den Arbeitsgruppenmodus übergeht. Konvergierende Erzeugungsargumente sind eine pro Spur FFTID und eine Maske, die angibt, ob der Stapel der Spur leer ist oder nicht. Diese Maske muss dynamisch berechnet werden, indem der Wert des pro-line-Stapelzeigers an der Rücksprungstelle überprüft wird. Der Compiler muss diese Maske berechnen, da sich diese aufrufbaren Threads rekursiv gegenseitig aufrufen können. Spuren in einer konvergierenden Erzeugung, bei denen das Konvergenzbit nicht gesetzt ist, verhalten sich wie gewöhnliche Erzeugungen.

Das bindungslose Thread-Dispatch löst das SIMD-Divergenzproblem für Strahlverfolgung in manchen Implementierungen, die keine gemeinsam genutzten lokalen Speicher- oder Barriereoperationen erlauben. Außerdem wird in einer Ausführungsform der Erfindung BTD verwendet, um SIMD-Divergenz unter Verwendung einer Vielzahl von Rechenmodellen zu adressieren. Insbesondere kann eine beliebige Rechenabfertigung mit einer Thread-Gruppenbarriere und gemeinsam genutztem lokalen Speicher bindungslose Kind-Threads (z. B. jeweils ein Kind-Thread pro Eltern) hervorrufen und alle gleichen Threads können durch BTD für eine bessere Effizienz neu gruppiert und abfertigt werden. Diese Ausführungsform ermöglicht es, dass die Ursprungs-Threads ihren gemeinsamen lokalen Speicherplatz mit ihren Kind-Threads teilen. Die gemeinsam genutzten lokalen Speicherzuweisungen und -barrieren werden erst freigegeben, wenn schließlich konvergierte Eltern enden (wie durch End-of-Thread(EOT)-Indikatoren angezeigt). Eine Ausführungsform der Erfindung stellt auch eine Verstärkung innerhalb eines aufrufbaren Modus bereit, was Baumtraversierungsfälle ermöglicht, bei denen mehr als ein Kind erzeugt wird.

Obwohl dies nicht darauf beschränkt ist, ist eine Ausführungsform der Erfindung auf einem System implementiert, bei dem Unterstützung zur Verstärkung durch eine beliebige SIMD-Spur bereitgestellt wird (d. h. nur eine einzige ausstehende SIMD-Spur in der Form eines divergierenden oder konvergierenden erzeugten Threads ermöglicht). Zusätzlich dazu wird bei einer Implementierung die 32 b von (FFTID, BARRIER_ID, SLM_ID) beim Senden eines Threads an den BTD-fähigen Dispatcher 8950 gesendet. In einer Ausführungsform werden alle diese Räume freigegeben, bevor die Threads gestartet werden und diese Informationen an den bindungslosen Thread-Dispatcher 8950 gesendet werden. In einer Implementierung ist jeweils nur ein einziger Kontext aktiv. Daher kann ein Roog-Kernel selbst nach dem Tempern des FFTID nicht auf den Adressraum des anderen Kontexts zugreifen.

In einer Ausführungsform werden, falls Stapel-ID-Zuweisung aktiviert ist, gemeinsam genutzter lokaler Speicher und Barrieren nicht mehr dereferenziert, wenn ein Thread endet. Stattdessen werden sie nur dereferenziert, wenn alle assoziierten Stapel-IDs freigegeben wurden, wenn der Thread endet. Eine Ausführungsform verhindert FFTID(Fixed Function Thread ID)-Lecks, indem sichergestellt wird, dass Stapel-IDs ordnungsgemäß freigegeben werden.

In einer Ausführungsform werden Barrierenachrichten so spezifiziert, dass sie explizit eine Barriere-ID aus dem sendenden Thread entnehmen. Dies ist notwendig, um eine Barriere/SLM-Nutzung nach einem bindungslosen Thread-Dispatch-Aufruf zu ermöglichen.

91 veranschaulicht eine Ausführungsform einer Architektur zum Durchführen von bindungslosem Threadversand und Thread-/Arbeitsgruppenbevorrechtigung, wie hier beschrieben. Die Ausführungseinheiten (EU) 8910 dieser Ausführungsform unterstützen direkte Manipulation der Thread-Ausführungsmaske 9150-9153 und jede BTD-Erzeugungsnachricht unterstützt FFTID-Referenzzählung zum erneuten Erzeugen eines Eltern-Threads nach Abschluss der konvergierenden Erzeugung 9021. Dementsprechend unterstützt die hier beschriebene Strahlverfolgungsschaltungsanordnung zusätzliche Nachrichtenvarianten für BTD-Erzeugungs- und TraceRay-Nachrichten. In einer Ausführungsform führt der BTD-fähige Dispatcher 8950 eine Pro-FFTID-Zählung (wie durch Thread-Dispatch zugewiesen) ursprünglicher SIMD-Spuren auf divergierenden erzeugten Threads 9001 und zählt für konvergierende erzeugte Threads 9021 herunter, um die Wiederaufnahme der Eltern-Threads 9000 zu starten.

Verschiedene Ereignisse können während der Ausführung gezählt werden, einschließlich unter anderem regulärer Erzeugungsausführungen 9011; divergierender Erzeugungsausführungen 9001; konvergierender Erzeugungsereignisse 9021; eines FFTID-Zählers, der eine minimale Schwelle erreicht (z. B. 0); und für diesen durchgeführter Lasten (FFTID, BARRIER_ID, SLM_ID).

In einer Ausführungsform werden gemeinsam genutzter lokaler Speicher (SLM) und Barrierezuweisung mit BTD-aktivierten Threads (d. h. zu Honor ThreadGroup-Semantik) erlaubt. Der BTD-fähige Thread-Dispatcher 8950 entkoppelt die FFTID-Freigabe und die Barriere-ID-Freigabe von den End-of-Thread(EOT)-Anzeigen (z. B. über spezifische Nachrichten).

In einer Ausführungsform wird, um aufrufbare Shader von Rechen-Threads zu unterstützen, ein treiberverwalteter Puffer 9170 verwendet, um Arbeitsgruppeninformationen über die bindungslosen Thread-Dispatches hinweg zu speichern. Bei einer bestimmten Implementierung weist der treiberverwaltete Puffer 9170 mehrere Einträge auf, wobei jeder Eintrag mit einer anderen FFTID assoziiert ist.

In einer Ausführungsform werden innerhalb des Zustandsinitialisierers 8920 zwei Bits zugewiesen, um den erzeugten Pipeline-Typ anzugeben, der für Nachrichtenkompaktierung berücksichtigt wird. Zum Divergieren von Nachrichten berücksichtigt der Zustandsinitialisierer 8920 auch die FFTID von der Nachricht und Pipelines mit jeder SIMD-Spur zu dem Strahl/Box-Traversierungsblock 8930 oder dem bindungslosen Thread-Dispatcher 8950. Zum Konvergieren von Erzeugung 9021 gibt es eine FFTID für jede SIMD-Spur in der Nachricht und eine Pipeline-FFTID mit jeder SIMD-Spur für die Strahl/Box-Traversiereinheit 8930 oder den bindungslosen Thread-Dispatcher 8950. In einer Ausführungsform leitet die Strahl/Box-Traversiereinheit 8930 auch Pipelines vom Erzeugungstyp, einschließlich konvergierender Erzeugung 9021. Insbesondere Pipelines und speichert in einer Ausführungsform die Strahl/Box-Traversiereinheit 8930 die FFTID mit jedem Strahl konvergierend 9021 für TraceRay Nachrichten.

In einer Ausführungsform weist der Thread-Dispatcher 8950 eine dedizierte Schnittstelle auf, um die folgende Datenstruktur in Vorbereitung des Dispatchens eines neuen Threads mit dem gesetzten bindungslosen Thread-Dispatch-Freigabebit bereitzustellen:

            Struct tsl_sts_inf { // non-stallable interface
                 Logic[8] FFTID;
                 Logic[8] BARRIER_ID;
                 Logic[8] SLM_ID;
                 Logic[8] count_valid_simd_lanes;
           }

Der bindungslose Thread-Dispatcher 8950 verarbeitet auch die Ende-of-Thread(EOT)-Nachricht mit drei zusätzlichen Bits: Release_FFTID, Release_BARRIER_ID, Release_SLM_ID. Wie erwähnt, gibt die Ende-of-Thread(EOT)-Nachricht nicht notwendigerweise alle den IDs zugeordneten Zuordnungen frei/dereferenziert, sondern nur die Zuordnungen mit einem gesetzten Freigabebit. Ein typischer Anwendungsfall ist, wenn eine divergierende Erzeugung 9001 initiiert wird, der Erzeugungsthread eine EOT-Nachricht erzeugt, aber das Freigabebit nicht gesetzt ist. Seine Fortsetzung nach der konvergierenden Erzeugung 9021 wird eine andere EOT-Nachricht erzeugen, diesmal jedoch mit dem Freigabebit gesetzt. Erst in diesem Stadium werden alle pro-Thread-Ressourcen rezykliert.

In einer Ausführungsform implementiert der bindungslose Thread-Dispatcher 8950 eine neue Schnittstelle, um die FFTID, die BARRIER_ID, die SLM_ID und die Spurenzahl zu laden. Sie speichert alle diese Informationen in einem FFTID-adressierbaren Speicher 9121, der eine gewisse Anzahl von Einträgen tief ist (max_fftid, 144 Einträge tief in einer Ausführungsform). Bei einer Implementierung verwendet der BTD-fähige Dispatcher 8950 als Reaktion auf irgendeine reguläre Erzeugung 9011 oder divergierende Erzeugung 9001 diese Identifikationsinformationen für jede SIMD-Spur, führt Anfragen an die FFTID-adressierbare Speicherung 9121 auf einer Pro-FFTID-Basis durch und speichert die Thread-Daten in dem Sortierpuffer, wie oben beschrieben (siehe z. B. inhaltsadressierbarer Speicher 4201 in 42). Dies führt zum Speichern einer zusätzlichen Datenmenge (z. B. 24 Bits) in dem Sortierpuffer 4201 pro SIMD-Spur.

Beim Empfangen einer konvergierenden erzeugten Nachricht wird für jede SIMD-Spur von dem Zustandsinitialisierer 8920 oder dem Strahl/Box-Traversierungsblock 8930 zu dem bindungslosen Thread-Dispatcher 8950 die Pro-FFTID-Zählung dekrementiert. Wenn der FFTID-Zähler eines gegebenen Elternteils null wird, wird der gesamte Thread mit ursprünglichen Ausführungsmasken 9150-9153 geplant. Eine Fortsetzungs-Shader-Aufzeichnung 4201 wird durch die konvergierende erzeugte Nachricht in der Sortierschaltung 4008 bereitgestellt.

Verschiedene Ausführungsformen der Erfindung können nach verschiedenen Ausgestaltungen arbeiten. In einer Ausführungsform müssen zum Beispiel alle divergierenden Erzeugungen 9001, die durch einen Thread durchgeführt werden, übereinstimmende SIMD-Breiten aufweisen. Zusätzlich darf in einer Ausführungsform eine SIMD-Spur keine konvergierenden Erzeugung 9021 durchführen, wobei das ConvergenceMask Bit innerhalb der relevanten Ausführungsmaske 9150-9153 gesetzt ist, es sei denn, dass ein früherer Thread eine divergierenden Erzeugung mit demselben FFTID durchgeführt hat. Wird eine divergierende Speiche 9001 mit einer gegebenen Stapel-ID durchgeführt, so muss eine konvergierende Speiche 9021 vor der nächsten divergierenden Speiche auftreten.

Falls irgendeine SIMD-Spur in einem Thread eine divergierende Erzeugung durchführt, dann müssen alle Spuren letztendlich eine divergierende Erzeugung durchführen. Ein Thread, der einen divergierenden Sprung durchgeführt hat, führt möglicherweise keine Barriere aus, oder es wird zu einer Blockierung kommen. Diese Drosselung ist notwendig, um Spaten innerhalb divergenter Steuerströmung zu ermöglichen. Erst wenn alle Fahrspuren auseinander- und wieder zusammengeführt haben, kann die Eltern-Untergruppe wieder behaust werden.

Ein Thread muss schließlich nach dem Ausführen eines Erzeugens enden, um einen Fortschritt zu gewährleisten. Falls mehrere Erzeugungen vor der Threadbeendigung durchgeführt werden, kann Deadlock auftreten. In einer besonderen Ausführungsform werden die folgenden Invarianten befolgt, obwohl die zugrundeliegenden Prinzipien der Erfindung nicht so beschränkt sind:

• Alle divergierenden Erzeugungen, die ein Thread ausführt, müssen übereinstimmende SIMD-Breiten aufweisen.
• Eine SIMD-Spur darf keine konvergierende Erzeugung mit dem innerhalb der relevanten Ausführungsmaske 9150-9153 gesetzten ConvergenceMask Bit durchführen, es sei denn, dass ein früherer Thread eine divergierende Erzeugung mit derselben FFTID durchgeführt hat.
• Wird eine divergierende Speiche mit einer gegebenen Stapel-ID durchgeführt, so muss eine konvergierende Speiche vor der nächsten divergierenden Speiche auftreten.
• Falls irgendeine SIMD-Spur in einem Thread eine divergierende Erzeugung durchführt, dann müssen alle Spuren letztendlich eine divergierende Erzeugung durchführen. Ein Thread, der einen divergierenden Sprung durchgeführt hat, führt möglicherweise keine Barriere aus, oder es wird zu einer Blockierung kommen. Diese Drosselung ermöglicht Erzeugungen innerhalb eines divergenten Steuerstroms. Erst wenn alle Spuren auseinander- und wieder zusammengeführt sind, kann die Eltern-Untergruppe wieder erzeugt werden.
• Ein Thread muss schließlich nach Ausführung einer beliebigen Erzeugung enden, um einen Fortschritt zu gewährleisten. Falls mehrere Erzeugungen vor der Threadbeendigung durchgeführt werden, kann Deadlock auftreten.

In einer Ausführungsform weist der BTD-fähige Dispatcher 8950 eine Threadpräemptionslogik 9120 auf, um die Ausführung bestimmter Typen von Arbeitslasten/Threads zu präemptieren, um Ressourcen zum Ausführen anderer Typen von Arbeitslasten/Threads freizugeben. Zum Beispiel können die verschiedenen hierin beschriebenen Ausführungsformen sowohl Rechenarbeitslasten als auch Grafikarbeitslasten (einschließlich Strahlverfolgungsarbeitslasten) ausführen, die mit unterschiedlichen Prioritäten ausgeführt werden können und/oder unterschiedliche Latenzanforderungen aufweisen können. Um die Anforderungen jedes Workload/Threads zu adressieren, setzt eine Ausführungsform der Erfindung Strahltraversierungsoperationen aus, um Ausführungsressourcen für einen Workload/Thread mit höherer Priorität oder einen Workload/Thread freizugeben, der ansonsten spezifizierte Latenzanforderungen nicht erfüllt.

Wie oben mit Bezug auf 52A-B beschrieben, reduziert eine Ausführungsform die Speicherungsanforderungen für die Traversierung unter Verwendung eines kurzen Stapels 5203-5204, um eine begrenzte Anzahl von BVH-Knoten während Traversierungsoperationen zu speichern. Diese Techniken können von der Ausführungsform in 91 verwendet werden, bei der die Strahl/Box-Traversiereinheit 8930 Einträge zu und von dem kurzen Stapel 5203-5204 effizient schiebt und entnimmt, um sicherzustellen, dass die erforderlichen BVH-Knoten 5290-5291 verfügbar sind. Zusätzlich dazu aktualisiert der Traversier-/Stapelverfolger 5248, wenn Traversieroperationen durchgeführt werden, die Trackingdatenstruktur, die hier als das Trackingarray 5249 bezeichnet wird, sowie die relevanten Stapel 5203-5204 und Strahlenverfolgungsdaten 4902. Unter Verwendung dieser Techniken kann die Traversierschaltungsanordnung/logik 8930, wenn das Traversieren eines Strahls pausiert und neu gestartet wird, die TrackingDatenstruktur 5249 konsultieren und auf die relevanten Stapel 5203-5204 und die Strahlverfolgungsdaten 4902 zugreifen, um Traversieroperationen für diesen Strahl an derselben Stelle innerhalb des BVH, an der er ausgelassen hat, zu beginnen.

In einer Ausführungsform bestimmt die Thread-Präemptionslogik 9120, wann ein Satz von Traversal-Threads (oder anderen Thread-Typen), wie hierin beschrieben, präemptiert werden soll (z. B. Ressourcen für eine Arbeitslast/einen Thread mit höherer Priorität freizugeben) und benachrichtigt die Strahl/Box-Traversiereinheit 8930, so dass sie die Verarbeitung eines der aktuellen Threads pausieren kann, Ressourcen zur Verarbeitung des Threads mit höherer Priorität freizugeben. In einer Ausführungsform wird die „Benachrichtigung“ einfach durch Senden von Anweisungen für einen neuen Thread durchgeführt, bevor das Durchlaufen auf einem alten Thread abgeschlossen ist.

Somit umfasst eine Ausführungsform der Erfindung Hardwareunterstützung sowohl für synchrone Strahlverfolgung, die im Arbeitsgruppenmodus arbeitet (d. h., bei der alle Threads einer Arbeitsgruppe synchron ausgeführt werden), als auch für asynchrone Strahlverfolgung, die bindungslose Thread-Aussendung verwendet, wie hier beschrieben. Diese Techniken verbessern drastisch die Leistungsfähigkeit im Vergleich zu aktuellen Systemen, die erfordern, dass alle Threads in einer Arbeitsgruppe abgeschlossen werden, bevor eine Bevorrechtigung durchgeführt wird. Im Gegensatz dazu können die hier beschriebenen Ausführungsformen eine Bevorrechtigung auf Stapelebene und Threadebene durch enges Verfolgen einer Traversieroperation, Speichern nur der Daten, die zum Neustart erforderlich sind, und Verwenden kurzer Stapel, falls angemessen, durchführen. Diese Techniken sind zumindest teilweise möglich, weil die Strahlverfolgungsbeschleunigungshardware- und Ausführungseinheiten 8910 über eine persistente Speicherstruktur 3198 kommunizieren, die auf der Pro-Strahlebene und der Pro-BVH-Ebene verwaltet wird.

Wenn eine Traceray-Nachricht wie oben beschrieben erzeugt wird und es eine Bevorrechtigungsanforderung gibt, kann die Strahltraversierungsoperation in verschiedenen Stufen bevorrechtigt werden, einschließlich (1) noch nicht gestartet, (2) teilweise abgeschlossen und bevorrechtigt, (3) Durchlaufen abgeschlossen mit keiner bindungslosen Thread-Dispatch und (4) Durchlaufen abgeschlossen, aber mit einer bindungslosen Thread-Dispatch. Falls das Durchlaufen noch nicht gestartet wird, dann werden keine zusätzlichen Daten von dem Tracking-Array 5249 benötigt, wenn die Raytrace-Nachricht wieder aufgenommen wird. Falls der Durchlauf teilweise abgeschlossen wurde, dann wird der Durchlauf/Stapelverfolger 5248 das Verfolgungsarray 5249 lesen, um zu bestimmen, wo der Durchlauf wieder aufgenommen werden soll, unter Verwendung der Strahlverfolgungsdaten 4902 und Stapel 5121 nach Bedarf. Es kann das Tracking-Array 5249 unter Verwendung der eindeutigen ID abfragen, die jedem Strahl zugewiesen ist.

Falls das Durchlaufen abgeschlossen war und es keine bindungslose Thread-Versendung gab, dann kann eine bindungslose Thread-Versendung unter Verwendung beliebiger Trefferinformationen, die in dem Tracking-Array 5249 (und/oder anderen Datenstrukturen 4902, 5121) gespeichert sind, geplant werden. Falls die Traversierung abgeschlossen ist und es eine bindungslose Thread-Versendung gab, dann wird der bindungslose Thread wiederhergestellt und die Ausführung wird wieder aufgenommen, bis sie abgeschlossen ist.

In einer Ausführungsform weist das Tracking-Array 5249 einen Eintrag für jede eindeutige Strahl-ID für Strahlen im Flug auf, und jeder Eintrag kann eine der Ausführungsmasken 9150-9153 für einen entsprechenden Thread aufweisen. Alternativ dazu können die Ausführungsmasken 9150-9153 in einer separaten Datenstruktur gespeichert sein. Bei jeder Implementierung kann jeder Eintrag in dem Tracking-Array 5249 einen 1-Bit-Wert aufweisen oder mit diesem assoziiert sein, um anzugeben, ob der entsprechende Strahl erneut ausgesendet werden muss, wenn die Strahl/Box-Traversiereinheit 8930 den Betrieb nach einer Bevorrechtigung wieder aufnimmt. Bei einer Implementierung wird dieser 1-Bit-Wert innerhalb einer Thread-Gruppe (d. h. einer Arbeitsgruppe) verwaltet. Dieses Bit kann zu Beginn der Strahltraversierung auf 1 gesetzt werden und kann wieder auf 0 zurückgesetzt werden, wenn die Strahltraversierung abgeschlossen ist.

Die hier beschriebenen Techniken ermöglichen, dass Traversierungs-Threads, die mit der Strahltraversierung assoziiert sind, durch andere Threads (z. B. Rechen-Threads) präemptiert werden, ohne darauf zu warten, dass der Traversierungs-Thread und/oder die gesamte Arbeitsgruppe abgeschlossen ist, wodurch die Leistungsfähigkeit, die mit Threads mit hoher Priorität und/oder niedriger Latenz assoziiert ist, verbessert wird. Zudem kann aufgrund der hier beschriebenen Techniken zum Verfolgen des Traversierungsfortschritts der Traversierungsthread neu gestartet werden, wo er ausgelassen wird, was signifikante Verarbeitungszyklen und Ressourcennutzung bewahrt. Zusätzlich ermöglichen die oben beschriebenen Ausführungsformen, dass ein Arbeitsgruppen-Thread einen bindungslosen Thread erzeugt und Mechanismen für eine Wiederkonvergenz bereitstellt, um zurück in den ursprünglichen SIMD-Architekturzustand zu gelangen. Diese Techniken verbessern effektiv die Leistungsfähigkeit für Strahlverfolgungs- und Rechen-Threads um eine Größenordnung.

VORRICHTUNG UND VERFAHREN ZUR DATENPARALLELEN STRAHLENVERFOLGUNG

In der wissenschaftlichen Visualisierung (aber auch in Filmen und anderen Domänen) wachsen Datensätze zunehmend auf Größen, die von einem einzigen Knoten nicht verarbeitet werden können. Für Offline-Algorithmen (meist in Filmen) wird dies häufig durch Paging, Caching und out-of-core Techniken gehandhabt; wenn aber eine interaktive Einstellung erforderlich ist (z. B. Visualisierung für Öl und Gas, wissenschaftliche Visualisierung in einer Großdaten/HPC-Umgebung, interaktive Filminhaltsvorschauen usw.) ist dies nicht mehr möglich. In diesem Fall ist es zwingend erforderlich, irgendeine Form von Datenparallel-Rendering zu verwenden, bei dem die Daten über mehrere verschiedene Knoten partitioniert werden-so dass die Gesamtheit der Daten über alle Knoten gespeichert werden kann- und wo diese Knoten beim Rendern des erforderlichen Bildes zusammenwirken.

Die Ausführungsformen der Erfindung umfassen eine Vorrichtung und ein Verfahren zum Reduzieren der Bandbreite zum Übertragen von Strahlen und/oder Volumenblöcken im Rahmen einer datenverteilten Strahlverfolgung über mehrere Rechenknoten. 92 veranschaulicht zum Beispiel einen Strahlverfolgungs-Cluster 9200, der mehrere Strahlverfolgungsknoten 9210-9213 umfasst, die Strahlverfolgungsoperationen parallel durchführen, wobei potentiell die Ergebnisse an einem der Knoten kombiniert werden. In der dargestellten Architektur sind die Strahlverfolgungsknoten 9210-9213 über ein Gateway 9220 kommunikativ mit einer clientseitigen Strahlverfolgungsanwendung 9230 gekoppelt.

In der nachfolgenden Beschreibung wird davon ausgegangen, dass mehrere Knoten 9210-9213 die Strahlverfolgungsdaten gemeinsam halten. Jeder solche Knoten 9210-9213 kann eine oder mehrere CPUs, GPUs, FPGAs usw. enthalten und die Berechnungen können an entweder einzelnen oder einer Kombination dieser Ressourcen durchgeführt werden. In einer Ausführungsform kommunizieren die Rechenknoten 9210-9213 miteinander durch irgendeine Form eines Netzwerks 9215, wie etwa Infiniband, OmniPath oder NVLink, um einige zu nennen. Die Daten können über die Speicher dieser Knoten 9210-9213 partitioniert werden, entweder weil die Anwendung, die den Renderer verwendet, die Daten selbst partitioniert hat (wie dies für viele In-situ-Algorithmen oder parallele Middleware, wie etwa ParaView, Visite usw. der Fall ist), oder weil der Renderer diese Partitionierung erzeugt hat.

Um ein paralleles Rendern in einer solchen Umgebung durchzuführen, gibt es eine Vielzahl von algorithmischen Auswahlen: Zusammensetzungsbasierte Ansätze weisen auf, dass jeder Knoten ein Bild seiner lokalen Daten rendert und diese Teilergebnisse unter Verwendung einer Tiefen- und/oder Alphazusammensetzung kombiniert. Ansätze zum Weiterleiten (oder Caching) von Daten berechnen Operationen eines gegebenen Strahls (oder Pixel, Pfad usw.) auf einem gegebenen Knoten, detektieren, wann immer dieser Strahl/dieser Pixel/Pfad Daten benötigt, die auf einem anderen Knoten leben, und holen diese Daten auf Anforderung. Strahlweiterleitungsbasierte Ansätze leiten Daten nicht an die Strahlen weiter, die dies benötigen, und senden stattdessen die Strahlen an den Knoten, der die Daten besitzt.

Unter diesen Auswahlen ist das Zusammensetzen am einfachsten und am weitesten verbreitet; es ist jedoch nur für relativ einfache Rendering-Effekte anwendbar und kann nicht ohne weiteres für Effekte wie etwa Schatten, Reflexionen, Umgebungsokklusion, globale Beleuchtung, volumetrische Streuung, volumetrische Schatten usw. verwendet werden. Solche Effekte, die häufiger von Benutzern benötigt werden, erfordern irgendeine Art von Strahlverfolgung, in welchem Fall das parallele Rendern von Daten entweder Daten zu den Strahlen holt oder die Strahlen zu den Daten sendet. Beide Ansätze wurden zuvor verwendet und ihre Einschränkungen sind gut verständlich. Insbesondere leiden beide Ansätze an hohen Bandbreitenanforderungen, entweder durch Senden von bis zu Milliarden Strahlen (zur Strahlweiterleitung) oder dadurch, dass jeder Knoten 9210-9213 bis zu viele Gigabyte Daten (zur Datenweiterleitung) oder beides holt (wenn eine Kombination von beiden verwendet wird).

Obwohl die Netzwerkbandbreite drastisch ansteigt, steigen auch Datengröße und/oder Strahlzahl, so dass diese Bandbreite in der Praxis sehr schnell der limitierende Faktor für die Performance ist. Tatsächlich ist es oft der einzige Grund, dass eine interaktive Leistungsfähigkeit nicht erreicht werden kann, außer in sehr simplistischen Einstellungen (wie etwa Nur-Primärstrahl-Rendering, in welchem Fall man auch Kompositen verwendet haben könnte).

Eine Ausführungsform der Erfindung konzentriert sich auf den Kerngedanken, dass in der Praxis sehr große Teile der Daten für einen gegebenen Rahmen oft tatsächlich nicht ins Gewicht fallen. Zum Beispiel verwendet der Benutzer beim Volumen-Rendern häufig eine „Transferfunktion“, um gewisse Regionen der Daten hervorzuheben, wobei weniger interessante Datensätze bis vollständig transparent sind. Anschaulich müsste ein Strahl, der nur „uninteressante“ Daten durchlaufen würde, diese Daten nicht abrufen (oder an diese Daten gesendet werden), und die jeweilige Bandbreite kann gespeichert werden. Gleichermaßen muss er für oberflächenbasiertes Strahlverfolgen, falls ein Strahl durch einen Raumbereich läuft, der einem anderen Knoten gehört, dort aber tatsächlich keine Dreiecke schneidet, tatsächlich nicht mit Dreiecken dieses anderen Knotens interagieren.

Eine Ausführungsform erweitert die Konzepte von „Leer-Space Skipping“ und „Bounding Volume“ von einzelnen Knoten zu parallelem Daten-Rendern in Form der Verwendung von sogenannten „Proxys“ 9230-9233 für die Daten eines Knotens. Insbesondere berechnet jeder Knoten einen Proxy 9230-9233 mit sehr niedrigem Speicherplatz seiner eigenen Daten, so dass dieser Proxy die Fähigkeit bereitstellt, diese Daten entweder anzunähern oder konservativ zu binden. Alle Knoten 9210-9213 tauschen dann ihre Proxys 9230-9233 aus, so dass jeder Knoten Proxys jedes anderen Knotens hat. Zum Beispiel werden die Proxys 9230, die auf dem Knoten 9210 gespeichert sind, Proxydaten von den Knoten 9211-9213 aufweisen. Wenn ein Knoten einen Strahl durch eine räumliche Region verfolgen muss, das einem anderen Knoten gehört, verfolgt er zunächst diesen Strahl durch seine eigene Kopie des Proxys dieses Knotens. Falls dieser Proxy garantiert, dass keine aussagekräftige Interaktion auftritt, kann er das Senden dieses Strahls/Holens dieser Daten überspringen, wodurch die dafür erforderliche Bandbreite gespeichert wird.

93 veranschaulicht zusätzliche Einzelheiten eines Strahlverfolgungsknotens 9210 gemäß einer Ausführungsform der Erfindung. Ein Volumenunterteilungsmodul 9265 unterteilt ein Volumen in mehrere Partitionen, von denen jede durch einen anderen Knoten verarbeitet wird. Der Arbeitsdatensatz 9360 umfasst die Daten für die vom Knoten 9210 zu verarbeitende Partition. Ein Proxy-Erzeugungsmodul 9250 erzeugt einen Proxy 9340 basierend auf dem Arbeitsdatensatz 9360. Der Proxy 9340 wird an jeden der anderen Strahlverfolgungsknoten 9211-9213 übertragen, die den Proxy verwenden, um nicht benötigte Daten zu beseitigen, wie hier beschrieben. Gleichermaßen werden Proxys 9341-9343, die jeweils auf den Knoten 9211-9213 erzeugt werden, an den Knoten 9210 übertragen. Die Strahlverfolgungsengine 9315 führt Strahlverfolgungsperationen unter Verwendung sowohl des lokal gespeicherten Arbeitsdatensatzes 9360 als auch der Proxys 9341-9343 durch, die durch jeden der miteinander verbundenen Knoten 9211-9213 bereitgestellt werden.

94 veranschaulicht ein Beispiel, bei dem im Kontext des Volumenrenderns ein gegebener Volumendatensatz 9400 zu groß ist, um auf einem Knoten gerendert zu werden, so dass er in mehrere Blöcke 9401-9404 (in diesem Fall einen 2x2-Satz) partitioniert wird. Wie in 95 veranschaulicht, kann dieses logisch partitionierte Volumen dann über verschiedene Knoten 9210-9213 verteilt werden, wobei jeder einen Teil des Volumens beibehält.

Traditionell muss ein Knoten jedes Mal, wenn er einen Strahl senden will, der durch räumliche Regionen anderer Knoten verläuft, diesen Strahl entweder an diese Knoten senden oder Daten dieser Knoten abrufen. In 96 verfolgt der Knoten 9210 zum Beispiel einen Strahl, der durch den Raum verläuft, der den Knoten 9211-9213 gehört.

Wie in 97 veranschaulicht, berechnet in einer Ausführungsform jeder Knoten 9210-9213 jeweils einen lokalen Proxy 9240-9243 für seinen Teil der Daten 9401-9404, wobei der Proxy eine beliebige Art von Objekt ist, das (signifikant) kleiner in der Größe ist, aber das Approximieren oder konservative Begrenzen dieser Daten dieses Knotens ermöglicht. In einer Ausführungsform berechnet jeder Knoten zum Beispiel ein sogenanntes „Makrozellengitter“; ein Gitter mit niedrigerer Auflösung, wobei jede Zelle einer Region von Zellen in dem Eingabevolumen entspricht und wobei jede solche Zelle zum Beispiel den minimalen und maximalen Skalarwert in dieser Region speichert (im Kontext des Einzelknoten-Renderns wird dies üblicherweise für „Space Skipping“ verwendet). In dem veranschaulichten Beispiel berechnet jeder Knoten 9210-9213 einen solchen Proxy 9240-9243 für seinen Teil der Daten. In einer Ausführungsform tauschen dann alle Knoten ihre jeweiligen Proxys aus, bis jeder Knoten alle Proxys für jeden Knoten aufweist, wie in 98 veranschaulicht ist.

Sind für eine gegebene Übertragungsfunktionseinstellung nur einige der Datenwerte tatsächlich interessant (in dem Sinne, dass sie nicht vollständig transparent sind), so kann dies konservativ im Proxy erkannt werden (ebenso wie herkömmliches Single-Node-Space Skipping). Dies ist in der 99 als Bereiche 9940-9943 dargestellt.

Da zusätzlich jeder Knoten Proxies jedes anderen Knotens aufweist, kann jeder Knoten auch konservativ begrenzen, welche Regionen der anderen Knoten interessant sind, basierend auf den Proxies er für diese Knoten aufweist, wie in 100 gezeigt. Falls der Knoten 9210 einen Strahl verfolgen muss, der Datenregionen des Knotens 9211 - 9213 überspannt, dann kann der Strahl auf den Proxy projiziert und dort durchlaufen werden, wie durch den gestrichelten Pfeil angegeben. Dies gibt an, dass, obwohl der Strahl durch den Raum läuft, der den Knoten 9210-9212 gehört, nur der Knoten 9212 tatsächlich beliebige interessante Regionen enthält, so dass dieser Strahl an den Knoten 9212 weitergeleitet werden kann, wie in 100 durch den durchgezogenen Pfeil angegeben, ohne Verarbeitung an den Knoten 9210 oder Senden an den Knoten 9211 (oder, in einem Zwischenspeicherungskontext, Daten können nur von dem Knoten 9210 anstatt von sowohl 9211 als auch 9212 abgerufen werden).

Ein Verfahren gemäß einer Ausführungsform der Erfindung ist in 101 dargestellt. Das Verfahren kann im Kontext der oben beschriebenen Architekturen implementiert werden, ist aber nicht auf irgendeine spezielle Verarbeitungs- oder Systemarchitektur beschränkt.

Bei 10101 wird ein Volumen logisch in eine Vielzahl von Partitionen unterteilt (N Partitionen, wobei N ein ganzzahliger Wert ist) und bei 10102 werden Daten, die mit den N Partitionen assoziiert sind, auf N verschiedene Knoten verteilt (z. B. eine Partition pro Knoten in einer Ausführungsform). Bei 10103 berechnet jeder Knoten einen Proxy für seine jeweilige Partition und sendet den Proxy an die anderen Knoten. Bei 10104 werden Traversier-/Schnittoperationen für einen aktuellen Strahl oder eine aktuelle Gruppe von Strahlen (z. B. ein Strahlenbündel) unter Verwendung der Proxys durchgeführt, wobei Regionen innerhalb der Proxys ignoriert werden, die für die Operationen (z. B. Regionen, die nicht von dem Strahl durchlaufen werden) nicht relevant sind. Wie erwähnt, sind für eine gegebene Übertragungsfunktionseinstellung nur einige der Datenwerte tatsächlich interessant (z. B. weil sie nicht vollständig transparent sind). Dies kann konservativ in dem Proxy detektiert werden, wie dies mit dem Single-Node-Space Skipping geschieht. Falls der Strahl mit dem Proxy interagiert, bestimmt bei 10105, dann werden bei 10106 der Strahl bzw. die Strahlen zu dem Knoten gesendet, der mit dem Proxy assoziiert ist, oder Daten werden von dem Knoten abgerufen. Der nächste Strahl oder die nächste Gruppe von Strahlen wird dann bei 10107 ausgewählt.

Natürlich hängen die hier beschriebenen Ausführungsformen von den tatsächlichen Daten, der Strahlverteilung, der Übertragungsfunktion usw. ab. Es ist jedoch nicht selten, dass Daten sehr ähnlich dem oben gegebenen Beispiel aussehen. Offensichtlich würden die Proxys für Datensätze/Transferfunktionen, die zu einem deutlich weniger „dünn besetzten“ nachklassifizierten Datensatz führen (d. h. Datensatz, nachdem die Transferfunktion angewandt wurde), nicht viel helfen. In diesem Fall würden die Strahlen jedoch wahrscheinlich sehr schnell enden und müssen daher nicht sehr oft zwischen Knoten gesendet werden und erzeugen keine übermäßige Bandbreite. Im Wesentlichen sind die größten Problemfälle jene, bei denen viele der Daten dünn besetzt sind und bei denen Strahlen über viele Knoten laufen, und jene sind genau die Fälle, bei denen die hier beschriebenen Techniken am effektivsten sind.

BEISPIELE

Im Folgenden werden beispielhafte Implementierungen verschiedener Ausführungsformen der Erfindung beschrieben.

Beispiel 1. Vorrichtung, die Folgendes aufweist: einen Tesselator zum Tesselieren eines Eingangspatches zu einem Gitter-Primitiv, das mehrere miteinander verbundene Vierecke aufweist, wobei jedes Viereck zwei implizite Dreiecke aufweist und mindestens zwei Vertices mit einem benachbarten Viereck gemeinsam nutzt; einen Begrenzungsrahmengenerator zum Konstruieren eines Begrenzungsrahmens zum Binden jedes Vierecks des Gitter-Primitivs, um mehrere Begrenzungsrahmen zu erzeugen, die den mehreren miteinander verbundenen Vierecken entsprechen; und eine Strahldurchlaufhardwarelogik, um zu bestimmen, ob ein Strahl einen oder mehrere der mehreren Begrenzungsrahmen durchläuft; und eine Kreuzungshardwarelogik, um einen Begrenzungsrahmen, der von dem Strahl durchlaufen wird, zu verarbeiten, um zu bestimmen, ob der Strahl eines der impliziten Dreiecke schneidet, die durch das Viereck repräsentiert werden, das von dem Begrenzungsrahmen begrenzt wird.

Beispiel 2. Vorrichtung nach Beispiel 1, wobei das Gitter-Primitiv eine M x M-Matrix von Vertices aufweist, die die mehreren Verbindungsvierecke bilden.

Beispiel 3. Vorrichtung nach Beispiel 1, wobei der Begrenzungsrahmengenerator integral mit der Strahltraversierungshardwarelogik oder einem Bounding Volume Hierarchy(BVH)-Builder ist.

Beispiel 4. Vorrichtung nach Beispiel 1, wobei für ein Gitter-Primitiv, das N Vierecke aufweist, der Begrenzungsrahmengenerator einen N-breiten BVH-Knoten erzeugen soll, der einen Kind-Knoten aufweist, der mit jedem Viereck assoziiert ist.

Beispiel 5. Vorrichtung nach Beispiel 1, wobei eine Bitmaske basierend auf dem Gitter-Primitiv erzeugt wird, wobei jedes Bit in der Bitmaske mit einem der impliziten Dreiecke oder einem der Vierecke assoziiert ist, wobei, wenn ein Bit in der Bitmaske auf 0 gesetzt ist, das assoziierte implizite Dreieck oder Viereck als ungültig angesehen wird.

Beispiel 6. Vorrichtung nach Beispiel 1, die ferner Folgendes aufweist: eine Bewegungsunschärfehardwarelogik zum Interpolieren zwischen einer ersten Repräsentation eines ersten impliziten Dreiecks zu einem ersten Zeitpunkt und einer zweiten Repräsentation des ersten impliziten Dreiecks zu einem zweiten Zeitpunkt.

Beispiel 7. Vorrichtung nach Beispiel 1, wobei das Gitter-Primitiv eines von mehreren Gitter-Primitiven ist, wobei die Vorrichtung ferner Folgendes aufweist: Komprimierungshardwarelogik zum Identifizieren gemeinsam genutzter Vertices der mehreren Gitter-Primitive und zum Speichern nur eines Satzes von Vertexdaten für jeden gemeinsam genutzten Vertex.

Beispiel 8. Vorrichtung nach Beispiel 7, wobei die Komprimierungshardwarelogik einen Index erzeugen soll, der auf ein Array zeigt, in dem der Satz von Vertexdaten gespeichert ist.

Beispiel 9. Vorrichtung nach Beispiel 8, wobei die Komprimierungshardwarelogik eine oder mehrere gemeinsam genutzte Kanten der impliziten Dreiecke identifizieren soll, wobei die Komprimierungshardwarelogik einen einzigen Satz von Kantendaten für jede gemeinsam genutzte Kante speichern soll.

Beispiel 10. Verfahren, umfassend: Tesselieren eines Eingangspatches zu einem Gitter-Primitiv, das mehrere miteinander verbundene Vierecke aufweist, wobei jedes Viereck zwei implizite Dreiecke aufweist und mindestens zwei Vertices mit einem benachbarten Viereck gemeinsam nutzt; Konstruieren eines Begrenzungsrahmens, um jedes Viereck des Gitter-Primitivs zu begrenzen, um mehrere Begrenzungsrahmen zu erzeugen, die den mehreren miteinander verbundenen Vierecken entsprechen; und Bestimmen, ob ein Strahl einen oder mehrere der mehreren Begrenzungsrahmen durchläuft; und Verarbeiten eines Begrenzungsrahmens, der durch den Strahl durchlaufen wird, um zu bestimmen, ob der Strahl eines der impliziten Dreiecke schneidet, die durch das Viereck repräsentiert werden, das durch den Begrenzungsrahmen begrenzt ist.

Beispiel 11. Verfahren nach Beispiel 10, wobei das Gitter-Primitiv eine M x M-Matrix von Vertices aufweist, die die mehreren Verbindungsvierecke bilden.

Beispiel 12. Verfahren nach Beispiel 10, wobei der Begrenzungsrahmengenerator integral mit der Strahltraversierungshardwarelogik und/oder einem Bounding Volume Hierarchy(BVH)-Builder ist.

Beispiel 13. Verfahren nach Beispiel 10, wobei für ein Gitter-Primitiv, das N Vierecke aufweist, der Begrenzungsrahmengenerator einen N-breiten BVH-Knoten erzeugen soll, der einen Kind-Knoten aufweist, der mit jedem Viereck assoziiert ist.

Beispiel 14. Verfahren nach Beispiel 10, wobei eine Bitmaske basierend auf dem Gitter-Primitiv erzeugt wird, wobei jedes Bit in der Bitmaske mit einem der impliziten Dreiecke oder einem der Vierecke assoziiert ist, wobei, falls ein Bit in der Bitmaske auf 0 gesetzt ist, das assoziierte implizite Dreieck oder Viereck als ungültig angesehen wird.

Beispiel 15. Verfahren nach Beispiel 10 eine erste Repräsentation eines ersten impliziten Dreiecks zu einem ersten Zeitpunkt und eine zweite Repräsentation des ersten impliziten Dreiecks zu einem zweiten Zeitpunkt.

Beispiel 16. Verfahren nach Beispiel 10, wobei das Gitter-Primitiv eines von mehreren Gitter-Primitiven ist, wobei das Verfahren ferner Folgendes umfasst: Identifizieren gemeinsam genutzter Vertices der mehreren Gitter-Primitive und Speichern nur eines Satzes von Vertexdaten für jeden gemeinsam genutzten Vertex.

Beispiel 17. Verfahren nach Beispiel 16, ferner umfassend: Erzeugen eines Index, der auf ein Array zeigt, in dem der Satz von Vertexdaten gespeichert ist.

Beispiel 18. Verfahren nach Beispiel 17, ferner umfassend: Identifizieren einer oder mehrerer gemeinsam genutzter Kanten der impliziten Dreiecke und Speichern nur eines einzigen Satzes von Kantendaten für jede gemeinsam genutzte Kante.

Beispiel 19. Maschinenlesbares Medium, auf dem Programmcode gespeichert ist, der, wenn er von einer Maschine ausgeführt wird, bewirkt, dass die Maschine die folgenden Operationen durchführt: Tesselieren eines Eingabepatches in ein Gitter-Primitiv, das mehrere miteinander verbundene Vierecke aufweist, wobei jedes Viereck zwei implizite Dreiecke aufweist und mindestens zwei Vertices mit einem benachbarten Viereck gemeinsam nutzt; Konstruieren eines Begrenzungsrahmens zum Begrenzen jedes Vierecks des Gitter-Primitivs, um mehrere Begrenzungsrahmen zu erzeugen, die den mehreren miteinander verbundenen Vierecken entsprechen; und Bestimmen, ob ein Strahl einen oder mehrere der mehreren Begrenzungsrahmen durchläuft; und Verarbeiten eines Begrenzungsrahmens, der von dem Strahl durchlaufen wird, um zu bestimmen, ob der Strahl eines der impliziten Dreiecke schneidet, die durch das Viereck repräsentiert werden, das von dem Begrenzungsrahmen begrenzt wird.

Beispiel 20. Maschinenlesbares Medium nach Beispiel 19, wobei das Gitter-Primitiv eine M x M-Matrix von Vertices aufweist, die die mehreren Zwischenverbindungsvierecke bilden.

Beispiel 21. Maschinenlesbares Medium nach Beispiel 19, wobei der Begrenzungsrahmengenerator integral mit der Strahltraversierungshardwarelogik und/oder einem Bounding Volume Hierarchy(BVH)-Builder ist.

Beispiel 22. Maschinenlesbares Medium nach Beispiel 19, wobei für ein Gitter-Primitiv, das N Vierecke aufweist, der Begrenzungsrahmengenerator einen N-breiten BVH-Knoten erzeugen soll, der einen Kind-Knoten aufweist, der mit jedem Viereck assoziiert ist.

Beispiel 23. Maschinenlesbares Medium nach Beispiel 19, wobei eine Bitmaske basierend auf dem Gitter-Primitiv erzeugt wird, wobei jedes Bit in der Bitmaske mit einem der impliziten Dreiecke oder einem der Vierecke assoziiert ist, wobei, falls ein Bit in der Bitmaske auf 0 gesetzt ist, das assoziierte implizite Dreieck oder Viereck als ungültig angesehen wird.

Beispiel 24. Maschinenlesbares Medium nach Beispiel 19, das ferner Programmcode aufweist, um zu bewirken, dass die Maschine die folgenden Operationen durchführt: Interpolieren zwischen einer ersten Repräsentation eines ersten impliziten Dreiecks zu einem ersten Zeitpunkt und einer zweiten Repräsentation des ersten impliziten Dreiecks zu einem zweiten Zeitpunkt.

Beispiel 25. Maschinenlesbares Medium nach Beispiel 19, wobei das Gitter-Primitiv eines von mehreren Gitter-Primitiven ist, wobei das maschinenlesbare Medium ferner Programmcode aufweist, um zu bewirken, dass die Maschine die folgenden Operationen durchführt: Identifizieren gemeinsam genutzter Vertices der mehreren Gitter-Primitive und Speichern nur eines Satzes von Vertexdaten für jeden gemeinsam genutzten Vertex.

Ausführungsformen der Erfindung können verschiedene Schritte umfassen, welche oben stehend beschrieben wurden. Die Schritte können als maschinenausführbare Befehle verkörpert werden, welche verwendet werden können, um zu bewirken, dass ein Allzweck- oder Spezialprozessor die Schritte durchführt. Alternativ können diese Schritte durch spezifische Hardwarekomponenten, welche festverdrahtete Logik zum Durchführen der Schritte enthalten, oder durch eine beliebige Kombination von programmierten Computerkomponenten und individualisierten Hardwarekomponenten durchgeführt werden.

Wie hier beschrieben, können Anweisungen spezifische Konfigurationen von Hardware bezeichnen, wie etwa anwendungsspezifische integrierte Schaltungen (ASIC), welche konfiguriert sind, gewisse Operationen durchzuführen, oder eine vorgegebene Funktionalität oder Softwareanweisungen aufweisen, welche in einem Speicher gespeichert sind, welcher in einem nichtflüchtigen computerlesbaren Medium verkörpert ist. Somit können die in den Figuren gezeigten Techniken unter Verwendung von Code und Daten, die auf einer oder mehreren elektronischen Vorrichtungen (z. B. einer Endstation, einem Netzwerkelement usw.) gespeichert und ausgeführt werden, implementiert sein. Derartige elektronische Vorrichtungen speichern und kommunizieren (intern und/oder mit anderen elektronischen Vorrichtungen über ein Netzwerk) Code und Daten unter Verwendung maschinenlesbarer Computermedien, wie beispielsweise nichtflüchtiger maschinenlesbarer Computerspeichermedien (z. B. magnetischer Festplatten; optischer Festplatten; Direktzugriffsspeicher; Nur-Lese-Speicher; Flash-Speichervorrichtungen; Phasenwechselspeicher) und flüchtiger maschinenlesbarer Computerkommunikationsmedien (z. B. elektrisch, optisch, akustisch oder auf andere Weise sich fortpflanzender Signale - wie beispielsweise Trägerwellen, Infrarotsignalen, digitalen Signalen usw.).

Zusätzlich weisen solche elektronischen Vorrichtungen typischerweise einen Satz von einem oder mehreren Prozessoren auf, welche mit einer oder mehreren anderen Komponenten gekoppelt sind, wie einer oder mehreren Speicherungsvorrichtungen (nichtflüchtigen maschinenlesbaren Speichermedien), Benutzereingabe-/- ausgabevorrichtungen (z. B. einer Tastatur, einem Berührungsbildschirm und/oder einer Anzeige) und Netzwerkverbindungen. Die Kopplung des Satzes von Prozessoren und anderen Komponenten erfolgt typischerweise durch einen oder mehrere Busse und Brücken (auch als Bussteuerungen bezeichnet). Die Speicherungsvorrichtung und die den Netzwerkverkehr führenden Signale repräsentieren jeweils ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien. Somit speichert die Speicherungsvorrichtung einer gegebenen elektronischen Vorrichtung in der Regel Code und/oder Daten zur Ausführung auf dem Satz von einem oder mehreren Prozessoren der elektronischen Vorrichtung. Natürlich können ein oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung unterschiedlicher Kombinationen von Software, Firmware und/oder Hardware implementiert werden. Überall in dieser ausführlichen Beschreibung wurden zum Zwecke der Erläuterung zahlreiche spezifische Einzelheiten dargelegt, um ein umfassendes Verständnis der vorliegenden Erfindung bereitzustellen. Fachleuten ist jedoch offenkundig, dass die Erfindung ohne einige dieser spezifischen Einzelheiten in die Praxis umgesetzt werden kann. In bestimmten Fällen wurden wohlbekannte Strukturen und Funktionen nicht ausführlich beschrieben, um ein Verschleiern des Gegenstands der vorliegenden Erfindung zu vermeiden. Dementsprechend sollten der Schutzumfang und die Idee der Erfindung hinsichtlich der folgenden Ansprüche beurteilt werden.

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Patentliteratur

US 63/066799 [0001]
WO 16/236185 [0538]

Claims

Vorrichtung, die Folgendes aufweist: einen Tesselator zum Tesselieren eines Eingabepatches in ein Gitter-Primitiv, das mehrere miteinander verbundene Vierecke aufweist, wobei jedes Viereck zwei implizite Dreiecke aufweist und mindestens zwei Vertices mit einem benachbarten Viereck gemeinsam nutzt; einen Begrenzungsrahmengenerator zum Konstruieren eines Begrenzungsrahmens, um jedes Viereck des Gitter-Primitivs zu begrenzen, um mehrere Begrenzungsrahmen zu erzeugen, die den mehreren miteinander verbundenen Vierecken entsprechen; und eine Strahltraversierungshardwarelogik, um zu bestimmen, ob ein Strahl einen oder mehrere der mehreren Begrenzungsrahmen durchläuft; und Kreuzungshardwarelogik zum Verarbeiten eines Begrenzungsrahmens, der durch den Strahl durchlaufen wird, um zu bestimmen, ob der Strahl eines der impliziten Dreiecke schneidet, die durch das Viereck repräsentiert werden, das durch den Begrenzungsrahmen begrenzt ist.
Vorrichtung nach Anspruch 1, wobei das Gitter-Primitiv eine M x M-Matrix von Vertices aufweist, die die mehreren Verbindungsvierecke bilden.
Vorrichtung nach Anspruch 1 oder 2, wobei der Begrenzungsrahmengenerator integral mit der Strahltraversierungshardwarelogik oder einem Begrenzungsrahmenhierarchie(BVH)-Builder ist.
Vorrichtung nach einem der Ansprüche 1 bis 3, wobei für ein Gitter-Primitiv, das N Vierecke aufweist, der Begrenzungsrahmengenerator einen N-breiten BVH-Knoten erzeugen soll, der einen Kind-Knoten aufweist, der mit jedem Viereck assoziiert ist.
Vorrichtung nach einem der Ansprüche 1 bis 4, wobei eine Bitmaske basierend auf dem Gitter-Primitiv erzeugt wird, wobei jedes Bit in der Bitmaske einem der impliziten Dreiecke oder einem der Vierecke zugeordnet ist, wobei, wenn ein Bit in der Bitmaske auf 0 gesetzt ist, das zugeordnete implizite Dreieck oder Viereck als ungültig angesehen wird.
Vorrichtung nach einem der Ansprüche 1 bis 5, die ferner Folgendes aufweist: Bewegungsunschärfehardwarelogik zum Interpolieren zwischen einer ersten Repräsentation eines ersten impliziten Dreiecks zu einem ersten Zeitpunkt und einer zweiten Repräsentation des ersten impliziten Dreiecks zu einem zweiten Zeitpunkt.
Vorrichtung nach einem der Ansprüche 1 bis 6, wobei das Gitter-Primitiv eines von mehreren Gitter-Primitiven ist, wobei die Vorrichtung ferner Folgendes aufweist: Komprimierungshardwarelogik zum Identifizieren gemeinsam genutzter Vertices der mehreren Gitter-Primitive und zum Speichern nur eines Satzes von Vertexdaten für jeden gemeinsam genutzten Vertex.
Vorrichtung nach Anspruch 7, wobei die Komprimierungshardwarelogik einen Index erzeugen soll, der auf ein Array zeigt, in dem der Satz von Vertexdaten gespeichert ist.
Vorrichtung nach Anspruch 8, wobei die Komprimierungshardwarelogik zum Identifizieren einer oder mehrerer gemeinsam genutzter Kanten der impliziten Dreiecke dient, wobei die Komprimierungshardwarelogik zum Speichern eines einzelnen Satzes von Kantendaten für jede gemeinsam genutzte Kante dient.
Verfahren, das Folgendes umfasst: Tesselieren eines Eingabepatches zu einem Gitter-Primitiv, das mehrere miteinander verbundene Vierecke aufweist, wobei jedes Viereck zwei implizite Dreiecke aufweist und mindestens zwei Vertices mit einem benachbarten Viereck gemeinsam nutzt; Konstruieren eines Begrenzungsrahmens, um jedes Viereck des Gitter-Primitivs zu begrenzen, um mehrere Begrenzungsrahmen zu erzeugen, die den mehreren miteinander verbundenen Vierecken entsprechen; und Bestimmen, ob ein Strahl einen oder mehrere der mehreren Begrenzungsrahmen durchläuft; und Verarbeiten eines Begrenzungsrahmens, der von dem Strahl durchlaufen wird, um zu bestimmen, ob der Strahl eines der impliziten Dreiecke schneidet, die durch das Viereck repräsentiert werden, das von dem Begrenzungsrahmen begrenzt wird.
Verfahren nach Anspruch 10, wobei das Gitter-Primitiv eine M x M-Matrix von Vertices aufweist, die die mehreren Verbindungsvierecke bilden.
Verfahren nach Anspruch 10 oder 11, wobei der Begrenungsrahmengenerator integral mit der Strahltraversierungshardwarelogik und/oder einem Bounding Volume Hierarchy(BVH)-Builder ist.
Verfahren nach einem der Ansprüche 10 bis 12, wobei für ein Gitter-Primitiv, das N Vierecke aufweist, der Begrenzungsrahmengenerator einen N-breiten BVH-Knoten erzeugen soll, der einen Kind-Knoten aufweist, der mit jedem Viereck assoziiert ist.
Verfahren nach einem der Ansprüche 10 bis 13, wobei eine Bitmaske basierend auf dem Gitter-Primitiv erzeugt wird, wobei jedes Bit in der Bitmaske mit einem der impliziten Dreiecke oder einem der Vierecke assoziiert ist, wobei, wenn ein Bit in der Bitmaske auf 0 gesetzt ist, das assoziierte implizite Dreieck oder Viereck als ungültig angesehen wird.
Verfahren nach einem der Ansprüche 10 bis 14, einer ersten Repräsentation eines ersten impliziten Dreiecks zu einem ersten Zeitpunkt und einer zweiten Repräsentation des ersten impliziten Dreiecks zu einem zweiten Zeitpunkt.
Verfahren nach einem der Ansprüche 10 bis 15, wobei das Gitter-Primitiv eines von mehreren Gitter-Primitiven ist, wobei das Verfahren ferner Folgendes umfasst: Identifizieren gemeinsam genutzter Vertices der mehreren Gitter-Primitive und Speichern nur eines Satzes von Vertexdaten für jeden gemeinsam genutzten Vertex.
Verfahren nach Anspruch 16, ferner umfassend: Erzeugen eines Index, der auf ein Array zeigt, in dem der Satz von Vertexdaten gespeichert ist.
Verfahren nach Anspruch 17, ferner umfassend: Identifizieren einer oder mehrerer gemeinsam genutzter Kanten der impliziten Dreiecke, und Speichern nur eines einzigen Satzes von Kantendaten für jede gemeinsam genutzte Kante.
Maschinenlesbares Medium mit darauf gespeichertem Programmcode, der bei Ausführung durch eine Maschine die Maschine dazu veranlasst, die folgenden Operationen durchzuführen: Tesselieren eines Eingabepatches zu einem Gitter-Primitiv, das mehrere miteinander verbundene Vierecke aufweist, wobei jedes Viereck zwei implizite Dreiecke aufweist und mindestens zwei Vertices mit einem benachbarten Viereck gemeinsam nutzt; Konstruieren eines Begrenzungsrahmens, um jedes Viereck des Gitter-Primitivs zu begrenzen, um mehrere Begrenzungsrahmen zu erzeugen, die den mehreren miteinander verbundenen Vierecken entsprechen; und Bestimmen, ob ein Strahl einen oder mehrere der mehreren Begrenzungsrahmen durchläuft; und Verarbeiten eines Begrenzungsrahmens, der von dem Strahl durchlaufen wird, um zu bestimmen, ob der Strahl eines der impliziten Dreiecke schneidet, die durch das Viereck repräsentiert werden, das von dem Begrenzungsrahmen begrenzt wird.
Maschinenlesbares Medium nach Anspruch 19, wobei das Gitter-Primitiv eine M x M-Matrix von Vertices aufweist, die die mehreren Verbindungsvierecke bilden.
Maschinenlesbares Medium nach Anspruch 19 oder 20, wobei der Begrenzungsrahmengenerator integral mit der Strahltraversierungshardwarelogik und/oder einem Bounding Volume Hierarchy(BVH)-Builder ist.
Maschinenlesbares Medium nach einem der Ansprüche 19 bis 21, wobei für ein Gitter-Primitiv, das N Vierecke aufweist, der Begrenzungsrahmengenerator einen N-breiten BVH-Knoten erzeugen soll, der einen Kind-Knoten aufweist, der mit jedem Viereck assoziiert ist.
Maschinenlesbares Medium nach einem der Ansprüche 19 bis 22, wobei eine Bitmaske basierend auf dem Gitter-Primitiv erzeugt wird, wobei jedes Bit in der Bitmaske mit einem der impliziten Dreiecke oder einem der Vierecke assoziiert ist, wobei, wenn ein Bit in der Bitmaske auf 0 gesetzt ist, das assoziierte implizite Dreieck oder Viereck als ungültig angesehen wird.
Maschinenlesbares Medium nach einem der Ansprüche 19 bis 23, das ferner Programmcode aufweist, um zu bewirken, dass die Maschine die folgenden Operationen durchführt: Interpolieren zwischen einer ersten Repräsentation eines ersten impliziten Dreiecks zu einem ersten Zeitpunkt und einer zweiten Repräsentation des ersten impliziten Dreiecks zu einem zweiten Zeitpunkt.
Maschinenlesbares Medium nach einem der Ansprüche 19 bis 24, wobei die Gitter-Primitiv eines von mehreren Gitter-Primitiven ist, wobei das maschinenlesbare Medium ferner Programmcode aufweist, um die Maschine zu veranlassen, die folgenden Operationen durchzuführen: Identifizieren gemeinsam genutzter Vertices der mehreren Gitter-Primitive und Speichern nur eines Satzes von Vertexdaten für jeden gemeinsam genutzten Vertex.