DE102019103326A1

DE102019103326A1 - Robuste, effiziente multiprozessor-koprozessor-schnittstelle

Info

Publication number: DE102019103326A1
Application number: DE102019103326.8A
Authority: DE
Inventors: Ronald Charles Jr. Babich; John Burgess; Jack Choquette; Tero Karras; Samuli Laine; Ignacio Llamas; Gregory Muthler; William Parsons Jr. Newhall
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2018-08-10
Filing date: 2019-02-11
Publication date: 2020-02-13
Also published as: US20210397449A1; US11966737B2; US11138009B2; US20200050451A1; CN110858387A; CN110858387B; US20240211255A1

Abstract

Bereitgestellt werden Systeme und Verfahren für eine effiziente und robuste Multiprozessor-Koprozessor-Schnittstelle, die zwischen einem Streaming-Multiprozessor und einem Beschleunigungs-Koprozessor in einer GPU verwendet werden kann. Um eine Beschleunigung einer bestimmten Operation unter Verwendung des Koprozessors durchzuführen, gibt gemäß einem Implementierungsbeispiel der Multiprozessor eine Reihe von Schreibanweisungen aus, um Eingabedaten für die Operation in für den Koprozessor zugreifbare Speicherorte zu schreiben, gibt eine Operationsanweisung aus, um den Koprozessor zur Ausführung der bestimmten Operation zu veranlassen, und gibt dann eine Reihe von Leseanweisungen aus, um Ergebnisdaten der Operation von für den Koprozessor zugreifbaren Speicherorten an für den Multiprozessor zugreifbare Speicherorte zu lesen.

Description

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

• 16/101,066 mit dem Titel „Method for Continued Bounding Volume Hierarchy Traversal On Intersection Without Shader Intervention“; eingereicht am 10. August 2018;
• 16/101,109 mit dem Titel „Method for Continued Bounding Volume Hierarchy Traversal On Intersection Without Shader Intervention“; eingereicht am 10. August 2018
• 16/101,180 mit dem Titel „Query-Specific Behavioral Modification of Tree Traversal“, eingereicht am 10. August 2018;
• 16/101,148 mit dem Titel „Conservative Watertight Ray Triangle Intersection“, eingereicht am 10. August 2018;
• 16/101,196 mit dem Titel „Method for Handling Out-of-Order Opaque and Alpha Ray/Primitive Intersections“, eingereicht am 10. August 2018; und
• 16/101,232 mit dem Titel „Method for Forward Progress and Programmable Timeouts of Tree Traversal Mechanisms in Hardware“, eingereicht am 10. August 2018.

Gebiet
Die vorliegende Technik bezieht sich auf Multiprozessor-Koprozessor-Schnittstellen. In einer bestimmten Anwendung bezieht sich die Technik auf Hardwarebeschleunigung von Computergrafikverarbeitung, einschließlich, aber nicht beschränkt auf Strahlverfolgung (engl. Raytracing). Konkreter bezieht sich eine nicht einschränkende Beispiel-Technik hierin auf einen hardwarebasierten Traversierungs-Koprozessor, der eine Beschleunigungsdatenstruktur effizient traversiert, z. B. für Echtzeit-Strahlverfolgung.
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_DanieLHall.pdf
Im Jahr 2010 nutzte NVIDIA dann den hohen Grad an Parallelität von NVIDIA-GPUs und anderen hochparallelen Architekturen für die Entwicklung der OptiX™ Strahlverfolgungs-Engine. Siehe Parker et al., „OptiX: A General Purpose Ray Tracing Engine“ (ACM Transactions on Graphics, Band 29, Nr. 4, Artikel 66, Juli 2010). Neben Verbesserungen bei APIs (Anwendungsprogrammierschnittstellen) war einer der Fortschritte von OptiX™ die Verbesserung der Beschleunigungsdatenstrukturen, die zum Finden eines Schnittpunkts zwischen einem Strahl und der Szenengeometrie verwendet werden. Solche Beschleunigungsdatenstrukturen sind gewöhnlich räumliche oder Objekt-Hierarchien, die vom Strahlverfolgungs-Traversierungsalgorithmus verwendet werden, um effizient nach Primitiven zu suchen, die einen gegebenen Strahl potentiell schneiden. OptiX™ stellt eine Reihe von verschiedenen Beschleunigungsstruktur-Typen zur Verfügung, aus denen die Anwendung wählen kann. Jede Beschleunigungsstruktur im Knotendiagramm kann ein anderer Typ sein, was Kombinationen von hochwertigen statischen Strukturen mit dynamisch aktualisierten Strukturen ermöglicht.
Die programmierbare Strahlverfolgungs-Pipeline OptiX™ brachte erhebliche Fortschritte, war aber an sich immer noch nicht im Stande, interaktive Echtzeit-Reaktionen auf Benutzereingaben auf relativ kostengünstigen Computerplattformen für komplexe 3D-Szenen zu liefern. Seitdem hat NVIDIA Hardwarebeschleunigungsfähigkeiten für Strahlverfolgung entwickelt. Siehe z. B. US 9,582,607 ; US 9,569,559 ; US 20160070820 ; und US 20160070767 .
Angesichts des großen Potenzials eines wirklich interaktiven Echtzeit-Strahlverfolgungs-Grafikverarbeitungssystems zum Rendern hochwertiger Bilder beliebiger Komplexität als Antwort auf zum Beispiel Benutzereingaben ist weitere Arbeit möglich und wünschenswert.
Figurenliste

