DE102019103178A1

DE102019103178A1 - Verfahren für vorankommen und programmierbare timeouts von baumtraversierungsmechanismen in hardware

Info

Publication number: DE102019103178A1
Application number: DE102019103178.8A
Authority: DE
Inventors: Greg Muthler; Ronald Charles Babich Jr.; William Parsons Newhall Jr.; Peter Nelson; James Robertson; John Burgess
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2018-08-10
Filing date: 2019-02-08
Publication date: 2020-02-13
Also published as: CN110827388B; US20240169655A1; US11455768B2; CN110827388A; US20210090319A1; US20200051318A1; US20220392148A1; US10885698B2; US11928772B2

Abstract

In einem Strahlverfolger stellt ein Traversierungs-Koprozessor einen Präemptionsmechanismus bereit, der es Strahlen erlaubt, die Verarbeitung zu stoppen oder früh einen Timeout zu haben, um zu verhindern, dass irgendeine lang laufende Abfrage die Grafikverarbeitungseinheit hängenbleiben lässt. Die hierin beschriebenen nicht einschränkenden Implementierungsbeispiele stellen einen derartigen Präemptionsmechanismus mit einer Vorankommgarantie und zusätzliche programmierbare Timeout-Optionen, die zeit- oder zyklusbasiert sein können, bereit. Diese programmierbaren Optionen stellen ein Mittel für Dienstgüte-Timing-Garantien für Anwendungen wie z. B. virtuelle Realität (VR), die strikte Timing-Anforderungen haben, bereit.

