DE102019133561A1

DE102019133561A1 - System und Verfahren zur Detektion von Änderungen gerenderter Szenen mit ferngehosteten Graphikanwendungen

Info

Publication number: DE102019133561A1
Application number: DE102019133561.2A
Authority: DE
Inventors: Tomasz Madajczak; Jaroslaw Motowidlo; James Varga jun.
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-12-07
Filing date: 2019-12-09
Publication date: 2020-06-10
Also published as: US11317098B2; US20200186811A1

Abstract

Eine Vorrichtung und ein Verfahren zum Detektieren von Szenenänderungen unter Verwendung von Datensätzen, die aus einer 3D-Pipeline gesammelt werden. Beispielsweise umfasst eine Ausführungsform einer Vorrichtung eine 3D-Graphikmaschine zum Rendern mehrerer Einzelbilder, die ein aktuelles Einzelbild und ein vorheriges Einzelbild umfassen; und einen Szenenänderungsdetektor zum Abrufen von Datensätzen aus der 3D-Graphikmaschine, wobei die Datensätze dem aktuellen Einzelbild zugeordnet sind, das von der 3D-Graphikmaschine gerendert wird, wobei der Szenenänderungsdetektor die Datensätze im Hinblick auf entsprechende Datensätze aus dem vorherigen Einzelbild analysiert, um einen ersten Codierungstyp zu bestimmen, der zum Codieren des aktuellen Einzelbilds vor der Übertragung über ein Netz verwendet werden soll.

Description

Hintergrund
Gebiet der Erfindung
Diese Erfindung bezieht sich allgemein auf das Gebiet von Graphikprozessoren. Insbesondere bezieht sich die Erfindung auf ein System und ein Verfahren zur Detektion von Änderungen gerenderter Szenen für ferngehostete Graphikanwendungen.
Beschreibung des Standes der Technik
In fern-gestreamten 3D-Spielen wird die Anwendung des 3D-Spiels auf einem Server mit einer Hochleistungs-CPU und -GPU in einem entfernten Rechenzentrum als Antwort auf Steuersignale, die von dem Anwender während des Spiels erzeugt werden (z. B. über einen Game-Controller oder eine Tastatur), verarbeitet und wiedergegeben. Die von der 3D-Maschine erzeugten Einzelbilder werden codiert/komprimiert und über das Internet oder ein proprietäres Netz an Client-Vorrichtungen von Anwendern gestreamt. Ein Nutzer einer CPU/GPU geringer Leistung kann das Spiel mit akzeptablem Anwendererlebnis spielen, da die gesamte betriebsmittelintensive 3D-Arbeit von dem Server ausgeführt wird. Der Client muss nur in der Lage sein, komprimierte Videoströme wie H.264-, H.265-, VP8-, VP9- oder AV1-Videoströme zu decodieren.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung kann aus der folgenden genauen Beschreibung in Verbindung mit den folgenden Zeichnungen erlangt werden.

1 ist ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor mit einem oder mehreren Prozessorkernen und Graphikprozessoren;
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors mit einem oder mehreren Prozessorkernen, einem integrierten Speicher-Controller und einem integrierten Graphikprozessor;
3 ist ein Blockdiagramm einer Ausführungsform eines Graphikprozessors, der eine diskrete Graphikverarbeitungseinheit sein kann oder ein Graphikprozessor sein kann, der in mehrere Verarbeitungskerne integriert ist;
4 ist ein Blockdiagramm einer Ausführungsform einer Graphikverarbeitungsmaschine für einen Graphikprozessor;
5 ist ein Blockdiagramm einer weiteren Ausführungsform eines Graphikprozessors;
6A-6B ein Blockdiagramm einer Strangausführungslogik mit einer Anordnung von Verarbeitungselementen;
7 zeigt ein Graphikprozessor-Ausführungseinheits-Befehlsformat gemäß einer Ausführungsform;
8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Graphikprozessors, der eine Graphikpipeline, eine Medienpipeline, eine Anzeigemaschine, eine Strangausführungslogik und eine Renderausgabepipeline aufweist;
9A ist ein Blockdiagramm, das ein Graphikprozessorbefehlsformat gemäß einer Ausführungsform zeigt;
9B ist ein Blockdiagramm, das eine Graphikprozessorbefehlssequenz gemäß einer Ausführungsform zeigt;
10 zeigt eine beispielhafte Graphiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einer Ausführungsform;
11A-B zeigen ein beispielhaftes IP-Kern-Entwicklungssystem, das verwendet werden kann, um eine integrierte Schaltung zum Durchführen von Operationen gemäß einer Ausführungsform herzustellen;
12 zeigt ein beispielhaftes System auf einer integrierten Chipschaltung, das unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform;
13A-B zeigen einen beispielhaften Graphikprozessor eines Systems auf einer integrierten Chipschaltung, der unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann;
14A-B zeigen einen zusätzlichen beispielhaften Graphikprozessor eines Systems auf einer integrierten Chipschaltung, der unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann;
15 zeigt eine Ausführungsform einer Architektur, auf der Ausführungsformen der Erfindung implementiert werden können;
16 zeigt eine Ausführungsform, die sowohl einen Fuzzy-Logik-Detektor als auch ein neuronales Netz umfasst.
17 zeigt eine Ausführungsform eines neuronalen Zwei-Schicht-Netzes, in dem Neuronen der ersten Schicht Korrelationsfunktionen bestimmter Parameter entsprechen; und
18 zeigt ein Verfahren gemäß einer Ausführungsform der Erfindung.