1 veranschaulicht ein Beispiel für ein nicht einschränkendes Strahlverfolgungs-Grafiksystem.
2A zeigt ein Beispiel für ein spiegelndes Objekt.
2B zeigt das Beispiel-Objekt innerhalb eines Begrenzungsvolumens.
2C zeigt eine volumetrische Beispiel-Unterteilung des Begrenzungsvolumens von 2B.
2D, 2E und 2F zeigen beispielhaft weitere Stufen von volumetrischer Unterteilung des Begrenzungsvolumens zum Erzeugen einer Begrenzungsvolumenhierarchie (BVH).
2G zeigt einen Beispiel-Teil des Objekts, das aus Primitiv-Oberflächen, in diesem Fall Dreiecken, besteht.
3A-3C zeigen beispielhaft vereinfachte Strahlverfolgungs-Tests zum Bestimmen, ob der Strahl ein Begrenzungsvolumen, das Geometrie enthält, durchläuft und ob der Strahl Geometrie schneidet.
4 veranschaulicht ein Beispiel-Strahlverfolgungs-Flussdiagramm.
5A-5C zeigen beispielhaft verschiedene Szenarien für Strahl-Primitiv-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 veranschaulicht einen Beispiel-Prozess, bei dem ein Multiprozessor (z. B. ein Streaming-Multiprozessor einer GPU) eine Multiprozessor-Koprozessor-Schnittstelle verwendet, um eine Ziel-Operation auf einem Koprozessor (z. B. einem Traversierungsbeschleuniger) auszuführen, gemäß manchen Ausführungsbeispielen.
11B veranschaulicht ein Flussdiagramm für einen Prozess, der auf dem Koprozessor als Antwort auf einen Prozess durchgeführt werden kann, der von dem Multiprozessor von 11A durchgeführt wird.
12 zeigt ein Aktivitätsflussdiagramm, das zeitliche Beziehungen zwischen den Anweisungen und durchgeführten Aktionen auf dem Multiprozessor und dem Koprozessor weiter veranschaulicht, wenn die in Bezug auf 11A beschriebene Multianweisungssequenz verwendet wird, gemäß manchen Ausführungsbeispielen.
13 ist ein Flussdiagramm, das Präemption auf Anweisungsebene an einer Multiprozessor-Koprozessor-Schnittstelle veranschaulicht, gemäß manchen Ausführungsbeispielen.
14A ist ein Flussdiagramm eines Prozesses, der eine angepasste Form der in Bezug auf 11A beschriebenen Multianweisungssequenz ausgibt, gemäß manchen Ausführungsbeispielen.
14B und 14C zeigen die Ergebnisausgabe eines Koprozessors für eine Gruppe von Threads, die in Untergruppen-Threads an die Multiprozessor-Register zurückgegeben werden, gemäß manchen Ausführungsbeispielen.
15 zeigt ein System mit einer Schnittstelle zwischen einem Multiprozessor und einem Koprozessor gemäß manchen Ausführungsbeispielen.
16 veranschaulicht ein Beispiel-Flussdiagramm zur Erzeugung eines Bildes.
17 veranschaulicht eine Beispiel-Parallelverarbeitungseinheit (PPU).
18 veranschaulicht eine Beispiel-Speicherpartitionseinheit.
19 veranschaulicht einen Beispiel-Allgemeinverarbeitungscluster (GPC) innerhalb der Parallelverarbeitungseinheit von 17.
20 ist ein Konzeptdiagramm einer mittels des GPC von 19 implementierten Grafikverarbeitungs-Pipeline.
21 und 22 veranschaulichen einen Beispiel-Streaming-Multiprozessor.
23 ist ein Konzeptdiagramm eines unter Verwendung von PPUs von 17 implementierten Verarbeitungssystems.
24 erweitert 23, 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.
Manche 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.
Wie oben erörtert, ermöglicht der Traversierungs-Koprozessor 138 schnelles Traversieren einer Beschleunigungsdatenstruktur (z. B. einer BVH), um zu bestimmen, welche Primitive (z. B. Dreiecke, die zum Erzeugen einer Szene verwendet werden) in der Datenstruktur von einer Abfragedatenstruktur (z. B. einem Strahl) geschnitten werden. Um die große Anzahl von Strahlen und Primitiven zu bewältigen, die in jeder Szene auf Schnittpunkte getestet werden, stellen manche Ausführungsbeispiele eine hocheffiziente und robuste Multiprozessor-Koprozessor-Schnittstelle 160 zwischen dem SM 132 und dem Traversierungs-Koprozessor 138 bereit.
Die Multiprozessor-Koprozessor-Schnittstelle 160 mancher Ausführungsformen ermöglicht es zum Beispiel einem Streaming-Prozessor, Beschleunigungsstruktur-Traversierungen effizient und robust auf dem Traversierungs-Koprozessor durchzuführen, indem eine Reihe von kürzeren Anweisungen anstelle einer einzelnen breiten Anweisung mit zahlreichen Operanden verwendet wird. Die Motivation dafür, keine „einzelne breite Anweisung“ zu verwenden, ist, dass sie eine invasive und aufwändige Änderung an den meisten Prozessor-Designs und insbesondere RISC-Architekturen wäre, die gewöhnlich auf Anweisungen mit fester Länge aufgebaut sind. Manche Ausführungsformen helfen, System-Ineffizienzen zu vermeiden, wie z. B. lange Vollendungszeiten pro Anweisung, die besonders relevant sind, wenn die Operation die Zuweisung von Ressourcen aus einem begrenzten Pool umfasst. Manche Ausführungsformen verbessern die Fähigkeit des Systems, Präemption von Threads auf Anweisungsebene zu implementieren.
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.
Die anfordernde SM 132 verfolgt, welche Objekte sich in Bezug auf jeden einzelnen Strahl vor welchen anderen Objekten befinden, und klärt die Sichtbarkeit in Fällen, in denen ein Objekt ein anderes Objekt verbirgt, einen Schatten auf ein anderes Objekt wirft und/oder Licht auf ein anderes Objekt reflektiert. Die anfordernde SM 132 kann den Traversierungs-Prozessor 138 verwenden, um jeden dieser Tests zu beschleunigen.
Beispiel-Baum-BVH-Beschleunigungsdatenstruktur
8A und 8B zeigen ein rekursiv unterteiltes Begrenzungsvolumen einer 3D-Szene (8A) und eine entsprechende Baumdatenstruktur (8B), auf die der Traversierungs-Koprozessor 138 zugreifen kann und die für hardwarebeschleunigte Operationen verwendet wird, die von dem Traversierungs-Koprozessor durchgeführt werden. Die Unterteilung der Begrenzungsvolumina kann in einer hierarchischen Baumdatenstruktur dargestellt werden, wobei das in 2B gezeigte große Begrenzungsvolumen durch einen Eltern-Knoten des Baums dargestellt wird und die kleineren Begrenzungsvolumina durch Kind-Knoten des Baums dargestellt werden, die von den Eltern-Knoten umfasst sind. Die kleinsten Begrenzungsvolumina werden als Blattknoten im Baum dargestellt und identifizieren ein oder mehrere geometrische Primitive, die in diesen kleinsten Begrenzungsvolumina enthalten sind.
Die Baumdatenstruktur kann in Speicher außerhalb des Traversierungs-Koprozessors 138 gespeichert und auf Basis von Abfragen, die die SMs 132 an den Traversierungs-Koprozessor 138 ausgeben, ausgelesen werden. Die Baumdatenstruktur enthält eine Vielzahl von Knoten, die in einer Hierarchie angeordnet sind. Die Wurzelknoten N1 der Baumstruktur entsprechen dem Begrenzungsvolumen N1, das alle Dreiecke 01-08 einschließt. Der Wurzelknoten N1 kann die Vertices des Begrenzungsvolumens N1 und Kind-Knoten des Wurzelknotens identifizieren.
In 8A ist das Begrenzungsvolumen N1 in Begrenzungsvolumina N2 und N3 unterteilt. Die Kind-Knoten N2 und N3 der Baumstruktur von 8B entsprechen den in 8A gezeigten Begrenzungsvolumina N2 und N3 und stellen sie dar. Die Kind-Knoten N2 und N3 in der Baumdatenstruktur identifizieren die Vertices der jeweiligen Begrenzungsvolumina N2 und N3 im Raum. Jedes der Begrenzungsvolumina N2 und N3 ist in diesem bestimmten Beispiel weiter unterteilt. Das Begrenzungsvolumen N2 ist in enthaltene Begrenzungsvolumina N4 und N5 unterteilt. Das Begrenzungsvolumen N3 ist in enthaltene Begrenzungsvolumina N6 und N7 unterteilt. Das Begrenzungsvolumen N7 enthält zwei Begrenzungsvolumina N8 und N9. Das Begrenzungsvolumen N8 enthält die Dreiecke O7 und OB, und das Begrenzungsvolumen N9 enthält Blatt-Begrenzungsvolumina N10 und N11 als seine Kind-Begrenzungsvolumina. Das Blatt-Begrenzungsvolumen N10 enthält einen Primitiv-Bereich (z. B. Dreieck-Bereich) O10, und das Blatt-Begrenzungsvolumen N11 enthält einen Element-Bereich O9. Jeweilige Kind-Knoten N4, N5, N6, N8, N10 und N11 der Baumstruktur von 8B entsprechen den Begrenzungsvolumina N4, N5, N6, N8, N10 und N11 von 8A im Raum und stellen sie dar.
Der Baum in 8B ist nur drei bis sechs Ebenen tief, so dass die Volumina N4, N5, N6, N8, N10 und N11 „Blattknoten“ bilden - das heißt, Knoten im Baum, die keine Kind-Knoten haben. 8A zeigt, dass jedes der Blattknoten-Begrenzungsvolumina N4, N5, N6 und N8 zwei Dreiecke der Geometrie in der Szene enthält. Zum Beispiel enthält die volumetrische Unterteilung N4 die Dreiecke O1 & O2; die volumetrische Unterteilung N5 enthält die Dreiecke O3 & O4; die volumetrische Unterteilung N6 enthält die Dreiecke O5 & O6; und die volumetrische Unterteilung N8 enthält die Dreiecke O7 & O8. Die in 8B gezeigte Baumstruktur stellt diese Blattknoten N4, N5, N6 und N7 dar, indem sie sie entsprechenden Dreiecken der Dreiecke 01-08 der Szenengeometrie zuordnet. Um auf diese Szenengeometrie zuzugreifen, traversiert der Traversierungs-Koprozessor 138 die Baumdatenstruktur von 8B bis hinab zu den Blattknoten. Im Allgemeinen können und werden unterschiedliche Teile des Baums unterschiedliche Tiefen haben und unterschiedliche Anzahlen von Dreiecken enthalten. Blattknoten, die volumetrischen Unterteilungen zugeordnet sind, die keine Geometrie enthalten, müssen nicht explizit in der Baumdatenstruktur dargestellt werden (d. h., der Baum wird „beschnitten“).
Gemäß manchen Ausführungsformen kann der bei N7 verwurzelte Teilbaum einen Satz von Begrenzungsvolumina oder BVH darstellen, der in einem anderen Koordinatenraum definiert ist als die Begrenzungsvolumina, die den Knoten N1-N3 entsprechen. Wenn sich das Begrenzungsvolumen N7 in einem anderen Koordinatenraum befindet als sein Eltern-Begrenzungsvolumen N3, kann ein Instanzknoten N7', der die Strahltransformation liefert, die notwendig ist, um den bei N7 verwurzelten Teilbaum zu traversieren, den Rest des Baums mit dem bei N7 verwurzelten Teilbaum verbinden. Der Instanzknoten N7' verbindet das Begrenzungsvolumen oder die BVH entsprechend den Knoten N1-N3 mit den Begrenzungsvolumina oder BVH entsprechend den Knoten N7 usw. durch Definieren der Transformation aus Koordinatenraum von N1-N3 (z. B. Welt-Raum) in den Koordinatenraum von N7 usw. (z. B. Objektbereich).
Die interne Struktur und der Betrieb des Traversierungs-Koprozessors 138
9 zeigt ein vereinfachtes Beispiel-Blockdiagramm des Traversierungs-Koprozessors 138 mit Hardware, die konfiguriert ist, um beschleunigte Traversierungsoperationen wie oben beschrieben durchzuführen (eine noch detailliertere Implementierung dieses Traversierungs-Koprozessors 138 wird im Folgenden beschrieben). Da der in 9 gezeigte Traversierungs-Koprozessor 138 zum Traversieren von baumbasierten Beschleunigungsdatenstrukturen wie z. B. in 8A, 8B gezeigt angepasst ist, kann er auch als „Baumtraversierungseinheit“ oder „TTU“ 700 bezeichnet werden (das Bezugszeichen 700 bezieht sich auf die detailliertere nicht einschränkende Implementierung des in 1 gezeigten Traversierungs-Koprozessors 138). Baumtraversierungsoperationen können zum Beispiel umfassen, zu bestimmen, ob ein Strahl Begrenzungsvolumina und/oder Primitive einer Baumdatenstruktur (z. B. ein BVH-Baum) schneidet, welche Tests umfassen können, den Strahl in einen Objekt-Raum zu transformieren.
Die TTU 700 enthält dedizierte Hardware zum Bestimmen, ob ein Strahl Begrenzungsvolumina schneidet, und dedizierte Hardware zum Bestimmen, ob ein Strahl Primitive der Baumdatenstruktur schneidet. In manchen Ausführungsformen kann die TTU 700 eine Traversierung einer Begrenzungsvolumenhierarchie nach Tiefe unter Verwendung einer Kurzstapeltraversierung mit Schnittpunkttesten von unterstützten Blattknoten-Primitiven und Rückgabe von Alpha-Primitiven und nicht unterstützten Blattknoten-Primitiven (Elementen) mitten in der Traversierung durchführen. Der Schnittpunkt der Primitive wird mit Bezug auf Dreiecke diskutiert, doch können auch andere geometrische Primitive verwendet werden.
Insbesondere enthält die TTU 700 einen Schnittpunktverwaltungsblock 722, einen Strahlverwaltungsblock 730 und einen Stapelverwaltungsblock 740. Jeder dieser Blöcke (und alle anderen Blöcke in 9) können dedizierte Hardware bilden, die durch Logikgatter, Register, in Hardware eingebettete Nachschlagtabellen oder andere kombinatorische Logik usw. implementiert wird.
Der Strahlverwaltungsblock 730 ist verantwortlich für die Verwaltung von Informationen über und die Durchführung von Operationen in Bezug auf einen Strahl, der dem Strahlverwaltungsblock von einem SM 132 spezifiziert wird. Der Stapelverwaltungsblock 740 arbeitet in Verbindung mit Traversierungslogik 712, um Informationen über die Traversierung einer BVH-Beschleunigungsdatenstruktur zu verwalten und diesbezügliche Operationen durchzuführen. Die Traversierungslogik 712 wird von Ergebnissen eines Strahl-Complet-Test-Blocks 710 geleitet, der Schnittpunkte zwischen dem vom Strahlverwaltungsblock 730 angezeigten Strahl und durch die BVH dargestellten volumetrischen Unterteilungen testet, wobei nach Bedarf Instanztransformationen verwendet werden. Der Strahl-Complet-Test-Block 710 liest zusätzliche Informationen bezüglich der BVH über einen L0-Complet-Cache 752, der Teil der TTU 700 ist, aus dem Speicher 140 aus. Die Ergebnisse des Strahl-Complet-Test-Blocks 710 informieren die Traversierungslogik 712 darüber, ob weitere rekursive Traversierungen erforderlich sind. Der Stapelverwaltungsblock 740 unterhält Stapel zum Im-Auge-Behalten von Statusinformationen, wenn die Traversierungslogik 712 von einer Ebene der BVH zu einer anderen übergeht, wobei der Stapelverwaltungsblock Elemente auf den Stapel schiebt, wenn die Traversierungslogik tiefer in die BVH traversiert, und Elemente vom Stapel entfernt, wenn die Traversierungslogik nach oben in der BVH traversiert. Der Stapelverwaltungsblock 740 ist im Stande, dem anfordernden SM 132 in jedem Zeitpunkt, in dem sie der SM anfordert, Statusinformationen (z. B. Zwischen- oder Endergebnisse) zur Verfügung zu stellen.
Der Schnittpunktverwaltungsblock 722 verwaltet Informationen über und führt Operationen in Bezug auf Schnittpunkte zwischen Strahlen und Primitiven durch, wobei nach Bedarf Instanztransformationen verwendet werden. Der Strahl-Primitiv-Test-Block 720 liest auf einer bedarfsweisen Basis Informationen in Bezug auf Geometrie über einen L0-Primitiv-Cache 754, der Teil der TTU 700 ist, aus dem Speicher 140 aus. Der Schnittpunktverwaltungsblock 722 wird über Ergebnisse von Schnittpunkttests informiert, die der Strahl-Primitiv-Test- und Transformationsblock 720 durchführt. Somit führt der Strahl-Primitiv-Test- und Transformationsblock 720 Schnittpunktergebnisse dem Schnittpunktverwaltungsblock 722 zu, der Geometrietreffer und Schnittpunkte an den anfordernden SM 132 meldet.
Eine Stapelverwaltungseinheit 740 prüft den Traversierungsstatus, um zu bestimmen, welcher Typ von Daten auszulesen sind und welcher Datenpfad (Complet oder Primitiv) sie verbrauchen wird. Die Schnittpunkte für die Begrenzungsvolumina werden im Strahl-Complet-Testpfad der TTU 700 bestimmt, die einen oder mehrere Strahl-Complet-Testblöcke 710 und einen oder mehrere Traversierungslogikblöcke 712 enthält. Ein Complet spezifiziert Wurzel- oder Innenknoten eines Begrenzungsvolumens. Somit kann ein Complet ein oder mehrere Begrenzungsvolumina für den Strahl-Complet-Test definieren. Der Strahl-Complet-Testpfad der TTU 700 identifiziert, welche Begrenzungsvolumina von dem Strahl geschnitten werden. Von dem Strahl geschnittene Begrenzungsvolumina müssen weiter verarbeitet werden, um zu bestimmen, ob die den geschnittenen Begrenzungsvolumina zugeordneten Primitive geschnitten werden. Die Schnittpunkte für die Primitive werden im Strahl-Primitiv-Testpfad bestimmt, der einen oder mehrere Strahl-Primitiv-Test- und Transformationsblöcke 720 und einen oder mehrere Schnittpunktverwaltungsblöcke 722 enthält.
Die TTU 700 empfängt Abfragen von einem oder mehreren SMs 132, um Baumtraversierungsoperationen durchzuführen. Die Abfrage kann anfordern, ob ein Strahl Begrenzungsvolumina und/oder Primitive in einer BVH-Datenstruktur schneidet. Die Abfrage kann einen Strahl (z. B. Ursprung, Richtung und Länge des Strahls) und eine BVH-Datenstruktur und einen Traversierungsstatus (z. B. Kurzstapel) identifizieren, der einen oder mehrere Einträge enthält, die auf Knoten in einer oder mehreren Begrenzungsvolumenhierarchien verweisen, die der Strahl besuchen soll. Die Abfrage kann auch Informationen darüber enthalten, wie der Strahl mit bestimmten Typen von Schnittpunkten während der Traversierung umgehen soll. Die Strahlinformationen können im Strahlverwaltungsblock 730 gespeichert werden. Die gespeicherten Strahlinformationen (z. B. Strahllänge) können auf Basis der Ergebnisse des Strahl-Primitiv-Tests aktualisiert werden.
Die TTU 700 kann anfordern, dass die in der Abfrage identifizierte BVH-Datenstruktur aus Speicher außerhalb der TTU 700 ausgelesen wird. Ausgelesene Teile der BVH-Datenstruktur können in Level-Null-(L0)-Cache 750 innerhalb der TTU 700 zwischengespeichert werden, so dass die Informationen für andere zeitkohärente TTU-Operationen verfügbar sind, wodurch Zugriffe auf den Speicher 140 reduziert werden. Teile der BVH-Datenstruktur, die für den Strahl-Complet-Test benötigt werden, können in einem L0-Complet-Cache 752 gespeichert werden, und Teile der BVH-Datenstruktur, die für den Strahl-Primitiv-Test benötigt werden, können in einem L0-Primitiv-Cache 754 gespeichert werden.
Nachdem die für einen angeforderten Traversierungsschritt erforderlichen Complet-Informationen im Complet-Cache 752 verfügbar sind, bestimmt der Strahl-Complet-Test-Block 710 die von dem Strahl geschnittenen Begrenzungsvolumina. Beim Durchführen dieses Tests kann der Strahl aus dem Koordinatenraum der Begrenzungsvolumenhierarchie in einen relativ zu einem Complet definierten Koordinatenraum transformiert werden. Der Strahl wird gegen die Begrenzungskästen getestet, die den Kind-Knoten des Complets zugeordnet sind. In dem nicht einschränkenden Ausführungsbeispiel wird der Strahl nicht gegen den eigenen Begrenzungskasten des Complets getestet, da (1) die TTU 700 den Strahl zuvor gegen einen ähnlichen Begrenzungskasten getestet hat, als sie das Eltern-Begrenzungskasten-Kind getestet hat, das auf dieses Complet verwiesen hat, und (2) ein Zweck des Complet-Begrenzungskastens darin besteht, ein lokales Koordinatensystem zu definieren, innerhalb dessen die Kind-Begrenzungskästen in komprimierter Form ausgedrückt werden können. Wenn der Strahl irgendeinen der Kind-Begrenzungskästen schneidet, werden die Ergebnisse an die Traversierungslogik weitergeleitet, um die Reihenfolge zu bestimmen, in der die entsprechenden Kind-Zeiger dann auf den Traversierungsstapel geschoben werden (weiteres Testen erfordert wahrscheinlich, dass die Traversierungslogik 712 zu der nächsten Ebene der BVH hinunter traversiert). Diese Schritte werden rekursiv wiederholt, bis geschnittene Blattknoten der BVH angetroffen werden.
Der Strahl-Complet-Test-Block 710 kann der Traversierungslogik 612 Strahl-Complet-Schnittpunkte zuführen. Unter Verwendung der Ergebnisse des Strahl-Complet-Tests erstellt die Traversierungslogik 712 Stapeleinträge, die an den Stapelverwaltungsblock 740 weiterzuleiten sind. Die Stapeleinträge können interne Knoten (d. h. einen Knoten, der einen oder mehrere Kind-Knoten enthält), die durch den Strahl-Complet-Test-Block 710 weiter auf Strahlschnittpunkte getestet werden müssen, und/oder in einem geschnittenen Blattknoten identifizierte Dreiecke anzeigen, die durch den Strahl-Primitiv-Test- und Transformationsblock 720 auf Strahlschnittpunkte getestet werden müssen. Der Strahl-Complet-Test-Block 710 kann die Traversierung auf im Stapel identifizierten internen Knoten wiederholen, um alle Blattknoten in der BVH zu bestimmen, die der Strahl schneidet. Die genauen Tests, die der Strahl-Complet-Test-Block 710 durchführt, werden in dem nicht einschränkenden Ausführungsbeispiel durch Modus-Bits, Strahloperationen (siehe unten) und Culling von Treffern bestimmt, und die TTU 700 kann Zwischen- sowie Endergebnisse an den SM 132 zurückgeben.
Die geschnittenen Blattknoten identifizieren Primitive, die von dem Strahl geschnitten werden können oder nicht. Eine Option für die TTU 700 ist, z. B. einen Bereich von in den geschnittenen Blattknoten identifizierten Geometrien dem SM 132 für weitere Verarbeitung zuzuführen. Zum Beispiel kann der SM 132 auf Basis der Informationen, die die TTU 700 als Ergebnis der die BVH traversierenden TTU liefert, selbst bestimmen, ob die identifizierten Primitive von dem Strahl geschnitten werden. Um den SM 132 von dieser Verarbeitung zu entlasten und ihn dadurch unter Verwendung der Hardware der TTU 700 zu beschleunigen, kann der Stapelverwaltungsblock 740 Anforderungen an den Strahl-Primitiv- und Transformationsblock 720 ausgeben, einen Strahl-Primitiv-Test für die Primitive innerhalb geschnittener Blattknoten durchzuführen, die der Strahl-Complet-Test-Block 710 der TTU identifiziert hat. In manchen Ausführungsformen kann der SM 132 eine Anforderung nach dem Strahl-Primitiv-Test zum Testen eines bestimmten Bereichs von Primitiven an den Transformationsblock 720 ausgeben, unabhängig davon, wie dieser Geometriebereich identifiziert worden ist.
Nachdem sichergestellt ist, dass die für einen angeforderten Strahl-Primitiv-Test benötigten Primitiv-Daten im Primitiv-Cache 754 verfügbar sind, kann der Strahl-Primitiv- und Transformationsblock 710 unter Verwendung der im Strahlverwaltungsblock 730 gespeicherten Strahlinformationen Primitive bestimmen, die von dem Strahl geschnitten werden. Der Strahl-Primitiv-Test-Block 720 führt die Identifizierung von Primitiven, die als von dem Strahl geschnitten bestimmt worden sind, dem Schnittpunktverwaltungsblock 722 zu.
Der Schnittpunktverwaltungsblock 722 kann die Ergebnisse des Strahl-Primitiv-Tests an den SM 132 zurückgeben. Die Ergebnisse des Strahl-Primitiv-Tests können Identifikatoren von geschnittenen Primitiven, die Entfernung von Schnittpunkten vom Strahlursprung und andere Informationen über Eigenschaften der geschnittenen Primitiven umfassen. In manchen Ausführungsformen kann der Schnittpunktverwaltungsblock 722 einen vorhandenen Strahl-Primitiv-Test auf Basis von früheren Schnittpunktergebnissen von dem Strahl-Primitiv- und Transformationsblock 710 modifizieren (z. B. durch Modifizieren der Länge des Strahls).
Der Schnittpunktverwaltungsblock 722 kann auch verschiedene Typen von Primitiven im Auge behalten. Zum Beispiel umfassen die verschiedenen Typen von Dreiecken opake Dreiecke, die einen Strahl blockieren, wenn sie geschnitten werden, und Alpha-Dreiecke, die den Strahl blockieren können oder nicht, wenn sie geschnitten werden, oder zusätzliche Behandlung durch den SM erfordern können. Ob ein Strahl durch ein transparentes Dreieck blockiert wird oder nicht, kann zum Beispiel von auf das Dreieck abgebildeten Textur(en), der von der Textur eingenommene Fläche des Dreiecks (siehe 6A und 6B) und der Art und Weise abhängen, in der die Textur das Dreieck modifiziert. Zum Beispiel erfordert Transparenz (z. B. Buntglas) in manchen Ausführungsformen, dass der SM 132 Treffer von transparenten Objekten im Auge behält, so dass sie in strahlparametrischer Reihenfolge sortiert und schattiert werden können, und blockiert den Strahl typischerweise nicht wirklich. Indessen ermöglicht Alpha-„Beschneiden“ das Beschneiden der Form des Primitivs auf Basis der Form einer auf das Primitiv abgebildeten Textur - zum Beispiel Ausschneiden einer Blattform aus einem Dreieck. (Man beachte, dass bei Rastergrafik Transparenz oft als „Alpha Blending“ und Beschneiden als „Alpha-Test“ bezeichnet wird). In anderen Ausführungsformen kann die TTU 700 transparente Treffer für spätere Behandlung durch den SM 132 in Warteschlangen in Speicher schieben und beschnittene Dreiecke direkt behandeln, indem sie Anforderungen an die Textureinheit sendet. Jedes Dreieck kann eine Kennung zum Anzeigen des Dreieck-Typs enthalten. Der Schnittpunktverwaltungsblock 722 ist konfiguriert, um eine Ergebniswarteschlange zum Verfolgen der verschiedenen Typen von geschnittenen Dreiecken zu unterhalten. Zum Beispiel kann die Ergebniswarteschlange eine oder mehrere 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 Entfemung), 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.
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 „Bottom“-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.
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. 16/101,148 mit dem Titel „Conservative Watertight Ray Triangle Intersection“, der US-Anmeldung Nr. 16/101,066 mit dem Titel „Method for Continued Bounding Volume Hierarchy Traversal on Intersection without Shader Intervention“ und der US-Anmeldung Nr. 16/101,066 mit dem Titel „Method for Handling Out-of-Order Opaque and Alpha Ray/Primitive Intersections“, die hiermit in ihrer Gesamtheit durch Bezugnahme aufgenommen werden.
Obwohl die obige Offenbarung in den speziellen Kontext von Computergrafik und Visualisierung eingebettet ist, könnten Strahlverfolgung und der offenbarte Traversierungs-Koprozessor für mannigfache Anwendungen jenseits von Grafik und Visualisierung eingesetzt werden. Nicht einschränkende Beispiele umfassen Schallausbreitung für realistische Klangsynthese, die Simulation von Sonarsystemen, Design optischer Elemente und Systeme, Partikeltransportsimulation (z. B. für Medizinphysik oder experimentelle Hochenergiephysik), allgemeine Wellenausbreitungssimulation, Vergleich mit LIDAR-Daten für Zwecke z. B. der Roboter- oder Fahrzeuglokalisierung und andere. Für einige dieser Anwendungsgebiete hat man OptiX™ bereits in der Vergangenheit genutzt.
Beispiel-Multiprozessor-Koprozessor-Schnittstelle
Ein Aspekt der TTU-700-Beschleunigung der vom SM 132 durchgeführten Strahlverfolgungs-Shading-Pipeline 900, wie oben beschrieben, ist die Beschleunigung der Schnittpunkt-Erkennung zwischen Strahlen und BVHs als Antwort auf TTU-Abfragen, die der SM 132 getätigt hat. Die TTU 700 empfängt Strahlinformationen und eine BVH (oder einen Teil einer BVH) zum Schnittpunkttesten vom SM 132. Die Anweisung, die die TTU 700 veranlasst, die beschleunigte Schnittpunkt-Erkennung durchzuführen („TTU-Abfrage“), erfordert möglicherweise viele Operanden, um die Strahlinformationen und die BVH-Informationen für die TTU 700 zu spezifizieren. Zum Beispiel umfasst in einer Ausführungsform die der TTU 700 für die beschleunigte Schnittpunkt-Erkennung gelieferte Eingabe einen Strahl, der unter Verwendung von 8 Gleitkommazahlen (z. B. Strahl-Ursprung und -Richtung, die jeweils 3 Gleitkommazahlen erfordern, und Strahl-Start- und -Endpositionen, die jeweils 1 Gleitkommazahl erfordern) und einen Stapel, der mit dem Äquivalent von 8 Gleitkommazahlen (z. B. 1-8 Stapeleinträge) spezifiziert ist, mit insgesamt mindestens 16 Gleitkommazahlen. Die entsprechende Ergebnisausgabe der TTU 700 enthält mindestens einen Identifizierer für jedes geschnittene Primitiv/Element und einen t-Wert (z. B. aktuelle Länge des Strahls), die jeweils 1 Gleitkommazahl erfordern, Koordinaten jedes Schnittpunkts, die 2 Gleitkommazahlen erfordern, und den aktualisierten Stapel, der das Äquivalent von 8 Gleitkommazahlen erfordert, mit insgesamt mindestens 12 Gleitkommazahlen. Darüber hinaus erfordern es möglicherweise manche konfigurierbare Kontrollen über die von der TTU 700 durchgeführte BVH-Traversierung, wie zum Beispiel in der US-Anmeldung Nr. 16/101,180 mit dem Titel „Query-Specific Behavioral Modification of Tree Traversal“ beschrieben, weitere zusätzliche Eingabeparameter in der Anweisung zu spezifizieren, die die TTU 700 veranlasst, die beschleunigte Schnittpunkt-Erkennung durchzuführen. Auf diese Weise erfordert eine Beispiel-TTU-Abfrageanweisung möglicherweise, eine große Anzahl (z. B. mehr als 4) von Operanden zu spezifizieren, wobei manche typische Anweisungen möglicherweise einen Opcode, der die durchzuführende Operation identifiziert, und 2-4 Operanden (z. B. Soforts, Registeridentifikatoren und/oder Speicheradressen), die Ein-/Ausgabeparameter spezifizieren, enthalten.
Im Idealfall würde eine TTU-Abfrage zum Bestimmen von Strahl-BVH-Schnittpunkten auf der TTU 700 mit einer einzelnen Anweisung initiiert, die mehrere Zielregister („Rd0“ usw.), mehrere Quellenregister („Rs0“ usw.) und einen Anforderungsspezifierer („Imm“) als ein Sofort enthält: „TTU Rd0, Rd1, Rd2, ...., Rs0, Rs1, Rs2, ...., Imm“. Aber dies ist bei vielen Systemen nicht praktikabel, da es möglicherweise keinen Platz in der Anweisungscodierung gibt, um die vielen Register unterzubringen, die benötigt werden, um die benötigte Ein- und Ausgabe vollständig zu spezifizieren. Darüber hinaus ist die Anzahl der Register, die in der Anweisung spezifiziert werden müssen, möglicherweise variabel.
Das Unterbringen von Anweisungen, die eine große Anzahl von Operanden enthalten, kann zu Ineffizienzen in einem System führen. Breite Kommunikationswege, große Warteschlangen und lange Zeitdauern zwischen Anweisungen sind einige der Gründe für potentielle Ineffizienzen. Zum Beispiel können Kommunikationspfade zwischen Prozessoren und/oder zwischen einem Prozessor und einem Speicher speziell zum Unterbringen von breiten Anweisungen ausgelegt sein, wobei solche breiten Kommunikationspfade breiter sein können als für die meisten Anweisungen erforderlich. Anweisungswarteschlangen/Puffer können erhebliche Mengen an Speicher erfordern. Zusätzlich sind viele Multiprozessoren RISC-basiert und haben relativ schmale Anweisungen mit fester Größe. Darüber hinaus kann eine hohe Anzahl von Ein- und Ausgabeparametern in einer Anweisung zu relativ langen Vollendungszeiten pro Anweisung führen, was zumindest teilweise auf eine große Anzahl von Speicher- und Ladevorgängen zurückzuführen ist und dadurch die Fähigkeit des Systems einschränkt, Präemption von Threads auf Anweisungsebene zu implementieren.
In Ausführungsbeispielen werden, statt eine einzelne breite Anweisung zu verwenden, um die TTU 700 eine Abfragetraversierung einer BVH ausführen zu lassen, Verfahren und Systeme bereitgestellt, durch die eine entsprechende Sequenz von schmaleren Anweisungen verwendet werden kann, um der TTU 700 zu befehlen, die Traversierung auszuführen. Obwohl in diesem Dokument in erster Linie die entsprechenden Anweisungssequenzen in Bezug auf die Schnittstelle zwischen SM 132 und TTU 700 beschrieben werden, sind die Lehren in Bezug auf die Anweisungssequenzen auch auf Schnittstellen zwischen anderen Multiprozessoren und Koprozessoren anwendbar. Darüber hinaus ist die Art der Koprozessor-Operation, die durch eine Sequenz von Anweisungen gemäß Ausführungsformen erleichtert wird, nicht auf Traversierungen einer BVH beschränkt und kann irgendeine Art von Operation umfassen, für deren Durchführung ein Koprozessor konfiguriert ist. Somit umfassen Ausführungsbeispiele eine Multianweisungssequenz von schmaleren Anweisungen (z. B. Anweisungen mit 2-4 Operanden) zum Befehlen einer Koprozessor-Operation als eine Alternative zu einer einzelnen breiteren Anweisung (z. B. Anweisungen mit mehr als 4 Operanden) zum Befehlen derselben Koprozessor-Operation.
Ein „Multiprozessor“, wie in diesem Dokument verwendet, ist ein Prozessor, der in der Lage ist, einen mikroarchitektonischen Status für mehrere gleichzeitige Ausführungs-Threads aufrechtzuerhalten, unabhängig von der Organisation oder Anzahl der Ausführungseinheiten. Beispiel-Multiprozessoren können Mehrkern-CPUs mit oder ohne Unterstützung für Simultan-Multithreading (SMT), Einzelkern-CPUs mit Unterstützung für SMT sowie individuelle Multiprozessoren in Parallelverarbeitungseinheiten (z. B. SMs in NVIDIA-GPUs) enthalten. Jeder SM in einer NVIDIA-GPU kann zum Beispiel einen mikroarchitektonischen Status für zig Warps und/oder Hunderte von gleichzeitigen Threads aufrechterhalten.
Ein Multiprozessor kann mannigfache Operationen unterschiedlicher Arten für Arithmetik, Steuerungsfluss, Datenbewegung usw. unterstützen, jeweils zugänglich über eine Anweisung im Anweisungssatz des Multiprozessors. Die hierin beschriebenen Ausführungsformen betreffen in erster Linie Operationen, die aus einem oder mehreren Gründen, wie zum Beispiel den Folgenden, aber nicht darauf beschränkt, nicht praktikabel über eine einzelne Anweisung zugänglich sind: (1) die Operation nimmt ihre Eingabe aus Registern oder anderen Speicherorten, benötigt aber eine große Menge von Eingaben, für die die Registernamen oder Speicheradressen nicht in einer einzelnen Anweisung codiert werden können, (2) die Operation erzeugt eine Ausgabe in Registern oder anderen Speicherorten, erzeugt aber eine große Menge Ausgaben, für die die Registernamen oder Speicheradressen nicht in einer einzelnen Anweisung codiert werden können, und (3) die Operation benötigt Ausführungsressourcen, die begrenzt sind, und hat eine so hohe Latenz, dass sich das Zugänglichmachen der Operation als eine einzelne Anweisung negativ auf die erzielbare Leistung auswirken würde oder ein Anweisungs-Scheduling erschweren würde. Zum Beispiel reichen in Bezug auf (1) und (2) oben die unterstützten Anweisungsbreiten in der Multiprozessor-Anweisungssatz-Architektur (ISA) möglicherweise nicht aus, um die erforderliche Anzahl von Eingangsregistern und/oder Ausgangsregistern als Operanden für die Operation zu codieren. Die Breite einer Anweisung, wie hierin verwendet, bezieht sich auf die Anzahl der Bits, die zum Codieren der Anweisung erforderlich sind, d. h. schmale Anweisungen erfordern im Vergleich zu breiten Anweisungen weniger Bits zum Codieren.
Die Hardware-Einheit, die eine solche Operation implementiert/ausführt, wird hierin als „Koprozessor“ bezeichnet, unabhängig davon, wie sehr sie in den Multiprozessor integriert ist. Viele nachfolgende Ausführungsformen werden in Bezug auf eine TTU 700 beschrieben, die als ein Koprozessor des SM 132 arbeitet, unter anderem durch Beschleunigen des BVH-Traversierungsprozesses für die SMs. Es ist jedoch nicht erforderlich, dass der Koprozessor eine TTU ist oder sogar dass der Koprozessor in ähnlichem Maße unabhängig von dem Multiprozessor ist wie die TTU 700 unabhängig von dem SM 132. Zum Beispiel, obwohl die TTU 700 im Wesentlichen unabhängig von dem SM 132 ist, da die TTU 700 viele Arten von Strahl-BVH-Schnittpunkten ohne weitere Kommunikation mit dem SM 132 nach Empfang der Strahl- und BVH-Informationen erkennen kann, sind die Multiprozessoren und Koprozessoren in Ausführungsbeispielen nicht auf irgendeine bestimmte Ebene der Kommunikation zwischen dem Multiprozessor und dem Koprozessor während der Ausführung der Koprozessor-Operation beschränkt.
Die hierin beschriebenen Ausführungsformen umfassen eine oder mehrere von drei Techniken, um mindestens einen Teil einer Multiprozessor-Koprozessor-Schnittstelle bereitzustellen. In manchen Ausführungsformen können die Techniken einen Teil der ISA einer GPU oder einer anderen PPU bereitstellen, um eine Schnittstellenverbindung eines Koprozessors wie z. B. der TTU mit dem SM der GPU herzustellen. Zwar wird die Multiprozessor-Koprozessor-Schnittstelle gemäß Ausführungsformen in diesem Dokument in erster Linie im Kontext der Schnittstellenverbindung der TTU mit dem SM in einer GPU beschrieben, doch sind die Lehren nicht darauf beschränkt und sind allgemeiner auf viele andere Arten von Multiprozessor-Koprozessor-Schnittstellen anwendbar.
Die drei allgemein beschriebenen Techniken umfassen: (1) programmtechnisches Initiieren einer Koprozessor-Abfrage unter Verwendung einer Multianweisungssequenz in einer Weise, die mehrere nicht-triviale Anforderungen erfüllt, (2) einen Mechanismus zum Fusionieren der Sequenz von Anweisungen, die eine Koprozessor-Abfrage bilden, zu einer einzelnen „Makroanweisung“, die garantiert ohne Unterbrechung auszuführen ist, und (3) eine Optimierung, die es erlaubt, eine Teilmenge der für eine gegebene Abfrage reservierten Koprozessor-Ressourcen freizugeben, bevor die gesamte Abfrage vollendet ist. Die Technik (1) ermöglicht es dem Multiprozessor, mit dem Koprozessor unter Verwendung einer Multianweisungssequenz zu interagieren, ohne dass breite Anweisungen mit zahlreichen Operanden erforderlich sind, die Technik (2) modifiziert die Multianweisungssequenz so, dass die Präemption auf Multiprozessor-Anweisungsebene effizienter gemacht wird, und die Technik (3) verbessert die Geschwindigkeit der Verarbeitung und Nutzung von Koprozessor-Ressourcen.
Multianweisungssequenz für Koprozessor-Operation
Manche Ausführungsbeispiele stellen eine Multianweisungssequenz von schmaleren Anweisungen bereit, um einen Koprozessor zur Durchführung einer bestimmten Operation zu veranlassen, die in einem System, das sehr breite Anweisungen unterbringt, durch eine einzelne breite Anweisung mit vielen Operanden veranlasst worden sein kann. Wie oben erwähnt, wird in Ausführungsbeispielen die relativ große Anzahl von Eingangs- und/oder Ausgangsregistern und/oder Speicheradressen, die für die effiziente Ausführung mancher Multiprozessor-Operationen erforderlich sind, dem Koprozessor durch viele Schreibanweisungen (auch als „Speicheranweisungen“ bezeichnet) und Leseanweisungen (auch als „Ladeanweisungen“ bezeichnet) vor bzw. nach der Operation bereitgestellt.
Die Multianweisungssequenz gemäß Ausführungsformen umfasst mehrere Anweisungen, die Teil der Anweisungssatz-Architektur des Multiprozessors sind, einschließlich Anweisungen zum Öffnen/Schließen der Koprozessor-Verbindung (z. B. „CP_OPEN“/ „CP_CLOSE“), eine Koprozessor-Warteanweisung (z. B. „CP_WAIT“), eine Anweisung, in den Koprozessor zu schreiben (z. B. „CP_WRITE“), eine Anweisung, vom Koprozessor zu lesen (z. B. „CP_READ“) und eine Koprozessor-Befehlsanweisung (z. B. „CP_COMMAND“). Der Fachmann erkennt, dass die hier verwendeten Namen, Bezeichnungen und Opcodes usw. nur Beispiele sind und die Ausführungsformen nicht beschränken.
11 A veranschaulicht einen Beispiel-Prozess 1100, bei dem ein Multiprozessor eine Multianweisungssequenz gemäß einem Ausführungsbeispiel verwendet, um eine Ziel-Operation auf einem Koprozessor auszuführen. Der mit dem Multiprozessor verbundene Koprozessor führt die Ziel-Operation und einen weiteren Prozess, der im Folgenden als Prozess 1120 beschrieben wird, als Antwort auf den Prozess 1100 aus. Gemäß manchen Ausführungsformen können ein Multiprozessor wie z. B. der Multiprozessor 1502 und ein Koprozessor wie z. B. der Koprozessor 1504 den Prozess 1100 bzw. 1120 ausführen.
In manchen Ausführungsbeispielen können der SM 132 und die TTU 700 den Prozess 1100 bzw. den Prozess 1120 ausführen. Zum Beispiel kann in einer Echtzeit-Strahlverfolgungs-Anwendung, wie sie oben in Bezug auf 1 beschrieben ist, eine Anwendung, die auf der CPU 120 ausgeführt wird, eine Strahlverfolgungs-Abfrage oder eine ähnliche Anforderung an die GPU 130 unter Verwendung einer Multianweisungssequenz der oben beschriebenen schmalen Anweisungen bilden. Innerhalb der GPU 130 kann die Multianweisungssequenz auf dem SM 132 ausgeführt werden, wobei der SM 132 die TTU 700 veranlasst, das Abfragen einer BVH in Übereinstimmung mit der Multianweisungssequenz durchzuführen.
Die im Prozess 1100 verwendete Beispiel-Multianweisungssequenz kann wie folgt sein:


 CP_OPEN
 CP_WAIT
 CP_WRITE cp[0x100] R2, R3
 CP_WRITE cp[0x208] R4, R5
 CP_WRITE cp[0x300] R10, R11
 CP_COMMAND 0x1
 CP_READ R12, R13, cp[0x400] &release_when_complete(sb0) 

 CP_READ R16, R17, cp[0x460] &release_when_complete(sb1)
 CP_CLOSE
 # ...
 # ... (optionale beliebige dazwischen liegende Anweisungen)
 # ...
 WAIT_ON_SCOREBOARD sb0
 WAIT_ON_SCOREBOARD sb1
 # Verbrauche Ergebnisse (z. B. Speichern von Ergebnissen in Speicher):
 STORE [R7], R12
 # ...