Description

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). Konkreter 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. Insbesondere beziehen sich nicht einschränkende Implementierungsbeispiele auf Mechanismen, die es einem Prozessor ermöglichen, einen Koprozessor aus Gründen wie z. B. Präemption oder programmierbare Timeouts bei der Verarbeitung von Strahlen zu unterbrechen, und auf einen Präemptionssteuermechanismus, der sicherstellt, dass ein Koprozessor garantiert vorankommt, bevor er die Ausführung als Antwort auf eine Präemptionsanforderung beendet.
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 Kanten 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 simuliert 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 Kanten 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.
Manche Strahl-Prozesse können zu lange dauern oder müssen möglicherweise unterbrochen werden
Strahlverfolgung umfasst im Allgemeinen, eine Strahlschnittpunkt-Abfrage gegen eine vorgefertigte Beschleunigungsstruktur (AS) auszuführen, die manchmal konkreter als Begrenzungsvolumenhierarchie (BVH) bezeichnet wird. Abhängig vom Aufbau des AS, der Anzahl der Primitive in der Szene und der Orientierung eines Strahls kann die Traversierung einige hundert bis sogar tausende Zyklen mittels spezieller Traversierungs-Hardware dauern. Wenn zudem ein Zyklus oder eine Schleife unabsichtlich (oder sogar absichtlich im Falle eines schlechten Mitwirkenden) in der BVH codiert wird, ist es möglich, dass eine Traversierung unendlich wird. Zum Beispiel ist es einer BVH möglich, eine Traversierung zu definieren, die zu einer „Endlosschleife“ führt.
Um zu verhindern, dass irgendeine lang laufende Abfrage die GPU hängenbleiben lässt, stellt die Baumtraversierungseinheit (Tree Traversal Unit; TTU) 700 des Implementierungsbeispiels einen Mechanismus für Präemption bereit, der Strahlen einen frühen Timeout erlaubt. Die hierin beschriebenen nicht einschränkenden Implementierungsbeispiele stellen einen derartigen Präemptionsmechanismus mit einer Vorankommgarantie und zusätzlichen programmierbaren Timeout-Optionen, die darauf aufbauen, bereit. Diese programmierbaren Optionen stellen ein Mittel für Dienstgüte-Timing-Garantien für Anwendungen wie z. B. virtuelle Realität (VR), die strikte Timing-Anforderungen haben, bereit.
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-Schnittpunkte.
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-11H zusammen sind eine Flipchart-Animation, die eine grobe Analogie zu dem Präemptionsmechanismus der TTU mit garantiertem Vorankommen veranschaulicht.
12 zeigt einen Beispiel-Prozess, den die TTU als Antwort auf den Empfang eines Präemptionssignals durchführt.
12A zeigt ein Beispiel-Flussdiagramm eines Vorankomm-Tests.
13 ist ein Flussdiagramm eines nicht einschränkenden Beispiels einer programmierbaren TTU-Strahl-Timeout-Anordnung.
13A ist ein Flussdiagramm eines nicht einschränkenden Beispiels einer alternativen programmierbaren TTU-Strahl-Timeout-Anordnung.
14 veranschaulicht ein Beispiel-Flussdiagramm zur Erzeugung eines Bildes.
15 veranschaulicht eine Beispiel-Parallelverarbeitungseinheit (PPU).
16 veranschaulicht eine Beispiel-Speicherpartitionseinheit.
17 veranschaulicht einen Beispiel-Allgemeinverarbeitungscluster (GPC) innerhalb der Parallelverarbeitungseinheit von 15.
18 ist ein Konzeptdiagramm einer mittels des GPC von 17 implementierten Grafikverarbeitungs-Pipeline.
19 und 20 veranschaulichen einen Beispiel-Streaming-Multiprozessor.
21 ist ein Konzeptdiagramm eines unter Verwendung von PPUs von 15 implementierten Verarbeitungssystems.
22 erweitert 21, um zusätzliche miteinander verbundene Geräte zu zeigen.

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.
Die vorliegend offenbarten nicht einschränkenden 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 Mehrzahl 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 nicht einschränkenden Ausführungsbeispielen arbeitet der Traversierungs-Koprozessor 138 als ein Diener (Koprozessor) der SMs (Streaming-Multiprozessoren) 132. Mit anderen Worten, der Traversierungs-Koprozessor 138 in nicht einschränkenden Ausführungsbeispielen 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.
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 den nicht einschränkenden Ausführungsbeispielen kann der SM 132 dem Traversierungs-Koprozessor 138 befehlen, unterschiedliche Arten von Strahl-Primitiv-Schnittpunkttests durchzuführen und unterschiedliche Ergebnisse zu melden, je nach 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. 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 Strahlschnittpunkt 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 den gleichen 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.
Der 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 LO-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 Geschnittenes-opakes-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 Schnittpunkt-Informationen 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 Schnittpunkt-Informationen 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 vorgesehen werden, um die neue Abfrage von einem gegebenen Typ zu starten, 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-lnformationen 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 in der Szene 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, selbst wenn Änderungen in der Szene auftreten. 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.
Beispiel Top-Level-Baumtraversierung
Die Top-Level-Baumtraversierung 1006 durch die TTU 700 empfängt Complets von dem L1-Cache 1012 und liefert eine Instanz an die Strahl-Transformation 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.
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 Strahl-Transformation 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 nicht-instanzierte 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 nicht-instanzierten Operationen von 10C umschalten. Zum Beispiel kann ein bestimmter Abfragetyp die TTU darauf beschränken, nur die nicht-instanzierten 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 ein Begrenzungsvolumen als von dem Strahl geschnitten bestimmt wird, werden die Kind-Begrenzungsvolumina (oder Verweise darauf) des geschnittenen Begrenzungsvolumens für nachfolgendes Testen auf Schnittpunkt mit dem Strahl und für Traversierung im Auge behalten. In Ausführungsbeispielen werden eine oder mehrere Stapel-Datenstrukturen verwendet, um Kind-Begrenzungsvolumina im Auge zu behalten, die nachfolgend auf Schnittpunkt 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.
Beispiel Bottom-Level-Baumtraversierung
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.
Die Blatt-Ausgaben der Bottom-Level-Baumtraversierung 1018 werden dem Strahl/Dreieck-Schnittpunkt 1026 zugeführt (der sowohl Zugriff auf L0-Cache als auch die Fähigkeit hat, Dreiecke über den L1-Cache 1028 auszulesen). Die L0-Complet- und Dreieck-Caches können kleine Nur-Lese-Caches innerhalb der TTU 700 sein. 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.
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. mit dem Titel „Conservative Watertight Ray Triangle Intersection“ (Anwaltsakte 6610-36 (18-SC-0145)) und US-Anmeldung Nr. ______ mit dem Titel „Method for Handling Out-of-Order Opaque and Alpha Ray/Primitive Intersections“ (Anwaltsakte 6610-37 (18-AU-0149)), 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.
Der Traversierungs-Koprozessor des Implementierungsbeispiels stellt eine Struktur zur Unterbrechung und Wiederaufnahme von Traversierungs-Operationen bereit.
Wie oben beschrieben, ist die Baumtraversierungseinheit (TTU) 700 ein Strahlverfolgungs-Hardwarebeschleuniger, der eng mit dem SM 132 gekoppelt ist. Die TTU 700 arbeitet durch Verfolgen von Strahlen durch eine generierte Begrenzungsvolumenhierarchie (BVH), die interne Knoten, Instanztransformationen, Element-Bereiche und Dreieck-Bereiche umfasst. Interner-Knoten-Schnittpunkte traversieren weiter in die Hierarchie hinein. Instanzknoten-Schnittpunkte können eine hardwarebeschleunigte Instanztransformation durchführen und dann die Traversierung auf der instanzierten Kind-BVH fortsetzen. Element-Bereiche werden an den SM 132 zurückgegeben. Dreieck-Bereiche können spezielle Hardwarebeschleunigung innerhalb der TTU 700 in der Strahl-Primitiv-Test-Einheit (RPT) verwenden, um einen Schnittpunkt zwischen einem Strahl und einem bestimmten Primitiv wie z. B. einem Dreieck zu bestimmen.
Der SM 132 verfügt über einen Mechanismus für Präemption, der es ermöglicht, einen oder mehrere aktuell auf dem SM laufende Warps (z. B. Threads) pausieren zu lassen, in der Absicht, sie gegen andere Arbeit auszutauschen. Dies ist ein Mittel für Zeitscheiben-Gemeinsamnutzung des SM 132 sowie ein Mechanismus, um auf schlecht geschriebene Programme zu reagieren und Hängenbleiben zu verhindern.
Wenn der SM 132 ein Präemptionssignal empfängt oder erzeugt, wird diese Benachrichtigung auch an die TTU 700 weitergeleitet. Mit anderen Worten, der SM 132 kann selbst entscheiden, die aktuellen Aufgaben der TTU 700 zu unterbrechen, oder die GPU kann entscheiden, die aktuellen Aufgaben des SM zu unterbrechen, oder der SM kann entscheiden, Arbeit auszutauschen. In jedem Fall empfängt die TTU 700 das Präemptionssignal. Die TTU 700 stoppt dann sauber die Ausführung für alle aktiven Strahlen und gibt irgendwelche Zwischen- und/oder Endergebnisse zusammen mit Statusinformationen, die es der TTU erlauben, die Abfrage genau dort neu zu starten, wo sie aufgehört hat, wenn die Traversierung nicht abgeschlossen ist, an den SM 132 zurück.
Jeder Strahl in der TTU 700 wird unabhängig auf Basis seiner eigenen Traversierungsanforderungen arbeiten gelassen. Im Falle eines Schnittpunkts, der Intervention des SM 132 erfordert (z. B. Element-Bereiche), gibt die TTU 700 an den SM 132 einen Opak- (zu dem SM) -Datenblob zurück, der die Stapeleinträge und Metainformationen enthält, die es einer Abfrage ermöglichen, genau dort fortzufahren, wo sie aufgehört hat. Der SM 132 macht mit diesem Opak-Datenblob nichts anderes, als ihn vorübergehend zur Aufbewahrung zu speichern und ihn an die TTU 700 zurückzugeben, falls/wenn der SM 132 möchte, dass die TTU 700 die Arbeit an dieser Abfrage wiederaufnimmt. In nicht einschränkenden Implementierungsbeispielen behält der SM 132 den Opak-Blob für die TTU 700, da die TTU 700 statuslos ist - sie kann Dinge sehr schnell erledigen, kann sich aber an keinen bestimmten Job erinnern, die sie vorher erledigt hat.
Die TTU 700 ist so etwas wie ein schneller und hocheffizienter Roboter, der Aufgaben sehr schnell ausführt, sich aber nicht mehr daran erinnern kann, an welchen bestimmten Aufgaben er vorher gearbeitet hat. In den nicht einschränkenden Implementierungsbeispielen kann die TTU 700 einen Job teilweise abschließen und Ergebnisse an den SM 132 zurückgeben, so dass der SM entscheiden kann, ob die TTU an diesem Job weiterarbeiten soll - und wenn ja, ob sie bestimmte Aspekte, Teilmengen oder Erweiterungen des Jobs durchführen soll.
Teil des Kontrakts mit Software ist, dass die TTU-Abfrage nach Präemption wieder aufgenommen werden kann. Zum Beispiel gäbe es typischerweise eine äußere Schleife um die Sequenz herum - aber im Falle der TTU 700 muss es (in nicht einschränkenden Implementierungsbeispielen) eine äußere Schleife um die Sequenz herum geben. Selbst wenn es keine Alpha-Dreiecke, benutzerdefinierten Primitive oder dergleichen gibt und selbst wenn die Geometrie aus Dingen besteht, mit denen die TTU 700 umzugehen weiß, besteht wegen der Möglichkeit von Präemption immer noch eine Chance, dass die Traversierung der TTU 700 nicht abgeschlossen wird. Obwohl die TTU 700 Ergebnisse an den SM 132 zurückgibt, kann es somit in einer Folgeabfrage von dem SM an die TTU noch mehr Arbeit zu tun geben. Zumindest aus diesem Grund kann irgendeine Abfrage, die der SM 132 an die TTU 700 richtet, mehrere Anforderungen, Vollendung stattfinden zu lassen, annehmen oder beinhalten.
In dem nicht einschränkenden Implementierungsbeispiel tut die TTU 700 dies, indem sie ein Signal an die Stapelverwaltungseinheit (Stack Management Unit; SMU) 740 sendet, die für Aktivierung des nächsten Traversierungsschritts nach Vollendung des aktuellen Traversierungsschritts verantwortlich ist. Wenn das Präemptionssignal gesetzt ist, aktiviert die TTU 700 nicht den nächsten Traversierungsschritt, sondern bewirkt eine Rückgabe an den SM 132. Auf diese Weise kann jeder Strahl den Traversierungsschritt, in dem er gerade involviert ist, beenden - daher ein „sauberer Stopp“. Sobald alle Strahlen angehalten und die Ergebnisse an den SM 132 zurückgegeben worden sind, ist die Präemption abgeschlossen, und die entsprechenden Warps werden im SM ausgetauscht.
Der Streaming-Prozessor kann keine Ausnahmebehandlung durchführen, bis alle abhängigen Operationen abgeschlossen sind
Das nicht einschränkende Implementierungsbeispiel stellt einem SM 132 einen Mechanismus zur Verfügung, der selektiv das Laufen von Warps oder Threads stoppen kann, was Präemption bewirkt, so dass diese Threads gegen andere hereinkommende Arbeit ausgetauscht werden können. Dies ist also ein Weg, um den SM 132 in Zeitscheiben zu schneiden. In der Zwischenzeit wird in nicht einschränkenden Implementierungsbeispielen der SM 132 daran gehindert, einer Ausnahmebehandlung oder Präemption unterzogen zu werden, solange es noch ausstehende Arbeit gibt, die andere Teile der GPU dem SM schulden. Man kann sich darauf verlassen, dass Texturabbildung und andere hardwarebeschleunigte Prozesse innerhalb einer kurzen Zeit Ergebnisse zurückgeben. Zum Beispiel beruht die längste Latenz, die der SM 132 typischerweise sehen wird, auf einer Speicherladung. Die meisten anderen unvollendeten Prozesse, auf die der SM 132 möglicherweise wartet, um sie vor einer Ausnahmebehandlung zu vollenden, haben im Allgemeinen feste und kurze Latenzen.
Die TTU 700 zu unterbrechen, ist aber eine Herausforderung für den SM 132, da irgendeine gegebene Abfrage, die der SM an die TTU sendet, eine unvorhersehbare Zeitspanne wie z. B. Tausende oder sogar Hunderttausende von Zyklen zur Vollendung in Anspruch nehmen könnte, abhängig von einer Vielzahl von Faktoren wie z. B. der BVH, die traversiert wird, der räumlichen Beziehung zwischen dem Strahl, den die Abfrage spezifiziert, der Art der Geometrie (z. B. Alpha im Gegensatz zu Opak), die der Strahl schneidet, wie viele Speicherladungen benötigt werden, ob sich die Daten bereits in Cache-Speicher befinden (und wenn ja, welchem), anderen interne Scheduling-Aufgaben innerhalb der TTU 700, usw. Der Umstand, dass die TTU 700 potenziell eine vergleichsweise lange, variable Zeit benötigen kann, um irgendeine gegebene Abfrage abzuschließen, erzeugt das Risiko, dass der Präemptionsmechanismus des SM 132 in gewissen Fällen nutzlos gemacht wird, in denen die TTU 700 lange braucht, um eine Abfrage abzuschließen, wodurch verhindert wird, dass der SM jemals eine Ausnahmebehandlung durchführt. Im Gegensatz dazu wäre es wünschenswert, dem SM 132 zu erlauben, der TTU 700 eine Strahl-Operations-Präemption aufzuzwingen und dabei sicherzustellen, dass die TTU in einer vorhersehbaren Weise und innerhalb einer angemessenen Zeit (geringe Latenz) elegant unterbrechen wird.
Konkreter können die nicht einschränkenden Beispiel-Prozesse „Scoreboards“ verwenden, um Abhängigkeiten von ausstehenden Lade- oder Lesevorgängen der TTU 700 zu verfolgen. In nicht einschränkenden Implementierungsbeispielen kann der SM 132 nicht unterbrochen werden, bis diese Daten von der TTU 700 zum SM zurückkommen - was im Allgemeinen nicht geschehen würde, bis die Traversierung abgeschlossen ist. Solange ein Scoreboard ausstehend ist, darf der SM 132 nicht in den Ausnahmebehandler eintreten, so dass er dort wartet. Im schlimmsten Fall könnte sich die Präemption um Hunderttausende von Zyklen verzögern, oder sogar noch länger, wenn es eine schlecht strukturierte BVH gibt, die eine interne (z. B. endlose) Schleife enthält (zum Beispiel zeigt ein Zeiger innerhalb des BVH-Baums auf die Wurzel des Baumes und bewirkt dadurch, dass die Traversierung des Baumes endlos ist, was bedeutet, dass der Graph kein Baum mehr ist). Dies könnte aufgrund eines Bugs geschehen oder könnte einen böswilligen Angriff auf das System bei einem Versuch, das System auf unbestimmte Zeit zu binden, darstellen. Auf einer gemeinsam genutzten Maschine könnte eine solche Schleife es einem Angreifer ermöglichen, einen Denial-of-Service-Angriff zu implementieren, es sei denn, es ist ein Mechanismus vorgesehen, um die Traversierung zu unterbrechen.
Eine mögliche Lösung für ein derartiges Problem besteht darin, einen Wachhund-Timer zu verwenden, um Aufgaben der TTU 700, deren Vollendung zu lange dauert, zu beenden. Diese Methode würde zwar dem Schutz des Systems dienen, ist aber nicht sehr flexibel und ermöglicht keine elegante Wiederherstellung für die auf SM 132 laufende Software.
Präemptionsmanagement
In den nicht einschränkenden Implementierungsbeispielen ist eine Anforderung oder Abfrage eines SM 132 an die TTU 700 etwas, das die TTU wieder an den SM zurückgeben kann, während sie läuft. Wenn die TTU 700 zum Beispiel während des Traversierens der BVH im Namen eines Strahls auf ein Alpha-Dreieck trifft, kann die TTU Abfrageergebnisse mitten in der Traversierung zurückgeben. Siehe die gleichzeitig anhängigen allgemein verwandten US-Anmeldungen:

(Anwaltsakte: 6610-0032/18-AU-127) mit dem Titel „Method for Continued Bounding Volume Hierarchy Traversal on Intersection without Shader Intervention“; (Anwaltsakte: 6610-0035/18-SC-0144) mit dem Titel „Query-Specific Behavioral Modification of Tree Traversal“; und (Anwaltsakte: 6610-0037/18-SC-0149) mit dem Titel „Method for Handling Out-of-Order Opaque and Alpha Ray/Primitive Intersections“. Eine Abfrage kann somit mehrere Abfragen zwischen einem SM 132 und der TTU 700 umfassen; und es existiert ein Mechanismus, der es der TTU erlaubt, einen Zwischen-Traversierungsstatus an den SM zurückzugeben. Das nicht einschränkende Implementierungsbeispiel nutzt diese Fähigkeit aus, um die Traversierung auf natürliche Weise zu unterbrechen und später wieder aufzunehmen, um weitere Funktionalität zu ermöglichen - nämlich Präemptions-Management. Bei einem solchen Präemptions-Management kann der SM 132 die gesamte TTU 700 unterbrechen und alle Arbeit stoppen, die die TTU durchführt. Dies bedeutet, dass alle Strahl-Verarbeitung, die die TTU 700 durchführt, stoppen sollte. Der SM 132 kann Präemption aus einer Reihe von Gründen anordnen, darunter zum Beispiel die Notwendigkeit, die TTU 700 neu zuzuweisen, um vorübergehend andere wichtige Arbeit zu tun (danach kann der SM die TTU anweisen, dort wieder aufzunehmen, wo sie aufgehört hat).

