DE102018114929B4 - System und verfahren für ein rendering eines lichtfeldes - Google Patents

Abstract

Verfahren zum Rendering eines Lichtfeldes, umfassend:Projizieren von Strahlen von einem Blickpunkt einer virtuellen Kameraposition, wobei der Blickpunkt aneiner ersten Seite eines räumlichen Lichtmodulator (SLM) positioniert ist, zu einer Abschneideebene, die an einer gegenüberliegenden Seite des SLM positioniert ist, um einenelementaren Betrachtungsstumpf innerhalb einer dreidimensionalen Szene zu bilden, wobei der SLM mit einer Anordnung von nichtüberlappenden Elementarbereichen gekachelt ist, und ein oberer Rand und ein unterer Rand eines ersten Elementarbereichs der nichtüberlappenden Elementarbereiche werden von den Strahlen geschnitten, um den elementaren Betrachtungsstumpf zu bilden; wobei die virtuelle Kameraposition einen lateralen Versatz entfernt von dem räumlichen Modulator angeordnet ist, der größer 0 ist, wobei der laterale Versatz berechnet wird basierend auf einer Pixelrastergröße des SLM und einer Breite eines holographischen Elements, wobei eine Anordnung von holographischen Elementen eine Oberfläche des SLM abdeckt undRendering von Objekten innerhalb des elementaren Betrachtungsstumpfes, um Komponenten eines ersten Elementarbildes für den ersten Elementarbereich zu erzeugen, wobei das Lichtfeld das erste Elementarbild und zusätzliche Elementarbilder umfasst, die der Anordnung von Elementarbereichen entsprechen, und jeweils eines der zusätzlichen Elementarbilder unter Verwendung eines zusätzlicher elementaren Betrachtungsstumpfs gerendert wird.

Description

