DE102019102821A1

DE102019102821A1 - Verfahren zur behandlung von ungeordneten opak- und alphastrahl/primitiv-schnittpunkten

Info

Publication number: DE102019102821A1
Application number: DE102019102821.3A
Authority: DE
Inventors: Samuli Laine; Tero Karras; Greg Muthler; William Parsons Jr. Newhall; Ronald Charles Babich; Ignacio Llamas; John Burgess
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2018-08-10
Filing date: 2019-02-05
Publication date: 2020-02-13
Also published as: US10740952B2; US20220020202A1; CN110827390B; US20200357159A1; US11164360B2; CN110827390A; US11790595B2; US20230410410A1; US20200051316A1

Abstract

Ein hardwarebasierter Traversierungs-Koprozessor ermöglicht Beschleunigung von Baumtraversierungs-Operationen, die nach Schnittpunkten zwischen in einer Baumdatenstruktur dargestellten Primitiven und einem Strahl suchen. Die Primitive können opake und Alpha-Dreiecke umfassen, die beim Erzeugen einer virtuellen Szene verwendet werden. Der hardwarebasierte Traversierungs-Koprozessor ist konfiguriert, um von dem Strahl geschnittene Primitive zu bestimmen und Schnittpunkt-Informationen an einen Streaming-Multiprozessor für weitere Verarbeitung zurückzugeben. Der hardwarebasierte Traversierungs-Koprozessor ist konfiguriert, um ein deterministisches Ergebnis von geschnittenen Dreiecken unabhängig von der Reihenfolge zu liefern, in der das Speicher-Subsystem Dreieck-Bereich-Blöcke zur Verarbeitung zurückgibt, während Alpha-Schnittpunkte, die entlang der Länge des Strahls weiter weg liegen als nähere Opak-Schnittpunkte, opportunistisch beseitigt werden.

Description

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

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

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