Das nicht einschränkende Implementierungsbeispiel bietet eine Vorankommgarantie
Stellen Sie sich einen Zimmermann vor, der einen Job an einem Arbeitsplatz zu erledigen versucht. Wenn der Zimmermann 30 Minuten zu Beginn des Arbeitstages braucht, um seine Werkzeuge, Sägepferde, Verlängerungskabel, Zubehör usw. einzurichten, bevor er mit der Arbeit beginnt, und 30 Minuten am Ende des Arbeitstages, um alle Werkzeuge zu reinigen und wegzuräumen, und man dann den Zimmermann nach 25 Minuten bei der Arbeit unterbricht und an einen anderen Arbeitsplatz schickt, bedeutet dies, dass er überhaupt keine Arbeit erledigt bekommt. Der Zimmermann wird nicht einmal das Auspacken und Einrichten seiner Werkzeuge beendet haben, bevor er mit dem Wiedereinpacken beginnen muss.
Ähnlich ist es wegen Overheads beim Starten einer TTU-700-Abfrage und beim Bekommen der ersten Daten für Traversierung möglich, dass eine Reihe von Präemptionen dazu führen könnten, dass konkurrierende Arbeit nicht vorwärts kommt, da sich die konkurrierenden Arbeitsaufgaben ständig gegenseitig unterbrechen, ohne dass eine (oder irgendeine) von ihnen vorankommt.
Um dieses Problem zu vermeiden, hat die TTU 700 in nicht einschränkenden Implementierungsbeispielen eine Vorankommgarantie: Jedem Strahl, der eine Abfrage startet, wird garantiert, mindestens einen Traversierungsschritt zu machen, der den Inhalt des Traversierungsstapels modifiziert. In dem nicht einschränkenden Implementierungsbeispiel verschiebt die TTU 700 somit den Präemptionsbefehl für einen Strahl, bis sie mindestens einen Traversierungsschritt abgeschlossen hat (der in dem nicht einschränkenden Implementierungsbeispiel durch ein Stapel-Drauflegen oder ein Stapel-Abheben gemessen werden kann). Um die Vorankommgarantie zu implementieren, wird die anfängliche Aktivierung für einen Strahl ignoriert, wenn es ein Präemptionssignal gibt, und statt an den SM 132 zurückzugeben, wird sie den korrekten Datenpfad aktivieren, wie von ihrem Stapelinhalt vorgeschrieben.
Ein Traversierungsschritt kann auch mit einer Stapeleintrag-Modifizierung gemessen werden. Zum Beispiel kann ein Alpha-Dreieck-Schnittpunkt den Dreieck-Bereich auf dem Stapel modifizieren, und dies kann als ein Traversierungsschritt gezählt werden. In diesem Fall wird das Alpha-Dreieck jedoch in diesem Zeitpunkt ohnehin an den SM 132 zurückgegeben, so dass sein Einschluss etwas umständlich sein könnte. Siehe unten.
In dem nicht einschränkenden Implementierungsbeispiel ist das erwartete Verhalten der TTU 700, dass sie einige sinnvolle Arbeit verrichtet, selbst wenn der SM 132 versucht, sie unmittelbar nach Empfang eines Abfragebefehls zu unterbrechen. Um ein Szenario zu vermeiden, in dem die TTU 700 nicht voran kommt, geben die nicht einschränkenden Implementierungsbeispiele eine Vorankommgarantie, dass ein Strahl, wenn er eine Strahl-Traversierung in der TTU 700 startet, mindestens eine Stapelmodifizierungsaktion durchführen darf, bevor er unterbrochen wird.
11A - 11H zeigen eine Analogie. In 11A führt ein Roboter, der die TTU 700 repräsentiert, einige Arbeit durch, d. h. einen Strahlverarbeitungs-Traversierungsschritt. Wenn der Roboter den Schritt abgeschlossen hat, legt der Roboter die Ergebnisse auf einen Stapel (11B) und beginnt mit der Arbeit am nächsten Traversierungsschritt (11C). Wenn der Roboter den nächsten Schritt vollendet, legt der Roboter diese Ergebnisse auf den Stapel (11D) und beginnt mit der Arbeit an der nächsten Traversierung-Operation (11E). 11E zeigt jedoch, dass der Roboter einen Befehl (vom SM 132 - dem „Chef“) empfängt, die Arbeit zu stoppen. Statt dem Präemptionsbefehl sofort zu gehorchen, beendet der Roboter (da er weiß, dass er vorankommen soll) den aktuellen Traversierungsschritt 11 F und legt die Ergebnisse auf den Stapel (11G). Durch Abschließen dieses Traversierungsschritts garantiert der Roboter ein Vorankommen (12 Block 3002), gleich wie oft der Roboter unterbrochen wird.
Sobald der Roboter den Traversierungsschritt abgeschlossen hat und die Ergebnisse auf den Stapel gelegt hat, beendet der Roboter die Arbeit (11H) und sendet den Stapel zur Aufbewahrung an den SM 132. Der Roboter wartet dann auf weitere Anweisungen (in manchen Implementierungen kann der Roboter sofort mit anderer Arbeit beginnen, statt nur zu warten).
Ähnlich, wenn in nicht einschränkenden Implementierungsbeispielen der SM 132 unterbrechen will, sendet er ein Präemptionssignal an die TTU 700 (siehe 12). Wenn die TTU 700 die Verarbeitung einfach sofort nach Empfang des Präemptionssignals des SM 132 stoppen würde, könnte es ein Szenario geben, in dem die TTU nie vorankommt. Es gibt eine begrenzte Menge an Overhead-Zeit, die mit dem Einrichten einer TTU-700-Abfrage und dem Zurückbringen der Ergebnisse an den SM 132 verbunden ist. Man könnte denken, dass es wünschenswert wäre, schneller als dieser Overhead zu unterbrechen. Angenommen, der SM 132 richtet eine Abfrage mit der TTU 700 ein, sendet dann kurz darauf ein Präemptionssignal an die TTU, das die TTU zwingt, zu stoppen, was auch immer sie gerade tut. Die TTU 700 würde als Antwort auf das Präemptionssignal stoppen und ihre Ergebnisse an den SM 132 zurücksenden. Würde eine solche Präemption in rascher Folge wiederholt werden, würde die TTU 700 nicht vorankommen. Vielmehr würde die TTU 700, wie der oben beschriebene Zimmermann, ihre gesamte Zeit damit verbringen, die aufeinanderfolgenden Abfragen einzurichten und zu unterbrechen, und würde keine Zeit damit verbringen, eine Abfrage tatsächlich durchzuführen.
Um Fläche zu sparen, verfolgt das nicht einschränkende Implementierungsbeispiel nicht direkt oder versucht nicht direkt zu verfolgen, ob ein Strahl seit der letzten Präemption tatsächlich vorangekommen ist. Wenn die TTU 700 das Präemptionssignal empfängt, stellt die TTU sicher, dass irgendein (jeder) Strahl, der aktiv ist, einen weiteren Schritt macht. Im Allgemeinen kann das System durch Beobachten seit dem Zeitpunkt, in dem das Präemptionssignal geltend gemacht wird, dass jeder aktive Strahl vorangekommen ist, garantieren, dass alle unbeendeten Strahlen etwas vorangekommen sind. Es mag ein ungewöhnlicher Fall sein, dass die TTU aufgrund wiederholter Präemptionen nicht vorankommt, doch sollte ein gut konstruiertes, robustes System in der Lage sein, auch solche ungewöhnlichen Ereignisse ohne Ausfall zu bewältigen.
In nicht einschränkenden Implementierungsbeispielen bedeutet Vorankommen (siehe 12 Block 3002), dass die TTU 700 etwas auf den Traversierungsstapel drauflegen, etwas von dem Stapel abheben oder einen bereits auf dem Stapel befindlichen Eintrag modifizieren kann oder wird. In nicht einschränkenden Implementierungsbeispielen wird die TTU 700 als nicht vorangekommen angesehen, wenn sie nicht und bis sie mindestens eine dieser Stapelmodifizierungsaktionen durchführt oder durchführen wird. In der Zwischenzeit verzögert der SM 132 Präemption, bis die TTU 700 den Status und die Ergebnisse an den SM zurückgibt, nachdem sie eine solche Stapelmodifizierungsaktion durchgeführt hat (oder garantiert durchführt), die ein Vorankommen darstellt (siehe 12, Ausgang „Nein“ zu Block 3002).
Stapelbasierte Vorankommgarantie
In nicht einschränkenden Implementierungsbeispielen sagt ein Kurzstapel-Mechanismus innerhalb der SMU 740 der TTU 700, welche Arbeit als nächstes erledigt werden muss. Der Stapel wird Einträge haben, die zum Beispiel Complet-Traversierungen sind, die verwendet werden, um den Strahl gegen Begrenzungskästen in der BVH zu testen. Der Stapel wird auch Einträge enthalten, die Geometriebereiche (z. B. Dreieck-Bereiche) spezifizieren, gegen die die TTU 700 den Strahl testen soll. Der Kurzstapel wird auch Einträge enthalten, die Instanzknoten anzeigen, gegen die die TTU 700 eine Transformation durchführen muss. Der Stapel kann auch Element-Bereiche oder Knotenverweise umfassen, die an den SM 132 zurückgegeben werden müssen.
In dem nicht einschränkenden Implementierungsbeispiel werden die Complet-Test-Einträge Einträge auf den Stapel drauflegen, während die TTU 700 tiefer in die BVH-Datenstruktur traversiert, und Einträge vom Stapel abheben, während die TTU nach oben in der BVH traversiert. Der Dreieck-Bereich-Teil, in dem die TTU 700 den Strahl gegen Dreiecke testet, wird Stapeleinträge modifizieren (während die TTU Schnittpunkttests gegen angezeigte bestimmte Dreiecke in dem Bereich durchführt), oder die TTU kann den vollendeten Eintrag vom Stapel abheben, wenn die TTU Schnittpunkttests gegen alle Dreiecke in dem Bereich durchgeführt hat. Ein Instanzknoten, der sich auf dem oberen (Welt-Raum-) Stapel befindet (d. h., das wird im Welt-Raum dargestellt), wird die TTU 700 veranlassen, eine Transformation in den Objekt-Raum durchzuführen, woraufhin der Instanzknoten bewirken wird, dass ein Eintrag (d. h. die Wurzel der instanzierten BVH) auf den unteren (Objekt-Raum-) Stapel draufgelegt wird, so dass die TTU die Traversierung (z. B. im Objekt-Raum des Teilbaums der Instanzknoten-BVH) auf dem unteren Stapel fortsetzen kann, während sie den oberen Stapel unverändert lässt. Der untere Stapel wird nun Inhalte enthalten, die initialisiert werden müssen (oder die durch die Transformation initialisiert werden können), die dann von der TTU 700 ausgeführt werden. Der untere Stapel wird im Allgemeinen Complets enthalten, die auf Basis irgendeiner Anzahl von Traversierungen der BVH gegen den Strahl getestet werden müssen, und wird auch Dreieck-Bereich-Einträge enthalten, während die Traversierung weitergeht. Der untere Stapel kann auch Instanzknoten und Element-Bereiche aufweisen, die an den SM 132 zurückgegeben werden müssen.
Während Instanzknoten im Welt-Raum die Traversierung fortsetzen werden, reicht in dem nicht einschränkenden Implementierungsbeispiel das bloße Wechseln in den Objekt-Raum nicht aus, um ein Vorankommen zu demonstrieren. Das nicht einschränkende Implementierungsbeispiel verwendet als Indiz für Vorankommen eine Modifizierung des ausgegebenen Stapels, um zum Beispiel zu demonstrieren, dass die TTU 700:

etwas im Strahl-Complet-Test getan hat (d. h. ein Complet auf den Stapel für eine Abwärts-Traversierung der BVH draufgelegt hat oder das gerade geprüfte Complet vom Stapel abgehoben hat) (Siehe 12A Block 3012); oder ...
im Falle eines Dreieck-Schnittpunkttests einen Dreieck-Bereich von dem Stapel abgehoben hat oder den Dreieck-Bereich modifiziert hat, der durch einen Stapeleintrag dargestellt wird, zum Beispiel im Falle von Alpha-Dreiecken, bei denen die TTU den Strahl verkürzt und/oder auf andere Weise den Dreieck-Bereich auf eine Teilmenge des gesamten Bereichs beschränkt (siehe 12A, Block 3014). In einer Implementierung kann die TTU 700 den Dreieck-Bereich beschränken, ohne den Strahl zu modifizieren. Man nehme zum Beispiel an, ein Alpha-Dreieck kehrt zum SM 132 zurück. Falls der SM einen Treffer ermittelt, kann der SM die Abfrage mit einem modifizierten t-Bereich für den Strahl neu starten. Davor modifiziert die TTU 700 den Dreieck-Bereich-Eintrag intern, um auf das nächste Dreieck zu zeigen, das bei Rückkehr zu testen ist.

