DE112014002771T5

DE112014002771T5 - Hybrid-on-Demand-Grafikübersetzungstabellen-Shadowing

Info

Publication number: DE112014002771T5
Application number: DE112014002771.5T
Authority: DE
Inventors: Yao Zu Dong; Xiao Zheng; Kun Tian
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2014-12-24
Filing date: 2014-12-24
Publication date: 2016-10-13
Also published as: CN105518746A; TW201636854A; GB2535823B; GB201518811D0; GB2535823A; WO2016101172A1; US20160292816A1; US9619860B2; CN105518746B; KR20160089863A; TWI570564B; KR101751629B1

Abstract

In mehreren Ausführungsformen wird ein Grafikprozessor mit einem Monitor für virtuelle Maschinen (VMM) gekoppelt, um einer oder mehreren virtuellen Maschinen einen virtuellen Grafikprozessor zu präsentieren. Ein Mediator für den virtuellen Grafikprozessor kopiert synchron Modifikationen einer Guest-Grafikübersetzungstabelle (GTT) einer virtuellen Maschine in eine Shadow-GTT der VMM unter Verwendung von Abfang- und Emulier-Virtualisierung. Wenn der Mediator eine Häufigkeit von Modifikationen in der Guest-GTT detektiert, die eine Schwelle überschreitet, dann kann der Mediator asynchron zumindest einen Teil der Guest-GTT in die Shadow-GTT kopieren und die Shadow-GTT wieder aufbauen, bevor Befehle für den virtuellen Grafikprozessor zum Grafikprozessor zugestellt werden.

Description

