DE102019101873A1

DE102019101873A1 - Abfragespezifische Verhaltensmodifizierung von Baumtraversierung

Info

Publication number: DE102019101873A1
Application number: DE102019101873.0A
Authority: DE
Inventors: Samuli Laine; Timo Aila; Tero Karras; Gregory Muthler; William Parsons Jr. Newhall; Ronald Charles Jr. Babich; Craig Kolb; Ignacio Llamas; John Burgess
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2018-08-10
Filing date: 2019-01-25
Publication date: 2020-02-13
Also published as: US10867429B2; US20240013471A1; US20220051468A1; CN110827385A; US11804000B2; US20200051315A1; US11189075B2; US20200302676A1

Abstract

Es werden in manchen Beispielen Verfahren und Systeme zum Ändern der Traversierung einer Beschleunigungsdatenstruktur auf eine hochdynamische abfragespezifische Weise beschrieben, wobei jede Abfrage Testparameter, einen Test-Opcode und eine Abbildung von Testergebnissen auf Aktionen spezifiziert. In einer Beispiel-Strahlverfolgungs-Implementierung wird Traversierung einer Begrenzungsvolumenhierarchie durch einen Strahl durchgeführt, wobei das Vorgabe-Verhalten der Traversierung in Übereinstimmung mit Ergebnissen eines Tests geändert wird, der unter Verwendung des Test-Opcodes und in der Strahldatenstruktur spezifizierter Testparameter und eines weiteren, in einem Knoten der Begrenzungsvolumenhierarchie spezifizierten Testparameters durchgeführt wird. In einer Beispiel-Implementierung ist ein Traversierungs-Koprozessor konfiguriert, um die Traversierung der Begrenzungsvolumenhierarchie durchzuführen.

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung bezieht sich auf die folgenden gemeinsam übertragenen US-Patente und Patentanmeldungen, deren gesamter Inhalt durch Bezugnahme aufgenommen wird: US-Anmeldung Nr. 14/563,872 mit dem Titel „Short Stack Traversal of Tree Data Structures“, eingereicht am 8. Dezember 2014; US-Patent Nr. 9,582,607 mit dem Titel „Block-Based Bounding Volume Hierarchy“; US-Patent Nr. 9,552,664 mit dem Titel „Relative Encoding For A Block-Based Bounding Volume Hierarchy“; US-Patent Nr. 9,569,559 mit dem Titel „Beam Tracing“, eingereicht am 18. März 2015; US-Patent Nr. 10,025,879 mit dem Titel „Tree Data Structures Based on a Plurality of Local Coordinate Systems“; US-Anmeldung Nr. 14/737,343 mit dem Titel „Block-Based Lossless Compression of Geometrie Data“, eingereicht am 11. Juni 2015; und die folgenden gleichzeitig hiermit eingereichten US-Anmeldungen:

• US 16/101,066 mit dem Titel „Method for Continued Bounding Volume Hierarchy Traversal On Intersection Without Shader Intervention“;
• US 16/101,109 mit dem Titel „Method for Efficient Grouping of Cache Requests for Datapath Scheduling“;
• US 16/101,180 mit dem Titel „Robust, Efficient Multiprocessor-Coprocessor Interface“;
• US 16/101,148 mit dem Titel „Conservative Watertight Ray Triangle Intersection“;
• US 16/101,196 mit dem Titel „Method for Handling Out-of-Order Opaque and Alpha Ray/Primitive Intersections“; und
• US 16/101,232 mit dem Titel „Method for Forward Progress and Programmable Timeouts of Tree Traversal Mechanisms in Hardware“.

GEBIET
Die vorliegende Technik bezieht sich auf Computergrafik und insbesondere auf Strahlverfolger (engl. Raytracer). Insbesondere bezieht sich die Technik auf Hardwarebeschleunigung von Computergrafikverarbeitung, einschließlich, aber nicht beschränkt auf Strahlverfolgung (engl. Raytracing). Noch spezieller bezieht sich die nicht einschränkende Beispiel-Technik hierin auf einen hardwarebasierten Traversierungs-Koprozessor, der eine Beschleunigungsdatenstruktur effizient traversiert, z. B. für Echtzeit-Strahlverfolgung und abfragespezifische Modifizierung des Traversierungsverhaltens des Koprozessors.
HINTERGRUND & KURZDARSTELLUNG
Wenn Sie sich in der visuellen Szene vor Ihnen umsehen, werden Sie feststellen, dass einige der interessantesten visuellen Effekte, die Sie sehen, durch Lichtstrahlen erzeugt werden, die mit Oberflächen wechselwirken. Denn Licht ist das Einzige, was wir sehen. Wir sehen keine Objekte - wir sehen das Licht, das von den Objekten reflektiert oder gebrochen wird. Die meisten der Objekte, die wir sehen können, reflektieren Licht (die Farbe eines Objekts wird dadurch bestimmt, welche Teile des Lichts das Objekt reflektiert und welche Teile es absorbiert). Glänzende Oberflächen wie z. B. metallische Oberflächen, glänzende Oberflächen, Keramik, Flüssigkeitsoberflächen und eine Vielzahl anderer (auch die Hornhäute der menschlichen Augen) wirken als Spiegel, die Licht spiegelnd reflektieren. So reflektiert zum Beispiel eine glänzende Metalloberfläche Licht im gleichen Winkel, in dem es auf die Oberfläche trifft. Ein Objekt kann auch Schatten werfen, indem es verhindert, dass Licht auf andere Oberflächen trifft, die sich relativ zu einer Lichtquelle hinter dem Objekt befinden. Wenn Sie sich umsehen, werden Sie feststellen, dass die Anzahl und Art der Reflexionen und die Anzahl, Art und Länge der Schatten von vielen Faktoren abhängen, einschließlich der Anzahl und Art der Beleuchtungen in der Szene. Ein einzelne Punktlichtquelle wie z. B. eine einzelne weit entfernte Glühbirne erzeugt einzelne Reflexionen und harte Schatten. Flächenlichtquellen wie z. B. Fenster oder Flächenleuchten erzeugen andere Arten von Reflexions-Schlaglichtern und weichere Schatten. Mehrere Lichtquellen erzeugen typischerweise mehrere Reflexionen und komplexere Schatten (z. B. erzeugen drei getrennte Punktlichtquellen drei Schatten, die sich je nach der Position der Lichtquellen relativ zu einem Objekt überlappen können).
Wenn Sie Ihren Kopf bewegen, während Sie die Szene betrachten, werden Sie feststellen, dass sich die Reflexionen in Position und Form ändern (die Schatten machen dasselbe). Indem Sie Ihren Standpunkt ändern, ändern Sie die verschiedenen Winkel der Lichtstrahlen, die Ihre Augen erkennen. Dies geschieht sofort - Sie bewegen Ihren Kopf, und die visuelle Szene ändert sich sofort.
Die einfache Handlung, eine Tasse Tee zu trinken, ist eine komplexe visuelle Erfahrung. Die verschiedenen glänzenden Oberflächen der glänzenden Keramik-Tasse auf dem Tisch vor Ihnen reflektieren jedes Licht im Raum, und die Tasse wirft einen Schatten für jedes Licht. Die bewegliche Oberfläche des Tees in der Tasse ist selbst reflektierend. Sie können kleine reflektierte Bilder der Lichtquellen auf der Oberfläche des Tees sehen, und noch kleinere Reflexionen auf dem Teil der Oberfläche des Tees, wo die Flüssigkeit die Wände der Tasse trifft. Die Becherwände werfen außerdem Schatten auf die Oberfläche der Flüssigkeit im Becher. Anheben der Tasse an Ihren Mund bewirkt, dass sich diese Reflexionen und Schatten verschieben und schimmern, wenn sich Ihr Standpunkt ändert und die Oberfläche der Flüssigkeit durch Bewegung bewegt wird.
Wir betrachten diese Komplexität von Reflexionen und Schatten als selbstverständlich. Unser Gehirn ist versiert darin, die Positionen, Größen und Formen von Schatten und Reflexionen zu entschlüsseln und sie als visuelle Hinweise zu verwenden. Zum Teil erkennen wir so die Position von Objekten zueinander, wie wir ein Objekt von einem anderen unterscheiden, und wie wir lernen, woraus Objekte bestehen. Unterschiedliche Objektoberflächen reflektieren unterschiedlich. Spiegelnde (spiegelartige) Reflexion von hartem Metall erzeugt Bilder von reflektierten Objekten, während diffuse Reflexion an rauen Oberflächen für Farbe verantwortlich ist und Objekte weicher beleuchtet. Schatten können weich und diffus oder hart und deutlich sein, je nach Art der Beleuchtung, und die Länge und Richtung der Schatten hängt vom Winkel der Lichtstrahlen in Bezug auf das Objekt und unsere Augen ab.
Anfänger-Künstler versuchen typischerweise nicht, Reflexionen oder Schatten zu zeigen. Sie neigen dazu, flache Szenen zu zeichnen, die keine Schatten und keine Reflexionen oder Schlaglichter haben. Dasselbe galt für Computergrafik der Vergangenheit.
Echtzeit-Computergrafik hat sich in den letzten 30 Jahren enorm weiterentwickelt. Mit der Entwicklung leistungsfähiger Grafikprozessoren (GPUs) in den 80er Jahren, die 3D-Hardware-Grafikpipelines bereitstellen, wurde es möglich, 3D-Grafikanzeigen auf Basis von texturabgebildeten Polygon-Primitiven in Echtzeit als Antwort auf Benutzereingaben zu erzeugen. Solche Echtzeit-Grafikprozessoren basierten auf einer Technik namens Abtastsignalwandlungs-Rasterung (engl. scan conversion rasterization), die ein Mittel zum Bestimmen der Sichtbarkeit von einem einzelnen Punkt oder einer einzelnen Perspektive ist. Mittels dieser Methode werden dreidimensionale Objekte aus Flächen modelliert, die aus geometrischen Primitiven aufgebaut sind, typischerweise Polygonen wie z. B. Dreiecken. Der Abtastsignalwandlungs-Prozess erstellt und projiziert Primitiv-Polygon-Vertices auf eine Ansichtsebene und füllt die Punkte innerhalb der Ränder der Primitive aus. Siehe z. B. Foley, Van Dam, Hughes et al, Computer Graphics: Principles and Practice (2. Ausgabe Addison-Wesley 1995 & 3. Ausgabe Addison-Wesley 2014).
Hardware wird seit langem verwendet, um zu bestimmen, wie jede Polygonfläche zu schattieren und texturabzubilden ist, und um die schattierten, texturabgebildeten Polygonflächen für Anzeige zu rastern. Typische dreidimensionale Szenen sind oft aus Millionen von Polygonen konstruiert. Schnelle moderne GPU-Hardware kann viele Millionen von Grafik-Primitiven für jedes Anzeige-Einzelbild (alle 1/30 oder 1/60 Sekunde) in Echtzeit als Antwort auf Benutzereingaben effizient verarbeiten. Die resultierenden Grafikanzeigen hat man bei einer Vielzahl von grafischen Echtzeit-Benutzeroberflächen verwendet, einschließlich, aber nicht beschränkt auf Augmented Reality, Virtual Reality, Videospiele und medizinische Bildgebung. Traditionell war eine solche interaktive Grafikhardware aber nicht im Stande, Reflexionen und Schatten genau zu modellieren und darzustellen.
Manche haben auf dieser grundlegenden Abtastsignalwandlungs-Rasterungs-Methode andere Techniken aufgebaut, um es Echtzeit-Grafiksystemen zu ermöglichen, ein gewisses Maß an Realismus beim Rendern von Schatten und Reflexionen zu erreichen. Zum Beispiel hat man manchmal Texturabbildung (engl. Texture Mapping) verwendet, um Reflexionen und Schatten in einer 3D-Szene zu simulieren. Eine Möglichkeit, dies zu erreichen, besteht darin, Objekte aus verschiedenen Perspektiven zu transformieren, zu projizieren und zu rastern, die gerasterten Ergebnisse in Texturabbildungen zu schreiben und die Texturabbildungen abzutasten, um Reflexionsabbildung, Umgebungsabbildung und Schattenbildung zu ermöglichen. Obwohl sich diese Techniken als nützlich und moderat erfolgreich erwiesen haben, arbeiten sie nicht in allen Situationen gut. Zum Beispiel kann oft so genannte „Umgebungsabbildung“ (eng. environment mapping) erforderlich sein, wenn die Umgebung unendlich weit vom Objekt entfernt ist. Darüber hinaus kann es sein, dass ein umgebungsabgebildetes Objekt typischerweise nicht im Stande ist, selbst zu reflektieren. Siehe z. B. http://developer.download.nvidia.com/CgTutorial/cg_tutorial_chapter07.html. Diese Einschränkungen resultieren daraus, dass konventionelle Computergrafik-Hardware - obwohl ausreichend schnell für hervorragendes Polygon-Rendern - nicht die Lichtvisualisierung durchführt, die für genaue und realistische Reflexionen und Schatten nötig ist. Manche haben Raster/Text-Approximationen von Reflexionen und Schatten als das visuelle Äquivalent von AM-Radio verglichen.
Es gibt eine andere Grafiktechnik, die physikalisch realistische Sichtbarkeitsbestimmungen für Reflexion und Schattenbildung durchführt. Sie wird als „Strahlverfolgung“ (engl. Raytracing) bezeichnet. Strahlverfolgung wurde Ende der 1960er Jahre entwickelt und in den 1980er Jahren verbessert. Siehe z. B. Apple, „Some Techniques for Shading Machine Renderings of Solids“ (SJCC 1968) S. 27-45; Whitted, „An Improved Illumination Model for Shaded Display“ S. 343-349 Communications of the ACM, Band 23, Ausgabe 6 (Juni 1980); und Kajiya, „The Rendering Equation“, Computer Graphics (SIGGRAPH 1986 Proceedings, Band 20, Seiten 143-150). Seitdem wird Strahlverfolgung bei Nicht-Echtzeit-Grafikanwendungen wie z. B. Design und Filmherstellung verwendet. Wer „Finding Dorie“ (2016) oder andere Pixar-Animationsfilme gesehen hat, hat das Ergebnis der Strahlverfolgungsmethode für Computergrafik gesehen - nämlich realistische Schatten und Reflexionen. Siehe z. B. Hery et al., „Towards Bidirectional Path Tracing at Pixar“ (2016).
Strahlverfolgung ist ein Grundprinzip, das bei einer Vielzahl von Render-Algorithmen verwendet wird, einschließlich zum Beispiel Pfadverfolgung (engl. Path Tracing) und Metropolis Light Transport. Bei einem Beispiel-Algorithmus simutiert Strahlverfolgung die Physik von Licht, indem der Lichttransport durch die Szene modelliert wird, um alle globalen Effekte (einschließlich zum Beispiel Reflexionen von glänzenden Oberflächen) unter Verwendung von Strahlenoptik zu berechnen. Bei solchen Anwendungen von Strahlverfolgung kann versucht werden, jeden von vielen hundert oder tausend Lichtstrahlen zu verfolgen, während sie durch die dreidimensionale Szene von potenziell mehreren Lichtquellen zum Standpunkt wandern. Häufig werden solche Strahlen relativ zum Auge durch die Szene verfolgt und gegen eine Datenbank aller Geometrien in der Szene getestet. Die Strahlen können vorwärts von Lichtquellen zum Auge oder rückwärts vom Auge zu den Lichtquellen verfolgt werden, oder sie können verfolgt werden, um zu sehen, ob Pfade, die an der virtuellen Kamera beginnen und am Auge beginnen, eine klare Sichtlinie haben. Das Testen bestimmt entweder den nächstgelegenen Schnittpunkt (um zu bestimmen, was vom Auge aus sichtbar ist) oder verfolgt Strahlen von der Oberfläche eines Objekts zu einer Lichtquelle, um zu bestimmen, ob etwas dazwischen liegt, das die Übertragung von Licht zu diesem Punkt im Raum blockieren würde. Da die Strahlen den Lichtstrahlen in der Realität ähnlich sind, machen sie eine Reihe von realistischen Effekten verfügbar, die mit der rasterbasierten Echtzeit-3D-Grafiktechnik, die man in den letzten dreißig Jahren implementiert hat, nicht möglich sind. Da jeder beleuchtende Strahl von jeder Lichtquelle innerhalb der Szene bewertet wird, wenn er jedes Objekts in der Szene durchläuft, können die resultierenden Bilder so aussehen, als wären sie in der Realität fotografiert worden. Dementsprechend werden diese Strahlverfolgungsverfahren seit langem bei professionellen Grafikanwendungen wie z. B. Design und Film eingesetzt, wo sie inzwischen über rasterbasiertes Rendern dominieren.
Die größte Herausforderung bei Strahlverfolgung war im Allgemeinen die Geschwindigkeit. Strahlverfolgung erfordert, dass das Grafiksystem für jedes Einzelbild jeden von vielen Millionen Lichtstrahlen berechnet und analysiert, die auf jede Oberfläche der Szene treffen (und möglicherweise davon reflektiert werden). In der Vergangenheit war es unmöglich, diese enorme Menge Berechnungskomplexität in Echtzeit durchzuführen.
Ein Grund dafür, dass moderne GPU-3D-Grafikpipelines schattierte, texturabgebildete Oberflächen so schnell rendern, ist, dass sie effizient Kohärenz nutzen. Bei konventioneller Abtastsignalwandlung wird davon ausgegangen, dass alles durch ein gemeinsames Fenster in einer gemeinsamen Bildebene betrachtet und auf einen einzigen Blickwinkel hinab projiziert wird. Jedes Dreieck oder andere Primitiv wird durch die Grafikpipeline gesendet und deckt eine Anzahl von Pixeln ab. Alle zugehörigen Berechnungen können für alle Pixel, die aus diesem Dreieck gerendert werden, gemeinsam genutzt werden. Rechteckige Pixel-Kacheln, die kohärenten Sichtlinien entsprechen, die durch das Fenster hindurchgehen, können somit Gruppen von Threads entsprechen, die im gleichen Streaming-Prozessor im Gleichschritt laufen. Alle Pixel, die zwischen die Ränder des Dreiecks fallen, werden als das gleiche Material angenommen, das den gleichen Shader (auf Deutsch „Schattierer“) laufen lässt und benachbarte Gruppen von Texeln aus den gleichen Texturen abruft. Im Gegensatz dazu können bei Strahlverfolgung Strahlen an einem gemeinsamen Punkt (einer Lichtquelle oder einem virtuellen Kameraobjektiv) beginnen oder enden, doch da sie sich durch die Szene ausbreiten und mit verschiedenen Materialien wechselwirken, divergieren sie schnell. Zum Beispiel führt jeder Strahl eine Suche nach dem nächstgelegenen Objekt durch. Es kann Cache-Speicherung und gemeinsame Nutzung von Ergebnissen durchgeführt werden, doch da jeder Strahl potenziell andere Objekte treffen kann, ist die Art der Kohärenz, die GPUs traditionell in Verbindung mit texturabgebildeten schattierten Dreiecken genutzt haben, nicht vorhanden (z. B. ein gemeinsamer Blickwinkel, Fenster und Bildebene sind nicht für Strahlverfolgung vorhanden). Dies macht Strahlverfolgung viel rechenintensiver als andere Grafikmethoden - und daher viel schwieriger interaktiv durchführbar.
Man hat viel Forschung betrieben, um den Prozess, Strahlen zu verfolgen, effizienter und zeitnaher zu gestalten. Siehe z. B. Glassner, An Introduction to Ray Tracing (Academic Press Inc., 1989). Da bei Strahlverfolgung jeder Strahl naturgemäß unabhängig von dem Rest bewertet wird, hat man Strahlverfolgung als „unangenehm parallel“ bezeichnet. Siehe z. B. Akenine-Möller et al., Real Time Rendering in Abschnitt 9.8.2, Seite 412 (Third Ed. CRC Press 2008). Wie oben erwähnt, beinhaltet Strahlverfolgung effektiv das Testen jedes Strahls gegen alle Objekte und Oberflächen in der Szene. Eine Optimierung namens „Beschleunigungsdatenstruktur“ und zugehörige Prozesse ermöglicht es dem Grafiksystem, eine „Teile-und-Herrsche“-Methode über die Beschleunigungsdatenstruktur hinweg zu verwenden, um festzustellen, welche Oberflächen der Strahl trifft und welche Oberflächen der Strahl nicht trifft. Jeder Strahl traversiert die Beschleunigungsdatenstruktur auf eine individualistische Weise. Dies bedeutet, dass das Widmen von mehr Prozessoren für Strahlverfolgung eine nahezu lineare Leistungssteigerung ermöglicht. Mit zunehmender Parallelität von Grafikverarbeitungssystemen haben manche begonnen, sich die Möglichkeit vorzustellen, dass Strahlverfolgung in Echtzeit durchgeführt werden könnte. Zum Beispiel hat man Mitte der 2000er Jahre an der Universität des Saarlandes ein frühes Spezialhardwaresystem für interaktive Strahlverfolgung entwickelt, das eine gewisse Programmierbarkeit für Verwendung von Geometrie-, Vertex- und Beleuchtungs-Shadern bot. Siehe Woop et al., „RPU: A Programmable Ray Processing Unit for Real Time Ray Tracing“ (ACM 2005). Als weiteres Beispiel entwickelte Advanced Rendering Technology „RenderDrive“ auf Basis eines Arrays von AR250/350-Render-Prozessoren, die von ARM1 abgeleitet und mit kundenspezifischen Pipelines für Strahl/Dreieck-Schnittpunkt- und SIMD-Vektor- und Textur-Mathematik erweitert worden sind, jedoch ohne Traversierungslogik mit fester Funktion. Siehe z. B. http://www.graphicshardware.org/previous/ www_2001/presentations/Hot3D_Daniel_Hall.pdf
Im Jahr 2010 nutzte NVIDIA dann den hohen Grad an Parallelität von NVIDIA-GPUs und anderen hochparallelen Architekturen für die Entwicklung der OptiX™ Strahlverfolgungs-Engine. Siehe Parker et al., „OptiX: A General Purpose Ray Tracing Engine“ (ACM Transactions on Graphics, Band 29, Nr. 4, Artikel 66, Juli 2010). Neben Verbesserungen bei APIs (Anwendungsprogrammierschnittstellen) war einer der Fortschritte von OptiX™ die Verbesserung der Beschleunigungsdatenstrukturen, die zum Finden eines Schnittpunkts zwischen einem Strahl und der Szenengeometrie verwendet werden. Solche Beschleunigungsdatenstrukturen sind gewöhnlich räumliche oder Objekt-Hierarchien, die vom Strahlverfolgungs-Traversierungsalgorithmus verwendet werden, um effizient nach Primitiven zu suchen, die einen gegebenen Strahl potentiell schneiden. OptiX™ stellt eine Reihe von verschiedenen Beschleunigungsstruktur-Typen zur Verfügung, aus denen die Anwendung wählen kann. Jede Beschleunigungsstruktur im Knotendiagramm kann ein anderer Typ sein, was Kombinationen von hochwertigen statischen Strukturen mit dynamisch aktualisierten Strukturen ermöglicht.
Die programmierbare Strahlverfolgungs-Pipeline OptiX™ brachte erhebliche Fortschritte, war aber an sich immer noch nicht im Stande, interaktive Echtzeit-Reaktionen auf Benutzereingaben auf relativ kostengünstigen Computerplattformen für komplexe 3D-Szenen zu liefern. Seitdem hat NVIDIA Hardwarebeschleunigungsfähigkeiten für Strahlverfolgung entwickelt. Siehe z. B. US 9,582,607 ; US 9,569,559 ; US 20160070820 ; und US 20160070767 .
Angesichts des großen Potenzials eines wirklich interaktiven Echtzeit-Strahlverfolgungs-Grafikverarbeitungssystems zum Rendern hochwertiger Bilder beliebiger Komplexität als Antwort auf zum Beispiel Benutzereingaben ist weitere Arbeit möglich und wünschenswert.
Figurenliste

1 veranschaulicht ein Beispiel für ein nicht einschränkendes Strahlverfolgungs-Grafiksystem.
2A zeigt ein Beispiel für ein spiegelndes Objekt.
2B zeigt das Beispiel-Objekt innerhalb eines Begrenzungsvolumens.
2C zeigt eine volumetrische Beispiel-Unterteilung des Begrenzungsvolumens von 2B.
2D, 2E und 2F zeigen beispielhaft weitere Stufen von volumetrischer Unterteilung des Begrenzungsvolumens zum Erzeugen einer Begrenzungsvolumenhierarchie (BVH).
2G zeigt einen Beispiel-Teil des Objekts, das aus Primitiv-Oberflächen, in diesem Fall Dreiecken, besteht.
3A-3C zeigen beispielhaft vereinfachte Strahlverfolgungs-Tests zum Bestimmen, ob der Strahl ein Begrenzungsvolumen, das Geometrie enthält, durchläuft und ob der Strahl Geometrie schneidet.
4 veranschaulicht ein Beispiel- Strahlverfolgungs-Flussdiagramm.
5A-5C zeigen beispielhaft verschiedene Szenarien für Strahl-Primitiv-Sch nittpunkte.
6A und 6B zeigen ein Beispiel dafür, wie sich Texturabbildung auf Strahl-Primitiv-Schnittpunkt-Ergebnisse auswirken kann.
7A und 7B veranschaulichen Strahl-Instanz-Transformationen.
8A veranschaulicht eine nicht einschränkende Beispiel-Begrenzungsvolumenhierarchie (BVH).
8B zeigt eine Beispiel-Beschleunigungsdatenstruktur in Form eines Graphen oder Baums.
9 zeigt einen nicht einschränkenden vereinfachten Beispiel-Traversierungs-Koprozessor, der eine Baumtraversierungseinheit (TTU) aufweist.
10A veranschaulicht ein Flussdiagramm einer nicht einschränkenden Beispiel-Strahlverfolgungs-Shading-Pipeline.
10B und 10C veranschaulichen detailliertere Strahlverfolgungs-Pipelines.
11A veranschaulicht eine Beispiel-Abfragedatenstruktur gemäß manchen Ausführungsformen.
11B zeigt eine Beispiel-Knoten-Datenstruktur in der BVH gemäß manchen Ausführungsformen.
12 veranschaulicht eine Beispiel-Traversierungsstapel-Datenstruktur gemäß manchen Ausführungsformen.
13 zeigt eine Beispiel-Ergebniswarteschlangen-Datenstruktur gemäß manchen Ausführungsformen.
14 veranschaulicht einen Prozess, der den für Begrenzungsvolumina in der BVH während Traversierung durchgeführten Hilfs-Strahloperationstest zeigt, gemäß manchen Ausführungsformen.
15 veranschaulicht einen Prozess, der den Prozess von 14 zeigt, wenn ein Blattknoten geschnitten wird, gemäß manchen Ausführungsbeispielen.
16 veranschaulicht einen Prozess, der den Prozess von 14 zeigt, wenn das Strahloperationstest-Ergebnis an den Strahl-Primitiv-Test-Block übergeben wird, gemäß manchen Ausführungsbeispielen.
17 veranschaulicht eine Beispiel-Parallelverarbeitungseinheit (PPU).
18 veranschaulicht eine Beispiel-Speicherpartitionseinheit.
19 veranschaulicht einen Beispiel-Allgemeinverarbeitungscluster (GPC) innerhalb der Parallelverarbeitungseinheit von 17.
20 und 21 veranschaulichen einen Beispiel-Streaming-Multiprozessor.
22 ist ein Konzeptdiagramm eines unter Verwendung von PPUs von 17 implementierten Verarbeitungssystems.
23 erweitert 22, um zusätzliche miteinander verbundene Geräte zu zeigen.
24 ist ein Konzeptdiagramm einer mittels des GPC von 19 implementierten Grafikverarbeitungs-Pipeline.

DETAILLIERTE BESCHREIBUNG VON NICHT EINSCHRÄNKENDEN AUSFÜHRUNGSFORMEN
Die Technik hierin stellt Hardwarefähigkeiten bereit, welche Strahlverfolgung so weit beschleunigen, dass sie Spielen und anderen interaktiven Echtzeit-Computergrafiken die Leistung der Strahlverfolgung beschert, wodurch zunächst hohe Effektqualität bei Schatten und Reflexionen und schließlich globale Beleuchtung ermöglicht wird. In der Praxis bedeutet dies, die Strahlverfolgung gegenüber dem, was in Software auf demselben Grafik-Render-System möglich wäre, um einen Faktor bis zu einer Größenordnung oder mehr zu beschleunigen.
Insbesondere stellt die nicht einschränkende Beispiel-Technik dedizierte Hardware zum Beschleunigen von Strahlverfolgung bereit. In nicht einschränkenden Ausführungsformen beschleunigt ein Hardware-Koprozessor (hierin als „Traversierungs-Koprozessor“ oder in manchen Ausführungsformen als „Baumtraversierungseinheit“ oder „TTU“ bezeichnet) bestimmte Prozesse, die interaktive Strahlverfolgung unterstützen, einschließlich Strahlbegrenzungsvolumen-Schnittpunkttests, Strahl-Primitiv-Schnittpunkttests und Strahl-„Instanz“-Transformationen.
In manchen nicht einschränkenden Ausführungsformen führt der Traversierungs-Koprozessor Abfragen auf einer Beschleunigungsdatenstruktur für Prozesse durch, die auf potenziell massiv-parallelen Streaming-Multiprozessoren (SMs) laufen. Der Traversierungs-Koprozessor traversiert die Beschleunigungsdatenstruktur, um Informationen darüber herauszufinden, wie ein gegebener Strahl mit einem Objekt wechselwirkt, das die Beschleunigungsdatenstruktur beschreibt oder darstellt. Für Strahlverfolgung sind die Traversierungs-Koprozessoren aufrufbar, im Gegensatz zu z. B. Einheiten mit fester Funktion, die eine Operation einmal zwischen logischen Pipeline-Stufen durchführen, die verschiedene Typen von Threads (z. B. Vertex-Threads und Pixel-Threads) laufen lassen.
In manchen nicht einschränkenden Ausführungsformen umfasst die Beschleunigungsdatenstruktur eine Hierarchie von Begrenzungsvolumina (Begrenzungsvolumenhierarchie oder BVH), die rekursiv immer kleiner werdende Begrenzungsvolumen-Unterteilungen einkapselt. Das größte volumetrische Begrenzungsvolumen kann als „Wurzelknoten“ bezeichnet werden. Die kleinsten Unterteilungen einer solchen Hierarchie von Begrenzungsvolumina („Blattknoten“) enthalten Elemente. Die Elemente könnten Primitive (z. B. Polygone wie z. B. Dreiecke) sein, die Oberflächen des Objekts definieren. Oder ein Element könnte ein Bereich sein, der eine ganz neue Ebene der Welt enthält, die als ein Element existiert, da sie der BVH nicht hinzugefügt worden ist (denken Sie an den Halsbandanhänger an der Katze aus „Men in Black“, der eine ganze Miniaturgalaxie darin enthielt). Wenn das Element Primitive umfasst, testet der Traversierungs-Koprozessor Strahlen gegen die Primitive, um zu bestimmen, welche Objektoberflächen die Strahlen schneiden und welche Objektoberflächen entlang des Strahls sichtbar sind.
Der Traversierungs-Koprozessor führt einen Test eines jeden Strahls gegen einen weiten Bereich von Begrenzungsvolumina durch und kann irgendwelche Begrenzungsvolumina, die sich nicht mit diesem Strahl schneiden, aussondern (einem Culling unterziehen). Beginnend an einem Wurzelknoten, der alles in der Szene begrenzt, testet der Traversierungs-Koprozessor jeden Strahl gegen kleinere (potenziell überlappende) Kind-Begrenzungsvolumina, die wiederum die nachkommenden Zweige der BVH begrenzen. Der Strahl folgt den Kind-Zeigern für die Begrenzungsvolumina, die der Strahl trifft, zu anderen Knoten, bis die Blätter oder Endknoten (Volumina) der BVH erreicht sind. Sobald der Traversierungs-Koprozessor die Beschleunigungsdatenstruktur traversiert, um einen End- oder „Blatt“-Knoten zu erreichen, der ein geometrisches Primitiv enthält, führt er einen beschleunigten Strahl-Primitiv-Schnittpunkttest durch, der bestimmt, ob der Strahl dieses Primitiv (und somit die von diesem Primitiv definierte Objektoberfläche) schneidet. Der Strahl-Primitiv-Test kann zusätzliche Informationen über Primitive liefern, die der Strahl schneidet, mit denen die Materialeigenschaften der Oberfläche bestimmt werden können, die für Shading und Visualisierung erforderlich sind. Rekursive Traversierung durch die Beschleunigungsdatenstruktur ermöglicht es dem Traversierungs-Koprozessor, alle Objekt-Primitive zu entdecken, die der Strahl schneidet, oder das nächstgelegene (aus der Perspektive des Standpunkts) Primitiv, das der Strahl schneidet (welches in manchen Fällen das einzige Primitiv ist, das von dem Standpunkt aus entlang des Strahls sichtbar ist).
Der Traversierungs-Koprozessor beschleunigt auch die Transformation jedes Strahls aus dem Welt-Raum in den Objekt-Raum, um immer feiner werdende Begrenzungskasten-Einkapselungen der Primitive zu erhalten und die Duplikation dieser Primitive in der gesamten Szene zu reduzieren. Objekte, die viele Male in der Szene in verschiedenen Positionen, Orientierungen und Maßstäben repliziert werden, können in der Szene als Instanzknoten, die einem Begrenzungskasten und Blattknoten in der Welt-Raum-BVH eine Transformation zuordnen, die auf den Welt-Raum-Strahl angewendet werden kann, um ihn in einen Objektkoordinatenraum zu transformieren, und ein Zeiger auf eine Objekt-Raum-BVH dargestellt werden. Dadurch wird vermieden, dass die Objekt-Raum-BVH-Daten mehrere Male im Welt-Raum repliziert werden, was Speicher und zugehörige Speicherzugriffe spart. Die Instanztransformation erhöht die Effizienz, indem sie den Strahl in den Objekt-Raum transformiert, statt die Geometrie oder die Begrenzungsvolumenhierarchie in den Welt-Raum (Strahl-Raum) transformieren zu müssen, und ist außerdem mit zusätzlichen, konventionellen Rasterungsprozessen kompatibel, welche die Grafikverarbeitung zur Visualisierung der Primitive durchführt.
Bestimmte vorliegend offenbarte nicht einschränkende Ausführungsformen stellen somit einen Traversierungs-Koprozessor, eine neue Untereinheit eines oder einer Gruppe von Streaming-Multiprozessoren SM einer 3D-Grafikverarbeitungs-Pipeline bereit. Um zu verstehen, wo der Traversierungs-Koprozessor in das Gesamtbild passt, kann es hilfreich sein, einige Grundlagen des Algorithmus zu verstehen, der von den meisten oder allen modernen Strahlverfolgern verwendet wird. Man beachte jedoch, dass die Technik hierin eine generische Fähigkeit bietet, für einen Thread, der in einer GPU läuft, zu bestimmen, was das nächst sichtbare Ding von einem gegebenen Punkt entlang einer spezifizierten Richtung ist oder ob irgendetwas zwischen zwei Punkten liegt. Ein häufiger Anwendungsfall für eine solche Fähigkeit wird in Prozessen liegen, die beginnen, Strahlen von Punkten zu verfolgen, die bereits mittels konventioneller Abtastsignalwandlungs-Techniken auf Dreiecken gerastert worden sind. Die offenbarte Technik kann, muss aber nicht notwendigerweise die Abtastsignalwandlungs-Technik ersetzen oder substituieren, und kann sie sie oft ergänzen und kann in Verbindung mit Abtastsignalwandlungs-Techniken verwendet werden, um Bilder mit fotorealistischen Reflexionen, Schatten und anderen Effekten zu verbessern.
Strahlverfolgungs-Techniken
Im Allgemeinen ist Strahlverfolgung ein Render-Verfahren, bei dem Strahlen verwendet werden, um die Sichtbarkeit verschiedener Elemente in der Szene zu bestimmen. Strahlverfolgung kann verwendet werden, um zu bestimmen, ob entlang eines Strahls irgendetwas sichtbar ist (zum Beispiel Testen auf Verdeckungen zwischen einem abgeschatteten Punkt auf einem geometrischen Primitiv und einem Punkt auf einer Lichtquelle) und kann auch zum Bewerten von Reflexionen verwendet werden (was zum Beispiel die Durchführung einer Traversierung zum Bestimmen der nächstgelegenen sichtbaren Oberfläche entlang einer Sichtlinie umfassen kann, so dass Software, die auf einem Streaming-Prozessor läuft, eine Materialschattierungsfunktion entsprechend dem, was getroffen worden ist, bewerten kann - was wiederum einen oder mehrere zusätzliche Strahlen in die Szene entsprechend den Materialeigenschaften des Objekts, das geschnitten worden ist, starten kann), um das Licht zu bestimmen, das entlang des Strahls zurück zum Auge gelangt. Bei Strahlverfolgung im klassischen Whitted-Stil werden Strahlen vom Standpunkt durch das Pixelraster in die Szene geschossen, doch sind auch andere Pfadtraversierungen möglich. Typischerweise wird für jeden Strahl das nächstgelegene Objekt gefunden. Dieser Schnittpunkt kann dann als beleuchtet oder im Schatten bestimmt werden, indem ein Strahl von ihm zu jeder Lichtquelle in der Szene geschossen wird und festgestellt wird, ob sich dazwischen irgendwelche Objekte befinden. Opake Objekte blockieren das Licht, während transparente Objekte es abschwächen. Andere Strahlen können von einem Schnittpunkt aus erzeugt werden. Wenn zum Beispiel die schneidende Oberfläche glänzend oder spiegelnd ist, werden Strahlen in der Reflexionsrichtung erzeugt. Der Strahl kann die Farbe des ersten geschnittenen Objekts annehmen, dessen Schnittpunkt wiederum auf Schatten getestet worden ist. Dieser Reflexionsprozess wird rekursiv wiederholt, bis eine Rekursionsgrenze erreicht ist oder der potenzielle Beitrag nachfolgender Aufpralle unter einen Schwellenwert fällt. Strahlen können auch in der Brechungsrichtung für transparente massive Objekte erzeugt werden und wieder rekursiv bewertet werden. Siehe Akenine-Möller et al., oben zitiert. Die Strahlverfolgungs-Technik ermöglicht es einem Grafiksystem somit, physikalisch korrekte Reflexionen und Schatten zu entwickeln, die nicht den Einschränkungen und Artefakten von Abtastsignalwandlungs-Techniken unterliegen.
Traversierungs-Koprozessor
Die grundlegende Aufgabe, die der Traversierungs-Koprozessor durchführt, besteht darin, einen Strahl gegen alle Primitive (in einer Ausführungsform gewöhnlich Dreiecke) in der Szene zu testen und je nach Anwendungsfall entweder den nächstgelegenen Treffer (entsprechend der entlang des Strahls gemessenen Entfernung) oder einfach den ersten (nicht notwendigerweise nächstgelegenen) angetroffenen Treffer zu melden. Der natürliche Algorithmus wäre eine O(n)-Brute-Force-Suche. Durch Vorverarbeiten der Szenengeometrie und Aufbauen einer geeigneten Beschleunigungsdatenstruktur im Voraus ist es jedoch möglich, die Komplexität im Durchschnittsfall auf O(log n) zu reduzieren. Bei Strahlverfolgung liegt die Zeit für das Finden des nächstgelegenen (oder für Schatten beliebigen) Schnittpunkts für einen Strahl typischerweise in der Größenordnung O(log n) für n Objekte, wenn eine Beschleunigungsdatenstruktur verwendet wird. Zum Beispiel haben Begrenzungsvolumenhierarchien (BVHs) von dem für moderne Strahlverfolgungs-Beschleunigungsdatenstrukturen gewöhnlich verwendeten Typ typischerweise ein O(log n)-Suchverhalten.
Begrenzungsvolumenhierarchien
Die von modernen Strahlverfolgern am häufigsten verwendete Beschleunigungsdatenstruktur ist eine Begrenzungsvolumenhierarchie (BVH), die verschachtelte, achsenausgerichtete Begrenzungskästen (AABBs) aufweist. Die Blattknoten der BVH enthalten die Primitive (z. B. Dreiecke), die auf Schnittpunkte zu testen sind. Die BVH wird am häufigsten durch eine Graph- oder Baumstruktur-Datendarstellung dargestellt. In solchen Fällen kann der Traversierungs-Koprozessor als „Baumtraversierungseinheit“ oder „TTU“ bezeichnet werden.
Bei einer BVH entsprechen Strahlverfolgungsmengen einer Baumsuche, bei der jeder von dem Strahl besuchte Knoten im Baum ein Begrenzungsvolumen für jeden nachkommenden Zweig oder Blatt aufweist und der Strahl nur die nachkommenden Zweige oder Blätter besucht, deren entsprechendes Begrenzungsvolumen er schneidet. Auf diese Weise muss nur eine kleine Anzahl von Primitiven explizit auf Schnittpunkte getestet werden, nämlich diejenigen, die sich in Blattknoten befinden, die von dem Strahl geschnitten werden. In dem nicht einschränkenden Ausführungsbeispiel beschleunigt der Traversierungs-Koprozessor sowohl Baumtraversierungs- (einschließlich der Strahl-Volumen-Tests) als auch Strahl-Primitiv-Tests. Als Teil der Traversierung kann der Traversierungs-Koprozessor auch „Instanztransformationen“ handhaben - Transformieren eines Strahls von Welt-Raum-Koordinaten in das Koordinatensystem eines instanzierten Maschennetzes (Objekt-Raum), z. B. um die Rechenkomplexität des Transformierens der Primitiv-Vertices in den Welt-Raum zu vermeiden. Dies kann auf eine MIMD (Multiple Instruction, Multiple Data) Weise geschehen, was bedeutet, dass die Strahlen unabhängig behandelt werden, sobald sie sich im Traversierungs-Koprozessor befinden.
Nicht einschränkendes Beispiel für interaktives Echtzeit-Strahlverfolgungssystem
1 veranschaulicht ein Beispiel für ein interaktives Echtzeit-Strahlverfolgungsgrafiksystem 100 zum Erzeugen von Bildern unter Verwendung dreidimensionaler (3D) Daten einer Szene oder eines oder mehrerer Objekte. Das System 100 enthält ein Eingabegerät 110, einen oder mehrere Prozessoren 120, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 130, Speicher 140 und ein oder mehrere Displays 150. Das in 1 gezeigte System kann irgendeinen Formfaktor annehmen, einschließlich, aber nicht beschränkt auf einen PC, ein Smartphone oder ein anderes smartes Gerät, ein Videospielsystem, ein tragbares Virtual- oder Augmented-Reality-System, ein Cloud-basiertes Computersystem, ein fahrzeugmontiertes Grafiksystem, ein System auf einem Chip (SoC; Systemon-a-Chip), usw.
Der Prozessor 120 kann eine Mehrkern-Zentralverarbeitungseinheit (CPU) sein, die betriebsfähig ist, um eine Anwendung in Echtzeit interaktiv als Antwort auf das Eingabegerät 110 auszuführen, und deren Ausgabe Bilder zur Anzeige auf dem Display 150 enthält. Das Display 50 kann irgendeine Art von Display sein, wie z. B. ein stationäres Display, ein am Kopf angebrachtes Display wie z. B. eine Display-Brille oder -Schutzbrille, andere Typen von tragbaren Displays, ein Hand-Display, ein fahrzeugmontiertes Display, usw. Zum Beispiel kann der Prozessor 120 eine Anwendung auf Basis von Eingaben ausführen, die von dem Eingabegerät 110 (z. B. einem Joystick, einem Trägheitssensor, einem Umgebungslichtsensor usw.) empfangen worden sind, und die GPU 130 anweisen, Bilder, die den Anwendungsfortschritt zeigen, für Anzeige auf dem Display 150 zu erzeugen.
Auf Basis der Ausführung der Anwendung auf dem Prozessor 120 kann der Prozessor Anweisungen für die GPU 130 ausgeben, um Bilder unter Verwendung von im Speicher 140 gespeicherten 3D-Daten zu erzeugen. Die GPU 130 enthält spezialisierte Hardware zum Beschleunigen der Erzeugung von Bildern in Echtzeit. Zum Beispiel ist die GPU 130 im Stande, Informationen für Tausende oder Millionen von Grafik-Primitiven (Polygonen) in Echtzeit zu verarbeiten, wegen der Fähigkeit der GPU, wiederholte und hochparallele spezialisierte Rechenaufgaben wie z. B. Polygon-Abtastsignalwandlung viel schneller durchzuführen als konventionelle softwaregesteuerte CPUs. Anders als der Prozessor 120, der mehrere Kerne mit einer Menge Cache-Speicher aufweisen kann, die ein paar Software-Threads gleichzeitig handhaben können, kann die GPU 130 zum Beispiel Hunderte oder Tausende von Verarbeitungskernen oder „Streaming-Multiprozessoren“ (SMs) 132 enthalten, die parallel laufen.
In einem Ausführungsbeispiel enthält die GPU 130 eine Vielzahl von programmierbaren Streaming-Multiprozessoren (SMs) 132 und eine hardwarebasierte Grafikpipeline mit einer Grafik-Primitiv-Engine 134 und einer Raster-Engine 136. Diese Komponenten der GPU 130 sind konfiguriert, um Echtzeit-Bildrendern unter Verwendung einer Technik namens „Abtastsignalwandlungs-Rasterung“ durchzuführen, um dreidimensionale Szenen auf einem zweidimensionalen Display 150 anzuzeigen. Bei der Rasterung werden geometrische Bausteine (z. B. Punkte, Linien, Dreiecke, Vierecke, Maschennetze, usw.) einer 3D-Szene auf Pixel des Displays abgebildet (oft über einen Bildpufferspeicher).
Die GPU 130 wandelt die geometrischen Bausteine (d. h. Polygon-Primitive wie z. B. Dreiecke) des 3D-Modells in Pixel des 2D-Bildes um und weist jedem Pixel einen Anfangs-Farbwert zu. Die Grafikpipeline kann Schattierungs-, Transparenz-, Textur- und/oder Farbeffekte auf Teile des Bildes anwenden, indem sie die Farbwerte der Pixel definiert oder anpasst. Die endgültigen Pixelwerte können einem Anti-Aliasing unterzogen, gefiltert und dem Display 150 zur Anzeige zugeführt werden. Viele Software- und Hardware-Fortschritte im Laufe der Jahre haben die subjektive Bildqualität verbessert, indem sie Rasterungstechniken mit Bildraten verwendet haben, die für Echtzeit-Grafik (d. h. 30 bis 60 Einzelbilder pro Sekunde) bei hohen Bildschirmauflösungen wie z. B. 4096 x 2160 Pixel oder mehr auf einem oder mehreren Displays 150 erforderlich sind.
Traversierungs-Koprozessor Erweiterung der Architektur
Damit die GPU 130 Strahlverfolgung in Echtzeit auf eine effiziente Weise durchführen kann, ist die GPU mit einem Traversierungs-Koprozessor 138 ausgestattet, der mit einem oder mehreren SMs 132 gekoppelt ist. Der Traversierungs-Koprozessor 138 enthält Hardwarekomponenten, die konfiguriert sind, um in Strahlverfolgungs-Algorithmen häufig verwendete Operationen durchzuführen. Ein Ziel des Traversierungs-Koprozessors 138 ist es, die bei Strahlverfolgung verwendeten Operationen so weit zu beschleunigen, dass er Echtzeit-Grafikanwendungen (z. B. Spielen) die Leistung der Strahlverfolgung beschert und so hochwertige Schatten, Reflexionen und globale Beleuchtung ermöglicht. Der Traversierungs-Koprozessor 138 enthält in manchen Ausführungsbeispielen Abfragespezifische-Traversierung-Hardware 139, die eine abfragespezifische Programmierung des Verhaltens des Traversierungs-Koprozessors ermöglicht, um z. B. die Flexibilität und Reaktionsfähigkeit von Strahlverfolgungs-Operationen auf dynamische Änderungen und dergleichen in einer gerade gerenderten Szene zu erhöhen. Wie im Folgenden näher erläutert, kann das Ergebnis des Traversierungs-Koprozessors 138 zusammen mit oder als Alternative zu anderen grafikbezogenen Operationen, die in der GPU 130 durchgeführt werden, verwendet werden.
Bei der gezeigten Beispiel-Architektur wird die neue Hardwarekomponente „Traversierungs-Koprozessor“ 138 verwendet, um bestimmte Aufgaben zu beschleunigen, einschließlich, aber nicht beschränkt auf Strahlverfolgung. Strahlverfolgung bezieht sich darauf, einen Strahl in eine Szene zu werfen und zu bestimmen, ob und wo dieser Strahl die Geometrie der Szene schneidet. Dieser grundlegende Strahlverfolgungs-Sichtbarkeitstest ist das fundamentale Grundprinzip, das einer Vielzahl von Render-Algorithmen und -Techniken bei Computergrafik zugrunde liegt. Zum Beispiel kann Strahlverfolgung zusammen mit oder als Alternative zu Rasterung und Z-Pufferung für Abtastung der Szenengeometrie eingesetzt werden. Sie kann auch als Alternative zu (oder in Kombination mit) Umgebungsabbildung und Schattentexturierung verwendet werden, um realistischere Reflexions-, Brechungs- und Schattenbildungseffekte zu erzielen als es mittels Texturierungstechniken oder anderen Raster-„Hacks“ erreicht werden kann. Um Einschränkungen der Bildqualität, die mit Rasterung erreicht werden können, zu überwinden, kann das System 100 auch ganze Bilder oder Teile von Bildern unter Verwendung von Strahlverfolgungs-Techniken erzeugen. Strahlverfolgung kann auch als das Basis-Grundprinzip verwendet werden, um Lichttransport bei physikalisch basierten Render-Algorithmen wie z. B. Pfadverfolgung, Photon Mapping, Metropolis Light Transport und anderen Lichttransport-Algorithmen genau zu simulieren.
Insbesondere können SMs 132 und der Traversierungs-Koprozessor 138 zusammenarbeiten, um Strahlen in ein 3D-Modell zu werfen und zu bestimmen, ob und wo dieser Strahl die Geometrie des Modells schneidet. Strahlverfolgung simuliert direkt, wie sich Licht durch eine virtuelle Umgebung oder Szene bewegt. Die Ergebnisse der Strahlschnittpunkte zusammen mit der Oberflächenstruktur, der Blickrichtung und/oder den Lichtverhältnissen werden verwendet, um Pixelfarbwerte zu bestimmen. Von SMs 132 in Zusammenarbeit mit dem Traversierungs-Koprozessor 138 durchgeführte Strahlverfolgung ermöglicht es computergenerierten Bildern, Schatten, Reflexionen und Brechungen in einer Weise einzufangen, die von Fotos oder Videos der realen Welt nicht unterscheidbar ist. Da Strahlverfolgungs-Techniken teils aufgrund der großen Anzahl von zu verfolgenden Strahlen noch rechenintensiver sind als Rasterung, ist der Traversierungs-Koprozessor 138 im Stande, einige der rechenintensiveren Aspekte dieses Prozesses in Hardware zu beschleunigen.
Bei der nicht einschränkenden Beispiel-Technik hierin beschleunigt der Traversierungs-Koprozessor 138 sowohl Strahl-Kasten-Tests als auch Strahl-Primitiv-Tests. Als Teil der Traversierung kann er auch mindestens eine Ebene der Instanztransformation handhaben und einen Strahl von Welt-Raum-Koordinaten in das Koordinatensystem eines instanzierten Maschennetzes transformieren. In dem nicht einschränkenden Ausführungsbeispiel vollbringt der Traversierungs-Koprozessor 138 all dies auf MIMD-Weise, was bedeutet, dass Strahlen unabhängig einmal innerhalb des Traversierungs-Koprozessors behandelt werden.
In dem nicht einschränkenden Ausführungsbeispiel arbeitet der Traversierungs-Koprozessor 138 als ein Diener (Koprozessor) der SMs (Streaming-Multiprozessoren) 132. Mit anderen Worten, der Traversierungs-Koprozessor 138 in dem nicht einschränkenden Ausführungsbeispiel arbeitet nicht unabhängig, sondern folgt den Befehlen der SMs 132, um bestimmte rechenintensive auf Strahlverfolgung bezogene Aufgaben wesentlich effizienter durchzuführen als es die SMs 132 selbst tun könnten.
In den gezeigten Beispielen empfängt der Traversierungs-Koprozessor 138 Befehle über Anweisungen des SM 132 und schreibt Ergebnisse zurück in eine SM-Registerdatei. Für viele übliche Anwendungsfälle (z. B. opake Dreiecke mit maximal einer Instanzierungsebene) kann der Traversierungs-Koprozessor 138 die Strahlverfolgungs-Abfrage ohne weitere Interaktion mit dem SM 132 bedienen. Komplexere Abfragen (z. B. mit Alpha-getesteten Dreiecken, anderen Primitiven als Dreiecken oder mehreren Instanzierungsebenen) erfordern möglicherweise mehrere Rundgänge. Zusätzlich zum Verfolgen von Strahlen ist der Traversierungs-Koprozessor 138 im Stande, allgemeinere räumliche Abfragen durchzuführen, bei denen ein AABB oder das ausgeweitete Volumen zwischen zwei AABBs (was wir ein „Strahlenbündel“ nennen) an die Stelle des Strahls tritt. Somit ist der Traversierungs-Koprozessor 138 zwar besonders für Beschleunigung von Strahlverfolgungs-Aufgaben geeignet, kann aber auch für andere Aufgaben als Strahlverfolgung verwendet werden.
Zusätzlich zu dem Traversierungs-Koprozessor 138 stellt die zur Unterstützung des Systems 100 von 1 verwendete nicht einschränkende Beispiel-Technik zusätzliche Verbesserungen der beschleunigten Strahlverfolgung für eine Anzahl von Einheiten sowie eine wesentliche der BVH-Konstruktion gewidmete Leistung bereit. Die BVH-Konstruktion muss nicht hardwarebeschleunigt sein (obwohl sie es in manchen nicht einschränkenden Ausführungsformen sein kann), sondern könnte stattdessen mittels hochoptimierter Softwareroutinen implementiert werden, die auf SMs 132 und/oder der CPU 120 und/oder anderen Entwicklungssystemen laufen, z. B. während der Entwicklung einer Anwendung. Die folgende Darstellung beschreibt unter anderem software-sichtbares Verhalten des Traversierungs-Koprozessors 138, Schnittstellen zu umgebenden Einheiten (SMs 132 und das Speicher-Subsystem) und zusätzliche Merkmale, die Teil einer vollständigen Strahlverfolgungs-Lösung sind, wie z. B. bestimmte Erweiterungen der Gruppe von SMs 132 und des Speicher-Cache-Systems.
Wie oben erläutert, ermöglicht der Traversierungs-Koprozessor 138 schnelles Traversieren einer Beschleunigungsdatenstruktur (z. B. einer BVH), um zu bestimmen, welche Primitive (z. B. Dreiecke, die zum Erzeugen einer Szene verwendet werden) in der Datenstruktur von einer Abfragedatenstruktur (z. B. einem Strahl) geschnitten werden. Ausführungsbeispiele ermöglichen weitere Verbesserungen, wie z. B. die Fähigkeit, das Traversierungsverhalten auf Basis von bestimmten Abfrage-Eigenschaften (z. B. Strahl-Eigenschaft) und/oder Eigenschaften von geschnittenen Knoten zu wählen, verbesserte Reaktionsfähigkeit auf dynamische Szenenänderungen, verbesserte BVH-Traversierungsgeschwindigkeiten usw., indem Techniken und Systeme für abfragespezifische Programmierung des Traversierungsprozesses bereitgestellt werden.
Traversieren einer Beschleunigungsdatenstruktur
Eine gute Möglichkeit, Strahlverfolgung zu beschleunigen, ist die Verwendung einer Beschleunigungsdatenstruktur. Die Beschleunigungsdatenstruktur stellt das 3D-Modell eines Objekts oder einer Szene in einer Weise dar, die dabei hilft, schnell zu entscheiden, welchen Teil des Objekts ein bestimmter Strahl wahrscheinlich schneiden wird, und große Teile der Szene, die der Strahl nicht schneiden wird, schnell zu verwerfen. Eine Begrenzungsvolumenhierarchie-Datenstruktur (BVH-Datenstruktur) ist ein Typ von Beschleunigungsdatenstruktur, der dazu beitragen kann, die Anzahl der zu testenden Schnittpunkte zu reduzieren. Die BVH-Datenstruktur stellt eine Szene oder ein Objekt mit einem Begrenzungsvolumen dar und unterteilt das Begrenzungsvolumen in immer kleiner werdende Begrenzungsvolumina, die in Blattknoten enden, die geometrische Primitive enthalten. Die Begrenzungsvolumina sind hierarchisch, was bedeutet, dass die oberste Ebene die Ebene darunter einschließt, diese Ebene die nächste Ebene darunter einschließt, und so weiter. In einer Ausführungsform können Blattknoten andere Blattknoten in der Begrenzungsvolumenhierarchie potentiell überlappen.
Um zu veranschaulichen, wie eine Begrenzungsvolumenhierarchie arbeitet, zeigen 2A-2G eine Teekanne, die rekursiv in immer kleiner werdende hierarchische Begrenzungsvolumina unterteilt ist. 2A zeigt ein Teekanne-Objekt, und 2B zeigt ein Begrenzungsvolumen 202 (in diesem Fall ein Kasten, Würfel oder rechteckiger Quader), das die gesamte Teekanne einschließt. Das Begrenzungsvolumen 202, das durch seine Vertices effizient definiert werden kann, liefert eine Angabe der räumlichen Lage des Objekts und ist typischerweise so bemessen, dass es nur geringfügig größer als das Objekt ist.
Die erste Stufe der Beschleunigungsstruktur-Konstruktion erfasst die Begrenzungskästen der referenzierten Geometrie. Dies wird erreicht, indem für jedes geometrische Primitiv in einem Objekt eine Begrenzungskasten-Prozedur durchgeführt wird, die einen konservativen achsenausgerichteten Begrenzungskasten für ihr Eingangs-Primitiv wie z. B. den in 2B gezeigten Kasten 202 zurückgibt. Die Verwendung dieser Begrenzungskästen als elementare Primitive für die Beschleunigungsstrukturen bietet die notwendige Abstraktion, um Strahlen gegen beliebige benutzerdefinierte Geometrien (einschließlich mehrerer Geometrietypen innerhalb einer einzelnen Struktur) zu verfolgen. Da in 2B das Begrenzungsvolumen 202 größer ist als die Teekanne und sie vollständig enthält, kann ein Strahl, der das Begrenzungsvolumen nicht schneidet, die Teekanne nicht schneiden, obwohl ein Strahl, der das Begrenzungsvolumen schneidet, die Teekanne schneiden kann oder nicht. Da das Begrenzungsvolumen 202 leicht durch die x,y,z-Koordinaten seiner Vertices im 3D-Raum definiert ist und ein Strahl durch seine x,y,z-Koordinaten im 3D-Raum definiert ist, ist der Strahl-Begrenzungsvolumen-Test zum Bestimmen, ob ein Strahl das Begrenzungsvolumen 202 schneidet, unkompliziert (obwohl eine Transformation zur Anpassung an unterschiedliche Koordinatensysteme verwendet werden kann, wie im Folgenden erläutert wird).
2C zeigt das Begrenzungsvolumen 202 unterteilt in kleinere, enthaltene Begrenzungsvolumina. Während das hier zur Veranschaulichung gezeigte Unterteilungsschema eine so genannte oktäre Unterteilung oder ein „Oktbaum“ ist, wobei jedes Volumen in acht kleinere Volumen einheitlicher Größe unterteilt ist, sind viele andere räumliche Hierarchien und Unterteilungsschemata bekannt, wie z. B. ein binärer Baum, ein quartärer Baum, ein k-d-Baum, ein Binärraumteilerbaum (BSP-Baum) und ein Begrenzungsvolumenhierarchie-Baum (BVH-Baum). Siehe z. B. US-Patent 9,582,607.
Jedes der in 2C gezeigten unterteilten Begrenzungsvolumina kann noch weiter unterteilt werden. 2D zeigt eines der unterteilten Volumina 204 von 2C, das weiter unterteilt wird, um zusätzliche unterteilte, eingekapselte Begrenzungsvolumina zu erzeugen. Wie in 2D gezeigt, enthalten einige der unterteilten Begrenzungsvolumina Teile der Teekanne und andere nicht. Volumina, die keinen Teil der Teekanne enthalten, werden nicht weiter unterteilt, da die weiteren Unterteilungen keine weiteren räumlichen Informationen über die Teekanne liefern. Bereits unterteilte Begrenzungsvolumina, die mindestens einen Teil der Teekanne enthalten, können noch weiter rekursiv unterteilt werden - wie das Auftauchen einer jeden aus einer Folge von immer kleiner werdenden Katzen aus den Hüten von Dr. Seuss' The Cat In The Hat Comes Back (1958). Die Teile des Raums innerhalb des Begrenzungsvolumens 202, die Geometrie enthalten, werden rekursiv unterteilt, um es dem Traversierungs-Koprozessor 138 zu ermöglichen, die volumetrischen Unterteilungen zu nutzen, um effizient herauszufinden, wo sich die Geometrie in Bezug auf irgendeinen gegebenen Strahl befindet. Man beachte, dass zwar eine räumliche oder aktive Unterteilung des Volumens möglich ist, viele Implementierungen aber die hierarchische Struktur, die Volumina und Subvolumina definiert, im Voraus erzeugen werden. In solchen Fällen kann der Erbauer die Hierarchie oft aus einzelnen Dreiecken und nicht aus der gesamten Szene herab aufbauen. Aufbauen bedeutet, dass Sie nicht bestimmen müssen, ob ein unterteiltes Volumen irgendetwas enthält, da es per Definition enthält, was in einer Hierarchie von volumetrischen Unterteilungen darunter liegt.
2E zeigt eine weitere derartige Unterteilung des Begrenzungsvolumens 204 in ein weiteres kleineres enthaltenes Begrenzungsvolumen 206, das in diesem Beispiel nur den Ausguss der Teekanne plus eine weitere Oberfläche an der Wand der Teekanne enthält, und 2F zeigt eine zusätzliche Unterteilung des Begrenzungsvolumens 206 in eine noch kleinere enthaltene Unterteilung 208, die das Ende des Ausgusses der Teekanne einkapselt. In Abhängigkeit von der Art und Weise, in der das BVH konstruiert ist, kann das Begrenzungsvolumen 208 nach Wunsch immer weiter unterteilt werden - und der Traversierungs-Koprozessor 138 ermöglicht es dem System 100 von 1, die BVH effizient hinab bis zu einer beliebigen Unterteilungsebene zu traversieren. Die Anzahl und Konfigurationen der rekursiven Unterteilungen hängen von der Komplexität und Konfiguration des gerade modellierten 3D-Objekts sowie anderen Faktoren wie z. B. gewünschten Auflösung, der Entfernung des Objekts vom Standpunkt, usw. ab.
Auf irgendeiner Ebene der Unterteilung (die für unterschiedliche Teile der BVH unterschiedliche Ebenen sein kann) trifft der Traversierungs-Koprozessor 138 auf Geometrie, die das gerade modellierte eingekapselte Objekt bildet. In Analogie zu einem Baum sind die aufeinanderfolgenden volumetrischen Unterteilungen Stamm, Verzweigungen, Äste und Zweige, und die Geometrie zeigt sich schließlich an den ganzen Spitzen des Baums, nämlich den Blättern. In diesem Fall zeigt 2G die Oberfläche des Ausgusses der Teekanne, die durch ein Beispiel-Maschennetz von geometrischen Primitiven definiert ist. Die gezeigten geometrischen Primitive sind Dreiecke, doch können auch andere geometrische Primitive wie z. B. Vierecke, Linien, Rechtecke, Quadriken, Flecken oder andere geometrische Primitive verwendet werden, die Fachleuten vertraut sind (in einer Ausführungsform können solche anderen Typen von Primitiven als Dreiecke ausgedrückt oder in Dreiecke umgewandelt werden). Die geometrischen Primitive in dem Maschennetz stellen die Form der 3D-Oberfläche des gerade modellierten Objekts dar. Das hier gezeigte Beispiel ist ein Maschennetz, doch kann die begrenzte Geometrie eine diskontinuierliche Geometrie enthalten, wie z. B. Partikel, die möglicherweise nicht verbunden sind. In den nicht einschränkenden Ausführungsbeispielen beschleunigt der Traversierungs-Koprozessor 138 auch Strahl-Schnittpunkttests mit dieser Geometrie, um schnell zu bestimmen, welche Dreiecke von einem gegebenen Strahl getroffen werden. Das Bestimmen von Strahl-Primitiv-Schnittpunkten umfasst das Vergleichen der räumlichen xyz-Koordinaten der Vertices jedes Primitivs mit den xyz-Koordinaten des Strahls, um zu bestimmen, ob der Strahl und die Oberfläche, die das Primitiv definiert, den gleichen Raum einnehmen. Der Strahl-Primitiv-Schnittpunkttest kann rechenintensiv sein, da möglicherweise viele Dreiecke zu testen sind. Zum Beispiel ist bei dem in 2G gezeigten Maschennetz der Ausguss der Teekanne allein aus über hundert Dreiecken zusammengesetzt - obwohl es in manchen Implementierungen effizienter sein kann, weiter volumetrisch zu unterteilen und dadurch die Anzahl der Dreiecke in einem solchen „Blattknoten“ auf etwas wie 16 oder weniger zu begrenzen.
Wie oben erörtert, bestimmen Strahlverfolgungsprozeduren, welche geometrischen Primitive einer Szene von einem Strahl geschnitten werden. Aufgrund der großen Anzahl von Primitiven in einer 3D-Szene ist es jedoch möglicherweise nicht effizient oder machbar, jedes geometrische Primitiv auf einen Schnittpunkt zu testen. Beschleunigungsdatenstrukturen wie z. B. BVH ermöglichen eine schnelle Bestimmung, welche Begrenzungsvolumina ignoriert werden können, welche Begrenzungsvolumina geschnittene geometrische Primitive enthalten können und welche geschnittenen geometrischen Primitive für Visualisierung wichtig sind und welche nicht.
Strahl-Schnittpunkttesten
3A-3C veranschaulichen eine Strahlverfolgung, die auf das Begrenzungsvolumen 208 von 2G angewendet wird, das ein Dreiecks-Maschennetz 320 enthält. 3A zeigt einen Strahl 302 in einem virtuellen Raum mit Begrenzungsvolumina 310 und 315. Um zu bestimmen, ob der Strahl 302 ein oder mehrere Dreiecke in dem Maschennetz 320 schneidet, könnte jedes Dreieck direkt gegen dem Strahl 302 getestet werden. Um den Prozess zu beschleunigen (da das Objekt viele tausend Dreiecke enthalten könnte), wird der Strahl 302 zuerst gegen die Begrenzungsvolumina 310 und 315 getestet. Wenn der Strahl 302 kein Begrenzungsvolumen schneidet, schneidet er keine Dreiecke innerhalb des Begrenzungsvolumens, und alle Dreiecke innerhalb des Begrenzungsvolumens können für die Zwecke dieses Strahls ignoriert werden. Da in 3A der Strahl 302 das Begrenzungsvolumen 310 verfehlt, müssen die Dreiecke des Maschennetzes 320 innerhalb dieses Begrenzungsvolumens nicht auf Schnittpunkte getestet werden. Obwohl das Begrenzungsvolumen 315 von dem Strahl 302 geschnitten wird, enthält das Begrenzungsvolumen 315 keine Geometrie, so dass kein weiteres Testen erforderlich ist.
Wenn andererseits ein Strahl wie z. B. der in 3B gezeigte Strahl 304 ein Begrenzungsvolumen 310 schneidet, das Geometrie enthält, dann kann der Strahl die Geometrie innerhalb des Begrenzungsvolumens schneiden oder nicht, so dass weitere Tests an der Geometrie selbst durchgeführt werden müssen, um mögliche Schnittpunkte zu finden. Da die Strahlen 304, 306 in 3B und 3C ein Begrenzungsvolumen 310 schneiden, das Geometrie enthält, müssen weitere Tests durchgeführt werden, um zu bestimmen, ob irgendwelche (und welche) der Primitive innerhalb des Begrenzungsvolumens geschnitten werden. In 3B würde weiteres Testen der Schnittpunkte mit den Primitiven anzeigen, dass der Strahl 304 zwar das Begrenzungsvolumen 310 durchläuft, aber keines der vom Begrenzungsvolumen eingeschlossenen Primitive schneidet (alternativ könnte, wie oben erwähnt, das Begrenzungsvolumen 310 weiter volumetrisch unterteilt werden, so dass ein Begrenzungsvolumen-Schnittpunkttest verwendet werden könnte, um zu zeigen, dass der Strahl keine Geometrie schneidet oder insbesondere, welche Primitive der Strahl möglicherweise schneidet).
3C zeigt eine Situation, in der das Begrenzungsvolumen 310 von dem Strahl 306 geschnitten wird und Geometrie enthält, die der Strahl 306 schneidet. Der Traversierungs-Koprozessor 138 testet die Schnittpunkte zwischen dem Strahl 306 und den einzelnen Primitiven, um zu bestimmen, welche Primitive der Strahl schneidet.
Strahlverfolgungs-Operationen
4 ist ein Flussdiagramm, das Beispiel-Strahlverfolgungs-Operationen zusammenfasst, die der Traversierungs-Koprozessor 138 in Zusammenarbeit mit SM(s) 132 wie oben beschrieben durchführt. Die Operationen in 4 werden vom Traversierungs-Koprozessor 138 in Zusammenarbeit mit seiner Interaktion mit einem SM 132 durchgeführt. Der Traversierungs-Koprozessor 138 kann somit die Identifizierung eines Strahls von dem SM 132 und den Traversierungsstatus, der einen oder mehrere Knoten in einer oder mehreren BVHs aufzählt, die der Strahl traversieren muss, empfangen. Der Traversierungs-Koprozessor 138 bestimmt, welche Begrenzungsvolumina einer BVH-Datenstruktur der Strahl schneidet (der „Strahl-Complet“-Test 512), und anschließend, ob der Strahl ein oder mehrere Primitive in den geschnittenen Begrenzungsvolumina schneidet und welche Dreiecke geschnitten werden (der „Strahl-Primitiv-Test“ 520). In nicht einschränkenden Ausführungsbeispielen spezifizieren „Complets“ (komprimierte Treelets („Drei-chen“) Wurzel- oder Innenknoten (d. h. Volumina) der Begrenzungsvolumenhierarchie mit Kindern, die andere Complets oder Blattknoten eines einzigen Typs pro Complet sind.
Zuerst überprüft der Traversierungs-Koprozessor 138 den Traversierungsstatus des Strahls. Wenn ein Stapel, den der Traversierungs-Koprozessor 138 für den Strahl unterhält, leer ist, ist die Traversierung abgeschlossen. Wenn sich ein Eintrag oben auf dem Stapel befindet, sendet der Traversierungs-Koprozessor 138 eine Anforderung an das Speicher-Subsystem, diesen Knoten auszulesen. Der Traversierungs-Koprozessor 138 führt dann einen Begrenzungskasten-Test 512 durch, um zu bestimmen, ob ein Begrenzungsvolumen einer BVH-Datenstruktur von einem bestimmten Strahl geschnitten wird, den der SM 132 spezifiziert (Schritt 512, 514). Wenn der Begrenzungskasten-Test feststellt, dass das Begrenzungsvolumen nicht von dem Strahl geschnitten wird („Nein“ in Schritt 514), ist es nicht notwendig, weitere Testen für Visualisierung durchzuführen, und der Traversierungs-Koprozessor 138 kann dieses Ergebnis an den anfordernden SM 132 zurückgeben. Denn wenn ein Strahl ein Begrenzungsvolumen verfehlt (wie in 3A in Bezug auf das Begrenzungsvolumen 310), dann verfehlt der Strahl alle anderen kleineren Begrenzungsvolumina innerhalb des gerade getesteten Begrenzungsvolumens und irgendwelche Primitive, die das Begrenzungsvolumen enthält.
Ergibt der vom Traversierungs-Koprozessor 138 durchgeführte Begrenzungskasten-Test, dass das Begrenzungsvolumen von dem Strahl geschnitten wird („Ja“ in Schritt 514), dann bestimmt der Traversierungs-Koprozessor, ob das Begrenzungsvolumen in kleinere Begrenzungsvolumina unterteilt werden kann (Schritt 518). In einem Ausführungsbeispiel führt der Traversierungs-Koprozessor 138 nicht notwendigerweise selbst irgendeine Unterteilung durch. Vielmehr hat jeder Knoten in der BVH ein oder mehrere Kinder (wobei jedes Kind ein Blatt oder ein Zweig in der BVH ist). Für jedes Kind gibt es ein Begrenzungsvolumen und einen Zeiger, der zu einem Zweig oder einem Blattknoten führt. Wenn ein Strahl einen Knoten unter Verwendung des Traversierungs-Koprozessors 138 verarbeitet, testet er sich selbst gegen die Begrenzungsvolumina der Kinder des Knotens. Der Strahl schiebt nur Stapeleinträge für diejenigen Zweige oder Blätter auf seinen Stapel, deren darstellende Begrenzungsvolumina getroffen worden sind. Wenn ein Strahl einen Knoten in dem Ausführungsbeispiel abruft, testet er nicht gegen das Begrenzungsvolumen des Knotens - er testet gegen die Begrenzungsvolumina der Kinder des Knotens. Der Traversierungs-Koprozessor 138 schiebt Knoten, deren Begrenzungsvolumina von einem Strahl getroffen werden, in einer durch die Strahlkonfiguration bestimmten Reihenfolge auf den Traversierungsstapel des Strahls. Zum Beispiel ist es möglich, Knoten in der Reihenfolge, in der die Knoten im Speicher erscheinen, oder in der Reihenfolge, in der sie entlang der Länge des Strahls erscheinen, oder in einer anderen Reihenfolge auf den Traversierungsstapel zu schieben. Wenn es weitere Unterteilungen des Begrenzungsvolumens gibt („Ja“ in Schritt 518), dann wird auf diese weiteren Unterteilungen des Begrenzungsvolumens zugegriffen, und der Begrenzungskasten-Test wird für jedes der resultierenden unterteilten Begrenzungsvolumina durchgeführt, um zu bestimmen, welche unterteilten Begrenzungsvolumina von dem Strahl geschnitten werden und welche nicht. Bei diesem rekursiven Prozess können einige der Begrenzungsvolumina durch den Test 514 eliminiert werden, während andere Begrenzungsvolumina in immer weiteren Unterteilungen resultieren können, die vom Traversierungs-Koprozessor 138 rekursiv durch Anwenden der Schritte 512-518 auf Schnittpunkte getestet werden.
Sobald der Traversierungs-Koprozessor 138 bestimmt hat, dass die von dem Strahl geschnittenen Begrenzungsvolumina Blattknoten sind („Nein“ in Schritt 518), führt der Traversierungs-Koprozessor einen Primitiv-(z. B. Dreieck)-Schnittpunkttest 520 durch, um zu bestimmen, ob der Strahl Primitive in den geschnittenen Begrenzungsvolumina schneidet und welche Primitive der Strahl schneidet. Der Traversierungs-Koprozessor 138 führt somit eine Traversierung von geschnittenen nachkommenden Verzweigungsknoten nach Tiefe durch, bis Blattknoten erreicht sind. Der Traversierungs-Koprozessor 138 verarbeitet die Blattknoten. Wenn die Blattknoten Primitiv-Bereiche sind, testet der Traversierungs-Koprozessor 138 sie gegen den Strahl. Wenn die Blattknoten Instanzknoten sind, wendet der Traversierungs-Koprozessor 138 die Instanztransformation an. Wenn die Blattknoten Element-Bereiche sind, gibt der Traversierungs-Koprozessor 138 sie an den anfordernden SM 132 zurück. In dem nicht einschränkenden Ausführungsbeispiel kann den SM 132 dem Traversierungs-Koprozessor 138 befehlen, verschiedene Arten von Strahl-Primitiv-Schnittpunkttests durchzuführen und in Abhängigkeit von den Operationen, die von einer Anwendung (oder einem Software-Stapel, auf dem die Anwendung läuft) kommen und von dem SM an die TTU weitergeleitet werden, verschiedene Ergebnisse zu melden. Zum Beispiel kann der SM 132 dem Traversierungs-Koprozessor 138 befehlen, das nächstgelegene sichtbare Primitiv zu melden, das durch den Schnittpunkttest aufgedeckt worden ist, oder alle Primitive zu melden, die der Strahl schneidet, unabhängig davon, ob es sich um das nächstgelegene sichtbare Primitiv handelt. Der SM 132 kann diese verschiedenen Ergebnisse für verschiedene Arten von Visualisierung verwenden. Sobald der Traversierungs-Koprozessor 138 mit der Verarbeitung der Blattknoten fertig ist, kann es weitere Verzweigungsknoten (die früher auf den Stapel des Strahls geschoben worden sind) zu Testen geben.
Mehrere Schnittpunkte
Wie in 3C gezeigt, kann insbesondere irgendein gegebener Strahl mehrere Primitive innerhalb eines Begrenzungsvolumens schneiden. Ob der Strahl-Schnittpunkt innerhalb eines gegebenen Primitivs für Visualisierung von Bedeutung ist, hängt von den Eigenschaften und der Position dieses Primitivs sowie von den Visualisierungsprozeduren ab, die der SM 132 durchführt. Zum Beispiel können Primitive opak, transparent oder teilweise transparent (d.h. transluzent) sein. Opake Primitive blockieren den Durchgang eines Strahls durch das Primitiv, weil das Auge nicht durch die opake Oberfläche des Primitivs sehen kann. Transparente Primitive lassen den Strahl durch (weil das Auge durch das transparente Primitiv hindurchsehen kann), doch kann die Situation komplexer sein. Zum Beispiel können transparente Primitive spiegelnde Eigenschaften aufweisen, die bewirken, dass ein Teil des Strahls reflektiert wird (denken Sie an Reflexion an einer Fensterscheibe) und der Rest des Strahls hindurchgeht. Andere transparente Primitive werden verwendet, um eine Oberfläche zu schaffen, auf die eine Textur abgebildet wird. Zum Beispiel kann jedes einzelne Blatt eines Baums durch ein transparentes Primitiv modelliert werden, auf das ein Bild des Blattes texturabgebildet wird.
5A-5C veranschaulichen einige dieser Szenarien anhand eines Beispiels von drei Dreiecken, von denen angenommen wird, dass sie sich in demselben Begrenzungsvolumen befinden und jeweils von einem Strahl geschnitten werden. 5A veranschaulicht einen Strahl, der auf diese drei Dreiecke gerichtet ist, wobei das erste Dreieck, das der Strahl in Bezug auf den Standpunkt trifft, opak ist. Da das „vordere“ (aus Sicht der Richtung des Strahls vom Auge her) geschnittene Dreieck opak ist, blockiert dieses Dreieck den Strahl, so dass der Strahl die anderen Dreiecke nicht erreicht, obwohl er sie räumlich schneidet. In diesem Beispiel können die Dreiecke „hinter“ dem opaken Dreieck vom Standpunkt aus ignoriert (ausgesondert) werden, nachdem der Schnittpunkt des opaken Dreiecks identifiziert worden ist, da das „vordere“, opake Dreieck die anderen Dreiecke vor der Sicht des Benutzers entlang des Strahls verdeckt. Culling (Aussondern) wird in 5A-5C durch gestrichelte Linien angezeigt. In diesem Fall muss der Traversierungs-Koprozessor 138 möglicherweise nur die Identifizierung des ersten, opaken Dreiecks an den SM 132 melden.
5B veranschaulicht einen Strahl, der auf die gleichen drei Dreiecke gerichtet ist, doch ist das nächstgelegene sichtbare Dreieck nun teilweise transparent statt opak. Da das nächstgelegene sichtbare geschnittene Dreieck mindestens teilweise transparent ist, kann der Strahl durch es hindurchgehen, um das opake Dreieck dahinter zu treffen. In diesem Fall ist das opake Dreieck durch das teilweise transparente Dreieck sichtbar, blockiert aber die Sicht des Benutzers auf das dritte Dreieck entlang des Strahls. Hier kann der Traversierungs-Koprozessor 138 die Identifizierung der beiden vorderen Dreiecke an den SM 132 melden, aber nicht des dritten, ausgesonderten Dreiecks, obwohl der Strahl dieses dritte Dreieck räumlich schneidet. Die Entdeckungsreihenfolge kann hier von Bedeutung sein. Im Falle eines Alpha- und opaken Dreiecks, wenn das opake zuerst gefunden worden ist, gibt der Traversierungs-Koprozessor 138 das opake Dreieck an den SM 132 mit einem Traversierungsstatus zurück, der das Testen am Alpha-Dreieck wieder aufnehmen wird. Zwar gibt es hier eine Bedeutung, dass das Alpha transparent bedeutet, doch bedeutet es wirklich: „Bringe mich zum SM 132 zurück und lasse den SM entscheiden, wie damit umzugehen ist“. Zum Beispiel kann ein Alpha-Dreieck entsprechend einer Textur oder Funktion beschnitten werden, so dass Teile des Dreiecks weggeschnitten werden (d. h. abwesend, nicht transparent). Der Traversierungs-Koprozessor 138 weiß nicht, wie der SM 132 die Alpha-Dreiecke behandeln wird (d. h. er behandelt transparente Dreiecke nicht anders als beschnittene Dreiecke). Somit können Alpha-Dreiecke das Licht, das von Punkten jenseits davon entlang des Strahls kommt, blockieren oder färben oder nicht, und in Ausführungsbeispielen erfordern sie ein Eingreifen des SM 132, um diese Dinge zu handhaben/bestimmen.
5C veranschaulicht ein Szenario, in dem die ersten beiden Dreiecke, die der Strahl trifft, teilweise transparent sind. Da das erste und das zweite geschnittene Dreieck mindestens teilweise transparent sind, durchläuft der Strahl das erste und das zweite Dreieck, um auf das ebenfalls schneidende dritte opake Dreieck zu treffen. Da das dritte geschnittene Dreieck opak ist, blockiert es den Strahl, und der Strahl trifft nicht auf irgendwelche anderen Dreiecke hinter dem dritten Dreieck, auch wenn sie räumlich von ihm geschnitten werden können. In diesem Fall kann der Traversierungs-Koprozessor 138 alle drei Dreiecke an den SM 132 melden, muss aber keine weiteren Dreiecke hinter dem opaken Dreieck melden, da das opake Dreieck den Strahl daran hindert, diese zusätzlichen Dreiecke zu erreichen.
In manchen Modi muss der SM 132 jedoch möglicherweise die Identitäten aller Dreiecke kennen, die der Strahl schneidet, unabhängig davon, ob sie opak oder transparent sind. In diesen Modi kann der Traversierungs-Koprozessor 138 einfach den Schnittpunkttest durchführen und die Identitäten aller Dreiecke zurückgeben, die der Strahl räumlich schneidet (in solchen Modi wird der Traversierungs-Koprozessor für alle drei in 5A-5C gezeigten Szenarien die gleichen Schnittpunktergebnisse zurückgeben) und es dem SM 132 ermöglichen, sie zu sortieren - oder in manchen Fällen dem Traversierungs-Koprozessor 138 befehlen, weitere Tests an diesen Dreiecken durchzuführen.
Wie im Folgenden näher erläutert, kann der Traversierungs-Koprozessor 138, wenn ein Strahl ein opakes Dreieck schneidet, bei manchen Operationen so programmiert sein, dass er die Länge des gerade getesteten Strahls auf die Position des Schnittpunkts mit einem opaken Dreieck reduziert, so dass er keine Dreiecke „hinter“ dem geschnittenen Dreieck meldet. Wenn ein teilweise transparentes Dreieck als von einem Strahl geschnitten bestimmt wird, gibt der Traversierungs-Koprozessor 138 für Visualisierungszwecke eine vollständigere Liste von Dreiecken zurück, auf die der Strahl trifft, und der anfordernde SM 132 kann weitere Verarbeitung durchführen, um zum Beispiel auf Basis irgendeiner Textur oder anderer Eigenschaften des Dreiecks zu bestimmen, ob der Strahl blockiert, durchgelassen oder teilweise durchgelassen und teilweise reflektiert wird. In Ausführungsbeispielen hat der Traversierungs-Koprozessor 138 keinen Zugriff auf Textureigenschaften von Dreiecken und versucht daher nicht, Visualisierung in Bezug auf diese Eigenschaften zu bestimmen.
Texturen oder andere Oberflächenmodifizierungen
Zum Beispiel zeigen 6A und 6B ein transparentes Dreieck 610 mit einer Textur 615 eines auf das Dreieck aufgebrachten Blattes. Man könnte sich ein Dreieck aus Plexiglas mit einem Aufkleber eines Blattes vorstellen. Wie in 6A gezeigt, schneidet der Strahl 620 das transparente Dreieck 610 an einem Punkt, der außerhalb der aufgebrachten Textur 615 liegt. Da der Strahl 620 das Dreieck außerhalb der aufgebrachten Textur 615 schneidet, blockiert die Textur den Strahl 620 nicht, und der Strahl durchläuft das transparente Dreieck 610 ungehindert. Dies ist wie durch die Teile des Plexiglas-Dreiecks sehen zu können, die nicht von dem Blattaufkleber bedeckt sind. Man beachte, dass in einem Ausführungsbeispiel der SM 132 die Sichtbarkeitsbestimmung durchführt, da der Traversierungs-Koprozessor 138 nicht notwendigerweise Zugriff auf Informationen über den Blattaufkleber hat. Der Traversierungs-Koprozessor 138 hilft dem SM 132, indem er die Identifizierung des Dreiecks, das der Strahl schneidet, zusammen mit Informationen über die Eigenschaften dieses Dreiecks an den SM zurückgibt.
In 6B schneidet der Strahl 630 das transparente Dreieck dort, wo die Textur 615 aufgebracht ist. Der SM 132 bestimmt auf Basis davon, ob die Textur 615 den Strahl 630 blockieren oder den Strahl 630 durchlassen wird, ob nachfolgende Traversierung durch den Traversierungs-Koprozessor 138 notwendig ist oder nicht. Wenn der Strahl 630 durch die Textur 615 blockiert wird, werden andere Dreiecke hinter dem transparenten Dreieck 610, die sonst von dem Strahl 630 geschnitten worden wären, von der Textur verdeckt und tragen nicht zur Visualisierung entlang des Strahls bei. In den hierin enthaltenen nicht einschränkenden Ausführungsbeispielen hat der Traversierungs-Koprozessor 138 keinen Zugriff auf Texturinformationen und versucht daher nicht, diese Bestimmung zu beschleunigen. Der Traversierungs-Koprozessor 138 kann zum Beispiel alle Schnittpunkte zwischen dem Strahl und den verschiedenen Dreiecken innerhalb des Objekts an den anfordernden SM 132 zurückgeben, und der SM kann dann die Grafik-Primitiv-Engine 134 verwenden, um weitere Strahlverfolgungs-Visualisierungsbestimmungen durchzuführen. In anderen Ausführungsbeispielen könnte der Traversierungs-Koprozessor 138 einige oder alle dieser Tests beschleunigen, indem er mit der Texturabbildungseinheit und anderen Teilen der 3D-Grafikpipeline innerhalb der Grafik-Primitiv-Engine 134 interagiert, um die notwendigen Visualisierungsbestimmungen vorzunehmen.
Koordinatentransformationen
2A-3C betreffen nur ein einziges Objekt, nämlich eine Teekanne. So wie der Raum, in dem Sie sich gerade befinden, mehrere Objekte enthält, enthalten die meisten 3D-Szenen viele Objekte. Eine 3D-Szene mit einer Teekanne enthält zum Beispiel wahrscheinlich auch eine Tasse, eine Untertasse, einen Milchkrug, einen Löffel, eine Zuckerdose usw., die alle auf einem Tisch stehen. Bei 3D-Grafik wird jedes dieser Objekte typischerweise unabhängig modelliert. Das Grafiksystem 100 verwendet dann Befehle vom Prozessor 120, um sämtliche Modelle zusammen in gewünschten Positionen, Orientierungen und Größen zwecks Visualisierung in die gemeinsame Szene zu setzen (so wie Sie den Tisch zum Servieren von Tee decken und anordnen). Dies bedeutet, dass der SM 132 dem Traversierungs-Prozessor 138 befehlen kann, denselben Strahl in Bezug auf mehrere Objekte in der Szene zu analysieren. Der Umstand, dass jedes dieser Objekte in Position, Orientierung und Größe transformiert wird, wenn es in die gemeinsame Szene gesetzt wird, wird jedoch vom Traversierungs-Koprozessor 138 berücksichtigt und beschleunigt. In nicht einschränkenden Ausführungsbeispielen wird die Transformation vom Welt-Raum zum Objekt-Raum zusammen mit einem Welt-Raum-Begrenzungskasten in der Welt-Raum-BVH gespeichert. Der Traversierungs-Koprozessor 138 beschleunigt den Transformationsprozess, indem er den Strahl aus dem Welt-(Szenen-)Raum in den Objekt-Raum transformiert, um die in 4 gezeigten Tests durchzuführen. Da die Transformation der Geometrie vom Objekt-Raum in den Welt-(Szenen-)Raum rechenintensiv ist, wird diese Transformation insbesondere der Grafikpipeline-Grafik-Primitiv-Engine 134 und/oder Raster-Engine 136 überlassen, um sie als Teil der Rasterung durchzuführen. Der Traversierungs-Koprozessor 138 wandelt stattdessen einen gegebenen Strahl aus dem Welt-Raum in das Koordinatensystem jedes durch eine Beschleunigungsdatenstruktur definierten Objekts um und führt seine Tests im Objekt-Raum durch.
7A und 7B veranschaulichen, wie der Traversierungs-Koprozessor 138 denselben Strahl in drei verschiedene Objekt-Räume transformiert. 7A zeigt drei Objekte auf einem Tisch: eine Tasse, eine Teekanne und einen Krug. Diese drei Objekte und ein Tisch bilden eine Szene, die im Welt-Raum existiert. Ein Strahl, der ebenfalls im Welt-Raum definiert ist, geht von dem Standpunkt aus und schneidet jedes der drei Objekte.
7B zeigt jedes der drei Objekte, wie sie in Objekt-Räumen definiert sind. Jedes dieser drei Objekte wird durch ein jeweiliges Modell definiert, das in einem jeweiligen Objekt-Raum existiert. Der Traversierungs-Koprozessor 138 transformiert in nicht einschränkenden Ausführungsbeispielen den Strahl in den Objekt-Raum jedes Objekts, bevor er die Schnittpunkttests für dieses Objekt durchführt. Diese „Instanztransformation“ erspart den Rechenaufwand für die Transformation der Geometrie jedes Objekts und der zugehörigen volumetrischen Unterteilungen der Beschleunigungsdatenstruktur vom Objekt-Raum in den Welt-Raum für die Zwecke des Traversierungs-Koprozessors 138 beim Durchführen von Schnittpunkttests.
Die anfordernde SM 132 verfolgt, welche Objekte sich in Bezug auf jeden einzelnen Strahl vor welchen anderen Objekten befinden, und klärt die Sichtbarkeit in Fällen, in denen ein Objekt ein anderes Objekt verbirgt, einen Schatten auf ein anderes Objekt wirft und/oder Licht auf ein anderes Objekt reflektiert. Die anfordernde SM 132 kann den Traversierungs-Prozessor 138 verwenden, um jeden dieser Tests zu beschleunigen.
Beispiel-Baum-BVH-Beschleunigungsdatenstruktur
8A und 8B zeigen ein rekursiv unterteiltes Begrenzungsvolumen einer 3D-Szene (8A) und eine entsprechende Baumdatenstruktur (8B), auf die der Traversierungs-Koprozessor 138 zugreifen kann und die für hardwarebeschleunigte Operationen verwendet wird, die von dem Traversierungs-Koprozessor durchgeführt werden. Die Unterteilung der Begrenzungsvolumina kann in einer hierarchischen Baumdatenstruktur dargestellt werden, wobei das in 2B gezeigte große Begrenzungsvolumen durch einen Eltern-Knoten des Baums dargestellt wird und die kleineren Begrenzungsvolumina durch Kind-Knoten des Baums dargestellt werden, die von den Eltern-Knoten umfasst sind. Die kleinsten Begrenzungsvolumina werden als Blattknoten im Baum dargestellt und identifizieren ein oder mehrere geometrische Primitive, die in diesen kleinsten Begrenzungsvolumina enthalten sind.
Die Baumdatenstruktur kann in Speicher außerhalb des Traversierungs-Koprozessors 138 gespeichert und auf Basis von Abfragen, die die SMs 132 an den Traversierungs-Koprozessor 138 ausgeben, ausgelesen werden. Die Baumdatenstruktur enthält eine Vielzahl von Knoten, die in einer Hierarchie angeordnet sind. Die Wurzelknoten N1 der Baumstruktur entsprechen dem Begrenzungsvolumen N1, das alle Dreiecke 01-08 einschließt. Der Wurzelknoten N1 kann die Vertices des Begrenzungsvolumens N1 und Kind-Knoten des Wurzelknotens identifizieren.
In 8A ist das Begrenzungsvolumen N1 in Begrenzungsvolumina N2 und N3 unterteilt. Die Kind-Knoten N2 und N3 der Baumstruktur von 8B entsprechen den in 8A gezeigten Begrenzungsvolumina N2 und N3 und stellen sie dar. Die Kind-Knoten N2 und N3 in der Baumdatenstruktur identifizieren die Vertices der jeweiligen Begrenzungsvolumina N2 und N3 im Raum. Jedes der Begrenzungsvolumina N2 und N3 ist in diesem bestimmten Beispiel weiter unterteilt. Das Begrenzungsvolumen N2 ist in enthaltene Begrenzungsvolumina N4 und N5 unterteilt. Das Begrenzungsvolumen N3 ist in enthaltene Begrenzungsvolumina N6 und N7 unterteilt. Das Begrenzungsvolumen N7 enthält zwei Begrenzungsvolumina N8 und N9. Das Begrenzungsvolumen N8 enthält die Dreiecke O7 und O8, und das Begrenzungsvolumen N9 enthält Blatt-Begrenzungsvolumina N10 und N11 als seine Kind-Begrenzungsvolumina. Das Blatt-Begrenzungsvolumen N10 enthält einen Primitiv-Bereich (z. B. Dreieck-Bereich) O10, und das Blatt-Begrenzungsvolumen N11 enthält einen Element-Bereich O9. Jeweilige Kind-Knoten N4, N5, N6, N8, N10 und N11 der Baumstruktur von 8B entsprechen den Begrenzungsvolumina N4, N5, N6, N8, N10 und N11 von 8A im Raum und stellen sie dar.
Der Baum in 8B ist nur drei bis sechs Ebenen tief, so dass die Volumina N4, N5, N6, N8, N10 und N11 „Blattknoten“ bilden - das heißt, Knoten im Baum, die keine Kind-Knoten haben. 8A zeigt, dass jedes der Blattknoten-Begrenzungsvolumina N4, N5, N6 und N8 zwei Dreiecke der Geometrie in der Szene enthält. Zum Beispiel enthält die volumetrische Unterteilung N4 die Dreiecke O1 & O2; die volumetrische Unterteilung N5 enthält die Dreiecke O3 & O4; die volumetrische Unterteilung N6 enthält die Dreiecke O5 & O6; und die volumetrische Unterteilung N8 enthält die Dreiecke O7 & O8. Die in 8B gezeigte Baumstruktur stellt diese Blattknoten N4, N5, N6 und N7 dar, indem sie sie entsprechenden Dreiecken der Dreiecke 01-08 der Szenengeometrie zuordnet. Um auf diese Szenengeometrie zuzugreifen, traversiert der Traversierungs-Koprozessor 138 die Baumdatenstruktur von 8B bis hinab zu den Blattknoten. Im Allgemeinen können und werden unterschiedliche Teile des Baums unterschiedliche Tiefen haben und unterschiedliche Anzahlen von Dreiecken enthalten. Blattknoten, die volumetrischen Unterteilungen zugeordnet sind, die keine Geometrie enthalten, müssen nicht explizit in der Baumdatenstruktur dargestellt werden (d. h., der Baum wird „beschnitten“).
Gemäß manchen Ausführungsformen kann der bei N7 verwurzelte Teilbaum einen Satz von Begrenzungsvolumina oder BVH darstellen, der in einem anderen Koordinatenraum definiert ist als die Begrenzungsvolumina, die den Knoten N1-N3 entsprechen. Wenn sich das Begrenzungsvolumen N7 in einem anderen Koordinatenraum befindet als sein Eltern-Begrenzungsvolumen N3, kann ein Instanzknoten N7', der die Strahltransformation liefert, die notwendig ist, um den bei N7 verwurzelten Teilbaum zu traversieren, den Rest des Baums mit dem bei N7 verwurzelten Teilbaum verbinden. Der Instanzknoten N7' verbindet das Begrenzungsvolumen oder die BVH entsprechend den Knoten N1-N3 mit den Begrenzungsvolumina oder BVH entsprechend den Knoten N7 usw. durch Definieren der Transformation aus Koordinatenraum von N1-N3 (z. B. Welt-Raum) in den Koordinatenraum von N7 usw. (z. B. Objektbereich).
Die interne Struktur und der Betrieb des Traversierungs-Koprozessors 138
9 zeigt ein vereinfachtes Beispiel-Blockdiagramm des Traversierungs-Koprozessors 138 mit Hardware, die konfiguriert ist, um beschleunigte Traversierungsoperationen wie oben beschrieben durchzuführen (eine noch detailliertere Implementierung dieses Traversierungs-Koprozessors 138 wird im Folgenden beschrieben). Da der in 9 gezeigte Traversierungs-Koprozessor 138 zum Traversieren von baumbasierten Beschleunigungsdatenstrukturen wie z. B. in 8A, 8B gezeigt angepasst ist, kann er auch als „Baumtraversierungseinheit“ oder „TTU“ 700 bezeichnet werden (das Bezugszeichen 700 bezieht sich auf die detailliertere nicht einschränkende Implementierung des in 1 gezeigten Traversierungs-Koprozessors 138). Baumtraversierungsoperationen können zum Beispiel umfassen, zu bestimmen, ob ein Strahl Begrenzungsvolumina und/oder Primitive einer Baumdatenstruktur (z. B. ein BVH-Baum) schneidet, welche Tests umfassen können, den Strahl in einen Objekt-Raum zu transformieren.
Die TTU 700 enthält dedizierte Hardware zum Bestimmen, ob ein Strahl Begrenzungsvolumina schneidet, und dedizierte Hardware zum Bestimmen, ob ein Strahl Primitive der Baumdatenstruktur schneidet. In manchen Ausführungsformen kann die TTU 700 eine Traversierung einer Begrenzungsvolumenhierarchie nach Tiefe unter Verwendung einer Kurzstapeltraversierung mit Schnittpunkttesten von unterstützten Blattknoten-Primitiven und Rückgabe von Alpha-Primitiven und nicht unterstützten Blattknoten-Primitiven (Elementen) mitten in der Traversierung durchführen. Der Schnittpunkt der Primitive wird mit Bezug auf Dreiecke diskutiert, doch können auch andere geometrische Primitive verwendet werden.
Insbesondere enthält die TTU 700 einen Schnittpunktverwaltungsblock 722, einen Strahlverwaltungsblock 730 und einen Stapelverwaltungsblock 740. Jeder dieser Blöcke (und alle anderen Blöcke in 9) können dedizierte Hardware bilden, die durch Logikgatter, Register, in Hardware eingebettete Nachschlagtabellen oder andere kombinatorische Logik usw. implementiert wird.
Der Strahlverwaltungsblock 730 ist verantwortlich für die Verwaltung von Informationen über und die Durchführung von Operationen in Bezug auf einen Strahl, der dem Strahlverwaltungsblock von einem SM 132 spezifiziert wird. Der Stapelverwaltungsblock 740 arbeitet in Verbindung mit Traversierungslogik 712, um Informationen über die Traversierung einer BVH-Beschleunigungsdatenstruktur zu verwalten und diesbezügliche Operationen durchzuführen. Die Traversierungslogik 712 wird von Ergebnissen eines Strahl-Complet-Test-Blocks 710 geleitet, der Schnittpunkte zwischen dem vom Strahlverwaltungsblock 730 angezeigten Strahl und durch die BVH dargestellten volumetrischen Unterteilungen testet, wobei nach Bedarf Instanztransformationen verwendet werden. Der Strahl-Complet-Test-Block 710 liest zusätzliche Informationen bezüglich der BVH über einen L0-Complet-Cache 752, der Teil der TTU 700 ist, aus dem Speicher 140 aus. Die Ergebnisse des Strahl-Complet-Test-Blocks 710 informieren die Traversierungslogik 712 darüber, ob weitere rekursive Traversierungen erforderlich sind. Der Stapelverwaltungsblock 740 unterhält Stapel zum Im-Auge-Behalten von Statusinformationen, wenn die Traversierungslogik 712 von einer Ebene der BVH zu einer anderen übergeht, wobei der Stapelverwaltungsblock Elemente auf den Stapel schiebt, wenn die Traversierungslogik tiefer in die BVH traversiert, und Elemente vom Stapel entfernt, wenn die Traversierungslogik nach oben in der BVH traversiert. Der Stapelverwaltungsblock 740 ist im Stande, dem anfordernden SM 132 in jedem Zeitpunkt, in dem sie der SM anfordert, Statusinformationen (z. B. Zwischen- oder Endergebnisse) zur Verfügung zu stellen.
Der Schnittpunktverwaltungsblock 722 verwaltet Informationen über und führt Operationen in Bezug auf Schnittpunkte zwischen Strahlen und Primitiven durch, wobei nach Bedarf Instanztransformationen verwendet werden. Der Strahl-Primitiv-Test-Block 720 liest auf einer bedarfsweisen Basis Informationen in Bezug auf Geometrie über einen L0-Primitiv-Cache 754, der Teil der TTU 700 ist, aus dem Speicher 140 aus. Der Schnittpunktverwaltungsblock 722 wird über Ergebnisse von Schnittpunkttests informiert, die der Strahl-Primitiv-Test- und Transformationsblock 720 durchführt. Somit führt der Strahl-Primitiv-Test- und Transformationsblock 720 Schnittpunktergebnisse dem Schnittpunktverwaltungsblock 722 zu, der Geometrietreffer und Schnittpunkte an den anfordernden SM 132 meldet.
Eine Stapelverwaltungseinheit 740 prüft den Traversierungsstatus, um zu bestimmen, welcher Typ von Daten auszulesen sind und welcher Datenpfad (Complet oder Primitiv) sie verbrauchen wird. Die Schnittpunkte für die Begrenzungsvolumina werden im Strahl-Complet-Testpfad der TTU 700 bestimmt, die einen oder mehrere Strahl-Complet-Testblöcke 710 und einen oder mehrere Traversierungslogikblöcke 712 enthält. Ein Complet spezifiziert Wurzel- oder Innenknoten eines Begrenzungsvolumens. Somit kann ein Complet ein oder mehrere Begrenzungsvolumina für den Strahl-Complet-Test definieren. Der Strahl-Complet-Testpfad der TTU 700 identifiziert, welche Begrenzungsvolumina von dem Strahl geschnitten werden. Von dem Strahl geschnittene Begrenzungsvolumina müssen weiter verarbeitet werden, um zu bestimmen, ob die den geschnittenen Begrenzungsvolumina zugeordneten Primitive geschnitten werden. Die Schnittpunkte für die Primitive werden im Strahl-Primitiv-Testpfad bestimmt, der einen oder mehrere Strahl-Primitiv-Test- und Transformationsblöcke 720 und einen oder mehrere Schnittpunktverwaltungsblöcke 722 enthält.
Die TTU 700 empfängt Abfragen von einem oder mehreren SMs 132, um Baumtraversierungsoperationen durchzuführen. Die Abfrage kann anfordern, ob ein Strahl Begrenzungsvolumina und/oder Primitive in einer BVH-Datenstruktur schneidet. Die Abfrage kann einen Strahl (z. B. Ursprung, Richtung und Länge des Strahls) und eine BVH-Datenstruktur und einen Traversierungsstatus (z. B. Kurzstapel) identifizieren, der einen oder mehrere Einträge enthält, die auf Knoten in einer oder mehreren Begrenzungsvolumenhierarchien verweisen, die der Strahl besuchen soll. Die Abfrage kann auch Informationen darüber enthalten, wie der Strahl mit bestimmten Typen von Schnittpunkten während der Traversierung umgehen soll. Die Strahlinformationen können im Strahlverwaltungsblock 730 gespeichert werden. Die gespeicherten Strahlinformationen (z. B. Strahllänge) können auf Basis der Ergebnisse des Strahl-Primitiv-Tests aktualisiert werden.
Die TTU 700 kann anfordern, dass die in der Abfrage identifizierte BVH-Datenstruktur aus Speicher außerhalb der TTU 700 ausgelesen wird. Ausgelesene Teile der BVH-Datenstruktur können in Level-Null-(L0)-Cache 750 innerhalb der TTU 700 zwischengespeichert werden, so dass die Informationen für andere zeitkohärente TTU-Operationen verfügbar sind, wodurch Zugriffe auf den Speicher 140 reduziert werden. Teile der BVH-Datenstruktur, die für den Strahl-Complet-Test benötigt werden, können in einem L0-Complet-Cache 752 gespeichert werden, und Teile der BVH-Datenstruktur, die für den Strahl-Primitiv-Test benötigt werden, können in einem L0-Primitiv-Cache 754 gespeichert werden.
Nachdem die für einen angeforderten Traversierungsschritt erforderlichen Complet-Informationen im Complet-Cache 752 verfügbar sind, bestimmt der Strahl-Complet-Test-Block 710 die von dem Strahl geschnittenen Begrenzungsvolumina. Beim Durchführen dieses Tests kann der Strahl aus dem Koordinatenraum der Begrenzungsvolumenhierarchie in einen relativ zu einem Complet definierten Koordinatenraum transformiert werden. Der Strahl wird gegen die Begrenzungskästen getestet, die den Kind-Knoten des Complets zugeordnet sind. In dem nicht einschränkenden Ausführungsbeispiel wird der Strahl nicht gegen den eigenen Begrenzungskasten des Complets getestet, da (1) die TTU 700 den Strahl zuvor gegen einen ähnlichen Begrenzungskasten getestet hat, als sie das Eltern-Begrenzungskasten-Kind getestet hat, das auf dieses Complet verwiesen hat, und (2) ein Zweck des Complet-Begrenzungskastens darin besteht, ein lokales Koordinatensystem zu definieren, innerhalb dessen die Kind-Begrenzungskästen in komprimierter Form ausgedrückt werden können. Wenn der Strahl irgendeinen der Kind-Begrenzungskästen schneidet, werden die Ergebnisse an die Traversierungslogik weitergeleitet, um die Reihenfolge zu bestimmen, in der die entsprechenden Kind-Zeiger dann auf den Traversierungsstapel geschoben werden (weiteres Testen erfordert wahrscheinlich, dass die Traversierungslogik 712 zu der nächsten Ebene der BVH hinunter traversiert). Diese Schritte werden rekursiv wiederholt, bis geschnittene Blattknoten der BVH angetroffen werden.
Der Strahl-Complet-Test-Block 710 kann der Traversierungslogik 612 Strahl-Complet-Schnittpunkte zuführen. Unter Verwendung der Ergebnisse des Strahl-Complet-Tests erstellt die Traversierungslogik 712 Stapeleinträge, die an den Stapelverwaltungsblock 740 weiterzuleiten sind. Die Stapeleinträge können interne Knoten (d. h. einen Knoten, der einen oder mehrere Kind-Knoten enthält), die durch den Strahl-Complet-Test-Block 710 weiter auf Strahlschnittpunkte getestet werden müssen, und/oder in einem geschnittenen Blattknoten identifizierte Dreiecke anzeigen, die durch den Strahl-Primitiv-Test- und Transformationsblock 720 auf Strahlschnittpunkte getestet werden müssen. Der Strahl-Complet-Test-Block 710 kann die Traversierung auf im Stapel identifizierten internen Knoten wiederholen, um alle Blattknoten in der BVH zu bestimmen, die der Strahl schneidet. Die genauen Tests, die der Strahl-Complet-Test-Block 710 durchführt, werden in dem nicht einschränkenden Ausführungsbeispiel durch Modus-Bits, Strahloperationen (siehe unten) und Culling von Treffern bestimmt, und die TTU 700 kann Zwischen- sowie Endergebnisse an den SM 132 zurückgeben.
Die geschnittenen Blattknoten identifizieren Primitive, die von dem Strahl geschnitten werden können oder nicht. Eine Option für die TTU 700 ist, z. B. einen Bereich von in den geschnittenen Blattknoten identifizierten Geometrien dem SM 132 für weitere Verarbeitung zuzuführen. Zum Beispiel kann der SM 132 auf Basis der Informationen, die die TTU 700 als Ergebnis der die BVH traversierenden TTU liefert, selbst bestimmen, ob die identifizierten Primitive von dem Strahl geschnitten werden. Um den SM 132 von dieser Verarbeitung zu entlasten und ihn dadurch unter Verwendung der Hardware der TTU 700 zu beschleunigen, kann der Stapelverwaltungsblock 740 Anforderungen an den Strahl-Primitiv- und Transformationsblock 720 ausgeben, einen Strahl-Primitiv-Test für die Primitive innerhalb geschnittener Blattknoten durchzuführen, die der Strahl-Complet-Test-Block 710 der TTU identifiziert hat. In manchen Ausführungsformen kann der SM 132 eine Anforderung nach dem Strahl-Primitiv-Test zum Testen eines bestimmten Bereichs von Primitiven an den Transformationsblock 720 ausgeben, unabhängig davon, wie dieser Geometriebereich identifiziert worden ist.
Nachdem sichergestellt ist, dass die für einen angeforderten Strahl-Primitiv-Test benötigten Primitiv-Daten im Primitiv-Cache 754 verfügbar sind, kann der Strahl-Primitiv- und Transformationsblock 710 unter Verwendung der im Strahlverwaltungsblock 730 gespeicherten Strahlinformationen Primitive bestimmen, die von dem Strahl geschnitten werden. Der Strahl-Primitiv-Test-Block 720 führt die Identifizierung von Primitiven, die als von dem Strahl geschnitten bestimmt worden sind, dem Schnittpunktverwaltungsblock 722 zu.
Der Schnittpunktverwaltungsblock 722 kann die Ergebnisse des Strahl-Primitiv-Tests an den SM 132 zurückgeben. Die Ergebnisse des Strahl-Primitiv-Tests können Identifikatoren von geschnittenen Primitiven, die Entfernung von Schnittpunkten vom Strahlursprung und andere Informationen über Eigenschaften der geschnittenen Primitiven umfassen. In manchen Ausführungsformen kann der Schnittpunktverwaltungsblock 722 einen vorhandenen Strahl-Primitiv-Test auf Basis von früheren Schnittpunktergebnissen von dem Strahl-Primitiv- und Transformationsblock 710 modifizieren (z. B. durch Modifizieren der Länge des Strahls).
Der Schnittpunktverwaltungsblock 722 kann auch verschiedene Typen von Primitiven im Auge behalten. Zum Beispiel umfassen die verschiedenen Typen von Dreiecken opake Dreiecke, die einen Strahl blockieren, wenn sie geschnitten werden, und Alpha-Dreiecke, die den Strahl blockieren können oder nicht, wenn sie geschnitten werden, oder zusätzliche Behandlung durch den SM erfordern können. Ob ein Strahl durch ein transparentes Dreieck blockiert wird oder nicht, kann zum Beispiel von auf das Dreieck abgebildeten Textur(en), der von der Textur eingenommene Fläche des Dreiecks (siehe 6A und 6B) und der Art und Weise abhängen, in der die Textur das Dreieck modifiziert. Zum Beispiel erfordert Transparenz (z. B. Buntglas) in manchen Ausführungsformen, dass der SM 132 Treffer von transparenten Objekten im Auge behält, so dass sie in strahlparametrischer Reihenfolge sortiert und schattiert werden können, und blockiert den Strahl typischerweise nicht wirklich. Indessen ermöglicht Alpha-„Beschneiden“ das Beschneiden der Form des Primitivs auf Basis der Form einer auf das Primitiv abgebildeten Textur - zum Beispiel Ausschneiden einer Blattform aus einem Dreieck. (Man beachte, dass bei Rastergrafik Transparenz oft als „Alpha Blending“ und Beschneiden als „Alpha-Test“ bezeichnet wird). In anderen Ausführungsformen kann die TTU 700 transparente Treffer für spätere Behandlung durch den SM 132 in Warteschlangen in Speicher schieben und beschnittene Dreiecke direkt behandeln, indem sie Anforderungen an die Textureinheit sendet. Jedes Dreieck kann eine Kennung zum Anzeigen des Dreieck-Typs enthalten. Der Schnittpunktverwaltungsblock 722 ist konfiguriert, um eine Ergebniswarteschlange zum Verfolgen der verschiedenen Typen von geschnittenen Dreiecken zu unterhalten. Zum Beispiel kann die Ergebniswarteschlange eine oder mehrere Geschnittenesopakes-Dreieck-Identifikatoren in einer Warteschlange und einen oder mehrere Transparentes-Dreieck-Identifikatoren in einer anderen Warteschlange speichern.
Für opake Dreiecke kann der Strahlschnittpunkt in der TTU 700 vollständig bestimmt werden, da die Fläche des opaken Dreiecks den Strahl daran hindert, die Oberfläche des Dreiecks zu passieren. Für transparente Dreiecke können in manchen Ausführungsformen Strahlschnittpunkte nicht vollständig in der TTU 700 bestimmt werden, da die TTU 700 den Schnittpunkttest auf Basis der Geometrie des Dreiecks durchführt und möglicherweise keinen Zugriff auf die Textur des Dreiecks und/oder die von der Textur eingenommene Fläche des Dreiecks hat (in anderen Ausführungsformen kann die TTU durch den Texturabbildungsblock der Grafikpipeline mit Texturinformationen versorgt werden). Um vollständig zu bestimmen, ob das Dreieck geschnitten wird, können Informationen über transparente Dreiecke, die der Strahl-Primitiv- und Transformationsblock 710 als geschnitten bestimmt, an den SM 132 gesendet werden, damit der SM die vollständige Bestimmung vornehmen kann, ob das Dreieck die Sichtbarkeit entlang des Strahls beeinflusst.
Der SM 132 kann klären, ob der Strahl eine dem transparenten Dreieck zugeordnete Textur schneidet oder nicht und/oder ob der Strahl durch die Textur blockiert wird. Der SM 132 kann in manchen Fällen auf Basis dieser Bestimmung eine modifizierte Abfrage an die TTU 700 senden (z. B. Verkürzen des Strahls, wenn der Strahl durch die Textur blockiert wird).
In einer Ausführungsform kann die TTU 700 konfiguriert sein, um alle als den Strahl schneidend bestimmten Dreiecke für weitere Verarbeitung an den SM 132 zurückzugeben. Da die Rückgabe jedes Dreieck-Schnittpunkts an den SM 132 für weitere Verarbeitung im Hinblick auf Schnittstellen- und Thread-Synchronisation aufwendig ist, kann die TTU 700 dafür konfiguriert sein, Dreiecke zu verbergen, die zwar geschnitten werden, aber nachweislich ohne funktionale Auswirkungen auf die resultierende Szene verborgen werden können. Da die TTU 700 zum Beispiel mit Dreieck-Typ-Informationen versehen wird (z. B. ob ein Dreieck opak oder transparent ist), kann die TTU 700 die Dreieck-Typ-Informationen verwenden, um geschnittene Dreiecke zu bestimmen, die entlang des Strahls von einem anderen schneidenden opaken Dreieck verdeckt werden und die daher nicht in die Ergebnisse einbezogen werden müssen, da sie die Sichtbarkeit entlang des Strahls nicht beeinträchtigen werden. Wie oben mit Bezug auf 5A-5C erörtert, kann, wenn die TTU 700 weiß, dass ein Dreieck entlang des Strahls durch ein opakes Dreieck verdeckt wird, das verdeckte Dreieck ohne Einfluss auf die Visualisierung der resultierenden Szene aus den Ergebnissen ausgeblendet werden.
Der Schnittpunktverwaltungsblock 722 kann eine Ergebniswarteschlange zum Speichern von Treffern, die eine Dreieck-ID zuordnen, und Informationen über den Punkt, an dem der Strahl das Dreieck trifft, enthalten. Wenn ein Strahl als ein opakes Dreieck schneidend bestimmt wird, können die Identität des Dreiecks und die Entfernung des Schnittpunkts vom Strahlursprung in der Ergebniswarteschlange gespeichert werden. Wenn der Strahl als ein anderes opakes Dreieck schneidend bestimmt wird, kann das andere opake Dreieck aus dem Ergebnis weggelassen werden, wenn die Entfernung des Schnittpunkts vom Strahlursprung größer ist als die Entfernung des bereits in der Ergebniswarteschlange gespeicherten geschnittenen opaken Dreiecks. Wenn die Entfernung des Schnittpunkts vom Strahlursprung kleiner ist als die Entfernung des bereits in der Ergebniswarteschlange gespeicherten geschnittenen opaken Dreiecks, kann das andere geschnittene opake Dreieck das in der Ergebniswarteschlange gespeicherte opake Dreieck ersetzen. Nachdem alle Dreiecke einer Abfrage getestet worden sind, können die in der Ergebniswarteschlange gespeicherten Informationen über opake Dreiecke und die Schnittpunktinformationen an den SM 132 gesendet werden.
In manchen Ausführungsformen kann der Schnittpunktverwaltungsblock 722, sobald ein Schnittpunkt mit einem opaken Dreieck identifiziert worden ist, den im Strahlverwaltungsblock 730 gespeicherten Strahl verkürzen, so dass Begrenzungsvolumina (die möglicherweise Dreiecke enthalten) hinter dem geschnittenen opaken Dreieck (entlang des Strahls) nicht als den Strahl schneidend identifiziert werden.
Der Schnittpunktverwaltungsblock 722 kann Informationen über geschnittene transparente Dreiecke in einer separaten Warteschlange speichern. Die gespeicherten Informationen über geschnittene transparente Dreiecke können an den SM 132 gesendet werden, damit der SM klärt, ob der Strahl eine dem Dreieck zugeordnete Textur schneidet oder nicht und/oder ob die Textur den Strahl blockiert. Das SM kann die Ergebnisse dieser Bestimmung an die TTU 700 zurückgeben und/oder die Abfrage auf Basis dieser Bestimmung modifizieren (z. B. den Strahl verkürzen, wenn der Strahl durch die Textur blockiert wird).
Beispiel-Strahlverfolgungs-Shading-Pipeline
10A zeigt eine Beispiel-Strahlverfolgungs-Shading-Pipeline 900, die von dem SM 132 durchgeführt und durch die TTU 700 beschleunigt werden kann. Die Strahlverfolgungs-Shading-Pipeline 900 beginnt damit, dass ein SM 132 eine Strahlerzeugung 910 aufruft und eine entsprechende Strahlverfolgungs-Anforderung an die TTU 700 ausgibt. Die Strahlverfolgungs-Anforderung identifiziert einen einzelnen in die Szene geworfenen Strahl und fordert die TTU 700 auf, nach Schnittpunkten mit einer ebenfalls durch den SM 132 spezifizierten Beschleunigungsdatenstruktur zu suchen. Die TTU 700 traversiert (10A Block 920) die Beschleunigungsdatenstruktur, um Schnittpunkte oder potenzielle Schnittpunkte zwischen dem Strahl und den volumetrischen Unterteilungen und zugeordneten Dreiecken zu bestimmen, die die Beschleunigungsdatenstruktur darstellt. Potenzielle Schnittpunkte können durch Finden von Begrenzungsvolumina in der Beschleunigungsdatenstruktur, die von dem Strahl geschnitten werden, identifiziert werden. Nachkommen von nicht geschnittenen Begrenzungsvolumina müssen nicht geprüft werden.
Für Dreiecke innerhalb von geschnittenen Begrenzungsvolumina führt der Strahl-Primitiv-Test-Block 720 der TTU 700 einen Schnittpunkt-Prozess 930 durch, um zu bestimmen, ob der Strahl die Primitive schneidet. Die TTU 700 gibt Schnittpunktinformationen an den SM 132 zurück, der als Antwort auf die Schnittpunktbestimmung eine „Irgendein-Treffer“ Shading-Operation 940 durchführen kann. Zum Beispiel kann der SM 132 ein Textur-Nachschlagen nach einem geschnittenen Primitiv durchführen (oder von anderer Hardware durchführen lassen) und auf Basis des passenden Texel-Wertes entscheiden, wie ein den Strahl visualisierendes Pixel zu schattieren ist. Der SM 132 behält diese Ergebnisse im Auge, da die TTU 700 möglicherweise mehrere Schnittpunkte mit unterschiedlicher Geometrie in der Szene in beliebiger Reihenfolge zurückgibt.
Alternativ können Primitive, die die TTU 700 als geschnitten bestimmt, weiterverarbeitet werden, um zu bestimmen 950, ob sie als ein Fehlschuss 960 oder als ein nächstgelegener Treffer 970 zu schattieren sind. Der SM 132 kann zum Beispiel die TTU 700 anweisen, einen nächstgelegenen Treffer in der spezifizierten Geometrie zu melden, oder sie kann die TTU anweisen, alle Treffer in der spezifizierten Geometrie zu melden. Zum Beispiel kann es Sache der SM 132 sein, auf Basis von implementierten Umgebungs-Nachschlagen (z. B. Approximieren des Aussehens einer reflektierenden Oberfläche mittels eines vorberechneten Texturbildes) eine „Fehlschuss“-Shading-Operation für ein Primitiv zu implementierten, das die TTU 700 als geschnitten bestimmt, wie z. B. in 6A & 6B gezeigt. Der SM 132 kann eine Nächstgelegener-Treffer-Shading-Operation durchführen, um das nächstgelegene geschnittene Primitiv auf Basis von Materialbewertungen und Texturnachschlagen als Antwort auf Nächstgelegener-Treffer-Meldungen zu bestimmen, die die TTU 700 für eine bestimmte Objektgeometrie geliefert hat.
Das detailliertere Flussdiagramm einer Strahlverfolgungs-Pipeline von 10B zeigt den Datenfluss und die Interaktion zwischen Komponenten für einen repräsentativen Anwendungsfall: Verfolgen von Strahlen gegen eine Szene, die geometrische Primitive enthält, mit in Hardware behandelten Instanztransformationen. In einem nicht einschränkenden Ausführungsbeispiel ist die Strahlverfolgungs-Pipeline von 10B im Wesentlichen softwaredefiniert (was in Ausführungsbeispielen bedeutet, dass sie durch die SMs 132 bestimmt wird), nutzt aber in hohem Maße Hardwarebeschleunigung durch die TTU 700. Schlüsselkomponenten umfassen den SM 132 (und den Rest der Rechenpipeline), die TTU 700 (die als Koprozessor zum SM dient) sowie den L1-Cache und das nachgelagerte Speichersystem, aus dem die TTU BVH- und Dreieck-Daten abruft.
Die in 10B gezeigte Pipeline zeigt, dass die Begrenzungsvolumenhierarchie-Erzeugung 1002 im Voraus von einem Entwicklungssystem durchgeführt werden kann. Sie zeigt auch, dass die Strahlerzeugung und -verteilung 1004 von dem SM 132 oder einer anderen Software in dem Ausführungsbeispiel durchgeführt oder gesteuert werden, wie Shading (welches Beleuchten und Texturieren umfassen kann). Die Beispiel-Pipeline enthält eine „Top-Level“-BVH-Baumtraversierung 1006, eine Strahltransformation 1014, eine „Bottom-Level“-BVH-Baumtraversierung 1018 und einen Strahl/Dreieck- (oder anderes Primitiv) - Schnittpunkt 1026, die jeweils von der TTU 700 durchgeführt werden. Diese müssen nicht in der gezeigten Reihenfolge durchgeführt werden, da ein Handshaking zwischen der TTU 700 und dem SM 132 bestimmt, was die TTU 700 tut und in welcher Reihenfolge.
Der SM 132 legt der TTU 700 jeweils einen oder mehrere Strahlen zugleich vor. Jeder Strahl, den der SM 132 der TTU 700 für Traversierung vorlegt, kann geometrische Parameter des Strahls, den Traversierungsstatus sowie Strahl-Flag-, Modus-Flag- und Strahloperations-Informationen des Strahls umfassen. In einem Ausführungsbeispiel liefert oder umfasst eine Strahloperation (RayOp) einen Hilfs-Arithmetik- oder Logik-Test zum Unterdrücken, Übersteuern und/oder Erlauben von Speichern eines Schnittpunkts. Der Traversierungsstapel kann auch von dem SM 132 verwendet werden, um bestimmte Statusinformationen an die TTU 700 zur Verwendung bei der Traversierung zu übermitteln. Eine neue Strahlabfrage kann mit einem expliziten Traversierungsstapel gestartet werden. Für manche Abfragen kann jedoch eine kleine Anzahl von Stapelinitialisierern verwendet werden, statt einen expliziten Stapel zum Beginnen der neuen Abfrage von einem gegebenen Typ zu spezifizieren, wie zum Beispiel: Traversierung ausgehend von einem Complet; Schnittpunkt eines Strahls mit einem Bereich von Dreiecken; Schnittpunkt eines Strahls mit einem Bereich von Dreiecken, gefolgt von Traversierung ausgehend von einem Complet; Vertex-Abruf aus einem Dreieck-Puffer für ein gegebenes Dreieck, usw. In manchen Ausführungsformen verbessert die Verwendung von Stapelinitialisierern anstelle von Explizitstapelinitialisierung die Leistung, da Stapelinitialisierer weniger Streaming-Prozessor-Register benötigen und die Anzahl der Parameter reduzieren, die vom Streaming-Prozessor an die TTU übertragen werden müssen.
In dem Ausführungsbeispiel kann ein Satz von Modus-Flags (-Merkern), die der SM 132 mit jeder Abfrage (z. B. Strahl) vorlegt, mindestens teilweise steuern, wie die TTU 700 die Abfrage verarbeitet, wenn die Abfrage das Begrenzungsvolumen eines bestimmten Typs schneidet oder ein Primitiv eines bestimmten Primitiv-Typs schneidet. Die Modus-Flags, die der SM 132 der TTU 700 vorlegt, geben dem SM und/oder der Anwendung die Fähigkeit, z. B. durch einen RayOp einen Hilfs-Arithmetik- oder Logik-Test zum Unterdrücken, Übersteuern und/oder Erlauben von Speichern eines Schnittpunkts zu spezifizieren. Die Modus-Flags können zum Beispiel ermöglichen, das Traversierungsverhalten in Übereinstimmung mit Aspekten zu ändern wie zum Beispiel einer Tiefe (oder Entfernung), die einem jedem Begrenzungsvolumen und/oder Primitiv zugeordnet ist, der Größe eines Begrenzungsvolumens oder Primitivs in Bezug auf eine Entfernung vom Ursprung oder dem Strahl, bestimmten Instanzen eines Objekts, usw. Diese Fähigkeit kann von Anwendungen genutzt werden, um dynamisch und/oder selektiv Sätze von Objekten für Schnittpunkttests gegenüber bestimmten Sätzen oder Gruppen von Abfragen freizugeben / zu deaktivieren, zum Beispiel um verschiedene Versionen von Modellen verwenden zu können, wenn sich ein Anwendungsstatus ändert (zum Beispiel beim Öffnen oder Schließen von Türen), oder um verschiedene Versionen eines Modells bereitzustellen, die als Funktion der Länge des Strahls ausgewählt werden, um eine Form von geometrischem Detaillierungsgrad zu realisieren, oder um bestimmten Sätzen von Objekten aus bestimmten Klassen von Strahlen zu erlauben, in bestimmten Ansichten manche Schichten sichtbar oder unsichtbar zu machen.
Zusätzlich zu dem Satz von Modus-Flags, die für den Strahl-Complet-Schnittpunkt und für Strahl-Primitiv-Schnittpunkte getrennt spezifiziert werden können, kann die Strahldatenstruktur andere RayOp-Test-bezogene Parameter spezifizieren, wie z. B. Strahl-Flags, Strahl-Parameter und einen RayOp-Test. Die Strahl-Flags können von der TTU 700 verwendet werden, um verschiedene Aspekte des Traversierungsverhaltens, des Backface-(Rückseiten)-Culling und der Behandlung der verschiedenen Kind-Knoten-Typen zu steuern, abhängig vom Bestehen/Nichtbestehen-Status eines optionalen RayOp-Tests. RayOp-Tests fügen daher den Fähigkeiten der TTU 700 Flexibilität hinzu, auf Kosten einer gewissen Komplexität. Die TTU 700 reserviert einen „Strahl-Slot“ für jeden aktiven Strahl, den sie verarbeitet, und kann die Strahl-Flags, Modus-Flags und/oder die RayOp-Informationen während Traversierung in dem entsprechenden Strahl-Slot-Puffer innerhalb der TTU speichern.
In dem in 10B gezeigten Beispiel führt die TTU 700 eine Top-Level-Baumtraversierung 1006 und eine Bottom-Level-Baumtraversierung 1018 durch. In dem Ausführungsbeispiel ermöglicht die Zwei-Level-Traversierung (Zwei-Ebenen-Traversierung) der BVH schnelle Strahlverfolgungsreaktionen auf dynamische Szenenänderungen.
Die Strahltransformation 1014 bietet den geeigneten Übergang von der Top-Level-Baumtraversierung 1006 zu der Bottom-Level-Baumtraversierung 1018, indem der Strahl, der bei der Top-Level-Traversierung in einem ersten Koordinatenraum (z. B. Welt-Raum) verwendet werden kann, in einen anderen Koordinatenraum (z. B. Objekt-Raum) der BVH der Bottom-Level-Traversierung transformiert wird. Eine Beispiel-BVH-Traversierungstechnik, die eine Zwei-Level-Traversierung verwendet, ist in früherer Literatur beschrieben, siehe z. B. Woop, „A Ray Tracing Hardware Architecture for Dynamic Scenes“, Universität des Saarlandes, 2004, doch sind Ausführungsformen nicht darauf beschränkt.
In manchen Ausführungsformen wird die Top-Level-Traversierung (im Welt-Raum) in einer BVH durchgeführt, die als Antwort auf Änderungen der Position oder Orientierung von instanzierten Objekten dynamisch neu berechnet werden kann (z. B. durch den SM 132), und die Bottom-Level-Traversierung wird in einer BVH von Begrenzungsvolumina durchgeführt, die statisch oder im Wesentlichen statisch bleiben. Änderungen in der Form der Geometrie in der BVH niedrigerer Ebene, die den Begrenzungskasten des Wurzelknotens dieses BVH niedrigerer Ebene nicht verändern, erfordern keine Änderungen in der Top-Level-BVH. Die Begrenzungsvolumina in der BVH, die für die Bottom-Level-Baumtraversierung 1018 (im Objekt-Raum) verwendet werden, können detailliertere Informationen über die Szenengeometrie umfassen als die jeweiligen Begrenzungsvolumina, die bei der Top-Level-Baumtraversierung 1006 verwendet werden, wodurch die Modifizierung der Bottom-Level-Traversierungs-BVH als Antwort auf Szenenänderungen vermieden oder zumindest reduziert wird. Dies trägt dazu bei, Strahlverfolgung von dynamischen Szenen zu beschleunigen.
Die Top-Level-Baumtraversierung 1006 durch die TTU 700 empfängt Complets von dem L1-Cache 1012 und liefert eine Instanz an die StrahlTransformation 1014 für Transformation oder eine Fehlschuss/Ende-Ausgabe 1013 an den SM 132 für Verarbeitung des Nächstgelegener-Treffer-Shaders 1015 durch den SM (dieser Block kann auch rekursiv auf Basis von Nicht-Blattknoten/Kein-Treffer-Bedingungen arbeiten). Bei der Top-Level-Baumtraversierung 1006 ruft ein Nächstes-Complet-Abruf-Schritt 1008 das nächste in Schritt 1010 auf Strahlschnittpunkte zu testende Complet aus dem Speicher und/oder der Cache-Hierarchie ab, und der Strahlbegrenzungsvolumen-Schnittpunkttest wird an den Begrenzungsvolumina im abgerufenen Complet durchgeführt. In Ausführungsbeispielen werden Instanzknoten als Blattknoten betrachtet und in Top-Level-Traversierung verarbeitet. Die nicht einschränkende Beispiel-TTU ist im Stande, Primitiv-Bereiche und Element-Bereiche in der Top-Level-BVH anzutreffen und zu verarbeiten. Jeder Traversierungsschritt eines jeden Strahls beginnt damit, dass die Stapelverwaltungseinheit den gegenwärtig aktiven Stapel eines aktiven Strahls überprüft. Bei Top-Level-Baumtraversierung ist der Top-Level-Stapel aktiv, und somit überprüft die Stapelverwaltungseinheit den Top-Level-Stapel. Wenn der Top-Level-Stapel aktiv und leer ist, werden der Strahl und seine Ergebniswarteschlange an den SM zurückgegeben. Andernfalls erhält die Stapelverwaltungseinheit die Adresse des nächsten Complets oder Blattes, das durch diesen Strahl zu verarbeiten ist, und fordert dieses Complet/Blatt über die L0/L1-Caches vom Speicher-Subsystem an. Bei Bottom-Level-Baumtraversierung ist der Bottom-Level-Stapel aktiv, und somit überprüft die Stapelverwaltungseinheit den Bottom-Level-Stapel. Wenn der Bottom-Level-Stapel aktiv und leer ist, schaltet der Strahl auf Top-Level-Traversierung um, und der Top-Level-Stapel wird zum aktiven Stapel. Die Traversierung kann somit in der untersten Ebene fortgesetzt werden (die Fortsetzung in der oberen Ebene erfolgt, wenn der Bottom-Level-Stapel leer wird).
Wie oben beschrieben, verbindet ein Instanzknoten eine BVH mit einer anderen BVH, die in einem anderen Koordinatensystem liegt. Wenn ein Kind des geschnittenen Begrenzungsvolumens ein Instanzknoten ist, ist die StrahlTransformation 1014 im Stande, eine passende Transformationsmatrix aus dem L1-Cache 1016 auszulesen. Die TTU 700 transformiert den Strahl unter Verwendung der entsprechenden Transformationsmatrix in das Koordinatensystem der Kind-BVH. Die US-Patentanmeldung Nr. 14/697,480 , die bereits durch Bezugnahme aufgenommen worden ist, beschreibt Transformationsknoten, die einen ersten Satz von Knoten in einem Baum mit einem zweiten Satz von Knoten verbinden, wobei der erste und der zweite Satz von Knoten in verschiedenen Koordinatensystemen liegen. Die Instanzknoten in Ausführungsbeispielen können den Transformationsknoten in der US-Anmeldung Nr. 14/697,480 ähnlich sein. In einem alternativen, nicht instanzierenden Modus der TTU 700, in 10C gezeigt, führt die TTU keine „Botton“-Level-Baumtraversierung durch, und nichtinstanzierte Baum-BVH-Traversierungen werden von Blöcken 1008, 1010 durchgeführt, z. B. unter Verwendung nur eines Stapels. Die TTU 700 kann auf Basis dessen, was sie aus der BVH und/oder dem Abfragetyp liest, zwischen den instanzierten Operationen von 10B und den nichtinstanzierten Operationen von 10C umschalten. Zum Beispiel kann ein bestimmter Abfragetyp die TTU darauf beschränken, nur die nichtinstanzierten Operationen zu verwenden. Bei einer solchen Abfrage würden irgendwelche geschnittenen Instanzknoten an den SM zurückgegeben.
In manchen nicht einschränkenden Ausführungsformen wird der Begrenzungsvolumen-Schnittpunkttest in Schritt 1010 an jedem Begrenzungsvolumen in dem abgerufenen Complet durchgeführt, bevor das nächste Complet abgerufen wird. Andere Ausführungsformen können andere Techniken verwenden, wie z. B. Traversieren der Top-Level-Traversierungs-BVH auf eine Weise nach Tiefe. Das bereits durch Bezugnahme aufgenommene US-Patent Nr. 9,582,607 beschreibt eine oder mehrere Complet-Strukturen und -Inhalte, die in Ausführungsbeispielen verwendet werden können. Das US-Patent Nr. 9,582,607 beschreibt ebenfalls eine Beispiel-Traversierung von Complets.
Wenn die RCT-Einheit bestimmt, dass ein Strahl ein Kind-Begrenzungsvolumen schneidet, zeichnet die Baumtraversierungseinheit einen Zeiger oder Verweis auf das entsprechende Kind-Complet oder den entsprechenden Blattknoten für nachfolgendes Testen gegen den Strahl auf. In Ausführungsbeispielen werden eine oder mehrere Stapel-Datenstrukturen (z. B. der in 12 gezeigte Traversierungsstapel) verwendet, um Complets oder Blattknoten im Auge zu behalten, die nachfolgend auf Schnittpunkte mit dem Strahl zu testen sind. In manchen Ausführungsbeispielen kann ein Traversierungsstapel von geringer Größe verwendet werden, um Complets, die durch Betrieb der Top-Level-Baumtraversierung 1006 zu traversieren sind, und auf Schnittpunkte zu testende Primitive im Auge zu behalten, und eine größere lokale Stapel-Datenstruktur kann verwendet werden, um den Traversierungsstatus in der Bottom-Level-Baumtraversierung 1018 im Auge zu behalten. In manchen Ausführungsbeispielen können die Traversierungsstapel sowohl für die Top-Level-Traversierung als auch die Bottom-Level-Traversierung kurz sein, d. h. auf eine geringe Größe (z. B. je 4 Einträge) beschränkt, um effiziente Übergabe von Stapelinformationen zwischen dem Traversierungs-Koprozessor und dem SM zu erleichtern. In manchen Ausführungsbeispielen sind die Top-Level- und Bottom-Level-Stapel gleich groß, und sowohl Blattknoten als auch Complets können sowohl in den Top-Level- als auch den Bottom-Level-BVHs vorhanden sein. In manchen Ausführungsbeispielen gibt es die Option, den zwischen dem Traversierungs-Koprozessor und dem SM ausgetauschten Stapelinhalt zu begrenzen (die Anzahl der Stapeleinträge, die ausgetauscht werden können, kann unabhängig von der Stapeltiefe konfigurierbar sein). Wenn die Anzahl der Stapeleinträge, die zwischen dem Traversierungs-Koprozessor und dem SM ausgetauscht werden können, begrenzt ist, kann der gesamte Stapel dennoch für Traversierung zur Verfügung stehen, und die Verwendungsweisen des Stapels können begrenzt werden. Eine Verwendungsgrenze könnte zum Beispiel sein, dass die oben auf den Stapel geschobenen Blattknoten die Stapelgrenze minus eins nicht überschreiten dürfen, außer im Falle aller opaken Dreiecke, für die möglicherweise gewährleistet wird, dass sie vor der Rückkehr von der Traversierung vom Stapel verschwinden.
In Ausführungsbeispielen werden bei aktiver Bottom-Level-BVH-Traversierung die Position und Richtung des Strahls in der BVH der oberen Ebene getrennt von der transformierten Position und Richtung gespeichert, die zum Traversieren der Bottom-Level-BVH verwendet werden. Bei der Bottom-Level-Baumtraversierung 1018 ruft ein Nächstes-Complet-Abruf-Schritt 1022 das nächste, in Schritt 1024 auf Strahlschnittpunkte zu testende Complet aus dem Speicher und/oder der Cache-Hierarchie 1020 ab, und das Strahlbegrenzungsvolumen-Schnittpunkttesten wird an den Begrenzungsvolumina in dem abgerufenen Complet durchgeführt. Die Bottom-Level-Baumtraversierung kann, wie oben erwähnt, Complets mit Begrenzungsvolumina in einem anderen Koordinatensystem enthalten als die bei der Baumtraversierung der oberen Ebene traversierten Begrenzungsvolumina. Die Bottom-Level-Baumtraversierung empfängt auch Complets aus dem L1-Cache und kann auf Basis von Nicht-Blatt/Kein-Treffer-Bedingungen und auch mit der Top-Level-Baumtraversierung 1006 auf Basis von Fehlschuss/Ende-Erkennung rekursiv oder iterativ in sich selbst arbeiten. Es können Schnittpunkte des Strahls mit den Begrenzungsvolumina in der BVH der unteren Ebene bestimmt werden, wobei der Strahl in das Koordinatensystem des ausgelesenen Complets der unteren Ebene transformiert wird. Die bei der Baumtraversierung der unteren Ebene als von dem Strahl geschnitten gefundenen Blatt-Begrenzungsvolumina werden dann dem Strahl/Dreieck-Schnittpunkt 1026 zugeführt.
Wie oben erwähnt, können in nicht einschränkenden Ausführungsbeispielen Blattknoten sowohl bei Top-Level- als auch Bottom-Level-Traversierung verarbeitet werden. Zum Beispiel können die Blatt-Ausgaben der Bottom-Level-Baumtraversierung 1018 dem Strahl/Dreieck-Schnittpunkt 1026 zugeführt werden (der sowohl Zugriff auf L0-Cache als auch die Fähigkeit hat, Dreiecke über den L1-Cache 1028 auszulesen). Der Strahl/Dreieck-Schnittpunkt 1026 kann auch Blatt-Ausgaben aus der Top-Level-Baumtraversierung 1006 empfangen, wenn bestimmte Blattknoten erreicht werden, ohne eine instanzierte BVH zu traversieren. Die L0-Complet- und Dreieck-Caches können kleine Nur-Lese-Caches innerhalb der TTU 700 sein.
Nachdem alle Primitive im Primitiv-Bereich verarbeitet worden sind, überprüft die Schnittpunktverwaltungseinheit den Status der Ergebniswarteschlange und fertigt Pakete an, die an die Stapelverwaltungseinheit und/oder Strahlverwaltungseinheit zu senden sind, um die Attribute und den Traversierungsstatus des Strahls zu aktualisieren, den nächsten Traversierungsschritt des Strahls einzurichten und/oder den Strahl (falls erforderlich) an den SM 132 zurückzugeben. Wenn die Ergebniswarteschlange Opak- oder Alpha-Schnittpunkte enthält, die während der Verarbeitung des Primitiv-Bereichs gefunden worden sind, dann signalisiert die Schnittpunktverwaltungseinheit der Strahlverwaltungseinheit die parametrische Länge (t) des nächstgelegenen Opak-Schnittpunkts in der Ergebniswarteschlange, um sie als das tmax des Strahls zum Verkürzen des Strahls aufzuzeichnen. Zum Aktualisieren des Traversierungsstatus, um den nächsten Traversierungsschritt des Strahls einzurichten, signalisiert die Schnittpunktverwaltungseinheit der Stapelverwaltungseinheit, ob ein Opak-Schnittpunkt aus dem Primitiv-Bereich in der Ergebniswarteschlange vorhanden ist, ob ein oder mehrere Alpha-Schnittpunkte in der Ergebniswarteschlange vorhanden sind, ob die Ergebniswarteschlange voll ist, ob zusätzliche Alpha-Schnittpunkte im Primitiv-Bereich gefunden worden sind, die nicht an den SM zurückgegeben worden sind und die nicht in der Ergebniswarteschlange vorhanden sind, und den Index des nächsten Alpha-Primitivs in dem Primitiv-Bereich für den zu testenden Strahl, nachdem der SM den Inhalt der Ergebniswarteschlange verbraucht hat (der Index des nächsten Primitivs in dem Bereich nach dem Alpha-Primitiv mit der höchsten Speicherreihenfolge aus dem aktuellen Primitiv-Bereich in der Ergebniswarteschlange).
Wenn die Stapelverwaltungseinheit 740 das Paket von der Schnittpunktverwaltungseinheit 722 empfängt, überprüft die Stapelverwaltungseinheit 740 das Paket, um die nächste Aktion zu bestimmen, die erforderlich ist, um den Traversierungsschritt abzuschließen und den nächsten zu starten. Wenn das Paket von der Schnittpunktverwaltungseinheit 722 anzeigt, dass ein Opak-Schnittpunkt im Primitiv-Bereich gefunden worden ist, und die Strahl-Modus-Bits anzeigen, dass der Strahl die Traversierung beenden soll, sobald irgendein Schnittpunkt gefunden worden ist, gibt die Stapelverwaltungseinheit 740 den Strahl und seine Ergebniswarteschlange mit einem Traversierungsstatus, der anzeigt, dass die Traversierung abgeschlossen ist (ein Fertig-Flag-gesetzt und/oder ein leerer Top-Level- und Bottom-Level-Stapel), an den SM zurück. Wenn das Paket von der Schnittpunktverwaltungseinheit 722 anzeigt, dass es Opak- oder Alpha-Schnittpunkte in der Ergebniswarteschlange gibt und dass es verbleibende, in der Ergebniswarteschlange nicht vorhandene Alpha-Schnittpunkte im Primitiv-Bereich gibt, die der Strahl während der Verarbeitung des Primitiv-Bereichs getroffen hat und die nicht bereits an den SM zurückgegeben worden sind, gibt die Stapelverwaltungseinheit 740 den Strahl und die Ergebniswarteschlange an den SM zurück, wobei der Traversierungsstatus modifiziert wird, das Cull-Opak-Bit so zu setzen, dass weitere Verarbeitung von opaken Primitiven im Primitiv-Bereich verhindert wird und der zu dem ersten Alpha-Primitiv nach dem höchsten Alpha-Primitiv-Schnittpunkt von dem Primitiv-Bereich vorgerückte Start-Index des Primitiv-Bereichs an den SM in der Ergebniswarteschlange des Strahls zurückgegeben wird. Wenn das Paket von der Schnittpunktverwaltungseinheit 722 anzeigt, dass keine Opak- oder Alpha-Schnittpunkte gefunden worden sind, als der Strahl den Primitiv-Bereich verarbeitet hat, entfernt die Stapelverwaltungseinheit 740 den oberen Teil des Stapeleintrags (entsprechend dem fertigen Primitiv-Bereich) von dem aktiven Traversierungsstapel. Wenn das Paket von der Stapelverwaltungseinheit 740 anzeigt oder dass entweder Opak-Schnittpunkte in der Ergebniswarteschlange vorhanden sind und die Strahl-Modus-Bits nicht anzeigen, dass der Strahl die Traversierung beenden soll, sobald irgendein Schnittpunkt gefunden worden ist, und/oder Alpha-Schnittpunkte in der Ergebniswarteschlange vorhanden sind, aber keine verbleibenden, nicht in der Ergebniswarteschlange vorhandenen Alpha-Schnittpunkte im Primitiv-Bereich gefunden worden sind, die nicht bereits an den SM zurückgegeben worden sind, entfernt die Stapelverwaltungseinheit 740 den oberen Teil des Stapeleintrags (entsprechend dem fertigen Primitiv-Bereich) vom aktiven Traversierungsstapel und modifiziert den Inhalt der Ergebniswarteschlange, um anzuzeigen, dass alle in der Ergebniswarteschlange vorhandenen Schnittpunkte aus einem Primitiv-Bereich stammen, dessen Verarbeitung abgeschlossen worden ist.
Wenn der aktive Stapel der untere Stapel ist und der untere Stapel leer ist, setzt die Stapelverwaltungseinheit 740 den aktiven Stapel auf den oberen Stapel. Wenn der obere Stapel der aktive Stapel ist und der aktive Stapel leer ist, gibt die Stapelverwaltungseinheit 740 den Strahl und seine Ergebniswarteschlange mit einem Traversierungsstatus, der anzeigt, dass die Traversierung abgeschlossen ist (ein Fertig-Flag-gesetzt und/oder ein leerer Top-Level- und Bottom-Level-Stapel), an den SM zurück. Wenn der aktive Stapel einen oder mehrere Stapeleinträge enthält, überprüft die Stapelverwaltungseinheit 740 den oberen Stapeleintrag und startet den nächsten Traversierungsschritt. Das Testen von Primitiven und/oder Primitiv-Bereichen auf Schnittpunkte mit einem Strahl und die Rückgabe der Ergebnisse an den SM 132 sind beschrieben in der gleichzeitig anhängigen US-Anmeldung Nr. 16/101,148 mit dem Titel „Conservative Watertight Ray Triangle Intersection“, der US-Anmeldung Nr. 16/101,066 mit dem Titel „Method for Continued Bounding Volume Hierarchy Traversal on Intersection without Shader Intervention“ und der US-Anmeldung Nr. 16/101,196 mit dem Titel „Method for Handling Out-of-Order Opaque and Alpha Ray/Primitive Intersections“, die hiermit in ihrer Gesamtheit durch Bezugnahme aufgenommen werden.
Obwohl die obige Offenbarung in den speziellen Kontext von Computergrafik und Visualisierung eingebettet ist, könnten Strahlverfolgung und der offenbarte Traversierungs-Koprozessor für mannigfache Anwendungen jenseits von Grafik und Visualisierung eingesetzt werden. Nicht einschränkende Beispiele umfassen Schallausbreitung für realistische Klangsynthese, die Simulation von Sonarsystemen, Design optischer Elemente und Systeme, Partikeltransportsimulation (z. B. für Medizinphysik oder experimentelle Hochenergiephysik), allgemeine Wellenausbreitungssimulation, Vergleich mit LIDAR-Daten für Zwecke z. B. der Roboter- oder Fahrzeuglokalisierung und andere. Für einige dieser Anwendungsgebiete hat man OptiX™ bereits in der Vergangenheit genutzt.
Strahlen werden unter verschiedenen Umständen und aus mannigfachen Gründen verfolgt. Es ist wünschenswert, unterschiedliche Typen von Strahlen mit Einschränkungen verfolgen zu können, um die Traversierung auf bestimmte Teilmengen der BVH zu beschränken oder um nur Strahlen gegen bestimmte Teilmengen von Primitiven auf Schnittpunkte zu testen. Beispiele für diese Umstände können Änderungen in Objektzuständen sein, die die Geometrie (z. B. Tore oder Türen öffnen/schließen) oder das Shading (z. B. Ampeln schalten um) beeinflussen, wobei mehrere Versionen desselben Objekts mit unterschiedlichem Geometrie- oder Shading-Detaillierungsgrad als Funktion der Anzahl der Aufpralle entlang eines Pfades oder einer akkumulierten Pfadlänge ausgewählt werden, wobei Alpha-Primitive oder Elemente weggelassen werden oder Objekte in bestimmten „Schichten“ einer CAD-Anwendung hervorgehoben werden.
Änderungen an Objekten und/oder der darzustellenden Szene können jedoch oft erfordern, dass die BVH oder Teile davon zur Laufzeit modifiziert und/oder regeneriert werden. Regenerieren oder sogar Modifizieren der BVH entsprechend einer Szene kann zeitaufwendig sein. Wie oben beschrieben, kann zum Beispiel jedes Begrenzungsvolumen in der BVH viele andere Begrenzungsvolumina und bis zu Millionen von geometrischen Primitiven umfassen. Daher benötigt man Techniken zur Verbesserung der Leistung von Strahlverfolgungs-Systemen, wenn dynamische Szenenänderungen zu rendern sind.
In manchen Anwendungen erfordern Änderungen in einer Szene und/oder Aspekte der Visualisierung möglicherweise nicht, dass alle Teile der Szene in der BVH regeneriert werden. Obwohl für viele Arten von Szenenänderungen ein Umbau der BVH oder von Teilen davon erforderlich sein kann, sind in manchen Fällen die Änderungen derart, dass Umbau oder Modifizierung der BVH im Interesse der Zeit minimiert oder vermieden werden kann. In manchen Anwendungen erfordert eine Änderung in einer Szene, wie zum Beispiel das Schließen einer offenen Tür und das resultierende Versperren von der Sicht auf das Innere eines Raums, das vorher in Sicht war, möglicherweise nicht, dass der BVH geändert oder regeneriert wird, wenn der Strahl dynamisch bestimmen kann, wie zwischen verschiedenen Instanzen oder Konfigurationen desselben Objekts, das in derselben BVH dargestellt wird, zu wählen ist. Manche Ausführungsbeispiele bieten Techniken, um Szenenänderungen effizient zu handhaben. Manche andere Techniken, wie zum Beispiel Instanzieren von BVH-Knoten, helfen, Änderungen an der BVH zu steuern, wenn Szenenänderungen stattfinden. Wenn instanzierte Objekte ihre Position und/oder Orientierung ändern, ohne ihre Form zu ändern, müssen wir nur die Transformationskoeffizienten und den Begrenzungskasten des Instanzknotens ändern (und irgendwelche Vorfahren-Complet-Begrenzungskästen, die den neuen Begrenzungskasten für den Instanzknoten nicht binden können). Dies ist weniger Arbeit als jedes Primitiv zu transformieren und es in eine Welt-Raum-BVH einzufügen.
Konventionelle Strahlverfolger führen Traversierung der Beschleunigungsdatenstruktur allein auf Basis der geometrischen Attribute des Strahls, einer Beschleunigungsdatenstruktur und von Primitiven durch. Während viele Strahlverfolger Alpha-Primitive oder Transparenz unterstützen, tun sie dies im Kontext von Post-Traversierungs-Shading. Das heißt, obwohl viele Strahlverfolger vorsehen, dass bestimmte Typen von Objekten (z. B. eine Gruppe von Blättern eines Baums und ähnliche Objekte, die nicht vollständig opak sind) als transparente Primitive modelliert werden, wird nach einer anfänglichen Bestimmung während Traversierung der BVH, dass ein transparentes Objekt möglicherweise einen Strahl schneidet, die endgültige Bestimmung außerhalb dieser Traversierung vorgenommen. Um danach weiter entlang des Pfades dieses Strahls zu testen, erfordern diese Systeme den Start eines neuen Strahls, der an einem Punkt kurz hinter dem transparenten Primitiv entspringt, das eine neue Traversierung von der Wurzel der BVH-Hierarchie startet. Eine solche Anforderung, dass das System bei jedem Verdacht auf einen Transparentes-Primitiv-Schnittpunkt eine neue Traversierung starten muss, kann zu einer erheblichen Leistungseinbuße im Sinne der Geschwindigkeit führen, mit der ein Strahlverfolgungs-System seine Aufgaben erzeugt. Einer der Vorteile von Ausführungsbeispielen besteht darin, dass Tests wie zum Beispiel der Alpha-Test (z. B. Test, ob das transparente Primitiv den Strahl schneidet) als eine Erweiterung des Strahl-Schnittpunkttests behandelt werden, welche die Traversierung nur kurzzeitig unterbricht, statt für jeden getroffenen Alpha-Schnittpunkt einen neuen Strahl starten zu müssen.
Ausführungsbeispiele liefern eine Vielzahl von Verbesserungen der Basis- oder Vorgabe-Traversierung einer BVH und des Shading bei Strahlverfolgung und liefern Mechanismen zum Instrumentieren, Erweitern oder Übersteuern von hardwarebeschleunigter Traversierung der BVH in einem Traversierungs-Koprozessor (z. B. TTU 700) mit programmierbaren Fähigkeiten, die auf einem Streaming-Multiprozessor (z. B. SM 132) laufen.
Die TTU 700 führt wie oben beschrieben eine beschleunigte Baumtraversierung für Strahlverfolgung durch. Wie oben beschrieben, führt die TTU 700 Abfragen im Namen von im SM 132 laufenden Threads durch, wobei gemäß manchen Ausführungsbeispielen jeder Thread einen jeweiligen Strahl darstellt. Das heißt, in manchen Ausführungsbeispielen bestimmt jeder Thread die Schnittpunkte eines jeweiligen Strahls mit der BVH. Unter Verwendung eines oder mehrerer Strahlen (z. B. typischerweise in manchen Ausführungsformen ein jeweiliger Strahl von jedem Thread in einer Gruppe von Threads wie z. B. eines Warps) von dem SM 132 als Eingabe beschleunigt die TTU 700 die Traversierung der BVH, um Strahl-Primitiv-Schnittpunkt-Informationen (z. B. Dreiecke oder andere Primitive, die geschnitten werden) zurückzugeben, die bei der Shading-Verarbeitung zu verwenden sind, die nachfolgend von dem SM 132 oder einer anderen Komponente der GPU durchgeführt wird. Nicht einschränkende Ausführungsbeispiele sehen vor, eine solche beschleunigte Traversierung in einer Weise durchzuführen, die eine feinere Steuerung durch die Anwendung(en) ermöglicht (z. B. TTUbeschleunigtes strahlverfolgtes Rendern in einer Softwareanwendung, die auf einer GPU läuft), für die die Strahlverfolgung durchgeführt wird. Jeder Strahl erklärt, wie er mit verschiedenen Typen von Primitiven und Knoten als Funktion der Modus-Bits und Parametern, die mit dem Strahl spezifiziert sind, und Parametern, die innerhalb der Knoten und Primitiven der BVH spezifiziert sind, umgehen wird.
Zum Beispiel stellen Ausführungsformen einer Anwendung Mittel zur Verfügung, um TTU-beschleunigte Traversierung für Zwecke wie z. B., aber nicht beschränkt auf, Begrenzung der Traversierung auf einen Teil der Beschleunigungsdatenstruktur feinabzustimmen, oder um es auf dem SM laufender Software zu ermöglichen, die Traversierung zu unterbrechen, um bestimmte Knoten oder Klassen von Knoten in der Beschleunigungsdatenstruktur zu übersteuern oder zu erweitern.
Um die oben erörterte abfragespezifische dynamische und programmierbare Änderung des Traversierungsprozesses zu erleichtern, stellen Ausführungsbeispiele einen Pro-Strahl-Satz von Strahloperationen (jede Strahloperation wird als „RayOp“ bezeichnet), zugeordneten Strahlparametern, Strahl-Flags und Modus-Flags bereit, auf deren Basis das Verhalten der TTU-Traversierung auf einer Pro Strahl- und/oder Pro-Schnittpunkt-Basis geändert werden kann. Manche Ausführungsbeispiele erweitern die im US-Patent Nr. 9,582,607 (die hierin in ihrer Gesamtheit durch Bezugnahme aufgenommen wird) beschriebene Baumtraversierungseinheit unter anderem um einen Satz von Pro-Strahl-RayOp-Tests, die an den Schnittpunkten durchzuführen sind, zugehörige Strahlparameter, Strahl-Flags und Modus-Flags, und erweitern die in der US-Patentanmeldung Nr. 14/697,480 (die hierin in ihrer Gesamtheit durch Bezugnahme aufgenommen wird) beschriebene Baumstruktur unter anderem um einen Pro-Kind-Knoten-Parameter (als „rval“-Parameter bezeichnet) zur Verwendung bei den RayOp-Tests. Die RayOp-Tests sind zusätzlich zu Strahl-Schnittpunkttests, die während Traversierung durchgeführt werden. In einer nicht einschränkenden Ausführungsform werden die RayOp-Tests zum Beispiel nur an Kind-Knoten und Primitiven durchgeführt, die von dem Strahl geschnitten worden sind. Während die Strahl-Schnittpunkttests auf geometrischen Aspekten (z. B. Ortskoordinaten, Richtung, Länge, Größe usw.) des Strahls und der BVH basieren, basieren zumindest einige RayOp-Tests möglicherweise nicht auf geometrischen Aspekten des Strahls oder der BVH.
Die TTU führt einen RayOp-Test für einen Strahl durch, indem sie einen vorbestimmten RayOp-Test-Ausdruck unter Verwendung des RayOp-ldentifikators des Strahls (in dieser Offenbarung als RayOp-Opcode des Strahls bezeichnet), der Strahlparameter und des rval-Parameters des Kind-Knotens bei jedem potentiellen Traversierungsschritt bewertet. Gemäß einer Ausführungsform spezifiziert die RayOp einen Pro-Strahl-Test, der für jedes Kind jedes während der Traversierung getesteten Knotens durchzuführen ist, unter Verwendung von zwei RayOp-Testparametern A, B pro Abfrage und einer für jedes Kind eines Knotens spezifizierten rval. Ein Beispiel-RayOp-Test sieht vor, einen linken numerischen Wert auf Basis eines Strahlparameters in Bezug auf eine bestimmte Arithmetik- oder Logik-Operation gegen einen rechten Wert auf Basis eines Strahlparameters und eines Parameters (z. B. rval-Parameter) des geschnittenen Knotens zu testen. Wie im Folgenden beschrieben, können in verschiedenen Ausführungsformen andere Formen von RayOp-Tests verwendet werden.
In Abhängigkeit vom Ergebnis des RayOp-Tests und den Modus-Flags des Strahls kann die TTU bestimmen, wie sie mit verschiedenen während der Traversierung getroffenen Knoten-Typen und Primitiv-Treffer-Typen umgehen würde - wie zum Beispiel ob der Kind-Knoten zu traversieren, zu ignorieren oder für besondere Behandlung an den SM zurückzugeben ist, oder ob der Primitiv-Schnittpunkt zu unterdrücken, beizubehalten oder für besondere Behandlung an den SM zurückzugeben ist. Die Bestimmung kann auch so erfolgen, dass sie mit einem oder mehreren Strahl-Flags konsistent ist. Die Strahl-Flags des Strahls können zum Beispiel eine Traversierungs-Reihenfolge für die Begrenzungsvolumina (z. B. Kind-Begrenzungsvolumina) spezifizieren, ob bei der Rückkehr von der Traversierung ein Stapel (z. B. ein Stapel, der den Status der Traversierung darstellt) zu öffnen ist oder nicht, ob Knotenverweise an den SM zu melden sind oder nicht, wenn das Intervall tmin ... tmax des Strahls innerhalb des Begrenzungskastens des Knotens beginnt, ob beim ersten Treffer eines Schnittpunkts zurückzugeben ist oder nicht, Frontfacing-Einstellungen und Culling-Einstellungen.
Die Modus-Flags spezifizieren das Verhalten der TTU, wie sie bestimmte Knoten-Typen und Primitiv-Test-Ergebnisse handhaben soll, als eine Funktion davon, ob der RayOp-Test bestanden wurde oder nicht. Die spezifizierten Modus-Flags können in zwei Kategorien betrachtet werden: Modus-Flags, die den Traversierungsstatus beeinflussen und als Antwort auf die von der Strahl-Complet-Test-(RCT)-Einheit wie z. B. dem Strahl-Complet-Test-Block 710 geschnittenen Kind-Begrenzungsvolumina an die Stapelverwaltungseinheit übergeben werden, und Modus-Flags, die den Traversierungsstatus beeinflussen und an die Stapelverwaltungseinheit übergeben werden, und Werte, die als Folge von Primitiven, die von der Strahl-Primitiv-Testuntereinheit (z. B. Strahl/Dreieck-Test-Block 720) getestet worden sind, von der Schnittpunktverwaltungseinheit (z. B. Block 722) in die Ergebniswarteschlange geschoben werden. Erstere können als RCT-Modus-Flags bezeichnet werden, und Letztere können als RPT-Modus-Flags bezeichnet werden.
Wenn die RCT-Einheit 710 ein Kind-Begrenzungsvolumen schneidet, führt die RCT-Einheit den RayOp-Test durch, der durch die RayOp-Abfrageparameter des Strahls spezifiziert wird, und zwar unter Verwendung der Parameter A und B des Strahls und des rval-Parameters des Complet-Kindes (und optional Invert-Parametern). Die RCT-Einheit 710 führt die von den entsprechenden RCT-Modus-Flags aufgezählte Aktion auf Basis des Ergebnisses des RayOp-Tests (oder des Inversen des Ergebnisses des RayOp-Tests, wenn das Invert-Flag des Kind-Knotens gesetzt ist), durch. Wenn zum Beispiel ein Strahl mit RayOp = EQUAL, A = 0x0 und B = 0xFF einen Complet-Kind-Knoten schneidet, dessen rval gleich 0x1 ist und dessen Invert-Feld auf FALSE gesetzt worden ist, schlägt der RayOp-Test (z. B. 0x0 == 0x1 & 0xFF) fehl. Auf Basis des Ergebnisses des RayOp-Tests werden das oder die entsprechenden Modus-Flag(s) identifiziert. Wenn zum Beispiel das oder die identifizierten Modus-Flag(s) (z. B. ch_f-Modus-Flag) anzeigen, dass das Complet-Kind auszusondern ist, wenn der RayOp-Test nicht bestanden wird, dann schiebt die TL 712 möglicherweise keinen Stapeleintrag auf den Traversierungsstapel des Strahls für dieses Complet-Kind, obwohl der Strahl das Begrenzungsvolumen des Complet-Kindes geschnitten hat. In manchen Ausführungsformen führt die RCT-Einheit 710 den RayOp-Test durch und leitet das Testergebnis an die TL-Untereinheit 712 weiter, die das Testergebnis verwendet, um zwischen den verfügbaren Modi zu wählen.
Die oben beschriebenen Modus-Flags sind Beispiele, und es werden viele weitere Modus-Flags und ihre jeweilige Konfiguration in Bezug auf 10B und 10C und in Bezug auf 14-16 beschrieben.
In Fällen, in denen die RayOp- und Modus-Flags anzeigen, dass das Ergebnis für besondere Behandlung an den Streaming-Prozessor zurückzugeben ist, können der Strahl, sein Traversierungsstatus und der Inhalt seiner Ergebniswarteschlange vollständig an den SM zurückgegeben werden. Der SM kann nach Bedarf (zum Beispiel Interpolieren von Texturkoordinaten und Bewerten einer Alpha-Textur, um zu bestimmen, ob ein Alpha-Schnittpunkt zu ignorieren ist oder nicht, usw.) oder wie spezifiziert zusätzliche Verarbeitung durchführen, und wenn nötig, kann der SM die Abfrage mit den gleichen oder geänderten Abfrageparametern wieder der TTU vorlegen (zum Beispiel Wiedervorlegen der Abfrage mit einem verkürzten Strahl).
In manchen Ausführungsformen ist auch ein Mechanismus vorgesehen, um das Ergebnis des im RCT-Test-Block 710 durchgeführten RayOp-Tests an den RTT-Test-Block 720 für nachfolgende Verwendung zu übermitteln.
Durch Bereitstellen einer Abfragestruktur und einer BVH-Struktur, die das Traversierungs- und Primitiv-Schnittpunkttest-Verhalten jedes Strahls in einem Traversierungs-Koprozessor wie zum Beispiel der TTU 700 individuell anpassen kann, können Anwendungen zumindest in manchen Fällen dynamische Änderungen beim Strahlverfolgungs-Rendern beeinflussen, ohne dass eine Regeneration, Modifizierung oder Duplizierung von BVH-Daten erforderlich ist. Ändern des Vorgabe-Verhaltens der Traversierung kann das Ändern eines Status der Traversierung (z. B. Auswählen eines anderen Teils der BVH für Traversierung oder einer anderen Reihenfolge oder Traversierung aus dem standardmäßig konfigurierten Verhalten) oder das Ändern einer an den SM zurückgegebenen Ausgabe (z. B. Ändern eines oder mehrerer der Schnittpunkte) umfassen.
Der Mechanismus ist oben in Bezug auf 10B und 10C beschrieben, doch wird nachfolgend ein kurzer Überblick über die verschiedenen Typen von Knoten eines Traversierungsbaums, die in eine BVH aufgenommen werden können und während der Traversierung getroffen werden, sowie die verschiedenen Treffertypen, die die TTU 700 an den SM zurückgeben kann, gegeben.
Der BVH enthält, wie oben beschrieben, einen hierarchisch (z. B. in einer Baumstruktur) angeordneten Satz von Begrenzungsvolumina, wobei jedes Volumen einen dreidimensionalen Teil einer Szene umfasst. Blattknoten des BVH-Baums können Bereiche von geometrischen Primitiven (z. B. Dreiecke), Elemente, Element-Bereiche oder Instanzknoten umfassen. Wie oben erwähnt, zeigt 8A eine Beispiel-3D-Szene, die rekursiv in Begrenzungsvolumina unterteilt ist, und 8B zeigt eine Beispiel-Baumdatenstruktur, die die 3D-Szene in 8A darstellen kann.
Die Beschreibung verwendet hier die Begriffe „Begrenzungsvolumenhierarchie“ (BVH) und „Beschleunigungsstruktur“ austauschbar. Ausführungsbeispiele werden in erster Linie so beschrieben, dass sie eine BVH als die Beschleunigungsstruktur verwenden. Fachleute erkennen jedoch, dass manche Ausführungsbeispiele andere Beschleunigungsstrukturen als den in dieser Offenbarung beschriebenen Typ von BVH-Strukturen enthalten können.
In manchen Ausführungsbeispielen wird der BVH in einem oder mehreren Complets gespeichert, die ein komprimiertes Format zum Speichern von Sätzen von Knoten der BVH in einer Baumstruktur sind. Jedes Complet, wie oben erwähnt, spezifiziert eine Wurzel, innere Knoten und Blattknoten, wobei jeder Knoten ein jeweiliges Begrenzungsvolumen der BVH darstellt. Die Knoten jedes Complets können in zusammenhängendem Speicher gespeichert werden.
Während der Traversierungs-Operation wird die BVH aus Speicher abgerufen, in den sie von Anwendungssoftware in Complets in die TTU geschrieben wird. Für effizientes Abrufen kann die Größe der Complets so konfiguriert werden, dass sie den Zugriffsmöglichkeiten von Cache und/oder anderem Speicher der Hardware entspricht. In manchen Ausführungsformen hat zum Beispiel jedes Complet 128B, was der Größe einer Cache-Zeile entspricht. Da, wie oben erwähnt, jedes Complet einen Wurzelknoten und Kind-Knoten enthält, kann die gespeicherte BVH als ein Baum von Complets betrachtet werden. Für effiziente Traversierung werden die Kind-Complets eines Eltern-Complets vorzugsweise zusammenhängend in Speicher gespeichert, wobei Zeiger auf die Kind-Complets im Eltern-Complet gespeichert werden. Die Zeiger können in komprimierter Form gespeichert werden.
Die Complets der BVH selbst sind in einer Baumstruktur angeordnet, und Beispiel-Kind-Knoten-Typen eines Complets umfassen Complets, Instanzknoten, Elemente oder Element-Bereiche und Primitive oder Primitiv-Bereiche.
Wenn während der Traversierung ein Kind-Complet-getroffen wird, ist das Vorgabe-Verhalten gemäß manchen Konfigurationen, dass die TTU 700 die Traversierung fortsetzt, indem sie das Kind-Complet aus dem Speicher ausliest und in das Kind-Complet absteigt, um die Knoten des Kind-Complets zu traversieren. Das Vorgabe-Verhalten kann sich auch in Übereinstimmung mit dem Knoten-Typ des Complet-Kindes unterscheiden.
Ein Instanzknoten-Kind eines Complets kann einen oder mehrere Zeiger auf die Hierarchie der Knoten der BVH oder insbesondere auf ein anderes Complet enthalten, das sich in einem anderen Koordinatenraum als der Instanzknoten und das Complet, das den Instanzknoten als Kind-Knoten enthält, befindet, sowie eine Transformation zum Transformieren eines Strahls von einer Welt oder einem anderen Koordinatenraum in den Koordinatenraum des referenzierten Complets. Eine BVH kann null oder mehr Instanzknoten enthalten, von denen jeder eine Verbindung von einem Blattknoten eines Complets zur Wurzel eines anderen herstellt. Wenn eine BVH als zwei oder mehr kleinere BVHs aufweisend betrachtet wird, kann ein Instanzknoten als eine Verbindung von einer ersten BVH in einem ersten Koordinatensystem zu einer zweiten BVH betrachtet werden, die als Kind der ersten BVH, also in einem zweiten Koordinatensystem, angeordnet ist. Gemäß manchen Ausführungsformen kann die Instanzknoten-Struktur zusätzlich zu den ein oder mehreren Zeigern auf das referenzierte Complet oder BVH Flags enthalten, die dazu verwendet werden können, das Verhalten (z. B. Backface-Culling-Verhalten) in dem referenzierten Complet oder BVH zu beeinflussen, sowie eine Transformationsmatrix (in homogenen Koordinaten) von dem Koordinatensystem des referenzierenden Complets oder BVH zu dem des referenzierten Complet oder BVH. Die Transformation kann vom Welt-Raum in den Objekt-Raum des referenzierten Complets oder BVH oder von einem ersten Objekt-Raum des referenzierenden Complets oder BVH in einen zweiten Objekt-Raum des referenzierten Complets oder BVH erfolgen. Das lokale Koordinatensystem des Objekt-Raums des referenzierten Complets oder BVH kann definiert werden als eine Übersetzung, die auf das Koordinatensystem des Raums (z. B. Welt-Raum oder anderer Objekt-Raum) des referenzierenden Complets oder BVH angewendet wird. Gemäß manchen Ausführungsformen kann zusätzlich zum Übersetzen des Ursprungs des globalen oder anderen lokalen Koordinatensystems des referenzierenden Complets oder BVH in einen neuen Ursprung des lokalen Koordinatensystems eine Rotations- und/oder Skalierungstransformation auf das globale oder andere lokale Koordinatensystem angewendet werden, um das lokale Koordinatensystem des referenzierten Complets oder BVH zu definieren.
Ein Element-Bereich-Kind eines Complets spezifiziert eine Gruppe von einem oder mehreren Primitiven eines Typs, der von der TTU nicht auf Schnittpunkte getestet wird. Gemäß manchen Ausführungsformen delegiert die TTU die Schnittpunktprüfung eines Element-Bereichs an Software, die auf dem SM läuft. Zum Beispiel, wenn ein Element-Bereich, bestehend aus einem Index (z. B. der von einer Benutzer- oder einer software-gelieferten „Element-Bereich-Basis“ abgeleitet werden kann, die im Complet gespeichert ist) und einer z. B. 6-Bit-Zählung von Elementen, während der Traversierung getroffen wird, werden standardmäßig Element-Bereiche als Treffertyp „ItemRange“ oder „ElementBereich“, bestehend aus zum Beispiel einem Index (z. B. 47-Bit-Index), einer Zählung (z. B. 6-Bit-Zählung) und dem t-Wert (z. B. Koordinaten entlang des Strahls) des Schnittpunkts mit dem Blatt-Begrenzungsvolumen, an den SM 132 zurückgegeben.
Ein Primitiv-Bereich (in einer Ausführungsform ein Dreieck-Bereich) eines Complets spezifiziert eine Gruppe von einem oder mehreren komprimierten oder unkomprimierten Alpha- (z. B. transparenten) oder opaken Primitiven des Primitiv-Typs, an dem die TTU Schnittpunkttests für einige oder alle von der TTU gehandhabten Typen von Abfragen durchführen kann, die in einem Array von zusammenhängenden Blöcken gespeichert sind. Null oder mehr Primitiv-Puffer enthalten Primitive, die als z. B. ein Triplett oder anderer Satz von z. B. fp32-Koordinaten oder Parametern pro Vertex oder in einem verlustfrei komprimierten Format gespeichert sind, das von der TTU 700 gelesen werden kann. Die Primitiv-Bereich-Parameter können Nicht-Vertex-Parameter (z. B. Radius) enthalten. Zusätzlich kann pro Primitiv ein Alpha-Bit bereitgestellt werden, das Primitive anzeigt, die ein Benutzer oder eine Software als solche bestimmt hat, die besondere Behandlung durch Software erfordern, um zu bestimmen, ob das Primitiv tatsächlich von einem bestimmten Strahl geschnitten wird. Primitiv-Puffer können in manchen Ausführungsbeispielen in Blöcken organisiert werden, die speicher- und/oder cacheorientiert sind, z. B. 128B groß und 128B-orientiert. In einer Ausführungsform spezifiziert ein Dreieck-Bereich eine Gruppe von einem oder mehreren komprimierten oder unkomprimierten Alpha- (z. B. transparenten) oder opaken Dreiecken, die die TTU auf Schnittpunkte mit Strahlen testen kann.
In einer Ausführungsform wird, wenn ein Dreieck-Bereich, der einem zusammenhängenden Satz von Dreiecken innerhalb eines Dreieck-Puffers entspricht, während Traversierung getroffen wird, in bestimmten Ausführungsbeispielen der von einem Strahl getroffene Dreieck-Bereich standardmäßig von der TTU 700 nativ behandelt, indem die Dreiecke in dem Bereich auf Schnittpunkte getestet werden und der Strahl entsprechend verkürzt wird. Wenn die Traversierung abgeschlossen ist und ein Dreieck geschnitten worden ist, ist das Vorgabe-Verhalten, dass die Dreieck-ID zusammen mit dem t-Wert und baryzentrischen Koordinaten des Schnittpunkts an den SM 132 zurückgegeben wird. Dies kann als Treffertyp „Dreieck“ bezeichnet werden. In manchen Ausführungsformen werden geschnittene Dreiecke mit dem gesetzten Alpha-Bit standardmäßig an den SM 132 zurückgegeben, auch wenn die Traversierung noch nicht abgeschlossen ist. Wie im Folgenden näher beschrieben, kann ein an den SM zurückgegebener Traversierungsstapel mit dem Schnittpunkt den Status enthalten, der zum Fortsetzen der Traversierung erforderlich ist, wenn Software bestimmt, dass das Dreieck tatsächlich transparent war. Dreieck-Schnittpunkt wird in manchen Ausführungsformen nicht für Strahlenbündel unterstützt, so dass getroffene Dreieck-Bereiche standardmäßig als Treffertyp „TriRange“ oder „DreiBereich“ an den SM 132 zurückgegeben werden können, der einen Zeiger auf den ersten Dreieck-Block, der den Bereich überlappt, Parameter, die den Bereich spezifizieren, und den t-Wert (z. B. parametrische Entfernung(en) des Schnittpunkts) des Schnittpunkts mit dem Blatt-Begrenzungsvolumen enthält.
Jeder Strahl, der der Baumtraversierungseinheit (z. B. TTU 700) für Abfrage durch den Streaming-Prozessor (z. B. SM 132) vorgelegt wird, umfasst: (1) geometrische Parameter des Strahls, wie zum Beispiel die Position des Strahls, einen Richtungsvektor und das nahe und das ferne parametrische Intervall (tmin, tmax); (2) Traversierungsstatus, der einen Stapel von einem oder mehreren Stapeleinträgen enthalten kann, die auf Blöcke in der BVH-Baumstruktur verweisen, die abzurufen und gegen den Strahl auf Schnittpunkte zu testen sind; und (3) Modus-Flags, die beschreiben, wie der Strahl bestimmte Typen von Interaktionen während der Traversierung und RayOp-lnformationen handhaben soll.
Für jeden Strahl können die geometrischen Informationen des Strahls, wie zum Beispiel der Ursprung, die Richtung und das nahe und ferne parametrische Intervall des Strahls, bereitgestellt werden. Der Ursprung, die Richtung sowie der Anfang und das Ende des parametrischen Intervalls können jeweils als Koordinaten-Tupel spezifiziert werden. Die nahen und fernen parametrischen Positionen werden hierin als tmin bzw. tmax bezeichnet und können als das aktuell interessierende Segment entlang des Strahls darstellend betrachtet werden. In manchen Ausführungsformen kann in der Abfrage ein Strahlenbündel spezifiziert werden. Ein Strahlenbündel ist zusätzlich durch einen zweiten Ursprung und eine zweite Richtung spezifiziert.
Eine Beispiel-Abfrage oder Strahldatenstruktur 1102 ist in 11A gezeigt. In manchen Ausführungsbeispielen werden die Strahlinformationen über Register im SM an die TTU übermittelt. In Ausführungsbeispielen, in denen Strahldaten über Speicher an die TTU weitergegeben werden, kann sich die Datenstruktur 1102 oder ein Teil davon in einem von der TTU zu lesenden Speicher befinden. Die Strahldatenstruktur 1102 kann einen Strahl-Identifikator 1104, der von der TTU oder dem SM zugewiesen werden kann, um Strahlen, die gleichzeitig in der TTU verarbeitet werden, eindeutig zu identifizieren, Strahlursprung- 1106, Strahlrichtung- 1108, Strahlanfang- (tmin) 1110 und Strahlende- (tmax) 1112 Parameter enthalten. Gemäß manchen Ausführungsformen können die Strahlinformationen 1102 auch Strahl-Flags 1114, RCT-Modus-Flags 1116 (auch als RCT-Modus-Bits bezeichnet), RPT-Modus-Flags 1118 (auch als RPT-Modus-Bits bezeichnet) und eine oder mehrere Ray-Operation (RayOps) -Spezifikationen enthalten. Jede RayOps-Spezifikation kann einen Strahloperations-Opcode 1120 und Strahl-Testparameter (z. B. Strahlparameter A & B) 1121 enthalten. Diese Strahldatenattribute werden im Folgenden beschrieben.
Wie im Folgenden beschrieben, wird für jeden Primitiv- oder Kind-Begrenzungskasten, der von einem Strahl geschnitten wird, ein „RayOp“-Test unter Verwendung des RayOp-Opcodes, der Modus-Bits und der Parameter A und B sowie eines oder mehrerer Parameter (z. B. Kind-Typ-, „rval“-Parameter oder „Alpha“-Flag) des Strahls durchgeführt, die mit jedem geschnittenen Complet-Kind oder Primitiv spezifiziert sind. In Ausführungsbeispielen werden die nachfolgend beschriebenen Kind-Typ- und rval-Parameter, die bei RayOp-Tests verwendet werden, für jedes Kind in einem Complet oder für das Complet als Ganzes spezifiziert, und der RayOp-Opcode, die Modus-Bits sowie die Parameter A und B werden für jeden Strahl spezifiziert. Ein Beispiel für eine Datenstruktur 1122, die RayOp-bezogene Informationen oder ein Complet oder Begrenzungsvolumen gemäß manchen Ausführungsformen enthalten kann, ist in 11B gezeigt. Gemäß manchen Ausführungsformen kann die Datenstruktur 1122 per Software in einem Speicher gespeichert werden, und die TTU kann entweder auf die Datenstruktur im Speicher zugreifen und/oder kann die Datenstruktur in den internen Speicher der TTU empfangen. Die Datenstruktur 1122 kann Kopfinformationen 1124, ein oder mehrere Übersteuer-Flags 1126 und ein rval 1128 enthalten. Kopfinformationen können geometrische Informationen, Knoten-Typ-Informationen usw. enthalten, die sich auf den Knoten beziehen. Die Übersteuer-Flags 1226 und die rval-Parameter 1128 werden im Folgenden beschrieben.
Während der Traversierung einer BVH durch einen Strahl in der TTU bleibt der Traversierungsstatus für den Strahl in der TTU aufrechterhalten. Der Traversierungsstatus kann einen Stapel von einem oder mehreren Einträgen enthalten, die auf Begrenzungsvolumina und/oder Complets in der Baumstruktur verweisen, die abzurufen und gegen den Strahl zu testen sind. Ein Traversierungsstapel 1202 gemäß manchen Ausführungsformen ist in 12 gezeigt. Der Traversierungsstapel 1202 kann beliebig viele Stapeleinträge enthalten. In manchen Ausführungsformen ist der Stapel 1202 auf eine kleine Anzahl von Einträgen beschränkt (z. B. ein „Kurzstapel“ von 4 Einträgen), so dass der Austausch des Stapels zwischen TTU und SM effizienter gemacht werden kann. In 12 sind ein unterer Stapeleintrag 1204 und ein oberer Stapeleintrag 1206 mit einem oder mehreren Einträgen dazwischen gezeigt.
Die TTU 700 ist, zumindest in manchen Ausführungsformen, statuslos. Das heißt, zwischen Abfragen wird in der TTU kein Architekturstatus aufrechterhalten. Der Traversierungsstapel ermöglicht es der TTU, den Status während einer Abfrage aufrechtzuerhalten und diesen Status nach Bedarf an den SM weiterzugeben. Die auf dem SM laufende Software kann Fortsetzung einer früheren Abfrage anfordern, indem sie den im Traversierungsstapel enthaltenen Status an die TTU zurückgibt. Der SM übermittelt den Traversierungsstatus für jede Abfrage an die TTU unter Verwendung eines oder mehrerer Stapel oder anderer Datenstrukturen einer bestimmten Größe StapelGrenze (SL), und die TTU gibt den Traversierungsstatus unter Verwendung eines oder mehrerer Stapel oder anderer Datenstrukturen der Größe SL an den SM zurück. Innerhalb der TTU unterhält jeder Strahl einen oder mehrere Stapel oder andere Datenstrukturen, die eine Größe >=SL haben können.
13 zeigt eine Beispiel-Ergebniswarteschlange gemäß manchen Ausführungsformen. Eine Ergebniswarteschlange, wie an anderer Stelle beschrieben, wird dafür verwendet, dass die TTU Informationen über die bisher erkannten Schnittpunkte an den SM überträgt. In manchen Ausführungsformen ist die Ergebniswarteschlange 1310 klein und kann nur ein Opakes-Primitiv-Schnittpunkt-Ergebnis 1312 und/oder ein oder mehrere Alpha-Primitiv-Schnittpunkt-Ergebnisse 1314 unterbringen. In anderen Ausführungsformen kann die Ergebniswarteschlange jedoch mehr Einträge unterbringen, die erkannte Schnittpunkte darstellen.
Die Diagramme von 10B und 10C fassen die Strahlverfolgungs-Pipeline zusammen und zeigen den Datenfluss und die Interaktion zwischen Komponenten für einen repräsentativen Anwendungsfall: das Verfolgen von Strahlen gegen eine Szene, die Primitive wie z. B. Dreiecke enthält, wobei Instanztransformationen und bestimmte Schnittpunkttests in Hardware verarbeitet werden. Wie in Bezug auf 10B beschrieben, können der TTU ein oder mehrere Strahlen gleichzeitig für Abfrage durch den SM vorgelegt werden, und jeder Strahl, der der TTU zur Traversierung vorgelegt wird, kann die geometrischen Parameter des Strahls, den Traversierungsstatus sowie die Strahl-Flags, Modus-Flags und RayOp-lnformationen des Strahls enthalten. Die Traversierungsoperationen von 10B und 10C können eine Strahldatenstruktur, wie sie in 11A gezeigt ist, eine Knoten-Datenstruktur, wie sie in 11B gezeigt ist, einen oder mehrere Traversierungsstapel, wie sie in 12 gezeigt sind, und eine Ergebniswarteschlange, wie sie in 13 gezeigt ist, verwenden. Eine Ergebniswarteschlange kann in manchen Ausführungsformen ein einzelner Eintrag sein, der ein Opak- oder ein Alpha-Ergebnis enthält.
Die Modus-Flags ermöglichen es, das Traversierungsverhalten zu ändern, indem z. B. ein Hilfs-Arithmetik- oder Logik-Test in Form eines RayOp spezifiziert wird, um einen Schnittpunkt zu unterdrücken, zu übersteuern oder Speicherung eines während einer Traversierung getroffenen Schnittpunkts zu erlauben, wie es in 10B gezeigt ist. Wie in Bezug auf 10B erwähnt, kann diese Fähigkeit von Anwendungen genutzt werden, um dynamisch und/oder selektiv Sätze von Objekten für Schnittpunkttests gegenüber bestimmten Sätzen oder Gruppen von Abfragen freizugeben / zu deaktivieren, zum Beispiel um verschiedene Versionen von Modellen verwenden zu können, wenn sich ein Spiel-Status ändert (zum Beispiel beim Öffnen oder Schließen von Türen), oder um verschiedene Versionen eines Modells bereitzustellen, die als Funktion der Länge des Strahls ausgewählt werden, um eine Form von geometrischem Detaillierungsgrad zu realisieren, oder um bestimmten Sätzen von Objekten aus bestimmten Klassen von Strahlen zu erlauben, in bestimmten Ansichten manche Schichten sichtbar oder unsichtbar zu machen. Diese Fähigkeit ermöglicht es auch, Alpha in Opak zu ändern und umgekehrt. Die Modus-Flags können es ermöglichen, das Traversierungsverhalten in Übereinstimmung mit Aspekten zu ändern wie zum Beispiel einer Tiefe (oder Entfernung), die einem jedem Begrenzungsvolumen und/oder Primitiv zugeordnet ist, der Größe eines Begrenzungsvolumens oder Primitivs in Bezug auf eine Entfernung vom Ursprung oder dem Strahl, bestimmten Instanzen eines Objekts, usw.
Der Satz von Modus-Flags, die mit jeder Abfrage (z. B. Strahl) vorgelegt werden, kann mindestens teilweise steuern, wie die TTU die Abfrage verarbeiten wird, wenn die Abfrage das Begrenzungsvolumen eines bestimmten Typs schneidet oder ein Primitiv eines bestimmten Primitiv-Typs schneidet. Zusätzlich zu dem Satz von Modus-Flags, die für den Strahl-Complet-Schnittpunkt und für Strahl-Primitiv-Schnittpunkte getrennt spezifiziert werden können, kann die Strahldatenstruktur andere RayOp-Testparameter spezifizieren, wie zum Beispiel die Strahl-Flags, Strahl-Parameter und den RayOp-Test. Die TTU reserviert einen „Strahl-Slot“ für jeden aktiven Strahl, der gerade in der TTU verarbeitet wird, und kann die Strahl-Flags, Modus-Flags und/oder die RayOp-lnformationen während der Traversierung in dem entsprechenden Strahl-Slot-Puffer innerhalb der TTU speichern.
Die Strahl-Flags können von der TTU verwendet werden, um verschiedene Aspekte des Traversierungsverhaltens, des Backface-Culling und der Behandlung der verschiedenen Kind-Knoten-Typen zu steuern, abhängig vom Bestehen/Nichtbestehen-Status eines optionalen RayOp-Tests. RayOp-Tests fügen daher den Fähigkeiten der TTU Flexibilität hinzu, auf Kosten einer gewissen Komplexität.
14 zeigt ein Flussdiagramm eines Prozesses 1400, der durchgeführt werden kann, wenn während der Strahlverfolgungs-Pipeline-Verarbeitung ein Strahlbegrenzungsvolumen-Schnittpunkt erkannt wird. Zum Beispiel kann der Prozess 1400, wenn in Schritt 1010 und/oder 1024, in 10B gezeigt, ein Strahlbegrenzungsvolumen-Schnittpunkt erkannt wird (z. B. bei der Top-Level-Traversierung und/oder der Bottom-Level-Traversierung), in Bezug auf den in 10B gezeigten Prozess durchgeführt werden. Die Strahlbegrenzungsvolumen-Schnittpunkttests 1010 und/oder 1024 können in der TTU 700 im Strahl-Complet-Test-Block 710 durchgeführt werden.
Die Schnittpunkt-Erkennung in Schritt 1402 kann stattfinden, wenn ein ausgelesenes Complet getestet wird, oder insbesondere, wenn ein Kind-Begrenzungsvolumen getestet wird, das in dem ausgelesenen Complet enthalten ist. Gemäß Ausführungsbeispielen kann die TTU, wenn ein Complet verarbeitet wird, optional den RayOp-Test an jedem Kind durchführen. In manchen Ausführungsformen wird der RayOp-Test nur an den Kindern laufen gelassen, deren entsprechendes Begrenzungsvolumen von dem Strahl geschnitten worden ist.
Somit wird in Schritt 1404 bestimmt, dass das abgerufene Complet mindestens ein Kind hat, und in Schritt 1406 wird auf die Kind-Begrenzungsvolumina zugegriffen und werden diese parallel getestet. In manchen Ausführungsformen hat jedes abgerufene Complet null oder ein Eltern-Complet und null oder mehr Complet-Kinder und null oder mehr Blattknoten-Kinder. In manchen Ausführungsformen verweist jedes abgerufene Complet mit einem Eltern-Zeiger oder Offset auf sein Eltern-Complet, codiert Kind-Zeiger in komprimierter Form und liefert eine Pro-Kind-Struktur, die einen Kind-Begrenzungskasten und Pro-Kind-Daten enthält, die vom RayOp-Test verwendet werden (z. B. Rval, Invert- RayOp-Ergebnis-Flag), und (im Falle von Blattknoten) Daten, die zum Adressieren und Verarbeiten von Blöcken von Blattknoten verwendet werden (z. B. Element-Zählung, Anfangs-Primitiv-Index, Anzahl der Blöcke im Blatt, ein Flag, das das Vorhandensein von Alpha-Primitiven anzeigt). In manchen Ausführungsformen können die Verarbeitungsschritte 1408-1414 für alle Kind-Begrenzungsvolumina parallel durchgeführt werden. In noch weiteren Ausführungsformen können die Verarbeitungsschritte 1408-1414 Kind für Kind, parallel für Gruppen von Kind-Begrenzungsvolumina, usw. durchgeführt werden.
Alle Kind-Begrenzungsvolumina des geschnittenen Elternteils sind potenzielle Traversierungsziele. In Ausführungsbeispielen ist ein Instanzknoten ein Blattknoten, der auf den Wurzelknoten einer anderen BVH zeigt. Der RayOp-Test kann an den Kind-Knoten eines geschnittenen Elternteils auf Basis der Kind-Begrenzungsvolumen-Informationen durchgeführt werden, die in dem bereits ausgelesenen Complet verfügbar sind, bevor bestimmt wird, ob die den jeweiligen Kind-Knoten entsprechenden Complets für Traversierung auszulesen sind oder nicht.
In Schritt 1408 wird der für den Strahl spezifizierte RayOp-Test in Bezug auf das zugegriffene Kind-Begrenzungsvolumen durchgeführt. Wie oben in Bezug auf 11A erwähnt, kann der RayOp-Opcode als Teil der Strahldaten spezifiziert werden, die der TTU 700 von dem SM 132 zugeführt werden. In Ausführungsbeispielen kann der Traversierungslogikblock 712 den RayOp-Test auf Basis des Strahls und der geschnittenen Kind-Knoten des Begrenzungsvolumens durchführen, wenn der Strahlbegrenzungsvolumen-Schnittpunkt im Strahl-Complet-Test-Block 710 erkannt wird. Insbesondere wird der RayOp-Test, der durch den für den Strahl spezifizierten bestimmten RayOp-Opcode spezifiziert ist, unter Verwendung der RayOp-Parameter A und B des Strahls und des für das Kind-Begrenzungsvolumen spezifizierten RayOp-rval-Parameters durchgeführt. In manchen Ausführungsformen wird der RayOp-Test nur für Kind-Begrenzungsvolumina durchgeführt, die selbst als den Strahl schneidend gefunden wurden. Wenn zum Beispiel die RCT-Einheit einen Strahl gegen ein Complet testet, wird jedes der Kind-Begrenzungsvolumina des Complets auch auf Schnittpunkte mit dem Strahl getestet, und für jedes Kind, das als den Strahl schneidend gefunden wird, wird der RayOp-Test durchgeführt.
Ein Beispiel-RayOp-Test kann das Testen eines linken numerischen Wertes auf Basis eines Strahlparameters in Bezug auf eine bestimmte Arithmetik- oder Logik-Operation gegen einen rechten Wert auf Basis eines Strahlparameters und eines Parameters des geschnittenen Knotens ermöglichen. Der RayOp-Test kann eine arithmetische oder logische Berechnung sein, die in einer Wahr/Falsch-Ausgabe resultiert. Die bestimmte Berechnung (z. B. die bestimmte Beziehung zwischen den RayOp-Parametern A und B, dem RayOp-Opcode und dem rval-Parameter) kann konfigurierbar sein und/oder kann in Hardware vorprogrammiert werden. In manchen Ausführungsformen kann jeder Strahl einen aus einer Vielzahl von Opcodes entsprechend jeweiligen RayOp-Tests spezifizieren. Somit bietet der RayOp-Test eine hochflexible Technik, mit der Strahlen das standardmäßige Strahlverfolgungs-Verhalten der TTU 700 auf einer Individual- oder Gruppenbasis ändern können.
Die RayOp-Tests können irgendwelche der Arithmetik- oder Logik-Operationen ALWAYS, NEVER, EQUAL, NOTEQUAL, LESS, LEQUAL, GREATER, GEQUAL, TMIN_LESS, TMIN GEQUAL, TMAX_LESS, TMAX_GEQUAL als Opcodes enthalten. Der in einem Strahl spezifizierte Opcode kann in manchen Ausführungsformen irgendeine Logik- oder Arithmetik- Operation sein.
Wenn zum Beispiel der RayOp-Opcode des Strahls in den der TTU zugeführten Strahlinformationen als „EQUAL“ definiert ist und die RayOp-Parameter A und B 0x0 bzw. 0xFF sind und das RayOp-rval des zugegriffenen Kind-Begrenzungsvolumens 0x1 ist, kann der RayOp-Test „A EQUAL rval && B“ sein. Somit ergibt der RayOp-Test mit den oben genannten Werten für die verschiedenen Parameter und Opcodes „0x00 == 0x1 && 0xFF“. Daher (da dies falsch ist) muss der RayOp-Test in diesem Beispiel Falsch zurückgeben. Das heißt, in diesem bestimmten Beispiel schlägt der RayOp-Test für den Strahl und das zugegriffene Kind-Begrenzungsvolumen fehl.
In manchen Ausführungsformen kann das Kind-Begrenzungsvolumen auch einen Invert-Parameter (z. B. „inv“) aufweisen, der dem RayOp-Testen zugeordnet ist. Wenn der Strahl auch einen dem RayOp zugeordneten Invert-Parameter aufweist und der Invert-Parameter auf TRUE (z. B. 1) gesetzt ist, kann das zurückgegebene RayOp-Ergebnis das Inverse des tatsächlichen RayOp-Testergebnisses sein. Wenn zum Beispiel der Invert-Parameter des Strahls auf TRUE gesetzt worden ist, würde der RayOp-Test in dem obigen Beispiel TRUE zurückgeben. RayOps können mit dem Stencil-Test bei Rastergrafik vergleichbar sein, außer dass der Stencil-Test die Fähigkeit besitzt, das Schreiben eines Fragments zu ermöglichen, auch wenn das Fragment den Tiefentest nicht bestanden hat. In Ausführungsbeispielen haben die RayOps nicht die Fähigkeit, ein verfehltes Complet-Kind in ein getroffenes Complet-Kind zu verwandeln, doch könnte in anderen Ausführungsformen die TTU Programmierbarkeit ermöglichen, so dass ein RayOp einen Fehlschuss so behandeln könnte, als wäre er ein Treffer.
Es ist nicht notwendig, dass der RayOp-Test die Parameter und den Opcode in einer Beziehung wie z. B. „A EQUAL rval && B“ angeordnet hat. Ausführungsbeispiele können die Parameter und den Opcode in irgendeiner logischen oder arithmetischen Beziehung angeordnet haben. In manchen Ausführungsformen kann die Beziehung zum Beispiel in einer Form wie z. B. „TMIN_LESS rval“ oder „TMIN_LESS A & rval“ vorliegen, was eine Beziehung zwischen einer spezifizierten interessierenden Fläche und entweder dem Knotenparameter allein oder einer Kombination der Strahlparameter und des Knotenparameters ausdrückt. Die Beispiel-Opcodes TMIN_LESS, TMIN GEQUAL, TMAX_LESS, TMAX_GEQUAL ermöglichen es alle, den RayOp-Test auf dem Anfang oder Ende des Schnittpunkts basieren zu lassen (z. B. TMIN und TMAX in den obigen Opcodes können die t-Werte am Eintritt des Strahls in das bzw. am Austritt aus dem geschnittenen Volumen darstellen (z. B. bbox.tmin, bbox.tmax unten)) und Aspekte entweder des getesteten Knotens allein oder des getesteten Knotens und der Strahlparameter A und/oder B einzubeziehen. Wenn zum Beispiel rval mit einem Entfernungswert für den Knoten codiert wird, kann „TMIN LESS rval“ einen Test darstellen wie z. B. „befindet sich der getestete Knoten in einer Entfernung, die kleiner als der Beginn der interessierenden Fläche ist?“ Opcodes, die auf anderen Aspekten des Strahls als Anfang/Ende des Strahls basieren, sind ebenfalls möglich und können in anderen Ausführungsformen für den RayOp verwendet werden. Im Gegensatz zu Opcodes, die einen Aspekt der geometrischen Eigenschaften des Strahls codieren, ermöglichen Beispiel-Opcodes ALWAYS, NEVER, EQUAL, NOTEQUAL, LESS, LEQUAL, GREATER, GEQUAL einen Vergleich eines beliebig spezifizierten Links-Wertes mit einem beliebig spezifizierten Rechts-Wert. Somit können Beispiel-Opcodes ALWAYS, NEVER, EQUAL, NOTEQUAL, LESS, LEQUAL, GREATER, GEQUAL für RayOp-Tests verwendet werden, die von manchen geometrischen Aspekten des Strahls oder des getesteten Knotens abhängen, und können außerdem für RayOp-Tests verwendet werden, die unabhängig von irgendwelchen geometrischen Eigenschaften des Strahls und/oder des getesteten Knotens sind. Somit bewerten in nicht einschränkenden Ausführungsbeispielen RayOp-Tests „FLT_TMIN_LESS“, „FLT_TMIN_GEQUAL“ und „FLT_TMAX_LESS“, und „FLT_TMAX_GEQUAL“ tatsächlich die Ausdrücke bbox.tmin < A * rval + B, bbox.tmin >= A * rval +B, bbox.tmax < A * rval + B bzw. bbox.tmax >= A * rval + B aus. In einer bestimmten nicht einschränkenden Ausführungsform ist rval ein FP0.6.2-Wert, und A und B sind FP1.5.10-Werte für diese Operationen. Da in manchen nicht einschränkenden Ausführungsbeispielen die Tests FLT_TMIN und FLT_TMAX an dem Begrenzungskasten-Wert tmin und dem Begrenzungskasten-Wert tmax arbeiten, welche beim Schnittpunkttest berechnete geometrische Werte sein können, können diese RayOps überdies für den geometrischen Detaillierungsgrad verwendet werden (z. B., wobei A dem Kosinus des Öffnungskegels der Bildebenenpixel entspricht und B der akkumulierten Länge der vorherigen Aufpralle des Strahls entspricht und rval der maximalen Länge max_length des Begrenzungskastens entspricht). In manchen Ausführungsformen ermöglichen die Opcodes (z. B. FLT_TMIN_LESS, FLT_TMAX_LESS), einen Wert, der während des Strahl-/Beschleunigungsdatenstruktur-Schnittpunkttests berechnet worden ist, der durch ein dem Strahl zugeordnetes geometrisches Attribut skaliert und durch ein anderes dem Strahl zugeordnetes geometrisches Attribut vorbelastet ist, mit mindestens einem dem mindestens einen Knoten zugeordneten geometrischen Parameter zu vergleichen.
In Schritt 1410 werden ein oder mehrere Modus-Flags entsprechend dem RayOp-Testergebnis identifiziert. Jedes Modus-Flag kann zum Beispiel in einer vorgegebenen Bitposition in einer Strahldatenstruktur spezifiziert werden und kann irgendeine Anzahl von Bits enthalten. Jedes Modus-Flag bildet ein Ergebnis des RayOp-Tests oder eine Kombination aus dem Ergebnis des RayOp-Tests und einem Knoten-Typ des getesteten Knotens auf eine bestimmte Aktion ab, die von der TTU durchzuführen ist. In manchen Ausführungsformen werden die Modus-Flags separat mit dem Strahl für Strahl-Complet-Testen bzw. Strahl-Primitiv-Testen spezifiziert. Als Antwort auf den Abschluss des RayOp-Tests in Schritt 1410 können somit das oder die anwendbaren Modus-Flag(s) in den für den Strahl spezifizierten RCT-Modus-Flags gefunden werden.
In dem obigen Beispiel, da der RayOp-Test fehlgeschlagen ist, enthalten das oder die anwendbaren Modus-Flag(s) das „ch_f mode flag“. Wie oben beschrieben, stellt „ch_f“ dar, dass der RayOp-Test für das Geschnittenes-Kind-Typ-Complet fehlgeschlagen ist.
In Schritt 1412 wird eine Aktion identifiziert, die auf Basis des oder der identifizierten Modus-Flag(s) und/oder der Strahl-Flags durchzuführen ist, und in Schritt 1414 wird die Aktion durchgeführt.
RCT-Modus-Flags drücken für jeden Complet-Kind-Typ (z. B. Complets, Instanz-Blattknoten, Element-Bereich-Blattknoten, Primitiv-Bereich-Blattknoten) aus, wie die TTU Strahlschnittpunkte mit Kind-Begrenzungsvolumina für Kind-Knoten dieses Typs für diejenigen Strahlen behandeln soll, die den RayOp-Test bestehen oder nicht bestehen. Beispiele für RCT-Modus-Flags umfassen „In_f“, „In_p“, „Ir_f“, „Ir_p“ , „Ir_p“, „pr_f“, „pr_p“, „ch_f“ und „ch_p“.
Das Modus-Flag „In_f“ („modelnstanceNodeFail“; „moduslnstanzKnoten-Nichtbestehen“) spezifiziert eine Aktion, die bei Nichtbestehen des RayOp-Tests für einen Geschnittenes-Kind-Typ-Instanzknoten („InstanceNode“) durchzuführen ist. Die unterstützten Aktionen können Verarbeitung in der TTU, Culling (z. B. Unterdrücke das Schieben eines Instanzknotens auf einen Traversierungsstapel), Rückgabe als Knotenverweis oder Rückgabe an den SM umfassen.
Das Modus-Flag „In_p“ („modeltemRangePass“; „modusElementBereich-Bestehen“) spezifiziert eine Aktion, die bei Bestehen des RayOp-Tests für einen Geschnittenes-Kind-Typ-Instanzknoten durchzuführen ist. Die unterstützten Aktionen können Verarbeitung in der TTU, Culling (z. B. Unterdrücke das Schieben eines Instanzknotens auf einen Traversierungsstapel), Rückgabe als Knotenverweis oder Rückgabe an den SM umfassen.
Das Modus-Flag „Ir_f“ („modeltemRangeFail“; „modusElementBereich-Nichtbestehen“) spezifiziert eine Aktion, die bei Nichtbestehen des RayOp-Tests für einen Geschnittenes-Kind-Typ-Element-Bereich („ItemRange“) durchzuführen ist. Die unterstützten Aktionen können Rückgabe an den SM (z. B. Schiebe Element-Bereich-Treffer in Ergebniswarteschlange), Culling (z. B. Unterdrücke das Speichern eines Element-Bereich-Treffers in der Ergebniswarteschlange) oder Rückgabe als Knotenverweis umfassen.
Das Modus-Flag „Ir_p“ („modeltemRangePass“; „modusElementBereich-Bestehen“) spezifiziert eine Aktion, die bei Bestehen des RayOp-Tests für einen Geschnittenes-Kind-Typ-Element-Bereich durchzuführen ist. Die unterstützten Aktionen können Rückgabe an den SM (z. B. Schiebe Element-Bereich-Treffer in Ergebniswarteschlange), Culling (z. B. Unterdrücke das Speichern eines Element-Bereich-Treffers in der Ergebniswarteschlange) oder Rückgabe als Knotenverweis umfassen.
Das Modus-Flag „pr_f“ („modePrimitiveRangeFail“; „modusPrimitivBereichNichtbestehen“) spezifiziert eine Aktion, die bei Nichtbestehen des RayOp-Tests für einen Geschnittenes-Kind-Typ-Primitiv-Bereich („PrimitiveRange“) durchzuführen ist. Die unterstützten Aktionen können Verarbeitung in der TTU (z. B. Schiebe Eintrag auf Traversierungsstapel), Culling (z. B. Unterdrücke das Schieben eines Dreieck-Bereich-Stapeleintrags auf Traversierungsstapel), Rückgabe als Knotenverweis oder Rückgabe an den SM umfassen.
Das Modus-Flag „pr_p“ („modePrimitiveRangePass“; „modusPrimitivBereichBestehen“) spezifiziert eine Aktion, die bei Bestehen des RayOp-Tests für einen Geschnittenes-Kind-Typ-Primitiv-Bereich durchzuführen ist. Die unterstützten Aktionen können Verarbeitung in der TTU (z. B. Schiebe Eintrag auf Traversierungsstapel), Culling (z. B. Unterdrücke das Schieben des Primitiv-Bereich-StapelEintrags auf Traversierungsstapel), Rückgabe als Knotenverweis oder Rückgabe an den SM umfassen.
Das Modus-Flag „ch_f“ („modeCompletFail“; „modusCompletNichtbestehen“) spezifiziert eine Aktion, die bei Nichtbestehen des RayOp-Tests für ein Geschnittenes-Kind-Typ-Complet („Complet“) durchzuführen ist. Die unterstützten Aktionen können Traversieren in der TTU, Culling oder Rückgabe als Knotenverweis umfassen.
Das Modus-Flag „ch_p“ („modeCompletPass“; „modusCompletBestehen“) spezifiziert eine Aktion, die bei Bestehen des RayOp-Tests für ein Geschnittenes-Kind-Typ-Complet durchzuführen ist. Die unterstützten Aktionen können Traversieren in der TTU, Culling oder Rückgabe als Knotenverweis umfassen.
In manchen Ausführungsformen kann zusätzlich zu dem oder den in Übereinstimmung mit dem RayOp-Testergebnis ausgewählten Modus-Flag(s) die ausgewählte Aktion in einer Weise durchgeführt werden, die mit einem oder mehreren in den Strahldaten spezifizierten Strahl-Flags konsistent ist. Die Strahl-Flags, wie z. B. die Strahl-Flags 1214, können das Verhalten unabhängig von irgendeinem bestimmten Schnittpunkt spezifizieren.
In Ausführungsbeispielen können die Strahl-Flags eine Traversierungs-Reihenfolge für die Begrenzungsvolumina spezifizieren, ob der Stapel bei Rückgabe zu öffnen ist oder nicht, ob Knotenverweise auf den SM zu melden sind oder nicht, wenn das tmin... tmax-Intervall des Strahls innerhalb des Begrenzungskastens des Knotens beginnt, ob beim ersten Treffer eines Schnittpunkts zurückzugeben ist oder nicht, Frontfacing-Einstellungen, Culling-Einstellungen und dergleichen.
Die Strahl-Flags für die Traversierungsreihenfolge können eines von Folgendem spezifizieren: Traversierung in der Reihenfolge der parametrischen Entfernung entlang des Strahls, Traversierung in der Speicherreihenfolge der Begrenzungsvolumina und/oder Primitive, Verkleinern der x-Koordinate, Vergrößern der x-Koordinate, Verkleinern der y-Koordinate, Vergrößern der y-Koordinate, Verkleinern der z-Koordinate und Vergrößern der z-Koordinate, usw. Insbesondere diktiert die Traversierungsreihenfolge die Reihenfolge, in der Stapeleinträge auf den Traversierungsstapel geschoben werden, wenn Complet-Kind-Begrenzungsvolumina von dem Strahl geschnitten werden. Insbesondere, wenn ein Knoten geschnitten wird, kann durch die Strahl-Flags spezifizierte Traversierungsreihenfolge von der TTU verwendet werden, um zu bestimmen, in welcher Reihenfolge die Kind-Knoten des geschnittenen Knotens in den Traversierungsstapel zu schieben sind. Es ist zum Beispiel nützlich, Schattenstrahlen zu verfolgen, die so eingestellt sind, dass sie bei dem ersten gefundenen Treffer und nicht speziell dem nächstgelegenen Treffer zurückkehren, wobei es wünschenswert ist, dass diese Strahlen zuerst gegen größere Primitive getestet werden (und somit wahrscheinlicher getroffen werden). Wenn der BVH derart aufgebaut ist, dass die Speicherreihenfolge von Blattknoten-Kindern Größtes-zuerst ist, dann ist es wünschenswert, für solche Strahlen die Speicherreihenfolge über t-Reihenfolge zu wählen, da es wahrscheinlicher ist, schneller an den SM zurückzugeben, und t-Reihenfolgebildung für solche Strahlen unerheblich ist.
Man kann die Traversierungsreihenfolge (t-Reihenfolge) aus verschiedenen Gründen ändern wollen. Zum Beispiel, wenn man versucht, das nächstgelegene Dreieck zu finden, möchte man typischerweise -Reihenfolge verwenden, so dass diejenigen Primitive, die auf der parametrischen Länge früher kommen könnten, zuerst getestet werden. Wenn diese Primitive geschnitten werden, müssen Primitive und Complets weiter entlang des Strahls möglicherweise nicht getestet werden. Wenn man versucht, irgendeinen Schnittpunkt zu finden (z. B. um zu testen, ob ein Punkt im Schatten eines Lichts liegt), dann ist es einem möglicherweise egal, welche bestimmten Primitive geschnitten werden, und man möchte möglicherweise die Primitive testen, die am wahrscheinlichsten zuerst geschnitten werden. In diesem Fall kann der BVH-Erbauer die größten Dreiecke früher in den Baum setzten, so dass die Speicherreihenfolge sie zuerst finden wird.
Die x/y/z-Reihenfolgebildung der Traversierung kann in dem Fall, dass die t-Reihenfolgebildung möglicherweise nicht konsistent ist, jeweils zum Approximieren der t-Reihenfolgebildung verwendet werden. Insbesondere ist der t-Schnittpunkt für eine Strahlenbündel-Traversierung und eine Strahl-Traversierung möglicherweise nicht konsistent, da die Abfragen unterschiedliche Formen haben (z. B. können sie ähnlich, aber nicht identisch sein). Die x/y/z-Reihenfolgebildungen basieren jedoch jeweils auf den Begrenzungsvolumen-Positionen allein und sind konsistent. Wenn die Verarbeitung so etwas wie Teilen des Stapels zwischen einem Strahlenbündel und einem Strahl erfordert, dann kann man die konsistente x/y/z-Reihenfolgebildung verwenden, um eine Leistung nahe an t-Reihenfolge zu erzielen.
Die Strahl-Flags zum Anzeigen, ob der Traversierungsstapel bei Rückgabe zu öffnen ist (z. B. „noPopOnReturn“; „keinÖffnenBeiRückgabe“), können spezifizieren, ob der Stapel zu öffnen ist und/oder ob das Ergebnis der Traversierung zurückzugeben ist, ohne den Stapel zu öffnen. Das Ergebnis der Traversierung zurückzugeben, ohne den Traversierungsstapel zu öffnen, kann es der SM ermöglichen, die gleiche Traversierung erneut laufen zu lassen oder den Stapel zu modifizieren, bevor eine neue Traversierung gestartet wird.
Die Strahl-Flags, die das Melden von Treffern steuern (z. B. das „reportOnEnter“- oder „meldeBeiEintritt“-Flag), können spezifizieren, dass die TTU einen Kind-Treffer nur dann melden soll, wenn ein AABB-Schnittpunkt t größer oder gleich dem tmin des Strahls ist, und andernfalls aussondern (und/oder nicht an den SM melden) soll. Dieses Flag ermöglicht es, ein Begrenzungsvolumen nicht an den SM zu melden, selbst wenn es geschnitten wird, wenn dieser Schnittpunkt (beim Eintritt des Strahls in das Begrenzungsvolumen) vor der spezifizierten interessierenden Fläche des Strahls stattfindet. Eine Beispiel-Verwendung dieses Flags ist für Strahlwandern, wobei nach dem Finden eines Schnittpunkts das tmin zum Beginn dieses Schnittpunkts vorgeschoben wird. Bei einem Neustart möchte man möglicherweise den nächsten Schnittpunkt finden, aber typischerweise nicht wieder den Schnittpunkt melden wollen, der gerade zurückgegeben worden ist. Durch Setzen des reportOnEnter-Flags kann vermieden werden, dass der Schnittpunkt wieder an den SM zurückgegeben wird, da ein neu gestarteter Strahl nicht in das Volumen eintritt, sondern innerhalb desselben startet.
Die Strahl-Flags, die steuern, ob beim ersten Treffer geendet werden soll (z. B. „terminateOnHit“; „beendeBeiTreffer“), spezifizieren, ob die TTU beim ersten Treffer für den während Traversierung gefundenen Strahl zurückgeben soll oder weiter traversieren soll, bis sie den parametrisch nächstgelegenen gefundenen Treffer zurückgeben kann.
Das oder die Strahl-Flag(s), die anzeigen, welche Dreiecke als nach vorne weisend anzusehen sind (z. B. „facingfrontFaceCW“; „vorweisendeFlächeCW“), können verwendet werden, um eine bestimmte Behandlung von geschnittenen Blättern zu spezifizieren. Unter der Voraussetzung eines rechtshändigen Koordinatensystems können diese Flags zum Beispiel die Behandlung von gegen den Uhrzeigersinn gewundenen Dreiecken als nach vorne weisend oder die Behandlung von im Uhrzeigersinn gewundenen Dreiecken als nach vorne weisend spezifizieren.
Strahl-Flags, die das Culling von geschnittenen Primitiven steuern (z. B. „cullMode“; „aussonderModus“), können spezifiziert werden, kein Culling, Culling von nach hinten weisenden Primitiven oder Culling von nach vorne weisenden Primitiven anzuzeigen oder das Culling und das Testen von Primitiv-Rändern zu deaktivieren.
Die Traversierungslogik (z. B. der Traversierungslogikblock 712) führt die von dem oder den entsprechenden Modus-Flag(s) aufgezählte Aktion auf Basis des Ergebnisses des RayOp-Tests (oder des Inversen des Ergebnisses des RayOp-Tests, wenn das Kind-Invert-Flag gesetzt ist) durch. Da in dem obigen Beispiel das ch_f-Modus-Flag anzeigt, dass das Kind-Begrenzungsvolumen auszusondern ist, wenn der RayOp-Test nicht bestanden wird, wird die Traversierungslogik keinen Stapeleintrag auf den Traversierungsstapel des Strahls für dieses Kind-Begrenzungsvolumen schieben, obwohl der Strahl das Begrenzungsvolumen des Kindes möglicherweise schneidet, und das Vorgabe-Verhalten für geschnittene Kind-Begrenzungsvolumina ist, dass das Kind in den Traversierungsstapel geschoben wird. Man beachte, dass der Strahl, statt einen Wert für ch_f mode flag zu spezifizieren, der anzeigt, dass das Kind auszusondern ist, wenn der RayOp-Test nicht bestanden wird, alternativ angezeigt haben könnte, dass das Kind in der TTU zu traversieren oder als Knotenverweis zurückzugeben ist.
Die Aktion der Traversierungslogik kann in einer Weise durchgeführt werden, die mit den Strahl-Flags des Strahls konsistent ist. Wenn zum Beispiel die Strahl-Flags eine bestimmte Traversierungsreihenfolge anzeigen, können die in Übereinstimmung mit dem RayOp-Test für Traversierung ausgewählten Kind-Begrenzungsvolumina auf eine mit der durch den oder die entsprechenden Strahl-Flag(s) spezifizierten Traversierungsreihenfolge konsistente Weise auf den Traversierungsstapel geschoben werden.
Die Schritte 1404-1414 können für jedes Kind des geschnittenen Begrenzungsvolumens wiederholt werden. Wenn jeder der Kind-Knoten oder zumindest jeder der Kind-Knoten, die als sich selbst mit dem Strahl schneidend gefunden worden sind, einen RayOp durchgeführt hat, hat das Eltern-Begrenzungsvolumen seinen Traversierungsschritt abgeschlossen. Das heißt, wenn ein Complet nur ein Wurzel-Begrenzungsvolumen und seine Kind-Begrenzungsvolumina enthält, ist die Traversierung dieses Complets abgeschlossen. Allgemeiner, wie wenn das Complet eine Wurzel und mehr als eine Ebene von Knoten enthält, ist die Traversierung des Complets abgeschlossen, wenn alle Blattknoten des Complets oder zumindest alle Blattknoten, die nicht ausgesondert worden sind, dem Strahlbegrenzungsvolumen-Schnittpunkttest und/oder dem RayOp-Test unterzogen worden sind.
15 zeigt ein Flussdiagramm eines Prozesses 1500, der zum Beispiel in Schritt 1414 im Prozess 1400 durchgeführt werden kann, wenn ein geschnittenes Begrenzungsvolumen ein Blatt ist.
In Schritt 1502 werden Informationen über die Strahlbegrenzungsvolumen-Schnittpunkt-Erkennung empfangen. Der nächste Schritt kann auf Basis des Typs der im geschnittenen Blatt-Begrenzungsvolumen enthaltenen Szenengeometrie bestimmt werden. Instanzknoten, Element-Bereiche und Primitiv-Bereiche werden in den Schritten 1504, 1508 bzw. 1512 verarbeitet.
Wenn die Szenengeometrie im geschnittenen Begrenzungsvolumen einen Instanzknoten enthält, wird in Schritt 1504 eine Strahl-Instanzknoten-Schnittpunkt-Erkennung durchgeführt. Wenn bestimmt wird, dass der Strahl den Instanzknoten schneidet, wird ein Eintrag mit folgenden Informationen auf den Traversierungsstapel geschoben: eine Adresse des Instanzknotens, der eine Transformation vom aktuellen (z. B. Welt-) Koordinatenraum in einen anderen Koordinatenraum und einen Zeiger auf die Wurzel einer anderen BVH in einem anderen (z. B. Objekt-) Koordinationsraum spezifiziert, ein „returnToSM“ („rückgabeAnSM“) -Flag, das anzeigt, ob die Abfrage an den SM zurückzugeben ist, so dass der SM den Traversierungsstatus der Abfrage in der aktuellen BVH abspeichern und die Transformation anwenden kann, und ein „initialisiertes“ Flag, das anzeigt, ob der Strahl (oder eine andere Instanz des aus dem Welt-Raum-Strahl geklonten Strahls) bereits initialisiert worden ist.
Wenn die Szenengeometrie im geschnittenen Begrenzungsvolumen einen Element-Bereich enthält, wird in Schritt 1506 eine Strahl-Element-Bereich-Schnittpunkt-Erkennung durchgeführt. Auf Basis der Schnittpunkt-Erkennung wird ein Eintrag mit folgenden Informationen auf den Traversierungsstapel geschoben:

eine Startadresse, die die Startadresse der Element-Bereich-Daten spezifiziert, und ein Zähler, der die Anzahl der Elemente in dem Bereich anzeigt.

Wenn die Szenengeometrie in dem geschnittenen Begrenzungsvolumen einen Primitiv-Bereich enthält, wird in Schritt 1512 eine Strahl-Primitiv-Bereich-Schnittpunkt-Erkennung durchgeführt. In Schritt 1514 wird bestimmt, ob die Primitive / der Primitiv-Bereich in der TTU zu verarbeiten ist oder ob ein Eintrag mit folgenden Informationen in den Traversierungsstapel zu schieben ist: die Adresse des letzten Blocks im Primitiv-Bereich („addrLast“), der Index des ersten Primitivs des Primitiv-Bereichs in der ersten Cache-Zeile („trildx“), der Index des letzten Primitivs in der letzten Cache-Zeile in dem Bereich, oder Null, was anzeigt, dass der Bereich in der letzten Cache-Zeile („triEnd“) endete, Anzahl der Blöcke, die den Primitiv-Bereich enthalten („Zeilen“), ein „co-Flag“, das anzeigt, ob opake Primitive auszusondern sind oder nicht, ein „ca-Flag“, das anzeigt, ob Alpha-Primitive auszusondern sind oder nicht, und ein „rp-Flag“, das anzeigt, ob der Primitiv-Bereich-RayOp-Test bestanden worden ist oder nicht.
In Fällen, in denen die RayOp- und Modus-Flags anzeigen, dass das Ergebnis für besondere Behandlung an den Streaming-Prozessor zurückzugeben ist, werden der Strahl, sein Traversierungsstatus und der Inhalt seiner Ergebniswarteschlange vollständig an den Streaming-Prozessor zurückgegeben. Der Streaming-Prozessor kann jede möglicherweise erforderliche zusätzliche Verarbeitung durchführen (zum Beispiel Interpolieren von Texturkoordinaten und Bewerten einer Alpha-Textur, um zu bestimmen, ob ein Alpha-Schnittpunkt zu ignorieren ist oder nicht, usw.), und wenn nötig, kann der SM die Abfrage mit den gleichen oder geänderten Abfrageparametern wieder vorlegen (zum Beispiel kann der Strahl beim Wiedervorlegen verkürzt werden, indem tmax enger gezogen wird).
16 zeigt ein Flussdiagramm eines Prozesses 1600, der durchgeführt werden kann, wenn zum Beispiel bei der Operation von Schritt 1502 ein Strahlbegrenzungsvolumen-Schnittpunkt 1602 in Bezug auf ein Blatt-Begrenzungsvolumen erkannt wird, das einen Primitiv-Bereich (z. B. einen Dreieck-Bereich) enthält, der in der TTU geklärt werden kann.
In Schritt 1604 wird der RayOp-Test für den Strahl in Bezug auf das Begrenzungsvolumen durchgeführt. Wenn die RCT-Einheit 710 ein Kind-Begrenzungsvolumen schneidet, das auf einen Primitiv-Bereich verweist, führt die TL-Untereinheit 712 den durch die RayOp-Abfrageparameter des Strahls spezifizierten RayOp-Test unter Verwendung der Parameter A, B und des rval-Parameters des Complet-Kindes durch und speichert das Ergebnis des RayOp-Tests in dem rp-Flag, das in dem Stapeleintrag gespeichert ist, der dem Primitiv-Bereich entspricht, der auf die Oberseite des Traversierungsstapels geschoben wird, wie oben in Bezug auf die Operation 1518 beschrieben.
Wenn die Stapelverwaltungseinheit 740 diesen Eintrag von der Oberseite des Stapels entfernt und eine Aktivierung an den Primitiv-Scheduler sendet, wird das rp-Flag vom Primitiv-Scheduler zusammen mit dieser Aktivierung an die RPT-Einheit 720 weitergeleitet. Wenn die RPT 720 einen Opak-Schnittpunkt oder Alpha-Schnittpunkt erkennt, liest die RPT 720 das oder die Modus-Flag(s) aus, die dem Typ des Primitiv-Treffers und dem rp-Flag entsprechen, und wendet die passende Aktion zum Behandeln des Schnittpunkts an. Wenn zum Beispiel ein Strahl mit rp flag = TRUE ein opakes Primitiv schneidet und das „op_p“-Flag des Strahls anzeigt, dass Opakes-Primitiv-Treffer aus bestandenen RayOp-Tests auszusondern sind, dann wird die RPT 720 den Opak-Schnittpunkt nicht in die Ergebniswarteschlange schieben.
In Schritt 1606 wird das Ergebnis des RayOp-Tests im rp-Flag gespeichert, und ein Eintrag, der das rp-Flag enthält, wird auf den Traversierungsstapel geschoben.
In Schritt 1608 wird der Stapel geöffnet und wird das rp-Flag dem Strahl-Primitiv-Test-Block zugeführt (z. B. Strahl/Dreieck-Test 1026 in 10B).
Wenn die Stapelverwaltungseinheit diesen Eintrag von der Oberseite des Stapels entfernt und eine Aktivierung an den Primitiv-Scheduler sendet, wird das rp-Flag vom Primitiv-Scheduler zusammen mit dieser Aktivierung an die RPT-Einheit weitergeleitet.
In Schritt 1610, bei der Strahl-Primitiv-Prüfung, werden Schnittpunkte zwischen dem Strahl und dem Primitiv erkannt. Wenn die RPT einen Opak-Schnittpunkt oder Alpha-Schnittpunkt erkennt, ruft die RPT das/die Modus-Flag(s) ab, die dem Typ des Primitiv-Treffers und dem rp-Flag entsprechen, und wendet die passende Aktion zum Behandeln des Schnittpunkts an.
RPT-Modus-Flags spezifizieren das TTU-Verhalten als Ergebnis eines abgeschlossenen Strahl-Primitiv-Tests. Das Beispiel-RPT-Modus-Flag „at_f“ („modeAlphaFail“; „modusAlphaNichtbestanden“) spezifiziert Aktionen, die durchzuführen sind, wenn der RayOp-Test für ein geschnittenes Alpha-Primitiv nicht bestanden wird. Die unterstützten Aktionen können das Schieben von Alpha-Treffern in eine Ergebniswarteschlange (z. B. Ergebnis 1310), die an den SM zu übermitteln ist, das Culling eines Alpha-Treffers (Alpha-Primitiv-Test unterdrücken) oder das Schieben eines Alpha-Treffers in die Ergebniswarteschlange als ein Opak-Treffer umfassen. Weitere Beispiel-RPT-Modus-Flags umfassen das Modus-Flag „at_p“ („modeAlphaPass“; „modusAlphaBestanden“), das Aktionen spezifiziert, die durchzuführen sind, wenn der RayOp-Test für ein geschnittenes Alpha-Primitiv bestanden wird. Die unterstützten Aktionen können das Schieben des Alpha-Primitiv-Treffers in die Ergebniswarteschlange, das Culling des Alpha-Treffers und das Schieben des Alpha-Treffers in die Ergebniswarteschlange als ein Opak-Treffer umfassen.
Das Modus-Flag „ot_f“ („modeOpaqueFail“; „modusOpakNichtbestanden“) spezifiziert eine Aktion, die durchzuführen ist, wenn der RayOp-Test für ein geschnittenes opakes Primitiv nicht bestanden wird. Die unterstützten Aktionen können das Schieben eines Opak-Treffers in die Ergebniswarteschlange, das Culling eines Opak-Treffers und das Schieben eines Opak-Treffers in die Ergebniswarteschlange als ein Alpha-Treffer umfassen. Das Modus-Flag „op_p“ („modeAlphaPass“; „modusAlphaBestanden“) spezifiziert eine Aktion, die durchzuführen ist, wenn der RayOp-Test für ein geschnittenes opakes Primitiv bestanden wird. Unterstützte Aktionen können das Schieben eines Opak-Treffers in die Ergebniswarteschlange, das Culling eines Opak-Treffers und das Schieben eines Opak-Treffers in die Ergebniswarteschlange als ein Alpha-Treffer umfassen.
Manche Knoten oder Blätter (z. B. Instanzknoten, Primitiv-Bereiche) können auch Flags enthalten, die mit den RayOp-Test- und Modus-Flags interagieren und/oder diese übersteuern. Zum Beispiel enthält der Instanzknoten-Kopf Flags „foa“ (Erzwinge Opak zu Alpha), „fao“ (Erzwinge Alpha zu opak), und „fnc“ (Erzwinge kein Culling) kann die Werte der Modus-Flags „op_p“, „op_f“, „ap_f“, „ap_f“, „ap_p“ eines Objekt-Raum-Strahls übersteuern, um die aus seinem entsprechenden Welt-Raum-Strahl kopierten Werte zu übersteuern. In Ausführungsbeispielen werden die Strahl-Modus-Bits für die Untere-BVH-Traversierung aus den Obere-BVH-Strahl-Modus-Bits kopiert.
In Schritt 1612 wird die Aktion auf Basis des rp-Flags und der Strahl-Primitiv-Modus-Flags ausgewählt. Wenn zum Beispiel ein Strahl mit rp flag = TRUE ein opakes Primitiv schneidet und die „op_p“-Flags des Strahls anzeigen, dass Opakes-Primitiv-Treffer aus bestandenen RayOp-Tests auszusondern sind, dann wird die RPT den Opak-Schnittpunkt nicht in die Ergebniswarteschlange schieben. Die Auswahl der Aktion kann auch irgendwelche Übersteuer-Parameter berücksichtigen, die in dem oder den getesteten Primitiv(en) und/oder anderen Strahl-Flags spezifiziert sind.
Wie oben beschrieben, bieten Ausführungsbeispiele die Fähigkeit, das Vorgabe-Verhalten der Traversierung einer Beschleunigungsstruktur durch eine Abfrage programmatisch zu ändern. In manchen Ausführungsbeispielen werden diese Fähigkeiten innerhalb der Chipfläche-Beschränkungen und anderer auferlegter Hardware-Beschränkungen nach Hardwarebeschleunigung der Traversierung ermöglicht. Die durch Ausführungsformen ermöglichten Fähigkeiten erlauben es Anwendungen unter anderem, geometrische Primitive eines Objekts in bestimmten Tiefenebenen für Strahlverfolgung selektiv zu verarbeiten, während der Strahlverfolgung unter mehreren Versionen eines Objekts in der BVH auszuwählen, geometrische Primitive von Objekten auf Basis des geometrischen Detailierungsgrades selektiv zu behandeln, geometrische Primitive von Objekten auf Basis des Auflösungsgrades selektiv zu behandeln, geometrische Primitive von Objekten auf Basis der Materialart selektiv zu behandeln, geometrische Primitive von Objekten auf Basis der Entfernung entlang des Strahls, von dem sie geschnitten werden, selektiv zu behandeln, usw. Ausführungsbeispiele können es auch ermöglichen, auf einer Pro-Strahl-Basis Operationen durchzuführen wie zum Beispiel Backface-Culling, welches für das Ignorieren aller Primitive sorgt, die vom Ursprung des bestimmten Strahls weg gerichtet sind, und Frontface-Culling, welches für das Ignorieren aller Primitive sorgt, die zum Ursprung des jeweiligen Strahls hin gerichtet sind. Darüber hinaus sorgen manche Ausführungsbeispiele auch für Übersteuern des Pro-Strahl-Verhaltens für bestimmte Schnittpunkte: Zum Beispiel können manche Knoten des BVH wie zum Beispiel Instanzknoten Übersteuer-Flags aufweisen, die ein Pro-Strahl-Verhalten wie z. B. Backface-Culling auf einer Instanz-Basis übersteuern können, so dass für Objekte wie z. B. Laub, bei dem ein einzelnes Dreieck-Primitiv ein Blatt darstellt, ein Strahl damit geschnitten wird, unabhängig davon, ob das Dreieck rückwärts weist.
Obwohl Ausführungsbeispiele in Bezug auf eine BVH als die Beschleunigungsstruktur und einen Strahl als die Abfrage beschrieben worden sind, sind Ausführungsformen nicht darauf beschränkt. Zum Beispiel kann in manchen anderen Ausführungsformen die Abfrage ein Strahlenbündel oder eine andere geometrische Form statt eines Strahls umfassen, und/oder hierarchische Strukturen, die sich von einer oben beschriebenen BVH unterscheiden, können als die Beschleunigungsstruktur verwendet werden. Ein Fachmann erkennt auch, dass die bestimmten Modus-Flags, RayOp-Opcodes, Strahl-Parameter-Werte, rval-Parameter Beispiele sind und dass Ausführungsformen irgendeine Kombination dieser und/oder anderer Parameter enthalten können, um die abfragespezifische Verhaltensmodifizierung der Traversierung einer Beschleunigungsstruktur bereitzustellen.
Die oben beschriebenen Fähigkeiten können in oder in Verbindung mit einer Parallelverarbeitungseinheit implementiert werden, wie sie nachstehend in Bezug auf 17-23 beschrieben ist.
Detailliertere TTU- und GPU-Architektur
Es werden nun nähere Informationen zu verschiedenen optionalen Architekturen und Merkmalen gegeben, mit denen das vorgenannte Gerüst nach den Wünschen des Benutzers implementiert werden kann oder nicht. Es sei ausdrücklich darauf hingewiesen, dass die folgenden Informationen zur Veranschaulichung gegeben werden und nicht als in irgendeiner Weise einschränkend auszulegen sind. Irgendeines der folgenden Merkmale kann wahlweise mit oder ohne den Ausschluss von anderen beschriebenen Merkmalen aufgenommen werden.
Parallelverarbeitungsarchitektur
17 veranschaulicht eine Parallelverarbeitungseinheit (PPU) 1700 gemäß einer Ausführungsform. In einer Ausführungsform ist die PPU 1700 ein Multi-Thread-Prozessor, der auf einer oder mehreren integrierten Schaltungen implementiert ist. Die PPU 1700 ist eine Latenz verbergende Architektur (Latency Hiding Architecture), die dafür ausgelegt ist, viele Threads parallel zu verarbeiten. Ein Thread (d. h. ein Thread einer Ausführung) ist eine Instanziierung eines Satzes von Befehlen, die konfiguriert sind, um von der PPU 1700 ausgeführt zu werden. In einer Ausführungsform ist die PPU 1700 eine Grafikverarbeitungseinheit (GPU, zum Beispiel wie die in Bezug auf 1 beschriebene), die konfiguriert ist, um eine Grafik-Render-Pipeline für Verarbeitung von dreidimensionalen (3D) Grafikdaten zu implementieren, um zweidimensionale (2D) Bilddaten für Anzeige auf einem Display-Gerät wie z. B. einem Flüssigkristalldisplay-Gerät (LCD-Gerät) zu erzeugen. In anderen Ausführungsformen kann die PPU 1700 zur Durchführung von Universalberechnungen verwendet werden. Obwohl hierin zur Veranschaulichung ein Beispiel-Parallelprozessor vorgesehen ist, sei ausdrücklich darauf hingewiesen, dass dieser Prozessor nur zu veranschaulichenden Zwecken angegeben ist und dass irgendein Prozessor eingesetzt werden kann, um diesen zu ergänzen und/oder zu ersetzen.
Eine oder mehrere PPUs 1700 können so konfiguriert sein, dass sie Tausende von Anwendungen für Hochleistungsrechner (HPC, High Performance Computing), Rechenzentren und maschinelles Lernen beschleunigen. Die PPU 1700 kann so konfiguriert sein, dass sie zahlreiche Systeme und Anwendungen für Deep Learning (tiefgehendes Lernen) beschleunigt, darunter autonome Fahrzeugplattformen, Deep Learning, hochpräzise Sprach-, Bild- und Texterkennungssysteme, intelligente Videoanalytik, molekulare Simulationen, Medikamentenentdeckung, Krankheitsdiagnose, Wettervorhersage, Big Data Analytik, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotik, Fabrikautomatisierung, Echtzeit-Sprachübersetzung, Online-Suchoptimierungen und personalisierte Benutzerempfehlungen und dergleichen.
Wie in 17 gezeigt, enthält die PPU 1700 eine Eingabe/Ausgabe-(I/O)-Einheit 1705, eine Vorverarbeitungseinheit 1715, eine Scheduler-Einheit 1720, eine Arbeitsverteilungseinheit 1725, einen Hub 1730, ein Koppelfeld (XBar, crossbar) 1770, einen oder mehrere Allgemeinverarbeitungscluster (GPCs) 1750 und eine oder mehrere Partitionseinheiten 1780. Die PPU 1700 kann über eine oder mehrere Hochgeschwindigkeits-NVLink-1710-Verbindungen mit einem Host-Prozessor oder anderen PPUs 1700 verbunden sein. Die PPU 1700 kann über eine Verbindung 1702 mit einem Host-Prozessor oder anderen Peripheriegeräten verbunden sein. Die PPU 1700 kann auch mit einem lokalen Speicher verbunden sein, der eine Anzahl von Speichergeräten 1704 umfasst. In einer Ausführungsform kann der lokale Speicher eine Anzahl von DRAM-(Dynamic Random Access Memory, Speicher mit dynamischem Direktzugriff)-Geräten umfassen. Die DRAM-Geräte können als ein HBM-(High-Bandwidth Memory)-Subsystem konfiguriert sein, wobei mehrere DRAM-Dies (Waferstücke) in jedem Gerät gestapelt sind.
Die NVLink 1710 Verbindung ermöglicht es Systemen, eine oder mehrere PPUs 1700 in Kombination mit einer oder mehreren CPUs zu skalieren und zu integrieren, unterstützt Cache-Kohärenz zwischen den PPUs 1700 und CPUs sowie CPU-Mastering. Daten und/oder Befehle können vom NVLink 1710 über den Hub 1730 zu/von anderen Einheiten der PPU 1700 übertragen werden, wie z. B. einer oder mehreren Kopier-Engines, einem Video-Encoder, einem Video-Decoder, einer Leistungsverwaltungseinheit usw. (nicht explizit gezeigt). Der NVLink 1710 wird in Verbindung mit 22 näher beschrieben.
Die I/O-Einheit 1705 ist so konfiguriert, dass sie über die Verbindung 1702 Kommunikation (d. h. Befehle, Daten, usw.) von einem Host-Prozessor (nicht gezeigt) sendet und empfängt. Die I/O-Einheit 1705 kann mit dem Host-Prozessor direkt über die Verbindung 1702 oder über ein oder mehrere Zwischen-Geräte wie z. B. eine Speicherbrücke kommunizieren. In einer Ausführungsform kann die I/O-Einheit 1705 über die Verbindung 1702 mit einem oder mehreren anderen Prozessoren kommunizieren, wie z. B. einer oder mehreren der PPUs 1700. In einer Ausführungsform implementiert die I/O-Einheit 1705 eine PCIe-(Peripheral Component Interconnect Express)-Schnittstelle für Kommunikation über einen PCIe-Bus, und die Verbindung 1702 ist ein PCIe-Bus. In alternativen Ausführungsformen kann die I/O-Einheit 1705 andere Arten von bekannten Schnittstellen für Kommunikation mit externen Geräten implementieren.
Die I/O-Einheit 1705 decodiert Pakete, die über die Verbindung 1702 empfangen wurden. In einer Ausführungsform repräsentieren die Pakete Befehle, die so konfiguriert sind, dass sie die PPU 1700 verschiedene Operationen durchführen lassen. Die I/O-Einheit 1705 überträgt die decodierten Befehle an verschiedene andere Einheiten der PPU 1700, wie es die Befehle spezifizieren können. Zum Beispiel können manche Befehle an die Vorverarbeitungseinheit 1715 übertragen werden. Andere Befehle können an den Hub 1730 oder andere Einheiten der PPU 1700 übertragen werden, wie z. B. eine oder mehrere Kopier-Engines, einen Video-Encoder, einen Video-Decoder, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt). Mit anderen Worten, die I/O-Einheit 1705 ist so konfiguriert, dass sie die Kommunikation zwischen und unter den verschiedenen Logikeinheiten der PPU 1700 weiterleitet.
In einer Ausführungsform codiert ein vom Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einem Puffer, der der PPU 1700 Arbeit (Workload) zur Verarbeitung liefert. Ein Workload kann mehrere Anweisungen sowie Daten, die von diesen Anweisungen verarbeitet werden sollen, umfassen. Der Puffer ist ein Bereich in einem Speicher, auf den sowohl der Host-Prozessor als auch die PPU 1700 zugreifen (d. h. lesen/schreiben) können. Zum Beispiel kann die I/O-Einheit 1705 so konfiguriert sein, dass sie über Speicheranforderungen, die über die Verbindung 1702 übertragen werden, auf den Puffer in einem Systemspeicher zugreift, der mit der Verbindung 1702 verbunden ist. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und sendet dann einen Zeiger auf den Anfang des Befehlsstroms an die PPU 1700. Die Vorverarbeitungseinheit 1715 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Vorverarbeitungseinheit 1715 verwaltet einen oder mehrere Ströme, liest Befehle aus den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 1700 weiter.
Die Vorverarbeitungseinheit 1715 ist mit einer Scheduler-Einheit 1720 gekoppelt, die die verschiedenen GPCs 1750 so konfiguriert, dass sie Aufgaben bzw. Tasks bearbeiten, die durch die ein oder mehreren Ströme definiert sind. Die Scheduler-Einheit 1720 ist so konfiguriert, dass sie Statusinformationen zu den verschiedenen Aufgaben verfolgt, die von der Scheduler-Einheit 1720 verwaltet werden. Der Status kann anzeigen, welchem GPC 1750 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, einen der Aufgabe zugewiesenen Prioritätsgrad und so weiter. Die Scheduler-Einheit 1720 verwaltet die Ausführung einer Vielzahl von Aufgaben auf den ein oder mehreren GPCs 1750.
Die Scheduler-Einheit 1720 ist mit einer Arbeitsverteilungseinheit 1725 gekoppelt, die so konfiguriert ist, dass sie Aufgaben zur Ausführung auf den GPCs 1750 abfertigt. Die Arbeitsverteilungseinheit 1725 kann eine Anzahl von geplanten Aufgaben verfolgen, die von der Scheduler-Einheit 1720 empfangen wurden. In einer Ausführungsform verwaltet die Arbeitsverteilungseinheit 1725 für jeden der GPCs 1750 einen Pool von anstehenden Aufgaben und einen Pool von aktiven Aufgaben. Der Pool von anstehenden Aufgaben kann eine Anzahl von Slots (z. B. 32 Slots) umfassen, die Aufgaben enthalten, die von einem bestimmten GPC 1750 zu bearbeiten sind. Der Pool von aktiven Aufgaben kann eine Anzahl von Slots (z. B. 4 Slots) für Aufgaben umfassen, die gerade von den GPCs 1750 aktiv bearbeitet werden. Wenn ein GPC 1750 die Ausführung einer Aufgabe beendet, wird diese Aufgabe aus dem Pool von aktiven Aufgaben für den GPC 1750 entfernt, und es wird eine der anderen Aufgaben aus dem Pool von anstehenden Aufgaben ausgewählt und für Ausführung auf dem GPC 1750 eingeplant. Wenn eine aktive Aufgabe auf dem GPC 1750 untätig war, z. B. während des Wartens auf Auflösung einer Datenabhängigkeit, kann die aktive Aufgabe aus dem GPC 1750 entfernt und an den Pool von anstehenden Aufgaben zurückgegeben werden, während eine andere Aufgabe im Pool von anstehenden Aufgaben ausgewählt und für Ausführung auf dem GPC 1750 eingeplant wird.
Die Arbeitsverteilungseinheit 1725 kommuniziert über das XBar 1770 mit einem oder mehreren GPCs 1750. Das XBar 1770 ist ein Verbindungsnetz, das viele Einheiten der PPU 1700 mit anderen Einheiten der PPU 1700 koppelt. Zum Beispiel kann das XBar 1770 so konfiguriert sein, dass es die Arbeitsverteilungseinheit 1725 mit einem bestimmten GPC 1750 koppelt. Obwohl nicht explizit gezeigt, können eine oder mehrere andere Einheiten der PPU 1700 auch über den Hub 1770 mit dem XBar 1770 verbunden sein.
Die Aufgaben werden von der Scheduler-Einheit 1720 verwaltet und von der Arbeitsverteilungseinheit 1725 an ein GPC 1750 abgefertigt. Der GPC 1750 ist so konfiguriert, dass er die Aufgabe bearbeitet und Ergebnisse erzeugt. Die Ergebnisse können von anderen Aufgaben innerhalb des GPC 1750 verbraucht, über das XBar 1770 an einen anderen GPC 1750 weitergeleitet oder im Speicher 1704 gespeichert werden. Die Ergebnisse können über die Partitionseinheiten 1780, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in den bzw. aus dem Speicher 1704 implementieren, in den Speicher 1704 geschrieben werden. Die Ergebnisse können über den NVLink 1710 an eine andere PPU 1704 oder CPU übertragen werden. In einer Ausführungsform enthält die PPU 1700 eine Anzahl U von Partitionseinheiten 1780, die der Anzahl von separaten und getrennten Speichergeräten 1704 entspricht, die mit der PPU 1700 gekoppelt sind. Eine Partitionseinheit 1780 wird im Folgenden in Verbindung mit 18 näher beschrieben.
In einer Ausführungsform führt ein Host-Prozessor einen Treiber-Kernel aus, der eine Anwendungsprogrammierschnittstelle (API) implementiert, die es einer oder mehreren auf dem Host-Prozessor ausgeführten Anwendungen ermöglicht, Operationen für Ausführung auf der PPU 1700 zu planen. In einer Ausführungsform werden mehrere Rechenanwendungen gleichzeitig von der PPU 1700 ausgeführt, und die PPU 1700 bietet Isolation, Dienstgüte (QoS, Quality of Service) und unabhängige Adressräume für die mehreren Rechenanwendungen. Eine Anwendung kann Anweisungen (d. h. API-Aufrufe) generieren, die den Treiber-Kernel veranlassen, eine oder mehrere Aufgaben für Ausführung durch die PPU 1700 zu generieren. Der Treiber-Kernel gibt Aufgaben an einen oder mehrere Ströme aus, die von der PPU 1700 bearbeitet werden. Jede Aufgabe kann eine oder mehrere Gruppen von verwandten Threads umfassen, die hier als ein Warp bezeichnet werden. In einer Ausführungsform umfasst ein Warp 32 in Bezug stehende Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Vielzahl von Threads beziehen, einschließlich Anweisungen zur Durchführung der Aufgabe und dass Daten über Gemeinschaftsspeicher ausgetauscht werden können. Threads und kooperierende Threads werden in Verbindung mit 20 näher beschrieben.
19 veranschaulicht einen GPC 1750 der PPU 1700 von 17 gemäß einer Ausführungsform. Wie in 19 gezeigt, enthält jeder GPC 1750 eine Anzahl von Hardware-Einheiten zur Bearbeitung von Aufgaben. In einer Ausführungsform enthält jeder GPC 1750 einen Pipeline-Manager 1810, eine Pre-Rasteroperationseinheit (PROP) 1815, eine Raster-Engine 1825, ein Arbeitsverteilungs-Koppelfeld (WDX) 1880, eine Speicherverwaltungs-Einheit (MMU) 1890 und einen oder mehrere Datenverarbeitungs-Cluster (DPCs) 1820. Man beachte, dass der GPC 1750 von 19 anstelle der oder zusätzlich zu den in 19 gezeigten Einheiten andere Hardware-Einheiten enthalten kann.
In einer Ausführungsform wird der Betrieb des GPC 1750 durch den Pipeline-Manager 1810 gesteuert. Der Pipeline-Manager 1810 verwaltet die Konfiguration der ein oder mehreren DPCs 1820 für Bearbeitung von Aufgaben, die dem GPC 1750 zugewiesen sind. In einer Ausführungsform kann der Pipeline-Manager 1810 mindestens einen der ein oder mehreren DPCs 1820 so konfigurieren, dass er mindestens einen Teil einer Grafik-Render-Pipeline implementiert. Zum Beispiel kann ein DPC 1820 so konfiguriert sein, dass er ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 1840 ausführt. Der Pipeline-Manager 1810 kann auch so konfiguriert sein, dass er von der Arbeitsverteilungseinheit 1725 empfangene Pakete an die entsprechenden Logikeinheiten innerhalb des GPC 1750 weiterleitet. Zum Beispiel können manche Pakete an Hardware-Einheiten mit fester Funktion in der PROP 1815 und/oder der Raster-Engine 1825 weitergeleitet werden, während andere Pakete an die DPCs 1820 zur Verarbeitung durch die Primitiv-Engine 1835 oder den SM 1840 weitergeleitet werden können. In einer Ausführungsform kann der Pipeline-Manager 1810 mindestens einen der ein oder mehreren DPCs 1820 so konfigurieren, dass er ein Modell für ein neuronales Netz und/oder eine Rechen-Pipeline implementiert.
Die PROP-Einheit 1815 ist so konfiguriert, dass sie von der Raster-Engine 1825 und den DPCs 1820 erzeugte Daten an eine Rasteroperations-(ROP)-Einheit weiterleitet, die in Verbindung mit 18 näher beschrieben wird. Die PROP-Einheit 1815 kann auch so konfiguriert sein, dass sie Optimierungen für Farbmischung durchführt, Pixeldaten organisiert, Adressenübersetzungen durchführt und dergleichen.
Die Raster-Engine 1825 enthält eine Anzahl von Hardware-Einheiten mit fester Funktion, die so konfiguriert sind, dass sie verschiedene Rasteroperationen durchführen können. In einer Ausführungsform enthält die Raster-Engine 1825 eine Setup-Engine, eine Grobraster-Engine, eine Culling-Engine, eine Clipping-Engine, eine Feinraster-Engine und eine Kachel-Coalescing-Engine. Die Setup-Engine empfängt transformierte Vertices und generiert Ebenengleichungen, die dem geometrischen Primitiv zugeordnet sind, das durch die Vertices definiert ist. Die Ebenengleichungen werden an die Grobraster-Engine übertragen, um Abdeckungsinformationen (z. B. eine x,y-Abdeckungsmaske für eine Kachel) für das Primitiv zu generieren. Die Ausgabe der Grobraster-Engine wird zu der Culling-Engine übertragen, wo Fragmente, die dem Primitiv zugeordnet sind, dass einen Z-Test nicht besteht, einem Culling (Auslesen) unterzogen werden, und zu einer Clipping-Engine übertragen, wo Fragmente, die außerhalb eines Betrachtungsstumpfs liegen, einem Clipping (Abschneiden) unterzogen werden. Diejenigen Fragmente, die das Clipping und Culling überleben, können an die Feinraster-Engine übergeben werden, um Attribute für die Pixelfragmente auf Basis der von der Setup-Engine generierten Ebenengleichungen zu generieren. Die Ausgabe der Raster-Engine 1825 umfasst Fragmente, die zum Beispiel von einem Fragment-Shader zu verarbeiten sind, der innerhalb eines DPC 1820 implementiert ist.
Jeder in dem GPC 1750 enthaltene DPC 1820 enthält einen M-Pipe-Controller (MPC) 1830, eine Primitiv-Engine 1835, einen oder mehrere SMs 1840, eine oder mehrere Textureinheiten 1842 und eine oder mehrere TTUs 1844. Die TTU 1844 kann ähnlich wie die oben beschriebene TTU 700 arbeiten. Der MPC 1830 steuert den Betrieb des DPC 1820 und leitet die vom Pipeline-Manager 1810 empfangenen Pakete an die entsprechenden Einheiten im DPC 1820 weiter. Zum Beispiel können Pakete, die einem Vertex zugeordnet sind, an die Primitiv-Engine 1835 weitergeleitet werden, die so konfiguriert ist, dass sie Vertex-Attribute, die dem Vertex zugeordnet sind, aus dem Speicher 1704 holt. Im Gegensatz dazu können Pakete, die einem Shader-Programm zugeordnet sind, an den SM 1840 übertragen werden.
Der SM 1840 umfasst einen programmierbaren Streaming-Prozessor, der so konfiguriert ist, dass er Aufgaben verarbeitet, die durch eine Anzahl von Threads repräsentiert werden. Jeder SM 1840 ist multi-threaded (mehrprozessfähig) und so konfiguriert, dass er eine Vielzahl von Threads (z. B. 32 Threads) aus einer bestimmten Gruppe von Threads gleichzeitig ausführen kann. In einer Ausführungsform implementiert der SM 1840 eine SIMD-(Single-Instruction, Multiple-Data)-Architektur, bei der jeder Thread in einer Gruppe von Threads (z. B. einem Warp) so konfiguriert ist, dass er einen anderen Datensatz auf Basis desselben Satzes von Anweisungen verarbeitet. Alle Threads in der Gruppe der Threads führen dieselben Anweisungen aus. In einer anderen Ausführungsform implementiert der SM 1840 eine SIMT-(Single-Instruction, Multiple-Thread)-Architektur, bei der jeder Thread in einer Gruppe von Threads so konfiguriert ist, dass er einen anderen Datensatz auf Basis desselben Satzes von Anweisungen verarbeitet, wobei jedoch einzelne Threads in der Gruppe von Threads während der Ausführung voneinander abweichen dürfen. In einer Ausführungsform werden für jeden Warp ein Programmzähler, ein Aufruf-Stapel und ein Ausführungsstatus unterhalten, was Gleichzeitigkeit zwischen Warps und serielle Ausführung innerhalb von Warps ermöglicht, wenn Threads innerhalb des Warps voneinander abweichen. In einer weiteren Ausführungsform werden für jeden einzelnen Thread ein Programmzähler, ein Aufruf-Stapel und ein Ausführungsstatus unterhalten, was gleiche Gleichzeitigkeit zwischen allen Threads, innerhalb und zwischen Warps, ermöglicht. Wenn der Ausführungsstatus für jeden einzelnen Thread aufrechterhalten wird, können Threads, die dieselben Anweisungen ausführen, konvergiert und parallel ausgeführt werden, um maximale Effizienz zu erreichen. Der SM 1840 wird im Folgenden in Verbindung mit 20 und 21 näher beschrieben.
Die MMU 1890 stellt eine Schnittstelle zwischen dem GPC 1750 und der Partitions-Einheit 1780 bereit. Die MMU 1890 kann Übersetzung von virtuellen Adressen in physische Adressen, Speicherschutz und Arbitrierung von Speicheranforderungen ermöglichen. In einer Ausführungsform stellt die MMU 1890 einen oder mehrere Übersetzungspuffer (TLBs, Translation Lookaside Buffers) bereit, um Übersetzung von virtuellen Adressen in physische Adressen im Speicher 1704 durchzuführen.
18 veranschaulicht eine Speicherpartitionseinheit 1780 der PPU 1700 von 17 gemäß einer Ausführungsform. Wie in 18 gezeigt, enthält die Speicherpartitionseinheit 1780 eine Rasteroperations-(ROP)-Einheit 1850, einen Level-2-Cache (L2-Cache) 1860 und eine Speicherschnittstelle 1870. Die Speicherschnittstelle 1870 ist mit dem Speicher 1704 gekoppelt. Die Speicherschnittstelle 1870 kann 32, 64, 128, 1024-Bit-Datenbusse oder dergleichen für Hochgeschwindigkeits-Datenübertragung implementieren. In einer Ausführungsform enthält die PPU 1700 U Speicherschnittstellen 1870, eine Speicherschnittstelle 1870 pro Paar Partitionseinheiten 1780, wobei jedes Paar Partitionseinheiten 1780 mit einem entsprechenden Speichergerät 1704 verbunden ist. Zum Beispiel kann die PPU 1700 mit bis zu Y Speichergeräten 1704 verbunden sein, wie z. B. Speicherstapel mit hoher Bandbreite oder Grafik mit Doppel-Datenrate, Version 5, Speicher mit synchronem dynamischen Direktzugriff oder anderen Arten von persistentem Speicher.
In einer Ausführungsform implementiert die Speicherschnittstelle 1870 eine HBM2-Speicherschnittstelle und entspricht U einem halben U. In einer Ausführungsform befinden sich die HBM2-Speicherstapel auf demselben physischen Gehäuse wie die PPU 1700, was im Vergleich zu herkömmlichen GDDR5-SDRAM-Systemen zu erheblichen Leistungs- und Flächeneinsparungen führt. In einer Ausführungsform enthält jeder HBM2-Stapel vier Speicher-Dies und ist Y gleich 4, wobei der HBM2-Stapel zwei 128-Bit-Kanäle pro Die für insgesamt 8 Kanäle sowie eine Datenbusbreite von 1024 Bits aufweist.
In einer Ausführungsform unterstützt der Speicher 1704 Einzelfehler korrigierenden und Doppelfehler erkennenden (SECDED) Fehlerkorrekturcode (ECC) zum Schutz von Daten. ECC bietet höhere Zuverlässigkeit für Rechenanwendungen, die empfindlich auf Datenbeschädigung reagieren. Zuverlässigkeit ist besonders wichtig in großen Cluster-Computerumgebungen, in denen PPUs 1700 sehr große Datensätze verarbeiten und/oder Anwendungen über längere Zeiträume laufen.
In einer Ausführungsform implementiert die PPU 1700 eine mehrstufige Speicherhierarchie. In einer Ausführungsform unterstützt die Speicherpartitionseinheit 1780 einen vereinheitlichten Speicher, um einen einzigen vereinheitlichten virtuellen Adressraum für Speicher der CPU und PPU 1700 bereitzustellen, der das Teilen von Daten zwischen virtuellen Speichersystemen ermöglicht. In einer Ausführungsform wird die Häufigkeit der Zugriffe einer PPU 1700 auf Speicher verfolgt, der sich auf anderen Prozessoren befindet, um sicherzustellen, dass Speicherseiten in den physischen Speicher derjenigen PPU 1700 verschoben werden, die häufiger auf die Seiten zugreift. In einer Ausführungsform unterstützt der NVLink 1710 Adressenübersetzungsdienste, die es der PPU 1700 ermöglichen, direkt auf Seitentabellen einer CPU zuzugreifen, und vollen Zugriff auf CPU-Speicher durch die PPU 1700 ermöglichen.
In einer Ausführungsform übertragen Kopier-Engines Daten zwischen mehreren PPUs 1700 oder zwischen PPUs 1700 und CPUs. Die Kopier-Engines können Seitenstörungen für Adressen erzeugen, die nicht in die Seitentabellen eingetragen sind. Die Speicherpartitionseinheit 1780 kann dann die Seitenstörungen bedienen und die Adressen in die Seitentabelle eintragen, woraufhin die Kopier-Engine die Übertragung durchführen kann. In einem herkömmlichen System ist Speicher für Mehrfach-Kopier-Engine-Operationen zwischen mehreren Prozessoren festgeheftet (d. h. nicht auslagerbar), was den verfügbaren Speicher erheblich reduziert. Bei Hardware-Seitenstörung können Adressen an die Kopier-Engines weitergegeben werden, ohne sich Sorgen zu machen, ob die Speicherseiten resident sind, und die Kopier-Operation ist transparent.
Daten aus dem Speicher 1704 oder einem anderen Systemspeicher können von der Speicherpartitionseinheit 1780 abgerufen und im L2-Cache 1860, der On-Chip (auf dem Chip) angesiedelt ist und zwischen den verschiedenen GPCs 1750 geteilt wird, gespeichert werden. Wie gezeigt, enthält jede Speicherpartitionseinheit 1780 einen Teil des L2-Cache 1860, der einem entsprechenden Speichergerät 1704 zugeordnet ist. Untergeordnete Caches können dann in verschiedenen Einheiten innerhalb der GPCs 1750 implementiert werden. Zum Beispiel kann jeder der SMs 1840 einen Level-One-Cache (L1-Cache) implementieren. Der L1-Cache ist privater Speicher, der einem bestimmten SM 1840 fest zugeordnet ist. Daten aus dem L2-Cache 1860 können abgerufen und in jedem der L1-Caches zur Verarbeitung in den Funktionseinheiten der SMs 1840 gespeichert werden. Der L2-Cache 1860 ist mit der Speicherschnittstelle 1870 und dem XBar 1770 gekoppelt.
Die ROP-Einheit 1850 führt grafische Rasteroperationen in Bezug auf Pixelfarbe durch, wie z. B. Farbkompression, Pixel-Blending und dergleichen. Die ROP-Einheit 1850 führt auch Tiefentesten in Verbindung mit der Raster-Engine 1825 durch und empfängt eine Tiefe für eine Abtast-Position, die einem Pixelfragment zugeordnet ist, von der Culling-Engine der Raster-Engine 1825. Die Tiefe wird gegen eine entsprechende Tiefe in einem Tiefenpuffer für eine dem Fragment zugeordnete Abtast-Position getestet. Wenn das Fragment den Tiefentest für die Abtast-Position besteht, aktualisiert die ROP-Einheit 1850 den Tiefenpuffer und sendet ein Ergebnis des Tiefentests an die Raster-Engine 1825. Man beachte, dass die Anzahl der Partitionseinheiten 1780 von der Anzahl der GPCs 1750 abweichen kann und daher jede ROP-Einheit 1850 mit jeder der GPCs 1750 gekoppelt sein kann. Die ROP-Einheit 1850 verfolgt die von den verschiedenen GPCs 1750 empfangenen Pakete und bestimmt, zu welchem GPC 1750 ein von der ROP-Einheit 1850 erzeugtes Ergebnis durch das XBar 1770 geleitet wird. Obwohl die ROP-Einheit 1850 in 18 innerhalb der Speicherpartitionseinheit 1780 enthalten ist, kann sich die ROP-Einheit 1850 in einer anderen Ausführungsform außerhalb der Speicherpartitionseinheit 1780 befinden. Zum Beispiel kann sich die ROP-Einheit 1850 im GPC 1750 oder einer anderen Einheit befinden.
Beispiel-Streaming-Multiprozessor
Der SM 1840 umfasst einen programmierbaren Streaming-Prozessor, der so konfiguriert ist, dass er Aufgaben verarbeitet, die durch eine Anzahl von Threads repräsentiert werden. Jeder SM 1840 ist multi-threaded (mehrprozessfähig) und so konfiguriert, dass er eine Vielzahl von Threads (z. B. 32 Threads) aus einer bestimmten Gruppe von Threads gleichzeitig ausführen kann. In einer Ausführungsform implementiert der SM 1840 eine SIMD-(Single-Instruction, Multiple-Data)-Architektur, bei der jeder Thread in einer Gruppe von Threads (z. B. einem Warp) so konfiguriert ist, dass er einen anderen Datensatz auf Basis desselben Befehlssatzes verarbeitet. Alle Threads in der Gruppe der Threads führen dieselben Anweisungen aus. In einer anderen Ausführungsform implementiert der SM 1840 eine SIMT-(Single-Instruction, Multiple-Thread)-Architektur, bei der jeder Thread in einer Gruppe von Threads so konfiguriert ist, dass er einen anderen Datensatz auf Basis desselben Befehlssatzes verarbeitet, wobei jedoch einzelne Threads in der Gruppe von Threads während der Ausführung voneinander abweichen dürfen. In einer Ausführungsform werden für jeden Warp ein Programmzähler, ein Aufruf-Stapel und ein Ausführungsstatus unterhalten, was Gleichzeitigkeit zwischen Warps und serielle Ausführung innerhalb von Warps ermöglicht, wenn Threads innerhalb des Warps voneinander abweichen. In einer weiteren Ausführungsform werden für jeden einzelnen Thread ein Programmzähler, ein Aufruf-Stapel und ein Ausführungsstatus unterhalten, was gleiche Gleichzeitigkeit zwischen allen Threads, innerhalb und zwischen Warps, ermöglicht. Wenn der Ausführungsstatus für jeden einzelnen Thread aufrechterhalten wird, können Threads, die dieselben Anweisungen ausführen, konvergiert und parallel ausgeführt werden, um maximale Effizienz zu erreichen.
20 veranschaulicht den Streaming-Multiprozessor 1840 von 19 gemäß einer Ausführungsform. Wie in 20 gezeigt, enthält der SM 1840 einen Anweisungs-Cache 1905, eine oder mehrere Scheduler-Einheiten 1910, eine Registerdatei 1920, einen oder mehrere Verarbeitungs-Rechenkerne 1950, eine oder mehrere Spezial-Funktionseinheiten (SFUs) 1952, eine oder mehrere Lade-/Speicher-Einheiten (LSUs) 1954, ein Verbindungsnetz 1980 und einen Gemeinschaftsspeicher/L1-Cache 1970.
Wie oben beschrieben, fertigt die Arbeitsverteilungseinheit 1725 Aufgaben zur Ausführung auf den GPCs 1750 der PPU 1700 ab. Die Aufgaben sind einem bestimmten DPC 1820 innerhalb eines GPC 1750 zugewiesen, und wenn die Aufgabe einem Shader-Programm zugeordnet ist, kann die Aufgabe einem SM 1840 zugewiesen werden. Die Scheduler-Einheit 1910 empfängt die Aufgaben von der Arbeitsverteilungseinheit 1725 und verwaltet die Anweisungsplanung für einen oder mehrere Thread-Blöcke, die der SM 1840 zugeordnet sind. Die Scheduler-Einheit 1910 plant Thread-Blöcke zur Ausführung als Warps von parallelen Threads ein, wobei jedem Thread-Block mindestens ein Warp zugewiesen ist. In einer Ausführungsform führt jeder Warp 32 Threads aus. Die Scheduler-Einheit 1910 kann eine Vielzahl verschiedener Thread-Blöcke verwalten, die Warps den verschiedenen Thread-Blöcken zuweisen und dann während jedes Taktzyklus Anweisungen von der Vielzahl von verschiedenen kooperativen Gruppen an die verschiedenen Funktionseinheiten (d. h. Rechenkerne 1950, SFUs 1952 und LSUs 1954) abfertigen.
Cooperative Groups ist ein Programmiermodell für die Organisation von Gruppen kommunizierender Threads, das es Entwicklern ermöglicht, die Granularität auszudrücken, mit der Threads kommunizieren, was den Ausdruck reichhaltigerer, effizienterer paralleler Zerlegungen ermöglicht. Kooperative Start-APIs unterstützen Synchronisation zwischen Thread-Blöcken für die Ausführung paralleler Algorithmen. Herkömmliche Programmiermodelle bieten ein einziges, einfaches Konstrukt zur Synchronisation kooperierender Threads: eine Barriere über alle Threads eines Thread-Blocks hinweg (d. h. die Funktion syncthreads()). Programmierer möchten jedoch oft Gruppen von Threads mit kleinerer Granularität als Thread-Blöcke definieren und innerhalb der definierten Gruppen synchronisieren, um mehr Leistung, Designflexibilität und Softwarewiederverwendung in Form von gemeinsamen gruppenweiten Funktionsschnittstellen zu ermöglichen.
Cooperative Groups ermöglicht es Programmierern, Gruppen von Threads explizit an Unterblock- (d. h. so klein wie ein einzelner Thread) und Multiblock-Granularitäten zu definieren und kollektive Operationen wie z. B. Synchronisation der Threads in einer kooperativen Gruppe durchzuführen. Das Programmiermodell unterstützt saubere Zusammensetzung über Softwaregrenzen hinweg, so dass Bibliotheken und Utility-Funktionen in ihrem lokalen Kontext sicher synchronisieren können, ohne Annahmen über Konvergenz treffen zu müssen. Cooperative Groups Primitive ermöglichen neue Muster kooperativer Parallelität, einschließlich Produzenten-Verbraucher-Parallelität, opportunistischer Parallelität und globaler Synchronisation über ein ganzes Netz von Thread-Blöcken hinweg.
Eine Abfertigungs-Einheit 1915 ist so konfiguriert, das sie Anweisungen an eine oder mehrere der Funktionseinheiten senden kann. In der Ausführungsform enthält die Scheduler-Einheit 1910 zwei Abfertigungs-Einheiten 1915, die es ermöglichen, während jedes Taktzyklus zwei verschiedene Anweisungen von derselben Warp zu senden. In alternativen Ausführungsformen kann jede Scheduler-Einheit 1910 eine einzige Abfertigungs-Einheit 1915 oder zusätzliche Abfertigungs-Einheiten 1915 enthalten.
Jeder SM 1840 enthält eine Registerdatei 1920, die einen Satz Register für die Funktionseinheiten der SM 1840 bereitstellt. In einer Ausführungsform ist die Registerdatei 1920 zwischen den einzelnen Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein bestimmter Teil der Registerdatei 1920 fest zugeordnet ist. In einer anderen Ausführungsform ist die Registerdatei 1920 zwischen den verschiedenen Warps aufgeteilt, die von dem SM 1840 ausgeführt werden. Die Registerdatei 1920 stellt temporären Speicher für Operanden bereit, die mit den Datenpfaden der Funktionseinheiten verbunden sind. 21 veranschaulicht eine Beispiel-Konfiguration der Registerdateien des SM 1840.
Jeder SM 1840 umfasst L Verarbeitungs-Rechenkerne 1950. In einer Ausführungsform enthält der SM 1840 eine große Anzahl (z. B. 128, usw.) von getrennten Verarbeitungs-Rechenkernen 1950. Jeder Rechenkern 1950 kann eine Verarbeitungseinheit mit vollständiger Pipeline, einfacher Genauigkeit, Einfachpräzision, Doppelpräzision und/oder gemischter Präzision enthalten, die eine Gleitkomma-Arithmetik-Logikeinheit und eine Ganzzahl-Arithmetik-Logikeinheit enthält. In einer Ausführungsform implementieren die Gleitkomma-Arithmetik-Logikeinheiten die Norm IEEE 754-2008 für Gleitkomma-Arithmetik. In einer Ausführungsform enthalten die Rechenkerne 1950 64 Einfachpräzision-(32-Bit)-Gleitkomma-Rechenkerne, 64 Ganzzahl-Rechenkerne, 32 Doppelpräzision-(64-Bit)-Gleitkomma-Rechenkerne und 8 Tensor-Rechenkerne.
Tensor-Rechenkerne sind dafür konfiguriert, Matrixoperationen durchzuführen, und in einer Ausführungsform sind ein oder mehrere Tensor-Rechenkerne in den Rechenkernen 1950 enthalten. Insbesondere sind die Tensor-Rechenkerne so konfiguriert, dass sie Deep-Learning-Matrixarithmetik durchführen können, wie z. B. Faltungsoperationen für Training und Inferenzierung neuronaler Netze. In einer Ausführungsform arbeitet jeder Tensor-Rechenkern auf einer 4x4-Matrix und führt eine Matrix-Multiplikations- und Akkumulationsoperation D=A×B+C durch, worin A, B, C und D 4x4-Matrizen sind.
In einer Ausführungsform sind die Matrix-Multiplikations-Eingaben A und B 16-Bit-Gleitkomma-Matrizen, während die Akkumulations-Matrizen C und D 16-Bit-Gleitkomma- oder 32-Bit-Gleitkomma-Matrizen sein können. Tensor-Rechenkerne arbeiten an 16-Bit-Gleitkomma-Eingabedaten mit 32-Bit-Gleitkomma-Akkumulation. Die 16-Bit-Gleitkomma-Multiplikation erfordert 64 Operationen und führt zu einem hochpräzisen Produkt, das dann unter Verwendung von 32-Bit-Gleitkomma-Addition mit den anderen Zwischenprodukten für eine 4x4x4-Matrix-Multiplikation akkumuliert wird. In der Praxis werden Tensor-Rechenkerne verwendet, um viel größere zweidimensionale oder höherdimensionale Matrixoperationen durchzuführen, die sich aus diesen kleineren Elementen zusammensetzen. Eine API, wie z. B. CUDA 9 C++ API, stellt spezialisierte Matrixlast-, Matrix-Multiplikation- und -Akkumulation- sowie Matrix-Speicheroperationen zur Verfügung, um Tensor-Rechenkerne von einem CUDA-C++-Programm effizient zu nutzen. Auf der CUDA-Ebene setzt die Schnittstelle auf Warp-Ebene Matrizen der Größe 16x16 voraus, die alle 32 Threads des Warps überspannen.
Jeder SM 1840 enthält auch M SFUs 1952, die spezielle Funktionen durchführen (z. B. Attributbewertung, reziproke Quadratwurzel und dergleichen). In einer Ausführungsform können die SFUs 1952 eine Baumtraversierungseinheit enthalten, die so konfiguriert ist, dass eine hierarchische Baumdatenstruktur traversiert wird. In einer Ausführungsform können die SFUs 1952 eine Textureinheit enthalten, die so konfiguriert ist, dass sie Texturabbildungs-Filteroperationen durchführt. In einer Ausführungsform sind die Textureinheiten so konfiguriert, dass sie Texturabbildungen (z. B. ein 2D-Array von Texeln) aus dem Speicher 1704 laden und die Texturabbildungen abtasten, um abgetastete Texturwerte zur Verwendung in Shader-Programmen zu erzeugen, die vom SM 1840 ausgeführt werden. In einer Ausführungsform werden die Texturabbildungen in Gemeinschaftsspeicher/L1-Cache 1970 gespeichert. Die Textureinheiten implementieren Textur-Operationen wie z. B. Filteroperationen unter Verwendung von Mip-Maps (d. h. Texturabbildungen mit unterschiedlichen Detaillierungsgraden). In einer Ausführungsform enthält jeder SM 340 zwei Textureinheiten.
Jeder SM 1840 umfasst auch N LSUs 1954, die Lade- und Speicheroperationen zwischen dem Gemeinschaftsspeicher/L1-Cache 1970 und der Registerdatei 1920 implementieren. Jeder SM 1840 enthält ein Verbindungsnetz 1980, das jede der Funktionseinheiten mit der Registerdatei 1920 und die LSU 1954 mit der Registerdatei 1920, Gemeinschaftsspeicher/ L1 Cache 1970 verbindet. In einer Ausführungsform ist das Verbindungsnetz 1980 ein Koppelfeld, das so konfiguriert sein kann, dass es irgendeine der Funktionseinheiten mit irgendeinem der Register in der Registerdatei 1920 verbindet und die LSUs 1954 mit der Registerdatei und Speicherstellen im Gemeinschaftsspeicher/L1-Cache 1970 verbindet.
Der Gemeinschaftsspeicher/L1 Cache 1970 ist ein Array von On-Chip-Speicher, das Datenspeicherung und Kommunikation zwischen dem SM 1840 und der Primitiv-Engine 1835 sowie zwischen Threads im SM 1840 ermöglicht. In einer Ausführungsform umfasst der Gemeinschaftsspeicher/L1-Cache 1970 128KB Speicherkapazität und befindet sich in dem Pfad vom SM 1840 zur Partitionseinheit 1780. Mit dem Gemeinschaftsspeicher/L1-Cache 1970 können Lese- und Schreibzugriffe zwischengespeichert werden. Einer oder mehrere von dem Gemeinschaftsspeicher/L1-Cache 1970, L2-Cache 1860 und Speicher 1704 sind Backup-Speicher.
Die Kombination von Daten-Cache und Gemeinschaftsspeicher-Funktionalität in einem einzigen Speicherblock bietet die beste Gesamtleistung für beide Arten von Speicherzugriffen. Die Kapazität ist als ein Cache von Programmen nutzbar, die keinen Gemeinschaftsspeicher verwenden. Wenn zum Beispiel Gemeinschaftsspeicher dafür konfiguriert ist, die Hälfte der Kapazität zu nutzen, können Textur- und Lade-/Speicher-Operationen die verbleibende Kapazität nutzen. Integration in den Gemeinschaftsspeicher/L1-Cache 1970 ermöglicht es dem Gemeinschaftsspeicher/L1-Cache 1970, als Hochdurchsatz-Leitung für das Streaming von Daten zu fungieren und zugleich Zugriff mit hoher Bandbreite und niedriger Latenz auf häufig wiederverwendete Daten zu ermöglichen.
21 veranschaulicht eine Beispiel-Architektur für den SM 1840. Wie in 19 gezeigt, kann der SM 1840 mit einer oder mehreren Textureinheiten 1842 und/oder einer oder mehreren TTUs 700 gekoppelt sein. Als Kompromiss zwischen Leistung und Fläche kann ein nicht einschränkendes Ausführungsbeispiel eine einzige Textureinheit 1842 und/oder eine einzige TTU 700 pro Gruppe von SMs 1840 enthalten (z. B. siehe 19). Die TTU 700 kann mit den SMs 1840 über einen TTU-Ein/Ausgabeblock in der Speicher-Eingabe-Ausgabe und mit einem L1-Cache über eine dedizierte Leseschnittstelle kommunizieren. In einem Ausführungsbeispiel liest die TTU 700 nur aus dem Hauptspeicher und schreibt nicht in den Hauptspeicher.
Detailliertere Beispiel-TTU-Architektur
Wie oben erörtert, kann die TTU 700 ein Koprozessor zum SM 1840 sein. Wie ein Texturprozessor wird sie über eine Anzahl von SM-Befehlen zugänglich gemacht, greift auf Speicher als ein Nur-Lese-Client des L1-Cache zu und gibt Ergebnisse in die SM-Registerdatei zurück. Im Gegensatz zu manchen Texturprozessoren macht es die Datenmenge, die für eine typische Abfrage in die TTU 700 ein- und daraus ausgelagert werden muss, in manchen Ausführungsformen schwierig, sämtliche Quellen- und Zielregister in einer einzigen Anweisung zu spezifizieren (und da die meisten dieser Daten Pro-Thread-eindeutig sind, gibt es kein TTU-Analogon von Texturköpfen und Abtastern). Infolgedessen wird die TTU 700 in manchen Ausführungsformen über eine Multi-Anweisungs-Sequenz programmiert. Diese Sequenz kann in manchen Implementierungen als eine einzelne „Makro-Anweisung“ konzipiert werden.
Und ebenso wie Textureinheiten 1842 kann sich die TTU 700 in manchen Implementierungen auf bestimmte Nur-Lese-Datenstrukturen im Speicher stützen, die mit Software vorgefüllt sind. Diese umfassen:

- Ein oder mehrere BVHs, wobei jede BVH zum Beispiel ein Baum von achsenausgerichteten Begrenzungskästen ist, die in einem komprimierten Format gespeichert sind, das den Speicherverkehr im Vergleich zu einer unkomprimierten Darstellung stark reduziert. Jeder Knoten in der BVH wird als eine Complet-Struktur gespeichert, wobei Größe und Ausrichtung in manchen Implementierungen an die einer L1-Cache-Zeile angepasst sind. Kind-Complets eines gegebenen Elternteils werden vorzugsweise zusammenhängend in Speicher gespeichert, und Kind-Zeiger werden in komprimierter Form gespeichert.
- Null oder mehr Instanzknoten, die eine Möglichkeit bieten, ein Blatt einer BVH mit der Wurzel einer anderen zu verbinden. Ein Instanzknoten kann eine Datenstruktur sein, die ebenfalls ausgerichtet ist. Diese Struktur kann einen Zeiger auf die Sub-BVH, Flags, die das Backface-Culling-Verhalten in der Sub-BVH beeinflussen, und eine Matrix enthalten, die den ersten drei Zeilen einer beliebigen Transformationsmatrix (in homogenen Koordinaten) von dem Koordinatensystem der Top-Level-BVH (gewöhnlich „Welt-Raum“) zu dem der Sub-BVH (gewöhnlich „Objekt-Raum“) entspricht. Die letzte Zeile der Matrix in manchen Ausführungsformen ist in manchen Implementierungen implizit (0, 0, 0, 1).
- Null oder mehr Dreieck- oder andere Primitiv-Puffer, die zum Beispiel Dreiecke enthalten, die entweder als ein Triplett von Koordinaten pro Vertex oder in einem verlustfrei komprimierten Format gespeichert sind, das von der TTU 700 verstanden wird. Zusätzlich kann pro Dreieck oder anderem Primitiv ein Alpha-Bit bereitgestellt werden, das Dreiecke anzeigt, die besondere Behandlung durch die Software erfordern, um zu bestimmen, ob das Dreieck tatsächlich von einem gegebenen Strahl geschnitten wird. Dreieck-Puffer können in Blöcken organisiert sein. Es kann auch ein Erzwinge-kein-Culling-Funktionsbit pro Dreieck geben. Wenn dieses Bit gesetzt ist, zeigt es an, dass beide Seiten des Dreiecks in Bezug auf Culling als nach vorne oder nach hinten weisend zu behandeln sind, d. h. das Dreieck ist nicht auszusondern, weil der Strahl die „Rückseite“ statt der „Vorderseite“ schneidet. Der einfachste Anwendungsfall dafür ist ein einzelnes Dreieck, das ein Blatt darstellt, wobei wir das Blatt noch sehen können, wenn der Strahl es auf der Rückseite trifft.

Die TTU 700 ist in manchen Ausführungsformen statuslos, was bedeutet, dass zwischen Abfragen kein Architekturstatus in der TTU aufrechterhalten wird. Gleichzeitig ist es oft sinnvoll, dass Software, die auf dem SM 1840 läuft, Fortsetzung einer früheren Abfrage anfordert, was bedeutet, dass der relevante Status von der TTU 700 in Register zu schreiben und dann in Registern (oft vor Ort) an die TTU zurückzugeben ist, um fortzufahren. Dieser Status kann die Form eines Traversierungsstapels annehmen, der den Fortschritt beim Traversieren der BVH verfolgt.
Es kann auch eine kleine Anzahl von Stapel-Initialisierern vorgesehen werden, um eine neue Abfrage eines gegebenen Typs zu beginnen, zum Beispiel:

• Traversierung startend von einem Complet
• Schnittpunkt eines Strahls mit einem Bereich von Dreiecken
• Schnittpunkt eines Strahls mit einem Bereich von Dreiecken, gefolgt von einer Traversierung, die von einem Complet startet
• Vertex-Abruf aus einem Dreieck-Puffer für ein gegebenes Dreieck
• Optionale Unterstützung für Instanztransformationen vor dem „Traversierung startend von einem Complet“ und „Schnittpunkt eines Strahls mit einem Bereich von Dreiecken“.

Vertex-Abruf ist eine einfache Abfrage, die mit Anforderungsdaten spezifiziert werden kann, die aus einem Stapelinitialisierer und sonst nichts besteht. Andere Abfragetypen können die Spezifikation eines Strahls oder Strahlenbündels erfordern, zusammen mit dem Stapel oder Stapelinitialisierer und verschiedenen Strahl-Flags, die Details der Abfrage beschreiben. Ein Strahl ist durch seinen Drei-Koordinaten-Ursprung, die Drei-Koordinaten-Richtung sowie Minimal- und Maximalwerte für den t-Parameter entlang des Strahls gegeben. Ein Strahlenbündel ist zusätzlich durch einen zweiten Ursprung und eine zweite Richtung gegeben.
Es können verschiedene Strahl-Flags verwendet werden, um verschiedene Aspekte des Traversierungsverhaltens, des Backface-Culling und der Behandlung der verschiedenen Kind-Knoten-Typen zu steuern, abhängig vom Bestehen/Nichtbestehen-Status eines optionalen RayOp-Tests. RayOps fügen den Fähigkeiten der TTU Flexibilität hinzu. In manchen Ausführungsbeispielen führt der RayOps-Teil zwei Strahl-Flag-Versionen ein, die auf Basis einer spezifizierten Operation an Daten, die mit dem Strahl übertragen werden, und Daten, die im Complet gespeichert sind, dynamisch ausgewählt werden können. Um solche Flags zu erkunden, ist es zunächst hilfreich, die verschiedenen Typen von Kind-Knoten zu verstehen, die innerhalb einer BVH erlaubt sind, sowie die verschiedenen Treffertypen, die die TTU 700 an den SM zurückgeben kann. Beispiel-Knoten-Typen sind:

■ Ein Kind-Complet (d. h. ein interner Knoten) Standardmäßig setzt die TTU 700 die Traversierung fort, indem sie in die Kind-Complets absteigt.
■ Ein Dreieck-Bereich, der einem zusammenhängenden Satz von Dreiecken innerhalb eines Dreieck-Puffers entspricht.
1. (1) Standardmäßig werden Dreieck-Bereiche, auf die ein Strahl trifft, von der TTU 700 nativ behandelt, indem die Dreiecke auf Schnittpunkte getestet und der Strahl entsprechend verkürzt wird. Wenn die Traversierung abgeschlossen ist und ein Dreieck getroffen worden ist, wird standardmäßig die Dreieck-ID zusammen mit dem t-Wert und baryzentrischen Koordinaten des Schnittpunkts an den SM 1840 zurückgegeben. Dies ist der Treffertyp „Dreieck“.
2. (2) Standardmäßig werden geschnittene Dreiecke mit dem Alpha-Bit-Set an den SM 1840 zurückgegeben, auch wenn die Traversierung noch nicht abgeschlossen ist. Der zurückgegebene Traversierungsstapel enthält den Status, der erforderlich ist, um die Traversierung fortzusetzen, wenn die Software bestimmt, dass das Dreieck tatsächlich transparent war.
3. (3) Dreieck-Schnittpunkte in manchen Ausführungsformen werden für Strahlenbündel nicht unterstützt, so dass getroffene Dreieck-Bereiche standardmäßig an den SM 1840 als Treffertyp „TriRange“ oder „DreiBereich“ zurückgegeben werden, der einen Zeiger auf den ersten Dreieck-Block, der den Bereich überlappt, Parameter, die den Bereich spezifizieren, und den t-Wert des Schnittpunkts mit dem BlattBegrenzungskasten enthält.
■ Ein Element-Bereich, bestehend aus einem Index (abgeleitet von einer vom Benutzer bereitgestellten „Element-Bereich-Basis“, die im Complet gespeichert ist) und einer Zählung von Elementen.

Standardmäßig werden Element-Bereiche als Treffertyp „ItemRange“ oder „ElementBereich“ an den SM 1840 zurückgegeben, bestehend aus z. B. einem Index, einer Zählung und dem t-Wert des Schnittpunkts mit dem Blatt-Beg renzu ngskasten.
■ Ein Instanzknoten.
Die TTU 700 kann in manchen Ausführungsformen eine Instanzierungsebene nativ bearbeiten, indem sie den Strahl in das Koordinatensystem der Instanz-BVH transformiert. Zusätzliche Instanzierungsebenen (oder jede andere Instanzierungsebene, je nach Strategie) können in der Software behandelt werden. Zu diesem Zweck wird der Treffertyp „InstanceNode“ oder „InstanzKnoten“ bereitgestellt, der aus einem Zeiger auf den Instanzknoten und dem t-Wert des Schnittpunkts mit dem Blattbegrenzungskasten besteht. In anderen Implementierungen kann die Hardware zwei, drei oder mehr Instanzierungsebenen verarbeiten.
Zusätzlich zu den knotenspezifischen Treffertypen wird ein generischer „NodeRef“-Treffertyp bereitgestellt, der aus einem Zeiger auf das Eltern-Element selbst, sowie einer ID, die angibt, welches Kind geschnitten worden ist, und dem t-Wert des Schnittpunkts mit dem Begrenzungskasten dieses Kindes besteht.
Ein Treffertyp „Fehler“ kann für Fälle vorgesehen werden, in denen die Abfrage oder der BVH unsachgemäß gebildet worden ist oder wenn die Traversierung während der Traversierung Problemen begegnet ist.
Für den Fall, dass der Strahl oder das Strahlenbündel die gesamte Geometrie in der Szene verfehlt, kann ein „Kein“-Treffer-Typ vorgesehen werden.
Wie die TTU mit jedem der vier möglichen Knoten-Typen umgeht, wird durch einen Satz von knotenspezifischen Modus-Flags bestimmt, die als Teil der Abfrage für einen bestimmten Strahl gesetzt werden. Das oben erwähnte „Vorgabe“-Verhalten entspricht dem Fall, dass die Modus-Flags auf alle Nullen gesetzt sind.
Alternative Werte für die Flags ermöglichen es, alle Knoten eines bestimmten Typs einem Culling zu unterziehen, Knoten eines bestimmten Typs als Treffertyp NodeRef („KnotenVerweis“) an den SM zurückzugeben oder Dreieck-Bereiche oder Instanzknoten unter Verwendung ihrer entsprechenden Treffertypen an den SM zurückzugeben, statt sie nativ innerhalb der TTU 700 zu verarbeiten.
Zusätzliche Modus-Flags können für die Steuerung der Behandlung von Alpha-Dreiecken vorgesehen werden.
Bei Konfiguration für Universal-Parallelberechnung kann eine einfachere Konfiguration im Vergleich zu Grafikverarbeitung verwendet werden. Insbesondere werden die in 17 gezeigten Grafikverarbeitungseinheiten mit fester Funktion umgangen, wodurch ein viel einfacheres Programmiermodell entsteht. In der Universal-Parallelberechnungs-Konfiguration weist die Arbeitsverteilungseinheit 1725 Thread-Blöcke direkt den DPCs 1820 zu und verteilt sie darauf. Die Threads in einem Block führen das gleiche Programm aus, wobei eine eindeutige Thread-ID bei der Berechnung verwendet wird, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, wobei der SM 1840 verwendet wird, um das Programm auszuführen und Berechnungen durchzuführen, der Gemeinschaftsspeicher/L1-Cache 1970, um zwischen Threads zu kommunizieren, und die LSU 1954, um über den Gemeinschaftsspeicher/L1-Cache 1970 und die Speicherpartitionseinheit 1780 globalen Speicher zu lesen und darin zu schreiben. Bei Konfiguration für Universal-Parallelberechnung kann der SM 1840 auch Befehle schreiben, mit denen die Scheduler-Einheit 1720 neue Arbeit auf den DPCs 1820 starten kann. Die TTU 700 kann verwendet werden, um räumliche Abfragen im Kontext der Universal-Parallelberechnung zu beschleunigen.
Die PPU 1700 kann in einem Desktop-Computer, einem Laptop-Computer, einem Tablet-Computer, Servern, Supercomputern, einem Smartphone (z. B. einem drahtlosen, tragbaren Gerät), einem Personal Digital Assistant (PDA), einer Digitalkamera, einem Fahrzeug, einem am Kopf befestigten Display, einem tragbaren elektronischen Gerät und dergleichen enthalten sein. In einer Ausführungsform ist die PPU 1700 auf einem einzelnen Halbleitersubstrat ausgebildet. In einer anderen Ausführungsform ist die PPU 1700 zusammen mit einem oder mehreren anderen Geräten, wie z. B. zusätzlichen PPUs 1700, dem Speicher 1704, einer CPU für Computer mit reduziertem Befehlssatz (RISC), einer Speicherverwaltungseinheit (MMU), einem Digital-Analog-Wandler (DAC) und dergleichen in einem SoC (System-on-a-Chip, System auf einem Chip) enthalten.
In einer Ausführungsform kann die PPU 1700 auf einer Grafikkarte enthalten sein, die ein oder mehrere Speichergeräte 1704 enthält. Die Grafikkarte kann so konfiguriert sein, dass sie eine Schnittstellenverbindung mit einem PCIe-Steckplatz auf einem Motherboard eines Desktop-Computers herstellt. In noch einer Ausführungsform kann die PPU 1700 eine integrierte Grafikverarbeitungseinheit (iGPU) oder ein Parallelprozessor sein, die bzw. der im Chipsatz des Motherboards enthalten ist.
Beispiel-Rechensystem
Systeme mit mehreren GPUs und CPUs werden in mannigfachen Branchen eingesetzt, da Entwickler mehr Parallelität bei Anwendungen wie z. B. künstlicher Intelligenz enthüllen und nutzen. Leistungsstarke GPU-beschleunigte Systeme mit Zehntausenden von Rechenknoten werden in Rechenzentren, Forschungseinrichtungen und Supercomputern eingesetzt, um immer größere Probleme zu lösen. Mit zunehmender Anzahl von Verarbeitungsgeräten innerhalb der Hochleistungssysteme müssen die Kommunikations- und Datenübertragungsmechanismen skaliert werden, um die erhöhte Bandübertragung zwischen den Verarbeitungsgeräten zu unterstützen.
22 ist ein Konzeptdiagramm eines unter Verwendung der PPU 1700 von 17 implementierten Verarbeitungssystems 2000 gemäß einer Ausführungsform. Das Beispiel-System 2000 kann so konfiguriert sein, dass es eines oder mehrere der in dieser Anmeldung offenbarten Verfahren implementiert. Das Verarbeitungssystem 2000 enthält eine CPU 1930, einen Switch 1910 und jeweils mehrere PPUs 1700 und entsprechende Speicher 1704. Der NVLink 1710 stellt Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 1700 bereit. Obwohl in 22 eine bestimmte Anzahl von Verbindungen mittels NVLink 1710 und Verbindung 1702 gezeigt ist, kann die Anzahl der Verbindungen zu jeder PPU 1700 und der CPU 1930 variieren. Der Switch 1910 bildet eine Schnittstelle zwischen der Verbindung 1702 und der CPU 1930. Die PPUs 1700, der Speicher 1704 und die NVLinks 1710 können sich auf einer einzelnen Halbleiterplattform befinden, um ein Parallelverarbeitungsmodul 1925 zu bilden. In einer Ausführungsform unterstützt der Switch 1910 zwei oder mehr Protokolle zur Schnittstellenbildung zwischen verschiedenen unterschiedlichen Verbindungen und/oder Links.
In einer weiteren Ausführungsform (nicht gezeigt) stellt der NVLink 1710 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 1700 und der CPU 1930 bereit, und der Switch 1910 bildet Schnittstellen zwischen der Verbindung 1702 und jeder der PPUs 1700. Die PPUs 1700, die Speicher 1704 und die Verbindung 1702 können sich auf einer einzelnen Halbleiterplattform befinden, um ein Parallelverarbeitungsmodul 1925 zu bilden. In noch einer Ausführungsform (nicht gezeigt) stellt die Verbindung 1702 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 1700 und der CPU 1930 bereit, und der Switch 1910 bildet Schnittstellen zwischen jeder der PPUs 1700 unter Verwendung des NVLinks 1710, um eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den PPUs 1700 bereitzustellen. In noch einer Ausführungsform (nicht gezeigt) stellt der NVLink 1710 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den PPUs 1700 und der CPU 1930 über den Switch 1910 bereit. In noch einer Ausführungsform (nicht gezeigt) stellt die Verbindung 1702 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 1700 direkt bereit. Eine oder mehrere der Hochgeschwindigkeits-Kommunikationsverbindungen NVLink 1710 können als physische NVLink-Verbindung oder als On-Chip- oder On-Die-Verbindung unter Verwendung des gleichen Protokolls wie der NVLink 1710 implementiert werden.
Im Kontext der vorliegenden Beschreibung kann sich eine einzelne Halbleiterplattform auf eine einzige einheitliche halbleiterbasierte integrierte Schaltung beziehen, die auf einem Die oder Chip hergestellt wird. Man beachte, dass sich der Begriff einzelne Halbleiterplattform auch auf Multichip-Module mit erhöhter Konnektivität beziehen kann, die On-Chip-Betrieb simulieren und wesentliche Verbesserungen gegenüber herkömmlicher Bus-Implementierung vornehmen. Natürlich können die verschiedenen Schaltungen oder Geräte nach den Wünschen des Benutzers auch getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen angeordnet sein. Alternativ kann das Parallelverarbeitungsmodul 1925 als ein Leiterplattensubstrat implementiert sein und kann jede(r) der PPUs 1700 und/oder Speicher 1704 als gepacktes Gerät ausgeführt sein. In einer Ausführungsform befinden sich die CPU 1930, der Switch 1910 und das Parallelverarbeitungsmodul 1925 auf einer einzelnen Halbleiterplattform.
In einer Ausführungsform beträgt die Signalübertragungsrate jedes NVLink 1710 20 bis 25 Gigabit/Sekunde und enthält jede PPU 1700 sechs NVLink 1710 Schnittstellen (wie in 22 gezeigt, sind fünf NVLink 1710 Schnittstellen für jede PPU 1700 enthalten). Jeder NVLink 1710 bietet eine Datenübertragungsrate von 25 Gigabyte/Sekunde in jede Richtung, wobei sechs Links 1700 Gigabyte/Sekunde liefern. Die NVLinks 1710 werden möglicherweise ausschließlich für PPU-zu-PPU-Kommunikation verwendet, wie in 22 gezeigt, oder für irgendeine Kombination von PPU-zu-PPU und PPU-zu-CPU, wenn die CPU 1930 ebenfalls eine oder mehrere NVLink 1710 Schnittstellen enthält.
In einer Ausführungsform ermöglicht der NVLink 1710 direkten Lade-/Speicher-/atomischen Zugriff von der CPU 1930 auf den Speicher 1704 jeder PPU 1700. In einer Ausführungsform unterstützt der NVLink 1710 Kohärenz-Operationen, so dass aus den Speichern 1704 gelesene Daten in der Cache-Hierarchie der CPU 1930 gespeichert werden können, was die Cache-Zugriffslatenz für die CPU 1930 reduziert. In einer Ausführungsform enthält der NVLink 1710 Unterstützung für Adressenübersetzungsdienste (ATS), so dass die PPU 1700 direkt auf Seitentabellen innerhalb der CPU 1930 zugreifen kann. Einer oder mehrere der NVLinks 1710 können auch für Betrieb in einem Niedrigverbrauchsmodus konfiguriert sein.
23 veranschaulicht ein Beispiel-System 1965, in dem die verschiedene Architektur und/oder Funktionalität der verschiedenen früheren Ausführungsformen implementiert sein kann. Das Beispiel-System 1965 kann so konfiguriert sein, dass es eines oder mehrere der in dieser Anmeldung offenbarten Verfahren 250 implementiert.
Wie gezeigt, ist ein System 1965 vorgesehen, das mindestens eine Zentralverarbeitungseinheit 1930 enthält, die mit einem Kommunikationsbus 1975 verbunden ist. Der Kommunikationsbus 1975 kann unter Verwendung irgendeines geeigneten Protokolls implementiert werden, wie z. B. PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), HyperTransport oder irgendeinem anderen Bus oder Punkt-zu-Punkt-Kommunikationsprotokoll(en). Das System 1965 enthält auch einen Hauptspeicher 1940. Steuerlogik (Software) und Daten werden im Hauptspeicher 1940 gespeichert, der als Direktzugriffsspeicher (RAM) ausgeführt sein kann.
Das System 1965 enthält auch Eingabegeräte 1960, das Parallelverarbeitungssystem 1925 und Display-Geräte 1945, d. h. ein herkömmliches CRT- (Kathodenstrahlröhre), LCD- (Flüssigkristallanzeige), LED-(Leuchtdioden), Plasma-Display oder dergleichen. Benutzereingaben können von den Eingabegeräten 1960 empfangen werden, z. B. einer Tastatur, einer Maus, einem Touchpad, einem Mikrofon und dergleichen. Jedes der vorgenannten Module und/oder Geräte kann sich sogar auf einer einzelnen Halbleiterplattform befinden, um das System 1965 zu bilden. Alternativ können die verschiedenen Module auch getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen nach den Wünschen des Anwenders angeordnet werden.
Weiterhin kann das System 1965 zu Kommunikationszwecken über eine Netzschnittstelle 1935 mit einem Netz (z. B. einem Telekommunikationsnetz, Lokalen Netz (LAN), Drahtlosnetz, Weitverkehrsnetz (WAN) wie z. B. das Internet, Peer-to-Peer-Netz, Kabelnetz oder dergleichen) gekoppelt sein.
Das System 1965 kann auch einen Sekundärspeicher enthalten (nicht gezeigt). Der Sekundärspeicher enthält zum Beispiel ein Festplattenlaufwerk und/oder ein Wechselspeicherlaufwerk, das ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein CD-Laufwerk, ein DVD-Laufwerk, ein Aufzeichnungsgerät oder einen USB-Flashspeicher repräsentiert. Das Wechselspeicherlaufwerk liest und/oder schreibt in einer bekannten Weise von einer bzw. auf eine Wechselspeicher-Einheit.
Computerprogramme oder Computer-Steuerlogikalgorithmen können in dem Hauptspeicher 1940 und/oder dem Sekundärspeicher gespeichert werden. Solche Computerprogramme ermöglichen es dem System 1965, verschiedene Funktionen durchzuführen, wenn sie ausgeführt werden. Der Speicher 1940, der Sekundärspeicher und/oder irgendwelche anderen Speicher sind mögliche Beispiele von computerlesbaren Medien.
Die Architektur und/oder Funktionalität der verschiedenen vorhergehenden Figuren kann im Kontext eines allgemeinen Computersystems, eines Platinensystems, eines Spielkonsolensystems für Unterhaltungszwecke, eines anwendungsspezifischen Systems und/oder irgendeines anderen gewünschten Systems implementiert werden. Das System 1965 kann zum Beispiel die Form eines Desktop-Computers, eines Laptop-Computers, eines Tablet-Computers, von Servern, Supercomputern, eines Smartphones (z. B. eines drahtlosen, tragbaren Geräts), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, eines am Kopf angebrachten Displays, eines tragbaren elektronischen Geräts, eines Mobiltelefongeräts, eines Fernsehgeräts, einer Workstation, einer Spielkonsole, eines eingebetteten Systems und/oder eines anderen Typs von Logik annehmen.
Obwohl verschiedene Ausführungsformen vorstehend beschrieben worden sind, versteht es sich, dass sie nur als Beispiel und nicht als Einschränkung präsentiert worden sind. Daher sind die Breite und der Schutzumfang einer bevorzugten Ausführungsform nicht durch irgendwelche der oben beschriebenen Ausführungsbeispiele einzuschränken, sondern nur in Übereinstimmung mit den folgenden Ansprüchen und ihren Äquivalenten zu definieren.
Grafikverarbeitungs-Pipeline
In einer Ausführungsform umfasst die PPU 1700 eine Grafikverarbeitungseinheit (GPU). Die PPU 1700 ist so konfiguriert, dass sie Befehle empfängt, die Shader-Programme zur Verarbeitung von Grafikdaten spezifizieren. Grafikdaten können als ein Satz von Primitiven definiert sein, wie z. B. Punkte, Linien, Dreiecke, Vierecke, Dreieckstreifen und dergleichen. Typischerweise enthält ein Primitiv Daten, die eine Anzahl von Vertices bzw. Eckpunkten für das Primitiv spezifizieren (z. B. in einem Modell-Raum-Koordinatensystem), sowie Attribute, die einem jedem Vertex des Primitivs zugeordnet sind. Die PPU 1700 kann so konfiguriert sein, dass sie die Grafik-Primitive verarbeitet, um einen Bildpuffer zu erzeugen (d. h. Pixeldaten für jedes Pixel des Displays).
Eine Anwendung schreibt Modelldaten für eine Szene (d. h. eine Sammlung von Vertices und Attributen) in einen Speicher, wie z. B. einen Systemspeicher oder Speicher 1704. Die Modelldaten definieren jedes der Objekte, die auf einem Display sichtbar sein können. Die Anwendung führt dann einen API-Aufruf an den Treiber-Kernel durch, der anfordert, dass die Modelldaten gerendert und angezeigt werden. Der Treiber-Kernel liest die Modelldaten und schreibt Befehle an die ein oder mehreren Ströme, um Operationen zur Verarbeitung der Modelldaten durchzuführen. Die Befehle können sich auf verschiedene Shader-Programme beziehen, die auf den SMs 1840 der PPU 1700 zu implementieren sind, einschließlich eines oder mehrerer Vertex-Shader, Hull-Shader, Domain-Shader, Geometrie-Shader, Pixel-Shader, Strahlerzeugungs-Shader, Strahlschnittpunkt-Shader, Strahltreffer-Shader und Strahlfehlschuss-Shader (diese entsprechen den durch die DXR-API definierten Shadern und ignorieren irgendeine Unterscheidung zwischen „Nächstgelegener-Treffer“ und „Irgendein-Treffer“ -Shadern; siehe https://devblogs.nvidia.com/introduction-nvidiartx-directx-ray-tracing/). Zum Beispiel kann ein oder können mehrere SMs 1840 so konfiguriert sein, dass sie ein Vertex-Shader-Programm ausführen, das eine Anzahl von Vertices verarbeitet, die durch die Modelldaten definiert sind. In einer Ausführungsform können die verschiedenen SMs 1840 so konfiguriert sein, dass sie verschiedene Shader-Programme gleichzeitig ausführen. Zum Beispiel kann eine erste Teilmenge von SMs 1840 so konfiguriert sein, dass sie ein Vertex-Shader-Programm ausführt, während eine zweite Teilmenge von SMs 1840 so konfiguriert sein kann, dass sie ein Pixel-Shader-Programm ausführt. Die erste Teilmenge von SMs 1840 verarbeitet Vertexdaten zu verarbeiteten Vertexdaten und schreibt die verarbeiteten Vertexdaten in den L2-Cache 1860 und/oder den Speicher 1704. Nachdem die verarbeiteten Vertexdaten gerastert (d. h. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum transformiert) worden sind, um Fragmentdaten zu erzeugen, führt die zweite Teilmenge von SMs 1840 einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, die dann mit anderen verarbeiteten Fragmentdaten gemischt und in den Bildpuffer im Speicher 1704 geschrieben werden. Das Vertex-Shader-Programm und das Pixel-Shader-Programm können gleichzeitig ausgeführt werden, wobei unterschiedliche Daten derselben Szene gemäß einem Pipeline-Vorgehen verarbeitet werden, bis alle Modelldaten für die Szene in den Bildpuffer gerendert worden sind. Anschließend wird der Inhalt des Bildpuffers an eine Display-Steuerung zur Anzeige auf einem Display-Gerät übertragen.
24 ist ein Konzeptdiagramm einer von der PPU 1700 von 17 implementierten Grafikverarbeitungs-Pipeline 2000 gemäß einer Ausführungsform. Die Grafikverarbeitungs-Pipeline 2000 ist ein abstraktes Flussdiagramm der zur Erzeugung von 2D-Computerbildern aus 3D-Geometriedaten implementierten Verarbeitungsschritte. Wie bekannt, können Pipeline-Architekturen Operationen mit langer Latenz effizienter durchführen, indem sie die Operation in eine Vielzahl von Stufen aufteilen, wobei der Ausgang jeder Stufe mit dem Eingang der nächstfolgenden Stufe gekoppelt ist. Somit empfängt die Grafikverarbeitungs-Pipeline 2000 Eingabedaten 2001, die von einer Stufe zur nächsten Stufe der Grafikverarbeitungs-Pipeline 2000 übertragen werden, um Ausgabedaten 2002 zu erzeugen. In einer Ausführungsform kann die Grafikverarbeitungs-Pipeline 2000 eine durch die OpenGLO-API definierte Grafikverarbeitungs-Pipeline repräsentieren. Optional kann die Grafikverarbeitungs-Pipeline 2000 im Kontext der Funktionalität und Architektur der vorherigen Figuren implementiert werden.
Wie in 24 gezeigt, weist die Grafikverarbeitungs-Pipeline 2000 eine Pipeline-Architektur auf, die eine Anzahl von Stufen umfasst. Die Stufen umfassen, sind aber nicht beschränkt auf, eine Datenaufbaustufe 2010, eine Vertex-Shading-Stufe 2020, eine Primitiv-Aufbaustufe 2030, eine Geometrie-Shading-Stufe 2040, eine Viewport Skalier-, Cull- und Clipp- (VSCC) Stufe 550, eine Rasterungsstufe 2060, eine Fragment-Shading-Stufe 2070 und eine Rasteroperationen-Stufe 2080. Die Eingabedaten 2001 umfassen in einer Ausführungsform Befehle, die die Verarbeitungseinheiten so konfigurieren, dass die Stufen der Grafikverarbeitungs-Pipeline 2000 und geometrische Primitive (z. B. Punkte, Linien, Dreiecke, Vierecke, Dreieckstreifen oder -fächer usw.), die von den Stufen zu verarbeiten sind, implementiert werden. Die Ausgabedaten 2002 können Pixeldaten (d. h. Farbdaten) umfassen, die in einen Bildpuffer oder eine andere Art von Oberflächendatenstruktur in einem Speicher kopiert werden.
Die Datenaufbaustufe 2010 empfängt die Eingabedaten 2001, die Vertexdaten für Oberflächen höherer Ordnung, Primitive oder dergleichen spezifizieren. Die Datenaufbaustufe 2010 sammelt die Vertexdaten in einem temporären Speicher oder einer Warteschlange, wie z. B. durch Empfangen eines Befehls vom Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher enthält, und Lesen der Vertexdaten aus dem Puffer. Die Vertexdaten werden dann zur Verarbeitung an die Vertex-Shading-Stufe 2020 übertragen.
Die Vertex-Shading-Stufe 2020 verarbeitet Vertexdaten, indem sie eine Reihe von Operationen (d. h. einen Vertex-Shader oder ein Programm) einmal für jeden der Vertices ausführt. Vertices können z. B. als ein 4-Koordinaten-Vektor (d. h. <x, y, z, w>) angegeben werden, der einem oder mehreren Vertex-Attributen zugeordnet ist (z. B. Farbe, Texturkoordinaten, Flächennormale, usw.). Die Vertex-Shading-Stufe 2020 kann einzelne Vertex-Attribute wie z. B. Position, Farbe, Texturkoordinaten und dergleichen handhaben. Mit anderen Worten führt die Vertex-Shading-Stufe 2020 Operationen an den Vertex-Koordinaten oder anderen Vertex-Attributen durch, die einem Vertex zugeordnet sind. Solche Operationen umfassen gewöhnlich Beleuchtungsoperationen (d. h. Modifizieren von Farbattributen für einen Vertex) und Transformationsoperationen (d. h. Modifizieren des Koordinatenraums für einen Vertex). Zum Beispiel können Vertices mit Hilfe von Koordinaten in einem Objekt-Koordinatenraum spezifiziert werden, welche durch Multiplikation der Koordinaten mit einer Matrix transformiert werden, die die Koordinaten aus dem Objekt-Koordinatenraum in einen Welt-Raum oder einen NCD-Raum (Raum mit normierten Gerätekoordinaten) übersetzt. Die Vertex-Shading-Stufe 2020 erzeugt transformierte Vertexdaten, die an die Primitiv-Aufbaustufe 2030 übertragen werden.
Die Primitiv-Aufbaustufe 2030 sammelt Vertices, die von der Vertex-Shading-Stufe 2020 ausgegeben werden, und gruppiert die Vertices zu geometrischen Primitiven für Verarbeitung durch die Geometrie-Shading-Stufe 2040. Zum Beispiel kann die Primitiv-Aufbaustufe 2030 so konfiguriert sein, dass sie immer drei aufeinanderfolgende Vertices als ein geometrisches Primitiv (d. h. ein Dreieck) für Übertragung an die Geometrie-Shading-Stufe 2040 gruppiert. In manchen Ausführungsformen können bestimmte Vertices für aufeinanderfolgende geometrische Primitive wiederverwendet werden (z. B. können zwei aufeinanderfolgende Dreiecke in einem Dreieckstreifen zwei Vertices gemeinsam benutzen). Die Primitiv-Aufbaustufe 2030 überträgt geometrische Primitive (d. h. eine Sammlung von zugehörigen Vertices) an die Geometrie-Shading-Stufe 2040.
Die Geometrie-Shading-Stufe 2040 verarbeitet geometrische Primitive, indem sie eine Reihe von Operationen (d. h. einen Geometrie-Shader oder ein Programm) an den geometrischen Primitiven ausführt. Tesselierungs-Operationen können aus jedem geometrischen Primitiv ein oder mehrere geometrische Primitive erzeugen. Mit anderen Worten kann die Geometrie-Shading-Stufe 2040 jedes geometrische Primitiv in ein feineres Maschennetz aus zwei oder mehr geometrischen Primitiven für Verarbeitung durch den Rest der Grafikverarbeitungs-Pipeline 2000 unterteilen. Die Geometrie-Shading-Stufe 2040 überträgt geometrische Primitive an die Viewport SCC Stufe 550.
In einer Ausführungsform kann die Grafikverarbeitungs-Pipeline 2000 innerhalb eines Streaming-Multiprozessors arbeiten, und die Vertex-Shading-Stufe 2020, die Primitiv-Aufbaustufe 2030, die Geometrie-Shading-Stufe 2040, die Fragment-Shading-Stufe 2070 und/oder zugehörige Hard- bzw. Software können sequentiell Verarbeitungsoperationen durchführen. Sobald die sequentiellen Verarbeitungsoperationen abgeschlossen sind, kann in einer Ausführungsform die Viewport SCC Stufe 550 die Daten verwenden. In einer Ausführungsform können von einer oder mehreren Stufen der Grafikverarbeitungs-Pipeline 2000 verarbeitete Primitiv-Daten in einen Cache geschrieben werden (z. B. L1-Cache, einen Vertex-Cache, usw.). In diesem Fall kann die Viewport SCC Stufe 550 in einer Ausführungsform auf die Daten im Cache zugreifen. In einer Ausführungsform sind die Viewport SCC Stufe 550 und die Rasterungsstufe 2060 als Schaltungen mit fester Funktion implementiert.
Die Viewport SCC Stufe 550 führt die Skalierung, das Culling und das Clipping der geometrischen Primitive durch. Jeder Oberfläche, die gerendert wird, ist eine abstrakte Kameraposition zugeordnet. Die Kameraposition stellt den Standort eines Betrachters dar, der auf die Szene schaut, und definiert einen Betrachtungsstumpf, der die Objekte der Szene umschließt. Der Betrachtungsstumpf kann eine Betrachtungsebene, eine hintere Ebene und vier Clipping-Ebenen umfassen. Jedes geometrische Primitiv, das sich vollständig außerhalb des Betrachtungsstumpfs befindet, kann einem Culling unterzogen (d. h. verworfen) werden, da das geometrische Primitiv nicht zu der endgültigen gerenderten Szene beiträgt. Irgendein geometrisches Primitiv, das sich teils innerhalb des Betrachtungsstumpfs und teils außerhalb des Betrachtungsstumpfs befindet, kann abgeschnitten werden (d. h. in ein neues geometrisches Primitiv umgewandelt werden, das innerhalb des Betrachtungsstumpfs eingeschlossen ist). Darüber hinaus können geometrische Primitive jeweils auf Basis einer Tiefe des Betrachtungsstumpfs skaliert werden. Alle potentiell sichtbaren geometrischen Primitive werden dann an die Rasterungsstufe 2060 übertragen.
Die Rasterungsstufe 2060 wandelt die geometrischen 3D-Primitive in 2D-Fragmente um (z. B. für Anzeige usw. verwendbar). Die Rasterungsstufe 2060 kann so konfiguriert sein, dass sie die Vertices der geometrischen Primitive verwendet, um einen Satz von Ebenengleichungen zu erstellen, aus denen verschiedene Attribute interpoliert werden können. Die Rasterungsstufe 2060 kann auch eine Abdeckungsmaske für eine Vielzahl von Pixeln berechnen, die angibt, ob eine oder mehrere Abtast-Positionen für das Pixel das geometrische Primitiv abschneiden. In einer Ausführungsform kann auch Z-Testen durchgeführt werden, um zu bestimmen, ob das geometrische Primitiv von anderen geometrischen Primitiven, die bereits gerastert wurden, verdeckt wird. Die Rasterungsstufe 2060 erzeugt Fragmentdaten (d. h. interpolierte Vertex-Attribute, die einer bestimmten Abtast-Position für jedes abgedeckte Pixel zugeordnet sind), die an die Fragment-Shading-Stufe 2070 übertragen werden.
Die Fragment-Shading-Stufe 2070 verarbeitet Fragmentdaten, indem sie eine Reihe von Operationen (z. B. einen Fragment-Shader oder ein Programm) an jedem der Fragmente durchführt. Die Fragment-Shading-Stufe 2070 kann Pixeldaten (d. h. Farbwerte) für das Fragment erzeugen, z. B. indem sie Beleuchtungs-Operationen oder Abtasten von Texturabbildungen unter Verwendung interpolierter Texturkoordinaten für das Fragment durchführt. Die Fragment-Shading-Stufe 2070 erzeugt Pixeldaten, die an die Rasteroperationen-Stufe 2080 übertragen werden.
Die Rasteroperationen-Stufe 2080 kann verschiedene Operationen an den Pixeldaten durchführen, wie z. B. Alpha-Tests, Schablonentests und Mischen der Pixeldaten mit anderen Pixeldaten, die anderen Fragmenten entsprechen, die dem Pixel zugeordnet sind. Wenn die Rasteroperationen-Stufe 2080 die Verarbeitung der Pixeldaten (d. h. der Ausgabedaten 2002) abgeschlossen hat, können die Pixeldaten in ein Renderziel wie z. B. einen Bildpuffer, einen Farbpuffer oder dergleichen geschrieben werden.
Man beachte, dass eine oder mehrere zusätzliche Stufen zusätzlich zu oder anstelle einer oder mehreren der oben beschriebenen Stufen in die Grafikverarbeitungs-Pipeline 2000 aufgenommen werden können. Verschiedene Implementierungen der abstrakten Grafikverarbeitungs-Pipeline können unterschiedliche Stufen implementieren. Darüber hinaus können in manchen Ausführungsformen eine oder mehrere der oben beschriebenen Stufen (wie z. B. die Geometrie-Shading-Stufe 2040) von der Grafikverarbeitungs-Pipeline ausgeschlossen sein. Andere Arten von Grafikverarbeitungs-Pipelines werden als im Schutzumfang der vorliegenden Offenbarung liegend betrachtet. Darüber hinaus kann jede der Stufen der Grafikverarbeitungs-Pipeline 2000 von einer oder mehreren dedizierten Hardware-Einheiten innerhalb eines Grafikprozessors wie z. B. der PPU 200 implementiert werden. Andere Stufen der Grafikverarbeitungs-Pipeline 2000 können durch programmierbare Hardware-Einheiten wie z. B. den SM 1840 der PPU 1700 implementiert werden.
Die Grafikverarbeitungs-Pipeline 2000 kann über eine Anwendung implementiert werden, die von einem Host-Prozessor ausgeführt wird, wie z. B. einer CPU. In einer Ausführungsform kann ein Gerätetreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, welche verschiedene Funktionen definiert, die von einer Anwendung genutzt werden können, um grafische Daten für Anzeige zu generieren. Der Gerätetreiber ist ein Softwareprogramm, das eine Vielzahl von Anweisungen enthält, die den Betrieb der PPU 1700 steuern. Die API bietet einem Programmierer eine Abstraktion, die es einem Programmierer ermöglicht, spezialisierte Grafikhardware wie z. B. die PPU 1700 zu verwenden, um die grafischen Daten zu erzeugen, ohne dass der Programmierer den spezifischen Befehlssatz für die PPU 1700 verwenden muss. Die Anwendung kann einen API-Aufruf enthalten, der an den Gerätetreiber für die PPU 1700 weitergeleitet wird. Der Gerätetreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu reagieren. In manchen Fällen kann der Gerätetreiber Operationen durchführen, indem er Anweisungen auf der CPU ausführt. In anderen Fällen kann der Gerätetreiber zumindest teilweise Operationen durchführen, indem er Operationen auf der PPU 1700 über eine Eingabe/Ausgabe-Schnittstelle zwischen der CPU und der PPU 1700 startet. In einer Ausführungsform ist der Gerätetreiber so konfiguriert, dass er die Grafikverarbeitungs-Pipeline 2000 unter Verwendung der Hardware der PPU 1700 implementiert.
Innerhalb der PPU 1700 können verschiedene Programme ausgeführt werden, um die verschiedenen Stufen der Grafikverarbeitungs-Pipeline 2000 zu implementieren. Zum Beispiel kann der Gerätetreiber einen Kernel auf der PPU 1700 starten, um die Vertex-Shading-Stufe 2020 auf einem SM 1840 (oder mehreren SMs 1840) durchzuführen. Der Gerätetreiber (oder der von der PPU 1800 ausgeführte anfängliche Kernel) kann auch andere Kernel auf der PPU 1800 starten, um andere Stufen der Grafikverarbeitungs-Pipeline 2000 auszuführen, wie z. B. die Geometrie-Shading-Stufe 2040 und die Fragment-Shading-Stufe 2070. Darüber hinaus können einige der Stufen der Grafikverarbeitungs-Pipeline 2000 auf Festeinheiten-Hardware implementiert werden, wie z. B. einem Rasterer oder einem Datenassembler, der in der PPU 1700 implementiert ist. Man beachte, dass Ergebnisse aus einem Kernel von einer oder mehreren dazwischenliegenden Hardware-Einheiten mit fester Funktion verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einem SM 1840 verarbeitet werden.
Maschinelles Lernen
Tiefe neuronale Netze (DNNs), die auf Prozessoren wie z. B. der PPU 1700 entwickelt wurden, hat man für verschiedene Anwendungsfälle eingesetzt, von selbstfahrenden Automobilen bis hin zu schnellerer Medikamentenentwicklung, von automatischer Bilderfassung in Online-Bilddatenbanken bis hin zur intelligenter Echtzeit-Sprachübersetzung in Video-Chat-Anwendungen. Deep Learning ist eine Technik, die den neuronalen Lernprozess des menschlichen Gehirns modelliert, kontinuierlich lernt, kontinuierlich intelligenter wird und im Laufe der Zeit schneller genauere Ergebnisse liefert. Ein Kind wird zunächst von einem Erwachsenen gelehrt, verschiedene Formen richtig zu identifizieren und zu klassifizieren, um schließlich ohne Nachhilfe Formen identifizieren zu können. Ähnlich muss ein System für Deep Learning oder neuronales Lernen in Objekterkennung und -klassifizierung trainiert werden, damit es intelligenter und effizienter wird, grundlegende Objekte, verdeckte Objekte usw. zu identifizieren und den Objekten auch Kontext zuzuweisen.
Auf der einfachsten Ebene betrachten Neuronen im menschlichen Gehirn verschiedene Eingaben, die empfangen werden, jedem dieser Inputs werden Wichtigkeitsstufen zugewiesen, und Ausgaben werden an andere Neuronen weitergeleitet, um darauf zu reagieren. Ein künstliches Neuron oder Perzeptron ist das grundlegendste Modell eines neuronalen Netzes. In einem Beispiel kann ein Perzeptron eine oder mehrere Eingaben empfangen, die verschiedene Merkmale eines Objekts repräsentieren, für die das Perzeptron trainiert wird, sie zu erkennen und zu klassifizieren, und jedem dieser Merkmale wird ein bestimmtes Gewicht zugewiesen, das auf der Wichtigkeit dieses Merkmals für die Definition der Form eines Objekts basiert.
Ein DNN-Modell enthält mehrere Schichten vieler verbundener Perzeptronen (z. B. Knoten), die mit enormen Mengen Eingabedaten trainiert werden können, um komplexe Probleme schnell und mit hoher Genauigkeit zu lösen. In einem Beispiel zerlegt eine erste Schicht des DNN-Modells ein Eingabebild eines Automobils in verschiedene Teile und sucht nach Grundmustern wie z. B. Linien und Winkeln. Die zweite Schicht setzt die Linien zusammen, um nach Mustern höherer Ebenen wie z. B. Rädern, Windschutzscheiben und Spiegeln zu suchen. Die nächste Schicht identifiziert den Fahrzeugtyp, und die letzten paar Schichten erzeugen ein Etikett für das Eingabebild, welches das Modell einer bestimmten Fahrzeugmarke identifiziert.
Sobald das DNN trainiert ist, kann das DNN eingesetzt und verwendet werden, um Objekte oder Muster in einem als Schlussfolgerung bekannten Prozess zu identifizieren und zu klassifizieren. Beispiele für eine Schlussfolgerung (den Prozess, durch den ein DNN nützliche Informationen aus einer gegebenen Eingabe extrahiert) umfassen das Identifizieren von handschriftlichen Zahlen auf in Geldautomaten gelegten Schecks, das Identifizieren von Bildern von Freunden auf Fotos, das Liefern von Filmempfehlungen an über fünfzig Millionen Benutzer, das Identifizieren und Klassifizieren von verschiedenen Arten von Automobilen, Fußgängern und Straßengefahren in fahrerlosen Fahrzeugen oder das Übersetzen von menschlicher Sprache in Echtzeit.
Während des Trainings fließen Daten in einer Vorwärtsfortpflanzungssphase durch das DNN, bis eine Vorhersage erzeugt wird, die ein der Eingabe entsprechendes Etikett anzeigt. Wenn das neuronale Netz die Eingabe nicht korrekt etikettiert, werden Fehler zwischen dem korrekten Etikett und dem vorhergesagten Etikett analysiert und werden die Gewichte für jedes Merkmal während einer Rückwärtsfortpflanzungssphase angepasst, bis der DNN die Eingabe und andere Eingaben in einem Trainingsdatensatz korrekt etikettiert. Das Training komplexer neuronaler Netze erfordert enorme Mengen an Parallelrechenleistung, einschließlich Gleitkomma-Multiplikationen und -Additionen, die von der PPU 1700 unterstützt werden. Schlussfolgerung ist weniger rechenintensiv als Training, da es sich um einen latenzsensitiven Prozess handelt, bei dem ein trainiertes neuronales Netz auf neue Eingaben angewendet wird, die es vorher nicht gesehen hat, um Bilder zu klassifizieren, Sprache zu übersetzen und allgemein neue Informationen zu schlussfolgern.
Neuronale Netze sind stark auf mathematische Matrix-Operationen angewiesen, und komplexe mehrschichtige Netze erfordern enorme Mengen an Gleitkommaleistung und Bandbreite für Effizienz und Geschwindigkeit. Mit Tausenden von Verarbeitungs-Rechenkernen, die für mathematische Matrix-Operationen optimiert sind und mehrere zehn bis Hunderte TFLOPS Leistung liefern, ist die PPU 1700 eine Computerplattform, die in der Lage ist, die für tiefe neuronale netzbasierte künstliche Intelligenz und Anwendungen für maschinelles Lernen erforderliche Leistung zu liefern.
Die Erfindung wurde zwar im Zusammenhang damit beschrieben, was gegenwärtig als die praktischsten und bevorzugten Ausführungsformen angesehen wird, jedoch erkennt man, dass die Erfindung nicht auf die offenbarten Ausführungsformen einzuschränken ist, sondern im Gegenteil verschiedene Modifizierungen und äquivalente Anordnungen abdecken sollen, die im Geist und Schutzumfang der beigefügten Ansprüche enthalten sind.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 14563872 [0001]
US 9582607 [0001, 0017, 0108, 0123]
US 9552664 [0001]
US 9569559 [0001, 0017]
US 10025879 [0001]
US 14737343 [0001]
US 16101066 [0001, 0114]
US 16101109 [0001]
US 16101180 [0001]
US 16101148 [0001, 0114]
US 16101196 [0001, 0114]
US 16101232 [0001]
US 20160070820 [0017]
US 20160070767 [0017]
US 14697480 [0107, 0123]

Zitierte Nicht-Patentliteratur

Foley, Van Dam, Hughes et al, Computer Graphics: Principles and Practice (2. Ausgabe Addison-Wesley 1995 & 3. Ausgabe Addison-Wesley 2014) [0008]

Claims

Verfahren zur Strahlverfolgung, umfassend: Zugreifen auf Strahldaten, die einem Strahl entsprechen, und eine Beschleunigungsdatenstruktur, die einer Szene entspricht; Traversieren der Beschleunigungsdatenstruktur in Übereinstimmung mit den Strahldaten; während des Traversierens, Durchführen eines Schnittpunkttests für mindestens einen Knoten in der Beschleunigungsdatenstruktur auf Basis von geometrischen Attributen des Strahls und der Beschleunigungsdatenstruktur und eines Hilfs-Strahloperationstests; auf Basis der Ergebnisse des Schnittpunkttests und des Hilfs-Strahloperationstests, während des Traversierens Durchführen von mindestens einem von folgendem: Ändern eines Status des Traversierens und Auswählen von Ausgabedaten, die einem oder mehreren Knoten der Beschleunigungsdatenstruktur entsprechen, die von dem Strahl geschnitten werden; und Zuführen von Ausgabedaten aus der Traversierung zu einem Render-Prozess zum Rendern von mindestens einem Teil der Szene auf ein Display.
Verfahren nach Anspruch 1, wobei das Durchführen eines Schnittpunkttests und eines Hilfs-Strahloperationstests umfasst, den Strahloperationstest auf Basis eines Opcodes in den Strahldaten auszuwählen.
Verfahren nach Anspruch 2, wobei das Durchführen eines Schnittpunkttests und eines Hilfs-Strahloperationstests weiterhin umfasst, den ausgewählten Strahloperationstest auf Basis mindestens eines Parameters jeweils aus den Strahldaten und dem mindestens einen Knoten durchzuführen.
Verfahren nach Anspruch 3, wobei der mindestens eine Parameter aus den Strahldaten pro Strahl konfigurierbar ist und der mindestens eine Parameter aus dem mindestens einen Knoten pro Knoten konfigurierbar ist.
Verfahren nach Anspruch 3 oder 4, wobei das Durchführen eines Schnittpunkttests und eines Hilfs-Strahloperationstests weiterhin umfasst, den ausgewählten Strahloperationstest auf Basis von nicht-geometrischen Attributen des Strahls und der Beschleunigungsdatenstruktur durchzuführen.
Verfahren nach einem der Ansprüche 2 bis 5, wobei das Durchführen eines Schnittpunkttests und eines Hilfs-Strahloperationstests weiterhin umfasst, den ausgewählten Strahloperationstest auf Basis eines Parameters aus dem mindestens einen Knoten und dem Opcode durchzuführen.
Verfahren nach einem der Ansprüche 2 bis 6, wobei das Durchführen von mindestens einem von dem Ändern eines Status des Traversierens und dem Auswählen von Ausgabedaten mindestens eines von folgendem umfasst: Ändern eines Status des Traversierens und Auswählen von Ausgabedaten auf Basis mindestens eines oder mehrerer in den Strahldaten spezifizierten Modus-Flags.
Verfahren nach Anspruch 7, wobei das eine oder die mehreren Modus-Flags auf Basis eines Knoten-Typs des mindestens einen Knotens ausgewählt werden.
Verfahren nach Anspruch 8, wobei das eine oder die mehreren Modus-Flags weiterhin auf Basis eines Ergebnisses des Hilfs-Strahloperationstests ausgewählt werden.
Verfahren nach einem der Ansprüche 7 bis 9, wobei das Durchführen von mindestens einem von Ändern eines Status des Traversierens und Auswählen von Ausgabedaten weiterhin umfasst, auf Basis der ein oder mehreren Modus-Flags eine Reihenfolge zu ändern, in der jeweilige Knoten in der Beschleunigungsdatenstruktur während des Traversierens traversiert werden.
Verfahren nach einem der Ansprüche 7 bis 10, wobei das Durchführen von mindestens einem von Ändern eines Status des Traversierens und Auswählen von Ausgabedaten weiterhin umfasst, auf Basis der ein oder mehreren Modus-Flags eine Struktur der Beschleunigungsdatenstruktur durch Culling eines Teils der Beschleunigungsdatenstruktur dynamisch zu ändern.
Verfahren nach einem der Ansprüche 7 bis 11, wobei das Auswählen von mindestens einem von Ändern eines Status des Traversierens und Auswählen von Ausgabedaten auf Basis eines oder mehrerer in den Strahldaten spezifizierten Modus-Flags weiterhin umfasst, in Übereinstimmung mit einem oder mehreren Übersteuer-Flags in dem mindestens einen Knoten auszuwählen.
Verfahren nach Anspruch 12, wobei der mindestens eine Knoten ein Instanzknoten ist.
Verfahren nach Anspruch 12 oder 13, wobei der mindestens eine Knoten ein Primitiv darstellt und mindestens eines der Übersteuer-Flags konfiguriert ist, um eine in den Strahldaten spezifizierte Culling-Konfiguration zu übersteuern.
Verfahren nach einem der Ansprüche 2 bis 14, wobei das Durchführen eines Schnittpunkttests für mindestens einen Knoten in der Beschleunigungsdatenstruktur auf Basis von geometrischen Attributen, die dem Strahl zugeordnet sind, und geometrischen Attributen, die der Beschleunigungsdatenstruktur zugeordnet sind, und eines Hilfs-Strahloperationstests umfasst, den Hilfs-Strahloperationstest auf Basis des Opcodes durchzuführen, wobei der Opcode es ermöglicht, einen Wert, der während des Schnittpunkttests berechnet worden ist, der durch ein dem Strahl zugeordnetes geometrisches Attribut skaliert und durch ein anderes dem Strahl zugeordnetes geometrisches Attribut vorbelastet ist, mit mindestens einem dem mindestens einen Knoten zugeordneten geometrischen Parameter zu vergleichen.
Verfahren nach einem der Ansprüche 2 bis 15, wobei das Durchführen eines Schnittpunkttests für mindestens einen Knoten in der Beschleunigungsdatenstruktur auf Basis von geometrischen Attributen des Strahls und der Beschleunigungsdatenstruktur und eines Hilfs-Strahloperationstests umfasst, den Hilfs-Strahloperationstest auf Basis des Opcodes durchzuführen, wobei der Opcode es ermöglicht, eine dem Strahl zugeordnete Entfernung mit mindestens einem Parameter des mindestens einen Knotens zu vergleichen.
Verfahren nach einem der Ansprüche 2 bis 16, wobei das Durchführen eines Schnittpunkttests für mindestens einen Knoten in der Beschleunigungsdatenstruktur auf Basis von geometrischen Attributen des Strahls und der Beschleunigungsdatenstruktur und eines Hilfs-Strahloperationstests umfasst, den Hilfs-Strahloperationstest auf Basis des Opcodes durchzuführen, wobei der Opcode es ermöglicht, einen ersten, auf mindestens einem Parameter in den Strahldaten basierenden Wert mit einem zweiten, auf mindestens einem Parameter des mindestens einen Knotens basierenden zweiten Wert zu vergleichen.
Verfahren nach einem der Ansprüche 2 bis 17, wobei das Durchführen eines Schnittpunkttests für mindestens einen Knoten in der Beschleunigungsdatenstruktur auf Basis von geometrischen Attributen des Strahls und der Beschleunigungsdatenstruktur und eines Hilfs-Strahloperationstests umfasst, den Hilfs-Strahloperationstest auf Basis des Opcodes durchzuführen, wobei der Opcode das Vergleichen einer Größe einer in dem mindestens einen Knoten dargestellten Oberfläche auf Basis mindestens eines Parameters aus dem mindestens einen Knoten mit einer Entfernung entlang des Strahls, in der ein Schnittpunkt auftritt, ermöglicht.
Verfahren nach einem der vorhergehenden Ansprüche, das weiterhin umfasst, mittels eines Parallelprozessors die Szene auf Basis mindestens eines Teils der Ausgabedaten, die von einem Traversierungs-Prozessor bereitgestellt werden, der die Traversierung ausführt, auf das Display zu rendern.
System, das einen Traversierungs-Koprozessor umfasst, der eine Hardware-Verarbeitungsschaltung zum Traversieren von Beschleunigungsdatenstrukturen umfasst, die konfiguriert ist, um: auf Strahldaten, die einem Strahl entsprechen, und eine Beschleunigungsdatenstruktur, die einer Szene entspricht, zuzugreifen; die Beschleunigungsdatenstruktur in Übereinstimmung mit den Strahldaten zu traversieren; während des Traversierens für mindestens einen Knoten in der Beschleunigungsdatenstruktur einen Schnittpunkttest auf Basis von geometrischen Attributen des Strahls und der Beschleunigungsdatenstruktur und einen Hilfs-Strahloperationstest durchzuführen; auf Basis der Ergebnisse des Schnittpunkttests und des Hilfs-Strahloperationstests während des Traversierens mindestens eines von folgendem durchzuführen: Ändern eines Status des Traversierens und Auswählen von Ausgabedaten, die einem oder mehreren Knoten der Beschleunigungsdatenstruktur entsprechen, die von dem Strahl geschnitten werden; und Ausgabedaten aus der Traversierung mindestens einem Render-Prozess zum Rendern von mindestens einem Teil der Szene auf ein Display zuzuführen.
System nach Anspruch 20, das weiterhin einen Parallelprozessor umfasst, der konfiguriert ist, um dem Strahl entsprechende Strahldaten und die einem Modell der Szene entsprechende Beschleunigungsdatenstruktur zu erzeugen.
System nach Anspruch 21, wobei die Strahldaten einen oder mehrere Strahlparameter, einen oder mehrere Opcodes und ein oder mehrere Modus-Flags umfassen, wobei der mindestens eine Knoten mindestens einen Knotenparameter enthält und wobei das System weiterhin konfiguriert ist, um: den Hilfs-Strahloperationstest durch Vergleichen von aus den ein oder mehreren Strahlparametern und dem mindestens einen Knotenparameter abgeleiteten Werten auf Basis mindestens eines der Opcodes durchzuführen; eines oder mehrere der Modus-Flags auf Basis von mindestens einem Ergebnis des Hilfstests auszuwählen; und mindestens eines von dem Ändern eines Status des Traversierens und dem Auswählen von Ausgabedaten, die einem oder mehreren Knoten der Beschleunigungsdatenstruktur entsprechen, die von dem Strahl geschnitten werden, auf Basis der ausgewählten ein oder mehreren Modus-Flags durchzuführen.
System nach einem der Ansprüche 20 bis 22, das weiterhin konfiguriert ist, um ein Verfahren gemäß einem der Ansprüche 1 bis 19 durchzuführen.
Koprozessor zum Beschleunigen von Traversierung einer Baumdatenstruktur, umfassend: eine Schnittstellenschaltung, die konfiguriert ist, um mit einem Multiprozessor und einem Speicher zu kommunizieren, um eine Vielzahl von Abfragedatenstrukturen, die Baumdatenstruktur und einen Abfragebefehl zu empfangen, wobei jede Abfragedatenstruktur Abfrage-Testparameter, einen Test-Opcode und Modus-Flags enthält und wobei ein Knoten in der Baumdatenstruktur einen Knoten-Testparameter enthält; und eine Baumtraversierungsschaltung, die konfiguriert ist, um: als Antwort auf den Abfragebefehl die Baumdatenstruktur in Übereinstimmung mit jeder der Abfragedatenstrukturen traversieren; und für jede der Abfragedatenstrukturen zu bestimmen: ein Ergebnis von Tests auf Basis des Opcodes und der Abfrage-Testparameter der jeweiligen Abfragedatenstrukturen und der Knoten-Testparameter des Knotens in der Baumdatenstruktur; und die Traversierung oder eine oder mehrere zurückgegebene Ausgaben auf Basis des Ergebnisses und der Modus-Flags der jeweiligen Abfragedatenstrukturen zu ändern.