DE102021206234A1 - Frühzeitige freigabe von ressourcen in strahlverfolgungs-hardware - Google Patents

Abstract

Es werden Techniken zur Verbesserung des Durchsatzes von Strahlschnitt- oder Sichtbarkeits-Abfragen offengelegt, die von einem Hardwarebeschleuniger für die Strahlverfolgung durchgeführt werden. Der Durchsatz wird beispielsweise dadurch verbessert, dass allokierte Ressourcen freigegeben werden, bevor der Hardware-Beschleuniger Ergebnisse der Strahlsichtbarkeitsabfrage meldet. Die allokierten Ressourcen werden freigegeben, wenn die Ergebnisse der Strahlsichtbarkeitsabfrage in einem komprimierten Format außerhalb der zugewiesenen Ressourcen gespeichert werden können. Wenn die Ergebnisse der Strahlsichtbarkeitsabfrage gemeldet werden, werden die Ergebnisse auf der Grundlage der im komprimierten Format gespeicherten Ergebnisse rekonstruiert. Die Speicherung im komprimierten Format kann für Strahlsichtbarkeitsabfragen verwendet werden, die keine Schnittpunkte zurückgeben oder sich bei einer Beliebiger-Treffer-Strahlsichtbarkeits-Abfrage beenden. Eine oder mehrere einzelne Komponenten der allokierten Ressourcen können auch unabhängig voneinander auf der Grundlage der Art der zurückzugebenden Daten und/oder von Ergebnissen der Strahlsichtbarkeitsabfrage freigegeben werden.

Description

