DE112017001845T5

DE112017001845T5 - Strahltraversierung mit reduzierter Genauigkeit mit Wiederverwendung von Ebenen

Info

Publication number: DE112017001845T5
Application number: DE112017001845.5T
Authority: DE
Inventors: Karthik Vaidyanathan; Marco Salvi
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2016-04-04
Filing date: 2017-01-25
Publication date: 2018-12-20
Also published as: CN108885796B; US20170287203A1; CN108885796A; WO2017176348A1; US9858704B2

Abstract

Es werden ein Verfahren, eines oder mehrere nichtflüchtige computerlesbare Medien und eine Vorrichtung zum Implementieren einer Bounding-Volume-Hierarchy-Strahltraversierung mit reduzierter Genauigkeit zur Grafikverarbeitung offenbart. Das Verfahren beinhaltet den Schritt, in einem Kindknoten eine Berechnung für einen Elterknoten in einer Bounding-Volume-Hierarchy-Strahltraversierung mit reduzierter Genauigkeit zur Grafikverarbeitung wiederzuverwenden. Der Rechenaufwand für die Bounding-Volume-Hierarchy-Strahltraversierung mit reduzierter Genauigkeit kann durch Wiederverwenden der Berechnung für den Elterknoten im Kindknoten reduziert werden.

Description