Detaillierte Beschreibung von nicht einschränkenden Ausführungsformen
Die Technik hierin stellt Hardwarefähigkeiten bereit, welche Strahlverfolgung so weit beschleunigen, dass sie Spielen und anderen interaktiven Echtzeit-Computergrafiken die Leistung der Strahlverfolgung beschert, wodurch zunächst hohe Effektqualität bei Schatten und Reflexionen und schließlich globale Beleuchtung ermöglicht wird. In der Praxis bedeutet dies, die Strahlverfolgung gegenüber dem, was in Software auf demselben Grafik-Render-System möglich wäre, um einen Faktor bis zu einer Größenordnung oder mehr zu beschleunigen.
Insbesondere stellt die nicht einschränkende Beispiel-Technik dedizierte Hardware zum Beschleunigen von Strahlverfolgung bereit. In nicht einschränkenden Ausführungsformen beschleunigt ein Hardware-Koprozessor (hierin als „Traversierungs-Koprozessor“ oder in manchen Ausführungsformen als „Baumtraversierungseinheit“ oder „TTU“ bezeichnet) bestimmte Prozesse, die interaktive Strahlverfolgung unterstützen, einschließlich Strahlbegrenzungsvolumen-Schnittpunkttests, Strahl-Primitiv-Schnittpunkttests und Strahl-„Instanz“-Transformationen.
In manchen nicht einschränkenden Ausführungsformen führt der Traversierungs-Koprozessor Abfragen auf einer Beschleunigungsdatenstruktur für Prozesse durch, die auf potenziell massiv-parallelen Streaming-Multiprozessoren (SMs) laufen. Der Traversierungs-Koprozessor traversiert die Beschleunigungsdatenstruktur, um Informationen darüber herauszufinden, wie ein gegebener Strahl mit einem Objekt wechselwirkt, das die Beschleunigungsdatenstruktur beschreibt oder darstellt. Für Strahlverfolgung sind die Traversierungs-Koprozessoren aufrufbar, im Gegensatz zu z. B. Einheiten mit fester Funktion, die eine Operation einmal zwischen logischen Pipeline-Stufen durchführen, die verschiedene Typen von Threads (z. B. Vertex-Threads und Pixel-Threads) laufen lassen.
In manchen nicht einschränkenden Ausführungsformen umfasst die Beschleunigungsdatenstruktur eine Hierarchie von Begrenzungsvolumina (Begrenzungsvolumenhierarchie oder BVH), die rekursiv immer kleiner werdende Begrenzungsvolumen-Unterteilungen einkapselt. Das größte volumetrische Begrenzungsvolumen kann als „Wurzelknoten“ bezeichnet werden. Die kleinsten Unterteilungen einer solchen Hierarchie von Begrenzungsvolumina („Blattknoten“) enthalten Elemente. Die Elemente könnten Primitive (z. B. Polygone wie z. B. Dreiecke) sein, die Oberflächen des Objekts definieren. Oder ein Element könnte ein Bereich sein, der eine ganz neue Ebene der Welt enthält, die als ein Element existiert, da sie der BVH nicht hinzugefügt worden ist (denken Sie an den Halsbandanhänger an der Katze aus „Men in Black“, der eine ganze Miniaturgalaxie darin enthielt). Wenn das Element Primitive umfasst, testet der Traversierungs-Koprozessor Strahlen gegen die Primitive, um zu bestimmen, welche Objektoberflächen die Strahlen schneiden und welche Objektoberflächen entlang des Strahls sichtbar sind.
Der Traversierungs-Koprozessor führt einen Test eines jeden Strahls gegen einen weiten Bereich von Begrenzungsvolumina durch und kann irgendwelche Begrenzungsvolumina, die sich nicht mit diesem Strahl schneiden, aussondern (einem Culling unterziehen). Beginnend an einem Wurzelknoten, der alles in der Szene begrenzt, testet der Traversierungs-Koprozessor jeden Strahl gegen kleinere (potenziell überlappende) Kind-Begrenzungsvolumina, die wiederum die nachkommenden Zweige der BVH begrenzen. Der Strahl folgt den Kind-Zeigern für die Begrenzungsvolumina, die der Strahl trifft, zu anderen Knoten, bis die Blätter oder Endknoten (Volumina) der BVH erreicht sind. Sobald der Traversierungs-Koprozessor die Beschleunigungsdatenstruktur traversiert, um einen End- oder „Blatt“-Knoten zu erreichen, der ein geometrisches Primitiv enthält, führt er einen beschleunigten Strahl-Primitiv-Schnittpunkttest durch, der bestimmt, ob der Strahl dieses Primitiv (und somit die von diesem Primitiv definierte Objektoberfläche) schneidet. Der Strahl-Primitiv-Test kann zusätzliche Informationen über Primitive liefern, die der Strahl schneidet, mit denen die Materialeigenschaften der Oberfläche bestimmt werden können, die für Shading und Visualisierung erforderlich sind. Rekursive Traversierung durch die Beschleunigungsdatenstruktur ermöglicht es dem Traversierungs-Koprozessor, alle Objekt-Primitive zu entdecken, die der Strahl schneidet, oder das nächstgelegene (aus der Perspektive des Standpunkts) Primitiv, das der Strahl schneidet (welches in manchen Fällen das einzige Primitiv ist, das von dem Standpunkt aus entlang des Strahls sichtbar ist).
Der Traversierungs-Koprozessor beschleunigt auch die Transformation jedes Strahls aus dem Welt-Raum in den Objekt-Raum, um immer feiner werdende Begrenzungskasten-Einkapselungen der Primitive zu erhalten und die Duplikation dieser Primitive in der gesamten Szene zu reduzieren. Objekte, die viele Male in der Szene in verschiedenen Positionen, Orientierungen und Maßstäben repliziert werden, können in der Szene als Instanzknoten, die einem Begrenzungskasten und Blattknoten in der Welt-Raum-BVH eine Transformation zuordnen, die auf den Welt-Raum-Strahl angewendet werden kann, um ihn in einen Objektkoordinatenraum zu transformieren, und ein Zeiger auf eine Objekt-Raum-BVH dargestellt werden. Dadurch wird vermieden, dass die Objekt-Raum-BVH-Daten mehrere Male im Welt-Raum repliziert werden, was Speicher und zugehörige Speicherzugriffe spart. Die Instanztransformation erhöht die Effizienz, indem sie den Strahl in den Objekt-Raum transformiert, statt die Geometrie oder die Begrenzungsvolumenhierarchie in den Welt-Raum (Strahl-Raum) transformieren zu müssen, und ist außerdem mit zusätzlichen, konventionellen Rasterungsprozessen kompatibel, welche die Grafikverarbeitung zur Visualisierung der Primitive durchführt.
Die vorliegend offenbarten nicht einschränkenden Ausführungsformen stellen somit einen Traversierungs-Koprozessor, eine neue Untereinheit eines oder einer Gruppe von Streaming-Multiprozessoren SM einer 3D-Grafikverarbeitungs-Pipeline bereit. Um zu verstehen, wo der Traversierungs-Koprozessor in das Gesamtbild passt, kann es hilfreich sein, einige Grundlagen des Algorithmus zu verstehen, der von den meisten oder allen modernen Strahlverfolgern verwendet wird. Man beachte jedoch, dass die Technik hierin eine generische Fähigkeit bietet, für einen Thread, der in einer GPU läuft, zu bestimmen, was das nächst sichtbare Ding von einem gegebenen Punkt entlang einer spezifizierten Richtung ist oder ob irgendetwas zwischen zwei Punkten liegt. Ein häufiger Anwendungsfall für eine solche Fähigkeit wird in Prozessen liegen, die beginnen, Strahlen von Punkten zu verfolgen, die bereits mittels konventioneller Abtastsignalwandlungs-Techniken auf Dreiecken gerastert worden sind. Die offenbarte Technik kann, muss aber nicht notwendigerweise die Abtastsignalwandlungs-Technik ersetzen oder substituieren, und kann sie sie oft ergänzen und kann in Verbindung mit Abtastsignalwandlungs-Techniken verwendet werden, um Bilder mit fotorealistischen Reflexionen, Schatten und anderen Effekten zu verbessern.
Strahlverfolgungs-Techniken
Im Allgemeinen ist Strahlverfolgung ein Render-Verfahren, bei dem Strahlen verwendet werden, um die Sichtbarkeit verschiedener Elemente in der Szene zu bestimmen. Strahlverfolgung kann verwendet werden, um zu bestimmen, ob entlang eines Strahls irgendetwas sichtbar ist (zum Beispiel Testen auf Verdeckungen zwischen einem abgeschatteten Punkt auf einem geometrischen Primitiv und einem Punkt auf einer Lichtquelle) und kann auch zum Bewerten von Reflexionen verwendet werden (was zum Beispiel die Durchführung einer Traversierung zum Bestimmen der nächstgelegenen sichtbaren Oberfläche entlang einer Sichtlinie umfassen kann, so dass Software, die auf einem Streaming-Prozessor läuft, eine Materialschattierungsfunktion entsprechend dem, was getroffen worden ist, bewerten kann - was wiederum einen oder mehrere zusätzliche Strahlen in die Szene entsprechend den Materialeigenschaften des Objekts, das geschnitten worden ist, starten kann), um das Licht zu bestimmen, das entlang des Strahls zurück zum Auge gelangt. Bei Strahlverfolgung im klassischen Whitted-Stil werden Strahlen vom Standpunkt durch das Pixelraster in die Szene geschossen, doch sind auch andere Pfadtraversierungen möglich. Typischerweise wird für jeden Strahl das nächstgelegene Objekt gefunden. Dieser Schnittpunkt kann dann als beleuchtet oder im Schatten bestimmt werden, indem ein Strahl von ihm zu jeder Lichtquelle in der Szene geschossen wird und festgestellt wird, ob sich dazwischen irgendwelche Objekte befinden. Opake Objekte blockieren das Licht, während transparente Objekte es abschwächen. Andere Strahlen können von einem Schnittpunkt aus erzeugt werden. Wenn zum Beispiel die schneidende Oberfläche glänzend oder spiegelnd ist, werden Strahlen in der Reflexionsrichtung erzeugt. Der Strahl kann die Farbe des ersten geschnittenen Objekts annehmen, dessen Schnittpunkt wiederum auf Schatten getestet worden ist. Dieser Reflexionsprozess wird rekursiv wiederholt, bis eine Rekursionsgrenze erreicht ist oder der potenzielle Beitrag nachfolgender Aufpralle unter einen Schwellenwert fällt. Strahlen können auch in der Brechungsrichtung für transparente massive Objekte erzeugt werden und wieder rekursiv bewertet werden. Siehe Akenine-Möller et al., oben zitiert. Die Strahlverfolgungs-Technik ermöglicht es einem Grafiksystem somit, physikalisch korrekte Reflexionen und Schatten zu entwickeln, die nicht den Einschränkungen und Artefakten von Abtastsignalwandlungs-Techniken unterliegen.
Traversierungs-Koprozessor
Die grundlegende Aufgabe, die der Traversierungs-Koprozessor durchführt, besteht darin, einen Strahl gegen alle Primitive (in einer Ausführungsform gewöhnlich Dreiecke) in der Szene zu testen und je nach Anwendungsfall entweder den nächstgelegenen Treffer (entsprechend der entlang des Strahls gemessenen Entfernung) oder einfach den ersten (nicht notwendigerweise nächstgelegenen) angetroffenen Treffer zu melden. Der natürliche Algorithmus wäre eine O(n)-Brute-Force-Suche. Durch Vorverarbeiten der Szenengeometrie und Aufbauen einer geeigneten Beschleunigungsdatenstruktur im Voraus ist es jedoch möglich, die Komplexität im Durchschnittsfall auf O(log n) zu reduzieren. Bei Strahlverfolgung liegt die Zeit für das Finden des nächstgelegenen (oder für Schatten beliebigen) Schnittpunkts für einen Strahl typischerweise in der Größenordnung O(log n) für n Objekte, wenn eine Beschleunigungsdatenstruktur verwendet wird. Zum Beispiel haben Begrenzungsvolumenhierarchien (BVHs) von dem für moderne Strahlverfolgungs-Beschleunigungsdatenstrukturen gewöhnlich verwendeten Typ typischerweise ein O(log n)-Suchverhalten.
Begrenzungsvolumenhierarchien
Die von modernen Strahlverfolgern am häufigsten verwendete Beschleunigungsdatenstruktur ist eine Begrenzungsvolumenhierarchie (BVH), die verschachtelte, achsenausgerichtete Begrenzungskästen (AABBs) aufweist. Die Blattknoten der BVH enthalten die Primitive (z. B. Dreiecke), die auf Schnittpunkte zu testen sind. Die BVH wird am häufigsten durch eine Graph- oder Baumstruktur-Datendarstellung dargestellt. In solchen Fällen kann der Traversierungs-Koprozessor als „Baumtraversierungseinheit“ oder „TTU“ bezeichnet werden.
Bei einer BVH entsprechen Strahlverfolgungsmengen einer Baumsuche, bei der jeder von dem Strahl besuchte Knoten im Baum ein Begrenzungsvolumen für jeden nachkommenden Zweig oder Blatt aufweist und der Strahl nur die nachkommenden Zweige oder Blätter besucht, deren entsprechendes Begrenzungsvolumen er schneidet. Auf diese Weise muss nur eine kleine Anzahl von Primitiven explizit auf Schnittpunkte getestet werden, nämlich diejenigen, die sich in Blattknoten befinden, die von dem Strahl geschnitten werden. In dem nicht einschränkenden Ausführungsbeispiel beschleunigt der Traversierungs-Koprozessor sowohl Baumtraversierungs- (einschließlich der Strahl-Volumen-Tests) als auch Strahl-Primitiv-Tests. Als Teil der Traversierung kann der Traversierungs-Koprozessor auch „Instanztransformationen“ handhaben - Transformieren eines Strahls von Welt-Raum-Koordinaten in das Koordinatensystem eines instanzierten Maschennetzes (Objekt-Raum), z. B. um die Rechenkomplexität des Transformierens der Primitiv-Vertices in den Welt-Raum zu vermeiden. Dies kann auf eine MIMD (Multiple Instruction, Multiple Data) Weise geschehen, was bedeutet, dass die Strahlen unabhängig behandelt werden, sobald sie sich im Traversierungs-Koprozessor befinden.
Nicht einschränkendes Beispiel für interaktives Echtzeit-Strahlverfolgungssystem
1 veranschaulicht ein Beispiel für ein interaktives Echtzeit-Strahlverfolgungsgrafiksystem 100 zum Erzeugen von Bildern unter Verwendung dreidimensionaler (3D) Daten einer Szene oder eines oder mehrerer Objekte. Das System 100 enthält ein Eingabegerät 110, einen oder mehrere Prozessoren 120, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 130, Speicher 140 und ein oder mehrere Displays 150. Das in 1 gezeigte System kann irgendeinen Formfaktor annehmen, einschließlich, aber nicht beschränkt auf einen PC, ein Smartphone oder ein anderes smartes Gerät, ein Videospielsystem, ein tragbares Virtual- oder Augmented-Reality-System, ein Cloud-basiertes Computersystem, ein fahrzeugmontiertes Grafiksystem, ein System auf einem Chip (SoC; System-on-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.
In den nicht einschränkenden Ausführungsbeispielen ermöglicht der Traversierungs-Koprozessor 138 schnelle Traversierung einer Beschleunigungsdatenstruktur (z. B. einer BVH), um zu bestimmen, welche Primitive (z. B. Dreiecke, die zur Erzeugung einer Szene verwendet werden) in der Datenstruktur von einer Abfragedatenstruktur (z. B. einem Strahl) geschnitten werden. Der Traversierungs-Koprozessor 138 bietet Lösungen für Probleme im Zusammenhang mit der Praxis des TTU-beschleunigten Strahlverfolgungs-Renderns in einer Softwareanwendung, die auf einer GPU läuft. Nicht einschränkende Ausführungsbeispiele dieser Offenbarung können zum Beispiel die im US-Patent Nr. 9,582,607 beschriebene Baumtraversierungseinheit (Tree Traversal Unit; TTU) und das im US-Patent Nr. 9,569,559 beschriebene Strahlverfolgungsverfahren erweitern, um Strahl/Dreieck-Schnittpunkt mitten in der Traversierung zu unterstützen, so dass Dreiecke direkt von der TTU behandelt werden können, ohne SM-Intervention zu benötigen, wodurch häufige aufwändige Synchronisationen vermieden werden, die ohne nicht einschränkende Ausführungsbeispiele dieser Offenbarung möglicherweise erforderlich sind. Die US-Patente Nr. 9,582,607 und 9,569,559 werden durch Bezugnahme aufgenommen.
In den nicht einschränkenden Ausführungsbeispielen ermöglicht der Traversierungs-Koprozessor 138 schnelle Traversierung einer Beschleunigungsdatenstruktur (z. B. einer BVH), um zu bestimmen, welche Primitive (z. B. Dreiecke, die zur Erzeugung einer Szene verwendet werden) in der Datenstruktur von einer Abfragedatenstruktur (z. B. einem Strahl) geschnitten werden. Zum Beispiel kann der Traversierungs-Koprozessor 138 bestimmen, welche Dreiecke in der Beschleunigungsdatenstruktur von dem Strahl geschnitten werden, und einen nächstgelegenen Opak-Treffer und/oder einen oder mehrere Alpha-Treffer an den SM 132 zurückgeben. Da die Rückgabe eines Ergebnisses an den SM 132 bei jedem Dreieck-Schnittpunkt im Hinblick auf Schnittstellen- und Thread-Synchronisation aufwendig ist, kann der Traversierungs-Koprozessor 138 einige der geschnittenen Dreiecke aus den dem SM 132 gelieferten Ergebnissen auslassen. Die ausgelassenen Dreiecke umfassen möglicherweise nur Dreiecke, die nachweislich ohne funktionalen Einfluss auf die Visualisierung der virtuellen Szene ausgelassen werden können.
Der Traversierungs-Koprozessor 138 kann eine Ergebniswarteschlange zum Speichern von Schnittpunkt-Informationen von geschnittenen Primitiven, bis die Schnittpunktergebnisse an den SM 132 zurückgegeben werden, enthalten. In manchen Fällen kann die Ergebniswarteschlange mit Schnittpunkten gefüllt sein, bevor alle Primitive in dem Primitiv-Bereich getestet sind. Wenn die Ergebniswarteschlange mit Ergebnissen gefüllt ist und ein zusätzliches geschnittenes Primitiv identifiziert wird, kann der Traversierungs-Koprozessor 138 die Schnittpunkt-Informationen in der Ergebniswarteschlange an den SM 132 zurückgeben und eine aktualisierte Abfrage vom SM 132 empfangen, um das Testen des Primitiv-Bereichs auf zusätzliche Schnittpunkte mit dem Strahl fortzusetzen.
Der Primitiv-Bereich kann über mehrere Blöcke in Cache-Zeilen-Größe verteilt sein, die in Speicher gespeichert sind. Auf eine Anforderung, den Primitiv-Bereich auf Strahl-Primitiv-Schnittpunkte zu testen, werden die Blöcke dem Traversierungs-Koprozessor 138 zur Verarbeitung zugeführt. Aufgrund der Hierarchie des Speichersystems 140 werden die Blöcke dem Traversierungs-Koprozessor 138 möglicherweise in zufälliger Reihenfolge zur Verarbeitung zugeführt. Eine Option für den Traversierungs-Koprozessor 138 ist, sämtliche Blöcke zu empfangen, bevor der Primitiv-Schnittpunkttest gestartet wird, so dass die Blöcke in der Reihenfolge verarbeitet werden können, in der sie in Speicher gespeichert sind. Diese Methode wird die geschnittenen Primitive in der Reihenfolge identifizieren, in der sie in Speicher gespeichert sind, und ein deterministisches Ergebnis an den SM 132 senden. Zu warten, bis alle Blöcke aus dem Speicher 140 ausgelesen worden sind, bevor der Primitiv-Schnittpunkttest gestartet wird, ist jedoch zeitaufwendig und bietet möglicherweise nicht die für die Echtzeit-Strahlverarbeitung erforderlichen Verarbeitungsgeschwindigkeiten.
In manchen nicht einschränkenden Ausführungsbeispielen kann der Traversierungs-Koprozessor 138 die Blöcke so verarbeiten, wie sie aus dem Speicher 140 empfangen werden, statt darauf zu warten, dass alle Blöcke empfangen worden sind, und die Blöcke in Speicherreihenfolge zu verarbeiten. Die Blöcke in der Reihenfolge zu verarbeiten, in der sie aus dem Speicher empfangen werden, liefert jedoch möglicherweise keine deterministischen Ergebnisse. Insbesondere werden möglicherweise keine deterministischen Ergebnisse geliefert, wenn die Dreiecke nicht in Speicherreihenfolge verarbeitet werden und wegen einer geringen Größe der Ergebniswarteschlange mehrere Rückgaben der Schnittpunktergebnisse an den SM 132 erfolgen müssen.
Wenn zum Beispiel die gleiche Abfrage vom Traversierungs-Koprozessor 138 verarbeitet wird, werden die geschnittenen Primitive möglicherweise jedes Mal in einer anderen Reihenfolge bestimmt und dem SM 132 identifiziert, da die Blöcke der TTU 700 möglicherweise jedes Mal in einer anderen Reihenfolge zugeführt werden. Da der SM 132 konfiguriert ist, um die Schnittpunktergebnisse zu verwenden, um weitere Verarbeitung und/oder Ausgabe zusätzlicher Schnittpunkt-Abfragen durchzuführen, kann der SM 132 möglicherweise keine zuverlässige Bildqualität und Stabilität in Szenen gewährleisten, wenn die Ergebnisse nicht auf eine deterministische Weise geliefert werden.
Um stabile Bilder ohne störende Artefakte zu erzeugen, kann der Traversierungs-Koprozessor 138 konfiguriert sein, um die Traversierung durchzuführen, die für eine Abfrage bei einem Strahl und einem Primitiv-Bereich, der eine Mischung aus opaken und Alpha-Primitiven enthält, die sich über mehrere Blöcke erstrecken, unabhängig von der Reihenfolge, in der das Speicher-Subsystem diese Blöcke an den Koprozessor zurückgibt, ein deterministisches Ergebnis erzeugt. Nicht einschränkende Ausführungsbeispiele stellen einen Traversierungs-Koprozessor 138 bereit, der konfiguriert ist, um deterministische Schnittpunktergebnisse unabhängig von der Reihenfolge zu erzeugen, in der der Speicher 140 die Blöcke mit Primitiven an den Traversierungs-Koprozessor 132 zurückgibt, während er opportunistisch Primitive aus den Ergebnissen auslässt, die nachweislich ohne funktionalen Einfluss auf die Visualisierung der virtuellen Szene ausgelassen werden können. Deterministische Ergebnisse können durch Rückgabe von Schnittpunktergebnissen für manche Primitive (z. B. Alpha-Primitive) in einer gespeicherten Speicherreihenfolge und nicht in der räumlichen Reihenfolge, in der sie sich in der Szene befinden, oder in der Reihenfolge, in der die Schnittpunkte bestimmt werden, an den SM 132 geliefert werden.
Der Traversierungs-Koprozessor 138 kann konfiguriert sein, um stabile Bilder ohne störende Artefakte mit Traversierungs-Regeln zu erzeugen, die für eine Abfrage bei einem Strahl und einem Primitiv-Bereich, der eine Mischung aus opaken und Alpha-Primitiven enthält, die sich über mehrere Blöcke erstrecken, unabhängig von der Reihenfolge, in der das Speicher-Subsystem diese Blöcke an den Traversierungs-Koprozessor 138 zurückgibt, ein deterministisches Ergebnis liefern.
Der Traversierungs-Koprozessor 138 kann konfiguriert sein, um eine Anzahl von Rückgaben an den SM mitten in der Traversierung durchzuführen, um Alpha-Schnittpunkte zu verarbeiten, deren Anzahl und Inhalt nicht von Durchlauf zu Durchlauf variieren. Wie im Folgenden näher erörtert wird, können Änderungen in der Reihenfolge der an den Traversierungs-Koprozessor 138 zurückgegebenen Blöcke eine unterschiedliche Reihenfolge von Opak-Schnittpunkten erzeugen, die unterschiedliche Sätze von innerhalb desselben Primitiv-Bereichs gefundenen Alpha-Schnittpunkten maskieren können oder nicht. Der in dieser Anmeldung offenbarte Traversierungs-Koprozessor 138 enthält eine Ergebniswarteschlange und Regeln für die Verarbeitung ungeordneter Blöcke, um sicherzustellen, dass die aus der abgeschlossenen Verarbeitung des Primitiv-Bereichs resultierenden Nebenwirkungen von Durchlauf zu Durchlauf konsistent sind.
In einem Ausführungsbeispiel verkürzt die Schnittpunktverwaltungseinheit im Traversierungs-Koprozessor 138 den Strahl möglicherweise nur und gibt den Inhalt der Ergebniswarteschlange an den SM zurück, nachdem alle Blöcke verarbeitet worden sind und der nächstgelegene Opak-Schnittpunkt gefunden worden ist. Die Schnittpunktverwaltungseinheit kann konfiguriert sein, um sicherzustellen, dass jeder Alpha-Schnittpunkt, der vor dem nächstgelegenen Opak-Schnittpunkt erscheint, dem SM in Speicherreihenfolge präsentiert wird, so dass die Anzahl und der Inhalt nicht von Durchlauf zu Durchlauf variieren würden.
In manchen Ausführungsbeispielen können die Anzahl und der Inhalt der Rückgaben an den SM als Funktion der Anzahl der Einträge in der Ergebniswarteschlange variieren. Wie im Folgenden näher erörtert wird, ermöglichen Ausführungsformen dieser Offenbarung, dass die Anzahl der Einträge in der Ergebniswarteschlange und/oder die Anzahl der identifizierten Ergebnisse keinen Einfluss auf die funktionale Korrektheit des Bildes hat und nicht als Folge der Speicherrückgabereihenfolge von Durchlauf zu Durchlauf variiert.
Nicht einschränkende Ausführungsbeispiele dieser Offenbarung verbessern die Strahlverfolgungs-Leistung, ohne die Bildqualität zu beeinträchtigen. Durch Unterstützung von beschleunigtem Strahl/Dreieck-Schnittpunkt während der Traversierung ist die TTU im Stande, die Streaming-Prozessoren von einer beträchtlichen Berechnungsmenge zu entlasten und eine teure Synchronisationsleistungseinbuße zu vermeiden. Da Echtzeit-Strahlverfolgung ebenso gute oder bessere Bildqualität und Stabilität bieten muss wie Echtzeit-Rasterung, ist es wichtig, dass der Strahl-Dreieck-Schnittpunkt der TTU die Eigenschaften von Hieb- und Stichfestigkeit, Konservatismus und Einzeltreffer aufweist. Nicht einschränkende Ausführungsbeispiele dieser Offenbarung ermöglichen die Anwendung von Echtzeit-Strahlverfolgung in Echtzeit-Spielen, die Millionen von Dreiecken verwenden.
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 O1-O8 einschließt. Der Wurzelknoten N1 kann die Vertices des Begrenzungsvolumens N1 und Kind-Knoten des Wurzelknotens identifizieren.
In 8A ist das Begrenzungsvolumen N1 in Begrenzungsvolumina N2 und N3 unterteilt. Die Kind-Knoten N2 und N3 der Baumstruktur von 8B entsprechen den in 8A gezeigten Begrenzungsvolumina N2 und N3 und stellen sie dar. Die Kind-Knoten N2 und N3 in der Baumdatenstruktur identifizieren die Vertices der jeweiligen Begrenzungsvolumina N2 und N3 im Raum. Jedes der Begrenzungsvolumina N2 und N3 ist in diesem bestimmten Beispiel weiter unterteilt. Das Begrenzungsvolumen N2 ist in enthaltene Begrenzungsvolumina N4 und N5 unterteilt. Das Begrenzungsvolumen N3 ist in enthaltene Begrenzungsvolumina N6 und N7 unterteilt. Das Begrenzungsvolumen N7 enthält zwei Begrenzungsvolumina N8 und N9. Das Begrenzungsvolumen N8 enthält die Dreiecke O7 und O8, und das Begrenzungsvolumen N9 enthält Blatt-Begrenzungsvolumina N10 und N11 als seine Kind-Begrenzungsvolumina. Das Blatt-Begrenzungsvolumen N10 enthält einen Primitiv-Bereich (z. B. Dreieck-Bereich) O10, und das Blatt-Begrenzungsvolumen N11 enthält einen Element-Bereich O9. Jeweilige Kind-Knoten N4, N5, N6, N8, N10 und N11 der Baumstruktur von 8B entsprechen den Begrenzungsvolumina N4, N5, N6, N8, N10 und N11 von 8A im Raum und stellen sie dar.
Der Baum in 8B ist nur drei bis sechs Ebenen tief, so dass die Volumina N4, N5, N6, N8, N10 und N11 „Blattknoten“ bilden - das heißt, Knoten im Baum, die keine Kind-Knoten haben. 8A zeigt, dass jedes der Blattknoten-Begrenzungsvolumina N4, N5, N6 und N8 zwei Dreiecke der Geometrie in der Szene enthält. Zum Beispiel enthält die volumetrische Unterteilung N4 die Dreiecke O1 & O2; die volumetrische Unterteilung N5 enthält die Dreiecke O3 & O4; die volumetrische Unterteilung N6 enthält die Dreiecke O5 & O6; und die volumetrische Unterteilung N8 enthält die Dreiecke O7 & O8. Die in 8B gezeigte Baumstruktur stellt diese Blattknoten N4, N5, N6 und N7 dar, indem sie sie entsprechenden Dreiecken der Dreiecke O1-O8 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 Entfernung), die einem jedem Begrenzungsvolumen und/oder Primitiv zugeordnet ist, der Größe eines Begrenzungsvolumens oder Primitivs in Bezug auf eine Entfernung vom Ursprung oder dem Strahl, bestimmten Instanzen eines Objekts, usw. Diese Fähigkeit kann von Anwendungen genutzt werden, um dynamisch und/oder selektiv Sätze von Objekten für Schnittpunkttests gegenüber bestimmten Sätzen oder Gruppen von Abfragen freizugeben / zu deaktivieren, zum Beispiel um verschiedene Versionen von Modellen verwenden zu können, wenn sich ein Anwendungsstatus ändert (zum Beispiel beim Öffnen oder Schließen von Türen), oder um verschiedene Versionen eines Modells bereitzustellen, die als Funktion der Länge des Strahls ausgewählt werden, um eine Form von geometrischem Detaillierungsgrad zu realisieren, oder um bestimmten Sätzen von Objekten aus bestimmten Klassen von Strahlen zu erlauben, in bestimmten Ansichten manche Schichten sichtbar oder unsichtbar zu machen.
Zusätzlich zu dem Satz von Modus-Flags, die für den Strahl-Complet-Schnittpunkt und für Strahl-Primitiv-Schnittpunkte getrennt spezifiziert werden können, kann die Strahldatenstruktur andere RayOp-Test-bezogene Parameter spezifizieren, wie z. B. Strahl-Flags, Strahl-Parameter und einen RayOp-Test. Die Strahl-Flags können von der TTU 700 verwendet werden, um verschiedene Aspekte des Traversierungsverhaltens, des Backface-(Rückseiten)-Culling und der Behandlung der verschiedenen Kind-Knoten-Typen zu steuern, abhängig vom Bestehen/Nichtbestehen-Status eines optionalen RayOp-Tests. RayOp-Tests fügen daher den Fähigkeiten der TTU 700 Flexibilität hinzu, auf Kosten einer gewissen Komplexität. Die TTU 700 reserviert einen „Strahl-Slot“ für jeden aktiven Strahl, den sie verarbeitet, und kann die Strahl-Flags, Modus-Flags und/oder die RayOp-Informationen während Traversierung in dem entsprechenden Strahl-Slot-Puffer innerhalb der TTU speichern.
In dem in 10B gezeigten Beispiel führt die TTU 700 eine Top-Level-Baumtraversierung 1006 und eine Bottom-Level-Baumtraversierung 1018 durch. In dem Ausführungsbeispiel ermöglicht die Zwei-Level-Traversierung (Zwei-Ebenen-Traversierung) der BVH schnelle Strahlverfolgungsreaktionen auf dynamische Szenenänderungen.
Die Strahltransformation 1014 bietet den geeigneten Übergang von der Top-Level-Baumtraversierung 1006 zu der Bottom-Level-Baumtraversierung 1018, indem der Strahl, der bei der Top-Level-Traversierung in einem ersten Koordinatenraum (z. B. Welt-Raum) verwendet werden kann, in einen anderen Koordinatenraum (z. B. Objekt-Raum) der BVH der Bottom-Level-Traversierung transformiert wird. Eine Beispiel-BVH-Traversierungstechnik, die eine Zwei-Level-Traversierung verwendet, ist in früherer Literatur beschrieben, siehe z. B. Woop, „A Ray Tracing Hardware Architecture for Dynamic Scenes“, Universität des Saarlandes, 2004, doch sind Ausführungsformen nicht darauf beschränkt.
In manchen Ausführungsformen wird die Top-Level-Traversierung (im Welt-Raum) in einer BVH durchgeführt, die als Antwort auf Änderungen in der Szene dynamisch neu berechnet werden kann (z. B. durch den SM 132), und die Bottom-Level-Traversierung wird in einer BVH von Begrenzungsvolumina durchgeführt, die statisch oder im Wesentlichen statisch bleiben, selbst wenn Änderungen in der Szene auftreten. Die Begrenzungsvolumina in der BVH, die für die Bottom-Level-Baumtraversierung 1018 (im Objekt-Raum) verwendet werden, können detailliertere Informationen über die Szenengeometrie umfassen als die jeweiligen Begrenzungsvolumina, die bei der Top-Level-Baumtraversierung 1006 verwendet werden, wodurch die Modifizierung der Bottom-Level-Traversierungs-BVH als Antwort auf Szenenänderungen vermieden oder zumindest reduziert wird. Dies trägt dazu bei, Strahlverfolgung von dynamischen Szenen zu beschleunigen.
Beispiel Top-Level-Baumtraversierung
Die Top-Level-Baumtraversierung 1006 durch die TTU 700 empfängt Complets von dem L1-Cache 1012 und liefert eine Instanz an die Strahl-Transformation 1014 für Transformation oder eine Fehlschuss/Ende-Ausgabe 1013 an den SM 132 für Verarbeitung des Nächstgelegener-Treffer-Shaders 1015 durch den SM (dieser Block kann auch rekursiv auf Basis von Nicht-Blattknoten/Kein-Treffer-Bedingungen arbeiten). Bei der Top-Level-Baumtraversierung 1006 ruft ein Nächstes-Complet-Abruf-Schritt 1008 das nächste in Schritt 1010 auf Strahlschnittpunkte zu testende Complet aus dem Speicher und/oder der Cache-Hierarchie ab, und der Strahlbegrenzungsvolumen-Schnittpunkttest wird an den Begrenzungsvolumina im abgerufenen Complet durchgeführt.
Wie oben beschrieben, verbindet ein Instanzknoten eine BVH mit einer anderen BVH, die in einem anderen Koordinatensystem liegt. Wenn ein Kind des geschnittenen Begrenzungsvolumens ein Instanzknoten ist, ist die Strahl-Transformation 1014 im Stande, eine passende Transformationsmatrix aus dem L1-Cache 1016 auszulesen. Die TTU 700 transformiert den Strahl unter Verwendung der entsprechenden Transformationsmatrix in das Koordinatensystem der Kind-BVH. Die US-Patentanmeldung Nr. 14/697,480 , die bereits durch Bezugnahme aufgenommen worden ist, beschreibt Transformationsknoten, die einen ersten Satz von Knoten in einem Baum mit einem zweiten Satz von Knoten verbinden, wobei der erste und der zweite Satz von Knoten in verschiedenen Koordinatensystemen liegen. Die Instanzknoten in Ausführungsbeispielen können den Transformationsknoten in der US-Anmeldung Nr. 14/697,480 ähnlich sein. In einem alternativen, nicht instanzierenden Modus der TTU 700, in 10C gezeigt, führt die TTU keine „Botton“-Level-Baumtraversierung durch, und nichtinstanzierte Baum-BVH-Traversierungen werden von Blöcken 1008, 1010 durchgeführt, z. B. unter Verwendung nur eines Stapels. Die TTU 700 kann auf Basis dessen, was sie aus der BVH und/oder dem Abfragetyp liest, zwischen den instanzierten Operationen von 10B und den nichtinstanzierten Operationen von 10C umschalten. Zum Beispiel kann ein bestimmter Abfragetyp die TTU darauf beschränken, nur die nichtinstanzierten Operationen zu verwenden. Bei einer solchen Abfrage würden irgendwelche geschnittenen Instanzknoten an den SM zurückgegeben.
In manchen nicht einschränkenden Ausführungsformen wird der Begrenzungsvolumen-Schnittpunkttest in Schritt 1010 an jedem Begrenzungsvolumen in dem abgerufenen Complet durchgeführt, bevor das nächste Complet abgerufen wird. Andere Ausführungsformen können andere Techniken verwenden, wie z. B. Traversieren der Top-Level-Traversierungs-BVH auf eine Weise nach Tiefe. Das bereits durch Bezugnahme aufgenommene US-Patent Nr. 9,582,607 beschreibt eine oder mehrere Complet-Strukturen und -Inhalte, die in Ausführungsbeispielen verwendet werden können. Das US-Patent Nr. 9,582,607 beschreibt ebenfalls eine Beispiel-Traversierung von Complets.
Wenn ein Begrenzungsvolumen als von dem Strahl geschnitten bestimmt wird, werden die Kind-Begrenzungsvolumina (oder Verweise darauf) des geschnittenen Begrenzungsvolumens für nachfolgendes Testen auf Schnittpunkt mit dem Strahl und für Traversierung im Auge behalten. In Ausführungsbeispielen werden eine oder mehrere Stapel-Datenstrukturen verwendet, um Kind-Begrenzungsvolumina im Auge zu behalten, die nachfolgend auf Schnittpunkt mit dem Strahl zu testen sind. In manchen Ausführungsbeispielen kann ein Traversierungsstapel von geringer Größe verwendet werden, um Complets, die durch Betrieb der Top-Level-Baumtraversierung 1006 zu traversieren sind, und auf Schnittpunkte zu testende Primitive im Auge zu behalten, und eine größere lokale Stapel-Datenstruktur kann verwendet werden, um den Traversierungsstatus in der Bottom-Level-Baumtraversierung 1018 im Auge zu behalten.
Beispiel Bottom-Level-Baumtraversierung
Bei der Bottom-Level-Baumtraversierung 1018 ruft ein Nächstes-Complet-Abruf-Schritt 1022 das nächste, in Schritt 1024 auf Strahlschnittpunkte zu testende Complet aus dem Speicher und/oder der Cache-Hierarchie 1020 ab, und das Strahlbegrenzungsvolumen-Schnittpunkttesten wird an den Begrenzungsvolumina in dem abgerufenen Complet durchgeführt. Die Bottom-Level-Baumtraversierung kann, wie oben erwähnt, Complets mit Begrenzungsvolumina in einem anderen Koordinatensystem enthalten als die bei der Baumtraversierung der oberen Ebene traversierten Begrenzungsvolumina. Die Bottom-Level-Baumtraversierung empfängt auch Complets aus dem L1-Cache und kann auf Basis von Nicht-Blatt/Kein-Treffer-Bedingungen und auch mit der Top-Level-Baumtraversierung 1006 auf Basis von Fehlschuss/Ende-Erkennung rekursiv oder iterativ in sich selbst arbeiten. Es können Schnittpunkte des Strahls mit den Begrenzungsvolumina in der BVH der unteren Ebene bestimmt werden, wobei der Strahl in das Koordinatensystem des ausgelesenen Complets der unteren Ebene transformiert wird. Die bei der Baumtraversierung der unteren Ebene als von dem Strahl geschnitten gefundenen Blatt-Begrenzungsvolumina werden dann dem Strahl/Dreieck-Schnittpunkt 1026 zugeführt.
Die Blatt-Ausgaben der Bottom-Level-Baumtraversierung 1018 werden dem Strahl/Dreieck-Schnittpunkt 1026 zugeführt (der sowohl Zugriff auf L0-Cache als auch die Fähigkeit hat, Dreiecke über den L1-Cache 1028 auszulesen). Die L0-Complet- und Dreieck-Caches können kleine Nur-Lese-Caches innerhalb der TTU 700 sein. Der Strahl/Dreieck-Schnittpunkt 1026 kann auch Blatt-Ausgaben aus der Top-Level-Baumtraversierung 1006 empfangen, wenn bestimmte Blattknoten erreicht werden, ohne eine instanzierte BVH zu traversieren.
Nachdem alle Primitive im Primitiv-Bereich verarbeitet worden sind, überprüft die Schnittpunktverwaltungseinheit den Status der Ergebniswarteschlange und fertigt Pakete an, die an die Stapelverwaltungseinheit und/oder Strahlverwaltungseinheit zu senden sind, um die Attribute und den Traversierungsstatus des Strahls zu aktualisieren, den nächsten Traversierungsschritt des Strahls einzurichten und/oder den Strahl (falls erforderlich) an den SM 132 zurückzugeben. Wenn die Ergebniswarteschlange Opak- oder Alpha-Schnittpunkte enthält, die während der Verarbeitung des Primitiv-Bereichs gefunden worden sind, dann signalisiert die Schnittpunktverwaltungseinheit der Strahlverwaltungseinheit die parametrische Länge (t) des nächstgelegenen Opak-Schnittpunkts in der Ergebniswarteschlange, um sie als das tmax des Strahls zum Verkürzen des Strahls aufzuzeichnen. Zum Aktualisieren des Traversierungsstatus, um den nächsten Traversierungsschritt des Strahls einzurichten, signalisiert die Schnittpunktverwaltungseinheit der Stapelverwaltungseinheit, ob ein Opak-Schnittpunkt aus dem Primitiv-Bereich in der Ergebniswarteschlange vorhanden ist, ob ein oder mehrere Alpha-Schnittpunkte in der Ergebniswarteschlange vorhanden sind, ob die Ergebniswarteschlange voll ist, ob zusätzliche Alpha-Schnittpunkte im Primitiv-Bereich gefunden worden sind, die nicht an den SM zurückgegeben worden sind und die nicht in der Ergebniswarteschlange vorhanden sind, und den Index des nächsten Alpha-Primitivs in dem Primitiv-Bereich für den zu testenden Strahl, nachdem der SM den Inhalt der Ergebniswarteschlange verbraucht hat (der Index des nächsten Primitivs in dem Bereich nach dem Alpha-Primitiv mit der höchsten Speicherreihenfolge aus dem aktuellen Primitiv-Bereich in der Ergebniswarteschlange).
Wenn die Stapelverwaltungseinheit 740 das Paket von der Schnittpunktverwaltungseinheit 722 empfängt, überprüft die Stapelverwaltungseinheit 740 das Paket, um die nächste Aktion zu bestimmen, die erforderlich ist, um den Traversierungsschritt abzuschließen und den nächsten zu starten. Wenn das Paket von der Schnittpunktverwaltungseinheit 722 anzeigt, dass ein Opak-Schnittpunkt im Primitiv-Bereich gefunden worden ist, und die Strahl-Modus-Bits anzeigen, dass der Strahl die Traversierung beenden soll, sobald irgendein Schnittpunkt gefunden worden ist, gibt die Stapelverwaltungseinheit 740 den Strahl und seine Ergebniswarteschlange mit einem Traversierungsstatus, der anzeigt, dass die Traversierung abgeschlossen ist (ein Fertig-Flag-gesetzt und/oder ein leerer Top-Level- und Bottom-Level-Stapel), an den SM zurück. Wenn das Paket von der Schnittpunktverwaltungseinheit 722 anzeigt, dass es Opak- oder Alpha-Schnittpunkte in der Ergebniswarteschlange gibt und dass es verbleibende, in der Ergebniswarteschlange nicht vorhandene Alpha-Schnittpunkte im Primitiv-Bereich gibt, die der Strahl während der Verarbeitung des Primitiv-Bereichs getroffen hat und die nicht bereits an den SM zurückgegeben worden sind, gibt die Stapelverwaltungseinheit 740 den Strahl und die Ergebniswarteschlange an den SM zurück, wobei der Traversierungsstatus modifiziert wird, das Cull-Opak-Bit so zu setzen, dass weitere Verarbeitung von opaken Primitiven im Primitiv-Bereich verhindert wird und der zu dem ersten Alpha-Primitiv nach dem höchsten Alpha-Primitiv-Schnittpunkt von dem Primitiv-Bereich vorgerückte Start-Index des Primitiv-Bereichs an den SM in der Ergebniswarteschlange des Strahls zurückgegeben wird. Wenn das Paket von der Schnittpunktverwaltungseinheit 722 anzeigt, dass keine Opak- oder Alpha-Schnittpunkte gefunden worden sind, als der Strahl den Primitiv-Bereich verarbeitet hat, entfernt die Stapelverwaltungseinheit 740 den oberen Teil des Stapeleintrags (entsprechend dem fertigen Primitiv-Bereich) von dem aktiven Traversierungsstapel. Wenn das Paket von der Stapelverwaltungseinheit 740 anzeigt oder dass entweder Opak-Schnittpunkte in der Ergebniswarteschlange vorhanden sind und die Strahl-Modus-Bits nicht anzeigen, dass der Strahl die Traversierung beenden soll, sobald irgendein Schnittpunkt gefunden worden ist, und/oder Alpha-Schnittpunkte in der Ergebniswarteschlange vorhanden sind, aber keine verbleibenden, nicht in der Ergebniswarteschlange vorhandenen Alpha-Schnittpunkte im Primitiv-Bereich gefunden worden sind, die nicht bereits an den SM zurückgegeben worden sind, entfernt die Stapelverwaltungseinheit 740 den oberen Teil des Stapeleintrags (entsprechend dem fertigen Primitiv-Bereich) vom aktiven Traversierungsstapel und modifiziert den Inhalt der Ergebniswarteschlange, um anzuzeigen, dass alle in der Ergebniswarteschlange vorhandenen Schnittpunkte aus einem Primitiv-Bereich stammen, dessen Verarbeitung abgeschlossen worden ist.
Wenn der aktive Stapel der untere Stapel ist und der untere Stapel leer ist, setzt die Stapelverwaltungseinheit 740 den aktiven Stapel auf den oberen Stapel. Wenn der obere Stapel der aktive Stapel ist und der aktive Stapel leer ist, gibt die Stapelverwaltungseinheit 740 den Strahl und seine Ergebniswarteschlange mit einem Traversierungsstatus, der anzeigt, dass die Traversierung abgeschlossen ist (ein Fertig-Flag-gesetzt und/oder ein leerer Top-Level- und Bottom-Level-Stapel), an den SM zurück. Wenn der aktive Stapel einen oder mehrere Stapeleinträge enthält, überprüft die Stapelverwaltungseinheit 740 den oberen Stapeleintrag und startet den nächsten Traversierungsschritt. Das Testen von Primitiven und/oder Primitiv-Bereichen auf Schnittpunkte mit einem Strahl und die Rückgabe der Ergebnisse an den SM 132 sind beschrieben in der gleichzeitig anhängigen US-Anmeldung Nr. mit dem Titel „Conservative Watertight Ray Triangle Intersection“ (Anwaltsakte 6610-36 (18-SC-0145)) und US-Anmeldung Nr. mit dem Titel „Method for Continued Bounding Volume Hierarchy Traversal on Intersection without Shader Intervention“ (Anwaltsakte 6610-32 (18-AU-0127)), 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-Strahl-Primitiv-Traversierung mit deterministischen Ergebnissen
Wie oben erörtert, enthält die TTU 700 dedizierte Hardware zum Bestimmen, ob ein Strahl Begrenzungsvolumina schneidet, und dedizierte Hardware zum Bestimmen, ob ein Strahl Primitive der Baumdatenstruktur schneidet. Die Primitive der Baumdatenstruktur können verschiedene geometrische Primitive (z. B. Punkte, Linien, Dreiecke, Vierecke, Maschennetze, usw.) umfassen, die in den Blattknoten der Baumdatenstruktur identifiziert werden. Mindestens einige der Primitive (z. B. Dreiecke) können eine Typ-Kennung zum Unterscheiden zwischen verschiedenen Typen von Primitiven enthalten. Wie mit Bezug auf 5A-5C erörtert, können verschiedene Typen von Dreiecken opake Dreiecke und Alpha-Dreiecke umfassen.
Die TTU 700 enthält Hardware, die konfiguriert ist, um Schnittpunkte für einen Typ von Primitiven vollständig zu bestimmen, während für andere Primitive die TTU 700 mögliche Schnittpunkte möglicherweise nur selbst bestimmen kann. Zum Beispiel kann die TTU möglicherweise vollständig bestimmen, dass ein Strahl ein opakes Dreieck schneidet. Für Alpha-Dreiecke ist die TTU möglicherweise nur im Stande, zu bestimmen, dass ein Schnittpunkt möglich ist, und benötigt noch den SM, um zu entscheiden (z. B. auf Basis von Textur-Informationen), ob der Strahl eine auf die Oberfläche des transparenten Dreiecks aufgebrachte Textur schneidet oder nicht und/oder ob die Textur den Strahl blockieren wird.
In einer Ausführungsform kann die TTU 700 konfiguriert sein, um alle als den Strahl schneidend bestimmten Primitive für weitere Verarbeitung an den SM 132 zurückzugeben. Jedes geschnittene Primitiv und möglicherweise geschnittene Primitive an den SM 132 zurückzugeben, ist jedoch im Hinblick auf Schnittstellen- und Thread-Synchronisation aufwendig. Darüber hinaus benötigt der SM 132 Ressourcen, um mindestens einige der zurückgegebenen Primitive zu verarbeiten, um zum Beispiel auf Basis von Texturabbildungsinformationen zu bestimmen, ob der Strahl eine auf das transparente Dreieck aufgebrachte Textur schneidet oder nicht und/oder ob der Strahl durch die Textur blockiert wird.
Die TTU 700 bietet eine Hardware-Lösung, um zu bestimmen, welche geschnittenen Primitive ohne funktionalen Einfluss auf die Visualisierung der resultierenden Szene aus den dem SM 132 zugeführten Ergebnissen ausgelassen werden können. Dies ermöglicht es der TTU 700, die Traversierung der BVH ohne Intervention eines im SM implementierten Shaders mit oder ohne andere zugehörige Hardware fortzusetzen. Zum Beispiel kann die TTU 700 konfiguriert sein, um diejenigen Primitive auszulassen, die sich relativ zu einem Strahlursprung hinter einem opaken Primitiv befinden, da, wie mit Bezug auf 5A-5C erörtert, ein Strahl in einer Szene durch ein opakes Primitiv blockiert wird und keine anderen Primitive erreichen wird, obwohl sie der Strahl räumlich schneidet.
Die TTU 700 kann konfiguriert sein, um geschnittene Primitive ohne funktionalen Einfluss auf die Visualisierung der resultierenden Szene auszulassen, während eine kleine Ergebniswarteschlange in der TTU 700 verwendet wird. Wenn die Anzahl der geschnittenen Primitive (z. B. der geschnittenen Alpha-Primitive) für eine Abfrage die Größe der Ergebniswarteschlange überschreitet, muss die TTU 700 möglicherweise mehrere Rückgaben an den SM 132 durchführen. Beim Liefern der Schnittpunktergebnisse an den SM 132 müssen die Ergebnisse möglicherweise auf eine deterministische Weise geliefert werden, damit der SM 132 konsistente Visualisierungsergebnisse liefern kann.
Die TTU 700 kann konfiguriert sein, um deterministische Schnittpunktergebnisse für den SM 132 zu erzeugen. Die TTU 700 kann konfiguriert sein, um deterministische Schnittpunktergebnisse zu liefern, selbst wenn der gerade auf Schnittpunkte getestete Primitiv-Bereich über mehrere Blöcke in Cache-Zeilen-Größe verteilt ist, die in einer zufälligen Reihenfolge an die TTU 700 geliefert werden. Dementsprechend kann die TTU 700 konfiguriert sein, um dem SM 132 deterministische Ergebnisse unabhängig von der Reihenfolge zu liefern, in der der Speicher 140 Blöcke mit Primitiv-Informationen zur Verarbeitung an die TTU 700 zurückgibt, während opportunistisch Primitive aus den Ergebnissen ausgelassen werden, die nachweislich ohne funktionalen Einfluss auf die Visualisierung der virtuellen Szene ausgelassen werden können.
Deterministische Ergebnisse können dem SM helfen, effizient stabile Bilder ohne störende Artefakte zu erzeugen. Zum Beispiel ist es wünschenswert, dass die TTU 700 Ergebnisse in einer dem SM bekannten Reihenfolge an den SM liefert. Wenn zum Beispiel der SM die gleiche Abfrage mehrmals an die TTU 700 sendet, sollte die TTU 700 jedes Mal die gleichen Ergebnisse in der gleichen Sequenz an den SM liefern, unabhängig von Faktoren wie z. B. der Reihenfolge, in der die TTU 700 Daten aus dem Speicher empfangen hat oder intern Arbeit geplant hat. Deterministische Ergebnisse ermöglichen es dem SM, auf Basis der empfangenen Ergebnisse auf eine effiziente Weise zusätzliche Verarbeitung durchzuführen und geeignete Anforderungen (z. B. zusätzliche Schnittpunkt-Abfragen) auszugeben. In einem Beispiel gibt der SM, wenn die TTU 700 keine deterministischen Ergebnisse liefert, möglicherweise eine nachfolgende Abfrage aus, die möglicherweise nicht ausgegeben zu werden braucht, oder gibt möglicherweise Abfragen aus, die nicht genau widerspiegeln, was als nächstes auf Schnittpunkte getestet werden muss. Ungenaues Identifizieren der Anzahl und/oder welche Primitive geschnitten werden kann zum Beispiel visuelle Artefakte in Bilder einführen, die das System von einer Szene erzeugt.
Indessen berechnet die TTU 700 ihre Ergebnisse häufig in Reihenfolgen, die nicht im Voraus vorhergesagt werden können, auf Basis von variablen Faktoren wie z. B. der Reihenfolge, in der das Speichersystem Traversierungs-Informationen abruft, die die TTU 700 anfordert, den Eigenschaften der Geometrie in dem Graphen, der Spezifikation der Abfrage des SM an die TTU 700, interne Ablaufplanung innerhalb der TTU 700, und so weiter.
11 ist ein Flussdiagramm eines nicht einschränkenden Beispiel-Verfahrens für beschleunigten Strahl-Primitiv-Schnittpunkttest. Das Verfahren kann mittels einer in dieser Anmeldung offenbarten TTU 700 durchgeführt werden, ist aber nicht darauf beschränkt.
Das Verfahren umfasst, eine Anforderung zu empfangen 1110. Die Anforderung kann eine Abfrage sein, die einen nächstgelegenen Schnittpunkt zwischen einer Abfragedatenstruktur und einem Primitiv-Bereich anfordert. Die Abfrage kann von einem SM empfangen werden oder kann das Ergebnis eines Strahl-Complet-Tests sein, der vom Strahl-Complet-Testpfad der TTU durchgeführt wird. In manchen Ausführungsformen kann die Abfragedatenstruktur ein Strahl sein, der durch seinen Drei-Koordinaten-Ursprung, seine Drei-Koordinaten-Richtung sowie Minimal- und Maximalwerte für den t-Parameter entlang des Strahls gegeben ist. Der Primitiv-Bereich für die Abfrage kann in einem oder mehreren Stapeleinträgen eines Stapelverwaltungsblocks in der TTU identifiziert werden. Die Stapeleinträge können auf Basis der Ergebnisse des Auffindens von geschnittenen Blattknoten einer BVH in dem Strahl-Complet-Testpfad der TTU vorgenommen werden.
Der Primitiv-Bereich wird aus dem Speicher 1112 ausgelesen. Der Primitiv-Bereich kann aus dem TTU-Speicher (z. B. Dreieck-Cache 754 des LO-Cache 750) oder Speicher außerhalb der TTU ausgelesen werden. Der Primitiv-Bereich kann zum Beispiel in einer zusammenhängenden Gruppe von Blöcken in Cache-Zeilen-Größe bereitgestellt werden. Jeder Block in Cache-Zeilen-Größe kann einen Kopf enthalten, der den Typ der innerhalb des Blocks Geometrie ausgedrückten Geometrie und einen Primitiv-Typ eines jeden Primitivs in dem Block identifiziert. Zum Beispiel kann der Kopf identifizieren, dass der Block Dreiecke enthält, und anzeigen, ob ein jedes Dreieck ein Alpha-Primitiv oder ein opakes Primitiv ist. Der Kopf kann ein Alpha-Bit für jedes Primitiv enthalten, um zu kennzeichnen, ob das jeweilige Primitiv ein Alpha-Primitiv oder ein opakes Primitiv ist.
12A veranschaulicht eine Mehrzahl von Blöcken 0-N, die einen Primitiv-Bereich identifizieren, gemäß einem Ausführungsbeispiel dieser Offenbarung. Jeder Block kann einen Kopf 1250 und geometrische Daten für Primitive 1260 enthalten. Jeder Block kann einer jeweiligen Speicheradresse (z. B. K, K+1, K+N) in physikalischem oder virtuellem Speicher zugeordnet sein. Die geometrischen Daten für Primitive können Vertices eines Primitivs enthalten (z. B. Dreieck mit drei Vertices, wobei jeder Vertex durch Koordinaten X0, Y0, Z0 identifiziert wird). In manchen Ausführungsformen können die geometrischen Daten komprimiert sein. Wie in 12A dargestellt, kann der Kopf den Typ der innerhalb des Blocks ausgedrückten Geometrie und das Codierschema (zum Beispiel komprimierte Dreiecke), die Anzahl der Primitive in dem Block (minus eins) und/oder einen Satz Erzwinge-kein-Culling-Bits, die für jedes Primitiv in dem Block anzeigen, ob Culling zu deaktivieren ist, und/oder einen Satz Alpha-Bits enthalten, die für jedes Primitiv in dem Block anzeigen, ob das Primitiv ein Alpha-Primitiv oder ein opakes Primitiv ist. Die in dem Kopf 1250 enthaltenen Informationen sind nicht auf die in 12A gezeigten Informationen beschränkt und können andere Informationen wie z. B. anwendungsspezifische Metadaten für die Primitive und/oder andere, mit einem oder mehreren bestimmten Primitiven in dem Block verknüpfte Primitiv-Metadatenwerte umfassen.
Jeder Block kann geometrische Daten für eine Mehrzahl von Primitiven speichern. In manchen Ausführungsformen können ein oder mehrere Blöcke ein oder mehrere opake Primitive und ein oder mehrere Alpha-Primitive enthalten. Jeder Block kann in seiner Größe einer Cache-Zeile des Speichers der TTU 700 entsprechen (z. B. LO-Cache 750). In manchen Ausführungsformen können Informationen für eine variierende Anzahl von Primitiven in irgend einem Block gespeichert werden. Die Anzahl der innerhalb eines gegebenen komprimierten Blocks gespeicherten Primitive kann eine Funktion der Datenähnlichkeit der Werte von geometrischen Daten für zugehörige Primitive sein. Die Blöcke können durch eine Block-Nummer identifiziert werden, wobei aufeinander folgende Blöcke entsprechende aufeinander folgende Block-Nummern aufweisen. Weiterhin können aufeinander folgende Blöcke Speicherplatz für aufeinander folgend identifizierte Primitive bereitstellen.
Beispiele für komprimierte und unkomprimierte Blöcke sowie Informationen, die in dem Kopf enthalten sein können, sind in der US-Patentanmeldung 2016/0071234 offenbart, die hiermit durch Bezugnahme aufgenommen wird.
Das Verfahren umfasst das Testen von Primitiven in dem Primitiv-Bereich auf Schnittpunkte mit dem Strahl 1114. Das Testen der Primitive kann umfassen, zu bestimmen, ob der Strahl eine durch das Primitiv (z. B. durch Vertices eines Dreiecks in Objekt-Raum-Koordinaten) identifizierte Fläche schneidet. Jedes Primitiv in dem Primitiv-Bereich kann auf einen Schnittpunkt mit dem Strahl getestet werden. Um den Strahl gegen die durch die Vertices identifizierte Fläche zu testen, kann der Strahl-Dreieck-Testpfad der TTU 700 den Strahl unter Verwendung von Instanztransformationen in die Objekt-Raum-Koordinaten des Primitiv-Bereichs transformieren.
Das Verfahren umfasst das Auslassen von geschnittenen Primitiven, die als keinen funktionalen Einfluss auf die Visualisierung einer resultierenden Szene 1116 habend bestimmt werden können. In einer Ausführungsform kann ein Schnittpunktverwaltungsblock 722 (siehe 9) bestimmen, welche räumlich geschnittenen Primitive aus den dem SM 132 zugeführten Ergebnissen ausgelassen werden können. Die TTU 700 kann bestimmen, dass ein oder mehrere räumlich geschnittene Primitive in dem Primitiv-Bereich durch ein anderes schneidendes opakes Dreieck, das näher am Strahlursprung liegt, entlang des Strahls verdeckt werden. Da ein näheres opakes Primitiv in einer Szene den Strahl daran hindert, durch das Primitiv hindurchzugehen, müssen die räumlich geschnittenen Primitive, die in Bezug auf den Strahlursprung durch das opake Dreieck verdeckt sind, nicht in das Ergebnis von geschnittenen Primitiven einbezogen werden und können aus den dem SM 132 zu meldenden Ergebnissen entfernt werden, wenn sie früher hinzugefügt worden sind.
Wenn mit Bezug auf 5A die TTU bestimmt, dass der Strahl ein vorderes Primitiv schneidet, welches opak ist, kann die TTU räumlich geschnittene Primitive hinter dem opaken Primitiv aus den Ergebnissen auslassen. In 5B ist das vordere räumlich geschnittene Primitiv ein Alpha-Primitiv, das den Strahl hindurchgehen und andere Primitive treffen lassen kann. Primitive hinter einem Alpha-Primitiv sind nicht aus den gemeldeten Ergebnissen auszulassen, da der Strahl je nach Ort und Typ der Textur durch das Alpha-Primitiv hindurchgehen und andere Primitive hinter dem Alpha-Primitiv treffen kann. In manchen Beispielen kann die TTU möglicherweise nicht selbst bestimmen (z. B. ohne Intervention des SM), ob ein Räumlicher-Schnittpunkt-Alpha-Dreieck einen Strahl blockiert oder dem Strahl zu anderen Primitiven hindurchgehen lässt.
Wenn daher die TTU bestimmt, dass der Strahl ein Alpha-Primitiv räumlich schneidet, fügt die TTU das geschnittene Alpha-Primitiv den Ergebnissen hinzu und setzt den Strahl-Primitiv-Schnittpunkttest fort, um irgendwelche anderen räumlich geschnittenen Primitive in dem Primitiv-Bereich zu bestimmen, die sich bezogen auf die Richtung des Strahl hinter oder vor dem Alpha-Primitiv befinden können. Mit Bezug auf 5C werden beide Alpha-Primitive zusammen mit dem opaken Primitiv dem Ergebnis hinzugefügt, da die ersten zwei räumlich geschnittenen Primitive Alpha-Primitive sind.
In einer Ausführungsform lässt die TTU Primitive hinter einem räumlich geschnittenen opaken Primitiv möglicherweise nur dann aus, wenn alle geschnittenen Primitive in dem Bereich opak sind. In einer anderen Ausführungsform ignoriert die TTU Primitive hinter einem räumlich geschnittenen opaken Primitiv möglicherweise, unabhängig davon, ob andere räumlich geschnittene Primitive opake oder Alpha-Primitive sind. In diesem Beispiel können die räumlich geschnittenen Primitive, die aus den Ergebnissen ausgeschlossen werden, opake und/oder Alpha-Primitive umfassen.
Die räumlich geschnittenen Primitive, die einen funktionalen Einfluss auf eine resultierende Szene haben könnten, können in einer Ergebniswarteschlange (z. B. in dem Schnittpunktverwaltungsblock 722) gespeichert werden. Die Ergebniswarteschlange liefert eine Datenstruktur innerhalb des TTU-Koprozessors 700 zum Speichern eines oder mehrerer Opakes- oder Alpha-Primitiv-Schnittpunkte, die während der Traversierung gefunden werden. In einer Ausführungsform ermöglicht es die Ergebniswarteschlange dem Koprozessor, Alpha-Tests durch den SM aufzuschieben und sie möglicherweise ganz zu vermeiden, wenn ein näherer Opak-Schnittpunkt einen Alpha-Schnittpunkt verdeckt.
12B veranschaulicht eine Ergebniswarteschlange 1200 gemäß einem Ausführungsbeispiel dieser Offenbarung. Die Ergebniswarteschlange 1200 kann einen Eintrag 1210 für einen Opakes-Primitiv-Schnittpunkt oder einen Alpha-Primitiv-Schnittpunkt enthalten. Die Ergebniswarteschlange 1200 kann optional einen oder mehrere zusätzliche Einträge 1220, 1230 für zusätzliche Alpha-Schnittpunkte enthalten.
In einem Ausführungsbeispiel spezifiziert jeder Ergebniswarteschlangen-Eintrag einen Treffertyp und eine parametrische Länge, die den Punkt entlang des Strahls spezifiziert, an dem der Treffer aufgetreten ist, und Attribute des Treffers wie z. B. die Instanz-ID, Material-ID oder Primitiv-ID, die von dem SM verwendet werden können, um einen bestimmten Material-Shader und einen Satz von Ressourcenbindungen auszuwählen, und Primitiv-IDs und Koordinaten (u,v), die von dem SM während Shading verwendet werden können, um Attribute oder Abtasttexturen auszulesen und zu interpolieren.
In anderen Ausführungsformen kann die Ergebniswarteschlange getrennte Warteschlangen für opake Primitive und Alpha-Primitive enthalten. Zum Beispiel kann die Ergebniswarteschlange einen einzigen Eintrag für einen Opakes-Primitiv-Schnittpunkt und einen oder mehrere Einträge für Alpha-Primitiv-Schnittpunkte enthalten.
Das Verfahren umfasst die Rückgabe der Ergebnisse von geschnittenen Primitiven an den SM 1118. Die Ergebnisse können an den SM zurückgegeben werden, wenn eine Abfrage abgeschlossen ist, oder mitten in der Traversierung, sollte SM-Intervention erforderlich werden (zum Beispiel wenn die Anzahl der innerhalb eines einzelnen Dreieck-Bereichs gefundenen Alpha-Treffer die Speicherkapazität der Ergebniswarteschlange für Alpha-Treffer überschreitet). Wenn alle Primitive in der Abfrage opak sind, kann die TTU nur das nächstgelegene opake Primitiv an den SM zurückgeben. Wenn die Primitive jedoch eine Mischung aus opaken und Alpha-Primitiven umfassen, kann eine Mehrzahl von Alpha-Primitiven von dem Strahl geschnitten werden. Jedes der geschnittenen Alpha-Primitive kann für weitere Verarbeitung an den SM zurückgegeben werden (z. B. um auf Basis von dem Alpha-Primitiv zugeordneten Textur-Informationen zu bestimmen, ob es einen Treffer gibt).
Die TTU 700 kann die geschnittenen Alpha-Primitive so an den SM zurückgeben, dass die Ergebnisse unabhängig von der Reihenfolge, in der die Primitive in dem Primitiv-Bereich von der TTU 700 verarbeitet werden, deterministisch sind. Zum Beispiel kann die TTU 700 die Primitive in dem Primitiv-Bereich in der Reihenfolge verarbeiten, in der die Blöcke in Cache-Zeilen-Größe von dem Speichersystem 140 zurückgegeben werden, aber die Ergebnisse in einer dem SM bekannten Reihenfolge an den SM zurückgeben.
Die Reihenfolge, in der die Blöcke in Cache-Zeilen-Größe an die TTU 700 geliefert werden, kann davon abhängen, wo in der Hierarchie des Speichersystems 140 sich die angeforderten Blöcke befinden. Dementsprechend kann die Latenz für jeden der Blöcke unterschiedlich sein. Zum Beispiel kann sich einer der angeforderten Blöcke im LO-Cache der TTU befinden, während sich andere Blöcke im LI-Cache oder L2-Cache der Speicherhierarchie befinden können. Darüber hinaus, wie in der gleichzeitig anhängigen gemeinsam übertragenen [US-Anmeldung Titel: Method for Efficient Grouping of cache Requests for Data path Scheduling: Ref: 18-AU-012; 6610-33], behandelt der LO-Cache 750 der TTU Anforderungen nicht notwendigerweise in der Reihenfolge des Eingangs, sondern gruppiert oder bündelt seine Antworten. Der LO-Cache 750 kann seine Antwort auf „Singletons“ („Einzelstücke“) verzögern, wenn er damit beschäftigt ist, eine Antwort auf eine Gruppe von Strahlen zu liefern. Aus zumindest diesen Gründen kann es sein, dass die Reihenfolge, in der die Strahlverarbeitung in der TTU angeforderte Teile der BVH zum Testen empfängt, unvorhersehbar ist. Dennoch kann die TTU 700 in nicht einschränkenden Ausführungsbeispielen die geschnittenen Primitive auf eine deterministische Weise an den SM liefern, indem sie bestimmte Typen von Primitiven (z. B. Alpha-Primitive) in der Reihenfolge der Speicheradressen (z. B. aufsteigend oder absteigend), in der die Primitive gespeichert sind, und nicht in der räumlichen Reihenfolge, in der sie sich in der Szene befinden, oder in der Reihenfolge, in der die Schnittpunkte durch die TTU 700 bestimmt werden, zurückgibt.
Die Speicherreihenfolge der Primitive ist durch die Adressenreihenfolge gegeben, in der die Primitive von der Beschleunigungsdatenstruktur (z. B. einer BVH) in einem physikalischen Speicher oder in einem virtuellen Speicher gespeichert werden. Wie oben erörtert, identifiziert ein Blattknoten einen Primitiv-Bereich, der in einer Mehrzahl von zusammenhängenden Blöcken in Cache-Zeilen-Größe gespeichert ist. Der Primitiv-Bereich kann innerhalb der Blatt-Daten der Beschleunigungsstruktur durch eine Adresse des ersten Blocks, der das erste Primitiv in dem Bereich enthält, einen Index des ersten Primitivs innerhalb dieses ersten Blocks, eine Gesamtzahl von Blöcken in dem Bereich und einen Index des letzten Primitivs in dem letzten Block ausgedrückt werden. In der Beschleunigungsdatenstruktur werden die dem Primitiv-Bereich zugeordneten Blöcke in einer bestimmten Reihenfolge gespeichert, und die Primitive innerhalb jedes Blocks werden in einer bestimmten Reihenfolge angeordnet. Die Reihenfolge der Speicheradressen der Primitive ist durch die Reihenfolge der Blöcke und die Reihenfolge der Primitive innerhalb jedes Blocks gegeben. In manchen Ausführungsformen ist die Reihenfolge der Primitive spezifisch für die spezielle Beschleunigungsdatenstruktur.
Der SM kann die Ergebnisse verwenden, um die Szene aufzubauen, zusätzliche Abfragen an die TTU auszugeben und/oder früher an die TTU ausgegebene Abfragen zu modifizieren. In einer Ausführungsform werden räumlich geschnittene Primitive mit dem gesetzten Alpha-Bit an den SM zurückgegeben, auch wenn die Traversierung noch nicht abgeschlossen ist. Die räumlich geschnittenen Primitive können an den SM mit Traversierungsstapel-Informationen zurückgegeben werden, die den Status enthalten, der zum Fortsetzen der Traversierung erforderlich ist, wenn Software bestimmt, dass das Dreieck tatsächlich transparent war. In einer Ausführungsform kann die TTU die Ergebnisse an den SM zurückgeben, nachdem alle Primitive in dem Primitiv-Bereich getestet worden sind. In dieser Ausführungsform muss die Größe der Ergebniswarteschlange ausreichend sein, um alle Ergebnisse zu speichern.
In manchen Ausführungsformen kann die Größe der Ergebniswarteschlange aufgrund physikalischer Einschränkungen auf einen einzigen Eintrag oder wenige Einträge beschränkt sein. Zum Beispiel kann die Ergebniswarteschlange einen einzigen Eintrag für den Opak-Schnittpunkt oder den Alpha-Schnittpunkt enthalten. In einem anderen Beispiel kann die Ergebniswarteschlange einen einzigen Eintrag für den Opak-Schnittpunkt und eine Mehrzahl von Einträgen (z. B. vier Einträge) für die Alpha-Schnittpunkte enthalten. Wenn ein Schnittpunkt identifiziert wird, der nicht verworfen werden kann, und die Ergebniswarteschlange voll ist, kann die TTU 700 die Ergebnisse in der Ergebniswarteschlange an den SM zurückgeben, mit Informationen, die den SM in die Lage versetzen, die Strahl-Test-Abfrage nach Verarbeitung eines oder mehrerer der in den Ergebnissen identifizierten Primitive wiedervorzulegen. Zum Beispiel kann der SM die Strahl-Test-Abfrage wiedervorlegen, die ein oder mehrere Primitive überspringt, die bereits an den SM zurückgegeben worden sind. Wenn daher mehrere Alpha-Primitive in einem Strahl geschnitten werden, kann jedes geschnittene Alpha-Primitiv eines nach dem anderen an den SM zurückgegeben werden.
Die TTU 700 kann konfiguriert sein, um die als von dem Strahl geschnitten bestimmten mehreren Alpha-Primitive in der Reihenfolge an den SM liefern, in der sie in Speicher gespeichert sind, um deterministische Ergebnisse zu liefern. In einem Beispiel, wenn ein Alpha-Primitiv-Schnittpunkt identifiziert wird, der nicht ausgelassen werden kann, und die Ergebniswarteschlange voll ist, kann die TTU 700 einen der Einträge in der Ergebniswarteschlange durch den neuen Alpha-Primitiv-Schnittpunkt ersetzen. Die TTU 700 kann einen der Einträge in der Ergebniswarteschlange ersetzen, wenn sich der neue Alpha-Primitiv-Schnittpunkt früher in der Speicherreihenfolge befindet als einer der in der Ergebniswarteschlange gespeicherten Alpha-Primitiv-Schnittpunkte.
Beispiel-Strahl-Dreieck-Traversierung ohne Shader-Intervention und mit deterministischen Ergebnissen
In einem konkreteren Beispiel arbeitet die TTU durch Verfolgen von Strahlen durch eine erzeugte BVH hindurch, die interne Knoten, Instanztransformationen, Element-Bereiche und Dreieck-Bereiche enthält. Intern-Knoten-Schnittpunkte traversieren weiter in die Hierarchie hinein. Instanzknoten-Schnittpunkt kann eine hardwarebeschleunigte Instanztransformation durchführen und dann die Traversierung auf der instanzierten Kind-BVH fortsetzen. Element-Bereiche werden an den SM zurückgegeben. Dreieck-Bereiche können konkrete Hardwarebeschleunigung innerhalb der TTU in dem Block Strahl-Dreieck-Test (RTT) verwenden, um einen Schnittpunkt zwischen einem Strahl und einem konkreten Dreieck zu bestimmen. Im Allgemeinen geht es bei einer Abfrage entweder um die nächstgelegene Interaktion mit dem Strahlursprung oder einfach darum, dass es einen Schnittpunkt gab.
Die TTU hat zwei Typen von Dreiecken, die sie schneidet: opak und Alpha. Der Typ des Dreiecks kann durch ein Flag (z. B. ein Alpha-Dreieck-Flag) gekennzeichnet werden. Die TTU kann konfiguriert sein, um einen Schnittpunkt für ein opakes Dreieck im Strahl-Dreieck-Testpfad der TTU vollständig zu bestimmen. Die TTU ist möglicherweise nicht im Stande, einen Schnittpunkt für Alpha-Dreiecke vollständig zu bestimmen. Für Alpha-Dreiecke bestimmt der Strahl-Dreieck-Testpfad der TTU, dass es einen Schnittpunkt geben könnte, und die Informationen über den möglichen Schnittpunkt werden an den SM gesendet, um das Vorhandensein oder die Abwesenheit eines tatsächlichen Schnittpunkts zu bestimmen. Ein Beispiel für die Verwendung eines Alpha-Dreiecks ist Laub, bei dem ein Blatt durch ein einzelnes Dreieck dargestellt werden kann, auf das eine Textur aufgebracht ist, um eine engere Grenze um die tatsächliche Blattform herum zu definieren. Dieses Konzept ist in 6A und 6B veranschaulicht, wobei eine Textur 615 eines Blattes auf einen Teil des Dreiecks 610 aufgebracht ist. Das Alpha-Dreieck-Flag kann auch auf im Übrigen opake Dreiecke angewendet werden, so dass die TTU jedes von dem Strahl geschnittene Dreieck zurückgibt.
Die TTU enthält die Schnittpunktverwaltungseinheit (IMU) und eine Ergebniswarteschlange, die es der TTU erlaubt, die verschiedenen Primitiv-Treffer-Typen zu behandeln und nicht alle geschnittenen Dreiecke an den SM zurückgeben zu müssen. Eine Reduzierung dieser Rückgaben ist wünschenswert, da eine Rückgabe zum SM eine Warp-weite Synchronisation erfordert. Die Schnittpunktergebnisse werden in der Ergebniswarteschlange gespeichert und werden nach Abschluss einer Abfrage an den SM zurückgegeben, oder mitten in der Traversierung, sollte SM-Intervention erforderlich werden (zum Beispiel wenn die Anzahl der innerhalb eines einzelnen Dreieck-Bereichs gefundenen Alpha-Treffer die Speicherkapazität der Ergebniswarteschlange für Alpha-Treffer überschreitet).
13 ist ein Flussdiagramm eines nicht einschränkenden Beispiel-Verfahrens für beschleunigten Strahl-Dreieck-Schnittpunkttest. Das Verfahren kann mit einer in dieser Anmeldung offenbarten TTU 700 durchgeführt werden, ist aber nicht darauf beschränkt.
Die TTU kann konfiguriert sein, um Primitive von einem bestimmten Geometrietyp im Strahl-Primitiv-Testpfad der TTU zu verarbeiten. In manchen Implementierungen werden andere Primitiv-Typen möglicherweise nicht im Strahl-Primitiv-Pfad der TTU unterstützt. Primitiv-Typen, die im Strahl-Primitiv-Pfad der TTU nicht unterstützt werden, können zur Verarbeitung an den SM zurückgegeben werden (z. B. nachdem sie im Strahl-Complet-Testpfad der TTU identifiziert worden sind oder wenn sie im Strahl-Schnittpunkt-Testpfad der TTU angetroffen werden). Das Flussdiagramm in 13 wird mit Bezug auf eine TTU erläutert, die konfiguriert ist, um Dreiecke im Strahl-Primitiv-Testpfad zu behandeln, aber nicht darauf beschränkt ist. Der Strahl-Primitiv-Testpfad der TTU kann konfiguriert sein, um Schnittpunkte für andere Primitive zu bestimmen, und kann konfiguriert sein, um Schnittpunkte für eine Vielzahl von unterschiedlichen Primitiven zu bestimmen. In manchen Ausführungsformen kann die TTU eine Vielzahl von Strahl-Primitiv-Testpfaden enthalten, die jeweils konfiguriert sind, um ein anderes Primitiv zu behandeln.
Das in 13 gezeigte Flussdiagramm umfasst, dass die TTU 700 eine Abfrage empfängt, die einen nächstgelegenen Schnittpunkt zwischen einem Strahl und einem Primitiv-Bereich anfordert (Schritt 1310). Die Abfrage kann von einem SM 132 empfangen werden oder kann auf Basis des Ergebnisses des vom Strahl-Complet-Testpfad der TTU durchgeführten Strahl-Complet-Tests eingeleitet werden.
Der Strahl kann durch seinen Drei-Koordinaten-Ursprung, seine Drei-Koordinaten-Richtung sowie Minimal- und Maximalwerte für den t-Parameter entlang des Strahls identifiziert werden. Der Primitiv-Bereich für die Abfrage kann in einem oder mehreren Stapeleinträgen eines Stapelverwaltungsblocks 740 in der TTU identifiziert werden. In einer Ausführungsform kann der Strahl-Complet-Testpfad einen oder mehrere geschnittene Blattknoten eines Baums identifizieren, die auf einen Bereich von Primitiven oder Elementen hinweisen. Der Primitiv-Bereich kann ein Satz von aufeinander folgenden Primitiven sein, die am n-ten Primitiv in einem Speicherblock beginnen und für null oder mehr Blöcke bis zum m-ten Primitiv des letzten Blocks laufen. Ein Block kann eine Cache-Zeile sein (z. B. 128B). Die Primitive können in den Cache-Zeilen komprimiert werden, mit einer variierenden Anzahl von Primitiven in jeder Cache-Zeile. Ein Bereich von Primitiven könnte sich über eine variierende Anzahl von Cache-Zeilen erstrecken.
Der Primitiv-Bereich wird aus Speicher ausgelesen (Schritt 1312). Der Primitiv-Bereich kann aus dem TTU-Speicher (z. B. Dreieck-Cache 754 des LO-Cache 750) oder Speicher 140 außerhalb der TTU ausgelesen werden. Der Primitiv-Bereich kann in einer zusammenhängenden Gruppe von Blöcken in Cache-Zeilen-Größe bereitgestellt werden. Jeder Block in Cache-Zeilen-Größe kann einen Kopf enthalten, der den innerhalb des Blocks ausgedrückten Geometrietyp und einen Primitiv-Typ jedes Primitivs in dem Block identifiziert..
Das Verfahren umfasst, ein Primitiv in dem Primitiv-Bereich auf einen Schnittpunkt mit dem Strahl zu testen (Schritt 1314). Da der Block mit dem Primitiv-Bereich mehrere opake oder Alpha-Primitive in irgendeiner Reihenfolge codieren kann und der Primitiv-Bereich sich über mehrere vom Speicher-Subsystem der TTU in beliebiger Reihenfolge zurückgegebene Blöcke erstrecken kann, ist das erste getestete Primitiv möglicherweise nicht das dem Strahlursprung am nächsten liegende Primitiv. Aus ähnlichen Gründen ist das erste getestete Primitiv möglicherweise nicht das erste Primitiv in der Speicherreihenfolge des Bereichs von Primitiven.
Der Strahl-Dreieck-Test- und Transformationsblock 720 kann das Primitiv auf einen Schnittpunkt mit dem Strahl testen. Wenn der Strahl-Dreieck-Test- und Transformationsblock 720 einen Schnittpunkt bestimmt, kann der Strahl-Dreieck-Test- und Transformationsblock 720 Informationen über den Schnittpunkt an die IMU 722 übergeben. Das Testen des Primitivs auf einen Schnittpunkt kann umfassen, zu bestimmen, ob der Strahl eine durch Vertices des Dreiecks identifizierte Fläche schneidet. Der Strahl-Dreieck-Test- und Transformationsblock 720 kann den Strahl vor Durchführung des Schnittpunkttests in Objekt-Raum-Koordinaten des Primitivs transformieren.
Wenn es keinen Schnittpunkt zwischen dem Primitiv und dem Strahl gibt (Nein in Schritt 1316), kann das Primitiv aus den Ergebnissen ausgelassen werden, und es wird bestimmt, ob es ein anderes zu testendes Primitiv in dem Bereich gibt (Schritt 1318). Wenn es ein anderes zu testendes Primitiv in dem Primitiv-Bereich gibt (Ja in Schritt 1318), entweder in dem gleichen Block oder in einem anderen, dem Primitiv-Bereich zugeordneten Block, kann der Dreieck-Strahl-Test an dem nächsten Primitiv durchgeführt werden (Schritt 1314). Wenn es keine anderen zu testenden Primitive in dem Primitiv-Bereich gibt (Nein in Schritt 1318), ist der Strahl-Dreieck-Test abgeschlossen, und die Ergebnisse des Strahl-Dreieck-Tests können an den SM oder einen anderen Block | innerhalb oder außerhalb der TTU 700 gesendet werden, die die Abfrage einleitet (Schritt 1320). Die Rückgabe der Ergebnisse (Schritt 1320) kann den parametrischen Opak-Schnittpunkt in dem Primitiv-Bereich liefern, der dem Strahlursprung am nächsten liegt, und/oder ein oder mehrere in der Warteschlange gespeicherte Alpha-Schnittpunkte. Für jedes als geschnitten bestimmte Primitiv können die Ergebnisse die Dreieck-ID zusammen mit dem t-Wert und den Koordinaten des Schnittpunkts (z. B. baryzentrischen Koordinaten des Schnittpunkts) liefern. Wenn keine Schnittpunkte in dem Primitiv-Bereich identifiziert werden, zeigt das Ergebnis dem SM an, dass keine Schnittpunkte gefunden worden sind.
Wenn es einen Schnittpunkt zwischen dem Primitiv und dem Strahl gibt (Ja in Schritt 1316), dann wird bestimmt (Schritt 1322), ob das Primitiv ein opakes Primitiv ist. Diese Bestimmung kann von der IMU 722 auf Basis des dem Primitiv zugeordneten Alpha-Bit durchgeführt werden. Wenn der Schnittpunkt mit einem opaken Primitiv besteht (Ja in Schritt 1322), dann kann die IMU 722 bestimmen, ob der Opakes-Primitiv-Schnittpunkt näher am Strahlursprung liegt als ein in der Ergebniswarteschlange gespeicherter Opak-Schnittpunkt (Schritt 1324). Wenn der eingehende Opakes-Primitiv-Schnittpunkt näher am Strahlursprung liegt als ein früher gespeicherter Opakes-Primitiv-Schnittpunkt in der Ergebniswarteschlange (Ja in Schritt 1324), dann ersetzt der Opakes-Primitiv-Schnittpunkt den früher gespeicherten Opakes-Primitiv-Schnittpunkt in der Ergebniswarteschlange (Schritt 1326). Ähnlich, wenn es keinen in der Ergebniswarteschlange gespeicherten Opakes-Primitiv-Schnittpunkt gibt und es keine Alpha-Schnittpunkte in der Ergebniswarteschlange gibt, dann ist der eingehende Opak-Schnittpunkt der dem Strahlursprung am nächsten gelegene Schnittpunkt und wird in der Warteschlange gespeichert (Schritt 1326).
Das Bestimmen, ob der eingehende Opak-Schnittpunkt näher am Strahlursprung liegt als der in der Ergebniswarteschlange gespeicherte Opak-Schnittpunkt, kann umfassen, dass die IMU 722 die t-Werte des Schnittpunkts vergleicht, die eine parametrische Länge entlang des Strahls darstellen (Punkt entlang des Strahls, an dem der Schnittpunkt auftrat). Der Schnittpunkt mit dem kleineren t-Wert kann in der Ergebniswarteschlange gespeichert werden, da er näher am Strahlursprung liegt und andere Primitive entlang des Strahls vor dem Betrachter verbirgt. Primitive mit einer größeren parametrischen Länge werden ausgesondert.
Beim Bestimmen, welcher Schnittpunkt näher liegt (Schritt 1324), könnten zwei Primitive den gleichen parametrischen Schnittpunktwert haben. Es kann „T-Streit“ in zwei Dreieck-Blöcken des gleichen Dreieck-Bereichs vorkommen. In einer Ausführungsform würde das nach Speicherreihenfolge führende Dreieck gewinnen und in der Ergebniswarteschlange gespeichert werden. Andere Ausführungsformen könnten andere Mechanismen verwenden, um zu bestimmen, welches Dreieck gewinnt.
In manchen Ausführungsbeispielen kann, wenn ein neuer Schnittpunkt für ein opakes Primitiv in der Ergebniswarteschlange gespeichert wird (Schritt 1326), die Länge des Strahls auf die parametrische Länge des Schnittpunkts des opaken Primitivs verkürzt werden. Auf diese Weise wird die TTU, wenn der Strahl-Schnittpunkttest für andere Primitive wiederholt wird, keinen eingehenden Opak- oder Alpha-Schnittpunkt in der Ergebniswarteschlange aufzeichnen, wenn sein t-Wert über dem t-Wert des in der Ergebniswarteschlange gespeicherten Opak-Schnittpunkts liegt. Um deterministische Ergebnisse zu liefern (z. B. wenn zwei Primitive den gleichen t-Wert haben könnten), darf der Strahl erst verkürzt werden, nachdem ein ganzer Primitiv-Bereich verarbeitet worden ist. In dieser Ausführungsform reicht der Nächstgelegener-Schnittpunkt-Test (in Schritt 1324) möglicherweise aus, um weitere Primitive auszusondern, ohne den Strahl verkürzen zu müssen, bis alle Primitive in dem Primitiv-Bereich auf Schnittpunkte getestet worden sind.
Wenn ein neuer Opakes-Primitiv-Schnittpunkt in der Ergebniswarteschlange gespeichert wird (Schritt 1326), kann irgendein in der Ergebniswarteschlange gespeicherter Alpha-Schnittpunkt, der parametrisch weiter vom Ursprung des Strahls weg liegt, in der Ergebniswarteschlange annulliert werden (Schritt 1328). Welche Alpha-Schnittpunkte zu annullieren sind, kann auf Basis der t-Werte der geschnittenen Primitive bestimmt werden. Zum Beispiel können Alpha-Schnittpunkte in der Ergebniswarteschlange, die einen größeren t-Wert als der t-Wert des neu gespeicherten Opak-Schnittpunkts aufweisen, aus der Ergebniswarteschlange entfernt werden. Wenn es nach Aktualisierung der Ergebniswarteschlange auf Basis des t-Wertes des Opak-Schnittpunkts noch irgendwelche verbleibenden Alpha-Schnittpunkte gibt, müssen diese parametrisch näher liegen als der in der Ergebniswarteschlange gespeicherte Opak-Schnittpunkt.
Wenn das geschnittene opake Primitiv nicht näher am Strahlursprung liegt als ein früher gespeicherter Opak-Schnittpunkt in der Ergebniswarteschlange (Nein in Schritt 1324), dann wird das geschnittene opake Primitiv aus der Ergebniswarteschlange ausgelassen, und es wird bestimmt, ob es irgendwelche zusätzlichen Primitive in dem Bereich gibt (Schritt 1318). Wenn es ein anderes zu testendes Primitiv in dem Primitiv-Bereich gibt (Ja in Schritt 1318), entweder in dem gleichen Block oder in einem anderen, dem Primitiv-Bereich zugeordneten Block, kann der Dreieck-Strahl-Test an dem nächsten Primitiv durchgeführt werden (Schritt 1314). Wenn es keine anderen zu testenden Primitive in dem Primitiv-Bereich gibt (Nein in Schritt 1318), ist die Verarbeitung des Primitiv-Bereichs abgeschlossen, und die Ergebnisse des Strahl-Dreieck-Tests können an den SM oder einen anderen Block innerhalb oder außerhalb der TTU, die die Abfrage ausgibt, gesendet werden (Schritt 1320).
Dementsprechend speichert die IMU-Einheit nach einem Schnittpunkt eines opaken Primitivs, statt diesen Primitiv-Schnittpunkt zurückzugeben, um von dem SM aufgezeichnet zu werden, stattdessen die Primitiv-Informationen und die Distanz, in der das Primitiv getroffen wurde. Der Strahl kann in der TTU intern so verkürzt werden, dass irgendwelche Elemente oder Primitive über dieses opake Primitiv hinaus ausgesondert werden. Irgendwelche früher geschnittenen Alpha-Primitive, die parametrisch hinter dem opaken Primitiv liegen, werden annulliert. In anderen Beispielen kann die Länge des Strahls von der TTU beibehalten werden, bis der Bereich getestet worden ist, und bei nachfolgenden Abfragen durch den SM verkürzt werden.
Wenn der Schnittpunkt mit einem Alpha-Primitiv besteht (Nein in Schritt 1322), bestimmt die IMU, ob die Ergebniswarteschlange voll ist (Schritt 1330). Wenn die Ergebniswarteschlange nicht voll ist (Nein in Schritt 1330), kann der Alpha-Schnittpunkt zu der Ergebniswarteschlange hinzugefügt werden (Schritt 1332). Wenn bereits andere Alpha-Schnittpunkte aus dem gleichen Primitiv-Bereich in der Ergebniswarteschlange gespeichert sind, kann der neue Alpha-Schnittpunkt auf Basis der Speicherreihenfolge, in der die Primitive in der BVH bereitgestellt werden, in der Ergebniswarteschlange gespeichert werden. Wenn die Ergebniswarteschlange voll ist, kann der eingehende Alpha-Schnittpunkt einen Alpha-Schnittpunkt aus dem gleichen Primitiv-Bereich ersetzen, wenn der eingehende Alpha-Schnittpunkt in Speicherreihenfolge früher ist als der Alpha-Schnittpunkt.
Nachdem der Alpha-Schnittpunkt zu der Ergebniswarteschlange hinzugefügt worden ist, wird bestimmt, ob es irgendwelche zusätzliche Primitive in dem Bereich gibt (Schritt 1334). Wenn es ein anderes zu testendes Primitiv in dem Primitiv-Bereich gibt (Ja in Schritt 1334), entweder in dem gleichen Block oder in einem anderen, dem Primitiv-Bereich zugeordneten Block, kann der Dreieck-Strahl-Test an dem nächsten Dreieck durchgeführt werden (Schritt 1314). Wenn es keine anderen zu testenden Primitive in dem Primitiv-Bereich gibt (Nein in Schritt 1334), können die Ergebnisse des Strahl-Dreieck-Tests an den SM oder einen anderen Block innerhalb oder außerhalb der TTU gesendet werden (Schritt 1336). Dementsprechend werden in einem Ausführungsbeispiel die Schnittpunkt-Informationen in der Ergebniswarteschlange nicht an den SM zurückgegeben, bis sämtliche dem Primitiv-Bereich zugeordneten Blöcke verarbeitet worden sind.
Wenn die Ergebniswarteschlange voll ist (Ja in Schritt 1330), dann bestimmt die IMU, ob die Speicheradressen-Reihenfolge des neuen Alpha-Primitiv-Schnittpunkts früher ist als eine Speicheradressen-Reihenfolge irgendeines Alpha-Schnittpunkts aus dem gleichen Primitiv-Bereich, der bereits in der Ergebniswarteschlange gespeichert ist (Schritt 1338). Wenn die Speicheradresse des eingehenden Alpha-Schnittpunkts früher ist als die Speicheradressen-Reihenfolge irgendeines Alpha-Schnittpunkts aus dem gleichen Primitiv-Bereich, der in der Ergebniswarteschlange gespeichert ist (Ja in Schritt 1338), dann ersetzt die IMU einen der in der Ergebniswarteschlange gespeicherten Alpha-Schnittpunkte durch den neuen Alpha-Schnittpunkt (Schritt 1340). Beim Speichern des neuen Alpha-Schnittpunkts kann der Schnittpunkt des Alpha-Primitivs mit der höheren Speicheradresse ersetzt werden. Dementsprechend fügt die IMU ein von früher in der Speicheradressen-Reihenfolge des Primitiv-Bereichs eingehendes geschnittenes Alpha-Primitiv vor einem geschnittenen Alpha-Primitiv aus dem gleichen Primitiv-Bereich ein, das in der Speicheradressen-Reihenfolge später erscheint, unabhängig davon, ob der eingehende Alpha-Schnittpunkt parametrisch näher oder weiter weg liegt als der Alpha-Schnittpunkt, der in der Speicheradressen-Reihenfolge früher gespeichert worden ist.
Nach dem Speichern des geschnittenen Alpha-Primitivs in der Ergebniswarteschlange (Schritt 1340) wird ein Flag Verbleibende-Alphas gesetzt, um anzuzeigen, dass es zusätzliche Alpha-Schnittpunkte in dem Primitiv-Bereich gibt, die nicht in der Ergebniswarteschlange gespeichert sind (Schritt 1350). Wenn das Flag Verbleibende-Alphas gesetzt ist, wurden in dem Primitiv-Bereich später in Speicherreihenfolge neben den in der Ergebniswarteschlange vorhandenen Alpha-Treffern weitere Alpha-Treffer in dem Primitiv-Bereich gefunden. Die verbleibenden Alpha-Treffer müssen möglicherweise verarbeitet werden, nachdem der SM die Menge der Alpha-Treffer in der Ergebniswarteschlange verbraucht hat.
Nach dem Speichern des Alpha-Schnittpunkts in der Ergebniswarteschlange (Schritt 1340) und dem Setzen des Flag Verbleibende-Alphas (Schritt 1350) wird bestimmt, ob es irgendwelche zusätzlichen Primitive in dem Bereich gibt (Schritt 1334). Wenn es ein anderes zu testendes Primitiv in dem Primitiv-Bereich gibt (Ja in Schritt 1334), entweder in dem gleichen Block oder in einem anderen, dem Primitiv-Bereich zugeordneten Block, kann der Dreieck-Strahl-Test an dem nächsten Primitiv durchgeführt werden (Schritt 1314). Wenn es keine anderen zu testenden Primitive in dem Primitiv-Bereich gibt (Nein in Schritt 1334), ist die Verarbeitung des Primitiv-Bereichs abgeschlossen, und die Ergebnisse des Strahl-Dreieck-Tests können an den SM gesendet werden (Schritt 1336), oder die Traversierung kann fortgesetzt werden. In einer Ausführungsform wird, nachdem die Primitive in einem Block der Gruppe von Blöcken alle auf Schnittpunkt getestet worden sind, der Anhängige-Cache-Zeile-Zähler dekrementiert. Wenn die anhängige Cache-Zeile Null erreicht, sind alle Blöcke der Gruppe von Blöcken verarbeitet worden.
Wenn die Speicheradresse des eingehenden Alpha-Schnittpunkts nicht früher ist als die Speicheradressen-Reihenfolge irgendeines Alpha-Schnittpunkts aus dem gleichen Primitiv-Bereich, der in der Ergebniswarteschlange gespeichert ist (Nein in Schritt 1338), dann werden die in der Ergebniswarteschlange gespeicherten Alpha-Schnittpunkte beibehalten, und es wird ein Flag Verbleibende-Alphas gesetzt, um anzuzeigen, dass es ein oder mehrere zusätzliche Alpha-Schnittpunkte in dem Primitiv-Bereich gibt, die nicht in der Ergebniswarteschlange gespeichert sind (Schritt 1350). Wenn das Flag Verbleibende-Alphas gesetzt ist, dann wurden in dem Primitiv-Bereich später in Speicherreihenfolge neben den in der Ergebniswarteschlange vorhandenen Alpha-Treffern weitere Alpha-Treffer gefunden.
Die in 13 dargestellten Operationen können wiederholt werden, bis alle Dreiecke in dem Primitiv-Bereich auf Schnittpunkt mit dem Strahl getestet worden sind. Nachdem alle Dreiecke in dem Primitiv-Bereich getestet worden sind, können die Ergebnisse für weitere Verarbeitung dem SM oder einen anderen Block zugeführt werden (Schritt 1336). Wie in 13 dargestellt, kann die TTU, wenn nicht alle geschnittenen Alpha-Dreiecke in die Ergebniswarteschlange passen, Informationen für geschnittene Alpha-Dreiecke zurückgeben, beginnend mit den geschnittenen Alpha-Dreiecken, die in der Speicheradressen-Reihenfolge früher gefunden worden sind, unabhängig davon, ob die anderen Alpha-Schnittpunkte parametrisch näher zum Strahlursprung oder weiter davon weg liegen. Die TTU führt dem SM aktuelle Schnittpunkt-Informationen in Speicheradressen-Reihenfolge zusammen mit den Strahl- und Stapelinformationen zu, so dass der SM nach Empfang der Ergebnisse eine andere Abfrage durchführen kann.
Die TTU kann den Traversierungsstatus im Stapel auf Basis des Fortschritts der in 13 dargestellten Operationen modifizieren. Der oberste Stapeleintrag (der auf den aktuellen Primitiv-Bereich verweist) kann das cullOpaque („aussondereOpak“) auf TRUE („WAHR“) setzen und erhöht den Start-Primitiv-Index auf 1 + den größten Alpha-Primitiv-Index aus dem aktuellen Primitiv-Bereich, der in der Ergebniswarteschlange gespeichert ist, wenn alle Dreiecke in dem Bereich getestet worden sind (Nein in Schritt 1318 oder Nein in Schritt 1334). Der modifizierte oberste Stapeleintrag und der Strahl können an den SM mit der Ergebniswarteschlange gesendet werden (Schritte 1336 oder 1320), um den Stapeleintrag mit einer nachfolgenden Abfrage durch den SM der TTU zuzuführen.
Die Rückgabe der Ergebnisse des Strahl-Dreieck-Tests an den SM 132 (Schritt 1336) kann umfassen, dem SM 132 anzuzeigen, dass es zusätzliche Alpha-Schnittpunkte in dem Primitiv-Bereich gibt, die aufgrund der begrenzten Größe der Warteschlange nicht in die Ergebniswarteschlange aufgenommen worden sind. Die IMU kann konfiguriert sein, um ein Verbleibendes-Alpha-Bit zu setzen, wenn ein Ergebnis eines Alpha-Schnittpunkts aus der Ergebniswarteschlange entfernt wird, da ein Alpha-Schnittpunkt, der in Speicherreihenfolge früher ist, identifiziert wird, oder wenn ein Alpha-Schnittpunkt identifiziert wird, aber nicht zu der Ergebniswarteschlange hinzugefügt wird, da er in Speicherreihenfolge später liegt als bereits in der Ergebniswarteschlange gespeicherte Alpha-Schnittpunkte (Schritt 1350). Das Verbleibendes-Alpha-Bit wird an den SM 132 gesendet, so dass der SM 132 eine weitere Strahl-Dreieck-Schnittpunkt-Abfrage ausgeben kann. Die Ergebniswarteschlange kann mit Traversierungsstapel-Informationen, die den Status enthalten, der zum Fortsetzen der Traversierung zum Bestimmen irgendwelcher verbleibenden Alpha-Schnittpunkte in dem Primitiv-Bereich erforderlich ist, an den SM 132 gesendet werden.
Das SM 132 kann die nachfolgende Abfrage auf Basis einer in Bezug auf die zurückgegebenen Ergebnisse durchgeführten Verarbeitung oder ohne irgendeine Verarbeitung durchzuführen ausgeben. Die von dem SM 132 ausgegebene nachfolgende Abfrage umfasst die von der TTU empfangenen Stapelinformationen, die sicherstellen, dass der Primitiv-Bereich in der nachfolgenden Abfrage nicht die geschnittenen Alpha-Primitive enthält, die bereits an den SM 132 zurückgegeben worden sind. Die nachfolgende Abfrage kann die Länge des Strahls auf die parametrische Länge des Opak-Schnittpunkts oder eines der Alpha-Schnittpunkte aktualisieren, wenn der SM bestimmt, dass eines oder mehrere der geschnittenen Alpha-Primitive den Strahl in einer parametrischen Distanz blockieren, die dem Strahlursprung näher ist als ein Opakes-Primitiv-Schnittpunkt. Wenn der SM 132 bestimmt, dass die geschnittenen Alpha-Dreiecke den Strahl nicht blockiert haben, kann der SM 132 die gleichen Strahlparameter in der nachfolgenden Abfrage beibehalten, aber den Bereich der zu testenden Dreiecke modifizieren.
In einer Ausführungsform mit einem Bereich von Dreiecken, die sowohl Alpha- als auch Opak-Schnittpunkte enthalten, können die an den SM 132 zurückgegebenen Ergebnisse des Strahl-Dreieck-Tests (Schritt 1336) einen Opak-Schnittpunkt und einen oder mehrere Alpha-Schnittpunkte enthalten. Der an den SM 132 zurückgegebene Opak-Schnittpunkt wird parametrisch näher am Strahlursprung liegen als irgendein anderer Opak-Schnittpunkt in dem Primitiv-Bereich. Die an den SM 132 zurückgegebenen Alpha-Schnittpunkte) werden parametrisch näher liegen als irgendein Opak-Schnittpunkt in der Ergebniswarteschlange, werden aber in der Ergebniswarteschlange in der Speicherreihenfolge gespeichert, in der sie in der Baumdatenstruktur bereitgestellt werden.
In einer Ausführungsform mit der Ergebniswarteschlange, die einen einzelnen Eintrag für einen Opak-Schnittpunkt oder einen Alpha-Schnittpunkt enthält, kann, wenn ein Schnittpunkt mit einem Alpha-Primitiv bestimmt wird (Nein in Schritt 1322) und ein Opak-Schnittpunkt in dem einzelnen Eintrag der Ergebniswarteschlange gespeichert ist, die Ergebniswarteschlange zusammen mit Informationen darüber, wie die Traversierung fortzusetzen ist, an den SM 132 zurückgegeben werden, bevor der Alpha-Schnittpunkt in der Ergebniswarteschlange gespeichert wird. Nach Rückgabe des Opak-Schnittpunkts an den SM 132 kann die TTU 700 eine andere Abfrage von dem SM 132 empfangen. Die andere Abfrage kann eine modifizierte Abfrage umfassen, die keine opaken Dreiecke in diesem Bereich berücksichtigen wird, da das opake Nächstgelegener-Treffer-Primitiv an den SM geliefert worden ist. Die andere Abfrage kann auch die Länge des Strahls auf die parametrische Länge des Schnittpunkts aktualisieren, so dass irgendwelche Primitive, die sich räumlich hinter dem opaken Primitiv befinden, nicht von dem Strahl geschnitten werden.
In diesem Beispiel gibt die TTU 700 den gespeicherten Schnittpunkt an den aufrufenden Thread mit einer Aufforderung zurück, erneut nach der Strahl-Dreieck-Abfrage zu fragen, da es mehr Dreiecke gibt, die getestet werden müssen. Der SM 132 kann die Informationen darüber, wie die Traversierung fortzusetzen ist, verwenden, um eine Abfrage an die TTU 700 auszugeben, um den Strahl-Schnittpunkttest für den Primitiv-Bereich beginnend an dem Primitiv fortzusetzen, das dem zurückgegebenen Opakes-Primitiv-Schnittpunkt im Speicher folgt. Auf diese Weise identifiziert die TTU 700 den Alpha-Primitiv-Schnittpunkt noch einmal, doch diesmal gibt es keinen Opak-Schnittpunkt, der in der Ergebniswarteschlange gespeichert ist, und der Alpha-Schnittpunkt kann für weitere Verarbeitung (z. B. um zu bestimmen, ob es einen tatsächlichen Treffer gibt) an den SM 132 zurückgegeben werden.
Manche Implementierungen können große Puffer in der IMU verwenden, um ein einzelnes opakes Dreieck und/oder mehrere Alpha-Dreiecke anzusammeln, bevor sie an den SM zurückgegeben werden. Angesichts der Natur von opaken Dreiecken ist es nie notwendig, mehr als eines anzusammeln. Dies reduziert die Anzahl der Rückgaben weiter. Manche Implementierungen können große Puffer verwenden, um auch Element-Bereich-Schnittpunkte aufzuzeichnen und die Traversierung über den ersten identifizierten Bereich hinaus fortzusetzen, der ansonsten mitten in der Traversierung zurückgegeben werden kann, wenn der Element-Bereich angetroffen wird.
Der Hauptunterschied, und die Verwendung einer Hardware-Lösung ermöglicht dies, besteht darin, dass wir diejenigen Elemente oder Dreiecke verbergen können, die nachweislich ohne funktionalen Einfluss auf die resultierende Szene verborgen werden können, während deterministische Ergebnisse geliefert werden. Die Bestimmung, welche Primitive ohne funktionalen Einfluss auf die resultierende Szene verborgen werden können, kann auf Basis einer mitten in der Traversierung der BVH durchgeführten Alpha-basierten Verarbeitung erfolgen. Durch Handhabung der Alpha-basierten Verarbeitung mitten in der Traversierung muss der Strahl nicht jedes Mal von Beginn an neu abgefeuert werden.
Die Ausführungsformen dieser Offenbarung unterscheiden sich von Software-implementierten Methoden, bei denen die Textur- oder Shading-Funktionen erst evaluiert werden, nachdem der nächstgelegene Treffer in der BVH für den gesamten Dreieck-Bereich bestimmt worden ist. Bei Software-implementierten Methoden wird der nächstgelegene Treffer evaluiert, um zu bestimmen, ob irgendetwas das Licht blockiert, und dann startet der Shader einen neuen Strahl. Im Gegensatz dazu sehen Ausführungsformen dieser Offenbarung Alpha-Verarbeitung mitten in der Traversierung vor, was die Anzahl der Strahlenwerf-Abfragen, die durchgeführt werden müssen, reduzieren kann.
In einem Ausführungsbeispiel kann die TTU konfiguriert sein, um alle opaken Primitive zu verarbeiten, um vor einer Verarbeitung zur Verarbeitung des Alpha-Primitivs, um mögliche Schnittpunkte zu bestimmen, den nächstgelegenen Opak-Treffer zu bestimmen. In dieser Ausführungsform kann der Strahl nach dem Testen aller opaken Primitive auf die parametrische Länge des nächstgelegenen Opak-Treffers verkürzt werden, und irgendwelche Alpha-Primitive, die parametrisch weiter vom Ursprung entfernt sind als der Opak-Schnittpunkt, werden als nicht von dem Strahl geschnitten bestimmt.
Nach der Verarbeitung von Primitiven in einem Primitiv-Bereich kann die TTU die Traversierung fortsetzen und in der TTU bleiben, statt die Ergebniswarteschlange jedes Mal an den SM zurückzugeben, wenn die Verarbeitung des Primitiv-Bereichs, die einen Treffer findet, beendet ist. Die Übertragung von in der Ergebniswarteschlange gespeicherten Schnittpunkt-Informationen an einen kann in manchen Ausführungsformen mindestens bis nach der Verarbeitung des letzten Primitivs des letzten Blocks des Primitiv-Bereichs angehalten werden. Die TTU kann die Traversierung fortsetzen und die Rückgabe einer Ergebniswarteschlange mit Treffern darin an den SM aufschieben, wenn es nur einen Opak-Treffer im Ergebnispuffer gibt und keine Flags anzeigen, dass in dem Primitiv-Bereich gefundene Schnittpunkte fallen gelassen oder annulliert wurden, da die Ergebniswarteschlange voll war (z. B. Verbleibende-Alphas), oder wenn sich Alphas in der Ergebniswarteschlange befinden und keine Flags anzeigen, dass in dem Primitiv-Bereich gefundene Schnittpunkte fallen gelassen oder annulliert wurden, da die Ergebniswarteschlange voll war (z. B. Verbleibende-Alphas) und der Ergebnispuffer gegenwärtig nicht voll ist. In manchen Ausführungsformen kann die TTU die Traversierung fortsetzen und die Rückgabe einer Ergebniswarteschlange mit Treffern darin an den SM aufschieben, solange Modus-Bits sagen, dass es in Ordnung ist, die Traversierung fortzusetzen (z. B. ist kein Flag terminateOnFirstHit („beendeBeiErstemTreffer“) gesetzt), und die TTU gibt die Ergebniswarteschlange zurück, wenn die Traversierung abgeschlossen ist.
13 wird mit Bezug auf das Liefern von Schnittpunktergebnissen in einer deterministischen Weise auf Basis der aufsteigenden Speicheradressen-Reihenfolge der Primitive erörtert. In anderen Ausführungsbeispielen können die Ergebnisse deterministisch geliefert werden, indem die Primitiv-Schnittpunkte in absteigender Speicheradressen-Reihenfolge zurückgegeben werden. In anderen Ausführungsbeispielen können die Ergebnisse deterministisch geliefert werden, indem die Primitiv-Schnittpunkte in der Reihenfolge zurückgegeben werden, in der sich die Alpha-Primitive räumlich in Speicherplatz befinden, unabhängig von der Reihenfolge, in der Blöcke vom Speicher-Subsystem zur Verarbeitung an die TTU zurückgegeben werden.
In manchen Ausführungsbeispielen kann die Abfrage Informationen zum Modifizieren der Art und Weise der Behandlung von opaken und/oder Alpha-Dreiecken umfassen. Zum Beispiel kann die Abfrage die TTU anweisen, opake Dreiecke als Alpha-Dreiecke und/oder Alpha-Dreiecke als opake Dreiecke zu behandeln.
In manchen Beispielen können die abfragespezifischen dynamischen und programmierbaren Änderungen in den Traversierungsprozess einbezogen werden, indem ein Pro-Strahl-Satz von Strahloperationen (jede Strahloperation wird als „RayOp“ bezeichnet), zugeordneten Strahlparametern, Strahl-Flags und Modus-Flags bereitgestellt wird, auf deren Basis das Standardverhalten der TTU-Traversierung auf einer Pro Strahl- und/oder Pro-Schnittpunkt-Basis geändert werden kann. Weitere Details zum Einstellen von Pro-Strahl-Operationen findet man in der gleichzeitig anhängigen US-Anmeldung Nr. (Anwaltsakte: 6610-0035/18-SC-0144) mit dem Titel „Query-Specific Behavioral Modification of Tree Traversal“, die hiermit in ihrer Gesamtheit durch Bezugnahme aufgenommen wird. Die Strahl-Flag-Einstellungen können bestimmen, wie die Alpha-Dreiecke und/oder opaken Dreiecke behandelt werden. Die Strahl-Flag-Einstellung kann die Alpha-Bit-Einstellung in dem Dreieck-Block überspielen. Dementsprechend ist das Bit im Dreieck-Block möglicherweise nicht das definitive Bit zum Spezifizieren, ob ein Dreieck innerhalb des RTT als opak oder Alpha zu behandeln ist. Die Art und Weise der Behandlung der Dreiecke kann durch die Pro-Strahl-Modus-Bits modifiziert werden, um ein anderes Verhalten zu erreichen.
Die Strahl-Flag-Einstellung kann die TTU anweisen, alle opaken Dreiecke als Alpha-Dreiecke für eine gegebene Abfrage zu behandeln, so dass die Schnittpunktergebnisse jedes geschnittene Alpha- und opake Dreieck an den SM zurückgeben. In einem anderen Beispiel kann die Strahl-Flag-Einstellung die TTU anweisen, alle Alpha-Dreiecke als opake Dreiecke für eine gegebene Abfrage, das nächstgelegene geschnittene Dreieck zurückzugeben, zu behandeln (unabhängig davon, ob der nächstgelegene Schnittpunkt mit einem opaken Dreieck oder einem Alpha-Dreieck besteht).
Beispiel-Strahl-Dreieck-Traversierung, die deterministische Ergebnisse liefert
14, 15A-C, 16A-C und 17A-D veranschaulichen nicht einschränkende Ausführungsbeispiele der Rückgabe von Schnittpunktergebnissen für einen Bereich von in einer Mehrzahl von in Speicher gespeicherten Blöcken identifizierten Dreiecken. In dem in 14 gezeigten Beispiel überschreitet die Anzahl der geschnittenen Dreiecke in dem Dreieck-Bereich eine Anzahl von Einträgen in der Ergebniswarteschlange nicht. In dem in 15A-C und 16A-C gezeigten Beispiel überschreitet die Anzahl der geschnittenen Dreiecke in dem Dreieck-Bereich eine Anzahl von Einträgen in der Ergebniswarteschlange, und es sind mehrere Rückgaben mitten in der Traversierung nötig, um die Schnittpunktergebnisse an den SM zurückzugeben. 14, 15A-C und 16A-C veranschaulichen unabhängige Warteschlangen zum Speichern von Opak- und Alpha-Schnittpunkt-Ergebnissen. In anderen Ausführungsformen kann die Ergebniswarteschlange als eine Einzel-Warteschlange mit Opak/Alpha-Markierungen implementiert sein. 17A-D veranschaulichen ein Ausführungsbeispiel mit einer Einzeleintrag-Ergebniswarteschlange.
Mit Bezug auf 14 wird ein Bereich von Dreiecken, die auf Schnittpunkte mit einem Strahl zu testen sind, über drei Blöcke in Cache-Zeilen-Größe (Block 0, Block 1 und Block 2) identifiziert, die in einem Speichersystem gespeichert sind. Die Strahl-Dreieck-Schnittpunkt-Testeinheit der TTU empfängt die Blöcke aus einem Speichersystem als Antwort auf eine Anforderung nach den Blöcken. Die Reihenfolge, in der die Blöcke aus dem Speichersystem geliefert werden, kann davon abhängen, wo in der Hierarchie der BVH die angeforderten Blöcke liegen und/oder wo in der Hierarchie des Speichersystems die angeforderten Blöcke liegen. In dem in 14 gezeigten Beispiel wird zuerst Block 1, dann Block 2 und zuletzt Block 0 an die Strahl-Dreieck-Schnittpunkt-Einheit der TTU geliefert. Die TTU ist konfiguriert, um die in den Blöcken identifizierten Dreiecke in der Reihenfolge zu verarbeiten, in der sie aus dem Speichersystem empfangen werden, um die mit dem Warten auf Empfang eines jeden Blocks des Dreieck-Bereichs verknüpfte Latenz zu vermeiden. In einem Ausführungsbeispiel verarbeitet die Strahl-Dreieck-Schnittpunkt-Testeinheit in der TTU die in den Blöcken identifizierten Dreiecke in der Reihenfolge, in der sie aus dem L0-Cache der TTU empfangen werden.
Wie in 13 gezeigt, wird Block 1 zuerst aus dem Speichersystem empfangen, und die in Block 1 identifizierten Dreiecke werden verarbeitet (z. B. in der Reihenfolge, in der sie in dem Block angeordnet sind), um zu bestimmen, ob irgendwelche Dreiecke von dem Strahl geschnitten werden. Die TTU bestimmt, dass ein opakes Dreieck TriO_b1 und ein Alpha-Dreieck TriA_b1 in Block 1 geschnitten werden. Die TTU speichert Schnittpunkte des opaken Dreiecks TriO_b1 und Alpha-Dreiecks TriA_b1 in der Ergebniswarteschlange und fährt damit fort, die im nächsten empfangenen Block (d. h. Block 2) identifizierten Dreiecke zu verarbeiten.
Das Alpha-Dreieck TriA_b1 wird zu der Ergebniswarteschlange hinzugefügt, da sich das Alpha-Dreieck TriA_b1 räumlich zwischen einem Ursprung des Strahls und dem geschnittenen opaken Dreieck TriO_b1 befindet. Wenn sich das Alpha-Dreieck TriA_b1 hinter dem opaken Dreieck TriO_b1 befunden hätte, wäre es der Ergebniswarteschlange nicht hinzugefügt worden. Irgendwelche Alpha-Dreiecke, die räumlich von dem Strahl geschnitten werden können, aber räumlich hinter dem opaken Dreieck TriO_b1 liegen, werden nicht in die Ergebniswarteschlange aufgenommen.
Die in Block 2 identifizierten Dreiecke werden verarbeitet, um zu bestimmen, ob irgendwelche Dreiecke von dem Strahl geschnitten werden. Die TTU bestimmt, dass das Alpha-Dreieck TriA_b2 von dem Strahl in Block 2 geschnitten wird. Die TTU speichert den Schnittpunkt des Alpha-Dreiecks TriA_b2 in der Ergebniswarteschlange fährt damit fort, die im nächsten empfangenen Block (d. h. Block 0) identifizierten Dreiecke zu verarbeiten.
Die in Block 0 identifizierten Dreiecke werden verarbeitet, um zu bestimmen, ob irgendwelche Dreiecke von dem Strahl geschnitten werden. Die TTU bestimmt, dass das Alpha-Dreieck TriA_b0 von dem Strahl in Block 0 geschnitten wird. Die TTU speichert den Schnittpunkt des Alpha-Dreiecks TriA_b0 in der Ergebniswarteschlange. Das Alpha-Dreieck TriA_b0 ist ein Dreieck, das sich räumlich zwischen einem Ursprung des Strahls und dem geschnittenen opaken Dreieck TriO_b1 befindet.
Nachdem alle Blöcke und in den Blöcken identifizierten Dreiecke verarbeitet worden sind, können die Schnittpunktergebnisse in der Ergebniswarteschlange für weitere Verarbeitung an den SM geliefert werden. Die Schnittpunktergebnisse umfassen einen einzelnen Opakes-Dreieck-Schnittpunkt (opakes Dreieck TriO_b1), welches das dem Strahlursprung nächstgelegene opake Dreieck ist, und eine Mehrzahl von Alpha-Dreiecken, die sich räumlich zwischen dem Strahlursprung und dem opaken Dreieck befinden. Wie in 14 gezeigt, können die Alpha-Dreiecke in der Reihenfolge der Speicheradressen an den SM zurückgegeben werden. Die an den SM zurückgegebenen Alpha-Dreiecke müssen möglicherweise vom SM weiterverarbeitet werden, um auf Basis von den Alpha-Dreiecken zugeordneten Texturinformationen zu bestimmen, ob es einen Treffer gibt.
In dem in 14 gezeigten Beispiel enthält die Ergebniswarteschlange genügend Platz, um alle Schnittpunktergebnisse zu speichern. In manchen Ausführungsbeispielen ist die Größe der Ergebniswarteschlange jedoch möglicherweise begrenzt (z. B. auf einen einzelnen Eintrag oder wenige Einträge), um Chip-Fläche zu sparen, und/oder die Schnittpunktergebnisse überschreiten möglicherweise die Größe der Warteschlange. In diesen Fällen muss die TTU mehrere Rückgaben an den SM mitten in der Traversierung durchführen, um alle Schnittpunktergebnisse zu liefern.
Wenn die Schnittpunktergebnisse in der Reihenfolge geliefert werden, in der sie von der TTU bestimmt werden, kann die Reihenfolge der an den SM gelieferten Schnittpunktergebnisse variieren, je nachdem, welche Blöcke, die den Dreieck-Bereich identifizieren, zuerst von der TTU verarbeitet werden. Rückgabe der Schnittpunktergebnisse auf Basis der Reihenfolge, in der sie bestimmt werden, variiert möglicherweise nicht nur die Reihenfolge, in der die geschnittenen Dreiecke an den SM geliefert werden, sondern auch, welche Dreiecke an den SM zurückgegeben werden. Wenn zum Beispiel Block 2 fünf Alpha-Dreiecke enthält und Block 0 vor Block 1 verarbeitet wird, dann werden möglicherweise vier der Alpha-Dreiecke der Warteschlange hinzugefügt und an den SM zurückgegeben, bevor bestimmt wird, dass das opake Dreieck Tri0_b1 den Strahl daran gehindert hätte, die meisten dieser Dreiecke zu erreichen.
15A-C, 16A-C und 17A-D veranschaulichen ein Verfahren zur Rückgabe von Schnittpunktergebnissen unter Verwendung einer kleinen Ergebniswarteschlange für den gleichen Dreieck-Bereich wie in 14 gezeigt. In 15A-C und 16A-C enthält die Ergebniswarteschlange einen einzelnen Eintrag für einen Opakes-Dreieck-Schnittpunkt und einen einzelnen Eintrag für einen Alpha-Dreieck-Schnittpunkt. 17A-D veranschaulichen eine Ergebniswarteschlange mit einem einzelnen Eintrag. 15A-C und 16A-C veranschaulichen eine andere Reihenfolge, in der die Blöcke aus dem Speicher empfangen werden, wobei jedoch das gleiche Endergebnis an den SM geliefert wird.
In dem in 15A gezeigten Beispiel wird zuerst Block 1, dann Block 2 und zuletzt Block 0 an die Strahl-Dreieck-Schnittpunkt-Einheit der TTU geliefert. Wie in 15A gezeigt, wird Block 1 zuerst aus dem Speichersystem empfangen, und die in Block 1 identifizierten Dreiecke werden verarbeitet, um zu bestimmen, ob irgendwelche Dreiecke von dem Strahl geschnitten werden. Die TTU bestimmt, dass ein opakes Dreieck TriO_b1 und ein Alpha-Dreieck TriA_b1 in Block 1 geschnitten werden. Die TTU speichert Schnittpunkte des opaken Dreiecks TriO_b1 und des Alpha-Dreiecks TriA_b1 in der Ergebniswarteschlange und fährt damit fort, die im nächsten empfangenen Block (d. h. Block 2) identifizierten Dreiecke zu verarbeiten.
Die in Block 2 identifizierten Dreiecke werden verarbeitet, um zu bestimmen, ob irgendwelche Dreiecke von dem Strahl geschnitten werden. Die TTU bestimmt, dass das Alpha-Dreieck TriA_b2 von dem Strahl in Block 2 geschnitten wird. Da jedoch kein Platz in der Ergebniswarteschlange für zusätzliche Schnittpunktergebnisse vorhanden ist und das Alpha-Dreieck TriA_b2 später in der Speicherreihenfolge gefunden wird (z. B. nach Block 1), wird das Alpha-Dreieck TriA_b2 der Ergebniswarteschlange nicht hinzugefügt, und das nächste Dreieck / der nächste Block wird auf Schnittpunkt verarbeitet. Da ein Alpha-Dreieck-Schnittpunkt identifiziert, aber nicht zu der Ergebniswarteschlange hinzugefügt wird, wird das Flag Verbleibende-Alphas gesetzt, um anzuzeigen, dass geschnittene Alpha-Dreiecke, die nicht in der Ergebniswarteschlange enthalten sind, noch in dem Dreieck-Bereich vorhanden sind.
Nach der Verarbeitung von Dreiecken in Block 2 fährt die TTU fort, die im nächsten empfangenen Block (d. h. Block 0) identifizierten Dreiecke zu verarbeiten. Die TTU bestimmt, dass das Alpha-Dreieck TriA_b0 von dem Strahl in Block 0 geschnitten wird. Da sich das Alpha-Dreieck TriA_b0 in Speicherreihenfolge vor dem in der Ergebniswarteschlange gespeicherten Alpha-Dreieck TriA-b1 befindet, werden die Schnittpunkt-Informationen für das Alpha-Dreieck TriA-b1 in der Ergebniswarteschlange durch die Schnittpunkt-Informationen für das Alpha-Dreieck TriA_b0 ersetzt.
Nachdem alle Blöcke und in den Blöcken identifizierten Dreiecke verarbeitet worden sind, können die Schnittpunktergebnisse in der Ergebniswarteschlange für weitere Verarbeitung an den SM geliefert werden. Die Schnittpunktergebnisse umfassen einen einzelnen Opakes-Dreieck-Schnittpunkt (opakes Dreieck TriO_b1), welches das dem Strahlursprung nächstgelegene opake Dreieck ist, und ein einzelnes Alpha-Dreieck, welches das erste geschnittene Alpha-Dreieck in Speicherreihenfolge ist. Die Schnittpunktergebnisse werden mit Traversierungsstapel-Informationen geliefert, die den Status enthalten, der zum Fortsetzen der Traversierung zum Bestimmen irgendwelcher verbleibenden Alpha-Dreieck-Schnittpunkte in dem Dreieck-Bereich erforderlich ist. Auf Basis des Traversierungsstapels gibt der SM eine Abfrage an die TTU aus, um andere Alpha-Dreieck-Schnittpunkte in dem Dreieck-Bereich zu finden. In der Abfrage enthält der Dreieck-Bereich nicht die geschnittenen Alpha-Dreiecke, die bereits an den SM geliefert worden sind. Die Abfrage kann das cullOpaque-Flag für diesen Primitiv-Bereich setzen, so dass opake Dreiecke nicht erneut getestet werden, da der nächstgelegene Opak-Schnittpunkt bereits an den SM zurückgegeben worden ist.
15B zeigt eine zweite Abfrage, bei der in Block 1 und Block 2 identifizierte Dreieck-Bereiche auf Schnittpunkte getestet werden. Block 0 wird in diesem Fall nicht getestet, da das an den SM zurückgegebene geschnittene Alpha-Dreieck aus Block 0 möglicherweise das letzte Dreieck von Block 0 in Speicherreihenfolge war und der Traversierungsstapel den Block 0 nicht mehr enthielt. In dem in 15B gezeigten Beispiel wird zuerst Block 1 und dann Block 2 an die Strahl-Dreieck-Testeinheit geliefert. Die in Block 1 identifizierten Dreiecke werden verarbeitet, um zu bestimmen, ob irgendwelche Dreiecke von dem Strahl geschnitten werden. Die TTU bestimmt, dass das Alpha-Dreieck TriA_b1 in Block 1 geschnitten wird. In diesem Zeitpunkt werden opake Dreiecke möglicherweise nicht getestet, da das cullOpaque-Flag gesetzt ist. Die TTU speichert den Schnittpunkt des Alpha-Dreiecks TriA_b1 in der Ergebniswarteschlange und fährt damit fort, die im nächsten empfangenen Block (d. h. Block 2) identifizierten Dreiecke zu verarbeiten.
Die in Block 2 identifizierten Dreiecke werden verarbeitet, um zu bestimmen, ob irgendwelche Dreiecke von dem Strahl geschnitten werden. Die TTU bestimmt, dass das Alpha-Dreieck TriA_b2 von dem Strahl in Block 2 geschnitten wird. Da jedoch wie vorher kein Platz in der Ergebniswarteschlange für zusätzliche Schnittpunktergebnisse ist und das Alpha-Dreieck TriA_b2 später in der Speicherreihenfolge gefunden wird (z. B. nach Block 1), wird das Alpha-Dreieck TriA_b2 nicht zu der Ergebniswarteschlange hinzugefügt. Da ein Alpha-Dreieck-Schnittpunkt identifiziert, aber nicht zu der Ergebniswarteschlange hinzugefügt wird, wird wieder das Flag Verbleibende-Alphas gesetzt, um anzuzeigen, dass geschnittene Alpha-Dreiecke, die nicht in der Ergebniswarteschlange enthalten sind, noch in dem Dreieck-Bereich vorhanden sind.
Nachdem alle Blöcke und in den Blöcken identifizierten Dreiecke verarbeitet worden sind, werden die Schnittpunktergebnisse in der Ergebniswarteschlange für weitere Verarbeitung an den SM geliefert. Die Schnittpunktergebnisse umfassen ein einzelnes Alpha-Dreieck TriA-b1, welches das zweite geschnittene Alpha-Dreieck in Speicherreihenfolge ist. Die Schnittpunktergebnisse werden mit Traversierungsstapel-Informationen geliefert, die den Status enthalten, der zum Fortsetzen der Traversierung zum Bestimmen irgendwelcher verbleibenden Alpha-Dreieck-Schnittpunkte in dem Dreieck-Bereich erforderlich ist. Auf Basis des Traversierungsstapels gibt der SM eine andere Abfrage an die TTU aus, um andere Alpha-Dreieck-Schnittpunkte in dem Dreieck-Bereich zu finden.
15C zeigt eine dritte Abfrage, bei der in Block 1 und Block 2 identifizierte Dreieck-Bereiche auf Schnittpunkte getestet werden. Dreiecke, die dem Alpha-Dreieck TriA-b1 vorausgehen, werden in Block 1 nicht getestet, da der mit der neuen Abfrage zurückgegebene Traversierungsstapel auf das Dreieck zeigt, das dem TriA_b1 folgt, das gerade an den SM zurückgegeben worden ist. In dem in 15C gezeigten Beispiel wird zuerst Block 1 und dann Block 2 geliefert. Die in Block 1 identifizierten Dreiecke werden verarbeitet, um zu bestimmen, ob irgendwelche Dreiecke von dem Strahl geschnitten werden. Da alle geschnittenen Dreiecke in Block 1 identifiziert und an den SM zurückgegeben worden sind, werden in Block 1 keine anderen geschnittenen Dreiecke identifiziert, und die TTU fährt damit fort, im nächsten empfangenen Block (d. h. Block 2) identifizierte Dreiecke zu verarbeiten. Die in Block 2 identifizierten Dreiecke werden verarbeitet, um zu bestimmen, ob irgendwelche Dreiecke von dem Strahl geschnitten werden. Die TTU bestimmt, dass das Alpha-Dreieck TriA_b2 von dem Strahl in Block 2 geschnitten wird und dass keine anderen Dreiecke geschnitten werden. In diesem Zeitpunkt wird das Flag Verbleibende-Alphas nicht gesetzt, und die Ergebniswarteschlange wird für weitere Verarbeitung an den SM zurückgegeben.
15A-C veranschaulichen unabhängige Warteschlangen zum Speichern von Opak- und Alpha-Schnittpunkt-Ergebnissen, doch sind Ausführungsformen dieser Offenbarung nicht darauf beschränkt. In manchen Ausführungsformen kann die Ergebniswarteschlange als eine Einzel-Warteschlange mit Opak/Alpha-Markierungen implementiert sein. Zum Beispiel kann die Ergebniswarteschlange in 15B mit zwei Einträgen das Schnittpunktergebnis aus Block 1 (TriA_b1) in einem ersten Eintrag in der Ergebniswarteschlange und das Schnittpunktergebnis aus Block 2 (TriA_b2) im zweiten Eintrag der Ergebniswarteschlange speichern. Ein für jeden Eintrag gesetztes Flag kann anzeigen, ob der Eintrag ein Opak- oder Alpha-Schnittpunkt ist.
16A-C veranschaulichen die Verarbeitung von Dreiecken, die in einer Mehrzahl von Blöcken identifiziert sind, die in einer anderen Reihenfolge als in 14A-C aus dem Speicher empfangen werden. In 16A-C wird zuerst Block 0, dann Block 2 und zuletzt Block 1 empfangen. Wie in 16A-C gezeigt, obwohl die Blöcke in einer anderen Reihenfolge empfangen und verarbeitet werden, werden die an den SM gelieferten Schnittpunktergebnisse in der gleichen Reihenfolge wie in dem in 15A-C gezeigten Beispiel geliefert. Ein ähnlicher Prozess wie oben mit Bezug auf 15A-C beschrieben wird in 16A-C durchgeführt. 16A-C veranschaulichen unabhängige Warteschlangen zum Speichern von Opak- und Alpha-Schnittpunkt-Ergebnissen, doch sind Ausführungsformen dieser Offenbarung nicht darauf beschränkt. In manchen Ausführungsformen kann die Ergebniswarteschlange als eine Einzel-Warteschlange mit Opak/Alpha-Markierungen implementiert sein. Zum Beispiel kann die Ergebniswarteschlange in 16B mit zwei Einträgen das Schnittpunktergebnis aus Block 1 (TriA_b1) in einem ersten Eintrag in der Ergebniswarteschlange und das Schnittpunktergebnis aus Block 2 (TriA_b2) im zweiten Eintrag der Ergebniswarteschlange speichern. Ein für jeden Eintrag gesetztes Flag kann anzeigen, ob der Eintrag ein Opak- oder Alpha-Schnittpunkt ist.
17A-D veranschaulichen die Verarbeitung von Dreiecken, die in einer Mehrzahl von Blöcken identifiziert sind, die in der mit Bezug auf 16A-C empfangenen Reihenfolge empfangen werden. In der mit Bezug auf 17A-D dargestellten Implementierung wird ein einzelner Eintrag in der Ergebniswarteschlange für Opak- und Alpha-Ergebnisse verwendet. Dem Eintrag in der Ergebniswarteschlange wird eine Opak oder Alpha-Markierung gegeben, um anzuzeigen, ob das Ergebnis ein Alpha- oder Opak-Schnittpunkt ist.
In 17A wird Block 0 zuerst aus dem Speichersystem empfangen, und die in Block 0 identifizierten Dreiecke werden verarbeitet, um zu bestimmen, ob irgendwelche Dreiecke von dem Strahl geschnitten werden. Die TTU bestimmt, dass ein Alpha-Dreieck TriA_b0 in Block 0 geschnitten wird. Die TTU speichert die Schnittpunkte des Alpha-Dreiecks TriA_b0 in der Ergebniswarteschlange und fährt damit fort, die in den verbleibenden Blöcken (d. h. den Blöcken 1 und 2) identifizierten Dreiecke in der Reihenfolge zu verarbeiten, in der sie aus dem Speicher empfangen werden. Andere Alpha- und Opak-Schnittpunkte werden in Block 1 und Block 2 identifiziert. Während jeder Block verarbeitet wird, werden individuelle Primitive innerhalb des Blocks in Speicherreihenfolge verarbeitet. Wenn jeder Alpha-Schnittpunkt ankommt, wird er in die Ergebniswarteschlange eingefügt, solange dort Kapazität vorhanden ist. Wenn die Ergebniswarteschlange voll ist, wenn Schnittpunkte aus Block 1 und Block 2 ankommen, ersetzen diese Schnittpunkte nicht den Alpha-Schnittpunkt aus Block 0 (der bereits in der Ergebniswarteschlange gespeichert ist, da Schnittpunkte aus Block 1 und Block 2 von Primitiven stammen, die in Speicherreihenfolge später sind). Wie in 17A gezeigt, kann der Opak-Schnittpunkt (TriO_b1) in Block 1 den in der Ergebniswarteschlange gespeicherten Alpha-Dreieck Schnittpunkt ersetzen, obwohl er in der Speicherreihenfolge früher gefunden worden ist.
Nach Verarbeitung der Blöcke 0-2 werden die Schnittpunktergebnisse in der Ergebniswarteschlange mit Traversierungsstapel-Informationen an den SM geliefert, die den Status enthalten, der zum Fortsetzen der Traversierung zum Bestimmen irgendwelcher verbleibenden Alpha-Dreieck-Schnittpunkte in dem Dreieck-Bereich erforderlich ist. Die Schnittpunktergebnisse können bei Rückgabe einen Stapeleintrag zum Zeigen auf TriA_b0 (den nächsten identifizierten Schnittpunkt) enthalten. Auf Basis des Traversierungsstapels gibt der SM eine Abfrage an die TTU aus, um andere Dreieck-Schnittpunkte in dem Dreieck-Bereich zu finden. In der Abfrage kann das cullOpaque-Flag für diesen Primitiv-Bereich gesetzt sein, so dass opake Dreiecke nicht erneut getestet werden, da der nächstgelegene Opak-Schnittpunkt bereits an den SM zurückgegeben worden ist.
17B zeigt eine zweite Abfrage, bei der Dreieck-Bereiche beginnend mit einem Eintrag zu TriA_b0 in Block 0 gefolgt von den Dreiecken in Block 1 und Block 2 getestet werden. In diesem Zeitpunkt werden opake Dreiecke möglicherweise nicht getestet, da das cullOpaque-Flag gesetzt ist. Die TTU testet Dreiecke in Block 0 beginnend mit TriA_b0. Die TTU speichert den Schnittpunkt des Alpha-Dreiecks TriA_b0 in der Ergebniswarteschlange und fährt damit fort, die in den anderen empfangenen Blöcken (d. h. den Blöcken 1 und 2) identifizierten Dreiecke in der Reihenfolge zu verarbeiten, in der sie empfangen werden. Da der Alpha-Schnittpunkt in den anderen Blöcken nicht früher in der Speicherreihenfolge gefunden wird, wird das bereits gespeicherte Ergebnis in der Ergebniswarteschlange nicht durch die anderen identifizierten Schnittpunkte ersetzt und wird das Flag Verbleibende-Alphas gesetzt.
Die Schnittpunktergebnisse in der Ergebniswarteschlange (d. h. TriA_b0) werden mit Traversierungsstapel-Informationen an den SM geliefert, die den Status enthalten, der zum Fortsetzen der Traversierung zum Bestimmen irgendwelcher verbleibenden Alpha-Dreieck-Schnittpunkte in dem Dreieck-Bereich erforderlich ist. Die Schnittpunktergebnisse können bei Rückgabe einen Stapeleintrag zum Zeigen auf TriA_b0 oder TriA_b1 (z. B. den nächsten identifizierten Alpha-Schnittpunkt) enthalten. Auf Basis des Traversierungsstapels gibt der SM eine andere Abfrage an die TTU aus, um andere Dreieck-Schnittpunkte in dem Dreieck-Bereich zu finden.
17C zeigt eine dritte Abfrage, bei der in Block 1 und Block 2 identifizierte Dreieck-Bereiche auf Schnittpunkte getestet werden. In dem in 17C gezeigten Beispiel wird zuerst Block 2 und dann Block 1 an die Strahl-Dreieck-Testeinheit geliefert. Die in Block 2 identifizierten Dreiecke werden verarbeitet, um zu bestimmen, ob irgendwelche Dreiecke von dem Strahl geschnitten werden. Die TTU bestimmt, dass das Alpha-Dreieck TriA_b2 in Block 2 geschnitten wird, und speichert den Schnittpunkt des Alpha-Dreiecks TriA_b2 in der Ergebniswarteschlange. Die TTU verarbeitet die verbleibenden Dreiecke in Block 2 und die im nächsten empfangenen Block (d. h. Block 1) identifizierten Dreiecke. Die TTU bestimmt, dass das Alpha-Dreieck TriA_b1 in Block 1 geschnitten wird. Die TTU speichert das Alpha-Dreieck TriA_b1 in der Ergebniswarteschlange (indem sie den bereits gespeicherten Alpha-Schnittpunkt TriA_b2 ersetzt), da das Alpha-Dreieck TriA_b1 in Speicherreihenfolge früher gefunden wird als TriA_b2.
Die Schnittpunktergebnisse in der Ergebniswarteschlange (d. h. TriA_b1) werden mit Traversierungsstapel-Informationen an den SM geliefert, die den Status enthalten, der zum Fortsetzen der Traversierung zum Bestimmen irgendwelcher verbleibenden Alpha-Dreieck-Schnittpunkte in dem Dreieck-Bereich erforderlich ist. Die Schnittpunktergebnisse können bei Rückgabe einen Stapeleintrag zum Zeigen auf TriA_b1 oder TriA_b2 (z. B. den nächsten identifizierten Alpha-Schnittpunkt) enthalten. Auf Basis des Traversierungsstapels gibt der SM eine andere Abfrage an die TTU aus, um andere Dreieck-Schnittpunkte in dem Dreieck-Bereich zu finden.
17D zeigt eine vierte Abfrage, bei der in Block 2 identifizierte Dreieck-Bereiche auf Schnittpunkte getestet werden. In dem in 17D gezeigten Beispiel zeigt die Abfrage auf den nächsten Schnittpunkt (TriA_b2), der in der früheren Abfrage identifiziert worden ist. Die TTU verarbeitet die in Block 2 identifizierten Dreiecke, um geschnittene Dreiecke zu bestimmen. Die TTU speichert den identifizierten Schnittpunkt des Alpha-Dreiecks (TriA_b2) in der Ergebniswarteschlange. Die TTU verarbeitet die verbleibenden Dreiecke in Block 2. Da keine weiteren Dreiecke in Block 2 von dem Strahl geschnitten werden und alle Blöcke in dem Bereich verarbeitet worden sind, wird in diesem Zeitpunkt das Flag Verbleibende-Alphas nicht gesetzt, und der Strahl hat die Verarbeitung des Primitiv-Bereichs beendet. Wenn die Ergebniswarteschlange voll ist oder die Ergebniswarteschlange Alpha-Schnittpunkte des Strahls enthält, können die Ergebnisse für weitere Verarbeitung an den SM zurückgegeben werden. Andernfalls kann der Strahl verkürzt werden, falls erforderlich, und der Strahl kann innerhalb der TTU bleiben und den nächsten Traversierungsschritt starten. In dem mit Bezug auf 17A-D dargestellten Beispiel gäbe es vier Rückgaben in der Reihenfolge von: TriO_b1, TriA_b0, TriA_b1 und TriA_b2.
Wenn innerhalb eines Primitiv-Bereichs gefundene Alpha-Schnittpunkte an den SM zurückgegeben werden, bevor die Traversierung fortgesetzt wird, wie in den obigen Beispielen gezeigt, ändern die Reihenfolge, in der die Blöcke von der TTU empfangen werden, und/oder die Anzahl der Einträge in der Ergebniswarteschlange nicht die Reihenfolge, in der die Schnittpunktergebnisse durch die Ausführungsbeispiele an den SM geliefert werden. Die Anzahl der Einträge in der Warteschlange ändert möglicherweise die Anzahl der Rückgaben, aber die Reihenfolge, in der die Dreieck-Schnittpunkte an den SM geliefert werden, kann die gleiche bleiben. Da die in dieser Anmeldung offenbarten Ausführungsbeispiele deterministische Ergebnisse auch bei unterschiedlicher Anzahl von Einträgen in der Ergebniswarteschlange liefern können, kann die Größe der Ergebniswarteschlange in manchen Ausführungsbeispielen auf Basis der verfügbaren Ressourcen dynamisch geändert werden, ohne zu ändern, wie der SM die Ergebnisse sehen wird. Wenn innerhalb eines Primitiv-Bereichs gefundene Alpha-Schnittpunkte in der Ergebniswarteschlange zurückbehalten werden, statt sie an den SM zurückzugeben, wenn die Verarbeitung des Primitiv-Bereichs abgeschlossen ist, kann eine nachfolgende Traversierung nähere Opak-Schnittpunkte ergeben, welche die Alpha-Treffer annullieren und die Notwendigkeit beseitigen, sie an den SM zurückzugeben. Unter diesen Umständen wirkt sich die Anzahl der Einträge in der Warteschlange sowohl auf die Anzahl der Rückgaben als auch auf die Anzahl der an den SM zurückgegebenen Schnittpunkte aus, jedoch hat diese Beseitigung von verdeckten Primitiven keinen funktionalen Einfluss auf die Visualisierung der virtuellen Szene.
In 15A-C, 16A-C und 17A-17D ist jedes Mal, wenn die Abfrage durchgeführt wird, die Reihenfolge der empfangenen Blöcke als die gleiche dargestellt, ist aber nicht darauf beschränkt. In manchen Ausführungsformen kann sich die Reihenfolge ändern, je nach der Verfügbarkeit der Blöcke in verschiedenen Teilen des Speichersystems in dem Zeitpunkt, in dem die Anforderung verarbeitet wird.
Weiterhin enthielten die mit Bezug auf 15A-C, 16A-C und 17A-D beschriebenen Prozesse keine Beschreibung der Verarbeitung von mitten in der Traversierung zurückgegebenen Alpha-Primitiven, bevor eine nachfolgende Abfrage an die TTU ausgegeben worden ist. In manchen nicht einschränkenden Ausführungsbeispielen kann der SM vor Ausgabe einer nachfolgenden Abfrage an die TTU eine Alpha-Dreieck-bezogene Verarbeitung durchführen, um zu bestimmen, ob der Strahl durch das Alpha-Dreieck blockiert wird. Wenn der Strahl als blockiert bestimmt wird, kann der SM die Länge des Strahls in der nachfolgenden Abfrage modifizieren. Die oben mit Bezug auf 15A-C, 16A-C und 17A-D beschriebenen Operationen würden ebenfalls deterministische Ergebnisse liefern, wenn der SM eine Alpha-Schnittpunktbezogene Verarbeitung durchführt und eine Abfrage ausgibt, die auf den Ergebnissen der Verarbeitung basiert.
In den mit Bezug auf 14, 15A-C, 16A-C und 17A-D erörterten Beispielen wurden die deterministischen Ergebnisse durch Rückgabe von geschnittenen Alpha-Dreiecken in aufsteigender Speicheradressen-Reihenfolge an den SM geliefert. In anderen nicht einschränkenden Ausführungsbeispielen können ähnliche Operationen angewendet werden, um deterministische Ergebnisse auf Basis von anderen Kriterien zu liefern. Zum Beispiel können deterministische Ergebnisse von geschnittenen Dreiecken an den SM geliefert werden, indem die Ergebnisse auf Basis einer absteigenden Speicheradressen-Reihenfolge zurückgegeben werden, unabhängig von der Reihenfolge, in der die Dreiecke von der TTU verarbeitet werden. In einem anderen Beispiel können deterministische Ergebnisse von geschnittenen Dreiecken an den SM geliefert werden, indem die Ergebnisse auf Basis der räumlichen Lage der Dreiecke relativ zum Strahlursprung zurückgegeben werden, unabhängig von der Reihenfolge, in der die Dreiecke von der TTU verarbeitet werden.
In Ausführungsformen, die Ergebniswarteschlangen bereitstellen, die mehrere Schnittpunkte speichern können und in denen Alpha-Treffer gefunden werden, ohne die Kapazität der Ergebniswarteschlange zu überschreiten, kann die TTU konfiguriert sein, um Alpha-Schnittpunkte zurückzubehalten, statt sie sofort an den SM zurückzugeben. Die Motivation dafür ist, dass eine nachfolgende Traversierung auf nähere Opak-Treffer stoßen könnte, welche die zurückbehaltenen Alpha-Treffer annullieren und somit eine unnötige Synchronisation beseitigen. In dieser Ausführungsform kann bei der Verarbeitung eines eingehenden Alpha-Treffers, wenn die Ergebniswarteschlange voll ist, der eingehende Alpha-Treffer einen Schnittpunkt in der Ergebniswarteschlange aus dem gleichen Primitiv-Bereich wie der eingehende Alpha-Treffer ersetzen, wenn der eingehende Alpha-Treffer in der Speicherreihenfolge früher erscheint. In Fällen, in denen Alpha-Treffer zurückbehalten werden, nachdem eine Primitiv-Verarbeitung wegen später in der Traversierung gefundenen Opak-Treffern beseitigt worden ist, würden Änderungen in der Größe der Ergebniswarteschlange sowohl die Anzahl der Rückgaben als auch die Anzahl der zurückgegebenen Schnittpunkte ändern, ohne jedoch die funktionale Korrektheit des resultierenden Bildes zu beeinträchtigen.
Speziellere Beispiel-Strahl-Primitiv-Traversierung mit deterministischen Ergebnissen
Wie oben erörtert, verdecken Strahlschnittpunkte für opake Primitive eindeutig andere mögliche Schnittpunkte weiter weg entlang des Strahls. Strahlschnittpunkte für Alpha-Primitive erfordern möglicherweise zusätzliche Berechnungen des Streaming-Prozessors, um Transparenz, Beschneiden, Verschiebung, Konstruktionskörpergeometrie oder andere Effekte zu berücksichtigen oder zu klären. Beim Berechnen eines nächstgelegenen Schnittpunkts zwischen einem Strahl und einem Primitiv-Bereich, der aus mehreren zusammenhängenden Speicherblöcken besteht, die opake und Alpha-Primitive enthalten können, ist es wünschenswert, deterministische Ergebnisse zu liefern, während geschnittene Primitive aus dem Ergebnis beseitigt werden, die keinen funktionalen Einfluss auf die Visualisierung der virtuellen Szene haben. Ausführungsbeispiele dieser Offenbarung stellen eine Hardware-Schaltung bereit, die konfiguriert ist, um ein deterministisches Ergebnis unabhängig von der Reihenfolge zu erzeugen, in der ein Speicher-Subsystem Primitiv-Bereich-Blöcke an die TTU zurückgibt, während Alpha-Schnittpunkte, die entlang der Länge des Strahls weiter weg liegen als nähere Opak-Schnittpunkte, opportunistisch beseitigt werden.
Während andere Strahlverfolgungs-Render-Architekturen Transparenz- oder Beschneidungseffekte unterstützen (welche erfordern, Strahlen nach dem Shading von beschnittenen oder transparenten Punkten aus zu starten), ermöglichen die Ausführungsbeispiele dieser Anmeldung Inhalte mit programmierbaren Transparenz- oder Beschneidungseffekten, die mitten in der Traversierung evaluiert werden. Die Ausführungsbeispiele bieten die Leistung von Traversierung mit fester Funktion, ohne die Kontextflexibilität oder Leistung zu beeinträchtigen oder zusätzliche Strahlen verfolgen zu müssen. Die Ausführungsbeispiele verbessern die Leistung von Strahlverfolgungs-Rendern und gewährleisten eine zuverlässige Bildqualität und Stabilität in Szenen mit Alpha- und opaken Primitiven. Die Ergebniswarteschlange ermöglicht es Produktplanern, Fläche gegen Leistung einzutauschen (größere Ergebniswarteschlangen erlauben es der TTU, aufwändige Synchronisationen zu verzögern und möglicherweise zu vermeiden). Durch Evaluieren von Beschneiden oder Transparenz von Primitiven mitten in der Traversierung vermeiden wir den Zusatzaufwand für das Neustarten von Strahlen, wenn schattierte Fragmente beschnitten oder transparent sind.
In einer komprimierten Beschleunigungsdatenstruktur werden ein oder mehrere logische I-Knoten oder Blattknoten in komprimierten Blöcken (Complets) in Cache-Zeilen-Größe gespeichert, von denen jeder folgendes codiert: einen gemeinsamen BlattTyp, einen Kind-CompletZeiger, einen Kind-BlattZeiger, den Index des ersten Primitivs des ersten Kind-Blattes, und Pro-Kind-Daten, welche die Koeffizienten codieren, die eine Geometrie definieren, welche die Ausdehnungen der Kind-Blatt-Daten oder absteigenden Blatt-Daten begrenzt, und Daten, welche einen Bereich von Primitiven aufzählen, die innerhalb einer zusammenhängenden Gruppe von Blöcken codiert sind, die in Bezug auf den BlattZeiger (oder das Ende des vorherigen Blatt-Kindes) ausgedrückt werden. Primitiv-Bereiche sind ein solcher Blatt-Typ. Wenn BlattTyp = PrimitivBereich, dann enthalten die Pro-Kind-Bits ein Alpha-Bit (das anzeigt, ob irgendwelche Alpha-Primitive in dem Bereich vorhanden sind), die Anzahl der Cache-Zeilen und den Start-Index, wo das erste Primitiv des nächsten Blattknotens beginnt.
Jeder Block in Cache-Zeilen-Größe innerhalb eines Primitiv-Bereichs enthält einen Kopf, der den Typ der innerhalb des Blocks ausgedrückten Geometrie und das Codierschema (zum Beispiel komprimierte Dreiecke) identifiziert, die Anzahl der Primitive in dem Block (minus eins), und einen Satz Erzwinge-kein-Culling-Bits, die anzeigen, ob Culling für jedes Primitiv in dem Block zu deaktivieren ist, sowie einen Satz Alpha-Bits, die für jedes Primitiv in dem Block anzeigen, ob das Primitiv ein Alpha-Primitiv oder ein opakes Primitiv ist.
Wenn der Strahl-Complet-Test (RCT) das erste Blattknoten-Kind findet, dessen Begrenzungsgeometrie von dem Strahl getroffen wird, schiebt die Traversierungs-Logik im RCT einen ersten Stapeleintrag oben auf den Stapel des Strahls, dessen Inhalte:

• Den Stapeleintrag als Primitiv-Bereich identifizieren
• Spezifizieren:
- ◯ addrLast (die Adresse der letzten Zeile des Primitiv-Bereichs),
- ◯ triIdx (der Index des ersten Primitivs in der ersten Cache-Zeile des Bereichs),
- ◯ triEnd (eins plus der Index des letzten Primitivs in der letzten Cache-Zeile oder eine Null, um anzuzeigen, dass der Bereich bis zum Ende der letzten Cache-Zeile reicht), und
- ◯ lines (die Anzahl der zusammenhängenden Cache-Zeilen im Bereich plus eins, es sei denn triEnd=0, in welchem Fall lines die Anzahl der zusammenhängenden Cache-Zeilen ist, die von dem Dreieck-Bereich berührt werden).

Jeder Stapeleintrag kann auch ein Bit co (Cull Opaque Hits, „Aussondere Opak-Treffer“) enthalten.
Wenn der Koprozessor Kurzstapeltraversierung verwendet, schiebt er nur einen Stapeleintrag, der direkt auf den Primitiv-Bereich verweist, oben auf den Stapel oder unter andere, in dem gleichen Traversierungsschritt oben auf den Stapel geschobene Blattknoten. Wenn die Abfrage vorschrieb, dass ein Primitiv-Bereich nach einem oder mehreren I-Knoten zu verschieben ist (deren Nachkommen möglicherweise genügend Stapeleinträge schieben könnten, um den Stapel überlaufen zu lassen), oder wenn das Schieben des Primitiv-Bereichs die Kapazität des Stapels übersteigen und dazu führen würde, dass die verbleibenden I-Knoten „verloren“ gehen, wird der Koprozessor stattdessen einen Fortsetzungs-Knoten schieben, der indirekt auf den Primitiv-Bereich verweist (als das N-te Kind seines Eltern-I-Knotens), da im Gegensatz zu dem Primitiv-Bereich der Eltern-I-Knoten Eltern-Zeiger hat, die bei Bedarf verwendet werden können, um die Traversierung fortzusetzen, nachdem der Primitiv-Bereich und alle Blattknoten oben auf dem Stapel die Verarbeitung beendet haben.
Wenn die Stapelverwaltungseinheit (SMU) einen Primitiv-Bereich-Stapel-Eintrag von oben vom Traversierungsstapel entfernt, benachrichtigt die SMU den Primitiv-Scheduler, dass ein Strahl bereit ist, für Schnittpunkttesten gegen einen Primitiv-Bereich geplant zu werden, indem sie eine Aktivierungsanforderung an den Primitiv-Scheduler sendet. Der Primitiv-Scheduler zeichnet ein Bit auf, das anzeigt, dass eine Primitiv-Aktivierung angefordert worden ist. Wenn der Primitiv-Scheduler über genügend SMU- und Arbeitsverteilungseintrags-Guthaben verfügt, sendet der Primitiv-Scheduler eine Oben-auf-dem-Stapel-Blatt-Anfrage an die Stapelverwaltungseinheit. Die Stapelverwaltungseinheit sendet dann ein TopLeafReturn („OberstesBlattRückgabe“) an den Primitiv-Scheduler, das den Strahl-Slot-Index für den Strahl, addrLast, triIdx, triEnd, lines, rayOpPass („rayOpÜbergabe“), CullOpaque („AussondereOpak“) und CullAlpha („AussondereAlpha“) enthält. Der Primitiv-Scheduler wird diese Werte in einem Eintrag in der Primitiv-Scheduler-Arbeitsverteilungs-Warteschlange aufzeichnen.
Zwecks Culling aufgrund von RayOps wird das RayOp-Testergebnis zusammen mit den Modus-Bits aus den in der Strahlverwaltungseinheit (RMU) gespeicherten Strahl-Flags in den Strahl-Dreieck-Testblock (RTT) übergeben. Die Aussondere-Opak und Aussondere-Alpha-Bits im Stapeleintrag können unterschiedlich verwendet werden. Aussondere-Alpha (ca) kann gesetzt werden, wenn das Complet nicht das ‚Alpha‘-Flag für dieses Kind gesetzt hat. Aussondere-Opak (co) kann gesetzt werden, nachdem der RTT ausgeführt worden ist und ein opakes Dreieck mit gesetzten verbleibenden Alphas zurückzugeben ist. Eine letzte Bedingung ist, sowohl Aussondere-Alpha (ca) als auch Aussondere-Opak in der Strahl-Complet-Test/Traversierungs-Logik (RCT/TL) zu setzen, was von der SMU dahingehend interpretiert wird, den Primitiv-Bereich an den SM zurückzugeben, statt ihn lokal zu verarbeiten. Im Laufe der Verarbeitung des Primitiv-Bereichs kann die IMU den Wert der Trildx- oder CullOpaque-Felder überspielen, wenn sie den Strahl an den Streaming-Prozessor zurückgibt, um Alpha-Schnittpunkte zu liefern, so dass, wenn der Streaming-Prozessor den Strahl der TTU wiedervorlegt, das Schnittpunkttesten irgendwelche Alpha-Primitive überspringt, die bereits an den Streaming-Prozessor zurückgegeben worden sind, oder alle opaken Primitive überspringt, wenn alle opaken Primitive bereits durch den Dreieck-Bereich verarbeitet worden sind.
Um die verschiedenen Primitiv-Treffer-Typen zu behandeln, unterhält die Schnittpunktverwaltungseinheit der TTU eine Ergebniswarteschlange-Datenstruktur, die für jeden Strahl Speicherplatz für einen Opakes-Primitiv-Schnittpunkt oder einen Alpha-Primitiv-Schnittpunkt sowie null oder mehr zusätzliche Einträge für zusätzliche Alpha-Schnittpunkte enthält. Die Ergebniswarteschlange kann nach Abschluss einer Abfrage an den SM zurückgegeben werden, oder mitten in der Traversierung, sollte SM-Intervention erforderlich werden (zum Beispiel wenn die Anzahl der innerhalb eines einzelnen Dreieck-Bereichs gefundenen Alpha-Treffer die Speicherkapazität der Ergebniswarteschlange für Alpha-Treffer überschreitet).
Jeder Ergebniswarteschlangen-Eintrag spezifiziert einen Treffertyp und eine parametrische Länge, die den Punkt entlang des Strahls spezifiziert, an dem der Treffer aufgetreten ist, und Attribute des Treffers wie z. B. die Instanz-ID, Material-ID oder Primitiv-ID, die von dem SM verwendet werden können, um einen bestimmten Material-Shader und einen Satz von Ressourcenbindungen auszuwählen, und Primitiv-IDs und Koordinaten (u,v), die von dem SM während Shading verwendet werden können, um Attribute oder Abtasttexturen auszulesen und zu interpolieren.
Da Primitiv-Blöcke mehrere opake oder Alpha-Primitive in irgendeiner Reihenfolge codieren können und da sich Primitiv-Bereiche über mehrere vom Speicher-Subsystem in beliebiger Reihenfolge zurückgegebene Blöcke erstrecken können, verfügt die TTU über Mechanismen, um sicherzustellen, dass eine Abfrage unabhängig von der Speicherrückgabereihenfolge von Blöcken in einem Primitiv-Bereich ein deterministisches Ergebnis erzeugt:

o Die TTU unterhält den Status für jede Abfrage, die den Fortschritt der Verarbeitung des Primitiv-Blocks verfolgt.
- • Ein initialisiertes Flag wird zwischen Primitiv-Bereichen auf false („falsch“) gesetzt und wird auf true („wahr“) gesetzt, wenn die Ergebniswarteschlange das erste Primitiv aus dem Primitiv-Bereich empfängt.
- • Eine Zählung von pendingCacheLines („anstehendeCacheZeilen“) wird auf die Anzahl der verbleibenden in dem Primitiv-Bereich zu verarbeitenden Blöcke initialisiert.
- • Ein Flag remainingAlphas („Verbleibende-Alphas“) zeigt an, ob es in dem Primitiv-Bereich noch andere Alpha-Treffer gibt als die in der Ergebnisliste gespeicherten.
- • Ein Flag hitUpdated („TrefferAkualisiert“) zeigt an, ob ein Treffer in dem Primitiv-Bereich gefunden worden ist.
◯ Die TTU wird keinen eingehenden Opak- oder Alpha-Schnittpunkt in der Ergebniswarteschlange aufzeichnen, wenn sein t-Wert über dem t-Wert eines Opak-Schnittpunkts liegt.
◯ Die TTU fügt einen eingehenden Alpha-Treffer von früher in der Speicheradressen-Reihenfolge des Primitiv-Bereichs vor einem Alpha-Treffer aus dem gleichen Primitiv-Bereich ein, der in der Speicheradressen-Reihenfolge später erscheint, unabhängig davon, ob der eingehende Alpha-Treffer parametrisch näher oder weiter weg ist als der Treffer, der zeitlich früher, aber in Speicheradressen-Reihenfolge später war.
◯ Wenn es keine verfügbaren Einträge zum Speichern des eingehenden Treffers früher in Speicheradressen-Reihenfolge gibt, wird der eingehende Treffer den zeitlich früheren, aber in Speicheradressen-Reihenfolge späteren Alpha-Treffer ersetzen und wird Verbleibende-Alphas auf TRUE setzen.
◯ Wenn ein eingehender Alpha-Treffer parametrisch näher ist als ein Opak-Treffer aus dem gleichen Primitiv-Bereich, es aber keine verfügbaren Einträge zum Speichern des eingehenden Alpha-Treffers gibt (d. h. sie sind von Alpha-Treffern besetzt, die in Speicherreihenfolge früher sind), wird die TTU den eingehenden Alpha-Treffer fallenlassen, den Opak- Treffer zurückbehalten und Verbleibende-Alphas auf TRUE setzen.
◯ Wenn ein eingehender Opak-Treffer parametrisch näher ist als irgendeiner der Alpha-Treffer in der Ergebniswarteschlange, wird die TTU diejenigen Alpha-Treffer in der Ergebniswarteschlange, die parametrisch weiter weg sind als in dem eingehenden Opak-Treffer, annullieren. Die TTU wird den eingehenden Opak-Treffer speichern. Das Flag Verbleibende-Alphas wird in diesem Fall jedoch nicht gelöscht.
◯ Wenn die parametrische Länge eines eingehenden Opak-Treffers identisch ist mit der parametrischen Länge eines in der Ergebnisliste gespeicherten Opak-Treffers, gewinnt der Treffer, der in der Speicherreihenfolge des Primitiv-Bereichs früher war, den Gleichstandsbrecher und ersetzt den Opak-Treffer, der in der Speicherreihenfolge später war.
◯ Wenn jeder Block abgeschlossen ist, wird pendingCacheLines dekrementiert.
◯ Wenn pendingCacheLines Null erreicht, sind alle Blöcke verarbeitet worden,
- • Wenn es in diesem Zeitpunkt einen Opak-Treffer in der Ergebniswarteschlange gibt, wird es der parametrisch nächstgelegene Opak-Treffer sein, der während der Traversierung angetroffen wird.
- • Wenn es irgendwelche Alpha-Treffer in der Ergebniswarteschlange gibt, werden sie parametrischer näher liegen als irgendein Opak-Treffer in der Ergebniswarteschlange, aber in Speicherreihenfolge in der Ergebniswarteschlange gespeichert werden.
- • Wenn verbleibende-Alphas gesetzt ist, dann wurden neben den in der Ergebnisliste vorhandenen Alpha-Treffern weitere Alpha-Treffer in dem Primitiv-Bereich später in Speicherreihenfolge gefunden. Diese verbleibenden Alpha-Treffer müssen verarbeitet werden, nachdem der SM den Satz von Alpha-Treffern in der Ergebniswarteschlange verbraucht hat. Die TTU modifiziert den Traversierungsstatus so, dass der oberste Stapeleintrag (der auf den aktuellen Primitiv-Bereich verweist) cullOpaque auf TRUE setzt, und erhöht den Start-Primitiv-Index auf 1 + den größten Alpha-Dreieck-Index aus dem aktuellen Primitiv-Bereich, der in der Ergebniswarteschlange gespeichert ist.
- • Die TTU gibt den Strahl, seine Ergebniswarteschlange und den Traversierungsstatus an den Streaming-Prozessor zurück.
- • Der Streaming-Prozessor führt irgendwelche erforderlichen Alpha-Test-Operationen durch und filtert irgendwelche Alpha-Schnittpunkte, die den Alpha-Test nicht bestehen, und irgendwelche Opak- oder Alpha-Schnittpunkte, die jenseits des nächstgelegenen Alpha-Schnittpunkts liegen, der den Alpha-Test bestanden hat, aus und zeichnet irgendwelche gültigen Treffer in Registern oder Speicher auf, worauf der Eltern-Thread der Abfrage Zugriff hat, und legt die Abfrage dann wieder vor, um die Traversierung fortzusetzen.
• Wenn verbleibende-Alphas nicht gesetzt ist:
- • Wenn die Abfrage noch nicht zugewiesene Einträge in der Ergebniswarteschlange aufweist, kann die TTU die Traversierung ohne Rückgabe an den SM fortsetzen.
- • Wenn die Abfrage keine verbleibenden nicht zugewiesenen Einträge in der Ergebniswarteschlange aufweist und es einen oder mehrere Alpha-Treffer in der Ergebniswarteschlange gibt, gibt die TTU die Abfrage und den zugehörigen Traversierungsstatus an den SM zurück, so dass der SM folgendes tun kann:
  - ◯ Führe irgendwelche Alpha-Tests durch.
  - ◯ Filtere irgendwelche Alpha-Treffer aus, die den Alpha-Test nicht bestehen, und filtere irgendwelche Opak- oder Alpha-Treffer aus, die jenseits des nächstgelegenen Opak- oder Alpha-Treffers liegen, der den Alpha-Test bestanden hat.
  - ◯ Lege die Abfrage erneut vor, mit möglicherweise verkürztem Strahl (falls erforderlich), um die Traversierung fortzusetzen.