Im Schritt 1102 beginnt der Multiprozessor nach Eintritt in den Prozess 1100 mit der Ausgabe von Anweisungen der obigen Multianweisungssequenz, um eine bestimmte Ziel-Operation (z. B. eine vorbestimmte Operation, für deren Ausführung der Koprozessor konfiguriert ist; z. B. eine oben beschriebene TTU-Abfrage) auf dem Koprozessor im Namen eines bestimmten Threads oder einer Gruppe von Threads (z. B. einem Warp), wie auf dem SM geplant, auszuführen. Im Schritt 1102 fordert der Multiprozessor eine Verbindung zum Koprozessor an, indem er zum Beispiel eine Verbindung-Öffnen-Anweisung (z. B. CP_OPEN) ausgibt. Die Anforderung kann für einen oder mehrere Threads auf dem Multiprozessor erfolgen. In manchen Ausführungsformen erfolgt die Anforderung für eine Gruppe von Threads (z. B. ein Warp) entsprechend den aktiven SIMD-Lanes im Multiprozessor.

Eine „Verbindung“ im Kontext der Multiprozessor-Koprozessor-Schnittstelle ist eine Sitzung, während der einige Ressourcen für Verwendung im Dienst der bestimmten Ziel-Operation reserviert sind, für die die Verbindung hergestellt worden ist. Zum Beispiel kann der Koprozessor bei Empfang einer Verbindungsanforderung Ressourcen wie z. B. Speicher, einen oder mehrere Ausführungs-Slots auf der Koprozessor-Verarbeitungs-Pipeline usw. reservieren. Die Ressourcen, und wie viel von einer Ressource zu reservieren ist, kann implementierungsspezifisch sein und kann vom Koprozessor auf Basis von vorbestimmten Informationen (z. B. vorkonfigurierten Informationen für jeden Thread in der Thread-Gruppe) oder auf Basis von einem oder mehreren mit der Verbindung-Öffnen-Anforderung spezifizierten Operanden bestimmt werden.

Im Schritt 1104 sperrt der Multiprozessor, bis die Verbindung-Öffnen-Anforderung vom Koprozessor beantwortet wird. Zum Beispiel gibt der Multiprozessor eine Anweisung (z. B. CP_WAIT in der obigen Sequenz) aus, den bzw. die anfordernden Thread(s) zu sperren, bis der Verbindungsaufbau vollendet ist. Somit kann der Multiprozessor nach CP_OPEN erst dann weitere Operationen zum Ausführen der bestimmten Ziel-Operation verarbeiten, nachdem die für die Verbindung benötigten Ressourcen im Koprozessor erworben und/oder reserviert worden sind und er benachrichtigt worden ist, dass der Verbindungsaufbau vollendet ist.

