DE102019117585A1

DE102019117585A1 - Selektives Packen von Patches für immersives Video

Info

Publication number: DE102019117585A1
Application number: DE102019117585.2A
Authority: DE
Inventors: Asaf J Shenberg; Eyal Ruhm; Jill Boyce
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-07-31
Filing date: 2019-06-28
Publication date: 2020-02-13
Also published as: US20240155094A1; US10887574B2; US11863731B2; US20200045290A1; US20210266515A1; CN110784714A

Abstract

Ausführungsformen sind allgemein auf selektives Packen von Patches für immersives Video gerichtet. Eine Ausführungsform eines Verarbeitungssystems weist einen oder mehrere Prozessorkerne auf und einen Speicher zum Speichern von Daten für immersives Video auf, wobei die Daten eine Mehrzahl von Patches für mehrere Projektionsrichtungen aufweisen. Das System soll die Patches zum Packen auswählen, wobei die Auswahl der Patches zumindest teilweise darauf basiert, welche der Mehrzahl von Projektionsrichtungen jedem der Patches zugeordnet ist. Das System soll die Patches gemäß der Auswahl der Patches in ein oder mehrere codierte Bilder codieren.

Description

VERWANDTE ANMELDUNG
Diese Anmeldung nimmt Bezug auf die US-Patentanmeldung Seriennummer 16/050153 des gleichen Anmelders mit dem Titel REDUCED RENDERING OF SIX-DEGREE OF FREEDOM VIDEO, von Jill Boyce, eingereicht am 31. Juli 2018, deren gesamter Inhalt hiermit durch Verweis übernommen wird.
TECHNISCHES GEBIET
Hier beschriebene Ausführungsformen beziehen sich allgemein auf das Gebiet elektronischer Einrichtungen und insbesondere auf das selektive Packen von Patches für immersives Video.
STAND DER TECHNIK
Sechs-Freiheitsgrade-(6DoF)-Video ist ein aufkommender immersiver Video-Anwendungsfall, der für einen Betrachter eine immersive Medienerfahrung bereitstellt, bei dem der Betrachter den Gesichtspunkt einer Szene steuert. Das einfachere Video mit drei Freiheitsgraden (3DoF) (z. B. 360-Grad- oder Panorama-Video) ermöglicht es einem Betrachter, die Ausrichtung um die X-, Y- und Z-Achse (als Gieren, Neigen und Rollen bezeichnet) von einer festen Position aus zu ändern. 6DoF-Video ermöglicht es dem Betrachter, die Position durch translatorische Bewegungen entlang der X-, Y- und Z-Achse zu ändern.
6DoF-Videos können mithilfe von Punktwolken dargestellt werden. Das Rendern von Punktwolkendaten ist jedoch rechenintensiv, was das Rendern von Punktwolkenvideos mit einer großen Anzahl von Punkten bei hohen Bildraten erschwert. Darüber hinaus sind Punktwolken-Datenraten groß, was eine große Speicherkapazität oder Übertragungskapazität erfordert.
Bei der Codierung von 6DoF-Videos, die von mehreren Kameras aufgenommen wurden, werden Patches von einzelnen Kameras oder Projektionen an Positionen virtueller Kameras mit Inhalten gebildet, die für diese bestimmte Kamera/virtuelle Kamera am besten sichtbar sind. Der Inhalt einer bestimmten Kamera oder virtuellen Kamera kann als Projektionsrichtung bezeichnet werden.
Textur- und Tiefen-Patches aus mehreren Projektionsrichtungen werden in ein einzelnes Bild gepackt und mit einem normalen Videocodec wie HEVC (High Efficiency Video Coding) oder AVC (Advanced Video Coding) codiert. MPEG Point Cloud Coding (PCC) verwendet Projektionen aus sechs Projektionsrichtungen, die Flächen eines Quaders entsprechen. Die Clients müssen dann jedoch das gesamte codierte Bild decodieren, das ein hochauflösendes Bild ist, da es Patches aus mehreren Projektionsrichtungen enthält. Das Decodieren eines gesamten codierten Bildes stellt eine erhebliche Belastung für einen Decoder dar und erfordert eine hohe Netzwerkbandbreite für die Übertragung.
Figurenliste
Hier beschriebene Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen dargestellt, in denen sich gleiche Bezugszeichen auf ähnliche Elemente beziehen.

1 ist ein Blockdiagramm eines Verarbeitungssystems gemäß einigen Ausführungsformen;
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors, aufweisend einen oder mehrere Prozessorkerne, eine integrierte Speichersteuerung und einen integrierten Grafikprozessor;
3 ist ein Blockdiagramm eines Grafikprozessors gemäß einigen Ausführungsformen;
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine eines Grafikprozessors gemäß einigen Ausführungsformen;
5 ist ein Blockdiagramm von Hardwarelogik eines Grafikprozessorkerns gemäß einigen Ausführungsformen;
6A-6B veranschaulichen eine Thread-Ausführungslogik, die ein Array von Verarbeitungselementen aufweist, die in einem Grafikprozessorkern gemäß einigen Ausführungsformen eingesetzt werden;
7 ist ein Blockdiagramm, das Grafikprozessoranweisungsformate gemäß einigen Ausführungsformen darstellt,
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors;
9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat gemäß einigen Ausführungsformen darstellt,
9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz gemäß einer Ausführungsform darstellt;
10 stellt eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einigen Ausführungsformen dar;
11A ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem darstellt, das verwendet werden kann, um eine integrierte Schaltung zur Durchführung von Operationen gemäß einer Ausführungsform herzustellen;
11B stellt eine Querschnittsseitenansicht einer Paketanordnung einer integrierten Schaltung gemäß einigen Ausführungsformen dar;
12 ist ein Blockdiagramm, das einen beispielhaften integrierten System-auf-einem-Chip-Schaltkreis darstellt, der unter Verwendung eines oder mehrerer IP-Kerne gemäß einer Ausführungsform hergestellt werden kann;
13A stellt einen beispielhaften Grafikprozessor eines integrierten System-auf-einem-Chip-Schaltkreis dar, der unter Verwendung eines oder mehrerer IP-Kerne gemäß einer Ausführungsform hergestellt werden kann;
13B stellt einen zusätzlichen beispielhaften Grafikprozessor eines integrierten System-auf-einem-Chip-Schaltkreises dar, der unter Verwendung eines oder mehrerer IP-Kerne gemäß einer Ausführungsform hergestellt werden kann;
14A stellt einen Grafikkern dar, der in einem Grafikprozessor gemäß einigen Ausführungsformen umfasst sein kann;
14B stellt eine hochparallele Grafikverarbeitungseinheit für allgemeine Zwecke dar, geeignet für den Einsatz auf einem Mehrchipmodul gemäß einigen Ausführungsformen;
15A stellt mehrere Formen von immersivem Video dar;
15B stellt Bildprojektions- und Texturebenen für immersives Video dar;
16 stellt ein Client-Server-System zur Erzeugung und zum Verbrauch von immersivem Video dar;
17A-17B veranschaulichen Systeme zum Codieren und Decodieren von 3DoF-Plus-Inhalt;
18A-18B veranschaulichen Systeme zum Codieren und Decodieren von 6DoF-Texturgeometriedaten;
19A-19B veranschaulichen ein System zum Codieren und Decodieren von 6DoF-Punktwolkendaten;
20A ist eine Darstellung eines Verarbeitungssystems zum Bereitstellen von selektivem Patch-Packen gemäß einigen Ausführungsformen;
20B ist eine Darstellung eines Client-Systems zum Decodieren eines oder mehrerer codierter Bilder, die ausgewählte Patches enthalten, gemäß einigen Ausführungsformen;
21 ist eine Darstellung eines Bildes für immersives Video unter Verwendung selektiven Packens von Patches gemäß einigen Ausführungsformen;
22 ist eine vereinfachte Darstellung von Patches, erzeugt für eine beispielhafte Gruppe von Bildern;
23 ist eine Darstellung einer beispielhaften Gruppe von Blickpunkten für ein System, aufweisend selektives Patch-Packen gemäß einigen Ausführungsformen;
24 ist eine Darstellung von selektivem Packen von Patches, um codierte Bilder für jeden Blickpunkt gemäß einigen Ausführungsformen bereitzustellen;
25A bis 25D veranschaulichen Gruppen von Blickpunkten für selektives Packen von Patches gemäß einigen Ausführungsformen;
27A ist eine Darstellung des selektiven Packens von Patches in Kacheln entsprechend der Projektionsrichtung gemäß einigen Ausführungsformen;
27B ist eine Darstellung des selektiven Packens von Patches in Kacheln entsprechend Gruppen von Projektionsrichtungen gemäß einigen Ausführungsformen;
28A ist ein Ablaufdiagramm zur Darstellung eines Prozesses zum selektiven Packen von Patches gemäß einigen Ausführungsformen; und
28B ist ein Ablaufdiagramm zur Darstellung eines Prozesses zum Decodieren und Entpacken von selektiv gepackten Patches gemäß einigen Ausführungsformen.

