DE102019117469A1

DE102019117469A1 - Videoverarbeitungsmechanismus

Info

Publication number: DE102019117469A1
Application number: DE102019117469.4A
Authority: DE
Inventors: Jill Boyce; Sang-Hee Lee; Scott Janus; Stanley Baran; Michael Apodaca; Prasoonkumar Surti; Srikanth Potluri; Atsuo Kuwahara; Kai Xiao; Jason Tanner; Gokcen Cilingir; Archie Sharma; Jeffrey Tripp; Jason Ross; Barnan Das
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-07-31
Filing date: 2019-06-28
Publication date: 2020-02-06
Also published as: CN110855971A; US20200043121A1; US10846814B2

Abstract

Eine Vorrichtung zum Ermöglichen der Verarbeitung von Videobitstromdaten wird offenbart. Die Vorrichtung schließt einen oder mehrere Prozessoren zum Decodieren von Occupancy-Map-Daten und Hilfs-Patch-Informationen und Generieren einer Mehrzahl von Patch-Video-Frames basierend auf Patch-Daten, die von den Occupancy-Map-Daten und Hilfs-Patch-Informationen decodiert werden, und einen Speicher, der kommunikativ mit dem einen oder den mehreren Prozessoren gekoppelt ist, ein.

Description

VERWANDTE ANMELDUNG
Diese Anmeldung ist verwandt mit der gemeinsam abgetretenen US-Patentanmeldung Seriennummer 16/050,153 mit dem Titel REDUCED RENDERING OF SIX-DEGREE OF FREEDOM VIDEO von Jill Boyce, eingereicht am 31. Juli 2018, deren gesamter Inhalt hierin durch Bezugnahme aufgenommen wird.
GEBIET DER ERFINDUNG
Diese Erfindung betrifft allgemein die Videoverarbeitung und insbesondere die Videoverarbeitung mittels einer Grafikverarbeitungseinheit.
HINTERGRUND DER BESCHREIBUNG
Video mit sechs Freiheitsgraden (6DoF, 6 Degrees of Freedom) ist ein neu entstehender immersiver Videoanwendungsfall, der dem Betrachter ein immersives Medienerlebnis bietet, bei dem der Betrachter den Betrachtungspunkt einer Szene steuert. Das einfachere Video mit drei Freiheitsgraden (3DoF, 3 Degrees of Freedom) (z. B. 360-Grad- oder Panoramavideo) ermöglicht es einem Betrachter, die Orientierung um die X-, Y- und Z-Achse (als Gieren, Nicken und Rollen beschrieben) von einer festen Position aus zu ändern. 6DoF-Video ermöglicht es dem Betrachter, die Position durch Translationsbewegungen entlang der X-, Y- und Z-Achse zu ändern.
6DoF-Video kann unter Verwendung von Punktwolken repräsentiert werden. Das Rendering von Punktwolkendaten ist jedoch rechenintensiv, was es schwierig macht, Punktwolkenvideo mit einer großen Anzahl von Punkten bei hohen Frameraten zu rendern. Ferner sind Punktwolkendatenraten groß, was eine große Speicherungs- oder Übertragungskapazität erfordert.
Figurenliste
So dass die Weise, in der die oben erwähnten Merkmale der vorliegenden Erfindung im Detail verstanden werden können, kann eine speziellere Beschreibung der Erfindung, die oben kurz beschrieben ist, mittels Bezugnahme auf Ausführungsformen gegeben werden, von denen einige in den beigefügten Zeichnungen veranschaulicht sind. Es sei jedoch zu beachten, dass die beigefügten Zeichnungen lediglich typische Ausführungsformen dieser Erfindung veranschaulichen und daher nicht als Einschränkung ihres Schutzbereichs anzusehen sind, da die Erfindung andere gleichermaßen effektive Ausführungsformen zulassen kann.

1 ist ein Blockschaltbild eines Verarbeitungssystems gemäß einer Ausführungsform;
2 ist ein Blockschaltbild eines Prozessors gemäß einer Ausführungsform;
3 ist ein Blockschaltbild eines Grafikprozessors gemäß einer Ausführungsform;
4 ist ein Blockschaltbild einer Grafikverarbeitungs-Engine eines Grafikprozessors gemäß einigen Ausführungsformen;
5 ist ein Blockschaltbild eines Grafikprozessors, der durch eine zusätzliche Ausführungsform bereitgestellt wird;
6A und 6B veranschaulichen eine Thread-Ausführungslogik, die ein Array von Verarbeitungselementen aufweist, die in einigen Ausführungsformen verwendet werden;
7 ist ein Blockschaltbild, das ein Grafikprozessor-Befehlsformat gemäß einigen Ausführungsformen veranschaulicht;
8 ist ein Blockschaltbild eines Grafikprozessors gemäß einer anderen Ausführungsform;
9A und 9B veranschaulichen ein Grafikprozessor-Befehlsformat und eine Befehlssequenz gemäß einigen Ausführungsformen;
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einigen Ausführungsformen;
11A und 11B sind Blockschaltbilder, die ein IP-Kern-Entwicklungssystem gemäß einer Ausführungsform veranschaulichen;
12 ist ein Blockschaltbild, das eine beispielhafte integrierte System-on-a-Chip-Schaltung gemäß einer Ausführungsform veranschaulicht;
13A und 13B sind Blockschaltbilder, die einen zusätzlichen beispielhaften Grafikprozessor veranschaulichen;
14A und 14B sind Blockschaltbilder, die einen zusätzlichen beispielhaften Grafikprozessor einer integrierten System-on-a-Chip-Schaltung gemäß einer Ausführungsform veranschaulichen;
15A veranschaulicht mehrere Formen von immersivem Video;
15B veranschaulicht Bildprojektions- und Texturebenen für immersives Video;
16 veranschaulicht ein Client-Server-System, mit dem immersiver Videoinhalt generiert und durch eine Serverinfrastruktur zur Übertragung an eine oder mehrere Clientvorrichtungen codiert werden kann;
17A-17B veranschaulichen ein System zum Codieren und Decodieren von 3DoF-Plus-lnhalt;
18A-18B veranschaulichen ein System zum Codieren und Decodieren von 6DoF-Inhalt unter Verwendung von texturierten Geometriedaten;
19A-19B veranschaulichen ein System zum Codieren und Decodieren von 6DoF-Inhalt mittels Punktwolkendaten;
20 veranschaulicht eine Rechenvorrichtung, die einen Videoverarbeitungsmechanismus verwendet, gemäß einer Ausführungsform;
21 veranschaulicht eine Ausführungsform eines Videoverarbeitungsmechanism us;
22 ist ein Flussdiagramm, das eine Ausführungsform eines Prozesses zum Durchführen einer Patch-Ausrichtung zur Bewegungsvorhersage veranschaulicht;
23A und 23B veranschaulichen Ausführungsformen von Beweg u ngsvektorfram es;
24 ist ein Flussdiagramm, das eine Ausführungsform eines Prozesses zum Durchführen einer Patch-Grenzenextrapolation veranschaulicht;
25 veranschaulicht verschobene Objekte;
26 ist ein Flussdiagramm, das eine Ausführungsform eines Prozesses zum Entfernen von Punktwolken-Cracking veranschaulicht;
27A veranschaulicht eine Ausführungsform eines Gitters, das auf dekomprimierte Objekte angewendet wird; und
27B veranschaulicht eine Ausführungsform von dekomprimierten Objekten, nachdem ein Gitter angewendet wurde.

DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung sind zahlreiche spezielle Details dargelegt, um ein gründlicheres Verständnis der vorliegenden Erfindung bereitzustellen. Jedoch wird für Fachleute auf dem Gebiet offensichtlich sein, dass die vorliegende Erfindung ohne eines oder mehrere dieser speziellen Details umgesetzt werden kann. In anderen Fällen wurden wohlbekannte Merkmale nicht beschrieben, um ein Verschleiern der vorliegenden Erfindung zu vermeiden.
Systemübersicht
1 ist ein Blockschaltbild eines Verarbeitungssystems 100 gemäß einer Ausführungsform. In verschiedenen Ausführungsformen schließt das System 100 einen oder mehrere Prozessoren 102 und einen oder mehrere Grafikprozessoren 108 ein und kann ein Einzelprozessor-Desktop-System, ein Multiprozessor-Workstation-System oder ein Serversystem mit einer großen Anzahl von Prozessoren 102 oder Prozessorkernen 107 sein. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die innerhalb einer integrierten System-on-a-Chip(SoC)-Schaltung zur Verwendung in Mobil-, Handheld- oder eingebetteten Vorrichtungen integriert ist.
In einer Ausführungsform kann das System 100 eine serverbasierte Spieleplattform, eine Spielekonsole, einschließlich einer Spiele- und Medienkonsole, eine mobile Spielekonsole, eine Handheld-Spielekonsole oder eine Online-Spielekonsole einschließen oder darin integriert sein. In einigen Ausführungsformen ist das System 100 ein Mobiltelefon, ein Smartphone, eine Tablet-Rechenvorrichtung oder eine mobile Internetvorrichtung. Das Verarbeitungssystem 100 kann auch eine tragbare Vorrichtung einschließen, damit gekoppelt oder darin integriert sein, wie beispielsweise eine tragbare Vorrichtung für intelligente Uhren, eine intelligente Brillenvorrichtung, eine Augmented-Reality-Vorrichtung oder eine Virtual-Reality-Vorrichtung. In einigen Ausführungsformen ist das Verarbeitungssystem 100 eine Fernseh- oder Set-Top-Box-Vorrichtung mit einem oder mehreren Prozessoren 102 und einer grafischen Schnittstelle, die von einem oder mehreren Grafikprozessoren 108 generiert wird.
In einigen Ausführungsformen beinhalten der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107, um Anweisungen zu verarbeiten, die, wenn sie ausgeführt werden, Operationen für System- und Benutzersoftware durchführen. In einigen Ausführungsformen ist jeder der einen oder mehreren Prozessorkerne 107 konfiguriert, um einen speziellen Befehlssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Befehlssatz 109 Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC) oder Computing über ein Very Long Instruction Word (VLIW) ermöglichen. Mehrere Prozessorkerne 107 können jeweils einen anderen Befehlssatz 109 verarbeiten, der Anweisungen einschließen kann, um die Emulation anderer Befehlssätze zu ermöglichen. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen aufweisen, wie beispielsweise einen digitalen Signalprozessor (DSP).
In einigen Ausführungsformen weist der Prozessor 102 einen Cachespeicher 104 auf. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Ebenen von internem Cache aufweisen. In einigen Ausführungsformen wird der Cachespeicher von verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z. B. einen Level-3(L3)-Cache oder einen Cache der letzten Ebene (LLC, Last Level Cache)) (nicht gezeigt), der unter Verwendung bekannter Cachekohärenztechniken von den Prozessorkernen 107 gemeinsam genutzt werden kann. Im Prozessor 102 ist zusätzlich eine Registerdatei 106 eingeschlossen, die verschiedene Typen von Registern zum Speichern verschiedener Datentypen aufweisen kann (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Befehlszeigerregister). Einige Register können Allzweck-Register sein, während andere Register speziell für das Design des Prozessors 102 sein können.
In einigen Ausführungsformen sind ein oder mehrere Prozessoren 102 mit einem oder mehreren Schnittstellenbussen 110 gekoppelt, um Kommunikationssignale wie Adressen, Daten oder Steuersignale zwischen dem Prozessor 102 und anderen Komponenten im System 100 zu übertragen. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus sein, wie beispielsweise 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 Typen von Schnittstellenbussen einschließen. In einer Ausführungsform weist/weisen der/die Prozessor(en) 102 einen integrierten Speichercontroller 116 und einen Plattformcontroller-Hub 130 auf. Der Speichercontroller 116 ermöglicht die Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der Plattformcontroller-Hub (PCH) 130 Verbindungen zu E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Speichervorrichtung 120 kann eine Vorrichtung für dynamischen Direktzugriffsspeicher (DRAM, Dynamic Random Access Memory), eine Vorrichtung für statischen Direktzugriffsspeicher (SRAM, Static Random Access Memory), eine Flash-Speichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Speichervorrichtung mit einer geeigneten Leistung sein, 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 Anweisungen 121 zur Verwendung zu speichern, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Der Speichercontroller 116 ist auch mit einem optionalen externen Grafikprozessor 112 gekoppelt, der mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen kann eine Anzeigevorrichtung 111 eine Verbindung zu dem/den Prozessor(en) 102 herstellen. Die Anzeigevorrichtung 111 kann eine oder mehrere interne Anzeigevorrichtungen sein, wie beispielsweise in einer mobilen elektronischen Vorrichtung oder einer Laptop-Vorrichtung oder einer externen Anzeigevorrichtung, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angeschlossen ist. In einer Ausführungsform kann die Anzeigevorrichtung 111 eine am Kopf montierte Anzeige (HMD, Head Mounted Display) sein, wie beispielsweise eine stereoskopische Anzeigevorrichtung zur Verwendung in Virtual-Reality(VR)-Anwendungen oder Augmented-Reality(AR)-Anwendungen.
In einigen Ausführungsformen ermöglicht der Plattformcontroller-Hub 130, dass Peripheriegeräte über einen Hochgeschwindigkeits-E/A-Bus eine Verbindung mit der Speichervorrichtung 120 und dem Prozessor 102 herstellen. Die E/A-Peripheriegeräte schließen einen Audiocontroller 146, einen Netzcontroller 134, eine Firmwareschnittstelle 128, einen drahtlosen Transceiver 126, Berührungssensoren 125, eine Datenspeicherungsvorrichtung 124 (z. B. ein Festplattenlaufwerk, Flash-Speicher usw.) ein, ohne darauf beschränkt zu sein. Die Datenspeicherungsvorrichtung 124 kann über eine Speicherungsschnittstelle (z. B. SATA) oder über einen Peripheriebus, wie beispielsweise einen Peripheral-Component-Interconnect-Bus (z. B. PCI, PCI Express), eine Verbindung herstellen. Die Berührungssensoren 125 können Berührungsbildschirmsensoren, Drucksensoren oder Fingerabdrucksensoren einschließen. Der drahtlose Transceiver 126 kann ein Wi-Fi-Transceiver, ein Bluetooth-Transceiver oder ein Mobilfunknetz-Transceiver, wie beispielsweise ein 3G-, 4G- oder Long-Term-Evolution(LTE)-Transceiver, sein. Die Firmwareschnittstelle 128 ermöglicht die Kommunikation mit der Systemfirmware und kann beispielsweise eine vereinheitlichte erweiterbare Firmwareschnittstelle (UEFI, Unified Extensible Firmware Interface) sein. Der Netzcontroller 134 kann eine Netzverbindung zu einem drahtgebundenen Netz ermöglichen. In einigen Ausführungsformen ist ein Hochleistungs-Netzcontroller (nicht gezeigt) mit dem Schnittstellenbus 110 gekoppelt. Der Audiocontroller 146 ist in einer Ausführungsform ein Mehrkanal-High-Definition-Audiocontroller. In einer Ausführungsform schließt das System 100 einen optionalen Legacy-E/A-Controller 140 zum Koppeln von Legacy-Vorrichtungen (z. B. Vorrichtungen für Personal System 2 (PS/2)) mit dem System ein. Der Plattformcontroller-Hub 130 kann auch eine Verbindung zu einem oder mehreren Universal-Serial-Bus(USB)-Controllern 142 herstellen, um Eingabevorrichtungen zu verbinden, wie beispielsweise Kombinationen aus Tastatur und Maus 143, eine Kamera 144 oder andere USB-Ei ngabevorrichtungen.
Es versteht sich, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da auch andere Typen von Datenverarbeitungssystemen verwendet werden können, die unterschiedlich konfiguriert sind. Beispielsweise kann eine Instanz des Speichercontrollers 116 und des Plattformcontroller-Hubs 130 in einen diskreten externen Grafikprozessor, wie beispielsweise den externen Grafikprozessor 112, integriert sein. In einer Ausführungsform können der Plattformcontroller-Hub 130 und/oder der Speichercontroller 160 außerhalb des einen oder der mehreren Prozessoren 102 sein. Beispielsweise kann das System 100 einen externen Speichercontroller 116 und einen Plattformcontroller-Hub 130 aufweisen, der als Speichercontroller-Hub und Peripheriecontroller-Hub innerhalb eines Systemchipsatzes konfiguriert sein kann, der mit dem/den Prozessor(en) 102 in Kommunikation steht.
2 ist ein Blockschaltbild einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A-202N, einem integrierten Speichercontroller 214 und einem integrierten Grafikprozessor 208. Diejenigen Elemente von 2, die die gleichen Bezugszeichen (oder Namen) wie die Elemente von einer beliebigen anderen Figur hierin aufweisen, können auf eine ähnliche Weise wie die an anderer Stelle hierin beschriebene arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Der Prozessor 200 kann zusätzliche Kerne bis einschließlich des zusätzlichen Kerns 202N aufweisen, der durch die gestrichelten Kästchen repräsentiert ist. Jeder der Prozessorkerne 202A-202N weist eine oder mehrere interne Cacheeinheiten 204A-204N auf. In einigen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf eine oder mehrere gemeinsam genutzte zwischengespeicherte Einheiten 206.
Die internen Cacheeinheiten 204A-204N und die gemeinsam genutzten Cacheeinheiten 206 repräsentieren eine Cachespeicherhierarchie innerhalb des Prozessors 200. Die Cachespeicherhierarchie kann wenigstens eine Ebene von Befehls- und Datencache in jedem Prozessorkern und eine oder mehrere Ebenen von gemeinsam genutztem Cache mittlerer Ebene einschließen, wie beispielsweise Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cacheebenen, wobei die höchste Cacheebene vor dem externen Speicher als LLC klassifiziert ist. In einigen Ausführungsformen hält die Cachekohärenzlogik die Kohärenz zwischen den verschiedenen Cacheeinheiten 206 und 204A-204N aufrecht.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von einer oder mehreren Buscontrollereinheiten 216 und einen Systemagentenkern 210 einschließen. Der eine oder die mehreren Buscontrollereinheiten 216 verwalten einen Satz von Peripheriebussen, wie beispielsweise einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 210 stellt Managementfunktionalität für die verschiedenen Prozessorkomponenten bereit. In einigen Ausführungsformen weist der Systemagentenkern 210 einen oder mehrere integrierte Speichercontroller 214 auf, um den Zugriff auf verschiedene externe Speichervorrichtungen (nicht gezeigt) zu verwalten.
In einigen Ausführungsformen schließen einer oder mehrere der Prozessorkerne 202A-202N eine Unterstützung für gleichzeitiges Multithreading ein. In einer derartigen Ausführungsform weist der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A-202N während der Multithread-Verarbeitung auf. Der Systemagentenkern 210 kann zusätzlich eine Stromsteuereinheit (PCU, Power Control Unit) aufweisen, die Logik und Komponenten zum Regeln des Stromzustands der Prozessorkerne 202A-202N und des Grafikprozessors 208 einschließt.
In einigen Ausführungsformen weist der Prozessor 200 zusätzlich einen Grafikprozessor 208 auf, um Grafikverarbeitungsoperationen auszuführen. In einigen Ausführungsformen ist der Grafikprozessor 208 mit dem Satz von gemeinsam genutzten Cacheeinheiten 206 und dem Systemagentenkern 210, einschließlich des einen oder der mehreren integrierten Speichercontroller 214, gekoppelt. In einigen Ausführungsformen weist der Systemagentenkern 210 auch einen Anzeigecontroller 211 auf, um die Grafikprozessorausgabe an eine oder mehrere gekoppelte Anzeigen anzusteuern. In einigen Ausführungsformen kann der Anzeigecontroller 211 auch ein separates Modul sein, das über wenigstens ein Interconnect mit dem Grafikprozessor gekoppelt ist, oder kann innerhalb des Grafikprozessors 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 eine alternative Interconnect-Einheit verwendet werden, wie beispielsweise ein Punkt-zu-Punkt-Interconnect, ein geschaltetes Interconnect oder andere Techniken, einschließlich Techniken, die in der Technik wohlbekannt sind. In einigen Ausführungsformen ist der Grafikprozessor 208 über einen E/A-Link 213 mit dem Ring-Interconnect 212 gekoppelt.
Der beispielhafte E/A-Link 213 repräsentiert wenigstens eine von mehreren Arten von E/A-Interconnects, einschließlich eines On-Package-E/A-Interconnect, der die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungs-Speichermodul 218, wie beispielsweise einem eDRAM-Modul, ermöglicht. In einigen Ausführungsformen verwenden jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als gemeinsam genutzten Cache der letzten Ebene.
In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, die die gleiche Befehlssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Befehlssatzarchitektur (ISA, Instruction Set Architecture) heterogen, wobei einer oder mehrere der Prozessorkerne 202A-202N einen ersten Befehlssatz ausführen, während wenigstens einer der anderen Kerne eine Teilmenge des ersten Befehlssatzes oder einen anderen Befehlssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Mikroarchitektur heterogen, wobei ein oder mehrere Kerne mit einem relativ höheren Stromverbrauch mit einem oder mehreren Stromkernen mit einem niedrigeren Stromverbrauch gekoppelt sind. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte SoC-Schaltung mit den veranschaulichten Komponenten zusätzlich zu anderen Komponenten implementiert werden.
3 ist ein Blockschaltbild eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor, der mit einer Mehrzahl von Verarbeitungskernen integriert ist, sein kann. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die in den Prozessorspeicher platziert werden. In einigen Ausführungsformen weist der Grafikprozessor 300 eine Speicherschnittstelle 314 auf, um auf den Speicher zuzugreifen. Die Speicherschnittstelle 314 kann eine Schnittstelle zum lokalen Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam genutzten externen Caches und/oder zum Systemspeicher sein.
In einigen Ausführungsformen weist der Grafikprozessor 300 auch einen Anzeigecontroller 302 auf, um Anzeigeausgabedaten an eine Anzeigevorrichtung 320 anzusteuern. Der Anzeigecontroller 302 weist Hardware für eine oder mehrere Überlagerungsebenen zur Anzeige und Zusammensetzung mehrerer Schichten von Video- oder Benutzerschnittstellenelementen auf. Die Anzeigevorrichtung 320 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 320 eine am Kopf montierte Anzeigevorrichtung, wie beispielsweise eine Virtual-Reality(VR)-Anzeigevorrichtung oder eine Augmented-Reality(AR)-Anzeigevorrichtung. In einigen Ausführungsformen weist der Grafikprozessor 300 eine Videocodec-Engine 306 zum Codieren, Decodieren oder Transcodieren von Medien in, von oder zwischen einem oder mehreren Mediencodierungsformaten auf, unter anderem Formate der Moving Picture Experts Group (MPEG) wie MPEG-2, Formate für Advanced Video Coding (AVC) wie H.264/MPEG-4 AVC sowie Formate der Society of Motion Picture & Television Engineers (SMPTE) 421 M/VC-1 und Joint Photographic Experts Group (JPEG) wie JPEG und Motion JPEG (MJPEG), jedoch nicht darauf beschränkt.
In einigen Ausführungsformen weist der Grafikprozessor 300 eine Engine 304 zur Blockbildübertragung (BLIT, Block Image Transfer) auf, um zweidimensionale (2D-) Rasterizer-Operationen durchzuführen, einschließlich beispielsweise Bitgrenzenblockübertragungen. Jedoch werden in einer Ausführungsform 2D-Grafikoperationen unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE, Graphics Processing Engine) 310 durchgeführt. In einigen Ausführungsformen ist die GPE 310 eine Rechen-Engine zum Durchführen von Grafikoperationen, einschließlich dreidimensionaler (3D-) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen weist die GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen auf, wie beispielsweise Rendering dreidimensionaler Bilder und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen (z. B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 312 schließt programmierbare und feste Funktionselemente ein, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungs-Threads zu einem 3D/Medien-Subsystem 315 erzeugen. Obgleich die 3D-Pipeline 312 verwendet werden kann, um Medienoperationen durchzuführen, schließt eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316 ein, die speziell verwendet wird, um Medienoperationen, wie beispielsweise Videonachbearbeitung und Bildverbesserung, durchzuführen.
In einigen Ausführungsformen schließt die Medien-Pipeline 316 Festfunktions- oder programmierbare Logikeinheiten ein, um eine oder mehrere spezialisierte Medienoperationen wie eine Videodecodierbeschleunigung, ein Video-De-Interlacing und eine Videocodierbeschleunigung anstelle oder im Auftrag der Videocodec-Engine 306 durchzuführen. In einigen Ausführungsformen schließt die Medien-Pipeline 316 zusätzlich eine Thread-Erzeugungseinheit zum Erzeugen von Threads für die Ausführung auf dem 3D/Medien-Subsystem 315 ein. Die erzeugten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten im 3D/Medien-Subsystem 315 durch.
In einigen Ausführungsformen schließt das 3D/Medien-Subsystem 315 eine Logik zum Ausführen von Threads, die von der 3D-Pipeline 312 und der Medien-Pipeline 316 erzeugt werden, ein. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanforderungen an das 3D/Medien-Subsystem 315, das eine Thread-Dispatch-Logik zum Arbitrieren und Versenden der verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen einschließt. Die Ausführungsressourcen schließen ein Array von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medien-Threads ein. In einigen Ausführungsformen schließt das 3D/Medien-Subsystem 315 einen oder mehrere interne Caches für Thread-Anweisungen und -Daten ein. In einigen Ausführungsformen beinhaltet das Subsystem auch einen gemeinsam genutzten Speicher, einschließlich Register und adressierbarem Speicher, um Daten zwischen Threads zu teilen und Ausgabedaten zu speichern.
Grafikverarbeitungs-Engine
4 ist ein Blockschaltbild einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors gemäß einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungs-Engine (GPE) 410 eine Version der in 3 gezeigten GPE 310. Elemente von 4, die die gleichen Bezugszeichen (oder Namen) wie die Elemente von einer beliebigen anderen Figur hierin aufweisen, können auf eine ähnliche Weise wie die an anderer Stelle hierin beschriebene arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Beispielsweise sind die 3D-Pipeline 312 und die Medien-Pipeline 316 aus 3 veranschaulicht. Die Medien-Pipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und ist möglicherweise nicht explizit innerhalb der GPE 410 eingeschlossen. Beispielsweise und in wenigstens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
In einigen Ausführungsformen ist die GPE 410 mit einem Befehls-Streamer 403 gekoppelt oder sie weist diesen auf, der der 3D-Pipeline 312 und/oder den Medien-Pipelines 316 einen Befehlsstrom bereitstellt. In einigen Ausführungsformen ist der Befehls-Streamer 403 mit einem Speicher gekoppelt, der ein Systemspeicher oder einer oder mehrere von einem internen Cachespeicher und einem gemeinsam genutzten Cachespeicher sein kann. In einigen Ausführungsformen empfängt der Befehls-Streamer 403 Befehle aus dem Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medien-Pipeline 316. Die Befehle sind Anweisungen, die aus einem Ringpuffer gefetcht werden, der Befehle für die 3D-Pipeline 312 und die Medien-Pipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Batch-Befehlspuffer aufweisen, die Batches von mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Verweise auf im Speicher gespeicherte Daten einschließen, wie beispielsweise Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316, ohne darauf beschränkt zu sein. Die 3D-Pipeline 312 und die Medien-Pipeline 316 verarbeiten die Befehle und Daten mittels Durchführen von Operationen über Logik innerhalb der jeweiligen Pipelines oder mittels Versenden eines oder mehrerer Ausführungs-Threads an ein Grafikkern-Array 414. In einer Ausführungsform weist das Grafikkern-Array 414 einen oder mehrere Blöcke von Grafikkernen (z. B. Grafikkern(e) 415A, Grafikkern(e) 415B) auf, wobei jeder Block einen oder mehrere Grafikkerne einschließt. Jeder Grafikkern schließt einen Satz von Grafikausführungsressourcen ein, die eine Allzweck- und grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Rechenoperationen sowie eine Festfunktions-Texturverarbeitungslogik und/oder eine Logik für maschinelles Lernen und zur Beschleunigung der künstlichen Intelligenz einschließen.
In verschiedenen Ausführungsformen weist die 3D-Pipeline 312 eine Festfunktions- und programmierbare Logik auf, um ein oder mehrere Shader-Programme, wie beispielsweise Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Rechen-Shader oder andere Shader-Programme, durch Verarbeiten der Anweisungen und Versenden von Ausführungs-Threads an das Grafikkern-Array 414 zu verarbeiten. Das Grafikkern-Array 414 stellt einen vereinheitlichten Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shader-Programme bereit. Eine Mehrzweck-Ausführungslogik (z. B. Ausführungseinheiten) innerhalb des/der Grafikkerns/e 415A-414B des Grafikkern-Arrays 414 schließt eine Unterstützung für verschiedene 3D-API-Shader-Sprachen ein und kann mehrere gleichzeitige Ausführungs-Threads ausführen, die mit mehreren Shadern assoziiert sind.
In einigen Ausführungsformen schließt das Grafikkern-Array 414 auch eine Ausführungslogik zum Durchführen von Medienfunktionen ein, wie beispielsweise Video- und/oder Bildverarbeitung. In einer Ausführungsform schließen die Ausführungseinheiten zusätzlich Allzweck-Logik ein, die programmierbar ist, um parallele Allzweck-Rechenoperationen zusätzlich zu Grafikverarbeitungsoperationen durchzuführen. Die Allzweck-Logik kann Verarbeitungsoperationen parallel oder in Verbindung mit der Allzweck-Logik innerhalb des/der Prozessorkerns/e 107 aus 1 oder des Kerns 202A-202N wie in 2 durchführen.
Ausgabedaten, die durch Threads generiert werden, die auf dem Grafikkern-Array 414 ausgeführt werden, können Daten an einen Speicher in einem vereinheitlichten Rückgabepuffer (URB, Unified Return Buffer) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen verschiedenen Threads zu senden, die auf dem Grafikkern-Array 414 ausgeführt werden. In einigen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisation zwischen Threads auf dem Grafikkern-Array und der Festfunktionslogik innerhalb der gemeinsam genutzten Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist das Grafikkern-Array 414 skalierbar, so dass das Array eine variable Anzahl von Grafikkernen einschließt, die jeweils eine variable Anzahl von Ausführungseinheiten basierend auf dem Zielstrom und der Leistungsstufe 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 Grafikkern-Array 414 ist mit einer gemeinsam genutzten Funktionslogik 420 gekoppelt, die mehrere Ressourcen aufweist, die zwischen den Grafikkernen im Grafikkern-Array gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen innerhalb der gemeinsam genutzten Funktionslogik 420 sind Hardwarelogikeinheiten, die dem Grafikkern-Array 414 eine spezialisierte Zusatzfunktionalität bereitstellen. In verschiedenen Ausführungsformen beinhaltet die gemeinsam genutzte Funktionslogik 420 die Logik des Samplers 421, der Mathematik 422 und der Inter-Thread-Kommunikation (ITC, Inter-Thread Communication) 423, ist jedoch nicht darauf beschränkt. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Caches 425 innerhalb der gemeinsam genutzten Funktionslogik 420.
Eine gemeinsam genutzte Funktion wird implementiert, wenn die Anforderung für eine gegebene spezialisierte Funktion nicht ausreicht, um innerhalb des Grafikkern-Arrays 414 aufgenommen zu werden. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eigenständige Entität in der gemeinsam genutzten Funktionslogik 420 implementiert und von den Ausführungsressourcen innerhalb des Grafikkern-Arrays 414 gemeinsam genutzt. Der präzise Satz von Funktionen, die zwischen dem Grafikkern-Array 414 geteilt und innerhalb des Grafikkern-Arrays 414 eingeschlossen sind, variiert zwischen Ausführungsformen. In einigen Ausführungsformen können spezielle gemeinsam genutzte Funktionen innerhalb der gemeinsam genutzten Funktionslogik 420, die umfassend vom Grafikkern-Array 414 verwendet werden, innerhalb der gemeinsam genutzten Funktionslogik 416 innerhalb des Grafikkern-Arrays 414 eingeschlossen sein. In verschiedenen Ausführungsformen kann die gemeinsam genutzte Funktionslogik 416 innerhalb des Grafikkern-Arrays 414 einige oder alle Logik innerhalb der gemeinsam genutzten Funktionslogik 420 aufweisen. In einer Ausführungsform können alle Logikelemente innerhalb der gemeinsam genutzten Funktionslogik 420 innerhalb der gemeinsam genutzten Funktionslogik 416 des Grafikkern-Arrays 414 dupliziert werden. In einer Ausführungsform ist die gemeinsam genutzte Funktionslogik 420 zugunsten der gemeinsam genutzten Funktionslogik 416 innerhalb des Grafikkern-Arrays 414 ausgeschlossen.
5 ist ein Blockschaltbild der Hardwarelogik eines Grafikprozessorkerns 500 gemäß einigen hierin beschriebenen Ausführungsformen. Elemente von 5, die die gleichen Bezugszeichen (oder Namen) wie die Elemente von einer beliebigen anderen Figur hierin aufweisen, können auf eine ähnliche Weise wie die an anderer Stelle hierin beschriebene arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Der veranschaulichte Grafikprozessorkern 500 ist in einigen Ausführungsformen innerhalb des Grafikkern-Arrays 414 aus 4 eingeschlossen. Der Grafikprozessorkern 500, der manchmal als Kern-Slice bezeichnet wird, kann ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 500 ist beispielhaft für ein Grafikkern-Slice, und ein Grafikprozessor, wie hierin beschrieben, kann mehrere Grafikkern-Slices basierend auf dem Zielstrom und Leistungshüllkurven aufweisen. Jeder Grafikkern 500 kann einen Festfunktionsblock 530 aufweisen, der mit mehreren Subkernen 501A-501F gekoppelt ist, die auch als Sub-Slices bezeichnet werden und modulare Blöcke von Allzweck- und Festfunktionslogik aufweisen.
In einigen Ausführungsformen beinhaltet der Festfunktionsblock 530 eine Geometrie-/Festfunktions-Pipeline 536, die von allen Subkernen im Grafikprozessor 500 gemeinsam genutzt werden kann, beispielsweise bei Implementierungen von Grafikprozessoren mit geringerer Leistung und/oder niedrigerem Strom. In verschiedenen Ausführungsformen beinhaltet die Geometrie-/Festfunktions-Pipeline 536 eine 3D-Festfunktions-Pipeline (z. B. die 3D-Pipeline 312 wie in 3 und 4), eine Video-Frontend-Einheit, einen Thread-Spawner und einen Thread-Dispatcher und einen Manager für vereinheitlichte Rückgabepuffer, der vereinheitlichte Rückgabepuffer, wie beispielsweise den vereinheitlichten Rückgabepuffer 418 aus 4, verwaltet.
In einer Ausführungsform weist der Festfunktionsblock 530 auch eine Grafik-SoC-Schnittstelle 537, einen Grafik-Mikrocontroller 538 und eine Medien-Pipeline 539 auf. Die Grafik-SoC-Schnittstelle 537 stellt eine Schnittstelle zwischen dem Grafikkern 500 und anderen Prozessorkernen innerhalb eines Systems auf einer integrierten Chipschaltung bereit. Der Grafik-Mikrocontroller 538 ist ein programmierbarer Subprozessor, der konfiguriert werden kann, um verschiedene Funktionen des Grafikprozessors 500 zu verwalten, einschließlich Thread-Dispatch, Scheduling und Preemption. Die Medien-Pipeline 539 (z. B. die Medien-Pipeline 316 aus 3 und 4) weist Logik auf, um das Decodieren, Codieren, Vorverarbeiten und/oder Nachbearbeiten von Multimediadaten, einschließlich Bild- und Videodaten, zu ermöglichen. Die Medien-Pipeline 539 implementiert Medienoperationen über Anforderungen zum Berechnen oder Abtastlogik innerhalb der Subkerne 501-501F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537, dass der Grafikkern 500 mit Allzweck-Anwendungsprozessorkernen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC kommuniziert, einschließlich Speicherhierarchieelementen, wie beispielsweise eines gemeinsam genutzten Cachespeichers der letzten Ebene, des System-RAM und/oder eines eingebetteten On-Chip- oder On-Package-DRAM. Die SoC-Schnittstelle 537 kann auch die Kommunikation mit Festfunktionsvorrichtungen innerhalb des SoC ermöglichen, wie beispielsweise Kamerabildgebungs-Pipelines, und ermöglicht die Verwendung und/oder Implementierung von globalen Speicheratomen, die zwischen dem Grafikkern 500 und den CPUs innerhalb des SoC gemeinsam genutzt werden können. Die SoC-Schnittstelle 537 kann auch Strommanagementsteuerungen 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 Befehls-Streamer und einem globalen Thread-Dispatcher, die so konfiguriert sind, dass sie Befehle und Anweisungen für jeden von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors bereitstellen. Die Befehle und Anweisungen können an die Medien-Pipeline 539, wenn Medienoperationen durchzuführen sind, oder an eine Geometrie- und Festfunktions-Pipeline (z. B. Geometrie- und Festfunktions-Pipeline 536, Geometrie- und Festfunktions-Pipeline 514) versendet werden, wenn Grafikverarbeitungsoperationen durchzuführen sind.
Der Grafik-Mikrocontroller 538 kann konfiguriert sein, um verschiedene Scheduling- und Managementaufgaben für den Grafikkern 500 durchzuführen. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 ein Grafik- und/oder Rechen-Workload-Scheduling auf den verschiedenen Grafik-Parallel-Engines innerhalb von Ausführungseinheits(EU, Execution Unit)-Arrays 502A-502F, 504A-504F innerhalb der Subkerne 501A-501F durchführen. In diesem Scheduling-Modell kann Hostsoftware, die auf einem CPU-Kern eines SoC einschließlich des Grafikkerns 500 ausgeführt wird, Workloads einer von mehreren Grafikprozessor-Doorbells einreichen, wodurch eine Scheduling-Operation auf der geeigneten Grafik-Engine aufgerufen wird. Scheduling-Operationen beinhalten das Bestimmen, welche Workload als Nächste ausgeführt werden soll, das Einreichen einer Workload an einen Befehls-Streamer, das Preempting vorhandener Workloads, die auf einer Engine ausgeführt werden, das Überwachen des Fortschritts einer Workload und das Benachrichtigen der Hostsoftware, wenn eine Workload abgeschlossen ist. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 auch Low-Power- oder Leerlaufzustände für den Grafikkern 500 ermöglichen, wodurch der Grafikkern 500 die Möglichkeit erhält, Register innerhalb des Grafikkerns 500 über Low-Power-Zustandsübergänge hinweg unabhängig vom Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederhe rzustellen.
Der Grafikkern 500 kann mehr oder weniger als die veranschaulichten Subkerne 501A-501F bis zu N modulare Subkerne aufweisen. Für jeden Satz von N Subkernen kann der Grafikkern 500 auch eine gemeinsam genutzte Funktionslogik 510, einen gemeinsam genutzten und/oder Cachespeicher 512, eine Geometrie-/Festfunktions-Pipeline 514 sowie eine zusätzliche Festfunktionslogik 516 zum Beschleunigen verschiedener Grafik- und Rechenverarbeitungsoperationen einschließen. Die gemeinsam genutzte Funktionslogik 510 kann Logikeinheiten einschließen, die mit der gemeinsam genutzten Funktionslogik 420 aus 4 assoziiert sind (z. B. Sampler-, Mathematik- und/oder Inter-Thread-Kommunikationslogik), die von allen N Subkernen innerhalb des Grafikkerns 500 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cachespeicher 512 kann ein Cache der letzten Ebene für den Satz von N Subkernen 501A-501F innerhalb des Grafikkerns 500 sein und kann auch als gemeinsam genutzter Speicher dienen, auf den mehrere Subkerne zugreifen können. Die Geometrie-/Festfunktions-Pipeline 514 kann anstelle der Geometrie-/Festfunktions-Pipeline 536 innerhalb des Festfunktionsblocks 530 eingeschlossen sein und kann die gleichen oder ähnliche Logikeinheiten aufweisen.
In einer Ausführungsform weist der Grafikkern 500 eine zusätzliche Festfunktionslogik 516 auf, die verschiedene Festfunktionsbeschleunigungslogiken zur Verwendung durch den Grafikkern 500 einschließen kann. In einer Ausführungsform weist die zusätzliche Festfunktionslogik 516 eine zusätzliche Geometrie-Pipeline zur Verwendung beim Position-only-Shading auf. Beim Position-only-Shading existieren zwei Geometrie-Pipelines, die vollständige Geometrie-Pipeline innerhalb der Geometrie-/Festfunktions-Pipeline 516, 536 und eine Cull-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die innerhalb der zusätzlichen Festfunktionslogik 516 eingeschlossen sein kann. In einer Ausführungsform ist die Cull-Pipeline eine verkleinerte Version der vollständigen Geometrie-Pipeline. Die vollständige Pipeline und die Cull-Pipeline können unterschiedliche Instanzen der gleichen Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Position-only-Shading kann lange Cull-Läufe von verworfenen Dreiecken verbergen, so dass das Shading in einigen Fällen früher abgeschlossen werden kann. Beispielsweise und in einer Ausführungsform kann die Cull-Pipeline-Logik innerhalb der zusätzlichen Festfunktionslogik 516 Positions-Shader parallel zur Hauptanwendung ausführen und generiert im Allgemeinen kritische Ergebnisse schneller als die vollständige Pipeline, während die Cull-Pipeline nur das Positionsattribut der Vertices fetcht und schattiert, ohne eine Rasterung und ein Rendering der Pixel zum Frame-Puffer durchzuführen. Die Cull-Pipeline kann die generierten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, unabhängig davon, ob diese Dreiecke gecullt sind. Die vollständige Pipeline (die in diesem Fall als Replay-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verbrauchen, um die gecullten Dreiecke zu überspringen und nur die sichtbaren Dreiecke zu schattieren, die schließlich an die Rasterungsphase weitergeleitet werden.
In einer Ausführungsform kann die zusätzliche Festfunktionslogik 516 auch eine Beschleunigungslogik für maschinelles Lernen, wie beispielsweise eine Festfunktions-Matrixmultiplikationslogik, für Implementierungen einschließlich Optimierungen für Training oder Inferenzierung für maschinelles Lernen aufweisen.
Jeder Grafik-Subkern 501A-501F weist einen Satz von Ausführungsressourcen auf, die verwendet werden können, um Grafik-, Medien- und Rechenoperationen in Reaktion auf Anforderungen durch Grafik-Pipeline-, Medien-Pipeline- oder Shader-Programme durchzuführen. Die Grafik-Subkerne 501A-501F beinhalten mehrere EU-Arrays 502A-502F, 504A-504F, Thread-Dispatch- und Inter-Thread-Kommunikations(TD/IC)-Logik 503A-503F, einen 3D-(z. B. Textur-) Sampler 505A-505F, einen Medien-Sampler 506A-506F, einen Shader-Prozessor 507A-507F und einen gemeinsam genutzten lokalen Speicher (SLM, Shared Local Memory) 508A-508F. Die EU-Arrays 502A-502F, 504A-504F schließen jeweils mehrere Ausführungseinheiten ein, die Allzweck-Grafikverarbeitungseinheiten sind, die Gleitkomma- und Ganzzahl-/Festkomma-Logikoperationen im Dienst einer Grafik-, Medien- oder Rechenoperation durchführen können, einschließlich Grafik-, Medien- oder Rechen-Shader-Programmen. Die TD/IC-Logik 503A-503F führt lokale Thread-Dispatch- und Thread-Steueroperationen für die Ausführungseinheiten innerhalb eines Subkerns durch und ermöglicht die Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Subkerns ausgeführt werden. Der 3D-Sampler 505A-505F kann Textur- oder andere 3D-Grafik-bezogene Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten basierend auf einem konfigurierten Abtastzustand und dem Texturformat, das mit einer gegebenen Textur assoziiert ist, unterschiedlich lesen. Der Medien-Sampler 506A-506F kann ähnliche Leseoperationen basierend auf dem Typ und Format durchführen, die mit Mediendaten assoziiert sind. In einer Ausführungsform kann jeder Grafik-Subkern 501A-501F alternativ einen vereinheitlichten 3D- und Medien-Sampler aufweisen. Threads, die auf den Ausführungseinheiten in jedem der Subkerne 501A-501F ausgeführt werden, können den gemeinsam genutzten lokalen Speicher 508A-508F in jedem Subkern verwenden, um die Ausführung von Threads innerhalb einer Thread-Gruppe unter Verwendung eines gemeinsamen Pools von On-Chip-Speicher zu ermöglichen.
Ausführungseinheiten
6A-6B veranschaulichen eine Thread-Ausführungslogik 600, die ein Array von Verarbeitungselementen aufweist, die in einem Grafikprozessorkern gemäß hierin beschriebenen Ausführungsformen verwendet werden. Elemente der 6A-6B, die die gleichen Bezugszeichen (oder Namen) wie die Elemente von einer beliebigen anderen Figur hierin aufweisen, können auf eine ähnliche Weise wie die an anderer Stelle hierin beschriebene arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. 6A veranschaulicht eine Übersicht über die Thread-Ausführungslogik 600, die eine Variante der Hardwarelogik einschließen kann, die mit jedem Subkern 501A-501F aus 5 veranschaulicht ist. 6B veranschaulicht beispielhafte interne Details einer Ausführungseinheit.
Wie in 6A veranschaulicht, weist die Thread-Ausführungslogik 600 in einigen Ausführungsformen einen Shader-Prozessor 602, einen Thread-Dispatcher 604, einen Befehlscache 606, ein skalierbares Ausführungseinheits-Array einschließlich einer Mehrzahl von Ausfuhrungseinheiten 608A-608N, einen Sampler 610, einen Datencache 612 und einen Datenport 614 auf. In einer Ausführungsform kann das skalierbare Ausführungseinheits-Array dynamisch skaliert werden, indem eine oder mehrere Ausführungseinheiten (z. B. eine beliebige der Ausführungseinheiten 608A, 608B, 608C, 608D bis 608N-1 und 608N) basierend auf den Rechenanforderungen einer Workload aktiviert oder deaktiviert werden. In einer Ausführungsform sind die eingeschlossenen Komponenten über eine Interconnect-Fabric miteinander verbunden, die mit jeder der Komponenten verknüpft ist. In einigen Ausführungsformen beinhaltet die Thread-Ausführungslogik 600 eine oder mehrere Verbindungen zum Speicher, wie beispielsweise zum Systemspeicher oder Cachespeicher, über einen oder mehrere vom Befehlscache 606, Datenport 614, Sampler 610 und von den Ausführungseinheiten 608A-608N. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 608A) eine eigenständige programmierbare Allzweck-Recheneinheit, die in der Lage ist, mehrere gleichzeitige Hardware-Threads auszuführen, während mehrere Datenelemente für jeden Thread parallel verarbeitet werden. In verschiedenen Ausführungsformen ist das Array von Ausführungseinheiten 608A-608N skalierbar, um eine beliebige Anzahl einzelner Ausführungseinheiten einzuschließen.
In einigen Ausführungsformen werden die Ausführungseinheiten 608A-608N hauptsächlich zum Ausführen von Shader-Programmen verwendet. Ein Shader-Prozessor 602 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads, die mit den Shader-Programmen assoziiert sind, über einen Thread-Dispatcher 604 versenden. In einer Ausführungsform beinhaltet der Thread-Dispatcher eine Logik zum Arbitrieren von Thread-Initiierungsanforderungen von den Grafik- und Medien-Pipelines und zum Instanziieren der angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 608A-608N. Beispielsweise kann eine Geometrie-Pipeline Vertex-, Tessellations- oder Geometrie-Shader zur Verarbeitung an die Thread-Ausführungslogik versenden. In einigen Ausführungsformen kann der Thread-Dispatcher 604 auch Laufzeit-Thread-Spawning-Anforderungen von den ausführenden Shader-Programmen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N einen Befehlssatz, der eine native Unterstützung für viele standardmäßige 3D-Grafik-Shader-Befehle einschließt, so dass Shader-Programme aus Grafikbibliotheken (z. B. Direct3D und OpenGL) mit einer minimalen Translation 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 Allzweck-Verarbeitung (z. B. Rechen- und Media-Shader). Jede der Ausführungseinheiten 608A-608N ist in der Lage, eine Multi-Issue-Single-Instruction-Multiple-Data(SIMD)-Ausfühung durchzuführen, und eine Multithread-Operation ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit hat eine dedizierte Registerdatei mit hoher Bandbreite und einen assoziierten unabhängigen Thread-Zustand. Die Ausführung erfolgt Multi-Issue pro Takt zu Pipelines, die in der Lage sind zu Gleitkomma-Operationen mit ganzzahliger einfacher und doppelter Genauigkeit, SIMD-Verzweigungsfähigkeit, logischen Operationen, transzendentalen Operationen und anderen verschiedenen Operationen. Während auf Daten aus dem Speicher oder eine der gemeinsam genutzten Funktionen gewartet wird, bewirkt die Abhängigkeitslogik innerhalb der Ausführungseinheiten 608A-608N, dass ein wartender Thread in den Ruhezustand versetzt wird, bis die angeforderten Daten zurückgegeben wurden. Während der wartende Thread im Ruhezustand ist, können Hardwareressourcen zur Verarbeitung anderer Threads verwendet werden. Beispielsweise kann während einer Verzögerung, die mit einer Vertex-Shader-Operation assoziiert ist, eine Ausführungseinheit Operationen für einen Pixel-Shader, einen Fragment-Shader oder einen anderen Typ eines Shader-Programms durchführen, einschließlich eines anderen Vertex-Shaders.
Jede Ausführungseinheit in den Ausführungseinheiten 608A-608N arbeitet auf Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ oder die Anzahl der Kanäle für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für den Datenelementzugriff, die Maskierung und die Flusssteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann unabhängig von der Anzahl der physikalischen Arithmetik-Logik-Einheiten (ALUs, Arithmetic Logic Units) oder Gleitkomma-Einheiten (FPUs, Floating Point Units) für einen bestimmten Grafikprozessor sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N Ganzzahl- und Gleitkomma-Datentypen.
Der Befehlssatz der Ausführungseinheit weist SIMD-Anweisungen auf. Die verschiedenen Datenelemente können als gepackter Datentyp in einem Register gespeichert werden, und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Wenn beispielsweise auf einem 256 Bit breiten Vektor gearbeitet wird, werden die 256 Bit des Vektors in einem Register gespeichert, und die Ausführungseinheit arbeitet auf dem Vektor als vier separate gepackte 64-Bit-Datenelemente (Datenelemente der Größe Quad-Wort (QW)), acht separate gepackte 32-Bit-Datenelemente (Datenelemente der Größe Doppelwort (DW)), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente der Größe Wort (W)) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente der Größe Byte (B)). Unterschiedliche Vektorbreiten und Registergrößen sind jedoch möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten zu einer fusionierten Ausführungseinheit 609A-609N mit einer Thread-Steuerlogik (607A-607N) kombiniert werden, die den fusionierten EUs gemeinsam ist. Mehrere EUs können zu einer EU-Gruppe fusioniert werden. Jede EU in der fusionierten EU-Gruppe kann konfiguriert sein, um einen separaten SIMD-Hardware-Thread auszuführen. Die Anzahl von EUs in einer fusionierten EU-Gruppe kann gemäß Ausführungsformen variieren. Zusätzlich können verschiedene SIMD-Breiten pro EU durchgeführt werden, einschließlich SIMD8, SIMD16 und SIMD32, jedoch nicht darauf beschränkt. Jede fusionierte Grafikausführungseinheit 609A-609N weist wenigstens zwei Ausführungseinheiten auf. Beispielsweise beinhaltet die fusionierte Ausführungseinheit 609A eine erste EU 608A, eine zweite EU 608B und eine Thread-Steuerlogik 607A, die der ersten EU 608A und der zweiten EU 608B gemeinsam ist. Die Thread-Steuerlogik 607A steuert Threads, die auf der fusionierten Grafikausführungseinheit 609A ausgeführt werden, so dass jede EU innerhalb der fusionierten Grafikausführungseinheiten 609A-609N unter Verwendung eines gemeinsamen Befehlszeigerregisters ausgeführt werden kann.
Ein oder mehrere interne Befehlscaches (z. B. 606) sind in der Thread-Ausführungslogik 600 eingeschlossen, um Thread-Anweisungen für die Ausführungseinheiten zwischenzuspeichern. In einigen Ausführungsformen sind ein oder mehrere Datencaches (z. B. 612) eingeschlossen, um Thread-Daten während der Thread-Ausführung zwischenzuspeichern. In einigen Ausführungsformen ist ein Sampler 610 eingeschlossen, um eine Texturabtastung für 3D-Operationen und eine Medienabtastung für Medienoperationen bereitzustellen. In einigen Ausführungsformen beinhaltet der Sampler 610 eine spezialisierte Textur- oder Medienabtastfunktionalität, um Textur- oder Mediendaten während des Abtastprozesses zu verarbeiten, bevor die abgetasteten Daten einer Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und Medien-Pipelines Thread-Initiierungsanforderungen an die Thread-Ausführungslogik 600 über die Thread-Spawning- und -Dispatch-Logik. Sobald eine Gruppe von geometrischen Objekten verarbeitet und in Pixeldaten gerastert wurde, wird eine Pixelprozessorlogik (z. B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) innerhalb des Shader-Prozessors 602 aufgerufen, um ferner Ausgabeinformation zu berechnen und um zu bewirken, dass Ergebnisse zu Ausgabeoberflächen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In einigen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertex-Attribute, die über das gerasterte Objekt interpoliert werden sollen. In einigen Ausführungsformen führt die Pixelprozessorlogik innerhalb des Shader-Prozessors 602 dann ein von der Anwendungsprogrammierschnittstelle (API, Application Programming Interface) bereitgestelltes Pixel- oder Fragment-Shader-Programm aus. Um das Shader-Programm auszuführen, versendet der Shader-Prozessor 602 Threads über den Thread-Dispatcher 604 an eine Ausführungseinheit (z. B. 608A). In einigen Ausführungsformen verwendet der Shader-Prozessor 602 eine Texturabtastlogik im Sampler 610, um auf Texturdaten in im Speicher gespeicherten Texturabbildungen zuzugreifen. Arithmetische Operationen an den Texturdaten und den eingegebenen Geometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel aus der weiteren Verarbeitung.
In einigen Ausführungsformen stellt der Datenport 614 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 600 bereit, um verarbeitete Daten zur weiteren Verarbeitung in einer Grafikprozessorausgabe-Pipeline an den Speicher auszugeben. In einigen Ausführungsformen schließt der Datenport 614 einen oder mehrere Cachespeicher (z. B. Datencache 612) ein oder ist mit diesen gekoppelt, um Daten für den Speicherzugriff über den Datenport zwischenzuspeichern.
Wie in 6B veranschaulicht, kann eine Grafikausführungseinheit 608 eine Befehls-Fetch-Einheit 637, ein allgemeines Registerdatei-Array (GRF, General Register File) 624, ein Architekturregisterdatei-Array (ARF, Architectural Register File) 626, einen Thread-Arbiter 622, eine Sendeeinheit 630, eine Verzweigungseinheit 632, einen Satz von SIMD-Gleitkommaeinheiten (FPUs, Floating Point Units) 634 und in einer Ausführungsform einen Satz von dedizierten Ganzzahl-SIMD-ALUs 635 einschließen. Das GRF 624 und das ARF 626 schließen den Satz von allgemeinen Registerdateien und Architekturregisterdateien ein, die mit jedem simultanen Hardware-Thread assoziiert sind, der in der Grafikausführungseinheit 608 aktiv sein kann. In einer Ausführungsform wird der Pro-Thread-Architekturzustand im ARF 626 beibehalten, während Daten, die während der Thread-Ausführung verwendet werden, im GRF 624 gespeichert werden. Der Ausführungszustand von jedem Thread, einschließlich der Befehlszeiger für jeden Thread, kann in Thread-spezifischen Registern im ARF 626 gehalten werden.
In einer Ausführungsform weist die Grafikausführungseinheit 608 eine Architektur auf, die eine Kombination aus simultanem Multi-Threading (SMT) und feinkörnigem Interleaved Multi-Threading (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zur Designzeit basierend auf einer Zielanzahl von gleichzeitigen Threads und einer Anzahl von Registern pro Ausführungseinheit fein abgestimmt werden kann, wobei die Ausführungseinheitsressourcen auf die Logik aufgeteilt sind, die zum Ausführen mehrerer gleichzeitiger Threads verwendet wird.
In einer Ausführungsform kann die Grafikausführungseinheit 608 mehrere Anweisungen gemeinsam ausgeben, die jeweils unterschiedliche Anweisungen sein können. Der Thread-Arbiter 622 des Grafikausführungseinheits-Threads 608 kann die Anweisungen zur Ausführung an eine der Sendeeinheit 630, Verzweigungseinheit 642 oder SIMD-FPU(s) 634 versenden. Jeder Ausführungs-Thread kann auf 128 Allzweck-Register innerhalb des GRF 624 zugreifen, wobei jedes Register 32 Byte speichern kann, auf die als ein SIMD-8-Element-Vektor von 32-Bit-Datenelementen zugegriffen werden kann. In einer Ausführungsform hat jeder Ausführungseinheits-Thread Zugriff auf 4 KByte innerhalb des GRF 624, obwohl Ausführungsformen nicht darauf beschränkt sind, und in anderen Ausführungsformen können mehr oder weniger Registerressourcen bereitgestellt werden. In einer Ausführungsform können bis zu sieben Threads gleichzeitig ausgeführt werden, obwohl die Anzahl der Threads pro Ausführungseinheit gemäß Ausführungsformen auch variieren kann. In einer Ausführungsform, in der sieben Threads auf 4 KByte zugreifen können, kann das GRF 624 insgesamt 28 KByte speichern. Flexible Adressierungsmodi können ermöglichen, dass Register zusammen adressiert werden, um effektiv breitere Register aufzubauen oder überschrittene rechteckige Blockdatenstrukturen zu repräsentieren.
In einer Ausführungsform werden Speicheroperationen, Sampler-Operationen und andere Systemkommunikationen mit längerer Latenz über „Sende“-Anweisungen versendet, die durch die Nachrichtenübergabe-Sendeeinheit 630 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 632 versendet, um eine SIMD-Divergenz und eventuelle Konvergenz zu ermöglichen.
In einer Ausführungsform schließt die Grafikausführungseinheit 608 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s), Floating Point Unit(s)) 634 ein, um Gleitkommaoperationen durchzuführen. In einer Ausführungsform unterstützen die FPU(s) 634 auch eine Ganzzahlberechnung. In einer Ausführungsform können die FPU(s) 634 eine SIMD-Ausführung bis zu M32-Bit-Gleitkommaoperationen (oder Ganzzahloperationen) oder eine SIMD-Ausführung bis zu 2 M 16-Bit-Ganzzahloperationen oder 16-Bit-Gleitkommaoperationen durchführen. In einer Ausführungsform stellt wenigstens eine der FPU(s) eine erweiterte mathematische Fähigkeit bereit, um transzendentale mathematische Funktionen mit hohem Durchsatz und 64-Bit-Gleitkomma mit doppelter Genauigkeit zu unterstützen. In einigen Ausführungsformen ist auch ein Satz von 8-Bit-Ganzzahl-SIMD-ALUs 635 vorhanden, die speziell optimiert werden können, um Operationen durchzuführen, die mit Berechnungen für maschinelles Lernen assoziiert sind.
In einer Ausführungsform können Arrays von mehreren Instanzen der Grafikausführungseinheit 608 in einer Grafiksubkerngruppierung (z. B. einem Sub-Slice) instanziiert werden. Zwecks Skalierbarkeit können Produktarchitekten die genaue Anzahl von Ausführungseinheiten pro Subkerngruppierung auswählen. In einer Ausführungsform kann die Ausführungseinheit 608 Anweisungen über eine Mehrzahl von Ausführungskanälen ausführen. In einer weiteren Ausführungsform wird jeder Thread, der auf der Grafikausführungseinheit 608 ausgeführt wird, auf einem anderen Kanal ausgeführt.
7 ist ein Blockschaltbild, das ein Grafikprozessor-Befehlsformat 700 gemäß einigen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die GrafikprozessorAusführungseinheiten einen Befehlssatz mit Anweisungen in mehreren Formaten. Die Kästchen mit durchgezogenen Linien veranschaulichen die Komponenten, die im Allgemeinen in einer Ausführungseinheitsanweisung eingeschlossen sind, während die gestrichelten Linien Komponenten einschließen, die optional sind oder die nur in einer Teilmenge der Anweisungen eingeschlossen sind. In einigen Ausführungsformen handelt es sich bei dem beschriebenen und veranschaulichten Befehlsformat 700 um Makroanweisungen, da es sich um Anweisungen handelt, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die sich aus der Befehlsdecodierung ergeben, sobald die Anweisung verarbeitet wurde.
In einigen Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten nativ Anweisungen in einem 128-Bit-Befehlsformat 710. Ein 64-Bit-komprimiertes Befehlsformat 730 ist für einige Anweisungen basierend auf der ausgewählten Anweisung, den 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 im 64-Bit-Format 730 eingeschränkt sind. Die nativen Anweisungen, die im 64-Bit-Format 730 verfügbar sind, variieren je nach Ausführungsform. In einigen Ausführungsformen wird die Anweisung teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 komprimiert. Die Ausführungseinheitshardware verweist auf einen Satz von Komprimierungstabellen basierend auf den Indexwerten und verwendet die Komprimierungstabellenausgaben, um eine native Anweisung im 128-Bit-Befehlsformat 710 zu rekonstruieren.
Für jedes Format definiert der Befehls-Opcode 712 die Operation, die die Ausführungseinheit ausführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden aus. Beispielsweise führt die Ausführungseinheit in Reaktion auf eine Additionsanweisung eine gleichzeitige Additionsoperation über jeden Farbkanal durch, der ein Texturelement oder ein Bildelement repräsentiert. Die Ausführungseinheit führt standardmäßig jede Anweisung über alle Datenkanäle der Operanden durch. In einigen Ausführungsformen ermöglicht das Befehlssteuerfeld 714 die Steuerung bestimmter Ausführungsoptionen, wie beispielsweise der Kanalauswahl (z. B. Prädikation) und der Datenkanalreihenfolge (z. B. Swizzle). Für Anweisungen im 128-Bit-Befehlsformat 710 begrenzt ein exec-size-Feld 716 die Anzahl von Datenkanälen, die parallel ausgeführt werden. In einigen Ausführungsformen ist das exec-size-Feld 716 nicht zur Verwendung im 64-Bit-komprimierten Befehlsformat 730 verfügbar.
Einige Ausführungseinheitsanweisungen haben bis zu drei Operanden, einschließlich zweier Quelloperanden, src0 720, src1 722, und eines Ziels 718. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Anweisungen mit zwei Zielen, wobei eines der Ziele impliziert ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden (z. B. SRC2 724) aufweisen, wobei der Befehls-Opcode 712 die Anzahl der Quelloperanden bestimmt. Der letzte Quelloperand einer Anweisung kann ein Immediate-Wert (z. B. festcodierter Wert) sein, der mit der Anweisung weitergeleitet wird.
In einigen Ausführungsformen beinhaltet das 128-Bit-Befehlsformat 710 ein Zugriffs-/Adressmodusfeld 726, das beispielsweise angibt, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn der direkte Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
In einigen Ausführungsformen beinhaltet das 128-Bit-Befehlsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung angibt. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Einige Ausführungsformen unterstützen Zugriffsmodi, einschließlich eines 16-Byte-ausgerichteten Zugriffsmodus und eines 1-Byte-ausgerichteten Zugriffsmodus, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Befehlsoperanden bestimmt. Beispielsweise kann die Anweisung in einem ersten Modus eine Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und in einem zweiten Modus kann die Anweisung eine 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressmodusabschnitt des Zugriffs-/Adressmodusfelds 726, ob die Anweisung eine direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, stellen Bits in der Anweisung die Registeradresse eines oder mehrerer Operanden direkt bereit. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem Adress-Immediate-Feld in der Anweisung berechnet werden.
In einigen Ausführungsformen werden Anweisungen basierend auf Opcode-712-Bitfeldern gruppiert, um die Opcode-Decodierung 740 zu vereinfachen. Bei einem 8-Bit-Opcode ermöglichen die Bits 4, 5 und 6 der Ausführungseinheit, den Typ des Opcodes zu bestimmen. Die gezeigte präzise Opcode-Gruppierung ist lediglich ein Beispiel. In einigen Ausführungsformen beinhaltet eine Bewegungs- und Logik-Opcode-Gruppe 742 Datenbewegungs- und Logikanweisungen (z. B. Bewegen (mov), Vergleichen (cmp)). In einigen Ausführungsformen teilen sich die Bewegungs- und Logikgruppe 742 die fünf höchstwertigen Bits (MSB, Most Significant Bits), wobei Bewegungs- (mov-) Anweisungen in Form von 0000xxxxb sind und Logikanweisungen in Form von 0001xxxxb sind. Eine Flusssteuerbefehlsgruppe 744 (z. B. Aufruf, Sprung (jmp)) beinhaltet Anweisungen in Form von 0010xxxxb (z. B. 0x20). Eine sonstige Befehlsgruppe 746 beinhaltet eine Mischung von Anweisungen, einschließlich Synchronisationsanweisungen (z. B. Warten, Senden) in Form von 0011xxxxb (z. B. 0x30). Eine parallele Mathematikbefehlsgruppe 748 beinhaltet komponentenweise arithmetische Anweisungen (z. B. Addieren, Multiplizieren (mul)) in Form von 0100xxxxb (z. B. 0x40). Die parallele Mathematikgruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle hinweg aus. Die Vektormathematikgruppe 750 beinhaltet arithmetische Anweisungen (z. B. dp4) in Form von 0101xxxxb (z. B. 0x50). Die Vektormathematikgruppe führt Arithmetik wie Skalarproduktberechnungen an Vektoroperanden durch.
Grafik-Pipeline
8 ist ein Blockschaltbild einer anderen Ausführungsform eines Grafikprozessors 800. Elemente von 8, die die gleichen Bezugszeichen (oder Namen) wie die Elemente von einer beliebigen anderen Figur hierin aufweisen, können auf eine ähnliche Weise wie die an anderer Stelle hierin beschriebene arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt.
In einigen Ausführungsformen beinhaltet der Grafikprozessor 800 eine Geometrie-Pipeline 820, eine Medien-Pipeline 830, eine Anzeige-Engine 840, eine Thread-Ausführungslogik 850 und eine Render-Ausgabe-Pipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkern-Verarbeitungssystems, das einen oder mehrere Allzweck-Verarbeitungskerne aufweist. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle gesteuert, die über ein Ring-Interconnect 802 an den Grafikprozessor 800 ausgegeben werden. In einigen Ausführungsformen koppelt das Ring-Interconnect 802 den Grafikprozessor 800 mit anderen Verarbeitungskomponenten, wie beispielsweise anderen Grafikprozessoren oder Allzweck-Prozessoren. Befehle vom Ring-Interconnect 802 werden durch einen Befehls-Streamer 803 interpretiert, der Anweisungen an einzelne Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 liefert.
In einigen Ausführungsformen leitet der Befehls-Streamer 803 die Operation eines Vertex-Fetchers 805, der Vertex-Daten aus dem Speicher liest und Vertex-Verarbeitungsbefehle ausführt, die vom Befehls-Streamer 803 bereitgestellt werden. In einigen Ausführungsformen stellt der Vertex-Fetcher 805 Vertex-Daten an einen Vertex-Shader 807 bereit, der für jeden Vertex Koordinatenraumtransformations- und Beleuchtungsoperationen durchführt. In einigen Ausführungsformen führen der Vertex-Fetcher 805 und der Vertex-Shader 807 Vertex-Verarbeitungsanweisungen durch Versenden von Ausführungs-Threads an die Ausführungseinheiten 852A-852B über einen Thread-Dispatcher 831 aus.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B ein Array von Vektorprozessoren mit einem Befehlssatz zum Durchführen von Grafik- und Medienoperationen. In einigen Ausführungsformen weisen die Ausführungseinheiten 852A-852B einen angeschlossenen L1-Cache 851 auf, der für jedes Array spezifisch ist oder von den Arrays gemeinsam genutzt wird. Der Cache kann als ein Datencache, ein Befehlscache oder ein einzelner Cache konfiguriert sein, der partitioniert ist, um Daten und Anweisungen in verschiedenen Partitionen zu enthalten.
In einigen Ausführungsformen weist die Geometrie-Pipeline 820 Tessellationskomponenten auf, um eine hardwarebeschleunigte Tessellation von 3D-Objekten durchzuführen. In einigen Ausführungsformen konfiguriert ein programmierbarer Hüllen-Shader 811 die Tessellationsoperationen. Ein programmierbarer Domänen-Shader 817 stellt eine Backend-Bewertung der Tessellationsausgabe bereit. Ein Tessellator 813 arbeitet in der Richtung des Hüllen-Shaders 811 und enthält eine Spezialzweck-Logik zum Generieren eines Satzes detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell, das als Eingabe für die Geometrie-Pipeline 820 bereitgestellt wird. In einigen Ausführungsformen können, falls keine Tessellation verwendet wird, Tessellationskomponenten (z. B. Hüllen-Shader 811, Tessellator 813 und Domänen-Shader 817) umgangen werden.
In einigen Ausführungsformen können vollständige geometrische Objekte von einem Geometrie-Shader 819 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 852A-852B versendet werden, oder können direkt zum Clipper 829 weitergeleitet werden. In einigen Ausführungsformen arbeitet der Geometrie-Shader auf ganzen geometrischen Objekten anstelle von Vertices oder Patches von Vertices wie in vorherigen Stufen der Grafik-Pipeline. Falls die Tessellation deaktiviert ist, empfängt der Geometrie-Shader 819 eine Eingabe vom Vertex-Shader 807. In einigen Ausführungsformen ist der Geometrie-Shader 819 durch ein Geometrie-Shader-Programm programmierbar, um eine Geometrietessellation durchzuführen, falls die Tessellationseinheiten deaktiviert sind.
Vor der Rasterung verarbeitet ein Clipper 829 Vertex-Daten. Der Clipper 829 kann ein Festfunktions-Clipper oder ein programmierbarer Clipper mit Clipping- und Geometrie-Shader-Funktionen sein. In einigen Ausführungsformen versendet eine Rasterizer- und Tiefentestkomponente 873 in der Render-Ausgabe-Pipeline 870 Pixel-Shader, um die geometrischen Objekte in Pro-Pixel-Repräsentationen umzuwandeln. In einigen Ausführungsformen ist die Pixel-Shader-Logik in der Thread-Ausführungslogik 850 eingeschlossen. In einigen Ausführungsformen kann eine Anwendung den Rasterizer und die Tiefentestkomponente 873 umgehen und über eine Stream-Out-Einheit 823 auf nicht gerasterte Vertex-Daten zugreifen.
Der Grafikprozessor 800 weist einen Interconnect-Bus, eine Interconnect-Fabric oder einen anderen Interconnect-Mechanismus auf, der das Weiterleiten von Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors ermöglicht. In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B und die assoziierten Logikeinheiten (z. B. L1-Cache 851, Sampler 854, Texturcache 858 usw.) über einen Datenport 856 miteinander verbunden, um einen Speicherzugriff durchzuführen und mit Render-Ausgabe-Pipeline-Komponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen weisen der Sampler 854, die Caches 851, 858 und die Ausführungseinheiten 852A-852B jeweils separate Speicherzugriffspfade auf. In einer Ausführungsform kann der Texturcache 858 auch als Sampler-Cache konfiguriert sein.
In einigen Ausführungsformen enthält die Render-Ausgabe-Pipeline 870 eine Rasterizer- und Tiefentestkomponente 873, die vertexbasierte Objekte in eine assoziierte pixelbasierte Repräsentation umwandelt. In einigen Ausführungsformen weist die Rasterizer-Logik eine Windower/Masker-Einheit auf, um eine Festfunktions-Dreiecks- und Linienrasterung durchzuführen. In einigen Ausführungsformen sind auch ein assoziierter Render-Cache 878 und Tiefencache 879 verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten durch, obwohl in einigen Fällen Pixeloperationen, die mit 2D-Operationen assoziiert sind (z. B. Bitblock-Bildübertragungen mit Blending), von der 2D-Engine 841 durchgeführt oder zur Anzeigezeit durch den Anzeigecontroller 843 unter Verwendung von Überlagerungsanzeigeebenen ersetzt werden. In einigen Ausführungsformen steht allen Grafikkomponenten ein gemeinsam genutzter L3-Cache 875 zur Verfügung, wodurch die gemeinsame Nutzung von Daten ohne Verwendung des Hauptsystemspeichers ermöglicht wird.
In einigen Ausführungsformen weist die Grafikprozessor-Medien-Pipeline 830 eine Medien-Engine 837 und ein Video-Frontend 834 auf. In einigen Ausführungsformen empfängt das Video-Frontend 834 Pipeline-Befehle vom Befehls-Streamer 803. In einigen Ausführungsformen weist die Medien-Pipeline 830 einen separaten Befehls-Streamer auf. In einigen Ausführungsformen verarbeitet das Video-Frontend 834 Medienbefehle, bevor der Befehl an die Medien-Engine 837 gesendet wird. In einigen Ausführungsformen weist die Medien-Engine 837 eine Thread-Spawning-Funktionalität auf, um Threads zum Versenden an die Thread-Ausführungslogik 850 über den Thread-Dispatcher 831 zu erzeugen.
In einigen Ausführungsformen weist der Grafikprozessor 800 eine Anzeige-Engine 840 auf. In einigen Ausführungsformen befindet sich die Anzeige-Engine 840 außerhalb des Prozessors 800 und ist über das Ring-Interconnect 802 oder einen anderen Interconnect-Bus oder eine Interconnect-Fabric mit dem Grafikprozessor gekoppelt. In einigen Ausführungsformen weist die Anzeige-Engine 840 eine 2D-Engine 841 und einen Anzeigecontroller 843 auf. In einigen Ausführungsformen weist die Anzeige-Engine 840 eine Spezialzweck-Logik auf, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen ist der Anzeigecontroller 843 mit einer Anzeigevorrichtung (nicht gezeigt) gekoppelt, die eine systemintegrierte Anzeigevorrichtung, wie beispielsweise in einem Laptop-Computer, oder eine externe Anzeigevorrichtung, die über einen Anzeigevorrichtungsverbinder angeschlossen ist, sein kann.
In einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 konfigurierbar, um Operationen basierend auf mehreren Grafik- und Medienprogrammierschnittstellen durchzuführen, und sind nicht spezifisch für eine Anwendungsprogrammierschnittstelle (API, Application Programming Interface). In einigen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die vom Grafikprozessor verarbeitet werden können. In einigen Ausführungsformen wird Unterstützung für die Open Graphics Library (OpenGL), die Open Computing Language (OpenCL) und/oder die Vulkan-Grafik- und Rechen-API bereitgestellt, die alle von der Khronos Group stammen. 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 auch unterstützt werden, falls eine Abbildung von der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors vorgenommen werden kann.
Grafik-Pipeline-Programmierung
9A ist ein Blockschaltbild, das ein Grafikprozessor-Befehlsformat 900 gemäß einigen Ausführungsformen veranschaulicht. 9B ist ein Blockschaltbild, das eine Grafikprozessor-Befehlssequenz 910 gemäß einer Ausführungsform veranschaulicht. Die Kästchen mit durchgezogenen Linien in 9A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl eingeschlossen sind, während die gestrichelten Linien Komponenten einschließen, die optional sind oder die nur in einer Teilmenge der Grafikbefehle eingeschlossen sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 aus 9A weist Datenfelder zum Identifizieren eines Clients 902, einen Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl auf. Ein Sub-Opcode 905 und eine Befehlsgröße 908 sind auch in einigen Befehlen eingeschlossen.
In einigen Ausführungsformen gibt der Client 902 die Clienteinheit der Grafikvorrichtung an, die die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessorbefehls-Parser das Clientfeld jedes Befehls, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten an die entsprechende Clienteinheit weiterzuleiten. In einigen Ausführungsformen weisen die Grafikprozessor-Clienteinheiten eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit auf. Jede Clienteinheit weist eine entsprechende Verarbeitungs-Pipeline auf, die die Befehle verarbeitet. Sobald der Befehl von der Clienteinheit empfangen wurde, liest die Clienteinheit den Opcode 904 und, falls vorhanden, den Sub-Opcode 905, um die durchzuführende Operation zu bestimmen. Die Clienteinheit führt den Befehl unter Verwendung von Informationen im Datenfeld 906 durch. Bei einigen Befehlen wird eine explizite Befehlsgröße 908 erwartet, um die Größe des Befehls anzugeben. In einigen Ausführungsformen bestimmt der Befehls-Parser automatisch die Größe von wenigstens einigen der Befehle basierend auf dem Befehls-Opcode. In einigen Ausführungsformen werden Befehle über Vielfache eines Doppelworts ausgerichtet.
Das Flussdiagramm in 9B veranschaulicht eine beispielhafte Grafikprozessor-Befehlssequenz 910. 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 nur zu Beispielzwecken gezeigt und beschrieben, da Ausführungsformen nicht auf diese speziellen Befehle oder auf diese Befehlssequenz beschränkt sind. Darüber hinaus können die Befehle als Batch von Befehlen in einer Befehlssequenz ausgegeben werden, so dass der Grafikprozessor die Befehlssequenz wenigstens teilweise gleichzeitig verarbeitet.
In einigen Ausführungsformen kann die Grafikprozessor-Befehlssequenz 910 mit einem Pipeline-Flush-Befehl 912 beginnen, um zu bewirken, dass eine beliebige aktive Grafik-Pipeline die aktuell anstehenden Befehle für die Pipeline abschließt. In einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Der Pipeline-Flush wird durchgeführt, um zu bewirken, dass die aktive Grafik-Pipeline alle anstehenden Befehle abschließt. In Reaktion auf einen Pipeline-Flush pausiert der Befehls-Parser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichen-Engines anstehende Operationen abschließen und die relevanten Lesecaches invalidiert sind. Optional können alle Daten im Render-Cache, die als „schmutzig“ markiert sind, in den Speicher geleert werden. In einigen Ausführungsformen kann der Pipeline-Flush-Befehl 912 zur Pipeline-Synchronisation oder vor dem Versetzen des Grafikprozessors in einen Low-Power-Zustand verwendet werden.
In einigen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. In einigen Ausführungsformen ist ein Pipeline-Auswahlbefehl 913 in einem Ausführungskontext nur einmal erforderlich, bevor Pipeline-Befehle ausgegeben werden, es sei denn, der Kontext soll Befehle für beide Pipelines ausgeben. In einigen Ausführungsformen ist ein Pipeline-Flush-Befehl 912 unmittelbar vor einem Pipeline-Wechsel über den Pipeline-Auswahlbefehl 913 erforderlich.
In einigen Ausführungsformen konfiguriert ein Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für den Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medien-Pipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Pipeline-Steuerbefehl 914 den Pipeline-Zustand für die aktive Pipeline. In einer Ausführungsform wird der Pipeline-Steuerbefehl 914 zur Pipeline-Synchronisation und zum Löschen von Daten aus einem oder mehreren Cachespeichern innerhalb der aktiven Pipeline verwendet, bevor ein Batch von Befehlen verarbeitet wird.
In einigen Ausführungsformen werden Rückgabepufferzustandsbefehle 916 verwendet, um einen Satz von Rückgabepuffern für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen während der Verarbeitung Zwischendaten schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und eine Cross-Thread-Kommunikation durchzuführen. In einigen Ausführungsformen schließt der Rückgabepufferzustand 916 das Auswählen der Größe und Anzahl von Rückgabepuffern ein, die für einen Satz von Pipeline-Operationen verwendet werden sollen.
Die verbleibenden Befehle in der Befehlssequenz unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipeline-Bestimmung 920 wird die Befehlssequenz auf die 3D-Pipeline 922 beginnend mit dem 3D-Pipeline-Zustand 930 oder die Medien-Pipeline 924 beginnend mit dem Medien-Pipeline-Zustand 940 zugeschnitten.
Die Befehle zum Konfigurieren des 3D-Pipeline-Zustands 930 beinhalten 3D-Zustandseinstellungsbefehle für den Vertex-Pufferzustand, den Vertex-Elementzustand, den konstanten Farbzustand, den Tiefenpufferzustand und andere Zustandsvariablen, die konfiguriert werden sollen, bevor 3D-Primitivbefehle verarbeitet werden. Die Werte dieser Befehle werden wenigstens teilweise basierend auf der bestimmten verwendeten 3D-API bestimmt. In einigen Ausführungsformen können Befehle des 3D-Pipeline-Zustands 930 auch bestimmte Pipeline-Elemente selektiv deaktivieren oder umgehen, falls diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird der Befehl des 3D-Primitivs 932 verwendet, um 3D-Primitive einzureichen, die von der 3D-Pipeline verarbeitet werden sollen. Befehle und assoziierte Parameter, die über den Befehl des 3D-Primitivs 932 an den Grafikprozessor übergeben werden, werden an die Vertex-Fetch-Funktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Fetch-Funktion verwendet die Befehlsdaten des 3D-Primitivs 932, um Vertex-Datenstrukturen zu generieren. Die Vertex-Datenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der Befehl des 3D-Primitivs 932 verwendet, um Vertex-Operationen an 3D-Primitiven über Vertex-Shader durchzuführen. Um Vertex-Shader zu verarbeiten, versendet die 3D-Pipeline 922 Shader-Ausführungs-Threads an Grafikprozessor-Ausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Befehl oder ein Ereignis zur Ausführung 934 ausgelöst. In einigen Ausführungsformen löst ein Registerschreibvorgang eine Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über einen „Go“- oder „Kick“-Befehl in der Befehlssequenz ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipeline-Synchronisationsbefehls ausgelöst, um die Befehlssequenz durch die Grafik-Pipeline zu leeren. Die 3D-Pipeline führt eine Geometrieverarbeitung für die 3D-Primitive durch. Sobald die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixel-Engine färbt die resultierenden Pixel. Für diese Operationen können auch zusätzliche Befehle zum Steuern der Pixel-Shading- und Pixel-Backend-Operationen eingeschlossen werden.
In einigen Ausführungsformen folgt die Grafikprozessor-Befehlssequenz 910 dem Pfad der Medien-Pipeline 924, wenn Medienoperationen durchgeführt werden. Im Allgemeinen hängt die spezielle Verwendung und Art der Programmierung für die Medien-Pipeline 924 von den durchzuführenden Medien- oder Rechenoperationen ab. Bestimmte Mediendecodierungsoperationen können während der Mediendecodierung in die Medien-Pipeline ausgelagert werden. In einigen Ausführungsformen kann die Medien-Pipeline auch umgangen werden, und die Mediendecodierung kann ganz oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Allzweck-Verarbeitungskernen bereitgestellt werden. In einer Ausführungsform beinhaltet die Medien-Pipeline auch Elemente für Operationen einer Allzweck-Grafikprozessoreinheit (GPGPU, General-Purpose Graphics Processor Unit), wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Rechen-Shader-Programmen durchzuführen, die nicht explizit mit dem Rendering von Grafikprimitiven zusammenhängen.
In einigen Ausführungsformen ist die Medien-Pipeline 924 auf ähnliche Weise wie die 3D-Pipeline 922 konfiguriert. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipeline-Zustands 940 wird vor den Medienobjektbefehlen 942 versendet oder in eine Befehlswarteschlange platziert. In einigen Ausführungsformen schließen Befehle für den Medien-Pipeline-Zustand 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente ein, die zum Verarbeiten der Medienobjekte verwendet werden. Dies beinhaltet Daten zum Konfigurieren der Videodecodierungs- und Videocodierungslogik innerhalb der Medien-Pipeline, wie beispielsweise das Codierungs- oder Decodierungsformat. In einigen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Zustand 940 auch die Verwendung eines oder mehrerer Zeiger auf „indirekte“ Zustandselemente, die einen Batch von Zustandseinstellungen enthalten.
In einigen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger zu Medienobjekten zur Verarbeitung durch die Medien-Pipeline. Die Medienobjekte weisen Speicherpuffer auf, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medien-Pipeline-Zustände gültig sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Sobald der Pipeline-Zustand konfiguriert ist und Medienobjektbefehle 942 in die Warteschlange gestellt sind, wird die Medien-Pipeline 924 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (z. B. Registerschreibvorgang) ausgelöst. Die Ausgabe von der Medien-Pipeline 924 kann dann durch Operationen, die von der 3D-Pipeline 922 oder der Medien-Pipeline 924 bereitgestellt werden, nachbearbeitet werden. In einigen Ausführungsformen werden GPGPU-Operationen auf ähnliche Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafiksoftwarearchitektur
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß einigen Ausführungsformen. In einigen Ausführungsformen weist die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und wenigstens einen Prozessor 1030 auf. In einigen Ausführungsformen weist der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Allzweck-Prozessorkerne 1034 auf. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programme, die Shader-Anweisungen 1012 einschließen. Die Shader-Sprachanweisungen können in einer höheren Shader-Sprache vorliegen, wie beispielsweise der High-Level-Shader-Sprache (HLSL, High Level Shader Language) oder der OpenGL-Shader-Sprache (GLSL, OpenGL Shader Language). Die Anwendung weist auch ausführbare Anweisungen 1014 in einer Maschinensprache auf, die zur Ausführung durch den Allweck-Prozessorkern 1034 geeignet ist. Die Anwendung beinhaltet auch Grafikobjekte 1016, die durch Vertex-Daten definiert sind.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows® Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein Open-Source-UNIX-ähnliches Betriebssystem, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022, wie beispielsweise die Direct3D-API, die OpenGL-API oder die Vulkan-API, unterstützen. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 1020 einen Frontend-Shader-Compiler 1024, um alle Shader-Anweisungen 1012 in HLSL in eine niedrigere Shader-Sprache zu kompilieren. Die Kompilierung kann eine Just-in-Time-Kompilierung (JIT-Kompilierung) sein, oder die Anwendung kann eine Shader-Vorkompilierung durchführen. In einigen Ausführungsformen werden Shader auf hoher Ebene während des Kompilierens der 3D-Grafikanwendung 1010 zu Shadern auf niedriger Ebene kompiliert. In einigen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform bereitgestellt, wie beispielsweise einer Version der Standard Portable Intermediate Representation (SPIR), die von der Vulkan-API verwendet wird.
In einigen Ausführungsformen enthält der Benutzermodus-Grafiktreiber 1026 einen Backend-Shader-Compiler 1027, um die Shader-Anweisungen 1012 in eine hardwarespezifische Repräsentation umzuwandeln. Wenn die OpenGL-API verwendet wird, werden Shader-Anweisungen 1012 in der GLSL-Hochsprache zur Kompilierung an einen Benutzermodus-Grafiktreiber 1026 übergeben. In einigen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystem-Kernel-Modus-Funktionen 1028, um mit einem Kernel-Modus-Grafiktreiber 1029 zu kommunizieren. In einigen Ausführungsformen kommuniziert der Kernel-Modus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen zu versenden.
IP-Kern-Implementlerungen
Ein oder mehrere Aspekte von wenigstens einer Ausführungsform können durch repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik in einer integrierten Schaltung, wie beispielsweise einem Prozessor, repräsentiert und/oder definiert. Beispielsweise kann das maschinenlesbare Medium Anweisungen aufweisen, die verschiedene Logik innerhalb des Prozessors repräsentieren. Beim Lesen durch eine Maschine können die Anweisungen die Maschine veranlassen, die Logik herzustellen, um die hierin beschriebenen Techniken durchzuführen. Derartige Repräsentationen, bekannt als „IP-Kerne“, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem konkreten, maschinenlesbaren Medium als ein Hardwaremodell gespeichert sein können, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann an verschiedene Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Fertigungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann so gefertigt sein, dass die Schaltung Operationen durchführt, die in Verbindung mit einer beliebigen der hierin beschriebenen Ausführungsformen beschrieben werden.
11A ist ein Blockschaltbild, das ein IP-Kern-Entwicklungssystem 1100 veranschaulicht, das zum Herstellen einer integrierten Schaltung zum Durchführen von Operationen gemäß einer Ausführungsform verwendet werden kann. Das IP-Kern-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs zu generieren, die in ein größeres Design integriert werden können oder zum Aufbau einer gesamten integrierten Schaltung (z. B. einer integrierten SOC-Schaltung) verwendet werden können. Eine Designeinrichtung 1130 kann eine Softwaresimulation 1110 eines IP-Kern-Designs in einer höheren Programmiersprache (z. B. C/C++) generieren. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu entwerfen, zu testen und zu verifizieren. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Timing-Simulationen einschließen. Ein Register-Transfer-Level(RTL)-Design 1115 kann dann aus dem Simulationsmodell 1112 erstellt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Signale zwischen Hardwareregistern modelliert, einschließlich der assoziierten Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs niedrigerer Ebenen auf der Logikebene oder der Transistorebene erstellt, entworfen oder synthetisiert werden. Somit können die besonderen Details des anfänglichen Designs und der Simulation variieren.
Das RTL-Design 1115 oder ein Äquivalent kann von der Designeinrichtung ferner zu einem Hardwaremodell 1120 synthetisiert werden, das in einer Hardwarebeschreibungssprache (HDL, Hardware Description Language) oder einer anderen Repräsentation physikalischer Designdaten sein kann. Die HDL kann ferner simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann zur Lieferung an eine Fertigungseinrichtung 1165 eines Dritten unter Verwendung eines nichtflüchtigen Speichers 1140 (z. B. Festplatte, Flash-Speicher oder ein beliebiges nichtflüchtiges Speicherungsmedium) gespeichert werden. Alternativ kann das IP-Kern-Design (z. B. über das Internet) über eine drahtgebundene Verbindung 1150 oder eine drahtlose Verbindung 1160 gesendet werden. Die Fertigungseinrichtung 1165 kann dann eine integrierte Schaltung fertigen, die wenigstens teilweise auf dem IP-Kern-Design basiert. Die gefertigte integrierte Schaltung kann konfiguriert sein, um Operationen gemäß wenigstens einer hierin beschriebenen Ausführungsform durchzuführen.
11B veranschaulicht eine Querschnittsseitenansicht einer Package-Baugruppe 1170 für integrierte Schaltungen gemäß einigen hierin beschriebenen Ausführungsformen. Die Package-Baugruppe 1170 für integrierte Schaltungen veranschaulicht eine Implementierung von einer oder mehreren Prozessor- oder Beschleunigervorrichtungen, wie hierin beschrieben. Die Package-Baugruppe 1170 weist mehrere Einheiten von Hardwarelogik 1172, 1174 auf, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann wenigstens teilweise in einer Hardware für konfigurierbare Logik oder Festfunktionslogik implementiert sein und kann einen oder mehrere Abschnitte von einem beliebigen der hierin beschriebenen Prozessorkerne, Grafikprozessoren oder anderen Beschleunigervorrichtungen einschließen. Jede Einheit von Logik 1172, 1174 kann in einem Halbleiter-Die implementiert und über eine Interconnect-Struktur 1173 mit dem Substrat 1180 gekoppelt sein. Die Interconnect-Struktur 1173 kann konfiguriert sein, um elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten, und kann Interconnects einschließen, wie beispielsweise Bumps oder Pillars, ohne darauf beschränkt zu sein. In einigen Ausführungsformen kann die Interconnect-Struktur 1173 so konfiguriert sein, dass sie elektrische Signale leitet, wie beispielweise Eingabe-/Ausgabesignale (E/A-Signale) und/oder Strom- oder Massesignale, die mit der Operation der Logik 1172, 1174 assoziiert sind. In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidbasis. Die Package-Baugruppe 1170 kann in anderen Ausführungsformen andere geeignete Typen von Substraten einschließen. Die Package-Baugruppe 1170 kann über ein Package-Interconnect 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Das Package-Interconnect 1183 kann mit einer Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale an andere elektrische Vorrichtungen, wie beispielsweise ein Motherboard, einen anderen Chipsatz oder ein Multi-Chip-Modul, zu leiten.
In einigen Ausführungsformen sind die Einheiten der Logik 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die konfiguriert ist, um 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 aufweisen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Auf dem Brückensubstrat können elektrische Routingmerkmale ausgebildet 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 veranschaulicht sind, können die hierin beschriebenen Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies einschließen. Der eine oder die mehreren Dies können durch null oder mehrere Brücken verbunden sein, da die Brücke 1182 ausgeschlossen sein kann, wenn die Logik auf einem einzelnen Die eingeschlossen ist. Alternativ können mehrere Dies oder Logikeinheiten durch eine oder mehrere Brücken verbunden sein. Zusätzlich können mehrere Logikeinheiten, Dies und Brücken in anderen möglichen Konfigurationen, einschließlich dreidimensionaler Konfigurationen, miteinander verbunden sein.
Beispielhafte integrierte System-on-a-Chip-Schaltung
12-14 veranschaulichen beispielhafte integrierte Schaltungen und assoziierte Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden können, gemäß verschiedenen hierin beschriebenen Ausführungsformen. Zusätzlich zu dem, was veranschaulicht ist, können andere Logik und Schaltungen eingeschlossen sein, unter anderem zusätzliche Grafikprozessoren/-kerne, periphere Schnittstellencontroller oder Allzweck -Prozessorkerne.
12 ist ein Blockschaltbild, das eine beispielhafte integrierte System-on-a-Chip-Schaltung 1200, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform veranschaulicht. Die beispielhafte integrierte Schaltung 1200 beinhaltet einen oder mehrere Anwendungsprozessoren 1205 (z. B. CPUs), wenigstens einen Grafikprozessor 1210 und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 einschließen, von denen jeder ein modularer IP-Kern von derselben oder mehreren unterschiedlichen Designeinrichtungen sein kann. Die integrierte Schaltung 1200 schließt eine Peripherie- oder Buslogik ein, einschließlich USB-Controller 1225, UART-Controller 1230, SPI/SDIO-Controller 1235 und I²S/I²C-Controller 1240. Zusätzlich kann die integrierte Schaltung eine Anzeigevorrichtung 1245 einschließen, die mit einem oder mehreren von einem Controller 1250 für eine High-Definition-Multimedia-Schnittstelle (HDMI, High-Definition Multimedia Interface) und/oder einer Mobile-Industry-Processor-Interface(MIPI)-Anzeigeschnittstelle 1255 gekoppelt ist. Die Speicherung kann durch ein Flash-Speichersubsystem 1260 einschließlich eines Flash-Speichers und eines Flash-Speichercontrollers bereitgestellt werden. Die Speicherschnittstelle kann über einen Speichercontroller 1265 für den Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt werden. Einige integrierte Schaltungen weisen zusätzlich eine eingebettete Sicherheits-Engine 1270 auf.
13A-13B sind Blockschaltbilder, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC gemäß hierin beschriebenen Ausführungsformen veranschaulichen. 13A veranschaulicht einen beispielhaften Grafikprozessor 1310 einer integrierten System-on-a-Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform. 13B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 1340 einer integrierten System-on-a-Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform. Der Grafikprozessor 1310 aus 13A ist ein Beispiel eines Low-Power-Grafikprozessorkerns. Der Grafikprozessor 1340 aus 13B ist ein Beispiel eines Grafikprozessorkerns mit höherer Leistung. Jeder der Grafikprozessoren 1310, 1340 kann eine Variante des Grafikprozessors 1210 aus 12 sein.
Wie in 13A gezeigt, schließt der Grafikprozessor 1310 einen Vertex-Prozessor 1305 und einen oder mehrere Fragmentprozessoren 1315A-1315N (z. B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N) ein. Der Grafikprozessor 1310 kann verschiedene Shader-Programme über eine separate Logik ausführen, so dass der Vertex-Prozessor 1305 für die Ausführung von Operationen für Vertex-Shader-Programme optimiert ist, während der eine oder die mehreren Fragmentprozessoren 1315A-1315N Fragment-Shading-Operationen (z. B. Pixel-Shading-Operationen) für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertex-Prozessor 1305 führt die Vertex-Verarbeitungsstufe der 3D-Grafik-Pipeline durch und generiert Primitive und Vertex-Daten. Der/die Fragmentprozessor(en) 1315A-1315N verwendet/verwenden die vom Vertex-Prozessor 1305 generierten Primitiv- und Vertex-Daten, um einen Frame-Puffer zu erzeugen, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform sind der/die Fragmentprozessor(en) 1315A-1315N optimiert, um Fragment-Shader-Programme auszuführen, wie in der OpenGL-API bereitgestellt, die verwendet werden können, um ähnliche Operationen wie ein Pixel-Shader-Programm durchzuführen, wie in der Direct3D-API bereitgestellt.
Der Grafikprozessor 1310 weist zusätzlich eine oder mehrere Speichermanagementeinheiten (MMUs, Memory Management Units) 1320A-1320B, einen oder mehrere Caches 1325A-1325B und ein oder mehrere Schaltungs-Interconnects 1330A-1330B auf. Die eine oder mehreren MMUs 1320A-1320B stellen eine Abbildung von virtueller zu physikalischer Adresse für den Grafikprozessor 1310 bereit, einschließlich des Vertex-Prozessors 1305 und/oder der Fragmentprozessoren 1315A-1315N, die zusätzlich zu den in dem einen oder den mehreren Caches 1325A-1325B gespeicherten Vertex- oder Bild-/Texturdaten auf im Speicher gespeicherte Vertex- oder Bild-/Texturdaten verweisen können. In einer Ausführungsform können die eine oder mehreren MMUs 1320A-1320B mit anderen MMUs innerhalb des Systems synchronisiert sein, einschließlich einer oder mehrerer MMUs, die mit dem einen oder den mehreren Anwendungsprozessoren 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 aus 12 assoziiert sind, so dass jeder Prozessor 1205-1220 an einem gemeinsam genutzten oder vereinheitlichten virtuellen Speichersystem teilnehmen kann. Das eine oder die mehreren Schaltungs-Interconnects 1330A-1330B ermöglichen es dem Grafikprozessor 1310, mit anderen IP-Kernen innerhalb des SoC eine Schnittstelle zu bilden, entweder über einen internen Bus des SoC oder über eine direkte Verbindung gemäß Ausführungsformen.
Wie in 13B gezeigt, weist der Grafikprozessor 1340 die eine oder mehreren MMUs 1320A-1320B, Caches 1325A-1325B und Schaltungs-Interconnects 1330A-1330B des Grafikprozessors 1310 aus 13A auf. Der Grafikprozessor 1340 weist einen oder mehrere Shader-Kerne 1355A-1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N) auf, wodurch eine vereinheitlichte Shader-Kernarchitektur bereitgestellt wird, in der ein einzelner Kern oder Typ von Kern alle Typen von programmierbarem Shader-Code ausführen kann, einschließlich Shader-Programmcode, um Vertex-Shader, Fragment-Shader und/oder Rechen-Shader zu implementieren. Die genaue Anzahl der vorhandenen Shader-Kerne kann zwischen Ausführungsformen und Implementierungen variieren. Zusätzlich beinhaltet der Grafikprozessor 1340 einen Inter-Core-Task-Manager 1345, der als Thread-Dispatcher fungiert, um Ausführungs-Threads an einen oder mehrere Shader-Kerne 1355A-1355N zu versenden, und eine Kachelungseinheit 1358, um Kachelungsoperationen für das kachelbasierte Rendering zu beschleunigen, wobei Rendering-Operationen für eine Szene in einen Bildraum unterteilt werden, um beispielsweise die lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder die Verwendung interner Caches zu optimieren.
14A-14B veranschaulichen zusätzliche beispielhafte Grafikprozessorlogik gemäß hierin beschriebenen Ausführungsformen. 14A veranschaulicht einen Grafikkern 1400, der innerhalb des Grafikprozessors 1210 aus 12 eingeschlossen sein kann und ein vereinheitlichter Shader-Kern 1355A-1355N wie in 13B sein kann. 14B veranschaulicht eine hochparallele Allzweck-Grafikverarbeitungseinheit 1430, die für den Einsatz auf einem Multi-Chip-Modul geeignet ist.
Wie in 14A gezeigt, weist der Grafikkern 1400 einen gemeinsam genutzten Befehlscache 1402, eine Textureinheit 1418 und einen Cache/gemeinsam genutzten Speicher 1420 auf, die den Ausführungsressourcen innerhalb des Grafikkerns 1400 gemeinsam sind. Der Grafikkern 1400 kann mehrere Slices 1401A-1401N oder Partitionen für jeden Kern aufweisen, und ein Grafikprozessor kann mehrere Instanzen des Grafikkerns 1400 aufweisen. Die Slices 1401A-1401N können eine Unterstützungslogik mit einem lokalen Befehlscache 1404A-1404N, einem Thread-Scheduler 1406A-1406N, einem Thread-Dispatcher 1408A-1408N und einem Satz von Registern 1410A aufweisen. Um logische Operationen durchzuführen, können die Slices 1401A-1401N einen Satz zusätzlicher Funktionseinheiten (AFUs (Additional Function Units) 1412A-1412N), Gleitkomma-Einheiten (FPUs (Floating-Point Units) 1414A-1414N), ganzzahlige Arithmetik-Logik-Einheiten (ALUs (Arithmetic Logic Units) 1416-1416N), Adressrecheneinheiten (ACUs (Address Computational Units) 1413A-1413N), Gleitkomma-Einheiten mit doppelter Genauigkeit (DPFPUs (Double-Precision Floating-Point Units) 1415A-1415N) und Matrixverarbeitungseinheiten (MPUs (Matrix Processing Units) 1417A-1417N) einschließen.
Einige der Recheneinheiten arbeiten mit einer bestimmten Genauigkeit. Beispielsweise können die FPUs 1414A-1414N Gleitkomma-Operationen mit einfacher Genauigkeit (32 Bit) und halber Genauigkeit (16 Bit) durchführen, während die DPFPUs 1415A-1415N Gleitkomma-Operationen mit doppelter Genauigkeit (64 Bit) durchführen. Die ALUs 1416A-1416N können Ganzzahloperationen mit variabler Genauigkeit mit 8-Bit-, 16-Bit- und 32-Bit-Genauigkeit durchführen und können für Operationen mit gemischter Genauigkeit konfiguriert werden. Die MPUs 1417A-1417N können auch für Matrixoperationen mit gemischter Genauigkeit, einschließlich Gleitkomma- und 8-Bit-Ganzzahloperationen mit halber Genauigkeit, konfiguriert werden. Die MPUs 1417-1417N können eine Vielzahl von Matrixoperationen durchführen, um Anwendungs-Frameworks für maschinelles Lernen zu beschleunigen, einschließlich Ermöglichen der Unterstützung für eine beschleunigte allgemeine Matrix-zu-Matrix-Multiplikation (GEMM, General Matrix to Matrix Multiplication). Die AFUs 1412A-1412N können zusätzliche Logikoperationen durchführen, die von den Gleitkomma- oder Ganzzahleinheiten nicht unterstützt werden, einschließlich trigonometrischer Operationen (z. B. Sinus, Cosinus usw.).
Wie in 14B gezeigt, kann eine Allzweck-Verarbeitungseinheit (GPGPU, General-Purpose Processing Unit) 1430 konfiguriert sein, um zu ermöglichen, dass hochparallele Rechenoperationen durch einen Array von Grafikverarbeitungseinheiten durchgeführt werden. Zusätzlich kann die GPGPU 1430 direkt mit anderen Instanzen der GPGPU verknüpft werden, um einen Multi-GPU-Cluster zu erzeugen, um die Trainingsgeschwindigkeit für besonders tiefe neuronale Netze zu verbessern. Die GPGPU 1430 weist eine Hostschnittstelle 1432 auf, 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 lieferantenspezifische Kommunikationsschnittstelle oder Kommunikations-Fabric sein. Die GPGPU 1430 empfängt Befehle vom Hostprozessor und verwendet einen globalen Scheduler 1434, um mit diesen Befehlen assoziierte Ausführungs-Threads an einen Satz von Rechenclustern 1436A-1436H zu verteilen. Die Rechencluster 1436A-1436H teilen einen Cachespeicher 1438. Der Cachespeicher 1438 kann als Cache höherer Ebene für Cachespeicher innerhalb der Rechencluster 1436A-1436H dienen.
Die GPGPU 1430 weist einen Speicher 1434A-1434B auf, der mit den Rechenclustern 1436A-1436H über einen Satz von Speichercontrollern 1442A-1442B gekoppelt ist. In verschiedenen Ausführungsformen kann der Speicher 1434A-1434B verschiedene Typen von Speichervorrichtungen aufweisen, einschließlich eines dynamischen Direktzugriffsspeichers (DRAM, Dynamic Random Access Memory) oder eines Grafik-Direktzugriffsspeichers, wie beispielsweise einen synchronen Grafik-Direktzugriffsspeicher (SGRAM, Synchronous Graphics Random Access Memory), einschließlich eines Grafikspeichers mit doppelter Datenrate (GDDR, Graphics Double Data Rate).
In einer Ausführungsform beinhalten die Rechencluster 1436A-1436H jeweils einen Satz von Grafikkernen, wie beispielsweise den Grafikkern 1400 aus 14A, die mehrere Typen von Ganzzahl- und Gleitkomma-Logikeinheiten aufweisen können, die Rechenoperationen mit einer Reihe von Genauigkeiten durchführen können, einschließlich der für maschinelles Lernen geeigneten Berechnungen. Beispielsweise und in einer Ausführungsform kann wenigstens eine Teilmenge der Gleitkomma-Einheiten in jedem der Rechencluster 1436A-1436H konfiguriert sein, um 16-Bit- oder 32-Bit-Gleitkomma-Operationen durchzuführen, während eine andere Teilmenge der Gleitkomma-Einheiten konfiguriert werden kann, um 64-Bit-Gleitkomma-Operationen durchzuführen.
Mehrere Instanzen der GPGPU 1430 können konfiguriert sein, um als ein Rechencluster zu arbeiten. Der Kommunikationsmechanismus, der vom Rechencluster für die Synchronisation und den Datenaustausch verwendet wird, variiert zwischen Ausführungsformen. In einer Ausführungsform kommunizieren die mehreren Instanzen der GPGPU 1430 über die Hostschnittstelle 1432. In einer Ausführungsform schließt die GPGPU 1430 einen E/A-Hub 1439 ein, der die GPGPU 1430 mit einem GPU-Link 1440 koppelt, der eine direkte Verbindung zu anderen Instanzen der GPGPU ermöglicht. In einer Ausführungsform ist der GPU-Link 1440 mit einer dedizierten GPU-zu-GPU-Brücke gekoppelt, die die Kommunikation und Synchronisation zwischen mehreren Instanzen der GPGPU 1430 ermöglicht. In einer Ausführungsform ist der GPU-Link 1440 mit einem Hochgeschwindigkeits-Interconnect gekoppelt, um Daten an andere GPGPUs oder parallele Prozessoren zu senden und zu empfangen. In einer Ausführungsform befinden sich die mehreren Instanzen der GPGPU 1430 in separaten Datenverarbeitungssystemen und kommunizieren über eine Netzvorrichtung, auf die über die Hostschnittstelle 1432 zugegriffen werden kann. In einer Ausführungsform kann der GPU-Link 1440 konfiguriert sein, um eine Verbindung zu einem Hostprozessor zusätzlich zu oder als Alternative zur Hostschnittstelle 1432 zu ermöglichen.
Während die veranschaulichte Konfiguration der GPGPU 1430 zum Trainieren neuronaler Netze konfiguriert werden kann, stellt eine Ausführungsform eine alternative Konfiguration der GPGPU 1430 bereit, die für die Bereitstellung innerhalb einer Hochleistungs- oder Low-Power-Inferenzierungsplattform konfiguriert werden kann. In einer Inferenzierungskonfiguration weist die GPGPU 1430 relativ zur Trainingskonfiguration weniger der Rechencluster 1436A-1436H auf. Zusätzlich kann sich die Speichertechnologie, die mit dem Speicher 1434A-1434B assoziiert ist, zwischen Inferenzierungs- und Trainingskonfigurationen unterscheiden, wobei Speichertechnologien mit höherer Bandbreite Trainingskonfigurationen gewidmet sind. In einer Ausführungsform kann die Inferenzierungskonfiguration der GPGPU 1430 die Inferenzierung spezieller Anweisungen unterstützen. Beispielsweise kann eine Inferenzierungskonfiguration Unterstützung für eine oder mehrere 8-Bit-Ganzzahl-Skalarprodukt-Anweisungen bereitstellen, die üblicherweise während Inferenzierungsoperationen für bereitgestellte neuronale Netze verwendet werden.
Übersicht über immersives Video
15A veranschaulicht mehrere Formen von immersivem Video. Immersives Video kann abhängig von den Freiheitsgraden, die einem Betrachter zur Verfügung stehen, in mehreren Formen präsentiert werden. Freiheitsgrade beziehen sich auf die Anzahl unterschiedlicher Richtungen, in die sich ein Objekt im dreidimensionalen (3D-) Raum bewegen kann. Immersives Video kann über eine am Kopf montierte Anzeige angesehen werden, die eine Verfolgung der Position und Orientierung beinhaltet. 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 6DoF-Video Omnidirectional 6DoF 1507 und Windowed 6DoF 1508 ein.
Bei einem Video in 3DoF 1502 (z. B. 360-Grad-Video) kann ein Betrachter die Orientierung ändern (z. B. Gieren, Nicken, Rollen), jedoch nicht die Position. Bei einem Video in 3DoF Plus 1504 kann ein Betrachter die Orientierung ändern und kleine Änderungen an Positionsänderungen vornehmen. Bei einem Video in 6DoF 1506 kann ein Betrachter die Orientierung und die Position ändern. Eingeschränktere Formen von 6DoF-Video sind auch verfügbar. Video in Omnidirectional 6DoF 1507 ermöglicht es einem Betrachter, mehrere Schritte in der virtuellen Szene zu machen. Video in Windowed 6DoF 1508 ermöglicht es einem Betrachter, die Orientierung und die Position zu ändern, der Betrachter ist jedoch auf einen begrenzten Sichtbereich beschränkt. Eine Erhöhung der verfügbaren Freiheitsgrade in einem immersiven Video beinhaltet im Allgemeinen die Erhöhung der Menge und Komplexität von Daten, die an der Erzeugung, Codierung, Decodierung und Wiedergabe von Videos beteiligt sind.
15B veranschaulicht Bildprojektions- und Texturebenen für immersives Video. Eine 3D-Ansicht 1510 von Videoinhalt kann unter Verwendung von Daten von mehreren Kameras generiert werden. Mehrere Projektionsebenen 1512 können verwendet werden, um Geometriedaten für Videoinhalt zu generieren. Für die Projektionsebenen 1512, die zum Generieren der Geometriedaten verwendet werden, können mehrere Texturebenen 1514 abgeleitet werden. Die Texturebenen 1514 können auf 3D-Modelle angewendet werden, die basierend auf einer aus Videodaten abgeleiteten Punktwolke vorgeneriert oder generiert werden. Die mehreren Projektionsebenen 1512 können verwendet werden, um mehrere zweidimensionale (2D-) Projektionen zu generieren, wobei jede Projektion mit einer Projektionsebene assoziiert ist.
16 veranschaulicht ein Client-Server-System, mit dem immersiver Videoinhalt generiert und durch eine Infrastruktur eines Servers 1620 zur Übertragung an eine oder mehrere Vorrichtungen eines Clients 1630 codiert werden kann. Die Vorrichtungen des Clients 1630 können dann den immersiven Videoinhalt dekomprimieren und rendern. In einer Ausführungsform können eine oder mehrere Vorrichtungen des Servers 1620 Eingaben von einer oder mehreren optischen Kameras 1601 mit Tiefensensoren 1602 einschließen. Ressourcen für die parallele Berechnung 1604 können die Video- und Tiefendaten in Punktwolken 1605 und/oder Texturdreiecke 1606 zerlegen. Daten zum Generieren von texturierten Dreiecken 1606 können auch durch vorgenerierte 3D-Modelle 1603 einer Szene bereitgestellt werden. Die Punktwolken 1605 und/oder texturierten Dreiecke 1606 können zur Übertragung an eine oder mehrere Clientvorrichtungen komprimiert werden, die den Inhalt lokal rendern können. In einer Ausführungsform können eine Vielzahl von Komprimierungseinheiten 1607, 1608 unter Verwendung einer Vielzahl von Komprimierungsalgorithmen generierten Inhalt zur Übertragung über ein Übermittlungsmedium vom Server 1620 an eine oder mehrere Vorrichtungen des Clients 1630 komprimieren. Die Dekomprimierungseinheiten 1609, 1610 auf den Vorrichtungen des Clients 1630 können eingehende Bitströme in Video-/Textur- und Geometriedaten dekomprimieren und decodieren. Beispielsweise kann die Dekomprimierungseinheit 1609 komprimierte Punktwolkendaten decodieren und die dekomprimierten Punktwolkendaten an eine Betrachtungspunktinterpolationseinheit 1611 bereitstellen. Die interpolierten Betrachtungspunktdaten können verwendet werden, um Bitmapdaten 1613 zu generieren. Die dekomprimierten Punktwolkendaten können einer Geometrierekonstruktionseinheit 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 zum Betrachten durch den Client 1630 zu generieren.
17A-17B veranschaulichen die Systeme 1700, 1710 zum Codieren und Decodieren von 3DoF-Plus-Inhalt. Das System 1700 kann beispielsweise wie in 16 durch Hardware und Software einer Infrastruktur des Servers 1620 implementiert werden. Das System 1710 kann durch Hardware und Software eines Clients 1630 wie in 16 implementiert werden.
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 bereitstellen, einschließlich Videodaten und Tiefendaten, wobei jeder Frame von Videodaten in eine Textur umgewandelt werden kann. Ein Satz von Einheiten für die Reprojektion 1706 und die Okklusionsdetektion 1707 kann an empfangenen Videodaten arbeiten und verarbeitete Daten an Einheiten für die Patch-Bildung 1708 ausgeben. Patches, die durch die Einheiten für die Patch-Bildung 1708 gebildet werden, können einer Einheit für die Patch-Packung 1709 bereitgestellt werden. Die Videodaten 1702 für die Basisansicht 1701 können beispielsweise über einen Coder 1703A für die hocheffiziente Videocodierung (HEVC, High Efficiency Video Coding) codiert werden. Eine Variante des HEVC-Coders 1703A kann auch verwendet werden, um Patch-Videodaten zu codieren, die von der Einheit für die Patch-Packung 1709 ausgegeben werden. Metadaten zum Rekonstruieren von Video aus den codierten Patches können durch eine Einheit für die Metadatencodierung 1703B codiert werden. Mehrere codierte Video- und Metadatenströme können dann zur Anzeige an eine Clientvorrichtung gesendet werden.
Wie in 17B gezeigt, können durch das System 1710 mehrere Videodatenströme empfangen, decodiert und in ein immersives Video rekonstruiert werden. Die mehreren Videoströme beinhalten einen Strom für das Basisvideo zusammen mit einem Strom, der gepackte Daten für die zusätzlichen Ansichten enthält. Codierte Metadaten werden auch empfangen. Die mehreren Videoströme können in einer Ausführungsform über einen Decoder für HEVC 1713A decodiert werden. Metadaten können über einen Decoder für Metadaten 1713B decodiert werden. Die decodierten Metadaten werden dann verwendet, um die decodierten zusätzlichen Ansichten über die Logik für die Patch-Entpackung 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 die Ansichtsgenerierungslogik 1718 auf dem Client (z. B. Client 1630 wie in 16) rekonstruiert. Das decodierte Video 1712, 1715A-1715C kann als Textur- und Tiefendaten an einen Zwischenansichts-Renderer 1714 bereitgestellt werden, der zum Rendern von Zwischenansichten für eine am Kopf montierte Anzeige 1711 verwendet werden kann. Die Positionsinformationen 1716 der am Kopf montierten Anzeige werden als Feedback an den Zwischenansichts-Renderer 1714 bereitgestellt, der aktualisierte Ansichten für den angezeigten Viewport rendern kann, der über die am Kopf montierte Anzeige 1711 präsentiert wird.
18A-18B veranschaulichen ein System zum Codieren und Decodieren von 6DoF-texturierten Geometriedaten. 18A zeigt ein 6DoF-texturiertes Geometriecodierungssystem 1800. 18B zeigt ein 6DoF-texturiertes Geometriedecodierungssystem 1820. Das Codieren und Decodieren von 6DoF-texturierten Geometrien kann verwendet werden, um eine Variante von immersivem 6DoF-Video zu ermöglichen, bei dem Videodaten als eine Textur auf Geometriedaten angewendet werden, wodurch ermöglicht wird, dass neue Zwischenansichten basierend auf der Position und der Orientierung einer am Kopf montierten Anzeige gerendert werden. Von mehreren Videokameras aufgezeichnete Daten können mit 3D-Modellen kombiniert werden, insbesondere bei statischen Objekten.
Wie in 18A gezeigt, kann ein 6DoF-texturiertes Geometriecodierungssystem 1800 Videodaten 1802 für eine Basisansicht und Videodaten 1805A-1805C für zusätzliche Ansichten empfangen. Die Videodaten 1802, 1805A-1805C weisen Textur- und Tiefendaten auf, die von einer Reprojektions- und Okklusionsdetektionseinheit 1806 verarbeitet werden können. Die Ausgabe von der Reprojektions- und Okklusionsdetektionseinheit 1806 kann einer Patch-Zerlegungseinheit 1807 und einem Geometriebildgenerator 1808 bereitgestellt werden. Die Ausgabe von der Patch-Zerlegungseinheit 1807 wird an eine Patch-Packungseinheit 1809 und einen Hilfs-Patch-Informations-Komprimierer 1813 bereitgestellt. Die Hilfs-Patch-Informationen (Patch-Info) stellen Informationen bereit, die zum Rekonstruieren von Patches von Videotextur- und Tiefendaten verwendet werden. Die Patch-Packungseinheit 1809 gibt gepackte Patch-Daten an den Geometriebildgenerator 1808, einen Texturbildgenerator 1810, einen Attributbildgenerator 1811 und einen Occupancy-Map-Komprimierer 1812 aus.
Der Geometriebildgenerator 1808, der Texturbildgenerator 1810 und der Attributbildgenerator 1811 geben Daten an einen Videokomprimierer 1814 aus. Der Geometriebildgenerator 1808 kann eine Eingabe von der Reprojektions- und Okklusionsdetektionseinheit 1806, der Patch-Zerlegungseinheit 1807 und der Patch-Packungseinheit 1809 empfangen und generiert Geometriebilddaten. Der Texturbildgenerator 1810 kann gepackte Patch-Daten von der Patch-Packungseinheit 1809 und Videotextur- und Tiefendaten von der Reprojektions- und Okklusionsdetektionseinheit 1806 empfangen. Der Attributbildgenerator 1811 generiert ein Attributbild aus Videotextur- und Tiefendaten, die von der Reprojektions- und Okklusionsdetektionseinheit 1806 empfangen werden, und gepatchten Patch-Daten, die von der Patch-Packungseinheit 1809 empfangen werden.
Eine Occupancy-Map kann durch einen Occupancy-Map-Komprimierer 1812 basierend auf gepackten Patch-Daten generiert werden, die von der Patch-Packungseinheit 1809 ausgegeben werden. Hilfs-Patch-Informationen können durch den Hilfs-Patch-Informations-Komprimierer 1813 generiert werden. Komprimierte Occupancy-Map- und Hilfs-Patch-Informations-Daten können durch einen Multiplexer 1815 zusammen mit komprimierten und/oder codierten Videodaten, die vom Videokomprimierer 1814 ausgegeben werden, in einen komprimierten Bitstrom 1816 gemultiplext werden. Die komprimierten Videodaten, die vom Videokomprimierer 1814 ausgegeben werden, schließen komprimierte Geometriebilddaten, Texturbilddaten und Attributbilddaten ein. Der komprimierte Bitstrom 1816 kann zur Dekomprimierung und Anzeige gespeichert oder an eine Clientvorrichtung bereitgestellt werden.
Wie in 18B gezeigt, kann ein 6DoF-texturiertes Geometriedecodierungssystem 1820 verwendet werden, um 6DoF-Inhalt zu decodieren, der unter Verwendung des Codierungssystems 1800 aus 18A generiert wurde. Der komprimierte Bitstrom 1816 wird von einem Demultiplexer 1835 empfangen und in mehrere Videodecodierungsströme, eine Occupancy-Map und Hilfs-Patch-Informationen demultiplext. Die mehreren Videoströme werden durch die Videodecoder 1834A-1834B decodiert/dekomprimiert. Occupancy-Map-Daten werden durch einen Occupancy-Map-Decoder 1832 decodiert/dekomprimiert. Die decodierten Videodaten und Occupancy-Map-Daten werden von den Videodecodern 1834A-1834B und dem Occupancy-Map-Decoder 1832 an eine Entpackungseinheit 1829 ausgegeben. Die Entpackungseinheit entpackt Video-Patch-Daten, die durch die Patch-Packungseinheit 1809 aus 18A gepackt werden. Hilfs-Patch-Informationen vom Hilfs-Patch-Info-Decoder 1833 werden an eine Okklusionsfülleinheit 1826 bereitgestellt, die verwendet werden kann, um Patches von verdeckten Abschnitten eines Objekts auszufüllen, die in einer bestimmten Ansicht der Videodaten fehlen können. Jeweilige Videoströme 1822, 1825A-1825C mit Textur- und Tiefendaten werden von der Okklusionsfülleinheit 1826 ausgegeben und an einen Zwischenansichts-Renderer 1823 bereitgestellt, der eine Ansicht zur Anzeige auf einer am Kopf montierten Anzeige 1824 basierend auf Positions- und Orientierungsinformationen, die von der am Kopf montierten Anzeige 1824 bereitgestellt werden, rendern kann.
19A-19B veranschaulichen ein System zum Codieren und Decodieren von 6DoF-Punktwolkendaten. 19A veranschaulicht ein 6DoF-Punktwolkencodierungssystem 1900. 19B veranschaulicht ein 6DoF-Punktwolkendecodierungssystem 1920. 6DoF-Video kann unter Verwendung von Punktwolken repräsentiert werden, wobei für eine Punktwolkenvideosequenz in regelmäßigen Zeitintervallen (z. B. 60 Hz) ein neuer Punktwolken-Frame vorhanden ist. Jeder Punkt im Punktwolkendaten-Frame wird durch sechs Parameter repräsentiert: (X, Y, Z)-Geometrieposition und (R, G, B oder Y, U, V)-Texturdaten. Im Codierungssystem 1900 aus 19A wird ein Punktwolken-Frame auf mehrere zweidimensionale (2D-) Ebenen projiziert, wobei jede 2D-Ebene einem Projektionswinkel entspricht. Die Projektionsebenen können den Projektionsebenen 1512 aus 15B ähnlich sein. In einigen Implementierungen werden im PCC-Standardtestmodell sechs Projektionswinkel verwendet, wobei die Projektionswinkel Winkeln entsprechen, die auf die Mitten von sechs Flächen eines rechteckigen Festkörpers zeigen, der das durch die Punktwolkendaten repräsentierte Objekt begrenzt. Obgleich sechs Projektionswinkel beschrieben sind, könnte möglicherweise eine andere Anzahl von Winkeln in unterschiedlichen Implementierungen verwendet werden.
Textur- und Tiefen-2D-Bild-Patch-Repräsentationen werden bei jedem Projektionswinkel gebildet. Die 2D-Patch-Bild-Repräsentationen für einen Projektionswinkel können erzeugt werden, indem nur diejenigen Punkte projiziert werden, für die ein Projektionswinkel die nächstliegende Normale aufweist. Mit anderen Worten wird die 2D-Patch-Bild-Repräsentation für die Punkte genommen, die das Skalarprodukt der Punktnormalen und der Ebenennormalen maximieren. Textur-Patches von den separaten Projektionen werden zu einem einzelnen Texturbild kombiniert, das als das Geometriebild bezeichnet wird. Metadaten zur Repräsentation der Patches und wie sie in einen Frame gepackt wurden, sind in der Occupancy-Map und den Hilfs-Patch-Informationen beschrieben. Die Occupancy-Map-Metadaten beinhalten eine Anzeige, welche Bildabtastpositionen leer sind (z. B. keine entsprechenden Punktwolkeninformationen enthalten). Die Hilfs-Patch-Informationen zeigen die Projektionsebene an, zu der ein Patch gehört, und können verwendet werden, um eine Projektionsebene zu bestimmen, die mit einer gegebenen Abtastposition assoziiert ist. Die Texturbilder und Tiefenbilder werden unter Verwendung eines herkömmlichen 2D-Videocoders codiert, wie beispielsweise eines Coders für die hocheffiziente Videocodierung (HEVC, High Efficiency Video Coding). Die Metadaten können unter Verwendung von Metadatencodierungslogik separat komprimiert werden. Im Testmodelldecoder werden die Texturbilder und Tiefenbilder unter Verwendung eines HEVC-Videodecoders decodiert. Eine Punktwolke wird unter Verwendung der decodierten Textur- und Tiefenbilder zusammen mit den Occupancy-Map- und den Hilfs-Patch-Info-Metadaten rekonstruiert.
Wie in 19A gezeigt, kann ein Eingabe-Frame von Punktwolkendaten in Patch-Daten zerlegt werden. Die Punktwolkendaten und die zerlegten Patch-Daten können auf ähnliche Weise wie die Videotextur- und Tiefendaten in 18A codiert werden. Eingabedaten, einschließlich eines Punktwolken-Frames 1906, können einer Patch-Zerlegungseinheit 1907 bereitgestellt werden. Die Eingabepunktwolkendaten und zerlegten Patches davon können durch eine Packungseinheit 1909, einen Geometriebildgenerator 1908, einen Texturbildgenerator 1910, einen Attributbildgenerator 1911, einen Occupancy-Map-Komprimierer 1912 und einen Hilfs-Patch-Informations-Komprimierer 1913 unter Verwendung von Techniken verarbeitet werden, die der Verarbeitung der Texturtiefe und der Videodaten ähnlich sind, die von der Reprojektions- und Okklusionsdetektionseinheit 1806 und der Patch-Zerlegungseinheit 1807 aus 18A ausgegeben werden. Ein Videokomprimierer 1914 kann Geometriebild-, Texturbild- und Attributbilddaten codieren und/oder komprimieren. Die komprimierten und/oder codierten Videodaten vom Videokomprimierer 1914 können durch einen Multiplexer 1915 mit Occupancy-Map- und Hilfs-Patch-Informations-Daten in einen komprimierten Bitstrom 1916 gemultiplext werden, der zur Anzeige gespeichert oder gesendet werden kann.
Der komprimierte Bitstrom, der vom System 1900 aus 19A ausgegeben wird, kann von dem in 19B gezeigten Punktwolkendecodierungssystem 1920 decodiert werden. Wie in 19B gezeigt, kann ein komprimierter Bitstrom 1916 in mehrere codierte/komprimierte Videoströme, Occupancy-Map-Daten und Hilfs-Patch-Informationen demultiplext werden. Die Videoströme können durch einen Multi-Stream-Videodecoder 1934 decodiert/dekomprimiert werden, der Textur- und Geometriedaten ausgeben kann. Occupancy-Map- und Hilfs-Patch-Informationen können durch einen Occupancy-Map-Decoder 1932 und einen Hilfs-Patch-Informations-Decoder 1933 dekomprimiert/decodiert werden.
Eine Geometrierekonstruktion, Glättung und Texturrekonstruktion können dann durchgeführt werden, um die Punktwolkendaten zu rekonstruieren, die dem 6DoF-Punktwolkencodierungssystem 1900 aus 19A bereitgestellt werden. Eine Geometrierekonstruktionseinheit 1936 kann Geometrieinformationen basierend auf Geometriedaten, die von einem Videostrom des Multi-Stream-Videodecoders 1934 decodiert werden, sowie der Ausgabe des Occupancy-Map-Decoders 1932 und des Hilfs-Patch-Informations-Decoders 1933 rekonstruieren. Rekonstruierte Geometriedaten können durch eine Glättungseinheit 1937 geglättet werden. Geglättete Geometrie- und Texturbilddaten, die von einem Videostrom, der vom Multi-Stream-Videodecoder 1934 ausgegeben wird, decodiert werden, werden an eine Texturrekonstruktionseinheit 1938 bereitgestellt. Die Texturrekonstruktionseinheit 1938 kann eine rekonstruierte Punktwolke 1939 ausgeben, die eine Variante des Eingabepunktwolken-Frames 1926 ist, der dem 6DoF-Punktwolkencodierungssystem 1900 aus 19A bereitgestellt wird.
20 veranschaulicht eine Rechenvorrichtung 2000, die einen Videoverarbeitungsmechanismus 2010 verwendet, gemäß einer Ausführungsform. Die Rechenvorrichtung 2000 (z. B. Server, intelligente tragbare Vorrichtungen, Virtual-Reality(VR)-Vorrichtungen, am Kopf montierte Anzeigen (HMDs, Head Mounted Displays), mobile Computer, Vorrichtungen für das Internet der Dinge (loT, Internet of Things), Laptop-Computer, Desktop-Computer, Server-Computer usw.) kann die gleiche sein wie das Verarbeitungssystem 100 aus 1, und dementsprechend werden der Kürze, Klarheit und Verständlichkeit halber viele der oben unter Bezugnahme auf die 1-14 angegebenen Details im Folgenden nicht weiter erörtert oder wiederholt. Wie veranschaulicht, ist in einer Ausführungsform die Rechenvorrichtung 2000 als Host eines Videoverarbeitungsmechanismus 2010 gezeigt.
Wie in einer Ausführungsform veranschaulicht, kann der Videoverarbeitungsmechanismus 2010 von der Firmware der Grafikverarbeitungseinheit („GPU“ (Graphics Processing Unit) oder „Grafikprozessor“) 2014 oder einem Teil davon gehostet werden. In anderen Ausführungsformen kann der Videoverarbeitungsmechanismus 2010 von der Firmware der zentralen Verarbeitungseinheit („CPU“ (Central Processing Unit) oder „Anwendungsprozessor“) 2012 oder einem Teil davon gehostet werden. Der Kürze, Klarheit und Verständlichkeit halber kann der Videoverarbeitungsmechanismus 2010 im weiteren Verlauf dieses Dokuments als Teil der GPU 2014 erörtert werden; Ausführungsformen sind jedoch nicht als solche beschränkt.
In noch einer anderen Ausführungsform kann der Videoverarbeitungsmechanismus 2010 vom Betriebssystem 2006 als Software- oder Firmwarlogik gehostet werden. In noch einer anderen Ausführungsform kann der Videoverarbeitungsmechanismus 2010 vom Grafiktreiber 2016 gehostet werden. In noch einer weiteren Ausführungsform kann der Videoverarbeitungsmechanismus 2010 teilweise und gleichzeitig von mehreren Komponenten der Rechenvorrichtung 2000 gehostet werden, wie beispielsweise eines oder mehrere von Grafiktreiber 2016, GPU 2014, GPU-Firmware, CPU 2012, CPU-Firmware, Betriebssystem 2006 und/oder dergleichen. Es wird in Betracht gezogen, dass der Videoverarbeitungsmechanismus 2010 oder eine oder mehrere seiner Komponenten als Hardware, Software und/oder Firmware implementiert sein können.
Die Rechenvorrichtung 2000 kann eine beliebige Anzahl und einen beliebigen Typ von Kommunikationsvorrichtungen einschließen, wie beispielsweise große Rechensysteme, wie beispielsweise Server-Computer, Desktop-Computer usw., und kann ferner Set-Top-Boxen (z. B. Internet-basierte Kabelfernseh-Set-Top-Boxen usw.), auf einem globalen Positionierungssystem (GPS) basierte Vorrichtungen usw. einschließen. Die Rechenvorrichtung 2000 kann mobile Rechenvorrichtungen einschließen, die als Kommunikationsvorrichtungen dienen, wie beispielsweise Mobiltelefone, einschließlich Smartphones, persönliche digitale Assistenten (PDAs), Tablet-Computer, Laptop-Computer, E-Reader, intelligente Fernseher, Fernsehplattformen, tragbare Vorrichtungen (z. B. Brillen, Uhren, Armbänder, Smartcards, Schmuck, Kleidungsstücke usw.), Mediaplayer usw. Beispielsweise kann die Rechenvorrichtung 2000 in einer Ausführungsform eine mobile Rechenvorrichtung einschließen, die eine Computerplattform verwendet, die eine integrierte Schaltung („IC“, Integrated Circuit) hostet, wie beispielsweise ein System auf einem Chip („SoC“ oder „SOC“, System-on-a-Chip), das verschiedene Hardware- und/oder Softwarekomponenten der Rechenvorrichtung 2000 auf einem einzelnen Chip integriert.
Wie veranschaulicht, kann die Rechenvorrichtung 2000 in einer Ausführungsform eine beliebige Anzahl und einen beliebigen Typ von Hardware- und/oder Softwarekomponenten einschließen, wie beispielsweise (ohne Einschränkung) GPU 2014, einen Grafiktreiber (auch als „GPU-Treiber“, „Grafiktreiberlogik“, „Treiberlogik“, Benutzermodustreiber (UMD, User-Mode Driver), UMD, Benutzermodustreiber-Framework (UMDF, User-Mode Driver Framework), UMDF, oder einfach „Treiber“ bezeichnet) 2016, CPU 2012, Speicher 2008, Netzvorrichtungen, Treiber oder dergleichen sowie Eingabe/Ausgabe(E/A)-Quellen 2004, wie beispielsweise Berührungsbildschirme, Touch-Panels, Touch-Pads, virtuelle oder reguläre Tastaturen, virtuelle oder reguläre Mäuse, Ports, Verbinder usw.
Die Rechenvorrichtung 2000 kann ein Betriebssystem (BS) 2006 aufweisen, das als eine Schnittstelle zwischen Hardware- und/oder physikalischen Ressourcen der Rechenvorrichtung 2000 und einem Benutzer dient. Es wird in Betracht gezogen, dass die CPU 2012 einen oder mehrere Prozessoren aufweisen kann, während die GPU 2014 einen oder mehrere Grafikprozessoren aufweisen kann.
Es ist zu beachten, dass Begriffe wie „Knoten“, „Rechenknoten“, „Server“, „Servervorrichtung“, „Cloud-Computer“, „Cloud-Server“, „Cloud-Server-Computer“, „Maschine“, „Hostmaschine“, „Vorrichtung“, „Rechenvorrichtung“, „Computer“, „Rechensystem“ und dergleichen in diesem Dokument austauschbar verwendet werden können. Es ist ferner zu beachten, dass Begriffe wie „Anwendung“, „Softwareanwendung“, „Programm“, „Softwareprogramm“, „Paket“, „Softwarepaket“ und dergleichen in diesem Dokument austauschbar verwendet werden können. Auch können Begriffe wie „Job“, „Eingabe“, „Anforderung“, „Nachricht“ und dergleichen in diesem Dokument austauschbar verwendet werden.
Ferner können Begriffe wie „Logik“, „Komponente“, „Modul“, „Engine“, „Modell“, „Einheit“ und dergleichen austauschbar bezeichnet sein und beispielsweise Software, Hardware, und/oder eine beliebige Kombination von Software und Hardware, wie beispielsweise Firmware, einschließen. Ferner sollte jede Verwendung einer bestimmten Marke, eines bestimmten Worts, eines bestimmten Begriffs, eines bestimmten Ausdrucks, eines bestimmten Namens und/oder eines bestimmten Akronyms nicht verstanden werden, dass Ausführungsformen auf Software oder Vorrichtungen beschränkt sind, die diese Bezeichnung in Produkten oder in der Literatur außerhalb dieses Dokuments tragen.
Es wird in Betracht gezogen, und wie unter Bezugnahme auf die 1-14 weiter beschrieben, einige Prozesse der Grafik-Pipeline, wie oben beschrieben, in Software zu implementieren, während der Rest in Hardware implementiert ist. Eine Grafik-Pipeline kann in einem Grafik-Coprozessor-Design implementiert werden, wobei die CPU 2012 so konzipiert ist, dass sie mit der GPU 2014 zusammenarbeitet, die in der CPU 2012 eingeschlossen sein kann oder mit dieser kolokalisiert sein kann. In einer Ausführungsform kann die GPU 2014 eine beliebige Anzahl und einen beliebigen Typ von herkömmlicher Software- und Hardwarelogik, um die herkömmlichen Funktionen in Bezug auf das Grafik-Rendering durchzuführen, sowie eine neuartige Software- und Hardwarelogik, um eine beliebige Anzahl und einen beliebigen Typ von Anweisungen auszuführen, verwenden.
Wie oben erwähnt, kann der Speicher 2008 einen Direktzugriffsspeicher (RAM, Random Access Memory) einschließen, der eine Anwendungsdatenbank mit Objektinformationen umfasst. Ein Speichercontroller-Hub kann auf Daten im RAM zugreifen und diese zur Grafik-Pipeline-Verarbeitung an die GPU 2014 weiterleiten. Der RAM kann einen RAM mit doppelter Datenrate (DDR-RAM, Double Data Rate RAM), einen RAM mit erweiterter Datenausgabe (EDO-RAM, Extended Data Output RAM) usw. einschließen. Die CPU 2012 interagiert mit einer Hardwaregrafik-Pipeline, um die Grafik-Pipelining-Funktionalität gemeinsam zu nutzen.
Verarbeitete Daten werden in einem Puffer in der Hardwaregrafik-Pipeline gespeichert, und Zustandsinformationen werden im Speicher 2008 gespeichert. Das resultierende Bild wird dann zu E/A-Quellen 2004 übertragen, wie beispielsweise einer Anzeigekomponente zum Anzeigen des Bilds. Es wird in Betracht gezogen, dass die Anzeigevorrichtung von verschiedenen Typen sein kann, wie beispielsweise Kathodenstrahlröhre (CRT, Cathode Ray Tube), Dünnschichttransistor (TFT, Thin Film Transistor), Flüssigkristallanzeige (LCD, Liquid Crystal Display), Array von organischen lichtemittierenden Dioden (OLED) usw., um einem Benutzer Informationen anzuzeigen.
Der Speicher 2008 kann einen vorab zugewiesenen Bereich eines Puffers (z. B. Frame-Puffer) umfassen; es versteht sich jedoch für Durchschnittsfachleute auf dem Gebiet, dass die Ausführungsformen nicht darauf beschränkt sind und dass ein beliebiger Speicher verwendet werden kann, auf den die untere Grafik-Pipeline zugreifen kann. Die Rechenvorrichtung 2000 kann ferner einen Plattformcontroller-Hub (PCH) 130, wie in 1 angegeben, als eine oder mehrere E/A-Quellen 2004 usw. aufweisen.
Die CPU 2012 kann einen oder mehrere Prozessoren aufweisen, um Anweisungen auszuführen, um alle Softwareroutinen auszuführen, die das Rechensystem implementiert. Die Anweisungen beinhalten häufig eine Art von Operation, die an Daten durchgeführt wird. Sowohl Daten als auch Anweisungen können im Systemspeicher 2008 und in einem beliebigen assoziierten Cache gespeichert werden. Der Cache ist typischerweise mit kürzeren Latenzzeiten als der Systemspeicher 2008 konzipiert; beispielsweise könnte der Cache auf dem/den gleichen Siliziumchip(s) wie der/die Prozessor(en) integriert sein und/oder mit schnelleren Zellen für den statischen RAM (SRAM) konstruiert sein, während der Systemspeicher 2008 mit langsameren Zellen für den dynamischen RAM (DRAM) konstruiert sein könnte. Durch die Tendenz, häufiger verwendete Anweisungen und Daten im Cache im Gegensatz zum Systemspeicher 2008 zu speichern, verbessert sich die Gesamtleistungseffizienz der Rechenvorrichtung 2000. Es wird in Betracht gezogen, dass die GPU 2014 in einigen Ausführungsformen als Teil der CPU 2012 (beispielsweise als Teil eines physikalischen CPU-Packages) existieren kann, in welchem Fall der Speicher 2008 von der CPU 2012 und der GPU 2014 gemeinsam genutzt oder getrennt gehalten werden kann.
Der Systemspeicher 2008 kann anderen Komponenten innerhalb der Rechenvorrichtung 2000 zur Verfügung gestellt werden. Beispielsweise werden alle Daten (z. B. eingegebene Grafikdaten), die von verschiedenen Schnittstellen zur Rechenvorrichtung 2000 (z. B. Tastatur und Maus, Druckerport, Port für ein Local Area Network (LAN), Modemport usw.) empfangen werden oder von einem internen Speicherungselement der Rechenvorrichtung 2000 (z. B. einem Festplattenlaufwerk) abgerufen werden, oft vorübergehend im Systemspeicher 2008 in eine Warteschlange gestellt, bevor sie von einem oder mehreren Prozessoren bei der Implementierung eines Softwareprogramms bearbeitet werden. In ähnlicher Weise werden Daten, von denen ein Softwareprogramm bestimmt, dass sie von der Rechenvorrichtung 2000 über eine der Rechensystemschnittstellen an eine externe Entität gesendet oder in einem internen Speicherungselement gespeichert werden sollten, oft vorübergehend im Systemspeicher 2008 in eine Warteschlange gestellt, bevor sie gesendet oder gespeichert werden.
Ferner kann beispielsweise ein PCH verwendet werden, um sicherzustellen, dass derartige Daten ordnungsgemäß zwischen dem Systemspeicher 2008 und seiner entsprechenden Rechensystemschnittstelle (und der internen Speichervorrichtung, falls das Rechensystem so konzipiert ist) übertragen werden,und kann bidirektionale Punkt-zu-Punkt-Links zwischen sich selbst und den beobachteten E/A-Quellen/Vorrichtungen 2004 aufweisen. In ähnlicher Weise kann ein MCH zum Verwalten der verschiedenen konkurrierenden Anforderungen für Zugriffe auf den Systemspeicher 2008 zwischen der CPU 2012 und der GPU 2014, Schnittstellen und internen Speicherungselementen verwendet werden, die zeitnah in Bezug aufeinander auftreten können.
Die E/A-Quellen 2004 können eine oder mehrere E/A-Vorrichtungen aufweisen, die zum Übertragen von Daten zu und/oder von der Rechenvorrichtung 2000 (z. B. Netzadapter) implementiert sind; oder für einen großen nichtflüchtigen Speicher innerhalb der Rechenvorrichtung 2000 (z. B. Festplattenlaufwerk). Eine Benutzereingabevorrichtung, einschließlich alphanumerischer und anderer Tasten, kann verwendet werden, um Informationen und Befehlsauswahlen an die GPU 2014 zu kommunizieren. Ein anderer Typ einer Benutzereingabevorrichtung ist eine Cursorsteuerung, wie beispielsweise eine Maus, ein Trackball, ein Berührungsbildschirm, ein Touchpad oder Cursorrichtungstasten, um Richtungsinformationen und Befehlsauswahlen an die GPU 2014 zu kommunizieren und die Cursorbewegung auf der Anzeigevorrichtung zu steuern. Kamera- und Mikrofonanordnungen der Rechenvorrichtung 2000 können verwendet werden, um Gesten zu beobachten, Audio und Video aufzuzeichnen und visuelle und Audiobefehle zu empfangen und zu senden.
Gemäß einer Ausführungsform ist die Rechenvorrichtung 2000 über ein oder mehrere Netze 2045 mit einer oder mehreren Client-Rechenvorrichtungen (oder Clients) 2040 gekoppelt. In einer weiteren Ausführungsform schließt der Client 2040 auch einen Videoverarbeitungsmechanismus 2010 ein. In dieser Ausführungsform ist der Videoverarbeitungsmechanismus 2010 bei der Rechenvorrichtung 2000 als ein Videoserver implementiert, um Videobitstromdaten zur Übertragung an einen Client 2040 zu verarbeiten und zu codieren (z. B. über den Videocoder 2002), wobei die Daten durch den Videoverarbeitungsmechanismus 2010 (z. B. über den Videodecoder 2041 decodiert) zum Rendern auf einer Anzeigevorrichtung 2042 verarbeitet werden.
Dementsprechend können der Server 2000 und der Client 2040 ferner eine oder mehrere Netzschnittstellen aufweisen, um einen Zugriff auf ein Netz bereitzustellen, wie beispielsweise ein LAN, ein Wide Area Network (WAN), ein Metropolitan Area Network (MAN), ein Personal Area Network (PAN), Bluetooth, ein Cloud-Netz, ein mobiles Netz (z. B. 3. Generation (3G), 4. Generation (4G) usw.), ein Intranet, das Internet usw. Netzschnittstellen können beispielsweise eine drahtlose Netzschnittstelle mit einer Antenne einschließen, die eine oder mehrere Antennen repräsentieren kann. Netzschnittstellen können beispielsweise auch eine drahtgebundene Netzschnittstelle zur Kommunikation mit entfernten Vorrichtungen über ein Netzkabel einschließen, das beispielsweise ein Ethernet-Kabel, ein Koaxialkabel, ein Glasfaserkabel, ein serielles Kabel oder ein Parallelkabel sein kann.
Netzschnittstellen können einen Zugriff auf ein LAN bereitstellen, beispielsweise indem sie den Standards IEEE 802.11b und/oder IEEE 802.11g entsprechen, und/oder die drahtlose Netzschnittstelle kann einen Zugriff auf ein Personal Area Network bereitstellen, beispielsweise indem sie Bluetooth-Standards entspricht. Andere drahtlose Netzschnittstellen und/oder -protokolle, einschließlich früherer und nachfolgender Versionen der Standards, können auch unterstützt werden. Zusätzlich zu oder anstelle der Kommunikation über die WLAN-Standards können die Netzschnittstellen eine drahtlose Kommunikation unter Verwendung von beispielsweise Time-Division-Multiple-Access(TDMA)-Protokollen, Global-Systems-for-Mobile-Communications(GSM)-Protokollen, Code-Division-Multiple-Access(CDMA)-Protokollen und/oder beliebigen anderen Typen von drahtlosen Kommunikationsprotokollen bereitstellen.
Netzschnittstellen können eine oder mehrere Kommunikationsschnittstellen einschließen, wie beispielsweise ein Modem, eine Netzschnittstellenkarte oder andere bekannte Schnittstellenvorrichtungen, wie beispielsweise solche, die zum Koppeln mit dem Ethernet, Token-Ring oder anderen Typen von physikalischen drahtgebundenen oder drahtlosen Einrichtungen verwendet werden, um beispielsweise ein Kommunikations-Link zur Unterstützung eines LAN oder eines WAN bereitzustellen. Auf diese Weise kann das Computersystem auch über eine herkömmliche Netzinfrastruktur, beispielsweise ein Intranet oder das Internet, mit einer Reihe von Peripherievorrichtungen, Clients, Steueroberflächen, Konsolen oder Servern gekoppelt werden.
Es versteht sich, dass ein weniger oder besser ausgestattetes System als das oben beschriebene Beispiel für bestimmte Implementierungen bevorzugt werden kann. Daher kann die Konfiguration der Rechenvorrichtung 2000 von Implementierung zu Implementierung abhängig von zahlreichen Faktoren, wie beispielsweise Preisbeschränkungen, Leistungsanforderungen, technologischen Verbesserungen oder anderen Umständen, variieren. Beispiele der elektronischen Vorrichtung oder des Rechensystems 2000 können (ohne Einschränkung) eine Mobilvorrichtung, einen persönlichen digitalen Assistenten, eine mobile Rechenvorrichtung, ein Smartphone, ein Mobiltelefon, einen Handapparat, einen Einweg-Pager, einen Zweiweg-Pager, eine Messaging-Vorrichtung, einen Computer, einen Personal Computer (PC), einen Desktop-Computer, einen Laptop-Computer, einen Notebook-Computer, einen Handheld-Computer, einen Tablet-Computer, einen Server, ein Server-Array oder eine Server-Farm, einen Web-Server, einen Netzserver, einen Internet-Server, eine Workstation, einen Mini-Computer, einen Main-Frame-Computer, einen Supercomputer, ein Netzgerät, ein Web-Gerät, ein verteiltes Rechensystem, Multi-Prozessor-Systeme, prozessorbasierte Systeme, Verbraucherelektronik, programmierbare Verbraucherelektronik, Fernseher, digitalen Fernseher, Set-Top-Box, drahtlosen Zugangspunkt, Basisstation, Teilnehmerstation, Mobilteilnehmerzentrum, Funknetzcontroller, Router, Hub, Gateway, Bridge, Switch, Maschine oder Kombinationen davon einschließen.
Ausführungsformen können implementiert werden als beliebige oder eine Kombination von: einem oder mehreren Mikrochips oder einer oder mehreren integrierten Schaltungen, die unter Verwendung von einer Hauptplatine, fest verdrahteter Logik, Software, die von einer Speichervorrichtung gespeichert wird und von einem Mikroprozessor ausgeführt wird, Firmware, einer anwendungsspezifischen integrierten Schaltung (ASIC, Application Specific Integrated Circuit) und/oder einem feldprogrammierbaren Gate-Array (FPGA) miteinander verbunden sind. Der Begriff „Logik“ kann beispielsweise Software oder Hardware und/oder Kombinationen von Software und Hardware einschließen.
Ausführungsformen können beispielsweise als ein Computerprogrammprodukt bereitgestellt werden, das ein oder mehrere maschinenlesbare Medien mit darauf gespeicherten maschinenausführbaren Anweisungen aufweist, die, wenn sie von einer oder mehreren Maschinen, wie beispielsweise einem Computer, einem Computernetz oder anderen elektronischen Vorrichtungen, ausgeführt werden, dazu führen können, dass die eine oder mehreren Maschinen Operationen gemäß hierin beschriebenen Ausführungsformen ausführen. Ein maschinenlesbares Medium kann Disketten, optische Platten, CD-ROMs (Compact Disc-Read Only Memories) und magnetooptische Platten, ROMs, RAMs, EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetische oder optische Karten, Flash-Speicher oder andere Typen von Medien/maschinenlesbaren Medien, die zum Speichern von maschinenausführbaren Anweisungen geeignet sind, aufweisen, ist jedoch nicht darauf beschränkt.
Darüber hinaus können Ausführungsformen als ein Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer (z. B. einem Server) zu einem anfordernden Computer (z. B. einem Client) mittels eines oder mehrerer Datensignale, die in einer Trägerwelle oder einem anderen Propagationsmedium enthalten und/oder durch diese moduliert sind, über einen Kommunikations-Link (z. B. eine Modem- und/oder Netzverbindung) übertragen werden kann.
Wie oben erörtert, werden Patches von Videobitstromdaten zusammen mit Patch-Informationen während der Codierung zur Übertragung an einen Client gepackt. Auf dem Client werden Textur- und Tiefendaten unter Verwendung der Patch-Informationen decodiert, um das Video zu rekonstruieren. Insbesondere beinhalten die decodierten Patch-Informationen Occupancy-Map-Daten und Hilfs-Patch-Informationen, die Informationen bereitstellen, die zum Rekonstruieren von Patches von Videotextur- und Tiefendaten während des Entpackens der Video-Patch-Daten vor dem 3D-Rendering verwendet werden. Die Occupancy-Map-Daten und Hilfs-Patch-Informationen werden jedoch gegenwärtig verworfen, sobald der Entpackungsprozess abgeschlossen ist.
Gemäß einer Ausführungsform werden decodierte Patch-Informationen weitergeleitet, um eine subjektive Artefaktreduzierung zu ermöglichen. In einer derartigen Ausführungsform werden Occupancy-Map-Daten und Hilfs-Patch-Informationen verarbeitet, um einen Video-Frame zu generieren, der eine Patch-ID bereitstellt, die verwendet wird, um eine Punktwolke (z. B. eine Patch-Punktwolke) zu generieren, die Patch-IDs anstelle von Texturwerten aufweist. Während des Renderns wird die Patch-Punktwolke generiert und verwendet, um die subjektive Artefaktreduzierung der aus der Texturpunktwolke gerenderten Viewports durchzuführen.
21 veranschaulicht eine Ausführungsform eines Videoverarbeitungsmechanismus 2010, der beim Client 2040 implementiert ist, um Patch-Informationen weiterzuleiten. Wie in 21 gezeigt, weist der Videoverarbeitungsmechanismus 2010 einen Decoder 2041 mit einem Texturdecoder 2102, einem Tiefendecoder 2104, einem Occupancy-Map-Decoder 2106 und einem Hilfs-Patch-Informations-Decoder 2108 auf. Zusätzlich ist eine Entpackungslogik 2110 eingeschlossen, um die Videodaten wie oben beschrieben zu entpacken. Die 2D-zu-3D-Umwandlungslogik 2112 empfängt die entpackten Textur- und Tiefendaten, um die Daten in eine 3D-Videopunktwolke zu transformieren, die in der Viewport-Rendering-Logik 2114 gerendert werden soll.
Gemäß einer Ausführungsform weist der Videoverarbeitungsmechanismus 2010 auch eine Patch-Verarbeitungslogik 2120 auf, die die Patch-Informationen zur Verwendung bei der subjektiven Artefaktreduzierung verarbeitet. In einer derartigen Ausführungsform schließt die Patch-Verarbeitungslogik 2120 die Entpackungs-Patch-Map-Logik 2122 ein, die decodierte Occupancy-Map-Daten und Hilfs-Patch-Informationen empfängt und entpackt, um Video-Frames zu generieren, die jeweils eine assoziierte Patch-Identifizierung (ID) (z. B. einen 8-Bit-Wert) aufweisen. In einer weiteren Ausführungsform weist jedes Patch auch assoziierte Metadaten auf, um einen Ursprungswinkel (z. B. einen Winkel, aus dem das Patch stammt) und eine relative Position anzuzeigen.
Die 2D-zu-3D-Umwandlungslogik 2124 ist auch in der Patch-Verarbeitungslogik 2120 eingeschlossen, um die Patch-Informationen (z. B. Patch-Video-Frames) in eine 3D-Repräsentation zu transformieren, wie beispielsweise eine Punktwolke mit Patch-IDs (anstelle von Texturwerten), die in der Viewport-Rendering-Logik 2114 gerendert werden soll. Während des Renderns untersucht die subjektive Artefaktreduzierungslogik 2130 die Patch-Informationen, um zu bestimmen, ob ein oder mehrere Artefakte in den gerenderten Daten vorhanden sind, und um alle detektierten Artefakte zu korrigieren. Beispielsweise kann die subjektive Artefaktreduzierungslogik 2130 bestimmen, dass Bereiche innerhalb desselben Patches mit unterschiedlichen Texturhelligkeitswerten unterschiedliche Objektmuster anzeigen, die real sind, während eine derartige Diskontinuität zwischen benachbarten Patches anzeigt, dass es ein Artefakt (oder eine Ungenauigkeit) aufgrund der Tatsache geben kann, dass die Patches separat codiert wurden. In derartigen Fällen kann die subjektive Artefaktreduzierungslogik 2130 einen Tiefpassfilter auf den gerenderten Textur-Viewport über die Patch-Grenze anwenden, um die Diskontinuität über die Patch-Grenze zu reduzieren.
Gemäß einer Ausführungsform schließt der Videoverarbeitungsmechanismus eine Bewegungsschätzungslogik 2005 und eine Bewegungskompensationslogik 2006 ein, um jeweils eine Bewegungsschätzungslogik und eine Bewegungskompensationslogik durchzuführen. Während des Codierens wird eine Bewegungsschätzung durchgeführt, um Bewegungsvektoren zu berechnen, die eine Transformation von einem 2D-Bild zu einem anderen beschreiben; in der Regel von benachbarten Frames in einer Videosequenz. Die Bewegungsvektoren können sich auf ein gesamtes Bild (globale Bewegungsschätzung) oder auf spezielle Teile beziehen, wie beispielsweise rechteckige Blöcke, beliebig geformte Patches oder sogar pro Pixel. Die Bewegungsvektoren können durch ein Translationsmodell oder viele andere Modelle repräsentiert werden, die die Bewegung einer realen Videokamera approximieren können, wie beispielsweise Rotation und Translation in allen drei Dimensionen und Zoom. Anschließend wird eine Bewegungskompensation unter Verwendung der Bewegungsschätzungsinformationen durchgeführt, um eine Komprimierung zu erreichen. Dementsprechend müssen, sobald eine Bewegung beschrieben ist, nur die Änderungen beschrieben werden, die nach dem Kompensieren dieser Bewegung auftreten.
Während der Bewegungsschätzung und -kompensation kann derselbe Bereich auf mehrere (z. B. zwei) Patches abgebildet werden, die gemäß unterschiedlicher Orientierung ausgerichtet sind (z. B. eines mit der x-Ebene ausgerichtet und das andere mit der y-Ebene ausgerichtet), wobei die Patches von einem zum anderen vorhergesagt werden können. Gemäß einer Ausführungsform schließt der Videoverarbeitungsmechanismus 2010 auch eine Bewegungsvorhersagelogik 2007 ein, um die Patch-Orientierung während der Bewegungsvorhersage auszurichten. In einer derartigen Ausführungsform empfängt die Bewegungsvorhersagelogik 2007 die im Videobitstrom eingeschlossenen Patch-Metadaten und bestimmt die Ausrichtung der Patches basierend auf den in den Metadaten eingeschlossenen Patch-Orientierungs-/Ausrichtungsinformationen.
22 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens 2200 zum Durchführen einer Patch-Ausrichtung zur Bewegungsvorhersage veranschaulicht. Das Verfahren 2200 kann durch Verarbeitungslogik durchgeführt werden, die Hardware (z. B. Schaltungen, dedizierte Logik, programmierbare Logik usw.), Software (wie beispielsweise auf einer Verarbeitungsvorrichtung ausgeführte Anweisungen) oder eine Kombination davon umfassen kann. Die Prozesse des Verfahrens 2200 sind der Kürze und Klarheit der Darstellung halber in linearen Sequenzen veranschaulicht; es wird jedoch in Betracht gezogen, dass eine beliebige Anzahl von ihnen parallel, asynchron oder in verschiedenen Reihenfolgen durchgeführt werden kann. Der Kürze, Klarheit und Verständlichkeit halber werden ferner viele der in Bezug auf die 1-21 beschriebenen Komponenten und Prozesse nachfolgend möglicherweise nicht wiederholt oder erörtert.
Das Verfahren 2200 beginnt bei Verarbeitungsblock 2210, in dem ein Patch empfangen wird. Am Entscheidungsblock 2220 wird eine Bestimmung getroffen, ob eine Orientierung des aktuell empfangenen (oder aktuellen) Patches mit einer Orientierung eines Referenz-Patches ausgerichtet ist. Wie oben erörtert, wird die Patch-Orientierung aus Patch-Metadaten bestimmt, die mit dem Patch assoziiert sind. Falls nicht, wird das Referenz-Patch auf die Orientierung des aktuellen Patches ausgerichtet, Verarbeitungsblock 2230. Bei Verarbeitungsblock 2240 wird die Bewegungsvorhersage des aktuellen Patches vom ausgerichteten Referenz-Patch durchgeführt. Falls bei Entscheidungsblock 2220 bestimmt wird, dass die Patches ausgerichtet sind, wird die Steuerung direkt an den Verarbeitungsblock 2240 weitergeleitet, in dem die Vorhersage durchgeführt wird. Der oben beschriebene Prozess kann entweder während der zeitlichen (z. B. Bilder, die zu verschiedenen Zeitpunkten aufgenommen werden) oder der räumlichen (z. B. Komponenten desselben Bilds) Charakterisierung angewendet werden.
Während des Codierens/Decodierens von Bewegungsvektoren kann derselbe Bereich eines Objekts auf verschiedene Stellen (z. B. Patches) in zwei verschiedenen Frames abgebildet werden, wenn Textur- und Geometriebilder generiert werden. Unter Bezugnahme auf 23A zeigt das Objekt 2300 bei Patch t beispielsweise zurück auf die Position bei Patch t-1. Je größer der Bewegungsvektor ist, desto mehr Daten müssen codiert werden.
Gemäß einer Ausführungsform führt die Bewegungsschätzungslogik 2005 eine Bewegungsvektorcodierung unter Verwendung eines Referenz-Patches und eines Patch-Metadaten-Offsets durch. In dieser Ausführungsform implementiert die Bewegungsschätzungslogik 2005 Positions-/Orientierungs-Metadaten, die in den Patch-Informationen eingeschlossen sind, als einen Offset, um die Bewegungsvektorcodierung durchzuführen. Somit kann die Positionsverschiebung eines aktuellen Patches unter Verwendung der Metadaten bereitgestellt werden, die die Positions-/Orientierungs-Koordinateninformationen des Patches (z. B. x-y-z) für jedes Patch anzeigen. Beispielsweise kann ein Bewegungsvektor durch Generieren eines Offsets vom Referenz-Patch basierend auf der Position/Orientierung codiert werden, die in den Metadaten von jedem Patch angezeigt werden. Infolgedessen wird die Anzahl der für die Bewegungsvektorcodierung erforderlichen Bits reduziert. 23B veranschaulicht eine Ausführungsform einer Reduzierung der Komplexität der Bewegungsvektorcodierung eines Objekts 2300 in den Patches t und t-1.
Gemäß einer Ausführungsform führt die Bewegungsschätzungslogik 2005 eine Patch-Grenzenextrapolation während des Codierens von Bewegungsschätzungs- oder Bewegungskompensationsdaten durch, anstatt eine separate Extrapolationsoperation durchführen zu müssen.
24 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens 2400 zum Durchführen einer Patch-Grenzenextrapolation veranschaulicht. Das Verfahren 2400 kann durch Verarbeitungslogik durchgeführt werden, die Hardware (z. B. Schaltungen, dedizierte Logik, programmierbare Logik usw.), Software (wie beispielsweise auf einer Verarbeitungsvorrichtung ausgeführte Anweisungen) oder eine Kombination davon umfassen kann. Die Prozesse des Verfahrens 2400 sind der Kürze und Klarheit der Darstellung halber in linearen Sequenzen veranschaulicht; es wird jedoch in Betracht gezogen, dass eine beliebige Anzahl von ihnen parallel, asynchron oder in verschiedenen Reihenfolgen durchgeführt werden kann. Der Kürze, Klarheit und Verständlichkeit halber werden ferner viele der in Bezug auf die 1-23 beschriebenen Komponenten und Prozesse nachfolgend möglicherweise nicht wiederholt oder erörtert.
Bei Verarbeitungsblock 2410 wird ein optimaler Bewegungsvektor basierend auf empfangenen Objektinformationen bestimmt. In einer derartigen Ausführungsform wird eine Bewegungsschätzung an den Objektinformationen durchgeführt, um einen Bewegungsvektor zu erhalten, der einen Pixelfehler minimiert. Wenn beispielsweise ein Block von Pixeldaten (z. B. 64×64) verarbeitet wird, umfassen viele der Pixel zusätzlich zu realen Objektdaten Hintergrunddaten. Somit wird eine Bewegungsschätzung nur an den Objektinformationen durchgeführt.
Bei Verarbeitungsblock 2420 werden aktuelle Pixel von Referenzpixeln subtrahiert, um einen Rest von realen Patch-Pixeln zu erhalten. Bei Verarbeitungsblock 2430 wird ein Hintergrundrest für den verbleibenden Hintergrund (z. B. Pixel, die nicht in den Patch-Pixeln enthalten sind) eines aktuellen Blocks auf Null gesetzt, um die zu codierenden Informationen zu minimieren. Der Hintergrundrest kann auf Null gesetzt werden, da er effektiv derselbe ist wie das Kopieren des Hintergrunds von der Referenz. Bei Verarbeitungsblock 2440 wird der aktuelle Block codiert.
In noch einer anderen Ausführungsform beinhaltet der Videoverarbeitungsmechanismus 2010 eine Crack-Entfernungslogik 2009, die implementiert ist, um Punktwolken-Cracking zu entfernen. Punktwolken erfordern, obwohl sie für die Übermittlung von volumetrischen Informationen äußerst nützlich sind, eine große Menge an Speicherplatz. Somit ist typischerweise die Komprimierung von Punktwolken erforderlich. Wenn Punktwolken komprimiert werden, können Quantisierungs- und andere Komprimierungsfehler dazu führen, dass die ursprünglichen Punkte geringfügig verschoben werden, was zu wesentlichen Defekten in der rekonstruierten Oberfläche während des Renderns führen kann.
25 veranschaulicht eine Ausführungsform eines Objektdefekts nach der Rekonstruktion. Wie in 25 gezeigt, sind die Positionen der Punkte, die mit zwei benachbarten Dreiecken assoziiert sind, während der Komprimierung geringfügig verschoben. Dies führt dazu, dass während der Dekomprimierung und Wiedergabe eine ursprünglich zusammenhängende Oberfläche mit einem Crack auftritt. Der unter Bezugnahme auf 25 erörterte Defekt kann in bestehenden Anwendungen auftreten, in denen eine diskrete Abtastung oft zu geometrischen Diskontinuitäten für feine Details unterhalb der Nyquist-Grenze führt, wenn eine reale Szene volumetrisch in einer Punktwolke erfasst wird. Beispielsweise kann ein Haarzopf, der sich zum Ende hin verjüngt und sich dann wieder über das Gummiband hinaus ausdehnt, als ein Satz von Punkten mit einer Lücke an der schmalen Stelle erfasst werden.
Gemäß einer Ausführungsform kompensiert die Crack-Entfernungslogik 2009 derartige Cracks durch Anwenden eines Gitters aufgrund eines dekomprimierten Punktwolkendatensatzes. In einer derartigen Ausführungsform entspricht das Gitter der ursprünglichen Abtastfrequenz (z. B. Voxel-Gitter) der ursprünglichen Datensatzerfassung. 26 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens 2600 zum Entfernen von Punktwolken-Cracking veranschaulicht. Das Verfahren 2600 kann durch Verarbeitungslogik durchgeführt werden, die Hardware (z. B. Schaltungen, dedizierte Logik, programmierbare Logik usw.), Software (wie beispielsweise auf einer Verarbeitungsvorrichtung ausgeführte Anweisungen) oder eine Kombination davon umfassen kann. Die Prozesse des Verfahrens 2600 sind der Kürze und Klarheit der Darstellung halber in linearen Sequenzen veranschaulicht; es wird jedoch in Betracht gezogen, dass eine beliebige Anzahl von ihnen parallel, asynchron oder in verschiedenen Reihenfolgen durchgeführt werden kann. Der Kürze, Klarheit und Verständlichkeit halber werden ferner viele der in Bezug auf die 1-25 beschriebenen Komponenten und Prozesse nachfolgend möglicherweise nicht wiederholt oder erörtert.
Bei Verarbeitungsblock 2610 wird eine Punktwolke dekomprimiert. Bei Verarbeitungsblock 2620 wird ein Gitter generiert. Wie oben erörtert, entspricht das Gitter der ursprünglichen Abtastfrequenz der ursprünglichen Datensatzerfassung. Bei Verarbeitungsblock 2630 wird der Punktwolkendatensatz auf das Gitter angewendet. 27A veranschaulicht eine Ausführungsform eines Gitters 2700, das auf dekomprimierte Punktwolkendaten angewendet wird. Obwohl das Gitter in 3D vorliegt, zeigt 27A das Gitter 2700 als eine 2D-Version zu Veranschaulichungszwecken. Bei Verarbeitungsblock 2640 werden Punkte innerhalb desselben Blocks identifiziert. Gemäß einer Ausführungsform werden zwei Punkte in der gleichen Box als gleicher Punkt betrachtet. Bei Verarbeitungsblock 2650 werden die Punkte innerhalb desselben Blocks an kolokalisierte Positionen angepasst, was dazu führt, dass Cracks versiegelt werden und die ursprüngliche Oberflächengeometrie genau wiederhergestellt wird. 27B veranschaulicht eine Ausführungsform der dekomprimierten Punktwolkenpunkte nach der Anpassung.
Einige Ausführungsformen betreffen Beispiel 1, das eine Vorrichtung zum Ermöglichen der Verarbeitung von Videobitstromdaten einschließt, umfassend einen oder mehrere Prozessoren zum Decodieren von Occupancy-Map-Daten und Hilfs-Patch-Informationen und Generieren einer Mehrzahl von Patch-Video-Frames basierend auf Patch-Daten, die von den Occupancy-Map-Daten und Hilfs-Patch-Informationen decodiert werden, und einen Speicher, der kommunikativ mit dem einen oder den mehreren Prozessoren gekoppelt ist.
Beispiel 2 schließt den Gegenstand von Beispiel 1 ein, wobei jeder der Mehrzahl von Patch-Video-Frames eine Patch-Identifizierung umfasst.
Beispiel 3 schließt den Gegenstand der Beispiele 1 und 2 ein, wobei der eine oder die mehreren Prozessoren ferner die Patch-Video-Frames in eine dreidimensionale (3D-) Repräsentation transformieren sollen.
Beispiel 4 schließt den Gegenstand der Beispiele 1-3 ein, wobei der eine oder die mehreren Prozessoren ferner einen Viewport von der 3D-Repräsentation rendern sollen.
Beispiel 5 schließt den Gegenstand der Beispiele 1-4 ein, wobei der eine oder die mehreren Prozessoren ferner eine Artefaktreduzierung durchführen sollen, um die Patch-Video-Frames während des Renderns zu untersuchen, um das Vorhandensein eines oder mehrerer Artefakte zu detektieren.
Beispiel 6 schließt den Gegenstand der Beispiele 1-5 ein, wobei das Untersuchen der Patch-Video-Frames das Anwenden eines Filters über eine Patch-Grenze im Patch-Video-Frame umfasst.
Beispiel 7 schließt den Gegenstand der Beispiele 1-6 ein, wobei die 3D-Repräsentation eine 3D-Patch-Punktwolke umfasst.
Beispiel 8 schließt den Gegenstand der Beispiele 1-7 ein, wobei der eine oder die mehreren Prozessoren ferner eine Patch-Orientierung während einer Bewegungsvorhersage ausrichten sollen.
Beispiel 9 schließt den Gegenstand der Beispiele 1-8 ein, wobei der eine oder die mehreren Prozessoren ferner ein aktuelles Patch empfangen sollen und bestimmen sollen, ob eine Orientierung des aktuellen Patches mit einer Orientierung eines Referenz-Patches ausgerichtet ist.
Beispiel 10 schließt den Gegenstand der Beispiele 1-9 ein, wobei der eine oder die mehreren Prozessoren ferner eine Bewegungsvorhersage des aktuellen Patches vom Referenz-Patch basierend auf der Ausrichtung durchführen sollen.
Beispiel 11 schließt den Gegenstand der Beispiele 1-10 ein, wobei der eine oder die mehreren Prozessoren ferner eine Bewegungsvektorcodierung unter Verwendung eines Referenz-Patches und von Patch-Metadaten durchführen sollen.
Beispiel 12 schließt den Gegenstand der Beispiele 1-11 ein, wobei der eine oder die mehreren Prozessoren ferner einen Offset vom Referenz-Patch über Koordinateninformationen generieren sollen, die in den Patch-Metadaten eingeschlossen sind.
Beispiel 13 schließt den Gegenstand der Beispiele 1-12 ein, wobei der eine oder die mehreren Prozessoren ferner eine Patch-Grenzenextrapolation während einer Bewegungsschätzungscodierung durchführen sollen.
Beispiel 14 schließt den Gegenstand der Beispiele 1-13 ein, wobei der eine oder die mehreren Prozessoren ferner einen optimalen Bewegungsvektor bestimmen sollen, der den Pixelfehler minimiert, aktuelle Pixel von Referenzpixeln subtrahieren sollen, um einen Rest realer Patch-Pixel zu erhalten, einen Hintergrundrest für verbleibende Hintergrundpixel eines aktuellen Blocks auf Null festlegen sollenund den aktuellen Block codieren sollen.
Beispiel 15 schließt den Gegenstand der Beispiele 1-14 ein, wobei der eine oder die mehreren Prozessoren ferner Punktwolken-Cracking in einer rekonstruierten gerenderten Oberfläche entfernen sollen.
Beispiel 16 schließt den Gegenstand der Beispiele 1-15 ein, wobei der eine oder die mehreren Prozessoren ferner ein Gitter auf einen dekomprimierten Punktwolkendatensatz anwenden sollen, wobei das Gitter einer ursprünglichen Abtastfrequenz einer ursprünglichen Datensatzerfassung entspricht.
Beispiel 17 schließt den Gegenstand der Beispiele 1-16 ein, wobei der eine oder die mehreren Prozessoren ferner Punkte in einem gleichen Block des Gitters an kolokalisierte Positionen anpassen.
Einige Ausführungsformen betreffen Beispiel 18, das ein computergeneriertes Verfahren zum Ermöglichen der Verarbeitung von Videobitstromdaten einschließt, umfassend das Decodieren von Occupancy-Map-Daten und Hilfs-Patch-Informationen und das Generieren einer Mehrzahl von Patch-Video-Frames basierend auf Patch-Daten, die von den Occupancy-Map-Daten und Hilfs-Patch-Informationen decodiert werden.
Beispiel 19 schließt den Gegenstand von Beispiel 18 ein, wobei jeder der Mehrzahl von Patch-Video-Frames eine Patch-Identifizierung umfasst.
Beispiel 20 schließt den Gegenstand der Beispiele 18 und 19 ein, ferner umfassend das Transformieren der Patch-Video-Frames in eine dreidimensionale (3D-) Repräsentation und das Rendern der 3D-Repräsentation.
Beispiel 21 schließt den Gegenstand der Beispiele 18-20 ein, ferner umfassend das Untersuchen der Patch-Video-Frames während des Renderns, um das Vorhandensein eines oder mehrerer Artefakte zu detektieren.
Beispiel 22 schließt den Gegenstand der Beispiele 18-21 ein, wobei das Untersuchen der Patch-Video-Frames das Anwenden eines Filters über eine Patch-Grenze im Patch-Video-Frame umfasst.
Beispiel 23 schließt den Gegenstand der Beispiele 18-22 ein, ferner umfassend das Ausrichten der Patch-Orientierung während der Bewegungsvorhersage.
Beispiel 24 schließt den Gegenstand der Beispiele 18-23 ein, wobei das Ausrichten der Patch-Orientierung das Empfangen eines aktuellen Patches und das Bestimmen, ob eine Orientierung des aktuellen Patches mit einer Orientierung eines Referenz-Patches ausgerichtet ist, umfasst.
Beispiel 25 schließt den Gegenstand der Beispiele 18-24 ein, ferner umfassend das Durchführen einer Bewegungsvorhersage des aktuellen Patches vom Referenz-Patch basierend auf der Ausrichtung.
Beispiel 26 schließt den Gegenstand der Beispiele 18-25 ein, ferner umfassend das Durchführen einer Bewegungsvektorcodierung unter Verwendung eines Referenz-Patches und von Patch-Metadaten.
Beispiel 27 schließt den Gegenstand der Beispiele 18-26 ein, wobei das Durchführen der Bewegungsvektorcodierung das Generieren eines Offsets vom Referenz-Patch über Koordinateninformationen, die in den Patch-Metadaten eingeschlossen sind, umfasst.
Beispiel 28 schließt den Gegenstand der Beispiele 18-27 ein, ferner umfassend das Entfernen von Punktwolken-Cracking in einer rekonstruierten gerenderten Oberfläche, einschließlich das Anwenden eines Gitters auf einen dekomprimierten Punktwolkendatensatz, wobei das Gitter einer ursprünglichen Abtastfrequenz einer ursprünglichen Datensatzerfassung entspricht, und das Anpassen von Punkten in einem gleichen Block des Gitters an kolokalisierte Positionen.
Einige Ausführungsformen betreffen Beispiel 29, das wenigstens ein computerlesbares Medium mit darauf gespeicherten Anweisungen einschließt, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, die Prozessoren zum Decodieren von Occupancy-Map-Daten und Hilfs-Patch-Informationen und Generieren einer Mehrzahl von Patch-Video-Frames basierend auf Patch-Daten, die von den Occupancy-Map-Daten und Hilfs-Patch-Informationen decodiert werden, veranlassen.
Beispiel 30 schließt den Gegenstand der Beispiele 18-29 ein, auf dem Anweisungen gespeichert sind, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, die Prozessoren ferner zum Transformieren der Patch-Video-Frames in eine dreidimensionale (3D-) Repräsentation und Rendern der 3D-Repräsentation veranlassen.
Die Erfindung wurde oben mit Bezug auf spezielle Ausführungsformen beschrieben. Fachleute auf dem Gebiet werden jedoch verstehen, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne vom weiter gefassten Wesen und Schutzbereich der Erfindung, wie in den beigefügten Ansprüchen dargelegt, abzuweichen. Die vorstehende Beschreibung und die Zeichnungen sind dementsprechend vielmehr in einem veranschaulichenden als in einem einschränkenden Sinne zu betrachten.