• GEBIET
• Die vorliegende Technologie bezieht sich auf Computergrafik und insbesondere auf Strahlverfolger bzw. Raytracer. Insbesondere bezieht sich die Technologie auf Hardware-Beschleunigung von Computergrafik-Verarbeitung, einschließlich, aber nicht beschränkt auf, Strahlverfolgung. Die beispielhafte, nicht beschränkende Technologie hierin bezieht sich auch auf eine hardwarebasierte Strahlschnittpunktprüfung, die effizient Strahlschnittpunkte bestimmt, z. B. für die Echtzeit-Strahlverfolgung. Noch spezieller bezieht sich das hierin beschriebene, nichtbeschränkende Technologiebeispiel auf Datenkompression und/oder frühzeitige Freigabe von zugewiesenen Strahlverfolgungs- bzw. Raytracing-HardwareRessourcen.
• HINTERGRUND
• Die Echtzeit-Computergrafik hat in den letzten 30 Jahren enorme Fortschritte gemacht. Mit der Entwicklung leistungsfähiger Grafikprozessoren bzw. Grafikverarbeitungseinheiten (GPUs) in den 1980er Jahren, die 3D-Hardware-Grafikpipelines bereitstellen, wurde es möglich, 3D-Grafikanzeigen auf der Grundlage von Polygonprimitiven mit Texturzuordnung in Echtzeit im Ansprechen auf Benutzereingaben zu erstellen. Solche Echtzeit-Grafikprozessoren basierten auf einer Technologie, die als Abtast-Konvertierungs- bzw. Scan-Conversion-Rasterisierung bezeichnet wird, welche ein Mittel zum Bestimmen der Sichtbarkeit ausgehend von einem einzigen Punkt oder einer einzigen Perspektive ist. Unter Verwendung dieses Ansatzes werden dreidimensionale Objekte aus Oberflächen modelliert, die aus geometrischen Primitiven, in der Regel Polygonen wie beispielsweise Dreiecken, aufgebaut sind. Der Scan-Conversion-Prozess erstellt und projiziert Eckpunkte bzw. Vertices der Primitiv-Polygone 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 wurde seit langem verwendet, um zu bestimmen, wie jede Polygonfläche schattiert und mit Texturen versehen werden sollte, und um die schattierten und mit Texturen versehenen Polygonflächen für die Anzeige zu rastern. Typische dreidimensionale Szenen sind oft aus Millionen von Polygonen aufgebaut. Schnelle moderne GPU-Hardware kann viele Millionen von Grafikprimitiven für jedes Einzelbild der Anzeige bzw. jeden Anzeige-Frame (alle 1/30 oder 1/60 Sekunde) in Echtzeit im Ansprechen auf eine Benutzereingabe effizient verarbeiten. Die resultierenden grafischen Anzeigen wurden in einer Vielzahl von grafischen Echtzeit-Benutzeroberflächen verwendet, einschließlich von, aber nicht beschränkt auf, erweiterter Realität, virtueller Realität, Videospielen und medizinischer Bildgebung. Bislang war solche interaktive Grafikhardware jedoch nicht in der Lage, Reflexionen und Schatten genau zu modellieren und darzustellen.
• Es gibt eine weitere Grafiktechnologie, die physikalisch realistische Sichtbarkeitsbestimmungen für Reflexion und Schattenwurf durchführt. Sie wird als „Raytracing“ bzw. Strahlverfolgung bezeichnet. Bei der Strahlverfolgung wird ein Strahl in eine Szene geworfen und bestimmt, ob und wo dieser Strahl die Geometrie der Szene schneidet. Diese grundlegende Sichtbarkeitsprüfung durch Strahlverfolgung ist die Basis für eine Vielzahl von Rendering-Algorithmen und Techniken in der Computergrafik. Die Strahlverfolgung wurde Ende der 1960er Jahre entwickelt und in den 1980er Jahren weiter verbessert. Siehe z.B. Appel, „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, S. 143-150). Seitdem wurde Strahlverfolgung auch in Nicht-Echtzeit-Grafikanwendungen wie beispielsweise Design und Filmherstellung verwendet. Jeder, der „Finding Dory“ (2016) oder andere Pixar-Animationsfilme gesehen hat, hat das Ergebnis des Strahlverfolgungs-Ansatzes für Computergrafiken gesehen - nämlich realistische Schatten und Reflexionen. Siehe z.B. Hery et al., „Towards Bidirectional Path Tracing at Pixar" (2016).
• Allgemein ist Raytracing bzw. Strahlverfolgung ein Rendering-Verfahren, bei dem Strahlen verwendet werden, um die Sichtbarkeit verschiedener Elemente in der Szene zu bestimmen. Strahlverfolgung ist ein Primitiv und wird in einer Vielzahl von Rendering-Algorithmen verwendet, einschließlich z.B. Pfadverfolgung und Metropolis-Lichttransport. In einem Beispielalgorithmus simuliert Strahlverfolgung die Physik des Lichts durch Modellieren des Lichttransports durch die Szene, um alle globalen Effekte (einschließlich z.B. Reflexionen von glänzenden Oberflächen) unter Verwendung der Strahlenoptik zu berechnen. Bei solchen Anwendungen der Strahlverfolgung kann versucht werden, jeden einzelnen von vielen Hunderten oder Tausenden von Lichtstrahlen zu verfolgen, wenn sie sich von möglicherweise mehreren Lichtquellen ausgehend durch die dreidimensionale Szene bis zum Blickpunkt bewegen. Häufig werden solche Strahlen relativ zum Auge durch die Szene verfolgt und gegen eine Datenbank der gesamten Geometrie in der Szene getestet. Die Strahlen können vorwärts von den 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 von der virtuellen Kamera ausgehen und am Auge beginnen, eine klare bzw. freie Sichtlinie haben. Das Testen bestimmt entweder den nächstgelegenen Schnittpunkt (um zu bestimmen, was vom Auge aus sichtbar ist) oder Strahlen werden von der Oberfläche eines Objekts in Richtung einer Lichtquelle verfolgt, um zu bestimmen, ob es etwas Dazwischenliegendes gibt, das die Übertragung von Licht zu diesem Punkt im Raum blockieren würde. Weil die Strahlen den Lichtstrahlen in der Realität ähneln, ermöglichen sie eine Reihe von realistischen Effekten, die mit der rasterbasierten Echtzeit-3D-Grafiktechnologie, die in den letzten dreißig Jahren implementiert wurde, nicht möglich sind. Weil jeder Lichtstrahl von jeder Lichtquelle innerhalb der Szene ausgewertet wird, während er jedes Objekt in der Szene durchläuft, können die resultierenden Bilder so aussehen, als wären sie in der Realität fotografiert worden. Demgemäß werden diese Strahlverfolgungs-Verfahren seit langem in professionellen Grafikanwendungen wie beispielsweise Design und Film verwendet, wo sie sich gegenüber dem rasterbasierten Rendering durchgesetzt haben.
• Strahlverfolgung kann verwendet werden, um zu bestimmen, ob irgendetwas entlang eines Strahls sichtbar ist (zum Beispiel, Testen auf Verdeckungen zwischen einem schattierten Punkt auf einem geometrischen Primitiv und einem Punkt auf einer Lichtquelle) und kann auch zur Auswertung von Reflexionen verwendet werden (welches beispielsweise die Durchführung einer Traversierung bzw. eines Durchlaufens involvieren kann, um die nächstgelegene sichtbare Oberfläche entlang einer Sichtlinie zu bestimmen, so dass Software, die auf einem Streaming-Prozessor läuft, eine Materialschattierungsfunktion auswerten kann, die dem getroffenen Objekt entspricht - was wiederum einen oder mehrere zusätzliche Strahlen in die Szene entsprechend den Materialeigenschaften des geschnittenen Objekts auslösen kann), um das Licht zu bestimmen, das entlang des Strahls zurück zum Auge gelangt. Bei der klassischen Strahlverfolgung nach Whitted werden Strahlen vom Standpunkt aus durch das Pixelraster in die Szene geschossen, aber es sind auch andere Pfadverläufe möglich. In der Regel wird für jeden Strahl das nächstgelegene Objekt gefunden. Dieser Schnitt bzw. Schnittpunkt kann dann als beleuchtet oder im Schatten liegend bestimmt werden, indem ein Strahl von ihm aus zu jeder Lichtquelle in der Szene geschossen wird und bestimmt wird, ob sich irgendwelche Objekte dazwischen befinden. Undurchsichtige bzw. opake Objekte blockieren das Licht, während transparente Objekte es abschwächen. Von einem Schnittpunkt aus können weitere Strahlen erzeugt werden. Wenn die sich schneidende Oberfläche beispielsweise 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 geprüft wird. Dieser Reflexionsprozess wird rekursiv wiederholt, bis eine Rekursionsgrenze erreicht ist oder der potenzielle Beitrag nachfolgender Abpraller unter einen Schwellenwert fällt. Für transparente, feste Objekte können auch Strahlen in der Brechungsrichtung erzeugt und ebenfalls rekursiv ausgewertet werden. Die Strahlverfolgungs-Technologie ermöglicht es folglich einem Grafiksystem, physikalisch korrekte Reflexionen und Schatten zu entwickeln, die nicht den Beschränkungen und Artefakten von Scan-Conversion-Verfahren unterliegen.
• Strahlverfolgung wurde zusammen mit oder als Alternative zu Rasterung und Z-Buffering für das Sampling bzw. Abtasten von Szenengeometrie verwendet. Es kann auch als eine Alternative zu (oder in Kombination mit) UmgebungsFIG. bzw. Environment Mapping und Schattentexturierung verwendet werden, um realistischere Reflexions-, Brechungs- und Schatteneffekte zu erzeugen, als sie mit Texturierungstechniken oder anderen Raster-„Hacks“ erreicht werden können. Strahlverfolgung kann auch als das grundlegende Primitiv zur genauen Simulation des Lichttransports in physikalisch basierten Rendering-Algorithmen wie beispielsweise Path Tracing, Photon Mapping, Metropolis-Lichttransport und anderen Lichttransport-Algorithmen verwendet werden.
• Die größte Herausforderung bei der Strahlverfolgung war im Allgemeinen die Geschwindigkeit. Bei der Strahlverfolgung muss das Grafiksystem für jedes Einzelbild bzw. jeden Frame jeden von vielen Millionen Lichtstrahlen berechnen und analysieren, die auf jede Oberfläche der Szene auftreffen (und potenziell von ihr reflektiert werden). In der Vergangenheit war es unmöglich, diese enorme Berechnungskomplexität in Echtzeit durchzuführen.
• Ein Grund dafür, dass moderne GPU-3D-Grafikpipelines schattierte, mit Texturen versehene Oberflächen so schnell rendern können, ist die effiziente Nutzung der Kohärenz. Bei herkömmlicher Abtastkonvertierung bzw. Scan Conversion wird davon ausgegangen, dass alles durch ein gemeinsames Fenster in einer gemeinsamen Bildebene betrachtet und auf einen einzigen Aussichtspunkt projiziert wird. Jedes Dreieck oder andere Primitiv wird durch die Grafikpipeline geschickt und deckt eine bestimmte Anzahl von Pixeln ab. Alle verwandten Berechnungen können für alle Pixel, die aus diesem Dreieck gerendert werden, gemeinsam durchgeführt werden. Rechteckige Pixelkacheln, die kohärenten, durch das Fenster verlaufenden Sichtlinien entsprechen, können somit Gruppen von Threads entsprechen, die schrittverriegelt bzw. im Gleichschritt in demselben Streaming-Prozessor laufen. Bei allen Pixeln, die zwischen die Kanten des Dreiecks fallen, wird davon ausgegangen, dass es sich um dasselbe Material handelt, auf dem derselbe Shader läuft und das benachbarte Gruppen von Texeln aus denselben Texturen abruft. Demgegenüber können Strahlen bei der Strahlverfolgung an einem gemeinsamen Punkt (einer Lichtquelle oder einer virtuellen Kameralinse) beginnen oder enden, aber während sie sich durch die Szene ausbreiten und mit verschiedenen Materialien interagieren, divergieren sie schnell. Zum Beispiel führt jeder Strahl eine Suche nach dem nächstgelegenen Objekt durch. Die Ergebnisse können zwar in gewissem Umfang zwischengespeichert und gemeinsam genutzt werden, aber da jeder Strahl potenziell auf verschiedene Objekte treffen kann, ist die Art von Kohärenz, die GPUs traditionell in Verbindung mit texturierten, schattierten Dreiecken zum Vorteil nutzten, nicht gegeben (z.B. gibt es keinen gemeinsamen Aussichtspunkt, kein gemeinsames Fenster und keine gemeinsame Bildebene für Strahlverfolgung). Dies macht Strahlverfolgung rechnerisch viel anspruchsvoller als andere grafische Ansätze - und daher viel schwieriger auf interaktiver Basis durchzuführen.
• Im Jahr 2010 nutzte NVIDIA den hohen Grad an Parallelität von NVIDIA-GPUs und anderen hochparallelen Architekturen zum Vorteil, um die OptiX™ Raytracing-Engine zu entwickeln. 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 der APIs (Application Programming Interfaces) bestand einer der Fortschritte von OptiX™ in der Verbesserung der Beschleunigungsdatenstrukturen, die für die Suche nach einem Schnittpunkt zwischen einem Strahl und der Szenengeometrie verwendet werden. Solche Beschleunigungsdatenstrukturen sind in der Regel Raum- oder Objekthierarchien, die vom Strahlverfolgungs-Traversierungs-Algorithmus verwendet werden, um effizient nach Primitiven zu suchen, die potenziell einen bestimmten Strahl schneiden. OptiX™ bietet eine Reihe von verschiedenen Beschleunigungsstrukturtypen, aus denen die Anwendung wählen kann. Jede Beschleunigungsstruktur im Knotengraphen kann von einem anderen Typ sein, so dass Kombinationen von hochwertigen statischen Strukturen mit dynamisch aktualisierten Strukturen möglich sind.
• Die programmierbare OptiX™-Raytracing-Pipeline brachte erhebliche Fortschritte, war aber im Allgemeinen immer noch nicht in der Lage, auf relativ preiswerten Computerplattformen für komplexe 3D-Szenen interaktive Reaktionen auf Benutzereingaben in Echtzeit zu liefern. Seitdem hat NVIDIA Hardware-Beschleunigungsfunktionen für Raytracing entwickelt. Siehe z.B. US 9,582,607 ; US 9,569,559 ; US 20160070820 ; US 20160070767 und die anderen vorstehend genannten US-Patente und Patentanmeldungen.
• Eine grundlegende Aufgabe der meisten Raytracer besteht darin, einen Strahl gegen alle Primitive (in einer Ausführungsform üblicherweise 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 unbedingt nächstgelegenen) Treffer zu melden bzw. zu berichten. Der naive Algorithmus wäre eine O(n)-Brute-Force-Suche. Aufgrund der großen Anzahl von Primitiven in einer 3D-Szene beliebiger Komplexität ist es jedoch für einen Raytracer in der Regel nicht effizient oder machbar, jedes geometrische Primitiv in der Szene auf einen Schnittpunkt mit einem bestimmten Strahl zu testen.
• Durch Vorverarbeiten der Szenengeometrie und Aufbauen einer geeigneten Beschleunigungsdatenstruktur im Voraus ist es jedoch möglich, die durchschnittliche Komplexität auf O(log n) zu reduzieren. Beschleunigungsdatenstrukturen, wie z.B. eine Begrenzungsvolumen- bzw. Bounding-Volume-Hierarchie oder BVH, ermöglichen eine schnelle Entscheidung darüber, welche Begrenzungsvolumen ignoriert werden können, welche Begrenzungsvolumen geschnittene geometrische Primitive enthalten können und welche geschnittenen geometrischen Primitive für die Visualisierung wichtig sind und welche nicht. Die Verwendung einfacher Volumen, wie z.B. Boxen bzw. Kästen, zur Aufnahme komplexerer Objekte führt zu einer höheren Rechen- und Speichereffizienz, die dabei helfen, die Strahlverfolgung in Echtzeit durchzuführen.
• 1A-1C veranschaulichen das Testen von Strahlverfolgungsschnitten im Kontext eines Begrenzungsvolumens mit einem geometrischem Netz 20. 1A zeigt einen Strahl 102 in einem virtuellen Raum mit Begrenzungsvolumen 10 und 15. Um zu bestimmen, ob der Strahl 102 die Geometrie im Netz 20 schneidet, könnte jedes geometrische Primitiv (z.B. Dreieck) direkt gegen den Strahl 102 getestet werden. Um den Prozess jedoch zu beschleunigen (da das Objekt viele Tausende geometrischer Primitive enthalten könnte), wird der Strahl 102 zunächst gegen die Begrenzungsvolumen 10 und 15 getestet. Falls der Strahl 102 ein Begrenzungsvolumen nicht schneidet, schneidet er auch keine Geometrie innerhalb des Begrenzungsvolumens, und kann die gesamte Geometrie innerhalb des Begrenzungsvolumens für die Zwecke dieses Strahls ignoriert werden. Weil in 1A der Strahl 102 das Begrenzungsvolumen 10 verfehlt, braucht jede Geometrie des Netzes 20 innerhalb dieses Begrenzungsvolumens nicht auf Schnittpunkte geprüft zu werden. Während das Begrenzungsvolumen 15 von dem Strahl 102 geschnitten wird, enthält das Begrenzungsvolumen 15 keinerlei Geometrie, so dass keine weitere Testung erforderlich ist.
• Falls andererseits ein Strahl wie beispielsweise der in 1B gezeigte Strahl 104 ein Begrenzungsvolumen 10 schneidet, das eine Geometrie enthält, dann kann der Strahl die Geometrie innerhalb des Begrenzungsvolumens schneiden oder auch nicht, so dass weitere Tests an der Geometrie selbst durchgeführt werden müssen, um mögliche Schnittpunkte zu finden. Weil die Strahlen 104, 306 in den 1 B und 1C ein Begrenzungsvolumen 10 schneiden, das Geometrie enthält, müssen weitere Tests durchgeführt werden, um zu bestimmen, ob (und welche) der Primitive innerhalb des Begrenzungsvolumens geschnitten werden. In 1 B würde ein weiteres Testen der Schnittpunkte mit den Primitiven darauf hindeuten, dass der Strahl 104 zwar durch das Begrenzungsvolumen 10 verläuft, aber keine der Geometrien schneidet, die das Begrenzungsvolumen einschließt (alternativ könnte, wie vorstehend erwähnt, das Begrenzungsvolumen 10 volumetrisch weiter unterteilt werden, so dass eine Begrenzungsvolumen-Schnittpunkt-Testung verwendet werden könnte, um zu bestimmen, dass der Strahl keinerlei Geometrie schneidet, oder genauer gesagt, welche geometrischen Primitive der Strahl möglicherweise schneidet).
• 1C zeigt eine Situation, in der der Strahl das Begrenzungsvolumen 10 schneidet und eine Geometrie enthält, die der Strahl 306 schneidet. Um die Strahlverfolgung in Echtzeit durchzuführen, testet ein Schnittpunkttester jedes geometrische Primitiv innerhalb des geschnittenen Begrenzungsvolumens 10, um zu bestimmen, ob der Strahl dieses geometrische Primitiv schneidet.
• Die von modernen Raytracern am häufigsten verwendete Beschleunigungsdatenstruktur ist eine Begrenzungsvolumen- bzw. Bounding-Volume-Hierarchie (BVH), die verschachtelte achsenausgerichtete Begrenzungsrahmen bzw. Bounding Boxes (AABBs; axis-aligned bounding boxes) umfasst. Die Blattknoten der BVH enthalten die Primitive (z.B. Dreiecke), die auf Schnittpunkte zu prüfen bzw. testen sind. Die BVH wird meist durch einen Graphen oder eine Baumstruktur dargestellt. Bei der Strahlverfolgung bzw. beim Raytracing ist die Zeit für die Suche nach dem nächstgelegenen Schnittpunkt (oder für Schatten, jedes) für einen Strahl typischerweise O(log n) für n Objekte, wenn eine solche Beschleunigungsdatenstruktur verwendet wird. Beispielsweise haben AABB Begrenzungsvolumen-Hierarchien (BVHs) der üblicherweise für moderne Beschleunigungsdatenstrukturen für Strahlverfolgung verwendeten Art ein O(log n)- Suchverhalten.
• Die BVH-Beschleunigungsdatenstruktur repräsentiert und/oder referenziert das 3D-Modell eines Objekts oder einer Szene auf eine Art und Weise, 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 zurückzuweisen. Die BVH-Datenstruktur repräsentiert eine Szene oder ein Objekt mit einem Begrenzungsvolumen und unterteilt das Begrenzungsvolumen in immer kleinere Begrenzungsvolumen, die in Blattknoten enden, die geometrische Primitive enthalten. Die Begrenzungsvolumen sind hierarchisch, d.h. die oberste Ebene umschließt die darunter liegende Ebene, diese Ebene umschließt wiederum die nächsttiefere Ebene usw. In einer Ausführungsform können Blattknoten andere Blattknoten in der Begrenzungsvolumen-Hierarchie potenziell überlappen.
• Die RTX-Plattform von NVIDIA beinhaltet eine Strahlverfolgungs-Technologie, die Inhaltserstellern und Spieleentwicklern Rendering in Echtzeit und in Kinoqualität ermöglicht. Siehe https://developer.nvidia.com/rtx/raytracing. In vielen oder den meisten Implementierungen, einschließlich NVIDIA RT Cores, verwenden die Begrenzungsvolumen, wie in 1A-1C gezeigt, achsen-ausgerichtete Begrenzungsrahmen bzw. Bounding Boxes („AABBs“), die kompakt gespeichert und einfach auf Strahlschnittpunkte getestet werden können. Falls ein Strahl den Begrenzungsrahmen der Geometrie schneidet, wird auch die darunter liegende Geometrie geprüft. Falls jedoch ein Strahl den Begrenzungsrahmen der Geometrie nicht schneidet, braucht die darunter liegende Geometrie nicht geprüft zu werden. Wie 1A-1C zeigen, wird eine Hierarchie von AABBs erzeugt, um den Culling- bzw. Ausleseeffekt eines einzelnen AABB-Begrenzungsrahmen-Tests zu erhöhen. Dies ermöglicht ein effizientes Traversieren und eine schnelle Reduzierung auf die interessierende Geometrie.
• In Anbetracht des großen Potenzials zur Verbesserung von Echtzeit-Raytracing-Grafikverarbeitungssystemen für das Rendern qualitativ hochwertiger Bilder durch Erhöhung der Verarbeitungsgeschwindigkeit oder die Möglichkeit, die Komplexität der Szene durch Verwendung einer größeren Anzahl von Primitiven zu erhöhen, sind weitere Arbeiten möglich und wünschenswert. Insbesondere wäre es sehr wünschenswert, die Testung auf Strahlschnittpunkte durch Erhöhen des Durchsatzes von Strahlschnittpunktanfragen in Raytracing-Hardware zu beschleunigen.
• Figurenliste
• 1A-1C zeigen beispielhafte vereinfachte Strahlverfolgungstests, um zu bestimmen, ob der Strahl durch ein Begrenzungsvolumen mit Geometrie verläuft und ob der Strahl Geometrie innerhalb des Begrenzungsvolumens schneidet.
• 2 zeigt einen Beispielprozess zum Aufbauen einer geeigneten Begrenzungsvolumen-Hierarchie.
• 3A und 3B zeigen beispielhafte Repräsentationen von Begrenzungsvolumen-hierarchien.
• 4 veranschaulicht ein Beispiel für ein nicht beschränkendes Strahlverfolgungs-Grafiksystem.
• 5 ist ein Ablaufdiagramm einer beispielhaften, nicht beschränkenden Strahlverfolgungs-Grafikpipeline.
• 6 ist ein Ablaufdiagramm von beispielhaften, nicht beschränkenden hardwarebasierten Strahlverfolgungs-Operationen.
• 7 zeigt ein vereinfachtes, nicht beschränkendes Beispiel für einen Traversierungs-Coprozessor, der eine Baum-Traversierungs-Einheit (TTU; tree traversal unit) umfasst.
• 8A und 8B zeigen die Ergebnisausgabe einer TTU für eine Gruppe von Threads, die für eine gesamte Gruppe und in Untergruppen an die Multiprozessorregister zurückgegeben wird, gemäß einigen beispielhaften Ausführungsformen.
• 9 zeigt ein System mit einer Schnittstelle zwischen Multiprozessor und TTU, gemäß einer beispielhaften Ausführungsform.
• 10A-10D zeigen Beispiele von Daten, die an den Multiprozessor zurückgegeben werden können, gemäß einigen beispielhaften Ausführungsformen.
• 11 zeigt ein Beispiel von Strahlinformationen, die von dem Multiprozessor für einen Thread bereitgestellt werden können.
• 12A zeigt ein Beispiel von Daten, die von einer Schnittpunktverwaltungseinheit (Intersect Management Unit) bereitgestellt werden können, um einen Treffer anzuzeigen und um Schnittpunktinformationen bereitzustellen.
• 12B zeigt ein Beispiel von Daten, die von einer Schnittstelle erzeugt werden können, um einen Treffer anzuzeigen, ohne jedoch Einzelheiten über den Treffer zu liefern.
• 12C zeigt ein Beispiel von Daten, die von einer Schnittpunktverwaltungseinheit bereitgestellt werden können, um einen Knotentreffer anzuzeigen.
• 12D zeigt ein Beispiel von Daten, die von einer Schnittpunktverwaltungseinheit bereitgestellt werden können, um einen Treffer im Dreieckbereich anzuzeigen.
• 12E zeigt ein Beispiel von Daten, die von einer Schnittpunktverwaltungseinheit bereitgestellt werden können, um einen Treffer im Elementbereich anzuzeigen.
• 12F zeigt ein Beispiel von Daten, die von einer Schnittpunktverwaltungseinheit bereitgestellt werden können, um einen Instanzknoten-Treffer anzuzeigen.
• 12G zeigt ein Beispiel von Daten, die von einer Schnittpunktverwaltungseinheit bereitgestellt werden können, um einen Fehler bei der Durchführung des Strahlenschnitttests anzuzeigen.
• 12H zeigt ein Beispiel von Daten, die von einer Schnittstelle erzeugt werden können, um ein Verfehlen anzuzeigen.
• 13A zeigt eine Tabelle von Daten, die von der Schnittstelle nachverfolgt werden können, gemäß einer beispielhaften Ausführungsform.
• 13B zeigt eine Zuordnung bzw. ein Mapping zwischen TTU-Slots und Slots der Strahlenverwaltungseinheit, der Schnittpunktverwaltungseinheit und der Stackverwaltungseinheit, gemäß einer beispielhaften Ausführungsform.
• 14 veranschaulicht ein Ablaufdiagramm eines beispielhaften, nicht beschränkenden Verfahrens zur Bestimmung von Schnittpunkten bzw. Überschneidungen zwischen einer Datenstruktur und Primitiven.
• 15A und 15B veranschaulichen detailliertere Raytracing-Pipelines.
• 16 ist ein Ablaufdiagramm eines Beispielprozesses zur Erzeugung eines Bilds.
• DETAILLIERTE BESCHREIBUNG NICHT-BESCHRÄNKENDER AUSFÜHRUNGSFORMEN
• Um eine Echtzeit-Strahlverfolgung zu erreichen, ist Strahlverfolgungs- bzw. Raytracing-Hardware so konzipiert, dass sie sehr effizient und schnell bei der Durchführung von Strahl-Schnittpunkt-Tests ist, d. h. bei einem Testen auf Strahl-Begrenzungsvolumen und/oder Strahl-Primitiv-Schnittpunkte. Um dies zu erreichen, empfängt die Raytracing-Hardware eine Gruppe von Abfragen für Strahl-Schnittpunkt-Tests von einem Prozessor, verarbeitet die Abfragen und gibt die Ergebnisse an den Prozessor zurück. Weil die Abfragen in der Gruppe unterschiedlich lange dauern können, bis sie abgeschlossen sind, werden die Ergebnisse abgeschlossener Abfragen gespeichert, bis die anderen Abfragen in der Gruppe verarbeitet und die Ergebnisse für die Gruppe an den Prozessor zurückgegeben sind. Der Durchsatz der Raytracing-Hardware wird durch den Verbrauch von Ressourcen begrenzt, die für die Speicherung der Abfrageergebnisse bis zu deren Meldung verwendet werden. Um den Durchsatz der Abfragen weiter zu erhöhen, könnte Speicher für die Speicherung der Ergebnisse bis zu ihrer Meldung vergrößert werden. Speicher ist jedoch kostspielig und eine begrenzte Ressource auf einem Chip.
• Die beispielhafte, nicht beschränkende Technologie bietet eine bessere Ressourcennutzung und Leistung für Raytracing-Traversierungs-Arbeitslasten. Beispielhafte Ausführungsformen nutzen eine erhebliche Speicherkomprimierung auf der Grundlage von Strahltraversierungsergebnissen. Durch die Speicherkomprimierung können die Hardwareressourcen, die normalerweise die Ergebnisdaten speichern würden, bis die Ergebnisse an einen Multiprozessor zurückgegeben werden, frühzeitig freigegeben werden. Durch die frühzeitige Freigabe der Ressourcen können diese anderen Abfragen zugewiesen werden, die auf ihre Bearbeitung warten.
• Die beispielhafte, nicht beschränkende Technologie stellt hardwarebasierte Fähigkeiten bereit, die Strahl-Schnittpunkt-Testungen effizient beschleunigen.
• Erstellen einer Begrenzungsvolumen-Hierarchie für effizientere Schnittpunkttestungen
• Wie vorstehend erklärt, wird die Strahl-Objekt-Schnittpunkt-Testung durch die Verwendung einer Beschleunigungsdatenstruktur effizienter gestaltet. Wie vorstehend beschrieben, umfasst eine Beschleunigungsdatenstruktur eine Hierarchie von Begrenzungsvolumen (Bounding Volume Hierarchy oder BVH), die rekursiv immer kleinere Unterteilungen von Begrenzungsvolumen kapselt. Das größte volumetrische Begrenzungsvolumen kann als ein „Wurzelknoten“ bezeichnet werden. Die kleinsten Unterteilungen einer solchen Hierarchie von Begrenzungsvolumen („Blattknoten“) enthalten Elemente. Bei den Elementen kann es sich um Primitive (z.B. Polygone wie Dreiecke) handeln, die Oberflächen des Objekts definieren. Ein Element könnte aber auch eine Kugel sein, die eine ganz neue Ebene der Welt enthält, die als ein Element existiert, weil sie nicht zu der BVH hinzugefügt wurde (man denke an das Halsband der Katze aus „Men in Black“, das in sich eine ganze Miniaturgalaxie enthielt). Falls das Element Primitive umfasst, testet bzw. prüft der Traversierungs-Coprozessor bei Erreichen eines sich schneidenden Blattknotens die Strahlen gegen die den Blattknoten zugeordneten Primitive, um zu bestimmen, welche Objektflächen die Strahlen schneiden und welche Objektflächen entlang des Strahls sichtbar sind.
• Das Erstellen einer BVH kann in zwei Teilen erfolgen: statisch und dynamisch. In vielen Anwendungen wird eine komplexe Szene vorverarbeitet und wird die BVH auf der Grundlage einer statischen Geometrie der Szene erstellt. Dann wird unter Verwendung einer interaktiven Grafikerzeugung, einschließlich dynamisch erzeugter und manipulierter beweglicher Objekte, ein weiterer Teil der BVH (oder eine oder mehrere zusätzliche, verknüpfte BVH(s)) in Echtzeit (z.B. in jedem Frame) von einem Treiber oder einer anderen Software erstellt, die auf dem interaktiven Echtzeit-Grafiksystem läuft. Die BVH-Erstellung muss nicht hardwarebeschleunigt sein (obwohl sie es in einigen nicht beschränkenden Ausführungsformen sein kann), sondern kann unter Verwendung hochoptimierter Softwareroutinen implementiert werden, die auf SMs 132 und/oder der CPU 120 und/oder anderen Entwicklungssystemen, z.B. während der Entwicklung einer Anwendung, laufen.
• Die erste Phase des Aufbaus bzw. der Erstellung der BVH-Beschleunigungsstruktur erfasst die Begrenzungsrahmen der referenzierten Geometrie (2, 204). Dies wird erreicht, indem für jedes geometrische Primitiv in einem Objekt eine Begrenzungsrahmen-Prozedur ausgeführt wird, die einen konservativ achsenausgerichteten Begrenzungsrahmen (AABB) für ihr Eingangsprimitiv zurückgibt. Die Ausrichtung von Begrenzungsrahmen an den Achsen der relevanten Koordinatensysteme für die Geometrie sorgt für eine höhere Effizienz geometrischer Echtzeit-Operationen wie beispielsweise Schnittpunkt-Testungen und Koordinatentransformationen, beispielsweise im Vergleich zu orientierten Begrenzungsrahmen bzw. Bounding Boxes (OBBs), Begrenzungskugeln bzw. Bounding Spheres oder anderen Ansätzen. Der Fachmann wird jedoch verstehen, dass die beispielhaften, nicht beschränkenden Ansätze hierin auch auf teurere Begrenzungskonstrukte wie beispielsweise OBBs, Begrenzungskugeln und andere Begrenzungsvolumentechnologien angewendet werden können.
• Bereits unterteilte Begrenzungsvolumen, die mindestens einen Teil der Geometrie in einer Szene enthalten, können noch weiter rekursiv unterteilt werden - wie das Auftauchen einer Aufeinanderfolge immer kleinerer Katzen aus den Hüten in Dr. Seuss' The Cat In The Hat Comes Back (1958). Die Anzahl und die Konfigurationen rekursiver Unterteilungen werden von der Komplexität und der Konfiguration des modellierten 3D-Objekts sowie von anderen Faktoren wie beispielsweise der gewünschten Auflösung, dem Abstand des Objekts vom Standpunkt usw. abhängen. Ein beispielhaftes Unterteilungsschema ist eine so genannte 8-adische bzw. stufige Unterteilung oder „Octree“, bei der jedes Volumen in acht kleinere Volumen einheitlicher Größe unterteilt wird, aber es sind auch viele andere räumliche Hierarchien und Unterteilungsschemata bekannt, wie z.B. ein binärer Baum, ein 4-adischer bzw. stufiger Baum, ein k-d-Baum, ein Binary Space Partitioning (BSP)-Baum und ein Bounding Volume Hierarchy (BVH)-Baum. Siehe z.B. USP 9,582,607 .
• Auf einer bestimmten Unterteilungsebene (die für verschiedene Teile der BVH unterschiedlich sein kann) trifft der BVH-Erstellungsprozess auf Geometrie, die das zu modellierende gekapselte Objekt ausmacht. In Analogie zu einem Baum sind die aufeinanderfolgenden volumetrischen Unterteilungen der Stamm, die Äste, die Zweige und das Reis, und wird die Geometrie schließlich an den äußersten Spitzen des Baumes, nämlich den Blättern, sichtbar. An diesem Punkt führt der BVH-Erstellungsprozess für beispielhafte, nicht beschränkende Ausführungsformen hierin in diesem Stadium eine Optimierung durch, um unter Verwendung heuristischer oder anderer analytischer Techniken (die in einigen Ausführungsformen künstliche Intelligenz und/oder neuronale Netzwerke beinhalten können) diejenigen Blattknoten auszumachen, die in Bezug auf die in ihnen enthaltene Geometrie schlecht passen (2, 206).
• Dieser Prozess wird solange fortgesetzt, bis alle Begrenzungsvolumen, die Geometrie enthalten, ausreichend unterteilt worden sind, um eine vernünftige Anzahl von geometrischen Primitiven pro Begrenzungsrahmen bereitzustellen (2, 210). Der Echtzeit-Raytracer bzw. Strahlverfolger, der die BVH verwendet, wird Strahl-Primitiv-Schnittpunkte bestimmen, indem er die räumlichen xyz-Koordinaten der Scheitel- bzw. Eckpunkte bzw. Vertices jedes Primitivs mit den xyz-Koordinaten des Strahls vergleicht, um zu bestimmen, ob der Strahl und die Oberfläche, die das Primitiv definiert, denselben Raum einnehmen. Der Strahl-Primitiv-Schnittpunkt-Test kann rechenintensiv sein, weil es viele Dreiecke zu prüfen gibt. In vielen Fällen kann es effizienter sein, eine volumetrische weiter zu unterteilen und dadurch die Anzahl von Primitiven in jedem „Blattknoten“ auf etwa 16 oder weniger zu begrenzen.
• Der daraus resultierende komprimierte Baum, der komprimierte Treelets („Complets“) umfasst, wird zur späteren Verwendung durch die Grafikverarbeitungshardware/- software z.B. während der Echtzeit-Grafikverarbeitung, die Echtzeit- Strahlverfolgung beinhaltet, in eine Datenstruktur im Speicher geschrieben (2, 212).
• 3A und 3B zeigen ein rekursiv unterteiltes Begrenzungsvolumen einer 3D-Szene (3A) und eine entsprechende Baumdatenstruktur (3B), auf die der Raytracer zugreifen und die für hardwarebeschleunigte Operationen verwendet werden kann. Die Baumdatenstruktur kann im Speicher abgelegt und bei Bedarf auf der Grundlage von Abfragen abgerufen werden.
• Die Aufteilung der Begrenzungsvolumen kann in einer hierarchischen Baumdatenstruktur dargestellt werden, wobei das große Begrenzungsvolumen durch einen übergeordneten Knoten bzw. Elternknoten des Baums und die kleineren Begrenzungsvolumen durch untergeordnete Knoten bzw. Kindknoten des Baums, die in dem übergeordneten Knoten enthalten sind, repräsentiert werden. Die kleinsten Begrenzungsvolumen werden als Blattknoten in der Baumstruktur repräsentiert und identifizieren ein oder mehrere geometrische Primitive, die innerhalb dieser kleinsten Begrenzungsvolumen enthalten sind.
• Die Baumdatenstruktur beinhaltet eine Vielzahl von Knoten, die in einer Hierarchie angeordnet sind. Die Wurzelknoten N1 der Baumstruktur entsprechen einem Begrenzungsvolumen N1, das alle der Primitive O1-O8 einschließt. Der Wurzelknoten N1 kann die Vertices des Begrenzungsvolumens N1 und Unterknoten des Wurzelknotens identifizieren.
• In 3A ist das Begrenzungsvolumen N1 in Begrenzungsvolumen N2 und N3 unterteilt. Kindknoten N2 und N3 der Baumstruktur von 3B entsprechen den in 3A gezeigten Begrenzungsvolumen N2 und N3 und repräsentieren diese. Die Kindknoten N2 und N3 in der Baumstruktur identifizieren die Vertices der jeweiligen Begrenzungsvolumen N2 und N3 im Raum. Jedes der Begrenzungsvolumen N2 und N3 ist in diesem speziellen Beispiel weiter unterteilt. Das Begrenzungsvolumen N2 ist in enthaltene Begrenzungsvolumen N4 und N5 unterteilt. Das Begrenzungsvolumen N3 ist in enthaltene Begrenzungsvolumen N6 und N7 unterteilt. Das Begrenzungsvolumen N7 umfasst zwei Begrenzungsvolumen N8 und N9. Das Begrenzungsvolumen N8 umfasst die Dreiecke O7 und O8, und das Begrenzungsvolumen N9 umfasst die Blattbegrenzungsvolumen N10 und N11 als seine untergeordneten (Kind-) Begrenzungsvolumen. Das Blattbegrenzungsvolumen N10 umfasst einen Primitivbereich (z.B. einen Dreiecksbereich) 010 und das Blattbegrenzungsvolumen N11 umfasst einen Elementbereich O9. Jeweilige untergeordneten (Kind-) Knoten N4, N5, N6, N8, N10 und N11 der Baumstruktur in 3B entsprechen den Begrenzungsvolumen N4, N5, N6, N8, N10 und N11 von 3A und repräsentieren diese im Raum.
• Der Baum in 3B ist in diesem bestimmten Beispiel nur drei bis sechs Ebenen tief, so dass die Volumen N4, N5, N6, N8, N10 und N11 „Blattknoten“ bilden - d.h. Knoten im Baum, die keine Kindknoten haben. 3A zeigt, dass die Blattknoten-Begrenzungsvolumen N4, N6 und N8 jeweils zwei Dreiecke der Geometrie in der Szene enthalten. Beispielsweise enthält die volumetrische Unterteilung N4 die Dreiecke O1 und O2, die volumetrische Unterteilung N6 die Dreiecke O5 und O6 und die volumetrische Unterteilung N8 die Dreiecke O7 und O8. 3A zeigt ferner, dass das Blattknoten-Begrenzungsvolumen N5 einen einzelnen Zylinder O3 enthält, der wie beispielsweise gezeigt keine gute Passung für das in gestrichelten Linien dargestellte AABB-Begrenzungsvolumen N5 bietet. Dementsprechend testet in einer beispielhaften, nicht beschränkenden Ausführungsform die TTU 138, anstatt das größere AABB-Begrenzungsvolumen N5 für den Strahl-Begrenzungsvolumen-Schnittpunkttest zu verwenden, den Strahl gegen eine Vielzahl von kleineren AABB-Begrenzungsvolumen, die so angeordnet, positioniert, dimensioniert und ausgerichtet sind, dass sie besser zum Zylinder O3 passen.
• Die in 3B gezeigte Baumstruktur repräsentiert diese Blattknoten N4, N5, N6 und N7, indem sie sie den entsprechenden Primitiven O1-O8 der Szenengeometrie zuordnet. Um auf diese Szenengeometrie zuzugreifen, durchläuft bzw. traversiert die TTU 138 die Baumdatenstruktur von 3B bis hinab zu den Blattknoten. Im Allgemeinen können und werden verschiedene Teile des Baums unterschiedliche Tiefen haben und eine unterschiedliche Anzahl von Primitiven enthalten. Blattknoten, die volumetrischen Unterteilungen zugeordnet sind, die keine Geometrie enthalten, brauchen nicht explizit in der Baumdatenstruktur dargestellt zu werden (d.h. der Baum wird „getrimmt“).
• Gemäß einigen Ausführungsformen kann der Teilbaum mit der Wurzel N7 einen Satz von Begrenzungsvolumen oder eine BVH repräsentieren, der oder die in einem anderen Koordinatenraum definiert ist als die den Knoten N1-N3 entsprechenden Begrenzungsvolumen. Befindet sich das Begrenzungsvolumen N7 in einem anderen Koordinatenraum als sein übergeordnetes Begrenzungsvolumen N3, so kann ein Instanzknoten N7', der die für die Traversierung des Teilbaums mit der Wurzel N7 erforderliche Strahltransformation bereitstellt, den Rest des Baums mit dem Teilbaum mit der Wurzel N7 verbinden. Der Instanzknoten N7' verbindet das Begrenzungsvolumen oder die BVH, das oder die den Knoten N1-N3 entspricht, mit den Begrenzungsvolumen oder der BVH, die den Knoten N7 usw. entsprechen, indem er die Transformation aus dem Koordinatenraum von N1-N3 (z.B. einem Weltraum) in den Koordinatenraum von N7 usw. (z.B. einem Objektraum) definiert.
• Die wie vorstehend beschrieben aufgebaute Beschleunigungsstruktur kann vorteilhaft von softwarebasierten Grafikpipeline-Prozessen genutzt werden, die auf einem herkömmlichen Universalcomputer laufen. Die derzeit offenbarten, nicht beschränkenden Ausführungsformen implementieren jedoch vorteilhaft die vorstehend beschriebenen Techniken im Kontext einer hardwarebasierten Grafikverarbeitungseinheit, die einen Hochleistungsprozessor wie beispielsweise einen oder mehrere Streaming-Multiprozessoren („SMs“) und einen oder mehrere Traversierungs-Coprozessoren oder „Baumtraversierungseinheiten“ bzw. „Tree Traversierung Units“ („TTUs“) - Untereinheiten eines oder einer Gruppe von Streaming-Multiprozessoren SMs einer 3D-Grafikverarbeitungspipeline - beinhaltet. Im Folgenden werden die allgemeine Struktur und die Funktionsweise eines solchen Systems beschrieben, das eine TTU 138 beinhaltet, die bestimmte Prozesse beschleunigt, die interaktive Strahlverfolgung unterstützen, darunter Strahl-Begrenzungsvolumen-Schnittpunkt-Tests, Strahl-Primitiv-Schnittpunkt-Tests und Strahl-„Instanz“-Transformationen für Echtzeit-Strahlverfolgung und andere Anwendungen.
• Beispielhaftes System-Blockdiagramm
• 4 veranschaulicht ein Beispiel für ein interaktives Echtzeit-Strahlverfolgungs-Grafiksystem 100 zur Erzeugung von Bildern unter Verwendung von dreidimensionalen (3D) Daten einer Szene oder eines Objekts (von Objekten), einschließlich der Beschleunigungsdatenstruktur wie vorstehend beschrieben.
• Das System 100 umfasst eine Eingabevorrichtung 110, einen oder mehrere Prozessor(en) 120, eine oder mehrere Grafikverarbeitungseinheit(en) (GPUs) 130, Speicher 140 und eine oder mehrere Anzeige(n) 150. Das in 4 gezeigte System kann jeden beliebigen Formfaktor annehmen, einschließlich, aber nicht beschränkt auf einen Personal Computer, ein Smartphone oder ein anderes intelligentes Gerät, ein Videospielsystem, ein tragbares Virtual- oder Augmented-Reality-System, ein Cloudbasiertes Computer- bzw. Rechensystem, ein in einem Fahrzeug montiertes Grafiksystem, ein System-on-a-Chip (SoC) usw.
• Der Prozessor 120 kann eine Multicore- bzw. Mehrkern-Zentralverarbeitungseinheit (CPU) sein, die dazu betreibbar ist, eine Anwendung in Echtzeit interaktiv im Ansprechen auf die Eingabevorrichtung 110 auszuführen, deren Ausgabe Bilder für die Anzeige auf einer Anzeige 150 enthält. Die Anzeige 150 kann jede beliebige Art von Anzeige sein, z.B. eine stationäre Anzeige, eine am Kopf befestigte Anzeige, wie z.B. Anzeigegläser oder eine Brille, andere Arten von tragbaren Anzeigen, eine in der Hand haltbare Anzeige, eine in einem Fahrzeug montierte Anzeige usw. Beispielsweise kann der Prozessor 120 eine Anwendung auf der Grundlage von Eingaben ausführen, die von der Eingabevorrichtung 110 (z.B. einem Joystick, einem Trägheitssensor, einem Umgebungslichtsensor usw.) empfangen werden, und kann die GPU 130 anweisen, Bilder zu erzeugen, die einen Anwendungsfortschritt für die Anzeige auf der Anzeige 150 zeigen.
• Basierend auf der Ausführung der Anwendung auf dem Prozessor 120 kann der Prozessor Anweisungen für die GPU 130 erteilen, um Bilder unter Verwendung von im Speicher 140 gespeicherten 3D-Daten zu erzeugen. Die GPU 130 enthält spezialisierte Hardware zur Beschleunigung der Bilderzeugung in Echtzeit. Die GPU 130 ist beispielsweise in der Lage, Informationen für Tausende oder Millionen von Grafikprimitiven (Polygonen) in Echtzeit zu verarbeiten, aufgrund der Fähigkeit des Grafikprozessors, sich wiederholende und hochparallele spezialisierte Berechnungsaufgaben wie eine Polygon-Abtast-Konvertierung viel schneller als herkömmliche softwaregesteuerte CPUs durchzuführen. Anders als zum Beispiel der Prozessor 120, der mehrere Kerne mit viel Cache-Speicher haben kann, die jeweils einige wenige Software-Threads gleichzeitig verarbeiten können, kann die GPU 130 Hunderte oder Tausende von parallel laufenden Verarbeitungs- bzw. Rechenkernen oder „Streaming-Multiprozessoren“ (SMs) 132 beinhalten.
• In einer beispielhaften Ausführungsform beinhaltet die GPU 130 eine Vielzahl von programmierbaren Hochleistungsprozessoren, die als „Streaming-Multiprozessoren“ („SMs“) 132 bezeichnet werden können, und eine hardwarebasierte Grafikpipeline mit einer Grafik-Primitiv-Engine 134 und einer Raster-Engine 136. Diese Komponenten der GPU 130 sind dazu konfiguriert, eine Bildwiedergabe in Echtzeit unter Verwendung einer Technik namens „Abtastkonversionsrasterung“ („scan conversion rasterization“) durchzuführen, um dreidimensionale Szenen auf einer zweidimensionalen Anzeige 150 anzuzeigen. Bei der Rasterisierung werden (häufig über einen Bildpufferspeicher) geometrische Bausteine (z.B. Punkte, Linien, Dreiecke, Quads, Netze usw.) einer 3D-Szene auf Pixel der Anzeige abgebildet.
• Die GPU 130 wandelt die geometrischen Bausteine (d.h. Polygonprimitive wie beispielsweise Dreiecke) des 3D-Modells in Pixel des 2D-Bilds um und weist jedem Pixel einen Anfangsfarbwert zu. Die Grafikpipeline kann Schattierungs-, Transparenz-, Textur- und/oder Farbeffekte auf Teile des Bilds anwenden, indem sie die Farbwerte der Pixel definiert oder anpasst. Die endgültigen Pixelwerte können mit Anti-Aliasing versehen, gefiltert und der Anzeige 150 zur Anzeige bereitgestellt werden. Viele Software- und Hardware-Fortschritte im Laufe der Jahre haben die subjektive Bildqualität unter Verwendung von Rasterisierungstechniken bei Bildwechselfrequenzen verbessert, die für Echtzeitgrafiken (d.h. 30 bis 60 Einzelbilder bzw. Frames pro Sekunde) bei hohen Anzeigeauflösungen wie beispielsweise 4096 x 2160 Pixel oder mehr auf einer oder mehreren Anzeigen 150 erforderlich sind.
• Damit die GPU 130 die Strahlverfolgung in Echtzeit auf effiziente Weise durchführen kann, stellt sie eine oder mehrere „TTUs“ 138 bereit, die mit einem oder mehreren SMs 132 gekoppelt sind. Die TTU 138 beinhaltet Hardwarekomponenten, die für die Durchführung (oder Beschleunigung) von Operationen konfiguriert sind, die üblicherweise in Strahlverfolgungs-Algorithmen verwendet werden. Ein Ziel der TTU 138 ist es, die bei der Strahlverfolgung verwendeten Operationen so weit zu beschleunigen, dass die Leistungsfähigkeit der Strahlverfolgung für Echtzeit-Grafikanwendungen (z.B. Spiele) nutzbar wird und qualitativ hochwertige Schatten, Reflexionen und globale Beleuchtung ermöglicht. Von der TTU 138 erzeugte Ergebnisse können zusammen mit oder alternativ zu anderen grafikbezogenen Operationen, die in der GPU 130 durchgeführt werden, verwendet werden.
• Insbesondere können die SMs 132 und die TTU 138 zusammenarbeiten, um Strahlen in ein 3D-Modell zu werfen und zu bestimmen, ob und wo dieser Strahl die Geometrie des Modells schneidet. Die Strahlverfolgung simuliert direkt Licht, das sich durch eine virtuelle Umgebung oder Szene bewegt. Die Ergebnisse der Strahlüberschneidungen zusammen mit der Oberflächentextur, der Blickrichtung und/oder den Beleuchtungsbedingungen werden zur Bestimmung von Pixelfarbwerten verwendet. Die von den SMs 132 in Zusammenarbeit mit der TTU 138 durchgeführte Strahlverfolgung ermöglicht es, dass computergenerierte Bilder Schatten, Reflexionen und Brechungen in einer Weise erfassen, die von Fotos oder Videos der realen Welt nicht zu unterscheiden ist. Da Strahlverfolgungs-Techniken aufgrund der großen Anzahl von Strahlen, die verfolgt werden müssen, noch rechenintensiver sind als die Rasterung, kann die TTU 138 einige der rechenintensiveren Aspekte dieses Prozesses in Hardware beschleunigen.
• Bei einer wie vorstehend beschrieben aufgebauten BVH führt die TTU 138 eine Baumsuche durch, bei der jeder von dem Strahl besuchte Knoten im Baum ein Begrenzungsvolumen für jeden absteigenden Zweig oder jedes absteigende Blatt hat, und besucht der Strahl nur die absteigenden Zweige oder Blätter, deren entsprechendes Begrenzungsvolumen er schneidet. Auf diese Weise testet die TTU 138 explizit nur eine kleine Anzahl von Primitiven auf Schnittpunkte, nämlich diejenigen, die sich in den vom Strahl geschnittenen Blattknoten befinden. In den beispielhaften, nicht beschränkenden Ausführungsformen beschleunigt die TTU 138 sowohl die Baumtraversierung (einschließlich der Strahl-Volumen-Tests) als auch die Strahl-Primitiv-Tests. Als Teil der Traversierung kann sie auch mindestens eine Ebene von Instanztransformationen verarbeiten, indem sie einen Strahl von Weltraumkoordinaten in das Koordinatensystem eines Instanznetzes transformiert. In den beispielhaften, nicht beschränkenden Ausführungsformen führt die TTU 138 all dies in MIMD-Manier durch, d.h. Strahlen werden unabhängig voneinander behandelt, sobald sie sich innerhalb der TTU befinden.
• In den beispielhaften, nicht beschränkenden Ausführungsformen arbeitet die TTU 138 als ein Diener (Coprozessor) der SMs (Streaming-Multiprozessoren) 132. Mit anderen Worten arbeitet die TTU 138 in den beispielhaften, nicht beschränkenden Ausführungsformen nicht unabhängig, sondern folgt den Befehlen der SMs 132, um bestimmte rechenintensive Aufgaben im Zusammenhang mit Strahlverfolgung viel effizienter auszuführen, als die SMs 132 dies selbst tun könnten. In anderen Ausführungsformen oder Architekturen könnte die TTU 138 mehr oder weniger autonom sein.
• In den gezeigten Beispielen empfängt die TTU 138 Befehle über SM 132-Anweisungen und schreibt Ergebnisse zurück in eine SM-Registerdatei. Für viele gewöhnliche Anwendungsfälle (z.B. bei opaken Dreiecken mit höchstens einer Instanzierungsebenen) kann die TTU 138 die Strahlverfolgungs-Abfrage ohne weitere Interaktion mit dem SM 132 bedienen. Kompliziertere Abfragen (z.B. mit alphagetesteten Dreiecken, anderen Primitiven als Dreiecken oder mehrere Instanzierungsebenen) können mehrere Wechsel erfordern (obwohl die hierin beschriebene Technologie die Notwendigkeit solcher „Wechsel“ für bestimmte Arten von Geometrien verringert, indem sie die TTU 138 mit erweiterten Fähigkeiten ausstattet, um autonom die Prüfung auf Strahl-Begrenzungsvolumen-Schnittpunkte durchzuführen, ohne den aufrufenden SM um Hilfe bitten zu müssen). Neben der Verfolgung von Strahlen ist die TTU 138 in der Lage, allgemeinere räumliche Abfragen durchzuführen, bei denen ein AABB oder das extrudierte Volumen zwischen zwei AABBs (das wir als einen „Strahl“ bezeichnen) den Platz des Strahls einnimmt. Die TTU 138 ist zwar besonders für die Beschleunigung von Aufgaben im Zusammenhang mit der Strahlverfolgung angepasst, kann aber auch für andere Aufgaben als die Strahlverfolgung verwendet werden.
• Die TTU 138 führt also autonom einen Test jedes Strahls gegen eine Vielzahl von Begrenzungsvolumen durch und kann alle Begrenzungsvolumen, die sich nicht mit dem Strahl schneiden, ausschließen. Beginnend bei einem Wurzelknoten, der alles in der Szene begrenzt, testet der Traversierungs-Coprozessor jeden Strahl gegen kleinere (möglicherweise überschneidende) Kind-Begrenzungsvolumen, die wiederum die absteigenden Zweige der BVH begrenzen. Der Strahl folgt den Kindzeigern für die Begrenzungsvolumen, auf die der Strahl trifft, zu anderen Knoten, bis die Blätter oder Endknoten (Volumen) der BVH erreicht sind.
• Sobald die TTU 138 die Beschleunigungsdatenstruktur durchläuft, um einen End- oder „Blatt“-Knoten zu erreichen (der durch ein oder mehrere Begrenzungsvolumen repräsentiert sein kann), der den Strahl schneidet und ein geometrisches Primitiv enthält, führt sie einen beschleunigten Strahl-Primitiv-Schnittpunkttest durch, um zu bestimmen, ob der Strahl dieses Primitiv (und damit die Objektoberfläche, die dieses Primitiv definiert) schneidet. Der Strahl-Primitiv-Test kann zusätzliche Informationen über Primitive liefern, die der Strahl schneidet und die zur Bestimmung der für die Schattierung und Visualisierung erforderlichen Materialeigenschaften der Oberfläche verwendet werden können. Durch rekursives Traversieren durch die Beschleunigungsdatenstruktur kann der Traversierungs-Coprozessor alle Objektprimitive ermitteln, die der Strahl schneidet, oder das (aus Sicht des Betrachtungspunkts) nächstgelegene Primitiv, das der Strahl schneidet (welches in einigen Fällen das einzige Primitiv ist, das vom Betrachtungspunkt entlang des Strahls sichtbar ist). Siehe z.B. Lefrancois et al, NVIDIA Vulkan Ray Tracing Tutorial, Dezember 2019, https://developer.nvidia.com/rtx/raytracing/vkray.
• Wie vorstehend erwähnt, beschleunigt die TTU 138 auch die Transformation jedes Strahls vom Weltraum in den Objektraum, um immer feinere Begrenzungsrahmen-Kapselungen der Primitive zu erhalten und die Duplizierung dieser Primitive über die Szene hinweg zu reduzieren. Wie vorstehend beschrieben, können Objekte, die viele Male in der Szene in unterschiedlichen Positionen, Ausrichtungen und Maßstäben repliziert werden, in der Szene als Instanzknoten, die einen Begrenzungsrahmen und einen Blattknoten im Weltraum-BVH mit einer Transformation verbinden, die auf den Weltraumstrahl angewendet werden kann, um ihn in einen Objektkoordinatenraum zu transformieren, und als ein Zeiger auf ein Objektraum-BVH dargestellt werden. Dadurch wird vermieden, dass die Objektraum-BVH-Daten mehrfach im Weltraum repliziert werden, was Speicher und damit verbundene Speicherzugriffe spart. Die Instanztransformation erhöht die Effizienz durch Transformieren des Strahls in den Objektraum, anstatt zu erfordern, die Geometrie oder die Begrenzungsvolumen-Hierarchie in den Welt (Strahl)-Raum zu transformieren, und ist außerdem mit zusätzlichen, herkömmlichen Rasterisierungsprozessen kompatibel, die die Grafikverarbeitung durchführt, um die Primitive zu visualisieren.
• Beispielhafte Strahlverfolgungsprozesse
• 5 zeigt eine beispielhafte Strahlverfolgungs-Schattierungspipeline bzw.-Shading-Pipeline 500, die von dem SM 132 ausgeführt und durch die TTU 138 beschleunigt werden kann. Die Strahlverfolgungs-Schattierungspipeline 500 beginnt damit, dass ein SM 132 die Strahlerzeugung 510 aufruft und eine entsprechende Strahlverfolgungsanforderung an die TTU 138 sendet. Die Strahlverfolgungsanforderung identifiziert einen einzelnen Strahl, der in die Szene geworfen wird, und fordert die TTU 138 auf, nach Schnittpunkten mit einer Beschleunigungsdatenstruktur zu suchen, die der SM 132 ebenfalls spezifiziert. Die TTU 138 durchläuft (5 Block 520) die Beschleunigungsdatenstruktur, um Schnittpunkte oder potenzielle Schnittpunkte zwischen dem Strahl und den volumetrischen Unterteilungen und zugeordneten Dreiecken zu bestimmen, die die Beschleunigungsdatenstruktur repräsentiert. Potenzielle Schnittpunkte können durch Finden von bzw. Suchen nach Begrenzungsvolumen in der Beschleunigungsdatenstruktur identifiziert werden, die von dem Strahl geschnitten werden. Nachkommen von nicht geschnittenen Begrenzungsvolumen müssen nicht untersucht werden.
• Für Dreiecke innerhalb geschnittener Begrenzungsvolumen führt der Strahl-Primitive-Testblock 720 der TTU 138 einen Schnittpunkt 530-Prozess durch, um zu bestimmen, ob der Strahl die Primitive schneidet.
• Der SM 132 kann z. B. die TTU 138 anweisen, nur den „nächstgelegenen Treffer“ bzw. „closest hit“-Schnittpunkt des Strahls mit der spezifizierten Geometrie zu melden, oder er kann die TTU 138 anweisen, auch „jeden Treffer“ bzw. „any hit“-Schnittpunkte des Strahls mit der spezifizierten Geometrie zu melden, unabhängig von der Reihenfolge. Im letzteren Fall kann die TTU 138 in der Mitte der Traversierung Schnittpunktinformationen an den SM 132 zurückgeben, der daraufhin eine „any hit“-Schattierungsoperation 540 durchführen kann, um zu bestimmen, ob tatsächlich ein Schnitt stattgefunden hat. Beispielsweise kann der SM 132 eine Texturabfrage für ein geschnittenes Primitiv durchführen (oder von anderer Hardware durchführen lassen) und auf der Grundlage des entsprechenden Texelwerts entscheiden, ob ein tatsächlicher Treffer aufgetreten ist, oder die Opazität eines lichtdurchlässigen Materials, und kann die Traversierung abschließen oder die Traversierung wieder aufnehmen bzw. fortsetzen (falls der Strahl mit einem nicht leeren Stack zurückgegeben wurde), und zwar auf der TTU 138 in Abhängigkeit von dem schattierten „any hit“-Wert. Der SM 132 nachverfolgt optional solche Ergebnisse, da die TTU 138 mehrere Schnittpunkte mit verschiedenen Geometrien in der Szene in beliebiger Reihenfolge zurückgeben kann und lichtdurchlässige Materialien in dieser Reihenfolge zusammengesetzt werden müssen.
• Wenn die Traversierung abgeschlossen ist, gibt die TTU 138 die Ergebnisse der Abfrage an den SM 132 zurück. Für Strahlen, die ein Primitiv geschnitten haben, gibt die TTU 138 Informationen über das geschnittene Primitiv zurück, z.B. im Fall eines geschnittenen Dreiecks eine Dreiecks-ID und baryzentrische Koordinaten, die der SM 132 verwenden kann, um eine „nächstgelegener Treffer“-Schattierungsfunktion 570 zu identifizieren und aufzurufen. Für Strahlen, die keine Primitive geschnitten haben, gibt der SM 132 einen Identifikator zurück, der anzeigt, dass nichts getroffen wurde, so dass der SM 132 eine „Verfehlt“-Schattierungsoperation durchführen kann, die einen zuvor bestimmten Verfehlungs-Shader 560 aufruft.
• 6 ist ein Ablaufdiagramm, das beispielhafte Strahlverfolgungsoperationen zusammenfasst, die die TTU 138 durchführt, wie vorstehend in Kooperation mit einem oder mehreren SM(s) 132 beschrieben. Die in 6 dargestellten Operationen werden von der TTU 138 in Zusammenarbeit mit einem SM 132 durchgeführt. Die TTU 138 kann somit die Identifikation eines Strahls vom SM 132 und einen Traversierungsstatus erhalten, der einen oder mehrere Knoten in einem oder mehreren BVHs aufzählt, die der Strahl traversieren muss. Die TTU 138 bestimmt, welche Begrenzungsvolumen einer BVH-Datenstruktur der Strahl schneidet (der „Strahl-Complet“-Test 612). Die TTU 138 kann anschließend auch bestimmen, ob der Strahl ein oder mehrere Primitive in den geschnittenen Begrenzungsvolumen schneidet und welche Dreiecke geschnitten werden (der „Strahl-Primitiv-Test“ 620) - oder der SM 132 kann diesen Test in Software durchführen, falls er für die TTU zu kompliziert ist, um ihn selbst durchzuführen. In beispielhaften, nicht beschränkenden Ausführungsformen spezifizieren Complets Wurzel- oder Innenknoten (d.h. Volumen) der Begrenzungsvolumen-Hierarchie mit Kindern, die andere Complets oder Blattknoten eines einzigen Typs pro Complet sind.
• Zunächst prüft die TTU 138 den Traversierungsstatus des Strahls. Falls ein Stapel bzw. Stack, den die TTU 138 für den Strahl unterhält, leer ist, dann ist die Durchquerung bzw. Traversierung abgeschlossen. Falls es einen Eintrag oben auf dem Stack gibt, gibt der Traversierungs-Coprozessor 138 eine Anfrage an das Speicher-Subsystem aus, um diesen Knoten abzurufen. Der Traversierungs-Coprozessor 138 führt dann einen Begrenzungsrahmen-Test 612 durch, um zu bestimmen, ob ein Begrenzungsvolumen einer BVH-Datenstruktur von einem bestimmten Strahl geschnitten wird, den der SM 132 spezifiziert (Schritt 612, 614). Falls der Begrenzungsrahmen-Test bestimmt, dass das Begrenzungsvolumen nicht von dem Strahl geschnitten wird („Nein“ in Schritt 614), dann besteht keine Notwendigkeit, irgendwelche weiteren Tests für die Visualisierung durchzuführen, und kann die TTU 138 dieses Ergebnis an den anfordernden SM 132 zurückgeben. Denn wenn ein Strahl ein Begrenzungsvolumen verfehlt (wie in 1A in Bezug auf das Begrenzungsvolumen 10), dann wird der Strahl alle anderen kleineren Begrenzungsvolumen innerhalb des getesteten Begrenzungsvolumens und alle Primitive, die dieses Begrenzungsvolumen enthält, verfehlen.
• Falls der von der TTU 138 durchgeführte Begrenzungsrahmen-Test ergibt, dass das Begrenzungsvolumen von dem Strahl geschnitten wird („Ja“ in Schritt 614), dann bestimmt die TTU, ob das Begrenzungsvolumen in kleinere Begrenzungsvolumen unterteilt werden kann (Schritt 618). In einer beispielhaften Ausführungsform führt die TTU 138 nicht unbedingt selbst eine 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 oder mehrere Begrenzungsvolumen und einen Zeiger, der zu einem Zweig- oder einem Blattknoten führt. Wenn ein Strahl einen Knoten unter Verwendung der TTU 138 verarbeitet, testet er sich selbst gegen die Begrenzungsvolumen der Kinder des Knotens. Der Strahl schiebt nur für die Zweige oder Blätter, deren repräsentative Begrenzungsvolumen getroffen wurden, Stack-Einträge auf seinen Stack. Wenn ein Strahl einen Knoten in der beispielhaften Ausführungsform abruft, testet er nicht gegen das Begrenzungsvolumen des Knotens - er testet gegen die Begrenzungsvolumen der Kinder des Knotens. Die TTU 138 schiebt Knoten, deren Begrenzungsvolumen von einem Strahl getroffen werden, in einer von der Strahlkonfiguration bestimmten Reihenfolge auf den Traversierungs-Stack des Strahls. Beispielsweise 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 Traversierungs-Stack zu schieben. Falls es weitere Unterteilungen des Begrenzungsvolumens gibt („Ja“ in Schritt 618), dann wird auf diese weiteren Unterteilungen des Begrenzungsvolumens zugegriffen, und wird der Begrenzungsrahmentest für jedes der sich ergebenden unterteilten Begrenzungsvolumen durchgeführt, um zu bestimmen, welche unterteilten Begrenzungsvolumen von dem Strahl geschnitten werden und welche nicht. In diesem rekursiven Prozess können einige der Begrenzungsvolumen durch den Test 614 eliminiert werden, während andere Begrenzungsvolumen in immer weiteren Unterteilungen resultieren können, die durch rekursives Anwenden der Schritte 612-618 von der TTU 738 auf Schnitte bzw. Schnittpunkte geprüft werden.
• Sobald die TTU 138 bestimmt, dass die von dem Strahl geschnittenen Begrenzungsvolumen Blattknoten sind („Nein“ in Schritt 518), führt die TTU 138 und/oder der SM 132 einen Primitiv (z.B. Dreieck)-Schnittpunkt-Test 620 durch, um zu bestimmen, ob der Strahl Primitive in den geschnittenen Begrenzungsvolumen schneidet und welche Primitive der Strahl schneidet. Die TTU 138 führt somit eine Tiefe-zuerst-Traversierung geschnittener absteigender Zweigknoten durch, bis Blattknoten erreicht werden. Die TTU 138 verarbeitet die Blattknoten. Falls die Blattknoten Primitivbereiche sind, prüft die TTU 138 oder der SM 132 sie gegen den Strahl. Falls die Blattknoten Instanzknoten sind, wendet die TTU 138 oder der SM 132 die Instanztransformation an. Falls die Blattknoten Elementbereiche sind, gibt die TTU 138 sie an den anfordernden SM 132 zurück. In den beispielhaften, nicht beschränkenden Ausführungsformen kann der SM 132 der TTU 138 befehlen, verschiedene Arten von Strahl-Primitiv-Schnittpunkttests durchzuführen und verschiedene Ergebnisse zu melden, je nachdem, welche Operationen von einer Anwendung (oder einem Software-Stack, auf dem die Anwendung läuft) kommen und von dem SM an die TTU weitergeleitet werden. Beispielsweise kann der SM 132 die TTU 138 anweisen, das nächstgelegene sichtbare Primitiv zu melden, das durch den Schnittpunkttest aufgedeckt wird, oder alle Primitive zu melden, die der Strahl schneidet, unabhängig davon, ob sie das nächstgelegene sichtbare Primitiv sind. Der SM 132 kann diese unterschiedlichen Ergebnisse für verschiedene Arten der Visualisierung verwenden. Oder der SM 132 kann den Strahl-Primitiv-Schnittpunkt-Test selbst durchführen, sobald die TTU 138 Strahl-Complet-Testergebnisse gemeldet hat. Sobald die TTU 138 mit der Verarbeitung der Blattknoten fertig ist, kann es andere Verzweigungsknoten (die zuvor auf den Stack des Strahls geschoben wurden) geben, die zu testen bzw. prüfen sind.
• Beispielhafte, nicht beschränkende TTU 138-Hardware-lmplementierunq
• 7 zeigt ein beispielhaftes, vereinfachtes Blockdiagramm der TTU 138 mit Hardware, die für die Durchführung beschleunigter Traversierungsoperationen wie vorstehend beschrieben konfiguriert ist. In einigen Ausführungsformen kann die TTU 138 eine Tiefe-zuerst-Traversierung einer Begrenzungsvolumen-Hierarchie unter Verwendung einer kurzen Stack-Traversierung mit Schnittpunkttestung von unterstützten Blattknoten-Primitiven und Rückgabe von Alpha-Primitiven und nicht unterstützten Blattknoten-Primitiven (Elementen) in der Mitte der Traversierung durchführen. Die TTU 138 beinhaltet dedizierte Hardware, um zu bestimmen, ob ein Strahl Begrenzungsvolumen schneidet, und dedizierte Hardware, um zu bestimmen, ob ein Strahl Primitive der Baumdatenstruktur schneidet.
• Die TTU 138 kann eine Schnittstelle 160 zwischen dem SM 132 und den TTU-Ausführungseinheiten enthalten. Die Schnittstelle 160 ermöglicht es dem SM 132, Beschleunigungsstrukturtraversierungen auf der TTU 138 effizient und robust auszuführen, indem empfangene Abfragen geplant und Abfrageergebnisse zurückgegeben werden, so dass die Ausführungseinheiten in der TTU 138 effizient mit Daten zur Verarbeitung versorgt werden. In einigen Beispielen kann die Schnittstelle 160 oder können eine oder mehrere Komponenten der Schnittstelle 160 außerhalb der TTU 138 bereitgestellt sein.
• Genauer beinhaltet die TTU 138 einen Schnittpunktverwaltungsblock 722, einen Strahlverwaltungsblock 730 und einen Stackverwaltungsblock 740. Jeder dieser Blöcke (und alle der anderen Blöcke in 7) kann dedizierte Hardware bilden, die durch Logikgatter, Register, in die Hardware eingebettete Nachschlagetabellen oder andere kombinatorische Logik usw. implementiert ist.
• Der Strahlverwaltungsblock 730 ist für die Verwaltung von Informationen über und die Durchführung von Operationen bezüglich eines Strahls verantwortlich, der von einem SM 132 gegenüber dem Strahlverwaltungsblock spezifiziert wurde. Der Stack-Verwaltungsblock 740 arbeitet in Verbindung mit der Traversierungslogik 712, um Informationen über die Traversierung einer BVH-Beschleunigungsdatenstruktur zu verwalten und Operationen mit Bezug dazu durchzuführen. Die Traversierungslogik 712 wird durch Ergebnisse eines Strahl-Complet-Testblocks 710 gesteuert, der Schnittpunkte zwischen dem von dem Strahlverwaltungsblock 730 spezifizierten Strahl und durch das BVH repräsentierten volumetrischen Unterteilungen prüft, unter Verwendung von Instanztransformationen nach Bedarf. Der Strahl-Complet-Testblock 710 ruft zusätzliche Informationen über die BVH aus dem Speicher 140 über einen L0-Complet-Cache 752 ab, der Teil der TTU 138 ist. Die Ergebnisse des Strahl-Complet-Testblocks 710 informieren die Traversierungslogik 712 darüber, ob weitere rekursive Traversierungen erforderlich sind. Der Stack-Verwaltungsblock 140 verwaltet Stapel bzw. Stacks, um Statusinformationen zu verfolgen, wenn die Traversierungslogik 712 von einer Ebene der BVH zu einer anderen wechselt, wobei der Stack-Verwaltungsblock 740 Elemente auf den Stack schiebt, wenn die Traversierungslogik tiefer in die BVH traversiert, und Elemente vom Stack nimmt, wenn die Traversierungslogik in der BVH nach oben wandert. Der Stackverwaltungsblock 740 ist in der Lage, dem anfragenden SM 132 Statusinformationen (z.B. Zwischen- oder Endergebnisse) jederzeit, wenn dieser sie anfordert, zur Verfügung zu stellen.
• Der Schnittpunktverwaltungsblock 722 verwaltet Informationen über Schnittpunkte zwischen Strahlen und Primitiven und führt entsprechende Operationen durch, unter Verwendung von Instanztransformationen bei Bedarf. Der Strahl-Primitiv-Testblock 720 ruft bei Bedarf Informationen betreffend die Geometrie aus dem Speicher 140 über einen L0-Primitiv-Cache 754 ab, der Teil der TTU 138 ist. Der Schnittpunktverwaltungsblock 722 wird durch Ergebnisse von Schnittpunkttests informiert, die der Strahl-Primitiv-Test- und Transformations-Block 720 durchführt. Folglich stellt der Strahl-Primitiv-Test- und Transformations-Block 720 dem Schnittmengenverwaltungsblock 722 Schnittpunktergebnisse bereit, welcher Geometrietreffer und Schnittpunkte an den anfordernden SM 132 meldet.
• Eine Stackverwaltungseinheit 740 inspiziert den Traversierungsstatus, um zu bestimmen, welche Art von Daten abgerufen werden muss und welcher Datenpfad (Complet oder Primitiv) sie verbrauchen wird. Die Schnittpunkte für die Begrenzungsvolumen werden in dem Strahl-Complet-Test-Pfad der TTU 138 bestimmt, der einen oder mehrere Strahl-Complet-Test-Blöcke 710 und einen oder mehrere Traversierungslogikblöcke 712 beinhaltet. Ein Complet spezifiziert Wurzel- oder Innenknoten eines Begrenzungsvolumens. Folglich kann ein Complet ein oder mehrere Begrenzungsvolumen für den Strahl-Complet-Test definieren. In den hierin beschriebenen beispielhaften Ausführungsformen kann ein Complet eine Vielzahl von „untergeordneten“ Begrenzungsvolumen definieren, die (unabhängig davon, ob sie Blattknoten repräsentieren oder nicht), nicht notwendigerweise alle Nachkommen haben, die aber die TTU parallel für Strahl-Begrenzungsvolumen-Schnittpunkte testen wird, um zu bestimmen, ob geometrische Primitive, die der Vielzahl von Begrenzungsvolumen zugeordnet sind, auf Schnittpunkte getestet werden müssen.
• Der Strahl-Complet-Testpfad der TTU 138 identifiziert, welche Begrenzungsvolumen von dem Strahl geschnitten werden. Begrenzungsvolumen, die von dem Strahl geschnitten werden, müssen weiterverarbeitet werden, um zu bestimmen, ob die den geschnittenen Begrenzungsvolumen zugeordneten Primitive geschnitten werden. Die Schnittpunkte für die Primitive werden in dem Strahl-Primitiv-Testpfad bestimmt, der einen oder mehrere Strahl-Primitiv-Test- und Transformations-Blöcke 720 und einen oder mehrere Schnittpunktverwaltungsblöcke 722 beinhaltet.
• Die TTU 138 empfängt Abfragen von einem oder mehreren SMs 132, um Baumtraversierungsoperationen durchzuführen. Die Abfrage kann erfragen, ob ein Strahl Begrenzungsvolumen und/oder Primitive in einer BVH-Datenstruktur schneidet. Die Abfrage kann einen Strahl (z.B. Ursprung, Richtung und Länge des Strahls) und einen BVH-Datenstruktur- und Traversierungsstatus (kurzer Stack) identifizieren, der einen oder mehrere Einträge enthält, die Knoten in einer oder mehreren Begrenzungsvolumen-Hierarchien referenziert, die der Strahl besuchen soll. Die Abfrage kann auch Informationen darüber enthalten, wie der Strahl bestimmte Arten von Schnittpunkten während der Traversierung behandeln soll. Die Strahlinformationen können im Strahlverwaltungsblock 730 gespeichert werden. Die gespeicherten Strahlinformationen (z.B. die Strahllänge) können auf der Grundlage der Ergebnisse der Strahl-Primitiv-Testung aktualisiert werden.
• Die TTU 138 kann anfordern, dass die in der Abfrage identifizierte BVH-Datenstruktur aus dem Speicher außerhalb der TTU 138 abgerufen wird. Abgerufene Teile der BVH-Datenstruktur können in dem Level-Zero (L0)-Cache 750 innerhalb der TTU 138 zwischengespeichert werden, so dass die Informationen für andere zeitkohärente TTU-Operationen zur Verfügung stehen, 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 benötigten Informationen im Complet-Cache 752 verfügbar sind, bestimmt der Strahl-Complet-Test-Block 710 von dem Strahl geschnittene Begrenzungsvolumen. Bei der Durchführung dieses Tests kann der Strahl aus dem Koordinatenraum der Begrenzungsvolumen-Hierarchie in einen Koordinatenraum transformiert werden, der relativ zu einem Complet definiert ist. Der Strahl wird gegen die Begrenzungsrahmen getestet, die den Kindknoten des Complets zugeordnet sind. In der beispielhaften, nicht beschränkenden Ausführungsform wird der Strahl nicht gegen den eigenen Begrenzungsrahmens des Complets getestet, weil (1) die TTU 138 den Strahl zuvor gegen einen ähnlichen Begrenzungsrahmen getestet hat, als sie das übergeordnete Begrenzungsrahmenkind prüfte, der dieses Complet referenzierte, und (2) ein Zweck des Complet-Begrenzungsrahmens darin besteht, ein lokales Koordinatensystem zu definieren, innerhalb dessen die untergeordneten Begrenzungsrahmen in komprimierter Form ausgedrückt werden können. Falls der Strahl irgendeinen der untergeordneten Begrenzungsrahmen schneidet, werden die Ergebnisse an die Traversierungslogik weitergeleitet, um die Reihenfolge zu bestimmen, in der die entsprechenden Kindzeiger auf den Traversierungs-Stack geschoben werden (weitere Tests werden wahrscheinlich erfordern, dass die Traversierungslogik 712 bis zu der nächsten Ebene der BVH abwärtstraversiert). Diese Schritte werden rekursiv wiederholt, bis geschnittene Blattknoten der BVH angetroffen werden
• Der Strahl-Complet-Test-Block 710 kann der Traversierungslogik 712 Strahl-Complet-Schnittpunkte bereitstellen. Unter Verwendung der Ergebnisse des Strahl-Complet-Tests erstellt die Traversierungslogik 712 Stack-Einträge, die in den Stackverwaltungsblock 740 zu schieben sind. Die Stack-Einträge können interne Knoten (d.h. einen Knoten, der einen oder mehrere Kindknoten 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, die durch den Strahl-Primitiv-Test- und Transformations-Block 720 auf Strahlschnittpunkte getestet werden müssen, anzeigen. Der Strahl-Complet-Test-Block 710 kann die Traversierung auf internen Knoten, die in dem Stack identifiziert wurden, wiederholen, um alle Blattknoten in der BVH zu ermitteln, die der Strahl schneidet. Die genauen Tests, die der Strahl-Complet-Test-Block 710 durchführt, werden in der beispielhaften, nicht beschränkenden Ausführungsform durch Modus-Bits, Strahloperationen (siehe unten) und Herausfiltern von Treffern bestimmt, und die TTU 138 kann sowohl Zwischen- als auch Endergebnisse an den SM 132 zurückgeben.
• Strahl-Primitiv-Schnittpunkt-Testung
• Erneut auf 7 Bezug nehmend, ist die TTU 138 auch in der Lage, Schnittpunkttests zu beschleunigen, die bestimmen, ob ein Strahl eine bestimmte Geometrie oder Primitive schneidet. Für einige Fälle ist die Geometrie ausreichend komplex (z.B. definiert durch Kurven oder andere abstrakte Konstrukte gegenüber z.B. Scheitelpunkten bzw. Vertices), so dass die TTU 138 in einigen Ausführungsformen nicht in der Lage sein kann, bei der Strahl-Primitiv-Schnittpunkt-Testung zu helfen. In solchen Fällen meldet die TTU 138 dem SM 132 einfach die Ergebnisse der Strahl-Complet-Schnittpunkt-Testergebnisse, und führt der SM 132 die Strahl-Primitiv-Schnittpunkt-Testung selbst durch. In anderen Fällen (z.B. bei Dreiecken) kann die TTU 132 den Strahl-Dreieck-Schnittpunkt-Test selbst durchführen, wodurch sich die Leistung des gesamten Strahlverfolgungsprozesses weiter erhöht. Der Vollständigkeit halber wird im Folgenden beschrieben, wie die TTU 138 die Strahl-Primitiv-Schnittpunkt-Testung durchführen oder beschleunigen kann.
• Wie vorstehend erklärt wurde, identifizieren (umschließen) Blattknoten, die als von dem Strahl geschnitten ermittelt wurden, Primitive, die von dem Strahl geschnitten werden können oder nicht. Eine Option besteht für die TTU 138 darin, z.B. einen Bereich von Geometrien, die in den geschnittenen Blattknoten identifiziert wurden, dem SM 132 zur weiteren Verarbeitung bereitzustellen. Beispielsweise kann der SM 132 selbst bestimmen, ob die identifizierten Primitive von dem Strahl geschnitten werden, auf der Grundlage der Informationen, die die TTU 138 als ein Ergebnis der Traversierung der BVH durch die TTU liefert. Um diese Verarbeitung aus dem SM 132 auszulagern und dadurch zu beschleunigen, unter Verwendung der Hardware der TTU 138, kann der Stackverwaltungsblock 740 Anforderungen an den Strahl-Primitiv- und Transformations-Block 720 ausgeben, um einen Strahl-Primitiv-Test für die Primitive innerhalb der vom Strahlen-Complet-Testblock 710 der TTU identifizierten geschnittenen Blattknoten durchzuführen. In einigen Ausführungsformen kann der SM 132 eine Anforderung für den Strahl-Primitiv-Test ausgeben, um einen bestimmten Bereich des Primitiv- und Transformations-Blocks 720 zu testen, unabhängig davon, wie dieser Geometriebereich identifiziert wurde.
• Nachdem er sich vergewissert hat, dass die für einen angeforderten Strahl-Primitiv-Test benötigten Primitivdaten im Primitiv-Cache 754 verfügbar sind, kann der Strahl-Primitiv- und Transformations-Block 720 Primitive bestimmen, die von dem Strahl geschnitten werden, indem er die im Strahlverwaltungsblock 730 gespeicherten Strahlinformationen verwendet. Der Strahl-Primitiv-Test-Block 720 stellt die Identifizierung der Primitive, die von dem Strahl geschnitten werden, für den Schnittpunktverwaltungsblock 722 bereit.
• Der Schnittpunktverwaltungsblock 722 kann die Ergebnisse des Strahl-Primitiv-Tests an den SM 132 zurückgeben. Die Ergebnisse des Strahl-Primitiv-Tests können Identifizierer der geschnittenen Primitive, den Abstand der Schnittpunkte vom Strahlursprung und andere Informationen über Eigenschaften der geschnittenen Primitive enthalten. In einigen Ausführungsformen kann der Schnittpunktverwaltungsblock 722 einen bestehenden Strahl-Primitiv-Test (z.B. durch Modifizieren der Länge des Strahls) auf der Grundlage früherer Schnittpunktergebnisse aus dem Strahl-Primitiv-Test-Block 720 modifizieren.
• Der Schnittpunktverwaltungsblock 722 kann auch verschiedene Arten von Primitiven nachverfolgen. Die verschiedenen Arten von Dreiecken beinhalten beispielsweise opake Dreiecke, die einen Strahl blockieren werden, wenn sie geschnitten werden, und Alpha-Dreiecke, die den Strahl blockieren können oder nicht, wenn sie geschnitten werden, oder die eine zusätzliche Behandlung durch den SM erfordern können. Ob ein Strahl durch ein transparentes Dreieck blockiert wird oder nicht, kann beispielsweise von einer oder mehreren, auf das Dreieck abgebildeten Textur(en), der von der Textur eingenommenen Fläche des Dreiecks und der Art und Weise, wie die Textur das Dreieck modifiziert, abhängen. Zum Beispiel erfordert Transparenz (z.B. Buntglas) in einigen Ausführungsformen, dass der SM 132 die Treffer von transparenten Objekten nachverfolgt, so dass diese in strahlparametrischer Reihenfolge sortiert und schattiert werden können, und in der Regel den Strahl nicht tatsächlich blockieren. Indessen ermöglicht Alpha-„Trimming“ das Trimmen der Form des Primitivs auf der Grundlage der Form einer auf das Primitiv gemappten Textur - zum Beispiel das Ausschneiden einer Blattform aus einem Dreieck. (Es wird angemerkt, dass in der Rastergrafik Transparenz oft als „Alpha-Blending“ und Trimmen als „Alpha-Test“ bezeichnet wird). In anderen Ausführungsformen kann die TTU 138 transparente Treffer zur späteren Behandlung durch den SM 132 in Warteschlangen im Speicher schieben und getrimmte Dreiecke direkt behandeln, indem sie Anfragen an die Textureinheit sendet. Jedes Dreieck kann einen Bezeichner zum Angeben des Dreieckstyps enthalten. Der Schnittpunktverwaltungsblock 722 ist dazu konfiguriert, eine Ergebniswarteschlange zur Nachverfolgung der verschiedenen Arten von geschnittenen Dreiecken zu unterhalten. Beispielsweise kann die Ergebniswarteschlange einen oder mehrere Identifizierer für geschnittene opake Dreiecke in einer Warteschlange und einen oder mehrere Identifizierer für transparente Dreiecke in einer anderen Warteschlange speichern.
• Bei opaken Dreiecken kann der Strahlschnittpunkt für weniger komplexe Geometrien vollständig in der TTU 138 bestimmt werden, weil die Fläche des opaken Dreiecks den Strahl daran hindert, die Oberfläche des Dreiecks zu passieren. Bei transparenten Dreiecken können Strahlschnittpunkte in einigen Ausführungsformen nicht vollständig in der TTU 138 bestimmt werden, weil die TTU 138 den Schnittpunkttest auf der Grundlage der Geometrie des Dreiecks durchführt und möglicherweise keinen Zugriff auf die Textur des Dreiecks und/oder den von der Textur eingenommenen Bereich des Dreiecks hat (in anderen Ausführungsformen kann die TTU vom 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 Transformations-Block 720 als geschnitten bestimmt, an den SM 132 gesendet werden, damit der SM vollständig bestimmen kann, ob das Dreieck die Sichtbarkeit entlang des Strahls beeinflusst.
• Der SM 132 kann auflösen, ob der Strahl eine dem transparenten Dreieck zugeordnete Textur schneidet und/oder ob der Strahl von der Textur blockiert wird. Der SM 132 kann in einigen Fällen basierend auf dieser Bestimmung eine modifizierte Abfrage an die TTU 138 senden (z.B. Verkürzung des Strahls, falls der Strahl durch die Textur blockiert wird). In einer Ausführungsform kann die TTU 138 dazu konfiguriert sein, alle Dreiecke, bei denen bestimmt wurde, dass sie den Strahl schneiden, zur weiteren Verarbeitung an den SM 132 zurückgeben. Weil die Rückgabe jedes Dreiecksschnittpunkts an den SM 132 zur weiteren Verarbeitung in Bezug auf Schnittstellen- und die Thread-Synchronisierung kostspielig ist, kann die TTU 138 dazu konfiguriert sein, Dreiecke auszublenden, die zwar geschnitten werden, aber nachweislich ohne funktionale Auswirkungen auf die resultierende Szene ausgeblendet werden können. Da der TTU 138 beispielsweise Informationen über den Dreieckstyp zur Verfügung stehen (z. B. ob ein Dreieck opak oder transparent ist), kann die TTU 138 die Informationen über den Dreieckstyp 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 aufgenommen werden müssen, da sie die Sichtbarkeit entlang des Strahls nicht beeinflussen werden.
• Falls die TTU 138 weiß, dass ein Dreieck entlang des Strahls von einem opaken Dreieck verdeckt wird, kann das verdeckte Dreieck aus den Ergebnissen ausgeblendet werden, ohne dass dies Auswirkungen auf die Visualisierung der resultierenden Szene hat.
• Der Schnittpunktverwaltungsblock 722 kann eine Ergebniswarteschlange zum Speichern von Treffern enthalten, die eine Dreiecks-ID und Informationen über den Punkt, an dem der Strahl das Dreieck getroffen hat, assoziieren. Wenn bestimmt wird, dass ein Strahl ein opakes Dreieck schneidet, können die Identität des Dreiecks und der Abstand des Schnittpunkts vom Strahlursprung in der Ergebniswarteschlange gespeichert werden. Falls der Strahl dazu bestimmt ist, ein anderes opakes Dreieck zu schneiden, kann das andere geschnittene opake Dreieck aus dem Ergebnis ausgelassen werden, falls der Abstand des Schnittpunkts vom Strahlursprung größer ist als der bereits in der Ergebniswarteschlange gespeicherte Abstand des geschnittenen opaken Dreiecks. Falls der Abstand des Schnittpunkts vom Strahlursprung kleiner als der Abstand des bereits in der Ergebniswarteschlange gespeicherten, geschnittenen, opaken Dreiecks ist, kann das andere geschnittene opake Dreieck das in der Ergebniswarteschlange gespeicherte opake Dreieck ersetzen. Nachdem alle Dreiecke einer Abfrage getestet worden sind, können die in der Ergebniswarteschlange gespeicherten Informationen über opake Dreiecke und die Schnittpunktinformationen an den SM 132 gesendet werden.
• In einigen Ausführungsformen kann der Schnittpunktverwaltungsblock 722, sobald ein opakes Dreieck identifiziert ist, den im Strahlverwaltungsblock 730 gespeicherten Strahl verkürzen, so dass Begrenzungsvolumen (die Dreiecke enthalten können) 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 auflösen kann, ob der Strahl eine dem Dreieck zugeordnete Textur schneidet oder nicht und/oder ob die Textur den Strahl blockiert. Der SM kann die Ergebnisse dieser Bestimmung an die TTU 138 zurückgeben und/oder die Abfrage auf der Grundlage dieser Bestimmung modifizieren (z.B. den Strahl verkürzen, falls der Strahl durch die Textur blockiert wird).
• Wie vorstehend diskutiert, ermöglicht die TTU 138 ein schnelles Traversieren 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. Die TTU 138 kann zum Beispiel bestimmen, welche Dreiecke in der Beschleunigungsdatenstruktur von dem Strahl geschnitten werden, und die Ergebnisse an den SM 132 zurückgeben. Die Rückgabe eines Ergebnisses für jeden Dreiecksschnittpunkt an den SM 132 ist jedoch hinsichtlich der Schnittstelle und der Thread-Synchronisierung kostspielig. Die TTU 138 stellt eine Hardware-Logik bereit, die dazu konfiguriert ist, diejenigen Elemente oder Dreiecke auszublenden, die nachweislich ohne funktionale Auswirkungen auf die resultierende Szene ausgeblendet werden können. Die Verringerung an Rückgaben von Ergebnissen an den SM und an Synchronisationsschritten zwischen Threads verbessert die Gesamtleistung der Traversierung erheblich. Die in dieser Anwendung offenbarten, beispielhaften, nicht beschränkenden Ausführungsformen der TTU 138 sehen vor, dass einige der Schnittpunkte innerhalb der TTU 138 ohne Eingreifen des SM 132 verworfen werden können, so dass weniger Schnittpunkte an den SM 132 zurückgegeben werden und der SM 132 nicht alle geschnittenen Dreiecke oder Elementbereiche inspizieren muss.
• Vorzeitige Freigabe von TTU-Ressourcen
• Wie vorstehend diskutiert, verarbeitet die TTU 138 Strahlsichtbarkeitsabfragen, die von dem SM 132 ausgegeben werden. Die TTU 138 führt Strahlsichtbarkeitsabfragen im Namen eines Warp durch. Jeder Warp umfasst eine Gruppe von Threads (z.B. 32 Threads in einem Warp), von denen jeder eine unabhängige Strahlabfrage starten kann. In der TTU 138 wird dem Warp ein Ticket zugewiesen, und jedem Thread werden in der TTU 138 Ressourcen zugewiesen. Die Ressourcen der TTU 138 können Ausführungsplätze (so genannte Strahl-Slots, bei denen es sich um Speicher oder Register handeln kann) zur Speicherung von Zwischen- und/oder Endergebnissen der Testung umfassen. Ein Strahl-Slot kann Komponenten enthalten, die über verschiedene Verarbeitungseinheiten der TTU 138 verteilt sind. Es steht der TTU 138 frei, die zugewiesenen Ressourcen in beliebiger Reihenfolge zu bearbeiten. Die Rückgabe der Ergebnisse an den SM 132 wird für ein Ticket synchronisiert.
• Ein Leistungsproblem besteht darin, dass Strahlabfragen sehr unterschiedlich komplex sein können, wobei einige kurz sind und andere sehr viel mehr Zeit in Anspruch nehmen. Beispielsweise kann eine Strahlabfrage länger dauern, weil die für die Abfrage benötigten Daten aus dem Speicher außerhalb der TTU 138 abgerufen werden müssen, während sich die für eine andere Abfrage benötigten Daten im Level-Zero (L0)-Cache 750 innerhalb der TTU 138 befinden. In einem anderen Beispiel kann die Anzahl der Primitive, die in jeder Abfrage getestet und abgerufen werden müssen, unterschiedlich sein. In anderen Beispielen beeinflussen die für den Strahl eingestellten Parameter, die festlegen, welche Testergebnisse zurückgegeben werden sollen, die Zeit, die für den Abschluss der Abfrage benötigt wird.
• Da die Ergebnisse für Tickets in Gruppen zurückgegeben werden, müssen alle kurzen Traversierungen innerhalb eines Tickets warten, bis die längsten Traversierungen abgeschlossen sind. Während des Wartens verbrauchen diese Strahlen TTU 138-Speicherressourcen (z. B. Strahl-Slots), die dann nicht für die aktive Traversierung verwendet werden. Die Leistung kann verbessert werden, wenn die Anzahl der Strahl-Slots erhöht wird, aber Strahl-Slots sind eine teure Ressource in der TTU 138, da sie viel Platz auf einem Chip einnehmen. Dementsprechend besteht die Notwendigkeit, die Anzahl der Strahl-Slots in der TTU zu minimieren und gleichzeitig die verfügbaren Strahl-Slots effizient zu nutzen.
• Die frühzeitige Strahlrückgabe ermöglicht die Strahlergebnisrückgabe, wobei der Strahl-Slot in der TTU 138 freigegeben wird, bevor der gesamte Warp zur Rückgabe bzw. Rückkehr bereit ist. Beispiele für ein Prozessor- und Coprozessor-System, das eine frühzeitige Strahlrückgabe ermöglicht, sind in der parallel anhängigen US-Anmeldung Nr. 16/101,247 mit dem Titel „Robust, Efficient multiprocessor-coprocessor interface “ beschrieben, die hiermit durch Bezugnahme vollumfänglich einbezogen wird. 8A und 8B zeigen das von der TTU 138 (einem Coprozessor) ausgegebene Ergebnis für eine Gruppe von 16 Threads, die für eine gesamte Gruppe und in Gruppen von 4 Threads an SM-Register zurückgegeben wird, wodurch die jeweiligen Ausführungs-Slots, die auf der TTU 138 für die jeweiligen Threads der Gruppe reserviert sind, frei werden, wenn der Strahl-Schnittpunkt-Test für jeden jeweiligen Thread abgeschlossen ist. Wie in 8A dargestellt, bleiben dann, wenn die gesamte Gruppe von 16 Threads gleichzeitig Ergebnisse in Multiprozessorregister schreibt, die TTU-Ressourcen (z. B. Strahl-Slots), die von jedem der 16 Threads verwendet werden, belegt, und bleiben alle Registerdateien in dem Multiprozessor, selbst wenn sie allokiert sind, ungenutzt. Demgegenüber dazu zeigt 8B, dass die Gruppe der 16 Threads die Ergebnisse in Gruppen von 4 Threads an die SM-Register zurückgeben kann. Die zeitlich gestaffelte Rückgabe von Ergebnissen, wenn jede Untergruppe von Threads ihre Verarbeitung in der TTU 138 abschließt, verbessert die Auslastung der bereits allokierten Register in dem SM 132 und gibt gleichzeitig wertvolle Ressourcen der TTU 138 schneller frei, wenn die jeweiligen Untergruppen der Threads ihre jeweilige Nutzung der TTU 138 beenden. Die Granularität der frühzeitigen Strahlrückgabe ist programmierbar. Die frühzeitige Freigabe von TTU-Ressourcen ermöglicht es, dass Strahl-Slots früher von anderen Abfragen genutzt werden können, wodurch die Gesamtauslastung der TTU 138 erhöht wird.
• Allerdings verbraucht jede Rückgabe von Ergebnissen Registerdatei (RF)-Bandbreite für einen ganzen Warp. Das bedeutet, dass ein Kompromiss zwischen der Freigabe von Strahl-Slots in der TTU 138 und dem Verbrauch von RF-Bandbreite gefunden werden muss, um zu verhindern, dass beides zu einem Engpass führt. Wo dieses Gleichgewicht liegt, ist unterschiedlich (z.B. abhängig von den spezifischen Abfragen, die gestellt werden), aber in einigen Beispielen wird es typischerweise bei größeren Granularitäten wie 16 (die Hälfte eines vollen Warps) oder 8 (ein Viertel eines vollen Warps) liegen. Es ist unwahrscheinlich, dass es sich dabei um das Extrem eines einzelnen Threads handelt. Selbst innerhalb dieser kleineren Gruppe von 8 oder 16 gibt es immer noch Unterschiede in der Traversierungslänge, die dazu führen können, dass kürzere Strahlen länger als erwünscht Strahl-Slot-Ressourcen verbrauchen.
• Beispiele der vorliegenden Offenbarung stellen Systeme und Verfahren bereit zur weiteren Freigabe von Ausführungsressourcen in der TTU 138, während auf den Abschluss anderer Abfragen gewartet wird. In einigen Beispielen kann die vorliegende Offenbarung weiter Ausführungsressourcen in der TTU 138 freigeben, ohne die Granularität der frühen Strahlrückgabe weiter zu verringern. Dementsprechend können in einigen Beispielen die Granularitäten der frühen Strahlrückgabe beibehalten oder erhöht werden (z. B. Granularitäten von 16 (die Hälfte eines vollen Warps) oder 8 (ein Viertel eines vollen Warps)), um den Verbrauch von RF-Bandbreite zu begrenzen. Beispiele der vorliegenden Offenbarung stellen eine Schnittstelle zwischen einem SM 132 und einer TTU 138 bereit, die dazu konfiguriert ist, Ausführungsressourcen in der TTU 132 freizugeben, so dass der SM 132 und die TTU 138 die Schnitttestung einer großen Anzahl von Strahlen durchführen können. Die Schnittstelle ermöglicht es, zumindest einige der Abfrageergebnisse in einem komprimierten Format zu speichern und Abfrageergebnisse auf der Grundlage der komprimierten Daten zu erzeugen, wenn die Abfrageergebnisse gemeldet werden.
• Beispielhafte Multiprozessor/TTU-Schnittstelle
• 9 zeigt ein System 900 mit einer Schnittstelle 160 zwischen einem SM 132 und einer TTU 138. In einigen Beispielen kann der SM 132 ein anderer Prozessor und die TTU 138 ein anderer Coprozessor sein. Während die Schnittstelle 160 als Teil der TTU 138 dargestellt ist, kann in einigen Beispielen die Schnittstelle 160 oder eine oder mehrere Komponenten der Schnittstelle 160 außerhalb der TTU 138 angeordnet sein.
• Der SM 132 und die TTU 138 können über die Schnittstelle 160 miteinander kommunizieren und beide können Zugriff auf einen gemeinsamen bzw. gemeinsam genutzten Speicher 140 haben. Der gemeinsam genutzte Speicher 140 befindet sich zwar wie dargestellt außerhalb des SM 132 und der TTU 138, ist aber nicht darauf beschränkt. In einigen Ausführungsformen kann der gemeinsame Speicher 140 ein Cache-Speicher (z. B. der L0/L1 -Cache der TTU 138) oder ein anderer Speicher sein, auf den die TTU 138 nur lesend zugreifen kann. Der gemeinsame Speicher 140 kann Speicherplätze enthalten, die für den Datenaustausch zwischen dem SM 132 und der TTU 138 verwendet werden.
• Der SM 132 ist dazu konfiguriert, mehrere Threads gleichzeitig auszuführen, und kann ferner dazu konfiguriert sein, der TTU 138 zu befehlen, eine oder mehrere TTU-Operationen durchzuführen, um die Verarbeitung eines oder einer Gruppe der mehreren Threads zu beschleunigen, die für die gleichzeitige Ausführung vorgesehen sind. Der SM 132 kann einen Warp für Sichtbarkeitstests von Strahlen gegen eine Szene ausgeben. Jeder Thread eines Warps kann eine andere Strahl-Schnittpunkt-Abfrage enthalten.
• Wenn die TTU 138 die Warp-Anforderung erhält, bestimmt ein Planer bzw. Scheduler in der Schnittstelle 160, ob Ressourcen für die Verarbeitung der Abfragen der Threads in dem Warp verfügbar sind. Die Ressourcen, die für die Verarbeitung der Abfragen benötigt werden, beinhalten Strahl-Slots (Speicher oder Register) zur Speicherung von Strahlinformationen und Zwischen- und/oder Endergebnissen der Testung. Falls der Warp 32 Threads umfasst, wobei jeder Thread eine Strahl-Schnittpunkt-Abfrage enthält, wird muss die TTU 138 32 Strahl-Slots allokieren müssen. Der Planer 160 stellt ein Ticket für den Warp aus und startet die Abfragen, sobald die Strahl-Slots für jeden der Threads, die eine Abfrage enthalten, verfügbar werden. Falls die Strahl-Slots nicht verfügbar sind, wartet die TTU 138, bis andere Abfragen abgeschlossen sind und Strahl-Slots für den Warp verfügbar werden.
• Nachdem die TTU 138 für jede der Abfragen in dem Warp die Schnittpunkttestergebnisse erhalten hat, werden die Testergebnisse in die Registerdateien in dem SM 132 zurückgegeben. Wie vorstehend diskutiert, kann die Schnittstelle 160 dazu konfiguriert sein, Ergebnisse der Strahlschnitte frühzeitig zurückzugeben, bevor der gesamte Warp zur Rückgabe bereit ist, weil einige der Abfragen länger dauern können. Das frühzeitige Zurückgeben der Strahlenschnittergebnisse gibt in der TTU 138 Strahl-Slots frei, die von anderen Warps früher genutzt werden können (d.h. vor Abschluss der gesamten Warps), verbraucht aber während der teilweisen Rückgabe RF-Bandbreite für einen ganzen Warp. Bei vorzeitiger Rückgabe von Strahlschnittergebnissen läuft das Ticket für den Warp weiter, bis alle Abfragen für das Ticket abgeschlossen sind. Wenn für den nächsten Warp genügend Strahl-Slots verfügbar werden, stellt der Planer ein weiteres Ticket für Abfragen im nächsten Warp aus.
• Ein Scoreboard wird verwendet, um dem SM 132 mitzuteilen, wenn eine Soll- bzw. Zieloperation (z.B. ein voller oder ein partieller Warp) ihre Ergebnisausgabe abschließt und die Ergebnisse in die für den Warp allokierten SM-Register geschrieben werden. Das Scoreboard verfolgt die zurückgegebenen Ergebnisse und zeigt dem SM 132 an, wann andere Befehle die zurückgegebenen Ergebnisse sicher verbrauchen können. Beispiele für die Nutzung eines Scoreboard zur Verfolgung der zurückgegebenen Ergebnisse sind in der parallel anhängigen US-Anmeldung Nr. 16/101,247 mit dem Titel „Robust, Efficient multiprocessor-coprocessor interface “ beschrieben, die hiermit durch Bezugnahme vollumfänglich einbezogen wird.
• Ausführungsformen dieser Offenbarung stellen Techniken bereit zur früheren Freigabe von Strahl-Slots (z.B. bevor andere Ergebnisse an den SM 132 gemeldet werden), so dass andere Tickets und Abfragen gestartet werden können, sobald Strahl-Slots für das nächste Ticket verfügbar sind. Beispielhafte Ausführungsformen für die Freigabe von Strahl-Slots ermöglichen es der TTU 138, die Anzahl der laufenden Abfragen in der TTU 138 zu maximieren.
• Die Informationen in den an den SM 132 zurückgegebenen Ergebnissen hängen von den in der Abfrage angeforderten Informationen ab (z.B. verschiedene Strahl-Flags, die Einzelheiten der Abfrage beschreiben). Ein Teil des Abfrage-Setups besteht darin, zu bestimmen, welche Informationen zurückgegeben werden müssen. Die zurückgegebenen Ergebnisse können Trefferinformationen, einen Zeiger auf das getroffene Objekt, Informationen über die getroffene Instanz, andere Strahlinformationen und Traversierungs-Stacks zur Fortsetzung der Traversierung bei Bedarf beinhalten.
• Typischerweise involviert eine Rückgabe an den SM 132 Lesevorgänge aus den RAMs in der Schnittpunktverwaltungseinheit 722, der Strahlverwaltungseinheit 730 und/oder der Stackverwaltungseinheit 740, um die Felder der Rückgabedaten auszufüllen. Während in 9 eine einzelne Schnittpunktverwaltungseinheit 722, Strahlverwaltungseinheit 730 und Stackverwaltungseinheit 740 dargestellt sind, sind Beispiele dieser Offenbarung nicht derart beschränkt und können eine Vielzahl von einer oder mehreren dieser Einheiten beinhalten. Dementsprechend kann eine Rückgabe an den SM 132 Leseergebnisse von einer einzelnen oder einer Vielzahl von Schnittpunktverwaltungseinheiten, Strahlverwaltungseinheiten und/oder Stackverwaltungseinheiten beinhalten.
• 9 zeigt die Schnittpunktverwaltungseinheit 722, die Strahlverwaltungseinheit 730 und die Stackverwaltungseinheit 740 einschließlich der Strahl-Slots, die der jeweiligen Verarbeitungseinheit zugeordnet sind. In einigen Beispielen kann jede der Verarbeitungseinheiten über ihren eigenen dedizierten Speicher verfügen, der für die Abfragen zugewiesen werden kann. In anderen Beispielen kann ein und derselbe Speicher aufgeteilt sein, um die jeweiligen Strahl-Slots für jede der Verarbeitungseinheiten bereitzustellen. In einigen Beispielen können die Strahl-Slots in einem gemeinsamen Cache-Speicher bereitgestellt sein.
• Nachdem die Verarbeitung der Abfrage abgeschlossen ist, ist die Schnittstelle 160 dazu konfiguriert, Informationen für die Testergebnisse (z. B. Trefferinformationen, einen Zeiger auf was auch immer getroffen wurde, Informationen über die Instanz, unter der es getroffen wurde, andere Strahleninformationen und Traversierungs-Stacks, um die Traversierung erforderlichenfalls fortzusetzen) von verschiedenen Stellen in der TTU 138 zu empfangen und die Informationen an den SM 132 weiterzuleiten. Die Informationen werden von den verschiedenen Stellen in der TTU 138 empfangen, wenn die Ergebnisse an den SM 132 zurückgegeben werden. Beispielsweise können die Informationen zu den Testergebnissen in der Schnittpunktverwaltungseinheit 722, der Strahlverwaltungseinheit 730 und/oder der Stackverwaltungseinheit 740 gespeichert werden. Bis die Informationen an den SM 132 zurückgegeben werden, werden sie an den verschiedenen Orten in der TTU 138 gespeichert. Wie vorstehend beschrieben, werden die Testergebnisdaten auf der Grundlage des Abschlusses anderer Abfragen (z.B. Abfragen für eine vorbestimmte Anzahl von Threads) desselben Warps zurückgegeben.
• 10A-10D zeigen Beispiele von Daten, die an den SM 132 zurückgegeben werden können. Die Trefferdaten (die weiter unten unter Bezugnahme auf 12A-12H näher diskutiert werden) können Daten sein, die von der Schnittpunktverwaltungseinheit 722, der Stackverwaltungseinheit 740 zurückgegeben oder von der Schnittstelle 160 erzeugt wurden. Die Parameter des getroffenen Dreiecks und die Daten der Trefferinstanz (gezeigt in 10A) werden von der Schnittpunktverwaltungseinheit 722 zurückgegeben. Die Stack-Daten (gezeigt in 10B) werden von der Stackverwaltungseinheit 740 zurückgegeben. Die transformierten Strahldaten (gezeigt in 10C) und Trifetch 0-2 Daten (gezeigt in 10D) werden von der Strahlverwaltungseinheit 730 zurückgegeben. Die Trifetch-3-Daten (gezeigt in 10D), die angeben, wo sich die Abfrage in der Traversierung von Abrufdreiecken befindet, werden von der Stackverwaltungseinheit 740 zurückgegeben.
• Die in den verschiedenen Einheiten der TTU 138 gespeicherten Ergebnisdaten belegen den Speicher in jeder jeweiligen Einheit, bis die Daten an den SM 132 zurückgegeben werden. In einem Beispiel kann jede der Strahlverwaltungseinheit 730, der Stackverwaltungseinheit 740 und der Schnittpunktverwaltungseinheit 722 für jede Abfrage eine andere vorbestimmte Anzahl von Bits allokiert haben.
• Vorzeitige Freigabe von Ressourcen ohne Meldung an den SM
• Beispiele der vorliegenden Offenbarung sehen vor, dass die zugewiesenen Strahl-Slots in den verschiedenen Einheiten der TTU 138 freigegeben werden, bevor die Daten an den SM 132 zurückgegeben werden, indem eine komprimierte Version der Ergebnisse (z.B. in der Schnittstelle 160) gespeichert wird, bis die Ergebnisse an den SM 132 zurückgegeben werden. Die Ergebnisse werden von der Schnittstelle 160 auf der Grundlage der komprimierten Informationen erzeugt, wenn die Daten an den SM 132 zurückgegeben werden. Dies ist in Situationen möglich, in denen die zurückzugebenden Daten bestimmte Ergebnisse anzeigen. Beispiele dafür, wann die Ressourcen in der TTU 138 freigegeben werden können, ohne dass die Ergebnisse an den SM 132 zurückgegeben werden, werden im Folgenden erläutert.
• Im Fall einer negativen Abfrage, bei der festgestellt wird, dass ein Strahl nichts schneidet, sind die Rückgabewerte für alle Informationen a priori bekannt. Wenn beispielsweise in der Abfrage festgestellt wird, dass der Strahl nichts schneidet, sind Trefferinformationen, ein Zeiger auf den getroffenen Gegenstand, Informationen über die Instanz, unter der er getroffen wurde, und andere Strahlinformationen bekannt. Das bedeutet, dass dann, wenn ein Strahl sowohl einen Fehltreffer bzw. Miss liefert als auch beendet wird, die Werte (die in den 10A-10D gezeigten Daten), die für diesen Strahl an den Stellen der TTU 138 gespeichert sind und zur Bildung der Rückgabepakete gelesen werden, deterministisch sind. Der Begriff „beendet“ bedeutet hier, dass für diesen Strahl keine weiteren Aktionen mehr durchgeführt werden müssen, was durch einen leeren Traversierungs-Stack angezeigt wird.
• Wenn ein Strahl in der Abfrage nichts schneidet, kann die Schnittstelle 160 die Information, die ein Verfehlen anzeigt, für die Abfrage speichern (was durch ein einzelnes Bit angezeigt werden kann), und können die für die Abfrage zugewiesenen Ressourcen in der TTU 138 zur Verwendung durch andere Tickets und Abfragen freigegeben werden. Wenn die Ergebnisse an den SM 132 zurückgegeben werden, erzeugt die Schnittstelle 160 die Daten, die aus den Ressourcen über die TTU 138 hinweg gelesen worden wären, basierend auf den Informationen in der Schnittstelle 160, die ein Verfehlen für die Abfrage anzeigen. Die Informationen müssen erzeugt und an den SM 132 zurückgegeben werden, weil der SM 132 erwartet, dass die Register in dem SM mit den Ergebnisdaten gefüllt werden, was in diesem Fall ein Verfehlen bedeuten würde.
• Der Mechanismus der frühzeitigen Strahlfreigabe ist im Grunde ein Komprimierungsverfahren, bei dem für einige bestimmte Fälle der gesamte Strahlspeicher auf ein einziges Bit komprimiert wird. Dieses einzelne Bit pro Thread kann in dem Ticket gespeichert werden, um anzuzeigen, ob ein Strahl-Slot vor der Rückgabe der Ergebnisse freigegeben wurde. Jeder Strahl-Slot, der ein Verfehlen zurückgeben soll und beendet wird, wird sofort freigegeben, und das Bit wird für diesen Thread im Ticket gesetzt. Später, wenn Ergebnisse für dieses Ticket zurückgegeben werden, werden die korrekten Werte rekonstruiert. Die Rekonstruktion kann von der Schnittstelle 160 durchgeführt werden. Der nicht komprimierte Speicher kann mehr als 1000 Bits in der Strahlverwaltungseinheit 730, der Stackverwaltungseinheit 740 und der Schnittpunktverwaltungseinheit 722 verbrauchen. Das ergibt ein Kompressionsverhältnis von mehr als 1000:1.
• Im Falle einer frühzeitigen Freigabe des Strahl-Slots wird die Schnittstelle 160 nicht aus der Strahlverwaltungseinheit bzw. RMU, der Schnittpunktverwaltungseinheit bzw. IMU oder der Stackverwaltungseinheit bzw. SMU lesen. Stattdessen generiert sie die korrekten Werte für jede angeforderte Rückgabe selbst. Die erzeugten Daten können in einigen Beispielen von der Schnittstelle 160 vorgespeichert werden und/oder Logik in der Schnittstelle 160 kann die Daten auf der Grundlage der komprimierten Version der Ergebnisse erzeugen.
• Die Möglichkeit, TTU-Ressourcen freizugeben, ohne die Ergebnisse an den SM 132 zurückzugeben, ist nicht nur auf Fehlabfragen beschränkt, sondern kann immer dann genutzt werden, wenn Rückgabewerte von vornherein bekannt sind. Einige dieser Situationen hängen von den Abfrageparametern ab, wie z.B. Strahl-Flags oder Modus-Flags für den Strahl.
• Einige Sichtbarkeitstests interessieren sich beispielsweise nur dafür, ob etwas getroffen wurde, und nicht dafür, was genau getroffen wurde. Diese Art von Abfragen kann als „Strahl mit beliebigem Treffer“ bzw. „any hit ray“ bezeichnet werden. Ein Anwendungsbeispiel sind Schattenstrahlen, die prüfen, ob ein Punkt im Raum für eine bestimmte Lichtquelle im Schatten oder im Licht liegt. Bei diesem Test versucht die Abfrage nicht, das nächstgelegene geschnittene Primitiv zu identifizieren, sondern ob es mindestens einen Primitivschnitt gibt, ohne Rücksicht auf den Ort des Schnittpunkts (z.B. die parametrische Länge des Schnittpunkts) oder welches Primitiv als von dem Strahl geschnitten bestimmt wurde.
• Diese Arten von Rückgaben können auch a priori bekannte Rückgabewerte haben. In einer möglichen Implementierung könnte ein TerminateOnAnyHit-Flag dieses Verhalten steuern, aber dies gibt immer noch das Dreieck zurück, das getroffen wurde und den Abbruch verursacht hat. Während dieser Treffer zwar nicht unbedingt das nächstgelegene Dreieck ist, kann in einigen Algorithmen als Näherungswert immer noch nützlich sein.
• In dem Fall, in dem nicht benötigt wird, welches Dreieck getroffen wurde, fügen die Beispiele der vorliegenden Offenbarung ein neues Strahlen-Flag-Bit „tu“ hinzu, das dasselbe Beenden-bei-jedem-Treffer-Verhalten ermöglicht, ohne jedoch zurückzugeben, was auch immer getroffen wurde. 11 zeigt ein Beispiel für Strahlinformationen, die von dem SM 132 für einen Thread bereitgestellt werden können. Die Strahlinformationen können beinhalten, wie die Traversierung durchgeführt wird und wie Trefferinformationen zu behandeln sind. Die Strahlinformationen können ein „t“-Bit für die Beendigung bei jedem beliebigen Treffer und ein „tu“-Bit für das Beendigungsverhalten bei jedem beliebigen Treffer, jedoch ohne Rückgabe dessen, was getroffen wurde, beinhalten. Wenn das Strahl-Glag-Bit „tu“ gesetzt ist, kann die Abfrage beendet werden, wenn nach dem Testen jedes in der Abfrage identifizierten Primitivs kein Treffer festgestellt wurde oder wenn ein erster Treffer identifiziert wird. Die Rückgabedaten für beide Ergebnisse sind a priori bekannt und können von der Schnittstelle 160 erzeugt werden, wenn die Ergebnisse an den SM 132 zurückgegeben werden. Demgemäß werden dann, wenn das Strahl-Flag-Bit „tu“ gesetzt ist, die für die Abfrage allokierten Ressourcen freigegeben, wenn nach dem Testen jedes Primitivs in der Abfrage kein Treffer festgestellt ist oder wenn ein erster Treffer ermittelt wird. Ein weiteres Bit kann im Ticket gespeichert werden, um einen Frühzeitige-Strahl-Freigabe-Schattentreffer gegenüber einem Frühzeitige-Strahl-Freigabe-Verfehlen anzuzeigen.
• Datenstrukturen für verschiedene Treffertypen
• 12A-12H zeigen Beispiele von Treffertypdaten, die von der IMU 722 abgerufen oder von der Schnittstelle 160 auf der Grundlage von komprimierten Daten, die Abfrageergebnisse anzeigen (z.B. kein Treffer oder Treffer beliebigen Typs), erzeugt werden können. Die Treffertypdaten können als Teil der in den 10 dargestellten „Treffer“-Daten bereitgestellt sein. Die Treffertypdaten werden dem SM 132 zur Verfügung gestellt, wenn die Warp-Ergebnisse an den SM 132 zurückgegeben werden. In einigen Beispielen kann jeder der in 12A-12H gezeigten Datenblöcke die gleiche Größe haben.
• 12A zeigt ein Beispiel von Daten, die von der IMU 722 zur Anzeige eines Treffers und zur Bereitstellung von Schnittpunktinformationen bereitgestellt werden können. Die Informationen beinhalten Dreieck-ID, Schnittpunktinformationen (z.B. parametrische Länge und/oder baryzentrische Koordinaten des Schnittpunkts), ob das Dreieck nach vorne oder nach hinten zeigt und ob das Dreieck ein opaked Dreieck oder ein Alpha-Dreieck ist.
  12B zeigt ein Beispiel von Daten, die von der Schnittstelle 160 erzeugt werden können, um einen Treffer anzuzeigen, ohne jedoch Einzelheiten über den Treffer zu liefern. Diese Datenstruktur kann für eine Schattentrefferabfrage erzeugt werden. Wenn die Daten an den SM 132 zurückgegeben werden, können alle anderen Felder, einschließlich HitTrianglePtr und Hitlnstance, mit Null gefüllt werden.
  12C zeigt ein Beispiel von Daten, die von der IMU 722 bereitgestellt werden können, um einen Knotentreffer anzuzeigen.
  12D zeigt ein Beispiel von Daten, die von der IMU 722 geliefert werden können, um einen Treffer im Dreieckbereich anzuzeigen.
  12E zeigt ein Beispiel von Daten, die von der IMU 722 bereitgestellt werden können, um einen Treffer im Elementbereich anzuzeigen.
  12F zeigt ein Beispiel von Daten, die von der IMU 722 bereitgestellt werden können, um einen Instanzknotentreffer anzuzeigen.
  12G zeigt ein Beispiel von Daten, die von der IMU 722 bereitgestellt werden können, um einen Fehler bei der Durchführung des Strahl-Schnittpunkt-Tests anzuzeigen.
  12H zeigt ein Beispiel von Daten, die von der Schnittstelle 160 erzeugt werden können, um ein Verfehlen anzuzeigen. In einem Beispiel kann der Treffertyp in 12H mit 1111 versehen werden, so dass alle für „Kein Treffertyp “ zurückgegebenen Daten Einsen sind. In einem anderen Beispiel können alle Daten für den in 12H gezeigten „Kein Treffertyp “ mit Nullen anstelle von Einsen gefüllt werden. Wenn die Daten an den SM 132 zurückgegeben werden, können alle anderen Felder mit Nullen ausgefüllt werden.
  Wie in 12A-12H gezeigt, enthält jeder unterschiedliche Treffertyp einen Typindikator, der den Typ des Treffers angibt, der zurückgegeben wird. Der Treffertyp kann durch ein oder mehrere Bits angegeben werden. In einem Beispiel kann die gleiche Anzahl von Bits für den Typindikator für eine Vielzahl der in den 12A-12H gezeigten verschiedenen Treffertypen zugewiesen werden. Wenn der SM 132 die Abfrageergebnisse pro Thread empfängt, kann die Treffertypinformation verwendet werden, um zu bestimmen, wie die zurückgegebenen Daten zu verwenden sind und welcher Teil der zurückgegebenen Daten für die Abfrage ignoriert werden kann.
• Teilweise Deallokation von TTU-Ressourcen
• Beispielhafte Ausführungsformen zerlegen Strahl-Slots in der TTU 138 in einzelne Komponenten, die unabhängig voneinander zugewiesen und freigegeben werden.
• Wie vorstehend diskutiert, können Ergebnisse einer Abfrage über verschiedene Orte hinweg in der TTU 138 gespeichert werden. In 9 können die Ergebnisse einer Abfrage in der IMU 722, der RMU 730 und/oder der SMU 740 gespeichert werden. In den vorstehenden Beispielen wird dann, wenn die in der IMU 722, der RMU 730 und der SMU 740 gespeicherten Abfrageergebnisse freigegeben und in komprimiertem Format (z.B. für eine Abfrage, die ein Verfehlen meldet bzw. berichtet) in der Schnittstelle 160 gespeichert werden, jede der einzelnen Komponenten des zugehörigen Strahl-Slots freigegeben, so dass der Strahl-Slot von einem anderen Ticket und einer anderen Abfrage verwendet werden kann. In dem nachstehend diskutierten Beispiel wird nur ein Teil (z.B. eine oder mehrere) der Komponenten des Strahl-Slots freigegeben, während eine oder mehrere andere Komponenten weiterhin Strahltestergebnisse speichern, bis die Ergebnisse der Abfrage an den SM 132 zurückgegeben werden. In diesem Beispiel wird ein Teil der Ergebnisse in einem komprimierten Format in der Schnittstelle 160 gespeichert und wird ein Teil der Ergebnisse in den Komponenten des Strahl-Slots (ohne Komprimierung) gespeichert, bis die Ergebnisse an den SM 132 zurückgegeben werden.
• Beispielsweise gibt es für Strahlen, die die Traversierung beenden, keinen realen Inhalt des Traversierungs-Stacks, der zurückzugeben ist, so dass der SMU 740-Teil des Strahl-Slots freigegeben werden kann. Während die Komponenten des Strahl-Slots in der SMU 740 freigegeben werden, kann die Komponente des Strahl-Slots in der IMU 722 und der RMU 730 beibehalten werden, bis die Ergebnisse der Abfrage an den SM 132 zurückgegeben werden. Wenn die Abfrageergebnisse zusammen mit anderen Abfrageergebnissen an den SM 132 zurückgegeben werden, liest die Schnittstelle 160 die Ergebnisse aus den Komponenten des Strahl-Slots in der IMU 722 und der RMU 730 und erzeugt die Ergebnisse, die andernfalls von der SMU 740 gelesen worden wären. In einigen Beispielen können die Felder, die von der SMU 740 abgerufen worden wären, von der Schnittstelle 160 alle mit Nullen gefüllt werden.
• In einem anderen Beispiel kann dann, wenn keine Ergebnisse von der RMU 730 benötigt werden (d.h. kein Dreieckabruf oder keine transformierte Strahlenrückgabe), kann der RMU 730-Teil des Strahl-Slots freigegeben werden. In einem anderen Beispiel benötigen Treffer, die sich nur auf dem Stack oder in der RMU 730 befinden, nicht den Speicher der IMU 722, der freigegeben werden kann.
• Das unabhängige Freigeben irgendeiner dieser Ressourcen erfordert ein Trennen ihrer Allokation bzw. Zuweisung. Alle Strahlzuweisungen beginnen mit allen Bestandteil bildenden Komponenten in der RMU 730, der IMU 722 und der SMU 740. In jeder dieser Einheiten ist eine Remap- bzw. Neuzuordnungstabelle hinzugefügt, um eine von der Schnittstelle stammende Strahl-Slot-ID mit dem physischen Strahl-Slot in jeder dieser Einheiten abzubilden. Bei der Zuweisung aktualisiert die Schnittstelle 160 jede dieser Tabellen. Beim Zugriff in der RMU 730, der IMU 722 oder der SMU 740 (z.B. wenn die Schnittpunktergebnisse an den SM 132 zurückgegeben werden) wird auf die Neuzuordnungstabelle zugegriffen, um den benötigten physischen Standort zu bestimmen. In einigen Ausführungsformen können die in den Neuzuordnungstabellen gespeicherten Informationen in der Schnittstelle 160 verwaltet werden.
• Da jedem Strahl alle Komponenten zum Start zugewiesen werden, geht es bei der Freigabe dieser Ressourcen um die Verringerung der Größe jeder dieser Einheiten (z.B. der RMU 730, der IMU 722 und/oder der SMU 740). Wären alle gleich groß, müssten sie nicht weiter verkleinert werden. Falls z.B. erwartet wird, dass nur sehr wenige Rückgaben RMU 730-Speicherplatz benötigen, kann der RMU 730-Speicherplatz reduziert werden, um die Latenzzeit zwischen dann, wenn ein Strahl endet, und dann, wenn ein Strahl an den SM 132 zurückgibt, nicht abzudecken. Oder falls beispielsweise erwartet wird, dass die meisten Abfragen ohne fortgesetzte Traversierung beendet werden und auch keine Rückgaben über die Strahleninformationen in der RMU 730 erfordern, dann könnten sowohl die SMU 740 als auch die RMU 730 kleiner dimensioniert werden, um nicht die gesamte Latenzzeit für anstehende Rückgaben abzudecken.
• Das Aufbrechen von Strahl-Slots in Komponenten für getrennte Allokation und Deallokation bedeutet, dass die Schnittstelle 160 erweitert wird, um die unabhängigen Ressourcen getrennt zu verfolgen, und dass in der RMU 730, der IMU 722 und der SMU 740 auch Neuzuordnungstabellen bereitgestellt werden. Die zusätzliche Fläche für diese Komponenten wird durch die Einsparungen bei der Fläche in den reduzierten Puffern in der RMU 730, der IMU 722 und/oder der SMU 740 ausgeglichen.
• Wie vorstehend diskutiert, empfängt die Schnittstelle 160 die Warps, gibt die Tickets aus und nachverfolgt die Strahl-Schnittpunkt-Testung, die Speicherung der Ergebnisse und die Rückgabe der Ergebnisse an den SM 132. 13A zeigt eine beispielhafte Tabelle von Daten, die von der Schnittstelle 160 nachverfolgt werden können. Für jeden Thread eines Warps kann die Schnittstelle 160 verfolgen, ob der Thread aktiv ist oder nicht, wo die Ergebnisse für den Thread gespeichert werden und ob abgeschlossene Abfragen keinen Treffer oder einen beliebigen Treffer anzeigen.
• Wie in 13A gezeigt, können ein aktiver Thread 23 und ein aktiver Thread 16 TTU-Slots (d.h. Strahl-Slots) zugewiesen und auf Slots in der RMU, der IMU und der SMU abgebildet haben. Wenn die Abfrage für einen Thread abgeschlossen ist (basierend auf den Parametereinstellungen des Strahls), kann die Schnittstelle 160 die Informationen in der Tabelle für die abgeschlossene Abfrage aktualisieren.
• Für einen inaktiven Thread 5 speichert die Tabelle Informationen über Ergebnisorte in der RMU, der IMU und der SMU. Wenn die Ergebnisse für den Thread 5 an den SM 132 zurückgegeben werden, kann die Schnittstelle 160 die Abfrageergebnisse aus den identifizierten Orten für die Thread ID 5 lesen.
• Für einen inaktiven Thread 16 zeigen die Testergebnisse an, dass es keinen Treffer gibt. Weil es keinen Treffer gibt, wird das „Kein Treffer“ bzw. „No Hit“-Bit in der Schnittstelle 160 für den Thread 16 gesetzt, und werden die zuvor zugewiesenen Slots für die Abfrage von Thread 16 zur Verwendung durch andere Abfragen freigegeben. Wenn die Ergebnisse für den Thread 16 an den SM 132 zurückgegeben werden, liest die Schnittstelle 160 nicht aus den zuvor zugewiesenen Slots für den Thread 16, sondern generiert die an Register des SM 132 zurückgegebenen Daten. In ähnlicher Weise erzeugte die Schnittstelle 160 Daten, die für einen Thread 8 an den SM 132 zurückzugeben sind, weil die Ergebnisse der Abfrage von Thread 8 anzeigten, dass es irgendeinen Treffer gab.
• 13A zeigt auch, dass die Teilergebnisse für einen Thread 4 in bestimmten Slots der RMU und der IMU gespeichert werden, aber die Daten, die von der SMU abgerufen worden wären, werden erzeugt, wenn die Ergebnisse für den Thread 4 an den SM zurückgegeben werden. Der Slot der SMU, in dem die Ergebnisse gespeichert worden wären, wird für andere Abfragen freigegeben.
• Die Zuordnung bzw. das Mapping zwischen dem TTU-Slot, der dem Thread zugewiesen ist, und den Slots in der RMU, der IMU und der SMU kann in einer Neuzuordnungstabelle erfolgen, die in jeder der in 9 gezeigten jeweiligen Einheiten gespeichert ist. 13B zeigt eine beispielhafte Zuordnung zwischen TTU-Slots und den RMU-, IMU- und SMU-Slots. Falls die Neuzuordnungstabellen in den jeweiligen Einheiten der TTU 138 bereitgestellt sind, braucht die Zuordnung nicht in der in 13A gezeigten Tabelle enthalten zu sein.
• Schnittstelle zur Bestimmung, ob eine Ressourcenzuweisung für eine Abfrage erforderlich ist
• In einigen Ausführungsformen kann die Schnittstelle 160 Schaltkreise enthalten, die dazu konfiguriert sind, zu bestimmen, ob einige der Ressourcen in der TTU 138 für eine bestimmte Abfrage nicht zugewiesen werden müssen. In diesem Beispiel kann die Schnittstelle 160 auf der Grundlage von Informationen in der Abfrage (z.B. Parameter des Strahls oder Art der Traversierung) bestimmen, dass eine oder mehrere der Komponenten des Strahl-Slots für die Abfrage nicht zugewiesen werden müssen. Falls die Abfrage beispielsweise nur ein einziges zu testendes Primitiv enthält, kann die Schnittstelle 160 bestimmen, dass Ressourcen in der Stackverwaltungseinheit nicht zugewiesen werden müssen. Die Schnittstelle 160, die diese Bestimmung trifft, bevor oder dann, wenn die Ressourcen zugewiesen werden, kann zulassen, dass das Ticket für die Warp-Ausführung früher ausgestellt wird.
• Beispielhafte Implementierung einer Strahl-Dreieck-Traversierung
• 14 veranschaulicht ein Ablaufdiagramm eines beispielhaften, nicht beschränkenden Verfahrens zur Bestimmung von Schnittpunkten zwischen einer Datenstruktur (z.B. einem Strahl) und Primitiven. Eine oder mehrere von in Bezug auf 14 beschriebene Operationen können von einer TTU 138 durchgeführt werden, die in dieser Anwendung offenbart ist, aber die beispielhaften Implementierungen sind nicht darauf beschränkt.
• Das Verfahren beinhaltet Empfangen einer Anfrage (z.B. einer Abfrage) nach einem oder mehreren Schnittpunkten zwischen einer Abfragedatenstruktur und einem Primitivbereich (Schritt 1110). Die Anfrage kann von einem SM 132 empfangen werden. Die Anfrage kann als Teil eines Warps mit einer Vielzahl von Threads empfangen werden, wobei jeder Thread eine Anfrage für einen Strahl-SchnittpunktTest enthält. Die Anfrage kann einen beliebigen Treffer, einen nächstgelegenen Schnittpunkt oder jeden Schnittpunkt im Primitivbereich anfordern. In einigen Ausführungsformen kann die Abfragedatenstruktur ein Strahl sein, der durch seinen Drei-Koordinaten-Ursprung, seine Drei-Koordinaten-Richtung und seine Minimal- und Maximalwerte (tmin, tmax) für das parametrische Intervall (t-Parameter) entlang des Strahls (der z.B. das Segment von aktuellem Interesse entlang des Strahls repräsentiert) gegeben ist. In einigen Ausführungsformen kann die Abfrage Informationen zur Definition einer Abfragedatenstruktur (z.B. eines Strahls) enthalten, die von der TTU 138 zur Erzeugung eines oder mehrerer Strahlparameter verwendet werden kann, um auf Primitiv-Schnittpunkte mit dem Strahl zu testen. Der Primitivbereich für die Anforderung kann in einem oder mehreren Stack-Einträgen eines Stackverwaltungsblocks in der TTU 138 identifiziert werden. Die Stack-Einträge können auf der Grundlage der Ergebnisse der Suche nach sich schneidenden Blattknoten einer BVH in dem Strahl-Complet-Test-Pfad der TTU 138 erstellt werden.
• Wenn die Ressourcen in der TTU 138 für die Ausführung der Anfragen in dem Warp verfügbar sind, plant die Schnittstelle 160 die Anfrage ein (Schritt 1112). Die Planung der Anfrage kann die Zuweisung von TTU-Ressourcen für die Anfrage beinhalten. Wie vorstehend diskutiert, kann der Anforderung ein Strahl-Slot zugewiesen werden.
• Der Primitivbereich wird aus dem Speicher abgerufen (Schritt 1114). Der Primitivbereich kann aus dem TTU-Speicher (z.B. dem Dreiecks-Cache 754 des L0-Cache 750) oder aus einem Speicher außerhalb der TTU 138 abgerufen werden. Der Primitivbereich kann beispielsweise in einer zusammenhängenden Gruppe von Blöcken in Cachezeilengröße bereitgestellt sein. Jeder Block in Cachezeilengröße kann einen Kopf bzw. Header enthalten, der die Art der im Block ausgedrückten Geometrie und einen Primitiv-Typ für jedes Primitiv im Block angibt. Der Header kann zum Beispiel identifizieren, dass der Block Dreiecke beinhaltet, und kann anzeigen, ob jedes Dreieck ein Alpha-Primitiv oder ein opakes Primitiv ist. Der Header kann ein Alpha-Bit für jedes Primitiv beinhalten, um anzugeben, ob das jeweilige Primitiv eine Alpha-Primitiv oder ein opakes Primitiv ist.
• Das Verfahren beinhaltet das Transformieren des Strahls und/oder der Primitive (Schritt 1116). Der Strahl und/oder die Primitive werden transformiert, um das 3D-Schnittproblem zu vereinfachen und die in der TTU-Hardware für die Durchführung des Schnittpunkttests benötigten Fließkommaressourcen zu verringern.
• Unter Verwendung des transformierten Strahls und/oder der Primitive wird eine Bestimmung durchgeführt, welche Primitive von dem Strahl geschnitten werden (Schritt 1118). Die auf den Strahl und die Primitive angewandten Transformationen vereinfachen das Schnittpunktproblem aus dem 3D-Raum in den 2D-Raum mit vereinfachten ebenen Koordinaten (z.B. 2D-Koordinaten, die auf den Strahl bezogen sind). Im 2D-Raum wird der Schnittpunkttest zur Bestimmung, ob der Strahlschnittpunkt innerhalb von Kanten des Primitivs (z. B. Dreieckskanten) liegt.
• Falls die TTU einen Schnittpunkt ermittelt, dann kann sie auch die Koordinaten des Schnittpunkts bestimmen. Die Schnittpunktkoordinaten können z.B. durch baryzentrische Koordinaten für die weitere Verarbeitung (z. B. Berechnung von Texturkoordinaten) durch den SM 132 oder in anderen (z.B. zukünftigen) Implementierungen durch Hardware innerhalb der TTU bereitgestellt werden.
• Die Schnittergebnisse werden in der TTU 138 gespeichert (Schritt 1120). Die Ergebnisse können angeben, ob der Strahl irgendwelche Primitive geschnitten hat oder nicht, den Zustand des Traversierungs-Stacks, Strahleninformationen usw.. Die Ergebnisse können in den Slots gespeichert werden, die für die Abfrage der jeweiligen Verarbeitungseinheit vorgesehen sind. Einige der Ergebnisse können in einem komprimierten Format (z. B. mit einem einzigen Bit) in der Schnittstelle 160 gespeichert werden. Wenn vollständige oder teilweise Ergebnisse in der Schnittstelle 160 gespeichert werden, können einer oder mehrere der für die Abfrage zugewiesenen Slots für andere Abfragen freigegeben werden.
• Ergebnisse des Schnittpunkttests für die Abfrage werden an den SM 132 zurückgegeben (Schritt 1122). In einem Beispiel gibt die TTU 138 ein Primitiv mit dem nächstgelegenen Treffer an den SM 132 zurück. In einer beispielhaften Ausführungsform können die an den SM 132 zurückgegebenen Ergebnisse für jedes geschnittene Primitiv eine parametrische Länge enthalten, die den Punkt entlang des Strahls angibt, an dem der Treffer auftrat, sowie Attribute des Treffers wie beispielsweise die Instanz-ID, die Material-ID oder die vom SM verwendet werden können, um einen bestimmten Material-Shader und einen Satz von Ressourcenbindungen auszuwählen, sowie Primitiv-IDs und (u,v)-Koordinaten, die vom SM 132 während der Schattierung verwendet werden können, um Attribute oder Mustertexturen abzurufen und zu interpolieren. In einigen Beispielen zeigen die Ergebnisse des Schnittpunkttests an, dass nichts als von dem Strahl geschnitten bestimmt wurde oder dass etwas von dem Strahl geschnitten wurde, ohne zu identifizieren, was geschnitten wurde.
• Die TTU 138 kann Ergebnisse an den SM 132 zurückgeben, wenn eine Anfrage abschließt, oder in der Mitte der Traversierung, falls sich die Notwendigkeit für ein Eingreifen des SM ergeben sollte (z.B. falls die Anzahl der Alpha-Treffer, die innerhalb eines einzelnen Dreieckbereichs gefunden wurden, die Speicherkapazität für Alpha-Treffer in der Ergebniswarteschlange übersteigt). Falls alle Primitive in der Anforderung opak sind, dann kann die TTU 138 nur das nächstgelegene opake Primitiv an den SM 132 zurückgeben. Falls jedoch die Primitive jedoch eine Mischung aus opaken Primitiven und Alpha-Primitiven enthalten, kann eine Vielzahl von Alpha-Primitiven von dem Strahl geschnitten werden. Jedes der geschnittenen Alpha-Primitive kann zur weiteren Verarbeitung an den SM 132 zurückgegeben werden (z.B. um zu bestimmen, ob es einen Treffer gibt, auf der Grundlage von Texturinformationen, die dem Alpha-Primitiv zugeordnet sind). Der SM 132 kann die Ergebnisse verwenden, um die Szene zu erstellen, zusätzliche Abfragen an die TTU 138 auszugeben und/oder zuvor ausgegebene Abfragen an die TTU 138 zu modifizieren.
• Die Rückgabe der Ergebnisse an den SM 132 kann beinhalten, dass vor der Rückgabe der Ergebnisse gewartet wird, bis jede der Anfragen in dem Warp abgeschlossen ist. In anderen Beispielen können die Ergebnisse zurückgegeben werden, wenn eine vorbestimmte Anzahl von Anfragen in der Warp abgeschlossen ist (z.B. 8 oder 16 Anfragen).
• Die Rückgabe der Ergebnisse für die Anfrage an den SM 132 kann beinhalten, dass die Schnittstelle 160 die in der TTU gespeicherten Ergebnisdaten anfordert und/oder die Ergebnisdaten auf der Grundlage zuvor gespeicherter Ergebnisse (z.B. als komprimierte Ergebnisdaten) in der Schnittstelle 160 erzeugt. Wie vorstehend erklärt, ermöglicht die Speicherung der Ergebnisse als komprimierte Daten in der Schnittstelle 160, dass zugewiesene TTU-Ressourcen (z.B. Strahl-Slots) für andere Warps oder Abfragen zur Nutzung dieser Ressourcen freigegeben werden.
• Beispielhafte Implementierung einer Instanzierunqs-Pipeline durch die TTU 138 und den SM 132
• Aus Gründen der Vollständigkeit wird nachstehend beschrieben, wie die TTU 138 in beispielhaften Ausführungsformen eine Instanzierung und zugeordnete Transformationen durchführt.
• Das detailliertere Ablaufdiagramm einer Strahlverfolgungs-Pipeline in 15A zeigt den Datenfluss und die Interaktion zwischen Komponenten für einen repräsentativen Anwendungsfall: Verfolgung von Strahlen gegen eine Szene, die geometrische Primitive enthält, wobei Instanztransformationen in Hardware verarbeitet werden. In einer beispielhaften, nicht beschränkenden Ausführungsform ist die Strahlverfolgungs-Pipeline in 15A im Wesentlichen softwaredefiniert (was in beispielhaften Ausführungsformen bedeutet, dass sie von den SMs 132 bestimmt wird), macht aber ausgiebigen Gebrauch von der Hardwarebeschleunigung durch TTU 138.
• Schlüsselkomponenten beinhalten den SM 132 (und der Rest der Rechenpipeline), die TTU 138 (die als ein Coprozessor für den SM dient) sowie der L1-Cache und das nachgeschaltete Speichersystem, aus welchem die TTU BVH- und Dreiecksdaten abruft.
• Die in 15A gezeigte Pipeline zeigt, dass die Erstellung der Begrenzungsvolumen-Hierarchie 1802 im Voraus von einem Entwicklungssystem durchgeführt werden kann. Sie zeigt auch, dass die Erzeugung und die Verteilung von Strahlen 1804 von dem SM 132 oder einer anderen Software in der beispielhaften Ausführungsform durchgeführt oder gesteuert wird, ebenso wie die Schattierung (welche Beleuchtung und Texturierung beinhalten kann). Die Beispielpipeline beinhaltet eine „Top-Level“-BVH-Baumtraversierung 1806, eine Strahltransformation 1814, eine „Bottom-Level“-BVH-Baumtraversierung 1818 und einen Strahl-/Dreieck- (oder einen anderen Primitiv) Schnittpunkt 1826, die jeweils von der TTU 138 durchgeführt werden. Diese müssen nicht in der gezeigten Reihenfolge durchgeführt werden, da ein Handshaking zwischen der TTU 138 und dem SM 132 bestimmt, was die TTU 138 tut und in welcher Reihenfolge.
• Der SM 132 präsentiert der TTU 138 einen oder mehrere Strahlen zu einer Zeit. Jeder Strahl, den der SM 132 der TTU 138 zur Traversierung präsentiert, kann die geometrischen Parameter des Strahls, den Traversierungsstatus sowie Strahl-Flags, Modus-Flags und Strahloperationsinformationen des Strahls beinhalten. In einer beispielhaften Ausführungsform stellt eine Strahloperation (RayOp) einen hilfsweisen arithmetischen und/oder logischen Test bereit oder umfasst diesen, um einen Schnittpunkt zu unterdrücken, außer Kraft zu setzen und/oder zu speichern. Der Traversierungs-Stack kann auch von dem SM 132 verwendet werden, um bestimmte Statusinformationen an die TTU 138 zur Verwendung in der Traversierung zu kommunizieren. Eine neue Strahlabfrage kann mit einem expliziten Traversierungs-Stack gestartet werden. Für einige Abfragen kann jedoch eine kleine Anzahl von Stack-Initialisierern bereitgestellt sein, um die neue Abfrage eines bestimmten Typs zu beginnen, wie z.B.: von einem Complet ausgehende Traversierung; Schnittpunkt eines Strahls mit einem Bereich von Dreiecken; Schnittpunkt eines Strahls mit einem Bereich von Dreiecken, gefolgt von einer von einem Complet ausgehenden Traversierung; Vertex-Abruf aus einem Dreieckspuffer für ein gegebenes Dreieck usw. In einigen Ausführungsformen verbessert die Verwendung von Stack-Initialisierern anstelle einer expliziten Stack-Initialisierung die Leistung, weil Stack-Initialisierer weniger Register des Streaming-Prozessors erfordern und die Anzahl der Parameter verringern, die vom Streaming-Prozessor an die TTU übertragen werden müssen.
• In der beispielhaften Ausführungsform kann ein Satz von Modus-Flags, die der SM 132 mit jeder Abfrage (z.B. Strahl) präsentiert, zumindest teilweise steuern, wie die TTU 138 die Abfrage verarbeiten wird, wenn die Abfrage das Begrenzungsvolumen eines bestimmten Typs schneidet oder ein Primitiv eines bestimmten Primitivtyps schneidet. Die Modus-Flags, die der SM 132 der TTU 138 zur Verfügung stellt, ermöglichen es dem SM und/oder der Anwendung, z.B. über eine RayOp, einen hilfsweisen arithmetischen oder logischen Test zu spezifizieren, um die Speicherung eines Schnittpunkts zu unterdrücken, aufzuheben oder zuzulassen. Die Modus-Flags können beispielsweise ermöglichen, das Traversierungsverhalten in Übereinstimmung mit solchen Aspekten wie beispielsweise einer Tiefe (oder Entfernung), die jedem Begrenzungsvolumen und/oder Primitiv zugeordnet ist, der Größe eines Begrenzungsvolumens oder Primitivs im Verhältnis zu einer Entfernung vom Ursprung oder dem Strahl, bestimmten Instanzen eines Objekts usw. zu ändern. Diese Fähigkeit kann von Anwendungen genutzt werden, um Sätze von Objekten dynamisch und/oder selektiv für Schnittpunkttestungen gegen bestimmte Sätze oder Gruppen von Abfragen zu aktivieren/deaktivieren, z.B. um die Verwendung verschiedener Versionen von Modellen zu ermöglichen, wenn sich der Anwendungszustand ändert (z.B. wenn sich Türen öffnen oder schließen), oder um verschiedene Versionen eines Modells bereitzustellen, die in Abhängigkeit von der Länge des Strahls ausgewählt werden, um eine Form von geometrischem Detailgrad zu realisieren, oder um bestimmte Sätze von Objekten aus bestimmten Klassen von Strahlen zuzulassen, um einige Ebenen in bestimmten Ansichten sichtbar oder unsichtbar zu machen.
• Zusätzlich zu dem Satz von Modus-Flags, die getrennt für den Strahl-Complet-Schnittpunkt und für den Strahl-Primitiv-Schnittpunkt spezifiziert sein werden können, kann die Strahldatenstruktur andere bzw. weitere RayOp-Test bezogene Parameter angeben, wie beispielsweise Strahl-Flags, Strahlparameter und einen RayOp-Test. Die Strahl-Flags können von der TTU 138 verwendet werden, um verschiedene Aspekte des Traversierungsverhaltens, des Backface-Cullings und der Behandlung der verschiedenen Kindknotentypen in Abhängigkeit vom Status eines Bestehens/Nichtbestehens eines optionalen RayOp-Tests zu steuern. RayOp-Tests fügen Flexibilität zu den Fähigkeiten der TTU 138 hinzu, auf Kosten einer gewissen Komplexität. Die TTU 138 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 der Traversierung in dem entsprechenden Strahl-Slot-Puffer innerhalb der TTU speichern.
• In dem in 15A gezeigten Beispiel führt die TTU 138 eine Top-Level-Baumtraversierung 1806 und ein Bottom-Level-Baumtraversierung 1818 durch. In der beispielhaften Ausführungsform ermöglicht die zweistufige Traversierung der BVH schnelle Strahlverfolgungsreaktionen auf dynamische Szenenänderungen.
• In einigen Ausführungsformen wird beim Eintritt in die Top-Level-Baumtraversierung oder in der Top-Level-Baumtraversierung ein Instanzknoten 1805, der eine Top-Level-Transformation spezifiziert, in der BVH angetroffen. Der Instanzknoten 1805 zeigt der TTU an, dass der Teilbaum, der im Instanzknoten 1805 verwurzelt ist, an einem alternativen Weltraum-Koordinatensystem ausgerichtet ist, für das die Transformation aus dem Weltraum in dem Instanzknoten 1805 definiert ist.
• Im Ansprechen auf das Traversieren des Instanzknotens 1805 transformiert die TTU den Strahl (oder die Strahlen), die von dem SM empfangen wurden, aus dem Weltraum in den alternativen Weltraum.
• Die Strahltransformation 1814 sorgt für den geeigneten Übergang von der Top-Level-Baumtraversierung 1806 zur Bottom-Level-Baumtraversierung 1818, indem der Strahl, der bei der Top-Level-Traversierung in einem ersten Koordinatenraum (z.B. Weltraum) verwendet werden kann, in einen anderen Koordinatenraum (z.B. Objektraum) der BVH der Bottom-Level-Traversierung transformiert wird. Ein beispielhaftes BVH-Traversierungsverfahren, das eine Traversierung auf zwei Ebenen verwendet, ist in der Literatur beschrieben, siehe z.B. Woop, „A Ray Tracing Hardware Architecture for Dynamic Scenes", Universität des Saarlandes, 2004, aber Ausführungsformen sind nicht darauf beschränkt.
• Beispielhafte Top-Level-Baumtraversierung
• Die Top-Level-Baumtraversierung 1806 durch die TTU 138 empfängt Complets aus dem L1-Cache 1812 und stellt eine Instanz für die Strahltransformation 1814 zur Transformation oder eine Fehler/Ende-Ausgabe 1813 für den SM 132 für die Verarbeitung durch einen Nächsten-Treffer- bzw. Closest Hit-Shader 1815 (dieser Block kann auch rekursiv auf der Grundlage von Nicht-Blatt-Knoten/Kein-Treffer-Bedingungen arbeiten) bereit. Bei der Top-Level-Baumtraversierung 1806 holt ein Schritt 1808 zum Abrufen des nächsten Complets das nächste Complet, das in Schritt 1810 auf Strahlüberschneidung zu testen ist, aus dem Speicher und/oder der Cache-Hierarchie, und wird die Prüfung auf Strahl-Begrenzungsvolumen-Schnittpunkte an den Begrenzungsvolumen in dem abgerufenen Complet durchgeführt.
• Wie vorstehend beschrieben, verbindet ein Instanzknoten eine BVH mit einer anderen BVH, die sich in einem anderen Koordinatensystem befindet. Wenn ein untergeordnetes Element bzw. Kind-Element des geschnittenen Begrenzungsvolumens ein Instanzknoten ist, kann die Strahltransformation 1814 eine geeignete Transformationsmatrix aus dem L1-Cache 1816 abrufen. Die TTU 138 transformiert den Strahl unter Verwendung der geeigneten Transformationsmatrix in das Koordinatensystem der untergeordneten BVH. Die US-Patentanmeldung Nr. 14/697,480 , die bereits durch Bezugnahme einbezogen 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 unterschiedlichen Koordinatensystemen liegen. Die Instanzknoten in beispielhaften Ausführungsformen können den Transformationsknoten in der US-Anmeldung Nr. 14/697,480 ähnlich sein. In einem alternativen, nicht-instanziierenden Modus der TTU 138, gezeigt in 15B, führt die TTU keine „Bottom“-Level-Baumtraversierung 1818 aus und werden nicht-instanziierte Baum-BVH-Traversierungen von Blöcken 1808, 1810 durchgeführt, z.B. unter Verwendung nur eines Stacks. Die TTU 138 kann zwischen den instanziierten Operationen aus 15A und den nicht-instanziierten Operationen aus 15B umschalten, basierend darauf, was sie aus der BVH und/oder dem Abfragetyp liest. Zum Beispiel kann ein bestimmter Abfragetyp die TTU darauf beschränken, nur die nicht-instanzierten Operationen zu verwenden. Bei einer solchen Abfrage würden alle geschnittenen Instanzknoten an den SM zurückgegeben.
• In einigen nicht beschränkenden Ausführungsformen wird in Schritt 1810 die Strahl-Begrenzungsvolumen-Schnittpunkt-Testung 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. das Traversieren der Top-Level-Traversierungs-BVH in der Tiefe zuerst. Das US-Patent Nr. 9,582,607 , das bereits durch Bezugnahme einbezogen wurde, beschreibt eine oder mehrere Complet-Strukturen und Inhalte, die in beispielhaften Ausführungsformen verwendet werden können. Das US-Patent Nr. 9,582,607 beschreibt darüber hinaus eine beispielhafte Traversierung von Complets.
• Wenn bestimmt wird, dass ein Begrenzungsvolumen von dem Strahl geschnitten wird, werden die untergeordneten (Kind-) Begrenzungsvolumen (oder Referenzen auf diese) des geschnittenen Begrenzungsvolumens für die anschließende Prüfung auf Schnittpunkte mit dem Strahl und für die Traversierung im Auge behalten. In beispielhaften Ausführungsformen werden eine oder mehrere Stack-Datenstrukturen verwendet, um untergeordnete Begrenzungsvolumen zu verfolgen, die anschließend auf eine Überschneidung mit dem Strahl zu testen sind. In einigen beispielhaften Ausführungsformen kann ein kleiner Traversierungs-Stack verwendet werden, um die durch den Betriebsablauf der Top-Level-Baumtraversierung 1806 zu traversierenden Complets und die auf Schnittpunkte zu testenden Primitive zu verfolgen, und kann eine größere lokale Stack-Datenstruktur verwendet werden, um den Traversierungsstatus in der Bottom-Level-Baumtraversierung 1818 zu verfolgen.
• Beispielhafte Bottom-Level-Baumtraversierung
• Bei der Bottom-Level-Baumtraversierung 1818 ruft ein Nächstes-Complet-Abrufschritt 1822 das nächste Complet, das in Schritt 1824 auf Strahlüberschneidung zu testen ist, aus dem Speicher und/oder der Cache-Hierarchie 1820 ab, und wird die Strahl-Begrenzungsvolumen-Schnittpunkt-Testung an den Begrenzungsvolumen in dem abgerufenen Complet durchgeführt. Die Bottom-Level-Baumtraversierung kann, wie vorstehend erwähnt, Complets mit Begrenzungsvolumen in einem anderen Koordinatensystem enthalten als die Begrenzungsvolumen, die in der Upper-Level-Baumtraversierung traversiert werden. Die Bottom-Level-Baumtraversierung empfängt ebenfalls Complets aus dem L1 -Cache und kann rekursiv oder iterativ in sich selbst auf der Grundlage von Nicht-Blatt/Nicht-Treffer-Bedingungen und auch mit der Top-Level-Baumtraversierung 1806 auf der Grundlage von Fehler-/Ende-Erfassung arbeiten. Schnittpunkte des Strahls mit den Begrenzungsvolumen in der BVH der unteren Ebene können bestimmt werden, wobei der Strahl in das Koordinatensystem der unteren Ebene transformiert wird. Die Blattbegrenzungsvolumen, die bei der Traversierung des Baums auf unterer Ebene als vom Strahl geschnitten aufgefunden wurden, werden dann dem Strahl/Dreieck-Schnittpunkt 1826 bereitgestellt.
• Die Blattausgaben der Baumverfolgung 1818 auf der untersten Ebene werden dem Strahl/Dreieck-Schnittpunkt 1826 bereitgestellt (welcher sowohl L0-Cache-Zugriff als auch die Möglichkeit hat, Dreiecke über den L1-Cache 1828 abzurufen). Die L0-Complet- und Dreieck-Cachespeicher können kleine Nur-Lese-Cachespeicher innerhalb der TTU 138 sein. Der Strahl-/Dreieck-Schnittpunkt 1826 kann auch Blattausgaben vom der Top-Level-Baumtraversierung 1806 erhalten, wenn bestimmte Blattknoten erreicht werden, ohne eine instanzierte BVH zu durchqueren.
• Nachdem alle Primitive im Primitivbereich verarbeitet wurden, prüft die Schnittpunktverwaltungseinheit den Status der Ergebniswarteschlange und erstellt Pakete, die an die Stackverwaltungseinheit und/oder die 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 an den SM 132 zurückzugeben (falls erforderlich). Falls die Ergebniswarteschlange opake oder Alpha-Schnittpunkte enthält, die während der Verarbeitung des Primitivbereichs aufgefunden wurden, dann signalisiert die Schnittpunktverwaltungs-einheit der Strahlverwaltungseinheit die parametrische Länge (t) des nächstgelegenen opaken Schnittpunkts in der Ergebniswarteschlange, um sie als tmax des Strahls zu speichern und den Strahl zu verkürzen. Zur Aktualisierung des Traversierungsstatus, um den nächsten Traversierungsschritt des Strahls einzurichten, signalisiert die Schnittpunktverwaltungseinheit der Stackverwaltungseinheit, ob ein opaker Schnittpunkt aus dem Primitivbereich in der Ergebniswarteschlange bzw. resultQueue vorhanden ist, ob ein oder mehrere Alpha-Schnitte in der Ergebniswarteschlange vorhanden sind, ob die Ergebniswarteschlange voll ist, ob weitere Alpha-Schnittpunkte im Primitivbereich aufgefunden wurden, die nicht an den SM zurückgegeben wurden und die nicht in der Ergebniswarteschlange vorhanden sind, und den Index des nächsten Alpha-Primitivs im Primitivbereich für den zu testenden bzw. prüfenden Strahl, nachdem der SM den Inhalt der Ergebniswarteschlange verbraucht hat (der Index des nächsten Primitivs im Bereich nach dem Alpha-Primitiv mit der höchsten Speicherordnung aus dem aktuellen Primitivbereich in der Ergebniswarteschlange).
• Wenn die Stackverwaltungseinheit 740 das Paket von der Schnittpunktverwaltungseinheit 722 empfängt, inspiziert die Stackverwaltungseinheit 740 das Paket, um die nächste Aktion zu bestimmen, die erforderlich ist, um den Traversierungsschritt abzuschließen und den nächsten zu beginnen. Falls das Paket von der Schnittpunktverwaltungseinheit 722 anzeigt, dass ein opaker Schnittpunkt im Primitivbereich aufgefunden wurde, und die Strahlmodus-Bits angeben, dass der Strahl die Traversierung beenden soll, sobald ein Schnittpunkt aufgefunden wurde, gibt die Stackverwaltungseinheit 740 den Strahl und seine Ergebniswarteschlange an den SM zurück, wobei der Traversierungsstatus anzeigt, dass die Traversierung abgeschlossen ist (ein gesetztes Fertig-Flag und/oder ein leerer Stack der oberen und der unteren Ebene). Falls das Paket von der Schnittpunktverwaltungseinheit 722 anzeigt, dass es opake oder Alpha-Schnittpunkte in der Ergebniswarteschlange gibt und dass es verbleibende Alpha-Schnittpunkte im Primitivbereich gibt, die nicht in der Ergebniswarteschlange vorhanden sind, die vom Strahl während der Verarbeitung des Primitivbereichs angetroffen wurden und die nicht bereits an den SM zurückgegeben wurden, sendet die Stackverwaltungseinheit 740 den Strahl und die Ergebniswarteschlange an den SM zurück, wobei der Traversierungsstatus so geändert wird, dass das Bit „cull opaque“ gesetzt wird, um die weitere Verarbeitung von opaken Primitiven im Primitivbereich zu verhindern, und wird der Startindex des Primitivbereichs auf das erste Alpha-Primitiv nach dem höchsten Alpha-Primitiv-Schnittpunkt aus dem Primitivbereich, der in der Ergebniswarteschlange des Strahls an den SM zurückgegeben wurde, vorgerückt. Falls das Paket von der Schnittpunktverwaltungseinheit 722 anzeigt, dass keine opaken Schnittpunkte oder Alpha-Schnittpunkte aufgefunden wurden, als der Strahl den Primitivbereich verarbeitete, entfernt die Stackverwaltungseinheit 740 den obersten Stack-Eintrag (der dem fertigen Primitivbereich entspricht) vom aktiven Traversierungs-Stack. Falls das Paket von der Stackverwaltungseinheit 740 anzeigt, dass entweder opake Schnittpunkte in der Ergebniswarteschlange vorhanden sind und die Strahlmodus-Bits nicht anzeigen, dass der Strahl die Traversierung beenden soll, sobald ein Schnittpunkt gefunden wurde, und/oder dass Alpha-Schnittpunkte in der Ergebniswarteschlange vorhanden sind, aber keine verbleibenden Alpha-Schnittpunkte im Primitivbereich aufgefunden wurden, die nicht in der Ergebniswarteschlange vorhanden sind und nicht bereits an den SM zurückgegeben wurden, entfernt die Stackverwaltungseinheit 740 den obersten Stack-Eintrag (der dem beendeten Primitivbereich entspricht) von dem aktiven Traversierungs-Stack und modifiziert den Inhalt der Ergebniswarteschlange, um anzuzeigen, dass alle in der Ergebniswarteschlange vorhandenen Schnittpunkte aus einem Primitivbereich stammen, dessen Verarbeitung abgeschlossen wurde.
• Falls der aktive Stack der untere Stack ist und der untere Stack leer ist, setzt die Stackverwaltungseinheit 740 den aktiven Stack auf den oberen Stack. Falls der oberste Stack der aktive Stack ist und der aktive Stack leer ist, gibt die Stackverwaltungseinheit 740 den Strahl und seine Ergebniswarteschlange an den SM zurück, wobei der Traversierungsstatus anzeigt, dass die Traversierung abgeschlossen ist (ein gesetztes Fertig-Flag und/oder ein leerer Stack der obersten und der untersten Ebene). Wenn der aktive Stack einen oder mehrere Stack-Einträge enthält, prüft die Stackverwaltungseinheit 740 den obersten Stack-Eintrag und beginnt mit dem nächsten Traversierungsschritt. Die Testung eines Primitivs und/oder von Primitivbereichen auf Überschneidungen mit einem Strahl und die Rückgabe der Ergebnisse an den SM 132 sind in den parallelen US-Anmeldungen Nr. 16/101,148 mit dem Titel „Conservative Watertight Ray Triangle Intersection“ und Nr. 16/101,196 mit dem Titel „Method for Handling Out-of-Order Opaque and Alpha Ray/Primitive Intersections“ beschrieben, die hiermit in ihrer Gesamtheit durch Bezugnahme einbezogen werden.
• Beispielhafte Bilderzeugungspipeline mit Strahlverfolgung
• Während die obige Offenbarung im spezifischen Kontext von Computergrafik und Visualisierung steht, könnten die Strahlverfolgung und die offenbarte TTU für eine Vielzahl von Anwendungen jenseits von Grafik und Visualisierung verwendet werden. Nicht beschränkende Beispiele beinhalten die Schallpropagation für eine realistische Klangsynthese, die Simulation von Sonarsystemen, das Design optischer Elemente und Systeme, die Simulation des Teilchentransports (z.B. für die medizinische Physik oder die experimentelle Hochenergiephysik), eine allgemeine Simulation der Wellenausbreitung, der Vergleich mit LIDAR-Daten zu Zwecken beispielsweise der Lokalisierung von Robotern oder Fahrzeugen, und andere. OptiX™ wurde bereits in der Vergangenheit für einige dieser Anwendungsbereiche eingesetzt.
• Die Strahlverfolgung und andere vorstehend beschriebene Fähigkeiten können beispielsweise auf verschiedene Weise genutzt werden. Sie können beispielsweise nicht nur zum Rendern einer Szene unter Verwendung der Strahlverfolgung verwendet werden, sondern auch in Kombination mit Abtastkonvertierungstechniken implementiert werden, wie z.B. im Kontext der Abtastkonvertierung geometrischer Bausteine (d.h. Polygonprimitiven wie beispielsweise Dreiecken) eines 3D-Modells zur Erzeugung von Bildern für die Anzeige (z.B. auf der in 4 dargestellten Anzeige 150).
• Indessen bietet die hierin beschriebene Technologie jedoch Vorteile, wenn sie zur Erzeugung von Bildern für die virtuelle Realität, die erweiterte Realität, die gemischte Realität, für Videospiele, die Erzeugung von Bewegungs- und Standbildern und andere Visualisierungsanwendungen verwendet wird. 16 veranschaulicht ein beispielhaftes Ablaufdiagramm zur Verarbeitung von Primitiven zur Bereitstellung von Bildpixelwerten eines Bilds, in Übereinstimmung mit einer Ausführungsform. Wie 16 zeigt, kann ein Bild eines 3D-Modells im Ansprechen auf den Empfang einer Benutzereingabe (Schritt 1952) erzeugt werden. Die Benutzereingabe kann eine Aufforderung zur Anzeige eines Bilds oder einer Bildsequenz sein, wie z.B. eine Eingabeoperation, die während einer Interaktion mit einer Anwendung (z.B. einer Spielanwendung) durchgeführt wird. Im Ansprechen auf die Benutzereingabe führt das System eine Abtastkonvertierung und eine Rasterisierung von geometrischen 3D-Modell-Primitiven einer Szene unter Verwendung einer herkömmlichen GPU-3D-Grafikpipeline durch (Schritt 1954). Die Abtastkonvertierung und die Rasterisierung geometrischer Primitive kann zum Beispiel die Verarbeitung von Primitiven des 3D-Modells beinhalten, um Bildpixelwerte unter Verwendung konventioneller Techniken wie Beleuchtung, Transformationen, Textur-Mapping, Rasterisierung und dergleichen zu bestimmen, wie sie dem Fachmann bekannt sind. Die erzeugten Pixeldaten können in einen Framepuffer geschrieben werden.
• In Schritt 1956 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 in Übereinstimmung mit einer oder mehreren in dieser Anwendung offenbarten Strahlverfolgungsfähigkeiten verfolgt werden. Basierend auf den Ergebnissen der Strahlverfolgung können die in dem Puffer gespeicherten Pixelwerte modifiziert werden (Schritt 1958). Die Modifizierung der Pixelwerte kann in einigen Anwendungen beispielsweise die Bildqualität verbessern, indem beispielsweise realistischere Reflexionen und/oder Schatten angewendet werden. Ein Bild wird unter Verwendung der in dem Puffer gespeicherten modifizierten Pixelwerte angezeigt (Schritt 1960).
• In einem Beispiel kann die Abtastkonvertierung und Rasterung geometrischer Primitive unter Verwendung des vorstehend beschriebenen Verarbeitungssystems implementiert sein, und kann die Strahlverfolgung von den SMs 132 unter Verwendung der in Bezug auf 7 beschriebenen TTU-Architektur implementiert sein, um weitere Visualisierungsmerkmale (z.B. spiegelnde Reflexion, Schatten usw.) hinzuzufügen. 16 ist nur ein nicht beschränkendes Beispiel - die SMs 132 könnten die beschriebene TTU selbst ohne Texturverarbeitung oder andere herkömmliche 3D-Grafikverarbeitung einsetzen, um Bilder zu erzeugen, oder die SMs könnten Texturverarbeitung und andere herkömmliche 3D-Grafikverarbeitung ohne die beschriebene TTU verwenden, um Bilder zu erzeugen. Die SMs können auch jede gewünschte Bilderzeugung oder andere Funktionalität in Software implementieren, je nach Anwendung, um jede gewünschte programmierbare Funktionalität bereitzustellen, die nicht an die Hardware-Beschleunigungsfunktionen gebunden ist, die von der Textur-Mapping-Hardware, Baumtraversierungs-Hardware oder anderer Grafik-Pipeline-Hardware bereitgestellt werden.
• In einigen Ausführungsformen ist die TTU 138 zustandslos, d.h. es wird kein architektonischer Zustand in der TTU zwischen Abfragen aufrechterhalten. Gleichzeitig ist es für Software, die auf dem SM 1840 läuft, oft nützlich, die Fortsetzung einer früheren Abfrage anzufordern, was bedeutet, dass der relevante Zustand von der TTU 138 in Register geschrieben und dann in Registern (oft an Ort und Stelle) an die TTU zurückgegeben werden sollte, um fortzufahren. Dieser Zustand kann die Form eines Traversierungs-Stacks annehmen, der den Fortschritt bei der Traversierung der BVH nachverfolgt.
• Eine kleine Anzahl von Stack-Initialisierern kann z.B. auch zum Beginnen einer neuen Abfrage eines bestimmten Typs vorgesehen sein:
• • Traversierung ausgehend von einem Complet
• • Schnittpunkt eines Strahls mit einer Reihe von Dreiecken
• • Schnittpunkt eines Strahls mit einer Reihe von Dreiecken, gefolgt von einer Traversierung ausgehend von einem Complet
• • Vertex-Abruf aus einem Dreieckspuffer für ein bestimmtes Dreieck
• • Optionale Unterstützung für Instanztransformationen vor dem „Traversierung ausgehend von einer Complet “ und „Schnittpunkt eines Strahls mit einem Bereich von Dreiecken“.
• Vertex-Abruf ist eine einfache Abfrage, die mit Anfragedaten spezifiziert werden kann, die aus einem Stack-Initialisierer und sonst nichts bestehen. Andere Abfragetypen können die Spezifikation eines Strahls, Strahlenbündels oder eines anderen geometrischen Objekts erfordern, zusammen mit dem Stack oder Stack-Initialisierer und verschiedenen Strahl-Flags, die Details der Abfrage beschreiben. Ein Strahl wird durch seinen Drei-Koordinaten-Ursprung, seine Drei-Koordinaten-Richtung und Minimal- und Maximalwerte für den t-Parameter entlang des Strahls spezifiziert. Ein Strahlbündel wird zusätzlich durch einen zweiten Ursprung und eine zweite Richtung spezifiziert.
• Verschiedene Strahl-Flags können verwendet werden, um verschiedene Aspekte des Traversierungsverhaltens, des Backface-Culling und der Behandlung der verschiedenen Kindknotenarten zu steuern, abhängig von einem Pass/Fail-Status eines optionalen RayOp-Tests. RayOps fügen beträchtliche Flexibilität zu den Möglichkeiten der TTU hinzu. In einigen Ausführungsformen führt der RayOps-Teil zwei Strahl-Flag-Versionen ein, die dynamisch auf der Grundlage einer bestimmten Operation an den mit dem Strahl übertragenen Daten und den in dem Complet gespeicherten Daten ausgewählt werden können. Um solche Flags zu untersuchen, ist es zunächst hilfreich, die verschiedenen Arten von Kindknoten, die innerhalb einer BVH zulässig sind, sowie die verschiedenen Treffertypen, die die TTU 138 an den SM zurückgeben kann, zu verstehen. Beispielhafte Knotentypen sind:
• ■ Eine untergeordnetes bzw. Kind-Complet (d.h. ein interner Knoten)
• Standardmäßig setzt die TTU 138 die Traversierung fort, indem es in untergeordnete Complets absteigt.
• ■ Ein Dreiecksbereich, der einem zusammenhängenden Satz von Dreiecken innerhalb eines Dreieckspuffers entspricht
• (1) Standardmäßig werden Dreiecksbereiche, auf die ein Strahl trifft, nativ von der TTU 138 behandelt, indem die Dreiecke auf Schnittpunkte getestet und der Strahl entsprechend verkürzt wird. Falls die Traversierung abschließt und ein Dreieck getroffen wurde, wird standardmäßig die Dreiecks-ID an den SM 1840 zurückgegeben, zusammen mit dem t-Wert und baryzentrischen Koordinaten des Schnittpunkts. Dies ist der Treffertyp „Dreieck“.
• (2) Standardmäßig werden geschnittene Dreiecke mit gesetztem Alpha-Bit an den SM 1840 zurückgegeben, auch wenn die Traversierung noch nicht abgeschlossen ist. Der zurückgegebene Traversierungs-Stack enthält den Status, der erforderlich ist, um den Traversierungsvorgang fortzusetzen, falls Software feststellt, dass das Dreieck tatsächlich transparent war.
• (3) Dreiecksüberschneidungen werden in einigen Ausführungsformen für Strahlbündel nicht unterstützt, so dass angetroffene Dreiecksbereiche standardmäßig als ein Treffertyp „TriRange“ an den SM 1840 zurückgegeben werden, welches einen Zeiger auf den ersten Dreiecksblock, der den Bereich überlappt, Parameter, die den Bereich spezifizieren, und den t-Wert der Überschneidung bzw. des Schnittpunkts mit dem Blattbegrenzungsrahmen enthält.
• ■ Ein Elementbereich, bestehend aus einem Index (abgeleitet von einer vom Benutzer bereitgestellten „Elementbereichbasis“, die in dem Complet gespeichert ist) und einer Anzahl von Elementen.
• Standardmäßig werden Elementbereiche als eine Trefferart „ItemRange“ an den SM 1840 zurückgegeben, die z.B. aus einem Index, einer Anzahl und dem t-Wert des Schnittpunkts mit dem Blattbegrenzungsrahmen besteht.
• ■ Ein Instanzknoten.
• In einigen Ausführungsformen kann die TTU 138 nativ eine Instanzierungsebene verarbeiten, indem sie den Strahl in das Koordinatensystem des Instanz-BVHs transformiert. Zusätzliche Instanzierungsebenen (oder jede andere Instanzierungsebene, je nach Strategie) können in Software verarbeitet werden (oder in anderen Ausführungsformen kann die TTU 138 Hardware zwei, drei oder mehr Instanzierungsebenen verarbeiten). Zu diesem Zweck ist der Treffertyp „InstanceNode“ vorgesehen, der aus einem Zeiger auf den Instanzknoten und dem t-Wert des Schnittpunkts mit dem Blattbegrenzungsrahmen besteht. In anderen Implementierungen kann die Hardware zwei, drei oder mehr Ebenen der Instanzierung verarbeiten.
• Zusätzlich zu den knotenspezifischen Treffertypen wird ein allgemeiner Treffertyp „NodeRef“, der aus einem Zeiger auf das übergeordnete (Eltern-) Complet selbst sowie einer ID, die angibt, welches Kind geschnitten wurde, und dem t-Wert des Schnittpunkts mit dem Begrenzungsrahmen dieses Kindes besteht.
• Ein Treffertyp „Fehler“ kann für Fälle bereitgestellt sein, in denen die Abfrage oder die BVH nicht korrekt erzeugt wurde, oder wenn bei der Traversierung Probleme aufgetreten sind.
• Für den Fall, dass der Strahl oder das Strahlbündel alle Geometrien in der Szene verfehlt, kann ein Treffertyp „None“ bereitgestellt sein.
• Wie die TTU jeden der vier möglichen Knotentypen behandelt, wird durch eine Reihe von knotenspezifischen Modus-Flags bestimmt, die als Teil der Abfrage für einen gegebenen Strahl gesetzt werden. Das vorstehend erwähnte „Standard“-Verhalten entspricht dem Fall, in dem die Modus-Flags alle auf Nullen gesetzt sind.
• Alternative Werte für die Flags ermöglichen ein Aussortieren bzw. Culling aller Knoten eines bestimmten Typs, die Rückgabe von Knoten eines bestimmten Typs an den SM als ein NodeRef-Treffertyp oder die Rückgabe von Dreiecksbereichen oder Instanzknoten an den SM unter Verwendung ihrer entsprechenden Treffertypen, anstatt sie nativ innerhalb der TTU 138 zu verarbeiten.
• Zusätzliche Modus-Flags können zur Steuerung der Behandlung von Alpha-Dreiecken bereitgestellt sein.
• Bilder, die unter Anwendung einer oder mehrerer der hierin offenbarten Techniken erzeugt wurden, können auf einem Monitor oder einer anderen Anzeigevorrichtung angezeigt werden. In einigen Ausführungsformen kann die Anzeigevorrichtung direkt mit dem System oder Prozessor verbunden sein, das oder der die Bilder erzeugt oder wiedergibt bzw. rendert. In anderen Ausführungsformen kann die Anzeigevorrichtung indirekt mit dem System oder Prozessor gekoppelt sein, beispielsweise über ein Netzwerk. Beispiele für solche Netzwerke sind das Internet, mobile Telekommunikationsnetzwerke, ein WIFI-Netzwerk sowie jedes andere drahtgebundene und/oder drahtlose Vernetzungssystem. Wenn die Anzeigevorrichtung indirekt gekoppelt ist, können die von dem System oder Prozessor erzeugten Bilder über das Netzwerk an die Anzeigevorrichtung gestreamt werden. Ein solches Streaming ermöglicht es beispielsweise, dass Videospiele oder andere Anwendungen, die Bilder rendern, auf einem Server oder in einem Rechenzentrum ausgeführt werden und die gerenderten Bilder auf ein oder mehrere Benutzergeräte (wie beispielsweise einen Computer, eine Videospielkonsole, ein Smartphone, ein anderes mobiles Gerät usw.) übertragen und angezeigt werden, die physisch von dem Server oder dem Rechenzentrum getrennt sind. Daher können die hierin offenbarten Techniken zur Verbesserung der gestreamten Bilder und zur Verbesserung von Diensten, die Bilder streamen, wie beispielsweise NVIDIA GeForce Now (GFN), Google Stadia und dergleichen, angewendet werden.
• Darüber hinaus können Bilder, die unter Anwendung einer oder mehrerer der hierin offenbarten Techniken erzeugt wurden, zum Trainieren, Testen oder Zertifizieren von tiefen neuronalen Netzen (DNNs; deep neural networks) verwendet werden, die zur Erkennung von Objekten und Umgebungen in der realen Welt verwendet werden.
• Solche Bilder können Szenen von Straßen, Fabriken, Gebäuden, städtischen Umgebungen, ländlichen Umgebungen, Menschen, Tieren und anderen physischen Objekten oder realen Umgebungen beinhalten. Solche Bilder können zum Trainieren, Testen oder Zertifizieren von DNNs verwendet werden, die in Maschinen oder Robotern verwendet werden, um physische Objekte in der realen Welt zu manipulieren, zu handhaben oder zu modifizieren. Ferner können solche Bilder verwendet werden, um DNNs zu trainieren, zu testen oder zu zertifizieren, die in autonomen Fahrzeugen eingesetzt werden, um die Fahrzeuge durch die reale Welt zu navigieren und zu bewegen. Darüber hinaus können Bilder, die unter Anwendung einer oder mehrerer der hierin offenbarten Techniken erzeugt wurden, verwendet werden, um den Benutzern solcher Maschinen, Roboter und Fahrzeuge Informationen zu vermitteln.
• Alle vorstehend zitierten Patente und Veröffentlichungen werden durch Bezugnahme einbezogen, als ob sie ausdrücklich aufgeführt wären.
• Während die Erfindung im Zusammenhang mit dem beschrieben wurde, was derzeit als die praktischsten und bevorzugten Ausführungsformen angesehen wird, versteht sich, dass die Erfindung nicht auf die offenbarten Ausführungsformen zu beschränken ist, sondern im Gegenteil verschiedene Modifikationen und äquivalente Anordnungen innerhalb der Idee und des Rahmens der beigefügten Ansprüche abdecken soll.
• Wie vorstehend beschrieben wurde, werden Techniken zur Verbesserung des Durchsatzes von Strahlschnitt- oder Sichtbarkeits-Abfragen offengelegt, die von einem Hardwarebeschleuniger für die Strahlverfolgung durchgeführt werden. Der Durchsatz wird beispielsweise dadurch verbessert, dass allokierte Ressourcen freigegeben werden, bevor der Hardware-Beschleuniger Ergebnisse der Strahlsichtbarkeitsabfrage meldet. Die allokierten Ressourcen werden freigegeben, wenn die Ergebnisse der Strahlsichtbarkeitsabfrage in einem komprimierten Format außerhalb der zugewiesenen Ressourcen gespeichert werden können. Wenn die Ergebnisse der Strahlsichtbarkeitsabfrage gemeldet werden, werden die Ergebnisse auf der Grundlage der im komprimierten Format gespeicherten Ergebnisse rekonstruiert. Die Speicherung im komprimierten Format kann für Strahlsichtbarkeitsabfragen verwendet werden, die keine Schnittpunkte zurückgeben oder sich bei einer Beliebiger-Treffer-Strahlsichtbarkeits-Abfrage beenden. Eine oder mehrere einzelne Komponenten der allokierten Ressourcen können auch unabhängig voneinander auf der Grundlage der Art der zurückzugebenden Daten und/oder von Ergebnissen der Strahlsichtbarkeitsabfrage freigegeben werden.
• ZITATE ENTHALTEN IN DER BESCHREIBUNG
• Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
• Zitierte Patentliteratur
• US 9582607 [0011, 0027, 0153]
• US 9569559 [0011]
• US 20160070820 [0011]
• US 20160070767 [0011]
• US 16101247 [0087, 0095]
• US 14697480 [0152]
• US 16101148 [0159]
• Zitierte Nicht-Patentliteratur
• Ausgabe Addison-Wesley 1995 & 3. Ausgabe Addison-Wesley 2014 [0002]
• Appel, „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) [0004]
• Kajiya, „The Rendering Equation“, Computer Graphics (SIGGRAPH 1986 Proceedings, Band 20, S. 143-150) [0004]
• Hery et al., „Towards Bidirectional Path Tracing at Pixar“ (2016) [0004]
• Parker et al., „OptiX: A General Purpose Ray Tracing Engine“ (ACM Transactions on Graphics, Band. 29, Nr. 4, Artikel 66, Juli 2010 [0010]
• Woop, „A Ray Tracing Hardware Architecture for Dynamic Scenes“, Universität des Saarlandes, 2004 [0150]

Claims (30)

1. Strahlverfolgungsverfahren, umfassend: (a) Durchführen eines Schnittpunkttests zum Bereitstellen eines Schnittpunkttestergebnisses; und (b) Auswählen, auf der Grundlage des Schnittpunkttestergebnisses, ob der Schnittpunkttest an einen kooperierenden Prozessor zu melden ist, unter Verwendung von Daten, die aus dem Schnittpunkttest gesammelt wurden, oder unter Verwendung von Daten, die vorbestimmt waren, bevor der Schnittpunkttest durchgeführt wurde.
2. Strahlverfolgungsverfahren nach Anspruch 1, ferner beinhaltend selektives Deallokieren von On-Chip-Speicher, der zum Sammeln von Daten aus dem Schnittpunkttest verwendet wird bei einem Bestimmen, auf der Grundlage des Schnittpunkttestergebnisses, dass das Schnittpunkttestergebnis gemeldet werden wird, unter Verwendung der Daten, die vorbestimmt waren, bevor der Schnittpunkttest durchgeführt wurde.
3. Strahlverfolgungsverfahren nach einem der Ansprüche 1 oder 2, wobei das Auswählen auswählt, wann immer das Schnittpunkttestergebnis ein Verfehlen ist, unter Verwendung der Daten, die vorbestimmt waren, bevor der Schnittpunkttest durchgeführt wurde.
4. Strahlverfolgungsverfahren nach einem der vorangehenden Ansprüche, ferner beinhaltend ein Verwenden derselben Meldeformatrepräsentation für jedes von Verwenden von Daten, die aus dem Schnittstellentest gesammelt wurden, und Verwenden von Daten, die vorbestimmt waren, bevor der Schnittpunkttest durchgeführt wurde.
5. Coprozessor, der an einen Prozessor gekoppelt ist und Schaltkreise umfasst, die dazu konfiguriert sind, Operationen durchzuführen, die umfassen: Empfangen, von dem Prozessor, einer Vielzahl von Thread-Anforderungen, wobei jede Anforderung eine Abfrage beinhaltet; für jede Abfrage, Allokieren von Ressourcen zum Speichern von Abfrageergebnissen; Verarbeiten der Abfragen; für zumindest eine verarbeitete Abfrage, Speichern von Abfrageergebnissen in der allokierten Ressource für die jeweilige Abfrage; für zumindest eine verarbeitete Abfrage, Speichern von Abfrageergebnissen außerhalb der allokierten Ressourcen für die jeweilige Abfrage und Deallokieren der allokierten Ressourcen für die jeweilige Abfrage; und wenn die Verarbeitung für eine vorbestimmte Anzahl von Abfragen abgeschlossen ist, gleichzeitiges Melden der Abfrageergebnisse, die in der allokierten Ressource der zumindest einen verarbeiteten Anfrage gespeichert sind, und der Abfrageergebnisse, die außerhalb der allokierten Ressourcen gespeichert sind, für die zumindest eine Abfrage.
6. Coprozessor nach Anspruch 5, wobei die vorbestimmte Anzahl von Abfragen eine Anzahl von Threads in der Vielzahl von Thread-Anforderungen ist.
7. Coprozessor nach Anspruch 5 oder 6, wobei die vorbestimmte Anzahl von Abfragen kleiner ist als eine Anzahl von Threads in der Vielzahl von Thread-Anforderungen.
8. Coprozessor nach einem der Ansprüche 5 bis 7, wobei jede Abfrage Informationen, die einen Strahl definieren, und eine Datenstruktur zum Testen auf Primitiv-Schnitte mit dem Strahl beinhaltet.
9. Coprozessor nach Anspruch 8, wobei die Abfrageergebnisse, die außerhalb der allokierten Ressourcen gespeichert sind, anzeigen, dass der Strahl als keine Primitive in der Datenstruktur schneidend bestimmt wird.
10. Coprozessor nach einem der Ansprüche 5 bis 9, wobei die Vielzahl von Thread-Anforderungen eine Beende-bei-beliebigem-Treffer-Abfrage beinhaltet, die Informationen, die einen Strahl definieren, und eine Vielzahl von Primitiven zum Testen von Schnitten mit dem Strahl beinhaltet, wobei die Beende-bei-beliebigem-Treffer-Abfrage eine Angabe, dass eines der Vielzahl von Primitiven durch den Strahl geschnitten wird, oder eine Angabe, dass keines der Vielzahl von Primitiven durch den Strahl geschnitten wird, zurückgibt.
11. Coprozessor nach Anspruch 10, wobei die allokierte Ressource für die Beende-bei-beliebigem-Treffer-Abfrage bei Abschluss der Beende-bei-beliebigem-Treffer-Abfrage deallokiert wird und Ergebnisse für die Beende-bei-beliebigem-Treffer-Abfrage in einem komprimierten Format außerhalb der allokierten Ressourcen für die Beende-bei-beliebigem-Treffer-Abfrage gespeichert werden, bis die Verarbeitung für die vorbestimmte Anzahl von Abfragen abgeschlossen ist.
12. Coprozessor nach einem der Ansprüche 5 bis 11, ferner umfassend eine Schnittstelle, die dazu konfiguriert ist, die Vielzahl von Thread-Anforderungen zu empfangen, die Allokation und die Deallokation der Ressourcen zu steuern, eine Speicherung von komprimierten Abfrageergebnissen außerhalb der allokierten Ressourcen bereitzustellen, und das Melden der Abfrageergebnisse an den Prozessor zu steuern.
13. Strahlverfolgungsvorrichtung, die an einen Prozessor gekoppelt ist und Schaltkreise umfasst, die dazu konfiguriert sind, Operationen durchzuführen, die umfassen: Empfangen, von dem Prozessor, einer Vielzahl von Abfragen, wobei jede Abfrage Informationen, die einen Strahl definieren, und eine Datenstruktur zum Testen auf Primitiv-Schnitte mit dem Strahl beinhaltet; für jede Abfrage, Allokieren von Ressourcen zum Speichern von Strahl-Schnittpunkt-Ergebnissen, Empfangen eines Primitivbereichs einschließlich einer Vielzahl von Primitiven, Bestimmen, ob eines oder mehrere der Vielzahl von Primitiven durch den Strahl geschnitten werden, Speichern des Schnittergebnisses in den allokierten Ressourcen, wenn bestimmt wird, dass der Strahl zumindest eines der Vielzahl von Primitiven schneidet, und Freigeben der allokierten Ressourcen für die Abfrage und Speichern einer komprimierten Repräsentation des Schnittergebnisses in einem Speicher außerhalb der allokierten Ressourcen für die Abfrage, wenn bestimmt wird, dass der Strahl keines der Vielzahl von Primitiven schneidet; und Melden, an den Prozessor, von Schnittergebnissen, die in den allokierten Ressourcen und/oder dem Speicher außerhalb der allokierten Ressourcen gespeichert sind.
14. Strahlverfolgungsvorrichtung nach Anspruch 13, wobei die Schnittergebnisse an den Prozessor gemeldet werden, nachdem eine vorbestimmte Anzahl der Vielzahl von Abfragen durch die Strahlverfolgungsvorrichtung verarbeitet ist, wobei die vorbestimmte Anzahl größer ist als Eins und kleiner ist als die Anzahl der Vielzahl von Abfragen.
15. Strahlverfolgungsvorrichtung nach Anspruch 13 oder 14, wobei die Schnittergebnisse an den Prozessor gemeldet werden, nachdem die Hälfte der Vielzahl von Abfragen durch die Strahlverfolgungsvorrichtung verarbeitet ist.
16. Strahlverfolgungsvorrichtung nach einem der Ansprüche 13 bis 15, wobei die allokierten Ressourcen für jede Abfrage eine Vielzahl von Speicherorten beinhalten, von denen jeder einem anderen Verarbeitungsschaltkreis der Strahlverfolgungsvorrichtung zugeordnet ist.
17. Strahlverfolgungsvorrichtung nach einem der Ansprüche 13 bis 16, wobei ein einzelnes Bit verwendet wird, um das Schnittergebnis in dem Speicher außerhalb der allokierten Ressourcen für die Abfrage zu repräsentieren, wenn bestimmt wird, dass der Strahl keines der Vielzahl von Primitiven schneidet.
18. Strahlverfolgungsvorrichtung nach einem der Ansprüche 13 bis 17, wobei das Melden der Ergebnisse für eine Abfrage, in welcher keines der Vielzahl von Primitiven durch den Strahl geschnitten wird, ein Erzeugen von Daten auf der Grundlage der komprimierten Repräsentation des Schnittergebnisses beinhaltet, das in dem Speicher außerhalb der allokierten Ressourcen gespeichert ist.
19. Strahlverfolgungsvorrichtung nach einem der Ansprüche 13 bis 18, wobei das Melden der Ergebnisse für eine Abfrage, in welcher keines der Vielzahl von Primitiven durch den Strahl geschnitten wird, ein Erzeugen von Daten auf der Grundlage der komprimierten Repräsentation des Schnittergebnisses beinhaltet, das in dem Speicher außerhalb der allokierten Ressourcen gespeichert ist, wenn die Schnittergebnisse für die Vielzahl von Abfragen gleichzeitig an den Prozessor zurückgegeben werden.
20. Strahlverfolgungsvorrichtung nach einem der Ansprüche 13 bis 19, wobei der Schaltkreis ein Teil eines Servers oder eines Rechenzentrums ist, der bzw. das bei einem Erzeugen eines Bilds verwendet wird, und das Bild an ein Benutzergerät gestreamt wird.
21. Strahlverfolgungsvorrichtung nach einem der Ansprüche 13 bis 20, wobei der Schaltkreis bei einem Erzeugen eines Bilds verwendet wird, und das Bild zum Trainieren, Testen oder Zertifizieren eines neuronalen Netzwerks verwendet wird, das in einer Maschine, einem Roboter oder einem autonomen Fahrzeug eingesetzt wird.
22. Verfahren, das von einem Coprozessor durchgeführt wird, der kommunikativ an einem Prozessor gekoppelt ist, wobei das Verfahren umfasst: Empfangen, von dem Prozessor, einer Vielzahl von Thread-Anforderungen, wobei jede Anforderung eine Abfrage beinhaltet; für jede Abfrage, Allokieren von Ressourcen zum Speichern von Abfrageergebnissen; Verarbeiten der Abfragen; für zumindest eine verarbeitete Abfrage, Speichern von Abfrageergebnissen in der allokierten Ressource für die jeweilige Abfrage; für zumindest eine verarbeitete Abfrage, Speichern von Abfrageergebnissen außerhalb der allokierten Ressourcen für die jeweilige Abfrage und Deallokieren der allokierten Ressourcen für die jeweilige Abfrage; und gleichzeitiges Melden der Abfrageergebnisse, die in der allokierten Ressource der zumindest einen verarbeiteten Anfrage gespeichert sind, und der Abfrageergebnisse, die außerhalb der allokierten Ressourcen gespeichert sind, für die zumindest eine Abfrage.
23. Verfahren nach Anspruch 22, wobei die Abfrageergebnisse gemeldet werden, wenn die Verarbeitung für eine vorbestimmte Anzahl von Abfragen abgeschlossen ist.
24. Verfahren nach Anspruch 23, wobei die vorbestimmte Anzahl von Abfragen eine Anzahl von Threads in der Vielzahl von Thread-Anforderungen ist.
25. Verfahren nach Anspruch 23 oder 24, wobei die vorbestimmte Anzahl von Abfragen kleiner ist als eine Anzahl von Threads in der Vielzahl von Thread-Anforderungen.
26. Verfahren nach einem der Ansprüche 22 bis 25, wobei jede Abfrage Informationen, die einen Strahl definieren, und eine Datenstruktur zum Testen auf Primitiv-Schnitte mit dem Strahl beinhaltet.
27. Verfahren nach Anspruch 26, wobei die Abfrageergebnisse, die außerhalb der allokierten Ressourcen gespeichert sind, anzeigen, dass der Strahl als keine Primitive in der Datenstruktur schneidend bestimmt wird.
28. Verfahren nach einem der Ansprüche 22 bis 27, wobei die Vielzahl von Thread-Anforderungen eine Beende-bei-beliebigem-Treffer-Abfrage beinhaltet, die Informationen, die einen Strahl definieren, und eine Vielzahl von Primitiven zum Testen von Schnitten mit dem Strahl beinhaltet, wobei die Beende-bei-beliebigem-Treffer-Abfrage eine Angabe, dass eines der Vielzahl von Primitiven durch den Strahl geschnitten wird, oder eine Angabe, dass keines der Vielzahl von Primitiven durch den Strahl geschnitten wird, zurückgibt, und wobei die allokierte Ressource für die Beende-bei-beliebigem-Treffer-Abfrage bei Abschluss der Beende-bei-beliebigem-Treffer-Abfrage deallokiert wird und Ergebnisse für die Beende-bei-beliebigem-Treffer-Abfrage in einem komprimierten Format außerhalb der allokierten Ressourcen für die Beende-bei-beliebigem-Treffer-Abfrage gespeichert werden, bis die Verarbeitung für jede der Vielzahl von Thread-Anforderungen abgeschlossen ist.
29. Verfahren nach einem der Ansprüche 22 bis 28, wobei das Empfangen, das Allokieren, das Verarbeiten der Abfragen, das Speichern der Abfrageergebnisse in der allokierten Ressource und/oder außerhalb der allokierten Ressource und das Melden auf einem Server oder in einem Rechenzentrum durchgeführt wird, um ein Bild zu erzeugen, und das Bild an ein Benutzergerät gestreamt wird.
30. Verfahren nach einem der Ansprüche 22 bis 29, wobei das Empfangen, das Allokieren, das Verarbeiten der Abfragen, das Speichern der Abfrageergebnisse in der allokierten Ressource und/oder außerhalb der allokierten Ressource und das Melden durchgeführt wird, um ein Bild zu erzeugen, das zum Trainieren, Testen oder Zertifizieren eines neuronalen Netzwerks verwendet wird, das in einer Maschine, einem Roboter oder einem autonomen Fahrzeug eingesetzt wird.

Images