Genaue Beschreibung
In der folgenden Beschreibung werden zum Zweck der Erläuterung zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der nachstehend beschriebenen Ausführungsformen der Erfindung zu ermöglichen. Es ist jedoch für Fachleute ersichtlich, dass die Ausführungsformen der Erfindung ohne einige dieser spezifischen Einzelheiten ausgeführt werden können. In anderen Fällen sind bekannte Strukturen und Vorrichtungen in Form von Blockdiagrammen gezeigt, um zu vermeiden, dass die zugrundeliegenden Prinzipien der Ausführungsformen der Erfindung verunklart werden.
Beispielhafte Graphikprozessorarchitekturen und Datentypen
Systemüberblick
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. In verschiedenen Ausführungsformen umfasst das System 100 einen oder mehrere Prozessoren 102 und einen oder mehrere Graphikprozessoren 108 und kann ein Einzelprozessor-Desktopsystem, ein Mehrprozessor-Arbeitsplatzsystem oder ein Serversystem mit einer großen Anzahl von Prozessoren 102 oder Prozessorkernen 107 sein. In einer Ausführungsform ist das System 100 eine integrierte Schaltung mit Ein-Chip-System (SOC) für den Einsatz in mobilen, tragbaren oder eingebetteten Vorrichtungen.
In einer Ausführungsform kann das System 100 eine serverbasierte Spiele-Plattform, eine Spielekonsole einschließlich einer Spiele- und Medienkonsole, eine mobile Spielekonsole, eine tragbare Spielekonsole oder eine Online-Spielekonsole umfassen oder darin integriert sein. In einigen Ausführungsformen ist das System 100 ein Mobiltelefon, ein Smartphone, eine Tablet-Rechenvorrichtung oder eine mobile Internetvorrichtung. Das Verarbeitungssystem 100 kann auch eine am Körper tragbare Vorrichtung wie beispielsweise eine Smartwatch, eine intelligente Brillenvorrichtung, eine Vorrichtung für erweiterte Realität oder eine Vorrichtung für virtuelle Realität umfassen, damit gekoppelt sein oder darin integriert sein. In einigen Ausführungsformen ist das Verarbeitungssystem 100 ein Fernseher oder ein Beistellgerät mit einem oder mehreren Prozessoren 102 und einer graphischen Schnittstelle, die von einem oder mehreren Graphikprozessoren 108 erzeugt wird.
In einigen Ausführungsformen umfassen der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107, um Befehle zu verarbeiten, die, wenn sie ausgeführt werden, Operationen für System- und Anwendersoftware durchführen. In einigen Ausführungsformen ist jeder des einen oder der mehreren Prozessorkerne 107 dazu ausgelegt, einen bestimmten Befehlssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Befehlssatz 109 eine Datenverarbeitung mit komplexem Befehlssatz (CISC), eine Datenverarbeitung mit reduziertem Befehlssatz (RISC) oder eine Datenverarbeitung mit sehr langem Befehlswort (VLIW) ermöglichen. Mehrere Prozessorkerne 107 können jeweils einen anderen Befehlssatz 109 verarbeiten, der Befehle enthalten kann, um die Emulation von anderen Befehlssätzen zu ermöglichen. Der Prozessorkern 107 kann zudem andere Verarbeitungsvorrichtungen wie einen Digitalsignalprozessor (DSP) umfassen.
In einigen Ausführungsformen umfasst der Prozessor 102 einen Cache-Speicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Ebenen von internem Cache aufweisen. In einer Ausführungsform wird der Cache-Speicher von den verschiedenen Komponenten des Prozessors 102 gemeinsam verwendet. In einer Ausführungsform verwendet der Prozessor 102 auch einen externen Cache (beispielsweise einen Ebene-3-Cache-Speicher (L3-Cache-Speicher) oder einen Cache der letzten Ebene (LLC)) (nicht gezeigt), der von den Prozessorkernen 107 unter Verwendung bekannter Cache-Kohärenz-Techniken gemeinsam verwendet werden kann. Zusätzlich ist ein Registersatz 106 in dem Prozessor 102 enthalten, der verschiedene Arten von Registern zum Speichern von verschiedenen Arten von Daten enthalten kann (beispielsweise ein Ganzzahlregister, ein Gleitkommaregister, ein Statusregister und ein Befehlszeigerregister). Einige Register können Allzweckregister sein, während andere Register spezifisch für den Entwurf des Prozessors 102 sein können.
In einigen Ausführungsformen sind der eine oder die mehreren Prozessoren 102 mit einem oder mehreren Schnittstellenbussen 110 gekoppelt, um Kommunikationssignale wie Adressen, Daten oder Steuersignale zwischen dem Prozessor 102 und anderen Komponenten in dem System 100 zu übertragen. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus sein, beispielsweise eine Version des Direktmedienschnittstellen-Busses (DMI-Busses). Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheriekomponenten-Zwischenverbindungs-Busse (z. B. PCI, PCI Express), Speicherbusse oder andere Arten von Schnittstellenbussen umfassen. In einer Ausführungsform umfassen die Prozessoren 102 einen integrierten Speicher-Controller 116 und einen Plattform-Controller-Hub 130. Der Speicher-Controller 116 ermöglicht die Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der Plattform-Controller-Hub (PCH) 130 Verbindungen zu E/A-Vorrichtungen über einen lokalen E/A-Bus bietet.
Die Speichervorrichtung 120 kann ein dynamischer Direktzugriffsspeicher (DRAM), ein statischer Direktzugriffsspeicher (SRAM), eine Flash-Speichervorrichtung, eine Phasenwechsel-Speichervorrichtung oder eine andere Speichervorrichtung mit geeignetem Leistungsvermögen, um als Prozessspeicher zu dienen, sein. In einer Ausführungsform kann die Speichervorrichtung 120 als Systemspeicher für das System 100 fungieren, um Daten 122 und Befehle 121 für die Verwendung beim Ausführen eines Prozesses oder einer Anwendung durch den Prozessor 102 zu speichern. Der Speicher-Controller 116 koppelt auch mit einem optionalen externen Graphikprozessor 112, der mit dem einen oder den mehreren Graphikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Graphik- und Medienoperationen durchzuführen. In einigen Ausführungsformen kann eine Anzeigevorrichtung 111 mit dem einen oder mehreren Prozessoren 102 verbunden sein. Die Anzeigevorrichtung 111 kann eine oder mehrere von einer internen Anzeigevorrichtung sein, wie etwa eine mobile elektronische Vorrichtung oder eine Laptop-Vorrichtung oder eine externe Anzeigevorrichtung, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) verbunden ist. In einer Ausführungsform kann die Anzeigevorrichtung 111 eine am Kopf befestigte Anzeige (HMD) wie etwa eine stereoskopische Anzeigevorrichtung zur Verwendung in Anwendungen der virtuellen Realität (VR-Anwendungen) oder Anwendungen der erweiterten Realität (AR-Anwendungen) sein.
In einigen Ausführungsformen ermöglicht es der Plattform-Controller-Hub 130 Peripheriegeräten, eine Verbindung zu der Speichervorrichtung 120 und dem Prozessor 102 über einen Hochgeschwindigkeits-E/A-Bus herzustellen. Die E/A-Peripheriegeräte umfassen einen Audio-Controller 146, einen Netz-Controller 134, eine Firmware-Schnittstelle 128, einen drahtlosen Sendeempfänger 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (z. B. ein Festplattenlaufwerk, Flash-Speicher usw.), ohne darauf beschränkt zu sein. Die Datenspeichervorrichtung 124 kann über eine Speicherschnittstelle (z. B. SATA) oder über einen Peripheriekomponentenbus wie einen Peripheriekomponenten-Zwischenverbindungs-Bus (z. B. PCI, PCI Express) verbunden sein. Die Berührungssensoren 125 können Berührungsschirmsensoren, Drucksensoren oder Fingerabdrucksensoren umfassen. Der drahtlose Sendeempfänger 126 kann ein Wi-Fi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein Mobilfunknetz-Sendeempfänger wie etwa ein 3G-, 4G- oder Langzeitzentwicklungs-Sendeempfänger (LTE-Sendeempfänger) sein. Die Firmware-Schnittstelle 128 ermöglicht die Kommunikation mit System-Firmware und kann beispielsweise eine vereinheitlichte erweiterbare Firmware-Schnittstelle (UEFI) sein. Der Netz-Controller 134 kann eine Netzverbindung zu einem drahtgebundenen Netz ermöglichen. In einigen Ausführungsformen koppelt ein Hochleistungs-Netz-Controller (nicht gezeigt) mit dem Schnittstellenbus 110. Der Audio-Controller 146 ist in einer Ausführungsform ein Mehrkanal-Hochdefinitions-Audio-Controller. In einer Ausführungsform umfasst das System 100 einen optionalen Alt-E/A-Controller 140 zum Koppeln von Alt-Vorrichtungen (z. B. Personal-System-2-Vorrichtungen (PS/2-Vorrichtungen)) an das System. Der Plattform-Controller-Hub 130 kann auch mit einem oder mehreren Controllern des universellen seriellen Busses (USB-Controllern) 142 verbunden sein, um Eingabevorrichtungen wie Kombinationen aus Tastatur und Maus 143, eine Kamera 144 oder andere USB-Eingabevorrichtungen zu verbinden.
Es versteht sich, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, weil andere Typen von Datenverarbeitungssystemen, die anders konfiguriert sind, ebenfalls verwendet werden können. Zum Beispiel kann eine Instanz des Speicher-Controllers 116 und des Plattform-Controller-Hubs 130 in einen diskreten externen Graphikprozessor wie etwa den externen Graphikprozessor 112 integriert sein. In einer Ausführungsform kann sich der Plattform-Controller-Hub 130 und/oder der Speicher-Controller 1160 außerhalb des einen oder der mehreren Prozessoren 102 befinden. Zum Beispiel kann das System 100 einen externen Speicher-Controller 116 und Plattform-Controller-Hub 130 umfassen, der als ein Speicher-Controller-Hub und Peripheriekomponenten-Controller-Hub innerhalb eines System-Chipsatzes, der mit dem einen oder den mehreren Prozessoren 102 in Kommunikation ist, ausgelegt sein kann.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A-202N, einem integrierten Speicher-Controller 214 und einem integrierten Graphikprozessor 208. Die Elemente von 2 mit den gleichen Bezugszeichen (oder Namen) wie die Elemente von irgendeiner anderen Figur hierin können auf eine Art und Weise arbeiten oder funktionieren, die der an anderer Stelle hierin beschriebenen ähnlich ist, sind jedoch nicht darauf beschränkt. Der Prozessor 200 kann zusätzliche Kerne bis zu und einschließlich des zusätzlichen Kerns 202N umfassen, die durch die gestrichelten Kästen dargestellt sind. Jeder der Kerne 202A-202N umfasst eine oder mehrere interne Cache-Einheiten 204A-204N. In einer Ausführungsform hat jeder Kern auch auf eine oder mehrere gemeinsam genutzte Cache-Einheiten 206 Zugriff.
Die internen Cache-Einheiten 204A-204N und die gemeinsamen Cache-Einheiten 206 stellen eine Cache-Speicherhierarchie innerhalb des Prozessors 200 dar. Die Cache-Speicherhierarchie kann mindestens eine Ebene eines Befehls- und Daten-Caches in jedem Kern und eine oder mehrere Ebenen von mehrere Caches einer mittleren Ebene wie z. B. Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder Caches anderer Ebenen umfassen, wobei die höchste Ebene des Caches vor dem externen Speicher als der LLC klassifiziert ist. In einigen Ausführungsformen hält eine Cache-Kohärenz-Logik die Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A-204N aufrecht.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von einem oder mehreren Bus-Controllereinheiten 216 und einen Systemagentenkern 210 umfassen. Der eine oder die mehreren Bus-Controllereinheiten 216 verwalten einen Satz von Peripheriebussen wie etwa einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 210 bietet Verwaltungsfunktionen für die verschiedenen Prozessorkomponenten. In einigen Ausführungsformen umfasst der Systemagentenkern 210 einen oder mehrere integrierte Speicher-Controller 214, die den Zugriff auf verschiedene externe Speichervorrichtungen (nicht gezeigt) verwalten.
In einigen Ausführungsformen weisen ein oder mehrere der Kerne 202A-202N eine Unterstützung für simultane Mehrsträngigkeit auf. In solchen Ausführungsformen umfasst der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A-202N während der Mehrstrangverarbeitung. Der Systemagentenkern 210 kann zusätzlich eine Leistungssteuereinheit (PCU) umfassen, die Logik und die Komponenten enthält, um den Leistungsaufnahmezustand der Kerne 202A-202N und des Graphikprozessors 208 zu regulieren.
In einigen Ausführungsformen umfasst der Prozessor 200 zusätzlich einen Graphikprozessor 208, um Graphikverarbeitungsoperationen auszuführen. In einigen Ausführungsformen ist der Graphikprozessor 208 mit dem Satz von gemeinsam genutzten Cache-Einheiten 206 und dem Systemagentenkern 210 einschließlich des einen oder der mehreren integrierten Speicher-Controller 214 gekoppelt. In einigen Ausführungsformen umfasst der Systemagentkern 210 außerdem einen Anzeige-Controller 211, um die Graphikprozessorausgabe an eine oder mehrere gekoppelte Anzeigen zu auszugeben. Der Anzeige-Controller 211 kann in einigen Ausführungsformen ein separates Modul sein, das mit dem Graphikprozessor über mindestens eine Zwischenverbindung gekoppelt ist, oder kann in den Graphikprozessor 208 integriert sein.
In einigen Ausführungsformen wird eine ringbasierte Zwischenverbindungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu verbinden, jedoch kann eine alternative Zwischenverbindungseinheit wie beispielsweise eine Punkt-zu-Punkt-Zwischenverbindung, eine geschaltete Zwischenverbindung oder andere Techniken, einschließlich Techniken, die im Stand der Technik gut bekannt sind, verwendet werden. In einigen Ausführungsformen ist der Graphikprozessor 208 mit der Ringzwischenverbindung 212 über einen E/A-Link 213 gekoppelt.
Der beispielhafte E/A-Link 213 stellt mindestens eine von mehreren Arten von E/A-Zwischenverbindungen dar, darunter eine Paket-E/A-Zwischenverbindung, die die Kommunikation zwischen verschiedenen Prozessorkomponenten ermöglicht, und ein eingebettetes Hochleistungs-Speichermodul 218 wie etwa ein eDRAM-Modul. In einigen Ausführungsformen verwenden jeder der Kerne 202-N und der Graphikprozessor 208 die eingebetteten Speichermodule 218 als gemeinsamen Cache der letzten Ebene.
In einigen Ausführungsformen sind die Kerne 202A-202N homogene Kerne, die die gleiche Befehlssatzarchitektur ausführen. In einer weiteren Ausführungsform sind die Kerne 202A-202N heterogen in Bezug auf die Befehlssatzarchitektur (ISA), wobei einer oder mehrere der Kerne 202A-202N einen ersten Befehlssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Befehlssatzes oder einen anderen Befehlssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Mikroarchitektur heterogen, wobei ein oder mehrere Kerne mit einer relativ höheren Leistungsaufnahme mit einem oder mehreren Leistungskernen mit einer geringeren Leistungsaufnahme gekoppelt sind. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte Schaltung mit Ein-Chip-System (SOC) mit den dargestellten Komponenten zusätzlich zu den anderen Komponenten implementiert sein.
3 ist ein Blockdiagramm eines Graphikprozessors 300, der eine diskrete Graphikverarbeitungseinheit sein kann oder ein Graphikprozessor sein kann, der in mehrere Prozessorkerne integriert ist. In einigen Ausführungsformen kommuniziert der Graphikprozessor über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Graphikprozessor und über Befehle, die in dem Prozessorspeicher platziert sind. In einigen Ausführungsformen umfasst der Graphikprozessor 300 eine Speicherschnittstelle 314, um auf den Speicher zuzugreifen. Die Speicherschnittstelle 314 kann eine Schnittstelle zu lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam genutzten externen Caches und/oder zu Systemspeicher sein.
In einigen Ausführungsformen umfasst der Graphikprozessor 300 zudem einen Anzeige-Controller 302, um Anzeigeausgabedaten an eine Anzeigevorrichtung 320 zu auszugeben. Der Anzeige-Controller 302 umfasst Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und die Komposition von mehreren Schichten von Video- oder Anwenderschnittstellenelementen. Die Anzeigevorrichtung 320 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 320 eine am Kopf angebrachte Anzeigevorrichtung wie etwa eine Anzeigevorrichtung für virtuelle Realität (VR-Anzeigevorrichtung) oder eine Anzeigevorrichtung für erweiterte Realität (AR-Anzeigevorrichtung). In einer Ausführungsform umfasst der Graphikprozessor 300 eine Video-Codec-Maschine 306 zum Codieren, Decodieren oder Transcodieren von Medien in, aus oder zwischen einen oder mehreren Mediencodierungsformaten, einschließlich, aber nicht beschränkt auf, Formate der Expertengruppe für bewegte Bilder (MPEG) wie MPEG-2, Fortgeschrittene Videcodierformate (AVC) wie H.264/MPEG-4 AVC sowie Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und Formate der gemeinsamen Photographieexpertengruppe (JPEG) wie JPEG und Motion JPEG (MJPEG).
In einigen Ausführungsformen umfasst der Graphikprozessor 300 eine Blockbildübertragungs-Maschine (BLIT-Maschine) 304, um zweidimensionale (2D) Rasterungs-Operationen, die beispielsweise Bitgrenzen-Blockübertragungen umfassen, durchzuführen. Jedoch werden in einer Ausführungsform 2D-Graphikoperationen unter Verwendung einer oder mehrerer Komponenten der Graphikverarbeitungsmaschine (GPE) 310 durchgeführt. In einigen Ausführungsformen ist die GPE 310 eine Rechenmaschine zum Ausführen von Graphikoperationen, die dreidimensionale Graphikoperationen (3D-Graphikoperationen) und Medienoperationen umfassen.
In einigen Ausführungsformen umfasst die GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen wie etwa dem Rendern dreidimensionaler Bilder und Szenen unter Verwendung von Verarbeitungsfunktionen, die mit 3D-Grundformen (z. B. Rechteck, Dreieck usw.) arbeiten. Die 3D-Pipeline 312 umfasst programmierbare und feste Funktionselemente, die verschiedene Aufgaben innerhalb des Elements erfüllen und/oder Ausführungsstränge zu einem 3D/Medien-Teilsystem 315 erzeugen. Obwohl die 3D-Pipeline 312 verwendet werden kann, um Medienoperationen auszuführen, umfasst eine Ausführungsform der GPE 310 auch eine Medienpipeline 316, die speziell verwendet wird, um Medienoperationen wie beispielsweise Videonachbearbeitung und Bildverbesserung durchzuführen.
In einigen Ausführungsformen umfasst die Medienpipeline 316 Logikeinheiten, die eine feste Funktion aufweisen oder programmierbar sind, um eine oder mehrere spezialisiertere Medienoperationen wie eine Videodecodierbeschleunigung, eine Videoentschachtelung und eine Videocodierbeschleunigung anstelle oder im Auftrag der Videocodec-Maschine 306 durchzuführen. In einigen Ausführungsformen umfasst die Medienpipeline 316 zusätzlich eine Strangerzeugungseinheit zum Erzeugen von Strängen für die Ausführung auf dem 3D/Medien-Teilsystem 315. Die erzeugten Stränge führen Berechnungen für die Medienoperationen auf einer oder mehreren Graphikausführungseinheiten in dem 3D/Medien-Teilsystem aus.
In einigen Ausführungsformen umfasst das 3D/Medien-Teilsystem 315 eine Logik zum Ausführen von Strängen, die von der 3D-Pipeline 312 und der Medienpipeline 316 erzeugt werden. In einer Ausführungsform senden die Pipelines Strangausführungsanforderungen an das 3D/Medien-Teilsystem 315, das eine Strangabfertigungslogik zum Zuteilen und Entsenden der verschiedenen Anforderungen an verfügbare Strangausführungsbetriebsmittel umfasst. Die Ausführungsbetriebsmittel umfassen eine Anordnung von Graphikausführungseinheiten, um die 3D- und Medien-Stränge zu verarbeiten. In einigen Ausführungsformen umfasst das 3D/Medien-Teilsystem 315 einen oder mehrere interne Caches für Strangbefehle und -daten. In einigen Ausführungsformen umfasst das Teilsystem zudem einen gemeinsamen Speicher, der Register und adressierbaren Speicher umfasst, um Daten zwischen Strängen zu teilen und Ausgabedaten zu speichern.
Graphikverarbeitungsmaschine
4 ist ein Blockdiagramm einer Graphikverarbeitungsmaschine 410 für einen Graphikprozessor gemäß einigen Ausführungsformen. In einer Ausführungsform ist die Graphikverarbeitungsmaschine (GPE) 410 eine Version der GPE 310, die in 3 gezeigt ist. Elemente von 4 mit den gleichen Bezugszeichen (oder Namen) wie die Elemente irgendeiner anderen Figur hierin können auf eine Art und Weise arbeiten oder funktionieren, die der an anderer Stelle hierin beschriebenen ähnlich ist, sind jedoch nicht darauf beschränkt. Beispielsweise sind die 3D-Pipeline 312 und die Medienpipeline 316 von 3 dargestellt. Die Medienpipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und kann nicht explizit in der GPE 410 enthalten sein. Beispielsweise und in mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
In einigen Ausführungsformen ist die GPE 410 mit einem Befehls-Streamer 403 gekoppelt, der einen Befehlsstrom für die 3D-Pipeline 312 und/oder die Medienpipelines 316 liefert. In einigen Ausführungsformen ist der Befehls-Streamer 403 mit einem Speicher, der ein Systemspeicher sein kann, oder einem oder mehreren des internen Cache-Speichers und des gemeinsam genutzten Cache-Speichers gekoppelt. In einigen Ausführungsformen empfängt der Befehls-Streamer 403 Befehle von dem Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medienpipeline 316. Die Befehle sind Anweisungen, die aus einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 312 und die Medienpipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Stapelbefehlspuffer enthalten, die Stapel von mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Verweise auf Daten enthalten, die im Speicher gespeichert sind, wie beispielsweise Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medienpipeline 316, ohne darauf beschränkt zu sein. Die 3D-Pipeline 312 und die Medienpipeline 316 verarbeiten die Befehle und Daten durch Ausführen von Operationen über Logik in den jeweiligen Pipelines oder durch Versenden eines oder mehrerer Ausführungsstränge an eine Graphikkernanordnung 414. In einer Ausführungsform enthält die Graphikkernanordnung 414 einen oder mehrere Blöcke von Graphikkernen (z. B. Graphikkern(e) 415A, Graphikkern(e) 415B), wobei jeder Block einen oder mehrere Graphikkerne enthält. Jeder Graphikkern enthält eine Reihe von Graphikausführungsbetriebsmitteln, die allgemeine und graphikspezifische Ausführungslogik zum Ausführen von Graphik- und Rechenoperationen sowie Texturverarbeitung mit festen Funktionen und/oder maschinelles Lernen und Beschleunigungslogik für künstliche Intelligenz umfassen.
In verschiedenen Ausführungsformen umfasst die 3D-Pipeline 312 eine Logik mit fester Funktion oder eine programmierbare Logik zum Verarbeiten eines oder mehrerer Schattierer-Programme wie z. B. Vertex-Schattierer, Geometrie-Schattierer, Pixel-Schattierer, Fragment-Schattierer, Rechen-Schattierer oder andere Schattierer-Programme, indem sie die Befehle verarbeitet und Ausführungsstränge an die Graphikkernanordnung 414 absendet. Die Graphikkernanordnung 414 stellt einen vereinheitlichten Block von Ausführungsbetriebsmitteln für die Verarbeitung dieser Schattierer-Programme bereit. Die Mehrzweckausführungslogik (z. B. Ausführungseinheiten) innerhalb des einen oder der mehreren Graphikkerne 415A-414B der Graphikkernanordnung 414 umfasst die Unterstützung verschiedener 3D-API-Schattierer-Sprachen und kann mehrere gleichzeitige Ausführungsstränge, die mehreren Schattierern zugeordnet sind, ausführen.
In einigen Ausführungsformen umfasst die Graphikkernanordnung 414 auch eine Ausführungslogik zum Ausführen von Medienfunktionen wie z. B. Video- und/oder Bildverarbeitung. In einer Ausführungsform umfassen die Ausführungseinheiten zusätzlich eine Allzwecklogik, die programmierbar ist, um zusätzlich zu Graphikverarbeitungsoperationen parallele Allzweck-Rechenoperationen durchzuführen. Die Allzwecklogik kann Verarbeitungsoperationen parallel oder in Verbindung mit der Allzwecklogik innerhalb des Prozessorkerns (der Prozessorkerne) 107 von 1 oder des Kerns 202A-202N wie in 2 ausführen.
Ausgabedaten, die von Strängen erzeugt werden, die auf der Graphikkernanordnung 414 ausgeführt werden, können Daten an einen Speicher in einem vereinheitlichten Rückgabepuffer (URB) 418 ausgeben. Der URB 418 kann Daten für mehrere Stränge speichern. In einigen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen verschiedenen auf der Graphikkernanordnung 414 ausgeführten Strängen zu senden. In einigen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisation zwischen Strängen auf der Graphikkernanordnung und für die Logik fester Funktionen innerhalb der gemeinsam genutzten Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist die Graphikkernanordnung 414 basierend auf der gewünschten Leistungsaufnahme und Rechenleistung der GPE 410 so skalierbar, dass die Anordnung eine variable Anzahl von Graphikkernen enthält, die jeweils eine variable Anzahl von Ausführungseinheiten aufweisen. Ausführungsbetriebsmittel sind in einer Ausführungsform dynamisch skalierbar, so dass Ausführungsbetriebsmittel nach Bedarf aktiviert oder deaktiviert werden können.
Die Graphikkernanordnung 414 ist mit einer gemeinsam genutzten Funktionslogik 420 gekoppelt, die mehrere Betriebsmittel aufweist, die unter den Graphikkernen in der Graphikkernanordnung gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen innerhalb der gemeinsam genutzten Funktionslogik 420 sind Hardwarelogikeinheiten, die für das Graphikkernanordnung 414 eine spezialisierte Zusatzfunktionalität bereitstellen. In verschiedenen Ausführungsformen umfasst die gemeinsam genutzte Funktionslogik 420 einen Abtaster 421, Mathematik 422 und eine Zwischenstrangkommunikations-Logik (ITC-Logik) 423, ist jedoch nicht darauf beschränkt. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Caches 425 in der gemeinsam genutzten Funktionslogik 420.
Eine gemeinsam genutzte Funktion wird implementiert, wenn der Bedarf an einer bestimmten spezialisierten Funktion für die Aufnahme in die Graphikkernanordnung 414 unzureichend ist. Stattdessen wird eine einzelne Instanz der spezialisierten Funktion ist als eigenständige Einheit in der gemeinsam genutzten Funktionslogik 420 implementiert und wird von den Ausführungsbetriebsmitteln innerhalb der Graphikkernanordnung 414 gemeinsam genutzt. Der genaue Satz von Funktionen, die unter der Graphikkernanordnung 414 gemeinsam genutzt werden und in der Graphikkernanordnung 414 enthalten sind, variiert zwischen Ausführungsformen. In einigen Ausführungsformen können bestimmte gemeinsam genutzte Funktionen in der gemeinsam genutzten Funktionslogik 420, die in großem Umfang von der Graphikkernanordnung 414 verwendet werden, in der gemeinsam genutzten Funktionslogik 416 in der Graphikkernanordnung 414 enthalten sein. In verschiedenen Ausführungsformen kann die gemeinsam genutzte Funktionslogik 416 in der Graphikkernanordnung 414 einen Teil oder die gesamte Logik innerhalb der gemeinsam genutzten Funktionslogik 420 umfassen. In einer Ausführungsform können alle Logikelemente innerhalb der gemeinsam genutzten Funktionslogik 420 innerhalb der gemeinsam genutzten Funktionslogik 416 der Graphikkernanordnung 414 dupliziert sein. In einer Ausführungsform ist die gemeinsam genutzte Funktionslogik 420 zugunsten der gemeinsam genutzten Funktionslogik 416 innerhalb der Graphikkernanordnung 414 weggelassen.
5 ist ein Blockdiagramm von Hardwarelogik eines Graphikprozessorkerns 500 gemäß einigen hierin beschriebenen Ausführungsformen. Elemente von 5, die die gleichen Bezugszeichen (oder Namen) wie die Elemente von irgendeiner anderen Figur hierin aufweisen, können auf eine beliebige Art und Weise, die mit der an einer anderen Stelle hierin beschriebenen vergleichbar ist, wirken oder funktionieren, ohne darauf beschränkt zu sein. Der veranschaulichte Graphikprozessorkern 500 ist in einigen Ausführungsformen innerhalb der Graphikkernanordnung 414 von 4 enthalten. Der Graphikprozessorkern 500, der gelegentlich als ein Kern-Slice bezeichnet wird, kann ein oder mehrere Graphikkerne innerhalb eines modularen Graphikprozessors sein. Der Graphikprozessorkern 500 ist beispielhaft für einen Graphikkern-Slice und ein hierin beschriebener Graphikprozessor kann mehrere Graphikkern-Slices basierend auf gewünschten Leistungsaufnahme- und Rechenleistungshüllkurven umfassen. Jeder Graphikprozessorkern 500 kann einen Block mit fester Funktion 530 umfassen, der mit mehreren Teilkernen 501A-501F gekoppelt ist, die auch als Unter-Slices bezeichnet werden, die modulare Blöcke von Universallogik und Logik mit fester Funktion umfassen.
In einigen Ausführungsformen umfasst der Block mit fester Funktion 530 eine Geometrie-Pipeline/Pipeline mit fester Funktion 536, die von allen Teilkernen in dem Graphikprozessorkern 500 gemeinsam genutzt werden kann, beispielsweise in Graphikprozessorimplementierungen mit niedrigerer Rechenleistung und/oder mit niedrigerer Leistungsaufnahme. In verschiedenen Ausführungsformen umfasst die Geometrie-Pipeline/Pipeline mit fester Funktion 536 eine 3D-Pipeline mit fester Funktion (z. B. die 3D-Pipeline 312 wie in 3 und 4), eine Video-Frontend-Einheit, einen Strangersteller und Strangabfertiger und einen Manager eines vereinheitlichten Rücklaufpuffers, der vereinheitlichte Rücklaufpuffer wie den vereinheitlichten Rücklaufpuffer 418 von 4 verwaltet.
In einer Ausführungsform umfasst der Block mit fester Funktion 530 zudem eine Graphik-SoC-Schnittstelle 537, einen Graphikmikrocontroller 538 und eine Medienpipeline 539. Die Graphik-SoC-Schnittstelle 537 stellt eine Schnittstelle zwischen dem Graphikprozessorkern 500 und anderen Prozessorkernen innerhalb einer integrierten Schaltung eines Ein-Chip-Systems bereit. Der Graphikmikrocontroller 538 ist ein programmierbarer Unterprozessor, der konfigurierbar ist, um verschiedene Funktionen des Graphikprozessorkerns 500 einschließlich Strangabfertigung, Planung und Vorwegnahme zu verwalten. Die Medienpipeline 539 (z. B. die Medienpipeline 316 von 3 und 4) umfasst Logik zum Unterstützen des Decodierens, Codierens, Vorverarbeitens und/oder Nachverarbeitens von Multimedia-Daten einschließlich Bild- und Videodaten. Die Medienpipeline 539 implementiert Medienoperationen über Anforderungen zum Berechnen oder Abtasten von Logik innerhalb der Teilkerne 501-501F.
In einer Ausführungsform ermöglicht es die SoC-Schnittstelle 537 dem Graphikprozessorkern 500, mit Universalanwendungsprozessorkernen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC einschließlich Speicherhierarchie-Elementen wie einem gemeinsam genutzten Cache-Speicher letzter Ebene, dem System-RAM und/oder eingebettetem DRAM auf dem Chip oder in der Baugruppe zu kommunizieren. Die SoC-Schnittstelle 537 kann auch eine Kommunikation mit Vorrichtungen mit fester Funktion innerhalb des SoC wie etwa Kamera-Bildgebungs-Pipelines ermöglichen und ermöglicht die Verwendung von globalen Speicheratomen, die zwischen dem Graphikprozessorkern 500 und CPUs innerhalb des SoC geteilt werden können, und/oder implementiert diese. Die SoC-Schnittstelle 537 kann auch Leistungsverwaltungssteuerungen für den Graphikkern 500 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Graphikprozessorkerns 500 und anderen Taktdomänen innerhalb des SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 den Empfang von Befehlspuffern von einem Befehls-Streamer und globalen Strangabfertiger, die dazu ausgelegt sind, Befehle und Anweisungen zu jedem von einem oder mehreren Graphikkernen innerhalb eines Graphikprozessors zu liefern. Die Befehle und Anweisungen können zu der Medienpipeline 539 gesendet werden, wenn Medienoperationen durchzuführen sind, oder zu einer Geometrie-Pipeline und Pipeline mit fester Funktion (z. B. der Geometrie-Pipeline und Pipeline mit fester Funktion 536, der Geometrie-Pipeline und Pipeline mit fester Funktion 514) gesendet werden, wenn Graphikverarbeitungsoperationen durchzuführen sind.
Der Graphikmikrocontroller 538 kann dazu ausgelegt sein, verschiedene Planungs- und Verwaltungsaufgaben für den Graphikprozessorkern 500 durchzuführen. In einer Ausführungsform kann der Graphikmikrocontroller 538 eine Graphik- und/oder Rechenarbeitslastplanung bei den verschiedenen parallelen Graphikmaschinen innerhalb der Ausführungseinheitsanordnungen (EU-Anordnungen) 502A-502F, 504A-504F innerhalb der Teilkerne 501A-501F durchführen. In diesem Planungsmodell kann Host-Software, die auf einem CPU-Kern eines SoC ausgeführt wird, das den Graphikprozessorkern 500 umfasst, Arbeitslasten eine von mehreren Graphikprozessor-Türklingeln übermitteln, wodurch eine Planungsoperation auf der geeigneten Graphikmaschine aufgerufen wird. Planungsoperationen umfassen ein Bestimmen, welche Arbeitslast als Nächstes ausgeführt wird, ein Übermitteln einer Arbeitslast an einen Befehls-Streamer, ein Vorwegnehmen vorhandener Arbeitslasten, die auf einer Maschine ausgeführt werden, ein Überwachen des Fortschritts einer Arbeitslast und ein Benachrichtigen von Host-Software, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Graphikmikrocontroller 538 auch Zustände mit niedrigem Leistungsaufnahme oder Ruhezustände für den Graphikprozessorkern 500 unterstützen, wodurch dem Graphikprozessorkern 500 die Fähigkeit gegeben wird, Register innerhalb des Graphikprozessorkerns 500 über Übergänge von Zuständen mit niedriger Leistungsaufnahme hinweg unabhängig von dem Betriebssystem und/oder der Graphiktreibersoftware auf dem System zu speichern und wiederherzustellen.
Der Graphikprozessorkern 500 kann mehr oder weniger als die veranschaulichten Teilkerne 501A-501F, bis zu N modulare Teilkerne, aufweisen. Für jeden Satz von N Teilkernen kann der Graphikprozessorkern 500 auch gemeinsam genutzte Funktionslogik 510, gemeinsam genutzten und/oder Cache-Speicher 512, eine Geometrie-Pipeline/Pipeline mit fester Funktion 514 sowie zusätzliche Logik mit fester Funktion 516 zum Beschleunigen verschiedener Graphik- und Rechenverarbeitungsoperationen umfassen. Die gemeinsam genutzte Funktionslogik 510 kann Logikeinheiten umfassen, die mit der gemeinsam genutzten Funktionslogik 420 von 4 (z. B. Abtaster-, Mathematik- und/oder Zwischenstrangkommunikations-Logik) verbunden sind und die von allen N Teilkernen innerhalb des Graphikprozessorkerns 500 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 512 kann ein Cache letzter Ebene für den Satz von N Teilkernen 501A-501F innerhalb des Graphikkerns 500 sein und kann auch als gemeinsam genutzter Speicher dienen, der mehreren Teilkernen zugänglich ist. Die Geometrie-Pipeline/Pipeline mit fester Funktion 514 kann anstelle der Geometrie-Pipeline/Pipeline mit fester Funktion 536 innerhalb des Blocks mit fester Funktion 530 enthalten sein und kann die gleichen oder ähnliche Logikeinheiten umfassen.
In einer Ausführungsform umfasst der Graphikprozessorkern 500 eine zusätzliche Logik mit fester Funktion 516, die verschiedene Beschleunigungslogik mit fester Funktion zur Verwendung durch den Graphikprozessorkern 500 umfassen kann. In einer Ausführungsform umfasst die zusätzliche Logik mit fester Funktion 516 eine zusätzliche Geometrie-Pipeline zur Verwendung bei Nur-Positions-Schattierung. Bei Nur-Positions-Schattierung sind zwei Geometrie-Pipelines vorhanden, die vollständige Geometrie-Pipeline innerhalb der Geometrie-Pipeline/Pipeline mit fester Funktion 516, 536 und eine Ausschuss-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die innerhalb der zusätzlichen Logik mit fester Funktion 516 enthalten sein kann. In einer Ausführungsform ist die Ausschuss-Pipeline eine gekürzte Version der vollständigen Geometrie-Pipeline. Die vollständige Pipeline und die Ausschuss-Pipeline können verschiedene Instanzen der gleichen Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Nur-Positions-Schattierung kann lange Ausschuss-Läufe von verworfenen Dreiecken verbergen, wodurch es ermöglicht wird, dass die Schattierung in einigen Fällen früher abgeschlossen wird. Zum Beispiel und in einer Ausführungsform kann die Ausschuss-Pipeline-Logik innerhalb der zusätzlichen Logik mit fester Funktion 516 Positions-Schattierer parallel zu der Hauptanwendung ausführen, und sie erzeugt allgemein kritische Ergebnisse schneller als die vollständige Pipeline, da die Ausschuss-Pipeline nur das Positionsattribut der Vertices abruft und schattiert, ohne eine Rasterung und ein Rendern der Pixel in den Einzelbildspeicher durchzuführen. Die Ausschuss-Pipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke unabhängig davon zu berechnen, ob diese Dreiecke aussortiert werden. Die vollständige Pipeline (die in diesem Fall als eine Replay-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verbrauchen, um die aussortierten Dreiecke zu überspringen, um nur die sichtbaren Dreiecke zu schattieren, die letztlich an die Rasterungsphase übergeben werden.
In einer Ausführungsform kann die zusätzliche Logik mit fester Funktion 516 auch Beschleunigungslogik für maschinelles Lernen wie Matrixmultiplikationslogik mit fester Funktion für Implementierungen, die Optimierungen für Training und Inferenz für maschinelles Lernen beinhalten, umfassen.
Innerhalb jedes Graphikteilkerns 501A-501F ist ein Satz von Ausführungsbetriebsmitteln enthalten, die verwendet werden können, um Graphik-, Medien- und Rechenoperationen als Antwort auf Anforderungen von einer Graphik-Pipeline, einer Medienpipeline oder Schattiererprogrammen durchzuführen. Die Graphikteilkerne 501A-501F umfassen mehrere EU-Anordnungen 502A-502F, 504A-504F, Strangabfertigungs- und Zwischenstrangkommunikations-Logik (TD/IC-Logik) 503A-503F, einen 3D-Abtaster (z. B. Textur-Abtaster) 505A-505F, einen Medienabtaster 506A-506F, einen Schattierer-Prozessor 507A-507F und einen gemeinsam genutzten lokalen Speicher (SLM) 508A-508F. Die EU-Anordnungen 502A-502F, 504A-504F umfassen jeweils mehrere Ausführungseinheiten, die Universalgraphikverarbeitungseinheiten sind, die dazu in der Lage sind, logische Gleitkomma- und Ganzzahl-/Festkommaoperationen für eine Graphik-, Medien- oder Rechenoperation einschließlich Graphik-, Medien- oder Rechen-Schattierer-Programmen durchzuführen. Die TD/IC-Logik 503A-503F führt lokale Strangabfertigungs- und Strangsteuerungsoperationen für die Ausführungseinheiten innerhalb eines Teilkerns durch und unterstützt eine Kommunikation zwischen Strängen, die auf den Ausführungseinheiten des Teilkerns ausgeführt werden. Der 3D-Abtaster 505A-505F kann Texturdaten oder andere auf 3D-Graphik bezogene Daten in einen Speicher lesen. Der 3D-Abtaster kann Texturdaten basierend auf einem konfigurierten Abtastzustand und dem Texturformat, das einer gegebenen Textur zugeordnet ist, verschieden lesen. Der Medienabtaster 506A-506F kann ähnliche Leseoperationen basierend auf dem Typ und Format, der bzw. das Mediendaten zugeordnet ist, durchführen. In einer Ausführungsform kann jeder Graphikteilkern 501A-501F abwechselnd einen vereinheitlichten 3D- und Medienabtaster umfassen. Stränge, die auf den Ausführungseinheiten innerhalb jedes der Teilkerne 501A-501F ausgeführt werden, können den gemeinsam genutzten lokalen Speicher 508A-508F innerhalb jedes Teilkerns verwenden, um es Strängen, die innerhalb einer Strang-Gruppe ausgeführt werden, zu ermöglichen, unter Verwendung eines gemeinsamen Pools von chipinternem Speicher ausgeführt zu werden.
Ausführungseinheiten
6A-6B zeigen eine Strangausführungslogik 600, einschließlich einer Anordnung von Verarbeitungselementen, die in einem Graphikprozessorkern eingesetzt werden, gemäß hierin beschriebenen Ausführungsformen. Elemente von 6A-6B, die die gleichen Bezugszeichen (oder Namen) wie die Elemente von irgendeiner anderen Figur hierin aufweisen, können auf eine beliebige Art und Weise, die mit der an einer anderen Stelle hierin beschriebenen vergleichbar ist, wirken oder funktionieren, ohne darauf beschränkt zu sein. 6A zeigt eine Übersicht über die Strangausführungslogik 600, die eine Variante der Hardwarelogik umfassen kann, die mit jedem Teilkern 501A-501F von 5 veranschaulicht ist. 6B zeigt beispielhafte interne Einzelheiten einer Ausführungseinheit.
Wie es in 6A dargestellt ist, umfasst die Strangausführungslogik 600 in einigen Ausführungsformen einen Schattierer-Prozessor 602, einen Strangabfertiger 604, einen Befehls-Cache 606, eine skalierbare Ausführungseinheitsanordnung, die mehrere Ausführungseinheiten 608A-608N umfasst, einen Abtaster 610, einen Daten-Cache 612 und einen Daten-Port 614. In einer Ausführungsform kann die skalierbare Ausführungseinheitsanordnung dynamisch skaliert werden, indem eine oder mehrere Ausführungseinheiten (z. B. eine beliebige der Ausführungseinheiten 608A, 608B, 608C, 608D bis 608N-1 und 608N) basierend auf den Rechenanforderungen einer Arbeitslast aktiviert oder deaktiviert werden. In einer Ausführungsform sind die enthaltenen Komponenten über eine Zwischenverbindungsstruktur, die mit jeder der Komponenten verbunden ist, miteinander verbunden. In einigen Ausführungsformen umfasst die Strangausführungslogik 600 eine oder mehrere Verbindungen zu Speicher wie Systemspeicher oder Cache-Speicher durch den Befehls-Cache 606, den Daten-Port 614, den Abtaster 610 und die Ausführungseinheiten 608A-608N. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 608A) eine eigenständige programmierbare Universalrecheneinheit, die dazu in der Lage ist, mehrere gleichzeitige Hardwarestränge auszuführen und zugleich für jeden Strang mehrere Datenelemente parallel zu verarbeiten. In verschiedenen Ausführungsformen ist die Anordnung von Ausführungseinheiten 608A-608N so skalierbar, dass sie eine beliebige Anzahl von einzelnen Ausführungseinheiten umfasst.
In einigen Ausführungsformen werden die Ausführungseinheiten 608A-608N hauptsächlich verwendet, um Schattierer-Programme auszuführen. Ein Schattierer-Prozessor 602 kann die verschiedenen Schattierer-Programme verarbeiten und Ausführungsstränge, die den Schattierer-Programmen zugeordnet sind, über einen Strangabfertiger 604 abfertigen. In einer Ausführungsform umfasst der Strangabfertiger Logik zum Vermitteln von Stranginitiierungsanforderungen von den Graphik- und Medien-Pipelines und Instanziieren der angeforderten Stränge auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 608A-608N. Zum Beispiel kann eine Geometrie-Pipeline Vertex-, Tessellations- oder Geometrie-Schattierer zum Verarbeiten an die Strangausführungslogik senden. In einigen Ausführungsformen kann der Strangabfertiger 604 auch Laufzeit-Strangerstellungsanforderungen von den ausgeführten Schattierer-Programmen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N einen Befehlssatz, der native Unterstützung für viele Standard-3D-Graphik-Schattierer-Befehle umfasst, so dass Schattierer-Programme von Graphikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen eine Vertex- und Geometrieverarbeitung (z. B. Vertex-Programme, Geometrieprogramme, Vertex-Schattierer), Pixelverarbeitung (z. B. Pixel-Schattierer, Fragment-Schattierer) und Universalverarbeitung (z. B. Rechen- und Medien-Schattierer). Jede der Ausführungseinheiten 608A-608N ist zu Ausführung mit Anwendung eines Befehls auf mehrere Datenströme (SIMD-Ausführung) mit mehrfacher Ausgabe in der Lage und ein mehrsträngiger Betrieb ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Strang innerhalb jeder Ausführungseinheit weist einen dedizierten Registersatz für hohe Bandbreite und einen zugehörigen unabhängigen Strangzustand auf. Die Ausführung erfolgt durch mehrfaches Ausgeben je Takt an Pipelines, die zu Ganzzahlgleitkommaoperationen mit einfacher und doppelter Genauigkeit, SIMD-Verzweigungsfähigkeit, logischen Operationen, transzendenten Operationen und anderen sonstigen Operationen in der Lage sind. Während des Wartens auf Daten aus Speicher oder von einer der gemeinsam genutzten Funktionen veranlasst eine Abhängigkeitslogik innerhalb der Ausführungseinheiten 608A-608N, dass ein wartender Strang im Ruhezustand bleibt, bis die angeforderten Daten zurückgegeben wurden. Während sich der wartende Strang im Ruhezustand befindet, können Hardwarebetriebsmittel für die Verarbeitung von anderen Strängen verwendet werden. Zum Beispiel kann eine Ausführungseinheit während einer Verzögerung in Verbindung mit einer Vertex-Schattierer-Operation Operationen für einen Pixel-Schattierer, einen Fragment-Schattierer oder einen anderen Typ von Schattierer-Programm einschließlich eines anderen Vertex-Schattierers durchführen.
Jede Ausführungseinheit in den Ausführungseinheiten 608A-608N wirkt auf Arrays von Datenelementen. Die Anzahl von Datenelementen 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 Datenelementzugriff, Maskierung und Flusssteuerung innerhalb von Befehlen. Die Anzahl von Kanälen kann von der Anzahl von arithmetischlogischen Einheiten (ALUs) oder Gleitkommaeinheiten (FPUs) für einen bestimmten Graphikprozessor unabhängig sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N Ganzzahl- und Gleitkommadatentypen.
Der Ausführungseinheits-Befehlssatz enthält SIMD-Befehle. Die verschiedenen Datenelemente können als gepackte Datentypen in einem Register gespeichert sein und die Ausführungseinheit wird die verschiedenen Elemente auf der Basis der Datengröße der Elemente verarbeiten. Beispielsweise sind beim Arbeiten mit einem 256 Bit breiten Vektor die 256 Bits des Vektors in einem Register gespeichert und die Ausführungseinheit arbeitet mit dem Vektor als vier separaten 64-Bit-gepackten Datenelementen (Datenelementen der Größe Vierfachwort (QW)), acht separaten 32-Bit-gepackten Datenelementen (Datenelementen der Größe Doppelwort (DW)), sechzehn separaten 16-Bit-gepackten Datenelementen (Datenelementen der Größe Wort (W)) oder zweiunddreißig separaten 8-Bit-Datenelementen (Datenelementen der Größe Byte (B)). Allerdings sind andere Vektorbreiten und Registergrößen möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten zu einer zusammengeschlossenen Ausführungseinheit 609A-609N kombiniert werden, die eine Strangsteuerlogik (607A-607N) aufweist, die den zusammengeschlossenen EUs gemein ist. Mehrere EUs können in einer EU-Gruppe zusammengeschlossen werden. Jede EU in der zusammengeschlossenen EU-Gruppe kann dazu ausgelegt sein, einen separaten SIMD-Hardware-Strang auszuführen. Die Anzahl von EUs in einer zusammengeschlossenen EU-Gruppe kann gemäß Ausführungsformen variieren. Außerdem können je EU verschiedene SIMD-Breiten durchgeführt werden, einschließlich, ohne darauf beschränkt zu sein, SIMD8, SIMD16 und SIMD32. Jede zusammengeschlossene Graphikausführungseinheit 609A-609N umfasst mindestens zwei Ausführungseinheiten. Zum Beispiel umfasst die zusammengeschlossene Ausführungseinheit 609A eine erste EU 608A, eine zweite EU 608B und die Strangsteuerlogik 607A, die der ersten EU 608A und der zweiten EU 608B gemein ist. Die Strangsteuerlogik 607A steuert Stränge, die auf der zusammengeschlossenen Graphikausführungseinheit 609A ausgeführt werden, wodurch es jeder EU innerhalb der zusammengeschlossenen Ausführungseinheiten 609A-609N ermöglicht wird, unter Verwendung eines gemeinsamen Befehlszeigerregisters ausgeführt zu werden.
Ein oder mehrere interne Befehls-Caches (z. B. 606) sind in der Strangausführungslogik 600 enthalten, um Strangbefehle für die Ausführungseinheiten zwischenzuspeichern. In einigen Ausführungsformen sind ein oder mehrere Daten-Caches (z. B. 612) enthalten, um Strangdaten während der Strangausführung zwischenzuspeichern. In einigen Ausführungsformen ist ein Abtaster 610 enthalten, um eine Texturabtastung für 3D-Operationen und eine Medienabtastung für Medienoperationen bereitzustellen. In einigen Ausführungsformen umfasst der Abtaster 610 eine spezielle Textur- oder Medienabtastfunktionalität, um Textur- oder Mediendaten während des Abtastverfahrens zu verarbeiten, bevor er die abgetasteten Daten an eine Ausführungseinheit liefert.
Während der Ausführung senden die Graphik- und Medien-Pipelines Stranginitiierungsanforderungen über Strangerstellungs- und Strangabfertigungs-Logik an die Strangausführungslogik 600. Sobald eine Gruppe von geometrischen Objekten verarbeitet und in Pixeldaten gerastert wurde, wird Pixelprozessorlogik (z. B. Pixel-Schattierer-Logik, Fragment-Schattierer-Logik usw.) innerhalb des Schattierer-Prozessors 602 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu veranlassen, dass Ergebnisse in Ausgabeoberflächen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In einigen Ausführungsformen berechnet ein Pixel-Schattierer oder Fragment-Schattierer die Werte der verschiedenen Vertexattribute, die über das gerasterte Objekt hinweg zu interpolieren sind. In einigen Ausführungsformen führt Pixelprozessorlogik innerhalb des Schattierer-Prozessors 602 dann ein von einer Anwendungsprogrammierschnittstelle (API) geliefertes Pixel- oder Fragment-Schattierer-Programm aus. Zum Ausführen des Schattierer-Programms sendet der Schattierer-Prozessor 602 über den Strangabfertiger 604 Stränge an eine Ausführungseinheit (z. B. 608A). In einigen Ausführungsformen verwendet der Schattierer-Prozessor 602 Texturabtastlogik in dem Abtaster 610, um auf Texturdaten in Texturkarten zuzugreifen, die in Speicher gespeichert sind. Arithmetische Operationen an den Texturdaten und die eingegebenen Geometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder schließen einen oder mehrere Pixel von einer Weiterverarbeitung aus.
In einigen Ausführungsformen bietet der Daten-Port 614 einen Speicherzugriffsmechanismus für die Strangausführungslogik 600 zum Ausgeben von verarbeiteten Daten an Speicher zur Weiterverarbeitung auf einer Graphikprozessorausgabe-Pipeline. In einigen Ausführungsformen umfasst der Daten-Port 614 einen oder mehrere Cache-Speicher (z. B. Daten-Cache 612) oder koppelt mit diesen, um Daten für einen Speicherzugriff über den Daten-Port zwischenzuspeichern.
Wie es in 6B dargestellt ist, kann eine Graphikausführungseinheit 608 eine Befehlsabrufeinheit 637, eine Allgemeinregistersatz-Anordnung (GRF-Anordnung) 624, eine Architekturregistersatz-Anordnung (ARF-Anordnung) 626, einen Strangvermittler 622, eine Sendeeinheit 630, eine Verzweigungseinheit 632, einen Satz von SIMD-Gleitkommaeinheiten (FPUs) 634 und in einer Ausführungsform einen Satz dedizierter Ganzzahl-SIMD-ALUs 635 umfassen. Die GRF 624 und die ARF 626 umfasst die Menge von Allgemeinregistersätzen und Architekturregistersätzen, die jedem gleichzeitigen Hardware-Strang zugeordnet sind, der in der Graphikausführungseinheit 608 aktiv sein kann. In einer Ausführungsform wird der Pro-Strang-Architekturzustand in der ARF 626 beibehalten, während Daten, die während der Strangausführung verwendet werden, in der GRF 624 gespeichert werden. Der Ausführungszustand jedes Strangs einschließlich der Befehlszeiger für jeden Strang kann in strangspezifischen Registern in der ARF 626 gehalten werden.
In einer Ausführungsform weist die Graphikausführungseinheit 608 eine Architektur auf, die eine Kombination von gleichzeitiget Mehrsträngigkeit (SMT) und feingranulärer verschachtelter Mehrsträngigkeit (IMT) darstellt. Die Architektur weist eine modulare Konfiguration auf, die zur Designzeit basierend auf einer Zielanzahl von gleichzeitigen Strängen und einer Anzahl von Registern je Ausführungseinheit fein abgestimmt werden kann, wobei Ausführungseinheitsbetriebsmittel auf Logik, die zum Ausführen von mehreren gleichzeitigen Strängen verwendet wird, verteilt wird.
In einer Ausführungsform kann die Graphikausführungseinheit 608 mehrere Befehle, die jeweils verschiedene Befehle sein können, gemeinsam ausgeben. Der Strangvermittler 622 des Graphikausführungseinheits-Strangs 608 kann die Befehle an die Sendeeinheit 630, die Verzweigungseinheit 6342 und/oder die SIMD-FPU(s) 634 zur Ausführung senden. Jeder Ausführungsstrang kann auf 128 Universalregister innerhalb der GRF 624 zugreifen, wobei jedes Register 32 Bytes speichern kann, die als ein SIMD-8-Element-Vektor von 32-Bit-Datenelementen zugänglich sind. In einer Ausführungsform hat jeder Ausführungseinheitsstrang Zugriff auf 4 KBytes innerhalb der GRF 624, wenngleich Ausführungsformen nicht hierauf beschränkt sind, und in anderen Ausführungsformen können mehr oder weniger Registerbetriebsmittel bereitgestellt sein. In einer Ausführungsform können bis zu sieben Stränge gleichzeitig ausgeführt werden, wenngleich die Anzahl von Strängen je Ausführungseinheit auch gemäß Ausführungsformen variieren kann. In einer Ausführungsform, in der sieben Stränge auf 4 KBytes zugreifen können, kann die GRF 624 insgesamt 28 KBytes speichern. Flexible Adressierungsmodi können es ermöglichen, dass Register zusammen adressiert werden, um effektiv breitere Register zu erstellen oder um rechteckige Blockdatenstrukturen mit Schritten darzustellen.
In einer Ausführungsform werden Speicheroperationen, Abtasteroperationen und andere Systemkommunikation mit einer längeren Latenz über „Senden“-Befehle gesendet, die durch die Nachrichtenweiterleitungssendeeinheit 630 ausgeführt werden. In einer Ausführungsform werden Verzweigungsbefehle an eine dedizierte Verzweigungseinheit 632 gesendet, um eine SIMD-Divergenz und letztliche Konvergenz zu unterstützen.
In einer Ausführungsform umfasst die Graphikausführungseinheit 608 eine oder mehrere SIMD-Gleitkommaeinheiten (FPUs) 634 zum Durchführen von Gleitkommaoperationen. In einer Ausführungsform unterstützt/unterstützen die FPU(s) 634 auch ein Ganzzahlrechnen. In einer Ausführungsform kann/können die FPU(s) 634 bis zu M Anzahl von 32-Bit-Gleitkomma-(oder Ganzzahl-) Operationen mit SIMD ausführen oder bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkommaoperationen mit SIMD ausführen. In einer Ausführungsform stellt zumindest eine der FPU(s) erweiterte Mathematikfähigkeit bereit, um transzendente Mathematikfunktionen mit hohem Durchsatz und 64-Bit-Gleitkomma mit doppelter Genauigkeit zu unterstützen. In einigen Ausführungsformen ist auch ein Satz von 8-Bit-Ganzzahl-SIMD-ALUs 635 vorhanden und kann insbesondere optimiert sein, um Operationen in Verbindung mit Berechnungen des maschinellen Lernens durchzuführen.
In einer Ausführungsform können Anordnungen von mehreren Instanzen der Graphikausführungseinheit 608 in einer Graphikteilkerngruppierung (z. B. einem Unter-Slice) instanziiert werden. Zur Skalierbarkeit können Produktarchitekten die genaue Anzahl von Ausführungseinheiten je Teilkerngruppierung auswählen. In einer Ausführungsform kann die Ausführungseinheit 608 Befehle über mehrere Ausführungskanäle hinweg ausführen. In einer weiteren Ausführungsform wird jeder Strang, der auf der Graphikausführungseinheit 608 ausgeführt wird, auf einem anderen Kanal ausgeführt.
7 ist ein Blockdiagramm, das ein Graphikprozessor-Ausführungseinheits-Befehlsformat 700 gemäß einigen Ausführungsformen darstellt. In einer oder mehreren Ausführungsformen unterstützen die Graphikprozessor-Ausführungseinheiten einen Befehlssatz mit Befehlen in mehreren Formaten. Die durchgezogenen Kasten zeigen die Komponenten, die in der Regel in einem Ausführungseinheitsbefehl enthalten sind, während die gestrichelten Linien Komponenten umfassen, die optional sind oder die nur in einem Teilsatz der Befehle enthalten sind. In einigen Ausführungsformen besteht das Befehlsformat 700, das gezeigt und beschrieben wird, aus Makrobefehlen, die Befehle sind, die an die Ausführungseinheit geliefert werden, im Gegensatz zu Mikrooperationen, die aus der Befehlsdecodierung resultieren, sobald der Befehl verarbeitet wird.
In einigen Ausführungsformen unterstützen die Graphikprozessor-Ausführungseinheiten standardmäßig Befehle in einem 128-Bit-Format 710. Ein verdichtetes 64-Bit-Befehlsformat 730 steht für einige Befehle abhängig von dem ausgewählten Befehl, den Befehlsoptionen und der Anzahl der Operanden zur Verfügung. Das standardmäßige 128-Bit-Format 710 bietet Zugriff auf alle Befehlsoptionen, während einige Optionen und Operationen in dem 64-Bit-Format 730 eingeschränkt sind. Die standardmäßigen Befehle, die in dem 64-Bit-Format 730 verfügbar sind, variieren je nach Ausführungsform. In einigen Ausführungsformen ist der Befehl unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 zum Teil verdichtet. Die Ausführungseinheits-Hardware verweist auf einen Satz von Verdichtungstabellen auf der Grundlage der Indexwerte und verwendet die Verdichtungstabellenausgaben, um einen standardmäßigen Befehl in dem 128-Bit-Format 710 zu rekonstruieren.
Für jedes Format definiert ein Befehls-Opcode 712 die Funktion, die die Ausführungseinheit ausführen soll. Die Ausführungseinheiten führen jeden Befehl parallel über die mehreren Datenelemente jedes Operanden hinweg aus. Zum Beispiel führt die Ausführungseinheit als Antwort auf einen Addierbefehl eine gleichzeitige Additionsoperation für jeden Farbkanal, der ein Texturelement oder Bildelement darstellt, durch. Standardmäßig führt die Ausführungseinheit jeden Befehl über alle Datenkanäle der Operanden hinweg aus. In einigen Ausführungsformen ermöglicht ein Befehlssteuerfeld 714 die Kontrolle über bestimmte Ausführungsoptionen wie beispielsweise die Kanalauswahl (z. B. Prädikation) und Datenkanalreihenfolge (z. B. Umordnen (Swizzle)). Für 128-Bit-Befehle 710 begrenzt ein Feld „exec-size“ 716 die Anzahl von Datenkanälen, die parallel ausgeführt werden. Das Feld „exec-size“ 716 steht in einigen Ausführungsformen nicht für den Einsatz in dem kompakten 64-Bit-Befehlsformat 730 zur Verfügung.
Einige Ausführungseinheitsbefehle weisen bis zu drei Operanden auf, darunter zwei Quellenoperanden src0 720, srcl 722, und ein Ziel 718. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Doppelziel-Befehle, wobei eines der Ziele impliziert ist. Datenmanipulationsbefehle können einen dritten Quelloperanden (z. B. SRC2 724) aufweisen, wobei der Befehls-Opcode 712 die Anzahl der Quelloperanden bestimmt. Der letzte Quelloperand eines Befehls kann ein direkter (z. B. fest codierter) Wert sein, der mit dem Befehl weitergegeben wird.
In einigen Ausführungsformen umfasst das 128-Bit-Befehlsformat 710 ein Zugriffs-/Adressmodusfeld 726, das beispielsweise angibt, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn der direkte Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt über Bits in dem Befehl bereitgestellt.
In einigen Ausführungsformen umfasst das 128-Bit-Befehlsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für den Befehl spezifiziert. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für den Befehl zu definieren. Einige Ausführungsformen unterstützen Zugriffsmodi einschließlich eines 16-Byte-Ausrichtungs-Zugriffsmodus und eines 1-Byte-Ausrichtungs-Zugriffsmodus, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Befehlsoperanden bestimmt. Wenn sich der Befehl beispielsweise in einem ersten Modus befindet, kann er eine Byte-Ausrichtungs-Adressierung für Quell- und Zieloperanden verwenden, und wenn sich der Befehl in einem zweiten Modus befindet, kann er eine 16-Byte-Ausrichtungs-Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressmodusabschnitt des Zugriffs-/Adressmodusfelds 726, ob der Befehl eine direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, liefern die Bits in dem Befehl direkt die Registeradresse eines oder mehrerer Operanden. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem Adress-Direktwertfeld in dem Befehl berechnet werden.
In einigen Ausführungsformen sind Befehle basierend auf Opcode-Bitfeldern 712 gruppiert, um eine Opcode-Decodierung 740 zu vereinfachen. Bei einem 8-Bit-Opcode ermöglichen die Bits 4, 5 und 6 es der Ausführungseinheit, den Typ von Opcode zu bestimmen. Die genau gezeigte Opcode-Gruppierung ist lediglich beispielhaft. In einigen Ausführungsformen umfasst eine Verschiebungs- und Logik-Opcode-Gruppe 742 Datenverschiebungs- und Logik-Befehle (z. B. Verschieben (mov), Vergleichen (cmp)). In einigen Ausführungsformen nutzt die Verschiebungs- und Logik-Gruppe 742 die fünf höchstwertigen Bits (MSB) gemeinsam, wobei die Verschiebungsbefehle in der Form 0000xxxxb sind und die Logikbefehle in der Form 0001xxxxb sind. Eine Ablaufsteuerungsbefehlsgruppe 744 (z. B. Aufrufen (call), Springen (jmp)) enthält Befehle in der Form 0010xxxxb (z. B. 0x20). Eine gemischte Befehlsgruppe 746 umfasst eine Mischung aus Befehlen, die Synchronisationsbefehle (z. B. Warten (wait), Senden (send)) in der Form 0011xxxxb (z. B. 0x30) umfasst. Eine Parallelmathematik-Befehlsgruppe 748 umfasst komponentenweise arithmetische Befehle (z. B. Addieren (add), Multiplizieren (mul)) in der Form 0100xxxxb (z. B. 0x40). Die Parallelmathematik-Gruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle hinweg aus. Die Vektormathematik-Gruppe 750 umfasst arithmetische Befehle (z. B. dp4) in der Form 0101xxxxb (z. B. 0x50). Die Vektormathematik-Gruppe führt arithmetische Operationen wie Skalarproduktberechnungen an Vektoroperanden aus.
Graphikpipeline
8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Graphikprozessors 800. Elemente von 8 mit den gleichen Bezugszeichen (oder Namen) wie die Elemente von irgendeiner anderen Figur hierin können auf eine Art und Weise arbeiten oder funktionieren, die der an anderer Stelle hierin beschriebenen ähnlich ist, sind jedoch nicht darauf beschränkt.
In einigen Ausführungsformen umfasst der Graphikprozessor 800 eine Geometrie-Pipeline 820, eine Medienpipeline 830, eine Anzeigemaschine 840, eine Strangausführungslogik 850 und eine Render-Ausgabe-Pipeline 870. In einigen Ausführungsformen ist der Graphikprozessor 800 ein Graphikprozessor innerhalb eines Mehrkern-Verarbeitungssystems, das einen oder mehrere Allzweck-Verarbeitungskerne enthält. Der Graphikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle, die über eine Ringzwischenverbindung 802 an den Graphikprozessor 800 erteilt werden, gesteuert. In einigen Ausführungsformen koppelt die Ringzwischenverbindung 802 den Graphikprozessor 800 mit anderen Verarbeitungskomponenten wie anderen Graphikprozessoren oder Allzweckprozessoren. Befehle aus der Ringzwischenverbindung 802 werden durch einen Befehls-Streamer 803 interpretiert, der Befehle an einzelne Komponenten der Geometrie-Pipeline 820 oder Medienpipeline 830 liefert.
In einigen Ausführungsformen lenkt der Befehls-Streamer 803 den Betrieb eines Vertexabrufers 805, der Vertexdaten aus dem Speicher liest und Vertexverarbeitungsbefehle, die von dem Befehls-Streamer 803 geliefert werden, ausführt. In einigen Ausführungsformen liefert der Vertexabrufer 805 Vertexdaten an einen Vertex-Schattierer 807, der eine Koordinatenraumtransformation und Beleuchtungsoperationen an jedem Vertex ausführt. In einigen Ausführungsformen führen der Vertexabrufer 805 und der Vertex-Schattierer 807 Vertexverarbeitungsbefehle durch Entsenden von Ausführungssträngen an die Ausführungseinheiten 852A-852B über einen Strangabfertiger 831 aus.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B eine Anordnung von Vektorprozessoren mit einem Befehlssatz zum Durchführen von Graphik- und Medienoperationen. In einigen Ausführungsformen weisen die Ausführungseinheiten 852A-852B einen angeschlossenen L1-Cache 851 auf, der spezifisch für jede Anordnung ist oder von den Anordnungen gemeinsam genutzt wird. Der Cache kann als Daten-Cache, Befehls-Cache oder ein einzelner Cache, der partitioniert ist, um Daten und Befehle in verschiedenen Partitionen zu enthalten, ausgelegt sein.
In einigen Ausführungsformen umfasst die Geometrie-Pipeline 820 Tessellationskomponenten zum Durchführen einer hardwarebeschleunigten Tessellation von 3D-Objekten. Ein programmierbarer Mantel-Schattierer 811 konfiguriert die Tessellationsoperationen. Ein programmierbarer Domain-Schattierer 817 liefert eine Backend-Auswertung der Tessellationsausgabe. Ein Tessellator 813 arbeitet unter der Führung des Mantel-Schattierers 811 und umfasst Sonderlogik, um einen Satz von detaillierten geometrischen Objekten basierend auf einem groben geometrischen Modell, das als Eingabe in die Geometrie-Pipeline 820 bereitgestellt wird, zu erzeugen. Wenn die Tessellation in einigen Ausführungsformen nicht verwendet wird, können die Tessellationskomponenten (z. B. Mantel-Schattierer 811, Tessellator 813 und Domain-Schattierer 817) umgangen werden.
In einigen Ausführungsformen können die vollständigen geometrischen Objekte durch einen Geometrie-Schattierer 819 über einen oder mehrere Stränge, die an die Ausführungseinheiten 852A, 852B entsendet werden, verarbeitet werden oder können direkt zu dem Clipper 829 voranschreiten. In einigen Ausführungsformen bearbeitet der Geometrie-Schattierer gesamte geometrische Objekte anstelle von Vertices oder Stellen von Vertices wie in vorherigen Stufen der Graphik-Pipeline. Wenn die Tessellation deaktiviert ist, empfängt der Geometrie-Schattierer 819 Eingaben aus dem Vertex-Schattierer 807. In einigen Ausführungsformen ist der Geometrie-Schattierer 819 durch ein Geometrie-Schattierer-Programm programmierbar, um eine Geometrie-Tessellation durchzuführen, wenn die Tessellationseinheiten deaktiviert sind.
Vor der Rasterung werden die Vertex-Daten durch einen Clipper 829 verarbeitet. Der Clipper 829 kann entweder ein Clipper mit fester Funktion oder ein programmierbarer Clipper mit Clipping- und Geometrie-Schattierer-Funktionen sein. In einigen Ausführungsformen fertigt eine Raster-und-Tiefentestkomponente 873 in der Renderausgabepipeline 870 Pixel-Schattierer ab, um die geometrischen Objekte in ihre pixelweisen Darstellungen zu konvertieren. In einigen Ausführungsformen ist die Pixel-Schattierer-Logik in der Strangausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung die Raster-und-Tiefentestkomponente 873 umgehen und über eine Stream-Out-Einheit 823 auf nicht gerasterte Vertex-Daten zugreifen.
Der Graphikprozessor 800 verfügt über einen Zwischenverbindungsbus, eine Zwischenverbindungsstruktur oder irgendeinen anderen Zwischenverbindungsmechanismus, der einen Daten- und Nachrichtenaustausch zwischen den Hauptkomponenten des Prozessors ermöglicht. In einigen Ausführungsformen sind Ausführungseinheiten 852A, 852B und zugehörige Logikeinheiten (z. B. L1-Cache 851, Abtaster 854 und ein Textur-Cache 858 usw.) über einen Datenanschluss 856 verbunden, um einen Speicherzugriff durchführen und mit Renderausgabepipeline-Komponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen weisen der Abtaster 854, die Caches 851, 858 und die Ausführungseinheiten 852A, 852B jeweils separate Speicherzugriffspfade auf. In einer Ausführungsform kann der Textur-Cache 858 auch als Abtaster-Cache ausgelegt sein.
In einigen Ausführungsformen enthält die Render-Ausgabe-Pipeline 870 eine Raster-und-Tiefentestkomponente 873, die vertexbasierte Objekte in die ihnen zugeordnete pixelbasierte Darstellung umwandelt. In einigen Ausführungsformen umfasst die Rasterlogik eine Fenster-/Maskier-Einheit, um eine Dreiecks- und Linien-Rasterung mit fester Funktion durchzuführen. Ein zugehöriger Render-Cache 878 und Tiefen-Cache 879 sind zudem in einigen Ausführungsformen verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten durch, obwohl in einigen Fällen Pixeloperationen, die 2D-Operationen zugeordnet sind (z. B. Bitblockbildübertragungen mit Überlagerung), von der 2D-Maschine 841 durchgeführt werden, oder zu der Anzeigezeit durch den Anzeige-Controller 843 mit Überlagerungsanzeigeebenen ersetzt werden. In einigen Ausführungsformen ist ein gemeinsam genutzter L3-Cache 875 für alle Graphikkomponenten verfügbar, so dass die gemeinsame Nutzung von Daten ohne den Einsatz des Hauptsystemspeichers ermöglicht wird.
In einigen Ausführungsformen umfasst die Graphikprozessor-Medienpipeline 830 eine Medienmaschine 337 und ein Video-Frontend 834. In einigen Ausführungsformen empfängt das Video-Frontend 834 Pipelinebefehle aus dem Befehls-Streamer 803. In einigen Ausführungsformen umfasst die Medienpipeline 830 aber einen separaten Befehls-Streamer. In einigen Ausführungsformen verarbeitet das Video-Frontend 834 Medienbefehle, bevor es den Befehl an die Medienmaschine 837 sendet. In einigen Ausführungsformen umfasst die Medienmaschine 837 eine Strangerzeugungsfunktionalität, um Stränge für das Entsenden an die Strangausführungslogik 850 über den Strangabfertiger 831 zu erzeugen.
In einigen Ausführungsformen umfasst der Graphikprozessor 800 eine Anzeigemaschine 840. In einigen Ausführungsformen ist die Anzeigemaschine 840 bezüglich des Prozessors 800 extern und ist mit dem Graphikprozessor über die Ringzwischenverbindung 802 oder irgendeinen anderen Zwischenverbindungsbus oder einen andere Zwischenverbindungsstruktur gekoppelt. In einigen Ausführungsformen umfasst die Anzeigemaschine 840 eine 2D-Maschine 841 und einen Anzeigecontroller 843. In einigen Ausführungsformen enthält die Anzeigemaschine 840 eine Sonderlogik, die unabhängig von der 3D-Pipeline arbeiten kann. In einigen Ausführungsformen ist der Anzeigecontroller 843 mit einer Anzeigevorrichtung (nicht dargestellt) gekoppelt, die eine integrierte Systemanzeigevorrichtung wie bei einem Laptop-Computer sein kann oder eine externe Anzeigevorrichtung, die über ein Anzeigevorrichtungs-Verbindungselement angeschlossen ist, sein kann.
In einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medienpipeline 830 konfigurierbar, um Operationen auf der Basis mehrerer Graphik- und Medienprogrammierschnittstellen durchzuführen, und sind nicht speziell für irgendeine Anwendungsprogrammierschnittstelle (API) ausgelegt. In einigen Ausführungsformen übersetzt die Treibersoftware für den Graphikprozessor API-Aufrufe, die spezifisch für eine bestimmte Graphik- oder Medienbibliothek sind, in Befehle, die von dem Graphikprozessor verarbeitet werden können. In einigen Ausführungsformen wird Unterstützung für die Open Graphics Library (OpenGL) und die Open Computing Language (OpenCL), und/oder Vulcan Graphics und Compute-API die von der Khronos Group bereitgestellt werden, geboten. In einigen Ausführungsformen kann auch Unterstützung für die Direct3D-Bibliothek von der Microsoft Corporation geboten werden. In einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Es kann auch Unterstützung für die Open Source Computer Vision Library (OpenCV) geboten werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde dann auch unterstützt, wenn eine Abbildung von der Pipeline der zukünftigen API auf die Pipeline des Graphikprozessors vorgenommen werden kann.
Graphikpipelineprogrammierung
9A ist ein Blockdiagramm eines Graphikprozessorbefehlsformats 900 gemäß einigen Ausführungsformen. 9B ist ein Blockdiagramm einer Graphikprozessorbefehlsfolge 910 gemäß einer Ausführungsform. Die durchgezogenen Kästchen in 9A veranschaulichen die Komponenten, die im Allgemeinen in einem Graphikbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einem Teilsatz der Graphikbefehle enthalten sind. Das beispielhafte Graphikprozessorbefehlsformat 900 von 9A umfasst Datenfelder zum Identifizieren eines Clients 902, eines Befehlsoperationscodes (Opcodes) 904 und von Daten 906 für den Befehl. Ein Teil-Opcode 905 und eine Befehlsgröße 908 sind ebenfalls in einigen Befehlen enthalten.
In einigen Ausführungsformen spezifiziert der Client 902 die Client-Einheit der Graphikvorrichtung, die die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Graphikprozessor-Befehls-Parser das Client-Feld jedes Befehls, um die weitere Verarbeitung des Befehls aufzubereiten und die Befehlsdaten an die geeignete Client-Einheit weiterzuleiten. In einigen Ausführungsformen weisen die Graphikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit auf. Jede Client-Einheit hat eine entsprechende Verarbeitungs-Pipeline, die die Befehle verarbeitet. Sobald der Befehl durch die Client-Einheit empfangen wurde, liest die Client-Einheit den Opcode 904 und, falls vorhanden, den Teil-Opcode 905, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Informationen in dem Datenfeld 906 aus. Für einige Befehle wird eine explizite Befehlsgröße 908 erwartet, die die Größe des Befehls angibt. In einigen Ausführungsformen bestimmt der Befehls-Parser automatisch die Größe von mindestens einigen der Befehle basierend auf dem Befehls-Opcode. In einigen Ausführungsformen sind Befehle nach Vielfachen eines Doppelwortes ausgerichtet.
Das Ablaufdiagramm in 9B zeigt eine beispielhafte Graphikprozessorbefehlsfolge 910. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Graphikprozessors aufweist, eine Version der dargestellten Befehlsfolge, um einen Satz von Graphikoperationen einzurichten, auszuführen und zu beenden. Eine beispielhafte Befehlsfolge wird nur zu Beispielszwecken dargestellt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlsfolge beschränkt sind. Darüber hinaus können die Befehle als Stapel von Befehlen in einer Befehlsfolge ausgegeben werden, so dass der Graphikprozessor die Folge von Befehlen zumindest teilweise gleichzeitig verarbeitet.
In einigen Ausführungsformen kann die Graphikprozessorbefehlsfolge 910 mit einem Pipelinebereinigungsbefehl 912 beginnen, um zu veranlassen, dass eine aktive Graphikpipeline die aktuell für die Pipeline ausstehenden Befehle abschließt. In einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medienpipeline 924 nicht gleichzeitig. Die Pipelinebereinigung wird ausgeführt, um zu veranlassen, dass die aktive Graphikpipeline alle ausstehenden Befehle abschließt. Als Antwort auf eine Pipelinebereinigung unterbricht der Befehls-Parser für den Graphikprozessor die Befehlsverarbeitung, bis die aktiven Zeichenmaschinen ausstehende Operationen abschließen und die relevanten Lese-Caches ungültig gemacht werden. Wahlweise können alle Daten im Render-Cache, die als „schmutzig“ gekennzeichnet sind, in den Speicher geleert werden. In einigen Ausführungsformen kann der Pipelinebereinigungsbefehl 912 für die Pipelinesynchronisation oder vor dem Versetzen des Graphikprozessors in einen Zustand niedriger Leistung verwendet werden.
In einigen Ausführungsformen wird ein Pipelineauswahlbefehl 913 verwendet, wenn eine Befehlsfolge erfordert, dass der Graphikprozessor explizit zwischen Pipelines wechselt. In einigen Ausführungsformen wird ein Pipelineauswahlbefehl 913 nur einmal in einem Ausführungskontext vor dem Ausgeben von Pipeline-Befehlen benötigt, es sei denn, der Kontext gibt vor, Befehle für beide Pipelines auszugeben. In einigen Ausführungsformen ist ein Pipelinebereinigungsbefehl 912 unmittelbar vor einem Pipelinewechsel mittels des Pipelineauswahlbefehls 913 erforderlich.
In einigen Ausführungsformen konfiguriert ein Pipelinesteuerbefehl 914 eine Graphikpipeline für den Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medienpipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Pipelinesteuerbefehl 914 den Pipelinezustand für die aktive Pipeline. In einer Ausführungsform wird der Pipelinesteuerbefehl 914 für eine Pipelinesynchronisation und zum Löschen von Daten aus einem oder mehreren Cache-Speichern innerhalb der aktiven Pipeline verwendet, bevor ein Stapel von Befehlen verarbeitet wird.
In einigen Ausführungsformen werden Rückgabepufferzustands-Befehle 916 verwendet, um einen Satz von Rückgabepuffern für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipelineoperationen erfordern die Zuweisung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen während der Verarbeitung Zwischendaten schreiben. In einigen Ausführungsformen verwendet der Graphikprozessor auch einen oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und eine strangübergreifende Kommunikation durchzuführen. In einigen Ausführungsformen beinhaltet der Rückgabepufferzustand 916 das Auswählen der Größe und Anzahl von Rückgabepuffern, die für einen Satz von Pipelineoperationen verwendet werden sollen.
Die verbleibenden Befehle in der Befehlsfolge unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipelinebestimmung 920 wird die Befehlsfolge auf die 3D-Pipeline 922, beginnend mit dem 3D-Pipeline-Zustand 930, oder die Medienpipeline 924, beginnend mit dem MedienpipelineZustand 940, zugeschnitten.
Die Befehle für den 3D-Pipeline-Zustand 930 umfassen 3D-Zustandseinstellungsbefehle für den Vertex-Pufferzustand, einen Vertex-Elementzustand, einen Konstantfarbzustand, einen Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitiv-Befehle verarbeitet werden. Die Werte dieser Befehle werden mindestens teilweise basierend auf der jeweiligen verwendeten 3D-API bestimmt. In einigen Ausführungsformen sind Befehle zum 3D-Pipeline-Zustand 930 auch in der Lage, bestimmte Pipelineelemente gezielt zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird der 3D-Primitiv-Befehl 932 verwendet, um 3D-Primitive, die von der 3D-Pipeline verarbeitet werden sollen, zu versenden. Befehle und zugehörige Parameter, die über den 3D-Primitiv-Befehl 932 an den Graphikprozessor geleitet werden, werden an die Vertex-Abruffunktion in der Graphik-Pipeline weitergeleitet. Die Vertex-Abruf funktion verwendet die Daten des 3D-Primitiv-Befehls 932, um Vertex-Datenstrukturen zu erzeugen. Die Vertex-Datenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der 3D-Primitiv-Befehl 932 verwendet, um Vertex-Operationen an 3D-Primitiven mittels Vertex-Schattierern durchzuführen. Um Vertex-Schattierer zu verarbeiten, sendet die 3D-Pipeline 922 Schattierer-Ausführungsstränge an Graphikprozessor-Ausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Befehl oder ein Ereignis Ausführen 934 ausgelöst. In einigen Ausführungsformen löst ein Registerschreibvorgang eine Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über einen „go“- oder „kick“-Befehl in der Befehlsfolge ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipelinesynchronisationsbefehls ausgelöst, um die Befehlsfolge durch die Graphikpipeline zu bereinigen. Die 3D-Pipeline führt eine Geometrieverarbeitung für die 3D-Primitive aus. Sobald die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixelmaschine färbt die resultierenden Pixel. Zusätzliche Befehle zum Steuern von Pixelschattierungs- und Pixel-Backend-Operationen können für diese Operationen ebenfalls enthalten sein.
In einigen Ausführungsformen folgt die Graphikprozessorbefehlsfolge 910 dem Pfad der Medienpipeline 924, wenn Medienoperationen ausgeführt werden. Im Allgemeinen hängt die spezifische Verwendung und Art der Programmierung für die Medienpipeline 924 von den durchzuführenden Medien- oder Rechenoperationen ab. Bestimmte Mediendecodieroperationen können während der Mediendecodierung in die Medienpipeline ausgelagert werden. In einigen Ausführungsformen kann die Medienpipeline auch umgangen werden und die Mediendecodierung kann ganz oder teilweise unter Verwendung von Betriebsmitteln durchgeführt werden, die von einem oder mehreren Allzweck-Verarbeitungskernen bereitgestellt werden. In einer Ausführungsform umfasst die Medienpipeline auch Elemente für Operationen einer Allzweck-Graphikprozessoreinheit (GPGPU), wobei der Graphikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Rechen-Schattierer-Programmen, die nicht explizit mit dem Rendern von Graphikprimitiven in Zusammenhang stehen, durchzuführen.
In einigen Ausführungsformen ist die Medienpipeline 924 in ähnlicher Weise wie die 3D-Pipeline 922 konfiguriert. Ein Satz von Befehlen zum Konfigurieren des Medienpipelinezustands 940 wird vor den Medienobjektbefehlen 942 an eine Befehlswarteschlange versendet oder in dieser platziert. In einigen Ausführungsformen umfassen die Befehle für den Medienpipelinezustand 940 Daten zum Konfigurieren der Medienpipelineelemente, die zum Verarbeiten der Medienobjekte verwendet werden. Dies umfasst Daten zum Konfigurieren der Videodecodierungs- und Videocodierungslogik in der Medienpipeline wie beispielsweise ein Codierungs- oder Decodierungsformat. In einigen Ausführungsformen unterstützen die Befehle für den Medienpipelinezustand 940 auch die Verwendung von einem oder mehreren Zeigern auf „indirekte“ Zustandselemente, die einen Stapel von Zustandseinstellungen enthalten.
In einigen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger auf Medienobjekte zur Verarbeitung durch die Medienpipeline. Die Medienobjekte weisen Speicherpuffer auf, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medienpipelinezustände gültig sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Sobald der Pipelinezustand konfiguriert ist und die Medienobjektbefehle 942 in die Warteschlange eingereiht sind, wird die Medienpipeline 924 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (z. B. Registerschreibvorgang) ausgelöst. Die Ausgabe aus der Medienpipeline 924 kann dann durch Operationen nachbearbeitet werden, die von der 3D-Pipeline 922 oder der Medienpipeline 924 bereitgestellt werden. In einigen Ausführungsformen werden GPGPU-Operationen auf ähnliche Weise wie Medienoperationen konfiguriert und ausgeführt.
Graphiksoftwarearchitektur
10 zeigt eine beispielhafte Graphiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß einigen Ausführungsformen. In einigen Ausführungsformen umfasst die Softwarearchitektur eine 3D-Graphikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. In einigen Ausführungsformen weist der Prozessor 1030 einen Graphikprozessor 1032 und einen oder mehrere Universalprozessorkerne 1034 auf. Die Graphikanwendung 1010 und das Betriebssystem 1020 werden jeweils in dem Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In einigen Ausführungsformen umfasst die 3D-Graphikanwendung 1010 ein oder mehrere Schattierer-Programme, die Schattierer-Befehle 1012 umfassen. Die Schattierer-Sprachen-Befehle können in einer Schattierer-Hochsprache wie der High Level Shader Language (HLSL) oder der OpenGL Shader Language (GLSL) vorliegen. Die Anwendung weist auch ausführbare Befehle 1014 in einer Maschinensprache auf, die zur Ausführung durch den Allzweck-Prozessorkern 1034 geeignet sind. Die Anwendung weist auch Graphikobjekte 1016 auf, die durch Vertex-Daten definiert sind.
In einigen Ausführungsformen ist das Betriebssystem 1020 das Betriebssystem Microsoft® Windows® der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein UNIX-ähnliches Open-Source-Betriebssystem, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann eine Graphik-API 1022 wie die Direct3D-API, die OpenGL-API oder die Vulkan-API unterstützen. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 1020 einen Frontend-Schattierer-Kompilierer 1024, um alle Schattierer-Befehle 1012 in HLSL in eine Schattierer-Sprache niedrigerer Ebene zu kompilieren. Die Kompilierung kann eine einsatzsynchrone Kompilierung (JIT-Kompilierung) sein oder die Anwendung kann eine Schattierer-Vorkompilierung ausführen. In einigen Ausführungsformen werden Schattierer hoher Ebene während der Kompilierung der 3D-Graphikanwendung 1010 zu Schattierern niedrigerer Ebene kompiliert. In einigen Ausführungsformen werden die Schattierer-Befehle 1012 in einer Zwischenform wie beispielsweise einer Version der von der Vulkan-API verwendeten portierbaren Standard-Zwischendarstellung (SPIR) bereitgestellt.
In einigen Ausführungsformen enthält der Anwendermodus-Graphiktreiber 1026 einen Backend-Schattierer-Kompilierer 1027, um die Schattierer-Befehle 1012 in eine hardwarespezifische Darstellung umzuwandeln. Wenn die OpenGL-API verwendet wird, werden die Schattierer-Befehle 1012 in der GLSL-Hochsprache an einen Anwendermodus-Graphiktreiber 1026 zur Kompilierung geleitet. In einigen Ausführungsformen verwendet der Anwendermodus-Graphiktreiber 1026 Betriebssystemkernelmodusfunktionen 1028, um mit einem Kernelmodus-Graphiktreiber 1029 zu kommunizieren. In einigen Ausführungsformen kommuniziert der Kernelmodus-Graphiktreiber 1029 mit dem Graphikprozessor 1032, um Befehle und Anweisungen zu entsenden.
IP-Kern-Implementierungen
Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch einen repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik innerhalb einer integrierten Schaltung wie eines Prozessors repräsentiert und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Befehle enthalten, die verschiedene Logik innerhalb des Prozessors repräsentieren. Wenn sie von einer Maschine gelesen werden, können die Befehle veranlassen, dass die Maschine die Logik herstellt, um die hierin beschriebenen Techniken durchzuführen. Solche Darstellungen, die als „IP-Kerne“ bekannt sind, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium als ein Hardwaremodell gespeichert werden können, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann an verschiedene Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Herstellungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann derart hergestellt werden, dass die Schaltung Operationen ausführt, die in Verbindung mit irgendeiner der hierin beschriebenen Ausführungsformen beschrieben sind.
11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100 zeigt, das zur Herstellung einer integrierten Schaltung zur Ausführung von Operationen gemäß einer Ausführungsform verwendet werden kann. Das IP-Kern-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Entwürfe zu erzeugen, die in einen größeren Entwurf integriert werden können oder verwendet werden können, um eine gesamte integrierte Schaltung (z. B. eine integrierte SoC-Schaltung) zu konstruieren. Eine Entwurfseinrichtung 1130 kann eine Softwaresimulation 1110 1110 eines IP-Kernentwurfs in einer Programmierhochsprache (z. B. C/C++) erzeugen. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu entwerfen, zu testen und zu verifizieren. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Zeitsteuerungssimulationen beinhalten. Ein Registertransferebenen-Entwurf (RTL-Entwurf) 1115 kann dann aus dem Simulationsmodell 1112 erzeugt oder synthetisiert werden. Der RTL-Entwurf 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Signale zwischen Hardware-Registern modelliert, einschließlich der zugehörigen Logik, die unter Verwendung der modellierten digitalen Signale ausgeführt wird. Neben einem RTL-Entwurf 1115 können auch Entwürfe auf niedrigerer Ebene auf der Logikebene oder der Transistorebene erzeugt, entworfen oder synthetisiert werden. Daher können die speziellen Einzelheiten des anfänglichen Entwurfs und der Simulation variieren.
Der RTL-Entwurf 1115 oder ein Äquivalent kann ferner durch die Entwurfseinrichtung zu einem Hardwaremodell 1120 synthetisiert werden, das in einer Hardwarebeschreibungssprache (HDL) oder einer anderen Darstellung von physischen Entwurfsdaten vorliegen kann. Die HDL kann weiter simuliert oder getestet werden, um den IP-Kernentwurf zu verifizieren. Der IP-Kernentwurf kann zur Lieferung an eine Drittherstellereinrichtung 1165 unter Verwendung eines nichtflüchtigen Speichers 1140 (z. B. Festplatte, Flash-Speicher oder ein beliebiges nichtflüchtiges Speichermedium) gespeichert werden. Alternativ kann der IP-Kernentwurf über eine drahtgebundene Verbindung 1150 oder eine drahtlose Verbindung 1160 (z. B. über das Internet) übertragen werden. Die Herstellungseinrichtung 1165 kann dann eine integrierte Schaltung herstellen, die zumindest teilweise auf dem IP-Kernentwurf basiert. Die hergestellte integrierte Schaltung kann konfiguriert sein, Operationen gemäß mindestens einer hierin beschriebenen Ausführungsform auszuführen.
11B zeigt eine Querschnittsseitenansicht einer Baugruppenanordnung einer integrierten Schaltung 1170 gemäß einigen hierin beschriebenen Ausführungsformen. Die Baugruppenanordnung einer integrierten Schaltung 1170 veranschaulicht eine Implementierung von einer oder mehreren Prozessor- oder Beschleunigervorrichtungen wie hierin beschrieben. Die Baugruppenanordnung 1170 umfasst mehrere Einheiten von Hardwarelogik 1172, 1174, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann zumindest teilweise in konfigurierbarer Logik oder Logikhardware mit fester Funktionalität implementiert sein und kann einen oder mehrere Abschnitte von beliebigen der hierin beschriebenen Prozessorkern(e), Graphikprozessor(en) oder anderen Beschleunigervorrichtungen umfassen. Jede Logikeinheit 1172, 1174 kann innerhalb eines Halbleiter-Chips implementiert und mit dem Substrat 1180 über eine Zwischenverbindungsstruktur 1173 gekoppelt sein. In einigen Ausführungsformen kann die Zwischenverbindungsstruktur 1173 dazu ausgelegt sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 weiterzuleiten, und kann Zwischenverbindungen wie Kontakthügel oder Kontaktsäulen umfassen, ohne darauf beschränkt zu sein. In einigen Ausführungsformen kann die Zwischenverbindungsstruktur 1173 dazu ausgelegt sein, elektrische Signale, wie zum Beispiel Eingabe/AusgabeSignale (E/A-Signale) und/oder Leistungs- oder Massesignale, die dem Betrieb der Logik 1172, 1174 zugeordnet sind, weiterzuleiten. In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidbasis. Das Baugruppensubstrat 1180 kann in anderen Ausführungsformen andere geeignete Typen von Substraten umfassen. Die Baugruppenanordnung 1170 kann über eine Baugruppenzwischenverbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Baugruppenzwischenverbindung 1183 kann an eine Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen wie einer Hauptplatine, einem anderen Chipsatz oder einem Mehrchipmodul weiterzuleiten.
In einigen Ausführungsformen sind die Logikeinheiten 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die dazu ausgelegt ist, elektrische Signale zwischen der Logik 1172, 1174 weiterzuleiten. Die Brücke 1182 kann eine dichte Zwischenverbindungsstruktur sein, die einen Weg für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat umfassen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Merkmale zur elektrischen Weiterleitung können auf dem Brückensubstrat ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Wenngleich zwei Logikeinheiten 1172, 1174 und eine Brücke 1182 veranschaulicht sind, können hierin beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Chips umfassen. Der eine oder die mehreren Chips können durch null oder mehr Brücken verbunden sein, weil die Brücke 1182 weggelassen werden kann, wenn die Logik auf einem einzelnen Chip enthalten ist. Alternativ dazu können mehrere Chips oder Logikeinheiten durch eine oder mehrere Brücken verbunden sein. Außerdem können mehrere Logikeinheiten, Chips und Brücken in anderen möglichen Konfigurationen einschließlich dreidimensionaler Konfigurationen miteinander verbunden sein.
Beispielhafte integrierte Ein-Chip-System-Schaltung
12-14 zeigen beispielhafte integrierte Schaltungen und zugeordnete Graphikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne gemäß verschiedenen hierin beschriebenen Ausführungsformen hergestellt werden können. Zusätzlich zu dem Dargestellten können andere Logik und Schaltungen einschließlich zusätzlicher Graphikprozessoren/-kerne, Peripherieschnittstellen-Controller oder Allzweck-Prozessorkerne enthalten sein.
12 ist ein Blockdiagramm, das eine beispielhafte integrierte Ein-Chip-System-Schaltung 1200, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform zeigt. Die beispielhafte integrierte Schaltung 1200 weist einen oder mehrere Anwendungsprozessoren 1205 (z. B. CPUs) und mindestens einen Graphikprozessor 1210 auf und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 aufweisen, von denen jeder ein modularer IP-Kern aus derselben oder mehreren verschiedenen Entwurfseinrichtungen sein kann. Die integrierte Schaltung 1200 weist eine Peripherie- oder Buslogik auf, die einen USB-Controller 1225, einen UART-Controller 1230, einen SPI/SDIO-Controller 1235 und einen I2S/I2C-Controller 1240 aufweist. Außerdem kann die integrierte Schaltung eine Anzeigevorrichtung 1245 aufweisen, die mit einem Controller für die hochauflösende Multimedia-Schnittstelle (HDMI-Controller) 1250 und einer Mobilindustrie-Prozessorschnittstellen-Anzeigeschnittstelle (MIPI-Anzeigeschnittstelle) 1255 gekoppelt ist. Die Speicherung kann durch ein Flash-Speicher-Untersystem 1260 bereitgestellt sein, das einen Flash-Speicher und einen Flash-Speichercontroller aufweist. Die Speicherschnittstelle kann über einen SpeicherController 1265 für den Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt sein. Einige integrierte Schaltungen weisen zusätzlich eine eingebettete Sicherheitsmaschine 1270 auf.
13A-13B sind Blockdiagramme, die beispielhafte Graphikprozessoren zur Verwendung innerhalb eines SoC gemäß hierin beschriebenen Ausführungsformen zeigen. 13A zeigt einen beispielhaften Graphikprozessor 1310 einer integrierten Ein-Chip-System-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. 13B zeigt einen zusätzlichen beispielhaften Graphikprozessor 1340 einer integrierten Ein-Chip-System-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. Der Graphikprozessor 1310 von 13A ist ein Beispiel eines Graphikprozessorkerns mit niedriger Leistungsaufnahme. Der Graphikprozessor 1340 von 13B ist ein Beispiel eines Graphikprozessorkerns mit höherer Rechenleistung. Die Graphikprozessoren 1310, 1340 können jeweils Varianten des Graphikprozessors 1210 von 12 sein.
Wie es in 13A gezeigt ist, weist der Graphikprozessor 1310 einen Vertexprozessor 1305 und einen oder mehrere Fragmentprozessoren 1315A-1315N (z. B., 1315A, 1315B, 1315C, 1315D, bis 1315N-1, 1315N) auf. Der Graphikprozessor 1310 kann unterschiedliche Schattierer-Programme über eine separate Logik ausführen, so dass der Vertexprozessor 1305 optimiert ist, um Operationen für Vertex-Schattierer-Programme auszuführen, während der eine oder die mehreren Fragmentprozessoren 1315A-1315N Fragment-Schattierungs-Operationen (z. B. Pixel-Schattierungs-Operationen) für Fragment- oder Pixel-Schattierer-Programme ausführen. Der Vertexprozessor 1305 führt die Vertexverarbeitungsstufe der 3D-Graphik-Pipeline durch und erzeigt Primitiv- und Vertexdaten. Der eine oder die mehreren Fragmentprozessoren 1315A-1315N verwenden Primitiv- und Vertexdaten, die durch den Vertexprozessor 1305 erzeugt werden, um einen Einzelbildspeicher zu erzeugen, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform sind der eine oder die mehreren Fragmentprozessoren 1315A-1315N optimiert, um Fragment-Schattierer-Programme auszuführen, die in der OpenGL-API bereitgestellt sind, die verwendet werden kann, um ähnliche Operationen durchzuführen wie ein Pixel-Schattierer-Programm, das in der Direct-3D-API bereitgestellt ist.
Der Graphikprozessor 1310 weist zusätzlich eine oder mehrere Speicherverwaltungseinheiten (MMUs) 1320A-1320B, Cache(s) 1325A-1325B und Schaltungszwischenverbindung(en) 1330A-1330B auf. Die eine oder mehreren MMUs 1320A-1320B stellen eine Virtuell-zu-Physisch-Adresszuordnung für Graphikprozessor 1310 einschließlich des Vertexprozessors 1305 und/oder des einen oder der mehreren Fragmentprozessoren 1315A-1315N auf, die auf Vertex- oder Bild-/Texturdaten verweisen kann, die in dem Speicher gespeichert sind, zusätzlich zu Vertex- oder Bild-/Texturdaten, die in dem einen oder den mehreren Caches 1325A-1325B gespeichert sind. In einer Ausführungsform können die eine oder mehreren MMU(s) 1320A-1320B mit anderen MMUs innerhalb des Systems einschließlich einer oder mehrerer MMUs synchronisiert sein, die dem einen oder den mehreren Anwendungsprozessoren 1205, Bildprozessor 1215 und/oder Videoprozessor 1220 von 12 zugeordnet sind, so dass jeder Prozessor 1205-1220 in einem gemeinsam genutzten oder vereinten virtuellen Speichersystem teilnehmen kann. Die eine oder mehreren Schaltungszwischenverbindungen 1330A-1330B ermöglichen es dem Graphikprozessor 1310 gemäß Ausführungsformen als Schnittstelle zu anderen IP-Kernen innerhalb des SoC zu dienen, entweder über einen internen Bus des SoC oder über eine direkte Verbindung.
Wie es in 13B gezeigt ist, umfasst der Graphikprozessor 1340 die eine oder die mehreren MMU(s) 1320A-1320B, Caches 1325A-1325B und Schaltungszwischenverbindungen 1330A-1330B des Graphikprozessors 1310 von 13A. Der Graphikprozessor 1340 umfasst einen oder mehrere Schattierer-Kerne 1355A-1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), was eine vereinheitlichte Schattierer-Kern-Architektur unterstützt, in der ein einzelner Kern oder Typ oder Kern alle Typen von programmierbarem Schattierer-Code einschließlich Schattierer-Programm-Code zum Implementieren von Vertex-Schattierern, Fragment-Schattierern und/oder Rechen-Schattierern ausführen kann. Die genaue Anzahl von vorhandenen Schattierer-Kernen kann zwischen Ausführungsformen und Implementierungen variieren. Außerdem umfasst der Graphikprozessor 1340 einen Zwischenkernaufgabenmanager 1345, der als ein Strangabfertiger fungiert, um Ausführungsstränge an einen oder mehrere Schattierer-Kernen 1355A-1355N zu senden, und eine Kachelungseinheit 1358 zum Beschleunigen von Kachelungsoperationen für kachelbasiertes Rendern, wobei Render-Operationen für eine Szene in Bildraum unterteilt werden, um zum Beispiel eine lokale räumliche Kohärenz innerhalb einer Szene zu nutzen oder um die Verwendung von internen Caches zu optimieren.
14A-14B zeigen eine zusätzliche beispielhafte Graphikprozessorlogik gemäß hierin beschriebenen Ausführungsformen. 14A zeigt einen Graphikkern 1400, der innerhalb des Graphikprozessors 1210 von 12 enthalten sein kann und ein vereinheitlichter Schattierer-Kern 1355A-1355N wie in 13B sein kann. 14B zeigt eine zusätzliche, in hohem Maße parallele Universalgraphikverarbeitungseinheit 1430, die eine in hohem Maße parallele Universalgraphikverarbeitungseinheit ist, die zum Einsatz auf einem Mehrchipmodul geeignet ist.
Wie es in 14A gezeigt ist, umfasst der Graphikkern 1400 einen gemeinsam genutzten Befehls-Cache 1402, eine Textureinheit 1418 und einen Cache/geteilten Speicher 1420, die den Ausführungsbetriebsmitteln innerhalb des Graphikkerns 1400 gemein sind. Der Graphikkern 1400 kann mehrere Slices 1401A-1401N oder eine Partition für jeden Kern umfasst und ein Graphikprozessor kann mehrere Instanzen des Graphikkerns 1400 umfassen. Die Slices 1401A-1401N können Unterstützungslogik, einschließlich eines lokalen Befehls-Caches 1404A-1404N, eines Strangplaners 1406A-1406N, eines Strangabfertigers 1408A-1408N und eines Satzes von Registern 1410A-1440N umfassen. Zum Durchführen von logischen Operationen können die Slices 1401A-1401N einen Satz von zusätzlichen Funktionseinheiten (AFUs, 1412A-1412N), Gleitkommaeinheiten (FPUs, 1414A-1414N), arithmetischlogischen Ganzzahl-Einheiten (ALUs, 1416-1416N), Adressrecheneinheiten (ACUs, 1413A-1413N), Gleitkommaeinheiten mit doppelter Genauigkeit (DPFPUs, 1415A-1415N) und Matrixverarbeitungseinheiten (MPUs, 1417A-1417N) umfassen.
Einige der Recheneinheiten arbeiten mit einer spezifischen Genauigkeit. Zum Beispiel können die FPUs 1414A-1414N Gleitkommaoperationen mit einfacher Genauigkeit (32 Bit) und mit 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 einer Genauigkeit von 8 Bit, 16 Bit und 32 Bit durchführen und können für Operationen mit gemischter Genauigkeit ausgelegt sein. Die MPUs 1417A-1417N können auch für Matrixoperationen mit gemischter Genauigkeit, einschließlich Gleitkommaoperationen mit halber Genauigkeit und 8-Bit-Ganzzahloperationen, ausgelegt sein. Die MPUs 1417-1417N können eine Vielfalt von Matrixoperationen durchführen, um Anwendungsrahmen für maschinelles Lernen zu beschleunigen, einschließlich des Ermöglichens einer Unterstützung für eine beschleunigte allgemeine Matrix-zu-Matrix-Multiplikation (GEMM). Die AFUs 1412A-1412N können zusätzliche logische Operationen durchführen, die von den Gleitkomma- oder Ganzzahleinheiten nicht unterstützt werden, einschließlich trigonometrischer Operationen (z. B. Sinus, Kosinus usw.).
Wie es in 14B gezeigt ist, kann eine Universalverarbeitungseinheit (GPGPU) 1430 dazu ausgelegt sein, zu ermöglichen, dass in hohem Maße parallele Rechenoperationen von einem Array von Graphikverarbeitungseinheiten durchgeführt werden. Außerdem kann die GPGPU 1430 direkt mit anderen Instanzen der GPGPU verbunden sein, um einen Multi-GPU-Cluster zu erstellen, um die Trainingsgeschwindigkeit für besonders tiefe neuronale Netze zu verbessern. Die GPGPU 1430 umfasst eine Host-Schnittstelle 1432, um eine Verbindung mit einem Host-Prozessor zu ermöglichen. In einer Ausführungsform ist die Host-Schnittstelle 1432 eine PCI-Express-Schnittstelle. Die Host-Schnittstelle kann jedoch auch eine anbieterspezifische Kommunikationsschnittstelle oder Kommunikationsstruktur sein. Die GPGPU 1430 empfängt Befehle von dem Host-Prozessor und verwendet einen globalen Scheduler 1434 zum Verteilen von Ausführungs-Strängen, die diesen Befehlen zugeordnet sind, auf einen Satz von Rechen-Clustern 1436A-1436H. Die Rechen-Cluster 1436A-1436H teilen sich einen Cache-Speicher 1438. Der Cache-Speicher 1438 kann als ein Cache höherer Ebene für Cache-Speicher innerhalb der Rechen-Cluster 1436A-1436H dienen.
Die GPGPU 1430 umfasst Speicher 14434A-14434B, der über einen Satz von Speichercontrollern 1442A-1442B mit den Rechen-Clustern 1436A-1436H gekoppelt ist. In verschiedenen Ausführungsformen kann der Speicher 1434A-1434B verschiedene Typen von Speichervorrichtungen einschließlich dynamischen Speichers mit wahlfreiem Zugriff (DRAM) oder Graphikdirektzugriffsspeicher wie synchronen Graphikdirektzugriffsspeicher (SGRAM) einschließlich Graphikspeicher mit doppelter Datenrate (GDDR) umfassen.
In einer Ausführungsform umfassen die Rechen-Cluster 1436A-1436H jeweils einen Satz von Graphikkernen wie etwa den Graphikkern 1400 von 14A, die mehrere Typen von Ganzzahl- und Gleitkommalogikeinheiten umfassen können, die Rechenoperationen in einem Bereich von Genauigkeiten durchführen können, auch für Berechnungen des maschinellen Lernens geeignet. Zum Beispiel und in einer Ausführungsform kann zumindest ein Teilsatz der Gleitkommaeinheiten in jedem der Rechen-Cluster 1436A-1436H dazu ausgelegt sein, 16-Bit- oder 32-Bit-Gleitkommaoperationen durchzuführen, während ein verschiedener Teilsatz der Gleitkommaeinheiten dazu ausgelegt sein kann, 64-Bit-Gleitkommaoperationen durchzuführen.
Mehrere Instanzen der GPGPU 1430 können dazu ausgelegt sein, als ein Rechen-Cluster zu fungieren. Der von dem Rechen-Cluster zur Synchronisierung und zum Datenaustausch verwendete Kommunikationsmechanismus variiert zwischen Ausführungsformen. In einer Ausführungsform kommunizieren die mehreren Instanzen der GPGPU 1430 über die Host-Schnittstelle 1432. In einer Ausführungsform umfasst die GPGPU 1430 einen E/A-Hub 1439, der die GPGPU 1430 mit einem GPU-Link 1440 koppelt, der eine Direktverbindung zu anderen Instanzen der GPGPU ermöglicht. In einer Ausführungsform ist der GPU-Link 1440 an eine dedizierte GPU-zu-GPU-Brücke gekoppelt, die eine Kommunikation und Synchronisierung zwischen mehreren Instanzen der GPGPU 1430 ermöglicht. In einer Ausführungsform koppelt der GPU-Link 1440 mit einer Hochgeschwindigkeitszwischenverbindung, um Daten zu anderen GPGPUs oder parallelen Prozessoren zu senden und zu empfangen. In einer Ausführungsform befinden sich die mehreren Instanzen der GPGPU 1430 in separaten Datenverarbeitungssystemen und kommunizieren über eine Netzvorrichtung, die über die Host-Schnittstelle 1432 zugänglich ist. In einer Ausführungsform kann der GPU-Link 1440 dazu ausgelegt sein, eine Verbindung zu einem Host-Prozessor zusätzlich zu oder alternativ zu der Host-Schnittstelle 1432 zu ermöglichen.
Während die veranschaulichte Konfiguration der GPGPU 1430 dazu ausgelegt sein kann, neuronale Netze zu trainieren, stellt eine Ausführungsform eine alternative Konfiguration der GPGPU 1430 bereit, die zur Bereitstellung innerhalb einer Inferenzplattform mit hoher Rechenleistung oder niedriger Leistungsaufnahme ausgelegt sein kann. In einer Inferenzkonfiguration umfasst die GPGPU 1430 weniger der Rechen-Cluster 1436A-1436H Im Vergleich zu der Trainingskonfiguration. Außerdem kann sich die Speichertechnologie, die dem Speicher 1434A-1434B zugeordnet ist, zwischen Inferenz- und Trainingskonfigurationen unterscheiden, wobei Speichertechnologien mit höherer Bandbreite für Trainingskonfigurationen verwendet werden. In einer Ausführungsform kann die Inferenzkonfiguration der GPGPU 1430 inferenzspezifische Befehle unterstützen. Zum Beispiel kann eine Inferenzkonfiguration Unterstützung für eine oder mehrere 8-Bit-Ganzzahlskalarprodukt-Befehle bereitstellen, die gemeinhin während Inferenzoperationen für bereitgestellte neuronale Netze verwendet werden.
System und Verfahren zur Detektion von Änderungen gerenderter Szenen mit ferngehosteten Graphikanwendungen
Ausführungsformen der Erfindung verringern die Bandbreite, ohne die Codiererlatenz für ein gestreamtes 3D-Spiel oder eine andere Anwendung zu erhöhen, wenn das Spiel eine große Szenenänderung ausführt, die an dem Codierer nicht vorhergesagt ist (und somit zu einer Erhöhung der Video-Stream-Bitrate führen würde oder die visuelle Qualität verschlechtern würde). Ein Vorcodierer führt eine Szenenänderungsdetektion unter Verwendung von Daten durch, die während der 3D-Renderphase gesammelt wurden, ohne dass zusätzliche Latenz eingebracht wird.
Das Verfahren basiert kurz gesagt auf dem Sammeln von Hardware- oder Software-Zählern aus der GPU-Perspektive auf die 3D-Spiel-Renderphase und deren Weitergabe als Metadaten an den intelligenten Codierer, der sowohl von der darin vordefinierten Fuzzy-Logik als auch mit verzögerten Informationen aus dem Codierer darüber, ob die Szenendetektion erwartet wurde oder nicht, geschult ist.
Wie erwähnt, wird ein Fern-3D-Spiel auf einem Server mit einer Hochleistungs-CPU und einer GPU in einem entfernten Rechenzentrum als Antwort auf Steuersignale, die von dem Anwender während des Spielens (z. B. über einen Spielecontroller oder eine Tastatur) erzeugt werden, verarbeitet und gerendert. Die von der 3D-Maschine erzeugten Einzelbilder werden codiert/komprimiert und über das Internet oder ein proprietäres Netz an Client-Vorrichtungen von Anwendern gestreamt. Ein Nutzer einer CPU/GPU geringer Leistung kann das Spiel mit akzeptabler Anwendererfahrung spielen, da die gesamte betriebsmittelintensive 3D-Arbeit von dem Server ausgeführt wird. Der Client muss nur in der Lage sein, komprimierte Videoströme wie H.264-, H.265-, VP8-, VP9- oder AV1-Videoströme zu decodieren.
Codierte Videoströme umfassen typischerweise I-Einzelbilder, P-Einzelbilder und B-Einzelbilder, die in einer Gruppe von Bildern (GOP) angeordnet sind. Insbesondere enthält jede GOP ein einzelnes I-Einzelbild, das als das Start-Einzelbild betrachtet wird, intracodiert ist und keinen Vorgänger benötigt. Die auf das I-Einzelbild folgenden P-Einzelbilder (prädiktiv codierten Bilder) enthalten bewegungskompensierte Differenzdaten, die Änderungen relativ zu zuvor codierten Bildern (in dem I-Einzelbild oder einem anderen P-Einzelbild) angeben. B-Einzelbilder sind bidirektional prädiktiv, so dass ein Einzelbild ein Vorgänger und eines ein Nachfolger sein muss.
Echtzeit-3D-Spiele verwenden hauptsächlich I-Einzelbilder und P-Einzelbilder, um die Latenz zu verringern (da B-Einzelbilder eine Latenz von 2 Einzelbildern erfordern, um das nachfolgende Einzelbild zu berücksichtigen). P-Einzelbilder sind nur in Fällen sehr effektiv, in denen sich die aufeinanderfolgenden codierten Einzelbilder nicht zu stark ändern, da ihre Bewegungskompensation nicht effizient berechnet werden kann und es vorkommen kann, dass die Delta-Informationen größer sind als ein intracodiertes Einzelbild. Dies ist ein Zustand, der beispielsweise während Szenewechseln oder infolge menschlicher Interaktion auftritt. Zum Beispiel kann sich die Zusammensetzung gerenderter Szenen schnell ändern, weil die Tür zu dem nächsten Raum in einem Spiel geöffnet wird, ein Auto schnell gewendet wird oder weil eine Explosion den größten Teil der Szene schnell überdeckt.
Eine Ausführungsform der Erfindung verwendet Wechselwirkungen zwischen der 3D-Spielmaschine und dem Videocodierer, was zu einer Pipeline führt, die Szenenänderungen detektieren kann, die zu einer nicht optimalen P-Einzelbild-Codierung führen würden (aufgrund von Grenzratenbeschränkungen), und Situationen identifizieren kann, in denen ein I-Einzelbild effizienter wäre. Insbesondere wird, wie es in 15 dargestellt ist, eine Maschinenlernmaschine 1520 in einer Ausführungsform verwendet, um eine Korrelation zwischen spezifizierten 3D-Graphikverarbeitungsdaten und Detektionsergebnissen, die von dem Codierer 1510 geliefert werden, durchzuführen. Weil der Codierer 1510 das korrekte Detektionsergebnis mit einer Verzögerung von einem einzelnen Einzelbild bestimmt, kann die Maschinenlernmaschine 1520 ohne wesentliche Verzögerung durchgehend trainiert werden. Wenn die Maschinenlernmaschine 1520 ausreichend trainiert wurde, kann sie das korrekte Detektionsergebnis mit einem hohen Maß an Genauigkeit vorhersagen. Der Codierer 1510 kann diese Vorhersagen verwenden, um Entscheidungen effizienter zu treffen.
15 zeigt auch einen beispielhaften Client 1540 und verschiedene andere Komponenten, die von einem oder mehreren 3D-Spieleservern 1530 implementiert werden. Im Betrieb wird eine Anwendereingabe 1501, die von einem Gamecontroller, einer Tastatur, einer Maus oder einer anderen Eingabevorrichtung geliefert wird, zur Übertragung an die Spieleserver 1530 erfasst. Die Anwendereingabe 1501 kann Folgen von Befehlen zum Steuern des aktuell gespielten Spiels umfassen (z. B. auf die gleiche Weise, wie die Befehle erzeugt würden, wenn der Anwender das Spiel lokal auf einer Spielekonsole oder einem Computer spielen würde). Die Befehle werden durch eine Netzschnittstelle 1502 paketiert und über ein Netz (z. B. unter Verwendung von TCP- und/oder UDP-Paketen, wenn das Netz das Internet ist) an die Spieleserver 1530 übertragen.
Eine Netzschnittstelle 1503 eines der 3D-Spieleserver 1530 entpackt die Befehle gemäß dem zugrundeliegenden Netzprotokoll und ein Eingabeabspielmodul 1504 führt die Befehle auf einer laufenden 3D-Spielinstanz 1508 aus. Obwohl in 15 nicht gezeigt, kann die Spielinstanz 1508 auf einer virtuellen Maschine (VM) in einer virtuellen Ausführungsumgebung ausgeführt werden, die die zugrundeliegenden Graphikverarbeitungsbetriebsmittel der 3D-Spielserver 1530 wie z. B. die GPU 1506 virtualisiert. Die Virtualisierungsumgebung kann einen Hypervisor, einen Überwacher virtueller Maschinen (VMM) oder andere Techniken zum Virtualisieren einer GPU und/oder CPU verwenden.
Unabhängig von der Plattform, auf der die 3D-Spielinstanz 1508 ausgeführt wird, greift sie auf die 3D-Graphikverarbeitungsbetriebsmittel einer GPU 1506 (oder eines Teils einer GPU) zu, indem sie eine 3D-Render-API 1507 aufruft. Die GPU 1506 führt 3D-Render-Operationen zum Erzeugen jedes Einzelbilds des Spiels aus. Ein Audio/Video-Aufnahmemodul (A/V-Aufnahmemodul) 1509 nimmt den Videostrom auf, der normalerweise lokal auf einer Anzeige wie etwa einem Fernseher oder einer Computer/Tablet-Anzeige angezeigt wird, und ein Codierer 1510 codiert/komprimiert jedes Videobild unter Verwendung der hierin beschriebenen Techniken. Wie erwähnt analysiert die Maschinenlernmaschine 1520 fortlaufend Daten, die von der 3D-Spielinstanz geliefert werden, im Hinblick auf Codiererergebnisse, um Korrelationen zu erlernen. Die Maschinenlernmaschine 1520 kann dann dem Codierer 1510 auf der Basis von Daten, die von der 3D-Spielinstanz 1508 bereitgestellt werden, Empfehlungen liefern, wie das aktuelle Einzelbild codiert werden sollte (z. B. ein neues I-Einzelbild oder P-Einzelbild erzeugen). Der von dem Codierer 1510 erzeugte codierte/komprimierte Videostrom wird paketiert und mittels der Netzschnittstelle 1511 über das Netz übertragen.
Eine Netzschnittstelle 1512 auf dem Client 1540 empfängt und entpackt den codierten Videostrom und der A/V-Decodierer 1513 decodiert den Videostrom gemäß dem zugrundeliegenden verwendeten Videokomprimierungsprotokoll (z. B. H.264). Die resultierenden decodierten Videobilder werden auf einer Anzeige 1515 unter der Steuerung eines A/V-Spielers 1514 wiedergegeben. In einer Ausführungsform sind die Anwendereingabe 1501, der A/V-Decodierer 1513 und der A/V-Spieler 1514 als clientseitige Software implementiert, die auf einer CPU des Clients 1540 läuft.
16 zeigt eine Ausführungsform der Maschinenlernmaschine 1520, die einen Fuzzy-Logik-Detektor 1601, einen Fuzzy-Logik-Codierer-Vermittler 1602 und ein neuronales Netz 1603 umfasst. Dargestellt ist auch der Codierer 1604, der Einzelbilder 1600 codiert und eine Szenenänderungsdetektionsergebnisse an den Fuzzy-Logik-Detektor 1601 und das neuronale Netz 1603 liefert.
In einer Ausführungsform nimmt der Fuzzy-Logik-Detektor 1601 Eingaben von der 3D-Render-Pipeline der 3D-Spielinstanz 1508 entgegen und führt eine Analyse durch, um Empfehlungen zu machen, ob ein neues I-Einzelbild oder P-Einzelbild erzeugt werden soll. Beispielsweise werden in einer Implementierung Parameter wie Zählwerte und Deltas zwischen den Parametern aufeinanderfolgender Einzelbilder für jedes gerenderte Einzelbild verfolgt (z. B. Deltas von Parametern für Einzelbild [i] und Einzelbild [i-1]; Einzelbild [i+1] und Einzelbild [i] usw.). Diese Parameter/Deltas können von dem Fuzzy-Logik-Detektor 1601 über eine Pipeline-Abfrage an die 3D-Render-Pipeline, die diese Werte verfolgt, gesammelt werden. In einer Ausführungsform vergleicht der Fuzzy-Logik-Detektor 1601 die Differenzen dieser Werte über aufeinanderfolgende Einzelbilder hinweg mit einer Menge von Schwellen, um zu bestimmen, ob ein neues I-Einzelbild oder ein neues P-Einzelbild erzeugt werden sollte. Beispielsweise können bestimmte Arten von Werten eine Szenenänderung angeben, wenn gemessen wird, dass sie sich zwischen Bildern radikal ändern.
In einer Ausführungsform ist der Fuzzy-Logik-Detektor 1601 mit schwachen und starken Schwellen für mehrere festcodierte heuristische Kreuzparameterfunktionen programmiert. Beispielsweise können die Deltas von Vertices (3 pro Dreieck), Deltas der von dem Pixel-Schattierer verarbeiteten Pixel und Deltas für frühe Tiefentestfehler (z. B. Pixel, die auf der Basis des hierarchischen Z-Puffers oder Pro-Pixel-Tiefentest verworfen wurden) in erster Linie als negatives Korrelat für den Szenenwechsel verwendet werden. Im Allgemeinen können alle Informationen verwendet werden, die mit Änderungen in aufeinanderfolgenden Einzelbildern korreliert sein können, einschließlich Pipeline-Statistiken, auf GPUs verfügbaren Standardzählern (z. B. basierend auf Standards wie OpenGL), proprietären Zählern. Beispielhaft und nicht einschränkend können die folgenden zusätzlichen Daten von dem Fuzzy-Logik-Detektor 1601 verwendet werden.
A. Pipeline-Statistik -> kann auf modernen GPUs implementiert werden und kann von der Hardware mit einer Pipeline-Abfrage gelesen werden, zum Beispiel:

• Vertices - Vertices (3 pro Dreieck), die an die 3D-Pipeline übergeben werden
• Grundformen - Grundformen, die von der Clipper-Stufe ausgegeben werden
• Pixel-Schattierer-Aufrufe - Pixel, die von dem Pixel-Schattierer verarbeitet werden
• Mantel-Schattierer-Aufrufe - geteilte Mantel-Aufrufe deuten in der Regel stark auf eine Änderung der Render-Technik hin
• Domain-Schattierer-Aufrufe - diese Aufrufe deuten in der Regel stark auf eine Änderung der Render-Technik usw. hin.

B. Andere auf GPUs verfügbare Zähler:

• Einzelbild-Renderzeit
• Früher Tiefentest schlägt fehl: Pixel, die vor der Pixel-Schattierer-Stufe basierend auf hierarchischem Z oder einem Pro-Pixel-Tiefentest verworfen wurden, können in erster Linie als negatives Korrelat für die Szenenänderungen verwendet werden
• Farbmischungen pro Pixel: können auf signifikante Transparenzänderungen in der Szene hinweisen
• Cache letzter bis mittlerer Ebene erleidet Fehltreffer: erhöhte Cache-Fehltreffer weisen darauf hin, dass für ein erheblich abgewandeltes Einzelbild neuer Inhalt erstellt wird
• GPU-Speicher-Lese- und Schreibvorgänge aus dem Renderer
• Strangbelegungsmetriken für GPU-Ausführungseinheiten einschließlich der allgemeinen Strangbelegung und der pro Schattierer-Typ
• Abtaster, Farb-Cache, Render-Cache-Zugriffe usw.
• Farb-Cache-Farbkomprimierungen -> Dies ist ein nützlicher Zähler, da er über die Entropieänderung informiert