TECHNISCHES GEBIET
Ausführungsformen betreffen im Allgemeinen Grafikvirtualisierungsumgebungen. Insbesondere betreffen Ausführungsformen die Verwaltung von Grafikübersetzungstabellen.
HINTERGRUND
Grafikvirtualisierung kann es einer Software, die in einer virtuellen Maschine (VM) läuft, erlauben, verschiedene Ereignisse zu steuern und Zugriff auf Grafikhardwareressourcen auf einer physischen Maschine zu haben, wobei ein Monitor für virtuelle Maschinen (Virtual Machine Monitor, VMM) die VMs auf der physischen Maschine erzeugen und laufen lassen kann. Demgemäß kann die VM-Software insgesamt als Guest-Software bezeichnet werden, und der VMM kann als Host bezeichnet werden. Partitionieren der Grafikhardwareressourcen zwischen mehreren VMs kann bestimmte Herausforderungen in Bezug auf Effizienz und Sicherheit mit sich bringen. Beispielsweise kann es in herkömmlichen Grafikvirtualisierungslösungen vorkommen, dass die Host- und die Guest-Software nicht die gleiche Darstellung (z. B. Größe und Layout) des Grafikspeicheradressraums haben, und außerdem kann es vorkommen, dass der Guest-Grafikspeicheradressraum in bestimmten Fällen nicht identisch mit dem Systemspeicheradressraum ist. Da Guest-Befehle (z. B. Bildsynthesebefehle) von der Guest-Software an die Grafikhardware ausgegeben werden, kann daher Adressenneuzuordnung und/oder -reparatur (z. B. Finden der Guest-Adresse im Befehl und Ersetzen durch eine Host-Adresse) von der Guest-Darstellung zur Host-Darstellung durchgeführt werden. Hardware-Adressenneuzuordnung und/oder -reparatur kann Markierungstechnologie umfassen, die Komplexität hinzufügt. Außerdem kann softwarebasierte Adressenneuzuordnung und/oder -reparatur VMM-Abfangen, Syntaxanalyse und/oder Umwandlung jedes Guest-Befehls umfassen, was zusätzliche Verwaltungsdaten verursachen kann.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Für Fachleute auf dem Gebiet der Erfindung ergeben sich die verschiedenen Vorteile der Ausführungsformen anhand der Lektüre der folgenden Patentschrift und beiliegenden Ansprüche und unter Bezugnahme auf die folgenden Zeichnungen, worin:
1 ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor mit einem oder mehreren Prozessorkernen und Grafikprozessoren ist;
2 ein Blockdiagramm einer Ausführungsform eines Prozessors mit einem oder mehreren Prozessorkernen, einer integrierten Speichersteuerung und einem integrierten Grafikprozessor ist;
3 ein Blockdiagramm einer Ausführungsform eines Grafikprozessors ist, der eine separate Grafikverarbeitungseinheit oder ein mit einer Vielzahl von Verarbeitungskernen integrierter Grafikprozessor sein kann;
4 ein Blockdiagramm einer Ausführungsform einer Grafikverarbeitungsmaschine für einen Grafikprozessor ist;
5 ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors ist;
6 ein Blockdiagramm einer Verarbeitungsstrang-Ausführungslogik ist, die eine Anordnung von Verarbeitungselementen umfasst;
7 ein Grafikprozessor-Ausführungseinheit-Anweisungsformat gemäß einer Ausführungsform zeigt;
8 ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessor ist, die eine Grafikpipeline, eine Medienpipeline, eine Anzeigemaschine, eine Verarbeitungsstrang-Ausführungslogik und eine Bildsyntheseausgabepipeline umfasst;
9A ein Blockdiagramm ist, das ein Grafikprozessor-Befehlsformat gemäß einer Ausführungsform zeigt;
9B ein Blockdiagramm ist, das eine Grafikprozessor-Befehlssequenz gemäß einer Ausführungsform zeigt;
10 eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einer Ausführungsform zeigt;
11 einen Überblick über ein beispielhaftes GPU-Programmiermodell, das Grafikübersetzungstabellen umfasst, gemäß einer Ausführungsform bereitstellt;
12 ein Blockdiagramm von beispielhaften globalen und prozessbezogenen Grafikübersetzungstabellen gemäß einer Ausführungsform ist;
13 ein Blockdiagramm von beispielhaften Grafikvirtualisierungsumgebungen gemäß einer Ausführungsform ist;
14 ein Flussdiagramm einer Logik zum Eintreten in einen asynchronen Modus für eine Guest-Grafikübersetzungstabelle ist;
15A–B Blockdiagramme von Shadow-Grafikübersetzungstabellen-Rekonstruktion gemäß einer Ausführungsform zeigt;
16 ein Flussdiagramm einer Logik zur Rekonstruktion zumindest eines Teils von Shadow-Grafikübersetzungstabellen ist;
17A–B Flussdiagramme sind, die eine Logik zum Austritt aus einem asynchronen Modus für eine Guest-Grafikübersetzungstabelle umfassen;
18 ein Blockdiagramm zur Veranschaulichung von Hybridsynchronisierung gemäß einer Ausführungsform ist; und
19 ein Flussdiagramm einer Logik zur Ausführung von Hybridsynchronisierung gemäß einer Ausführungsform ist.
BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
Systemüberblick
1 ist ein Blockdiagramm eines Datenverarbeitungssystems 100 gemäß einer Ausführungsform. Ein Datenverarbeitungssystem 100 umfasst einen oder mehrere Prozessoren 102 und einen oder mehrere Grafikprozessoren 108 und kann ein Desktopsystem mit einem einzelnen Prozessor, ein Workstationsystem mit mehreren Prozessoren oder ein Serversystem mit einer großen Anzahl an Prozessoren 102 oder Prozessorkernen 107 sein. In einer Ausführungsform ist das Datenverarbeitungssystem 100 eine integrierte Ein-Chip-System-(SoC-)Schaltung zur Verwendung in mobilen, tragbaren oder eingebetteten Vorrichtung.
Eine Ausführungsform eines Datenverarbeitungssystems 100 kann eine serverbasierte Spielplattform, eine Spielkonsole, einschließlich einer Spiel- und Medienkonsole, oder eine Onlinespielkonsole umfassen oder darin inkorporiert sein. In manchen Ausführungsformen ist das Datenverarbeitungssystem 100 ein Mobiltelefon, ein Smartphone, eine Tabletrechnervorrichtung oder eine mobile Internetvorrichtung. Das Datenverarbeitungssystem 100 kann auch eine tragbare Vorrichtung, wie z. B. eine tragbare Smart-Armbanduhrvorrichtung, eine Smart-Brillenvorrichtung, eine Vorrichtung für erweiterte Realität oder eine Vorrichtung für virtuelle Realität umfassen, damit gekoppelt oder darin integriert sein. In manchen Ausführungsformen ist das Datenverarbeitungssystem 100 ein Fernseh- oder Beistellgerät mit einem oder mehreren Prozessoren 102 und einer Grafikschnittstelle, die von einem oder mehreren Grafikprozessoren 108 erzeugt wird. In einer Ausführungsform ist das Datenverarbeitungssystem 100 ein Drahtlosrouter oder Zugangspunkt zur Verwendung als Heimnetzwert-Gateway, Heimmedienserver oder eine Kombination aus Zugangspunkt/digitaler Beschilderungslösung für öffentliche Bereiche (z. B. Krankenhäuser).
In manchen Ausführungsformen umfassen der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107, um Anweisungen zu verarbeiten, die bei Ausführung Operationen in System- und Benutzersoftware durchführen. In manchen Ausführungsformen ist jeder der einen oder mehreren Prozessorkerne 107 konfiguriert, um einen bestimmen Anweisungssatz 109 zu verarbeiten. In manchen Ausführungsformen kann der Anweisungssatz 109 Rechnen mit komplexem Anweisungssatz (CISC), Rechnen mit reduziertem Anweisungssatz (RISC) oder Rechnen über sehr lange Anweisungswörter (VLIW) sein. Verschiedene Prozessorkerne 107 können jeweils einen anderen Anweisungssatz 109 verarbeiten, die Anweisungen zur Vereinfachung der Emulation anderer Anweisungssätze umfassen können. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen, wie z. B. einen digitalen Signalprozessor (DSP), umfassen.
In manchen Ausführungsformen umfasst der Prozessor 102 einen Cachespeicher 104. Je nach Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Ebenen von internen Caches aufweisen. In manchen Ausführungsformen teilen sich verschiedene Komponenten des Prozessors 102 einen Cachespeicher. In manchen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z. B. einen Cache der Ebene 3 (L3) oder einen Cache der letzten Ebene (LLC)) (nicht dargestellt), die sich mehreren Prozessorkerne 107 unter Anwendung von bekannten Cachekohärenztechniken teilen können. Eine Registerdatei 106 ist ebenfalls im Prozessor 102 enthalten, die verschiedene Arten von Registern zum Speichern verschiedener Arten von Daten umfassen kann (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und Anweisungszeigerregister). Manche Register können Allzweckregister sein, während andere Register für den Aufbau des Prozessors 102 spezifisch sind.
In manchen Ausführungsformen ist der Prozessor 102 mit einem Prozessorbus 110 gekoppelt, um Datensignale zwischen dem Prozessor 102 und andere Komponenten im System 100 zu übertragen. Das System 100 verwendet beispielsweise eine ,Knotenpunkt'-Systemarchitektur, die einen Speichersteuerungsknotenpunkt 116 und einen Eingang-Ausgang-(E/A-)Steuerungsknotenpunkt 130 umfasst. Der Speichersteuerungsknotenpunkt 116 erleichtert Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten von System 100, während der E/A-Steuerungsknotenpunkt (ICH) 130 Verbindungen mit E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
Speichervorrichtung 120 kann eine dynamische Direktzugriffsspeicher-(DRAM-)Vorrichtung, eine statische Direktzugriffsspeicher-(SRAM-)Vorrichtung, eine Flashspeichervorrichtung oder eine andere Speichervorrichtung mit geeigneter Leistung sein, um als Prozessspeicher zu dienen. Der Speicher 120 kann Daten 122 und Anweisungen 121 zur Verwendung speichern, wenn der Prozessor 102 einen Prozess ausführt. Der Speichersteuerungsknotenpunkt 116 ist auch mit einem optionalen externen Grafikprozessor 112 gekoppelt, der mit dem einen oder den mehreren Grafikprozessoren 108 in Prozessor 102 kommunizieren kann, um Grafik- und Medienoperationen auszuführen.
In manchen Ausführungsformen ermöglicht es ICH 130 Peripheriegeräten, sich über einen Hochgeschwindigkeits-E/A-Bus mit dem Speicher 120 und dem Prozessor 102 zu verbinden. Die E/A-Peripheriegeräte umfassen eine Audiosteuerung 146, eine Firmware-Schnittstelle 128, einen Drahtlos-Sendeempfänger 126 (z. B. Wi-Fi, Bluetooth), eine Datenspeichervorrichtung 124 (z. B. Festplatte, Flashspeicher usw.) und eine Altsystem-E/A-Steuerung zur Kopplung von Altsystemvorrichtungen (z. B. Personal System 2 (PS/2)) mit dem System. Eine oder mehrere serielle Bus-(USB-)Steuerungen 142 verbinden Eingabevorrichtungen, wie z. B. Kombinationen aus Tastatur und Maus 144. Eine Netzwerksteuerung 134 kann ebenfalls mit ICH 130 gekoppelt werden. In manchen Ausführungsformen ist eine Hochleistungs-Netzwerksteuerung (nicht dargestellt) mit dem Prozessorbus 110 gekoppelt.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A-N, einer integrierten Speichersteuerung 214 und einem integrierten Grafikprozessor 208. Elemente aus 2 mit derselben Bezugszahl (oder Bezeichnung) wie Elemente einer beliebigen anderen Figur hierin können auf ähnliche Weise arbeiten oder funktionieren wie an anderer Stelle hierin beschrieben, sind jedoch nicht darauf eingeschränkt. Der Prozessor 200 kann weitere Kerne umfassen, bis zu und einschließlich einen weiteren Kern 202N, wie durch gestrichelte Rahmen dargestellt ist. Jeder der Kerne 202A-N umfasst eine oder mehrere interne Cacheeinheiten 204A-N. In manchen Ausführungsformen weist jeder Kern auch Zugang zu einer oder mehreren gemeinsamen Cacheeinheiten 206 auf.
Die internen Cacheeinheiten 204A-N und gemeinsamen Cacheeinheiten 206 stellen eine Cachespeicherhierarchie innerhalb des Prozessors 200 dar. Die Cachespeicherhierarchie kann zumindest eine Anweisungs- und Datencacheebene innerhalb jedes Kerns und eine oder mehrere Ebenen von gemeinsamen Mittelebenenencaches umfassen, wie z. B. der Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder anderen Ebenen, wobei die höchste Cacheebene vor dem externen Speicher als LLC klassifiziert ist. In manchen Ausführungsformen erhält die Cachekohärenzlogik Kohärenz zwischen den verschiedenen Cacheeinheiten 206 und 204A-N.
In manchen Ausführungsformen kann der Prozessor 200 auch einen Satz von einem oder mehreren Bussteuereinheiten 216 und einen System-Agent 210 umfassen. Die eine oder mehreren Bussteuereinheiten verwalten einen Satz von Peripheriebussen, wie z. B. einen oder mehrere Peripheriekomponenten-Verbindungsbusse (z. B. PCI, PCI Express). Der System-Agent 210 stellt Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. In manchen Ausführungsformen umfasst der System-Agent 210 eine oder mehrere integrierte Speichersteuerungen 214 zur Verwaltung des Zugriffs auf verschiedene externe Speichervorrichtungen (nicht dargestellt).
In manchen Ausführungsformen unterstützen der eine oder die mehreren der Kerne 202A-N mehrere simultane Verarbeitungsstränge. In solch einer Ausführungsform umfasst der System-Agent 210 Komponenten zur Koordination und Operation der Kerne 202A-N während der mehrsträngigen Verarbeitung. Der System-Agent 210 kann zusätzlich eine Leistungssteuerungseinheit (PCU) umfassen, die Logik und Komponenten zur Regulierung des Leistungszustands der Kerne 202A-N und des Grafikprozessors 208 umfasst.
In manchen Ausführungsformen umfasst der Prozessor 200 zusätzlich den Grafikprozessor 208 zur Ausführung von Grafikverarbeitungsoperationen. In manchen Ausführungsformen ist der Grafikprozessor 208 mit dem Satz von gemeinsamen Cacheeinheiten 206 und der System-Agent-Einheit 210, einschließlich der einen oder mehreren integrierten Speichersteuerungen 214, gekoppelt. In manchen Ausführungsformen ist eine Anzeigensteuerung 211 mit dem Grafikprozessor 208 gekoppelt, um die Grafikprozessorausgabe zu einer oder mehreren gekoppelten Anzeigen anzusteuern. In manchen Ausführungsformen kann die Anzeigensteuerung 211 ein separates Modul sein, das mit dem Grafikprozessor über zumindest eine Verbindung gekoppelt ist, oder sie kann im Grafikprozessor 208 oder System-Agent 210 integriert sein.
In manchen Ausführungsformen wird eine ringbasierte Verbindungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann aber auch eine alternative Verbindungseinheit verwendet werden, wie z. B. eine Punkt-zu-Punkt-Verbindung, eine Schaltverbindung oder andere Techniken, einschließlich auf dem Gebiet der Erfindung wohlbekannter Techniken. In manchen Ausführungsformen ist der Grafikprozessor 208 mit der Ringverbindung 212 über eine E/A-Verknüpfung 213 gekoppelt.
Die beispielhafte E/A-Verknüpfung 213 stellt zumindest eine von mehreren Variationen von E/A-Verbindungen dar, einschließlich einer E/A-Verbindung am Gehäuse, die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungs-Speichermodul 218, wie z. B. einem eDRAM-Modul, erleichtert. In manchen Ausführungsformen verwenden jeder der Kerne 202-N und der Grafikprozessor 208 eingebettete Speichermodule 218 als gemeinsamen Cache der letzten Ebene.
In manchen Ausführungsformen sind die Kerne 202A-N homogene Kerne, welche die gleiche Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Kerne 202A-N heterogen in Bezug auf die Anweisungssatzarchitektur (ISA), wobei einer oder mehrere der Kerne 202A-N einen ersten Anweisungssatz ausführen, während zumindest einer der anderen Kerne einen Untersatz des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführt.
In manchen Ausführungsformen ist der Prozessor 200 Teil eines oder mehrerer Substrate oder unter Verwendung beliebiger von einer Reihe von Prozesstechnologien darauf implementiert, beispielsweise als sich ergänzender Metalloxidhalbleiter (CMOS), sich ergänzender Metalloxidhalbleiter mit Bipolarverbindung (BiCMOS) oder Metalloxidhalbleiterlogik vom N-Typ (NMOS). Außerdem kann der Prozessor 200 auf einem oder mehreren Chips oder als integrierte SoC-Schaltung mit den veranschaulichten Komponenten zusätzlich zu anderen Komponenten implementiert sein.
3 ist ein Blockdiagramm eines Grafikprozessors 300, der eine separate Grafikverarbeitungseinheit oder ein mit einer Vielzahl von Verarbeitungskernen integrierter Grafikprozessor sein kann. In manchen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die im Prozessorspeicher platziert werden. In manchen Ausführungsformen umfasst der Grafikprozessor 300 eine Speicherschnittstelle 314, um auf den Speicher zuzugreifen. Die Speicherschnittstelle 314 kann eine Schnittstelle mit einem lokalen Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsamen externen Caches und/oder einem Systemspeicher sein.
In manchen Ausführungsformen umfasst der Grafikprozessor 300 auch eine Anzeigensteuerung 302, um Anzeigeausgabedaten zu einer Anzeigevorrichtung 320 zu steuern. Die Anzeigensteuerung 302 umfasst Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und für die Komposition von mehreren Ebenen von Video- oder Benutzerschnittstellenelementen. In manchen Ausführungsformen umfasst der Grafikprozessor 300 eine Video-Codec-Maschine 306 zum Kodieren, Dekodieren oder Transkodieren von Medien in, aus oder zwischen ein(em) oder mehrere(n) Medienkodierformat(en), einschließlich, nicht jedoch eingeschränkt auf Formate der Moving Picture Experts Group (MPEG), wie z. B. MPEG-2, Formate zum Advanced Video Coding (AVC), wie z. B. H.264/MPEG-4 AVC, sowie Formate der Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und Formate der Joint Photographic Experts Group (JPEG), wie z. B. die Formate JPEG und Motion JPEG (MJPEG).
In manchen Ausführungsformen umfasst der Grafikprozessor 300 eine Blockbildtransfer-(BLIT-)Maschine 304 zur Ausführung von zweidimensionalen (2D) Rasterungsoperationen, einschließlich beispielsweise Bitgrenzenblocktransfers.
In einer Ausführungsform werden 2D-Grafikoperationen jedoch unter Verwendung eines oder mehrerer Komponenten der Grafikverarbeitungsmaschine (GPE) 310 ausgeführt. In manchen Ausführungsformen ist die Grafikverarbeitungsmaschine 310 eine Rechenmaschine zur Ausführung von Grafikoperationen, einschließlich dreidimensionalen (3D) Grafikoperationen und Medienoperationen.
In manchen Ausführungsformen umfasst die GPE 310 eine 3D-Pipeline 312 zur Ausführung von 3D-Operationen, wie z. B. dreidimensionale Bildsynthesebilder und -szenen unter Verwendung von Verarbeitungsfunktionen, die auf Formen von 3D-Primitiven wirken (z. B. Rechteck, Dreieck usw.). Die 3D-Pipeline 312 umfasst programmierbare und fixe Funktionselemente, die verschiedene Aufgaben innerhalb des Elements ausführen und/oder Verarbeitungsstränge in einem 3D/Medien-Subsystem 315 initialisieren. Die 3D-Pipeline 312 kann zwar zur Ausführung von Medienoperationen verwendet werden, eine Ausführungsform der GPE 310 umfasst aber auch eine Medienpipeline 316, die spezifisch zur Ausführung von Medienoperationen, wie z. B. Videonachbearbeitung und Bildverbesserung, verwendet wird.
In manchen Ausführungsformen umfasst die Medienpipeline 316 Einheiten mit fixen Funktionen oder programmierbarer Logik zur Ausführung einer oder mehrerer spezialisierter Medienoperationen, wie z. B. Videodekodierbeschleunigung, Videozeilenentflechtung und Videokodierbeschleunigung anstelle der oder für die Video-Codec-Maschine 306. In manchen Ausführungsformen umfasst die Medienpipeline 316 außerdem eine Verarbeitungsstranginitialisierungseinheit zum Initialisieren von Verarbeitungssträngen zur Ausführung am 3D/Medien-Subsystem 315. Die initialisierten Verarbeitungsstränge führen Berechnungen für Medienoperationen an einer oder mehreren der Grafikausführungseinheiten aus, die im 3D/Medien-Subsystem 315 enthalten sind.
In manchen Ausführungsformen umfasst das 3D/Medien-Subsystem 315 Logik zur Ausführung von Verarbeitungssträngen, die von der 3D-Pipeline 312 und der Medienpipeline 316 initialisiert wurden. In einer Ausführungsform senden die Pipelines Verarbeitungsstrangausführungsanfragen an das 3D/Medien-Subsystem 315, das eine Verarbeitungsstrang-Weiterleitungslogik zum Zuordnen und Weiterleiten der verschiedenen Anfragen an verfügbare Verarbeitungsstrangausführungsressourcen umfasst. Die Ausführungsressourcen umfassen eine Anordnung von Grafikausführungseinheiten zur Verarbeitung der 3D- und Medien-Verarbeitungsstränge. In manchen Ausführungsformen umfasst das 3D/Medien-Subsystem 315 eine oder mehrere interne Caches für Verarbeitungsstranganweisungen und -daten. In manchen Ausführungsformen umfasst das Subsystem auch gemeinsame Speicher, einschließlich Register und adressierbarer Speicher, um Daten zwischen Verarbeitungssträngen zu teilen und Ausgabedaten zu speichern.
3D/Medien-Verarbeitung
4 ist ein Blockdiagramm einer Grafikverarbeitungsmaschine 410 eines Grafikprozessors gemäß einigen Ausführungsformen. In einer Ausführungsform ist die GPE 410 eine Version der GPE 310, die in 3 dargestellt ist. Elemente aus 4 mit den gleichen Bezugszahlen (oder Bezeichnungen) wie Elemente einer beliebigen anderen Figur hierin können auf ähnliche Weise arbeiten oder funktionieren, wie an anderer Stelle hierin beschrieben ist, sind aber nicht darauf eingeschränkt.
In manchen Ausführungsformen ist die GPE 410 mit einem Befehlsstreamer 403 gekoppelt, der einen Befehlsstrom für die GPE-3D- und Medienpipelines 412, 416 bereitstellt. In manchen Ausführungsformen ist der Befehlsstreamer 403 mit einem Speicher gekoppelt, der ein Systemspeicher oder ein oder mehrere interne Cachespeicher und gemeinsame Cachespeicher sein kann. In manchen Ausführungsformen empfängt der Befehlsstreamer 403 Befehle vom Speicher und sendet die Befehle an die 3D-Pipeline 412 und/oder Medienpipeline 416. Die 3D- und Medienpipelines verarbeiten die Befehle, indem sie Operationen über eine Logik innerhalb der entsprechenden Pipelines ausführen oder eine oder mehrere Verarbeitungsstränge zu einer Ausführungseinheitsanordnung 414 abgeben. In manchen Ausführungsformen ist die Ausführungseinheitsanordnung 414 skalierbar, sodass die Anordnung basierend auf dem gewünschten Energie- und Leistungsgrad der GPE 410 eine variable Anzahl von Ausführungseinheiten umfasst.
In manchen Ausführungsformen ist eine Abtastmaschine 430, die mit dem Speicher (z. B. Cachespeicher oder Systemspeicher) und der Ausführungseinheitsanordnung 414 gekoppelt ist. In manchen Ausführungsformen stellt die Abtastmaschine 430 einen Speicherzugriffsmechanismus für die Ausführungseinheitsanordnung 414 bereit, die es der Ausführungsanordnung 414 erlaubt, Grafik- und Mediendaten aus dem Speicher auszulesen. In manchen Ausführungsformen umfasst die Abtastmaschine 430 eine Logik zur Ausführung spezialisierter Abtastoperationen für Medien.
In manchen Ausführungsformen umfasst die spezialisierte Medienabtastlogik in der Abtastmaschine 430 ein Entrausch-/Entflechtmodul 432, ein Bewegungsschätzmodul 434 und ein Bildskalier- und -filtermodul 436. In manchen Ausführungsformen umfasst das Entrausch-/Entflechtmodul 432 eine Logik zur Ausführung eines oder mehrerer Entrausch- oder Entflechtalgorithmen an dekodierten Videodaten. Die Entflechtlogik kombiniert alternierende Felder von verflochtenen Videoinhalten zu einem einzelnen Videobild. Die Entrauschlogik reduziert oder entfernt Datenrauschen aus Video- und Bilddaten. In manchen Ausführungsformen sind die Entrauschlogik und die Entflechtlogik bewegungsadaptiv und verwenden räumliche oder zeitliche Filterung basierend auf dem Bewegungsausmaß, das in den Videodaten detektiert wird. In manchen Ausführungsformen umfasst das Entrausch-/Entflechtmodul 432 zugeordnete Bewegungsdetektionslogik (z. B. innerhalb der Bewegungsschätzungsmaschine 434).
In manchen Ausführungsformen stellt die Bewegungsschätzungsmaschine 434 Hardware-Beschleunigung für Videooperationen bereit, indem Videobeschleunigungsfunktionen, wie z. B. Bewegungsvektorschätzung und Vorhersage von Videodaten, durchgeführt werden. Die Bewegungsschätzungsmaschine bestimmt Bewegungsvektoren, welche die Transformation von Bilddaten zwischen aufeinanderfolgenden Einzelbildern eines Videos beschreiben. In manchen Ausführungsformen verwendet ein Grafikprozessormediencodec die Videobewegungsschätzungsmaschine 434 zur Ausführung von Operationen an einem Video auf der Makroblockebene, die ansonsten zu rechenintensiv waren, um von einem Allzweckprozessor ausgeführt zu werden. In manchen Ausführungsformen steht die Bewegungsschätzungsmaschine 434 im Allgemeinen Grafikprozessorkomponenten zu Verfügung, um Videodekodier- und -verarbeitungsfunktionen zu unterstützen, die zu sensibel oder adaptiv für die Richtung oder Größe der Bewegung innerhalb von Videodaten sind.
In manchen Ausführungsformen führt das Skalier- und Filtermodul 436 Bildverarbeitungsoperationen aus, um die visuelle Qualität von erzeugten Bildern und Videos zu verbessern. In manchen Ausführungsformen verarbeitet das Skalier- und Filtermodul 436 Bild- und Videodaten während der Abtastoperation, bevor die Daten zur Ausührungseinheitsanordnung 414 bereitgestellt werden.
In manchen Ausführungsformen umfasst die GPE 410 einen Datenanschluss 444, der einen weiteren Speicherzugriffsmechanismus für Grafiksubsysteme darstellt. In manchen Ausführungsformen vereinfacht der Datenanschluss 444 Speicherzugriff für Operationen, die Bildsynthesezieleintragungen, konstante Cacheauslesungen, Scratch-Speicherplatzauslesungen/-eintragungen und Medienoberflächenzugriffe umfassen. In manchen Ausführungsformen umfasst der Datenanschluss 444 Cachespeicherplatz zum Puffen von Zugriffen auf einen Speicher. Der Cachespeicher kann ein einzelner Datencache sein oder in mehrere Caches für die mehreren Subsysteme unterteilt sein, die auf den Speicher mittels des Datenanschlusses zugreifen (z. B. ein Bildsynthesepuffercache, ein konstanter Puffercache usw.). In manchen Ausführungsformen kommunizieren Verarbeitungsstränge, die auf einer Ausführungseinheit in der Ausführungseinheitsanordnung 414 ausgeführt werden, mit dem Datenanschluss durch Austausch von Nachrichten über eine Datenweiterleitungsverbindung, welche die einzelnen Subsysteme der GPE 410 verbindet.
Ausführungseinheiten
5 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors 500. Elemente in 5 mit derselben Bezugszahl (oder Bezeichnung) wie Elemente einer beliebigen anderen Figur hierin können auf ähnliche Weise arbeiten oder funktionieren wie an anderer Stelle hierin beschrieben, sind jedoch nicht darauf eingeschränkt.
In manchen Ausführungsformen umfasst der Grafikprozessor 500 eine Ringverbindung 502, ein Pipeline-Frontend 504, eine Medienmaschine 537 und Grafikkerne 580A-N. In manchen Ausführungsformen koppelt die Ringverbindung 502 den Grafikprozessor an andere Verarbeitungseinheiten, einschließlich anderer Grafikprozessoren oder einen oder mehrere Allzweckprozessorkerne. In manchen Ausführungsformen ist der Grafikprozessor einer von vielen Prozessoren, die in einem Mehrkernverarbeitungssystem integriert sind.
In manchen Ausführungsformen empfängt der Grafikprozessor 500 Befehlsstapel über die Ringverbindung 502. Die ankommenden Befehle werden von einem Befehlsstreamer 503 im Pipeline-Frontend 504 interpretiert. In manchen Ausführungsformen umfasst der Grafikprozessor 500 eine skalierbare Ausführungslogik zur Ausführung von 3D-Geometrieverarbeitung und Medienverarbeitung über den/die Grafikkerne) 580A-N. Für 3D-Geometrieverarbeitungsbefehle stellt der Befehlsstreamer 503 Befehle für die Geometriepipeline 536 bereit. Zumindest für manche Medienverarbeitungsbefehle stellt der Befehlsstreamer 503 die Befehle zu einem Video-Frontend 534 bereit, das mit einer Medienmaschine 537 gekoppelt ist. In manchen Ausführungsformen umfasst die Medienmaschine 537 eine Videoqualitätsmaschine (VQE) 530 für Video- und Bildnachbearbeitung und eine Multiformatkodier-/-dekodier-(MFX-) 533 Maschine zur Bereitstellung von hardwarebeschleunigter Mediendatenkodierung und -dekodierung. In manchen Ausführungsformen können die Geometriepipeline 536 und Medienmaschine 537 jeweils Verarbeitungsstränge für die Verarbeitungsstrang-Ausführungsressourcen erzeugen, die von zumindest einem Grafikkern 580A bereitgestellt werden.
In manchen Ausführungsformen umfasst der Grafikprozessor 500 skalierbare Verarbeitungsstrang-Ausführungsressourcen mit modularen Kernen 580A-N (manchmal als Kern-Slices bezeichnet), die jeweils mehrere Subkerne 550A-N, 560A-N (manchmal als Kern-Subslices bezeichnet) aufweisen. In manchen Ausführungsformen kann der Grafikprozessor 500 eine Reihe von Grafikkernen 580A bis 580N aufweisen. In manchen Ausführungsformen umfasst der Grafikprozessor 500 einen Grafikkern 580A mit zumindest einem ersten Subkern 550A und einem zweiten Subkern 560A. In anderen Ausführungsformen ist der Grafikprozessor ein Niedrigleistungsprozessor mit einem einzelnen Subkern (z. B. 550A). In manchen Ausführungsformen umfasst der Grafikprozessor 500 mehrere Grafikkerne 580A-N, die jeweils einen Satz von ersten Subkernen 550A-N und einen Satz von zweiten Subkernen 560A-N umfassen. Jeder Subkern im Satz von ersten Subkernen 550A-N umfasst zumindest einen ersten Satz von Ausführungseinheiten 552A-N und Medien/Textur-Abtastern 554A-N. Jeder Subkern im Satz von zweiten Subkernen 560A-N umfasst zumindest einen zweiten Satz von Ausführungseinheiten 562A-N und Abtastern 564A-N. In manchen Ausführungsformen teilen sich die einzelnen Subkerne 550A-N, 560A-N einen Satz von gemeinsamen Ressourcen 570A-N. In manchen Ausführungsformen umfassen die gemeinsamen Ressourcen gemeinsame Cachespeicher und Pixeloperationslogik. Andere gemeinsame Ressourcen können ebenfalls in den verschiedenen Ausführungsformen des Grafikprozessors enthalten sein.
6 veranschaulicht eine Verarbeitungsstrang-Ausführungslogik 600, die eine Anordnung von Verarbeitungselementen umfasst, die in manchen Ausführungsformen einer GPE eingesetzt werden. Elemente in 6 mit derselben Bezugszahl (oder Bezeichnung) wie Elemente einer beliebigen anderen Figur hierin können auf ähnliche Weise arbeiten oder funktionieren wie an anderer Stelle hierin beschrieben, sind jedoch nicht darauf eingeschränkt.
In manchen Ausführungsformen umfasst die Verarbeitungsstrang-Ausführungslogik 600 einen Pixelschattierer 602, einen Verarbeitungsstrangweiterleiter 604, einen Anweisungscache 606, eine skalierbare Ausführungseinheitsanordnung, die eine Vielzahl von Ausführungseinheiten 608A-N umfasst, einen Abtaster 610, einen Datencache 612 und einen Datenanschluss 614. In einer Ausführungsform sind die enthaltenen Komponenten über ein Verbindungsgewebe verbunden, das an jedes der Komponenten angeschlossen ist. In manchen Ausführungsformen umfasst die Verarbeitungsstrang-Ausführungslogik 600 eine oder mehrere Verbindungen mit einem Speicher, wie z. B. einem Systemspeicher oder Cachespeicher, durch einen oder mehrere aus Anweisungscache 606, Datenanschlüssen 614, Abtaster 610 und Ausführungseinheitsanordnungen 608A-N. In manchen Ausführungsformen ist jede Ausführungseinheit (z. B. 608A) ein separater Vektorprozessor, der in der Lage ist, mehrere simultane Verarbeitungsstränge auszuführen und mehrere Datenelemente parallel für die einzelnen Verarbeitungsstränge zu verarbeiten. In manchen Ausführungsformen umfasst die Ausführungseinheitsanordnung 608A-N eine beliebige Anzahl an separaten Ausführungseinheiten.
In manchen Ausführungsformen wird die Ausführungseinheitsanordnung 608A-N primär zur Ausführung von „Schattierer”-Programmen verwendet. In manchen Ausführungsformen führen die Ausführungseinheiten in einer Anordnung 608A-N einen Anweisungssatz aus, der native Unterstützung für viele Standard-3D-Grafik-Schattierer-Anweisungen umfasst, sodass Schattierer-Programme von Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit minimaler Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertexprogramme, Geometrieprogramme, Vertexschattierer), Pixelverarbeitung (z. B. Pixelschattierer, Fragmentschattierer) und Allzweckverarbeitung (z. B. Rechen- und Medienschattierer).
Jede Ausführungseinheit in der Ausführungseinheitsanordnung 608A-N läuft auf Anordnungen von Datenelementen. Die Anzahl an Datenelementen ist die „Ausführungsgröße” oder die Anzahl an Kanälen für die Anweisung. Ein Ausführungskanal ist eine Ausführungseinheit für Datenelementzugang, Maskierung und Flussteuerung innerhalb von Anweisungen. Die Anzahl an Kanälen kann unabhängig von der Anzahl an physischen arithmetischen Logikeinheiten (ALUs) oder Gleitkommaeinheiten (FPUs) für einen bestimmten Grafikprozessor sein. In manchen Ausführungsformen unterstützen die Ausführungseinheiten 608A-N Ganzzahl- und Gleitpunktdatentypen.
Der Ausführungseinheit-Anweisungssatz umfasst Einzelanweisung-Mehrfachdaten-(SIMD-)Anweisungen. Die verschiedenen Datenelemente können als gepackter Datentyp in einem Register gespeichert sein, und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Wenn beispielsweise auf einem 256 Bit breiten Vektor gearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert, und die Ausführungseinheit arbeitet am Vektor als vier separate gepackte 64-Bit-Datenelemente (Datenelemente mit Vierfachwort-(QW-)Größe), acht separate gepackte 32-Bit-Datenelemente (Datenelemente mit Doppelwort-(DW-)Größe), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente mit Wort-(W-)Größe) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente mit Byte-(B-)Größe). Es sind jedoch verschiedene Vektorbreiten und Registergrößen möglich.
Ein oder mehrere interne Anweisungscaches (z. B. 606) sind in der Verarbeitungsstrang-Ausführungslogik 600 enthalten, um Verarbeitungsstranganweisungen für die Ausführungseinheiten zu cachen. In manchen Ausführungsformen sind ein oder mehrere Datencaches (z. B. 612) enthalten, um Verarbeitungsstrangdaten während der Verarbeitungsstrangausführung zu cachen. In manchen Ausführungsformen ist der Abtaster 610 enthalten, um Texturabtastung für 3D-Operationen und Medienabtastung für Medienoperationen auszuführen. In manchen Ausführungsformen umfasst der Abtaster 610 spezialisierte Textur- oder Medienabtastfunktionalität zur Verarbeitung von Textur- oder Mediendaten während des Abtastprozesses, bevor die abgetasteten Daten einer Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und Medienpipelines Verarbeitungsstranginitiationsanfragen an die Verarbeitungsstrang-Ausführungslogik 600 über Verarbeitungsstranginitialisierung und Weiterleitungslogik. In manchen Ausführungsformen umfasst die Verarbeitungsstrang-Ausführungslogik 600 einen lokalen Verarbeitungsstrangweiterleitungsvorrichtung 604, der Verarbeitungsstranginitiationsanfragen aus den Grafik- und Medienpipelines arbitriert und die angefragten Verarbeitungsstränge auf einer oder mehreren Ausführungseinheiten 608A-N instantiiert. Beispielsweise leitet die Geometriepipeline (z. B. 536 in 5) Vertexverarbeitung-, Tessellation- oder Geometrieverarbeitung-Verarbeitungsstränge an die Verarbeitungsstrang-Ausführungslogik 600 (6) weiter. In manchen Ausführungsformen kann der Verarbeitungsstrangweiterleitungsvorrichtung 604 auch Laufzeit-Verarbeitungsstrang-Initialisierungsanfragen von den ausführenden Schattierer-Programmen verarbeiten.
Sobald eine Gruppe von geometrischen Objekten verarbeitet und zu Pixeldaten gerastert wurde, wird der Pixel-Schattierer 602 aufgerufen, um Ausgabeinformationen weiter zu berechnen und die Ergebnisse auf Ausgabeoberflächen (z. B. Farbpuffer, Tiefenpuffer, Matrizenpuffer usw.) schreiben zu lassen. In manchen Ausführungsformen berechnet der Pixel-Schattierer 602 die Werte der verschiedenen Vertexattribute, die über das gerasterte Objekt interpoliert werden sollen. In manchen Ausführungsformen führt der Pixel-Schattierer 602 dann ein über eine API bereitgestelltes Pixel-Schattierer-Programm aus. Um das Pixel-Schattierer-Programm auszuführen, leitet der Pixel-Schattierer 602 Verarbeitungsstränge an die Ausführungseinheit (z. B. 608A) über den Verarbeitungsstrangweiterleitungsvorrichtung 604 weiter. In manchen Ausführungsformen verwendet der Pixel-Schattierer 602 Texturabtastlogik im Abtaster 610, um auf Texturdaten in Texturkarten zuzugreifen, die in einem Speicher gespeichert sind. Arithmetische Operationen an den Texturdaten und den Eingabegeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder leiten ein oder mehrere Pixel für weitere Verarbeitung weiter.
In manchen Ausführungsformen stellt der Datenanschluss 614 einen Speicherzugriffsmechanismus für die Verarbeitungsstrang-Ausführungslogik 600 zur Ausgabe von verarbeiteten Daten an einen Speicher zur Verarbeitung auf einer Grafikprozessorausgabepipeline bereit. In manchen Ausführungsformen umfasst der Datenanschluss 614 einen oder mehrere Cachespeicher (z. B. Datencache 612) oder ist damit gekoppelt, um Daten für Speicherzugriff über den Datenanschluss zu cachen.
7 ist ein Blockdiagramm, das Grafikprozessoranweisungsformate 700 gemäß einigen Ausführungsformen zeigt. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die Kästchen mit durchgehenden Linien zeigen die Komponenten, die im Allgemeinen in einer Ausführungseinheitsanweisung enthalten sind, während die gestrichelten Linien Komponenten zeigen, die optional sind oder nur in einem Untersatz der Anweisungen enthalten sind. In manchen Ausführungsformen besteht das beschriebene und dargestellte Anweisungsformat 700 aus Makroanweisungen, da es sich um Anweisungen handelt, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen als Ergebnis aus einer Anweisungsdekodierung nachdem die Anweisung verarbeitet wurde.
In manchen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten nativ Anweisungen in einem 128-Bit-Format 710. Ein kompaktiertes 64-Bit-Anweisungsformat 730 ist für manche Anweisungen basierend auf der ausgewählten Anweisung, den Anweisungsoperationen und der Anzahl an Operanden verfügbar. Das native 128-Bit-Format 710 stellt Zugang zu allen Anweisungsoptionen bereit, während manche Optionen und Operationen beim 64-Bit-Format 730 eingeschränkt sind. Die nativen Anweisungen, die im 64-Bit-Format 730 verfügbar sind, variieren je nach Ausführungsform. In manchen Ausführungsformen ist die Anweisung unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 teilweise kompaktiert. Die Ausführungseinheit-Hardware bezieht sich auf einen Satz von Kompaktiertabellen basierend auf den Indexwerten und verwendet die Kompaktiertabellenausgaben zur Rekonstruktion einer nativen Anweisung im 128-Bit-Format 710.
Für jedes Format definiert ein Anweisungs-Opkode 712 die Operation, welche die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen die einzelnen Anweisungen parallel über die verschiedenen Datenelemente der einzelnen Operanden aus. Beispielsweise führt die Ausführungseinheit als Antwort auf eine Hinzufügeanweisung eine simultane Hinzufügeoperation in allen Farbkanälen aus, die ein Texturelement oder Bildelement darstellen. Standardmäßig führt die Ausführungseinheit jede Anweisung in allen Datenkanälen der Operanden aus. In manchen Ausführungsformen ermöglicht das Anweisungssteuerungsfeld 712 Kontrolle über bestimmte Ausführungsoptionen, wie z. B. Kanalauswahl (z. B. Predikation) und Datenkanalreihenfolge (z. B. Swizzle). Bei 128-Bit-Anweisungen 710 schränkt ein Ausf-Größe-Feld 716 die Anzahl an Datenkanälen ein, die parallel ausgeführt wird. In manchen Ausführungsformen steht das Ausf-Größe-Feld 716 im 64-Bit-Kompaktanweisungsformat 730 nicht zur Verwendung zur Verfügung.
Einige Ausführungseinheitsanweisungen weisen bis zu drei Operanden auf, einschließlich zwei Quelloperanden, src0 722, src1 722, und ein Ziel 718. In manchen Ausführungsformen unterstützen die Ausführungseinheiten duale Zielanweisungen, wobei eines der Ziele impliziert ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden aufweisen (z. B. SRC2 724), wobei der Anweisungs-Opkode 712 die Anzahl an Quelloperanden bestimmt. Der letzte Quelloperand einer Anweisung kann ein unmittelbarer (z. B. fest kodierter) Wert sein, der mit der Anweisung mitgeschickt wird.
In manchen Ausführungsformen umfasst das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung spezifiziert. In einer Ausführungsform dient der Zugriffsmodus zur Definition einer Datenzugriffsausrichtung für die Anweisung. Einige Ausführungsformen unterstützen Zugriffsmodi, einschließlich eines ausgerichteten 16-Byte-Zugriffsmodus und eines ausgerichteten 1-Byte-Zugriffsmodus, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. In einer Ausführungsform bestimmt der Addressmodusteil des Zugriffs-/Adressmodusfelds 726, ob die Anweisung direkte oder indirekte Adressierung verwenden soll.
In manchen Ausführungsformen sind Anweisungen basierend auf Opkode-Bit-Feldern gruppiert, um Opkode-Dekodierung 740 zu vereinfachen. Bei einem 8-Bit-Opkode erlauben die Bits 4, 5 und 6 es der Ausführungseinheit, den Typ des Opkodes zu bestimmen. Die exakte Opkodegruppierung ist lediglich als Beispiel angeführt. In manchen Ausführungsformen umfasst eine Bewegungs- und Logik-Opkodegruppe 742 Datenbewegungs- und Logikanweisungen (z. B. bewegen (mov), vergleichen (cmp)). In manchen Ausführungsformen haben die Bewegungs- und Logikgruppe 742 die fünf wichtigsten Bits (MSB) gemeinsam, wobei Bewegungs-(mov-)Anweisungen in Form von 0000xxxxb (z. B. 0x0x) und Logikanweisungen in Form von 0001xxxxb (z. B. 0x01) vorliegen. Eine Flusskontrollanweisungsgruppe 744 (z. B. rufen, springen (jmp)) umfasst Anweisungen in der Form 0010xxxxb (z. B. 0x20). Eine gemischte Anweisungsgruppe 746 umfasst eine Mischung aus Anweisungen, einschließlich Synchronisierungsanweisungen (z. B. warte, sende) in der Form 0011xxxxb (z. B. 0x30). Eine parallele mathematische Anweisungsgruppe 748 umfasst komponentenbezogene arithmetische Anweisungen (z. B. addiere, multipliziere (mul)) in der Form 0100xxxxb (z. B. 0x40). Die parallele mathematische Gruppe 748 führt die arithmetischen Operationen parallel über mehrere Datenkanäle aus. Die mathematische Vektorgruppe 750 umfasst arithmetische Anweisungen (z. B. dp4) in der Form 0101xxxxb (z. B. 0x50). Die mathematische Vektorgruppe führt Arithmetik wie beispielsweise Punktproduktberechnungen an Vektoroperanden aus.
Grafikpipeline
8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors 800. Elemente in 8 mit derselben Bezugszahl (oder Bezeichnung) wie Elemente einer beliebigen anderen Figur hierin können auf ähnliche Weise operieren oder funktionieren wie an anderer Stelle hierin beschrieben, sind jedoch nicht darauf eingeschränkt.
In manchen Ausführungsformen umfasst der Grafikprozessor 800 eine Grafikpipeline 820, eine Medienpipeline 830, eine Anzeigemaschine 840, eine Verarbeitungsstrang-Ausführungslogik 850 und eine Bildsynthesemaschine 870. In manchen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkernverarbeitungssystems, das einen oder mehrere Allzweckverarbeitungskerne umfasst. Der Grafikprozessor wird durch Registereinträge in ein oder mehr Kontrollregister (nicht dargestellt) gesteuert oder über Befehle, die über eine Ringverbindung 802 an den Grafikprozessor 800 ausgegeben werden. In manchen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 an andere Verarbeitungskomponenten, wie z. B. andere Grafikprozessoren oder Allzweckprozessoren. Befehle von der Ringverbindung 802 werden von einem Befehlsstreamer 803 interpretiert, der Anweisungen einzelnen Komponenten der Grafikpipeline 820 oder Medienpipeline 830 zuführt.
In manchen Ausführungsformen steuert der Befehlsstreamer 803 den Betrieb einer Vertexabrufvorrichtung 805, die Vertexdaten aus einem Speicher ausliest und Vertexverarbeitungsbefehle ausführt, die vom Befehlsstreamer 803 bereitgestellt werden. In manchen Ausführungsformen stellt die Vertexabrufvorrichtung 805 Vertexdaten für einen Vertex-Schattierer 807 bereit, der Koordinatenraumtransformationen und Beleuchtungsoperationen an jedem Vertex ausführt. In manchen Ausführungsformen führen die Vertexabrufvorrichtung 805 und der Vertex-Schattierer 807 Vertexverarbeitungsanweisungen aus, indem sie Verarbeitungsstränge über eine Verarbeitungsstrang-Weiterleitungsvorrichtung 831 an die Ausführungseinheiten 852A, 852B weiterleiten.
In manchen Ausführungsformen sind die Ausführungseinheiten 852A, 852B eine Anordnung von Vektorprozessoren mit einem Anweisungssatz zur Ausführung von Grafik- und Medienoperationen. In manchen Ausführungsformen weisen die Ausführungseinheiten 852A, 852B einen angeschlossenen L1-Cache 851 auf, der spezifisch für die jeweilige Anordnung ist oder von den Anordnungen gemeinsam genutzt wird. Der Cache kann als Datencache, Anweisungscache oder einzelner Cache konfiguriert sein, der partitioniert ist, um Daten und Anweisungen in unterschiedlichen Partitionen zu enthalten.
In manchen Ausführungsformen umfasst die Grafikpipeline 820 Tessellationskomponenten zur Ausführung von hardwarebeschleunigter Tessellation von 3D-Objekten. In manchen Ausführungsformen konfiguriert ein programmierbarer Hull-Schattierer 811 die Tessellationsoperationen. Ein programmierbarer Domänen-Schattierer 817 stellt Backend-Evaluierung für eine Tessellationsausgabe bereit. Eine Tessellationsvorrichtung 813 arbeitet unter Steuerung des Hull-Schattierers 811 und enthält Speziallogik zur Erzeugung eine Satzes von detaillierten geometrischen Objekten basierend auf einem groben geometrischen Modell, das als Eingabe in die Grafikpipeline 820 bereitgestellt wird. In manchen Ausführungsformen können, wenn keine Tessellation verwendet wird, Tessellationskomponenten 811, 813, 817 umgangen werden.
In manchen Ausführungsformen können komplette geometrische Objekte von einem Geometrie-Schattierer 819 über einen oder mehrere Verarbeitungsstränge verarbeitet werden, die zu den Ausführungseinheiten 852A, 852B weitergeleitet werden, oder sie können direkt zum Clipper 829 fortschreiten. In manchen Ausführungsformen arbeitet der Geometrie-Schattierer auf ganzen geometrischen Objekten und nicht an Vertices oder Stücken von Vertices wie in vorangegangenen Stufen der Grafikpipeline. Wenn die Tessellation abgeschaltet ist, empfängt der Geometrie-Schattierer 819 Eingaben vom Vertex-Schattierer 807. In manchen Ausführungsformen ist der Geometrie-Schattierer 819 durch ein Geometrie-Schattierer-Programm programmierbar, um Geometrie-Tessellation auszuführen, wenn die Tessellationseinheiten ausgeschaltet sind.
Vor der Rasterung verarbeitet ein Clipper 829 Vertexdaten. Der Clipper 829 kann ein Clipper mit fixer Funktion oder ein programmierbarer Clipper mit Clipping- und Geometrie-Schattierer-Funktionen sein. In manchen Ausführungsformen leitet eine Rasterungsvorrichtung 873 in der Bildsyntheseausgabepipeline 870 Pixel-Schattierer an, die geometrischen Objekte in ihre Pixeldarstellungen umzuwandeln. In manchen Ausführungsformen ist eine Pixel-Schattierer-Logik in der Verarbeitungsstrang-Ausführungslogik 850 enthalten. In manchen Ausführungsformen kann eine Anwendung die Rasterungsvorrichtung 873 umgehen über eine Stream-Out-Einheit 823 auf ungerasterte Vertexdaten zugreifen.
Der Grafikprozessor 800 weist einen Verbindungsbus, ein Verbindungsgewebe oder einen anderen Verbindungsmechanismus auf, der Übertragen von Daten und Botschaften zwischen den Hauptkomponenten des Prozessors erlaubt. In manchen Ausführungsformen sind die Ausführungseinheiten 852A, 852B und (ein) zugeordnete(r) Cache(s) 851, ein Textur- und Medienabtaster 854 und ein Textur-/Abtastercache 858 über einen Datenanschluss 856 verbunden, um Speicherzugriff auszuführen und mit Bildsyntheseausgabepipelinekomponenten des Prozessors zu kommunizieren. In manchen Ausführungsformen weisen der Abtaster 854, die Caches 851, 858 und die Ausführungseinheiten 852A, 852B jeweils separate Speicherzugriffspfade auf.
In manchen Ausführungsformen enthält die Bildsyntheseausgabepipeline 870 eine Rasterungsvorrichtung und eine Tiefentestkomponente 873, die vertexbasierte Objekte in eine zugeordnete pixelbasierte Darstellung umwandelt. In manchen Ausführungsformen umfasst die Rasterungsvorrichtungslogik eine Fensterbildungs-/Maskiereinheit zur Ausführung von Dreieck- und Linienrasterung mit fixer Funktion. Zugeordnete Bildsynthese- und Tiefenpuffercaches 878, 879 sind in manchen Ausführungsformen ebenfalls vorhanden. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten aus, obwohl in manchen Fällen Pixeloperationen, die mit 2D-Operationen zusammenhängen (z. B. Bitblockbildtransfers mit Mischen), von der 2D-Maschine 841 ausgeführt werden oder zum Anzeigezeitpunkt von der Anzeigensteuerung 843 unter Verwendung von Überlagerungsanzeigenebenen ergänzt werden. In manchen Ausführungsformen steht ein gemeinsamer L3-Cache 875 für alle Grafikkomponenten zur Verfügung, der das Teilen der Daten ohne Einsatz eines Hauptsystemspeichers ermöglicht.
In manchen Ausführungsformen umfasst die Grafikprozessor-Medienpipeline 830 eine Medienmaschine 837 und ein Video-Frontend 834. In manchen Ausführungsformen empfängt das Video-Frontend 834 Pipelinebefehle vom Befehlsstreamer 803. In manchen Ausführungsformen umfasst die Medienpipeline 830 einen separaten Befehlsstreamer. In manchen Ausführungsformen verarbeitet das Video-Frontend 834 Medienbefehle, bevor der Befehl zur Medienmaschine 837 gesendet wird. In manchen Ausführungsformen umfasst die Medienmaschine 337 Verarbeitungsstrangweiterleitungsfunktionalität zur Initialisierung von Verarbeitungssträngen zur Weiterleitung zur Verarbeitungsstrang-Ausführungslogik 850 über die Verarbeitungsstrangweiterleitungsvorrichtung 831. In manchen Ausführungsformen umfasst der Grafikprozessor 800 eine Anzeigemaschine 840. In manchen Ausführungsformen ist die Anzeigemaschine 840 extern vom Prozessor 800 und über die Ringverbindung 802 oder ein(en) anderen/s Verbindungsbus oder -gewebe mit dem Grafikprozessor gekoppelt. In manchen Ausführungsformen umfasst die Anzeigemaschine 840 eine 2D-Maschine 841 und eine Anzeigensteuerung 843. In manchen Ausführungsformen enthält die Anzeigemaschine 840 spezielle Logik, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In manchen Ausführungsformen ist die Anzeigensteuerung 843 mit einer Anzeigevorrichtung (nicht dargestellt) gekoppelt, die eine systemintegrierte Anzeigevorrichtung sein kann, wie etwa in einem Laptopcomputer, oder eine externe Anzeigevorrichtung, die über eine Anzeigevorrichtungsverbindung angeschlossen ist.
In manchen Ausführungsformen sind die Grafikpipeline 820 und die Medienpipeline 830 konfigurierbar, um Operationen basierend auf mehreren Grafik- und Medienprogrammierschnittstellen auszuführen und sind nicht für eine bestimmte Anwendungsprogrammierschnittstelle (API) spezifisch. In manchen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Anfragen, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die vom Grafikprozessor verarbeitet werden können. In manchen Ausführungsformen werden die Open Graphics Library (OpenGL) und die Open Computing Language (OpenCL) der Khronos Group, die Direct3D-Bibliothek von Microsoft Corporation oder sowohl OpenGL als auch D3D unterstützt. Auch die Open Source Computer Vision Library (OpenCV) kann unterstützt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde auch unterstützt, wenn eine Abbildung von der Pipeline der zukünftigen API zur Pipeline des Grafikprozessors durchgeführt werden kann.
Grafikpipeline-Programmierung
9A ist ein Blockdiagramm eines Grafikprozessor-Befehlsformats 900 gemäß einigen Ausführungsformen. 9B ist ein Blockdiagramm einer Grafikprozessor-Befehlssequenz 910 gemäß einer Ausführungsform. Die Rahmen aus durchgehenden Linien in 9A zeigen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten zeigen, die optional sind oder nur in einem Untersatz der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 aus 9A umfasst Datenfelder zur Identifikation eines Ziel-Clients 902 des Befehls, eines Befehlsoperationskodes (Opkode) 904 und der relevanten Daten 906 für den Befehl. Ein Subopkode 905 und eine Befehlsgröße 908 sind in manchen Befehlen ebenfalls enthalten.
In manchen Ausführungsformen spezifiziert der Client 902 die Client-Einheit der Grafikvorrichtung, welche die Befehlsdaten verarbeitet. In manchen Ausführungsformen untersucht ein Grafikprozessorbefehlszerteiler das Client-Feld für jeden Befehl, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten zur geeigneten Client-Einheit zu routen. In manchen Ausführungsformen umfassen die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Bildsyntheseeinheit, eine 2D-Einheit, eine 3D-Einehit und eine Medieneinheit. Jede Client-Einheit weist eine entsprechende Verarbeitungspipeline auf, welche die Befehle verarbeitet. Sobald der Befehl von der Client-Einheit empfangen wird, liest die Client-Einheit den Opkode 904 und, falls vorhanden, den Subopkode 905, um die auszuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Informationen im Datenfeld 906 aus. Bei manchen Befehlen wird erwartet, dass eine explizite Befehlsgröße 908 die Größe des Befehls spezifiziert. In manchen Ausführungsformen bestimmt der Befehlszerteiler automatisch die Größe von zumindest einigen der Befehle basierend auf dem Befehlsopkode. In manchen Ausführungsformen werden Befehle über Mehrfache eines Doppelworts angeordnet.
Das Flussdiagramm in 9B zeigt eine beispielhafte Befehlssequenz 910. In manchen Ausführungsformen verwendet eine Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessor ist, eine Version der Befehlssequenz, die einen Satz von Grafikoperationen erstellt, ausführt und beendet. Eine beispielhafte Befehlssequenz ist lediglich als Beispiel dargestellt und beschrieben, da Ausführungsformen nicht auf diese bestimmten Befehle oder auf diese Befehlssequenz eingeschränkt sind. Außerdem können die Befehle als Befehlsstapel in einer Befehlssequenz ausgegeben werden, sodass der Grafikprozessor die Befehlssequenz in zumindest teilweiser Übereinstimmung verarbeitet.
In manchen Ausführungsformen kann eine beispielhafte Befehlssequenz 910 mit einem Pipelinespülbefehl 912 beginnen, damit jegliche aktive Grafikpipelines die noch unerledigten Befehle für die Pipeline beenden. In manchen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medienpipeline 924 nicht gleichzeitig. Die Pipelinespülung wird durchgeführt, damit die aktive Grafikpipeline jegliche noch unerledigte Befehle beendet. Als Reaktion auf eine Pipelinespülung pausiert der Befehlszerteiler für den Grafikprozessor die Befehlsverarbeitung bis die aktive Zeichenmaschine unerledigte Operationen beendet und die relevanten Lesecaches invalidiert sind. Gegebenenfalls können beliebige Daten im Bildsynthesecache, die als ,schmutzig' markiert sind, in einen Speicher gespült werden. In manchen Ausführungsformen kann der Pipelinespülbefehl 912 zur Pipelinesynchronisierung verwendet werden oder bevor der Grafikprozessor in einen Niedrigleistungszustand versetzt wird.
In manchen Ausführungsformen wird ein Pipelineauswahlbefehl 913 verwendet, wenn eine Befehlssequenz vom Grafikprozessor explizit verlangt, zwischen den Pipelines umzuschalten. In manchen Ausführungsformen ist der Pipelineauswahlbefehl 913 nur einmal innerhalb eines Ausführungskontexts erforderlich, bevor Pipelinebefehle ausgegeben werden, sofern der Kontext nicht die Ausgabe von Befehlen für beide Pipelines ist. In manchen Ausführungsformen ist ein Pipelinespülbefehl 912 direkt vor einer Pipelineumschaltung durch den Pipelineauswahlbefehl 913 erforderlich.
In manchen Ausführungsformen konfiguriert ein Pipelinesteuerbefehl 914 eine Grafikpipeline zur Operation und wird verwendet, um die 3D-Pipeline 922 und die Medienpipeline 924 zu programmieren. In manchen Ausführungsformen konfiguriert der Pipelinesteuerbefehl 914 den Pipelinezustand für die aktive Pipeline. In einer Ausführungsform wird der Pipelinesteuerbefehl 914 zur Pipelinesynchronisierung und zur Entfernung von Daten aus einem oder mehreren Cachespeichern innerhalb der aktiven Pipeline verwendet, bevor ein Befehlsstapel verarbeitet wird.
In manchen Ausführungsformen werden Rückkehrpufferzustandsbefehle 916 verwendet, um einen Satz von Rückkehrpuffern für die jeweiligen Pipelines zu konfigurieren, damit sie Daten schreiben. Manche Pipelineoperationen erfordern die Zuordnung, Auswahl oder Konfiguration eines oder mehrerer Rückkehrpuffer, in welche die Operationen Zwischendaten während der Verarbeitung schreiben. In manchen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückkehrpuffer zum Speichern von Ausgabedaten und zur Durchführung von Kreuzverarbeitungsstrangkommunikation. In manchen Ausführungsformen umfasst der Rückkehrpufferzustand 916 Auswählen der Größe und Anzahl von Rückkehrpuffern zur Verwendung für einen Satz von Pipelineoperationen.
Die restlichen Befehle in der Befehlssequenz unterscheiden sich je nach aktiver Pipeline für Operationen. Basierend auf einer Pipelinebestimmung 920 wird die Befehlssequenz 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 umfassten 3D-Zustandeseinstellungsbefehle für einen Vertexpufferzsutand, Vertexelementzustand, konstanten Farbzustand, Tiefenpufferzustand und andere Zustandsvariablen, die konfiguriert werden müssen, bevor 3D-Primitiv-Befehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise basierend auf jeweils verwendeten 3D-API bestimmt. In manchen Ausführungsformen sind 3D-Pipeline-Zustand- 930 Befehle auch in der Lage, bestimmte Pipeline-Elemente selektiv auszuschalten oder zu umgehen, wenn diese Elemente nicht verwendet werden.
In manchen Ausführungsformen wird ein 3D-Primitiv-Befehl 932 verwendet, um 3D-Primitive zuzustellen, die von der 3D-Pipeline verarbeitet werden sollen. Befehle und zugehörige Parameter, die über das 3D-Primitiv 392 zum Grafikprozessor geleitet werden, werden zur Vertexabruffunktion in der Grafikpipeline weitergeleitet. Die Vertexabruffunktion verwendet die Befehlsdaten des 3D-Primitivs 932 zur Erzeugung von Vertexdatenstrukturen. Die Vertexdatenstrukturen werden in einem oder mehreren Rückkehrpuffern gespeichert. In manchen Ausführungsformen wird der 3D-Primitiv-Befehl 932 verwendet, um Vertexoperationen an 3D-Primitiven über Vertex-Schattierer durchzuführen. Um Vertex-Schattierer zu verarbeiten, leitet die 3D-Pipeline 922 Schattierer-Ausführungsverarbeitungsstränge an Grafikprozessor-Ausführungseinheiten weiter.
In manchen Ausführungsformen wird die 3D-Pipeline 922 über einen Befehl oder Vorgang Ausführen 934 ausgelöst. In manchen Ausführungsformen löste eine Registereintragung Befehlsausführung aus. In manchen Ausführungsformen wird die Ausführung durch einen Befehl ,Go' oder ,Kick' in der Befehlssequenz ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipelinesynchronisierungsbefehls ausgelöst, um die Befehlssequenz durch die Grafikpipeline zu spülen. Die 3D-Pipeline führt Geometrieverarbeitung für die 3D-Primitive aus. Sobald Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixelmaschine färbt die resultierenden Pixel ein. Weitere Befehle zur Steuerung von Pixelschattierung und Pixel-Backend-Operationen können ebenfalls für diese Operationen enthalten sein.
In manchen Ausführungsformen folgt die beispielhafte Befehlssequenz 910 dem Pfad der Medienpipeline 924, wenn Medienoperationen ausgeführt werden. Im Allgemeinen hängt die jeweilige Verwendung und Art der Programmierung für die Medienpipeline 924 von den Medien oder auszuführenden Rechenoperationen ab. Bestimmte Mediendekodieroperationen können während der Mediendekodierung an die Medienpipeline abgeladen werden. In manchen Ausführungsformen kann die Medienpipeline auch umgangen werden und die Mediendekodierung kann als Ganzes oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Allzweckverarbeitungskernen bereitgestellt werden. In einer Ausführungsform umfasst die Medienpipeline auch Elemente für Allzweckgrafikprozessoreinheit-(GPGPU-)Operationen, wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von rechnerischen Schattiererprogrammen auszuführen, die nicht explizit mit der Bildsynthese von Grafikprimitiven zusammenhängen.
In manchen Ausführungsformen ist die Medienpipeline 924 auf ähnliche Weise konfiguriert wie die 3D-Pipeline 922. Ein Satz von Medienpipelinezustandsbefehlen 940 wird vor den Medienobjektbefehlen 942 in eine Befehlswarteschlange weitergeleitet oder gegeben. In manchen Ausführungsformen umfassen die Medienpipelinezustandsbefehle 940 Daten zur Konfiguration der Medienpipelineelemente, die zur Verarbeitung der Medienobjekte verwendet werden.
Dies umfasst Daten zur Konfiguration der Videodekodier- und Videokodierlogik innerhalb der Medienpipeline, wie z. B. das Kodier- oder Dekodierformat. In manchen Ausführungsformen unterstützen die Medienpipelinezustandsbefehle 940 auch die Verwendung eines oder mehrerer Zeiger auf „indirekte” Zustandselemente, die eine Gruppe von Zustandseinstellungen enthalten.
In manchen Ausführungsformen stellen Medienobjektbefehle 942 Zeiger auf Medienobjekte zur Verarbeitung durch die Medienpipeline bereit. Die Medienobjekte umfassen Speicherpuffer, die zu verarbeitende Videodaten enthalten. In manchen Ausführungsformen müssen alle Medienpipelinezustände gültig sein, bevor Medienobjektbefehl 942 ausgegeben wird. Sobald der Pipelinezustand konfiguriert ist und Medienobjektbefehle 942 gereiht sind, wird die Medienpipeline 924 über einen Ausführungsbefehl 944 oder einen äquivalenten Ausführungsvorgang (z. B. Schreiben ins Register) ausgelöst. Eine Ausgabe der Medienpipeline 924 kann dann durch Operationen nachbearbeitet werden, die von der 3D-Pipeline 922 oder der Medienpipeline 924 bereitgestellt werden. In manchen Ausführungsformen werden GPGPU-Operationen auf ähnliche Weise konfiguriert und ausgeführt wie Medienoperationen.
Grafiksoftwarearchitektur
10 zeigt eine beispielhafte Grafiksoftwarearchitektur 1000 für ein Datenverarbeitungssystem gemäß einigen Ausführungsformen. In manchen Ausführungsformen umfasst die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und zumindest einen Prozessor 1030. In manchen Ausführungsformen umfasst der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Allzweckprozessorkern(e) 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In manchen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Schattiererprogramme, die Schattiereranweisungen 1012 umfassen. Die Schattiererspracheanweisungen können in einer höheren Schattierersprache vorliegen, wie z. B. High Level Shading Language (HLSL) oder OpenGL Shading Language (GLSL). Die Anwendung umfasst auch ausführbare Anweisungen 1014 in einer Maschinensprache, die zur Ausführung durch den Allzweckprozessorkern 1034 geeignet ist. Die Anwendung umfasst außerdem Grafikobjekte 1016, die durch Vertexdaten definiert sind.
In manchen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft^®-Windows^®-Betriebssystem von Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein UNIX-ähnliches Open-Source-Betriebssystem basierend auf einer Variante des Linux-Kerns. Wenn die Direct3D-API in Verwendung ist, verwendet das Betriebssystem 1020 einen Frontend-Schattiererkompilierer 1024 zur Kompilation von Schattiereranweisungen 1012 in HLSL in einer niedrigeren Schattierersprache. Die Kompilation kann eine einsatzsynchrone (JIT) Kompilation sein oder die Anwendung kann eine Schattierervorkompilation durchführen. In manchen Ausführungsformen werden hohe Schattierer während der Kompilation der 3D-Grafikanwendung 1010 in niedrige Schattierers kompiliert.
In manchen Ausführungsformen enthält ein Benutzermodusgrafiktreiber 1026 einen Backend-Schattiererkompilierer 1027 zur Umwandlung der Schattiereranweisungen 1012 in eine hardwarespezifische Darstellung. Wenn die OpenGL-API in Verwendung ist, werden Schattiereranweisungen 1012 in der hohen GLSL-Sprache zur Kompilation zu einem Benutzermodusgrafiktreiber 1026 geleitet. In manchen Ausführungsformen verwendet der Benutzermodusgrafiktreiber 1026 Betriebssystemkernmodusfunktionen 1028 zur Kommunikation mit einem Kernmodusgrafiktreiber 1029. In manchen Ausführungsformen kommuniziert der Kernmodusgrafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen weiterzuleiten.
Grafikübersetzungstabellen
11 stellt einen Überblick über ein beispielhaftes GPU-Programmiermodell, das Grafikübersetzungstabellen umfasst, gemäß einer Ausführungsform bereit. Das Programmiermodell veranschaulicht die Wechselwirkung zwischen einem oder mehreren Systemprozessoren 1102 und einer GPU 1108 unter Verwendung eines gemeinsamen Speichers 1104, der in einer Ausführungsform ein Systemspeicher ist. Der gemeinsame Speicher umfasst einen Befehlspuffer 1114 und einen Einzelbildpuffer 1124. Ein Satz von Grafikübersetzungstabellen (GTT) wird verwendet, damit der Grafikspeicher auf den Systemspeicher zugreifen kann, der den Befehlspuffer 1114 und Einzelbildpuffer 1124 umfasst.
In einer Ausführungsform programmieren der eine oder die mehreren Systemprozessoren 1102 die GPU 1108 unter Verwendung von GPU-spezifischen Befehlen, wie z. B. in 9A–B beschrieben. In einer Ausführungsform programmiert ein Grafiktreiber Befehle in den Befehlspuffer 1114, der im Systemspeicher 1104 gespeichert ist. In einer Ausführungsform informieren ein oder mehrere Prozessoren die GPU, wenn die Befehle zur Ausführung bereit sind, beispielsweise über prozessorspezifische Methoden, wie z. B. das Schwanzregister eines Bildsyntheseringpuffers und/oder die Vorlage einer Ausführungsliste. Die Bildsynthesemaschine 1128 der GPU 1108 ruft dann die Befehle im Befehlspuffer 1114 ab und führt sie aus. Das Abrufen und Ausführen kann direkt nach der Benachrichtigung der GPU durch den Prozessor stattfinden, dass Befehle im Bildsynthesering bereit sind, oder das Abrufen kann zu einem späteren Zeitpunkt basierend auf der internen GPU-Zeitplanung oder Verwaltungsstrategie erfolgen.
In einer Ausführungsform führt die GPU ein einziges Abrufen aller unerledigter Befehle und Anweisungen aus, verwendet die GTT für eine Übersetzung und speichert die GTT-Daten in einem internen Cache, bevor sie beginnt, die Grafikbefehle auszuführen. In einer Ausführungsform ruft die GPU die Anweisungen basierend auf interner Ressourcenverfügbarkeit ab und führt sie aus, und sie kann auf die GTT mehrere Male während der Verarbeitung von Grafikbefehlen für eine Speicherübersetzung zugreifen. In einer Ausführungsform führt die GPU-Bildsynthesemaschine unabhängig von beliebigen des einen oder der mehreren Prozessoren aus und die Prozessoren und die GPU sollten Annahmen bezüglich der Ausführungsgeschwindigkeit jeglicher anderer Gegenstücke vermeiden. Die Verfügbarkeit eines Ausführungsergebnisses eines Prozessors oder einer GPU sollte nicht angenommen werden, sofern nicht ein expliziter Synchronisierungsvorgang zwischen einem Prozessor und einer GPU vorhanden ist.
In einer Ausführungsform führt die Bildsynthesemaschine 1128 Grafikoperationen basierend auf den Befehlen und Ausgaben von Bildsynthesedaten zu einem Bildsyntheseziel in einem Speicher aus, was schlussendlich in den Einzelbildpuffer 1124 im Speicher geschrieben wird. In einer Ausführungsform können der eine oder die mehreren Prozessoren manche Operationen parallel mit der GPU 1108 ausführen und diese Ergebnisse an den Einzelbildpuffer 1124 ausgeben. Die Anzeigemaschine ruft dann Pixeldaten aus dem Einzelbildpuffer 1124 ab und gibt die Pixeldaten an eine Anzeige aus.
In manchen Ausführungsformen kann ein Systemspeicher von einer GTT 1118 in mehrere virtuelle Adressräume abgebildet werden. In einer Ausführungsform ist ein 2 GB großer, globaler, virtueller Adressraum für sowohl die GPU 1108 als auch den einen oder die mehreren Prozessoren 1102 zugänglich und wird durch eine globale Kacheltabelle in der GTT 1118 abgebildet. In einer Ausführungsform wird ein lokaler Grafikspeicher für die Bildsynthesemaschine von mehreren 2 GB großen, lokalen, virtuellen Adressräumen unterstützt.
12 zeigte beispielhaft globale und prozessbezogene Grafikübersetzungstabellen in der Grafikvirtualisierungsumgebung gemäß einer Ausführungsform. In einer Ausführungsform umfasst die Grafikvirtualisierungsumgebung 1200 eine globale GTT 1288 und eine prozessbezogene GTT 1289 zur Konfiguration des Zugriffs auf einen Speicher 1296 für ein Grafikmodul 1290 (z. B. Bildsynthesemaschine 1128, Anzeigemaschine 1138 aus 11). In einer Ausführungsform wird die lokale, prozessbezogene GTT unter Verwendung einer Zweiebenen-Auslagerungsstruktur implementiert. Die erste Ebene umfasst Kachelverzeichniseinträge (PDEs) in eine Kachelverzeichnistabelle (PDT) 1292. Die PDEs im Kachelverzeichnis 1292 enthalten Kacheltabellenbasisadressen. Die zweite Ebene umfasst die Kacheltabellen (z. B. 1294). Jede Kacheltabelle 1294 umfasst Kacheltabelleneinträge (PTEs), die Speicherfensteradressen (z. B. Speicherfensternummern) in einem physischen Speicher speichern, die im Grafikmodul 1290 abgebildet werden.
Obwohl sie separat dargestellt sind, können in einer Ausführungsform zumindest manche der Einträge im Kacheltabellenverzeichnis 1292 der prozessbezogenen GTT in der globalen GTT 1288 enthalten sein.
GPU-Virtualisierung
Die hierin beschriebenen Ausführungsformen können durch ein GPU-Virtualisierungssystem virtualisiert werden. Die GPU-Virtualisierung ermöglicht es einer virtuellen GPU (vGPU) innerhalb einer virtuellen Maschine, auf die volle von der GPU-Hardware bereitgestellte Funktionalität zuzugreifen. Die virtuelle GPU kann mehreren virtuellen Guest-Maschinen (VMs) präsentiert werden. Die Guest-VMs können auf den vollen Umfang der GPU-Funktionen zugreifen und native GPU-Treibersoftware verwenden, um virtuelle Grafikprozessoren zu verwalten. Der vGPU-Kontext wird pro Quantum oder Vorgang umgeschaltet, wobei abwechselnd eine vGPU jeder VM zum „Eigentümer-Guest” wird. In einer Ausführungsform kann die Kontextschaltung pro GPU-Bildsynthesemaschine stattfinden. Das regelmäßige Umschalten erlaubt es mehreren VMs, sich eine physische GPU auf eine Weise zu teilen, die für die Benutzer transparent ist.
In einer Ausführungsform verwaltet die virtuelle GPU Grafikspeicherabbildung mittels Guest- und Shadow-Grafikübersetzungstabellen (GTT), die einen Grafikprozessorspeicher im Systemspeicher abbilden. Jede VM weist eine Guest-GTT zur Übersetzung der Grafikspeicherkachelnummer in die Guest-Speicherkachelnummer (GPN) auf. Die Shadow-GTT-Einträge werden von der Grafikspeicherkachelnummer in eine Host-Speicherkachelnummer (HPN) übersetzt. In einer Ausführungsform wird die Shadow-GTT geteilt und enthält die Übersetzungen für mehrere VMs. In einer Ausführungsform umfasst jede VM sowohl prozessbezogene als auch globale GTTs. Die GTT-Synchronisierungsmechanismen, die hierin beschrieben sind, können zur Synchronisierung von sowohl globalen als auch prozessbezogenen GTTs verwendet werden.
In einer Ausführungsform werden die Guest- und Shadow-GTTs über ein Hybrid-Shadow-Konstruktionsschema (HSCS) synchronisiert, das entweder eine synchrone oder eine asynchrone Shadow-GTT-Implementierung basierend auf Guest-GTT-Zugriffsheuristiken implementiert. In einer Ausführungsform ist bei synchroner Operation die Speicherkachel einer Guest-GTT schreibgeschützt. Jede Aktualisierung der Guest-GTT führt zu einer Schreibschutzfalle, die vom Mediator gehandhabt wird. Ein VM-Mediator handhabt die Falle, indem er die entsprechenden Aktualisierungen sowohl in der Shadow-GTT als auch der Guest-GTT je nach Strategie durchführt. In einem Beispiel kann die Guest-GTT mit GPN aktualisiert werden, und die Shadow-GTT kann mit HPN aktualisiert werden. Bei synchronem Betrieb werden die Guest- und Shadow-GTT synchron gehalten, auch wenn der Guest nicht der Eigentümer-Guest ist. Bei asynchronem Betrieb ist die Guest-GTT nicht schreibgeschützt und der Guest kann die GTT-Einträge frei aktualisieren. Wenn die Guest-VM zum Eigentümer-Guest eines bestimmten Bildsyntheserings wird, kann ein Prozessor die GPU informieren, dass Befehle zur Ausführung bereit sind (z. B. durch eine Schwanzregisteraktualisierung). In einer Ausführungsform fängt der VMM die Benachrichtigung ab und rekonstruiert die Shadow-GTT, bevor die Befehle weitergegeben werden. In einer Ausführungsform kann es der Guest-GTT erlaubt sein, aus der Synchronisierung mit der Shadow-GTT auszutreten (z. B. asynchron zu arbeiten), bis Befehle tatsächlich zur physischen GPU weitergeleitet werden.
13 ist ein Blockdiagramm einer beispielhaften Grafikvirtualisierungsumgebung gemäß einer Ausführungsform. In einer Ausführungsform umfasst die Virtualisierungsumgebung eine Host- oder Service-VM 1302, die ein Host-Betriebssystem sein kann, das eine Schnittstelle mit einem Host- (z. B. Typ-zwei-)Hypervisor/Monitor für virtuelle Maschinen (VMM) 1320 aufweisen kann, wobei der VMM als Teil der Host-OS-Kernkomponenten vorliegt, oder eine VM mit privilegiertem Dienst, die auf einer nackten Maschine (z. B. Typ 1) einer VMM-1320-Schnittstelle läuft, wobei der VMM unter der VM mit privilegiertem Dienst liegt. Der VMM 1320 stellt virtualisierten Zugriff auf einen Grafikprozessor (z. B. GPU) 1330 für eine oder mehrere Guest-VMs (z. B. VM1 1304, VM2 1306) bereit. Die Guest-VMs 1304, 1306 und die Host/Service-VM 1302 können mit nativen GPU-Treibern 1308a–b beladen sein, die Versionen der GPU-Treibersoftware sind, die zur Steuerung einer nichtvirtualisierten GPU verwendet werden. In einer Ausführungsform umfasst die Host/Dienst-VM 1302 außerdem einen Mediator 1312, der einen vGPU-Vorrichtungsmodelltreiber 1314 umfasst, um GPU-Virtualisierung über ein vGPU-VMM-Modul 1324 innerhalb des VMM 1320 zu steuern. Der Mediator 1312 kann Teil des nativen GPU-Treibers oder ein separates Modul sein.
In einer Ausführungsform unterscheidet sich der Betrieb des Mediators basierend auf der Verwendung eines Typ-eins- oder Typ-zwei-Hypervisors. Bei einem Typ-zwei-Hypervisor können Haken im Treiberkode für die vGPU platziert werden, um vom Mediator 1312 bereitgestellte Zugriffsfunktionen aufzurufen. Bei einem Typ-eins-Hypervisor können Softwarefallen verwendet werden, um es dem Mediator 1312 zu ermöglichen, der vGPU Funktionalität zu verleihen. Es versteht sich, dass bei Beschreibung der Verwendung von Fallen oder des Abfangen-und-Emulieren-Modells hierin ähnliche Funktionalität unter Verwendung eines Typ-zwei-Hypervisors unter Verwendung von Software-Haken im Treiberkode bereitgestellt werden kann, um auf den vGPU-Mediator 1312 zuzugreifen. Demgemäß sind hierin beschriebene Ausführungsformen nicht auf einen bestimmten Typ von Hypervisor beschränkt
In einer Ausführungsform wird eine vermittelte Durchleitung eingeschaltet, bei dem Guest-VMs 1304, 1306 direkt auf leistungsentscheidende Ressourcen innerhalb der GPU 1330 zugreifen können, ohne Intervention durch den VMM 1320. In solchen Ausführungsformen können leistungsentscheidende Operationen von VMs (z. B. Bildsyntheseoperationen) unter Verwendung eines Durchleitungsaufrufs 1316 an die GPU 1330 ausgeführt werden. Privilegierte Grafikoperationen von den VMs 1304, 1306 werden jedoch durch ein Abfangen-und-Emulieren-Modell gehandhabt, bei dem der VM-Zugriff 1317 eine Softwarefalle auslöst, die zum Mediator 1312 geroutet 1318 wird. Der Mediator 1312 kann dann die Falle emulieren und die entsprechenden Operationen auf der GPU-Hardware ausführen. In einer Ausführungsform, die für einen Typ-eins-Hypervisor konfiguriert ist, emuliert der Mediator 1312 die Falle über einen Hypervisoraufruf 1319 an das vGPU-VMM-Modul 1324 im VMM 1320, die privilegierten Zugriff auf die GPU 1330 hat. In einer Ausführungsform, die für einen Typ-zwei-Hypervisor konfiguriert ist, emuliert der Mediator 1313 die Falle und betreibt die GPU-Hardware über einen nativen Treiber 1308a eines Host-OS, wobei der native Treiber 1308a in einem privilegierten Modus läuft.
In einer Ausführungsform wird der vGPU-Kontext pro Quantum geschaltet, wobei jede VM regelmäßig zum „Eigentümer-Guest” wird. Dieses regelmäßige Umschalten ermöglicht es mehreren VMs, eine physische GPU auf eine Weise zu teilen, die für Benutzer der VM transparent ist. Beispielsweise kann der Guest Befehlspuffer vorbereiten und die Verwendung des virtuellen Grafikzustands der GPU programmieren, wenn die VM nicht der Eigentümer-Guest der GPU ist. Der VMM kann die vorbereiteten Befehlspuffer an die GPU weiterleiten, wenn die VMs zum Eigentümer-Guest der vGPU werden. In einer Ausführungsform werden, wenn eine VM Eigentümer-Guest ist, die VM-Befehle im Befehlspuffer einer Bildsynthesemaschine in der GPU 1330 (z. B. Bildsynthesemaschine 1128 in 11) bereitgestellt.
Jeder native Grafiktreiber der Guest-VM (und Dienst-VM in einem Typ-eins-Hypervisor) kann eine separate Guest-GTT 1311, 1310 aufweisen, die globale und prozessbezogene GTTs umfasst. Der Mediator 1312 kann unter Verwendung des vGPU-Vorrichtungsmodelltreibers 1314 die Guest-GTTs 1311, 1310 kopieren (Shadowing), um die GTT 1322 entweder synchron mit jeder Guest-GTT-Modifikation oder asynchron vor dem Weiterleiten von Bildsynthesebefehlen zu kopieren. In einem Typ-zwei-VMM kann der native Grafiktreiber eines Hosts zusätzlich eine separate Shadow-GTT verwalten.
Prozesse, die GPU-Aufgaben ausführen, neigen dazu, Grafikspeicher chargenweise zuzuordnen und zu leeren, was die Auswirkung von GTT-Modifikationen auf den Bildsyntheseprozess verringert. Somit sind die Abfang- und Emulierverwaltungsdaten, die durch Synchronhalten der Guest-GTT mit der Shadow-GTT erzeugt werden, im Allgemeinen beschränkt. Es kann jedoch zu Leistungsproblemen kommen, wenn der Guest häufig die GTT manipuliert. Manche Medientranskodierbenchmarks führen zu schlechter Virtualisierungsleistung aufgrund des häufigen Wechselns von Grafikspeicherkacheln, was eine große Anzahl von GTT-Modifikationen mit sich bringt.
In einer Ausführungsform umfasst der Mediator 1312 eine Logik zur Bestimmung, dass ein Guest eine Reihe von zusammenhängenden GTT-Kachelmodifikationen ausführt oder wiederholte Modifikationen am selben GTT-Eintrag ausführt. In einer Ausführungsform soll die Logik eine Anzahl von GTT-Kacheltabellenmodifikationen bestimmen, die eine definierte Schwelle innerhalb eines Zeitraums überschreitet (z. B. 500 Aktualisierungen pro Sekunde). Die genaue Schwelle kann in manchen Ausführungsformen dynamisch bestimmt werden. Basierend auf dieser Bestimmung kann der Mediator den Schreibschutz an der Guest-GTT entfernen und in einen asynchronen Betrieb überleiten, bei dem die Guest-GTT nicht mit der Schadow-GTT synchronisiert ist, bis die Guest-VM-Befehle bereit für die Weiterleitung an die Grafikhardware sind. In einer Ausführungsform rekonstruiert der Mediator dann in einer Ausführungsform die Shadow-GTT und schaltet um, wenn eine VM zu einem Eigentümer-Guest wird, wobei der Mediator die Shadow-GTT so rekonstruiert, dass sie mit der Guest-GTT synchronisiert ist, wenn neue vGPU-Befehle der physischen GPU zugestellt werden sollen.
14 ist ein Flussdiagramm einer Logik zum Eintritt in einen asynchronen Modus für eine Guest-Grafikübersetzungstabelle. Eine Analyse der Zugriffsmuster auf die Guest-GTT zeigt, dass Guests-VMs Guest-GTT-Modifikationen (z. B. globale oder prozessbezogene GTT) in zusammenhängenden Blöcken vornehmen. In einer Ausführungsform kann, wenn das Zugriffsmuster eine Reihe von zusammenhängenden GTT-Modifikationen oder wiederholte Modifikationen an derselben GTT-Seite aufzeigt, der Mediator prüfen, ob die Guest-GTT oder zumindest ein Teil der Guest-GTT asynchron kopiert werden soll.
In einer Ausführungsform kann ein Mediator, wie bei 1402 dargestellt, konfiguriert sein, um Blöcke von GTT-Modifikationen in einer Anzahl und Häufigkeit über eine bestimmten Schwelle zu detektieren. Als Antwort auf die Detektion kann der Mediator in einen asynchronen Shadow-GTT-Betrieb übergehen.
Ein asynchroner Shadow-GTT-Betrieb kann bei Block 1404 beginnen, wenn der Mediator den Schreibschutz am Guest-GTT entfernt und es der GTT erlaubt, die Synchronisierung mit der Shadow-GTT zu verlassen. Für eine Zeitlang empfängt, wie bei Block 1406 dargestellt, die Guest-GTT Eintragungen von der Guest-VM. Wenn es der Zeitplan der Guest-vGPU vorsieht (z. B. ist der vGPU-Kontext auf die physische GPU geladen) und/oder ein neuer Stapel von Guest-vGPU-Befehlen bereit für die Zustellung an die GPU ist, wird die Shadow-GTT wiederhergestellt, wie bei 1408 dargestellt ist. Sobald die Shadow-GTT unter Verwendung der Guest-GTT rekonstruiert ist, können die Guest-VM-Befehle dem Grafikprozessor zugestellt werden, wie bei 1410 dargestellt ist.
15A–B sind Blockdiagramme einer Shadow-Grafikübersetzungstabelle-Rekonstruktion gemäß einer Ausführungsform. 15A zeigt eine vollständige Rekonstruktion 1506 einer Shadow-GTT. 15B zeigt eine teilweise Rekonstruktion 1516 einer Shadow-GTT.
Wie in 15A dargestellt ist, wird eine ganze beschreibbare Guest-GTT 1502 (z. B. globale GTT 1388 oder prozessbezogene GTT 1389 aus 13), der erlaubt wurde, die Synchronisierung mit der vorhandenen Shadow-GTT zu verlassen, verwendet, um eine vollständig rekonstruierte Shadow-GTT 1512 herzustellen. In einer Ausführungsform wird die vollständig rekonstruierte Shadow-GTT von Grund auf neu geschaffen, wenn der GPU neue Befehle zugestellt werden. Während der Rekonstruktion wird jeder Kachelverzeichniseintrag oder Kacheltabelleneintrag in der Guest-GTT überprüft, um sicherzustellen, dass er auf einen Speicher verweist, auf den die Guest-VM zugreifen darf.
Wie in 15B dargestellt ist, wird ein Teil einer beschreibbaren Guest-GTT 1504 (z. B. globale GTT 1388 oder prozessbezogene GTT 1389 aus 13) verwendet, um eine Hybrid-Shadow-GTT 1524 herzustellen, die eine teilweise Rekonstruktion 1516 verwendet, wobei ein Teil der Shadow-GTT-Kacheln mit einer Guest-GTT synchronisiert ist, ein anderer Teil der Shadow-GTT aber nicht. Die Wahl einer teilweisen Rekonstruktion oder vollständigen Rekonstruktion kann heuristisch basierend auf der Anzahl von GTT-Kacheln erfolgen, die der Guest zu einem gegebenen Zeitpunkt modifiziert. Wenn beispielsweise die Anzahl an modifizierten Kacheln der Guest-GTT 1504 unter einer Schwelle liegt, kann eine teilweise Rekonstruktion durchgeführt werden, bei der die schmutzigen Bits (z. B. modifizierte Statusindikatorbits) der Kacheltabelleneinträge oder Kachelverzeichniseinträge der Guest-GTT 1504 verwendet werden können, um zu bestimmen, welche Speicherfensternummern von der Guest-VM modifiziert wurden, und nur die Shadow-GTT-Kacheln werden synchronisiert, die modifizierten Guest-GTT-Kacheln entsprechen. Die teilweise rekonstruierte Shadow-GTT 1524 kann durch Kopieren oder Wiederverwenden der vorhandenen Shadow-GTT als Basis und Aktualisieren nur jener Einträge hergestellt werden, die nicht mit der Guest-GTT synchronisiert sind.
Bestimmen der modifizierten Guest-Kacheln kann zusätzlich zur Verwendung der schmutzigen Bits der Guest-Kacheln unter Verwendung von verschiedenen Techniken erfolgen. In einer Ausführungsform werden die modifizierten GTT-Kacheln über die Guest-Standardadresse aus einem Guest-VM-Zugriff auf eine schreibgeschützte Guest-GTT-Kachel bestimmt. In einer Ausführungsform kann der VMM eine separate Datenstruktur verwenden (z. B. Linktabelle, Hashtabelle, lineare Anordnung), um die Liste von Guest-Kacheln in der Guest-GTT zu verfolgen, die asynchron bezüglich der Shadow-GTT sein dürfen, und die Datenstruktur verwenden, um zu bestimmen, welche der modifizierten Guest-GTT-Kacheln mit entsprechenden Shadow-GTT-Kacheln synchronisiert werden sollen, und/oder sie kann zusätzlich „schmutzige” Bits verwenden, um die Liste von zu synchronisierenden Kacheln einzugrenzen.
In einer weiteren Ausführungsform kann, wenn die Anzahl an Guest-GTT-Kacheln, die asynchron mit der Shadow-GTT sein dürfen, sehr groß ist und Guest-GTT-Kacheln nicht immer zu dem Zeitpunkt modifiziert werden, zu dem die Shadow-GTT rekonstruiert wird, der schmutzige Bit einer Kacheltabelle einer höheren Ebene verwendet werden, um den Prozess des Identifizierens jener GTT-Kacheln weiter einzuengen, die während der Rekonstruktion der Shadow-GTT aktualisiert werden sollen. Wie dargestellt weisen GPN_1 1505a und GPN_n – 1 1505b jeweils eine kachelstabile Schmutzig-Markierung auf, die für den Kacheltabellen- oder Kachelverzeichniseintrag der beschreibbaren GTT 1504 gesetzt ist. Somit kann die beispielhafte teilweise rekonstruierte Shadow-GTT 1524 durch Aktualisieren der vorhandenen Shadow-GTT mit den Speicherfenster- oder Kacheltabellendaten geschaffen werden, die in den schmutzigen Kacheltabelleneinträgen 1505a–b enthalten sind.
16 ist ein Flussidagramm einer Logik zur Rekonstruktion zumindest eines Teils einer Shadow-Grafikübersetzungstabelle. In einer Ausführungsform bestimmt, wie bei 1602 dargestellt, ein virtueller GPU-Mediator (z. B. Mediator 1212 aus 12) einen Rekonstruktionsmodus für eine GTT oder einen Teil der GTT. In einer Ausführungsform kann die Shadow-GTT für den Teil der GTT, der vom asynchronen Modus verwaltet wird, eine teilweise oder vollständige Rekonstruktion aufbauen, wie bei 1604 bestimmt wird. In einer Ausführungsform wird die Shadow-GTT rekonstruiert, wenn die Befehle der Guest-vGPU der physischen GPU zugestellt werden. Wenn die GTT nicht teilweise rekonstruiert wird, kann der Mediator bei 1606 die gesamte Shadow-GTT für eine Rekonstruktion auswählen. Ansonsten kann, wenn eine teilweise Rekonstruktion bei 1604 eingeschaltet wird, der Mediator bestimmte GTT-Kacheln basierend auf der Datenstruktur, die in 00132 erwähnt wurde, bei 1607 für eine Rekonstruktion auswählen.
Bei 1608 bestimmt der Mediator, ob alle der ausgewählten Kacheln, welche die Synchronisierung verlassen haben, rekonstruiert werden sollen (z. B. die gesamte Shadow-GTT, wenn vollständige Rekonstruktion eingeschaltet ist, oder alle ausgewählten GTT-Kacheln, wenn teilweise Rekonstruktion eingeschaltet ist). Wenn nur schmutzige Kacheln rekonstruiert werden sollen, kann der Mediator bei 1609 die vorhandenen ausgewählten Shadow-GTT-Kacheln kopieren oder wiederverwenden, und bei Block 1611 kann er eine Unterauswahl der ausgewählten GTT-Kacheln basierend auf den schmutzigen Bits in den Kacheltabellen- oder Kachelverzeichniseinträgen der Guest-GTT erstellen. Wenn die Shadow-GTT vollständig rekonstruiert werden soll, wird bei 1610 eine neue Shadow-GTT geschaffen.
Bei 1612 wird die neue oder vorhandene Shadow-GTT unter Verwendung des ausgewählten oder subausgewählten Teils der Shadow-GTT, was die gesamte GTT, die zuvor ausgewählten spezifischen GTT-Kacheln oder die Shadow-GTT-Einträge in Verbindung mit dem subausgewählten Teil der Guest-GTT basierend auf den schmutzigen Guest-GTT-Bits umfassen kann, rekonstruiert. In einer Ausführungsform werden die schmutzigen Guest-Bits gegebenenfalls nach einer Rekonstruktion gelöscht, wie bei 1614 dargestellt ist.
17A–B sind Flussidagramme, die eine beispielhafte Logik zur Überleitung aus dem asynchronen Betriebsmodus einer GTT und für die Überleitung einer Untergruppe der GTT in einen synchronen Betrieb zeigen. In einer Ausführungsform kann, nachdem die in 14 dargestellten Operationen ausgeführt wurden, einschließlich der Weiterleitung von Befehlen an den Grafikprozessor sobald die relevante(n) Shadow-GTT(s) synchron sind, der Mediator über das vGPU-VMM-Modul (z. B. Mediator 1312 und vGPU-VMM-Modul 1324 aus 13) bestimmen, dass er aus dem asynchronen Betrieb aussteigen und in den synchronen Betrieb zwischen Guest- und Shadow-GTT zurückkehren soll. Die Operationen sind zwar sequenziell dargestellt, in manchen Ausführungsformen können die dargestellten Operationen aber auch zumindest teilweise parallel ausgeführt werden. Beispielsweise können mehrere unabhängige Bestimmungen und Evaluierungen gleichzeitig durchgeführt werden. Außerdem können mehrere Teile einer globalen oder prozessbezogenen Guest-GTT in verschiedenen Betriebsmodi verwaltet werden, sodass ein Teil einer GTT synchron verwaltet werden kann, während ein anderer Teil der GTT asynchron verwaltet wird. Darüber hinaus kann eine globale GTT synchron verwaltet werden, während zumindest ein Teil einer prozessbezogenen GTT asynchron in Bezug auf die zugeordneten prozessbezogenen Shadow-GTT-Kacheln laufen kann, bis der GPU Befehle zugestellt werden.
17A ist ein Flussidagramm, das eine Logik zur Überleitung von zumindest einem Teil einer GTT in einen synchronen Betrieb gemäß einer Ausführungsform umfasst. 17B ist ein Flussidagramm, das eine Logik zur Auswahl und zur Überleitung eines Satzes von GTT-Kacheln in einen synchronen Betrieb gemäß einer Ausführungsform umfasst.
In einer Ausführungsform bestimmt, wenn eine Überleitung in einen synchronen Betrieb beginnt, wie bei 1730 in 17A dargestellt ist, der Mediator bei 1732, ob eine vollständige Überleitung der GTT stattfinden soll. Wenn die gesamte globale oder prozessbezogene GTT in einen synchronen Modus übergehen soll, kann der Mediator bei 1740 die gesamte GTT in einen synchronen Modus versetzen. In einer Ausführungsform löst die vollständige Überleitung bei 1738 eine vollständige Rekonstruktion der zugeordneten Shadow-GTT aus, wenn die Überleitung in den synchronen Betrieb abgeschlossen ist.
In einer Ausführungsform kann eine Überleitung in einen synchronen Modus für weniger als die ganze GTT ausgeführt werden. Wenn beispielsweise der Mediator bei 1734 bestimmt, dass die Überleitung in einen synchronen Betrieb ausgelöst wurde, weil die Anzahl an asynchronen GTT-Kacheln eine Kachelanzahlschwelle überschritten hat, kann der Mediator bei 1742a bestimmte GTT-Kacheln für eine Überleitung auswählen. Alternativ dazu kann, wie bei 1736 dargestellt, aus verschiedenen Gründen eine spontane Kachelauswahl von der Mediatorlogik ausgeführt werden. Beispielsweise wird in einer Ausführungsform das Alter der asynchronen GTT-Kacheln überwacht, um zu bestimmen, ob das Alter der Kacheln eine bestimmte Schwelle überschreitet. Wenn eine bestimmte Anzahl an Kacheln die Altersschwelle überschreitet, kann die Mediatorlogik bei 1736 alle oder einige der älteren Kacheln für eine Überleitung in einen synchronen Betrieb bei 1742a auswählen.
Die Auswahl von GTT-Kacheln bei 1742a kann basierend auf einer vorbestimmten Strategie oder basierend auf einer dynamischen Strategie erfolgen, die während des Laufens modifiziert werden kann. Eine beispielhafte Logik für die Auswahl und Überleitung einzelner GTT-Kacheln bei 1742a ist in 17B dargestellt. Bei 1744 werden jegliche gecachte Versionen der GTT-Kacheln in der Hardware gespült, und diese Kacheln werden in einen synchronen Betrieb versetzt. Dann kann der Mediator die Überleitung in den synchronen Betrieb bei 1738 abschließen. In einer Ausführungsform löst die Überleitung einer Untergruppe von GTT-Kacheln eine teilweise Rekonstruktion der zugeordneten Shadow-GTT aus.
Die Auswahl von GTT-Kacheln bei 1742a in 17A beginnt in einer Ausführungsform bei 1742b von 17B. Eine Logik für die Auswahl und Überleitung einzelner GTT-Kacheln umfasst Initialisieren eines Kachelzeigers bei 1750. Der Kachelzeiger kann eine Register- oder Speicheradresse sein, die zum Anfang einer mit NULL terminierten Liste von asynchronen GTT-Kacheln initialisiert wird, die vom Mediator geführt wird. Bei 1754 kann eine anfängliche NULL-Prüfung durchgeführt werden bevor die Liste durchgegangen wird, wobei eine NULL-Liste den Mediator veranlasst, bei 1764 Vollständigkeit der Liste zu signalisieren. Wenn die Liste nicht NULL ist, kann der Mediator bei 1756 für jedes Element der Liste eine Kachel in der Liste von asynchronen GTT-Kacheln auswählen und bei 1758 bestimmen, ob die Kachel ein Kandidat für den Austritt aus dem asynchronen Modus ist. In einer Ausführungsform erfolgt die Bestimmung bei 1758 durch eine Analyse von Metadaten für die GTT-Kachel, um eine Zugriffshäufigkeit auf die Kachel oder die Dauer, für welche die Kachel sich im asynchronen Modus befunden hat, oder die Anzahl an VM-Zeitplanzyklen seit die Kachel zum letzten Mal modifiziert wurde zu bestimmen. In einer Ausführungsform kann, wenn auf die Kachel häufig oder kürzlich zugegriffen wurde, der Mediator bei 1760 bestimmen, dass die Kachel kein Austrittskandidat ist. Der Mediator kann dann bei 1763 die nächste Kachel in der Liste auswählen. Alternativ dazu kann, wenn die Kachel ein Austrittskandidat ist, der Mediator bei 1760 die ausgewählte Kachel aus dem asynchronen Modus nehmen und die Kachel bei 1762 aus der Liste von asynchronen Kacheln entfernen, bevor bei 1763 die nächste Kachel in der Liste ausgewählt wird. In einer Ausführungsform ist, wenn die Liste vollständig abgearbeitet ist, die nächste bei 1763 ausgewählte Kachel in der Liste NULL. Somit führt die Bestimmung von NULL in der Liste bei 1754 dazu, dass der Mediator bei 1764 Vollständigkeit der Liste signalisiert. Dann kann der Mediator bei 1738 in 17A die Überleitung in einen synchronen Betrieb für die ausgewählte GTT abschließen.
18 ist ein Blockdiagramm, das eine Hybridsynchronisierung gemäß einer Ausführungsform veranschaulicht. In einer Ausführungsform verwaltet ein Guest-VM-Mediator unter Verwendung von Hybridsynchronisierung einen Teil einer GTT unter Einsatz des synchronen Modus, und ein anderer Teil der GTT wird unter Einsatz des asynchronen Modus verwaltet. Wie dargestellt verwendet eine Ausführungsform eine gemeinsame Shadow-GTT 1830, die Shadow-Einträge für mehrere Guest-GTTs enthält. Es ist zwar eine gemeinsame Shadow-GTT 1830 dargestellt, in einer anderen Ausführungsform kann aber auch eine VM-bezogene Shadow-GTT verwendet werden, die ähnlich ist wie die gemeinsame Shadow-GTT 1830.
In einer Ausführungsform umfasst eine erste VM-Guest-GTT 1801 einen Satz von Guest-Kachelnummern, einschließlich GPN(A) 1803, die kontinuierlich mit einem zugeordneten Satz von Host-Kachelnummern, einschließlich HPN(A) 1833, synchronisiert werden, sodass GPN(A) 1803 und HPN(A) 1833 kontinuierlich auf das gleiche Speicherfenster (z. B. Speicherfenster (A) 1823) im Systemspeicher 1820 zeigen. In einer Ausführungsform umfasst die gemeinsame Shadow-GTT 1830 auch einen Satz von Host-Kachelnummern, einschließlich HPN(B) 1834, die nicht mit ihren zugeordneten Guest-Kachelnummern, einer zweiten VM-Guest-GTT 1802 (einschließlich GPN(B) 1804), synchronisiert werden (z. B. asynchron sind). Demgemäß zeigen in einer Ausführungsform HPN(B) 1834 und GPN(B) 1804 nicht auf dasselbe Speicherfenster (z. B. Speicherfenster (B) 1824) im Systemspeicher 1820, bis die Befehle der Guest-VM (z. B. vGPU-Bildsynthesemaschine der Guest-VM) an die GPU weitergeleitet werden.
19 ist ein Flussidagramm einer Logik zur Ausführung von Hybridsynchronisierung gemäß einer Ausführungsform. In einer Ausführungsform konfiguriert der Guest-VM-Mediator bei 1902 einen synchronen Betrieb für eine globale oder prozessbezogene Guest-GTT. Während des synchronen Betriebs emuliert der Mediator Guest-Eintragungen in die GTT, wie bei 1904 dargestellt ist. In einer Ausführungsform verwendet der Mediator ein Abfangen-und-Emulier-Modell zum Emulieren von Guest-GTT-Eintragungen. Wenn die Hybridsynchronisierungslogik konfiguriert ist, bei 1906 Guest-GTT-Eintragungsschutzfehler selektiv abzufangen, emuliert der Mediator in einer Ausführungsform die Guest-GTT-Eintragungen (für jene GTT-Kacheln im synchronen Modus) während des Abfangens der Schreibschutzfehlerursachen aufgrund der Guest-Eintragung in die GTT. In einer Ausführungsform kann der Mediator in einem Host-OS in einem Typ-eins-VMM laufen und mit einem Host-Grafiktreiber zusammenarbeiten. Die Host-OS-Eintragung einer GTT wird als Guest-Eintragung einer GTT angesehen (wie z. B. die Dienst-VM in einem Typ-zwei-VMM), und der Mediator fängt GTT-Eintragungsfehler des Host-Grafiktreibers nicht ab. Stattdessen wird, wie bei 1909 dargestellt, in einer Ausführungsform ein Treiber, der auf die GTT zugreift, vom Mediator festgehakt, der einen Grafiktreiber verwendet, um den Mediator anzurufen, GTT-Eintragungen für das Host-OS vorzunehmen (was nachfolgend als Guest-GTT-Eintragung gesehen wird). In einer Ausführungsform basiert die Falle-versus-Haken-Konfiguration auf dem Hypervisor, der zur Virtualisierung der GTT verwendet wird, wobei die Guest-GTT-Eintragungen bei 1908 abgefangen werden, wenn ein Typ-eins-Hypervisor in Verwendung ist, und die Mediator-Haken bei 1909 verwendet werden, wenn ein Typ-zwei-Hypervisor verwendet wird.
Unabhängig vom Mechanismus, mit dem Guest-GTT-Eintragungen emuliert werden, wenn der Mediator bei 1910 häufige Guest-GTT-Modifikationen an einem Teil der Guest-GTT detektiert, kann der Mediator bei 1912 einen asynchronen Betrieb für den Teil der Guest-GTT konfigurieren, was es dem Guest erlaubt, ohne Mediatoremulierung in die Guest-GTT zu schreiben. In einer Ausführungsform umfasst, wie bei 1914 dargestellt, die Synchronisierungslogik Register, Pufferspeicher oder Datenstrukturen im Systemspeicher, um den Teil der Guest-GTT nachzuverfolgen, der nicht schreibgeschützt ist oder auf andere Weise asynchron in Bezug auf die Shadow-GTT läuft. Wie bei 1916 dargestellt rekonstruiert die Synchronisierungslogik den relevanten Teil der Shadow-GTT basierend auf dem nachverfolgten Teil der Guest-GTT, der asynchron in Bezug auf die Shadow-GTT ist, bevor Befehle zur GPU-Hardware weitergeleitet werden.
In einer Ausführungsform kann es dem zumindest einen Teil der Guest-GTT erlaubt sein, nicht synchron mit dem zugeordneten Teil der Shadow-GTT zu sein, bis Hardware-Befehle übermitteln werden. Die GTT sollte jedoch passend synchronisiert werden, bevor Befehle an Hardware übermittelt werden, ansonsten kann die Ausführung der GPU-Befehle fehlschlagen. Wenn die GPU-Hardware konfiguriert ist, die GTT-Kacheln zu cachen, dann kann die GPU-Hardware die relevanten GTT-Kacheln in Hardware cachen, während Grafikbefehle ausgeführt werden.
In einer Ausführungsform, die in 15 und 16 dargestellt ist, werden die modifizierten Statusindikatorbits (z. B. schmutzige Bits) des asynchronen Teils der Guest-GTT verwendet, um die veränderten Elemente des asynchronen Teils der Guest-GTT zu bestimmen. In einer solchen Ausführungsform werden nur jene Guest-GTT-Elemente, die sich tatsächlich verändert haben, zur Rekonstruktion des Teils der Shadow-GTT verwendet, sodass die vorhandene Shadow-GTT als Basis für die Konstruktion einer neuen Shadow-GTT verwendet werden kann.
Verschiedene Ausführungsformen können unter Einsatz von Hardwareelementen, Softwareelementen oder einer Kombination von beidem implementiert werden. Beispiele für Hardwareelemente können Prozessoren, Mikroprozessoren, Schaltungen, Schaltungselemente (z. B. Transistoren, Widerstände, Kondensatoren, Induktoren usw.), integrierte Schaltungen, anwendungsspezifische integrierte Schaltungen (ASIC), programmierbare Logikvorrichtungen (PLD), digitale Signalprozessoren (DSP), feldprogrammierbare Gatter-Anordnungen (FPGA), Logikgatter, Register, Halbleitervorrichtungen, Chips, Mikrochips, Chipsätze usw. umfassen. Beispiele für Software können Softwarekomponenten, Programme, Anwendungen, Computerprogramme, Anwendungsprogramme, Systemprogramme, Maschinenprogramme, Betriebssystemsoftware, Middleware, Firmware, Softwaremodule, Routinen, Subroutinen, Funktionen, Verfahren, Prozesse, Softwareschnittstellen, Anwendungsprogrammierschnittstellen (API), Befehlssätze, Rechenkodes, Computerkodes, Kodesegmente, Computerkodesegmente, Wörter, Werte, Symbole oder eine beliebige Kombination davon umfassen. Bestimmen, ob eine Ausführungsform unter Verwendung von Hardwareelementen und/oder Softwareelementen implementiert wird, kann in Abhängigkeit von verschiedenen Faktoren variieren, wie beispielsweise Rechengeschwindigkeit, Leistungsniveaus, Wärmebeständigkeit, Verarbeitungszyklusbudget, Eingabedatengeschwindigkeiten, Ausgabedatengeschwindigkeiten, Speicherressourcen, Datenbusgeschwindigkeiten und anderen Design- oder Leistungseinschränkungen.
Ein oder mehrere Aspekte von zumindest einer Ausführungsform können durch repräsentative Anweisungen implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das unterschiedliche Logik im Prozessor dargestellt, die bei Lesen durch eine Maschine die Maschine veranlasst, Logik zu erstellen, um die hierin beschriebenen Techniken auszuführen. Solche Repräsentationen, die als „IP-Kerne” bekannt sind, können auf einem physischen maschinenlesbaren Medium gespeichert sein und verschiedenen Kunden oder Produktionseinrichtungen bereitgestellt werden, um auf die Produktionsgeräte geladen zu werden, die dann tatsächlich die Logik oder den Prozessor produzieren.
Ausführungsformen können mit allen Arten von integrierten Halbleiterschaltungs-(„IC-”)Chips verwendet werden. Beispiele für diese IC-Chips umfassen, sind jedoch nicht eingeschränkt auf, Prozessoren, Steuerungen, Chipsetkomponenten, programmierbare Logikanordnungen (PLAs), Speicherchips, Netzwerkchips und dergleichen. Außerdem sind in einigen der Zeichnungen Signalleitungen durch Linien dargestellt. Einige können unterschiedlich sein, um stärker konstituierende Signalpfade darzustellen, eine Zahlmarkierung aufweisen, um eine Anzahl von konstituierenden Signalpfaden anzugeben, und/oder Pfeile an einem oder mehreren Enden aufwiesen, um die primäre Informationsflussrichtung anzuzeigen. Dies ist jedoch nicht auf einschränkende Weise zu verstehen. Solche hinzugefügten Details können vielmehr in Verbindung mit einer oder mehreren beispielhaften Ausführungsformen herangezogen werden, um ein besseres Verständnis einer Schaltung bereitzustellen. Alle dargestellten Signalleitungen, mit oder ohne Zusatzinformationen, können in der Tat ein oder mehrere Signale umfassen, die in mehrere Richtungen wandern können, und können mit einem beliebigen Typ von Signalschema implementiert sein, z. B. digitale oder analoge Leitungen, die mit unterschiedlichen Paaren, Faseroptikleitungen und/oder einendigen Leitungen implementiert sind.
Beispiele für Größen/Modelle/Werte/Bereiche können angeführt sein, aber Ausführungsformen sind nicht auf diese beschränkt. Da sich Herstellungstechniken (z. B. Photolithographie) im Laufe der Zeit weiterentwickeln, ist zu erwarten, dass in Zukunft Vorrichtungen mit geringerer Größe hergestellt werden. Außerdem sind eventuell allgemein bekannte Strom-/Masseverbindungen für IC-Chips und andere Komponenten in den Figuren der einfacheren Darstellung und Erläuterung halber nicht dargestellt, um bestimmte Aspekte der Ausführungsformen nicht zu verschleiern. Ferner können Anordnungen in Blockdiagrammen dargestellt sein, um eine Verschleierung von Ausführungsformen zu vermeiden, und manche Spezifika in Bezug auf die Implementierung von solchen Blockdiagrammanordnungen hängen stark von der Plattform ab, in welcher die Ausführungsform implementiert werden soll, d. h. solche Spezifika sind Fachleuten auf dem Gebiet der Erfindung geläufig. Sind spezifische Details (z. B. Schaltungen) dargelegt, um beispielhafte Ausführungsformen zu beschreiben, sollte für Fachleute auf dem Gebiet der Erfindung offensichtlich sein, dass Ausführungsformen ohne diese oder mit Variationen dieser spezifischen Details umgesetzt werden können. Die Beschreibung ist daher als veranschaulichend und nicht als einschränkend zu sehen. Darüber hinaus können Aspekte, die in Verbindung mit einer Ausführungsform beschrieben sind, mit anderen, hierin beschriebenen Ausführungsformen kombiniert werden.
Einige Ausführungsformen können beispielsweise unter Verwendung einer Maschine oder eines physischen, computerlesbaren Mediums oder Artikels umgesetzt werden, die eine Anweisung oder einen Satz von Anweisungen speichern können, die bei Ausführung durch eine Maschine die Maschine veranlassen können, ein Verfahren und/oder Operationen gemäß den Ausführungsformen auszuführen. Solch eine Maschine kann beispielsweise eine beliebige geeignete Verarbeitungsplattform, Rechenplattform, Rechenvorrichtung, Verarbeitungsvorrichtung, ein Rechensystem, Verarbeitungssystem, einen Computer, Prozessor oder dergleichen umfassen und kann unter Verwendung einer beliebigen geeigneten Kombination von Hardware und/oder Software implementiert werden.
Sofern nicht spezifisch anders angegeben ist, sei darauf hingewiesen, dass sich Bezeichnungen wie „Verarbeitung”, „rechnen”, „Berechnung”, „bestimmen” oder dergleichen auf die Aktion und/oder auf Prozesse eines Computers oder Rechensystems oder einer ähnlichen elektronischen Rechenvorrichtung beziehen, die Daten, die als physikalische Mengen (z. B. elektronisch) in den Registern und/oder Speichern in Registern des Rechensystems dargestellt sind, manipuliert und/oder in andere Daten transformiert, die auf ähnliche Weise als physikalische Mengen innerhalb der Speicher, Register oder anderen Informationsspeicher-, Übertragungs- oder Anzeigevorrichtungen im Rechensystem dargestellt sind. Die Ausführungsformen sind in diesem Zusammenhang nicht eingeschränkt.
Die Bezeichnung „gekoppelt” kann hierin verwendet werden, um eine beliebige Art von Beziehung, direkt oder indirekt, zwischen den betreffenden Komponenten zu bezeichnen und kann sich auf elektrische, mechanische, Fluid-, optische, elektromagnetische, elektromechanische oder anderen Verbindungen beziehen. Außerdem werden die Bezeichnungen „erster”, „zweiter” usw. hierin eventuell nur zur einfacheren Erläuterung verwenden und besitzen keine bestimmte zeitliche oder chronologische Bedeutung, sofern nicht anders angegeben ist.
Wie in dieser Anmeldung und den Ansprüchen verwendet kann eine Liste von Elementen, die durch die Bezeichnung „eines oder mehrere” verbunden ist, eine beliebige Kombination der aufgelisteten Elemente bezeichnen. Beispielsweise kann die Phrase „eines oder mehrere von A, B oder C” für A; B; C; A und B; A und C; B und C; oder A, B und C stehen.
Es versteht sich, dass mehrere Typen von Hypervisoren hierein beschrieben sind, einschließlich ,Host-' (z. B. Typ-zwei-) oder ,nackte-Maschine-' (z. B. Typ-eins-)Hypervisoren. Die beschriebenen Techniken sind nicht auf einen bestimmten Typ, eine bestimmte Form oder ein bestimmtes Modell von Hypervisoren beschränkt und können für virtuelle GPUs verwendet werden, die durch Typ-eins-, Typ-zwei- oder eine beliebige andere Art von Hybridhypervisoren laufen.
Hierin beschriebene Ausführungsformen betreffen Systeme, Methoden und ein Gerät zur Verwaltung von virtuellen Maschinen. In einer Ausführungsform umfasst das Gerät einen Grafikprozessor, der mit einem Monitor für virtuelle Maschinen (VMM) gekoppelt ist, um einer ersten virtuellen Maschine einen virtuellen Grafikprozessor zu präsentieren, und mit einem Mediator für den virtuellen Grafikprozessor, um Modifikationen in einer Guest-Grafikübersetzungstabelle (GTT) einer ersten virtuellen Maschine synchron in eine Shadow-GTT des VMM zu kopieren. Der Mediator kann auch konfiguriert sein, um zu detektieren, wenn eine Modifikationshäufigkeit der ersten Guest-GTT eine Schwelle überschreitet, und als Antwort auf die Detektion kann er zumindest einen Teil der ersten Guest-GTT asynchron in der Shadow-GTT kopieren. Der Mediator kann zwar in einer Ausführungsform konfiguriert sein, eine Modifikationshäufigkeit über einer Schwelle zu detektieren, der Mediator kann aber auch konfiguriert sein, eine Anzahl von zusammenhängenden Modifikationen über einer Schwelle oder eine Anzahl von wiederholten Modifikationen im selben Bereich der GTT zu detektieren.
Ein oder mehrere Aspekte von zumindest einer Ausführungsform können durch repräsentative Anweisungen implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das unterschiedliche Logik im Prozessor darstellt, die bei Lesen durch eine Maschine die Maschine veranlasst, Logik zu erstellen, um die hierin beschriebenen Techniken auszuführen. Solche Repräsentationen, die als „IP-Kerne” bekannt sind, können auf einem physischen maschinenlesbaren Medium („Band”) gespeichert sein und verschiedenen Kunden oder Produktionseinrichtungen bereitgestellt werden, um auf die Produktionsgeräte geladen zu werden, die dann tatsächlich die Logik oder den Prozessor produzieren. Beispielsweise könne IP-Kerne, wie z. B. die Mali^TM-Familie von Grafiklösungen, die von ARM Holdings, Ltd. Entwickelt wurde, und Loongson-IP-Kerne, die vom Institut für Computertechnologie (ICT) der chinesischen Wissenschaftsakademie entwickelt wurden, lizenziert und an verschiedene Kunden oder Lizenznehmer, wie z. B. Texas Instruments, Qualcomm, Apple oder Samsung, verkauft und in Prozessoren, die von diesen Kunden oder Lizenznehmern produziert werden, implementiert werden.
Die Entwicklung solcher IP-Kodes umfasst die Verwendung von Simulationssoftware oder -hardware, die zur Modellierung spezifischer Ausführungsformen von hierin beschriebener GPU-Hardware verwendet werden können. Daten, die das Design des IP-Kerns darstellen, können einer Produktionseinrichtung zur Verfügung gestellt werden, wo die Produktion von einer dritten Partei durchgeführt werden kann, um die mit den beschriebenen Ausführungsformen assoziierte Funktionalität bereitzustellen.
Fachleute auf dem Gebiet der Erfindung werden aus der vorangegangenen Beschreibung entnehmen, dass die allgemeinen Techniken der Ausführungsformen in verschiedensten Formen implementiert werden können. Obwohl also die Ausführungsformen in Verbindung mit bestimmten Beispielen davon beschrieben wurden, ist der wahre Schutzumfang der Ausführungsformen nicht dadurch eingeschränkt, da sich für Fachleute auf dem Gebiet der Erfindung nach Einsicht in die Zeichnungen, Beschreibung und nachstehenden Ansprüche andere Modifikationen ergeben werden.