Im Schritt 1106 werden eine oder mehrere Schreibanweisungen (z. B. CP_WRITE) ausgegeben, die Eingabedaten von dem Multiprozessor in Speicher und/oder Register schreiben, der bzw. die für den Koprozessor zugreifbar sind. Die Quellendaten für das CP_WRITE können aus Multiprozessor-Registern und/oder aus einem Speicher stammen. Das Ziel für das CP_WRITE kann interner Speicher des Koprozessors, Register des Koprozessors und/oder anderer Speicher sein, der für den Koprozessor zugreifbar ist. Die Eingabedaten umfassen die für die bestimmte Operation erforderlichen Daten und in manchen Ausführungsformen möglicherweise nur diese. Das heißt, zumindest in manchen Ausführungsformen sind die durch die eine oder mehrere Schreibanweisungen spezifizierten Eingabedaten kollektiv der gesamte Satz von Eingabedaten, der von der bestimmten Ziel-Operation verwendet wird, die auf dem Koprozessor ausgeführt wird.

Im Schritt 1108 wird eine Befehlsanweisung (z. B. CP_COMMAND) ausgegeben, um den Koprozessor zu veranlassen, die bestimmte Ziel-Operation durchzuführen. In manchen Ausführungsformen enthält die Befehlsanweisung möglicherweise keine Operanden, wie z. B. wenn der Koprozessor ein spezialisierter Prozessor ist, der konfiguriert ist, nur eine einzelne Koprozessor-Operation auszuführen (z. B. nur eine Abfrage zum Erkennen von Strahl-BVH-Schnittpunkten), und daher kann irgendein Aufruf an den Koprozessor als eine Aufforderung zum Ausführen der einzelnen Ziel-Operation interpretiert werden. In manchen Ausführungsformen kann ein Operand (z. B. ein Sofort) spezifiziert werden, der eine von mehreren vordefinierten, vom Koprozessor ausführbaren Operationen identifiziert.

Im Schritt 1110 werden eine oder mehrere Leseanweisungen (z. B. CP_READ) ausgegeben, um die Ergebnisdaten aus der vom Koprozessor durchgeführten Ziel-Operation zu lesen. Die Leseanweisungen kopieren die Ergebnisdaten aus dem bzw. den für den Koprozessor zugreifbaren Speicher und/oder Registern in Multiprozessor-Register und/oder -Speicher. Gemäß manchen Ausführungsformen umfassen die eine oder mehreren Leseanweisungen kollektiv die Gesamtheit der Ergebnisdaten, die vom Koprozessor an den Multiprozessor geliefert werden.

Da die Multianweisungssequenz konfiguriert ist, nur bei Verbindungsaufbau zu sperren, können die Anweisungen in der Multianweisungssequenz nach der Verbindung-Öffnen-Anweisung bis zu und einschließlich einer Verbindung-Schließen-Anweisung von dem Multiprozessor direkt hintereinander ausgegeben werden (d. h. Ausgeben der Anweisung, ohne darauf zu warten, dass eine vorher ausgegebene Anweisung vollendet ist). Obwohl eine solche Direkt-Hintereinander-Ausgabe die Ausführungsgeschwindigkeit erhöhen kann, kann sie auch dazu führen, dass die Leseanweisungen vom Koprozessor empfangen werden, bevor die durch die Befehlsanweisung initiierte bestimmte Koprozessor-Operation vollendet (d. h., die Koprozessor-Operation noch im Fluge) ist, und somit bevor die Ergebnisdaten überhaupt verfügbar sind, um zu dem Multiprozessor herausgeschrieben zu werden.

Dementsprechend kann jede der Leseanweisungen einen Scoreboard-Eintrag (oder eine andere ähnliche Technik) konfigurieren, um ein Signal an den Multiprozessor zu erzeugen, wenn die Ergebnisdaten tatsächlich zu dem Multiprozessor geschrieben werden.

Scoreboarding ist ein Beispiel für eine Technik, die verwendet werden kann, um zu überwachen, wann das der Leseanweisung zugeordnete Datenschreiben durchgeführt werden kann, und Ausführungsformen sind nicht darauf beschränkt. Scoreboarding ist eine bekannte Technik, die früher in Geräten wie z. B. dem Computer CDC 6600 zur Ausführung von Anweisungen eingesetzt wurde. Ein Scoreboard kann konfiguriert sein, um die Datenabhängigkeiten einer jeden Anweisung zu verfolgen, und gibt eine Anweisung frei, wenn bestimmt wird, dass keine Konflikte mit vorher ausgegebenen und noch unvollendeten Anweisungen bestehen. In Ausführungsbeispielen kann jede Leseanweisung einen jeweiligen Scoreboard-Eintrag konfigurieren, so dass die Verfügbarkeit der zu dem Multiprozessor zu schreibenden Ergebnisdaten überwacht werden kann, bevor die Daten tatsächlich vom Quellenort in dem bzw. den für den Koprozessor zugreifbaren Speicher und/oder Registern in Multiprozessor-Speicher und/oder - Register kopiert werden.

Im Schritt 1112, nachdem die eine oder mehreren Leseanweisungen ausgegeben worden sind, gibt der Multiprozessor eine Verbindung-Schließen-Anweisung aus. Das Verbindung-Schließen bewirkt, dass der Multiprozessor die Verbindung zum Koprozessor schließt, da die bestimmte Operation in diesem Zeitpunkt vollständig spezifiziert worden ist.

Zwischen den Schritten 1112 und 1114 kann der Multiprozessor optional eine oder mehrere weitere Anweisungen ausgeben. Diese Fähigkeit ermöglicht es dem Thread oder der Thread-Gruppe des Multiprozessors, die Verarbeitung oder andere Operationen weiter durchzuführen, während der Koprozessor die bestimmte Operation ausführt, wie vom Multiprozessor befohlen. In manchen Ausführungsformen kann zwischen den Schritten 1112 und 1114 eine weitere Multianweisungssequenz für eine bestimmte Koprozessor-Ziel-Operation ausgegeben werden. Diese Fähigkeit, eine andere Verarbeitung weiter durchzuführen, bevor die Ergebnisse von einer früher ausgegebenen Koprozessor-Ziel-Operation empfangen werden, verbessert die Effizienz und das Verbergen von Latenz.

Im Schritt 1114 wartet der Thread oder die Thread-Gruppe auf dem Scoreboard. Es können eine oder mehrere Warteanweisungen ausgegeben werden, die bewirken, den Thread oder Warp auf dem Scoreboard zu sperren. Wie oben beschrieben, kann jede Leseanweisung einen Scoreboard-Eintrag dafür konfigurieren, ausgelöst zu werden, wenn ein bestimmter Ergebnisdatenort im Koprozessor bereit ist (z. B. schreibt die auf dem Koprozessor ausgeführte bestimmte Operation die Ergebnisdaten in den bzw. das für den Koprozessor zugreifbare(n) Speicher und/oder Register). Wenn der Scoreboard-Eintrag ausgelöst wird, weil der überwachte Datenspeicherort zum Lesen zur Verfügung steht, werden diese Ergebnisdaten aus dem für den Koprozessor zugreifbaren Speicher in den oder die bezeichneten für den Multiprozessor zugreifbaren Speicherort(e) und/oder Register kopiert.

Im Schritt 1116 kann der Multiprozessor, nachdem jeder der einen oder mehreren Wartebefehle, die auf dem Scoreboard sperren, gelöscht worden ist, die Ergebnisdaten verbrauchen, die in seine zugreifbaren Speicherorte und/oder Register geschrieben worden sind. Zum Beispiel kann der Thread oder die Thread-Gruppe die Ergebnisdaten einer vom Koprozessor durchgeführten bestimmten Operation verbrauchen, indem er bzw. sie die Ergebnisdaten aus den Multiprozessor-Registern in Speicher schreibt.

11B veranschaulicht ein Flussdiagramm für einen Prozess 1120, der, wie oben beschrieben, als Antwort auf den vom Multiprozessor durchgeführten Prozess 1100 auf dem Koprozessor durchgeführt werden kann.

Der Koprozessor empfängt eine Benachrichtigung einer Verbindung-Öffnen-Anforderung im Schritt 1122.

Im Schritt 1124 werden Ressourcen reserviert. Die Ressourcen können Speicher-Speicherung, Register und/oder Pipeline-Slot-Verarbeitung umfassen. Die für Ausführung der bestimmten Operation für einen Thread oder eine Thread-Gruppe reservierten Ressourcen können kollektiv als ein Ausführungs-Slot bezeichnet werden. Die Anzahl der Ausführungs-Slots, die auf einmal in aktivem Gebrauch sein können, kann von den Ressourcenkapazitäten und Verfügbarkeiten abhängen.

Wie oben beschrieben, öffnet der bzw. die Multiprozessor-Thread oder -Thread-Gruppe, der bzw. die die Verbindung-Öffnen-Anweisung ausgibt, Anweisungsblöcke, nachdem die Anweisung ausgegeben worden ist. Dies stellt sicher, dass es nur eine einzelne schwebende Anforderung nach einer offenen Verbindung für einen bestimmten Thread oder eine bestimmte Thread-Gruppe auf einmal gibt. In manchen Ausführungsformen stellt dies auch sicher, dass der Koprozessor die Ressourcen zugewiesen hat, die zum Speichern der durch die nachfolgenden CP_WRITEs gesendeten Daten erforderlich sind.

Im Schritt 1126 benachrichtigt der Koprozessor den Multiprozessor über eine offene Verbindung. Nachdem der Koprozessor den bzw. die Ausführungs-Slot(s) als Antwort auf die Verbindungsanforderung erfolgreich reserviert hat, wird der Multiprozessor benachrichtigt, dass der Ressourcenerwerb erfolgreich vollendet worden ist.

Bei der Operation 1128 führt der Koprozessor die angeforderte Ziel-Operation unter Verwendung von in für den Koprozessor zugreifbare(n) Speicher und/oder Register geschriebenen Eingabedaten aus. Die Ziel-Operation kann eine von mehreren Operationen sein, für die die Koprozessor-Hardware speziell konfiguriert ist. In einem Ausführungsbeispiel kann der Koprozessor, wie oben beschrieben, eine TTU 700 sein, die Hardware enthalten kann, die für BVH-Traversierung maßgeschneidert ist. In manchen anderen Ausführungsformen kann ein Koprozessor wie z. B. der Koprozessor 1504 Hardware enthalten, die für bestimmte andere Arten von Ziel-Operationen optimiert ist.

Im Schritt 1130 schreibt der Koprozessor Ergebnisdaten in Speicher. Die Speicherorte können durch ein Scoreboard oder dergleichen überwacht werden, das im Multiprozessor implementiert ist. Wenn entsprechende Speicherorte beschrieben werden, kann das Scoreboard den Multiprozessor veranlassen (zum Beispiel im Schritt 1114), die Ergebnisdaten von den vom Koprozessor beschriebenen Speicherorten in Multiprozessor-Speicher und/oder -Register zu kopieren.

Im Schritt 1132, nachdem der Koprozessor die Ergebnisdaten in Speicher geschrieben hat, wird die Verbindung auf dem Koprozessor geschlossen, und die reservierten Ressourcen werden freigegeben.

12 zeigt ein Aktivitätsflussdiagramm 1200, das die zeitlichen Beziehungen zwischen den Anweisungen und auf dem Multiprozessor 1202 und Koprozessor 1204 durchgeführten Aktionen weiter veranschaulicht, wenn die oben in Bezug auf 11A beschriebene Multianweisungssequenz auf dem Multiprozessor 1202 ausgeführt wird. Der Prozess 1200 kann ein bestimmtes Implementierungsbeispiel der oben beschriebenen Prozesse 1100 und 1120 darstellen.

Auf einer hohen Ebene ermöglicht es die oben gezeigte Anweisungssequenz dem Multiprozessor, Ressourcen im Koprozessor zu reservieren, Eingabeparameter zu spezifizieren, die Operation im Koprozessor unter Verwendung der spezifizierten Eingabeparameter auszuführen und das Schreiben der Ergebnisse in Register oder Speicher zu veranlassen, auf die der Multiprozessor zugreifen kann. Das Folgende liefert eine Beschreibung der Semantik einer jeden Anweisung in der obigen Multianweisungssequenz (z. B. wie im Prozess 1200 verwendet, wenn ein Multiprozessor wie zum Beispiel der SM 132 Strahlschnittpunkt-Operationen für einen bestimmten Thread oder eine Gruppe von Threads beschleunigt), gemäß manchen Ausführungsformen.

Die Anweisung „CP_OPEN [optionale(r) Ressourcen-Spezifierer]“ 1206 bewirkt, dass der Multiprozessor 1202 eine Verbindung zum Koprozessor 1204 öffnet und genügend Ressourcen reserviert, um die bestimmte Operation abzuschließen. In manchen Ausführungsformen, insbesondere in Ausführungsformen, in denen der Koprozessor konfiguriert ist, um nur eine Art von Ziel-Operation durchzuführen (wie z. B. ein Koprozessor, der konfiguriert ist, nur beschleunigte Traversierung einer BVH durchzuführen), werden die Arten und Mengen der zu empfangenden Ressourcen möglicherweise nicht explizit spezifiziert. In solchen Ausführungsformen kann der Multiprozessor die benötigten Ressourcen auf Basis von impliziten Aspekten wie zum Beispiel der Art des Threads und/oder der Anzahl der aktuell aktiven SIMD-Lanes im Multiprozessor bestimmen. Wenn zum Beispiel der Multiprozessor Strahlverfolgung durchführt und jeder Thread in einer Gruppe von Threads einen entsprechenden Strahl repräsentiert, und wenn n SIMD-Lanes im Multiprozessor aktuell aktiv sind, bestimmt der Multiprozessor möglicherweise, Speicher zum Speichern von n Strahlen zu reservieren oder anfänglich nur einen Teil des zu reservierenden benötigten Speichers anzufordern. In manchen Ausführungsformen, wie zum Beispiel Ausführungsformen, in denen der Koprozessor für mehr als eine Beschleunigungsfunktion konfiguriert ist, kann die Anweisung CP_OPEN optional einen oder mehrere Operanden (z. B. als Soforts spezifiziert) unterbringen, die verwendet werden können, um die gerade von der Multianweisungssequenz aufgerufene bestimmte Koprozessor-Operation und/oder zu reservierende Ressourcenarten und -mengen zu spezifizieren. In manchen Ausführungsformen kann der Multiprozessor die erforderlichen Ressourcen auf Basis von einem oder mehreren der Operanden des CP_OPEN bestimmen und kann eine Anforderung nach Ressourcenreservierung an den Koprozessor in Übereinstimmung mit seiner Bestimmung von Ressourcen stellen.

In manchen Ausführungsformen bestimmt der Koprozessor auf Basis der vom Multiprozessor empfangenen Anforderung die Arten und Mengen der zu reservierenden Ressourcen. Auf Basis der Art der durchzuführenden Koprozessor-Operation und/oder einer Anzahl von aktiven SIMD-Lanes, wie von dem Multiprozessor signalisiert, kann der Koprozessor zum Beispiel den Speicher, die Register und/oder die Verarbeitungs-Pipeline-Slots bestimmen, die zu reservieren sind. Auf Basis seiner Bestimmung der benötigten Ressourcen und/oder auf Basis der vom Multiprozessor gelieferten Informationen reserviert der Koprozessor 1210 Ressourcen. Das Reservieren kann umfassen, sicherzustellen, dass die bestimmten Ressourcen aktuell verfügbar sind und nicht für Verwendung durch eine aktuell unvollendete Operation im Koprozessor zugewiesen sind. Der Koprozessor kann konfiguriert sein, um zu verfolgen, welche Ressourcen einer jeden Ziel-Operation zugewiesen werden, die entweder gerade durchgeführt wird oder als Antwort auf eine ausgegebene CP_COMMAND-Anweisung durchzuführen ist.

Die Anweisung „CP _WAIT“ 1208 bewirkt, dass der Thread oder die Gruppe von Threads auf dem Multiprozessor auf eine Bestätigung 1212 vom Koprozessor wartet, dass die angeforderten Ressourcen zugewiesen worden sind und die Verbindung geöffnet worden ist. Das heißt, in einem Ausführungsbeispiel wird der Wartestatus (z. B. Sperrstatus) für den Thread oder die Thread-Gruppe erst freigegeben 1214, wenn die Bestätigung 1212 vom Koprozessor empfangen wird. Die Sperrung kann durch Setzen eines Flags (z. B. „CP_WAIT_FLAG“ 1516 in 15) implementiert werden, das von dem Multiprozessor zu prüfen ist, bevor irgendeine Koprozessoranweisung ausgegeben wird. In Ausführungsbeispielen gibt der Multiprozessor keine Verbindung-Öffnen-Anweisungen für andere Threads oder Thread-Gruppen aus, wenn er aufgrund eines Threads oder einer Thread-Gruppe bereits in einem gesperrten Status wartet. Das heißt, in manchen Ausführungsbeispielen ist möglicherweise nur ein einzelnes Verbindung-Öffnen am Koprozessor in der Schwebe.

