DE102020134334A1

DE102020134334A1 - Vorrichtung und verfahren zur quantisierten konvergenten richtungsbasierten strahlsortierung

Info

Publication number: DE102020134334A1
Application number: DE102020134334.5A
Authority: DE
Inventors: Karol Szerszen; Prasoonkumar Surti; Gabor Liktor; Karthik Vaidyanathan; Sven Woop
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-12-27
Filing date: 2020-12-21
Publication date: 2021-07-01
Also published as: US20240104825A1; CN113052747A; TW202143175A; US11783530B2; US20210201558A1; KR20210084222A; JP2021108103A; US11263800B2; US20220262063A1

Abstract

Vorrichtung und Verfahren zum Gruppieren von Strahlen basierend auf quantisierten Strahlrichtungen. Eine Ausführungsform einer Vorrichtung umfasst zum Beispiel: Eine Vorrichtung umfasst: einen Strahlgenerator zum Generieren mehrerer Strahlen; Strahlrichtungsauswertungsschaltungsanordnung/Logik zum Generieren ungefährer Strahlrichtungsdaten für jeden der mehreren Strahlen; Strahlsortierschaltungsanordnung/Logik zum Sortieren der Strahlen in mehrere Strahlwarteschlangen, zumindest teilweise basierend auf den ungefähren Strahlrichtungsdaten.

Description

HINTERGRUND
Gebiet der Erfindung
Diese Erfindung betrifft allgemein das Gebiet Grafikprozessoren. Insbesondere betrifft die Erfindung eine Vorrichtung und ein Verfahren für quantisierte konvergente richtungsbasierte Strahlsortierung.
Beschreibung des Standes der Technik
Raytracing ist eine Technik, bei der ein Lichttransport durch physikalisch basiertes Rendering simuliert wird. Es ist im cinematischem Rendering weit verbreitet und galt bis vor wenigen Jahren als zu ressourcenintensiv für Echtzeitleistung. Eine der wichtigsten Operationen des Raytracings ist Verarbeitung einer Sichtbarkeitsabfrage für Strahlszenenüberschneidungen, die als „Strahltraversierung“ (engl. „Ray Travesal“) bekannt ist, welche Strahlszenenüberschneidungen durch Traversierungs- und Überschneidungsknoten in einer Bounding-Volumen-Hierarchie (BVH) berechnet.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung ergibt sich aus der folgenden ausführlichen Beschreibung in Verbindung mit den folgenden Zeichnungen, in denen:

1 ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor ist, der über einen oder mehrere Prozessorkerne und Grafikprozessoren verfügt;
2A-D Rechensysteme und Grafikprozessoren veranschaulichen, die von hierin beschriebenen Ausführungsformen bereitgestellt werden;
3A-C Blockdiagramme zusätzlicher Grafikprozessor- und Rechenbeschleunigerarchitekturen veranschaulichen;
4 ein Blockdiagramm einer Ausführungsform einer Grafikverarbeitungs-Engine eines Grafikprozessors ist;
5A-B Thread-Ausführungslogik veranschaulichen, die ein Array von Verarbeitungselementen enthält, die in einem Grafikprozessor eingesetzt werden;
6 eine zusätzliche Ausführungseinheit gemäß einer Ausführungsform veranschaulicht;
7 ein Anweisungsformat für eine Grafikprozessorausführungseinheit gemäß einer Ausführungsform veranschaulicht;
8 ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors ist, der eine Grafik-Pipeline, eine Medien-Pipeline, eine Anzeige-Engine, Thread-Ausführungslogik und eine Rendering-Ausgabe-Pipeline enthält;
9A ein Blockdiagramm ist, das ein Grafikprozessorbefehlsformat gemäß einer Ausführungsform veranschaulicht;
9B ein Blockdiagramm ist, das eine Grafikprozessorbefehlssequenz gemäß einer Ausführungsform veranschaulicht;
10 eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einer Ausführungsform veranschaulicht;
11A ein Blockdiagramm ist, das ein IP-Kern-Entwicklungssystem gemäß einer Ausführungsform veranschaulicht;
11B eine Querschnittsseitenansicht einer integrierten Package-Schaltungsbaugruppe gemäß manchen Ausführungsformen veranschaulicht;
11C eine Package-Baugruppe veranschaulicht, die mehrere Einheiten von Hardware-Logik-Chiplets enthält, die mit einem Substrat verbunden sind;
11D eine Package-Baugruppe veranschaulicht, die gemäß einer Ausführungsform austauschbare Chiplets enthält.
12 eine beispielhafte System-on-a-Chip-integrierte Schaltung veranschaulicht, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform;
13 einen beispielhaften Grafikprozessor einer System-on-a-Chipintegrierten Schaltung veranschaulicht, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann;
14 eine beispielhafte Grafikprozessorarchitektur veranschaulicht;
15 ein Beispiel für eine Verarbeitungsarchitektur veranschaulicht, die Raytracing-Kerne und Tensor-Kerne enthält;
16 ein Raytracing-Cluster von Knoten veranschaulicht;
17 zusätzliche Details für beispielhafte Raytracing-Knoten veranschaulicht;
18 Strahlkomprimierung/-dekomprimierung veranschaulicht, die in einer Ausführungsform eingesetzt werden;
19 eine Ausführungsform einer hybriden Raytracing-Architektur veranschaulicht;
20 beispielhafte Aufrufstapelverweise veranschaulicht;
21 einen beispielhaften Satz von Shader-Eintrag-Zeigern veranschaulicht;
22 ein Beispiel einer Bounding-Volumen-Hierarchie veranschaulicht;
23 eine Ausführungsform eines Aufrufstapels und zugeordneten Traversalzustands veranschaulicht;
24 eine Ausführungsform der Erfindung für Strahlsortierung veranschaulicht;
25 einen beispielhaften Satz von Strahlen, die ein Volumen schneiden, veranschaulicht;
26 einen Sortierschlüssel gemäß einer Ausführungsform der Erfindung veranschaulicht; und
27 ein Verfahren gemäß einer Ausführungsform der Erfindung veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zu Erklärungszwecken zahlreiche spezifische Details dargelegt, um ein genaues Verständnis der nachfolgend beschriebenen Ausführungsformen der Erfindung zu ermöglichen. Es wird Fachleuten jedoch offensichtlich sein, dass die Ausführungsformen der Erfindung auch ohne manche dieser spezifischen Details praktiziert werden können. In anderen Fällen sind weithin bekannte Strukturen und Vorrichtungen in Form von Blockdiagrammen gezeigt, um eine Verundeutlichung 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. System 100 kann in einem Einzelprozessor-Desktop-System, einem Multiprozessor-Workstation-System 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 in einer integrierten System-on-a-Chip-Schaltung (SoC) zur Verwendung in mobilen, Handheld- oder eingebetteten Vorrichtungen integriert ist, wie etwa in Internet-der-Dinge-Vorrichtungen (Internet-of-Things; IoT) mit drahtgebundener oder drahtloser Konnektivität zu einem lokalen oder Wide Area Network.
In einer Ausführungsform kann System 100 enthalten, gekoppelt sein mit oder integriert sein in: eine serverbasierte Gaming-Plattform; eine Spielkonsole, die ein Spiel und eine Medienkonsole umfasst; eine mobile Spielkonsole, eine Handheld-Spielkonsole oder eine Online-Spielkonsole. In manchen Ausführungsformen ist das System 100 Teil eines Mobiltelefons, Smartphones, einer Tablet-Rechenvorrichtung oder einer mobilen mit dem Internet verbundenen Vorrichtung, wie etwa ein Laptop mit niedriger interner Speicherkapazität. Verarbeitungssystem 100 kann auch umfassen, koppeln mit oder integriert sein in: einer tragbaren Vorrichtung, wie etwa eine tragbare Smartwatch-Vorrichtung; einer intelligenten Brille oder in intelligenter Kleidung, die mit Augmented-Reality (AR) oder Virtual-Reality (VR) Merkmalen ausgestattet ist, um visuelle, akustische oder taktile Ausgaben zur Ergänzung realer visueller, akustischer oder taktiler Erfahrungen bereitzustellen, oder anderweitig Text, Audio, Grafiken, Video, holografische Bilder oder Video oder taktiles Feedback bereitzustellen; einer anderen Augmented-Reality-Vorrichtung (AR); oder einer anderen Virtual-Reality-Vorrichtung (VR). In manchen Ausführungsformen enthält das Verarbeitungssystem 100 ein Fernsehgerät oder eine Set-Top-Box-Vorrichtung oder ist Teil davon. In einer Ausführungsform kann System 100 ein selbstfahrendes Fahrzeug umfassen, damit gekoppelt oder darin integriert sein, wie etwa einen Bus, Traktoranhänger, Auto, motor- oder elektrisch betriebenes Fahrrad, Flugzeug oder Glider (oder eine Kombination davon). Das selbstfahrende Fahrzeug kann System 100 verwenden, um die um das Fahrzeug erfasste Umgebung zu verarbeiten.
In manchen Ausführungsformen umfassen ein oder mehrere Prozessoren 102 einen oder mehrere Prozessorkerne 107 zum Verarbeiten von Anweisungen, die, wenn sie ausgeführt werden, Operationen für System- oder Benutzersoftware durchführen. In manchen Ausführungsformen ist mindestens einer der einen oder mehrere Prozessorkerne 107 dafür ausgelegt, einen spezifischen Anweisungssatz 109 zu verarbeiten. In manchen Ausführungsformen kann Anweisungssatz 109 Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC) oder Rechnen über ein Very Long Instruction Word (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 enthalten kann. Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen enthalten, wie etwa einen digitalen Signalprozessor (DSP).
In manchen Ausführungsformen enthält der Prozessor 102 Cache-Speicher 104. Je nach Architektur kann der Prozessor 102 über einen einzelnen internen Cache oder mehrere Ebenen interner Caches verfügen. In manchen Ausführungsformen wird der Cache-Speicher von verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. In manchen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z.B. einen Level-3 (L3) Cache oder einen Last Level Cache (LLC)) (nicht gezeigt), der von den Prozessorkernen 107 unter Verwendung bekannter Cache-Kohärenztechniken gemeinsam genutzt werden kann. Zusätzlich kann in Prozessor 102 eine Registerdatei 106 enthalten sein und diese kann unterschiedliche Arten von Registern zum Speichern unterschiedlicher Arten von Daten enthalten (z.B. Integer-Register, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister). Manche Register können Universalregister sein, während andere Register spezifisch für das Design des Prozessors 102 sein können.
In manchen Ausführungsformen sind ein oder mehrere Prozessor(en) 102 mit einem oder mehreren Schnittstellenbus(sen) 110 gekoppelt, um Kommunikationssignale, wie etwa Adress-, Daten- oder Steuersignale, zwischen 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 Direct Media Interface (DMI) Bus. 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 enthalten der oder die Prozessor(en) 102 einen integrierten Speicher-Controller 116 und einen Plattform-Controller-Hub 130. Der Speicher-Controller 116 ermöglicht Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der Plattform-Controller-Hub (PCH) 130 über einen lokalen I/O-Bus Verbindungen zu I/O-Vorrichtungen bereitstellt.
Die Speichervorrichtung 120 kann eine Direktzugriffsspeichervorrichtung (DRAM), eine statische Direktzugriffsspeichervorrichtung (SRAM), eine Flash-Speichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Speichervorrichtung sein, die eine geeignete Leistung 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. Speicher-Controller 116 koppelt außerdem mit einem optionalen externen Grafikprozessor 118, der mit dem einen oder den mehreren Grafikprozessoren 108 in Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In manchen Ausführungsformen können Grafiken, Medien und/oder Rechenoperationen durch einen Beschleuniger 112 unterstützt werden, welcher ein Koprozessor ist, der konfiguriert werden kann, um einen spezialisierten Satz von Grafik-, Medien- oder Rechenoperationen durchzuführen. In einer Ausführungsform ist der Beschleuniger 112 beispielsweise ein Matrixmultiplikationsbeschleuniger, der verwendet wird, um Maschinenlern- oder Rechenoperationen zu optimieren. In einer Ausführungsform ist der Beschleuniger 112 ein Raytracing-Beschleuniger, der zum Durchführen von Raytracing-Operationen in Zusammenarbeit mit dem Grafikprozessor 108 verwendet werden kann. In einer Ausführungsform kann anstatt von oder in Verbindung mit dem Beschleuniger 112 ein externer Beschleuniger 119 verwendet werden.
In manchen Ausführungsformen kann eine Anzeigevorrichtung 111 mit dem oder den Prozessor(en) 102 verbinden. Die Anzeigevorrichtung 111 kann eine oder mehrere interne Anzeigevorrichtung(en) sein, wie in einer mobilen elektronischen Vorrichtung oder einer Laptop-Vorrichtung, oder eine externe Anzeigevorrichtung, die über eine Anzeigeschnittstelle (z.B. DisplayPort usw.) verbunden ist. In einer Ausführungsform kann die Anzeigevorrichtung 111 eine am Kopf angebrachte Anzeige (Head Mounted Display; HMD) sein, wie etwa eine stereoskopische Anzeigevorrichtung zur Verwendung in Virtual-Reality-Anwendungen (VR) oder Augmented-Reality-Anwendungen (AR).
In manchen Ausführungsformen befähigt Plattform-Controller-Hub 130 Peripheriegeräte mit Speichervorrichtung 120 und Prozessor 102 über einen Hochgeschwindigkeits-I/O-Bus zu verbinden. Die I/O-Peripheriegeräte umfassen, sind aber nicht beschränkt auf, einen Audio-Controller 146, einen Netzwerk-Controller 134, eine Firmware-Schnittstelle 128, einen drahtlosen Sendeempfänger 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (z.B. nichtflüchtiger Speicher, flüchtigen Speicher, Festplattenlaufwerk, Flash-Speicher, NAND, 3D NAND, 3D XPoint usw.). Die Datenspeichervorrichtung 124 kann über eine Speicherschnittstelle (z.B. SATA) oder über einen Peripheriebus, wie etwa einen Peripheral Component Interconnect Bus (z.B. PCI, PCI-Express), verbinden. Die Berührungssensoren 125 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren umfassen. Der drahtlose Sendeempfänger 126 kann ein Wi-Fi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein Mobilnetzwerk-Sendeempfänger sein, wie etwa ein 3G, 4G, 5G oder Long-Term-Evolution (LTE) Sendeempfänger. Die Firmwareschnittstelle 128 ermöglicht Kommunikation mit System-Firmware und kann beispielsweise ein Unified Extensible Firmware Interface (UEFI) sein. Der Netzwerk-Controller 134 kann eine Netzwerkverbindung mit einem drahtgebundenem Netzwerk ermöglichen. In manchen Ausführungsformen koppelt ein Hochleistungs-Netzwerk-Controller (nicht gezeigt) mit dem Schnittstellenbus 110. Der Audio-Controller 146 ist in einer Ausführungsform ein Mehrkanal-High-Definition-Audio-Controller. In einer Ausführungsform enthält das System 100 einen optionalen Legacy-I/O-Controller 140 zum Koppeln von Legacy-Vorrichtungen (z.B. Personal System 2 (PS/2)) mit dem System. Der Plattform-Controller-Hub 130 kann auch mit einem oder mehreren Universal Serial Bus (USB) Controllern 142 verbinden, um Eingabevorrichtungen zu verbinden, wie etwa Tastatur und Maus 143 Kombinationen, eine Kamera 144 oder andere USB-Eingabevorrichtungen.
Es ist zu würdigen, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da auch andere Arten von Datenverarbeitungssystemen, die anders konfiguriert sind, verwendet werden können. Eine Instanz des Speicher-Controllers 116 und des Plattform-Controller-Hubs 130 kann beispielsweise in einen diskreten externen Grafikprozessor integriert werden, wie etwa den externen Grafikprozessor 118. In einer Ausführungsform können der Plattform-Controller-Hub 130 und/oder Speicher-Controller 116 extern zu einem oder mehreren Prozessor(en) 102 sein. System 100 kann beispielsweise einen externen Speicher-Controller 116 und einen Plattform-Controller-Hub 130 umfassen, die als ein Speicher-Controller-Hub und Peripherie-Controller-Hub innerhalb eines System-Chipsatzes, der in Kommunikation mit dem oder den Prozessor(en) 102 steht, konfiguriert sein.
Es können beispielsweise Leiterplatten („Schlitten“), auf denen Komponenten, wie etwa CPUs, Speicher und andere Komponenten platziert sind, die für höhere thermische Leistung ausgelegt sind, verwendet werden. In 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 dieses Design bereitgestellt wird, können die Komponenten mit höheren Frequenzen und Leistungspegeln arbeiten als typische Systeme, wodurch die Leistung erhöht wird. Darüber hinaus sind die Schlitten konfiguriert, blind mit Strom- und Datenkommunikationskabeln in einem Rack verbunden zu werden, wodurch ihre Fähigkeit verbessert wird, schnell entfernt, aufgerüstet, neuinstalliert und/oder ausgetauscht zu werden. Auf ähnliche Weise werden individuelle Komponenten, die sich auf den Schlitten befinden, wie etwa Prozessoren, Beschleuniger, Speicher und Datenspeicherlaufwerke, konfiguriert, aufgrund ihrer größeren Beabstandung voneinander einfacher aufgerüstet zu werden. In der veranschaulichenden Ausführungsform enthalten die Komponenten zusätzlich Hardware-Attestierungsmerkmale, um ihre Authentizität nachzuweisen.
Ein Rechenzentrum kann eine einzelne Netzwerkarchitektur („Fabric“) verwenden, die mehrere andere Netzwerkarchitekturen, einschließlich Ethernet und Omni-Path, unterstützt. Die Schlitten können über optische Fasern mit Schaltern gekoppelt werden, die höhere Bandbreite und niedrigere Latenz bereitstellen als typische Twisted-Pair-Verkabelungen (z.B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.). Aufgrund der hohen Bandbreite, Verbindungen mit niedriger Latenz und Netzwerkarchitektur kann das Rechenzentrum bei der Verwendung Ressourcen, wie etwa Speicher, Beschleuniger (z.B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, neurale Netzwerk- und/oder künstliche Intelligenz Beschleuniger usw.) und Datenspeicherlaufwerke, die physisch disaggregiert sind, bündeln und ihnen Rechenressourcen (z.B. Prozessoren) nach Bedarf zuweisen, was es den Rechenressourcen ermöglicht, auf die gebündelten Ressourcen so zuzugreifen, als wären sie lokal.
Eine Stromversorgung oder -quelle kann Spannung und/oder Strom an das hierin beschriebene System 100 oder eine Komponente oder ein System zuführen. In einem Beispiel enthält die Stromversorgung einen AC-DC-Adapter (Wechselstrom zu Gleichstrom) zum Anschluss an eine Wandsteckdose. Solch ein Wechselstrom kann aus einer Quelle erneuerbarer Energie (z.B. Solarstrom) kommen. In einem Beispiel enthält die Stromquelle eine Gleichstromquelle, wie etwa einen externen Wechselstrom-Gleichstrom-Wandler. In einem Beispiel enthält die Stromquelle oder Stromversorgung Hardware für kabelloses Laden zum Laden über die Nähe zu einem Ladefeld. In einem Beispiel kann die Stromquelle eine interne Batterie, Wechselstromversorgung, bewegungsbasierte Stromquelle, Solarstromquelle oder Brennstoffzellenquelle enthalten.
2A-2D veranschaulichen Rechensysteme und Grafikprozessoren, die von hierin beschriebenen Ausführungsformen bereitgestellt werden. Die Elemente in 2A-2D, die die gleichen Referenzzahlen (oder Bezeichnungen), wie die Elemente einer anderen Figur hierin aufweisen, können auf eine ähnliche Weise arbeiten oder funktionieren, wie an anderer Stelle hierin beschrieben, sie sind aber nicht darauf beschränkt.
2A ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A-202N, einem integrierten Speicher-Controller 214 und einem integrierten Grafikprozessor 208. Prozessor 200 kann zusätzliche Kerne bis zu und einschließlich Kern 202N enthalten, was durch die mit gestrichelten Linien dargestellten Kästchen repräsentiert ist. Jeder der Prozessorkerne 202A-202N enthält eine oder mehrere interne Cache-Einheiten 204A-204N. In manchen Ausführungsformen hat jeder Prozessorkern außerdem Zugriff auf eine oder mehrere gemeinsam genutzte Cache-Einheiten 206. Die internen Cache-Einheiten 204A-204N und gemeinsam genutzten Cache-Einheiten 206 repräsentieren eine Cache-Speicherhierarchie innerhalb des Prozessors 200. Die Cache-Speicherhierarchie kann mindestens eine Ebene von Anweisungs- und Datencache in jedem Prozessorkern und eine oder mehr Ebene(n) gemeinsam genutzten Mid-Level-Cache enthalten, wie etwa einen Ebene 2 (Level 2; L2), Ebene 3 (L3), Ebene 4 (L4), oder andere Cache-Ebenen, wobei die höchste Cache-Ebene vor externem Speicher als LLC klassifiziert ist. In manchen Ausführungsformen erhält Cache-Kohärenzlogik Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A-204N.
In manchen Ausführungsformen kann Prozessor 200 auch einen Satz von einer oder mehreren Bus-Controller-Einheiten 216 und einen Systemagentenkern 210 enthalten. Die eine oder mehreren Bus-Controller-Einheiten 216 verwalten einen Satz von Peripheriebussen, wie etwa einen oder mehrere PCI- oder PCI-Express-Busse. Systemagentenkern 210 stellt Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. In manchen Ausführungsformen enthält Systemagentenkern 210 einen oder mehrere integrierte Speicher-Controller 214 zum Verwalten des Zugriffs auf diverse externe Speichervorrichtungen (nicht gezeigt).
In manchen Ausführungsformen enthalten ein oder mehrere der Prozessorkerne 202A-202N Unterstützung für simultanes Multithreading. In solchen Ausführungsformen enthält der Systemagentenkern 210 Komponenten zum Koordinieren und Betrieben von Kernen 202A-202N während Multithreading-Verarbeitung. Systemagentenkern 210 kann zusätzlich eine Leistungssteuerungseinheit (Power Control Unit; PCU) enthalten, die Logik und Komponenten zum Regeln des Leistungszustands der Prozessorkerne 202A-202N und des Grafikprozessors 208 enthalten.
In manchen Ausführungsformen enthält Prozessor 200 zusätzlich Grafikprozessor 208 zum Ausführen von Grafikverarbeitungsoperationen. In manchen Ausführungsformen koppelt der Grafikprozessor 208 mit dem Satz gemeinsam genutzter Cache-Einheiten 206 und dem Systemagentenkern 210, einschließlich des einen oder der mehreren integrierten Speicher-Controller 214. In manchen Ausführungsformen enthält Systemagentenkern 210 außerdem Anzeige-Controller 211 zum Treiben von Grafikprozessorausgaben an ein oder mehrere gekoppelte Anzeigen. In manchen Ausführungsformen kann Anzeige-Controller 211 auch ein separates Modul sein, das mit dem Grafikprozessor über mindestens eine Verbindung gekoppelt ist, oder er kann in den Grafikprozessor 208 integriert sein.
In manchen Ausführungsformen wird eine ringbasierte Verbindungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch auch eine alternative Verbindungseinheit verwendet werden, wie etwa eine Punkt-zu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Techniken, einschließlich im Fach bekannter Techniken. In manchen Ausführungsformen koppelt Grafikprozessor 208 mit der Ringverbindung 212 über eine I/O-Verbindung 213.
Die beispielhafte I/O-Verbindung 213 repräsentiert mindestens eine mehrerer verschiedener I/O-Verbindungen, einschließlich einer On-Package-I/O-Verbindung, die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebettetem Hochleistungsspeichermodul 218, wie etwa ein eDRAM-Modul, ermöglicht. In manchen Ausführungsformen kann jeder der Prozessorkerne 202A-202N und Grafikprozessor 208 eingebettete Speichermodule 218 als einen gemeinsam genutzten Last Level Cache verwenden.
In manchen Ausführungsformen sind Prozessorkerne 202A-202N homogene Kerne, die die gleiche Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind Prozessorkerne 202A-202N heterogen in Hinblick auf Anweisungssatzarchitektur (Instruction Set Architecture; ISA), wobei ein oder mehrere der Prozessorkerne 202A-202N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne einen Untersatz des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführen. In einer Ausführungsform sind Prozessorkerne 202A-202N in Bezug auf Mikroarchitektur heterogen, wobei ein oder mehrere Kerne eine relativ hohe Leistungsverbrauchskopplung mit einem oder mehreren Leistungskern(en) mit einem niedrigen Leistungsverbrauch aufweisen. In einer Ausführungsform sind Prozessorkerne 202A-202N in Bezug auf die Rechenfähigkeit heterogen. Zusätzlich kann 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äß manchen hierin beschriebenen Ausführungsformen. Elemente in 2B, die die gleichen Referenzzahlen (oder Bezeichnungen) aufweisen wie die Elemente einer anderen Figur hierin, können auf eine ähnliche Weise arbeiten oder funktionieren, wie an anderer Stelle hierin beschrieben, sind aber nicht darauf beschränkt. Der Grafikprozessorkern 219, der bisweilen als Core-Slice bezeichnet wird, kann ein oder mehrere Grafikkern(e) in einem modularen Grafikprozessor sein. Der Grafikprozessorkern 219 ist beispielhaft für einen Grafik-Core-Slice und ein Grafikprozessor, wie hierin beschrieben, kann mehrere Grafik-Core-Slices basierend auf Zielleistung und Leistungshüllen enthalten. Jeder Grafikprozessorkern 219 kann einen Festfunktionsblock 230 enthalten, der mit mehreren Sub-Kernen 221A-221F, die auch als Sub-Slices bezeichnet werden, die modulare Blöcke von Universal- und Festfunktionslogik enthalten, gekoppelt sein.
In manchen Ausführungsformen enthält der Festfunktionsblock 230 eine Geometrie-/Festfunktionspipeline 231, die von allen Sub-Kernen in dem Grafikprozessorkern 219 gemeinsame genutzt werden kann, beispielsweise bei Implementierungen mit niedrigerer Leistung und/oder mit einem Grafikprozessor mit niedrigerer Leistung. In verschiedenen Ausführungsformen enthält die Geometrie-/Festfunktionspipeline 231 eine 3D-Festfunktionspipeline (z.B. 3D-Pipeline 312, wie in 3 und 4 unten beschrieben), eine Video-Frontendeinheit, einen Thread-Spawner und Thread-Dispatcher und einen Unified-Return-Buffer-Manager, der Unified-Return-Buffer verwaltet (z.B. Unified-Return-Buffer 418 in 4, wie unten beschrieben).
In einer Ausführungsform enthält der Festfunktionsblock 230 außerdem eine Grafik-SoC-Schnittstelle 232, einen Grafik-Mikrocontroller 233 und eine Medienpipeline 234. Die Grafik-SoC-Schnittstelle 232 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 219 und anderen Prozessorkernen innerhalb einer integrierten System-on-a-Chip-Schaltung bereit. Der Grafikmikrocontroller 233 ist ein programmierbarer Sub-Prozessor, der dafür konfigurierbar ist, verschiedene Funktionen des Grafikprozessorkerns 219 zu verwalten, einschließlich Thread-Dispatch, Scheduling und Preemption. Die Medienpipeline 234 (z.B. Medienpipeline 316 in 3 und 4) enthält Logik, um das Dekodieren, Kodieren, Vorverarbeiten und/oder Nachbearbeiten von Multimediadaten, einschließlich Bild- und Videodaten, zu ermöglichen. Die Medienpipeline 234 implementiert Medienoperationen über Anforderungen, Logik in Sub-Kernen 221-221F zu berechnen oder zu samplen.
In einer Ausführungsform befähigt die SoC-Schnittstelle 232 den Grafikprozessorkern 219 mit Universalanwendungsprozessorkernen (z.B. CPUs) und/oder anderen Komponenten in einer SoC zu kommunizieren, einschließlich Speicherhierarchieelementen, wie etwa einem gemeinsamen Last-Level-Cache-Speicher, dem System-RAM und/oder auf Chip oder auf Package eingebettetem DRAM. Die SoC-Schnittstelle 232 kann auch Kommunikation mit Festfunktionsvorrichtungen innerhalb des SoC ermöglichen, wie etwa Kamerabildgebungspipelines, und ermöglicht die Verwendung von und/oder implementiert globale Speicher-Atome, die gemeinsam von dem Grafikprozessorkern 219 und CPUs in dem SoC genutzt werden können. 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 in dem SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 Empfang von Befehlspuffern von einem Befehls-Streamer und globalem Thread-Dispatcher, die dafür ausgelegt sind, Befehle und Anweisungen jeweils an einen oder mehrere Grafikkerne in einem Grafikprozessor bereitzustellen. Die Befehle und Anweisungen können an die Medien-Pipeline 234 versendet werden, wenn Medienoperationen durchgeführt werden sollen, oder an eine Geometrie- und Festfunktions-Pipeline (z.B. Geometrie- und Festfunktions-Pipeline 231, Geometrie- und Festfunktions-Pipeline 237), wenn Grafikverarbeitungsoperationen durchgeführt werden sollen.
Der Grafikmikrocontroller 233 kann dafür ausgelegt sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 219 durchzuführen. In einer Ausführungsform kann Grafikmikrocontoller 233 Grafik- und/oder Rechenarbeitslastplanung an den verschiedenen parallelen Grafik-Engines in Ausführungseinheitarrays (Execution Unit; EU) 222A-222F, 224A-224F in den Sub-Kernen 221A-221F durchführen. In diesem Planungsmodell kann Host-Software, die auf einem CPU-Kern eines SoC ausgeführt wird, das den Grafikprozessorkern 219 enthält, Arbeitslasten eines von mehreren Grafikprozessor-Doorbells einreichen, was eine Planungsoperation an der entsprechenden Grafik-Engine aufruft. Planungsoperationen umfassen Bestimmen, welche Arbeitslast als nächstes auszuführen ist, Einreichen einer Arbeitslast an einen Befehls-Streamer, Vorziehen bestehender Arbeitslasten, die auf einer Engine laufen, Überwachen des Fortschritts einer Arbeitslast und Benachrichtigen von Host-Software, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann Grafikmikrocontroller 233 auch stromsparende oder Ruhezustände für den Grafikprozessorkern 219 ermöglichen, dem Grafikprozessorkern 219 die Fähigkeit bereitstellen, Register in dem Grafikprozessorkern 219 bei Übergängen zu einem stromsparendem Zustand unabhängig von dem Betriebssystem und/oder von Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
Der Grafikprozessorkern 219 kann mehr oder weniger als die veranschaulichten Sub-Kerne 221A-221F, bis zu N modulare Sub-Kerne, aufweisen. Für jeden Satz der N Sub-Kerne kann der Grafikprozessorkern 219 auch gemeinsam genutzte Funktionslogik 235, gemeinsam genutzte und/oder Cache-Speicher 236, eine Geometrie-/Festfunktionspipeline 237 sowie eine zusätzliche Festfunktionslogik 238 enthalten, um diverse Grafik- und Rechenverarbeitungsoperationen zu beschleunigen. Die gemeinsam genutzte Funktionslogik 235 kann Logikeinheiten enthalten, die der gemeinsam genutzten Funktionslogik 420 in 4 (z.B. Sampler-, Mathematik- und/oder Inter-Thread-Kommunikationslogik) zugeordnet ist, die gemeinsam von allen N Sub-Kernen in dem Grafikprozessorkern 219 genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 236 kann bzw. können ein Last-Level-Cache für den Satz von N Sub-Kernen 221A-221F in dem Grafikprozessorkern 219 sein und sie können auch als gemeinsamer Speicher dienen, auf den mehrere Sub-Kerne zugreifen können. Die Geometrie-/Festfunktions-Pipeline 237 kann anstatt der Geometrie-/Festfunktions-Pipeline 231 in dem Festfunktionsblock 230 enthalten sein und die gleichen oder ähnliche Logikeinheiten enthalten.
In einer Ausführungsform enthält der Grafikprozessorkern 219 zusätzliche Festfunktionslogik 238, die diverse feste Funktionsbeschleunigungslogik zur Verwendung durch den Grafikprozessorkern 219 enthalten kann. In einer Ausführungsform enthält die zusätzliche Festfunktionslogik 238 eine zusätzliche Geometriepipeline zur Verwendung in der Nur-Positions-Schattierung. Bei Nur-Positions-Schattierung existieren zwei Geometrie-Pipelines in der Geometrie-/Festfunktions-Pipeline 238, 231 und eine Cull-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Festfunktionslogik 238 enthalten sein kann. In einer Ausführungsform ist die Cull-Pipeline eine reduzierte Version der vollen Geometrie-Pipeline. Die vollständige Pipeline und die Cull-Pipeline können unterschiedliche Instanzen der gleichen Anwendung ausführen, wobei jede Instanz einen separaten Kontext hat. Nur-Positions-Schattierung kann lange Cull-Runs verworfener Dreiecke verstecken, was es in manchen Fällen ermöglicht, dass die Schattierung früher abgeschlossen wird. Zum Beispiel kann die Cull-Pipeline-Logik in einer Ausführungsform innerhalb der zusätzlichen Festfunktionslogik 238 Positions-Shader parallel mit der Hauptanwendung ausführen und erzeugt generell kritische Resultate schneller als die vollständige Pipeline, da die Cull-Pipeline nur die Positionsattribute der Vertices abruft und schattiert ohne Rasterung und Rendern der Pixel zu dem Frame-Buffer durchzuführen. Die Cull-Pipeline kann die erzeugten kritischen Resultate verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, ungeachtet dessen, ob diese Dreiecke reduziert sind. Die vollständige Pipeline (die sich in diesem Fall als eine Replay-Pipeline bezeichnen lässt) kann die Sichtbarkeitsinformationen konsumieren, um die reduzierten Dreiecke zu überspringen, um nur die sichtbaren Dreiecke zu schattieren, die letztlich an die Rasterungsphase weitergeben werden.
In einer Ausführungsform kann die zusätzliche Festfunktionslogik 238 auch, für Implementierungen, die Optimierungen für Maschinenlerntraining oder Inferenzierung umfassen, Maschinenlernbeschleunigungslogik enthalten, wie etwa F estfunktionsmatrixmulti p likationslo gik.
In jedem Grafik-Sub-Kern 221A-221F ist ein Satz von Ausführungsressourcen enthalten, die zum Durchführen von Grafik-, Medien- und Rechenoperationen in Reaktion auf Anforderungen durch Grafikpipeline, Medienpipeline oder Shader-Pogrammen verwendet werden können. Die Grafik-Sub-Kerne 221A-221F enthalten mehrere EU-Arrays 222A-222F, 224A-224F, Thread-Dispatch und Inter-Thread-Kommunikations-Logik (TD/IC) 223A-223F, einen 3D-Sampler (z.B. Textur) 225A-225F, einen Medien-Sampler 206A-206F, einen Shader-Prozessor 227A-227F und gemeinsam genutzten lokalen Speicher (Shared Local Memory; SLM) 228A-228F. Die EU-Arrays 222A-222F, 224A-224F enthalten jeweils mehrere Ausführungseinheiten, die Universalgrafikverarbeitungseinheiten sind, die dazu in der Lage sind, Gleitkomma- und Ganzzahl-/Festkomma-Logikoperationen im Dienst einer Grafik-, Medien oder Rechenoperation, einschließlich Grafik-, Medien- oder Rechen-Shader-Programme, durchzuführen. Die TD/IC-Logik 223A-223F führt lokale Thread-Dispatch- und Thread-Steueroperationen für die Ausführungseinheiten in einem Sub-Kern durch und ermöglicht Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Sub-Kerns 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-Zustand und dem Texturformat, das einer gegebenen Textur zugeordnet ist, unterschiedlich lesen. Der Medien-Sampler 206A-206F kann ähnliche Lesevorgänge basierend auf dem Typ und Format, die Mediendaten zugewiesen sind, durchführen. In einer Ausführungsform kann jeder Grafik-Sub-Kern 221A-221F alternierend einen vereinigten 3D- und Medien-Sampler enthalten. Threads, die auf den Ausführungseinheiten in jedem der Sub-Kerne 221A-221F ausgeführt werden, können gemeinsamen lokalen Speicher 228A-228F in jedem Sub-Kern nutzen, um zu ermöglichen, dass Threads, die in einer Thread-Gruppe ausgeführt werden, unter Verwendung eines gemeinsamen Pools von On-Chip-Speicher ausgeführt werden.
2C veranschaulicht eine Grafikverabeitungseinheit (GPU) 239, die dedizierte Sätze von Grafikverarbeitungsressourcen enthält, die in Mehrkerngruppen 240A-240N angeordnet sind. Obwohl nur die Details einer einzelnen Mehrkerngruppe 240A bereitgestellt werden, ist zu würdigen, dass die anderen Mehrkerngruppen 240B-240N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können.
Wie veranschaulicht, kann Mehrkerngruppe 240A einen Satz von Grafikkernen 243, einen Satz von Tensor-Kernen 244 und einen Satz von Raytracing-Kernen 245 enthalten. Ein Scheduler/Dispatcher 241 plant und versendet die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 243, 244, 245. Ein Satz von Registerdateien 242 speichert Operandenwerte, die von den Kernen 243, 244, 245 bei Ausführen der Grafik-Threads verwendet werden. Diese können beispielsweise Integer-Register zum Speichern von Integer-Werten, Gleitkommaregister zum Speichern von Gleitkommawerten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern gepackter Datenelemente (Integer- und/oder Gleitkommadatenelemente) und Kachel-Register zum Speichern von Tensor-/Matrixwerten enthalten. In einer Ausführungsform sind die Kachel-Register als kombinierte Sätze von Vektorregistern implementiert.
Eine oder mehrere kombinierte Level 1 (L1) Caches und gemeinsame Speichereinheiten 247 speichern Grafikdaten, wie etwa Texturdaten, Vertexdaten, Pixeldaten, Strahldaten, Bounding-Volume-Daten usw. lokal in jeder Mehrkerngruppe 240A. Zum Durchführen der Texturing-Operationen, wie etwa Textur-Mapping und Sampling, kann bzw. können ein oder mehrere Textur-Einheiten 247 verwendet werden. Ein Level 2 (L2) Cache 253, der von allen oder einer Teilmenge der Mehrkerngruppen 240A-240N gemeinsam genutzt wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafik-Threads. Wie veranschaulicht, kann L2-Cache 253 von einer Mehrzahl von Mehrkerngruppen 240A-240N gemeinsam genutzt werden. Ein oder mehrere Speicher-Controller 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.
Eingabe-/Ausgabe-Schaltungsanordnung (I/O) 250 koppelt die GPU 239 mit einer oder mehreren I/O-Vorrichtungen 252, wie etwa Digitalsignalprozessoren (DSPs), Netzwerk-Controllern oder Benutzereingabegeräte. Zum Koppeln der I/O-Vorrichtungen 252 mit der GPU 239 und Speicher 249 kann eine On-Chip-Verbindung verwendet werden. Ein oder mehrere I/O-Speicherverwaltungseinheiten (I/O Memory Management Units; IOMMUs) 251 der I/O-Schaltungsanordnung 250 koppeln die I/O-Vorrichtungen 252 direkt mit dem Systemspeicher 249. In einer Ausführungsform verwaltet die IOMMU 251 mehrere Sätze von Seitentabellen zum Abbilden virtueller Adressen zu physischen Adressen im Systemspeicher 249. In dieser Ausführungsform können sich die I/O-Vorrichtungen 252, CPU(s) 246 und GPU(s) 239 den gleichen virtuellen Adressraum teilen.
In einer Implementierung unterstützt die IOMMU 251 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen verwalten, um virtuelle Gast-/Grafikadressen zu physischen Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen zum Abbilden der physischen Gast-/Grafikadressen zu physischen System-/Host-Adressen (z.B. innerhalb des Systemspeichers 249). Die Basisadressen des ersten und des zweiten Satzes von Seitentabellen kann in Steuerregistern gespeichert werden und bei einem Kontextwechsel getauscht werden (z.B. so dass der neue Kontext mit Zugang zu dem relevanten Satz der Seitentabellen bereitgestellt wird). Obwohl in 2C nicht veranschaulicht, kann jeder der Kerne 243, 244, 245 und/oder jede der Mehrkerngruppen 240A-240N Translation Lookaside Buffer (TLBs) enthalten, um virtuelle Gast- zu physischen Gast-Übersetzungen, physische Gast zu physischen Host-Übersetzungen und virtuelle Gast- zu physischen Host-Übersetzungen zwischenzuspeichern.
In einer Ausführungsform sind die CPUs 246, GPUs 239 und I/O-Vorrichtungen 252 auf einem einzelnen Halbleiterchip und/oder Chip-Package integriert. Der veranschaulichte Speicher 249 kann auf dem gleichen Chip integriert sein oder er kann mit den Speicher-Controllern 248 über eine Off-Chip-Schnittstelle gekoppelt sein. In einer Implementierung umfasst der Speicher 249 GDDR6-Speicher, der den gleichen virtuellen Adressraum teilt, wie andere physische Speicher auf Systemebene, obwohl das zugrundeliegende Prinzip der Erfindung nicht auf diese spezifische Implementierung beschränkt ist.
In einer Ausführungsform enthalten Tensor-Kerne 244 eine Mehrzahl von Ausführungseinheiten, die spezifisch dafür entworfen sind, Matrixoperationen durchzuführen, welche die fundamentale Rechenoperation ist, die zum Durchführen von Deep Learning Operationen verwendet wird. Für das Training eines neuralen Netzwerks und Inferenzierung können beispielsweise simultane Matrixmultiplikationsoperationen verwendet werden. Die Tensor-Kerne 244 können Matrixverarbeitung unter Verwendung einer Vielzahl von Operandenpräzisionen durchführen, einschließlich Gleitkomma mit einfacher Genauigkeit (z.B. 32 Bit), Gleitkomma mit halber Genauigkeit (z. B. 16 Bit), Ganzzahlwörter (16 Bit), Bytes (8 Bit) und Halbbytes (4 Bit). In einer Ausführungsform extrahiert eine Implementierung eines neuralen Netzwerks Merkmale jeder gerenderten Szene und kombiniert dabei potenziell Details aus mehreren Frames, um ein Endbild in hoher Qualität zu konstruieren.
In Deep-Learning-Implementierungen kann Parallelmatrixmultiplikationsarbeit für Ausführung auf den Tensor-Kernen 244 geplant werden. Das Training neuraler Netzwerke erfordert insbesondere eine erhebliche Anzahl von Matrixpunktproduktoperationen. Um eine Innenproduktformulierung einer N × N × N Matrix zu multiplizieren, können die Tensor-Kerne 244 mindestens N Punktproduktverarbeitungselemente enthalten. Bevor das Matrixmultiplizieren beginnt, wird eine ganze Matrix in Kachel-Register geladen und mindestens eine Spalte einer zweiten Matrix wird jeden Zyklus für N Zyklen geladen. In jedem Zyklus gibt es N Punktprodukte, die verarbeitet werden.
Matrixelemente können mit verschiedenen Präzisionen je nach der bestimmten Implementierung gespeichert werden, einschließlich 16-Bit-Wörtern, 8-Bit-Bytes (z.B. INT8) und 4-Bit-Halbbytes (z.B. INT4). Für die Tensor-Kerne 244 können verschiedene Präzisionsmodi festgelegt werden, um sicherzustellen, dass die effizienteste Präzision für unterschiedliche Arbeitslasten verwendet wird (z.B. Inferenzierung von Arbeitslasten, die Quantisierung zu Bytes und Halbbytes tolerieren können).
In einer Ausführungsform beschleunigen die Raytracing-Kerne 245 Raytracing-Operationen für Echtzeit-Raytracing- und Nicht-Echtzeit-Raytracing-Implementierungen. Die Raytracing-Kerne 245 enthalten insbesondere eine Strahltraversierungs-/Überschneidungsschaltungsanordnung zum Durchführen von Strahltraversierung unter Verwendung von Bounding-Volume-Hierarchien (BVHs) und Identifizieren von Überschneidungen zwischen Strahlen und Primitiven, die in den BVH-Volumen eingeschlossen sind. Die Raytracing-Kerne 245 können außerdem eine Schaltungsanordnung zum Durchführen von Tiefentests und Culling enthalten (z.B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung). In einer Implementierung führen die Raytracing-Kerne 245 Traversierungs- und Überschneidungsoperationen in Zusammenarbeit mit den hierin beschriebenen Bildentrauschungstechniken durch, von denen zumindest ein Teil auf den Tensor-Kernen 244 ausgeführt werden kann. In einer Ausführungsform implementieren die Tensor-Kerne 244 beispielsweise ein neurales Deep Learning Netzwerk, um Entrauschen von Frames durchzuführen, die von den Raytracing-Kernen 245 erzeugt wurden. Die CPU(s) 246, Grafikkerne 243 und/oder Raytracing-Kerne 245 können jedoch auch einen Teil oder alle der Entrausch- und/oder Deep-Learning-Algorithmen implementieren.
Darüber hinaus kann, wie vorstehend beschrieben, ein verteilter Ansatz zum Entrauschen eingesetzt werden, bei dem sich die GPU 239 in einer Rechenvorrichtung befindet, die mit anderen Rechenvorrichtungen über ein Netzwerk oder eine Hochgeschwindigkeitsverbindung gekoppelt ist. In dieser Ausführungsform teilen die miteinander verbundenen Rechenvorrichtung neurales Netzwerk Lern-/Trainingdaten, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, Entrauschen für verschiedene Arten von Bild-Frames und/oder unterschiedliche Grafikanwendungen durchzuführen.
In einer Ausführungsform verarbeiten die Raytracing-Kerne 245 alle BVH-Traversalen und strahlprimitiven Überschneidungen, wodurch die Grafikkerne 243 nicht mit Tausenden von Anweisungen pro Strahl überlastet werden. In einer Ausführungsform enthält jeder Raytracing-Kern 245 einen ersten Satz spezialisierter Schaltungsanordnungen zum Durchführen von Bounding-Box-Tests (z.B. für Traversierungsoperationen) und einen zweiten Satz spezialisierter Schaltungsanordnung zum Durchführen von Strahl-Dreieck-Überschneidungstests (z.B. sich überschneidende Strahlen, die traversiert wurden). Somit kann die Mehrkerngruppe 240A in einer Ausführungsform einfach eine Strahlsonde starten und die Raytracing-Kerne 245 führen unabhängig Strahltraversierung und Überschneidung 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- und Rechenarbeit durchzuführen, während die Raytracing-Kerne 245 die Traversierungs- und Überschneidungsoperationen durchführen.
In einer Ausführungsform enthält jeder Raytracing-Kern 245 eine Traversierungseinheit zum Durchführen von BVH-Testoperationen und eine Überschneidungseinheit, die strahlprimitive Überschneidungstests durchführt. Die Überschneidungseinheit generiert eine „Treffer“, „kein Treffer“ oder „mehrere Treffer“ Reaktion, die sie an den entsprechenden Thread bereitstellt. Während der Traversal- und Überschneidungsoperationen werden die Ausführungsressourcen der anderen Kerne (z.B. Grafikkerne 243 und Tensor-Kerne 244) freigegeben, um andere Formen von Grafikarbeit durchzuführen.
In einer bestimmten, unten beschriebenen Ausführungsform wird ein Hybrid-Rasterungs-/Raytracing-Ansatz verwendet, bei dem Arbeit zwischen den Grafikkernen 243 und Raytracing-Kernen 245 verteilt wird.
In einer Ausführungsform enthalten die Raytracing-Kerne 245 (und/oder andere Kerne 243, 244) Hardwareunterstützung für einen Raytracing-Anweisungssatz, wie etwa Microsoft DirectX Ray Tracing (DXR), welches einen DispatchRays-Befehl enthält, sowie Strahlgenerierung, Closest-Hit, Any-Hit und Miss-Shader und Texturen für jedes Objekt. Eine andere Raytracing-Plattform, die von den Raytracing-Kernen 245, Grafikkernen 243 und Tensor-Kernen 244 unterstützt werden kann, ist Vulkan 1.1.85. Es ist jedoch zu beachten, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf eine bestimmte Raytracing-ISA beschränkt sind.
Im Allgemeinen können die verschiedenen Kerne 245, 244, 243 einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen zur Strahlerzeugung, Closest-Hit, Any-Hit, strahlprimitive Überschneidung, perprimitive und hierarchische Bounding-Box-Konstruktion, Miss, Visit und Ausnahmen enthält. Eine Ausführungsform umfasst insbesondere Raytracing-Anweisungen zum Durchführen der folgenden Funktionen:
Strahlerzeugung - Strahlerzeugungsanweisungen können für jeden Pixel, jedes Sample oder andere benutzerdefinierte Arbeitszuweisungen ausgeführt werden.
Closest Hit - Eine Closest-Hit-Anweisung kann ausgeführt werden, um den am nächsten gelegenen Überschneidungspunkt eines Strahls mit Primitiven in einer Szene zu lokalisieren.
Any Hit - Eine Any-Hit-Anweisung identifiziert mehrere Überschneidungen zwischen einem Strahl und Primitiven in einer Szene, um potenziell einen neuen am nächsten liegenden Überschneidungspunkt zu identifizieren.
Überschneidung - Eine Überschneidungsanweisung führt einen strahlprimitiven Überschneidungstest durch und gibt ein Ergebnis aus.
Per-Primitiv Bounding-Box-Konstruktion - Diese Anweisung errichtet eine Bounding-Box um eine gegebene Primitive oder Gruppe von Primitiven (z.B. beim Bauen einer neuen BVH oder anderen Beschleunigungsdatenstruktur).
Miss- Gibt an, dass ein Strahl die gesamte Geometrie in einer Szene oder einen bestimmten Bereich einer Szene verfehlt.
Visit- Gibt die Child-Volumen an, die ein Strahl durchläuft.
Ausnahmen - Beinhaltet verschiedene Arten von Ausnahme-Handlern (z.B. für diverse Fehlerbedingungen aufgerufen).
2D ist ein Blockdiagramm der Universalzweck-Grafikverarbeitungseinheit (GPGPU) 270, die gemäß hierin beschriebenen Ausführungsformen als ein Grafikprozessor und/oder Rechenbeschleuniger konfiguriert sein kann. Die GPGPU 270 kann mit Host-Prozessoren (z.B. einer oder mehreren CPU(s) 246) und Speicher 271, 272 über ein oder mehrere System(e) und/oder Speicherbusse verbinden. In einer Ausführungsform ist der Speicher 271 ein Systemspeicher, der mit der einen oder den mehreren CPU(s) 246 geteilt werden kann, während Speicher 272 ein Vorrichtungsspeicher ist, der der GPGPU 270 zugewiesen ist. In einer Ausführungsform können Komponenten in der GPGPU 270 und Speichervorrichtung 272 in Speicheradressen abgebildet werden, die der einen oder den mehreren CPU(s) 246 zugänglich sind. Zugriff auf Speicher 271 und 272 kann über einen Speicher-Controller 268 ermöglicht werden. In einer Ausführungsform enthält der Speicher-Controller 268 einen internen Controller für direkten Speicherzugriff (Direct Memory Access; DMA) 269 oder er kann Logik zum Durchführen von Operationen enthalten, die ansonsten von einem DMA-Controller durchgeführt werden würden.
Die GPGPU 270 enthält mehrere Cache-Speicher, einschließlich eines L2-Cache 253, L1-Cache 254, eines Anweisungs-Cache 255 und gemeinsam genutzten Speichers 256, von dem mindestens ein Teil ebenfalls als ein Cache-Speicher partitioniert sein kann. Die GPGPU 270 enthält außerdem mehrere Recheneinheiten 260A-260N. Jede Recheneinheit 260A-260N enthält einen Satz von Vektorregistern 261, Skalarregistern 262, Vektorlogikeinheiten 263 und Skalarlogikeinheiten 264. Die Recheneinheiten 260A-260N können auch lokalen gemeinsam genutzten Speicher 265 und einen Programmzähler 266 enthalten. Die Recheneinheiten 260A-260N können mit einem Konstant-Cache 267 koppeln, der zum Speichern konstanter Daten verwendet werden kann. Das sind Daten, die sich während der Ausführung des Kernel oder Shader-Programms, die auf der GPGPU 270 ausgeführt werden, nicht ändern. In einer Ausführungsform ist der Konstant-Cache 267 ein Skalardaten-Cache und zwischengespeicherte Daten können direkt in die Skalarregister 262 abgerufen werden.
Im Betrieb können die eine oder mehreren CPU(s) 246 Befehle in Register oder Speicher in die GPGPU 270 schreiben, die in einen zugänglichen Adressraum abgebildet wurde. Die Befehlsprozessoren 257 können die Befehle aus Registern oder dem Speicher auslesen und bestimmen, wie diese Befehle in der GPGPU 270 verarbeitet werden. Dann kann ein Thread-Dispatcher 258 zum Versenden der Threads an die Recheneinheiten 260A-260N zur Durchführung dieser Befehle verwendet werden. Jede Recheneinheit 260A-260N kann Threads unabhängig von den anderen Recheneinheiten ausführen. Zusätzlich kann jede Recheneinheit 260A-260N unabhängig für 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 CPU(s) 246 unterbrechen, wenn die übermittelten Befehle abgeschlossen sind.
3A-3C veranschaulichen Blockdiagramme zusätzlicher Grafikprozessor- und Rechenbeschleunigerarchitekturen, die durch die hierin beschriebenen Ausführungsformen bereitgestellt werden. Die Elemente in 3A-3C, die die gleichen Referenzzahlen (oder Bezeichnungen), wie die Elemente einer anderen Figur hierin aufweisen, können auf eine ähnliche Weise arbeiten oder funktionieren, wie an anderer Stelle hierin beschrieben, sie sind aber nicht darauf beschränkt.
3A ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverabeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen oder anderen Halbleitervorrichtungen integriert ist, wie etwa, aber nicht beschränkt auf Speichervorrichtungen oder Netzwerkschnittstellen. In manchen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete I/O-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die in dem Prozessspeicher platziert sind. In manchen Ausführungsformen enthält Grafikprozessor 300 eine Speicherschnittstelle 314 für Zugriff auf den Speicher. Speicherschnittstelle 314 kann eine Schnittstelle mit lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam genutzten externen Caches und/oder dem Systemspeicher bilden.
In manchen Ausführungsformen enthält Grafikprozessor 300 auch einen Anzeige-Controller 302 zum Steuern von Anzeigeausgabedaten an eine Anzeigevorrichtung 318. Anzeige-Controller 302 enthält Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Komposition mehrerer Videoschichten oder Benutzerschnittstellenelemente. Die Anzeigevorrichtung 318 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 318 eine am Kopf angebrachte Anzeigevorrichtung (Head-Mounted Display), wie etwa eine Virtual-Reality-Anzeigevorrichtung (VR) oder eine Augmented-Reality-Anzeigevorrichtung (AR). In manchen Ausführungsformen enthält Grafikprozessor 300 eine Video-Codec-Engine 306 zum Kodieren, Dekodieren oder Transkodieren von Medien zu, von oder zwischen einem oder mehreren Medien-Kodierungsformaten, einschließlich, aber nicht beschränkt auf Moving Picture Experts Group (MPEG) Formate, wie etwa MPEG-2, Advanced Video Coding (AVC) Formate, wie etwa H.264/MPEG-4 AVC, H.265/HEVC, Alliance for Open Media (AOMedia) VP8, VP9 sowie die Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und Joint Photographic Experts Group (JPEG) Formate, wie etwa JPEG und Motion JPEG (MJPEG) Formate.
In manchen Ausführungsformen enthält Grafikprozessor 300 eine Block-Image-Transfer-Engine (BLIT) 304 zum Durchführen zweidimensionaler (2D) Rasterungsoperationen, einschließlich beispielsweise Bit-Boundary Block Transfers. In einer Ausführungsform werden 2D-Grafikoperationen jedoch unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (Graphics Processing Engine; GPE) 310 durchgeführt. In manchen Ausführungsformen ist GPE 310 eine Rechen-Engine zum Durchführen von Grafikoperationen, einschließlich dreidimensionaler (3D) Grafikoperationen und Medienoperationen.
In manchen Ausführungsformen enthält 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 Grundlage von 3D-primitiven Formen (z.B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 312 enthält programmierbare und Festfunktionselemente, die innerhalb des Elements diverse Aufgaben durchführen und/oder Ausführungs-Threads zu einem 3D/Medien-Subsystem 315 spawnen. Während 3D-Pipeline 312 zum Durchführen von Medienoperationen verwendet werden kann, enthält eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316, die speziell zur Durchführung von Medienoperationen verwendet wird, wie etwa Videonachbearbeitung und Bildverbesserung.
In manchen Ausführungsformen enthält Medien-Pipeline 316 Festfunktions- oder programmierbare Logikeinheiten zum Durchführen einer oder mehrerer spezialisierter Medienoperationen, wie etwa Videodekodierungsbeschleunigung, Videoentflechtung und Videokodierungsbeschleunigung anstatt von oder für Video-Codec-Engine 306. In manchen Ausführungsformen enthält Medien-Pipeline 316 zusätzlich eine Thread-Spawning-Einheit zum Spawnen von Threads zur Ausführung auf 3D-/Medien-Subsystem 315. Die gespawnten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten, die in 3D-/Medien-Subsystem 315 enthalten sind, durch.
In manchen Ausführungsformen enthält 3D-/Medien-Subsystem 315 Logik zum Ausführen von Threads, die von 3D-Pipeline 312 und Medien-Pipeline 316 gespawnt wurden. In einer Ausführungsform senden die Pipelines Thread-Ausführungs-Anforderungen an 3D-/Medien-Subsystem 315, die Thread-Dispatch-Logik zur Vermittlung und zum Versand der verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen enthalten. Die Ausführungsressourcen enthalten ein Array von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medien-Threads. In manchen Ausführungsformen enthält 3D-/Medien-Subsystem 315 einen oder mehrere interne Caches für Thread-Anweisungen und Daten. In manchen Ausführungsformen enthält das Subsystem außerdem gemeinsam genutzten Speicher, einschließlich Registern und adressierbarem Speicher, um Daten zwischen Threads zu teilen und um Ausgabedaten zu speichern.
3B veranschaulicht einen Grafikprozessor 320 mit einer Kachelarchitektur gemäß hierin beschriebenen Ausführungsformen. In einer Ausführungsform enthält der Grafikprozessor 320 ein Grafikverarbeitungs-Engine-Cluster 322 mit mehreren Instanzen der Grafikverarbeitungs-Engine 310 der 3A in einer Grafik-Engine-Kachel 310A-310D. Jede Grafik-Engine-Kachel 310A-310D kann über einen Satz von Kachelverbindungen 323A-323F verbunden werden. Jede Grafik-Engine-Kachel 310A-310D kann auch mit einem Speichermodul oder einer Speichervorrichtung 326A-326D über Speicherverbindungen 325A-325D verbunden werden. Die Speichervorrichtungen 326A-326D können jedwede Grafikspeichertechnologie verwenden. Die Speichervorrichtungen 326A-326D können beispielsweise ein GDDR-Speicher (Graphics Double Data Rate) sein. Die Speichervorrichtungen 326A-326D sind in einer Ausführungsform HBM-Module (High-Bandwith Memory), die mit ihrer jeweiligen Grafik-Engine-Kachel 310A-310D in dem 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 sein können. In einer Ausführungsform befindet sich jede Grafik-Engine-Kachel 310A-310D und der zugeordnete Speicher 326A-326D auf separaten Chiplets, die mit einem Basis-Die oder Basissubstrat bondiert sind, wie in 11B-11D ausführlicher beschrieben.
Das Grafik-Verarbeitungs-Engine-Cluster 322 kann mit einer On-Chip- oder On-Package-Fabric-Verbindung 324 verbinden. Die Fabric-Verbindung 324 kann Kommunikation zwischen Grafik-Engine-Kacheln 310A-310D und Komponenten, wie etwa dem Video-Codec 306 und einer oder mehreren Copy-Engines 304, ermöglichen. Die Copy-Engines 304 können verwendet werden, um Daten aus, in und zwischen den Speichervorrichtungen 326A-326D und einem Speicher extern von dem Grafikprozessor 320 (z.B. Systemspeicher) zu bewegen. Die Fabric-Verbindung 324 kann auch dazu verwendet werden, die Grafik-Engine-Kacheln 310A-310D zu verbinden. Der Grafikprozessor 320 kann optional einen Anzeige-Controller 302 enthalten, um eine Verbindung mit einer externen Anzeigevorrichtung 318 zu ermöglichen. Der Grafikprozessor kann auch als ein Grafik- oder Rechenbeschleuniger konfiguriert sein. In der Beschleunigerkonfiguration können der Anzeige-Controller 302 und die Anzeigevorrichtung 318 weggelassen werden.
Der Grafikprozessor 320 kann über eine Host-Schnittstelle 328 mit einem Host-System verbinden. Die Host-Schnittstelle 328 kann Kommunikation zwischen dem Grafikprozessor 320, Systemspeicher und/oder anderen Systemkomponenten ermöglichen. Die Host-Schnittstelle 328 kann beispielsweise ein PCI-Express-Bus oder eine andere Art von Host-System-Schnittstelle sein.
3C veranschaulicht einen Rechenbeschleuniger 330 gemäß hierin beschriebenen Ausführungsformen. Der Rechenbeschleuniger 330 kann architektonische Ähnlichkeiten mit dem Grafikprozessor 320 in 3B aufweisen und ist für Rechenbeschleunigung optimiert. Ein Rechen-Engine-Cluster 332 kann einen Satz von Rechen-Engine-Kacheln 340A-340D enthalten, die Ausführungslogik enthalten, die für Parallel- oder vektorbasierte Universalrechenoperationen optimiert ist. In manchen Ausführungsformen enthalten die Rechen-Engine-Kacheln 340A-340D keine Festfunktionsgrafikverarbeitungslogik, obwohl in einer Ausführungsform eine oder mehrere der Rechen-Engine-Kacheln 340A-340D Logik zum Durchführen von Medienbeschleunigung enthalten können. Die Rechen-Engine-Kacheln 340A-340D können über Speicherverbindungen 325A-325D mit Speichern 326A-326D verbinden. Die Speicher 326A-326D und Speicherverbindungen 325A-325D können eine ähnliche Technologie sein, wie im Grafikprozessor 320, oder sie können unterschiedlich sein. Die Grafik-Rechen-Engine-Kacheln 340A-340D können auch über einen Satz von Kachelverbindungen 323A-323F miteinander verbunden sein und sie können mit und/oder durch eine Fabric-Verbindung 324 verbunden sein. In einer Ausführungsform enthält der Rechenbeschleuniger 330 einen großen L3-Cache 336, der als ein vorrichtungsweiter Cache konfiguriert sein kann. Der Rechenbeschleuniger 330 kann auch mit einem Host-Prozessor und Speicher über eine Host-Schnittstelle 328 auf eine ähnliche Weise verbunden sein, wie der Grafikprozessor 320 in 3B.
Grafikverarbeitungs-Engine
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors gemäß manchen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungs-Engine (GPE) 410 eine Version der in 3A gezeigten GPE 310 und sie kann auch eine Grafik-Engine Kachel 310A-310D in 3B repräsentieren. Elemente in 4, die die gleichen Referenzzahlen (oder Bezeichnungen), wie die Elemente einer anderen Figur hierin aufweisen, können auf eine ähnliche Weise arbeiten oder funktionieren, wie an anderer Stelle hierin beschrieben, sie sind aber nicht darauf beschränkt. Es sind beispielsweise die 3D-Pipeline 312 und Medien-Pipeline 316 in 3A veranschaulicht. Die Medien-Pipeline 316 ist in manchen Ausführungsformen der GPE 410 optional und sie muss nicht explizit in der GPE 410 enthalten sein. Zum Beispiel und in mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
In manchen Ausführungsformen koppelt GPE 410 mit oder enthält einen Befehls-Streamer 403, der einen Befehls-Stream an die 3D-Pipeline 312 und/oder Medien-Pipelines 316 bereitstellt. In manchen Ausführungsformen ist Befehls-Streamer 403 mit Speicher gekoppelt, welcher ein Systemspeicher oder ein oder mehrere interne Cache-Speicher und gemeinsam genutzter Cache-Speicher sein kann. In manchen Ausführungsformen empfängt Befehls-Streamer 403 Befehle von dem Speicher und sendet die Befehle an 3D-Pipeline 312 und/oder Medien-Pipeline 316. Die Befehle sind Direktiven, die von einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 312 und Medien-Pipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Batch-Befehls-Puffer enthalten, die Batches mit mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Verweise auf Daten, die im Speicher gespeichert sind, enthalten, wie etwa, aber nicht beschränkt auf Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 312 und Medien-Pipeline 316 verarbeiten die Befehle und Daten durch Durchführung von Operationen über Logik in den jeweiligen Pipelines oder durch Versenden eines oder mehrerer Ausführungs-Threads an ein Grafikkern-Array 414. In einer Ausführungsform enthalten das Grafikkern-Array 414 einen oder mehrere Blöcke von Grafikkernen (z.B. Grafikkern(e) 415A, Grafikkern(e) 415B), wobei jeder Block einen oder mehrere Grafikkerne enthält. Jeder Grafikkern enthält einen Satz von Grafikausführungsressourcen, die Universal- und grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Rechenoperationen sowie Festfunktionstexturverarbeitung und/oder Maschinenlern- und künstliche Intelligenz Beschleunigungslogik enthalten.
In verschiedenen Ausführungsformen kann die 3D-Pipeline 312 Festfunktions- und programmierbare Logik enthalten, 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 Versenden 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. Mehrzweck-Ausführungslogik (z.B. Ausführungseinheiten) in dem oder den Grafikkern(en) 415A-414B des Grafikkern-Array 414 enthalten Unterstützung für diverse 3D-API-Shader-Sprachen und können mehrere gleichzeitige Ausführungs-Threads, die mehreren Shadern zugeordnet sind, ausführen.
In manchen Ausführungsformen enthält das Grafikkern-Array 414 Ausführungslogik zum Durchführen von Medienfunktionen, wie etwa Video- und/oder Bildverarbeitung. In einer Ausführungsform enthalten die Ausführungseinheiten Universallogik, die programmierbar ist, um parallele Universalrechenoperationen zusätzlich zu Grafikverarbeitungsoperationen durchzuführen. Die Universallogik kann Verarbeitungsoperationen parallel zu oder zusammen mit Universallogik in dem bzw. den Prozessorkern(en) 107 in 1 oder Kern 202A-202N in 2A durchführen.
Von Threads, die auf dem Grafikkern-Array 414 ausgeführt werden, generierte Ausgabedaten können an einen Speicher in einem URB (Unified Return Buffer) 418 ausgegeben werden. Der URB 418 kann Daten für mehrere Threads speichern. In manchen Ausführungsformen kann der URB 418 zum Senden von Daten zwischen unterschiedlichen Threads, die auf dem Grafikkern-Array 414 ausgeführt werden, verwendet werden. In manchen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisation von Threads auf dem Grafikkern-Array und Festfunktionslogik in der gemeinsam genutzten Funktionslogik 420 verwendet werden.
In manchen Ausführungsformen ist Grafikkern-Array 414 derart skalierbar, dass das Array eine variable Anzahl von Grafikkernen enthält, die jeweils eine variable Anzahl von Ausführungseinheiten basierend auf der Zielleistung und dem Leistungsniveau 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 Grafik-Kern-Array 414 koppelt mit gemeinsamer Funktionslogik 420, die mehrere Ressourcen enthält, die zwischen den Grafikkernen in dem Grafikkern-Array geteilt werden. Die gemeinsamen Funktionen in der gemeinsamen Funktionslogik 420 sind Hardwarelogikeinheiten, die spezialisierte Zusatzfunktionalität an das Grafikkern-Array 414 bereitstellen. In verschiedenen Ausführungsformen enthält gemeinsame Funktionslogik 420 Sampler 421, Mathematik 422 und ITC (Inter-Thread Communication) 423 Logik, ist aber nicht darauf beschränkt. Zusätzlich implementieren manche Ausführungsformen einen oder mehrere Cache(s) 425 in der gemeinsamen Funktionslogik 420.
Eine gemeinsame Funktion wird mindestens in einem Fall implementiert, in dem der Bedarf an einer gegebenen spezialisierten Funktion unzureichend für Aufnahme in das Grafikkern-Array 414 ist. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eine eigenständige Entität in der gemeinsamen Funktionslogik 420 implementiert und von den Ausführungsressourcen in dem Grafikkern-Array 414 gemeinsam genutzt. Der genaue Satz von Funktionen, der von dem Grafikkern-Array 414 gemeinsam genutzt wird und in dem Grafikkern-Array 414 enthalten ist, variiert je nach Ausführungsform. In manchen Ausführungsformen können spezifische gemeinsam genutzte Funktionen in der gemeinsamen Funktionslogik 420, die intensiv von dem Grafikkern-Array 414 genutzt werden, in gemeinsame Funktionslogik 416 in dem Grafik-Core-Array 414 aufgenommen werden. In verschiedenen Ausführungsformen kann die gemeinsam genutzte Funktionslogik 416 in dem Grafikkern-Array 414 manche oder die gesamte Logik in der gemeinsam genutzten Funktionslogik 420 enthalten. In einer Ausführungsform können alle Logikelemente in der gemeinsam genutzten Funktionslogik 420 in der gemeinsam genutzten Funktionslogik 416 des Grafikkern-Array 414 dupliziert werden. In einer Ausführungsform ist die gemeinsam genutzte Logik 420 zugunsten der gemeinsam genutzten Funktionslogik 416 in dem Grafikkern-Array 414 ausgeschlossen.
Ausführungseinheiten
5A-5B veranschaulichen Thread-Ausführungslogik 500, die ein Array von Verarbeitungselementen enthält, die in einem Grafikprozessorkern gemäß hierin beschriebenen Ausführungsformen eingesetzt werden. Elemente in 5A-5B, die die gleichen Referenzzahlen (oder Bezeichnungen), wie die Elemente einer anderen Figur hierin aufweisen, können auf eine ähnliche Weise arbeiten oder funktionieren, wie an anderer Stelle hierin beschrieben, sie sind aber nicht darauf beschränkt. 5A-5B veranschaulichen einen Überblick über Thread-Ausführungslogik 500, die für Hardwarelogik repräsentativ sein kann, die mit jedem Sub-Kern 221A-221F in 2B veranschaulicht ist. 5A ist für eine Ausführungseinheit in einem Universalgrafikprozessor repräsentativ, während 5B für eine Ausführungseinheit repräsentativ ist, die in einem Computerbeschleuniger verwendet werden kann.
Wie in 5A veranschaulicht, enthält Thread-Ausführungslogik 500 in manchen Ausführungsformen einen Shader-Prozessor 502, einen Thread-Dispatcher 504, einen Anweisungs-Cache 506, ein skalierbares Ausführungseinheit-Array, das mehrere Ausführungseinheiten 508A-508N enthält, einen Sampler 510, gemeinsam genutzten lokalen Speicher 511, einen Daten-Cache 512 und einen Datenport 514. In einer Ausführungsform kann das skalierbare Ausführungseinheit-Array durch Aktivieren oder Deaktivieren von einer oder mehreren Ausführungseinheiten (z.B. beliebige der Ausführungseinheiten 508A, 508B, 508C, 508D bis 508N-1 und 508) basierend auf den Rechenerfordernissen einer Arbeitslast skalieren. In einer Ausführungsform sind die enthaltenen Komponenten über ein Verbindungs-Fabric, das mit jeder der Komponenten verbunden ist, miteinander verbunden. In manchen Ausführungsformen enthält Thread-Ausführungslogik 500 eine oder mehrere Verbindungen mit einem Speicher, wie etwa Systemspeicher oder Cache-Speicher, durch einen Anweisungs-Cache 506, Datenport 514, Sampler 510 und/oder Ausführungseinheiten 508A-508N. In manchen Ausführungsformen ist jede Ausführungseinheit (z.B. 508A) eine eigenständige programmierbare Universalrecheneinheit, die dazu in der Lage ist, mehrere simultane Hardware-Threads auszuführen, während mehrere Datenelemente parallel für jeden Thread verarbeitet werden. In verschiedenen Ausführungsformen ist das Array von Ausführungseinheiten 508A-508N skalierbar, um eine beliebige Anzahl individueller Ausführungseinheiten zu enthalten.
In manchen Ausführungsformen werden die Ausführungseinheiten 508A-508N primär zum Ausführen von Shader-Programmen verwendet. Ein Shader-Prozessor 502 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads, die den Shader-Programmen zugeordnet sind, über einen Thread-Dispatcher 504 versenden. In einer Ausführungsform enthält der Thread-Dispatcher Logik zum Vermitteln von Thread-Initiierungsanforderungen von den Grafik- und Medien-Pipelines und zum Instanziieren der angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 508A-508N. Eine Geometrie-Pipeline kann beispielsweise Vertex-, Tesselations- oder Geometrie-Shader an die Thread-Ausführungslogik zur Verarbeitung senden. In manchen Ausführungsformen kann Thread-Dispatcher 504 auch Laufzeit-Thread-Spawning-Anforderungen von den ausführenden Shader-Programmen verarbeiten.
In manchen Ausführungsformen unterstützen die Ausführungseinheiten 508A-508N einen Anweisungssatz, der derart native Unterstützung für viele Standard-3D-Grafik-Shader-Anweisungen enthält, 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 SIMD-Ausführung (Multi-Issue Single Instruction Multiple Data) in der Lage und Multi-Thread-Operation ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread in jeder Ausführungseinheit verfügt über eine dedizierte Registerdatei mit hoher Bandbreite und zugeordnetem unabhängigem Thread-Status. Ausführung erfolgt mehrfach pro Takt an Pipelines, die Integer-, einfach und doppeltgenaue Gleitkommaoperationen, SIMD-Verzweigungsfähigkeit, logische Operationen, transzendentale Operationen und andere verschiedene Operationen ausführen können. Während des Wartens auf Daten aus dem Speicher oder einer der gemeinsam genutzten Funktionen veranlasst Abhängigkeitslogik in Ausführungseinheiten 508A-508N einen wartenden Thread zum Schlafen bis die angeforderten Daten zurückgeführt wurden. Während der wartende Thread schläft, können Hardwareressourcen der Verarbeitung anderer Threads gewidmet werden. Während einer Verzögerung in Verbindung mit einer Vertex-Shader-Operation kann eine Ausführungseinheit beispielsweise Operationen für einen Pixel-Shader, Fragment-Shader oder eine andere Art von Shader-Programm durchführen, einschließlich eines anderen Vertex-Shaders. Verschiedene Ausführungsformen können Ausführung durch Verwendung von Single Instruction Multiple Thread (SIMT) als eine Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD anwenden. Verweise auf einen SIMD-Kern oder -Betrieb können auch für SIMT gelten oder für SIMD in Kombination mit SIMT gelten.
Jede Ausführungseinheit in Ausführungseinheiten 508A-508N arbeitet an Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ bzw. die Anzahl der Kanäle für die Anweisung. Ein Ausführungskanal ist eine logische Einheit der Ausführung für Datenelementezugriff, Maskierung und Flusssteuerung in Anweisungen. Die Anzahl der Kanäle kann unabhängig von der Anzahl physischer arithmetischer Logikeinheiten (Arithmetic Logic Units; ALUs) oder Gleitkommaeinheiten (Floating Point Units; FPUs) für einen bestimmten Grafikprozessor sein. In manchen Ausführungsformen unterstützen Ausführungseinheiten 508A-508N Ganzzahl- und Gleitkomma-Datentypen.
Der Ausführungseinheitanweisungssatz enthält SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert werden und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Bei der Arbeit an einem 256-Bit breiten Vektor werden die 256 Bits des Vektors beispielsweise in einem Register gespeichert und die Ausführungseinheit arbeitet an dem Vektor als vier separate gepackte 54-Bit-Datenelemente (Datenelemente mit Quad-Wort (QW) Größe), acht separaten gepackten 32-Bit-Datenelementen (Datenelemente mit Doppel-Wort (DW) Größe), sechzehn separaten gepackten 16-Bit-Datenelementen (Datenelemente mit Wort (W) Größe) oder zweiunddreißig separaten 8-Bit-Datenelementen (Datenelemente mit Byte (B) Größe). Es sind jedoch auch andere Vektorbreiten und Registergrößen möglich.
In einer Ausführungsform kann eine oder können mehrere Ausführungseinheiten in eine gemeinsame Ausführungseinheit 509A-509N mit Thread-Steuerlogik (507A-507N), die den kombinierten EUs gemeinsam ist, kombiniert werden. Mehrere EUs können in eine EU-Gruppe kombiniert werden. Jede EU in der kombinierten EU-Gruppe kann konfiguriert werden, einen separaten SIMD-Hardware-Thread auszuführen. Die Anzahl der EUs in einer kombinierten EU-Gruppe kann je nach Ausführungsform variieren. Zusätzlich können verschiedene SIMD-Breiten pro EU ausgeführt werden, einschließlich, aber nicht beschränkt auf SIMD8, SIMD16 und SIMD32. Jede kombinierte Grafikausführungseinheit 509A-509N enthält mindestens zwei Ausführungseinheiten. Kombinierte Ausführungseinheit 509A enthält beispielsweise eine erste EU 508A, zweite EU 508B und Thread-Steuerlogik 507A, die der ersten EU 508A und der zweiten EU 508B gemeinsam sind. Die Thread-Steuerlogik 507A steuert Threads, die auf der kombinierten Grafikausführungseinheit 509A ausgeführt werden und ermöglicht jeder EU in den kombinierten Ausführungseinheiten 509A-509N unter Verwendung eines gemeinsamen Anweisungszeigerregisters auszuführen.
In der Thread-Ausführungslogik 500 sind ein oder mehrere interne Anweisungs-Caches (z.B. 506) enthalten, um Thread-Anweisungen für die Ausführungseinheiten zwischenzuspeichern. In manchen Ausführungsformen sind ein oder mehrere Daten-Caches (z.B. 512) enthalten, um Thread-Daten während Thread-Ausführung zwischenzuspeichern. Threads, die auf der Ausführungslogik 500 ausgeführt werden, können auch explizit verwaltete Daten in dem gemeinsam genutztem lokalen Speicher 511 speichern. In manchen Ausführungsformen ist ein Sampler 510 enthalten, um Textur-Sampling für 3D-Operationen und Medien-Sampling für Medienoperationen bereitzustellen. In manchen Ausführungsformen enthält Sampler 510 spezialisierte Textur- oder Medien-Sampling-Funktionalität, um Textur- oder Mediendaten während des Sampling-Prozesses vor Bereitstellen der gesampleten Daten an eine Ausführungseinheit zu verarbeiten.
Während der Ausführung senden die Grafik- und Medien-Pipelines über Thread-Spawning- und Dispatch-Logik Thread-Initiierungs-Anforderungen an Thread-Ausführungslogik 500. Nachdem eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten gerastert wurde, wird Pixelprozessorlogik (z.B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) in dem Shader-Prozessor 502 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu veranlassen, dass Ergebnisse zu Ausgabeflächen (z.B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In manchen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertex-Attribute, die über das gerasterte Objekt zu interpolieren sind. In manchen Ausführungsformen führt die Pixel-Prozessor-Logik in dem Shader-Prozessor 502 dann ein API (Application Programming Interface) bereitgestelltes Pixel- oder Fragment-Shader-Programm aus. Zum Ausführen des Shader-Programms sendet der Shader-Prozessor 502 Threads über Thread-Dispatcher 504 an eine Ausführungseinheit (z.B. 508A). In manchen Ausführungsformen verwendet Shader-Prozessor 502 Textur-Sampling-Logik in dem Sampler 510, um auf Texturdaten in Textur-Maps, die im Speicher gespeichert sind, zuzugreifen. Arithmetische Operationen an den Texturdaten und den Eingabegeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen einen oder mehrere Pixel aus der weiteren Verarbeitung.
In manchen Ausführungsformen stellt der Datenport 514 einen Speicherzugangsmechanismus für die Thread-Ausführungslogik 500 bereit, um verarbeitete Daten an den Speicher zur weiteren Verarbeitung in einer Grafikprozessorausgabe-Pipeline auszugeben. In manchen Ausführungsformen enthält der Datenport 514 oder koppelt mit einem oder mehreren Cache-Speichern (z.B. Daten-Cache 512), um Daten für Speicherzugriff über den Datenport zwischenzuspeichern.
In einer Ausführungsform kann die Ausführungslogik 500 auch einen Raytracer 505 enthalten, der Raytracing-Beschleunigungsfunktionalität bereitstellen kann. Der Raytracer 505 kann einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen für Strahlerzeugung enthält. Der Raytracing-Anweisungssatz kann dem Raytracing-Anweisungssatz, der von den Raytracing-Kernen 245 in 2C unterstützt wird, ähnlich sein oder sich davon unterscheiden.
5B veranschaulicht beispielhafte interne Details einer Ausführungseinheit 508 gemäß Ausführungsformen. Eine Grafikausführungseinheit 508 kann eine Anweisungsabrufeinheit 537, ein allgemeines Registerdatei-Array (General Register File; GRF) 524, ein architektonisches Registerdatei-Array (Architectural Register File; ARF) 526, einen Thread-Arbiter 522, eine Sendeeinheit 530, eine Verzweigungseinheit 532, einen Satz von SIMD-Gleitkommaeinheiten (Floating Point Units; FPUs) 534 und in einer Ausführungsform einen Satz dedizierter Ganzzahl-SIMD-ALUs 535 umfassen. Das GRF 524 und ARF 526 enthalten den Satz allgemeiner Registerdateien und Architekturregisterdateien, die jedem simultanen Hardware-Thread zugewiesen sind, der in der Grafikausführungseinheit 508 aktiv sein kann. In einer Ausführungsform wird der architektonische per Thread Zustand in dem ARF 526 aufrechterhalten, während Daten, die während der Thread-Ausführung genutzt werden, in dem GRF 524 gespeichert werden. Der Ausführungszustand jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, können in Thread-spezifischen Registern in dem ARF 526 gehalten werden.
In einer Ausführungsform verfügt die Grafikausführungseinheit 508 über eine Architektur, die eine Kombination aus simultanem Multi-Threading (SMT) und feinkörnigem Interleaved Multi-Threading (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zum Entwurfszeitpunkt auf Grundlage einer Zielanzahl simultaner Threads und einer Anzahl von Registern pro Ausführungseinheit fein abgestimmt sein kann, wobei Ausführungseinheitressourcen über Logik verteilt sind, die zum Ausführen mehrerer simultaner Threads verwendet wird. Die Anzahl logischer Threads, die von der Grafikausführungseinheit 508 ausgeführt werden können, ist nicht auf die Anzahl von Hardware-Threads beschränkt und es können jedem Hardware-Thread mehrere logische Threads zugewiesen werden.
In einer Ausführungsform kann die Grafikausführungseinheit 508 mehrere Anweisungen mit ausgeben, die jeweils andere Anweisungen sein können. Der Thread-Arbiter 522 des Grafikausführungseinheit-Threads 508 kann die Anweisungen an eine von Sendeeinheit 530, Verzweigungseinheit 532 oder SIMD-FPU(s) 534 zur Ausführung versenden. Jeder Ausführungs-Thread kann auf 128 Universalregister in dem GRF 524 zugreifen, wobei jedes Register 32 Bytes speichern kann, auf die als ein SIMD 8-Element-Vektor von 32-Bit-Datenelementen zugegriffen werden kann. In einer Ausführungsform verfügt jeder Ausführungseinheit-Thread über Zugang zu 4 Kbytes in dem GRF 524, obwohl Ausführungsformen nicht auf diese Weise eingeschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt werden können. In einer Ausführungsform ist die Grafikausführungseinheit 508 in sieben Hardware-Threads partitioniert, die Rechenoperationen unabhängig durchführen können, obwohl die Anzahl der Threads pro Ausführungseinheit ebenfalls je nach Ausführungsform variieren kann. In einer Ausführungsform werden beispielsweise bis zu 16 Hardware-Threads unterstützt. In einer Ausführungsform, in der sieben Threads auf 4 Kbytes zugreifen können, kann der GRF 524 insgesamt 28 Kbytes speichern. Wenn 16 Threads auf 4 Kbytes zugreifen können, kann das GRF 524 insgesamt 64 Kbytes speichern. Flexible Adressierungsmodi können es zulassen, dass Register zusammen adressiert werden, um effektiv breitere Register zu bilden oder um geschichtete rechteckige Blockdatenstrukturen zu repräsentieren.
In einer Ausführungsform werden Speicheroperationen, Sampler-Operationen und andere Systemkommunikationen mit höherer Latenz über „Sende“-Anweisungen versendet, die von der Message-Passing-Sendeeinheit 530 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 532 versendet, um SIMD-Divergenz und eventuelle Konvergenz zu ermöglichen.
In einer Ausführungsform enthält die Grafikausführungseinheit 508 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 534 zum Durchführen von Gleitkommaoperationen. In einer Ausführungsform unterstützen die FPU(s) 534 auch Ganzzahlberechnung. In einer Ausführungsform können die FPU(s) 534 bis zu einer M Anzahl von 32-Bit Gleitkomma- (oder Ganzzahl-) Operationen SIMD-ausführen oder bis zu 2M 16-Bit Ganzzahl- oder 16-Bit-Gleitkommaoperationen SIMD-ausführen. In einer Ausführungsform stellt mindestens eine der FPU(s) erweiterte mathematische Fähigkeit zur Unterstützung von transzendentalen mathematischen Funktionen mit hohem Durchsatz und 54-Bit Gleitkomma mit doppelter Präzision bereit. In manchen Ausführungsformen ist auch ein Satz von 8-Bit Ganzzahl-SIMD-ALUs 535 vorhanden und kann spezifisch optimiert sein, um Operationen durchzuführen, die Maschinenlernberechnungen zugeordnet sind.
In einer Ausführungsform können Arrays mehrerer Instanzen der Grafikausführungseinheit 508 in einer Grafik-Sub-Kern-Gruppierung (z.B. einem Sub-Slice) instanziiert werden. Zur Skalierbarkeit können Produktarchitekten die exakte Anzahl von Ausführungseinheiten pro Sub-Kern-Gruppierung wä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 beispielsweise zur Verwendung in einer Rechen-Engine-Kachel 340A-340D, wie in 3C gezeigt, sein, ist insofern aber nicht beschränkt. Varianten der Ausführungseinheit 600 können auch in einer Grafik-Engine-Kachel 310A-310D, wie in 3B gezeigt, verwendet werden. In einer Ausführungsform enthält die Ausführungseinheit 600 eine Thread-Steuereinheit 601, eine Thread-Zustandseinheit 602, eine Anweisungs-Abruf-/Vorabrufeinheit 603 und eine Anweisungsdekodiereinheit 604. Die Ausführungseinheit 600 enthält zusätzlich eine Registerdatei 606, die Register speichert, die an Hardware-Threads in der Ausführungseinheit zugewiesen werden können. Die Ausführungseinheit 600 enthält zusätzlich eine Sendeeinheit 607 und eine Verzweigungseinheit 608. In einer Ausführungsform können die Sendeeinheit 607 und Verzweigungseinheit 608 ähnlich wie die Sendeeinheit 530 und eine Verzweigungseinheit 532 der Grafikausführungseinheit 508 in 5B arbeiten.
Die Ausführungseinheit 600 enthält auch eine Recheneinheit 610, die mehrere unterschiedliche Arten funktionaler Einheiten umfasst. In einer Ausführungsform enthält die Recheneinheit 610 eine ALU-Einheit 611, die ein Array arithmetischer Logikeinheiten umfasst. Die ALU-Einheit 611 kann dafür ausgelegt 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 Mathematikeinheit 613 enthalten. Das systolische Array 612 enthält ein W breites und D tiefes Netzwerk von Datenverarbeitungseinheiten, die verwendet werden können, um Vektor- oder andere datenparallele Operationen auf eine systolische Weise durchzuführen. In einer Ausführungsform kann das systolische Array 612 dafür ausgelegt sein, Matrixoperationen durchzuführen, wie etwa Matrixpunktproduktoperationen. 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 dafür ausgelegt sein, Maschinenlernoperationen zu beschleunigen. In solchen Ausführungsformen kann das systolische Array 612 mit Unterstützung für das bfloat 16-Bit Gleitkommaformat konfiguriert sein. In einer Ausführungsform kann eine Mathematikeinheit 613 enthalten sein, um eine spezifische Untergruppe mathematischer Operationen auf eine effizientere und stromsparendere Weise als die ALU-Einheit 611 durchzuführen. Die Mathematikeinheit 613 kann eine Variante von Mathematiklogik enthalten, die sich in gemeinsam genutzter Funktionslogik einer Grafikverarbeitungs-Engine findet, die von anderen Ausführungsformen bereitgestellt wird (z.B. Mathematiklogik 422 der gemeinsam genutzten Funktionslogik 420 in 4). In einer Ausführungsform kann die Mathematikeinheit 613 dafür ausgelegt sein, 32-Bit und 64-Bit Gleitkommaoperationen durchzuführen.
Die Thread-Steuereinheit 601 enthält Logik zum Steuern der Ausführung von Threads in der Ausführungseinheit. Die Thread-Steuereinheit 601 kann Thread-Arbitrierungslogik zum Starten, Stoppen und zur vorzeitigen Ausführung von Threads in der Ausführungseinheit 600 enthalten. Die Thread-Zustandslogik 602 kann zum Speichern des Thread-Zustands für Threads, die einer Ausführung auf der Ausführungseinheit 600 zugewiesen sind, verwendet werden. Speichern des Thread-Zustands in der Ausführungseinheit 600 ermöglicht die schnelle vorzeitige Ausführung von Threads, wenn diese Threads blockiert werden oder untätig sind. Die Anweisungs-Abruf-/Vorabrufeinheit 603 kann Anweisungen aus einem Anweisungs-Cache einer Ausführungslogik höherer Ebene (z.B. Anweisungs-Cache 506, wie in 5A) abrufen. Die Anweisungs-Abruf-/Vorabrufeinheit 603 kann auch, basierend auf einer Analyse der Threads, die aktuell ausgeführt werden, Vorabrufanforderungen für Anweisungen ausgeben, die in den Anweisungs-Cache zu laden sind. Die Anweisungsdekodiereinheit 604 kann zum Dekodieren von Anweisungen, die von den Recheneinheiten auszuführen sind, verwendet werden. In einer Ausführungsform kann die Anweisungsdekodiereinheit 604 als ein Sekundärdekoder zum Dekodieren komplexer Anweisungen in einzelne Mikrooperationen verwendet werden.
Die Ausführungseinheit 600 enthält zusätzlich eine Registerdatei 606, die von Hardware-Threads genutzt werden kann, die auf der Ausführungseinheit 600 ausgeführt werden. Register in der Registerdatei 606 lassen sich über die Logik, die zum Ausführen mehrerer simultaner Threads in der Recheneinheit 610 der Ausführungseinheit 600 verwendet wird, verteilen. Die Anzahl logischer Threads, die von der Grafikausführungseinheit 600 ausgeführt werden können, ist nicht auf die Anzahl von Hardware-Threads beschränkt und es können jedem Hardware-Thread mehrere logische Threads zugewiesen werden. Die Größe der Registerdatei 606 kann je nach Ausführungsform basierend auf der Anzahl unterstützter Hardware-Threads variieren. In einer Ausführungsform kann Registerumbenennung verwendet werden, um Register dynamisch an Hardware-Threads zuzuweisen.
7 ist ein Blockdiagramm, das ein Grafikprozessoranweisungsformat 700 gemäß manchen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die mit durchgezogenen Linien gezeigten Kästchen veranschaulichen die Komponenten, die im Allgemeinen in einer Ausführungseinheitanweisung enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Untergruppe der Anweisungen enthalten sind. In manchen Ausführungsformen besteht das beschriebene und veranschaulichte Anweisungsformat 700 insofern aus Makroanweisungen, als dass sie Anweisungen sind, die an die Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die aus Anweisungsdekodierung resultieren, nachdem die Anweisung verarbeitet wurde.
In manchen Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten nativ Anweisungen in einem 128-Bit Anweisungsformat 710. Ein kompaktes 64-Bit Anweisungsformat 730 ist für manche Anweisungen basierend auf der gewählten Anweisung, Anweisungsoptionen und Anzahl von Operanden verfügbar. Das native 128-Bit Anweisungsformat 710 stellt Zugang zu allen Anweisungsoptionen bereit, während manche Optionen und Operationen in dem 64-Bit Format 730 eingeschränkt sind. Die in dem 64-Bit Format 730 verfügbaren nativen Anweisungen variieren je nach Ausführungsform. In manchen Ausführungsformen wird die Anweisung teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 verdichtet. Die Ausführungseinheithardware referenziert einen Satz von Verdichtungstabellen basierend auf den Indexwerten und verwendet die Ausgaben der Verdichtungstabelle zum Rekonstruieren einer nativen Anweisung in dem 128-Bit Anweisungsformat 710. Es können auch andere Größen und Formate von Anweisungen verwendet werden
Für jedes Format definiert Anweisungs-Opcode 712 die Operation, die die Ausführungseinheit durchzuführen hat. Die Ausführungseinheiten führen jede Anweisung parallel in den mehreren Datenelementen jedes Operanden aus. In Reaktion auf eine Addieranweisung führt die Ausführungseinheit beispielsweise eine simultane Addieroperation für jeden Farbkanal durch, der ein Texturelement oder Bildelement repräsentiert. Standardmäßig führt die Ausführungseinheit jede Anweisung an allen Datenkanälen der Operanden durch. In manchen Ausführungsformen ermöglicht Anweisungssteuerungsfeld 714 Steuerung bestimmter Ausführungsoptionen, wie etwa Kanalauswahl (z.B. Prädikation) und Datenkanalreihenfolge (z.B. Swizzle). Für Anweisungen in dem 128-Bit Anweisungsformat 710 begrenzt ein exec-size-Feld 716 die Anzahl von Datenkanälen, die parallel ausgeführt werden. In manchen Ausführungsformen steht das exec-size-Feld 716 zur Verwendung in dem kompakten 64-Bit Anweisungsformat 730 nicht zur Verfügung.
Manche Ausführungseinheitanweisungen verfügen über bis zu drei Operanden, einschließlich zwei Quelloperanden, src0 720, src1 722, und ein Ziel 718. In manchen Ausführungsformen unterstützen die Ausführungseinheiten duale Zielanweisungen, wobei eines der Ziele impliziert ist. Datenmanipulationsanweisungen können über einen dritten Quelloperanden (z.B. SRC2 724) verfügen, wobei der Anweisungs-Opcode 712 die Anzahl der Quelloperanden bestimmt. Ein letzter Quelloperand einer Anweisung kann ein unmittelbarer (z.B. hartkodierter) Wert sein, der mit der Anweisung übermittelt wird.
In manchen Ausführungsformen enthält das 128-Bit Anweisungsformat 710 ein Zugriffs-/Adressierungsmodusfeld 726, das beispielsweise spezifiziert, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn direkter Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
In manchen Ausführungsformen enthält das 128-Bit Anweisungsformat 710 ein Zugriffs-/Adressierungsmodusfeld 726, das einen Adressierungsmodus und/oder einen Zugriffsmodus für die Anweisung enthält. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Manche Ausführungsformen unterstützen Zugriffsmodi, die einen ausgerichteten 16-Byte Zugriffsmodus und einen ausgerichteten 1-Byte Zugriffsmodus enthalten, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. In einem ersten Modus kann die Anweisung beispielsweise Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden und in einem zweiten Modus kann die Anweisung ausgerichtete 16-Byte Adressierung für alle Quell- und Zieloperanden enthalten.
In einer Ausführungsform bestimmt der Adressierungsmodusteil des Zugriffs-/Adressierungsmodusfelds 726, ob die Anweisung direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, stellen Bits in der Anweisung die Registeradresse von einem oder mehreren Operanden direkt bereit. 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 manchen Ausführungsformen werden Anweisungen basierend auf Opcode 712 Bit-Feldern gruppiert, um Opcode-Dekodierung 740 zu vereinfachen. Für einen 8-Bit Opcode erlauben Bits 4, 5 und 6 der Ausführungseinheit, die Art des Opcodes zu bestimmen. Die gezeigte genaue Opcode-Gruppierung ist lediglich ein Beispiel. In manchen Ausführungsformen enthält eine Move- und Logik-Opcode-Gruppe 742 Datenbewegungs- und Logikanweisungen (z.B. Move (mov), Compare (cmp)). In manchen Ausführungsformen teilt die Move-und-Logik-Gruppe 742 die fünf höchstwertigsten Bits (Most Significant Bits; MSB), wobei Move-Anweisungen (mov) die Form 0000xxxxb und Logikanweisungen die Form 0001xxxxb haben. Eine Flusssteuerungsanweisungsgruppe 744 (z.B. Call, Jump (jmp)) enthält Anweisungen in der Form 0010xxxxb (z.B. 0x20). Eine Gruppe diverser Anweisungen 746 enthält einen Mix von Anweisungen, einschließlich Synchronisationsanweisungen (z.B. Wait, Send) in der Form 0011xxxxb (z.B. 0x30). Eine Gruppe paralleler mathematischer Anweisungen 748 enthält komponentenweise arithmetische Anweisungen (z.B. Add, Multiply (mul)) in der Form 0100xxxxb (z.B. 0x40). Die parallele mathematische Gruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle aus. Die Gruppe Vektor-Mathematik 750 enthält arithmetische Anweisungen (z.B. dp4) in der Form 0101xxxxb (z.B. 0x50). Die Gruppe Vektor-Mathematik führt Arithmetik durch, wie etwa Punktproduktberechnungen an Verktoroperanden. Die veranschaulichte Opcode-Dekodierung 740 kann in einer Ausführungsform zum Bestimmen verwendet werden, welcher Teil einer Ausführungseinheit zum Ausführen einer dekodierten Anweisung verwendet wird. Manche Anweisungen können beispielsweise als systolische Anweisungen designiert sein, die von einem systolischen Array durchgeführt werden. Andere Anweisungen, wie etwa Raytracing-Anweisungen (nicht gezeigt), können zu einem Raytracing-Kern oder an Raytracing-Logik in einem Slice oder einer Partition der Ausführungslogik weitergeleitet werden.
Grafik-Pipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente in 8, die die gleichen Referenzzahlen (oder Bezeichnungen), wie die Elemente einer anderen Figur hierin aufweisen, können auf eine ähnliche Weise arbeiten oder funktionieren, wie an anderer Stelle hierin beschrieben, sie sind aber nicht darauf beschränkt.
In manchen Ausführungsformen enthält Grafikprozessor 800 eine Geometrie-Pipeline 820, eine Medien-Pipeline 830, eine Anzeige-Engine 840, Thread-Ausführungslogik 850 und eine Rendering-Ausgabe-Pipeline 870. In manchen Ausführungsformen ist Grafikprozessor 800 ein Grafikprozessor in einem Mehrkern-Verarbeitungssystem, das einen oder mehrere Universalverarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle gesteuert, die an Grafikprozessor 800 über eine Ringverbindung 802 ausgegeben werden. In manchen Ausführungsformen koppelt Ringverbindung 802 Grafikprozessor 800 mit anderen Verarbeitungskomponenten, wie etwa anderen Grafikprozessoren oder Universalprozessoren. Befehle von Ringverbindung 802 werden von einem Befehls-Streamer 803 interpretiert, der Anweisungen an individuelle Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 zuführt.
In manchen Ausführungsformen leitet Befehls-Streamer 803 den Betrieb eines Vertex-Fetchers 805 an, der Vertexdaten aus Speicher liest und Vertexverarbeitungsbefehle, die von Befehls-Streamer 803 bereitgestellt werden, ausführt. In manchen Ausführungsformen stellt Vertex-Fetcher 805 Vertexdaten an einen Vertex-Shader 807 bereit, der Koordinatenraumtransformation und Beleuchtungsoperationen an jedem Vertex durchführt. In manchen Ausführungsformen führen Vertex-Fetcher 805 und Vertex-Shader 807 Vertexverarbeitungsanweisungen durch Versenden von Ausführungs-Threads an Ausführungseinheiten 852A-852B über einen Thread-Dispatcher 83 1 aus.
In manchen Ausführungsformen sind Ausführungseinheiten 852A-852B ein Array von Vektorprozessoren mit einem Anweisungssatz zum Durchführen von Grafik- und Medienoperationen. In manchen Ausführungsformen verfügen Ausführungseinheiten 852A-852B über einen verbundenen L1-Cache 851, 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 Einzel-Cache, der partitioniert ist, um Daten und Anweisungen in unterschiedlichen Partitionen zu halten, konfiguriert sein.
In manchen Ausführungsformen enthält Geometrie-Pipeline 820 Tesselierungskomponenten zur Durchführung von hardwarebeschleunigter Tesselierung von 3D-Objekten. In manchen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tesselierungsoperationen. Ein programmierbarer Domain-Shader 817 stellt Backend-Auswertung der Tesselierungsausgabe bereit. Ein Tesselator 813 arbeitet unter Anleitung des Hull-Shaders 811 und enthält Speziallogik zum Generieren eines Satzes detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell, das als Eingabe in Geometrie-Pipeline 820 bereitgestellt wird. In manchen Ausführungsformen können, wenn keine Tesselierung verwendet wird, Tesselierungskomponenten (z.B. Hull-Shader 811, Tesselator 813 und Domain-Shader 817) umgangen werden.
In manchen Ausführungsformen können vollständige geometrische Objekte von einem Geometrie-Shader 819 über einen oder mehrere Threads verarbeitet werden, die an Ausführungseinheiten 852A-852B gesendet werden, oder sie können direkt zu dem Clipper 829 fortfahren. In manchen Ausführungsformen arbeitet der Geometrie-Shader an ganzen geometrischen Objekten anstatt von Vertices oder Flecken von Vertices, wie in den vorherigen Stufen der Grafikpipeline. Wenn die Tesselierung deaktiviert ist, empfängt der Geometrie-Shader 819 Eingaben von dem Vertex-Shader 807. In manchen Ausführungsformen ist Geometrie-Shader 819 durch ein Geometrie-Shader-Programm programmierbar, Geometrie-Tesselierung durchzuführen, wenn die Tesselierungseinheiten deaktiviert sind.
Vor Rasterung verarbeitet ein Clipper 829 Vertexdaten. Der Clipper 829 kann ein Festfunktions-Clipper oder ein programmierbarer Clipper mit Clipping- und Geometrie-Shader-Funktionen sein. In manchen Ausführungsformen sendet eine Rasterungs- und Tiefentestkomponente 873 in der Rendering-Ausgabe-Pipeline 870 Pixel-Shader zum Wandeln der geometrischen Objekte in per-Pixel-Repräsentationen. In manchen Ausführungsformen ist Pixel-Shader-Logik in Thread-Ausführungs-Logik 850 enthalten. In manchen Ausführungsformen kann eine Anweisung die Rasterungs- und Tiefentestkomponente 873 umgehen und über eine Stream-out-Einheit 823 auf ungerasterte Vertexdaten zugreifen.
Der Grafikprozessor 800 verfügt über einen Verbindungs-Bus, ein Verbindungs-Fabric oder irgendeinen anderen Verbindungsmechanismus, der es erlaubt, Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors weiterzugeben. In manchen Ausführungsformen verbinden Ausführungseinheiten 852A-852B und zugeordnete Logikeinheiten (z.B. L1-Cache 851, Sampler 854, Textur-Cache 858 usw.) über einen Datenport 856, um Zugriff auf und Kommunikation mit Rendering-Ausgabe-Pipeline-Komponenten des Prozessors durchzuführen. In manchen Ausführungsformen verfügen Sampler 854, Caches 851, 858 und Ausführungseinheiten 852A-852B jeweils über separate Speicherzugriffspfade. In einer Ausführungsform kann der Textur-Cache 858 auch als ein Sampler-Cache konfiguriert sein.
In manchen Ausführungsformen enthält Rendering-Ausgabe-Pipeline 870 eine Rasterungs- und Tiefentestkomponente 873, die Vertex-basierte Objekte in eine zugeordnete pixelbasierte Repräsentation wandelt. In manchen Ausführungsformen enthält die Rasterungslogik eine Fenster-/Maskierereinheit zum Durchführen von Festfunktions-Dreieck- und Linienrasterung. In manchen Ausführungsformen stehen auch ein zugeordneter Rendering-Cache 878 und Tiefen-Cache 879 zur Verfügung. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten durch, obwohl in manchen Fällen Pixeloperationen, die 2D-Operationen (z.B. Bit-Block-Bildtransfers mit Überblendung) zugeordnet sind, von der 2D-Engine 841 durchgeführt oder zum Anzeigezeitpunkt durch die Anzeigesteuerung 843 unter Verwendung von Overlay-Anzeigeebenen ersetzt wird. In manchen Ausführungsformen steht allen Grafikkomponenten ein gemeinsam genutzter L3-Cache 875 zur Verfügung, der die gemeinsame Nutzung von Daten ohne die Verwendung des Hauptsystemspeichers erlaubt.
In manchen Ausführungsformen enthält Grafikprozessor-Medien-Pipeline 830 eine Medien-Engine 837 und ein Video-Frontend 834. In manchen Ausführungsformen empfängt Video-Frontend 834 Pipeline-Befehle von dem Befehls-Streamer 803. In manchen Ausführungsformen enthält Medien-Pipeline 830 einen separaten Befehls-Streamer. In manchen Ausführungsformen verarbeitet Video-Frontend 834 Medienbefehle vor Senden des Befehls an die Medien-Engine 837. In manchen Ausführungsformen enthält Medien-Engine 837 Thread-Spawning-Funktionalität zum Spawnen von Threads zum Versand an Thread-Ausführungslogik 850 über Thread-Dispatcher 831.
In manchen Ausführungsformen enthält Grafikprozessor 800 eine Anzeige-Engine 840. In manchen Ausführungsformen ist Anzeige-Engine 840 extern zu Prozessor 800 und koppelt mit dem Grafikprozessor über die Ringverbindung 802 oder einen anderen Verbindungs-Bus oder ein anderes Verbindungs-Fabric. In manchen Ausführungsformen enthält Anzeige-Engine 840 eine 2D-Engine 841 und eine Anzeigesteuerung 843. In manchen Ausführungsformen enthält Anzeige-Engine 840 Speziallogik, die dazu in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In manchen Ausführungsformen koppelt Anzeigesteuerung 843 mit einer Anzeigevorrichtung (nicht gezeigt), die eine systemintegrierte Anzeigevorrichtung sein kann, wie in einem Laptop-Computer, oder eine externe Anzeigevorrichtung, die über einen Anzeigevorrichtungskonnektor verbunden ist.
In manchen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 konfigurierbar, um Operationen auf Grundlage mehrerer Grafik- und Medienprogrammierungsschnittstellen durchzuführen und sind nicht für irgendeine Anwendungsprogrammierschnittstelle (API) spezifisch. In manchen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die von dem Grafikprozessor verarbeitet werden können. In manchen Ausführungsformen wird Unterstützung für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan-Grafik- und Rechen-API, alle von der Khronos Group, bereitgestellt. In manchen Ausführungsformen kann auch Unterstützung für die Direct3D-Bibliothek der Microsoft Corporation bereitgestellt werden. In manchen Ausführungsformen kann eine Kombination aus diesen Bibliotheken unterstützt werden. Unterstützung kann auch für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde ebenfalls unterstützt, wenn ein Mapping aus der Pipeline der zukünftigen API zu der Pipeline des Grafikprozessors erfolgen kann.
Grafik-Pipeline-Programmierung
9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat 900 gemäß manchen Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 910 gemäß einer Ausführungsform veranschaulicht. Die in 9A gezeigten Kästchen mit durchgezogenen Linien veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind, oder die nur in einer Untergruppe der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessorbefehlsformat 900 in 9A enthält Datenfelder zum Identifizieren eines Client 902, einen Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl. In manchen Befehlen sind auch ein Sub-Opcode 905 und eine Befehlsgröße 908 enthalten.
In manchen Ausführungsformen spezifiziert Client 902 die Client-Einheit der Grafikvorrichtung, die die Befehlsdaten verarbeitet. In manchen Ausführungsformen untersucht ein Grafikprozessorbefehl-Parser das Client-Feld jedes Befehls, um das weitere Verarbeiten des Befehls zu bedingen und leitet die Befehlsdaten an die entsprechende Client-Einheit weiter. In manchen Ausführungsformen enthalten die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Rendering-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Client-Einheit hat eine entsprechende Verarbeitungs-Pipeline, die die Befehle verarbeitet. Nachdem der Befehl von der Client-Einheit empfangen wurde, liest die Client-Einheit den Opcode 904 und, sofern vorhanden, Sub-Opcode 905, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Informationen in Datenfeld 906 durch. Für manche Befehle wird eine explizite Befehlsgröße 908 erwartet, um die Größe des Befehls zu spezifizieren. In manchen Ausführungsformen bestimmt der Befehls-Parser automatisch die Größe zumindest eines Teils des Befehls auf Grundlage des Befehl-Opcodes. In manchen Ausführungsformen sind Befehle über Vielfache eines Doppelworts ausgerichtet. Es können auch andere Befehlsformate verwendet werden.
Das Flussdiagramm in 9B veranschaulicht eine beispielhafte Grafikprozessorbefehlssequenz 910. In manchen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors darstellt, eine Version der gezeigten Befehlssequenz zum Einrichten, Ausführen und Beenden eines Satzes von Grafikoperationen. Eine beispielhafte Befehlssequenz wird ausschließlich zu Beispielzwecken gezeigt und beschrieben, da Ausführungsformen nicht auf diese konkreten Befehle oder auf diese Befehlssequenz beschränkt sind. Darüber hinaus können die Befehle als ein Befehlsstapel in einer Befehlssequenz ausgegeben werden, so dass der Grafikprozessor die Befehlssequenz zumindest teilweise gleichzeitig verarbeitet.
In manchen Ausführungsformen kann die Grafikprozessorbefehlssequenz 910 mit einem Pipeline-Flush-Befehl 912 beginnen, um zu veranlassen, dass eine aktive Grafik-Pipeline die aktuell für die Pipeline ausstehenden Befehle abschließt. In manchen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Der Pipeline-Flush wird durchgeführt, um die aktive Grafik-Pipeline zu veranlassen, jedwede ausstehenden Befehle abzuschließen. In Reaktion auf einen Pipeline-Flush pausiert der Befehls-Parser für den Grafikprozessor das Befehlsverarbeiten bis die aktiv ziehenden Engines ausstehende Operationen beendet haben und die relevanten Lese-Caches ungültig gemacht wurden. Optional können Daten, die in dem Rendering-Cache als „dirty“ markiert sind, in einen Speicher gespült werden. In manchen Ausführungsformen kann Pipeline-Flush-Befehl 912 zur Pipeline-Synchronisation oder vor Platzieren des Grafikprozessor in einen Stromsparmodus verwendet werden.
In manchen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz erforderlich macht, dass der Grafikprozessor explizit zwischen Pipelines schaltet. In manchen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 nur einmal innerhalb eines Ausführungskontexts vor Ausgabe von Pipeline-Befehlen erforderlich, sofern der Kontext nicht Ausgabe von Befehlen für beide Pipelines umfasst. In manchen Ausführungsformen ist ein Pipeline-Flush-Befehl 912 unmittelbar vor einem Pipeline-Wechsel über den Pipeline-Auswahlbefehl 913 erforderlich.
In manchen Ausführungsformen konfiguriert ein Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für den Betrieb und wird zum Programmieren der 3D-Pipeline 922 und der Medien-Pipeline 924 verwendet. In manchen Ausführungsformen konfiguriert Pipeline-Steuerbefehl 914 den Pipeline-Zustand für die aktive Pipeline. In einer Ausführungsform wird der Pipeline-Steuerbefehl 914 für Pipeline-Synchronisation und zum Löschen von Daten aus einem oder mehreren Cache-Speichern in der aktiven Pipeline vor Verarbeiten eines Befehlstapels verwendet.
In manchen Ausführungsformen werden Return-Buffer-Zustandsbefehle 916 zum Konfigurieren eines Satzes von Return-Puffern für die jeweiligen Pipelines zum Schreiben von Daten verwendet. Manche Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration von einem oder mehreren Return-Puffern, in die die Operationen Zwischendaten während der Verarbeitung schreiben. In manchen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Return-Puffer zum Speichern von Ausgabedaten und zum Durchführen von Thread-übergreifender Kommunikation. In manchen Ausführungsformen umfasst der Return-Buffer-Zustand 916 Auswählen der Größe und Anzahl von Return-Puffern zur Verwendung für einen Satz von Pipeline-Operationen.
Die übrigen Befehle in der Befehlssequenz unterscheiden sich auf Grundlage der aktiven Pipeline für Operationen. Basierend auf einer Pipeline-Bestimmung 920 wird die Befehlssequenz der 3D-Pipeline 922, beginnend mit dem 3D-Pipeline-Zustand 930, oder der Medien-Pipeline 924, beginnend mit dem Medien-Pipeline-Zustand 940, individuell angepasst.
Die Befehle zum Konfigurieren des 3D-Pipeline-Zustands 930 enthalten 3D-Zustandseinstellungsbefehle für den Vertex-Pufferzustand, Vertex-Elementzustand, Konstantfarbenzustand, Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitivenbefehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise auf Grundlage des konkreten 3D-API in Verwendung bestimmt. In manchen Ausführungsformen sind 3D-Pipeline-Zustand 930 Befehle auch dazu in der Lage, bestimmte Pipeline-Elemente zu deaktivieren oder zu umgehen, wenn diese Elemente nicht genutzt werden.
In manchen Ausführungsformen wird der 3D-Primitiv 932 Befehl zur Übermittlung von durch die 3D-Pipeline zu verarbeitenden 3D-Primitiven verwendet. Befehle und zugeordnete Parameter, die über den 3D-Primitiv 932 Befehl an den Grafikprozessor übergeben werden, werden an die Vertex-Abruffunktion der Grafikpipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die 3D-Primitv 932 Befehlsdaten zum Generieren von Vertexdatenstrukturen. Die Vertexdatenstrukturen werden in einem oder mehreren Return-Puffern gespeichert. In manchen Ausführungsformen wird der 3D-Primitiv 932 Befehl zum Durchführen von Vertexoperationen an 3D-Primitiven über Vertex-Shader verwendet. Zum Verarbeiten von Vertex-Shadern versendet 3D-Pipeline 922 Shader-Ausführungs-Threads an Grafikprozes sorausführungseinheiten.
In manchen Ausführungsformen wird 3D-Pipeline 922 über einen Ausführung 934 Befehl oder Ereignis ausgelöst. In manchen Ausführungsformen löst ein Registerschreibvorgang Befehlsausführung aus. In manchen Ausführungsformen wird Ausführung über einen „Go“- oder „Kick“-Befehl in der Befehlssequenz ausgelöst. In einer Ausführungsform wird Befehlsausführung unter Verwendung eines Pipeline-Synchronisationsbefehls zum Auslagern der Befehlssequenz durch die Grafik-Pipeline ausgelöst. Die 3D-Pipeline führt Geometrieverarbeitung für die 3D-Primitiven durch. Nachdem die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixel-Engine koloriert die resultierenden Pixel. Für diese Operationen können auch zusätzliche Befehle zum Steuern von Pixel-Shading und Pixel-Backend-Operationen enthalten sein.
In manchen Ausführungsformen folgt die Grafikprozessorbefehlssequenz 910 bei Durchführung von Medienoperationen dem Pfad der Medien-Pipeline 924. Im Allgemeinen hängt die spezifische Verwendung und Art und Weise der Programmierung für die Medien-Pipeline 924 von den Medien oder durchzuführenden Rechenoperationen ab. Spezifische Mediendekodieroperationen können während der Mediendekodierung zu der Medien-Pipeline ausgelagert werden. In manchen Ausführungsformen kann die Medien-Pipeline auch umgangen werden und Mediendekodierung kann insgesamt oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Universalverarbeitungskernen bereitgestellt werden. In einer Ausführungsform enthält die Medien-Pipeline auch Elemente für Operationen einer Universalgrafikprozessoreinheit (General-Purpose Graphics Processor Unit; GPGPU), wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Berechnungs-Shader-Programmen durchzuführen, die nicht explizit auf das Rendern von Grafik-Primitiven bezogen sind.
In manchen Ausführungsformen ist Medien-Pipeline 924 auf eine ähnliche Weise konfiguriert wie die 3D-Pipeline 922. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipeline-Zustands 940 wird vor den Medien-Objektbefehlen 942 an eine Befehlswarteschlange gesendet oder darin platziert. In manchen Ausführungsformen enthalten Befehle für den Medien-Pipeline-Zustand 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medienobjekte verwendet werden. Diese enthalten Daten zum Konfigurieren der Videodekodier- und Videokodierlogik in der Medien-Pipeline, wie etwa Kodier- und Dekodierformat. In manchen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Zustand 940 auch die Verwendung von einem oder mehreren Zeigern zu „indirekten“ Zustandselementen, die einen Stapel von Zustandseinstellungen enthalten.
In manchen Ausführungsformen führen Medienobjektbefehle 942 Zeiger an Medienobjekte zum Verarbeiten durch die Medien-Pipeline zu. Die Medienobjekte enthalten Speicherpuffer, die zu verarbeitende Videodaten enthalten. In manchen Ausführungsformen müssen alle Medien-Pipeline-Zustände vor Ausgabe eines Medienobjektbefehls 942 gültig sein. Nachdem der Pipeline-Zustand konfiguriert ist und Medienobjektbefehle 942 in der Warteschlange stehen, wird die Medien-Pipeline 924 über einen Ausführbefehl 944 oder ein äquivalentes Ausführereignis (z.B. Registerschreibvorgang) ausgelöst. Die Ausgabe aus der Medien-Pipeline 924 kann dann durch Operationen, die von der 3D-Pipeline 922 oder der Medien-Pipeline 924 bereitgestellt werden, nachbearbeitet werden. In manchen Ausführungsformen sind GPGPU-Operationen konfiguriert und werden auf eine ähnliche Weise ausgeführt, wie Medienoperationen.
Grafik-Software-Architektur
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß manchen Ausführungsformen. In manchen Ausführungsformen enthält Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. In manchen Ausführungsformen enthält Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Universalprozessorkern(e) 1034. Die Grafikanwendung 1010 und Betriebssystem 1020 führen jeweils in dem Systemspeicher 1050 des Datenverarbeitungssystems aus.
In manchen Ausführungsformen enthält 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programm(e), die Shader-Anweisungen 1012 enthalten. Die Shader-Sprachanweisungen können in einer Shader-Sprache hoher Ebene sein, wie etwa die High-Level Shader Language (HLSL) von Direct3D, die OpenGL Shader Language (GLSL) usw. Die Anwendung enthält auch ausführbare Anweisungen 1014 in einer Maschinensprache, die zur Ausführung durch den Universalprozessorkern 1034 geeignet ist. Die Anwendung enthält außerdem Grafikobjekte 1016, die durch Vertexdaten definiert sind.
In manchen Ausführungsformen ist Betriebssystem 1020 ein Microsoft® Windows® Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein Open-Source UNIX-ähnliches Betriebssystem unter Verwendung des Linux-Kernels. 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, nutzt das Betriebssystem 1020 einen Frontend-Shader-Compiler 1024 zum Kompilieren von Shader-Anweisungen 1012 in HLSL in eine Shader-Sprache niedrigerer Ebene. Die Kompilierung kann eine Just-in-Time (JIT) Kompilierung sein oder die Anwendung kann Shader-Vorkompilierung durchführen. In manchen Ausführungsformen werden Shader hoher Ebene während der Kompilierung der 3D-Grafikanwendung 1010 in Shader niedriger Ebene kompiliert. In manchen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform bereitgestellt, wie etwa als eine Version der Standard Portable Intermediate Representation (SPIR), die von der Vulkan-API genutzt wird.
In manchen Ausführungsformen enthält Benutzermodusgrafiktreiber 1026 einen Backend-Shader-Compiler 1027 zum Wandeln der Shader-Anweisungen 1012 in eine hardwarespezifische Repräsentation. Wenn die OpenGL-API verwendet wird, werden Shader-Anweisungen 1012 in der GLSL-Sprache hoher Ebene zu einem Benutzermodusgrafiktreiber 1026 zur Kompilierung übergeben. In manchen Ausführungsformen verwendet Benutzermodusgrafiktreiber 1026 Betriebssystem-Kernel-Modusfunktionen 1028, um mit einem Kernel-Modusgrafiktreiber 1029 zu kommunizieren. In manchen Ausführungsformen kommuniziert Kernel-Modusgrafiktreiber 1029 mit Grafikprozessor 1032, um Befehle und Anweisungen zu versenden.
IP-Kern-Implementierungen
Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch repräsentativen Code implementiert werden, der auf einem maschinenlesbarem Medium gespeichert ist, das Logik in einer integrierten Schaltung, wie einem Prozessor, repräsentiert und/oder definiert. Das maschinenlesbare Medium kann beispielsweise Anweisungen enthalten, die verschiedene Logik in dem Prozessor repräsentieren. Wenn sie von einer Maschine gelesen werden, können die Anweisungen die Maschine veranlassen, die Logik zum Durchführen der hierin beschriebenen Techniken herzustellen. Solche Repräsentationen, die als „IP-Kerne“ (IP-Cores) bekannt sind, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem greifbarem, maschinenlesbarem Medium als ein Hardwaremodell, das die Struktur der integrierten Schaltung beschreibt, gespeichert werden können. Das Hardwaremodell kann an verschiedene Kunden oder Fertigungseinrichtungen geliefert werden, die das Hardwaremodell auf Fertigungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann derart gefertigt werden, dass die Schaltung Operationen durchführt, die hierin in Verbindung mit jedweden der Ausführungsformen beschrieben sind.
11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100 veranschaulicht, das zur Herstellung einer integrierten Schaltung zur Durchführung von Operationen gemäß einer Ausführungsform verwendet werden kann. Das IP-Kern-Entwicklungssystem 1100 kann zum Generieren modularer, wiederverwendbarer Designs verwendet werden, die in ein größeres Design integriert oder zum Konstruieren einer gesamten integrierten Schaltung (z.B. einer integrierten SoC-Schaltung) verwendet werden können. Eine Designeinrichtung 1130 kann eine Softwaresimulation 1110 eines IP-Kern-Designs in einer Programmiersprache hoher Ebene (z.B. C/C++) generieren. Die Softwaresimulation 1110 kann für den Entwurf, das Testen und Verifizieren des Verhaltens des IP-Kerns unter Verwendung eines Simulationsmodells 1112 eingesetzt werden. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Zeitsimulationen enthalten. Ein Design auf Register-Transfer-Ebene (RTL) 1115 kann dann aus dem Simulationsmodell 1112 erstellt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Daten zwischen Hardwareregistern modelliert, einschließlich der dazugehörigen Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs tieferer Ebene auf der Logikebene oder Transistorebene erstellt, entworfen oder synthetisiert werden. Somit können die konkreten Details des anfänglichen Designs und der Simulation variieren.
Das RTL-Design 1115 oder ein Äquivalent können durch die Designeinrichtung in ein Hardwaremodell 1120, das in einer Hardwarebeschreibungssprache (Hardware Description Language; HDL) oder eine andere Repräsentation physischer Designdaten sein kann, weiter synthetisiert werden. Die HDL kann weiterhin simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann für Auslieferung an eine Dritt-Fertigungseinrichtung 1165 unter Verwendung eines nichtflüchtigen Speichers 1140 (z.B. Festplatte, Flash-Speicher oder jedwedes nichtflüchtige Speichermedium) gespeichert werden. Alternativ kann das IP-Kern-Design (z.B. über das Internet) über eine drahtgebundene Verbindung 1150 oder eine drahtlose Verbindung 1160 übertragen werden. Die Fertigungseinrichtung 1165 kann dann eine integrierte Schaltung fertigen, die zumindest teilweise auf dem IP-Kern-Design basiert. Die gefertigte integrierte Schaltung kann dafür ausgelegt sein, Operationen in Übereinstimmung mit mindestens einer hierin beschriebenen Ausführungsform durchzuführen.
11B veranschaulicht eine Querschnittsseitenansicht einer Package-Baugruppe einer integrierten Schaltung 1170 gemäß manchen hierin beschriebenen Ausführungsformen. Die Package-Baugruppe einer integrierten Schaltung 1170 veranschaulicht eine Implementierung einer oder mehrerer Prozessor- oder Beschleunigervorrichtungen, wie hierin beschrieben. Die Package-Baugruppe 1170 enthält mehrere Einheiten von Hardware-Logik 1172, 1174, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann zumindest teilweise in konfigurierbarer Logik oder Festfunktionalitätslogikhardware implementiert sein und sie kann einen oder mehrere Teile eines Prozessorkerns/Prozessorkerne, Grafikprozessor(en) oder anderer hierin beschriebener Beschleunigervorrichtungen enthalten. Jede Einheit der Logik 1172, 1174 kann in einem Halbleiter-Die implementiert und über eine Verbindungsstruktur 1173 mit dem Substrat 1180 verbunden sein. Die Verbindungsstruktur 1173 kann dafür ausgelegt sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 weiterzuleiten und kann Verbindungen, wie etwa Höcker oder Säulen enthalten, ist aber nicht darauf beschränkt. In manchen Ausführungsformen kann die Verbindungsstruktur 1173 dafür ausgelegt sein, elektrische Signale, wie beispielsweise Eingabe-/Ausgabesignale (I/O) und/oder Strom- oder Massesignale, die dem Betrieb der Logik 1172, 1174 zugeordnet sind, weiterzuleiten. In manchen Ausführungsformen ist das Substrat 1180 ein Substrat auf Basis von Epoxidlaminat. Das Substrat 1180 kann in anderen Ausführungsformen auch andere geeignete Arten von Substraten enthalten. Die Package-Baugruppe 1170 kann über eine Package-Verbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Package-Verbindung 1183 kann mit einer Fläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie etwa eine Hauptplatine, andere Chipsätze oder ein Mehrchipmodul, zu leiten.
In manchen Ausführungsformen sind die Einheiten der Logik 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die dafür ausgelegt ist, elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Brücke 1182 kann eine dichte Verbindungsstruktur sein, die einen Weg für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat enthalten, 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 Einheiten von Logik 1172, 1174 und eine Brücke 1182 veranschaulicht sind, können hierin beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies enthalten. Der eine oder die mehreren Dies können durch Null oder mehr Brücken verbunden sein, da die Brücke 1182 ausgeschlossen werden kann, wenn die Logik auf einem einzelnen Die enthalten ist. Alternativ 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 dreidimensionalen Konfigurationen, miteinander verbunden werden.
11C veranschaulicht eine Package-Baugruppe 1190, die mehrere Einheiten von Hardware-Logik-Chiplets enthält, die mit einem Substrat 1180 (z.B. einem Basis-Die) verbunden sind. Ein(e) Grafikverarbeitungseinheit, Parallelprozessor und/oder Rechenbeschleuniger, wie hierin beschrieben, kann bzw. können aus diversen Siliziumchiplets zusammengesetzt sein, die separat hergestellt wurden. In diesem Zusammenhang ist ein Chiplet zumindest teilweise eine gepackte integrierte Schaltung, die unterschiedliche Logikeinheiten enthält, die mit anderen Chiplets in ein größeres Package gepackt werden können. Ein vielfältiger Satz von Chiplets mit unterschiedlicher IP-Kern-Logik kann in eine einzelne Vorrichtung gepackt werden. Zusätzlich können die Chiplets in einen Basis-Die oder ein Basis-Chiplet unter Verwendung aktiver Interposertechnologie integriert werden. Die hierin beschriebenen Konzepte ermöglichen die Verbindung und Kommunikation zwischen den unterschiedlichen Formen von IP innerhalb der GPU. IP-Kerne können unter Verwendung unterschiedlicher Prozesstechnologien hergestellt und während der Fertigung zusammengesetzt werden, was die Komplexität des Konvergierens mehrerer IPs, insbesondere auf einem großen SoC mit mehreren Arten von IPs, in dem gleichen Fertigungsprozess vermeidet. Ermöglichung der Verwendung mehrerer Prozesstechnologien verbessert die Markteinführungszeit und bietet eine kosteneffektive Möglichkeit, mehrere Produkt-SKUs zu erstellen. Außerdem lassen sich die disaggregierten IPs besser unabhängig mit Strom versorgen. Komponenten, die bei einer gegebenen Arbeitslast nicht in Verwendung sind, können ausgeschaltet werden, was den Gesamtstromverbrauch reduziert.
Die Hardwarelogikchiplets können Spezial-Hardwarelogikchiplets 1172, Logik- oder I/O-Chiplets 1174 und/oder Speicherchiplets 1175 enthalten. Die Hardwarelogikchiplets 1172 und Logik- oder I/O-Chiplets 1174 können zumindest teilweise in konfigurierbarer Logik oder Festfunktionalitätslogikhardware implementiert sein und sie können einen oder mehrere Teile eines von Prozessorkern/Prozessorkernen, Grafikprozessor(en) oder anderer hierin beschriebener Beschleunigervorrichtungen enthalten. Die Speicherchiplets 1175 können DRAM-Speicher (z.B. GDDR, HBM) oder Cache-Speicher (SRAM) sein.
Jedes Chiplet kann als separater Halbleiter-Die gefertigt und mit dem Substrat 1180 über eine Verbindungsstruktur 1173 gekoppelt werden. Die Verbindungsstruktur 1173 kann dafür ausgelegt sein, um elektrische Signale zwischen den verschiedenen Chiplets und Logik in dem Substrat 1180 zu leiten. Die Verbindungsstruktur 1173 kann Verbindungen enthalten, wie etwa, aber nicht beschränkt auf Höcker oder Säulen. In manchen Ausführungsformen kann die Verbindungsstruktur 1173 dafür ausgelegt sein, elektrische Signale, wie beispielsweise Eingabe-/Ausgabesignale (I/O) und/oder Strom- oder Massesignale, die dem Betrieb der Logik, I/O und Speicherchiplets zugeordnet sind, weiterzuleiten.
In manchen Ausführungsformen ist das Substrat 1180 ein Substrat auf Basis von Epoxidlaminat. Das Substrat 1180 kann in anderen Ausführungsformen auch andere geeignete Arten von Substraten enthalten. Die Package-Baugruppe 1190 kann über eine Package-Verbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Package-Verbindung 1183 kann mit einer Fläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie etwa eine Hauptplatine, andere Chipsätze oder ein Mehrchipmodul, zu leiten.
In manchen Ausführungsformen können eine Logik oder ein I/O-Chiplet 1174 und ein Speicherchiplet 1175 elektrisch über eine Brücke 1187 gekoppelt werden, die dafür ausgelegt ist, elektrische Signale zwischen der Logik oder dem I/O-Chiplet 1174 und einem Speicherchiplet 1175 zu leiten. Die Brücke 1187 kann eine dichte Verbindungsstruktur sein, die einen Weg für elektrische Signale bereitstellt. Die Brücke 1187 kann ein Brückensubstrat enthalten, 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 1174 oder dem I/O-Chiplet 1174 und einem Speicherchiplet 1175 bereitzustellen. Die Brücke 1187 kann auch als eine Siliziumbrücke oder eine Verbindungsbrücke bezeichnet werden. Die Brücke 1187 ist in manchen Ausführungsformen beispielsweise eine Embedded-Multi-Die-Interconnect Bridge (EMIB). In manchen 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 I/O 1191, Cache-Speicher 1192 und andere Hardwarelogik 1193 enthalten. In dem Substrat 1180 kann ein Fabric 1185 eingebettet sein, um Kommunikation zwischen den verschiedenen Logikchiplets und der Logik 1191, 1193 in dem Substrat 1180 zu ermöglichen. In einer Ausführungsform können die I/O 1191, Fabric 1185, Cache, Brücke und andere Hardwarelogik 1193 in einen Basis-Die integriert sein, der auf dem Substrat 1180 geschichtet ist.
In verschiedenen Ausführungsformen kann eine Package-Baugruppe 1190 eine kleinere oder größere Anzahl an Komponenten und Chiplets enthalten, die untereinander durch ein Fabric 1185 oder eine oder mehrere Brücken 1187 verbunden sind. Die Chiplets in der Package-Baugruppe 1190 können in einer 3D- oder 2,5D-Anordnung angeordnet sein. Im Allgemeinen können die Brückenstrukturen 1187 genutzt werden, um eine Punkt-zu-Punkt-Verbindung zwischen, beispielsweise, Logik oder I/O-Chiplets und Speicherchiplets zu ermöglichen. Das Fabric 1185 kann zum Verbinden der verschiedenen Logik- und/oder I/O-Chiplets (z.B. Chiplets 1172, 1174, 1191, 1193) mit anderer Logik und/oder I/O-Chiplets verwendet werden. In einer Ausführungsform kann der Cache-Speicher 1192 in dem Substrat als ein globaler Cache für die Package-Baugruppe 1190, Teil eines verteilten globalen Cache oder als ein dedizierter Cache für das Fabric 1185 dienen.
11D veranschaulicht eine Package-Baugruppe 1194, die gemäß einer Ausführungsform austauschbare Chiplets 1195 enthält. Die austauschbaren Chiplets 1195 können in standardisierte Steckplätze auf einem oder mehreren Basischiplets 1196, 1198 montiert werden. Die Basischiplets 1196, 1198 können über eine Brückenverbindung 1197 gekoppelt werden, die den anderen hierin beschriebenen Brückenverbindungen ähnlich sein kann, und sie kann beispielsweise eine EMIB sein. Speicherchiplets können auch mit Logik- oder I/O-Chiplets über eine Brückenverbindung verbunden werden. I/O- und Logikchiplets können über ein Verbindungs-Fabric kommunizieren. Die Basischiplets können jeweils einen oder mehrere Steckplätze in einem standardisierten Format für eines von Logik oder I/O oder Speicher/Cache unterstützen.
In einer Ausführungsform können SRAM und Stromversorgungsschaltungen in einem oder mehreren der Basischiplets 1196, 1198, die unter Verwendung einer anderen Prozesstechnologie im Vergleich zu den austauschbaren Chiplets 1195, die auf den Basischiplets gestapelt werden, gefertigt werden, hergestellt werden. Die Basischiplets 1196, 1198 können unter Verwendung einer größeren Prozesstechnologie gefertigt werden, während die austauschbaren Chiplets unter Verwendung einer kleineren Prozesstechnologie hergestellt werden können. Ein oder mehrere der austauschbaren Chiplets 1195 können Speicherchiplets (z.B. DRAM) sein. Für die Package-Baugruppe 1194 können basierend auf der Leistung und/oder der für das Produkt, das die Package-Baugruppe 1194 nutzt, vorgesehene Performance unterschiedliche Speicherdichten ausgewählt werden. Zusätzlich können Logikchiplets mit einer unterschiedlichen Anzahl von Typen funktionaler Einheiten zum Zeitpunkt der Montage basierend auf der Leistung und/oder für das Produkt vorgesehenen Performance ausgewählt werden. Darüber hinaus können Chiplets, die IP-Logik-Kerne unterschiedlicher Typen enthalten, in die austauschbaren Chiplet-Steckplätze eingesetzt werden, was Hybridprozessordesigns ermöglicht, die unterschiedliche Technologie-IP-Blöcke mischen und anpassen können.
Beispielhafte integrierte System-auf-Chip-Schaltung
12-13 veranschaulichen beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden können, gemäß verschiedener hierin beschriebener Ausführungsformen. Zusätzlich zu dem, was veranschaulicht ist, können auch andere Logik und Schaltungen enthalten sein, einschließlich zusätzlicher Grafikprozessoren/-kerne, Peripherieschnittstellen-Controller oder Uni versal prozessorkerne.
12 ist ein Blockdiagramm, das eine beispielhafte integrierte System-on-Chip-Schaltung 1200 veranschaulicht, die unter Verwendung von einem oder mehreren IP-Kernen gefertigt werden kann, gemäß einer Ausführungsform. Die beispielhafte integrierte Schaltung 1200 enthält einen oder mehrere Anwendungsprozessor(en) 1205 (z.B. CPUs), mindestens einen Grafikprozessor 1210 und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 enthalten, die alle ein modularer IP-Kern aus den gleichen oder mehreren unterschiedlichen Designeinrichtungen sein können. Integrierte Schaltung 1200 enthält Peripherie- oder Bus-Logik, einschließlich eines USB-Controllers 1225, UART-Controllers 1230, einen SPI/SDIO-Controller 1235 und einen I2S/I2C-Controller 1240. Zusätzlich kann die integrierte Schaltung eine Anzeigevorrichtung 1245 enthalten, die mit einem oder mehreren von einem High-Definition Multimedia Interface (HDMI) Controller 1250 und einer Mobile Industry Processor Interface (MIPI) Anzeigeschnittstelle 1255 gekoppelt ist. Speicher kann durch ein Flash-Speicher-Subsystem 1260 bereitgestellt werden, einschließlich eines Flash-Speichers und eines Flash-Speicher-Controllers. Die Speicherschnittstelle kann über einen Speicher-Controller 1265 zum Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt werden. Manche integrierte Schaltungen enthalten zusätzlich eine eingebettete Sicherheits-Engine 1270.
13-14 sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC veranschaulichen, gemäß hierin beschriebener Ausführungsformen. 13 veranschaulicht einen beispielhaften Grafikprozessor 1310 einer integrierten System-on-Chip-Schaltung, die unter Verwendung von einem oder mehreren IP-Kernen gefertigt werden kann, gemäß einer Ausführungsform. 13B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 1340 einer integrierten System-on-Chip-Schaltung, die unter Verwendung von einem oder mehreren IP-Kernen gefertigt werden kann, gemäß einer Ausführungsform. Grafikprozessor 1310 in 13 ist ein Beispiel für einen Grafikprozessorkern mit niedrigem Stromverbrauch. Grafikprozessor 1340 in 13B ist ein Beispiel für einen Grafikprozessorkern mit höherer Leistung. Jeder der Grafikprozessoren 1310, 1340 kann eine Variante des Grafikprozessors 1210 in 12 sein.
Wie in 13 gezeigt, enthält Grafikprozessor 1310 einen Vertexprozessor 1305 und einen oder mehrere Fragmentprozessor(en) 1315A-1315N (z.B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N). Grafikprozessor 1310 kann verschiedene Shader-Programme über separate Logik derart ausführen, dass der Vertexprozessor 1305 optimiert wird, Operationen für Vertex-Shader-Programme auszuführen, während der eine oder die mehreren Fragmentprozessor(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 bzw. die Fragmentprozessor(en) 1315A-1315N verwenden die Primitiven und Vertexdate, die von dem Vertexprozessor 1305 erzeugt wurden, um einen Framebuffer zu produzieren, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform ist bzw. sind der bzw. die Fragmentprozessor(en) 1315A-1315N optimiert, um Fragment-Shader-Programme, wie in der OpenGL-API bereitgestellt, auszuführen, die verwendet werden können, um ähnliche Operationen wie ein Pixel-Shader-Programm, wie durch die Direct 3D API bereitgestellt, durchzuführen.
Grafikprozessor 1310 enthält zusätzlich eine oder mehrere Speicherverwaltungseinheiten (Memory Management Units; MMUs) 1320A-1320B, Cache(s) 1325A-1325B und Schaltungsverbindung(en) 1330A-1330B. Die eine oder die mehreren MMU(s) 1320A-1320B ermöglichen virtuell-zu-physisches Adressmapping für den Grafikprozessor 1310, einschließlich des Vertexprozessors 1305 und/oder Fragmentprozessor(en) 1315A-1315N, die Vertex- oder Bild-/Texturdaten, die in dem Speicher gespeichert sind, zusätzlich zu Vertex- oder Bild-/Texturdaten, die in dem einen oder den mehreren Cache(s) 1325A-1325B gespeichert sind, referenzieren können. In einer Ausführungsform kann bzw. können die eine oder die mehreren MMU(s) 1320A-1320B mit anderen MMUs in dem System synchronisiert werden, einschließlich einer oder mehreren MMUs, die dem einen oder den mehreren Anwendungsprozessor(en) 1205, Bildprozessor 1215 und/oder Videoprozessor 1220 in 12 derart zugeordnet sind, dass jeder Prozessor 1205-1220 an einem gemeinsamem oder einheitlichem virtuellen Speichersystem partizipieren kann. Die eine oder die mehreren Schaltungsverbindung(en) 1330A-1330B befähigen gemäß Ausführungsformen Grafikprozessor 1310 eine Schnittstelle mit anderen IP-Kernen in dem SoC, entweder über einen internen Bus des SoC oder über eine direkte Verbindung, zu bilden.
Wie in 14 gezeigt, enthält Grafikprozessor 1340 die eine oder die mehreren MMU(s) 1320A-1320B, Cache(s) 1325A-1325B und Schaltungsverbindung(en) 1330A-1330B des Grafikprozessors 1310 in 13A. Grafikprozessor 1340 enthält einen oder mehrere Shader-Kern(e) 1355A-1355N (z.B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), der bzw. die eine einheitliche Shader-Kern-Architektur ermöglichen, in der ein einzelner Kern oder Typ oder Kern alle Arten programmierbarer Shade-Codes ausführen kann, einschließlich Shader-Programm-Code zum Implementieren von Vertex-Shadern, Fragment-Shadern und/oder Rechen-Shadern. Die genaue Anzahl der vorhandenen Shader-Kerne kann bei verschiedenen Ausführungsformen und Implementierungen variieren. Zusätzlich enthält Grafikprozessor 1340 einen Inter-Kern-Taskmanager 1345, der als ein Thread-Dispatcher zum Versenden von Ausführungs-Threads an einen oder mehrere Shader-Kerne 1355A-1355N wirkt und eine Kacheleinheit 1358 zum Beschleunigen von Kacheloperationen für kachelbasiertes Rendering, bei dem Renderingoperationen für eine Szene in Bildraum unterteilt werden, beispielsweise um lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder um Verwendung interner Caches zu optimieren.
Wie vorstehend angegeben, wird zur Quantisierung der Vertexkomponente in dem vorzeichenbehafteten NV-Bit-Raum der Exponent jeder Vertexkomponente von dem globalen Exponent für diese Achse subtrahiert. Der Komponentenwert wird dann um diese Differenz nach unten verschoben. Dadurch kann natürlich eine gewisse Genauigkeit im unteren Bereich der Komponente verloren gehen. Zum Erfassen dieses Verlusts wird ein AABB durch Abrunden des Min-Werts und Aufrunden des Max-Werts nach dieser Verschiebung erzeugt. Der Einfachheit halber wird ein Vertex selbst dann zu einer Einheit AABB quantisiert, wenn während der Quantisierung kein Fehler auftritt.
RA YTRACING-ARCHITEKTUR
In einer Implementierung enthält der Grafikprozessor Schaltungsanordnungen und/oder Programmcode zum Durchführen von Echtzeit-Raytracing. In manchen Ausführungsformen ist in dem Grafikprozessor zum Durchführen der diversen hierin beschriebenen Raytracing-Operationen, einschließlich Strahltraversierungs- und/oder Strahlüberschneidungsoperationen, ein dedizierter Satz von Raytracing-Kernen enthalten. Zusätzlich zu den Raytracing-Kernen enthält eine Ausführungsform mehrere Sätze von Grafikverarbeitungskernen zum Durchführen programmierbarer Shading-Operationen und mehrere Sätze von Tensor-Kernen zum Durchführen von Matrixoperationen an Tensor-Daten.
15 veranschaulicht einen beispielhaften Abschnitt solcher einer Grafikverarbeitungseinheit (GPU) 1505, die dedizierte Sätze von Grafikverarbeitungsressourcen enthält, die in Mehrkerngruppen 1500A-N angeordnet sind. Während nur die Einzelheiten zu einer einzelnen Mehrkerngruppe 1500A bereitgestellt werden, ist zu würdigen, dass die anderen Mehrkerngruppen 1500B-N mit den gleichen oder ähnlichen Sätzen von grafikverarbeitenden Ressourcen ausgestattet sein können.
Wie veranschaulicht, kann Mehrkerngruppe 1500A einen Satz von Grafikkernen 1530, einen Satz von Tensor-Kernen 1540 und einen Satz von Raytracing-Kernen 1550 enthalten. Ein Scheduler/Dispatcher 1510 plant und versendet die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 1530, 1540, 1550. Ein Satz von Registerdateien 1520 speichert Operandenwerte, die von den Kernen 1530, 1540, 1550 bei Ausführen der Grafik-Threads verwendet werden. Diese können beispielsweise Integer-Register zum Speichern von Integer-Werten, Gleitkommaregister zum Speichern von Gleitkommawerten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern gepackter Datenelemente (Integer- und/oder Gleitkommadatenelemente) und Kachel-Register zum Speichern von Tensor-/Matrixwerten enthalten. In einer Ausführungsform sind die Kachel-Register als kombinierte Sätze von Vektorregistern implementiert.
Ein oder mehrere Level 1 (L1) Caches und Textureinheiten 1560 speichern Grafikdaten, wie etwa Texturdaten, Vertexdaten, Pixeldaten, Strahldaten, Bounding-Volume-Daten usw. lokal in jeder Mehrkerngruppe 1500A. Ein Level 2 (L2) Cache 1580, der von allen oder einer Teilmenge der Mehrkerngruppen 1500AN gemeinsam genutzt wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafik-Threads. Wie veranschaulicht, kann der L2-Cache 1580 von mehreren Mehrkerngurppen 1500A-N gemeinsam genutzt werden. Ein oder mehrere Speicher-Controller 1570 koppeln die GPU 1505 mit einem Speicher 1598, der ein Systemspeicher (z.B. DRAM) und/oder ein dedizierter Grafikspeicher (z.B. GDDR6-Speicher) sein kann.
Eingabe-/Ausgabe-Schaltungsanordnung (I/O) 1595 koppelt die GPU 1505 mit einer oder mehreren I/O-Vorrichtungen 1595, wie etwa Digitalsignalprozessoren (DSPs), Netzwerk-Controllern oder Benutzereingabegeräte. Zum Koppeln der I/O-Vorrichtungen 1590 mit der GPU 1505 und Speicher 1598 kann eine On-Chip-Verbindung verwendet werden. Ein oder mehrere I/O-Speicherverwaltungseinheiten (IO Memory Management Units; IOMMUs) 1570 der I/O-Schaltungsanordnung 1595 koppeln die I/O-Vorrichtungen 1590 direkt mit dem Systemspeicher 1598. In einer Ausführungsform verwaltet die IOMMU 1570 mehrere Sätze von Seitentabellen zum Abbilden virtueller Adressen zu physischen Adressen im Systemspeicher 1598. In dieser Ausführungsform können sich die I/O-Vorrichtungen 1590, CPU(s) 1599 und GPU(s) 1505 den gleichen virtuellen Adressraum teilen.
In einer Implementierung unterstützt die IOMMU 1570 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen verwalten, um virtuelle Gast-/Grafikadressen zu physischen Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen zum Abbilden der physischen Gast-/Grafikadressen zu physischen System-/Host-Adressen (z.B. innerhalb des Systemspeichers 1598). Die Basisadressen des ersten und des zweiten Satzes von Seitentabellen kann in Steuerregistern gespeichert werden und bei einem Kontextwechsel getauscht werden (z.B. so dass der neue Kontext mit Zugang zu dem relevanten Satz der Seitentabellen bereitgestellt wird). Obwohl in 15 nicht veranschaulicht, kann jeder der Kerne 1530, 1540, 1550 und/oder Mehrkerngruppen 1500A-N Translation Lookaside Buffer (TLBs) enthalten, um virtuelle Gast- zu physischen Gast-Übersetzungen, physische Gast- zu physischen Host-Übersetzungen und virtuelle Gast- zu physischen Host-Übersetzungen zwischenzuspeichern.
In einer Ausführungsform sind die CPUs 1599, GPUs 1505 und I/O-Vorrichtungen 1590 auf einem einzelnen Halbleiterchip und/oder Chip-Package integriert. Der veranschaulichte Speicher 1598 kann auf dem gleichen Chip integriert sein oder er kann mit den Speicher-Controllern 1570 über eine Off-Chip-Schnittstelle gekoppelt sein. In einer Implementierung umfasst der Speicher 1598 GDDR6-Speicher, der den gleichen virtuellen Adressraum teilt, wie andere physische Speicher auf Systemebene, obwohl das zugrundeliegende Prinzip der Erfindung nicht auf diese spezifische Implementierung beschränkt ist.
In einer Ausführungsform enthalten Tensor-Kerne 1540 eine Mehrzahl von Ausführungseinheiten, die spezifisch dafür entworfen sind, Matrixoperationen durchzuführen, welche die fundamentale Rechenoperation sind, die zum Durchführen von Deep Learning Operationen verwendet wird. Für das Training eines neuralen Netzwerks und Inferenzierung können beispielsweise simultane Matrixmultiplikationsoperationen verwendet werden. Die Tensor-Kerne 1540 können Matrixverarbeitung unter Verwendung einer Vielzahl von Operandenpräzisionen durchführen, einschließlich Gleitkomma mit einfacher Genauigkeit (z.B. 32 Bit), Gleitkomma mit halber Genauigkeit (z. B. 16 Bit), Ganzzahlwörter (16 Bit), Bytes (8 Bit) und Halbbytes (4 Bit). In einer Ausführungsform extrahiert eine Implementierung eines neuralen Netzwerks Merkmale jeder gerenderten Szene und kombiniert dabei potenziell Details aus mehreren Frames, um ein Endbild in hoher Qualität zu konstruieren.
In Deep-Learning-Implementierungen kann Parallelmatrixmultiplikationsarbeit für Ausführung auf den Tensor-Kernen 1540 geplant werden. Das Training neuraler Netzwerke erfordert insbesondere eine erhebliche Anzahl von Matrixpunktproduktoperationen. Um eine Innenproduktformulierung einer N × N × N Matrix zu multiplizieren, können die Tensor-Kerne 1540 mindestens N Punktproduktverarbeitungselemente enthalten. Bevor das Matrixmultiplizieren beginnt, wird eine ganze Matrix in Kachel-Register geladen und mindestens eine Spalte einer zweiten Matrix wird jeden Zyklus für N Zyklen geladen. In jedem Zyklus gibt es N Punktprodukte, die verarbeitet werden.
Matrixelemente können mit verschiedenen Präzisionen je nach der bestimmten Implementierung gespeichert werden, einschließlich 16-Bit-Wörtern, 8-Bit-Bytes (z.B. INT8) und 4-Bit-Halbbytes (z.B. INT4). Für die Tensor-Kerne 1540 können verschiedene Präzisionsmodi festgelegt werden, um sicherzustellen, dass die effizienteste Präzision für unterschiedliche Arbeitslasten verwendet wird (z.B. Inferenzierung von Arbeitslasten, die Quantisierung zu Bytes und Halbbytes tolerieren können).
In einer Ausführungsform beschleunigen die Raytracingkerne 1550 Raytracingoperationen für Echtzeit-Raytracing- und Nicht-Echtzeit-Raytracing-Implementierungen. Die Raytracing-Kerne 1550 enthalten insbesondere eine Strahltraversierungs-/Überschneidungsschaltungsanordnung zum Durchführen von Strahltraversierung unter Verwendung von Bounding-Volume-Hierarchien (BVHs) und Identifizieren von Überschneidungen zwischen Strahlen und Primitiven, die in den BVH-Volumen eingeschlossen sind. Die Raytracing-Kerne 1550 können außerdem eine Schaltungsanordnung zum Durchführen von Tiefentests und Culling enthalten (z.B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung). In einer Implementierung führen die Raytracing-Kerne 1550 Traversierungs- und Überschneidungsoperationen in Zusammenarbeit mit den hierin beschriebenen Bildentrauschungstechniken durch, von denen zumindest ein Teil auf den Tensor-Kernen 1540 ausgeführt werden kann. In einer Ausführungsform implementieren die Tensor-Kerne 1540 beispielsweise ein neurales Deep Learning Netzwerk, um Entrauschen von Frames durchzuführen, die von den Raytracing-Kernen 1550 erzeugt wurden. Die CPU(s) 1599, Grafikkerne 1530 und/oder Raytracing-Kerne 1550 können jedoch auch einen Teil oder alle der Entrausch- und/oder Deep-Learning-Algorithmen implementieren.
Darüber hinaus kann, wie vorstehend beschrieben, ein verteilter Ansatz zum Entrauschen eingesetzt werden, bei dem sich die GPU 1505 in einer Rechenvorrichtung befindet, die mit anderen Rechenvorrichtungen über ein Netzwerk oder eine Hochgeschwindigkeitsverbindung gekoppelt ist. In dieser Ausführungsform teilen die miteinander verbundenen Rechenvorrichtungen neurales Netzwerk Lern-/Trainingdaten, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, Entrauschen für verschiedene Arten von Bild-Frames und/oder unterschiedliche Grafikanwendungen durchzuführen.
In einer Ausführungsform verarbeiten die Raytracing-Kerne 1550 alle BVH-Traversierungen und strahlprimitiven Überschneidungen, wodurch die Grafikkerne 1530 nicht mit Tausenden von Anweisungen pro Strahl überlastet werden. In einer Ausführungsform enthält jeder Raytracing-Kern 1550 einen ersten Satz spezialisierter Schaltungsanordnungen zum Durchführen von Bounding-Box-Tests (z.B. für Traversierungsoperationen) und einen zweiten Satz spezialisierter Schaltungsanordnung zum Durchführen von Strahl-Dreieck-Überschneidungstests (z.B. sich überschneidende Strahlen, die traversiert wurden). Somit kann die Mehrkerngruppe 1500A in einer Ausführungsform einfach eine Strahlsonde starten und die Raytracing-Kerne 1550 führen unabhängig Strahltraversierung und Überschneidung durch und geben Trefferdaten (z.B. ein Treffer, kein Treffer, mehrere Treffer usw.) an den Thread-Kontext zurück. Die anderen Kerne 1530, 1540 werden freigegeben, um andere Grafik- und Rechenarbeit durchzuführen, während die Raytracing-Kerne 1550 die Traversierungs- und Überschneidungsoperationen durchführen.
In einer Ausführungsform enthält jeder Raytracing-Kern 1550 eine Traversierungseinheit zum Durchführen von BVH-Testoperationen und eine Überschneidungseinheit, die strahlprimitive Überschneidungstests durchführt. Die Überschneidungseinheit generiert eine „Treffer“, „kein Treffer“ oder „mehrere Treffer“ Reaktion, die sie an den entsprechenden Thread bereitstellt. Während der Traversierungs- und Überschneidungsoperationen werden die Ausführungsressourcen der anderen Kerne (z.B. Grafikkerne 1530 und Tensor-Kerne 1540) freigegeben, um andere Formen von Grafikarbeit durchzuführen.
In einer bestimmten, unten beschriebenen Ausführungsform wird ein Hybrid-Rasterungs-/Raytracing-Ansatz verwendet, bei dem Arbeit zwischen den Grafikkernen 1530 und Raytracing-Kernen 1550 verteilt wird.
In einer Ausführungsform enthalten die Raytracing-Kerne 1550 (und/oder andere Kerne 1530, 1540) Hardwareunterstützung für einen Raytracing-Anweisungssatz, wie etwa Microsoft DirectX Ray Tracing (DXR), welches einen DispatchRays-Befehl enthält, sowie Strahlgenerierung, Closest-Hit, Any-Hit und Miss-Shader und Texturen für jedes Objekt. Eine andere Raytracing-Plattform, die von den Raytracing-Kernen 1550, Grafikkernen 1530 und Tensor-Kernen 1540 unterstützt werden kann, ist Vulkan 1.1.85. Es ist jedoch zu beachten, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf eine bestimmte Raytracing-ISA beschränkt sind.
Im Allgemeinen können die verschiedenen Kerne 1550, 1540, 1530 einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen zur Strahlerzeugung, Closest-Hit, Any-Hit, strahlprimitive Überschneidung, perprimitive und hierarchische Bounding-Box-Konstruktion, Miss, Visit und Ausnahmen enthält. Eine Ausführungsform umfasst insbesondere Raytracing-Anweisungen zum Durchführen der folgenden Funktionen:
Strahlerzeugung - Strahlerzeugungsanweisungen können für jeden Pixel, jedes Sample oder andere benutzerdefinierte Arbeitszuweisungen ausgeführt werden.
Closest Hit - Eine Closest-Hit-Anweisung kann ausgeführt werden, um den am nächsten gelegenen Überschneidungspunkt eines Strahls mit Primitiven in einer Szene zu lokalisieren.
Any Hit - Eine Any-Hit-Anweisung identifiziert mehrere Überschneidungen zwischen einem Strahl und Primitiven in einer Szene, um potenziell einen neuen am nächsten liegenden Überschneidungspunkt zu identifizieren.
Überschneidung - Eine Überschneidungsanweisung führt einen strahlprimitiven Überschneidungstest durch und gibt ein Ergebnis aus.
Per-Primitiv Bounding-Box-Konstruktion - Diese Anweisung errichtet eine Bounding-Box um eine gegebene Primitive oder Gruppe von Primitiven (z.B. beim Bauen einer neuen BVH oder anderen Beschleunigungsdatenstruktur).
Miss - Gibt an, dass ein Strahl die gesamte Geometrie in einer Szene oder einen bestimmten Bereich einer Szene verfehlt.
Visit - Gibt die Child-Volumen an, die ein Strahl durchläuft.
Ausnahmen - Beinhaltet verschiedene Arten von Ausnahmen-Handlern (z.B. für diverse Fehlerbedingungen aufgerufen).
VERLUSTBEHAFTETE UND VERLUSTFREIE PAKETKOMPRIMIERUNG IN EINEM VERTEILTEN RAYTRACING-SYSTEM
In einer Ausführungsform sind Raytracing-Operationen über mehrere Rechenknoten, die über ein Netzwerk miteinander gekoppelt sind, verteilt. 16 veranschaulicht beispielsweise ein Raytracing-Cluster 1600, das mehrere Raytracing-Knoten 1610-1613 zum Durchführen paralleler Raytracing-Operationen umfasst, wobei die Ergebnisse potenziell auf einem der Knoten kombiniert werden. In der veranschaulichten Architektur sind die Raytracing-Knoten 1610-1613 über einen Gateway kommunikativ mit einer Client-seitigen Raytracing-Anwendung 1630 gekoppelt.
Eine der Schwierigkeiten bei einer verteilten Architektur ist die große Menge an packetierten Daten, die zwischen jedem der Raytracing-Knoten 1610-1613 übertragen werden muss. In einer Ausführungsform werden sowohl verlustfreie Komprimierungstechniken als auch verlustbehaftete Komprimierungstechniken zum Reduzieren der Daten, die zwischen den Raytracing-Knoten 1610-1613 übertragen werden, verwendet.
Zum Implementieren verlustfreier Komprimierung werden, anstatt des Sendens von Paketen, die mit den Ergebnissen bestimmter Arten von Operationen gefüllt sind, Daten oder Befehle gesendet, die es dem empfangenden Knoten erlauben, die Ergebnisse zu rekonstruieren. Zum Beispiel müssen stochastisch abgetastete Flächenlicht- und Umgebungsokklusions- (Ambient Occlusion; AO) Operationen nicht zwangsläufig Richtungen sein. Dementsprechend sendet ein übertragender Knoten in einer Ausführungsform einfach einen zufälligen Seed, der dann von dem empfangenden Knoten verwendet wird, um Zufalls-Sampling durchzuführen. Wenn eine Szene beispielsweise über Knoten 1610-1612 verteilt ist, müssen zum Abtasten von Licht 1 an Punkten p1-p3 nur die Licht-ID und Ursprünge an Knoten 1610-1612 gesendet werden. Jeder der Knoten kann dann das Licht unabhängig stochastisch abtasten. In einer Ausführungsform wird der zufällige Seed von dem empfangenden Knoten erzeugt. Auf ähnliche Weise kann für primäre Strahlen-Hit-Punkte Umgebungsokklusion (AO) und weiche Schattenabtastung an Knoten 1610-1612 ohne Abwarten auf die Originalpunkte für sukzessive Frames berechnet werden. Zusätzlich können, wenn bekannt ist, dass ein Strahlensatz zu der gleichen Punktlichtquelle läuft, Anweisungen gesendet werden, die die Lichtquelle dem empfangenden Knoten gegenüber identifizieren, der sie dann auf den Strahlensatz anwendet. In einem anderen Beispiel kann, wenn an einem einzelnen Punkt N Umgebungsokklusionsstrahlen übertragen werden, ein Befehl zum Erzeugen von N Samplen von diesem Punkt gesendet werden.
Für verlustbehaftete Komprimierung können verschiedene zusätzliche Techniken verwendet werden. In einer Ausführungsform kann beispielsweise ein Quantisierungsfaktor eingesetzt werden, um alle Koordinatenwerten, die BVH, Primitiven und Strahlen zugeordnet sind, zu quantisieren. Darüber hinaus können 32-Bit-Gleitkommawerte, die für Daten, wie etwa BVH-Knoten und Primitive verwendet werden, in 8-Bit-Ganzzahlwerte gewandelt werden. In einer bestimmten Implementierung werden die Grenzen von Strahlpaketen in voller Präzision gespeichert, aber individuelle Strahlpunkte P1-P3 werden als indexierte Offsets zu den Grenzen übertragen. Auf ähnliche Weise können mehrere lokale Koordinatensystem generiert werden, die 8-Bit-Ganzzahlwerte als lokale Koordinaten verwenden. Die Position des Ursprungs jedes dieser lokalen Koordinatensysteme kann unter Verwendung der Vollpräzisionswerte (z.B. 32-Bit-Gleitkomma) kodiert werden, was effektiv die globalen und lokalen Koordinatensystem miteinander verbindet.
Das Folgende ist ein Beispiel für verlustfreie Komprimierung, die in einer Ausführungsform der Erfindung eingesetzt wird. Ein Beispiel für ein Strahldatenformat, das intern in einem Raytracing-Programm verwendet wird, lautet wie folgt:

      struct Ray
      {
         uint32 pixId;
         uint32 materialID;
         uint32 instanceID;
         uint64 primitiveID;
         uint32 geometrylD;
         uint32 lightID;
         float origin[3];
         float direction[3];
         float t0;
         float t;
         float time;
         float normal[3]; //wird für Geometrieüberschneidungen verwendet
         float u;
         float v;
         float wavelength;
         float phase; //Interferometrie
         float refractedOffset; //Schlieren-esque
         float amplitude;
         float weight;
          };

Anstatt eines Sendens der Rohdaten für jeden einzelnen erzeugten Knoten können diese Daten durch Gruppierung von Werten und durch Erzeugen implizierter Strahlen unter Verwendung gültiger Metadaten, sofern möglich, komprimiert werden.

Bündeln und Gruppieren von Strahlendaten

Eine Ausführungsform verwendet Flags für gemeinsame Daten oder Masken mit Modifikatoren.

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

Zum Beispiel:

RayPacket.rays = ray_1 to ray_256

Alle Ursprünge werden geteilt

Alle Strahldaten werden gepackt und nur ein einziger Ursprung wird für alle Strahlen gespeichert. RayPacket.flags wird festgelegt für RAYPACKET_COMMON ORIGIN. Wenn RayPacket bei Empfang entpackt wird, werden die Ursprünge aus dem einzelnen Ursprungswert gefüllt. Ursprünge werden nur von manchen Strahlen geteilt

Alle Strahldaten, mit Ausnahme von Strahlen, die Ursprünge teilen, werden gepackt. Für jede Gruppe eindeutig gemeinsamer Ursprünge wird ein Operator gepackt, der die Operation (gemeinsame Ursprünge) identifiziert, den Ursprung speichert und maskiert, welche Strahlen die Informationen teilen. Solch eine Operation kann über gemeinsame Werte zwischen den Knoten erfolgen, wie etwa Material-IDs, Primitiv-IDs, Ursprung, Richtung, Normale usw.

      struct RayOperation
      { 

         uint8 operationID;
         void* value; 
         uint64 mask;
      }

Senden implizierter Strahlen

Strahldaten lassen sich häufig an dem empfangenden Ende mit minimalen Metainformationen, die zu deren Erzeugung verwendet wurden, ableiten. Ein sehr übliches Verfahren ist das Erzeugen mehrerer Sekundärstrahlen zum stochastischen Abtasten eines Bereichs. Anstatt, dass der Sender einen Sekundärstrahl erzeugt, ihn sendet und der Empfänger daran arbeitet, kann der Sender einen Befehl senden, dass der Strahl mit den abhängigen Informationen erzeugt werden muss und der Strahl wird dann an dem empfangenden Ende erzeugt. In dem Fall, in dem der Strahl zunächst von dem Sender erzeugt werden muss, um zu bestimmen, an welchen Empfänger er zu senden ist, wird der Strahl erzeugt und der Zufalls-Seed kann gesendet werden, um den exakt gleichen Strahl zu erzeugen.

Zum Abtasten eines Trefferpunktes mit 64 Schattenstrahlen, die eine Bereichslichtquelle abtasten, überschneiden beispielsweise alle 64 Strahlen Bereiche aus der gleichen Berechnung N4. Es wird ein RayPacket mit gemeinsamem Ursprung und Normalen erzeugt. Wenn man möchte, könnten auch mehr Daten an den Empfänger gesendet werden, um den resultierenden Pixelbeitrag zu schattieren. Für dieses Beispiel wollen wir aber davon ausgehen, dass wir nur zurückmelden möchten, ob ein Strahl andere Knotendaten trifft. Für eine erzeuge Schattenstrahloperation wird eine RayOperation erzeugt und dem Wert der abzutastenden lightID und dem Zufallszahl-Seed zugewiesen. Wenn N4 das Strahlenpaket empfängt, erzeugt er die vollständig gefüllten Strahldaten durch Ausfüllen der gemeinsamen Ursprungsdaten zu allen Strahlen und der Einstellung der Richtung basierend auf der lightID, die stochastisch mit dem Zufallszahl-Seed abgetastet wurde, um die gleichen Strahlen zu erzeugen, die der ursprüngliche Sender erzeugt hatte. Bei Zurückführen der Ergebnisse müssen nur Binärergebnisse für jeden Strahl zurückgeführt werden, die durch eine Maske über den Strahlen übergeben werden können.

Senden der ursprünglichen 64 Strahlen in diesem Beispiel hätte 104 Bytes * 64 Strahlen = 6656 Bytes in Anspruch genommen. Wenn die zurückkehrenden Strahlen ebenfalls in ihrer Rohform gesendet wurden, dann wird dies ebenfalls auf 13312 Bytes verdoppelt. Bei verlustfreier Komprimierung, bei der nur der gemeinsame Strahlursprung, die Normale und die Strahlerzeugungsoperation mit Seed und ID gesendet werden, werden nur 29 Bytes gesendet, wobei 8 Bytes für die „was intersected“-Maske zurückgeführt werden. Dies resultiert in einer Datenkomprimierungsrate von ~360:1, die über das Netzwerk gesendet werden muss. Dies beinhaltet kein Overhead zum Verarbeiten der Nachricht an sich, was auf irgendeine Weise identifiziert werden müsste. Das wird aber der Implementierung überlassen. Für Neuberechnung von Strahlursprung und Richtungen aus der pixelID für Primärstrahlen, Neuberechnung von pixelIDs basierend auf den Bereichen in dem Strahlpaket und viele andere mögliche Implementierungen für eine Neuberechnung von Werten können andere Operationen durchgeführt werden. Ähnliche Operationen können für jedwede gesendeten einzelne oder Gruppen von Strahlen verwendet werden, einschließlich Schatten, Reflexionen, Refraktion, Umgebungsokklusion, Überschneidungen, Volumenüberschneidungen, Shading, abgeprallte Reflexionen bei der Pfadverfolgung usw.

17 veranschaulicht zusätzliche Einzelheiten für zwei Raytracing-Knoten 1710-1711, die Komprimierung und Dekomprimierung von Raytracing-Paketen durchführen. Insbesondere führt Strahlkomprimierungsschaltungsanordnung 1720 in einer Ausführungsform, wenn eine erste Raytracing-Engine 1730 bereit ist, Daten an eine zweite Raytracing-Engine 1731 zu übertragen, verlustbehaftete und/oder verlustfreie Komprimierung der Raytracing-Daten wie hierin beschrieben durch (z.B. Wandeln von 32-Bit-Werten zu 8-Bit-Werten, Ersetzen von Rohdaten durch Anweisungen zum Rekonstruieren von Daten usw.). Die komprimierten Strahlenpakete 1701 werden von Netzwerkschnittstelle 1725 an Netzwerkschnittstelle 1726 über ein lokales Netzwerk (z.B. ein 10Gb/s, 100Gb/s Ethernet-Netzwerk) übertragen. Eine Strahldekomprimierungsschaltungsanordnung dekomprimiert dann gegebenenfalls die Strahlenpakete. Sie kann beispielsweise Befehle zum Rekonstruieren der Raytracing-Daten ausführen (z.B. unter Verwendung eines Zufall-Seeds zum Durchführen von Zufalls-Sampling für Beleuchtungsoperationen). Raytracing-Engine 1731 verwendet die empfangenen Daten dann zur Durchführung von Raytracing-Operationen.

In der umgekehrten Richtung komprimiert Strahlenkomprimierungsschaltungsanordnung 1741 Strahldaten, Netzwerkschnittstelle 1726 überträgt die komprimierten Strahldaten über das Netzwerk (z.B. unter Verwendung der hierin beschriebenen Techniken), Strahlendekomprimierungsschaltung 1740 dekomprimiert, sofern nötig, die Strahldaten und Raytracing-Engine 1730 verwendet die Daten in Raytracing-Operationen. Obwohl in 17 als eine separate Einheit veranschaulicht, kann Strahlendekomprimierungsschaltungsanordnung 1740-1741 jeweils in Raytracing-Engines 1730-1731 integriert sein. Insoweit, als dass die komprimierten Strahldaten Befehle zum Rekonstruieren der Strahldaten umfassen, können diese Befehle beispielsweise durch jede jeweilige Raytracing-Engine 1730-1731 ausgeführt werden.

Wie in 18 veranschaulicht, kann Strahlkomprimierungsschaltungsanordnung 1720 eine Schaltungsanordnung für verlustbehaftete Komprimierung 1801 zum Durchführen der hierin beschriebenen verlustbehafteten Komprimierungstechniken (z.B. Wandeln von 32-Bit-Gleitkommkoordinaten zu 8-Bit-Ganzzahlkoordinaten) und eine Schaltungsanordnung für verlustfreie Komprimierung 1803 zum Durchführen der verlustfreien Komprimierungstechniken (z.B. Übertragen von Befehlen und Daten, um es der Strahldekomprimierungsschaltung 1821 zu ermöglichen, die Daten zu rekonstruieren) enthalten. Strahldekomprimierungsschaltungsanordnung 1721 enthält Schaltungsanordnung für verlustbehaftete Dekomprimierung 1802 und Schaltungsanordnung für verlustfreie Dekomprimierung 1804 zum Durchführen verlustfreier Dekomprimierung.

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

Bei 3900 werden Strahldaten empfangen, die von einem ersten Raytracing-Knoten an einen zweiten Raytracing-Knoten übertragen werden. Bei 3901 führt eine Schaltungsanordnung für verlustbehaftete Komprimierung verlustbehaftete Komprimierung an ersten Raytracing-Daten durch und bei 3902 führt eine Schaltungsanordnung für verlustfreie Komprimierung verlustfreie Komprimierung an zweiten Raytracing-Daten durch. Bei 3903 werden die komprimierten Raytracing-Daten an einen zweiten Raytracing-Knoten übertragen. Bei 3904 führt eine Schaltungsanordnung für verlustbehaftete/verlustfreie Dekomprimierung verlustbehaftete/verlustfreie Dekomprimierung der Raytracing-Daten durch und bei 3905 führt der zweite Raytracing-Knoten Raytracing-Operationen an den dekomprimierten Daten durch.

GRAFIKPROZESSOR MIT HARDWAREBESCHLEUNIGTEM HYBRID-RAYTRACING

Eine Ausführungsform der Erfindung umfasst eine Hybrid-Rendering-Pipeline, die Rasterung an Grafikkernen 1530 und Raytracing-Operationen an den Raytracing-Kernen 1550, Grafikkernen 1530 und/oder CPU 1599 Kernen durchführt. Rasterung und Tiefentests können beispielsweise an den Grafikkernen 1530 anstatt während der primären Strahl-Casting-Stufe durchgeführt werden. Die Raytracing-Kerne 1550 können dann sekundäre Strahlen für Strahlreflexionen, Brechungen und Schatten erzeugen. Darüber hinaus können bestimmte Ausführungsformen bestimmte Bereiche einer Szene auswählen, in denen die Raytracing-Kerne 1550 Raytracing-Operationen (z.B. basierend auf Schwellenwerten für Materialeigenschaften, wie etwa hohe Reflexionsgrade) durchführen, während andere Bereiche der Szene mit Rasterung auf den Grafikkernen 1530 gerendert werden. In einer Ausführungsform wird diese Hybridimplementierung für Echtzeit-Raytracing-Anwendungen verwendet - wobei Latenz ein kritischer Aspekt ist.

Eine Ausführungsform der unten beschriebenen Strahltraversierungs-Architektur führt programmierbares Shading und Steuern von Strahltraversierung unter Verwendung bestehender SIMD- (Single Instruction Multiple Data) und/oder SIMT- (Single Instruction Multiple Thread) Grafikprozessoren durch, während kritische Funktionen, wie etwa BVH-Traversierung und/oder Überschneidungen, unter Verwendung dedizierter Hardware beschleunigt werden. In dieser Ausführungsform wird SIMD-Belegung für inkohärente Pfade durch Neugruppierung gespawnter Shader an spezifischen Punkten während der Traversierung und vor dem Shading verbessert. Dies wird durch Verwendung dedizierter Hardware erzielt, die Shader dynamisch, on-Chip sortiert. Die Rekursion wird durch Splitten einer Funktion in Kontinuitäten verwaltet, die bei Rückführen und Neugruppierung von Kontinuitäten vor Ausführung zur verbesserten SIMD-Belegung ausführen.

Programmierbare Steuerung der Strahlentraversierung/-überschneidung wird durch Zerlegen von Traversierungsfunktionalität in eine innere Traversierung erreicht, die als Festfunktionshardware implementiert sein kann, und eine äußere Traversierung, die auf GPU-Prozessoren ausführt und programmierbare Steuerung durch benutzerdefinierte Traversierungs-Shader ermöglicht. Die Kosten der Übertragung des Traversierungskontexts zwischen Hardware und Software wird durch konservatives Abschneiden des inneren Traversierungszustands während des Übergangs zwischen innerer und äußerer Traversierung reduziert.

Programmierbare Steuerung des Raytracings kann durch die unterschiedlichen Shader-Typen, die in Tabelle A unten aufgeführt sind, ausgedrückt werden. Für jeden Typ kann es mehrere Shader geben. Jedes Material kann beispielsweise einen anderen Hit-Shader haben. TABELLE A

Shader- Typ	Funktionsweise
Primary	Starten von Primärstrahlen
Hit	Abtasten bidirektionaler Reflexionsverteilungsfunktion (Bidirectional Reflectance Distribution Function; BRDF), Starten von Sekundärstrahlen
Any Hit	Berechnen des Transmissionsgrads für alpha-texturierte Geometrien
Miss	Berechnen der Strahlung von einer Lichtquelle
Intersection	Überschneidung benutzerdefinierter Formen
Traversal	Instanzauswahl und -transformation
Callable	Eine Allzweckfunktion

In einer Ausführungsform wird rekursives Raytracing durch eine API-Funktion initiiert, die dem Grafikprozessor befiehlt, einen Satz von Primär-Shadern oder eine Überschneidungsschaltungsanordnung zu starten, der bzw. die Strahlszenenüberschneidungen für Primärstrahlen spawnen kann. Das wiederum spawnt andere Shader, wie etwa Traversal-, Hit-Shader oder Miss-Shader. Ein Shader, der einen Child-Shader spawnt, kann auch einen Rückgabewert von diesem Child-Shader empfangen. Aufrufbare Shader sind Allzweckfunktionen, die direkt von einem anderen Shader gespawnt werden und sie können auch Werte zu dem aufrufendem Shader zurückführen.

19 veranschaulicht eine Ausführungsform einer Grafikverarbeitungsarchitektur, die Shader-Ausführungsschaltungsanordnung 1900 und Festfunktionsschaltungsanordnung 1910 enthält. Das Allzweckausführungshardware-Subsystem enthält mehrere SIMD- (Single Instruction Multiple Data) und/oder SIMT- (Single Instructions Multiple Threads) Kerne/Ausführungseinheiten (Execution Units; EUs) 1901 (d.h. jeder Kern umfasst mehrere Ausführungseinheiten), einen oder mehrere Sampler 1902 und einen Level-1 (L1) Cache 1903 oder eine andere Form lokalen Speichers. Das Festfunktionshardware-Subsystem 1910 enthält Nachrichteneinheit 1904, einen Scheduler 1907, Strahl-BVH-Traversierungs-/Überschneidungsschaltungsanordnung 1905, Sortierschaltungsanordnung 1908 und einen lokalen L1-Cache 1906.

Im Betrieb sendet ein Primär-Dispatcher 1909 einen Satz von Primärstrahlen an den Scheduler 1907, der die Arbeit für die Shader, die auf den SIMD-/SIMT-Kernen/EUs 1901 ausgeführt werden, plant. Die SIMD-Kerne/EUs 1901 können über die vorstehend beschriebenen Raytracing-Kerne 1550 und/oder Grafikkerne 1530 verfügen. Ausführung der Primär-Shader spawnt zusätzlich durchzuführende Arbeit (z.B. zur Ausführung durch einen oder mehrere Child-Shader und/oder Festfunktionshardware). Die Nachrichteneinheit 1904 verteilt Arbeit, die durch die SIMD-Kerne/EUs 1901 zum Scheduler 1907 gespawnt wurde, und greift nach Bedarf auf den freien Stapel-Pool, die Sortierschaltung 1908 oder die Strahl-BVH-Überschneidungsanordnung 1905 zu. Wenn zusätzliche Arbeit an den Scheduler 1907 gesendet wird, wird sie für Verarbeitung auf den SIMD-/SIMT-Kernen/EUs 1901 eingeplant. Vor der Planung kann die Sortierschaltungsanordnung 1908 die Strahlen in Gruppen oder Bins sortieren, wie hierin beschrieben (z.B. Gruppieren von Strahlen mit ähnlichen Eigenschaften). Die Strahl-BVH-Überschneidungsschaltungsanordnung 1905 führt Überschneidungstests der Strahlen unter Verwendung von BVH-Volumen durch. Die Strahlen-BVH-Überschneidungsschaltungsanordnung 1905 kann beispielsweise Strahlkoordinaten mit jeder Ebene der BVH vergleichen, um Volumen zu identifizieren, die von dem Strahl geschnitten werden.

Shader können über einen Shader-Eintrag, eine benutzerzugewiesene Struktur, die einen Zeiger zu der Eintragsfunktion enthält, händlerspezifische Metadaten und globale Argumente zu dem Shader, der von den SIMD-Kernen/EUs 1901 ausgeführt wird, referenzieren. Jede ausführende Instanz eines Shaders ist einem Abrufstapel zugeordnet, der zum Speichern von Argumenten verwendet werden kann, die zwischen einem Parent-Shader und einem Child-Shader übergeben werden. Abrufstapel können auch Verweise auf die Kontinuitätsfunktionen speichern, die ausgeführt werden, wenn ein Abruf zurückkehrt.

20 veranschaulicht einen beispielhaften Satz zugewiesener Stapel 2001, der einen Primär-Shader-Stapel, einen Hit-Shader-Stapel, einen Traversierungs-Shader-Stapel, einen Kontinuitätsfunktionsstapel und einen Strahl-BVH-Überschneidungsstapel enthält (die, wie beschrieben, von Festfunktionshardware 1910 ausgeführt werden können). Neue Shader-Aufrufe können neue Stapel aus einem freien Stapel-Pool 2002 implementieren. Die Abrufstapel können in einem lokalen L1-Cache 1903, 1906 zwischengespeichert werden, um die Latenz der Zugriffen zu reduzieren.

In einer Ausführungsform liegt eine endliche Anzahl von Abrufstapeln vor, jeweils mit einer festen Maximalgröße „Sstack“, die in einem benachbartem Speicherbereich zugewiesen ist. Daher kann die Basisadresse eines Stapels direkt aus einem Stapelindex (SID) als Basisadresse = SID * Sstack berechnet werden. In einer Ausführungsform werden die Stapel-IDs durch den Scheduler 1907 beim Planen von Arbeit für die SIMD-Kerne/EUs 1901 zugewiesen und freigegeben.

In einer Ausführungsform umfasst der Primär-Dispatcher 1909 einen Grafikprozessor-Befehlsprozessor, der Primär-Shader in Reaktion auf einen Dispatch-Befehl von dem Host (z.B. eine CPU) versendet. Der Scheduler 1907 empfängt diese Dispatch-Anforderungen und startet einen Primär-Shader auf einem SIMD-Prozessor-Thread, wenn er eine Stapel-ID für jede SIMD-Lane zuordnen kann. Stapel-IDs werden von dem freien Stapel-Pool 2002 zugewiesen, der zu Beginn des Dispatch-Befehls initialisiert wird.

Ein ausführender Shader kann einen Child-Shader durch Senden einer Spawn-Nachricht an die Nachrichteneinheit 1904 spawnen. Dieser Befehl enthält die Stapel-IDs, die dem Shader zugeordnet sind, und außerdem einen Zeiger zu dem Child-Shader-Eintrag für jede aktive SIMD-Lane. Ein Parent-Shader kann diese Nachricht nur einmal für eine aktive Lane ausgeben. In einer Ausführungsform beendet der Parent-Shader nach dem Senden von Spawn-Nachrichten für alle relevanten Lanes.

Ein Shader, der auf den SIMD-Kernen/EUs 1901 ausgeführt wird, kann außerdem Festfunktionsaufgaben spawnen, wie etwa Strahlen-BVH-Überschneidungen unter Verwendung einer Spawn-Nachricht mit einem Shader-Eintragzeiger, der für die Festfunktionshardware reserviert ist. Wie bereits erwähnt, sendet die Nachrichteneinheit 1904 gespawnte Strahl-BVH-Überschneidungsarbeit an die Festfunktions-Strahl-BVH-Überschneidungsschaltungsanordnung 1905 und aufrufbare Shader direkt an die Sortierschaltungsanordnung 1908. In einer Ausführungsform gruppiert die Sortierschaltungsanordnung die Shader nach Shader-Eintragzeiger, um ein SIMD-Batch mit ähnlichen Eigenschaften abzuleiten. Dementsprechend können Stapel-IDs von unterschiedlichen Parent-Shadern von der Sortierschaltungsanordnung 1908 in dem gleichen Batch gruppiert werden. Die Sortierschaltungsanordnung 1908 sendet gruppierte Batches an den Scheduler 1907, der auf den Shader-Eintrag aus Grafikspeicher 2511 oder den Last-Level-Cache (LLC) 1920 zugreift und den Shader auf einem Prozessor-Thread startet.

In einer Ausführungsform werden Kontinuitäten als aufrufbare Shader behandelt und können auch über Shader-Einträge referenziert werden. Wenn ein Child-Shader gespawnt wird und Werte an den Parent-Shader zurückführt werden, wird ein Zeiger zu dem Kontinuitäts-Shader-Eintrag auf dem Abrufstapel 2001 geschoben. Wenn ein Child-Shader zurückführt, wird der Kontinuitäts-Shader-Eintrag aus dem Aufrufstapel 2001 gepoppt und ein Kontinuitäts-Shader gespawnt. Gespawnte Kontinuitäten durchlaufen die Sortiereinheit ähnlich wie aufrufbare Shader und werden auf einem Prozessor-Thread gestartet.

Wie in 21 veranschaulicht, gruppiert eine Ausführungsform der Sortierschaltungsanordnung 1908 gespawnte Aufgaben nach Shader-Eintragszeigern 2101A, 2101B, 2101n, um SIMD-Batches für Shading zu erstellen. Die Stapel-IDs oder Kontext-IDs können in einem sortierten Batch aus unterschiedlichen Dispatches und unterschiedlichen Eingabe-SIMD-Lanes gruppiert werden. In einer Ausführungsform führt Gruppierungsschaltungsanordnung 2110 das Sortieren unter Verwendung einer CAM-Struktur (Content Addressable Memory) 2101 durch, die mehrere Einträge umfasst, wobei jeder Eintrag mit einem Tag 2101 identifiziert wird. Wie erwähnt, ist das Tag 2101 in einer Ausführungsform ein korrespondierender Shader-Eintragszeiger 2101A, 2101B, 2101n. In einer Ausführungsform speichert die CAM-Struktur 2101 eine begrenzte Anzahl von Tags (z.B. 32, 64, 128 usw.), die jeweils einem unvollständigem SIMD-Batch zugeordnet sind, das einem Shader-Eintragsszeiger entspricht.

Für einen eingehenden Spawn-Befehl verfügt jede SIMD-Lane über eine entsprechende Stapel-ID (gezeigt als 16 Kontext-IDs 0-15 in jedem CAM-Eintrag) und einen Shader-Eintragzeiger 2101A-B,...n (der als ein Tag-Wert dient). In einer Ausführungsform vergleicht die Gruppierungsschaltungsanordnung 2110 den Shader-Eintragzeiger für jede Lane mit den Tags 2101 in der CAM-Struktur 2101, um ein übereinstimmendes Batch zu finden. Wird ein übereinstimmendes Batch gefunden, wird dem Batch die Stapel-ID/Kontext-ID hinzugefügt. Ansonsten wird ein neuer Eintrag mit einem neuen Shader-Eintragzeiger-Tag erzeugt, wodurch möglicherweise ein älterer Eintrag mit einem unvollständigem Batch verdrängt wird.

Ein ausführender Shader kann den Aufrufstapel freigeben, wenn er leer ist, indem er eine Freigabenachricht an die Nachrichteneinheit sendet. Die Freigabenachricht wird an den Scheduler weitergeleitet, der die Stapel-IDs/Kontext-IDs für aktive SIMD-Lanes an den freien Pool zurückführt.

Eine Ausführungsform der Erfindung implementiert einen Hybridansatz für Strahl-Traversierungs-Operationen unter Verwendung einer Kombination aus Festfunktions-Strahl-Traversierung und Software-Strahl-Traversierung. Folglich bietet sie die Flexibilität der Software-Traversierung, während sie gleichzeitig die Effizienz der Festfunktions-Traversierung erhält. 22 zeigt eine Beschleunigungsstruktur, die für hybride Traversierung verwendet werden kann. Dabei handelt es sich um einen Baum mit zwei Ebenen, mit einer einzelnen oberen Ebene BVH 2200 und mehreren unteren Ebenen BVHs 2201 und 2202. Rechts sind Grafikelemente gezeigt, um innere Traversierungspfade 2203, äußere Traversierungspfade 2204, Traversierungsknoten 2205, Blattknoten mit Dreiecken 2206 und Blattknoten mit benutzerdefinierten Primitiven 2207 anzugeben.

Die Blattknoten mit Dreiecken 2206 auf der oberen Ebene BVH 2200 können Dreiecke, Überschneidungs-Shader-Einträge für benutzerdefinierte Primitive oder Traversierungs-Shader-Einträge referenzieren. Die Blattknoten mit Dreiecken 2206 der unteren Ebene BVHs 2201-2202 können nur Dreiecke und Überschneidungs-Shader-Einträge für benutzerdefinierte Primitive referenzieren. Die Art der Referenz ist innerhalb des Blattknotens 2206 kodiert. Innere Traversierung 2203 bezieht sich auf Traversierung innerhalb jeder BVH 2200-2202. Innere Traversierungsoperationen umfassen Berechnung von Strahl-BVH-Überschneidungen und Traversierung über die BVH-Strukturen 2200-2202 ist als äußere Traversierung bekannt. Innere Traversierungsoperationen können effizient in Festfunktionshardware implementiert werden, während äußere Traversierungsoperationen mit programmierbaren Shadern bei akzeptabler Leistung durchgeführt werden können. Folglich führt eine Ausführungsform der Erfindung innere Traversierungsoperationen unter Verwendung von Festfunktionsschaltung 1910 durch und führt äußere Traversierungsoperationen unter Verwendung der Shader-Ausführungsschaltungsanordnung 1900, die SIMD-Kerne/EUs 1901 zum Ausführen programmierbarer Shader enthält, durch.

In einer Ausführungsform wird, wenn ein Strahl einen Traversierungsknoten während einer inneren Traversierung schneidet, ein Traversal-Shader gespawnt. Die Sortierschaltungsanordnung 1908 gruppiert diese Shader nach Shader-Eintragzeigern 2101A-B, n, um ein SIMD-Batch zu erzeugen, das durch den Scheduler 1907 für SIMD-Ausführung auf den Grafik-SIMD-Kernen/EUs 1901 gestartet wird. Traversal-Shader können Traversierung auf mehrere Weisen modifizieren, was eine Vielzahl von Anwendungen ermöglicht. Der Traversal-Shader kann beispielsweise eine BVH auf gröberer Detailstufe (Level of Detail; LOD) auswählen oder den Strahl transformieren, um Starrkörpertransformationen zu ermöglichen. Der Traversal-Shader spawnt dann eine innere Traversierung für die ausgewählte BVH.

Die innere Traversierung berechnet Strahl-BVH-Überschneidungen durch Traversieren des BVH und Berechnen von Strahl-Box- und Strahl-Dreieck-Überschneidungen. Die innere Traversierung wird auf die gleiche Weise wie Shader durch Senden einer Nachricht an die Nachrichtenschaltungsanordnung 1904, welche die entsprechende Spawn-Nachricht an die Strahl-BVH-Überschneidungsschaltungsanordnung 1905 weiterleitet, die die Strahl-BVH-Überschneidungen berechnet, gespawnt.

In einer Ausführungsform wird der Stapel für innere Traversierung lokal in der Festfunktionsschaltungsanordnung 1910 (z.B. innerhalb des L1-Cache 1906) gespeichert. Wenn ein Strahl einen Blattknoten schneidet, der einem Traversal-Shader oder einem Überschneidungs-Shader entspricht, wird die innere Traversierung beendet und der innere Stapel wird abgeschnitten. Der abgeschnittene Stapel wird zusammen mit einem Zeiger zu dem Strahl und der BVH an einer Position in den Speicher geschrieben, die durch den aufrufenden Shader spezifiziert wird, und dann wird der entsprechende Traversal-Shader oder Überschneidungs-Shader gespawnt. Falls der Strahl Dreiecke während der inneren Traversierung schneidet, wird die entsprechende Hit-Information als Eingabeargumente an diese Shader bereitgestellt, wie in dem Code unten gezeigt. Diese gespawnten Shader werden von der Sortierschaltungsanordnung 1908 gruppiert, um SIMD-Batches zur Ausführung zu erzeugen.

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

Abschneiden des inneren Traversierungsstapels reduziert die Kosten eines Spülens in den Speicher. Eine Ausführungsform der Erfindung verwendet zum Abschneiden des Stapels zu einer geringen Anzahl von Einträgen an der Oberseite des Stapels den in Restart Trail for Stackless BVH Traversal, High Performance Graphics (2010), S. 107-111, beschriebenen Ansatz eines 42-Bit-Restart-Trails und eines 6-Bit-Tiefenwertes. Der Restart-Trail gibt Verzweigungen an, denen innerhalb der BVH bereits gefolgt wurde und der Tiefenwert gibt die Tiefe der Traversierung, dem letzten Stapeleintrag entsprechend, an. Dies sind hinreichende Informationen, um innere Traversierung zu einem späteren Zeitpunkt wieder aufzunehmen.

Innere Traversierung ist abgeschlossen, wenn der innere Stapel leer ist und keine BVH-Knoten zum Testen mehr vorliegen. In diesem Fall wird ein äußerer Stapel-Handler gespawnt, der die Oberseite des äußeren Stapel poppt und Traversierung wieder aufnimmt, wenn der äußere Stapel nicht leer ist.

In einer Ausführungsform führt die äußere Traversierung die Haupt-Traversierungs-Zustandsmaschine aus und ist in Programmcode implementiert, der von der Shader-Ausführungsschaltungsanordnung 1900 ausgeführt wird. Sie spawnt eine innere Traversierungsabfrage unter den folgenden Bedingungen: (1) wenn ein neuer Strahl durch einen Hit-Shader oder einen Primär-Shader gespawnt wird; (2) wenn ein Taversal-Shader eine BVH für Traversierung auswählt; und (3) wenn ein äußerer Stapel-Handler innere Traversierung für eine BVH wieder aufnimmt.

Wie in 23 veranschaulicht, wird, bevor innere Traversierung gespawnt wird, auf dem Abrufstapel 2305 Platz für die Festfunktionsschaltungsanordnung 1910 zum Speichern des abgeschnittenen inneren Stapels 2310 zugewiesen. Offsets 2303-2304 zu der Oberseite des Abrufstapels und des inneren Stapels werden in dem Traversierungszustand 2300, der ebenfalls in Speicher 2511 gespeichert wird, aufrechterhalten. Der Traversierungszustand 2300 enthält auch den Strahl in Weltraum 2301 und Objektraum 2302 sowie Hit-Informationen für das nächstgelegene schneidende Primitiv.

Der Traversal-Shader, Überschneidungs-Shader und äußere Stapel-Handler werden alle von der Strahl-BVH-Überschneidungsschaltungsanordnung 1905 gespawnt. Der Traversal-Shader weist auf dem Abruf-Stapel 2305 vor Initiieren einer neuen inneren Traversierung für die BVH auf zweiter Ebene zu. Der äußere Stapel-Handler ist ein Shader, der für Aktualisieren der Hit-Information und Wiederaufnahme ausstehender innerer Traversierungsaufgaben verantwortlich ist. Der äußere Stapel-Handler ist auch für Spawning von Hit- oder Miss-Shadern verantwortlich, wenn die Traversierung abgeschlossen ist. Die Traversierung ist abgeschlossen, wenn keine ausstehenden inneren Traversierungsabfragen für Spawning mehr anstehen. Wenn die Traversierung abgeschlossen ist und eine Überschneidung gefunden wurde, wird ein Hit-Shader gespawnt; andernfalls wird ein Miss-Shader gespawnt.

Während das vorstehend beschriebene hybride Traversierungsschema eine BVH-Hierarchie auf zwei Ebenen nutzt, können Ausführungsformen der hierin beschriebenen Erfindung auch eine beliebige Anzahl von BVH-Ebenen mit einer entsprechenden Veränderung der äußeren Traversierungsimplementierung verwenden.

Weiterhin können, während für die Durchführung von Strahl-BVH-Überschneidungen Festfunktionsschaltungsanordnung 1910 in den vorstehenden Ausführungsformen beschrieben ist, auch andere Systemkomponenten in Festfunktionsschaltungsanordnungen implementiert sein. Der vorstehend beschriebene äußere Stapel-Handler kann beispielsweise ein interner (dem Benutzer nicht sichtbarer) Shader sein, der potenziell in der Festfunktions-BVH-Traversierungs-/Überschneidungsschaltungsanordnung 1905 implementiert sein kann. Diese Implementierung kann zum Reduzieren der Anzahl versendeter Shader-Stufen und Roundtrips zwischen der Festfunktions-Überschneidungs-Hardware 1905 und dem Prozessor verwendet werden.

Die hierin beschriebenen Ausführungsformen der Erfindung ermöglichen programmierbares Shading und Strahl-Traversierungssteuerung unter Verwendung benutzerdefinierter Funktionen, die mit größerer SIMD-Effizienz auf bestehenden und zukünftigen GPU-Prozessoren ausgeführt werden können. Programmierbare Steuerung von Strahl-Traversierung ermöglicht mehrere wichtige Merkmale, wie etwa prozedurale Instanziierung, stochastische Level-of-Detail-Auswahl, benutzerdefinierte Primitivschnittpunkte und verzögerte BVH-Aktualisierungen.

VORRICHTUNG UND VERFAHREN ZUR QUANTISIERTEN, KONVERGENTEN RICHTUNGSBASIERTEN STRAHLSORTIERUNG

Beim Hardware-Raytracing mit einer SIMD-Architektur besteht eines der fundamentalen Probleme darin, alle SIMD-Lanes effektiv auszulasten. Jede Lane kann beispielsweise gleichzeitig an einem separaten Strahl arbeiten und die Strahlen können komplett unabhängig voneinander sein. Um zusammen versandt zu werden, müssen Strahlen gemeinsame Eigenschaften teilen, wie etwa Shader-Programmcode und Texturressourcen.

Darüber hinaus ist es wünschenswert, dass die Strahlen eine gemeinsame Richtung aufweisen und das gleiche Objekt in dem gleichen allgemeinem Raum schneiden. Dadurch wird die Cache-Auslastung verbessert, weil diese Strahlen höchstwahrscheinlich Texturdaten verwenden, die ebenfalls eng beieinander liegen.

Die Ausführungsformen der Erfindung stellen eine energieeffiziente Hardwarelösung zum schnellen Bestimmen der ungefähren Einfallsrichtung eines Strahls aus Sicht des geschnittenen Objekts, basierend auf dessen BVH-Bounding-Box, bereit. Diese Näherung kann dann verwendet werden, um versendete Strahlen nach Einfallsrichtung zu gruppieren.

Insbesondere eine Ausführungsform gruppiert die Strahlen basierend sowohl auf der geschätzten Einfallsrichtung als auch einer Shader-Eintrag-ID, einer benutzerzugewiesenen Struktur, die einen Zeiger zu der Eintragsfunktion enthält, händlerspezifischen Metadaten und globalen Argumenten zu dem Shader, der von den SIMD-Kernen/EUs ausgeführt wird. Diese Ausführungsform gruppiert beispielsweise Strahlen, die an dem gleichen Schnittpunkt konvergieren. Dazu werden grobe Schnittpunktkoordinaten mit der Bounding-Box des Zielobjekts bestimmt und an die Shader-Eintrag-ID angehängt um einen zusammengesetzten Sortierschlüssel zu erzeugen. Strahlen, die die Bounding-Box ungefähr an der gleichen Stelle schneiden, weisen eine höhere Wahrscheinlichkeit auf, dass sie in dem Texturraum des Objekts gemeinsam platziert sind.

Zusätzlich weisen die resultierenden Sekundärstrahlen, wie etwa Reflexionsstrahlen, Schattenstrahlen usw., eine höhere Wahrscheinlichkeit auf, auch die gleiche allgemeine Richtung zu haben. Sie können daher während des Versendens der Sekundärstrahlen unter Verwendung der gleichen Techniken gruppiert werden. Strahlen, die unterschiedliche Instanzen des gleichen Objekts schneiden, können ebenfalls gruppiert werden.

In einer in 24 veranschaulichten Ausführungsform generiert ein Primärstrahl-Generierungs-Shader 2405, der auf einer oder mehreren Ausführungseinheiten (EUs) ausgeführt wird, Sätze von Primärstrahlen. StrahlTraversierungsschaltungsanordnung/Logik 2420 traversiert die Strahlen durch eine konstruierte Bounding-Volumen-Hierarchie (BVH), um Volumen zu identifizieren, durch die die Strahlen laufen. Überschneidungsschaltungsanordnung 2430 führt Überschneidungstests durch, um Objekte in den Volumen zu identifizieren, die von den Strahlen geschnitten werden.

Eine Ausführungsform der Überschneidungsschaltungsanordnung 2430 enthält Strahlrichtungauswertungsschaltungsanordnung/Logik 2435 zum Verarbeiten einer geschätzten Einfallsrichtung 2436 jedes der Strahlen unter Verwendung der nachfolgend beschriebenen Techniken. In einer Ausführungsform generiert der Strahlrichtungsauswerter 2435 einen Strahlrichtungssortierschlüssel 2438 basierend auf der geschätzten Strahlrichtung 2436.

Strahlsortierschaltungsanordnung/Logik 2440 sortiert die Strahlen basierend auf der geschätzten Strahlrichtung 2436 und/oder Strahlrichtungssortierschlüssel 2438 in Kombination mit der Shader-Eintrag-ID 2437. In einer Ausführungsform werden die Strahlen in Gruppen innerhalb mehrerer Sortier-FIFO-Warteschlangen 2400-2403 sortiert. Ein Strahl-Dispatcher 2430 versendet dann die Gruppen von Strahlen aus den Sortier-FIFOs 2400-2403 zu den EUs 2415 zur Weiterverarbeitung und für Traversierungs- und Überschneidungsoperationen.

Wie erwähnt, bestimmt eine Ausführungsform des Strahlrichtungsauswerters 2435 die ungefähre Strahlrichtung 2436 aus einem effizienten Strahl-/Bounding-Box-Test. Er konstruiert dann einen Richtungsortierungsschlüssel 2438 basierend auf der ungefähren Strahlrichtung, was eine kleine Anzahl von Bits zum Kodieren der Richtung des Strahls verwendet. Die Sortierschaltungsanordnung/Logik 2440 verwendet den Richtungsortierschlüssel in Kombination mit einem Shader-Eintrag-ID-Sortierschlüssel (z.B. eine Verkettung der Shader-Eintrag-ID und zusätzlicher konfigurierbarer Felder) zum Gruppieren des Strahlverkehrs in den unterschiedlichen Sortier-FIFOs 2400-2403.

In einer Ausführungsform generiert der Strahlrichtungsauswerter 2435 eine quantisierte Strahlrichtung unter Verwendung der Bounding-Box um das Objekt, die auf der Bounding-Box des BVH-Blatt-Knotens basiert. Da diese BVH-Daten bereits vorliegen, erfordert das Erhalten des BVH-Blatt-Knotens keinen zusätzlichen Aufwand. Zusätzlich wird im Rahmen normaler Raytracing-Operationen ein Strahl-/Blatt-Knoten-Box-Test durchgeführt. Eine Ausführungsform des Strahlrichtungsauswerters 2435 erweitert den Strahl-/Box-Überschneidungstest, um die geschnittene Fläche und Überschneidungskoordinaten niedriger Auflösung dieser Fläche zu extrahieren.

In einer Ausführungsform ist eine eindeutige Identifikation des geschnittenen Knotens in dem Sortierschlüsssel nicht erforderlich. Dies erlaubt es, dass Strahlen, die unterschiedliche Instanzen des gleichen Objekts schneiden, gruppiert werden können. Eine Übereinstimmung mit der Shader-Eintrag-ID schützt vor Gruppieren komplett unzusammenhängender Strahlen, die unzusammenhängende Objekte schneiden. Dies ist für Szenen, die viele wiederholte Strukturen enthalten, besonders vorteilhaft.

25 veranschaulicht ein beispielhaftes Volumen, das von Strahlen 2501-2505 geschnitten wird, mit sechs Wänden A1-A2, B1-B2 und C1-C2 . In einer Ausführungsform erfasst der Strahlrichtungsauswerter 2435, während der Prüfung auf eine Bounding-Box-Überschneidung, welche der sechs Wände A1-A2, B1-B2 und C1-C2 geschnitten wurden. In einer Ausführungsform weist der Strahlrichtungsauswerter 2435 gegenüberliegenden Seiten des Volumens identische Kodierungen zu, weil Strahlen das Objekt im Allgemeinen von einer allgemeinen Seite der Szene aus schneiden. Auf diese Weise gibt es nur drei eindeutige Seitenkodierungen: A, B und C, die in einer 2-Bit-Zahl kodiert werden können. Es ist sehr unwahrscheinlich, dass Strahlen aus exakt gegenüberliegenden Seiten des Objekts kommen. Falls dies geschehen sollte, dann kann der Strahlrichtungsauswerter 2435 wieder zur Verwendung der Shader-Eintrag-ID 2437 zur Gruppierung zurückkehren.

In einer Ausführungsform werden zweidimensionale Strahlüberschneidungskoordinaten generiert, um den Schnittpunkt auf der geschnittenen Wand zu identifizieren. Diese Koordinaten werden dann in ihrer Genauigkeit derart reduziert, dass sie in einen Sortierschlüssel einer bestimmten Größe passen. Als Beispiel und nicht als Einschränkung, können Schnittpunktberechnungen in Gleitkommaformaten mit reduzierter Genauigkeit oder Festkommaformaten durchgeführt werden (z.B. Int4, Int8, Bfloat16 usw.). In einer bestimmten Implementierung wird zum Kodieren jeder der 2D-Koordinanten 3-Bit-Präzision verwendet. Somit können eine 2-Bit-Seitenkodierung und 3-Bit-Werte für jedes von U und V in ein 8-Bit-Feld des Sortierschlüssels gepackt werden.

Diese niedrige Koordinatenauflösing hat zahlreiche Vorteile. Erstens ist, angesichts dessen, dass die Sortierschlüsselgröße nicht oft erhöht wird, ein 8-BitWert ein vernünftiger Kompromiss. Strahlen werden nur grob nach ihren Schnittpunkten gruppiert, ohne dass der Dispatcher 2430 untätig bleibt, weil er auf einen Strahl wartet, der sehr nah mit jenen gepackt ist, die bereits warten. Die hierin beschriebene, zum Erzeugen der Strahl-/Bounding-Box-Schnittpunkte erforderliche Schaltungsanordnung kann von der bestehenden Traversierungs-/Überschneidungsschaltungsanordnung und Operationen profitieren. Die Ausführungsformen der Erfindung erfordern nicht die erhebliche Anzahl zusätzlicher Gates, die typischerweise mit präzisen Gleitkommaberechnungen verbunden sind.

Die Erzeugung eines quantisierten Richtungssortierschlüssels wird unter Bezugnahme auf 25 beschrieben. Strahlen 2501 und 2502 sollten zusammen versendet werden, weil sie das Objekt, das in dieser Bounding-Box enthalten ist, an einer ähnlichen Stelle schneiden. Strahlen 2503 und 2504 sind nicht gemeinsam platziert, weil sie unterschiedliche Wände der Bounding-Box schneiden (d.h. wie durch unterschiedliche Seiten-IDs angegeben). Strahl 2505 trifft die gleiche Wand wie 2501 und 2502, aber an einer anderen Stelle. Folglich hat Strahl 2505 die gleiche Seiten-ID, aber andere U/V-Koordinaten.

26 veranschaulicht eine Ausführungsform eines Sortierschlüssels 2600, der einen Shader-Eintrag-Schlüssel 2601 und einen Überschneidungsschlüssel 2602 umfasst. Der Überschneidungsschlüssel dieser Ausführungsform umfasst die vorstehend beschriebenen 8-Bit-Werte - d.h. 6 Bits für die U- und V-Koordinaten (d.h. Bits 39:34) und eine 2-Bit-Seiten-ID (d.h. 33:32). Die Bits des 8-Bit-Überschneidungsschlüssels 2602, die sich am häufigsten ändern können (d.h. die U[0]- und V[0]-Werte) sind in den höchstwertigsten Bitpositionen des Sortierschlüssels 2600 kodiert. Die Bits sind gewissermaßen nach ihrer Entropie sortiert. Der Grund für diesen besonderen Aspekt ist, dass die Sortiergenauigkeit leicht durch Ändern nur der Anzahl von Sortierschlüssel-Bits zur Übereinstimmung angepasst werden kann. In einer Implementierung wird die niedrigste Genauigkeit (1) durch Abgleich nur der niederwertigsten 32 Bits, die die Shader-Eintrag-ID kodieren (d.h. Bits 31:0), erreicht. Die höchste Genauigkeit (5) wird durch Übereinstimmung aller 40 Bits erreicht.

In einer Ausführungsform verwendet die Sortierschaltungsanordnung/Logik 2440 die angleichbare Sortierschlüsselgenauigkeit und füllt die Sortier-FIFOs 2403 in Übereinstimmung mit dem folgenden Regelsatz, der unter Bezugnahme auf das Flussdiagramm in 27 beschrieben ist.

Bei 2701 wird, wenn ein neuer Strahl zum Sortieren empfangen wird, die Genauigkeit P anfänglich auf den höchsten Wert gesetzt (z.B. 40 Bits in einer Ausführungsform). Wird eine Übereinstimmung gefunden, wie bei 2702 bestimmt, dann wird der Strahl bei 2706 an die entsprechende Sortier-FIFO übergeben. Wird bei 2702 keine Übereinstimmung gefunden und wenn alle Sortier-FIFOs zugeordnet sind, was bei 2703 bestimmt wird, dann wird die Genauigkeit bei 2705 um ein bestimmtes Inkrement reduziert. Bei 2702 wird ein Versuch unternommen, eine Übereinstimmung bei der niedrigeren Genauigkeit zu finden, und falls eine gefunden wird, wird der Strahl bei 2706 der Sortier-FIFO hinzugefügt. Falls nicht, dann kann die Genauigkeit bei 2705 weiter gesenkt werden bis bei 2702 eine Übereinstimmung gefunden wird.

Wenn bei 2703, nach Bestimmung keiner Übereinstimmung bei 2702, Sortier-FIFOs verfügbar sind, dann wird bei 2704 bei der aktuellen Genauigkeit P (z.B. der höchsten Genauigkeit) eine neue Sortier-FIFO gebildet. Wie erwähnt, kann die neue Sortier-FIFO den gleichen Shader-Eintrag-Schlüssel 2601 aufweisen wie ein bestehender Sortier-FIFO (aber mit einem anderen Überschneidungsschlüssel). Der aktuelle Strahl wird dem neuen Sortier-FIFO hinzugefügt und der nächste Strahl wird bei 2707 ausgewählt.

Somit wird in dieser Ausführungsform, wenn alle Sortier-FIFOs 2400-2403 zugewiesen sind und es keine exakten 40-Bit-Sortierschlüsselübereinstimmungen gibt, die Genauigkeit reduziert bis eine Übereinstimmung gefunden wird oder bis die Genauigkeit einen Mindestwert (d.h. die 32-Bit-Shader-Eintrag-ID 2601) erreicht hat. Wenn manche Sortier-FIFOs verfügbar sind und keine exakte 40-Bit-Sortierschlüsselübereinstimmung vorliegt, wird für diesen nicht übereinstimmenden Sortierschlüssel eine neue Sortier-FIFO gebildet. Die Shader-Eintrag-ID kann somit über mehrere FIFOs dupliziert werden. In einer Ausführungsform können, während erzwungener Räumung teilweise belegter Sortier-FIFOs, Strahlen über unterschiedliche Sortier-FIFOs kombiniert werden, solange die Shader-Eintrag-IDs 2601 übereinstimmen.

Dieser Ansatz verbessert die Speichereffizienz des Hardware-Raytracings, was die Leistung verbessert und den Stromverbrauch reduziert. Raytracing soll zukünftig herkömmliche Rasterungstechniken ersetzen. Wir müssen bei der Leistung äußerst wettbewerbsfähig sein, um das Marksegment High-End-Grafik zu gewinnen.

In Ausführungsformen kann sich der Begriff „Engine“ oder „Modul“ oder „Logik“ auf eine anwendungsspezifische integrierte Schaltung (Application Specific Integrated Circuit; ASIC), eine elektronische Schaltung, einen Prozessor (geteilt, dediziert oder Gruppe) und/oder Speicher (geteilt, dediziert oder Gruppe), der bzw. die ein oder mehrere Software- oder Firmwareprogramme ausführt bzw. ausführen, eine kombinatorische Logikschaltung und/oder andere geeignete Komponenten, die die beschriebene Funktionalität bereitstellt, beziehen, Teil davon sein, oder diese beinhalten. In Ausführungsformen kann eine Engine, ein Modul oder eine Logik in Firmware, Hardware, Software oder einer Kombination aus Firmware, Hardware und Software implementiert sein.

BEISPIELE

Das Folgende sind beispielhafte Implementierungen unterschiedlicher Ausführungsformen der Erfindung.

Beispiel 1. Eine Vorrichtung umfasst: einen Strahlgenerator zum Generieren mehrerer Strahlen; Strahlrichtungsauswertungsschaltungsanordnung/Logik zum Generieren ungefährer Strahlrichtungsdaten für jeden der mehreren Strahlen; und Strahlsortierschaltungsanordnung/Logik zum Sortieren der Strahlen in mehrere Strahlwarteschlangen, zumindest teilweise basierend auf den ungefähren Strahlrichtungsdaten.

Beispiel 2. Die Vorrichtung des Beispiels 1, wobei die ungefähren Strahlrichtungsdaten einen quantisierten Richtungswert umfassen, der jedem Strahl der mehreren Strahlen zugeordnet ist.

Beispiel 3. Die Vorrichtung des Beispiels 2, wobei der quantisierte Richtungswert für jeden Strahl erste Daten umfasst, die eine Seite eines Volumens angeben, das von dem Strahl geschnitten wird, und zweite Daten quantisierte Überschneidungskoordinaten einer Überschneidung zwischen dem Strahl und der Seite des Volumens umfassen.

Beispiel 4. Die Vorrichtung des Beispiels 2, wobei die Strahlsortierschaltungsanordnung/Logik einen oder mehrere der Vielzahl von Strahlen in die mehreren Strahlwarteschlangen basierend auf einer Kombination des quantisierten Richtungswerts mit einem Shader-Eintrag-Schlüssel, der dem Strahl zugeordnet ist, zu gruppieren hat.

Beispiel 5. Die Vorrichtung des Beispiels 4, wobei die Strahlsortierschaltungsanordnung/Logik zuerst zu versuchen hat, einen Strahl mit einer Strahlwarteschlange unter Verwendung sowohl des quantisierten Strahlrichtungswerts als auch des Shader-Eintrag-Schlüssels abzugleichen, und zu versuchen hat, den Strahl mit einer Strahlwarteschlange unter Verwendung nur des Shader-Eintrag-Schlüssels nur abzugleichen, wenn keine Übereinstimmung gefunden wird.

Beispiel 6. Die Vorrichtung des Beispiels 5, wobei, wenn unter Verwendung des quantisierten Strahlrichtungswerts und des Shader-Eintrag-Schlüssels keine Übereinstimmung gefunden wird, die Strahlsortierschaltungsanordnung/Logik zu versuchen hat, eine neue Strahlwarteschlange, die den Strahl enthält, zuzuweisen.

Beispiel 7. Die Vorrichtung des Beispiels 6, wobei die Sortierschaltungsanordnung/Logik zu versuchen hat, den Strahl mit einer Strahlwarteschlange nur unter Verwendung des Shader-Eintrag-Schlüssels nur nach Bestimmen, dass die neue Strahlwarteschlange nicht zugewiesen werden kann, abzugleichen.

Beispiel 8. Die Vorrichtung des Beispiels 1, ferner umfassend: einen Strahl-Dispatcher zum Versenden der mehreren Strahlen in Gruppen, die durch die Strahlwarteschlangen, in denen die Strahlen gespeichert sind, definiert sind.

Beispiel 9. Die Vorrichtung des Beispiels 1, ferner umfassend: Strahltraversierungsschaltungsanordnung zum Traversieren eines oder mehrerer der mehreren Strahlen durch eine Bounding-Volumen-Hierarchie; und Strahlüberschneidungsschaltungsanordnung zum Bestimmen von Überschneidungen zwischen einem oder mehreren der mehreren Strahlen und einem oder mehreren Objekten in einer Szene.

Beispiel 10. Ein Verfahren, umfassend: Erzeugen mehrerer Strahlen; Bestimmen ungefährer Strahlrichtungsdaten für jeden der mehreren Strahlen; und Sortieren der Strahlen in mehrere Strahlwarteschlangen zumindest teilweise basierend auf den ungefähren Strahlrichtungsdaten.

Beispiel 11. Das Verfahren des Beispiels 10, wobei die ungefähren Strahlrichtungsdaten einen quantisierten Richtungswert umfassen, der jedem Strahl der mehreren Strahlen zugeordnet ist.

Beispiel 12. Das Verfahren des Beispiels 11, wobei der quantisierte Richtungswert für jeden Strahl erste Daten umfasst, die eine Seite eines Volumens angeben, das von dem Strahl geschnitten wird, und zweite Daten quantisierte Überschneidungskoordinaten einer Überschneidung zwischen dem Strahl und der Seite des Volumens umfassen.

Beispiel 13. Das Verfahren nach Beispiel 11, wobei Sortieren ferner umfasst: Gruppieren der mehreren Strahlen in die mehreren Strahlwarteschlangen basierend auf einer Kombination des quantisierten Richtungswerts und eines Shader-Eintrag-Schlüssels, der dem Strahl zugeordnet ist.

Beispiel 14. Das Verfahren des Beispiels 13, ferner umfassend: anfängliches Versuchen, einen Strahl mit einer Strahlwarteschlange unter Verwendung sowohl des quantisierten Strahlrichtungswerts als auch des Shader-Eintrag-Schlüssels abzugleichen; und Versuchen, den Strahl mit einer Strahlwarteschlange unter Verwendung nur des Shader-Eintrag-Schlüssels nur wenn keine Übereinstimmung gefunden wird abzugleichen.

Beispiel 15. Das Verfahren des Beispiels 14, ferner umfassend: Versuchen, eine neue Strahlwarteschlange, die den Strahl enthält, zuzuweisen, wenn unter Verwendung sowohl des quantisierten Strahlrichtungswerts als auch des Shader-Eintrag-Schlüssels keine Übereinstimmung gefunden wird.

Beispiel 16. Das Verfahren des Beispiels 15, wobei Versuchen, den Strahl mit einer Strahlwarteschlange unter Verwendung nur des Shader-Eintrag-Schlüssels abzugleichen, nur nach Bestimmen, dass die neue Strahlwarteschlange nicht zugewiesen werden kann, durchgeführt wird.

Beispiel 17. Das Verfahren des Beispiels 10, ferner umfassend: Versenden der mehreren Strahlen in Gruppen, die durch die Strahlwarteschlangen, in denen die Strahlen gespeichert sind, definiert sind.

Beispiel 18. Das Verfahren des Beispiels 10, ferner umfassend: Traversieren von einem oder mehreren der mehreren Strahlen durch eine Bounding-Volumen-Hierarchie; und Bestimmen von Überschneidungen zwischen einem oder mehreren der mehreren Strahlen und einem oder mehreren Objekten in einer Szene.

Beispiel 19. Ein maschinenlesbares Medium mit darauf gespeichertem Programmcode, der, wenn er von einer Maschine ausgeführt wird, die Maschine veranlasst, die folgenden Operationen durchzuführen: Generieren mehrerer Strahlen; Bestimmen ungefährer Strahlrichtungsdaten für jeden der mehreren Strahlen; und Sortieren der Strahlen in mehrere Strahlwarteschlangen zumindest teilweise basierend auf den ungefähren Strahlrichtungsdaten.

Beispiel 20. Das maschinenlesbare Medium des Beispiels 19, wobei die ungefähren Strahlrichtungsdaten einen quantisierten Richtungswert umfassen, der jedem Strahl der mehreren Strahlen zugeordnet ist.

Beispiel 21. Das maschinenlesbare Medium des Beispiels 20, wobei der quantisierte Richtungswert für jeden Strahl erste Daten umfasst, die eine Seite eines Volumens angeben, die von dem Strahl geschnitten wird, und zweite Daten, die quantisierte Überschneidungskoordinaten einer Überschneidung zwischen dem Strahl und der Seite des Volumens umfassen.

Beispiel 22. Das maschinenlesbare Medium des Beispiels 20, wobei Sortieren ferner umfasst: Gruppieren der mehreren Strahlen in die mehreren Strahlwarteschlangen basierend auf einer Kombination des quantisierten Richtungswerts und eines Shader-Eintrag-Schlüssels, der dem Strahl zugeordnet ist.

Beispiel 23. Das maschinenlesbare Medium des Beispiels 22, ferner Programmcode umfassend, um die Maschine zu veranlassen, die folgenden Operationen durchzuführen: anfängliches Versuchen einen Strahl mit einer Strahlwarteschlange unter Verwendung sowohl des quantisierten Strahlrichtungswerts als auch des Shader-Eintrag-Schlüssels abzugleichen; und Versuchen, den Strahl mit einer Strahlwarteschlange unter Verwendung von nur dem Shader-Eintrag-Schlüssel nur wenn keine Übereinstimmung gefunden wurde abzugleichen.

Beispiel 24. Das maschinenlesbare Medium des Beispiels 23, ferner umfassend: Versuchen, eine neue Strahlwarteschlange, die den Strahl enthält, zuzuweisen, wenn unter Verwendung sowohl des quantisierten Strahlrichtungswerts als auch des Shader-Eintrag-Schlüssels keine Übereinstimmung gefunden wird.

Beispiel 25. Das maschinenlesbare Medium des Beispiels 24, wobei Versuchen, den Strahl mit einer Strahlwarteschlange unter Verwendung nur des Shader-Eintrag-Schlüssels abzugleichen, nur nach Bestimmen, dass die neue Strahlwarteschlange nicht zugewiesen werden kann, durchgeführt wird.

Beispiel 26. Das maschinenlesbare Medium des Beispiels 19, ferner Programmcode umfassend, um die Maschine zu veranlassen, die folgenden Operationen durchzuführen: Versenden der mehreren Strahlen in Gruppen, die durch die Strahlwarteschlangen, in denen die Strahlen gespeichert sind, definiert sind.

Beispiel 27. Das maschinenlesbare Medium des Beispiels 19, ferner Programmcode umfassend, um die Maschine zu veranlassen, die folgenden Operationen durchzuführen: Traversieren von einem oder mehreren der mehreren Strahlen durch eine Bounding-Volumen-Hierarchie; und Bestimmen von Überschneidungen zwischen einem oder mehreren der mehreren Strahlen und einem oder mehreren Objekten in einer Szene.

Ausführungsformen der Erfindung können verschiedene Schritte umfassen, die vorstehend beschrieben wurden. Die Schritte können in maschinenausführbaren Anweisungen verkörpert sein, die verwendet werden können, um einen Universal- oder Spezialprozessor zu veranlassen, die Schritte durchzuführen. Alternativ können diese Schritte von spezifischen Hardwarekomponenten durchgeführt werden, die festverdrahtete Logik zum Durchführen dieser Schritte enthalten, oder durch eine beliebige Kombination programmierter Computerkomponenten und benutzerdefinierter Hardwarekomponenten.

Wie hierin beschrieben, können sich Anweisungen auf spezifische Konfigurationen von Hardware beziehen, wie etwa anwendungsspezifische integrierte Schaltungen (ASICs), die dafür ausgelegt sind, bestimmte Operationen durchzuführen oder eine vorbestimmte Funktionalität aufzuweisen, oder Softwareanweisungen, die in einem Speicher gespeichert sind, der in einem nichtflüchtigen, computerlesbarem Medium verkörpert ist. Somit lassen sich die in den Figuren gezeigten Techniken unter Verwendung von Code und Daten implementieren, der bzw. die auf einer oder mehreren elektronischen Vorrichtungen (z.B. eine Endstation, ein Netzwerkelement usw.) gespeichert ist bzw. sind und ausgeführt wird bzw. werden. Solche elektronischen Vorrichtungen speichern und kommunizieren (intern und/oder mit anderen elektronischen Vorrichtungen über ein Netzwerk) Code und Daten unter Verwendung computermaschinenlesbarer Medien, wie etwa nichtflüchtige computer-maschinenlesbare Speichermedien (z.B. Magnetplatten; optische Platten; Direktzugriffsspeicher; Nur-Lese-Speicher; Flash-Speichervorrichtungen; Phasenwechselspeicher) und flüchtige computer-maschinenlesbare Kommunikationsmedien (z.B. elektrische, optische, akustische oder andere Formen sich ausbreitender Signale - wie etwa Trägerwellen, Infrarotsignale, digitale Signale usw.).

Darüber hinaus umfassen solche elektronischen Vorrichtungen typischerweise einen Satz von einem oder mehreren Prozessoren, die mit einer oder mehreren anderen Komponenten gekoppelt sind, wie etwa eine oder mehrere Speichervorrichtungen (nichtflüchtige, maschinenlesbare Speichermedien), Benutzer-Eingabe-/Ausgabevorrichtungen (z.B. eine Tastatur, ein Touchscreen und/oder eine Anzeige) und Netzwerkverbindungen. Die Kopplung des Satzes von Prozessoren und anderer Komponenten erfolgt typischerweise über einen oder mehrere Busse und Brücken (auch als Bus-Controller bezeichnet). Die Speichervorrichtung und die Signale, die den Netzwerkverkehr befördern, repräsentieren jeweils ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien. Somit speichert die Speichervorrichtung einer gegebenen elektronischen Vorrichtung typischerweise Code und/oder Daten zur Ausführung auf dem Satz von einem oder mehreren Prozessoren dieser elektronischen Vorrichtung. Natürlich kann bzw. können ein oder mehrere Teile einer Ausführungsform der Erfindung auch unter Verwendung anderer Kombinationen von Software, Firmware und/oder Hardware implementiert werden. In dieser ausführlichen Beschreibung sind zu Erklärungszwecken zahlreiche spezifische Details dargelegt, um ein genaues Verständnis der vorliegenden Erfindung zu ermöglichen. Es wird Fachleuten jedoch offensichtlich sein, dass die Erfindung auch ohne manche dieser spezifischen Details praktiziert werden kann. In bestimmten Fällen wurden weithin bekannte Strukturen und Funktionen nicht ausführlich beschrieben, um eine Verundeutlichung des Gegenstands der vorliegenden Erfindung zu vermeiden. Dementsprechend muss der Umfang und Geist der Erfindung anhand 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 Nicht-Patentliteratur

Restart Trail for Stackless BVH Traversal, High Performance Graphics (2010), S. 107-111 [0226]

Claims

Vorrichtung, umfassend: einen Strahlgenerator zum Erzeugen mehrerer Strahlen; Strahlrichtungsauswertungsschaltungsanordnung/Logik zum Generieren ungefährer Strahlrichtungsdaten für jeden der mehreren Strahlen; und Strahlsortierschaltungsanordnung/Logik zum Sortieren der Strahlen in mehrere Strahlwarteschlangen zumindest teilweise basierend auf den ungefähren Strahlrichtungsdaten.
Vorrichtung nach Anspruch 1, wobei die ungefähren Strahlrichtungsdaten einen quantisierten Richtungswert umfassen, der jedem Strahl der mehreren Strahlen zugeordnet ist.
Vorrichtung nach Anspruch 2, wobei der quantisierte Richtungswert für jeden Strahl erste Daten umfasst, die eine Seite eines Volumens angeben, das von dem Strahl geschnitten wird, und zweite Daten, die quantisierte Überschneidungskoordinaten einer Überschneidung zwischen dem Strahl und der Seite des Volumens umfassen.
Vorrichtung nach Anspruch 2, wobei die Strahlsortierschaltungsanordnung/Logik einen oder mehrere der mehreren Strahlen in die mehreren Strahlwarteschlangen basierend auf einer Kombination des quantisierten Richtungswerts und einem Shader-Eintrag-Schlüssel, der dem Strahl zugeordnet ist, zu gruppieren hat.
Vorrichtung nach Anspruch 4, wobei die Strahlsortierschaltungsanordnung/Logik zuerst zu versuchen hat, einen Strahl mit einer Strahlwarteschlange unter Verwendung sowohl des quantisierten Strahlrichtungswerts als auch des Shader-Eintrag-Schlüssels abzugleichen, und zu versuchen hat, den Strahl mit einer Strahlwarteschlange unter Verwendung nur des Shader-Eintrag-Schlüssels nur abzugleichen, wenn keine Übereinstimmung gefunden wird.
Vorrichtung nach Anspruch 5, wobei, wenn unter Verwendung sowohl des quantisierten Strahlrichtungswerts als auch des Shader-Eintrag-Schlüssels keine Übereinstimmung gefunden wird, die Strahlsortierschaltungsanordnung/Logik zu versuchen hat, eine neue Strahlwarteschlange, die den Strahl enthält, zuzuweisen.
Vorrichtung nach Anspruch 6, wobei die Sortierschaltungsanordnung/Logik zu versuchen hat, den Strahl mit einer Strahlwarteschlange unter Verwendung nur des Shader-Eintrag-Schlüssels nur nach Bestimmen, dass die neue Strahlwarteschlange nicht zugewiesen werden kann, abzugleichen.
Vorrichtung nach einem der Ansprüche 1 bis 7, ferner umfassend: einen Strahl-Dispatcher zum Versenden der mehreren Strahlen in Gruppen, die durch die Strahlwarteschlangen, in denen die Strahlen gespeichert sind, definiert sind.
Vorrichtung nach einem der Ansprüche 1 bis 8, ferner umfassend: Strahltraversierungsschaltungsanordnung zum Traversieren von einem oder mehreren der mehreren Strahlen durch eine Bounding-Volumen-Hierarchie; und Strahlüberschneidungsschaltungsanordnung zum Bestimmen von Überschneidungen zwischen einem oder mehreren der mehreren Strahlen und einem oder mehreren Objekten in einer Szene.
Verfahren, umfassend: Generieren mehrerer Strahlen; Bestimmen ungefährer Strahlrichtungsdaten für jeden der mehreren Strahlen; und Sortieren der Strahlen in mehrere Strahlwarteschlangen zumindest teilweise basierend auf den ungefähren Strahlrichtungsdaten.
Verfahren nach Anspruch 10, wobei die ungefähren Strahlrichtungsdaten einen quantisierten Richtungswert umfassen, der jedem Strahl der mehreren Strahlen zugeordnet ist.
Verfahren nach Anspruch 11, wobei der quantisierte Richtungswert für jeden Strahl erste Daten umfasst, die eine Seite eines Volumens angeben, das von dem Strahl geschnitten wird, und zweite Daten, die quantisierte Überschneidungskoordinaten einer Überschneidung zwischen dem Strahl und der Seite des Volumens umfassen.
Verfahren nach Anspruch 11, wobei Sortieren ferner umfasst: Gruppieren der mehreren Strahlen in die mehreren Strahlwarteschlangen basierend auf einer Kombination des quantisierten Richtungswerts und eines Shader-Eintrag-Schlüssels, der dem Strahl zugeordnet ist.
Verfahren nach Anspruch 13, ferner umfassend: anfängliches Versuchen, einen Strahl mit einer Strahlwarteschlange unter Verwendung sowohl des quantisierten Strahlrichtungswerts als auch des Shader-Eintrag-Schlüssels abzugleichen; und Versuchen, den Strahl mit einer Strahlwarteschlange unter Verwendung nur des Shader-Eintrag-Schlüssels nur, wenn keine Übereinstimmung gefunden wird, abzugleichen.
Verfahren nach Anspruch 14, ferner umfassend: Versuchen, eine neue Strahlwarteschlange, die den Strahl enthält, zuzuweisen, wenn unter Verwendung sowohl des quantisierten Strahlrichtungswerts als auch des Shader-Eintrag-Schlüssels keine Übereinstimmung gefunden wird.
Verfahren nach Anspruch 15, wobei Versuchen, den Strahl mit einer Strahlwarteschlange unter Verwendung nur des Shader-Eintrag-Schlüssels abzugleichen, nur nach Bestimmen, dass die neue Strahlwarteschlange nicht zugewiesen werden kann, durchgeführt wird.
Verfahren nach einem der Ansprüche 10 bis 16, ferner umfassend: Versenden der mehreren Strahlen in Gruppen, die durch die Strahlwarteschlangen, in denen die Strahlen gespeichert sind, definiert sind.
Verfahren nach einem der Ansprüche 10 bis 17, ferner umfassend: Traversieren von einem oder mehreren der mehreren Strahlen durch eine Bounding-Volumen-Hierarchie; und Bestimmen von Überschneidungen zwischen einem oder mehreren der mehreren Strahlen und einem oder mehreren Objekten in einer Szene.
Maschinenlesbares Medium mit darauf gespeichertem Code, der, wenn er von einer Maschine ausgeführt wird, die Maschine veranlasst, die folgenden Operationen durchzuführen: Generieren mehrerer Strahlen; Bestimmen ungefährer Strahlrichtungsdaten für jeden der mehreren Strahlen; und Sortieren der Strahlen in mehrere Strahlwarteschlangen zumindest teilweise basierend auf den ungefähren Strahlrichtungsdaten.
Maschinenlesbares Medium nach Anspruch 19, wobei die ungefähren Strahlrichtungsdaten einen quantisierten Richtungswert umfassen, der jedem Strahl der mehreren Strahlen zugeordnet ist.
Maschinenlesbares Medium nach Anspruch 20, wobei der quantisierte Richtungswert für jeden Strahl erste Daten umfasst, die eine Seite eines Volumens angeben, das von dem Strahl geschnitten wird, und zweite Daten quantisierte Überschneidungskoordinaten einer Überschneidung zwischen dem Strahl und der Seite des Volumens umfassen.
Maschinenlesbares Medium nach Anspruch 20, wobei Sortieren ferner umfasst: Gruppieren der mehreren Strahlen in die mehreren Strahlwarteschlangen basierend auf einer Kombination des quantisierten Richtungswerts und eines Shader-Eintrag-Schlüssels, der dem Strahl zugeordnet ist.
Maschinenlesbares Medium nach Anspruch 22, ferner Programmcode umfassend, um die Maschine zu veranlassen, die folgenden Operationen durchzuführen: anfängliches Versuchen, einen Strahl mit einer Strahlwarteschlange unter Verwendung sowohl des quantisierten Strahlrichtungswerts als auch des Shader-Eintrag-Schlüssels abzugleichen; und Versuchen, den Strahl mit einer Strahlwarteschlange unter Verwendung nur des Shader-Eintrag-Schlüssels nur, wenn keine Übereinstimmung gefunden wird, abzugleichen.
Maschinenlesbares Medium nach Anspruch 23, ferner umfassend: Versuchen, eine neue Strahlwarteschlange, die den Strahl enthält, zuzuweisen, wenn unter Verwendung sowohl des quantisierten Strahlrichtungswerts als auch des Shader-Eintrag-Schlüssels keine Übereinstimmung gefunden wird.
Maschinenlesbares Medium nach Anspruch 24, wobei Versuchen, den Strahl mit einer Strahlwarteschlange unter Verwendung nur des Shader-Eintrag-Schlüssels abzugleichen, nur nach Bestimmen, dass die neue Strahlwarteschlange nicht zugewiesen werden kann, durchgeführt wird.