DE112017003841T5

DE112017003841T5 - Verfahren und vorrichtung für die korrekte reihung und nummerierung mehrerer aufeinanderfolgender strahl-oberflächen-schnittpunkte innerhalb einer raytracing-architektur

Info

Publication number: DE112017003841T5
Application number: DE112017003841.3T
Authority: DE
Inventors: Ingo Wald
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2016-09-29
Filing date: 2017-08-21
Publication date: 2019-05-02
Also published as: US11107266B2; US20180089885A1; US10282890B2; CN109643461B; CN109643461A; WO2018063582A1; US20190228561A1

Abstract

Eine Vorrichtung und ein Verfahren zum Ausführen eines Abstandtests in einem Raytracing-System werden beschrieben. Zum Beispiel weist eine Ausführungsform einer Grafikverarbeitungsvorrichtung auf: eine Raytracing-Querungs-/Schnittpunkteinheit, um zwei oder mehr Strahl-Fläche-Schnittpunkte zu identifizieren, wobei jeder der Strahl-Fläche-Schnittpunkte einer einzigartigen Trefferpunktkennung (ID) zugeteilt ist; und ein Abstandtestmodul, um die Reihung der Strahl-Fläche-Schnittpunkte unter Verwendung der Trefferpunkt-ID eindeutig zu machen, falls es zwei oder mehr der Strahl-Fläche-Schnittpunkte gibt, die den gleichen Abstand teilen.

Description

HINTERGRUND
Gebiet der Erfindung
Die Erfindung bezieht sich im Allgemeinen auf das Feld von Computerprozessoren. Insbesondere bezieht sich die Erfindung auf eine Vorrichtung und ein Verfahren zum Identifizieren der korrekten Reihung und Nummerierung aufeinanderfolgender Strahl-Oberflächen-Schnittpunkte in einer Raytracing-Architektur.
Beschreibung des Stands der Technik
Raytracing ist eine Grafikverarbeitungstechnik zum Erzeugen eines Bilds dadurch, den Pfad jedes Lichtstrahls durch Pixel in einer Bildebene durchzuziehen und die Effekte dessen Einfalls auf verschiedene Objekte zu simulieren. Durchzugsberechnungen folgend, wird jeder Strahl typischerweise auf Schnitt mit einem Teilsatz der Objekte in der Szene getestet. Sobald das nächstliegende Objekt identifiziert wurde, wird das eingehende Licht am Schnittpunkt geschätzt, die Materialeigenschaften des Objekts werden ermittelt und diese Informationen verwendet, um die finale Farbe des Pixels zu berechnen.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung kann aus der folgenden ausführlichen Beschreibung in Verbindung mit den folgenden Zeichnungen erhalten werden, in denen:

1 ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor ist, der einen oder mehr Prozessorkerne und Grafikprozessoren hat;
2 ein Blockdiagramm einer Ausführungsform eines Prozessors mit einem oder mehr Prozessorkernen, einer integrierten Speichersteuerung und einem integrierten Grafikprozessor ist;
3 ein Blockdiagramm einer Ausführungsform eines Grafikprozessors ist, der eine diskrete Grafikverarbeitungseinheit sein kann oder mit mehreren Verarbeitungskernen in den Grafikprozessor integriert sein kann;
4 ein Blockdiagramm einer Ausführungsform einer Grafikverarbeitungs-Engine für einen Grafikprozessor ist;
5 ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors ist;
6 ein Blockdiagramm von ThreadDurchführungslogik ist, enthaltend ein Array von Verarbeitungselementen;
7 ein Grafikprozessordurchführungseinheit-Befehlsformat gemäß einer Ausführungsform veranschaulicht;
8 ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors ist, der eine Grafikpipeline, eine Medienpipeline, eine Anzeige-Engine, Threaddurchführungslogik und eine Render-Ausgabepipeline enthält;
9A ein Blockdiagramm ist, das ein Grafikprozessorkommandoformat gemäß einer Ausführungsform veranschaulicht;
9B ein Blockdiagramm ist, das eine Grafikprozessorkommandosequenz gemäß einer Ausführungsform veranschaulicht;
10 beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einer Ausführungsform veranschaulicht;
11 ein beispielhaftes IP-Kernentwicklungssystem veranschaulicht, das verwendet werden kann, einen integrierten Schaltkreis herzustellen, um Betriebe gemäß einer Ausführungsform auszuführen;
12 ein beispielhaftes System-auf-einem-Chip-integrierten Schaltkreis veranschaulicht, der unter Verwendung eines oder mehr IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform;
13 eine Ausführungsform eines Systems zum Ausführen einer Abstandsprüfung in einer Raytracing-Architektur veranschaulicht; und
14 ein Verfahren in Übereinstimmung mit einer Ausführungsform der Erfindung veranschaulicht;
15 eine Ausführungsform eines Verfahrens zum Finden eines nächsten Treffers in einer Raytracing-Implementierung veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zum Zweck der Erklärung zahlreiche spezifische Details vorgebracht, um ein umfassendes Verständnis der Ausführungsformen der Erfindung, die in der Folge beschrieben werden, bereitzustellen. Es wird jedoch dem Fachkundigen ersichtlich sein, dass die Ausführungsformen der Erfindung ohne manche dieser spezifischen Details ausgeübt werden können. In anderen Fällen werden wohlbekannte Strukturen und Geräte in Blockdiagrammform gezeigt, um zu vermeiden, die zugrundeliegenden Prinzipien der Ausführungsformen der Erfindung zu verschleiern.
BEISPIELHAFTE GRAFIKPROZESSORARCHITEKTUREN UND DATENTYPEN
Systemübersicht
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. In unterschiedlichen Ausführungsformen enthält das System 100 einen oder mehr Prozessoren 102 und einen oder mehr Grafikprozessoren 108 und kann ein Einzelprozessor-Standrechnersystem, ein Mehrfachprozessor-Arbeitsstationssystem oder ein Serversystem mit einer großen Zahl an Prozessoren 102 oder Prozessorkernen 107 sein. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die innerhalb eines System-auf-einem-Chip- (System-on-a-Chip, SoC) integrierten Schaltkreis zur Verwendung in mobilen, handgehaltenen oder eingebetteten Geräten, eingegliedert ist.
Eine Ausführungsform von System 100 kann eine serverbasierte Spieleplattform, eine Spielkonsole, enthaltend eine Spiele- und Medienkonsole, eine mobile Spielkonsole, eine handgetragene Spielkonsole oder eine Online-Spielkonsole enthalten oder darin eingegliedert sein. In manchen Ausführungsformen ist System 100 ein Mobiltelefon, Smartphone, Tablet-Rechengerät oder mobiles Internetgerät. Datenverarbeitungssystem 100 kann auch ein tragbares Gerät enthalten, damit gekoppelt sein oder darin integriert sein, wie ein tragbares Smartwatch-Gerät, smartes Brillen- und Kontaktlinsengerät, Erweiterte-Realität-Gerät oder Virtuelle-Realität-Gerät. In manchen Ausführungsformen ist Datenverarbeitungssystem 100 ein Fernseher oder Set-Top-Box-Gerät mit einem oder mehr Prozessoren 102 und einer grafischen Schnittstelle, die von einem oder mehr Grafikprozessoren 108 erzeugt ist.
In manchen Ausführungsformen enthält jeder des einen oder der mehr Prozessoren 102 einen oder mehr Prozessorkerne 107, um Befehle zu verarbeiten, die, wenn durchgeführt, Operationen für System und Anwendersoftware ausführen. In manchen Ausführungsformen ist jeder des einen oder der mehr Prozessorkerne 107 konfiguriert, einen spezifischen Befehlssatz 109 zu verarbeiten. In manchen Ausführungsformen kann Befehlssatz 109 komplexe Befehlssatzerrechnung (Complex Instruction Set Computing, CISC), reduzierte Befehlssatzerrechnung (Reduced Instruction Set Computing, RISC) oder Errechnung über ein sehr langes Befehlswort (Very Long Instruction Word, VLIW) erleichtern. Mehrere Prozessorkerne 107 können jeweils einen verschiedenen Befehlssatz 109 verarbeiten, der Befehle enthalten kann, um die Emulation anderer Befehlssätze zu erleichtern. Prozessorkern 107 kann auch andere Verarbeitungsgeräte enthalten, wie einen Digitalsignalprozessor (DSP).
In manchen Ausführungsformen enthält der Prozessor 102 Cachespeicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Stufen interner Caches haben. In manchen Ausführungsformen ist der Cachespeicher unter unterschiedlichen Komponenten des Prozessors 102 geteilt. In manchen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z.B. einen Stufe 3 (L3) Cache oder Letzte-Stufe-Cache (Last Level Cache, LLC)) (nicht gezeigt), der unter Prozessorkernen 107 unter Verwendung bekannter Cachekohärenztechniken geteilt sein kann. Eine Registerdatei 106 ist zusätzlich in Prozessor 102 enthalten, die verschiedene Typen von Registern enthalten kann, um verschiedene Typen von Daten zu speichern (z.B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Befehlszeigerregister) . Manche Register können Allzweckregister sein, während andere Register spezifisch für die Gestaltung des Prozessors 102 sein können.
In manchen Ausführungsformen ist Prozessor 102 mit einem Prozessorbus 110 gekoppelt, um Kommunikationssignale, wie eine Adresse, Daten oder Steuersignale zwischen Prozessor 102 und anderen Komponenten in System 100 zu übertragen. In einer Ausführungsform verwendet das System 100 eine beispielhafte „Hub“-Systemarchitektur, die einen Speichersteuerhub 116 und einen Eingang Ausgang (Input Output, I/O) Steuerhub 130 enthält. Ein Speichersteuerhub 116 erleichtert Kommunikation zwischen einem Speichergerät und anderen Komponenten von System 100, während ein I/O-Steuerhub (I/O Controller Hub, ICH) 130 Verbindungen mit I/O-Geräten über einen lokalen I/O-Bus bereitstellt. In einer Ausführungsform ist die Logik des Speichersteuerhub 116 innerhalb des Prozessors integriert.
Speichergerät 120 kann ein dynamisches Direktzugriffspeicher- (Dynamic Random Access Memory, DRAM) Gerät, ein statisches Direktzugriffspeicher-(Static Random Access Memory, SRAM) Gerät, Flashspeichergerät, Phasenänderungsspeichergerät oder ein anderes Speichergerät mit geeigneter Leistung, um als Prozessspeicher zu dienen, sein. In einer Ausführungsform kann das Speichergerät 120 als Systemspeicher für das System 100 arbeiten, um Daten 122 und Befehle 121 zur Verwendung, wenn der eine oder die mehr Prozessoren 102 eine Anwendung oder einen Prozess durchführen, zu speichern. Speichersteuerhub 116 koppelt sich auch mit einem optionalen externen Grafikprozessor 112, der mit dem einen oder den mehr Grafikprozessoren 108 in Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen auszuführen.
In manchen Ausführungsformen ermöglicht der ICH 130 Peripheriegeräte, sich mit Speichergerät 120 und Prozessor 102 über einen Hochgeschwindigkeits-I/O-Bus zu verbinden. Die I/O-Peripheriegeräte enthalten, sind aber nicht begrenzt auf, eine Audiosteuerung 146, eine Firmwareschnittstelle 128, einen drahtlosen Sendeempfänger 126 (z.B. Wi-Fi, Bluetooth), ein Datenspeichergerät 124 (z.B. Festplatte, Flashspeicher usw.) und eine Legacy-I/O-Steuerung 140 zum Koppeln etablierter (z.B. Personal System 2 (PS/2)) Geräte an das System. Ein oder mehr Universal Serial Bus (USB) Steuerungen 142 verbinden Eingangsgeräte, wie Tastatur- und Maus- 144 Kombinationen. Eine Netzwerksteuerung 134 kann sich auch mit ICH 130 koppeln. In manchen Ausführungsformen koppelt eine Hochleistungs-Netzwerksteuerung (nicht gezeigt) sich mit Prozessorbus 110. Es wird begrüßt werden, dass das gezeigte System 100 beispielhaft und nicht begrenzend ist, da andere Typen von Datenverarbeitungssystemen, die verschieden konfiguriert sind, auch verwendet werden können. Zum Beispiel kann der I/O-Steuerhub 130 innerhalb des einen oder der mehr Prozessoren 102 integriert sein, oder der Speichersteuerhub 116 und I/O-Steuerhub 130 können in einen diskreten externen Grafikprozessor, wie den externen Grafikprozessor 112, integriert sein.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200 mit einem oder mehr Prozessorkernen 202A-202N, einer integrierten Speichersteuerung 214 und einem integrierten Grafikprozessor 208. Diese Elemente von 2 haben dieselben Bezugsnummern (oder -namen), da die Elemente jeder anderen Figur hierin auf jede Weise arbeiten oder fungieren können, ähnlich der, die hierin an anderer Stelle beschrieben ist, aber nicht auf diese begrenzt sind. Prozessor 200 kann zusätzliche Kerne bis zu und einschließlich zusätzlichem Kern 202N enthalten, der durch die strichlierten Kästchen dargestellt ist. In manchen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf eine oder mehr geteilte Cacheeinheiten 206.
Die internen Cacheeinheiten 204A-204N und geteilten Cacheeinheiten 206 stellen eine Cachespeicherhierarchie innerhalb des Prozessors 200 dar. Die Cachespeicherhierarchie kann mindestens eine Stufe von Befehls- und Datencache innerhalb jedes Prozessorkerns und eine oder mehr Stufen von geteiltem Mittelstufencache, wie ein Stufe 2 (L2), Stufe 3 (L3), Stufe 4 (L4) oder andere Stufen von Cache enthalten, wo die höchste Stufe von Cache vor externem Speicher als der LLC klassifiziert ist. In manchen Ausführungsformen behält Cachekohärenzlogik eine Kohärenz zwischen den unterschiedlichen Cacheeinheiten 206 und 204A-204N bei.
In manchen Ausführungsformen kann Prozessor 200 auch einen Satz von einer oder mehr Bussteuereinheiten 216 und einen Systemagentenkern 210 enthalten. Die eine oder mehr Bussteuereinheiten 216 verwalten einen Satz peripherer Busse, wie einen oder mehr Peripheral Component Interconnect-Busse (Peripheriekomponentenzwischenverbindungsbusse, z.B. PCI, PCI Express). Systemagentenkern 210 stellt Verwaltungsfunktionalität für die unterschiedlichen Prozessorkomponenten bereit. In manchen Ausführungsformen enthält der Systemagentenkern 210 eine oder mehr integrierte Speichersteuerungen 214, um Zugriff auf unterschiedliche externe Speichergeräte (nicht gezeigt) zu verwalten.
In manchen Ausführungsformen enthalten ein oder mehr der Prozessorkerne 202A-202N Unterstützung für zeitgleiches Multithreading. In solch einer Ausführungsform enthält der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben von Kernen 202A-202N, während multi-gethreadeter Verarbeitung. Systemagentenkern 210 kann zusätzlich eine Leistungssteuereinheit (Power Control Unit, PCU) enthalten, die Logik und Komponenten enthält, um den Leistungszustand von Prozessorkernen 202A-202N und Grafikprozessor 208 zu regulieren.
In manchen Ausführungsformen enthält Prozessor 200 zusätzlich Grafikprozessor 208, um Grafikverarbeitungsoperationen durchzuführen. In manchen Ausführungsformen koppelt sich der Grafikprozessor 208 mit dem Satz geteilter Cacheeinheiten 206 und dem Systemagentenkern 210, enthaltend die eine oder mehr integrierten Speicherschaltungen 214. In manchen Ausführungsformen ist eine Anzeigesteuerung 211 mit dem Grafikprozessor 208 gekoppelt, um Grafikprozessorausgang an ein oder mehr gekoppelte Anzeigen zu treiben. In manchen Ausführungsformen kann Anzeigesteuerung 211 ein separates Modul sein, das mit dem Grafikprozessor über mindestens eine Zwischenverbindung gekoppelt ist, oder kann innerhalb des Grafikprozessors 208 oder Systemagentenkerns 210 integriert sein.
In manchen Ausführungsformen wird eine ringbasierte Zwischenverbindungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Eine alternative Zwischenverbindungseinheit kann jedoch verwendet werden, wie eine Punkt-zu-Punkt-Zwischenverbindung, eine geschaltete Zwischenverbindung oder andere Techniken, enthaltend nach dem Stand der Technik wohlbekannte Techniken. In manchen Ausführungsformen koppelt Grafikprozessor 208 sich mit der Ringzwischenverbindung 212 über einen I/O-Link 213.
Der beispielhafte I/O-Link 213 stellt mindestens eine von mehreren Varianten von I/O-Zwischenverbindungen dar, enthaltend eine I/O-Zwischenverbindung auf einem Package, die Kommunikation zwischen unterschiedlichen Prozessorkomponenten und einem eingebetteten Hochleistungsspeichermodul 218, wie einem eDRAM-Modul, erleichtert. In manchen Ausführungsformen verwenden jeder der Prozessorkerne 202-202N und Grafikprozessor 208 eingebettete Speichermodule 218 als einen geteilten Letzte-Stufe-Cache.
In manchen Ausführungsformen sind Prozessorkerne 202A-202N homogene Kerne, die dieselbe Befehlssatzarchitektur durchführen. In einer anderen Ausführungsform sind Prozessorkerne 202A-202N im Sinne der Befehlssatzarchitektur (Instruction Set Architecture, ISA) heterogen, wo ein oder mehr Prozessorkerne 202A-N einen ersten Befehlssatz durchführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Befehlssatzes oder einen verschiedenen Befehlssatz durchführt. In einer Ausführungsform sind Prozessorkerne 202A-202N im Sinne der Mikroarchitektur heterogen, wo ein oder mehr Kerne mit einem relativ hohen Leistungsverbrauch sich mit einem oder mehr Leistungskernen mit einem niedrigeren Leistungsverbrauch koppeln. Zusätzlich kann Prozessor 200 auf einem oder mehr Chips oder als ein SoCintegrierter Schaltkreis mit den veranschaulichten Komponenten, zusätzlich zu anderen Komponenten, implementiert sein.
3 ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen integriert ist. In manchen Ausführungsformen kommuniziert der Grafikprozessor über eine Speicher-gemappte I/O-Schnittstelle mit Registern auf dem Grafikprozessor und mit Kommandos, die im Prozessorspeicher platziert sind. In manchen Ausführungsformen enthält der Grafikprozessor 300 eine Speicherschnittstelle 314 zum Zugriffsspeicher. Speicherschnittstelle 314 kann eine Schnittstelle zu lokalem Speicher, einem oder mehr internen Caches, einem oder mehr geteilten externen Caches und/oder Systemspeicher sein.
In manchen Ausführungsformen enthält Grafikprozessor 300 auch eine Anzeigesteuerung 302, um Anzeigeausgangsdaten an ein Anzeigegerät 320 zu treiben. Anzeigesteuerung 302 enthält Hardware für eine oder mehr Überlagerungsebenen für die Anzeige und Zusammensetzung mehrerer Schichten von Video oder Anwenderschnittstellenelementen. In manchen Ausführungsformen enthält Grafikprozessor 300 eine Videocodec-Engine 306, um Medien zu, von oder zwischen einem oder mehr Mediencodierungsformaten zu codieren, decodieren oder transcodieren, enthaltend, aber nicht begrenzt auf. Moving Picture Experts Group (MPEG) Formate, wie MPEG-2, Advanced Video Coding (AVC) Formate, wie H.264/MPEG-4 AVC, wie auch die Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und Joint Photographic Experts Group (JPEG) Formate, wie JPEG, und Motion JPEG (MJPEG) Formate.
In manchen Ausführungsformen enthält Grafikprozessor 300 eine Blockbildübermittlungs- (Block Image Transfer, BLIT) Engine 304, um zweidimensionale (2D) Rasteroperationen auszuführen, enthaltend zum Beispiel Bitrand-Blockübermittlungen. In einer Ausführungsform werden 2D-Grafikoperationen jedoch unter Verwendung einer oder mehr Komponenten von Grafikverarbeitungs-Engine (Graphics Processing Engine, GPE) 310 ausgeführt. In manchen Ausführungsformen ist Grafikverarbeitungs-Engine 310 eine Rechen-Engine zum Ausführen von Grafikoperationen, enthaltend dreidimensionale (3D) Grafikoperationen und Medienoperationen.
In manchen Ausführungsformen enthält GPE 310 eine 3D-Pipeline 312 zum Ausführen von 3D-Operationen, wie Rendern von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen (z.B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 312 enthält programmierbare und fixierte Funktionselemente, die unterschiedliche Aufgaben innerhalb des Elements ausführen und/oder Durchführungsthreads auf einem 3D/Medienteilsystem 315 hervorbringen. Während 3D-Pipeline 312 verwendet werden kann Medienoperationen auszuführen, enthält eine Ausführungsform von GPE 310 auch eine Medienpipeline 316, die spezifisch verwendet wird, um Medienoperationen auszuführen, wie Videonachbearbeitung und Bildqualitätsverbesserung.
In manchen Ausführungsformen enthält Medienpipeline 316 fixierte Funktions- oder programmierbare Logikeinheiten, um eine oder mehr spezialisierte Medienoperationen auszuführen, wie Videodecodierungsbeschleunigung, Videoentflechtung und Videocodierungsbeschleunigung anstatt oder an Stelle von Videocodec-Engine 306. In manchen Ausführungsformen enthält Medienpipeline 316 zusätzlich eine Threadhervorbringungseinheit, um Threads zur Durchführung auf 3D/Medienteilsystem 315 hervorzubringen. Die hervorgebrachten Threads führen Berechnungen für die Medienoperationen auf einer oder mehr Grafikdurchführungseinheiten aus, die in 3D/Medienteilsystem 315 enthalten sind.
In manchen Ausführungsformen enthält 3D/Medienteilsystem 315 Logik zum Durchführen von Threads, die durch 3D-Pipeline 312 und Medienpipeline 316 hervorgebracht werden. In einer Ausführungsform senden die Pipelines Threaddurchführungsanfragen an 3D/Medienteilsystem 315, das Threadeinplanungslogik zum Schlichten und Einplanen der unterschiedlichen Anfragen für verfügbare Threaddurchführungsressourcen enthält. Die Durchführungsressourcen enthalten ein Array von Grafikdurchführungseinheiten, um die 3D- und Medienthreads zu verarbeiten. In manchen Ausführungsformen enthält 3D/Medienteilsystem 315 einen oder mehr interne Caches für Threadbefehle und Daten. In manchen Ausführungsformen enthält das Teilsystem auch geteilten Speicher, enthaltend Register und adressierbaren Speicher, um Daten zwischen Threads zu teilen und Ausgangsdaten zu speichern.
D/Medienverarbeitung
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors in Übereinstimmung mit manchen Ausführungsformen. In einer Ausführungsform ist die GPE 410 eine Version der in 3 gezeigten GPE 310. Elemente von 4 haben dieselben Bezugsnummern (oder -namen), da die Elemente von jeder anderen Figur hierin auf jede Weise arbeiten oder fungieren können, ähnlich der, die hierin an anderer Stelle beschrieben ist, aber nicht auf diese begrenzt sind.
In manchen Ausführungsformen koppelt sich GPE 410 mit einem Kommandostreamer 403, der einen Kommandostream an die GPE 3D- und Medienpipelines 412, 416 bereitstellt. In manchen Ausführungsformen ist Kommandostreamer 403 mit Speicher gekoppelt, der ein Systemspeicher sein kann, oder einem oder mehr von internem Cachespeicher und geteiltem Cachespeicher. In manchen Ausführungsformen empfängt Kommandostreamer 403 Kommandos vom Speicher und sendet die Kommandos an 3D-Pipeline 412 und/oder Medienpipeline 416. Die Kommandos sind Anweisungen, die von einem Ringpuffer abgerufen werden, der Kommandos für die 3D- und Medienpipelines 412, 416 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Stapelkommandopuffer enthalten, die Stapel mehrerer Kommandos speichern. Die 3D- und Medienpipelines 412, 416 verarbeiten die Kommandos durch Ausführen von Operationen über Logik innerhalb der jeweiligen Pipelines oder durch Einplanen eines oder mehrerer Durchführungsthreads für ein Durchführungseinheit-Array 414. In manchen Ausführungsformen ist Durchführungseinheit-Array 414 derart skalierbar, dass das Array eine variable Zahl an Durchführungseinheit enthält, basierend auf der Zielleistung und Arbeitsleistungsstufe von GPE 410.
In manchen Ausführungsformen koppelt eine Abtastungs-Engine 430 sich mit Speicher (z.B. Cachespeicher oder Systemspeicher) und Durchführungseinheit-Array 414. In manchen Ausführungsformen stellt Abtastungs-Engine 430 einen Speicherzugriffsmechanismus für Durchführungseinheit-Array 414 bereit, der Durchführungs-Array 414 erlaubt, Grafik- und Mediendaten von Speicher zu lesen. In manchen Ausführungsformen enthält Abtastungs-Engine 430 Logik, um spezialisierte Bildabtastungsoperationen für Medien auszuführen.
In manchen Ausführungsformen enthält die spezialisierte Medienabtastungslogik in Abtastungs-Engine 430 ein Entrauschungs-/Entflechtungsmodul 432, ein Bewegungsschätzungsmodul 434 und ein Bildskalierungs- und Filterungsmodul 436. In manchen Ausführungsformen enthält Entrauschungs-/Entflechtungsmodul 432 Logik, um einen oder mehr eines Entrauschungs- oder einen Entflechtungsalgorithmus an decodierten Videodaten auszuführen. Die Entflechtungslogik kombiniert abwechselnde Felder von verflochtenem Videoinhalt in einen einzelnen Ruhm von Video. Die Entrauschungslogik verringert oder entfernt Datenrauschen von Video- und Bilddaten. In manchen Ausführungsformen sind die Entrauschungslogik und die Entflechtungslogik bewegungsadaptiv und verwenden räumliches oder temporäres Filtern, basierend auf dem Ausmaß an Bewegung, das in den Videodaten erfasst wird. In manchen Ausführungsformen enthält das Entrauschungs-/Enflechtungsmodul 432 dedizierte Bewegungserfassungslogik (z.B. innerhalb der Bewegungsschätzungs-Engine 434).
In manchen Ausführungsformen stellt Bewegungsschätzungs-Engine 434 Hardwarebeschleunigung für Videooperationen durch Ausführen von Videobeschleunigungsfunktionen bereit, wie Bewegungsvektorschätzung und Vorhersage von Videodaten. Die Bewegungsschätzungs-Engine ermittelt Bewegungsvektoren, die die Transformation von Bilddaten zwischen aufeinanderfolgenden Videoframes beschreiben. In manchen Ausführungsformen verwendet ein Grafikprozessor-Mediencodec Videobewegungsschätzungs-Engine 434, um Operationen an Video bei der Makroblockstufe auszuführen, die ansonsten zu rechenintensiv wären, um mit einem Allzweckprozessor zu funktionieren. In manchen Ausführungsformen ist Bewegungsschätzungs-Engine 434 im Allgemeinen Grafikprozessorkomponenten verfügbar, um beim Videodecodieren und bei Verarbeitungsfunktionen zu assistieren, die für die Richtung oder Magnitude der Bewegung innerhalb von Videodaten sensibel oder adaptiv sind.
In manchen Ausführungsformen führt Bildskalierungs- und Filterungsmodul 436 Bildverarbeitungsoperationen aus, um die visuelle Qualität von erzeugten Bildern und Video zu verbessern. In manchen Ausführungsformen verarbeitet Skalierungs- und Filterungsmodul 436 Bild- und Videodaten während der Abtastungsoperation, bevor sie die Daten an Durchführungseinheit-Array 414 bereitstellt.
In manchen Ausführungsformen enthält die GPE 410 einen Datenanschluss 444, der einen zusätzlichen Mechanismus für Grafikteilsysteme bereitstellt, um auf Speicher zuzugreifen. In manchen Ausführungsformen erleichtert Datenanschluss 444 Speicherzugriff für Operationen, enthaltend Renderzielschreibvorgänge, konstante Pufferlesungen, Notizblockspeicherplatzlesungen/-schreibvorgänge und Medienflächenzugriffe. In manchen Ausführungsformen enthält Datenanschluss 444 Cachespeicherplatz, um Zugriffe auf Speicher zu cachen. Der Cachespeicher kann ein einzelner Datencache sein oder in mehrere Caches für die mehreren Teilsysteme, die über den Datenanschluss auf Speicher zugreifen, separiert sein (z.B. ein Renderpuffercache, ein konstanter Puffercache usw.). In manchen Ausführungsformen kommunizieren Threads, die auf einer Durchführungseinheit in Durchführungseinheit-Array 414 ablaufen, mit dem Datenanschluss durch Austauschen von Nachrichten über eine Datenverteilungszwischenverbindung, die jedes der Teilsysteme von GPE 410 koppelt.
Durchführungseinheiten
5 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 500. Elemente von 5 haben dieselben Bezugsnummern (oder - namen), da die Elemente von jeder anderen Figur hierin auf jede Weise arbeiten oder fungieren können, ähnlich der, die hierin an anderer Stelle beschrieben ist, aber nicht auf diese begrenzt sind.
In manchen Ausführungsformen enthält Grafikprozessor 500 eine Ringzwischenverbindung 502, ein Pipeline-Frontend 504, eine Medien-Engine 537 und Grafikkerne 580A-580N. In manchen Ausführungsformen koppelt Ringzwischenverbindung 502 den Grafikprozessor mit anderen Verarbeitungseinheiten, enthaltend andere Grafikprozessoren oder einen oder mehr Allzweckprozessorkerne. In manchen Ausführungsformen ist der Grafikprozessor einer von vielen Prozessoren, die innerhalb eines Mehrkernverarbeitungssystems integriert sind.
In manchen Ausführungsformen empfängt Grafikprozessor 500 Stapel von Kommandos über Ringzwischenverbindung 502. Die eingehenden Kommandos werden durch einen Kommandostreamer 503 im Pipeline-Frontend 504 interpretiert. In manchen Ausführungsformen enthält Grafikprozessor 500 skalierbare Durchführungslogik, um 3D-Geometrieverarbeitung und Medienverarbeitung über den (die) Grafikkern(e) 580A-580N auszuführen. Für 3D-Geometrieverarbeitungskommandos leitet Kommandostreamer 503 Kommandos zu Geometriepipeline 536. Für mindestens manche Medienverarbeitungskommandos leitet Kommandostreamer 503 die Kommandos an ein Video-Frontend 534, das sich mit einer Medien-Engine 537 koppelt. In manchen Ausführungsformen enthält Medien-Engine 537 eine Videoqualitäts-Engine (VQE) 530 für Video- und Bildnachbearbeitung und eine Mehrformat-Codierungs-/Decodierungs- (Multi-Format Encode/Decode, MFX) 533 Engine, um hardwarebeschleunigte Mediendatencodierung und -decodierung bereitzustellen. In manchen Ausführungsformen erzeugen Geometriepipeline 536 und Medien-Engine 537 jeweils Durchführungsthreads für die Threaddurchführungsressourcen, die von mindestens einem Grafikkern 580A bereitgestellt werden.
In manchen Ausführungsformen enthält Grafikprozessor 500 skalierbare Threaddurchführungsressourcen, die sich durch modulare Kerne 580A-580N auszeichnen (manchmal als Kern-stück bezeichnet), wobei jeder mehrere Teilkerne 550A-550N, 560A-560N hat (manchmal als Kernteilstücke bezeichnet). In manchen Ausführungsformen kann Grafikprozessor 500 irgendeine Zahl von Grafikkernen 580A bis 580N haben. In manchen Ausführungsformen enthält Grafikprozessor 500 einen Grafikkern 580A mit mindestens einem ersten Teilkern 550A und einem zweiten Kern-Teilkern 560A. In anderen Ausführungsformen ist der Grafikprozessor ein Niederleistungsprozessor mit einem einzelnen Teilkern (z.B. 550A). In manchen Ausführungsformen enthält Grafikprozessor 500 mehrere Grafikkerne 580A-580N, jeder einen Satz erster Teilkerne 550A-550N und einen Satz zweiter Teilkerne 560A-560N enthaltend. Jeder Teilkern im Satz erster Teilkerne 550A-550N enthält mindestens einen ersten Satz von Durchführungseinheiten 552A-552N und Medien-/Texturabtastern 554A-554N. Jeder Teilkern im Satz zweiter Teilkerne 560A-560N enthält mindestens einen zweiten Satz von Durchführungseinheiten 562A-562N und Abtastern 564A-564N. In manchen Ausführungsformen teilt sich jeder Teilkern 550A-550N, 560A-560N einen Satz geteilter Ressourcen 570A-570N. In manchen Ausführungsformen enthalten die geteilten Ressourcen geteilten Cachespeicher und Pixeloperationslogik. Andere geteilte Ressourcen können auch in den unterschiedlichen Ausführungsformen des Grafikprozessors enthalten sein.
6 veranschaulicht Threaddurchführungslogik 600, die ein Array von Verarbeitungselementen enthält, die in manchen Ausführungsformen einer GPE eingesetzt werden. Elemente von 6 haben dieselben Bezugsnummern (oder - namen), da die Elemente von jeder anderen Figur hierin auf jede Weise arbeiten oder fungieren können, ähnlich der, die hierin an anderer Stelle beschrieben ist, aber nicht auf diese begrenzt sind.
In manchen Ausführungsformen enthält Threaddurchführungslogik 600 einen Pixelshader 602, einen Threadeinplaner 604, Befehlscache 606, ein skalierbares Durchführungseinheit-Array, enthaltend mehrere Durchführungseinheiten 608A-608N, einen Abtaster 610, einen Datencache 612 und einen Datenanschluss 614. In einer Ausführungsform sind die enthaltenen Komponenten über ein Zwischenverbindungs-Fabric zwischenverbunden, das jede der Komponenten verlinkt. In manchen Ausführungsformen enthält Threaddurchführungslogik 600 eine oder mehr Verbindungen mit Speicher, wie Systemspeicher oder Cachespeicher, durch einen oder mehr von Befehlscache 606, Datenanschluss 614, Abtaster 610 und Durchführungseinheit-Array 608A-608N. In manchen Ausführungsformen ist jede Durchführungseinheit (z.B. 608A) ein individueller Vektorprozessor, der fähig ist, mehrere zeitgleiche Threads durchzuführen und mehrere Datenelemente parallel für jeden Thread zu verarbeiten. In manchen Ausführungsformen enthält Durchführungseinheit-Array 608A-608N irgendeine Zahl individueller Durchführungseinheiten.
In manchen Ausführungseinheiten wird Durchführungseinheit-Array 608A-608N primär dafür verwendet, „Shader“-Programme durchzuführen. In manchen Ausführungsformen führen die Durchführungseinheiten in Array 608A-608N einen Befehlssatz durch, der native Unterstützung für viele Standard-3D-Grafiksshaderbefehle enthält, sodass Shaderprogramme von Grafikbibliotheken (z.B. Direct 3D und OpenGL) mit einer minimalen Übersetzung durchgeführt werden. Die Durchführungseinheiten unterstützen Scheitelpunkt- und Geometrieverarbeitung (z.B. Scheitelpunktprogramme, Geometrieprogramme, Scheitelpunktshader), Pixelverarbeitung (z.B. Pixelshader, Fragmentshader) und Allzweckverarbeitung (z.B. Rechnungs- und Medienshader).
Jede Durchführungseinheit in Durchführungseinheit-Array 608A-608N arbeitet auf Arrays von Datenelementen. Die Zahl an Datenelementen ist die „Durchführungsgröße“ oder die Zahl an Kanälen für den Befehl. Ein Durchführungskanal ist eine logische Durchführungseinheit für Datenelementzugriff, Maskierung und Flusssteuerung innerhalb von Befehlen. Die Zahl an Kanälen kann von der Zahl physischer arithmetischer Logikeinheiten (Arithmetic Logic Units, ALUs) oder Gleitkommaeinheiten (Floating Point Units, FPUs) für einen bestimmten Grafikprozessor unabhängig sein. In manchen Ausführungsformen unterstützen Durchführungseinheiten 608A-608N Ganzzahl- und Gleitkommadatentypen.
Der Durchführungseinheitenbefehlssatz enthält Einzelbefehls-Mehrdaten- (Single Instruction Multiple Data, SIMD) Befehle. Die unterschiedlichen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert werden und die Durchführungseinheit wird die unterschiedlichen Elemente basierend auf der Datengröße der Elemente verarbeiten. Zum Beispiel, wenn auf einem 256-Bit weiten Vektor gearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert und die Durchführungseinheit arbeitet auf dem Vektor als vier separate 64-Bit gepackte Datenelemente (Quadword- (QW) Größe-Datenelemente), acht separate 32-Bit gepackte Datenelemente (Doubleword- (DW) Größe-Datenelemente), sechzehn separate 16-Bit gepackte Datenelemente (Word-(W) Größe-Datenelemente) oder zweiunddreißig separate 8-Bit Datenelemente (Byte- (B) Größe Datenelemente). Jedoch sind verschiedene Vektorweiten und Registergrößen möglich.
Ein oder mehr interne Befehlscaches (z.B. 606) sind in der Threaddurchführungslogik 600 enthalten, um Threadbefehle für die Durchführungseinheiten zu cachen. In manchen Ausführungsformen sind ein oder mehr Datencaches (z.B. 612) enthalten, um Threaddaten während Threaddurchführung zu cachen. In manchen Ausführungsformen ist Abtaster 610 enthalten, um Texturabtastung für 3D-Operationen und Medienabtastung für Medienoperationen bereitzustellen. In manchen Ausführungsformen enthält Abtaster 610 spezialisierte Textur- oder Medienabtastungsfunktionalität, um Textur- oder Mediendaten während dem Abtastungsprozess vor Bereitstellen der abgetasteten Daten an eine Durchführungseinheit zu verarbeiten.
Während Durchführung senden die Grafik- und Medienpipelines Threadinitialisierungsanfragen über Threadhervorbringungs- und Einplanungslogik an Threaddurchführungslogik 600. In manchen Ausführungsformen enthält Threaddurchführungslogik 600 einen lokalen Threadeinplaner 604, der Threadinitialisierungsanfragen von den Grafik- und Medienpipelines schlichtet und die angefragten Threads auf einer oder mehr Durchführungseinheiten 608A-608N instanziiert. Zum Beispiel plant die Geometriepipeline (z.B. 536 von 5) Scheitelpunktverarbeitung, Tessellation oder Geometrieverarbeitungsthreads der Threaddurchführungslogik 600 ein (6). In manchen Ausführungsformen kann Threadeinplaner 604 auch Laufzeit-Threadhervorbringungsanfragen von den ablaufenden Shaderprogrammen verarbeiten.
Sobald eine Gruppe von Geometrieobjekten verarbeitet und in Pixeldaten gerastert wurde, wird Pixelshader 602 aufgerufen, um Ausgangsinformationen weiter zu verrechnen und Ergebnisse zu veranlassen, an Ausgangsflächen geschrieben zu werden (z.B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.). In manchen Ausführungsformen berechnet Pixelshader 602 die Werte der unterschiedlichen Scheitelpunktattribute, die über das gerasterte Objekt zu interpolieren sind. In manchen Ausführungsformen führt Pixelshader 602 dann ein über eine Anwendungsprogrammierungsschnittstelle (Application Programming Interface, API) zugeteiltes Pixelshaderprogramm durch. Um das Pixelshaderprogramm durchzuführen, plant Pixelshader 602 Threads einer Durchführungseinheit (z.B. 608A) über Threadeinplaner 604 ein. In manchen Ausführungsformen verwendet Pixelshader 602 Texturabtastungslogik in Abtaster 610 an, um auf Texturdaten in Texturmaps zuzugreifen, die in Speicher gespeichert sind. Arithmetische Operationen auf den Texturdaten und die Eingangsgeometriedaten errechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehr Pixel in einer weiteren Verarbeitung.
In manchen Ausführungsformen stellt der Datenanschluss 614 einen Speicherzugriffsmechanismus für die von Threaddurchführungslogik 600 bereit, um verarbeiteten Daten an Speicher zum Verarbeiten auf einer Grafikprozessorausgangspipeline auszugeben. In manchen Ausführungsformen enthält der Datenanschluss 614 einen oder mehr Cachespeicher (z.B. Datencache 612) oder koppelt sich mit diesen, um Daten für Speicherzugriff über den Datenanschluss zu cachen.
7 ist ein Blockdiagramm, das Grafikprozessorbefehlsformate 700 gemäß mancher Ausführungsformen veranschaulicht. In einer oder mehr Ausführungsformen unterstützen die Grafikprozessordurchführungseinheiten einen Befehlssatz mit Befehlen in mehreren Formaten. Die durchgängig linierten Kästchen veranschaulichen die Komponenten, die im Allgemeinen in einem Durchführungseinheitsbefehl enthalten sind, während die strichlierten Linien Komponenten enthalten, die optional sind oder die nur in einem Teilsatz der Befehle enthalten sind. In manchen Ausführungsformen besteht das beschriebene und veranschaulichte Befehlsformat 700 aus Makrobefehlen, die Befehle sind, die an die Durchführungseinheit geleitet werden, im Gegensatz zu Mikrooperationen, die sich aus Befehlsdecodierung ergeben, sobald der Befehl verarbeitet wird.
In manchen Ausführungsformen unterstützen die Grafikprozessordurchführungseinheiten nativ Befehle in einem 128-Bit Format 710. Ein 64-Bit verdichtetes Befehlsformat 730 ist für manche Befehle verfügbar, basierend auf dem ausgewählten Befehl, den Befehlsoptionen und der Zahl an Operanden. Das native 128-Bit Format 71 stellt Zugriff auf alle Befehlsoptionen bereit, während manche Optionen und Operationen im 64-Bit Format 730 beschränkt sind. Die nativen Befehle, die im 64-Bit Format 730 verfügbar sind, variieren je nach Ausführungsform. In manchen Ausführungsformen ist der Befehl zum Teil unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 verdichtet. Die Durchführungseinheitshardware referenziert einen Satz von Verdichtungstabellen, basierend auf den Indexwerten, und verwendet die Verdichtungstabellenausgänge, um einen nativen Befehl im 128-Bit Format 710 zu rekonstruieren.
Für jedes Format definiert Befehlsopcode 712 die Operation, die die Durchführungseinheit ausführen wird. Die Durchführungseinheiten führen jeden Befehl parallel über die mehreren Datenelemente von jedem Operanden durch. Zum Beispiel führt in Antwort auf einen Addierbefehl die Durchführungseinheit eine zeitgleiche Addieroperation über jeden Farbkanal aus, der ein Texturelement oder Bildelement darstellt. Standardmäßig führt die Durchführungseinheit jeden Befehl über alle Datenkanäle der Operanden aus. In manchen Ausführungsformen ermöglicht Befehlssteuerfeld 714 Steuerung über gewisse Durchführungsoptionen, wie Kanalauswahl (z.B. Aussage) und Datenkanalreihung (z.B. Durchmischen). Für 128-Bit Befehle 710 begrenzt ein Exec-Größen-Feld 716 die Zahl von Datenkanälen, die parallel durchgeführt sein werden. In manchen Ausführungsformen ist Exec-Größen-Feld 716 zur Verwendung im 64-Bit kompakten Befehlsformat 730 nicht verfügbar.
Manche Durchführungseinheitenbefehle haben bis zu drei Operanden, enthaltend zwei Quelloperanden, src0 722, src1 722 und ein Ziel 718. In manchen Ausführungsformen unterstützen die Durchführungseinheiten Dualzielbefehle, wo eines der Ziele impliziert ist. Datenmanipulationsbefehle können einen dritten Quelloperanden haben (z.B. SRC2 724), wo der Befehlsopcode 712 die Zahl von Quelloperanden ermittelt. Ein letzter Quelloperand eines Befehls kann ein unmittelbarer (z.B. hartkodierter) Wert sein, der mit dem Befehl übermittelt wird.
In manchen Ausführungsformen enthält das 128-Bit Befehlsformat 710 eine Zugriffs-/Adressierungsmodus-Information 726, die zum Beispiel spezifiziert, ob direkter Registeradressierungsmodus oder indirekter Registeradressierungsmodus verwendet wird. Wenn direkter Registeradressierungsmodus verwendet wird, ist die Registeradresse von einem oder mehr Operanden direkt durch Bits im Befehl 710 bereitgestellt.
In manchen Ausführungsformen enthält das 128-Bit Befehlsformat 710 ein Zugriffs-/Adressierungsmodus-Feld 726, das einen Adressierungsmodus und/oder Zugriffsmodus für den Befehl spezifiziert. In einer Ausführungsform dient der Zugriffsmodus dazu, eine Datenzugriffsausrichtung für den Befehl zu definieren. Manche Ausführungsformen unterstützen Zugriffsmodi, enthaltend einen 16-Byte ausgerichteten Zugriffsmodus und einen 1-Byte ausgerichteten Zugriffsmodus, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Befehlsoperanden ermittelt. Zum Beispiel kann in einem ersten Modus der Befehl 710 Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden und in einem zweiten Modus kann der Befehl 710 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform ermittelt der Adressierungsmodus-Abschnitt des Zugriffs-/Adressierungsmodus-Felds 726, ob der Befehl direkte oder indirekte Adressierung verwenden soll. Wenn direkter Registeradressierungsmodus verwendet wird, stellen Bits im Befehl 710 direkt die Registeradressierung von einem oder mehr Operanden bereit. Wenn indirekter Registeradressierungsmodus verwendet wird, kann die Registeradressierung von einem oder mehr Operanden basierend auf einem Adressierungsregisterwert und einem Adressierungsimmediatfeld im Befehl errechnet werden.
In manchen Ausführungsformen werden Befehle basierend auf Opcode 712 Bit-Feldern gruppiert, um Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit Opcode erlauben Bits 4, 5 und 6 der Durchführungseinheit den Typ von Opcode zu ermitteln. Die gezeigte präzise Opcodegruppierung ist bloß ein Beispiel. In manchen Ausführungsformen enthält eine Bewegungs- und Logik-Opcodegruppe 742 Datenbewegungs- und Logikbefehle (z.B. Bewegen (move, mov), Vergleichen (compare, cmp)). In manchen Ausführungsformen teilt Bewegungs- und Logikgruppe 742 die fünf hochwertigsten Bits (Most Significant Bits, MSB), wo Bewegen- (mov) Befehle in der Form von 0000xxxxb sind und Logikbefehle in der Form von 0001xxxxb sind. Eine Flusssteuerbefehlsgruppe 744 (z.B. Aufrufen, Springen (jump, jmp) enthält Befehle in der Form von 0010xxxxb (z.B. 0x20). Eine Sonstiger-Befehl-Gruppe 746 enthält einen Mix aus Befehlen, enthaltend Synchronisationsbefehle (z.B. Warten, Senden) in der Form von 0011xxxxb (z.B. 0x30). Eine Parallele-Mathematikbefehl-Gruppe 748 enthält komponentenweise arithmetische Befehle (z.B. Addieren, Multiplizieren (mul)) in der Form von 0100xxxxb (z.B. 0x40). Die Parallele-Mathematikgruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle aus. Die Vektor-Mathematikgruppe 750 enthält arithmetische Befehle (z.B. dp4) in der Form von 0101xxxxb (z.B. 0×50). Die Vektor-Mathematikgruppe führt Arithmetik aus, wie Skalarproduktberechnungen auf Vektoroperanden.
Grafikpipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente von 8 haben dieselben Bezugsnummern (oder - namen), da die Elemente von jeder anderen Figur hierin auf jede Weise arbeiten oder fungieren können, ähnlich der, die hierin an anderer Stelle beschrieben ist, aber nicht auf diese begrenzt sind.
In manchen Ausführungsformen enthält Grafikprozessor 800 eine Grafikpipeline 820, eine Medienpipeline 830, eine Anzeige-Engine 840, Threaddurchführungslogik 850 und eine Renderausgangspipeline 870. In manchen Ausführungsformen ist Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkernverarbeitungssystems, das einen oder mehr Allzweckverarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehr Steuerregister (nicht gezeigt) oder über Kommandos, die über eine Ringzwischenverbindung 802 an Grafikprozessor 800 ausgestellt sind, gesteuert. In manchen Ausführungsformen koppelt Ringzwischenverbindung 802 Grafikprozessor 800 mit anderen Verarbeitungskomponenten, wie anderen Grafikprozessoren oder Allzweckprozessoren. Kommandos von Ringzwischenverbindung 802 werden durch einen Kommandostreamer 803 interpretiert, der Befehle an individuelle Komponenten von Grafikpipeline 820 oder Medienpipeline 830 leitet.
In manchen Ausführungsformen lenkt Kommandostreamer 803 die Operation eines Scheitelpunktabrufers, der Scheitelpunktdaten aus Speicher liest und Scheitelpunktverarbeitungskommandos durchführt, die von Kommandostreamer 803 bereitgestellt sind. In manchen Ausführungsformen stellt Scheitelpunktabrufer 805 Scheitelpunktdaten an einen Scheitelpunktshader 807 bereit, der Koordinatenraumtransformation und Beleuchtungsoperationen zu jedem Scheitelpunkt ausführt. In manchen Ausführungsformen führen Scheitelpunktabrufer 805 und Scheitelpunktshader 807 Scheitelpunktverarbeitungsbefehle durch Einplanen von Durchführungsthreads über einen Threadeinplaner 831 für Durchführungseinheiten 852A, 852B, durch.
In manchen Ausführungsformen sind Durchführungseinheiten 852A, 852B ein Array von Vektorprozessoren mit einem Befehlssatz zum Ausführen von Grafik- und Medienoperationen. In manchen Ausführungsformen haben Durchführungseinheiten 852A, 852B einen angehängten L1 Cache 851, der für jedes Array spezifisch ist oder zwischen den Arrays geteilt wird. Der Cache kann als ein Datencache, ein Befehlscache oder ein einzelner Cache, der partitioniert ist, Daten und Befehle in verschiedenen Partitionen zu beinhalten, konfiguriert sein.
In manchen Ausführungsformen enthält Grafikpipeline 820 Tessellationskomponenten, um hardwarebeschleunigte Tessellation von 3D-Objekten auszuführen. In manchen Ausführungsformen konfiguriert ein programmierbarer Hüllenshader 811 die Tessellationsoperationen. Ein programmierbarer Domänenshader 817 stellt Backend-Evaluierung von Tessellationsausgang bereit. Ein Tessellator 813 arbeitet bei der Richtung von Hüllenshader 811 und beinhaltet Sonderzwecklogik, um einen Satz detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell zu erzeugen, das als Eingang zu Grafikpipeline 820 bereitgestellt ist. In manchen Ausführungsformen, falls Tessellation nicht verwendet wird, können Tessellationskomponenten 811, 813, 817 umgangen werden.
In manchen Ausführungsformen können vollständige geometrische Objekte von einem Geometrieshader 819 über einen oder mehr Threads verarbeitet werden, die für Durchführungseinheit 852A, 852B eingeplant sind, oder können direkt zum Begrenzer 829 fortfahren. In manchen Ausführungsformen arbeitet der Geometrieshader auf gesamten geometrischen Objekten und nicht auf Scheitelpunkten oder Stellen von Scheitelpunkten wie in vorherigen Stufen der Grafikpipeline. Falls die Tessellation deaktiviert ist, empfängt der Geometrieshader 819 Eingang vom Scheitelpunktshader 807. In manchen Ausführungsformen ist Geometrieshader 819 durch ein Geometrieshaderprogramm programmierbar, um Geometrietessellation auszuführen, falls die Tessellationseinheiten deaktiviert sind.
Vor Rasterung verarbeitet ein Begrenzer 829 Scheitelpunktdaten. Der Begrenzer 829 kann ein fixierter Funktionsbegrenzer oder ein programmierbarer Begrenzer mit Begrenzungs- und Geometrieshaderfunktionen sein. In manchen Ausführungsformen plant eine Rasterungs- und Tiefentestkomponente 873 in der Renderausgangspipeline 870 Pixelshader ein, die geometrischen Objekte in deren Pro-Pixel-Darstellungen zu konvertieren. In manchen Ausführungsformen ist Pixelshaderlogik in Threaddurchführungslogik 850 enthalten. In manchen Ausführungsformen kann eine Anwendung den Raster 873 umgehen und auf ungerasterte Scheitelpunktdaten über eine Ausströmeinheit 823 zugreifen.
Der Grafikprozessor 800 hat ein(en) Zwischenverbindungsbus, Zwischenverbindungs-Fabric oder irgendeinen anderen Zwischenverbindungsmechanismus, der Daten und einer Nachricht einen Durchlauf unter den wichtigsten Komponenten des Prozessors erlaubt. In manchen Ausführungsformen zwischenverbinden sich Durchführungseinheiten 852A, 852B und zugehörige Cache(s) 81, Textur- und Medienabtaster 854 und Textur-/Abtastercache 858 über einen Datenanschluss 856, um Speicherzugriff auszuführen und mit Renderausgangspipelinekomponenten des Prozessors zu kommunizieren. In manchen Ausführungsformen haben Abtaster 854, Caches 851, 858 und Durchführungseinheiten 852A, 852B jeweils separate Speicherzugriffspfade.
In manchen Ausführungsformen beinhaltet Renderausgangspipeline 879 eine Raster- und Tiefentestkomponente 873, die scheitelpunktbasierte Objekte in eine zugehörige pixelbasierte Darstellung umwandelt. In manchen Ausführungsformen enthält die Rasterlogik eine Windower-/Maskereinheit, um fixiertes Funktionsdreieck und Linienrasterung auszuführen. Ein zugehöriger Rendercache 878 und Tiefencache 879 sind in manchen Ausführungsformen auch verfügbar. Eine Pixeloperationskomponente 877 führ pixelbasierte Operationen an den Daten aus, obwohl in manchen Instanzen Pixeloperationen, die 2D-Operationen zugehörig sind (z.B. Bildblockbildübermittlung mit Überlagerung), durch die 2D-Engine 841 ausgeführt werden, oder bei Anzeigezeit durch die Anzeigesteuerung 843 unter Verwendung von Einblendungsanzeigeebenen ersetzt werden. In manchen Ausführungsformen ist ein geteilter L3 Cache 875 allen Grafikkomponenten verfügbar, was das Teilen von Daten ohne die Verwendung von Hauptsystemspeicher erlaubt.
In manchen Ausführungsformen enthält Grafikmedienpipeline 830 eine Medien-Engine 837 und ein Video-Frontend 834. In manchen Ausführungsformen empfängt Video-Frontend 834 Pipelinekommandos vom Kommandostreamer 803. In manchen Ausführungsformen enthält Medienpipeline 830 einen separaten Kommandostreamer. In manchen Ausführungsformen verarbeitet Video-Frontend 834 Medienkommandos, bevor das Kommando an die Medien-Engine 837 gesendet wird. In manchen Ausführungsformen enthält Medien-Engine 337 Threadhervorbringungsfunktionalität, um Threads hervorzubringen, um sie über Threadeinplaner 831 für die Threaddurchführungslogik 850 einzuplanen.
In manchen Ausführungsformen enthält Grafikprozessor 800 eine Anzeige-Engine 840. In manchen Ausführungsformen ist Anzeige-Engine 840 extern von Prozessor 8000 und koppelt sich mit dem Grafikprozessor über die Ringzwischenverbindung 802 oder irgendein(en) andere(n) Zwischenverbindungsbus oder Fabric. In manchen Ausführungsformen enthält Anzeige-Engine 840 eine 2D-Engine 841 und eine Anzeigesteuerung 843. In manchen Ausführungsformen beinhaltet Anzeige-Engine 840 Sonderzwecklogik, die fähig ist, unabhängig der 3D-Pipeline zu arbeiten. In manchen Ausführungsformen koppelt sich Anzeigesteuerung 843 mit einem Anzeigegerät (nicht gezeigt), das ein systemintegriertes Anzeigegerät, wie in einem Laptopcomputer, oder ein externes Anzeigegerät, das über einen Anzeigegerätverbinder angehängt ist, sein kann.
In manchen Ausführungsformen sind Grafikpipeline 820 und Medienpipeline 830 konfigurierbar, um Operationen auszuführen, die auf mehreren Grafik- und Medienprogrammierungsschnittstellen beruhen, und nicht für eine Anwendungsprogrammierungsschnittstelle (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 Kommandos, die vom Grafikprozessor verarbeitet werden können. In manchen Ausführungsformen ist Unterstützung für die Open Graphics Library (OpenGL) und Open Computing Language (OpenCL) von der Khronos Group, die Direct3D Bibliothek der Firma Microsoft bereitgestellt, oder Unterstützung kann für sowohl OpenGL als auch D3D bereitgestellt sein. Unterstützung kann auf für die Open Source Computer Vision Library (OpenCV) bereitgestellt sein. Eine zukünftige API mit kompatibler 3D-Pipeline würde auch unterstützt werden, falls Mapping von der Pipeline der zukünftigen API zur Pipeline des Grafikprozessors getätigt werden könnte.
Grafikpipelineprogrammierung
9A ist ein Blockdiagramm, das ein Grafikprozessorkommandoformat 900 gemäß mancher Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das eine Grafikprozessorkommandosequenz 910 gemäß einer Ausführungsform veranschaulicht. Die durchgängig linierten Kästchen in 9A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikkommando enthalten sind, während die strichlierten Linien Komponenten enthalten, die optional sind oder die nur in einem Teilsatz der Grafikkommandos enthalten sind. Das beispielhafte Grafikprozessorkommandoformat 900 von 9A enthält Datenfelder, um einen Zielclient 902 des Kommandos zu identifizieren, einen Kommandooperationscode (Opcode) 904 und die relevanten Daten 906 für das Kommando. Ein Teilopcode 905 und eine Kommandogröße 908 sind auch in manchen Kommandos enthalten.
In manchen Ausführungsformen spezifiziert Client 902 die Clienteinheit des Grafikgeräts, das die Befehlsdaten verarbeitet. In manchen Ausführungsformen untersucht ein Grafikprozessorkommandosyntaxanalysierer das Clientfeld jedes Kommando, um die weitere Verarbeitung des Kommandos zur Bedingung zu machen und die Kommandodaten an die angemessene Clienteinheit zu leiten. In manchen Ausführungsformen enthalten die Grafikprozessorclienteinheiten eine Speicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Clienteinheit hat eine entsprechende Verarbeitungspipeline, die die Kommandos verarbeitet. Sobald das Kommando von der Clienteinheit empfangen ist, liest die Clienteinheit den Opcode 904 und, falls vorhanden, Teilopcode 905, um die auszuführende Operation zu ermitteln. Die Clienteinheit führt das Kommando unter Verwendung von Informationen im Datenfeld 906 aus. Für manche Kommandos ist eine explizite Kommandogröße 908 erwartet, um die Größe des Kommandos zu spezifizieren. In manchen Ausführungsformen ermittelt der Kommandosyntaxanalysierer automatisch die Größe von mindestens manchen der Kommandos, basierend auf dem Kommandoopcode. In manchen Ausführungsformen werden Kommandos über Vielfaches eines Doubleword ausgerichtet.
Das Flussdiagramm in 9B zeigt eine beispielhafte Grafikprozessorkommandosequenz 910. In manchen Ausführungsformen verwenden Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors mitbringt, eine Version der Kommandosequenz, die gezeigt ist einen Satz von Grafikoperationen einzurichten, durchzuführen und abzuschließen. Eine Abtastkommandosequenz wird nur zu beispielhaften Zwecken gezeigt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Kommandos oder auf diese Kommandosequenz begrenzt sind. Außerdem können die Kommandos als Stapel von Kommandos in einer Kommandosequenz ausgestellt werden, sodass der Grafikprozessor die Sequenz von Kommandos in mindestens teilweiser Gleichzeitigkeit verarbeiten wird.
In manchen Ausführungsformen kann die Grafikprozessorkommandosequenz 910 mit einem Pipelineleerungsbefehl 912 beginnen, um jede aktive Grafikpipeline zu veranlassen, die momentan ausstehenden Kommandos für die Pipeline zu beenden. In manchen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medienpipeline 924 nicht gleichzeitig. Die Pipelineleerung wird ausgeführt, um die aktive Grafikpipeline zu veranlassen, alle ausstehenden Befehle zu beenden. In Antwort auf eine Pipelineleerung wird der Kommandosyntaxanalysierer für den Grafikprozessor eine Kommandoverarbeitung pausieren, bis die aktiven Zeichnung-Engines ausstehende Operationen beenden und die relevanten Lesecaches für ungültig erklärt sind. Optional können alle Daten im Rendercache, die als „schmutzig“ markiert sind, zu Speicher geleert werden. In manchen Ausführungsformen kann Pipelineleerungskommando 912 für Pipelinesynchronisation verwendet werden, oder vor Versetzen des Grafikprozessors in einen Niederleistungszustand.
In manchen Ausführungsformen wird ein Pipelineauswahlkommando 913 verwendet, wenn eine Kommandosequenz den Grafikprozessor benötigt, explizit zwischen Pipelines umzuschalten. In manchen Ausführungsformen wird ein Pipelineauswahlkommando 913 nur einmal innerhalb eines Durchführungskontext benötigt, bevor Pipelinekommandos ausgestellt werden, außer der Kontext ist, Kommandos für beide Pipelines auszustellen. In manchen Ausführungsformen wird ein Pipelineleerungskommando ist 912 unmittelbar vor einem Pipelinewechsel über den Pipelineauswahlkommando 913 benötigt.
In manchen Ausführungsformen konfiguriert ein Pipelinesteuerkommando 914 eine Grafikpipeline zur Operation und wird verwendet, die 3D-Pipeline 922 und die Medienpipeline 924 zu programmieren. In manchen Ausführungsformen konfiguriert Pipelinesteuerkommando 914 den Pipelinezustand für die aktive Pipeline. In einer Ausführungsform wird das Pipelinesteuerkommando 914 für Pipelinesynchronisation verwendet und um Daten aus einem oder mehr Cachespeichern innerhalb der aktiven Pipeline zu beseitigen, bevor ein Stapel von Kommandos verarbeitet wird.
In manchen Ausführungsformen werden Rückkehrpufferzustandskommandos 916 verwendet, um einen Satz von Rückkehrpuffern für die jeweiligen Pipelines zu konfigurieren, Daten zu schreiben. Manche Pipelineoperationen benötigen die Zuteilung, Auswahl oder Konfiguration von einem oder mehr Rückkehrpuffern, in die die Operationen zwischenliegende Daten während Verarbeitung schreiben. In manchen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehr Rückkehrpuffer, um Ausgangsdaten zu speichern und Querthreadkommunikation auszuführen. In manchen Ausführungsformen enthält der Rückkehrpufferzustand 916 Auswählen der Größe und Zahl von Rückkehrpuffern zur Verwendung für einen Satz von Pipelineoperationen.
Die verbleibenden Kommandos in der Kommandosequenz unterschieden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipelineermittlung 920 ist die Kommandosequenz auf die 3D-Pipeline 922 maßgeschneidert, die mit dem 3D-Pipelinezustand 930 beginnt, oder die Medienpipeline 924, die beim Medienpipelinezustand 940 beginnt.
Die Kommandos für den 3D-Pipelinezustand 930 enthalten 3D-Zustandseinstellungskommandos für Scheitelpunktpufferzustand, Scheitelpunktelementzustand, konstanten Farbzustand, Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitivkommandos verarbeitet werden. Die Werte dieser Kommandos werden mindestens teilweise basierend auf der bestimmten 3D-API in Verwendung ermittelt. In manchen Ausführungsformen sind 3D-Pipelinezustand 930 Kommandos auch fähig, selektiv gewisse Pipelineelemente zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
In manchen Ausführungsformen wird 3D-Primitiv 932 Befehl verwendet, um 3D-Primitive einzureichen, di durch die 3D-Pipeline verarbeitet werden. Kommandos und zugehörige Parameter, die über den 3D-Primitiv 032 Befehl an den Grafikprozessor weitergegeben sind, werden an die Scheitelpunktabruffunktion in der Grafikpipeline weitergeleitet. Die Scheitelpunktabruffunktion verwendet die 3D-Primitiv 932 Kommandodaten, um Scheitelpunktdatenstrukturen zu erzeugen. Die Scheitelpunktdatenstrukturen werden in einem oder mehr Rückkehrpuffern gespeichert. In manchen Ausführungsformen wird 3D-Primitv 932 Befehl verwendet, um Scheitelpunktoperationen über Scheitelpunktshader an 3D-Primitiven auszuführen. Um Scheitelpunktshader zu verarbeiten, plant 3D-Pipeline 922 Shaderdurchführungsthreads für Grafikprozessordurchführungseinheiten ein.
In manchen Ausführungsformen wird 3D-Pipeline 922 über ein Durchführungs- 934 Kommando oder Ereignis ausgelöst. In manchen Ausführungsformen löst ein Registerschreibvorgang eine Kommandodurchführung aus. In manchen Ausführungsformen wird eine Durchführung über eine ‚go‘ oder ‚kick‘ Befehl in der Befehlssequenz ausgelöst. In manchen Ausführungsformen wird Kommandodurchführung unter Verwendung eines Pipelinesynchronisationskommandos ausgelöst, um die Kommandosequenz durch die Grafikpipeline zu leeren. Die 3D-Pipeline wird geometrische Verarbeitung für die 3D-Primitive ausführen. Sobald Operationen vollständig sind, werden die resultierenden geometrischen Objekte gerastert und die Pixel-Engine färbt die resultierenden Pixel. Zusätzliche Kommandos zum Steuern von Pixelshading und Pixel-Backend-Operationen können auch für diese Operationen enthalten sein.
In manchen Ausführungsformen folgt die Grafikprozessorkommandosequenz 910 dem Medienpipeline 924 Pfad, wenn Medienoperationen ausgeführt werden. Im Allgemeinen hängt die spezifische Verwendung und Weise vom Programmieren für die Medienpipeline 924 von den Medien- oder Berechnungsoperationen ab, die auszuführen sind. Spezifische Mediendecodierungsoperationen können während Mediendecodierung an die Medienpipeline abgeladen werden. In manchen Ausführungsformen kann die Medienpipeline auch umgangen werden und Mediendecodierung kann im Gesamten oder teilweise unter Verwendung von Ressourcen ausgeführt werden, die von einem oder mehr Allzweckverarbeitungskernen bereitgestellt sind. In einer Ausführungsform kann die Medienpipeline auch Elemente für Allzweckgrafikprozessoreinheit (General-Purpose Graphics Processor Unit, GPGPU) Operationen enthalten, wo der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von rechnenden Shaderprogrammen, die nicht ausdrücklich auf das Rendern von Grafikprimitiven bezogen sind, auszuführen.
In manchen Ausführungsformen ist Medienpipeline 924 auf eine ähnliche Weise konfiguriert, wie die 3D-Pipeline 922. Ein Satz von Medienpipelinezustandskommandos 940 wird vor den Medienobjektkommandos 942 eingeplant oder in eine Kommandoreihe versetzt. In manchen Ausführungsformen enthalten Medienpipelinezustandskommandos 940 Daten, um die Medienpipelineelemente zu konfigurieren, die verwendet werden, um die Medienobjekte zu verarbeiten. Dies enthält Daten, um die Videodecodierungs- und Videocodierungslogik innerhalb der Medienpipeline, wie Codierungs- oder Decodierungsformat, zu konfigurieren. In manchen Ausführungsformen unterstützen Medienpipelinezustandskommandos 940 auch die Verwendung von einem oder mehr Zeigern zu „indirekten“ Zustandselementen, die einen Stapel von Zustandseinstellungen beinhalten.
In manchen Ausführungsformen leiten Medienobjektkommandos 942 Zeiger zu Medienobjekten, zur Verarbeitung durch die Medienpipeline. Die Medienobjekte enthalten Speicherpuffer, die Videodaten beinhalten, die zu verarbeiten sind. In manchen Ausführungsformen müssen alle Medienpipelinezustände gültig sein, bevor ein Medienobjektkommando 942 ausgestellt wird. Sobald der Pipelinezustand konfiguriert ist und Medienobjektkommandos 942 eingereiht sind, wird die Medienpipeline 924 über ein Durchführungskommando 944 oder ein äquivalentes Durchführungsereignis (z.B. Registerschreibvorgang) ausgelöst. Ausgang von Medienpipeline 924 kann durch Operationen nachbearbeitet werden, die durch die 3D-Pipeline 922 oder die Medienpipeline 924 bereitgestellt sind. In manchen Ausführungsformen werden GPGU-Operationen auf ähnliche Weise wie Medienoperationen konfiguriert und durchgeführt.
Grafiksoftwarearchitektur
10 veranschaulicht beispielhafte Softwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß mancher 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 mehr Allzweckkern(e) 1034. Die Grafikanwendung 1010 und Betriebssystem 1020 laufen jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ab.
In manchen Ausführungsformen beinhaltet die 3D-Grafikanwendung 1010 ein oder mehr Shaderprogramme, enthaltend Shaderbefehle 1012. Die Shadersprachenbefehle können in einer Shaderhochsprache sein, wie die High Level Shader Language (HLSL) oder die OpenGL Shader Language (GLSL). Die Anwendung enthält auch durchführbare Befehle 1014 in einer Maschinensprache, die zur Durchführung durch den Allzweckprozessorkern 1034 geeignet ist. Die Anwendung enthält auch Grafikobjekte 1016, die durch Scheitelpunktdaten definiert sind.
In manchen Ausführungsformen ist Betriebssystem 1020 ein Microsoft® Windows® Betriebssystem von der Firma Microsoft, ein proprietäres UNIX-ähnliches Betriebssystem oder ein quelloffenes UNIX-ähnliches Betriebssystem, das eine Variante des Linuxkernel verwendet. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 1020 einen Frontend-Shaderkompilierer 1024, um alle Shaderbefehle 1012 in HLSL in eine Shader niedrigere Shadersprache zu kompilieren. Die Kompilierung kann eine Just-in-time (JIT) Kompilierung sein oder die Anwendung kann Shadervorkompilierung ausführen. In manchen Ausführungsformen werden während der Kompilierung der 3D-Grafikanwendung 1010 hohe Shader in niedere Shader kompiliert.
In manchen Ausführungsformen beinhaltet Anwendermodusgrafiktreiber 1036 einen Backend-Shaderkompilierer 1027, um die Shaderbefehle 1012 in eine hardwarespezifische Darstellung umzuwandeln. Wenn die OpenGL- API verwendet wird, werden Shaderbefehle 1012 in der GLSL-Hochsprache an einen Anwendermodusgrafiktreiber 1026 zur Kompilierung weitergegeben. In manchen Ausführungsformen verwendet Anwendermodusgrafiktreiber 1026 Betriebssystemkernelmodusfunktionen 1028, um mit einem Kernelmodusgrafiktreiber 1029 zu kommunizieren. In manchen Ausführungsformen kommuniziert Kernelmodusgrafiktreiber 1029 mit Grafikprozessor 1032, um Kommandos und Befehle einzuplanen.
IP-Kernimplementierungen
Ein oder mehr Aspekte von mindestens einer Ausführungsform können durch repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, der Logik innerhalb eines integrierten Schaltkreises, wie einem Prozessor, darstellt und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Befehle enthalten, die unterschiedliche Logik innerhalb des Prozessors darstellen. Wenn von einer Maschine gelesen, können die Befehle die Maschine veranlassen, die Logik zu fertigen, um die hierin beschriebenen Techniken auszuführen. Solche Darstellungen, bekannt als „IP-Kerne“, sind wiederverwendbare Einheiten von Logik für einen integrierten Schaltkreis, der auf einem greifbaren, maschinenlesbaren Medium als ein Hardwaremodell gespeichert sein kann, das die Struktur des integrierten Schaltkreises beschreibt. Das Hardwaremodell kann an unterschiedliche Verbraucher oder Herstellungseinrichtungen zur Verfügung gestellt werden, die das Hardwaremodell auf Fertigungsmaschinen laden, die den integrierten Schaltkreis herstellen. Der integrierte Schaltkreis kann derart gefertigt werden, dass der Schaltkreis Operationen ausführt, die in Verbindung mit einer der hierin beschriebenen Ausführungsformen beschrieben werden.
11 ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem 1100 veranschaulicht, das verwendet werden kann, um einen integrierten Schaltkreis herzustellen, um Operationen gemäß einer Ausführungsform auszuführen. Das IP-Kernentwicklungssystem 1100 kann verwendet werden, um modulare wiederverwendbare Gestaltungen zu erzeugen, die in eine größere Gestaltung eingegliedert werden können oder verwendet werden können, einen gesamten integrierten Schaltkreis zu konstruieren (z.B. ein SOCintegrierter Schaltkreis). Eine Gestaltungseinrichtung 1130 kann eine Softwaresimulation 1110 einer IP-Kerngestaltung in einer Programmierhochsprache (z.B. C/C++) erzeugen. Die Softwaresimulation 1110 kann zum Gestalten, Testen und Verifizieren des Verhaltens des IP-Kerns verwendet werden. Eine Registerübermittlungsstufe (Register Transfer Level, RTL) Gestaltung kann dann vom Simulationsmodell 1100 erzeugt oder synthetisiert werden. Die RTL-Gestaltung 1115 ist eine Abstraktion des Verhaltens des integrierten Schaltkreises, der den Fluss eines digitalen Signals zwischen Hardwareregistern modelliert, enthaltend die zugehörige Logik, die unter Verwendung der modellierten digitalen Signale ausgeführt wird. Zusätzlich zu einer RTL-Gestaltung 1115 können niedere Gestaltungen auch bei der Logikstufe oder Transistorstufe erzeugt, gestaltet oder synthetisiert werden. Daher können die bestimmten Details der anfänglichen Gestaltung und Simulation variieren.
Die RTL-Gestaltung 1115 oder ein Äquivalent können weiter durch die Gestaltungseinrichtung in ein Hardwaremodell 1120 synthetisiert werden, das in einer Hardwarebeschreibungssprache (Hardware Description Language, HDL) oder einer anderen Repräsentation von physischen Gestaltungsdaten sein kann. Die HDL kann weiter simuliert oder getestet werden, um die IP-Kerngestaltung zu verifizieren. Die IP-Kerngestaltung kann zur Lieferung an eine Drittanbieterfertigungseinrichtung 1165 unter Verwendung eines nichtflüchtigen Speichers 1140 (z.B. Festplatte, Flashspeicher oder irgendein nichtflüchtiges Datenspeichermedium) gespeichert werden. Alternativ kann die IP-Kerngestaltung über eine festverdrahtete Verbindung 1150 oder drahtlose Verbindung 1160 übertragen werden (z.B. über das Internet). Die Fertigungseinrichtung 1165 kann dann einen integrierten Schaltkreis fertigen, der mindestens teilweise auf der IP-Kerngestaltung basiert. Der gefertigte integrierte Schaltkreis kann konfiguriert sein, Operationen in Übereinstimmung mit mindestens einer hierin beschriebenen Ausführungsform auszuführen.
12 ist ein Blockdiagramm, das eine beispielhafte System-auf-einem-Chip-integrierte Schaltung 1200 gemäß einer Ausführungsform veranschaulicht, die unter Verwendung eines oder mehr IP-Kerne gefertigt werden kann. Der beispielhafte integrierte Schaltkreis enthält einen oder mehr Anwendungsprozessoren 1205 (z.B. CPUs), mindestens einen Grafikprozessor 1210 und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 12120 enthalten, von denen jeder ein modularer IP-Kern von derselben oder mehreren verschiedenen Gestaltungseinrichtungen sein kann. Der integrierte Schaltkreis enthält Peripherie- oder Buslogik, enthaltend eine USB-Steuerung 1225, UART-Steuerung 1230, eine SPI/SDIO-Steuerung 1235 und eine I²S/I²C-Steuerung 1240. Zusätzlich kann der integrierte Schaltkreis ein Anzeigegerät 1245 enthalten, das mit einer oder mehr von einer High-Definition Multimedia Interface (HDMI) Steuerung 1250 und einer Mobile Industry Prozessor Interface (MIPI) Anzeigeschnittstelle 1255 gekoppelt ist. Datenspeicher kann durch ein Flashspeicherteilsystem 1260 bereitgestellt sein, das Flashspeicher und eine Flashspeichersteuerung enthält. Speicherschnittstelle kann über eine Speichersteuerung 1265 für Zugriff auf SDREAM oder SRAM Speichergeräte bereitgestellt sein. Manche integrierte Schaltkreise enthalten zusätzlich eine eingebettete Sicherheits-Engine 1270.
Zusätzlich können andere Logik und Schaltkreise im Prozessor von integriertem Schalkreis 1200 enthalten sein, enthaltend zusätzliche Grafikprozessoren/kerne, Peripherieschnittstellensteuerungen oder Allzweckprozessorkerne.
VERFAHREN UND VORRICHTUNG ZUM IDENTIFIZIEREN DES JEWEILS NÄCHSTEN STRAHL-FLÄCHEN-SCHNITTPUNKTS INNERHALB EINER RAYTRACING-ARCHITEKTUR
EINFÜHRUNG
In seiner grundlegenden Form bezieht sich Raytracing auf einen Satz von Algorithmen oder Kernels, die verschiedenen Arten von Anwendungen erlauben zu ermitteln, welche(s) - oder ob überhaupt welche - geometrische(n) Primitiv(e) entlang der „Sichtlinie“ eines gegebenen „Strahls“ R liegen, wo der Strahl R typischerweise als eine direkte Linie R(t) = R_org + tR_dir spezifiziert ist und die Suche nach Primitiven typischerweise auf ein (möglicherweise unbefristetes) Parameterintervall t in [t0,t1] eingeschränkt ist.
Die üblichste Anwendung von Raytracing ist Rendern, wo Strahlen getracet werden, Licht oder Partikel zwischen einer virtuellen Kamera, Lichtern und Flächen zu transportieren; Raytracing geht jedoch weiter über Grafik hinaus und wird oft in Simulationscodes bezüglich Ballistik, Funk-/Drahtlossignalen, Schallausbreitung, Physik usw. verwendet.
Find-first-hit, find-any-hit und Find-all-hits
Über die Jahre wurden viele verschiedene Kernels, Datenstrukturen und Implementierungen für effizientes Raytracing vorgeschlagen. Die meisten davon können in zwei Arten von Familien gruppiert werden: Find-first-hit Kernels zum Finden des nächstgelegenen Treffers entlang eines Strahls (d.h. der Treffer H mit der kleinsten H_t∈[t₀,t₁]) und Kernels zum Ermitteln, ob es irgendeinen Schnittpunkt (find-any-hit) im spezifizierten Strahlintervall gibt. Das erste dieser Kernel erlaubt einer Anwendung zu ermitteln, mit welcher Fläche eines (einer) gegebenen Strahls/Partikels/Welle als nächstes interagiert werden wird; zweiteres wird für gewöhnlich verwendet, um zu ermitteln, ob es eine nichtokkludierte Sichtlinie zwischen zwei Punkten gibt (z.B. zum Ermitteln von Schattenwurf oder Okklusion zwischen einer Quelle und einem Empfänger).
Während diese zwei die bei weitem am häufigsten verwendeten Kernel sind, gibt es einen andern Typ von Kernel, nämlich entweder alle Treffer (find-all-hits) oder die ersten N Treffer zu finden (find-N-hits). Diese sogenannten Multi-hit-Kernels haben im Allgemeinen signifikant weniger Aufmerksamkeit erhalten als closest-hit und any-hit - wohl weil beim Rendern diese oft (aber nicht immer) durch einfaches „Durchschreiten“ mehrerer Treffer mit wiederholten Aufrufen, um den nächstgelegenen zu finden, emuliert werden können.
Warum Multi-Hit wichtig ist
Während first-hit und any-hit oft zum Rendern ausreichen - wo Strahl-Flächen-Interaktionen typischerweise neue, verschiedene Strahlen auslösen, die von diesem Trefferpunkt weg zu tracen sind - sind Multi-hit-Kernels für Nutzlasten besonders nützlich, wo die Simulation oft mehrere Strahl-Flächen-Interaktionen entlang desselben Strahls berücksichtigen muss - wie zum Beispiel, wenn ein Partikel, eine Welle oder ein Projektil durch oft mehrere Schichten von Geometrien stößt, bevor es (sie) absorbiert oder durch das Medium zwischen zwei Flächen zerstreut wird.
Für solche Anwendungen sind Multi-hit-Kernels für beide von zwei Schlüsselgründen wichtig. Der erste solche Grund ist Effizienz. Für Kernels, die auf mehreren (oder allen) aufeinanderfolgenden Schnittpunkten entlang desselben Strahls arbeiten müssen, kann es signifikant effizienter sein, alle diese N Schnittpunkte in einer einzelnen Querung zu finden, als N aufeinanderfolgende unabhängige Querungen auszuführen. Falls individuell getätigt, werden aufeinanderfolgende Strahlen oft Knoten erneut durchqueren und Primitive erneut schneiden, die der vorherige Strahl bereits verarbeitet hat.
Der zweite Grund - Robustheit und Korrektheit in der Gegenwart von komplanaren oder nahezu komplanaren Flächen - ist wohl noch wichtiger. Wenn first-Hit-Kernels verwendet werden, um durch mehrere aufeinanderfolgende Treffer zu schreiten, kann im Allgemeinen eines von zwei Dingen passieren. Falls Treffer bei exakt demselben Abstand t wie der t des vorherigen Trefferpunkts erlaubt sind, können Algorithmen in „Selbstschnittpunkten“ hängenbleiben, oder ewig durch denselben Satz von Treffern mit selbem Abstand wechseln. Um diesen Fall zu vermeiden, ist das gewöhnlich verwendete Verfahren, Treffer mit gleichem Abstand nicht zu erlauben, oft durch „Epsilonversatz“ d.h. bewegen des Eintrittspunkts des gültigen Strahlintervalls um ein kleines Epsilon nach vorne). Dies vermeidet tatsächlich Selbstschnittpunkte, bedeutet aber, dass aus mehreren Trefferpunkten bei demselben oder sehr nahen Abständen immer nur einer gefunden wird, da alle anderen durch das Epsilonversatz-Strahlintervall abgelehnt werden.
Für einfache Renderalgorithmen ist es oft akzeptabel nur eine von mehreren komplanaren Flächen zu finden; dies ist jedoch für hochwertige Renderalgorithmen oder Simulationscodes nicht akzeptabel, für die Flächen verwendet werden, um die Grenzen von Festkörpern oder Medien zwischen diesen Grenzen zu modellieren. Die meisten solcher Algorithmen müssen intern nachverfolgen, wo exakt der Strahl in verschiedene Objekte eintritt und sie verlässt, weshalb es wichtig, sowohl die Fläche zu finden, wo der Strahl ein Objekt verlässt, als auch die Fläche, wo der Strahl in das andere Objekt eintritt, selbst falls diese zwei Flächen komplanar sind (was, bei diesen Nutzlasten, für gewöhnlich der Fall und nicht die Ausnahme ist). Für solche Nutzlasten ist die Verwendung eines find-allhit-Kernels im Allgemeinen der einzige Weg zu garantieren, dass jeder einzelne Strahl-FlächenSchnittpunkt exakt einmal gemeldet wird - ohne sowohl einen zu verfehlen oder doppelt zu melden. Dies ist selbst dann wahr, wenn der Algorithmus letztendlich nur die ersten paar dieser Schnittpunkte braucht.
In Renderalgorithmen ist dieser Fall insbesondere dann wichtig, wenn teilnehmende Medien, große Mengen teilweiser transparenter Flächen usw., in denen find-all-hits-Kernel verwendet werden, abgehandelt werden.
Warum Multi-Hit nicht genug ist
Find-all-hits-Kernels lösen das Korrektheitsproblem effektiv und sind auch ziemlich effizient für Anwendungen, die alle Trefferpunkte benötigen. Sie haben jedoch Begrenzungen. Zuerst ist es im Allgemeinen nicht möglich vorherzusagen, wie viele Trefferpunkte ein gegebener Strahl letztendlich mit sich bringen wird, was effektive Speicherverwaltung für einen Rückkehrwert eines Find-all-hits-Kernels herausfordernd macht. Dies ist insbesondere im Kontext ansonsten schneller Raytracer und/oder moderner Plattformen mit hohem Durchsatz, auf denen viele Strahlen parallel im Flug sind, und da, wo potentiell unbegrenzter Speicher pro Thread eine Herausforderung ist, wahr.
Zweitens ist selbst das Effizienzargument komplexer als es klingt. Alle Treffer in einem Durchgang zu finden, wird in Fällen, wo die Anwendung tatsächlich alle solche Trefferpunkte benötigt, klar effizienter sein; aber in den meisten Anwendungen wird das (die) Partikel/Welle/Projektil letztendlich absorbiert oder abgelenkt werden, sodass alle Trefferpunkte über diesen Punkt hinaus unnötigerweise berechnet werden. Daher wird, ob ein Find-all-hits-Kernel, der alle N Treffer findet, tatsächlich schneller ist, als M individuelle Strahlen für die M<N Trefferpunkte zu tracen, die die Anwendung wirklich benötigt, von den jeweiligen Werten von M und N abhängig sein, von denen keiner vorhergesagt oder sogar vorab eingegrenzt werden kann.
Ersetzen des Find-all-hits-Kernel mit einem speziellen Find-K-hits-Kernel, der immer nur die ersten K Treffer findet, für ein gegebenes fixiertes K, kann sowohl das unbegrenzte Speicherproblem lösen als auch den Find-all-hits-Aufwand für M«N abschwächen. Diese Implementierung würde jedoch unter signifikantem Aufwand leiden, falls K signifikant größer ist als die unbekannte Zahl von M benötigten Treffern; und eröffnet die Robustheitsfragen für diese Fälle wieder, wo sich das ausgewählte K als zu klein erwiesen hat.
Letztendlich würden alle der zuvor besprochenen Fälle - Epsilonversatz für Find-first-hits, Überspringen von Schnittpunkten, wenn Epsilonversatz verwendet wird, Speicher- und Rechenkosten für Find-all-hits und Behandeln von Find-K-hits-Kernels - sich großteils erledigen, sobald es einen effizienten Weg gäbe, auf eine robuste und korrekte Weise wiederholt durch mehrere Treffer entlang desselben Strahls zu schreiten und idealerweise, ohne ein Queren für jeden nächsten Schritt neu zu starten.
Beiträge
Ausführungsformen der Erfindung enthalten eine Modifizierung bestehender Find-first-hit-Kernels, die im Wesentlichen das Robustheitsproblem dadurch löst zu garantieren, dass mehrere aufeinanderfolgende Aufrufe jede Fläche auf eine Front-zu-Back-Weise exakt einmal wiedergeben, ohne irgendwelche Trefferpunkte zu überspringen oder mehrmals zu melden. Zusätzlich enthalten manche Ausführungsformen einen iterativen Find-ext-hit-Kernel, der erlaubt, effizienter durch mehrere Hits zu schreiten als bei Verwendung mehrerer sequentieller aber unabhängiger Strahlen.
FINDEN DES ERSTEN TREFFERS
Wie zuvor erwähnt gibt es zwei Hauptgründe sich Multi-hit-Kernels anzusehen: Effizienz, wenn mehrere Trefferpunkte auf einmal benötigt werden, und Korrektheit (wie darin, keine Trefferpunkte zu überspringen), wenn der jeweils „nächste“ Trefferpunkt entlang eines Strahls iterativ abgefragt wird. Das Thema von Effizienz für den Moment ignorierend, enthält eine Ausführungsform der Erfindung eine Modifikation bestehender Querungsschemata, die sie in Bezug auf Trefferpunkte beim selben Abstand robust macht.
Identifizieren des Problems
Um die geeignete Lösung zu wählen, muss die Grundursache des Problems adressiert werden: aufeinanderfolgende Aufrufe zu einem regulären Find-first-hit-Kernel führt zu inkorrekten Ergebnissen, weil Trefferpunkte mit demselben Abstand übersprungen werden; dies passiert, weil die Anwendung einen Epsilonversatz des gültigen Strahlintervalls tätigen (d.h. explizit nach einem minimalen Trefferabstand hinter dem letzten Treffer fragen) muss. Epsilonversatz muss nur getätigt werden, um Eigenschnittpunkte zu vermeiden, und diese treten wiederum nur auf, weil ein Verfolgen des jeweils „nächstgelegenen“ Treffers während einer Querung nicht zwischen Treffern desselben Abstands unterscheiden kann.
So betrachtet ist die Wurzel des Problems die einfache Tatsache, dass Vergleichen verschiedener Treffer nur anhand des Abstands doppeldeutig ist, was dem Querungsalgorithmus eine Möglichkeit bietet, zu ermitteln, welche Treffer näher sind als andere, aber ihm nicht erlaubt, eine klare nichtdoppeldeutige Reihung von Treffern zu festzulegen, die denselben Abstand haben. Solange keine solche nichtdoppeldeutige Reihung besteht, macht über den jeweiligen „ersten“ oder „nächsten“ Treffer entlang eines Strahls zu reden keinen Sinn.
Lösen des Problems
Eine Ausführungsform der Erfindung modifiziert den „Abstandtest“, der in Strahlquerung und Primitivschnittpunkt verwendet wird, um eindeutig zu werden. Insbesondere, wie in 13 veranschaulicht, anstatt nur den tatsächlichen Abstand zur Fläche zu testen (was notwendigerweise doppeldeutig wird, wenn mehrere Flächen denselben Abstand teilen) ist eine absolute Reihung aller Strahl-Flächen-Schnittpunkte definiert, indem ein Tupel von Abstand und eine eindeutige Trefferpunkt-ID 1338, wie die Primitiv-ID (die in Speicher 1330 mit anderen Primitivdaten 1333 gespeichert sein kann) verwendet wird. Distanztestlogik 1311, 1321 innerhalb der Querungseinheit 1310 und/oder Schnittpunkteinheit 1320 kann die Trefferpunkt-ID 1338 verwenden, um Trefferpunkte auf Flächen eindeutig zu machen, die denselben Abstand teilen. Daher ist, unter Verwendung der Trefferpunkt-ID 1338, eine Reihung derart definiert, dass ein Flächenschnittpunkt „kleiner als“ (d.h. zuvor gemeldet wird) ein anderer ist, falls sein Abstand zum Strahlursprung kleiner ist, ODER, im Fall gleicher Abstände, falls seine eindeutige Trefferpunkt-ID 1338 kleiner ist als die andere Trefferpunkt-ID. In einer Ausführungsform, wann immer ein Strahl getracet wird, um den „nächsten“ Schnittpunkt zu finden, wird der bestehende Abstand/Trefferpunkt-ID-Tupel mit dem Strahl (z.B. innerhalb einer Cache/Speicherhierarchie und/oder lokaler Puffer 1330), und dem Schnittpunkt mit dem „kleinsten“ Tupel (unter Verwendung der absoluten Reihung), der noch größer ist als der vorangehende, gespeichert.
Andere Komponenten in 13 können auf eine bekannte Weise arbeiten. Zum Beispiel quert die Querungseinheit 1310 Strahlen 1301, die von einer Strahlerzeugungseinheit (nicht gezeigt) durch eine Strahlquerungsbeschleunigungsstruktur, wie eine Abgrenzungsvolumenhierarchie (Bounding Volume Hierarchy, BVH) wie von einem Satz von BVH-Knoten 1331 definiert, empfangen sind. Dieselbe Technik funktioniert auch für andere Beschleunigungsstrukturen, wie k-d-Bäume, Gitter usw. Knoten, die ermittelt sind Primitive zu enthalten, werden zu den Schnittpunkteinheiten 1320 weitergegeben, die Schnittpunkte zwischen den Strahlen und Primitiven identifizieren.
In einem Raytracing-System gibt es eine Rückmeldungsschleife zwischen der Schnittpunkteinheit 1320 und Querungseinheit 1310, weil ein Schnittpunkt während Querung auftritt (d.h. jedes Mal, wenn ein Strahl einen Blattknoten quert). In diesem Fall, wenn der Strahl mit den Primitiven in den Knoten geschnitten wird, werden ein oder mehr Strahl-Primitiv-Schnittpunkte identifiziert (und der nächstgelegene typischerweise gespeichert), aber da eine Querung nicht beendet sein könnte, kann es andere, nähere Schnittpunkte in anderen Knoten geben. Daher kann eine von zwei Situationen auftreten: falls ein Schnittpunkt gefunden wird UND garantiert werden kann, dass er näher ist als jeder andere, den man noch finden könnte (z.B. weil er näher ist als alle anderen Knoten, die sich noch auf dem Querungsstapel befinden), kann er dann als „der“ Schnittpunkt ausgegeben werden; falls nicht, wird er gespeichert und Querung wird fortgesetzt. So oder so wird ein Strahl typischerweise erst an einen Shader weitergegeben, wenn der gesamte Querungs-/Schnittprozess beendet ist. Sobald beendet, errechnet der Shader eine Farbe, die in das akkumulierte Bild geschrieben wird. Zusätzlich kann der Shader Schatten oder sekundäre Strahlen erzeugen, die an die Querungsstufe zurückgegeben werden können.
Nun zurück zur Abstandstestlogik 1311, 1221, die innerhalb der Querungs- und/oder Schnittpunkteinheiten implementiert ist, kann eine gesamte Reihung von Trefferpunkten unter Verwendung eines Vergleichsoperators <_hit durchgesetzt werden, der eine gesamte Reihungsbeziehung auf dem Raum aller möglichen Trefferpunkte implementiert. Zum Beispiel können dann, unter der Annahme, dass jeder mögliche Trefferpunkt H einzigartig durch eine Primitiv-ID H.p und einen Abstand H.t identifiziert werden könnte, sowohl Abstand als auch Primitiv-ID im Vergleich verwendet werden und insbesondere kann die Primitiv-ID verwendet werden, Treffer mit demselben Abstand eindeutig zu machen. Mathematisch ausgedrückt:

wahr ; für H₁.t<H₂.t

H₁<H₂= wahr ; für H₁.t=H₂.t und H₁.p<H₂.p

falsch ; ansonsten
Unter Verwendung einer solchen gesamten Reihung ist die Reihung von Trefferpunkten entlang eines gegeben Strahls nun gut definiert, was heißt, dass es nun möglich ist, exakt den nächsten Trefferpunkt abzufragen, der jener ist, der <_hit aller anderen Trefferpunkte ist, der aber „nach“ einem anderen Treffer h₀ kommt. Ähnlich kann das Konzept von einem „gültigen t Intervall“ t∈[t₀,t₁] durch ein „gültiges Trefferintervall h∈[H₀,H₁] ersetzt werden, dass nur Treffer H erlaubt, die H₀<H<H₁ erfüllen. Für Anwendungen, die nur einen minimalen Abstand t₀ spezifizieren, selbst falls es keinen Schnittpunkt bei diesem Abstand gibt, ist es immer noch möglich, einen minimalen Treffer H₀=(t₀,-1) zu spezifizieren (angenommen, dass -1 eine ungültige Primitiv-ID ist).
Sobald der modifizierte Vergleichstest in ein gegebenes Find-first-hit-Querungskernel integriert ist (z.B. innerhalb von Abstandtestlogik 1311), kann eine Anwendung, die durch mehrere Treffer entlang eines Strahls schreiten muss, dies leicht tun, wissend, dass jeder Treffer exakt einmal gemeldet werden wird. Ein anfängliches Strahlintervall [t₀;t₁] gegeben, startet die Anwendung mit Abfragen des ersten Treffers im [(t₀;t₁);( t₁;t₁-1)] Intervall und bekommt Trefferpunkt H₂; usw.
Ein Verfahren in Übereinstimmung mit einer Ausführungsform der Erfindung ist in 14 veranschaulicht. Das Verfahren kann innerhalb des Kontexts der hierin beschriebenen Raytracing-Architektur implementiert sein, ist aber nicht auf eine bestimmte Grafikarchitektur begrenzt.
Bei 1404 werden zwei oder mehr Strahl-Fläche-Schnittpunkte identifiziert und bei 1402 werden einzigartige Trefferpunktkennungen (Identifiers, IDs) (z.B. Primitiv-IDs) für jeden Schnittpunkt erzeugt. Falls zwei oder mehr der Schnittpunkte denselben Abstand haben (oder nahezu denselben Abstand, was es unmöglich macht, sie zu unterscheiden), die bei 1403 ermittelt wurden, in dann bei 1404 eine absolute Reihung von Schnittpunkten unter Verwendung einer Kombination von Abstand und Trefferpunkt-ID erzeugt. Eine Primitiv-ID zum Beispiel, die das Primitiv, das geschnitten wird, einzigartig identifiziert, kann leicht verwendet werden, um zwischen Schnittpunkten, die denselben Abstand teilen, zu unterscheiden. Falls die zwei oder mehr Schnittpunkte nicht beim selben Abstand sind, dann wird bei 1405 eine absolute Reihung von Schnittpunkten unter Verwendung der jeweiligen Abstände erzeugt.
Variationen und Erweiterungen
Während die obenstehende Beschreibung eine einzelne Primitiv-ID verwendet, ist Erweiterung auf Mehrstufenadressierungsschemata (wie Embree's (instID, meshID, primID)) unkompliziert. Jedes andere Vergleichsverfahren kann verwendet werden, solange ein Paar von Trefferpunkten eine konsistente und gut definierte Reihung hat. Insbesondere, da alles was in einer Ausführungsform modifiziert werden muss, der Abstandstest zwischen zwei Trefferpunkten ist, ist das Verfahren vollständig mit jeder (jedem) Beschleunigungsstruktur, Primitivtyp, Querungsreihung, SIMD-Optimierung oder anderen Querungsvariante, die auf Verfolgung des „nächstgelegenen“ Treffers innerhalb eines gegebenen Intervalls basiert, kompatibel.
Es ist tatsächlich möglich, die Reihungsbeziehung zu arrangieren, um andere Ziele zu erzielen, die für die Anwendung wünschenswert sein können. Zum Beispiel kann für Anwendungen, die verfolgen müssen, in welche Objekte ein Strahl eintritt oder welche er verlässt, das Find-next-hit-Kernel konfiguriert sein, immer „Austritt“-Ereignisse vor „Eintritt“-Ereignissen zurück zu schicken. Ähnlich kann beim Rendern, wenn mit Dekoren verfahren wird, sichergestellt werden, dass Flächen, die als Dekore markiert sind, vor der Basisgeometrie zurückgesendet werden.
Im Sinne von Kosten sind Modifikationen unbedeutend günstig. Ungeachtet des Querungsverfahrens wird die Querungseinheit bereits Abstandstests ausführen, sodass alles was zu tun ist der zusätzliche Test in dem Falle ist, dass der bestehende Abstandstest fehlschlägt.

H₀t==H₁t&&H₀.p<H₁.p

EFFIZIENTER ALGORITHMUS ZUM FINDEN EINES NÄCHSTEN TREFFERS
Während die zuvor beschriebenen Ausführungsformen eine wichtige Begrenzung für ein Multi-hit-Kernel adressieren (d.h. das Problem fehlender Schnittpunkte), benötigen diese Ausführungsformen nach wie vor einen vollständigen Neustart der Datenstrukturquerung, jedes Mal, wenn die Querung angerufen wird. Eine Ausführungsform weist ein Kernel auf, das „aufnehmen“ kann, wo ein vorheriger Aufruf aufgehört hat. Dazu ist eine Technik zum Weitergeben von Informationen von einer Querung zum jeweils „nächsten“ Treffer in derselben Querungssequenz nötig. Dafür wird eine Pause gemacht, mit dem Paradigma, dass alle Querungen unabhängig sind, im Sinne eines neuen Zwei-Schritt-Paradigmas, das einem „Iterator“ ähnlich ist. Nach Anfragen eines neuen „find next hit“ Iterators für einen gegebenen Strahl, werden nachfolgende Aufrufe zu diesem Iterator aufeinanderfolgend den jeweiligen nächsten Trefferpunkt zurücksenden. Der Iterator kann dann Informationen darüber verfolgen, was bereits gequert wurde.
Mit dem eingerichteten Iteratorparadigma ist ein Implementieren einer effizienten Find-next-hit-Architektur relativ unkompliziert. Zuerst werden Knoten verfolgt, die bisher nicht gequert wurden, und Knoten werden nur gequert, wenn der nächste Treffer gefunden wurde. Dies bedeutet, dass der Iterator einen Stapel oder eine Prioritätsreihe von bisher-nichtgequerten-Knoten verwenden muss. In einer Ausführungsform werden diese gequert, bis der momentan nächstgelegene Treffer garantiert ist näher zu liegen als jeder nichtgequerte Knoten. Als zweites wird jeder Treffer verfolgt, der währen Querung angetroffen wird. Selbst ein Treffer, der nicht der momentanen nächstgelegene Treffer ist kann der nächstgelegene Treffer in einer zukünftigen Querung sein; daher muss der Iterator auch Übersicht über alle bereits gefundenen Treffer behalten (möglicherweise in einer Form von Speicherhalde oder sortierter Liste).
Obwohl die hierin beschriebenen Kernideen auch auf andere Datenstrukturen anwendbar sind, wird sich der Rest dieser Beschreibung auf Abgrenzungsvolumenhierarchen (BVHs) (von beliebigen Verzweigungsfaktoren) konzentrieren, weil BVHs aktuell die vorherrschenden Beschleunigungsstrukturen sind. Auch obwohl dieselben Techniken auch in rekursiven Tiefe-zuerst-Querungsschemata implementiert werden können, ist es am einfachsten in einer Front-zu-Back-BVH-Querung erklärt.
Front-zu-Back-Querung für BVHs
Ungleich räumlichen Hierarchien, wie einem Gitter oder K-D-Bäumen, sind Abgrenzungsvolumenhierarchien (BVHs) Objekthierarchien, in denen verschiedene Teilbäume überlappen können. Dies heißt, dass rekursive BVH-Querung nicht garantieren kann, dass Knoten (oder Blätter) in einer Front-zu-Back-Reihung gequert werden, selbst falls jeder Querungsschritt seine Kinder ordentlich sortiert.
Obwohl manchmal angenommen wird, dass eine Front-zu-Back-Querung mit BVHs unmöglich sei, ist sie tatsächlich leicht zu erzielen. Alles was getan werden muss, ist, den Stapel von noch-zu-querenden-Knoten mit einer Prioritätsreihe (z.B. Speicherhalde, sortierte Liste usw.) zu ersetzen und noch-zu-querende-Knoten nach deren Abstand zum Strahlursprung (der vom Strahl-Box-Schnittpunkttest bekannt ist) einzufügen. Eine Pseudocodeversion dieses Algorithmus ist in Tabelle 1 unterhalb bereitgestellt.

Dieser Pseudocode optimiert nicht tatsächlich für den findNextHit-Fall, sondern setzt eine Front-zu-Back-Querung von BVHs durch, die in einer Ausführungsform die Basis für die findNextHit-Operationen bildet.
Ein Verfahren für Front-zu-Back-Querung ist in 15 veranschaulicht. Das Verfahren kann auf den hierin beschriebenen Architekturen implementiert werden, ist aber nicht auf irgendeine bestimmte Grafikverarbeitungsarchitektur begrenzt.
Bei 1501 werden nichtgequerte BVH-Knoten gemeinsam mit dem nächstgelegenen momentan lokalisierten Trefferpunkt eingereiht. Bei 1502 wird der nächstgelegene nichtgequerte Knoten identifiziert und bei 1503, falls der Knoten weiter entfernt als der nächstgelegene bekannte Treffer ist, müssen dann alle anderen Treffer, wie bei 1510 angezeigt, weiter weg sein. Daher schließt der Prozess ab.
Falls der Knoten nicht weiter weg ist als der nächstgelegene bekannte Treffer, dann ist bei 1504 der nächstgelegene Knoten erweitert. Bei 1505, falls der nächstgelegene Knoten ein Blattknoten ist, dann sind in diesem Blattknoten die Primitive auf Schnittpunkt getestet und für jeden erfolgreichen Schnittpunkttest wird der resultierende Trefferpunkt nur akzeptiert, falls er näher ist als der momentane Trefferpunkt. Bei 1506, falls der Knoten ein Blattknoten ist, dann wird jedes Kind des Knotens, das mit dem Strahl schneidet, eingereiht, gemeinsam mit deren jeweiligen Abständen. Falls die Reihe leer ist, was bei 1507 ermittelt wird, dann schließt der Prozess ab. Falls nicht, dann kehrt der Prozess zu 1502 für den nächstgelegenen eingereihten Knoten zurück.
Adaption für findNextHit
Sobald eine Front-zu-Back-Querung erlangt wird, ist Implementieren eines Find-next-hit-Schemas ziemlich einfach. In einer Ausführungsform wird zusätzlich zu einer Prioritätsreihe für die bis jetzt nichtgequerten Knoten eine Prioritätsreihe bereits gefundener Treffer beibehalten. Dann, sobald der nächstgelegene bereits gefundene Treffer näher gelegen ist als der nächstgelegene noch nicht gequerte Knoten, ist dies der garantiert nächstgelegene Treffer und kann zurückgesendet werden. Ansonsten wird der nächstgelegene noch-nichtquerte Knoten aus der Prioritätsreihe geworfen und gequert. Falls es ein Blattknoten ist, werden alle Primitive geschnitten und alle gefundenen Treffer werden zur Trefferliste hinzugefügt (jeder mit dessen jeweiligen Abstand); falls es ein innerer Knoten ist, werden alle Kinder getestet und zur Knotenliste hinzugefügt. Die nächster-Treffer-Sequenz wird mit einer Knotenreihe initialisiert, die den BVH-Ursprungsknoten beinhaltet.
Ein einfacher Pseudocode von diesem Algorithmus - enthaltend die Ausnahmefälle von „kein Knoten mehr zu queren“ ist in unten Tabelle 2 bereitgestellt. Es ist garantiert, dass nachfolgende Aufrufe jeden Treffer exakt einmal in tiefensortierter Reihung melden.
Besprechung
Ein kleinerer Nachteil bei der vorherigen Technik ist, dass sie nicht so leicht auf bestehende Raytracing-APIs gemappt werden kann, ohne die API zu modifizieren. Embree zum Beispiel bietet einen einzelnen rtcIntersect () Aufruf, der keine Mittel zum Weitergeben von Querungszustand von einem Aufruf zum anderen bietet. Daher sind in einer Ausführungsform drei API-Aufrufe verwendet, um dieses Schema zu implementieren: einer, um eine neue Querung zu starten (z.B. state=rtcInitTraversal(ray)), einer, um den jeweils nächsten Treffer zu finden (z.B. rtcFindNextHit(state)) und einer, um eine Querungssequenz zu beenden und Statusinformationen freizugeben (z.B. rtcEndTraversal(state)).
Arbeitsleistungsüberlegungen
Im Sinne von Arbeitsleistung schaut das Konzept, einen gesamten Querungszustand von einem Aufruf zum nächsten weiterzugeben anfänglich wie eine teure Operation aus. In der Praxis jedoch wenden praktisch alle rekursiven Querungsverfahren bereits irgendwie einen Stapel an und da dieser typischerweise nicht in Register passt, wird er bereits in Speicher gespeichert (z.B. Stapelspeicher). Diese in Haldenspeicher zu speichern, ist nur für den Programmierer ein Unterschied, und solange dieser Zustand in Cache bleibt, wird der nächste Aufruf dieselbe Zugriffgeschwindigkeit haben, egal ob Speicherhalde oder auf einem Stapel.
Es gibt nicht unbeachtliche Kosten im Beibehalten sortierter Prioritätsreihen. Dies erfordert eine sehr bedachte Implementierung, um dynamische Speicherzuteilungen zu minimieren. Selbst dann wird eine Prioritätsreihe beizubehalten immer teurer sein, als nur den jeweils nächstgelegenen Strahl zu verfolgen. Daher, falls alles, was benötigt wird, der erste Treffer entlang eines Strahls ist, kann erwartet werden, dass ein gewöhnlicher findNextHit-Kernel schneller ist. Ähnlich kann für ein großes (und vorbestimmtes) N erwartet werden, dass N nachfolgende Aufrufe langsamer als ein dedizierter Kernel sind, der alle N Treffer in einem einzelnen Durchgang abfragt. Der Kernel kann jedoch verwendet werden, wo dieses N nicht bekannt ist, und garantiert sein, immer den jeweils nächsten Trefferpunkt zu kriegen, ungeachtet dessen, wie viele Aufrufe getätigt werden.
Anwendbarkeit auf andere Beschleunigungsstrukturen
Obwohl die vorherigen Ausführungsformen im Kontext einer Front-zu-Back-Querung beschrieben werden, können sie auch in jeden rekursiven Raytracer implementiert werden, solange es einen schnellen Weg gibt, den nächstgelegenen noch-zu-querenden Knoten und das nächstgelegene bereits gefundene Dreieck zu ermitteln. Ähnlich sind sich diese Ausführungsformen BVH-Verzeigungsfaktoren, dem Algorithmus, der zum Konstruieren der BVH verwendet wird, oder der Form von Grenzprimitiven komplett unbewusst; diese können selbst in „Hybrid“-BVHs verwendet werden, in denen selbst innere Knoten Primitive speichern, oder in nicht-BVH-Datenstrukturen, wie k-d-Bäumen, rekursiven Gittern usw. Diese Ausführungsformen können auch mit Embrees Konzept von „Schnittpunktfiltern“ integriert werden (leicht garantierend, dass jedes Primitiv nur einmal gefiltert wird), und können erweitert werden, um jeden nächsten Treffer anstatt immer den nächstgelegenen nächsten (wie hierin beschrieben) zurückzusenden.
Für die Reihe an Trefferpunkten kann der zuvor beschriebene Abstandtest verwendet werden, um Treffer mit demselben Abstand eindeutig zu machen, aber, da jedes Primitiv zur Trefferreihe nur exakt einmal hinzugefügt wird, kann Korrektheit garantiert werden, selbst falls nur Abstand für den Vergleich verwendet wird. In diesem Fall kann die Reihung, in der Treffer mit demselben Abstand zurückgesendet werden, nicht garantiert werden, Treffer werden aber nicht übersprungen oder mehrfach gemeldet werden.
Der vorherige Code besteht aus zwei Teilen: Initialisieren einer neuen anfänglichen Querung (initNextHit) und Durchschreiten vom zuletzt gefundenen Treffer zum jeweils nächsten Treffer entlang des Strahls.
Anstatt zwei separate Prioritätsreihen aufrecht zu erhalten - eine für Treffer und eine für Knoten - hält eine Ausführungsform nur eine einzelne aufrecht die beide speichert. In diesem Fall wird der Algorithmus ein einfacher eleganter Baumerweiterungsalgorithmus, wo jeder Knoten sich in entweder einen Satz von Treffern oder einen Satz neuer Knoten, die zu queren sind, „erweitert“. Sehr ähnliche Schemata können auch auf KD-Bäume, oc-Bäume oder irgendwelche anderen hierarchischen Datenstrukturen und selbst auf Gitter angewendet werden.
Ausführungsformen der Erfindung können unterschiedliche Schritte enthalten, die zuvor beschrieben wurden. Die Schritte können in maschinendurchführbaren Befehlen eingebettet sein, die verwendet werden können, um einen Allzweckprozessor oder Sonderzweckprozessor zu veranlassen, die Schritte auszuführen. Alternativ können diese Schritte von spezifischen Hardwarekomponenten ausgeführt werden, die festverdrahtete Logik zum Ausführen der Schritte beinhalten, oder durch eine Kombination programmierter Computerkomponenten und kundenspezifischer Hardwarekomponenten.
Wie hierin beschrieben, können sich Befehle auf spezifische Hardwarekonfigurationen beziehen, wie anwendungsspezifische integrierte Schaltkreise (Application Specific Integrated Circuits, ASICs), die konfiguriert sind, gewisse Operationen auszuführen oder eine vorbestimmte Funktionalität oder Softwarebefehle zu haben, die in Speicher gespeichert sind, der in einem nichttransitorischen computerlesbaren Medium eingebettet ist. Daher können die in den Figuren gezeigten Techniken unter Verwendung von Code und Daten implementiert werden, die auf einem oder mehr elektronischen Geräten (z.B. einer Endstation, einem Netzwerkelement usw.) gespeichert und durchgeführt werden. Solche elektronischen Geräte speichern und kommunizieren (intern und/oder mit anderen elektronischen Geräten über ein Netzwerk) Code und Daten, unter Verwendung computerlesbarer Medien, wie nichttransitorische computermaschinenlesbare Datenspeichermedien (z.B. Magnetdatenträger; optische Datenträger; Direktzugriffspeicher; Nur-Lese-Speicher; Flashspeichergeräte; Phasenänderungsspeicher) und transitorische computermaschinenlesbare Kommunikationsmedien (z.B. elektrisch, optisch, akustisch oder andere Form propagierter Signale - wie Trägerwellen, Infrarotsignale, digitale Signale usw.). Zusätzlich enthalten solche elektronischen Geräte typischerweise einen Satz von einem oder mehr Prozessoren, die mit einer oder mehr anderen Komponenten gekoppelt sind, wie einem oder mehr Datenspeichergeräten (nichttransitorische maschinenlesbare Datenspeichermedien), Anwendereingangs/ausgangsgeräten (z.B. eine Tastatur, einen Berührungsbildschirm und/oder eine Anzeige) und Netzwerkverbindungen. Das Koppeln des Satzes von Prozessoren und anderen Komponenten ist typischerweise durch einen oder mehr Busse und Brücken (auch als Bussteuerungen bezeichnet). Das Datenspeichergerät beziehungsweise Signale, die den Netzwerkverkehr tragen, stellen ein oder mehr maschinenlesbare Datenspeichermedien und maschinenlesbare Kommunikationsmedien dar. Daher speichert das Datenspeichergerät eines gegebenen elektronischen Geräts typischerweise Code und/oder Daten zur Durchführung auf dem Satz von einem oder mehr Prozessoren des elektronischen Geräts. Selbstverständlich können ein oder mehr Teile einer Ausführungsform der Erfindung unter Verwendung verschiedener Kombinationen von Software, Firmware und/oder Hardware implementiert werden. In dieser ausführlichen Beschreibung wurden zum Zweck der Erklärung zahlreiche spezifische Details vorgebracht, um ein umfassendes Verständnis der vorliegenden Erfindung bereitzustellen. Es wird jedoch für den Fachkundigen offensichtlich, dass die Erfindung ohne manche dieser spezifischen Details ausgeübt werden kann. In gewissen Instanzen wurden wohlbekannte Strukturen und Funktionen nicht in ausführlichem Detail beschrieben, um ein Verschleiern des Gegenstands der vorliegenden Erfindung zu verhindern. Dementsprechend sollte Der Umfang und das Wesen der Erfindung im Sinne der folgenden Ansprüche beurteilt werden.

Claims

Beansprucht wird:
Grafikverarbeitungsvorrichtung, aufweisend: eine Raytracing-Querungs-/Schnittpunkteinheit, um zwei oder mehr Strahl-Fläche-Schnittpunkte zu identifizieren, wobei jedem der Strahl-Fläche-Schnittpunkte eine einzigartige Trefferpunktkennung (ID) zugeteilt ist; und ein Abstandtestmodul, um die Strahl-Fläche-Schnittpunkte unter Verwendung der Trefferpunkt-ID eindeutig zu machen, falls sich die zwei oder mehr der Strahl-Fläche-Schnittpunkte denselben Abstand teilen.
Grafikverarbeitungsvorrichtung nach Anspruch 1, wobei die einzigartige Trefferpunkt-ID eine Primitiv-ID aufweist, die ein Primitiv der Fläche einzigartig identifiziert.
Grafikverarbeitungsvorrichtung nach Anspruch 1 oder 2, ferner aufweisend: das Abstandtestmodul, das eine absolute Reihung der Strahl-Fläche-Schnittpunkte unter Verwendung einer Kombination der Abstände und Trefferpunkt-IDs erzeugt.
Grafikverarbeitungsvorrichtung nach Anspruch 1, 2 oder 3, ferner aufweisend: die Raytracing-Querungs-/Schnittpunkteinheit, die eine erste Querungsoperation unter Verwendung eines ersten Strahl-Fläche-Schnittpunkts ausführt und Informationen von der ersten Querungsoperation zu einer zweiten Querungsoperation weitergibt, unter Verwendung eines zweiten Strahl-Fläche-Schnittpunkts mit einer sequentiellen Reihung, die direkt dem ersten Strahl-Fläche-Schnittpunkt folgt.
Grafikverarbeitungsvorrichtung nach Anspruch 1, 2 oder 4, ferner aufweisend: einen Stapel oder eine Prioritätsreihe, beinhaltend Strahl-Fläche-Schnittpunkte, die noch zu queren sind; und nach Ausführen einer Querung unter Verwendung eines Strahl-Fläche-Schnittpunkts, wobei das Abstandtestmodul einen nächsten Strahl-Fläche-Schnittpunkt aus dem Stapel oder der Prioritätsreihe für eine nächste Querungsoperation identifiziert.
Grafikverarbeitungsvorrichtung nach Anspruch 1, 2 oder 5, ferner aufweisend: das Abstandtestmodul, das Querungen ausführt, bis garantiert ist, dass ein momentan nächstgelegener Strahl-Fläche-Schnittpunkt näher gelegen ist als irgendein nichtgequerter Strahl-Fläche-Schnittpunkt im Stapel oder in der Prioritätsreihe.
Grafikverarbeitungsvorrichtung nach Anspruch 4 oder 6, wobei die Querungsoperationen Querungen unter Verwendung von Knoten einer Abgrenzungsvolumenhierarchie (BVH) aufweisen.
Grafikverarbeitungsvorrichtung nach Anspruch 4, 6 oder 7, wobei die Querungsoperationen Back-zu-Front-Querungen aufweisen, in denen nichtgequerte Strahl-Fläche-Schnittpunkte in einer ersten Prioritätsreihe geordnet sind, basierend auf deren Abstand zum Strahlursprung.
Grafikverarbeitungsvorrichtung nach Anspruch 1, 2 oder 8, ferner aufweisend: eine zweite Prioritätsreihe, um zuvor gequerte Strahl-Fläche-Schnittpunkte zu speichern.
Grafikverarbeitungsvorrichtung nach Anspruch 9, ferner aufweisend: das Abstandtestmodul, um einen zuvor gequerten Strahl-Fläche-Schnittpunkt von der zweiten Prioritätsreihe mit einem oder mehr Strahl-Fläche-Schnittpunkten in der ersten Prioritätsreihe zu vergleichen, und falls der gequerte Strahl-Fläche-Schnittpunkt von der zweiten Prioritätsreihe nähergelegen ist, dann Identifizieren des vorherigen gequerten Strahl-Fläche-Schnittpunkts als den nächstgelegenen Strahl-Fläche-Schnittpunkt.
Vorrichtung, aufweisend: Mittel zum Identifizieren von zwei oder mehr Strahl-Fläche-Schnittpunkten; Mittel zum Erzeugen einer einzigartigen Trefferpunkt-ID für jeden Strahl-Fläche-Schnittpunkt; und Mittel zum Vereindeutigen der Reihung der Strahl-Fläche-Schnittpunkte unter Verwendung der Trefferpunkt-ID, falls sich zwei oder mehr der Strahl-Fläche-Schnittpunkte denselben Abstand teilen.
Vorrichtung nach Anspruch 11, wobei die einzigartige Trefferpunkt-ID eine Primitiv-ID aufweist, die ein Primitiv der Fläche einzigartig identifiziert.
Vorrichtung nach Anspruch 11 oder 12, ferner aufweisend: Erzeugen einer absoluten Reihung der Strahl-Fläche-Schnittpunkte unter Verwendung einer Kombination der Abstände und Trefferpunkt-IDs.
Vorrichtung nach Anspruch 11, 12 oder 13, ferner aufweisend: Ausführen einer ersten Querungsoperation unter Verwendung eines ersten Strahl-Fläche-Schnittpunkts; und Weitergeben von Informationen von der ersten Querungsoperation an eine zweite Querungsoperation unter Verwendung eines zweiten Strahl-Fläche-Schnittpunkts mit einer sequentiellen Reihung, die direkt dem ersten Strahl-Fläche-Schnittpunkt folgt.
Vorrichtung nach Anspruch 11, 12 oder 14, ferner aufweisend: Beibehalten eines Stapels oder einer Prioritätsreihe, der bzw. die Strahl-Fläche-Schnittpunkte beinhaltet, die noch zu queren sind; und nach Ausführen einer Querung unter Verwendung eines Strahl-Fläche-Schnittpunkts, Identifizieren eines nächsten Strahl-Fläche-Schnittpunkts von dem Stapel oder der Prioritätsreihe für eine nächste Querungsoperation.
Vorrichtung nach Anspruch 11, 12 oder 15, ferner aufweisend: Ausführen von Querungen, bis garantiert ist, dass ein momentan nächstgelegener Strahl-Fläche-Schnittpunkt näher gelegen ist als jeder nichtgequerte Strahl-Fläche-Schnittpunkt im Stapel oder in der Prioriätsreihe.
Vorrichtung nach Anspruch 14 oder 16, wobei die Querungsoperationen Querungen unter Verwendung von Knoten einer Abgrenzungsvolumenhierarchie (BVH) aufweisen.
Vorrichtung nach Anspruch 14, 16 oder 17, wobei die Querungsoperationen Back-zu-Front-Querungen aufweisen, in denen nichtgequerte Strahl-Fläche-Schnittpunkte in einer ersten Prioritätsreihe gereiht werden, basierend auf deren Abstand vom Strahlursprung.
Vorrichtung nach Anspruch 11, 12 oder 18, ferner aufweisend: Speichern zuvor gequerter Strahl-Fläche-Schnittpunkte innerhalb einer zweiten Prioritätsreihe.
Vorrichtung nach Anspruch 19, ferner aufweisend: Vergleichen eines zuvor gequerten Strahl-Fläche-Schnittpunkts von der zweiten Prioriätsreihe mit einem oder mehr Strahl-Fläche-Schnittpunkten in der ersten Prioritätsreihe, und falls der gequerte Strahl-Fläche-Schnittpunkt von der zweiten Prioritätsreihe nähergelegen ist, dann Identifizieren des zuvor gequerten Strahl-Fläche-Schnittpunkts als den nächstgelegenen Strahl-Fläche-Schnittpunkt.
Maschinenlesbares Medium mit Programmcode, der darauf gespeichert ist, der, wenn von einer Maschine durchgeführt, die Maschine veranlasst, die Operationen auszuführen: Identifizieren von zwei oder mehr Strahl-Fläche-Schnittpunkten; Erzeugen einer einzigartigen Trefferpunkt-ID für jeden Strahl-Fläche-Schnittpunkt; und falls zwei oder mehr der Strahl-Fläche-Schnittpunkte denselben Abstand teilen, dann Vereindeutigen der Reihung der Strahl-Fläche-Schnittpunkte unter Verwendung der Trefferpunkt-ID.
Maschinenlesbares Medium nach Anspruch 21, wobei die einzigartige Trefferpunkt-ID eine Primitiv-ID aufweist, die ein Primitiv der Fläche einzigartig identifiziert.
Maschinenlesbares Medium nach Anspruch 22 oder 23, ferner aufweisend Programmcode, um die Maschine zu veranlassen, die Operation auszuführen: Erzeugen einer absoluten Reihung der Strahl-Fläche-Schnittpunkte unter Verwendung einer Kombination der Abstände und Trefferpunkt-IDs.
Maschinenlesbares Medium nach Anspruch 21, 22 oder 23, ferner aufweisend Programmcode, um die Maschine zu veranlassen, die Operation auszuführen: Ausführen einer ersten Querungsoperation unter Verwendung eines ersten Strahl-Fläche-Schnittpunkts; und Weitergeben von Informationen von der ersten Querungsoperation zu einer zweiten Querungsoperation, unter Verwendung eines zweiten Strahl-Fläche-Schnittpunkts mit einer sequentiellen Reihung, die direkt dem ersten Strahl-Fläche-Schnittpunkt folgt.
Maschinenlesbares Medium nach Anspruch 21, 22 oder 24, ferner aufweisend Programmcode, um die Maschine zu veranlassen, die Operation auszuführen: Beibehalten eines Stapels oder von Prioritätsreihen, die Strahl-Fläche-Schnittpunkte beinhalten, die noch zu queren sind; und nach Ausführen einer Querung unter Verwendung eines Strahl-Fläche-Schnittpunkts, Identifizieren eines nächsten Strahl-Fläche-Schnittpunkts von dem Stapel oder der Prioritätsreihe für eine nächste Querungsoperation.
Maschinenlesbares Medium nach Anspruch 21, 22 oder 25, ferner aufweisend Programmcode, um die Maschine zu veranlassen, die Operation auszuführen: Ausführen von Querungen, bis garantiert ist, dass ein momentan nächstgelegener Strahl-Fläche-Schnittpunkt nähergelegen ist als irgendein nichtgequerter Strahl-Fläche-Schnittpunkt im Stapel oder in der Prioritätsreihe.