Allgemeiner Stand der Technik
Eine Bounding Volume Hierarchy (BVH) kann Raytracing-Algorithmen verbessern. Eine BVH ist ein Baum von Bounding Volumes, der Objekte innerhalb einer Szene einschließt. Raytracing generiert Bilder durch Verfolgen von Pfaden von Lichtstrahlen durch eine virtuelle dreidimensionale Umgebung. Anstatt die Strahltraversierung für jedes einer größeren Anzahl von Objekten zu prüfen, kann die Strahltraversierung einfacher für einen Raum („Elterknoten“) in einer BVH geprüft werden, der diese Objekte begrenzt. In diesem Fall können kleinere Bounding Volumes („Geschwisterknoten“) sukzessive auf Strahlschnittpunkte geprüft werden.
In Bounding Volume Hierarchies mit reduzierter Genauigkeit wird ein lokales Gitter mit niedriger Auflösung ausgewählt, so dass der Ursprung des Gitters zu einer Elter-u-Achse ausgerichtet ist, und die Maße des Gitters werden so ausgewählt, dass sie den kleinesten Wert, der eine Zweierpotenz ist, haben und größer als die Maße der Elter-Bounding-Box sind. Die Bounding Box wird durch Berechnen von ganzzahligen Offsets der Koordinaten der Bounding Box im lokalen Gitter quantisiert.
Eine BVH mit Bounding Volumes kann durch Bounding Boxes mit Achsenausrichtung dargestellt werden, die unter Verwendung ihrer Minimalkoordinate p und ihrer Maximalkoordinate q spezifiziert sind, wobei (p, q) ∈ ℝ³. Diese Koordinaten können komprimiert werden, indem sie in ein lokales Gitter mit niedriger Auflösung quantisiert werden, und dekomprimiert werden, wenn die BVH traversiert wird, um Schnittpunkte von Strahl und Szene auszuwerten. Im Folgenden wird auf die Komponenten eines Punktesp als p = (p₀, p₁, p₂) zugegriffen.
Es seien (u^Elter, v^Elter) die entsprechenden Koordinaten der quantisierten Bounding Box. Der nächste Schritt ist, die Kind-Box im Innern des Elter zu codieren. Weil die BVH-Kompression verlustbehaftet ist, können sich die dekomprimierten Koordinaten von den unquantisierten Koordinaten unterscheiden. Das lokale Gitter mit niedriger Auflösung wird so ausgewählt, dass der Ursprung des Gitters zu u^Elter ausgerichtet ist, und die Maße des Gitters werden so ausgewählt, dass sie den kleinesten Wert, der eine Zweierpotenz ist, haben und größer als die Elter-Bounding-Box sind. Die quantisierte Bounding Box wird durch Berechnen der relativen Offsets der Koordinaten der Bounding Box zum Ursprung des Gitters und Quantisieren des Ergebnisses auf eine geringe Bitanzahl N_b abgeleitet. Für eine Achse i werden diese Operationen beschrieben durch: $r_{i} = ⌊ \frac{(p_{i} - u_{i}^{E l t e r})}{2^{e_{i}^{E l t e r}}} 2^{(N_{b})} ⌋, s_{i} = ⌊ \frac{(q_{i} - u_{i}^{E l t e r})}{2^{e_{i}^{E l t e r}}} 2^{(N_{b})} ⌋$
wobei $2^{e_{i}^{E l t e r}}$
das Gittermaß entlang x ist und (r, s) ∈^Z
3 > 0 die quantisierten Offsets relativ zur quantisierten Elter-Bounding-Box sind. Die Verwendung des Floor-Rundungsmodus gewährleistet, dass (r_i, s_i) ∈ [0,2^N
b, -1].Der Exponent $e_{i}^{E l t e r}$
ist gegeben durch: $e_{i}^{E l t e r} = a r g_{k} m i n (2^{k} > (v_{i}^{E l t e r} - u_{i}^{E l t e r}))$
Die Bounding Boxes können aus den quantisierten Koordinaten iterativ dekomprimiert werden, wenn die BVH vom Wurzelknoten traversiert wird, wie in den Gleichungen 3 und 4 beschrieben wird: $u_{i} = u_{i}^{E l t e r} + r_{i} 2^{(e_{i}^{E l t e r} - N_{b})}$
$v_{i} = u_{i}^{E l t e r} + (s_{i} + 1) 2^{(e_{i}^{E l t e r} - N_{b})},$
wobei (u, v) die zerlegten Koordinaten sind, die am Start der Traversierung mit den Koordinaten des Wurzelknotens mit voller Genauigkeit initialisiert werden. Der Wert von s_i wird um eins inkrementiert, was die Minusabweichung kompensiert, die durch die Floor-Operation ganz rechts in der Gleichung 1 eingebracht wird. Dies gewährleistet auch v_i - u_i > 0, was für deterministische Gittermaße erforderlich ist, falls ein Elterknoten aus einem Kindknoten dekomprimiert wird.
Schnittpunkte zwischen Strahlen und der komprimierten BVH können durch Traversieren der BVH, Dekomprimieren des Knotens, der die Boxes umschließt, und Berechnen von Schnittpunkten von Strahl und Bounding Box, die unter Verwendung des Slab-Tests nach Kay und Kajiya ausgewertet werden können, bestimmt werden. Diese Prüfung berechnet drei Distanzintervalle entlang des Strahls zu als Slabs bezeichneten Ebenenpaaren, die Oberflächen der Bounding Box definieren. Der Slab-Test verwendet eine parametrisierte Strahldarstellung o+td, wobei o der Strahlursprung, d die Strahlrichtung und t die parametrische Distanz entlang des Strahls ist. Ein Paar parametrischer Distanzen wird entlang jeder Achse i berechnet: $λ_{i} = (u_{i} - o_{i}) w_{i}$
$μ_{i} = (v_{i} - o_{i}) w_{i}$
wobei $w_{i} = \frac{1}{d}$
die Strahlsteigung ist. Parametrische Distanzen, die den y- und z-Achsen entsprechen, können ähnlich berechnet werden. Unter der Annahme, dass die Steigungen (w_x, w_y, w_z)positiv sind, schneidet ein Strahl die Bounding Box, falls $max (λ^{m a x}, t^{m i n}) \leq min (μ^{m i n} + 2 u l p (μ^{m i n}, t^{m a x})$
wobei λ^max und t^min die Maximal- und Minimalwerte von λ_i bzw. µ_i sind und (t^min, t^max) die Clip-Distanzen des Strahls darstellen. Die Funktion ulp() gibt die Einheit an der letzten Stelle eines Gleitkommawerts mit endlicher Genauigkeit zurück. Durch Hinzufügen dieser Kompensation gewährleistet der Ausdruck u^min korrekte Schnittpunktergebnisse. Falls eine Steigung w_i negativ ist, müssen die entsprechenden Werte von λ_i und µ_i vertauscht werden.
Die Slab-Tests können mit Arithmetik mit reduzierter Genauigkeit durchgeführt werden, falls der Ursprung des Strahls nach jedem Traversierungsschritt näher zur Bounding Box bewegt wird. Dies kann durch Aktualisieren des Ursprungs des Strahls nach jedem Traversierungsschritt erfolgen. Falls der Strahlursprung allerdings modifiziert wird, können die Werte (µ), die für den Elterknoten berechnet worden sind, nicht für die Kindknoten wiederverwendet werden. Daher müssen für ein Paar Geschwisterknoten die Gleichungen 5 und 6 für jede der zwölf Bounding-Ebenen ausgewertet werden, was die Anzahl von Berechnungen verdoppelt.
Figurenliste
Einige Ausführungsformen werden unter Bezugnahme auf die folgenden Figuren beschrieben:

1 ist eine Abbildung eines lokalen Gitters für ein Komprimierungsschema gemäß einer Ausführungsform;
2 ist ein Flussdiagramm für die Codierung der Bounding Volume Hierarchy gemäß einer Ausführungsform;
3 ist ein Flussdiagramm für das Berechnen von Schnittpunkten von Strahl und Bounding Volume Hierarchy gemäß einer Ausführungsform;
4 ist eine Abbildung eines Paars Geschwisterknoten, die zusammen komprimiert und gespeichert werden, gemäß einer Ausführungsform;
5 ist ein Blockdiagramm eines Verarbeitungssystems gemäß einer Ausführungsform;
6 ist ein Blockdiagramm eines Prozessors gemäß einer Ausführungsform;
7 ist ein Blockdiagramm eines Grafikprozessors gemäß einer Ausführungsform;
8 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine gemäß einer Ausführungsform;
9 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors;
10 ist eine Abbildung einer Thread-Ausführungslogik gemäß einer Ausführungsform;
11 ist ein Blockdiagramm eines Grafikprozessor-Anweisungsformats gemäß einigen Ausführungsformen;
12 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors;
13A ist ein Blockdiagramm eines Grafikprozessor-Befehlsformats gemäß einigen Ausführungsformen;
13B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlsfolge gemäß einigen Ausführungsformen veranschaulicht;
14 ist eine Abbildung einer beispielhaften Grafik-Software-Architektur gemäß einigen Ausführungsformen;
15 ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem gemäß einigen Ausführungsformen veranschaulicht;
16 ist ein Blockdiagramm, das eine beispielhafte integrierte System-on-Chip-Schaltung gemäß einigen Ausführungsformen zeigt;
17 ist ein Blockdiagramm eines Grafikprozessors in einem System-on-Chip gemäß einer Ausführungsform; und
18 ist ein Blockdiagramm eines anderen Grafikprozessors gemäß einer Ausführungsform.

Ausführliche Beschreibung
Bounding Volume Hierarchies (BVH) mit reduzierter Genauigkeit und Strahltraversierung ermöglichen in einigen Ausführungsformen Hochleistungs-Echtzeit-Raytracing durch kostengünstige Hardware mit fester Funktion. Der Rechenaufwand der Strahltraversierung kann durch Wiederverwenden der Berechnungen der Strahl-Box-Schnittpunkte für die sechs Bounding-Ebenen, die von einem Elter-BVH-Knoten und seinen beiden Kindern gemeinsam genutzt werden, reduziert werden. Leider ist diese Wiederverwendung mit den vorherigen Traversierungsverfahren mit reduzierter Genauigkeit nicht möglich.
Korrekte Schnittpunkte (d. h. ohne Sprünge) in den Strahltraversierungsalgorithmen sind insbesondere bei der Strahltraversierung mit reduzierter Genauigkeit wichtig, bei der die numerischen Abweichungen größer sein können, was zu fehlenden Schnittpunkten führt. Ein Traversierungsalgorithmus mit reduzierter Genauigkeit ermöglicht in einigen Ausführungsformen die Wiederverwendung von Berechnungen für Bounding-Ebenen, die von einem Elterknoten und seinen Kindern gemeinsam genutzt werden, und gewährleistet korrekte Schnittpunkte.
Die Bounding Boxes eines Geschwisterknotenpaares nutzen sechs Bounding-Ebenen (Koordinaten) gemeinsam mit dem Elterknoten. Indem dies wirksam eingesetzt wird, können die Begrenzungen (in einem Binärbaum) für ein Geschwisterknotenpaar zusammen mit sechs quantisierten Offsets und einem Paar 3-Bit-Masken (l, m), die dem linken oder rechten Geschwister Koordinaten zuordnen, gespeichert werden. Unter der Annahme eines tiefenorientierten Layouts für einen Binärbaum wird ein Bit gespeichert, um einen internen oder Blattknoten, sechs komprimierte Koordinaten für das Geschwisterknotenpaar, ein Paar 3-Bit-Masken und einen N_p-Bit-Index zum rechten Kinderpaar anzugeben, wie in der Tabelle 1 gezeigt wird. Falls der Index des rechten Kinderpaars sich auf den Elterknoten bezieht, dann ist dieser Index immer gerade, und das niederwertigste Bit des Index kann entfallen. Falls daher N_p die Anzahl an Bits ist, die für den Kindindex verwendet werden, kann eine einzelne BVH Z^N
p+1 - 1 Knoten enthalten. Unter der Annahme von N_b = 6 und N_p = 21 sind nur 8 Bytes erforderlich, um ein Paar Knoten zu speichern.

Feld Bitanzahl

Blattknoten-Indikator 1

(l, m) 6

(r, s) N_b × 6

Index zum rechten Kinderpaar N_p
Indem die Dekomprimierung der Bounding Box mit der Traversierung kombiniert wird, kann ein Traversierungsalgorithmus mit reduzierter Genauigkeit Berechnungen für Ebenen, die mit dem Elterknoten gemeinsam genutzt werden, wiederverwenden. Dieses kombinierte Traversierungsverfahren akkumuliert die parametrischen Distanzen iterativ in Bezug auf den Elterknoten: $λ_{i} = λ_{i}^{E l t e r} + w_{i} r_{i} 2^{(e_{i}^{E l t e r} - N_{b})}$
$μ_{i} = λ_{i}^{E l t e r} + w_{i} s_{i} 2^{(e_{i}^{E l t e r} - N_{b})}$
Weil r_i ein Ausdruck mit reduzierter Genauigkeit ist, können die Multiplikationsoperationen in den Gleichungen 8 und 9 mit reduzierter Genauigkeit berechnet werden. Die Genauigkeit der Steigung s_i kann um eine geringe Menge reduziert werden, um die arithmetische Komplexität weiter zu senken. Das BVH-Quantisierungsschema kann modifiziert werden, um korrekte Schnittpunkte zu ermöglichen.
Mit diesem Traversierungsalgorithmus sind die dekomprimierten Bounding Boxes nicht mehr verfügbar. Daher kann der Exponent e^Elter nicht direkt berechnet werden. Ein kostengünstiges Verfahren zum Berechnen von Exponenten vermeidet das Dekomprimieren der Bounding Boxes.
Mit jedem Traversierungsschritt können numerische Abweichungen durch Gleitkomma-Arithmetik mit endlicher Genauigkeit eingebracht werden, was für die parametrischen Distanzen eine untere Begrenzung λ^untere, µ^untere) und eine obere Begrenzung (λ^obere, µ^obere ) ergibt. Unter der Annahme, dass die Steigung w_i positiv ist, ist eine notwendige und ausreichende Bedingung für korrekte Schnittpunkte, dass für jede Achse i, $λ_{i}^{o b e r e} \leq λ_{i}$
und µ^untere ≥ µ_i.Die obere Begrenzung für λ_i nach dem ersten Traversierungsschritt kann anhand der Gleichung 9 hergeleitet werden: $λ_{i}^{o b e r e} = (λ_{i}^{E l t e r} + w_{i} r_{i}^{o b e r e} 2^{(e_{i} E l t e r - N_{b})} {(1 + ε)}^{2}) (1 + ε),$
wobei ε die Maschinengenauigkeit der zugrundeliegenden Gleitkomma-Darstellung ist und Abweichungen durch die Berechnung der Steigung w_i, der inneren Multiplikation und der äußeren Addition eingebracht werden. Der Wert von $r_{i}^{o b e r e}$
kann anhand des Ausdrucks ganz links in der Gleichung 1 hergleitet werden: $r_{i}^{o b e r e} = (p_{i} - u_{i}^{u n t e r e} 2^{(N_{b} - e_{i}^{E l t e r})}$
Rückwärts von der Gleichung 12 ist der erste Schritt oder das erste Kriterium hin zu korrekten Schnittpunkten, durch Modifizieren der Gleichung 3 sicherzustellen, dass $μ_{i}^{u n t e r e} \geq u_{i},$
wie im Block 16 gezeigt wird: $u_{i} = R U (u_{i}^{E l t e r} + r_{i} 2^{(e_{i}^{E l t e r} - N_{b})}$
wobei RU() das Ergebnis der Gleitkomma-Operationen auf den oberen Wert rundet, wie im IEEE-Standard für Gleitkomma-Arithmetik (IEEE 754) spezifiziert ist. Mit Strahltraversierung mit fester Funktion kann die Gleitkomma-Hardware für diesen Rundungsmodus statisch konfiguriert werden. Als Nächstes wird $r_{i}^{o b e r e}$
so ausgeführt, dass es kleiner oder gleich r_i, indem die Gleichung 1 modifiziert wird: $r_{i} = ⌊ R L (p_{i} - u_{i}^{E l t e r}) 2^{(N_{b} - e_{i}^{E l t e r})} ⌋$
wobei RL() das Ergebnis der Gleitkomma-Operationen auf den unteren Wert rundet, wie im IEEE-Standard 754 spezifiziert ist. Schließlich wird $λ_{i}^{o b e r e}$
so ausgeführt, dass es kleiner oder gleich λ_i, indem die Gleichung 8 modifiziert wird: $λ_{i} = R L (λ_{i}^{W u r z e l} + R L (w_{i} r_{i}) 2^{(e_{i}^{E l t e r} - N_{b})})$
wobei die Steigung w_i ebenfalls auf den unteren Wert gerundet wird. Daher wird die erste Vorgabe für korrekte Schnittpunkte erfüllt.
Obwohl positive Abweichungen im Wert von λ_i eliminiert werden, können negative Abweichungen weiter vorhanden sein. Außerdem werden diese negativen Abweichungen mit jedem Traversierungsschritt akkumuliert. Weil der Offset für µ_i in Bezug auf $λ_{i}^{E l t e r}$
hergeleitet wird, werden Abweichungen in λ leider mit den Abweichungen in u_i gekoppelt. Daher würden die akkumulierten negativen Abweichungen in λ_i den Wert von $μ_{i}^{u n t e r e}$
herabsetzen, was eine zweite Vorgabe für die Korrektheit verletzt. Um diese Abweichung u_i zu kompensieren, müsste ein akkumulierter Korrekturausdruck angewendet werden, was zusätzliche arithmetische Komplexität einbringt.
Allerdings können λ_i und u_i unter Verwendung einer alternativen Komprimierung entkoppelt werden, wobei die Offsets für q_i in Bezug auf $v_{i}^{E l t e r}$
hergeleitet werden, wie in der 1 gezeigt wird. Die negativen numerischen Abweichungen in µ_i können dann unabhängig eliminiert werden, ähnlich wie die positiven Abweichungen in λ_i. Der Algorithmus 1 beschreibt den Komprimierungsteil, und der Algorithmus 2 beschreibt den Traversierungsteil dieser Technik für korrekte Traversierung. Die parametrischen Distanzen werden dann verglichen, um Strahl-Box-Schnittpunkte für die Geschwisterknoten zu bestimmen, wie in der Gleichung 7 beschrieben wird.
Die in der 2 gezeigte Folge kann in Software, Firmware und/oder Hardware implementiert werden. In Software- und Firmware-Ausführungsformen kann sie durch vom Computer ausgeführte Anweisungen implementiert werden, die in einem oder mehreren nichtflüchtigen computerlesbaren Medien gespeichert sind, wie zum Beispiel magnetische, optische oder Halbleiter-Speicher. Diese Speicher können in einer Ausführungsform Teil einer Grafikverarbeitungseinheit sein oder in einer anderen Ausführungsform außerhalb der Grafikverarbeitungseinheit liegen. Andere Ausführungsformen werden ebenfalls in Betracht gezogen.
Die in der 2 gezeigte Folge 10 beginnt mit dem Aufbau einer Beschleunigungsstruktur, die auf der Eingangsgeometrie basiert, die aus einem Satz Primitive zusammengesetzt ist, typischerweise Dreiecke, wie im Block 12 angegeben ist. Die Bounding Volume Hierarchy beginnt mit einem Wurzelknoten und endet mit einem Blattknoten. Jeder Wurzelknoten wird in ein Paar Kind- oder Geschwisterknoten unterteilt, und jeder dieser Knoten wird wieder und wieder herunter bis zum Blattknoten unterteilt. Für jedes Paar Kindknoten gibt es einen Satz Minimalkoordinaten p in drei Dimensionen und einen Satz von Maximalkoordinaten q in drei Dimensionen. Jede Dimension wird als eine Ebene betrachtet.
Für die Knotenminimalkoordinaten wird, wie in 14 angegeben ist, eine Folge, die sich aus den Blöcken 16 bis 20 zusammensetzt, implementiert. Die Koordinaten der Kindknoten, die sich von den Koordinaten ihrer Elterknoten unterscheiden, werden im Block 16 bestimmt. Dann wird im Block 18 für jede dieser Koordinaten die Differenz zu ihren Elterknoten berechnet. Bemerkenswerterweise wird diese Differenz durch Decodieren der Elterknotenkoordinaten bestimmt. Schließlich wird die Differenz zwischen den decodierten Elterknotenkoordinaten und den Kindknotenkoordinaten quantisiert, wie im Block 20 angegeben ist.
In einer Ausführungsform werden nur die Differenzen für Koordinaten, die sich unterscheiden, gespeichert. Für die Koordinaten, die die gleichen wie die Elterknotenkoordinaten sind, wird eine Bitmaske identifiziert, die sich auf die Elterkoordinateninformationen bezieht, so dass die Kindkoordinaten, die die gleichen wie die Elterkoordinaten sind, für die Kindknoten nicht erneut gespeichert werden müssen.
Somit werden die Minimalkoordinaten des Kindknotens in Bezug auf die Minimalkoordinaten des Elter codiert, und die Maximalkoordinaten des Kindknotens werden in Bezug auf die Maximalkoordinaten des Elter codiert. Dies ergibt korrekte Schnittpunkte. Die Verwendung der dekomprimierten Koordinaten des Elter zum Berechnen der Offsets für die Kindkoordinate führt zu einer engeren Begrenzung, weil die Abweichungen, die in den Elterknoten eingebracht werden, kompensiert werden, während der Kindknoten codiert wird. Ein anderer Weg, um engere Begrenzungen zu erreichen, ist es, die Offsets für das Kind in Bezug auf die ursprünglichen Koordinaten des Elterknotens zu berechnen.
Wie im Block 22 angegeben wird, wird dann die Folge der Blöcke 16, 18 und 20 für die Maximalkoordinaten wiederholt. Am Ende werden nur die Koordinaten, die sich unterscheiden, zusammen mit einer Bitmaske gespeichert, die für die Kindkoordinaten, die die gleichen wie die Elterkoordinaten sind, identifiziert, wo für den Kindknoten die Koordinateninformationen aus dem Elterknoten wiederverwendet werden sollen. Der nachstehend dargelegte Pseudocode 1 kann für die Komprimierung der Bounding Volume Hierarchy verwendet werden.
In jeder Stufe beim Heruntergehen durch den Baum vom Wurzelknoten zum Blattknoten haben die Ebenen der Kindknoten entweder die gleiche Größe wie die Ebenen der Elterknoten oder sie sind kleiner als diese. Somit wachsen die Bounding Boxes nicht. Durch das Quantisieren der Bounding Volume Hierarchy, wenn sie in Bezug auf den Elter herunterläuft, tendieren also die Differenzen dazu, klein zu sein, und daher kann der Umfang der Daten, die gespeichert werden, reduziert werden.
Für die Minimalkoordinaten wird eine Differenz r berechnet, und für die Maximalkoordinaten wird eine Differenz s berechnet. Falls die Koordinaten des Kindes sich von den Koordinaten des Elter unterscheiden, dann wird eine Variable l_i gleich eins gesetzt, und andernfalls wird l_i null gesetzt, was angibt, wie die Informationen gespeichert werden. Am Ende werden die Koordinaten u, v des Kindes berechnet.
Die r- und s-Differenzen werden durch Abrunden (RL) berechnet. Die Kindkoordinate u wird durch Addieren einer Elterkoordinate zu r-mal einem Faktor und Aufrunden (RU) berechnet. Die Kindkoordinate v wird durch Abrunden (RL) der Differenz zwischen der Elterknotenkoordinate und s-mal einem Faktor berechnet. Die Bitanzahl wird als N_b im nachstehend dagelegten Pseudocode 1 angegeben. Somit müssen in einigen Ausführungsformen, obwohl es zwölf Koordinaten für die Minimal- und Maximalkoordinaten gibt, tatsächlich nur sechs gespeichert werden.
Der nachstehend dargelegte Pseudocode 1 zeigt eine Bounding-Box-Komprimierung für ein Paar Geschwisterknoten mit entkoppelten Minimal- und Maximalkoordinaten. Die Bounding-Box-Koordinaten, die nicht gemeinsam mit der Elter-Box genutzt werden, werden durch ein Paar von drei Bitmasken angegeben:
Eine in der 3 gezeigte Folge 30 zum Durchführen von Tests auf Schnittpunkte von Strahl und Primitiven kann in Software, Firmware und/oder Hardware implementiert werden. In Software- und Firmware-Ausführungsformen kann sie durch vom Computer ausgeführte Anweisungen implementiert werden, die in einem oder mehreren nichtflüchtigen computerlesbaren Medien gespeichert sind, wie zum Beispiel magnetische, optische oder Halbleiter-Speicher. Zum Beispiel kann die Folge in einer Grafikverarbeitungseinheit oder ohne, nämlich in einem externen Speicher, gespeichert werden. Andere Ausführungsformen werden ebenfalls in Betracht gezogen.
Die Folge 30 der Bounding-Volume-Traversierung beginnt durch Bestimmen, wo ein Strahl in eine Bounding Box eintritt, unter Verwendung von r_i, um λ_i zu ermitteln, wie im Block 32 angegeben ist. Dann bestimmt der Fluss, wo der Strahl aus der Bounding Box austritt, unter Verwendung von s_i, um µ_i zu ermitteln, wie im Block 34 angegeben ist.
Im Block 36 werden µ_i, λ_i verglichen, um einen Schnittpunkt von Strahl und Bounding Box zu bestimmen, indem die Strahlsteigung und λ_i und die Strahlsteigung und µ unter Verwendung von Multiplikation mit reduzierter Genauigkeit multipliziert werden.
Der Test auf Schnittpunkte von Strahl und Primitiven verwendet die oben beschriebenen Distanzen r und s in Verbindung mit dem Pseudocode 1 wieder. Diese Wiederverwendung der Distanzen vom Strahlursprung zu jeder Ebene aus Minimal- und Maximalkoordinaten ist eine Form der Wiederverwendung der Ebenen, die die Berechnungen in einigen Ausführungsformen wesentlich reduziert. Die Werte r und s werden in Verbindung mit der Bounding-Volume-Codierung gespeichert, und sie werden in einer Ausführungsform in der Bounding Volume Hierarchy selbst gespeichert, so dass auf sie während des Schnittpunkttests zugegriffen werden kann.
Durch die Verwendung von Bounding Volume Hierarchies für Schnittpunkte von Strahl und Primitiven kann der Test effizienter durchgeführt werden, weil es möglich ist, bestimmte Primitive auszusondern, die niemals von einem Strahl geschnitten werden. Die Traversierung startet an der Wurzel der Bounding Volume Hierarchy und startet mit dem Schneiden eines Strahls mit der Bounding Box der Wurzel. Falls kein Schnittpunkt vorhanden ist, dann stoppt die Traversierung, weil kein Schnittpunkt vorhanden sein kann. Falls die Wurzel geschnitten wird, dann geht der Test weiter zu jedem der Kindknoten. Die Traversierung stoppt an jedem Kindknoten, den ein Strahl nicht schneidet, und fährt nur fort, um die Hierarchie über einen Kindknoten herunterzulaufen, der einen Strahlschnittpunkt aufweist. Schließlich wird der Blattknoten geschnitten, und der Blattknoten entspricht der Primitiven selbst.
Indem die Ausdrücke der Kind-Bounding-Boxes relativ zu den Elter-Bounding-Boxes berechnet werden, können in einigen Ausführungsformen deutliche Einsparungen hinsichtlich der Speicherbandbreite erreicht werden. Durch Wiederverwenden der Werte r und s aus der Codierungsverarbeitung können in einigen Ausführungsformen zusätzliche Einsparungen gemacht werden.
Außerdem wird jeder folgende Knoten inkrementell getestet, wenn der Fluss den Baum herunterläuft. Berechnungen werden nur für Ebenen vorgenommen, die nicht mit Elterebenen gemeinsam genutzt werden, und für Ebenen, die nicht gemeinsam genutzt werden, nur bestimmte Ausdrücke werden unter Verwendung der Offsets r und s berechnet, wie bereits beschrieben worden ist.
In einer herkömmlichen Traversierung weist ein Strahl einen Ursprung und eine Richtung auf. Die Distanzen zu den sechs Ebenen werden berechnet, wie sie durch die Koordinaten der Bounding Boxes definiert sind. Dann werden diese Distanzen verwendet, um zu bestimmen, ob der Strahl die Box schneidet.
Im nachstehenden Pseudocode 2 sind λ und µ die Distanzen vom Ursprung zu jeder der sechs Ebenen. Anstatt absolute Distanzen zu berechnen, werden die Maximaldistanzen zu den Minimalkoordinaten berechnet, um drei Distanzen zu ermitteln. Dies sind die Distanzen, bei denen der Strahl in die Bounding Box eintritt. Dann werden die Minimaldistanzen zu den Maximalkoordinaten berechnet, um drei Distanzen zu ermitteln, diese Distanzen sind die Distanzen, an denen der Strahl aus der Box austritt. Dann werden die Eintritts- und Austrittsdistanzen verglichen, um zu bestimmen, ob irgendein Schnittpunkt auftritt. Falls eine Distanz, an der der Strahl in die Box eintritt, kleiner als eine Distanz ist, an der der Strahl aus der Box austritt, dann schneidet der Strahl die Bounding Box, und andernfalls gibt es keinen Schnittpunkt.
Die Distanzen können genauso berechnet werden, wie die Offsets oben berechnet worden sind, nämlich unter Verwendung der exakt gleichen Werte r und s, die im Pseudocode 1 verwendet werden. Indem die Distanzen relativ zur Elter-Bounding-Box berechnet werden, können kleinere Distanzen ermittelt werden, was die Verwendung von Multiplikation mit reduzierter Genauigkeit ermöglicht. Dann können λ und µ unter Verwendung der bereits berechneten r- und s-Offset-Werte berechnet werden. Als ein Ergebnis können die Werte unter Verwendung von Multiplikation mit reduzierter Genauigkeit mit der Steigung w_i des Strahls multipliziert werden.
Der nachstehend dargelegte Pseudocode 2 zeigt korrekte Traversierung für ein Paar Geschwisterknoten. Falls die Steigung w_i des Strahls negativ ist, werden die Minimal- und Maximalkoordinaten vertauscht. Es werden sechs parametrische Distanzen berechnet und dann dem linken oder rechten Kind zugeordnet, abhängig von der Maske (l, m):
Das Gittermaß d_i entlang der Achse i kann durch Berechnen der Distanz d_i zwischen den dekomprimierten Minimal- und Maximalkoordinaten im lokalen Gitter bestimmt werden. Weil die dekomprimierten Koordinaten quantisiert sind, kann d_i eine nicht vorzeichenbehaftete N_B-Bit Gleitkommazahl sein. Bei jedem Traversierungsschritt kann der Wert von d_i iterativ aus seinem vorherigen Wert $d_{i}^{E l t e r} :$
hergeleitet werden: $d_{i} = d_{i}^{E l t e r} - (r_{i} - s_{i}) e_{i}^{E l t e r}$
Der Exponent von d_i ergibt den neuen Gitterexponenten, d. h. e_i = exponent(d_i). Der Anfangswert des Gittermaßes d^Wurzel und die quantisierten Koordinaten der Wurzel-Bounding-Box können während der BVH-Komprimierung vorberechnet werden.
Um Bounding-Ebenen und Traversierungsberechnungen durch einen Elterknoten und seine Kinder gemeinsam zu nutzen, kann die BVH in einer topologischen Reihenfolge traversiert werden, d. h. ein Elterknoten kann vor seinen Kindern traversiert werden. Typischerweise würde solch eine Traversierung einen Stack erfordern, wobei jeder Stack-Eintrag den Traversierungszustand für den Elterknoten speichern würde, was die Werte von λ, µ, e und d ebenso wie den Index des fernen Kindes einschließen würde, wie in der 4 gezeigt wird. Die Werte von λ und µ mit voller Genauigkeit zu speichern, erhöht erheblich die Größe eines Stack-Eintrags im Vergleich zu einer nicht komprimierten BVH, bei der nur der Index des Kindknotens gespeichert werden muss.
Für jeden Strahl-BVH-Schnittpunkt werden die Werte der parametrischen Distanzen (λ^Wurzel, µ^Wurzel) initialisiert, indem ein Schnittpunkttest mit voller Genauigkeit mit der quantisierten Wurzel-Bounding-Box durchgeführt wird. Die anfänglichen parametrischen Distanzen und die Strahlsteigung werden in einer Ausführungsform nur einmal pro Strahl berechnet und können daher im Shader vor dem Aufruf der Traversierung auf Hardware-Basis ausgewertet werden. Die berechneten Strahlsteigungen können auch für korrekte Strahl-Dreieck-Schnittpunkte verwendet werden.
Falls eine Komponente der Strahlrichtung d_i entlang einer Achse i null ist, dann werden die entsprechenden Werte von (λ_i µ_i) zu ±∞ ausgewertet und können daher nicht inkrementell hergeleitet werden. In solch einem Szenario wird die Achse i als eine degenerierte Achse gekennzeichnet, und anstatt die Werte von (λ_i, µ_i) inkrementell zu berechnen, wird der Offset der Ebenenkoordinaten relativ zum Strahlursprung (µ_i - o_i, v_i - o_i) inkrementell berechnet. Das ist äquivalent zum inkrementellen Berechnen des Wertes von (λ_i, µ_i mit einer Steigung w_i = 1Sobald diese Koordinaten-Offsets hergleitet worden sind, können sie direkt mit dem Strahlursprung verglichen werden, um die Werte von (λ_i, µ_i) herzuleiten:
5 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. In verschiedenen Ausführungsformen enthält das System 100 einen oder mehrere Prozessoren 102 und einen oder mehrere Grafikprozessoren 108 auf und kann ein Einzelprozessor-Desktopsystem, ein Mehrprozessor-Arbeitsstationssystem oder ein Serversystem mit einer großen Anzahl von Prozessoren 102 oder Prozessorkernen 107 sein. In einer Ausführungsform ist das System 100 eine integrierte System-on-Chip- (SoC-) Schaltung zur Verwendung in mobilen, handgehaltenen oder eingebetteten Vorrichtungen.
Eine Ausführungsform des Systems 100 kann eine serverbasierte Spiele-Plattform, eine Spielkonsole, einschließlich einer Spiel- und Medienkonsole, eine mobile Spielkonsole, eine tragbare Spielkonsole oder eine Online-Spielkonsole enthalten oder darin integriert sein. In einigen Ausführungsformen ist das System 100 ein Mobiltelefon, ein Smartphone, eine Tablet-Rechenvorrichtung oder eine mobile Internetvorrichtung. Das Datenverarbeitungssystem 100 kann auch eine tragbare Vorrichtung, wie zum Beispiel eine tragbare intelligente Uhrenvorrichtung, eine intelligente Brillenvorrichtung, eine Vorrichtung für eine erweiterte Realität oder eine Vorrichtung für eine virtuelle Realität enthalten, mit dieser gekoppelt sein oder in diese integriert sein. Bei einigen Ausführungsformen ist das Datenverarbeitungssystem 100 ein Fernseher oder eine Set-Top-Box-Vorrichtung mit einer oder mehreren Prozessoren 102 und einer grafischen Schnittstelle, die durch einen oder mehrere Grafikprozessoren 108 erzeugt wird.
In einigen Ausführungsformen enthält der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 zum Verarbeiten von Anweisungen, die, wenn sie ausgeführt werden, Operationen für System und Benutzer-Software durchführen. In einigen Ausführungsformen ist jeder des einen oder der mehreren Prozessorkerne 107 dazu konfiguriert, einen spezifischen Anweisungssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Anweisungssatz 109 eine Datenverarbeitung mit komplexem Anweisungssatz (CISC, Complex Instruction Set Computing), eine Datenverarbeitung mit reduziertem Anweisungssatz (RISC, Reduced Instruction Set Computing) oder eine Datenverarbeitung mit sehr langem Anweisungswort (VLIW, Very Long Instruction Word) ermöglichen. Mehrere Prozessorkerne 107 können jeweils einen anderen Anweisungssatz 109 verarbeiten, der Anweisungen zum Ermöglichen der Emulation anderer Anweisungssätze enthalten kann. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen enthalten, wie zum Beispiel einen Digitalsignalprozessor (DSP).
Bei einigen Ausführungsformen enthält der Prozessor 102 einen Cache-Speicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Ebenen von internem Cache aufweisen. Bei einigen Ausführungsformen wird der Cache-Speicher durch verschiedene Komponenten des Prozessors 102 gemeinsam genutzt. Bei einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z. B. einen Ebene-3(L3)-Cache oder einen Cache der letzten Ebene (LLC)) (nicht dargestellt), der durch Prozessorkerne 107, die bekannte Cache-Kohärenztechniken verwenden, gemeinsam genutzt wird. Eine Registerdatei 106 ist zusätzlich im Prozessor 102 enthalten, die unterschiedliche Arten von Registern zum Speichern unterschiedlicher Arten von Daten (z. B. Ganzzahlregister, Gleitkommaregister, Zustandsregister und ein Anweisungszeigerregister) umfassen kann. Einige Register können Universalregister sein, während andere Register für den Entwurf des Prozessors 102 spezifisch sein können.
Bei einigen Ausführungsformen ist der Prozessor 102 mit einem Prozessorbus 110 zum Übertragen von Kommunikationssignalen, wie zum Beispiel Adress-, Daten- oder Steuersignalen, zwischen dem Prozessor 102 und anderen Komponenten im System 100 gekoppelt. In einer Ausführungsform verwendet das System 100 eine beispielhafte „Hub“-Systemarchitektur, einschließlich eines Speicher-Controller-Hubs 116 und eines Eingabe-/Ausgabe(E/A)-Controller-Hubs 130. Ein Speicher-Controller-Hub 116 ermöglicht die Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der E/A-Controller-Hub (ICH, I/O Controller Hub) 130 Verbindungen zu E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt. In einer Ausführungsform ist die Logik des Speicher-Controller-Hubs 116 in den Prozessor integriert.
Die Speichervorrichtung 120 kann eine dynamische Direktzugriffsspeicher(DRAM)-Vorrichtung, eine statische Direktzugriffsspeicher(SRAM)-Vorrichtung, eine Flash-Speichervorrichtung, eine Phasenwechsel-Speichervorrichtung oder eine andere Speichervorrichtung sein, die eine geeignete Leistungsfähigkeit aufweist, um als ein Prozessspeicher zu dienen. In einer Ausführungsform kann die Speichervorrichtung 120 als Systemspeicher für das System 100 betrieben werden, um Daten 122 und Anweisungen 121 zu speichern, die verwendet werden, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder eine Verarbeitung ausführen. Der Speicher-Controller-Hub 116 ist auch mit einem optionalen externen Grafikprozessor 112 gekoppelt, der mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen.
In einigen Ausführungsformen aktiviert der ICH 130 Peripheriegeräte, um die Speichervorrichtung 120 und den Prozessor 102 über einen Hochgeschwindigkeits-E/A-Bus zu verbinden. Die E/A-Peripherievorrichtungen enthalten unter anderem einen Audiocontroller 146, eine Firmware-Schnittstelle 128, einen drahtlosen Sendeempfänger 126 (z. B. WLAN, Bluetooth), eine Datenspeicherungsvorrichtung 124 (z. B. Festplattenlaufwerk, Flash-Speicher usw.) und einen Legacy-E/A-Controller 140 zum Koppeln von Legacy-Vorrichtungen (z. B. Personal System 2 (PS/2)) mit dem System. Einer oder mehrere USB(Universal Serial Bus)-Controller 142 verbinden Eingangsvorrichtungen, wie zum Beispiel Kombinationen von Tastatur und Maus 144. Ein Netzwerk-Controller 134 kann auch mit dem ICH 130 koppeln. Bei einigen Ausführungsformen koppelt ein Hochleistungsnetzwerk-Controller (nicht dargestellt) mit dem Prozessorbus 110. Es versteht sich, dass das dargestellte System 100 beispielhaft und nicht einschränkend ist, da andere Arten von Datenverarbeitungssystemen, die anders konfiguriert sind, ebenfalls verwendet werden können. Zum Beispiel kann der E/A-Controller-Hub 130 in den einen oder die mehreren Prozessoren 102 integriert sein, oder der Speicher-Controller-Hub 116 und der E/A-Controller-Hub 130 können in einen diskreten externen Grafikprozessor, wie zum Beispiel den externen Grafikprozessor 112, integriert sein.
6 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200, der einen oder mehrere Prozessorkerne 202A - 202N, einen integrierten Speicher-Controller 214 und einen integrierten Grafikprozessor 208 aufweist. Die Elemente aus der 6, die die gleichen Bezugsnummern (oder Bezeichnungen) wie die Elemente einer beliebigen anderen Figur aufweisen, können auf eine beliebige Art und Weise, die der hier an anderer Stelle beschriebenen ähnelt, arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Der Prozessor 200 kann zusätzliche Kerne bis zu und einschließlich des zusätzlichen Kerns 202N enthalten, der durch die gestrichelten Kästchen dargestellt ist. Jeder der Prozessorkerne 202A - 202N enthält eine oder mehrere interne Cache-Einheiten 204A - 204N. In einigen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf eine oder mehrere gemeinsam genutzte Cache-Einheiten 206.
Die internen Cache-Einheiten 204A - 204N und die gemeinsam genutzten Cache-Einheiten 206 stellen eine Cache-Speicherhierarchie innerhalb des Prozessors 200 dar. Die Cache-Speicherhierarchie kann mindestens eine Ebene von Anweisungs- und Daten-Cache innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen von gemeinsam genutztem Cache einer mittleren Ebene enthalten, wie zum Beispiel eine Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder andere Cache-Ebenen, wobei die höchste Cache-Ebene vor dem externen Speicher als der LLC eingestuft ist. In einigen Ausführungsformen hält die Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A - 204N aufrecht.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von einer oder mehreren Bus-Controller-Einheiten 216 und einen Systemagentenkern 210 enthalten. Die eine oder die mehreren Bus-Controller-Einheiten 216 managen einen Satz von peripheren Bussen, wie zum Beispiel einen oder mehrere Peripheriekomponentenverbindungsbusse (z. B. PCI, PCI Express). Der Systemagentenkern 210 stellt eine Management-Funktionalität für die verschiedenen Prozessorkomponenten bereit. In einigen Ausführungsformen enthält der Systemagentenkern 210 eine oder mehrere integrierte Speicher-Controller 214 zum Managen des Zugriffs auf verschiedene externe Speichervorrichtungen (nicht dargestellt).
In einigen Ausführungsformen enthalten einer oder mehrere der Prozessorkerne 202A - 202N eine Unterstützung für simultanes Multithreading. In einer solchen Ausführungsform enthält der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A - 202N während der Multithread-Verarbeitung auf. Der Systemagentenkern 210 kann zusätzlich eine Leistungssteuereinheit (PCU, Power Control Unit) enthalten, die Logik und Komponenten zum Regeln des Leistungszustands der Prozessorkerne 202A - 202N und des Grafikprozessors 208 aufweist.
In einigen Ausführungsformen enthält der Prozessor 200 zusätzlich einen Grafikprozessor 208 zum Ausführen von Grafikverarbeitungsoperationen. In einigen Ausführungsformen koppelt der Grafikprozessor 208 mit dem Satz von gemeinsam genutzten Cache-Einheiten 206 und dem Systemagentenkern 210, einschließlich dem einen oder den mehreren integrierten Speicher-Controllern 214. In einigen Ausführungsformen ist ein Anzeige-Controller 211 mit dem Grafikprozessor 208 gekoppelt, um eine Grafikprozessorausgabe zu einer oder mehreren gekoppelten Anzeigen anzusteuern. In einigen Ausführungsformen kann der Anzeige-Controller 211 ein separates Modul sein, das über mindestens eine Verbindung mit dem Grafikprozessor gekoppelt ist, oder im Grafikprozessor 208 oder dem Systemagentenkern 210 integriert sein.
In einigen Ausführungsformen wird eine ringbasierte Verbindungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Jedoch kann eine alternative Verbindungseinheit verwendet werden, wie zum Beispiel eine Punkt-zu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Techniken, einschließlich Techniken, die im Fachgebiet gut bekannt sind. In einigen Ausführungsformen verkoppelt der Grafikprozessor 208 über eine E/A-Verknüpfung 213 mit der Ringverbindung 212.
Der beispielhafte E/A-Verknüpfung 213 stellt mindestens eine von mehreren Varianten von E/A-Verbindungen dar, einschließlich einer Package-E/A-Verbindung, die die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsspeichermodul 218, wie zum Beispiel einem eDRAM-Modul, ermöglicht. In einigen Ausführungsformen verwendet jeder der Prozessorkerne 202A - 202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als einen gemeinsam genutzten Last-Level-Cache.
In einigen Ausführungsformen sind die Prozessorkerne 202A - 202N homogene Kerne, die die gleiche Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A - 202N hinsichtlich der Anweisungssatzarchitektur (ISA, Instruction Set Architecture) heterogen, wobei ein oder mehrere Prozessorkerne 202A - 202N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A - 202N in Bezug auf die Mikroarchitektur heterogen, wobei einer oder mehrere Kerne mit einem relativ höheren Leistungsverbrauch mit einem oder mehreren Leistungskernen mit einem niedrigeren Leistungsverbrauch gekoppelt sind. Außerdem kann der Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte SoC-Schaltung mit den veranschaulichten Komponenten zusätzlich zu anderen Komponenten implementiert sein.
7 ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit sein kann, oder der ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen integriert ist. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die in den Prozessorspeicher platziert werden. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Speicherschnittstelle 314, um auf Speicher zuzugreifen. Die Speicherschnittstelle 314 kann eine Schnittstelle zu lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam genutzten externen Caches und/oder Systemspeicher sein.
In einigen Ausführungsformen enthält der Grafikprozessor 300 auch einen Anzeige-Controller 302 auf, um Anzeigeausgabedaten zu einer Anzeigevorrichtung 320 zu lenken. Der Anzeige-Controller 302 enthält Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Zusammensetzung mehrerer Schichten von Video- oder Benutzerschnittstellenelementen. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Video-Codec-Engine 306 zum Codieren, Decodieren oder Umcodieren von Medien zu, von oder zwischen einem oder mehreren Mediencodierungsformaten, einschließlich, jedoch nicht beschränkt auf Moving Picture Experts Group (MPEG)-Formate, wie zum Beispiel MPEG-2, auf Advanced Video Coding (AVC)-Formate, wie zum Beispiel H.264/MPEG-4 AVC sowie die Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und die Joint Photographic Experts Group (JPEG)-Formate, wie zum Beispiel JPEG- und Motion JPEG (MJPEG)-Formate.
In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Blockbildübertragungs (BLIT, Block Image Transfer)-Engine 304, um zweidimensionale (2D) Rasterisierer-Operationen, einschließlich zum Beispiel Bit-Boundary Block Transfers durchzuführen. In einer Ausführungsform werden jedoch 2D-Grafikoperationen unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE, Graphics Processing Engine) 310 durchgeführt. In einigen Ausführungsformen ist die GPE 310 eine Rechen-Engine zum Durchführen von Grafikoperationen, einschließlich dreidimensionaler (3D-) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen enthält die GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen, wie zum Beispiel für das Rendering von dreidimensionalen Bildern und Szenen, unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen (z. B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 312 enthält programmierbare und feste Funktionselemente, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungs-Threads zu einem 3D-/Medien-Teilsystem 315 erzeugen. Während die 3D-Pipeline 312 zum Durchführen von Medienoperationen verwendet werden kann, enthält eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316, die speziell zum Durchführen von Medienoperationen, wie zum Beispiel Videonachbearbeitung und Bildverbesserung, verwendet wird.
In einigen Ausführungsformen enthält die Medien-Pipeline 316 Logikeinheiten mit fester Funktion oder programmierbare Logikeinheiten, um eine oder mehrere spezialisierte Medienoperationen durchzuführen, wie zum Beispiel Videodecodierungsbeschleunigung, Video-Deinterlacing und Videocodierungsbeschleunigung, anstelle von oder im Auftrag der Video-Codec-Engine 306. In einigen Ausführungsformen enthält die Medien-Pipeline 316 zusätzlich eine Thread-Erzeugungseinheit, um Threads zur Ausführung auf dem 3D-/Medien-Teilsystem 315 zu erzeugen. Die erzeugten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die im 3D-/Medien-Teilsystem 315 enthalten sind.
In einigen Ausführungsformen enthält das 3D/Medien-Teilsystem 315 Logik zum Ausführen von Threads, die von der 3D-Pipeline 312 und der Medien-Pipeline 316 erzeugt wurden. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanfragen an das 3D-/Medien-Teilsystem 315, das eine Thread-Dispatch-Logik zum Vermitteln und Senden der verschiedenen Anfragen an verfügbare Thread-Ausführungsressourcen enthält. Die Ausführungsressourcen enthalten ein Array aus Grafikausführungseinheiten zum Verarbeiten der 3D- und Medien-Threads. In einigen Ausführungsformen enthält das 3D-/Medien-Teilsystem 315 einen oder mehrere interne Caches für Thread-Anweisungen und Daten. In einigen Ausführungsformen enthält das Teilsystem auch gemeinsam genutzten Speicher, einschließlich Registern und adressierbarem Speicher, um Daten zwischen Threads gemeinsam zu nutzen und Ausgabedaten zu speichern.
8 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors gemäß einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungs-Engine (GPE) 410 eine Version der in 7 dargestellten GPE 310. Elemente aus der 8, die die gleichen Bezugsnummern (oder Bezeichnungen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf beliebige ähnliche Weise wie hierin an anderer Stelle beschrieben betrieben werden oder funktionieren, sind jedoch nicht darauf beschränkt. Zum Beispiel werden die 3D-Pipeline 312 und die Medien-Pipeline 316 aus 7 veranschaulicht. Die Medien-Pipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und möglicherweise nicht explizit 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 einigen Ausführungsformen verkoppelt die GPE 410 mit einem Befehls-Streamer 403, der einen Befehlsstrom an die 3D-Pipeline 312 und/oder die Medien-Pipelines 316 bereitstellt, oder enthält diesen. In einigen Ausführungsformen ist der Befehls-Streamer 403 mit einem Speicher gekoppelt, der ein Systemspeicher oder einer oder mehrere interne Cache-Speicher und gemeinsam genutzter Cache-Speicher sein kann. In einigen Ausführungsformen empfängt der Befehls-Streamer 403 Befehle aus dem Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medien-Pipeline 316. Die Befehle sind Direktiven, die aus einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 312 und die Medien-Pipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Batch-Befehlspuffer enthalten, die Batches mehrerer Befehle speichern. Die Befehle für die 3D-Pipeline 312 können auch Verweise auf Daten enthalten, die im Speicher gespeichert sind, wie zum Beispiel, jedoch nicht darauf beschränkt, Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 312 und die Medien-Pipeline 316 verarbeiten die Befehle und Daten, indem sie Operationen über Logik innerhalb der jeweiligen Pipelines durchführen oder indem sie einen oder mehrere Ausführungs-Threads an ein Grafikkern-Array 414 senden.
In verschiedenen Ausführungsformen kann die 3D-Pipeline 312 eines oder mehrere Shader-Programme ausführen, wie zum Beispiel Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Compute-Shader oder andere Shader-Programme, indem sie die Anweisungen verarbeitet und Ausführungs-Threads an das Grafikkern-Array 414 sendet. Das Grafikkern-Array 414 stellt einen vereinheitlichten Block von Ausführungsressourcen bereit. Eine Mehrzweck-Ausführungslogik (z. B. Ausführungseinheiten) innerhalb des Grafikkern-Arrays 414 unterstützt verschiedene 3D-API-Shader-Sprachen und kann mehrere simultane Ausführungs-Threads ausführen, die mehreren Shadern zugeordnet sind.
In einigen Ausführungsformen enthält das Grafikkern-Array 414 auch Ausführungslogik zum Durchführen von Medienfunktionen, wie zum Beispiel Video- und/oder Bildverarbeitung. In einer Ausführungsform enthalten die Ausführungseinheiten zusätzlich Universallogik auf, die dazu programmierbar ist, parallele Universal-Rechenoperationen zusätzlich zu Grafikverarbeitungsoperationen durchzuführen. Die Universallogik kann Verarbeitungsoperationen parallel oder in Verbindung mit Universallogik innerhalb des/der Prozessorkern(e) 107 aus 5 oder des Kerns 202A - 202N wie in der 6 durchführen.
Ausgabedaten, die von Threads generiert werden, die auf dem Grafikkern-Array 414 ausgeführt werden, können Daten in einem vereinheitlichten Rückgabepuffer (Unified Return Buffer - URB) 418 an den Speicher ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen verschiedenen Threads zu senden, die auf dem Grafikkern-Array 414 ausgeführt werden. In einigen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisation zwischen Threads auf dem Grafikkern-Array und der festen Funktionslogik innerhalb der Logik der gemeinsam genutzten Funktion 420 verwendet werden.
In einigen Ausführungsformen ist das Grafikkern-Array 414 skalierbar, so dass das Array eine variable Anzahl von Grafikkernen mit jeweils einer variablen Anzahl von Ausführungseinheiten enthält, basierend auf der Zielleistung und dem Leistungsniveau der GPE 410. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, so dass Ausführungsressourcen je nach Bedarf aktiviert oder deaktiviert werden können.
Das Grafikkern-Array 414 ist mit Logik 420 für eine gemeinsam genutzte Funktion gekoppelt, die mehrere Ressourcen enthält, die von den Grafikkernen im Grafikkern-Array gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen in der Logik 420 für gemeinsam genutzte Funktionen sind Hardware-Logikeinheiten, die dem Grafikkern-Array 414 spezialisierte Zusatzfunktionen bereitstellen. In verschiedenen Ausführungsformen enthält die gemeinsam genutzte Funktionslogik 420 den Sampler 421, die Math-Einheit 422 und die Inter-Thread-Kommunikations (ITC) -Logik 423, ist jedoch nicht darauf beschränkt. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Cache-Speicher 425 in der Logik 420 für gemeinsam genutzte Funktionen. Eine gemeinsam genutzte Funktion wird implementiert, wenn die Nachfrage nach einer gegebenen spezialisierten Funktion nicht ausreicht, um in das Grafikkern-Array 414 aufgenommen zu werden. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eine eigenständige Entität in der gemeinsam genutzten Funktionslogik 420 implementiert und von den Ausführungsressourcen innerhalb des Grafikkern-Arrays 414 gemeinsam genutzt. Der genaue Satz von Funktionen, die vom Grafikkern-Array 414 gemeinsam genutzt werden und im Grafikkern-Array 414 enthalten sind, variiert zwischen den Ausführungsformen.
9 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 500. Elemente aus der 9, die die gleichen Bezugsnummern (oder Bezeichnungen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf beliebige ähnliche Weise wie hierin an anderer Stelle beschrieben betrieben werden oder funktionieren, sind jedoch nicht darauf beschränkt.
In einigen Ausführungsformen enthält der Grafikprozessor 500 eine Ringverbindung 502, ein Pipeline-Frontend 504, eine Medien-Engine 537 und Grafikkerne 580A - 580N. In einigen Ausführungsformen koppelt die Ringverbindung 502 den Grafikprozessor mit anderen Verarbeitungseinheiten, einschließlich anderen Grafikprozessoren oder einem oder mehreren Universalprozessorkernen. In einigen Ausführungsformen ist der Grafikprozessor einer von vielen Prozessoren, die in einem Multi-Kern-Verarbeitungssystem integriert sind.
In einigen Ausführungsformen empfängt der Grafikprozessor 500 Befehls-Batches über die Ringverbindung 502. Die eingehenden Befehle werden von einem Befehls-Streamer 503 im Pipeline-Frontend 504 interpretiert. In einigen Ausführungsformen enthält der Grafikprozessor 500 eine skalierbare Ausführungslogik zum Durchführen einer 3D-Geometrieverarbeitung und Medienverarbeitung über den/die Grafikkern(e) 580A - 580N auf. Für 3D-Geometrie-Verarbeitungsbefehle führt der Befehls-Streamer 503 der Geometrie-Pipeline 536 Befehle zu. Für mindestens einige Medienverarbeitungsbefehle führt der Befehls-Streamer 503 einem Video-Frontend 534, das mit einer Medien-Engine 537 gekoppelt ist, Befehle zu. In einigen Ausführungsformen enthält die Medien-Engine 537 eine Videoqualitäts-Engine (VQE) 530 zur Video- und Bildnachverarbeitung und eine Multiformat-Codier-/Decodier-Engine (MFX) 533, um eine hardwarebeschleunigte Mediendatencodierung und -decodierung bereitzustellen. In einigen Ausführungsformen generieren die Geometrie-Pipeline 536 und die Medien-Engine 537 jeweils Ausführungs-Threads für die Thread-Ausführungsressourcen, die von mindestens einem Grafikkern 580A bereitgestellt werden.
In einigen Ausführungsformen enthält der Grafikprozessor 500 skalierbare Thread-Ausführungsressourcen mit modularen Kernen 580A - 580N (manchmal als Kern-Slices bezeichnet) mit jeweils mehreren Teilkerne 550A - 550N, 560A - 560N (manchmal als Kern-Teil-Slices bezeichnet). In einigen Ausführungsformen kann der Grafikprozessor 500 eine beliebige Anzahl von Grafikkernen 580A bis 580N aufweisen. In einigen Ausführungsformen enthält der Grafikprozessor 500 einen Grafikkern 580A mit mindestens einem ersten Teilkern 550A und einem zweiten Teilkern 560A. In anderen Ausführungsformen ist der Grafikprozessor ein Prozessor mit geringer Leistung mit einem einzigen Teilkern (z. B. 550A). In einigen Ausführungsformen enthält der Grafikprozessor 500 mehrere Grafikkerne 580A - 580N, die jeweils einen Satz erster Teilkerne 550A - 550N und einen Satz zweiter Teilkerne 560A - 560N aufweisen. Jeder Teilkern im Satz von ersten Teilkernen 550A - 550N enthält mindestens einen ersten Satz von Ausführungseinheiten 552A - 552N und Medien-/Textur-Samplern 554A - 554N. Jeder Teilkern im Satz von zweiten Teilkernen 560A - 560N enthält mindestens einen zweiten Satz von Ausführungseinheiten 562A - 562N und Samplern 564A - 564N. In einigen Ausführungsformen nutzt jeder Teilkern 550A - 550N, 560A - 560N einen Satz von gemeinsam genutzten Ressourcen 570A - 570N gemeinsam. In einigen Ausführungsformen enthalten die gemeinsam genutzten Ressourcen einen gemeinsam genutzten Cache-Speicher und eine Pixeloperationslogik. Andere gemeinsam genutzte Ressourcen können ebenfalls in den verschiedenen Ausführungsformen des Grafikprozessors enthalten sein.
10 veranschaulicht eine Thread-Ausführungslogik 600, die ein Array aus Verarbeitungselementen enthält, die in einigen Ausführungsformen einer GPE verwendet werden. Elemente aus der 10, die die gleichen Bezugsnummern (oder Bezeichnungen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf beliebige ähnliche Weise wie hierin an anderer Stelle beschrieben betrieben werden oder funktionieren, sind jedoch nicht darauf beschränkt.
In einigen Ausführungsformen enthält die Thread-Ausführungslogik 600 einen Shader-Prozessor 602, einen Thread-Dispatcher 604, einen Anweisungs-Cache 606, ein skalierbares Ausführungseinheiten-Array mit mehreren Ausführungseinheiten 608A - 608N, einen Sampler 610, einen Daten-Cache 612 und einen Datenanschluss 614. In einer Ausführungsform kann das skalierbare Ausführungseinheiten-Array dynamisch skalieren, indem eine oder mehrere Ausführungseinheiten (z. B. beliebige der Ausführungseinheiten 608A, 608B, 608C, 608D bis 608N-1 und 608N) basierend auf den Berechnungsanforderungen einer Arbeitslast aktiviert oder deaktiviert werden. In einer Ausführungsform sind die enthaltenen Komponenten über eine Verbindungsstruktur miteinander verbunden, die mit jeder der Komponenten verknüpft. In einigen Ausführungsformen enthält die Thread-Ausführungslogik 600 eine oder mehrere Verbindungen zum Speicher, wie zum Beispiel dem Systemspeicher oder Cache-Speicher, über einen oder mehrere von Anweisungs-Cache 606, Datenanschluss 614, Sampler 610 und Ausführungseinheiten 608A - 608N. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 608A) eine selbständige programmierbare Universalrecheneinheit, die in der Lage ist, mehrere gleichzeitige Hardware-Threads auszuführen, während sie mehrere Datenelemente parallel für jeden Thread verarbeitet. In verschiedenen Ausführungsformen kann das Array aus Ausführungseinheiten 608A - 608N skalierbar sein, so dass es eine beliebige Anzahl einzelner Ausführungseinheiten enthält.
In einigen Ausführungsformen werden die Ausführungseinheiten 608A - 608N hauptsächlich zum Ausführen von Shader-Programmen verwendet. Ein Shader-Prozessor 602 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads senden, die den Shader-Programmen über einen Thread-Dispatcher 604 zugeordnet sind. In einer Ausführungsform enthält der Thread-Dispatcher Logik, um Thread-Initiierungsanfragen aus den Grafik- und Medien-Pipelines zu arbitrieren und die angeforderten Threads auf einer oder mehreren Ausführungseinheiten 608A - 608N zu instanziieren. Zum Beispiel kann die Geometrie-Pipeline (z. B. 536 aus der 9) Vertex-, Tessellations- oder Geometrie-Shaders an die Thread-Ausführungslogik 600 (10) senden. In einigen Ausführungsformen kann der Thread-Dispatcher 604 auch Laufzeit-Thread-Erzeugungsanfragen von den ausführenden Shader-Programmen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A - 608N einen Anweisungssatz, der native Unterstützung für viele Standard-3D-Grafik-Shader-Anweisungen beinhaltet, so dass Shader-Programme aus Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertex-Programme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z. B. Pixel-Shader, Fragment-Shader) und Universalverarbeitung (z. B. Rechen- und Medien-Shader). Jede der Ausführungseinheiten 608A - 608N ist zu einer Single Instruction, Multiple Data (SIMD) -Ausführung mit Mehrfachausgabe in der Lage, und eine Multithread-Operation ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit weist eine dedizierte Registerdatei mit hoher Bandbreite und einen zugeordneten unabhängigen Thread-Zustand auf. Die Ausführung erfolgt als Mehrfach-Ausgabe pro Takt an Pipelines mit Gleitkomma-Operationen mit ganzzahliger, einfacher und doppelter Genauigkeit, SIMD-Verzweigungskapazität, logischen Operationen, transzendenten Operationen und anderen sonstigen Operationen. Während auf Daten aus dem Speicher oder einer der gemeinsam genutzten Funktionen gewartet wird, bewirkt die Abhängigkeitslogik innerhalb der Ausführungseinheiten 608A - 608N, dass ein wartender Thread in den Ruhezustand geht, bis die angeforderten Daten zurückgegeben worden sind. Während der wartende Thread im Ruhezustand ist, können sich Hardware-Ressourcen der Verarbeitung anderer Threads widmen. Zum Beispiel kann während einer Verzögerung, die einer Vertex-Shader-Operation zugeordnet ist, eine Ausführungseinheit Operationen für einen Pixel-Shader, Fragment-Shader oder einen anderen Typ von Shader-Programm durchführen, einschließlich eines anderen Vertex-Shaders.
Jede Ausführungseinheit in den Ausführungseinheiten 608A - 608N arbeitet auf Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ oder die Anzahl der Kanäle für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für den Datenelementzugriff, die Maskierung und die Flusssteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann unabhängig von der Anzahl der physischen arithmetischen Logikeinheiten (ALUs, Arithmetic Logic Units) oder der Gleitkommaeinheiten (FPUs, Floating Point Units) für einen bestimmten Grafikprozessor sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A - 608N Ganzzahl- und Gleitkomma-Datentypen.
Der Ausführungseinheit-Anweisungssatz enthält SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert werden und die Ausführungseinheit wird die verschiedenen Elemente basierend auf der Datengröße der Elemente verarbeiten. Wenn zum Beispiel auf einem 256 Bit breiten Vektor gearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert, und die Ausführungseinheit arbeitet auf dem Vektor als vier separate gepackte 64-Bit-Datenelemente (Datenelemente der Größe Vierfachwort (QW, Quad-Word)), als acht separate gepackte 32-Bit-Datenelemente (Datenelemente der Größe Doppelwort (DW)), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente der Größe Wort (W)) oder zweiunddreißig separate gepackte 8-Bit-Datenelemente (Datenelemente der Größe Byte (B)). Es sind jedoch andere Vektorbreiten und Registergrößen möglich.
Einer oder mehrere interne Anweisungs-Caches (z. B. 606) sind in der Thread-Ausführungslogik 600 enthalten, um Thread-Anweisungen für die Ausführungseinheiten zu cachen. In einigen Ausführungsformen sind ein oder mehrere Daten-Caches (z. B. 612) enthalten, um Thread-Daten während der Thread-Ausführung zu cachen. In einigen Ausführungsformen ist ein Sampler 610 enthalten, um eine Texturabtastung für 3D-Operationen und Medienabtastung für Medienoperationen bereitzustellen. In einigen Ausführungsformen enthält der Sampler 610 eine spezielle Textur- oder Medienabtastungsfunktionalität, um Textur- oder Mediendaten während des Abtastprozesses zu verarbeiten, bevor die abgetasteten Daten einer Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und Medien-Pipelines Thread-Initiierungsanfragen über die Thread-Erzeugungs- und Dispatch-Logik an die Thread-Ausführungslogik 600. Sobald eine Gruppe geometrischer Objekte verarbeitet und zu Pixeldaten rasterisiert worden ist, wird die Pixelprozessorlogik (z. B. die Pixel-Shader-Logik, die Fragment-Shader-Logik usw.) im Shader-Prozessor 602 aufgerufen, um die Ausgabeinformationen weiter zu berechnen und zu bewirken, dass Ergebnisse auf Ausgabeflächen geschrieben werden (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.). In einigen Ausführungsformen berechnen ein Pixel-Shader oder ein Fragment-Shader die Werte der verschiedenen Vertex-Attribute, die über das rasterisierte Objekt zu interpolieren sind. In einigen Ausführungsformen führt die Pixel-Prozessorlogik im Shader-Prozessor 602 dann ein von einer Anwendungsprogrammierschnittstelle (API) zugeführtes Pixel- oder Fragment-Shader-Programm aus. Um das Shader-Programm auszuführen, sendet der Shader-Prozessor 602 Threads über den Thread-Dispatcher 604 an eine Ausführungseinheit (z. B. 608A). In einigen Ausführungsformen verwendet der Pixel-Shader 602 eine Texturabtastlogik im Sampler 610, um auf Texturdaten in im Speicher gespeicherten Texturabbildungen zuzugreifen. Arithmetische Operationen an den Texturdaten und den Eingabegeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder sondern eines oder mehrere Pixel von der weiteren Verarbeitung aus.
In einigen Ausführungsformen stellt der Datenanschluss 614 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 600 bereit, um verarbeitete Daten an den Speicher zur Verarbeitung auf einer Grafikprozessorausgabe-Pipeline auszugeben. In einigen Ausführungsformen enthält der Datenanschluss 614 einen oder mehrere Cache-Speicher (z. B. den Daten-Cache 612) oder ist damit gekoppelt, um Daten für einen Speicherzugriff über den Datenanschluss zu cachen.
11 ist ein Blockdiagramm, das ein Grafikprozessor-Anweisungsformat 700 gemäß einigen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die Kästchen in durchgezogenen Linien veranschaulichen die Komponenten, die im Allgemeinen in einer Ausführungseinheitsanweisung enthalten sind, während die gestrichelten Linien Komponenten umfassen, die optional sind oder die nur in einem Teilsatz der Anweisungen enthalten sind. In einigen Ausführungsformen ist das beschriebene und veranschaulichte Anweisungsformat 700 insofern Makroanweisungen, dass sie Anweisungen sind, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die sich aus der Anweisungsdecodierung ergeben, sobald die Anweisung verarbeitet wird.
In einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten Anweisungen nativ in einem 128-Bit-Anweisungsformat 710. Ein verdichtetes 64-Bit-Anweisungsformat 730 ist für einige Anweisungen auf Basis der ausgewählten Anweisung, den Anweisungsoptionen und der Anzahl der Operanden verfügbar. Das native 128-Bit-Anweisungsformat 710 bietet Zugriff auf alle Anweisungsoptionen, während einige Optionen und Operationen im 64-Bit-Format 730 eingeschränkt sind. Die nativen Anweisungen, die im 64-Bit-Format 730 verfügbar sind, variieren je nach Ausführungsform. In einigen Ausführungsformen wird die Anweisung teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 verdichtet. Die Ausführungseinheit-Hardware referenziert einen Satz von Kompaktierungstabellen auf Basis der Indexwerte und verwendet die Kompaktierungstabellenausgaben, um eine native Anweisung im 128-Bit-Anweisungsformat 710 zu rekonstruieren.
Für jedes Format definiert der Anweisungs-Opcode 712 die Operation, die die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden aus. Zum Beispiel führt die Ausführungseinheit als Reaktion auf eine Addieranweisung eine gleichzeitige Addieroperation über jeden Farbkanal durch, der ein Texturelement oder Bildelement darstellt. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden durch. In einigen Ausführungsformen ermöglicht das Anweisungsteuerungsfeld 714 das Steuern über bestimmte Ausführungsoptionen, wie zum Beispiel die Kanalauswahl (z. B. Prädikation) und die Datenkanalreihenfolge (z. B. Swizzle). Für Anweisungen im 128-Bit-Anweisungsformat 710 begrenzt ein Ausführungsgrößenfeld 716 die Anzahl der Datenkanäle, die parallel ausgeführt werden. In einigen Ausführungsformen ist das Ausführungsgrößenfeld 716 nicht zur Verwendung im kompakten 64-Bit-Anweisungsformat 730 verfügbar.
Einige Ausführungseinheitsanweisungen weisen bis zu drei Operanden auf, einschließlich zwei Quellenoperanden, src0 720, src1 722, und einem Ziel 718. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Doppelzielanweisungen, wobei eines der Ziele implizit ist. Datenmanipulationsanweisungen können einen dritten Quellenoperanden aufweisen (z. B. SRC2 724), wobei der Anweisungs-Opcode 712 die Anzahl der Quellenoperanden bestimmt. Der letzte Quellenoperand einer Anweisung kann ein unmittelbarer (z. B. fest codierter) Wert sein, der mit der Anweisung weitergegeben wird.
In einigen Ausführungsformen beinhaltet das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodus-Feld 726, das zum Beispiel angibt, ob der direkte Registeradressierungsmodus oder der indirekte Registeradressierungsmodus verwendet wird. Wenn der direkte Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
In einigen Ausführungsformen beinhaltet das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung spezifiziert. In einer Ausführungsform wird der Zugriffsmodus zum Definieren einer Datenzugriffsausrichtung für die Anweisung verwendet. Einige Ausführungsformen unterstützen Zugriffsmodi, einschließlich eines 16-Byte-ausgerichteten Zugriffsmodus und eines 1-Byte-ausgerichteten Zugriffsmodus, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Zum Beispiel kann die Anweisung, wenn sie sich in einem ersten Modus befindet, eine Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und wenn sie sich in einem zweiten Modus befindet, kann die Anweisung eine 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressmodusabschnitt des Zugriffs-/Adressmodusfeldes 726, ob die Anweisung eine direkte oder eine indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, stellen die Bits in der Anweisung direkt die Registeradresse eines oder mehrerer Operanden ein. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem unmittelbaren Adressfeld in der Anweisung berechnet werden.
In einigen Ausführungsformen werden Anweisungen basierend auf Bitfeldern von Opcode 712 gruppiert, um die Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit-Opcode ermöglichen die Bits 4, 5 und 6 der Ausführungseinheit, den Opcode-Typ zu bestimmen. Die dargestellte genaue Opcode-Gruppierung ist lediglich ein Beispiel. In einigen Ausführungsformen beinhaltet eine Bewegungs- und Logik-Opcode-Gruppe 742 Datenbewegungs- und Logikanweisungen (z. B. move (mov), compare (cmp)). In einigen Ausführungsformen nutzt die Bewegungs- und Logikgruppe 742 die fünf höchstwertigen Bits (MSB) gemeinsam, wobei move (mov) -Anweisungen die Form 0000xxxxb haben und Logikanweisungen die Form 0001xxxxb haben. Eine Flusssteueranweisungsgruppe 744 (z. B. call, jump (jmp)) beinhaltet Anweisungen in Form von 0010xxxxb (z. B. 0x20). Eine gemischte Anweisungsgruppe 746 beinhaltet eine Mischung von Anweisungen einschließlich Synchronisationsanweisungen (z. B. wait, send) in der Form 0011xxxxb (z. B. 0x30). Eine parallele Math.-Anweisungsgruppe 748 beinhaltet komponentenweise arithmetische Anweisungen (z. B. add, multiply (mul)) in der Form 0100xxxxb (z. B. 0x40). Die parallele Math.-Gruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle durch. Die Vektor-Math.-Gruppe 750 beinhaltet arithmetische Anweisungen (z. B. dp4) in Form von 0101xxxxb (z. B. 0x50). Die Vektor-Math.-Gruppe führt Arithmetik, wie zum Beispiel Skalarproduktberechnungen, an Vektoroperanden durch.
12 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente aus der 12, die die gleichen Bezugsnummern (oder Bezeichnungen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf beliebige ähnliche Weise wie hierin an anderer Stelle beschrieben betrieben werden oder funktionieren, sind jedoch nicht darauf beschränkt.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Grafik-Pipeline 820, eine Medien-Pipeline 830, eine Anzeige-Engine 840, eine Thread-Ausführungslogik 850 und eine Render-Ausgabe-Pipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor in einem Multi-Kern-Verarbeitungssystem, das einen oder mehrere Universalverarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht dargestellt) oder über Befehle gesteuert, die über eine Ringverbindung 802 an den Grafikprozessor 800 ausgegeben werden. In einigen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 mit anderen Verarbeitungskomponenten, wie zum Beispiel anderen Grafikprozessoren oder Universalprozessoren. Befehle von der Ringverbindung 802 werden von einem Befehls-Streamer 803 interpretiert, der einzelnen Komponenten der Grafik-Pipeline 820 oder der Medien-Pipeline 830 Anweisungen zuführt.
In einigen Ausführungsformen leitet der Befehls-Streamer 803 die Operation eines Vertex-Fetchers 805, der Vertex-Daten aus dem Speicher liest, und führt Vertex-Verarbeitungsbefehle aus, die von dem Befehls-Streamer 803 bereitgestellt werden. In einigen Ausführungsformen stellt der Vertex-Fetcher 805 Vertex-Daten einem Vertex-Shader 807 bereit, der Koordinatenraumtransformationen und Beleuchtungsoperationen für jeden Vertex durchführt. In einigen Ausführungsformen führen der Vertex-Fetcher 805 und der Vertex-Shader 807 Vertex-Verarbeitungsanweisungen aus, indem sie Ausführungs-Threads über einen Thread-Dispatcher 831 an die Ausführungseinheiten 852A, 852B senden.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A, 852B ein Array aus Vektorprozessoren mit einem Anweisungssatz zum Durchführen von Grafik- und Medienoperationen. In einigen Ausführungsformen weisen die Ausführungseinheiten 852A - 852B einen angeschlossenen L1-Cache 851 auf, der für jedes Array spezifisch ist oder von den Arrays gemeinsam genutzt wird. Der Cache kann als Daten-Cache, als Anweisungs-Cache oder als einzelner Cache konfiguriert sein, der derart partitioniert ist, dass er Daten und Anweisungen in verschiedenen Partitionen enthält.
In einigen Ausführungsformen enthält die Grafik-Pipeline 820 Tessellationskomponenten, um eine hardwarebeschleunigte Tessellation von 3D-Objekten durchzuführen. In einigen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tessellationsoperationen. Ein programmierbarer Domänen-Shader 817 stellt eine Backend-Auswertung der Tessellationsausgabe bereit. Ein Tessellator 813 arbeitet in Richtung des Hull-Shaders 811 und enthält eine spezielle Logik zum Generieren eines Satzes detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell, das als Eingabe für die Grafik-Pipeline 820 bereitgestellt wird. In einigen Ausführungsformen können, falls keine Tesselation verwendet wird, Tessellationskomponenten (z. B. Hull-Shader 811, Tesselator 813 und Domänen-Shader 817) umgangen werden.
In einigen Ausführungsformen können vollständige geometrische Objekte durch einen Geometrie-Shader 819 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 852A - 852B gesendet werden, oder sie können direkt zu dem Clipper 829 weitergehen. In einigen Ausführungsformen arbeitet der Geometrie-Shader an ganzen geometrischen Objekten und nicht an Vertices oder Patches von Vertices wie in vorherigen Stufen der Grafik-Pipeline. Wenn die Tessellation deaktiviert ist, empfängt der Geometrie-Shader 819 eine Eingabe von dem Vertex-Shader 807. In einigen Ausführungsformen ist der Geometrie-Shader 819 durch ein Geometrie-Shader-Programm programmierbar, um eine Geometrie-Tessellation durchzuführen, wenn die Tessellations-Einheiten deaktiviert sind.
Vor der Rasterisierung verarbeitet ein Clipper 829 Vertex-Daten. Der Clipper 829 kann ein Clipper mit fester Funktion oder ein programmierbarer Clipper mit Clipping- und Geometrie-Shader-Funktionen sein. In einigen Ausführungsformen versendet eine Rasterisierer- und Tiefentestkomponente 873 in der Render-Ausgabe-Pipeline 870 Pixel-Shader, um die geometrischen Objekte in ihre Pro-Pixel-Darstellungen umzuwandeln. In einigen Ausführungsformen ist eine Pixel-Shader-Logik in der Thread-Ausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung den Rasterisierer und die Tiefentestkomponente 873 umgehen und auf nicht rasterisierte Vertex-Daten über eine Strom-Aus-Einheit 823 zugreifen.
Der Grafikprozessor 800 weist einen Verbindungsbus, ein Verbindungs-Fabric oder einen anderen Verbindungsmechanismus auf, der ein Durchlaufen von Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors ermöglicht. In einigen Ausführungsformen sind die Ausführungseinheiten 852A - 852B und die der/die zugeordnete(n) Cache(s) 851, der Textur- und Medien-Sampler 854 und der Textur-/Sampler-Cache 858 über einen Datenanschluss 856 miteinander verbunden, um Speicherzugriff durchzuführen und mit Render-Ausgabe-Pipeline-Komponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen haben der Sampler 854, die Caches 851, 858 und die Ausführungseinheiten 852A - 852B jeweils getrennte Speicherzugriffspfade.
In einigen Ausführungsformen enthält die Render-Ausgabe-Pipeline 870 eine Rasterisierer- und Tiefentestkomponente 873, die vertexbasierte Objekte in eine zugeordnete pixelbasierte Darstellung umwandelt. In einigen Ausführungsformen enthält die Rasterisierer-Logik eine Windower/Maskierer-Einheit, um eine Dreiecks- und Linienrasterisierung mit festen Funktionen durchzuführen. Ein zugeordneter Render-Cache 878 und ein Tiefen-Cache 879 sind in einigen Ausführungsformen ebenfalls verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten durch, wenngleich in einigen Fällen Pixeloperationen, die 2D-Operationen zugeordnet sind (z. B. Bitblockbildübertragungen mit Mischen), von der 2D-Engine 841 ausgeführt oder zur Anzeigezeit durch den Anzeige-Controller 843 unter Verwendung von Overlay-Anzeigeebenen ersetzt werden. In einigen Ausführungsformen ist ein gemeinsamer L3-Cache 875 für alle Grafikkomponenten verfügbar, was die gemeinsame Nutzung von Daten ohne die Verwendung von Hauptsystemspeicher ermöglicht.
In einigen Ausführungsformen enthält die Grafikprozessor-Medien-Pipeline 830 eine Medien-Engine 837 und ein Video-Frontend 834. In einigen Ausführungsformen empfängt das Video-Frontend 834 Pipeline-Befehle von dem Befehls-Streamer 803. In einigen Ausführungsformen enthält die Medien-Pipeline 830 einen separaten Befehls-Streamer. In einigen Ausführungsformen verarbeitet das Video-Frontend 834 Medienbefehle vor dem Senden des Befehls an die Medien-Engine 837. In einigen Ausführungsformen enthält die Medien-Engine 837 eine Thread-Spawning-Funktionalität, um Threads zum Versenden an die Thread-Ausführungslogik 850 über den Thread-Dispatcher 831 hervorzubringen.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Anzeige-Engine 840. In einigen Ausführungsformen befindet sich die Anzeige-Engine 840 außerhalb des Prozessors 800 und ist mit dem Grafikprozessor über die Ringverbindung 802 oder einen anderen Verbindungsbus oder -fabric verbunden. In einigen Ausführungsformen enthält die Anzeige-Engine 840 eine 2D-Maschine 841 und einen Anzeige-Controller 843. In einigen Ausführungsformen weist die Anzeige-Engine 840 eine spezielle Logik auf, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen ist die Anzeige-Controller 843 mit einer Anzeigevorrichtung (nicht dargestellt) gekoppelt, die eine systemintegrierte Anzeigevorrichtung wie in einem Laptop-Computer oder eine externe Anzeigevorrichtung sein kann, die über einen Anzeigevorrichtungsverbinder angeschlossen ist.
In einigen Ausführungsformen sind die Grafik-Pipeline 820 und die Medien-Pipeline 830 konfigurierbar, um Operationen basierend auf mehreren Grafik- und Medienprogrammierschnittstellen durchzuführen, und sind für keine Anwendungsprogrammierschnittstelle (API) spezifisch. In einigen Ausführungsformen übersetzt die Treiber-Software für den Grafikprozessor API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die von dem Grafikprozessor verarbeitet werden können. In einigen Ausführungsformen wird Unterstützung für Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan Graphics und Rechen-API bereitgestellt, die alle von der Khronos Group sind. In einigen Ausführungsformen wird Unterstützung auch für die Direct3D-Bibliothek von der Microsoft Corporation bereitgestellt. In einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Unterstützung kann auch für die Open Source Computer Vision Bibliothek (OpenCV) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline wird ebenfalls unterstützt, wenn eine Abbildung von der Pipeline der zukünftigen API auf Pipeline des Grafikprozessors vorgenommen werden kann.
13A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat 900 gemäß einigen Ausführungsformen veranschaulicht. 13B ist ein Blockdiagramm, das eine Grafikprozessorbefehlsfolge 910 gemäß einer Ausführungsform veranschaulicht. Die Kästchen in durchgezogenen Linien in der 13A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einem Untersatz der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessorbefehlsformat 900 aus 13A enthält Datenfelder zum Identifizieren eines Ziel-Client 902 des Befehls, eines Befehlsoperationscodes (Opcode) 904 und der relevanten Daten 906 für den Befehl. Ein Teil-Opcode 905 und eine Befehlsgröße 908 sind ebenfalls in einigen Befehlen enthalten.
In einigen Ausführungsformen spezifiziert der Client 902 die Client-Einheit der Grafikvorrichtung, die die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessor-Befehls-Parser das Client-Feld jedes Befehls, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten an die geeignete Client-Einheit weiterzuleiten. In einigen Ausführungsformen enthalten die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Client-Einheit hat eine entsprechende Verarbeitungs-Pipeline, die die Befehle verarbeitet. Sobald der Befehl von der Client-Einheit empfangen wurde, liest die Client-Einheit den Opcode 904 und, falls vorhanden, den Teil-Opcode 905, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Informationen im Datenfeld 906 durch. Für einige Befehle wird eine explizite Befehlsgröße 908 erwartet, um die Größe des Befehls anzugeben. In einigen Ausführungsformen bestimmt der Befehls-Parser automatisch die Größe von mindestens einigen der Befehle basierend auf dem Befehlsoperationscode. In einigen Ausführungsformen werden Befehle über Vielfache eines Doppelwortes ausgerichtet.
Das Flussdiagramm in der 13B zeigt eine beispielhafte Grafikprozessorbefehlsfolge 910. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors aufweist, eine Version der Befehlsfolge, die dargestellt wird, um einen Satz von Grafikoperationen einzurichten, auszuführen und zu beenden. Eine beispielhafte Befehlsfolge wird nur zu Beispielszwecken dargestellt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlsfolge beschränkt sind. Darüber hinaus können die Befehle als Befehls-Batch in einer Befehlsfolge ausgegeben werden, so dass der Grafikprozessor die Folge von Befehlen zumindest teilweise gleichzeitig verarbeitet.
In einigen Ausführungsformen kann die Grafikprozessorbefehlsfolge 910 mit einem Pipeline-Entleerungsbefehl 912 beginnen, um zu bewirken, dass eine aktive Grafik-Pipeline die aktuell anstehenden Befehle für die Pipeline vervollständigt. In einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Die Pipeline-Entleerung wird durchgeführt, um zu bewirken, dass die aktive Grafik-Pipeline alle ausstehenden Befehle abschließt. Als Antwort auf eine Pipeline-Entleerung unterbricht der Befehls-Parser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichen-Engines ausstehende Operationen abschließen und die relevanten Lese-Caches ungültig gemacht werden. Wahlweise können alle Daten im Render-Cache, die als „fehlerhaft“ gekennzeichnet sind, in den Speicher geleert werden. In einigen Ausführungsformen kann der Pipeline-Entleerungsbefehl 912 für die Pipeline-Synchronisation oder vor dem Platzieren des Grafikprozessors in einen Zustand von niedriger Leistung verwendet werden.
In einigen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlsfolge erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. In einigen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 nur einmal in einem Ausführungskontext vor dem Ausgeben von Pipeline-Befehlen benötigt, es sei denn, der Kontext gibt Befehle für beide Pipelines aus. In einigen Ausführungsformen ist ein Pipeline-Entleerungsbefehl 912 unmittelbar vor einem Pipeline-Wechsel über den Pipeline-Auswahlbefehl 913 erforderlich.
In einigen Ausführungsformen konfiguriert ein Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für den Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medien-Pipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Pipeline-Steuerbefehl 914 den Pipeline-Zustand für die aktive Pipeline. In einer Ausführungsform wird der Pipeline-Steuerbefehl 914 für die Pipeline-Synchronisation und zum Löschen von Daten von einem oder mehreren Cache-Speichern innerhalb der aktiven Pipeline verwendet, bevor ein Befehls-Batch verarbeitet wird.
In einigen Ausführungsformen werden Rückgabepufferzustand-Befehle 916 verwendet, um einen Satz von Rückgabepuffern für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen während der Verarbeitung Zwischendaten schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und eine Cross-Thread-Kommunikation durchzuführen. In einigen Ausführungsformen beinhaltet der Rückgabepufferzustand 916 das Auswählen der Größe und Anzahl von Rückgabepuffern, die für einen Satz von Pipeline-Operationen zu verwenden sind.
Die verbleibenden Befehle in der Befehlsfolge unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipeline-Bestimmung 920 wird die Befehlsfolge auf die 3D-Pipeline 922 zugeschnitten, beginnend mit dem 3D-Pipeline-Zustand 930, oder die Medien-Pipeline 924, beginnend mit dem Medien-Pipeline-Zustand 940.
Die Befehle zum Konfigurieren des 3D-Pipeline-Zustands 930 beinhalten 3D-Zustandseinstellbefehle für den Vertex-Pufferzustand, den Vertex-Elementzustand, den konstanten Farbzustand, den Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitivenbefehle verarbeitet werden. Die Werte dieser Befehle werden mindestens teilweise basierend auf der jeweiligen verwendeten 3D-API bestimmt. In einigen Ausführungsformen sind 3D-Pipeline-Zustand 930-Befehle auch in der Lage, bestimmte Pipeline-Elemente selektiv zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird der 3D-Primitivenbefehl 932 verwendet, um 3D-Primitive, die von der 3D-Pipeline verarbeitet werden sollen, zu versenden. Befehle und zugeordnete Parameter, die über den 3D-Primitivenbefehl 932 an den Grafikprozessor geleitet werden, werden an die Vertex-Abruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die Daten des 3D-Primitivenbefehls 932, um Vertex-Datenstrukturen zu generieren. Die Vertex-Datenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der 3D-Primitivenbefehl 932 verwendet, um Vertex-Operationen an 3D-Primitiven über Vertex-Shader durchzuführen. Um Vertex-Shader zu verarbeiten, sendet die 3D-Pipeline 922 Shader-Ausführungs-Threads an Grafikprozessor-Ausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Befehl oder ein Ereignis execute 934 ausgelöst. In einigen Ausführungsformen löst ein Registerschreiben eine Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über einen „go“- oder „kick“-Befehl in der Befehlsfolge ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipeline-Synchronisationsbefehls ausgelöst, um die Befehlsfolge durch die Grafik-Pipeline zu entleeren. Die 3D-Pipeline führt eine Geometrieverarbeitung für die 3D-Primitiven durch. Sobald die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte rasterisiert und die Pixel-Engine färbt die resultierenden Pixel. Zusätzliche Befehle zum Steuern des Pixel-Shadings und der Pixel-Backend-Operationen können ebenfalls für diese Operationen enthalten sein.
In einigen Ausführungsformen folgt die Grafikprozessorbefehlsfolge 910 dem Pfad der Medien-Pipeline 924, wenn Medienoperationen durchgeführt werden. Im Allgemeinen hängt die spezifische Verwendung und Art der Programmierung für die Medien-Pipeline 924 von den durchzuführenden Medien oder Rechenoperationen ab. Bestimmte Mediendecodieroperationen können während der Mediendecodierung in die Medien-Pipeline ausgelagert werden. In einigen Ausführungsformen kann die Medien-Pipeline auch umgangen werden, und die Mediendecodierung kann ganz oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Universalverarbeitungskernen bereitgestellt werden. In einer Ausführungsform beinhaltet die Medien-Pipeline auch Elemente für GPGPU-Operationen (GPGPU = General-Graphics Processor Unit), wobei der Grafikprozessor zur Durchführung von SIMD-Vektoroperationen unter Verwendung von Computer-Shader-Programmen verwendet wird, die nicht explizit mit dem Rendern von Grafikprimitiven in Zusammenhang stehen.
In einigen Ausführungsformen ist die Medien-Pipeline 924 auf ähnliche Weise wie die 3D-Pipeline 922 konfiguriert. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipelinestatus 940 wird vor den Medienobjektbefehlen 942 versendet oder in einer Befehlswarteschlange platziert. In einigen Ausführungsformen beinhalten Befehle 940 für den Medien-Pipelinestatus Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medienobjekte verwendet werden. Dies schließt Daten zum Konfigurieren der Videodecodierungs- und Videocodierungslogik in der Medien-Pipeline ein, wie zum Beispiel ein Codierungs- oder Decodierungsformat ein. In einigen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Status 940 auch die Verwendung von einem oder mehreren Zeigern auf „indirekte“ Statuselemente, die einen Batch von Statuseinstellungen enthalten.
In einigen Ausführungsformen führen Medienobjektbefehle 942 den Medienobjekten Zeiger zur Verarbeitung durch die Medien-Pipeline zu. Die Medienobjekte enthalten Speicherpuffer, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medien-Pipeline-Stati gültig sein, bevor sie einen Medienobjektbefehl 942 ausgeben. Sobald der Pipeline-Status konfiguriert ist und die Medienobjektbefehle 942 in die Warteschlange eingereiht sind, wird die Medien-Pipeline 924 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (z. B. Registerschreibvorgang) ausgelöst. Die Ausgabe von der Medien-Pipeline 924 kann dann durch Operationen nachbearbeitet werden, die von der 3D-Pipeline 922 oder der Medien-Pipeline 924 bereitgestellt werden. In einigen Ausführungsformen werden GPGPU-Operationen auf ähnliche Weise wie Medienoperationen konfiguriert und ausgeführt.
14 veranschaulicht eine beispielhafte Grafik-Software-Architektur für ein Datenverarbeitungssystem 1000 gemäß einigen Ausführungsformen. In einigen Ausführungsformen beinhaltet die Software-Architektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. In einigen Ausführungsformen enthält der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Mehrzweckprozessorkern(e) 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programme, die Shader-Anweisungen 1012 enthalten. Die Shader-Sprachanweisungen können in einer High-Level-Shader-Sprache vorliegen, wie zum Beispiel der High Level Shader Language (HLSL) oder der OpenGL Shader Language (GLSL). Die Anwendung beinhaltet auch ausführbare Anweisungen 1014 in einer Maschinensprache, die zur Ausführung durch den Mehrzweckprozessorkern 1034 geeignet sind. Die Anwendung beinhaltet auch Grafikobjekte 1016, die durch Vertex-Daten definiert sind.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft@ Windows®-Betriebssystem von der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein Open-Source-UNIX-ähnliches Betriebssystem, das eine Variante des Linux-Kerns verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022 unterstützen, wie zum Beispiel die Direct3D-API, die OpenGL-API oder die Vulkan-API. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 1020 einen Frontend-Shader-Compiler 1024, um alle Shader-Anweisungen 1012 in HLSL in eine Shader-Sprache niedrigerer Ebene zu kompilieren. Die Kompilierung kann eine Just-in-Time (JIT) -Kompilierung sein, oder die Anwendung kann eine Shader-Vorkompilierung durchführen. In einigen Ausführungsformen werden Shader hoher Ebene während der Kompilierung der 3D-Grafikanwendung 1010 zu Shadern niedrigerer Ebene kompiliert. In einigen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform bereitgestellt, wie zum Beispiel als eine Version der Standard Portable Intermediate Representation (SPIR), die von der Vulkan-API verwendet wird.
In einigen Ausführungsformen enthält der Benutzermodus-Grafiktreiber 1026 einen Backend-Shader-Compiler 1027, um die Shader-Anweisungen 1012 in eine hardwarespezifische Darstellung umzuwandeln. Wenn die OpenGL-API verwendet wird, werden die Shader-Anweisungen 1012 in der GLSL-Hochsprache an einen Benutzermodus-Grafiktreiber 1026 zur Kompilierung geleitet. In einigen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystem-Kernmodusfunktionen 1028, um mit einem Kernmodus-Grafiktreiber 1029 zu kommunizieren. In einigen Ausführungsformen kommuniziert der Kernmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen zu versenden.
Einer oder mehrere Aspekte mindestens einer Ausführungsform können durch einen repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik innerhalb einer integrierten Schaltung, wie zum Beispiel einem Prozessor, darstellt und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Anweisungen enthalten, die verschiedene Logik innerhalb des Prozessors repräsentieren. Wenn sie von einer Maschine gelesen werden, können die Anweisungen bewirken, dass die Maschine die Logik herstellt, um die hierin beschriebenen Techniken durchzuführen. Solche Darstellungen, die als „IP-Kerne“ bekannt sind, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium als ein Hardware-Modell gespeichert werden können, das die Struktur der integrierten Schaltung beschreibt. Das Hardware-Modell kann an verschiedene Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Herstellungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann derart hergestellt sein, dass die Schaltung Operationen durchführt, die in Verbindung mit irgendeiner der hier beschriebenen Ausführungsformen beschrieben sind.
15 ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100 veranschaulicht, das zur Herstellung einer integrierten Schaltung zur Durchführung von Operationen verwendet werden kann. Das IP-Kernentwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Entwürfe zu erzeugen, die in einen größeren Entwurf integriert werden können oder verwendet werden können, um eine gesamte integrierte Schaltung (z. B. eine integrierte SOC-Schaltung) zu konstruieren. Eine Entwurfseinrichtung 1130 kann eine Software-Simulation 1110 eines IP-Kern-Entwurfs in einer höheren Programmiersprache (z. B. C/C ++) generieren. Die Software-Simulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu entwerfen, zu testen und zu verifizieren. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Timing-Simulationen beinhalten. Ein Registerübertragungspegel (RTL) -Entwurf 1115 kann dann aus dem Simulationsmodell 1112 erzeugt oder synthetisiert werden. Der RTL-Entwurf 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Signale zwischen Hardware-Registern modelliert, einschließlich der zugeordneten Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Neben einem RTL-Entwurf 1115 können auch Entwürfe auf niedrigerer Ebene auf der Logikebene oder der Transistorebene erzeugt, entworfen oder synthetisiert werden. Daher können die speziellen Details des anfänglichen Entwurfs und der Simulation variieren.
Der RTL-Entwurf 1115 oder ein Äquivalent kann ferner durch die Entwurfseinrichtung in ein Hardwaremodell 1120 synthetisiert werden, das in einer Hardware-Beschreibungssprache (HDL) oder einer anderen Darstellung von Daten des physischen Entwurfs vorliegen kann. Die HDL kann weiter simuliert oder getestet werden, um den IP-Kern-Entwurf zu verifizieren. Der IP-Kern-Entwurf kann zur Lieferung an eine Drittherstellereinrichtung 1165 unter Verwendung eines nichtflüchtigen Speichers 1140 (z. B. Festplatte, Flash-Speicher oder ein beliebiges nichtflüchtiges Speichermedium) gespeichert werden. Alternativ kann der IP-Kern-Entwurf über eine Kabelverbindung 1150 oder eine drahtlose Verbindung 1160 (z. B. über das Internet) übertragen werden. Die Herstellungseinrichtung 1165 kann dann eine integrierte Schaltung herstellen, die zumindest teilweise auf dem IP-Kern-Entwurf basiert. Die hergestellte integrierte Schaltung kann konfiguriert sein, Operationen gemäß mindestens einer hierin beschriebenen Ausführungsform durchzuführen.
16 - 18 veranschaulichen beispielhafte integrierte Schaltungen und zugeordnete Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne gemäß verschiedenen hierin beschriebenen Ausführungsformen hergestellt werden können. Zusätzlich zu den Veranschaulichungen, können andere Logik und Schaltungen enthalten sein, einschließlich zusätzlicher Grafikprozessoren/-kerne, Peripherieschnittstellen-Controller oder Universalprozessorkernen.
16 ist ein Blockdiagramm, das eine beispielhafte integrierte System-on-Chip-Schaltung 1200 veranschaulicht, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. Die beispielhafte integrierte Schaltung 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 denen jeder ein modularer IP-Kern aus derselben oder mehreren verschiedenen Entwurfseinrichtungen sein kann. Die integrierte Schaltung 1200 enthält eine Peripherie- oder Buslogik, einschließlich eines USB-Controllers 1225, eines UART-Controllers 1230, eines SPI/SDIO-Controllers 1235 und eines I²S/I²C-Controllers 1240. Zusätzlich kann die integrierte Schaltung eine Anzeigevorrichtung 1245 enthalten, die mit einer oder mehreren von einer High-Definition Multimedia Interface (HDMI-) Controller 1250 und einer Mobile Industry Processor Interface (MIPI-) Anzeigeschnittstelle 1255 gekoppelt ist. Die Speicherung kann von einem Flash-Speicher-Teilsystem 1260 bereitgestellt werden, das einen Flash-Speicher und einen Flash-Speicher-Controller enthält. Die Speicherschnittstelle kann über einen Speicher-Controller 1265 für den Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt werden. Einige integrierte Schaltungen enthalten zusätzlich eine eingebettete Sicherheits-Engine 1270.
17 ist ein Blockdiagramm, das einen beispielhaften Grafikprozessor 1310 einer integrierten System-on-Chip-Schaltung veranschaulicht, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. Der Grafikprozessor 1310 kann eine Variante des Grafikprozessors 1210 aus der 16 sein. Der Grafikprozessor 1310 enthält einen Vertex-Prozessor 1305 und einen oder mehrere Fragment-Prozessoren 1315A - 1315N (z. B. 1315A, 1315B, 1315C, 1315D bis 3515N-1 und 3515N). Der Grafikprozessor 1310 kann unterschiedliche Shader-Programme über separate Logik ausführen, so dass der Vertex-Prozessor 1305 zum Ausführen von Operationen für Vertex-Shader-Programme optimiert ist, während der eine oder die mehreren Fragment-Prozessor(en) 1315A - 1315N Fragment- (z. B. Pixel-) Shading-Operationen für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertex-Prozessor 1305 führt die Vertex-Verarbeitungsstufe der 3D-Grafik-Pipeline durch und generiert Primitive und Vertex-Daten. Der bzw. die Fragment-Prozessor(en) 1315A - 1315N verwenden die von dem Vertex-Prozessor 1305 generierten Primitiven und Vertex-Daten, um einen Frame-Puffer zu erzeugen, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform ist/sind der/die Fragment-Prozessor(en) 1315A - 1315N dazu optimiert, Fragment-Shader-Programme, wie sie in der OpenGL-API bereitgestellt werden, auszuführen, die verwendet werden können, um ähnliche Operationen wie ein Pixel-Shader-Programm durchzuführen, wie es in der Direct 3D API bereitgestellt wird.
Der Grafikprozessor 1310 enthält zusätzlich eine oder mehrere Speicher-Management-Einheiten (MMUs, Memory Management Units) 1320A - 1320B, den/die Cache(s) 1325A - 1325B und die Schaltungsverbindung(en) 1330A - 1330B. Die eine oder mehreren MMU(s) 1320A - 1320B sorgen für eine Abbildung von virtuellen auf physikalische Adressen für die integrierte Schaltung 1310, einschließlich für den Vertex-Prozessor 1305 und/oder den/die Fragment-Prozessor(en) 1315A - 1315N, die zusätzlich zu den Vertex- oder Bild-/Textur-Daten, die in dem einen oder den mehreren Caches 1325A - 1325B gespeichert sind, Vertex- oder Bild-/Texturdaten referenzieren können, die im Speicher gespeichert sind. In einer Ausführungsform können die eine oder die mehreren MMU(s) 1325A - 1325B mit anderen MMUs innerhalb des Systems synchronisiert sein, einschließlich einer oder mehreren MMU(s), die dem einen oder den mehreren Anwendungsprozessoren 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 aus der 17 zugeordnet sind, so dass jeder Prozessor 1205 - 1220 an einem gemeinsam genutzten oder vereinheitlichten virtuellen Speichersystem teilnehmen kann. Die eine oder die mehreren Schaltungsverbindung(en) 1330A - 1330B ermöglichen dem Grafikprozessor 1310 gemäß Ausführungsformen, sich mit anderen IP-Kernen innerhalb des SoC zu verbinden, entweder über einen internen Bus des SoC oder über eine direkte Verbindung.
18 ist ein Blockdiagramm, das einen zusätzlichen beispielhaften Grafikprozessor 1410 einer integrierten System-on-Chip-Schaltung veranschaulicht, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. Der Grafikprozessor 1410 kann eine Variante des Grafikprozessors 1210 aus der 16 sein. Der Grafikprozessor 1410 enthält die eine oder die mehreren MMU(s) 1320A - 1320B, den/die Cache(s) 1325A - 1325B und die Schaltungsverbindung(en) 1330A - 1330B der integrierten Schaltung 1300 aus der 17.
Der Grafikprozessor 1410 enthält einen oder mehrere Shader-Kern(e) 1415A - 1415N (z. B. 1415A, 1415B, 1415C, 1415D, 1415E, 1415F bis 1315N-1 und 1315N), was für eine vereinheitlichte Shader-Kernarchitektur sorgt, in der ein einzelner Kern oder Kerntyp alle Arten von programmierbarem Shader-Code ausführen kann, einschließlich Shader-Programmcode zum Implementieren von Vertex-Shadern, Fragment-Shadern und/oder Compute-Shadern. Die genaue Anzahl der vorhandenen Shader-Kerne kann zwischen Ausführungsformen und Implementierungen variieren. Zusätzlich enthält der Grafikprozessor 1410 einen Inter-Core-Aufgabenmanager 1405, der als Thread-Dispatcher zum Versenden von Ausführungs-Threads an einen oder mehrere Shader-Kerne 1415A - 1415N und eine Kachelungseinheit 1418 fungiert, um Kachelungsoperationen für kachelbasiertes Rendering zu beschleunigen, wobei die Rendering-Operationen für eine Szene in einen Bildraum unterteilt sind, um zum Beispiel lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder um die Verwendung von internen Caches zu optimieren.
Die folgenden Abschnitte und/oder Beispiele betreffen weitere Ausführungsformen:
Ein Ausführungsbeispiel kann ein Verfahren sein, das das Wiederverwenden einer Berechnung für einen Elterknoten in einer Bounding-Volume-Hierarchy-Strahltraversierung mit reduzierter Genauigkeit zur Grafikverarbeitung in einem Kindknoten umfasst. Das Verfahren kann für Knotenminimalkoordinaten auch das Identifizieren von Koordinaten beinhalten, die sich von den Elterknoten-Minimalkoordinaten unterscheiden. Das Verfahren kann das Berechnen von Differenzen zwischen Elter- und Kindknotenkoordinaten beinhalten. Das Verfahren kann das Quantisieren der Differenzen beinhalten. Das Verfahren kann für Knotenmaximalkoordinaten das Identifizieren von Koordinaten beinhalten, die sich von den Elterknoten-Maximalkoordinaten unterscheiden. Das Verfahren kann das Berechnen von Differenzen zwischen Elter- und Kindknotenkoordinaten beinhalten. Das Verfahren kann das Quantisieren der Differenzen beinhalten. Das Verfahren kann das Bestimmen, wo ein Strahl in eine Bounding Box eintritt, und das Verwenden einer ersten quantisierten Koordinate r_i beinhalten, um eine erste parametrische Distanz λ_i zu ermitteln. Das Verfahren kann das Bestimmen, wo der Strahl in der Bounding Box vorhanden ist, unter Verwendung einer zweiten quantisierten Koordinate s_i beinhalten, um eine zweite parametrische Distanz µ_i zu ermitteln. Das Verfahren kann das Vergleichen von µ_i und λ_i beinhalten, um einen Schnittpunkt von Strahl und Bounding Box zu bestimmen, indem die Strahlsteigung und λ_i und die Strahlsteigung und µ_i unter Verwendung von Multiplikation mit reduzierter Genauigkeit multipliziert werden.
Ein anderes Ausführungsbeispiel kann mindestens ein nichtflüchtiges computerlesbares Medium sein, das Anweisungen speichert, um eine Folge durchzuführen, die das Wiederverwenden einer Berechnung für einen Elterknoten in einer Bounding-Volume-Hierarchy-Strahltraversierung mit reduzierter Genauigkeit zur Grafikverarbeitung in einem Kindknoten umfasst. Die Medien können für Knotenminimalkoordinaten das Identifizieren von Koordinaten beinhalten, die sich von den Elterknoten-Minimalkoordinaten unterscheiden. Die Medien können das Berechnen von Differenzen zwischen Elter- und Kindknotenkoordinaten beinhalten. Die Medien können das Quantisieren der Differenzen beinhalten. Die Medien können für Knotenmaximalkoordinaten das Identifizieren von Koordinaten beinhalten, die sich von den Elterknoten-Maximalkoordinaten unterscheiden. Die Medien können das Berechnen von Differenzen zwischen Elter- und Kindknotenkoordinaten beinhalten. Die Medien können das Quantisieren der Differenzen beinhalten. Die Medien können das Bestimmen, wo ein Strahl in eine Bounding Box eintritt, und das Verwenden einer ersten quantisierten Koordinate r_i beinhalten, um eine erste parametrische Distanz λ_i zu ermitteln. Die Medien können das Bestimmen, wo der Strahl in der Bounding Box vorhanden ist, unter Verwendung einer zweiten quantisierten Koordinate s_i beinhalten, um eine zweite parametrische Distanz µ_i zu ermitteln. Die Medien können das Vergleichen von µ_i und λ_i beinhalten, um einen Schnittpunkt von Strahl und Bounding Box zu bestimmen, indem die Strahlsteigung und λ_i und die Strahlsteigung und µ_i unter Verwendung von Multiplikation mit reduzierter Genauigkeit multipliziert werden.
Ein anderes Ausführungsbeispiel kann eine Vorrichtung sein, die einen Prozessor zum Wiederverwenden einer Berechnung für einen Elterknoten in einer Bounding-Volume-Hierarchy-Strahltraversierung mit reduzierter Genauigkeit zur Grafikverarbeitung in einem Kindknoten und einen mit dem Prozessor gekoppelten Speicher umfasst. Die Vorrichtung des Prozessors dient dazu, für Knotenminimalkoordinaten das Identifizieren von Koordinaten, die sich von den Elterknoten-Minimalkoordinaten unterscheiden, zu beinhalten. Die Vorrichtung des Prozessors dient zum Berechnen von Differenzen zwischen Elter- und Kindknotenkoordinaten. Die Vorrichtung des Prozessors dient zum Quantisieren der Differenzen. Die Vorrichtung des Prozessors dient dazu, für Knotenmaximalkoordinaten das Identifizieren von Koordinaten, die sich von den Elterknoten-Maximalkoordinaten unterscheiden, zu beinhalten. Die Vorrichtung des Prozessors dient zum Berechnen von Differenzen zwischen Elter- und Kindknotenkoordinaten. Die Vorrichtung des Prozessors dient zum Quantisieren der Differenzen. Die Vorrichtung des Prozessors dient zum Bestimmen, wo ein Strahl in eine Bounding Box eintritt, und zum Verwenden einer ersten quantisierten Koordinate r_i, um eine erste parametrische Distanz λ_i zu ermitteln. Die Vorrichtung des Prozessors dient zum Bestimmen, wo der Strahl in der Bounding Box vorhanden ist, unter Verwendung einer zweiten quantisierten Koordinate s_i, um eine zweite parametrische Distanz µ_i zu ermitteln. Die Vorrichtung des Prozessors dient zum Vergleichen von µ_i und λ_i, um einen Schnittpunkt von Strahl und Bounding Box zu bestimmen, indem die Strahlsteigung und λ_i und die Strahlsteigung und µ_i unter Verwendung von Multiplikation mit reduzierter Genauigkeit multipliziert werden.
Die hier beschriebenen Grafikverarbeitungstechniken können in verschiedenen Hardware-Architekturen implementiert werden. Zum Beispiel kann die Grafikfunktionalität in einem Chipsatz integriert sein. Alternativ kann ein diskreter Grafikprozessor verwendet werden. Als noch eine andere Ausführungsform können die Grafikfunktionen durch einen Universalprozessor, einschließlich einem Mehrkernprozessor, implementiert werden.
Bezugnahmen in dieser Spezifikation auf „eine Ausführungsform“ oder „Ausführungsform“ bedeuten durchweg, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, das bzw. die in Verbindung mit der Ausführungsform beschrieben wird, in mindestens einer Implementierung enthalten ist, die in der vorliegenden Offenbarung eingeschlossen ist. Daher beziehen sich die Vorkommen des Ausdrucks „eine Ausführungsform“ oder „in einer Ausführungsform“ nicht notwendigerweise auf die gleiche Ausführungsform. Des Weiteren können die besonderen Merkmale, Strukturen oder Eigenschaften in anderen geeigneten Formen eingerichtet werden, die sich von der besonderen veranschaulichten Ausführungsform unterscheiden, und alle derartigen Formen können in den Ansprüchen der vorliegenden Anmeldung eingeschlossen sein.
Während eine beschränkte Anzahl von Ausführungsformen beschrieben worden ist, werden Fachleute zahlreiche Modifikationen und Varianten davon anerkennen. Es ist beabsichtigt, dass die beigefügten Ansprüche alle derartigen Modifikationen und Varianten abdecken, weil sie in den wahren Geist und den Schutzbereich dieser Offenbarung fallen.

Claims

Verfahren, das Folgendes umfasst: in einem Kindknoten eine Berechnung für einen Elterknoten in einer Bounding-Volume-Hierarchy-Strahltraversierung mit reduzierter Genauigkeit zur Grafikverarbeitung wiederzuverwenden.
Verfahren nach Anspruch 1, das für Knotenminimalkoordinaten das Identifizieren von Koordinaten beinhaltet, die sich von den Elterknoten-Minimalkoordinaten unterscheiden.
Verfahren nach Anspruch 2, das das Berechnen von Differenzen zwischen Elter- und Kindknotenkoordinaten beinhaltet.
Verfahren nach Anspruch 3, das das Quantisieren der Differenzen beinhaltet.
Verfahren nach Anspruch 2, das für Knotenmaximalkoordinaten das Identifizieren von Koordinaten beinhaltet, die sich von den Elterknoten-Maximalkoordinaten unterscheiden.
Verfahren nach Anspruch 5, das das Berechnen von Differenzen zwischen Elter- und Kindknotenkoordinaten beinhaltet.
Verfahren nach Anspruch 6, das das Quantisieren der Differenzen beinhaltet.
Verfahren nach Anspruch 1, das das Bestimmen, wo ein Strahl in eine Bounding Box eintritt, und das Verwenden einer ersten quantisierten Koordinate r_i beinhaltet, um eine erste parametrische Distanz λ_i zu ermitteln.
Verfahren nach Anspruch 8, das das Bestimmen, wo der Strahl in der Bounding Box vorhanden ist, unter Verwendung einer zweiten quantisierten Koordinate s_i beinhaltet, um eine zweite parametrische Distanz µ_i zu ermitteln.
Verfahren nach Anspruch 9, das das Vergleichen von µ_i und λ_i beinhaltet, um einen Schnittpunkt von Strahl und Bounding Box zu bestimmen, indem die Strahlsteigung und λ_i und die Strahlsteigung und µ_i unter Verwendung von Multiplikation mit reduzierter Genauigkeit multipliziert werden.
Nichtflüchtiges computerlesbares Medium oder mehrere nichtflüchtige computerlesbare Medien, die Anweisungen speichern, um eine Folge durchzuführen, die Folgendes umfasst: in einem Kindknoten eine Berechnung für einen Elterknoten in einer Bounding-Volume-Hierarchy-Strahltraversierung mit reduzierter Genauigkeit zur Grafikverarbeitung wiederzuverwenden.
Medien nach Anspruch 11, die für Knotenminimalkoordinaten das Identifizieren von Koordinaten beinhalten, die sich von den Elterknoten-Minimalkoordinaten unterscheiden.
Medien nach Anspruch 12, die das Berechnen von Differenzen zwischen Elter- und Kindknotenkoordinaten beinhalten.
Medien nach Anspruch 13, die das Quantisieren der Differenzen beinhalten.
Medien nach Anspruch 12, die für Knotenmaximalkoordinaten das Identifizieren von Koordinaten beinhalten, die sich von den Elterknoten-Maximalkoordinaten unterscheiden.
Medien nach Anspruch 15, die das Berechnen von Differenzen zwischen Elter- und Kindknotenkoordinaten beinhalten.
Medien nach Anspruch 16, die das Quantisieren der Differenzen beinhalten.
Medien nach Anspruch 11, die das Bestimmen, wo ein Strahl in eine Bounding Box eintritt, und das Verwenden einer ersten quantisierten Koordinate r_i beinhalten, um eine erste parametrische Distanz λ_i zu ermitteln.
Medien nach Anspruch 18, die das Bestimmen, wo der Strahl in der Bounding Box vorhanden ist, unter Verwendung einer zweiten quantisierten Koordinate s_i beinhalten, um eine zweite parametrische Distanz µ_i zu ermitteln.
Medien nach Anspruch 19, die das Vergleichen von µ_i und λ_i beinhalten, um einen Schnittpunkt von Strahl und Bounding Box zu bestimmen, indem die Strahlsteigung und λ_i und die Strahlsteigung und µ_i unter Verwendung von Multiplikation mit reduzierter Genauigkeit multipliziert werden.
Vorrichtung, die Folgendes umfasst: einen Prozessor, um in einem Kindknoten eine Berechnung für einen Elterknoten in einer Bounding-Volume-Hierarchy-Strahltraversierung mit reduzierter Genauigkeit zur Grafikverarbeitung wiederzuverwenden; und einen Speicher, der mit dem Prozessor gekoppelt ist.
Vorrichtung nach Anspruch 21, wobei der Prozessor dazu dient, für Knotenminimalkoordinaten das Identifizieren von Koordinaten, die sich von den Elterknoten-Minimalkoordinaten unterscheiden, zu beinhalten.
Vorrichtung nach Anspruch 22, wobei der Prozessor dazu dient, Differenzen zwischen Elter- und Kindknotenkoordinaten zu berechnen.
Vorrichtung nach Anspruch 23, wobei der Prozessor dazu dient, die Differenzen zu quantisieren.
Vorrichtung nach Anspruch 22, wobei der Prozessor dazu dient, für Knotenmaximalkoordinaten das Identifizieren von Koordinaten, die sich von den Elterknoten-Maximalkoordinaten unterscheiden, zu beinhalten.