Claims

Gerät zur Verwaltung von virtuellen Maschinen, wobei das Gerät umfasst: einen Grafikprozessor, der mit einem Monitor für virtuelle Maschinen (VMM) gekoppelt ist, um einer ersten virtuellen Maschine einen virtuellen Grafikprozessor zu präsentieren; und einen Mediator für den virtuellen Grafikprozessor, um Modifikationen einer ersten Grafikübersetzungstabelle (GTT) der ersten virtuellen Maschine synchron in eine Shadow-GTT der VMM zu kopieren, wobei der Mediator ferner dazu dient, zu detektieren, dass eine Modifikationshäufigkeit der ersten GTT eine Schwelle überschritten hat und als Antwort auf die Detektion zumindest einen Teil der ersten GTT asynchron in die Shadow-GTT kopiert.
Gerät nach Anspruch 1, wobei der Mediator ferner dazu dient, zumindest den Teil der ersten GTT asynchron zu kopieren, bevor Befehle für den virtuellen Grafikprozessor von der ersten virtuellen Maschine zum Grafikprozessor zugestellt werden.
Gerät nach Anspruch 1, wobei die erste GTT dazu dient, eine erste Grafikspeicheradresse für den virtuellen Grafikprozessor in eine Systemspeicheradresse zu übersetzen.
Gerät nach Anspruch 1, wobei die Shadow-GTT in der VMM dazu dient, eine Host-Grafikspeicheradresse in eine Systemspeicheradresse zu übersetzen.
Gerät nach Anspruch 1, wobei die erste virtuelle Maschine dazu dient, den virtuellen Grafikprozessor unter Verwendung von nativer Grafiktreibersoftware zu verwalten.
Gerät nach Anspruch 1, wobei der Mediator ein Vorrichtungsmodell für den virtuellen Grafikprozessor umfasst.
Gerät nach Anspruch 1, wobei die erste GTT eine globale GTT und eine prozessbezogene GTT umfasst.
Gerät nach Anspruch 7, wobei die prozessbezogene GTT eine Kachelverzeichnistabelle und eine Kacheltabelle umfasst.
Gerät nach einem der Ansprüche 1–8, wobei die VMM ferner dazu dient, einer zweiten virtuellen Maschine einen zweiten virtuellen Grafikprozessor zu präsentieren.
Gerät nach Anspruch 9, wobei der Mediator ferner dazu dient, Modifikationen einer zweiten Grafikübersetzungstabelle (GTT) einer zweiten virtuellen Maschine synchron in die Shadow-GTT der VMM zu kopieren.
Gerät nach Anspruch 10, wobei der Mediator ferner dazu dient, zu detektieren, ob die die Häufigkeit von Modifikationen der zweiten GTT eine Schwelle überschreitet und als Antwort auf die Detektion die zweite GTT asynchron in die Shadow-GTT zu kopieren, bevor Befehle für den virtuellen Grafikprozessor von der zweiten virtuellen Maschine zum Grafikprozessor zugestellt werden.
Verfahren zum Verwalten von virtuellen Maschinen, wobei das Verfahren umfasst: synchrones Kopieren einer ersten Grafikübersetzungstabelle (GTT) einer ersten virtuellen Maschine in eine Shadow-GTT eines Monitors für virtuelle Maschinen (VMM), Detektieren, dass eine Anzahl von Modifikationen zumindest eines ersten Teils von zusammenhängenden GTT-Einträgen der ersten GTT eine Schwelle überschritten hat; Konfigurieren eines asynchronen Betriebs für zumindest den ersten Teil der ersten GTT, wobei Konfigurieren Rekonstruieren zumindest eines Teils der Shadow-GTT umfasst, der dem ersten Teil der ersten GTT zugeordnet ist, bevor Grafikbefehle von der ersten virtuellen Maschine zugestellt werden.
Verfahren nach Anspruch 12, wobei synchrones Kopieren der ersten GTT in die Shadow-GTT Abfangen und Emulieren jeder Eintragung in die erste GTT durch die erste virtuelle Maschine umfasst.
Verfahren nach Anspruch 13, wobei Abfangen und Emulieren jeder Eintragung in die erste GTT Empfangen einer Schreibschutzfalle als Antwort auf einen Versuch, die erste GTT zu modifizieren, Modifizieren der ersten GTT und Kopieren der Modifikation in die Shadow-GTT umfasst.
Verfahren nach einem der Ansprüche 12–14, wobei Konfigurieren eines asynchronen Betriebs für zumindest den ersten Teil der ersten GTT Entfernen eines Schreibschutzes von zumindest dem ersten Teil der ersten GTT umfasst.
System zum Verwalten von virtuellen Maschinen, das System umfassend: einen oder mehrere Prozessoren, die mit einer Coprozessorvorrichtung gekoppelt sind; einen Monitor für virtuelle Maschinen (VMM), um einer virtuellen Maschine einen virtuellen Coprozessor zu präsentieren; und ein Mediatormodul, um den einen oder die mehreren Prozessoren zu veranlassen: zu detektieren, wenn eine Modifikationshäufigkeit einer Speicherübersetzungstabelle der virtuellen Maschine eine Schwelle überschritten hat, wobei die Speicherübersetzungstabelle vor Modifikation durch die virtuelle Maschine geschützt ist und Modifikation der Speicherübersetzungstabelle Emulation der Modifikation der Übersetzungstabelle umfasst; den Schutz von zumindest einem Teil der Speicherübersetzungstabelle zu entfernen, um eine Modifikation der Speicherübersetzungstabelle ohne Emulation zuzulassen; eine Shadow-Übersetzungstabelle basierend auf der modifizierten Speicherübersetzungstabelle zu konstruieren, bevor Befehle für den virtuellen Coprozessor zur Coprozessorvorrichtung zugestellt werden.
System nach Anspruch 16, wobei das Mediatormodul den einen oder die mehreren Prozessoren veranlasst: zu bestimmen, ob für den virtuellen Coprozessor geplant ist, Befehle zur Coprozessorvorrichtung zuzustellen; und Befehle für den virtuellen Coprozessor zuzustellen, sobald die Shadow-Übersetzungstabelle konstruiert ist.
System nach Anspruch 17, wobei die Übersetzungstabelle eine Grafikübersetzungstabelle (GTT) ist und der virtuelle Coprozessor ein virtueller Grafikprozessor ist.
System nach Anspruch 18, wobei die GTT eine Guest-GTT für den virtuellen Grafikprozessor ist.
System nach Anspruch 19, wobei das Mediatormodul ferner den einen oder die mehreren Prozessoren veranlasst, eine erste Modifikation eines geschützten Teils der Guest-GTT synchron zu emulieren, die erste Modifikation der Shadow-Übersetzungstabelle synchron zu spiegeln und eine zweite Modifikation eines ungeschützten Teils der Guest-GTT asynchron in der Shadow-Übersetzungstabelle zu spiegeln, während die Shadow-Übersetzungstabelle konstruiert wird.
System nach Anspruch 19, wobei das Mediatormodul ferner den einen oder die mehreren Prozessoren veranlasst, die zweite Modifikation der Shadow-Übersetzungstabelle während einer vollständigen Rekonstruktion der Shadow-Übersetzungstabelle zu spiegeln.
System nach Anspruch 19, wobei das Mediatormodul ferner den einen oder die mehreren Prozessoren veranlasst, die zweite Modifikation der Shadow-Übersetzungstabelle während einer teilweisen Rekonstruktion der Shadow-Übersetzungstabelle zu spiegeln.
System nach Anspruch 19, wobei das Mediatormodul ferner den einen oder die mehreren Prozessoren veranlasst, die Shadow-Übersetzungstabelle teilweise zu rekonstruieren, indem weitere Operationen ausgeführt werden, um: Shadow-Übersetzungstabellenkacheln zur Rekonstruktion auszuwählen; und vorhandene Shadow-Übersetzungstabellenkacheln wiederzuverwenden.
System nach Anspruch 23, wobei das Mediatormodul ferner den einen oder die mehreren Prozessoren veranlasst, die Shadow-Übersetzungstabelle teilweise zu rekonstruieren, indem weitere Operationen ausgeführt werden, um: eine Unterauswahl von Shadow-Übersetzungstabellenkacheln zur Rekonstruktion basierend auf einem Statusindikator von GTT-Kacheln zu schaffen, die den ausgewählten Shadow-Übersetzungstabellenkacheln zugeordnet sind.
System nach Anspruch 24, wobei das Mediatormodul ferner den einen oder die mehreren Prozessoren veranlasst, den Statusindikator der GTT-Kacheln zu löschen.