Die Ergebniswarteschlange führt eine Sichtbare-Oberflächen-Zusammensetzungsfunktion ähnlich der Art und Weise aus, wie ein Tiefenpuffer bei Rastergrafik gerastete Fragmente in Sichtbarkeitsreihenfolge sortiert. Die Kapazität der Ergebniswarteschlange erlaubt es der Architektur, Fläche gegen Effizienz einzutauschen, um die Häufigkeit aufwändiger Synchronisationen zu reduzieren, die erforderlich sind, um Alpha-Treffer (oder auch mögliche Element-Bereich-Treffer) an den SM zurückzugeben. Durch Verarbeitung von Alpha-Treffern in einem Primitiv-Block in Speicheradressen-Reihenfolge statt in der Reihenfolge, in der Blöcke vom Speicher-Subsystem zurückgegeben werden, ist die TTU im Stande, deterministische Ergebnisse zu erzeugen, ohne die Leistung des Speicher-Subsystems einzuschränken.
Jeder komprimierte Block in der Beschleunigungsstrukturhierarchie hat ein oder mehrere Kinder, von denen manche andere interne Knoten in dem Baum sein können und manche Blattknoten im Kontext einer von der TTU traversierten Beschleunigungsdatenstruktur sind, die aus mehreren Speicherblöcken zusammengesetzt ist, die sowohl opake Primitive (deren Strahlschnittpunkte andere mögliche Schnittpunkte weiter weg entlang des Strahls eindeutig verdecken) als auch Alpha-Primitive (deren Schnittpunkte Berechnungen des Streaming-Prozessors erfordern, um Transparenz, Beschneiden, Verschiebung, Konstruktionskörpergeometrie oder andere Effekte zu berücksichtigen oder zu klären) enthalten.
In nicht einschränkenden Ausführungsbeispielen ermöglichen Primitiv-Bereiche ein Verfahren zum Spezifizieren einer Gruppe von Primitiven einer vom Koprozessor unterstützten Geometrieklasse innerhalb einer Beschleunigungsdatenstruktur, die innerhalb einer Sequenz von komprimierten oder unkomprimierten Speicherblöcken codiert sind, die der Koprozessor gegen irgendwelche Strahlen testen soll, die einen bestimmten Punkt (oder bestimmte Punkte) im Traversierungsraum der Beschleunigungsdatenstruktur erreichen. Innerhalb eines Primitiv-Bereichs zeigt jedes Primitiv an, ob es als Opak bezeichnet wird (was anzeigt, dass irgendein Schnittpunkt zwischen einem Strahl und dem Primitiv eindeutig irgendwelche Schnittpunkte verdeckt, die entlang des Strahls parametrisch weiter weg liegen) oder als Alpha (was anzeigt, dass der geometrische Schnittpunkt möglicherweise unterdrückt, perturbiert oder durch eine Alpha-Test-Operation auf dem SM ergänzt wird).
In nicht einschränkenden Ausführungsbeispielen können Primitiv-Bereiche innerhalb des Kontextes einer Beschleunigungsstruktur (an einem bestimmten Punkt in der Traversierung der Beschleunigungsstruktur) platziert werden, um eine Anordnung von Primitiven eines gemeinsamen Typs zu spezifizieren, die gegen irgendeinen Strahl zu testen sind, der diesen bestimmten Punkt in der Traversierung der Beschleunigungsstruktur erreicht.
Somit kann innerhalb der Beschleunigungsstruktur der Primitiv-Bereich innerhalb der Blatt-Daten der Beschleunigungsstruktur die Adresse des ersten Blocks, der das erste Dreieck in dem Bereich enthält, den Index des ersten Dreiecks innerhalb dieses ersten Blocks, die Gesamtzahl der Blöcke in dem Bereich und den Index des letzten Primitivs in dem letzten Block ausdrücken. Mehrere Primitiv-Bereiche innerhalb der Beschleunigungsstruktur können auf verschiedene Teilmengen der Dreiecke im Block verweisen. Wenn zum Beispiel in der TTU der Strahl einen Kind-Begrenzungskasten schneidet, der einem Primitiv-Bereich-Kind-Block zugeordnet ist, schiebt die TTU einen Stapeleintrag oben auf den Traversierungsstapel, der eines oder mehrere der folgenden Bitfelder enthält:

◯ addrLast - Die Adresse des letzten Blocks in dem Primitiv-Bereich
◯ triIdx - Der (inklusive) Index des ersten Primitivs in dem Primitiv-Bereich in der ersten Cache-Zeile
◯ triEnd - Der (exklusive) Index des letzten Primitivs in der letzten Cache-Zeile in dem Bereich oder Null, was anzeigt, dass der Bereich in der vorherigen Cache-Zeile endete
◯ lines - Die Anzahl der Blöcke - 1, die den Primitiv-Bereich enthalten (außer triEnd=0, dann ist lines die Anzahl der Blöcke)

Mehrere Primitiv-Bereiche innerhalb der Beschleunigungsstruktur können auf den gleichen Block verweisen, so dass die Blöcke, die Primitive in einem Primitiv-Bereich enthalten, möglicherweise keine Eltern-Zeiger aufweisen.
Wenn ein Strahl während der Traversierung einer Beschleunigungsdatenstruktur auf einen Primitiv-Bereich trifft (zum Beispiel wenn ein Strahl den Begrenzungskasten eines Blattknotens schneidet, dessen Kind-Daten einen Primitiv-Bereich spezifizieren), kann der Koprozessor den Primitiv-Bereich für sofortiges Testen oben auf seinen Traversierungsstapel schieben oder kann den Eintrag tiefer in dem Stapel unter anderen Primitiv-Bereichen platzieren, die in dem gleichen Traversierungsschritt in Übereinstimmung mit den durch die Abfrage spezifizierten Kriterien früher geschoben worden sind (zum Beispiel um parametrisch nähere Primitiv-Bereiche oder Knoten zuerst zu testen).
In einem nicht einschränkenden Ausführungsbeispiel bietet Strahl-Primitiv-Bereich-Verarbeitung einen Mechanismus, um den Streaming-Prozessor von der Aufgabe zu entlasten, Strahlen gegen Primitiv-Bereiche zu testen, auf welche die Beschleunigungsdatenstruktur verweist, die sich über mehrere Blöcke erstreckt.
In einem nicht einschränkenden Ausführungsbeispiel bieten Element-Bereiche ein Verfahren zum Spezifizieren einer Gruppe von Primitiven einer Geometrieklasse, die vom Koprozessor unterstützt werden können oder nicht und die innerhalb einer Sequenz von Speicherblöcken codiert sind, innerhalb einer Beschleunigungsdatenstruktur.
In einem nicht einschränkenden Ausführungsbeispiel bietet Element-Schnittpunkttest-Delegierung dem Koprozessor einen Mechanismus, um mitten in der Traversierung durchgeführtes Schnittpunkttesten von Primitiv-Bereichen, die Primitive einer Klasse enthalten, die von der Strahl-Primitiv-Verarbeitung des Koprozessors nicht unterstützt wird, an den Streaming-Prozessor zu delegieren, um sie mit programmierbarer Funktionalität auszuführen, und dann die Traversierung im Koprozessor bedingt wieder aufzunehmen.
In einem nicht einschränkenden Ausführungsbeispiel bietet Alpha-Test-Delegierung dem Koprozessor einen Mechanismus, um zwischen spezifisch konfigurierten Strahlen und spezifisch konfigurierten Primitiven in einem Primitiv-Bereich gefundene Schnittpunkte an den Streaming-Prozessor zurückzugeben, so dass der Streaming-Prozessor das Ergebnis des Schnittpunkttests mit programmierbarer Funktionalität wie z. B. Alpha-Testen (oder anderen dem Fachmann bekannten Merkmalen) überspielen, unterdrücken oder erweitern und dann die Traversierung im Koprozessor bedingt wieder aufnehmen kann.
In einem nicht einschränkenden Ausführungsbeispiel bietet die Ergebniswarteschlange eine Datenstruktur innerhalb des Koprozessors zum Speichern eines oder mehrerer Opak- oder Alpha-Primitiv-Schnittpunkte, die während der Traversierung gefunden werden. Die Ergebniswarteschlange erlaubt es dem Koprozessor, Alpha-Tests aufzuschieben und möglicherweise ganz zu vermeiden, wenn ein näherer Opak-Schnittpunkt einen Alpha-Schnittpunkt verdeckt.
In einem nicht einschränkenden Ausführungsbeispiel bietet die Verarbeitung ungeordneter Blöcke einen Satz von Regeln für Strahl-Primitiv-Bereich-Verarbeitung, um sicherzustellen, dass Abfragen robuste, deterministische Ergebnisse erzeugen, wenn Primitiv-Bereiche getestet werden, die sich über mehrere Blöcke erstrecken, die vom Speicher-Subsystem in beliebiger Reihenfolge zurückgegeben werden, unabhängig von der Reihenfolge und Anzahl der gefundenen Alpha- und Opak-Schnittpunkte.
Der Koprozessor kann konfiguriert sein, um stabile Bilder ohne störende Artefakte mit Traversierung zu erzeugen, die ein deterministisches Ergebnis für eine Abfrage bei einem gegebenem Strahl und einem gegebenem Primitiv-Bereich, der eine Mischung aus opaken und Alpha-Primitiven enthält, die sich über mehrere Blöcke erstrecken, unabhängig von der Reihenfolge liefert, in der das Speicher-Subsystem diese Blöcke an den Koprozessor zurückgibt.
Um dieses Ergebnis zu erzielen, kann der Koprozessor eine Anzahl von Rückgaben an den SM mitten in der Traversierung durchführen, um Alpha-Schnittpunkte zu handhaben, deren Anzahl und Inhalt von Durchlauf zu Durchlauf variieren kann, da Änderungen in der Reihenfolge der an die TTU zurückgegebenen Blöcke eine unterschiedliche Reihenfolge von Opak-Schnittpunkten erzeugen, die unterschiedliche Sätze von innerhalb desselben Primitiv-Bereichs gefundenen Alpha-Schnittpunkten maskieren können oder nicht, doch stellen die Ergebniswarteschlange und die Regeln für Verarbeitung ungeordneter Blöcke sicher, dass die aus der abgeschlossenen Verarbeitung des Primitiv-Bereichs resultierenden Nebenwirkungen von Durchlauf zu Durchlauf konsistent sind.
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. 18 veranschaulicht ein Beispiel-Flussdiagramm für die Verarbeitung von Primitiven, um Bildpixelwerte eines Bildes zu liefern, gemäß einer Ausführungsform.
Wie 18 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 22 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 19-21, 23, 24, 25 und/oder 26 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. 18 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 19-26 beschrieben ist. Eine derartige Parallelverarbeitungsarchitektur kann zum Beispiel zum Implementieren der GPU 130 von 1 verwendet werden.
Beispiel-Parallelverarbeitungsarchitektur
19 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 19 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 25 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 20 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 23 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.
20 veranschaulicht eine Speicherpartitionseinheit 1780 der PPU 1700 von 19 gemäß einer Ausführungsform. Wie in 20 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 20 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
21 veranschaulicht ein GPC 1750 der PPU 1700 von 19 gemäß einer Ausführungsform. Wie in 21 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 21 anstelle der oder zusätzlich zu den in 21 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 19 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 20 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-raytracing/). 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 20). 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.
22 ist ein Konzeptdiagramm einer mittels der PPU 1700 von 19 implementierten Grafikverarbeitungs-Pipeline 2000. Die Grafikverarbeitungs-Pipeline 2000 ist ein abstraktes Flussdiagramm der zur Erzeugung von 2D-Computerbildern aus 3D-Geometriedaten implementierten Verarbeitungsschritte. Wie bekannt, können Pipeline-Architekturen Operationen mit langer Latenz effizienter durchführen, indem sie die Operation in eine Vielzahl von Stufen aufteilen, wobei der Ausgang jeder Stufe mit dem Eingang der nächstfolgenden Stufe gekoppelt ist. Somit empfängt die Grafikverarbeitungs-Pipeline 2000 Eingabedaten 2001, die von einer Stufe zur nächsten Stufe der Grafikverarbeitungs-Pipeline 2000 übertragen werden, um Ausgabedaten 2002 zu erzeugen. In einer Ausführungsform kann die Grafikverarbeitungs-Pipeline 2000 eine durch die OpenGL®-API definierte Grafikverarbeitungs-Pipeline repräsentieren. Optional kann die Grafikverarbeitungs-Pipeline 2000 im Kontext der Funktionalität und Architektur der vorherigen Figuren und/oder irgendwelcher nachfolgender Figur(en) implementiert werden. Wie oben mit Bezug auf 14 erörtert, kann die Strahlverfolgung zur Verbesserung der durch Rasterung von geometrischen Primitiven erzeugten Bildqualität verwendet werden. In manchen Ausführungsformen können die in dieser Anmeldung offenbarten Strahlverfolgungs-Operationen und TTU-Strukturen auf einen oder mehrere Zustände der Grafikverarbeitungs-Pipeline 2000 angewendet werden, um die subjektive Bildqualität zu verbessern.
Wie in 22 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. LI-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.
23 veranschaulicht den Streaming-Multiprozessor 1840 von 21 gemäß einer Ausführungsform. Wie in 23 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. 24 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/L 1-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-/SpeicherOperationen die verbleibende Kapazität nutzen. Integration in den Gemeinschaftsspeicher/L1-Cache 1970 ermöglicht es dem Gemeinschaftsspeicher/Ll-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.
24 veranschaulicht eine Beispiel-Architektur für den SM 1840. Wie in 21 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 21). 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 LI-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.
25 ist ein Konzeptdiagramm eines unter Verwendung der PPU 1700 von 19 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 25 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 25 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 25 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.
26 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, 0047, 0062, 0125]
US 9552664 [0001]
US 9569559 [0001, 0017, 0047]
US 10025879 [0001]
US 14737343 [0001]
US 16101066 [0001]
US 16101109 [0001]
US 16101247 [0001]
US 16101180 [0001]
US 16101148 [0001]
US 16101232 [0001]
US 20160070820 [0017]
US 20160070767 [0017]
US 14697480 [0124]
US 2016/0071234 [0146]