Aufgrund der Art und Weise, wie der SM 132 Strahlen im Abfrage-Setup so spezifiziert, dass sie sich immer im Welt-Raum befinden, muss die nicht einschränkende Beispiel-TTU 700, wenn sie eine vorherige Abfrage im Objekt-Raum wiederaufnimmt, als erstes den Strahl wieder vom Welt-Raum in den Objekt-Raum transformieren. Da die TTU 700 statuslos ist und immer mit dem oberen oder Welt-Raum-Stapel beginnt, ist der erste Schritt für eine instanzierte Traversierung immer eine Instanztransformation. Dieser Schritt modifiziert nicht den Inhalt des Traversierungsstapels für diesen Instanzknoten-Eintrag, sondern verschiebt die Ausführung vom oberen oder Welt-Raum-Stapel zum unteren oder Objekt-Raum-Stapel. (Die Transformation kann Einträge auf den unteren Stapel drauflegen.) Somit verschieben in nicht einschränkenden Implementierungsbeispielen Instanzknoten lediglich die TTU-Verarbeitung vom oberen (Welt-Raum-) Stapel zum unteren (Objekt-Raum-) Stapel, ohne den Eintrag auf dem oberen Stapel zu ändern und ohne noch einen Eintrag auf den unteren Stapel draufzulegen.
Wenn dies die einzige Aktion ist, die die TTU 700 seit Wiederaufnahme der Abfrage durchgeführt hat, muss diese TTU bei einem Neustart der Abfrage die gleiche Aktion erneut ausführen. Da der Transformationsknoten den Instanzknoten-Stapeleintrag nicht modifiziert, wird möglicherweise eine Instanztransformation durchgeführt und ist für dieselbe Traversierung möglicherweise eine Anzahl vom Malen erforderlich. Wenn dies der einzige bei der Vorankommgarantie erlaubte Schritt wäre, dann wäre er für Vorankommen unzureichend, da dieser Schritt den Traversierungsstapel nicht modifiziert und beim Neustart der Abfrage einfach immer wieder wiederholt wird. Aus diesem Grund wird in dem nicht einschränkenden Implementierungsbeispiel ein Instanzmodifizierer nicht als ein Stapelmodifizierer betrachtet, um das Vorankommen zu demonstrieren (siehe 12A, Block 3014, Ausgang „Nein“, und Verzweigung zu Block 3012 nach Fortsetzung). Aus diesem Grund ist die Aktivierung nach einer Instanztransformation (wie die anfängliche Aktivierung) auch für Umleitung zum SM 132 bei Präemption nicht zulässig. Auf diese Weise wird der untere oder Objekt-Raum-Stapel inspiziert, und mindestens ein Traversierungsschritt, der diesen Stapel modifiziert, wird vollendet, bevor Präemption stattfinden kann.
Es ist auch möglich, dass ein Strahl mehr als einen Traversierungsschritt durchführen muss. In dem nicht einschränkenden Implementierungsbeispiel gibt es manche Stapeleinträge, die als Auto-Pop-Einträge („Auto-Drauflege-Einträge“) bezeichnet werden. In nicht einschränkenden Implementierungsbeispielen ist ein Auto-Pop-Eintrag typischerweise auf einen Opakes-Dreieck-Bereich beschränkt, der in der TTU 700 zu verarbeiten ist. Das Vorhandensein dieser Einträge liegt daran, dass ein Benutzer eine reduzierte Stapelgrenze angeben kann, die einschränkt, was an den SM 132 zurückgegeben werden kann. Aus Gründen der Leistungsfähigkeit wollen wir oft intern diese Stapelgrenze überschreiten, und dies kann für diejenigen Stapeleinträge sicher getan werden, die keinen Eintrag auf dem Stapel lassen oder zusätzliche Einträge auf den Stapel drauflegen können. Ein Opakes-Dreieck-Bereich hebt sich garantiert selbst vom Stapel ab und erzeugt keine neuen Einträge auf dem Stapel. Ein Strahl, der mit Opakes-Dreieck-Bereichen oben auf dem Stapel unterbrochen wird, muss möglicherweise jeden dieser Einträge verbrauchen, um in die Stapelgrenze für Rückgabe an den SM 132 zu passen. Nur aus Gründen der Einfachheit gehen manche nicht einschränkende Implementierungs-Designs davon aus, dass alle Opakes-Dreieck-Bereiche aus Präemptionsgründen Auto-Pop sind - obwohl dies keine funktionale Voraussetzung für andere Implementierungen ist.
Innerhalb der TTU 700 in nicht einschränkenden Implementierungsbeispielen besitzt die Stapelverwaltungseinheit (SMU) 740 eine Steuerschaltung, die den oberen Stapeleintrag betrachtet und entscheidet, was die TTU als nächstes tun wird. Abhängig vom Inhalt des oberen Stapeleintrags kann die SMU 740 zum Beispiel die entsprechende Arbeit über den Pfad Strahl-Complet-Test 710 oder stattdessen über den Pfad Strahl-Dreieck-Test 720 senden. Das Senden solcher Arbeit über einen dieser Wege bedeutet, dass die TTU 700 einen weiteren Schritt in der aktuellen Abfrage macht. Alternativ kann die SMU 740 der Schnittstelle von der abfragenden SM 132 signalisieren, dass der aktuelle Strahl durchgeführt wird. Die SMU 740 besitzt auch eine Aufzeichnung der unmittelbar vorhergehenden Verarbeitung - zum Beispiel, ob der letzte Test ein Strahl-Complet-Test oder ein Strahl-Dreieck-Test war. Die SMU 740 weiß zum Beispiel, dass, wenn die letzte Operation ein Strahl-Complet-Test war, dann tatsächlich ein Traversierungsschritt gemacht worden ist, dass Vorankommen stattgefunden hat und dass die nächste Operation darin besteht, einen Eintrag vom Stapel abzuheben. Wenn die letzte Operation ein Strahl-Dreieck-Test auf Basis eines Dreieck-Bereichs war, dann weiß die SMU 740, dass sie den entsprechenden Stapeleintrag modifizieren wird. Wenn die letzte Operation eine Instanztransformation war, dann weiß die SMU 740, dass sie den Stapel nicht so modifizieren wird, dass kein Vorankommen deklariert wird. Was die SMU 740 in diesen Beispielen testet, ist, dass jeder Strahl eine Aktivierung durchlaufen hat oder beendet worden ist.
Eine vierte mögliche Bedingung ist eine anfängliche Strahl-Aktivierung, die von der Strahlverwaltungseinheit 730 kommt. In dem nicht einschränkenden Implementierungsbeispiel deklariert die Strahlverwaltungseinheit (RMU) 730, dass ein neuer Strahl aktiviert worden ist, und weist die SMU 740 an, oben auf den Stapel zu sehen. Wie oben erörtert, ist dies in nicht einschränkenden Implementierungsbeispielen für Vorankommen nicht genug, da keine Stapeländerungen vorgenommen worden sind.
Da die SMU 740 weiß, woher die Verarbeitung gekommen ist (d. h., dem letzten Schritt, der durchgeführt worden ist), kann die SMU ermitteln, ob ein Vorankommen stattgefunden hat. Es ist möglich, dass die TTU 700 seit der letzten Präemption oder einem anderen Ereignis mehrere Traversierungsschritte durchgeführt hat. Dies könnte in einem oder mehreren Flags gespeichert werden. In dem nicht einschränkenden Implementierungsbeispiel zeichnet die TTU 700 diesen Umstand nicht auf, um Chipfläche zu sparen. Die Auswirkung ist, dass das nicht einschränkende Implementierungsbeispiel einen zusätzlichen Traversierungsschritt machen kann, wenn ein solcher zusätzlicher Schritt nicht unbedingt notwendig war, um eine Vorankommgarantie zu bieten. Ein einzelner Traversierungsschritt ist typischerweise kein Ereignis mit langer Latenz. In anderen nicht einschränkenden Implementierungsbeispielen könnte die Art der Stapelaktualisierung, die stattgefunden hat oder stattfinden wird, als eine Vorankommgarantie verwendet werden (z. B. um sicherzustellen, dass der Stapel aktualisiert wird, um widerzuspiegeln, dass ein Blattknoten in der BVH erreicht oder verarbeitet worden ist).
Der Mechanismus des nicht einschränkenden Implementierungsbeispiels zum Garantieren von Vorankommen muss nicht die Stapelmodifizierung selbst als Auslöser verwenden, sondern verwendet stattdessen „woher sind Sie gekommen“ -Informationen, die eine Stapelmodifizierung bedeuten. Der Vorankommgarantie-Mechanismus in Implementierungsbeispielen muss daher nur wissen, dass der Stapel modifiziert werden wird. Er muss weder die Stapelmodifizierung tatsächlich beobachten, um zu beweisen, dass sie stattfindet, noch muss er genau wissen, wie der Stapel modifiziert worden ist oder werden wird. Wenn sie die Bestimmung von Vorankommen durchführt, untersucht die SMU 740 den vorherigen Status der TTU 700, was bedeutet, dass der Stapel tatsächlich modifiziert wird. Der Stapel ist eine Art Prüfpunkt, der darstellt, wo sich ein bestimmter Strahl im Laufe der Traversierung einer BVH befindet und wie er dorthin gelangt ist. Das Konzept der Verwendung einer Stapelaktualisierung als Indikator für Vorankommen funktioniert gut, da der Stapel den wahren aktuellen Status der TTU 700 anzeigt, so dass die Anwendung einer Aktualisierung auf diesen Stapel ein zuverlässiger Mechanismus zum Anzeigen von Vorankommen ist.
In dem nicht einschränkenden Implementierungsbeispiel ermöglicht die TTU 700 dem SM 132, auf den Status der TTU zuzugreifen und ihn abzuspeichern. In dem nicht einschränkenden Implementierungsbeispiel ist die TTU 700 statuslos, das heißt, sobald sie einen bestimmten Prozess beendet, „vergisst“ sie völlig, was sie getan hat und wie weit sie gekommen ist. Dieses Merkmal ermöglicht ein hohes Maß an Skalierbarkeit und erfordert nicht, das die TTU 700 Schreibzugriff auf Hauptspeicher hat. Wenn eine Ausnahme auftritt und die TTU 700 das Vorankommen für jeden aktiven unvollendeten Strahl, den sie aktuell bearbeitet, bestätigt hat, speichert der SM 132 den Status der TTU 700 für diesen Thread oder Ausführungs-Slot ab, d. h. das Ergebnis der bisherigen Traversierung der TTU und ausreichende Zusatzinformationen, damit die TTU ihren Status wiederherstellen und dort fortfahren kann, wo sie aufgehört hat (dazu muss der SM nicht wissen, wie weit die TTU in dem Prozess gekommen ist, da der SM den Status der TTU für den gerade unterbrochenen Ausführungs-Slot/Thread speichert).
Die TTU 700 gibt jeden (oder alle) aktuell gespeicherten Treffer an den SM 132 zurück. In den meisten Präemptionsfällen gibt es Zwischentreffer, die in irgendeiner Weise gespeichert werden müssen (entweder in Registern oder in Speicher überschwappen gelassen). Ein Zwischentreffer kann gleichbedeutend mit dem letzten Treffer sein oder auch nicht. Die TTU 700 wird die Traversierung auf Basis der zurückgegebenen Stapel- und Strahlinformationen fortsetzen. In dem Ausführungsbeispiel ist es Sache des SM 132, im Falle von Zwischentreffern den Strahl auch so zu verkürzen, dass er dem zurückgegebenen Treffer entspricht (statt in dem ursprünglichen tmax zurückzugeben).
Aus der Sicht des SM 132 gibt es keinen Unterschied zwischen einer TTU-700-Rückgabe aufgrund von Präemption und einer TTU-Rückgabe, weil die TTU SM-Unterstützung benötigt (z. B. Alpha-Strahlen, Element-Bereiche, usw.). Eine Ausnahme ist, dass die TTU 700 im Falle einer Präemption einen Fehlschlag zurückgeben kann, gepaart mit einem Stapel, der weitere Traversierung erfordert (in dem Ausführungsbeispiel würde die TTU normalerweise die Traversierung abschließen, bevor sie einen Fehlschlag meldet). In dem nicht einschränkenden Ausführungsbeispiel ist der Ausnahmebehandler des SM 132 dafür verantwortlich, den Registerinhalt für diesen Thread in einem allgemeinen Sinne zu speichern. Diese Register werden die von der TTU 700 zurückgegebenen Informationen enthalten, aber auch irgendwelche anderen Informationen, über die der SM verfügt. Wenn die Threads wiederhergestellt werden, ist der Ausnahmebehandler des SM 132 für Wiederherstellung des Inhalts dieser Register verantwortlich. Der SM 132 inspiziert dann die TTU-Rückgabe und wirkt darauf ebenso wie wenn die Ausnahme nicht passiert wäre. Wenn es sich nämlich nur um ein Zwischenergebnis handelt, speichert der SM 132 das Ergebnis ab und startet die Abfrage neu, so dass die TTU 700 dort weitermachen kann, wo sie aufgehört hat.
Nicht einschränkendes Beispiel für programmierbare Timeouts
Wir bauen auf diesem Präemptions-Timeout und der Vorankommgarantie auf, um benutzerprogrammierbare Timeouts zu implementieren. Wir erläutern zwei Varianten: arbeitsbasiert und zyklusbasiert. Solche Timeouts können verwendet werden, um die Verarbeitung für einen bestimmten Strahl automatisch zu unterbrechen. In nicht einschränkenden Implementierungsbeispielen ist ein TTUweiter Timeout für Präemption reserviert und wird nicht durch individuelle Timeouts für individuelle Strahlen ausgelöst.
Es ist möglich, benutzerprogrammierbare Timeouts bereitzustellen, die auf demselben Mechanismus aufbauen. Grafikentwickler sind es gewohnt, Szenen zu modellieren und Grafiken zu steuern, so dass sie garantieren können, dass Einzelbilder innerhalb einer Einzelbild-Zeit wie z. B. 16 ms (entsprechend 60 Hz) verarbeitet werden. Bei Strahlverfolgung ist dies möglicherweise nicht der Fall. Wie oben erörtert, kann es für die TTU 700 unvorhersehbar lange Zeit oder Zyklen dauern, um einen gegebenen Strahl zu verarbeiten. Zum Beispiel kann es sein, dass ein gegebener Strahl von viel Geometrie überflogen wird (man stelle sich z. B. einen Strahl vor, der parallel zu einer Brücke oder entlang eines kettenverknüpften Zauns verläuft), so dass er gegen eine große Anzahl von BVH-Knoten zu testen ist, um einen Schnittpunkt zu bestimmen. Es kann nützlich sein, Steuerungen bereitzustellen, die es Entwicklern erlauben, die Zeitspanne, Verarbeitungszyklen oder beides für die Verarbeitung eines gegebenen Strahls zu begrenzen.
In dem nicht einschränkenden Implementierungsbeispiel ist ein Timer damit verknüpft, wie lange die TTU 700 braucht, um einen gegebenen Strahl zu verarbeiten, nicht wie lange sie braucht, um alle Strahlen in der Szene oder sogar alle Strahlen in einem gegebenen Warp oder Thread zu verarbeiten.
Zum Beispiel ist es in Implementierungsbeispielen möglich, anstelle eines Timeout für eine gesamte TTU 700 einen Timeout für einen einzelnen Strahl zu erzeugen, der gerade von der TTU verarbeitet wird. Ein solcher Mechanismus kann verwendet werden, um die Menge an Arbeit zu steuern, die ein einzelner Strahl leistet. Zum Beispiel ist es möglich, eine obere Grenze zu setzen, wie lange die Verarbeitung eines bestimmten Strahls dauern wird. Dies ist besonders nützlich bei virtueller Realität, die ein Ergebnis in einer gewissen Zeitspanne benötigt, um die Display-Latenz zu reduzieren und VR-Krankheit zu vermeiden (die sich wie Reisekrankheit anfühlen kann). Da eine Strahl-Traversierung in einem beliebigen Fall möglicherweise zu lange dauert, kann es wünschenswert sein, eine Grenze für die Dauer der Strahl-Traversierung festzulegen. Dies könnte eine Möglichkeit bieten, einen Strahl aufzugeben, den das System in die Szene geschossen hat, und (weil diese Aufgabe zu lange dauert) auf einen anderen Mechanismus zurückzugreifen, um das Bild in einer kürzeren Zeitspanne zu zeichnen.
Wie in 13 gezeigt, sieht ein Implementierungsbeispiel eines arbeitsbasierten Timeout einen Zähler pro Strahl und ein programmierbares Ziel pro Strahl vor. Jedes Mal, wenn die TTU 700 eine Aktion (Traversierungsschritt) wie z. B. einen Strahl-Complet-Test oder einen Strahl-Dreieck-Test in Bezug auf einen bestimmten Strahl durchführt, inkrementiert die TTU einen entsprechenden Zähler 3200 für diesen Strahl. Der Zähler könnte jeden Traversierungsschritt zählen, unabhängig vom Typ, oder er könnte Blattknoten-Traversierungsschritte zählen, oder es könnte separate Zähler für unterschiedliche Arten von Traversierungsschritten geben. Sobald diese(r) Zähler 3200 das programmierbare Ziel 3202 für diesen Strahl überschreiten bzw. überschreitet, stoppt die TTU 700 den Strahl und sendet die Ergebnisse an den SM 132 zurück.
Da dies ein sauberer Stopp ist, könnte der Kernel aufrufende SM 132, wenn er dies wollte, den Strahl neu starten und die TTU 700 die Arbeit beenden lassen. Oder der SM 132 könnte den Strahl fallen lassen und eine andere Methode verwenden, um die Verarbeitung des aktuellen Bildes zu beenden. Da diese Technik pro Strahl angewendet wird, kann jeder Strahl so programmiert werden, dass er seinen eigenen Zielwert hat, der bei Überschreitung eine Beendigungsausführung auslöst. Unterschiedliche Strahlen können unterschiedlich viele Traversierungsschritte durchführen, bevor die TTU 700 sie daran hindert, fortzufahren, und den SM 132 fragt, was sie als nächstes tun soll, je nachdem, was sonst noch vor sich geht.
Der arbeitsbasierte Timeout bietet einem Benutzer ein Mittel, um die Anzahl der erlaubten Traversierungsschritte pro Strahl zu beschränken. In einem Ausführungsbeispiel speichert der arbeitsbasierte Timeout einen einzelnen Wert, was Fläche spart. Dieser Wert wird auf den Zielwert initialisiert, bei jedem Traversierungsschritt dekrementiert und löst einen Pro-Strahl-Timeout aus, wenn er 0 erreicht. Das Auslösen könnte alternativ beim Übergang von 1 zu 0 stattfinden, so dass der Wert 0 als Sonderfall zum Unterbinden von Timeouts reserviert werden kann. In diesem Fall würde ein Auto-Pop-Eintrag oben auf dem Stapel nach dem 1-zu-0-Übergang den Zähler zurück auf 1 inkrementieren, um den 1-zu-0-Übergang noch zu sehen, nachdem der Auto-Pop-Eintrag verarbeitet worden ist.
In einer alternativen Ausführungsform kann der arbeitsbedingte Timeout auf zwei Werten basieren gelassen werden, die miteinander verglichen werden. In dieser Zwei-Werte-Ausführungsform wird während des Abfrage-Setup für einen Strahl ein zusätzliches N-Bit-Feld aufgenommen, das eine Ziel-Anzahl von Traversierungsschritten spezifiziert. Dieses Ziel wird in der SMU 740 neben einem Zähler der Traversierungsschritte für diesen Strahl gespeichert. Der Traversierungsschrittzähler wird bei jeder Aktivierung nach der anfänglichen Aktivierung inkrementiert (d. h. irgendeiner Aktivierung, die nach einem Strahl-Complet-Test- oder Strahl-Dreieck-Test-Datenpfad-Ereignis stattfindet). Ein Komparator vergleicht kontinuierlich den (inkrementierten) Traversierungsschrittzähler mit der Ziel-Anzahl der Traversierungsschritte. Wenn (und falls) die Traversierungszählung das Ziel überschreitet, wird ein Timeout-Bit gesetzt, das pro Strahl existiert. Wenn dieses Bit gesetzt ist, führt die nächste Aktivierung dazu, dass der individuelle Strahl einen Timeout hat, ebenso wie es der Fall wäre, wenn die gesamte TTU unterbrochen würde. Andere Strahlen werden durch diese Aktion nicht beeinflusst.
In manchen Implementierungen könnte die Anzahl der durchgeführten Traversierungsschritte (oder die Anzahl der verbleibenden Schritte, falls die SMU nur einen Zähler speichert, der auf 0 herunterzählt) als Teil des Ergebnisses der Abfrage an den SM 132 zurückgegeben werden. Dies würde es dem Entwickler ermöglichen, die Gesamtzahl der Schritte, die für einen Strahl über mehrere Abfragen hinweg durchgeführt werden, zu begrenzen (z. B. wenn Alpha-Dreiecke oder Primitive beteiligt sind, die die TTU nicht nativ verarbeiten kann). Nehmen wir zum Beispiel an, dass der Entwickler die Gesamtzahl der Schritte anfänglich auf 100 begrenzt hat und die TTU 700 nach nur 20 Schritten für einen Alpha-Test ein Ergebnis an den SM 132 zurückgegeben hat. Wenn der Alpha-Test einen Fehlschlag anzeigt, kann es wünschenswert sein, die nachfolgende Abfrage (Fortsetzung der Traversierung) auf nur 80 Schritte zu begrenzen. Ein ähnliches Schema könnte auf zyklusbasierte Timeouts angewendet werden (unten).
Programmierbare Timeouts sind in nicht einschränkenden Implementierungsbeispielen nicht notwendigerweise erforderlich, um das Kein-Timeout-nach-Transformation-Erfordernis für die Präemptions-Vorankommgarantie einzuhalten. Im Falle, dass ein nicht einschränkendes Implementierungsbeispiel beliebt, dies nicht einzuhalten, ist es Sache des Benutzers, mindestens 2 Traversierungsschritte zu spezifizieren oder den Fall zu erkennen und die 2 Traversierungsschritte bei Neustart zu spezifizieren.
Darüber hinaus ist es ebenso wie im Präemptionsfall möglich, dass die tatsächliche Anzahl der Traversierungsschritte aufgrund von Auto-Pop-Einträgen die Ziel-Anzahl der Traversierungsschritte übersteigt.
Die Anzahl der Bits, die zum Codieren des Arbeitsziels verwendet werden, muss keine bestimmte Anzahl sein. Sie muss auch nicht bei einer Granularität von 1 Eintrag sein. Das heißt, die N-Bits könnten verschoben oder multipliziert werden, so dass sie mehr als nur die Zahl anstreben können, die durch N spezifiziert werden kann. So ermöglichen zum Beispiel 8 Bits ein Ziel zwischen 0 und 255, wobei 0 „unterbunden“ werden könnte. Durch Erlauben einer Verschiebung dieser Bits könnte eine höhere Granularität wie z. B. 4 bis 1023 in 4er-Schritten oder 8 bis 2048 in 8er-Schritten angestrebt werden. Diese Verschiebung kann auch pro Strahl programmierbar gemacht werden. Wenn die Verschiebung pro Strahl programmierbar ist, dann erklären die in der SMU 740 gespeicherten Pro-Strahl-Ziele alle möglichen Bits für notwendig, nicht nur die spezifizierten N Bits. Die Pro-Strahl-Traversierungszähler in der SMU 740 können eine Zählgranularität von 1 aufweisen.
Nicht einschränkendes Beispiel für zyklusbasierte Timeouts
Die zyklusbasierten Timeouts arbeiten ähnlich wie die arbeitsbasierten Timeouts, sind aber, wie der Name schon sagt, zeitbasiert. Globalzähler (siehe 13A, Block 3302, 3304) in der SMU 740 verfolgen „Epochen“, die als eine Anzahl von Zyklen definiert sind, z. B. 1024. Ein Zähler 3302 in der SMU 740 rückt die Zykluszählung vor, bis die Epochenzählung erreicht ist, und dann rückt der Epochenzähler 3304 um 1 vor. Der Epochenzähler 3304 bestimmt grob die aktuelle Zeit bis innerhalb dieser Granularität. Es ist möglich, einen Epochenzähler 3304 zu haben, bei dem die Epoche als ein einzelner Zyklus definiert ist. In diesem Fall gibt es nur einen einzigen Zähler, und das zweistufige Zählerdesign ist nicht erforderlich.
Ein zyklusbasierter Timeout für einen Strahl wird im Sinne von Epochen programmiert. Während des Abfrage-Setup beim Schreiben in die SMU 740 addiert jeder Strahl den aktuellen Epochenzählerwert zu seiner Ziel-Anzahl von Epochen, was Wrapping ermöglicht, und speichert diesen Wert pro Strahl in einem Zielregister 3306.
Wenn der pro Strahl mit Ziel versehene Zähler mit dem Epochenzähler übereinstimmt (d. h. der Epochenzähler ist zum Timeout-Punkt vorgerückt) (Komparator 3308), wird der Strahl so eingestellt, dass er im nächsten Schritt endet. Operationen nach diesem Zeitpunkt sind mit den vorher beschriebenen Operationen für die arbeitsbasierten Timeouts identisch.
Der zyklusbasierte Timeout ist nur genau bis innerhalb der Granularität einer Epoche plus der Zeit zum Beenden ihrer letzten Traversierungsschritte, die eine gewisse Anzahl von Speicherzugriffen mit langer Latenz sowie irgendeine Anzahl von Auto-Pop-Schritten umfassen können. Auf diese Weise ist das zyklusbasierte Timeout im Sinne des Treffens eines Ziels weniger präzise als das arbeitsbasierte Timeout, begrenzt aber dennoch die Traversierung effektiv auf einen gewünschten Zeitrahmen.
Dieser zyklusbasierte Timeout arbeitet somit durch Programmieren der maximalen Zeitspanne, die der Strahl absolvieren darf, statt eine exakte Anzahl von Traversierungsschritten zu programmieren. Die Zeitspanne könnte zum Beispiel in Form der Anzahl der TTU-Zyklen ausgedrückt werden. Nach Aktivieren des Strahls würde die TTU 700 einen Timer 3302 starten, der die verstrichenen TTU-Zyklen zählt. Sobald der Timer eine SM-spezifizierte Ziel-Zyklusanzahl überschreitet, stoppt die TTU 700 den Strahl. Da dies ein sauberer Stopp ist, kann der aufrufende SM 132 die Traversierung fortsetzen, wenn er dies will, oder er kann den Strahl fallen lassen, weil das Verarbeiten zu lange dauert, und auf einen anderen Mechanismus zurückgreifen.
In einem Implementierungsbeispiel könnte anstelle eines langen (z. B. eines 64-Bit-) Zählers pro Strahl ein einzelner Zähler 3302 von allen Strahlen gemeinsam benutzt werden. Ein Laufender-Zyklus-Zähler zählt verstrichene Zyklen. Jedes Mal, wenn der Zykluszähler eine bestimmte Anzahl von Zyklen (eine „Epoche“) zählt, wie zum Beispiel 1024 Zyklen, inkrementiert ein Epochenzähler 3304 um eins. Der Epochenzähler zählt somit Epochen. Der SM 132 sendet an die TTU 700 für jeden Strahl die Anzahl der Epochen, die der SM diesem Strahl erlaubt, bevor der Strahl aufgrund von Timeout gestoppt wird. Wenn der SM zum Beispiel den Strahl-Zeitwert auf „5“ programmiert, stellt dies zwischen 5 x 1024 Zyklen (fünf „Epochen“) und 6 x 1024 Zyklen (sechs Epochen) für Traversierung vor einem Timeout bereit (in diesem Beispiel ist es möglich, einen Strahl jederzeit während einer Epoche zu starten). Man beachte, dass ein sauberer Stopp weitere Zeit hinzufügen kann. Der zyklusbasierte Timeout ist daher nicht ganz so genau wie ein arbeitsbasierter Timeout, kann aber für viele Anwendungen ausreichend genau sein.
Zum Beispiel gibt es einen Anwendungsfall, in dem der SM 132 die TTU 700 aufgefordert hat, 32 Strahlen zu verarbeiten, und einige (zum Beispiel 28) Strahlen mit einigen Nachzüglern durchgeführt werden, die noch nicht fertig verarbeitet worden sind. Wenn diese Nachzügler so programmiert sind, dass sie vor vollständiger Vollendung einen Timeout haben, dann können alle Strahl-Ergebnisse in dieser Anforderung früher zurückgegeben werden. In diesem Fall geben die Strahlen, die beendet werden, Verarbeitungskapazität in der TTU 700 frei, und der SM 132 fordert die TTU auf, die Verarbeitung der Strahlen wiederaufzunehmen, die noch nicht vollendet worden sind, und sendet gleichzeitig mehr (neue) Strahlen, mit deren Verarbeitung die TTU beginnen soll. Dies ermöglicht eine höhere Ausnutzung der TTU 700 und eine größere Effizienz. Dieses Beispiel zeigt, dass die TTU 700 mit der Arbeit an anderen Strahlen beschäftigt sein kann, während sie darauf wartet, dass Nachzügler-Strahlen die Verarbeitung vollenden. Während der SM 132 also die Option hat, einfach Strahlen fallen zu lassen, die zu lange dauern, hat der SM die weitere Option, alle diese Nachzügler-Strahlen zusammenzufassen und zur Vollendung an die TTU 700 zurückzusenden. Durch Gruppieren dieser Nachzügler-Strahlen ist es wahrscheinlich, dass die Verarbeitung effizienter wird als wenn der SM 132 darauf wartet, dass alle Nachzügler im ersten Durchgang fertig sind.
Die arbeitsbasierten und zyklusbasierten Timeouts ermöglichen Dienstgüte-Garantien, was für jede Anwendung nützlich sein kann, die harte Begrenzungen von Arbeit erfordert. Die zusätzlichen programmierbaren Timeouts können dazu beitragen, Timing-Garantien für Anwendungen wie z. B. Strahlverfolgung in Anwendungen für virtuelle Realität (VR) zu ermöglichen und einen deterministischen Fehlerbeseitigungsmechanismus bereitzustellen. Zum Beispiel erfordert virtuelle Realität (VR) konsistente Einzelbildraten und -auffrischung, oder das Benutzererleben verschlechtert sich und kann Benutzern schließlich Unbehagen bereiten. Es kann besser sein, ein falsches Bild zu zeichnen, als die Auffrischrate zu verkleinern und Benutzer Schwindel oder Übelkeit erleben zu lassen. Programmierbare Timeouts können auch Einzelschritt-Fehlerbeseitigungs-Modi ermöglichen, die für Auf-Silizium-Bringen und interne Fehlerbeseitigung nützlich sind. Der Präemptionsmechanismus und die Vorankommgarantie ist ein hilfreicher Mechanismus für die TTU 700, die für Strahlverfolgung bei DirectX-Strahlverfolgung (DXR) und OptiX™ verwendet wird.
Weitere Implementierungsbeispiele
In anderen Implementierungen setzt die TTU 700 ein Bit oder Flag, immer wenn sie mit einem bestimmten Strahl vorankommt. Dies würde die Notwendigkeit vermeiden, einen zusätzlichen Schritt zu machen, um zu garantieren, dass ein Vorankommen erreicht worden ist, und zwar auf Kosten zusätzlicher Fläche und Schaltungskomplexität, die mit dem Lesen und Schreiben des zusätzlichen Bits oder Flags verknüpft sind.
Ein Stapel ist hilfreich, aber nicht notwendig, um die nicht einschränkenden Implementierungsbeispiele zu implementieren. Zum Beispiel gibt es stapellose Traversierungsverfahren, die verwendet werden können, um eine BVH zu traversieren. Tatsächlich ist die in 9 gezeigte Implementierung der nicht einschränkenden Beispiel-TTU 700 eine Art Hybrid zwischen einer stapellosen Traversierungs-Architektur und einer traditionellen Methode, die einen Stapel verwendet, der grenzenlos wachsen kann. In einem Beispiel kann der von der SMU 740 verwaltete „Kurzstapel“ auf N Einträge in einer aktuellen Implementierung beschränkt werden.
Zum Verwalten von Präemption ist es hilfreich, einen Mechanismus zu haben, der anzeigt, wo sich die TTU 700 beim Traversieren der aktuellen BVH befindet, um nach Präemption nicht noch einmal von vorne anfangen und frühere Arbeit wiederholen zu müssen (was natürlich kein Vorankommen bringen würde).
In manchen nicht einschränkenden Beispiel-Methoden ist es möglich, einen Stapel durch eine Bit-Spur zu ersetzen, die anzeigt, welche Teile eines binären Baums, Graphen oder dergleichen traversiert worden sind. Dieser oder andere Mechanismen könnten von der TTU 700 verwendet werden, um zu verfolgen, wo sich der Strahl beim Traversieren der aktuellen BVH befindet. Eine solche Verfolgung könnte zu einem Datenobjekt oder einem anderen Indikator führen, den die TTU 700 dem SM 132 zur Aufbewahrung zuführen kann und den der SM schließlich an die TTU zurückgibt, damit die TTU dort weitermachen kann, wo sie aufgehört hat. Solche Daten dienen zwei Zwecken: einer Darstellung, wo sich die TTU 700 in der BVH-Traversierung befindet und wie sie dorthin gelangt ist, und der Möglichkeit, Änderungen in dieser Darstellung vorzunehmen, um anzuzeigen, dass ein Vorankommen erreicht worden ist.
Während in nicht einschränkenden Implementierungen der Präemptionsmechanismus bewirkt, dass die TTU 700 die Verarbeitung aller Strahlen stoppt, ist es möglich, dass der Präemptionsmechanismus die TTU daran hindert, nur eine Teilmenge von Strahlen oder sogar nur einen einzelnen Strahl zu verarbeiten. Zum Beispiel könnte in nicht einschränkenden Implementierungsbeispielen jede TTU 700 zwei oder mehr SMs 132 bedienen. Wenn nur einer der SMs 132 unterbrochen wird, kann es wünschenswert sein, nur die von dem unterbrochenen SM abgefragten Strahlen zu unterbrechen, während die TTU 700 die Verarbeitung der Strahlen von einem anderen SM fortsetzen darf, der nicht unterbrochen wird. In anderen Beispielen wäre es dem SM 132 möglich, eine Steuerung mit höherer Granularität bereitzustellen, bei der zum Beispiel der SM 132 seine Verarbeitung Thread für Thread unterbrechen und der TTU 700 befehlen könnte, ihre Arbeit an einem bestimmten Thread zu stoppen. Dies würde eine kompliziertere Schnittstelle bereitstellen und würde erfordern, dass der SM 132 verfolgt, welche ausstehende Strahlverarbeitungsanforderung zu welchem Thread gehört. Es kann effizienter sein, wie oben beschrieben, die SMU 740 innerhalb der TTU 700 verfolgen zu lassen, welche unvollendeten Strahlen zu welchen noch nicht beantworteten Abfragen gehören. Im Falle von Timeout oder Zyklusgrenzen, wie oben beschrieben, kann es in manchen Anwendungen für den SM 132 einfacher sein, der TTU 700 Ziele für jeden Strahl zu liefern und der TTU zu erlauben, alle Strahlen mit ihren zugehörigen Zielen zu verfolgen.
Beispiel-Bilderzeugungs-Pipeline mit Strahlverfolgung
Die oben beschriebenen Strahlverfolgungs- und anderen Fähigkeiten können auf mannigfache Weise genutzt werden. Zum Beispiel können sie nicht nur zum Rendern einer Szene unter Verwendung von Strahlverfolgung genutzt werden, sondern können auch in Kombination mit Abtastsignalwandlungs-Techniken wie z. B. im Kontext der Abtastsignalwandlung von geometrischen Bausteinen (d. h. Polygon-Primitiven wie z. B. Dreiecken) eines 3D-Modells zur Erzeugung eines Bildes zur Anzeige (z. B. auf dem in 1 dargestellten Display 150) implementiert werden. 14 veranschaulicht ein Beispiel-Flussdiagramm für die Verarbeitung von Primitiven, um Bildpixelwerte eines Bildes zu liefern, gemäß einer Ausführungsform.
Wie 14 zeigt, kann als Antwort auf das Empfangen einer Benutzereingabe ein Bild eines 3D-Modells erzeugt werden (Schritt 1652). Die Benutzereingabe kann eine Aufforderung zur Anzeige eines Bildes oder einer Bildsequenz sein, wie z. B. eine Eingabe-Operation, die während Interaktion mit einer Anwendung (z. B. einer Spiel-Anwendung) durchgeführt wird. Als Antwort auf die Benutzereingabe führt das System Abtastsignalwandlung und Rasterung von geometrischen Primitiven des 3D-Modells einer Szene unter Verwendung einer konventionellen GPU-3D-Grafikpipeline durch (Schritt 1654). Die Abtastsignalwandlung und Rasterung von geometrischen Primitiven kann zum Beispiel das Verarbeiten von Primitiven des 3D-Modells umfassen, um Bildpixelwerte unter Verwendung konventioneller Techniken wie z. B. Beleuchtung, Transformationen, Texturabbildung, Rasterung und dergleichen zu bestimmen, wie sie Fachleuten bekannt sind und im Folgenden in Verbindung mit 18 erörtert werden. Die erzeugten Pixeldaten können in einen Bildpuffer geschrieben werden.
In Schritt 1656 können ein oder mehrere Strahlen von einem oder mehreren Punkten auf den gerasterten Primitiven unter Verwendung von TTU-Hardwarebeschleunigung verfolgt werden. Die Strahlen können gemäß einer oder mehreren der in dieser Anmeldung offenbarten Strahlverfolgungs-Fähigkeiten verfolgt werden. Auf Basis der Ergebnisse der Strahlverfolgung können die im Puffer gespeicherten Pixelwerte modifiziert werden (Schritt 1658). Modifizieren der Pixelwerte kann in manchen Anwendungen zum Beispiel die Bildqualität verbessern, indem zum Beispiel realistischere Reflexionen und/oder Schatten angewendet werden. Ein Bild wird unter Verwendung der im Puffer gespeicherten modifizierten Pixelwerte angezeigt (Schritt 1660).
In einem Beispiel können Abtastsignalwandlung und Rasterung von geometrischen Primitiven unter Verwendung des in Bezug auf 15-17, 19, 20, 21 und/oder 22 beschriebenen Verarbeitungssystems implementiert werden, und Strahlverfolgung kann von den SMs 132 unter Verwendung der in Bezug auf 9 beschriebenen TTU-Architektur implementiert werden, um weitere Visualisierungsmerkmale (z. B. Spiegelreflexion, Schatten, usw.) hinzuzufügen. 14 ist nur ein nicht einschränkendes Beispiel - die SMs 132 könnten die beschriebene TTU ohne Texturverarbeitung oder andere konventionelle 3D-Grafikverarbeitung selbst verwenden, um Bilder zu erzeugen, oder die SMs könnten Texturverarbeitung und andere konventionelle 3D-Grafikverarbeitung ohne die beschriebene TTU verwenden, um Bilder zu erzeugen. Die SMs können auch irgendeine gewünschte Bilderzeugung oder andere Funktionalität in Software implementieren, je nach der Anwendung, um irgendeine gewünschte programmierbare Funktionalität bereitzustellen, die nicht an die Hardwarebeschleunigungs-Merkmale gebunden ist, die von Texturabbildungs-Hardware, Baumtraversierungs-Hardware oder anderer Grafikpipeline-Hardware bereitgestellt werden.
Beispiel-Parallelverarbeitungsarchitektur mit Strahlverfolgung
Die oben beschriebene TTU-Struktur kann in oder in Verbindung mit einer nicht einschränkenden Beispiel-Parallelverarbeitungs-Systemarchitektur implementiert werden, wie sie nachfolgend in Bezug auf 15-22 beschrieben ist. Eine derartige Parallelverarbeitungsarchitektur kann zum Beispiel zum Implementieren der GPU 130 von 1 verwendet werden.
Beispiel-Parallelverarbeitungsarchitektur
15 veranschaulicht eine nicht einschränkende Beispiel-Parallelverarbeitungseinheit (PPU) 1700. 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 konfiguriert, 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), einem Gerät mit organischen Leuchtdioden (OLED), einem Gerät mit transparenten Leuchtdioden (TOLED), einem Feldemissions-Display (FED), einem Feldsequenz-Display, einem Projektions-Display, einem am Kopf angebrachten Display oder irgendeinem anderen gewünschten Display 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 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.
Zum Beispiel können eine oder mehrere PPUs 1700 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.
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.
Wie in 15 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 21 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 16 näher beschrieben.
In einer Ausführungsform führt ein Host-Prozessor (z. B. der Prozessor 120 von 1) 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 19 näher beschrieben.
Beispiel-Speicherpartitionseinheit
Die MMU 1890 stellt eine Schnittstelle zwischen dem GPC 1750 und der Partitionseinheit 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.
16 veranschaulicht eine Speicherpartitionseinheit 1780 der PPU 1700 von 15 gemäß einer Ausführungsform. Wie in 16 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 16 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-Allgemeinverarbeitungscluster
17 veranschaulicht ein GPC 1750 der PPU 1700 von 15 gemäß einer Ausführungsform. Wie in 17 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 Speicherverwaltungseinheit (MMU) 1890 und einen oder mehrere Datenverarbeitungs-Cluster (DPCs) 1820. Man beachte, dass der GPC 1750 von 17 anstelle der oder zusätzlich zu den in 17 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-Rendering-Pipeline implementiert.
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 700. Der SM 1840 kann ähnlich wie der oben beschriebene SM 132 strukturiert sein. 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.
Bei Konfiguration für Universal-Parallelberechnung kann eine einfachere Konfiguration im Vergleich zu Grafikverarbeitung verwendet werden. Insbesondere werden die in 15 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.
Grafik-Render-Pipeline
Ein DPC 1820 kann so konfiguriert sein, dass er ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 1840 ausführt, was bestimmte Shading-Operationen mit der TTU 700 beschleunigen kann. 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 eines neuronalen Netzes 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 16 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.
Im Einzelnen ist die PPU 1700 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), zum Beispiel unter Verwendung der TTU 700 als Hardwarebeschleunigungs-Ressource.
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 Modelldaten können auch eine oder mehrere BVHs wie oben beschrieben definieren. 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“ -Shadem; siehe https://devblogs.nvidia.com/introduction-nvidia-rtx-directxray-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 (siehe 16). 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.
18 ist ein Konzeptdiagramm einer mittels der PPU 1700 von 15 implementierten Grafikverarbeitungs-Pipeline 2000. 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 OpenGL®-API definierte Grafikverarbeitungs-Pipeline repräsentieren. Optional kann die Grafikverarbeitungs-Pipeline 2000 im Kontext der Funktionalität und Architektur der vorherigen Figuren und/oder irgendwelcher nachfolgender Figur(en) implementiert werden. Wie oben mit Bezug auf 14 erörtert, kann die Strahlverfolgung zur Verbesserung der durch Rasterung von geometrischen Primitiven erzeugten Bildqualität verwendet werden. In manchen Ausführungsformen können die in dieser Anmeldung offenbarten Strahlverfolgungs-Operationen und TTU-Strukturen auf einen oder mehrere Zustände der Grafikverarbeitungs-Pipeline 2000 angewendet werden, um die subjektive Bildqualität zu verbessern.
Wie in 18 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 120. 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.
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 (d. h. 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.
19 veranschaulicht den Streaming-Multiprozessor 1840 von 17 gemäß einer Ausführungsform. Wie in 19 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, doppelter Genauigkeit und/oder gemischter Genauigkeit 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 Einfachgenauigkeits-(32-Bit)-Gleitkomma-Rechenkerne, 64 Ganzzahl-Rechenkerne, 32 Doppelgenauigkeits-(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 einen Satz von SM-Befehlen zugänglich gemacht, greift als ein Nur-Lese-Client des L1-Cache auf Speicher 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 Stapelinitialisierern 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) 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) 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) 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 Blatt-Begrenzungskasten 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-Begrenzungskasten.