DETAILLIERTE BESCHREIBUNG
Hier beschriebene Ausführungsformen sind allgemein auf das selektive Packen von Patches für immersives Video gerichtet.
Bei der Codierung von 6DoF-Videos (sechs Freiheitsgrade), die von mehreren Kameras erfasst wurden, werden Patches von einzelnen Kameras oder Projektionen virtueller Kameras an Positionen mit Inhalten gebildet, die für die betreffende bestimmte Kamera/virtuelle Kamera am besten sichtbar sind. Der Inhalt einer bestimmten Kamera oder virtuellen Kamera kann als Projektionsrichtung bezeichnet werden.
Textur- und Tiefen-Patches aus mehreren Projektionsrichtungen werden in ein einzelnes Bild gepackt und mit einem normalen Videocodec wie HEVC (High Efficiency Video Coding) oder AVC (Advanced Video Coding) codiert. MPEG Point Cloud Coding (PCC) verwendet Projektionen aus sechs Projektionsrichtungen, die Flächen eines Quaders entsprechen. Die Clients müssen dann jedoch das gesamte codierte Bild decodieren, das ein hochauflösendes Bild ist, da es Patches aus mehreren Projektionsrichtungen enthält. Das Decodieren eines gesamten codierten Bildes stellt eine erhebliche Belastung für einen Decoder dar und erfordert eine hohe Netzwerkbandbreite für die Übertragung.
Bei einigen Ausführungsformen stellen eine Vorrichtung, ein System oder ein Prozess selektives Packen von Patches für immersives Video bereit. Bei einigen Ausführungsformen werden die Patches danach ausgewählt, welche einer Mehrzahl von Projektionsrichtungen jedem der Patches zugeordnet ist.
Systemübersicht
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. Bei verschiedenen Ausführungsformen weist das System 100 einen oder mehrere Prozessoren 102 und einen oder mehrere Grafikprozessoren 108 auf und kann ein Einzelprozessor-Desktopsystem, ein Multiprozessor-Workstationsystem oder ein Serversystem sein, das eine große Anzahl von Prozessoren 102 oder Prozessorkernen 107 aufweist. Bei einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in einer integrierten System-auf-einem-Chip-(SoC)-Schaltung zur Verwendung in Mobil-, Handheld- oder eingebetteten Einrichtungen umfasst ist.
Bei einer Ausführungsform kann das System 100 eine Spielkonsole aufweisen, umfassend eine Spiel- und Medienkonsole, eine mobile Gaming-Konsole, eine Handheld Gaming-Konsole oder eine Online-Gaming-Konsole, oder es kann in eine serverbasierte Gaming-Plattform integriert sein. Bei einigen Ausführungsformen ist das System 100 ein Mobiltelefon, ein Smartphone, eine Tablet-Recheneinrichtung oder eine mobile Interneteinrichtung. Das Verarbeitungssystem 100 kann auch eine am Körper tragbare Einrichtung umfassen, damit gekoppelt oder in diese integriert sein, wie beispielsweise eine am Körper tragbare Smartwatch-Einrichtung, eine Smart-Eyewear-Einrichtung, eine Einrichtung mit erweiterter Realität oder eine Einrichtung mit virtueller Realität. Bei einigen Ausführungsformen ist das Verarbeitungssystem 100 eine Fernseh- oder Set-Top-Box-Einrichtung mit einem oder mehreren Prozessoren 102 und einer grafischen Schnittstelle, die von einem oder mehreren Grafikprozessoren 108 erzeugt wird.
Bei einigen Ausführungsformen umfassen der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 zur Verarbeitung von Anweisungen, die bei ihrer Ausführung Operationen für System- und Benutzersoftware durchführen. Bei einigen Ausführungsformen ist jeder der ein oder mehreren Prozessorkerne 107 dafür ausgelegt, einen spezifischen Befehlssatz 109 zu verarbeiten. Bei einigen Ausführungsformen kann der Befehlssatz 109 das Rechnen mit komplexem Befehlssatz (CISC), das Rechnen mit reduziertem Befehlssatz (RISC) oder das Rechnen über ein sehr langes Befehlswort (VLIW) ermöglichen. Mehrere Prozessorkerne 107 können jeweils einen unterschiedlichen Befehlssatz 109 verarbeiten, der Befehle aufweisen kann, um die Emulation anderer Befehlssätze zu ermöglichen. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen aufweisen, beispielsweise einen digitalen Signalprozessor (DSP).
Bei einigen Ausführungsformen weist der Prozessor 102 einen Cache-Speicher 104 auf. Abhängig von der Architektur, kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Ebenen von internem Cache aufweisen. Bei einigen Ausführungsformen wird der Cache-Speicher von verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. Bei einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z. B. einen Level-3 (L3) Cache oder einen Last-Level-Cache (LLC)) (nicht gezeigt), der unter Verwendung bereits bekannter Cache-Kohärenztechniken von den Prozessorkernen 107 gemeinsam genutzt werden kann. Der Prozessor 102 weist zusätzlich eine Registerdatei 106 auf, die unterschiedliche Arten von Registern zum Speichern unterschiedlicher Datentypen umfassen kann (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister). Einige Register können Register für allgemeine Zwecke sein, während andere Register für das Design des Prozessors 102 spezifisch sein können.
Bei einigen Ausführungsformen sind ein oder mehrere Prozessoren 102 mit einem oder mehreren Schnittstellenbus(sen) 110 gekoppelt, um Kommunikationssignale wie Adressen, Daten oder Steuersignale zwischen dem Prozessor 102 und anderen Komponenten im System 100 zu übertragen. Bei einer Ausführungsform kann der Schnittstellenbus 110 ein Prozessorbus sein, beispielsweise eine Version des Busses der direkten Medienschnittstelle (DMI). Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral-Component-Interconnect-Busse (z. B. PCI, PCI Express), Speicherbusse oder andere Arten von Schnittstellenbussen aufweisen. Bei einer Ausführungsform weisen die Prozessoren 102 eine integrierte Speichersteuerung 116 und einen Plattformsteuerungs-Hub 130 auf. Die Speichersteuerung 116 ermöglicht die Kommunikation zwischen einer Speichereinrichtung und anderen Komponenten des Systems 100, während der Plattformsteuerungs-Hub (PCH) 130 Verbindungen zu E/A-Einrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Speichereinrichtung 120 kann eine dynamische Direktzugriffsspeichereinrichtung (DRAM), eine statische Direktzugriffsspeichereinrichtung (SRAM), eine Flash-Speichereinrichtung, eine Phasenänderungsspeichereinrichtung oder eine andere Speichereinrichtung mit geeigneter Leistung sein, um als Prozessspeicher zu wirken. Bei einer Ausführungsform kann die Speichereinrichtung 120 als Systemspeicher für das System 100 wirken, um Daten 122 und Anweisungen 121 zur Verwendung zu speichern, wenn der eine Prozessor oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Die Speichersteuerung 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. Bei einigen Ausführungsformen kann eine Anzeigeeinrichtung 111 mit den Prozessoren 102 verbunden sein. Die Anzeigeeinrichtung 111 kann eine oder mehrere interne Anzeigeeinrichtungen sein, wie beispielsweise eine mobile elektronische Einrichtung oder eine Laptopeinrichtung oder eine externe Anzeigeeinrichtung, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angeschlossen ist. Bei einer Ausführungsform kann die Anzeigeeinrichtung 111 eine am Kopf befestigte Anzeige (HMD) sein, beispielsweise eine stereoskopische Anzeigeeinrichtung zur Verwendung in Anwendungen virtueller Realität (VR) oder Anwendungen erweiterter Realität (AR).
Bei einigen Ausführungsformen ermöglicht der Plattformsteuerungs-Hub 130 Peripherieeinrichtungen die Verbindung mit der Speichereinrichtung 120 und dem Prozessor 102 über einen Hochgeschwindigkeits-E/A-Bus. Die E/A-Peripherieeinrichtungen umfassen ohne diesbezügliche Einschränkung eine Audiosteuerung 146, eine Netzwerksteuerung 134, eine Firmwareschnittstelle 128, einen drahtlosen Sendeempfänger 126, berührungssensible Sensoren 125, eine Datenspeichereinrichtung 124 (z. B. Festplattenlaufwerk, Flash-Speicher usw.). Die Datenspeichereinrichtung 124 kann über eine Speicherschnittstelle (z. B. SATA) oder über einen Peripheriebus, wie z. B. einen Peripheral-Component-Interconnect-Bus (z. B. PCI, PCIExpress), verbunden sein. Die berührungssensiblen Sensoren 125 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren aufweisen. Der drahtlose Sendeempfänger 126 kann ein Wi-Fi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein Mobilfunknetz-Sendeempfänger wie ein 3G-, 4G- oder Long-Term-Evolution-(LTE)-Sendeempfänger sein. Die Firmware-Schnittstelle 128 ermöglicht die Kommunikation mit der Systemfirmware und kann beispielsweise eine einheitliche erweiterbare Firmware-Schnittstelle (UEFI) sein. Die Netzwerksteuerung 134 kann eine Netzwerkverbindung zu einem kabelgebundenen Netzwerk ermöglichen. Bei einigen Ausführungsformen ist eine Hochleistungsnetzwerksteuerung (nicht gezeigt) mit dem Schnittstellenbus 110 gekoppelt. Die Audiosteuerung 146 ist bei einer Ausführungsform eine Mehrkanal-Audiosteuerung mit hoher Auflösung. Bei einer Ausführungsform umfasst das System 100 einen optionalen Legacy-E/A-Controller 140 zum Koppeln von übernommenen Altgeräten (z. B. Personal System 2 (PS/2)) an das System. Der Plattformsteuerungs-Hub 130 kann ebenfalls eine Verbindung zu einem oder mehreren USB-Steuerungen (Universal Serial Bus) 142 herstellen, die Eingabeeinrichtungen wie Tastatur- und Mauskombinationen 143, eine Kamera 144 oder andere USB-Eingabeeinrichtungen verbinden.
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 ausgelegt sind. Beispielsweise kann eine Instanz der Speichersteuerung 116 und des Plattformsteuerungs-Hubs 130 in einen diskreten externen Grafikprozessor wie den externen Grafikprozessor 112 integriert sein. Bei einer Ausführungsform können der Plattformsteuerungs-Hub 130 und/oder die Speichersteuerung 160 außerhalb des einen Prozessors oder der mehreren Prozessoren 102 sein. Beispielsweise kann das System 100 eine externe Speichersteuerung 116 und einen Plattformsteuerungs-Hub 130 umfassen, die als Speichersteuerungs-Hub und Peripheriesteuerungs-Hub in einem Systemchipsatz eingerichtet sein können, der mit dem Prozessor (den Prozessoren) 102 in Kommunikation steht.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200, aufweisend einen oder mehrere Prozessorkerne 202A-202N, eine integrierte Speichersteuerung 214 und einen integrierten Grafikprozessor 208. Diese Elemente von 2, die die gleichen Bezugszeichen (oder Bezeichnungen) aufweisen wie die Elemente einer beliebigen anderen hier wiedergegebenen Figur, können auf ähnliche Weise wie hier an anderer Stelle beschrieben arbeiten oder wirken, sind jedoch nicht diesbezüglich eingeschränkt. Der Prozessor 200 kann zusätzliche Kerne bis einschließlich des zusätzlichen Kerns 202N aufweisen, der durch die gestrichelten Kästchen dargestellt wird. Jeder der Prozessorkerne 202A-202N enthält eine oder mehrere interne Cache-Einheiten 204A-204N. Bei einigen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf eine oder mehrere gemeinsam genutzte in Cache abgelegte Einheiten 206.
Die internen Cache-Einheiten 204A-204N und die gemeinsam genutzten Cache-Einheiten 206 repräsentieren eine Cache-Speicherhierarchie innerhalb des Prozessors 200. Die Cache-Speicherhierarchie kann mindestens eine Befehls- und Daten-Cache-Ebene in jedem Prozessorkern und eine oder mehrere Ebenen eines gemeinsam genutzten Cache mittlerer Ebene, wie z. B. Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4), oder andere Cache-Ebenen aufweisen, wobei die höchste Cache-Ebene vor dem externen Speicher als LLC klassifiziert wird. Bei einigen Ausführungsformen hält die Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A-204N aufrecht.
Bei einigen Ausführungsformen kann der Prozessor 200 auch eine Gruppe von einer oder mehreren Bussteuerungseinheiten 216 und einen Systemagentenkern 210 aufweisen. Die eine oder mehreren Bussteuerungseinheiten 216 verwalten eine Gruppe von Peripheriebussen, wie beispielsweise einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 210 stellt Verwaltungsfunktionen für die verschiedenen Prozessorkomponenten bereit. Bei einigen Ausführungsformen umfasst der Systemagentenkern 210 einen oder mehrere integrierte Speichersteuerungen 214, um den Zugriff auf verschiedene externe Speichereinrichtungen (nicht gezeigt) zu verwalten.
Bei einigen Ausführungsformen umfassen ein oder mehrere der Prozessorkerne 202A-202N Unterstützung für gleichzeitiges Multithreading. Bei 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 Leistungssteuerungseinheit (PCU) aufweisen, die Logik und Komponenten zum Regeln des Leistungszustands der Prozessorkerne 202A-202N und des Grafikprozessors 208 aufweist.
Bei einigen Ausführungsformen weist der Prozessor 200 zusätzlich einen Grafikprozessor 208 auf, um Grafikverarbeitungsoperationen auszuführen. Bei einigen Ausführungsformen ist der Grafikprozessor 208 mit der Gruppe von gemeinsam genutzten Cache-Einheiten 206 und dem Systemagentenkern 210, der die eine oder die mehreren integrierten Speichersteuerungen 214 aufweist, gekoppelt. Bei einigen Ausführungsformen umfasst der Systemagentenkern 210 auch eine Anzeigesteuerung 211, um die Grafikprozessorausgabe an eine oder mehrere gekoppelte Anzeigen zu steuern. Bei einigen Ausführungsformen kann die Anzeigesteuerung 211 auch ein separates Modul sein, das über mindestens eine Verbindung mit dem Grafikprozessor gekoppelt ist, oder sie kann in den Grafikprozessor 208 integriert sein.
Bei einigen Ausführungsformen wird eine ringbasierte Verbindungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es können jedoch alternative Verbindungseinheiten verwendet werden, beispielsweise eine Punkt-zu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Techniken, umfassend auf diesem Gebiet bereits bekannte Techniken. Bei einigen Ausführungsformen ist der Grafikprozessor 208 über eine E/A-Verbindung 213 mit der Ringverbindung 212 gekoppelt.
Die beispielhafte E/A-Verbindung 213 stellt mindestens eine von mehreren Arten von E/A-Verbindungen dar, umfassend eine On-Package-E/A-Verbindung, die die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsspeichermodul 218, wie einem eDRAM-Modul, ermöglicht. Bei einigen Ausführungsformen verwenden jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als gemeinsam genutzten Last-Level-Cache.
Bei einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, die dieselbe Befehlssatzarchitektur ausführen. Bei einer anderen Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Befehlssatzarchitektur (ISA) heterogen, wobei einer oder mehrere der Prozessorkerne 202A-202N einen ersten Befehlssatz ausführen, während mindestens einer der anderen Kerne eine Untergruppe des ersten Befehlssatzes oder einen anderen Befehlssatz ausführt. Bei einer Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Mikroarchitektur heterogen, wobei ein oder mehrere Kerne, die einen relativ höheren Stromverbrauch aufweisen, mit einem oder mehreren Leistungskernen gekoppelt sind, die einen geringeren Stromverbrauch aufweisen. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte SoC-Schaltung implementiert sein, die zusätzlich zu anderen Komponenten die dargestellten Komponenten aufweist.
3 ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit oder ein Grafikprozessor sein kann, der mit einer Vielzahl von Verarbeitungskernen integriert ist. Bei einigen Ausführungsformen kommuniziert der Grafikprozessor über eine in Speicher abgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die im Prozessorspeicher platziert sind. Bei einigen Ausführungsformen weist der Grafikprozessor 300 eine Speicherschnittstelle 314 auf, um auf den Speicher zuzugreifen. Die Speicherschnittstelle 314 kann eine Schnittstelle zu lokalem Speicher, zu einem oder mehreren internen Caches, zu einem oder mehreren gemeinsam genutzten externen Caches und/oder zum Systemspeicher sein.
Bei einigen Ausführungsformen umfasst der Grafikprozessor 300 auch eine Anzeigesteuerung 302, um Anzeigeausgabedaten zu einer Anzeigeeinrichtung 320 zu steuern. Die Anzeigesteuerung 302 weist Hardware für eine oder mehrere Überlagerungsebenen zum Anzeigen und Zusammensetzen mehrerer Schichten von Video- oder Benutzerschnittstellenelementen auf. Die Anzeigeeinrichtung 320 kann eine interne oder externe Anzeigeeinrichtung sein. Bei einer Ausführungsform ist die Anzeigeeinrichtung 320 eine am Kopf befestigte Anzeigeeinrichtung, wie beispielsweise eine Anzeigeeinrichtung für virtuelle Realität (VR) oder eine Anzeigeeinrichtung für erweiterte Realität (AR). Bei einigen Ausführungsformen umfasst der Grafikprozessor 300 eine Videocodec-Engine 306 zum Codieren, Decodieren oder Transcodieren von Medien in, von oder zwischen einem oder mehreren Mediencodierungsformaten, ohne diesbezügliche Einschränkung aufweisend Formate der „Moving Picture Experts Group“ (MPEG) wie MPEG-2, Formate erweiterter Videocodierung (AVC) wie H.264/MPEG-4 AVC, sowie die Formate der „Society of Motion Picture & Television Engineers“ (SMPTE) 421M/VC-1 und Formate der „Joint Photographic Experts Group“ (JPEG) Formate wie JPEG und Motion JPEG (MJPEG).
Bei einigen Ausführungsformen weist der Grafikprozessor 300 eine Blockbildübertragungs-Engine (BLIT) 304 auf, um zweidimensionale (2D) Rasteroperationen durchzuführen, die beispielsweise Bitgrenzenblockübertragungen aufweisen. Bei einer Ausführungsform werden jedoch 2D-Grafikoperationen unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE) 310 durchgeführt. Bei einigen Ausführungsformen ist die GPE 310 eine Rechen-Engine zum Durchführen von Grafikoperationen, umfassend dreidimensionale (3D) Grafikoperationen und Medienoperationen.
Bei einigen Ausführungsformen weist die GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen auf, wie zum Beispiel zum Rendern dreidimensionaler Bilder und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Grundformen einwirken (z. B. Rechteck, Dreieck usw.). Die 3D-Pipeline 312 weist programmierbare und feste Funktionselemente auf, die verschiedene Aufgaben innerhalb des Element- und/oder Spawn-Ausführungs-Threads für ein 3D/Mediensubsystem 315 durchführen. Während die 3D-Pipeline 312 zum Durchführen von Medienoperationen verwendet werden kann, weist eine Ausführungsform der GPE 310 auch eine Medienpipeline 316 auf, die spezifisch zum Durchführen von Medienoperationen eingesetzt wird, wie zum Beispiel Videonachbearbeitung und Bildverbesserung.
Bei einigen Ausführungsformen umfasst die Medienpipeline 316 feste Funktionen oder programmierbare Logikeinheiten zum Durchführen von einer oder mehreren spezialisierten Medienoperationen, wie beispielsweise Videodecodierbeschleunigung, Video-De-Interlacing und Videocodierbeschleunigung, anstelle der oder auf Veranlassung durch die Videocodec-Engine 306. Bei einigen Ausführungsformen umfasst die Medien-Pipeline 316 zusätzlich eine Thread-Spawning-Einheit, um Child-Threads zur Ausführung auf dem 3D/Mediensubsystem 315 zu erzeugen. Die erzeugten Threads führen Berechnungen für die Medienoperationen an einer oder mehreren Grafikausführungseinheiten durch, die in dem 3D/Mediensubsystem 315 umfasst sind.
Bei einigen Ausführungsformen weist das 3D/Mediensubsystem 315 eine Logik zum Ausführen von Threads auf, die von der 3D-Pipeline 312 und der Medien-Pipeline 316 erzeugt wurden. Bei einer Ausführungsform senden die Pipelines Thread-Ausführungsanforderungen an das 3D/Mediensubsystem 315, das eine Thread-Verteilungslogik zum Arbitrieren und Verteilen der verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen aufweist. Die Ausführungsressourcen umfassen ein Array von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medien-Threads. Bei einigen Ausführungsformen weist das 3D/Mediensubsystem 315 einen oder mehrere interne Caches für Thread-Anweisungen und Daten auf. Bei einigen Ausführungsformen umfasst das Subsystem auch gemeinsam genutzten Speicher, der Register und adressierbaren Speicher aufweist, um Daten zwischen Threads gemeinsam zu nutzen und Ausgabedaten zu speichern.
Grafikverarbeitungs-Engine
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors gemäß einigen Ausführungsformen. Bei einer Ausführungsform ist die Grafikverarbeitungs-Engine (GPE) 410 eine Version der GPE 310, gezeigt in 3. Elemente von 4, die die gleichen Bezugszeichen (oder Bezeichnungen) aufweisen wie die Elemente einer beliebigen anderen hier wiedergegebenen Figur, können auf ähnliche Weise wie hier an anderer Stelle beschrieben arbeiten oder wirken, sind jedoch nicht diesbezüglich eingeschränkt. Zum Beispiel sind die 3D-Pipeline 312 und die Medien-Pipeline 316 von 3 dargestellt. Die Medienpipeline 316 ist bei einigen Ausführungsformen der GPE 410 optional und möglicherweise nicht explizit in der GPE 410 umfasst. Beispielsweise und bei mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
Bei einigen Ausführungsformen ist die GPE 410 mit einem Befehls-Streamer 403 gekoppelt oder weist ihn auf, der einen Befehls-Stream zu der 3D-Pipeline 312 und/oder den Medien-Pipelines 316 bereitstellt. Bei einigen Ausführungsformen ist der Befehls-Streamer 403 mit Speicher gekoppelt, der ein Systemspeicher sein kann oder ein oder mehrere von internem Cache-Speicher und gemeinsam genutztem Cache-Speicher. Bei einigen Ausführungsformen empfängt der Befehls-Streamer 403 Befehle aus dem Speicher und sendet die Befehle zu der 3D-Pipeline 312 und/oder der Medien-Pipeline 316. Die Befehle sind Anweisungen, die aus einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 312 und die Medien-Pipeline 316 speichert. Bei einer Ausführungsform kann der Ringpuffer zusätzlich Stapelbefehlspuffer aufweisen, die Stapel von mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Verweise auf Daten aufweisen, die im Speicher gespeichert sind, wie beispielsweise, aber ohne diesbezügliche Einschränkung, Scheitel- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 312 und die Medien-Pipeline 316 verarbeiten die Befehle und Daten durch Durchführen von Operationen über Logik innerhalb der jeweiligen Pipelines oder durch Verteilen eines oder mehrerer Ausführungsthreads zu einem Grafikkern-Array 414. Bei einer Ausführungsform umfasst das Grafikkern-Array 414 einen oder mehrere Blöcke von Grafikkernen (z. B. Grafikkern(e) 415A, Grafikkern(e) 415B), wobei jeder Block einen oder mehrere Grafikkerne aufweist. Jeder Grafikkern weist eine Reihe von Grafikausführungsressourcen auf, die allgemeine und grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Rechenoperationen aufweisen, sowie Texturverarbeitung mit festen Funktionen und/oder maschinelles Lernen und Beschleunigungslogik für künstliche Intelligenz.
Bei verschiedenen Ausführungsformen umfasst die 3D-Pipeline 312 eine Festfunktions- und programmierbare Logik, um ein oder mehrere Shader-Programme wie Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Rechen-Shader oder andere Shader-Programme abzuarbeiten, indem die Anweisungen abgearbeitet und Ausführungs-Threads zu dem Grafikkern-Array 414 verteilt werden. Das Grafikkernarray 414 stellt einen einheitlichen Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shader-Programme bereit. Die Mehrzweck-Ausführungslogik (z. B. Ausführungseinheiten) in dem/den Kern(en) des Grafikkerns 415A-414B des Grafikkern-Arrays 414 weist die Unterstützung verschiedener 3D-API-Shader-Sprachen auf und kann mehrere gleichzeitige Ausführungs-Threads ausführen, die mehreren Shadern zugeordnet sind.
Bei einigen Ausführungsformen umfasst das Grafikkern-Array 414 auch Ausführungslogik zum Ausführen von Medienfunktionen, wie z. B. Video- und/oder Bildverarbeitung. Bei einer Ausführungsform weisen die Ausführungseinheiten zusätzlich Logik für allgemeine Zwecke auf, die programmierbar ist, um zusätzlich zu Grafikverarbeitungsoperationen parallele allgemeine Rechenoperationen durchzuführen. Die Logik für allgemeine Zwecke kann Verarbeitungsoperationen parallel oder in Verbindung mit der Logik für allgemeine Zwecke in dem Prozessorkern (den Prozessorkernen) 107 von 1 oder Kern 202A-202N wie in 2.
Ausgabedaten, die von Threads erzeugt werden, die auf dem Grafikkern-Array 414 ausgeführt werden, können Daten zu Speicher in einem einheitlichen Rückmeldepuffer (URB) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. Bei einigen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen unterschiedlichen Threads zu senden, die auf dem Grafikkern-Array 414 ausgeführt werden. Bei 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.
Bei einigen Ausführungsformen ist das Grafikkern-Array 414 skalierbar, sodass das Array eine variable Anzahl von Grafikkernen aufweist, die jeweils eine variable Anzahl von Ausführungseinheiten aufweisen, basierend auf der Zielleistung und der Leistungsstufe der GPE 410. Bei einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, sodass 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 von den Grafikkernen in dem Grafikkern-Array gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen innerhalb der gemeinsam genutzten Funktionslogik 420 sind Hardware-Logikeinheiten, die spezialisierte zusätzliche Funktionalität für das Grafikkern-Array 414 bereitstellen. Bei verschiedenen Ausführungsformen weist die gemeinsam genutzte Funktionslogik 420 ohne diesbezügliche Einschränkung eine Sampler-Logik 421, Mathematik-Logik 422 und Inter-Thread-Kommunikations-(ITC)-Logik 423 auf. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Cache(s) 425 in der gemeinsam genutzten Funktionslogik 420.
Eine gemeinsam genutzte Funktion wird implementiert, wenn der Bedarf an einer gegebenen spezialisierten Funktion für die Aufnahme in das Grafikkern-Array 414 unzureichend ist. Stattdessen wird eine einzelne Instanziierung der betreffenden spezialisierten Funktion als eigenständige Einheit in der gemeinsam genutzten Funktionslogik 420 implementiert und von den Ausführungsressourcen in dem Grafikkern-Array 414 gemeinsam genutzt. Die genaue Gruppe von Funktionen, die in dem Grafikkern-Array 414 gemeinsam genutzt werden und in dem Grafikkern-Array 414 umfasst sind, variiert zwischen Ausführungsformen. Bei einigen Ausführungsformen können bestimmte gemeinsam genutzte Funktionen in der gemeinsam genutzten Funktionslogik 420, die von dem Grafikkern-Array 414 weitläufig verwendet werden, in der gemeinsam genutzten Funktionslogik 416 in dem Grafikkern-Array 414 umfasst sein. Bei verschiedenen Ausführungsformen kann die gemeinsam genutzte Funktionslogik 416 in dem Grafikkern-Array 414 einen Teil der oder die gesamte Logik in der gemeinsam genutzten Funktionslogik 420 aufweisen. Bei 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. Bei einer Ausführungsform ist die gemeinsam genutzte Funktionslogik 420 zugunsten der gemeinsam genutzten Funktionslogik 416 innerhalb des Grafikkern-Arrays 414 ausgeschlossen.
5 ist ein Blockdiagramm von Hardwarelogik eines Grafikprozessorkerns 500 gemäß einigen hier beschriebenen Ausführungsformen. Elemente von 5, die die gleichen Bezugszeichen (oder Bezeichnungen) aufweisen wie die Elemente einer beliebigen anderen hier wiedergegebenen Figur, können auf ähnliche Weise wie hier an anderer Stelle beschrieben arbeiten oder wirken, sind jedoch nicht diesbezüglich eingeschränkt. Der dargestellte Grafikprozessorkern 500 ist bei einigen Ausführungsformen in dem Grafikkern-Array 414 von 4. Der Grafikprozessorkern 500, der manchmal als Kernschnitt bezeichnet wird, kann einen oder mehrere Grafikkern(e) in einem modularen Grafikprozessor sein. Der Grafikprozessorkern 500 ist beispielhaft für einen Grafikkernschnitt, und ein hier beschriebener Grafikprozessor kann mehrere Grafikkernschnitte auf der Grundlage von Zielleistung und Leistungsbereichen enthalten. Jeder Grafikkern 500 kann einen Festfunktionsblock 530 aufweisen, der mit mehreren Subkernen 501A-501F gekoppelt ist, die auch als Subschnitte bezeichnet werden, und er kann modulare Blöcke für allgemeine und Festfunktionslogik aufweisen.
Bei einigen Ausführungsformen weist der Festfunktionsblock 530 eine Geometrie-/Festfunktions-Pipeline 536 auf, die von allen Subkernen im Grafikprozessor 500 gemeinsam genutzt werden kann, zum Beispiel bei Implementierungen mit niedrigerer Performanz und/oder Grafikprozessor-Implementierungen mit niedriger Leistung. Bei verschiedenen Ausführungsformen weist die Geometrie-/Festfunktions-Pipeline 536 eine 3D-Festfunktions-Pipeline auf (z. B. die 3D-Pipeline 312 entsprechend 3 und 4), eine Video-Frontend-Einheit, einen Thread-Spawner und Thread-Verteiler und einen „Unified Return Buffer“-Manager, der einheitliche Rückmeldepuffer verwaltet, wie beispielsweise den einheitlichen Rückmeldepuffer 418 aus 4.
Bei einer Ausführungsform umfasst der Festfunktionsblock 530 auch eine Grafik-SoC-Schnittstelle 537, eine Grafik-Mikrosteuerung 538 und eine Medien-Pipeline 539. Die Grafik-SoC-Schnittstelle 537 stellt eine Schnittstelle zwischen dem Grafikkern 500 und anderen Prozessorkernen in einer integrierten System-auf-einem-Chip-Schaltung bereit. Die Grafik-Mikrosteuerung 538 ist ein programmierbarer Subprozessor, der zum Verwalten verschiedener Funktionen des Grafikprozessors 500 einschließlich Thread-Verteilung, Zeitplanung und Präemption einrichtbar ist. Die Medien-Pipeline 539 (z. B. die Medien-Pipeline 316 von 3 und 4) weist Logik zum Ermöglichen des Decodierens, Codierens, Vorverarbeitens und/oder Nachverarbeitens von Bild- und Videodaten umfassenden Multimediadaten auf. Die Medien-Pipeline 539 implementiert Medienoperationen über Anforderungen zum Berechnen oder Abtasten von Logik in den Subkernen 501-501F.
Bei einer Ausführungsform ermöglicht die SoC-Schnittstelle 537, dass der Grafikkern 500 mit Anwendungsprozessorkernen für allgemeine Zwecke (z. B. CPUs) und/oder anderen Komponenten in einem SoC kommuniziert, umfassend Speicherhierarchieelemente, wie einen gemeinsam genutzten Last-Level-Cache-Speicher, dem System-RAM und/oder eingebettetem On-Chip- oder On-Package-DRAM. Die SoC-Schnittstelle 537 kann auch die Kommunikation mit Festfunktioneinrichtungen innerhalb des SoC ermöglichen, wie z. B. bildgebenden Kamera-Pipelines, und sie ermöglicht die Verwendung von globalem atomarem Speicher, der zwischen dem Grafikkern 500 und den CPUs innerhalb des SoC gemeinsam genutzt werden kann. Die SoC-Schnittstelle 537 kann auch Energieverwaltungssteuerungen 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. Bei einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 den Empfang von Befehlspuffern von einem Befehls-Streamer und globalem Thread-Verteiler, die dafür ausgelegt sind, Befehle und Anweisungen für jeden der ein oder mehreren Grafikkerne in einem Grafikprozessor bereitzustellen. Die Befehle und Anweisungen können an die Medien-Pipeline 539 gesendet werden, wenn Medienoperationen durchzuführen sind, oder an eine Geometrie- und Festfunktions-Pipeline (z. B. Geometrie- und Festfunktions-Pipeline 536, Geometrie- und Festfunktions-Pipeline 514), wenn Grafikverarbeitungsoperationen durchgeführt werden sollen.
Die Grafik-Mikrosteuerung 538 kann dafür ausgelegt sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikkern 500 durchzuführen. Bei einer Ausführungsform kann die Grafik-Mikrosteuerung 538 eine Grafik- und/oder Rechenarbeitslastplanung auf den verschiedenen parallelen Grafik-Engines in den Ausführungseinheit-(EU)-Arrays 502A-502F, 504A-504F in den Subkernen 501A-501F durchführen. Bei diesem Planungsmodell kann Host-Software, die auf einem CPU-Kern eines den Grafikkern 500 aufweisenden SoC Software ausführt, Auslastungen von einer von mehreren Grafikprozessor-Doorbells senden, wodurch eine Planungsoperation auf der entsprechenden Grafik-Engine aufgerufen wird. Zeitplanungsoperationen umfassen die Festlegung, welche Arbeitslast als nächstes ausgeführt wird, das Senden einer Arbeitslast zu einem Befehls-Streamer, die Präemption vorhandener Workloads auf einer Engine, die Überwachung des Fortschritts einer Arbeitslast und die Benachrichtigung von Host-Software, wenn eine Arbeitslast abgeschlossen ist. Bei einer Ausführungsform kann die Grafik-Mikrosteuerung 538 auch Zustände mit niedriger Leistung oder Inaktivität für den Grafikkern 500 ermöglichen, wobei für den Grafikkern 500 die Möglichkeit bereitgestellt wird, Register im Grafikkern 500 über Niederstrom-Statusübergänge zu speichern und wiederherzustellen, und zwar unabhängig vom Betriebssystem und/oder der Grafiktreibersoftware auf dem System.
Der Grafikkern 500 kann mehr oder weniger als die dargestellten Subkerne 501A-501F und bis zu N modulare Subkerne aufweisen. Für jede Gruppe von N-Subkernen kann der Grafikkern 500 auch gemeinsam genutzte Funktionslogik 510, gemeinsam genutzten und/oder Cache-Speicher 512, eine Geometrie-/Festfunktions-Pipeline 514 sowie zusätzliche Festfunktionslogik 516 aufweisen, um verschiedene Grafik- und Rechenverarbeitungsvorgänge zu beschleunigen. Die gemeinsam genutzte Funktionslogik 510 kann Logikeinheiten aufweisen, die der gemeinsam genutzten Funktionslogik 420 aus 4 zugeordnet sind (z. B. Sampler-, Mathematik- und/oder Inter-Thread-Kommunikationslogik), die von jedem der N Subkerne im Grafikkern 500 gemeinsam genutzt werden kann. Der gemeinsam genutzte und/oder Cache-Speicher 512 kann ein Last-Level-Cache für die Gruppe von N Subkernen 501A-501F innerhalb des Grafikkerns 500 sein und 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 in dem Festfunktionsblock 530 umfasst sein und die gleichen oder ähnliche Logikeinheiten aufweisen.
Bei einer Ausführungsform weist der Grafikkern 500 zusätzliche Festfunktionslogik 516 auf, die verschiedene Festfunktionsbeschleunigungslogik für die Verwendung durch den Grafikkern 500 aufweisen kann. Bei einer Ausführungsform weist die zusätzliche Festfunktionslogik 516 eine zusätzliche Geometrie-Pipeline für den Einsatz beim Position-only-Schattieren auf. Bei der Position-only-Schattierung liegen zwei Geometrie-Pipelines, die vollständige Geometrie-Pipeline innerhalb der Geometrie-/Festfunktions-Pipeline 516, 536 und eine Cull-Pipeline vor, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Festfunktionslogik 516 umfasst sein. Bei einer Ausführungsform ist die Cull-Pipeline eine reduzierte Version der vollständigen Geometrie-Pipeline. Die vollständige Pipeline und die Cull-Pipeline können unterschiedliche Instanzen derselben Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Die Position-only-Schattierung kann lange Sondierdurchläufe von verworfenen Dreiecken ausblenden und ermöglicht bei einigen Instanzen den früheren Abschluss der Schattierung. Zum Beispiel kann bei einer Ausführungsform die Cull-Pipeline Logik innerhalb der zusätzlichen Festfunktionslogik 516 Position-Shader parallel zur Hauptanwendung ausführen und erzeugt generell kritische Ergebnisse schneller als die vollständige Pipeline, da die Cull-Pipeline nur das Positionsattribut der Scheitel abruft und schattiert, ohne Rastern und Rendern der Pixel zum Rahmenpuffer durchzuführen. Die Cull-Pipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformation für alle Dreiecke ohne Rücksicht darauf zu berechnen, ob die betreffenden Dreiecke ausgesondert werden. Die vollständige Pipeline (die in diesem Fall als eine Wiedergabe-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformation nutzen, um die ausgesonderten Dreiecke zu überspringen, um nur die sichtbaren Dreiecke zu schattieren, die schließlich zur Rasterungsphase weitergeleitet werden.
Bei einer Ausführungsform kann die zusätzliche Festfunktionslogik 516 auch Maschinenlern-Beschleunigungslogik aufweisen, wie Festfunktions-Matrixmultiplikationslogik für Implementierungen, aufweisend Optimierungen für Maschinenlern-Training oder Schlussfolgerungen.
Innerhalb jedes Grafik-Subkerns 501A-501F ist eine Gruppe von Ausführungsressourcen umfasst, die Grafik-, Medien- und Rechenoperationen in Reaktion auf Anforderungen durch die Grafik-Pipeline, Medien-Pipeline oder Shader-Programme einsetzen kann. Die Grafik-Subkerne 501A-501F umfassen mehrere EU-Arrays 502A-502F, 504A-504F, Thread-Verteilung 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 gemeinsam genutzten lokalen Speicher (SLM) 508A-508F. Die EU-Arrays 502A-502F, 504A-504F weisen jeweils mehrere Ausführungseinheiten auf, die allgemeine Grafikverarbeitungseinheiten sind, die Gleitkomma- und Ganzzahl-/Festkomma-Logikoperationen für eine Grafik-, Medien- oder Rechenoperation durchführen können, aufweisend Grafik-, Medien- oder Rechen-Shader-Programme. Die TD/IC-Logik-503A- 503F führt lokale Thread-Verteilung und Thread-Steuerungsoperationen für die Ausführungseinheiten in einem Subkern durch und ermöglicht die Kommunikation zwischen auf den Ausführungseinheiten des Subkerns ausgeführten Threads. Der 3D Sampler 505A-505F kann Daten mit Bezug auf Textur oder andere 3D-Grafik in den Speicher einlesen. Der 3D-Sampler kann Texturdaten, basierend auf einem eingerichteten Abtaststatus und dem mit einer gegebenen Textur assoziierten Texturformat, unterschiedlich einlesen. Der Medien-Sampler 506A-506F kann ähnliche Leseoperationen basierend auf dem mit Mediendaten assoziierten Typ und Format durchführen. Bei einer Ausführungsform kann jeder Grafik-Subkern 501A-501F alternativ dazu einen einheitlichen 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 es Threads, die in einer Thread-Gruppe ausgeführt werden, zu ermöglichen, unter Verwendung eines gemeinsamen Pools von On-Chip-Memory ausgeführt zu werden.
Ausführungseinheiten
6A-6B veranschaulichen eine Thread-Ausführungslogik 600, die ein Array von Verarbeitungselementen aufweist, die in einem Grafikprozessorkern gemäß einigen Ausführungsformen eingesetzt werden. Elemente aus 6A-6B, die die gleichen Bezugsziffern (oder Bezeichnungen) aufweisen wie die Elemente einer beliebigen anderen hier wiedergegebenen Figur, können auf ähnliche Weise wie hier an anderer Stelle beschrieben arbeiten oder wirken, sind jedoch nicht diesbezüglich eingeschränkt. 6A zeigt eine Übersicht über die Thread-Ausführungslogik 600, die eine Variante der Hardwarelogik aufweisen kann, die mit jedem Subkern 501A-501F von 5. 6B zeigt beispielhafte interne Details einer Ausführungseinheit.
Wie in 6A dargestellt, umfasst bei einigen Ausführungsformen die Thread-Ausführungslogik 600 einen Shader-Prozessor 602, einen Thread-Verteiler 604, einen Anweisungs-Cache 606, ein Array skalierbarer Ausführungseinheiten, aufweisend eine Mehrzahl von Ausführungseinheiten 608A-608N; einen Sampler 610, einen Daten-Cache 612 und einen Datenanschluss 614. Bei einer Ausführungsform kann das Array skalierbarer Ausführungseinheiten dynamisch skaliert werden, indem eine oder mehrere Ausführungseinheiten (z. B. eine der Ausführungseinheiten 608A, 608B, 608C, 608D bis 608N-1 und 608N) basierend auf den Rechenanforderungen einer Arbeitslast aktiviert oder deaktiviert werden. Bei einer Ausführungsform sind die umfassten Komponenten über eine Verbindungsstruktur miteinander verbunden, die mit jeder der Komponenten verknüpft ist. Bei einigen Ausführungsformen umfasst die Thread-Ausführungslogik 600 eine oder mehrere Verbindungen zu Speicher, wie zum Beispiel zum Systemspeicher oder zum Cache-Speicher, über eines oder mehrere von dem Anweisungs-Cache 606, dem Datenanschluss 614, dem Sampler 610 und den Ausführungseinheiten 608A-608N. Bei einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 608A) eine programmierbare Stand-Alone-Recheneinheit für allgemeine Zwecke, die in der Lage ist, mehrere gleichzeitige Hardware-Threads auszuführen, während mehrere Datenelemente parallel für jeden Thread verarbeitet werden. Bei verschiedenen Ausführungsformen ist das Array von Ausführungseinheiten 608A-608N skalierbar, um eine beliebige Anzahl einzelner Ausführungseinheiten aufzuweisen.
Bei 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 den Shader-Programmen zugeordnete Ausführungs-Threads über einen Thread-Verteiler 604 verteilen. Bei einer Ausführungsform weist der Thread-Verteiler 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 auf. Beispielsweise kann eine Geometrie-Pipeline Vertex-, Tessellierungs- oder Geometrie-Shader zur Verarbeitung an die Thread-Ausführungslogik senden. Bei einigen Ausführungsformen kann der Thread-Verteiler 604 auch Laufzeit-Thread-Spawning-Anforderungen von den ausführenden Shader-Programmen verarbeiten.
Bei einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N einen Befehlssatz, der native Unterstützung für viele standardmäßige 3D-Grafik-Shader-Anweisungen aufweist, sodass Shader-Programme aus Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit minimaler Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertex-Programme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z. B. Pixel-Shader, Fragment-Shader) und allgemeine Verarbeitung (z. B. Rechen- und Medien-Shader). Jede der Ausführungseinheiten 608A-608N ist in der Lage, mehrfach ausgegebene „Single Instruction Multiple Data“-(SIMD)-Anweisungen auszuführen, und Multi-Thread-Operationen ermöglichen eine effiziente Ausführungsumgebung bei Speicherzugriffen mit höherer Latenz. Jeder HardwareThread in jeder Ausführungseinheit hat eine dedizierte Registerdatei mit hoher Bandbreite und einen zugeordneten unabhängigen Thread-Status. Die Ausführung erfolgt mit mehreren Ausgaben pro Takt zu Pipelines, die zu Gleitkommaoperationen mit ganzzahliger, einfacher und doppelter Genauigkeit, SIMD-Verzweigung, logischen Operationen, transzendentalen Operationen und verschiedenen anderen Operationen fähig sind. Während des Wartens auf Daten aus dem Speicher oder von einer der gemeinsam genutzten Funktionen bewirkt die Abhängigkeitslogik in den Ausführungseinheiten 608A-608N, dass ein wartender Thread in den Ruhezustand versetzt wird, bis die angeforderten Daten zurückgeleitet worden sind. Während der wartende Thread im Ruhezustand ist, werden Hardwareressourcen möglicherweise für die Verarbeitung anderer Threads abgestellt. 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 eine andere Art von Shader-Programm durchführen, die unterschiedlichen Vertex-Shader umfassen.
Jede Ausführungseinheit in den Ausführungseinheiten 608A-608N arbeitet mit Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ oder die Anzahl von Kanälen für den Befehl. Ein Ausführungskanal ist eine logische Ausführungseinheit für den Zugriff auf Datenelemente, die Maskierung und die Flusssteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann unabhängig von der Anzahl von physischen arithmetisch-logischen Einheiten (ALUs) oder Gleitkommaeinheiten (FPUs) für einen bestimmten Grafikprozessor sein. Bei 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 zum Beispiel mit einem 256 Bit breiten Vektor gearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert, und die Ausführungseinheit arbeitet mit dem Vektor in Form von vier separaten gepackten Datenelementen mit 64 Bits (Quad-Word-Größe-(QW)-Datenelemente), acht separaten gepackten 32-Bit-Datenelementen (Datenelemente mit Doppelwortgröße (DW)), sechzehn separaten gepackten 16-Bit-Datenelementen (Datenelemente mit Wortgröße (W)) oder zweiunddreißig separaten 8-Bit-Datenelemente (Bytegröße-(B)-Datenelemente). Unterschiedliche Vektorbreiten und Registergrößen sind jedoch möglich.
Bei einer Ausführungsform können eine oder mehrere Ausführungseinheiten zu einer vereinten Ausführungseinheit 609A-609N mit einer Thread-Steuerlogik (607A-607N) kombiniert werden, die den vereinten EUs gemeinsam ist. Mehrere EUs können zu einer EU-Gruppe vereint werden. Jede EU in der fusionierten EU-Gruppe kann dafür ausgelegt werden, einen separaten SIMD-HardwareThread auszuführen. Die Anzahl der EUs in einer fusionierten EU-Gruppe kann je nach Ausführungsform variieren. Zusätzlich können verschiedene SIMD-Breiten pro EU durchgeführt werden, ohne diesbezügliche Einschränkung umfassend SIMD8, SIMD16 und SIMD32. Jede fusionierte Grafikausführungseinheit 609A-609N weist mindestens zwei Ausführungseinheiten auf. Zum Beispiel weist die fusionierte Ausführungseinheit 609A eine erste EU 608A, eine zweite EU 608B und eine Thread-Steuerlogik 607A auf, die der ersten EU 608A und der zweiten EU 608B gemeinsam sind. Die Thread-Steuerlogik 607A steuert Threads, die auf der fusionierten Grafikausführungseinheit 609A ausgeführt werden, sodass jede EU innerhalb der fusionierten Ausführungseinheiten 609A-609N unter Verwendung eines gemeinsamen Anweisungszeigerregisters ausgeführt werden kann.
Ein oder mehrere interne Befehls-Caches (z. B. 606) sind in der Thread-Ausführungslogik 600 umfasst, um Thread-Anweisungen für die Ausführungseinheiten in Cache zu speichern. Bei einigen Ausführungsformen sind ein oder mehrere Daten-Caches (z. B. 612) umfasst, um Thread-Daten während der Thread-Ausführung in Cache zwischenzuspeichern. Bei einigen Ausführungsformen ist ein Sampler 610 umfasst, um ein Textur-Sampling für 3D-Operationen und ein Medien-Sampling für Medienoperationen bereitzustellen. Bei einigen Ausführungsformen umfasst der Sampler 610 spezialisierte Textur- oder Medien-Sampling-Funktionalität, um Textur- oder Mediendaten während des Sampling-Prozesses zu verarbeiten, bevor die abgetasteten Daten zu einer Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und Medien-Pipelines über die Thread-Spawning- und Verteiler-Logik Thread-Initiierungsanforderungen an die Thread-Ausführungslogik 600. Nachdem eine Gruppe von geometrischen Objekten verarbeitet und in Pixeldaten gerastert worden ist, wird die Pixelprozessorlogik (z. B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) im Shader-Prozessor 602 aufgerufen, um die Ausgabeinformationen weiter zu berechnen und das Schreiben der Ergebnisse zu Ausgabeoberflächen zu veranlassen (z. B. Farbpuffer, Tiefenpuffer, Stencil-Puffer usw.). Bei einigen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertex-Attribute, die über dem gerasterten Objekt interpoliert werden sollen. Bei einigen Ausführungsformen führt die Pixelprozessorlogik innerhalb des Shader-Prozessors 602 anschließend ein von der Anwendungsprogrammierschnittstelle (API) bereitgestelltes Pixel- oder Fragment-Shader-Programm aus. Um das Shader-Programm auszuführen, verteilt der Shader-Prozessor 602 Threads über den Thread-Verteiler 604 zu einer Ausführungseinheit (z. B. 608A). Bei einigen Ausführungsformen verwendet der Shader-Prozessor 602 eine Texturabtastlogik im Sampler 610, um auf Texturdaten in Textur-Maps zuzugreifen, die in Speicher gespeichert sind. Arithmetische Operationen an den Texturdaten und den eingegebenen Geometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel vor der weiteren Verarbeitung.
Bei einigen Ausführungsformen stellt der Datenanschluss 614 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 600 bereit, um verarbeitete Daten zur weiteren Verarbeitung an einer Grafikprozessor-Ausgangspipeline an Speicher auszugeben. Bei einigen Ausführungsformen weist der Datenanschluss 614 einen oder mehrere Cache-Speicher auf (z. B. Daten-Cache 612) oder ist damit gekoppelt, um Daten für den Speicherzugriff über den Datenanschluss in Cache zu speichern.
Wie in 6B dargestellt, kann eine Grafikausführungseinheit 608 eine Anweisungsabrufeinheit 637, ein allgemeines Registerdatei-Array (GRF) 624, ein Architektur-Registerdatei-Array (ARF) 626, einen Thread-Arbiter 622, eine Sendeeinheit 630, eine Verzweigungseinheit 632, eine Gruppe von SIMD-Gleitkommaeinheiten (FPUs) 634 und, bei einer Ausführungsform, eine Gruppe von dedizierten Ganzzahl-SIMD-ALUs 635 aufweisen. Das GRF 624 und das ARF 626 umfassen die Gruppe von allgemeinen Registerdateien und Architekturregisterdateien, die mit jedem simultanen Hardwarethread assoziiert sind, der in der Grafikausführungseinheit 608 aktiv sein kann. Bei einer Ausführungsform wird der Architekturzustand pro Thread in dem ARF 626 beibehalten, während Daten, die während der Thread-Ausführung verwendet werden, in dem GRF 624 gespeichert werden. Der Ausführungsstatus jedes Threads, umfassend die Befehlszeiger für jeden Thread, kann in Thread-spezifischen Registern in dem ARF 626 vorgehalten werden.
Bei 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 hat eine modulare Konfiguration, die zur Entwurfszeit basierend auf einer Zielanzahl von gleichzeitigen Threads und einer Anzahl von Registern pro Ausführungseinheit feinabgestimmt werden kann, wobei die Ressourcen der Ausführungseinheit über der Logik aufgeteilt sind, die zum Ausführen mehrerer gleichzeitiger Threads verwendet wird.
Bei einer Ausführungsform kann die Grafikausführungseinheit 608 mehrere Anweisungen gemeinsam ausgeben, die jeweils unterschiedliche Anweisungen sein können. Der Thread-Arbiter 622 des Threads 608 der Grafikausführungseinheit kann die Anweisungen zur Ausführung an eine von der Sendeeinheit 630, der Verzweigungseinheit 642 oder den SIMD-FPUs 634 verteilen. Jeder Ausführungsthread kann auf 128 Register für allgemeine Zwecke in dem GRF 624 zugreifen, wobei jedes Register 32 Bytes speichern kann, auf die als SIMD-8-Element-Vektor von 32-Bit-Datenelementen zugegriffen werden kann. Bei einer Ausführungsform hat jeder Thread einer Ausführungseinheit Zugriff auf 4 KByte innerhalb des GRF 624, obwohl Ausführungsformen nicht diesbezüglich eingeschränkt sind und bei anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt werden können. Bei einer Ausführungsform können bis zu sieben Threads gleichzeitig ausgeführt werden, obwohl die Anzahl von Threads pro Ausführungseinheit gemäß Ausführungsformen auch variieren kann. Bei einer Ausführungsform, in der sieben Threads auf 4 KB zugreifen können, kann das GRF 624 insgesamt 28 KB speichern. Flexible Adressierungsmodi können ermöglichen, dass Register zusammen adressiert werden, um effektiv breitere Register aufzubauen oder gespreizte Quader-Datenstrukturen darzustellen.
Bei einer Ausführungsform werden Speicheroperationen, Sampler-Operationen und andere Systemkommunikationen mit längerer Latenz über „Sende“ - Anweisungen verteilt, die von der Nachrichtenübergabe-Sendeeinheit 630 ausgeführt werden. Bei einer Ausführungsform werden Verzweigungsbefehle an eine dedizierte Verzweigungseinheit 632 verteilt, um die SIMD-Divergenz und folgende Konvergenz zu ermöglichen.
Bei einer Ausführungsform weist die Grafikausführungseinheit 608 eine oder mehrere SIMD-Gleitkommaeinheiten (FPUs) 634 auf, um Gleitkommaoperationen auszuführen. Bei einer Ausführungsform unterstützen die FPUs 634 auch Ganzzahlberechnung. Bei einer Ausführungsform können die FPUs 634 SIMD bis zu Anzahl M von 32-Bit-Gleitkommaoperationen (oder Ganzzahloperationen) ausführen, oder SIMD können bis zu 2 M 16-Bit-Ganzzahloperationen oder 16-Bit-Gleitkommaoperationen ausführen. Bei einer Ausführungsform stellt mindestens eine der FPUs erweiterte mathematische Fähigkeiten bereit, um transzendentale mathematische Funktionen mit hohem Durchsatz und 64-Bit-Gleitkomma mit doppelter Genauigkeit zu unterstützen. Bei einigen Ausführungsformen liegt auch eine Gruppe von 8-Bit-Ganzzahl-SIMD-ALUs 635 vor, die im Einzelnen optimiert werden können, um Operationen durchzuführen, die mit Berechnungen des maschinellen Lernens assoziiert sind.
Bei einer Ausführungsform können Arrays von mehreren Instanzen der Grafikausführungseinheit 608 in einer Grafik-Subkerngruppierung (z. B. einer Sub-Slice) instanziiert werden. Zur Skalierbarkeit können Produktarchitekten die genaue Anzahl von Ausführungseinheiten pro Subkerngruppierung auswählen. Bei einer Ausführungsform kann die Ausführungseinheit 608 Anweisungen über einer Mehrzahl von Ausführungskanälen ausführen. Bei einer weiteren Ausführungsform wird jeder Thread, der auf der Grafikausführungseinheit 608 ausgeführt wird, auf einem unterschiedlichen Kanal ausgeführt.
7 ist ein Blockdiagramm, das Grafikprozessoranweisungsformate 700 gemäß einigen Ausführungsformen darstellt. Bei einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Befehlssatz, der Anweisungen in mehreren Formaten aufweist. Die Kästchen mit durchgezogenen Linien veranschaulichen die Komponenten, die generell in einer Anweisung der Ausführungseinheit umfasst sind, während die gestrichelten Linien Komponenten umfassen, die optional sind oder nur in einer Untergruppe der Anweisungen umfasst sind. Bei einigen Ausführungsformen weist das beschriebene und dargestellte Anweisungsformat 700 Makroanweisungen auf, da es zu der Ausführungseinheit geleitete Anweisungen sind, im Gegensatz zu Mikrooperationen, die sich aus der Anweisungsdecodierung ergeben, nachdem die Anweisung verarbeitet worden ist.
Bei einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten Anweisungen in einem 128-Bit-Anweisungsformat 710 nativ. Ein kompaktiertes 64-Bit-Befehlsformat 730 ist für einige Anweisungen verfügbar, basierend auf der ausgewählten Anweisung, den Anweisungsoptionen und der Anzahl von Operanden. Das native 128-Bit-Anweisungsformat 710 ermöglicht den Zugriff auf alle Anweisungsoptionen, während einige Optionen und Operationen im 64-Bit-Format 730 eingeschränkt sind. Die im 64-Bit-Format 730 verfügbaren nativen Anweisungen variieren je nach Ausführungsform. Bei einigen Ausführungsformen wird die Anweisung teilweise unter Verwendung einer Gruppe von Indexwerten in einem Indexfeld 713 kompaktiert. Die Hardware der Ausführungseinheit verweist auf eine Gruppe von Kompaktierungstabellen basierend auf den Indexwerten und verwendet die Ausgaben der Kompaktierungstabellen, um eine native Anweisung im 128-Bit-Anweisungsformat 710 zu rekonstruieren.
Für jedes Format definiert der Befehls-Opcode 712 die Operation, die die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden aus. Beispielsweise führt die Ausführungseinheit in Reaktion auf eine Additionsanweisung eine gleichzeitige Additionsoperation über jeden Farbkanal durch, der ein Texturelement oder Bildelement darstellt. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden aus. Bei einigen Ausführungsformen ermöglicht das Befehlssteuerfeld 714 die Steuerung über bestimmte Ausführungsoptionen, wie beispielsweise die Kanalauswahl (z. B. Prädikation) und die Datenkanalreihenfolge (z. B. Swizzle). Für Befehle im 128-Bit-Anweisungsformat 710 begrenzt ein Feld 716 in Ausführungsgröße die Anzahl der Datenkanäle, die parallel ausgeführt werden. Bei einigen Ausführungsformen ist das Feld 716 in Ursprungsgröße nicht zur Verwendung in dem kompakten 64-Bit-Anweisungsformat 730 verfügbar.
Einige Anweisungen der Ausführungseinheit weisen bis zu drei Operanden auf, umfassend zwei Quelloperanden, src0 720, srcl 722, und ein Ziel 718. Bei 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 Anweisungs-Opcode 712 die Anzahl von Quelloperanden bestimmt. Der letzte Quelloperand einer Anweisung kann ein unmittelbarer (z. B. fest codierter) Wert sein, der mit der Anweisung weitergegeben wird.
Bei einigen Ausführungsformen weist das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726 auf, das zum Beispiel angibt, ob ein direkter Register-Adressierungsmodus oder ein indirekter Register-Adressierungsmodus verwendet wird. Bei Verwendung des direkten Register-Adressierungsmodus wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
Bei einigen Ausführungsformen umfasst das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung spezifiziert. Bei einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Einige Ausführungsformen unterstützen Zugriffsmodi, aufweisend einen auf 16 Byte ausgerichteten Zugriffsmodus und einen auf 1 Byte ausgerichteten Zugriffsmodus, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Beispielsweise kann die Anweisung in einem ersten Modus Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und in einem zweiten Modus kann die Anweisung auf 16 Byte ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
Bei einer Ausführungsform bestimmt der Adressmodus-Teil des Zugriffs-/Adressmodusfelds 726, ob die Anweisung direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, stellen die 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-Direktfeld in der Anweisung berechnet werden.
Bei 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 das Bestimmen des Typs des Opcodes. Die angezeigte genaue Opcode-Gruppierung ist nur ein Beispiel. Bei einigen Ausführungsformen enthält eine Bewegungs- und Logik-Opcode-Gruppe 742 Datenbewegungs- und Logikanweisungen (z. B. bewegen (mov), vergleichen (cmp)). Bei einigen Ausführungsformen teilt die Bewegungs- und Logikgruppe 742 die fünf höchstwertigen Bits (MSB), wobei Bewegungs-(mov)-Anweisungen in Form von 0000xxxxb und Logikanweisungen in Form von 0001xxxxb vorliegen. Eine Flusssteuerungsanweisungsgruppe 744 (z. B. Aufruf, Sprung (jmp)) weist Anweisungen in Form von 0010xxxxb auf (z. B. 0x20). Eine gemischte Anweisungsgruppe 746 weist eine Mischung von Anweisungen auf, umfassend Synchronisierungsanweisungen (z. B. Warten, Senden) in Form von 0011xxxxb (z. B. 0x30). Eine parallele mathematische Anweisungsgruppe 748 weist komponentenweise arithmetische Anweisungen auf (z. B. Addieren, Multiplizieren (mul)) in Form von 0100xxxxb (z. B. 0x40). Die parallele mathematische Gruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle aus. Die Vektormathematikgruppe 750 weist arithmetische Anweisungen (z. B. dp4) in Form von 0101xxxxb (z. B. 0x50) auf. Die Vektormathematikgruppe führt Arithmetik wie Punktproduktberechnungen für Vektoroperanden durch.
Grafik-Pipeline
8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors 800. Elemente von 8, die die gleichen Bezugszeichen (oder Bezeichnungen) aufweisen wie die Elemente einer beliebigen anderen hier wiedergegebenen Figur, können auf ähnliche Weise wie hier an anderer Stelle beschrieben arbeiten oder wirken, sind jedoch nicht diesbezüglich eingeschränkt.
Bei einigen Ausführungsformen umfasst 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. Bei einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor in einem Mehrkernverarbeitungssystem, das einen oder mehrere Verarbeitungskerne für allgemeine Zwecke aufweist. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle gesteuert, die über eine Ringverbindung 802 zu dem Grafikprozessor 800 ausgegeben werden. In einigen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 mit anderen Verarbeitungskomponenten, wie z. B. anderen Grafikprozessoren oder Prozessoren für allgemeine Zwecke. Befehle von der Ringverbindung 802 werden von einem Befehls-Streamer 803 interpretiert, der Anweisungen zu einzelnen Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 bereitstellt.
Bei einigen Ausführungsformen lenkt der Befehls-Streamer 803 den Betrieb eines Vertex-Abrufers 805, der Vertex-Daten aus Speicher ausliest und Vertex-Verarbeitungsbefehle ausführt, die vom Befehls-Streamer 803 bereitgestellt werden. Bei einigen Ausführungsformen stellt der Vertex-Abrufer 805 Vertex Daten zu einem Vertex-Shader 807 bereit, der für jeden Scheitel Koordinatenraumtransformations- und Beleuchtungsoperationen durchführt. Bei einigen Ausführungsformen führen der Vertex-Abrufer 805 und der Vertex-Shader 807 Vertex-Verarbeitungsanweisungen durch Verteilen von Ausführungsthreads an die Ausführungseinheiten 852A-852B über einen Thread-Verteiler 831 aus.
Bei einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B ein Array von Vektorprozessoren, aufweisend eine Anweisungsgruppe zum Durchführen von Grafik- und Medienoperationen. Bei einigen Ausführungsformen weisen die Ausführungseinheiten 852A-852B einen dazugehörigen LI-Cache 851 auf, der für jedes Array spezifisch ist oder von den Arrays gemeinsam genutzt wird. Der Cache kann als Daten-Cache, Anweisung-Cache oder einzelner Cache eingerichtet werden, der partitioniert ist, um Daten und Anweisungen in unterschiedlichen Partitionen zu enthalten.
In einigen Ausführungsformen umfasst die Geometrie-Pipeline 820 Tessellierungskomponenten, um eine hardwarebeschleunigte Tessellierung von 3D-Objekten durchzuführen. Bei einigen Ausführungsformen richtet ein programmierbarer Hull-Shader 811 die Tessellierungsoperationen ein. Ein programmierbarer Domänen-Shader 817 stellt eine Backend-Bewertung der Tessellierungsausgabe bereit. Ein Tessellator 813 arbeitet in der Richtung des Hull-Shaders 811 und enthält spezielle Logik zum Erzeugen einer Gruppe detaillierter geometrischer Objekte auf der Grundlage eines groben geometrischen Modells, das als Eingabe zu der Geometrie-Pipeline 820 bereitgestellt wird. Bei einigen Ausführungsformen können, wenn keine Tessellierung verwendet wird, Tessellierungskomponenten (z. B. Hull-Shader 811, Tessellator 813 und Domänen-Shader 817) übergangen werden.
Bei 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 verteilt werden, oder sie können direkt zum Clipper 829 weitergeleitet werden. Bei einigen Ausführungsformen arbeitet der Geometrie-Shader an ganzen geometrischen Objekten anstelle von Vertices oder Patches von Vertices wie in vorherigen Stufen der Grafik-Pipeline. Wenn die Tessellierung deaktiviert ist, empfängt der Geometrie-Shader 819 eine Eingabe von dem Vertex-Shader 807. Bei einigen Ausführungsformen ist der Geometrie-Shader 819 durch ein Geometrie-Shader-Programm programmierbar, um eine Geometrie-Tessellierung durchzuführen, wenn die Tessellierungseinheiten deaktiviert sind.
Vor der Rasterung verarbeitet ein Clipper 829 Vertex-Daten. Der Clipper 829 kann ein Clipper mit fester Funktion oder ein programmierbarer Clipper sein, der Clipping- und Geometrie-Shader-Funktionen aufweist. Bei einigen Ausführungsformen verteilt eine Rasterizer- und Tiefentestkomponente 873 in der Render-Ausgabepipeline 870 Pixel-Shader aus, um die geometrischen Objekte in Darstellungen pro Pixel umzuwandeln. Bei einigen Ausführungsformen ist die Pixel-Shader-Logik in Thread-Ausführungslogik 850 umfasst. Bei einigen Ausführungsformen kann eine Anwendung den Rasterizer und die Tiefentestkomponente 873 übergehen und über eine Stream-Out-Einheit 823 auf nicht gerasterte Vertex-Daten zugreifen.
Der Grafikprozessor 800 weist einen Verbindungsbus, eine Verbindungsstruktur oder einen anderen Verbindungsmechanismus auf, der das Weiterleiten von Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors ermöglicht. Bei einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B und zugeordnete Logikeinheiten (z. B. der LI-Cache 851, der Sampler 854, der Textur-Cache 858 usw.) über einen Datenanschluss 856 verbunden, um Speicherzugriff durchzuführen und mit den Render-Ausgangspipelinekomponenten des Prozessors zu kommunizieren. Bei einigen Ausführungsformen weisen der Sampler 854, die Caches 851, 858 und die Ausführungseinheiten 852A-852B jeweils separate Speicherzugriffspfade auf. Bei einer Ausführungsform kann der Textur-Cache 858 auch als Sampler-Cache eingerichtet sein.
Bei einigen Ausführungsformen enthält die Render-Ausgabepipeline 870 eine Rasterizer- und Tiefentestkomponente 873, die Vertex-basierte Objekte in eine zugeordnete pixelbasierte Darstellung umwandelt. Bei einigen Ausführungsformen umfasst die Rasterizer-Logik eine Windower/Masker-Einheit, um Dreiecks- und Zeilenrasterung mit fester Funktion durchzuführen. Bei einigen Ausführungsformen sind auch ein zugeordneter Render-Cache 878 und Tiefen-Cache 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 Vermischung, werden von der 2D-Engine 841 durchgeführt oder zur Anzeigezeit von der Anzeigesteuerung 843 unter Verwendung von Überlagerungsanzeigeebenen ersetzt. Bei einigen Ausführungsformen steht allen Grafikkomponenten ein gemeinsam genutzter L3-Cache 875 zur Verfügung, der die gemeinsame Nutzung von Daten ohne Verwendung von Hauptsystemspeicher ermöglicht.
Bei einigen Ausführungsformen umfasst die Grafikprozessor-Medien-Pipeline 830 eine Medien-Engine 837 und ein Video-Frontend 834. Bei einigen Ausführungsformen empfängt das Video-Frontend 834 Pipeline-Befehle vom Befehls-Streamer 803. Bei einigen Ausführungsformen weist die Medien-Pipeline 830 einen separaten Befehls-Streamer auf. Bei einigen Ausführungsformen verarbeitet das Video-Frontend 834 Medienbefehle, bevor der Befehl zu der Medien-Engine 837 gesendet wird. Bei einigen Ausführungsformen umfasst die Medien-Engine 837 Thread-Spawning-Funktionalität zum Erzeugen von Threads zum Verteilen an die Thread-Ausführungslogik 850 über den Thread-Verteiler 831.
Bei einigen Ausführungsformen weist der Grafikprozessor 800 eine Anzeige-Engine 840 auf. Bei einigen Ausführungsformen ist die Anzeige-Engine 840 außerhalb des Prozessors 800 und über die Ringverbindung 802 oder einen anderen Verbindungsbus oder eine Struktur mit dem Grafikprozessor gekoppelt. Bei einigen Ausführungsformen umfasst die Anzeige-Engine 840 eine 2D-Engine 841 und eine Anzeigesteuerung 843. Bei einigen Ausführungsformen enthält die Anzeige-Engine 840 eine spezielle Logik, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. Bei einigen Ausführungsformen ist die Anzeigesteuerung 843 mit einer Anzeigeeinrichtung (nicht gezeigt) gekoppelt, die eine systemintegrierte Anzeigeeinrichtung wie in einem Laptop-Computer oder eine externe Anzeigeeinrichtung sein kann, die über einen Anzeigeeinrichtungsverbinder angeschlossen ist.
Bei einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 einrichtbar, um Operationen basierend auf mehreren Grafik- und Medienprogrammierschnittstellen durchzuführen, und sie sind nicht spezifisch für eine beliebige Anwendungsprogrammierschnittstelle (API). Bei 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. Bei einigen Ausführungsformen wird Unterstützung für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan-Grafik- und Rechen-API bereitgestellt, die alle von der Khronos Group stammen. Bei einigen Ausführungsformen kann Support möglicherweise auch für die Direct3D-Bibliothek von der Microsoft Corporation bereitgestellt werden. Bei einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Möglicherweise kann Support auch für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine künftige API mit einer kompatiblen 3D-Pipeline würde ebenfalls unterstützt, wenn eine Abbildung von der Pipeline der zukünftigen API zur Pipeline des Grafikprozessors erfolgen kann.
Grafik-Pipeline-Programmierung
9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat 900 gemäß einigen Ausführungsformen darstellt. 9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 910 gemäß einer Ausführungsform darstellt. Die Kästchen mit durchgezogenen Linien in 9A zeigen die Komponenten, die im Allgemeinen in einem Grafikbefehl umfasst sind, während die gestrichelten Linien Komponenten umfassen, die optional sind oder die nur in einer Teilmenge der Grafikbefehle umfasst sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 von 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 ebenfalls in einigen Befehlen umfasst.
Bei einigen Ausführungsformen spezifiziert der Client 902 die Client-Einheit der Grafikeinrichtung, die die Befehlsdaten verarbeitet. Bei einigen Ausführungsformen untersucht ein Grafikprozessor-Befehlsparser das Client-Feld jedes Befehls, um die weitere Verarbeitung des Befehls festzulegen und die Befehlsdaten an die entsprechende Client-Einheit weiterzuleiten. Bei einigen Ausführungsformen umfassen die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Client-Einheit weist eine entsprechende Verarbeitungs-Pipeline auf, die die Befehle verarbeitet. Sobald der Befehl von der Client-Einheit empfangen worden ist, liest die Client-Einheit den Opcode 904 ein und, falls vorhanden, den Sub-Opcode 905, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Information im Datenfeld 906 aus. Für einige Befehle wird eine explizite Befehlsgröße 908 erwartet, um die Größe des Befehls anzugeben. Bei einigen Ausführungsformen ermittelt der Befehlsparser automatisch die Größe von mindestens einigen der Befehle basierend auf dem Befehls-Opcode. Bei einigen Ausführungsformen werden Befehle über Vielfache eines Doppelworts ausgerichtet.
Das Ablaufdiagramm in 9B zeigt eine beispielhafte Grafikprozessorbefehlssequenz 910. Bei einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors aufweist, eine Version der gezeigten Befehlssequenz, um eine Gruppe von Grafikoperationen einzurichten, auszuführen und zu beenden. Eine beispielhafte Befehlssequenz wird nur zu Beispielzwecken gezeigt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlssequenz eingeschränkt sind. Darüber hinaus können die Befehle als Stapel von Befehlen in einer Befehlssequenz ausgegeben werden, sodass der Grafikprozessor die Befehlssequenz zumindest teilweise gleichzeitig verarbeitet.
Bei einigen Ausführungsformen kann die
Grafikprozessorbefehlssequenz 910 mit einem Pipeline-Flush-Befehl 912 beginnen, um zu veranlassen, dass eventuell aktive Grafikpipelines die aktuell anstehenden Befehle für die Pipeline vervollständigen. Bei einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Das Entleeren der Pipeline wird durchgeführt, um die aktive Grafik-Pipeline zu veranlassen, alle anstehenden Befehle abzuschließen. In Reaktion auf eine Pipeline-Entleerung hält der Befehlsparser für den Grafikprozessor die Befehlsverarbeitung an, bis die aktiven Zeichen-Engines anstehende Vorgänge abschließen und die relevanten Lese-Caches hinfällig sind. Optional können alle Daten im Render-Cache, die als „Dirty“ markiert sind, in Speicher ausgelagert werden. Bei einigen Ausführungsformen kann der Pipeline-Flush-Befehl 912 zur Pipeline-Synchronisation oder vor dem Versetzen des Grafikprozessors in einen Zustand mit niedrigem Stromverbrauch verwendet werden.
Bei einigen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. Bei einigen Ausführungsformen ist ein Pipeline-Auswahlbefehl 913 in einem Ausführungskontext nur einmal erforderlich, bevor Pipeline-Befehle ausgegeben werden, sofern der Kontext keine Befehle für beide Pipelines ausgeben soll. Bei einigen Ausführungsformen ist ein Pipeline-Flush-Befehl 912 unmittelbar vor einem Pipeline-Wechsel über den Pipeline-Auswahlbefehl 913 erforderlich.
Bei einigen Ausführungsformen richtet ein Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für den Betrieb ein, und er wird verwendet, um die 3D-Pipeline 922 und die Medien-Pipeline 924 zu programmieren. Bei einigen Ausführungsformen richtet der Pipeline-Steuerbefehl 914 den Pipeline-Zustand für die aktive Pipeline ein. Bei einer Ausführungsform wird der Pipeline-Steuerbefehl 914 zur Pipeline-Synchronisation und zum Löschen von Daten aus einem oder mehreren Cache-Speichern in der aktiven Pipeline verwendet, bevor ein Stapel von Befehlen verarbeitet wird.
Bei einigen Ausführungsformen werden Rückleitungspuffer-Statusbefehle 916 verwendet, um eine Gruppe von Rückleitungspuffern für die jeweiligen Pipelines zum Schreiben von Daten einzurichten. Einige Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration eines oder mehrerer Rückleitungspuffer, in die die Operationen während der Verarbeitung Zwischendaten schreiben. Bei einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückleitungspuffer, um Ausgabedaten zu speichern und Threadübergreifende Kommunikation durchzuführen. Bei einigen Ausführungsformen umfasst der Rückleitungspuffer-Zustand 916 das Auswählen der Größe und Anzahl von Rückleitungspuffern zur Verwendung für eine Gruppe von Pipelineoperationen.
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 zugeschnitten, beginnend mit dem 3D-Pipeline-Zustand 930, oder auf die Medien-Pipeline 924, beginnend mit dem Medien-Pipeline-Zustand 940.
Die Befehle zum Einrichten des 3D-Pipeline-Zustands 930 umfassen 3D-Zustandseinstellbefehle für den Vertex-Pufferzustand, den Vertex-Elementzustand, den konstanten Farbzustand, den Tiefen-Pufferzustand und andere Zustandsvariablen, die eingerichtet werden müssen, bevor 3D-Primitivbefehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise basierend auf der besonderen verwendeten 3D-API festgelegt. Bei einigen Ausführungsformen können 3D-Pipeline-Statusbefehle 930 auch bestimmte Pipeline-Elemente selektiv deaktivieren oder übergehen, wenn diese Elemente nicht verwendet werden.
Bei einigen Ausführungsformen wird der 3D-Primitivbefehl 932 verwendet, um 3D-Primitive zu übermitteln, die von der 3D-Pipeline verarbeitet werden sollen. Befehle und assoziierte Parameter, über den 3D-Primitiv-Befehl 932 zu dem Grafikprozessor übermittelt, werden an die Vertex-Abruf-Funktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruf-Funktion verwendet die 3D-Primitiv-Befehlsdaten 932, um Vertex-Datenstrukturen zu erzeugen. Die Vertex-Datenstrukturen werden in einem oder mehreren Rückleitungspuffern gespeichert. Bei einigen Ausführungsformen wird der 3D-Primitivbefehl 932 verwendet, um Vertex-Operationen an 3D-Primitiven über Vertex-Shader durchzuführen. Zum Verarbeiten von Vertex-Shadern verteilt die 3D-Pipeline 922 Shader-Ausführungs-Threads an Grafikprozessor-Ausführungseinheiten.
Bei einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Ausführungsbefehl 934 oder ein Ereignis ausgelöst. Bei einigen Ausführungsformen löst ein Register-Schreibvorgang eine Befehlsausführung aus. Bei einigen Ausführungsformen wird die Ausführung über einen „Go“- oder „Kick“-Befehl in der Befehlssequenz ausgelöst. Bei einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipeline-Synchronisationsbefehls ausgelöst, um die Befehlssequenz durch die Grafik-Pipeline zu entleeren. Die 3D-Pipeline führt die 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 sich ergebenden Pixel. Für diese Operationen können auch zusätzliche Befehle zum Steuern der Pixelschattierung und der Pixel-Backend-Operationen umfasst sein.
Bei einigen Ausführungsformen folgt die Grafikprozessorbefehlssequenz 910 dem Pfad der Medien-Pipeline 924, wenn Medienoperationen ausgeführt werden. Im Allgemeinen hängt die spezifische Verwendung und Art der Programmierung für die Medien-Pipeline 924 von den durchzuführenden Medien- oder Rechenoperationen ab. Spezifische Mediendecodierungsoperationen können während der Mediendecodierung in die Medien-Pipeline ausgelagert werden. Bei einigen Ausführungsformen kann die Medien-Pipeline auch übergangen werden, und die Mediendecodierung kann ganz oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Verarbeitungskernen für allgemeine Zwecke bereitgestellt werden. Bei einer Ausführungsform weist die Medien-Pipeline auch Elemente für Operationen der Grafikprozessoreinheit für allgemeine Zwecke (GPGPU) auf, wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Rechen-Shader-Programmen durchzuführen, die nicht explizit mit dem Rendern von Grafikprimitiven zusammenhängen.
Bei einigen Ausführungsformen ist die Medien-Pipeline 924 auf ähnliche Weise eingerichtet wie die 3D-Pipeline 922. Eine Gruppe von Befehlen zum Einrichten des Medien-Pipeline-Zustands 940 wird vor den Medienobjektbefehlen 942 verteilt oder in eine Befehlswarteschlange gestellt. Bei einigen Ausführungsformen weisen Befehle für den Medien-Pipeline-Zustand 940 Daten zum Einrichten der Medien-Pipeline-Elemente auf, die zum Verarbeiten der Medienobjekte verwendet werden. Dies umfasst Daten zum Einrichten der Videodecodierungs- und Videocodierungslogik in der Medien-Pipeline, z. B. das Codierungs- oder Decodierungsformat. Bei 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 Stapel von Zustandseinstellungen enthalten.
Bei einigen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger an Medienobjekte zur Verarbeitung durch die Medien-Pipeline. Die Medienobjekte weisen Speicherpuffer auf, die zu verarbeitende Videodaten enthalten. Bei einigen Ausführungsformen müssen alle Medien-Pipeline-Zustände gültig sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Sobald der Pipeline-Zustand eingerichtet ist und Medienobjektbefehle 942 in die Warteschlange eingestellt 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 anschließend durch Operationen nachbearbeitet werden, die von der 3D-Pipeline 922 oder der Medien-Pipeline 924 bereitgestellt werden. Bei einigen Ausführungsformen werden GPGPU-Operationen auf ähnliche Weise wie Medienoperationen eingerichtet und ausgeführt.
Grafik-Software-Architektur
10 stellt eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß einigen Ausführungsformen dar. Bei einigen Ausführungsformen umfasst die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. Bei einigen Ausführungsformen umfasst der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Prozessorkerne 1034 für allgemeine Zwecke. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
Bei einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programme, die Shader-Anweisungen 1012 aufweisen. Die Shader-Sprachanweisungen können in einer Shader-Sprache höherer Ebene vorliegen, z. B. der Shader-Sprache höherer Ebene (HLSL) oder der OpenGL-Shader-Sprache (GLSL). Die Anwendung weist auch ausführbare Anweisungen 1014 in einer Maschinensprache auf, die zur Ausführung durch den Prozessorkern 1034 für allgemeine Zwecke geeignet ist. Die Anwendung weist auch Grafikobjekte 1016 auf, die durch Vertex Daten definiert sind.
Bei 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 die Direct3D-API, die OpenGL-API oder die Vulkan-API unterstützen. Wenn die Direct3D-API eingesetzt wird, verwendet das Betriebssystem 1020 einen Frontend-Shader-Compiler 1024, um Shader-Anweisungen 1012 in HLSL in eine Shader-Sprache niedriger Ebene zu kompilieren. Die Kompilierung kann eine Justin-time-Kompilierung (JIT) sein oder die Anwendung kann eine Shader-Vorkompilierung durchführen. Bei einigen Ausführungsformen werden Shader höherer Ebene während der Kompilierung der 3D-Grafikanwendung 1010 in Shader niedriger Ebene kompiliert. Bei einigen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform bereitgestellt, wie beispielsweise einer Version der von der Vulkan-API verwendeten Standard Portable Intermediate Representation (SPIR).
Bei einigen Ausführungsformen enthält der Benutzermodus-Grafiktreiber 1026 einen Backend-Shader-Compiler 1027, um die Shader-Anweisungen 1012 in eine hardwarespezifische Darstellung umzuwandeln. Wenn die OpenGL-API verwendet wird, werden die Shader-Anweisungen 1012 in der GLSL-Sprache höherer Ebene zur Kompilierung zu einem Benutzermodus-Grafiktreiber 1026 weitergeleitet. Bei einigen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystem-Kernelmodusfunktionen 1028, um mit einem Kernelmodus-Grafiktreiber 1029 zu kommunizieren. Bei einigen Ausführungsformen kommuniziert der Kernelmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen zu verteilen.
IP-Core-Implementierungen
Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik in einer integrierten Schaltung wie einem Prozessor darstellt und/oder definiert. Beispielsweise kann das maschinenlesbare Medium Anweisungen aufweisen, die verschiedene Logik innerhalb des Prozessors wiedergeben. Beim Lesen durch eine Maschine können die Anweisungen die Maschine veranlassen, die Logik zum Durchführen der hier beschriebenen Techniken zu erstellen. Solche als „IP-Cores“ bezeichneten Darstellungen sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die als Hardwaremodell, das die Struktur der integrierten Schaltung beschreibt, auf einem materiellen, maschinenlesbaren Medium gespeichert sein können. Das Hardwaremodell kann an verschiedene Kunden oder Fertigungsstätten geliefert werden, die das Hardwaremodell auf Fertigungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann so hergestellt sein, dass die Schaltung Operationen durchführt, die in Verbindung mit einer der hier beschriebenen Ausführungsformen beschrieben sind.
11A ist ein Blockdiagramm, das ein IP-Core-Entwicklungssystem 1100 darstellt, das eingesetzt werden kann, um eine integrierte Schaltung zur Durchführung von Operationen gemäß einer Ausführungsform herzustellen. Das IP-Core-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs zu erzeugen, 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-Core-Designs in einer Programmiersprache höherer Ebene (z. B. C/C ++) erzeugen. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Cores unter Verwendung eines Simulationsmodells 1112 zu entwerfen, zu testen und zu prüfen. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Zeitsimulationen aufweisen. Ein Registertransferebenen-(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, aufweisend die zugehörige Logik, die unter Verwendung der modellierten digitalen Signale ausgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Entwürfe niedriger Ebenen auf der Logikebene oder Transistorebene erzeugt, entworfen oder synthetisiert werden. Daher können die besonderen Details des anfänglichen Entwurfs und der Simulation variieren.
Das RTL-Design 1115 oder ein Äquivalent können ferner von der Designeinrichtung zu einem Hardwaremodell 1120 synthetisiert werden, das in einer Hardwarebeschreibungssprache (HDL) oder einer anderen Darstellung physikalischer Designdaten vorliegen kann. Die HDL kann ferner simuliert oder getestet werden, um das IP-Core-Design zu überprüfen. Das IP-Core-Design kann zur Lieferung an eine Herstellungseinrichtung 1165 von Dritten unter Verwendung von nichtflüchtigem Speicher 1140 gespeichert werden (z. B. Festplatte, Flash-Speicher oder ein beliebiges nichtflüchtiges Speichermedium). Alternativ dazu kann das IP-Core-Design über eine drahtgebundene Verbindung 1150 oder eine drahtlose Verbindung 1160 übertragen werden (z. B. über das Internet). Die Herstellungseinrichtung 1165 kann anschließend eine integrierte Schaltung herstellen, die zumindest teilweise auf dem IP-Core-Design basiert. Die hergestellte integrierte Schaltung kann dafür ausgelegt sein, Operationen gemäß mindestens einer hier beschriebenen Ausführungsform durchzuführen.
11B stellt eine Querschnittsseitenansicht einer Paketanordnung 1170 einer integrierten Schaltung gemäß einigen hier beschriebenen Ausführungsformen dar. Die Paketanordnung 1170 der integrierten Schaltung veranschaulicht eine Implementierung von einer oder mehreren hier beschriebenen Prozessor- oder Beschleunigereinrichtungen. Die Paketanordnung 1170 enthält mehrere Einheiten von Hardwarelogik 1172, 1174, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann zumindest teilweise in einrichtbarer Logik oder Logikhardware mit fester Funktionalität implementiert sein, und sie kann einen oder mehrere Teile von beliebigen der hier beschriebenen Prozessorkerne, Grafikprozessoren oder anderen Beschleunigereinrichtungen aufweisen. Jede Logikeinheit 1172, 1174 kann in einem Halbleiter-Die implementiert und über eine Verbindungsstruktur 1173 mit dem Substrat 1180 gekoppelt sein. Die Verbindungsstruktur 1173 kann dafür ausgelegt sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten, und sie kann Verbindungen aufweisen, wie z. B., ohne diesbezügliche Einschränkung, Beulen oder Säulen. Bei einigen Ausführungsformen kann die Verbindungsstruktur 1173 dafür ausgelegt sein, elektrische Signale wie zum Beispiel Eingabe-/Ausgabe-(E/A)-Signale und/oder Leistungs- oder Erdungssignale weiterzuleiten, die mit dem Betrieb der Logik 1172, 1174 assoziiert sind. Bei einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidbasis. Die Paketanordnung 1170 kann bei anderen Ausführungsformen andere geeignete Typen von Substraten aufweisen. Die Paketanordnung 1170 kann über eine Paketverbindung 1183 mit anderen elektrischen Einrichtungen verbunden sein. Die Paketverbindung 1183 kann mit einer Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Einrichtungen zu leiten, wie z. B. zu einer Hauptplatine, einem anderen Chipsatz oder einem Multi-Chip-Modul.
Bei einigen Ausführungsformen sind die Einheiten der Logik 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die dafür ausgelegt ist, elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Brücke 1182 kann eine dichte Verbindungsstruktur sein, die eine Strecke 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 Leitwegmerkmale ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Obwohl zwei Logikeinheiten 1172, 1174 und eine Brücke 1182 dargestellt sind, können die hier beschriebenen Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies aufweisen. Der eine oder die mehreren Dies können durch null oder mehr Brücken verbunden sein, da die Brücke 1182 ausgeschlossen sein kann, wenn die Logik auf einem einzelnen Die umfasst 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, umfassend dreidimensionale Konfigurationen, miteinander verbunden sein.
Beispielhaftes System auf einer integrierten Chipschaltung
12-14 veranschaulichen beispielhafte integrierte Schaltungen und zugeordnete Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Cores gemäß verschiedenen hier beschriebenen Ausführungsformen hergestellt werden können. Zusätzlich zu der Darstellung können andere Logik und Schaltungen umfasst sein, aufweisend zusätzliche Grafikprozessoren/-kerne, periphere Schnittstellencontroller oder Prozessorkerne für allgemeine Zwecke.
12 ist ein Blockdiagramm, das einen beispielhaften integrierten System-auf-einem-Chip-Schaltkreis 1200 darstellt, der unter Verwendung eines oder mehrerer IP-Cores gemäß einer Ausführungsform hergestellt sein kann. Die beispielhafte integrierte Schaltung 1200 weist einen oder mehrere Anwendungsprozessoren 1205 (z. B. CPUs) und mindestens einen Grafikprozessor 1210 auf und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 aufweisen, von denen jeder ein modularer IP-Core von derselben oder mehreren unterschiedlichen Designeinrichtungen sein kann. Die integrierte Schaltung 1200 enthält eine Peripherie- oder Buslogik, aufweisend eine USB-Steuerung 1225, eine UART-Steuerung 1230, eine SPI/SDIO-Steuerung 1235 und eine I2S/I2C-Steuerung 1240. Zusätzlich kann die integrierte Schaltung eine Anzeigeeinrichtung 1245 aufweisen, die mit einer oder mehreren von einer Steuerung 1250 einer hochauflösenden Multimediaschnittstelle (HDMI) und einer Anzeigeschnittstelle 1255 einer „Mobile Industry Processor Interface“ (MIPI) gekoppelt ist. Speicherung kann durch ein Flash-Speichersubsystem 1260 bereitgestellt werden, das einen Flash-Speicher und eine Flash-Speichersteuerung aufweist. Die Speicherschnittstelle kann über eine Speichersteuerung 1265 für den Zugriff auf SDRAM- oder SRAM-Speichereinrichtungen bereitgestellt werden. Einige integrierte Schaltungen weisen zusätzlich eine eingebettete Sicherheits-Engine 1270 auf.
13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC gemäß hier beschriebenen Ausführungsformen darstellen. 13A stellt einen beispielhaften Grafikprozessor 1310 eines integrierten System-auf-einem-Chip-Schaltkreises dar, der unter Verwendung eines oder mehrerer IP-Cores gemäß einer Ausführungsform hergestellt werden kann. 13B stellt einen zusätzlichen beispielhaften Grafikprozessor 1340 eines integrierten System-auf-einem-Chip-Schaltkreises dar, der unter Verwendung eines oder mehrerer IP-Cores gemäß einer Ausführungsform hergestellt sein kann. Der Grafikprozessor 1310 von 13A ist ein Beispiel eines Grafikprozessorkerns mit niedrigem Stromverbrauch. Der Grafikprozessor 1340 von 13B ist ein Beispiel eines Grafikprozessorkerns mit höherem Stromverbrauch. Jeder der Grafikprozessoren 1310, 1340 kann eine Variante des Grafikprozessors 1210 aus 12.
Entsprechend der Darstellung in 13A umfasst 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). Der Grafikprozessor 1310 kann unterschiedliche Shader-Programme über separate Logik ausführen, sodass 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 Fragment-Prozessoren 1315A-1315N Fragment-Shading-Operationen (z. B. Pixel-Shading-Operationen) für Fragment- oder Pixel-Shader-Programme durchführen. Der Vertex-Punktprozessor 1305 führt die Vertex-Verarbeitungsstufe der 3D-Grafikpipeline durch und erzeugt Primitive und Vertex-Daten. Die Fragmentprozessoren 1315A-1315N verwenden die vom Vertex-Prozessor 1305 erzeugten Primitive und Vertex-Daten, um einen Framebuffer zu erzeugen, der auf einer Anzeigeeinrichtung angezeigt wird. Bei einer Ausführungsform sind die Fragmentprozessoren 1315A-1315N optimiert, um Fragment-Shader-Programme auszuführen, wie sie in der OpenGL-API bereitgestellt werden, die eingesetzt werden können, um ähnliche Operationen wie ein Pixel-Shader-Programm durchzuführen, wie es in der Direct 3D-API bereitgestellt ist.
Der Grafikprozessor 1310 weist zusätzlich eine oder mehrere Speicherverwaltungseinheiten (MMUs) 1320A-1320B, Caches 1325A- 1325B und Schaltkreisverbindungen 1330A-1330B auf. Die eine oder mehreren MMUs 1320A-1320B stellen eine Zuordnung von virtueller zu physikalischer Adressabbildung für den Grafikprozessor 1310 bereit, umfassend den Vertex-Prozessor 1305 und/oder die Fragmentprozessoren 1315A-1315N, die auf in Speicher gespeicherte Vertex- oder Bild-/Texturdaten verweisen können, zusätzlich zu in einem oder mehreren Caches 1325A-1325B gespeicherten Vertex- oder Bild-/Texturdaten. Bei einer Ausführungsform können die eine oder die mehreren MMUs 1320A-1320B mit anderen MMUs in dem System synchronisiert sein, umfassend eine oder mehrere MMUs, die dem einen oder den mehreren Anwendungsprozessoren 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 aus 12 zugeordnet sind, sodass jeder Prozessor 1205-1220 kann an einem gemeinsam genutzten oder einheitlichen virtuellen Speichersystem beteiligt sein kann. Die eine oder mehreren Schaltkreisverbindungen 1330A-1330B ermöglichen dem Grafikprozessor 1310 gemäß Ausführungsformen die Verbindung mit anderen IP-Cores innerhalb des SoC entweder über einen internen Bus des SoC oder über eine direkte Verbindung.
Entsprechend der Darstellung in 13B weist der Grafikprozessor 1340 die eine oder die mehreren MMUs 1320A-1320B, die Caches 1325A-1325B und die Schaltkreisverbindungen 1330A-1330B des Grafikprozessors 1310 aus 13A. Der Grafikprozessor 1340 umfasst einen oder mehrere Shader-Kerne 1355A-1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F, bis 1355N-1 und 1355N), die eine einheitliche Shader-Kernarchitektur bereitstellen, in der ein einzelner Kern oder Typ oder Core kann alle Arten von programmierbarem Shader-Code ausführen kann, umfassend Shader-Programmcode zum Implementieren von Vertex-Shadern, Fragment-Shadern und/oder Rechen-Shadern. Die genaue Anzahl der vorhandenen Shader-Kerne kann zwischen Ausführungsformen und Implementierungen variieren. Zusätzlich weist der Grafikprozessor 1340 einen Inter-Core-Task-Manager 1345 auf, der als Thread-Verteiler fungiert, um Ausführungs-Threads an einen oder mehrere Shader-Kerne 1355A-1355N zu verteilen, und eine Kacheleinheit 1358, um Kachel Operationen für kachelbasiertes Rendern zu beschleunigen, wobei Rendering-Operationen für eine Szene werden in Bildbereiche unterteilt werden, um beispielsweise die lokale räumliche Kohärenz in einer Szene auszunutzen oder die Verwendung interner Caches zu optimieren.
14A-14B veranschaulichen zusätzliche beispielhafte Grafikprozessorlogik gemäß hier beschriebenen Ausführungsformen. 14A zeigt einen Grafikkern 1400, der in dem Grafikprozessor 1210 aus 12 umfasst sein kann und der ein einheitlicher Shader-Kern 1355A-1355N wie in 13B gezeigt ist. 14B zeigt eine hochparallele Grafikverarbeitungseinheit 1430 für allgemeine Zwecke, die für den Einsatz auf einem Multi-Chip-Modul geeignet ist.
Entsprechend der Darstellung in 14A umfasst der Grafikkern 1400 einen gemeinsam genutzten Anweisungs-Cache 1402, eine Textureinheit 1418 und einen Cache/gemeinsam genutzten Speicher 1420, die den Ausführungsressourcen in dem Grafikkern 1400 gemein 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 Unterstützungslogik aufweisen, die einen lokalen Anweisungs-Cache 1404A-1404N, einen Thread-Scheduler 1406A-1406N, einen Thread-Verteiler 1408A-1408N und eine Gruppe von Registern 1410A umfasst. Zur Durchführung von Logikoperationen können die Slices 1401A-1401N eine Gruppe zusätzlicher Funktionseinheiten (AFUs 1412A-1412N), Gleitkommaeinheiten (FPUs 1414A-1414N), arithmetische Ganzzahl-Logikeinheiten (ALUs 1416-1416N), Adressberechnungseinheiten (ACU 1413A-1413N), Gleitkommaeinheiten mit doppelter Genauigkeit (DPFPUs 1415A-1415N) und Matrixverarbeitungseinheiten (MPUs 1417A-1417N) aufweisen.
Einige der Recheneinheiten arbeiten mit einer spezifischen Genauigkeit. Beispielsweise können die FPUs 1414A-1414N Gleitkommaoperationen mit einfacher Genauigkeit (32 Bit) und halber Genauigkeit (16 Bit) durchführen, während die DPFPUs 1415A-1415N Gleitkommaoperationen 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 sie können für Operationen mit gemischter Genauigkeit ausgelegt sein. Die MPUs 1417A-1417N können auch für Matrixoperationen mit gemischter Genauigkeit ausgelegt werden, umfassend Gleitkomma- und 8-Bit-Ganzzahloperationen mit halber Genauigkeit. Die MPUs 1417-1417N können eine Vielzahl von Matrixoperationen durchführen, um die Anwendungs-Frameworks für maschinelles Lernen zu beschleunigen, aufweisend Unterstützung der beschleunigten allgemeinen Matrix-zu-Matrix-Multiplikation (GEMM). Die AFUs 1412A-1412N können zusätzliche Logikoperationen durchführen, die von den Gleitkomma- oder Ganzzahl-Einheiten nicht unterstützt werden, umfassend trigonometrische Operationen (z. B. Sinus, Cosinus usw.).
Entsprechend der Darstellung in 14B kann eine Verarbeitungseinheit für allgemeine Zwecke (GPGPU) 1430 dafür ausgelegt sein, die Durchführung von hochparallelen Rechenoperationen durch ein Array von Grafikverarbeitungseinheiten zu ermöglichen. 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 Host-Schnittstelle 1432 auf, um eine Verbindung mit einem Host-Prozessor zu ermöglichen. Bei einer Ausführungsform ist die Host-Schnittstelle 1432 eine PCI-Express-Schnittstelle. Die Host-Schnittstelle kann jedoch auch eine herstellerspezifische Kommunikationsschnittstelle oder Kommunikationsstruktur sein. Die GPGPU 1430 empfängt Befehle vom Host-Prozessor und verwendet einen globalen Scheduler 1434, um mit diesen Befehlen assoziierte Ausführungsthreads auf eine Gruppe von Rechen-Clustern 1436A-1436H zu verteilen. Die Rechen-Cluster 1436A-1436H nutzen gemeinsam einen Cache-Speicher 1438. Der Cache-Speicher 1438 kann als Cache höherer Ebene für Cache-Speicher in den Rechen-Clustern 1436A-1436H dienen.
Die GPGPU 1430 weist einen Speicher 1434A-1434B auf, der über eine Gruppe von Speichersteuerungen 1442A-1442B mit den Rechen-Clustern 1436A-1436H gekoppelt ist. Bei verschiedenen Ausführungsformen kann der Speicher 1434A-1434B verschiedene Arten von Speichereinrichtungen aufweisen, einschließlich eines dynamischen Direktzugriffsspeichers (DRAM) oder eines Grafik-Direktzugriffsspeichers, wie beispielsweise eines synchronen Grafik-Direktzugriffsspeichers (SGRAM), umfassend einen Grafikspeicher mit doppelter Datenrate (GDDR).
Bei einer Ausführungsform umfassen die Rechen-Cluster 1436A-1436H jeweils eine Gruppe von Grafikkernen, wie beispielsweise den Grafikkern 1400 von 14A, der mehrere Arten von Ganzzahl- und Gleitkomma-Logikeinheiten aufweisen kann, die Rechenoperationen mit einer Reihe von Genauigkeiten ausführen können, umfassend für maschinelles Lernen geeignete Berechnungen. Beispielsweise und bei einer Ausführungsform kann mindestens eine Teilmenge der Gleitkommaeinheiten in jedem der Rechen-Cluster 1436A-1436H dafür ausgelegt sein, um 16-Bit- oder 32-Bit-Gleitkommaoperationen durchzuführen, während eine unterschiedliche Teilmenge der Gleitkommaeinheiten dafür ausgelegt sein kann, 64-Bit-Gleitkommaoperationen durchzuführen.
Mehrere Instanzen der GPGPU 1430 können dafür ausgelegt sein, als Rechen-Cluster zu arbeiten. Der Kommunikationsmechanismus, der von dem Rechen-Cluster für Synchronisation und Datenaustausch verwendet wird, variiert zwischen Ausführungsformen. Bei einer Ausführungsform kommunizieren die mehreren Instanzen der GPGPU 1430 über die Host-Schnittstelle 1432. Bei einer Ausführungsform umfasst die GPGPU 1430 einen E/A-Hub 1439, der die GPGPU 1430 mit einer GPU-Verbindung 1440 koppelt, die eine direkte Verbindung zu anderen Instanzen der GPGPU ermöglicht. Bei einer Ausführungsform ist die GPU-Verbindung 1440 mit einer dedizierten GPU-zu-GPU-Brücke gekoppelt, die die Kommunikation und Synchronisation zwischen mehreren Instanzen der GPGPU 1430 ermöglicht. Bei einer Ausführungsform ist die GPU-Verbindung 1440 mit einer Hochgeschwindigkeitsverbindung gekoppelt, um Daten an andere GPGPUs oder parallele Prozessoren zu senden und sie von ihnen zu empfangen. Bei einer Ausführungsform sind die mehreren Instanzen der GPGPU 1430 in separaten Datenverarbeitungssystemen positioniert und kommunizieren über eine Netzwerkeinrichtung, auf die über die Host-Schnittstelle 1432 zugegriffen werden kann. Bei einer Ausführungsform kann die GPU-Verbindung 1440 dafür ausgelegt sein, eine Verbindung zu einem Host-Prozessor zusätzlich oder als Alternative zu der Host-Schnittstelle 1432 zu ermöglichen.
Während die dargestellte Konfiguration der GPGPU 1430 zum Trainieren neuronaler Netze eingerichtet werden kann, stellt eine Ausführungsform eine alternative Konfiguration der GPGPU 1430 bereit, die für den Einsatz innerhalb einer Inferenzplattform mit hohem Stromverbrauch oder niedrigem Stromverbrauch eingerichtet werden kann. Bei einer Inferenz-Konfiguration weist die GPGPU 1430 relativ zu der Trainingskonfiguration weniger Rechen-Cluster 1436A-1436H auf. Zusätzlich kann sich die dem Speicher 1434A-1434B zugeordnete Speichertechnologie zwischen Inferenz- und Trainingskonfigurationen unterscheiden, wobei Speichertechnologien mit höherer Bandbreite auf Trainingskonfigurationen ausgerichtet sind. Bei einer Ausführungsform kann die Inferenzkonfiguration der GPGPU 1430 die Inferenz spezifischer Anweisungen unterstützen. Beispielsweise kann eine Inferenzkonfiguration Unterstützung für eine oder mehrere 8-Bit-Ganzzahl-Punkt-Produktanweisungen unterstützen, die üblicherweise während Inferenzoperationen für eingesetzte neuronale Netze verwendet werden.
Übersicht zu immersivem Video
15A stellt mehrere Formen von immersivem Video dar. Immersives Video kann in Abhängigkeit von den Freiheitsgraden, die einem Betrachter zur Verfügung stehen, in mehreren Formen präsentiert werden. Freiheitsgrade beziehen sich auf die Anzahl der unterschiedlichen Richtungen, in denen sich ein Objekt im dreidimensionalen (3D) Raum bewegen kann. Immersives Video kann über eine am Kopf befestigte Anzeige angezeigt werden, die eine Positions- und Orientierungsverfolgung aufweist. Beispiele für immersive Videos sind 3DoF 1502, 3DoF Plus 1504 und vollständige 6DoF 1506. Zusätzlich zu immersivem Video mit vollständigem 6DoF 1506 umfasst immersives 6DoF-Video omnidirektionale 6DoF 1507 und 6DoF 1508 mit Fenstern.
Bei Videos in 3DoF 1502 (z. B. 360-Grad-Video) kann ein Betrachter die Ausrichtung ändern (z. B. Gieren, Nicken, Rollen), jedoch nicht die Position. Bei Videos in 3DoF Plus 1504 kann ein Betrachter die Ausrichtung ändern und geringfügige Änderungen an Positionsänderungen vornehmen. Bei Videos in 6DoF 1506 kann ein Betrachter die Ausrichtung ändern und die Position ändern. Eingeschränktere Formen von 6DoF-Videos sind ebenfalls verfügbar. Video in omnidirektionalem 6DoF 1507 ermöglicht einem Betrachter die Befähigung zur Vornahme mehrerer Schritte in der virtuellen Szene. Video in 6DoF 1508 mit Fenstern ermöglicht es einem Betrachter, die Ausrichtung und Position zu ändern, wobei der Betrachter jedoch auf einen begrenzten Sichtbereich eingeschränkt ist. Das Erhöhen der verfügbaren Freiheitsgrade bei einem immersiven Video umfasst im Allgemeinen das Erhöhen der Menge und Komplexität von Daten, die bei der Videoerzeugung, -codierung, -decodierung und -wiedergabe einbezogen sind.
15B stellt Bildprojektions- und Texturebenen für immersives Video dar. Eine 3D-Ansicht 1510 von Videoinhalt kann unter Verwendung von Daten von mehreren Kameras erzeugt werden. Mehrere Projektionsebenen 1512 können verwendet werden, um Geometriedaten für Videoinhalt zu erzeugen. Für die Projektionsebenen 1512, die zum Erzeugen der Geometriedaten verwendet werden, können mehrere Texturebenen 1514 abgeleitet werden. Die Texturebenen 1514 können auf 3D-Modelle angewendet werden, die vorgeneriert oder basierend auf einer aus Videodaten abgeleiteten Punktwolke erzeugt werden. Die mehreren Projektionsebenen 1512 können verwendet werden, um mehrere zweidimensionale (2D) Projektionen zu erzeugen, wobei jede Projektion einer Projektionsebene zugeordnet ist.
16 zeigt ein Client-Server-System, mit dem immersiver Videoinhalt von einer Server-Infrastruktur 1620 zur Übertragung an eine oder mehrere Client-Einrichtungen 1630 erzeugt und codiert werden kann. Die Client-Einrichtungen 1630 können anschließend den immersiven Videoinhalt dekomprimieren und rendern. Bei einer Ausführungsform können ein oder mehrere Server-Einrichtungen 1620 Eingaben von einer oder mehreren optischen Kameras 1601 aufweisen, die Tiefensensoren 1602 aufweisen. Ressourcen für die parallele Berechnung 1604 können die Video- und Tiefendaten in Punktwolken 1605 und/oder Texturdreiecke 1606 zerlegen. Daten zum Erzeugen von strukturierten Dreiecken 1606 können auch durch vorgenerierte 3D-Modelle 1603 einer Szene bereitgestellt werden. Die Punktwolken 1605 und/oder strukturierten Dreiecke 1606 können zur Übertragung zu einer oder mehreren Client-Einrichtungen komprimiert werden, die den Inhalt lokal rendern können. Bei einer Ausführungsform können mehrere Komprimierungseinheiten 1607, 1608 unter Verwendung einer Mehrzahl von Komprimierungsalgorithmen erzeugten Inhalt zur Übertragung über ein Übertragungsmedium vom Server 1620 zu einer oder mehreren Client-Einrichtungen 1630 komprimieren. Dekomprimierungseinheiten 1609, 1610 auf den Clienteinrichtungen 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 zu einer Betrachtungspunkt-Interpolationseinheit 1611 bereitstellen. Die interpolierten Ansichtspunktdaten können verwendet werden, um Bitmap-Daten 1613 zu erzeugen. Die dekomprimierten Punktwolkendaten können zu einer Geometrie-Rekonstruktionseinheit 1612 bereitgestellt werden, um Geometriedaten für eine Szene zu rekonstruieren. Die rekonstruierten Geometriedaten können durch decodierte Texturdaten (texturierte Dreiecke 1614) texturiert werden, um ein 3D-Rendering 1616 zum Betrachten durch den Client 1630 zu erzeugen.
17A-17B veranschaulicht Systeme 1700, 1710 zum Codieren und Decodieren von 3DoF-Plus-Inhalt. Das System 1700 kann beispielsweise durch Hardware und Software einer Server-Infrastruktur 1620 wie beispielsweise in 16. Das System 1710 kann durch Hardware und Software eines Clients 1630 wie in 16.
Entsprechend der Darstellung in 17A 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, aufweisend Videodaten und Tiefendaten, bereitstellen, wobei jeder Rahmen von Videodaten in eine Textur konvertiert werden kann. Eine Gruppe von Einheiten für die Reproduktion 1706 und Verschlusserkennung 1707 kann mit empfangenen Videodaten arbeiten und verarbeitete Daten an Einheiten 1708 zur Patch-Bildung ausgeben. Durch die Einheiten zur Patch-Bildung 1708 gebildete Patches können zu einer Patch-Packungs-Einheit 1709 bereitgestellt werden. Videodaten 1702 für die Basisansicht 1701 können zum Beispiel über einen hocheffizienten Videocodierungs-(HEVC)-Codierer 1703A codiert werden. Eine Variante des HEVC-Codierers 1703A kann auch zum Codieren von Patch-Videodaten verwendet werden, die von der Patch-Packungseinheit 1709 ausgegeben werden. Metadaten zum Rekonstruieren von Video aus den codierten Patches können durch eine Metadaten-Codiereinheit 1703B codiert werden. Anschließend können mehrere codierte Video- und Metadatenströme zur Anzeige zu einer Client-Einrichtung übertragen werden.
Entsprechend der Darstellung in 17B können mehrere Videodatenströme vom System 1710 empfangen, decodiert und in immersives Video rekonstruiert werden. Die mehreren Videostreams weisen einen Stream für das Basisvideo zusammen mit einem Stream auf, der gepackte Daten für die zusätzlichen Ansichten enthält. Codierte Metadaten werden ebenfalls empfangen. Die mehreren Videoströme können bei einer Ausführungsform über einen HEVC 1713A-Decoder decodiert werden. Metadaten können über einen Metadaten-Decoder 1713B decodiert werden. Die decodierten Metadaten werden anschließend verwendet, um die decodierten zusätzlichen Ansichten über die Patch-Entpackungslogik 1719 zu entpacken. Decodierte Textur- und Tiefendaten (Video 0 1712, Video 1-3 1714A-1715C) der Basisansicht 1701 und der zusätzlichen Ansichten 1704 werden durch die Ansichtserzeugungslogik 1718 auf dem Client (z. B. Client 1630 wie in 16) rekonstruiert. Das decodierte Video 1712, 1715A-1715C kann als Textur- und Tiefendaten zu einem Zwischenansichts-Renderer 1714 bereitgestellt werden, der zum Rendern von Zwischenansichten für eine am Kopf befestigte Anzeige 1711 verwendet werden kann. Am Kopf befestigte Anzeigepositionsinformation 1716 wird als Rückmeldung zu dem Zwischenansichts-Renderer 1714 bereitgestellt, der aktualisierte Ansichten für das angezeigte Ansichtsfenster rendern kann, das über die am Kopf befestigte Anzeige 1711 präsentiert wird.
18A-18B veranschaulichen ein System zum Codieren und Decodieren von 6DoF-Texturgeometriedaten. 18A zeigt ein 6DoF-Texturgeometrie-Codiersystem 1800. 18B zeigt ein 6DoF-Decodiersystem 1820 für texturierte Geometrie. 6DoF-Codierung und -Decodierung für texturierte Geometrie können verwendet werden, um eine Variante von immersivem 6DoF-Videos zu aktivieren, bei der Videodaten als Textur auf Geometriedaten angewendet werden, sodass neue Zwischenansichten basierend auf der Position und Ausrichtung einer am Kopf befestigten Anzeige gerendert werden können. Von mehreren Videokameras aufgezeichnete Daten können mit 3D-Modellen kombiniert werden, insbesondere für statische Objekte.
Entsprechend der Darstellung in 18A kann ein 6DoF-Codiersystem für texturierte Geometrie 1800 Videodaten 1802 für eine Basisansicht und Videodaten 1805A-1805C für zusätzliche Ansichten empfangen. Die Videodaten 1802, 1805A-1805C enthalten Textur- und Tiefendaten, die von einer Reproduktions- und Verschlusserkennungseinheit 1806 verarbeitet werden können. Die Ausgabe von der Reproduktions- und Verschlusserkennungseinheit 1806 kann zu einer Patch-Zerlegungseinheit 1807 und einem Geometrie-Bildgenerator 1808 bereitgestellt werden. Die Ausgabe von der Patch-Zerlegungseinheit 1807 wird zu einer Patch-Packungseinheit 1809 und einem unterstützenden Patch-Informationsverdichter 1813 bereitgestellt. Die unterstützende Patch-Information (patch-info) stellt Information zum Wiederherstellen von Videotextur- und Tiefendaten bereit. Die Patch-Packeinheit 1809 gibt gepackte Patch-Daten zu dem Geometrie-Bildgenerator 1808, einem Textur-Bildgenerator 1810, einem Attribut-Bildgenerator 1811 und einem Belegungsabbildungsverdichter 1812 aus.
Der Geometrie-Bilderzeuger 1808, der Textur-Bilderzeuger 1810 und der Attribut-Bilderzeuger 1811 geben Daten zu einem Videokomprimierer 1814 aus. Der Geometrie-Bilderzeuger 1808 kann eine Eingabe von der Reproduktions- und Verschlusserkennungseinheit 1806, der Patch-Zerlegungseinheit 1807 und der Patch-Packungseinheit 1809 empfangen und erzeugt Geometrie-Bilddaten. Der Texturbildgenerator 1810 kann gepackte Patch-Daten von der Patch-Packeinheit 1809 und Videotextur- und Tiefendaten von der Reproduktions- und Verschlusserfassungseinheit 1806 empfangen. Der Attributbildgenerator 1811 erzeugt ein Attributbild aus Videotextur- und Tiefendaten, die von der Reproduktions- und Verschlusserfassungseinheit 1806 empfangen wurden, und gepatchten Patch-Daten, die von der Patch-Packeinheit 1809 empfangen wurden.
Eine Belegungskarte kann von einem Belegungskartenverdichter 1812 basierend auf gepackten Patch-Daten erzeugt werden, die von der Patch-Packeinheit 1809 ausgegeben werden. Hilfs-Patchinformation kann durch den Hilfs-Patchinformationsverdichter 1813 erzeugt werden. Die verdichtete Belegungskarten- und Hilfs-Patchinformationsdaten können durch einen Multiplexer 1815 zusammen mit komprimierten und/oder codierten Videodaten, die von dem Videoverdichter 1814 ausgegeben werden, in einen verdichteten Bitstrom 1816 gebündelt werden. Die verdichteten Videodaten, die von dem Videoverdichter 1814 ausgegeben werden, weisen verdichtete Geometriebilddaten, Texturbilddaten und Attributbilddaten auf Der verdichtete Bitstrom 1816 kann gespeichert oder zu einer Client-Einrichtung zur Dekomprimierung und Betrachtung bereitgestellt werden.
Entsprechend der Darstellung in 18B kann ein 6DoF-Decodiersystem mit strukturierter Geometrie 1820 verwendet werden, um 6DoF-Inhalt zu decodieren, der unter Verwendung des Codiersystems 1800 aus 18A. Der verdichtete Bitstrom 1816 wird von einem Demultiplexer 1835 empfangen und in mehrere Videodecodierströme, eine Belegungskarte und Hilfs-Patchinformation entbündelt. Die mehreren Videoströme werden von den Videodecodern 1834A-1834B decodiert/dekomprimiert. Belegungskartendaten werden durch einen Belegungskartendecoder 1832 decodiert/dekomprimiert. Die decodierten Videodaten und Belegungskartendaten werden von den Videodecodern 1834A-1834B und dem Belegungskartendecoder 1832 an eine Entpackeinheit 1829 ausgegeben. Die Entpackeinheit entpackt Video-Patchdaten, die von der Patch-Packeinheit 1809 aus 18A. Hilfs-Patch-Information von dem Hilfs-Patch-Info-Decoder 1833 werden zu einer Verschluss-Fülleinheit 1826 bereitgestellt, die verwendet werden kann, um Patches von verschlossenen Teilen eines Objekts auszufüllen, die bei einer bestimmten Ansicht der Videodaten möglicherweise fehlen. Entsprechende Videoströme 1822, 1825A-1825C, die Textur- und Tiefendaten aufweisen, werden von der Verschluss-Fülleinheit 1826 ausgegeben und zu einem Zwischenansichts-Renderer 1823 bereitgestellt, der eine Ansicht zur Anzeige auf einer am Kopf befestigten Anzeige 1824 basierend auf der durch die am Kopf befestigte Anzeige 1824 bereitgestellten Positions- und Ausrichtungsinformation rendern kann.
19A-19B veranschaulichen ein System zum Codieren und Decodieren von 6DoF-Punktwolkendaten. 19A veranschaulicht ein 6DoF-Punktwolken-Codiersystem 1900. 19B veranschaulicht ein 6DoF-Punktwolken-Decodiersystem 1920. 6DoF-Video kann mithilfe von Punktwolken dargestellt werden, wobei für eine Punktwolken-Videosequenz in regelmäßigen Zeitintervallen (z. B. 60 Hz) ein neuer Punktwolkenrahmen vorliegt. Jeder Punkt im Punktwolken-Datenrahmen wird durch sechs Parameter dargestellt: (X, Y, Z) Geometrieposition und (R, G, B oder Y, U, V) Texturdaten. Bei dem Codiersystem 1900 aus 19A wird ein Punktwolkenrahmen auf mehrere zweidimensionale (2D) Ebenen projiziert, wobei jede 2D-Ebene einem Projektionswinkel entspricht. Die Projektionsebenen können den Projektionsebenen 1512 aus 15B gezeigt ist. Bei einigen Implementierungen werden im PCC-Standardtestmodell sechs Projektionswinkel verwendet, wobei die Projektionswinkel Winkeln entsprechen, die auf die Mitten von sechs Flächen eines Quaders zeigen, die das durch die Punktwolkendaten dargestellte Objekt begrenzen. Während sechs Projektionswinkel beschrieben sind, könnte bei unterschiedlichen Implementierungen möglicherweise eine andere Anzahl von Winkeln verwendet werden.
Textur- und Tiefen-2D-Bild-Patch-Darstellungen werden bei jedem Projektionswinkel gebildet. Die 2D-Patch-Bilddarstellungen für einen Projektionswinkel können erstellt werden, indem nur die Punkte projiziert werden, für die ein Projektionswinkel die nächstliegende Normale aufweist. Anders ausgedrückt, wird die 2D-Patch-Bilddarstellung für die Punkte verwendet, die das Skalarprodukt der Punktnormalen und der Ebenennormalen maximieren. Texturfelder aus den einzelnen Projektionen werden zu einem einzelnen Texturbild kombiniert, das als das Geometriebild bezeichnet wird. Metadaten zur Darstellung der Patches, und wie diese in einen Rahmen gepackt sind, werden in der Belegungskarte und der Patch-Zusatzinformation beschrieben. Die Belegungskarten-Metadaten weisen eine Angabe auf, welche Bildabtastpositionen leer sind (z. B. keine entsprechende Punktwolkeninformation enthalten). Die Patch-Zusatzinformation gibt die Projektionsebene an, zu der ein Patch gehört, und kann verwendet werden, um eine Projektionsebene festzulegen, die einer bestimmten Abtastposition zugeordnet ist. Die Texturbilder und Tiefenbilder werden unter Verwendung eines herkömmlichen 2D-Videocodierers, beispielsweise eines hocheffizienten Videocodierers (HEVC), codiert. Die Metadaten können mithilfe der Metadaten-Codierlogik separat verdichtet werden. Bei dem Testmodelldecoder werden die Texturbilder und Tiefenbilder unter Verwendung eines HEVC-Videodecoders decodiert. Eine Punktwolke wird unter Verwendung der decodierten Textur- und Tiefenbilder zusammen mit der Belegungskarte und den zusätzlichen Patch-Info-Metadaten rekonstruiert.
Entsprechend der Darstellung in 19A kann ein Eingaberahmen von Punktwolkendaten in Patchdaten zerlegt werden. Die Punktwolkendaten und die zerlegten Patchdaten können auf ähnliche Weise wie Videotextur- und Tiefendaten in 18A. Eingabedaten, die einen Punktwolkenrahmen 1906 aufweisen, können zu einer Patch-Zerlegungseinheit 1907 bereitgestellt werden. Die Eingabepunktwolkendaten und zerlegten Patches davon können durch eine Packeinheit 1909, einen Geometriebildgenerator 1908, einen Texturbildgenerator 1910, einen Attributbildgenerator 1911, einen Belegungskartenverdichter 1912 und einen Hilfs-Patch-Informationsverdichter 1913 unter Verwendung von Techniken verarbeitet werden, die der Verarbeitung der Texturtiefe- und Videodaten ähneln, die von der Reproduktions- und Verschlusserfassungseinheit 1806 und der Patch-Zerlegungseinheit 1807 aus 18A. Ein Videoverdichter 1914 kann Geometriebild-, Texturbild- und Attributbilddaten codieren und/oder verdichten. Die verdichteten und/oder codierten Videodaten von dem Videoverdichter 1914 können durch einen Multiplexer 1915 mit Belegungskarten- und zusätzlichen Patch-Informationsdaten in einen verdichteten Bitstrom 1916 gebündelt werden, der gespeichert oder zur Anzeige übertragen werden kann.
Der verdichtete Bitstrom, der von dem System 1900 aus 19A ausgegeben wird, kann durch das Punktwolken-Decodiersystem 1920 decodiert werden, das in 19B gezeigt ist. Entsprechend der Darstellung in 19B kann ein verdichteter Bitstrom 1916 in mehrere codierte/verdichtete Videoströme, Belegungskartendaten und Hilfs-Patchinformation entbündelt werden. Die Videoströme können durch einen Multi-Stream-Videodecoder 1934 decodiert/dekomprimiert werden, der Textur- und Geometriedaten ausgeben kann. Belegungskarten und Hilfs-Patchinformation können durch einen Belegungskartendecoder 1932 und einen Hilfs-Patchinformationsdecoder 1933 dekomprimiert/decodiert werden.
Anschließend kann eine Geometrie-Rekonstruktion, Glättung und Textur-Rekonstruktion durchgeführt werden, um die Punktwolkendaten zu rekonstruieren, die zu dem 6DoF-Punktwolken-Codiersystem 1900 aus 19A. Eine Geometrie-Rekonstruktionseinheit 1936 kann Geometrieinformation rekonstruieren, basierend auf aus einem Videostrom des Multi-Stream-Videodecoders 1934 decodierten Geometriedaten sowie der Ausgabe des Belegungskartendecoders 1932 und des Hilfs-Patchinformationsdecoders 1933. Rekonstruierte Geometriedaten können durch eine Glättungseinheit 1937 geglättet werden. Geglättete Geometrie- und Texturbilddaten, die aus einem von dem Multi-Stream-Videodecoder 1934 ausgegebenen Videostrom decodiert wurden, werden zu einer Textur-Rekonstruktionseinheit 1938 bereitgestellt. Die Textur-Rekonstruktionseinheit 1938 kann eine rekonstruierte Punktwolke 1939 ausgeben, die eine Variante des Eingabe-Punktwolkenrahmens 1926 ist, der zu dem 6DoF-Punktwolken-Codiersystem 1900 aus 19A.
Selektives Packen von Patches für immersives Video
Bei einigen Ausführungsformen stellen eine Vorrichtung, ein System oder ein Prozess selektives Packen von Patches für immersives Video bereit. Bei einigen Ausführungsformen werden die Patches danach ausgewählt, welche einer Mehrzahl von Projektionsrichtungen (wobei eine Projektionsrichtung Inhalt von einer gegebenen Kamera oder virtuellen Kamera ist) jedem der Patches zugeordnet ist.
Beim herkömmlichen Packen von Patches für immersives Video werden alle Patches gepackt und zur Übertragung an einen Benutzer in einem codierten Bild codiert, wobei der Benutzer anschließend das gesamte Bild, das die Patches enthält, decodieren muss, um ein oder mehrere benötigte Patches zu erhalten und zum Rendern eines bestimmten Ansichtsfensters mit einer Hauptansicht zu mischen.
Wenn jedoch ein Ansichtsfenster zum Betrachten basierend auf einer bestimmten Ansichtsposition gerendert wird, z. B. einer Position/Ausrichtung des HMD (am Kopf befestigte Anzeige), wird zum Rendern des Ansichtsfensters nur eine Teilmenge der Projektionsrichtungen verwendet, wobei die Projektionsrichtungen in der Regel diejenigen sind, die in der Nähe der Ansichtsfensterposition liegen.
Bei einigen Ausführungsformen wird eine selektive Patch-Packanordnung für die Patches aus den verschiedenen Projektionsrichtungen angewendet, sodass ein Client weniger Patch-Daten beim Rendern eines bestimmten Ansichtsfensters decodieren kann, während ein korrektes Rendern des für willkürliche Betrachtungspositionen benötigten Ansichtsfensters weiterhin ermöglicht wird.
Bei einigen Ausführungsformen umfassen eine Vorrichtung, ein System oder ein Prozess zum selektiven Füllen von Patches für immersives Video eines oder mehrere von Folgendem:

(1) Das selektive Patch-Packen stellt die Erzeugung mehrerer codierter Bilder bereit, wobei jedes codierte Bild ausgewählte Patches für eine oder mehrere Projektionsrichtungen aufweist, wobei Folgendes umfasst sein kann:
- (a) Die Patches aus jeder Projektionsrichtung werden jeweils in ein entsprechendes codiertes Bild gepackt, sodass die selektive Patch-Füllung für jede Projektionsrichtung ein getrenntes codiertes Bild bereitstellt.
- (b) Sätze oder Gruppen von Projektionsrichtungen werden erstellt, und ein getrenntes codiertes Bild wird zum Packen von mit jeder Gruppe von Projektionsrichtungen assoziierten Patches erzeugt.
(2) Das selektive Patch-Packen verwendet Kacheln, um ausgewählte Patches für eine oder mehrere Projektionsrichtungen zu umfassen, die Folgendes aufweisen können:
- (a) Kacheln werden zum selektiven Packen von Patches für jede Projektionsrichtung verwendet, wobei das gesamte codierte Bild eine Kachel enthält, die jeder Projektionsrichtung entspricht und die entsprechenden Patches für die Projektionsrichtung enthält.
- (b) Kacheln werden zum selektiven Packen von Patches für jede Gruppe von Projektionsrichtungen angewandt, wobei das gesamte codierte Bild eine Kachel enthält, die jeder Gruppe von Projektionsprojektionen entspricht und die entsprechenden Patches für die Gruppe von Projektionsrichtungen enthält.