Claims

System, das folgendes enthält: Speicher, der konfiguriert ist, um mindestens einen Teil einer Beschleunigungsdatenstruktur zu speichern, die eine Mehrzahl von hierarchischen Knoten enthält, wobei mindestens ein Knoten Primitive einer virtuellen Szene identifiziert; und autonome Hardware-Schaltung, die operativ mit dem Speicher gekoppelt ist und konfiguriert ist, um: in der Reihenfolge, in der die in dem mindestens einen Knoten identifizierten Primitive aus Speicher empfangen werden, Primitive zu bestimmen, die von einem Strahl geschnitten werden; und mindestens einen Teil der als von dem Strahl geschnitten bestimmten Primitive in einer Speicherreihenfolge zu melden, in der die Primitive in dem Speicher gespeichert sind.
System nach Anspruch 1, wobei die autonome Hardware-Schaltung einen Koprozessor aufweist.
System nach Anspruch 1 oder 2, wobei der Speicher konfiguriert ist, um eine Mehrzahl von Blöcken in Cache-Zeilen-Größe zu speichern, die jeweils einen anderen Satz von in dem mindestens einen Knoten identifizierten Primitiven enthalten, und wobei die Blöcke von der Hardware-Schaltung nicht in der Reihenfolge empfangen werden, in der sie in dem Speicher gespeichert sind.
System nach einem der Ansprüche 1 bis 3, wobei die Hardware-Schaltung weiterhin konfiguriert ist, um das Melden von einem oder mehreren als von dem Strahl geschnitten bestimmten Primitiven auszulassen.
System nach Anspruch 4, wobei die ausgelassenen ein oder mehreren Primitive Primitive umfassen, die nachweislich ohne funktionalen Einfluss auf die Visualisierung der virtuellen Szene ausgelassen werden können.
System nach Anspruch 5, wobei die von dem Strahl geschnittenen Primitive, die nachweislich ohne funktionale Auswirkung auf die Visualisierung der virtuellen Szene ausgelassen werden können, parametrisch weiter von einem Ursprung des Strahls entfernt sind als ein anderes als von dem Strahl geschnitten bestimmtes Primitiv.
System nach einem der Ansprüche 1 bis 6, wobei die in dem mindestens einen Knoten identifizierten Primitive opake Primitive und Alpha-Primitive umfassen und wobei die Hardware-Schaltung konfiguriert ist, um ein von dem Strahl geschnittenes opakes Primitiv, welches ein zu einem Ursprung des Strahls parametrisch nächstgelegenes geschnittenes opakes Primitiv ist, und eine Mehrzahl von von dem Strahl geschnittenen Alpha-Primitiven in der Speicherreihenfolge, in der die Alpha-Primitive in dem Speicher gespeichert sind, einem Streaming-Prozessor zu identifizieren.
System nach einem der Ansprüche 1 bis 7, wobei die Hardware-Schaltung konfiguriert ist, um: wenn bestimmt wird, dass der Strahl ein neues Primitiv schneidet, zu bestimmen, ob eine Ergebniswarteschlange einen leeren Eintrag zum Speichern von Schnittpunkt-Informationen für das neue geschnittene Primitiv enthält oder nicht; wenn bestimmt wird, dass die Ergebniswarteschlange einen leeren Eintrag zum Speichern von Schnittpunkt-Informationen für das neue geschnittene Primitiv enthält, Schnittpunkt-Informationen für das neue geschnittene Primitiv zu speichern; wenn bestimmt wird, dass die Ergebniswarteschlange keinen leeren Eintrag zum Speichern der Schnittpunkt-Informationen für das neue geschnittene Primitiv enthält, zu bestimmen, ob das neue geschnittene Primitiv früher in dem Speicher gespeichert ist als andere geschnittene Primitive, für die Schnittpunkt-Informationen in der Ergebniswarteschlange gespeichert sind; wenn bestimmt wird, dass das neue geschnittene Primitiv früher in dem Speicher gespeichert ist als die anderen geschnittenen Primitive, Schnittpunkt-Informationen für eines der anderen geschnittenen Primitive durch die Schnittpunkt-Informationen für das neue geschnittene Primitiv zu ersetzen; und in der Ergebniswarteschlange gespeicherte Schnittpunkt-Informationen an einen Streaming-Prozessor zu übertragen.
System nach Anspruch 8, wobei das neue geschnittene Primitiv in der virtuellen Szene räumlich weiter weg von einem Ursprung des Strahls positioniert ist als die anderen geschnittenen Primitive, für die Informationen in der Ergebniswarteschlange gespeichert sind.
System nach einem der Ansprüche 1 bis 9, wobei die Primitive Alpha-Primitive und opake Primitive umfassen und wobei die Hardware-Schaltung konfiguriert ist, um: wenn bestimmt wird, dass der Strahl ein neues opakes Primitiv schneidet, Schnittpunkt-Informationen für das neue opake Primitiv zu speichern und als von dem Strahl geschnitten bestimmte Alpha-Primitive und opake Primitive parametrisch weiter weg entlang des Strahls als das neue opake Primitiv zu annullieren.
System nach einem der Ansprüche 1 bis 10, wobei der mindestens eine Knoten einen Primitiv-Bereich identifiziert, der Alpha-Primitive enthält, und wobei die Hardware-Schaltung konfiguriert ist, um: wenn bestimmt wird, dass der Strahl ein neues Alpha-Primitiv in dem Primitiv-Bereich schneidet, zu bestimmen, ob eine Ergebniswarteschlange, die Schnittpunkt-Informationen für ein oder mehrere geschnittene Primitive speichert, einen leeren Eintrag zum Speichern von Schnittpunkt-Informationen für das neue geschnittene Alpha-Primitiv enthält oder nicht; wenn bestimmt wird, dass die Ergebniswarteschlange den leeren Eintrag nicht enthält, zu bestimmen, ob ein Alpha-Schnittpunkt höherer Speicherreihenfolge aus dem gleichen Primitiv-Bereich wie das neue geschnittene Alpha-Primitiv in der Ergebniswarteschlange gespeichert ist; wenn bestimmt wird, dass der Alpha-Schnittpunkt höherer Speicherreihenfolge aus dem gleichen Primitiv-Bereich wie das neue geschnittene Alpha-Primitiv in der Ergebniswarteschlange gespeichert ist, den Alpha-Schnittpunkt höherer Speicherreihenfolge durch den neuen Alpha-Schnittpunkt zu ersetzen; und in der Ergebniswarteschlange gespeicherte Schnittpunkt-Informationen an einen Streaming-Prozessor zu übertragen.
System nach einem der Ansprüche 1 bis 11, wobei die Primitive opake Primitive umfassen und wobei die Hardware-Schaltung konfiguriert ist, um: wenn bestimmt wird, dass der Strahl zwei oder mehr opake Primitive mit Schnittpunkt gleicher parametrischer Länge entlang des Strahls schneidet, einen einzelnen Opakes-Primitiv-Schnittpunkt der zwei oder mehr opaken Primitive zu melden, der früher in dem Speicher gespeichert ist.
System nach einem der Ansprüche 1 bis 12, wobei die in dem mindestens einen Knoten identifizierten Primitive opake Primitive und Alpha-Primitive umfassen und wobei die Hardware-Schaltung konfiguriert ist, um: ein als von dem Strahl geschnitten bestimmtes opakes Primitiv, das ein zu einem Ursprung des Strahls parametrisch nächstgelegenes geschnittenes opakes Primitiv ist, einem Streaming-Prozessor zu identifizieren; und eine Mehrzahl von als von dem Strahl geschnitten bestimmten Alpha-Primitiven, die räumlich zwischen dem Ursprung des Strahls und dem parametrisch nächstgelegenen opaken Primitiv liegen, dem Streaming-Prozessor in der Speicherreihenfolge zu identifizieren, in der die geschnittenen Alpha-Primitive in dem Speicher gespeichert sind.
System nach einem der Ansprüche 1 bis 13, wobei die in mindestens einem der Knoten identifizierten Primitive einen Bereich von Dreiecken umfassen, die innerhalb einer zusammenhängenden Gruppe von Blöcken codiert sind; und die Hardware-Schaltung eine Strahl-Dreieck-Test- und Transformationseinheit und eine Schnittpunktverwaltungseinheit enthält, wobei die Strahl-Dreieck-Test- und Transformationseinheit Verarbeitungslogik enthält, die konfiguriert ist, um den Strahl aus dem Welt-Raum in den Objekt-Raum des Bereichs von Dreiecken zu transformieren und Dreiecke in dem Bereich von Dreiecken zu bestimmen, die von dem Strahl in dem Objekt-Raum geschnitten werden, und wobei die Schnittpunktverwaltungseinheit eine Ergebniswarteschlange enthält und konfiguriert ist, um zu bestimmen, welche geschnittenen Dreiecke nachweislich ohne funktionalen Einfluss auf die Visualisierung der virtuellen Szene ausgelassen werden können, und die geschnittenen Dreiecke in der Speicherreihenfolge, in der die geschnittenen Dreiecke in dem Speicher gespeichert sind, an einen Streaming-Prozessor zurückzugeben.
Verfahren, das durch einen hardwarebasierten Traversierungs-Koprozessor implementiert wird, der mit einem Streaming-Multiprozessor gekoppelt ist, wobei das Verfahren umfasst: mindestens einen Teil einer Beschleunigungsdatenstruktur, die eine Vielzahl von hierarchischen Knoten enthält, in Speicher zu speichern, wobei mindestens ein Knoten Primitive einer virtuellen Szene identifiziert; in der Reihenfolge, in der die in dem mindestens einen Knoten identifizierten Primitive aus Speicher empfangen werden, Primitive zu bestimmen, die von einem Strahl geschnitten werden; und mindestens einen Teil der als von dem Strahl geschnitten bestimmten Primitive in einer Speicherreihenfolge zu melden, in der die Primitive in dem Speicher gespeichert sind.
Verfahren nach Anspruch 15, wobei der Speicher konfiguriert ist, um eine Mehrzahl von Blöcken in Cache-Zeilen-Größe zu speichern, die jeweils einen anderen Satz von in dem mindestens einen Knoten identifizierten Primitiven enthalten, und wobei die Blöcke von der Hardware-Schaltung nicht in der Reihenfolge empfangen werden, in der sie in dem Speicher gespeichert sind.
Verfahren nach Anspruch 15 oder 16, das weiterhin umfasst, das Melden von einem oder mehreren als von dem Strahl geschnitten bestimmten Primitiven an den Streaming-Multiprozessor auszulassen.
Verfahren nach Anspruch 17, wobei die ausgelassenen ein oder mehreren Primitive Primitive umfassen, die nachweislich ohne funktionalen Einfluss auf die Visualisierung der virtuellen Szene ausgelassen werden können.
Verfahren nach Anspruch 18, wobei die von dem Strahl geschnittenen Primitive, die nachweislich ohne funktionalen Einfluss auf die Visualisierung der virtuellen Szene ausgelassen werden können, parametrisch weiter von einem Ursprung des Strahls entfernt sind als ein anderes als von dem Strahl geschnitten bestimmtes Primitiv.
Verfahren nach einem der Ansprüche 15 bis 19, wobei die in dem mindestens einen Knoten identifizierten Primitive opake Primitive und Alpha-Primitive umfassen und wobei die Hardware-Schaltung konfiguriert ist, um ein von dem Strahl geschnittenes opakes Primitiv, welches ein zu einem Ursprung des Strahls parametrisch nächstgelegenes geschnittenes opakes Primitiv ist, und eine Mehrzahl von von dem Strahl geschnittenen Alpha-Primitiven in der Speicherreihenfolge, in der die Alpha-Primitive in dem Speicher gespeichert sind, einem Streaming-Prozessor zu identifizieren.
Verfahren nach einem der Ansprüche 15 bis 20, wobei die in dem mindestens einen Knoten identifizierten Primitive opake Primitive und Alpha-Primitive umfassen und wobei das Verfahren weiterhin umfasst: ein als von dem Strahl geschnitten bestimmtes opakes Primitiv, das ein zu einem Ursprung des Strahls parametrisch nächstgelegenes geschnittenes opakes Primitiv ist, einem Streaming-Prozessor zu identifizieren; und eine Mehrzahl von als von dem Strahl geschnitten bestimmten Alpha-Primitiven, die räumlich zwischen dem Ursprung des Strahls und dem parametrisch nächstgelegenen opaken Primitiv liegen, dem Streaming-Prozessor in der Speicherreihenfolge zu identifizieren, in der die geschnittenen Alpha-Primitive in dem Speicher gespeichert sind.
Verfahren nach einem der Ansprüche 15 bis 21, wobei die in dem mindestens einen Knoten identifizierten Primitive Alpha-Dreiecke und opake Dreiecke umfassen und wobei der Strahl durch Drei-Koordinaten-Ursprung, Drei-Koordinaten-Richtung und Minimal- und Maximalwerte für einen t-Parameter entlang des Strahls identifiziert wird.
Hardwarebasierter Traversierungs-Koprozessor, der konfiguriert ist, um: von einem Streaming-Multiprozessor eine Abfrage zu empfangen, die einen Strahl und eine Baumdatenstruktur zum Testen auf Primitiv-Schnittpunkte mit dem Strahl identifiziert; aus Speicher außerhalb der Baumtraversierungseinrichtung Teile der Baumdatenstruktur auszulesen, wobei jeder Teil ein oder mehrere Begrenzungsvolumina einer Hierarchie von in der Baumdatenstruktur identifizierten Begrenzungsvolumina identifiziert; kleinste Unterteilungen der Hierarchie von Begrenzungsvolumina, die von dem Strahl geschnitten werden, zu bestimmen; einen Bereich von in der kleinsten Unterteilung der Hierarchie der von dem Strahl geschnittenen Begrenzungsvolumina identifizierten Primitiven auf einen Stapel zu schieben; in der Reihenfolge, in der die Primitive in dem Bereich von Primitiven aus Speicher empfangen werden, Primitive zu bestimmen, die von einem Strahl geschnitten werden; einen oder mehrere Schnittpunkte für als von dem Strahl geschnitten bestimmte Primitive in einer Speicherreihenfolge, in der die als von dem Strahl geschnitten bestimmten Primitive in dem Speicher gespeichert sind, in einer Ergebniswarteschlange zu speichern; Schnittpunkt-Informationen der in der Ergebniswarteschlange gespeicherten geschnittenen Primitive an den Streaming-Multiprozessor zurückzugeben.
Traversierungs-Koprozessor nach Anspruch 23, wobei der Speicher konfiguriert ist, um eine Mehrzahl von Blöcken in Cache-Zeilen-Größe zu speichern, die jeweils einen anderen Satz von in mindestens einem Knoten der Baumdatenstruktur identifizierten Primitiven enthalten, und wobei die Blöcke von dem hardwarebasierten Traversierungs-Koprozessor nicht in der Reihenfolge empfangen werden, in der sie in dem Speicher gespeichert sind.
Traversierungs-Koprozessor nach Anspruch 23 oder 24, wobei die in der Ergebniswarteschlange gespeicherten geschnittenen Primitive mitten in der Traversierung der Baumdatenstruktur an den Streaming-Multiprozessor übertragen werden.
Traversierungs-Koprozessor nach einem der Ansprüche 23 bis 25, wobei die in der Ergebniswarteschlange gespeicherten geschnittenen Primitive nach Abschluss einer Verarbeitung auf Primitiv-Ebene von in den kleinsten Unterteilungen der Hierarchie von als von dem Strahl geschnitten bestimmten Begrenzungsvolumina identifizierten Primitiven an den Streaming-Multiprozessor übertragen werden.
System, das folgendes enthält: Speicher, der konfiguriert ist, um mindestens einen Teil einer Beschleunigungsdatenstruktur zu speichern, die eine Mehrzahl von hierarchischen Knoten enthält, wobei mindestens ein Knoten Primitive einer virtuellen Szene identifiziert; und einen hardwarebasierten Traversierungs-Koprozessor, der operativ mit dem Speicher und einem Multiprozessor gekoppelt ist, wobei der Traversierungs-Koprozessor konfiguriert ist, um: die Beschleunigungsdatenstruktur zu traversieren, um Primitive in dem mindestens einen Knoten zu bestimmen, die von einem Strahl geschnitten werden; und Schnittpunkt-Informationen für ein als von dem Strahl geschnitten bestimmtes Primitiv in dem mindestens einen Knoten mitten in der Traversierung der Beschleunigungsdatenstruktur an den Multiprozessor zu melden.
System nach Anspruch 27, wobei der Traversierungs-Koprozessor konfiguriert ist, um die Primitive in dem mindestens einen Knoten in der Reihenfolge zu verarbeiten, in der die Primitive aus dem Speicher empfangen werden.
System nach Anspruch 27 oder 28, wobei der Traversierungs-Koprozessor konfiguriert ist, um zusammen mit den Schnittpunkt-Informationen Statusinformationen zu melden, die benötigt werden, um die Traversierung der Beschleunigungsdatenstruktur fortzusetzen, um andere von dem Strahl geschnittene Primitive zu bestimmen.
System, das folgendes enthält: Speicher, der konfiguriert ist, um mindestens einen Teil einer Beschleunigungsdatenstruktur zu speichern, die eine Mehrzahl von hierarchischen Knoten enthält, wobei mindestens ein Knoten Primitive einer virtuellen Szene identifiziert und wobei die Primitive des Primitiv-Bereichs in einer Mehrzahl von Blöcken in Cache-Zeilen-Größe gespeichert sind, die jeweils einen anderen Satz von Primitiven des Primitiv-Bereichs enthalten; und autonome Hardware-Schaltung, die operativ mit dem Speicher gekoppelt und konfiguriert ist, um: die Blöcke in der Reihenfolge zu verarbeiten, in der die Blöcke aus Speicher empfangen werden, um von einem Strahl geschnittene Primitive zu bestimmen, wobei die Blöcke von der Hardware-Schaltung nicht in der Reihenfolge empfangen werden, in der sie in dem Speicher gespeichert sind; und nachdem jedes Primitiv des Primitiv-Bereichs verarbeitet worden ist, Schnittpunkt-Informationen für mindestens einen Teil der als von dem Strahl geschnitten bestimmten Primitive zu melden.
System nach Anspruch 30, wobei der Primitiv-Bereich opake und Alpha-Primitive enthält und wobei die Hardware-Schaltung konfiguriert ist, um: Schnittpunkt-Informationen für mindestens einen Teil der als von dem Strahl geschnitten bestimmten Primitive in einer Ergebniswarteschlange zu speichern, und wenn nur ein Opakes-Primitiv-Schnittpunkt in der Ergebniswarteschlange gespeichert ist und keine Flags anzeigen, dass in dem Primitiv-Bereich gefundene Primitiv-Schnittpunkte fallen gelassen oder annulliert worden sind, da die Ergebniswarteschlange voll war, Primitive aus einem anderen Primitiv-Bereich zu verarbeiten, um Schnittpunkte zu bestimmen, bevor der in der Ergebniswarteschlange gespeicherte Opakes-Primitiv-Schnittpunkt gemeldet wird.
System nach Anspruch 30 oder 31, wobei der Primitiv-Bereich opake und Alpha-Primitive enthält und wobei die Hardware-Schaltung konfiguriert ist, um: Schnittpunkt-Informationen für mindestens einen Teil der als von dem Strahl geschnitten bestimmten Primitive in einer Ergebniswarteschlange zu speichern, und wenn ein oder mehrere Alpha-Primitiv-Schnittpunkte in der Ergebniswarteschlange gespeichert sind und keine Flags anzeigen, dass in dem Primitiv-Bereich gefundene Primitiv-Schnittpunkte fallen gelassen oder annulliert worden sind, da die Ergebniswarteschlange voll war und die Ergebniswarteschlange nicht voll ist, Primitive aus einem anderen Primitiv-Bereich zu verarbeiten, um Schnittpunkte zu bestimmen, bevor die in der Ergebniswarteschlange gespeicherten Primitiv-Schnittpunkte gemeldet werden.
System nach einem der Ansprüche 30 bis 32, wobei die Hardware-Schaltung konfiguriert ist, um: Schnittpunkt-Informationen für mindestens einen Teil der als von dem Strahl geschnitten bestimmten Primitive in einer Ergebniswarteschlange zu speichern, und wenn jedes Primitiv des Primitiv-Bereichs verarbeitet worden ist und ein Strahl-Modus-Bit anzeigt, die Traversierung fortzusetzen, Primitive aus einem anderen Primitiv-Bereich zu verarbeiten, um Schnittpunkte zu bestimmen, bevor die in der Ergebniswarteschlange gespeicherten Primitiv-Schnittpunkte gemeldet werden.
System nach einem der Ansprüche 30 bis 33, wobei der Primitiv-Bereich opake und Alpha-Primitive enthält und wobei die Hardware-Schaltung konfiguriert ist, um: Schnittpunkt-Informationen für mindestens einen Teil der als von dem Strahl geschnitten bestimmten Primitive in einer Ergebniswarteschlange zu speichern, und wenn die Ergebniswarteschlange keinen Platz zum Speichern von Schnittpunkt-Informationen für ein als von dem Strahl geschnitten bestimmtes Alpha-Primitiv hat oder ein in der Ergebniswarteschlange gespeicherter Alpha-Primitiv-Schnittpunkt durch ein anderes Alpha-Primitiv ersetzt wird, ein Flag Verbleibende-Alphas zu setzen, das anzeigt, dass andere Alpha-Primitive in dem Primitiv-Bereich nicht in der Ergebniswarteschlange enthalten sind.
System nach einem der Ansprüche 30 bis 34, wobei der Primitiv-Bereich opake und Alpha-Primitive umfasst und wobei die Hardware-Schaltung konfiguriert ist, um: Schnittpunkt-Informationen für mindestens einen Teil der als von dem Strahl geschnitten bestimmten Primitive in einer Ergebniswarteschlange zu speichern; und wenn die Ergebniswarteschlange keinen Platz zum Speichern von Schnittpunkt-Informationen für ein als von dem Strahl geschnitten bestimmtes Alpha-Primitiv hat oder ein in der Ergebniswarteschlange gespeicherter Alpha-Primitiv-Schnittpunkt durch ein anderes Alpha-Primitiv ersetzt wird, einen Traversierungsstapel zu modifizieren, um das Testen von Primitiven in dem Primitiv-Bereich an dem ersten Alpha-Primitiv nach dem in der Ergebniswarteschlange gespeicherten Primitiv-Schnittpunkt höchster Speicherreihenfolge fortzusetzen; und die in der Ergebniswarteschlange gespeicherten Schnittpunkt-Informationen und den modifizierten Traversierungsstapel an einen Multiprozessor zu melden.