Als ein Beispiel betrachte man, dass die durch CP_OPEN angeforderten Koprozessor-Ressourcen aus einem einzelnen „Ausführungs-Slot“ pro bestimmte Ziel-Operation bestehen, die als Antwort auf CP_COMMAND durchzuführen ist. Die bzw. das oben beschriebene Multianweisungssequenz und Ausführungsschema sind ignorant gegenüber der Anzahl der von der Implementierung bereitgestellten Koprozessor-Ausführungs-Slots sowie der maximalen Anzahl der von dem Multiprozessor unterstützten gleichzeitigen Threads. In einem degenerierten Fall dieses Beispiels können sich Tausende von Threads einen einzelnen Ausführungs-Slot ohne Risiko einer Blockade sicher teilen. Dies folgt aus der Konfiguration in Ausführungsformen, dass ein Thread, der CP_OPEN ausgeführt und die Bestätigung empfangen hat, dass ein Ausführungs-Slot gewährt worden ist, garantiert den Rest der Sequenz (bis CP_CLOSE) ausführt, unabhängig davon, was irgendein anderer Thread tut, da grundlegende Annahmen wie z. B. Fairness beim Scheduling im Multiprozessor und Koprozessor enthalten sind. Ebenso wird der Koprozessor nach dem Schließen der Verbindung über CP_CLOSE garantiert ohne weitere Intervention des Threads oder der Thread-Gruppe die Operation vollenden und zugeordnete Ressourcen frei machen, da alle erlaubten Operationen selbst garantiert enden.

Die Anweisung „CP_WRITE <Koprozessor-Zieladresse>, <Quellenregister>“ 1216 bewirkt, dass der Multiprozessor Eingabedaten an eine Koprozessor-„Adresse“ von einem oder mehreren Multiprozessor-Registern oder -Speicher schreibt. Die spezifizierte Koprozessor-Adresse kann einen physischen Speicherort in einem internen Daten-RAM des Koprozessors spezifizieren und/oder auf andere Weise für den Koprozessor zugreifbar machen. In manchen Ausführungsformen kann die spezifizierte Koprozessor-Adresse eine abstrakte Spezifikation der Art und Weise enthalten, wie die Daten interpretiert und/oder transformiert werden, wenn sie zu dem Koprozessor geschrieben werden, um die Gesamtoperation zu beeinflussen. Bei der Beispiel-Strahlverfolgungs-Beschleunigung speichern die CP_WRITE-Anweisungen 1216 und optional eine nachfolgende Koprozessor-Kopie 1218 Eingabedaten, die einen oder mehrere Strahlen enthalten, wobei ein oder mehrere Stapel zur Verwendung beim Informationsaustausch zwischen dem Koprozessor und dem Multiprozessor in für den Koprozessor zugreifbare(n) Speicher und/oder Register geschrieben werden.

Die Anweisung „CP_COMMAND [optionaler Befehlsspezifizierer]“ 1220 initiiert die bestimmte Ziel-Operation und wirkt auf die durch die vorangegangenen CP_WRITE-Anweisungen 1216 gelieferten Eingabedaten und/oder aus dem Speicher kopierte 1218 Eingabedaten, geschrieben durch die CP_WRITE-Anweisung 1216 in Koprozessor-Register durch den Koprozessor. In manchen Ausführungsformen, wie zum Beispiel in Ausführungsformen, in denen der Koprozessor konfigurierbar ist, um eine ausgewählte oder eine Vielzahl von Koprozessor-Operation(en) durchzuführen, kann die durchzuführende bestimmte Koprozessor-Operation 1224 durch einen optionalen Operanden (z. B. einen Befehlsspezifizierer) spezifiziert werden. In dem aktuellen Beispiel der Strahlverfolgungs-Beschleunigung verwendet der Multiprozessor den Koprozessor, um die Traversierung der BVH zu beschleunigen, um Strahl-BVH-Schnittpunkte über eine vom Koprozessor ausgeführte BVH-Traversierungs-Operation zu bestimmen.

Die Anweisung „CP_READ <Zielregister>, <Koprozessor-Quellenadresse>“ 1222 bewirkt, dass der Multiprozessor Ausgabedaten von einer Koprozessor-„Adresse“ liest und in ein oder mehrere Register des Multiprozessors schreibt. Die spezifizierte Koprozessor-Adresse kann einen physischen Speicherort in einem internen Daten-RAM des Koprozessors spezifizieren und/oder auf andere Weise für den Koprozessor zugreifbar machen. In manchen Ausführungsformen kann die spezifizierte Koprozessor-Adresse eine abstrakte Spezifikation der Art und Weise enthalten, wie die Ergebnisdaten zu interpretieren und/oder zu transformieren sind, wenn sie zu dem Multiprozessor geschrieben werden. Bei der Beispiel-Strahlverfolgungs-Beschleunigung können ein oder mehrere CP_READ verwendet werden, um den bzw. die erkannten Strahl-BVH-Schnittpunkt(e) und einen Fortsetzungsstapel vom Koprozessor an den Multiprozessor zurückzugeben.

Gemäß Ausführungsbeispielen ist die CP_READ-Anweisung 1222 nicht-sperrend, und die durch das vorhergehende CP_COMMAND 1220 initiierte Operation muss beim Ausführen von CP_READ nicht vollendet sein. CP_READ 1222 ist in der Tat ein Versprechen, die Ausgabedaten schließlich an den bzw. die spezifizierten Zielort(e) zu schreiben.

Ausführungsbeispiele sehen vor, den Thread oder die Gruppe von Threads zu benachrichtigen, wenn sich die Ergebnisdaten in Registern und/oder an einem anderen für den Multiprozessor zugreifbaren Speicherort befinden und zum Verbrauch bereit sind. Wie oben beschrieben, wird in manchen Ausführungsformen ein Scoreboard verwendet, um den Multiprozessor zu benachrichtigen, wenn die Ergebnisdaten aus der vom Koprozessor durchgeführten bestimmten Operation vom Koprozessor 1230 vom Koprozessor an den vom Multiprozessor gelesenen Ort geschrieben werden. Das heißt, der Multiprozessor ordnet ein explizit benanntes Scoreboard mit einer CP_READ-Anweisung über eine Annotation „release_when_complete“ („freigeben_wenn_vollendet“) zu. Der Thread oder die Thread-Gruppe wartet dann darauf, dass das Scoreboard unmittelbar vor dem Verbrauch der Ergebnisse freigegeben wird, was es erlaubt, zusätzliche Arbeit durchzuführen, während die Operation noch läuft.

Die Anweisung „CP_CLOSE“ 1226 bewirkt, dass der Multiprozessor die Verbindung zum Koprozessor schließt. In diesem Zeitpunkt ist die Spezifikation der bestimmten Koprozessor-Operation (einschließlich Zielregistern für die Ausgabe-Ergebnisdaten) vollendet, aber die gerade vom Koprozessor durchgeführte Ziel-Operation kann noch im Fluge sein.

Die einzige Sperranweisung in der Sequenz {CP_OPEN, ...., CP_CLOSE} ist CP_WAIT, die auf Ressourcen wartet. Alle nachfolgenden Anweisungen können in dem durch die Implementierung erlaubten Umfang direkt hintereinander ausgeführt werden. Tatsächlich ist es für die „beliebigen dazwischen liegenden Anweisungen“ 1227, die CP_CLOSE in dem Beispiel folgen, gültig, eine weitere Sequenz {CP_OPEN, ...., CP_CLOSE} zu enthalten, die anzeigt, dass mehrere Koprozessor-Operationen im Namen eines einzelnen Ausführungs-Threads gleichzeitig im Fluge sein können.

In manchen Ausführungsbeispielen ist jede Verbindung unabhängig. Das heißt, der Koprozessor ist statuslos in dem Sinne, dass eine gegebene Operation (spezifiziert über eine Sequenz {CP_OPEN ,...., CP_CLOSE}) keine später stattfindenden Koprozessor-Operationen beeinflussen kann (d. h. später stattfindende bestimmte Koprozessor-Befehle, spezifiziert durch CP_COMMAND-Anweisungen), es sei denn, ihre Ausgabe-Ergebnisdaten werden direkt oder indirekt von dem Thread oder der Thread-Gruppe verwendet, um die Eingabe dieser später stattfindenden Koprozessor-Operation zu beeinflussen, wie zum Beispiel durch Übergabe solcher Ergebnisdaten an die später stattfindende bestimmte Koprozessor-Operation über CP_WRITE.

Die Anweisung(en) WAIT_ON_SCOREBOARD („Warte_auf_Scoreboard“) 1228 ist bzw. sind Sperranweisungen, die bewirken, dass der Thread oder die Thread-Gruppe auf einen bestimmten Scoreboard-Eintrag wartet, der von einem vorhergehenden CP_READ 1226 eingerichtet worden ist. Wie oben beschrieben, wird das Scoreboard verwendet, um definierte Abhängigkeiten zu verfolgen, und wird verwendet, um den Thread oder die Thread-Gruppe zu benachrichtigen, wenn jede der CP_READ-Anweisung(en) vom Koprozessor ausgegebene Ergebnisdaten in Multiprozessor-Register und/oder -Speicher schreibt.

Eine Aktivität 1230 veranschaulicht das Koprozessor-Schreiben von Ergebnisdaten als Folge der von dem gerade auf dem Koprozessor ausgeführten CP_COMMAND 1220 initiierten bestimmten Ziel-Operation. In manchen Ausführungsbeispielen kann der Koprozessor die Ergebnisdaten in einen für den Koprozessor zugreifbaren Speicher schreiben, woraus der Multiprozessor die Ergebnisdaten erhält, indem er die in der bzw. den Anweisung(en) CP_READ 1222 spezifizierte „Koprozessor-Quellenadresse“ spezifiziert.

Nachdem das letzte WAIT_ON_SCOREBOARD 1228 entsperrt worden ist, kann der Thread oder die Thread-Gruppe die Ergebnisdaten verbrauchen. Bei der Beispiel-Strahlverfolgungs-Beschleunigung, wenn das letzte WAIT_ON_SCOREBOARD entsperrt ist, hätten alle vom Koprozessor zurückgegebenen Stapelinformationen das Schreiben in Multiprozessor-Register und/oder -Speicher vollendet. Die weitere Verarbeitung des Threads oder der Thread-Gruppe kann dann durch Speichern (SCHREIBE ERGEBNISSE 1232) oder anderweitiges Verbrauchen der Ergebnisdaten erfolgen. Bei der Beispiel-Strahlverfolgungs-Beschleunigung kann das Verbrauchen umfassen, die zurückgegebenen Strahl-BVH-Schnittpunktinformationen und einen Fortsetzungsstapel dabei zu verwenden, Bildeigenschaften zu bestimmen und/oder einen anderen Teil der vom Koprozessor zu verarbeitenden BVH zu bestimmen.

Präemption auf Anweisungsebene in der Multianweisungssequenz

Um die Anwendungsleistung zu verbessern, können Multiprozessoren wie z. B. der SM 132 konfiguriert sein, um einen Thread oder eine Thread-Gruppe auf einer individuellen Anweisungsebene zu unterbrechen. In manchen Ausführungsbeispielen kann der SM 132 konfiguriert sein, um zu unterstützen, dass ein Thread oder ein Thread-Gruppe in irgendeinem Zeitpunkt oder zumindest während eines wesentlichen Teils der Laufzeit des Threads oder der Thread-Gruppe unterbrochen wird. Um den Thread oder die Thread-Gruppe auf dem SM 132 derart zu unterbrechen, dass er nachfolgend konsistent wiederhergestellt werden kann, muss der Status des Koprozessors in Bezug auf den Thread oder die Thread-Gruppe gespeichert und nachfolgend wiederhergestellt werden. Ein weiterer Vorteil des obigen Schemas mit der Multianweisungssequenz ist, dass es mit Anforderungen von Hochleistungs-Multiprozessoren an Präemption auf Anweisungsebene konsistent gemacht werden kann.

Dies erreicht man in Ausführungsbeispielen durch Reservieren eines Bereichs von Koprozessor-Adressen, die Zugriff auf den Koprozessor-Status bieten, für Verwendung durch den oder die Ausnahmebehandler (Software-Interrupt-Behandlungsroutine; engl. trap handler), der bzw. die für das Abspeichern und nachfolgende Wiederherstellen des Thread-Status verantwortlich ist bzw. sind, und weiterhin durch Verlangen, dass irgendeine Ziel-Operation, die bereits auf dem Koprozessor mit CP_COMMAND initiiert worden ist, vollendet werden darf, bevor der Thread oder die Thread-Gruppe unterbrochen wird.

13 enthält ein Flussdiagramm, das die Präemption auf Anweisungsebene an der Multiprozessor-Koprozessor-Schnittstelle gemäß manchen Ausführungsbeispielen veranschaulicht. Das Flussdiagramm veranschaulicht, wie Präemption von einem Ausnahmebehandler 1300 gehandhabt wird, der auf dem Multiprozessor ausgeführt wird, wenn Ausnahmen an verschiedenen Orten in der Ausführung des Threads oder der Thread-Gruppe der in Bezug auf 11A beschriebenen Multianweisungssequenz stattfinden.

Der Ausnahmebehandler 1300 kann als Antwort auf Unterbrechungen aufgerufen werden, die auf dem Multiprozessor oder an anderer Stelle im System stattfinden. Wenn der Ausnahmebehandler 1300 aufgerufen wird, bestimmt er die aktuelle Position in der Multianweisungssequenz, die von dem oder der aktuell ausgeführten Thread oder Thread-Gruppe ausgeführt wird. Der oder die aktuell ausgeführte Thread oder Thread-Gruppe wird nachfolgend als „erster Thread“ bezeichnet, und der Thread oder die Thread-Gruppe, der bzw. die die Präemption bewirkt, wird als „zweiter Thread“ bezeichnet.

Wenn die aktuelle Position des ersten Threads vor CP_OPEN 1302 liegt, führt der Ausnahmebehandler keine Verarbeitung oder Statusspeicherung in Bezug auf den Koprozessor durch, da keine Verbindung zwischen dem Multiprozessor und dem Koprozessor für den ersten Thread offen ist. Daher fährt der Ausnahmebehandler fort, den ersten Thread zu unterbrechen 1304 und zum zweiten Thread zu wechseln, und wechselt nachfolgend zum ersten Thread zurück 1306, nachdem der zweite Thread vollendet ist, seine Zeitscheibe abläuft oder dergleichen.

Wenn die aktuelle Position in dem ersten Thread zwischen CP_OPEN und CP_WAIT 1310 liegt, stellt der Ausnahmebehandler möglicherweise fest, dass ein CP_OPEN für den ersten Thread in der Schwebe war, kann die Verbindung dann aber sofort durch Ausgeben eines CP_CLOSE 1312 schließen. Der Ausnahmebehandler fährt dann fort, um den ersten Thread zu unterbrechen 1314 und zum zweiten Thread zu wechseln, und wechselt nachfolgend zum ersten Thread zurück 1316. Beim Wiederherstellen des Thread-Status für den ersten Thread kann der Ausnahmebehandler eine Verbindung im Namen des ersten Thread durch ein CP_OPEN 1316 wieder öffnen.

Wenn die aktuelle Position des ersten Threads zwischen CP_WAIT und CP_COMMAND 1320 liegt, kann eine beliebige Anzahl von CP_WRITE-Anweisungen von dem ersten Thread ausgeführt worden sein. Somit kann der Ausnahmebehandler 1300 den Koprozessor-Status durch eine Reihe von CP_READ-Anweisungen 1322 abspeichern, bevor er die Verbindung durch Ausgeben eines CP_CLOSE 1324 schließt. Der Ausnahmebehandler fährt dann fort, um den ersten Thread zu unterbrechen 1326 und zum zweiten Thread zu wechseln, und wechselt nachfolgend zum ersten Thread zurück 1328. Beim Wiederherstellen des Thread-Status für den ersten Thread 1330 öffnet der Ausnahmebehandler eine Verbindung im Namen des ersten Threads über CP_OPEN wieder und stellt dann den Koprozessor-Status über eine Reihe von einer oder mehreren CP_WRITE-Anweisungen wieder her.

Wenn die aktuelle Position des ersten Threads zwischen CP_COMMAND und CP_CLOSE 1340 liegt, kann an dieser Position in der Sequenz eine beliebige Anzahl von CP_READ-Anweisungen von dem ersten Thread ausgeführt worden sein. Da die durch CP_COMMAND initiierte Ziel-Operation vollendet werden durfte, bevor der Ausnahmebehandler ausgeführt wird, werden die bereits ausgeführten CP_READ-Anweisungen ihre Ergebnisse in Register geschrieben haben, die vom Ausnahmebehandler auf die konventionelle Weise abgespeichert 1342 werden können. Damit irgendwelche nachfolgenden CP_READ-Anweisungen die korrekten Ergebnisse erzeugen können, muss der Ausnahmebehandler den Koprozessor-Status speichern 1344 und wiederherstellen 1350. In ähnlicher Weise wie im Schritt 1330, um den Thread-Status für den ersten Thread 1350 wiederherzustellen, öffnet der Ausnahmebehandler eine Verbindung im Namen des ersten Threads über CP_OPEN wieder und stellt dann den Koprozessor-Status über eine Reihe von einer oder mehreren CP_WRITE-Anweisungen wieder her.

Wenn die aktuelle Position der Multianweisungssequenz nach CP_CLOSE 1360 liegt, dann gibt es aktuell kein Verbindung-Öffnen für den ersten Thread zwischen dem Multiprozessor und dem Koprozessor, so dass der Ausnahmebehandler bei dem Prozess, den ersten Thread zu unterbrechen und wiederherzustellen, kein Speichern/Wiederherstellen des Koprozessor-Status durchführt. Daher fährt der Ausnahmebehandler fort, den ersten Thread zu unterbrechen 1360 und zum zweiten Thread zu wechseln, und wechselt nachfolgend zum ersten Thread zurück 1362, nachdem der zweite Thread vollendet ist, seine Zeitscheibe abläuft oder dergleichen.