20A ist eine Darstellung eines Verarbeitungssystems zum Bereitstellen von selektivem Patch-Packen gemäß einigen Ausführungsformen. Bei einigen Ausführungsformen weist ein Verarbeitungssystem 2000, wie z. B. ein Verarbeitungssystem 100, dargestellt in 1, einen oder mehrere Prozessorkerne auf. Bei einigen Ausführungsformen weist das Verarbeitungssystem 2000 einen oder mehrere Prozessoren 2005 auf (die eine oder mehrere CPUs (zentrale Recheneinheiten) aufweisen können), wie z. B. Prozessoren 102, die in 1 dargestellt sind und die einen oder mehrere Prozessorkerne aufweisen, und es weist ferner eine oder mehrere GPUs 2010 auf, wie die in 1 dargestellten Grafikprozessoren 108, die einen oder mehrere Grafikprozessorkerne aufweisen, wobei die GPUs 2010 in dem einen oder den mehreren Prozessoren 2005 umfasst oder von diesen getrennt sein können. Ausführungsformen sind jedoch nicht auf diese besondere Verarbeitungsstruktur beschränkt. Der eine oder die mehreren Prozessoren 2205 können die Elemente entsprechend der Darstellung für den Prozessor 200 in 2 aufweisen, und die eine oder mehreren GPUs 2010 können die Elemente entsprechend der Darstellung für den Grafikprozessor 300 in 3. Das Verarbeitungssystem umfasst ferner einen Speicher 2015 zum Speichern von Daten zum Codieren von immersivem Video.
Bei einigen Ausführungsformen stellen die Prozessorkerne, wie die Prozessorkerne der einen oder mehreren GPUs 2010, das Patch-Packen und Codieren bereit, wie als Patch-Packen 1709 und HEVC-Codieren 1703A und Metadaten-Codieren 1703B in 17A. Bei einigen Ausführungsformen umfasst das Patch-Packen ein selektives Packen von Patches, zumindest teilweise basierend auf der Projektionsrichtung zum Erzeugen von einem oder mehreren codierten Bildern, die die ausgewählten Patches 2025 enthalten. Bei einigen Ausführungsformen kann das selektive Packen von Patches das Packen umfassen, das in den codierten Bildern dargestellt ist, die in einer von 24, 26, 27A oder 27B dargestellt sind.
20B ist eine Darstellung eines Client-Systems zum Decodieren eines oder mehrerer codierter Bilder, die ausgewählte Patches enthalten, gemäß einigen Ausführungsformen. Bei einigen Ausführungsformen weist ein Client-System 2050, wie z. B. ein Verarbeitungssystem 100, das in 1 dargestellt ist, einen oder mehrere Prozessorkerne auf. Bei einigen Ausführungsformen weist das Client-System 2050 einen oder mehrere Prozessoren 2055 auf (die eine oder mehrere CPUs (zentrale Recheneinheiten) aufweisen können), wie z. B. Prozessoren 102, die in 1 dargestellt sind und die einen oder mehrere Prozessorkerne aufweisen, und es weist ferner eine oder mehrere GPUs 2060 auf, wie die in 1 dargestellten Grafikprozessoren 108, die einen oder mehrere Grafikprozessorkerne aufweisen, wobei die GPUs 2060 in dem einen oder den mehreren Prozessoren 2055 umfasst oder von diesen getrennt sein können. Ausführungsformen sind jedoch nicht auf diese besondere Verarbeitungsstruktur beschränkt. Der eine oder die mehreren Prozessoren 2055 können die Elemente entsprechend der Darstellung für den Prozessor 200 in 2 aufweisen, und die eine oder mehreren GPUs 2060 können die Elemente entsprechend der Darstellung für den Grafikprozessor 300 in 3. Das Client-System 2050 umfasst ferner einen Speicher 2065 zum Speichern von Daten zum Bereitstellen von immersivem Video, wie beispielsweise Daten für eine am Kopf befestigte Anzeige (HMD).
Bei einigen Ausführungsformen werden ein oder mehrere codierte Bilder mit ausgewählten Patches für bestimmte Projektionsrichtungen 2070 von dem Client-System 2050 empfangen, wie beispielsweise die codierten Bilder 2025, die in 20A dargestellt sind. Die Prozessorkerne, wie die Prozessorkerne der einen oder mehreren GPUs 2060, stellen eine begrenzte Decodierung und ein begrenztes Entpacken 2075 von Patches bereit, wie dies als HEVC-Decodieren 1713A und Metadatendecodieren 1713B und als Entpacken 1719 von Patches in 17A für ein oder mehrere codierte Bilder mit ausgewählten Patches dargestellt ist. Bei einigen Ausführungsformen umfasst das Decodieren und Entpacken von Patches das Decodieren und Entpacken mit Einschränkung auf Patches, die mit einem bestimmten Ansichtsfenster assoziiert sind, das vom Client-System gerendert werden soll, um den für das Bereitstellen von immersivem Video erforderlichen Decodierumfang zu minimieren, entsprechend der Darstellung durch die für das Ansichtsfenster 2080 erforderlichen Patches, die zu einem Ansichtsfenster-Renderer 2085 bereitgestellt werden. Bei einigen Ausführungsformen kann das eingeschränkte Decodieren und Entpacken von Patches 2075 das Decodieren und Entpacken umfassen, wie es in den codierten Bildern erforderlich ist, die in einer von 24, 26, 27A oder 27B dargestellt sind.
21 ist eine Darstellung eines Bildes für immersives Video unter Verwendung selektiven Packens von Patches gemäß einigen Ausführungsformen. In dem Bild 2100 können mehrere Vordergrundelemente vorliegen, beispielsweise mehrere Spieler in einem Fußballspiel oder einem anderen Sportereignis. Das Fußballspiel kann von einer beliebigen Anzahl von Kameras aufgezeichnet werden, wobei jede Kamera eine bestimmte Ansicht definieren kann. Bei einem bestimmten Beispiel können 36 Bilder pro Rahmen vorliegen, wobei jedes Bild eine Auflösung von 5K×3K (5120×2880) aufweist.
Patches werden basierend auf Objekten erzeugt, die aus einer bestimmten Kameraansicht sichtbar sind. 22 ist eine vereinfachte Darstellung von Patches, die für eine beispielhafte Gruppe von Bildern erzeugt wurden, beispielsweise aufweisend das in 21. Die Anzahl von Patches hängt von der Kameraansicht und der Art der Bilder ab, kann jedoch eine sehr große Menge hochauflösender Daten aufweisen, die in ein codiertes Bild gepackt werden. Ein als Atlas bezeichnetes Bild wird aus mehreren Bildern zur gleichen Frame-Zeit, jedoch aus unterschiedlichen Positionen/Perspektiven kopiert. Bei einem herkömmlichen System muss ein Client alle Patches in dem Atlas decodieren, wodurch erhebliche Verarbeitungskosten anfallen. Bei einigen Ausführungsformen stellt ein System selektives Packen von Patches basierend auf der Projektionsrichtung bereit, um den Decodierumfang zu reduzieren, der von einem Client benötigt wird, um eine bestimmte Perspektive zu erzeugen. Bei einigen Ausführungsformen sind in den Patches für eine bestimmte Kamera-Projektionsrichtung nur Bereiche umfasst, die von anderen Projektionsrichtungen verdeckt sind. Bei einigen Ausführungsformen kann das selektive Packen von Patches das Packen umfassen, das in den codierten Bildern dargestellt ist, die in einer von 24, 26, 27A oder 27B dargestellt sind.
23 ist eine Darstellung einer beispielhaften Gruppe von Blickpunkten für ein System, aufweisend selektives Patch-Packen gemäß einigen Ausführungsformen. Während eine Ausführungsform eines Systems eine beliebige Anzahl von Kameras aufweisen kann, stellt 23 ein Beispiel dar, das 24 Kameras (Kameras C01 bis C24) aufweist, die 24 unterschiedliche Blickpunkte erstellen. Tatsächliche Systeme können eine größere Anzahl von Kameras aufweisen, und derartige Kameras können abhängig von den Erfordernissen für ein bestimmtes Subjekt für immersives Video in beliebiger Anordnung verteilt sein.
Bei einigen Ausführungsformen wird selektives Packen von Patches für immersives Video basierend auf den verschiedenen Blickpunkten in einem System durchgeführt, wobei die Patches ausgewählt werden, die jedem Blickpunkt zugeordnet sind. 24 ist eine Darstellung von selektivem Packen von Patches, um codierte Bilder für jeden Blickpunkt gemäß einigen Ausführungsformen bereitzustellen. Bei einigen Ausführungsformen soll ein System Patches gemäß jedem verfügbaren Blickpunkt auszuwählen und die mit jedem Blickpunkt assoziierten Patches packen und derartige Patches in ein separates codiertes Bild codieren.
Bei einem besonderen Beispiel, in dem n Blickpunkte vorliegen, wie z. B. die n=24 Blickpunkte, die in 23 dargestellt sind, soll ein System n codierte Bilder erzeugen. Entsprechend der Darstellung in 24 sind das Ergebnis des selektiven Packens von Patches n codierte Bilder (und somit n Atlanten von Bildern), wie z. B. Patches-1 1410, Patches-2, und weiter bis Patches-n. Bei einigen Ausführungsformen kann ein Client eines oder mehrere der mehreren codierten Bilder 1410 bis 2430 nach Bedarf bei der Erzeugung von immersivem Video decodieren.
Bei einigen Ausführungsformen wird das selektive Packen von Patches für immersives Video basierend auf den verschiedenen Blickpunkten in einem System durchgeführt, wobei die Patches ausgewählt werden, die mit jedem der mehreren Gruppen von Blickpunkten assoziiert sind. 25A bis 25D veranschaulichen Gruppen von Blickpunkten für selektives Packen von Patches gemäß einigen Ausführungsformen. 25A bis 25D veranschaulichen ein besonderes Beispiel, bei dem bestimmte Gruppen von Blickpunkten basierend auf den Blickpunkten festgelegt werden, die in 23.
Bei diesem Beispiel stellt 25A eine erste Gruppe von Blickpunkten für Kameras C01 bis C06 bereit; 25B stellt eine zweite Gruppe von Blickpunkten für Kameras C07 bis C12 bereit; 25C stellt eine dritte Gruppe von Blickpunkten für Kameras C13 bis C18 bereit; 25D stellt eine vierte Gruppe von Blickpunkten für Kameras C19 bis C24 bereit. Während in diesem Beispiel zur Vereinfachung der Darstellung die Kameras gleichmäßig beabstandet sind und es 6 Blickpunkte in jeder von 4 Gruppen von Blickpunkten gibt, sind Ausführungsformen nicht auf eine bestimmte Anzahl oder Position der Blickpunkte beschränkt und können abweichende Größen und Positionen der Gruppen von Blickpunkten aufweisen.
26 ist eine Darstellung des selektiven Packens von Patches, um codierte Bilder für jede Gruppe von Blickpunkten gemäß einigen Ausführungsformen bereitzustellen. Bei einigen Ausführungsformen soll ein System Patches gemäß jeder Gruppe von Blickpunkten auszuwählen und die mit jeder Gruppe von Blickpunkten assoziierten Patches packen und die Patches in ein separates codiertes Bild codieren (das einen Atlas für eine Untermenge von Bildern wiedergibt).
26 stellt mehrere codierte Bilder dar, wobei in einem möglichen Beispiel jedes codierte Bild die Patches für eine der Gruppen von Blickpunkten codiert, die in 25A bis 25D. Entsprechend der Darstellung in 26 enthält ein erstes codiertes Bild, CodedPicture-1 2610, ausgewählte Patches für die erste Gruppe von Blickpunkten, die in 25A dargestellt ist; ein zweites codiertes Bild, CodedPicture-2 2620, enthält ausgewählte Patches für die zweite Gruppe von Blickpunkten, die in 25B dargestellt ist; ein drittes codiertes Bild, CodedPicture-3 2630, enthält ausgewählte Patches für die dritte Gruppe von Blickpunkten, die in 25C dargestellt ist; und ein viertes codiertes Bild, CodedPicture-4 2640, enthält ausgewählte Patches für die vierte Gruppe von Blickpunkten, die in 25D dargestellt ist.
Bei einigen Ausführungsformen wird selektives Packen von Patches für immersives Video basierend auf den verschiedenen Blickpunkten in einem System durchgeführt, wobei die Patches, die jedem Blickpunkt zugeordnet sind, für eine Kachel in einem codierten Bild ausgewählt werden. 27A ist eine Darstellung des selektiven Packens von Patches in Kacheln entsprechend der Projektionsrichtung gemäß einigen Ausführungsformen. Bei einigen Ausführungsformen werden Kacheln zum selektiven Packen von Patches für jede Projektionsrichtung angewendet. Zum Beispiel kann das Merkmal des bewegungsbeschränkten Kachelsatzes (MCTS) der HEVC (hocheffiziente Videocodierung) angewendet werden, sodass ausgewählte Patches in einer bestimmten bewegungsbeschränkten Kachel umfasst sind. Auf diese Weise können Decoder Kacheln einzeln decodieren, ohne dass das gesamte codierte Bild decodiert werden muss. Beispielsweise können Patches aus jeder Projektionsrichtung jeweils gepackt und in ihre eigene Kachel codiert werden, wobei das gesamte codierte Bild eine Kachel enthält, die jeder Projektionsrichtung entspricht, die zugeordnete Patches enthält.
Bei dem in 27A gezeigten besonderen Beispiel soll eine Vorrichtung, ein System oder ein Prozess ein selektives Packen von Patches durchführen, wie beispielsweise von den Patches, die in 22 dargestellt sind, basierend auf Projektrichtungen zum Codieren eines gekacheltes codiertes Bildes 2700, das eine Kachel für jede Projektionsrichtung aufweist. Bei einigen Ausführungsformen soll jede Kachel des codierten Bildes 2700 die der Projektionsrichtung zugeordneten Patches enthalten. Beispielsweise soll Tile-1 die Patches für eine erste Projektionsrichtung enthalten, wie bei einem Beispiel für die Projektionsrichtung der in 23 dargestellten Kamera C01.
Bei einigen Ausführungsformen wird selektives Packen von Patches für immersives Video basierend auf den verschiedenen Blickpunkten in einem System durchgeführt, wobei die Patches, die jedem Blickpunkt zugeordnet sind, für eine Kachel in einem codierten Bild ausgewählt werden. 27B ist eine Darstellung des selektiven Packens von Patches in Kacheln entsprechend Gruppen von Projektionsrichtungen gemäß einigen Ausführungsformen. Bei einigen Ausführungsformen werden Kacheln zum selektiven Packen von Patches für jede von mehreren Gruppen von Projektionsrichtungen angewendet. Beispielsweise kann das HEVC-MCTS-Merkmal so angewendet werden, dass ausgewählte Patches für eine Gruppe von Projektionsrichtungen in einer bestimmten bewegungsbeschränkten Kachel umfasst sind. Auf diese Weise können Decoder Kacheln einzeln decodieren, ohne dass das gesamte codierte Bild decodiert werden muss. Beispielsweise können Patches aus jeder Gruppe von Projektionsrichtungen jeweils gepackt und in ihre eigene Kachel codiert werden, wobei das gesamte codierte Bild eine Kachel enthält, die jeder Gruppe von Projektionsrichtungen entspricht, die zugeordnete Patches enthält. Die Gruppen von Projektionsrichtungen können beispielsweise der Darstellung in 25A bis 25D.
Bei dem in 27B gezeigten besonderen Beispiel sollen eine Vorrichtung, ein System oder ein Prozess ein selektives Packen von Patches durchführen, wie beispielsweise von den Patches, die in 22 dargestellt sind, basierend auf Gruppen von Projektionsrichtungen zum Codieren eines gekacheltes codiertes Bildes 2750, das eine Kachel für jede Gruppe von Projektionsrichtungen aufweist. Bei einigen Ausführungsformen soll jede Kachel des codierten Bildes 2750 die der besonderen Gruppe von Projektionsrichtungen zugeordneten Patches enthalten. Beispielsweise soll Tile-1 die Patches für eine erste Gruppe von Projektionsrichtungen enthalten, wie bei einem Beispiel für die Gruppe von Projektionsrichtungen, die in 25A. Auf ähnliche Weise kann Tile-2 Patches für die Gruppe von Projektionsrichtungen enthalten, die in 25B dargestellt ist; Tile-3 kann Patches für die Gruppe von Projektionsrichtungen enthalten, die in 25C dargestellt ist, und Tile-4 kann Patches für die Gruppe von Projektionsrichtungen enthalten, die in 25D dargestellt ist. Ausführungsformen sind jedoch nicht auf diese besondere Anordnung beschränkt und können abweichende Anzahlen und Größen von Kacheln umfassen, die unterschiedliche Gruppen von Projektionsrichtungen darstellen.
28A ist ein Ablaufdiagramm zur Darstellung eines Prozesses zum selektiven Packen von Patches gemäß einigen Ausführungsformen. Bei einigen Ausführungsformen umfasst ein Prozess für immersives Video die Erzeugung von Patches für mehrere Blickpunkte 2810. Der Prozess kann das Erkennen von Verschlüssen und das Erzeugen von Patches für detektierte Verschlüsse umfassen, wie beispielsweise das Erkennen 1707 von Verschlüssen und das Bilden von Patches 1708 entsprechend der Darstellung in 17A. Bei einigen Ausführungsformen umfasst der Prozess die Auswahl von Patches basierend auf der Projektionsrichtung 2815. Bei einigen Ausführungsformen können die Patches basierend auf jeder Projektionsrichtung oder jeder von mehreren Gruppen von Projektionsrichtungen ausgewählt werden, wie z. B. den Gruppen von Projektionsrichtungen, die dargestellt sind in 25A bis 25D. Bei einigen Ausführungsformen sind in den Patches für eine bestimmte Kamera-Projektionsrichtung nur Bereiche umfasst, die von anderen Projektionsrichtungen verdeckt sind.
Bei einigen Ausführungsformen werden die ausgewählten Patches gepackt und in ein oder mehrere codierte Bilder 2820 codiert, wobei die ausgewählten Patches so gepackt werden, dass ein Client einen relevanten Teil der Patches für einen Blickpunkt decodieren kann, statt alle Patches decodieren zu müssen. Bei einigen Ausführungsformen kann das Packen der ausgewählten Patches umfassen:

2822: Packen von Patches für jede Projektionsrichtung in ein separates codiertes Bild,
2824: Packen von Patches für jede Gruppe von Projektionsrichtungen in ein separates codiertes Bild;
2826: Packen der Patches in ein codiertes Bild, aufweisend mehrere Kacheln, wobei jede Kachel Patches für eine der Projektionsrichtungen aufweist; oder
2828: Packen der Patches in ein codiertes Bild, aufweisend mehrere Kacheln, wobei jede Kachel Patches für eine Gruppe von Projektionsrichtungen aufweist.

Bei einigen Ausführungsformen werden das eine codierte Bild oder die mehreren codierten Bilder basierend auf ausgewählten Patches zu einem Client zum Decodieren und Entpacken 2830 bereitgestellt.
28B ist ein Ablaufdiagramm zur Darstellung eines Prozesses zum Decodieren und Entpacken von selektiv gepackten Patches gemäß einigen Ausführungsformen. Ein Prozess, der immersives Video darstellt, umfasst das Empfangen eines codierten Bildes oder mehrerer codierter Bilder, die selektiv gepackte Patches 2850 enthalten. Bei einigen Ausführungsformen können die Patches basierend auf jeder Projektionsrichtung oder jeder von mehreren Gruppen von Projektionsrichtungen ausgewählt werden, wie z. B. den Gruppen von Projektionsrichtungen, die dargestellt sind in 25A bis 25D. Bei einigen Ausführungsformen kann das Packen der ausgewählten Patches umfassen:

2852: Patches für jede Projektionsrichtung, gepackt in ein separates codiertes Bild;
2854: Patches für jede Gruppe von Projektionsrichtungen, gepackt in ein separates codiertes Bild;
2856: Patches in einem codierten Bild, aufweisend mehrere Kacheln, wobei jede Kachel Patches für eine der Projektionsrichtungen aufweist; oder
2858: Patches in einem codierten Bild, aufweisend mehrere Kacheln, wobei jede Kachel Patches für eine Gruppe der Projektionsrichtungen aufweist.

Bei einigen Ausführungsformen werden ein oder mehrere codierte Bilder oder Kacheln von codierten Bildern basierend auf Projektionsrichtungen, die den codierten Bildern oder Kacheln zugeordnet sind, und auf einem aktuellen oder erwarteten Blickpunkt 2860 identifiziert. Bei einigen Ausführungsformen werden das/die identifizierte von ein oder mehreren codierten Bildern oder Kacheln von codierten Bildern decodiert und entpackt 2865. Auf diese Weise wird der für ein Client-System erforderliche Decodierungsumfang im Vergleich zu herkömmlichen Systemen reduziert, indem die Decodierung auf Patches beschränkt wird, die Richtungen nahe dem Blickpunkt zugeordnet sind.
Bei einigen Ausführungsformen umfasst ein Verarbeitungssystem einen oder mehrere Prozessorkerne; und einen Speicher zum Speichern von Daten für immersives Video, wobei die Daten eine Mehrzahl von Patches für eine Mehrzahl von Projektionsrichtungen aufweisen. Das System soll die Patches zum Packen auswählen, wobei die Auswahl der Patches zumindest teilweise darauf basiert, welche der Mehrzahl von Projektionsrichtungen jedem der Patches zugeordnet ist; und das System soll die Patches gemäß der Auswahl der Patches in ein oder mehrere codierte Bilder codieren.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder eine Mehrzahl codierter Bilder auf, wobei jedes der Mehrzahl codierter Bilder Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weist jedes der Mehrzahl codierter Bilder Patches für eine der Mehrzahl von Projektionsrichtungen auf.
Bei einigen Ausführungsformen ist die Mehrzahl von Projektionsrichtungen in eine Mehrzahl von Gruppen von Projektionsrichtungen unterteilt, wobei jede Gruppe von Projektionsrichtungen eine oder mehrere Projektionsrichtungen aufweist und wobei jedes der Mehrzahl von codierten Bildern Patches für eine der Gruppen von Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder ein codiertes Bild auf, das eine Mehrzahl von Kacheln enthält, wobei jede der Mehrzahl von Kacheln Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weist jede der Mehrzahl von Kacheln Patches für eine der Mehrzahl von Projektionsrichtungen auf.
Bei einigen Ausführungsformen ist die Mehrzahl von Projektionsrichtungen in eine Mehrzahl von Gruppen von Projektionsrichtungen unterteilt, wobei jede Gruppe von Projektionsrichtungen eine oder mehrere Projektionsrichtungen aufweist und wobei jede der Mehrzahl von Kacheln Patches für eine der Gruppen von Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen ist jede der Mehrzahl von Kacheln eine bewegungsbeschränkte Kachel in einem bewegungsbeschränkten Kachelsatz (MCTS) mit HEVC (hocheffiziente Videocodierung).
Bei einigen Ausführungsformen sind in den Patches für eine bestimmte Projektionsrichtung nur Bereiche umfasst, die durch andere Projektionsrichtungen der Mehrzahl von Projektionsrichtungen verdeckt werden.
Bei einigen Ausführungsformen soll das System das eine oder die mehreren codierten Bilder einem Client-System zum Decodieren bereitstellen.
Bei einigen Ausführungsformen ist das immersive Video ein 6DoF-Video (6 Freiheitsgrade).
Bei einigen Ausführungsformen umfassen der eine oder die mehreren Prozessorkerne einen oder mehrere Grafikprozessorkerne einer Grafikverarbeitungseinheit (GPU).
Bei einigen Ausführungsformen umfasst ein Client-System einen oder mehrere Prozessorkerne und einen Speicher zum Speichern von Daten für immersives Video. Das Client-System soll ein oder mehrere codierte Bilder empfangen, wobei das eine oder die mehreren codierten Bilder eine Mehrzahl von Patches für eine Mehrzahl von Projektionsrichtungen aufweisen, wobei das eine oder die mehreren codierten Bilder gemäß einer Auswahl der Patches zumindest teilweise basierend darauf codiert werden, welche der Mehrzahl von Projektionsrichtungen jedem der Patches zugeordnet ist; und das Client-System soll eine Teilmenge der Vielzahl von Patches zum Rendern eines Ansichtsfensters decodieren, wobei das Client-System die Teilmenge von Patches aus dem einen oder den mehreren codierten Bildern basierend zumindest teilweise auf einem durch das Client-System zu rendernden Ansichtsfenster auswählen soll.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder eine Mehrzahl codierter Bilder auf, wobei jedes der Mehrzahl codierter Bilder Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weist jedes der Mehrzahl codierter Bilder Patches für eine der Mehrzahl von Projektionsrichtungen auf.
Bei einigen Ausführungsformen ist die Mehrzahl von Projektionsrichtungen in eine Mehrzahl von Gruppen von Projektionsrichtungen unterteilt, wobei jede Gruppe von Projektionsrichtungen eine oder mehrere Projektionsrichtungen aufweist und wobei jedes der Mehrzahl von codierten Bildern Patches für eine der Gruppen von Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder ein codiertes Bild auf, das eine Mehrzahl von Kacheln enthält, wobei jede der Mehrzahl von Kacheln Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weist jede der Mehrzahl von Kacheln Patches für eine der Mehrzahl von Projektionsrichtungen auf.
Bei einigen Ausführungsformen ist die Mehrzahl von Projektionsrichtungen in eine Mehrzahl von Gruppen von Projektionsrichtungen unterteilt, wobei jede Gruppe von Projektionsrichtungen eine oder mehrere Projektionsrichtungen aufweist und wobei jede der Mehrzahl von Kacheln Patches für eine der Gruppen von Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen ist jede der Mehrzahl von Kacheln eine bewegungsbeschränkte Kachel in einem bewegungsbeschränkten Kachelsatz (MCTS) mit HEVC (hocheffiziente Videocodierung).
Bei einigen Ausführungsformen weist ein nicht vorübergehendes rechnerlesbares Speichermedium darauf gespeicherte Daten auf, die Anweisungssequenzen wiedergeben, die bei Ausführung durch einen oder mehrere Prozessoren den einen oder die mehreren Prozessoren veranlassen, Operationen durchzuführen, umfassend das Detektieren eines oder mehrerer Objekte aus einer Mehrzahl von Projektionsrichtungen für immersives Video; das Erzeugen einer Mehrzahl von Patches für die detektierten Objekte; das Auswählen der Mehrzahl von Patches zum Packen basierend zumindest teilweise darauf, welche der Mehrzahl von Projektionsrichtungen jedem der Patches zugeordnet ist; und das Codieren der Patches in ein oder mehrere codierte Bilder gemäß der Auswahl der Patches.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder eine Mehrzahl codierter Bilder auf, wobei jedes der Mehrzahl codierter Bilder Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder ein codiertes Bild auf, das eine Mehrzahl von Kacheln enthält, wobei jede der Mehrzahl von Kacheln Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen sind in den Patches für eine bestimmte Projektionsrichtung nur Bereiche umfasst, die durch andere Projektionsrichtungen der Mehrzahl von Projektionsrichtungen verdeckt werden.
Bei einigen Ausführungsformen umfasst eine Vorrichtung Mittel zum Detektieren eines oder mehrerer Objekte aus einer Mehrzahl von Projektionsrichtungen für immersives Video; Mittel zum Erzeugen einer Mehrzahl von Patches für die detektierten Objekte; Auswählen der Mehrzahl von Patches zum Packen basierend zumindest teilweise darauf, welche der Mehrzahl von Projektionsrichtungen jedem der Patches zugeordnet ist; und Mittel zum Codieren der Patches in ein oder mehrere codierte Bilder gemäß der Auswahl der Patches.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder eine Mehrzahl codierter Bilder auf, wobei jedes der Mehrzahl codierter Bilder Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder ein codiertes Bild auf, das eine Mehrzahl von Kacheln enthält, wobei jede der Mehrzahl von Kacheln Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen sind in den Patches für eine bestimmte Projektionsrichtung nur Bereiche umfasst, die durch andere Projektionsrichtungen der Mehrzahl von Projektionsrichtungen verdeckt werden.
Bei einigen Ausführungsformen umfasst ein Verfahren das Detektieren eines oder mehrerer Objekte aus einer Mehrzahl von Projektionsrichtungen für immersives Video; das Erzeugen einer Mehrzahl von Patches für die detektierten Objekte; das Auswählen der Mehrzahl von Patches zum Packen basierend zumindest teilweise darauf, welche der Mehrzahl von Projektionsrichtungen jedem der Patches zugeordnet ist; und das Codieren der Patches in ein oder mehrere codierte Bilder gemäß der Auswahl der Patches.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder eine Mehrzahl codierter Bilder auf, wobei jedes der Mehrzahl codierter Bilder Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder ein codiertes Bild auf, das eine Mehrzahl von Kacheln enthält, wobei jede der Mehrzahl von Kacheln Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen sind in den Patches für eine bestimmte Projektionsrichtung nur Bereiche umfasst, die durch andere Projektionsrichtungen der Mehrzahl von Projektionsrichtungen verdeckt werden.
Bei einigen Ausführungsformen weist ein nicht vorübergehendes rechnerlesbares Speichermedium darauf gespeicherte Daten auf, die Anweisungssequenzen wiedergeben, die bei Ausführung durch einen oder mehrere Prozessoren den einen oder die mehreren Prozessoren veranlassen, Operationen durchzuführen, umfassend das Empfangen eines oder mehrerer codierter Bilder, wobei das eine oder die mehreren codierten Bilder eine Mehrzahl von Flecken für eine Mehrzahl von Projektionsrichtungen aufweisen, wobei das eine oder die mehreren codierten Bilder gemäß einer Auswahl der Patches codiert werden, basierend zumindest teilweise darauf, welche der Mehrzahl von Projektionsrichtungen mit jedem der Patches assoziiert ist; und das Auswählen einer Teilmenge der Mehrzahl von Patches aus dem einen oder den mehreren codierten Bildern, zumindest teilweise basierend auf einem Ansichtsfenster, das für immersives Video gerendert werden soll; und das Decodieren der Teilmenge der Patches zum Rendern des Ansichtsfensters.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder eine Mehrzahl codierter Bilder auf, wobei jedes der Mehrzahl codierter Bilder Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder ein codiertes Bild auf, das eine Mehrzahl von Kacheln enthält, wobei jede der Mehrzahl von Kacheln Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weist eine Vorrichtung Mittel zum Empfangen eines oder mehrerer codierter Bilder auf, wobei das eine oder die mehreren codierten Bilder eine Mehrzahl von Patches für eine Mehrzahl von Projektionsrichtungen aufweisen, wobei das eine oder die mehreren codierten Bilder gemäß einer Auswahl der Patches codiert werden, basierend zumindest teilweise darauf, welche der Mehrzahl von Projektionsrichtungen jedem der Patches zugeordnet ist; und Mittel zum Auswählen einer Teilmenge der Mehrzahl von Patches aus dem einen oder den mehreren codierten Bildern, basierend zumindest teilweise auf einem Ansichtsfenster, das für immersives Video gerendert werden soll; und zum Decodieren der Teilmenge der Patches zum Rendern des Ansichtsfensters.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder eine Mehrzahl codierter Bilder auf, wobei jedes der Mehrzahl codierter Bilder Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder ein codiertes Bild auf, das eine Mehrzahl von Kacheln enthält, wobei jede der Mehrzahl von Kacheln Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen umfasst ein Verfahren das Empfangen eines oder mehrerer codierter Bilder, wobei das eine oder die mehreren codierten Bilder eine Mehrzahl von Patches für eine Mehrzahl von Projektionsrichtungen umfassen, wobei das eine oder die mehreren codierten Bilder gemäß einer Auswahl der Patches codiert werden, basierend zumindest teilweise darauf, welche der Mehrzahl von Projektionsrichtungen jedem der Patches zugeordnet ist; und das Auswählen einer Teilmenge der Mehrzahl von Patches aus dem einen oder den mehreren codierten Bildern, basierend zumindest teilweise auf einem Ansichtsfenster, das für immersives Video gerendert werden soll; und das Decodieren der Teilmenge der Patches zum Rendern des Ansichtsfensters. Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder eine Mehrzahl codierter Bilder auf, wobei jedes der Mehrzahl codierter Bilder Patches für eine oder mehrere Projektionsrichtungen aufweist.
Bei einigen Ausführungsformen weisen das eine oder die mehreren codierten Bilder ein codiertes Bild auf, das eine Mehrzahl von Kacheln enthält, wobei jede der Mehrzahl von Kacheln Patches für eine oder mehrere Projektionsrichtungen aufweist.
In der vorstehenden Beschreibung werden zum Zweck der Erläuterung zahlreiche spezifische Details angeführt, um ein gründliches Verständnis der beschriebenen Ausführungsformen zu ermöglichen. Es ist jedoch für Fachleute auf diesem Gebiet offensichtlich, dass Ausführungsformen ohne einige dieser spezifischen Details umgesetzt werden können. In anderen Fällen sind bereits bekannte Strukturen und Einrichtungen in Blockdiagrammform gezeigt. Zwischen dargestellten Komponenten kann eine Zwischenstruktur vorliegen. Die hier beschriebenen oder dargestellten Komponenten können zusätzliche Ein- oder Ausgänge aufweisen, die nicht dargestellt oder beschrieben sind.
Verschiedene Ausführungsformen können verschiedene Prozesse aufweisen. Diese Prozesse können von Hardwarekomponenten durchgeführt werden oder in Rechnerprogrammen oder maschinenausführbaren Anweisungen umfasst sein, die verwendet werden können, um einen Prozessor für allgemeine oder spezielle Zwecke oder Logikschaltungen, die mit den Anweisungen programmiert sind, zu veranlassen, die Prozesse durchzuführen. Alternativ dazu können die Prozesse mittels einer Kombination von Hardware und Software durchgeführt werden.
Teile verschiedener Ausführungsformen können als Rechnerprogrammprodukt bereitgestellt werden, das ein rechnerlesbares Medium mit darauf gespeicherten Rechnerprogrammanweisungen aufweisen kann, die verwendet werden können, um einen Rechner (oder andere elektronische Einrichtungen) für die Ausführung durch einen oder mehrere Prozessoren zu programmieren, um einen Prozess gemäß bestimmten Ausführungsformen durchzuführen. Das rechnerlesbare Medium kann ohne diesbezügliche Einschränkung Magnetplatten, optische Platten, Nur-Lese-Speicher (ROM), Direktzugriffsspeicher (RAM), löschbaren programmierbaren Nur-Lese-Speicher (EPROM) und elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM), magnetische oder optische Karten, Flash-Speicher oder einen anderen Typ eines rechnerlesbaren Mediums aufweisen, das zum Speichern elektronischer Anweisungen geeignet ist. Zudem können Ausführungsformen auch als Rechnerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Rechner zu einem anfordernden Rechner übertragen werden kann. Bei einigen Ausführungsformen weist ein nicht vorübergehendes rechnerlesbares Speichermedium darauf gespeicherte Daten auf, die Anweisungssequenzen wiedergeben, die bei Ausführung durch einen Prozessor den Prozessor veranlassen, bestimmte Operationen durchzuführen.
Viele der Verfahren sind in ihrer grundlegendsten Form beschrieben, doch können zu beliebigen der Verfahren Prozesse hinzugefügt oder daraus entfernt werden, und Information kann zu beliebigen der beschriebenen Nachrichten hinzugefügt oder daraus entfernt werden, ohne vom grundlegenden Schutzumfang der vorliegenden Ausführungsformen abzuweichen. Es ist für Fachleute auf diesem Gebiet ersichtlich, dass viele weitere Abänderungen und Anpassungen vorgenommen werden können. Die besonderen Ausführungsformen sind nicht bereitgestellt, um das Konzept einzuschränken, sondern um es zu veranschaulichen. Der Schutzumfang der Ausführungsformen soll nicht durch die vorstehend bereitgestellten spezifischen Beispiele festgelegt werden, sondern nur durch die im Folgenden wiedergegebenen Ansprüche.
Wenn angegeben wird, dass ein Element „A“ an oder mit Element „B“ gekoppelt ist, kann Element A direkt an Element B gekoppelt sein oder indirekt durch beispielsweise Element C gekoppelt sein. Wenn die Beschreibung oder die Ansprüche aussagen, dass eine Komponente, ein Merkmal, eine Struktur, ein Prozess oder eine Eigenschaft A eine Komponente, ein Merkmal, eine Struktur, einen Prozess oder eine Eigenschaft B „veranlassen“, bedeutet dies, dass „A“ mindestens eine Teilursache von „B“ ist, wobei es aber auch mindestens eine andere Komponente, ein anderes Merkmal, eine andere Struktur, einen anderen Prozess oder eine andere Eigenschaft geben kann, die das Veranlassen von „B“ unterstützen. Wenn die Spezifikation angibt, dass eine Komponente, ein Merkmal, eine Struktur, ein Prozess oder eine Eigenschaft „vielleicht“, „eventuell“ oder „möglicherweise“ umfasst sein kann, ist es nicht erforderlich, dass die bestimmte Komponente, das bestimmte Merkmal, die bestimmte Struktur, der bestimmte Prozess oder die bestimmte Eigenschaft umfasst sind. Falls die Spezifikation oder der Anspruch auf „ein“ Element verweist, bedeutet dies nicht, dass nur eines der beschriebenen Elemente vorliegt.
Eine Ausführungsform ist eine Implementierung oder ein Beispiel. Der Verweis in der Spezifikation auf „eine Ausführungsform“, „einige Ausführungsformen“ oder „andere Ausführungsformen“ bedeutet, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, die in Verbindung mit den Ausführungsformen beschrieben sind, in mindestens einigen Ausführungsformen, jedoch nicht notwendigerweise in allen Ausführungsformen, umfasst sind. Die verschiedenen Vorkommnisse von „eine Ausführungsform“ oder „einigen Ausführungsformen“ verweisen nicht notwendigerweise immer auf die gleichen Ausführungsformen. Es versteht sich, dass in der vorstehenden Beschreibung beispielhafter Ausführungsformen verschiedene Merkmale gelegentlich zu einer einzigen Ausführungsform, Figur oder Beschreibung davon zusammengefasst sind, um die Offenbarung zu straffen und das Verständnis eines oder mehrerer der verschiedenen neuartigen Aspekte zu unterstützen. Dieses Offenbarungsverfahren soll jedoch nicht so ausgelegt werden, dass es eine Absicht widerspiegelt, wonach die beanspruchten Ausführungsformen mehr Merkmale erfordern, als in jedem Anspruch ausdrücklich angegeben ist. Vielmehr finden sich, wie die folgenden Ansprüche widerspiegeln, neuartige Aspekte in weniger als allen Merkmalen einer einzelnen vorstehend offenbarten Ausführungsform. Somit werden die Ansprüche hiermit ausdrücklich in diese Beschreibung übernommen, wobei jeder Anspruch für sich als eine separate Ausführungsform gilt.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 16/050153 [0001]

