DE112017004918T5

DE112017004918T5 - Hybrides Stereo-Rendering für Tiefenverlängerung in dynamischen Lichtfeldanzeigen

Info

Publication number: DE112017004918T5
Application number: DE112017004918.0T
Authority: DE
Inventors: Joshua J. Ratcliff; Tuotuo LI
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2016-09-29
Filing date: 2017-08-21
Publication date: 2019-06-06
Also published as: US11483543B2; CN109644260A; US20180091800A1; CN109644260B; CN113923433A; WO2018063579A1; US10623723B2; US20200304776A1

Abstract

Ein Gerät und Verfahren für hybrides Rendering. Zum Beispiel weist eine Ausführungsform eines Verfahrens Folgendes auf: Identifizieren der linken und rechten Sicht der Augen einer Benutzerperson; Erstellen mindestens einer Tiefenkarte für die linke und rechte Sicht; Berechnen von Tiefen-Clamping-Schwellenwerten, die einen Mindesttiefenwert und einen Maximaltiefenwert aufweisen; Umwandeln der Tiefenkarte gemäß dem Mindesttiefenwert und dem Maximaltiefenwert; und Durchführen von Sichtsynthese zum Rendern von linker und rechter Sicht unter Verwendung der umgewandelten Tiefenkarte.

Description

HINTERGRUND
Gebiet der Erfindung
Diese Erfindung betrifft im Allgemeinen das Gebiet von Rechenprozessoren. Insbesondere betrifft die Erfindung ein Gerät und Verfahren für hybrides Stereo-Rendering für Tiefenverlängerung in dynamischen Lichtfeldanzeigen.
Beschreibung der verwandten Technik
Virtual Reality (VR) betrifft Datenverarbeitungstechnologien, die eine reale oder imaginäre Umgebung durch Simulieren der körperlichen Anwesenheit einer Benutzerperson in dieser Umgebung replizieren und bei manchen Implementierungen wird es der Benutzerperson ermöglicht, mit der Umgebung zu interagieren. Viele derzeitige VR-Umgebungen werden entweder auf einem Computerbildschirm oder mit einem speziellen Virtual-Reality-Headset angezeigt. Manche Simulationen weisen zusätzliche sensorische Informationen auf, wie zum Beispiel Ton über Lautsprecher oder Kopfhörer, die auf VR-Benutzerpersonen gerichtet sind.
Lichtfeldanzeigen sind eine aufkommende Art der Anzeigentechnologie, die Bilder sowohl mit räumlicher als auch Winkelauflösung (sichtabhängig) bieten. Sie bieten Potential für „fast holografische“ visuelle Wiedergabetreue. Dazu zählen eine Vielfalt an Tiefenhinweisen, wie zum Beispiel Bewegungsparallaxe, Retina-Unschärfe, Akkomodation, als auch brillenlose Stereopsis. Auch wenn unklar bleibt, welche Lichtfeldarchitektur erfolgreich sein wird, bedingen alle Design-Kompromisse für räumliche Auflösung, Winkelauflösung und effektive Schärfentiefe (wie „tief“ das 3D-Bild wahrgenommen wird).
Zurzeit werden Lichtfeldanzeigen unter Verwendung von Content, der auf die Schärfentiefe (die heutzutage eher oberflächlich sein kann) beschränkt ist, betrieben, wobei Content außerhalb des Bereichs vorsichtig defokussiert und/oder eliminiert wird, um Aliasing-Artefakte (aufgrund von inadäquater Winkelabtastung) zu reduzieren. Anzeigen können für große Schärfentiefe ausgelegt sein, aber beinahe immer zu Lasten der Vertiefung räumlicher Auflösung und/oder der Sweetspot-Größe des Betrachtungsbereichs.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung kann von der folgenden detaillierten Beschreibung in Verbindung mit den folgenden Zeichnungen erhalten werden, in denen:

1 ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor, der einen oder mehrere Prozessorkerne aufweist, und Grafikprozessoren ist;
2 ein Blockdiagramm einer Ausführungsform eines Prozessors mit einem oder mehreren Prozessorkernen, einer integrierten Speichersteuerung; und einem integrierten Grafikprozessor ist;
3 ein Blockdiagramm einer Ausführungsform eines Grafikprozessors, bei dem es sich um eine diskrete Grafikverarbeitungseinheit handeln kann, oder um einen Grafikprozessor mit einer Vielzahl an Verarbeitungskernen handeln kann, ist;
4 ein Blockdiagramm einer Ausführungsform einer Grafikverarbeitungsmaschine für einen Grafikprozessor ist;
5 ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors ist;
6 ein Blockdiagramm einer Thread-Ausführungs-Logik, die eine Anordnung an Verarbeitungselementen aufweist, ist;
7 ein Grafikprozessor-Ausführungseinheitsinstruktionsformat gemäß einer Ausführungsform veranschaulicht;
8 ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors, der eine Grafik-Pipeline, eine Medien-Pipeline, eine Display-Engine, eine Thread-Ausführungs-Logik und eine Render-Ausgabe aufweist, ist;
9A ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat gemäß einer Ausführungsform veranschaulicht, ist;
9B ein Blockdiagramm, das eine Grafikprozessor-Befehlssequenz gemäß einer Ausführungsform veranschaulicht, ist;
10 eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einer Ausführungsform veranschaulicht;
11 ein beispielhaftes IP-Kernentwicklungssystem, das zur Herstellung einer integrierten Schaltung zum Durchführen von Operationen verwendet werden kann, gemäß einer Ausführungsform veranschaulicht;
12 ein beispielhaftes System auf einer integrierten Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt sein kann, gemäß einer Ausführungsform veranschaulicht;
13A einen beispielhaften Anzeigenbildschirm mit einer Diffusionseigenschaft veranschaulicht;
13B Tiefenbereiche für Stereo-3D-Rendering, Lichtfeldanzeigen-Rendering, und Hybrid-Rendering gemäß einer Ausführungsform veranschaulicht;
14A eine Architektur gemäß einer Ausführungsform der Erfindung veranschaulicht;
14B beispielhafte Stereo- und fastholografische Zonen für ein Lichtfeld-Head-Mounted-Display (HMD) veranschaulicht;
14C eine beispielhafte Sehbox, unterteilt in einen linken Sehbereich und einen rechten Sehbereich, veranschaulicht;
14D eine Ausführungsform, die Zeit-Multiplexing mit gerichtetem Gegenlicht verwendet, veranschaulicht;
14E eine beispielhafte 3D-Szene-Pipeline veranschaulicht; und
15 ein Verfahren ein Verfahren gemäß einer Ausführungsform der Erfindung veranschaulicht.

DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung werden zum Zweck der Erklärung zahlreiche spezifische Details präsentiert, um ein umfassendes Verständnis der Ausführungsformen der Erfindung, die unten beschrieben ist, bereitzustellen. Einer Fachperson ist jedoch ersichtlich, dass die Ausführungsformen der Erfindung ohne manche dieser spezifischen Details umgesetzt werden kann. Zum Beispiel sind gut bekannte Strukturen und Vorrichtungen in Blockdiagrammform gezeigt, um zu vermeiden, dass zugrundeliegende Prinzipien der Ausführungsformen der Erfindung verdeckt werden.
BEISPIELHAFTE GRAFIKPROZESSORARCHITEKTUREN UND DATENTYPEN
Systemüberblick
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. Bei verschiedenen Ausführungsformen weist das System 100 einen oder mehrere Prozessoren 102 und einen oder mehrere Grafikprozessoren 108 auf und kann ein Einzelprozessor-Desktopsystem, ein Multiprozessor-Workstation-System oder ein Serversystem mit einer großen Anzahl an Prozessoren 102 oder Prozessorkernen 107 sein. Bei einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in einer integrierten System-on-a-Chip(SoC-)Schaltung für Verwendung in mobilen, handheld oder eingebetteten Vorrichtungen eingebaut ist.
Eine Ausführungsform des Systems 100 kann eine serverbasierte Gaming-Plattform, eine Spielkonsole, darunter eine Spiel- und Mediakonsole, eine mobile Spielkonsole, eine handheld Spielkonsole oder eine online Spielkonsole aufweisen oder darin eingebaut sein. Bei manchen Ausführungsformen ist das System 100 eine mobile, Telefon-, Smartphone-, Tablet-Computer-Vorrichtung oder eine mobile Internetvorrichtung. Das Datenverarbeitungssystem 100 kann auch eine tragbare Vorrichtung, wie zum Beispiel eine tragbare Smartwatch-Vorrichtung, eine Smart-Eyewear-Vorrichtung, eine Augmented-Reality-Vorrichtung oder eine Virtual-Reality-Vorrichtung aufweisen, damit gekoppelt sein oder damit integriert sein. Bei manchen Ausführungsformen ist das Datenverarbeitungssystem 100 ein Fernseher oder eine Set-Top-Box-Vorrichtung mit einem oder mehreren Prozessoren 102 und einer Grafikschnittstelle, die von einem der mehreren Grafikprozessoren 108 erstellt wird.
Bei manchen Ausführungsformen weisen der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 zum Verarbeiten von Instruktionen auf, die bei Ausführung Operationen für System- und Benutzersoftware durchführen. Bei manchen Ausführungsformen sind ein oder mehrere Prozessorkerne 107 dazu ausgelegt, einen spezifischen Instruktionssatz 109 zu verarbeiten. Bei manchen Ausführungsformen kann der Instruktionssatz 109 Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC) oder Computing über ein Very Long Instruction Word (VLIW) ermöglichen. Mehrere Prozessorkerne 107 können jeweils einen unterschiedlichen Instruktionssatz 109 verarbeiten, der Instruktionen aufweisen kann, um die Emulation anderer Instruktionssätze zu ermöglichen. Der Prozessorkern 107 kann auch weitere Verarbeitungsvorrichtungen aufweisen, wie zum Beispiel einen digitalen Signalprozessor (DSP).
Bei manchen Ausführungsformen weist der Prozessor 102 einen Cache-Speicher 104 auf. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Levels an internen Caches aufweisen. Bei manchen Ausführungsformen teilen sich verschiedene Komponenten des Prozessors 102 den Cache-Speicher. Bei manchen Ausführungsformen kann der Prozessor 102 auch einen externen Cache (zum Beispiel einen Level-3(L3-)Cache oder Last-Level-Cache (LLC)) (nicht gezeigt) verwenden, der von Prozessorkernen 107 unter Verwendung bekannter Cache-Kohärenz-Techniken geteilt wird. Eine Registerdatei 106 ist zusätzlich in dem Prozessor 102 enthalten, die unterschiedliche Arten von Registern zum Speichern unterschiedlicher Typen von Daten aufweisen kann (zum Beispiel Ganzzahlregister, Gleitkommaregister, Zustandsregister und ein Instruktionszeigerregister). Manche Register können Allzweck-Register sein, während andere Register spezifisch für das Design des Prozessors 102 sein können.
Bei manchen Ausführungsformen ist der Prozessor 102 mit einem Prozessor-Bus 110 gekoppelt, um Kommunikationssignale, wie zum Beispiel Adress-, Datender Steuersignale, zwischen dem Prozessor 102 und weiteren Komponenten in dem System 100 zu übertragen. Bei einer Ausführungsform verwendet das System 100 eine beispielhafte „Hub-“Systemarchitektur, darunter einen Speichersteuer-Hub 116 und einen Eingabe/Ausgabe(E/A-)Steuer-Hub 130. Ein Speichersteuer-Hub 116 ermöglicht Kommunikation zwischen einer Speichervorrichtung und weiteren Komponenten des Systems 100, während ein E/A-Steuer-Hub (ICH) 130 Verbindungen mit E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt. Bei einer Ausführungsform ist die Logik des Speichersteuer-Hubs 116 mit dem Prozessor integriert.
Die Speichervorrichtung 120 kann eine DRAM(dynamischer Direktzugriffsspeicher)-Vorrichtung, eine SRAM(statistischer Direktzugriffsspeicher)-Vorrichtung, eine Flash-Speicher-Vorrichtung, eine Phasenwechselspeicher-Vorrichtung oder eine beliebige Speichervorrichtung mit geeigneter Leistung, um als Prozessspeicher zu dienen, sein. Bei einer Ausführungsform kann die Speichervorrichtung 120 als Systemspeicher für das System 100 arbeiten, um Daten 122 und Instruktionen 121 für Verwendung, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen, zu speichern. Der Speichersteuer-Hub 116 kann auch mit einem optionalen externen Grafikprozessor 112 gekoppelt werden, der mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen.
Bei manchen Ausführungsformen ermöglicht der ICH 130, dass Peripheriegeräte über einen Hochgeschwindigkeits-E/A-Bus mit der Speichervorrichtung 120 und dem Prozessor 102 verbunden werden. Zu den E/A-Peripheriegeräten zählen, unter anderem, eine Audio-Steuerung 146, eine Firmware-Schnittstelle 128, ein drahtloser Sendeempfänger 126 (zum Beispiel Wi-Fi, Bluetooth), eine Datenspeichervorrichtung 124 (zum Beispiel ein Festplattenlaufwerk, ein Flash-Speicher usw.) und eine Legacy-E/A-Steuerung 140 zum Koppeln von Legacy-Vorrichtungen (zum Beispiel Personal System 2 (PS/2)) mit dem System. Eine oder mehrere USB(universeller serieller Bus)-Steuerungen 142 verbinden Eingabevorrichtungen, wie zum Beispiel Kombinationen aus Tastatur und Maus 144. Eine Netzwerksteuerung 134 kann auch mit dem ICH 130 verbunden werden. Bei manchen Ausführungsformen wird eine Hochleistungs-Netzwerksteuerung (nicht gezeigt) mit dem Prozessor-Bus 110 gekoppelt. Es ist ersichtlich, dass das System 100, das gezeigt ist, beispielhaft und nicht beschränkend ist, da auch andere Arten von Datenverarbeitungssystemen, die unterschiedlich konfiguriert sind, verwendet werden können. Zum Beispiel kann der E/A-Steuer-Hub 130 in dem einen oder den mehreren Prozessoren 102 integriert sein oder der Speichersteuer-Hub 116 und der E/A-Steuer-Hub 130 können in einem diskreten externen Grafikprozessor, wie zum Beispiel dem externen Grafikprozessor 112, integriert sein.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A bis 202N, einer integrierten Speichersteuerung 214 und einem integrierten Grafikprozessor 208. Diese Elemente in 2, die dieselben Bezugszeichen (oder Namen) als die Elemente in irgendeiner anderen Figur hierin aufweisen, können in einer beliebigen Weise ähnlich der, die anderswo hierin beschrieben ist, arbeiten oder funktionieren, sind aber nicht darauf beschränkt. Der Prozessor 200 kann zusätzliche Kerne bis zu und inklusive dem zusätzlichen Kern 202N aufweisen, wie durch Kästchen aus gestrichelten Linien dargestellt. Jeder der Prozessorkerne 202A bis 202N weist eine oder mehrere interne Cache-Einheiten 204A bis 204N auf. Bei manchen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf eine oder mehrere gemeinsame Cache-Einheiten 206.
Die internen Cache-Einheiten 204A bis 204N und die gemeinsamen Cache-Einheiten 206 stellen eine Cache-Speicherhierarchie in dem Prozessor 200 dar. Die Cache-Speicherhierarchie kann mindestens ein Level an Instruktions- und Daten-Cache in jedem Prozessorkern und ein oder mehrere Levels an gemeinsamen Mid-Level-Cache, wie zum Beispiel einen Level 2 (L2), Level 3 (L3), Level 4 (L4) oder weitere Levels an Cache, bei denen das höchste Level an Cache vor dem externen Speicher als der LLC klassifiziert ist, aufweisen. Bei manchen Ausführungsformen erhält Cache-Kohärenz-Logik Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A bis 204N aufrecht.
Bei manchen Ausführungsformen kann der Prozessor 200 auch einen Satz einer oder mehrerer Bus-Steuereinheiten 216 und einen System-Agent-Kern 210 aufweisen. Die eine oder die mehreren Bus-Steuereinheiten 216 verwalten einen Satz an peripheren Bussen, wie zum Beispiel einen oder mehrere Peripheral-Component-Interconnect-Busse (zum Beispiel PCI, PCI Express). Der System-Agent-Kern 210 stellt Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. Bei manchen Ausführungsformen weist der System-Agent-Kern 210 eine oder mehrere integrierte Speichersteuerungen 214 zum Verwalten von Zugriff auf verschiedene externe Speichervorrichtungen (nicht gezeigt) auf.
Bei manchen Ausführungsformen weisen einer oder mehrere der Prozessorkerne 202A bis 202N Unterstützung für gleichzeitiges Multi-Threading auf. Bei solchen Ausführungsformen weist der System-Agent-Kern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A bis 202N während Multi-Threaded-Processing auf. Der System-Agent-Kern 210 kann zusätzlich eine Leistungssteuereinheit (PCU) aufweisen, die Logik und Komponenten zum Regulieren des Leistungszustands der Prozessorkerne 202A bis 202N und des Grafikprozessors 208 aufweist.
Bei manchen Ausführungsformen weist der Prozessor 200 zusätzlich den Grafikprozessor 208 zum Ausführen von Grafikverarbeitungsoperationen auf. Bei manchen Ausführungsformen wird der Grafikprozessor 208 mit dem Satz gemeinsamer Cache-Einheiten 206 und dem System-Agent-Kern 210, der die eine oder die mehreren integrierten Speichersteuerungen 214 aufweist, gekoppelt. Bei manchen Ausführungsformen wird eine Anzeigesteuerung 211 mit dem Grafikprozessor 208 gekoppelt, um Grafikprozessorausgabe zu einer oder mehreren gekoppelten Anzeigen zu leiten. Bei manchen Ausführungsformen kann die Anzeigesteuerung 211 ein getrenntes Modul sein, das über mindestens ein Interconnect mit dem Grafikprozessor gekoppelt ist oder in dem Grafikprozessor 208 oder dem System-Agent-Kern 210 integriert ist.
Bei manchen Ausführungsformen wird eine ringbasierte Interconnect-Einheit 212 zum Koppeln der internen Komponenten des Prozessors 200 verwendet. Eine alternative Interconnect-Einheit kann jedoch verwendet werden, wie zum Beispiel ein Punkt-zu-Punkt-Interconnect, ein switched Interconnect oder andere Techniken, darunter Techniken die gut in der Technik bekannt sind. Bei manchen Ausführungsformen wird der Grafikprozessor 208 über einen E/A-Link 213 mit dem Ring-Interconnect 212 gekoppelt.
Der beispielhafte E/A-Link 213 stellt mindestens eine mehrerer Varianten von E/A-Interconnects dar, darunter ein On-Package-E/A-Interconnect, das Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungs-Speichermodul 218, wie zum Beispiel einem eDRAM-Modul, ermöglicht. Bei manchen Ausführungsformen verwenden jeder der Prozessorkerne 202A bis 202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als einen gemeinsamen Last-Level-Cache.
Bei manchen Ausführungsformen sind die Prozessorkerne 202A bis 202N homogene Kerne, die die gleiche Instruktionssatzarchitektur ausführen. Bei einer weiteren Ausführungsform sind die Prozessorkerne 202A bis 202N heterogen im Sinne der Instruktionssatzarchitektur (ISA), bei der einer oder mehrere der Prozessorkerne 202A bis 202N einen ersten Instruktionssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Instruktionssatzes oder einen unterschiedlichen Instruktionssatz ausführt. Bei einer Ausführungsform sind die Prozessorkerne 202A bis 202N heterogen im Sinne der Mikroarchitektur, bei der ein oder mehrere Kerne mit einem relativ höheren Leistungsverbrauch mit einem oder mehreren Kernen mit einem niedrigeren Leistungsverbrauch gekoppelt werden. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte SoC-Schaltung, die die veranschaulichten Komponenten aufweist, zusätzlich zu weiteren Komponenten, implementiert werden.
3 ist ein Blockdiagramm eines Grafikprozessors 300, bei dem es sich um eine diskrete Grafikverarbeitungseinheit handeln kann, oder um einen Grafikprozessor, der mit einer Vielzahl an Verarbeitungskernen integriert ist, handeln kann. Bei manchen Ausführungsformen kommuniziert der Grafikprozessor über eine Memory-Mapped-E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die in dem Prozessorspeicher platziert werden. Bei manchen Ausführungsformen weist der Grafikprozessor 300 eine Speicherschnittstelle 314 zum Speicherzugriff auf. Die Speicherschnittstelle 314 kann eine Schnittstelle mit einem lokalen Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsamen externen Caches und/oder dem Systemspeicher sein.
Bei manchen Ausführungsformen weist der Grafikprozessor 300 außerdem eine Anzeigesteuerung 302 zum Leiten von Anzeigeausgabedaten zu einer Anzeigevorrichtung 320 auf. Die Anzeigesteuerung 302 weist Hardware für eine oder mehrere Overlay-Ebenen für die Anzeige und Komposition von mehreren Schichten von Video- oder Benutzerschnittstellenelementen auf. Bei manchen Ausführungsformen weist der Grafikprozessor 300 eine Video-Codec-Engine 306 zum Codieren, Decodieren oder Umcodieren von Medien zu, von oder zwischen einem oder mehreren Medienverschlüsselungsformaten, darunter unter anderem Moving-Picture-Experts-Group(MPEG-)Formate, wie zum Beispiel MPEG-2, Advanced-Video-Coding(AVC-)Formate, wie zum Beispiel H.264/MPEG-4 AVC, als auch Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1-, und Joint-Photographic-Experts-Group(JPEG-)Formate, wie zum Beispiel JPEG und Motion-JPEG(MJPEG-)Formate, auf.
Bei manchen Ausführungsformen weist der Grafikprozessor 300 eine Block-Image-Transfer(BLIT-)Engine 304 zum Durchführen zweidimensionaler (2D-) Rasteroperationen, darunter unter anderem Bit-Boundary-Blocktransfers, auf. Bei einer Ausführungsform werden 2D-Grafikoperationen jedoch unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE) 310 durchgeführt. Bei manchen Ausführungsformen ist die Grafikverarbeitungs-Engine 310 eine Computer-Engine zum Durchführen von Grafikoperationen, darunter dreidimensionale (3D-) Grafikoperationen und Medienoperationen.
Bei manchen Ausführungsformen, weist die GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen auf, wie zum Beispiel dem Rendering von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen wirken (zum Beispiel Rechteck, Dreieck usw.). Die 3D-Pipeline 312 weist programmierbare und festgelegte Funktionselemente auf, die verschiedene Aufgaben in den Elementen durchführen und/oder Ausführungs-Threads an ein 3D-/Medien-Untersystem 315 spawnt. Auch wenn die 3D-Pipeline 312 zum Durchführen von Medienoperationen verwendet werden kann, weist eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316 auf, die spezifisch dazu verwendet wird, Medienoperationen durchzuführen, wie zum Beispiel Video-Nachverarbeitung und Bildverbesserung.
Bei manchen Ausführungsformen weist die Medien-Pipeline 316 festgelegte Funktions- oder programmierbare Logikeinheiten auf, um eine oder mehrere spezialisierte Medienoperationen durchzuführen, wie zum Beispiel Video-Dekodierungsbeschleunigung, Video-Schnittstellentrennung und Video-Codierungsbeschleunigung statt oder seitens der Video-Codec-Engine 306. Bei manchen Ausführungsformen weist die Medien-Pipeline 316 zusätzlich eine Thread-Spawn-Einheit zum Spawnen von Threads für Ausführung auf einem 3D-/Medien-Untersystem 315 auf. Die spawnt Threads führen Rechnen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten, die sich in dem 3D-/Medien-Untersystem 315 befinden, aus.
Bei manchen Ausführungsformen weist das 3D-/Medien-Untersystem 315 Logik zum Ausführen von Threads, die von der 3D-Pipeline und der Medien-Pipeline 316 gespawnt werden, auf. Bei einer Ausführungsform senden die Pipelines Thread-Ausführungsanfragen an das 3D-/Medien-Untersystem 315, das Thread-Verteilungslogik zum Schlichten und Versenden der verschiedenen Anfragen an verfügbare Thread-Ausführungsressourcen aufweist. Die Ausführungsressourcen weisen eine Anordnung an Grafikausführungseinheiten zum Verarbeiten der 3D- und Medien-Threads auf. Bei manchen Ausführungsformen weist das 3D-/Medien-Untersystem 315 einen oder mehrere interne Caches für Thread-Ausführungen und Daten auf. Bei manchen Ausführungsformen weist das Untersystem auch einen gemeinsamen Speicher auf, der Register und adressierbaren Speicher aufweist, um Daten zwischen Threads zu teilen und Ausgabedaten zu speichern.
D-/Medienverarbeitung
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors gemäß einiger Ausführungsformen. Bei einer Ausführungsform ist die GPE 410 eine Version der GPE 310, die in 3 gezeigt ist. Elemente aus 4, die dieselben Bezugszeichen (oder Namen) als die Elemente in irgendeiner anderen Figur hierin aufweisen, können in einer beliebigen Weise ähnlich der, die anderswo hierin beschrieben ist, arbeiten oder funktionieren, sind aber nicht darauf beschränkt.
Bei manchen Ausführungsformen wird die GPE 410 mit einem Befehls-Bandlaufwerk 403 gekoppelt, das einen Befehlsstrom an die GPE-3D- und Medien-Pipelines 412, 416 bereitstellt. Bei manchen Ausführungsformen wird das Befehls-Bandlaufwerk 403 mit dem Speicher gekoppelt, bei dem es sich um einen Systemspeicher oder einen oder mehrere interne Cache-Speicher und gemeinsame Cache-Speicher handeln kann. Bei manchen Ausführungsformen empfängt das Befehls-Bandlaufwerk 403 Befehle von dem Speicher und sendet die Befehle an die 3D-Pipeline 412 und/oder Medien-Pipeline 416. Die Befehle sind Anweisungen, die von einem Ring-Puffer gefetcht werden, der Befehle für die 3D- und Medien-Pipelines 412, 416 speichert. Bei einer Ausführungsform kann der Ring-Puffer zusätzlich Batch-Befehls-Puffer aufweisen, der Batches von mehreren Befehlen speichert. Die 3D- und Medien-Pipelines 412, 416 verarbeiten die Befehle mittels Durchführens von Operationen über Logik in den jeweiligen Pipelines oder mittels Versendens eines oder mehrerer Ausführungs-Threads an eine Ausführungseinheitsanordnung 414. Bei manchen Ausführungsformen ist die Ausführungseinheitsanordnung 414 derart skalierbar, dass die Anordnung eine variable Anzahl an Ausführungseinheiten basierend auf der Zielleistung und dem Leistungsniveau der GPE 410 aufweist.
Bei manchen Ausführungsformen wird eine Abtastmaschine 430 mit dem Speicher (zum Beispiel einem Cache-Speicher oder Systemspeicher) und einer Ausführungseinheitsanordnung 414 gekoppelt. Bei manchen Ausführungsformen stellt die Abtastmaschine 430 einen Speicherzugriffsmechanismus für die Ausführungseinheitsanordnung 414 bereit, was es der Ausführungsanordnung 414 gestattet, Grafik- und Mediendaten von dem Speicher auszulesen. Bei manchen Ausführungsformen weist die Abtastmaschine 430 Logik zum Durchführen von spezialisierten Bildabtastoperationen für Medien auf.
Bei manchen Ausführungsformen weist die spezialisierte Medienabtastlogik in der Abtastmaschine 430 ein Rauschunterdrückungs-/Schnittstellenentfernungs-Modul 432, ein Bewegungsschätzmodul 434 und ein Bildskalier- und - Filtermodul 436 auf. Bei manchen Ausführungsformen weist das Rauschunterdrückungs-/Schnittstellenentfernungs-Modul 432 Logik zum Durchführen eines oder mehrerer eines Rauschunterdrückungs- oder eines Schnittstellenentfernungs-Algorithmus auf decodierten Video-Daten auf. Die Schnittstellenentfernungs-Logik kombiniert alternierende Felder von verflochtenem Videoinhalt in ein einzelnes Videobild. Die Rauschunterdrückungs-Logik reduziert oder entfernt Datenrauschen von Video- und Bilddaten. Bei manchen Ausführungsformen sind die Rauschunterdrückungs-Logik und die Schnittstellenentfernungs-Logik bewegungsanpassbar und verwenden räumliches und zeitliches Filtern basierend auf der Menge an Bewegung, die in den Videodaten detektiert wird. Bei manchen Ausführungsformen weist das Rauschunterdrückungs-/Schnittstellenentfernungs-Modul 432 dedizierte Bewegungserkennungs-Logik (zum Beispiel in der Bewegungsschätzmaschine 434) auf.
Bei manchen Ausführungsformen stellt die Bewegungsschätzmaschine 434 Hardware-Beschleunigung für Video-Operationen durch Durchführen von Video-Beschleunigungsfunktionen, wie zum Beispiel Bewegungsvektorschätzung und -vorhersage auf Videodaten, bereit. Die Bewegungsschätzmaschine bestimmt Bewegungsvektoren, die die Umwandlung von Bilddaten zwischen aufeinanderfolgenden Videobildern bestimmen. Bei manchen Ausführungsformen verwendet ein Grafikprozessor-Medien-Codec die Videobewegungsschätzmaschine 434 zum Durchführen von Operationen auf Video auf dem Makroblocklevel, was ansonsten zu rechenintensiv zum Durchführen mit einem Allzweck-Prozessor sein kann. Bei manchen Ausführungsformen ist die Bewegungsschätzmaschine 434 im Allgemeinen für Grafikprozessorkomponenten verfügbar, um bei Video-Decodierung und - Verarbeitungsfunktionen zu helfen, die hinsichtlich der Richtung oder dem Ausmaß der Bewegung in den Videodaten sensible oder adaptiv sind.
Bei manchen Ausführungsformen führt das Bildskalierungs- und -filtermodul 436 Bildverarbeitungsoperationen durch, um die visuelle Qualität der erzeugten Bilder und des erzeugten Videos zu verbessern. Bei manchen Ausführungsformen verarbeitet das Skalierungs- und Filtermodul 436 Bild- und Video-Daten während der Abtastoperation bevor die Daten der Ausführungseinheitsanordnung 414 bereitgestellt werden.
Bei manchen Ausführungsformen weist die GPE 410 einen Datenport 444 auf, der einen zusätzlichen Mechanismus für Grafik-Untersysteme für Speicherzugriff bereitstellt. Bei manchen Ausführungsformen ermöglicht der Datenport 444 Speicherzugriff für Operationen, darunter Rendern von Zielschreibvorgängen, konstante Puffer-Lesevorgänge, Scratch-Speicherplatz-Lese/- Schreibvorgänge und Medienoberflächenzugriffe. Bei manchen Ausführungsformen weist der Datenport 444 Cache-Speicherplatz zum Cachen von Zugriffen auf den Speicher auf. Der Cache-Speicher kann ein Einzeldaten-Cache oder aufgeteilt in mehrere Caches für die mehreren Untersysteme, die über den Datenport zum Beispiel auf den Speicher zugreifen (zum Beispiel ein Render-Puffer-Cache, ein Konstant-Puffer-Cache usw.), sein. Bei manchen Ausführungsformen kommunizieren Threads, die auf einer Ausführungseinheit in der Ausführungseinheitsanordnung 414 ausgeführt werden, mit dem Datenport durch Austauschen von Nachrichten über ein Datenverteilungs-Interconnect, das jedes der Untersysteme der GPE 410 koppelt.
Ausführungseinheiten
5 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors 500. Elemente aus 5, die dieselben Bezugszeichen (oder Namen) als die Elemente in irgendeiner anderen Figur hierin aufweisen, können in einer beliebigen Weise ähnlich der, die anderswo hierin beschrieben ist, arbeiten oder funktionieren, sind aber nicht darauf beschränkt.
Bei manchen Ausführungsformen weist der Grafikprozessor 500 ein Ring-Interconnect 502, ein Pipeline-Frontend 504, eine Medien-Engine 537 und Grafikkerne 580A bis 580N auf. Bei manchen Ausführungsformen koppelt das Ring-Interconnect 502 den Grafikprozessor mit weiteren Verarbeitungseinheiten, darunter weiteren Grafikprozessoren oder einem oder mehreren Allzweck-Prozessorkernen. Bei manchen Ausführungsformen ist der Grafikprozessor einer von vielen Prozessoren, die in einem Multikern-Verarbeitungssystem integriert sind.
Bei manchen Ausführungsformen empfängt der Grafikprozessor 500 Batches von Befehlen über das Ring-Interconnect 502. Die eintreffenden Befehle werden von einem Befehls-Bandlaufwerk 503 in dem Pipeline-Frontend 504 interpretiert. Bei manchen Ausführungsformen weist der Grafikprozessor 500 eine skalierbare Ausführungslogik zum Durchführen von 3D-Geometrie-Verarbeitung und Medien-Verarbeitung über den/die Grafikkern(e) 580A bis 580N auf. Für 3D-Geometrie-Verarbeitungsbefehle stellt das Befehls-Bandlaufwerk 503 der Geometrie-Pipeline 536 Befehle bereit. Für mindestens einige Medien-Verarbeitungsbefehle stellt das Befehls-Bandlaufwerk 503 die Befehle einem Video-Frontend 534 bereit, das mit einer Medien-Engine 537 koppelt. Bei manchen Ausführungsformen weist die Medien-Engine 537 eine Video-Qualitäts-Engine (VQE) 530 für Video- und Bild-Nachverarbeitung und eine Multiformat-Codier/Decodier(MFX-)Engine 533 zum Bereitstellen von hardwarebeschleunigter Mediendaten-Codierung und -Decodierung auf. Bei manchen Ausführungsformen erstellen die Geometrie-Pipeline 536 und die Medien-Engine 537 jeweils Ausführungs-Threads für die Thread-Ausführungsressourcen, die von mindestens einem Grafikkern 580A bereitgestellt werden.
Bei manchen Ausführungsformen weist der Grafikprozessor 500 skalierbare Thread-Ausführungsressourcen auf, die modulare Kerne 580A bis 580N (manchmal als Kernschnitte bezeichnet) aufweisen, die jeweils mehrere Teilkerne 550A bis 550N, 560A bis 560N (manchmal als Kernteilschnitte bezeichnet) aufweisen. Bei manchen Ausführungsformen kann der Grafikprozessor 500 eine beliebige Anzahl an Grafikkernen 580A bis 580N aufweisen. Bei manchen Ausführungsformen weist der Grafikprozessor 500 einen Grafikkern 580A auf, der mindestens einen ersten Teilkern 550A und einen zweiten Kern-Teilkern 560A aufweist. Bei einer weiteren Ausführungsform ist der Grafikprozessor ein Low-Power-Prozessor mit einem einzelnen Teilkern (zum Beispiel 550A). Bei manchen Ausführungsformen weist der Grafikprozessor 500 mehrere Grafikkerne 580A bis 580N auf, wobei jeder einen Satz an ersten Teilkernen 550A bis 550N und einen Satz an zweiten Teilkernen 560A-560N aufweist. Jeder Teilkern in dem Satz an ersten Teilkernen 550A bis 550N weist mindestens einen ersten Satz an Ausführungseinheiten 552A bis 552N und Medien-/Texturabtastern 554A bis 554N auf. Jeder Teilkern in dem Satz an zweiten Teilkernen 560A bis 560N weist mindestens einen zweiten Satz an Ausführungseinheiten 562A-562N und Abtastern 554A bis 554N auf. Bei manchen Ausführungsformen teilt sich jeder Teilkern 550A bis 550N, 560A bis 560N einen Satz an gemeinsamen Ressourcen 570A bis 570N. Bei manchen Ausführungsformen weisen die gemeinsamen Ressourcen einen gemeinsamen Cache-Speicher und gemeinsame Pixel-Operations-Logik auf. Es können auch weitere gemeinsame Ressourcen in den verschiedenen Ausführungsformen des Grafikprozessors vorhanden sein.
6 veranschaulicht eine Thread-Ausführungseinheit 600, die eine Anordnung von Verarbeitungselementen, die in einigen Ausführungsformen einer GPE eingesetzt werden, aufweist. Elemente aus 6, die dieselben Bezugszeichen (oder Namen) als die Elemente in irgendeiner anderen Figur hierin aufweisen, können in einer beliebigen Weise ähnlich der, die anderswo hierin beschrieben ist, arbeiten oder funktionieren, sind aber nicht darauf beschränkt.
Bei manchen Ausführungsformen weist die Thread-Ausführungs-Logik 600 einen Pixel-Shader 602, einen Thread-Verteiler 604, einen Instruktions-Cache 606, eine skalierbare Ausführungseinheitsanordnung, die eine Vielzahl an Ausführungseinheiten 608A bis 608N aufweist, einen Abtaster 610, einen Daten-Cache 612 und einen Datenport 614 auf. Bei einer Ausführungsform sind die Komponenten über eine Interconnect-Struktur, die mit jeder der Komponenten verbunden ist, miteinander verbunden. Bei manchen Ausführungsformen weist die Thread-Ausführungs-Logik 600 eine oder mehrere Verbindungen mit dem Speicher, wie zum Beispiel dem Systemspeicher oder Cache-Speicher, über einen Instruktions-Cache 606, einen Datenport 614, einen Abtaster 610 und/oder eine Ausführungseinheitsanordnung 608A bis 608N auf. Bei manchen Ausführungsformen ist jede Ausführungseinheit (zum Beispiel 608A) ein einzelner Vektorprozessor, der in der Lage ist, mehrere gleichzeitige Threads auszuführen und mehrere Datenelemente parallel für jedes Thread zu verarbeiten. Bei manchen Ausführungsformen weist die Ausführungseinheitsanordnung 608A bis 608N eine beliebige Anzahl an einzelnen Ausführungseinheiten auf.
Bei manchen Ausführungsformen wird die Ausführungseinheitsanordnung 608A bis 608N hauptsächlich zum Ausführen von „Shader-“Programmen verwendet. Bei manchen Ausführungsformen führen die Ausführungseinheiten in der Anordnung 608A bis 608N einen Instruktionssatz aus, der native Unterstützung für viele Standard-3D-Grafik-Shader-Instruktionen derart aufweist, dass Shader-Programme mit einer Mindestübersetzung von Grafikbibliotheken (zum Beispiel Direct-3D und OpenGL) ausgeführt werden. Die Ausführungseinheiten unterstützten Vertex- und Geometrie-Verarbeitung (zum Beispiel Vertex-Programme, Geometrie-Programme, Vertex-Shaders), Pixel-Verarbeitung (zum Beispiel Pixel-Shaders, Fragment-Shaders) und Allzweck-Verarbeitung (zum Beispiel Rechen- und Medien-Shaders).
Jede Ausführungseinheit in der Ausführungseinheitsanordnung 608A bis 608N arbeitet auf Anordnungen von Datenelementen. Die Anzahl an Datenelementen ist die „Ausführungsgröße“ oder die Anzahl an Kanälen für die Instruktion. Ein Ausführungskanal ist eine logische Einheit von Ausführung für Datenelementzugriff, Masking und Flusssteuerung in den Instruktionen. Die Anzahl an Kanälen kann unabhängig von der Anzahl an physischen Rechenwerken (ALUs) oder Gleitkommaeinheiten (FPUs) für einen bestimmten Grafikprozessor sein. Bei manchen Ausführungsformen unterstützen die Ausführungseinheiten 608A bis 608N Ganzzahl- und Gleitkomma-Datentypen.
Der Ausführungseinheitsinstruktionssatz weist SIMD(Single Instruction Multiple Data)-Instruktionen auf. Die verschiedenen Datenelemente können als paketierte Datentypen in einem Register gespeichert werden und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Zum Beispiel, bei Operation auf einem 256-Bit-breitem Vektor, werden die 256 Bit des Vektors in einem Register gespeichert und die Ausführungseinheit arbeitet auf dem Vektor als vier getrennte 64-Bit-packetierte Datenelemente (Quad-Word(OW-)große Datenelemente), acht getrennte 32-Bit-packetierte Datenelemente (Double-Word(DW-)große Datenelemente), sechzehn getrennte 16-Bit-paketierte Datenelemente (Word(W-)große Datenelemente) oder zweiunddreißig getrennte 8-Bit-paketierte Datenelemente (Byte(B-)große Datenelemente). Unterschiedliche Vektorbreiten und Registergrößen sind jedoch möglich.
Ein oder mehrere Anweisungs-Caches (zum Beispiel 606) sind in der Thread-Ausführungs-Logik 600 enthalten, um Thread-Instruktionen für die Ausführungseinheiten zu cachen. Bei manchen Ausführungsformen sind ein oder mehrere Daten-Caches (zum Beispiel 612) enthalten, um Thread-Daten während Thread-Ausführung zu cachen. Bei manchen Ausführungsformen ist ein Abtaster 610 enthalten, um Texturabtastung für 3D-Operationen und Medienabtastung für Medienoperationen bereitzustellen. Bei manchen Ausführungsformen weist der Abtaster 610 spezialisierte Textur- oder Medienabtastungsfunktionalität zum Verarbeiten von Textur- oder Mediendaten während des Abtastvorgangs, bevor die abgetasteten Daten der Ausführungseinheit bereitgestellt werden, auf.
Während der Ausführung senden die Grafik- und Medien-Pipelines Thread-Initiierungsanfragen an die Thread-Ausführungs-Logik 600 mittels Thread-Spawning und Verteilungslogik. Bei manchen Ausführungsformen weist die Thread-Ausführungs-Logik 600 einen lokalen Thread-Verteiler 604 auf, der Thread-Initiierungsanfragen von den Grafik- und Medien-Pipelines schlichtet und die angefragten Threads auf einer oder mehreren Ausführungseinheiten 608A bis 608N instanziiert. Zum Beispiel versendet die Geometrie-Pipeline (zum Beispiel 536 aus 5) Vertex-Verarbeitung, Tesselation oder Geometrie-Verarbeitungs-Threads an die Thread-Ausführungs-Logik 600 (6). Bei manchen Ausführungsformen kann der Thread-Verteiler 604 auch Laufzeit-Thread-Spawning-Anfragen von den ausführenden Shader-Programmen verarbeiten.
Sobald eine Gruppe von Geometrieobjekten verarbeitet und in Pixeldaten gerastert wurde, wird der Pixel-Shader 602 aufgerufen, ferner Ausgabeinformationen zu berechnen und zu veranlassen, dass Ergebnisse in Ausgabeoberflächen (zum Beispiel Farb-Puffer, Tiefen-Puffer, Stencil-Puffer usw.) geschrieben werden. Bei manchen Ausführungsformen berechnet der Pixel-Shader 602 die Werte der verschiedenen Vertex-Attribute, die über das gerasterte Objekt zu interpolieren sind. Bei manchen Ausführungsformen führt der Pixel-Shader 602 dann ein anwendungsprogrammierschnittstellen(API-)bereitgestelltes Pixel-Shader-Programm aus. Zum Ausführen des Pixel-Shader-Programms versendet der Pixel-Shader 602 Threads über den Thread-Verteiler 604 an eine Ausführungseinheit (zum Beispiel 608A). Bei manchen Ausführungsformen verwendet der Pixel-Shader 602 Texturabtast-Logik in dem Abtaster 610, um auf Texturdaten in Textur-Karten, die in dem Speicher gespeichert sind, zuzugreifen. Arithmetische Operationen auf den Texturdaten und den Eingabegeometrie-Daten berechnen Pixelfarbdaten für jedes geometrische Fragment oder löschen ein oder mehrere Pixel von weiterer Verarbeitung.
Bei manchen Ausführungsformen stellt der Datenport 614 einen Speicherzugriffsmechanismus für die von der Thread-Ausführungs-Logik 600 verarbeiteten Daten auf dem Speicher zum Verarbeiten auf einer Grafikprozessor-Ausgabe-Pipeline bereit. Bei manchen Ausführungsformen weist der Datenport 614 einen oder mehrere Cache-Speicher (zum Beispiel Daten-Cache 612) zum Cachen von Daten für Speicherzugriff über den Datenport auf oder wird damit gekoppelt.
7 ist ein Blockdiagramm, das ein Grafikprozessor-Instruktionsformat 700 gemäß einiger Ausführungsformen veranschaulicht. Bei einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Instruktionssatz, der Instruktionen in mehreren Formaten aufweist. Die Kästchen aus durchgezogenen Linien veranschaulichen die Komponenten, die im Allgemeinen in einer Ausführungseinheitsinstruktion enthalten sind, während die gestrichelten Linien Komponenten aufweisen, die optional sind oder nur in einem Teilsatz der Instruktionen enthalten sind. Bei manchen Ausführungsformen ist das Instruktionsformat 700, das beschrieben und veranschaulicht ist, Makroinstruktionen, in dem Sinne, dass sie Instruktionen sind, die der Ausführungseinheit bereitgestellt werden, im Gegensatz zu Mikrooperationen, die aus Instruktionsdecodierung entstehen, sobald die Instruktion verarbeitet ist.
Bei manchen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten nativ Instruktionen in einem 128-Bit-Format 710. Ein 64-Bitkomprimiertes Instruktionsformat 730 steht für manche Instruktionen basierend auf der ausgewählten Instruktion, den Instruktionsoptionen und der Anzahl an Operanden zur Verfügung. Das native 128-Bit-Format 710 stellt Zugriff auf alle Instruktionsoptionen bereit, auch wenn manche Optionen und Operationen in dem 64-Bit-Format 730 beschränkt sind. Die nativen Instruktionen, die in dem 64-Bit-Format 730 zur Verfügung stehen, variieren nach Ausführungsform. Bei manchen Ausführungsformen wird die Instruktion teilweise unter Verwendung eines Satzes an Indexwerten in einem Index-Feld 713 komprimiert. Die Ausführungseinheits-Hardware bezieht sich auf einen Satz von Komprimiertabellen basierend auf den Indexwerten und verwendet die Komprimiertabellenausgaben, um eine native Instruktion in dem 128-Bit-Format 710 wiederherzustellen.
Der Instruktions-Opcode 712 definiert die Operation, die die Ausführungseinheit durchführen soll, für jedes Format. Die Ausführungseinheiten führen jede Instruktion parallel über die mehreren Datenelemente jedes Operanden aus. Zum Beispiel führt die Ausführungseinheit in Reaktion auf eine Hinzufügungs-Instruktion eine gleichzeitige Hinzufügungs-Operation über jeden Farbkanal, der ein Texturelement oder Bildelement darstellt, durch. Standardmäßig führt die Ausführungseinheit jede Instruktion über alle Datenkanäle der Operanden durch. Bei manchen Ausführungsformen ermöglicht das Instruktions-Steuerfeld 714 Steuerung über bestimmte Ausführungsoptionen, wie zum Beispiel Kanalauswahl (zum Beispiel „Predication“) und Datenkanalfolge (zum Beispiel „Swizzle“). Ein Exec-Größen-Feld 716 beschränkt die Anzahl an Datenkanälen, die parallel ausgeführt werden, für die 128-Bit-Instruktionen 710. Bei manchen Ausführungsformen ist das Exec-Größen-Feld 716 nicht für Verwendung in dem 64-Bit-kompromierten Instruktionsformat 730 verfügbar.
Manche Ausführungseinheitsinstruktionen weisen bis zu drei Operanden auf, die zwei Quellen-Operanden src0 722, src1 722 und eine Destination 718 aufweisen. Bei manchen Ausführungsformen unterstützen die Ausführungseinheiten Dual-Destination-Instruktionen, in denen eine der Destinationen impliziert ist. Datenmanipulationsinstruktionen können einen dritten Quellen-Operanden (zum Beispiel SRC2 724) aufweisen, wobei der Instruktions-Opcode 712 die Anzahl an Quellen-Operanden bestimmt. Ein letzter Quellen-Operand der Instruktion kann ein unmittelbarer (zum Beispiel hartcodierter) Wert sein, der mit der Instruktion angegeben wird.
Bei manchen Ausführungsformen weist das 128-Bit-Instruktionsformat 710 eine Zugriffs-/Adressmodusinformation 726 auf, die zum Beispiel spezifiziert, ob ein direkter Registeradressmodus oder ein indirekter Registeradressmodus verwendet wird. Wenn der direkte Registeradressmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt von Bits in der Instruktion 710 bereitgestellt.
Bei manchen Ausführungsformen weist das 128-Bit-Instruktionsformat 710 ein Zugriffs-/Adressmodusfeld 726 auf, das einen Adressmodus und/oder einen Zugriffsmodus für die Instruktion spezifiziert. Bei einer Ausführungsform dient der Zugriffsmodus zum Definieren einer Datenzugriffsausrichtung für die Instruktion. Manche Ausführungsformen unterstützen Zugriffsmodi, die einen 16-Byte-ausgerichteten Zugriffsmodus und einen 1-Byte-ausgerichteten Zugriffsmodus aufweisen, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Instruktions-Operanden bestimmt. Zum Beispiel kann die Instruktion 710, wenn in einem ersten Modus, Byteausgerichtetes Adressieren für Quellen- und Destinations-Operanden verwenden und, wenn in einem zweiten Modus, kann die Instruktion 710 16-Byteausgerichtetes Adressieren für alle Quellen- und Destinations-Operanden verwenden.
Bei einer Ausführungsform bestimmt der Adressmodusabschnitt des Zugriffs-/Adressmodusfelds 726, ob die Instruktion direktes oder indirektes Adressieren verwenden soll. Wenn der direkte Registeradressmodus verwendet wird, stellen Bits in der Instruktion 710 direkt die Registeradresse eines oder mehrerer Operanden bereit. Wenn der indirekte Registeradressmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem unmittelbaren Adressfeld in der Instruktion berechnet werden.
Bei manchen Ausführungsformen werden Instruktionen basierend auf Bit-Feldern von Opcode 712 gruppiert, um die Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit-Opcode gestatten es Bits 4, 5 und 6 der Ausführungseinheit, den Typ des Opcodes zu bestimmen. Die exakte Opcode-Gruppierung, die gezeigt ist, ist nur ein Beispiel. Bei manchen Ausführungsformen weist eine Bewegungs- und Logik-Opcode-Gruppe 742 Datenbewegungs- und Logikinstruktionen (zum Beispiel Bewegen (mov), Vergleichen (cmp)) auf. Bei manchen Ausführungsformen teilt sich die Bewegungs- und Logikgruppe 742 die fünf signifikantesten Bits (MSB), wobei Bewegungs(mov)-Instruktionen die Form 0000xxxxb und Logikinstruktionen die Form 0001xxxxb aufweisen. Eine Flusssteuerinstruktionsgruppe 744 (zum Beispiel, Aufrufen, Springen (jmp)) weist Instruktionen in der Form von 0010xxxxb (zum Beispiel 0x20) auf. Eine Sonstiges-Instruktionsgruppe 746 weist eine Mischung von Instruktionen auf, darunter Synchronisationsinstruktionen (zum Beispiel Warten, Senden) in der Form von 0011xxxxb (zum Beispiel 0x30). Eine parallele Mathematik-Instruktionsgruppe 748 weist komponentenmäßige Recheninstruktionen (zum Beispiel Addieren, Multiplizieren (mul)) in der Form von 0100xxxxb (zum Beispiel 0x40) auf. Die parallele Mathematik-Gruppe 748 führt die Rechenoperationen parallel über Datenkanäle durch. Die Vektor-Mathematik-Gruppe 750 weist Recheninstruktionen (zum Beispiel dp4) in der Form von 0101xxxxb (zum Beispiel 0x50) auf. Die Vektor-Mathematik-Gruppe führt Rechnen, wie zum Beispiel Skalarproduktberechnungen, auf Vektor-Operanden durch.
Grafik-Pipeline
8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors 800. Elemente aus 8, die dieselben Bezugszeichen (oder Namen) als die Elemente in irgendeiner anderen Figur hierin aufweisen, können in einer beliebigen Weise ähnlich der, die anderswo hierin beschrieben ist, arbeiten oder funktionieren, sind aber nicht darauf beschränkt.
Bei manchen Ausführungsformen weist der Grafikprozessor 800 eine Grafik-Pipeline 820, eine Medien-Pipeline 830, eine Display-Engine 840, eine Thread-Ausführungs-Logik 850 und eine Render-Ausgabe-Pipeline 870 auf. Bei manchen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor in einem Multikern-Verarbeitungssystem, das einen oder mehrere Allzweck-Verarbeitungskerne aufweist. Der Grafikprozessor wird von Registerschreibvorgängen in ein oder mehrere Steuerregister (nicht gezeigt) oder mittels Befehlen, die an den Grafikprozessor 800 über ein Ring-Interconnect 802 ausgegeben werden, gesteuert. Bei manchen Ausführungsformen koppelt das Ring-Interconnect 802 den Grafikprozessor 800 mit weiteren Verarbeitungskomponenten, wie zum Beispiel weiteren Grafikprozessoren oder Allzweck-Prozessoren. Befehle von dem Ring-Interconnect 802 werden von einem Befehls-Bandlaufwerk 803 interpretiert, der Instruktionen an individuelle Komponenten der Grafik-Pipeline 820 oder Medien-Pipeline 830 liefert.
Bei manchen Ausführungsformen leitet das Befehls-Bandlaufwerk 803 die Operation eines Vertex-Fetchers 805, der Vertex-Daten von dem Speicher ausliest und Vertex-Verarbeitungsbefehle, die von dem Befehls-Bandlaufwerk 803 bereitgestellt werden, ausführt. Bei manchen Ausführungsformen stellt der Vertex-Fetcher 805 Vertex-Daten an einen Vertex-Shader 807 bereit, der koordinierte Raumtransformations- und Beleuchtungsoperationen auf jedem Vertex durchführt. Bei manchen Ausführungsformen führen der Vertex-Fetcher 805 und der Vertex-Shader 807 Vertex-Verarbeitungsinstruktionen mittels Verteilung von Ausführungs-Threads an Ausführungseinheiten 852A, 85B über einen Thread-Verteiler 831 aus.
Bei manchen Ausführungsformen sind die Ausführungseinheiten 852A, 852B eine Anordnung von Vektorprozessoren, die einen Instruktionssatz zum Durchführen von Grafik- und Medien-Operationen aufweisen. Bei manchen Ausführungsformen weisen die Ausführungseinheiten 852A, 852B einen L1-Cache 851 auf, der für jede Anordnung spezifisch ist oder zwischen Anordnungen geteilt wird. Der Cache kann als ein Daten-Cache, ein Instruktions-Cache oder ein einzelner Cache, der dazu partitioniert ist, Daten und Instruktionen in unterschiedlichen Partitionen aufzuweisen, ausgelegt sein.
Bei manchen Ausführungsformen weist die Grafik-Pipeline 820 Tesselationskomponenten zum Durchführen von Hardware-beschleunigter Tesselation von 3D-Objekten auf. Bei manchen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tesselationsoperationen. Ein programmierbarer Domain-Shader 817 stellt Backend-Evaluierung von Tesselationsausgabe bereit. Ein Tesselator 813 arbeitet unter Anweisung des Hull-Shaders 811 und weist spezielle Zweck-Logik zum Erstellen eines Satzes von detaillierten geometrischen Objekten basierend auf einem groben geometrischen Modell, das als Eingabe in eine Grafik-Pipeline 820 bereitgestellt wird, auf. Bei manchen Ausführungsformen können, falls Tesselation nicht verwendet wird, die Tesselationskomponenten 811, 813, 817 umgangen werden.
Bei manchen Ausführungsformen können vollständige geometrische Objekte von einem Geometrie-Shader 819 über einen oder mehrere Threads, die an die Ausführungseinheiten 852A, 852B gesendet werden, verarbeitet werden oder direkt zu dem Begrenzer 829 fortschreiten. Bei manchen Ausführungsformen arbeitet der Geometrie-Shader auf komplett geometrischen Objekten statt Eckpunkten oder Patches von Eckpunkten wie bei vorhergehenden Phasen der Grafik-Pipeline. Falls die Tesselation deaktiviert ist, empfängt der Geometrie-Shader 819 Eingabe von dem Vertex-Shader 807. Bei manchen Ausführungsformen ist der Geometrie-Shader 819 von einem Geometrie-Shader-Programm programmierbar, um Geometrie-Tesselation durchzuführen, falls die Tesselationseinheiten deaktiviert sind.
Vor Rasterung verarbeitet ein Begrenzer 829 Vertex-Daten. Der Begrenzer 829 kann ein Begrenzer festgelegter Funktion oder ein programmierbarer Begrenzer mit Begrenzungs- und Geometrie-Shader-Funktionen sein. Bei manchen Ausführungsformen verteilt eine Raster- und Tiefentestkomponente 873 in der Render-Ausgabe-Pipeline 870 Pixel-Shaders, um die geometrischen Objekte in deren Darstellung pro Pixel umzuwandeln. Bei manchen Ausführungsformen ist die Pixel-Shader-Logik in der Thread-Ausführungs-Logik 850 enthalten. Bei manchen Ausführungsformen kann eine Anwendung den Rasterizer 873 umgehen und über eine Stream-Out-Einheit 823 auf nicht-rasterisierte Vertex-Daten zugreifen.
Der Grafikprozessor 800 weist einen Interconnect-Bus, eine Interconnect-Struktur oder einen beliebigen weiteren Interconnect-Mechanismus auf, der gestattet, dass sich Daten und Nachrichten unter den Hauptkomponenten des Prozessors bewegen. Bei manchen Ausführungsformen sind die Ausführungseinheiten 852A, 852B und zugeordnete Cache(s) 851, der Textur- und Medien-Abtaster 854 und der Textur-/Abtaster-Cache 585 über einen Datenport 856 miteinander verbunden, um Speicherzugriff und Kommunikation mit Render-Ausgabe-Pipelinekomponenten des Prozessors durchzuführen. Bei manchen Ausführungsformen weisen der Abtaster 854, die Caches 851, 858 und die Ausführungseinheiten 852A, 852B jeweils getrennte Speicherzugriffspfade auf.
Bei manchen Ausführungsformen weist die Render-Ausgabe-Pipeline 870 eine Raster- und Tiefentestkomponente 873 auf, die vertexbasierte Objekte in eine zugeordnete pixelbasierte Darstellung umwandelt. Bei manchen Ausführungsformen weist die Raster-Logik eine Fensterungs-/Maskierungs-Einheit zum Durchführen eines Dreiecks festgelegter Funktion und Linien-Rasterung auf. Ein zugeordneter Render-Cache 878 und Tiefen-Cache 879 sind ebenfalls in manchen Ausführungsformen verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen auf den Daten durch, auch wenn in manchen Fällen Pixeloperationen, die mit 2D-Operationen (zum Beispiel Bit-Block-Bildtransfer mit Blending) assoziiert sind, von der 2D-Engine 841 durchgeführt werden oder zur Anzeigezeit von der Anzeigesteuerung 843 unter Verwendung von Overlay-Anzeigeebenen ersetzt werden. Bei manchen Ausführungsformen ist ein gemeinsamer L3-Cache 875 für alle Grafikkomponenten verfügbar, was das Teilen von Daten ohne die Verwendung eines Hauptsystemspeichers gestattet.
Bei manchen Ausführungsformen weist die Grafikprozessor-Medien-Pipeline 830 eine Medien-Engine 837 und ein Video-Frontend 834 auf. Bei manchen Ausführungsformen empfängt das Video-Frontend 834 Pipeline-Befehle von dem Befehls-Bandlaufwerk 803. Bei manchen Ausführungsformen weist die Medien-Pipeline 830 ein getrenntes Befehls-Bandlaufwerk auf. Bei manchen Ausführungsformen verarbeitet das Video-Frontend 834 Medienbefehle, bevor die Befehle an die Medien-Engine 837 gesendet werden. Bei manchen Ausführungsformen weist die Medien-Engine 337 Thread-Spawning-Funktionalität zum Spawnen von Threads zum Versenden an die Thread-Ausführungs-Logik 850 über den Thread-Verteiler 831 auf.
Bei manchen Ausführungsformen weist der Grafikprozessor 800 eine Display-Engine 840 auf. Bei manchen Ausführungsformen ist die Display-Engine 840 extern eines Prozessors 800 und ist mit dem Grafikprozessor über das Ring-Interconnect 802 oder eine/n beliebige/n weitere/n Interconnect-Bus oder - Struktur gekoppelt. Bei manchen Ausführungsformen weist die Display-Engine 840 eine 2D-Engine 841 und eine Anzeigesteuerung 843 auf. Bei manchen Ausführungsformen weist die Display-Engine 840 spezielle Zweck-Logik auf, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. Bei manchen Ausführungsformen wird die Anzeigesteuerung 843 mit einer Anzeigevorrichtung (nicht gezeigt) gekoppelt, bei der es sich um eine systemintegrierte Anzeigevorrichtung, wie in einem Laptop-Computer, oder eine externe Anzeigevorrichtung, die über einen Anzeigevorrichtungsverbinder angebracht ist, handeln kann.
Bei manchen Ausführungsformen sind die Grafik-Pipeline 820 und die Medien-Pipeline 830 dazu ausgelegt, Operationen basierend auf mehreren grafik- und medienprogrammierenden Schnittstellen durchzuführen, und sind nicht spezifisch für eine beliebige Anwendungsprogrammierschnittstelle (API). Bei manchen Ausführungsformen übersetzt die Treibersoftware für den Grafikprozessor API-Aufrufe, die spezifisch für eine bestimmte Grafik -oder Medienbibliothek sind, in Befehle, die von dem Grafikprozessor verarbeitet werden können. Bei manchen Ausführungsformen wird Unterstützung für die Open Graphics Library (OpenGL) und Open Computing Language (OpenCL) von der Khronos Group, die Direct3D Library von der Microsoft Corporation, bereitgestellt oder Unterstützung kann für sowohl OpenGL als auch D3D bereitgestellt werden. Unterstützung kann auch für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine zukünftige API mit kompatibler 3D-Pipeline würde auch unterstützt werden, falls Mapping von der Pipeline der zukünftigen API zu der Pipeline des Grafikprozessors möglich ist.
Grafik-Pipeline-Programmierung
9A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat 900 gemäß einiger Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlssequenz 910 gemäß einer Ausführungsform veranschaulicht. Die Kästchen aus durchgezogenen Linien 9A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten aufweisen, die optional sind oder nur in einem Teilsatz der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 aus 9A weist Datenfelder zum Identifizieren eines Ziel-Clients 902 des Befehls, einen Befehlsoperationscode (Opcode) 904 und die relevanten Daten 906 für den Befehl auf. Ein Teil-Opcode 905 und eine Befehlsgröße 908 sind auch in manchen Befehlen enthalten.
Bei manchen Ausführungsformen spezifiziert der Client 902 die Client-Einheit der Grafikvorrichtung, die die Befehlsdaten verarbeitet. Bei manchen Ausführungsformen prüft ein Grafikprozessor-Befehls-Parser das Client-Feld jedes Befehls, um das weitere Verarbeiten des Befehls zu konditionieren und die Befehlsdaten zu der geeigneten Client-Einheit zu routen. Bei manchen Ausführungsformen weisen die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit auf. Jede Client-Einheit weist eine entsprechende Verarbeitungs-Pipeline auf, die die Befehle verarbeitet. Nachdem der Befehl von der Client-Einheit empfangen wird, liest die Client-Einheit den Opcode 904 aus und, falls vorhanden, den Teilcode 905, um die Operation, die durchgeführt werden soll, zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Information in dem Datenfeld 906 durch. Für manche Befehle wird eine explizite Befehlsgröße 908 erwartet, die Größe des Befehls zu spezifizieren. Bei manchen Ausführungsformen bestimmt der Befehls-Parser automatisch die Größe mindestens einiger der Befehle basierend auf dem Befehls-Opcode. Bei manchen Ausführungsformen werden Befehle über mehrere eines Double-Word ausgerichtet.
Das Flussdiagramm in 9B zeigt eine beispielhafte Grafikprozessor-Befehlssequenz 910. Bei manchen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystem, das eine Ausführungsform eines Grafikprozessor aufweist, eine Version der Befehlssequenz, die gezeigt ist, um einen Satz von Grafikoperationen vorzubereiten, auszuführen und zu beenden. Eine Beispielsbefehlssequenz ist rein zu Beispielzwecken gezeigt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Befehle oder diese Befehlssequenz beschränkt sind. Darüber hinaus können die Befehle als Batches von Befehlen in einer gemeinsamen Sequenz ausgegeben werden, so dass der Grafikprozessor die Sequenz von Befehlen in zumindest teilweisem Auftreten verarbeiten wird.
Bei manchen Ausführungsformen kann die Grafikprozessor-Befehlssequenz 910 mit einem Pipeline-Flush-Befehl 912 beginnen, um eine beliebige aktive Grafik-Pipeline zu veranlassen, die aktuell ausstehenden Befehle für die Pipeline zu vervollständigen. Bei manchen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Der Pipeline-Flush wird durchgeführt, um die aktive Grafik-Pipeline zu veranlassen, jegliche ausstehenden Befehle zu vervollständigen. In Reaktion auf einen Pipeline-Flush pausiert der Befehls-Parser für den Grafikprozessor die Befehlsverarbeitung bis die aktiven Drawing-Engines die ausstehenden Operationen vervollständigen und die relevanten Auslese-Caches ungültig gemacht werden. Optional können beliebige Daten in dem Render-Cache, die als „dirty“ markiert sind, in den Speicher geflusht werden. Bei manchen Ausführungsformen kann der Pipeline-Flush-Befehl 912 für Pipeline-Synchronisierung oder vor dem Eintreten des Grafikprozessors in einen Leistungssparmodus verwendet werden.
Bei manchen Ausführungsformen wird ein Pipeline-Auswahl-Befehl 913 verwendet, wenn eine Befehlssequenz bedingt, dass der Grafikprozessor explizit zwischen Pipelines wechselt. Bei manchen Ausführungsformen wird ein Pipeline-Auswahl-Befehl 913 nur einmal in einem Ausführungs-Context benötigt bevor Pipeline-Befehle ausgegeben werden, außer der Context soll Befehle für beide Pipelines ausgeben. Bei manchen Ausführungsformen wird ein Pipeline-Flush-Befehl ist 912 unmittelbar vor einem Pipeline-Wechsel über den Pipeline-Auswahl-Befehl 913 benötigt.
Bei manchen Ausführungsformen konfiguriert ein Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für Operation und wird zum Programmieren der 3D-Pipeline 922 und der Medien-Pipeline 924 verwendet. Bei manchen Ausführungsformen konfiguriert der Pipeline-Steuerbefehl 914 den Pipeline-Zustand für die aktive Pipeline. Bei einer Ausführungsform wird der Pipeline-Steuerbefehl 914 für Pipeline-Synchronisierung und zum Löschen von Daten aus einem oder mehreren Cache-Speichern in der aktiven Pipeline vor dem Verarbeiten eines Batches von Befehlen verwendet.
Bei manchen Ausführungsformen werden Return-Puffer-Zustands-Befehle 916 zum Konfigurieren eines Satzes von Return-Puffern für die jeweiligen Pipelines zum Schreiben von Daten verwendet. Manche Pipeline-Operationen benötigen die Zuordnung, Auswahl oder Konfiguration eines oder mehrerer Return-Puffer, in die die Operationen Zwischendaten während des Verarbeitens schreiben. Bei manchen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Return-Puffer zum Speichern von Ausgabedaten und zum Durchführen über Thread-Kommunikation. Bei manchen Ausführungsformen weist der Return-Puffer-Zustand 916 Auswählen der Größe und Anzahl von Return-Puffern zum Verwenden für einen Satz von Pipeline-Operationen auf.
Die verbleibenden Befehle in der Befehlssequenz unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipeline-Bestimmung 920 wird die Befehlssequenz auf die 3D-Pipeline 922, beginnend mit dem 3D-Pipeline-Zustand 930, oder die Medien-Pipeline 924, beginnend mit dem Medien-Pipeline-Zustand 940, zugeschnitten.
Die Befehle für den 3D-Pipeline-Zustand 930 weisen 3D-Zustandseinstellungsbefehle für den Vertex-Puffer-Zustand, den Vertex-Element-Zustand, konstanten Farbzustand, Tiefenpufferzustand und weitere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitivbefehle verarbeitet werden, auf. Die Werte dieser Befehle werden zumindest teilweise basierend auf der bestimmten 3D-API in Verwendung bestimmt. Bei manchen Ausführungsformen sind die 3D-Pipeline-Zustands(930)-Befehle auch in der Lage, bestimmte Pipeline-Elemente selektiv zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
Bei manchen Ausführungsformen wird der 3D-Primitiv(932)-Befehl verwendet, um 3D-Primitive zu senden, um von der 3D-Pipeline verarbeitet zu werden. Befehle und zugehörige Parameter, die über den 3D-Primitiv(932)-Befehl an den Grafikprozessor geleitet werden, werden in der Grafik-Pipeline an die Vertex-Fetch-Funktion weitergeleitet. Die Vertex-Fetch-Funktion verwendet die 3D-Primitiv(932)-Befehlsdaten zum Erstellen von Vertex-Datenstrukturen. Die Vertex-Datenstrukturen werden in einem oder mehreren Return-Puffern gespeichert. Bei manchen Ausführungsformen wird der 3D-Primit(932)-Befehl verwendet, um Vertex-Operationen auf 3D-Primitiven mittels Vertex-Shaders durchzuführen. Zum Verarbeiten der Vertex-Shaders versendet die 3D-Pipeline 922 Shader-Ausführungs-Threads an die Grafikprozessor-Ausführungseinheiten.
Bei manchen Ausführungsformen wird die 3D-Pipeline 922 mittels eines Ausführungs(934)-Befehls oder -Ereignisses ausgelöst. Bei manchen Ausführungsformen löst ein Register-Schreibvorgang Befehlsausführung aus. Bei manchen Ausführungsformen wird Ausführung mittels eines „Go“- oder „Kick“-Befehls in der Befehlssequenz ausgelöst. Bei einer Ausführungsform wird Befehlsausführung unter Verwendung eines Pipeline-Synchronisierungsbefehls zum Flushen der Befehlssequenz durch die Grafik-Pipeline ausgelöst. Die 3D-Pipeline führt Geometrie-Verarbeitung für die 3D-Primitive durch. Bei Beendigung der Operationen werden die entstandenen geometrischen Objekte gerastert und die Pixel-Engine färbt die entstandenen Pixel. Zusätzliche Befehle zum Steuern von Pixel-Shading und Pixel-Backend-Operationen können ebenfalls für diese Operationen enthalten sind.
Bei manchen Ausführungsformen folgt die Grafikprozessor-Befehlssequenz 910 des Medien-Pipeline(924)-Pfads bei Durchführung den Medien-Operationen. Im Allgemeinen ist die spezifische Verwendung und Weise des Programmierens der Medien-Pipeline 924 von den Medien- oder Rechenoperationen, die durchzuführen sind, abhängig. Spezifische Medien-Decodieroperationen können während des Medien-Decodierens an die Medien-Pipeline abgeladen werden. Bei manchen Ausführungsformen kann die Medien-Pipeline auch umgangen werden und Medien-Decodierung kann als Ganzes oder teilweise unter Verwendung von Ressourcen, die von einem oder mehreren Allzweck-Verarbeitungskernen bereitgestellt werden, durchgeführt werden. Bei einer Ausführungsform weist die Medien-Pipeline auch Elemente für Allzweck-Grafikprozessor(GPGPU)-Operationen auf, bei denen der Grafikprozessor zum Durchführen von SMID-Vektor-Operationen unter Verwendung von Rechen-Shader-Programmen, die nicht explizit auf das Rendern von Grafikprimitiven bezogen sind, verwendet wird.
Bei manchen Ausführungsformen ist die Medien-Pipeline 924 auf eine ähnliche Weise als die 3D-Pipeline 922 ausgelegt. Ein Satz von Medien-Pipeline-Zustands-Befehlen 940 wird versandt oder in eine Befehls-Queue vor den Medien-Objekt-Befehlen 942 eingeführt. Bei manchen Ausführungsformen weisen die Pipeline-Zustands-Befehle 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medien-Objekte verwendet werden, auf. Dazu zählen Daten zum Konfigurieren der Video-Decodier- und Video-Codier-Logik in der Medien-Pipeline, wie zum Beispiel ein Codier- oder Decodier-Format. Bei manchen Ausführungsformen unterstützen die Zustands-Befehle 940 auch die Verwendung eines oder mehrerer Zeiger auf „indirekte“ Zustandselemente, die einen Batch von Zustandseinstellungen enthalten.
Bei manchen Ausführungsformen liefern Medien-Objekt-Befehle 942 Zeiger an die Medien-Objekte zum Verarbeiten durch die Medien-Pipeline. Zu den Medien-Objekten zählen Speicherpuffer, die Videodaten, die zu verarbeiten sind, enthalten. Bei manchen Ausführungsformen müssen alle Medien-Pipeline-Zustände gültig sein, bevor ein Medien-Objekt-Befehl 942 ausgegeben wird. Nachdem der Pipeline-Zustand konfiguriert ist und die Medien-Objekt-Befehle 942 gereiht sind, wird die Medien-Pipeline 924 mittels eines Ausführungsbefehls 944 oder einem äquivalenten Ausführungsereignis (zum Beispiel Registerschreibvorgang) ausgelöst. Die Ausgabe der Medien-Pipeline 924 kann dann von Operationen, die von der 3D-Pipeline 922 oder der Medien-Pipeline 924 bereitgestellt werden, Nachverarbeitet werden. Bei manchen Ausführungsformen werden GPGPU-Operationen auf ähnliche Weise wie Medien-Operationen konfiguriert und ausgeführt.
Grafiksoftwarearchitektur
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß mancher Ausführungsformen. Bei manchen Ausführungsformen weist Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030 auf. Bei manchen Ausführungsformen weist der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Allzweck-Prozessorkerne 1034 auf. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils in dem Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
Bei manchen Ausführungsformen weist die 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programme auf, die Shader-Instruktionen 1012 aufweisen. Die Shader-Sprachinstruktionen können in einer höheren Shader-Sprache sein, wie zum Beispiel die High Level Shader Language (HLSL) oder die OpenGL Shader Language (GLSL). Die Anwendung weist auch ausführbare Instruktionen 1014 in einer Maschinensprache auf, die zur Ausführung von dem Allzweck-Prozessorkern 1034 geeignet ist. Die Anwendung weist auch Grafikobjekte 1016 auf, die durch die Vertex-Daten definiert sind.
Bei manchen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows® Betriebssystem von der Microsoft Corporation, ein geschütztes UNIX-ähnliches Betriebssystem oder ein UNIX-ähnliches Open-Source-Betriebssystem, das eine Variation des Linux-Systemkerns verwendet. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 1020 einen Frontend-Shader-Compiler 1024 zum Kompilieren beliebiger Shader-Instruktionen 1012 in HLSL in einer niedrigeren Shader-Sprache. Bei der Kompilierung kann es sich um Just-in-time(JIT-)Kompilierung handeln oder die Anwendung kann Shader-Vor-Kompilierung durchführen. Bei manchen Ausführungsformen werden höhere Shaders während der Kompilierung der 3D-Grafikanwendung 1010 in niedrigere Shaders kompiliert.
Bei manchen Ausführungsformen weist der Benutzermodus-Grafiktreiber 1026 einen Backend-Shader-Compiler 1027 zum Umwandeln der Shader-Instruktionen 1012 in eine Hardware-spezifische Darstellung auf. Wenn die OpenGL-API verwendet wird, werden Shader-Instruktionen 1012 in der höheren GLSL-Sprache zu einem Benutzermodus-Grafiktreiber 1026 für Kompilierung geleitet. Bei manchen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystem-Systemkernmodusfunktionen 1028 zum Kommunizieren mit einem Systemkernmodus-Grafiktreiber 1029. Bei manchen Ausführungsformen kommuniziert der Systemkernmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032 zum Versenden von Befehlen und Instruktionen.
IP-Kernimplementierungen
Ein oder mehrere Aspekte mindestens einer Ausführungsform können mittels repräsentativen Codes, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik in einer integrierten Schaltung, wie zum Beispiel einen Prozessor, darstellt und/oder definiert, implementiert werden. Zum Beispiel kann das maschinenlesbare Medium Instruktionen aufweisen, die verschiedene Logik in dem Prozessor darstellt. Wenn sie von einer Maschine gelesen werden, können die Instruktionen die Maschine veranlassen, die Logik herzustellen, um die Techniken, die hierin beschrieben werden, durchzuführen. Solche Darstellungen, bekannt als „IP-Kerne“, sind wiederverwendbare Einheiten von Logik für eine integrierte Schaltung, die als ein Hardware-Modell, das die Struktur der integrierten Schaltung beschreibt, auf einem greifbaren, maschinenlesbaren Medium gespeichert sein können. Das Hardware-Modell kann verschiedenen Kunden oder Produktionsanlagen bereitgestellt werden, die das Hardware-Modell auf Herstellungsmaschinen, die die integrierte Schaltung herstellen, laden. Die integrierte Schaltung kann derart hergestellt werden, dass die Schaltung Operationen, die in Zusammenhang mit einer beliebigen der Ausführungsformen, die hier beschriebenen sind, beschriebenen sind, durchführt.
11 ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem 1100 veranschaulicht, das zur Herstellung einer integrierten Schaltung zum Durchführen von Operationen verwendet werden kann, gemäß einer Ausführungsform. Das IP-Kernentwicklungssystem 1100 kann zum Erstellen modularer, wiederverwendbarer Designs, die in ein größeres Design eingebaut werden können oder zum Bauen einer komplett integrierten Schaltung (zum Beispiel einer SOC integrierten Schaltung) verwendet werden können, verwendet werden. Eine Designanlage 1130 kann eine Software-Simulation 1110 eines IP-Kern-Designs in einer höheren Programmiersprache (zum Beispiel C/C++) erstellen. Die Software-Simulation 1110 kann zum Designen, Testen und Verifizieren des Verhaltens des IP-Kerns verwendet werden. Ein Register-Transfer-Level (RTL-) Design kann dann von dem Simulationsmodell 1100 erstellt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, das den Fluss von digitalen Signalen zwischen Hardware-Registern modelliert, aufweisend die zugehörige Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch niedrigere Designs auf dem Logik-Level oder Transistor-Level erstellt, designt oder synthetisiert werden. Somit können die bestimmten Details des anfänglichen Designs und der anfänglichen Simulation variieren.
Das RTL-Design 1115 oder das Äquivalent können ferner von der Designanlage in ein Hardware-Modell 1120 synthetisiert werden, das in einer Hardwarebeschreibungssprache (HDL) oder einer beliebigen weiteren Repräsentation physikalischer Design-Daten vorhanden sein kann. Die HDL kann ferner simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann für Lieferung an eine Drittpartei-Herstellungsanlage 1165 unter Verwendung eines nichtflüchtigen Speichers 1140 (zum Beispiel einer Festplatte, eines Flash-Speichers oder eines beliebigen nichtflüchtigen Speichermediums) gespeichert werden. Alternativ kann das IP-Kern-Design über eine Kabelverbindung 1150 oder eine drahtlose Verbindung 1160 übertragen werden (zum Beispiel über das Internet). Die Herstellungsanlage 1165 kann dann eine integrierte Schaltung herstellen, die zumindest teilweise auf dem IP-Kern-Design basiert. Die hergestellte integrierte Schaltung kann dazu ausgelegt sein, Operationen gemäß mindestens einer Ausführungsform, die hierin beschrieben ist, durchzuführen.
12 ist ein Blockdiagramm, das ein beispielhaftes System auf einer integrierten Chip-Schaltung 1200 veranschaulicht, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt sein kann, gemäß einer Ausführungsform. Die beispielhafte integrierte Schaltung weist einen oder mehrere Anwendungsprozessoren 1205 (zum Beispiel CPUs), mindestens einen Grafikprozessor 1210 auf und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 aufweisen, von denen ein beliebiger ein modularer IP-Kern von derselben oder mehreren unterschiedlichen Designanlagen sein kann. Die integrierte Schaltung weist periphere oder Bus-Logik, darunter eine USB-Steuerung 1225, eine UART-Steuerung 1230, eine SPI/SDIO-Steuerung 1235 und eine I2S/I2C-Steuerung 1240, auf. Zusätzlich kann die integrierte Schaltung eine Anzeigevorrichtung 1245 aufweisen, die mit einer oder mehreren einer High-Definition-Multimedia-Interface(HDMI-)Steuerung 1250 und einer Mobile-Industry-Processor-Interface(MIPI-)Anzeigeschnittstelle 1255 gekoppelt ist. Speicherplatz kann von einem Flash-Speicher-Untersystem 1260 bereitgestellt werden, das einen Flash-Speicher und eine Flash-Speicher-Steuerung aufweist. Eine Speicherschnittstelle kann mittels einer Speichersteuerung 1265 für Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt werden. Manche integrierten Schaltungen weisen zusätzlich eine eingebettete Security-Engine 1270 auf.
Zusätzlich können weitere Logik und Schaltungen in dem Prozessor einer integrierten Schaltung 1200 enthalten sein, darunter zusätzliche Grafikprozessoren/-Kerne, periphere Schnittstellensteuerungen oder Allzweck-Prozessorkerne.
VERFAHREN UND GERÄT FÜR HYBRIDES STEREO-RENDERING
Wie erwähnt werden Lichtfeldanzeigen typischerweise unter Verwendung von Content, der auf die Schärfentiefe (die heutzutage eher oberflächlich sein kann) beschränkt ist, betrieben, wobei Content außerhalb des Bereichs vorsichtig defokussiert und/oder eliminiert wird, um Aliasing-Artefakte (aufgrund von inadäquater Winkelabtastung) zu reduzieren. Anzeigen können für große Schärfentiefe ausgelegt sein, aber beinahe immer zu Lasten der Vertiefung räumlicher Auflösung und/oder der Sweetspot-Größe des Betrachtungsbereichs. 13A veranschaulicht einen traditionellen Lichtfeldanzeigenbildschirm mit einer Diffusionseigenschaft 1310, von dem Lichtstrahlen durch eine Elementlinsenanordnung 1310 projiziert werden, um ein Bild 1313 zu rendern. Wie veranschaulicht wird das Bild 1313 von einer Vielzahl an Elementbildern 13111, die jeweils von einer der Linsen in der Linsenanordnung 1312 gerendert werden, konstruiert.
Die Ausführungsformen der Erfindung weisen Techniken zum Verarbeiten des Content auf, der derart angezeigt wird, die wahrgenommene Tiefe einer gegebenen Anzeige über jeden dieser Hinweise (Parallax, Akkomodation, Stereopsis und so weiter) zu maximieren, wodurch gestattet wird, dass Stereo-Tiefenhinweise über den Bereich, der für andere Hinweise gestattet ist, hinaus wahrgenommen werden. Mit anderen Worten, das schwächste Glied in der Kette hält die Kette nicht mehr zurück.
Insbesondere verbessern die Ausführungsformen der Erfindung den Stand der Technik durch Verbinden von stereoskopischem Rendering mit bestehenden Lichtfeldzugängen (Mehrfachsicht, optimiertes Raytracing usw.) und Nutzen von Anzeigeausgabe pro Auge, um „elegant“ auf rein Stereobilder, wie sie von einer menschlichen Benutzerperson wahrgenommen werden, „herabzustufen“. Das Ergebnis ist eine Anzeige, die so natürlich (oder „fast holografisch“) wie es die Technologie gestattet ist, während weiterhin eine gewisse Wahrnehmung von Tiefe über den gesamten menschlichen Stereopsisbereich gestattet wird.
13B veranschaulicht das Level an Bildqualität für unterschiedliche Tiefenwerte bezüglich einer Lichtfeldanzeigenebene 1300 (einfach als „schlecht“, „gut“ und „hervorragend“ bezeichnet). Ausgabe unter Verwendung von Stereo-3D-Implementierungen 1301 ist im Allgemeinen gut für den gesamten Bereich von Tiefenwerten, während Lichtfeldanzeigenimplementierungen 1302 einen positiven und negativen Tiefenwert erreichen, wo Bildergebnisse schlecht werden. Unter Verwendung von hybridem Rendering 1303, wie hierin beschrieben, wird die Tiefenregion, die als „hervorragend“ identifiziert wird, für Lichtfeldanzeigen beibehalten, und eine Stereo-3D-Implementierung wird außerhalb dieser Region für akzeptable Ergebnisse verwendet. Die Ausführungsformen der Erfindung können entweder auf bestehenden 3D-Filmen oder beim direkten Rendern von 3D-Szenen arbeiten (das heißt, unter Verwendung von computererstellten Lichtfeldern).
Es ist anzumerken, dass, auch wenn die folgende Erläuterung Beispiele von Anzeigen basierend auf integralen Bildern verwendet, die zugrundeliegenden Prinzipien der Erfindung unter Verwendung anderer Lichtfeldtechnologien, die Tensoranzeigen aufweisen, und additiver Multiebenen-Techniken implementiert werden können.
14A veranschaulicht ein Grafikrenderinggerät 1400 gemäß einer Ausführungsform der Erfindung, das eine Lichtfeldanzeige 1410 und ein Benutzerverfolgungsgerät 1420 zum Verfolgen der Position der Augen und/oder des Kopfes 1411 der Benutzerperson gemeinsam mit Benutzer-/Bildschirmprofilinformationen 1440 verwendet. Eine Ausführungsform des Grafikrenderinggeräts 1400 ist eine Datenverarbeitungsvorrichtung (zum Beispiel ein Computersystem) mit einem Speicher zum Speichern von Programmcode und Daten und einer oder mehreren Grafikverarbeitungseinheiten (GPUs) und/oder zentralen Verarbeitungseinheiten (CPUs) für Implementierung der Techniken, die hierin beschrieben sind. Diese Komponenten sind nicht in 14A veranschaulicht, um zu vermeiden, dass die zugrundeliegenden Prinzipien der Erfindung verdeckt werden. Es ist jedoch offensichtlich, dass die Komponenten, die in 14A veranschaulicht sind (zum Beispiel das Rendering-Typ-Auswahlmodul 1401 und das hybride Rendering-Modul 1402, unten beschrieben), durch Schaltkreise in einer GPU und/oder CPU durch Programmcode, der von der GPU/CPU ausgeführt wird, oder durch eine Kombination von Programmcode und Schaltkreis implementiert werden können.
Bei einer Ausführungsform lokalisiert das Benutzerverfolgungsgerät 1420 das linke und rechte Auge der Benutzerperson in dreidimensionalem (XYZ-)Raum. Dies kann auf viele Weisen implementiert werden, darunter Infrarot-Augenverfolgung, monokulare Gesichtserkennung (unter Annahme, dass IPD und Benutzerkalibrierungsdaten in einem Profil 1440 gespeichert sind) und Tracker/Markierungen/Brillen, die von der Benutzerperson getragen werden.
Die Lichtfeldanzeige 1410 einer Ausführungsform ist ein integrales bildbasiertes System. Auch wenn diese Implementierung einfach zu erklären ist und ideal für die Ausführungsformen der Erfindung ist, können Techniken für Tensoranzeigen und additive Mehrschichtanzeigenarchitekturen adaptiert werden. Die Grafikeingabe kann 3D-Szenen 1430, die unter Verwendung einer Anzahl an Zugängen gerendert werden sollen, oder einen Stereo-3D-Film 1431 (in wessen Fall die Daten zur Erweiterung der Lichtfeldanzeige neu verarbeitet werden) aufweisen.
Die folgenden Techniken können für Rendering/Neuverarbeitung von Content gemäß der Ausführungsformen der Erfindung verwendet werden. Bei einer Ausführungsform führt das hybride Rendering-Modul 1402 diese Techniken unter Steuerung des Rendering-Steuermoduls 1401 durch. Wie veranschaulicht, kann das Rendering-Steuermodul 1401 das hybride Rendering-Modul 1402 gemäß XYZ-Daten, die von dem Benutzerverfolgungsgerät 1420 bereitgestellt werden (zum Beispiel die aktuelle Richtung der Benutzersicht angibt), und Benutzer-/Bildschirmprofildaten 1440 steuern.
Eine Vielfalt an unterschiedlichen Lichtfeldanzeigensystemen funktioniert mit den Rendering-Techniken, die hierin beschrieben sind. Wie in 14B veranschaulicht, kann die Lichtfeldanzeige in einem Head-Mounted-Display (HMD) (zum Beispiel als eine integrale Anzeige oder eine Tensoranzeige) verwendet werden. Unten ist eine detaillierte Beschreibung, wie die vorgeschlagenen Rendering-Verfahren auf einige dieser Anzeigen abbilden, bereitgestellt.
Wie in 14C veranschaulicht, weist eine Ausführungsform eines Head-Mounted-Displays 1465 zwei unabhängige Anzeigen 1466 bis 1467 auf, bei denen es sich zum Beispiel um integrale Anzeigen oder Tensoranzeigen handeln kann. Mit unabhängigen Anzeigen, die für das linke und rechte Auge dediziert sind, wird Konvergenz von HMD mittels Rendering unter Verwendung der Mittenposition jedes Auges erreicht. Als Ergebnis muss für ein Lichtfeld-HMD jede unabhängige Anzeige nur das Problem der Akkomodation für jedes einzelne Auge behandeln. Mit der Rendering-Technik, die hierin beschrieben ist, kann das Rendering auf jeder unabhängigen Anzeige auf die Schärfentiefe der Anzeige geklammert werden; wodurch das Bild in der Szene scharf bleibt.
Für die Lichtfeldanzeige mit standardmäßigem Betrachtungsabstand sehen sowohl das linke Auge als auch das rechte Auge auf dieselbe physische Vorrichtung, was es etwas schwieriger macht, da die Anzeige sowohl Akkomodation als auch Konvergenz erzeugen muss. Wie oben erläutert, weisen aktuell verfügbare SLM keine ausreichende Auflösung zum Unterstützen von Konvergenz und Akkomodation mit großer Schärfentiefe auf. Ein praktischerer Weg wäre die Verfolgung der Betrachterposition und Rendern nur der Position der Betrachterperson mit der vorgeschlagenen Technik. Die vorgeschlagene Technik funktioniert nur mit bestimmten Arten von Anzeigenarchitekturen, wie zum Beispiel integraler Anzeige. Für normale Tensoranzeige verwirrt der widersprüchliche Content auf der vorderen Cutoff-Ebene für Stereo wahrscheinlich den Auflöser, was zu einem großen Rest führt.
Die integrale Anzeige kann ein korrektes Lichtfeld in einem spezifischen Bereich, Auge genannt, erzeugen. Der Sehbereich kann in einen linken Sehbereich und einen rechten Sehbereich unterteilt werden. Die beiden Bereich sind relativ unabhängig voneinander, so wie im Fall von HMD, wo das Lichtfeld unabhängig für jedes Auge erzeugt werden kann. Wie in dem obigen Bild gezeigt, ist die Mittensicht, die fett gezeichnet ist, die Referenzsicht, die als die Textur für die vorderen/hinteren Cutoff-Ebene verwendet wird. Der Sehbereich kann der Bewegung der Augenposition der Betrachterperson mittels Verfolgens der Augenposition der Betrachterperson und Einstellens des integralen Bilds in Echtzeit folgen.
Wie in 14D gezeigt, ist ein weiterer möglicher Zugang Zeit-Multiplexing mit gerichtetem Gegenlicht. Die integrale Anzeige wird mit einem steuerbaren gerichteten Gegenlicht 1490 beleuchtet. Das gerichtete Gegenlicht kann das Licht derart lenken, dass zu jedem Zeitpunkt nur ein Auge in der Lage ist, das Lichtfeld, das von der integralen Anzeige erzeugt wird, wahrzunehmen. Durch schnelles Richtungswechseln des Gegenlichts 1490 auf das linke und rechte Auge, nimmt die Betrachterperson das linke und rechte Lichtfeld zur selben Zeit wahr. Diese Technik kann auch mit Tensoranzeigen verwendet werden.
Bildbasierte Pipeline
Bei einer Ausführungsform nimmt die bildbasierte Pipeline gerasterten Content (zum Beispiel in der Form von Rot-Grün-Blau-Tiefen(RGBD-)Daten) und neuverarbeitet ihn, um Lichtfeldausgabe zu erzeugen. Mit anderen Worten, sie arbeitet im Bildraum. Bei einer Ausführungsform arbeitet die bildbasierte Pipeline wie folgt. Linke/rechte Sichten (oder Multisicht-Nachbarbereiche) werden lokalisiert. Dies kann mittels Anordnens von Multisicht-Rendering-Kameras wie benötigt für Rendering eines Lichtfeldbildes erreicht werden. Basierend auf der Eingabe von dem Benutzerverfolgungsmodul 1420 wird eine Bestimmung gemacht, welche Sicht aktuell von dem linken/rechten Auge der Benutzerperson gesehen werden würde.
Dann wird bei einer Ausführungsform der folgende Vorgang für jedes Auge (links und rechts) wiederholt:
1. Erstellen der relevanten Tiefenkarte. Beliebige Techniken können angewendet werden, darunter Epipolarübereinstimmung, dichter optischer Fluss, Graph Cuts usw. Um Neuprojektionsfehler während Sichtsynthese zu reduzieren, ist es am besten, die Tiefenkarte relativ zu dem Farbkanal von Interesse (linke Farbeingabe für Sichtbereiche des linken Auges und rechte Farbeingabe für Sichtbereiche des rechten Auges) zu berechnen.
2. Berechnen von Z-Raum-Clampingschwellenwerten.
Die Winkelabtastungsgrenze der Lichtfeldanzeige 1410 in Pixel gemessen muss bekannt sein. Für mikrolinsenbasierte integrale Anzeigen kann dies zum Beispiel mittels |Z_Range| = abs(f * nViews) genähert werden, wobei f die Brennweite der Mikrolinsen ist und nViews die Anzahl an Pixeln, die in jedem Elementbild vorhanden sind, (oder die Anzahl an individuellen „Sichten“, die von einem Winkelpixel auf der Lichtfeldanzeige 1410 geliefert werden) ist. Bei einer Ausführungsform werden genauere Schätzungen abhängig von der Anzeige gemacht. Bei einer Ausführungsform kann der Z_Range von einem im Vorhinein gespeicherten Profil 1440 abgerufen werden. Nachdem der Z_Range bestimmt ist, werden die nahen und fernen Tiefenerweiterungen der Anzeige in Pixeln wie folgt bestimmt:

(i) minDispLF = -Z_Range; und
(ii) maxDispLF = +Z_Range.

3. Umwandeln der Tiefenkarten (Clamping, Skalieren, Übersetzen). Bei einer Ausführungsform wird die Tiefenkarte auf minDispLF- und maxDispLF-Grenzen vor der Sichtsynthese geklammert. Die Tiefenkartenwerte können vor dem Clamping auch übersetzt und/oder skaliert werden. Dies hat den Effekt, dass die Tiefenklammer komprimiert und versetzt wird. Die Clamping-Operation wird bei einer Ausführungsform wie folgt implementiert:

(i) falls (zInput <= minDispLF), dann ist zOutput = minDispLF;
(ii) elseif (zlnput >= maxDispLF), dann ist zOuptut = maxDispLF;
(iii) oder sonst ist zOutput = zlnput.

Mit anderen Worten, falls der Eingabetiefenwert zwischen der Mindest- und der Maximaltiefe, die spezifiziert ist, liegt, dann wird der Eingabetiefenwert verwendet; falls er unter dem Mindesttiefenwert liegt, dann wird er an den Mindesttiefenwert geklammert; und falls er über dem maximal erlaubten Tiefenwert liegt, dann wird er an das Maximum geklammert.
4. Sichtsynthese. Zahlreiche Techniken können verwendet werden, die Neuprojizierung der Quellenbilder (zum Beispiel RGBD) verwenden, gemeinsam mit Techniken zum Abschwächen von Okklusions-Artefakten (In-Painting, bilineare Interpolation usw.)
5. Lichtfeldbildformation. Es können bestehende Multisicht-Lichtfeldabbildungstechniken von hier verwendet werde, um diese gerenderten Sichten in das endgültige Rasterbild zu verzahnen/verarbeiten oder als eine Eingabe zum Optimieren von Algorithmen für Mehrschicht-Rendering-Pipelines für andere Anzeigenarchitekturen (wie zum Beispiel Tensoranzeigen).
D-Szenen-Rendering-Pipeline
Bei einer Ausführungsform rendert die 3D-Pipeline direkt geometrische 3D-Szenen in die nötige Lichtfeldausgabe. Sie „schneidet“ eine 3D-Szene, und verflacht den außer Bereich liegenden Content auf eine stereostrukturierte Ebene. Diese Ebene wird dann wieder in die Szene eingefügt und direkt in die Lichtfeldausgabe gerendert (gemeinsam mit dem Nahfeld-Content) . Dies ergibt ein „hybrides“ Lichtfeld, bei dem Nahfeld-Content alle Tiefenhinweise (Akkomodation, Retina-Unschärfe, Stereopsis usw.) aufweist, während Stereopsis-Wahrnehmung in dem Fernfeld beibehalten wird, trotz der inhärenten Fähigkeit der Lichtfeldanzeige, Fernfeldobjekte anzuzeigen.
14E stellt eine Visualisierung der 3D-Szenen-Pipeline bereit. Bei 1491 wird die Szene wie oben beschrieben geschnitten (zum Beispiel unter Verwendung einer hinteren Clamping-Ebene). Schneiden der hinteren Stereo-Ebene ist bei 1492 veranschaulicht, wobei Daten der linken und rechten hinteren Ebene extrahiert werden. Bei 1493 werden die linken oder rechten Grafikdaten ausgewählt und in der Szene bei 1494 wieder zusammengesetzt. Schließlich wird die hybride Lichtfeldausgabe bei 1495 gerendert. Es ist anzumerken, dass dieser Vorgang einmal pro Auge wiederholt werden kann, wobei die geeignete hintere Stereo-Ebene für Rendering ausgewählt wird. Es ist anzumerken, dass der Einfachheit halber nur das Schneiden der hinteren Ebene visualisiert ist. Die zugrundeliegenden Prinzipien der Erfindung können jedoch für sehr nahe Objekte (das heißt nah genug, um außerhalb der Schärfentiefe der Anzeige zu sein) implementiert werden.
Bei einer Ausführungsform kann die 3D-Szenen-Rendering-Pipeline geometriebasiert sein (zum Beispiel Hinzufügen von Ebenen zu der Szene) oder auf Basis eines stereogerenderten Bilds sein:
1. Geometriebasierte Verarbeitung. Eine Ausführungsform der geometriebasierten Pipeline arbeitet wie folgt. Linke/rechte Sichten (oder Multisicht-Nachbarbereiche) werden lokalisiert. Wie oben hinsichtlich der bildbasierten Pipeline erläutert:

