DE102018114286A1

DE102018114286A1 - Durchführen einer Traversierungs-Stack-Komprimierung

Info

Publication number: DE102018114286A1
Application number: DE102018114286.2A
Authority: DE
Inventors: Henri Johannes Ylitie; Tero Tapani KARRAS; Samuli Matias Laine
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2017-06-27
Filing date: 2018-06-14
Publication date: 2018-12-27
Also published as: US20180373809A1; US10984049B2

Abstract

Ein Verfahren, ein von einem Computer lesbares Medium und ein System werden offenbart, um eine Traversierungs-Stack-Komprimierung durchzuführen. Das Verfahren umfasst ein Traversieren einer hierarchischen Datenstruktur mit mehr als zwei Kindern pro Knoten und während des Traversierens ein Erzeugen mindestens eines Stackeintrags mittels eines Prozessors, wobei jeder Stackeintrag mehrere geschnittene Knoten enthält, und mittels des Prozessors Hinzufügen des mindestens einen Stackeintrags zu einem komprimierten Traversierungs-Stack, welcher in einem Speicher gespeichert ist.

Description

BEREICH DER ERFINDUNG
Die vorliegende Erfindung betrifft Raytracing und insbesondere ein Implementieren eines Ray-Traversierungs-Algorithmus, welcher auf einem komprimierten Traversierungs-Stack arbeitet.
HINTERGRUND DER ERFINDUNG
Ein Traversieren von hierarchischen Datenstrukturen wird im Allgemeinen während verschiedener Operationen (z. B. Raytracing, Kollisionserkennung, usw.) durchgeführt. Jedoch wird ein großer Teil der verfügbaren Speicherbandbreite bei einem Prozessor durch den Speicherverkehr zu und von herkömmlichen Traversierungs-Stacks (wobei Knoten individuell innerhalb des Stacks gespeichert sind) verbraucht.
Daher existiert ein Bedürfnis, diese Aufgaben und/oder andere Aufgaben, welche dem Stand der Technik zugeordnet sind, zu adressieren.
ZUSAMMENFASSUNG
Ein Verfahren, ein von einem Computer lesbares Medium und ein System werden offenbart, um eine Traversierungs-Stack-Komprimierung durchzuführen. Das Verfahren weist auf ein Durchlaufen bzw. Traversieren einer hierarchischen Datenstruktur auf, welche mehr als zwei Kinder pro Knoten aufweist, und während des Traversierens ein Erzeugen mindestens eines Stackeintrags, wobei ein Prozessor eingesetzt wird, wobei jeder Stackeintrag mehrere geschnittene Knoten enthält, und ein Addieren des mindestens einen Stackeintrags zu einem komprimierten Traversierungs-Stack, welcher in einem Speicher gespeichert ist, wobei der Prozessor eingesetzt wird.
Figurenliste

1 stellt einen Flussplan eines Verfahrens zum Durchführen einer Traversierungs-Stack-Komprimierung gemäß einer Ausführungsform dar.
2 stellt eine Parallelverarbeitungseinheit gemäß einer Ausführungsform dar.
3A stellt ein allgemeines Verarbeitungscluster der Parallelverarbeitungseinheit der 2 gemäß einer Ausführungsform dar.
3B stellt eine Partitionseinheit der Parallelverarbeitungseinheit der 2 gemäß einer Ausführungsform dar.
4 stellt den Streaming-Multiprozessor der 3A gemäß einer Ausführungsform dar.
5 stellt ein Ein-Chip-System mit der Parallelverarbeitungseinheit der 2 gemäß einer Ausführungsform dar.
6 ist gemäß einer Ausführungsform ein Konzeptdiagramm einer Grafikverarbeitungspipeline, welche durch die Parallelverarbeitungseinheit der 2 implementiert ist.
7 stellt ein beispielhaftes System dar, in welchem die verschiedenen Architekturen und/oder Funktionalitäten von allen Ausführungsformen implementiert werden können.
8 stellt einen Flussplan eines Verfahrens zum Durchführen einer Knotentraversierung gemäß einer Ausführungsform dar, wobei komprimierte Traversierungs-Stackeinträge eingesetzt werden.
9 stellt gemäß einer Ausführungsform beispielhafte Traversierungs-Stackeinträge dar, welche während einer Knoten-Traversierung eingesetzt werden.
10 stellt gemäß einer Ausführungsform eine beispielhafte XOR-basierte Traversierungs-Reihenfolge bei zwei Dimensionen dar.
11 stellt einen beispielhaften Speicherentwurf gemäß einer Ausführungsform dar.
12 stellt eine beispielhafte Kodierung gemäß einer Ausführungsform dar.
13 stellt gemäß einer Ausführungsform einen beispielhaften Knotengruppeneintrag und einen beispielhaften Dreieck-Gruppeneintrag dar.