Claims

Verarbeitungssystem, umfassend: einen oder mehrere Prozessorkerne; und einen Speicher zum Speichern von Daten für immersives Video, wobei die Daten eine Mehrzahl von Patches für eine Mehrzahl von Projektionsrichtungen aufweisen, wobei das System die Patches zum Packen auswählen soll, wobei die Auswahl der Patches zumindest teilweise darauf basiert, welche der Mehrzahl von Projektionsrichtungen jedem der Patches zugeordnet ist; und wobei das System die Patches gemäß der Auswahl der Patches in ein oder mehrere codierte Bilder codieren soll.
System nach Anspruch 1, wobei das eine oder die mehreren codierten Bilder eine Mehrzahl codierter Bilder aufweisen, wobei jedes der Mehrzahl codierter Bilder Patches für eine oder mehrere Projektionsrichtungen aufweist.
System nach Anspruch 2, wobei entweder jedes der Mehrzahl codierter Bilder Patches für eine der Mehrzahl von Projektionsrichtungen aufweist; oder die Mehrzahl von Projektionsrichtungen in eine Mehrzahl von Gruppen von Projektionsrichtungen unterteilt ist, wobei jede Gruppe von Projektionsrichtungen eine oder mehrere Projektionsrichtungen aufweist und wobei jedes der Mehrzahl von codierten Bildern Patches für eine der Gruppen von Projektionsrichtungen aufweist.
System nach Anspruch 1, wobei das eine oder die mehreren codierten Bilder ein codiertes Bild aufweisen, das eine Mehrzahl von Kacheln enthält, wobei jede der Mehrzahl von Kacheln Patches für eine oder mehrere Projektionsrichtungen aufweist.
System nach Anspruch 4, wobei jede der Mehrzahl von Kacheln Patches für eine der Mehrzahl von Projektionsrichtungen aufweist.
System nach Anspruch 4, wobei die Mehrzahl von Projektionsrichtungen in eine Mehrzahl von Gruppen von Projektionsrichtungen unterteilt ist, wobei jede Gruppe von Projektionsrichtungen eine oder mehrere Projektionsrichtungen aufweist, und wobei jede der Mehrzahl von Kacheln Patches für eine der Gruppen von Projektionsrichtungen aufweist.
System nach Anspruch 4, wobei jede der Mehrzahl von Kacheln eine bewegungsbeschränkte Kachel in einem bewegungsbeschränkten Kachelsatz (MCTS) mit HEVC (hocheffiziente Videocodierung) ist.
System nach Anspruch 1, wobei in den Patches für eine bestimmte Projektionsrichtung nur Bereiche umfasst sind, die durch andere Projektionsrichtungen der Mehrzahl von Projektionsrichtungen verdeckt werden.
System nach Anspruch 1, wobei das System das eine oder die mehreren codierten Bilder einem Client-System zum Decodieren bereitstellen soll.
System nach Anspruch 1, wobei das immersive Video ein 6DoF-Video (6 Freiheitsgrade) ist.
System nach Anspruch 1, wobei der eine oder die mehreren Prozessorkerne einen oder mehrere Grafikprozessorkerne einer Grafikverarbeitungseinheit (GPU) aufweisen.
Client-System, umfassend: einen oder mehrere Prozessorkerne; und einen Speicher zum Speichern von Daten für immersives Video; wobei das Client-System ein oder mehrere codierte Bilder empfangen soll, wobei das eine oder die mehreren codierten Bilder eine Mehrzahl von Patches für eine Mehrzahl von Projektionsrichtungen aufweisen, wobei das eine oder die mehreren Bilder gemäß einer Auswahl der Patches codiert werden, basierend zumindest teilweise darauf, welche der Mehrzahl von Projektionsrichtungen mit jedem der Patches assoziiert ist; und wobei das Client-System eine Teilmenge der Mehrzahl von Patches zum Rendern eines Ansichtsfensters decodieren soll, wobei das Client-System die Teilmenge von Patches aus dem einen oder den mehreren codierten Bildern zumindest teilweise basierend auf einem durch das vom Client-System zu rendernden Ansichtsfenster auswählen soll.
Client-System nach Anspruch 12, wobei das eine oder die mehreren codierten Bilder eine Mehrzahl codierter Bilder aufweisen, wobei jedes der Mehrzahl codierter Bilder Patches für eine oder mehrere Projektionsrichtungen aufweist.
Client-System nach Anspruch 13, wobei jedes der Mehrzahl von codierten Bildern Patches für eine der Mehrzahl von Projektionsrichtungen aufweist.
Client-System nach Anspruch 13, wobei die Mehrzahl von Projektionsrichtungen in eine Mehrzahl von Gruppen von Projektionsrichtungen unterteilt ist, wobei jede Gruppe von Projektionsrichtungen eine oder mehrere Projektionsrichtungen aufweist und wobei jedes der Mehrzahl von codierten Bildern Patches für eine der Gruppen von Projektionsrichtungen aufweist.
Client-System nach Anspruch 12, wobei das eine oder die mehreren codierten Bilder ein codiertes Bild aufweisen, das eine Mehrzahl von Kacheln enthält, wobei jede der Mehrzahl von Kacheln Patches für eine oder mehrere Projektionsrichtungen aufweist.
Client-System nach Anspruch 16, wobei entweder: jede der Mehrzahl von Kacheln Patches für eine der Mehrzahl von Projektionsrichtungen aufweist; oder die Mehrzahl von Projektionsrichtungen in eine Mehrzahl von Gruppen von Projektionsrichtungen unterteilt ist, wobei jede Gruppe von Projektionsrichtungen eine oder mehrere Projektionsrichtungen aufweist und wobei jede der Mehrzahl von Kacheln Patches für eine der Gruppen von Projektionsrichtungen aufweist.
Client-System nach Anspruch 16, wobei jede der Mehrzahl von Kacheln eine bewegungsbeschränkte Kachel in einem bewegungsbeschränkten Kachelsatz (MCTS) mit HEVC (hocheffiziente Videocodierung) ist.
Rechnerlesbares Speichermedium, aufweisend darauf gespeicherte Daten, die Anweisungssequenzen wiedergeben, die bei Ausführung durch einen oder mehrere Prozessoren den einen oder die mehreren Prozessoren veranlassen, Operationen durchzuführen, umfassend: Detektieren eines oder mehrerer Objekte aus einer Mehrzahl von Projektionsrichtungen für immersives Video; Erzeugen einer Mehrzahl von Patches für die detektierten Objekte; Auswählen der Mehrzahl von Patches zum Packen basierend zumindest teilweise darauf, welche der Mehrzahl von Projektionsrichtungen jedem der Patches zugeordnet ist; und Codieren der Patches gemäß der Auswahl der Patches in ein oder mehrere codierte Bilder.
Medium nach Anspruch 19, wobei das eine oder die mehreren codierten Bilder eine Mehrzahl codierter Bilder aufweisen, wobei jedes der Mehrzahl codierter Bilder Patches für eine oder mehrere Projektionsrichtungen aufweist.
Medium nach Anspruch 19, wobei das eine oder die mehreren codierten Bilder ein codiertes Bild aufweisen, das eine Mehrzahl von Kacheln enthält, wobei jede der Mehrzahl von Kacheln Patches für eine oder mehrere Projektionsrichtungen aufweist.
Medium nach Anspruch 19, wobei in den Patches für eine bestimmte Projektionsrichtung nur Bereiche umfasst sind, die durch andere Projektionsrichtungen der Mehrzahl von Projektionsrichtungen verdeckt werden.
Rechnerlesbares Speichermedium, aufweisend darauf gespeicherte Daten, die Anweisungssequenzen wiedergeben, die bei Ausführung durch einen oder mehrere Prozessoren den einen oder die mehreren Prozessoren veranlassen, Operationen durchzuführen, umfassend: Empfangen von einem oder mehreren codierten Bildern, wobei das eine oder die mehreren codierten Bilder eine Mehrzahl von Patches für eine Mehrzahl von Projektionsrichtungen aufweisen, wobei das eine oder die mehreren Bilder gemäß einer Auswahl der Patches codiert werden, basierend zumindest teilweise darauf, welche der Mehrzahl von Projektionsrichtungen mit jedem der Patches assoziiert ist; Auswählen einer Teilmenge der Mehrzahl von Patches aus dem einen oder den mehreren codierten Bildern, zumindest teilweise basierend auf einem Ansichtsfenster, das für ein immersives Video gerendert werden soll; und Decodieren der Teilmenge der Patches zum Rendern des Ansichtsfensters.
Medium nach Anspruch 23, wobei das eine oder die mehreren codierten Bilder eine Mehrzahl codierter Bilder aufweisen, wobei jedes der Mehrzahl codierter Bilder Patches für eine oder mehrere Projektionsrichtungen aufweist.
Medium nach Anspruch 23, wobei das eine oder die mehreren codierten Bilder ein codiertes Bild aufweisen, das eine Mehrzahl von Kacheln enthält, wobei jede der Mehrzahl von Kacheln Patches für eine oder mehrere Projektionsrichtungen aufweist.