(i) Zuerst wird Tiefen-Peeling zum Rendern der entsprechenden nahen/fernen Regionen der originalen 3D-Szene in zwei jeweilige RGB-Texturen verwendet.
(ii) Diese beiden texturierten Ebenen werden (parallel zu der Rendering-Kamera und bildschirmbemessen) eingefügt, an den nahen/fernen Grenzen positioniert. Diese neuen Ebenen sollten die Szene in 3 Regionen schneiden: nah, halbnah (entsprechend der nativen DoF der Anzeige) und fern. Sie zeigen die entsprechende Textur, die sich von dem Tiefen-peeled Rendering-Phasen ergibt, derart an, dass sie perfekt die Szene in dem Bildraum überlappen.
(iii) Lichtfeldbildformation. Wie oben erwähnt, können bestehende Multisicht-LF-Abbildungstechniken von hier verwendet werde, um diese gerenderten Sichten in das endgültige Rasterbild zu verzahnen/verarbeiten oder als eine Eingabe zum Optimieren von Algorithmen für Mehrschicht-Rendering-Pipelines für andere Anzeigenarchitekturen (wie zum Beispiel Tensoranzeigen).

2. Auf Basis eines stereogerenderten Bilds. Eine Ausführungsform der Pipeline auf Basis eines stereogerenderten Bilds arbeitet wie folgt:

