DE112018007635T5

DE112018007635T5 - Vorrichtung und verfahren zur effizienten gemeinsamen nutzung einer lokalen anzeige für einen virtualisierten grafikprozessor

Info

Publication number: DE112018007635T5
Application number: DE112018007635.0T
Authority: DE
Inventors: Matthew Roper; Zhi Wang; Satyeshwar Singh; Kalyan Kondapally; Daniel Vetter; Wei Zhang
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-11-30
Filing date: 2018-11-30
Publication date: 2021-04-01
Also published as: US20210264559A1; WO2020107405A1; CN113039522A

Abstract

Vorrichtung und Verfahren zur Implementierung einer virtuellen Anzeige. Zum Beispiel weist eine Ausführungsform einer Grafikverarbeitungsvorrichtung Host-Ausführungsschaltungen zum Ausführen von Anweisungen zum Implementieren von Host- und Virtualisierungsanweisungen zum Implementieren einer virtualisierten Ausführungsumgebung, die mehrere virtuelle Maschinen (VMs) aufweist; Grafikausführungsschaltungen zum Ausführen von Grafikanweisungen zum Rendern von Framebuffern im Auftrag jeder VM, wobei jeder Framebuffer mit einer virtuellen Funktion (VF) assoziiert ist; und eine Anzeigemaschine, die eine oder mehrere Anzeige-Pipes und mehrere Anzeigeebenen aufweist, auf; wobei eine dynamische Abbildung durchgeführt werden soll, um einen oder mehrere der Framebuffer mit einer oder mehreren der Anzeigeebenen zu assoziieren, wobei die dynamische Abbildung das Erzeugen eines Framebuffer-Objektes mit Framebuffer-Informationen, die eine physische Funktion (PF) des Hostes zum Aktualisieren der einen oder mehreren Anzeigeebenen benötigt, umfasst.

Description

ALLGEMEINER STAND DER TECHNIK
Gebiet der Erfindung
Diese Erfindung betrifft im Allgemeinen das Gebiet der Grafikprozessoren. Insbesondere betrifft die Erfindung eine Vorrichtung und ein Verfahren zur effizienten gemeinsamen Nutzung einer lokalen Anzeige.
Beschreibung des Standes der Technik
Die Spezifikation der Single-Root-E/A-Virtualisierung (SR-IOV - Single Root I/O Virtualization) bietet die Möglichkeit zur Implementierung einer Hardware-virtualisierten Grafikverarbeitungseinheit (z.B. einer GPU - Graphics Processing Unit) durch das Definieren eines virtualisierten P CIe-Gerätes zum Anzeigen einer physischen Funktion (PF) und einer Reihe virtueller Funktionen (VFs) auf dem PCIe-Bus.
Diese VFs können die gleichen Grafikfähigkeiten der physischen GPU übernehmen, wodurch jede von ihnen komplett in der Lage ist, die Grafikfunktionalität sowie die Anzeige der GPU zu unterstützen. Über die PF steuert Systemsoftware die Aktivierung und die Zugriffsberechtigungen der VFs.
Auf dem Automobilmarkt, wo ein einzelnes SoC ein sicherheitskritisches Cluster digitaler Instrumente, welche Sicherheitsmetriken (z.B. Geschwindigkeit, Drehzahl usw.) anzeigen, zusammen mit einigen Bord-Infotainment (IVI - In-Vehicle Infotainment) -Systemen, welche Infotainment-Apps anzeigen, konsolidiert, ist es erforderlich, eine Gast-VM mit einer VF zu versehen, welche die Anzeigeressourcen, die dieser VF zugewiesen sind, direkt antreiben kann, um die beste Anzeigeleistung mit geringem Mehraufwand zu erzielen.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung kann aus der folgenden detaillierten Beschreibung in Verbindung mit den nachfolgenden Zeichnungen erhalten werden, in welchen:

1 ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor, der einen oder mehrere Prozessorkerne und Grafikprozessoren aufweist, ist;
2 ein Blockdiagramm einer Ausführungsform eines Prozessors, der einen oder mehrere Prozessorkerne, einen integrierten Speicher-Controller und einen integrierten Grafikprozessor aufweist, ist;
3 ein Blockdiagramm einer Ausführungsform eines Grafikprozessors ist, bei welchem es sich um eine eigenständige Grafikverarbeitungseinheit oder um einen Grafikprozessor, der in mehrere Verarbeitungskerne integriert ist, handeln kann;
4 ein Blockdiagramm einer Ausführungsform einer Grafikverarbeitungsmaschine für einen Grafikprozessor ist;
5 ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors ist;
6A-B Blockdiagramme von Thread-Ausführungslogik, die eine Anordnung von Verarbeitungselementen aufweist, sind;
7 ein Anweisungsformat einer Grafikprozessor-Ausführungseinheit gemäß einer Ausführungsform veranschaulicht;
8 ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors ist, welcher eine Grafik-Pipeline, eine Medien-Pipeline, eine Anzeigemaschine, Thread-Ausführungslogik und eine Renderausgabe-Pipeline aufweist;
9A ein Blockdiagramm ist, welches ein Grafikprozessor-Befehlsformat gemäß einer Ausführungsform veranschaulicht;
9B ein Blockdiagramm ist, welches eine Grafikprozessor-Befehlssequenz gemäß einer Ausführungsform veranschaulicht;
10 eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einer Ausführungsform veranschaulicht;
11A-B ein beispielhaftes IP-Kern-Entwicklungssystem veranschaulichen, das zur Herstellung einer integrierten Schaltung zum Durchführen von Operationen gemäß einer Ausführungsform verwendet werden kann;
12 eine beispielhafte integrierte Schaltung eines Ein-Chip-Systems, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform veranschaulicht;
13A-B einen beispielhaften Grafikprozessor einer integrierten Schaltung eines Ein-Chip-Systems, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, veranschaulichen;
14A-B einen zusätzlichen Grafikprozessor einer integrierten Schaltung eines Ein-Chip-Systems, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, veranschaulichen;
15 ein Beispiel einer Gast/Host-Anordnung für die Grafik-Virtualisierung veranschaulicht;
16 eine Ausführungsform einer Grafik-Virtualisierungsumgebung unter Verwendung von Umblätter-Operationen veranschaulicht;
17 unterschiedliche Arten von Anzeigeinformationen veranschaulicht, die in einer Ausführungsform verwendet werden;
18 beispielhafte virtuelle Anzeige-Pipes und -ebenen, virtuelle Encoder und virtuelle Verbindungselemente veranschaulicht;
19 eine Ausführungsform eines Framebuffer-Deskriptor-Seiteneintrags und einer entsprechenden Seite veranschaulicht;
20 eine bestimmte Ausführungsform der Grafik-Virtualisierung veranschaulicht, welche einen Backend-Dienst und einen entfernten Protokollserver einsetzt;
21 ein Beispiel einer Anzeigemaschine, die mehrere Ebenen und eine Anzeige-Pipe aufweist, veranschaulicht;
22 ein weiteres Beispiel einer Anzeigemaschine, die mehrere Ebenen und eine Anzeige-Pipe aufweist, veranschaulicht;
23 Probleme im Zusammenhang mit einer nicht ordnungsgemäßen Pipe-Steuerung in einem Grafik-Virtualisierungssystem veranschaulicht;
24 eine Ausführungsform der Erfindung veranschaulicht, bei welcher Framebuffer-Informationen zum Durchführen einer Grafik-Virtualisierung gesammelt werden;
25 eine Ausführungsform veranschaulicht, bei welcher eine physische Funktion des Hostes decodierte Framebuffer-Informationen zum Durchführen von Anzeigemaschinenaktualisierungen und Anzeigeebenenaktualisierungen verwendet; und
26 ein Verfahren in Übereinstimmung mit einer Ausführungsform der Erfindung veranschaulicht.

DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung sind zum Zweck der Erläuterung zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der unten beschriebenen Ausführungsformen der Erfindung bereitzustellen. Es wird einem Fachmann auf dem Gebiet jedoch offensichtlich sein, dass die Ausführungsformen der Erfindung auch ohne einige dieser spezifischen Einzelheiten in der Praxis umgesetzt werden können. In anderen Fällen sind gut bekannte Strukturen und Geräte in Form von Blockdiagrammen gezeigt, um ein Verdecken der zugrundeliegenden Prinzipien der Ausführungsformen der Erfindung zu vermeiden.
BEISPIELHAFTE GRAFIKPROZESSORARCHITEKTUREN UND DATENTYPEN
Svstemüberblick
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. In verschiedenen Ausführungsformen weist das System 100 einen oder mehrere Prozessoren 102 und einen oder mehrere Grafikprozessoren 108 auf, und es kann sich dabei um ein Einzelprozessor-Desktopsystem, ein Multiprozessor-Arbeitsplatzsystem oder ein Serversystem mit einer großen Anzahl an Prozessoren 102 oder Prozessorkernen 107 handeln. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in eine integrierte Schaltung eines Ein-Chip-Systems (SoC - System-on-a-Chip) integriert ist, zur Verwendung in Mobilgeräten, Handheld-Geräten oder eingebetteten Geräten.
In einer Ausführungsform kann das System 100 eine serverbasierte Spieleplattform, eine Spielekonsole, einschließlich einer Spiele- und Medienkonsole, eine mobile Spielekonsole, eine Handheld-Spielekonsole oder eine Online-Spielekonsole aufweisen oder darin integriert sein. In einigen Ausführungsformen ist das System 100 ein Mobiltelefon, ein Smartphone, ein Tablet-Rechengerät oder ein mobiles Internetgerät. Das Verarbeitungssystem 100 kann auch ein tragbares Gerät, wie z.B. eine Smartwatch, eine smarte Brille, ein Augmented-Reality-Gerät oder ein Virtual-Reality-Gerät aufweisen, damit gekoppelt sein oder darin integriert sein. In einigen Ausführungsformen ist das Verarbeitungssystem 100 ein Fernsehgerät oder eine Set-Top-Box mit einem oder mehreren Prozessoren 102 und einer Grafikschnittstelle, die durch einen oder mehrere Grafikprozessoren 108 erzeugt wird.
In einigen Ausführungsformen weisen der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 zum Verarbeiten von Anweisungen auf, welche, wenn sie ausgeführt werden, Operationen für System- und Benutzersoftware durchführen. In einigen Ausführungsformen ist jeder des einen oder der mehreren Prozessorkerne 107 zum Verarbeiten eines spezifischen Anweisungssatzes 109 konfiguriert. In einigen Ausführungsformen kann der Anweisungssatz 109 CISC (Complex Instruction Set Computing), RISC (Reduced Instruction Set Computing) oder Berechnung über ein VLIW (Very Long Instruction Word) ermöglichen. Mehrere Prozessorkerne 107 können jeweils einen unterschiedlichen Anweisungssatz 109 verarbeiten, zu welchen Anweisungen zum Ermöglichen der Emulation anderer Anweisungssätze zählen können. Der Prozessorkern 107 kann auch andere Verarbeitungsgeräte aufweisen, wie z.B. einen digitalen Signalprozessor (DSP).
In einigen Ausführungsformen weist der Prozessor 102 einen Cache-Speicher 104 auf. In Abhängigkeit von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Level von internem Cache aufweisen. In einigen Ausführungsformen wird der Cache-Speicher von verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z.B. einen L3 (Level-3) -Cache oder einen LLC (Last Level Cache)) (nicht gezeigt), welcher von den Prozessorkernen 107 unter Verwendung bekannter Cache-Kohärenz-Techniken gemeinsam genutzt werden kann. Außerdem ist eine Registerdatei 106 im Prozessor 102 enthalten, welche unterschiedliche Arten von Registern zum Speichern unterschiedlicher Arten von Daten aufweisen kann (z.B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister). Einige Register können Universalregister sein, während andere Register spezifisch für das Design des Prozessors 102 sein können.
In einigen Ausführungsformen sind ein oder mehrere Prozessor(en) 102 mit einem oder mehreren Schnittstellenbus(sen) 110 gekoppelt, um Kommunikationssignale, wie z.B. Adress-, Daten- oder Steuersignale, zwischen dem Prozessor 102 und anderen Komponenten in dem System 100 zu übertragen. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus sein, wie z.B. eine Version des DMI (Direct Media Interface) -Busses. Jedoch sind Prozessorbusse nicht auf den DMI-Bus beschränkt und können auch einen oder mehrere PCI (Peripheral Component Interconnect) -Busse (z.B. PCI, PCI Express), Speicherbusse oder andere Arten von Schnittstellenbussen aufweisen. In einer Ausführungsform weist (weisen) der (die) Prozessor(en) 102 einen integrierten Speicher-Controller 116 und einen Plattform-Controller-Hub 130 auf. Der Speicher-Controller 116 ermöglicht die Kommunikation zwischen einem Speichergerät und anderen Komponenten des Systems 100, während der Plattform-Controller-Hub (PCH) 130 Verbindungen zu E/A-Geräten über einen lokalen E/A-Bus bereitstellt.
Das Speichergerät 120 kann ein DRAM (Dynamic Random Access Memory) -Gerät, ein SRAM (Static Random Access Memory) -Gerät, ein Flash-Speichergerät, ein Phasenwechsel-Speichergerät oder ein anderes Speichergerät mit geeigneter Leistung, um als ein Prozessspeicher zu dienen, sein. In einer Ausführungsform kann das Speichergerät 120 als ein Systemspeicher für das System 100 arbeiten, zum Speichern von Daten 122 und Anweisungen 121 zur Verwendung, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Der Speicher-Controller 116 ist auch mit einem optionalen externen Grafikprozessor 112 gekoppelt, welcher mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen kann ein Anzeigegerät 111 mit dem (den) Prozessor(en) 102 verbunden sein. Das Anzeigegerät 111 kann eines oder mehrere aus einem internen Anzeigegerät, wie z.B. in einem mobilen elektronischen Gerät oder einem Laptop, oder einem externen Anzeigegerät, das über eine Anzeigeschnittstelle (z.B. DisplayPort usw.) angeschlossen ist, sein. In einer Ausführungsform kann das Anzeigegerät 111 eine am Kopf befestigte Anzeige (HMD - Head Mounted Display) sein, wie z.B. ein stereoskopisches Anzeigegerät zur Verwendung bei VR (Virtual Reality) -Anwendungen oder AR (Augmented Reality) -Anwendungen.
In einigen Ausführungsformen ermöglicht der Plattform-Controller-Hub 130 Peripheriegeräten das Verbinden mit dem Speichergerät 120 und dem Prozessor 102 über einen High-Speed-E/A-Bus. Zu den E/A-Peripheriegeräten zählen, jedoch nicht darauf beschränkt, ein Audio-Controller 146, ein Netzwerk-Controller 134, eine Firmware-Schnittstelle 128, ein drahtloser Sendeempfänger 126, Berührungssensoren 125 und ein Datenspeichergerät 124 (z.B. ein Festplattenlaufwerk, ein Flash-Speicher usw.). Das Datenspeichergerät 124 kann über eine Speicherschnittstelle (z.B. SATA) oder über einen Peripheriebus, wie z.B. einen PCI (Peripheral Component Interconnect) -Bus (z.B. PCI, PCI Express) verbunden sein. Zu den Berührungssensoren 125 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren zählen. Der drahtlose Sendeempfänger 126 kann ein Wi-Fi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein Mobilnetz-Sendeempfänger, wie z.B. ein 3G, 4G oder LTE (Long Term Evolution) -Sendeempfänger, sein. Die Firmware-Schnittstelle 128 ermöglicht die Kommunikation mit System-Firmware und kann zum Beispiel eine einheitliche erweiterbare Firmware-Schnittstelle (UEFI - Unified Extensible Firmware Interface) sein. Der Netzwerk-Controller 134 kann eine Netzwerkverbindung zu einem verdrahteten Netzwerk ermöglichen. In einigen Ausführungsformen ist ein Hochleistungsnetzwerk-Controller (nicht gezeigt) mit dem Schnittstellenbus 110 gekoppelt. Der Audio-Controller 146 ist in einer Ausführungsform ein Mehrkanal-High-Definition-Audio-Controller. In einer Ausführungsform weist das System 100 einen optionalen älteren E/A-Controller 140 zum Koppeln von älteren Geräten (z.B. Personal System 2 (PS/2)) an das System auf. Der Plattform-Controller-Hub 130 kann auch mit einem oder mehreren USB (Universal Serial Bus) -Controllern 142 verbunden sein, um Eingabegeräte, wie z.B. eine Kombination aus Tastatur und Maus 143, eine Kamera 144 oder andere USB-Eingabegeräte anzuschließen.
Es wird verstanden werden, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da auch andere Arten von Datenverarbeitungssystemen, die unterschiedlich konfiguriert sind, zum Einsatz kommen können. Zum Beispiel kann eine Instanz des Speicher-Controllers 116 und des Plattform-Controller-Hubs 130 in einen eigenständigen externen Grafikprozessor integriert sein, wie z.B. den externen Grafikprozessor 112. In einer Ausführungsform können sich der Plattform-Controller-Hub 130 und/oder der Speicher-Controller 1160 außerhalb des einen oder der mehreren Prozessor(en) 102 befinden. Zum Beispiel kann das System 100 einen externen Speicher-Controller 116 und Plattform-Controller-Hub 130 aufweisen, welche als ein Speicher-Controller-Hub und Peripherie-Controller-Hub innerhalb eines System-Chipsatzes, der in Kommunikation mit dem (den) Prozessor(en) 102 steht, konfiguriert sein können.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200, der einen oder mehrere Prozessorkerne 202A-202N, einen integrierten Speicher-Controller 214 und einen integrierten Grafikprozessor 208 aufweist. Diejenigen Elemente von 2, welche die gleichen Bezugsziffern (oder Namen) wie die Elemente jeglicher anderen Figur hierin aufweisen, können in jeglicher Art und Weise ähnlich der an anderer Stelle hierin beschriebenen arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Der Prozessor 200 kann zusätzliche Kerne aufweisen, bis einschließlich des zusätzlichen Kerns 202N, der durch die Kästchen in gestrichelten Linien dargestellt ist. Jeder der Prozessorkerne 202A-202N weist eine oder mehrere interne Cache-Einheiten 204A-204N auf. In einigen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf eine oder mehrere gemeinsam genutzte Cache-Einheiten 206.
Die internen Cache-Einheiten 204A-204N und die gemeinsam genutzten Cache-Einheiten 206 stellen eine Cache-Speicher-Hierarchie innerhalb des Prozessors 200 dar. Die Cache-Speicher-Hierarchie kann mindestens ein Level von Anweisungs- und Daten-Cache innerhalb jedes Prozessorkerns und ein oder mehrere Level von gemeinsam genutztem Cache eines mittleren Levels, wie z.B. Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cache-Level, aufweisen, wobei das höchste Cache-Level vor einem externen Speicher als der LLC klassifiziert ist. In einigen Ausführungsformen hält eine Cache-Kohärenz-Logik die Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A-204N aufrecht.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von einer oder mehreren Bus-Controller-Einheiten 216 und einen System-Agent-Kern 210 aufweisen. Die eine oder die mehreren Bus-Controller-Einheiten 216 managen einen Satz von Peripheriebussen, wie z.B. einen oder mehrere PCI- oder PCI Express-Busse. Der System-Agent-Kern 210 stellt Managementfunktionalität für die verschiedenen Prozessorkomponenten zur Verfügung. In einigen Ausführungsformen weist der System-Agent-Kern 210 einen oder mehrere integrierte Speicher-Controller 214 zum Verwalten des Zugriffs auf verschiedene externe Speichergeräte (nicht gezeigt) auf.
In einigen Ausführungsformen weisen einer oder mehrere der Prozessorkerne 202A-202N Unterstützung für gleichzeitiges Multi-Threading auf. In einer derartigen Ausführungsform weist der System-Agent-Kern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A-202N während der Multi-Thread-Verarbeitung auf. Der System-Agent-Kern 210 kann außerdem eine Leistungssteuereinheit (PCU - Power Control Unit) aufweisen, welche Logik und Komponenten zum Regeln des Energiezustands der Prozessorkerne 202A-202N und des Grafikprozessors 208 aufweist.
In einigen Ausführungsformen weist der Prozessor 200 außerdem den Grafikprozessor 208 zum Ausführen von Grafikverarbeitungsoperationen auf. In einigen Ausführungsformen ist der Grafikprozessor 208 mit dem Satz von gemeinsam genutzten Cache-Einheiten 206 und dem System-Agent-Kern 210 gekoppelt, welcher den einen oder die mehreren integrierten Speicher-Controller 214 aufweist. In einigen Ausführungsformen weist der System-Agent-Kern 210 auch einen Anzeige-Controller 211 zum Antreiben der Grafikprozessorausgabe an eine oder mehrere gekoppelte Anzeigen auf. In einigen Ausführungsformen kann der Anzeige-Controller 211 auch ein separates Modul sein, das über mindestens eine Verbindung mit dem Grafikprozessor gekoppelt ist, oder er kann in den Grafikprozessor 208 integriert sein.
In einigen Ausführungsformen wird eine ringbasierte Verbindungseinheit 212 zum Koppeln der internen Komponenten des Prozessors 200 verwendet. Jedoch kann auch eine alternative Verbindungseinheit zum Einsatz kommen, wie z.B. eine Punkt-zu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Techniken, einschließlich Techniken, die auf dem Gebiet gut bekannt sind. In einigen Ausführungsformen ist der Grafikprozessor 208 über eine E/A-Verknüpfung 213 mit der Ringverbindung 212 gekoppelt.
Die beispielhafte E/A-Verknüpfung 213 stellt mindestens eine von mehreren Varianten von E/A-Verbindungen dar, einschließlich einer On-Package-E/A-Verbindung, welche die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsspeichermodul 218, wie z.B. einem eDRAM-Modul, ermöglicht. In einigen Ausführungsformen verwenden jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als einen gemeinsam genutzten Last-Level-Cache.
In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, welche die gleiche Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Anweisungssatzarchitektur (ISA - Instruction Set Architecture) heterogen, wobei einer oder mehrere der Prozessorkerne 202A-202N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne eine Teilmenge des ersten Anweisungssatzes oder einen unterschiedlichen Anweisungssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich einer Mikroarchitektur heterogen, wobei ein oder mehrere Kerne, die einen relativ höheren Stromverbrauch aufweisen, mit einem oder mehreren Energiekernen, die einen niedrigeren Stromverbrauch aufweisen, gekoppelt sind. Außerdem kann der Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte Schaltung eines SoC, welches die veranschaulichten Komponenten zusätzlich zu anderen Komponenten aufweist, implementiert sein.
3 ist ein Blockdiagramm eines Grafikprozessors 300, bei welchem es sich um eine eigenständige Grafikverarbeitungseinheit oder um einen Grafikprozessor, der in mehrere Verarbeitungskerne integriert ist, handeln kann. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine im Speicher abgebildete E/A-Schnittstelle zu Registern auf dem Grafikprozessor und mit Befehlen, die sich im Prozessorspeicher befinden. In einigen Ausführungsformen weist der Grafikprozessor 300 eine Speicherschnittstelle 314 zum Zugreifen auf Speicher auf. Bei der Speicherschnittstelle 314 kann es sich um eine Schnittstelle zu lokalem Speicher, zu einem oder mehreren internen Caches, zu einem oder mehreren gemeinsam genutzten externen Caches und/oder zu Systemspeicher handeln.
In einigen Ausführungsformen weist der Grafikprozessor 300 auch einen Anzeige-Controller 302 zum Antreiben von Anzeigeausgabedaten an ein Anzeigegerät 320 auf. Der Anzeige-Controller 302 weist Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Zusammensetzung mehrerer Videoschichten oder Benutzerschnittstellenelemente auf. Das Anzeigegerät 320 kann ein internes oder externes Anzeigegerät sein. In einer Ausführungsform ist das Anzeigegerät 320 ein am Kopf befestigtes Anzeigegerät, wie z.B. ein VR (Virtual Reality) -Anzeigegerät oder ein AR (Augmented Reality) -Anzeigegerät. In einigen Ausführungsformen weist der Grafikprozessor 300 eine Video-Codec-Maschine 306 zum Encoder-Decodieren oder -Transcodieren von Medien in, aus oder zwischen ein/em oder mehrere/n Mediencodierungsformate/n auf, einschließlich, jedoch nicht darauf beschränkt, MPEG (Moving Picture Experts Group) -Formate, wie z.B. MPEG-2, AVC (Advanced Video Coding) -Formate, wie z.B. H.264/MPEG-4 AVC, sowie SMPTE (Society of Motion Picture & Television Engineers) 421M/VC-1 und JPEG (Joint Photographic Experts Group) -Formate, wie z.B. JPEG und MJPEG (Motion JPEG) -Formate.
In einigen Ausführungsformen weist der Grafikprozessor 300 eine BLIT (Block Image Transfer) -Maschine 304 zum Durchführen von zweidimensionalen (2D) Rasterer-Operationen, einschließlich zum Beispiel Bit-Grenzen-Blockübertragungen, auf. Jedoch werden in einer Ausführungsform 2D-Grafikoperationen unter Verwendung von einer oder mehreren Komponenten der Grafikverarbeitungsmaschine (GPE - Graphics Processing Engine) 310 durchgeführt. In einigen Ausführungsformen ist die GPE 310 eine Rechenmaschine zum Durchführen von Grafikoperationen, einschließlich dreidimensionaler (3D) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen weist die GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen auf, wie z.B. dem Rendern von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die mit primitiven 3D-Formen arbeiten (z.B. Rechteck, Dreieck usw.). Die 3D-Pipeline 312 weist programmierbare und Feste-Funktion-Elemente auf, die verschiedene Aufgaben innerhalb der Element- und/oder Spawn-Ausführungs-Threads an ein 3D/Medien-Untersystem 315 durchführen. Während die 3D-Pipeline 312 zum Durchführen von Medienoperation verwendet werden kann, weist eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316 auf, die spezifisch zum Durchführen von Medienoperationen verwendet wird, wie z.B. Videonachbearbeitung und Bildverbesserung.
In einigen Ausführungsformen weist die Medien-Pipeline 316 Feste-Funktion- oder programmierbare Logikeinheiten zum Durchführen von einer oder mehreren spezialisierten Medienoperationen, wie z.B. Video-Decodierungsbeschleunigung, Video-De-Interlacing und Video-Codierungsbeschleunigung, anstelle der oder im Auftrag der Video-Codec-Maschine 306 auf. In einigen Ausführungsformen weist die Medien-Pipeline 316 außerdem eine Thread-Spawning-Einheit zum Spawnen von Threads zur Ausführung auf dem 3D/Medien-Untersystem 315 auf. Die gespawnten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten, die im 3D/Medien-Untersystem 315 enthalten sind, durch.
In einigen Ausführungsformen weist das 3D/Medien-Untersystem 315 Logik zum Ausführen von Threads auf, die durch die 3D-Pipeline 312 und die Medien-Pipeline 316 gespawnt werden. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanfragen an das 3D/Medien-Untersystem 315, welches Thread-Versendungslogik zum Abwägen und Versenden der verschiedenen Anfragen an verfügbare Thread-Ausführungsressourcen aufweist. Zu den Ausführungsressourcen zählt eine Anordnung von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medien-Threads. In einigen Ausführungsformen weist das 3D/Medien-Untersystem 315 einen oder mehrere interne Caches für Thread-Anweisungen und Daten auf. In einigen Ausführungsformen weist das Untersystem auch gemeinsam genutzten Speicher auf, einschließlich Registern und adressierbarem Speicher, um Daten zwischen Threads gemeinsam zu nutzen und um Ausgabedaten zu speichern.
Grafikverarbeitungsmaschine
4 ist ein Blockdiagramm einer Grafikverarbeitungsmaschine 410 eines Grafikprozessors in Übereinstimmung mit einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungsmaschine (GPE - Graphics Processing Engine) 410 eine Version der in 3 gezeigten GPE 310. Elemente von 4, welche die gleichen Bezugsziffern (oder Namen) wie die Elemente jeglicher anderen Figur hierin aufweisen, können in jeglicher Art und Weise ähnlich der an anderer Stelle hierin beschriebenen arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Zum Beispiel sind die 3D-Pipeline 312 und die Medien-Pipeline 316 von 3 veranschaulicht. Die Medien-Pipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und ist möglicherweise nicht explizit innerhalb der GPE 410 enthalten. Zum Beispiel ist in mindestens einer Ausführungsform ein separater Medien- und/oder Bildprozessor an die GPE 410 gekoppelt.
In einigen Ausführungsformen ist die GPE 410 mit einem Befehl-Streamer 403 gekoppelt oder weist diesen auf, welcher einen Befehlsstrom an die 3D-Pipeline 312 und/oder die Medien-Pipeline 316 bereitstellt. In einigen Ausführungsformen ist der Befehl-Streamer 403 mit einem Speicher gekoppelt, bei welchem es sich um Systemspeicher oder einen oder mehrere aus internem Cache-Speicher und gemeinsam genutztem Cache-Speicher handeln kann. In einigen Ausführungsformen empfängt der Befehl-Streamer 403 Befehle von dem Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medien-Pipeline 316. Die Befehle sind Anweisungen, die von einem Ringpuffer abgerufen werden, welcher Befehle für die 3D-Pipeline 312 und die Medien-Pipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer außerdem Stapelbefehlspuffer aufweisen, welche Stapel von mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Verweise auf Daten umfassen, die im Speicher gespeichert sind, wie z.B., jedoch nicht darauf beschränkt, Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 312 und die Medien-Pipeline 316 verarbeiten die Befehle und Daten durch das Durchführen von Operationen über Logik innerhalb der entsprechenden Pipelines oder durch das Versenden von einem oder mehreren Ausführungs-Threads an eine Grafikkernanordnung 414. In einer Ausführungsform weist die Grafikkernanordnung 414 einen oder mehrere Blöcke von Grafikkernen (z.B. den (die) Grafikkern(e) 415A, den (die) Grafikkern(e) 415B) auf, wobei jeder Block einen oder mehrere Grafikkerne aufweist. Jeder Grafikkern weist einen Satz von Grafikausführungsressourcen auf, welche Universal- und grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Berechnungsoperationen sowie Feste-Funktion-Texturverarbeitungslogik und/oder Beschleunigungslogik für Maschinenlernen und künstliche Intelligenz umfassen.
In verschiedenen Ausführungsformen weist die 3D-Pipeline 312 Feste-Funktion- und programmierbare Logik zum Verarbeiten von einem oder mehreren Shader-Programmen, wie z.B. Vertex-Shadern, Geometrie-Shadern, Pixel-Shadern, Fragment-Shadern, Berechnungs-Shadern oder anderen Shader-Programmen, durch das Verarbeiten der Anweisungen und das Versenden von Ausführungs-Threads an die Grafikkernanordnung 414 auf. Die Grafikkernanordnung 414 stellt einen einheitlichen Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shader-Programme zur Verfügung. Mehrzweck-Ausführungslogik (z.B. Ausführungseinheiten) innerhalb des/der Grafikkernsie 415A-415B der Grafikkernanordnung 414 umfasst Unterstützung für verschiedene 3D-API-Shader-Sprachen und kann mehrere gleichzeitige Ausführungs-Threads, die mit mehreren Shadern assoziiert sind, ausführen.
In einigen Ausführungsformen weist die Grafikkernanordnung 414 auch Ausführungslogik zum Durchführen von Medienfunktionen auf, wie z.B. Video- und/oder Bildverarbeitung. In einer Ausführungsform weisen die Ausführungseinheiten außerdem Universallogik auf, die zum Durchführen paralleler Universalberechnungsoperationen zusätzlich zu Grafikverarbeitungsoperationen programmierbar ist. Die Universallogik kann Verarbeitungsoperationen parallel zu oder in Verbindung mit Universallogik innerhalb des/der Prozessorkerns/e 107 von 1 oder des Kerns 202A-202N wie in 2 verarbeiten.
Ausgabedaten, die durch Threads erzeugt werden, die in der Grafikkernanordnung 414 ausgeführt werden, können Daten an einen Speicher in einem einheitlichen Rückgabepuffer (URB - Unified Return Buffer) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 zum Senden von Daten zwischen unterschiedlichen Threads, die in der Grafikkernanordnung 414 ausgeführt werden, verwendet werden. In einigen Ausführungsformen kann der URB 418 außerdem zur Synchronisierung zwischen Threads in der Grafikkernanordnung und Feste-Funktion-Logik innerhalb der gemeinsam genutzten Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist die Grafikkernanordnung 414 derart skalierbar, dass die Anordnung eine variable Zahl von Grafikkernen umfasst, die jeweils, basierend auf dem Zielenergie- und -leistungslevel der GPE 410, eine variable Zahl von Ausführungseinheiten aufweisen. In einer Ausführungsform sind die Ausführungsressourcen derart dynamisch skalierbar, dass Ausführungsressourcen nach Bedarf aktiviert oder deaktiviert werden können.
Die Grafikkernanordnung 414 ist mit der gemeinsam genutzten Funktionslogik 420 gekoppelt, welche mehrere Ressourcen umfasst, die zwischen den Grafikkernen in der Grafikkernanordnung gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen innerhalb der gemeinsam genutzten Funktionslogik 420 sind Hardware-Logikeinheiten, die spezialisierte ergänzende Funktionalität an die Grafikkernanordnung 414 bereitstellen. In verschiedenen Ausführungsformen umfasst die gemeinsam genutzte Funktionslogik 420 Logik für Sampler 421, Mathematik 422 und Inter-Thread-Kommunikation (ITC - Inter-Thread Communication) 423, jedoch nicht darauf beschränkt. Außerdem implementieren einige Ausführungsformen einen oder mehrere Cache(s) 425 innerhalb der gemeinsam genutzten Funktionslogik 420.
Eine gemeinsam genutzte Funktion wird implementiert, wenn der Bedarf an einer gegebenen spezialisierten Funktion unzureichend für einen Einschluss innerhalb der Grafikkernanordnung 414 ist. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eine eigenständige Einheit in der gemeinsam genutzten Funktionslogik 420 implementiert und durch die Ausführungsressourcen innerhalb der Grafikkernanordnung 414 gemeinsam genutzt. Der exakte Satz von Funktionen, die durch die Grafikkernanordnung 414 gemeinsam genutzt werden und innerhalb der Grafikkernanordnung 414 enthalten sind, variiert über die Ausführungsformen hinweg. In einigen Ausführungsformen können spezifische gemeinsam genutzte Funktionen innerhalb der gemeinsam genutzten Funktionslogik 420, die durch die Grafikkernanordnung 414 extensiv verwendet werden, innerhalb der gemeinsam genutzten Funktionslogik 416 innerhalb der Grafikkernanordnung 414 enthalten sein. In verschiedenen Ausführungsformen kann die gemeinsam genutzte Funktionslogik 416 innerhalb der Grafikkernanordnung 414 einen Teil der oder die gesamte Logik innerhalb der gemeinsam genutzten Funktionslogik 420 umfassen. In einer Ausführungsform können alle Logikelemente innerhalb der gemeinsam genutzten Funktionslogik 420 innerhalb der gemeinsam genutzten Funktionslogik 416 der Grafikkernanordnung 414 dupliziert sein. In einer Ausführungsform ist die gemeinsam genutzte Funktionslogik 420 zugunsten der gemeinsam genutzten Funktionslogik 416 innerhalb der Grafikkernanordnung 414 ausgeschlossen.
5 ist ein Blockdiagramm von Hardware-Logik eines Grafikprozessorkerns 500 gemäß einigen hierin beschriebenen Ausführungsformen. Elemente of 5, welche die gleichen Bezugsziffern (oder Namen) wie die Elemente jeglicher anderen Figur hierin aufweisen, können in jeglicher Art und Weise ähnlich der an anderer Stelle hierin beschriebenen arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Der veranschaulichte Grafikprozessorkern 500 ist in einigen Ausführungsformen innerhalb der Grafikkernanordnung 414 von 4 enthalten. Bei dem Grafikprozessorkern 500, gelegentlich als Kern-Slice bezeichnet, kann es sich um einen oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors handeln. Der Grafikprozessorkern 500 ist beispielhaft für ein Grafikkern-Slice, und ein Grafikprozessor, wie hierin beschrieben, kann, basierend auf dem Zielenergie- und -leistungsumfang, mehrere Grafikkern-Slices aufweisen. Jeder Grafikprozessorkern 500 kann einen Feste-Funktion-Block 530 gekoppelt mit mehreren Unterkernen 501A-501F, auch bezeichnet als Sub-Slices, aufweisen, die modulare Blöcke von Universal- und Feste-Funktion-Logik aufweisen.
In einigen Ausführungsformen weist der Feste-Funktion-Block 530 eine Geometrie/Feste-Funktion-Pipeline 536 auf, die durch alle Unterkerne in dem Grafikprozessorkern 500 gemeinsam genutzt werden kann, zum Beispiel in Grafikprozessorimplementierungen mit niedrigerer Leistung und/oder niedrigerer Energie. In verschiedenen Ausführungsformen weist die Geometrie/Feste-Funktion-Pipeline 536 eine Feste-Funktion-3D-Pipeline (z.B. die 3D-Pipeline 312 wie in 3 und 4), eine Video-Frontend-Einheit, einen Thread-Spawner und Thread-Dispatcher und einen Manager für einheitliche Rückgabepuffer, welcher einheitliche Rückgabepuffer, wie z.B. den einheitlichen Rückgabepuffer 418 von 4, managt, auf.
In einer Ausführungsform weist der Feste-Funktion-Block 530 auch eine Grafik-SoC-Schnittstelle 537, einen Grafik-Mikrocontroller 538 und eine Medien-Pipeline 539 auf. Die Grafik-SoC-Schnittstelle 537 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 500 und anderen Prozessorkernen innerhalb einer integrierten Schaltung eines Ein-Chip-Systems bereit. Der Grafik-Mikrocontroller 538 ist ein programmierbarer Unterprozessor, der zum Managen verschiedener Funktionen des Grafikprozessorkerns 500, einschließlich Thread-Versendung, -Zeitplanung und -Vorwegnahme, konfigurierbar ist. Die Medien-Pipeline 539 (z.B. die Medien-Pipeline 316 von 3 und 4) weist Logik zum Ermöglichen der Decodierung, Codierung, Vorverarbeitung und/oder Nachbearbeitung von Multimedia-Daten, einschließlich Bild- und Videodaten, auf. Die Medien-Pipeline 539 implementiert Medienoperationen über Berechnungsanfragen oder Abtastlogik innerhalb der Unterkerne 501-501F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 dem Grafikprozessorkern 500 das Kommunizieren mit Universal-Anwendungsprozessorkernen (z.B. CPUs) und/oder anderen Komponenten innerhalb eines SoC, einschließlich Speicherhierarchieelementen, wie z.B. einem gemeinsam genutzten Last-Level-Cache-Speicher, dem System-RAM und/oder eingebettetem On-Chip- oder On-Package-DRAM. Die SoC-Schnittstelle 537 kann auch die Kommunikation mit Feste-Funktion-Geräten innerhalb des SoC, wie z.B. Kamerabildgebungs-Pipelines, ermöglichen und ermöglicht die Verwendung von globaler Speicheratomik und/oder implementiert diese, welche zwischen dem Grafikprozessorkern 500 und CPUs innerhalb des SoC gemeinsam genutzt werden kann. Die SoC-Schnittstelle 537 kann auch Energiemanagementsteuerungen für den Grafikprozessorkern 500 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 500 und anderen Taktdomänen innerhalb des SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 den Empfang von Befehlspuffern von einem Befehl-Streamer und einem globalen Thread-Dispatcher, die zum Bereitstellen von Befehlen und Anweisungen an jeden von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors konfiguriert sind. Die Befehle und Anweisungen können an die Medien-Pipeline 539 versendet werden, wenn Medienoperationen durchgeführt werden sollen, oder an eine Geometrie- und Feste-Funktion-Pipeline (z.B. die Geometrie- und Feste-Funktion-Pipeline 536, die Geometrie- und Feste-Funktion-Pipeline 514), wenn Grafikverarbeitungsoperationen durchgeführt werden sollen.
Der Grafik-Mikrocontroller 538 kann zum Durchführen verschiedener Zeitplanungs- und Managementaufgaben für den Grafikprozessorkern 500 konfiguriert sein. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 Grafik- und/oder Berechnungsarbeitslast-Zeitplanung an den verschiedenen parallelen Grafikmaschinen innerhalb der Ausführungseinheit (EU - Execution Unit) -Anordnungen 502A-502F, 504A-504F innerhalb der Unterkerne 501A-501F durchführen. Bei diesem Zeitplanungsmodell kann Host-Software, die auf einem CPU-Kern eines SoC, welches den Grafikprozessorkern 500 aufweist, ausgeführt wird, Arbeitslasten an eine von vielen Grafikprozessor-Signalisierungseinheiten bereitstellen, wodurch eine Zeitplanungsoperation an der entsprechenden Grafikmaschine ausgelöst wird. Zu Zeitplanungsoperationen zählen das Bestimmen, welche Arbeitslast als nächstes ausgeführt werden soll, das Bereitstellen einer Arbeitslast an einen Befehl-Streamer, das Vorwegnehmen bereits vorhandener Arbeitslasten, die auf einer Maschine ausgeführt werden, das Überwachen des Voranschreitens einer Arbeitslast und das Benachrichtigen der Host-Software, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 auch Niedrigenergie- oder Ruhezustände für den Grafikprozessorkern 500 ermöglichen, wodurch der Grafikprozessorkern 500 die Fähigkeit erhält, Register innerhalb des Grafikprozessorkerns 500 über Niedrigenergie-Zustandsübergänge hinweg unabhängig vom Betriebssystem und/oder der Grafiktreiber-Software auf dem System einzusparen und wiederherzustellen.
Der Grafikprozessorkern 500 kann mehr oder weniger als die veranschaulichten Unterkerne 501A-501F und bis zu N modulare Unterkerne aufweisen. Für jeden Satz von N Unterkernen kann der Grafikprozessorkern 500 auch die gemeinsam genutzte Funktionslogik 510, den gemeinsam genutzten und/oder Cache-Speicher 512, eine Geometrie/Feste-Funktion-Pipeline 514 sowie zusätzliche Feste-Funktion-Logik 516 zum Beschleunigen verschiedener Grafik- und Berechnungsverarbeitungsoperationen aufweisen. Die gemeinsam genutzte Funktionslogik 510 kann Logikeinheiten umfassen, die mit der gemeinsam genutzten Funktionslogik 420 von 4 assoziiert sind (z.B. Logik für Sampler, Mathematik und/oder Inter-Thread-Kommunikation), die durch jeden von N Unterkernen innerhalb des Grafikprozessorkerns 500 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 512 kann ein Last-Level-Cache für den Satz von N Unterkernen 501A-501F innerhalb des Grafikprozessorkerns 500 sein und kann auch als gemeinsam genutzter Speicher dienen, auf den mehrere Unterkerne zugreifen können. Die Geometrie/Feste-Funktion-Pipeline 514 kann anstelle der Geometrie/Feste-Funktion-Pipeline 536 innerhalb des Feste-Funktion-Blocks 530 enthalten sein und kann die gleichen oder ähnliche Logikeinheiten aufweisen.
In einer Ausführungsform weist der Grafikprozessorkern 500 zusätzliche Feste-Funktion-Logik 516 auf, welche verschiedene Feste-Funktion-Beschleunigungslogik zur Verwendung durch den Grafikprozessorkern 500 umfassen kann. In einer Ausführungsform umfasst die zusätzliche Feste-Funktion-Logik 516 eine zusätzliche Geometrie-Pipeline zur Verwendung beim Nur-Position-Shading. Beim Nur-Position-Shading liegen zwei Geometrie-Pipelines vor, die vollständige Geometrie-Pipeline innerhalb der Geometrie/Feste-Funktion-Pipeline 516, 536 und eine aussortierte Pipeline, wobei es sich um eine zusätzliche Geometrie-Pipeline handelt, die innerhalb der zusätzlichen Feste-Funktion-Logik 516 enthalten sein kann. In einer Ausführungsform ist die aussortierte Pipeline eine reduzierte Version der vollständigen Geometrie-Pipeline. Die vollständige Pipeline und die aussortierte Pipeline können unterschiedliche Instanzen der gleichen Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Nur-Position-Shading kann lange Aussortierungsläufe verworfener Dreiecke verbergen, wodurch das Shading in einigen Fällen früher abgeschlossen werden kann. Zum Beispiel kann in einer Ausführungsform die Logik für die aussortierte Pipeline innerhalb der zusätzlichen Feste-Funktion-Logik 516 Positions-Shader parallel zur Hauptanwendung ausführen und erzeugt im Allgemeinen kritische Ergebnisse schneller als die vollständige Pipeline, da die aussortierte Pipeline nur das Positionsattribut der Vertices abruft und schattiert, ohne ein Rastern und Rendern der Pixel an den Framebuffer durchzuführen. Die aussortierte Pipeline kann die erzeugten kritischen Ergebnisse zum Berechnen von Sichtbarkeitsinformationen für sämtliche Dreiecke verwenden, ohne Rücksicht darauf, ob diese Dreiecke aussortiert sind. Die vollständige Pipeline (welche in diesem Fall als eine Wiedergabe-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformation nutzen, um die aussortierten Dreiecke zu überspringen und so nur die sichtbaren Dreiecke zu schattieren, welche schließlich an die Rasterungsphase weitergegeben werden.
In einer Ausführungsform kann die zusätzliche Feste-Funktion-Logik 516 auch Maschinenlernen-Beschleunigungslogik, wie z.B. Feste-Funktion-Matrixmultiplikationslogik, für Implementierungen umfassen, die Optimierungen für Maschinenlerntraining oder -inferenz aufweisen.
Innerhalb jedes Grafikunterkerns 501A-501F ist ein Satz von Ausführungsressourcen enthalten, die zum Durchführen von Grafik-, Medien- und Berechnungsoperationen als Reaktion auf Anfragen durch die Grafik-Pipeline, die Medien-Pipeline oder Shader-Programme verwendet werden können. Die Grafikunterkerne 501A-501F weisen mehrere EU-Anordnungen 502A-502F, 504A-504F, TD/IC (Thread Dispatch/Inter-Thread Communication) -Logik 503A-503F, einen 3D (z.B. Textur) -Sampler 505A-505F, einen Medien-Sampler 506A-506F, einen Shader-Prozessor 507A-507F und gemeinsam genutzten lokalen Speicher (SLM - Shared Local Memory) 508A-508F auf. Die EU-Anordnungen 502A-502F, 504A-504F weisen jeweils mehrere Ausführungseinheiten auf, bei welchen es sich um Universal-Grafikverarbeitungseinheiten handelt, die zum Durchführen von Gleitkomma- und Ganzzahl/Fixpunkt-Logikoperationen im Dienst einer Grafik-, Medien- oder Berechnungsoperation in der Lage sind, einschließlich Grafik-, Medien- oder Berechnungs-Shader-Programmen. Die TD/IC-Logik 503A-503F führt lokale Thread-Versendungs- und Thread-Steuerungsoperationen für die Ausführungseinheiten innerhalb eines Unterkerns durch und ermöglicht die Kommunikation zwischen Threads, die in den Ausführungseinheiten des Unterkerns ausgeführt werden. Der 3D-Sampler 505A-505F kann Textur- oder andere 3D-Grafik-bezogene Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten basierend auf einem konfigurierten Abtastzustand und dem Texturformat, das mit einer gegebenen Textur assoziiert ist, unterschiedlich lesen. Der Medien-Sampler 506A-506F kann ähnliche Leseoperationen basierend auf dem Typ und dem Format, die mit Mediendaten assoziiert sind, durchführen. In einer Ausführungsform kann jeder Grafikunterkern 501A-501F alternativ einen einheitlichen 3D- und Medien-Sampler aufweisen. Threads, die in den Ausführungseinheiten innerhalb jedes der Unterkerne 501A-501F ausgeführt werden, können den gemeinsam genutzten lokalen Speicher 508A-508F innerhalb jedes Unterkerns nutzen, um Threads, die innerhalb einer Thread-Gruppe ausgeführt werden, die Ausführung unter Verwendung eines gemeinsamen Pools von On-Chip-Speicher zu ermöglichen.
Ausführungseinheiten
6A-6B veranschaulichen die Thread-Ausführungslogik 600, die eine Anordnung von Verarbeitungselementen umfasst, die in einem Grafikprozessorkern gemäß hierin beschriebenen Ausführungsformen eingesetzt werden. Elemente der 6A-6B, welche die gleichen Bezugsziffern (oder Namen) wie die Elemente jeglicher anderen Figur hierin aufweisen, können in jeglicher Art und Weise ähnlich der an anderer Stelle hierin beschriebenen arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. 6A veranschaulicht einen Überblick über die Thread-Ausführungslogik 600, welche eine Variante der bei jedem Unterkern 501A-501F von 5 veranschaulichten Hardware-Logik umfassen kann. 6B veranschaulicht beispielhaft interne Details einer Ausführungseinheit.
Wie in 6A veranschaulicht, umfasst die Thread-Ausführungslogik 600 in einigen Ausführungsformen einen Shader-Prozessor 602, einen Thread-Dispatcher 604, einen Anweisungs-Cache 606, eine skalierbare Anordnung von Ausführungseinheiten, die mehrere Ausführungseinheiten 608A-608N aufweist, einen Sampler 610, einen Daten-Cache 612 und einen Datenanschluss 614. In einer Ausführungsform kann die skalierbare Anordnung von Ausführungseinheiten durch das Aktivieren oder Deaktivieren von einer oder mehreren Ausführungseinheiten (z.B. jegliche der Ausführungseinheiten 608A, 608B, 608C, 608D bis 608N-1 und 608N) basierend auf den Berechnungsanforderungen einer Arbeitslast dynamisch skaliert werden. In einer Ausführungsform sind die enthaltenen Komponenten über eine Verbindungsstruktur verbunden, die mit jeder der Komponenten verknüpft ist. In einigen Ausführungsformen umfasst die Thread-Ausführungslogik 600 eine oder mehrere Verbindungen zu einem Speicher, wie z.B. Systemspeicher oder Cache-Speicher, durch eines oder mehrere aus dem Anweisungs-Cache 606, dem Datenanschluss 614, dem Sampler 610 und den Ausführungseinheiten 608A-608N. In einigen Ausführungsformen ist jede Ausführungseinheit (z.B. 608A) eine eigenständige programmierbare Universalberechnungseinheit, die zum Ausführen mehrerer gleichzeitiger Hardware-Threads in der Lage ist, während parallel mehrere Datenelemente für jeden Thread verarbeitet werden. In verschiedenen Ausführungsformen ist die Anordnung von Ausführungseinheiten 608A-608N derart skalierbar, dass sie jegliche Zahl von einzelnen Ausführungseinheiten aufweist.
In einigen Ausführungsformen werden die Ausführungseinheiten 608A-608N primär zum Ausführen von Shader-Programmen verwendet. Ein Shader-Prozessor 602 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads, die mit den Shader-Programmen assoziiert sind, über einen Thread-Dispatcher 604 versenden. In einer Ausführungsform weist der Thread-Dispatcher Logik zum Abwägen von Thread-Initiierungsanfragen von der Grafik- und der Medien-Pipeline und zum Instanziieren der angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 608A-608N auf. Zum Beispiel kann eine Geometrie-Pipeline Vertex-, Tesselierungs- oder Geometrie-Shader zur Verarbeitung an die Thread-Ausführungslogik versenden. In einigen Ausführungsformen kann der Thread-Dispatcher 604 auch Laufzeit-Thread-Spawning-Anfragen von den ausführenden Shader-Programmen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N einen Anweisungssatz, der systemeigene Unterstützung für viele Standard-3D-Grafik-Shader-Anweisungen umfasst, derart, dass Shader-Programme aus Grafikbibliotheken (z.B. Direct 3D und OpenGL) mit minimaler Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z.B. Vertex-Programme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z.B. Pixel-Shader, Fragment-Shader) und Universalverarbeitung (z.B. Berechnungs- und Medien-Shader). Jede der Ausführungseinheiten 608A-608N ist zu Mehrfach-Ausgabe-SIMD (Single Instruction Multiple Data) -Ausführung in der Lage, und das Arbeiten mit mehreren Threads ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit weist eine dedizierte Registerdatei mit hoher Bandbreite und einen assoziierten unabhängigen Thread-Zustand auf. Die Ausführung erfolgt als Mehrfachausgabe pro Takt an Pipelines, die zu Ganzzahloperationen, Gleitkommaoperationen mit einfacher und doppelter Genauigkeit, SIMD-Verzweigungsfähigkeit, logischen Operationen, transzendenten Operationen und verschiedenen anderen Operationen in der Lage sind. Während auf Daten aus dem Speicher oder eine der gemeinsam genutzten Funktionen gewartet wird, veranlasst eine Abhängigkeitslogik innerhalb der Ausführungseinheiten 608A-608N, dass ein wartender Thread schläft, bis die angeforderten Daten zurückgesendet wurden. Während der wartende Thread schläft, können Hardware-Ressourcen der Verarbeitung anderer Threads gewidmet werden. Zum Beispiel kann eine Ausführungseinheit während einer Verzögerung im Zusammenhang mit einer Vertex-Shader-Operation Operationen für einen Pixel-Shader, einen Fragment-Shader oder eine andere Art eines Shader-Programms, einschließlich eines unterschiedlichen Vertex-Shaders, durchführen.
Jede Ausführungseinheit in den Ausführungseinheiten 608A-608N arbeitet an Anordnungen von Datenelementen. Die Zahl von Datenelementen ist die „Ausführungsgröße“ oder die Zahl von Kanälen für die Anweisung. Ein Ausführungskanal ist eine logische Einheit der Ausführung für den Datenelementzugriff, Maskierung und Flusssteuerung innerhalb von Anweisungen. Die Zahl von Kanälen kann unabhängig von der Zahl von physischen arithmetischen Logikeinheiten (ALUs - Arithmetic Logic Units) oder Gleitkommaeinheiten (FPUs - Floating Point Units) für einen bestimmten Grafikprozessor sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N Ganzzahl- und Gleitkomma-Datentypen.
Der Anweisungssatz der Ausführungseinheit umfasst SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert werden, und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Zum Beispiel sind, wenn mit einem 256-Bit-breiten Vektor gearbeitet wird, die 256 Bits des Vektors in einem Register gespeichert, und die Ausführungseinheit arbeitet mit dem Vektor als vier separate gepackte 64-Bit-Datenelemente (Datenelemente der Größe QW (Quad-Word)), acht separate gepackte 32-Bit-Datenelemente (Datenelemente der Größe DW (Double Word)), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente der Größe W (Word)) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente der Größe B (Byte)). Es sind jedoch auch unterschiedliche Vektorbreiten und Registergrößen möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten zu einer verschmolzenen Ausführungseinheit 609A-609N kombiniert werden, die Thread-Steuerungslogik (607A-607N) aufweist, welche die verschmolzenen EUs gemeinsam haben. Mehrere EUs können zu einer EU-Gruppe verschmolzen sein. Jede EU in der verschmolzenen EU-Gruppe kann zum Ausführen eines separaten SIMD-Hardware-Threads konfiguriert sein. Die Zahl von EUs in einer verschmolzenen EU-Gruppe kann gemäß Ausführungsformen variieren. Außerdem können verschiedene SIMD-Breiten pro EU durchgeführt werden, einschließlich, jedoch nicht darauf beschränkt, SIMD8, SIMD16 und SIMD32. Jede verschmolzene Grafikausführungseinheit 609A-609N weist mindestens zwei Ausführungseinheiten auf. Zum Beispiel weist die verschmolzene Ausführungseinheit 609A eine erste EU 608A, eine zweite EU 608B und die Thread-Steuerungslogik 607A, welche die erste EU 608A und die zweite EU 608B gemeinsam haben, auf. Die Thread-Steuerungslogik 607A steuert Threads, die in der verschmolzenen Grafikausführungseinheit 609A ausgeführt werden, wodurch jeder EU innerhalb der verschmolzenen Ausführungseinheiten 609A-609N gestattet wird, die Ausführung unter Verwendung eines gemeinsamen Anweisungszeigerregisters vorzunehmen.
Ein oder mehrere interne Anweisungs-Caches (z.B. 606) sind in der Thread-Ausführungslogik 600 enthalten, um Thread-Anweisungen für die Ausführungseinheiten zwischenzuspeichern. In einigen Ausführungsformen sind ein oder mehrere Daten-Caches (z.B. 612) enthalten, um Thread-Daten während der Thread-Ausführung zwischenzuspeichern. In einigen Ausführungsformen ist ein Sampler 610 enthalten, um Texturabtastung für 3D-Operationen und Medienabtastung für Medienoperationen bereitzustellen. In einigen Ausführungsformen weist der Sampler 610 spezialisierte Textur- oder Medienabtastfunktionalität zum Verarbeiten von Textur- oder Mediendaten während des Abtastprozesses vor der Bereitstellung der abgetasteten Daten an eine Ausführungseinheit auf.
Während der Ausführung senden die Grafik- und die Medien-Pipeline über die Thread-Spawning- und -Dispatch-Logik Thread-Initiierungsanfragen an die Thread-Ausführungslogik 600. Nachdem eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten gerastert wurde, wird Pixelprozessorlogik (z.B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) innerhalb des Shader-Prozessors 602 aktiviert, um Ausgabeinformationen weiter zu berechnen und zu veranlassen, dass Ergebnisse auf Ausgabeoberflächen (z.B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In einigen Ausführungsformen berechnet ein Pixel-Shader oder ein Fragment-Shader die Werte der verschiedenen Vertex-Attribute, die über das gerasterte Objekt hinweg interpoliert werden sollen. In einigen Ausführungsformen führt Pixelprozessorlogik innerhalb des Shader-Prozessors 602 dann ein durch eine Anwendungsprogrammierungsschnittstelle (API - Application Programming Interface) bereitgestelltes Pixel- oder Fragment-Shader-Programm aus. Zum Ausführen des Shader-Programms versendet der Shader-Prozessor 602 über den Thread-Dispatcher 604 Threads an eine Ausführungseinheit (z.B. 608A). In einigen Ausführungsformen verwendet der Shader-Prozessor 602 Texturabtastlogik im Sampler 610 zum Zugreifen auf Texturdaten in Texturabbildungen, die im Speicher gespeichert sind. Arithmetische Operationen an den Texturdaten und den eingegebenen Geometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel aus der weiteren Verarbeitung.
In einigen Ausführungsformen stellt der Datenanschluss 614 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 600 zum Ausgeben verarbeiteter Daten an einen Speicher zur weiteren Verarbeitung in einer Grafikprozessor-Ausgabe-Pipeline zur Verfügung. In einigen Ausführungsformen weist der Datenanschluss 614 einen oder mehrere Cache-Speicher (z.B. den Daten-Cache 612) auf oder ist daran gekoppelt, um Daten für den Speicherzugriff über den Datenanschluss zwischenzuspeichern.
Wie in 6B veranschaulicht, kann eine Grafikausführungseinheit 608 eine Anweisungsabrufeinheit 637, eine allgemeine Registerdatei (GRF - General Register File) -Anordnung 624, eine Architekturregisterdatei (ARF - Architectural Register File) -Anordnung 626, einen Thread-Arbiter 622, eine Sendeeinheit 630, eine Verzweigungseinheit 632, einen Satz von SIMD-Gleitkommaeinheiten (FPUs - Floating Point Units) 634 und in einer Ausführungsform einen Satz von dedizierten Ganzzahl-SIMD-ALUs 635 aufweisen. Die GRF 624 und die ARF 626 weisen den Satz von allgemeinen Registerdateien und Architekturregisterdateien auf, die mit jedem gleichzeitigen Hardware-Thread assoziiert sind, der in der Grafikausführungseinheit 608 aktiv sein kann. In einer Ausführungsform wird der Architekturzustand pro Thread in der ARF 626 gepflegt, während Daten, die während der Thread-Ausführung verwendet werden, in der GRF 624 gespeichert sind. Der Ausführungszustand jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in Thread-spezifischen Registern in der ARF 626 enthalten sein.
In einer Ausführungsform weist die Grafikausführungseinheit 608 eine Architektur auf, bei welcher es sich um eine Kombination aus gleichzeitigem Multithreading (SMT - Simultaneous Multi-Threading) und fein abgestimmtem verschachteltem Multithreading (IMT - Interleaved Multi-Threading) handelt. Die Architektur weist eine modulare Konfiguration auf, die während der Designphase basierend auf eine Zielzahl von gleichzeitigen Threads und einer Zahl von Registern pro Ausführungseinheit feinabgestimmt werden kann, wobei Ressourcen der Ausführungseinheit über Logik hinweg aufgeteilt werden, die zum Ausführen mehrerer gleichzeitiger Threads zum Einsatz kommt.
In einer Ausführungsform kann die Grafikausführungseinheit 608 gleichzeitig mehrere Anweisungen ausgeben, bei welchen es sich um unterschiedliche Anweisungen handeln kann. Der Thread-Arbiter 622 der Grafikausführungseinheit 608 kann die Anweisungen zur Verarbeitung an eine aus der Sendeeinheit 630, der Verzweigungseinheit 6342 oder der/den SIMD-FPU(s) 634 versenden. Jeder Ausführungs-Thread kann auf 128 Universalregister innerhalb der GRF 624 zugreifen, wobei jedes Register 32 Bytes speichern kann, die als ein SIMD-8-Element-Vektor von 32-Bit-Datenelementen zugänglich sind. In einer Ausführungsform hat jeder Ausführungs-Thread Zugriff auf 4 kBytes innerhalb der GRF 624, obwohl Ausführungsformen dahingehend nicht beschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt werden können. In einer Ausführungsform können bis zu sieben Threads gleichzeitig ausgeführt werden, obwohl die Zahl der Threads pro Ausführungseinheit gemäß Ausführungsformen auch variieren kann. In einer Ausführungsform, in welcher sieben Threads auf 4 kBytes zugreifen können, kann die GRF 624 insgesamt 28 kBytes speichern. Flexible Adressierungsmodi können es gestatten, dass Register zusammen adressiert werden, um effektiv breitere Register aufzubauen, oder dass diese schrittweise rechtwinklige Blockdatenstrukturen darstellen.
In einer Ausführungsform werden Speicheroperationen, Sampler-Operationen und andere Systemkommunikation mit längerer Latenz über „Sende“-Anweisungen versendet, die durch die Nachrichtenaustausch-Sendeeinheit 630 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 632 versendet, um SIMD-Divergenz und letztendlich Konvergenz zu ermöglichen.
In einer Ausführungsform weist die Grafikausführungseinheit 608 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s) - Floating Point Unit(s)) 634 zum Durchführen von Gleitkommaoperationen auf. In einer Ausführungsform unterstützt (unterstützen) die FPU(s) 634 auch Ganzzahlberechnung. In einer Ausführungsform kann (können) die FPU(s) 634 bis zu M 32-Bit-Gleitkomma (oder Ganzzahl) -Operationen mittels SIMD ausführen oder bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkomma-Operationen mittels SIMD ausführen. In einer Ausführungsform stellt mindestens eine der FPU(s) erweiterte Mathematikfähigkeiten zur Unterstützung von transzendenten Mathematikfunktionen mit hohem Durchsatz und 64-Bit-Gleitkomma mit doppelter Genauigkeit zur Verfügung. In einigen Ausführungsformen liegt auch ein Satz von 8-Bit-Ganzzahl-SIMD-ALUs 635 vor und kann spezifisch optimiert werden, um Operationen im Zusammenhang mit Maschinenlernen-Berechnungen durchzuführen.
In einer Ausführungsform können Anordnungen mehrerer Instanzen der Grafikausführungseinheit 608 in einer Grafikunterkern-Gruppierung (z.B. einem Sub-Slice) instanziiert sein. Für die Skalierbarkeit können Produktarchitekten die exakte Zahl von Ausführungseinheiten pro Unterkern-Gruppierung wählen. In einer Ausführungsform kann die Ausführungseinheit 608 Anweisungen über mehrere Ausführungskanäle hinweg ausführen. In einer weiteren Ausführungsform wird jeder Thread, der in der Grafikausführungseinheit 608 ausgeführt wird, auf einem unterschiedlichen Kanal ausgeführt.
7 ist ein Blockdiagramm, welches ein Grafikprozessoranweisungsformat 700 gemäß einigen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Anweisungssatz, der Anweisungen in mehreren Formaten aufweist. Die Kästchen mit durchgezogenen Linien veranschaulichen die Komponenten, die im Allgemeinen in einer Anweisung einer Ausführungseinheit enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Anweisungen enthalten sind. In einigen Ausführungsformen handelt es sich bei dem beschriebenen und veranschaulichten Anweisungsformat 700 um Makroanweisungen, bei welchen es sich um Anweisungen handelt, die an die Ausführungseinheit bereitgestellt werden, im Gegensatz zu Mikrooperationen, die aus einer Anweisungsdecodierung resultieren, nachdem die Anweisung verarbeitet wurde.
In einigen Ausführungsformen weisen die Grafikprozessor-Ausführungseinheiten systemeigene Unterstützung für Anweisungen in einem 128-Bit-Anweisungsformat 710 auf. Ein komprimiertes 64-Bit-Anweisungsformat 730 steht für einige Anweisungen basierend auf der ausgewählten Anweisung, Anweisungsoptionen und der Zahl der Operanden zur Verfügung. Das systemeigene 128-Bit-Anweisungsformat 710 bietet Zugriff auf alle Anweisungsoptionen, während einige Optionen und Operationen auf das 64-Bit-Format 730 beschränkt sind. Die systemeigenen Anweisungen, die im 64-Bit-Format 730 zur Verfügung stehen, variieren je nach Ausführungsform. In einigen Ausführungsformen ist die Anweisung unter Verwendung eines Satzes von Indexwerten in einem Index-Feld 713 teilweise komprimiert. Die Hardware der Ausführungseinheit verweist auf einen Satz von Komprimierungstabellen, die auf den Indexwerten basieren, und verwendet die Ausgaben der Komprimierungstabelle zum Rekonstruieren einer systemeigenen Anweisung im 128-Bit-Anweisungsformat 710.
Für jedes Format definiert ein Anweisungs-Opcode 712 die Operation, welche die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden hinweg aus. Zum Beispiel führt die Ausführungseinheit als Reaktion auf eine Hinzufügen-Anweisung eine gleichzeitige Hinzufügen-Operation über jeden Farbkanal, der ein Texturelement oder Bildelement darstellt, hinweg durch. Voreingestellt führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden hinweg durch. In einigen Ausführungsformen ermöglicht ein Feld Anweisungssteuerung 714 die Steuerung bestimmter Ausführungsoperationen, wie z.B. Kanalauswahl (z.B. Prädikation) und Datenkanalreihenfolge (z.B. Umstellung). Bei Anweisungen im 128-Bit-Anweisungsformat 710 begrenzt ein Feld Ausführungsgröße 716 die Zahl der Datenkanäle, die parallel ausgeführt werden. In einigen Ausführungsformen steht das Feld Ausführungsgröße 716 nicht zur Verwendung im komprimierten 64-Bit-Anweisungsformat 730 zur Verfügung.
Einige Anweisungen der Ausführungseinheit weisen bis zu drei Operanden auf, einschließlich zweier Quelloperanden, src0 720, srcl 722, und eines Ziels 718. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Doppelzielanweisungen, wobei eines der Ziele impliziert ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden (z.B. SRC2 724) aufweisen, wobei der Anweisungs-Opcode 712 die Zahl der Quelloperanden bestimmt. Ein letzter Quelloperand der Anweisung kann ein unmittelbarer (z.B. fest codierter) Wert sein, der mit der Anweisung weitergegeben wird.
In einigen Ausführungsformen weist das 128-Bit-Anweisungsformat 710 ein Feld Zugriffs-/Adressierungsmodus 726 auf, das zum Beispiel spezifiziert, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn ein direkter Registeradressierungsmodus verwendet wird, wird die Registeradresse von einem oder mehreren Operanden direkt durch Bits in der Anweisung bereitgestellt.
In einigen Ausführungsformen weist das 128-Bit-Anweisungsformat 710 ein Feld Zugriffs-/Adressierungsmodus 726 auf, welches einen Adressierungsmodus und/oder einen Zugriffsmodus für die Anweisung spezifiziert. In einer Ausführungsform wird der Zugriffsmodus zum Definieren einer Datenzugriffsausrichtung für die Anweisung verwendet. Einige Ausführungsformen unterstützen Zugriffsmodi, einschließlich eines ausgerichteten 16-Byte-Zugriffsmodus und eines ausgerichteten 1-Byte-Zugriffsmodus, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Zum Beispiel kann die Anweisung, in einem ersten Modus, Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden und, in einem zweiten Modus, kann die Anweisung 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressierungsmodus-Abschnitt des Feldes Zugriffs-/Adressierungsmodus 726, ob die Anweisung direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, stellen Bits in der Anweisung die Registeradresse von einem oder mehreren Operanden direkt zur Verfügung. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse von einem oder mehreren Operanden basierend auf einem Adressregisterwert und einem unmittelbaren Adressfeld in der Anweisung berechnet werden.
In einigen Ausführungsformen sind die Anweisungen basierend auf Bit-Feldern des Opcodes 712 gruppiert, um die Opcode-Decodierung 740 zu vereinfachen. Bei einem 8-Bit-Opcode gestatten die Bits 4, 5 und 6 der Ausführungseinheit das Bestimmen des Typs des Opcodes. Die gezeigte genaue Opcode-Gruppierung ist lediglich ein Beispiel. In einigen Ausführungsformen umfasst eine Opcode-Gruppe Bewegung und Logik 742 Datenbewegungs- und Logikanweisungen (z.B. Bewegen (mov), Vergleichen (cmp)). In einigen Ausführungsformen nutzt die Gruppe Bewegung und Logik 742 die fünf signifikantesten Bits (MSB - Most Significant Bits) gemeinsam, wobei Bewegungs- (mov) Anweisungen die Form 0000xxxxb aufweisen und LogikAnweisungen die Form 0001xxxxb aufweisen. Eine Anweisungsgruppe Flusssteuerung 744 (z.B. Rufen, Springen (jmp)) umfasst Anweisungen in der Form 0010xxxxb (z.B. 0x20). Eine Anweisungsgruppe Sonstige 746 umfasst eine Mischung von Anweisungen, einschließlich Synchronisierungsanweisungen (z.B. Warten, Senden) in der Form 0011xxxxb (z.B. 0x30). Eine Anweisungsgruppe Parallelmathematik 748 umfasst komponentenweise arithmetische Anweisungen (z.B. Addieren, Multiplizieren (mul)) in der Form 0100xxxxb (z.B. 0x40). Die Gruppe Parallelmathematik 748 führt die arithmetischen Operationen parallel über Datenkanäle hinweg durch. Die Gruppe Vektormathematik 750 umfasst arithmetische Anweisungen (z.B. dp4) in der Form 0101xxxxb (z.B. 0x50). Die Gruppe Vektormathematik führt Arithmetik durch, wie z.B. Punktproduktberechnungen an Vektoroperanden.
Grafik-Pipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente von 8, welche die gleichen Bezugsziffern (oder Namen) wie die Elemente jeglicher anderen Figur hierin aufweisen, können in jeglicher Art und Weise ähnlich der an anderer Stelle hierin beschriebenen arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt.
In einigen Ausführungsformen weist der Grafikprozessor 800 eine Geometrie-Pipeline 820, eine Medien-Pipeline 830, eine Anzeigemaschine 840, Thread-Ausführungslogik 850 und eine Renderausgabe-Pipeline 870 auf. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkern-Verarbeitungssystems, das einen oder mehrere Universalverarbeitungskerne aufweist. Der Grafikprozessor wird durch Registerschreibvorgänge in eine oder mehrere Steuerregister (nicht gezeigt) oder über Befehle, die über eine Ringverbindung 802 an den Grafikprozessor 800 ausgegeben werden, gesteuert. In einigen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 an andere Verarbeitungskomponenten, wie z.B. andere Grafikprozessoren oder Universalprozessoren. Befehle von der Ringverbindung 802 werden durch einen Befehl-Streamer 803 interpretiert, welcher Anweisungen an einzelne Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 bereitstellt.
In einigen Ausführungsformen steuert der Befehl-Streamer 803 die Operation einer Vertex-Abrufeinheit 805, die Vertex-Daten aus einem Speicher liest und Vertex-Verarbeitungsbefehle ausführt, die durch den Befehl-Streamer 803 bereitgestellt werden. In einigen Ausführungsformen stellt die Vertex-Abrufeinheit 805 Vertex-Daten an einen Vertex-Shader 807 bereit, welcher Koordinatenraumtransformations- und -beleuchtungsoperationen an jedem Vertex durchführt. In einigen Ausführungsformen führen die Vertex-Abrufeinheit 805 und der Vertex-Shader 807 Vertex-Verarbeitungsanweisungen durch das Versenden von Ausführungs-Threads an die Ausführungseinheiten 852A-852B über einen Thread-Dispatcher 831 aus.
In einigen Ausführungsformen handelt es sich bei den Ausführungseinheiten 852A-852B um eine Anordnung von Vektorprozessoren mit einem Anweisungssatz zum Durchführen von Grafik- und Medienoperationen. In einigen Ausführungsformen weisen die Ausführungseinheiten 852A-852B einen daran angeschlossenen L1-Cache 851 auf, der spezifisch für jede Anordnung ist oder zwischen den Anordnungen gemeinsam genutzt wird. Der Cache kann als ein Daten-Cache, ein Anweisungs-Cache oder ein einzelner Cache, der derart partitioniert ist, dass er Daten und Anweisungen in unterschiedlichen Partitionen enthält, konfiguriert sein.
In einigen Ausführungsformen weist die Geometrie-Pipeline 820 Tesselierungskomponenten zum Durchführen von Hardware-beschleunigter Tesselierung von 3D-Objekten auf. In einigen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tesselierungsoperationen. Ein programmierbarer Domain-Shader 817 stellt eine Backend-Evaluierung der Tesselierungsausgabe zur Verfügung. Ein Tessellator 813 arbeitet auf Anweisung des Hull-Shaders 811 und enthält Speziallogik zum Erzeugen eines Satzes detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell, welches als Eingabe in die Geometrie-Pipeline 820 bereitgestellt wird. In einigen Ausführungsformen können, wenn keine Tesselierung angewandt wird, die Tesselierungskomponenten (z.B. Hull-Shader 811, Tessellator 813 und Domain-Shader 817) umgangen werden.
In einigen Ausführungsformen können vollständige geometrische Objekte über einen oder mehrere Threads, die an die Ausführungseinheiten 852A-852B versandt werden, durch einen Geometrie-Shader 819 verarbeitet werden oder können direkt zum Clipper 829 weitergeleitet werden. In einigen Ausführungsformen arbeitet der Geometrie-Shader an kompletten geometrischen Objekten anstatt an Vertices oder Patches von Vertices, wie in vorherigen Stufen der Grafik-Pipeline. Wenn die Tesselierung deaktiviert ist, empfängt der Geometrie-Shader 819 eine Eingabe vom Vertex-Shader 807. In einigen Ausführungsformen ist der Geometrie-Shader 819 durch ein Geometrie-Shader-Programm programmierbar, um Geometrie-Tesselierung durchzuführen, falls die Tesselierungseinheiten deaktiviert sind.
Vor der Rasterung verarbeitet ein Clipper 829 die Vertex-Daten. Der Clipper 829 kann ein Feste-Funktion-Clipper oder ein programmierbarer Clipper sein, der Begrenzungs- und Geometrie-Shader-Funktionen aufweist. In einigen Ausführungsformen versendet eine Rasterer- und Tiefentestkomponente 873 in der Renderausgabe-Pipeline 870 Pixel-Shader zum Umwandeln der geometrischen Objekte in Pro-Pixel-Darstellungen. In einigen Ausführungsformen ist Pixel-Shader-Logik in der Thread-Ausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung die Rasterer- und Tiefentestkomponente 873 umgehen und über eine Ausströmeinheit 823 auf ungerasterte Vertex-Daten zugreifen.
Der Grafikprozessor 800 weist einen Verbindungsbus, eine Verbindungsstruktur oder einen anderen Verbindungsmechanismus auf, welche/r die Weitergabe von Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors gestattet. In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B und assoziierte Logikeinheiten (z.B. der L1-Cache 851, der Sampler 854, der Textur-Cache 858 usw.) über einen Datenanschluss 856 verbunden, um Speicherzugriff durchzuführen und mit Komponenten der Renderausgabe-Pipeline des Prozessors zu kommunizieren. In einigen Ausführungsformen weisen der Sampler 854, die Caches 851, 858 und die Ausführungseinheiten 852A-852B jeweils separate Speicherzugriffspfade auf. In einer Ausführungsform kann der Textur-Cache 858 auch als ein Sampler-Cache konfiguriert sein.
In einigen Ausführungsformen enthält die Renderausgabe-Pipeline 870 eine Rasterer- und Tiefentestkomponente 873, die Vertex-basierte Objekte in eine assoziierte Pixel-basierte Darstellung umwandelt. In einigen Ausführungsformen umfasst die Rasterer-Logik eine Windower/Maskierer-Einheit zum Durchführen von Feste-Funktion-Dreiecks- und -Linien-Rasterung. In einigen Ausführungsformen stehen auch ein assoziierter Render-Cache 878 und Tiefen-Cache 879 zur Verfügung. Eine Komponente für Pixel-Operationen 877 führt Pixel-basierte Operationen an den Daten durch, obwohl in einigen Fällen Pixel-Operationen im Zusammenhang mit 2D-Operationen (z.B. Bit-Block-Bildtransfers mit Vermischung) auch durch die 2D-Maschine 841 durchgeführt werden oder zum Zeitpunkt der Anzeige durch den Anzeige-Controller 843 unter Verwendung von Überlagerungsanzeigeebenen ersetzt werden. In einigen Ausführungsformen steht allen Grafikkomponenten ein gemeinsam genutzter L3-Cache 875 zur Verfügung, welcher die gemeinsame Nutzung von Daten ohne die Verwendung des Hauptsystemspeichers gestattet.
In einigen Ausführungsformen weist die Medien-Pipeline 830 des Grafikprozessors eine Medienmaschine 837 und ein Video-Frontend 834 auf. In einigen Ausführungsformen empfängt das Video-Frontend 834 Pipeline-Befehle vom Befehl-Streamer 803. In einigen Ausführungsformen weist die Medien-Pipeline 830 einen separaten Befehl-Streamer auf. In einigen Ausführungsformen verarbeitet das Video-Frontend 834 Medienbefehle vor dem Senden des Befehls an die Medienmaschine 837. In einigen Ausführungsformen weist die Medienmaschine 837 Thread-Spawning-Funktionalität zum Spawnen von Threads zum Versenden an die Thread-Ausführungslogik 850 über den Thread-Dispatcher 831 auf.
In einigen Ausführungsformen weist der Grafikprozessor 800 eine Anzeigemaschine 840 auf. In einigen Ausführungsformen befindet sich die Anzeigemaschine 840 außerhalb des Prozessors 800 und ist über die Ringverbindung 802 oder einein andere/n Verbindungsbus oder -struktur mit dem Grafikprozessor gekoppelt. In einigen Ausführungsformen weist die Anzeigemaschine 840 eine 2D-Maschine 841 und einen Anzeige-Controller 843 auf. In einigen Ausführungsformen enthält die Anzeigemaschine 840 Speziallogik, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen ist der Anzeige-Controller 843 mit einem Anzeigegerät (nicht gezeigt) gekoppelt, wobei es sich um ein systemintegriertes Anzeigegerät, wie in einem Laptop, oder ein externes Anzeigegerät, das über ein Anzeigegerät-Verbindungselement angeschlossen ist, handeln kann.
In einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 zum Durchführen von Operationen basierend auf mehreren Grafik- und Medienprogrammierungsschnittstellen konfigurierbar und sind nicht spezifisch für jegliche eine Anwendungsprogrammierungsschnittstelle (API - Application Programming Interface). In einigen Ausführungsformen übersetzt Treiber-Software für den Grafikprozessor API-Aufrufe, die spezifisch für eine bestimmte Grafik- oder Medienbibliothek sind, in Befehle, die durch den Grafikprozessor verarbeitet werden können. In einigen Ausführungsformen wird Unterstützung für die OpenGL (Open Graphics Library), OpenCL (Open Computing Language) und/oder Vulkan-Grafik- und Berechnungs-API, alle von der Khronos Gruppe, bereitgestellt. In einigen Ausführungsformen kann auch Unterstützung für die Direct3D-Bibliothek von der Microsoft Corporation bereitgestellt werden. In einigen Ausführungsformen kann eine Kombination aus diesen Bibliotheken unterstützt werden. Es kann auch Unterstützung für die OpenCV (Open Source Computer Vision Library) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde auch unterstützt werden, wenn eine Abbildung von der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors vorgenommen werden kann.
Grafik-Pipeline-Programmierung
9A ist ein Blockdiagramm, welches ein Grafikprozessor-Befehlsformat 900 gemäß einigen Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, welches eine Grafikprozessor-Befehlssequenz 910 gemäß einer Ausführungsform veranschaulicht. Die Kästchen mit durchgezogenen Linien in 9A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 von 9A umfasst Datenfelder zum Identifizieren eines Clients 902, eines Befehlsoperationscodes (Opcode) 904 und von Daten 906 für den Befehl. Ein Sub-Opcode 905 und eine Befehlsgröße 908 sind auch in einigen Befehlen enthalten.
In einigen Ausführungsformen spezifiziert der Client 902 die Client-Einheit des Grafikgerätes, das die Befehlsdaten verarbeitet. In einigen Ausführungsformen prüft ein Befehl-Parser des Grafikprozessors das Client-Feld jedes Befehls zum Konditionieren der weiteren Verarbeitung des Befehls und zum Routen der Befehlsdaten zu der entsprechenden Client-Einheit. In einigen Ausführungsformen weisen die Client-Einheiten des Grafikprozessors eine Speicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit auf. Jede Client-Einheit weist eine entsprechende Verarbeitungs-Pipeline auf, welche die Befehle verarbeitet. Nachdem der Befehl durch die Client-Einheit empfangen wurde, liest die Client-Einheit den Opcode 904 und, falls vorhanden, den Sub-Opcode 905 zum Bestimmen der durchzuführenden Operation. Die Client-Einheit führt den Befehl unter Verwendung von Informationen im Datenfeld 906 durch. Bei einigen Befehlen wird eine explizite Befehlsgröße 908 zum Spezifizieren der Größe des Befehls erwartet. In einigen Ausführungsformen bestimmt der Befehl-Parser automatisch die Größe von zumindest einigen der Befehle basierend auf dem Befehls-Opcode. In einigen Ausführungsformen werden Befehle über Multiple eines Doppelwortes ausgerichtet.
Das Flussdiagramm in 9B veranschaulicht eine beispielhafte Grafikprozessor-Befehlssequenz 910. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors aufweist, eine Version der gezeigten Befehlssequenz zum Erstellen, Ausführen und Beenden eines Satzes von Grafikoperationen. Eine Beispielbefehlssequenz ist lediglich zu Beispielzwecken gezeigt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlssequenz beschränkt sind. Darüber hinaus können die Befehle als ein Stapel von Befehlen in einer Befehlssequenz ausgegeben werden, derart, dass der Grafikprozessor die Sequenz von Befehlen mit zumindest teilweiser Gleichzeitigkeit verarbeitet.
In einigen Ausführungsformen kann die Befehlssequenz 910 des Grafikprozessors mit einem Befehl Pipeline Leeren 912 beginnen, um jegliche aktive Grafik-Pipeline zu veranlassen, die gegenwärtig ausstehenden Befehle für die Pipeline abzuschließen. In einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Das Leeren der Pipeline wird durchgeführt, um die aktive Grafik-Pipeline zu veranlassen, jegliche ausstehenden Befehle abzuschließen. Als Reaktion auf das Leeren der Pipeline pausiert der Befehl-Parser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichnungsmaschinen ausstehende Operationen abgeschlossen haben und die relevanten Lese-Caches annulliert wurden. Wahlweise können jegliche Daten im Render-Cache, die als „unsauber‟ gekennzeichnet sind, in den Speicher verschoben werden. In einigen Ausführungsformen kann der Befehl Pipeline Leeren 912 zur Pipeline-Synchronisierung verwendet werden, oder bevor der Grafikprozessor in einen Niedrigenergiezustand geschaltet wird.
In einigen Ausführungsformen wird ein Befehl Pipeline-Auswahl 913 verwendet, wenn eine Befehlssequenz es erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. In einigen Ausführungsformen ist ein Befehl Pipeline-Auswahl 913 lediglich einmal innerhalb eines Ausführungskontextes vor der Ausgabe von Pipeline-Befehlen erforderlich, es sei denn, der Kontext soll Befehle für beide Pipelines ausgeben. In einigen Ausführungsformen ist ein Befehl Pipeline Leeren 912 unmittelbar vor einer Pipeline-Umschaltung über den Befehl Pipeline-Auswahl 913 erforderlich.
In einigen Ausführungsformen konfiguriert ein Befehl Pipeline-Steuerung 914 eine Grafik-Pipeline für den Betrieb und wird zum Programmieren der 3D-Pipeline 922 und der Medien-Pipeline 924 verwendet. In einigen Ausführungsformen konfiguriert der Befehl Pipeline-Steuerung 914 den Pipeline-Zustand für die aktive Pipeline. In einer Ausführungsform wird der Befehl Pipeline-Steuerung 914 zur Pipeline-Synchronisierung und zum Löschen von Daten aus einem oder mehreren Cache-Speichern innerhalb der aktiven Pipeline vor der Verarbeitung eines Befehlsstapels verwendet.
In einigen Ausführungsformen werden Befehle zum Rückgabepufferzustand 916 zum Konfigurieren eines Satzes von Rückgabepuffern für die entsprechenden Pipelines zum Schreiben von Daten verwendet. Einige Pipeline-Operationen erfordern die Zuordnung, Auswahl oder Konfiguration von einem oder mehreren Rückgabepuffern, in welche die Operationen Zwischendaten während der Verarbeitung schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückgabepuffer zum Speichern von Ausgabedaten und zum Durchführen von Cross-Thread-Kommunikation. In einigen Ausführungsformen umfasst der Rückgabepufferzustand 916 das Auswählen der Größe und der Zahl von Rückgabepuffern zur Verwendung für einen Satz von Pipeline-Operationen.
Die verbleibenden Befehle in der Befehlssequenz unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipeline-Bestimmung 920 wird die Befehlssequenz auf die 3D-Pipeline 922, beginnend mit dem 3D-Pipeline-Zustand 930, oder die Medien-Pipeline 924, beginnend mit dem Medien-Pipeline-Zustand 940, zugeschnitten.
Zu den Befehlen zum Konfigurieren des 3D-Pipeline-Zustands 930 zählen 3D-Zustand-Einstellbefehle für einen Vertex-Pufferzustand, einen Vertex-Elementzustand, einen Konstantfarbenzustand, einen Tiefenpufferzustand und andere Zustandsvariable, die konfiguriert werden sollen, bevor Befehle für 3D-Primitive verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise basierend auf der jeweils verwendeten 3D-API bestimmt. In einigen Ausführungsformen sind die Befehle zum 3D-Pipeline-Zustand 930 auch in der Lage, bestimmte Pipeline-Elemente selektiv zu deaktivieren oder zu umgehen, wenn diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird der Befehl 3D-Primitive 932 zum Bereitstellen von 3D-Primitiven verwendet, die durch die 3D-Pipeline verarbeitet werden sollen. Befehle und assoziierte Parameter, die über den Befehl 3D-Primitive 932 an den Grafikprozessor weitergegeben werden, werden an die Vertex-Abruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die Befehlsdaten für die 3D-Primitive 932 zum Erzeugen von Vertex-Datenstrukturen. Die Vertex-Datenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der Befehl 3D-Primitive 932 zum Durchführen von Vertex-Operationen an 3D-Primitiven über Vertex-Shader verwendet. Zum Verarbeiten von Vertex-Shadern versendet die 3D-Pipeline 922 Shader-Ausführungs-Threads an Ausführungseinheiten des Grafikprozessors.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Befehl Ausführen 934 oder ein Ereignis ausgelöst. In einigen Ausführungsformen löst ein Registerschreibvorgang die Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über einen ,Los'- oder „Start‟-Befehl in der Befehlssequenz ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipeline-Synchronisierungsbefehls zum Leeren der Befehlssequenz durch die Grafik-Pipeline ausgelöst. Die 3D-Pipeline führt dann die Geometrieverarbeitung für die 3D-Primitive durch. Nachdem die Operationen abgeschlossen wurden, werden die resultierenden geometrischen Objekte gerastert und die Pixelmaschine koloriert die resultierenden Pixel. Zusätzliche Befehle zum Steuern von Pixelschattierungs- und Pixel-Backend-Operationen können für diese Operationen auch enthalten sein.
In einigen Ausführungsformen folgt die Befehlssequenz 910 des Grafikprozessors dem Pfad der Medien-Pipeline 924, wenn Medienoperationen durchgeführt werden. Im Allgemeinen hängt die spezifische Verwendung und Art und Weise der Programmierung für die Medien-Pipeline 924 von den Medien- oder Berechnungsoperationen ab, die durchgeführt werden sollen. Spezifische Mediendecodierungsoperationen können während der Mediendecodierung in die Medien-Pipeline abgeladen werden. In einigen Ausführungsformen kann die Medien-Pipeline auch umgangen werden, und die Mediendecodierung kann als Ganzes oder in Teilen unter Verwendung von Ressourcen durchgeführt werden, die durch einen oder mehrere Universalverarbeitungskerne bereitgestellt werden. In einer Ausführungsform weist die Medien-Pipeline auch Elemente für Operationen einer Universal-Grafikprozessoreinheit (GPGPU - General-Purpose Graphics Processor Unit) auf, wobei der Grafikprozessor zum Durchführen von SIMD-Vektoroperationen unter Verwendung von Shader-Rechenprogrammen, die keinen expliziten Bezug zum Rendern von Grafikprimitiven haben, verwendet wird.
In einigen Ausführungsformen ist die Medien-Pipeline 924 in einer ähnlichen Art und Weise wie die 3D-Pipeline 922 konfiguriert. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipeline-Zustands 940 wird versendet oder vor den Medienobjekt-Befehlen 942 in eine Befehlswarteschlange platziert. In einigen Ausführungsformen umfassen Befehle für den Medien-Pipeline-Zustand 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medienobjekte verwendet werden. Dies beinhaltet Daten zum Konfigurieren der Videodecodierungs- und Videocodierungslogik innerhalb der Medien-Pipeline, wie z.B. ein Codierungs- oder Decodierungsformat. In einigen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Zustand 940 auch die Verwendung von einem oder mehreren Zeigern auf „indirekte“ Zustandselemente, die einen Stapel von Zustandseinstellungen enthalten.
In einigen Ausführungsformen stellen die Medienobjekt-Befehle 942 Zeiger auf Medienobjekte zur Verarbeitung durch die Medien-Pipeline zur Verfügung. Die Medienobjekte weisen Speicherpuffer auf, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medien-Pipeline-Zustände gültig sein, bevor ein Medienobjekt-Befehl 942 ausgegeben wird. Nachdem der Pipeline-Zustand konfiguriert wurde und die Medienobjekt-Befehle 942 aufgereiht sind, wird die Medien-Pipeline 924 über einen Befehl Ausführen 944 oder ein äquivalentes Ausführungsereignis (z.B. einen Registerschreibvorgang) ausgelöst. Die Ausgabe aus der Medien-Pipeline 924 kann dann durch Operationen nachbearbeitet werden, die durch die 3D-Pipeline 922 oder die Medien-Pipeline 924 bereitgestellt werden. In einigen Ausführungsformen werden GPGPU-Operationen in einer ähnlichen Art und Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafiksoftwarearchitektur
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß einigen Ausführungsformen. In einigen Ausführungsformen weist die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030 auf. In einigen Ausführungsformen weist der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Universalprozessorkern(e) 1034 auf. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programme, die Shader-Anweisungen 1012 umfassen. Die Shader-Sprachanweisungen können in einer Shader-Hochsprache vorliegen, wie z.B. der HLSL (High Level Shader Language) oder der GLSL (OpenGL Shader Language). Die Anwendung umfasst auch ausführbare Anweisungen 1014 in einer Maschinensprache, die zur Ausführung durch den Universalprozessorkern 1034 geeignet ist. Die Anwendung umfasst auch Grafikobjekte 1016, die durch Vertex-Daten definiert sind.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft®-Windows®-Betriebssystem von der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein Open-Source-UNIX-ähnliches Betriebssystem unter Verwendung einer Variante des Linux-Kernels. Das Betriebssystem 1020 kann eine Grafik-API 1022 unterstützen, wie z.B. die Direct3D-API, die OpenGL-API oder die Vulkan-API. Wenn die Direct3D-API zum Einsatz kommt, verwendet das Betriebssystem 1020 einen Frontend-Shader-Compiler 1024 zum Kompilieren jeglicher Shader-Anweisungen 1012 in HLSL in eine Shader-Sprache einer niedrigeren Ebene. Die Kompilierung kann eine JIT (Just-In-Time) -Kompilierung sein, oder die Anwendung kann Shader-Vorkompilierung durchführen. In einigen Ausführungsformen werden High-Level-Shader während der Kompilierung der 3D-Grafikanwendung 1010 zu Low-Level-Shadern kompiliert. In einigen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform bereitgestellt, wie z.B. einer Version der SPIR (Standard Portable Intermediate Representation), die durch die Vulkan-API verwendet wird.
In einigen Ausführungsformen enthält der Benutzermodus-Grafiktreiber 1026 einen Backend-Shader-Compiler 1027 zum Umwandeln der Shader-Anweisungen 1012 in eine Hardware-spezifische Darstellung. Wenn die OpenGL-API zum Einsatz kommt, werden die Shader-Anweisungen 1012 in der GLSL-Hochsprache zur Kompilierung an einen Benutzermodus-Grafiktreiber 1026 weitergegeben. In einigen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystem-Kernelmodus-Funktionen 1028 zum Kommunizieren mit einem Kernelmodus-Grafiktreiber 1029. In einigen Ausführungsformen kommuniziert der Kernelmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032 zum Versenden von Befehlen und Anweisungen.
IP-Kern-Implementierungen
Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, welcher Logik innerhalb einer integrierten Schaltung, wie z.B. eines Prozessors, darstellt und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Anweisungen umfassen, welche verschiedene Logik innerhalb des Prozessors darstellen. Wenn die Anweisungen durch eine Maschine gelesen werden, können sie die Maschine zum Herstellen der Logik zum Durchführen der hierin beschriebenen Techniken veranlassen. Derartige Darstellungen, bekannt als „IP-Kerne“, sind wiederverwendbare Einheiten von Logik für eine integrierte Schaltung, die als ein Hardware-Modell, das die Struktur der integrierten Schaltung beschreibt, auf einem greifbaren, maschinenlesbaren Medium gespeichert sein können. Das Hardware-Modell kann verschiedenen Kunden oder Herstellungseinrichtungen zur Verfügung gestellt werden, welche das Hardware-Modell auf Herstellungsmaschinen laden, welche die integrierte Schaltung herstellen. Die integrierte Schaltung kann derart hergestellt werden, dass die Schaltung Operationen durchführt, die im Zusammenhang mit jeglicher der hierin beschriebenen Ausführungsformen beschrieben sind.
11A ist ein Blockdiagramm, welches ein IP-Kern-Entwicklungssystem 1100 veranschaulicht, das zur Herstellung einer integrierten Schaltung zum Durchführen von Operationen gemäß einer Ausführungsform verwendet werden kann. Das IP-Kern-Entwicklungssystem 1100 kann zum Erzeugen modularer, wiederverwendbarer Designs verwendet werden, die in ein größeres Design integriert werden können oder zum Konstruieren einer kompletten integrierten Schaltung (z.B. einer integrierten Schaltung eines SoC) verwendet werden können. Eine Design-Einrichtung 1130 kann eine Software-Simulation 1110 eines IP-Kern-Designs in einer höheren Programmiersprache (z.B. C/C++) erzeugen. Die Software-Simulation 1110 kann zum Entwickeln, Testen und Verifizieren des Verhaltens des IP-Kerns unter Verwendung eines Simulationsmodells 1112 verwendet werden. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Zeitablaufsimulationen umfassen. Ein Registertransferlevel (RTL) -Design 1115 kann dann erstellt oder aus dem Simulationsmodell 1112 synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, welche den Fluss von digitalen Signalen zwischen Hardware-Registern modelliert, einschließlich der assoziierten Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs einer niedrigeren Ebene auf der Logikebene oder der Transistorebene erstellt, entwickelt oder synthetisiert werden. Somit können die jeweiligen Einzelheiten des Anfangsdesigns und der Simulation variieren.
Das RTL-Design 1115 oder ein Äquivalent kann durch die Design-Einrichtung weiter in ein Hardware-Modell 1120 synthetisiert werden, das in einer Hardware-Beschreibungssprache (HDL - Hardware Description Language) oder einer anderen Darstellung physischer Design-Daten vorliegen kann. Die HDL kann weiter simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann unter Verwendung von nichtflüchtigem Speicher 1140 (z.B. einer Festplatte, eines Flash-Speichers oder jeglichem nichtflüchtigem Speichermedium) zur Bereitstellung an eine Drittanbieter-Herstellungseinrichtung 1165 gespeichert werden. Alternativ dazu kann das IP-Kern-Design über eine verdrahtete Verbindung 1150 oder eine drahtlose Verbindung 1160 übertragen werden (z.B. über das Internet). Die Herstellungseinrichtung 1165 kann dann eine integrierte Schaltung herstellen, die zumindest teilweise auf dem IP-Kern-Design basiert. Die hergestellte integrierte Schaltung kann zum Durchführen von Operationen in Übereinstimmung mit mindestens einer hierin beschriebenen Ausführungsform konfiguriert werden.
11B veranschaulicht eine Querschnitt-Seitenansicht einer integrierten Schaltungsbaustein-Baugruppe 1170 gemäß einigen hierin beschriebenen Ausführungsformen. Die integrierte Schaltungsbaustein-Baugruppe 1170 veranschaulicht eine Implementierung von einem oder mehreren Prozessor- oder Beschleunigergeräten, wie hierin beschrieben. Die Package-Baugruppe 1170 weist mehrere Einheiten von Hardware-Logik 1172, 1174 verbunden mit einem Substrat 1180 auf. Die Logik 1172, 1174 kann zumindest teilweise in konfigurierbare Logik-Hardware oder Logik-Hardware mit fester Funktionalität implementiert sein und kann einen oder mehrere Abschnitte von jeglichen aus dem (den) hierin beschriebenen Prozessorkern(en), Grafikprozessor(en) oder anderen Beschleunigergeräten aufweisen. Jede Einheit von Logik 1172, 1174 kann innerhalb eines Halbleiter-Dies implementiert sein und über eine Verbindungsstruktur 1173 mit dem Substrat 1180 gekoppelt sein. Die Verbindungsstruktur 1173 kann zum Routen elektrischer Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 konfiguriert sein und kann Verbindungen aufweisen, wie z.B., jedoch nicht darauf beschränkt, Lotpunkte oder Säulen. In einigen Ausführungsformen kann die Verbindungsstruktur 1173 zum Routen elektrischer Signale konfiguriert sein, wie zum Beispiel Eingabe/Ausgabe (E/A) -Signale und/oder Strom- oder Massesignale im Zusammenhang mit dem Betrieb der Logik 1172, 1174. In einigen Ausführungsformen ist das Substrat 1180 ein Mehrschichtsubstrat auf Epoxidbasis. Das Package-Substrat 1180 kann in anderen Ausführungsformen auch andere geeignete Arten von Substraten aufweisen. Die Package-Baugruppe 1170 kann über einen Package-Verbindung 1183 auch mit anderen elektrischen Geräten verbunden sein. Die Package-Verbindung 1183 kann an eine Oberfläche des Substrates 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Geräten zu routen, wie z.B. einem Motherboard, einem anderen Chipsatz oder einem Multi-Chip-Modul.
In einigen Ausführungsformen sind die Einheiten von Logik 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die zum Routen elektrischer Signale zwischen der Logik 1172, 1174 konfiguriert ist. Die Brücke 1182 kann eine dichte Verbindungsstruktur sein, die einen Pfad für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat aufweisen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Routing-Merkmale können auf dem Brückensubstrat ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Obwohl zwei Einheiten von Logik 1172, 1174 und eine Brücke 1182 veranschaulicht sind, können hierin beschriebene Ausführungsformen auch mehr oder weniger Logikeinheiten auf einem oder mehreren Dies aufweisen. Der eine oder die mehreren Dies können durch null oder mehr Brücken verbunden sein, da die Brücke 1182 möglicherweise nicht vorliegt, wenn die Logik auf einem einzelnen Die enthalten ist. Alternativ dazu können mehrere Dies oder Einheiten von Logik durch eine oder mehrere Brücken verbunden sein. Außerdem können mehrere Logikeinheiten, Dies und Brücken in anderen möglichen Konfigurationen, einschließlich dreidimensionaler Konfigurationen, zusammengeschlossen sein.
Beispielhafte integrierte Schaltung eines Ein-Chip-Systems
12-14 veranschaulichen beispielhafte integrierte Schaltungen und assoziierte Grafikprozessoren, die gemäß verschiedenen hierin beschriebenen Ausführungsformen unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden können. Zusätzlich zu dem, was veranschaulicht ist, können auch andere Logik und Schaltungen enthalten sein, einschließlich zusätzlicher Grafikprozessoren/-kerne, Peripherieschnittstellen-Controller oder Universalprozessorkerne.
12 ist ein Blockdiagramm, welches eine beispielhafte integrierte Schaltung eines Ein-Chip-Systems 1200 veranschaulicht, die gemäß einer Ausführungsform unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann. Die beispielhafte integrierte Schaltung 1200 weist einen oder mehrere Anwendungsprozessor(en) 1205 (z.B. CPUs) und mindestens einen Grafikprozessor 1210 auf und kann außerdem einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 aufweisen, wobei es sich bei jedem davon um einen modularen IP-Kern von der gleichen oder mehreren unterschiedlichen Design-Einrichtungen handeln kann. Die integrierte Schaltung 1200 weist Peripherie- oder Buslogik auf, einschließlich eines USB-Controllers 1225, eines UART-Controllers 1230, eines SPI/SDIO-Controllers 1235 und eines I2S/I2C-Controllers 1240. Außerdem kann die integrierte Schaltung ein Anzeigegerät 1245 aufweisen, das an eines oder mehrere aus einem HDMI (High-Definition Multimedia Interface) -Controller 1250 und einer MIPI (Mobile Industry Processor Interface) -Anzeigeschnittstelle 1255 gekoppelt ist. Speicherung kann durch ein Flash-Speicher-Untersystem 1260 bereitgestellt werden, das Flash-Speicher und einen Flash-Speicher-Controller aufweist. Eine Speicherschnittstelle zum Zugriff auf SDRAM- oder SRAM-Speichergeräte kann über einen Speicher-Controller 1265 bereitgestellt werden. Einige integrierte Schaltungen weisen außerdem eine eingebettete Sicherheitsmaschine 1270 auf.
13A-13B sind Blockdiagramme, welche beispielhafte Grafikprozessoren zur Verwendung innerhalb eines SoC gemäß hierin beschriebenen Ausführungsformen veranschaulichen. 13A veranschaulicht einen beispielhaften Grafikprozessor 1310 einer integrierten Schaltung eines Ein-Chip-Systems, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform. 13B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 1340 einer integrierten Schaltung eines Ein-Chip-Systems, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform. Der Grafikprozessor 1310 von 13A ist ein Beispiel eines Grafikprozessorkerns mit niedrigem Energieverbrauch. Der Grafikprozessor 1340 von 13B ist ein Beispiel eines Grafikprozessorkerns mit höherer Leistung. Bei jedem der Grafikprozessoren 1310, 1340 kann es sich um Varianten des Grafikprozessors 1210 von 12 handeln.
Wie in 13A gezeigt, weist der Grafikprozessor 1310 einen Vertex-Prozessor 1305 und einen oder mehrere Fragmentprozessor(en) 1315A-1315N (z.B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N) auf. Der Grafikprozessor 1310 kann unterschiedliche Shader-Programme über separate Logik ausführen, derart, dass der Vertex-Prozessor 1305 zum Ausführen von Operationen für Vertex-Shader-Programme optimiert wird, während der eine oder die mehreren Fragmentprozessor(en) 1315A-1315N Fragment (z.B. Pixel) - Schattierungsoperationen für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertex-Prozessor 1305 führt die Vertex-Verarbeitungsstufe der 3D-Grafik-Pipeline durch und erzeugt Primitiven- und Vertex-Daten. Der (Die) Fragmentprozessor(en) 1315A-1315N verwendet (verwenden) die Primitiven- und Vertex-Daten, die durch den Vertex-Prozessor 1305 erzeugt werden, zum Erzeugen eines Framebuffers, der auf einem Anzeigegerät angezeigt wird. In einer Ausführungsform ist der (sind die) Fragmentprozessor(en) 1315A-1315N zum Ausführen von Fragment-Shader-Programmen optimiert, wie sie in der OpenGL-API bereitgestellt werden, welche zum Durchführen ähnlicher Operationen wie bei einem Pixel-Shader-Programm, wie es in der Direct3D-API bereitgestellt wird, verwendet werden können.
Der Grafikprozessor 1310 weist außerdem eine(n) oder mehrere Speichermanagementeinheiten (MMUs - Memory Management Units) 1320A-1320B, Cache(s) 1325A-1325B und Schaltungsverbindung(en) 1330A-1330B auf. Die eine oder die mehreren MMU(s) 1320A-1320B sorgen für eine Virtuell-zu-Physisch-Adressabbildung für den Grafikprozessor 1310, einschließlich für den Vertex-Prozessor 1305 und/oder den (die) Fragmentprozessor(en) 1315A-1315N, welche auf Vertex- oder Bild-/Texturdaten, die im Speicher gespeichert sind, verweisen kann, zusätzlich zu Vertex- oder Bild-/Texturdaten, die in dem einen oder den mehreren Cache(s) 1325A-1325B gespeichert sind. In einer Ausführungsform können die eine oder die mehreren MMU(s) 1320A-1320B mit anderen MMUs innerhalb des Systems synchronisiert sein, einschließlich einer oder mehreren MMUs, die mit dem einen oder den mehreren Anwendungsprozessor(en) 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 von 12 assoziiert sind, derart, dass jeder Prozessor 1205-1220 an einem gemeinsam genutzten oder einheitlichen virtuellen Speichersystem teilnehmen kann. Die eine oder die mehreren Schaltungsverbindung(en) 1330A-1330B ermöglichen dem Grafikprozessor 1310 die Schnittstellenbildung mit anderen IP-Kernen innerhalb des SoC, gemäß Ausführungsformen entweder über einen internen Bus des SoC oder über eine direkte Verbindung.
Wie in 13B gezeigt, weist der Grafikprozessor 1340 die eine oder die mehreren MMU(s) 1320A-1320B, die Caches 1325A-1325B und die Schaltungsverbindungen 1330A-1330B des Grafikprozessors 1310 von 13A auf. Der Grafikprozessor 1340 weist einen oder mehrere Shader-Kern(e) 1355A-1355N (z.B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N) auf, wodurch für eine einheitliche Shader-Kernarchitektur gesorgt wird, in welcher ein einzelner Kern oder Kerntyp alle Arten von programmierbarem Shader-Code ausführen kann, einschließlich Shader-Programmcode zum Implementieren von Vertex-Shadern, Fragment-Shadern und/oder Rechen-Shadern. Die genaue Zahl von vorliegenden Shader-Kernen kann zwischen Ausführungsformen und Implementierungen variieren. Außerdem weist der Grafikprozessor 1340 einen Zwischenkern-Aufgabenmanager 1345, welcher als ein Thread-Dispatcher zum Versenden von Ausführungs-Threads an einen oder mehrere Shader-Kerne 1355A-1355N agiert, und eine Tiling-Einheit 1358 zum Beschleunigen von Tiling-Operationen für kachelbasiertes Rendern auf, in welcher Render-Operationen für eine Szene im Bildraum unterteilt werden, um zum Beispiel eine lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder die Verwendung interner Caches zu optimieren.
14A-14B veranschaulichen zusätzliche beispielhafte Grafikprozessorlogik gemäß hierin beschriebenen Ausführungsformen. 14A veranschaulicht einen Grafikkern 1400, der innerhalb des Grafikprozessors 1210 von 12 enthalten sein kann, und es kann sich dabei um einen einheitlichen Shader-Kern 1355A-1355N wie in 13B handeln. 14B veranschaulicht eine zusätzliche hochparallele Universal-Grafikverarbeitungseinheit 1430, bei welcher es sich um eine hochparallele Universal-Grafikverarbeitungseinheit handelt, die zum Einsatz auf einem Multi-Chip-Modul geeignet ist.
Wie in 14A gezeigt, weist der Grafikkern 1400 einen gemeinsam genutzten Anweisungs-Cache 1402, eine Textureinheit 1418 und einen Cache/gemeinsam genutzten Speicher 1420 auf, die den Ausführungsressourcen innerhalb des Grafikkerns 1400 gemeinsam sind. Der Grafikkern 1400 kann mehrere Slices 1401A-1401N oder Partitionen für jeden Kern aufweisen, und ein Grafikprozessor kann mehrere Instanzen des Grafikkerns 1400 aufweisen. Die Slices 1401A-1401N können Unterstützungslogik aufweisen, einschließlich eines lokalen Anweisungs-Caches 1404A-1404N, eines Thread-Schedulers 1406A-1406N, eines Thread-Dispatchers 1408A-1408N und eines Satzes von Registern 1410A-1410N. Zum Durchführen von Logikoperationen können die Slices 1401A-1401N einen Satz zusätzlicher Funktionseinheiten (AFUs - Additional Function Units - 1412A-1412N), Gleitkommaeinheiten (FPUs - Floating-Point Units - 1414A-1414N), Ganzzahl-Arithmetik-Logikeinheiten (ALUs - Arithmetic Logic Units - 1416-1416N), Adressberechnungseinheiten (ACUs - Address Computational Units - 1413A-1413N), Gleitkommaeinheiten mit doppelter Genauigkeit (DPFPUs - Double-Precision Floating-Point Units - 1415A-1415N) und Matrixverarbeitungseinheiten (MPUs - Matrix Processing Units - 1417A-1417N) aufweisen.
Einige der Recheneinheiten arbeiten mit einer spezifischen Genauigkeit. Zum Beispiel können die FPUs 1414A-1414N Gleitkommaoperationen mit einfacher Genauigkeit (32-Bit) und halber Genauigkeit (16-Bit) durchführen, während die DPFPUs 1415A-1415N Gleitkommaoperationen mit doppelter Genauigkeit (64-Bit) durchführen. Die ALUs 1416A-1416N können Ganzzahloperationen mit variabler Genauigkeit mit 8-Bit-, 16-Bit- und 32-Bit-Genauigkeit durchführen und können für Operationen mit gemischter Genauigkeit konfiguriert sein. Die MPUs 1417A-1417N können auch für Operationen mit gemischter Genauigkeit konfiguriert sein, einschließlich Gleitkommaoperationen mit halber Genauigkeit und 8-Bit-Ganzzahloperationen. Die MPUs 1417-1417N können eine Vielzahl von Matrixoperationen zum Beschleunigen von Maschinenlernen-Anwendungsframeworks durchführen, einschließlich des Ermöglichens von Unterstützung für beschleunigte allgemeine Matrix-zu-Matrix-Multiplikation (GEMM - General Matrix to Matrix Multiplication). Die AFUs 1412A-1412N können zusätzliche Logikoperationen durchführen, die nicht durch die Gleitkomma- oder Ganzzahleinheiten unterstützt werden, einschließlich trigonometrischer Operationen (z.B. Sinus, Cosinus usw.).
Wie in 14B gezeigt, kann eine Universal-Grafikverarbeitungseinheit (GPGPU - General-Purpose Graphics Processing Unit) 1430 zum Ermöglichen hochparalleler Rechenoperationen konfiguriert sein, die durch eine Anordnung von Grafikverarbeitungseinheiten durchgeführt werden sollen. Außerdem kann die GPGPU 1430 direkt mit anderen Instanzen der GPGPU verknüpft sein, um ein Multi-GPU-Cluster zur Verbesserung der Trainingsgeschwindigkeit für besonders tiefe neuronale Netzwerke zu erzeugen. Die GPGPU 1430 weist eine Host-Schnittstelle 1432 zum Ermöglichen einer Verbindung mit einem Host-Prozessor auf. In einer Ausführungsform ist die Host-Schnittstelle 1432 eine PCI Express-Schnittstelle. Jedoch kann die Host-Schnittstelle auch eine herstellerspezifische Kommunikationsschnittstelle oder Kommunikationsstruktur sein. Die GPGPU 1430 empfängt Befehle vom Host-Prozessor und verwendet einen globalen Scheduler 1434 zum Verteilen von Ausführungs-Threads, die mit diesen Befehlen assoziiert sind, an einen Satz von Rechenclustern 1436A-1436H. Die Rechencluster 1436A-1436H nutzen einen Cache-Speicher 1438 gemeinsam. Der Cache-Speicher 1438 kann als ein Cache höherer Ebene für Cache-Speicher innerhalb der Rechencluster 1436A-1436H dienen.
Die GPGPU 1430 weist die Speicher 14434A-14434B auf, die über einen Satz von Speicher-Controllern 1442A-1442B mit den Rechenclustern 1436A-1436H gekoppelt sind. In verschiedenen Ausführungsformen kann der Speicher 1434A-1434B verschiedene Arten von Speichergeräten aufweisen, einschließlich DRAM (Dynamic Random Access Memory) oder GRAM (Graphics Random Access Memory), wie z.B. SGRAM (Synchronous Graphics Random Access Memory), einschließlich GDDR (Graphics Double Data Rate) - Speicher.
In einer Ausführungsform weisen die Rechencluster 1436A-1436H jeweils einen Satz von Grafikkernen auf, wie z.B. den Grafikkern 1400 von 14A, welche mehrere Arten von Ganzzahl- und Gleitkomma-Logikeinheiten aufweisen können, die Rechenoperationen in einem Bereich von Genauigkeiten durchführen können, einschließlich einer Eignung für Maschinenlernen-Berechnungen. Zum Beispiel kann in einer Ausführungsform mindestens eine Teilmenge der Gleitkommaeinheiten in jedem der Rechencluster 1436A-1436H zum Durchführen von 16-Bit- oder 32-Bit-Gleitkommaoperationen konfiguriert sein, während eine unterschiedliche Teilmenge der Gleitkommaeinheiten zum Durchführen von 64-Bit-Gleitkommaoperationen konfiguriert sein kann.
Mehrere Instanzen der GPGPU 1430 können zum Arbeiten als ein Rechencluster konfiguriert sein. Der durch das Rechencluster für Synchronisierung und Datenaustausch verwendete Kommunikationsmechanismus variiert über die Ausführungsformen hinweg. In einer Ausführungsform kommunizieren die mehreren Instanzen der GPGPU 1430 über die Host-Schnittstelle 1432. In einer Ausführungsform weist die GPGPU 1430 einen E/A-Hub 1439 auf, der die GPGPU 1430 mit einer GPU-Verknüpfung 1440 koppelt, die eine direkte Verbindung zu anderen Instanzen der GPGPU ermöglicht. In einer Ausführungsform ist die GPU-Verknüpfung 1440 an eine dedizierte GPUzu-GPU-Brücke gekoppelt, die Kommunikation und Synchronisierung zwischen mehreren Instanzen der GPGPU 1430 ermöglicht. In einer Ausführungsform ist die GPU-Verknüpfung 1440 mit einer Hochgeschwindigkeitsverbindung zum Senden und Empfangen von Daten an andere/von anderen GPGPUs oder parallele/n Prozessoren gekoppelt. In einer Ausführungsform befinden sich die mehreren Instanzen der GPGPU 1430 in separaten Datenverarbeitungssystemen und kommunizieren über ein Netzwerkgerät, das über die Host-Schnittstelle 1432 zugänglich ist. In einer Ausführungsform kann die GPU-Verknüpfung 1440 zum Ermöglichen einer Verbindung zu einem Host-Prozessor zusätzlich oder als eine Alternative zu der Host-Schnittstelle 1432 konfiguriert sein.
Während die veranschaulichte Konfiguration der GPGPU 1430 zum Trainieren neuronaler Netzwerke konfiguriert sein kann, sieht eine Ausführungsform eine alternative Konfiguration der GPGPU 1430 vor, die für einen Einsatz innerhalb einer Hochleistungs- oder Energiespar-Inferenzplattform konfiguriert werden kann. In einer Inferenzkonfiguration weist die GPGPU 1430 weniger der Rechencluster 1436A-1436H relativ zu der Trainingskonfiguration auf. Außerdem kann sich die Speichertechnologie, die mit dem Speicher 1434A-1434B assoziiert ist, zwischen Inferenz- und Trainingskonfigurationen unterscheiden, wobei für Trainingskonfigurationen Speichertechnologien mit höherer Bandbreite eingesetzt werden. In einer Ausführungsform kann die Inferenzkonfiguration der GPGPU 1430 Inferenz-spezifische Anweisungen unterstützen. Zum Beispiel kann eine Inferenzkonfiguration Unterstützung für eine oder mehrere 8-Bit-Ganzzahl-Punktprodukt-Anweisungen bereitstellen, welche üblicherweise während Inferenzoperationen für eingesetzte neuronale Netzwerke verwendet werden.
VORRICHTUNG UND VERFAHREN FÜR EINE VIRTUALISIERTE ANZEIGE
Wie oben beschrieben, wird die Single-Root-E/A-Virtualisierung (SR-IOV) heute zur Implementierung einer virtualisierten Grafikverarbeitungseinheit (GPU) verwendet. Dies wird durch das Definieren eines virtualisierten PCI Express (PCIe) -Gerätes zum Anzeigen einer physischen Funktion (PF) sowie einer Reihe virtueller Funktionen (VFs) auf dem PCIe-Bus erreicht.
In einem derartigen System wird das VF-Anzeigemodell zum Antreiben lokaler Anzeigefunktionalitäten in einer virtuellen Maschine (VM) durch das direkte Posten des Gast-Framebuffers auf den lokalen Monitor oder das Anzeigen der Gast-Framebuffer-Informationen für den Host verwendet. Zum Beispiel gibt es bei aktuellen Bord-Infotainment (IVI) -Systemen einen Trend zur Verwendung von Virtualisierungstechnologie zur Konsolidierung eines sicherheitskritischen Clusters digitaler Instrumente, welche Sicherheitsmetriken (z.B. Geschwindigkeit, Drehzahl und so weiter) anzeigen, zusammen mit einigen IVI-Systemen, die Infotainment-Apps anzeigen. Bei einer derartigen Architektur teilt die GPU ihre Rechen- und Anzeigefähigkeiten mit unterschiedlichen VMs, derart, dass jede VM ihre graphische Benutzerschnittstelle direkt auf das assoziierte Anzeigefeld posten kann.
Bei einem Anwendungsfall mit einem Cloud-Server zeigt die vorgelagerte Anzeige den Gast-Framebuffer als einen DMA-BUF-Dateideskriptor für den Host-Benutzerraum an. Auf den Gast-Framebuffer kann dann zugegriffen werden, und er kann über ein entferntes Protokoll durch vorhandene Medien- oder Grafikstapel auf der Host-Seite gerendert und/oder gestreamt werden.
15 hebt hervor, wie eine GPU 1540, auf die mit einer virtuellen Funktion 1521 zugegriffen wird, nicht in der Lage ist, ihre Anzeigeanforderungen in der PF 1510 auf die lokale Anzeige-Hardware 1515 zu posten (wie durch das große X angegeben). Die GPU 1540 kann auch nicht in Fernanzeigekonfigurationen verwendet werden, welche einen Framebuffer einer Gast-VM 1540 von einem VF-Treiber 1541 für einen entfernten Protokollserver 1530 anzeigen müssen, der auf der Host-Seite läuft. In diesen Fällen, ohne das Anzeigemodell, kann die GPU 1540 weder die lokale Anzeige direkt antreiben noch kann sie ihren Anzeige-Framebuffer auf die Host-Seite posten.
Die Ausführungsformen der Erfindung umfassen ein virtuelles Paravirtualisierungs- (PV) Anzeigemodell zum Bereitstellen einer Hardware-virtualisierten GPU (z.B. einer Hardware-virtualisierten Gen12 SR-IOV-GPU) mit der Fähigkeit zum direkten Posten eines Gast-Framebuffers auf den lokalen Hardware-Anzeigemonitor oder zum gemeinsamen Nutzen des Gast-Framebuffers mit der Host-Seite durch das Anzeigen von Gast-Framebuffer-Informationen. Während hierin spezifische Implementierungen beschrieben sind, wie z.B. Gen12 SR-IOV, sind die Ausführungsformen der Erfindung auf keine bestimmte Implementierung beschränkt.
Unter Verwendung der unten beschriebenen Techniken können die virtuellen Maschinen (VMs) unterschiedliche Arten von Betriebssystemen (BSs) unterstützen, einschließlich eines oder mehrerer Echtzeit-Betriebssysteme (RTOSs - Real Time Operating Systems). Diese BSs können Framebuffer während Gast-„Umblätter“-Operationen durch eine Framebuffer-Deskriptorseite, die Gast-Anzeigeanforderungen enthält, direkt auf die zugewiesenen lokalen Anzeigefelder posten. Diese Ausführungsform verwendet ein Backend-Anzeigemodell, welches einen Backend-Anzeigedienst in einem Dienst-BS aufruft, um die Hardware-Anzeige durch einen Treiber einer physischen Funktion im Auftrag der virtuellen Funktion gemäß dem geposteten Framebuffer-Deskriptor zu konfigurieren.
16 veranschaulicht eine derartige Ausführungsform, welche ein virtuelles Anzeigemodell für ein Bord-Infotainment (IVI) -System implementiert. In der veranschaulichten Ausführungsform werden ein Echtzeit-BS (RTOS) 1670 und assoziierte Apps 1680 durch eine primäre Dienst/Host-VM 1601 unterstützt, die Instrumentencluster-Apps 1681 werden auf einem RTOS 1671 innerhalb einer Instrumentencluster-VM 1602 ausgeführt, die vorderen Infotainment-Apps 1682 werden auf einem Linux/Android-BS 1672 innerhalb einer vorderen Infotainment-VM 1603 ausgeführt und die hinteren Infotainment-Apps 1683 werden auf einem Linux/Android-BS 1673 innerhalb einer hinteren Infotainment-VM 1604 ausgeführt.
Jede/s der virtuellen Maschinen 1601-1604 und assoziierten Gast-Betriebssysteme 1670-1673 wird durch einen Hypervisor 1650 (gelegentlich auch als ein Monitor der virtuellen Maschine (VMM - Virtual Machine Monitor) bezeichnet) gemanagt, welcher Zugriff auf die Grafikausführungsressourcen einer GPU 1648 und eines Anzeigeuntersystems 1630 bereitstellt, welches mehrere Pipes 1620-1622 aufweist, von welchen jede mehrere Ebenen aufweist (in dem Beispiel z.B. die Ebenen 0-7). Wie hierin verwendet, steht eine „Pipe“ für einen Satz von Verarbeitungsressourcen, die zum Verarbeiten von Videoframes im Auftrag einer virtuellen Maschine zugeordnet werden, und eine „Ebene“ umfasst einen bestimmten einen oder mehrere Videoframes oder Kacheln von Videoframes, welche eine Ansicht definieren, die auf der Anzeige 1630 (in einer Ausführungsform z.B. eine Bordanzeige) gerendert werden soll.
In einer Ausführungsform managen die Backend-Dienste 1661, die innerhalb des RTOS 1670 der Dienst/Host-VM 1601 laufen, den Zugriff auf physische Verarbeitungsressourcen durch die anderen VMs. Zum Beispiel können die Backend-Dienste 1661 die verschiedenen Verarbeitungsressourcen der GPU 1648 und der Anzeige 1630 unterschiedlichen VMs 1601-1604 zuordnen. In der veranschaulichten Ausführungsform wurde der Instrumentencluster-VM 1602 Pipe 0 (1620) zugewiesen, der vorderen Infotainment-VM 1603 wurde Pipe 1 (1621) zugewiesen und der hinteren Infotainment-VM 1604 wurde Pipe 2 (1622) zugewiesen.
Jedes Betriebssystem weist einen zugewiesenen Grafiktreiber für den Zugriff auf die Grafikverarbeitungsressourcen der GPU 1648 und der Anzeige 1630 auf. Das RTOS 1670 der Dienst/Host-VM 1601 weist zum Beispiel einen Host-GPU-Treiber 1660 auf (welcher in einer Ausführungsform kein virtueller Treiber ist). Die Betriebssysteme 1671-1673 der anderen VMs 1602-1604 weisen jeweils die Treiber der virtuellen Funktion (VFDs - Virtual Function Drivers) 1662-1664 auf, von welchen jeder entsprechend eine Treiberkomponente der virtuellen Anzeige (VDD - Virtual Display Driver) 1665-1667 aufweist. In einer Ausführungsform wird ein Framebuffer-Deskriptor (FBD) 1668-1651, der entsprechend durch jeden VDD 1665-1667 gepflegt wird, zum Konfigurieren der Anzeige 1630 im Auftrag jedes Gastes 1671-1673 verwendet (wie unten detaillierter beschrieben).
Die GPU 1648 in 16 weist ein Basisadressregister der physischen Funktion (PF-BAR - Physical Function Base Address Register) 1640, auf das durch den Host-GPU-Treiber 1660 zugegriffen werden kann, und einen Satz von Basisadressregistern der virtuellen Funktion (VF-BARs - Virtual Function Base Address Registers) 1645-1647 auf, welche jeweils mit einer unterschiedlichen virtuellen Funktion (VF) 1641-1643 assoziiert sind bzw. die für einen entsprechenden Treiber der virtuellen Funktion 1662-1664 zugänglich sind.
Da die VMs 1602-1604 keine Kenntnis von der virtualisierten Ausführungsumgebung haben, fängt der Hypervisor 1650 Anweisungen/Befehle, die von den VDDs 1665-1667 erzeugt werden, ab und ruft die Backend-Dienste 1661 in der Dienst/Host-VM 1601 auf, um die Hardware-Anzeige durch den Host-GPU-Treiber 1660 (einen PF-Treiber) im Auftrag des anfragenden Treibers der virtuellen Funktion 1662-1664 in Übereinstimmung mit dem geposteten Framebuffer-Deskriptor zu konfigurieren. Im Betrieb kann jede VM 1601-1604 ihren Framebuffer während einer Gast-Umblätter-Operation direkt auf die zugewiesenen lokalen Anzeigefelder posten, unter Ausnutzung des entsprechenden Framebuffer-Deskriptors (FBD) 1668-1651, welcher die erforderliche Anzeigekonfiguration spezifiziert.
Wie bereits erwähnt, wird eine Ausführungsform des virtuellen Anzeigemodells durch die Dienst/Host-VM 1601 konfiguriert und gefüllt, bevor es durch die Treiber der virtuellen Funktion 1662-1664 verwendet werden kann. In einer spezifischen Implementierung kann dies unter Verwendung der PV_INFO-Register erreicht werden, welche nur für die Virtualisierung Bedeutung haben. 17 veranschaulicht die relevanten virtuellen Anzeigefelder in den PVINFO-Registern, zu welchen ein Feld Framebuffer-Deskriptorbasis 1701 zum Identifizieren einer physischen Adresse für die Anzeige-Deskriptorseite des Gastes zählt (welches z.B. die relevanten Framebuffer-Deskriptoren 1668-1651 enthält).
Eine Ausführungsform der Erfindung kann mehr Ebenen oder Pipes zuordnen, als durch die physische Hardware unterstützt werden. Zum Beispiel können, unter Verwendung von acht als die maximale Zahl, jeder VF 1641-1643 höchstens acht Anzeigen zugeordnet werden, wobei jede Anzeige zum Anzeigen von bis zu acht Framebuffern zusammen in einer Gast-Umblätter-Transaktion konfiguriert ist. Diese Zahl lässt sich leicht erhöhen, wenn in praktischen Anwendungsfällen mehr Anzeigen benötigt werden.
Die Dienst/Host-VM 1601 kann verschiedene Arten von Anzeigemodus-Einstellungen konfigurieren. In einer Ausführungsform wird die Anzeigemodus-Einstellung 0 durch den Treiber der virtuellen Anzeige 1665-1667 als die bevorzugte Modus-Einstellung behandelt. Die Host-VM 1601 kann die Anzeigemodus-Einstellungen füllen, welche nicht mit Nullen verwendet werden.
In einer Ausführungsform sammelt, wenn ein Gast in einer VM mit Unterstützung des virtuellen VF-Anzeigemodells gestartet wird, der Treiber der virtuellen Anzeige 1665-1667 zunächst die virtuellen Anzeigeinformationen durch das Lesen der PV_INFO-Register, die durch die Host-VM 1601 gefüllt werden, und erstellt dann die Anzeigeobjekte gemäß diesen virtuellen Anzeigeinformationen. Zum Beispiel wird, wenn die Dienst/Host-VM 1601 die auf die virtuelle Anzeige bezogenen Felder in PV_INFO für die Instrumentencluster-VM 1602 mit zwei Pipes und drei Ebenen und einem Anzeigemodus füllt, das Anzeigemodell der VM 1602 wie in 18 gezeigt präsentiert. Aus Sicht des Gast-BS 1671 umfassen jede virtuelle Anzeige-Pipe 1805, 1815 zusammen mit ihren zugehörigen Ebenen 1801-1803, 1811-1813, der dedizierte virtuelle Encoder 1821, 1822, die Speicherschnittstelle 1800, 1810 bzw. das virtuelle Verbindungselement 1831, 1832 ein Anzeigesteuerungsuntersystem auf Treiberebene. In einer Ausführungsform wird die eigene Schnittstelle jedes Objektes in dem Untersystem durch das Anzeigeframework in dem Gast-BS 1671 aufgerufen, um die Gast-Anzeigeanforderungen zu implementieren. Die hierin beschriebenen Ausführungsformen des Treibers der virtuellen Anzeige behalten diese Anforderungen nur im Speicher, wenn die Schnittstellen aufgerufen werden, und stellen die Anforderungen während einer Umblätter-Operation des Gast-BS 1671 im Framebuffer-Deskriptor 1668 zur Verfügung.
Wieder bezugnehmend auf die Instrumentencluster-VM 1602 (obwohl die gleichen Prinzipien auch für die anderen VMs 1603-1604 gelten), verwendet sie, wenn der Treiber der virtuellen Anzeige 1665 des Gastes ein Umblättern durchführt, die Framebuffer-Deskriptorseite (welche die Daten des FBD 1668 enthält) zum Speichern der Framebuffer-Informationen und schreibt die Adresse der Framebuffer-Deskriptorseite in das Feld Framebuffer-Deskriptorbasis 1701 in der PV_INFO-Datenstruktur. Wie in 16 angegeben, wird diese Operation durch den Hypervisor 1650 abgefangen, welcher die Anzeige-Backend-Dienste 1661 (z.B. den PF-Treiber) aufruft, um die Anzeige-Hardware gemäß den Aktualisierungen auf der Framebuffer-Deskriptorseite zu konfigurieren.
19 veranschaulicht eine Ausführungsform einer Framebuffer-Deskriptorseite 2001, die spezifische Datenfelder aufweist, die innerhalb eines Framebuffer-Deskriptorseiteneintrags 2902 enthalten sind (z.B. für Pipe 0 und Ebene 0). Beispielhaft und nicht einschränkend enthalten die Datenfelder die/den Ebenenposition, -versatz, -schritt und -größe und die Pipe-Fensterposition und - größe. Innerhalb der Deskriptorseite 1901 können auch verschiedene andere Datenarten spezifiziert werden, während weiterhin die zugrundliegenden Grundsätze der Erfindung erfüllt werden.
In einer Ausführungsform kann eine gesamte Pipe vollständig einer VM zugewiesen sein, was als Vollmodus-Einstellung bezeichnet wird (unter der Annahme, dass eine derartige Gast-Einstellung gestattet ist). Sowohl Vollmodus-Einstellung als auch Anzeigeumblättern werden durch das Aufrufen des Treibers der physischen Funktion 1660 des Hostes auf atomische Weise konfiguriert, um sicherzustellen, dass die Konfiguration in einer Transaktion durchgeführt werden kann.
In einer Ausführungsform werden Anzeigeunterbrechungen in die Ziel-VM 1601-1604 eingeführt. In einer Ausführungsform werden unterschiedliche Arten von Unterbrechungen unterstützt, einschließlich einer Unterbrechung ausgelöst durch virtuelles Umblättern als Reaktion auf eine virtuelle Umblätter-Operation und einer physischen Umblätter-Unterbrechung als Reaktion auf eine physische Umblätter-Unterbrechung. Bei einer virtuellen Gast-Anzeige ohne jegliche zugewiesenen physischen Ebenen wird die durch virtuelles Umblättern abgeschlossene Unterbrechung periodisch gemäß einem Timer eingeführt. Bei einer virtuellen Gast-Anzeige mit zugewiesenen physischen Ebenen wird eine durch Umblättern abgeschlossene Unterbrechung während der Ausführung eines physischen Interrupt-Handlers eingeführt.
Im Vergleich zu bestehenden Systemen, welche eine Hardware-Anzeigemaschine exklusiv an eine virtuelle Funktion bereitstellen, sind die Ausführungsformen der Erfindung signifikant skalierbarer und bieten effiziente Anzeigeunterstützung in einer Virtualisierungsumgebung (d.h. nicht begrenzt durch die geräteunterstützte #SRIOV-Funktion). Diese Ausführungsformen können auch in Arten von Systemen mit unterschiedlichen Merkmalen verwendet werden, einschließlich, jedoch nicht darauf beschränkt, SR-IOV, skalierbarer IOV und Container-Modellen, ohne dass Veränderungen an der Geräte-Hardware notwendig sind.
Eine Implementierung des Anzeigemodells einer vollständig virtualisierten physischen Funktion kann einige der obigen Vorteile erzielen. Jedoch würde dies einen hohen Engineering-Aufwand zur Behandlung von Problemen bedeuten, wie z.B. der Virtualisierung unterschiedlicher Arten von Anzeigeanschlussregistern. Diese spezifischen Details sind nicht notwendig, um die Gast-Anzeigeanforderungen zu erfüllen, und können in Leistungsproblemen resultieren.
Die Ausführungsformen der Erfindung können auch mit bestehenden vorgelagerten Kernel-basierten virtuellen Maschinen und E/A-Virtualisierungsanzeigen (z.B. VFIO) in einem Cloud-Server oder einem anderen Rechengerät verwendet werden. Eine derartige Ausführungsform, gezeigt in 20, weist eine virtuelle Maschine 2040 mit einem Treiber der virtuellen Funktion 2041 unter Verwendung eines Framebuffer-Deskriptors 2051 zum Spezifizieren der Gast-Anzeigeanforderungen auf. Wie bereits zuvor beschrieben, wird ein Backend-Anzeigemodell verwendet, bei welchem der Treiber der virtuellen Funktion 2041 des Gastes einen Backend-Anzeigedienst 2020 in einem Host zum Konfigurieren der Hardware-Anzeige aufruft. In dieser bestimmten Ausführungsform erfolgt die Konfiguration durch einen entfernten Protokollserver 2015 unter Verwendung eines Treibers der physischen Funktion 2010 zum Durchführen der Aktualisierung der physischen Konfiguration (z.B. angegeben durch PF 2061). Der VF-Treiber 2041 kann auch über eine virtuelle Funktion 2062 auf die GPU zugreifen, wie zuvor beschrieben. In der veranschaulichten Ausführungsform umfasst der Framebuffer-Deskriptor 2051 einen DMA-BUF (Direct Memory Access Buffer) -Dateideskriptor, welcher zum Anzeigen eines Gast-Framebuffers für den Host verwendet wird.
Bord-Infotainment (IVI) -Systeme haben sich signifikant auf die Automobilindustrie ausgewirkt. Die Virtualisierung spielt in IVI-Systemen eine Schlüsselrolle zur Konsolidierung eines sicherheitskritischen Clusters digitaler Instrumente und Sicherheitsmetriken (z.B. Geschwindigkeit, Drehzahl usw.) zusammen mit einigen IVI-Systemen, die Infotainment-Apps anzeigen. Die Ausführungsformen der Erfindung sehen eine Hardware-virtualisierte GPU mit den Schaltungen und der Logik zum Erfüllen der Anzeigeanforderungen des IVI-Systems auf einem hohen Leistungsniveau vor. Während einige Ausführungsformen der Erfindung in Bezug auf einen Gen12 SR-IOV-Grafikprozessor beschrieben wurden, können die zugrundeliegenden Prinzipien der Erfindung auch mit verschiedenen unterschiedlichen Arten von Grafikprozessoren, Host-Prozessoren und Virtualisierungsarchitekturen implementiert werden.
VORRICHTUNG UND VERFAHREN ZUR EFFIZIENTEN GEMEINSAMEN NUTZUNG EINER LOKALEN ANZEIGE FÜR EINEN VIRTUALISIERTEN GRAFIKPROZESSOR
21 veranschaulicht eine typische Implementierung einer virtuellen Funktion (VF) für direktes Umblättern unter Verwendung von drei unterschiedlichen VMs (1-3), jeweils mit einem Framebuffer 2101-2103 zum Erzeugen von Bildframes. Eine assoziierte Ebene 2111-2113 innerhalb der Hardware-Anzeigemaschine 2100 wird aus den entsprechenden Framebuffern 2101-2103 aktualisiert, die in drei VMs, jeweils mit einem unterschiedlichen Anwendungsfall, enthalten sind. Die drei Ebenen 2111-2113 werden an eine Pipe 2120 bereitgestellt, welche die Ebenen, wie veranschaulicht, in der Anzeigeausgabe 2130 abbildet.
Mit der physischen Funktion (PF) verantwortlich für die Steuerung der Zuweisung der Anzeigemaschine 2100 und der Ebene 2111-2113, weist jede VF die Fähigkeit auf, die zugewiesene Anzeigeebene 2111-2113 direkt anzutreiben, um die Pixeldaten entsprechend aus jedem entsprechenden Framebuffer 2101-2103 im eigenen Speicher der VM in die Anzeigemaschine 2100 herauszuscannen. Dadurch kann das System die Mischungsfähigkeiten der Anzeigemaschinen-Pipe 2120 für alle angeschlossenen Framebuffer 2101-2103 aus unterschiedlichen VMs ausnutzen und das abschließende Bild an die Anzeige 2130 bereitstellen.
Bezugnehmend auf 22, wird die Anzeigemaschine 2200 in einer systemeigenen Umgebung gemäß den Anzeigeanfragen der Framebuffer 2201-2203, die entsprechend in den Ebenen 2211-2213 angeschlossen sind, über einen Anzeigetreiber 2210 gemanagt und programmiert. Üblicherweise wird die Anzeigeaktualisierung durch Programmierung der Register der Anzeigemaschine 2200 mit den Werten, die aus den Anfragen der Framebuffer, die an die Ebenen 2211-2213 angeschlossen sind, berechnet werden, implementiert. Zum Beispiel muss, während jeder Anzeigeaktualisierung, der Anzeigemaschinentreiber 2210, der in einem systemeigenen BS 2205 läuft, möglicherweise die Anzeigemaschinen-Speicheranfragen von allen der Framebuffer 2201-2203 sammeln und dann die Ressource für jeden Framebuffer zuordnen und die Anzeige-Pipe 2220 mit den notwendigen Werten programmieren. Diese Werte müssen ordnungsgemäß gemäß den Informationen der Framebuffer 2201-2203, die in den Ebenen 2211-2213 angeschlossen sind, berechnet und programmiert werden, um optimale Energie und Leistung zu erzielen. Ansonsten kann es zu einer Verfälschung der Anzeigeausgabe 2130 kommen.
Ein derartiges Beispiel, bei welchem es zu einer Bildschirmverfälschung in der Anzeigeausgabe 2230 kommt, ist in 23 veranschaulicht. Ein Server-Anzeige-Hardware-Synchronisierungsproblem liegt bei diesen VF-Systemen zum direkten Umblättern vor, weil die Framebuffer 2101-2103, die in den zugewiesenen Ebenen 2211-2213 angeschlossen sind, im BS in unterschiedlichen VMs 1-3 vorliegen und die physische Funktion in dem Host-BS 2300 keine Kenntnis von ihnen hat. Ohne Informationen in Bezug auf die Framebuffer 2201-2203, die an die Ebenen 2211-2213 angeschlossen sind, kann der Anzeigetreiber 2211 die Anzeigemaschine 2200 nicht ordnungsgemäß steuern und programmieren, was in einer Verfälschung der Anzeigeausgabe 2230 resultiert.
Dies bleibt auch dann eine Herausforderung, wenn eine virtuelle Funktion zum direkten Umblättern wie oben beschrieben in die Hardware bewegt wird. Tatsächlich bleibt, solange die Anzeigeebenen von einer Anzeige-Pipe unterschiedlichen Domains zugewiesen sind, das Synchronisierungsproblem eine Herausforderung.
Vorherige Lösungen konzentrieren sich auf das Bereitstellen eines Satzes fester Konfigurationen, welche durch physische Funktionen zum Managen und Programmieren der Anzeigemaschine verwendet werden. Anstatt die Framebuffer der VMs für den Host anzuzeigen, wo die Anzeigemaschine gesteuert wird, erwartet diese Lösung von der physischen Funktion das Programmieren der Anzeigemaschine 2200 mit einem Satz fester Konfigurationen zum Erfüllen der meisten Anfragen von den Framebuffern, welche in zugewiesenen Ebenen angeschlossen sind. Diese Lösung löst das Hardware-Synchronisierungsproblem jedoch nicht grundlegend. Insbesondere kann ein Satz fester Konfigurationen nicht alle potentiellen Framebuffer-Anzeigeanfragen erfüllen, was letztendlich in einer Bildschirmverfälschung resultiert.
Darüber hinaus können die Anzeigeressourcen, die durch eine VM verwendet werden, geringer als die feste Konfiguration sein, jedoch kann der Zusatzabschnitt nicht durch andere VMs verwendet werden, da die Ressourcen während des Lebenszyklus der VM feststehend sind, was das System unzureichend flexibel für die Handhabung praktischer Anwendungsfälle macht.
Ausführungsformen der Erfindung lösen dieses Hardware-Synchronisierungsproblem, das durch die gemeinsame Nutzung lokaler Anzeigeebenen zwischen VMs verursacht wird, durch die Einführung eines Framebuffers der VM, der in einer zugewiesenen Ebene angeschlossen ist, auf der Host-Seite als ein Framebuffer-Objekt für den Host, sodass die Anzeigemaschine, die durch die PF gesteuert wird, zeitnah gemäß den Anfragen der Framebuffer der VMs aktualisiert werden kann.
24 veranschaulicht eine Ausführungsform eines Frameworks zum Synchronisieren der Anzeigemaschinen-Hardware 2200, die durch virtuelle GPUs gemeinsam genutzt wird. In dieser Ausführungsform weist das Host-BS 2400 einen Satz lokaler Informationen 2401-2403 auf, die mit den VM-Framebuffern 2201-2203 assoziiert sind. In einer Ausführungsform greift der Host-Anzeigetreiber 2411 auf die Framebuffer-Informationen 2401-2403 zu. Unter Verwendung dieser Ausführungsform können jeder virtuellen Funktion bestimmte Anzeigeebenen 2213-2211 zugewiesen werden. Insbesondere schließt eine virtuelle Funktion ihre Framebuffer 2201-2203 entsprechend direkt an die zugewiesenen Ebenen 2211-2213 an und führt eine Umblätter-Operation wie oben beschrieben durch, ohne jegliche Anzeigesynchronisierungsprobleme zu verursachen, und zwar aufgrund der Informationen 2401-2403, die durch den Host-Anzeigetreiber 2411 gesammelt werden.
25 veranschaulicht zusätzliche Einzelheiten für eine Ausführungsform, welche mit einer Hardware-virtualisierten SR-IOV-GPU 2530 arbeitet. Diese Ausführungsform löst die Hardware-Synchronisierungsprobleme, die durch die gemeinsame Nutzung von lokalen Anzeigeebenen zwischen virtuellen Maschinen verursacht werden, durch die Einführung jedes Framebuffers auf der Host-Seite als ein Framebuffer-Objekt. Dadurch kann die Anzeigemaschine, die durch die physische Funktion im Host gesteuert wird, ordnungsgemäß gemäß den Anfragen der Framebuffer der VMs gesteuert werden.
In dem in 25 gezeigten Beispiel sind zum Beispiel die Framebuffer 2501-2503 von mehreren virtuellen Maschinen VM1-VMn durch eine Abbildung, die am Host 2510 (wobei es sich z.B. um ein Host-BS handeln kann) durchgeführt wird, an die GPU 2530 gekoppelt. Insbesondere weist der Host 2510 eine Anzeigevermittlungskomponente 2540 und einen GPU-Treiber der physischen Funktion 2515 zum Durchführen des Anschließens und zum Managen des Renderns der Ebenen in einer Anzeige 2536 auf. Jeder Framebuffer 2501-2503 stellt entsprechend die Informationen der virtuellen Funktion 2545-2547 zur Verfügung, die zum Durchführen der Abbildung auf seiner zugewiesenen Pipe und Ebene (z.B. über ein Framebuffer-Objekt) erforderlich sind.
In diesem bestimmten Beispiel liefert der Framebuffer 2501 das Framebuffer-Objekt 2545, das Informationen für VF1, Pipe0 und EbeneO enthält, der Framebuffer 2502 liefert das Framebuffer-Objekt 2546 mit Informationen für VF1, Pipe0 und Ebene1, und der Framebuffer# 2503 liefert das Framebuffer-Objekt 2547 mit Informationen für VFn, Pipe# und Ebene# 2547. In diesem Beispiel wird # als ein Platzhalter verwendet, um anzugeben, dass die Ausführungsformen der Erfindung unter Verwendung jeglicher Zahl von Framebuffern, mit jeglicher Zahl von virtuellen Funktionen, abgebildet auf jegliche Zahl von Pipes/Ebenen implementiert werden können. In einer Ausführungsform decodiert der GPU-Treiber der physischen Funktion 2515 die Framebuffer-Informationen der virtuellen Funktion 2545-2547 zum Erzeugen der decodierten Framebuffer-Objekte 2525-2527, welche er zum ordnungsgemäßen Konfigurieren der GPU 2530 und Rendern der Anzeigeausgabe 2536 verwendet.
In einer Implementierung schließen Gäste, wie z.B. VM1-VMn, ihre Framebuffer 2501-2503 an ihre virtuellen Ebenen an, wie oben beschrieben, um ein direktes Umblättern durchzuführen (siehe z.B. 16-20 und assoziierter Text). Diese Operation wird durch die Anzeigevermittlungskomponente 2540 im Host 2510 abgefangen, wo der Zustand der virtuellen Ebene an den PF-GPU-Treiber 2515 bereitgestellt wird. Wie bereits erwähnt, ruft der PF-GPU-Treiber 2515 in einer Ausführungsform die Informationen des Gast-Framebuffers 2515 durch das Decodieren des Zustands der virtuellen Ebene 2545-2547 in decodierte Framebuffer-Informationen 2525-2527 ab. Bei der virtuellen Funktion mit Unterstützung für direktes Umblättern können die Informationen des Gast-Framebuffers durch die Ebenenregister der virtuellen Funktion decodiert werden.
In einer Ausführungsform umfassen die decodierten Framebuffer-Informationen 2525-2527 folgende Angaben:

Breite Framebuffer-Breite

Höhe Framebuffer-Höhe

Größe Framebuffer-Größe

Format Framebuffer-Format

Versatz Die Basisadresse des Framebuffers
In einer Ausführungsform wägt ein Ebenenaktualisierungsarbiter 2520 des PF-GPU-Treibers 2515 zwischen den verschiedenen Gästen ab, wobei, wie erforderlich, Anzeigemaschinenaktualisierungen 2522 und Anzeigeebenenaktualisierungen 2524 am Basisadressregister (BAR) der physischen Funktion 2532 durchgeführt werden.
25 veranschaulicht auch einen Unterbrechungspfad, der in einer Ausführungsform implementiert ist, in welcher eine Unterbrechung 2535, die durch die Anzeige 2536 erzeugt wird, durch die Anzeigevermittlungskomponente 2540 abgefangen und an die entsprechende virtuelle Maschine weitergegeben wird (z.B. die virtuelle Maschine, an welche die Unterbrechung gerichtet ist, wie z.B. VM1 oder VMn). Die virtuelle Maschine kann die Unterbrechung ignorieren, die Unterbrechung verarbeiten und/oder eine Antwort auf die Unterbrechung 2535 erzeugen.
Eine Ausführungsform der Erfindung wird auf Plattformen ohne Unterstützung für die Hardware-VF zum direkten Umblättern implementiert. Insbesondere stellt hier das Framework den VFs mit den decodierten Framebuffer-Informationen 2525 durch die Anzeigeebenenaktualisierung das Merkmal zum direkten Umblättern zur Verfügung und verwendet den Anzeigemaschinen-Aktualisierungspfad 2522 zum Synchronisieren der Anzeige-Hardware 2536.
In einer Ausführungsform führt das Framework eine Prüfung durch, um zu bestimmen, ob dieses VF-Umblättern eine Anzeigemaschinenaktualisierung erfordert. Wenn sich die Größe und das Format des Framebuffers nicht ändern, wird der Anzeigeebenen-Aktualisierungspfad zum Programmieren der zugewiesenen Ebenenregister gemäß den Framebuffer-Informationen im Auftrag einer VF gewählt. Wenn sich die Größe und das Format des Framebuffers ändern, wird der Anzeigemaschinen-Aktualisierungspfad zum Neuberechnen der Anzeigeressource und zum Programmieren der jeweiligen Anzeigemaschinenregister (einschließlich der zugewiesenen Ebenenregister) gemäß den Framebuffer-Informationen gewählt.
Bei Plattformen mit Unterstützung für die Hardware-VF zum direkten Umblättern führt das vorgeschlagene effiziente Framework die Anzeigeebenenaktualisierung wie Folgt mit den decodierten Framebuffer-Informationen durch. Die Ressourcen werden berechnet und die jeweilige Anzeigemaschinenkonfiguration wird im Speicher aktualisiert. Die jeweiligen Anzeigemaschinenregister werden mit der aktualisierten Konfiguration im Speicher programmiert.
Für die Unterbrechungsverarbeitung werden Vertikalaustastung, Umblättern und atomische Unterbrechungsereignisse in jede VM eingefügt, die eine Ebene oder Ebenen für eine gegebene Pipe aufweist.
Ein Verfahren in Übereinstimmung mit einer Ausführungsform der Erfindung ist in 26 veranschaulicht. Das Verfahren kann innerhalb des Kontextes der oben beschriebenen Systemarchitekturen implementiert werden, ist jedoch nicht notwendigerweise auf jegliche der hierin genannten spezifischen Einzelheiten beschränkt.
Bei 2600 erzeugt ein Gast (z.B. ein BS, das in einer virtuellen Maschine läuft) ein Umblättern in einer Ebene. Bei 2601 fängt der Host die Umblätter-Operation der VM ab. Wenn die virtuelle Funktion eine zugewiesene Ebene aufweist, wie bei 2602 bestimmt wird, dann werden die Framebuffer-Informationen der VM durch den bereitgestellten Ebenenzustand bei 2603 decodiert. Wenn dem nicht so ist, ist die Umblätter-Operation bei 2607 abgeschlossen.
Nachdem die Framebuffer-Informationen der VM bei 2603 decodiert wurden, erfolgt bei 2604 eine Bestimmung, ob der Framebuffer der VM lediglich eine Ebenenaktualisierung anfragt. Wenn dem so ist, wird bei 2605 die Ebenenaktualisierung angezeigt. Wenn dem nicht so ist, wird bei 2606 die Maschinenaktualisierung angezeigt. In jedem Fall ist das Umblättern bei 2607 abgeschlossen und der Prozess kehrt bei 2600 zu dem Gast zurück.
BEISPIELE
Folgendes sind Beispielimplementierungen unterschiedlicher Ausführungsformen der Erfindung.
Beispiel 1. Eine Grafikverarbeitungsvorrichtung, welche Folgendes umfasst: Host-Ausführungsschaltungen zum Ausführen von Anweisungen zum Implementieren von Host- und Virtualisierungsanweisungen zum Implementieren einer virtualisierten Ausführungsumgebung, die mehrere virtuelle Maschinen (VMs) aufweist; Grafikausführungsschaltungen zum Ausführen von Grafikanweisungen zum Rendern von Framebuffern im Auftrag jeder VM, wobei jeder Framebuffer mit einer virtuellen Funktion (VF) assoziiert ist, und eine Anzeigemaschine, die eine oder mehrere Anzeige-Pipes und mehrere Anzeigeebenen umfasst; wobei eine dynamische Abbildung durchgeführt werden soll, um einen oder mehrere der Framebuffer mit einer oder mehreren der Anzeigeebenen zu assoziieren, wobei die dynamische Abbildung das Erzeugen eines Framebuffer-Objektes mit Framebuffer-Informationen, die eine physische Funktion (PF) des Hostes zum Aktualisieren der einen oder mehreren Anzeigeebenen benötigt, umfasst.
Beispiel 2. Die Grafikverarbeitungsvorrichtung von Beispiel 1, wobei die Framebuffer-Informationen Framebuffer-Abmessungen umfassen.
Beispiel 3. Die Grafikverarbeitungsvorrichtung von Beispiel 1, wobei die Framebuffer-Informationen ein Framebuffer-Format umfassen.
Beispiel 4. Die Grafikverarbeitungsvorrichtung von Beispiel 1, wobei die Framebuffer-Informationen eine Basisadresse umfassen, die mit dem Framebuffer assoziiert ist.
Beispiel 5. Die Grafikverarbeitungsvorrichtung von Beispiel 1, welche ferner Folgendes umfasst: einen Framebuffer-Informationsdecoder zum Lesen der Framebuffer-Objekte und zum Erzeugen entsprechender decodierter Framebuffer-Informationen.
Beispiel 6. Die Grafikverarbeitungsvorrichtung von Beispiel 5, welche ferner Folgendes umfasst: einen Ebenenaktualisierungsarbiter, der durch den Host implementiert wird, zum Verwenden der decodierten Framebuffer-Informationen zum Durchführen einer Anzeigemaschinenaktualisierung und/oder einer Anzeigeebenenaktualisierung.
Beispiel 7. Die Grafikverarbeitungsvorrichtung von Beispiel 6, wobei die Anzeigemaschinenaktualisierung und/oder die Anzeigeebenenaktualisierung das Aktualisieren von einem oder mehreren Registern der Grafikausführungsschaltungen zum Anzeigen der dynamischen Abbildung umfasst, um den einen oder die mehreren Framebuffer mit der einen oder den mehreren der Anzeigeebenen zu assoziieren.
Beispiel 8. Die Grafikverarbeitungsvorrichtung von Beispiel 1, wobei jedes Framebuffer-Objekt eine Nummer der virtuellen Funktion zum Identifizieren einer virtuellen Funktion, die mit einem entsprechenden Framebuffer assoziiert ist, umfasst.
Beispiel 9. Die Grafikverarbeitungsvorrichtung von Beispiel 8, wobei jedes Framebuffer-Objekt ferner einen Ebenenidentifikator und einen Pipe-Identifikator zum Angeben einer Ebene und einer Pipe der Anzeigemaschine, die mit dem entsprechenden Framebuffer assoziiert sind, umfasst.
Beispiel 10. Ein Verfahren, welches Folgendes umfasst: Ausführen von Host-Anweisungen zum Implementieren einer Host- und einer virtualisierten Ausführungsumgebung, die mehrere virtuelle Maschinen (VMs) umfasst; Ausführen von Grafikanweisungen durch Grafikausführungsschaltungen zum Rendern von Framebuffern im Auftrag jeder VM, wobei jeder Framebuffer mit einer virtuellen Funktion (VF) assoziiert ist; dynamisches Abbilden eines Framebuffers auf einer oder mehreren Anzeigeebenen einer Anzeigemaschine, wobei das dynamische Abbilden das Erzeugen eines Framebuffer-Objektes mit Framebuffer-Informationen, die eine physische Funktion (PF) des Hostes zum Aktualisieren der einen oder mehreren Anzeigeebenen benötigt, umfasst.
Beispiel 11. Das Verfahren von Beispiel 10, wobei die Framebuffer-Informationen Framebuffer-Abmessungen umfassen.
Beispiel Das Verfahren von Beispiel 10, wobei die Framebuffer-Informationen ein Framebuffer-Format umfassen.
Beispiel 13. Das Verfahren von Beispiel 10, wobei die Framebuffer-Informationen eine Basisadresse umfassen, die mit dem Framebuffer assoziiert ist.
Beispiel 14. Das Verfahren von Beispiel 10, welches ferner Folgendes umfasst: Lesen der Framebuffer-Objekte und Erzeugen entsprechender decodierter Framebuffer-Informationen.
Beispiel 15. Das Verfahren von Beispiel 14, welches ferner Folgendes umfasst: Durchführen einer Anzeigemaschinenaktualisierung und/oder einer Anzeigeebenenaktualisierung unter Verwendung der decodierten Framebuffer-Informationen.
Beispiel 16. Das Verfahren von Beispiel 15, wobei die Anzeigemaschinenaktualisierung und/oder die Anzeigeebenenaktualisierung Folgendes umfasst: Aktualisieren von einem oder mehreren Registern der Grafikausführungsschaltungen zum Anzeigen der dynamischen Abbildung, um den einen oder die mehreren Framebuffer mit der einen oder den mehreren der Anzeigeebenen zu assoziieren.
Beispiel 17. Das Verfahren von Beispiel 10, wobei jedes Framebuffer-Objekt eine Nummer der virtuellen Funktion zum Identifizieren einer virtuellen Funktion, die mit einem entsprechenden Framebuffer assoziiert ist, umfasst.
Beispiel 18. Das Verfahren von Beispiel 17, wobei jedes Framebuffer-Objekt ferner einen Ebenenidentifikator und einen Pipe-Identifikator zum Angeben einer Ebene und einer Pipe der Anzeigemaschine, die mit dem entsprechenden Framebuffer assoziiert sind, umfasst.
Beispiel 19. Ein maschinenlesbares Medium, auf welchem Programmcode gespeichert ist, welcher, wenn er durch eine Maschine ausgeführt wird, die Maschine zum Durchführen folgender Operationen veranlasst: Ausführen von Host-Anweisungen zum Implementieren einer Host- und einer virtualisierten Ausführungsumgebung, die mehrere virtuelle Maschinen (VMs) umfasst; Ausführen von Grafikanweisungen durch Grafikausführungsschaltungen zum Rendern von Framebuffern im Auftrag jeder VM, wobei jeder Framebuffer mit einer virtuellen Funktion (VF) assoziiert ist; dynamisches Abbilden eines Framebuffers auf einer oder mehreren Anzeigeebenen einer Anzeigemaschine, wobei das dynamische Abbilden das Erzeugen eines Framebuffer-Objektes mit Framebuffer-Informationen, die eine physische Funktion (PF) des Hostes zum Aktualisieren der einen oder mehreren Anzeigeebenen benötigt, umfasst.
Beispiel 20. Das maschinenlesbare Medium von Beispiel 19, wobei die Framebuffer-Informationen Framebuffer-Abmessungen umfassen.
Beispiel 21. Das maschinenlesbare Medium von Beispiel 19, wobei die Framebuffer-Informationen ein Framebuffer-Format umfassen.
Beispiel 22. Das maschinenlesbare Medium von Beispiel 19, wobei die Framebuffer-Informationen eine Basisadresse umfassen, die mit dem Framebuffer assoziiert ist.
Beispiel 23. Das maschinenlesbare Medium von Beispiel 19, welches ferner Programmcode umfasst, um die Maschine zum Durchführen folgender Operationen zu veranlassen: Lesen der Framebuffer-Objekte und Erzeugen entsprechender decodierter Framebuffer-Informationen.
Beispiel 24. Das maschinenlesbare Medium von Beispiel 23, welches ferner Programmcode umfasst, um die Maschine zum Durchführen folgender Operationen zu veranlassen: Durchführen einer Anzeigemaschinenaktualisierung und/oder einer Anzeigeebenenaktualisierung unter Verwendung der decodierten Framebuffer- Informationen.
Beispiel 25. Das maschinenlesbare Medium von Beispiel 24, wobei die Anzeigemaschinenaktualisierung und/oder die Anzeigeebenenaktualisierung Folgendes umfasst: Aktualisieren von einem oder mehreren Registern der Grafikausführungsschaltungen zum Anzeigen der dynamischen Abbildung, um den einen oder die mehreren Framebuffer mit der einen oder den mehreren der Anzeigeebenen zu assoziieren.
Beispiel 26. Das maschinenlesbare Medium von Beispiel 19, wobei jedes Framebuffer-Objekt eine Nummer der virtuellen Funktion zum Identifizieren einer virtuellen Funktion, die mit einem entsprechenden Framebuffer assoziiert ist, umfasst.
Beispiel 27. Das maschinenlesbare Medium von Beispiel 26, wobei jedes Framebuffer-Objekt ferner einen Ebenenidentifikator und einen Pipe-Identifikator zum Angeben einer Ebene und einer Pipe der Anzeigemaschine, die mit dem entsprechenden Framebuffer assoziiert sind, umfasst.
Die Ausführungsformen der Erfindung stellen eine virtuelle GPU ohne Hardware-DirectFlip-Unterstützung zur Verfügung, mit der Fähigkeit, eine direkte Umschaltung durch Anzeigevermittlung durchzuführen, und ohne jegliche Hardware-Synchronisierungsprobleme zu verursachen.
Interaktive Fahrzeug-Infotainment (IVI - Interactive Vehicle Infotainment) -Systeme haben sich signifikant auf die Automobilindustrie ausgewirkt. Die Virtualisierung spielt in diesen Systemen eine Schlüsselrolle zur Konsolidierung eines sicherheitskritischen Clusters digitaler Instrumente, welche Sicherheitsmetriken (z.B. Geschwindigkeit, Drehzahl und so weiter) anzeigen, zusammen mit einigen Infotainment-Apps.
Eine Ausführungsform des Mechanismus zur gemeinsamen Nutzung einer lokalen Anzeige stellt eine Hardware-virtualisierte SR-IOV-GPU sowie virtuelle GPUs zur Verfügung, mit der Fähigkeit, die Anzeigeanforderungen des IVI-Systems mit hoher Leistung und einer akzeptablen Benutzererfahrung zu erfüllen. Die Hardware-virtualisierte SR-IOV-GPU kann die zugewiesene Anzeigeebene direkt antreiben, um die Pixeldaten aus dem Framebuffer im eigenen Speicher der VM auf eine HW-Ebene der Anzeigemaschine herauszuscannen, ohne jegliche Synchronisierungsprobleme zu verursachen. Folglich kann das System die Mischungsfähigkeiten des Anzeige-Controllers für alle angeschlossenen Framebuffer aus unterschiedlichen VMs nutzen und das abschließende Bild an den Anzeigemonitor liefern.
Ausführungsformen der Erfindung können verschiedene Schritte umfassen, welche oben beschrieben wurden. Die Schritte können in maschinenausführbaren Anweisungen verkörpert sein, welche verwendet werden können, um einen Universal- oder Spezialprozessor zum Durchführen der Schritte zu veranlassen. Alternativ dazu können diese Schritte durch spezifische Hardware-Komponenten, die festverdrahtete Logik zum Durchführen der Schritte enthalten, oder durch jegliche Kombination aus programmierten Computerkomponenten und kundenspezifischen Hardware-Komponenten durchgeführt werden.
Wie hierin beschrieben, können sich Anweisungen auf spezifische Konfigurationen von Hardware, wie z.B. anwendungsspezifische integrierte Schaltungen (ASICs - Application Specific Integrated Circuits), die zum Durchführen bestimmter Operationen konfiguriert sind oder eine vorbestimmte Funktionalität aufweisen, oder Softwareanweisungen, die in einem Speicher gespeichert sind, der in einem nichttransitorischen computerlesbaren Medium verkörpert ist, beziehen. Somit können die in den Figuren gezeigten Techniken unter Verwendung von Code und Daten, die auf einem oder mehreren elektronischen Geräten (z.B. einer Endstation, einem Netzwerkelement usw.) gespeichert sind und ausgeführt werden, implementiert werden. Derartige elektronische Geräte speichern und kommunizieren (intern und/oder mit anderen elektronischen Geräten über ein Netzwerk) Code und Daten unter Verwendung von computermaschinenlesbaren Medien, wie z.B. nichttransitorischen computermaschinenlesbaren Speichermedien (z.B. magnetischen Platten, optischen Platten, Direktzugriffsspeicher, Nur-Lese-Speicher, Flash-Speichergeräten, Phasenwechselspeicher) und transitorischen computermaschinenlesbaren Kommunikationsmedien (z.B. elektrischen, optischen, akustischen oder anderen Formen von propagierten Signalen - wie z.B. Trägerwellen, Infrarotsignalen, digitalen Signalen usw.).
Außerdem weisen derartige elektronische Geräte üblicherweise einen Satz von einem oder mehreren Prozessoren gekoppelt an eine oder mehrere andere Komponenten auf, wie z.B. ein oder mehrere Speichergeräte (nichttransitorische maschinenlesbare Speichermedien), Benutzer-Eingabe/Ausgabe-Geräte (z.B. eine Tastatur, ein Touchscreen und/oder eine Anzeige) und Netzwerkverbindungen. Das Koppeln des Satzes von Prozessoren und anderen Komponenten erfolgt üblicherweise über einein oder mehrere Busse und Brücken (auch als Bus-Controller bezeichnet). Das Speichergerät und Signale, welche den Netzwerkverkehr übertragen, stellen jeweils ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien dar. Somit speichert das Speichergerät eines gegebenen elektronischen Gerätes üblicherweise Code und/oder Daten zur Ausführung auf dem Satz von einem oder mehreren Prozessoren dieses elektronischen Gerätes. Natürlich können ein oder mehrere Teile einer Ausführungsform der Erfindung auch unter Verwendung unterschiedlicher Kombinationen aus Software, Firmware und/oder Hardware implementiert werden. In dieser gesamten detaillierten Beschreibung wurden zu Erläuterungszwecken zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der vorliegenden Erfindung bereitzustellen. Einem Fachmann auf dem Gebiet wird jedoch offensichtlich sein, dass die Erfindung auch ohne einige dieser spezifischen Einzelheiten in der Praxis umgesetzt werden kann. In bestimmten Fällen wurden gut bekannte Strukturen und Funktionen nicht im Einzelnen beschrieben, um ein Verdecken des Gegenstands der vorliegenden Erfindung zu vermeiden. Dementsprechend sollten der Umfang und Geist der Erfindung hinsichtlich der Ansprüche beurteilt werden, welche nun folgen.

Claims

Grafikverarbeitungsvorrichtung, welche Folgendes umfasst: Host-Ausführungsschaltungen zum Ausführen von Anweisungen zum Implementieren von Host- und Virtualisierungsanweisungen zum Implementieren einer virtualisierten Ausführungsumgebung, die mehrere virtuelle Maschinen (VMs) aufweist; Grafikausführungsschaltungen zum Ausführen von Grafikanweisungen zum Rendern von Framebuffern im Auftrag jeder VM, wobei jeder Framebuffer mit einer virtuellen Funktion (VF) assoziiert ist; und eine Anzeigemaschine, die eine oder mehrere Anzeige-Pipes und mehrere Anzeigeebenen umfasst; wobei eine dynamische Abbildung durchgeführt werden soll, um einen oder mehrere der Framebuffer mit einer oder mehreren der Anzeigeebenen zu assoziieren, wobei die dynamische Abbildung das Erzeugen eines Framebuffer-Objektes mit Framebuffer-Informationen, die eine physische Funktion (PF) des Hostes zum Aktualisieren der einen oder mehreren Anzeigeebenen benötigt, umfasst.
Grafikverarbeitungsvorrichtung nach Anspruch 1, wobei die Framebuffer-Informationen Framebuffer-Abmessungen umfassen.
Grafikverarbeitungsvorrichtung nach Anspruch 1, wobei die Framebuffer-Informationen ein Framebuffer-Format umfassen.
Grafikverarbeitungsvorrichtung nach Anspruch 1, wobei die Framebuffer-Informationen eine Basisadresse umfassen, die mit dem Framebuffer assoziiert ist.
Grafikverarbeitungsvorrichtung nach Anspruch 1, welche ferner Folgendes umfasst: einen Framebuffer-Informationsdecoder zum Lesen der Framebuffer-Objekte und zum Erzeugen entsprechender decodierter Framebuffer-Informationen.
Grafikverarbeitungsvorrichtung nach Anspruch 5, welche ferner Folgendes umfasst: einen Ebenenaktualisierungsarbiter, der durch den Host implementiert wird, zum Verwenden der decodierten Framebuffer-Informationen zum Durchführen einer Anzeigemaschinenaktualisierung und/oder einer Anzeigeebenenaktualisierung.
Grafikverarbeitungsvorrichtung nach Anspruch 6, wobei die Anzeigemaschinenaktualisierung und/oder die Anzeigeebenenaktualisierung das Aktualisieren von einem oder mehreren Registern der Grafikausführungsschaltungen zum Anzeigen der dynamischen Abbildung umfasst, um den einen oder die mehreren Framebuffer mit der einen oder den mehreren der Anzeigeebenen zu assoziieren.
Grafikverarbeitungsvorrichtung nach Anspruch 1, wobei jedes Framebuffer-Objekt eine Nummer der virtuellen Funktion zum Identifizieren einer virtuellen Funktion, die mit einem entsprechenden Framebuffer assoziiert ist, umfasst.
Grafikverarbeitungsvorrichtung nach Anspruch 8, wobei jedes Framebuffer-Objekt ferner einen Ebenenidentifikator und einen Pipe-Identifikator zum Angeben einer Ebene und einer Pipe der Anzeigemaschine, die mit dem entsprechenden Framebuffer assoziiert sind, umfasst.
Verfahren, welches Folgendes umfasst: Ausführen von Host-Anweisungen zum Implementieren einer Host- und einer virtualisierten Ausführungsumgebung, die mehrere virtuelle Maschinen (VMs) umfasst; Ausführen von Grafikanweisungen durch Grafikausführungsschaltungen zum Rendern von Framebuffern im Auftrag jeder VM, wobei jeder Framebuffer mit einer virtuellen Funktion (VF) assoziiert ist; dynamisches Abbilden eines Framebuffers auf einer oder mehreren Anzeigeebenen einer Anzeigemaschine, wobei das dynamische Abbilden das Erzeugen eines Framebuffer-Objektes mit Framebuffer-Informationen, die eine physische Funktion (PF) des Hostes zum Aktualisieren der einen oder mehreren Anzeigeebenen benötigt, umfasst.
Verfahren nach Anspruch 10, wobei die Framebuffer-Informationen Framebuffer-Abmessungen umfassen.
Verfahren nach Anspruch 10, wobei die Framebuffer-Informationen ein Framebuffer-Format umfassen.
Verfahren nach Anspruch 10, wobei die Framebuffer-Informationen eine Basisadresse umfassen, die mit dem Framebuffer assoziiert ist.
Verfahren nach Anspruch 10, welches ferner Folgendes umfasst: Lesen der Framebuffer-Objekte; und Erzeugen entsprechender decodierter Framebuffer-Informationen.
Verfahren nach Anspruch 14, welches ferner Folgendes umfasst: Durchführen einer Anzeigemaschinenaktualisierung und/oder einer Anzeigeebenenaktualisierung unter Verwendung der decodierten Framebuffer-Informationen.
Verfahren nach Anspruch 15, wobei die Anzeigemaschinenaktualisierung und/oder die Anzeigeebenenaktualisierung Folgendes umfasst: Aktualisieren von einem oder mehreren Registern der Grafikausführungsschaltungen zum Anzeigen der dynamischen Abbildung, um den einen oder die mehreren Framebuffer mit der einen oder den mehreren der Anzeigeebenen zu assoziieren.
Verfahren nach Anspruch 10, wobei jedes Framebuffer-Objekt eine Nummer der virtuellen Funktion zum Identifizieren einer virtuellen Funktion, die mit einem entsprechenden Framebuffer assoziiert ist, umfasst.
Verfahren nach Anspruch 17, wobei jedes Framebuffer-Objekt ferner einen Ebenenidentifikator und einen Pipe-Identifikator zum Angeben einer Ebene und einer Pipe der Anzeigemaschine, die mit dem entsprechenden Framebuffer assoziiert sind, umfasst.
Maschinenlesbares Medium, auf welchem Programmcode gespeichert ist, welcher, wenn er durch eine Maschine ausgeführt wird, die Maschine zum Durchführen folgender Operationen veranlasst: Ausführen von Host-Anweisungen zum Implementieren einer Host- und einer virtualisierten Ausführungsumgebung, die mehrere virtuelle Maschinen (VMs) umfasst; Ausführen von Grafikanweisungen durch Grafikausführungsschaltungen zum Rendern von Framebuffern im Auftrag jeder VM, wobei jeder Framebuffer mit einer virtuellen Funktion (VF) assoziiert ist; dynamisches Abbilden eines Framebuffers auf einer oder mehreren Anzeigeebenen einer Anzeigemaschine, wobei das dynamische Abbilden das Erzeugen eines Framebuffer-Objektes mit Framebuffer-Informationen, die eine physische Funktion (PF) des Hostes zum Aktualisieren der einen oder mehreren Anzeigeebenen benötigt, umfasst.
Maschinenlesbares Medium nach Anspruch 19, wobei die Framebuffer-Informationen Framebuffer-Abmessungen umfassen.
Maschinenlesbares Medium nach Anspruch 19, wobei die Framebuffer-Informationen ein Framebuffer-Format umfassen.
Maschinenlesbares Medium nach Anspruch 19, wobei die Framebuffer-Informationen eine Basisadresse umfassen, die mit dem Framebuffer assoziiert ist.
Maschinenlesbares Medium nach Anspruch 19, welches ferner Programmcode umfasst, um die Maschine zum Durchführen folgender Operationen zu veranlassen: Lesen der Framebuffer-Objekte; und Erzeugen entsprechender decodierter Framebuffer-Informationen.
Maschinenlesbares Medium nach Anspruch 23, welches ferner Programmcode umfasst, um die Maschine zum Durchführen folgender Operationen zu veranlassen: Durchführen einer Anzeigemaschinenaktualisierung und/oder einer Anzeigeebenenaktualisierung unter Verwendung der decodierten Framebuffer-Informationen.
Maschinenlesbares Medium nach Anspruch 24, wobei die Anzeigemaschinenaktualisierung und/oder die Anzeigeebenenaktualisierung Folgendes umfasst: Aktualisieren von einem oder mehreren Registern der Grafikausführungsschaltungen zum Anzeigen der dynamischen Abbildung, um den einen oder die mehreren Framebuffer mit der einen oder den mehreren der Anzeigeebenen zu assoziieren.
Maschinenlesbares Medium nach Anspruch 19, wobei jedes Framebuffer-Objekt eine Nummer der virtuellen Funktion zum Identifizieren einer virtuellen Funktion, die mit einem entsprechenden Framebuffer assoziiert ist, umfasst.
Maschinenlesbares Medium nach Anspruch 26, wobei jedes Framebuffer-Objekt ferner einen Ebenenidentifikator und einen Pipe-Identifikator zum Angeben einer Ebene und einer Pipe der Anzeigemaschine, die mit dem entsprechenden Framebuffer assoziiert sind, umfasst.