DE102019114970A1

DE102019114970A1 - Erweiterte immersive medien-pipeline zur korrektur von artefakten und der klarheit von objekten in rechenumgebungen

Info

Publication number: DE102019114970A1
Application number: DE102019114970.3A
Authority: DE
Inventors: Atsuo Kuwahara; Gokcen Cilingir; James Holland; Jason Tanner; Kai Xiao; Mayuresh Varerkar; Narayan Biswal; Qian Xu; Sang-Hee Lee; Yi-Jen Chiu
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-07-31
Filing date: 2019-06-04
Publication date: 2020-02-06
Also published as: US10839589B2; US20200043217A1

Abstract

Es wird ein Mechanismus zum Unterstützen einer erweiterten immersiven Medien-Pipeline zur Korrektur von Artefakten und der Klarheit von Objekten in Rechenumgebungen beschrieben. Eine Vorrichtung der hier beschriebenen Ausführungsformen enthält ein oder mehrere Prozessoren zum Extrahieren von semantischen Daten, die sich auf Objekte in einer Szene beziehen, die von ein oder mehreren Kameras aufgenommen wurde, wobei die Objekte Verzerrungen aufweisen und, basierend auf den semantischen Daten, ein dreidimensionales (3D) Modell des Inhalts der Szene bilden, wobei der Inhalt die Objekte einschließt. Die ein oder mehreren Prozessoren haben ferner die Aufgabe, das 3D-Modell, das den Inhalt und die semantischen Daten enthält, zu einer codierten Datei zu codieren, die den codierten Inhalt und codierte semantische Daten enthält, und die codierte Datei über eine immersive Medien-Pipeline zu übertragen, um die Korrektur der Verzerrungen zu unterstützen und die Szene, welche die Objekte enthält, ohne die Verzerrungen zu rendern.

Description

VERWANDTE ANMELDUNG
Diese Anmeldung bezieht sich auf die gemeinsam zugewiesene U.S.-Patentanmeldung der Serien-Nr. 16/050,153, mit dem Titel REDUZIERTES RENDERING EINES SECHS-FREIHEITSGRADE-VIDEOS von Jill Boyce, eingereicht am 31. Juli 2018, deren gesamter Inhalt hierin aus Referenzgründen einbezogen ist.
TECHNISCHES GEBIET
Die hierin beschriebenen Ausführungsformen beziehen sich allgemein auf Computer. Insbesondere werden Ausführungsformen zum Unterstützen einer erweiterten immersiven Medien-Pipeline zur Korrektur von Artefakten und der Klarheit von Objekten in Rechenumgebungen beschrieben.
HINTERGRUND
Grafikverarbeitung hat sich von zweidimensionalen (2D) Ansichten zu dreidimensionalen (3D) Ansichten weiterentwickelt. Die fortgesetzte Evolution von Grafikverarbeitung wird als Weiterentwicklung von 360-Grad-Video und Entwicklung von Drei-Freiheitsgrade-(3DoF)-Video und Sechs-Freiheitsgrade-(6DoF)-Video für die Präsentation von immersivem Video (IV), erweiterter Realität (AR) und Erfahrungen virtueller Realität (VR) betrachtet.
Sechs-Freiheitsgrade-Video ist ein aufstrebender Fall des Gebrauchs von immersivem Video, das einem Betrachter ein immersives Medienerlebnis bietet, bei dem der Betrachter den Blickpunkt einer Szene steuert. Das einfachere 3DoF-Video (z. B. 360-Grad- oder Panoramavideo) gestattet einem Betrachter, von einer feststehenden Position aus die Orientierung um die X-, Y- und Z-Achse, auch als Gieren, Nicken und Rollen beschrieben, zu ändern, während 6DoF-Video es dem Betrachter ermöglicht, die Position durch Translationsbewegungen entlang der X-, Y- und Z-Achse zu ändern.
Es wird in Erwägung gezogen, dass 6DoF-Video unter Verwendung von Punktwolken repräsentiert werden kann. Das Rendering von Punktwolkendaten ist jedoch rechnerisch teuer, so dass es schwierig ist, Punktwolkenvideos, die eine große Anzahl von Punkten bei hoher Bildfrequenz enthalten, zu rendern. Außerdem sind Punktwolkendatenraten groß, so dass sie eine große Kapazität für Speicherung oder Übertragung benötigen.
Die Korrektur von Artefakten und die Klarheit von Objekten ist seit langem ein Anliegen bei der Videoverarbeitung und Rendering in Rechenumgebungen. Konventionelle Techniken sind erheblich ineffizient und verschwenderisch im Umgang mit Ressourcen und bieten keine hochwertigen Resultate. Konventionellen Techniken mangelt es an Klarheit der Objekterkennung und -betrachtung neben mangelhafter Präzision in der Klassifizierung von Bildern und Objekten.
Figurenliste
Ausführungsformen werden beispielhaft und nicht beschränkend in den Figuren der beigefügten Zeichnungen dargestellt, in denen gleiche Bezugszeichen auf ähnliche Elemente verweisen.