C. Softwarezähler: Jegliche Schattiere-Programmänderungen, die mit Änderungen zwischen Einzelbildern korreliert werden können.
Zahlreiche unterschiedliche Schwellen können eingestellt werden, um es dem Fuzzy-Logik-Detektor 1601 zu ermöglichen, schwache und starke Hinweise zu identifizieren. Beispielsweise kann eine schwache Hinweisschwelle ein Parameter-Delta von 10 % bis 19 % sein und eine starke Hinweisschwelle ein Parameter-Delta von 20 % und mehr sein. In Abhängigkeit von der Konfiguration kann ein feinerer Kategorisierungsgrad verwendet werden, bei dem zusätzliche Schwellen (z. B. niedrig, mittel, hoch) auf unterschiedliche Prozentsätze eingestellt werden.
In einer Ausführungsform können die Codierungsergebnisse analysiert werden, um die verschiedenen Schwellen anzupassen. Wenn beispielsweise ein P-Einzelbild für ein aktuelles Einzelbild größer als ein letztes I-Einzelbild ist, können die Parameter, die die signifikantesten Deltas aufweisen, ein größeres Gewicht beim Detektieren eines Szenenwechsels erhalten. Die schwachen und starken Schwellen können auch auf niedrigere Werte eingestellt werden, um die Genauigkeit des Detektionssystems zu verbessern.
Im Gegensatz dazu können, wenn der Codierer zu viele Hinweise auf die Szenenänderung erhält (z. B. unter Umständen, unter denen ein P-Einzelbild effizienter wäre), die Schwellen erhöht werden, um falsch positive Ergebnisse zu reduzieren. Der Codierer kann zum Beispiel auch überwachen, ob ein schwacher Hinweis auf eine Szenenänderung real ist, indem er eine P-Einzelbild-Codierung außerhalb des Zyklus durchführt und sie mit der Größe des I-Einzelbilds vergleicht. Ein solches P-Einzelbild erhöht die Gesamtlatenz nicht, da es nicht an den Anwender gesendet oder in anderen Phasen verarbeitet wird.
In einer Ausführungsform wird das neuronale Netz 1603 auch als Szenenänderungsdetektor verwendet und wird basierend auf Eingaben von dem Fuzzy-Logik-Detektor 1601 und dem Codierer 1510 mit einer Verzögerung von einem Einzelbild aktiv lernen. Der Codierer-Vermittler 1602 empfängt einen ersten Szenenänderungshinweis von dem Fuzzy-Logik-Detektor 1601 (z. B. schwach/stark, wenn er über einer Schwelle liegt) und einen zweiten Szenenänderungshinweis von dem neuronalen Netz 1603. Der Fuzzy-Logik-Detektor 1601 arbeitet auf einem akzeptablen Genauigkeitsniveau für typische Szenenänderungen (z. B. 70-80 % Genauigkeit) und liefert auch Ergebnishinweise an das neuronale Netz 1603 (z. B. schwache/starke Hinweise und ein Fuzzy-Logik-Gesamtergebnis), um zusätzliche Lerneingaben bereitzustellen. Bevor das neuronale Netz ausreichend trainiert wurde, wird der Codierer-Vermittler 1602 das Ergebnis des Fuzzy-Logik-Detektors 1601 bevorzugen, das er an den Codierer 1510 liefert. In dieser Ausführungsform kann der Codierer-Vermittler 1602 so programmiert sein, dass er weiß, wie viel Training das neuronale Netz 1603 erhalten hat und wird seine Auswahl basierend auf diesen Informationen treffen. Nachdem das neuronale Netz 1603 für eine bestimmte Zeitspanne trainiert wurde (so dass es eine größere Genauigkeit aufweist als der Fuzzy-Logik-Detektor 1601 allein), kann der Codierer-Vermittler 1602 dem Ergebnis des neuronalen Netzes 1603 mehr Gewicht verleihen.
Verschiedene 3D-Spiele können je nach ihrer speziellen Konfiguration unterschiedliche Eigenschaften wie beispielsweise die Anzahl von Vertices oder gerenderten Pixeln aufweisen. Infolgedessen kann die genaue Kreuzkorrelation von Zählern und anderen Informationen, die von dem Renderer an den Detektor weitergegeben werden, für bestimmte Spiele-Maschinen möglicherweise nicht erraten werden. Diese Kreuzkorrelationen werden durch die hierin beschriebenen Techniken des neuronalen Netzes 1603 adaptiv gelernt (d. h. unter Verwendung der Fehlerrückausbreitung von dem Codierer 1510). Der Fuzzy-Logik-Detektor 1601 kann die bestmögliche Gegenkorrelationsheuristik unter Verwendung einer Datenbank aktueller 3D-Spiele empirisch finden. Wenn der Fuzzy-Logik-Detektor 1601 die genaueste Zählerkorrelation geladen hat, liefert er genaue Anfangsergebnisse und das Weiterleiten des Wahrscheinlichkeitsergebnisses des Fuzzy-Logik-Detektors 1601 an das neuronale Netz 1603 sorgt für ein effizienteres Lernen.
In den oben beschriebenen Ausführungsformen wird die 3D-Render-API wie Direct3DX, OpenGL, Vulcan oder Metal abgefragt, um die Daten zu sammeln, die zum Bestimmen des Betriebs des Codierers verwendet werden. Dies wird als „Abfängerschicht“ für die API bezeichnet. Aus der Sicht des API-Abfängers tragen neben den hier beschriebenen Abfragen alle anderen 3D-Render-API-Aufrufe zum Rendern des Einzelbilds bei. Die Abfängerschicht sammelt zusätzliche Parameter der verwendeten API und kann auch die GPU nach den hardware implementierten und gesammelten Zählern abfragen. Andere Informationen, die von der Abfängerschicht gesammelt werden, sind die Anzahl der spezifischen API-Aufrufe, wie beispielsweise des Zeichen-API-Aufrufs, der auf einem hohen Niveau auf irgendeine prozedurale Änderung des gerenderten Einzelbilds hinweist.
Die pro Einzelbild gesammelten Parameter werden mit den Werten der gleichen Parameter aus dem vorherigen Einzelbild verglichen. Das relative Delta zwischen den beiden Einzelbildern wird berechnet und als Metadaten an den Codierer 1510, den Fuzzy-Logik-Detektor 1601 oder das neuronale Netz 1603 weitergeleitet.
17 zeigt zusätzliche Einzelheiten für ein neuronales 2-Schicht-Netz 1603 zur Szenenänderungsdetektion. Das Netzlernen wird unter Verwendung von Eingaben wie der unmittelbaren Ergebnisrückkopplung für das aktuelle Einzelbild und der um 1 Einzelbild verzögerten Rückkopplung für das vorherige Einzelbild durchgeführt. In dieser speziellen Implementierung wird die unmittelbare Rückmeldung von den starken/schwachen Detektionsergebnissen des Fuzzy-Logik-Detektors und/oder seinem Wahrscheinlichkeitsergebnis, der Angabe zu häufiger Szenenänderungsdetektionen von dem endgültigen Fuzzy-Logik-Vermittler 1602 und dem endgültigen Detektionsergebnis bereitgestellt. Das aktuell korrekte Ergebnis wird bei 1701 bestimmt und zum Lernen an das neuronale Netz 1603 zurückübertragen. In ähnlicher Weise wird die Rückkopplung des um 1 Einzelbild verzögerten Ergebnisses bei 1702 (z. B. durch den Codierer) bestimmt und zum Lernen an das neuronale Netz 1603 zurückübertragen.
In dieser Ausführungsform ist die erste Stufe 1705 des neuronalen Netzes 1603 Parameterkorrelationsfunktionen gewidmet. Beispielsweise erhält jedes Parameterkorrelationsneuron anfänglich ein durch Fuzzy-Logik gesteuertes Standard-Gewicht und/oder zufälliges Anfangsgewicht, so dass sie Parameteränderungen kreuz korrelieren (z. B. werden einige von ihnen stark positiv korreliert, stark negativ korreliert oder nicht korreliert sein). Die zweite Stufe 1706 des neuronalen Netzes ist ein einzelnes Neuron mit jedem Ausgang der Neuronen der ersten Stufe 1705 zugeordneten Gewichten. Wie erwähnt werden die Gewichte von jedem der Neuronen der ersten Stufe abhängig von der Analyse der Rückkopplungsergebnisse fortlaufend erhöht oder verringert.
Eine Ausführungsform eines Verfahrens ist in 18 dargestellt. Das Verfahren kann auf den oben beschriebenen Architekturen implementiert werden, ist jedoch nicht auf eine bestimmte Architektur beschränkt.
Bei 1801 werden Datensätze, die dem aktuellen Einzelbild zugeordnet sind, von der 3D-Render-Maschine abgerufen. Wie bereits erwähnt kann die 3D-Render-API abgefragt werden, um verschiedene Datentypen zu lesen, ohne die Latenz zu beeinträchtigen. Bei 1802 werden die Datensätze mit entsprechenden Datensätzen aus einem vorherigen Einzelbild verglichen. Wenn eine schwache oder starke Schwelle erreicht ist, was bei 1803 bestimmt wird, wird dieser Hinweis bei 1804 an das neuronale Netz geliefert und bei 1805 analysiert das neuronale Netz die Datensätze für das aktuelle Einzelbild auf der Grundlage entsprechender Datensätze aus einem vorherigen Einzelbild und bewertet auch den schwachen/starken Hinweis. Wenn kein schwacher/starker Hinweis bereitgestellt wird, analysiert das neuronale Netz die Datensätze für das aktuelle Einzelbild basierend auf entsprechenden Datensätzen aus einem vorherigen Einzelbild.
Bei 1808 erzeugt das neuronale Netz basierend auf seiner Analyse einen Szenenänderungshinweis/Nicht-Szenenänderungshinweis. Der Hinweis wird an den Codierer geliefert, der das aktuelle Einzelbild codiert und das neuronale Netz über das Ergebnis benachrichtigt (z. B. ob ein I-Rahmen oder ein P-Rahmen erzeugt wurde). Nachdem das System über einen bestimmten Zeitraum trainiert wurde, kann sich der Codierer auf den von dem neuronalen Netz gelieferten Szenenänderungshinweis/Nicht-Szenenänderungshinweis verlassen. Bis zu diesem Zeitpunkt kann sich der Codierer jedoch auf die Empfehlung des Fuzzy-Logik-Detektors verlassen oder einfach das nächsten Einzelbild codieren, wie dies normalerweise ohne ein neuronales Netz oder einen Fuzzy-Logik-Detektor der Fall wäre.
Beispiele
Im Folgenden sind beispielhafte Implementierungen verschiedener Ausführungsformen der Erfindung dargelegt.
Beispiel 1. Verfahren, das Folgendes umfasst: Abrufen von Datensätzen aus einer 3D-Graphikmaschine, wobei die Datensätze einem aktuellen Einzelbild zugeordnet sind, das von der 3D-Graphikmaschine gerendert wird; und Analysieren der Datensätze im Hinblick auf entsprechende Datensätze aus einem vorherigen Einzelbild, um einen ersten Codierungstyp zu bestimmen, der zum Codieren des aktuellen Einzelbilds vor der Übertragung über ein Netz verwendet werden soll.
Beispiel 2. Das Verfahren von Beispiel 1, wobei das Analysieren der Datensätze ein Durchführen einer Fuzzy-Logik-Detektion an den Datensätzen, die dem aktuellen Einzelbild zugeordnet sind, und den entsprechenden Datensätzen aus dem vorherigen Einzelbild umfasst, um den ersten Codierungstyp zu schätzen.
Beispiel 3. Das Verfahren von Beispiel 1, wobei der erste Codierungstyp aus einer Gruppe ausgewählt ist, die aus Intra-Einzelbild-Codierung und prädiktiver Codierung besteht.
Beispiel 4. Das Verfahren nach Beispiel 3, wobei die Intra-Einzelbild-Codierung eine I-Einzelbild-Codierung und die prädiktive Codierung eine P-Einzelbild-Codierung umfasst.
Beispiel 5. Das Verfahren von Beispiel 3, das ferner umfasst: Auswählen eines Codierungstyps aus entweder Intra-Einzelbild-Codierung oder prädiktiver Codierung durch einen Codierer; Codieren des aktuellen Einzelbilds durch den Codierer unter Verwendung der gewählten Codierung aus Intra-Einzelbild-Codierung oder prädiktiver Codierung; und Benachrichtigen eines neuronalen Netzes über den ausgewählten Codierungstyp.
Beispiel 6. Das Verfahren von Beispiel 5, das ferner umfasst: Analysieren des ausgewählten Codierungstyps im Hinblick auf die Datensätze, die dem aktuellen Einzelbild zugeordnet sind, und die entsprechenden Datensätze aus dem vorherigen Einzelbild durch das neuronale Netz; und Bestimmen einer Korrelation zwischen dem ausgewählten Codierungstyp und Differenzen zwischen den Datensätzen, die dem aktuellen Einzelbild zugeordnet sind, und den Datensätzen, die dem vorherigen Einzelbild zugeordnet sind, basierend auf der Analyse.
Beispiel 7. Das Verfahren von Beispiel 6, wobei das Entwickeln der Korrelation Folgendes umfasst: Anpassen eines Gewichts, das einer oder mehreren Verbindungen zwischen einer Menge von Neuronen der ersten Ebene und einem oder mehreren Neuronen der zweiten Ebene zugeordnet ist.
Beispiel 8. Das Verfahren von Beispiel 7, wobei jedes Neuron der ersten Ebene einem der Datensätze und entsprechenden Datensätze zugeordnet ist.
Beispiel 9. Das Verfahren von Beispiel 8, wobei die Datensätze und entsprechenden Datensätze eines oder mehrere der folgenden Elemente umfassen: 3D-Pipeline-Statistiken, die von der 3D-Render-Maschine, Hardware-Zählern oder Software-Zählern gesammelt werden.
Beispiel 10. Das Verfahren von Beispiel 9, wobei: die 3D-Pipeline-Statistiken Datensätze umfassen, die einem oder mehreren der folgenden Elemente zugeordnet sind: Vertices, Grundformen, Pixel-Schattierer-Aufrufe, Mantel-Schattierer-Aufrufe und Domain-Schattierer-Aufrufe; die Hardware- oder Software-Zähler Daten umfassen, die einem oder mehreren der folgenden Faktoren zugeordnet sind: Einzelbild-Renderzeit, Fehler im frühen Tiefentest, Farbmischungen pro Pixel, Cache-Fehltreffer letzter bis mittlerer Ebene, Speicher-Lese- und Schreibvorgänge, Strangbelegungsmetriken für Ausführungseinheiten, Abtaster, Farb-Cache, Render-Cache-Zugriff und Schattierer-Programmänderungen.
Beispiel 11. Das Verfahren von Beispiel 6, das ferner umfasst: Verwenden der Korrelationen und mehrerer zusätzlicher Korrelationen durch das neuronale Netz, um einen Codierungstyp vorherzusagen, den der Codierer zum Codieren nachfolgender Einzelbilder verwenden soll.
Beispiel 12. Vorrichtung, die Folgendes umfasst: eine 3D-Graphikmaschine zum Rendern mehrerer Einzelbilder, die ein aktuelles Einzelbild und ein vorheriges Einzelbild umfassen; und einen Szenenänderungsdetektor zum Abrufen von Datensätzen aus der 3D-Graphikmaschine, wobei die Datensätze dem aktuellen Einzelbild zugeordnet sind, das von der 3D-Graphikmaschine gerendert wird, wobei der Szenenänderungsdetektor die Datensätze im Hinblick auf entsprechende Datensätze aus dem vorherigen Einzelbild analysiert, um einen ersten Codierungstyp zu bestimmen, der zum Codieren des aktuellen Einzelbilds vor der Übertragung über ein Netz verwendet werden soll.
Beispiel 13. Die Vorrichtung von Beispiel 12, wobei der Szenenänderungsdetektor ferner Folgendes umfasst: eine Fuzzy-Logik-Detektionsschaltung zum Durchführen von Fuzzy-Logik-Vergleichen an den Datensätzen, die dem aktuellen Einzelbild zugeordnet sind, und den entsprechenden Datensätzen aus dem vorherigen Einzelbild, um den ersten Codierungstyp zu schätzen.
Beispiel 14. Die Vorrichtung von Beispiel 12, wobei der erste Codierungstyp aus einer Gruppe ausgewählt ist, die aus Intra-Einzelbild-Codierung und prädiktiver Codierung besteht.
Beispiel 15. Die Vorrichtung von Beispiel 14, wobei die Intra-Einzelbild-Codierung eine I-Einzelbild-Codierung und die prädiktive Codierung eine P-Einzelbild-Codierung umfasst.
Beispiel 16. Die Vorrichtung von Beispiel 14, die ferner umfasst: einen Codierer zum Auswählen eines Codierungstyps aus entweder der Intra-Einzelbild-Codierung oder der prädiktiven Codierung und zum Codieren des aktuellen Einzelbilds unter Verwendung der gewählten Codierung aus Intra-Einzelbild-Codierung oder prädiktiver Codierung, wobei der Codierer den Szenenänderungsdetektor über den ausgewählten Codierungstyp benachrichtigen soll.
Beispiel 17. Die Vorrichtung von Beispiel 16, wobei der Szenenänderungsdetektor ferner umfasst: ein neuronales Netz zum Analysieren des ausgewählten Codierungstyps im Hinblick auf die Datensätze, die dem aktuellen Einzelbild zugeordnet sind, und die entsprechenden Datensätze aus dem vorherigen Einzelbild, wobei das neuronale Netz basierend auf der Analyse eine Korrelation zwischen dem gewählten Codierungstyp und den Differenzen zwischen den Datensätzen, die dem aktuellen Einzelbild zugeordnet sind, und den Datensätzen, die dem vorherigen Einzelbild zugeordnet sind, bestimmen soll.
Beispiel 18. Die Vorrichtung von Beispiel 17, das Entwickeln der Korrelation Folgendes umfasst: Anpassen eines Gewichts, das einer oder mehreren Verbindungen zwischen einer Menge von Neuronen der ersten Ebene und einem oder mehreren Neuronen der zweiten Ebene zugeordnet ist.
Beispiel 19. Die Vorrichtung von Beispiel 18, wobei jedes Neuron der ersten Ebene einem der Datensätze und entsprechenden Datensätze zugeordnet ist.
Beispiel 20. Die Vorrichtung von Beispiel 18, wobei die Datensätze und entsprechenden Datensätze eines oder mehrere der folgenden Elemente umfassen: 3D-Pipeline-Statistiken, die von der 3D-Render-Maschine, Hardware-Zählern oder Software-Zählern gesammelt werden.
Beispiel 21. Vorrichtung nach Anspruch 20, wobei: die 3D-Pipeline-Statistiken Datensätze umfassen, die einem oder mehreren der folgenden Elemente zugeordnet sind: Vertices, Grundformen, Pixel-Schattierer-Aufrufe, Mantel-Schattierer-Aufrufe und Domain-Schattierer-Aufrufe; die Hardware- oder Software-Zähler Daten umfassen, die einem oder mehreren der folgenden Faktoren zugeordnet sind: Einzelbild-Renderzeit, Fehler im frühen Tiefentest, Farbmischungen pro Pixel, Cache-Fehltreffer letzter bis mittlerer Ebene, Speicher-Lese- und Schreibvorgänge, Strangbelegungsmetriken für Ausführungseinheiten, Abtaster, Farb-Cache, Render-Cache-Zugriff und Schattierer-Programmänderungen.
Beispiel 22. Ein maschinenlesbares Medium, auf dem Programmcode gespeichert ist, der, wenn er von einer Maschine ausgeführt wird, die Maschine dazu veranlasst, die folgenden Operationen auszuführen: Abrufen von Datensätzen aus einer 3D-Graphikmaschine, wobei die Datensätze einem aktuellen Einzelbild zugeordnet sind, das von der 3D-Graphikmaschine gerendert wird; und Analysieren der Datensätze im Hinblick auf entsprechende Datensätze aus einem vorherigen Einzelbild, um einen ersten Codierungstyp zu bestimmen, der zum Codieren des aktuellen Einzelbilds vor der Übertragung über ein Netz verwendet werden soll.
Beispiel 23. Das maschinenlesbare Medium von Beispiel 22, wobei das Analysieren der Datensätze ein Durchführen einer Fuzzy-Logik-Detektion an den Datensätzen, die dem aktuellen Einzelbild zugeordnet sind, und den entsprechenden Datensätzen aus dem vorherigen Einzelbild umfasst, um den ersten Codierungstyp zu schätzen.
Beispiel 24. Das maschinenlesbare Medium von Beispiel 22, wobei der erste Codierungstyp aus einer Gruppe ausgewählt ist, die aus Intra-Einzelbild-Codierung und prädiktiver Codierung besteht.
Beispiel 25. Das maschinenlesbare Medium von Beispiel 24, wobei die Intra-Einzelbild-Codierung eine I-Einzelbild-Codierung und die prädiktive Codierung eine P-Einzelbild-Codierung umfasst.
Beispiel 26. Das maschinenlesbare Medium von Beispiel 24, das ferner Programmcode umfasst, um die Maschine dazu zu veranlassen, die folgenden Operationen durchzuführen: Auswählen eines Codierungstyps aus entweder Intra-Einzelbild-Codierung oder prädiktiver Codierung durch einen Codierer; Codieren des aktuellen Einzelbilds durch den Codierer unter Verwendung der gewählten Codierung aus Intra-Einzelbild-Codierung oder prädiktiver Codierung; und Benachrichtigen eines neuronalen Netzes über den ausgewählten Codierungstyp.
Beispiel 27. Das maschinenlesbare Medium von Beispiel 26, das ferner Programmcode umfasst, um die Maschine dazu zu veranlassen, die folgenden Operationen durchzuführen: Analysieren des ausgewählten Codierungstyps im Hinblick auf die Datensätze, die dem aktuellen Einzelbild zugeordnet sind, und die entsprechenden Datensätze aus dem vorherigen Einzelbild durch das neuronale Netz; und Bestimmen einer Korrelation zwischen dem ausgewählten Codierungstyp und Differenzen zwischen den Datensätzen, die dem aktuellen Einzelbild zugeordnet sind, und den Datensätzen, die dem vorherigen Einzelbild zugeordnet sind, basierend auf der Analyse.
Beispiel 28. Das maschinenlesbare Medium von Beispiel 27, wobei das Entwickeln der Korrelation Folgendes umfasst: Anpassen eines Gewichts, das einer oder mehreren Verbindungen zwischen einer Menge von Neuronen der ersten Ebene und einem oder mehreren Neuronen der zweiten Ebene zugeordnet ist.
Beispiel 29. Das maschinenlesbare Medium von Beispiel 28, wobei jedes Neuron der ersten Ebene einem der Datensätze und entsprechenden Datensätze zugeordnet ist.
Beispiel 30. Das maschinenlesbare Medium von Beispiel 29, wobei die Datensätze und entsprechenden Datensätze eines oder mehrere der folgenden Elemente umfassen: 3D-Pipeline-Statistiken, die von der 3D-Render-Maschine, Hardware-Zählern oder Software-Zählern gesammelt werden.
Beispiel 31. Das maschinenlesbare Medium von Beispiel 30, wobei: die 3D-Pipeline-Statistiken Datensätze umfassen, die einem oder mehreren der folgenden Elemente zugeordnet sind: Vertices, Grundformen, Pixel-Schattierer-Aufrufe, Mantel-Schattierer-Aufrufe und Domain-Schattierer-Aufrufe; die Hardware- oder Software-Zähler Daten umfassen, die einem oder mehreren der folgenden Faktoren zugeordnet sind: Einzelbild-Renderzeit, Fehler im frühen Tiefentest, Farbmischungen pro Pixel, Cache-Fehltreffer letzter bis mittlerer Ebene, Speicher-Lese- und Schreibvorgänge, Strangbelegungsmetriken für Ausführungseinheiten, Abtaster, Farb-Cache, Render-Cache-Zugriff und Schattierer-Programmänderungen.
Beispiel 32. Das maschinenlesbare Medium von Beispiel 21, das ferner Programmcode umfasst, um die Maschine dazu zu veranlassen, die folgenden Operationen durchzuführen: Verwenden der Korrelationen und mehrerer zusätzlicher Korrelationen durch das neuronale Netz, um einen Codierungstyp vorherzusagen, den der Codierer zum Codieren nachfolgender Einzelbilder verwenden soll.
Unabhängig davon, ob sich der Codierer auf das Ergebnis der Analyse des neuronalen Netzes stützt, verwendet das neuronale Netz bei 1810 das von dem Codierer erzeugte Ergebnis, um die den verschiedenen GPU-Parametern zugeordneten neuronalen Verbindungen zu stärken oder zu schwächen. Beispielsweise kann eine bestimmte Verbindung von einer ersten Schicht des neuronalen Netzes zur nächsten (oder letzten) Schicht verstärkt werden, wenn die Parameterwerte, die dem Neuron der ersten Schicht zugeordnet sind, hinreichend deutlich sind und/oder auf das Ergebnis hinweisen (z. B. wenn die Parameter angeben, dass ein I-Einzelbild vorzuziehen ist und der Codierer ein I-Einzelbild erzeugt hat). In ähnlicher Weise können die Verbindungen von Neuronen, die Parametern zugeordnet sind, die ein falsches Ergebnis angegeben hätten, geschwächt werden.
Obwohl bestimmte oben beschriebene Ausführungsformen sowohl ein neuronales Netz als auch einen Fuzzy-Logik-Detektor umfassen, können bestimmte Ausführungsformen der Erfindung nur mit einem Fuzzy-Logik-Detektor oder einem neuronalen Netz implementiert sein. Wenn beispielsweise eine Menge relevanter Parameter/Deltas zur Verwendung durch den Fuzzy-Logik-Detektor ausgewählt wird, kann er Szenenänderungen ohne das neuronale Netz mit einem hohen Maß an Genauigkeit identifizieren. Ebenso kann das neuronale Netz, solange es richtig trainiert ist, durch Schwächen/Verstärken der Verbindungen zwischen Neuronen in verschiedenen Ebenen des neuronalen Netzes „lernen“, eine Szenenänderung zu identifizieren.
Ausführungsformen der Erfindung verringern die Bandbreite, ohne die Codiererlatenz für ein gestreamtes 3D-Spiel oder eine andere Anwendung zu erhöhen, wenn das Spiel eine große Szenenänderung ausführt, die bei dem Codierer nicht vorhergesagt ist (und somit zu einer Erhöhung der Videostrom-Bitrate führen würde oder die visuelle Qualität verschlechtern würde). Ein Vorcodierer führt eine Szenenänderungsdetektion unter Verwendung von Daten durch, die während der 3D-Renderphase gesammelt wurden, ohne dass eine zusätzliche Latenz eingebracht wird.
Das Verfahren basiert kurz gesagt auf dem Sammeln von Hardware- oder Software-Zählern aus der GPU-Perspektive auf die 3D-Spiel-Renderphase und deren Weitergabe als Metadaten an den intelligenten Codierer, der sowohl von der darin vordefinierten Fuzzy-Logik als auch mit verzögerten Informationen aus dem Codierer darüber, ob die Szenendetektion erwartet wurde oder nicht, geschult ist.
Ausführungsformen der Erfindung können verschiedene Schritte umfassen, die oben beschrieben wurden. Die Schritte können in maschinenausführbaren Befehlen verkörpert sein, die verwendet werden können, um einen Universal- oder Spezialprozessor dazu zu veranlassen, die Schritte auszuführen. Alternativ können diese Schritte von bestimmten Hardwarekomponenten, die eine festverdrahtete Logik zum Ausführen der Schritte enthalten, oder von einer beliebigen Kombination aus programmierten Computerkomponenten und spezifischen Hardwarekomponenten ausgeführt werden.
Wie es hierin beschrieben ist, können sich Befehle auf bestimmte Konfigurationen von Hardware wie beispielsweise anwendungsspezifische integrierte Schaltungen (ASICs), die zum Ausführen bestimmter Operationen ausgelegt sind oder eine vorbestimmte Funktionalität aufweisen, oder Softwarebefehle, die in einem Speicher gespeichert sind, der in einem nichtflüchtigen computerlesbaren Medium enthalten ist, beziehen. Somit können die in den Figuren gezeigten Techniken unter Verwendung von Code und Daten implementiert werden, die auf einem oder mehreren elektronischen Vorrichtungen (z. B. einer Endstation, einem Netzelement usw.) gespeichert und ausgeführt werden. Solche elektronischen Vorrichtungen speichern und übermitteln (intern und/oder zu anderen elektronischen Vorrichtungen über ein Netz) Code und Daten unter Verwendung von computerlesbaren Medien wie etwa nichtflüchtigen computerlesbaren Speichermedien (z. B. Magnetplatten; optischen Platten; Direktzugriffsspeicher; Nur-Lese-Speicher; Flash-Speichervorrichtungen; Phasenwechselspeicher) und transitorischen maschinenlesbaren Computerkommunikationsmedien (z. B. elektrischen, optischen, akustischen Signalen oder andere Formen von sich ausbreitenden Signalen - wie etwa Trägerwellen, Infrarotsignale, digitale Signale, etc.).
Darüber hinaus umfassen solche elektronischen Vorrichtungen typischerweise einen Satz von einem oder mehreren Prozessoren, die mit einer oder mehreren anderen Komponenten wie z. B. einer oder mehreren Speichervorrichtungen (nicht flüchtigen maschinenlesbaren Speichermedien), AnwenderEingabe/Ausgabe-Vorrichtungen (z. B. einer Tastatur, einem Berührungsschirm und/oder einer Anzeige) und Netzverbindungen gekoppelt sind. Die Kopplung des Satzes von Prozessoren und anderer Komponenten erfolgt typischerweise über einen oder mehrere Busse und Brücken (auch als Bus-Controller bezeichnet). Die Speichervorrichtung und Signale, die den Netzverkehr führen, repräsentieren jeweils ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien. Somit speichert die Speichervorrichtung einer gegebenen elektronischen Vorrichtung typischerweise Code und/oder Daten zur Ausführung auf dem Satz von einem oder mehreren Prozessoren dieser elektronischen Vorrichtung. Selbstverständlich können ein oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung verschiedener Kombinationen von Software, Firmware und/oder Hardware implementiert werden. In dieser genauen Beschreibung wurden zum Zweck der Erläuterung zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der vorliegenden Erfindung zu ermöglichen. Es ist jedoch für Fachleute offensichtlich, dass die Erfindung ohne einige dieser spezifischen Einzelheiten praktiziert werden kann. In bestimmten Fällen wurden bekannte Strukturen und Funktionen nicht ausführlich beschrieben, um eine Verunklarung des Gegenstands der vorliegenden Erfindung zu vermeiden. Dementsprechend sollten der Umfang und der Gedanke der Erfindung anhand der folgenden Ansprüche beurteilt werden.