Claims

Vorrichtung zum Ermöglichen der Verarbeitung von Videobitstromdaten, umfassend: einen oder mehrere Prozessoren zum Decodieren von Occupancy-Map-Daten und Hilfs-Patch-Informationen und Generieren einer Mehrzahl von Patch-Video-Frames basierend auf Patch-Daten, die von den Occupancy-Map-Daten und Hilfs-Patch-Informationen decodiert werden; und einen Speicher, der kommunikativ mit dem einen oder den mehreren Prozessoren gekoppelt ist.
Vorrichtung nach Anspruch 1, wobei jeder der Mehrzahl von Patch-Video-Frames eine Patch-Identifizierung umfasst.
Vorrichtung nach Anspruch 2, wobei der eine oder die mehreren Prozessoren ferner die Patch-Video-Frames in eine dreidimensionale (3D-) Repräsentation transformieren sollen.
Vorrichtung nach Anspruch 3, wobei der eine oder die mehreren Prozessoren ferner einen Viewport von der 3D-Repräsentation rendern sollen.
Vorrichtung nach Anspruch 4, wobei der eine oder die mehreren Prozessoren ferner eine Artefaktreduzierung durchführen sollen, um die Patch-Video-Frames während des Renderns zu untersuchen, um das Vorhandensein eines oder mehrerer Artefakte zu detektieren.
Vorrichtung nach Anspruch 5, wobei das Untersuchen der Patch-Video-Frames das Anwenden eines Filters über eine Patch-Grenze im Patch-Video-Frame umfasst.
Vorrichtung nach Anspruch 3, wobei die 3D-Repräsentation eine 3D-Patch-Punktwolke umfasst.
Vorrichtung nach Anspruch 1, wobei der eine oder die mehreren Prozessoren ferner eine Patch-Orientierung während einer Bewegungsvorhersage ausrichten sollen.
Vorrichtung nach Anspruch 8, wobei der eine oder die mehreren Prozessoren ferner ein aktuelles Patch empfangen sollen und bestimmen sollen, ob eine Orientierung des aktuellen Patches mit einer Orientierung eines Referenz-Patches ausgerichtet ist.
Vorrichtung nach Anspruch 9, wobei der eine oder die mehreren Prozessoren ferner eine Bewegungsvorhersage des aktuellen Patches vom Referenz-Patch basierend auf der Ausrichtung durchführen sollen.
Vorrichtung nach Anspruch 1, wobei der eine oder die mehreren Prozessoren ferner eine Bewegungsvektorcodierung unter Verwendung eines Referenz-Patches und von Patch-Metadaten durchführen sollen.
Vorrichtung nach Anspruch 11, wobei der eine oder die mehreren Prozessoren ferner einen Offset vom Referenz-Patch über Koordinateninformationen generieren sollen, die in den Patch-Metadaten eingeschlossen sind.
Vorrichtung nach Anspruch 1, wobei der eine oder die mehreren Prozessoren ferner eine Patch-Grenzenextrapolation während einer Bewegungsschätzungscodierung durchführen sollen.
Vorrichtung nach Anspruch 13, wobei der eine oder die mehreren Prozessoren ferner einen optimalen Bewegungsvektor bestimmen sollen, der den Pixelfehler minimiert, aktuelle Pixel von Referenzpixeln subtrahieren sollen, um einen Rest realer Patch-Pixel zu erhalten, einen Hintergrundrest für verbleibende Hintergrundpixel eines aktuellen Blocks auf null festlegen sollen und den aktuellen Block codieren sollen.
Vorrichtung nach Anspruch 1, wobei der eine oder die mehreren Prozessoren ferner Punktwolken-Cracking in einer rekonstruierten gerenderten Oberfläche entfernen sollen, ein Gitter auf einen dekomprimierten Punktwolkendatensatz anwenden sollen, wobei das Gitter einer ursprünglichen Abtastfrequenz einer ursprünglichen Datensatzerfassung entspricht, und Punkte in einem gleichen Block des Gitters an kolokalisierte Positionen anpassen sollen.