Das Merkmal, dass Präemption in beliebigen Zeitpunkten auf diese Weise robust gehandhabt werden kann, ist eine nicht-triviale Eigenschaft der Ausführungsbeispiele, wie man durch Betrachtung von scheinbar kleinen Störungen erkennen kann. Man betrachte zum Beispiel, was geschehen würde, wenn die Anweisung CP_COMMAND weggelassen würde, um die Initiierung der Operation zu einer Nebenwirkung von CP_CLOSE zu machen. Bei einem solchen Schema wäre es nicht möglich, bereits ausgeführte CP_READ-Anweisungen zu bedienen, da die Koprozessor-Operation selbst noch nicht initiiert worden wäre, setzt man Präemption vor dem CP_CLOSE voraus. In Abhängigkeit von den Details des Multiprozessors könnte das Wiedergeben dieser CP_READ-Anweisungen nicht möglich sein oder eine erhebliche zusätzliche Komplexität mit sich bringen. Einfaches Abspeichern des Zielregisternamens als Teil des Koprozessor-Status ist keine Lösung für sich allein, da Multithread-Prozessoren im Allgemeinen Register so virtualisieren, dass ein gegebener Registername einer beliebigen Anzahl von physischen Speicherorten in der Registerdatei entsprechen könnte, und das Name-Physisch-Mapping für einen gegebenen Thread könnte sich je nach den Details, wie unterbrochen und wiederhergestellt wird, ändern.

Darüber hinaus können einige Varianten des obigen Schemas, die im Wesentlichen kosmetischer Natur sind, durch eine Implementierung in manchen Ausführungsbeispielen übernommen werden, um die Länge einer typischen Multianweisungssequenz durch eine oder mehrere Anweisungen zu reduzieren. Eine erste Variante kann umfassen, dass CP_COMMAND mit dem letzten CP_WRITE in der Sequenz kombiniert werden kann, um eine kombinierte Anweisung „CP _WRITE_AND_COMMAND“ zu bilden, wenn in der Anweisungscodierung Platz ist (was wahrscheinlich der Fall ist, wenn die Anzahl der unterstützten Befehle klein ist). Eine zweite Variante umfasst, ähnlich wie die erste Variante, dass CP_CLOSE mit dem endgültigen CP_READ kombiniert werden kann, um eine kombinierte Anweisung „CP_READ_AND_CLOSE“ zu bilden.

Vereinfachte Präemption auf Anweisungsebene mit einer Makroanweisung

Die in Bezug auf 11-13 oben beschriebene Multianweisungssequenz veranschaulicht, wie die Multiprozessor-Koprozessor-Interaktion in Ausführungsbeispielen auch bei Vorhandensein von Präemption robust gemacht wird. Eine Variante dieser Basis-Schnittstelle wird in manchen Ausführungsbeispielen angepasst, um die Notwendigkeit für Rohzugriff auf den Koprozessor-Status, wie vom Ausnahmebehandler 1300 verwendet, zu vermeiden. Diese Anpassung kann die Design- und Verifizierungskomplexität reduzieren und kann auch besser für Koprozessoren geeignet sein, die von zwei oder mehr Multiprozessoren gemeinsam genutzt werden.

Die von den Erfindern in der Anpassung implementierte Idee ist es, die vollständige Anweisungs-Teilsequenz {CP_OPEN, ...., CP_CLOSE} innerhalb der in Bezug auf 11A beschriebenen Multianweisungssequenz zu einer einzelnen „Makroanweisung“ zu fusionieren, indem Interrupts für die Dauer der Teilsequenz unterbunden werden. Darüber hinaus wird die Makroanweisung derart implementiert, dass sie nicht missbraucht oder versehentlich missbraucht werden kann, um Interrupts auf unbestimmte Zeit unterbunden zu halten. Dies geschieht mit einer Makro-Initiierungsanweisung (z. B. „CP_MACRO_FUSE“), die eine explizite Zählung von Anweisungen nimmt, die der Multiprozessor konfigurationsgemäß ohne Unterbrechung ausführt. In der Beschreibung hier wird die Konvention übernommen, dass die Zählung die Anweisung CP_MACRO_FUSE selbst ausschließt, doch sind die Ausführungsformen nicht darauf beschränkt.

Eine Makroanweisung, die aus drei „Mikroanweisungen“ besteht, hätte dann die folgende allgemeine Form:


 CP_MAKRO_FUSE 3
 MICRO_INSTA
 MICRO_INST_B
 MICRO_INST_C

Das heißt, die Makroanweisung für die drei Mikroanweisungen besteht aus einer Makro-Initiierungsanweisung (CP_MACRO_FUSE) gefolgt von den drei Mikroanweisungen. Bei Anwendung auf die in Bezug auf 11A, 11B und 12 beschriebene Multiprozessor-Koprozessor-Schnittstelle wird CP_MACRO _FUSE mit CP_WAIT kombiniert, um eine neue Anweisung CP_MACRO_FUSE zu bilden, damit sie die gewünschte Wirkung hat, die gesamte Teilsequenz der Koprozessoranweisung (mit Ausnahme von CP_OPEN) zu fusionieren und zugleich auch die Möglichkeit zu beseitigen, dass ein Thread Interrupts unterbindet und dann eine unbestimmte Zeit lang auf die Zuweisung von Koprozessor-Ressourcen und das Öffnen einer Verbindung wartet, wie es geschehen könnte, wenn CP_OPEN in die Makroanweisung aufgenommen worden wäre.

Mit dieser Erweiterung wird die in Bezug auf 11-12 beschriebene Beispiel-Multianweisungssequenz wie folgt angepasst:

 CP_OPEN
 CP_MAKRO_FUSE 7
 CP_WRITE cp[0x100] R2, R3
 CP_WRITE cp[0x208] R4, R5
 CP_WRITE cp[0x300] R10, R11
 CP_COMMAND 0x1
 CP_READ R12, R13, cp[0x400] &release_when_complete(sb0)
 CP_READ R16, R17, cp[0x460] &release_when_complete(sb1)
 CP_CLOSE
 # .... 

 # ... (optionale beliebige dazwischen liegende Anweisungen)
 #...
 WAIT_ON_SCOREBOARD sb0
 WAIT_ON_SCOREBOARD sb1
 # Verbrauche Ergebnisse (z. B. Speichern von Ergebnissen in Speicher):
 STORE [R7], R12
 # ...

Die angepasste Multianweisungssequenz, wie oben gezeigt, enthält die Anweisung „CP_MACRO_FUSE 7“, die spezifiziert, dass die nächsten 7 Anweisungen in der Sequenz auszugeben sind, während Interrupts unterbunden werden. Die nächsten 7 Anweisungen enthalten alle Anweisungen CP_WRITE, CP_COMMAND, CP_READ und CP_CLOSE in der spezifizierten Sequenz. Das Ermöglichen von Interrupts kann erst nach den 7 Anweisungen erfolgen. Daher wird in der angepassten Multianweisungssequenz die gesamte Teilsequenz {CP_OPEN .... CP_CLOSE} garantiert ohne Präemption ausgeführt.

Es können konventionelle Techniken verwendet werden, um Interrupts zu unterbinden und um nachfolgend Interrupts zu ermöglichen.

14A enthält ein Flussdiagramm eines Prozesses 1400, der die angepasste Multianweisungssequenz (d. h. einschließlich der Anweisung CP_MACRO_FUSE) gemäß manchen Ausführungsbeispielen ausgibt. Die einzigen Änderungen gegenüber dem in Bezug auf 11A beschriebenen Prozess 1100 sind die Anweisung CP_MACRO_FUSE (und das zugeordnete Unterbinden von Interrupts) im Schritt 1404 nach dem CP_OPEN 1402 und das Ermöglichen von Interrupts im Schritt 1408. Somit entspricht Schritt 1402 in 14A dem Schritt 1102, wie in Bezug auf 11 A beschrieben, Schritt 1406 entspricht den Schritten 1104-1112, wie in Bezug auf 11A beschrieben, Schritt 1408 entspricht dem Schritt 1114, wie in Bezug auf 11 A beschrieben, und Schritt 1410 entspricht dem Schritt 1116, wie in Bezug auf 11A beschrieben.

Man beachte, dass es noch möglich ist, dass der Thread oder die Thread-Gruppe, die die Multianweisungssequenz ausführt, zwischen den Anweisungen CP_OPEN und CP_MACRO_FUSE unterbrochen wird. Daher ist der Ausnahmebehandler konfiguriert, um diese Möglichkeit zu prüfen (z. B. über eine dedizierte Anweisung) und dann eine neue Verbindung im Namen des Threads über CP_OPEN zu öffnen, bevor die Steuerung an den wiederhergestellten Thread zurückgegeben wird. Dies ist möglicherweise die einzige verbleibende Verantwortlichkeit des Ausnahmebehandlers, soweit es die Koprozessor-Schnittstelle betrifft. Man beachte auch, dass der Ausnahmebehandler zwar das Öffnen einer Verbindung über CP_OPEN initiieren muss, aber nicht darauf warten muss, dass Koprozessor-Ressourcen zugewiesen werden oder dass die Verbindung tatsächlich geöffnet wird, da dies von dem wiederhergestellten Thread bewerkstelligt wird, der an CP_MACRO_FUSE (was z. B. CP_WAIT bei Verbindung-Öffnen enthält) wartet.

Die Anweisung CP_MACRO_FUSE ermöglicht in der Tat die Implementierung einer Koprozessoranweisung, die eine „Makroanweisung“ variabler Länge ist, die über eine Reihe von einfacheren Mikroanweisungen bewerkstelligt wird. Die Implementierung in Ausführungsbeispielen erfüllt mehrere übergeordnete Anforderungen, darunter die folgenden: (1) die Makroanweisung muss als eine einzelne Anweisung zum Zwecke der Berechnung von Präemption auf Anweisungsebene (CILP; compute instruction-level preemption) betrachtet werden; (2) die Präemptionslatenz muss für alle möglichen Makroanweisungen, die in der ISA ausgedrückt werden können, begrenzt bleiben, und insbesondere muss Hardware garantieren, dass der Makroanweisungs-Mechanismus nicht missbraucht werden kann, um Ausnahmen auf unbestimmte Zeit zurückzuhalten; und (3) die Makroanweisung muss als eine einzelne Anweisung für den Zweck von Einzelschritt-Fehlerbeseitigung betrachtet werden.

Wie in Bezug auf 11A beschrieben, fordert CP_OPEN die Zuweisung der für die Abfrage benötigten Koprozessor-Ressourcen an. Die Ressourcen können ein „Ticket“ für die Verbindung und entweder einen oder mehrere „Ausführungs-Slots“ pro Thread oder Thread-Gruppe umfassen. CP_OPEN ist nicht sperrend, hat aber den Nebeneffekt, ein Flag im SM zu setzten, der dem Thread oder der Thread-Gruppe zugeordnet ist, was als „CP_WAIT_FLAG“-Bit bezeichnet wird. Man beachte, dass CP_OPEN nicht Teil der Koprozessor-Makroanweisung ist.

Die Makroanweisung beginnt mit der Makroinitiierungsanweisung „CP_MACRO_FUSE“. Diese Mikroanweisung darf nicht ausgegeben werden, bis CP_WAIT_FLAG gelöscht ist. Sobald dies geschieht, werden auch die nächsten N Mikrobefehle garantiert vollendet, bevor der SM eine Ausnahmebehandlung durchführen kann, wobei N als ein Sofort-Operand der Anweisung CP_MACRO_FUSE spezifiziert ist.

Die einzigen Anweisungen, die innerhalb eines Makros erlaubt sind, sind die Anweisungen CP_MACRO_FUSE (womit das Makro beginnen muss), CP_WRITE, CP_COMMAND, CP_READ und CP_CLOSE.

CP_MACRO_FUSE darf nicht ausgegeben werden, bis das Bit CP_WAIT_FLAG gelöscht ist (d. h., bis der SM vom Koprozessor eine Bestätigung erhält, dass ein Ticket für diesen Thread oder diese Thread-Gruppe zugewiesen worden ist).

Verbesserte Gleichzeitigkeit mit partieller Ergebnisrückgabe

Ein Koprozessor, der in der Lage ist, mehrere Operationen parallel (im Namen eines oder mehrerer Threads) auszuführen, benötigt eine gewisse Menge an Ressourcen für jede Im-Fluge-Operation. Beispiele für erforderliche Ressourcen können internen Arbeitsspeicher und Platz zum Speichern von Ergebnissen, bevor sie an den Host-Prozessor zurückgegeben werden, umfassen. Sofern sie nicht im Übermaß bereitgestellt werden (auf Kosten von Fläche auf dem Koprozessor), begrenzen solche Ressourcen wahrscheinlich die Anzahl der Operationen, die auf einmal im Fluge sein können, und somit den Gesamtdurchsatz in Fällen, in denen die Latenz der Operationen zu Leerlauf-Ausführungseinheiten führt (im Koprozessor und/oder im Multiprozessor, da Threads auf Vollendung von Koprozessor-Operationen warten).

Um solche Ineffizienzen zu vermeiden, weisen manche Ausführungsbeispiele Koprozessor-Ressourcen für eine bestimmte Koprozessor-Ziel-Operation mit einer feineren Granularität als ein einzelner „Ausführungs-Slot“ zu. Eine Ziel-Operation könnte zum Beispiel aus einer größeren Anzahl von Teiloperationen oder „Arbeitselementen“ bestehen, die voneinander unabhängig sind. In einem SIMD-Multiprozessor könnten solche Arbeitselemente SIMD-Lanes entsprechen, die aktiv sind, wenn der Thread die Operation initiiert hat.

Da Arbeitselemente unabhängig sind, ist es in diesem Szenario möglich, und manche Ausführungsbeispiele sind dafür konfiguriert, Ergebnisdaten nur für eine Teilmenge von Arbeitselementen in Register zurückzuschreiben und irgendwelche zugeordneten Koprozessor-Ressourcen frei zu machen, bevor der vollständige Satz von Elementen (und somit die Ziel-Operation) vollendet ist. Somit können gemäß manchen Ausführungsformen einige Koprozessor-Ressourcen (z. B. Ausführungs-Slot), die Ergebnisdaten festhalten, gelöscht werden, bevor die einem Thread oder einer Thread-Gruppe zugeordnete Verbindung geschlossen wird, wodurch die Wiederverwendung solcher Ressourcen ermöglicht wird, wie und wenn sie frei gemacht werden. Dies macht sich die Speicherung in der Registerdatei im Multiprozessor entsprechend den Zielregistern von CP_WRITE-Anweisungen, die andernfalls leer stehen würden, zu Nutze. Man beachte, dass es nicht notwendig ist, alle Daten für ein gegebenes CP_WRITE auf einmal zurückzuschreiben; zum Beispiel wenn die Zielregister Vektor-Register sind (mit einem Register pro SIMD-Lane), kann es vorteilhaft sein, Ergebnisse nur für eine Teilmenge von Lanes auf einmal zurückzuschreiben. Die einzige Anforderung, zumindest in manchen Ausführungsformen, ist, dass das Programm die Ergebnisse von einem gegebenen CP_WRITE nicht verbraucht, bis alle Ergebnisse für dieses CP_WRITE in der Multiprozessor-Registerdatei vorhanden sind. In Ausführungsformen, bei denen Bereitschaft durch ein Scoreboard angezeigt wird, bedeutet dies, dass das Scoreboard nicht freizugeben ist, bis alle Ergebnisse zurückgeschrieben worden sind.

In einem Ausführungsbeispiel ermöglicht die Multiprozessor-Koprozessor-Schnittstelle es dem Multiprozessor, dem Koprozessor zu befehlen, eine Koprozessor-Operation (z. B. Strahl-Traversierung einer BVH, eine „TTU-Abfrage“) an bis zu 32 Arbeitselementen (z. B. entsprechend den 32 Lanes oder „Threads“ in einem Warp) auszuführen. Arbeitselemente in diesem Ausführungsbeispiel können Strahlen umfassen. Die Koprozessor-Ziel-Operation (z. B. „TTU-Abfrage“) kann Strahlschnittpunktergebnisse mit konfigurierbarer Granularität zurückschreiben, wobei die Standard-Granularität 8 Strahlen sein kann. 14B und 14C zeigen die Ergebnisausgabe des Koprozessors für eine 16-Thread-Gruppe von Threads, die in Gruppen von 4 Threads an die Multiprozessor-Register zurückgegeben werden, wodurch die jeweiligen Ausführungs-Slots, die auf dem Koprozessor für jeweilige Threads der Gruppe von Threads reserviert sind, frei gemacht werden, wenn die Ziel-Operation für jeden jeweiligen Thread vollendet ist. Wie in 14B veranschaulicht, wenn die gesamte Gruppe von 16 Threads gleichzeitig Ergebnisse in Multiprozessor-Register schreibt, bleibt der von jedem der 16 Threads verwendete Koprozessor-Speicher belegt, und alle Registerdateien im Multiprozessor, auch wenn sie zugewiesen sind, bleiben unbelegt. Im Gegensatz dazu veranschaulicht 14C, dass die Gruppe von 16 Threads Ergebnisse an die Multiprozessor-Register in Gruppen von 4 Threads zurückgeben darf. Die zeitversetzte Rückgabe von Ergebnissen, während jede Untergruppe von Threads ihre Verarbeitung auf dem Koprozessor vollendet, verbessert die Ausnutzung der bereits zugewiesenen Register im Multiprozessor und macht gleichzeitig schneller wertvollen Koprozessor-Speicher frei, wie und wenn jeweilige Untergruppen der Threads ihre jeweiligen Nutzungen des Koprozessors vollenden. Dies führt zu einer signifikanten Leistungssteigerung (z. B. um einige zehn Prozent) bei festem Flächenbedarf des Prozessors, oder aus anderer Perspektive zu einer Verringerung der Fläche bei fester Leistung.

Allgemeine Multiprozessor-Koprozessor-Schnittstelle