• GEBIET DER ERFINDUNG
• Die vorliegende Erfindung betrifft computererzeugte Holographie und genauer gesagt ein System und ein Verfahren für ein Rendering eines Lichtfeldes.
• HINTERGRUND
• Eine Erzeugung einer komfortablen visuellen Erfahrung ist für den Erfolg von modernen Systemen virtueller Realität (VR = Virtual Reality) und erweiterter Realität (AR = Augmented Reality) bedeutsam. Ein weites Blickfeld, eine hohe Auflösung, Interaktivität, eine blickabhängige Verdeckung und kontinuierliche Fokushinweise sind signifikante Merkmale zum Bereitstellen einer komfortablen visuellen Erfahrung. Herkömmliche VR-Systeme versagen jedoch typischerweise viele dieser Merkmale bereitzustellen, was zu Unbehagen des Benutzers führt. Somit gibt es eine Notwenigkeit, sich diesen und/oder anderen Problemen zu widmen, die dem Stand der Technik zugeordnet sind. Die WO 2007/118 842 A1 beschreibt ein Verfahren zum Rendern und Generieren von Video Hologrammen in Echtzeit mit einer virtuellen Kameraposition. Die DE 10 2004 044 111 A1 beschreibt ein Verfahren zum Kodieren und Rekonstruieren von Hologrammen, wobei eine virtuelle Kameraposition in der Ebene des Betrachters angeordnet wird.
• ZUSAMMENFASSUNG
• Ein Verfahren, und ein System werden gemäß den unabhängigen Ansprüchen bereitgestellt und konfiguriert, um ein Lichtfeld zu rendern. Das Verfahren umfasst unter anderem ein Projizieren von Strahlen von einem Blickpunkt einer virtuellen Kameraposition, wobei der Blickpunkt an einer ersten Seite eines räumlichen Lichtmodulators (SLM = spatial light modulator) positioniert ist, zu einer Abschneideebene, die an einer gegenüberliegenden Seite des SLM positioniert ist, um einen elementaren Betrachtungsstumpf innerhalb einer dreidimensionalen Szene zu bilden. Objekte innerhalb des elementaren Betrachtungsstumpfs werden gerendert, um Komponenten eines ersten Elementarbilds für den ersten Elementarbereich zu erzeugen. In einer Ausführungsform ist der SLM mit einer Anordnung von Elementarbereichen gekachelt und ein oberer Rand und ein unterer Rand eines ersten Elementarbereichs des nichtüberlappenden Elementarbereichs werden von den Strahlen geschnitten, um den elementaren Betrachtungsstumpf zu bilden. In bestimmten Ausführungsformen umfasst das Lichtfeld das erste Elementarbild und zusätzliche Elementarbilder, die der Anordnung von Elementarbereichen entsprechen, und jeweils eines der zusätzlicher Elementarbilder wird unter Verwendung eines zusätzlichen elementaren Betrachtungsstumpfs gerendert.
• Des Weiteren umfasst das System eine Verarbeitungseinheit, die mit dem SLM gekoppelt und konfiguriert ist, um das Verfahren durchzuführen.
• Ein zweites Verfahren, und ein zweites System werden konfiguriert, um ein Lichtfeld zu rendern. Das zweite Verfahren umfasst ein Berechnen eines lateralen Versatzes zwischen einer Blickposition und einem räumlichen Lichtmodulator (SLM) basierend auf einer Größe des SLM und einer Breite eines holographischen Elements. Eine dreidimensionale Szene wird von der Blickposition gerendert, um eine Anordnung von Elementarbildern zu erzeugen. In einer Ausführungsform bedeckt eine Anordnung von holographischen Elementen eine Oberfläche des SLM.
• Des Weiteren umfasst das zweite System eine Verarbeitungseinheit, die mit dem SLM gekoppelt und konfiguriert ist, um das zweite Verfahren durchzuführen.
• KURZE BESCHREIBUNG DER ZEICHNUNGEN
• 1A veranschaulicht ein Ablaufdiagramm eines Verfahrens zum Rendering eines Lichtfeldes gemäß einer Ausführungsform.
• 1B veranschaulicht ein Ablaufdiagramm eines Verfahrens zum Rendering von Objekten innerhalb eines elementaren Betrachtungsstumpfs gemäß einer Ausführungsform.
• 1C veranschaulicht eine computererzeugte Holographie gemäß einer Ausführungsform.
• 1D veranschaulicht ein holographisches Element gemäß einer Ausführungsform.
• 2A veranschaulicht ein herkömmliches Hogel-Rendering gemäß dem Stand der Technik.
• 2B veranschaulicht ein Hogel-Rendering mit Planwellenbeleuchtung gemäß einer Ausführungsform.
• 2C veranschaulicht einen Bereich eines Ambiguitätssegments gemäß einer Ausführungsform.
• 2D veranschaulicht ein Hogel-Rendering mit Kugelwellenbeleuchtung gemäß einer Ausführungsform.
• 2E veranschaulicht einen Bereich eines Ambiguitätssegments gemäß einer Ausführungsform.
• 2F veranschaulicht algorithmische Operationen eines Verfahrens zum Rendering eines Lichtfeldes unter Verwendung von Kugelbeleuchtung gemäß einer Ausführungsform.
• 2G veranschaulicht einen Vergleich von ElementarbildAuflösungsergebnissen gemäß einer Ausführungsform.
• 2H veranschaulicht ein Ablaufdiagramm eines Verfahrens zum Rendering eines Lichtfeldes gemäß einer Ausführungsform.
• 3 veranschaulicht eine Parallelverarbeitungseinheit gemäß einer Ausführungsform.
• 4A veranschaulicht einen allgemeinen Verarbeitungs-Cluster innerhalb der Parallelverarbeitungseinheit von 3 gemäß einer Ausführungsform.
• 4B veranschaulicht eine Speicher-Partitions-Einheit der Parallelverarbeitungseinheit von 3 gemäß einer Ausführungsform.
• 5A veranschaulicht den Streaming-Multiprozessor von 4A gemäß einer Ausführungsform.
• 5B ist ein Konzeptdiagramm eines Verarbeitungssystems, das unter Verwendung der PPU von 3 implementiert wird, gemäß einer Ausführungsform.
• 5C veranschaulicht ein beispielhaftes System, bei dem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden kann.
• 6 ist ein Konzeptdiagramm einer durch die PPU von 3 implementierten Graphikverarbeitungs-Pipeline gemäß einer Ausführungsform.
• AUSFÜHRLICHE BESCHREIBUNG
• Ausführungsformen der vorliegenden Erfindung verbessern das Blickfeld, die Interaktivität bei hoher Auflösung und die blickabhängige Verdeckung bei computererzeugter Holographie (CGH). Des Weiteren stellen verschiedene Ausführungsformen vorteilhafterweise kontinuierliche Fokushinweise bereit, um dadurch im Wesentlichen einen Vergenzakkommodationskonflikt in augennahen Anzeigen zu vermeiden. In einer Ausführungsform umfasst eine augennahe Anzeige Flüssigkristall(LC)- und/oder räumliche Lichtmodulator(SLM)-Strukturen, die konfiguriert sind, um ein CGH-Lichtfeld einem Benutzer anzuzeigen. Das CGH-Lichtfeld kann gemäß Planwellenbeleuchtung, Kugelwellenbeleuchtung oder einem beliebigen anderen, technisch möglichen Wellenausbreitungs-Beleuchtungsmodell berechnet werden.
• Ein CGH-Lichtfeld stellt eine Objektwelle für einen gegebenen beobachtbaren Punkt in einer dreidimensionalen (3D) Szene basierend auf einer Bezugswelle bereit. Die Form der Bezugswelle (z.B., Planwellen) kann spezifiziert werden und die CGH-Verarbeitung berechnet ein Beugungsmuster, das eine Umwandlung von der Bezugswelle in eine Objektwelle an einem gegebenen Ort innerhalb eines Hologramms durchführen wird. In einer Ausführungsform umfasst das Berechnen der Objektwelle ein Projizieren von Strahlen von einem Blickpunkt (z.B., Rendering-Kameraposition), der vor einem SLM positioniert ist, in Richtung einer Abschneideebene, die hinter dem SLM positioniert ist. Im Allgemeinen kann der Blickpunkt und die Abschneideebene auf gegenüberliegenden Seiten des SLM positioniert sein. Ein gegebener Strahl kann berechnet werden, um eine Amplitude und eine Phase relativ zu anderen Strahlen aufzuweisen. Bereiche des SLM können in Elementarbildern jeweils mit einem elementaren Betrachtungsstumpf innerhalb der 3D-Szene organisiert werden, so dass jedes Elementarbild eine einzelne, unterschiedliche repräsentative Ansicht der 3D-Szene umfassen kann. Des Weiteren können mehrere Elementarbilder gerendert werden, um eine vollständige 3D-Szene zu bilden, die einem Benutzer präsentiert wird.
• 1A veranschaulicht ein Ablaufdiagramm eines Verfahrens 110 zum Rendering eines Lichtfeldes gemäß einer Ausführungsform. Obwohl das Verfahren 110 im Kontext einer Verarbeitungseinheit beschrieben wird, kann das Verfahren 110 ebenfalls durch ein Programm, kundenspezifische Schaltungsanordnungen oder durch eine Kombination von kundenspezifischen Schaltungsanordnungen und einem Programm durchgeführt werden. Beispielsweise kann das Verfahren 110 von einer Graphikverarbeitungseinheit (GPU), einer zentralen Verarbeitungseinheit (CPU) oder einem beliebigen Prozessor ausgeführt werden. Des Weiteren werden Fachleute verstehen, dass jedes System, welches das Verfahren 110 durchführt, innerhalb des Umfangs und Wesens von Ausführungsformen der vorliegenden Erfindung ist.
• Bei Schritt 112 projiziert die Verarbeitungseinheit Strahlen von einem Blickpunkt, der vor einem SLM positioniert ist, auf eine Abschneideebene, die hinter dem SLM positioniert ist, um einen elementaren Betrachtungsstumpf innerhalb einer 3D-Szene zu bilden. Allgemeiner gesagt, kann der Blickpunkt an einer ersten Seite des SLM positioniert werden und die Abschneideebene kann an einer gegenüberliegenden Seite des SLM positioniert werden. In einer Ausführungsform ist der Blickpunkt auf der Seite des Beobachters des SLM positioniert und die nahe Abschneideebene ist auf der gegenüberliegenden Seite (entgegengesetzte Seite relativ zu dem Beobachter) des SLM positioniert. In einer Ausführungsform ist die nahe Abschneideebene koinzident mit der Oberfläche des SLM lokalisiert. In einer Ausführungsform ist der SLM mit einer Anordnung von nichtüberlappenden Elementarbereichen gekachelt und ein oberen Rand und ein unterer Rand eines ersten Elementarbereichs der nichtüberlappenden Elementarbereiche werden von den Strahlen geschnitten, um den elementaren Betrachtungsstumpf zu bilden.
• Bei Schritt 114 rendert die Verarbeitungseinheit Objekte innerhalb des elementaren Betrachtungsstumpfs, um Komponenten eines ersten Elementarbildes für den ersten Elementarbereich zu erzeugen. In einer Ausführungsform umfasst das Lichtfeld das erste Elementarbild und zusätzliche Elementarbilder, die der Anordnung von Elementarbereichen entsprechen, und jeweils eines der zusätzlichen Elementarbilder wird unter Verwendung eines zusätzlichen elementaren Betrachtungsstumpfs gerendert.
• Bei Schritt 116 berechnet die Verarbeitungseinheit Phasen- und Amplitudenkomponenten zum Antreiben des SLM als ein Produkt einer Objektwelle und einer konjugierten Bezugswelle. Des Weiteren können die Komponenten Farbe und Position innerhalb der 3D-Szene umfassen. In einer Ausführungsform umfasst die konjugierte Bezugswelle eine Planwellenbeleuchtungsquelle. In einer weiteren Ausführungsform umfasst die konjugierte Bezugswelle eine Kugelwellenbeleuchtungsquelle. In anderen Ausführungsformen umfasst die konjugierte Bezugswelle eine beliebige Beleuchtungsquelle.
• In einer Ausführungsform umfasst, für jedes Pixel des SLM innerhalb des ersten Elementarbereichs, das Rendering ein Projizieren zweiter Strahlen von dem Pixel des SLM zu der Abschneideebene, um einen Pixelbeugungskegel zu definieren, der eine Basis einer ersten Breite aufweist, und Entfernen eines Abschnitts der Komponenten des ersten Elementarbilds, die außerhalb des Pixelbeugungskegels sind, um Ambiguitätssegmentaussonderung durchzuführen.
• 1B veranschaulicht ein Ablaufdiagramm eines Verfahrens 120 zum Rendering von Objekten innerhalb des elementaren Betrachtungsstumpfs gemäß einer Ausführungsform. Obwohl das Verfahren 120 im Kontext einer Verarbeitungseinheit beschrieben wird, kann das Verfahren 120 ebenfalls von einem Programm, kundenspezifische Schaltungen oder von einer Kombination von kundenspezifischen Schaltungen und ein Programm durchgeführt werden. Beispielsweise kann das Verfahren 120 durch eine GPU, eine CPU oder jedem anderen, technisch möglichen Prozessor ausgeführt werden. Des Weiteren werden Fachleute verstehen, dass jedes System, welches das Verfahren 120 durchführt, innerhalb des Umfangs und Wesens von Ausführungsformen der vorliegenden Erfindung ist. Wie in 1B gezeigt, umfasst in einer Ausführungsform Schritt 114 des Verfahrens 110 die Schritte 122 und 124.
• Bei Schritt 122 projiziert die Verarbeitungseinheit zweite Strahlen von dem Pixel des SLM zu der Abschneideebene, um einen Pixelbeugungskegel zu definieren, der eine Basis einer ersten Breite aufweist. Bei Schritt 124 entfernt die Verarbeitungseinheit einen Abschnitt der Komponenten des ersten Elementarbildes, die außerhalb des Pixelbeugungskegels sind. In einer Ausführungsform wird eine Ambiguitätssegmentaussonderung mittels Entfernen des Abschnitts von Komponenten außerhalb des Pixelbeugungskegels durchgeführt.
• Die Verfahren 110 und 120 können im Kontext von computererzeugter Holographie (CGH) zum Erzeugen von Lichtfelddaten durchgeführt werden, die verwendet werden, um eine SLM-Vorrichtung anzutreiben. Eine Beschreibung von CGH wird nun zusammen mit Implementierungseinzelheiten dargelegt, die für verschiedene Ausführungsformen relevant sind.
• 1C veranschaulicht eine computererzeugte Holographie (CGH = computer generated holography) gemäß einer Ausführungsform. Wie gezeigt, wird ein Rendering-Blickpunkt durch eine virtuelle Kamera 142 angegeben, die positioniert ist, um ein Szenenobjekt 140 durch ein SLM 144 zu betrachten. Ein Punkt j wird auf dem Szenenobjekt 140 gezeigt und ein Abstand r trennt Punkt j von einem Pixelort x auf dem SLM 144.
• Im Allgemeinen wandelt ein Hologramm eine Eingangsbezugslichtwelle E_R(x) in eine passende Ausgangsobjektlichtwelle E₀(x) um. Bei der CGH erfordert das Erzeugen der Ausgabeobjektlichtwelle Kenntnis von sowohl der Bezugslichtwelle als auch der Objektlichtwelle. Die Form der Bezugslichtwelle kann gegeben und verschiedene CGH-Techniken können angewendet werden, um ein Beugungsmuster zu berechnen, das die Objektlichtwelle an jedem Ort auf dem SLM 144 ergeben wird. Ein Beugungsmuster kann für jeden Ort basierend auf einer gewünschten Ausgangswellenform für den Ort auf dem SLM 144 berechnet werden. Um eine gegebene Ausgangswellenform zu berechnen, die von dem Szenenobjekt 140 resultiert, wird Licht rückwärts in Richtung des SLM 144 unter Verwendung eines Fresnelschen Beugungsintegrals ausgebreitet. Für ein Szenenobjekt 140, das diskrete Punkte j umfasst, kann eine Summation von Kugelwellen, die von den Punkten j herrühren, anstelle eines Beugungsintegrals arbeiten. Eine derartige Summation wird durch Gleichung 1 berechnet. $${\text{E}}_{\text{O}}\left(\text{x}\right)={\displaystyle \sum {}_{\text{j}}\frac{{\text{A}}_{\text{j}}}{{\text{r}}_{\text{j}}\left(\text{x}\right)}{\text{e}}^{\text{i}\left(\frac{2\mathrm{\pi }}{\mathrm{\lambda }}{\text{r}}_{\text{j}}\left(\text{x}\right)+{\mathrm{\varphi }}_{\text{j}}\right)}}$$

  
• In Gleichung 1 ist λ die Wellenlänge einer monochromatischen Lichtquelle, A_j ist die Amplitude des Punkts j auf dem Szenenobjekt 140 und r_j(x) ist der euklidische Abstand von dem Punkt j zu einem Pixelort x auf dem SLM 144 zu einem gegebenen Punkt j auf dem Szenenobjekt 140. Des Weiteren ist Φ_j eine zufällige Anfangsphase, die jedem Punkt j zugeordnet ist.
• Das resultierende elektrische Feld E_O(x) ist komplexwertig. In CGH wird eine entsprechende Beleuchtungs-Wellenfront durch Multiplizieren des resultierenden elektrischen Felds mit einem passenden Beleuchtungsfeld erzeugt. Beispielsweise wird bei der Planwellen-Beleuchtung (Beleuchtung mit kollimiertem Strahl) das resultierende elektrische Feld mit einer Konstante (z.B. 1) multipliziert. Für Kugelwellenbeleuchtung kann das elektrische Feld mit einem komplexen Exponential mit einer quadratischen Phase multipliziert werden, um die quadratische Phase einer Kugelbezugswelle zu beseitigen. Ein Anzeigen eines korrekten Beugungsmusters auf dem SLM 144 wird durch räumliches Variieren von sowohl der Amplitude als auch von Phasenverzögerungen gemäß einem resultierenden Produkt bereitgestellt.
• In einer Ausführungsform startet eine CGH-Rendering- und Anzeige-Pipeline mit einem polygonbasierten holographischen Lichtfeld-Rendering und umfasst eine punktbasierte Vorgehensweise (d.h., Summation von propagierenden Feldern von Punkten auf dem Szenenobjekt 140) mit lokaler Partitionierung für blickabhängige Wirkung. Eine Verdeckung wird durch die Pipeline unter Verwendung eines z-Puffers gehandhabt. Abgetastete Fragmente ermöglichen eine parallele full-parallax CGH-Berechnung auf einer GPU bei interaktiver Geschwindigkeit mit hochauflösender (z.B. 1080p) Bildqualität. In bestimmten Ausführungsformen umfasst eine CGH-Rendering-Pipeline eine Polygonoberflächen-Vorgehensweise (d.h., Summation von propagierenden Feldern von sichtbaren Polygonoberflächen, die das Szenenobjekt 140 umfassen), die unabhängig oder in Verbindung mit der punktbasierten Vorgehensweise arbeiten kann. Jede technisch machbare Technik kann durchgeführt werden, um Felder der Polygonoberflächen bei unterschiedlichen Pixeln des SLM 144 zu berechnen. Des Weiteren werden Fachleute verstehen, obwohl verschiedene hier gelehrte Techniken mit Bezugnahme auf Punkte auf einem Szenenobjekt beschrieben werden, dass die Techniken auf Vielecke und/oder beliebige Formen oder Oberflächen angewendet werden können, ohne vom Umfang und Wesen verschiedener Ausführungsformen abzuweichen.
• Ein Rendering eines vollen Lichtfelds erzeugt hoch überlappende Ansichten für benachbarte Hologrammpixel und führt herkömmlicherweise zu einer signifikanten Rechenredundanz. Beispielsweise erfordert bei einer punktbasierten Vorgehensweise das herkömmliche Rendering ein sequentielles Abtasten der Szene, um Wellenfronten zu akkumulieren, die von tiefensortierten Szenenpunkten emittiert werden. Eine derartige Operation entspricht dem Hinzufügen dicht abgetasteter Winkelansichten bei herkömmlichen Lichtfeld-Rendering, eine Vorgehensweise, die in der Technik bekannt ist, für Echtzeit-Graphiken unpraktisch zu sein.
• Unter der Annahme von Lambertschen Oberflächen für das Szenenobjekt 140 ist jedoch eine einzige Aufzeichnung von jedem Punkt ausreichend, um die Wellenfront zu bestimmen. Wenn diese Beobachtung wirksam eingesetzt wird, kann ein Hologramm räumlich in aneinanderstoßende Gitter partioniert werden, wobei ein einzelnes Gitter hier als ein in 1D veranschaulichtes holographisches Element (Hogel) bezeichnet wird.
• 1D veranschaulicht ein holographisches Element gemäß einer Ausführungsform. Wie gezeigt, umfasst eine Farbenintensitätskarte ein aneinanderstoßendes Gitter von Elementarbildern. Jedes Elementarbild umfasst eine einzelne repräsentative Ansicht einer 3D-Szene. Eine Ort- und Tiefenkarte umfasst ein entsprechendes Gitter von Tiefeninformation für die Elementarbilder. Ein gegebenes Elementarbild wird gerendert und verwendet, um jedes Hogel unter der Annahme zu berechnen, dass alle erfassten Punkte allen Pixeln in dem Hogel sichtbar sind. In einer Ausführungsform weist jedes Hogel eine geordnete Phasenkarte und eine geordnete Amplitudenkarte auf. Die Phasenkarte und die Amplitudenkarte können basierend auf der Farbenintensitätskarte und der Ort- und Tiefenkarte berechnet werden.
• Eine monokulare Verdeckungsparallaxe wird durch die Hogelgröße (w_h) innerhalb eines Augapfels begrenzt. In einer Ausführungsform ist ein Augapfel ein Bereich an einer Augenposition des Benutzers, die ausreichend groß ist, um einem Auge des Benutzers zu ermöglichen, sich frei zu bewegen, während dem Benutzer (Betrachter) ermöglicht wird, die gesamte 3D-Szene zu sehen, die durch den SLM 144 anschaulich dargestellt wird (z.B., alle Punkte auf dem Szenenobjekt 140). Eine Näherung einer vollständigen holographischen Lichtfeldanzeige als ein Gitter von Hogeln verringert Rendering-Durchläufe und Rechenaufwand wesentlich, was herkömmlichen GPU-Systemen ermöglicht, Echtzeit-Rendering-Anwendungen zu unterstützen. Herkömmliches Hogel-Rendering projiziert jedoch zu einer gegebenen Hogelmitte, wodurch es misslingt, ein Pro-Pixel-Beugungskegelsammlung zu rendern und herkömmliches Hogel-Rendering kann in Kugelbeleuchtungsszenarien schlecht skalieren.
• 2A veranschaulicht ein herkömmliches Hogel-Rendering gemäß dem Stand der Technik. Wie gezeigt, umfasst eine Renderingkonfiguration 200 eine virtuelle Kamera 210, die in der Mitte eines Hogels 218 positioniert ist, das innerhalb eines SLM 203 umfasst ist. Die virtuelle Kamera 210 ist auf eine zu rendernde Szene gerichtet. Die Position der virtuellen Kamera 210 führt zu einem herkömmlichen Betrachtungsstumpf 212, der nur ein genaues Rendering für Pixel bereitstellt, die innerhalb des Hogels zentriert sind. 218. In Hogel-Rendering-Systemen des Standes der Technik wird der herkömmliche Betrachtungsstumpf 212 zum Rendering all Pixel in dem Hogel 218 verwendet, weil die virtuelle Kamera 210 in der Mitte des Hogels 218 statisch positioniert ist. Folglich wird für ein Bodenpixel in dem Hogel 218 ein Bereich 215 in dem Pixel während des Rendering fehlerhafterweise aufgenommen, während ein Bereich 217 von dem Pixel während des Rendering fälschlicherweise ausgeschlossen wird. Um das Bodenpixel in dem Hogel 218 genau zu rendern, sollte der Betrachtungsstumpf 216 verwendet werden. Auf ähnliche Weise sollte der Betrachtungsstumpf 214 verwendet werden, um das Spitzenpixel in dem Hogel 218 genau zu rendern.
• Wie gezeigt, weisen die Hogel 218, 219 auf dem SLM 203 eine Hogelgröße w_h auf. Des Weiteren ist eine nahe Abschneideebene 204 einen Abstand d₁ von dem SLM 203 positioniert und eine ferne Abschneideebene 206 ist einen Abstand d₂ von dem SLM 203 positioniert. Die Hogelgröße w_h stellt eine Tiefengrenze von z ≤ d_min an Szenenobjekten und der nahen Abschneideebene 204 ein, um geometrisches Abschneiden zu verhindern. In bestimmten Szenarien verringert diese Tiefengrenze zusammen mit potentiellem geometrischen Abschneiden ungenaue Propixel-Beugungskegelerfassung und/oder zusätzliche Einschränkungen von herkömmlichem Hogel-Rendering den Komfort und die Qualität einer Benutzererfahrung.
• 2B veranschaulicht ein Hogel-Rendering mit Planwellen-Beleuchtung gemäß einer Ausführungsform. Wie gezeigt, umfasst eine Renderingkonfiguration 220 eine virtuelle Kamera 230, die an einem lateralen Versatz d_CZ entlang der Z(Tiefen)-Achse mit Bezug auf ein SLM 223 positioniert ist. Im Gegensatz dazu ist mit herkömmlichen Techniken, wie in 2A gezeigt, wobei die virtuelle Kamera 210 an einem lateralen Versatz von Null positioniert ist, der laterale Versatz d_CZ größer als Null. Die virtuelle Kamera 230 ist auf eine zu rendernde Szene gerichtet, die eine nahe Abschneideebene 224 und eine ferne Abschneideebene 226 umfasst. Die Position der virtuellen Kamera 230 führt zu einem Betrachtungsstumpf 232, der mindestens ein Hogel 238 auf dem SLM 223 schneidet. Hogel 238, 239 auf dem SLM 223 weisen eine Hogelgröße w_h auf. Die nahe Abschneideebene 224 ist an einem Abstand d₁ von dem SLM 223 positioniert und die ferne Abschneideebene 226 ist an einem Abstand d₂ von dem SLM 203 positioniert. Der laterale Versatz d_CZ kann gleich einer Tiefengrenze von z ≤ d_min relativ zu Szenenobjekten und der nahen Abschneideebene 224 sein. In einer Ausführungsform wird der laterale Versatz gemäß Gleichung 2 berechnet: $${\text{d}}_{\text{CZ}}={\text{d}}_{\text{min}}=\frac{{\text{w}}_{\text{h}}}{2\text{tan}\left({\text{sin}}^{-1}\left(\frac{\mathrm{\lambda }}{2\Delta \text{p}}\right)\right)}$$

  
• In Gleichung 2 ist Δp eine Pixelrastergröße für den SLM 223 und X ist die Wellenlänge einer monochromatischen Lichtquelle, wie beispielsweise einer Lichtquelle, die zum Rendering verwendet wird. Wie gezeigt, erlaubt die Versatzposition der virtuellen Kamera 230 dem gesamten sichtbaren Bereich für den Betrachtungsstumpf 232 gerendert zu werden. Dieser sichtbare Bereich wird durch w₁ angegeben und durch Gleichung 3 berechnet: $${\text{w}}_1=2{\text{sin}}^{-1}\left(\raisebox{1ex}{$\mathrm{\lambda }$}\!\left/ \!\raisebox{-1ex}{$2\Delta \text{p}$}\right.\right)\left({\text{d}}_1+{\text{d}}_{\text{CZ}}\right)$$

  
• In einer Ausführungsform schneidet der Betrachtungsstumpf 232 den Rand des Hogels 238 und die nahe Abschneideebene 224 mit einem Maß von w₁. Des Weiteren kann jedes Pixel in dem SLM 223 unter Verwendung von lediglich einem gültigen Beugungskegel erzeugt werden, der durch eine Projektion 234 begrenzt wird. Eine Pro-Pixel-Perspektive kann durch Ausrichten des Beugungskegels in der fernen Abschneideebene 226 mit einem Schiebefenster erhalten werden, das durch w₃ definiert wird. Das Schiebefenster (w₃) kann gemäß Gleichung 4 berechnet werden: $${\text{w}}_3=\left(1-\frac{{\text{d}}_{\text{CZ}}}{{\text{d}}_1+{\text{d}}_{\text{CZ}}}\right){\text{w}}_1$$

  
• Eine Beugungs-Aussonderung kann an einem in 2C veranschaulichten Ambiguitätssegment verwendet werden, das einen Bereich 240 ausführlich zeigt, um ein genaueres Rendering bereitzustellen. Die Beugungs-Aussonderung kann ohne Einschränkung das Entfernen bestimmter abgedeckter Szenenobjektgeometrie umfassen, die einem Ambiguitätssegment zugeordnet sind, das zu einem gegebenen Pixel auf dem SLM 223 beiträgt. Der Ambiguitätsbereich kann durch Erweitern des Schiebefensters auf w₂ erhalten werden, wie in Gleichung 5 berechnet. Des Weiteren begrenzen w₃ und w₂ die Projektion 234. $${\text{w}}_2=\left(1-\frac{{\text{d}}_{\text{CZ}}}{{\text{d}}_2+{\text{d}}_{\text{CZ}}}\right){\text{w}}_1$$

  
• Ein Anrichten einer Anordnung von virtuellen Kameras 230 (z.B., einer virtuellen Kamera pro elementarer Ansicht oder Elementarbereich) gemäß der offenbarten Konfiguration ermöglicht eine uneingeschränkte Disposition von Szenenobjekten. Der laterale Versatz d_CZ gewährleistet, dass benachbarte Kameraansichten direkt vor dem SLM 223 überlappen und eine resultierende gekachelte Kegelstumpfanordnung das Blickfeld des gesamten Hologramms (der gesamtem 3D-Szene) vollständig überdeckt. Dies erlaubt der nahen Abschneideebene 224 bei einer beliebigen Tiefe vor dem SLM 223 eingestellt zu werden.
• 2C veranschaulicht einen Bereich 240 eines Ambiguitätssegments 242 gemäß einer Ausführungsform. Die Projektion 234 schneidet die nahe Abschneideebene 224 und die ferne Abschneideebene 226. Die Projektion 234 kann einen Pixelbeugungskegel mit einer Basis einer bestimmten Breite definieren. Des Weiteren kann die Projektion 234 einen (innerhalb der Breite) umfassten Bereich 245 schneiden, der beim Rendering eines geordneten Pixels auf dem SLM 223 umfasst sein sollte, und einen ausgeschlossenen Bereich 244 (außerhalb der Breite), der vom Rendering des Pixels ausgeschlossen sein sollte. Komponenten außerhalb des Pixelbeugungskegels können als Teil des Rendering eines oder mehrerer Pixel innerhalb des Pixelbeugungskegels entfernt werden.
• 2D veranschaulicht ein Hogel-Rendering mit Kugelwellenbeleuchtung gemäß einer Ausführungsform. Wie gezeigt, umfasst eine Renderingkonfiguration 250 eine virtuelle Kamera 260, die an einem lateralen Versatz d_CZ entlang der Z(Tiefen)-Achse mit Bezug auf ein SLM 263 positioniert ist. Die virtuelle Kamera 260 ist auf eine Szene gerichtet, um gerendert zu werden, die eine nahe Abschneideebene 254 und eine ferne Abschneideebene 256 umfasst. Die Position der virtuellen Kamera 260 führt zu einem Betrachtungsstumpf 262, der mindestens das Hogel 268 auf dem SLM 263 schneidet. Hogel 268, 269 auf dem SLM 263 weisen eine Hogelgröße w_h. Auf. Die nahe Abschneideebene 254 ist ein Abstand d₃ entlang der Z-Achse der virtuellen Kamera 260 positioniert und die ferne Abschneideebene 256 ist ein Abstand d₄ entlang der Z-Achse der virtuellen Kamera 260 positioniert. Ein Benutzerauge 261 ist einen Abstand d_F entlang der Z-Achse von dem SLM 263 positioniert. Wie gezeigt, wird ein Augapfel gezeigt, der größenmäßig gleich w_e ist. In einer Ausführungsform ist eine Projektion des Betrachtungsstumpfs 262 durch die virtuelle Kamera 260 mindestens so groß wie der Augapfel.
• In verschiedenen Ausführungsformen, die eine Kugelbeleuchtung implementieren, kann der Betrachtungsstumpf 262 (and andere Betrachtungsstümpfe, die einer Anordnung von virtuellen Kameras oder Kamerapositionen zugeordnet sind) eine räumlich variierende Transformation erfahren, weil Kugelbeleuchtungs-Wellenfronten Krümmung und eine außeraxiale Drehung auf eine lokalen einfallende Strahlrichtung eines Beugungskegels für eine gegebenen Position der virtuellen Kamera 260 einführen. Derartige Beugungskegel verbreitern zusammen das Blickfeld eines gegebenen Hogels.
• Eine Erweiterung der Renderingkonfiguration 220 von 2C auf eine Renderingkonfiguration 250 für Kugelbeleuchtung stellt die virtuelle Kamera 260 an dem Schnittpunkt von Randstrahlen ein, die durch den Augapfel eingeschränkt werde, und verdreht das verfügbare Blickfeld. In einer Ausführungsform wird der laterale Versatz d_CZ der virtuellen Kamera 260 relativ zu der Position des SLM 263 durch Gleichung 6 gegeben: $${\text{d}}_{\text{CZ}}=\frac{{\text{d}}_{\text{F}}{\text{w}}_{\text{h}}}{{\text{w}}_{\text{w}}\left({\text{d}}_{\text{F}}\right)+{\text{w}}_{\text{h}}}$$

  
• Ein Versatz zwischen einer Mittelansicht der virtuellen Kamera 260 und einer Hogelmitte entlang der X-Achse und Y-Achse hängt von der Position des Hogels relativ zu dem Augapfel ab. Unter der Annahme einer 2m + 1 mal 2n + 1 Partitionierung des SLM 263 entlang der X-Achse bzw. Y-Achse wird die Verschiebung einer (m,n)-ten Hogelmitte zu einer entsprechenden virtuellen Kamera durch Gleichungen 7 und 8 gegeben: $${\text{d}}_{\text{CX}}=\frac{{\text{mw}}_{\text{h}}{\text{d}}_{\text{CZ}}}{{\text{d}}_{\text{F}}}$$

  

  $${\text{d}}_{\text{CY}}=\frac{{\text{mw}}_{\text{h}}{\text{d}}_{\text{CZ}}}{{\text{d}}_{\text{F}}}$$

  