Claims

Beansprucht wird:
Verfahren, das Folgendes umfasst: Abrufen von Datensätzen aus einer 3D-Graphikmaschine, wobei die Datensätze einem aktuellen Einzelbild zugeordnet sind, das von der 3D-Graphikmaschine gerendert wird; und Analysieren der Datensätze im Hinblick auf entsprechende Datensätze aus einem vorherigen Einzelbild, um einen ersten Codierungstyp zu bestimmen, der zum Codieren des aktuellen Einzelbilds vor der Übertragung über ein Netz verwendet werden soll.
Verfahren nach Anspruch 1, wobei das Analysieren der Datensätze ein Durchführen einer Fuzzy-Logik-Detektion an den Datensätzen, die dem aktuellen Einzelbild zugeordnet sind, und den entsprechenden Datensätzen aus dem vorherigen Einzelbild umfasst, um den ersten Codierungstyp zu schätzen.
Verfahren nach Anspruch 1 oder 2, wobei der erste Codierungstyp aus einer Gruppe ausgewählt ist, die aus Intra-Einzelbild-Codierung und prädiktiver Codierung besteht.
Verfahren nach Anspruch 3, wobei die Intra-Einzelbild-Codierung eine I-Einzelbild-Codierung und die prädiktive Codierung eine P-Einzelbild-Codierung umfasst.
Verfahren nach Anspruch 3, das ferner umfasst: Auswählen eines Codierungstyps aus Intra-Einzelbild-Codierung oder prädiktiver Codierung durch einen Codierer; Codieren des aktuellen Einzelbilds durch den Codierer unter Verwendung der aus Intra-Einzelbild-Codierung oder prädiktiver Codierung gewählten Codierung; und Benachrichtigen eines neuronalen Netzes über den ausgewählten Codierungstyp.
Verfahren nach Anspruch 5, das ferner umfasst: Analysieren des ausgewählten Codierungstyps im Hinblick auf die Datensätze, die dem aktuellen Einzelbild zugeordnet sind, und die entsprechenden Datensätze aus dem vorherigen Einzelbild durch das neuronale Netz; und Bestimmen einer Korrelation zwischen dem ausgewählten Codierungstyp und Differenzen zwischen den Datensätzen, die dem aktuellen Einzelbild zugeordnet sind, und den Datensätzen, die dem vorherigen Einzelbild zugeordnet sind, basierend auf der Analyse.
Verfahren nach Anspruch 6, wobei das Entwickeln der Korrelation Folgendes umfasst: Anpassen eines Gewichts, das einer oder mehreren Verbindungen zwischen einer Menge von Neuronen erster Ebene und einem oder mehreren Neuronen zweiter Ebene zugeordnet ist.
Verfahren nach Anspruch 7, wobei jedes Neuron erster Ebene einem der Datensätze und entsprechenden Datensätze zugeordnet ist.
Verfahren nach Anspruch 8, wobei die Datensätze und entsprechenden Datensätze eines oder mehrere der folgenden Elemente umfassen: 3D-Pipeline-Statistiken, die von der 3D-Render-Maschine gesammelt werden, Hardware-Zähler oder Software-Zähler.
Verfahren nach Anspruch 9, wobei: die 3D-Pipeline-Statistiken Datensätze umfassen, die einem oder mehreren der folgenden Elemente zugeordnet sind: Vertices, Grundformen, Pixel-Schattierer-Aufrufe, Mantel-Schattierer-Aufrufe und Domain-Schattierer-Aufrufe; die Hardware- oder Software-Zähler Daten umfassen, die einem oder mehreren der folgenden Faktoren zugeordnet sind: Einzelbild-Renderzeit, Fehler im frühen Tiefentest, Farbmischungen pro Pixel, Cache-Fehltreffer letzter bis mittlerer Ebene, Speicher-Lese- und Schreibvorgänge, Strangbelegungsmetriken für Ausführungseinheiten, Abtaster, Farb-Cache, Render-Cache-Zugriff und Schattierer-Programmänderungen.
Verfahren nach Anspruch 6, das ferner umfasst: Verwenden der Korrelationen und mehrerer zusätzlicher Korrelationen durch das neuronale Netz, um einen Codierungstyp vorherzusagen, den der Codierer zum Codieren nachfolgender Einzelbilder verwenden soll.
Vorrichtung, die Folgendes umfasst: eine 3D-Graphikmaschine zum Rendern mehrerer Einzelbilder, die ein aktuelles Einzelbild und ein vorheriges Einzelbild umfassen; und einen Szenenänderungsdetektor zum Abrufen von Datensätzen aus der 3D-Graphikmaschine, wobei die Datensätze dem aktuellen Einzelbild zugeordnet sind, das von der 3D-Graphikmaschine gerendert wird, wobei der Szenenänderungsdetektor die Datensätze im Hinblick auf entsprechende Datensätze aus dem vorherigen Einzelbild analysiert, um einen ersten Codierungstyp zu bestimmen, der zum Codieren des aktuellen Einzelbilds vor der Übertragung über ein Netz verwendet werden soll.
Vorrichtung nach Anspruch 12, wobei der Szenenänderungsdetektor ferner Folgendes umfasst: eine Fuzzy-Logik-Detektionsschaltungsanordnung zum Durchführen von Fuzzy-Logik-Vergleichen an den Datensätzen, die dem aktuellen Einzelbild zugeordnet sind, und den entsprechenden Datensätzen aus dem vorherigen Einzelbild, um den ersten Codierungstyp zu schätzen.
Vorrichtung nach Anspruch 12 oder 13, wobei der erste Codierungstyp aus einer Gruppe ausgewählt ist, die aus Intra-Einzelbild-Codierung und prädiktiver Codierung besteht.
Vorrichtung nach Anspruch 14, wobei die Intra-Einzelbild-Codierung eine I-Einzelbild-Codierung und die prädiktive Codierung eine P-Einzelbild-Codierung umfasst.
Vorrichtung nach Anspruch 14, die ferner Folgendes umfasst: einen Codierer zum Auswählen eines Codierungstyps aus der Intra-Einzelbild-Codierung oder der prädiktiven Codierung und zum Codieren des aktuellen Einzelbilds unter Verwendung der aus Intra-Einzelbild-Codierung oder prädiktiver Codierung gewählten Codierung, wobei der Codierer den Szenenänderungsdetektor über den ausgewählten Codierungstyp benachrichtigen soll.
Vorrichtung nach Anspruch 16, wobei der Szenenänderungsdetektor ferner Folgendes umfasst: ein neuronales Netz zum Analysieren des ausgewählten Codierungstyps im Hinblick auf die Datensätze, die dem aktuellen Einzelbild zugeordnet sind, und die entsprechenden Datensätze aus dem vorherigen Einzelbild, wobei das neuronale Netz basierend auf der Analyse eine Korrelation zwischen dem gewählten Codierungstyp und den Differenzen zwischen den Datensätzen, die dem aktuellen Einzelbild zugeordnet sind, und den Datensätzen, die dem vorherigen Einzelbild zugeordnet sind, bestimmen soll.
Vorrichtung nach Anspruch 17, wobei das Entwickeln der Korrelation Folgendes umfasst: Anpassen eines Gewichts, das einer oder mehreren Verbindungen zwischen einer Menge von Neuronen erster Ebene und einem oder mehreren Neuronen zweiter Ebene zugeordnet ist.
Vorrichtung nach Anspruch 18, wobei jedes Neuron der ersten Ebene einem der Datensätze und entsprechenden Datensätze zugeordnet ist.
Vorrichtung nach Anspruch 18, wobei die Datensätze und entsprechenden Datensätze eines oder mehrere der folgenden Elemente umfassen: 3D-Pipeline-Statistiken, die von der 3D-Render-Maschine gesammelt werden, Hardware-Zähler oder Software-Zähler.
Vorrichtung nach Anspruch 20, wobei: die 3D-Pipeline-Statistiken Datensätze umfassen, die einem oder mehreren der folgenden Elemente zugeordnet sind: Vertices, Grundformen, Pixel-Schattierer-Aufrufe, Mantel-Schattierer-Aufrufe und Domain-Schattierer-Aufrufe; die Hardware- oder Software-Zähler Daten umfassen, die einem oder mehreren der folgenden Faktoren zugeordnet sind: Einzelbild-Renderzeit, Fehler im frühen Tiefentest, Farbmischungen pro Pixel, Cache-Fehltreffer letzter bis mittlerer Ebene, Speicher-Lese- und Schreibvorgänge, Strangbelegungsmetriken für Ausführungseinheiten, Abtaster, Farb-Cache, Render-Cache-Zugriff und Schattierer-Programmänderungen.
Maschinenlesbares Medium, auf dem Programmcode gespeichert ist, der, wenn er von einer Maschine ausgeführt wird, die Maschine dazu veranlasst, die folgenden Operationen auszuführen: Abrufen von Datensätzen aus einer 3D-Graphikmaschine, wobei die Datensätze einem aktuellen Einzelbild zugeordnet sind, das von der 3D-Graphikmaschine gerendert wird; und Analysieren der Datensätze im Hinblick auf entsprechende Datensätze aus einem vorherigen Einzelbild, um einen ersten Codierungstyp zu bestimmen, der zum Codieren des aktuellen Einzelbilds vor der Übertragung über ein Netz verwendet werden soll.
Maschinenlesbares Medium nach Anspruch 22, wobei das Analysieren der Datensätze ein Durchführen einer Fuzzy-Logik-Detektion an den Datensätzen, die dem aktuellen Einzelbild zugeordnet sind, und den entsprechenden Datensätzen aus dem vorherigen Einzelbild umfasst, um den ersten Codierungstyp zu schätzen.
Maschinenlesbares Medium nach Anspruch 22 oder 23, wobei der erste Codierungstyp aus einer Gruppe ausgewählt ist, die aus Intra-Einzelbild-Codierung und prädiktiver Codierung besteht.
Maschinenlesbares Medium nach Anspruch 24, wobei die Intra-Einzelbild-Codierung eine I-Einzelbild-Codierung und die prädiktive Codierung eine P-Einzelbild-Codierung umfasst.