Wie oben beschrieben, sind Ausführungsformen nicht auf eine Multiprozessor-Koprozessor-Schnittstelle beschränkt, die der Schnittstelle zwischen dem SM 132 und der TTU 700 entspricht. 15 zeigt ein System 1500 mit einer Schnittstelle zwischen einem Multiprozessor 1502, der ein anderer Typ von Multiprozessor als der SM 132 sein kann, und einem Koprozessor 1504, der ein anderer Typ von Koprozessor als die TTU 700 sein kann. Der Multiprozessor 1502 und der Koprozessor 1504 können über einen Kommunikationsbus 1505 direkt kommunizieren, und beide können Zugriff auf einen Gemeinschaftsspeicher 1506 haben. Der Gemeinschaftsspeicher 1506 ist zwar als außerhalb des Koprozessors 1504 und des Multiprozessors 1502 befindlich gezeigt, ist aber darauf nicht beschränkt. In manchen Ausführungsformen kann sich der
Gemeinschaftsspeicher 1506 innerhalb des Koprozessors 1502 befinden, separat oder mit einem lokalen Speicher 1520 des Koprozessors integriert. In manchen Ausführungsformen kann der Gemeinschaftsspeicher 1506 Cache-Speicher (wie z. B. L0/L1 -Cache der TTU 700) oder anderer Speicher sein, auf den der Koprozessor nur Lesezugriff hat.

Der Multiprozessor 1502 ist konfiguriert, um gleichzeitig eine Vielzahl von Threads 1510 auszuführen, und kann weiterhin konfiguriert sein, um dem Koprozessor 1504 zu befehlen, eine oder mehrere Koprozessor-Operationen 1526 durchzuführen, um die Verarbeitung eines oder einer Gruppe der Vielzahl von Threads 1510 zu beschleunigen. Wie oben beschrieben, kann in einem SIMD-Multiprozessor eine Gruppe von Threads (z. B. ein Warp) für gleichzeitige Ausführung geplant werden.

Der Koprozessor 1504 kann sein eigenes Scheduling 1524 enthalten, das faires Scheduling für vom Multiprozessor dem Koprozessor vorgelegte Arbeitselemente (d. h. Threads) gewährleisten kann. Der Koprozessor kann auch seinen lokalen Speicher (z. B. RAM) 1520 und die Register 1522 enthalten.

Der Multiprozessor 1502 gemäß einer oder mehreren oben beschriebenen Ausführungsformen kann den Ausnahmebehandler 1518 enthalten, der zum Beispiel in Übereinstimmung mit dem oben beschriebenen Prozess 1300 arbeitet. Der Multiprozessor 1502 kann auch ein CP _WAIT_FLAG 1516 enthalten, wobei ein Flag/Bit bei Ausführung der CP_WAIT-Anweisung oder der CP_MACROFUSE-Anweisung gesetzt wird und gelöscht wird, wenn der Multiprozessor benachrichtigt wird, dass die angeforderte Koprozessor-Verbindung hergestellt ist. Der Multiprozessor kann konfiguriert sein, um das CP_WAIT_FLAG 1516 vor einem Scheduling von Threads zu prüfen, um sicherzustellen, dass ein bestimmter Thread oder eine bestimmte Thread-Gruppe nur dann zu den Koprozessor-Operationen übergeht, wenn die benötigten Koprozessoren verfügbar sind, und um sicherzustellen, dass ein gegebener Thread oder eine gegebene Thread-Gruppe in irgendeinem gegebenen Zeitpunkt nicht mehr als eine schwebende Verbindung geöffnet hat.

Der Multiprozessor kann auch einen MACROFUSE-Zähler 1514 enthalten, der als ein Zähler verwendet werden kann, um zu bestimmen, wann Interrupts wieder freizugeben sind, nachdem sie durch die Anweisung CP_MACRO_FUSE unterbunden worden sind. Wenn zum Beispiel die Anweisung CP_MACRO_FUSE in einer Multianweisungssequenz spezifiziert, dass n Anweisungen auszuführen sind, ohne Präemption zu erlauben, kann der Zähler 1514 als ein Countdown-Timer mit einem Wert von n gesetzt werden. Der Zähler wird dann für jede ausgegebene Anweisung dekrementiert, bis er 0 erreicht.

Der Gemeinschaftsspeicher 1506 kann Speicherorte enthalten, die zum Datenaustausch zwischen dem Multiprozessor 1502 und dem Koprozessor 1504 verwendet werden. In manchen Ausführungsformen hat der Koprozessor möglicherweise keinen Schreibzugriff auf den Gemeinschaftsspeicher 1506. In manchen Ausführungsformen kann der Gemeinschaftsspeicher 1506 eine oder mehrere Ebenen von Cache-Speicher umfassen, auf die der Koprozessor nur Lesezugriff hat.

In manchen Ausführungsformen kann der Gemeinschaftsspeicher 1506 einen Roh-Koprozessor-Status 1530 und ein Scoreboard 1532 aufweisen. Der Roh-Koprozessor-Status 1530 kann sich in manchen Ausführungsformen im lokalen Speicher 1520 des Koprozessors befinden. Wenn sich der Roh-Koprozessor-Status 1530 im lokalen Speicher 1520 des Koprozessors befindet, kann der Multiprozessor noch darauf zugreifen, wenn es zum Beispiel durch eine Reihe von CP_READs, die von einem Ausnahmebehandler ausgegeben werden, der auf dem Multiprozessor ausgeführt wird, erforderlich wird. Der Roh-Koprozessor-Status 1530 umfasst den Status des Koprozessor-Speichers und der Register im Zeitpunkt einer Präemption des bzw. der auf dem Multiprozessor ausgeführten Threads oder Thread-Gruppe.

Das Scoreboard 1532 wird verwendet, um den Multiprozessor zu benachrichtigen, wenn eine Ziel-Operation, die möglicherweise asynchron ausgeführt wird, ihre Ergebnisausgabe vollendet und die Ergebnisse in die Register oder Speicher des Multiprozessors geschrieben werden.

Wie oben beschrieben, werden Anforderungsdaten über Register und/oder Gemeinschaftsspeicher an den Koprozessor mit dem Befehl zum Auslösen der Koprozessor-Ziel-Operation für einen Thread oder eine Gruppe von Threads übergeben. Der Koprozessor führt die Ziel-Operation aus und schreibt die Ergebnisse schließlich in einen Gemeinschaftsspeicher oder einen Satz von Registern zurück. Der Multiprozessor schreibt dann die Ergebnisdaten aus den vom Koprozessor beschriebenen Orten in Multiprozessor-Speicher und/oder - Register, während er ein Scoreboard dekrementiert, um anzuzeigen, dass die Ergebnisse für Verbrauch bereit sind. In manchen Ausführungsbeispielen, in denen die Ergebnisse nicht in einen Gemeinschaftsspeicher geschrieben werden, kann der Koprozessor ein oder mehrere Pakete, die die Ergebnisse enthalten, über eine Schnittstelle an den Multiprozessor senden, wo sie in Register im Multiprozessor geschrieben werden. Das letzte Paket, das ein gegebenes CP_READ bedient, kann ein Feld enthalten, das anzeigt, dass ein Scoreboard freizugeben ist. Das letzte Paket kann auch den Index für den Scoreboard-Eintrag enthalten, da dieser Index von dem Multiprozessor als Teil des gegebenen CP_READ an den Koprozessor geliefert werden kann.

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. 16 veranschaulicht ein Beispiel-Flussdiagramm für die Verarbeitung von Primitiven, um Bildpixelwerte eines Bildes zu liefern, gemäß einer Ausführungsform.

Wie 16 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 20 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 17-19, 21, 22, 23 und/oder 24 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. 16 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 17-24 beschrieben ist. Eine derartige Parallelverarbeitungsarchitektur kann zum Beispiel zum Implementieren der GPU 130 von 1 verwendet werden.

Beispiel-Parallelverarbeitungsarchitektur

17 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 17 gezeigt, enthält die PPU 1700 eine Eingabe/Ausgabe-(I/O)-Einheit 1705, eine Vorverarbeitungseinheit 1715, eine Scheduler-Einheit 1720, eine Arbeitsverteilungseinheit 1725, einen Hub 1730, ein Koppelfeld (XBar, crossbar) 1770, einen oder mehrere Allgemeinverarbeitungscluster (GPCs) 1750 und eine oder mehrere Partitionseinheiten 1780. Die PPU 1700 kann über eine oder mehrere Hochgeschwindigkeits-NVLink-1710-Verbindungen mit einem Host-Prozessor oder anderen PPUs 1700 verbunden sein. Die PPU 1700 kann über eine Verbindung 1702 mit einem Host-Prozessor oder anderen Peripheriegeräten verbunden sein. Die PPU 1700 kann auch mit einem lokalen Speicher verbunden sein, der eine Anzahl von Speichergeräten 1704 umfasst. In einer Ausführungsform kann der lokale Speicher eine Anzahl von DRAM-(Dynamic Random Access Memory, Speicher mit dynamischem Direktzugriff)-Geräten umfassen. Die DRAM-Geräte können als ein HBM-(High-Bandwidth Memory)-Subsystem konfiguriert sein, wobei mehrere DRAM-Dies (Waferstücke) in jedem Gerät gestapelt sind.

Die NVLink-1710-Verbindung ermöglicht es Systemen, eine oder mehrere PPUs 1700 in Kombination mit einer oder mehreren CPUs zu skalieren und zu integrieren, unterstützt Cache-Kohärenz zwischen den PPUs 1700 und CPUs sowie CPU-Mastering. Daten und/oder Befehle können vom NVLink 1710 über den Hub 1730 zu/von anderen Einheiten der PPU 1700 übertragen werden, wie z. B. einer oder mehreren Kopier-Engines, einem Video-Encoder, einem Video-Decoder, einer Leistungsverwaltungseinheit usw. (nicht explizit gezeigt). Der NVLink 1710 wird in Verbindung mit 23 näher beschrieben.

Die I/O-Einheit 1705 ist so konfiguriert, dass sie über die Verbindung 1702 Kommunikation (d. h. Befehle, Daten, usw.) von einem Host-Prozessor (nicht gezeigt) sendet und empfängt. Die I/O-Einheit 1705 kann mit dem Host-Prozessor direkt über die Verbindung 1702 oder über ein oder mehrere Zwischen-Geräte wie z. B. eine Speicherbrücke kommunizieren. In einer Ausführungsform kann die I/O-Einheit 1705 über die Verbindung 1702 mit einem oder mehreren anderen Prozessoren kommunizieren, wie z. B. einer oder mehreren der PPUs 1700. In einer Ausführungsform implementiert die I/O-Einheit 1705 eine PCIe-(Peripheral Component Interconnect Express)-Schnittstelle für Kommunikation über einen PCIe-Bus, und die Verbindung 1702 ist ein PCIe-Bus. In alternativen Ausführungsformen kann die I/O-Einheit 1705 andere Arten von bekannten Schnittstellen für Kommunikation mit externen Geräten implementieren.

Die I/O-Einheit 1705 decodiert Pakete, die über die Verbindung 1702 empfangen wurden. In einer Ausführungsform repräsentieren die Pakete Befehle, die so konfiguriert sind, dass sie die PPU 1700 verschiedene Operationen durchführen lassen. Die I/O-Einheit 1705 überträgt die decodierten Befehle an verschiedene andere Einheiten der PPU 1700, wie es die Befehle spezifizieren können. Zum Beispiel können manche Befehle an die Vorverarbeitungseinheit 1715 übertragen werden. Andere Befehle können an den Hub 1730 oder andere Einheiten der PPU 1700 übertragen werden, wie z. B. eine oder mehrere Kopier-Engines, einen Video-Encoder, einen Video-Decoder, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt). Mit anderen Worten, die I/O-Einheit 1705 ist so konfiguriert, dass sie die Kommunikation zwischen und unter den verschiedenen Logikeinheiten der PPU 1700 weiterleitet.

In einer Ausführungsform codiert ein vom Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einem Puffer, der der PPU 1700 Arbeit (Workload) zur Verarbeitung liefert. Ein Workload kann mehrere Anweisungen sowie Daten, die von diesen Anweisungen verarbeitet werden sollen, umfassen. Der Puffer ist ein Bereich in einem Speicher, auf den sowohl der Host-Prozessor als auch die PPU 1700 zugreifen (d. h. lesen/schreiben) können. Zum Beispiel kann die I/O-Einheit 1705 so konfiguriert sein, dass sie über Speicheranforderungen, die über die Verbindung 1702 übertragen werden, auf den Puffer in einem Systemspeicher zugreift, der mit der Verbindung 1702 verbunden ist. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und sendet dann einen Zeiger auf den Anfang des Befehlsstroms an die PPU 1700. Die Vorverarbeitungseinheit 1715 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Vorverarbeitungseinheit 1715 verwaltet einen oder mehrere Ströme, liest Befehle aus den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 1700 weiter.

Die Vorverarbeitungseinheit 1715 ist mit einer Scheduler-Einheit 1720 gekoppelt, die die verschiedenen GPCs 1750 so konfiguriert, dass sie Aufgaben bzw. Tasks bearbeiten, die durch die ein oder mehreren Ströme definiert sind. Die Scheduler-Einheit 1720 ist so konfiguriert, dass sie Statusinformationen zu den verschiedenen Aufgaben verfolgt, die von der Scheduler-Einheit 1720 verwaltet werden. Der Status kann anzeigen, welchem GPC 1750 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, einen der Aufgabe zugewiesenen Prioritätsgrad und so weiter. Die Scheduler-Einheit 1720 verwaltet die Ausführung einer Vielzahl von Aufgaben auf den ein oder mehreren GPCs 1750.

Die Scheduler-Einheit 1720 ist mit einer Arbeitsverteilungseinheit 1725 gekoppelt, die so konfiguriert ist, dass sie Aufgaben zur Ausführung auf den GPCs 1750 abfertigt. Die Arbeitsverteilungseinheit 1725 kann eine Anzahl von geplanten Aufgaben verfolgen, die von der Scheduler-Einheit 1720 empfangen wurden. In einer Ausführungsform verwaltet die Arbeitsverteilungseinheit 1725 für jeden der GPCs 1750 einen Pool von anstehenden Aufgaben und einen Pool von aktiven Aufgaben. Der Pool von anstehenden Aufgaben kann eine Anzahl von Slots (z. B. 32 Slots) umfassen, die Aufgaben enthalten, die von einem bestimmten GPC 1750 zu bearbeiten sind. Der Pool von aktiven Aufgaben kann eine Anzahl von Slots (z. B. 4 Slots) für Aufgaben umfassen, die gerade von den GPCs 1750 aktiv bearbeitet werden. Wenn ein GPC 1750 die Ausführung einer Aufgabe beendet, wird diese Aufgabe aus dem Pool von aktiven Aufgaben für den GPC 1750 entfernt, und es wird eine der anderen Aufgaben aus dem Pool von anstehenden Aufgaben ausgewählt und für Ausführung auf dem GPC 1750 eingeplant. Wenn eine aktive Aufgabe auf dem GPC 1750 untätig war, z. B. während des Wartens auf Auflösung einer Datenabhängigkeit, kann die aktive Aufgabe aus dem GPC 1750 entfernt und an den Pool von anstehenden Aufgaben zurückgegeben werden, während eine andere Aufgabe im Pool von anstehenden Aufgaben ausgewählt und für Ausführung auf dem GPC 1750 eingeplant wird.

Die Arbeitsverteilungseinheit 1725 kommuniziert über das XBar 1770 mit einem oder mehreren GPCs 1750. Das XBar 1770 ist ein Verbindungsnetz, das viele Einheiten der PPU 1700 mit anderen Einheiten der PPU 1700 koppelt. Zum Beispiel kann das XBar 1770 so konfiguriert sein, dass es die Arbeitsverteilungseinheit 1725 mit einem bestimmten GPC 1750 koppelt. Obwohl nicht explizit gezeigt, können eine oder mehrere andere Einheiten der PPU 1700 auch über den Hub 1770 mit dem XBar 1770 verbunden sein.

Die Aufgaben werden von der Scheduler-Einheit 1720 verwaltet und von der Arbeitsverteilungseinheit 1725 an ein GPC 1750 abgefertigt. Der GPC 1750 ist so konfiguriert, dass er die Aufgabe bearbeitet und Ergebnisse erzeugt. Die Ergebnisse können von anderen Aufgaben innerhalb des GPC 1750 verbraucht, über das XBar 1770 an einen anderen GPC 1750 weitergeleitet oder im Speicher 1704 gespeichert werden. Die Ergebnisse können über die Partitionseinheiten 1780, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in den bzw. aus dem Speicher 1704 implementieren, in den Speicher 1704 geschrieben werden. Die Ergebnisse können über den NVLink 1710 an eine andere PPU 1704 oder CPU übertragen werden. In einer Ausführungsform enthält die PPU 1700 eine Anzahl U von Partitionseinheiten 1780, die der Anzahl von separaten und getrennten Speichergeräten 1704 entspricht, die mit der PPU 1700 gekoppelt sind. Eine Partitionseinheit 1780 wird im Folgenden in Verbindung mit 18 näher beschrieben.