(i) Erzeugen von Stereo-Farbpuffern und z-Puffern. Rendern von linken/rechten Farbbildern und linken/rechten Tiefenkarten.
(ii) Anwenden der bildbasierten Pipeline (in Abschnitt A oben beschrieben).

Ein Verfahren gemäß einer Ausführungsform der Erfindung ist in 15 veranschaulicht. Das Verfahren kann in dem Kontext der Systemarchitektur, die oben beschrieben ist, implementiert werden, ist jedoch nicht auf eine spezifische Systemarchitektur beschränkt.
Bei 1500 werden linke/rechte Sichten oder Multisicht-Nachbarbereiche lokalisiert. Wie oben erwähnt, wird basierend auf der Eingabe von dem Benutzerverfolgungsmodul 1420 eine Bestimmung gemacht, welche Sicht aktuell von dem linken/rechten Auge der Benutzerperson gesehen werden würde.
Dann wird der Vorgang, der bei 1501 bis 1505 gezeigt wird, für jedes Auge durchgeführt. Bei 1501 wird eine relevante Tiefenkarte erstellt. Wie erwähnt, kann dies unter Verwendung von Techniken, wie zum Beispiel Epipolarübereinstimmung, dichten optischen Fluss, Graph Cuts, erreicht werden.
Bei 1502 werden die Z-Space-Clamping-Schwellenwerte bestimmt. Wie oben beschrieben, kann dies für mikrolinsenbasierte integrale Anzeigen zum Beispiel wie folgt genähert werden:
|Z_Range| = abs(f * nViews), wobei f die Brennweite der Mikrolinsen ist und nViews die Anzahl an Pixeln, die in jedem Elementbild vorhanden sind, (oder die Anzahl an individuellen „Sichten“, die von einem Winkelpixel auf der Lichtfeldanzeige 1410 geliefert werden) ist. Z_Range kann auch von einem im Vorhinein gespeicherten Profil 1440 abgerufen werden. Nachdem der Z_Range bestimmt ist, werden die nahen und fernen Tiefenerweiterungen der Anzeige in Pixeln wie folgt bestimmt:

(i) minDispLF = -Z_Range; und
(ii) maxDispLF = +Z_Range.

Bei 1503 werden die Tiefenkarten mittels Clamping, Skalieren und/oder Übersetzen umgewandelt. Zum Beispiel kann die Tiefenkarte auf die minDispLF- und maxDispLF-Grenzen vor der Sichtsynthese geklammert werden. Die Tiefenkartenwerte können vor dem Clamping auch übersetzt und/oder skaliert werden. Wie oben beschrieben, falls der Eingabetiefenwert zwischen der Mindest- und der Maximaltiefe, die spezifiziert ist, liegt, dann kann der Eingabetiefenwert verwendet werden; falls er unter dem Mindesttiefenwert liegt, dann kann er an den Mindesttiefenwert geklammert werden; und falls er über dem maximal erlaubten Tiefenwert liegt, dann kann er an das Maximum geklammert werden.
Bei 1504 wird Sichtsynthese zum Beispiel durch Verwenden von Neuprojizierung von Quellenbildern (zum Beispiel RGBD) gemeinsam mit Techniken zum Abschwächen von Okklusions-Artefakten (In-Painting, bilineare Interpolation usw.) durchgeführt und bei 1505 werden die gerenderten Sichten in das endgültige Rasterbild verzahnt/verarbeitet.
Die obigen Beispiele können spezifische Kombinationen von Merkmalen aufweisen. Diese solchen Beispiele sind jedoch nicht in dieser Hinsicht beschränkt und die obigen Beispiele können in verschiedenen Implementierungen das Ausführen nur eines Teilsatzes solcher Merkmale, das Ausführen einer unterschiedlichen Reihenfolge solcher Merkmale, das Ausführen einer unterschiedlichen Kombination solcher Merkmale und/oder das Ausführen zusätzlicher Merkmale zu den explizit aufgelisteten Merkmalen aufweisen. Zum Beispiel können alle Merkmale, die hinsichtlich der beispielhaften Verfahren beschrieben wurden, hinsichtlich des beispielhaften Geräts, des beispielhaften Systems und/oder der beispielhaften Artikel und umgekehrt implementiert werden.
Ausführungsformen der Erfindung können verschiedene Schritte aufweisen, die oben beschrieben wurden. Die Schritte können in maschinenausführbaren Instruktionen umgesetzt sein, die verwendet werden können, um einen Allzweck- oder Spezialprozessor zu veranlassen, die Schritte durchzuführen. Alternativ können diese Schritte von spezifischen HardwareKomponenten, die festverdrahtete Logik zum Durchführen der Schritte aufweisen, oder von einer beliebigen Kombination an programmierbaren Computerkomponenten und benutzerspezifischen Hardwarekomponenten durchgeführt werden.
Wie hierin beschrieben können sich Instruktionen auf spezifische Konfigurationen von Hardware beziehen, wie zum Beispiel anwendungsspezifische integrierte Schaltungen (ASICs), die dazu ausgelegt sind, bestimmte Operationen durchzuführen oder eine vorbestimmte Funktionalität oder Software-Instruktionen aufweisen, die in einem Speicher gespeichert sind, der in einem nichtflüchtigen computerlesbaren Medium umgesetzt ist. Somit können die Techniken, die in den Figuren gezeigt sind, unter Verwendung von Code und Daten, die auf einer oder mehreren elektronischen Vorrichtungen (zum Beispiel ein Endgerät, ein Netzwerkelement usw.) gespeichert sind und darauf ausgeführt werden, implementiert werden. Solche elektronischen Vorrichtungen speichern und kommunizieren (intern und/oder über ein Netzwerk mit weiteren elektronischen Vorrichtungen) Code und Daten unter Verwendung von computermaschinenlesbaren Medien, wie zum Beispiel nichtflüchtigen computermaschinenlesbaren Speichermedien (zum Beispiel Magnetplatten; optische Platten; Direktzugriffsspeicher-, Nurlesespeicher-, Flash-Speicher-Vorrichtungen; Phasenwechselspeicher) und flüchtigen computermaschinenlesbaren Kommunikationsmedien (zum Beispiel elektrische, optische, akustische oder andere Formen von verbreiteten Signalen - wie zum Beispiel Trägerwellen, Infrarotsignale, digitale Signale usw.). Zusätzlich weisen solche elektronischen Vorrichtungen typischerweise einen Satz von einem oder mehreren Prozessoren, die mit einer oder mehreren Komponenten gekoppelt sind, wie zum Beispiel eine oder mehrere Speichervorrichtungen (nichtflüchtige maschinenlesbare Speichermedien), Benutzereingabe-/-ausgabevorrichtungen (zum Beispiel eine Tastatur, einen Berührungsbildschirm und/oder eine Anzeige) und Netzwerkverbindungen auf. Das Koppeln des Satzes von Prozessoren und weiterer Komponenten geschieht typischerweise über einen oder mehrere Busse und Bridges (auch als Bussteuerungen bezeichnet). Die Speichervorrichtung und -Signale, die den Netzwerkverkehr tragen, stellen jeweils ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien dar. Somit speichert die Speichervorrichtung einer gegebenen elektronischen Vorrichtung typischerweise Code und/oder Daten für Ausführung auf dem Satz von einem oder mehreren Prozessoren der elektronischen Vorrichtung. Natürlich können ein oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung unterschiedlicher Kombinationen von Software, Firmware und/oder Hardware implementiert werden. Durch diese detaillierte Beschreibung wurden zum Zweck der Erklärung zahlreiche spezifische Details präsentiert, um ein umfassendes Verständnis der vorliegenden Erfindung bereitzustellen. Einer Fachperson ist jedoch ersichtlich, dass die Erfindung ohne manche dieser spezifischen Details umgesetzt werden kann. In bestimmten Fällen wurden gut bekannte Strukturen und Funktionen nicht ausführlich im Detail beschrieben, um zu vermeiden, dass der Gegenstand der vorliegenden Erfindung verdeckt wird. Dementsprechend soll der Schutzumfang und Geist der Erfindung in Bezug auf die Ansprüche, die folgen, bewertet werden.

