DE112017004671T5

DE112017004671T5 - Vorrichtung und Verfahren für optimiertes Raytracing

Info

Publication number: DE112017004671T5
Application number: DE112017004671.8T
Authority: DE
Inventors: Tomas G. Akenine-Moller; Ingo Wald
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2016-09-16
Filing date: 2017-08-15
Publication date: 2019-05-29
Also published as: CN109564699A; WO2018052606A3; WO2018052606A2; US20220254091A1; CN109564699B; US10580189B2; US20180082466A1; US11321902B2; US20200202606A1

Abstract

Eine Vorrichtung und ein Verfahren für effizientes Raytracing. Zum Beispiel weist eine Ausführungsform einer Vorrichtung auf: einen Allzweckprozessor, um mehrere Strahlströme zu erzeugen; eine erste Hardwareschlange, um die Strahlströme zu empfangen, die vom Allzweckprozessor erzeugt werden; eine Grafikverarbeitungseinheit (GPU), die mehrere Durchführungseinheiten (EUs) aufweist, um die Strahlströme von der ersten Hardwareschlange zu verarbeiten; eine zweite Hardwareschlange, um Grafikverarbeitungsaufträge zu speichern, die von der GPU vorgelegt werden; wobei der Allzweckprozessor dazu dient, die Aufträge zu verarbeiten, die von der GPU vorgelegt werden, und Ergebnisse mit der GPU zu teilen.

Description

HINTERGRUND
Gebiet der Erfindung
Die Erfindung bezieht sich im Allgemeinen auf das Gebiet von Computerprozessoren. Insbesondere bezieht sich die Erfindung auf eine Vorrichtung und ein Verfahren für optimiertes Raytracing.
Beschreibung des Stands der Technik
Raytracing ist eine Rendering-Technik, die fotorealistische Bilder erzeugen kann. Sie funktioniert dadurch, Strahlen durch eine Szene zu schießen und Schattierung bei geschnittenen Punkten zu errechnen und Werte für Pixel zu akkumulieren. In gewissem Sinne kann man sagen, dass Raytracing die Interaktion von Photonen mit Materialien und Geometrie simuliert.
In einem heterogenen System, das zum Beispiel aus einer CPU mit einigen Kernen und einem Grafikprozessor besteht, möchte man alle Ressourcen auf die bestmögliche Weise ausnutzen, um die bestmögliche Arbeitsleistung zu kriegen. Manche Systeme haben die Aufgaben derart aufgeteilt, dass Raytracing (Querung von räumlicher Datenstruktur und Schnittpunkttest) am Grafikprozessor erledigt wird, während Schattierung auf den CPU-Kernen erledigt wird, oder umgekehrt. Es ist wichtig die Kommunikation zwischen zwei Recheneinheiten zu reduzieren. Ein CPU-Kern ist zum Beispiel eine Recheneinheit und eine EU im Grafikprozessor ist ein anderer Typ von Recheneinheit. Manche Systeme verwenden geteilten Speicher für Strahlteilung, die Kommunikation braucht aber immer noch Zeit, weil neue Aufträge für jeden Strom an Strahlen, die von einer Seite zur anderen geteilt werden, gestartet werden.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung kann aus der folgenden ausführlichen Beschreibung in Verbindung mit den folgenden Zeichnungen erhalten werden, in denen:

1 ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor ist, der einen oder mehrere Prozessorkerne und Grafikprozessoren aufweist;
2 ein Blockdiagramm einer Ausführungsform eines Prozessors mit einem oder mehreren Prozessorkernen, einer integrierten Speichersteuerung und einem integrierten Grafikprozessor ist;
3 ein Blockdiagramm einer Ausführungsform eines Grafikprozessors ist, der eine separate Grafikverarbeitungseinheit sein kann oder ein mit mehreren Verarbeitungskernen integrierter Grafikprozessor sein kann;
4 ein Blockdiagramm einer Ausführungsform einer Grafikverarbeitungs-Engine für einen Grafikprozessor ist;
5 ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors ist;
6 ein Blockdiagramm einer Thread-Durchführungslogik ist, die ein Array an Verarbeitungselementen enthält;
7 ein Grafikprozessordurchführungseinheit-Befehlsformat gemäß einer Ausführungsform veranschaulicht;
8 ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors ist, der eine Grafikpipeline, eine Medienpipeline, eine Anzeige-Engine, Thread-Durchführungslogik und eine Renderausgangspipeline enthält;
9A ein Blockdiagramm ist, das ein GrafikprozessorKommandoformat gemäß einer Ausführungsform veranschaulicht;
9B ein Blockdiagramm ist, das eine GrafikprozessorKommandosequenz gemäß einer Ausführungsform veranschaulicht;
10 beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einer Ausführungsform veranschaulicht;
11 ein beispielhaftes IP-Kern-Entwicklungssystem veranschaulicht, das verwendet werden kann, um einen integrierten Schaltkreis herzustellen, um Operationen gemäß einer Ausführungsform auszuführen;
12 einen beispielhaften System-auf-einem-Chip integrierten Schaltkreis veranschaulicht, der unter Verwendung eines oder mehrerer IP-Kerne gemäß einer Ausführungsform gefertigt werden kann;
13 einen beispielhaften Grafikprozessor eines System-auf-einem-Chip integrierten Schaltkreises veranschaulicht, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann;
14 einen zusätzlichen beispielhaften Grafikprozessor eines System-auf-einem-Chip integrierten Schaltkreises veranschaulicht, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann;
15 eine Ausführungsform eine Architektur für Kachel-basiertes Immediatmodus-Rendering (Tile-Based Immediate Mode Rendering, TBIMR) veranschaulicht;
16 eine Ausführungsform von Speicherpuffern innerhalb des Chips, die Hinweisadressenschlangen für jede Kachel enthalten, und Geometriedatenpuffer veranschaulicht;
17 ein Verfahren in Übereinstimmung mit einer Ausführungsform der Erfindung veranschaulicht;
18 ein Geometrieverarbeitungsmodul und ein Pixelverarbeitungsmodul in Übereinstimmung mit einer Ausführungsform der Erfindung veranschaulicht;
19 ein Verfahren in Übereinstimmung mit einer Ausführungsform der Erfindung veranschaulicht;
20 veranschaulicht, wie Bounding Boxen in einer Ausführungsform der Erfindung mit Tiefenwerten verglichen werden;
21 Teilkachelstatus in Bezug auf Teilkacheltiefenwerte veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zum Zweck der Erklärung zahlreiche spezifische Details vorgebracht, um ein gründliches Verständnis der Ausführungsformen der unten beschriebenen Erfindung bereitzustellen. Es wird Fachkundigen jedoch ersichtlich werden, dass die Ausführungsformen der Erfindung ohne manche dieser spezifischen Details umgesetzt werden können. In anderen Instanzen werden wohlbekannte Strukturen und Geräte in Blockdiagrammform gezeigt, um zu vermeiden, die zugrundeliegenden Prinzipien der Ausführungsformen der Erfindung zu verschleiern.
BEISPIELHAFTE GRAFIKPROZESSORARCHITEKTUREN UND DATENTYPEN
Systemübersicht
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. In unterschiedlichen Ausführungsformen enthält das System 100 einen oder mehrere Prozessoren 102 und einen oder mehrere Grafikprozessoren 108 und kann ein Einzelprozessor-Desktopsystem, ein Mehrprozessor-Arbeitsstationssystem oder ein Serversystem mit einer großen Zahl an Prozessoren 102 oder Prozessorkernen 107 sein. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die innerhalb eines System-auf-einem-Chip (System-on-a-Chip, SoC) integrierten Schaltkreises eingegliedert ist, zur Verwendung in mobilen, handgehaltenen oder eingebetteten Geräten.
Eine Ausführungsform von System 100 kann eine Server-basierte Spieleplattform, eine Spielkonsole, enthaltend eine Spiele- und Medienkonsole, eine mobile Spielkonsole, eine handgehaltene Spielkonsole oder eine Online-Spielkonsole enthalten oder darin eingegliedert sein. In manchen Ausführungsformen ist System 100 ein Mobiltelefon, Smartphone, Tablet-Rechengerät oder mobiles Internetgerät. Datenverarbeitungssystem 100 kann auch innerhalb eines tragbaren Geräts, wie ein Smartwatch tragbares Gerät, smartes Brillen- oder Kontaktlinsengerät, Erweiterte-Realität-Gerät oder Virtuelle-Realität-Gerät, enthalten, damit gekoppelt oder darin integriert sein. In manchen Ausführungsformen ist Datenverarbeitungssystem 100 ein Fernseher oder Set-Top-Box-Gerät mit einem oder mehreren Prozessoren 102 und einer grafischen Schnittstelle, die von einem oder mehreren Grafikprozessoren 108 erzeugt wird.
In manchen Ausführungsformen enthalten der eine oder die mehreren Prozessoren jeweils einen oder mehrere Prozessorkerne 107, um Befehle zu verarbeiten, die, wenn durchgeführt, Operationen für System und Anwendersoftware ausführen. In manchen Ausführungsformen ist jeder des einen oder der mehreren Prozessorkerne 107 konfiguriert, einen spezifischen Befehlssatz 109 zu verarbeiten. In manchen Ausführungsformen kann Befehlssatz 109 komplexe Befehlssatzberechnung (Complex Instruction Set Computing, CISC), reduzierte Befehlssatzberechnung (Reduced Instruction Set Computing, RISC), oder Errechnen über ein sehr langes Befehlswort (Very Long Instruction Word, VLIW) erleichtern. Mehrere Prozessorkerne 107 können jeweils einen verschiedenen Befehlssatz 109 verarbeiten, der Befehle enthalten kann, um die Emulation anderer Befehlssätze zu erleichtern. Prozessorkern 107 kann auch andere Verarbeitungsgeräte enthalten, wie einen Digitalsignalprozessor (DSP).
In manchen Ausführungsformen enthält der Prozessor 102 Cachespeicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Stufen von internem Cache haben. In manchen Ausführungsformen wird der Cachespeicher unter unterschiedlichen Komponenten des Prozessors 102 geteilt. In manchen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z.B. Stufe-3 (Level-3, L3) Cache oder Letzte-Stufe-Cache (Last-Level-Cache, LLC)) (nicht gezeigt), der unter Prozessorkernen 107 geteilt werden kann, die bekannte Cachekohärenztechniken verwenden. Eine Registerdatei 106 ist zusätzlich in Prozessor 102 enthalten, die verschiedene Typen von Registern zum Speichern verschiedener Typen von Daten enthalten kann (z.B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Befehlshinweisadressenregister). Manche Register können Allzweckregister sein, während andere Register für die Gestaltung des Prozessors 102 spezifisch sein können.
In manchen Ausführungsformen ist Prozessor 102 mit einem Prozessorbus 110 gekoppelt, um Kommunikationssignale, wie Adress-, Daten- oder Steuersignale, zwischen Prozessor 102 und anderen Komponenten in System 100 zu übertragen. In einer Ausführungsform verwendet das System 100 eine beispielhafte „Hub“-Systemarchitektur, die einen Speichersteuerhub 116 und einen Eingang-Ausgang- (Input Output, I/O) Steuerhub 130 enthält. Ein Speichersteuerhub 116 erleichtert Kommunikation zwischen einem Speichergerät und anderen Komponenten von System 100, während ein I/O-Steuerhub (I/O Controller Hub, ICH) 130 Verbindungen mit I/O-Geräten über einen lokalen I/O-Bus bereitstellt. In einer Ausführungsform ist die Logik des Speichersteuerhubs 116 innerhalb des Prozessors integriert.
Speichergerät 120 kann ein dynamisches Direktzugriffspeicher- (Dynamic Random Access Memory, DRAM) Gerät, ein statisches Direktzugriffspeicher- (Static Random Access Memory, SRAM) Gerät, Flashspeichergerät, Phasenwechsel-Speichergerät oder ein anderes Speichergerät mit geeigneter Arbeitsleistung, um als Prozessspeicher zu dienen, sein. In einer Ausführungsform kann das Speichergerät 120 als Systemspeicher für das System 100 arbeiten, um Daten 122 und Befehle 121 zur Verwendung, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess durchführen, zu speichern. Speichersteuerhub 116 koppelt sich auch mit einem optionalen externen Grafikprozessor 112, der mit dem einen oder den mehreren Grafikprozessoren 108 in Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen auszuführen.
In manchen Ausführungsformen ermöglicht ICH 130 Peripheriegeräten, sich mit Speichergerät 120 und Prozessor 102 über einen Hochgeschwindigkeits-I/O-Bus zu verbinden. Die I/O-Peripheriegeräte enthalten, sind aber nicht begrenzt auf, eine Audiosteuerung 146, eine Firmwareschnittstelle 128, einen drahtlosen Sendeempfänger 126 (z.B. Wi-Fi, Bluetooth), ein Datenspeichergerät 124 (z.B. Festplatte, Flashspeicher usw.) und eine Ältere-I/O-Steuerung 140 zum Koppeln älterer (z.B. Personal System 2 (PS/2)) Geräte an das System. Eine oder mehrere Universal Serial Bus (USB) Steuerungen 142 verbinden Eingangsgeräte, wie Tastatur und Maus 144 Kombinationen. Eine Netzwerksteuerung 134 kann sich auch mit ICH 130 koppeln. In manchen Ausführungsformen koppelt sich eine Hochleistungsnetzwerksteuerung (nicht gezeigt) mit Prozessorbus 110. Es versteht sich, dass das gezeigte System 100 beispielhaft und nicht begrenzend ist, da andere Typen von Datenverarbeitungssystemen, die anders konfiguriert sind, auch verwendet werden können. Zum Beispiel kann der I/O-Steuerhub 130 innerhalb des einen oder der mehreren Prozessoren 102 integriert sein, oder der Speichersteuerhub 116 und I/O-Steuerhub 130 können in einen separaten externen Grafikprozessor, wie der externe Grafikprozessor 112, integriert sein.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A-202N, einer integrierten Speichersteuerung 214 und einem integrierten Grafikprozessor 208. Diese Elemente von 2 haben dieselben Bezugsnummern (oder -namen), da die Elemente von jeder anderen Figur hierin auf jede Weise ähnlich der woanders hierin beschriebenen arbeiten oder fungieren, sind aber nicht auf solche begrenzt. Prozessor 200 kann zusätzliche Kerne bis zu und einschließlich zusätzlichem Kern 202N enthalten, der durch die gestrichelten Kästchen dargestellt ist. Jeder von Prozessorkernen 202A-202N enthält eine oder mehrere interne Cacheeinheiten 204A-204N. In manchen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf eine oder mehrere geteilte Cacheeinheiten 206.
Die internen Cacheeinheiten 204A-204N und geteilten Cacheeinheiten 206 stellen eine Cachespeicherhierarchie innerhalb des Prozessors 200 dar. Die Cachespeicherhierarchie kann mindestens eine Stufe von Befehls- und Datencache innerhalb jedes Prozessorkerns und eine oder mehrere Stufen von geteiltem Mittelstufen-Cache, wie ein Stufe-2 (L2), Stufe-3 (L3), Stufe-4 (L4) oder andere Stufen von Cache enthalten, wo die höchste Stufe von Cache vor externem Cache als der LLC klassifiziert ist. In manchen Ausführungsformen hält Cachekohärenzlogik Kohärenz zwischen den unterschiedlichen Cacheeinheiten 206 und 204A-204N bei.
In manchen Ausführungsformen kann Prozessor 200 auch einen Satz von einer oder mehreren Bussteuereinheiten 216 und einen Systemagentenkern 210 enthalten. Die eine oder die mehreren Bussteuereinheiten 216 verwalten einen Satz von peripheren Bussen, wie einen oder mehrere Peripheral Component Interconnect Busse (z.B. PCI, PCI Express). Systemagentenkern 210 stellt Verwaltungsfunktionalität für die unterschiedlichen Prozessorkomponenten bereit. In manchen Ausführungsformen enthält Systemagentenkern 210 eine oder mehrere integrierte Speichersteuerungen 214, um Zugriff auf unterschiedliche externe Speichergeräte (nicht gezeigt) zu verwalten.
In manchen Ausführungsformen enthalten ein oder mehrere der Prozessorkerne 202A-202N Unterstützung für zeitgleiches Multithreading. In solch einer Ausführungsform enthält der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben von Kernen 202A-202N während multigethreadeter Verarbeitung. Systemagentenkern 210 kann zusätzlich eine Leistungssteuereinheit (Power Control Unit, PCU) enthalten, die Logik und Komponenten enthält, um den Leistungszustand von Prozessorkernen 202A-202N und Grafikprozessor 208 zu regulieren.
In manchen Ausführungsformen enthält Prozessor 200 zusätzlich Grafikprozessor 208, um Grafikverarbeitungsoperationen durchzuführen. In manchen Ausführungsformen koppelt sich der Grafikprozessor 208 mit dem Satz geteilter Cacheeinheiten 206 und dem Systemagentenkern 210, der die eine oder die mehreren integrierten Speichersteuerungen 214 enthält. In manchen Ausführungsformen ist eine Anzeigesteuerung 211 mit dem Grafikprozessor 208 gekoppelt, um Grafikprozessorausgang zu einer oder mehreren gekoppelten Anzeigen zu treiben. In manchen Ausführungsformen kann Anzeigesteuerung 211 ein separates Modul sein, das mit dem Grafikprozessor über mindestens eine Zwischenverbindung gekoppelt ist oder innerhalb des Grafikprozessors 208 oder Systemagentenkerns 210 integriert sein kann.
In manchen Ausführungsformen wird eine ringbasierte Zwischenverbindungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Eine alternative Zwischenverbindungseinheit kann jedoch verwendet werden, wie eine Punkt-zu-Punkt-Zwischenverbindung oder andere Techniken, die im Stand der Technik wohlbekannte Techniken enthalten. In manchen Ausführungsformen koppelt sich Grafikprozessor 208 mit der Ringzwischenverbindung 212 über einen I/O-Link 213.
Der beispielhafte I/O-Link 213 stellt mindestens eine von mehreren Varianten von I/O-Zwischenverbindungen dar, enthaltend eine I/O-Zwischenverbindung innerhalb des Pakets, die Kommunikation zwischen unterschiedlichen Prozessorkomponenten und einem eingebetteten Hochleistungs- Speichermodul 218, wie einem eDRAM-Modul, erleichtert. In manchen Ausführungsformen verwenden jeder der Prozessorkerne 202A-202N und Grafikprozessor 208 eingebettete Speichermodule 218 als geteilten Letzte-Stufe-Cache.
In manchen Ausführungsformen sind Prozessorkerne 202A-202N homogene Kerne, die dieselbe Befehlssatzarchitektur durchführen. In einer anderen Ausführungsform sind Prozessorkerne 202A-202N im Sinne der Befehlssatzarchitektur (Instruction Set Architecture, ISA) heterogen, wo ein oder mehrere von Prozessorkernen 202A-202N einen ersten Befehlssatz durchführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Befehlssatzes oder einen anderen Befehlssatz durchführt. In einer Ausführungsform sind Prozessorkerne 202A-202N im Sinne von Mikroarchitektur heterogen, wo ein oder mehrere Kerne mit einem relativ hohen Leistungsverbrauch sich mit einem oder mehreren Leistungskernen koppeln, die einen niedrigeren Leistungsverbrauch haben. Zusätzlich kann Prozessor 200 auf einem oder mehreren Chips oder als ein SoC integrierter Schaltkreis, der die veranschaulichten Komponenten aufweist, zusätzlich zu anderen Komponenten implementiert sein.
3 ist ein Blockdiagramm eines Grafikprozessors 300, der eine separate Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen integriert ist. In manchen Ausführungsformen kommuniziert der Grafikprozessor über eine Speicher-gemappte I/O-Schnittstelle mit Registern auf dem Grafikprozessor und mit Kommandos, die in den Prozessorspeicher platziert sind. In manchen Ausführungsformen enthält Grafikprozessor 300 eine Speicherschnittstelle 314, um auf Speicher zuzugreifen. Speicherschnittstelle 314 kann eine Schnittstelle zu lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren geteilten externen Caches und/oder Systemspeicher sein.
In manchen Ausführungsformen enthält Grafikprozessor 300 auch eine Anzeigesteuerung 302, um Anzeigeausgangsdaten zu einem Anzeigegerät 320 zu treiben. Anzeigesteuerung 302 enthält Hardware für eine oder mehrere Einblendungsebenen für die Anzeige und Zusammenstellung mehrerer Schichten von Video oder Anwenderschnittstellenelementen. In manchen Ausführungsformen enthält Grafikprozessor 300 eine Videocodec-Engine 306, um Medien zu, von oder zwischen einem oder mehreren Mediencodierungsformaten zu codieren, decodieren oder transcodieren, enthaltend, aber nicht begrenzt auf, Moving Picture Experts Group (MPEG) Formate, wie MPEG-2, Advanced Video Coding (AVC) Formate, wie H.264/MPEG-4 AVC, wie auch Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1, und Joint Photographic Experts Group (JPEG) Formate, wie JPEG, und Motion JPEG (MJPEG) Formate.
In manchen Ausführungsformen enthält Grafikprozessor 300 eine Blockbildübermittlungs- (Block Image Transfer, BLIT) Engine 304, um zweidimensionale (2D) Rasterungsoperationen auszuführen, enthaltend zum Beispiel Bit-Grenzblockübermittlungen. In einer Ausführungsform jedoch sind 2D-Grafikoperationen unter Verwendung einer oder mehrerer Komponenten von Grafikverarbeitungs-Engine (Graphics Processing Engine, GPE) 310 ausgeführt. In manchen Ausführungsformen ist GPE 310 eine Rechen-Engine zum Ausführen von Grafikoperationen, enthaltend dreidimensionale (3D) Grafikoperationen und Medienoperationen.
In manchen Ausführungsformen enthält GPE 310 eine 3D-Pipeline 312, um 3D-Operationen auszuführen, wie Rendering von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen wirken (z.B. Rechteck, Dreieck usw.). Die 3D-Pipeline 312 enthält programmierbare und fixierte Funktionselemente, die unterschiedliche Aufgaben innerhalb des Elements ausführen und/oder Durchführungsthreads zu einem 3D/Medienteilsystem 315 hervorbringen. Während 3D-Pipeline 312 verwendet werden kann, um Medienoperationen auszuführen, kann eine Ausführungsform von GPE 310 auch eine Medienpipeline 316 enthalten, die spezifisch verwendet wird, um Medienoperationen auszuführen, wie Videonachbearbeitung und Bildqualitätsverbesserung.
In manchen Ausführungsformen enthält Medienpipeline 316 fixierte Funktions- oder programmierbare Logikeinheiten, um eine oder mehrere spezialisierte Medienoperationen, wie Videodecodierungsbeschleunigung, Videoentflackerung und Videocodierungsbeschleunigung an Stelle von oder für Videocodec-Engine 306 auszuführen. In manchen Ausführungsformen enthält Medienpipeline 316 zusätzlich eine Threadhervorbringungseinheit, um Threads zur Durchführung auf 3D/Medienteilsystem 315 hervorzubringen. Die hervorgebrachten Threads führen Errechnungen für die Medienoperationen auf einer oder mehreren Grafikdurchführungseinheiten aus, die in 3D/Medienteilsystem 315 enthalten sind.
In manchen Ausführungsformen enthält 3D/Medienteilsystem 315 Logik zum Durchführen von Threads, die von 3D-Pipeline 312 und Medienpipeline 316 hervorgebracht sind. In einer Ausführungsform senden die Pipelines Threaddurchführungsanfragen an 3D/Medienteilsystem 315, das Threadversandlogik zum Vermitteln und Versenden unterschiedlicher Anfragen zu verfügbaren Threaddurchführungsressourcen enthält. Die Durchführungsressourcen enthalten ein Array von Grafikdurchführungseinheiten, um die 3D- und Medienthreads zu verarbeiten. In manchen Ausführungsformen enthält 3D/Medienteilsystem 315 einen oder mehrere interne Caches für Threadbefehle und Daten. In manchen Ausführungsformen enthält das Teilsystem auch geteilten Speicher, enthaltend Register und adressierbaren Speicher, um Daten zwischen Threads zu teilen und Ausgangsdaten zu speichern.
Grafikverarbeitungs-Engine
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors in Übereinstimmung mit manchen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungs-Engine (GPE) 410 eine Version der GPE 310, die in 3 gezeigt ist. Elemente von 4 haben dieselben Bezugsnummern (oder -namen), da die Elemente von jeder anderen Figur hierin auf jede Weise ähnlich der woanders hierin beschriebenen arbeiten oder fungieren, sind aber nicht auf solche begrenzt. Zum Beispiel werden die 3D-Pipeline 312 und Medienpipeline 316 von 3 veranschaulicht. Die Medienpipeline 316 ist in manchen Ausführungsformen der GPE 410 optional und ist nicht ausdrücklich in der GPE 410 enthalten. Zum Beispiel und in mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
In manchen Ausführungsformen koppelt sich GPE 410 mit einem Kommandostreamer 403 oder enthält diesen, der einen Kommandostrom an die 3D-Pipeline 312 und/oder Medienpipelines 316 bereitstellt. In manchen Ausführungsformen ist Kommandostreamer 403 mit Speicher gekoppelt, der Systemspeicher oder einer oder mehrere von internem Cachespeicher und geteiltem Cachespeicher sein kann. In manchen Ausführungsformen empfängt Kommandostreamer 403 Kommandos vom Speicher und sendet Kommandos an 3D-Pipeline 312 und/oder Medienpipeline 316. Die Kommandos sind Angaben, die von einem Ringpuffer abgerufen werden, der Kommandos für die 3D-Pipeline 312 und Medienpipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Stapelkommandopuffer enthalten, die zum Speichern von Stapeln mehrerer Kommandos dienen. Die Kommandos für die 3D-Pipeline 312 können auch Referenzen auf Daten enthalten, die in Speicher gespeichert sind, wie, aber nicht begrenzt auf, Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medienpipeline 316. Die 3D-Pipeline 312 und Medienpipeline 316 verarbeiten die Kommandos und Daten durch Ausführen von Operationen über Logik innerhalb der jeweiligen Pipelines oder durch Versenden eines oder mehrerer Durchführungsthreads zu einem Grafikkern-Array 414.
In unterschiedlichen Ausführungsformen kann die 3D-Pipeline 312 ein oder mehrere Shaderprogramme, wie Vertexshader, Geometrieshader, Pixelshader, Fragmentshader, Rechenshader oder andere Shaderprogramme, durch Verarbeiten der Befehle und Versenden von Durchführungsthreads an das Grafikkern-Array 414 durchführen. Das Grafikkern-Array 414 stellt einen vereinheitlichten Block von Durchführungsressourcen bereit. Mehrzweckdurchführungslogik (z.B. Durchführungseinheiten) innerhalb des Grafikkern-Arrays 414 enthalten Unterstützung für unterschiedliche 3D-API-Shadersprachen und können mehrere zeitgleiche Durchführungsthreads durchführen, die mehreren Shadern zugehörig sind.
In manchen Ausführungsformen enthält das Grafikkern-Array 414 auch Durchführungslogik, um Medienfunktionen, wie Video- und/oder Bildverarbeitung, auszuführen. In einer Ausführungsform enthalten die Durchführungseinheiten zusätzlich Allzwecklogik, die programmierbar ist, um parallele Allzweckrechenoperationen zusätzlich zu Grafikverarbeitungsoperationen auszuführen. Die Allzwecklogik kann Verarbeitungsoperationen parallel oder in Verbindung mit Allzwecklogik innerhalb des Prozessorkerns bzw. der Prozesskerne von 1 oder Kern 202A-202N wie in 2 ausführen.
Ausgangsdaten, die durch Threads erzeugt werden, die auf dem Grafikkern-Array 414 ablaufen, können Daten an Speicher in einem vereinheitlichten Rückkehrpuffer (Unified Return Buffer, URB) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In manchen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen verschiedenen Threads zu senden, die auf dem Grafikkern-Array 414 ablaufen. In manchen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisation zwischen Threads auf dem Grafikkern-Array und fixierter Funktionslogik innerhalb der geteilten Funktionslogik 420 verwendet werden.
In manchen Ausführungsformen ist Grafikkern-Array 414 derart skalierbar, dass das Array eine variable Zahl an Grafikkernen enthält, von denen jeder eine variable Zahl an Durchführungseinheiten basierend auf der Zielleistung und der Arbeitsleistungsstufe von GPE 410 hat. In einer Ausführungsform sind die Durchführungsressourcen derart dynamisch skalierbar, dass Durchführungsressourcen wie benötigt aktiviert oder deaktiviert werden können.
Das Grafikkern-Array 414 koppelt sich mit geteilter Funktionslogik 420, die mehrere Ressourcen enthält, die zwischen den Grafikkernen im Grafikkern-Array geteilt werden. Die geteilten Funktionen innerhalb der geteilten Funktionslogik 420 sind Hardwarelogikeinheiten, die spezialisierte ergänzende Funktionalität an das Grafikkern-Array 414 bereitstellen. In unterschiedlichen Ausführungsformen enthält geteilte Funktionslogik 420, ist aber nicht begrenzt auf, Abtaster- 421, Mathematik- 422 und Zwischen-Thread-Kommunikation- (Inter-Thread Communication, ITC) 423 Logik. Zusätzlich implementieren manche Ausführungsformen einen oder mehrere Cache(s) 425 innerhalb der geteilten Funktionslogik 420. Eine geteilte Funktion ist da implementiert, wo der Bedarf für eine gegebene spezialisierte Funktion zum Einschluss innerhalb des Grafikkern-Arrays 414 unzureichend ist. Stattdessen ist eine einzelne Instanziierung dieser spezialisierten Funktion als eine unabhängige Instanz in der geteilten Funktionslogik 420 implementiert und unter den Durchführungsressourcen innerhalb des Grafikkern-Arrays 414 geteilt. Der präzise Satz an Funktionen, die zwischen dem Grafikkern-Array 414 geteilt werden und innerhalb des Grafikkern-Arrays 414 enthalten sind, variiert zwischen Ausführungsformen.
5 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 500. Elemente von 5 haben dieselben Bezugsnummern (oder - namen), da die Elemente jeder anderen Figur hierin auf jede Weise ähnlich der woanders hierin beschriebenen arbeiten oder fungieren, sind aber nicht auf solche begrenzt.
In manchen Ausführungsformen enthält Grafikprozessor 500 eine Ringzwischenverbindung 502, ein Pipeline-Frontend 504, eine Medien-Engine 537 und Grafikkerne 580A-580N. In manchen Ausführungsformen koppelt Ringzwischenverbindung 502 den Grafikprozessor mit anderen Verarbeitungseinheiten, enthaltend andere Grafikprozessoren oder einen oder mehrere Allzweckprozessorkerne. In manchen Ausführungsformen ist der Grafikprozessor einer von vielen Prozessoren, die innerhalb eines Mehrkernverarbeitungssystems integriert sind.
In manchen Ausführungsformen empfängt Grafikprozessor 500 Stapel von Kommandos über Ringzwischenverbindung 502. Die eingehenden Kommandos werden durch einen Kommandostreamer 503 im Pipeline-Frontend 504 interpretiert. In manchen Ausführungsformen enthält Grafikprozessor 500 skalierbare Durchführungslogik, um 3D-Geometrieverarbeitung und Medienverarbeitung über den (die) Grafikkern(e) 580A-580N auszuführen. Für 3D-Geometrieverarbeitungskommandos liefert Kommandostreamer 503 Kommandos an Geometriepipeline 536. Für mindestens manche Medienverarbeitungskommandos liefert Kommandostreamer 503 die Kommandos an ein Video-Frontend 534, das sich mit einer Medien-Engine 537 koppelt. In manchen Ausführungsformen enthält Medien-Engine 537 eine Videoqualitäts-Engine (VQE) 530 für Video- und Bildnachbearbeitung und eine Mehrformat-Codierungs-/Decodierungs- (Multi-Format Encode/Decode, MFX) 533 Engine, um hardwarebeschleunigte Mediendatencodierung und -decodierung bereitzustellen. In manchen Ausführungsformen erzeugen Geometriepipeline 536 und Medien-Engine 537 jeweils Durchführungsthreads für die Threaddurchführungsressourcen, die durch mindestens einen Grafikkern 580A bereitgestellt sind.
In manchen Ausführungsformen enthält Grafikprozessor 500 skalierbare Durchführungsressourcen, die modulare Kerne 580A-580N darbieten (manchmal als Kernstücke bezeichnet), wobei jeder mehrere Teilkerne 550A-550N, 560A-560N (manchmal als Kernteilstücke bezeichnet) hat. In manchen Ausführungsformen kann Grafikprozessor 500 irgendeine Zahl an Grafikkernen 580A bis 580N haben. In manchen Ausführungsformen enthält Grafikprozessor 500 einen Grafikkern 580A mit mindestens einem ersten Teilkern 550A und einem zweiten Teilkern 560A. In anderen Ausführungsformen ist der Grafikprozessor ein Niederleistungsprozessor mit einem einzelnen Teilkern (z.B. 550A). In manchen Ausführungsformen enthält Grafikprozessor 500 mehrere Grafikkerne 580A-580N, wobei jeder einen Satz erster Teilkerne 550A-550N und einen Satz zweiter Teilkerne 560A-560N enthält. Jeder Teilkern im Satz erster Teilkerne 550A-550N enthält mindestens einen ersten Satz von Durchführungseinheiten 552A-552N und Medien-/Texturabtastern 554A-554N. Jeder Teilkern im Satz zweiter Teilkerne 560A-560N enthält mindestens einen zweiten Satz von Durchführungseinheiten 562A-562N und Abtastern 564A-564N. In manchen Ausführungsformen teilt sich jeder Teilkern 550A-550N, 560A-560N einen Satz geteilter Ressourcen 570A-570N. In manchen Ausführungsformen enthalten die geteilten Ressourcen geteilten Cachespeicher und Pixeloperationslogik. Andere geteilte Ressourcen können auch in den unterschiedlichen Ausführungsformen des Grafikprozessors enthalten sein.
Durchführungseinheiten
6 veranschaulicht Threaddurchführungslogik 600, die ein Array von Verarbeitungselementen enthält, die in manchen Ausführungsformen einer GPE eingesetzt werden. Elemente von 6 haben dieselben Bezugsnummern (oder - namen), da die Elemente von jeder anderen Figur hierin auf jede Weise ähnlich der woanders hierin beschriebenen arbeiten oder fungieren, sind aber nicht auf solche begrenzt.
In manchen Ausführungsformen enthält Threaddurchführungslogik 600 einen Shaderprozessor 602, einen Threadversender 604, Befehlscache 606, ein skalierbares Durchführungseinheits-Array, das mehrere Durchführungseinheiten 608A-608N enthält, einen Abtaster 610, einen Datencache 612 und einen Datenanschluss 614. In einer Ausführungsform kann das skalierbare Durchführungseinheits-Array durch aktivieren oder deaktivieren einer oder mehrerer Durchführungseinheiten (z.B. eine von Durchführungseinheit 608A, 608B, 608C, 608D bis 608N-1 und 608N), basierend auf den Rechenanforderungen einer Nutzlast dynamisch skalieren. In einer Ausführungsform werden die enthaltenen Komponenten über ein Zwischenverbindungs-Fabric zwischenverbunden, das sich an jede der Komponenten anschließt. In manchen Ausführungsformen enthält Threaddurchführungslogik 600 eine oder mehrere Verbindungen zu Speicher, wie Systemspeicher oder Cachespeicher, durch einen oder mehrere von Befehlscache 606, Datenanschluss 614, Abtaster 610 und Durchführungseinheiten 608A-608N. In manchen Ausführungseinheiten ist jede Durchführungseinheit (z.B. 608A) eine eigenständige programmierbare Allzweckrecheneinheit, die fähig ist mehrere zeitgleiche Hardwarethreads durchzuführen, während mehrere Datenelemente parallel für jeden Thread verarbeitet werden. In unterschiedlichen Ausführungsformen ist das Array von Durchführungseinheiten 608A-608N skalierbar, um irgendeine Zahl individueller Durchführungseinheiten zu enthalten.
In manchen Ausführungsformen werden die Durchführungseinheiten 608A-608N vorranging verwendet, um Shaderprogramme durchzuführen. Ein Shaderprozessor 602 kann die unterschiedlichen Shaderprogramme verarbeiten und Durchführungsthreads, die den Shaderprogrammen zugehörig sind, über einen Threadversender 604 versenden. In einer Ausführungsform enthält der Threadversender Logik, um Threadinitialisierungsanfragen von den Grafik- und Medienpipelines zu vermitteln und die angefragten Threads auf einer oder mehreren Durchführungseinheiten in den Durchführungseinheiten 608A-608N zu instanziieren. Zum Beispiel kann die Geometriepipeline (z.B. 536 von 5) Vertex-, Tessellations- oder Geometrieshader für die Threaddurchführungslogik 600 (6) zur Verarbeitung versenden. In manchen Ausführungsformen kann Threadversender 604 auch Laufzeit-Threadhervorbringungsanfragen von den ablaufenden Shaderprogrammen verarbeiten.
In manchen Ausführungsformen unterstützen die Durchführungseinheiten 608A-608N einen Befehlssatz, der native Unterstützung für viele Standard-3D-Grafikshaderbefehle enthält, sodass Shaderprogramme von Grafikbibliotheken (z.B. Direct 3D und OpenGL) mit einer minimalen Übersetzung durchgeführt werden. Die Durchführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z.B. Vertexprogramme, Geometrieprogramme, Vertexshader), Pixelverarbeitung (z.B. Pixelshader, Fragmentshader) und Allzweckverarbeitung (z.B. Errechnen und Medienshader). Jede der Durchführungseinheiten 608A-608N ist zur Mehrfachausgabe von Einzelbefehls-Mehrdaten- (Single Instruction Multiple Data, SIMD) Durchführung fähig und multigethreadeter Betrieb ermöglicht eine effiziente Durchführungsumgebung angesichts von Speicherzugriffen mit hoher Latenz. Jeder Hardwarethread innerhalb jeder Durchführungseinheit hat eine dedizierte Registerdatei mit hoher Bandbreite und einen zugehörigen unabhängigen Threadzustand. Durchführung ist Mehrfachausgabe pro Takt an Pipelines, die zu Ganzzahl-, Einzel- und Doppelpräzisions-Gleitkommaoperationen, SIMD-Zweigkapazität, logischen Operationen, transzendentalen Operationen und anderen sonstigen Operationen fähig sind. Während auf Daten von Speicher oder einer der geteilten Funktionen gewartet wird, veranlasst Abhängigkeitslogik innerhalb der Durchführungseinheiten 608A-608N einen wartenden Thread zu ruhen, bis die angefragten Daten zurückgeschickt wurden. Während der wartende Thread ruht, können Hardwareressourcen sich einer Verarbeitung anderer Threads widmen. Zum Beispiel kann während einer Verzögerung, die einer Vertexshader-Operation zugehörig ist, eine Durchführungseinheit Operationen für einen Pixelshader, Fragmentshader oder anderen Typ von Shaderprogramm ausführen, enthaltend einen anderen Vertexshader.
Jede Durchführungseinheit in Durchführungseinheiten 608A-608N arbeitet auf Arrays von Datenelementen. Die Zahl an Datenelementen ist die „Durchführungsgröße“ oder die Zahl an Kanälen für den Befehl. Ein Durchführungskanal ist eine logische Einheit von Durchführung für Datenelementzugriff, Maskierung und Flusssteuerung innerhalb von Befehlen. Die Zahl an Kanälen kann von der Zahl physischer arithmetischer Logikeinheiten (Arithmetic Logic Units, ALUs) oder Gleitkommaeinheiten (Floating Point Units, FPUs) für einen bestimmten Grafikprozessor unabhängig sein. In manchen Ausführungsformen unterstützen Durchführungseinheiten 608A-608N Ganzzahl- und Gleitkommadatentypen.
Der Durchführungseinheitsbefehlssatz enthält SIMD-Befehle. Die unterschiedlichen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert sein und die Durchführungseinheit wird die unterschiedlichen Elemente basierend auf der Datengröße der Elemente verarbeiten. Zum Beispiel, wenn auf einem 256-Bit weiten Vektor arbeitend, sind die 256 Bits des Vektors in einem Register gespeichert und die Durchführungseinheit arbeitet auf dem Vektor als vier separate 64-Bit-gepackte Datenelemente (Quadword- (QW) Größen-Datenelemente), acht separate 32-Bit-gepackte Datenelemente (Doubleword- (DW) Größen-Datenelemente), sechzehn separate 16-Bit-gepackte Datenelemente (Word- (W) Größen-Datenelemente) oder zweiunddreißig separate 8-Bit Datenelemente (Byte- (B) Größe-Datenelemente). Verschiedene Vektorweiten und Registergrößen sind jedoch möglich.
Ein oder mehrere interne Befehlscaches (z.B. 606) sind in der Threaddurchführungslogik 600 enthalten, um Threadbefehle für die Durchführungseinheiten zu cachen. In manchen Ausführungsformen sind ein oder mehrere Datencaches (z.B. 612) enthalten, um Threaddaten während Threaddurchführung zu cachen. In manchen Ausführungsformen ist ein Abtaster 610 enthalten, um Texturabtastung für 3D-Operationen und Medianabtastung für Medienoperationen bereitzustellen. In manchen Ausführungsformen enthält Abtaster 610 spezialisierte Textur- oder Medienabtastungsfunktionalität, um Textur- oder Mediendaten während des Abtastungsprozesses zu verarbeiten, bevor die abgetasteten Daten an eine Durchführungseinheit bereitgestellt werden.
Während Durchführung senden die Grafik- und Medienpipelines Threadeinleitungsanfragen über Threadhervorbringungs- und Versandlogik an Threaddurchführungslogik 600. Sobald eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten gerastert wurde, wird Pixelprozessorlogik (z.B. Pixelshaderlogik, Fragmentshaderlogik usw.) innerhalb des Shaderprozessors 602 aufgerufen, um Ausgangsinformationen weiter zu errechnen und zu veranlassen, dass Ergebnisse zu Ausgangsflächen (z.B. Farbpuffern, Tiefenpuffern, Schablonenpuffer usw.) geschrieben werden. In manchen Ausführungsformen berechnet ein Pixelshader oder Fragmentshader die Werte der unterschiedlichen Vertexattribute, die über das gerasterte Objekt zu interpolieren sind. In manchen Ausführungsformen führt Pixelprozessorlogik innerhalb des Shaderprozessors 602 dann ein Anwendungsprogrammierschnittstellen- (Application Programming Interface, API) geliefertes Pixel- oder Fragmentshaderprogramm durch. Um das Shaderprogramm durchzuführen versendet der Shaderprozessor 602 Threads für eine Durchführungseinheit (z.B. 608A) über Threadversender 604. In manchen Ausführungsformen verwendet Pixelshader 602 Texturabtastungslogik in dem Abtaster 610, um auf Texturdaten in Texturmaps zuzugreifen, die in Speicher gespeichert sind. Arithmetische Operationen auf den Texturdaten und den Eingangsgeometriedaten errechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel von weiterer Verarbeitung.
In manchen Ausführungsformen stellt der Datenanschluss 614 einen Speicherzugriffsmechanismus für die Threaddurchführungslogik 600 bereit, um verarbeitete Daten zur Verarbeitung auf einer Grafikprozessorausgangspipeline an Speicher auszugeben. In manchen Ausführungsformen enthält der Datenanschluss 614 einen oder mehrere Cachespeicher (z.B. Datencache 612) oder koppelt sich mit diesen, um Daten für Speicherzugriff über den Datenanschluss zu cachen.
7 ist ein Blockdiagramm, das Grafikprozessorbefehlsformate 700 gemäß mancher Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessordurchführungseinheiten einen Befehlssatz mit Befehlen in mehreren Formaten. Die Kästchen mit durchgehender Linie veranschaulichen die Komponenten, die im Allgemeinen in einem Durchführungseinheitsbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einem Teilsatz der Befehle enthalten sind. In manchen Ausführungsformen sind in Befehlsformat 700 Makrobefehle derart beschrieben und veranschaulicht, dass sie Befehle sind, die an die Durchführungseinheit geliefert werden, im Gegensatz zu Mikrooperationen, die aus Befehlsdecodierung resultieren, sobald der Befehl verarbeitet ist.
In manchen Ausführungsformen unterstützen die Grafikprozessordurchführungseinheiten nativ Befehle in einem 128-Bit Befehlsformat 710. Ein 64-Bit komprimiertes Befehlsformat 730 ist für manche Befehle basierend auf dem ausgewählten Befehl, Befehlsoptionen und Zahl an Operanden verfügbar. Das native 128-Bit Befehlsformat 710 stellt Zugriff auf alle Befehlsoptionen bereit, während manche Optionen und Operationen im 64-Bit Befehlsformat 730 beschränkt sind. Die nativen Befehle, die im 64-Bit Befehlsformat 730 verfügbar sind, variieren je nach Ausführungsform. In manchen Ausführungsformen ist der Befehl teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 komprimiert. Die Durchführungseinheitshardware bezieht sich auf einen Satz von Komprimierungstabellen, basierend auf den Indexwerten, und verwendet die Komprimierungstabellenausgänge, um einen nativen Befehl im 128-Bit Befehlsformat 710 zu rekonstruieren.
Für jedes Format definiert Befehlsopcode 712 die Operation, die die Durchführungseinheit ausführen soll. Die Durchführungseinheit führt jeden Befehl parallel über die mehreren Datenelemente für jeden Operanden durch. Zum Beispiel, als Reaktion auf einen Zugabebefehl, führt die Durchführungseinheit eine zeitgleiche Zugabeoperation über jeden Farbkanal aus, der ein Texturelement oder Bildelement darstellt. Standardmäßig führt die Durchführungseinheit jeden Befehl über alle Datenkanäle des Operanden aus. In manchen Ausführungsformen ermöglicht Befehlssteuerfeld 714 Steuerung über gewisse Durchführungsoptionen, wie Kanalauswahl (z.B. Vorhersage) und Datenkanalreihung (z.B. Neuanordnung). Für Befehle im 128-Bit Befehlsformat 710 begrenzt ein Exec-Größenfeld 716 die Zahl an Datenkanälen, die parallel durchgeführt werden. In manchen Ausführungsformen ist Exec-Größenfeld 716 nicht zur Verwendung im 64-Bit komprimierten Befehlsformat 730 verfügbar.
Manche Durchführungseinheitsbefehle haben bis zu drei Operanden, enthaltend zwei Quelloperanden, src0 720, src1 722 und ein Ziel 718. In manchen Ausführungsformen unterstützen die Durchführungseinheiten Doppelzielbefehle, wo eines der Ziele impliziert ist. Datenmanipulationsbefehle können einen dritten Quelloperanden (z.B. SRC2 724) haben, wo der Befehlsopcode 712 die Zahl an Quelloperanden bestimmt. Ein letzter Quelloperand des Befehls kann ein Immediat-(z.B. festcodierter) Wert sein, der mit dem Befehl weitergegeben wird.
In manchen Ausführungsformen enthält das 128-Bit Befehlsformat 710 ein Zugriffs-/Adressiermodusfeld 726, das zum Beispiel spezifiziert, ob direkter Registeradressierungsmodus oder indirekter Adressierungsmodus verwendet wird. Wenn direkter Registeradressierungsmodus verwendet wird, wird die Registeradresse von einem oder mehreren Operanden direkt durch Bits im Befehl bereitgestellt.
In manchen Ausführungsformen enthält das 128-Bit Befehlsformat 710 ein Zugriffs-/Adressiermodusfeld 726, das einen Adressiermodus und/oder einen Zugriffsmodus für den Befehl spezifiziert. In einer Ausführungsform wird der Adressiermodus verwendet, um eine Datenzugriffsausrichtung für den Befehl zu definieren. Manche Ausführungsformen unterstützen Zugriffsmodi, die einen 16-Byte ausgerichteten Zugriffsmodus und einen 1-Byte ausgerichteten Zugriffsmodus enthalten, wo die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Befehlsoperanden bestimmt. Zum Beispiel, wenn in einem ersten Modus, kann der Befehl Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und wenn in einem zweiten Modus, kann der Befehl 16-Byte ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressiermodusabschnitt des Zugriffs-/Adressiermodusfelds 726, ob der Befehl direkte oder indirekte Adressierung verwenden soll. Wenn direkter Registeradressierungsmodus verwendet wird, stellen Bits im Befehl die Registeradresse von einem oder mehreren Operanden direkt bereit. Wenn indirekter Registeradressierungsmodus verwendet wird, kann die Registeradresse von einem oder mehreren Operanden basierend auf einem Adressregisterwert und einem Adressimmediatfeld im Befehl errechnet werden.
In manchen Ausführungsformen werden Ausführungsbefehle basierend auf Opcode 712 Bit-Felder gruppiert, um Opcodedecodierung 740 zu vereinfachen. Für einen 8-Bit Opcode erlauben Bits 4, 5 und 6 der Durchführungseinheit, den Typ von Opcode zu bestimmen. Die gezeigte präzise Opcodegruppierung ist lediglich ein Beispiel. In manchen Ausführungsformen enthält eine Bewegungs- und Logikopcodegruppe 742 Datenbewegungs- und Logikbefehle (z.B. bewegen (move, mov), vergleichen (compare, cmp)). In manchen Ausführungsformen teilt die Bewegungs- und Logikgruppe 742 die fünf signifikantesten Bits (Most Significant Bits, MSB), wo bewegen (mov)-Befehle in der Form von 0000xxxxb und Logikbefehle in der Form von 0001xxxxb sind. Eine Flusssteuerbefehlsgruppe 744 (z.B. Anruf, Sprung (jump, jmp)) enthält Befehle in der Form von 0010xxxxb (z.B. 0x20). Eine sonstige Befehlsgruppe 746 enthält eine Mischung aus Befehlen, enthaltend Synchronisationsbefehle (z.B. Warten, Senden) in der Form von 001 Ixxxxb (z.B. 0x30). Eine parallele Mathematikbefehlsgruppe 748 enthält komponentenweise arithmetische Befehle (z.B. Addieren, Multiplizieren (mul)) in der Form von 0100xxxxb (z.B. 0x40). Die parallele Mathematikgruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle aus. Die Vektormathematikgruppe 750 enthält arithmetische Befehle (z.B. dp4) in der Form von 0101xxxxb (z.B. 0x50). Die Vektormathematikgruppe führt Arithmetik aus, so wie Skalarproduktberechnungen auf Vektoroperanden.
Grafikpipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente von 8 haben dieselben Bezugsnummern (oder - namen), da die Elemente von jeder anderen Figur hierin auf jede Weise ähnlich der woanders hierin beschriebenen arbeiten oder fungieren, sind aber nicht auf solche begrenzt.
In manchen Ausführungsformen enthält Grafikprozessor 800 eine Grafikpipeline 820, eine Medienpipeline 830, eine Anzeige-Engine 840, Threaddurchführungslogik 850 und eine Renderausgangspipeline 870. In manchen Ausführungsformen ist Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkernverarbeitungssystems, das einen oder mehrere Allzweckverarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Kommandos, die über eine Ringzwischenverbindung 802 an Grafikprozessor 800 ausgegeben werden, gesteuert. In manchen Ausführungsformen koppelt die Ringzwischenverbindung 802 Grafikprozessor 800 an andere Verarbeitungskomponenten, wie andere Grafikprozessoren oder Allzweckprozessoren. Kommandos von Ringzwischenverbindung 802 werden durch einen Kommandostreamer 803 interpretiert, der Befehle an individuelle Komponenten von Grafikpipeline 820 oder Medienpipeline 830 liefert.
In manchen Ausführungsformen lenkt Kommandostreamer 803 den Betrieb eines Vertexabrufers 805, der Vertexdaten aus Speicher liest und Vertexverarbeitungskommandos durchführt, die durch Kommandostreamer 803 bereitgestellt sind. In manchen Ausführungsformen stellt Vertexabrufer 805 Vertexdaten an einen Vertexshader 807 bereit, der Koordinatenraumtransformation und Belichtungsoperationen an jedem Vertex ausführt. In manchen Ausführungspunkten führen Vertexabrufer 805 und Vertexshader 807 Vertexverarbeitungsbefehle durch Versenden von Durchführungsthreads an Durchführungseinheiten 852A-852B über einen Threadversender 831 durch.
In manchen Ausführungsformen sind Durchführungseinheiten 852A-852B ein Array von Vektorprozessoren mit einem Befehlssatz zum Ausführen von Grafik- und Medienoperationen. In manchen Ausführungsformen haben Durchführungseinheiten 852A-852B einen angehängten L1-Cache 851, der für jedes Array spezifisch ist oder zwischen den Arrays geteilt wird. Der Cache kann als ein Datencache, ein Befehlscache oder ein einzelner Cache konfiguriert sein, der partitioniert ist, Daten und Befehle in verschiedenen Partitionen zu beinhalten.
In manchen Ausführungsformen enthält Grafikpipeline 820 Tessellationskomponenten, um hardwarebeschleunigte Tessellation von 3D-Objekten auszuführen. In manchen Ausführungsformen konfiguriert ein programmierbarer Hüllenshader 811 die Tessellationsoperationen. Ein programmierbarer Domänenshader 817 stellt Backend-Evaluierung von Tessellationsausgang bereit. Ein Tessellator 813 arbeitet bei der Richtung von Hüllenshader 811 und beinhaltet Sonderzwecklogik, um einen Satz detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell zu erzeugen, das als Eingang zu Grafikpipeline 820 bereitgestellt ist. In manchen Ausführungsformen, falls Tessellation nicht verwendet wird, können Tessellationskomponenten (z.B. Hüllenshader 811, Tessellator 813 und Domänenshader 817) umgangen werden.
In manchen Ausführungsformen können komplette geometrische Objekte durch einen Geometrieshader 819 über einen oder mehrere Threads verarbeitet werden, die an Durchführungseinheiten 852A-852B gesendet werden, oder können direkt zum Begrenzer 829 fortschreiten. In manchen Ausführungsformen arbeitet der Geometrieshader auf gesamten geometrischen Objekten, statt Vertices oder Stellen von Vertices wie in vorherigen Phasen der Grafikpipeline. Falls die Tessellation deaktiviert ist, empfängt der Geometrieshader 819 Eingang vom Vertexshader 807. In manchen Ausführungsformen ist Geometrieshader 819 durch ein Geometrieshaderprogramm programmierbar, um Geometrietessellation auszuführen, falls die Tessellationseinheiten deaktiviert sind.
Vor Rasterung verarbeitet ein Begrenzer 829 Vertexdaten. Der Begrenzer 829 kann ein Begrenzer mit fixierter Funktion oder ein programmierbarer Begrenzer mit Begrenzungs- und Geometrieshaderfunktionen sein. In manchen Ausführungsformen plant eine Rasterungs- und Tiefentestkomponente 873 in der Renderausgangspipeline 870 Pixelshader ein, um die geometrischen Objekte in deren Pro-Pixel-Darstellung umzuwandeln. In manchen Ausführungsformen ist Pixelshaderlogik in Threaddurchführungslogik 850 enthalten. In manchen Ausführungsformen kann eine Anwendung die Rasterungs- und Tiefentestkomponente 873 umgehen und über eine Ausströmeinheit 823 auf ungerasterte Vertexdaten zugreifen.
Der Grafikprozessor 800 hat einen Zwischenverbindungsbus, ein Zwischenverbindungs-Fabric oder einen anderen Zwischenverbindungsmechanismus, der Daten und Nachrichten unter den Hauptkomponenten des Prozessors Durchgang erlaubt. In manchen Ausführungsformen zwischenverbinden sich Durchführungseinheiten 852A-852B und zugehörige(r) Cache(s) 851, Textur- und Medienabtaster 854 und Textur-/Abtastercache 858 über einen Datenanschluss 856, um Speicherzugriff auszuführen und mit Renderausgangspipelinekomponenten des Prozessors zu kommunizieren. In manchen Ausführungsformen haben Abtaster 854, Caches 851, 858 und Durchführungseinheiten 852A-852B jeweils separate Speicherzugriffspfade.
In manchen Ausführungsformen beinhaltet Renderausgangspipeline 870 eine Rasterungs- und Tiefentestkomponente 873, die Vertex-basierte Objekte in eine zugehörige Pixel-basierte Darstellung umwandelt. In manchen Ausführungsformen enthält die Rasterungslogik eine Windower-/Maskereinheit, um Dreiecks- und Linienrasterung mit fixierter Funktion auszuführen. Ein zugehöriger Rendercache 878 und Tiefencache 879 sind in manchen Ausführungsformen auch verfügbar. Eine Pixeloperationskomponente 877 führt Pixel-basierte Operationen an den Daten aus, obwohl in manchen Instanzen Pixeloperationen, die 2D-Operationen zugehörig sind (z.B. Bitblockbildübermittlungen mit Überlagern) durch die 2D-Engine 841 ausgeführt oder bei Anzeigezeit durch die Anzeigesteuerung 843 unter Verwendung von Einblendungsanzeigeebenen ersetzt werden. In manchen Ausführungsformen ist ein geteilter L3-Cache 875 allen Grafikkomponenten verfügbar, was das Teilen von Daten ohne die Verwendung von Hauptsystemspeicher erlaubt.
In manchen Ausführungsformen enthält Grafikprozessormedienpipeline 830 eine Medien-Engine 837 und ein Video-Frontend 834. In manchen Ausführungsformen empfängt Video-Frontend 834 Pipelinekommandos vom Kommandostreamer 803. In manchen Ausführungsformen enthält Medienpipeline 830 einen separaten Kommandostreamer. In manchen Ausführungsformen verarbeitet Video-Frontend 834 Medienkommandos vor Senden des Kommandos an die Medien-Engine 837. In manchen Ausführungsformen enthält Medien-Engine 837 Threadhervorbringungsfunktionalität, um Threads hervorzubringen, die für Threaddurchführungslogik 850 über Threadversender 831 zu versenden sind.
In manchen Ausführungsformen enthält Grafikprozessor 800 eine Anzeige-Engine 840. In manchen Ausführungsformen ist Anzeige-Engine 840 extern vom Prozessor 800 und koppelt sich über die Ringzwischenverbindung 802 oder einen anderen Zwischenverbindungsbus oder ein Fabric mit dem Grafikprozessor. In manchen Ausführungsformen enthält Anzeige-Engine 840 eine 2D-Engine 841 und eine Anzeigesteuerung 843. In manchen Ausführungsformen beinhaltet Anzeige-Engine 840 Sonderzwecklogik, die fähig ist unabhängig von der 3D-Pipeline zu arbeiten. In manchen Ausführungsformen koppelt sich Anzeigesteuerung 843 mit einem Anzeigegerät (nicht gezeigt), das ein systemintegriertes Anzeigegerät sein kann, wie in einem Laptopcomputer, oder ein externes Anzeigegerät, das über einen Anzeigegerätverbinder angehängt ist.
In manchen Ausführungsformen sind Grafikpipeline 820 und Medienpipeline 830 konfigurierbar, Operationen basierend auf mehreren Grafik- und Medienprogrammierungsschnittstellen auszuführen und sind nicht für irgendeine Anwendungsprogrammierschnittstelle (API) spezifisch. In manchen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Anrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Kommandos, die durch den Grafikprozessor verarbeitet werden können. In manchen Ausführungsformen ist Unterstützung für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan Grafik und Rechen-API, alle von der Khronos Group, bereitgestellt. In manchen Ausführungsformen kann auch Unterstützung für Direct3D Bibliothek von der Microsoft Corporation bereitgestellt sein. In manchen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt sein. Unterstützung kann auch für die Open Source Computer Vision Library (OpenCV) bereitgestellt sein. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde auch unterstützt werden, falls ein Mapping von der Pipeline der zukünftigen PAI zur Pipeline des Grafikprozessors vorgenommen werden kann.
Grafikpipeline-Programmierung
9A ist ein Blockdiagramm, das ein Grafikprozessorkommandoformat 900 gemäß mancher Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das eine Grafikprozessorkommandosequenz 910 gemäß einer Ausführungsform veranschaulicht. Die Kästchen mit durchgehender Linie in 9A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikkommando enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einem Teilsatz der Grafikkommandos enthalten sind. Das beispielhafte Grafikprozessorkommandoformat 900 von 9A enthält Datenfelder, um einen Ziel-Client 902 des Kommandos, einen Kommandooperationscode (Opcode) 904 und die relevanten Daten 906 für das Kommando zu identifizieren. Ein Teilopcode 905 und eine Kommandogröße 908 sind auch in manchen Kommandos enthalten.
In manchen Ausführungsformen spezifiziert der Client 902 die Client-Einheit des Grafikgeräts, die die Kommandodaten verarbeitet. In manchen Ausführungsformen untersucht ein Grafikprozessor-Kommandozerteiler das Client-Feld von jedem Kommando, um die weitere Verarbeitung des Kommandos weiter zu bedingen und die Kommandodaten zur geeigneten Client-Einheit zu leiten. In manchen Ausführungsformen enthalten die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Client-Einheit hat eine entsprechende Verarbeitungs-Pipeline, die die Befehle verarbeitet. Sobald das Kommando durch die Client-Einheit empfangen wird, liest die Client-Einheit den Opcode 904 und, falls vorhanden, Teilopcode 905, um die auszuführende Operation zu bestimmen. Die Client-Einheit führt das Kommando unter Verwendung von Informationen in Datenfeld 906 aus. Für manche Kommandos wird erwartet, dass eine explizite Kommandogröße 908 die Größe des Kommandos spezifiziert. In manchen Ausführungsformen bestimmt der Kommandozerteiler automatisch die Größe von mindestens manchen der Kommandos, basierend auf dem Kommandoopcode. In manchen Ausführungsformen sind Kommandos über Vielfache eines Doubleword ausgerichtet.
Das Flussdiagramm in 9B zeigt eine beispielhafte Grafikprozessorkommandosequenz 910. In manchen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors darbietet, eine Version der Kommandosequenz, die zeigt wie ein Satz von Grafikoperationen einzurichten, durchzuführen und zu beenden ist. Eine Abtastkommandosequenz wird nur zu beispielhaften Zwecken gezeigt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Kommandos oder diese Kommandosequenz begrenzt sind. Außerdem können die Kommandos als Stapel von Kommandos in einer Kommandosequenz derart ausgegeben werden, dass der Grafikprozessor die Sequenz von Kommandos mindestens in teilweiser Gleichzeitigkeit verarbeiten wird.
In manchen Ausführungsformen kann die Grafikprozessorkommandosequenz 910 mit einem Pipelineleerungskommando 912 beginnen, um eine aktive Grafikpipeline zu veranlassen, die momentan ausstehenden Kommandos für die Pipeline zu beenden. In manchen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medienpipeline 924 nicht gleichzeitig. Die Pipelineleerung wird ausgeführt, um die aktive Grafikpipeline zu veranlassen, alle ausstehenden Kommandos zu beenden. Als Reaktion auf eine Pipelineleerung wird der Kommandozerteiler für den Grafikprozessor Kommandoverarbeitung pausieren, bis die aktiven Zeichnungs-Engines ausstehende Operationen beenden und die relevanten Lese-Caches für ungültig erklärt sind. Optional können alle Daten im Rendercache, der als „schmutzig“ markiert ist, zum Speicher geleert werden. In manchen Ausführungsformen kann Pipelineleerungskommando 912 für Pipelinesynchronisation oder vor Platzieren des Grafikprozessors in einen Niederleistungszustand verwendet werden.
In manchen Ausführungsformen wird ein Pipelineauswahlkommando 913 verwendet, wenn eine Kommandosequenz verlangt, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. In manchen Ausführungsformen wird ein Pipelineauswahlkommando 913 nur einmal innerhalb eines Durchführungskontexts benötigt, bevor Pipelinekommandos ausgegeben werden, es sei denn der Kontext ist, Kommandos für beide Pipelines auszugeben. In manchen Ausführungsformen wird ein Pipelineleerungskommando 912 unmittelbar vor einer Pipelineumschaltung über das Pipelineauswahlkommando 913 benötigt.
In manchen Ausführungsformen konfiguriert ein Pipelinesteuerkommando 914 eine Grafikpipeline für Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medienpipeline 924 zu programmieren. In manchen Ausführungsformen konfiguriert Pipelinesteuerkommando 914 den Pipelinezustand für die aktive Pipeline. In einer Ausführungsform wird das Pipelinesteuerkommando 914 für Pipelinesynchronisation und zur Räumung von Daten aus einem oder mehreren Cachespeichern innerhalb der aktiven Pipeline verwendet, bevor ein Stapel von Kommandos verarbeitet wird.
In manchen Ausführungsformen werden Kommandos für den Rückkehrpufferzustand 916 verwendet, um einen Satz von Rückkehrpuffern für die jeweiligen Pipelines zu konfigurieren, Daten zu schreiben. Manche Pipelineoperationen benötigen die Zuteilung, Auswahl oder Konfiguration von einem oder mehreren Rückkehrpuffern, in die die Operationen während Verarbeitung dazwischenliegende Daten schreiben. In manchen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückkehrpuffer, um Ausgangsdaten zu speichern und Kreuz-Threadkommunikation auszuführen. In manchen Ausführungsformen enthält Konfigurieren des Rückkehrpufferzustands 916 Auswählen der Größe und Zahl von Rückkehrpuffern, die für einen Satz von Pipelineoperationen zu verwenden sind.
Die verbleibenden Kommandos in der Kommandosequenz unterscheiden sich, basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipelinebestimmung 920 ist die Kommandosequenz auf die 3D-Pipeline 922 maßgeschneidert, beginnend mit dem 3D-Pipelinezustand 930, oder die Medienpipeline 924, beginnend beim Medienpipelinezustand 940.
Die Kommandos zum Konfigurieren des 3D-Pipelinezustands 930 enthalten 3D-Zustandseinstellungskommandos für Vertexpufferzustand, Vertexelementzustand, konstanten Farbzustand, Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitivkommandos verarbeitet werden. Die Werte dieser Kommandos werden mindestens teilweise basierend auf der bestimmten 3D-API in Verwendung bestimmt. In manchen Ausführungsformen sind 3D-Pipelinezustands- 930 Kommandos auch fähig, selektiv gewisse Pipelineelemente zu deaktivieren oder umgehen, falls diese Elemente nicht verwendet werden.
In manchen Ausführungsformen wird 3D-Primitiv- 932 Kommando verwendet, um 3D-Primitive vorzulegen, die durch die 3D-Pipeline zu verarbeiten sind. Kommandos und zugehörige Parameter, die über das 3D-Primitiv- 932 Kommando an den Grafikprozessor weitergegeben werden, werden an die Vertexabruffunktion in der Grafikpipeline weitergeleitet. Die Vertexabruffunktion verwendet 3D-Primitiv- 932 Kommandodaten, um Vertexdatenstrukturen zu erzeugen. Die Vertexdatenstrukturen werden in einem oder mehreren Rückkehrpuffern gespeichert. In manchen Ausführungsformen wird 3D-Primitiv- 932 Kommando verwendet, um Vertexoperationen auf 3D-Primitiven über Vertexshader auszuführen. Um Vertexshader zu verarbeiten, sendet 3D-Pipeline 922 Shaderdurchführungsthreads an Grafikprozessordurchführungseinheiten.
In manchen Ausführungsformen wird 3D-Pipeline 922 über ein Durchführen- 934 Kommando oder Ereignis ausgelöst. In manchen Ausführungsformen löst ein Registerschreibvorgang eine Kommandodurchführung aus. In manchen Ausführungsformen wird eine Durchführung über ein „go“ oder „kick“ Kommando in der Kommandosequenz ausgelöst. In einer Ausführungsform wird Kommandodurchführung unter Verwendung eines Pipelinesynchronisationskommandos ausgelöst, um die Kommandosequenz durch die Grafikpipeline zu leeren. Die 3D-Pipeline wird Geometrieverarbeitung für die 3D-Primitive ausführen. Sobald Operationen beendet sind, werden die resultierenden geometrischen Objekte gerastert und die Pixel-Engine färbt die resultierenden Pixel. Zusätzliche Kommandos, um Pixelshading und Pixel-Backendoperationen zu steuern, können auch für diese Operationen enthalten sein.
In manchen Ausführungsformen folgt die Grafikprozessorkommandosequenz 910 dem Medienpipeline- 924 Pfad, wenn Medienoperationen ausgeführt werden. Im Allgemeinen hängt die spezifische Nutzung und Weise von Programmieren für die Medienpipeline 924 von den auszuführenden Medien- oder Rechenoperationen ab. Spezifische Mediendecodierungsoperationen können während Mediendecodierung zur Medienpipeline abgeladen werden. In manchen Ausführungsformen kann die Medienpipeline auch umgangen werden und Mediendecodierung kann als Ganzes oder teilweise unter Verwendung von Ressourcen ausgeführt werden, die durch einen oder mehrere Allzweckverarbeitungskerne bereitgestellt sind. In einer Ausführungsform enthält die Medienpipeline auch Elemente für Allzweckgrafikprozessoreinheit- (General-Purpose Graphics Processor Unit, GPGPU) Operationen, wo der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Rechen-Shaderprogrammen auszuführen, die nicht explizit auf das Rendering von Grafikprimitiven bezogen sind.
In manchen Ausführungsformen ist Medienpipeline 924 auf eine ähnliche Weise wie die 3D-Pipeline 922 konfiguriert. Ein Satz von Kommandos, um den Medienpipelinezustand 940 zu konfigurieren, wird gesendet oder vor den Medienobjektkommandos 942 in eine Kommandoschlange platziert. In manchen Ausführungsformen enthalten Kommandos für den Medienpipelinezustand 940 Daten, um die Medienpipelineelemente zu konfigurieren, die verwendet werden, um die Medienobjekte zu verarbeiten. Dies enthält Daten zum Konfigurieren der Videodecodierungs- und Videocodierungslogik innerhalb der Medienpipeline, wie Codierungs- und Decodierungsformat. In manchen Ausführungsformen unterstützen Kommandos für den Medienpipelinezustand 940 auch die Nutzung von einem oder mehreren Adresshinweisen zu „indirekten“ Zustandselementen, die einen Stapel von Zustandseinstellungen beinhalten.
In manchen Ausführungsformen liefert Medienpipeline 924 Adresshinweise zu Medienobjekten zur Verarbeitung durch die Medienpipeline. Die Medienobjekte enthalten Speicherpuffer, die zu verarbeitende Videodaten beinhalten. In manchen Ausführungsformen müssen alle Medienpipelinezustände gültig sein, bevor ein Medienobjektkommando 942 ausgegeben wird. Sobald der Pipelinezustand konfiguriert ist und Medienobjektkommandos 942 angereiht sind, wird die Medienpipeline 924 über ein Durchführungskommando 944 oder ein äquivalentes Durchführungsereignis (z.B. Registerschreibvorgang) ausgelöst. Ausgang von Medienpipeline 924 kann dann durch Operationen nachbearbeitet werden, die durch die 3D-Pipeline 922 oder die Medienpipeline 924 bereitgestellt sind. In manchen Ausführungsformen sind GPGPU-Operationen auf ähnliche Weise wie Medienoperationen konfiguriert und durchgeführt.
Grafiksoftwarearchitektur
10 veranschaulicht beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß manchen Ausführungsformen. In manchen Ausführungsformen enthält Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. In manchen Ausführungsformen enthält Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Allzweckprozessorkern(e) 1034. Die Grafikanwendung 1010 und Betriebssystem 1020 laufen jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ab.
In manchen Ausführungsformen beinhaltet 3D-Grafikanwendung 1010 ein oder mehrere Shaderprogramme, enthaltend Shader-Befehle 1012. Die Shadersprachenbefehle können in einer Shader-Hochsprache, wie der High Level Shader Language (HLSL) oder der OpenGL Shader Language (GLSL) sein. Die Anwendung enthält auch durchführbare Befehle 1014 in einer Maschinensprache, die zur Durchführung durch den Allzweckprozessorkern 1034 geeignet sind. Die Anwendung enthält auch Grafikobjekte 1016, die durch Vertexdaten definiert sind.
In manchen Ausführungsformen ist Betriebssystem 1020 ein Microsoft® Windows® Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein quelloffenes UNIX-ähnliches Betriebssystem, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022, wie die Direct3D-API, die OpenGL-API oder die Vulkan-API unterstützen. Wenn die Direct3D-API in Verwendung ist, verwendet das Betriebssystem 1020 einen Frontend-Shaderkompilierer 1024, um alle Shaderbefehle 1012 in HLSL in eine niedrige Shadersprache zu kompilieren. Die Kompilierung kann eine Just-in-Time (JIT) Kompilierung sein oder die Anwendung kann Shaderkompilierung ausführen. In manchen Ausführungsformen werden höhere Shader während der Kompilierung der 3D-Grafikanwendung 1010 in niedrigere Shader kompiliert. In manchen Ausführungsformen werden die Shaderbefehle 1012 in einer zwischenliegenden Form bereitgestellt, wie einer Version der Standard Portable Intermediate Repräsentation (SPIR), die von der Vulkan-API verwendet wird.
In manchen Ausführungsformen beinhaltet Anwendermodus-Grafiktreiber 1026 einen Backend-Shaderkompilierer 1027, um die Shaderbefehle 1012 in eine hardwarespezifische Darstellung umzuwandeln. Wenn die OpenGL-API verwendet wird, werden Shaderbefehle 1012 in der GLSL-Hochsprache an einen Anwendermodus-Grafiktreiber 1026 zur Kompilierung weitergegeben. In manchen Ausführungsformen verwendet Anwendermodus-Grafiktreiber 1026 Betriebssystem-Kernelmodusfunktionen 1029, um mit einem Kernelmodus-Grafiktreiber 1029 zu kommunizieren. In manchen Ausführungsformen kommuniziert Kernelmodus-Grafiktreiber 1029 mit Grafikprozessor 1032, um Kommandos und Befehle einzuplanen.
IP-Kern-Implementierungen
Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik innerhalb eines integrierten Schaltkreises, wie eines Prozessors, darstellt und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Befehle enthalten, die unterschiedliche Logik innerhalb des Prozessors darstellen. Wenn von einer Maschine gelesen, können die Befehle die Maschine veranlassen, die Logik zu fertigen, um die hierin beschriebenen Techniken auszuführen. Solche Darstellungen, als „IP-Kerne“ bekannt, sind wiederverwendbare Einheiten von Logik für einen integrierten Schaltkreis, der auf einem greifbaren, maschinenlesbaren Medium als ein Hardwaremodell gespeichert werden kann, das die Struktur des integrierten Schaltkreises beschreibt. Das Hardwaremodell kann an unterschiedliche Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Fertigungsmaschinen laden, die den integrierten Schaltkreis herstellen. Der integrierte Schaltkreis kann derart gefertigt werden, dass der Schaltkreis Operationen ausführt, die in Verknüpfung mit einer der hierin beschriebenen Ausführungsformen beschrieben werden.
11 ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100 veranschaulicht, das verwendet werden kann, um einen integrierten Schaltkreis herzustellen, um Operationen gemäß einer Ausführungsform auszuführen. Das IP-Kern-Entwicklungssystem 1100 kann verwendet werden, um modulare wiederverwendbare Gestaltungen zu erzeugen, die in eine größere Gestaltung eingegliedert werden können oder verwendet werden können, um einen gesamten integrierten Schaltkreis (z.B. einen SOC-integrierten Schaltkreis) zu konstruieren. Eine Gestaltungseinrichtung 1130 kann eine Softwaresimulation 1110 einer IP-Kern-Gestaltung in einer Programmierhochsprache (z.B. C/C++) erzeugen. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu gestalten, zu testen und zu verifizieren. Das Simulationsmodell 1112 kann funktionelle, verhaltensmäßige und/oder Taktungssimulationen enthalten. Eine Registerübermittlungsstufen- (Register Transfer Level, RTL) Gestaltung 1115 kann dann erzeugt oder aus dem Simulationsmodell 1112 synthetisiert werden. Die RTL-Gestaltung 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss von digitalen Signalen zwischen Hardwareregistern modelliert, enthaltend die zugehörige Logik, die unter Verwendung der modellierten digitalen Signale ausgeführt wird. Zusätzlich zu einer RTL-Gestaltung 1115 können niedrigere Gestaltungen bei der Logikstufe oder Transistorstufe auch erzeugt, gestaltet oder synthetisiert werden. Daher können die bestimmten Details der anfänglichen Gestaltung und Simulation variieren.
Die RTL-Gestaltung 1115 oder das Äquivalent kann weiter durch die Gestaltungseinrichtung in ein Hardwaremodell 1120 synthetisiert werden, das in einer Hardwarebeschreibungssprache (Hardware Description Language, HDL) oder einer anderen Darstellung physischer Gestaltungsdaten sein kann. Die HDL kann weiter simuliert oder getestet werden, um die IP-Kern-Gestaltung zu verifizieren. Die IP-Kern-Gestaltung kann zur Zustellung an eine Dritt-Fertigungseinrichtung 1165 unter Verwendung von nichtflüchtigem Speicher 1140 (z.B. Festplatte, Flashspeicher oder irgendeinem nichtflüchtigen Datenspeichermedium) gespeichert werden. Alternativ kann die IP-Kern-Gestaltung über eine verdrahtete Verbindung 1150 oder drahtlose Verbindung 1160 übertragen werden (z.B. über das Internet). Die Fertigungseinrichtung 1165 kann dann einen integrierten Schaltkreis fertigen, der mindestens teilweise auf der IP-Kern-Gestaltung basiert. Der gefertigte integrierte Schaltkreis kann konfiguriert sein, Operationen in Übereinstimmung mit mindestens einer hierin beschriebenen Ausführungsform auszuführen.
Beispielhafter System-auf-einem-Chip-integrierter Schaltkreis
12-14 veranschaulichen beispielhafte integrierte Schaltkreise und zugehörige Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne gemäß unterschiedlichen hierin beschriebenen Ausführungsformen gefertigt werden können. Zusätzlich zu dem, was veranschaulicht ist, können andere Logik und Schaltkreise enthalten sein, enthaltend zusätzliche Grafikprozessoren/kerne, periphere Schnittstellensteuerungen oder Allzweckprozessorkerne.
12 ist ein Blockdiagramm, das einen beispielhaften System-auf-einem-Chip-integrierten Schaltkreis 1200 veranschaulicht, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform. Beispielhafter integrierter Schaltkreis 1200 enthält einen oder mehrere Anwendungsprozessor(en) 1205 (z.B. CPUs), mindestens einen Grafikprozessor 1210 und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 enthalten, von welchen jeder ein modularer IP-Kern von derselben oder mehreren verschiedenen Gestaltungseinrichtungen sein kann. Integrierter Schaltkreis 1200 enthält Peripheriegerät- oder Buslogik, enthaltend eine USB-Steuerung 1225, UART-Steuerung 1230, eine SPI/SDIO-Steuerung 1235 und eine IS2/I2C-Steuerung 1240. Zusätzlich kann der integrierte Schaltkreis ein Anzeigegerät 1245 enthalten, das mit einer oder mehreren von einer High-Definition Multimedia Interface (HDMI) Steuerung 1250 und einer Mobile Industry Processor Interface (MIPI) Anzeigeschnittstelle 1255 gekoppelt ist. Datenspeicher kann durch ein Flashspeicher-Teilsystem 1260 bereitgestellt werden, das Flashspeicher und eine Flashspeichersteuerung enthält. Speicherschnittstelle kann über eine Speichersteuerung 1265 zum Zugriff auf SDRAM oder SRAM Speichergeräte bereitgestellt werden. Manche integrierte Schaltkreise enthalten zusätzlich eine eingebettete Sicherheits-Engine 1270.
13 ist ein Blockdiagramm, das einen beispielhaften Grafikprozessor 1310 eines System-auf-einem-Chip-integrierten Schaltkreises gemäß einer Ausführungsform veranschaulicht, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann. Grafikprozessor 1310 kann eine Variante des Grafikprozessors 1210 von 12 sein. Grafikprozessor 1310 enthält einen Vertexprozessor 1305 und einen oder mehrere Fragmentprozessor(en) 1315A-1315N (Z.B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N). Grafikprozessor 1310 kann verschiedene Shaderprogramme über separate Logik derart durchführen, dass der Vertexprozessor 1305 optimiert ist, um Operationen für Vertexshaderprogramme durchzuführen, während der eine oder die mehreren Fragmentprozessor(en) 1315A-1315N Fragment-(z.B. Pixel) Shading-Operationen für Fragment- oder Pixelshaderprogramme durchführen. Der Vertexprozessor 1305 führt die Vertexverarbeitungsphase der 3D-Grafikpipeline aus und erzeugt Primitiv- und Vertexdaten. Der (Die) Fragmentprozessor(en) 1315A-1315N verwenden die Primitiv- und Vertexdaten, die vom Vertexprozessor 1305 erzeugt werden, um einen Framepuffer zu produzieren, der auf einem Anzeigegerät angezeigt wird. In einer Ausführungsform sind der (die) Fragmentprozessor(en) 1315A-1315N optimiert, um Fragmentshaderprogramme, wie in der OpenGL-API bereitgestellt, durchzuführen, die verwendet werden können, um ähnliche Operationen wie ein Pixelshaderprogramm, wie in der Direct 3D API bereitgestellt, auszuführen.
Grafikprozessor 1310 enthält zusätzlich eine oder mehrere Speicherverwaltungseinheiten (Memory Management Units, MMUs) 1320A-1320B, Cache(s) 1325A-1325B und Schaltkreiszwischenverbindung(en) 1330A-1330B. Die eine oder die mehreren MMU(s) 1320A-1320B stellen virtuelle zu physischer Adresse-Mapping für Grafikprozessor 1310 bereit, einschließlich für den Vertexprozessor 1305 und/oder Fragmentprozessor(en) 1315A-1315N, die Vertex- oder Bild-/Texturdaten referenzieren können, die in einem Speicher gespeichert sind, zusätzlich zu Vertex- oder Bild-/Texturdaten, die in dem einen oder den mehreren Cache(s) 1325A-1325B gespeichert sind. In einer Ausführungsform können die einen oder die mehreren MMU(s) 1320A-1320B mit anderen MMUs innerhalb des Systems synchronisiert werden, einschließlich einer oder mehrerer MMUs, die dem einen oder den mehr Anwendungsprozessor(en) 1205, Bildprozessor 1215 und/oder Videoprozessor 1220 von 12 zugehörig sind, sodass jeder Prozessor 1205-1220 an einem geteilten oder vereinheitlichten virtuellen Speichersystem teilnehmen kann. Die eine oder die mehreren Schaltkreiszwischenverbindung(en) 1330A-1330B ermöglichen Grafikprozessor 1310, sich an andere IP-Kerne innerhalb des SoC entweder über einen internen Bus des SoC oder über eine direkte Verbindung gemäß Ausführungsformen anzuschließen.
14 ist ein Blockdiagramm, das einen zusätzlichen beispielhaften Grafikprozessor 1410 eines Systems-auf-einem-Chip-integrierten Schaltkreises veranschaulicht, das unter Verwendung eines oder mehrerer IP-Kerne gemäß einer Ausführungsform gefertigt werden kann. Grafikprozessor 1410 kann eine Variante des Grafikprozessors 1210 von 12 sein. Grafikprozessor 1410 enthält die eine oder die mehreren MMU(s) 1320A-13020B, Cache(s) 1325A-1325B und Schaltkreiszwischenverbindung(en) 1330A-1330B des integrierten Schaltkreises 1300 von 13.
Grafikprozessor 1410 enthält einen oder mehrere Shaderkern(e) 1415A-1415N (z.B. 1415A, 1415B, 1415C, 1415D, 1415E, 1415F bis 1315N-1 und 1315N), die eine vereinheitlichte Shaderkernarchitektur bereitstellen, in der ein einzelner Kern oder Typ oder Kern alle Typen von programmierbarem Shadercode durchführen kann, einschließlich Shaderprogrammcode, um Vertexshader, Fragmentshader und/oder Rechenshader zu implementieren. Die exakte Zahl an vorliegenden Shaderkernen kann unter Ausführungsformen und Implementierungen variieren. Zusätzlich enthält Grafikprozessor 1410 einen Zwischen-Kernaufgabenverwalter 1405, der als ein Threadversender agiert, um Durchführungsthreads an einen oder mehrere Shaderkern(e) 1415A-1415N zu versenden, und eine Kachelungseinheit 1418, um Kachelungsoperationen für Kachel-basiertes Rendering zu beschleunigen, in dem Rendering-Operationen für eine Szene in Bildraum unterteilt werden, zum Beispiel, um lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder Verwendung interner Caches zu optimieren.
VORRICHTUNG UND VERFAHREN FÜR OPTIMIERTES RAYTRACING
Stream-basiertes Raytracing erfährt oft einen Arbeitsleistungszugewinn, verglichen mit traditionellerem Raytracing. Ein „Stream“ ist ein Satz an Strahlen. In einem heterogenen System möchte man die Ressourcen so gut wie möglich ausnutzen. In einer Ausführungsform, veranschaulicht in 15, werden Hardware-unterstützte Schlangen 1503, 1507 (die in Speicher 1501 zugeteilte Bereiche sein können), um die Verarbeitung von Strahlen voranzutreiben, zwischen zum Beispiel der CPU 1502 und GPU 1512 hinzugefügt, um Strahlverarbeitungseffizienz zu erhöhen.
Die CPU 1502 kann zum Beispiel Auge-Strahl-Streams erzeugen (was ein Auftrag ist) und diese in eine Hardware-unterstütze Schlange 1503 setzen. Die EUs auf der GPU 1512 können dann Aufträge (bestehend aus den Strahl-Streams) aus dieser Schlange 1503 mit einer vernachlässigbaren Strafe stehlen. Das heißt, eine Aufgabe wird auf jeder EU gestartet, die Raytracing ausführen soll, und die EU bleibt dabei, daran zu arbeiten und Aufträge von der Schlange 1503 zu stehlen, bis ein Signal durch die Schlange gesendet wird, dass die EU zu beenden ist. Normalerweise würde man eine Aufgabe für jeden Strahl-Stream starten und das kostet einiges an Mehraufwand.
Ähnlich kann in einer Ausführungsform die GPU 1512 Aufträge zu einer Schlange 1507 hinzufügen, die in die andere Richtung zeigt, d.h. von der GPU 1507 zur CPU 1502. Dies könnte zum Beispiel ein Shading-Auftrag oder sogar ein Raytracing-Auftrag sein. Dieser könnte zum Beispiel in Fällen erledigt werden, wo die GPU 1512 Strahl-Streams nicht schnell genug verarbeiten kann und die CPU 1502 im Ruhezustand ist.
In einer Ausführungsform ist ein Strahl-Stream in der Schlange 1503 von CPU 1502 zu GPU 1512 nur ein Adresshinweis zu der Stelle, wo der Strahl-Stream startet und auch wie groß der Strahl-Stream ist. Ein Auftrag in der anderen Schlange 1507 (von GPU zu CPU) kann allgemeiner sein. Zum Beispiel besteht er in einer Ausführungsform aus einem Adresshinweis zu der Stelle, wo die Daten gelegen sind, einer Größe und einem Typ. Allgemeiner ausgedrückt, beide Schlangen können auf diese Weise konfiguriert werden.
In einer Ausführungsform wird Vorabrufen auf eine neue Weise vorgenommen, um Zugriffe effizienter zu machen. Zunächst mit Fokus auf die Schlange 1503 von der CPU 1502 zur GPU 1512 wird angenommen, dass eine EU genau jetzt Arbeit zu erledigen hat, aber fast bereit ist (etwa sie hat N Strahlen aus M übrig zu verarbeiten, mit denen der Strahl-Stream zu starten hatte).
Zu diesem Punkt könnte die EU die Schlange 1503 anweisen, die Strahlen (oder allgemeiner, die Daten) vorabzurufen, auf die der nächste Auftrag in der Schlange hinweist. Also angenommen, die nächsten Aufträge beinhalten einen Strahl-Stream, mit M Strahlen darin, werden diese Strahlen aus Speicher in die Cachehierarchie abgerufen, wenn die EU die Schlange anweist, dass sie den nächsten Auftrag in der Schlange bearbeiten wird. So sprechen wir von einem Vorabrufen eines Satzes von Daten (z.B. all die Strahlen in einem Strahl-Stream), anstatt von nur Vorabrufen einer Cachezeile.
16 veranschaulicht eine Ausführungsform, in der ein Datenvorabrufschaltkreis 1620 Strahl-Streams und/oder zugehörige Daten von einem Speicher mit hoher Bandbreite 1530 und/oder Systemspeicher 1501 (z.B. DRAM) vorabruft und die vorabgerufenen Daten derart innerhalb der EU Cachehierarchie 1621 speichert, dass sie verfügbar sind, wenn die EUs bereit sind, den nächsten Auftrag zu verarbeiten. Vorabrufen kann von HBM 1630 zu DRAM 1501, oder von HBM 1630 zur Cachehierarchie 1621 und/oder von DRAM 1501 zu Cachehierarche 1621 erledigt werden. Es gibt endlos viele Varianten und dies hängt nur von der Architektur ab. Die Idee ist es, einen Stapel von Daten derart vorabzurufen, dass diese Daten exakt dann verfügbar sind, wenn die EU (in diesem Beispiel) die Daten braucht, d.h. sie hat aufgehört, die verbleibenden N Strahlen im Strahl-Stream zu verarbeiten. Dies wird die Arbeitsleistung signifikant verbessern. Das gesamte System mit Schlangen könnte auch von einem HPC (Hochleistungsrechen- (High Performance Compute)) Kern zu einem anderen HPG-Kern (und zurück) angewendet werden. Um mehr als eine Cachezeile vorabzurufen, kann ein Vorabrufflächenbefehl verwendet werden (d.h. aus einem zugewiesenen Bereich in Speicher vorabzurufen). Wie erwähnt, falls die CPU 1502 verfügbare Ressourcen hat, kann die GPU 1512 auch Shading-Aufträge für die CPU zur Beendigung vorlegen.
VORRICHTUNG UND VERFAHREN ZUM DEKOMPRIMIEREN EINER GRENZVOLUMENHIERARCHIE
Raytracing ist eine wichtige Anwendung, die immer unter Verwendung einer räumlichen Datenstruktur beschleunigt wird, die ein k-d-Baum, eine Grenzvolumenhierarchie (Bounding Volume Hierarchy, BVH), Gitter, Octree usw. sein kann (obwohl die bekanntesten Techniken heutzutage BVHs verwenden). Wenngleich es zum Ausführen von Strahlquerungen wichtig ist, ruft BVH-Knoten Speicherverkehr hervor. Um diesen Speicherverkehr zu reduzieren, ist es üblich, die Knoten der BVH zu komprimieren, typischerweise durch Quantisieren von Koordinaten mehrerer Knoten relativ zu einem gemeinsamen Elternknoten, und dann diese Knoten während Querung fliegend zu dekomprimieren. Während dies Bandbreite sparen kann, können Rechenkosten zur Dekomprimierung der Knoten in Software erheblich sein und die meisten (wenn nicht alle) der Bandbreitenzugewinne zunichtemachen.
In einer Ausführungsform werden besondere Befehle zu einer CPU und/oder den Recheneinheiten in einem Grafikprozessor hinzugefügt, was die Kosten einer Ausführung dieser BVH-Knoten-Dekomprimierung signifikant reduziert. Diese Recheneinheiten von Grafikprozessoren werden hierin als Durchführungseinheiten, oder EUs (Execution Units) bezeichnet. Mit solchen besonderen Befehlen kann die Geschwindigkeit von Strahlquerung durch eine BVH signifikant erhöht werden. Dies ist eine fundamentale Operation, die Millionen oder Milliarden Male pro Frame ausgeführt wird (wobei jede solche Querung hunderte solcher Knoten der BVHs zur Dekomprimierung benötigt). Während der Fokus der vorliegenden Anwendung auf den BVHs liegt, können die offenbarten Befehle potentiell mit anderen Datenstrukturen als der BVH verwendet werden - oder für andere BVH-basierte Algorithmen, wie nächster-Nachbar-Abfragen oder Kollisionserfassung.
Eine Box in einer BVH ist fast immer achsausgerichtet und als solches kann eine Box unter Verwendung von (Xmin, Ymin, Zmin, Xmax, Ymax, Zmax) dargestellt werden, wobei (Xmin, Ymin, Zmin) der minimale Punkt der Box ist und (Xmax, Ymax, Zmax) der maximale Punkt der Box ist.
Im Allgemeinen ist die BVH eine Baumstruktur, die interne Knoten und Blattknoten beinhaltet, wobei jeder Knoten eine Grenzbox wie zuvor beschrieben speichert. Blattknoten beinhalten (beziehen sich auf) geometrische Primitive und haben deren Grenzbox auf eine Box eingestellt, die diese geometrischen Primitive eng umschließt. Interne Knoten beinhalten eine Zahl von Kinderknoten (typischerweise durch einen Adresshinweis oder Liste von Adresshinweisen zu diesen Knoten); deren Grenzbox ist eingestellt (rekursiv) alle Grenzboxen aller Kinderknoten zu umschließen. Querungsalgorithmen - entweder für Raytracing oder ähnliche Techniken, wie Kollisionserfassung, Nächster-Nachbar-Abfragen usw. - verwenden diese hierarchische Baumstruktur, um eine Art von Zweig-und-Grenz-Querungen auszuführen, in denen, in jedem Querungsschritt, ein Abfrageobjekt (ein Strahl, Abfragebox usw.) mit einer Grenzbox eines BVH-Knotens verglichen wird, und entweder den jeweiligen Teilbaum verarbeitet oder entfernt, basierend auf dem Resultat dieses Überlagerungstests. Raytracing benötigt Millionen bis Milliarden von Strahl-BVH-Querungen pro Frame, wobei jeder viel Strahl-Box-Tests benötigt.
Während es beim Entfernen sehr effektiv ist, verursacht ein Zugriff auf hunderte von BVH-Knoten pro Strahl eine signifikante Speicherbandbreite. Um bessere Arbeitsleistung zu erzielen, könnte man die BVH komprimieren, was zuvor von einigen Autoren vorgeschlagen wurde Typischerweise wird diese Komprimierung durch Quantisieren der Koordinaten der Grenzbox relativ zu einer gemeinsamen bekannten Elternbox erledigt (wie die Box des Elternknotens, die Box eines Teilbaums usw.). Zum Beispiel können, vorerst nur unter Betrachtung der X-Dimension (d.h. bei den Xmin- und Xmax-Koordinaten der Box) diese zwei Koordinaten relativ zu ihrem Elternwert (parentMinX, parentMinY, parentMinZ und parentMaxX, parentMaxY, parentMaxZ) komprimiert werden. Da Kinderknoten garantiert vollständig in deren Elternbox eingeschlossen sind, ist es üblich, die Kinderbox relativ zu deren Elternbox auszudrücken.
Der üblichste Weg minX und maxX zu codieren, ist, parentMin zu speichern (oder unter Verwendung von Dekomprimierung zu errechnen) und dann einen Skalenfaktor, scale=(scaleX, scaleY, scaleZ), zu speichern (oder als Teil von Dekomprimierung zu errechnen), wobei der erste Ausdruck errechnet ist als: $scaleX = (parentMaxX - parentMinX) / 2 n,$
und ähnlich für scaleY und scaleZ und wobei n die Zahl von Bits ist, zu denen wir die Kindbox quantisieren. Also angenommen, dass wir parentMin haben und für einen Knoten skalieren, dann speichern wir n Bits für jede Verwendung (Xmin, Ymin, Zmin, Xmax, Ymax, Zmax) dieses Kinds. Ein üblicher Wert für n ist 8, der wesentlich billiger ist als sie jeweils in 32 Bits zu speichern (tatsächlich reichen selbst 4 Bits oft aus). Wir nennen diese quantisierten Werte (QXmin, QYmin, QZmin, QXmax, QYmax, QZmax).
Um Xmin und Xmax zu dekomprimieren, würde man dann errechnen: $Xmin = parentMinX + scaleX*QXmin;$
$Xmax = parentMinX + scaleX* (2 n - QXmax)$
Diese können im Allgemeinen unter Verwendung von Multiplizier-und-Addier-Befehlen (Multiply-and-Add, MAD) implementiert werden, wie: $Xmin = MAD (scaleX, QXmin, parentMinX);$
$Xmax = MAD (scaleX, (2 n - QXmax), parentMinX);$
Zusätzlich werden die quantisierten Werte oft gemeinsam gespeichert, 4 in 32 Bits zum Beispiel, und deshalb muss man oft QXmin errechnen, als:
(T & 0x0000FF00)>>8,
Angenommen, dass vier Werte in T gespeichert werden (32 Bits) und dass QXmin das zweitniedrigste Byte ist, was der Grund für AND (&) 0x0000FF00 ist, ist es dann um 8 Bits nach unten verschoben, um den Wert in den unteren acht Bits zu bekommen.
Eine Ausführungsform der Erfindung enthält besondere Befehle, die den gesamten Prozess des Errechnens (Xmin, Ymin, Zmin, Xmax, Ymax, Zmax) viel schneller machen. Ein Befehl, der als erstes beschrieben ist, kann verwendet werden, um einen min-Wert (z.B. Xmin) oder einen max-Wert (z.B. Xmax) zu dekomprimieren, nicht aber beide zur selben Zeit. Eine Hardware-Einheit zum Ausführen dieser Operationen ist nachstehend in Bezug auf 17 beschrieben.
Es wird angenommen, dass der Befehl die folgende Einstellung hat, wobei in-Parameter ein I an deren Namen angehängt haben und der out-Parameter ein O angehängt hat: DCMP1 resultO, scalel, parentMinl, Qvaluesl, whichl. Man beachte, dass alle Parameter Skalarwerte sind und nachstehend erklärt sind:

resultO: Dies ist das errechnete Ergebnis, das erzeugt wird, wenn dieser Befehl ausgeführt wird. Dies könnte entweder ein min-Wert oder ein max-Wert sein (z.B. Xmin oder Zmax).
scaleI: Dies ist der Skalenwert für die zu dekomprimierende Dimension, also, um in X zu dekomprimieren, ist dieser Parameter auf den scaleX eingestellt usw.
parentMinI: Dies ist der parentMin-Wert für die Dimension, die zu dekomprimieren ist, sodass, um in X diesen Parameter zu dekomprimieren, dieser Parameter auf den parentMinX eingestellt ist, usw.
QvaluesI: Dies können 32 Bits von quantisierten min- und max-Werten sein.
WhichI: Dies sind nur ein paar Bits, die anzeigen, welcher Wert benötigt wird, um aus Qvaluesl zu extrahieren. Es gibt höchstens 6 Werte (min und max in X,Y,Z) und so werden nur drei Bits dafür benötigt.

17 veranschaulicht eine Ausführungsform, die in Hardware implementiert ist (wobei die in-Parameter oben gezeigt werden) und das Ergebnis ganz unten gezeigt wird (entweder ein min- oder ein max-Wert, abhängig von den Parametern. Man beachte, dass wir die Gleichungen von oben implementieren wollen, die hier wiederholt werden: $Xmin = parentMinX + scaleX * QXmin;$
$Xmax = parentMinX + scaleX * (2 n - QXmax)$
Falls whichl anzeigt, dass ein min-Wert zu errechnen ist, wenn die erste Reihe der zwei Gleichungen von zuvor durchgeführt werden sollen, und falls whichl anzeigt, dass ein max-Wert zu errechnen ist, dann wollen wir die zweite Reihe durchführen. Man beachte, dass Qvaluesl die quantisierten Werte beinhaltet und dass whichl anzeigt, welche quantisierten Werte aus Qvaluesl extrahiert werden müssen. Deshalb gibt es eine Verschiebungseinheit 1701, die eine angemessene Menge an Qvaluesl abhängig von whichl verschiebt. Dann werden die n niedrigeren Bits aus der Verschiebungseinheit 1701 verwendet. Falls whichl anzeigt, dass es ein mx-Wert ist, den wir errechnen wollen, dann kehrt die Umkehreinheit 1702 all die Bits um (was äquivalent zu 2n-Qmax ist, aber effizienter), ansonsten werden die Bits lediglich durch die Umkehreinheit 1702 durchgegeben. Als nächstes folgt eine 32 Bits X einer n Bits Multiplikationseinheit 1703. Da n nur 8 Bits sein kann, kann diese Einheit kleiner sein als eine allgemeine 32 x 32 Multiplikationseinheit. Letztlich wird das Ergebnis von der Multiplikation mit dem parentMinl-Wert wie veranschaulicht addiert, was in entweder einem Dekomprimierungs-min-Wert oder einem dekomprimierten max-Wert resultiert.
Eine andere Ausführungsform, veranschaulicht in 18, errechnet sowohl min als auch max gleichzeitig. Diese Ausführungsform enthält zwei Verschiebungseinheiten 1801-1801, die erste 1801, um Q Werte zu verschieben, um N Bits für Q min zu erzeugen, und die zweite 1802, um die Q Werte zu verschieben, um N Bits für Q max zu erzeugen. Umkehreinheit 1702 kehrt die N Bits für Q max wie zuvor beschrieben um, was zu 32 x n Bit Multiplizierer 1804 eingegeben wird, um mit dem scalel-Wert multipliziert zu werden und Erzeugen von SCALE X (2^K- Q_MIN), der zum Eltern-minl-Wert addiert wird, um den MAX-Wert zu erzeugen. Zur selben Zeit multipliziert ein anderer 32 x N Bit Multiplizierer 1803 scalel mit N Bits Q_MIN, die von Verschiebungseinheit 1801 bereitgestellt sind, um ein Ergebnis zu erzeugen, das dann zum parentl-Wert addiert wird, um den MIN-Wert zu erzeugen.
VORRICHTUNG UND VERFAHREN, ENTHALTEND BEFEHLE UND SCHALTUNG FÜR EFFIZIENTES RAYTRACING
Um Raytracing-Effizienz zu verbessern, enthält eine Ausführungsform der Erfindung besondere Befehle, die zum Befehlssatz in einer CPU und/oder in einer GPU hinzugefügt werden (in den EUs zum Beispiel). Dies stellt schnelleres Raytracing im Grafikprozessor (da die EU schneller sein wird) und/oder in der CPU bereit.
In Raytracing gibt es gewisse Operationen, die Milliarden Male für ein einzelnes Bild durchgeführt werden. Wenn eine Grenzvolumenhierarchie verwendet wird (welche die am häufigsten verwendete räumliche Datenstruktur heutzutage ist), ist zum Beispiel eine Kernroutine, die durchgeführt wird, ein Strahl-gegen-Box-Schnittpunkt. Befehle werden nachstehend bereitgestellt, die diese Operation schneller machen. Insbesondere weist eine Ausführungsform kombinierte min-max-Befehle in einer neuartigen Form auf. Zusätzlich wird ein Sammelcache beschrieben, der Daten von individuellen Cachezeilen derart speichert, dass, falls aufeinanderfolgende Sammeladressen in derselben Cachezeile sind, diese lokal verfügbar sein werden.
Eine Operation, die sechs Mal für jeden Strahl-gegen-Box-Schnittpunkttest erledigt wird, ist eine min-max-Operation oder eine max-min-Operation. Zum Beispiel haben manche aktuelle Architekturen VMIN_MAX und VMAX_MIN Befehle, die dies erledigen. Sie können ausgedrückt werden als: $Vmin_max (a,b,c) = min (max (a,b), c)$
$Vmax_min (a,b,c) = max (min (a,b), c)$
Der gesamte Strahl-Box-Schnittpunkt besteht dann aus manchen Errechnungen zuerst, gefolgt von 3 min-max und 3 max-min Operationen. Dies ist eine Verbesserung von 6 min und 6 max Operationen, die ansonsten erledigt werden würden.
Jedoch können diese Errechnungen ausgedrückt werden als: $max4 (tminray, min (x0, x1), min (y0,y1), min2 (z0, z1))$
$min4 (tmaxray, max (x0, x1), max (y0,y1), max (z0, z1))$
In einer Ausführungsform der Erfindung werden die folgenden zwei Varianten implementiert, um die vorherigen zu unterstützen:
Variante 1: In dieser Ausführungsform wird ein separater Befehl für jede dieser Funktionen bereitgestellt. Eine Ausführungsform der Befehle enthält die folgenden: $max4min3 (a, b, c, d, e, f, g) = max4 (a, min (b, c), min (d, e), min2 (f, g))$
$min 4 max 3 (a, b, c, d, e, f, g) = min 4 (a, max (b, c), max (d,e), max (f, g))$
Man beachte, dass der a-Parameter tminray für max4min3 und tmaxray für min4max3 wäre. Ein möglicher Nachteil ist, dass es zu viele Argumente zu diesem Befehl gibt. AVX2 Befehle können jedoch leicht einige SIMD-Register mit je 8 Gleitkommaregistern unterstützen, damit diese unter Verwendung aktueller Architekturen implementiert werden können. Ausführungsformen von Hardware-Implementierungen für die vorherigen Befehle sind in 19 (max4min3) und 20 (min4max3) veranschaulicht.
Insbesondere führen in 19 MIN-Einheiten 1901-1903 die Funktionen min(b,c), min(d,e) und min2(f,g)) aus. MAX4-Einheit 1920 führt dann die Operation max4(a, min(b,c), min(d,e), min2(f,g)) aus, um das Ergebnis zu erzeugen. Ähnlich führen in 20 MIN-Einheiten 2001-2003 die Funktionen max(b,c), max(d,e) und max(f,g) aus. MIN4-Einheit 2020 führt dann die Operation min4(a, max(b,c), max(d,e), max(f,g)) aus.
Variante 2: In dieser Ausführungsform wird ein Mega-Befehl für alles verwendet (da viele Errechnungen geteilt werden können). Eine Ausführungsform nimmt die Form an: $\begin{array}{l} minmax4minmax 3 (a, b, c, d, e, f, g, h) = (max 4 (a, min (b, c), min (d, e), min 2 (f, g), \\ min 4 (h, max (b, c), max (d, e), max (f, g)) \end{array}$
Man beachte, dass der a-Parameter tminray wäre und der h-Parameter in diesem Fall der h-Parameter wäre. Man beachte, dass dies bedeutet, da wir sowohl Gleichung (*) als auch (**) für diese Variante ausführen müssen, dass wir zum Beispiel sowohl min(b,c) als auch max(b,c) errechnen müssen. Dies bedeutet einfach, dass wir b und c so sortieren müssen, dass nach dem Sortieren b <= c ist. Dies kann weit effizienter erledigt werden, als eine min und eine max Auswertung. Ein Vorschlag für eine Hardware-Implementierung dieses Befehls ist in 21 gezeigt.
Insbesondere geben mehrere Sortierungseinheiten 2101-2103 alle MIN-Werte zu der MAX4-Einheit 3110 aus und geben alle MAX-Werte zu der MIN4-Einheit 2111 aus, zwei Ergebnisse erzeugend, von denen nur eines abhängig von der ausgeführten Operation genutzt wird.
Zusätzlich enthält eine Ausführungsform einen Sammelcache, der Daten von individuellen Cachezeilen derart speichert, dass, falls aufeinanderfolgende Sammeladressen in derselben Cachezeile sind, sie lokal verfügbar sein werden.
Die Ausdrücke „Modul“, „Logik“ und „Einheit“, die in der vorliegenden Anmeldung verwendet werden, können sich auf einen Schaltkreis zum Ausführen der spezifizierten Funktion beziehen. In manchen Ausführungsformen kann die spezifizierte Funktion von einem Schaltkreis in Kombination mit Software, wie von Software, die von einem Allzweckprozessor durchgeführt wird, ausgeführt werden.
Ausführungsformen der Erfindung können unterschiedliche Schritte enthalten, die zuvor beschrieben wurden. Diese Schritte können in maschinendurchführbaren Befehlen verkörpert sein, die verwendet werden können, um einen Allzweck- oder Sonderzweckprozessor zu veranlassen, die Schritte auszuführen. Alternativ können diese Schritte durch spezifische Hardwarekomponenten ausgeführt werden, die festverdrahtete Logik zum Ausführen der Schritte beinhalten, oder durch eine Kombination programmierter Computerkomponenten und kundenspezifischer Hardwarekomponenten.
Wie hierin beschrieben, können Befehle sich auf spezifische Konfigurationen von Hardware beziehen, wie anwendungsspezifische integrierte Schaltkreise (Application Specific Integrated Circuits, ASICs), die konfiguriert sind, gewisse Operationen auszuführen oder eine vorbestimmte Funktionalität oder Softwarebefehle, die in Speicher gespeichert sind, der von einem nichttransitorischen computerlesbaren Medium verkörpert wird, aufweisen. Daher können die in den Figuren gezeigten Techniken unter Verwendung von Code und Daten, die auf einem oder mehreren elektronischen Geräten gespeichert sind und ablaufen (z.B. eine Endstation, ein Netzwerkelement usw.) implementiert werden. Solche elektronischen Geräte speichern und kommunizieren (intern und/oder mit anderen elektronischen Geräten über ein Netzwerk) Code und Daten unter Verwendung computermaschinenlesbarer Medien, wie nichttransitorische computermaschinenlesbare Datenspeichermedien (z.B. magnetische Datenträger; optische Datenträger; Direktzugriffspeicher; Nur-LeseSpeicher; Flashspeichergeräte; Phasenwechselspeicher) und transitorische computermaschinenlesbare Kommunikationsmedien (z.B. elektrische, optische, akustische oder andere Form sich ausbreitender Signale - wie Trägerwellen, infrarote Signale, digitale Signale usw.).
Zusätzlich enthalten solche elektronischen Geräte typischerweise einen Satz eines oder mehrerer Prozessoren, die mit einer oder mehreren anderen Komponenten gekoppelt sind, wie einem oder mehreren Datenspeichergeräten (nichttransitorische maschinenlesbare Datenspeichermedien), Anwendereingabe-/ausgabegeräten (z.B. eine Tastatur, einen Berührungsbildschirm und/oder eine Anzeige) und Netzwerkverbindungen. Die Kopplung des Satzes von Prozessoren und anderen Komponenten erfolgt typischerweise durch einen oder mehr Busse und Brücken (auch als Bussteuerungen bezeichnet). Das Datenspeichergerät und Signale, die den Netzwerkverkehr tragen, stellen jeweils ein oder mehrere maschinenlesbare Datenspeichermedien und maschinenlesbare Kommunikationsmedien dar. Daher speichert das Datenspeichergerät eines gegebenen elektronischen Geräts typischerweise Code und/oder Daten zur Durchführung auf dem Satz von einem oder mehreren Prozessoren dieses elektronischen Geräts. Selbstverständlich können ein oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung verschiedener Kombinationen von Software, Firmware und/oder Hardware implementiert werden. Durch diese ausführliche Beschreibung hinweg wurden zum Zweck der Erklärung zahlreiche spezifische Details vorgebracht, um ein gründliches Verständnis der vorliegenden Erfindung bereitzustellen. Es wird Fachleuten jedoch ersichtlich sein, dass die Ausführungsformen der Erfindung ohne manche dieser spezifischen Details umgesetzt werden können. In gewissen Instanzen wurden wohlbekannte Strukturen und Funktionen nicht ausführlich beschrieben, um zu vermeiden, die zugrundeliegenden Prinzipien der Ausführungsformen der Erfindung zu verschleiern. Dementsprechend sollten der Umfang und das Wesen der Erfindung im Sinne der folgenden Ansprüche beurteilt werden.

Claims

Beansprucht wird:
Vorrichtung, aufweisend: einen Allzweckprozessor, um mehrere Strahlströme zu erzeugen; eine erste Hardwareschlange, um die Strahlströme zu empfangen, die durch den Allzweckprozessor erzeugt werden; eine Grafikverarbeitungseinheit (Graphics Processing Unit, GPU), die mehrere Durchführungseinheiten (Execution Units, EUs) aufweist, um die Strahlströme von der ersten Hardwareschlange zu verarbeiten; eine zweite Hardwareschlange, um Grafikverarbeitungsaufträge zu speichern, die von der GPU vorgelegt werden; den Allzweckprozessor, um die Aufträge, die von der GPU vorgelegt werden, zu verarbeiten und Ergebnisse mit der GPU zu teilen.
Vorrichtung nach Anspruch 1, wobei die Grafikverarbeitungsaufträge Schattierungsaufträge und/oder Raytracing-Aufträge aufweisen.
Vorrichtung nach Anspruch 1, wobei Aufgaben auf den EUs gestartet werden, um die Strahlströme zu verarbeiten, bis ein Signal durch die Schlange gesendet wird, dass die EU abzuschließen ist.
Vorrichtung nach Anspruch 1, weiter aufweisend: einen Datenvorabrufschaltkreis, der in der GPU eingebaut ist, um Strahlströme und/oder zugehörige Daten von einem Speicher mit hoher Bandbreite und/oder Systemspeicher vorab abzurufen und die vorab abgerufenen Tagströme innerhalb einer Cachehierarchie der EUs zu speichern.
Vorrichtung nach Anspruch 4, wobei der Datenvorabrufschaltkreis in Antwort auf einen Vorabrufflächenbefehl, der den Datenvorabrufschaltkreis veranlasst, von einem zugewiesenen Bereich im Speicher mit hoher Bandbreite und/oder Systemspeicher vorab abzurufen, vorab abrufen wird, wobei der zugewiesene Bereich größer ist als eine Cachezeile.
Vorrichtung, aufweisend: eine Grafikverarbeitungseinheit oder Allzweckverarbeitungseinheit, mehrere Durchführungseinheiten (EUs) aufweisend; die EUs Dekomprimierungsschaltung aufweisend, um Grenzvolumenhierarchie(Bounding Volume Hierarchy, BVH)-Daten zu dekomprimieren, die Dekomprimierungsschaltung aufweisend: eine Verschiebungseinheit, um eine zugewiesene Menge quantisierter min- und/oder max-Werte in Übereinstimmung mit einem ersten Satz von Bits zu verschieben, die anzeigen, welcher Wert benötigt wird, um aus den min- und/oder max-Werten zu extrahieren, wobei N Bits von der Verschiebungseinheit ausgegeben werden; eine Umkehreinheit, um die N Bits umzukehren, falls der erste Satz von Bits anzeigt, dass ein dekomprimierter max-Wert zu errechnen ist, oder um die N Bits durchzuleiten, falls der erste Satz von Bits anzeigt, dass ein dekomprimierter min-Wert zu errechnen ist; eine Multiplikationseinheit, um die N Bits mit einem Skalenwert zu multiplizieren, um ein Multiplikationsergebnis zu erzeugen; und eine Additionseinheit, um das Multiplikationsergebnis mit einem minimalen Wert zu addieren, der einem Elternknoten in der BVH zugehörig ist, was entweder in einem dekomprimierten min-Wert oder einem dekomprimierten max-Wert resultiert.
Vorrichtung nach Anspruch 6, wobei die Multiplikationseinheit eine 32 Bit x N Bit Multiplikationseinheit aufweist.
Vorrichtung nach Anspruch 7, wobei der minimale Wert, der dem Elternknoten zugehörig ist, einen 32-Bit Wert aufweist.
Vorrichtung nach Anspruch 1, wobei die Dekomprimierungsschaltung BVH-Knoten in Antwort auf einen Dekomprimierungsbefehl dekomprimieren wird.
Vorrichtung nach Anspruch 9, wobei der Dekomprimierungsbefehl einen Ergebnisoperanden, der anzeigt, dass entweder ein min-Wert oder ein max-Wert benötigt wird, einen Skalenwert für das zu dekomprimierende Ausmaß, den minimalen Wert, der dem Elternknoten zugehörig ist, für das zu dekomprimierende Ausmaß, quantisierte min- und/oder max-Werte, und den ersten Satz von Bits, die anzeigen, welcher Wert benötigt wird, um aus den quantisierten min- und/oder max-Werten zu extrahieren, aufweist.
Vorrichtung, aufweisend: eine Grafikverarbeitungseinheit oder Allzweckverarbeitungseinheit, aufweisend mehrere Durchführungseinheiten (EUs); die EUs Strahl-Volumen-Schnittschaltung aufweisend, um zu bestimmen, ob ein Strahl ein Grenzvolumen einer Grenzvolumenhierarchie (BVH) schneidet, die Strahl-Volumen-Schnittschaltung aufweisend: mehrere MIN-Einheiten, wobei jede MIN-Einheit dazu dient, zwei Werte zu empfangen, die eine erste Koordinate und eine zweite Koordinate aufweisen, und den minimalen Wert der ersten und zweiten Koordinaten auszugeben, wobei die ersten und zweiten Koordinaten Koordinaten eines Strahls und/oder Grenzvolumens sind, die auf Schnittpunkt getestet werden; wobei die Ausgänge von jeder der MIN-Einheiten kommunikativ mit einer MAX-Einheit gekoppelt sind, wobei die MAX-Einheit dazu dient, N + 1 Werte zu empfangen, wo N gleich der Zahl von MIN-Einheiten ist, und um ein Maximum der N + 1 Werte auszuwählen und auszugeben.
Vorrichtung nach Anspruch 11, wobei N = 3 ist.
Vorrichtung, aufweisend: eine Grafikverarbeitungseinheit oder Allzweckverarbeitungseinheit, mehrere Durchführungseinheiten (EUs) aufweisend; die EUs aufweisend Strahl-Volumen-Schnittschaltung, um zu bestimmen, ob ein Strahl ein Grenzvolumen einer Grenzvolumenhierarchie (BVH) schneidet, die Strahl-Volumen-Schnittschaltung aufweisend: mehrere MAX-Einheiten, wobei jede MAX-Einheit dazu dient, zwei Werte zu empfangen, die eine erste Koordinate und eine zweite Koordinate aufweisen, und den minimalen Wert der ersten und zweiten Koordinaten auszugeben, wobei die ersten und zweiten Koordinaten Koordinaten von einem Strahl und/oder Grenzvolumen sind, die auf Schnittpunkt getestet werden; wobei die Ausgänge von jeder der MAX-Einheiten kommunikativ mit einer MIN-Einheit gekoppelt sind, wobei die MIN-Einheit dazu dient, N + 1 Werte zu empfangen, wo N gleich der Zahl von MAX-Einheiten ist, und um ein Minimum der N + 1 Werte auszuwählen und auszugeben.
Vorrichtung nach Anspruch 13, wobei N = 3 ist.
Vorrichtung, aufweisend: eine Grafikverarbeitungseinheit oder Allzweckverarbeitungseinheit, mehrere Durchführungseinheiten (EUs) aufweisend; die EUs aufweisend Strahl-Volumen-Schnittschaltung, um zu bestimmen, ob ein Strahl ein Grenzvolumen einer Grenzvolumenhierarchie (BVH) schneidet, die Strahl-Volumen-Schnittschaltung aufweisend: mehrere Sortierungseinheiten, wobei jede Sortierungseinheit dazu dient, zwei Werte zu empfangen, die eine erste Koordinate und eine zweite Koordinate aufweisen, und den minimalen Wert und den maximalen Wert der zwei Werte auszugeben; eine MAX-Einheit, um alle der minimalen Werte, die von den Sortierungseinheiten ausgegebenen werden, und einen ersten zusätzlichen Koordinatenwert zu empfangen, wobei die MAX-Einheit dazu dient, einen maximalen Wert von den minimalen Werten und dem ersten zusätzlichen Koordinatenwert auszuwählen und auszugeben; und eine MIN-Einheit, um alle der maximalen Werte, die von den Sortierungseinheiten ausgegebenen werden, und einen zweiten zusätzlichen Koordinatenwert zu empfangen, wobei die MIN-Einheit dazu dient, einen minimalen Wert von den maximalen Werten und dem zweiten zusätzlichen Koordinatenwert auszuwählen und auszugeben.
Vorrichtung nach Anspruch 15, weiter aufweisend: Auswahllogik, um zwischen dem minimalen Wert, der durch die MIN-Einheit ausgegeben wird, oder dem maximalen Wert, der durch die MAX-Einheit ausgegeben wird, zu wählen.