In einer Ausführungsform führt ein Host-Prozessor (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 21 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.

18 veranschaulicht eine Speicherpartitionseinheit 1780 der PPU 1700 von 17 gemäß einer Ausführungsform. Wie in 18 gezeigt, enthält die Speicherpartitionseinheit 1780 eine Rasteroperations-(ROP)-Einheit 1850, einen Level-2-Cache (L2-Cache) 1860 und eine Speicherschnittstelle 1870. Die Speicherschnittstelle 1870 ist mit dem Speicher 1704 gekoppelt. Die Speicherschnittstelle 1870 kann 32, 64, 128, 1024-Bit-Datenbusse oder dergleichen für Hochgeschwindigkeits-Datenübertragung implementieren. In einer Ausführungsform enthält die PPU 1700 U Speicherschnittstellen 1870, eine Speicherschnittstelle 1870 pro Paar Partitionseinheiten 1780, wobei jedes Paar Partitionseinheiten 1780 mit einem entsprechenden Speichergerät 1704 verbunden ist. Zum Beispiel kann die PPU 1700 mit bis zu Y Speichergeräten 1704 verbunden sein, wie z. B. Speicherstapel mit hoher Bandbreite oder Grafik mit Doppel-Datenrate, Version 5, Speicher mit synchronem dynamischen Direktzugriff oder anderen Arten von persistentem Speicher.

In einer Ausführungsform implementiert die Speicherschnittstelle 1870 eine HBM2-Speicherschnittstelle und entspricht U einem halben U. In einer Ausführungsform befinden sich die HBM2-Speicherstapel auf demselben physischen Gehäuse wie die PPU 1700, was im Vergleich zu herkömmlichen GDDR5-SDRAM-Systemen zu erheblichen Leistungs- und Flächeneinsparungen führt. In einer Ausführungsform enthält jeder HBM2-Stapel vier Speicher-Dies und ist Y gleich 4, wobei der HBM2-Stapel zwei 128-Bit-Kanäle pro Die für insgesamt 8 Kanäle sowie eine Datenbusbreite von 1024 Bits aufweist.

In einer Ausführungsform unterstützt der Speicher 1704 Einzelfehler korrigierenden und Doppelfehler erkennenden (SECDED) Fehlerkorrekturcode (ECC) zum Schutz von Daten. ECC bietet höhere Zuverlässigkeit für Rechenanwendungen, die empfindlich auf Datenbeschädigung reagieren. Zuverlässigkeit ist besonders wichtig in großen Cluster-Computerumgebungen, in denen PPUs 1700 sehr große Datensätze verarbeiten und/oder Anwendungen über längere Zeiträume laufen.

In einer Ausführungsform implementiert die PPU 1700 eine mehrstufige Speicherhierarchie. In einer Ausführungsform unterstützt die Speicherpartitionseinheit 1780 einen vereinheitlichten Speicher, um einen einzigen vereinheitlichten virtuellen Adressraum für Speicher der CPU und PPU 1700 bereitzustellen, der das Teilen von Daten zwischen virtuellen Speichersystemen ermöglicht. In einer Ausführungsform wird die Häufigkeit der Zugriffe einer PPU 1700 auf Speicher verfolgt, der sich auf anderen Prozessoren befindet, um sicherzustellen, dass Speicherseiten in den physischen Speicher derjenigen PPU 1700 verschoben werden, die häufiger auf die Seiten zugreift. In einer Ausführungsform unterstützt der NVLink 1710 Adressenübersetzungsdienste, die es der PPU 1700 ermöglichen, direkt auf Seitentabellen einer CPU zuzugreifen, und vollen Zugriff auf CPU-Speicher durch die PPU 1700 ermöglichen.

In einer Ausführungsform übertragen Kopier-Engines Daten zwischen mehreren PPUs 1700 oder zwischen PPUs 1700 und CPUs. Die Kopier-Engines können Seitenstörungen für Adressen erzeugen, die nicht in die Seitentabellen eingetragen sind. Die Speicherpartitionseinheit 1780 kann dann die Seitenstörungen bedienen und die Adressen in die Seitentabelle eintragen, woraufhin die Kopier-Engine die Übertragung durchführen kann. In einem herkömmlichen System ist Speicher für Mehrfach-Kopier-Engine-Operationen zwischen mehreren Prozessoren festgeheftet (d. h. nicht auslagerbar), was den verfügbaren Speicher erheblich reduziert. Bei Hardware-Seitenstörung können Adressen an die Kopier-Engines weitergegeben werden, ohne sich Sorgen zu machen, ob die Speicherseiten resident sind, und die Kopier-Operation ist transparent.

Daten aus dem Speicher 1704 oder einem anderen Systemspeicher können von der Speicherpartitionseinheit 1780 abgerufen und im L2-Cache 1860, der On-Chip (auf dem Chip) angesiedelt ist und zwischen den verschiedenen GPCs 1750 geteilt wird, gespeichert werden. Wie gezeigt, enthält jede Speicherpartitionseinheit 1780 einen Teil des L2-Cache 1860, der einem entsprechenden Speichergerät 1704 zugeordnet ist. Untergeordnete Caches können dann in verschiedenen Einheiten innerhalb der GPCs 1750 implementiert werden. Zum Beispiel kann jeder der SMs 1840 einen Level-One-Cache (L1-Cache) implementieren. Der L1-Cache ist privater Speicher, der einem bestimmten SM 1840 fest zugeordnet ist. Daten aus dem L2-Cache 1860 können abgerufen und in jedem der L1 -Caches zur Verarbeitung in den Funktionseinheiten der SMs 1840 gespeichert werden. Der L2-Cache 1860 ist mit der Speicherschnittstelle 1870 und dem XBar 1770 gekoppelt.

Die ROP-Einheit 1850 führt grafische Rasteroperationen in Bezug auf Pixelfarbe durch, wie z. B. Farbkompression, Pixel-Blending und dergleichen. Die ROP-Einheit 1850 führt auch Tiefentesten in Verbindung mit der Raster-Engine 1825 durch und empfängt eine Tiefe für eine Abtast-Position, die einem Pixelfragment zugeordnet ist, von der Culling-Engine der Raster-Engine 1825. Die Tiefe wird gegen eine entsprechende Tiefe in einem Tiefenpuffer für eine dem Fragment zugeordnete Abtast-Position getestet. Wenn das Fragment den Tiefentest für die Abtast-Position besteht, aktualisiert die ROP-Einheit 1850 den Tiefenpuffer und sendet ein Ergebnis des Tiefentests an die Raster-Engine 1825. Man beachte, dass die Anzahl der Partitionseinheiten 1780 von der Anzahl der GPCs 1750 abweichen kann und daher jede ROP-Einheit 1850 mit jeder der GPCs 1750 gekoppelt sein kann. Die ROP-Einheit 1850 verfolgt die von den verschiedenen GPCs 1750 empfangenen Pakete und bestimmt, zu welchem GPC 1750 ein von der ROP-Einheit 1850 erzeugtes Ergebnis durch das XBar 1770 geleitet wird. Obwohl die ROP-Einheit 1850 in 18 innerhalb der Speicherpartitionseinheit 1780 enthalten ist, kann sich die ROP-Einheit 1850 in einer anderen Ausführungsform außerhalb der Speicherpartitionseinheit 1780 befinden. Zum Beispiel kann sich die ROP-Einheit 1850 im GPC 1750 oder einer anderen Einheit befinden.

Beispiel-Allgemeinverarbeitungscluster

19 veranschaulicht ein GPC 1750 der PPU 1700 von 17 gemäß einer Ausführungsform. Wie in 19 gezeigt, enthält jeder GPC 1750 eine Anzahl von Hardware-Einheiten zur Bearbeitung von Aufgaben. In einer Ausführungsform enthält jeder GPC 1750 einen Pipeline-Manager 1810, eine Pre-Rasteroperationseinheit (PROP) 1815, eine Raster-Engine 1825, ein Arbeitsverteilungs-Koppelfeld (WDX) 1880, eine Speicherverwaltungseinheit (MMU) 1890 und einen oder mehrere Datenverarbeitungs-Cluster (DPCs) 1820. Man beachte, dass der GPC 1750 von 19 anstelle der oder zusätzlich zu den in 19 gezeigten Einheiten andere Hardware-Einheiten enthalten kann.

In einer Ausführungsform wird der Betrieb des GPC 1750 durch den Pipeline-Manager 1810 gesteuert. Der Pipeline-Manager 1810 verwaltet die Konfiguration der ein oder mehreren DPCs 1820 für Bearbeitung von Aufgaben, die dem GPC 1750 zugewiesen sind. In einer Ausführungsform kann der Pipeline-Manager 1810 mindestens einen der ein oder mehreren DPCs 1820 so konfigurieren, dass er mindestens einen Teil einer Grafik-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 17 gezeigten Grafikverarbeitungseinheiten mit fester Funktion umgangen, wodurch ein viel einfacheres Programmiermodell entsteht. In der Universal-Parallelberechnungs-Konfiguration weist die Arbeitsverteilungseinheit 1725 Thread-Blöcke direkt den DPCs 1820 zu und verteilt sie darauf. Die Threads in einem Block führen das gleiche Programm aus, wobei eine eindeutige Thread-ID bei der Berechnung verwendet wird, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, wobei der SM 1840 verwendet wird, um das Programm auszuführen und Berechnungen durchzuführen, der Gemeinschaftsspeicher/L1-Cache 1970, um zwischen Threads zu kommunizieren, und die LSU 1954, um über den Gemeinschaftsspeicher/L1 -Cache 1970 und die Speicherpartitionseinheit 1780 globalen Speicher zu lesen und darin zu schreiben. Bei Konfiguration für Universal-Parallelberechnung kann der SM 1840 auch Befehle schreiben, mit denen die Scheduler-Einheit 1720 neue Arbeit auf den DPCs 1820 starten kann. Die TTU 700 kann verwendet werden, um räumliche Abfragen im Kontext der Universal-Parallelberechnung zu beschleunigen.

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 18 näher beschrieben wird. Die PROP-Einheit 1815 kann auch so konfiguriert sein, dass sie Optimierungen für Farbmischung durchführt, Pixeldaten organisiert, Adressenübersetzungen durchführt und dergleichen.

Die Raster-Engine 1825 enthält eine Anzahl von Hardware-Einheiten mit fester Funktion, die so konfiguriert sind, dass sie verschiedene Rasteroperationen durchführen können. In einer Ausführungsform enthält die Raster-Engine 1825 eine Setup-Engine, eine Grobraster-Engine, eine Culling-Engine, eine Clipping-Engine, eine Feinraster-Engine und eine Kachel-Coalescing-Engine. Die Setup-Engine empfängt transformierte Vertices und generiert Ebenengleichungen, die dem geometrischen Primitiv zugeordnet sind, das durch die Vertices definiert ist. Die Ebenengleichungen werden an die Grobraster-Engine übertragen, um Abdeckungsinformationen (z. B. eine x,y-Abdeckungsmaske für eine Kachel) für das Primitiv zu generieren. Die Ausgabe der Grobraster-Engine wird zu der Culling-Engine übertragen, wo Fragmente, die dem Primitiv zugeordnet sind, dass einen Z-Test nicht besteht, einem Culling (Auslesen) unterzogen werden, und zu einer Clipping-Engine übertragen, wo Fragmente, die außerhalb eines Betrachtungsstumpfs liegen, einem Clipping (Abschneiden) unterzogen werden. Diejenigen Fragmente, die das Clipping und Culling überleben, können an die Feinraster-Engine übergeben werden, um Attribute für die Pixelfragmente auf Basis der von der Setup-Engine generierten Ebenengleichungen zu generieren. Die Ausgabe der Raster-Engine 1825 umfasst Fragmente, die zum Beispiel von einem Fragment-Shader zu verarbeiten sind, der innerhalb eines DPC 1820 implementiert ist.

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 DirectX Raytracing (DXR) API definierten Shadern und ignorieren irgendeine Unterscheidung zwischen „Nächstgelegener-Treffer“ und „Irgendein-Treffer“ -Shadern; siehe https://devblogs.nvidia.com/introduction-nvidia-rtx-directx-ray-tracing/). Zum Beispiel kann ein oder können mehrere SMs 1840 so konfiguriert sein, dass sie ein Vertex-Shader-Programm ausführen, das eine Anzahl von Vertices verarbeitet, die durch die Modelldaten definiert sind. In einer Ausführungsform können die verschiedenen SMs 1840 so konfiguriert sein, dass sie verschiedene Shader-Programme gleichzeitig ausführen. Zum Beispiel kann eine erste Teilmenge von SMs 1840 so konfiguriert sein, dass sie ein Vertex-Shader-Programm ausführt, während eine zweite Teilmenge von SMs 1840 so konfiguriert sein kann, dass sie ein Pixel-Shader-Programm ausführt. Die erste Teilmenge von SMs 1840 verarbeitet Vertexdaten zu verarbeiteten Vertexdaten und schreibt die verarbeiteten Vertexdaten in den L2-Cache 1860 und/oder den Speicher 1704 (siehe 18). 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.

20 ist ein Konzeptdiagramm einer mittels der PPU 1700 von 17 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 16 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 20 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.

21 veranschaulicht den Streaming-Multiprozessor 1840 von 19 gemäß einer Ausführungsform. Wie in 21 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. 22 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.

22 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 Supercomputern eingesetzt, um immer größere Probleme zu lösen. Mit zunehmender Anzahl von Verarbeitungsgeräten innerhalb der Hochleistungssysteme müssen die Kommunikations- und Datenübertragungsmechanismen skaliert werden, um die erhöhte Bandübertragung zwischen den Verarbeitungsgeräten zu unterstützen.

23 ist ein Konzeptdiagramm eines unter Verwendung der PPU 1700 von 17 implementierten Verarbeitungssystems 2000 gemäß einer Ausführungsform. Das Beispiel-System 2000 kann so konfiguriert sein, dass es eines oder mehrere der in dieser Anmeldung offenbarten Verfahren implementiert. Das Verarbeitungssystem 2000 enthält eine CPU 1930, einen Switch 1910 und jeweils mehrere PPUs 1700 und entsprechende Speicher 1704. Der NVLink 1710 stellt Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 1700 bereit. Obwohl in 23 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 23 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 23 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.

24 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 14563872 [0001]
US 9582607 [0001, 0017, 0048, 0111]
US 9552664 [0001]
US 9569559 [0001, 0017]
US 10025879 [0001]
US 14737343 [0001]
US 20160070820 [0017]
US 20160070767 [0017]
US 14697480 [0110]
US 16101148 [0117]
US 16101066 [0117]
US 16101180 [0119]

Zitierte Nicht-Patentliteratur

Siehe z. B. Hery et al., „Towards Bidirectional Path Tracing at Pixar“ (2016) [0011]

Claims

Verfahren, das von einem Multiprozessor durchgeführt wird, um eine Operation auf einem kommunikativ gekoppelten Koprozessor auszuführen, wobei das Verfahren umfasst: Herstellen einer Verbindung zu dem Koprozessor; Ausgeben einer Vielzahl von Schreibanweisungen, um Eingabedaten für die Operation in für den Koprozessor zugreifbare Speicherorte zu schreiben; Ausgeben einer Operationsanweisung, um den Koprozessor zu veranlassen, die Operation unter Verwendung der Eingabedaten auszuführen; Ausgeben einer Vielzahl von Leseanweisungen, um Ergebnisdaten der Operation von für den Koprozessor zugreifbaren Speicherorten an für den Multiprozessor zugreifbare Speicherorte zu schreiben; und Schließen der Verbindung.
Verfahren nach Anspruch 1, das weiterhin umfasst, zu sperren, bis das Herstellen einer Verbindung vollendet ist.
Verfahren nach Anspruch 2, wobei das Sperren, bis das Herstellen einer Verbindung vollendet ist, die einzelne Sperranweisung zwischen dem Herstellen und dem Schließen ist.
Verfahren nach Anspruch 2 oder 3, das weiterhin umfasst: nach dem Schließen auf die in einen oder mehrere der für den Multiprozessor zugreifbaren Speicherorte zu schreibenden Ergebnisdaten zu warten; und nach dem Warten die Ergebnisdaten in den für den Multiprozessor zugreifbaren Speicherorten zu verbrauchen.
Verfahren nach Anspruch 4, das weiterhin eine oder mehrere andere Anweisungen zwischen dem Schließen und dem Warten auf die zu schreibenden Ergebnisdaten umfasst.
Verfahren nach Anspruch 5, wobei die eine oder mehreren anderen Anweisungen mindestens eine weitere Sequenz von Anweisungen umfassen, die eine Anweisung, eine zweite Verbindung zu dem Koprozessor herzustellen, und eine Anweisung zum Schließen der zweiten Verbindung umfassen.
Verfahren nach einem der Ansprüche 4 bis 6, wobei das Warten umfasst, auf ein Scoreboard zu warten.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Operationsanweisung die einzige Verarbeitungsanweisung zwischen der Vielzahl von Schreibanweisungen und der Vielzahl von Leseanweisungen ist.
Verfahren nach Anspruch 8, wobei die Operationsanweisung ein sofortiges Identifizieren der Operation unter einer Vielzahl von Operationen, die auf dem Koprozessor ausführbar sind, umfasst.
Verfahren nach Anspruch 8 oder 9, wobei die Operationsanweisung keine Operanden enthält.
Verfahren nach einem der Ansprüche 2 bis 10, das weiterhin umfasst, eine Makroinitiierungsanweisung auszugeben, wobei die Makroinitiierungsanweisung bewirkt, dass eine vorbestimmte Anzahl von Anweisungen im Anschluss an die Makroinitiierungsanweisung ohne dazwischen liegende Präemption ausgeführt wird.
Verfahren nach Anspruch 11, wobei die vorbestimmte Anzahl auf Basis eines Operanden der Makroinitiierungsanweisung bestimmt wird.
Verfahren nach Anspruch 11 oder 12, wobei die Makroinitiierungsanweisung bewirkt, dass Interrupts für eine vorbestimmte Anzahl von nachfolgenden Anweisungen unterbunden werden.
Verfahren nach einem der Ansprüche 11 bis 13, wobei die Makroinitiierungsanweisung das Sperren, bis das Herstellen einer Verbindung vollendet ist, umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Operation den Koprozessor veranlasst, eine Vielzahl von Teiloperationen auszuführen, und wobei das Verfahren weiterhin umfasst, dass einer oder mehrere der für den Multiprozessor zugreifbaren Speicherorte Daten von jeweiligen der Teiloperationen auf eine zeitversetzte Weise empfängt bzw. empfangen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Eingabedaten aus Registern in dem Multiprozessor in einen lokalen Speicher des Koprozessors geschrieben werden.
System, das einen Multiprozessor und einen kommunikativ gekoppelten Koprozessor aufweist, wobei der Multiprozessor konfiguriert ist, um ein Verfahren wie in einem der Ansprüche 1 bis 16 erwähnt durchzuführen.