• Wie gezeigt, ist die Verschiebung d_CY eine Verschiebung entlang der Y-Achse von der Mitte des Hogels 268 zu der Mitte der Ansicht für die virtuelle Kamera 260. Im Kameraraum wird eine passende achsenversetzte Projektionsmatrix durch Gleichung 9 definiert: $${\text{P}}_{\left\{\text{m},\text{n}\right\}}=\left[\begin{array}{cccc}\frac{2{\text{d}}_{\text{CZ}}}{{\text{w}}_{\text{h}}}& 0& \frac{2{\text{d}}_{\text{CX}}}{{\text{w}}_{\text{h}}}& 0\\ 0& \frac{2{\text{d}}_{\text{CZ}}}{{\text{w}}_{\text{h}}}& \frac{2{\text{d}}_{\text{CY}}}{{\text{w}}_{\text{h}}}& 0\\ 0& 0& -\frac{{\text{d}}_4+{\text{d}}_3}{{\text{d}}_4-{\text{d}}_3}& -\frac{2{\text{d}}_4{\text{d}}_3}{{\text{d}}_4-{\text{d}}_3}\\ 0& 0& -1& 0\end{array}\right]$$

  
• Ein Schiebefenster w₂ innerhalb jedes Elementarbildes kann verwendet werden, um ein projiziertes Pixel eindeutig zu machen, wobei w₂ gemäß Gleichung 10 berechnet wird: $${\text{w}}_2=\left(1-\frac{{\text{d}}_{\text{CZ}}\left({\text{d}}_4+{\text{d}}_{\text{F}}-{\text{d}}_{\text{CZ}}\right)}{{\text{d}}_4{\text{d}}_{\text{F}}}\right){\text{w}}_1$$

  
• Eine Beugungs-Aussonderung kann auf einem Ambiguitätssegment verwendet werden, das in 2E veranschaulicht wird, die ein Detail des Bereiches 270 zeigt, um ein genaueres Rendering bereitzustellen. Die Beugungs-Aussonderung kann ohne Einschränkung ein Entfernen von einem Ambiguitätssegment zugeordneter, bestimmter abgedeckter Szenenobjektgeometrie, die zu einem gegebenen Pixel auf dem SLM 263 beiträgt, umfassen.
• Ein Bruchteil eines fehlerfreien Segments innerhalb des Schiebefensters kann verwendet werden, um eine Hogelgröße herzuleiten, die erforderlich ist, um einen annehmbaren Abtastfehler zu erhalten. Gleichung 11: $$\frac{{\text{w}}_3}{{\text{w}}_2}=1-\frac{\left({\text{d}}_4-{\text{d}}_3\right){\text{d}}_{\text{CZ}}}{{\text{d}}_{3\left({\text{d}}_4-{\text{d}}_{\text{CZ}}\right)}}$$

  
• Die Hogelgröße kann eine signifikante Auswirkung auf die visuelle Qualität sowie auch auf den Rechenaufwand aufweisen. In einem extremen Fall von Hogelgröße ist ein Hogel ein Pixel innerhalb des SLM 263. In diesem ersten Fall expandiert das holographische Lichtfeld-Rendering auf volles Lichtfeld-Rendering, was unpraktisch sein kann. In einem weiteren extremen Fall von Hogelgröße erstreckt sich ein Hogel auf die gesamte Größe des SLM 263. In diesem zweiten Fall weicht das gerenderte Lichtfeld in eine einzige Abbildung von Punkten zurück, die von dem nächsten Abstand gerendert werden, wobei der SLM 263 für einen Betrachter (z.B., ein Benutzer) vollständig beobachtbar ist. In einem praktischen Szenario wird die Hogelgröße zwischen diesen beiden Extremen ausgewählt, wie weiter in Verbindung mit 2G erläutert.
• In einem holographischen Lichtfeld erleichtert eine Eins-zu-eins-Abbildung zwischen einem Hogel auf einem SLM und einem entsprechenden sichtbaren Elementarbild, wie in 1D gezeigt, eine parallele Berechnung unter Verwendung eines punktbasierten Verfahrens für Fresnel-Integration (d.h., Summation). Beispielsweise kann die Lichtfeldberechnung wie eine parallele Operation auf Pixeln fortfahren, die ein Hogel, eine parallele Operation an unterschiedlichen virtuellen Kameraansichten oder eine Kombination davon umfassen. Des Weiteren kann eine parallele Operation auf Pixeln umfassen parallele Berechnung von Summationstermen umfassen, die Fresnelsche Integration/Summation umfassen. In einer Ausführungsform kann eine Parallelverarbeitungseinheit, wie beispielsweise die in 3 gezeigte PPU 300, verwendet werden, um die parallelen Berechnungen durchzuführen.
• 2E veranschaulicht einen Bereich 270 eines Ambiguitätssegments 272 gemäß einer Ausführungsform. Eine Projektion 264 schneidet nahe Abschneideebene 254 und ferne Abschneideebene 256. Die Projektion 264 kann einen Pixelbeugungskegel mit einer Basis einer bestimmten Breite definieren. Des Weiteren kann die Projektion 264 einen (innerhalb der Breite) umfassten Bereich 275 schneiden, der beim Rendering eines geordneten Pixels auf dem SLM 263 eingeschlossenen werden sollte, und einen ausgeschlossenen Bereich 274 (außerhalb der Breite), der vom Rendering des Pixel ausgeschlossen werden sollte. Komponenten außerhalb des Pixelbeugungskegels können als Teil des Rendering eines oder mehrerer Pixel innerhalb des Pixelbeugungskegels entfernt werden.
• 2F veranschaulicht algorithmische Operationen eines Verfahrens zum Rendering eines Lichtfeldes unter Verwendung einer Kugelbeleuchtung gemäß einer Ausführungsform. In den algorithmischen Operationen bezeichnet p ein SLM-Pixel in dem (m,n)-ten Hogel an einer Verschiebung (Δx,Δy) zu der Hogelmitte. Eine CGH-Randbereichsberechnung für E(p) von jedem SLM-Pixel unter Kugelbeleuchtung multipliziert die Objektwelle E_o(p) mit einer konjugierten Bezugswelle ${\text{E}}_{\text{R}}^{*}\left(\text{p}\right).$

  

  Eine Position q ist auf einem zu rendernden Szenenobjekt lokalisiert, wobei die Position durch einen Index j gekennzeichnet wird. In einem geordneten virtuellen Kameraraum unter Kugelbeleuchtung wird die räumliche Koordinate von p's durch (Δx + d_CX, Δy + d_CY, -d_CZ) gegeben. In einer Ausführungsform ist die geschätzte Ansicht von p's ein Schiebefenster von k × k Pixeln. Des Weiteren ist q_j das elementare Pixel mit einem gerenderten Punkt, der bei (x_qj , y_qj , z_qj ) lokalisiert ist, einer Amplitude A_qj und einer Anfangsphase ϕ_qj . Diese Berechnung basierend auf Gleichung 1 und wird ausführlich in Gleichungen 12-16 gezeigt. $$\text{E}\left(\text{p}\right)={\text{E}}_{\text{o}}\left(\text{p}\right)\cdot {\text{E}}_{\text{R}}^{*}\left(\text{p}\right)$$

  
• In Gleichung 12 kann E_o(p) gemäß Gleichung 13 berechnet werden: $${\text{E}}_{\text{o}}\left(\text{p}\right)=\left({\displaystyle {\sum }_{\text{j}=1}^{{\text{k}}^2}\frac{{\text{A}}_{{\text{q}}_{\text{j}}}}{r\left(\text{p},{\text{a}}_{\text{j}}\right)}}{\text{e}}^{\text{i}2\mathrm{\pi }\frac{\text{r}\left(\text{p},{\text{q}}_{\text{j}}\right)}{\mathrm{\lambda }}+{\mathrm{\varphi }}_{{\text{q}}_{\text{j}}}}\right)$$

  
• Des Weiteren kann ${\text{E}}_{\text{R}}^{*}\left(\text{p}\right)$

  

  gemäß Gleichung 14 berechnet werden: $${\text{E}}_{\text{R}}^{*}\left(\text{p}\right)=\left(\frac{{\text{A}}_{\text{F}}}{\text{r}\left(\text{p},\text{F}\right)}{\text{e}}^{\text{i}2\mathrm{\pi }\frac{\text{r}\left(\text{p},\text{F}\right)}{\mathrm{\lambda }}}\right)$$

  
• Euklidische Abstände r(p, q_j) und r(p, F) können gemäß Gleichungen 15 bzw. 16 berechnet werden: $$\text{r}\left(\text{p},{\text{q}}_{\text{j}}\right)=\sqrt{{\left({\text{x}}_{{\text{q}}_{\text{j}}}-\mathrm{\Delta }\text{x}-{\text{d}}_{\text{CX}}\right)}^2+{\left({\text{y}}_{{\text{q}}_{\text{j}}}-\mathrm{\Delta }\text{y}-{\text{d}}_{\text{CY}}\right)}^2+{\left({\text{z}}_{{\text{q}}_{\text{j}}}+{\text{d}}_{\text{CZ}}\right)}^2}$$

  

  $$\text{r}\left(\text{p},\text{F}\right)=\sqrt{{\left({\text{d}}_{\text{F}}\right)}^2+{\left({\text{mw}}_{\text{h}}+\mathrm{\Delta }\text{x}\right)}^2+{\left({\text{nw}}_{\text{h}}+\mathrm{\Delta }\text{y}\right)}^2}$$

  