■ 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.
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 Supercomputem 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.
21 ist ein Konzeptdiagramm eines unter Verwendung der PPU 1700 von 15 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 21 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 21 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.
22 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.
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.
Alle oben genannten Patente und Veröffentlichungen werden durch Bezugnahme aufgenommen, als wenn sie ausdrücklich dargelegt wären.
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 9582607 [0016, 0047, 0110]
US 9569559 [0016]
US 20160070820 [0016]
US 20160070767 [0016]
US 14697480 [0109]

Claims

Unterbrechbarer Koprozessor, der eine Vorankommgarantie bietet, umfassend: Begrenzungsvolumenhierarchie-Traversierungsschaltung; und Steuerschaltung, die operativ mit der Begrenzungsvolumenhierarchie-Traversierungsschaltung gekoppelt und die verbunden ist, um ein Präemptionssignal zu empfangen, wobei die Steuerschaltung sicherstellt, dass die Begrenzungsvolumenhierarchie-Traversierungsschaltung vorankommt, bevor sie als Antwort auf Geltendmachung des Präemptionssignals ein weiteres Vorankommen stoppt.
Unterbrechbarer Koprozessor nach Anspruch 1, wobei der unterbrechbare Koprozessor statuslos ist und die Steuerschaltung stapelbasiert ist.
Unterbrechbarer Koprozessor nach Anspruch 1 oder 2, wobei der unterbrechbare Koprozessor ein Vorankommen bestätigt, indem er sicherstellt, dass mindestens eine Operation, die einen Stapel ändert, durchgeführt worden ist oder werden wird.
Unterbrechbarer Koprozessor nach einem der vorhergehenden Ansprüche, wobei der unterbrechbare Koprozessor eine Bit-Anordnung verwendet, um die Traversierung zu verfolgen.
Unterbrechbarer Koprozessor nach einem der vorhergehenden Ansprüche, wobei die Steuerschaltung eine Schlussfolgerung verwendet, dass ein Vorankommen stattgefunden hat.
Unterbrechbarer Koprozessor nach einem der vorhergehenden Ansprüche, wobei die Steuerschaltung eine Schlussfolgerung verwendet, dass eine Stapelmodifizierung stattfinden wird.
Unterbrechbarer Koprozessor nach einem der vorhergehenden Ansprüche, wobei die Steuerschaltung konfiguriert ist, um zu testen, dass ein Vorankommen von einem bestimmten Typ stattgefunden hat.
Unterbrechbarer Koprozessor nach Anspruch 7, wobei der bestimmte Typ die Traversierung von mindestens einem Blattknoten der Begrenzungsvolumenhierarchie umfasst.
Unterbrechbarer Koprozessor nach einem der vorhergehenden Ansprüche, wobei die Steuerschaltung konfiguriert ist, um auf Basis einer Operation, die durch eine Abfrage spezifiziert worden ist und einen bestimmten Schwellenwert erreicht hat, zu testen, ob ein Zähler inkrementiert oder dekrementiert worden ist.
Unterbrechbarer Koprozessor nach einem der vorhergehenden Ansprüche, wobei der unterbrechbare Koprozessor konfiguriert ist, um autonom mit variabler und unvorhersehbarer Latenz beim Traversieren der Begrenzungsvolumenhierarchie zu arbeiten.
Strahlverfolgungsvorrichtung, umfassend: Baumtraversierungshardware; und einen programmierbaren Timeout-Mechanismus, der überwacht, wie sehr ein Strahl die Baumtraversierungshardware verwendet, um einen Graphen zu traversieren, und die Baumtraversierungshardware unterbricht, wenn eine Menge, in der der Strahl die Baumtraversierungshardware verwendet, einen für diesen Strahl programmierbaren Schwellenwert überschreitet.
Strahlverfolgungsvorrichtung nach Anspruch 11, wobei der programmierbare Timeout-Mechanismus arbeitsbasiert ist.
Strahlverfolgungsvorrichtung nach Anspruch 11 oder 12, wobei der programmierbare Timeout-Mechanismus zyklusbasiert ist.
Strahlverfolgungsvorrichtung nach einem der Ansprüche 11 bis 13, wobei der programmierbare Timeout-Mechanismus zeitbasiert ist.
Strahlverfolgungsvorrichtung nach einem der Ansprüche 11 bis 14, wobei der programmierbare Timeout-Mechanismus epochenbasiert ist.
Strahlverfolgungsvorrichtung nach einem der Ansprüche 11 bis 15, wobei der programmierbare Timeout-Mechanismus unterschiedliche Strahlen programmiert, unterschiedliche Schwellenwerte zu haben.
Strahlverfolgungsvorrichtung nach einem der Ansprüche 11 bis 16, wobei der programmierbare Timeout-Mechanismus die Anzahl von bestimmten Traversierungs-Operationen zählt, die die Hardware für den Strahl durchführt.
Strahlverfolgungsvorrichtung nach Anspruch 17, wobei die bestimmten Traversierungs-Operationen Blattknoten-Traversierungen umfassen.
Strahlverfolgungsvorrichtung, umfassend: einen Speicher, der eine Darstellung einer 3D-Szene speichert; eine Traversierungsschaltung, die operativ mit dem Speicher gekoppelt ist, wobei die Traversierungsschaltung konfiguriert ist, um mindestens einen Strahl gegen die Darstellung der 3D-Szene zu verarbeiten; und eine Präemptionsschaltung, die operativ mit der Traversierungsschaltung gekoppelt ist und konfiguriert ist, um sicherzustellen, dass die Traversierungsschaltung beim Verarbeiten des mindestens einen Strahls gegen die 3D-Szene vorankommt, bevor die Traversierungsschaltung unterbrochen wird.
Strahlverfolgungsvorrichtung nach Anspruch 19, die weiterhin mindestens einen mit der Traversierungsschaltung verbundenen Stapel enthält, und wobei die Präemptionsschaltung einen Stapelmanager enthält, der operativ mit dem mindestens einen Stapel gekoppelt ist, wobei der Stapelmanager konfiguriert ist, um sicherzustellen, dass die Traversierungsschaltung den mindestens einen Stapel modifiziert, bevor die Traversierungsschaltung unterbrochen wird.