DETAILLIERTE BESCHREIBUNG
1 stellt einen Flussplan eines Verfahrens 100 zum Durchführen einer Traversierungs-Stack-Komprimierung bzw. Kompression gemäß einer Ausführungsform dar. Wie im Schritt 102 dargestellt ist, wird eine hierarchische Datenstruktur mit mehr als zwei Kindern pro Knoten traversiert. Bei einer Ausführungsform kann die hierarchische Datenstruktur eine Hüllkörper-Hierarchie („Bounding Volume Hierarchy“ (BVH)), wie z.B. eine große oder weite BVH, einen Octree, usw., aufweisen. Bei einer anderen Ausführungsform kann die hierarchische Datenstruktur als Teil von einer oder von mehreren Operationen (z.B. einer Raytracing-Operation als Teil einer Kollisionserkennungs-Operation, usw.) traversiert werden.
Darüber hinaus wird, wie es in Operation 104 dargestellt ist, während des Traversierens mindestens ein Stackeintrag unter Verwendung eines Prozessors erzeugt, wobei jeder Stackeintrag mehrere geschnittene Knoten enthält. Bei einer Ausführungsform können die geschnittenen Knoten Geschwisterknoten umfassen. Bei einer anderen Ausführungsform können die geschnittenen Knoten bestimmt werden, indem ein Knoten ausgewählt wird und eine Schnittmenge mit den Bounding Boxes aller Kinder in dem Knoten gebildet wird.
Der Knoten kann zum Beispiel aus einer aktuellen Knotengruppe ausgewählt werden. Bei einem anderen Beispiel kann der Knoten abhängig von einer bestimmten Traversierungs-Reihenfolge ausgewählt werden. Natürlich kann der Knoten auch gemäß irgendeiner anderen Vorgehensweise ausgewählt werden.
Darüber hinaus kann gemäß einer Ausführungsform der mindestens eine Stackeintrag in einer komplexen Form (z. B. in einem komprimierten Format, usw.) erzeugt werden. Bei einer anderen Ausführungsform werden mehrere verschiedene Stackeinträge während der Traversierung der hierarchischen Datenstruktur erzeugt. Zum Beispiel kann ein einziger Stackeintrag eine interne Knotengruppe (z. B. einen oder mehrere interne Knoten, welche durch denselben Elter referenziert werden) repräsentieren. Bei einem anderen Beispiel kann ein einzelner Stackeintrag eine Primitiv-Knotengruppe (z. B. ein oder mehrere Primitive (Blattknoten), welche durch einen internen Knoten referenziert werden, usw.) repräsentieren. Bei noch einem anderen Beispiel kann ein Stackeintrag für jeden verschiedenen Primitivtyp erzeugt werden, welcher während der Traversierung geschnitten wird. Zum Beispiel können die Primitivtypen einen oder mehrere von Dreiecken, benutzerdefinierten abstrakten Primitiven, Kugeln, Vierecke, usw. sein.
Darüber hinaus kann bei einer Ausführungsform jeder individuelle Stackeintrag einen Basisindex zu einem Knoten in der hierarchischen Datenstruktur aufweisen. Bei einer anderen Ausführungsform kann jeder individuelle Stackeintrag eine Bitmaske aufweisen, welche anzeigt, welcher der mehreren geschnittenen Knoten noch nicht verarbeitet worden ist. Bei noch einer anderen Ausführungsform kann jeder individuelle Stackeintrag eine interne Knotengruppe repräsentieren und kann ein Feld aufweisen, welches den Typ von jedem Kind anzeigt. Bei noch einer anderen Ausführungsform kann jeder individuelle Stackeintrag eine interne Knotengruppe repräsentieren und kann ein Feld aufweisen, welches Kinder repräsentiert, welche in einer bestimmten Traversierungs-Reihenfolge zu traversieren sind.
Darüber hinaus wird, wie es in Schritt 106 dargestellt ist, während der Traversierung der mindestens eine Stackeintrag einem komprimierten Traversierungs-Stack hinzugefügt, welcher in einem Speicher gespeichert ist, wobei der Prozessor eingesetzt wird. Bei einer Ausführungsform kann der Speicher einen Gemeinschaftsspeicher (z. B. einen SM-lokalen Gemeinschaftsspeicher, usw.) aufweisen. Bei einer anderen Ausführungsform kann der Speicher einen Thread-Iokalen Speicher aufweisen. Bei noch einer anderen Ausführungsform kann jeder individuelle Stackeintrag als ein individueller Eintrag in dem komprimierten Traversierungs-Stack gespeichert sein.
Auf diese Weise kann der Stack komprimiert werden, und ein Speicherverkehr bezüglich des komprimierten Stacks kann verringert werden, was eine verfügbare Verarbeitungsspeicherbandbreite erhöhen kann. Genauer gesagt kann, anstelle eines Speicherns von jedem geschnittenen Knoten als individueller Eintrag in dem Stack, eine Mehrzahl von geschnittenen Knoten in dem Stack als ein einziger Eintrag gespeichert werden, was eine Größe des Stacks reduziert (was wiederum die Speicherverwendung reduziert) wie auch die Speicherbandbreite reduziert, welche eingesetzt wird, um dem Stack etwas hinzuzufügen oder von diesem zu entnehmen. Dies kann die Leistung eines Systems erhöhen, welches eine Traversierung einer hierarchischen Datenstruktur durchführt.
Es werden nun weitere veranschaulichende Informationen zu verschiedenen optionalen Architekturen und Merkmalen dargelegt, mit denen das vorgenannte Framework nach den Wünschen des Benutzers implementiert werden kann oder auch nicht. Es sei ausdrücklich darauf hingewiesen, dass die folgenden Informationen zur Veranschaulichung dargelegt werden und nicht als einschränkend aufgefasst werden sollen. Jedes der folgenden Merkmale kann wahlweise mit oder ohne Ausschluss anderer beschriebener Merkmale eingesetzt werden.
PARALLELVERARBEITUNGSARCHITEKTUR
2 stellt eine Parallelverarbeitungseinheit (PPU) 200 gemäß einer Ausführungsform dar. In einer Ausführungsform ist die PPU 200 ein Multi-Thread-Prozessor, der auf einem oder mehreren integrierten Schaltkreisbauelementen implementiert ist. Die PPU 200 ist eine latenzverbergende Architektur, die so konzipiert ist, dass sie eine große Anzahl von Threads parallel verarbeiten kann. Ein Thread (d.h. ein Ausführungs-Thread) ist eine Instanziierung eines Satzes von Befehlen, die für die Ausführung durch die PPU 200 konfiguriert sind. In einer Ausführungsform ist die PPU 200 eine Grafikverarbeitungseinheit (Grafikprozessor), die zum Implementieren einer Grafik-Rendering-Pipeline zum Verarbeiten von dreidimensionalen (3D-)Grafikdaten zum Erzeugen von zweidimensionalen (2D-)Bilddaten für die Anzeige auf einer Anzeigevorrichtung, wie beispielsweise einer Flüssigkristallanzeige (LCD)-Vorrichtung, konfiguriert ist. In anderen Ausführungsformen kann die PPU 200 für die Durchführung von Universalberechnungen verwendet werden. Obwohl hierin ein exemplarischer Parallelprozessor zu veranschaulichenden Zwecken bereitgestellt wird, ist dringend darauf hinzuweisen, dass dieser Prozessor nur zu veranschaulichenden Zwecken aufgeführt ist und dass jeder Prozessor als Ergänzung und/oder Ersatz für diesen eingesetzt werden kann.
Wie in 2 dargestellt ist, beinhaltet die PPU 200 eine Input/Output (I/O)-Einheit 205, eine Host-Schnittstelleneinheit 210, eine Front-End-Einheit 215, eine Schedulereinheit 220, eine Arbeitsverteilungseinheit 225, einen Netzwerkknoten bzw. Hub 230, ein Koppelfeld (Xbar) 270, einen oder mehrere allgemeine Verarbeitungscluster (GPCs) 250 und eine oder mehrere Partitionseinheiten 280. Die PPU 200 kann über einen Systembus 202 an einen Host-Prozessor oder andere Peripheriegeräte angeschlossen sein. Die PPU 200 kann auch an einen lokalen Speicher mit einer Anzahl von Speichervorrichtungen 204 angeschlossen sein. In einer Ausführungsform kann der lokale Speicher eine Anzahl von dynamischen Direktzugriffsspeicher-(DRAM)-Bauelementen umfassen.
Die I/O-Einheit 205 ist konfiguriert, um über den Systembus 202 Kommunikationen (d.h. Befehle, Daten, etc.) von einem Host-Prozessor (nicht dargestellt) über den Systembus 202 zu senden und zu empfangen. Die I/O-Einheit 205 kann mit dem Host-Prozessor direkt über den Systembus 202 oder über eine oder mehrere Zwischenvorrichtungen, wie beispielsweise eine Speicherbrücke, kommunizieren. In einer Ausführungsform implementiert die I/O-Einheit 205 eine Peripheral Component Interconnect Express (PCIe)-Schnittstelle für die Kommunikation über einen PCIe-Bus. In alternativen Ausführungsformen kann die I/O-Einheit 205 andere Arten von bekannten Schnittstellen für die Kommunikation mit externen Vorrichtungen implementieren.
Die I/O-Einheit 205 ist mit einer Host-Schnittstelleneinheit 210 gekoppelt, die über den Systembus 202 empfangene Pakete dekodiert. In einer Ausführungsform stellen die Pakete Befehle dar, die so konfiguriert sind, dass die PPU 200 verschiedene Operationen durchführt. Die Hostschnittstelleneinheit 210 überträgt die dekodierten Befehle an verschiedene andere Einheiten der PPU 200, wie es in den Befehlen angegeben ist. So können beispielsweise einige Befehle an die Front-End-Einheit 215 übertragen werden. Andere Befehle können an den Hub 230 oder andere Einheiten der PPU 200 übertragen werden, wie zum Beispiel eine oder mehrere Kopiermaschinen, einen Video-Encoder, einen Videodecoder, eine Spannungsverwaltungseinheit, usw. (nicht explizit dargestellt). Mit anderen Worten, die Host-Schnittstelleneinheit 210 ist konfiguriert, um die Kommunikation zwischen und unter den verschiedenen logischen Einheiten der PPU 200 zu routen.
In einer Ausführungsform kodiert ein vom Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einen Zwischenspeicher, der der PPU 200 Arbeit zur Verarbeitung bereitstellt. Eine Arbeit kann eine Reihe von Anweisungen und Daten umfassen, die durch diese Anweisungen verarbeitet werden sollen. Der Puffer ist ein Bereich in einem Speicher, der sowohl für den Host-Prozessor als auch für die PPU 200 zugänglich ist (d.h. lesen/schreiben). So kann beispielsweise die Host-Schnittstelleneinheit 210 konfiguriert werden, um auf den Puffer in einem mit dem Systembus 202 verbundenen Systemspeicher zuzugreifen, und zwar über Speicheranforderungen, die über den Systembus 202 von der I/O-Einheit 205 übertragen werden. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und überträgt dann einen Zeiger auf den Start des Befehlsstroms an die PPU 200. Die Host-Schnittstelleneinheit 210 stellt der Front-End-Einheit 215 Zeiger auf einen oder mehrere Befehlsströme zur Verfügung. Die Front-End-Einheit 215 verwaltet den einen oder die mehreren Streams bzw. Ströme, liest Befehle aus den Streams und leitet Befehle an die verschiedenen Einheiten der PPU 200 weiter.
Die Front-End-Einheit 215 ist mit einer Scheduler-Einheit 220 gekoppelt, die die verschiedenen GPCs 250 für die Verarbeitung von Tasks konfiguriert, welche durch den einen oder die mehreren Streams definiert sind. Die Scheduler-Einheit 220 ist konfiguriert, um Zustandsinformationen in Bezug auf die verschiedenen Tasks zu verfolgen, die von der Scheduler-Einheit 220 verwaltet werden. Der Zustand kann anzeigen, welchem GPC 250 eine Task zugeordnet ist, ob die Task aktiv oder inaktiv ist, welche Prioritätsstufe der Task zugeordnet ist, und so weiter. Die Scheduler-Einheit 220 verwaltet die Ausführung einer Vielzahl von Tasks auf einem oder mehreren GPCs 250.
Die Scheduler-Einheit 220 ist mit einer Arbeitsverteilungseinheit 225 gekoppelt, die konfiguriert ist, um Tasks zur Ausführung auf die GPCs 250 zu verteilen. Die Arbeitsverteilungseinheit 225 kann eine Anzahl von geplanten Tasks verfolgen, die sie von der Scheduler-Einheit 220 erhalten hat. In einer Ausführungsform verwaltet die Arbeitsverteilungseinheit 225 für jeden der GPCs 250 einen Pool anstehender Tasks und einen Pool aktiver Tasks. Der Pool anstehender Tasks kann aus einer Anzahl von Slots (z.B. 32 Slots) bestehen, die Tasks enthalten, die von einem bestimmten GPC 250 bearbeitet werden sollen. Der Pool aktiver Tasks kann eine Anzahl von Feldern bzw. Slots (z.B. 4 Slots) für Tasks umfassen, die von den GPCs 250 aktiv bearbeitet werden. Wenn ein GPC 250 die Ausführung einer Task beendet, wird diese Task aus dem Pool aktiver Tasks für den GPC 250 geworfen und eine der anderen Tasks aus dem Pool anstehender Tasks ausgewählt und zur Ausführung auf dem GPC 250 eingeplant. Wenn eine aktive Task auf dem GPC 250 inaktiv ist, z. B. während des Wartens auf die Auflösung einer Datenabhängigkeit, kann die aktive Task aus dem GPC 250 geworfen und in den Pool der anstehenden Tasks zurückgeführt werden, während eine andere Task im Pool der anstehenden Tasks ausgewählt und für die Ausführung auf dem GPC 250 eingeplant wird.
Die Arbeitsverteilungseinheit 225 kommuniziert mit einem oder mehreren GPCs 250 über die XBar 270. Die XBar 270 ist ein Verbindungsnetzwerk, das viele der Einheiten der PPU 200 mit anderen Einheiten der PPU 200 koppelt. So kann beispielsweise die XBar 270 so konfiguriert werden, dass sie die Arbeitsverteilungseinheit 225 mit einem bestimmten GPC 250 koppelt. Obwohl es nicht explizit dargestellt ist, sind eine oder mehrere andere Einheiten der PPU 200 mit der Host-Einheit 210 gekoppelt. Die anderen Einheiten können auch über einen Netzwerkknoten bzw. Hub 230 mit der XBar 270 verbunden sein.
Die Tasks werden von der Scheduler-Einheit 220 verwaltet und von der Arbeitsverteilungseinheit 225 an einen GPC 250 gesendet. Der GPC 250 ist so konfiguriert, dass er die Task bearbeitet und Ergebnisse erzeugt. Die Ergebnisse können von anderen Tasks innerhalb des GPC 250 aufgenommen, über die XBar 270 an einen anderen GPC 250 weitergeleitet oder im Speicher 204 gespeichert werden. Die Ergebnisse können über die Partitionseinheiten 280 in den Speicher 204 geschrieben werden, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in den/aus dem Speicher 204 implementieren. In einer Ausführungsform beinhaltet die PPU 200 eine Anzahl U von Partitionseinheiten 280, die gleich der Anzahl der einzelnen und getrennten Speichervorrichtungen 204 ist, die mit der PPU 200 gekoppelt sind. Eine Partitionseinheit 280 wird im Folgenden in Verbindung mit 3B näher beschrieben.
In einer Ausführungsform führt ein Host-Prozessor einen Treiberkern aus, der eine Anwendungsprogrammierschnittstelle (API) implementiert, mit der eine oder mehrere auf dem Host-Prozessor ausgeführte Anwendungen Operationen zur Ausführung auf der PPU 200 einplanen können. Eine Anwendung kann Anweisungen (z.B. API-Aufrufe) erzeugen, die den Treiberkern dazu veranlassen, einen oder mehrere Tasks für die Ausführung durch die PPU 200 zu erzeugen. Der Treiberkern gibt Tasks an einen oder mehrere Streams aus, die von der PPU 200 verarbeitet werden. Jede Task kann eine oder mehrere Gruppen von verwandten Threads umfassen, die in diesem Dokument als Warp bezeichnet werden. Ein Thread-Block kann sich auf eine Vielzahl von Gruppen von Threads beziehen, einschließlich Anweisungen zur Ausführung der Task. Threads in der gleichen Gruppe von Threads können Daten über den Gemeinschaftsspeicher austauschen. In einer Ausführungsform umfasst eine Gruppe von Threads 32 zueinander in Beziehung stehende Threads.
3A veranschaulicht einen GPC 250 der PPU 200 von 2 gemäß einer Ausführungsform. Wie in 3A dargestellt ist, beinhaltet jeder GPC 250 eine Reihe von Hardwareeinheiten zur Bearbeitung von Tasks. In einer Ausführungsform beinhaltet jeder GPC 250 einen Pipeline-Manager 310, eine Pre-Raster-Operations-Einheit (PROP) 315, eine Raster-Engine 325, ein Arbeitsverteilungs-Koppelfeld (WDX) 380, eine Speicherverwaltungseinheit (MMU) 390 und einen oder mehrere Texturverarbeitungscluster (TPCs) 320. Es ist zu beachten, dass der GPC 250 von 3A anstelle oder zusätzlich zu den in 3A dargestellten Einheiten weitere Hardwareeinheiten beinhalten kann.
In einer Ausführungsform wird der Betrieb des GPC 250 durch den Pipelinemanager 310 gesteuert. Der Pipelinemanager 310 verwaltet die Konfiguration eines oder mehrerer TPCs 320 für die Bearbeitung von Tasks, die dem GPC 250 zugeordnet sind. In einer Ausführungsform kann der Pipelinemanager 310 mindestens ein der einen oder mehreren TPCs 320 so konfigurieren, dass es mindestens einen Teil einer grafischen Rendering-Pipeline implementiert. So kann beispielsweise ein TPC 320 konfiguriert werden, um ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 340 auszuführen. Der Pipeline-Manager 310 kann auch konfiguriert werden, um von der Arbeitsverteilungseinheit 225 empfangene Pakete an die entsprechenden logischen Einheiten innerhalb des GPC 250 weiterzuleiten. So können beispielsweise einige Pakete an Hardwareeinheiten mit fester Funktion im PROP 315 und/oder in der Raster-Engine 325 geroutet werden, während andere Pakete an die TPCs 320 zur Verarbeitung durch die Primitiv-Engine 335 oder den SM 340 geroutet werden können.
Die PROP-Einheit 315 ist konfiguriert, um die von der Raster-Engine 325 und den TPCs 320 erzeugten Daten an eine Raster-Operations- (ROP)-Einheit in der Partitionseinheit 280 weiterzuleiten, die im Folgenden näher beschrieben wird. Die PROP-Einheit 315 kann auch konfiguriert werden, um Optimierungen für das Farbmischen, das Organisieren von Pixeldaten, das Durchführen von Adressübersetzungen und dergleichen durchzuführen.
Die Raster-Engine 325 beinhaltet eine Reihe von Hardware-Einheiten mit festgelegter Funktion, die für die Durchführung verschiedener Rasteroperationen konfiguriert sind. In einer Ausführungsform beinhaltet die Raster-Engine 325 eine Setup-Engine, eine Grob-Raster-Engine, eine Culling-Engine, eine Clipping-Engine, eine Fein-Raster-Engine und eine Kachel-Vereinigungs-Engine. Die Setup-Engine empfängt transformierte Vertices und erzeugt Ebenengleichungen, die dem durch die Vertices definierten geometrischen Primitiv zugeordnet sind. Die Ebenengleichungen werden an die Grob-Raster-Engine übertragen, um Abdeckungsinformationen (z.B. eine x,y-Abdeckmaske für eine Kachel) für das Primitiv zu erzeugen. Die Ausgabe der Grob-Raster-Engine kann an die Culling-Engine übertragen werden, wo Fragmente, die dem Primitiv zugeordnet sind und einen z-Test nicht bestehen, aussortiert werden, und an eine Clipping-Engine übertragen werden, wo Fragmente, die außerhalb eines Sichtfeldes liegen, abgeschnitten werden. Die Fragmente, die das Clipping und Culling überleben, können an eine Fein-Raster-Engine übergeben werden, um Attribute für die Pixelfragmente basierend auf den von der Setup-Engine erzeugten Ebenengleichungen zu erzeugen. Die Ausgabe der Raster-Engine 380 umfasst Fragmente, die beispielsweise von einem in einem TPC 320 implementierten Fragment-Shader verarbeitet werden sollen.
Jeder im GPC 250 enthaltene TPC 320 beinhaltet einen M-Pipe-Controller (MPC) 330, eine Primitiv-Engine 335, einen oder mehrere SMs 340 und eine oder mehrere Textureinheiten 345. Der MPC 330 steuert den Betrieb des TPC 320 und leitet die vom Pipelinemanager 310 empfangenen Pakete an die entsprechenden Einheiten des TPC 320 weiter. So können beispielsweise Pakete, die einem Knoten zugeordnet sind, an die Primitiv-Engine 335 weitergeleitet werden, die konfiguriert ist, um die dem Knoten zugeordneten Knotenattribute aus dem Speicher 204 zu holen. Im Gegensatz dazu können Pakete, die einem Shader-Programm zugeordnet sind, an den SM 340 übertragen werden.
In einer Ausführungsform sind die Textureinheiten 345 konfiguriert, um Texturkarten (z.B. ein 2D-Array von Texturen) aus dem Speicher 204 zu laden und die Texturkarten abzutasten, um abgetastete Texturwerte für die Verwendung in Shader-Programmen zu erzeugen, die von dem SM 340 ausgeführt werden. Die Textureinheiten 345 implementieren Texturoperationen wie das Filtern von Operationen mit Hilfe von Mip-Maps (d.h. Texturkarten mit unterschiedlichem Detaillierungsgrad). Die Textureinheit 345 wird auch als Lade-/Speicherpfad für den SM 340 bis zur MMU 390 verwendet. In einer Ausführungsform beinhaltet jeder TPC 320 zwei (2) Textur-Einheiten 345.
Der SM 340 umfasst einen programmierbaren Streaming-Prozessor, der konfiguriert ist, um Tasks zu bearbeiten, die durch eine Reihe von Threads repräsentiert werden. Jeder SM 340 ist multi-threaded und konfiguriert, um eine Vielzahl von Threads (z.B. 32 Threads) aus einer bestimmten Gruppe von Threads gleichzeitig auszuführen. In einer Ausführungsform implementiert der SM 340 eine SIMD-Architektur (Single-Instruction, Multiple-Data), bei der jeder Thread in einer Gruppe von Threads (d.h. ein Warp) konfiguriert ist, um einen anderen Datensatz basierend auf demselben Befehlssatz zu verarbeiten. Alle Threads in der Gruppe der Threads führen die gleichen Anweisungen aus. In einer weiteren Ausführungsform implementiert der SM 340 eine SIMT-Architektur (Single-Instruction, Multiple Thread), bei der jeder Thread in einer Gruppe von Threads konfiguriert ist, um einen anderen Datensatz zu verarbeiten, der auf demselben Befehlssatz basiert, wobei jedoch einzelne Threads in der Gruppe von Threads während der Ausführung divergieren können. Mit anderen Worten, wenn eine Anweisung für die Gruppe von Threads zur Ausführung gesendet wird, können einige Threads in der Gruppe von Threads aktiv sein und so den Befehl ausführen, während andere Threads in der Gruppe von Threads inaktiv sein können, wodurch eine No-Operation (NOP) anstelle der Ausführung des Befehls ausgeführt wird. Der SM 340 kann im Folgenden in Verbindung mit 4 näher beschrieben werden.
Die MMU 390 bietet eine Schnittstelle zwischen dem GPC 250 und der Partitionseinheit 280. Die MMU 390 kann die Übersetzung virtueller Adressen in physikalische Adressen, den Speicherschutz und die Konkurrenzbereinigung von Speicheranforderungen ermöglichen. In einer Ausführungsform stellt die MMU 390 einen oder mehrere Translation Lookaside Buffer (TLBs) zur Verfügung, um die Übersetzung von virtuellen Adressen in physikalische Adressen im Speicher 204 zu verbessern.
3B veranschaulicht eine Partitionseinheit 280 der PPU 200 von 2 gemäß einer Ausführungsform. Wie in 3B dargestellt, beinhaltet die Partitionseinheit 280 eine Raster Operations (ROP)-Einheit 350, einen Level-2 (L2) Cache 360, eine Speicherschnittstelle 370 und ein L2 Koppelfeld (XBar) 365. Die Speicherschnittstelle 370 ist mit dem Speicher 204 gekoppelt. Die Speicherschnittstelle 370 kann 16, 32, 64, 128-Bit-Datenbusse oder dergleichen für die Hochgeschwindigkeits-Datenübertragung implementieren. In einer Ausführungsform umfasst die PPU 200 U Speicherschnittstellen 370, eine Speicherschnittstelle 370 pro Partitionseinheit 280, wobei jede Partitionseinheit 280 mit einer entsprechenden Speichervorrichtung 204 verbunden ist. So kann die PPU 200 beispielsweise an bis zu U Speicherbauelemente 204 angeschlossen werden, wie z.B. Grafik mit doppelter Datenrate, Version 5, synchroner dynamischer Direktzugriffsspeicher (GDDR5 SDRAM). In einer Ausführungsform implementiert die Speicherschnittstelle 370 eine DRAM-Schnittstelle und U ist gleich 8.
In einer Ausführungsform implementiert die PPU 200 eine mehrstufige Speicherhierarchie. Der Speicher 204 befindet sich außerhalb des Chips im SDRAM, das mit der PPU 200 gekoppelt ist. Daten aus dem Speicher 204 können abgerufen und im L2-Cache 360 gespeichert werden, der sich auf dem Chip befindet und zwischen den verschiedenen GPCs 250 geteilt wird. Wie dargestellt ist, beinhaltet jede Partitionseinheit 280 einen Abschnitt des L2-Cache 360, der einem entsprechenden Speicherbauelement 204 zugeordnet ist. Untergeordnete Caches können dann in verschiedenen Einheiten innerhalb der GPCs 250 implementiert werden. So kann beispielsweise jeder der SMs 340 einen Level One (L1)-Cache implementieren. Der L1-Cache ist ein privater Speicher, der für einen bestimmten SM 340 reserviert ist. Daten aus dem L2-Cache 360 können abgerufen und in jedem der L1-Caches zur Verarbeitung in den Funktionseinheiten des SMs 340 gespeichert werden. Der L2-Cache 360 ist mit der Speicherschnittstelle 370 und der XBar 270 gekoppelt.
Die ROP-Einheit 350 beinhaltet einen ROP-Manager 355, eine Color ROP (CROP) Einheit 352 und eine Z ROP (ZROP) Einheit 354. Die CROP-Einheit 352 führt Rasteroperationen im Zusammenhang mit Pixelfarben durch, wie z.B. Farbkompression, Pixelblending und dergleichen. Die ZROP-Einheit 354 führt in Verbindung mit der Raster-Engine 325 eine Tiefenprüfung durch. Die ZROP-Einheit 354 empfängt eine Tiefe für eine Abtastposition, die einem Pixelfragment von der Culling-Engine der Raster-Engine 325 zugeordnet ist. Die ZROP-Einheit 354 testet die Tiefe gegen eine entsprechende Tiefe in einem Tiefenpuffer für eine dem Fragment zugeordnete Abtastposition. Wenn das Fragment den Tiefentest für die Probenposition besteht, aktualisiert die ZROP-Einheit 354 den Tiefenpuffer und sendet ein Ergebnis des Tiefentests an die Raster-Engine 325. Der ROP-Manager 355 steuert den Betrieb der ROP-Einheit 350. Es ist zu beachten, dass die Anzahl der Partitionseinheiten 280 von der Anzahl der GPCs 250 abweichen kann und daher jede ROP-Einheit 350 mit jedem der GPCs 250 gekoppelt werden kann. Daher verfolgt der ROP-Manager 355 die von den verschiedenen GPCs 250 empfangenen Pakete und bestimmt, zu welchem GPC 250 ein von der ROP-Einheit 350 erzeugtes Ergebnis weitergeleitet wird. Die CROP-Einheit 352 und die ZROP-Einheit 354 sind über eine L2 XBar 365 mit dem L2-Cache 360 gekoppelt.
4 stellt den Streaming-Multiprozessor 340 von 3A gemäß einer Ausführungsform dar. Wie in 4 dargestellt ist, beinhaltet der SM 340 einen Befehls-Cache 405, eine oder mehrere Scheduler-Einheiten 410, eine Registerdatei 420, einen oder mehrere Verarbeitungskerne 450, eine oder mehrere Special Function Units (SFUs) 452, eine oder mehrere Load/Speicher-Einheiten (LSUs) 454, ein Verbindungsnetzwerk 480, einen Gemeinschaftsspeicher 470 und einen L1-Cache 490.
Wie vorstehend beschrieben ist, plant die Arbeitsverteilungseinheit 225 Tasks zur Ausführung auf den GPCs 250 der PPU 200 ein. Die Tasks werden einem bestimmten TPC 320 innerhalb eines GPC 250 zugeordnet und, wenn die Task einem ShaderProgramm zugeordnet ist, kann die Aufgabe einem SM 340 zugeordnet werden. Die Scheduler-Einheit 410 empfängt die Tasks von der Arbeitsverteilungseinheit 225 und verwaltet die Befehlsplanung für eine oder mehrere Gruppen von Threads (z.B. Warps), die dem SM 340 zugeordnet sind. Die Scheduler-Einheit 410 plant Threads zur Ausführung in Gruppen von parallelen Threads, wobei jede Gruppe als Warp bezeichnet wird. In einer Ausführungsform beinhaltet jeder Warp 32 Threads. Die Scheduler-Einheit 410 kann eine Vielzahl von verschiedenen Warps verwalten, die Warps zur Ausführung einplanen und dann während jedes Taktzyklus Anweisungen von der Vielzahl von verschiedenen Warps an die verschiedenen Funktionseinheiten (d.h. Kerne 350, SFUs 352 und LSUs 354) zuteilen.
In einer Ausführungsform beinhaltet jede Scheduler-Einheit 410 eine oder mehrere Befehlsverteilungseinheiten 415. Jede Verteilungseinheit 415 ist konfiguriert, um Anweisungen an eine oder mehrere der Funktionseinheiten zu senden. In der in 4 dargestellten Ausführungsform beinhaltet die Scheduler-Einheit 410 zwei Verteilungseinheiten 415, die es ermöglichen, während jedes Taktzyklus zwei verschiedene Anweisungen von demselben Warp abzufertigen. In alternativen Ausführungsformen kann jede Scheduler-Einheit 410 eine einzelne Verteilungseinheit 415 oder zusätzliche Verteilungseinheiten 415 beinhalten.
Jeder SM 340 enthält eine Registerdatei 420, die einen Satz von Registern für die Funktionseinheiten des SM 340 bereitstellt. In einer Ausführungsform ist die Registerdatei 420 auf jede der Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein bestimmter Teil der Registerdatei 420 zugeordnet ist. In einer weiteren Ausführungsform wird die Registerdatei 420 auf die verschiedenen Warps aufgeteilt, die von dem SM 340 ausgeführt werden. Die Registerdatei 420 bietet Zwischenspeicher für Operanden, die mit den Datenpfaden der Funktionseinheiten verbunden sind.
Jeder SM 340 umfasst L Verarbeitungskerne 450. In einer Ausführungsform beinhaltet der SM 340 eine große Anzahl (z.B. 128, etc.) von verschiedenen Verarbeitungskernen 450. Jeder Kern 450 kann eine vollständig hintereinander ausführende Einzelpräzisionsverarbeitungseinheit beinhalten, die eine Gleitkommaarithmetik-Logikeinheit und eine ganzzahlige arithmetische Logikeinheit beinhaltet. Der Kern 450 kann auch eine Doppelpräzisionsverarbeitungseinheit mit einer Gleitkommaarithmetik beinhalten. In einer Ausführungsform implementieren die Gleitkommaarithmetik-Logikeinheiten den Standard IEEE 754-2008 für Gleitkommaarithmetik. Jeder SM 340 umfasst auch M SFUs 452, die spezielle Funktionen ausführen (z.B. Attributbewertung, reziproke Quadratwurzel und dergleichen), und N LSUs 454, die Lade- und Speicheroperationen zwischen dem Gemeinschaftsspeicher 470 oder L1-Cache 490 und der Registerdatei 420 implementieren. In einer Ausführungsform beinhaltet der SM 340 128 Kerne 450, 32 SFUs 452 und 32 LSUs 454.
Jeder SM 340 beinhaltet ein Verbindungsnetzwerk 480, das jede der Funktionseinheiten mit der Registerdatei 420 und die LSU 454 mit der Registerdatei 420, dem Gemeinschaftsspeicher 470 und dem L1-Cache 490 verbindet. In einer Ausführungsform ist das Verbindungsnetzwerk 480 ein Koppelfeld, das konfiguriert werden kann, um jede der Funktionseinheiten mit einem der Register in der Registerdatei 420 zu verbinden und die LSUs 454 mit der Registerdatei und den Speicherplätzen im Gemeinschaftsspeicher 470 und L1-Cache 490 zu verbinden.
Der Gemeinschaftsspeicher 470 ist eine Anordnung von On-Chip-Speichern, die die Datenspeicherung und -kommunikation zwischen dem SM 340 und der Primitiv-Engine 335 sowie zwischen den Threads im SM 340 ermöglicht. In einer Ausführungsform umfasst der Gemeinschaftsspeicher 470 eine Speicherkapazität von 64KB. Ein L1-Cache 490 befindet sich im Pfad von dem SM 340 zur Partitionseinheit 280. Der L1-Cache 490 kann zum Cache-Lesen und Schreiben verwendet werden. In einer Ausführungsform umfasst der L1-Cache 490 eine Speicherkapazität von 24KB.
Die oben beschriebene PPU 200 kann konfiguriert werden, um hochparallele Berechnungen viel schneller durchzuführen als herkömmliche CPUs. Paralleles Rechnen hat Vorteile bei der Grafikverarbeitung, Datenkompression, Biometrie, Stream-Verarbeitungsalgorithmen und dergleichen.
Bei der Konfiguration für die allgemeine parallele Berechnung kann eine einfachere Konfiguration verwendet werden. In diesem Modell werden, wie in 2 dargestellt ist, Grafikverarbeitungseinheiten mit festgelegter Funktion umgangen, wodurch ein wesentlich einfacheres Programmiermodell entsteht. In dieser Konfiguration weist die Arbeitsverteilungseinheit 225 Blöcke von Threads direkt den TPCs 320 zu und verteilt sie. Die Threads in einem Block führen das gleiche Programm aus, wobei eine eindeutige Thread-ID in der Berechnung verwendet wird, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, wobei der SM 340 verwendet wird, um das Programm auszuführen und Berechnungen durchzuführen, wobei der Gemeinschaftsspeicher 470 eingesetzt wird, um zwischen Threads zu kommunizieren, und die LSU 454 eingesetzt wird, um den globalen Speicher über den Partition L1-Cache 490 und die Partitionseinheit 280 zu lesen und zu schreiben.
Wenn der SM 340 für die allgemeine parallele Berechnung konfiguriert ist, kann er auch Befehle schreiben, mit denen die Scheduler-Einheit 220 neue Arbeiten auf den TPCs 320 ablaufen lassen kann.
In einer Ausführungsform umfasst die PPU 200 eine Grafikprozessoreinheit (GPU). Die PPU 200 ist konfiguriert, um Befehle zu empfangen, die Shader-Programme zur Verarbeitung von Bilddaten spezifizieren. Grafikdaten können als eine Reihe von Primitives, wie Punkte, Linien, Dreiecke, Quads, Dreiecksstreifen und dergleichen, definiert werden. Typischerweise beinhaltet ein Primitiv Daten, die eine Anzahl von Knoten für das Primitiv angeben (z.B. in einem Modell-Raum-Koordinatensystem) sowie Attribute, die jedem Knoten des Primitives zugeordnet sind. Die PPU 200 kann konfiguriert werden, um die Grafik-Primitives zu verarbeiten, um einen Frame-Puffer zu erzeugen (d.h. Pixeldaten für jedes der Pixel des Displays).
Eine Anwendung schreibt Modelldaten für eine Szene (d.h. eine Sammlung von Knoten und Attributen) in einen Speicher, wie beispielsweise einen Systemspeicher oder Speicher 204. Die Modelldaten definieren jedes der Objekte, die auf einer Anzeige sichtbar sein können. Die Anwendung führt dann einen API-Aufruf an den Treiberkern durch, um die Modelldaten rendern und darstellen zu lassen. Der Treiberkern liest die Modelldaten und schreibt Befehle in einen oder mehrere Streams, um Operationen zur Verarbeitung der Modelldaten durchzuführen. Die Befehle können auf verschiedene Shader-Programme verweisen, die auf den SMs 340 der PPU 200 implementiert werden sollen, einschließlich eines oder mehrerer Vertex-Shader, Rumpf-Shader, Domain-Shader, Geometrie-Shader und Pixel-Shader. So kann bzw. können beispielsweise einer oder mehrere der SMs 340 konfiguriert werden, um ein Vertex-Shader-Programm auszuführen, das eine Anzahl von durch die Modelldaten definierten Vertices verarbeitet. In einer Ausführungsform können die verschiedenen SMs 340 konfiguriert werden, um verschiedene Shader-Programme gleichzeitig auszuführen. So kann beispielsweise eine erste Teilmenge von SMs 340 konfiguriert werden, um ein Vertex-Shader-Programm auszuführen, während eine zweite Teilmenge von SMs 340 konfiguriert werden kann, um ein Pixel-Shader-Programm auszuführen. Die erste Teilmenge der SMs 340 verarbeitet Vertex-Daten, um verarbeitete Vertex-Daten zu erzeugen, und schreibt die verarbeiteten Vertex-Daten in den L2-Cache 360 und/oder den Speicher 204. Nachdem die verarbeiteten Vertexdaten gerastert wurden (d.h. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum umgewandelt wurden), um Fragmentdaten zu erzeugen, führt die zweite Teilmenge der SMs 340 einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, die dann mit anderen verarbeiteten Fragmentdaten gemischt und in den Frame-Puffer im Speicher 204 geschrieben werden. Das Vertex-Shader-Programm und das Pixel-Shader-Programm können gleichzeitig ausgeführt werden und verschiedene Daten aus derselben Szene in einer Pipeline verarbeiten, bis alle Modelldaten für die Szene in den Frame-Puffer übertragen wurden. Anschließend wird der Inhalt des Frame-Puffers an eine Anzeigesteuerung zur Anzeige auf einer Anzeigevorrichtung übertragen.
Die PPU 200 kann in einem Desktop-Computer, einem Laptop-Computer, einem Tablet-Computer, einem Smartphone (z.B. einem drahtlosen, tragbaren Gerät), einem Personal Digital Assistant (PDA), einer Digitalkamera, einem tragbaren elektronischen Gerät und dergleichen enthalten sein. In einer Ausführungsform ist die PPU 200 auf einem einzigen Halbleitersubstrat ausgeführt. In einer weiteren Ausführungsform ist die PPU 200 in einem System auf einem Chip (SoC) zusammen mit einer oder mehreren anderen Logikeinheiten enthalten, wie beispielsweise einer CPU mit reduziertem Befehlssatz (RISC), einer Speicherverwaltungseinheit (MMU), einem Digital-Analog-Wandler (DAC) und dergleichen.
In einer Ausführungsform kann die PPU 200 auf einer Grafikkarte enthalten sein, die eine oder mehrere Speicherbauelemente 204 wie beispielsweise GDDR5 SDRAM beinhaltet. Die Grafikkarte kann konfiguriert werden, um mit einem PCIe-Steckplatz auf einem Motherboard eines Desktop-Computers zu kommunizieren, der z.B. einen Northbridge-Chipsatz und einen Southbridge-Chipsatz beinhaltet. In noch einer weiteren Ausführungsform kann die PPU 200 eine integrierte Grafikverarbeitungseinheit (iGPU) sein, die im Chipsatz (z.B. Northbridge) des Motherboards enthalten ist.
5 veranschaulicht ein System-on-Chip (SoC) 500 einschließlich der PPU 200 aus 2 gemäß einer Ausführungsform. Wie in 5 dargestellt ist, beinhaltet das SoC 500, wie oben beschrieben, eine CPU 550 und eine PPU 200. Das SoC 500 kann auch einen Systembus 202 beinhalten, um die Kommunikation zwischen den verschiedenen Komponenten des SoC 500 zu ermöglichen. Speicheranforderungen, die von der CPU 550 und der PPU 200 erzeugt werden, können über eine System-MMU 590 geleitet werden, die von mehreren Komponenten des SoC 500 gemeinsam genutzt wird. Das SoC 500 kann auch eine Speicherschnittstelle 595 beinhalten, die mit einer oder mehreren Speicherbauelementen 204 gekoppelt ist. Die Speicherschnittstelle 595 kann z.B. eine DRAM-Schnittstelle implementieren.
Obwohl es nicht explizit dargestellt ist, kann das SoC 500 neben den in 5 dargestellten Komponenten weitere Komponenten beinhalten. So kann beispielsweise das SoC 500 mehrere PPUs 200 (z.B. vier PPUs 200), einen Video-Encoder/Decoder und einen drahtlosen Breitbandsender/Empfänger sowie andere Komponenten beinhalten. In einer Ausführungsform kann das SoC 500 mit dem Speicher 204 in einer Package-on-Package (PoP)-Konfiguration zusammengefasst sein.
6 ist ein konzeptionelles Diagramm einer Grafikverarbeitungspipeline 600, die von der PPU 200 aus 2 gemäß einer Ausführungsform implementiert ist. Die Grafikverarbeitungspipeline 600 ist ein abstraktes Flussdiagramm der implementierten Verarbeitungsschritte zur Erzeugung von 2D-Computerbildern aus 3D-Geometriedaten. Wie bekannt ist, können Pipeline-Architekturen Operationen mit langen Latenzzeiten effizienter ausführen, indem sie den Betrieb in eine Vielzahl von Stufen aufteilen, wobei der Ausgang jeder Stufe mit dem Eingang der nächsten nachfolgenden Stufe gekoppelt ist. Somit empfängt die Grafikverarbeitungspipeline 600 Eingangsdaten 601, die von einer Stufe zur nächsten Stufe der Grafikverarbeitungspipeline 600 übertragen werden, um Ausgangsdaten 602 zu erzeugen. In einer Ausführungsform kann die Grafikverarbeitungspipeline 600 eine durch die O-penGL®-API definierte Grafikverarbeitungspipeline darstellen. Optional kann die Grafikverarbeitungspipeline 600 im Rahmen der Funktionalität und Architektur der vorherigen Figuren und/oder jeder (der) nachfolgenden Figur(en) implementiert werden.
Wie in 6 dargestellt ist, umfasst die Grafikverarbeitungspipeline 600 eine Pipelinearchitektur, die mehrere Stufen umfasst. Die Stufen beinhalten, sind aber nicht beschränkt auf, eine Datenmontagestufe 610, eine Vertex-Shading-Stufe 620, eine Primitiv-Zusammenfügstufe 630, eine Geometrie-Shading-Stufe 640, eine Bildschirmbereichs-Skalierungs-, Culling und Clipping (VSCC-) Stufe 650, eine Rasterungsstufe 660, eine Fragment-Shading-Stufe 670 und eine Rasteroperationsstufe 680. In einer Ausführungsform umfassen die Eingabedaten 601 Befehle, die die Verarbeitungseinheiten so konfigurieren, dass sie die Stufen der Grafikverarbeitungspipeline 600 und geometrische Primitives (z.B. Punkte, Linien, Dreiecke, Vierecke, Quads, Dreiecksstreifen oder Fans usw.) implementieren, die von den Stufen zu verarbeiten sind. Die Ausgabedaten 602 können Pixeldaten (d.h. Farbdaten) umfassen, die in einen Frame-Puffer oder eine andere Art von Oberflächendatenstruktur in einem Speicher kopiert werden.
Die Datenzusammenfügstufe 610 empfängt die Eingangsdaten 601, die Vertexdaten für Oberflächen hoher Ordnung, Primitives oder dergleichen spezifizieren. Die Datenzusammenfügstufe 610 sammelt die Vertexdaten in einem Zwischenspeicher oder einer Warteschlange, beispielsweise durch Empfangen eines Befehls vom Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher enthält, und Lesen der Vertexdaten aus dem Puffer. Die Vertexdaten werden dann zur Verarbeitung an die Vertex-Shading-Stufe 620 übertragen.
Die Vertex-Shading-Stufe 620 verarbeitet Vertexdaten, indem sie eine Reihe von Operationen (z.B. einen Vertex-Shader oder ein Programm) einmal für jeden der Vertices durchführt. Vertices können z.B. als 4-Koordinaten-Vektor (d.h. <x, y, y, z, w>) spezifiziert werden, der einem oder mehreren Vertexattributen (z.B. Farbe, Texturkoordinaten, Oberflächennormale, etc.) zugeordnet ist. Die Vertex-Shading-Stufe 620 kann einzelne Vertex-Attribute wie Position, Farbe, Texturkoordinaten und dergleichen manipulieren. Mit anderen Worten, die Vertex-Shading-Stufe 620 führt Operationen an den Vertexkoordinaten oder anderen Vertexattributen durch, die einem Vertex zugeordnet sind. Solche Operationen beinhalten üblicherweise Ausleuchtungsoperationen (d.h. das Ändern von Farbattributen für einen Vertex) und Transformationsoperationen (d.h. das Ändern des Koordinatenraums für einen Vertex). So können beispielsweise Vertices durch Koordinaten in einem Objektkoordinatenraum spezifiziert werden, die durch Multiplikation der Koordinaten mit einer Matrix transformiert werden, die die Koordinaten aus dem Objektkoordinatenraum in einen Worldspace oder einen normalisierten Gerätekoordinatenraum (Normailzed-Device-Coordinate (NDC)) übersetzt. Die Vertex-Shading-Stufe 620 erzeugt transformierte Vertex-Daten, die an die Primitiv-Zusammenfügstufe 630 übertragen werden.
Die Primitiv-Zusammenfügstufe 630 sammelt die von der Vertex-Shading-Stufe 620 ausgegebenen Vertices und gruppiert die Vertices zu geometrischen Primitives für die Verarbeitung durch die Geometrie-Shading-Stufe 640. So kann beispielsweise die Primitiv-Zusammenfügstufe 630 konfiguriert werden, um alle drei aufeinanderfolgenden Vertices als eine geometrisches Primitiv (d.h. ein Dreieck) zur Übertragung auf die Geometrie-Shading-Stufe 640 zu gruppieren. In einigen Ausführungsformen können bestimmte Vertices für aufeinanderfolgende geometrische Primitives wiederverwendet werden (z.B. können zwei aufeinanderfolgende Dreiecke in einem Dreieckstreifen zwei Vertices teilen). Die Primitiv-Zusammenfügstufe 630 überträgt geometrische Primitives (d.h. eine Sammlung von zugehörigen Vertices) an die Geometrie-Shading-Stufe 640.
Die Geometrie-Shading-Stufe 640 verarbeitet geometrische Primitives, indem sie eine Reihe von Operationen (d.h. einen Geometrie-Shader oder ein Programm) auf den geometrischen Primitives durchführt. Tessellierungsoperationen können aus jedem geometrischen Primitiv ein oder mehrere geometrische Primitives erzeugen. Mit anderen Worten, die Geometrie-Shading-Stufe 640 kann jedes geometrische Primitiv in ein feineres Netz von zwei oder mehr geometrischen Primitives unterteilen, die zur Verarbeitung durch den Rest der Grafikverarbeitungspipeline 600 vorgesehen sind. Die Geometrie-Shading-Stufe 640 überträgt geometrische Primitives an die Bildschirmbereichs-SCC-Stufe 650.
In einer Ausführungsform kann die Grafikverarbeitungspipeline 600 innerhalb eines Streaming-Multiprozessors betrieben werden und die Vertex-Shading-Stufe 620, die Primitiv-Zusammenfügstufe 630, die Geometrie-Shading-Stufe 640, die Fragment-Shading-Stufe 670 und/oder die damit verbundene Hard- und Software können nacheinander Verarbeitungsvorgänge durchführen. Sobald die sequentiellen Verarbeitungsvorgänge in einer Ausführungsform abgeschlossen sind, kann die Bildschirmbereichs-SCC-Stufe 650 die Daten verwenden. In einer Ausführungsform können Primitivdaten, die von einem oder mehreren der Schritte bzw. Stufen in der Grafikverarbeitungspipeline 600 verarbeitet werden, in einen Cache geschrieben werden (z.B. L1-Cache, Vertex-Cache, etc.). In diesem Fall kann die Bildschirmbereichs-SCC-Stufe 650 in einer Ausführungsform auf die Daten im Cache zugreifen. In einer Ausführungsform sind die Bildschirmbereichs-SCC-Stufe 650 und die Rasterungsstufe 660 als Schaltung mit festgelegter Funktion implementiert.
Die Bildschirmbereichs-SCC-Stufe 650 führt die Skalierung, das Ausschneiden und das Zuschneiden der geometrischen Primitives durch. Jede Oberfläche, auf die gerendert wird, ist mit einer abstrakten Kameraposition verbunden. Die Kameraposition stellt eine Position eines Betrachters dar, der die Szene betrachtet, und definiert ein Betrachtungsfrustum, das die Objekte der Szene umschließt. Das Betrachtungsfrustum kann eine Betrachtungsebene, eine hintere Ebene und vier Clipping-Ebenen beinhalten. Jedes geometrische Primitiv, das sich vollständig außerhalb des Betrachtungsfrustums befindet, kann aussortiert (d.h. verworfen) werden, da das geometrische Primitiv nicht zur endgültigen gerenderten Szene beiträgt. Jedes geometrische Primitiv, das sich teilweise innerhalb des Betrachtungsfrustums und teilweise außerhalb des Betrachtungsfrustums befindet, kann abgeschnitten werden (d.h. in ein neues geometrisches Primitiv umgewandelt werden, das innerhalb des Betrachtungsrandes eingeschlossen ist). Darüber hinaus können geometrische Primitives jeweils auf der Grundlage einer Tiefe des Betrachtungsfrustums skaliert werden. Alle potenziell sichtbaren geometrischen Primitives werden dann an die Rasterungsstufe 660 übertragen.
Die Rasterungsstufe 660 wandelt die geometrischen 3D-Primitives in 2D-Fragmente um (welche z.B. geeignet für eine Anzeige einsetzbar sind, etc.). Die Rasterungsstufe 660 kann konfiguriert werden, um die Vertices der geometrischen Primitives zu nutzen, um einen Satz von Ebenengleichungen aufzubauen, aus denen verschiedene Attribute interpoliert werden können. Die Rasterungsstufe 660 kann auch eine Abdeckungsmaske für eine Vielzahl von Pixeln berechnen, die angibt, ob eine oder mehrere Abtastpositionen für das Pixel das geometrische Primitiv unterbrechen. In einer Ausführungsform kann auch ein z-Test durchgeführt werden, um zu bestimmen, ob das geometrische Primitiv durch andere geometrische Primitives, die bereits gerastert wurden, verdeckt wird. Die Rasterungsstufe 660 erzeugt Fragmentdaten (d.h. interpolierte Vertexattribute, welche einer bestimmten Abtaststelle für jedes abgedeckte Pixel zugeordnet sind), die an die Fragment-Shading-Stufe 670 übertragen werden.
Die Fragment-Shadingstufe 670 verarbeitet Fragment-Daten, indem sie eine Reihe von Operationen (d.h. einen Fragment-Shader oder ein Programm) an jedem der Fragmente durchführt. Die Fragment-Shading-Stufe 670 kann Pixeldaten (d.h. Farbwerte) für das Fragment erzeugen, z.B. durch Beleuchtungsoperationen oder Abtasten von Texturkarten unter Verwendung interpolierter Texturkoordinaten für das Fragment. Die Fragment-Shading-Stufe 670 erzeugt Pixeldaten, die an die Rasteroperationsstufe 680 übertragen werden.
Die Rasteroperationenstufe 680 kann verschiedene Operationen an den Pixeldaten durchführen, wie z.B. Alpha-Tests, Schablonentests und das Mischen der Pixeldaten mit anderen Pixeldaten, die anderen dem Pixel zugeordneten Fragmenten entsprechen. Wenn die Rasteroperationenstufe 680 die Verarbeitung der Pixeldaten (d.h. die Ausgabedaten 602) abgeschlossen hat, können die Pixeldaten in ein Render-Target, wie einen Frame-Puffer, einen Farbpuffer oder dergleichen, geschrieben werden.
Es sei darauf hingewiesen, dass neben oder anstelle einer oder mehrerer der oben beschriebenen Stufen eine oder mehrere zusätzliche Stufen in die Grafikverarbeitungspipeline 600 aufgenommen werden können. Verschiedene Implementierungen der abstrakten Grafikverarbeitungspipeline können verschiedene Phasen implementieren. Darüber hinaus kann in einigen Ausführungsformen (z. B. der Geometrie-Shading-Stufe 640) eine oder mehrere der vorstehend beschriebenen Stufen von der Grafikverarbeitungspipeline ausgeschlossen werden. Andere Arten von Grafikverarbeitungspipelines werden als im Umfang der vorliegenden Offenbarung liegend betrachtet. Darüber hinaus kann jede der Phasen der Grafikverarbeitungspipeline 600 durch eine oder mehrere spezielle Hardwarekomponenten in einem Grafikprozessor, wie der PPU 200, realisiert werden. Weitere Stufen der Grafikverarbeitungspipeline 600 können durch programmierbare Hardwareeinheiten, wie dem SM 340 der PPU 200, realisiert werden.
Die Grafikverarbeitungspipeline 600 kann über eine Anwendung implementiert werden, die von einem Host-Prozessor, wie beispielsweise einer CPU 550, ausgeführt wird. In einer Ausführungsform kann ein Gerätetreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, die verschiedene Funktionen definiert, die von einer Anwendung verwendet werden können, um grafische Daten für eine Anzeige zu erzeugen. Der Gerätetreiber ist ein Softwareprogramm, das eine Vielzahl von Anweisungen enthält, die den Betrieb der PPU 200 steuern. Die API bietet eine Abstraktion für einen Programmierer, die es einem Programmierer ermöglicht, spezielle Grafikhardware wie die PPU 200 zu verwenden, um die grafischen Daten zu erzeugen, ohne dass der Programmierer den spezifischen Befehlssatz für die PPU 200 verwenden muss. Die Anwendung kann einen API-Aufruf beinhalten, der an den Gerätetreiber für die PPU 200 weitergeleitet wird. Der Gerätetreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu reagieren. In einigen Fällen kann der Gerätetreiber Operationen ausführen, indem er Anweisungen auf der CPU 550 ausführt. In anderen Fällen kann der Gerätetreiber zumindest teilweise Operationen durchführen, indem er Operationen auf der PPU 200 über eine Ein-/Ausgabeschnittstelle zwischen der CPU 550 und der PPU 200 startet. In einer Ausführungsform ist der Gerätetreiber konfiguriert, um die Grafikverarbeitungspipeline 600 unter Verwendung der Hardware der PPU 200 zu implementieren.
Innerhalb der PPU 200 können verschiedene Programme ausgeführt werden, um die verschiedenen Phasen der Grafikverarbeitungspipeline 600 zu realisieren. So kann beispielsweise der Gerätetreiber einen Kernel auf der PPU 200 starten, um die Vertex-Shading-Stufe 620 auf einem SM 340 (oder mehreren SMs 340) durchzuführen. Der Gerätetreiber (oder der initiale Kernel, der von der PPU 200 ausgeführt wird) kann auch andere Kernel auf der PPU 200 starten, um andere Stufen der Grafikverarbeitungspipeline 600 auszuführen, wie z.B. die Geometrie-Shading-Stufe 640 und die Fragment-Shading-Stufe 670. Darüber hinaus können einige der Phasen der Grafikverarbeitungspipeline 600 auf Hardware mit festgelegter Funktion, wie einem Rasterisierer oder einem innerhalb der PPU 200 implementierten Datenassembler, implementiert werden. Es ist zu beachten, dass die Ergebnisse eines Kernels von einer oder mehreren dazwischenliegenden Hardwareeinheiten mit festgelegter Funktion verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einem SM 340 verarbeitet werden.
7 veranschaulicht ein exemplarisches System 700, in dem die unterschiedlichen Architekturen und/oder Funktionalitäten der verschiedenen vorherigen Ausführungsformen implementiert werden können. Wie dargestellt ist, ist ein System 700 vorgesehen, das mindestens einen zentralen Prozessor 701 beinhaltet, der mit einem Kommunikationsbus 702 verbunden ist. Der Kommunikationsbus 702 kann mit jedem geeigneten Protokoll implementiert werden, wie z.B. PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), Hyper-Transport oder jedem anderen Bus oder Punkt-zu-Punkt Kommunikationsprotokoll(en). Das System 700 beinhaltet auch einen Hauptspeicher 704. Die Steuerlogik (Software) und die Daten werden im Hauptspeicher 704 gespeichert, der als Direktzugriffsspeicher (RAM) ausgeführt sein kann.
Das System 700 beinhaltet auch Eingabegeräte 712, einen Grafikprozessor 706 und eine Anzeige 708, d.h. eine herkömmliche CRT (Kathodenstrahlröhre), LCD (Flüssigkristallanzeige), LED (Leuchtdiode), Plasmaanzeige oder dergleichen. Benutzereingaben können von den Eingabegeräten 712 empfangen werden, z.B. Tastatur, Maus, Touchpad, Mikrofon und dergleichen. In einer Ausführungsform kann der Grafikprozessor 706 eine Vielzahl von Shader-Modulen, ein Rastermodul usw. beinhalten. Jedes der vorgenannten Module kann sich sogar auf einer einzigen Halbleiterplattform befinden, um eine Grafikprozessoreinheit (GPU) zu bilden.
In der vorliegenden Beschreibung kann sich eine einzelne Halbleiterplattform auf eine einzige einheitliche halbleiterbasierte integrierte Schaltung oder einen Chip beziehen. Es ist zu beachten, dass sich der Begriff einzelne Halbleiterplattform auch auf Multi-Chip-Module mit erhöhter Konnektivität beziehen kann, die eine On-Chip-Operation simulieren und wesentliche Verbesserungen gegenüber der Verwendung einer herkömmlichen Zentraleinheit (CPU) und der Bus-Implementierung aufweisen. Natürlich können die verschiedenen Module auch einzeln oder in verschiedenen Kombinationen von Halbleiterplattformen nach den Wünschen des Anwenders platziert werden.
Das System 700 kann auch einen Sekundärspeicher 710 beinhalten. Der Sekundärspeicher 710 beinhaltet beispielsweise ein Festplattenlaufwerk und/oder ein Wechselspeicherlaufwerk, das ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein Kompaktdiskettenlaufwerk, ein digitales vielseitiges Platten-(DVD)-Laufwerk, ein Aufzeichnungsgerät, einen universellen seriellen Bus-(USB)-Flashspeicher darstellt. Das Wechselspeicherlaufwerk liest und/oder schreibt in bekannter Weise von einer bzw. auf eine Wechselspeichereinheit.
Computerprogramme oder Algorithmen der Computersteuerungslogik können im Hauptspeicher 704 und/oder im Sekundärspeicher 710 gespeichert werden. Solche Computerprogramme ermöglichen es dem System 700, verschiedene Funktionen auszuführen. Der Speicher 704, der Speicher 710 und/oder jeder andere Speicher sind mögliche Beispiele für computerlesbare Medien.
In einer Ausführungsform können die Architektur und/oder Funktionalität der verschiedenen vorhergehenden Figuren im Zusammenhang mit dem Zentralprozessor 701, dem Grafikprozessor 706, einer integrierten Schaltung (nicht dargestellt), die mindestens einen Teil der Fähigkeiten sowohl des Zentralprozessors 701 als auch des Grafikprozessors 706 erfüllen kann, einem Chipsatz (d.h. einer Gruppe von integrierten Schaltungen, die als Einheit zum Ausführen zugehöriger Funktionen arbeiten und verkauft werden können, usw.) und/oder einer anderen integrierten Schaltung implementiert werden.
Noch immer kann die Architektur und/oder Funktionalität der verschiedenen vorherigen Figuren im Kontext eines allgemeinen Computersystems, eines Platinensystems, eines Spielkonsolensystems für Unterhaltungszwecke, eines anwendungsspezifischen Systems und/oder eines anderen gewünschten Systems implementiert werden. Das System 700 kann beispielsweise in Form eines Desktop-Computers, Laptops, Servers, Arbeitsplatzes, Spielkonsolen, eines eingebetteten Systems und/oder einer anderen Art von Logik ausgeführt werden. Dennoch kann das System 700 in Form verschiedener anderer Geräte ausgeführt werden, einschließlich, aber nicht beschränkt auf eine PDA-Vorrichtung (Personal Digital Assistant), eine Mobiltelefonvorrichtung, einen Fernseher usw.
Darüber hinaus kann das System 700, obwohl es nicht dargestellt ist, zu Kommunikationszwecken an ein Netzwerk (z.B. Telekommunikationsnetzwerk, Local Area Network (LAN), drahtloses Netzwerk, Wide Area Network (WAN) wie das Internet, Peer-to-Peer-Netzwerk, Kabelnetzwerk oder dergleichen) gekoppelt werden.
8 stellt ein Flussdiagramm eines Verfahrens 800 zum Durchführen einer Knoten-Traversierung unter Verwendung von komprimierten Traversierungs-Stackeinträgen gemäß einer Ausführungsform dar. Wie bei der Abfrage 802 dargestellt ist, wird bestimmt, ob ein Traversierungs-Stack leer ist. Wenn bei der Abfrage 802 bestimmt wird, dass der Traversierungs-Stack leer ist, dann wird in dem Schritt 804 die Traversierung des Stacks abgeschlossen.
Wenn bei der Abfrage 802 bestimmt wird, dass der Traversierungs-Stack nicht leer ist, wird in dem Schritt 806 eine Knotengruppe G aus dem Traversierungs-Stack geholt. Zusätzlich wird im Schritt 808 der Typ der Knoten in der Knotengruppe G bestimmt. Weiterhin wird, wie in Schritt 810 gezeigt ist, wenn bestimmt wird, dass der Typ der Knoten in der Knotengruppe G interne Knoten sind, ein Knoten n aus der aktuellen Knotengruppe G gemäß einer Traversierungs-Reihenfolge extrahiert.
Weiterhin werden, wie in Schritt 812 gezeigt ist, wenn bestimmt wird, dass die Knotengruppe G nicht leer ist, die Reste der Knotengruppe G auf den Stapel geschoben. Außerdem werden, wie in Schritt 814 dargestellt, die Bounding Boxes aller Kinder im Knoten n geschnitten, und die Ergebnisse des Schneidens werden in einer oder mehreren einer internen Knotengruppe Gc und einer Blattknotengruppe Gt gespeichert.
Darüber hinaus wird, wie in Schritt 816 dargestellt ist, beim Bestimmen, dass die interne Knotengruppe Gc und die Blattknotengruppe Gt nicht leer sind, die jeweilige Knotengruppe auf den Stapel geschoben. Das Verfahren kann dann mit der Abfrage 802 fortfahren, wo erneut bestimmt wird, ob der Traversierungs-Stack leer ist.
Darüber hinaus wird, wie es in Schritt 818 gezeigt ist, wenn bestimmt wird, dass die Knoten in der Knotengruppe G vom Typ Blattknoten sind, mindestens ein Primitiv, das durch die Blattknoten in der Knotengruppe G dargestellt wird, geschnitten. Weiterhin werden, wie es in Schritt 820 gezeigt ist, wenn bestimmt wird, dass die Knotengruppe G nicht leer ist, die Reste der Knotengruppe G auf den Stack geschoben. Das Verfahren kann dann mit der Abfrage 802 fortfahren, wo erneut bestimmt wird, ob der Traversierungs-Stack leer ist.
Weiterhin können in einer Ausführungsform einige Knotengruppen in Registern zwischengespeichert werden, anstatt in einem Stack über mehrere Schleifeniterationen hinweg gespeichert zu werden. So kann beispielsweise das oberste Element eines Stacks für einen schnelleren Zugriff in Registern gespeichert werden. Alternativ kann das oberste Element beider Typen (interne Knotengruppe, Blattknotengruppe) in Registern gespeichert werden.
Zusätzlich kann in einer Ausführungsform die Verarbeitung von Knotengruppen neu geordnet werden. Selbst wenn sich beispielsweise eine Blattknotengruppe oben auf dem Stapel befindet, kann sie zurückgestellt werden, und die oberste interne Knotengruppe kann stattdessen verarbeitet werden. In einer weiteren Ausführungsform kann eine Schleifenstruktur reorganisiert werden. So kann beispielsweise die Schleife beliebig oft unrolled (abgerollt) werden. Als weiteres Beispiel können die bedingten Zweige seriell ausgeführt werden, bevor die Schleife wiederholt wird.
9 veranschaulicht exemplarisch entsprechend einer Ausführungsform die Traversierungs-Stackeinträge 900, die während der Knoten-Traversierung eingesetzt werden. Wie dargestellt ist, beinhaltet ein interner Knotengruppeneintrag 902 einen Basisindex 906 für einen internen Knoten, ein Trefferfeld 908, ein Padding-Feld 910 und ein imask-Feld 912. Außerdem beinhaltet ein Primitiv-Knotengruppeneintrag 904 einen Primitiv-Basisindex 914, ein Padding-Feld 916 und ein Primitiv-Trefferfeld 918.
In einer Ausführungsform kann eine aktuelle Knotengruppe G im Gruppeneintrag 902 für interne Knoten und eine Primitiv-Gruppe Gt im Primitiv-Knotengruppeneintrag 904 gespeichert sein. Der interne Knoten-Basisindex 906 des internen Knotengruppeneintrags 902 speichert einen Basisindex für den internen Knoten, und der Primitiv-Basisindex 914 des Primitiv-Knotengruppeneintrags 904 speichert einen Basisindex für das Primitiv.
Zusätzlich speichert das Trefferfeld 908 des internen Knotengruppeneintrags 902 eine Bitmaske, die angibt, welche internen Knoten aktiv sind (z.B. deren Bounding Boxes geschnitten wurden und die noch nicht verarbeitet wurden). Das Feld 918 des Primitiv-Knotengruppeneintrags 904 speichert eine Bitmaske, die angibt, welche Primitiv-Knoten aktiv sind (z.B. deren Bounding Boxes geschnitten wurden und die noch nicht verarbeitet wurden).
Weiterhin gibt das imask-Feld 912 des Gruppeneintrags 902 für einen internen Knoten an, welche der Kinder innerhalb des Gruppeneintrags 902 für einen internen Knoten interne Knoten sind. In einer Ausführungsform werden zur Unterscheidung zwischen dem Gruppeneintrag 902 für einen internen Knoten und dem Primitiv- Knotengruppeneintrag 904 vorbestimmte Bits, welche mit dem Trefferfeld 908 korrespondieren, überprüft. Wenn die vorgegebenen Bits einen Wert von Null haben, dann ist der Eintrag ein Primitiv-Knotengruppeneintrag 904; andernfalls ist der Eintrag ein Gruppeneintrag 902 für einen internen Knoten.
Weiterhin können in einer Ausführungsform Bits im Trefferfeld 908 nach Priorität in Bezug auf eine Traversierungsreihenfolge neu geordnet werden. So werden beispielsweise Kindknoten innerhalb einer aktuellen Knotengruppe G, die zuerst durchlaufen werden sollen, durch höchstwertigste Bits und Kindknoten einer aktuellen Knotengruppe G, die zuletzt durchlaufen werden sollen, durch niederwertigste Bits dargestellt. Infolgedessen entspricht das nächste aktive zu traversierende Kind dem höchstwertigsten gesetzten Bit im Trefferfeld 908.
Wie der Fachmann erkennt, ermöglicht die exemplarische Stackeintragskodierung das Auffinden eines als nächstes zu verarbeitenden Knotens im Speicher, ohne Informationen hinzuzuziehen, die während der Traversierung zusätzlich zu dem betreffenden Stackeintrag erzeugt werden. Darüber hinaus sei darauf hingewiesen, dass die Kodierung insbesondere eine Stackkomprimierung durchführt, da mehrere geschnittene Knoten über einen einzigen Basisindex referenziert werden, anstatt für jeden geschnittenen Knoten einen separaten Index zu speichern.
Effiziente inkohärente Ray-Traversierung auf GPUs durch komprimierte Wide BVHs
Übersicht
Ein GPU-basierter Ray-Traversierungs-Algorithmus wird bereitgestellt, der auf komprimierten breiten bzw. weiten (wide) BVHs arbeitet und den Traversierungs-Stack in einem komprimierten Format hält. Dieses Verfahren kann den Umfang des Speicherdatenverkehrs reduzieren, was die Leistung der inkohärenten Ray-Traversierung verbessern kann. Darüber hinaus kann der Speicherverbrauch der BVH reduziert werden.
Einführung
Raycasting ist nach wie vor eine wichtige Primitiv-Operation bei Anwendungen in realistischer Computergrafik, wissenschaftlicher Visualisierung und Simulation. Die Entwicklung der CPU- und GPU-Hardware hat eine Menge Forschungsarbeit initiiert, um zu untersuchen, wie man Raycasting am effizientesten auf moderner Hardware implementieren kann. Ein Schwerpunkt kann auf inkohärenten Strahlen (Rays) liegen, da sie die Arbeitsbelastung für das GPU-Raycasting belasten und der vorherrschende Fall für hochwertiges Rendering sein können.
Die aktuelle Implementierung zeigt eine signifikante Verbesserung der inkohärenten Raycasting-Leistung sowie einen geringeren Speicherverbrauch. Die Diskrepanz zwischen verfügbarer Rechenleistung und Speicherlatenz und Bandbreite ermöglicht es, die Leistung zu verbessern, indem mehr Rechenleistung für weniger Speicheraufkommen bzw. Speicherverkehr eingetauscht wird. Ein exemplarischer Ansatz ist die Komprimierung sowohl der Beschleunigungsstruktur als auch des Traversierungs-Stacks.
Eine exemplarische komprimierte Beschleunigungsstruktur ist eine 8-weite BVH, für deren Aufbau ein neuartiger Algorithmus implementiert ist. Insbesondere kann eine binäre BVH mit einem Builder erstellt werden, und die binäre BVH kann SAH-optimal in eine 8-weite BVH umgewandelt werden. Oktanten-bewusste Traversierung mit fester Reihenfolge kann ebenso verwendet werden wie ein verbessertes Verfahren zum Ordnen der Kindknoten zur Aufbauzeit, um eine bessere Traversierungs-Reihenfolge zu erhalten.
Komprimierte weite BVH
In einer Ausführungsform kann eine Beschleunigungsstruktur eine komprimierte 8-weite BVH beinhalten, die achsenorientierte Bounding Boxes (AABBs) als Hüllkörper verwendet. Der hohe Verzweigungsfaktor kann die Speicherabruf-Latenzen über 8 Bounding-Box-Schnitttests amortisieren und das Niveau der Parallelität der Befehle während Tests der internen Knoten erhöhen.
Sowohl Bounding Boxes als auch Kind-Zeiger können komprimiert werden, so dass die internen Knoten nur zehn Bytes pro Kind benötigen, was ein Kompressionsverhältnis von 1:3,2 im Vergleich zum standardmäßigen unkomprimierten BVH-Knotenformat ergibt. Dies kann zu einer sofortigen Reduzierung des Speicherverkehrs führen. Zweitens können dank des geringen Speicherbedarfs mehr Knoten in die GPU-Caches passen, was den teuersten DRAM-Verkehr weiter reduzieren kann.
Kompression der Kind-Bounding Boxes
In einer Ausführungsform können AABBs von Kindknoten auf ein lokales Gitter quantisiert und die Positionen der AABB-Ebenen mit einer kleinen Anzahl von Bits gespeichert werden. Insbesondere kann angesichts der gemeinsamen Bounding Box B_lo, B_hi, die alle Kinder abdeckt, der Ursprungspunkt des lokalen Gitters p = B_lo als drei Fließkommawerte gespeichert werden. Die Koordinaten der AABBs des Kindes können als vorzeichenlose ganze Zahlen mit N_q = 8 Bit pro Ebene gespeichert werden. Die Skalierung des Gitters auf jeder Achse i ∈ {x, y, z} kann auf eine Potenz von zwei 2^e
i beschränkt werden, wobei e_i als kleinste ganze Zahl gewählt wird, die es ermöglicht, die maximale Ebene der gemeinsamen AABB in N_q Bits ohne Überlauf darzustellen, d.h., B_hi,i ≤ p_i + 2^e
i(2^N
q - 1). Von dieser Bedingung kann Folgendes abgeleitet werden $e_{i} = ⌈ l o g_{2} \frac{B_{h i, i - p_{i}}}{2^{N_{q}} - 1} ⌉ .$
Um den vollständigen Fließkommabereich abzudecken, kann jeder Exponent e_i mittels 8 Bits gespeichert werden. Die Kind-AABBs b_lo, b_hi können nun in q_lo, q_hi quantisiert werden, wie $\begin{array}{l} q_{l o, i} = ⌊ (b_{l o, i} - p_{i} / 2^{e_{i}}) ⌋ \\ q_{h i, i} = ⌈ (b_{h i, i} - p_{i} / 2^{e_{i}}) ⌉ \end{array}$
Mit einer Dekomprimierung zurück zum Worldspace ergibt sich: $\begin{array}{l} b'_{l o, i} = p_{i} + 2^{e_{i}} q_{l o, i} \\ b'_{h i, i} = p_{i} + 2^{e_{i}} q_{h i, i} \end{array}$
für jede Achse i. Das Verfahren kann konservativ sein, da sich die Kind-AABBs nur vergrößern können, d.h. b'_lo,i ≤ b_lo,i and b'_hi,i ≥ b_hi,i.
Diese Implementierung kann sich von früheren Verfahren unterscheiden, indem sie alle Informationen speichert, die zum Dekomprimieren der Kind-Bounding Boxes im Knoten selbst erforderlich sind. Auf diese Weise müssen möglicherweise keine zusätzlichen Daten im Traversierungs-Stack gespeichert werden, was eine kompaktere Speicherung der Stackeinträge ermöglicht. Die lokalen Rasterdaten können insgesamt 15 Bytes pro Knoten betragen: drei 32-Bit Fließkommazahlen für p und drei 8-Bit-Exponenten e_i.
Die Verwendung einer geringeren Genauigkeit für die quantisierten Bounding Boxes kann zu falsch-positiven Ray-Box-Schnittmengen führen, da die Boxes in Gleichung (2) konservativ vergrößert sind. Nq = 8 Bit können verwendet werden, um eine effiziente Dekomprimierung zu ermöglichen, aber mit geringerer Genauigkeit kann die Anzahl der Ray-Box- und Ray-Dreieck-Tests schnell ansteigen.
Oktanten-basierte Traversierungs-Reihenfolge
In einer Ausführungsform kann das Sortieren der Ray-AABB-Treffer nach Trefferabstand für weite BVHs aufwändig sein. Ein Sortier-Netzwerk kann 19 Vergleichs- und Austauschoperationen für 8 Kind-Knoten erfordern, während das Sortieren nur der Treffer zu problematischen Abweichungen bei der SIMT-Ausführung führen kann. Daher kann eine vorberechnete oder fest zugeordnete Traversierung verwendet werden, die nicht von den tatsächlichen Schnittpunktabständen abhängt. Um den Speicherverbrauch so gering wie möglich zu halten, kann die Traversierungs-Reihenfolge implizit in der Reihenfolge kodiert sein, in der die Kinder im Knoten gespeichert sind, wodurch kein zusätzlicher Speicher verbraucht wird.
Eine exemplarische Implementierung kann das Bestimmen der Kindknoten-Traversierungs-Reihenfolge abhängig von den Vorzeichen des Ray-Richtungsvektors, d.h. des Ray-Oktanten, beinhalten. Im ursprünglichen Schema können die Kind-Knoten in der Morton-Reihenfolge entsprechend ihren AABB-Schwerpunkten im Speicher gespeichert werden, was eine natürliche Traversierungs-Reihenfolge für Rays bzw. Strahlen mit allseits positivem Richtungsvektor ist. Der Oktant wird am einfachsten als 3-Bit-Code oct ∈ [0, 7] dargestellt, wobei Nullen eine positive Traversierungs-Richtung und Einsen eine negative Traversierungs-Richtung anzeigen. Wenn man nun die Kinder i ∈ [0, 7] in der Reihenfolge (i XOR oct) traversiert, kann dies zu einer wünschenswerten Reihenfolge für jeden Ray-Oktanten führen.
10 veranschaulicht eine exemplarische XOR-basierte Traversierungs-Reihenfolge 1000 bei zwei Dimensionen gemäß einer Ausführungsform. Wie dargestellt ist, werden vier Kindknoten 1002A-D in der Morton-Reihenfolge entsprechend ihren Schwerpunkten im Speicher gespeichert. Die Reihenfolge, in der die geschnittenen Kinder traversiert werden, wird durch den Ray-Oktanten durch die einfache Formel order[i] = i XOR oct bestimmt.
Das Speichern der Kindknoten in der Morton-Reihenfolge funktioniert einwandfrei, wenn sich die Kindknoten etwa an den Ecken des Eltern-AABBs befinden und 8 Kindknoten zu speichern sind. Der aktuelle Algorithmus verwendet die gleiche Oktanten-basierte Traversierungs-Reihenfolge, aber zur Aufbauzeit wird die Reihenfolge, in der die Kinder im Speicher gespeichert werden, optimiert. Dadurch ist dieser Ansatz problemlos auf Knoten mit weniger als 8 Kindern anwendbar.
Speicherlayout
In einer Ausführungsform können die internen Knoten die Bounding Boxes ihrer Kinder und die Informationen speichern, die erforderlich sind, um sie im Speicher zu finden. 11 veranschaulicht ein exemplarisches Speicherlayout 1100 gemäß einer Ausführungsform. Blattknoten können direkt als Bereiche in einer separaten Dreiecksanordnung dargestellt werden, d.h. es muss keine explizite Knotenstruktur mit ihnen verbunden sein. Jeder interne Knoten kann 8 quantisierte Bounding Boxes und die für die Dekomprimierung benötigten lokalen Koordinatengitterinformationen speichern.
Darüber hinaus kann jeder interne Knoten die Indizes des ersten referenzierten Kindknotens und des ersten referenzierten Dreiecks in seinen jeweiligen Anordnungen speichern. Alle Kindknoten, auf die derselbe Elternknoten verweist, können zusammenhängend im Speicher gespeichert sein, und das Gleiche kann auch für die Dreiecke gelten. Als Standard können diese Knoten- und Dreieckscluster in der Tiefensuche-Reihenfolge sortiert werden, wobei das Verfahren nicht von dieser globalen Ordnung abhängig sein muss. Zusätzlich kann jeder Knoten speichern ein 8-Bit-Feld imask 1102, um anzugeben, welche der Kinder interne Knoten sind, und ein 8-Bit-Feld meta 1104 pro Kind, das die Indexierungsinformationen kodiert, die benötigt werden, um den entsprechenden Knoten- oder Dreiecksbereich in der entsprechenden Anordnung zu finden.
Der Inhalt des 8-Bit-Feldes meta kann wie folgt bestimmt werden:

• Leeres Kindfeld: Das Feld wird auf 00000000 gesetzt.
• Interner Knoten: Die hochwertigen 3 Bit werden auf 001 gesetzt, während die niederwertigen 5 Bit den Kind-Feld-Index plus 24 speichern (d.h. die Werte liegen im Bereich von 24...31).
• Blattknoten: Die hochwertigen 3 Bit speichern die Anzahl der Dreiecke mit unärer Codierung, und die niederwertigen 5 Bits speichern den Index des ersten Dreiecks relativ zum Basisindex des Dreiecks (Bereich 0... 23).

12 veranschaulicht eine exemplarische Kodierung 1200 gemäß einer Ausführungsform. Variable Blattgrößen von bis zu 3 Dreiecken können ebenso unterstützt werden wie Knoten mit weniger als 8 Kindern, wobei die volle Flexibilität in Bezug auf die Kinder-Reihenfolge erhalten bleibt. In einer Ausführungsform kann der Inhalt des Feldes meta für interne Knoten unmittelbar rekonstruiert werden, da der Knotentyp aus dem Feld imask bekannt ist und der Feld-Index der Index des Kindknotens im Elternknoten ist. Außerdem können die Blattknoten die Dreiecksanzahl in 2 statt 3 Bit speichern, indem sie die Anzahl der Dreiecke anstelle von einem Bit pro Dreieck speichern. Die exemplarische Kodierung kann eine effiziente parallele Verarbeitung von Kindknoten indexierenden Daten durch die Verwendung einer 32-Bit-Arithmetik ermöglichen.
In einer Ausführungsform können die Dreiecke in einem einfachen Format gespeichert werden, das die Vertices direkt als 32-Bit-Floats darstellt und auf 48 Byte aufgefüllt wird. Dadurch bleiben 12 Bytes pro Dreieck übrig, um z.B. den ursprünglichen Dreieckindex im Eingabegitter zu speichern.
Optimale weite BVH-Konstruktion
In einer Ausführungsform kann die weite BVH aufgebaut werden, indem zuerst eine standardmäßige binäre BVH konstruiert und dann ihre Knoten SAH-optimal zu weiten Knoten zusammengelegt werden. Die Topologie der resultierenden weiten BVH kann durch die Topologie der anfänglichen binären BVH eingeschränkt werden, und die SAH-Kosten können unter dieser Bedingung minimiert werden.
Die anfängliche binäre BVH kann mit einem SBVH-Algorithmus mit einem Primitiv pro Blatt aufgebaut werden. Dies kann zu einer hochwertigen binären BVH mit kontrollierbarer Menge von räumlich aufgeteilten Dreiecken führen. Um die binäre BVH in eine weite BVH zu konvertieren, kann ein dynamischer Programmieransatz verwendet werden. So können beispielsweise sowohl interne Knoten als auch Blattknoten gemeinsam gleichzeitig optimiert werden, um ein globales Optimum in Bezug auf sie beide zu erreichen.
Ein Ziel der Konstruktion kann es sein, die gesamten SAH-Kosten [15, 20] der resultierenden weiten BVH zu minimieren: $S A H = \sum_{n \in I} A_{n} \cdot c_{n o d e} + \sum_{n \in L} A_{n} \cdot P_{n} \cdot c_{p r i m},$
wobei I und L dem Satz interner Knoten bzw. dem Satz von Blattknoten entsprechen, wobei An dem AABB-Oberflächenbereich des Knotens n, ausgedrückt in Bezug auf den Oberflächenbereich der Wurzel, entspricht, wobei Pn der Anzahl der Primitiven im Blattknoten n entspricht, und c_node bzw. c_prim Konstanten sind, die die Kosten für den Ray-Knoten- bzw. Ray-Dreieckstest darstellen.
Gleichung (4) kann minimiert werden, indem für jeden Knoten n in der binären BVH die optimalen SAH-Kosten C(n, i) berechnet und gespeichert werden, die erzielt werden können, wenn der Inhalt des gesamten Teilbaums von n als ein Wald von höchstens i weiten BVHs dargestellt wird. Nur i ∈ [1, 7] kann für die Zwecke einer 8-weiten BVH-Konstruktion berücksichtigt werden. Nach der Berechnung können die optimalen SAH-Kosten der gesamten Hierarchie dargestellt werden, da eine einzige weite BVH bei C(root, 1) verfügbar sein kann. Die eigentliche Konstruktion der weiten BVH kann nach Abschluss des Kostenberechnungsdurchgangs durchgeführt werden.
Die Kostenberechnung kann in der binären Hierarchie von unten nach oben (bottom-up) erfolgen, d.h. ein Knoten darf erst verarbeitet werden, nachdem seine beiden Kinder verarbeitet wurden. Dadurch kann sichergestellt werden, dass die Berechnungen, die von den Kindern des Knotens abhängen, ohne Rekursion durchgeführt werden können. An den Blättern der binären BVH, die jeweils ein Primitiv enthalten, gilt C(n, i) = A_n · c_prim für alle i ∈ [1, 7]. An den internen Knoten können die Kosten C(n, i) wie folgt berechnet werden: $C_{(n, i)} = {\begin{array}{l} m i n (C_{l e a f} (n), C_{i n t e r n a l} (n)) & i f i = 1 \\ m i n (C_{d i s t r i b u t e} (n, i), C (n, i - 1)) & o t h e r w i s e \end{array}$
Der erste Fall entspricht der Erstellung eines neuen weiten BVH-Knotens, der als Wurzel des Teilbaums bei n dient, und es kann entweder ein Blattknoten oder ein interner Knoten erstellt werden. Der zweite Fall entspricht der Erzeugung eines Waldes mit bis zu i Wurzeln, und es kann eine optimale Verteilung dieser Wurzeln in einen linken und rechten Teilbaum von n bestimmt werden. Alternativ können auch weniger als i Wurzeln erzeugt werden.
Das Erzeugen eines Blattknotens ist möglicherweise möglich, wenn es ausreichend wenige Primitive im Teilbaum von n gibt: $c_{l e a f} (n) = {\begin{array}{l} A_{n} \cdot P_{n} \cdot c_{p r i m} & i f P_{n} \leq P_{m a x} \\ \infty & o t h e r w i s e \end{array}$
Hier entspricht P_n der Gesamtanzahl der Primitiven unter dem Knoten n und Pmax entspricht der maximal zulässigen Blattgröße für die weite BVH.
Das Erzeugen eines internen Knotens bei n kann die Auswahl von bis zu 8 nachkommenden Knoten erfordern, die als seine Kinder fungieren. Die minimalen SAH-Kosten dieser Knoten können von C_distribute(n, 8) vorgegeben werden, und der mit n selbst verbundene Kostenterm kann hinzuaddiert werden: $C_{i n t e r n a l} (n) = C_{d i s t r i b u t e} (n,8) + A_{n} \cdot c_{n o d e}$
Schließlich kann die Funktion C_distribute(n, j) definiert werden, um die optimalen Kosten für die Darstellung des gesamten Teilbaums von n unter Verwendung eines Waldes von mindestens zwei und höchstens j weiten BVHs zu erhalten: $C_{d i s t r i b u t e} (n, j) = \begin{array}{l} m i n C (n_{l e f t}, k) + C (n_{r i g h t}, j - k) \\ 0 < k < j \end{array}$
Dabei entsprechen n_left und n_right dem linken und rechten Kindknoten von n. Das Minimum wird über die verschiedenen Möglichkeiten der Verteilung von höchstens k der Wurzeln im linken Teilbaum von n und von höchstens j - k Wurzeln im rechten Teilbaum übernommen.
Während der Kostenberechnung können die Entscheidungen gespeichert werden, die das optimale C(n, i) für jedes n und i ergeben haben. Nach Abschluss der Kostenberechnung können diese Entscheidungen ausgehend von C(root, 1) zurückverfolgt werden, wobei weite BVH-Knoten erzeugt werden, so dass die optimalen Kosten realisiert werden. Dies kann den Topologieaufbau der weiten BVH abschließen.
Reihenfolge der Kindknoten
In einer Ausführungsform können keine die Traversierungs-Reihenfolge betreffende Daten in den Knoten gespeichert sein, und die Traversierungsreihenfolge kann implizit in der Reihenfolge der Kindknoten kodiert sein. Abhängig von einer Oktanten-basierten Traversierungs-Reihenfolge existiert ein konzeptionell einfaches Optimierungsproblem: Ein Ziel kann es sein, sicherzustellen, dass die Kindknoten für alle Ray-Richtungen in einer Reihenfolge durchlaufen werden, die der Entfernungsreihenfolge so nah wie möglich kommt.
In einer Ausführungsform kann für jeden Knoten eine 8 × 8 Tabelle cost (c, s) gefüllt werden, wobei jede Tabellenzelle die Kosten für die Platzierung eines bestimmten Kindknotens c in einem bestimmten Kindfeld s ∈ [0, 7] angibt. Aus diesen Daten kann die Zuordnung, die die Gesamtkosten minimiert, mit Hilfe eines Auktionsalgorithmus ermittelt werden.
Zur Definition von cost(c, s) kann ein diagonaler Ray mit der Richtung d_s = (±1, ±1, ±1) betrachtet werden, der das Feld s zuerst gemäß der Oktanten-Reihenfolge durchläuft. Das Vorzeichen der i-ten Komponente von d_s basiert auf dem i-ten Bit von s, so dass Null + und Eins - entspricht.
Die Kosten können als Differenz zwischen dem Elternknoten-Schwerpunkt p und dem Kindknoten-Schwerpunkt c berechnet werden, projiziert auf diese diagonale Ray-Richtung: $c o s t (c, s) = (c - p) \cdot d_{s} .$
Die Kosten für verschiedene Kindfelder können durch Berechnung der projizierten Abstände mit allen acht Vorzeichenkombinationen ausgefüllt werden.
Traversierungs-Algorithmus
In einem Beispiel kann ein BVH-Traversierungs-Algorithmus die Verwendung von persistenten Threads und dynamischem Ray-Holen basierend auf SIMD-Nutzungsheuristiken aufweisen und jeden Ray auf einen einzelnen CUDA-Thread abbilden. Es kann ein komprimierter Traversierungs-Stack verwendet werden, bei dem jeder Eintrag mehrere Kinder eines 8-weiten BVH-Knotens enthalten kann. Der durch den Traversierungs-Stack verursachte Speicherverkehr hat traditionell einen großen Teil der verfügbaren Speicherbandbreite auf GPUs verbraucht, wovon ein Großteil durch Komprimierung und die Verwendung von Gemeinschaftsspeicher eliminiert werden kann.
Tabelle 1 enthält exemplarischen Pseudocode zum Traversieren eines einzelnen Rays bzw. Strahls mit einem einzelnen CUDA-Thread gemäß einer Ausführungsform. Der Pseudocode spiegelt nicht die Verwendung von persistenten Threads oder dynamischem Ray-Holen (Ray Fetching) wider. Es ist natürlich zu beachten, dass der in Tabelle 1 dargestellte Pseudocode nur zur Veranschaulichung angegeben ist und daher nicht als Einschränkung ausgelegt werden sollte.
In einer Ausführungsform ist der Traversierungs-Stack S anfänglich leer, wenn sein oberster Eintrag G oder seine aktuelle Knotengruppe in Registern gehalten wird. Jeder Stackeintrag kann sich beziehen auf einen oder mehrere interne Knoten, die von demselben Elternknoten referenziert werden, oder auf ein oder mehrere Dreiecke, die von einem internen Knoten referenziert werden. Interne Knoten und Dreiecke dürfen nicht in derselben Gruppe gemischt auftreten.
Die Haupt-Traversierungs-Schleife beginnt in Zeile 4 von Tabelle 1. Zu Beginn jeder Iteration wird die aktuelle Knotengruppe G überprüft, welche Art von Knoten sie enthält - per Design, ist sie nie leer zwischen den Iterationen der Hauptschleife. Wenn G interne Knoten enthält, wird der Knoten n, der als nächstes besucht werden soll, gemäß der Oktanten-Traversierungs-Reihenfolge extrahiert. Wenn dadurch G nicht leer wird, werden ihre Reste zurück auf den Stack geschoben. In Zeile 9 von Tabelle 1 werden die Bounding Boxes aller Kinder im Knoten n geschnitten, was sowohl zu Treffern bei internen Knoten als auch bei Blattknoten führen kann. Diese bilden zwei getrennte Gruppen G und G_t für interne Knoten bzw. Dreiecke.
Besteht in Zeile 5 von Tabelle 1 G aus Dreiecken anstelle von internen Knoten, wird ihr Inhalt in Zeile 11 von Tabelle 1 nach G_t verschoben und G wird gelöscht.
Als nächstes werden die Dreiecke der aktuellen Dreiecksgruppe G_t geschnitten. Dreiecke werden in G_t geschnitten, bis sie leer ist oder bis die Anzahl der aktiven Threads im Warp unter einen Schwellenwert fällt. Im letzteren Fall wird das Schneiden der verbleibenden Dreiecke zurückgestellt, indem G_t in Zeile 16 von Tabelle 1 auf den Stack geschoben wird.
Bevor mit der nächsten Iteration der Traversierungsschleife fortgefahren wird, wird bei Bedarf eine neue Knotengruppe G aus dem Stapel geholt. Wenn sowohl G als auch der Stapel leer sind, ist die Traversierung beendet.
Komprimierter Traversierungsstack
Die aktuelle Knotengruppe G und die Dreiecksgruppe Gt können in einem komprimierten Format gespeichert werden, und das gleiche Format kann verwendet werden, wenn Gruppen in den Stack geschoben werden. Die aktuelle Knotengruppe G kann als 64-Bit-Knotengruppeneintrag und die aktuelle Dreiecksgruppe Gt als 64-Bit-Dreiecksgruppeneintrag gespeichert sein. 13 veranschaulicht einen exemplarischen Knotengruppeneintrag 1302 und einen exemplarischen Dreiecksgruppeneintrag 1304 gemäß einer Ausführungsform.
Diese Einträge 1302 und 1304 speichern den Basisindex auf interne Knoten oder Dreiecke sowie eine Bitmaske 1306A und 1306B, die angibt, welche Knoten oder Dreiecke aktiv sind, d.h. deren Bounding Boxes geschnitten wurden und die noch nicht verarbeitet wurden. Zusätzlich wird für die Einträge der Knotengruppen das imask-Feld 1308 von dem internen Knoten gespeichert. Um zwischen den beiden Typen beim Ausführen eines Stack-Abhebens zu unterscheiden, können die Bits 24-31 (das Byte, das durch das Trefferfeld für Knoteneinträge belegt ist) untersucht werden. Wenn dieses Byte Null ist, kann bestimmt werden, dass es sich bei dem Eintrag um einen Dreiecksgruppeneintrag handelt. Andernfalls handelt es sich um einen Knotengruppeneintrag.
In einer Ausführungsform können die Bits im Trefferfeld des Knotengruppeneintrags entsprechend ihrer Priorität in Bezug auf die Oktanten-basierte Traversierungsreihenfolge neu geordnet werden. Mit anderen Worten, die Kinder, die zuerst durchlaufen werden sollen, können durch die hochwertigsten Bits dargestellt werden, während die Kinder, die zuletzt durchlaufen werden sollen, durch die niederwertigsten Bits dargestellt werden können. Dies ermöglicht die Bestimmung des nächsten aktiven zu traversierenden Kindes, indem das hochwertigste gesetzte Bit in diesem Feld gefunden wird. Um den entsprechenden Kind-Feld-Index zu bestimmen, kann der Bitindex mit (7 - oct) XOR-verknüpft werden.
Um den externen Speicherverkehr während der Traversierung zu reduzieren, können die ersten N Stackeinträge im SM-lokalen Gemeinschaftsspeicher gespeichert werden. Da die Größe des Gemeinschaftsspeichers begrenzt ist, kann es sein, dass er nicht in allen Situationen den gesamten Stack aufnehmen kann, und daher kann Thread-Iokaler Speicher auch verwendet werden, wenn die Stackkapazität des Gemeinschaftsspeichers überschritten wird. In einer exemplarischen Implementierung können maximal 12 Stackeinträge (96 Bytes) im Gemeinschaftsspeicher pro Thread abgelegt werden, ohne die Anzahl der gleichzeitig aktiven Threads zu reduzieren. Da jede Ebene in der Hierarchie 0-2 Stackeinträge erzeugt, können 12 Einträge ausreichend sein und ein Überlauf wird selten vorkommen.
Dekomprimierung und Schnittmengenbildung von Knoten
In einer Ausführungsform können sowohl interne Knoten als auch Dreiecke über die Cache-Hierarchie mit 128-Bit breiten Vektor-Ladeanweisungen geladen werden.
Anstatt die quantisierten Bound Boxes in den Worldspace zu transformieren, können die 8-Bit-Ebenenpositionen direkt in Gleitkommazahlen umgewandelt werden, und der Ray-Ursprung o und Richtung d können transformiert werden, um den Quantisierungsgitter-Ursprung und die Skalierung zu berücksichtigen. In einer Ausführungsform kann jedes Byte in einem 32-Bit-Wort mit einem einzigen Befehl in einen Gleitkommawert umgewandelt werden. Für jede Achse i ∈ {x, y, z} kann der Ray wie folgt eingestellt werden: $\begin{array}{l} d'_{i} = 2^{e_{i}} / d_{i} \\ o'_{i} = (p_{i} - o_{i}) / d_{i} \end{array}$
Danach können die Schnittpunktabstände der Ray-Ebene mit einer einzigen FMA-Anweisung pro Ebene berechnet werden: $\begin{array}{l} t_{l o, i} = q_{l o, i} d'_{i} + o'_{i} \\ t_{h i, i} = q_{h i, i} d'_{i} + o'_{i} \end{array}$
In einer Ausführungsform können VMIN-, VMAX-Befehle für effiziente 3-Wege-Minima und -Maxima im Schnittmengentest verwendet werden. Die PRMT-Anweisung kann auch verwendet werden, um die nahen und fernen Ebenen von 4 quantisierten Boxen gleichzeitig vor dem Test abhängig vom Ray-Oktant auszuwählen.
Traversierungszustandsverwaltung
Neben der Boxendekomprimierung und der Schnittmengenbildung ist die Funktion IntersectChildren in Zeile 9 von Tabelle 1 auch für die Traversierungs-Reihenfolge-Berechnung und die Bildung der Traversierungs-Stackeinträge verantwortlich. So können beispielsweise die Traversierungs-Reihenfolge-Berechnungen in komprimierter Form für 4 Kinder gleichzeitig durchgeführt werden.
Um das Trefferfeld des Knotengruppeneintrags gemäß der Oktanten-Traversierungs-Reihenfolge zu konstruieren, kann für jedes Kind, das mit einem internen Knoten korrespondiert, die Traversierungspriorität (slot_index ^ (7 - oct)) berechnet werden. Mit der C-Syntax wird die Berechnung für 4 Kinder parallel wie folgt durchgeführt:

octinv4 = (7 - oct) * 0x01010101;
is_inner4 = (meta4 & (meta4 << 1)) & 0x10101010;
inner_mask4 = sign_extend_s8x4(is_inner4 << 3);
bit_index4 = (meta4 ^ (octinv4 & inner_mask4)) & 0x1F1F1F1F;

Hier enthält jede Variable mit einem Postfix 4 Daten für 4 verschiedene Kindknoten. Die Berechnung von is_inner4 nutzt die Tatsache aus, dass die Bits 3 und 4 nur für interne Knoten aufgrund der Vorbesetzung von meta mit 24 gleichzeitig gesetzt sind. Die Funktion sign_extend_s8x4, die mit dem PRMT-Befehl implementiert wurde, erweitert jedes Byte in einem 32-Bit-Wort individuell mit einer einzigen Assembler-Anweisung um das Vorzeichen und erzeugt eine Byte-Maske für die internen Knoten. Am Ende enthält jedes Byte von bit_index4 die Traversierungspriorität, mit 24 vorbesetzt für interne Knoten, und den Dreiecksversatz für Blattknoten.
Praktischerweise zeigen die Bytes in bit_index4 nun direkt an, wo Bits in den Feldern Treffer und Dreieckstreffer in Knoten- und Dreiecksgruppeneinträgen für G und Gt gesetzt werden sollen. In Anbetracht der Tatsache, dass die hochwertigsten 3 Bits für meta 001 für interne Knoten sind und ein Bit pro Dreieck für Blattknoten enthalten, können die Treffer- und Dreieckstrefferfelder in G und Gt gleichzeitig konstruiert werden, ohne zu berücksichtigen, von welchem Typ der Kindknoten ist, indem die oberen 3 Bit von meta an die Position verschoben werden, die durch das entsprechende Byte in bit_index4 angegeben wird. Darüber hinaus hat ein nicht vorhandener Kindknoten 000 für die hochwertigen 3 Bit von meta, so dass diese Operation keine Bits in beide Felder einfügen kann. Bei erneuter Verwendung der C-Syntax können die hochwertigen 3 Bit in Feldern von meta von einer niederwertigsten Bitposition aus verschoben werden, child_bits4 = (meta4 >> 5) & 0x07070707 und dann kann ein bestimmtes Kind wie folgt in die Treffer- und Dreiecksfelder eingefügt werden:

if (intersected) {
    child_bits = extract_byte(child_bits4, slot_index % 4);
    bit_index = extract_byte(bit_index4, slot_index % 4);
    hitmask = hitmask | (child_bits << bit_index);
 }

Das Loop Unrolling kann verwendet werden, um den gleichen Vorgang für jeden der 8 Kind-Felder nachzubilden. Der gesamte Teil der if-Anweisung wird auf eine einzige PTX-Anweisung vshl.u32.u32.u32.wrap.add r0, r1.b, r2.b, r3 abgebildet, die wiederum zu einem einzigen Assemblerbefehl kompiliert wird.

Das Erlangen des nächsten internen Knotens in G in Zeile 6 von Tabelle 1 funktioniert wie folgt: Der Index des höchstwertigsten gesetzten Bit befindet sich im Trefferfeld des Knotengruppeneintrags, und das Bit wird gelöscht, um den Knoten zu entfernen. Der entsprechende Kind-Feld-Index wird gefunden, indem die Vorbesetzung mit 24 subtrahiert und die Traversierungs-Priorität-Berechnung invertiert wird: slot index = (bit_index - 24) ^ (7.- oct). Ein relativer Index des Knotens wird dann durch Berechnen der Anzahl der benachbarten Knoten erhalten, die in den unteren Kind-Feldern gespeichert sind: relative_index = popc(imask & ~(-1 << slot_index)). Die Auswahl eines aktiven Dreiecks aus Gt in Zeile 19 ist einfacher, da der Index jedes gesetzten Bit in Dreieckstreffern direkt den relativen Index des Dreiecks anzeigt.

Obwohl verschiedene Ausführungsformen vorstehend beschrieben wurden, sollte klar sein, dass sie nur als Beispiel und nicht als Einschränkung dargestellt wurden. Daher sollte die Breite und der Umfang einer bevorzugten Ausführungsform nicht durch eine der oben beschriebenen exemplarischen Ausführungsformen eingeschränkt werden, sondern nur in Übereinstimmung mit den folgenden Ansprüchen und ihren Entsprechungen definiert werden.

Claims

Verfahren zum Implementieren eines komprimierten Traversierungs-Stacks, umfassend: Traversieren einer hierarchischen Datenstruktur mit mehr als zwei Kindern pro Knoten; und während des Traversierens: Erzeugen mindestens eines Stackeintrags mittels eines Prozessors, wobei jeder Stackeintrag mehrere geschnittene Knoten enthält, und Hinzufügen des mindestens einen Stackeintrags zu einem komprimierten Traversierungs-Stacks, welcher in einem Speicher gespeichert ist, mittels des Prozessors.
Verfahren nach Anspruch ein, wobei die geschnittenen Knoten bestimmt werden, indem ein Knoten ausgewählt wird und Bounding Boxes von allen Kindern in dem Knoten geschnitten werden.
Verfahren nach Anspruch 2, wobei der Knoten abhängig von einer vorbestimmten Traversierungs-Reihenfolge ausgewählt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei mehrere verschiedene Stackeinträge während des Traversierens erzeugt werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei jeder des mindestens einen Stackeintrags mehrere interne Knoten repräsentiert, welche durch ein einziges Elter referenziert werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei jeder des mindestens einen Stackeintrags mehrere Blattknoten repräsentiert, welche durch einen internen Knoten referenziert werden.
Verfahren nach einem der vorhergehenden Ansprüche, weiter ein Erzeugen eines Stackeintrags für jeden verschiedenen Primitivtyp, welcher geschnitten wird, umfassend.
Verfahren nach einem der vorhergehenden Ansprüche, wobei jeder des mindestens einen Stackeintrags einen Basisindex zu einem Knoten in der hierarchischen Datenstruktur aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei jeder des mindestens einen Stackeintrags eine Bitmaske aufweist, welche anzeigt, welcher der mehreren geschnittenen Knoten noch nicht verarbeitet worden ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der mindestens eine Stackeintrag einen Stackeintrag aufweist, welcher eine interne Knotengruppe repräsentiert und welcher eine Bitmaske aufweist, welche einen Typ von jedem Kind anzeigt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der mindestens eine Stackeintrag einen Stackeintrag aufweist, welcher eine interne Knotengruppe repräsentiert und welcher ein Trefferfeld aufweist, welches Kinder repräsentiert, welche in einer vorbestimmten Traversierungs-Reihenfolge zu traversieren sind.
Verfahren nach einem der vorhergehenden Ansprüche, darüber hinaus während eines Traversierens einer hierarchischen Datenstruktur ein Lokalisieren eines Knotens, welcher als nächstes zu verarbeiten ist, wobei nur ein aktueller Stackeintrag eingesetzt wird, umfassend.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der komprimierte Traversierungs-Stack eine Stackkomprimierung implementiert, indem mehrere geschnittene Knoten in einem Stackeintrag des komprimierten Traversierungs-Stacks mittels eines gemeinsamen Basisindex referenziert werden.
System umfassend: einen Prozessor, welcher ausgestaltet ist, um eine hierarchische Datenstruktur mit mehr als zwei Kindern pro Knoten zu traversieren; und um während des Traversierens: mindestens einen Stackeintrag mittels des Prozessors zu erzeugen, wobei jeder Stackeintrag mehrere geschnittene Knoten enthält, und mittels des Prozessors den mindestens einen Stackeintrag einem komprimierten Traversierungs-Stack hinzuzufügen, welcher in einem Speicher gespeichert ist.
System nach Anspruch 14, wobei der Prozessor ausgestaltet ist, um ein Verfahren nach einem der Ansprüche 2 bis 13 auszuführen.
Von einem Computer lesbares Speichermedium, welches Anweisungen speichert, welche, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor die Schritte eines Verfahrens nach einem der Ansprüche 1 bis 13 ausführt.