Claims

Beansprucht wird:
Gerät, das Folgendes aufweist: eine Benutzerverfolgungsvorrichtung, die verwendet werden kann, die linke und rechte Sicht der Augen einer Benutzerperson zu identifizieren; eine Grafikrenderingvorrichtung zum Erstellen mindestens einer Tiefenkarte für die linke und rechte Sicht und Berechnen von Tiefen-Clamping-Schwellenwerten, die einen Mindesttiefenwert und einen Maximaltiefenwert aufweisen; die Grafikrenderingvorrichtung zum Umwandeln der Tiefenkarte gemäß dem Mindesttiefenwert und dem Maximaltiefenwert und, um als Reaktion Sichtsynthese zum Rendern von linken und rechten Sichten unter Verwendung der umgewandelten Tiefenkarte durchzuführen.
Gerät nach Anspruch 1, das ferner Folgendes aufweist: das Grafikrenderinggerät zum Durchführen von Multisicht-Lichtfeldabbildungstechniken zum Verzahnen/Verarbeiten der gerenderten Sichten, die sich aus der Sichtsynthese ergeben, in ein endgültiges Rasterbild oder als Eingabe für eine Optimierung für Mehrschicht-Rendering-Pipelines für andere Anzeigenarchitekturen.
Gerät nach Anspruch 1 oder 2, wobei das Identifizieren der linken und rechten Sicht das Verwenden von Augenverfolgung zum Verfolgen einer aktuellen Ausrichtung der Augen der Benutzerperson aufweist.
Gerät nach Anspruch 1, 2 oder 3, wobei die mindestens eine Tiefenkarte unter Verwendung von Epipolarübereinstimmung, dichtem optischen Fluss und/oder Graph Cuts erstellt wird.
Gerät nach Anspruch 1, 2 oder 3, wobei die mindestens eine Tiefenkarte bezüglich Farbkanälen, die der linken und rechten Sicht zugeordnet sind, erstellt wird.
Gerät nach Anspruch 1, 2 oder 5, das ferner Folgendes aufweist: eine Lichtfeldanzeige, wobei Berechnen der Tiefenwertschwellenwerte ferner Bestimmen der Winkelabtastgrenze der Lichtfeldanzeige in Pixel gemessen aufweist.
Gerät nach Anspruch 6, wobei die Lichtfeldanzeige eine mikrolinsenbasierte integrale Anzeige aufweist, und wobei die Winkelabtastgrenze geschätzt wird mittels |Z_Range| = abs(f * nViews), wobei f eine Brennweite der Mikrolinsen ist und nViews eine Anzahl an Pixeln in jedem Elementbild ist.
Gerät nach Anspruch 1 oder 7, wobei das Rendering der linken und rechten Sicht ferner Verwenden einer geometriebasierten Rendering-Pipeline einer Grafikverarbeitungseinheit aufweist.
Gerät nach Anspruch 1 oder 7, wobei das Rendering der linken und rechten Sicht ferner Verwenden einer Rendering-Pipeline auf Basis eines stereogerenderten Bilds einer Grafikverarbeitungseinheit aufweist.
Gerät, das Folgendes aufweist: Mittel zum Identifizieren der linken und rechten Sicht der Augen einer Benutzerperson; Mittel zum Erstellen mindestens einer Tiefenkarte für die linke und rechte Sicht; Mittel zum Berechnen von Tiefen-Clamping-Schwellenwerten, die einen Mindesttiefenwert und einen Maximaltiefenwert aufweisen; Mittel zum Umwandeln der Tiefenkarte gemäß dem Mindesttiefenwert und dem Maximaltiefenwert; und Mittel zum Durchführen von Sichtsynthese zum Rendern von linker und rechter Sicht unter Verwendung der umgewandelten Tiefenkarte.
Gerät nach Anspruch 10, das ferner Folgendes aufweist: Mittel zum Durchführen von Multisicht-Lichtfeldabbildungstechniken zum Verzahnen/Verarbeiten der gerenderten Sichten, die sich aus der Sichtsynthese ergeben, in ein endgültiges Rasterbild oder als Eingabe für eine Optimierung für Mehrschicht-Rendering-Pipelines für andere Anzeigenarchitekturen.
Gerät nach Anspruch 10 oder 11, wobei das Identifizieren der linken und rechten Sicht das Verwenden von Augenverfolgung zum Verfolgen einer aktuellen Ausrichtung der Augen der Benutzerperson aufweist.
Gerät nach Anspruch 10, 11 oder 12, wobei die mindestens eine Tiefenkarte unter Verwendung von Epipolarübereinstimmung, dichtem optischen Fluss und/oder Graph Cuts erstellt wird.
Gerät nach Anspruch 10, 11 oder 12, wobei die mindestens eine Tiefenkarte bezüglich Farbkanälen, die der linken und rechten Sicht zugeordnet sind, erstellt wird.
Gerät nach Anspruch 10, 11 oder 14, wobei Berechnen der Tiefenwertschwellenwerte ferner Bestimmen der Winkelabtastgrenze einer Lichtfeldanzeige in Pixel gemessen aufweist.
Gerät nach Anspruch 15, wobei die Lichtfeldanzeige eine mikrolinsenbasierte integrale Anzeige aufweist, und wobei die Winkelabtastgrenze geschätzt wird mittels |Z_Range| = abs(f * nViews), wobei f eine Brennweite der Mikrolinsen ist und nViews eine Anzahl an Pixeln in jedem Elementbild ist.
Gerät nach Anspruch 10 oder 16, wobei das Rendering der linken und rechten Sicht ferner Verwenden einer geometriebasierten Rendering-Pipeline einer Grafikverarbeitungseinheit aufweist.
Gerät nach Anspruch 10 oder 16, wobei das Rendering der linken und rechten Sicht ferner Verwenden einer Rendering-Pipeline auf Basis eines stereogerenderten Bilds einer Grafikverarbeitungseinheit aufweist.
Maschinenlesbares Medium, auf dem Programmcode gespeichert ist, der bei Ausführung durch eine Maschine die Maschine veranlasst, die folgenden Operationen durchzuführen: Identifizieren der linken und rechten Sicht der Augen einer Benutzerperson; Erstellen mindestens einer Tiefenkarte für die linke und rechte Sicht; Berechnen von Tiefen-Clamping-Schwellenwerten, die einen Mindesttiefenwert und einen Maximaltiefenwert aufweisen; Umwandeln der Tiefenkarte gemäß dem Mindesttiefenwert und dem Maximaltiefenwert; und Durchführen von Sichtsynthese zum Rendern von linken und rechten Sichten unter Verwendung der umgewandelten Tiefenkarte.
Maschinenlesbares Medium nach Anspruch 19, das ferner Programmcode aufweist, um die Maschine zu veranlassen, die folgende Operation durchzuführen: Durchführen von Multisicht-Lichtfeldabbildungstechniken zum Verzahnen/Verarbeiten der gerenderten Sichten, die sich aus der Sichtsynthese ergeben, in ein endgültiges Rasterbild oder als Eingabe für eine Optimierung für Mehrschicht-Rendering-Pipelines für andere Anzeigenarchitekturen.
Maschinenlesbares Medium nach Anspruch 19 oder 20, wobei das Identifizieren der linken und rechten Sicht das Verwenden von Augenverfolgung zum Verfolgen einer aktuellen Ausrichtung der Augen der Benutzerperson aufweist.
Maschinenlesbares Medium nach Anspruch 19, 20 oder 21, wobei die mindestens eine Tiefenkarte unter Verwendung von Epipolarübereinstimmung, dichtem optischen Fluss und/oder Graph Cuts erstellt wird.
Maschinenlesbares Medium nach Anspruch 19, 20 oder 21, wobei die mindestens eine Tiefenkarte bezüglich Farbkanälen, die der linken und rechten Sicht zugeordnet sind, erstellt wird.
Maschinenlesbares Medium nach Anspruch 19, 20 oder 23, wobei Berechnen der Tiefenwertschwellenwerte ferner Bestimmen der Winkelabtastgrenze einer Lichtfeldanzeige in Pixel gemessen aufweist.
Maschinenlesbares Medium nach Anspruch 24, wobei die Lichtfeldanzeige eine mikrolinsenbasierte integrale Anzeige aufweist, und wobei die Winkelabtastgrenze geschätzt wird mittels |Z_Range| = abs(f * nViews), wobei f eine Brennweite der Mikrolinsen ist und nViews eine Anzahl an Pixeln in jedem Elementbild ist.
Maschinenlesbares Medium nach Anspruch 19 oder 25, wobei das Rendering der linken und rechten Sicht ferner Verwenden einer geometriebasierten Rendering-Pipeline einer Grafikverarbeitungseinheit aufweist.