• In Schritten 1-4 von 2F wird i als ein Pixelindex für ein Pixel innerhalb eines SLM (z.B., SLM 263) definiert und eine Teilmenge von Pixeln wird gekennzeichnet, als innerhalb eines Hogels zu sein. Pixeln innerhalb eines Schiebefensters für das Hogel werden ein Index j gegeben. A für Schleife bei Schritt 5 wird konfiguriert, um über Pixel innerhalb des Schiebefensters zu iterieren, um einen Feldwert für jedes Pixel zu berechnen. Eine Wellenfrontphase (ϕ) von einem Punkt q zu einem Pixel innerhalb des SLM wird bei Schritt 8 berechnet, während eine Amplitude (A) für die Wellenfront bei Schritt 9 berechnet wird. Eine Feldsummation von Gleichung 12 wird bei Schritt 11 abgeschlossen.
• 2G veranschaulicht einen Vergleich von Elementarbildauflösungsergebnissen gemäß einer Ausführungsform. Eine Winkelabtastrate (Pixel pro beobachteten Grad) wird verändert, wobei Bild (a) eine Winkelabtastrate von 6 aufweist, Bild (b) eine Winkelabtastrate von 18 aufweist, Bild (c) eine Winkelabtastrate von 30 aufweist und Bild (d) eine Winkelabtastrate von 45 aufweist. Ein Einsatz (links unten) von jedem Bild stellt das gerenderte Elementarbild mit verändernder Auflösung anschaulich dar, die eine entsprechende Winkelabtastrate aufweist, während ein Detail (rechts oben) Rekonstruktionen bei der entsprechenden Winkelabtastrate veranschaulicht. Rekonstruktionen niedrigerer Auflösung (obere Reihe von Bildern) zeigen offensichtliches Aliasing; wobei jedoch Rekonstruktionen höherer Auflösung (untere Reihe von Bildern) ein glattes Erscheinungsbild ohne offensichtliche Anzeichen von Aliasing aufweisen. Im Allgemeinen stellt eine Winkelabtastrate oberhalb 30 Pixel pro Grad eine gute Näherung mit wenig bemerkbarem Aliasing bereit. Folglich wird in einer Ausführungsform eine Winkelabtastrate oberhalb 30 Pixel pro Grad implementiert.
• Obwohl eine kleine Hogelgröße (w_h) und eine dichte Partitionierung die Anzahl von benötigten gerenderten Ansichten erhöht, verringert eine kleinere Hogelgröße ebenfalls Ambiguitätsbereiche und erzeugt genauere Perspektiven zur intraokkularen Abdeckung. Ein Ausgleich kann zwischen konkurrierenden Parametern durch Auswerten der Hogelgröße basierend auf einem Verhältnis zwischen einem fehlerfreien Segment und einem genäherten Schiebefenster erreicht werden. In einer Ausführungsform der SLM umfasst eine Auflösung von 3840x2160 und w_h ≈ 1mm. Diese Konfiguration kann einen Ambiguitätsbereich von weniger als 0,16% für eine zweidimensionale Ansicht mit einer 16x9 Hogel-Partitionierung erzeugen. Es sei bemerkt, dass ein größeres Pixelraster eine dichtere Hogel-Partitionierung erfordern kann.
• 2H veranschaulicht ein Ablaufdiagramm eines Verfahrens 280 zum Rendering eines Lichtfeldes gemäß einer Ausführungsform. Obwohl das Verfahren 280 im Kontext einer Verarbeitungseinheit beschrieben wird, kann das Verfahren 280 ebenfalls von einem Programm, kundenspezifischen Schaltungen oder von einer Kombination von kundenspezifischen Schaltungen und ein Programm durchgeführt werden. Beispielsweise kann das Verfahren 280 durch eine GPU, eine CPU oder einem beliebigen anderen, technisch möglichen Prozessor ausgeführt werden. Des Weiteren werden Fachleute verstehen, dass jedes System, welches das Verfahren 280 durchführt, innerhalb des Umfangs und Wesens von Ausführungsformen der vorliegenden Erfindung ist.
• Bei Schritt 282 berechnet die Verarbeitungseinheit einen lateralen Versatz (z.B., d_CZ) zwischen einer Blickposition und einem SLM (z.B., SLM 223, SLM 263) basierend auf einer Größe des SLM und einer Breite eines holographischen Elements (Hogel). In einer Ausführungsform spezifiziert die Blickposition eine Blickposition für eine virtuelle Kamera (z.B., virtuelle Kamera 230, virtuelle Kamera 260). Des Weiteren deckt in einer Ausführungsform eine Anordnung von Hogeln eine Oberfläche des SLM ab. Bei Schritt 284 rendert die Verarbeitungseinheit eine dreidimensionale Szene von der Blickposition, um ein Elementarbild zu erzeugen, das innerhalb einer Anordnung von Elementarbildern umfasst ist. Die Verarbeitungseinheit kann jedes Elementarbild innerhalb der Anordnung von Elementarbildern rendern. In einer Ausführungsform umfasst die Anordnung von Elementarbildern eine entsprechende Anordnung von Tiefenkarten (z.B., zusammen mit den Elementarbildern gerendert). Eine Phasenkarte und eine Amplitudenkarte werden dann von den Elementarbildern und den Tiefenkarten berechnet, wie in 1D anschaulich dargestellt. Die Phasenkarte und Amplitudenkarte können partitioniert werden, um eine Eins-zu-eins-Abbildung zu der Anordnung von Hogeln zu bilden. Jede technisch machbare Technik kann implementiert werden, um die Phasenkarte und die Amplitudenkarte zu berechnen.
• Veranschaulichendere Information wird nun hinsichtlich verschiedenen optionaler Architekturen und Merkmalen dargelegt, mit denen das vorhergehende Rahmenwerk gemäß den Wünschen der Benutzer implementiert werden kann oder nicht. Es sei nachdrücklich bemerkt, dass die folgende Information für veranschaulichende Zwecke dargelegt wird und nicht in irgendeiner Art und Weise als begrenzend ausgelegt werden sollte. Jedes der folgenden Merkmale kann optional mit dem oder ohne den Ausschluss von anderen beschriebenen Merkmalen eingebunden werden.
• Parallelverarbeitungsarchitektur
• 3 veranschaulicht eine Parallelverarbeitungseinheit (PPU) 300 gemäß einer Ausführungsform. In einer Ausführungsform ist die PPU 300 ein Multi-Threaded-Prozessor bzw. mehrsträngiger Prozessor, der auf einer oder mehreren integrierten Schaltungsvorrichtungen implementiert ist. Die PPU 300 ist eine Latenz-verbergende Architektur, die ausgestaltet ist, um eine große Anzahl von Threads bzw. Strängen parallel zu verarbeiten. Ein Thread bzw. Strang (d.h. ein Ausführungsthread) ist eine Instanziierung eines Satzes von Anweisungen, die konfiguriert sind, um von der PPU 300 ausgeführt zu werden. In einer Ausführungsform ist die PPU 300 eine Graphikverarbeitungseinheit (GPU), die konfiguriert ist, um eine Graphik-Rendering-Pipeline zur Verarbeitung von dreidimensionalen (3D) Graphikdaten zu implementieren, um zweidimensionale (2D) Bilddaten zur Anzeige auf einer Anzeigevorrichtung, wie beispielsweise einer Flüssigkristallanzeige(LCD)-Vorrichtung, zu erzeugen. In anderen Ausführungsformen kann die PPU 300 zum Durchführen von Allzweckberechnungen benutzt werden. Während ein beispielhafter paralleler Prozessor hier für veranschaulichende Zwecke bereitgestellt wird, sei nachdrücklich bemerkt, dass ein derartiger Prozessor lediglich für veranschaulichende Zwecke dargelegt wird und dass ein beliebiger Prozessor benutzt werden kann, um dasselbe zu ergänzen und/oder zu ersetzen.
• Eine oder mehrere PPUs 300 können konfiguriert sein, um Tausende von HPC(High Performing Computing)-, Datenzentrum- und Maschinenlern-Anwendungen zu beschleunigen. Die PPU 300 kann konfiguriert sein, um zahlreiche Deep-Learning-Systeme und Anwendungen zu beschleunigen, die autonome Fahrzeugplattformen, Deep-Learning, hochgenaue Sprache, Bild- und Texterkennungssysteme, intelligente Videoanalyse, molekulare Simulationen, Wirkstoffentdeckung, Krankheitsdiagnose, Wettervorhersage, Analyse großer Datenmengen, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotertechnik, Fabrikautomation, Sprachübersetzung in Echtzeit, Online-Suchoptimierungen und personalisierte Benutzerempfehlungen und dergleichen umfassen.
• Wie in 3 gezeigt, umfasst die PPU 300 eine Eingabe/Ausgabe(E/A)-Einheit 305, eine Frontend-Einheit 315, eine Planereinheit 320, eine Arbeitsverteilungs-Einheit 325, einen Hub 330, eine Kreuzschiene (Xbar) 370, einen oder mehrere allgemeine Verarbeitungscluster (GPCs) 350 und eine oder mehrere Partitions-Einheiten 380. Die PPU 300 kann mit einem Host-Prozessor oder anderen PPUs über einen Interconnect des Hochgeschwindigkeits-NVLink 310 verbunden sein. Die PPU 300 kann ebenfalls mit einem Host-Prozessor oder anderen peripheren Vorrichtungen über einen Interconnect 302 verbunden sein. In einer Ausführungsform kann der lokale Speicher eine Anzahl von Direktzugriffsspeicher(DRAM)-Vorrichtungen umfassen. Die DRAM-Vorrichtungen können als ein HBM(Speicher mit hoher Bandbreite)-Subsystem konfiguriert sein, wobei mehrere DRAM-Dies innerhalb jeder Vorrichtung gestapelt sind.
• Der Interconnect des NVLink 310 ermöglicht Systemen, eine oder mehrere PPUs 300 zu skalieren und zu umfassen, die mit einer oder mehreren CPUs kombiniert sind, unterstützt Cache-Kohärenz zwischen den PPUs 300 und CPUs sowie CPU-Mastering. Daten und/oder Befehle können mittels des NVLink 310 durch den Hub 330 an/von anderen Einheiten der PPU 300, wie beispielsweise eine oder mehrere Kopiermaschinen, einen Videocodierer, einen Videodecodierer, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt) übertragen werden. Das NVLink 310 wird ausführlicher in Verbindung mit 5B beschrieben.
• Die E/A-Einheit 305 ist konfiguriert, um Kommunikationen (d.h. Befehle, Daten usw.) von einem Host-Prozessor (nicht gezeigt) über den Interconnect 302 zu übertragen und zu empfangen. Die E/A-Einheit 305 kann mit dem Host-Prozessor direkt über den Interconnect 302 oder durch eine oder mehrere Zwischenvorrichtungen, wie beispielsweise eine Speicherbrücke, kommunizieren. In einer Ausführungsform kann die E/A-Einheit 305 mit einem oder mehreren anderen Prozessoren, wie beispielsweise eine oder mehrere der PPUs, über den Interconnect 302 kommunizieren. In einer Ausführungsformen implementiert die E/A-Einheit 305 eine PCIe(Peripheral Component Interconnect Express)-Schnittstelle für Kommunikationen über einen PCIe-Bus und der Interconnect 302 ist ein PCIe-Bus. In alternativen Ausführungsformen kann die E/A-Einheit 305 andere Typen von wohlbekannten Schnittstellen zum Kommunizieren mit externen Vorrichtungen umfassen.
• Die E/A-Einheit 305 decodiert Pakete, die über den Interconnect 302 empfangen wurden. In einer Ausführungsform stellen die Pakete Befehle dar, die konfiguriert sind, um die PPU 300 zu veranlassen, verschiedene Operationen durchzuführen. Die E/A-Einheit 305 überträgt die decodierten Befehle an verschiedene andere Einheiten der PPU 300, wie es die Befehle spezifizieren können. Beispielsweise können einige Befehle an die Frontend-Einheit 315 übertragen werden. Andere Befehle können an den Hub 330 oder andere Einheiten der PPU 300, wie beispielsweise eine oder mehrere Kopiermaschinen, einen Video-Codierer, einen VideoDecodierer, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt) übertragen werden. Mit anderen Worten ist die E/A-Einheit 305 konfiguriert, um Kommunikationen zwischen und unter den verschiedenen logischen Einheiten der PPU 300 weiterzuleiten.
• In einer Ausführungsform codiert ein Programm, das von dem Host-Prozessor ausgeführt wird, einen Befehlsstrom in einem Puffer, welcher der PPU 300 Arbeitslasten zur Verarbeitung bereitstellt. Eine Arbeitslast kann mehrere Anweisungen und Daten umfassen, die von diesen Anweisungen zu verarbeiten sind. Der Puffer ist ein Bereich in einem Speicher, der von sowohl dem Host-Prozessor als auch der PPU 300 zugänglich ist (d.h. Lesen/Schreiben). Beispielsweise kann die Host-Schnittstelleneinheit 310 konfiguriert sein, um auf den Puffer in einem Systemspeicher, der mit dem Interconnect 302 verbunden ist, über Speicheranfragen, die über den Interconnect 302 übertragen werden, durch die E/A-Einheit 305 zuzugreifen. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und überträgt dann einen Zeiger zu dem Start des Befehlsstroms an die PPU 300. Die Frontend-Einheit 315 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Frontend-Einheit 315 verwaltet den einen oder mehrere Ströme, liest Befehle von den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 300 weiter.
• Die Frontend-Einheit 315 ist mit einer Planereinheit 320 gekoppelt, welche die verschiedenen GPCs 350 konfiguriert, um Aufgaben zu verarbeiten, die durch den einen oder mehrere Ströme definiert sind. Die Planereinheit 320 ist konfiguriert, um Zustandsinformation zu verfolgen, die verschiedene Aufgaben betrifft, die von der Planereinheit 320 verwaltet werden. Der Zustand kann angeben, welchem GPC 350 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, ob ein Prioritätsniveau der Aufgabe zugeordnet ist und so weiter. Die Planereinheit 320 verwaltet die Ausführung einer Mehrzahl von Aufgaben auf dem einen oder mehreren GPCs 350.
• Die Planereinheit 320 ist mit einer Arbeitsverteilungs-Einheit 325 gekoppelt, die konfiguriert ist, um Aufgaben zur Ausführung auf den GPCs 350 zu versenden. Die Arbeitsverteilungs-Einheit 325 kann eine Anzahl von eingeplanten Aufgaben verfolgen, die von der Planereinheit 320 empfangen werden. In einer Ausführungsform verwaltet die Arbeitsverteilungs-Einheit 325 einen Pool für anhängige Aufgaben und einen Pool für aktive Aufgaben für jeden der GPCs 350. Der Pool für anhängige Aufgaben kann eine Anzahl von Schlitzen (z.B. 32 Schlitze) umfassen, die Aufgaben enthalten, die zugewiesen sind, um von einem bestimmten GPC 350 verarbeitet zu werden. Der Pool für aktive Aufgaben kann eine Anzahl von Schlitzen (z.B. 4 Schlitze) für Aufgaben umfassen, die von den GPCs 350 aktiv verarbeitet werden. Wenn ein GPC 350 die Ausführung einer Aufgabe abschließt, wird diese Aufgabe aus dem Pool für aktive Aufgaben für den GPC 350 geräumt und eine der anderen Aufgaben wird aus dem Pool für anhängige Aufgaben ausgewählt und zur Ausführung auf dem GPC 350 eingeplant. Wenn eine aktive Aufgabe auf dem GPC 350 inaktiv war, wie beispielsweise während darauf gewartet wird, dass eine Datenabhängigkeit behoben wird, dann kann die aktive Aufgabe aus dem GPC 350 geräumt und zu dem Pool für anhängige Aufgaben zurückgeführt werden, während eine weitere Aufgabe in dem Pool für anhängige Aufgaben ausgewählt und zur Ausführung auf dem GPC 350 eingeplant wird.
• Die Arbeitsverteilungs-Einheit 325 kommuniziert mit dem einen oder mehreren GPCs 350 über eine Kreuzschiene bzw. XBar 370. Die XBar 370 ist ein Zwischenverbindungs-Netzwerk, das viele der Einheiten der PPU 300 mit anderen Einheiten der PPU 300 koppelt. Beispielsweise kann die XBar 370 konfiguriert sein, um die Arbeitsverteilungs-Einheit 325 mit einem bestimmten GPC 350 zu koppeln. Obwohl nicht explizit gezeigt, kann eine oder mehrere andere Einheiten der PPU 300 ebenfalls mit der XBar 370 über den Hub 330 verbunden sein.
• Die Aufgaben werden von der Planereinheit 320 verwaltet und an einen GPC 350 von der Arbeitsverteilungs-Einheit 325 versandt. Der GPC 350 ist konfiguriert, um die Aufgabe zu verarbeiten und Ergebnisse zu erzeugen. Die Ergebnisse können von anderen Aufgaben innerhalb des GPC 350 verbraucht werden, an einen unterschiedlichen GPC 350 über die XBar 370 weitergeleitet oder im Speicher 304 gespeichert werden. Die Ergebnisse können in den Speicher 304 über die Partitions-Einheiten 380 geschrieben werden, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/von dem Speicher 304 implementieren. Die Ergebnisse können an eine andere PPU 304 oder CPU über den NVLink 310übertragen werden. In einer Ausführungsform umfasst die PPU 300 eine Anzahl U von Partitions-Einheiten 380, die gleich der Anzahl von getrennten und unterschiedlichen Speichervorrichtungen 304 ist, die mit der PPU 300 gekoppelt sind. Eine Partitions-Einheit 380 wird nachstehend ausführlicher in Verbindung mit 4B beschrieben.
• In einer Ausführungsform führt ein Host-Prozessor einen TreiberKernel aus, der eine Anwendungsprogrammmier-Schnittstelle (API) implementiert, die einer oder mehreren Anwendungen ermöglicht, die auf dem Host-Prozessor ausgeführt werden, Operationen zur Ausführung auf der PPU 300 einzuplanen. In einer Ausführungsform werden mehrere Rechenanwendungen gleichzeitig von der PPU 300 ausgeführt und die PPU 300 stellt Isolierung, Dienstqualität (QoS) und unabhängige Adressräume für die mehreren Rechenanwendungen bereit. Eine Anwendung kann Anweisungen (d.h. API-Aufrufe) erzeugen, welche den TreiberKernel veranlassen, eine oder mehrere Aufgaben zur Ausführung durch die PPU 300 zu erzeugen. Der Treiberkernel gibt Aufgaben an einen oder mehrere Streams aus, die von der PPU 300 verarbeitet werden. Jede Aufgabe kann eine oder mehrere Gruppen von in Beziehung stehender Threads umfassen, die hier als ein Warp bezeichnet werden. In einer Ausführungsform umfasst ein Warp 32 in Beziehung stehende Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Mehrzahl von Threads beziehen, die Anweisungen umfassen, um die Aufgabe durchzuführen, und die Daten durch einen gemeinsam benutzten Speicher austauschen können. Threads und kooperierende Threads werden ausführlicher in Verbindung mit 5A beschrieben.
• 4A veranschaulicht einen GPC 350 der PPU 300 von 3 gemäß einer Ausführungsform. Wie in 4A gezeigt, umfasst jeder GPC 350 eine Anzahl von Hardwareeinheiten zur Verarbeitung von Aufgaben. In einer Ausführungsform umfasst jeder GPC 350 einen Pipeline-Manager 410, eine Vor-Raster-Operationen-Einheit (PROP) 415, eine Raster-Engine 425, eine Arbeitsverteilungs-Kreuzschiene (WDX) 480, eine Speicherverwaltungseinheit (MMU) 490 und einen oder mehrere Datenverarbeitungscluster (DPCs) 420. Es wird anerkannt, dass der GPC 350 von 4A andere Hardwareeinheiten anstelle von oder zusätzlich zu den in 4A gezeigten Einheiten umfassen kann.
• In einer Ausführungsform wird der Betrieb des GPC 350 durch den Pipeline-Manager 410 gesteuert. Der Pipeline-Manager 410 verwaltet die Konfiguration des einen oder mehrerer DPCs 420 zur Verarbeitung von Aufgaben, die dem GPC 350 zugeteilt sind. In einer Ausführungsform kann der Pipeline-Manager 410 mindestens einen des einen oder mehrerer DPCs 420 konfigurieren, um mindestens einen Abschnitt einer Graphik-Rendering-Pipeline zu implementieren. Beispielsweise kann ein DPC 420 konfiguriert sein, um ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 440 auszuführen. Der Pipeline-Manager 410 kann ebenfalls konfiguriert sein, um Pakete, die von der Arbeitsverteilungs-Einheit 325 empfangen werden, an die geeigneten logischen Einheiten innerhalb des GPC 350 weiterzuleiten. Beispielsweise können einige Pakete an Festfunktions-Hardwareeinheiten in der PROP 415 und/oder der Raster-Engine 425 weitergeleitet werden, während andere Pakete an die DPCs 420 zur Verarbeitung durch die Primitiven-Engine 435 oder den SM 440 weitergeleitet werden können. In einer Ausführungsform kann der Pipeline-Manager 410 mindestens einen der einen oder mehreren DPCs 420 konfigurieren, um ein Neuronal-Netzwerkmodell und/oder eine Rechen-Pipeline zu implementieren.
• Die PROP-Einheit 415 ist konfiguriert, um Daten, die von der Raster-Engine 425 und den DPCs 420 erzeugt werden, an eine Raster-Operationen-Einheit (ROP-Einheit) in der Partitions-Einheit 380 weiterzuleiten, die nachstehend ausführlicher in Verbindung mit 4B beschrieben wird. Die PROP-Einheit 415 kann ebenfalls konfiguriert sein, um Optimierungen zur Farbenmischung durchzuführen, Pixeldaten zu organisieren, Adressenübersetzungen und dergleichen durchzuführen.
• Die Raster-Engine 425 umfasst eine Anzahl von Festfunktions-Hardwareeinheiten, die konfiguriert sind, um verschiedene Raster-Operationen durchzuführen. In einer Ausführungsform umfasst die Raster-Engine 425 eine Setup-Engine, eine Grobraster-Engine, eine Aussonderungs-Engine, eine Abschneide-Engine, eine Feinraster-Engine und eine Kachel-verschmelzende Engine. Die Setup-Engine empfängt transformierte Vertices und erzeugt Ebenengleichungen, die den geometrischen Primitiven zugeordnet sind, die durch die Vertices definiert werden. Die Ebenengleichungen werden an die Grobraster-Engine übertragen, um Abdeckungsinformation (z.B. eine (x,y)-Abdeckungsmaske für eine Kachel) für die Primitive zu erzeugen. Die Ausgabe der Grobraster-Engine wird an die Aussonderungs-Engine übertragen, wo Fragmente, die der Primitiven zugeordnet sind, die einen z-Test nicht bestehen, ausgesondert und an eine Abschneide-Engine übertragen werden, wo Fragmente, die außerhalb eines Betrachtungsstumpfes liegen, abgeschnitten werden. Diejenigen Fragmente, welche die Abschneidung und Aussonderung überleben, können an eine Feinraster-Engine weitergeben werden, um Attribute für die Pixelfragmente basierend auf den Ebenengleichungen zu erzeugen, die durch die Setup-Engine erzeugt werden. Die Ausgabe der Raster-Engine 425 umfasst Fragmente, die beispielsweise von einem Fragment-Shader zu verarbeiten sind, der innerhalb eines DPC 420 implementiert ist.
• Jeder DPC 420, der in dem GPC 350 umfasst ist, umfasst einen M-Pipe-Controller (MPC) 430, eine Primitiven-Engine 435 und einen oder mehrere SMs 440. Der MPC 430 steuert den Betrieb des DPC 420, wobei von dem Pipeline-Manager 410 empfangene Pakete an die geeigneten Einheiten im DPC 420 weiterleitet werden. Beispielsweise können einem Vertex zugeordnete Pakete an die Primitiven-Engine 435 weitergeleitet werden, die konfiguriert ist, um der Vertex zugeordnete Vertexattribute von dem Speicher 304 zu holen. Im Gegensatz dazu können einem Shader-Programm zugeordnete Pakete an den SM 440 übertragen werden.
• Der SM 440 umfasst einen programmierbaren Streaming-Prozessor, der konfiguriert ist, um Aufgaben zu verarbeiten, die durch eine Anzahl von Threads dargestellt werden. Jeder SM 440 umfasst mehrere Threads (ist multi-threaded) und ist konfiguriert, um eine Mehrzahl von Threads (z.B. 32 Threads) von einer bestimmten Gruppe von Threads nebenläufig auszuführen. In einer Ausführungsform implementiert der SM 440 eine SIMD(Einzelne-Anweisung, Mehrere-Daten)-Architektur, wobei jeder Thread in einer Gruppe von Threads (d.h. einem Warp) konfiguriert ist, um einen unterschiedlichen Satz von Daten basierend auf dem gleichen Satz von Anweisungen zu verarbeiten. Alle Threads in der Gruppe von Threads führen die gleichen Anweisungen aus. In einer anderen Ausführungsform implementiert der SM 440 eine SIMT(Einzelne Anweisung, Mehrere Threads)-Architektur, wobei jeder Thread in einer Gruppe von Threads konfiguriert ist, um einen unterschiedlichen Satz von Daten basierend auf dem gleichen Satz von Anweisungen zu verarbeiten, wobei jedoch einzelnen Threads in der Gruppe von Threads ermöglicht wird, während der Ausführung zu divergieren. In einer Ausführungsform wird ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand für jeden Warp beibehalten, was eine Nebenläufigkeit zwischen Warps und eine serielle Ausführung innerhalb Warps ermöglicht, wenn Threads innerhalb des Warp divergieren. In einer weiteren Ausführungsform wird ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand für jeden einzelnen Thread beibehalten, was eine gleiche Nebenläufigkeit zwischen allen Threads, innerhalb und zwischen Warps ermöglicht. Wenn der Ausführungszustand für jeden einzelnen Thread beibehalten wird, können Threads, welche die gleichen Anweisungen ausführen, konvergiert und für maximale Effizienz parallel ausgeführt werden. Der SM 440 wird ausführlicher nachstehend in Verbindung mit 5A beschrieben.
• Die MMU 490 stellt eine Schnittstelle zwischen dem GPC 350 und der Partitions-Einheit 380 bereit. Die MMU 490 kann eine Übersetzung von virtuellen Adressen in physische Adressen, einen Speicherschutz und eine Arbitrierung von Speicheranfragen bereitstellen. In einer Ausführungsform stellt die MMU 490 einen oder mehrere Adressenübersetzungspuffer (TLBs = translation lookaside buffers) zum Durchführen der Übersetzung von virtuellen Adressen in physische Adressen in dem Speicher 304 bereit.
• 4B veranschaulicht eine Speicher-Partitions-Einheit 380 der PPU 300 von 3 gemäß einer Ausführungsform. Wie in 4B gezeigt, umfasst die Partitions-Einheit 380 eine Raster-Operationen(ROP)-Einheit 450, einen L2-Cache-Speicher 460 und eine Speicherschnittstelle 470. Die Speicherschnittstelle 470 ist mit dem Speicher 304 gekoppelt. Die Speicherschnittstelle 470 kann 32-, 64-, 128-, 1024-Bit-Datenbusse oder dergleichen für Hochgeschwindigkeits-Datentransfer implementieren. In einer Ausführungsform umfasst die PPU 300 U Speicherschnittstellen 470, eine Speicherschnittstelle 470 pro Paar von Partitions-Einheiten 380, wobei jedes Paar von Partitions-Einheiten 380 mit einer entsprechenden Speichervorrichtung 304 verbunden ist. Beispielsweise kann die PPU 300 mit bis zu Y Speichervorrichtungen 304, wie beispielsweise Speicherstapel mit hoher Bandbreite oder Graphikdoppeldatenraten, Version 5 SDRAM verbunden sein.
• In einer Ausführungsform implementiert die Speicherschnittstelle 470 eine HBM2-Speicherschnittstelle und Y ist gleich einem halben U. In einer Ausführungsform sind die HBM2-Speicherstapel auf der gleichen physischen Packung wie die PPU 300 lokalisiert, die wesentliche Leistungs- und Flächeneinsparungen verglichen mit herkömmlichen GDDR5 SDRAM Systemen bereitstellt. In einer Ausführungsform umfasst jeder HBM2-Stapel vier Speicher-Dies und Y ist gleich 4, wobei der HBM2-Stapel zwei 128-Bit Kanäle pro Die für eine Gesamtzahl von 8 Kanälen und eine Datenbusbreite von 1024 Bit umfasst.
• In einer Ausführungsform unterstützt der Speicher 304 Fehlerkorrekturcode (ECC) mit Einzelfehlerkorrektur und Doppelfehlerdetektion (SECDED), um Daten zu schützen. Der ECC stellt eine höhere Zuverlässigkeit für Rechenanwendungen bereit, die gegen Datenverfälschung empfindlich sind. Zuverlässigkeit ist besonders wichtig in großen Cluster-Rechenumgebungen, wo PPUs 300 sehr große Datensätze verarbeiten und/oder Anwendungen für längere Zeiträume ausführen.
• In einer Ausführungsform implementiert die PPU 300 eine Mehr-Ebenen-Speicherhierarchie. In einer Ausführungsform unterstützt die Speicher-Partitions-Einheit 380 einen vereinheitlichten Speicher, um einen einzigen vereinheitlichten virtuellen Adressraum für den Speicher der CPU und den Speicher der PPU 300 bereitzustellen, der Datenteilung zwischen virtuellen Speichersystemen ermöglicht. In einer Ausführungsform wird die Häufigkeit von Zugriffen durch eine PPU 300 auf einen Speicher, der auf anderen Prozessoren lokalisiert ist, verfolgt, um sicherzustellen, dass Speicherseiten in den physischen Speicher der PPU 300 bewegt werden, die häufiger auf die Seiten zugreift. In einer Ausführungsform unterstützt das NVLink 310 Adressenübersetzungsdienste, die der PPU 300 erlauben, auf Seitentabellen einer CPU direkt zuzugreifen und einen vollen Zugriff auf den CPU-Speicher durch die PPU 300 bereitstellen.
• In einer Ausführungsform transferieren Kopiermaschinen Daten zwischen mehreren PPUs 300 oder zwischen PPUs 300 und CPUs. Die Kopiermaschinen können Seitenfehler für Adressen erzeugen, die nicht in den Seitentabellen abgebildet werden. Die Speicher-Partitions-Einheit 380 kann dann die Seitenfehler bedienen, wobei die Adressen in der Seitentabelle abgebildet werden, nachdem die Kopiermaschine den Transfer durchführen kann. In einem herkömmlichen System ist der Speicher für mehrere Kopiermaschinenoperationen zwischen mehreren Prozessoren gesperrt (d.h. nicht auslagerbar), was den verfügbaren Speicher wesentlich verringert. Mit Hardware-Seiten-Faulting können Adressen an die Kopiermaschinen weitergeleitet werden, ohne sich Sorgen zu machen, ob die Speicherseiten resident sind und das Kopierverfahren transparent ist.
• Daten von dem Speicher 304 oder einem anderen Systemspeicher können von der Speiche-Partitions-Einheit 380 geholt und in dem L2-Cache-Speicher 460 gespeichert werden, der Auf-Chip lokalisiert ist und zwischen den verschiedenen GPCs 350 gemeinsam benutzt wird. Wie gezeigt, umfasst jede Speicher-Partitions-Einheit 380 einen Bereich des L2-Cache-Speichers 460, der einer entsprechenden Speichervorrichtung 304 zugeordnet ist. Cache-Speicher niedrigerer Ebene können dann in verschiedenen Einheiten innerhalb der GPCs 350 implementiert werden. Beispielsweise kann jeder der SMs 440 einen L1-Cache-Speicher implementieren. Der L1-Cache-Speicher ist ein privater Speicher, der einem bestimmten SM 440 fest zugeordnet ist. Daten von dem L2-Cache-Speicher 460 können geholt und in jedem der L1-Cache-Speicher zur Verarbeitung in den Funktionseinheiten der SMs 440 gespeichert werden. Der L2-Cache-Speicher 460 ist mit der Speicherschnittstelle 470 und der XBar 370 gekoppelt.
• Die ROP-Einheit 450 führt Graphik-Raster-Operationen durch, welche die Pixelfarbe betreffen, wie beispielsweise Farbenkomprimierung, Pixelmischung und dergleichen. Die ROP-Einheit 450 implementiert ebenfalls Tiefentesten in Verbindung mit der Raster-Engine 425, wobei eine Tiefe für einen Abtastort, der einem Pixelfragment zugeordnet ist, von der Aussonderungs-Engine der Raster-Engine 425 empfangen wird. Die Tiefe wird gegen eine entsprechende Tiefe in einem Tiefenpuffer für einen Abtastort geprüft, der dem Fragment zugeordnet ist. Wenn das Fragment den Tiefentest für den Abtastort besteht, dann aktualisiert die ROP-Einheit 450 den Tiefenpuffer und überträgt ein Ergebnis des Tiefentests an die Raster-Engine 425. Es wird anerkannt, dass sich die Anzahl von Partitions-Einheiten 380 von der Anzahl von GPCs 350 unterscheiden kann, und daher kann jede ROP-Einheit 450 mit jedem der GPCs 350 gekoppelt werden. Die ROP-Einheit 450 verfolgt Pakete, die von den unterschiedlichen GPCs 350 empfangen werden, und bestimmt, zu welchem GPC 350 ein durch die ROP-Einheit 450 erzeugtes Ergebnis durch die Xbar 470 weitergeleitet wird.
• 5A veranschaulicht den Streaming-Multiprozessor 440 von 4A gemäß einer Ausführungsform. Wie in 5A gezeigt, umfasst der SM 440 einen Anweisungs-Cache-Speicher 505, eine oder mehrere Planereinheiten 510, eine Registerdatei 520, einen oder mehrere Verarbeitungskerne 550, eine oder mehrere Spezialfunktionseinheiten (SFUs) 552, eine oder mehrere Lade/Speicher-Einheiten (LSUs) 554, ein Zwischenverbindungs-Netzwerk 580 und einen gemeinsam benutzten L1-Cache-Speicher 570.
• Wie oben beschrieben, versendet die Arbeitsverteilungs-Einheit 325 Aufgaben zur Ausführung auf den GPCs 350 der PPU 300. Die Aufgaben werden einem bestimmten DPC 420 innerhalb eines GPC 350 zugeteilt, und wenn die Aufgabe einem Shader-Programm zugeordnet ist, kann die Aufgabe einem SM 440 zugeteilt werden. Die Planereinheit 510 empfängt die Aufgaben von der Arbeitsverteilungs-Einheit 325 und verwaltet die Anweisungs-Planung (instruction scheduling) für einen oder mehrere Thread-Blöcke, die dem SM 440 zugewiesen sind. Die Planereinheit 510 plant Thread-Blöcke zur Ausführung als Warps von parallelen Threads, wobei jeder Thread-Block mindestens einem Warp zugeordnet ist. In einer Ausführungsform führt jeder Warp 32 Threads aus. Die Planereinheit 510 kann eine Mehrzahl von unterschiedlichen Thread-Blöcken verwalten, welche die Warps den unterschiedlichen Thread-Blöcken zuordnet und dann Anweisungen von der Mehrzahl von unterschiedlichen kooperativen Gruppen an die verschiedenen Funktionseinheiten (d.h. Kerne 550, SFUs 552 und LSUs 554) während jedes Taktzyklus versendet.
• Cooperative Groups ist ein Programmiermodell zum Organisieren von Gruppen von kommunizierenden Threads, das Entwicklern ermöglicht, die Granularität auszudrücken, bei der Threads kommunizieren, wobei der Ausdruck von reicheren, effizienten Parallelzerlegungen ermöglicht wird. Cooperative-Start-APIs unterstützen die Synchronisierung unter Thread-Blöcken für die Ausführung von parallelen Algorithmen. Herkömmliche Programmiermodelle stellen einen einzigen, einfachen Aufbau zum Synchronisieren von kooperierenden Threads bereit: eine Barriere über alle Threads eines Threadblocks (d.h. die Funktion syncthreads( )). Programmierer würden jedoch häufig gerne Gruppen von Threads bei kleineren als Thread-Block-Granularitäten definieren und innerhalb der definierten Gruppen synchronisieren, um größere Leistung, Gestaltungsflexibilität und Software-Wiederverwendung in der Form von kollektiven gruppenweiten Funktionsschnittstellen zu ermöglichen.
• Cooperative Groups ermöglicht Programmierern, Gruppen von Threads explizit bei Sub-Block(d.h. so klein wie ein einziger Thread)- und Mehr-Block-Granularitäten zu definieren und kollektive Operationen, wie beispielsweise Synchronisierung, an den Threads in einer kooperativen Gruppe durchzuführen. Das Programmiermodell unterstützt eine saubere Zusammensetzung über Softwaregrenzen, so dass Bibliotheken und Hilfsfunktionen innerhalb ihres lokalen Kontexts sicher synchronisieren können, ohne Annahmen über Konvergenz machen zu müssen. Cooperative-Groups-Primitiven ermöglichen neue Muster von kooperativer Parallelität, die Erzeuger-Verbraucher Parallelität, opportunistische Parallelität und globale Synchronisierung über ein gesamtes Gitter von Threadblöcken umfassen.
• Eine Versandeinheit 515 ist konfiguriert, um Anweisungen an eine oder mehrere der Funktionseinheiten zu übertragen. In der Ausführungsform umfasst die Planereinheit 510 zwei Versandeinheiten 515, die ermöglichen, dass zwei unterschiedliche Anweisungen von dem gleichen Warp während jedes Taktzyklus versandt werden. In alternativen Ausführungsformen kann jede Planereinheit 510 eine einzige Versandeinheit 515 oder zusätzliche Versandeinheiten 515 umfassen.
• Jeder SM 440 umfasst eine Registerdatei 520, die einen Satz von Registern für die Funktionseinheiten des SM 440 bereitstellt.
• In einer Ausführungsform ist die Registerdatei 520 zwischen jeder der Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein zugehöriger Abschnitt der Registerdatei 520 zugeteilt ist. In einer anderen Ausführungsform ist die Registerdatei 520 zwischen den unterschiedlichen Warps aufgeteilt, die von dem SM 440 ausgeführt werden. Die Registerdatei 520 stellt temporäre Speicherung für Operanden bereit, die mit den Datenpfaden der Funktionseinheiten verbunden sind.
• Jeder SM 440 umfasst L Verarbeitungskerne 450. In einer Ausführungsform umfasst der SM 440 eine große Anzahl (z.B. 128, usw.) von unterschiedlichen Verarbeitungskernen 450. Jeder Kern 450 kann eine vollständig in einer Pipeline angeordnete (fullypipelined) Einfach-Präzisions- Verarbeitungseinheit umfassen, die eine Gleitkommaarithmetik-Logikeinheit und eine Ganzzahlarithmetik-Logikeinheit umfasst. In einer Ausführungsform implementieren die Gleitkommaarithmetik-Logikeinheiten den IEEE 754-3008 Standard für Gleitkommaarithmetik. In einer Ausführungsform umfassen die Kerne 550 64 Einfach-Präzisions-(32-Bit)-Gleitkommakerne, 64 Integer-Kerne, 32 Doppel-Präzisions-(64-Bit)-Gleitkommakerne und 8 Tensorkerne.
• Tensorkerne, die konfiguriert sind, um Matrix-Operationen, und in einer Ausführungsform ein oder mehrere Tensorkerne durchzuführen, sind in den Kernen 550 umfasst. Insbesondere sind die Tensorkerne konfiguriert, um Deep-Learning-Matrix-Arithmetik, wie beispielsweise Faltungsoperationen für Neuronal-Netzwerktraining und Inferenzieren, durchzuführen. In einer Ausführungsform arbeitet jeder Tensorkern an einer 4x4 Matrix und führt eine Matrix-Multiplikations- und Akkumulations-Operation D=A×B+C durch, wobei A, B, C und D 4x4 Matrizen sind.
• In einer Ausführungsform sind die Matrix-Multiplikations-Eingaben A und B 16-Bit-Gleitkomma-Matrizen, während die Akkumulationsmatrizen C und D 16-Bit-Gleitkomma- oder 32-Bit-Gleitkomma-Matrizen sein können. Tensorkerne arbeiten an 16-Bit-Gleitkomma-Eingabedaten mit 32-Bit-Gleitkomma-Akkumulation. Die 16-Bit-Gleitkomma-Multiplikation erfordert 64 Operationen und ergibt ein Produkt voller Präzision, das dann unter Verwendung einer 32-Bit-Gleitkomma-Addition mit den anderen Zwischenprodukten für eine 4x4x4-Matrix-Multiplikation akkumuliert wird. In der Praxis werden Tensorkerne verwendet, um viel größere zweidimensionale oder höherdimensionale Matrixoperationen durchzuführen, die von diesen kleineren Elementen aufgebaut werden. Eine API, wie beispielsweise die CUDA 9 C++ API, stellt spezialisierte Matrix-Lade-, Matrix-Multiplikations- und Matrix-Akkumulations- und Matrix-SpeicherOperationen bereit, um Tensorkerne von einem CUDA-C++ Programm effizient zu verwenden. Auf der CUDA-Ebene nimmt das Warp-Schnittstellenniveau 16x16 große Matrizen an, die alle 32 Threads des Warp überspannen.
• Jeder SM 440 umfasst ebenfalls M SFUs 552, die Sonderfunktionen durchführen (z.B. Attributauswertung, reziproke Quadratwurzel und dergleichen). In einer Ausführungsform können die SFUs 552 eine Baumtraversierungseinheit umfassen, die konfiguriert ist, um eine hierarchische Baumdatenstruktur zu durchlaufen. In einer Ausführungsform können die SFUs 552 eine Textureinheit umfassen, die konfiguriert ist, um Texturkarten-Filteroperationen durchzuführen. In einer Ausführungsform sind die Textureinheiten konfiguriert, um Texturkarten (z.B. eine 2D-Anordnung von Texeln) von dem Speicher 304 zu laden und die Texturkarten abzutasten, um abgetastete Texturwerte zum Gebrauch in Shader-Programmen zu erzeugen, die von dem SM 440 ausgeführt werden. In einer Ausführungsform werden die Texturkarten in dem gemeinsam benutzten Speicher/L1-Cache-Speicher 470 gespeichert. Die Textureinheiten implementieren Texturoperationen, wie beispielsweise Filteroperationen, unter Verwendung von Mip-Maps (d.h. Texturkarten von veränderlichem Detaillierungsgrad). In einer Ausführungsform umfasst jeder SM 340 zwei Textureinheiten.
• Jeder SM 440 umfasst ebenfalls N LSUs 554, die Lade- und Speicheroperationen zwischen dem gemeinsam benutzten Speicher/L1-Cache-Speicher 570 und der Registerdatei 520 implementieren. Jeder SM 440 umfasst ein Zwischenverbindungs-Netzwerk 580, das jede der Funktionseinheiten mit der Registerdatei 520 und die LSU 554 mit der Registerdatei 520, dem gemeinsam benutzten Speicher/ L1-Cache-Speicher 570 verbindet. In einer Ausführungsform ist das Zwischenverbindungs-Netzwerk 580 eine Kreuzschiene, die konfiguriert sein kann, um irgendeine der Funktionseinheiten mit irgendeinem der Register in der Registerdatei 520 zu verbinden und die LSUs 554 mit der Registerdatei und Speicherorten im gemeinsam benutzten Speicher/L1-Cache-Speicher 570 zu verbinden.
• Der gemeinsam benutzte Speicher/L1-Cache-Speicher 570 ist eine Auf-Chip-Speicheranordnung, die Datenspeicherung und Kommunikation zwischen dem SM 440 und der Primitiven-Engine 435 und zwischen Threads in dem SM 440 ermöglicht. In einer Ausführungsform umfasst der gemeinsam benutzte Speicher/L1-Cache-Speicher 570 128KB von Speicherkapazität und ist in dem Pfad von dem SM 440 zu der Partitions-Einheit 380. Der gemeinsam benutzte Speicher/L1-Cache-Speicher 570 kann verwendet werden, um Lese- und Schreibvorgänge zwischenzuspeichern. Einer oder mehrere der gemeinsam benutzten Speicher/L1-Cache-Speicher 570, L2-Cache-Speicher 460 und Speicher 304 sind Hintergrundspeicher.
• Das Kombinieren eines Daten-Cache und gemeinsam benutzter Speicherfunktionalität in einem einzigen Speicherblock stellt die beste Gesamtleistung für beide Arten von Speicherzugriffen bereit. Die Kapazität ist als ein Cache von Programmen benutzbar, die den gemeinsam benutzten Speicher nicht verwenden. Wenn der gemeinsam benutzte Speicher beispielsweise konfiguriert ist, die Hälfte der Kapazität zu verwenden, können Textur- und Lade/Speicher-Operationen die verbleibende Kapazität verwenden. Integration innerhalb des gemeinsam benutzten Speichers/L1-Cache-Speicher 570 ermöglicht dem gemeinsam benutzten Speicher/L1-Cache-Speicher 570 als eine Leitung mit hohem Durchsatz zum Streamen von Daten zu arbeiten, während gleichzeitig eine höhere Bandbreite und ein latenzarmer Zugriff auf häufig wiederverwendete Daten bereitgestellt werden.
• Wenn für Allzweck-Parallelberechnung konfiguriert, kann im Vergleich mit der Graphikverarbeitung eine einfachere Konfiguration verwendet werden. Im Einzelnen werden die in 3 gezeigten Festfunktions-Graphikverarbeitungseinheiten umgangen, wobei ein viel einfacheres Programmiermodell erzeugt wird. In der Allzweck-Parallelberechnungs-Konfiguration werden Blöcke von Threads von der Arbeitsverteilungs-Einheit 325 direkt den DPCs 420 zugewiesen und verteilt. Die Threads in einem Block führen das gleiche Programm unter Verwendung einer eindeutigen Thread-ID in der Berechnung, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, unter Verwendung des SM 440, um das Programm auszuführen und Berechnungen durchzuführen, eines gemeinsam benutzten Speicher/L1-Cache-Speichers 570, um zwischen Threads zu kommunizieren, und der LSU 554 aus, um globalen Speicher durch den gemeinsam benutzten Speicher/L1-Cache-Speicher 570 und die Speicher-Partitions-Einheit 380 zu lesen und zu beschreiben. Wenn für Allzweck-Parallelberechnung konfiguriert, kann der SM 440 ebenfalls Befehle schreiben, welche die Planereinheit 320 verwenden kann, um neue Arbeit auf den DPCs 420 zu starten.
• Die PPU 300 kann in einem Tischcomputer, einem Laptop-Computer, einem Tablet-Computer, einem Smartphone (z.B. einer drahtlosen handgehaltenen Vorrichtung), einem persönlichen digitalen Assistenten (PDA), einer Digitalkamera, einer handgehaltenen elektronischen Vorrichtung und dergleichen umfasst sein. In einer Ausführungsform ist die PPU 300 auf einem einzelnen Halbleitersubstrat verkörpert. In einer anderen Ausführungsform ist die PPU 300 in einem System-auf-Chip (SoC) zusammen mit einer oder mehreren anderen Vorrichtungen, wie beispielsweise zusätzlichen PPUs 300, dem Speicher 204, einem Rechner-mitreduziertem-Befehlssatz(RISC)-CPU, einer Speicherverwaltungseinheit (MMU), einem Digital/Analog-Wandler (DAC) und dergleichen umfasst.
• In einer Ausführungsform kann die PPU 300 auf einer Graphikkarte umfasst sein, die eine oder mehrere Speichervorrichtungen 304 umfasst. Die Graphikkarte kann konfiguriert sein, um sich mit einem PCIe-Schlitz auf einer Hauptplatine eines Tischcomputers schnittstellenmäßig zu verbinden. In noch einer anderen Ausführungsform kann die PPU 300 eine integrierte Graphikverarbeitungseinheit (iGPU) oder ein Parallelprozessor sein, der in dem Chipsatz der Hauptplatine umfasst ist.
• Beispielhaftes Rechensystem
• Systeme mit mehrere GPUs und CPUs werden in einer Vielfalt von Industrien verwendet, sowie Entwickler mehr Parallelität in Anwendungen, wie beispielsweise Rechnen für künstliches Intelligenz, freilegen und wirksam einsetzen. Hochleistungs-GPU-beschleunigte Systeme mit zehn bis vielen tausenden von Rechenknoten werden in Datenzentren, Forschungsanlagen und Supercomputern eingesetzt, um immer größere Probleme zu lösen. Sowie die Anzahl von Verarbeitungsvorrichtungen innerhalb der Hochleistungssysteme zunimmt, müssen die Kommunikations- und Datentransfermechanismen angepasst werden, um die erhöhte Bandbreite zu unterstützen.
• 5B ist ein Konzeptdiagramm eines Verarbeitungssystems 500, das unter Verwendung der PPU 300 von 3 implementiert wird, gemäß einer Ausführungsform. Das Verarbeitungssystem 500 kann konfiguriert sein, um das in 1A gezeigte Verfahren 110, das in 1B gezeigte Verfahren 120, das in 2H gezeigte Verfahren 280 oder eine beliebige Kombination davon zu implementieren. Das Verarbeitungssystem 500 umfasst eine CPU 530, einen Schalter 510 und jeweils mehrere PPUs 300 und jeweilige Speicher 304. Das NVLink 310 stellt Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 300 bereit. Der Schalter 510 ist schnittstellenmäßig zwischen dem Interconnect 302 und der CPU 530 verbunden. Die PPUs 300, die Speicher 304 und die NVLinks 310 können auf einer einzigen Halbleiterplattform situiert sein, um ein Parallelverarbeitungsmodul 525 zu bilden.
• Im Kontext der vorliegenden Beschreibung kann sich eine einzige Halbleiterplattform auf eine einzelne unitäre Halbleiterbasierte integrierte Schaltung beziehen, die auf einem Die oder Chip angefertigt ist. Es sei bemerkt, dass sich der Begriff einzige Halbleiterplattform ebenfalls auf Mehr-Chip-Module mit erhöhter Konnektivität beziehen kann, die eine Auf-Chip-Operation simulieren und die wesentliche Verbesserungen gegenüber der Benutzung einer herkömmlichen Busimplementierung vornehmen. Natürlich können die verschiedenen Schaltungen oder Vorrichtungen ebenfalls getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen gemäß den Wünschen des Benutzers situiert sein. Alternativ kann das Parallelverarbeitungsmodul 525 als ein Leiterplattensubstrat implementiert sein und jede der PPUs 300 und/oder Speicher 304 können verpackte Vorrichtungen sein. In einer Ausführungsform sind die CPU 530, der Schalter 510 und das Parallelverarbeitungsmodul 525 auf einer einzigen Halbleiterplattform situiert.
• In einer Ausführungsform ist die Signalrate von jedem NVLink 310 20 bis 25 Gigabit/s und jede PPU 300 umfasst sechs NVLink 310 Schnittstellen (wie in 5B gezeigt, sind fünf NVLink 310 Schnittstellen sind für jede PPU 300 umfasst). Jedes NVLink 310 stellt eine Datentransferrate von 25 Gigabyte/s in jeder Richtung bereit, wobei sechs Verknüpfungen 300 Gigabyte/s bereitstellen. Die NVLinks 310 können exklusiv für PPU-zu-PPU Kommunikation, wie in 5B gezeigt, oder einer Kombination von PPU-zu-PPU und PPU-zu-CPU verwendet werden, wenn die CPU 530 ebenfalls eines oder mehrere NVLink 310 Schnittstellen umfasst.
• In einer Ausführungsform ermöglicht das NVLink 310 einen direkten Lade/Speicher/atomaren Zugriff der CPU 530 auf jeden Speicher 304 der PPU 300. In einer Ausführungsform unterstützt das NVLink 310 Kohärenzoperationen, die ermöglichen, das von dem Speicher 304 gelesene Daten in der Cache-Hierarchie der CPU 530 gespeichert werden können, was die Cachezugriffslatenz für die CPU 530 verringert. In einer Ausführungsform umfasst das NVLink 310 Unterstützung für Address Translation Services (ATS), was der PPU 300 ermöglicht, auf Seitentabellen innerhalb der CPU 530 direkt zuzugreifen. Einer oder mehrere der NVLinks 310 können ebenfalls konfiguriert sein, um in einem Niedrigleistungsmodus zu arbeiten.
• 5C veranschaulicht ein beispielhaftes System 565, bei dem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden kann. Das beispielhafte System 565 kann konfiguriert sein, um das in 1A gezeigte Verfahren 100, das in 1B gezeigte Verfahren 120, das in 2H gezeigte Verfahren 280 oder jede beliebige Kombination davon zu implementieren.
• Wie gezeigt, wird ein System 565 bereitgestellt, das mindestens eine zentrale Verarbeitungseinheit 530 umfasst, die mit einem Kommunikationsbus 575 verbunden ist. Der Kommunikationsbus 575 kann unter Verwendung jedes geeigneten Protokolls, wie beispielsweise PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), Hyper-Transport oder irgendeinem anderen Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll(en), implementiert sein. Das System 565 umfasst ebenfalls einen Hauptspeicher 540. Steuerlogik (Software) und Daten werden in dem Hauptspeicher 540 gespeichert, der die Form eines Direkt-Zugriffs-Speichers (RAM) annehmen kann.
• Das System 565 umfasst ebenfalls Eingabevorrichtungen 560, das Parallelverarbeitungssystem 525 und Anzeigevorrichtungen 545, d.h. eine herkömmliche CRT (Kathodenstrahlröhre), eine LCD (Flüssigkristallanzeige), eine LED (lichtemittierende Diode), eine Plasmaanzeige oder dergleichen. Eine Benutzereingabe kann von den Eingabevorrichtungen 560, z.B. Tastatur, Maus, Berührfeld, Mikrophon und dergleichen empfangen werden. Jedes der vorhergehenden Module und/oder Vorrichtungen kann sogar auf einer einzigen Halbleiterplattform situiert sein, um das System 565 zu bilden. Alternativ können die verschiedenen Module ebenfalls getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen gemäß den Wünschen des Benutzers situiert sein.
• Ferner kann das System 565 mit einem Netzwerk (z.B. einem Telekommunikationsnetzwerk, Lokalbereichsnetzwerk (LAN), drahtlosen Netzwerk, Weitbereichsnetzwerk (WAN), wie beispielsweise dem Internet, Peer-zu-Peer-Netzwerk, Kabelnetzwerk oder dergleichen) durch eine Netzwerkschnittstelle 535 für Kommunikationszwecke gekoppelt sein.
• Das System 565 kann ebenfalls einen Sekundärspeicher umfassen (nicht gezeigt). Der Sekundärspeicher 610 umfasst beispielsweise ein Festplattenlaufwerk und/oder ein entfernbares Speicherlaufwerk, das ein Diskettenlaufwerk darstellt, ein Magnetbandlaufwerk, ein Kompaktdisklaufwerk, ein digitale versatile Disk-(DVD)-Laufwerk, eine Aufzeichnungsvorrichtung und einen Universal-Serial-Bus-(USB)-Flash-Speicher. Das entfernbare Speicherlaufwerk liest von und/oder schreibt auf eine entfernbare Speichereinheit auf eine wohlbekannte Art und Weise.
• Computerprogramme oder Computersteuerlogik-Algorithmen können in dem Hauptspeicher 540 und/oder dem Sekundärspeicher gespeichert sein. Derartige Computerprogramme, wenn ausgeführt, ermöglichen dem System 565, verschiedene Funktionen durchzuführen. Der Speicher 540, die Speicherung, und/oder jede andere Speicherung sind mögliche Beispiele von computerlesbaren Medien.
• Die Architektur und/oder Funktionalität der verschiedener vorherigen Figuren kann im Kontext eines allgemeinen Computersystems, eines Platinensystems, eines Unterhaltungszwecken fest zugeordneten Spielkonsolensystems, eines anwendungsspezifischen Systems und/oder jedem anderen gewünschten System implementiert sein. Beispielsweise kann das System 565 die Form eines Tischcomputers, eines Laptop-Computers, eines Tablet-Computers, von Servern, von Supercomputern, eines Smartphones (z.B. einer drahtlosen handgehaltenen Vorrichtung), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, einer am Kopf angebrachten Anzeige, einer handgehaltenen elektronischen Vorrichtung, eines mobilen Telefongeräts, eines Fernsehers, einer Arbeitsstation, einer Spielkonsole, eines eingebetteten Systems und/oder von jedem anderen Typ von Logik annehmen.
• Während verschiedene Ausführungsformen oben beschrieben wurden, sei zu verstehen, dass sie lediglich beispielhaft und nicht begrenzend präsentiert wurden. Somit sollte die Breite und der Umfang einer bevorzugten Ausführungsform nicht durch irgendeine der oben beschriebenen beispielhaften Ausführungsformen begrenzt werden, sondern sollte nur durch die folgenden Ansprüche und ihrer Äquivalente definiert werden.
• Graphikverarbeitungs-Pipeline
• In einer Ausführungsform umfasst die PPU 300 eine Graphikverarbeitungseinheit (GPU). Die PPU 300 ist konfiguriert, um Befehle zu empfangen, die Shader-Programme zur Verarbeitung von Graphikdaten spezifizieren. Graphikdaten können als ein Satz von Primitiven, wie beispielsweise Punkte, Linien, Dreiecke, Vierecke, Dreieckstreifen und dergleichen definiert sein. Typischerweise umfasst eine Primitive Daten, die eine Anzahl von Vertices für die Primitive (z.B., in einem Modellraum-Koordinatensystem) sowie auch Attribute spezifizieren, die jedem Vertex der Primitiven zugeordnet sind. Die PPU 200 kann konfiguriert sein, um die Graphikprimitive zu verarbeiten, um ein Frame-Puffer zu erzeugen (d.h. Pixeldaten für jedes der Pixel der Anzeige). In einer Ausführungsform werden Phasen- und Amplitudenabtastungen für Pixel eines SLM (z.B. SLM 263 in 2D) von der PPU gemäß den hier erläuterten Techniken gerendert. Insbesondere kann 3D-Szeneninformation, die geometrische, Vertex- und oder Fragmentprimitiven umfasst, von der GPU gerendert werden, um Fragmente zu erzeugen, die unterschiedlichen Szenenobjekten zugeordnet sind. Blickabhängige Wirkungen können unter Verwendung des 3D-Rendering-Pipeline-z-Puffers durchgeführt werden. In einer Ausführungsform können die Fragmente parallel durch eine oder mehrere Instanzen der PPU 300 innerhalb der GPU erzeugt werden. Des Weiteren kann eine Anordnung von Elementarbildern gemäß berechneten virtuellen Kameraansichten für die 3D-Szene gerendert werden und die Elementbilder werden verwendet, um dann entsprechende Hogel zu berechnen. Ein holographisches Lichtfeld-Frame, das eine Anordnung von Hogeln umfasst, wird einem Betrachter von dem SLM präsentiert. Eine zeitliche Abfolge von Lichtfeld-Frames, die von der GPU gerendert und dann von dem SLM angezeigt wird, kann dem Betrachter eine Erfahrung bereitstellen, tatsächliche 3D-Objekte in der 3D-Szene mit passender blickabhängiger Verdeckung, kontinuierlichen Fokushinweisen und Echtzeitreaktion basierend auf spezifischer Anwendungsszeneninformation (z.B., Modelldaten und virtuelle Kamerapositionsdaten) zu sehen.
• Eine Anwendung schreibt Modelldaten für eine Szene (d.h. eine Sammlung von Vertices und Attributen) in einen Speicher, wie beispielsweise einen Systemspeicher oder Speicher 304. Die Modelldaten definieren jedes der Objekte, die auf einer Anzeige sichtbar sein können. Die Anwendung führt dann einen API-Aufruf an dem Treiber-Kernel aus, der die Modelldaten anfragt, die zu rendern und anzuzeigen sind. Der Treiber-Kernel liest die Modelldaten und schreibt Befehle an den einen oder mehrere Ströme, um Operationen durchzuführen, um die Modelldaten zu verarbeiten. Die Befehle können unterschiedliche Shader-Programme referenzieren, die auf den SMs 440 der PPU 300 zu implementieren sind, die einen oder mehrere eines Vertex-Shader, Hull-Shader, Domain-Shader, Geometrie-Shader und eines Pixel-Shader umfassen können. Beispielsweise können eine oder mehrere der SMs 440 konfiguriert sein, um ein Vertex-Shader-Programm auszuführen, das eine Anzahl von Vertices verarbeitet, die durch die Modelldaten definiert sind. In einer Ausführungsform können die unterschiedlichen SMs 440 konfiguriert sein, um unterschiedliche Shader-Programme nebenläufig auszuführen. Beispielsweise kann eine erste Untermenge von SMs 440 konfiguriert sein, ein Vertex-Shader-Programm auszuführen, während eine zweite Untermenge von SMs 440 konfiguriert sein kann, ein Pixel-Shader-Programm auszuführen. Die erste Untermenge von SMs 440 verarbeitet Vertexdaten, um verarbeitete Vertexdaten zu erzeugen, und schreibt die verarbeiteten Vertexdaten in den L2-Cache-Speicher 460 und/oder den Speicher 304. Nachdem die verarbeiteten Vertexdaten gerastert sind (d.h. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum transformiert sind), um Fragmentdaten zu erzeugen, führt die zweite Untermenge von SMs 440 einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, die dann mit anderen verarbeiteten Fragmentdaten gemischt werden und in den Frame-Puffer im Speicher 304 geschrieben werden. Das Vertex-Shader-Programm und das Pixel-Shader-Programm können nebenläufig ausgeführt werden, wobei unterschiedliche Daten von der gleichen Szene in einem Pipeline-Verfahren verarbeitet werden, bis alle der Modelldaten für die Szene gerenderten zu dem Frame-Puffer gerendert wurden. Dann wird der Inhalt des Frame-Puffers an einen Anzeigencontroller zur Anzeige auf einer Anzeigevorrichtung übertragen.
• 6 ist ein Konzeptdiagramm einer von der PPU 300 von 3 implementierten Graphikverarbeitungs-Pipeline 600 gemäß einer Ausführungsform. Die Graphikverarbeitungs-Pipeline 600 ist ein abstraktes Ablaufdiagramm der Verarbeitungsschritte, die implementiert werden, um 2D-Computer-erzeugte Bilder von 3D-Geometriedaten zu erzeugen. Wie bekannt ist, können Pipeline-Architekturen Operationen mit langer Latenz effizienter durch Aufteilen der Operation in eine Mehrzahl von Stufen durchführen, wobei der Ausgang jeder Stufe mit dem Eingang der nächsten aufeinanderfolgenden Stufe gekoppelt ist. Somit empfängt die Graphikverarbeitungs-Pipeline 600 Eingangsdaten 601, die von einer Stufe zu der nächsten Stufe der Graphikverarbeitungs-Pipeline 600 übertragen werden, um Ausgangsdaten 602 zu erzeugen. In einer Ausführungsform kann die Graphikverarbeitungs-Pipeline 600 eine Graphikverarbeitungs-Pipeline darstellen, die durch die OpenGL® API definiert ist. Als eine Option kann die Graphikverarbeitungs-Pipeline 600 im Kontext der Funktionalität und Architektur der vorherigen Figuren und/oder etwaiger nachfolgenden Figur(en) implementiert werden.
• Wie in 6 gezeigt, umfasst die Graphikverarbeitungs-Pipeline 600 eine Pipeline-Architektur, die eine Anzahl von Stufen umfasst. Die Stufen umfassen, sind jedoch nicht beschränkt auf, eine Daten-Zusammenstellungsstufe 610, eine Vertex-Shading-Stufe 620, eine Primitiven-Zusammenstellungsstufe 630, eine Geometrie-Shading-Stufe 640, eine Darstellungsfeld-Skalierungs-, Aussonderungs- und Abschneide-(VSCC)-Stufe 650, eine Rasterungsstufe 660, eine Fragment-Shading-Stufe 670 und eine Raster-Operationen-Stufe 680. In einer Ausführungsform umfassen die Eingangsdaten 601 Befehle, welche die Verarbeitungseinheiten konfigurieren, um die Stufen der Graphikverarbeitungs-Pipeline 600 und geometrische Primitive (z.B., Punkte, Linien, Dreiecke, Vierecke, Dreieckstreifen oder Fächer, usw.) zu implementieren, die mittels der Stufen zu verarbeiten sind. Die Ausgangsdaten 602 können Pixeldaten (d.h. Farbdaten) umfassen, die in einen Frame-Puffer oder einen anderen Typ von Oberflächen-Datenstruktur in einem Speicher kopiert werden.
• Die Daten-Zusammenstellungsstufe 610 empfängt die Eingangsdaten 601, die Vertexdaten für Oberflächen höherer Ordnung, Primitiven oder dergleichen spezifizieren. Die Daten-Zusammenstellungsstufe 610 sammelt die Vertexdaten in einem temporären Speicher oder Warteschlange, wie beispielsweise durch Empfangen eines Befehls von dem Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher umfasst und die Vertexdaten aus dem Puffer liest. Die Vertexdaten werden dann an die Vertex-Shading-Stufe 620 zur Verarbeitung übertragen.
• Die Vertex-Shading-Stufe 620 verarbeitet Vertexdaten durch Durchführen eines Satzes von Operationen (d.h. eines Vertex-Shader oder eines Programms) einmal für jede der Vertices. Vertices können beispielsweise als ein 4-Koordinaten-Vektor (d.h. <x, y, z, w>) spezifiziert sein, der einem oder mehreren Vertexattributen (z.B., Farbe, Texturkoordinaten, Oberflächennormalen, usw.) zugeordnet ist. Die Vertex-Shading-Stufe 620 kann einzelne Vertexattribute, wie beispielsweise Position, Farbe, Texturkoordinaten und dergleichen, manipulieren. Mit anderen Worten führt die Vertex-Shading-Stufe 620 Operationen an den Vertex-Koordinaten oder anderen Vertexattributen durch, welche einer Vertex zugeordnet sind. Derartige Operationen umfassen gewöhnlicherweise Beleuchtungs-Operationen (d.h. Modifizieren von Farbattributen für einen Vertex) und Transformations-Operationen (d.h. Modifizieren des Koordinatenraums für einen Vertex). Beispielsweise können Vertices unter Verwendung von Koordinaten in einem Objekt-Koordinatenraum spezifiziert sein, die durch Multiplizieren der Koordinaten mittels einer Matrix transformiert werden, welche die Koordinaten aus dem Objekt-Koordinatenraum in einen WeltRaum oder einen normierten Vorrichtungskoordinaten(NCD = Normalized Device Coordinates)-Raum übersetzt. Die Vertex-Shading-Stufe 620 erzeugt transformierte Vertexdaten, die an die Primitiven-Zusammenstellungsstufe 630 übertragen werden.
• Die Primitiven-Zusammenstellungsstufe 630 sammelt Vertices, die mittels der Vertex-Shading-Stufe 620 ausgegeben werden, und gruppiert die Vertices in geometrische Primitiven zur Verarbeitung durch die Geometrie-Shading-Stufe 640. Beispielsweise kann die Primitiven-Zusammenstellungsstufe 630 konfiguriert sein, um alle drei aufeinanderfolgenden Vertices als eine geometrische Primitive (d.h. ein Dreieck) zur Übertragung an die Geometrie-Shading-Stufe 640 zu gruppieren. In einigen Ausführungsformen können spezifische Vertices für aufeinanderfolgende geometrische Primitiven erneut verwendet werden (z.B. können zwei aufeinanderfolgende Dreiecke in einem Dreieckstreifen zwei Vertices gemeinsam benutzen). Die Primitiven-Zusammenstellungsstufe 630 überträgt geometrische Primitiven (d.h. eine Sammlung von zugeordneten Vertices) an die Geometrie-Shading-Stufe 640.
• Die Geometrie-Shading-Stufe 640 verarbeitet geometrische Primitiven durch Durchführen eines Satzes von Operationen (d.h. eines Geometrie-Shader oder Programms) an den geometrischen Primitiven. Tessellations-Operationen können eine oder mehrere geometrische Primitiven aus jeder geometrischen Primitive erzeugen. Mit anderen Worten kann die Geometrie-Shading-Stufe 640 jede geometrische Primitive in ein feineres Netz von zwei oder mehr geometrischen Primitiven zur Verarbeitung durch den Rest der Graphikverarbeitungs-Pipeline 600 unterteilen. Die Geometrie-Shading-Stufe 640 überträgt geometrische Primitiven an die Darstellungsfeld-SCC-Stufe 650.
• In einer Ausführungsform kann die Graphikverarbeitungs-Pipeline 600 innerhalb eines Streaming-Mehrfachprozessors arbeiten, und die Vertex-Shading-Stufe 620, die Primitiven-Zusammenstellungsstufe 630, die Geometrie-Shading-Stufe 640, die Fragment-Shading-Stufe 670 und/oder die damit zugeordnete Hardware/Software kann sequentiell Verarbeitungsoperationen durchführen. Sobald die sequentiellen Verarbeitungsoperationen in einer Ausführungsform abgeschlossen sind, kann die Darstellungsfeld-SCC-Stufe 650 die Daten benutzen. In einer Ausführungsform können Primitivendaten, die durch eine oder mehrere der Stufen in der Graphikverarbeitungs-Pipeline 600 verarbeitet wurden, in einen Cache-Speicher (z.B. einen L1-Cache-Speicher, einen Vertex-Cache-Speicher usw.) geschrieben werden. In diesem Fall kann in einer Ausführungsform die Darstellungsfeld-SCC-Stufe 650 auf die Daten in dem Cache-Speicher zugreifen. In einer Ausführungsform sind die Darstellungsfeld-SCC-Stufe 650 und die Rasterungsstufe 660 als Festfunktions-Schaltungen implementiert.
• Die Darstellungsfeld-SCC-Stufe 650 führt Darstellungsfeld-Skalierung, Aussonderung und Abschneidung der geometrischen Primitiven durch. Jede Oberfläche, die gerendert wird, wird einer abstrakten Kameraposition zugeordnet. Die Kameraposition stellt einen Ort eines Betrachters dar, der die Szene betrachtet, und definiert einen Betrachtungsstumpf, der die Objekte der Szene einschließt. Der Betrachtungsstumpf kann eine Betrachtungs-Ebene, eine hintere Ebene und vier Abschneide-Ebenen umfassen. Jede geometrische Primitive, die vollständig außerhalb des Betrachtungsstumpfes ist, kann ausgesondert (d.h. verworfen) werden, weil die geometrische Primitive nicht zu der endgültigen gerenderten Szene beitragen wird. Jede geometrische Primitive, die innerhalb des Betrachtungsstumpfs und teilweise außerhalb des Betrachtungsstumpfs ist, kann abgeschnitten werden (d.h. in eine neue geometrische Primitive transformiert werden, die innerhalb des Betrachtungsstumpf eingeschlossen ist). Des Weiteren können geometrische Primitiven jeweils basierend auf einer Tiefe des Betrachtungsstumpfes skaliert werden. Alle potentiell sichtbaren geometrischen Primitiven werden dann an die Rasterungsstufe 660 übertragen.
• Die Rasterungsstufe 660 wandelt die 3D-geometrischen Primitiven in 2D-Fragmente um (die z.B. in der Lage sind, zur Anzeige benutzt zu werden, usw.). Die Rasterungsstufe 660 kann konfiguriert sein, um die Vertices der geometrischen Primitive zu benutzen, um einen Satz von Ebenengleichungen aufzustellen, von denen verschiedene Attribute interpoliert werden können. Die Rasterungsstufe 660 kann ebenfalls eine Abdeckungsmaske für eine Mehrzahl von Pixeln berechnen, die angibt, ob eine oder mehrere Abtastorte für das Pixel die geometrische Primitive schneiden. In einer Ausführungsform kann auch z-Testen durchgeführt werden, um zu bestimmen, ob die geometrische Primitive von anderen geometrischen Primitiven verdeckt wird, die bereits gerastert wurden. Die Rasterungsstufe 660 erzeugt Fragmentdaten (d.h. interpolierte Vertexattribute, die einem bestimmten Abtastort für jedes abgedeckte Pixel zugeordnet sind), die an die Fragment-Shading-Stufe 670 übertragen werden.
• Die Fragment-Shading-Stufe 670 verarbeitet Fragmentdaten durch Durchführen eines Satzes von Operationen (d.h. eines Fragment-Shader oder eines Programms) an jedem der Fragmente. Die Fragment-Shading-Stufe 670 kann Pixeldaten (d.h. Farbenwerte) für das Fragment erzeugen, wie beispielsweise durch Durchführen von Beleuchtungs-Operationen oder Abtasten von Texturabbildungen unter Verwendung von interpolierten Texturkoordinaten für das Fragment. Die Fragment-Shading-Stufe 670 erzeugt Pixeldaten, die an die Raster-Operationen-Stufe 680 übertragen werden.
• Die Raster-Operationen-Stufe 680 kann verschiedene Operationen an den Pixeldaten durchführen, wie beispielsweise Alpha-Tests, Stencil-Tests und Mischung der Pixeldaten mit anderen Pixeldaten, die anderen Fragmente entsprechen, die dem Pixel zugeordnet sind. Wenn die Raster-Operationen-Stufe 680 die Verarbeitung der Pixeldaten (d.h. der Ausgangsdaten 602) beendet hat, können die Pixeldaten in ein Render-Ziel, wie beispielsweise einen Frame-Puffer, einen Farbenpuffer oder dergleichen, geschrieben werden.
• Es wird anerkannt, dass eine oder mehrere zusätzliche Stufen in der Graphikverarbeitungs-Pipeline 600 zusätzlich zu oder anstatt einer oder mehrerer der oben beschriebenen Stufen umfasst sein können. Verschiedene Implementierungen der abstrakten Graphikverarbeitungs-Pipeline können unterschiedliche Stufen implementieren. Des Weiteren können eine oder mehrere der oben beschriebenen Stufen der Graphikverarbeitungs-Pipeline in einigen Ausführungsformen (wie beispielsweise der Geometrie-Shading-Stufe 640) ausgeschlossen sein. Andere Arten von Graphikverarbeitungs-Pipelines werden betrachtet, als innerhalb des Schutzumfangs der vorliegenden Offenbarung zu liegen. Des Weiteren können beliebige der Stufen der Graphikverarbeitungs-Pipeline 600 von einer oder mehreren dedizierten Hardwareeinheiten innerhalb eines Graphikprozessors, wie beispielsweise der PPU 300, implementiert werden. Andere Stufen der Graphikverarbeitungs-Pipeline 600 können durch programmierbare Hardwareeinheiten, wie beispielsweise dem SM 440 der PPU 300, implementiert werden.
• Die Graphikverarbeitungs-Pipeline 600 kann über eine Anwendung implementiert werden, die von einem Host-Prozessor, wie beispielsweise einer CPU 550, ausgeführt wird. In einer Ausführungsform kann ein Vorrichtungstreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, die verschiedene Funktionen definiert, die von einer Anwendung benutzt werden können, um graphische Daten zur Anzeige zu erzeugen. Der Vorrichtungstreiber ist ein Softwareprogramm, das eine Mehrzahl von Anweisungen umfasst, die den Betrieb der PPU 300 steuern. Die API stellt eine Abstraktion für einen Programmierer bereit, die einem Programmierer erlaubt, spezialisierte Graphikhardware zu benutzen, wie beispielsweise die PPU 300, um die graphischen Daten zu erzeugen, ohne zu verlangen, dass der Programmierer den spezifischen Anweisungssatz für die PPU 300 benutzen muss. Die Anwendung kann einen API-Aufruf umfassen, der an den Vorrichtungstreiber für die PPU 300 weitergeleitet wird. Der Vorrichtungstreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu antworten. In einigen Fällen kann der Vorrichtungstreiber Operationen durch Ausführen von Anweisungen auf der CPU durchführen. In anderen Fällen kann der Vorrichtungstreiber Operationen, zumindest teilweise, durch Starten von Operationen auf der PPU 300 durchführen, wobei eine Eingang/Ausgabe-Schnittstelle zwischen der CPU und der PPU 300 benutzt wird. In einer Ausführungsform ist der Vorrichtungstreiber konfiguriert, um die Graphikverarbeitungs-Pipeline 600 unter Benutzung der Hardware der PPU 300 zu implementieren.
• Verschiedene Programme können innerhalb der PPU 300 ausgeführt werden, um die verschiedenen Stufen der Graphikverarbeitungs-Pipeline 600 zu implementieren. Beispielsweise kann der Vorrichtungstreiber ein Kernel auf der PPU 300 starten, um die Vertex-Shading-Stufe 620 auf einem SM 440 (oder mehreren SMs 440) durchzuführen. Der Vorrichtungstreiber (oder den von der PPU 300 ausgeführten Anfangskernel) kann ebenfalls andere Kernels auf der PPU 300 starten, um andere Stufen der Graphikverarbeitungs-Pipeline 600 durchzuführen, wie beispielsweise die Geometrie-Shading-Stufe 640 und die Fragment-Shading-Stufe 670. Außerdem können einige der Stufen der Graphikverarbeitungs-Pipeline 600 auf einer festen Hardwareeinheit implementiert werden, wie beispielsweise einem Rasterer oder einem Daten-Assembler, der innerhalb der PPU 300 implementiert ist. Es wird anerkannt, dass Ergebnisse von einem Kernel durch eine oder mehrere intervenierende Festfunktions-Hardwareeinheiten verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einem SM 440 verarbeitet werden.