1 ist ein Blockdiagramm eines Verarbeitungssystems gemäß einer Ausführungsform.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors, der ein oder mehrere Prozessorkerne aufweist, eines integrierten Speichercontrollers und eines integrierten Grafikprozessors.
3 ist ein Blockdiagramm eines Grafikprozessors, der eine diskrete Grafikverarbeitungseinheit oder ein mit einer Vielzahl von Prozessorkernen integrierter Grafikprozessor sein kann.
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine eines Grafikprozessors im Einklang mit einigen Ausführungsformen.
5 ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns gemäß einigen Ausführungsformen.
6A-6B stellen eine Thread-Ausführungslogik dar, die ein Array von Verarbeitungselementen einschließt, die gemäß einiger Ausführungsformen in einem Grafikprozessorkern eingesetzt werden.
7 ist ein Blockdiagramm, das Grafikprozessor-Befehlsformate gemäß einigen Ausführungsformen darstellt.
8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors.
9A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat gemäß einer Ausführungsform darstellt.
9B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlssequenz gemäß einer Ausführungsform darstellt.
10 stellt eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einiger Ausführungsformen dar.
11A ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem darstellt, das zur Herstellung einer integrierten Schaltung verwendet werden kann, um Operationen gemäß einer Ausführungsform durchzuführen.
11B stellt eine Querschnitts-Seitenansicht einer Gehäuseanordnung einer integrierten Schaltung gemäß einiger Ausführungsformen dar.
12 ist ein Blockdiagramm, das eine beispielhafte integrierte Schaltung als Ein-Chip-System darstellt, die gemäß einer Ausführungsform unter Verwendung von ein oder mehreren IP-Kernen hergestellt werden kann.
13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren für den Einsatz innerhalb eines Ein-Chip-Systems (SoC) gemäß den hierin beschriebenen Ausführungsformen darstellen.
14A-14B stellen eine zusätzliche beispielhafte Grafikprozessorlogik gemäß den hierin beschriebenen Ausführungsformen dar.
15A stellt mehrere Formen von immersivem Video dar.
15B stellt Bildprojektions- und Texturebenen für immersives Video dar.
16 stellt ein Client-Server-System für Erzeugung und Konsum von immersivem Video dar.
17A-17B stellen Systeme zum Codieren und Decodieren von 3DoF Plus-Inhalten dar.
18A-18B stellen Systeme zum Codieren und Decodieren von texturierten 6DoF-Geometriedaten dar.
19A-19B stellen ein System zum Codieren und Decodieren von 6DoF-Punktwolkendaten dar.
20 stellt eine Rechenvorrichtung dar, die einen erweiterten Konstruktions-Pipelinemechanismus gemäß einer Ausführungsform hostet.
21 stellt einen Konstruktions-Pipelinemechanismus für erweiterte immersive Medien und einen Render-Pipelinemechanismus für erweiterte immersive Medien gemäß einer Ausführungsform dar.
22 stellt eine konventionelle Pipeline dar, die eine konventionelle Technik anwendet.
23A stellt eine erweiterte immersive Medien-Pipeline gemäß einer Ausführungsform dar.
23B stellt eine erweiterte immersive Medien-Pipeline gemäß einer Ausführungsform dar.
24A stellt ein Verfahren zur Nutzung von semantischen Daten in einer erweiterten immersiven Medien-Pipeline gemäß einer Ausführungsform dar.
24B stellt ein Verfahren zur Nutzung von Codebucheigenschaften in einer erweiterten immersiven Medien-Pipeline gemäß einer Ausführungsform dar.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt. Die hierin beschriebenen Ausführungsformen können jedoch ohne diese spezifischen Details durchgeführt werden. In anderen Fällen sind wohlbekannte Schaltungen, Strukturen und Techniken nicht ausführlich gezeigt worden, um das Verständnis dieser Beschreibung nicht zu verschleiern.
Ausführungsformen ermöglichen eine neuartige Technik für Korrektur von Artefakten, auf Objekterkennung basierende Texturgrenzen, erweiterte Konstruktion von Punktwolken, die auf künstlicher Intelligenz (AI) basierende Bildobjekt-Klassifizierungen verschmelzen. Wie in diesem Dokument weiter ausgeführt werden wird, ermöglicht diese neuartige Technik ferner ein ressourceneffizientes System für bessere Verarbeitung und Ausgabe von Objekten durch effiziente Korrektur von Artefakten, Erkennung und Klassifizierung von Objekten usw.
Es wird in Betracht gezogen, dass Begriffe wie „Anfrage“, „Abfrage“, „Job“, „Arbeit“, „Arbeitselement“ und „Arbeitslast“ in diesem Dokument austauschbar verwendet sein können. Gleichermaßen kann sich eine „Anwendung“ oder ein „Agent“ auf ein Computerprogramm, eine Softwareanwendung, ein Spiel, eine Arbeitsstationsanwendung usw. beziehen oder diese umfassen, das über eine Anwendungsprogrammierschnittstelle (API) angeboten wird, wie beispielsweise eine freie Rendering-API, wie beispielsweise Open Graphics Library (OpenGL®), Open Computing Language (OpenCL®), CUDA®, DirectX® 11, DirectX® 12 usw., wobei „Dispatch“ austauschbar als „Arbeitseinheit“ oder „Zeichnung“ bezeichnet werden kann und gleichermaßen „Anwendung“ austauschbar als „Arbeitsablauf“ oder einfach „Agent“ bezeichnet werden kann. Beispielsweise kann eine Arbeitslast, wie z. B. die eines dreidimensionalen (3D) Spiels, eine beliebige Anzahl und Art von „Einzelbildern“ umfassen und ausgeben, wobei jedes Einzelbild ein Bild darstellen kann (z. B. Segelboot, menschliches Gesicht). Ferner kann jedes Einzelbild eine beliebige Anzahl und Art von Arbeitseinheiten enthalten und anbieten, wobei jede Arbeitseinheit einen Teil (z. B. den Mast eines Segelboots, die Stirn eines menschlichen Gesichts) des Bilds (z. B. Segelboot, menschliches Gesicht) repräsentieren kann, der durch sein entsprechendes Einzelbild repräsentiert wird. Aus Gründen der Kohärenz kann jedoch jeder Posten in diesem Dokument durch einen einzigen Begriff (z. B. „Dispatch“, „Agent“ usw.) referenziert sein.
In einigen Ausführungsformen können Begriffe wie „Anzeigebildschirm“ und „Anzeigefläche“ unter Bezugnahme auf den sichtbaren Teil einer Anzeigevorrichtung austauschbar verwendet werden, während der Rest der Anzeigevorrichtung in eine Rechenvorrichtung, wie etwa ein Smartphone, eine tragbare Vorrichtung usw., integriert sein kann.
Es wird betrachtet und darauf hingewiesen, dass Ausführungsformen nicht auf eine bestimmte Rechenvorrichtung, Software-Anwendung, Hardware-Komponente, Anzeigevorrichtung, Anzeigebildschirm oder -fläche, Protokoll, Standard usw. beschränkt sind. Ausführungsformen können beispielsweise auf eine beliebige Anzahl und Art von Echtzeit-Anwendungen auf einer beliebigen Anzahl und Art von Computern, wie etwa Desktops, Laptops, Tablet-Computern, Smartphones, Head-Mounted Displays und anderen tragbaren Geräten und/oder dergleichen angewandt und damit verwendet werden. Ferner können beispielsweise Rendering-Szenarien, die für effiziente Leistung diese neue Technologie nutzen, von einfachen Szenarien, wie beispielsweise Desktopgestaltung, bis zu komplexen Szenarien, wie beispielsweise 3D-Spiele, Anwendungen für erweiterte Realität usw., reichen.
Systemübersicht
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. In verschiedenen Ausführungsformen umfasst das System 100 ein oder mehrere Prozessoren 102 und ein oder mehrere Grafikprozessoren 108 und kann ein Einzelprozessor-Desktopsystem, ein Multiprozessor-Arbeitsplatzsystem oder ein Serversystem sein, das eine große Anzahl von Prozessoren 102 oder Prozessorkernen 107 aufweist. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in einer integrierten Schaltung als Ein-Chip-System (SoC) für den Einsatz in mobilen, handgehaltenen oder integrierten Vorrichtungen einbezogen sein kann.
In einer Ausführungsform kann das System 100 eine serverbasierte Spielplattform, eine Spielkonsole, einschließlich einer Spiel- und Medienkonsole, eine mobile Spielkonsole, eine handgehaltene Spielkonsole oder eine Online-Spielkonsole enthalten oder darin integriert sein. In einigen Ausführungsformen ist das System 100 ein Mobiltelefon, ein Smartphone, eine Tablet-Rechenvorrichtung oder eine mobile Internet-Vorrichtung. Das Verarbeitungssystem 100 kann auch eine tragbare Vorrichtung, wie etwa eine tragbare Smart Watch-Vorrichtung, eine Smart Eyewear-Vorrichtung, eine Vorrichtung für erweiterte Realität oder eine Vorrichtung für virtuelle Realität enthalten, damit gekoppelt oder darin integriert sein. In einigen Ausführungsformen ist das Verarbeitungssystem 100 ein Fernsehgerät oder eine Set-Top-Box, die ein oder mehrere Prozessoren 102 und eine grafische Benutzeroberfläche aufweist, die von ein oder mehreren Grafikprozessoren 108 erzeugt wird.
In einigen Ausführungsformen enthalten die ein oder mehreren Prozessoren 102 jeweils ein oder mehrere Prozessorkerne 107, um Befehle zu verarbeiten, die, wenn sie ausgeführt werden, Operationen für System- und Benutzersoftware durchführen. In einigen Ausführungsformen ist jeder der ein oder mehreren Prozessorkerne 107 dazu ausgebildet, einen bestimmten Befehlssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Befehlssatz 109 Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC) oder Datenverarbeitung über ein Very Long Instruction Word (VLIW) unterstützen. Mehrere Prozessorkerne 107 können jeweils einen unterschiedlichen Befehlssatz 109 verarbeiten, der Befehle enthalten kann, um die Emulation anderer Befehlssätze zu unterstützen. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen, wie etwa einen Digitalsignalprozessor (DSP), enthalten.
In einigen Ausführungsformen enthält der Prozessor 102 einen Cache-Speicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzigen internen Cache oder mehrere Ebenen von internem Cache aufweisen. In einigen Ausführungsformen wird der Cache-Speicher von verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. In einigen Ausführungsformen nutzt der Prozessor 102 auch einen externen Cache (z. B. einen Level-3 (L3)-Cache oder Last Level Cache (LLC)) (nicht gezeigt), der von Prozessorkernen 107 unter Verwendung von bekannten Cache-Kohärenztechniken gemeinsam genutzt werden kann. Zusätzlich in dem Prozessor 102 enthalten ist eine Registerdatei 106, die unterschiedliche Arten von Registern zum Speichern unterschiedlicher Arten von Daten (z. B. Ganzzahlenregister, Gleitkommaregister, Statusregister und ein Befehlszeigerregister) enthalten kann. Einige Register können Allzweckregister sein, während andere Register für das Design des Prozessors 102 spezifisch sein können.
In einigen Ausführungsformen ist (sind) ein oder mehrere Prozessor(en) 102 mit einem oder mehreren Schnittstellenbus(sen) 110 gekoppelt, um Kommunikationssignale, wie etwa Adressen, Daten oder Steuersignale zwischen dem Prozessor 102 und anderen Komponenten in dem System 100 zu übertragen. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus sein, wie z. B. eine Version des Direct Media Interface (DMI)-Busses. Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral Component Interconnect-Busse (z. B. PCI, PCI Express), Speicherbusse oder andere Arten von Schnittstellenbussen einschließen. In einer Ausführungsform enthält (enthalten) der Prozessor (die Prozessoren) 102 einen integrierten Speichercontroller 116 und einen Plattform-Controllerhub 130. Der Speichercontroller 116 unterstützt Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der Plattform-Controllerhub (PCH) 130 Verbindungen zu E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Speichervorrichtung 120 kann eine dynamische Direktzugriffsspeicher (DRAM)-Vorrichtung, eine statische Direktzugriffsspeicher (SRAM)-Vorrichtung, eine Flash-Speichervorrichtung, eine Phasenwechsel-Speichervorrichtung oder eine andere Speichervorrichtung sein, die eine geeignete Leistung aufweist, um als Prozessspeicher zu dienen. In einer Ausführungsform kann die Speichervorrichtung 120 als Systemspeicher für das System 100 arbeiten, um Daten 122 und Befehle 121 zum Gebrauch zu speichern, wenn die ein oder mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Der Speichercontroller 116 wird auch mit einem optionalen externen Grafikprozessor 112 gekoppelt, der mit den ein oder mehreren Grafikprozessoren 108 in den Prozessoren 102 kommuniziert, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen kann eine Anzeigevorrichtung 111 mit dem (den) Prozessor(en) 102 verbunden werden. Die Anzeigevorrichtung 111 kann eine oder mehrere einer internen Anzeigevorrichtung, wie etwa in einer mobilen elektronischen Vorrichtung, oder einer Laptop-Vorrichtung oder einer externen Anzeigevorrichtung sein, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angebracht sein kann. In einer Ausführungsform kann die Anzeigevorrichtung 111 ein Head-Mounted Display (HMD), wie etwa eine stereoskopische Anzeigevorrichtung, für den Einsatz in Virtual Reality (VR)-Anwendungen oder Augmented Reality (AR)-Anwendungen sein.
In einigen Ausführungsformen versetzt der Plattform-Controllerhub 130 Peripheriegeräte in die Lage, eine Verbindung mit der Speichervorrichtung 120 und dem Prozessor 102 über einen Hochgeschwindigkeits-E/A-Bus herzustellen. Die E/A-Peripheriegeräte umfassen, sind aber nicht beschränkt auf, einen Audiocontroller 146, einen Netzwerkcontroller 134, eine Firmware-Schnittstelle 128, einen Funk-Transceiver 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (z. B. Festplattenlaufwerk, Flash-Speicher usw.). Die Datenspeichervorrichtung 124 kann über eine Speicherschnittstelle (z. B. SATA) oder über einen Peripheriebus, wie z. B. einen Peripheral Component Interconnect-Bus (z. B. PCI, PCI Express) verbunden werden. Die Berührungssensoren 125 können Touchscreensensoren, Drucksensoren oder Fingerabdrucksensoren einschließen. Der Funk-Transceiver 126 kann ein Wi-Fi-Transceiver, ein Bluetooth-Transceiver oder ein Mobilnetzwerk-Transceiver, wie z. B. ein 3G-, 4G- oder Long-Term Evolution (LTE)-Transceiver, sein. Die Firmware-Schnittstelle 128 ermöglicht Kommunikation mit System-Firmware und kann zum Beispiel eine Unified Extensible Firmware Interface (UEFI) sein. Der Netzwerkcontroller 134 kann eine Netzwerkverbindung mit einem Kabelnetzwerk ermöglichen. In einigen Ausführungsformen wird ein Hochleistungs-Netzwerkcontroller (nicht gezeigt) mit dem Schnittstellenbus 110 gekoppelt. Der Audiocontroller 146 ist in einer Ausführungsform ein Multi-Channel-High-Definition-Audiocontroller. In einer Ausführungsform enthält das System 100 einen optionalen Legacy-E/A-Controller 140, um Legacy-Vorrichtungen (z. B. Personal System 2 (PS/2)) mit dem System zu koppeln. Der Plattform-Controllerhub 130 kann auch mit einem oder mehreren Universal Serial Bus (USB)-Controllern 142 zum Anschließen von Eingabevorrichtungen, wie z. B. Kombinationen von Tastatur und Maus 143, einer Kamera 144 oder anderen USB-Eingabevorrichtungen, verbunden werden.
Es versteht sich, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da andere Arten von Datenverarbeitungssystemen, die anders konfiguriert sind, ebenfalls verwendet werden können. Zum Beispiel kann eine Instanz des Speichercontrollers 116 und des Plattform-Controllerhubs 130 in einen diskreten externen Grafikprozessor, wie z. B. den externen Grafikprozessor 112, integriert sein. In einer Ausführungsform können der Plattform-Controllerhub 130 und/oder der Speichercontroller 160 extern zu dem einen oder den mehreren Prozessor(en) 102 sein. Zum Beispiel kann das System 100 einen externen Speichercontroller 116 und einen Plattform-Controllerhub 130 enthalten, die innerhalb eines System-Chipsatzes, der mit dem (den) Prozessor(en) 102 in Kommunikation steht, als Speicher-Controllerhub und Peripheriegeräte-Controllerhub konfiguriert sein kann.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200, der ein oder mehrere Prozessorkerne 202A-202N aufweist, eines integrierten Speichercontrollers 214 und eines integrierten Grafikprozessors 208. Jene Elemente von 2, welche die gleichen Bezugsnummern (oder Namen) wie die Elemente einer anderen hierin enthaltenen Figur haben, können in jeder Weise ähnlich den woanders hierin beschriebenen Elementen arbeiten oder funktionieren, sind aber nicht auf solche beschränkt. Der Prozessor 200 kann zusätzliche Kerne bis zu und einschließlich dem zusätzlichen Kern 202N, die durch die gestrichelten Kästen repräsentiert sind, enthalten.
Jeder der Prozessorkerne 202A-202N enthält ein oder mehrere interne Cache-Einheiten 204A-204N. In einigen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf ein oder mehrere gemeinsam genutzte Cache-Einheiten 206.
Die internen Cache-Einheiten 204A-204N und die gemeinsam genutzten Cache-Einheiten 206 repräsentieren eine Cache-Speicherhierarchie innerhalb des Prozessors 200. Die Cache-Speicherhierarchie kann mindestens eine Ebene von Befehls- und Datencache innerhalb jedes Prozessorkerns und ein oder mehrere Ebenen von gemeinsam genutztem Mid-Level-Cache, wie z. B. Level 2 (L2), Level 3 (L3), Level 4 (L4), oder andere Ebenen von Cache aufweisen, wobei die höchste Cache-Ebene vor dem externen Speicher als LLC klassifiziert ist. In einigen Ausführungsformen erhält eine Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A-204N aufrecht.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von ein oder mehreren Buscontrollereinheiten 216 und einen Systemdienstkern 210 enthalten. Die ein oder mehreren Buscontrollereinheiten 216 verwalten einen Satz von Peripheriebussen, wie z. B. ein oder mehrere PCI- oder PCI Express-Busse. Der Systemdienstkern 210 bietet eine Verwaltungsfunktion für die verschiedenen Prozessorkomponenten. In einigen Ausführungsformen enthält der Systemdienstkern 210 ein oder mehrere integrierte Speichercontroller 214, die den Zugriff auf verschiedene externe Speichervorrichtungen (nicht gezeigt) verwalten.
In einigen Ausführungsformen schließen die ein oder mehreren Prozessorkerne 202A-202N Unterstützung für gleichzeitiges Multi-Threading ein. In einer solchen Ausführungsform schließt der Systemdienstkern 210 Komponenten zum Koordinieren und Betreiben von Kernen 202A-202N während der Multi-Threading-Verarbeitung ein. Der Systemdienstkern 210 kann zusätzlich eine Leistungssteuereinheit (PCU) aufweisen, die Logik und Komponenten zum Regulieren des Leistungszustands der Prozessorkerne 202A-202N und des Grafikprozessors 208 enthält.
In einigen Ausführungsformen enthält der Prozessor 200 zusätzlich einen Grafikprozessor 208, um Grafikverarbeitungsoperationen auszuführen. In einigen Ausführungsformen ist der Grafikprozessor 208 mit dem Satz von gemeinsam genutzten Cache-Einheiten 206 und dem Systemdienstkern 210 gekoppelt, der die ein oder mehreren integrierten Speichercontroller 214 einschließt. In einigen Ausführungsformen enthält der Systemdienstkern 210 auch einen Anzeige-Controller 211, um die Grafikprozessorausgabe zu ein oder mehreren gekoppelten Displays anzutreiben. In einigen Ausführungsformen kann der Anzeige-Controller 211 auch ein getrenntes Modul sein, das über mindestens einen Interconnect mit dem Grafikprozessor gekoppelt ist, oder er kann in dem Grafikprozessor 208 integriert sein.
In einigen Ausführungsformen wird eine ringbasierte Interconnect-Einheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch auch eine alternative Interconnect-Einheit, wie z. B. ein Punkt-zu-Punkt-Interconnect, ein geschalteter Interconnect, oder andere Techniken, einschließlich im Stand der Technik wohlbekannte Techniken, verwendet werden. In einigen Ausführungsformen ist der Grafikprozessor 208 über eine E/A-Verbindung 213 mit dem Ring-Interconnect 212 gekoppelt.
Die beispielhafte E/A-Verbindung 213 repräsentiert mindestens eine von mehreren Varianten von E/A-Interconnects, einschließlich eines On-Package-E/A-Interconnects, der Kommunikation zwischen verschiedenen Prozessorkomponenten und einem integrierten Hochleistungs-Speichermodul 218, wie z. B. einem eDRAM-Modul, unterstützt. In einigen Ausführungsformen verwendet jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 integrierte Speichermodule 218 als einen gemeinsam genutzten Last Level Cache.
In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, welche die gleiche Befehlssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A-202N heterogen in Bezug auf die Befehlssatzarchitektur (ISA), wobei ein oder mehrere Prozessorkerne 202A-202N einen ersten Befehlssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Befehlssatzes oder einen unterschiedlichen Befehlssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N heterogen in Bezug auf die Mikroarchitektur, wobei ein oder mehrere Kerne, die einen relativ hohen Stromverbrauch haben, mit ein oder mehreren Energiekernen gekoppelt sind, die einen geringeren Stromverbrauch haben. Außerdem kann der Prozessor 200 auf ein oder mehreren Chips oder als integrierte SoC-Schaltung implementiert werden, welche die dargestellten Komponenten zusätzlich zu anderen Komponenten aufweist.
3 ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit oder ein mit einer Vielzahl von Prozessorkernen integrierter Grafikprozessor sein kann. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine im Speicher abgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die in den Prozessorspeicher platziert werden. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Speicherschnittstelle 314 für den Zugriff auf den Speicher. Die Speicherschnittstelle 314 kann eine Schnittstelle zu einem lokalen Speicher, ein oder mehreren internen Caches, ein oder mehreren gemeinsam genutzten externen Caches und/oder zum Systemspeicher sein.
In einigen Ausführungsformen enthält der Grafikprozessor 300 auch einen Anzeige-Controller 302, um die Anzeige-Ausgangsdaten zu einer Anzeigevorrichtung 320 anzusteuern. Der Anzeige-Controller 302 enthält Hardware für ein oder mehrere Overlay-Ebenen für das Display und die Komposition von mehreren Schichten von Video- oder Benutzerschnittstellenelementen. Die Anzeigevorrichtung 320 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 320 eine am Kopf montierte Anzeigevorrichtung, wie z. B. eine Virtual Reality (VR)-Anzeigevorrichtung oder eine Augmented Reality (AR)-Anzeigevorrichtung. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Videocodec-Engine 306, um Medien zu, von oder zwischen ein oder mehreren Mediencodierungsformaten zu codieren, decodieren oder transcodieren, einschließlich, aber nicht beschränkt auf Moving Picture Experts Group (MPEG)-Formate, wie z. B. MPEG-2, Advanced Video Coding (AVC)-Formate, wie z. B. H.264/MPEG-4 AVC, sowie Formate der Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und der Joint Photographic Experts Group (JPEG), wie z. B. JPEG, und Motion JPEG (MJPEG)-Formate.
In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Block Image Transfer (BLIT)-Engine 304, um zweidimensionale (2D) Rasterizer-Operationen, einschließlich z. B. Bit-Boundary Block-Transfers, durchzuführen. In einer Ausführungsform werden jedoch 2D-Grafikoperationen unter Verwendung von ein oder mehreren Komponenten der Grafikverarbeitungs-Engine (GPE) 310 durchgeführt. In einigen Ausführungsformen ist GPE 310 eine Compute-Engine zur Durchführung von Grafikoperationen, einschließlich dreidimensionaler (3D) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen enthält die GPE 310 eine 3D-Pipeline 312 zur Durchführung von 3D-Operationen, wie z. B. Rendering von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Grundkörperformen (z. B. Rechteck, Dreieck usw.) reagieren. Die 3D-Pipeline 312 enthält programmierbare und Festfunktionselemente, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungsthreads zu einem 3D/Medien-Untersystem 315 hervorbringen. Während die 3D-Pipeline 312 zur Durchführung von Medienoperationen verwendet werden kann, enthält eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316, die speziell verwendet wird, um Medienoperationen, wie z. B. Video-Nachverarbeitung und Bildverbesserung, durchzuführen.
In einigen Ausführungsformen enthält die Medien-Pipeline 316 Festfunktions- oder programmierbare Logikeinheiten, um ein oder mehrere spezialisierte Medienoperationen, wie z. B. Videodecodierungsbeschleunigung, Video-De-Interlacing und Videocodierungsbeschleunigung, anstelle der oder zugunsten der Videocodec-Engine 306 durchzuführen. In einigen Ausführungsformen enthält die Medien-Pipeline 316 zusätzlich eine Thread-Hervorbringungseinheit, um Threads zur Ausführung auf dem 3D/Medien-Untersystem 315 hervorzubringen. Die hervorgebrachten Threads führen Berechnungen für die Medienoperationen auf ein oder mehreren Grafikausführungseinheiten durch, die in dem 3D/Medien-Untersystem 315 enthalten sind.
In einigen Ausführungsformen enthält das 3D/Medien-Untersystem 315 Logik zum Ausführen von Threads, die durch die 3D-Pipeline 312 und die Medien-Pipeline 316 hervorgebracht wurden. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanforderungen an das 3D/Medien-Untersystem 315, das Thread-Versendungslogik zum Arbitrieren und Entsenden der verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen enthält. Die Ausführungsressourcen schließen ein Array von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medienthreads ein. In einigen Ausführungsformen enthält das 3D/Medien-Untersystem 315 ein oder mehrere interne Caches für Threadbefehle und Daten. In einigen Ausführungsformen enthält das Untersystem auch gemeinsam genutzten Speicher, einschließlich Registern und adressierbarem Speicher, um Daten zwischen Threads zu teilen und Ausgabedaten zu speichern.
Grafikverarbeitungs-Engine
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors im Einklang mit einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungs-Engine (GPE) 410 eine Version der in 3 gezeigten GPE 310. Elemente von 4, welche die gleichen Bezugsnummern (oder Namen) wie die Elemente einer anderen hierin enthaltenen Figur haben, können in jeder Weise ähnlich den woanders hierin beschriebenen Elementen arbeiten oder funktionieren, sind aber nicht auf solche beschränkt. Zum Beispiel werden die 3D-Pipeline 312 und die Medien-Pipeline 316 von 3 dargestellt. Die Medien-Pipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und ist möglicherweise nicht unbedingt in der GPE 410 enthalten. Zum Beispiel, und in mindestens einer Ausführungsform, ist ein getrenntes Medium und/oder ein Bildprozessor mit der GPE 410 gekoppelt.
In einigen Ausführungsformen koppelt die GPE 410 mit oder enthält einen Befehlsstreamer 403, der einen Befehlsstrom zu der 3D-Pipeline 312 und/oder den Medien-Pipelines 316 bereitstellt. In einigen Ausführungsformen ist der Befehlsstreamer 403 mit dem Speicher gekoppelt, der Systemspeicher oder einen oder mehrere des internen Cache-Speichers und gemeinsam genutzten Cache-Speichers sein kann. In einigen Ausführungsformen empfängt der Befehlsstreamer 403 Befehle von dem Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medien-Pipeline 316. Die Befehle sind von einem Ringpuffer abgerufene Richtlinien, der Befehle für die 3D-Pipeline 312 und die Medien-Pipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Stapelbefehlspuffer enthalten, die Stapel von mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Referenzen zu im Speicher abgelegten Daten enthalten, wie z. B., aber nicht beschränkt auf, Scheitelpunkt- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 312 und Medien-Pipeline 316 verarbeiten die Befehle und Daten, indem sie Operationen über Logik innerhalb der jeweiligen Pipelines durchführen oder ein oder mehrere Ausführungsthreads zu einem Grafikkernarray 414 entsenden. In einer Ausführungsform enthält das Grafikkernarray 414 ein oder mehrere Blöcke von Grafikkernen (z. B. Grafikkern(e) 415A, Grafikkern(e) 415B), wobei jeder Block ein oder mehrere Grafikkerne enthält. Jeder Grafikkern enthält einen Satz von Grafikausführungsressourcen, der Allzweck- und grafikspezifische Ausführungslogik enthält, um Grafik- und Rechenoperationen durchzuführen, sowie Festfunktions-Texturverarbeitung und/oder Maschinenlern- und Beschleunigungslogik von künstlicher Intelligenz.
In verschiedenen Ausführungsformen enthält die 3D-Pipeline 312 Festfunktions- und programmierbare Logik, um ein oder mehrere Shaderprogramme, wie z. B. Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Compute-Shader oder andere Shaderprogramme zu verarbeiten, und zwar durch Verarbeiten der Befehle und Entsenden von Ausführungsthreads zu dem Grafikkernarray 414. Das Grafikkernarray 414 liefert einen vereinheitlichten Block von Ausführungsressourcen zum Gebrauch bei der Verarbeitung dieser Shaderprogramme. Mehrzweck-Ausführungslogik (z. B. Ausführungseinheiten) innerhalb des (der) Grafikkern(e) 415A-414B des Grafikkernarrays 414 schließt Unterstützung für verschiedene 3D API-Shadersprachen ein und kann mit mehreren Shadern verbundene mehrfache gleichzeitige Ausführungsthreads ausführen.
In einigen Ausführungsformen enthält das Grafikkernarray 414 auch Ausführungslogik, um Medienfunktionen, wie z. B. Video- und/oder Bildverarbeitung durchzuführen. In einer Ausführungsform enthalten die Ausführungseinheiten zusätzlich Allzwecklogik, die programmierbar ist, um parallele Allzweck-Rechenoperationen zusätzlich zu Grafikverarbeitungsoperationen durchzuführen.
Die Allzwecklogik kann Verarbeitungsoperationen parallel oder in Verbindung mit Allzwecklogik innerhalb des (der) Prozessorkern(e) 107 von 1 oder der Kerne 202A-202N wie in 2 durchführen.
Ausgabedaten, die von auf dem Grafikkernarray 414 ausgeführte Threads erzeugt werden, können Daten an den Speicher in einem Unified Return Buffer (URB) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 auch verwendet werden, um Daten zwischen unterschiedlichen Threads zu senden, die auf dem Grafikkernarray 414 ausgeführt werden. In einigen Ausführungsformen kann der URB 418 zusätzlich für Synchronisierung zwischen Threads auf dem Grafikkernarray und Festfunktionslogik innerhalb der gemeinsamen Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist das Grafikkernarray 414 skalierbar, so dass das Array eine veränderliche Anzahl von Grafikkernen aufweist, die jeweils eine veränderliche Anzahl von Ausführungseinheiten auf der Basis der Soll-Leistung und des Leistungsniveaus der GPE 410 aufweisen: In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, so dass Ausführungsressourcen nach Bedarf aktiviert oder deaktiviert werden können.
Das Grafikkernarray 414 koppelt mit der gemeinsamen Funktionslogik 420, die mehrere Ressourcen umfasst, die zwischen den Grafikkernen in dem Grafikkernarray geteilt werden. Die gemeinsamen Funktionen innerhalb der gemeinsamen Funktionslogik 420 sind Hardware-Logikeinheiten, die spezialisierte ergänzende Funktionalität für das Grafikkernarray 414 bereitstellen. In verschiedenen Ausführungsformen schließt die gemeinsame Funktionslogik 420 Logik für Sampler 421, Math 422 und Inter-Thread-Kommunikation (ITC) 423 ein, ist aber nicht darauf beschränkt. Außerdem implementieren einige Ausführungsformen einen oder mehrere Cache(s) 425 innerhalb der gemeinsamen Funktionslogik 420.
Eine gemeinsame Funktion wird implementiert, wenn der Bedarf an einer gegebenen spezialisierten Funktion unzureichend für Einbeziehung in das Grafikkernarray 414 ist. Statt dessen wird eine einzige Instanziierung dieser spezialisierten Funktion als unabhängige Einheit in der gemeinsamen Funktionslogik 420 implementiert und unter den Ausführungsressourcen innerhalb des Grafikkernarrays 414 geteilt. Der genaue Satz von Funktionen, die zwischen dem Grafikkernarray 414 geteilt werden und in dem Grafikkernarray 414 enthalten sind, ist je nach Ausführungsform unterschiedlich. In einigen Ausführungsformen können spezifische gemeinsame Funktionen innerhalb der gemeinsamen Funktionslogik 420, die von dem Grafikkernarray 414 häufig verwendet werden, in der gemeinsamen Funktionslogik 416 innerhalb des Grafikkernarrays 414 enthalten sein. In verschiedenen Ausführungsformen kann die gemeinsame Funktionslogik 416 innerhalb des Grafikkernarrays 414 einige oder alle Logik innerhalb der gemeinsamen Funktionslogik 420 enthalten. In einer Ausführungsform können alle Logikelemente innerhalb der gemeinsamen Funktionslogik 420 innerhalb der gemeinsamen Funktionslogik 416 des Grafikkernarrays 414 dupliziert werden. In einer Ausführungsform wird die gemeinsame Funktionslogik 420 zugunsten der gemeinsamen Funktionslogik 416 innerhalb des Grafikkernarrays 414 ausgeschlossen.
5 ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns 500 gemäß einigen hierin beschriebenen Ausführungsformen. Elemente von 5, welche die gleichen Bezugsnummern (oder Namen) wie die Elemente einer anderen hierin enthaltenen Figur haben, können in jeder Weise ähnlich den woanders hierin beschriebenen Elementen arbeiten oder funktionieren, sind aber nicht auf solche beschränkt. Der dargestellte Grafikprozessorkern 500 ist in einigen Ausführungsformen innerhalb des Grafikkernarrays 414 von 4 enthalten. Der Grafikprozessorkern 500, der manchmal auch als Kernscheibe bezeichnet wird, kann ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 500 ist beispielhaft für eine Grafikkernscheibe, und ein Grafikprozessor, wie hierin beschrieben, kann mehrere Grafikkernscheiben auf der Basis von Soll-Leistung und Leistungshüllen enthalten. Jeder Grafikkern 500 kann einen Festfunktionsblock 530 enthalten, der mit mehreren Teilkernen 501A-501F, auch als Teilscheiben bezeichnet, gekoppelt ist, die modulare Blöcke von Allzweck- und Festfunktionslogik enthalten.
In einigen Ausführungsformen enthält der Festfunktionsblock 530 eine Geometrie/Festfunktions-Pipeline 536, die von allen Teilkernen in dem Grafikprozessor 500 gemeinsam genutzt werden können, zum Beispiel in Implementierungen von geringerer Leistung und/oder niedrigerer Grafikprozessorleistung. In verschiedenen Ausführungsformen enthält die Geometrie/Festfunktions-Pipeline 536 eine 3D-Festfunktions-Pipeline (z. B. 3D-Pipeline 312, wie in 3 und 4), eine Video-Front-End-Einheit, einen Thread-Spawner und Thread-Dispatcher sowie einen vereinheitlichten Rückgabepuffermanager, der vereinheitlichte Rückgabepuffer verwaltet, wie z. B. den vereinheitlichten Rückgabepuffer 418 von 4.
In einer Ausführungsform enthält der Festfunktionsblock 530 auch eine Grafik-SoC-Schnittstelle 537, einen Grafik-Mikrocontroller 538 und eine Medien-Pipeline 539. Die Grafik-SoC-Schnittstelle 537 stellt eine Schnittstelle zwischen dem Grafikkern 500 und anderen Prozessorkernen innerhalb einer integrierten Ein-Chip-System-Schaltung bereit. Der Grafik-Mikrocontroller 538 ist ein programmierbarer Subprozessor, der konfigurierbar ist, um verschiedene Funktionen des Grafikprozessors 500, einschließlich Thread-Dispatch, Planung und Vorwegnahme, zu verwalten. Die Medien-Pipeline 539 (z. B. Medien-Pipeline 316 von 3 und 4) enthält Logik, um Decodierung, Codierung, Vorverarbeitung und/oder Nachverarbeitung von Multimediadaten, einschließlich Bild- und Videodaten, zu unterstützen. Die Medien-Pipeline 539 implementiert Medienoperationen über Anforderungen an die Rechen- oder Sampling-Logik innerhalb der Teilkerne 501-501F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 dem Grafikkern 500, mit den Allzweck-Anwendungsprozessorkernen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC, einschließlich Speicherhierarchieelementen, wie z. B. einem gemeinsamen Last-Level-Cache-Speicher, dem System-RAM und/oder integriertem On-Chip- oder On-Package-DRAM, zu kommunizieren. Die SoC-Schnittstelle 537 kann auch Kommunikation mit Festfunktionsvorrichtungen innerhalb des SoC, wie z. B. Kamerabild-Pipelines, ermöglichen, und ermöglicht den Einsatz von und/oder implementiert Global Memory Atomics, die zwischen dem Grafikkern 500 und CPUs innerhalb des SoC geteilt werden können. Die SoC-Schnittstelle 537 kann auch Energieverwaltungskontrollen für den Grafikkern 500 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 500 und anderen Taktdomänen innerhalb des SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 den Empfang von Befehlspuffern von einem Befehlsstreamer und einem globalen Thread-Dispatcher, die dazu ausgebildet sind, Befehle und Anweisungen zu jedem der ein oder mehreren Grafikkerne innerhalb eines Grafikprozessors zu liefern. Die Befehle und Anweisungen können zu der Medien-Pipeline 539 entsendet werden, wenn Medienoperationen durchzuführen sind, oder zu einer Geometrie- und Festfunktions-Pipeline (z. B. der Geometrie- und Festfunktions-Pipeline 536, der Geometrie- und Festfunktions-Pipeline 514), wenn Grafikverarbeitungsoperationen durchzuführen sind.
Der Grafik-Mikrocontroller 538 kann dazu ausgebildet sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikkern 500 durchzuführen. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 Grafik- und/oder Rechenarbeitslastplanung an den verschiedenen parallelen Grafik-Engines innerhalb der Ausführungseinheit (AE)-Arrays 502A-502F, 504A-504F innerhalb der Teilkerne 501A-501F durchführen. In diesem Planungsmodell kann Hostsoftware, die auf einem CPU-Kern eines den Grafikkern 500 enthaltenden SoC ausgeführt wird, Arbeitslasten von einer von mehreren Grafikprozessor-Türklingeln übermitteln, wodurch eine Planungsoperation an der entsprechenden Grafik-Engine aufgerufen wird. Planungsoperationen umfassen das Bestimmen, welche Arbeitslast als Nächstes auszuführen ist, Übermitteln einer Arbeitslast zu einem Befehlsstreamer, Vorwegnehmen existierender Arbeitslasten, die auf einer Engine ausgeführt werden, Überwachen des Fortschritts einer Arbeitslast, und Benachrichtigen der Hostsoftware, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 auch Energiespar- oder Ruhezustände für den Grafikkern 500 unterstützen, indem er dem Grafikkern 500 die Fähigkeit verleiht, Register innerhalb des Grafikkerns 500 über Energiesparzustandsübergänge unabhängig von dem Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
Der Grafikkern 500 kann mehr oder weniger als die dargestellten Teilkerne 501A-501F, bis zu N modularen Teilkernen, aufweisen. Für jeden Satz von N Teilkernen kann der Grafikkern 500 auch eine gemeinsame Funktionslogik 510, einen gemeinsam genutzten und/oder Cache-Speicher 512, eine Geometrie/Festfunktions-Pipeline 514 sowie zusätzliche Festfunktionslogik 516 enthalten, um verschiedene Grafik- und Datenverarbeitungsoperationen zu beschleunigen. Die gemeinsame Funktionslogik 510 kann mit der gemeinsamen Funktionslogik 420 von 4 verbundene Logikeinheiten (z. B. Sampler-, Math- und/oder Inter-Thread-Kommunikationslogik) enthalten, die von allen N Teilkernen innerhalb des Grafikkerns 500 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 512 kann ein Last-Level-Cache für den Satz von N Teilkernen 501A-501F innerhalb des Grafikkerns 500 sein, und kann auch als gemeinsam genutzter Speicher dienen, der von mehreren Teilkernen zugänglich ist. Die Geometrie/Festfunktions-Pipeline 514 kann anstelle der Geometrie/Festfunktions-Pipeline 536 innerhalb des Festfunktionsblocks 530 enthalten sein, und kann die gleichen oder ähnliche Logikeinheiten aufweisen.
In einer Ausführungsform enthält der Grafikkern 500 zusätzliche Festfunktionslogik 516, die verschiedene Festfunktions-Beschleunigungslogiken zur Verwendung durch den Grafikkern 500 enthalten kann.
In einer Ausführungsform enthält die zusätzliche Festfunktionslogik 516 eine zusätzliche Geometrie-Pipeline für Position-only-Shading. In Position-only-Shading existieren zwei Geometrie-Pipelines, die volle Geometrie-Pipeline innerhalb der Geometrie/Festfunktions-Pipeline 516, 536, und eine Cull-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Festfunktionslogik 516 enthalten sein kann. In einer Ausführungsform ist die Cull-Pipeline eine abgespeckte Version der vollen Geometrie-Pipeline. Die volle Pipeline und die Cull-Pipeline können unterschiedliche Instanzen derselben Anwendung ausführen, wobei jede Instanz einen getrennten Kontext hat. Position-only-Shading kann lange Cull-Läufe von verworfenen Dreiecken verbergen, wodurch es in manchen Fällen möglich ist, Shading früher zu vollenden. Zum Beispiel und in einer Ausführungsform kann die Cull-Pipeline-Logik innerhalb der zusätzlichen Festfunktionslogik 516 Position-Shader parallel zu der Hauptanwendung ausführen und erzeugt im Allgemeinen kritische Resultate schneller als die volle Pipeline, da die volle Pipeline nur das Positionsattribut der Vertices abruft und schattiert, ohne Rasterisierung und Rendering der Pixel am Bildspeicher durchzuführen. Die Cull-Pipeline kann die erzeugten kritischen Resultate verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, ohne Rücksicht darauf, ob diese Dreiecke ausgesondert werden. Die volle Pipeline (die in diesem Fall als Replay-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen konsumieren, um die ausgesonderten Dreiecke zu überspringen und nur die sichtbaren Dreiecke zu schattieren, die letztendlich zu der Rasterisierungsphase geleitet werden.
In einer Ausführungsform kann die zusätzliche Festfunktionslogik 516 auch Maschinenlern-Beschleunigungslogik, wie z. B. Festfunktions-Matrixmultiplikationslogik, für Implementierungen einschließlich Optimierungen für Maschinenlerntraining oder Ableiten enthalten.
In jedem Grafik-Teilkern 501A-501F ist ein Satz von Ausführungsressourcen enthalten, der verwendet werden kann, um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen von der Grafik-Pipeline, der Medien-Pipeline oder von Shaderprogrammen durchzuführen. Die Grafik-Teilkerne 501A-501F schließen mehrere AE-Arrays 502A-502F, 504A-504F, Thread-Dispatch- und Inter-Thread-Kommunikationslogik (TD/IC) 503A-503F, einen 3D-Sampler (z. B. Textur) 505A-505F, einen Mediensampler 506A-506F, einen Shaderprozessor 507A-507F und Shared Local Memory (SLM) 508A-508F ein. Die AE-Arrays 502A-502F, 504A-504F enthalten jeweils mehrere Ausführungseinheiten, bei denen es sich um Allzweck-Grafikverarbeitungseinheiten handelt, die in der Lage sind, Gleitkomma- und Ganzzahl/Festpunkt-Logikoperationen im Dienste einer Grafik-, Medien- oder Rechenoperation, einschließlich Grafik-, Medien- oder Compute-Shaderprogrammen, durchzuführen. Die TD/IC-Logik 503A-503F führt lokale Thread-Dispatch- und Thread-Control-Operationen für die Ausführungseinheiten innerhalb eines Teilkerns durch und unterstützt Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Teilkerns ausgeführt werden. Der 3D-Sampler 505A-505F kann auf Textur oder andere 3D-Grafik bezogene Daten in den Speicher einlesen. Der 3D-Sampler kann Texturdaten auf der Basis eines konfigurierten Abtastzustands und des mit einer gegebenen Textur verbundenen Texturformats unterschiedlich lesen. Der Mediensampler 506A-506F kann ähnliche Lesevorgänge auf der Basis des mit den Mediendaten verbundenen Typs und Formats durchführen. In einer Ausführungsform kann jeder Grafik-Teilkern 501A-501F abwechselnd einen vereinheitlichten 3D-Sampler und einen Mediensampler enthalten. Threads, die auf den Ausführungseinheiten innerhalb jedes der Teilkerne 501A-501F ausgeführt werden, können den gemeinsamen lokalen Speicher 508A-508F innerhalb jedes Teilkerns nutzen, um zu ermöglichen, dass Threads, die innerhalb einer Threadgruppe ausgeführt werden, unter Verwendung eines gemeinsamen Pools von On-Chip-Speicher ausgeführt werden.
Ausführungseinheiten
6A-6B stellen eine Thread-Ausführungslogik 600 dar, die ein Array von Verarbeitungselementen einschließt, die gemäß hierin beschriebenen Ausführungsformen in einem Grafikprozessorkern eingesetzt werden.
Elemente der 6A-6B, welche die gleichen Bezugsnummern (oder Namen) wie die Elemente einer anderen hierin enthaltenen Figur haben, können in jeder Weise ähnlich den woanders hierin beschriebenen Elementen arbeiten oder funktionieren, sind aber nicht auf solche beschränkt. 6A stellt eine Übersicht der Thread-Ausführungslogik 600 dar, die eine Variante der Hardwarelogik enthalten kann, die mit jedem Teilkern 501A-501F von 5 dargestellt ist. 6B stellt beispielhafte interne Details einer Ausführungseinheit dar.
6A-6B stellen eine Thread-Ausführungslogik 600 dar, die ein Array von Verarbeitungselementen einschließt, die gemäß hierin beschriebenen Ausführungsformen in einem Grafikprozessorkern eingesetzt werden.
Elemente der 6A-6B, welche die gleichen Bezugsnummern (oder Namen) wie die Elemente einer anderen hierin enthaltenen Figur haben, können in jeder Weise ähnlich den woanders hierin beschriebenen Elementen arbeiten oder funktionieren, sind aber nicht auf solche beschränkt. 6A stellt eine Übersicht der Thread-Ausführungslogik 600 dar, die eine Variante der Hardwarelogik enthalten kann, die mit jedem Teilkern 501A-501F von 5 dargestellt ist. 6B stellt beispielhafte interne Details einer Ausführungseinheit dar.
Wie in 6A dargestellt, enthält die Thread-Ausführungslogik 600 in einigen Ausführungsformen einen Shaderprozessor 602, einen Thread-Dispatcher 604, Befehlscache 606 und ein skalierbares Ausführungseinheitsarray, das eine Vielzahl von Ausführungseinheiten 608A-608N, einen Sampler 610, einen Datencache 612 und einen Datenport 614 enthält. In einer Ausführungsform kann das skalierbare Ausführungseinheitsarray dynamisch skalieren, indem es ein oder mehrere Ausführungseinheiten (z. B. eine der Ausführungseinheiten 608A, 608B, 608C, 608D bis 608N-1 und 608N) auf der Basis der Rechenanforderungen einer Arbeitslast aktiviert oder deaktiviert. In einer Ausführungsform sind die enthaltenen Komponenten über ein Interconnect-Netzwerk verbunden, das alle Komponenten miteinander verbindet. In einigen Ausführungsformen weist die Thread-Ausführungslogik 600 ein oder mehrere Verbindungen mit dem Speicher auf, wie z. B. einem Systemspeicher oder Cache-Speicher, durch ein oder mehrere von Befehlscache 606, Datenport 614, Sampler 610 und Ausführungseinheiten 608A-608N. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 608A) eine unabhängige programmierbare Allzweck-Recheneinheit, die in der Lage ist, mehrere simultane Hardware-Threads auszuführen, während sie parallel mehrere Datenelemente für jeden Thread verarbeitet. In verschiedenen Ausführungsformen ist das Array von Ausführungseinheiten 608A-608N skalierbar, um eine beliebige Anzahl von individuellen Ausführungseinheiten einzuschließen.
In einigen Ausführungsformen werden die Ausführungseinheiten 608A-608N hauptsächlich verwendet, um Shaderprogramme auszuführen. Ein Shaderprozessor 602 kann die verschiedenen Shaderprogramme verarbeiten und mit den Shaderprogrammen verbundenen Ausführungsthreads über einen Thread-Dispatcher 604 versenden. In einer Ausführungsform enthält der Thread-Dispatcher Logik, um Thread-Initiierungsanforderungen von den Grafik- und Medien-Pipelines zu vermitteln und die angeforderten Threads auf ein oder mehreren Ausführungseinheiten der Ausführungseinheiten 608A-608N zu instanziieren. Zum Beispiel kann eine Geometrie-Pipeline Vertex-, Tessellations- oder Geometrie-Shader zur Verarbeitung an die Thread-Ausführungslogik entsenden. In einigen Ausführungsformen kann der Thread-Dispatcher 604 auch Runtime-Thread-Hervorbringungsanforderungen von den laufenden Shaderprogrammen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N einen Befehlssatz, der native Unterstützung für viele standardmäßige 3D-Grafik-Shaderbefehle einschließt, so dass Shaderprogramme von Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit minimaler Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertex-Programme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z. B. Pixel-Shader, Fragment-Shader) und Allzweckverarbeitung (z. B. Rechen- und Medien-Shader). Jede der Ausführungseinheiten 608A-608N ist zur Ausführung von mehrteiligen Single Instruction Multiple Data (SIMD) fähig, und Multithread-Betrieb ermöglicht eine effiziente Ausführungsumgebung angesichts Speicherzugriffen von höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit hat eine dedizierte Registerdatei von hoher Bandbreite und einen zugehörigen unabhängigen Thread-Zustand. Die Ausführung erfolgt mehrteilig per Taktgeber an Pipelines, die zu Ganzzahl-, Gleitkommaoperationen von einfacher und doppelter Präzision, SIMD-Verzweigungsfähigkeit, logischen Operationen, transzendentalen Operationen und anderen verschiedenen Operationen fähig sind. Während auf Daten vom Speicher oder eine der gemeinsamen Funktionen gewartet wird, veranlasst Abhängigkeitslogik innerhalb der Ausführungseinheiten 608A-608N einen wartenden Thread zu schlafen, bis die angeforderten Daten zurückgegeben worden sind. Während der wartende Thread schläft, können Hardware-Ressourcen zum Verarbeiten anderer Threads eingesetzt werden. Zum Beispiel kann eine Ausführungseinheit während einer durch eine Vertex-Shaderoperation bedingte Verzögerung Operationen für einen Pixel-Shader, Fragment-Shader oder eine andere Art von Shaderprogramm, das einen anderen Vertex-Shader enthält, durchführen.
Jede Ausführungseinheit in den Ausführungseinheiten 608A-608N arbeitet an Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ bzw. die Anzahl von Kanälen für den Befehl. Ein Ausführungskanal ist eine logische Einheit der Ausführung für Datenelementzugriff, Maskierung und Ablaufsteuerung innerhalb von Befehlen. Die Anzahl von Kanälen kann unabhängig von der Anzahl von physischen Arithmetic Logic Units (ALUs) oder Floating Point Units (FPUs) für einen bestimmten Grafikprozessor sein. In einigen Ausführungsformen unterstützen Ausführungseinheiten 608A-608N Ganzzahl- und Gleitkomma-Datentypen.
Der Ausführungseinheits-Befehlssatz enthält SIMD-Befehle. Die verschiedenen Datenelemente können als gepackter Datentyp in einem Register gespeichert werden, und die Ausführungseinheit verarbeitet die verschiedenen Elemente auf der Basis der Datengröße der Elemente. Zum Beispiel, wenn an einem 256 Bit breiten Vektor gearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert, und die Ausführungseinheit arbeitet an dem Vektor als vier getrennte 64-Bit-gepackte Datenelemente (Datenelemente von Quad-Word (QW)-Größe), acht getrennte 32-Bit-gepackte Datenelemente (Datenelemente von Double Word (DW)-Größe), sechzehn getrennte 16-Bit-gepackte Datenelemente (Datenelemente von Word (W)-Größe) oder zweiunddreißig getrennte 8-Bit-Datenelemente (Datenelemente von Byte (B)-Größe). Es sind jedoch unterschiedliche Vektorbreiten und Registergrößen möglich.
In einer Ausführungsform können ein oder mehrere Ausführungseinheiten zu einer verschmolzenen Ausführungseinheit 609A-609N kombiniert werden, die eine Thread-Steuerlogik (607A-607N) aufweist, die den verschmolzenen AEs gemeinsam ist. Mehrere AEs können zu einer AE-Gruppe verschmolzen werden. Jede AE in der verschmolzenen AE-Gruppe kann dazu ausgebildet sein, einen getrennten SIMD-Hardware-Thread auszuführen. Die Anzahl von AEs in einer verschmolzenen AE-Gruppe kann gemäß den Ausführungsformen variieren. Außerdem können verschiedene SIMD-Breiten pro AE durchgeführt werden, einschließlich, aber nicht beschränkt auf, SIMD8, SIMD16 und SIMD32. Jede verschmolzene Grafikausführungseinheit 609A-609N enthält mindestens zwei Ausführungseinheiten. Zum Beispiel enthält die verschmolzene Ausführungseinheit 609A eine erste AE 608A, eine zweite AE 608B und eine Thread-Steuerlogik 607A, die der ersten AE 608A und der zweiten AE 608B gemeinsam ist. Die Thread-Steuerlogik 607A steuert die auf der verschmolzenen Grafikausführungseinheit 609A ausgeführten Threads, so dass jede AE in den verschmolzenen Ausführungseinheiten 609A-609N in der Lage ist, unter Verwendung eines gemeinsamen Befehlszeigerregisters auszuführen.
Ein oder mehrere interne Befehlscaches (z. B. 606) sind in der Thread-Ausführungslogik 600 enthalten, um Threadbefehle für die Ausführungseinheiten zu cachen. In einigen Ausführungsformen sind ein oder mehrere Datencaches (z. B. 612) enthalten, um Threaddaten während der Threadausführung zu cachen. In einigen Ausführungsformen ist ein Sampler 610 enthalten, um Textursampling für 3D-Operationen und Mediensampling für Medienoperationen bereitzustellen. In einigen Ausführungsformen enthält der Sampler 610 spezialisierte Textur- oder Mediensamplingfunktionen, um Textur- oder Mediendaten während des Samplingprozesses zu verarbeiten, bevor die gesampelten Daten einer Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und Medien-Pipelines Thread-Initiierungsanforderungen an die Thread-Ausführungslogik 600 über Thread-Hervorbringungs- und Versendungslogik. Nachdem eine Gruppe von geometrischen Objekten zu Pixeldaten verarbeitet und rasterisiert worden ist, wird die Pixelprozessorlogik (z. B. Pixel-Shaderlogik, Fragment-Shaderlogik usw.) innerhalb des Shaderprozessors 602 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu veranlassen, dass Resultate auf Ausgabeflächen (z. B. Farbpuffer, Tiefenpuffer, Stencilpuffer usw.) geschrieben werden. In einigen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertexattribute, die zu interpolieren sind, über das rasterisierte Objekt.
In einigen Ausführungsformen führt die Pixelprozessorlogik innerhalb des Shaderprozessors 602 dann ein von einer Anwendungsprogrammierschnittstelle (API) geliefertes Pixel- oder Fragment-Shaderprogramm aus. Um das Shaderprogramm auszuführen, versendet der Shaderprozessor 602 Threads über den Thread-Dispatcher 604 zu einer Ausführungseinheit (z. B. 608A). In einigen Ausführungsformen verwendet der Shaderprozessor 602 Texturabtastlogik in dem Sampler 610, um auf Texturdaten zuzugreifen, die in gespeicherten Texturabbildungen vorliegen. In Rechenoperationen an den Texturdaten und den eingegebenen Geometriedaten werden Pixelfarbdaten für jedes geometrische Fragment berechnet, oder es werden ein oder mehrere Pixel von weiterer Verarbeitung ausgeschlossen.
In einigen Ausführungsformen stellt der Datenport 614 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 600 bereit, um verarbeitete Daten für weitere Verarbeitung auf einer Grafikprozessor-Ausgabe-Pipeline auszugeben. In einigen Ausführungsformen enthält der Datenport 614 ein oder mehrere Cache-Speicher (z. B. Datencache 612), oder wird damit gekoppelt, um Daten für Speicherzugriff über den Datenport zu cachen.
Wie in 6B dargestellt, kann eine Grafikausführungseinheit 608 eine Befehlsabrufeinheit 637, ein allgemeines Registerdateiarray (GRF) 624, ein architektonisches Registerdateiarray (ARF) 626, einen Thread-Vermittler 622, eine Sendeeinheit 630, eine Verzweigungseinheit 632, einen Satz von SIMD-Gleitkommaeinheiten (FPUs) 634 und in einer Ausführungsform einen Satz von dedizierten Ganzzahl-SIMD ALUs 635 umfassen. Das GRF 624 und das ARF 626 enthalten den Satz von allgemeinen Registerdateien und architektonischen Registerdateien, die mit jedem simultanen Hardware-Thread verbunden sind, der in der Grafikausführungseinheit 608 aktiv sein kann.
In einer Ausführungsform wird pro Thread der architektonische Zustand in dem ARF 626 aufrechterhalten, während Daten, die während der Threadausführung verwendet werden, in dem GRF 624 gespeichert werden. Der Ausführungszustand jedes Threads, einschließlich der Befehlszeiger für jeden Thread, kann in Thread-spezifischen Registern in dem ARF 626 gehalten werden.
In einer Ausführungsform weist die Grafikausführungseinheit 608 eine Architektur auf, die eine Kombination von Simultaneous Multi-Threading (SMT) und feinkörnigem Interleaved Multi-Threading (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zur Designzeit auf der Basis einer Sollzahl von simultanen Threads und der Anzahl von Registern pro Ausführungseinheit fein abgestimmt werden kann, wobei Ausführungseinheitsressourcen über die Logik aufgeteilt werden, die verwendet wird, um mehrere simultane Threads auszuführen.
In einer Ausführungsform kann die Grafikausführungseinheit 608 mehrere Befehle zusammen ausgeben, die jeweils unterschiedliche Befehle sein können. Der Thread-Vermittler 622 des Threads der Grafikausführungseinheit 608 kann die Befehle zur Ausführung an eine Einheit der Sendeeinheit 630, der Verzweigungseinheit 642 oder der SIMD FPU(s) 634 entsenden. Jeder Ausführungsthread kann auf 128 Allzweckregister innerhalb des GRF 624 zugreifen, wobei jedes Register 32 Bytes speichern kann, die als SIMD 8-Element-Vektor von 32-Bit-Datenelementen zugänglich sind. In einer Ausführungsform hat jeder Ausführungseinheitsthread Zugriff auf 4 Kilobyte innerhalb des GRF 624, obwohl Ausführungsformen nicht derartig eingeschränkt sind, und mehr oder weniger Registerressourcen können in anderen Ausführungsformen bereitgestellt werden. In einer Ausführungsform können bis zu sieben Threads gleichzeitig ausgeführt werden, obwohl die Anzahl von Threads pro Ausführungseinheit gemäß den Ausführungsformen auch variieren kann. In einer Ausführungsform, in der sieben Threads auf 4 Kilobyte zugreifen können, kann das GRF 624 insgesamt 28 Kilobyte speichern. Flexible Adressiermodi können es gestatten, dass Register zusammen adressiert werden, um effektiv breitere Register aufzubauen, oder um streifenförmige rechteckige Blockdatenstrukturen zu repräsentieren.
In einer Ausführungsform werden Speicheroperationen, Sampleroperationen und andere Systemkommunikationsvorgänge von längerer Latenz über „Senden“-Befehle versendet, die durch die Nachrichtenübertragungs-Sendeeinheit 630 ausgeführt werden. In einer Ausführungsform werden Verzweigungsbefehle zu einer dedizierten Verzweigungseinheit 632 versendet, um SIMD-Divergenz und eventuelle Konvergenz zu unterstützen.
In einer Ausführungsform enthält die Grafikausführungseinheit 608 ein oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 634 zur Durchführung von Gleitkommaoperationen. In einer Ausführungsform unterstützen die FPU(s) 634 auch Ganzzahlberechnung. In einer Ausführungsform können die FPU(s) 634 bis zu M Zahlen von 32-Bit-Gleitkomma- (oder Ganzzahl-) Operationen SIMD-ausführen, oder bis zu 2Mvon 16-Bit-Ganzzahl- oder 16-Bit-Gleitkommaoperationen SIMD-ausführen. In einer Ausführungsform bietet mindestens eine der FPU(s) erweiterte Rechenfähigkeit, um transzendentale Rechenfunktionen von hohem Durchsatz und 64-Bit-Gleitkommafunktionen von doppelter Präzision zu unterstützen. In einigen Ausführungsformen ist ein Satz von 8-Bit-Ganzzahl-SIMD ALUs 635 ebenfalls vorhanden und kann speziell optimiert werden, um mit Maschinenlernberechnungen verbundene Operationen durchzuführen.
In einer Ausführungsform können Arrays von mehreren Instanzen der Grafikausführungseinheit 608 in einer Grafik-Teilkern-Gruppierung (z. B. einer Teilscheibe) instanziiert werden. Für Skalierbarkeit können Produktarchitekten die genaue Anzahl von Ausführungseinheiten pro Teilkerngruppierung wählen. In einer Ausführungsform kann die Ausführungseinheit 608 Befehle über eine Vielzahl von Ausführungskanälen ausführen. In einer weiteren Ausführungsform wird jeder auf der Grafikausführungseinheit 608 ausgeführte Thread auf einem anderen Kanal ausgeführt.
7 ist ein Blockdiagramm, das Grafikprozessor-Befehlsformate 700 gemäß einigen Ausführungsformen darstellt. In ein oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Befehlssatz, der Befehle in mehreren Formaten aufweist. Die Kästen mit durchgezogener Linie stellen die Komponenten dar, die im Allgemeinen in einem Ausführungseinheitsbefehl enthalten sind, während die Kästen mit gestrichelter Linie Komponenten enthalten, die optional oder nur in einem Teilsatz der Befehle enthalten sind. In einigen Ausführungsformen stellt das beschriebene und dargestellte Befehlsformat 700 Makrobefehle dar, insofern als sie Befehle sind, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die aus Befehlsdecodierung resultieren, nachdem der Befehl verarbeitet worden ist.
In einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten nativ Befehle in einem 128-Bit-Befehlsformat 710. Ein komprimiertes 64-Bit-Befehlsformat 730 ist für einige Befehle auf der Basis des ausgewählten Befehls, der Befehlsoptionen und der Anzahl von Operanden verfügbar. Das native 128-Bit-Befehlsformat 710 bietet Zugriff auf alle Befehlsoptionen, während einige Optionen und Operationen in dem 64-Bit-Format 730 eingeschränkt sind. Die in dem 64-Bit-Format 730 verfügbaren nativen Befehle variieren nach Ausführungsform. In einigen Ausführungsformen wird der Befehl unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 teilweise komprimiert. Die Ausführungseinheit-Hardware referenziert einen Satz von Komprimierungstabellen auf der Basis der Indexwerte und verwendet die Komprimierungstabellenausgaben, um einen nativen Befehl in dem 128-Bit-Befehlsformat 710 zu rekonstruieren.
Für jedes Format definiert der Befehls-Opcode 712 die Operation, die von der Ausführungseinheit auszuführen ist. Die Ausführungseinheiten führen jeden Befehl parallel über die mehreren Datenelemente jedes Operanden aus. Zum Beispiel führt die Ausführungseinheit als Reaktion auf einen Hinzufügungsbefehl eine simultane Hinzufügungsoperation über jeden Farbkanal, der ein Texturelement oder Bildelement repräsentiert, durch. Standardmäßig führt die Ausführungseinheit jeden Befehl über alle Datenkanäle der Operanden durch. In einigen Ausführungsformen ermöglicht das Befehlssteuerfeld 714 eine Kontrolle über bestimmte Ausführungsoptionen, wie z. B. Kanalwahl (z. B. Prädikation) und Datenkanalreihenfolge (z. B. Umstellmechanismus). Für Befehle in dem 128-Bit-Befehlsformat 710 begrenzt ein Exec-Größenfeld 716 die Anzahl von Datenkanälen, die parallel ausgeführt werden. In einigen Ausführungsformen ist das Exec-Größenfeld 716 nicht für die Verwendung in dem kompakten 64-Bit-Befehlsformat 730 verfügbar.
Einige Ausführungseinheitsbefehle haben bis zu drei Operanden, die zwei Quellenoperanden, src0 720, src1 722 und ein Ziel 718 enthalten. In einigen Ausführungsformen unterstützen die Ausführungseinheiten doppelte Zielbefehle, wobei eines der Ziele impliziert wird. Datenmanipulationsbefehle können einen dritten Quellenoperanden (z. B. SRC2 724) aufweisen, wobei der Befehls-Opcode 712 die Anzahl von Quellenoperanden bestimmt. Der letzte Quellenoperand eines Befehls kann ein unmittelbarer (z. B. hartcodierter) Wert sein, der mit dem Befehl weitergeleitet wird.
In einigen Ausführungsformen enthält das 128-Bit-Befehlsformat 710 ein Zugriffs-/Adressmodusfeld 726 das zum Beispiel angibt, ob der direkte Registeradressiermodus oder der indirekte Registeradressiermodus verwendet wird. Wenn der direkte Registeradressiermodus verwendet wird, wird die Registeradresse von ein oder mehreren Operanden direkt durch Bits in dem Befehl bereitgestellt.
In einigen Ausführungsformen enthält das 128-Bit-Befehlsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für den Befehl angibt. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für den Befehl zu definieren.
Einige Ausführungsformen unterstützen Zugriffsmodi, die einen 16-Byte-Ausrichtungs-Zugriffsmodus und einen 1-Byte-Ausrichtungs-Zugriffsmodus enthalten, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Befehlsoperanden bestimmt. Zum Beispiel kann der Befehl in einem ersten Modus Byte-ausgerichtete Adressierung für Quellen- und Zieloperanden verwenden, während der Befehl in einem zweiten Modus 16-Byte-ausgerichtete Adressierung für alle Quellen- und Zieloperanden verwenden kann.
In einer Ausführungsform bestimmt der Adressmodusteil des Zugriffs-/Adressmodusfelds 726, ob der Befehl direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressiermodus verwendet wird, liefern Bits in dem Befehl direkt die Registeradresse von ein oder mehreren Operanden. Wenn der indirekte Registeradressiermodus verwendet wird, kann die Registeradresse von ein oder mehreren Operanden auf der Basis eines Adressenregisterwertes und eines unmittelbaren Adressenfelds in dem Befehl berechnet werden.
In einigen Ausführungsformen werden Befehle auf der Basis von Bitfeldern des Opcodes 712 gruppiert, um die Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit-Opcode gestatten die Bits 4, 5 und 6 der Ausführungseinheit, die Art des Opcodes zu bestimmen. Die gezeigte präzise Opcodegruppierung ist lediglich ein Beispiel. In einigen Ausführungsformen enthält eine Bewegungs- und Logik-Opcodegruppe 742 Datenbewegungs- und Logikbefehle (z. B. Bewegen (mov), Vergleichen (cmp)). In einigen Ausführungsformen teilt die Bewegungs- und Logikgruppe 742 die fünf höchstwertigen Bits (MSB), wobei Bewegungs-(mov)-Befehle in der Form von 0000xxxxb vorliegen, und Logikbefehle in der Form von 0001xxxxb vorliegen. Eine Ablaufsteuerungs-Befehlsgruppe 744 (z. B. Aufruf, Sprung (jmp)) enthält Befehle in der Form von 0010xxxxb (z. B. 0x20). Eine Gruppe für verschiedene Befehle 746 enthält eine Mischung aus Befehlen, die Synchronisierungsbefehle (z. B. Warten, Senden) in der Form von 0011xxxxb (z. B. 0x30) enthalten. Eine parallele Rechenbefehlsgruppe 748 enthält komponentenweise Rechenbefehle (z. B. Addieren, Multiplizieren (mul)) in der Form von 0100xxxxb (z. B. 0x40). Die parallele Rechengruppe 748 führt die Rechenoperationen parallel über Datenkanäle durch. Die Vector Math-Gruppe 750 enthält Rechenbefehle (z. B. dp4) in der Form von 0101xxxxb (z. B. 0x50). Die Vector Math-Gruppe führt Arithmetik, wie z. B. Skalarproduktberechnungen, an Vektoroperanden durch.
Grafik-Pipeline
8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors 800.
Elemente von 8, welche die gleichen Bezugsnummern (oder Namen) wie die Elemente einer anderen hierin enthaltenen Figur haben, können in jeder Weise ähnlich den woanders hierin beschriebenen Elementen arbeiten oder funktionieren, sind aber nicht auf solche beschränkt.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Geometrie-Pipeline 820, eine Medien-Pipeline 830, eine Display-Engine 840, Thread-Ausführungslogik 850 und eine Renderausgabe-Pipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkern-Verarbeitungssystems, das ein oder mehrere Allzweck-Verarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreibvorgänge zu ein oder mehreren Steuerregistern (nicht gezeigt) oder über Befehle, die über einen Ring-Interconnect 802 an den Grafikprozessor 800 ausgegeben werden, gesteuert. In einigen Ausführungsformen koppelt der Ring-Interconnect 802 den Grafikprozessor 800 mit anderen Verarbeitungskomponenten, z. B. mit anderen Grafikprozessoren oder Allzweckprozessoren. Befehle vom Ring-Interconnect 802 werden durch einen Befehlsstreamer 803 interpretiert, der Anweisungen zu individuellen Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 liefert.
In einigen Ausführungsformen leitet der Befehlsstreamer 803 die Operation eines Vertex-Fetchers 805, der Vertexdaten aus dem Speicher ausliest und von dem Befehlsstreamer 803 gelieferte Vertex-Verarbeitungsbefehle ausführt. In einigen Ausführungsformen liefert der Vertex-Fetcher 805 Vertexdaten zu einem Vertex-Shader 807, der Koordinaten-Raumtransformations- und Beleuchtungsoperationen für jeden Vertex durchführt. In einigen Ausführungsformen führen Vertex-Fetcher 805 und Vertex-Shader 807 Vertex-Verarbeitungsbefehle aus, indem sie Ausführungsthreads über einen Thread-Dispatcher 831 zu den Ausführungseinheiten 852A-852B versenden.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B ein Array von Vektorprozessoren, die einen Befehlssatz zur Durchführung von Grafik- und Medienoperationen aufweisen. In einigen Ausführungsformen haben die Ausführungseinheiten 852A-852B einen angeschlossenen L1-Cache 851, der für jedes Array spezifisch ist oder zwischen den Arrays geteilt wird. Der Cache kann als Datencache, Befehlscache oder Einzelcache konfiguriert werden, der partitioniert ist, um Daten und Befehle in unterschiedlichen Partitionen zu enthalten.
In einigen Ausführungsformen enthält die Geometrie-Pipeline 820 Tessellationskomponenten, um hardwarebeschleunigte Tessellation von 3D-Objekten durchzuführen. In einigen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tessellationsoperationen. Ein programmierbarer Domain-Shader 817 liefert Back-End-Bewertung der Tessellationsausgabe. Ein Tessellator 813 arbeitet auf Anweisung des Hull-Shaders 811 und enthält Sonderzwecklogik, um einen Satz von detaillierten geometrischen Objekten auf der Basis eines groben geometrischen Modells zu erzeugen, das als Eingabe in die Geometrie-Pipeline 820 bereitgestellt wird. Falls Tessellation in einigen Ausführungsformen nicht verwendet wird, können die Tessellationskomponenten (z. B. Hull-Shader 811, Tessellator 813 und Domain-Shader 817) umgangen werden.
In einigen Ausführungsformen können komplette geometrische Objekte durch einen Geometrie-Shader 819 über ein oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 852A-852B versendet werden, oder sie können direkt zu dem Clipper 829 vorrücken. In einigen Ausführungsformen arbeitet der Geometrie-Shader an gesamten geometrischen Objekten anstatt an Vertices oder Stücken von Vertices, wie in vorhergehenden Phasen der Grafik-Pipeline. Falls die Tessellation deaktiviert ist, empfängt der Geometrie-Shader 819 Eingabe von dem Vertex-Shader 807. In einigen Ausführungsformen ist der Geometrie-Shader 819 durch ein Geometrie-Shaderprogramm programmierbar, um Geometrie-Tessellation durchzuführen, falls die Tessellationseinheiten deaktiviert sind.
Vor der Rasterisierung verarbeitet ein Clipper 829 Vertexdaten. Der Clipper 829 kann ein Festfunktionsclipper oder ein programmierbarer Clipper sein, der Clipping- und Geometrie-Shaderfunktionen aufweist.
In einigen Ausführungsformen versendet eine Rasterisierungs- und Tiefentestkomponente 873 in der Render-Ausgabepipeline 870 Pixel-Shader, um die geometrischen Objekte in Pro-Pixel-Repräsentationen umzuwandeln. In einigen Ausführungsformen ist eine Pixel-Shaderlogik in der Thread-Ausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung die Rasterisierungs- und Tiefentestkomponente 873 umgehen und über eine Streamausgabeeinheit 823 auf nicht rasterisierte Vertexdaten zugreifen.
Der Grafikprozessor 800 hat einen Interconnect-Bus, ein Interconnect-Netzwerk oder einen anderen Interconnect-Mechanismus, der Daten- und Nachrichtendurchgang zwischen den Hauptkomponenten des Prozessors gestattet. In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B und die zugehörigen Logikeinheiten (z. B. L1-Cache 851, Sampler 854, Texturcache 858 usw.) über einen Datenport 856 verbunden, um Speicherzugriff durchzuführen und mit Renderausgabe-Pipelinekomponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen verwenden Sampler 854, Caches 851, 858 und Ausführungseinheiten 852A-852B jeweils getrennte Speicherzugriffspfade. In einer Ausführungsform kann der Texturcache 858 auch als Samplercache konfiguriert sein.
In einigen Ausführungsformen enthält die Renderausgabe-Pipeline 870 eine Rasterisierungs- und Tiefentestkomponente 873, die vertexbasierte Objekte in eine zugehörige pixelbasierte Repräsentation umwandelt.
In einigen Ausführungsformen enthält die Rastererlogik eine Windower/Masker-Einheit, um Festfunktions-Dreieck- und Linienrasterisierung durchzuführen. Ein verbundener Rendercache 878 und Tiefencache 879 sind in einigen Ausführungsformen ebenfalls verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten durch, obwohl in manchen Fällen mit 2D-Operationen (z. B. Bitblock-Bildübertragungen mit Mischung) verbundene Pixeloperationen durch die 2D-Engine 841 durchgeführt oder zur Anzeigezeit durch den Anzeige-Controller 843 unter Verwendung von Überlagerungs-Anzeigeebenen ersetzt werden. In einigen Ausführungsformen ist ein gemeinsamer L3-Cache 875 für alle Grafikkomponenten verfügbar, so dass die gemeinsame Nutzung von Daten ohne Verwendung des Hauptsystemspeichers möglich ist.
In einigen Ausführungsformen enthält die Grafikprozessor-Medien-Pipeline 830 eine Medien-Engine 837 und ein Video-Front-End 834. In einigen Ausführungsformen empfängt das Video-Front-End 834 Pipelinebefehle von dem Befehlsstreamer 803. In einigen Ausführungsformen enthält die Medien-Pipeline 830 einen getrennten Befehlsstreamer. In einigen Ausführungsformen verarbeitet das Video-Front-End 834 Medienbefehle, bevor der Befehl zu der Medien-Engine 837 gesendet wird. In einigen Ausführungsformen enthält die Medien-Engine 837 Thread-Hervorbringungsfunktionalität, um Threads zum Versenden zu der Thread-Ausführungslogik 850 über den Thread-Dispatcher 831 hervorzubringen.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Display-Engine 840. In einigen Ausführungsformen ist die Display-Engine 840 extern zu dem Prozessor 800 und koppelt mit dem Grafikprozessor über den Ring-Interconnect 802 oder einen anderen Interconnect-Bus oder ein Netzwerk. In einigen Ausführungsformen enthält die Display-Engine 840 eine 2D-Engine 841 und einen Anzeige-Controller 843.
In einigen Ausführungsformen enthält die Display-Engine 840 Sonderzwecklogik, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen koppelt der Anzeige-Controller 843 mit einer Anzeigevorrichtung (nicht gezeigt), die eine systemintegrierte Anzeigevorrichtung, wie in einem Laptop-Computer, oder eine externe Anzeigevorrichtung sein kann, die über einen Anzeigevorrichtungsanschluss angeschlossen wird.
In einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 konfigurierbar, um auf mehreren Grafik- und Medien-Programmierschnittstellen basierende Operationen durchzuführen, und sind nicht spezifisch für eine beliebige Anwendungsprogrammierschnittstelle (API). In einigen Ausführungsformen übersetzt 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. In einigen Ausführungsformen wird Unterstützung für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan-Grafik- und Berechnungs-API, alle von der Khronos Group, bereitgestellt. In einigen Ausführungsformen kann auch Unterstützung für die Direct3D-Bibliothek von der Microsoft Corporation bereitgestellt werden. In einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Unterstützung kann auch für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde ebenfalls unterstützt werden, falls ein Mapping von der Pipeline der zukünftigen API zu der Pipeline des Grafikprozessors gemacht werden kann.
Grafik-Pipeline-Programmierung
9A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat 900 gemäß einigen Ausführungsformen darstellt. 9B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlssequenz 910 gemäß einer Ausführungsform darstellt. Die Kästen mit durchgezogener Linie in 9A stellen die Komponenten dar, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die Kästen mit gestrichelter Linie Komponenten enthalten, die optional oder nur in einem Teilsatz der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 von 9A enthält Datenfelder, um einen Client 902, einen Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl zu identifizieren. Ein Sub-Opcode 905 und eine Befehlsgröße 908 sind ebenfalls in einigen Befehlen enthalten.
In einigen Ausführungsformen gibt der Client 902 die Client-Einheit des Grafikgerätes an, das die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessor-Befehlsparser das Client-Feld jedes Befehls, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten zu der entsprechenden Client-Einheit zu leiten. In einigen Ausführungsformen enthalten die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Client-Einheit hat eine entsprechende Verarbeitungs-Pipeline, welche die Befehle verarbeitet. Sobald der Befehl von der Client-Einheit empfangen wird, liest die Client-Einheit den Opcode 904 und, falls vorhanden, den Sub-Opcode 905, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung der Informationen im Datenfeld 906 durch. Für einige Befehle wird eine explizite Befehlsgröße 908 erwartet, um die Größe des Befehls anzugeben. In einigen Ausführungsformen bestimmt der Befehlsparser automatisch die Größe von mindestens einigen der Befehle auf der Basis des Befehls-Opcodes. In einigen Ausführungsformen werden Befehle über Vielfache eines Doppelworts ausgerichtet.
Das Flussdiagramm in 9B stellt eine beispielhafte Grafikprozessor-Befehlssequenz 910 dar. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors aufweist, eine Version der gezeigten Befehlssequenz, um einen Satz von Grafikoperationen einzurichten, auszuführen und zu beenden. Eine beispielhafte Befehlssequenz wird lediglich zum Zwecke eines Beispiels 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 Stapel von Befehlen in einer Befehlssequenz ausgegeben werden, so dass der Grafikprozessor die Sequenz von Befehlen in zumindest teilweiser Übereinstimmung verarbeitet.
In einigen Ausführungsformen kann die Grafikprozessor-Befehlssequenz 910 mit einem Pipeline-Spülbefehl 912 beginnen, um eine aktive Grafik-Pipeline zu veranlassen, die gegenwärtig ausstehenden Befehle für die Pipeline zu vollenden. In einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Die Pipeline-Spülung wird durchgeführt, um die aktive Grafik-Pipeline zu veranlassen, etwaige ausstehende Befehle zu vollenden. Als Reaktion auf eine Pipeline-Spülung unterbricht der Befehlsparser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichnungs-Engines ausstehende Operationen vollenden und die relevanten Lese-Caches invalidiert werden.
Optional können etwaige Daten im Rendercache, die als ,schmutzig‘ markiert sind, in den Speicher gespült werden. In einigen Ausführungsformen kann der Pipeline-Spülbefehl 912 für Pipeline-Synchronisierung oder vor der Versetzung des Grafikprozessors in einen Energiesparzustand verwendet werden.
In einigen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz ausdrücklich vom Grafikprozessor verlangt, zwischen Pipelines umzuschalten. In einigen Ausführungsformen ist ein Pipeline-Auswahlbefehl 913 nur einmal innerhalb eines Ausführungskontextes vor der Ausgabe von Pipeline-Befehlen erforderlich, es sei denn der Kontext besteht darin, Befehle für beide Pipelines auszugeben. In einigen Ausführungsformen ist ein Pipeline-Spülbefehl 912 unmittelbar vor einer Pipeline-Umschaltung über den Pipeline-Auswahlbefehl 913 erforderlich.
In einigen Ausführungsformen konfiguriert ein Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für eine Operation und wird verwendet, die 3D-Pipeline 922 und die Medien-Pipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Pipeline-Steuerbefehl 914 den Pipeline-Zustand für die aktive Pipeline. In einer Ausführungsform wird der Pipeline-Steuerbefehl 914 für Pipeline-Synchronisierung und zum Löschen von Daten von einem oder mehreren Cache-Speichern innerhalb der aktiven Pipeline vor der Verarbeitung eines Stapels von Befehlen verwendet.
In einigen Ausführungsformen werden Rückgabepuffer-Zustandsbefehle 916 verwendet, um einen Satz von Rückgabepuffern für die entsprechenden Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration von ein oder mehreren Rückgabepuffern, in welche die Operationen Zwischendaten während der Verarbeitung schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch ein oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und Cross-Thread-Kommunikation durchzuführen.
In einigen Ausführungsformen beinhaltet der Rückgabepufferzustand 916 das Auswählen der Größe und Anzahl von Rückgabepuffern zur Verwendung für einen Satz von Pipeline-Operationen.
Die verbleibenden Befehle in der Befehlssequenz sind je nach der aktiven Pipeline für Operationen unterschiedlich. Basierend auf einer Pipeline-Bestimmung 920, ist die Befehlssequenz auf die 3D-Pipeline 922 beginnend mit dem 3D-Pipeline-Zustand 930 oder die Medien-Pipeline 924 beginnend bei dem Medien-Pipeline-Zustand 940 abgestimmt.
Die Befehle zum Konfigurieren des 3D-Pipeline-Zustands 930 enthalten 3D-Zustand-Einstellungsbefehle für Vertex-Pufferzustand, Vertex-Elementzustand, Konstantfarbenzustand, Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Grundkörperbefehle verarbeitet werden.
Die Werte dieser Befehle werden zumindest teilweise auf der Basis der verwendeten bestimmten 3D-API bestimmt. In einigen Ausführungsformen sind Befehle des 3D-Pipeline-Zustands 930 auch in der Lage, bestimmte Pipeline-Elemente gezielt zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird ein 3D-Grundkörperbefehl 932 verwendet, um durch die 3D-Pipeline zu verarbeitende 3D-Grundkörper zu übermitteln. Befehle und zugehörige Parameter, die über den Befehl des 3D-Grundkörpers 932 zu dem Grafikprozessor geleitet werden, werden zu der Vertex-Abruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die Befehlsdaten des 3D-Grundkörpers 932, um Vertex-Datenstrukturen zu erzeugen. Die Vertex-Datenstrukturen werden in ein oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der Befehl des 3D-Grundkörpers 932 verwendet, um Vertex-Operationen an 3D-Grundkörpern über Vertex-Shader durchzuführen. Um Vertex-Shader zu verarbeiten, versendet die 3D-Pipeline 922 Shader-Ausführungsthreads zu Grafikprozessor-Ausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Ausführungsbefehl 934 oder ein Ausführungsereignis ausgelöst. In einigen Ausführungsformen löst ein Registerschreibvorgang eine Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über den Befehl ,go‘ oder ,kick‘ in der Befehlssequenz ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipeline-Synchronisierungsbefehls ausgelöst, um die Befehlssequenz durch die Grafik-Pipeline zu spülen. Die 3D-Pipeline führt Geometrieverarbeitung für die 3D-Grundkörper durch. Sobald die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte rasterisiert, und die Pixel-Engine färbt die resultierenden Pixel. Zusätzliche Befehle zum Steuern von Pixel-Shading und Pixel-Back-End-Operationen können ebenfalls für diese Operationen enthalten sein.
In einigen Ausführungsformen folgt die Grafikprozessor-Befehlssequenz 910 dem Pfad der Medien-Pipeline 924 bei der Durchführung von Medienoperationen. Im Allgemeinen hängt die spezifische Nutzung und Art der Programmierung für die Medien-Pipeline 924 von den durchzuführenden Medien- oder Berechnungsoperationen ab. Spezifische Mediendecodierungsoperationen können während der Mediendecodierung auf die Medien-Pipeline abgeladen werden. In einigen Ausführungsformen kann die Medien-Pipeline auch umgangen werden, und die Mediendecodierung kann ganz oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von ein oder mehreren Allzweck-Verarbeitungskernen bereitgestellt werden. In einer Ausführungsform enthält die Medien-Pipeline auch Elemente für Operationen der Allzweck-Grafikprozessoreinheit (GPGPU), wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von rechnerischen Shaderprogrammen durchzuführen, die nicht ausdrücklich auf das Rendern von Grafik-Grundkörpern bezogen sind.
In einigen Ausführungsformen ist die Medien-Pipeline 924 in einer ähnlichen Weise wie die 3D-Pipeline 922 ausgelegt. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipelinezustands 940 wird versendet oder in eine Befehlswarteschlange vor den Medienobjektbefehlen 942 gesetzt. In einigen Ausführungsformen enthalten Befehle für den Medien-Pipelinezustand 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medienobjekte verwendet werden. Dies schließt Daten zum Konfigurieren der Videodecodier- und Videocodierlogik innerhalb der Medien-Pipeline ein, wie z. B. das Codier- oder Decodierformat. In einigen Ausführungsformen unterstützen Befehle für den Medien-Pipelinezustand 940 auch die Verwendung von ein oder mehreren Zeigern zu Elementen des Zustands „indirekt“, die einen Stapel von Zustandseinstellungen enthalten.
In einigen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger zu Medienobjekten zum Verarbeiten durch die Medien-Pipeline. Die Medienobjekte schließen Speicherpuffer ein, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medien-Pipelinezustände gültig sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Nachdem der Pipelinezustand konfiguriert worden ist und die Medienobjektbefehle 942 aufgereiht worden sind, wird die Medien-Pipeline 924 über einen Ausführbefehl 944 oder ein gleichwertiges Ausführereignis (z. B. Registerschreibvorgang) ausgelöst. Die Ausgabe von der Medien-Pipeline 924 kann dann durch Operationen, die von der 3D-Pipeline 922 oder der Medien-Pipeline 924 bereitgestellt werden, nachverarbeitet werden. In einigen Ausführungsformen werden die GPGPU-Operationen in einer ähnlichen Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafiksoftwarearchitektur
10 stellt eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß einiger Ausführungsformen dar. In einigen Ausführungsformen enthält die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. In einigen Ausführungsformen enthält der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Allzweck-Prozessorkern(e) 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shaderprogramme, die Shaderbefehle 1012 aufweisen. Die Shader-Sprachbefehle können in einer Shader-Hochsprache vorliegen, wie z. B. der High Level Shader Language (HLSL) oder der OpenGL Shader Language (GLSL). Die Anwendung enthält auch ausführbare Befehle 1014 in einer Maschinensprache, die für Ausführung durch den Allzweck-Prozessorkern 1034 geeignet ist. Die Anwendung enthält auch durch Vertexdaten definierte Grafikobjekte 1016.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows® Betriebssystem von der Microsoft Corporation, ein proprietäres UNIX-artiges Betriebssystem oder ein UNIX-artiges Open-Source-Betriebssystem, das eine Variante des Linux-Kerns verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022, wie etwa die Direct3D-API, die OpenGL-API oder die Vulkan-API, unterstützen. Wenn die Direct3D-API in Gebrauch ist, verwendet das Betriebssystem 1020 einen Front-End-Shader-Compiler 1024, um in HLSL vorliegende Shaderbefehle 1012 zu einer Shadersprache einer niedrigeren Ebene zu kompilieren. Die Kompilierung kann eine Just-in-Time (JIT)-Kompilierung sein, oder die Anwendung kann eine Shader-Vorkompilierung durchführen. In einigen Ausführungsformen werden Shader einer hohen Ebene während der Kompilierung der 3D-Grafikanwendung 1010 zu Shadern einer niedrigen Ebene kompiliert. In einigen Ausführungsformen werden die Shaderbefehle 1012 in einer Zwischenform bereitgestellt, wie z. B. einer Version der von der Vulkan-API verwendeten Standard Portable Intermediate Representation (SPIR).
In einigen Ausführungsformen enthält der Benutzermodus-Grafiktreiber 1026 einen Back-End-Shader-Compiler 1027, um die Shaderbefehle 1012 in eine hardwarespezifische Repräsentation umzuwandeln.
Wenn die OpenGL-API in Gebrauch ist, werden Shaderbefehle 1012 in der GLSL-Hochsprache zur Kompilierung zu einem Benutzermodus-Grafiktreiber 1026 geleitet. In einigen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystem-Kernmodusfunktionen 1028, um mit einem Kernmodus-Grafiktreiber 1029 zu kommunizieren. In einigen Ausführungsformen kommuniziert der Kernmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen zu versenden.
IP-Kern-Implementierungen
Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, und der Logik innerhalb einer integrierten Schaltung, wie z. B. einem Prozessor, repräsentiert und/oder definiert. Beispielsweise kann das maschinenlesbare Medium Befehle enthalten, die verschiedene Logik innerhalb des Prozessors repräsentieren. Wenn von einer Maschine gelesen, können die Befehle die Maschine veranlassen, die Logik zu fabrizieren, um die hierin beschriebenen Techniken durchzuführen. Solche Repräsentationen, auch als „IP-Kerne“ bekannt, sind wiederverwendbare Einheiten von Logik für eine integrierte Schaltung, die auf einem materiellen, maschinenlesbaren Medium als ein Hardwaremodell gespeichert werden können, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann zu verschiedenen Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Fertigungsmaschinen laden, welche die integrierte Schaltung herstellen. Die integrierte Schaltung kann so gefertigt werden, dass die Schaltung Operationen durchführt, die in Verbindung mit beliebigen der hierin beschriebenen Ausführungsformen beschrieben werden.
11A ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem 1100 darstellt, das zur Herstellung einer integrierten Schaltung verwendet werden kann, um Operationen gemäß einer Ausführungsform durchzuführen. Das IP-Kernentwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs zu erzeugen, die in ein größeres Design integriert oder verwendet werden können, um eine gesamte integrierte Schaltung (z. B. eine integrierte SOC-Schaltung) zu konstruieren. Eine Designeinrichtung 1130 kann eine Softwaresimulation 1110 eines IP-Core-Designs in einer Programmier-Hochsprache (z. B. C/C++) erzeugen. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu entwerfen, zu testen und zu überprüfen. Das Simulationsmodell 1112 kann funktionale, verhaltensbasierte und/oder Timingsimulationen enthalten. Ein Register-Transfer-Level (RTL)-Design 1115 kann dann von dem Simulationsmodell 1112 erzeugt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, das den Fluss von Digitalsignalen zwischen Hardwareregistern, einschließlich der zugehörigen Logik, die unter Verwendung der modellierten Digitalsignale durchgeführt wird, modelliert. Zusätzlich zu einem RTL-Design 1115 können auch Designs einer niedrigeren Ebene auf dem Logikniveau oder Transistorniveau erzeugt, entworfen oder synthetisiert werden. Somit können die konkreten Details des anfänglichen Designs und der Simulation variieren.
Das RTL-Design 1115 oder eine Entsprechung kann durch die Designeinrichtung zu einem Hardwaremodell 1120, das in einer Hardwarebeschreibungssprache (HDL) vorliegen kann, oder zu einer anderen Repräsentation der physischen Designdaten weiter synthetisiert werden. Die HDL kann ferner simuliert oder getestet werden, um das IP-Core-Design zu überprüfen. Das IP-Core-Design kann zur Lieferung an eine Fertigungseinrichtung 1165 eines anderen Herstellers unter Verwendung von nichtflüchtigem Speicher 1140 (z. B. Festplatte, Flash-Speicher oder einem beliebigen nichtflüchtigen Speichermedium) gespeichert werden. Alternativ dazu kann das IP-Core-Design über eine Kabelverbindung 1150 oder eine Funkverbindung 1160 übertragen werden (z. B. über das Internet). Die Fertigungseinrichtung 1165 kann dann eine integrierte Schaltung fertigen, die zumindest teilweise auf dem IP-Core-Design basiert. Die gefertigte integrierte Schaltung kann dazu ausgelegt sein, Operationen im Einklang mit mindestens einer hierin beschriebenen Ausführungsform durchzuführen.
11B stellt eine Querschnitts-Seitenansicht einer IC-Gehäuseanordnung 1170 gemäß einigen hierin beschriebenen Ausführungsformen dar. Die IC-Gehäuseanordnung 1170 stellt eine Implementierung von ein oder mehreren Prozessor- oder Beschleunigereinrichtungen dar, wie hierin beschrieben. Die Gehäuseanordnung 1170 enthält mehrere Einheiten von Hardwarelogik 1172, 1174, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann zumindest teilweise in konfigurierbarer Logik- oder Festfunktions-Logikhardware implementiert sein, und kann ein oder mehrere Teile eines der Prozessorkerne, der Grafikprozessoren oder der anderen hierin beschriebenen Beschleunigereinrichtungen enthalten. Jede Einheit der Logik 1172, 1174 kann innerhalb eines Halbleiterchips implementiert und über eine Interconnect-Struktur 1173 mit dem Substrat 1180 gekoppelt werden. Die Interconnect-Struktur 1173 kann dazu ausgebildet sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten, und kann solche Interconnects wie etwa Höcker oder Säulen enthalten, ohne jedoch darauf beschränkt zu sein. In einigen Ausführungsformen kann die Interconnect-Struktur 1173 dazu ausgebildet sein, elektrische Signale, wie z. B. Eingabe/Ausgabe (E/A)-Signale und/oder Strom- oder Massesignale, die mit dem Betrieb der Logik 1172, 1174 verbunden sind, zu leiten. In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidbasis. In anderen Ausführungsformen kann die Gehäuseanordnung 1170 andere geeignete Arten von Substraten enthalten. Die Gehäuseanordnung 1170 kann über ein Gehäuse-Interconnect 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Das Gehäuse-Interconnect 1183 kann mit einer Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie z. B. einer Systemplatine, einem anderen Chipsatz oder einem Multi-Chip-Modul, zu leiten.
In einigen Ausführungsformen sind die Einheiten der Logik 1172, 1174 mit einer Brücke 1182 elektrisch gekoppelt, die dazu ausgelegt ist, elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Brücke 1182 kann eine dichte Interconnect-Struktur sein, die eine Route für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat einschließen, das aus Glas oder einem geeigneten Halbleitermaterial gebildet ist. Elektrische Leitungselemente können auf dem Brückensubstrat gebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Obwohl zwei Einheiten von Logik 1172, 1174 und eine Brücke 1182 dargestellt sind, können die hierin beschriebenen Ausführungsformen mehr oder weniger Logikeinheiten auf ein oder mehreren Chips enthalten. Die ein oder mehreren Chips können durch null oder mehr Brücken verbunden sein, da die Brücke 1182 ausgeschlossen sein kann, wenn die Logik auf einem einzelnen Chip enthalten ist. Alternativ dazu können mehrere Chips oder Logikeinheiten durch ein oder mehrere Brücken verbunden sein. Außerdem können in anderen möglichen Konfigurationen, einschließlich dreidimensionaler Konfigurationen, mehrere Logikeinheiten, Chips und Brücken miteinander verbunden sein.
Beispielhafte integrierte Ein-Chip-System-Schaltung
12-14 stellen beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren dar, die gemäß verschiedenen hierin beschriebenen Ausführungsformen unter Verwendung von ein oder mehreren IP-Cores gefertigt sein können. Zusätzlich zu den dargestellten Elementen können andere Logikeinheiten und Schaltungen enthalten sein, darunter auch zusätzliche Grafikprozessoren/-kerne, Peripherie-Schnittstellencontroller oder Allzweck-Prozessorkerne.
12 ist ein Blockdiagramm, das eine beispielhafte integrierte Ein-Chip-System-Schaltung 1200 darstellt, die gemäß einer Ausführungsform unter Verwendung von ein oder mehreren IP-Kernen gefertigt werden kann. Die beispielhafte integrierte Schaltung 1200 enthält ein oder mehrere Anwendungsprozessoren 1205 (z. B. CPUs), mindestens einen Grafikprozessor 1210, und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 enthalten, von denen jeder ein modularer IP-Core von derselben oder von mehreren unterschiedlichen Designeinrichtungen sein kann. Die integrierte Schaltung 1200 enthält Peripheriegeräte- oder Bus-Logik, darunter einen USB-Controller 1225, UART-Controller 1230, einen SPI/SDIO-Controller 1235 und einen I²S/I²C-Controller 1240. Außerdem kann die integrierte Schaltung eine Anzeigevorrichtung 1245 enthalten, die mit ein oder mehreren eines High-Definition-Multimedia-Interface (HDMI)-Controllers 1250 und einer Mobile Industry Processor Interface (MIPI)-Anzeigeschnittstelle 1255 gekoppelt ist. Speicherung kann von einem Flash-Speicher-Untersystem 1260 bereitgestellt werden, das einen Flash-Speicher und einen Flash-Speichercontroller enthält.
Eine Speicherschnittstelle kann über einen Speichercontroller 1265 für Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt werden. Einige integrierte Schaltungen enthalten zusätzlich eine integrierte Sicherheits-Engine 1270.
13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren für den Einsatz innerhalb eines SoC gemäß den hierin beschriebenen Ausführungsformen darstellen. 13A stellt einen beispielhaften Grafikprozessor 1310 einer integrierten Ein-Chip-System-Schaltung dar, der gemäß einer Ausführungsform unter Verwendung von ein oder mehreren IP-Cores gefertigt werden kann. 13B stellt einen zusätzlichen beispielhaften Grafikprozessor 1340 einer integrierten Ein-Chip-System-Schaltung dar, der gemäß einer Ausführungsform unter Verwendung von ein oder mehreren IP-Cores gefertigt werden kann. Der Grafikprozessor 1310 von 13A ist ein Beispiel eines energiesparenden Grafikprozessorkerns. Der Grafikprozessor 1340 von 13B ist ein Beispiel eines Grafikprozessorkerns mit höherer Leistung. Jeder der Grafikprozessoren 1310, 1340 kann eine Variante des Grafikprozessors 1210 von 12 sein.
Wie in 13A gezeigt, enthält der Grafikprozessor 1310 einen Vertex-Prozessor 1305 und einen oder mehrere Fragment-Prozessor(en) 1315A-1315N (z. B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N). Der Grafikprozessor 1310 kann unterschiedliche Shaderprogramme über eine getrennte Logik ausführen, so dass der Vertex-Prozessor 1305 optimiert wird, um Operationen für Vertex-Shaderprogramme auszuführen, während der eine oder die mehreren Fragment-Prozessor(en) 1315A-1315N Fragment- (z. B. Pixel)-Shading-Operationen für Fragment- oder Pixel-Shaderprogramme ausführen. Der Vertex-Prozessor 1305 führt die Vertex-Verarbeitungsstufe der 3D-Grafik-Pipeline durch und erzeugt Grundkörper und Vertexdaten. Der (Die) Fragment-Prozessor(en) 1315A-1315N verwendet (verwenden) die von dem Vertex-Prozessor 1305 erzeugten Grundkörper und Vertexdaten, um einen Framebuffer zu produzieren, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform wird der (werden die) Fragment-Prozessor(en) 1315A-1315N optimiert, um Fragment-Shaderprogramme gemäß der OpenGL-API auszuführen, die verwendet werden können, um ähnliche Operationen wie ein Pixel-Shaderprogramm gemäß der Direct 3D-API durchzuführen.
Der Grafikprozessor 1310 enthält zusätzlich ein oder mehrere Speicherverwaltungseinheiten (MMUs) 1320A-1320B, Caches 1325A-1325B und Schaltungs-Interconnects 1330A-1330B.
Die eine oder mehreren MMU(s) 1320A-1320B sorgen für virtuelle auf physische Adresszuordnung für den Grafikprozessor 1310, einschließlich für den Vertex-Prozessor 1305 und/oder den (die) Fragment-Prozessor(en) 1315A-1315N, die im Speicher abgelegte Vertex- oder Bild-/Texturdaten referenzieren können, zusätzlich zu in den ein oder mehreren Caches 1325A-1325B gespeicherten Vertex- oder Bild-/Texturdaten. In einer Ausführungsform kann (können) die eine oder mehreren MMU(s) 1320A-1320B mit anderen MMUs innerhalb des Systems synchronisiert werden, einschließlich den ein oder mehreren MMUs, die mit dem einen oder mehreren Anwendungsprozessor(en) 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 von 12, verbunden sind, so dass jeder Prozessor 1205-1220 an einem gemeinsamen oder vereinheitlichten virtuellen Speichersystem teilhaben kann. Der (Die) eine oder mehreren Schaltungs-Interconnect(s) 1330A-1330B ermöglicht (ermöglichen) es dem Grafikprozessor 1310, Schnittstellen mit anderen IP-Cores innerhalb des SoC, entweder über einen internen Bus des SoC oder über eine Direktverbindung gemäß den Ausführungsformen, zu bilden.
Wie in 13B gezeigt, enthält der Grafikprozessor 1340 die eine oder mehreren MMU(s) 1320A-1320B, Caches 1325A-1325B und Schaltungs-Interconnects 1330A-1330B des Grafikprozessors 1310 von 13A. Der Grafikprozessor 1340 enthält ein oder mehrere Shaderkerne 1355A-1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), wodurch eine vereinheitlichte Shaderkern-Architektur gebildet wird, in der ein einzelner Core oder Typ oder Core alle Arten von programmierbarem Shadercode, einschließlich Shader-Programmcode, ausführen kann, um Vertex-Shader, Fragment-Shader und/oder Compute-Shader zu implementieren. Die genaue Anzahl von vorhandenen Shaderkernen kann je nach Ausführungsformen und Implementierungen variieren. Außerdem enthält der Grafikprozessor 1340 einen Inter-Core-Taskmanager 1345, der als Thread-Dispatcher agiert, um Ausführungsthreads zu ein oder mehreren Shaderkernen 1355A-1355N und einer Kachelungseinheit 1358 zu versenden, um Kachelungsoperationen für kachelbasiertes Rendering zu beschleunigen, wobei Rendering-Operationen für eine Szene in Bildraum unterteilt werden, um beispielsweise lokale räumliche Kohärenz innerhalb einer Szene auszunutzen, oder um den Gebrauch von internen Caches zu optimieren.
14A-14B stellen eine zusätzliche beispielhafte Grafikprozessorlogik gemäß den hierin beschriebenen Ausführungsformen dar. 14A stellt einen Grafikkern 1400 dar, der in dem Grafikprozessor 1210 von 12 enthalten sein kann, und der ein vereinheitlichter Shaderkern 1355A-1355N sein kann, wie in 13B gezeigt. 14B stellt eine äußerst parallele Allzweck-Grafikverarbeitungseinheit 1430 dar, die für den Einsatz auf einem Multi-Chip-Modul geeignet ist.
Wie in 14A gezeigt, enthält der Grafikkern 1400 einen gemeinsamen Befehlscache 1402, eine Textureinheit 1418 und einen Cache-/Freigabespeicher 1420, die den Ausführungsressourcen innerhalb des Grafikkerns 1400 gemeinsam sind. Der Grafikkern 1400 kann mehrere Scheiben 1401A-1401N oder Partitionen für jeden Kern enthalten, und ein Grafikprozessor kann mehrere Instanzen des Grafikkerns 1400 enthalten. Die Scheiben 1401A-1401N können Supportlogik enthalten, die einen lokalen Befehlscache 1404A-1404N, einen Thread-Scheduler 1406A-1406N, einen Thread-Dispatcher 1408A-1408N und einen Satz von Registern 1410A einschließt. Um Logikoperationen durchzuführen, können die Scheiben 1401A-1401N einen Satz von Zusatzfunktionseinheiten (AFUs 1412A-1412N), Gleitkommaeinheiten (FPU 1414A-1414N), Ganzzahl-Arithmetik-Logik-Einheiten (ALUs 1416-1416N), Adressberechnungseinheiten (ACU 1413A-1413N), Doppelpräzisions-Gleitkommaeinheiten (DPFPU 1415A-1415N) und Matrix-Verarbeitungseinheiten (MPU 1417A-1417N) enthalten.
Einige der Berechnungseinheiten arbeiten mit einer spezifischen Präzision. Beispielsweise können die FPUs 1414A-1414N Single-Precision (32-Bit) und Half-Precision (16-Bit)-Gleitkommaoperationen durchführen, während die DPFPUs 1415A-1415N Double-Precision (64-Bit)-Gleitkommaoperationen durchführen können. Die ALUs 1416A-1416N können Ganzzahloperationen mit variabler Präzision mit einer Präzision von 8-Bit, 16-Bit und 32-Bit durchführen und können für Operationen mit gemischter Präzision konfiguriert werden. Die MPUs 1417A-1417N können ebenfalls für Matrixoperationen mit gemischter Präzision, einschließlich Half-Precision-Gleitkomma- und 8-Bit-Ganzzahloperationen, konfiguriert werden. Die MPUs 1417-1417N können eine Vielfalt von Matrixoperationen durchführen, um Maschinenlernanwendungs-Frameworks zu beschleunigen und Unterstützung für beschleunigte allgemeine Matrix-Matrix-Multiplikation (GEMM) zu ermöglichen. Die AFUs 1412A-1412N können zusätzliche Logikoperationen durchführen, die nicht von den Gleitkomma- oder Ganzzahleinheiten unterstützt werden, u. a. trigonometrische Operationen (z. B. Sinus, Kosinus usw.).
Wie in 14B gezeigt, kann eine Allzweck-Verarbeitungseinheit (GPGPU) 1430 dazu ausgebildet sein, äußerst parallele Berechnungsoperationen zu ermöglichen, die von einem Array von Grafikprozessoren durchzuführen sind. Außerdem kann die GPGPU 1430 direkt mit anderen Instanzen der GPGPU verbunden werden, um einen Multi-GPU-Cluster zu erzeugen, der die Trainingsgeschwindigkeit für besonders tiefe neuronale Netzwerke verbessert. Die GPGPU 1430 enthält eine Hostschnittstelle 1432, um eine Verbindung mit einem Hostprozessor zu ermöglichen. In einer Ausführungsform ist die Hostschnittstelle 1432 eine PCI Express-Schnittstelle. Die Hostschnittstelle kann jedoch auch eine herstellerspezifische Kommunikationsschnittstelle oder ein Kommunikationsnetzwerk sein.
Die GPGPU 1430 empfängt Befehle von dem Hostprozessor und verwendet einen globalen Scheduler 1434, um mit diesen Befehlen verbundene Ausführungsthreads zu einem Satz von Berechnungsclustern 1436A-1436H zu verteilen. Die Berechnungscluster 1436A-1436H teilen sich einen Cache-Speicher 1438. Der Cache-Speicher 1438 kann als ein übergeordneter Cache für Cache-Speicher innerhalb der Berechnungscluster 1436A-1436H dienen.
Die GPGPU 1430 enthält Speicher 1434A-1434B, der mit den Berechnungsclustern 1436A-1436H über einen Satz von Speichercontrollern 1442A-1442B gekoppelt ist. In verschiedenen Ausführungsformen kann der Speicher 1434A-1434B verschiedene Arten von Speichervorrichtungen enthalten, darunter auch dynamischen Direktzugriffsspeicher (DRAM) oder Grafik-Direktzugriffsspeicher, wie z. B. synchroner Grafik-Direktzugriffsspeicher (SGRAM), einschließlich Grafik-Doppeldatenraten-(GDDR)-Speicher.
In einer Ausführungsform enthalten die Berechnungscluster 1436A-1436H jeweils einen Satz von Grafikkernen, wie z. B. den Grafikkern 1400 von 14A, der mehrere Arten von Ganzzahl- und Gleitkomma-Logikeinheiten enthalten kann, die Berechnungsoperationen mit einer Reihe von Präzisionen durchführen können, die auch für Maschinenlernberechnungen geeignet sind. Beispielsweise und in einer Ausführungsform kann zumindest ein Teilsatz der Gleitkommaeinheiten in jedem der Berechnungscluster 1436A-1436H dazu ausgebildet sein, 16-Bit- oder 32-Bit-Gleitkommaoperationen durchzuführen, während ein anderer Teilsatz der Gleitkommaeinheiten dazu ausgebildet sein kann, 64-Bit-Gleitkommaoperationen durchzuführen.
Mehrere Instanzen der GPGPU 1430 können dazu ausgebildet sein, als ein Berechnungscluster zu arbeiten. Der von dem Berechnungscluster für Synchronisierung und Datenaustausch verwendete Kommunikationsmechanismus variiert je nach Ausführungsform. In einer Ausführungsform kommunizieren die mehreren Instanzen der GPGPU 1430 über die Hostschnittstelle 1432. In einer Ausführungsform enthält die GPGPU 1430 einen E/A-Hub 1439, der die GPGPU 1430 mit einer GPU-Verbindung 1440 koppelt, die eine Direktverbindung mit anderen Instanzen der GPGPU ermöglicht. In einer Ausführungsform ist die GPU-Verbindung 1440 mit einer dedizierten GPU-GPU-Brücke gekoppelt, die Kommunikation und Synchronisierung zwischen mehreren Instanzen der GPGPU 1430 ermöglicht. In einer Ausführungsform ist die GPU-Verbindung 1440 mit einem Hochgeschwindigkeits-Interconnect gekoppelt, um Daten von und zu anderen GPGPUs oder parallelen Prozessoren zu empfangen und zu senden. In einer Ausführungsform befinden sich die mehreren Instanzen der GPGPU 1430 in getrennten Datenverarbeitungssystemen und kommunizieren über eine Netzwerkvorrichtung, die über die Hostschnittstelle 1432 zugänglich ist. In einer Ausführungsform kann die GPU-Verbindung 1440 dazu ausgebildet sein, eine Verbindung zu einem Hostprozessor zusätzlich zu oder als Alternative der Hostschnittstelle 1432 zu ermöglichen.
Während die dargestellte Konfiguration der GPGPU 1430 dazu ausgebildet sein kann, neuronale Netzwerke zu trainieren, stellt eine Ausführungsform eine alternative Konfiguration der GPGPU 1430 bereit, die zum Einsatz innerhalb einer Inferenzplattform von hoher Leistung oder geringer Energie konfiguriert werden kann. In einer Inferenzkonfiguration enthält die GPGPU 1430 weniger der Berechnungscluster 1436A-1436H relativ zu der Trainingskonfiguration. Außerdem kann die mit dem Speicher 1434A-1434B verbundene Speichertechnologie zwischen den Inferenz- und Trainingskonfigurationen abweichen, wobei Speichertechnologien mit höherer Bandbreite den Trainingskonfigurationen gewidmet sind. In einer Ausführungsform kann die Inferenzkonfiguration der GPGPU 1430 Inferenz-spezifische Befehle unterstützen. Beispielsweise kann eine Inferenzkonfiguration Unterstützung für ein oder mehrere 8-Bit-Ganzzahl-Skalarproduktbefehle bereitstellen, die allgemein während Inferenzoperationen für eingesetzte neuronale Netzwerke verwendet werden.
Übersicht über immersives Video
15A stellt mehrere Formen von immersivem Video dar. Immersives Video kann, abhängig von den für einen Betrachter verfügbaren Freiheitsgraden, in mehreren Formen präsentiert werden. Freiheitsgrade bezieht sich auf die Anzahl der unterschiedlichen Richtungen, in denen sich ein Objekt im dreidimensionalen (3D) Raum bewegen kann. Immersives Video kann über ein Head-Mounted Display betrachtet werden, das Verfolgung von Position und Orientierung einschließt. Beispielhafte Formen von immersivem Video schließen 3DoF 1502, 3DoF Plus 1504 und Full-6DoF 1506 ein. Zusätzlich zu immersivem Video in Full-6DoF 1506 schließt immersives 6D0F-Video omnidirektionales 6DoF 1507 und gefenstertes 6DoF 1508 ein.
Für Video in 3DoF 1502 (z. B. 360-Grad-Video) kann ein Betrachter die Orientierung (z. B. Gieren, Nicken, Rollen), aber nicht die Position ändern. Für Video in 3DoF Plus 1504 kann ein Betrachter die Orientierung ändern und kleine Änderungen an der Position vornehmen. Für Video in 6DoF 1506 kann ein Betrachter die Orientierung und die Position ändern. Stärker eingeschränkte Formen von 6DoF-Video sind ebenfalls verfügbar.
Video in omnidirektionalem 6DoF 1507 gestattet einem Betrachter, mehrere Schritte in der virtuellen Szene auszuführen. Video in gefenstertem 6DoF 1508 gestattet einem Betrachter, die Orientierung und Position zu ändern, doch der Betrachter ist auf einen begrenzten Sichtbereich beschränkt. Das Erhöhen der verfügbaren Freiheitsgrade in einem immersiven Video bringt im Allgemeinen Erhöhen der Menge und Komplexität der an Erzeugung, Codierung, Decodierung und Wiedergabe des Videos beteiligten Daten mit sich.
15B stellt Bildprojektions- und Texturebenen für immersives Video dar. Eine 3D-Ansicht 1510 des Videoinhalts kann mit Hilfe von Daten von mehreren Kameras erzeugt werden. Mehrere Projektionsebenen 1512 können verwendet werden, um Geometriedaten für den Videoinhalt zu erzeugen. Mehrere Texturebenen 1514 können für die Projektionsebenen 1512 abgeleitet werden, die zum Erzeugen der Geometriedaten verwendet werden.
Die Texturebenen 1514 können auf 3D-Modelle angewandt werden, die auf der Basis einer von Videodaten abgeleiteten Punktwolke vorerzeugt oder erzeugt werden. Die mehreren Projektionsebenen 1512 können verwendet werden, um mehrere zweidimensionale (2D) Projektionen zu erzeugen, wobei jede Projektion mit einer Projektionsebene verbunden ist.
16 stellt ein Client-Server-System dar, durch das immersive Videoinhalte erzeugt und codiert werden können, und zwar durch eine Server-Infrastruktur 1620 zur Übertragung zu ein oder mehreren Client-Geräten 1630. Die Client-Geräte 1630 können dann die immersiven Videoinhalte dekomprimieren und rendern. In einer Ausführungsform können ein oder mehrere Servergeräte 1620 Eingaben von ein oder mehreren optischen Kameras 1601 mit Tiefensensoren 1602 einschließen. Parallelberechnungsressourcen 1604 können die Video- und Tiefendaten zu Punktwolken 1605 und/oder Texturdreiecken 1606 zerlegen. Daten zum Erzeugen von texturierten Dreiecken 1606 können ebenfalls durch vorerzeugte 3D-Modelle 1603 einer Szene bereitgestellt werden. Die Punktwolken 1605 und/oder texturierten Dreiecke 1606 können für Übertragung zu ein oder mehreren Client-Geräten, die den Inhalt lokal rendern können, komprimiert werden. In einer Ausführungsform können mehrere Kompressionseinheiten 1607, 1608 unter Verwendung einer Vielfalt an Kompressionsalgorithmen erzeugte Inhalte zur Übertragung über ein Fördermedium von dem Server 1620 zu ein oder mehreren Client-Geräten 1630 komprimieren. Dekompressionseinheiten 1609, 1610 an den Client-Geräten 1630 können eingehende Bitstreams zu Video-/Textur- und Geometriedaten dekomprimieren und decodieren. Beispielsweise kann die Dekompressionseinheit 1609 komprimierte Punktwolkendaten decodieren und die dekomprimierten Punktwolkendaten einer Blickpunkt-Interpolationseinheit 1611 bereitstellen. Die interpolierten Blickpunktdaten können verwendet werden, um Bitmapdaten 1613 zu erzeugen. Die dekomprimierten Punktwolkendaten können einer Geometrie-Rekonstruktionseinheit 1612 bereitgestellt werden, um Geometriedaten für eine Szene zu rekonstruieren.
Die rekonstruierten Geometriedaten können durch decodierte Texturdaten (texturierte Dreiecke 1614) texturiert werden, um ein 3D-Rendering 1616 zur Betrachtung durch den Client 1630 zu erzeugen.
17A-17B stellen Systeme 1700, 1710 zum Codieren und Decodieren von 3DoF Plus-Inhalten dar. Das System 1700 kann zum Beispiel durch Hardware und Software einer Server-Infrastruktur 1620, implementiert werden, wie in 16 dargestellt. Das System 1710 kann durch Hardware und Software eines Clients 1630 implementiert werden, wie in 16 dargestellt.
Wie in 17A gezeigt, kann ein System 1700 verwendet werden, um Videodaten 1702 für eine Basisansicht 1701 und Videodaten 1705A-1705C für zusätzliche Ansichten 1704 zu codieren. Mehrere Kameras können Eingabedaten, einschließlich Videodaten und Tiefendaten, bereitstellen, wobei jedes Einzelbild von Videodaten in eine Textur umgewandelt werden kann. Ein Satz von Einheiten für Neuprojektion 1706 und Okklusionserkennung 1707 kann mit empfangenen Videodaten arbeiten und verarbeitete Daten an Einheiten für Patchbildung 1708 ausgeben. Von den Einheiten für Patchbildung 1708 gebildete Patches können einer Einheit für Patchpackung 1709 bereitgestellt werden. Videodaten 1702 für die Basisansicht 1701 können zum Beispiel über einen High Efficiency Video Coding (HEVC)-Codierer 1703A codiert werden. Eine Variante des HEVC-Codierers 1703A kann auch verwendet werden, um von der Einheit für Patchpackung 1709 ausgegebene Patch-Videodaten zu codieren. Metadaten zum Rekonstruieren von Video aus den codierten Patches können durch eine Einheit für Metadatencodierung 1703B codiert werden. Mehrere codierte Video- und Metadatenstreams können dann zur Betrachtung zu einem Client-Gerät übertragen werden.
Wie in 17B gezeigt, können mehrere Streams von Videodaten durch das System 1710 empfangen, decodiert und zu immersivem Video rekonstruiert werden. Die mehreren Streams von Video enthalten einen Stream für das Basisvideo neben einem Stream, der gepackte Daten für die zusätzlichen Ansichten enthält.
Codierte Metadaten werden ebenfalls empfangen. In einer Ausführungsform können die mehreren Videostreams über einen HEVC-Decoder 1713A decodiert werden. Metadaten können über einen Metadatendecoder 1713B decodiert werden. Die decodierten Metadaten werden dann verwendet, um die decodierten zusätzlichen Ansichten über Patch-Entpackungslogik 1719 zu entpacken. Decodierte Textur- und Tiefendaten (Video 0 1712, Video 1-3 1714A-1715C) der Basisansicht 1701 und der zusätzlichen Ansichten 1704 werden durch Ansichtserzeugungslogik 1718 am Client (z. B. Client 1630 wie in 16) rekonstruiert. Das decodierte Video 1712, 1715A-1715C kann als Textur- und Tiefendaten einem Zwischenansichtsrenderer 1714 bereitgestellt werden, der verwendet werden kann, um Zwischenansichten für ein Head-Mounted Display 1711 zu rendern. Head-Mounted Display-Positionsinformationen 1716 werden als Feedback dem Zwischenansichtsrenderer 1714 bereitgestellt, der aktualisierte Ansichten für das angezeigte Ansichtsfenster rendern kann, das über das Head-Mounted Display 1711 präsentiert wird.
18A-18B stellen ein System zum Codieren und Decodieren von texturierten 6DoF-Geometriedaten dar. 18A zeigt ein Codiersystem 1800 für texturierte 6DoF-Geometrie. 18B zeigt ein Decodiersystem 1820 für texturierte 6DoF-Geometrie. Codierung und Decodierung von texturierter 6DoF-Geometrie kann verwendet werden, um eine Variante von immersivem 6DoF-Video zu ermöglichen, in dem Videodaten als Textur für Geometriedaten angewandt werden, so dass neue Zwischenansichten auf der Basis der Position und Orientierung eines Head-Mounted Displays gerendert werden können. Von mehreren Videokameras aufgezeichnete Daten können insbesondere für statische Objekte mit 3D-Modellen kombiniert werden.
Wie in 18A gezeigt, kann ein Codiersystem 1800 für texturierte 6DoF-Geometrie Videodaten 1802 für eine Basisansicht und Videodaten 1805A-1705C für zusätzliche Ansichten empfangen. Die Videodaten 1802, 1805A-1805C enthalten Textur- und Tiefendaten, die durch eine Neuprojektions- und Okklusionserkennungseinheit 1806 verarbeitet werden können. Die Ausgabe von der Neuprojektions- und Okklusionserkennungseinheit 1806 kann einer Patchzerlegungseinheit 1807 und einem Geometriebildgenerator 1808 bereitgestellt werden. Die Ausgabe von der Patchzerlegungseinheit 1807 wird einer Patchpackungseinheit 1809 und einem Patch-Zusatzinformationskompressor 1813 bereitgestellt. Die Patch-Zusatzinformationen (Patch-Info) liefern Informationen, die verwendet werden, um Patches von Videotextur- und Tiefendaten zu rekonstruieren.
Die Patchpackungseinheit 1809 gibt gepackte Patchdaten an den Geometriebildgenerator 1808, einen Texturbildgenerator 1810, einen Attributbildgenerator 1811 und einen Belegungsplankompressor 1812 aus.
Der Geometriebildgenerator 1808, Texturbildgenerator 1810 und Attributbildgenerator 1811 geben Daten an einen Videokompressor 1814 aus. Der Geometriebildgenerator 1808 kann Eingaben von der Neuprojektions- und Okklusionserkennungseinheit 1806, der Patchzerlegungseinheit 1807 und der Patchpackungseinheit 1809 empfangen und Geometriebilddaten erzeugen. Der Texturbildgenerator 1810 kann gepackte Patchdaten von der Patchpackungseinheit 1809 und Videotextur- und Tiefendaten von der Neuprojektions- und Okklusionserkennungseinheit 1806 empfangen. Der Attributbildgenerator 1811 erzeugt ein Attributbild aus den von der Neuprojektions- und Okklusionserkennungseinheit 1806 empfangenen Videotextur- und Tiefendaten und aus den von der Patchpackungseinheit 1809 empfangenen gepackten Patchdaten.
Ein Belegungsplan kann durch einen Belegungsplankompressor 1812 auf der Basis der von der Patchpackungseinheit 1809 ausgegebenen gepackten Patchdaten erzeugt werden. Patch-Zusatzinformationen können von dem Patch-Zusatzinformationskompressor 1813 erzeugt werden. Komprimierte Belegungsplan- und Patch-Zusatzinformationsdaten können durch einen Multiplexer 1815 zusammen mit komprimierten und/oder codierten Videodaten, die von dem Videokompressor 1814 ausgegeben werden, zu einem komprimierten Bitstream 1816 multiplexiert werden. Die von dem Videokompressor 1814 ausgegebenen komprimierten Videodaten enthalten komprimierte Geometriebilddaten, Texturbilddaten und Attributbilddaten. Der komprimierte Bitstream 1816 kann gespeichert oder einem Client-Gerät für Dekomprimierung und Betrachtung bereitgestellt werden.
Wie in 18B gezeigt, kann ein Decodiersystem 1820 für texturierte 6DoF-Geometrie verwendet werden, um mit Hilfe des Codiersystems 1800 von 18A erzeugte 6DoF-Inhalte zu decodieren. Der komprimierte Bitstream 1816 wird empfangen und von einem Demultiplexer 1835 zu mehreren Videodecodierstreams, einem Belegungsplan und Patch-Zusatzinformationen demultiplexiert. Die mehreren Videostreams werden durch Videodecodierer 1834A-1834B decodiert/dekomprimiert. Die Belegungsplandaten werden durch einen Belegungsplan-Decodierer 1832 decodiert/dekomprimiert. Die decodierten Videodaten und Belegungsplandaten werden von den Videodecodierern 1834A-1834B und dem Belegungsplan-Decodierer 1832 zu einer Entpackungseinheit 1829 ausgegeben. Die Entpackungseinheit entpackt Video-Patchdaten, die durch die Patchpackungseinheit 1809 von 18A gepackt werden. Patch-Zusatzinformationen von dem Patch-Zusatzinfo-Decodierer 1833 werden einer Okklusionsausfülleinheit 1826 bereitgestellt, die verwendet werden kann, um Patches von verdeckten Teilen eines Objekts, das in einer bestimmten Ansicht der Videodaten fehlen kann, auszufüllen. Die jeweiligen Videostreams 1822, 1825A-1825C, die Textur- und Tiefendaten aufweisen, werden von der Okklusionsausfülleinheit 1826 ausgegeben und einem Zwischenansichtsrenderer 1823 bereitgestellt, der eine Ansicht zur Anzeige auf einem Head-Mounted Display 1824 auf der Basis der von dem Head-Mounted Display 1824 bereitgestellten Positions- und Orientierungsinformationen rendern kann.
19A-19B stellen ein System zum Codieren und Decodieren von 6DoF-Punktwolkendaten dar. 19A stellt ein 6DoF-Punktwolken-Codiersystem 1900 dar. 19B stellt ein 6DoF-Punktwolken-Decodiersystem 1920 dar. 6DoF-Video kann unter Verwendung von Punktwolken repräsentiert werden, wobei für eine Punktwolken-Videosequenz in regelmäßigen Zeitintervallen (z. B. 60 Hz) ein neuer Punktwolkenframe vorhanden ist. Jeder Punkt in dem Punktwolkendatenframe wird durch sechs Parameter repräsentiert: (X, Y, Z) Geometrieposition und (R, G, B oder Y, U, V) Texturdaten. In dem Codiersystem 1900 von 19A wird ein Punktwolkenframe auf mehrere zweidimensionale (2D) Ebenen projiziert, wobei jede 2D-Ebene einem Projektionswinkel entspricht. Die Projektionsebenen können den Projektionsebenen 1512 von 15B ähnlich sein. Bei einigen Implementierungen werden sechs Projektionswinkel in dem PCC-Standardtestmodell verwendet, wobei die Projektionswinkel den Winkeln entsprechen, die auf die Mitte der sechs Flächen eines rechteckigen Festkörpers zeigen, die das durch die Punktwolkendaten repräsentierte Objekt begrenzen. Während sechs Projektionswinkel beschrieben werden, könnte möglicherweise eine andere Anzahl von Winkeln in anderen Implementierungen verwendet werden.
Textur- und Tiefen-2D-Bildpatchrepräsentationen werden an jedem Projektionswinkel gebildet. Die 2D-Patchbildrepräsentationen für einen Projektionswinkel können erzeugt werden, indem nur jene Punkte, für die ein Projektionswinkel die nächste Normale hat, projiziert werden. Mit anderen Worten, die 2D-Patchbildrepräsentation wird für die Punkte genommen, die das Skalarprodukt der Punktnormalen und der Ebenennormalen maximieren. Texturpatches von den getrennten Projektionen werden zu einem einzelnen Texturbild kombiniert, das als das Geometriebild bezeichnet wird. Metadaten, welche die Patches repräsentieren, und das Verfahren, wie sie in einen Frame gepackt wurden, werden in dem Belegungsplan und der Patch-Zusatzinfo beschrieben. Die Belegungsplan-Metadaten enthalten eine Angabe dafür, welche Bildprobenpositionen leer sind (z. B. enthalten keine entsprechenden Punktwolkeninformationen). Die Patch-Zusatzinfo gibt die Projektionsebene an, der ein Patch angehört, und kann verwendet werden, um eine mit einer gegebenen Probenposition verbundene Projektionsebene zu bestimmen. Die Texturbilder und Tiefenbilder werden mit Hilfe eines konventionellen 2D-Videocodierers, wie z. B. einem High Efficiency Video Coding (HEVC)-Codierer, codiert. Die Metadaten können mit Hilfe von Metadaten-Codierlogik getrennt komprimiert werden. In dem Testmodell-Decodierer werden die Texturbilder und Tiefenbilder mit Hilfe eines HEVC-Videodecodierers decodiert. Eine Punktwolke wird unter Verwendung der decodierten Textur- und Tiefenbilder zusammen mit dem Belegungsplan und den Patch-Zusatzinfo-Metadaten rekonstruiert.
Wie in 19A gezeigt, kann ein Eingabeframe von Punktwolkendaten zu Patchdaten zerlegt werden. Die Punktwolkendaten und die zerlegten Patchdaten können in einer ähnlichen Weise wie die Videotextur- und Tiefendaten in 18A codiert werden. Eingabedaten, die einen Punktwolkenframe 1906 enthalten, können einer Patchzerlegungseinheit 1907 bereitgestellt werden. Die eingegebenen Punktwolkendaten und deren zerlegte Patches können durch eine Packungseinheit 1909, einen Geometriebildgenerator 1908, einen Texturbildgenerator 1910, einen Attributbildgenerator 1911, einen Belegungsplankompressor 1912 und einen Patch-Zusatzinformationskompressor 1913 unter Verwendung von Techniken verarbeitet werden, die der Verarbeitung von Texturtiefen- und Videodaten, die von der Neuprojektions- und Okklusionserkennungseinheit 1806 und der Patchzerlegungseinheit 1807 von 18A ausgegeben werden, ähnlich sind. Ein Videokompressor 1914 kann Geometriebild-, Texturbild- und Attributbilddaten codieren und/oder komprimieren. Die komprimierten und/oder codierten Videodaten von dem Videokompressor 1914 können durch einen Multiplexer 1915 mit Belegungsplan- und Patch-Zusatzinformationsdaten zu einem komprimierten Bitstream 1916 multiplexiert werden, der zur Anzeige gespeichert oder übertragen werden kann.
Der von dem System 1900 von 19A ausgegebene komprimierte Bitstream kann durch das in 19B gezeigte Punktwolken-Decodiersystem 1920 decodiert werden. Wie in 19B gezeigt, kann ein komprimierter Bitstream 1916 zu mehreren codierten/komprimierten Videostreams, Belegungsplandaten und Patch-Zusatzinformationen demultiplexiert werden. Die Videostreams können durch einen Multi-Stream-Videodecodierer 1934, der Textur- und Geometriedaten ausgeben kann, decodiert/dekomprimiert werden. Belegungsplan- und Patch-Zusatzinformationen können durch einen Belegungsplan-Decodierer 1932 und einen Patch-Zusatzinformations-Decodierer 1933 dekomprimiert/decodiert werden.
Geometrierekonstruktion, Glättung und Texturrekonstruktion können dann durchgeführt werden, um die dem 6DoF-Punktwolken-Codiersystem 1900 von 19A bereitgestellten Punktwolkendaten zu rekonstruieren. Eine Geometrie-Rekonstruktionseinheit 1936 kann Geometrieinformationen auf der Basis der von einem Videostream des Multi-Stream-Videodecodierers 1934 decodierten Geometriedaten sowie der Ausgabe des Belegungsplan-Decodierers 1932 und des Patch-Zusatzinformations-Decodierers 1933 rekonstruieren. Die rekonstruierten Geometriedaten können durch eine Glättungseinheit 1937 geglättet werden. Die geglätteten Geometrie- und Texturbilddaten, die von einem Videostream decodiert wurden, der von dem Multi-Stream-Videodecodierer 1934 ausgegeben wurde, werden einer Textur-Rekonstruktionseinheit 1938 bereitgestellt. Die Textur-Rekonstruktionseinheit 1938 kann eine rekonstruierte Punktwolke 1939 ausgeben, die eine Variante des eingegebenen Punktwolkenframes 1926 ist, der dem 6DoF-Punktwolken-Codiersystem 1900 von 19A bereitgestellt wird.
20 stellt eine Rechenvorrichtung 2000 dar, die einen erweiterten Konstruktions-Pipelinemechanismus („Konstruktionspipeline-Mechanismus“) 2010 gemäß einer Ausführungsform hostet.
Die Rechenvorrichtung 2000 repräsentiert eine Kommunikations- und Datenverarbeitungsvorrichtung, die intelligente tragbare Geräte, Smartphones, Virtual Reality (VR)-Geräte, Head-Mounted Displays (HMDs), mobile Computer, Internet of Things (IoT)-Geräte, Laptop-Computer, Desktop-Computer, Servercomputer usw. einschließt (aber nicht darauf beschränkt ist), und die der Verarbeitungsvorrichtung 100 von 1 ähnlich oder mit ihr identisch sind; dementsprechend werden viele der oben angegebenen Details unter Bezugnahme auf die 1-19B im Folgenden der Kürze, Klarheit und Verständlichkeit halber nicht weiter erörtert oder wiederholt.
Die Rechenvorrichtung 2000 kann ferner (ohne Einschränkungen) eine autonome Maschine oder einen Agenten von künstlicher Intelligenz, wie z. B. einen mechanischen Agenten oder eine solche Maschine, einen elektronischen Agenten oder eine solche Maschine, einen virtuellen Agenten oder eine solche Maschine, einen elektromechanischen Agenten oder eine solche Maschine usw. einschließen.
Beispiele von autonomen Maschinen oder Agenten von künstlicher Intelligenz können (ohne Einschränkung) Roboter, autonome Fahrzeuge (z. B. selbstfahrende Autos, selbstfliegende Flugzeuge, selbstfahrende Boote usw.), autonome Geräte (selbstfahrende Baufahrzeuge, selbsttätige medizinische Geräte usw.) und/oder dergleichen einschließen. In diesem Dokument kann „Rechenvorrichtung“ austauschbar auch als „autonome Maschine“ oder „Agent von künstlicher Intelligenz“ oder einfach als „Roboter“ bezeichnet werden.
Es wird in Erwägung gezogen, dass, obwohl „autonomes Fahrzeug“ und „autonomes Fahren“ im ganzen Dokument in Beziehung gesetzt werden, Ausführungsformen nicht derartig eingeschränkt sind. Zum Beispiel ist „autonomes Fahrzeug“ nicht auf ein Kraftfahrzeug beschränkt, sondern kann eine beliebige Anzahl und Art von autonomen Maschinen einschließen, wie z. B. Roboter, autonome Ausrüstung, autonome Haushaltsgeräte und/oder dergleichen, und eine oder mehrere Aufgaben oder Operationen in Bezug auf solche autonomen Maschinen können austauschbar mit autonomem Fahren in Beziehung gesetzt werden.
Die Rechenvorrichtung 2000 kann ferner (ohne Einschränkungen) große Rechensysteme, wie z. B. Servercomputer, Desktopcomputer usw. einschließen und außerdem Set-Top-Boxen (z. B. Internet-basierte Kabel-TV-Set-Top-Boxen usw.), Global Positioning System (GPS)-basierte Geräte usw. umfassen. Die Rechenvorrichtung 2000 kann mobile Rechenvorrichtungen umfassen, die als Kommunikationsvorrichtungen dienen, wie z. B. Zelltelefone, einschließlich Smartphones, Personal Digital Assistants (PDAs), Tablet-Computer, Laptop-Computer, e-Reader, intelligente Fernsehgeräte, TV-Plattformen, tragbare Geräte (z. B. Brillen, Uhren, Armbänder, Smartcards, Schmuck, Kleidungsstücke usw.), Medienspieler usw. Zum Beispiel kann die Rechenvorrichtung 600 in einer Ausführungsform eine mobile Rechenvorrichtung einschließen, die eine Computer-Plattform verwendet, die eine integrierte Schaltung („IC“) hostet, wie z. B. ein Ein-Chip-System („SoC“ oder „SOC“), die verschiedene Hardware- und/oder Softwarekomponenten der Rechenvorrichtung 2000 auf einem einzigen Chip integriert.
Wie dargestellt, kann die Rechenvorrichtung 2000 in einer Ausführungsform eine beliebige Anzahl und Art von Hardware- und/oder Softwarekomponenten einschließen, wie z. B. (ohne Einschränkung) eine Grafikverarbeitungseinheit („GPU“ oder einfach „Grafikprozessor“) 2014, Grafiktreiber (auch als „GPU-Treiber“, „Grafiktreiberlogik“, „Treiberlogik“, Benutzermodustreiber (UMD), UMD, Benutzermodustreiber-Framework (UMDF), UMDF oder einfach „Treiber“ bezeichnet) 2016, zentrale Verarbeitungseinheit („CPU“ oder einfach „Anwendungsprozessor“) 2012, Speicher 2008, Netzwerkvorrichtungen, Treiber oder dergleichen, sowie Eingabe/Ausgabe-(I/O)-Quellen 2004, wie Touchscreens, Touchpanels, Touchpads, virtuelle oder reguläre Tastaturen, virtuelle oder reguläre Mäuse, Ports, Verbinder usw. Die Rechenvorrichtung 2000 kann ein Betriebssystem (OS) 2006 aufweisen, das als eine Schnittstelle zwischen Hardware und/oder physikalischen Ressourcen der Rechenvorrichtung 2000 und einem Benutzer dient. Es wird in Erwägung gezogen, dass der Grafikprozessor 2014 und der Anwendungsprozessor 2012 ein oder mehrere der Prozessoren 102 von 1 sein können.
Es sei darauf hingewiesen, dass für bestimmte Implementierungen ein weniger oder besser ausgerüstetes System als das oben beschriebene Beispiel zu bevorzugen ist. Daher kann die Konfiguration der Rechenvorrichtung 2000 von einer Implementierung zur anderen abhängig von zahlreichen Faktoren, wie z. B. Preisbeschränkungen, Leistungsanforderungen, technologischen Verbesserungen oder sonstigen Umständen, variieren.
Ausführungsformen können als beliebige oder als Kombination der folgenden Punkte implementiert werden: ein oder mehrere Mikrochips oder integrierte Schaltungen durch eine Parent-Platine verbunden, festverdrahtete Logik, von einer Speichervorrichtung gespeicherte und von einem Mikroprozessor ausgeführte Software, Firmware, eine anwendungsspezifische integrierte Schaltung (ASIC) und/oder ein feldprogrammierbares Gate-Array (FPGA). Die Begriffe „Logik“, „Modul”. „Komponente“, „Engine“, „Mechanismus“, „Werkzeug“, „Schaltung“ und „Schaltkreise“ werden im ganzen Dokument austauschbar referenziert und schließen als Beispiel Software, Hardware, Firmware oder eine beliebige Kombination davon ein.
In einer Ausführungsform kann der Konstruktionspipeline-Mechanismus 2010, wie dargestellt, von dem Speicher 2008 der Rechenvorrichtung 2000 gehostet werden. In einer anderen Ausführungsform kann der Konstruktionspipeline-Mechanismus 2010 von dem Betriebssystem 2006 oder dem Grafiktreiber 2016 gehostet werden. In noch einer anderen Ausführungsform kann der Konstruktionspipeline-Mechanismus 2010 von einer Grafikverarbeitungseinheit („GPU“ oder einfach „Grafikprozessor“) 2014 oder einer Firmware des Grafikprozessors 2014 gehostet werden oder Teil davon sein. Zum Beispiel kann der Konstruktionspipeline-Mechanismus 2010 in die Verarbeitungshardware des Grafikprozessors 2014 eingebettet sein oder als Teil davon implementiert sein. In ähnlicher Weise kann in noch einer weiteren Ausführungsform der Konstruktionspipeline-Mechanismus 2010 von einer zentralen Verarbeitungseinheit („CPU“ oder einfach „Anwendungsprozessor“) 2012 gehostet werden oder Teil davon sein. Zum Beispiel kann der Konstruktionspipeline-Mechanismus 2010 in die Verarbeitungshardware des Anwendungsprozessors 2012 eingebettet sein oder als Teil davon implementiert sein.
In noch einer anderen Ausführungsform kann der Konstruktionspipeline-Mechanismus 2010 von einer beliebigen Anzahl und Art von Komponenten der Rechenvorrichtung 2000 gehostet werden oder ein Teil davon sein, so wie ein Abschnitt des Konstruktionspipeline-Mechanismus 2010 von einem Betriebssystem 2006 gehostet werden oder ein Teil davon sein kann, ein anderer Abschnitt von einem Grafikprozessor 2014 gehostet werden oder ein Teil davon sein kann, ein anderer Abschnitt von einem Anwendungsprozessor 2012 gehostet werden oder ein Teil davon sein kann, während ein oder mehrere Abschnitte des Konstruktionspipeline-Mechanismus 2010 von dem Betriebssystem 2006 und/oder einer beliebigen Anzahl und Art von Vorrichtungen der Rechenvorrichtung 2000 gehostet werden oder Teil davon sein können. Es wird in Erwägung gezogen, dass Ausführungsformen nicht auf irgendeine Implementierung oder ein Hosting des Konstruktionspipeline-Mechanismus 2010 beschränkt sind, und dass ein oder mehrere Abschnitte oder Komponenten des Konstruktionspipeline-Mechanismus 2010 als Hardware, Software, oder eine beliebige Kombination davon, wie z. B. Firmware, verwendet oder implementiert werden können.
Die Rechenvorrichtung 2000 kann Netzwerk-Schnittstellen hosten, um Zugang zu einem Netzwerk, wie z. B. einem LAN, einem Wide Area Network (WAN), einem Metropolitan Area Network (MAN), einem Personal Area Network (PAN), Bluetooth, einem Cloud-Netzwerk, einem mobilen Netzwerk (z. B. 3. Generation (3G), 4. Generation (4G) usw.), einem Intranet, dem Internet usw. bereitzustellen. Die Netzwerk-Schnittstellen können zum Beispiel eine Drahtlosnetzwerk-Schnittstelle mit Antenne umfassen, die eine oder mehrere Antennen repräsentieren kann. Netzwerk-Schnittstellen können zum Beispiel auch eine Kabelnetzwerk-Schnittstelle aufweisen, um mit Remote-Geräten über ein Netzwerkkabel zu kommunizieren, das zum Beispiel ein Ethernet-Kabel, ein Koaxialkabel, ein Glasfaserkabel, ein serielles Kabel oder ein paralleles Kabel sein kann.
Ausführungsformen können zum Beispiel als ein Computerprogrammprodukt bereitgestellt sein, das ein oder mehrere maschinenlesbare Medien aufweisen kann, auf denen maschinenausführbare Befehle gespeichert sind, die, wenn sie von ein oder mehreren Maschinen, wie z. B. einem Computer, einem Netzwerk von Computern oder anderen elektronischen Geräten, ausgeführt werden, bewirken können, dass die ein oder mehreren Maschinen Operationen im Einklang mit hierin beschriebenen Ausführungsformen ausführen. Ein maschinenlesbares Medium kann Disketten, optische Discs, CD-ROMs (Compact Disc-Read Only Memories) und magneto-optische Disks, ROMs, RAMs, EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetische oder optische Karten, Flash-Speicher oder andere Arten von Medien/maschinenlesbaren Medien, die zum Speichern von maschinenausführbaren Befehlen geeignet sind, umfassen, ohne darauf beschränkt zu sein.
Darüber hinaus können Ausführungsformen als ein Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem Remote-Computer (z. B. einem Server) zu einem anfordernden Computer (z. B. einem Client) über ein oder mehrere Datensignale übertragen werden kann, die in einer Trägerwelle oder einem anderen Ausbreitungsmedium über eine Kommunikationsverbindung (z. B. einem Modem und/oder einer Netzwerkverbindung) enthalten sind und/oder davon moduliert werden.
Im gesamten Dokument kann der Begriff „Benutzer“ austauschbar als „Betrachter“, „Beobachter“, „Person“, „Individuum“, „Endbenutzer“ und/oder dergleichen bezeichnet werden. Es sei darauf hingewiesen, dass im ganzen Dokument Begriffe wie „Grafikdomäne“ mit „Grafikverarbeitungseinheit“, „Grafikprozessor“ oder einfach „GPU“ austauschbar bezeichnet sein kann, und dass in ähnlicher Weise „CPU-Domäne“ oder „Hostdomäne“ mit „Computerverarbeitungseinheit“, „Anwendungsprozessor“ oder einfach „CPU“ austauschbar bezeichnet sein können.
Es sei darauf hingewiesen, dass Begriffe wie „Knoten“, „Berechnungsknoten“, „Server“, „Servereinrichtung“, „Cloud-Computer“, „Cloud-Server“, „Cloud-Servercomputer“, „Maschine“, „Hostmaschine“, „Vorrichtung“, „Rechenvorrichtung“, „Computer“, „Rechnersystem“ und dergleichen im ganzen Dokument austauschbar verwendet werden können. Es sei ferner darauf hingewiesen, dass Begriffe wie „Anwendung“, „Software-Anwendung“, „Programm“, „Software-Programm“, „Paket“, „Software-Paket“ und dergleichen im ganzen Dokument austauschbar verwendet werden können. Auch Begriffe wie „Job“, „Eingabe“, „Anforderung“, „Nachricht“ und dergleichen können im ganzen Dokument austauschbar verwendet werden.
21 stellt einen Konstruktions-Pipelinemechanismus für erweiterte immersive Medien 2010 von 20 und einen Render-Pipelinemechanismus für erweiterte immersive Medien 2160 gemäß einer Ausführungsform dar. Der Kürze halber werden viele der Details, die bereits unter Bezugnahme auf die 1-20 erläutert wurden, nicht wiederholt oder im Folgenden erläutert. In einer Ausführungsform kann der Konstruktionspipeline-Mechanismus 2010 eine beliebige Anzahl und Art von Komponenten umfassen, wie z. B. (aber nicht beschränkt auf): Erkennungs- und Auswahllogik 2101; Logik für Extraktion von semantischen Daten („Extraktionslogik“) 2103; Modellbildungslogik 2105; Kommunikations-/Kompatibilitätslogik 2107; Codierlogik 2109; und Codebuch- und Klassifizierungslogik 2111.
Wie in einer Ausführungsform dargestellt, steht die Rechenvorrichtung 2000 (auch als „Servercomputer“ oder „Konstruktionsvorrichtung“ bezeichnet) auf der Erfassungsseite oder Konstruktionsseite in Kommunikation mit einer weiteren Rechenvorrichtung 2150 (auch als „Clientcomputer“ oder „Rendervorrichtung“ bezeichnet) auf der Renderseite, wobei die Rendervorrichtung 2150 einen Speicher 2158 enthält, der einen Renderpipeline-Mechanismus für erweiterte immersive Medien („Renderpipeline-Mechanismus“) 2160 hostet, der ein beliebige Anzahl und Art von Komponenten aufweist, wie z. B. (aber nicht beschränkt auf): Erkennungs- und Empfangslogik 2161; Decodierlogik 2163; Interpretationslogik für semantische Daten („Interpretationslogik“) 2165; Korrektur- und Renderinglogik 2167; und Kommunikations-/Anzeigelogik 2169. Die Rendervorrichtung 2150 enthält ferner einen Grafikprozessor 2154 und einen Anwendungsprozessor 2152 in Kommunikation mit dem Speicher 2158, um den Renderpipeline-Mechanismus 2160 auszuführen, wobei die Rendervorrichtung 2150 ferner eine Benutzerschnittstelle 2159 und E/A-Komponenten 2156, wie z. B. eine Anzeigevorrichtung zum Anzeigen von immersiven Medien, wie z. B. 3DoF+-Video, 6DoF-Video usw., aufweist.
Es wird ferner gezeigt, dass die Konstruktionsvorrichtung 2000 in Kommunikation mit ein oder mehreren Repositories, Datensätzen und/oder Datenbanken, wie etwa den Datenbanken 2030 (z. B. Cloud-Speicherung, Nicht-Cloud-Speicherung usw.), steht, wobei die Datenbanken 2030 in einem lokalen Speicher oder einem Remote-Speicher über Kommunikationsmedien 2025, wie z. B. ein oder mehreren Netzwerken (z. B. Cloud-Netzwerk, Proximity-Netzwerk, mobiles Netzwerk, Intranet, Internet usw.), residieren können.
Es wird in Erwägung gezogen, dass eine auf der Rechenvorrichtung 2000 laufende Software-Anwendung verantwortlich zur Durchführung oder Unterstützung der Durchführung einer beliebigen Anzahl und Art von Aufgaben sein kann, die ein oder mehrere Komponenten (z. B. GPU 2014, Grafiktreiber 2016, CPU 2012 usw.) der Rechenvorrichtung 2000 verwenden. Wenn solche Aufgaben durchgeführt werden, wie durch die Software-Anwendung definiert, können ein oder mehrere Komponenten, wie z. B. GPU 2014, Grafiktreiber 2016, CPU 2012 usw., miteinander kommunizieren, um eine genaue und rechtzeitige Verarbeitung und Vollendung dieser Aufgaben zu gewährleisten.
Ausführungsformen sorgen für eine neuartige Technik mit Hilfe des erweiterten Pipeline-Mechanismus 2010, um semantische Informationen für die Korrektur von Artefakten, die Klarheit von Objekten und/oder dergleichen zu extrahieren, zu interpretieren und anzuwenden. In einer Ausführungsform, wie z. B. der eines Texturabbilds, können semantische Informationen während der Erfassung und Konstruktion extrahiert oder erzeugt und gesendet werden, um die Korrektur von Artefakten auf der Renderseite zu unterstützen. Außerdem können diese semantischen Informationen auf der Erfassungsseite prognostiziert und als Metadaten gesendet werden, um Farben und Texturen auf der Renderseite zu normalisieren. Zum Beispiel können semantische Informationen Beleuchtungseigenschaften, Klangeigenschaften, semantische Etikettierung von Objekten und/oder Personen usw. einschließen (müssen aber nicht darauf beschränkt sein).
Ausführungsformen sorgen ferner für eine neuartige Technik zum Zuordnen von Texturgrenzen auf der Basis der Erkennung von Objekten in einer Szene. Zum Beispiel kann ein Objekt (z. B. ein menschliches Gesicht) auf der Basis seiner Erkennung erfasst, erkannt und mit Texturgrenzen versehen werden, um zu vermeiden, dass Grenzen über das Gesicht oder einen anderen wichtigen Bereich einer Einheit gezogen werden, wo Fehler besonders sichtbar sind.
Ausführungsformen sorgen ferner für eine neuartige Technik zum Erweitern der Konstruktion einer Punktwolke durch Verschmelzen von Al-basierter Klassifizierung und Segmentierung von Bildobjekten. In einer Ausführungsform können Codebuch-Stichobjekteigenschaften verwendet werden, um die Klarheit von Objekten zur Renderzeit zu erhöhen, wobei Objekteigenschaften Mattigkeit, Glanz, Textur usw. durch erweiterte Kommunikation zwischen einer Konstruktionsseite und einer Renderseite einschließen können (aber nicht darauf beschränkt sein müssen).
In einer Ausführungsform kann der erweiterte Pipeline-Mechanismus 2010 durch ein oder mehrere Verarbeitungsvorrichtungen, wie z. B. ein oder mehrere eines Grafikprozessors 2014 und eines Anwendungsprozessors 1512 usw., ausgeführt werden, um ein oder mehrere zusätzliche Verarbeitungsblöcke bereitzustellen, um eine Codier- und Decodier-Pipeline („immersive Medien-Pipeline“) für immersive Medienerlebnisse, wie z. B. Einbeziehung von immersivem 3DoF+-Video, immersivem 6DoF-Video usw., zu erweitern.
Die konventionelle Pipeline, wie sie unter Bezugnahme auf 22A dargestellt ist, sammelt Kamerafeeds aus mehreren Winkeln und bildet ein dreidimensionales (3D) Modell der Feeds. Dieses 3D-Modell kann dann in bestimmten Weisen, wie z. B. Punktwolkenrepräsentation, repräsentiert und codiert werden. Solche Repräsentationen und Codierungen stellen eine verlustbehaftete Komprimierung dar, die Artefakte in den von einem 3D-Renderer erzeugten endgültigen Inhalt einführen. Diese Artefakte können in der Form von farbigem Rauschen auf Teilen des Inhalts (z. B. Salz-und-Pfeffer-Rauschen auf Oberflächen), Verzerrungen in der 3D-Geometrie von Objekten, fehlenden Bereichen in der 3D-Geometrie usw. vorliegen. Diese konventionelle Pipeline und ihre Techniken sind nicht in der Lage, solche Artefakte zu korrigieren.
Ausführungsformen sorgen für eine neuartige Technik zum Sammeln von semantischen Informationen während der Erfassung von Inhalten durch Kameras und zum Verwenden der semantischen Informationen, um konventionelle Artefakte auf der Renderseite zu korrigieren. Außerdem können diese gesammelten semantischen Informationen verwendet werden, um Inhalte intelligenter zu nutzen.
Zum Beispiel kann die Erkennungs- und Auswahllogik 2101 verwendet werden, um Inhalte, wie z. B. Bilder oder Videos von Objekten (z. B. Menschen, Bäume, Möbel, Autos usw.), die von ein oder mehreren Kameras erfasst werden, wie z. B. Kamera A 2181, Kamera B 2183, Kamera C 2185 und Kamera N 2187, in Kommunikation mit der Konstruktionsvorrichtung 2000 zu erkennen. Es wird in Erwägung gezogen, dass Ausführungsformen nicht auf irgendeine Anzahl oder Art von Kameras beschränkt sind, auch nicht auf die Art, wie die Kameras 2181-2187 in Kommunikation mit der Konstruktionsvorrichtung 2000 stehen, indem z. B. ein oder mehrere Kameras 2181-2187 unabhängig angeordnet, oder ein Teil von E/A-Quellen 2004, oder ein Teil einer anderen Rechenvorrichtung in Kommunikation mit der Konstruktionsvorrichtung 2000 sein können.
Nachdem der Inhalt (z. B. Szenen, die Bilder von Objekten usw. aufweisen) durch ein oder mehrere Kamerafeeds, die von ein oder mehreren Kameras 2181-2187 erfasst werden, gesammelt worden ist, wird der Inhalt dann auf die Modellbildungslogik 2105 übertragen, um ein 3D-Modell des erfassten Inhalts zu bilden. In einer Ausführungsform ist diese 3D-Modellbildung jedoch auf semantischen Daten basiert, die mit Hilfe von Extraktionslogik 2103 extrahiert und auf die Modellbildungslogik 2105 übertragen werden. In einer Ausführungsform kann die Extraktionslogik 2103 während der Erfassung von Szenen durch die Kameras 2181-2187 ausgelöst werden, um gleichzeitig semantische Daten zu sammeln, die dann verwendet werden können, um das 3D-Modell mit Hilfe der Modellbildungslogik 2105 zu bilden.
In einer Ausführungsform werden die mittels Extraktion gewonnenen semantischen Daten auf intelligente Weise für die 3D-Modellbildung verwendet, um etwaige Artefakte in dem erfassten Inhalt zu korrigieren, wenn der Inhalt mit Hilfe der Renderlogik 2167 auf der Rendervorrichtung 2150 gerendert wird. Außerdem werden die semantischen Daten auf intelligente Weise zum Codieren des Inhalts durch einen Codierer mit Hilfe der Codierlogik 2109 verwendet.
Extraktion von semantischen Daten
Inhalt von semantischen Daten. In einer Ausführungsform kann die Extraktion der semantischen Daten durch eine Extraktionslogik 2103 erleichtert werden, wobei die semantischen Daten semantische Segmentierung von individuellen Kamerafeeds, die den Kameras 2181-2187 entsprechen, in vorbestimmte Objektklassen enthalten können. Diese Objektklassen können alltägliche Objekte, wie z. B. Tisch, Stuhl, Bodenmatte, Wand, menschliche Körperteile, wie Gesicht, Haar, Haut, Beine usw., einschließen (ohne darauf beschränkt zu sein), wobei nahezu alles in der Welt, das als Etikett zum Annotieren eines Videofeeds angesehen und verwendet werden könnte, als eine semantische Klasse betrachtet werden kann; außerdem kann jede Art von Material (z. B. Stoff, Stahl, Holz usw.) solcher Objekte ebenfalls prognostiziert werden. Semantische Segmentierung zielt darauf ab, jeden Pixel in einem gegebenen Bild mit einem semantischen Klassenetikett zu etikettieren. Beispielsweise enthält sie dichte Informationen in Bezug auf Objektgrenzen sowie Objektklassen, während Annotation weiter gehen kann, um Dinge, wie menschliche Gesichter, Schall absorbierende oder reflektierende Eigenschaften von Oberflächen, Licht emittierende oder reflektierende Eigenschaften von Oberflächen, Prognostizieren von Lichtquellen in den Bildern und/oder dergleichen zu identifizieren.
Codieren von semantischen Daten. Außerdem können die semantischen Daten nach der 3D-Modellbildung durch die Modellbildungslogik 2105 durch die Codierlogik 2109 codiert werden, so dass die semantischen Daten, wie auf der Inhaltserfassungsseite an der Konstruktionsvorrichtung 2000 erfasst und prognostiziert, als Metadaten betrachtet und durch einen Codierer codiert werden können, wie durch die Codierlogik 2109 ermöglicht, und zwar in einer Weise, wie Texturabbildungen codiert werden. Außerdem werden Kennungen von semantischen Daten in einer Ausführungsform mit Hilfe der Codebuch- und Klassifizierungslogik 2111 in einem Codebuch verwaltet, wobei das Codebuch universal ist, so dass die Codierung mit einer minimalen Anzahl von erforderlichen Bits erfolgt, ohne dass zusätzliche Daten während der Codierung der semantischen Daten gepackt werden müssen. Ausführungsformen sind nicht beschränkt in Bezug darauf, wo das Codebuch residiert, so dass es Teil der Konstruktionsvorrichtung 2000 sein kann oder in einer Datenbank 2160 oder der Rendervorrichtung 2150 auf der Renderseite gespeichert sein kann. Zum Beispiel kann die Konstruktionsseite oder Erfassungsseite das Codebuch als Teil der Decodierroutinen aufweisen, oder es kann am Anfang der Renderung von einem zentralen Servercomputer angefordert werden, wo der Inhalt gestreamt werden kann.
Intelligente Codierung unter Verwendung von semantischen Daten. Außerdem kann Codierung von einer 3D-Modell-Punktwolkenrepräsentation mit Hilfe der Codierlogik 2109 auf mehrere Arten durchgeführt werden.
Zum Beispiel kann projektionsbasierte Codierung auf der Auswahl der Projektionsfläche, der Patchsegmentierung usw. basiert sein, wobei die Auswahl der Projektionsflächen und Patches für die Codierung verwendet werden kann, um Artefakte zu minimieren, wenn der Inhalt von einem Decodierer und mit Hilfe von Decodierlogik 2163 decodiert wird, nachdem der Inhalt und die semantischen Daten durch die Erkennungs- und Empfangslogik 2161 von der Kommunikations-/Kompatibilitätslogik 2107 empfangen worden sind.
In einer Ausführungsform können Optimierungskriterien für Codierungszwecke verwendet werden, wobei die Optimierungskriterien ein oder mehrere der Minimierung der Größe des codierten Inhalts, Minimierung des Projektionsfehlers und Minimierung der durch Auswählen der Projektions- und/oder Patchgrenzen in bestimmten Teilen der Inhalte, wie z. B. menschlichen Gesichtern, eingeführten Fehler einschließen können. Zum Beispiel kann die Kenntnis von semantischen Klassen, wie z. B. menschliche Gesichter, verwendet werden, um das oben genannte dritte Optimierungskriterium, wie z. B. Minimierung der Fehler, anzuwenden und zu erzielen.
Zum Beispiel kann herkömmlicherweise die Aufspaltung eines Bilds eines menschlichen Gesichts in mehrere Patches zu Artefakten in dem menschlichen Gesicht führen, wenn die Texturen zusammengefügt und unter Verwendung der Anzeigevorrichtung gerendert werden. In einer Ausführungsform, wie durch den Konstruktionspipeline-Mechanismus 2010 und/oder den Renderpipeline-Mechanismus 2160 ermöglicht, wird das 3D-Modell für Bereiche von Interesse eines Objekts (z. B. menschliches Gesicht) analysiert, und dann wird eine Texturabbildung erzeugt, um die Bereiche von Interesse des Objekts intakt zu halten, wodurch Artefakte in jedem der Bereiche von Interesse eliminiert oder zumindest erheblich reduziert werden.
Interpretation von semantischen Daten
Normalisieren von Farben und Texturen. Unterdessen, an der Rendervorrichtung 2150 auf der Renderseite, werden die semantischen Daten und die zugehörigen Inhalte (einschließlich jeglicher Artefakte) von der Konstruktionsvorrichtung 2000 durch die Erkennungs- und Empfangslogik 2161 empfangen, unter Verwendung eines Decodierers mit Hilfe der Decodierlogik 2163 decodiert, und dann unter Verwendung der Interpretationslogik 2165 interpretiert. Es wird in Erwägung gezogen, dass einige der Artefakte in der Form von Salz-und-Pfeffer-Rauschen auf Oberflächen, die scheinbar homogen sind, wie etwa im Falle von menschlicher Haut, empfangen werden. Zum Beispiel kann eine Metadatenabbildung zeigen, welche Pixel zu dem Objekt gehören, basierend auf bestimmten Eigenschaften, wie etwa menschlicher Haut (basierend auf einem Code des Farbtons der Haut), die dann verwendet werden können, um Pixel zu korrigieren, die als Rauschen in dem Objekt betrachtet werden (wie etwa Flecken oder Teile, die nicht identisch oder zu unterschiedlich oder zu weit entfernt von dem Hautton sind), während ähnliche Korrekturen auf Oberflächen vorgenommen werden können, die zu der gleichen semantischen Klasse gehören, um Farben und Texturen der Objekte des Inhalts zu normalisieren.
In einer Ausführungsform, wie durch die Interpretationslogik 2165 ermöglicht, können Haben und Interpretieren von semantischen Daten, die mit Lichtquellen verbunden sind (wie etwa Informationen, die auf Ort, Intensität, Richtung, Temperatur usw. bezogen sind), und Objektgeometrie auf intelligente Weise angewandt werden, um Artefakte zu korrigieren, zum Beispiel durch Kenntnis, wo die Schatten sein würden, und wie sie die Farben und Texturen von Objekten beeinflussen mögen. Ein beispielhafter Pseudocode ist nachstehend dargestellt, wobei alle durch die Erkennungs- und Empfangslogik 2161 an der Rendervorrichtung 2150 empfangenen Metadaten in einer durch semanticClasses indizierten Liste gesammelt werden, wobei Modellieren der semantischen Klasse die Anwendung von Informationen beispielsweise auf Objektgeometrie, Art des Oberflächenmaterials, Lichtquellen und Lichtstärken in dem Raum (um z. B. realistische Schatten zu prognostizieren), Codebücher über semantische Klassen, die Weltwissen über sie ausführen, usw., mit sich bringen kann.
for each semanticClass in semanticClasses:
model_s = model (SemanticClass, micslnfoOnSemanticClass)
for each pixel_patch in semanticClass:
correct_if_noise(pixel, model_s)
Ausfüllen der Lücken. Es wird in Erwägung gezogen, dass decodierte Inhalte dennoch Lücken in der 3D-Geometrie der Objekte als Okklusionen enthalten können, zum Beispiel wenn eventuell ein Teil des Kleids einer Frau zum Zeitpunkt des Renderns der Inhalte fehlt. In einer Ausführungsform werden die semantischen Daten auf Pro-Pixel-Ebene interpretiert, um dann zum Prognostizieren verwendet zu werden, wie fehlende Oberflächen, wie etwa das Kleid der Frau, erscheinen mögen, und ferner kann die Interpretationslogik 2165 durch Haben und Anwenden dieser Kenntnisse ermitteln, welche Pixel zu dem Objekt, wie etwa dem Kleid, gehören, und die mit dem fehlenden Teil verbundene semantische Klasse identifizieren (z. B. dass die Lücke von Kleidpixeln umgeben sein kann usw.). Auf diese Weise kann in einer Ausführungsform unter Verwendung der Korrektur- und Renderinglogik 2167 jede Oberfläche mit Lücken erneuert oder repariert werden, indem durch Haben und Interpretieren der Kenntnisse enthüllt wird, wie der Rest des Kleides erscheinen oder aussehen würde. Es wird in Erwägung gezogen, dass Ausführungsformen nicht auf irgendeine Art oder Anzahl von Objekten bezogen ist, und dass diese neuartige Technik auf Objekte verschiedener Arten, wie z. B. menschliches Gesicht, menschliche Haut, Haare, Boote, Bäume, Kleider, Maschinen, Natur, Tiere und ein beliebiges anderes der alltäglichen Objekte usw., angewandt werden kann.
Korrektur von Verzerrungen.
Es wird in Erwägung gezogen, dass der Inhalt mehrere Verzerrungen aufweisen kann, die vor dem Rendern des Inhalts behoben werden müssen. In einer Ausführungsform können etwaige Verzerrungen, die mit irgendeinem der Objekte in dem Inhalt verbunden sind, zuerst durch die Erkennungs- und Empfangslogik 2161 erkannt werden, und dann werden solche Verzerrungen unter Verwendung der relevanten semantischen Daten über die Objekte, welche die Verzerrungen aufweisen, mit Hilfe der Korrektur- und Renderinglogik 2167 korrigiert.
In einer Ausführungsform kann ein Maschinenlernmodell mit verzerrten und nicht verzerrten Objekten trainiert werden, um zu lernen, wie verzerrte Objekte unter Verwendung der Erkennungs- und Auswahllogik 2101 zu erkennen sind.
Zum Beispiel kann ein Maschinenlernmodell im Laufe der Zeit aufgebaut und trainiert werden, indem es mit Proben von verzerrten und akkuraten Objekten gefüttert wird, bis das Modell völlig austrainiert und in der Lage ist, Verzerrungen an jedem Objekt zu erkennen und zu identifizieren, und in einer Ausführungsform wird dann die Erkennungs- und Empfangslogik 2161 verwendet, um solche Verzerrungen auf der Basis dieses trainierten und effizienten Maschinenlernmodells und von ihm unterstützt zu erkennen. Es wird in Erwägung gezogen, dass Ausführungsformen nicht auf irgendeine Art oder Anzahl von Objekten beschränkt ist, und dass Maschinenlernmodelle trainiert sein können, um als Prädiktoren für beliebige reale Objekte zu dienen, ganz gleich, ob sie lebende Objekte (z. B. Menschen, Pflanzen, Tiere usw.) oder nicht lebende Objekte (z. B. Maschinen, Steine usw.) sind.
Nachdem die Verzerrungen durch die Erkennungs- und Empfangslogik 2161 erkannt worden sind, werden jegliche verfügbaren relevanten semantischen Daten durch die Interpretationslogik 2165 interpretiert und durch die Korrektur- und Renderinglogik 2167 angewandt, um die Verzerrungen zu korrigieren, zum Beispiel durch Ausfüllen der Lücken, wie oben beschrieben, wobei Verzerrungen als Lücken betrachtet und bezeichnet werden können. Außerdem kann in einer Ausführungsform selbst eine Verzerrung gewisse Informationen enthalten, die verwendet werden können, um etwas über den verzerrten Bereich zu erfahren, und um sie dann zusammen mit relevanten semantischen Daten anzuwenden, um die Verzerrung zu beheben. Wenn zum Beispiel die rechte Seite eines verzerrten Gesichts nach unten links verlagert ist, können verschiedene Teile oder Abschnitte des Gesichts durch die Erkennungs- und Auswahllogik 2101 erkannt werden, um dann unter Verwendung der Korrektur- und Renderinglogik 2167 wiederhergestellt oder korrigiert zu werden. Diese Kenntnisse können dann angewandt werden, um Maschinenlernmodelle zu trainieren und zu benutzen, um Lückenprognosen in Objekten durchzuführen.
In einer Ausführungsform wird durch Verwenden der neuartigen erweiterten immersiven Medien-Pipeline die Konstruktion einer Punktwolke verbessert, indem AI-basierte Bildobjektklassifizierung, z. B. durch Trainieren und Anwenden von Maschinenlernmodellen, mit Hilfe der Codebuch- und Klassifizierungslogik 2111 verschmolzen werden. Zum Beispiel können Codebuch-Stichobjekteigenschaften verwendet werden, um die Klarheit von Objekten beim Rendern zu verbessern, wobei die Objekteigenschaften Mattigkeit, Glanz, Textur usw. einschließen können (ohne darauf beschränkt zu sein). Zum Beispiel können semantische Daten verwendet werden, um Eigenschaften, wie Punktwolkenkontext, Bild- und/oder Objektklassifizierung und/oder Segmentierung, und semantische Codebucheigenschaften auf der Konstruktionsseite an der Konstruktionsvorrichtung 2000 (ohne darauf beschränkt zu sein) zu erhalten oder zu erlernen und dann anzuwenden , wobei einige dieser Eigenschaften in Datenbanken 2030 gespeichert sein können. In einer Ausführungsform können auf der Renderseite, z. B. an der Rendervorrichtung 2150, Eigenschaften wie Punktwolkenkontext verwendet und mit semantischen Codebucheigenschaften kombiniert werden, um Objekt- und/oder Bildrekonstruktion zu erhalten, um ein Renderingobjekt zu produzieren, das dann durch die Korrektur- und Renderinglogik 2167 gerendert wird, wobei das Objekt unter Verwendung von ein oder mehreren Anzeigevorrichtungen angezeigt wird, die in die Rendervorrichtung 2150 integriert sind oder mit ihr in Kommunikation stehen.
Die Kommunikations-/Kompatibilitätslogik 2107 kann verwendet werden, um die benötigte Kommunikation und Kompatibilität zwischen einer beliebigen Anzahl von Geräten der Konstruktionsvorrichtung 2000 und verschiedenen Komponenten des Konstruktionspipeline-Mechanismus 2110 zu erleichtern. Ebenso kann die Kommunikations-/Anzeigelogik 2169 verwendet werden, um die Kommunikation und Kompatibilität zwischen den verschiedenen Komponenten der Rendervorrichtung 2150 und des Renderpipeline-Mechanismus 2160 zu erleichtern.
Die Kommunikations-/Kompatibilitätslogik 2107 kann verwendet werden, um dynamische Kommunikation und Kompatibilität zwischen der Konstruktionsvorrichtung 2000 und einer beliebigen Anzahl und Art von anderen Rechenvorrichtungen wie den folgenden zu erleichtern: (wie z. B. mobile Rechenvorrichtung, Desktop-Computer, Server-Rechenvorrichtung usw.); Verarbeitungsvorrichtungen oder -komponenten (wie z. B. CPUs, GPUs usw.); Aufnahme-/Wahrnehmungs-/Erkennungsvorrichtungen (wie z. B. Aufnahme-/Wahrnehmungskomponenten einschließlich Kameras, Tiefenmesskameras, Kamerasensoren, Rot-Grün-Blau (RGB)-Sensoren, Mikrofone usw.); Anzeigevorrichtungen (wie z. B. Ausgabekomponenten einschließlich Anzeigebildschirmen, Anzeigeflächen, Anzeigeprojektoren usw.); Benutzer/Kontext-Wahrnehmungskomponenten und/oder Identifizierungs-/Verifizierungssensoren/-vorrichtungen (wie z. B. biometrische Sensoren/Detektoren, Scanner usw.); Datenbanken 2130, wie z. B. Speicher oder Speichervorrichtungen, Datenbanken und/oder Datenquellen (wie z. B. Datenspeichervorrichtungen, Festplattenlaufwerke, Festkörperlaufwerke, Festplatten, Speicherkarten oder -vorrichtungen, Speicherschaltungen usw.); Kommunikationsmedien 2125, wie z. B. ein oder mehrere Kommunikationskanäle oder Netzwerke (z. B. Cloud-Netzwerk, das Internet, Intranet, Mobilfunknetze, Proximity-Netzwerke, wie z. B. Bluetooth, Bluetooth Low Energy (BLE), Bluetooth Smart, Wi-Fi Proximity, Radio Frequency Identification (RFID), Near Field Communication (NFC), Body Area Network (BAN) usw.); drahtlose oder verdrahtete Kommunikation und relevante Protokolle (z. B., Wi-Fi®, WiMAX, Ethernet usw.); Konnektivitäts- und Lokalisierungsmanagementtechniken; Software-Anwendungen/Websites (z. B. Sozial- und/oder Geschäftsnetz-Websites, usw., Geschäftsanwendungen, Spiele und andere Unterhaltungsanwendungen usw.); und Programmiersprachen usw., währen Kompatibilität mit sich ändernden Technologien, Parametern, Protokollen, Standards usw. gewährleistet wird.
In diesem Dokument werden Begriffe wie „Logik“, „Komponente“, „Modul“, „Framework“, „Engine“, „Mechanismus“, „Schaltung“, „Schaltkreise“ und/oder dergleichen austauschbar verwendet und können zum Beispiel Software, Hardware, Firmware oder eine beliebige Kombination davon einschließen. In einem Beispiel kann „Logik“ eine Software-Komponente bezeichnen oder enthalten, die mit ein oder mehreren eines Betriebssystems (z. B. dem Betriebssystem 2006), einem Grafiktreiber (z. B. dem Grafiktreiber 2016) usw. einer Rechenvorrichtung, wie z. B. der Konstruktionsvorrichtung 2000 arbeitet. In einem anderen Beispiel kann „Logik“ eine Hardwarekomponente bezeichnen oder einschließen, die physisch zusammen mit oder als Teil von einem oder mehreren System-Hardwareelementen installiert werden kann, wie z. B. einem Anwendungsprozessor (z. B. CPU 2012), einem Grafikprozessor (z. B. GPU 2014) usw. einer Rechenvorrichtung, wie der Rechenvorrichtung 2000. In noch einer anderen Ausführungsform kann „Logik“ eine Firmware-Komponente bezeichnen oder einschließen, die Teil einer System-Firmware sein kann, wie z. B. einer Firmware eines Anwendungsprozessors (z. B. CPU 2012) oder eines Grafikprozessors (z. B. GPU 2014) usw. einer Rechenvorrichtung, wie der Rechenvorrichtung 2000. Mit anderen Worten, „Logik“ kann selbst die Schaltkreise oder Hardware-Komponente sein oder enthalten, um bestimmte Aufgaben durchzuführen oder bestimmte Schaltkreise oder Hardware-Komponenten unterstützen, um bestimmte Aufgaben durchzuführen oder von ein oder mehreren Prozessoren, wie z. B. dem Grafikprozessor 2014, dem Anwendungsprozessor 2012 usw. ausgeführt werden, um bestimmte Aufgaben durchzuführen.
Außerdem sollte jeder Gebrauch einer bestimmten Marke, eines Worts, eines Begriffs, einer Phrase, eines Namens und/oder einer Abkürzung, wie z. B. „Rekonstruktion“, „Punktwolken-Rekonstruktion“, „grobe visuelle Hülle“, „feine visuelle Hülle“, „Distanzfeld und Normale“, „Sichtbarkeit“, „Foto-Kohärenz“, „Glätte“, „Ausgabe“, „GPU“, „GPU-Domäne“, „GPGPU“, „CPU“, „CPU-Domäne“, „Grafiktreiber“, „Arbeitslast“, „Anwendung“, „Grafik-Pipeline“, „Pipeline-Prozesse“, „Register“, „Registerdatei“, „RF“, „erweiterte Registerdatei“, „ERF“, „Ausführungseinheit“, „AE“, „Befehl“, „API“, „3D-API“, „OpenGL®“, „DirectX®“, „Fragment-Shader“, „YUV-Textur“, „Shader-Ausführung“, „existierende UAV-Fähigkeiten“, „existierendes Back-End“, „Hardware“, „Software“, „Agent“, „Grafiktreiber“, „Kernmodus-Grafiktreiber“, „Benutzermodustreiber“, „Benutzermodus-Treiber-Framework“, „Puffer“, „Grafikpuffer“, „Aufgabe“, „Prozess“, „Operation“, „Software-Anwendung“, „Spiel“ usw. nicht so verstanden werden, dass Ausführungsformen auf Software oder Vorrichtungen beschränkt sind, welche die Bezeichnung in Produkten oder in Literatur außerhalb dieses Dokuments tragen.
Es wird in Betracht gezogen, dass eine beliebige Anzahl und Art von Komponenten dem Konstruktionspipeline-Mechanismus 2010 und/oder dem Renderpipeline-Mechanismus 2150 hinzugefügt und/oder daraus entfernt werden kann, um verschiedene Ausführungsformen zu ermöglichen, einschließlich Hinzufügen, Entfernen und/oder Verbessern bestimmter Merkmale. Der Kürze, der Klarheit und des leichten Verständnisses des Konstruktionspipeline-Mechanismus 2010 halber sind viele der standardmäßigen und/oder bekannten Komponenten, wie diejenigen einer Rechenvorrichtung, hier nicht dargestellt oder erläutert. Es wird in Betracht gezogen, dass Ausführungsformen, wie hierin beschrieben, nicht auf eine Technologie, eine Topologie, ein System, eine Architektur und/oder einen Standard beschränkt sind und dynamisch genug sind, um zukünftige Änderungen anzunehmen und sich daran anzupassen.
22 stellt eine konventionelle Pipeline 2200 dar, die eine konventionelle Technik anwendet. Wie dargestellt, ist die konventionelle Pipeline 2200 darauf beschränkt, Kamerafeeds von den Kameras 2201, 2203 zu erhalten und die Feeds für 3D-Modellbildung bei 2209 weiterzuleiten, gefolgt von Codierung des Inhalts bei 2211, basierend auf den Kamerafeeds, die nun in einem 3D-Modellformat vorliegen. Dieser codierte Inhalt wird dann von einem ersten Computer über das Netzwerk 2213 zu einem zweiten Computer weitergeleitet, wobei an dem zweiten Computer der codierte Inhalt bei 2215 decodiert wird. Mit dieser konventionellen Pipeline 2200 sind jegliche Repräsentation und Codierung des Inhalts an dem ersten Computer auf verlustbehafteter Kompression basiert, die Artefakte in dem endgültigen Inhalt an dem zweiten Computer einführt, wobei der endgültige Inhalt durch 3D-Rendering des decodierten Inhalts bei 2217 erzeugt wird. Dieses 3D-Rendering des Inhalts wird dann zum Anzeigen auf der Anzeigevorrichtung 2219 übermittelt.
Es wird in Erwägung gezogen, dass die Artefakte von dieser konventionellen Pipeline 2200 in der Regel in der Form von farbigem Rauschen auf Teilen des endgültigen Inhalts (z. B. Salz-und-Pfeffer-Rauschen auf Oberflächen), Verzerrungen in der 3D-Geometrie von Objekten, fehlenden Bereichen in der 3D-Geometrie usw. vorliegen. Diese konventionelle Pipeline und ihre Techniken sind nicht in der Lage, solche Artefakte zu korrigieren.
23A stellt eine erweiterte immersive Medien-Pipeline 2300 gemäß einer Ausführungsform dar. Der Kürze halber werden viele der Details, die bereits unter Bezugnahme auf die 1-22 erörtert wurden, im Folgenden möglicherweise nicht erläutert oder wiederholt. Jegliche Prozesse in Bezug auf eine Transaktionssequenz, die an oder durch die erweiterte Pipeline 2300 durchgeführt werden, können von einer Verarbeitungslogik, die Hardware (z. B. Schaltungen, dedizierte Logik, programmierbare Logik usw.), Software (wie z. B. auf einer Verarbeitungsvorrichtung ausgeführte Anweisungen) oder eine Kombination daraus umfassen kann, wie durch den Konstruktionspipeline-Mechanismus 2010 von 20 und dem Renderpipeline-Mechanismus 2160 von 21 ermöglicht, durchgeführt werden. Die mit der Transaktionssequenz verbundenen Prozesse können der Kürze und Klarheit der Präsentation halber in linearen Sequenzen dargestellt oder wiedergegeben werden; es wird jedoch in Erwägung gezogen, dass eine beliebige Anzahl von ihnen parallel, asynchron oder in verschiedenen Reihenfolgen ausgeführt werden kann.
In der dargestellten Ausführungsform werden ein oder mehrere Kamerafeeds von und durch ein oder mehrere Kameras A 2181, B 2183, C 2185, N 2187 aufgenommen und empfangen, wobei die Kamerafeeds Inhalte von Szenen von Objekten (jegliche lebenden oder nicht lebenden Dinge in der Natur, Umwelt usw.) enthalten, wobei solche Inhalte dann weitergeleitet werden, um bei 2301 zu einem 3D-Modell formatiert zu werden, wie durch die Modellbildungslogik 2105 von 21 ermöglicht, und dann bei 2303 durch einen Codierer mit Hilfe der Codierlogik 2109 von 21 codiert zu werden.
Wie unter Bezugnahme auf 21 beschrieben, werden in einer Ausführungsform ein oder mehrere 3D-Modellbildungen bei 2309 und Codierungen bei 2311 unter Verwendung von semantischen Daten, die bei 2321 mit Hilfe der Extraktionslogik 2103 von 21 extrahiert werden, durchgeführt. Zum Beispiel können spezifische Informationen oder Eigenschaften in Bezug auf Objekte (z. B. Menschen, Maschinen, Pflanzen, Tiere, Gebäude, Schuhe usw.) auf eine oder mehrere Arten extrahiert werden, indem sie z. B. unter Verwendung von ein oder mehreren Kameras 2301 direkt aufgenommen, von den Kamerafeeds extrahiert und/oder durch antrainierte Maschinenlernmodelle usw. erhalten werden.
Zum Beispiel können in einer Ausführungsform semantische Daten auf Segmentierung jedes Kamerafeeds in vorbestimmte Objektklassen basiert sein, wobei eine Objektklasse eine beliebige Anzahl und Art von alltäglichen Objekten, wie etwa Tisch, Stuhl, Pflege, Fußboden, Berg, Zug, Wand, menschliches Gesicht, Haare, Haut, Nägel, Augen, Arme usw., einschließen kann. Außerdem können semantische Klassen verwendet werden, um andere relevante Informationen über diese Objekte zu erhalten, wie etwa die Art des Materials eines Objekts, z. B. Stahl, Stoff, Holz, menschliche Haut usw. Diese semantischen Klassen können verwendet werden, um die Objekte von den Kamerafeeds zu annotieren, wie etwa ein aus Stahl hergestelltes Werkzeug, ein aus Baumwolle hergestelltes Hemd, ein aus Holz hergestellter Tisch, die Farbe der Haut, der Haare oder der Augen einer Person usw. Diese Annotationen können dann für Identifizierung und andere Zwecke verwendet werden, z. B. genaues Identifizieren von Objekten, wie etwa ein menschliches Gesicht, absorbierende oder reflektierende Eigenschaften von verschiedenen Oberflächen, und sogar zum Prognostizieren von Lichtquellen in Bildern usw.
In einer Ausführungsform werden die semantischen Daten und alle ihre Merkmale, wie z. B. Objektklassen, Annotationen usw., während der 3D-Modellbildung bei 2301 und der Codierung bei 2303 bestimmt und verwendet. Diese codierten Inhalte, die semantische Daten enthalten und darauf basieren, werden dann von einer Konstruktionsvorrichtung, wie etwa der Konstruktionsvorrichtung 2000 von 20 auf der Konstruktionsseite 2331 zu einer Rendervorrichtung, wie etwa der Rendervorrichtung 2150 von 21 auf der Renderseite 2333 über das Netzwerk 2125 (z. B. Internet, Cloud-Netzwerk, Proximity-Netzwerk usw.) weitergeleitet.
Nach dem Empfangen der codierten Inhalte auf der Renderseite 2333 werden die codierten Inhalte dann bei 2305 durch einen Decodierer mit Hilfe der Decodierlogik 2163 von 21 decodiert. Nachdem die Inhalte decodiert worden sind, werden die decodierten semantischen Daten von den decodierten Inhalten bei 2323 mit Hilfe der Interpretationslogik 2165 von 21 interpretiert. In einer Ausführungsform werden die interpretierten semantischen Daten und der Rest der decodierten Inhalte bei 2307 mit Hilfe der Korrektur- und Renderinglogik 2167 von 21 für 3D-Rendering vorbereitet. In einer Ausführungsform, wie durch die Korrektur- und Renderinglogik 2167 von 21 ermöglicht, beinhaltet der Prozess des 3D-Rendering bei 2307 die Nutzung der interpretierten semantischen Daten zum Korrigieren etwaiger Artefakte, Lücken, Verzerrungen usw. der decodierten Inhalte, welche die Kamerafeeds repräsentieren. Zum Beispiel kann die Korrektur von Artefakten, Lücken, Verzerrungen usw. in decodierten Inhalten das Normalisieren von Farben und Texturen, das Ausfüllen von Lücken, die Korrektur von Verzerrungen und/oder dergleichen beinhalten.
Es wird dann erlaubt, dieses korrigierte 3D-Rendering der Inhalte auf ein oder mehreren Anzeigevorrichtungen/-bildschirmen, wie z. B. einem HMD 2309, einem Lichtfelddisplay 2311 usw., der Rendervorrichtung, wie z. B. der Rendervorrichtung 2150 von 21 und/oder derjenigen von ein oder mehreren Rechenvorrichtungen, wie z. B. mobilen Rechenvorrichtungen, tragbaren intelligenten Geräten usw., zu rendern.
23B stellt eine erweiterte immersive Medien-Pipeline 2350 gemäß einer Ausführungsform dar. Der Kürze halber werden viele der Details, die bereits unter Bezugnahme auf die 1-23A erörtert wurden, nicht weiter erörtert oder wiederholt. Jegliche Prozesse in Bezug auf eine Transaktionssequenz, die an oder durch die erweiterte Pipeline 2300 durchgeführt werden, können von einer Verarbeitungslogik, die Hardware (z. B. Schaltungen, dedizierte Logik, programmierbare Logik usw.), Software (wie z. B. auf einer Verarbeitungsvorrichtung ausgeführte Anweisungen) oder eine Kombination daraus umfassen kann, wie durch den Konstruktionspipeline-Mechanismus 2010 von 20 und dem Renderpipeline-Mechanismus 2160 von 21 ermöglicht, durchgeführt werden. Die mit der Transaktionssequenz verbundenen Prozesse können der Kürze und Klarheit der Präsentation halber in linearen Sequenzen dargestellt oder wiedergegeben werden; es wird jedoch in Erwägung gezogen, dass eine beliebige Anzahl von ihnen parallel, asynchron oder in verschiedenen Reihenfolgen ausgeführt werden kann.
Wie dargestellt, wird in einer Ausführungsform die erweiterte Pipeline 2350 für erweiterte Konstruktion einer Punktwolke durch Verschmelzen eines Al-basierten Bilds und/oder Objektklassifizierung bereitgestellt. Wie oben dargestellt und erörtert, werden Punktwolkenkontext 2351, Bild- und/oder Objektklassifizierungs-Erkennungsinformationen 2353 und semantische Codebucheigenschaften 2355 in der Konstruktionsvorrichtung 2200 auf der Konstruktionsseite gesammelt und verwaltet. Zum Beispiel werden Codebuch-Stichobjekteigenschaften von semantischen Codebucheigenschaften 2355 verwendet, um die Klarheit von Objekten und/oder Bildern zur Renderzeit zu erhöhen, wobei die Objekteigenschaften Materie, Glanz, Textur usw. einschließen können (ohne jedoch darauf beschränkt zu sein).
In einer Ausführungsform können jede Menge und Art von Informationen, die in dem Punktwolkenkontext 2351 enthalten sind, Bild- und/oder Objektklassifizierungs-Erkennungsinformationen 2353 und semantische Codebucheigenschaften 2355 über ein Netzwerk 2125 (z. B. Internet, Cloud-Netzwerk, Proximity-Netzwerk) zu der Rendervorrichtung 2150 auf der Renderseite übermittelt werden. Zum Beispiel kann, wie dargestellt, der Punktwolkenkontext 2357 an der Rendervorrichtung 2150 mit Bild- und/oder Objekt-Rekonstruktionsinformationen 2359 an der Rendervorrichtung 2150 auf der Basis von semantischen Codebucheigenschaften 2355 der Konstruktionsvorrichtung 2200 verwendet werden, um eine Bilder- und/oder Objekte-Renderingversion 2361 zu erzeugen.
Außerdem wird in einer Ausführungsform der Punktwolkenkontext 2351 an der Konstruktionsvorrichtung 2000 optimiert, bevor er als Punktwolkenkontext 2357 zu der Rendervorrichtung 2150 gesendet wird, wobei, in einer Ausführungsform, durch Verwenden von Bild-/Objektklassifizierungs-Erkennungsinformationen 2353 jegliche mit dem Punktwolkenkontext 2351 verbundenen Objekte in einer Weise segmentiert werden, dass durch Klassifizierung identifizierte Regionen oder Bereiche intakt bleiben, und werden dann durch den Punktwolkenkontext 2357 der Rendervorrichtung 2150 angeboten, was zu einer auf den semantischen Codebucheigenschaften 2355 basierenden Bild-/Objektrekonstruktion 2359 führt. In einer Ausführungsform wird diese endgültige oder Renderingversion 2361 von Bildern und/oder Objekten dann durch die Rendervorrichtung 2150 gerendert, um unter Verwendung von ein oder mehreren Anzeigevorrichtungen/-bildschirmen angezeigt zu werden.
24A stellt ein Verfahren 2400 zur Nutzung von semantischen Daten in einer erweiterten immersiven Medien-Pipeline gemäß einer Ausführungsform dar. Der Kürze halber werden viele der Details, die bereits unter Bezugnahme auf die 1-23B erörtert wurden, nicht weiter erörtert oder wiederholt. Jegliche Prozesse in Bezug auf das Verfahren 2400 können von einer Verarbeitungslogik, die Hardware (z. B. Schaltungen, dedizierte Logik, programmierbare Logik usw.), Software (wie z. B. auf einer Verarbeitungsvorrichtung ausgeführte Anweisungen) oder eine Kombination daraus umfassen kann, wie durch den Konstruktionspipeline-Mechanismus 2010 von 20 und dem Renderpipeline-Mechanismus 2160 von 21 ermöglicht, durchgeführt werden. Die mit der Transaktionssequenz verbundenen Prozesse können der Kürze und Klarheit der Präsentation halber in linearen Sequenzen dargestellt oder wiedergegeben werden; es wird jedoch in Erwägung gezogen, dass eine beliebige Anzahl von ihnen parallel, asynchron oder in verschiedenen Reihenfolgen ausgeführt werden kann.
Das Verfahren 2400 beginnt bei Block 2401 mit der Aufnahme von Szenen durch ein oder mehrere Kameras in Kommunikation mit einer Rechenvorrichtung (z. B. Konstruktionsvorrichtung), wobei diese Aufnahme von Szenen als Kamerafeeds betrachteten Inhalt repräsentiert. Bei Block 2403 werden semantische Daten in Bezug auf Objekte, die in den Szenen aufgenommen werden, von dem Inhalt selbst extrahiert, basierend auf bekannten oder ermittelten Eigenschaften, die mit den Objekten verbunden sind. Zum Beispiel können die Stoffart und Farbe eines Hemds, das in einer Szene von einem Objekt, wie z. B. einer Person, getragen wird, als mit der Person verbundene semantische Daten betrachtet werden.
Bei Block 2405 wird in einer Ausführungsform ein 3D-Modell des Inhalts und jeglicher semantischer Daten, die mit einem beliebigen der Objekte des Inhalts verbunden sind, durch 3D-Modellbildung erzeugt.
Außerdem wird in einer Ausführungsform eine Codierung des 3D-Modells (einschließlich des Inhalts und der semantischen Daten) mit Hilfe von ein oder mehreren Codierern bei Block 2407 durchgeführt, wobei diese codierten Informationen des 3D-Modells dann bei Block 2409 über ein oder mehrere Netzwerke, wie z. B. einem Cloud-Netzwerk, das Internet, von der Konstruktionsvorrichtung zu einer anderen Rechenvorrichtung (z. B. der Rendervorrichtung) übertragen werden.
Bei Block 2411 werden nach Empfangen des codierten 3D-Modells an der Rendervorrichtung die codierten Informationen an der Rendervorrichtung mit Hilfe von ein oder mehreren Decodierern decodiert, wobei die decodierten Informationen decodierte semantische Daten und decodierte Szeneninhalte, einschließlich der Objekte, enthalten. Bei Block 2413 werden in einer Ausführungsform die semantischen Daten dann interpretiert, um zum Korrigieren der verschiedenen mit den Objekten verbundenen Verzerrungen verwendet zu werden, wobei solche Verzerrungen Artefakte, Lücken usw. einschließen können. Bei Block 2415 werden jegliche vorherigen Informationen über die Objekte, die von den interpretierten semantischen Daten erhalten wurden, zum Korrigieren der verschiedenen Verzerrungen in Objekten verwendet, zum Beispiel durch Anwenden der genauen Informationen über die von den semantischen Daten erhaltenen Objekte, zum Beispiel durch Normalisieren der Farben und Texturen der Objekte, Ausfüllen der Lücken in Objekten usw. Bei Block 2417 wird ein 3D-Rendering der Szenen unter Verwendung der decodierten Inhalte einschließlich verzerrungsfreier Objekte auf der Basis der interpretierten semantischen Daten erzeugt. Bei Block 2419 werden die Szenen mit Hilfe der Rendervorrichtung gerendert, einschließlich Anzeigen der Szenen zum Betrachten durch Benutzer, unter Verwendung von ein oder mehreren mit der Rendervorrichtung verbundenen Vorrichtungen.
24B stellt ein Verfahren 2450 zur Nutzung von Codebucheigenschaften in einer erweiterten immersiven Medien-Pipeline gemäß einer Ausführungsform dar. Der Kürze halber werden viele der Details, die bereits unter Bezugnahme auf die 1-24A erörtert wurden, nicht weiter erörtert oder wiederholt. Jegliche Prozesse in Bezug auf das Verfahren 2450 können von einer Verarbeitungslogik, die Hardware (z. B. Schaltungen, dedizierte Logik, programmierbare Logik usw.), Software (wie z. B. auf einer Verarbeitungsvorrichtung ausgeführte Anweisungen) oder eine Kombination daraus umfassen kann, wie durch den Konstruktionspipeline-Mechanismus 2010 von 20 und dem Renderpipeline-Mechanismus 2160 von 21 ermöglicht, durchgeführt werden. Die mit der Transaktionssequenz verbundenen Prozesse können der Kürze und Klarheit der Präsentation halber in linearen Sequenzen dargestellt oder wiedergegeben werden; es wird jedoch in Erwägung gezogen, dass eine beliebige Anzahl von ihnen parallel, asynchron oder in verschiedenen Reihenfolgen ausgeführt werden kann.
Das Verfahren 2450 beginnt bei Block 2451 mit der Bestimmung der semantischen Codebucheigenschaften von Objekten in Bildern einer Szene, die von ein oder mehreren Kameras aufgenommen wurde, die mit einer Rechenvorrichtung, wie z. B. einer Konstruktionsvorrichtung, verbunden sind oder damit in Kommunikation stehen. In einer Ausführungsform werden die mit Objekten verbundenen semantischen Codebucheigenschaften verwendet, um die Konstruktion einer Punktwolke durch Verschmelzen der Al-basierten Bild- und/oder Objektklassifizierung zu verbessern. Zum Beispiel können die Codebucheigenschaften eine beliebige Anzahl und Art von mit Objekten verbundenen Eigenschaften, wie etwa Materie, Glanz, Textur der Oberfläche eines Objekts usw., einschließen. Diese Codebucheigenschaften werden in einem Codebuch verwaltet und können bei Block 2453 neben Punktwolkenkontext und Bild- und/oder Objektklassifizierungs-Erkennungsinformationen usw. in einer mit der Konstruktionsvorrichtung verbundenen Datenbank gespeichert werden. Bei Block 2455 werden das Codebuch und andere Informationen, wie z. B. Bild- und/oder Objektklassifizierungsinformationen usw., über ein Netzwerk (z. B. Cloud-Netzwerk, Internet usw.) zu einer Rendervorrichtung übertragen.
In einer Ausführungsform können semantische Codebucheigenschaften, wie vorher beschriebene semantische Daten, dann mit Punktwolkenkontext, Bild- und/oder Objektklassifizierungserkennung usw. verwendet werden, um eine Rekonstruktion des Bilds und/oder Objekts auf dem Rendercomputer bei Block 2457 bereitzustellen. Diese Bild- und/oder Objektrekonstruktion wird dann verwendet, um bei Block 2459 eine Renderingversion der Objekte aus der Szene zu erzeugen, wobei diese Renderingversion bei Block 2461 durch die Rendervorrichtung unter Verwendung von ein oder mehreren Anzeigevorrichtungen gerendert und angezeigt wird.
Verweise auf „eine einzelne Ausführungsform“, „eine Ausführungsform“, „Ausführungsbeispiel“, „verschiedene Ausführungsformen“ und dergleichen zeigen an, dass die so beschriebene(n) Ausführungsform(en) bestimmte Merkmale, Strukturen oder Charakteristiken beinhalten kann/können, wobei allerdings nicht jede Ausführungsform notwendigerweise die bestimmten Merkmale, Strukturen oder Charakteristiken beinhaltet. Ferner können manche Ausführungsformen einige, alle oder keine der für andere Ausführungsformen beschriebenen Merkmale aufweisen.
In der vorstehenden Spezifikation sind Ausführungsformen unter Bezugnahme auf spezifische beispielhafte Ausführungsformen davon beschrieben worden. Es ist jedoch offensichtlich, dass verschiedene Modifikationen und Änderungen daran gemacht werden können, ohne von dem breiteren Sinn und Schutzbereich der Ausführungsformen abzuweichen, wie in den angehängten Ansprüchen dargelegt. Die Spezifikationen und Zeichnungen sind dementsprechend vielmehr in einem illustrativen als in einem einschränkenden Sinn zu betrachten.
In der folgenden Beschreibung und in den Ansprüchen kann der Begriff „gekoppelt“ zusammen mit seinen Ableitungen verwendet werden. „Gekoppelt“ wird verwendet, um anzuzeigen, dass zwei oder mehrere Elemente kooperieren oder miteinander interagieren, aber sie können dazwischenliegende physische oder elektrische Komponenten zwischen ihnen haben oder nicht.
Wie in den Ansprüchen verwendet, wenn nicht anders angegeben, zeigt der Gebrauch der Ordnungsadjektive „erste“, „zweite“, „dritte“ usw. zum Beschreiben eines gemeinsamen Elements lediglich an, dass unterschiedliche Beispiele von gleichen Elementen genannt werden, und es ist nicht beabsichtigt zu unterstellen, dass die so beschriebenen Elemente in einer gegebenen Folge, sei es zeitlich, räumlich, in Rang oder in irgendeiner anderen Weise, angeordnet sein müssen.
Die folgenden Bestimmungen und/oder Beispiele betreffen weitere Ausführungsformen oder Beispiele. Einzelheiten in den Beispielen können an irgendeiner Stelle in ein oder mehreren Ausführungsformen verwendet werden. Die verschiedenen Merkmale der unterschiedlichen Ausführungsformen oder Beispiele können verschiedenartig mit einigen eingeschlossenen und anderen ausgeschlossenen Merkmalen kombiniert werden, um einer Vielfalt von unterschiedlichen Applikationen zu entsprechen. Beispiele können den Gegenstand enthalten, wie z. B. ein Verfahren, Mittel zum Durchführen von Handlungen des Verfahrens, mindestens ein maschinenlesbares Medium, das Befehle enthält, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, Handlungen des Verfahrens durchzuführen, oder von einer Vorrichtung oder einem System zur Unterstützung von Hybridkommunikation gemäß den hierin beschriebenen Ausführungsformen und Beispielen.
Einige Ausführungsformen betreffen Beispiel 1, das eine Vorrichtung zur Unterstützung einer erweiterten immersiven Medien-Pipeline zur Korrektur von Artefakten und der Klarheit von Objekten in Rechenumgebungen einschließt, wobei die Vorrichtung Folgendes umfasst: ein oder mehrere Prozessoren für folgende Aufgaben: Extrahieren von semantischen Daten in Bezug auf Objekte in einer Szene, die durch ein oder mehrere Kameras aufgenommen wurde, wobei die Objekte Verzerrungen aufweisen; Bilden, auf der Basis der semantischen Daten, eines dreidimensionalen (3D) Modells des Inhalts der Szene, wobei der Inhalt die Objekte enthält; Codieren des 3D-Modells einschließlich des Inhalts und der semantischen Daten zu einer codierten Datei, die codierten Inhalt und codierte semantische Daten aufweist; und Übertragen der codierten Datei über eine immersive Medien-Pipeline, um die Korrektur der Verzerrungen zu erleichtern, und Rendern der Szene einschließlich der Objekte ohne die Verzerrungen.
Beispiel 2 enthält den Gegenstand von Beispiel 1, wobei die ein oder mehreren Prozessoren ferner die Aufgabe haben, die Szene und die mit den Objekten verbundenen Verzerrungen zu erkennen, wobei die Verzerrungen Artefakte und Lücken einschließen, wobei der Inhalt der Szene auf immersiven Medieninhalten basiert oder solche Inhalte aufweist, die immersive Videos enthalten.
Beispiel 3 enthält den Gegenstand der Beispiele 1-2, wobei die semantischen Daten mit den Objekten verbundene Eigenschaften umfassen, wobei die Eigenschaften eine oder mehrere von Beleuchtungseigenschaften, Klangeigenschaften und semantischer Kennzeichnung einschließen, wobei die Objekte ein oder mehrere von lebenden Dingen und nicht lebenden Dingen einschließen.
Beispiel 4 enthält den Gegenstand der Beispiele 1-3, wobei die Codebucheigenschaften der Eigenschaften in einem Codebuch in einer Datenbank geführt werden, wobei die Codebucheigenschaften die Aufgabe haben, die Codierung des 3D-Modells mit minimalen Bits zu unterstützen, wobei die Codebucheigenschaften ferner die Aufgabe haben, die Klassifizierung der Objekte, basierend auf ein oder mehreren von Textur, Material und Form, zu unterstützen.
Beispiel 5 enthält den Gegenstand der Beispiele 1-4, wobei die immersiven Videos ein oder mehrere Videos mit drei Freiheitsgraden+ (3DoF+) und Videos mit sechs Freiheitsgraden (6DoF) enthalten, wobei die ein oder mehreren Prozessoren einen oder mehrere eines Grafikprozessors und eines Anwendungsprozessors aufweisen, wobei der Grafik- und der Anwendungsprozessor zusammen auf einem gemeinsamen Halbleitergehäuse angeordnet sind.
Einige Ausführungsformen betreffen Beispiel 6, das eine Vorrichtung zur Unterstützung der erweiterten immersiven Medien-Pipeline zur Korrektur von Artefakten und der Klarheit von Objekten in Rechenumgebungen enthält, wobei die Vorrichtung Folgendes umfasst: einen oder mehrere Prozessoren für folgende Aufgaben: Empfangen einer codierten Datei, die codierten Inhalt und codierte semantische Daten enthält, die mit Objekten in einer Szene verbunden sind; Decodieren des codierten Inhalts und der codierten semantischen Daten jeweils zu einem decodierten Inhalt und decodierten semantischen Daten; Interpretieren der semantischen Daten auf der Basis des Inhalts, einschließlich der Objekte, die Verzerrungen aufweisen; und Korrigieren, auf der Basis der interpretierten semantischen Daten, der mit den Objekten verbundenen Verzerrungen.
Beispiel 7 enthält den Gegenstand von Beispiel 6, wobei die Korrektur der Verzerrungen ein oder mehrere Vorgänge des Normalisierens der Farben und Texturen der Objekte und des Ausfüllens der Lücken in den Objekten umfasst.
Beispiel 8 enthält den Gegenstand der Beispiele 6-7, wobei die ein oder mehreren Prozessoren ferner die Aufgabe haben, eine Renderingversion der Szene bereitzustellen, wobei die Renderingversion die Objekte ohne die Verzerrungen enthält.
Beispiel 9 enthält den Gegenstand der Beispiele 6-8, wobei die ein oder mehreren Prozessoren ferner die Aufgabe haben, die Renderingversion der Szene so zu rendern, dass die Szene zum Betrachten unter Verwendung von ein oder mehreren Anzeigevorrichtungen angezeigt wird, wobei der Inhalt der Szene auf immersiven Medieninhalten basiert oder solche Inhalte aufweist, die immersive Videos enthalten.
Beispiel 10 enthält den Gegenstand der Beispiele 6-9, wobei die immersiven Videos ein oder mehrere Videos mit drei Freiheitsgraden+ (3DoF+) und Videos mit sechs Freiheitsgraden (6DoF) enthalten, wobei die ein oder mehreren Prozessoren einen oder mehrere eines Grafikprozessors und eines Anwendungsprozessors aufweisen, wobei der Grafik- und der Anwendungsprozessor zusammen auf einem gemeinsamen Halbleitergehäuse angeordnet sind.
Einige Ausführungsformen betreffen Beispiel 11, das ein Verfahren zur Unterstützung einer erweiterten immersiven Medien-Pipeline zur Korrektur von Artefakten und der Klarheit von Objekten in Rechenumgebungen einschließt, wobei das Verfahren Folgendes umfasst: Extrahieren von semantischen Daten in Bezug auf Objekte in einer Szene, die durch ein oder mehrere Kameras aufgenommen wurde, wobei die Objekte Verzerrungen aufweisen; Bilden, auf der Basis der semantischen Daten, eines dreidimensionalen (3D) Modells des Inhalts der Szene, wobei der Inhalt die Objekte enthält; Codieren des 3D-Modells einschließlich des Inhalts und der semantischen Daten zu einer codierten Datei, die codierten Inhalt und codierte semantische Daten aufweist; und Übertragen der codierten Datei über eine immersive Medien-Pipeline, um die Korrektur der Verzerrungen zu erleichtern, und Rendern der Szene einschließlich der Objekte ohne die Verzerrungen.
Beispiel 12 enthält den Gegenstand von Beispiel 11, das ferner Erkennen der Szene und der mit den Objekten verbundenen Verzerrungen umfasst, wobei die Verzerrungen Artefakte und Lücken einschließen, wobei der Inhalt der Szene auf immersiven Medieninhalten basiert oder solche Inhalte aufweist, die immersive Videos enthalten.
Beispiel 13 enthält den Gegenstand der Beispiele 11-12, wobei die semantischen Daten mit den Objekten verbundene Eigenschaften umfassen, wobei die Eigenschaften eine oder mehrere von Beleuchtungseigenschaften, Klangeigenschaften und semantischer Kennzeichnung einschließen, wobei die Objekte ein oder mehrere von lebenden Dingen und nicht lebenden Dingen einschließen.
Beispiel 14 enthält den Gegenstand der Beispiele 11-13, wobei die Codebucheigenschaften der Eigenschaften in einem Codebuch in einer Datenbank geführt werden, wobei die Codebucheigenschaften die Aufgabe haben, die Codierung des 3D-Modells mit minimalen Bits zu unterstützen, wobei die Codebucheigenschaften ferner die Aufgabe haben, die Klassifizierung der Objekte, basierend auf ein oder mehreren von Textur, Material und Form, zu unterstützen.
Beispiel 15 enthält den Gegenstand der Beispiele 11-14, wobei die immersiven Videos ein oder mehrere Videos mit drei Freiheitsgraden+ (3DoF+) und Videos mit sechs Freiheitsgraden (6DoF) enthalten, wobei das Verfahren durch ein oder mehrere Prozessoren einer Rechenvorrichtung unterstützt werden, wobei die ein oder mehreren Prozessoren einen oder mehrere eines Grafikprozessors und eines Anwendungsprozessors aufweisen, wobei der Grafik- und der Anwendungsprozessor zusammen auf einem gemeinsamen Halbleitergehäuse der Rechenvorrichtung angeordnet sind.
Einige Ausführungsformen betreffen Beispiel 16, das ein Verfahren zur Unterstützung der erweiterten immersiven Medien-Pipeline zur Korrektur von Artefakten und der Klarheit von Objekten in Rechenumgebungen enthält, wobei das Verfahren Folgendes umfasst: Empfangen einer codierten Datei, die codierten Inhalt und codierte semantische Daten enthält, die mit Objekten in einer Szene verbunden sind; Decodieren des codierten Inhalts und der codierten semantischen Daten jeweils zu einem decodierten Inhalt und decodierten semantischen Daten; Interpretieren der semantischen Daten auf der Basis des Inhalts, einschließlich der Objekte, die Verzerrungen aufweisen; und Korrigieren, auf der Basis der interpretierten semantischen Daten, der mit den Objekten verbundenen Verzerrungen.
Beispiel 17 enthält den Gegenstand von Beispiel 16, wobei die Korrektur der Verzerrungen ein oder mehrere Vorgänge des Normalisierens der Farben und Texturen der Objekte und des Ausfüllens der Lücken in den Objekten umfasst.
Beispiel 18 enthält den Gegenstand der Beispiele 16-17, wobei die ein oder mehreren Prozessoren ferner die Aufgabe haben, eine Renderingversion der Szene bereitzustellen, wobei die Renderingversion die Objekte ohne die Verzerrungen enthält.
Beispiel 19 enthält den Gegenstand der Beispiele 16-18 und umfasst ferner das Rendern der Renderingversion der Szene, so dass die Szene zum Betrachten unter Verwendung von ein oder mehreren Anzeigevorrichtungen angezeigt wird, wobei der Inhalt der Szene auf immersiven Medieninhalten basiert oder solche Inhalte aufweist, die immersive Videos enthalten.
Beispiel 20 enthält den Gegenstand der Beispiele 16-19, wobei die immersiven Videos ein oder mehrere Videos mit drei Freiheitsgraden+ (3DoF+) und Videos mit sechs Freiheitsgraden (6DoF) enthalten, wobei das Verfahren durch ein oder mehrere Prozessoren einer Rechenvorrichtung unterstützt werden, wobei die ein oder mehreren Prozessoren einen oder mehrere eines Grafikprozessors und eines Anwendungsprozessors aufweisen, wobei der Grafik- und der Anwendungsprozessor zusammen auf einem gemeinsamen Halbleitergehäuse der Rechenvorrichtung angeordnet sind.
Einige Ausführungsformen betreffen Beispiel 21, das ein Datenverarbeitungssystem mit einer Verarbeitungsvorrichtung für folgende Aufgaben enthält: Extrahieren von semantischen Daten in Bezug auf Objekte in einer Szene, die durch ein oder mehrere Kameras aufgenommen wurde, wobei die Objekte Verzerrungen aufweisen; Bilden, auf der Basis der semantischen Daten, eines dreidimensionalen (3D) Modells des Inhalts der Szene, wobei der Inhalt die Objekte enthält; Codieren des 3D-Modells einschließlich des Inhalts und der semantischen Daten zu einer codierten Datei, die codierten Inhalt und codierte semantische Daten aufweist; und Übertragen der codierten Datei über eine immersive Medien-Pipeline, um die Korrektur der Verzerrungen und Rendern der Szene einschließlich der Objekte ohne die Verzerrungen zu erleichtern; und einen Speicher, der kommunikativ mit der Verarbeitungsvorrichtung gekoppelt ist.
Beispiel 22 enthält den Gegenstand von Beispiel 21, wobei die Verarbeitungsvorrichtung ferner die Aufgabe hat, die Szene und die mit den Objekten verbundenen Verzerrungen zu erkennen, wobei die Verzerrungen Artefakte und Lücken einschließen, wobei der Inhalt der Szene auf immersiven Medieninhalten basiert oder solche Inhalte aufweist, die immersive Videos enthalten.
Beispiel 23 enthält den Gegenstand der Beispiele 21-22, wobei die semantischen Daten mit den Objekten verbundene Eigenschaften umfassen, wobei die Eigenschaften eine oder mehrere von Beleuchtungseigenschaften, Klangeigenschaften und semantischer Kennzeichnung einschließen, wobei die Objekte ein oder mehrere von lebenden Dingen und nicht lebenden Dingen einschließen.
Beispiel 24 enthält den Gegenstand der Beispiele 21-23, wobei die Codebucheigenschaften der Eigenschaften in einem Codebuch in einer Datenbank geführt werden, wobei die Codebucheigenschaften die Aufgabe haben, die Codierung des 3D-Modells mit minimalen Bits zu unterstützen, wobei die Codebucheigenschaften ferner die Aufgabe haben, die Klassifizierung der Objekte, basierend auf ein oder mehreren von Textur, Material und Form, zu unterstützen.
Beispiel 25 enthält den Gegenstand der Beispiele 21-24, wobei die immersiven Videos ein oder mehrere Videos mit drei Freiheitsgraden+ (3DoF+) und Videos mit sechs Freiheitsgraden (6DoF) enthalten, wobei die Verarbeitungsvorrichtung einen mit einem Anwendungsprozessor gekoppelten Grafikprozessor aufweist, wobei der Grafik- und der Anwendungsprozessor zusammen auf einem gemeinsamen Halbleitergehäuse des Datenverarbeitungssystems angeordnet sind.
Einige Ausführungsformen betreffen Beispiel 26, das ein Datenverarbeitungssystem mit einer Verarbeitungsvorrichtung für folgende Aufgaben enthält: Empfangen einer codierten Datei, die codierten Inhalt und codierte semantische Daten enthält, die mit Objekten in einer Szene verbunden sind; Decodieren des codierten Inhalts und der codierten semantischen Daten jeweils zu einem decodierten Inhalt und decodierten semantischen Daten; Interpretieren der semantischen Daten auf der Basis des Inhalts, einschließlich der Objekte, die Verzerrungen aufweisen; und Korrigieren, auf der Basis der interpretierten semantischen Daten, der mit den Objekten verbundenen Verzerrungen; und einen Speicher, der kommunikativ mit der Verarbeitungsvorrichtung gekoppelt ist.
Beispiel 27 enthält den Gegenstand von Beispiel 26, wobei die Korrektur der Verzerrungen ein oder mehrere Vorgänge des Normalisierens der Farben und Texturen der Objekte und des Ausfüllens der Lücken in den Objekten umfasst.
Beispiel 28 enthält den Gegenstand der Beispiele 26-27, wobei die Verarbeitungsvorrichtung ferner die Aufgabe hat, eine Renderingversion der Szene bereitzustellen, wobei die Renderingversion die Objekte ohne die Verzerrungen enthält.
Beispiel 29 enthält den Gegenstand der Beispiele 26-28, wobei die Verarbeitungsvorrichtung ferner die Aufgabe hat, die Renderingversion der Szene so zu rendern, dass die Szene zum Betrachten unter Verwendung von ein oder mehreren Anzeigevorrichtungen angezeigt wird, wobei der Inhalt der Szene auf immersiven Medieninhalten basiert oder solche Inhalte aufweist, die immersive Videos enthalten.
Beispiel 30 enthält den Gegenstand der Beispiele 26-29, wobei die immersiven Videos ein oder mehrere Videos mit drei Freiheitsgraden+ (3DoF+) und Videos mit sechs Freiheitsgraden (6DoF) enthalten, wobei die Verarbeitungsvorrichtung einen mit einem Anwendungsprozessor gekoppelten Grafikprozessor aufweist, wobei der Grafik- und der Anwendungsprozessor zusammen auf einem gemeinsamen Halbleitergehäuse des Datenverarbeitungssystems angeordnet sind.
Einige Ausführungsformen betreffen Beispiel 31, das eine Vorrichtung zur Unterstützung einer erweiterten immersiven Medien-Pipeline zur Korrektur von Artefakten und der Klarheit von Objekten in Rechenumgebungen einschließt, wobei die Vorrichtung Folgendes umfasst: Mittels zum Extrahieren von semantischen Daten in Bezug auf Objekte in einer Szene, die durch ein oder mehrere Kameras aufgenommen wurde, wobei die Objekte Verzerrungen aufweisen; Mittel zum Bilden, auf der Basis der semantischen Daten, eines dreidimensionalen (3D) Modells des Inhalts der Szene, wobei der Inhalt die Objekte enthält; Mittel zum Codieren des 3D-Modells einschließlich des Inhalts und der semantischen Daten zu einer codierten Datei, die codierten Inhalt und codierte semantische Daten aufweist; und Mittel zum Übertragen der codierten Datei über eine immersive Medien-Pipeline, um die Korrektur der Verzerrungen und Rendern der Szene einschließlich der Objekte ohne die Verzerrungen zu erleichtern.
Beispiel 32 enthält den Gegenstand von Beispiel 31, das ferner Mittel zum Erkennen der Szene und der mit den Objekten verbundenen Verzerrungen umfasst, wobei die Verzerrungen Artefakte und Lücken einschließen, wobei der Inhalt der Szene auf immersiven Medieninhalten basiert oder solche Inhalte aufweist, die immersive Videos enthalten.
Beispiel 33 enthält den Gegenstand der Beispiele 31-32, wobei die semantischen Daten mit den Objekten verbundene Eigenschaften umfassen, wobei die Eigenschaften eine oder mehrere von Beleuchtungseigenschaften, Klangeigenschaften und semantischer Kennzeichnung einschließen, wobei die Objekte ein oder mehrere von lebenden Dingen und nicht lebenden Dingen einschließen.
Beispiel 34 enthält den Gegenstand der Beispiele 31-33, wobei die Codebucheigenschaften der Eigenschaften in einem Codebuch in einer Datenbank geführt werden, wobei die Codebucheigenschaften die Aufgabe haben, die Codierung des 3D-Modells mit minimalen Bits zu unterstützen, wobei die Codebucheigenschaften ferner die Aufgabe haben, die Klassifizierung der Objekte, basierend auf ein oder mehreren von Textur, Material und Form, zu unterstützen.
Beispiel 35 enthält den Gegenstand der Beispiele 31-34, wobei die immersiven Videos ein oder mehrere Videos mit drei Freiheitsgraden+ (3DoF+) und Videos mit sechs Freiheitsgraden (6DoF) enthalten, wobei die Vorrichtung ein oder mehrere Prozessoren umfasst, die einen oder mehrere eines Grafikprozessors und eines Anwendungsprozessors aufweisen, wobei der Grafik- und der Anwendungsprozessor zusammen auf einem gemeinsamen Halbleitergehäuse angeordnet sind.
Einige Ausführungsformen betreffen Beispiel 36, das eine Vorrichtung zur Unterstützung der erweiterten immersiven Medien-Pipeline zur Korrektur von Artefakten und der Klarheit von Objekten in Rechenumgebungen enthält, wobei die Vorrichtung Folgendes umfasst: Mittel zum Empfangen einer codierten Datei, die codierten Inhalt und codierte semantische Daten enthält, die mit Objekten in einer Szene verbunden sind; Mittel zum Decodieren des codierten Inhalts und der codierten semantischen Daten jeweils zu einem decodierten Inhalt und decodierten semantischen Daten; Mittel zum Interpretieren der semantischen Daten auf der Basis des Inhalts, einschließlich der Objekte, die Verzerrungen aufweisen; und Mittel zum Korrigieren, auf der Basis der interpretierten semantischen Daten, der mit den Objekten verbundenen Verzerrungen.
Beispiel 37 enthält den Gegenstand von Beispiel 36, wobei die Korrektur der Verzerrungen ein oder mehrere Vorgänge des Normalisierens der Farben und Texturen der Objekte und des Ausfüllens der Lücken in den Objekten umfasst.
Beispiel 38 enthält den Gegenstand der Beispiele 36-37, wobei die ein oder mehreren Prozessoren ferner die Aufgabe haben, eine Renderingversion der Szene bereitzustellen, wobei die Renderingversion die Objekte ohne die Verzerrungen enthält.
Beispiel 39 enthält den Gegenstand der Beispiele 36-38 und umfasst ferner Mittel zum Rendern der Renderingversion der Szene, so dass die Szene zum Betrachten unter Verwendung von ein oder mehreren Anzeigevorrichtungen angezeigt wird, wobei der Inhalt der Szene auf immersiven Medieninhalten basiert oder solche Inhalte aufweist, die immersive Videos enthalten.
Beispiel 40 enthält den Gegenstand der Beispiele 36-39, wobei die immersiven Videos ein oder mehrere Videos mit drei Freiheitsgraden+ (3DoF+) und Videos mit sechs Freiheitsgraden (6DoF) enthalten, wobei die Vorrichtung ein oder mehrere Prozessoren umfasst, die einen oder mehrere eines Grafikprozessors und eines Anwendungsprozessors aufweisen, wobei der Grafik- und der Anwendungsprozessor zusammen auf einem gemeinsamen Halbleitergehäuse angeordnet sind.
Beispiel 41 beinhaltet mindestens ein nichtflüchtiges oder greifbares maschinenlesbares Medium, das eine Vielzahl von Anweisungen enthält, die, wenn sie auf einer Rechenvorrichtung ausgeführt werden, zum Implementieren oder Ausführen eines Verfahrens nach einem der Ansprüche oder Beispiele 11-20 dienen.
Beispiel 42 beinhaltet mindestens ein maschinenlesbares Medium, das eine Vielzahl von Anweisungen enthält, die, wenn sie auf einer Rechenvorrichtung ausgeführt werden, zum Implementieren oder Ausführen von ein oder mehreren Verfahren nach einem der Ansprüche oder Beispiele 11-20 dienen.
Beispiel 43 beinhaltet ein System, das einen Mechanismus umfasst, der zum Implementieren oder Durchführen von ein oder mehreren Verfahren nach einem der Ansprüche oder Beispiele 11-20 dient.
Beispiel 44 beinhaltet eine Vorrichtung, die Mittel zum Durchführen von ein oder mehreren Verfahren nach einem der Ansprüche oder Beispiele 11-20 umfasst.
Beispiel 45 beinhaltet eine Rechenvorrichtung, die dazu ausgebildet ist, ein oder mehrere Verfahren nach einem der Ansprüche oder Beispiele 11-20 zu implementieren oder durchzuführen.
Beispiel 46 beinhaltet eine Kommunikationsvorrichtung, die dazu ausgebildet ist, ein oder mehrere Verfahren nach einem der Ansprüche oder Beispiele 11-20 zu implementieren oder durchzuführen.
Beispiel 47 beinhaltet mindestens ein maschinenlesbares Medium, das eine Vielzahl von Anweisungen enthält, die, wenn sie auf einer Rechenvorrichtung ausgeführt werden, zum Implementieren oder Durchführen eines Verfahrens oder Realisieren einer Einrichtung nach einem der vorstehenden Ansprüche dienen.
Beispiel 48 beinhaltet mindestens ein nichtflüchtiges oder greifbares maschinenlesbares Medium, das mehrere Anweisungen umfasst, die, wenn sie auf einer Rechenvorrichtung ausgeführt werden, zum Implementieren oder Durchführen eines Verfahrens oder Realisieren einer Einrichtung nach einem der vorstehenden Ansprüche dienen.
Beispiel 49 beinhaltet ein System, das einen Mechanismus zum Implementieren oder Durchführen eines Verfahrens oder Realisieren einer Vorrichtung nach einem der vorstehenden Ansprüche umfasst.
Beispiel 50 beinhaltet eine Vorrichtung, die Mittel zum Durchführen eines Verfahrens nach einem der vorhergehenden Ansprüche umfasst.
Beispiel 51 beinhaltet eine Rechenvorrichtung, die dazu ausgebildet ist, nach einem der vorstehenden Ansprüche ein Verfahren zu implementieren oder durchzuführen, oder eine Vorrichtung zu realisieren.
Beispiel 52 beinhaltet eine Kommunikationsvorrichtung, die dazu ausgebildet ist, nach einem der vorstehenden Ansprüche ein Verfahren zu implementieren oder durchzuführen, oder eine Vorrichtung zu realisieren.
Beispiel 53 beinhaltet eine Kommunikationsvorrichtung, die dazu ausgebildet ist, nach einem der vorstehenden Ansprüche ein Verfahren zu implementieren oder durchzuführen, oder eine Vorrichtung zu realisieren.
Die Zeichnungen und die vorangehende Beschreibung geben Beispiele von Ausführungsformen. Es versteht sich für Fachleute, dass eines oder mehrere der beschriebenen Elemente durchaus zu einem einzelnen funktionalen Element kombiniert werden können. Alternativ dazu können bestimmte Elemente in mehrere funktionale Elemente aufgeteilt werden. Elemente von einer Ausführungsform können zu einer anderen Ausführungsform hinzugefügt werden. Beispielsweise können Reihenfolgen von hier beschriebenen Prozessen geändert werden und sind nicht auf die hier beschriebene Weise beschränkt. Außerdem müssen die Aktionen eines beliebigen Ablaufdiagramms nicht unbedingt in der gezeigten Reihenfolge umgesetzt werden; es müssen auch nicht alle diese Handlungen unbedingt ausgeführt werden. Jene Handlungen, die nicht von anderen Handlungen abhängig sind, können auch parallel zu den anderen Handlungen durchgeführt werden. Der Schutzumfang von Ausführungsformen wird keineswegs durch diese spezifischen Beispiele begrenzt. Zahlreiche Variationen, ob ausdrücklich in der Spezifikation gegeben oder nicht, wie z. B. Unterschiede in Struktur, Dimension und Gebrauch von Material, sind möglich. Der Schutzumfang von Ausführungsformen ist mindestens so breit, wie durch die folgenden Ansprüche gegeben.