Claims (15)

1. Verfahren zum Rendering eines Lichtfeldes, umfassend: Projizieren von Strahlen von einem Blickpunkt einer virtuellen Kameraposition, wobei der Blickpunkt an einer ersten Seite eines räumlichen Lichtmodulator (SLM) positioniert ist, zu einer Abschneideebene, die an einer gegenüberliegenden Seite des SLM positioniert ist, um einen elementaren Betrachtungsstumpf innerhalb einer dreidimensionalen Szene zu bilden, wobei der SLM mit einer Anordnung von nichtüberlappenden Elementarbereichen gekachelt ist, und ein oberer Rand und ein unterer Rand eines ersten Elementarbereichs der nichtüberlappenden Elementarbereiche werden von den Strahlen geschnitten, um den elementaren Betrachtungsstumpf zu bilden; wobei die virtuelle Kameraposition einen lateralen Versatz entfernt von dem räumlichen Modulator angeordnet ist, der größer 0 ist, wobei der laterale Versatz berechnet wird basierend auf einer Pixelrastergröße des SLM und einer Breite eines holographischen Elements, wobei eine Anordnung von holographischen Elementen eine Oberfläche des SLM abdeckt und Rendering von Objekten innerhalb des elementaren Betrachtungsstumpfes, um Komponenten eines ersten Elementarbildes für den ersten Elementarbereich zu erzeugen, wobei das Lichtfeld das erste Elementarbild und zusätzliche Elementarbilder umfasst, die der Anordnung von Elementarbereichen entsprechen, und jeweils eines der zusätzlichen Elementarbilder unter Verwendung eines zusätzlicher elementaren Betrachtungsstumpfs gerendert wird.
2. Verfahren gemäß Anspruch 1, wobei das Rendering für jedes Pixel des SLM innerhalb des ersten Elementarbereichs umfasst: Projizieren zweiter Strahlen von dem Pixel des SLM zu der Abschneideebene, um einen Pixelbeugungskegel zu definieren, der eine Basis einer ersten Breite aufweist; und Entfernen eines Abschnitts der Komponenten des ersten Elementarbildes, die außerhalb des Pixelbeugungskegels sind.
3. Verfahren gemäß Anspruch 1 oder 2, wobei die Komponenten Farbe und Position im dreidimensionalen Raum umfassen.
4. Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Komponenten Phase und Amplitude umfassen.
5. Verfahren gemäß Anspruch 4, ferner umfassend Berechnen der Phase und Amplitude als ein Produkt einer Objektwelle und einer konjugierten Bezugswelle, die einer Planwellenbeleuchtungsquelle entspricht.
6. Verfahren gemäß Anspruch 4, ferner umfassend Berechnen der Phase und Amplitude als ein Produkt einer Objektwelle und einer konjugierten Bezugswelle, die einer Kugelwellenbeleuchtungsquelle entspricht.
7. Verfahren zum Rendering eines Lichtfeldes, umfassend: Berechnen eines lateralen Versatzes größer null zwischen einer Blickposition und einem räumlichen Lichtmodulator (SLM) basierend auf einer Pixelrastergröße des SLM und einer Breite eines holographischen Elements, wobei eine Anordnung von holographischen Elementen eine Oberfläche des SLM abdeckt; und Rendering einer dreidimensionalen Szene von der Blickposition, um eine Anordnung von Elementarbildern zu erzeugen.
8. Verfahren gemäß Anspruch 7, wobei für mindestens ein Elementarbild der Anordnung von Elementarbildern das Rendering umfasst: Berechnen einer Farbenanordnung und einer Tiefenanordnung, die dem mindestens einen Elementarbild entsprechen.
9. Verfahren gemäß Anspruch 8, ferner umfassend: Berechnen eines Phasenwerts für ein Pixel des SLM basierend auf mindestens einem Tiefenwert der Tiefenanordnung.
10. Verfahren gemäß Anspruch 8 oder 9, ferner umfassend: Berechnen einer Amplitude für ein Pixel des SLM basierend auf mindestens einem entsprechenden Farbenwert der Farbenanordnung.
11. Verfahren gemäß einem der Ansprüche 7 bis 10, ferner umfassend Berechnen einer Phase und einer Amplitude für ein Pixel des SLM als ein Produkt einer Objektwelle und einer konjugierten Bezugswelle, die einer Kugelwellenbeleuchtungsquelle entspricht.
12. Verfahren gemäß einem der Ansprüche 7 bis 11, wobei das Rendering ein Projizieren von Strahlen von dem Pixel des SLM zu der Abschneideebene umfasst, um einen Pixelbeugungskegel zu definieren, der eine Basis einer Breite aufweist.
13. Verfahren gemäß Anspruch 12, ferner umfassend: Entfernen eines Abschnitts der Komponenten des ersten Elementarbilds, die außerhalb des Pixelbeugungskegels sind.
14. System zum Rendering eines Lichtfeldes, umfassend: einen räumlichen Lichtmodulator (SLM); und eine Verarbeitungseinheit, die mit dem SLM gekoppelt und konfiguriert ist, um ein Verfahren auszuführen, wie in einem der Ansprüche 1 bis 13 erwähnt.
15. System gemäß Anspruch 14, wobei die Verarbeitungseinheit eine graphische Verarbeitungseinheit umfasst.

Images