Claims

Beansprucht wird:
Vorrichtung zum Unterstützen einer erweiterten immersiven Medien-Pipeline zur Korrektur von Artefakten und der Klarheit von Objekten, wobei die Vorrichtung Folgendes umfasst: einen oder mehrere Prozessoren zum: Extrahieren von semantischen Daten, die sich auf Objekte in einer Szene beziehen, die von ein oder mehreren Kameras aufgenommen wurde, wobei die Objekte Verzerrungen aufweisen; Bilden, basierend auf den semantischen Daten, eines dreidimensionalen (3D) Modells des Inhalts der Szene, wobei der Inhalt die Objekte enthält; Codieren des 3D-Modells, das den Inhalt und die semantischen Daten enthält, zu einer codierten Datei, die codierten Inhalt und codierte semantische Daten aufweist; und Übertragen der codierten Datei über eine immersive Medien-Pipeline, um die Korrektur der Verzerrungen zu unterstützen und die Szene, welche die Objekte enthält, ohne die Verzerrungen zu rendern.
Vorrichtung nach Anspruch 1, wobei die ein oder mehreren Prozessoren ferner die Aufgabe haben, die Szene und die mit den Objekten verbundenen Verzerrungen zu erkennen, wobei die Verzerrungen Artefakte und Lücken einschließen, wobei der Inhalt der Szene auf immersiven Medieninhalten basiert oder solche Inhalte aufweist, die immersive Videos enthalten.
Vorrichtung nach Anspruch 1, wobei die semantischen Daten mit den Objekten verbundene Eigenschaften umfassen, wobei die Eigenschaften eine oder mehrere von Beleuchtungseigenschaften, Klangeigenschaften und semantischer Kennzeichnung einschließen, wobei die Objekte ein oder mehrere von lebenden Dingen und nicht lebenden Dingen einschließen.
Vorrichtung nach Anspruch 3, wobei die Codebucheigenschaften der Eigenschaften in einem Codebuch in einer Datenbank geführt werden, wobei die Codebucheigenschaften die Aufgabe haben, die Codierung des 3D-Modells mit minimalen Bits zu unterstützen, wobei die Codebucheigenschaften ferner die Aufgabe haben, die Klassifizierung der Objekte, basierend auf ein oder mehreren von Textur, Material und Form, zu unterstützen.
Vorrichtung nach Anspruch 2, wobei die immersiven Videos ein oder mehrere Videos mit drei Freiheitsgraden+ (3DoF+) und Videos mit sechs Freiheitsgraden (6DoF) enthalten, wobei die ein oder mehreren Prozessoren einen Grafikprozessor aufweisen, der mit einem Anwendungsprozessor und einem Speicher gekoppelt ist, wobei der Grafik- und der Anwendungsprozessor zusammen auf einem gemeinsamen Halbleitergehäuse angeordnet sind.
Verfahren zum Unterstützen der erweiterten immersiven Medien-Pipeline zur Korrektur von Artefakten und der Klarheit von Objekten, wobei das Verfahren Folgendes umfasst: Extrahieren von semantischen Daten, die sich auf Objekte in einer Szene beziehen, die von ein oder mehreren Kameras aufgenommen wurde, wobei die Objekte Verzerrungen aufweisen; Bilden, basierend auf den semantischen Daten, eines dreidimensionalen (3D) Modells des Inhalts der Szene, wobei der Inhalt die Objekte enthält; Codieren des 3D-Modells, das den Inhalt und die semantischen Daten enthält, zu einer codierten Datei, die codierten Inhalt und codierte semantische Daten aufweist; und Übertragen der codierten Datei über eine immersive Medien-Pipeline, um die Korrektur der Verzerrungen zu unterstützen und die Szene, welche die Objekte enthält, ohne die Verzerrungen zu rendern.
Verfahren nach Anspruch 6, das ferner Erkennen der Szene und der mit den Objekten verbundenen Verzerrungen umfasst, wobei die Verzerrungen Artefakte und Lücken einschließen, wobei der Inhalt der Szene auf immersiven Medieninhalten basiert oder solche Inhalte aufweist, die immersive Videos enthalten.
Verfahren nach Anspruch 6, wobei die semantischen Daten mit den Objekten verbundene Eigenschaften umfassen, wobei die Eigenschaften eine oder mehrere von Beleuchtungseigenschaften, Klangeigenschaften und semantischer Kennzeichnung einschließen, wobei die Objekte ein oder mehrere von lebenden Dingen und nicht lebenden Dingen einschließen.
Verfahren nach Anspruch 8, wobei die Codebucheigenschaften der Eigenschaften in einem Codebuch in einer Datenbank geführt werden, wobei die Codebucheigenschaften die Aufgabe haben, die Codierung des 3D-Modells mit minimalen Bits zu unterstützen, wobei die Codebucheigenschaften ferner die Aufgabe haben, die Klassifizierung der Objekte basierend auf ein oder mehreren von Textur, Material und Form zu unterstützen.
Verfahren nach Anspruch 7, wobei die immersiven Videos ein oder mehrere Videos mit drei Freiheitsgraden+ (3DoF+) und Videos mit sechs Freiheitsgraden (6DoF) enthalten, wobei das Verfahren durch ein oder mehrere Prozessoren einer Rechenvorrichtung unterstützt wird, wobei die ein oder mehreren Prozessoren einen Grafikprozessor aufweisen, der mit einem Anwendungsprozessor und einem Speicher gekoppelt ist, wobei der Grafik- und der Anwendungsprozessor zusammen auf einem gemeinsamen Halbleitergehäuse angeordnet sind.
Maschinenlesbares Medium bzw. maschinenlesbare Medien, das/die eine Vielzahl von Anweisungen umfasst/umfassen, die, wenn sie auf einer Rechenvorrichtung ausgeführt werden, zum Implementieren oder Durchführen eines Verfahrens nach einem der Ansprüche 6-10 dienen.
System, das einen Mechanismus umfasst, der zum Implementieren oder Durchführen eines Verfahrens nach einem der Ansprüche oder Beispiele 6-10 dient.
Vorrichtung, die Mittel zum Durchführen eines Verfahrens nach einem der Ansprüche oder Beispiele 6-10 umfasst.
Rechenvorrichtung, die dazu ausgebildet ist, ein Verfahren nach einem der Ansprüche oder Beispiele 6-10 zu implementieren oder durchzuführen.
Kommunikationsvorrichtung, die dazu ausgebildet ist, ein Verfahren nach einem der Ansprüche oder Beispiele 6-10 zu implementieren oder durchzuführen.