DE112018005527T5

DE112018005527T5 - Automatisches aufwecken von leistungsdomänen fürgrafikkonfigurationsanforderungen

Info

Publication number: DE112018005527T5
Application number: DE112018005527.2T
Authority: DE
Inventors: William S. Dubel; Josh B. Mastronarde; Melaku Teshome
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2017-09-26
Filing date: 2018-07-09
Publication date: 2020-07-02
Also published as: US20190095223A1; WO2019067058A1; US10503520B2

Abstract

Die Ausführungsformen sind allgemein auf das automatische Aufwecken von Leistungsdomänen für Grafikkonfigurationsanforderungen gerichtet. In einer Ausführungsform weist eine Vorrichtung eine Schnittstelle zum Erhalten einer Grafikkonfigurationsanforderung, wobei die Grafikkonfigurationsanforderung an ein Zielgrafikregister in einer Grafikdomäne gerichtet ist; Register zum Speichern von Daten, wobei die Register ein oder mehrere Konfigurationsregister umfassen, auf die zum Speichern der Grafikkonfigurationsanforderung zugegriffen werden kann; eine automatische Leistungsdomänenbestimmungslogik zum Bestimmen einer Leistungsdomäne für das Zielgrafikregister basierend auf geteilten Informationen, auf die von der automatischen Leistungsdomänenbestimmungslogik zugegriffen wird; und eine Aufweckanzeigelogik zum Bestimmen, ob sich die Leistungsdomäne für das Zielgrafikregister in einem Zustand mit verringerter Leistung befindet, und nach dem Durchführen einer Bestimmung eines Zustands mit verringerter Leistung, zum Erzeugen einer Aufweckanzeige für die Leistungsdomäne, auf.

Description

VERWANDTE ANMELDUNG
Diese Anmeldung beansprucht die Priorität unter 35 USC 119(e) der US-Patentanmeldung Nr. 15/716.239 , die am 26. September 2017 eingereicht wurde, wobei diese Anmeldung hierin vollständig durch Bezugnahme aufgenommen ist.
TECHNISCHES GEBIET
Die hierin beschriebenen Ausführungsformen beziehen sich allgemein auf das Feld der elektronischen Vorrichtungen und genauer auf das automatische Aufwecken von Leistungsdomänen für Grafikkonfigurationsanforderungen.
ALLGEMEINER STAND DER TECHNIK
Bei Computeroperationen haben Leistungseffizienzbemühungen zur Schaffung von zunehmenden Anzahlen an Leistungsdomänen in elektronischen Vorrichtungen geführt. Um den Stromverbrauch zu minimieren, ist das Ziel bei der Operation für jede Leistungsdomäne, auf einen Zustand mit geringerer Leistung, wie etwa einen Bereitschaftszustand, zu jeder Zeit, wenn die Domäne inaktiv ist, verringert zu werden, um den gesamten Stromverbrauch zu verringern.
Insbesondere wird ein Treiber benötigt, um Register zu programmieren, die sich in verschiedenen Leistungsdomänen befinden, damit ein Treiber Arbeitslasten in Grafik konfigurieren und initiieren kann. Jedoch kann sich jede solcher Leistungsdomänen in einem Zustand mit verringerter Leistung zum Zeitpunkt einer Anforderung befinden und muss somit zum Betrieb eingeschaltet werden.
Folglich muss bei einer herkömmlichen Operation zur Grafikkonfiguration der Treibercode verstehen, welche Register zu jeder Leistungsdomäne gehören, um sicherzustellen, dass die geeignete Domäne vor dem Programmieren aufgeweckt ist. Ein Register wird dann allgemein programmiert und abgefragt, um zu bestimmen, wann die Leistungsdomäne vor dem Programmieren des Ziels eingeschaltet wird, was darauffolgende Anforderungen verzögern kann. Ferner kann, wenn eine falsche Leistungsdomäne für ein konkretes Register spezifiziert wird, ein Aufhängen eines Programms oder ein sonstiges unerwünschtes Ergebnis aus dem Grafikkonfigurationsprozess resultieren, wenn die richtige Leistungsdomäne nicht während dem Programmieren mit Strom versorgt wird.
Figurenliste
Die Ausführungsformen, die hier beschrieben sind, sind beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen veranschaulicht, in welchen sich gleiche Bezugszeichen auf ähnliche Elemente beziehen.

1 ist ein Blockdiagramm eines Verarbeitungssystems gemäß einigen Ausführungsformen;
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors, der einen oder mehrere Prozessorkerne, einen integrierten Speichercontroller und einen integrierten Grafikprozessor aufweist;
3 ist ein Blockdiagramm eines Grafikprozessors gemäß einigen Ausführungsformen;
4 ist ein Blockdiagramm einer Grafikverarbeitungsengine eines Grafikprozessors gemäß einigen Ausführungsformen;
5 ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns 500 gemäß einigen Ausführungsformen;
6A-6B veranschaulichen eine Thread-Ausführungslogik einschließlich einer Anordnung von Verarbeitungselementen, die in einem Grafikprozessorkern eingesetzt werden, gemäß einigen Ausführungsformen;
7 ist ein Blockdiagramm, das Grafikprozessoranweisungsformate gemäß einigen Ausführungsformen veranschaulicht;
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors;
9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat gemäß einigen Ausführungsformen veranschaulicht;
9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz gemäß einer Ausführungsform veranschaulicht;
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einigen Ausführungsformen;
11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100 gemäß einer Ausführungsform veranschaulicht, das verwendet werden kann, um eine integrierte Schaltung herzustellen, um Operationen durchzuführen;
11B veranschaulicht eine Querschnittsseitenansicht einer integrierten Schaltungspackungsanordnung gemäß einigen Ausführungsformen;
12 ist ein Blockdiagramm, das eine beispielhafte integrierte System-on-a-Chip-Schaltung 1200, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform veranschaulicht;
13A veranschaulicht einen beispielhaften Grafikprozessor einer integrierten System-on-a-Chip-Schaltung, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform;
13B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor einer integrierten System-on-a-Chip-Schaltung, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform;
14A veranschaulicht einen Grafikkern, der innerhalb eines Grafikprozessors enthalten sein kann, gemäß einigen Ausführungsformen;
14B veranschaulicht eine hochparallele Universalgrafikverarbeitungseinheit, die zum Einsatz auf einem Mehrfach-Chipmodul geeignet ist, gemäß einigen Ausführungsformen;
15A ist eine Veranschaulichung eines Systems zum Bereitstellen einer automatischen Leistungsdomänenbestimmung gemäß einigen Ausführungsformen;
15B ist ein Flussdiagramm zum Veranschaulichen eines Prozesses zur automatischen Leistungsdomänenbestimmung gemäß einigen Ausführungsformen;
16 ist eine Veranschaulichung einer Schnittstellenbrücke einschließlich automatischer Leistungsdomänenbestimmung gemäß einigen Ausführungsformen;
17A und 17B veranschaulichen Elemente eines automatischen Leistungsdomänenmechanismus gemäß einigen Ausführungsformen;
18 ist ein Registerpaar, das bei der automatischen Leistungsdomänenbestimmung zu verwenden ist, gemäß einigen Ausführungsformen;
19 ist ein beispielhafter Prozessfluss, der eine Signalisierung zur automatischen Leistungsdomänenbestimmung unter Verwendung eines Entkopplungsanforderungsschreibens gemäß einigen Ausführungsformen veranschaulicht; und
20 ist ein Flussdiagramm zum Veranschaulichen eines Prozesses zum Bereitstellen einer automatischen Leistungsdomänenbestimmung gemäß einigen Ausführungsformen.

AUSFÜHRLICHE BESCHREIBUNG
Die hierin beschriebenen Ausführungsformen sind allgemein auf das automatische Aufwecken von Leistungsdomänen für Grafikkonfigurationsanforderungen gerichtet.
So wie sie hierin verwendet werden, gelten folgende Ausdrücke:
Mit „Zustand mit verringerter Leistung“ oder „Modus mit verringerter Leistung“ ist ein beliebiger Leistungszustand oder -modus für eine Vorrichtung, ein Gerät oder eine Leistungsdomäne gemeint, in welchem der Stromverbrauch in Bezug auf einen normalen Leistungszustand (welcher auch als ein Betriebsleistungszustand oder ähnlich bezeichnet werden kann) verringert ist. Zustände mit verringerter Leistung umfassen einen Bereitschaftszustand, einen Ruhezustand oder einen sonstigen ähnlichen Zustand, ohne jedoch darauf beschränkt zu sein.
Um Arbeitslasten bei einer Grafik zu initiieren und zu konfigurieren, kann ein Treiber, der auf einem oder mehreren Prozessoren ausgeführt wird (allgemein hierin als der Prozessor des Systems bzw. Vorrichtung bezeichnet) erforderlich sein, um mehrere benötigte Register zu programmieren, wobei sich die Register in mehreren unterschiedlichen Leistungsdomänen befinden können. Bei einem herkömmlichen System ist es notwendig, dass der Treiber Wissen in Bezug darauf hat, welche Register zu jeder Leistungsdomäne gehören, um sicherzustellen, dass die geeignete Domäne vor dem Programmieren aufgeweckt ist.
Es ist jedoch ein deutlicher Overhead für den Treiber und den Prozessor vorhanden, die an dem Verwalten der Informationen bezüglich der Leistungsdomänen beteiligt sind, und der Prozess des Einschaltens und Schreibens in jedes benötigte Register erzeugt Verzögerungen, da jedes Register programmiert und abgefragt wird, um zu bestimmen, wann die Leistungsdomäne eingeschaltet wird, bevor das Zielregister programmiert wird.
Wenn ferner eine falsche Leistungsdomäne für ein konkretes Register spezifiziert wird, was dazu führt, dass Anweisungen an ein Register in einer Leistungsdomäne gerichtet werden, die nicht eingeschaltet ist, können die Folgen verloren gegangene Schreibdaten, falsche Lesedaten, eine Programmaufhängung oder ein sonstiges unerwünschtes Ergebnis umfassen.
In einigen Ausführungsformen wird ein Hardwaremechanismus (welcher hierin allgemein als ein automatischer Leistungsdomänenmechanismus oder APDM bezeichnet werden kann) bereitgestellt, um automatisch die Zielleistungsdomäne für ein Zielregister (welches auch als angezieltes Zielregister bezeichnet werden kann) anhand der programmierten Adresse einer Grafikkonfigurationsanforderung unter Verwendung einer Suche von geteilten Adressinformationen zu bestimmen. Die geeignete Leistungsdomäne kann dann, falls nötig, zur Programmierung des Zielregisters eingeschaltet werden.
In einigen Ausführungsformen ist der automatische Leistungsdomänenmechanismus in einer Schnittstellenbrücke zwischen dem Prozessor-Nicht-Kern-Konfigurationstraffic (wie etwa über das IOSF(Integrated On-Chip System Fabric)-Seitenband) von dem Prozessor zu der GT(Grafik)-Nachrichtenübermittlung (über den Grafiknachrichtenkanal) implementiert. In einigen Ausführungsformen ist die Schnittstellenbrückendomäne immer während dem Betrieb eingeschaltet und ist somit verfügbar, um mit einer automatischen Leistungsdomänenbestimmung für eine beliebige Grafikkonfigurationsanforderung zu antworten, die an ein Register innerhalb einer der GT-Leistungsdomänen zu richten ist.
In einigen Ausführungsformen ist der Betrieb des automatischen Leistungsdomänenmechanismus für den Treiber transparent, welcher nicht Bestimmungen bezüglich der Kennzeichnung der Zielleistungsdomäne oder der aktuellen Leistungsaktivität solch einer Leistungsdomäne vornehmen muss. Ferner sind auch beliebige Änderungen bezüglich der Leistungsdomänen für den Treiber transparent, welcher somit nicht als Reaktion auf solche Änderungen modifiziert werden muss.
In einigen Ausführungsformen hat der automatische Leistungsdomänenmechanismus geteilten Zugriff auf Informationen, die von dem Client für Adressenrouting verwaltet werden, wobei der Mechanismus die geteilten Informationen bei der Kennzeichnung der Domänenbestimmung verwenden wird. In einigen Ausführungsformen werden die geteilten Informationen, die in der Schnittstelle bereitgestellt werden, von Informationen in einer Client-Tabelle abgeleitet (d. h., sie basieren darauf), die von Nachrichtenkanalroutern verwaltet wird, wobei der Mechanismus die geteilten Informationen zum Ausrichten von Adressen auf Clients und Leistungsdomänen, zu denen die Clients gehören, verwenden wird. Zu dem Zeitpunkt, wenn eine Anforderung programmiert wird, wird die automatische Domänenbestimmung die Zielleistungsdomäne für das Zielregister kennzeichnen und, falls nötig, eine Aufweckanzeige für jene Leistungsdomäne bestätigen. Nachdem die Leistungsdomäne bereit ist (d. h., sich die Domäne in einem aktiven Zustand befindet), wird die Anforderung automatisch auf dem Nachrichtenkanal initiiert.
In einigen Ausführungsformen kann der automatische Leistungsdomänenmechanismus ferner den Entkopplungsanforderungs(DCR, Decouple Request)-mechanismus verwenden und darauf aufbauen, um ein Hinauszögern von Anforderungen in dem Grafikkonfigurationsprozessfluss zu verhindern. Der Entkopplungsanforderungsmechanismus wirkt, um Anforderungen von Datentraffic zu entkoppeln, wobei bei einer aktuellen Implementierung der Entkopplungsanforderungsmechanismus 16 Paare von Registern bereitstellt, die von dem Treiber zu verwenden sind, um Anforderungen von mehreren Threads zu senden, ohne Treibertraffic in der Signalfabric (d. h., der IOSF) hinauszuzögern. Der adressierbare Registerraum für Grafik nimmt jedoch bei Produkten weiterhin zu und die Anzahl an Adressbits, die benötigt wird, weist unter einigen Umständen überschrittene aktuelle Programmiergrenzen des Prozessors bezüglich des GT-Entkopplungsanforderungsmechanismus auf. In einigen Ausführungsformen wirkt der automatische Leistungsdomänenmechanismus derart, dass er die Datenbits löscht, die zur Domänenauswahl benötigt werden, um vermehrte Adressbits beim Programmieren durch den Entkopplungsanforderungsmechanismus zu erlauben.
Systemübersicht
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 kann ein Einprozessor-Desktopsystem, ein Mehrfachprozessor-Arbeitsstationssystem oder ein Serversystem, das eine große Anzahl an Prozessoren 102 oder Prozessorkernen 107 aufweist, sein. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die innerhalb einer integrierten System-on-a-Chip(SoC)-Schaltung zur Verwendung in mobilen, handgehaltenen oder eingebetteten Vorrichtungen aufgenommen ist.
In einer Ausführungsform kann das System 100 eine serverbasierte Spieleplattform, eine Spielekonsole einschließlich einer Spiele- und Medienkonsole, eine mobile Spielekonsole, eine handgehaltene Spielekonsole oder eine Online-Spielekonsole umfassen oder innerhalb von diesen aufgenommen sein. In einigen Ausführungsformen ist das System 100 ein Mobiltelefon, ein Smartphone, eine Tablet-Computervorrichtung oder eine mobile Internetvorrichtung. Das Verarbeitungssystem 100 kann auch eine tragbare Vorrichtung, wie etwa eine tragbare Smartwatch-Vorrichtung, eine intelligente Eyewear-Vorrichtung, eine Augmented Reality-Vorrichtung oder eine Virtual Reality-Vorrichtung umfassen, mit diesen gekoppelt oder innerhalb von diesen integriert sein. In einigen Ausführungsformen ist das Verarbeitungssystem 100 ein Fernseher oder eine Set-Top-Box-Vorrichtung, der bzw. die einen oder mehrere Prozessoren 102 und eine Grafikschnittstelle, die von einem oder mehreren Grafikprozessoren 108 erzeugt wird, aufweist.
In einigen Ausführungsformen weisen der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 auf, um Anweisungen zu verarbeiten, 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 konfiguriert, um einen spezifischen Anweisungssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Anweisungssatz 109 Rechnen mit einem komplexen Anweisungssatz (CISC, Complex Instruction Set Computing), Rechnen mit einem verringerten Anweisungssatz (RISC, Reduced Instruction Set Computing) oder Rechnen über ein sehr langes Anweisungswort (VLIW, Very Long Instruction Word) ermöglichen. Mehrere Prozessorkerne 107 können jeweils einen anderen Anweisungssatz 109 verarbeiten, welcher Anweisungen umfassen kann, um die Emulation anderer Anweisungssätze zu ermöglichen. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen, wie etwa einen Digitalsignalprozessor (DSP), aufweisen.
In einigen Ausführungsformen weist der Prozessor 102 einen Cache-Speicher 104 auf. Je nach der Architektur kann der Prozessor 102 einen einzigen internen Cache oder mehrere Ebenen von internem Cache aufweisen. In einigen Ausführungsformen wird der Cache-Speicher unter verschiedenen Komponenten des Prozessors 102 geteilt. In einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z. B. einen Level-3(L3)-Cache oder Last-Level-Cache (LLC) (nicht gezeigt), welcher unter den Prozessorkernen 107 unter Verwendung bekannter Cache-Kohärenz-Techniken geteilt werden kann. Eine Registerdatei 106 ist zusätzlich in dem Prozessor 102 enthalten, welche verschiedene Arten von Registern zum Speichern von verschiedenen Arten von Daten (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister) aufweisen kann. Einige Register können Universalregister sein, während andere Register spezifisch bezüglich der Gestaltung des Prozessors 102 sein können.
In einigen Ausführungsformen sind ein oder mehrere Prozessor(en) mit einem oder mehreren Schnittstellenbus(sen) 110 gekoppelt, um Kommunikationssignale, wie etwa 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 etwa eine Version des DMI(Direct Media Interface, Direkte Medienschnittstelle)-Busses. Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Periphere Komponentenverschaltungsbusse (z. B. PCI, PCI Express), Speicherbusse oder sonstige Arten von Schnittstellenbussen umfassen. In einer Ausführungsform weist bzw. weisen der bzw. die Prozessor(en) 102 einen integrierten Speichercontroller 116 und einen Plattformcontrollerhub 130 auf. Der Speichercontroller 116 ermöglicht die Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der Plattformcontrollerhub (PCH) 130 Verbindungen mit E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Speichervorrichtung 120 kann eine dynamische Direktzugriffsspeicher(DRAM, Direct Random Access Memory)-vorrichtung, eine statische Direktzugriffsspeicher(SRAM, Static Random Access Memory)-vorrichtung, eine Flash-Speichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Speichervorrichtung, die eine geeignete Leistungsfähigkeit aufweist, um als Prozessspeicher zu dienen, sein. In einer Ausführungsform kann die Speichervorrichtung 120 als Systemspeicher für das System 100 wirken, um Daten 122 und Anweisungen 121 zur Verwendung, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen, zu speichern. Der Speichercontroller 116 ist auch mit einem optionalen externen Grafikprozessor 122 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 eine Anzeigevorrichtung 111 mit dem bzw. den Prozessor(en) 102 verbunden sein. Die Anzeigevorrichtung 111 kann eine oder mehrere einer internen Anzeigevorrichtung, wie in einer mobilen elektronischen Vorrichtung oder einer Laptop-Vorrichtung, oder einer externen Anzeigevorrichtung, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) verbunden ist, sein. In einer Ausführungsform kann die Anzeigevorrichtung 111 eine am Kopf montierte Anzeige (HMD, Head Mounted Display), wie etwa eine stereoskopische Anzeigevorrichtung zur Verwendung bei VR(Virtual Reality)-Anwendungen oder AR(Augmented Reality)-Anwendungen, sein.
In einigen Ausführungsformen ermöglicht der Plattformcontrollerhub 130 Peripherievorrichtungen, sich mit der Speichervorrichtung 120 und dem Prozessor 102 über einen Hochgeschwindigkeits-E/A-Bus zu verbinden. Die E/A-Peripherievorrichtungen umfassen einen Audio-Controller 146, einen Netzwerk-Controller 134, eine Firmware-Schnittstelle 128, einen drahtlosen Sendeempfänger 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (z. B. Festplatte, Flash-Speicher usw.), ohne jedoch darauf beschränkt zu sein. Die Datenspeichervorrichtung 124 kann sich über eine Speicherschnittstelle (z. B. SATA) oder über einen peripheren Bus, wie etwa einen Peripheren Komponentenverschaltungsbus (z. B. PCI, PCI Express), verbinden. Die Berührungssensoren 125 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren umfassen. Der drahtlose Sendeempfänger 126 kann ein Wi-Fi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein mobiler Netzwerk-Sendeempfänger, wie etwa ein 3G-, 4G- oder Langzeitentwicklungs(LTE, Long Term Evolution)-Sendeempfänger, sein. Die Firmware-Schnittstelle 128 ermöglicht eine Kommunikation mit System-Firmware und kann zum Beispiel eine vereinheitlichte erweiterbare Firmware-Schnittstelle (UEFI, Unified Extensible Firmware Interface) sein. Der Netzwerk-Controller 134 kann eine Netzwerkverbindung mit einem drahtgebundenen Netzwerk ermöglichen. In einigen Ausführungsformen ist ein Hochleistungs-Netzwerkcontroller (nicht gezeigt) mit dem Schnittstellenbus 110 gekoppelt. Der Audio-Controller 146 ist in einer Ausführungsform ein Mehrkanalhochauflösungs-Audio-Controller. In einer Ausführungsform weist das System 100 einen optionalen alten E/A-Controller 140 zum Koppeln von alten (z. B. Personal System 2(PS/2)-) Vorrichtungen mit dem System auf. Der Plattform-Controller-Hub 130 kann sich auch mit einem oder mehreren universellen seriellen Bus(USB)-Controllern 142, Verbindungseingabevorrichtungen, wie etwa Kombinationen von Tastatur und Maus 143, einer Kamera 144 oder sonstigen USB-Eingabevorrichtungen verbinden.
Es wird ersichtlich sein, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da auch andere Arten von Datenverarbeitungssystemen verwendet werden können, die unterschiedlich konfiguriert sind. Zum Beispiel kann eine Instanz des Speichercontrollers 116 und des Plattform-Controller-Hubs 130 in einen diskreten externen Grafikprozessor, wie etwa der externe Grafikprozessor 112, integriert sein. In einer Ausführungsform können der Plattform-Controller-Hub 130 und/oder der Speichercontroller 116 extern in Bezug auf den einen oder die mehreren Prozessor(en) 102 sein. Zum Beispiel kann das System 100 einen externen Speichercontroller 116 und einen Plattform-Controller-Hub 130 aufweisen, welche als ein Speichercontroller-Hub und ein peripherer Controller-Hub innerhalb eines Systemchipsatzes konfiguriert sein können, der mit dem bzw. den Prozessor/Prozessoren 102 kommuniziert.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200, der einen oder mehrere Prozessorkerne 202A-202N, einen integrierten Speichercontroller 214 und einen integrierten Grafikprozessor 208 aufweist. Diejenigen Elemente aus 2, die dieselben Bezugszeichen (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine beliebige ähnliche Art wie die andernorts hierin beschriebene wirken oder funktionieren, sind jedoch nicht darauf beschränkt. Der Prozessor 200 kann zusätzliche Kerne bis zu und einschließlich dem zusätzlichen Kern 202N, der durch die Kästen mit gestrichelten Linien dargestellt ist, aufweisen. 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 geteilte in Cache gespeicherte Einheiten 206.
Die internen Cache-Einheiten 204A-204N und die geteilten Cache-Einheiten 206 stellen eine Cache-Speicherhierarchie innerhalb des Prozessors 200 dar. Die Cache-Speicherhierarchie kann mindestens eine Ebene von Anweisungs- und Datencache innerhalb von jedem Prozessorkern und eine oder mehrere Ebenen von gemeinsamem Mid-Level-Cache, wie etwa ein Level 2(L2)-Cache, Level 3(L3)-Cache, Level 4(L4)-Cache oder andere Cache-Ebenen, wobei die höchste Cache-Ebene vor dem externen Speicher als der LLC klassifiziert ist, aufweisen. In einigen Ausführungsformen behält die Cachekohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A-204N bei.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von einem oder mehreren Bus-Controller-Einheiten 216 und einen Systemagentenkern 210 aufweisen. Die eine oder die mehreren Bus-Controller-Einheiten 216 verwalten einen Satz peripherer Busse, wie etwa ein oder mehrere PCI- oder PCI Express-Busse. Der Systemagentenkern 210 stellt eine Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. In einigen Ausführungsformen weist der Systemagentenkern 210 einen oder mehrere integrierte Speichercontroller 214 auf, um den Zugriff auf verschiedene externe Speichervorrichtungen (nicht gezeigt) zu verwalten.
In einigen Ausführungsformen weisen einer oder mehrere der Prozessorkerne 202A-202N Unterstützung für simultanes Multithreading auf. In solch einer Ausführungsform weist der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A-202N während einer Multithreading-Verarbeitung auf. Der Systemagentenkern 210 kann zusätzlich eine Leistungssteuereinheit (PCU, Power Control Unit) aufweisen, welche Logik und Komponenten zum Regeln des Leistungszustands der Prozessorkerne 202A-202N und des Grafikprozessors 208 aufweist.
In einigen Ausführungsformen weist der Prozessor 200 zusätzlich den Grafikprozessor 208 auf, um Grafikverarbeitungsoperationen auszuführen. In einigen Ausführungsformen ist der Grafikprozessor 208 mit dem Satz geteilter Cache-Einheiten 206 und dem Systemagentenkern 210 einschließlich des einen oder der mehreren integrierten Speichercontroller 214 gekoppelt. In einigen Ausführungsformen weist der Systemagentenkern 210 auch einen Anzeigecontroller 211 zum Steuern der Grafikprozessorausgabe an eine oder mehrere gekoppelte Anzeigen auf. In einigen Ausführungsformen kann der Anzeigecontroller 211 auch ein separates Modul sein, das mit dem Grafikprozessor über mindestens eine Verschaltung gekoppelt ist, oder kann innerhalb von dem Grafikprozessors 208 integriert sein.
In einigen Ausführungsformen wird eine ringbasierte Verschaltungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch eine alternative Verschaltungseinheit verwendet werden, wie etwa eine Punkt-zu-Punkt-Verschaltung, eine geschaltete Verschaltung oder andere Techniken einschließlich im Stand der Technik hinreichend bekannter Techniken. In einigen Ausführungsformen ist der Grafikprozessor 208 mit der Ringverschaltung 212 über einen E/A-Link 213 gekoppelt.
Der beispielhafte E/A-Link 213 stellt mindestens eine von mehreren Varianten von E/A-Verschaltungen einschließlich einer On-Package-E/A-Verschaltung, welche eine Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsspeichermodul 218, wie etwa einem eDRAM-Modul, ermöglicht, dar. In einigen Ausführungsformen verwenden jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 die eingebetteten Speichermodule 218 als einen geteilten Last-Level-Cache.
In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, die dieselbe Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A-202N heterogen hinsichtlich der Anweisungssatzarchitektur (ISA, Instruction Set Architecture), wo einer oder mehrere der Prozessorkerne 202A-202N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N heterogen hinsichtlich der Mikroarchitektur, wo ein oder mehrere Kerne, die einen relativ höheren Stromverbrauch aufweisen, mit einem oder mehreren Leistungskernen, die einen geringeren Stromverbrauch aufweisen, gekoppelt sind. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte SoC-Schaltung, die die veranschaulichten Komponenten zusätzlich zu anderen Komponenten aufweist, implementiert sein.
3 ist ein Blockdiagramm eines Grafikprozessors 300, welcher eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen integriert ist. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die in den Prozessorspeicher platziert sind. In einigen Ausführungsformen weist der Grafikprozessor 300 eine Speicherschnittstelle 314 auf, um auf den Speicher zuzugreifen. Die Speicherschnittstelle 314 kann eine Schnittstelle zu einem lokalen Speicher, einem oder mehreren internen Caches, einem oder mehreren geteilten externen Caches und/oder zu dem Systemspeicher sein.
In einigen Ausführungsformen weist der Grafikprozessor 300 auch einen Anzeigecontroller 302 zum Steuern der Anzeigeausgabedaten an eine Anzeigevorrichtung 320 auf. Der Anzeigecontroller 302 weist Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Zusammensetzung von mehreren Schichten von Video oder Benutzerschnittstellenelementen auf. Die Anzeigevorrichtung 320 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 320 eine am Kopf montierte Anzeigevorrichtung, wie etwa eine VR(Virtual Reality)-Anzeigevorrichtung oder eine AR(Augmented Reality)-Anzeigevorrichtung. In einigen Ausführungsformen weist der Grafikprozessor 300 eine Videocodecengine 306 zum Codieren, Decodieren oder Umcodieren von Medien in, von oder zwischen einem oder mehreren Mediencodierungsformaten einschließlich MPEG(Moving Picture Experts Group)-Formaten, wie etwa MPEG-2, AVC(Advanced Video Coding)-Formaten, wie etwa H.264/MPEG-4 AVC, sowie die SMPTE(Society ofMotion Picture & Television Engineers) 421M/VC-1 und JPEG(Joint Photographic Experts Group)-Formate, wie etwa JPEG- und MJPEG(Motion JPEG)-Formate, ohne jedoch darauf beschränkt zu sein, auf.
In einigen Ausführungsformen weist der Grafikprozessor 300 eine Blockbildübertragungs(BLIT(Block Image Transfer))-engine 304 auf, um zweidimensionale (2D) Rasterisiereroperationen einschließlich zum Beispiel Bit-Grenzen-Blockübertragungen durchzuführen. In einer Ausführungsform werden jedoch 2D-Grafikoperationen unter Verwendung von einer oder mehreren Komponenten der Grafikverarbeitungsengine (GPE, Graphics Processing Engine) 310 durchgeführt. In einigen Ausführungsformen ist die GPE 310 eine Rechenengine 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, wie etwa das Rendern von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Grundformen wirken (z. B. Rechteck, Dreieck usw.), auf. Die 3D-Pipeline 312 weist programmierbare Elemente und Festfunktionselemente auf, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungsthreads für ein 3D/Medien-Untersystem 315 hervorbringen. Wenngleich die 3D-Pipeline 312 verwendet werden kann, um Medienoperationen durchzuführen, umfasst eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316, die spezifisch verwendet wird, um Medienoperationen, wie etwa Videonachbearbeitung und Bildverbesserung, durchzuführen.
In einigen Ausführungsformen weist die Medien-Pipeline 316 Festfunktionslogikeinheiten oder programmierbare Logikeinheiten auf, um eine oder mehrere spezialisierte Medienoperationen, wie etwa Videodecodierbeschleunigung, Video-Deinterlacing und Videocodierbeschleunigung, anstelle von oder zugunsten der Videocodecengine 306 durchzuführen. In einigen Ausführungsformen weist die Medien-Pipeline 316 zusätzlich eine Threadhervorbringungseinheit auf, um Threads zur Ausführung auf dem 3D/Medien-Untersystem 315 hervorzubringen. Die hervorgebrachten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die in dem 3D/Medien-Untersystem 315 enthalten sind.
In einigen Ausführungsformen weist das 3D/Medien-Untersystem 315 eine Logik zum Ausführen von Threads, die von der 3D-Pipeline 312 und der Medien-Pipeline 316 hervorgebracht werden, auf. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanforderungen zum 3D/Medien-Untersystem 315, das eine Thread-Abfertigungslogik aufweist, um die verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen zu arbitrieren und abzufertigen. Die Ausführungsressourcen weisen eine Anordnung von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medienthreads auf. 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 geteilten Speicher einschließlich Register und adressierbarer Speicher, um Daten zwischen Threads zu teilen und ausgegebene Daten zu speichern, auf.
Grafikverarbeitungsengine
4 ist ein Blockdiagramm einer Grafikverarbeitungsengine 410 eines Grafikprozessors gemäß einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungsengine (GPE, Graphics Processing Engine) 410 eine Version der GPE 310, die in 3 gezeigt ist. Diejenigen Elemente aus 4, die dieselben Bezugszeichen (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine beliebige ähnliche Art wie die andernorts hierin beschriebene wirken 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 aufgenommen. Zum Beispiel ist in mindestens einer Ausführungsform ein separater Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
In einigen Ausführungsformen ist die GPE 410 mit einem Befehls-Streamer 403 gekoppelt oder weist diesen auf, welcher einen Befehlsstrom der 3D-Pipeline 312 und/oder den Medien-Pipelines 316 bereitstellt. In einigen Ausführungsformen ist der Befehls-Streamer 403 mit dem Speicher, welcher Systemspeicher sein kann, oder einem oder mehreren des internen Cache-Speichers und des geteilten Cache-Speichers gekoppelt. In einigen Ausführungsformen erhält der Befehls-Streamer 403 Befehle von dem Speicher und sendet die Befehle zu der 3D-Pipeline 312 und/oder der Medien-Pipeline 316. Die Befehle sind Richtlinien, 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 zusätzlich Stapelbefehlspuffer aufweisen, die Stapel von mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Bezugnahmen auf Daten, die in dem Speicher gespeichert sind, wie etwa Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316, ohne jedoch darauf beschränkt zu sein, umfassen. Die 3D-Pipeline 312 und die Medien-Pipeline 316 verarbeiten die Befehle und Daten durch Durchführen von Operationen über eine Logik innerhalb der jeweiligen Pipelines oder durch Abfertigen von einem oder mehreren Ausführungsthreads an eine Grafikkernanordnung 414. In einer Ausführungsform weist die Grafikkernanordnung 414 einen oder mehrere Blöcke von Grafikkernen (z. B. der/die Grafikkern(e) 415A, der/die Grafikkern(e) 415B) auf, wobei jeder Block einen oder mehrere Grafikkerne umfasst. Jeder Grafikkern umfasst einen Satz Grafikausführungsressourcen, die eine Universal-Ausführungslogik und eine grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Rechenoperationen sowie eine Festfunktionstexturverarbeitungslogik und/oder eine Maschinenlern- und Beschleunigungslogik mit künstlicher Intelligenz umfassen.
In verschiedenen Ausführungsformen weist die 3D-Pipeline 312 eine Festfunktionslogik und eine programmierbare Logik auf, um ein oder mehrere Shader-Programme zu verarbeiten, wie etwa Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Rechen-Shader oder sonstige Shader-Programme, indem die Anweisungen verarbeitet und Ausführungsthreads für die Grafikkernanordnung 414 abgefertigt werden. Die Grafikkernanordnung 414 stellt einen vereinheitlichten Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shader-Programme bereit. Eine Mehrzweckausführungslogik (z. B. Ausführungseinheiten) innerhalb des bzw. der Grafikkerns/Grafikkerne 415A-415B der Grafikkernanordnung 414 weist eine Unterstützung für verschiedene 3D API-Shadersprachen auf und kann mehrere simultane Ausführungsthreads ausführen, die mit mehreren Shadern verknüpft sind.
In einigen Ausführungsformen weist die Grafikkernanordnung 414 auch eine Ausführungslogik zum Durchführen von Medienfunktionen, wie etwa Video- und/oder Bildverarbeitung, auf. In einer Ausführungsform weisen die Ausführungseinheiten zusätzlich eine Universallogik auf, die programmierbar ist, um parallele Universalrechenoperationen zusätzlich zu Grafikverarbeitungsoperationen durchzuführen. Die Universallogik kann Verarbeitungsoperationen parallel oder zusammen mit der Universallogik innerhalb des/der Prozessorkerns/Prozessorkerne 107 von 1 oder des Kerns 202A-202N wie in 2 durchführen.
Ausgabedaten, die durch Threads erzeugt werden, die auf der Grafikkernanordnung 414 ausgeführt werden, können Daten an den Speicher in einem vereinheitlichten Rücklaufpuffer (URB, Unified Return Buffer) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen verschiedenen Threads zu senden, die auf der Grafikkernanordnung 414 ausgeführt werden. In einigen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisierung zwischen Threads auf der Grafikkernanordnung und der Festfunktionslogik innerhalb der geteilten Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist die Grafikkernanordnung 414 skalierbar, so dass die Anordnung eine variable Anzahl an Grafikkernen aufweist, die jeweils eine variable Anzahl an Ausführungseinheiten basierend auf der Zielleistung und der Leistungsstufe der GPE 410 aufweisen. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, so dass die Ausführungsressourcen je nach Bedarf aktiviert oder deaktiviert werden können.
Die Grafikkernanordnung 414 ist mit der geteilten Funktionslogik 420 gekoppelt, die mehrere Ressourcen aufweist, die unter den Grafikkernen in der Grafikkernanordnung geteilt werden. Die geteilten Funktionen innerhalb der geteilten Funktionslogik 420 sind Hardwarelogikeinheiten, die der Grafikkernanordnung 414 eine spezialisierte ergänzende Funktionalität bereitstellen. In verschiedenen Ausführungsformen weist die geteilte Funktionslogik 420 eine Abtaster- 421, eine Mathematik- 422 und eine Zwischen-Thread-Kommunikations(ITC, Inter-Thread Communication) 433 -Logik auf, ohne jedoch darauf beschränkt zu sein. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Cache(s) 425 innerhalb der geteilten Funktionslogik 420.
Eine geteilte Funktion wird dort implementiert, wo die Nachfrage nach einer gegebenen spezialisierten Funktion nicht zur Aufnahme innerhalb der Grafikkernanordnung 414 ausreicht. Stattdessen ist eine einzelne Instantiierung jener spezialisierten Funktion als eine alleinstehende Entität in der geteilten Funktionslogik 420 implementiert und wird unter den Ausführungsressourcen innerhalb der Grafikkernanordnung 414 geteilt. Die genaue Gruppe von Funktionen, die unter der Grafikkernanordnung 414 geteilt werden und innerhalb der Grafikkernanordnung 414 enthalten sind, variiert unter den Ausführungsformen. In einigen Ausführungsformen können spezifische geteilte Funktionen innerhalb der geteilten Funktionslogik 420, die extensiv von der Grafikkernanordnung 414 verwendet werden, innerhalb der geteilten Funktionslogik 416 innerhalb der Grafikkernanordnung 414 enthalten sein. In verschiedenen Ausführungsformen kann die geteilte Funktionslogik 416 innerhalb der Grafikkernanordnung 414 die gesamte Logik oder einen Teil davon innerhalb der geteilten Funktionslogik 420 umfassen. In einer Ausführungsform können alle Logikelemente innerhalb der geteilten Funktionslogik 420 innerhalb der geteilten Funktionslogik 416 der Grafikkernanordnung 414 dupliziert werden. In einer Ausführungsform ist die geteilte Funktionslogik 420 zugunsten der geteilten Funktionslogik 416 innerhalb der Grafikkernanordnung 414 ausgeschlossen.
5 ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns 500 gemäß einigen Ausführungsformen, die hierin beschrieben sind. Diejenigen Elemente aus 5, die dieselben Bezugszeichen (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine beliebige ähnliche Art wie die andernorts hierin beschriebene wirken oder funktionieren, sind jedoch nicht darauf beschränkt. Der veranschaulichte Grafikprozessorkern 500 ist in einigen Ausführungsformen innerhalb der Grafikkernanordnung 414 von 4 enthalten. Der Grafikprozessorkern 500, der manchmal als ein Kern-Slice bezeichnet wird, kann ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 500 ist beispielhaft für ein Grafikkernslice, und ein Grafikprozessor, wie er hierin beschrieben ist, kann mehrere Grafikkernslices basierend auf der Zielleistung und dem Leistungsumfang aufweisen. Jeder Grafikkern 500 kann einen Festfunktionsblock 530 aufweisen, der mit mehreren Teilkernen 501A-501F gekoppelt ist, die auch als Teil-Slices bezeichnet werden, die modulare Blöcke einer Universal- und Festfunktionslogik aufweisen.
In einigen Ausführungsformen weist der Festfunktionsblock 530 eine Geometrie-/Festfunktionspipeline 536 auf, die von allen Teilkernen in dem Grafikprozessor 500 geteilt werden kann, zum Beispiel bei Grafikprozessorimplementierungen mit geringerer Leistungsfähigkeit und/oder geringerer Leistung. In verschiedenen Ausführungsformen umfasst die Geometrie-/Festfunktionspipeline 536 eine 3D-Festfunktionspipeline (z. B. die 3D-Pipeline 312, wie in 3 und 4), eine Video-Front-End-Einheit, einen Thread-Spawner und einen Thread-Abfertiger und einen vereinheitlichten Rücklaufpuffermanager, welcher vereinheitlichte Rücklaufpuffer verwaltet, wie etwa den vereinheitlichten Rücklaufpuffer 418 von 4.
In einer Ausführungsform weist der Festfunktionsblock 530 auch eine Grafik-SoC-Schnittstelle 537, einen Grafik-Mikrocontroller 538 und eine Medien-Pipeline 539 auf. Die Grafik-SoC-Schnittstelle 537 stellt eine Schnittstelle zwischen dem Grafikkern 500 und anderen Prozessorkernen innerhalb einer integrierten System-on-a-Chip-Schaltung bereit. Der Grafik-Mikrocontroller 538 ist ein programmierbarer Teilprozessor, der konfiguriert werden kann, um verschiedene Funktionen des Grafikprozessors 500 einschließlich Thread-Abfertigung, Planung und Vorwegnahme zu verwalten. Die Medien-Pipeline 539 (z. B. die Medien-Pipeline 316 von 3 und 4) weist eine Logik zum Ermöglichen der Decodierung, Codierung, Vorverarbeitung und/oder Nachbearbeitung von Multimediadaten einschließlich Bild- und Videodaten auf. Die Medien-Pipeline 539 implementiert Medienoperationen über Anforderungen an die Rechen- oder Abtastlogik innerhalb der Teilkerne 501-501F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 dem Grafikkern 500, mit Universalanwendungsprozessorkernen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC einschließlich Speicherhierarchieelementen, wie etwa ein geteilter Last-Level-Cache-Speicher, das System-RAM und/oder das eingebettete On-Chip- oder On-Package-DRAM, zu kommunizieren. Die SoC-Schnittstelle 537 kann auch eine Kommunikation mit Festfunktionsvorrichtungen innerhalb des SoC, wie etwa Kamerabildgebungpipelines, ermöglichen, und ermöglicht die Verwendung von globalen Speicheratomen, die unter dem Grafikkern 500 und CPUs innerhalb des SoC geteilt werden können, und/oder implementiert diese. Die SoC-Schnittstelle 537 kann auch Leistungsverwaltungssteuerungen für den Grafikkern 500 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 500 und anderen Taktdomänen innerhalb des SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 den Empfang von Befehlspuffern von einem Befehls-Streamer und einem globalen Thread-Abfertiger, die konfiguriert sind, um jedem von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors Befehle und Anweisungen bereitzustellen. Die Befehle und Anweisungen können für die Medien-Pipeline 539, wenn Medienoperationen durchzuführen sind, oder eine Geometrie- und Festfunktionspipeline (z. B. die Geometrie- und Festfunktionspipeline 536, die Geometrie- und Festfunktionspipeline 514), wenn Grafikverarbeitungsoperationen durchzuführen sind, abgefertigt werden.
Der Grafik-Mikrocontroller 538 kann konfiguriert sein, um verschiedene Planungs- und Verwaltungsaufgaben für den Grafikkern 500 durchzuführen. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 Grafik- und/oder Rechenarbeitslastplanung auf den verschiedenen parallelen Grafikengines innerhalb der Ausführungseinheit(EU, Execution Unit)-anordnungen 502A-502F, 504A-504F innerhalb der Teilkerne 501A-501F durchführen. In diesem Planungsmodell kann die Host-Software, die auf einem CPU-Kern eines SoC einschließlich des Grafikkerns 500 ausgeführt wird, Arbeitslasten einer von mehreren Grafikprozessordoorbells liefern, was eine Planungsoperation auf der geeigneten Grafikengine hervorruft. Die Planungsoperationen umfassen das Bestimmen, welche Arbeitslast als Nächstes auszuführen ist, das Liefern einer Arbeitslast an einen Befehls-Streamer, die Vorwegnahme vorhandener Arbeitslasten, die auf einer Engine ausgeführt werden, das Überwachen des Fortschritts einer Arbeitslast und das Benachrichtigen einer Host-Software, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 auch Zustände mit geringer Leistung oder inaktive Zustände für den Grafikkern 500 ermöglichen, wobei der Grafikkern 500 mit der Fähigkeit, Register innerhalb des Grafikkerns 500 über Übergänge eines Zustands mit geringer Leistung unabhängig von dem Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen, versehen wird.
Der Grafikkern 500 kann mehr als oder weniger als die veranschaulichten Teilkerne 501A-501F, bis zu N modulare Teilkerne, aufweisen. Für jeden Satz von N Teilkernen kann der Grafikkern 500 auch eine geteilte Funktionslogik 510, einen geteilten und/oder Cache-Speicher 512, eine Geometrie-/Festfunktionspipeline 514 sowie eine zusätzliche Festfunktionslogik 516 zum Beschleunigen verschiedener Grafik- und Rechenverarbeitungsoperationen aufweisen. Die geteilte Funktionslogik 510 kann Logikeinheiten aufweisen, die mit der geteilten Funktionslogik 420 von 4 verknüpft sind (z. B. die Abtaster-, die Mathematik- und/oder die Zwischen-Thread-Kommunikationslogik), die von jeden N Teilkernen innerhalb des Grafikkerns 500 geteilt werden kann. Der geteilte und/oder Cache-Speicher 512 kann ein Last-Level-Cache für den Satz von N Teilkernen 501A-501F innerhalb des Grafikkerns 500 sein und kann auch als geteilter Speicher dienen, auf den von mehreren Teilkernen zugegriffen werden kann. Die Geometrie-/Festfunktionspipeline 514 kann anstatt der Geometrie-/Festfunktionspipeline 536 innerhalb des Festfunktionsblocks 530 enthalten sein und dieselben oder ähnliche Logikeinheiten aufweisen.
In einer Ausführungsform weist der Grafikkern 500 eine zusätzliche Festfunktionslogik 516 auf, die verschiedene Festfunktionsbeschleunigungslogiken zur Verwendung durch den Grafikkern 500 umfassen kann. In einer Ausführungsform weist die zusätzliche Festfunktionslogik 516 eine zusätzliche Geometrie-Pipeline zur Verwendung bei Position-only-Shading auf. Bei Position-only-Shading sind zwei Geometriepipelines vorhanden, die volle Geometrie-Pipeline innerhalb der Geometrie-/Festfunktionspipeline 516, 536, und eine Auslesepipeline, welche eine zusätzliche Geometrie-Pipeline ist, welche innerhalb der zusätzlichen Festfunktionslogik 516 enthalten sein kann. In einer Ausführungsform ist die Auslesepipeline eine gekürzte Version der vollen Geometrie-Pipeline. Die volle Pipeline und die Auslesepipeline können verschiedene Instanzen derselben Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Das Position-only-Shading kann lange Ausleseabläufe von verworfenen Dreiecken ausblenden, wobei dem Schattieren ermöglicht wird, in einigen Instanzen früher abgeschlossen zu werden. Beispielsweise und in einer Ausführungsform kann die Auslesepipelinelogik innerhalb der zusätzlichen Festfunktionslogik 516 Positionsshader parallel mit der Hauptanwendung ausführen und erzeugt allgemein kritische Ergebnisse schneller als die volle Pipeline, da die Auslesepipeline nur das Positionsattribut der Vertices abruft und schattiert, ohne eine Rasterisierung und ein Rendern der Pixel zu dem Frame-Puffer durchzuführen. Die Auslesepipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, ohne zu berücksichtigen, ob jene Dreiecke ausgelesen werden. Die volle Pipeline (welche in dieser Instanz als eine Wiederholungspipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verbrauchen, um die ausgelesenen Dreiecke zu überspringen, um nur die sichtbaren Dreiecke zu schattieren, die schließlich an die Rasterisierungsphase übergeben werden.
In einer Ausführungsform kann die zusätzliche Festfunktionslogik 516 auch eine Maschinenlernbeschleunigungslogik, wie etwa eine Festfunktionsmatrixmultiplikationslogik, für Implementierungen einschließlich Optimierungen für Maschinenlerntraining oder Inferenzierung umfassen.
Innerhalb jedes Grafikteilkerns 501A-501F ist ein Satz Ausführungsressourcen enthalten, die verwendet werden können, um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen durch die Grafik-Pipeline, die Medien-Pipeline oder Shader-Programme durchzuführen. Die Grafikteilkerne 501A-501F weisen mehrere EU-Anordnungen 502A-502F, 504A-504F, eine Thread-Abfertigungs- und Zwischen-Thread-Kommunikations(TD/IC)-Logik 503A-503F, einen 3D(z. B. Textur)-Abtaster 505A-505F, einen Mediensampler 506A-506F, einen Shader-Prozessor 507A-507F und einen geteilten lokalen Speicher (SLM, Shared Local Memory) 508A-508F auf. Die EU-Anordnungen 502A-502F, 504A-504F weisen jeweils mehrere Ausführungseinheiten auf, welche Universalgrafikverarbeitungseinheiten sind, die in der Lage sind, Gleitkomma- und Ganzzahl-/Festpunktlogikoperationen beim Dienst einer Grafik-, Medien- oder Rechenoperation durchzuführen, einschließlich Grafik-, Medien- oder Rechen-Shader-Programmen. Die TD/IC-Logik 503A-503F führt lokale Threadabfertigungs- und Threadsteueroperationen für die Ausführungseinheiten innerhalb eines Teilkerns durch und ermöglicht die Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Teilkerns ausgeführt werden. Der 3D-Abtaster 505A-505F kann Textur oder andere 3D-Grafikbezogene Daten in den Speicher einlesen. Der 3D-Abtaster kann Texturdaten unterschiedlich basierend auf einem konfigurierten Abtastungszustand und dem Texturformat in Verbindung mit einer gegebenen Textur lesen. Der Mediensampler 506A-506F kann ähnliche Leseoperationen basierend auf der Art und dem Format in Verbindung mit Mediendaten durchführen. In einer Ausführungsform kann jeder Grafikteilkern 501A-501F abwechselnd einen vereinheitlichten 3D- und einen Mediensampler aufweisen. Threads, die auf den Ausführungseinheiten innerhalb von jedem der Teilkerne 501A-501F ausgeführt werden, können den geteilten lokalen Speicher 508A-508F innerhalb von jedem Teilkern verwenden, um zu ermöglichen, dass Threads, die innerhalb eines Thread-Satzes ausgeführt werden, unter Verwendung einer geteilten Gruppe eines On-Chip-Speichers ausgeführt werden.
Ausführungseinheiten
6A-6B veranschaulichen eine Thread-Ausführungslogik 600 einschließlich einer Anordnung von Verarbeitungselementen, die in einem Grafikprozessorkern eingesetzt werden, gemäß hierin beschriebenen Ausführungsformen. Diejenigen Elemente von 6A-6B, die dieselben Bezugszeichen (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine beliebige ähnliche Art wie die andernorts hierin beschriebene wirken oder funktionieren, sind jedoch nicht darauf beschränkt. 6A veranschaulicht eine Übersicht der Thread-Ausführungslogik 600, welche eine Variante der Hardwarelogik umfassen kann, die mit jedem Teilkern 501A-501F von 5 veranschaulicht ist. 6B veranschaulicht beispielhafte interne Details einer Ausführungseinheit.
Wie in 6A veranschaulicht ist, weist in einigen Ausführungsformen die Thread-Ausführungslogik 600 einen Shader-Prozessor 602, einen Thread-Abfertiger 604, einen Anweisungscache 606, eine skalierbare Ausführungseinheitsanordnung mit mehreren Ausführungseinheiten 608A-608N, einen Abtaster 610, einen Datencache 612 und einen Datenport 614 auf. In einer Ausführungsform kann die skalierbare Ausführungseinheitsanordnung durch Aktivieren oder Deaktivieren von einer oder mehreren Ausführungseinheiten (z. B. einer beliebigen der Ausführungseinheit 608A, 608B, 608C, 608D bis 608N-1 und 608N) basierend auf den Rechenanforderungen einer Arbeitslast dynamisch skalieren. In einer Ausführungsform sind die enthaltenen Komponenten über ein Verbindungsfabric verbunden, das mit jeder der Komponenten verknüpft ist. In einigen Ausführungsformen weist die Thread-Ausführungslogik 600 eine oder mehrere Verbindungen zum Speicher in der Art des Systemspeichers oder eines Cache-Speichers über einen oder mehrere vom Anweisungscache 606, vom Datenport 614, vom Abtaster 610 und von den Ausführungseinheiten 608A-608N auf. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 608A) eine alleinstehende programmierbare Universalrecheneinheit, die in der Lage ist, mehrere simultane Hardware-Threads auszuführen, während mehrere Datenelemente parallel für jeden Thread verarbeitet werden. In verschiedenen Ausführungsformen ist die Anordnung der Ausführungseinheiten 608A-608N derart skalierbar, dass sie eine beliebige Anzahl an einzelnen Ausführungseinheiten aufweist.
In einigen Ausführungsformen werden die Ausführungseinheiten 608A-608N in erster Linie für das Ausführen von „Shader“-Programmen verwendet. Ein Shader-Prozessor 602 kann die verschiedenen Shader-Programme verarbeiten und Ausführungsthreads, die mit den Shader-Programmen verknüpft sind, über einen Thread-Abfertiger 604 abfertigen. In einer Ausführungsform weist der Thread-Abfertiger eine Logik zum Arbitrieren von Thread-Initiierungsanforderungen von den Grafik- und Medien-Pipelines und Instantiieren der angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 608A-608N auf. Zum Beispiel kann eine Geometrie-Pipeline Vertex-, Tesselations- oder Geometrie-Shader für die Thread-Ausführungslogik zur Verarbeitung abfertigen. In einigen Ausführungsformen kann der Thread-Abfertiger 604 auch Laufzeit-Thread-Hervorbringungsanforderungen von den ausführenden Shader-Programmen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N einen Anweisungssatz, der derart eine native Unterstützung für viele Standard-3D-Grafik-Shader-Anweisungen aufweist, dass Shader-Programme von Grafikbibliotheken (beispielsweise Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen eine Vertex- und Geometrieverarbeitung (z. B. Vertexprogramme, Geometrieprogramme, Vertex-Shader), eine Pixelverarbeitung (z. B. Pixel-Shader, Fragment-Shader) und eine Universalverarbeitung für allgemeine Zwecke (z. B. Rechen-und Medien-Shader). Jede der Ausführungseinheiten 608A-608N ist zur Mehrfachausgabe-Einzelanweisungs-Mehrfachdaten(SIMD, Single Instruction Multiple Data)-Ausführung in der Lage, und eine Multi-Threading-Operation mit mehreren Threads ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb von jeder Ausführungseinheit weist eine dedizierte Registerdatei mit großer Bandbreite und einem zugehörigen unabhängigen Thread-Zustand auf. Die Ausführung wird mehrmals pro Takt bezüglich Pipelines ausgegeben, die zu Ganzzahl-, Einzel- und Doppelgenauigkeitsgleitkommaoperationen, SIMD-Verzweigungsfähigkeit, logische Operationen, transzendente Operationen und sonstige verschiedene Operationen in der Lage sind. Während auf Daten aus dem Speicher oder eine der geteilten Funktionen gewartet wird, bewirkt die Abhängigkeitslogik innerhalb der Ausführungseinheiten 608A-608N, dass ein wartender Thread ruht, bis die angeforderten Daten zurückgegeben worden sind. Während der wartende Thread ruht, können Hardwareressourcen zur Verarbeitung anderer Threads verwendet werden. Zum Beispiel kann während einer Verzögerung, die mit einer Vertex-Shader-Operation verknüpft ist, eine Ausführungseinheit Operationen für einen Pixel-Shader, Fragment-Shader oder eine andere Art von Shader-Programm einschließlich eines anderen Vertex-Shaders durchführen.
Jede Ausführungseinheit in den Ausführungseinheiten 608A-608N wirkt an Anordnungen von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ oder die Anzahl der Kanäle für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für den Datenelementzugriff, die Maskierung und die Ablaufsteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann von der Anzahl der physikalischen arithmetischen logischen Einheiten (ALU, Arithmetic Logic Units) oder Gleitkommaeinheiten (FPU, Floating Point Units) für einen konkreten Grafikprozessor unabhängig sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N ganzzahlige und Gleitkommadatentypen.
Der Ausführungseinheitsanweisungsssatz umfasst SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert werden, und die Ausführungseinheit wird die verschiedenen Elemente basierend auf der Datengröße der Elemente verarbeiten. Wenn beispielsweise ein 256 Bit breiter Vektor verarbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert und verarbeitet die Ausführungseinheit den Vektor als vier getrennte 64-Bit-gepackte Datenelemente (Vier-Wort-(QW, Quad-Word)-Größen-Datenelemente), acht getrennte 32-Bit-gepackte Datenelemente (Doppel-Wort-(DW)-Größen-Datenelemente), sechzehn getrennte 16-Bit-gepackte Datenelemente (Wort-(W)-Größen-Datenelemente) oder zweiunddreißig getrennte 8-Bit-Datenelemente (Byte-(B)-Größen-Datenelemente). Es sind jedoch auch andere Vektorbreiten und Registergrößen möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten zu einer zusammengefügten Ausführungseinheit 609A-609N kombiniert werden, die eine Thread-Steuerlogik (607A-607N) aufweist, die für die zusammengefügten EUs gemeinsam ist. Mehrere Ausführungseinheiten können zu einer EU-Gruppe zusammengefügt werden. Jede EU in der zusammengefügten EU-Gruppe kann konfiguriert sein, um einen separaten SIMD-Hardware-Thread auszuführen. Die Anzahl an EUs in einer zusammengefügten EU-Gruppe kann gemäß den Ausführungsformen variieren. Zusätzlich können verschiedene SIMD-Breiten pro EU einschließlich SIMD8, SIMD16 und SIMD32, ohne jedoch auf diese beschränkt zu sein, realisiert werden. Jede zusammengefügte Grafikausführungseinheit 609A-609N umfasst mindestens zwei Ausführungseinheiten. Zum Beispiel umfasst die zusammengefügte Ausführungseinheit 609A eine erste EU 608A, eine zweite EU 608B und eine Thread-Steuerlogik 607A, die der ersten EU 608A und der zweiten EU 608B gemeinsam ist. Die Thread-Steuerlogik 607A steuert Threads, die auf der zusammengefügten Grafikausführungseinheit 609A ausgeführt werden, wobei jeder EU innerhalb der zusammengefügten Ausführungseinheiten 609A-609N erlaubt wird, unter Verwendung eines geteilten Anweisungszeigerregisters ausgeführt zu werden.
Ein oder mehrere interne Anweisungscaches (z. B. 606) sind in die Thread-Ausführungslogik 600 aufgenommen, um Thread-Anweisungen für die Ausführungseinheiten in dem Cache zu speichern. In einigen Ausführungsformen sind ein oder mehrere Datencaches (z. B. 612) aufgenommen, um Thread-Daten während der Thread-Ausführung in dem Cache zu speichern. In einigen Ausführungsformen ist ein Abtaster 610 aufgenommen, um eine Texturabtastung für 3D-Operationen und eine Medienabtastung für Medienoperationen bereitzustellen. In einigen Ausführungsformen weist der Abtaster 610 eine spezialisierte Textur-oder Medienabtastfunktionalität für das Verarbeiten von Textur- oder Mediendaten während des Abtastprozesses auf, bevor die abgetasteten Daten einer Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und die Medien-Pipeline Thread-Initiierungsanforderungen über die Thread-Hervorbringungs- und Abfertigungslogik zur Thread-Ausführungslogik 600. Sobald eine Gruppe von geometrischen Objekten verarbeitet und in Pixeldaten rasterisiert wurde, wird eine Pixelprozessorlogik (z. B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) innerhalb des Shader-Prozessors 602 aufgerufen, um ferner Ausgabeinformationen zu berechnen und zu bewirken, dass Ergebnisse in Ausgabeflächen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In einigen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertexattribute, die über das rasterisierte Objekt zu interpolieren sind. In einigen Ausführungsformen führt die Pixelprozessorlogik innerhalb des Shader-Prozessors 602 dann ein API(Application Programming Interface, Anwendungsprogrammierschnittstelle)-zugeführtes Pixel- oder Fragment-Shader-Programm aus. Zur Ausführung des Shader-Programms fertigt der Shader-Prozessor 602 Threads über den Thread-Abfertiger 604 für eine Ausführungseinheit (z. B. 608A) ab. In einigen Ausführungsformen verwendet der Shader-Prozessor 602 eine Texturabtastlogik in dem Abtaster 610, um auf Texturdaten in Texturkarten, die in dem Speicher gespeichert sind, zuzugreifen. Arithmetische Operationen an den Texturdaten und den eingegebenen Geometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel derart, dass sie nicht weiterverarbeitet werden.
In einigen Ausführungsformen stellt der Datenport 614 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 600 bereit, um verarbeitete Daten zur weiteren Verarbeitung auf einer Grafikprozessorausgabepipeline an den Speicher auszugeben. In einigen Ausführungsformen weist der Datenport 614 einen oder mehrere Cache-Speicher (z. B. den Datencache 612) auf oder ist damit gekoppelt, um Daten für den Speicherzugriff über den Datenport in dem Cache zu speichern.
Wie in 6B veranschaulicht ist, kann eine Grafikausführungseinheit 608 eine Anweisungsabrufeinheit 637, eine allgemeine Registerdateianordnung (GRF, General Register File) 624, eine architektonische Registerdateianordnung (ARF, Architectural Register File) 626, einen Thread-Arbitrierer 622, eine Sendeeinheit 630, eine Verzweigungseinheit 632, einen Satz SIMD-Gleitkommaeinheiten (FPUs, Floating Point Units) 634 und in einer Ausführungsform einen Satz dedizierter ganzzahliger SIMD ALUs 635 aufweisen. Die GRF 624 und die ARF 626 umfassen den Satz allgemeiner Registerdateien und Architekturregisterdateien, die mit jedem simultanen Hardware-Thread verknüpft sind, der in der Grafikausführungseinheit 608 aktiv sein kann. In einer Ausführungsform wird ein architektonischer Zustand pro Thread in der ARF 626 aufrechterhalten, 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 aufgenommen werden.
In einer Ausführungsform weist die Grafikausführungseinheit 608 eine Architektur auf, die eine Kombination von Simultanem Multithreading (SMT) und feinkörnigem verschachteltem Multi-Threading (IMT, Interleaved Multi-Threading) ist. Die Architektur weist eine modulare Konfiguration auf, die zur Gestaltungszeit fein eingestellt werden kann basierend auf einer Zielanzahl von simultanen Threads und einer Anzahl an Registern pro Ausführungseinheit, wobei die Ausführungseinheitsressourcen über die Logik aufgeteilt sind, die verwendet wird, um mehrere simultane Threads auszuführen.
In einer Ausführungsform kann die Grafikausführungseinheit 608 gemeinsam mehrere Anweisungen ausgeben, welche jeweils unterschiedliche Anweisungen sein können. Der Thread-Arbitrierer 622 des Grafikausführungseinheitsthreads 608 kann die Anweisungen an eine der Sendeeinheit 630, der Verzweigungseinheit 642 oder SIMD FPU(s) 634 zur Ausführung abfertigen. Jeder Ausführungsthread kann auf 128 Universalregister innerhalb der GRF 624 zugreifen, wobei jedes Register 32 Bytes speichern kann, auf die als ein SIMD 8-Elementvektor von 32-Bit-Datenelementen zugegriffen werden kann. In einer Ausführungsform hat jeder Ausführungseinheitsthread Zugriff auf 4 Kbytes innerhalb der GRF 624, wenngleich die Ausführungsformen nicht derart beschränkt sind, und können mehr oder weniger Registerressourcen in anderen Ausführungsformen bereitgestellt werden. In einer Ausführungsform können bis zu sieben Threads gleichzeitig ausgeführt werden, wenngleich die Anzahl an Threads pro Ausführungseinheit auch gemäß den Ausführungsformen 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 Adressiermodi können erlauben, dass Register zusammen adressiert werden, um effektiv breitere Register zu bilden oder schrittweise rechteckige Blockdatenstrukturen darzustellen.
In einer Ausführungsform werden Speicheroperationen, Abtasteroperationen und andere Systemkommunikationen mit längerer Latenz über „Sende“-Anweisungen abgefertigt, die durch die Nachrichtenübergabesendeeinheit 630 ausgeführt werden. In einer Ausführungsform werden Zweiganweisungen an eine dedizierte Zweigeinheit 632 abgefertigt, um eine SIMD-Divergenz und eine eventuelle 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 bzw. unterstützen die FPU(s) 634 auch Ganzzahlberechnung. In einer Ausführungsform kann bzw. können das bzw. die FPU(s) 634 mit SIMD eine Anzahl an bis zu M 32-Bit-Gleitkomma(oder -Ganzzahl-)-operationen ausführen oder mit SIMD bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkommaoperationen ausführen. In einer Ausführungsform stellt mindestens eine der FPU(s) eine erweiterte Mathematikfähigkeit bereit, um transzendentale Mathematikfunktionen mit hohem Durchsatz und Doppelpräzisions-64-Bit-Gleitkomma zu unterstützen. In einigen Ausführungsformen sind auch ein Satz 8-Bit-Ganzzahl-SIMD ALUs 635 vorhanden und können spezifisch optimiert sein, um Operationen durchzuführen, die mit Maschinenlemberechnungen verknüpft sind.
In einer Ausführungsform können Anordnungen von mehreren Instanzen der Grafikausführungseinheit 608 in einer Grafikteilkerngruppierung (z. B. ein Teil-Slice) instantiiert werden. Zur Skalierbarkeit können Produktarchitekten die genaue Anzahl an Ausführungseinheiten pro Teilkerngruppierung auswählen. In einer Ausführungsform kann die Ausführungseinheit 608 Anweisungen über mehrere Ausführungskanäle ausführen. In einer weiteren Ausführungsform wird jeder Thread, der auf der Grafikausführungseinheit 608 ausgeführt wird, auf einem anderen Kanal ausgeführt.
7 ist ein Blockdiagramm, das Grafikprozessoranweisungsformate 700 gemäß einigen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die mit durchgezogenen Linien dargestellten Kästchen veranschaulichen die Komponenten, die im Allgemeinen in einer Ausführungseinheitsanweisung enthalten sind, während die gestrichelten Linien Komponenten aufweisen, die optional sind oder die nur in einem Teilsatz der Anweisungen enthalten sind. In einigen Ausführungsformen sind das beschriebene und veranschaulichte Anweisungsformat 700 in der Hinsicht Makroanweisungen, dass sie der Ausführungseinheit zugeführte Anweisungen sind, was im Gegensatz zu Mikrooperationen steht, die sich aus einer Anweisungsdecodierung ergeben, sobald die Anweisung verarbeitet wurde.
In einigen Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten Anweisungen in einem 128-Bit-Anweisungsformat 710 nativ. Ein kompaktiertes 64-Bit-Anweisungsformat 730 ist für einige Anweisungen basierend auf der ausgewählten Anweisung, auf Anweisungssoptionen und der Anzahl der Operanden verfügbar. Das native 128-Bit-Anweisungsformat 710 stellt einen Zugang zu allen Anweisungsoptionen bereit, während einige Optionen und Operationen in dem 64-Bit-Format 730 beschränkt sind. Die nativen Anweisungen, die in dem 64-Bit-Format 730 verfügbar sind, variieren gemäß der Ausführungsform. In einigen Ausführungsformen wird die Anweisung teilweise unter Verwendung eines Satzes Indexwerte in einem Indexfeld 713 kompaktiert. Die Ausführungseinheitshardware bezieht sich basierend auf den Indexwerten auf einen Satz Kompaktierungstabellen und verwendet die Kompaktierungstabellenausgaben zum Rekonstruieren einer nativen Anweisung in dem 128-Bit-Anweisungsformat 710.
Für jedes Format definiert ein Anweisungsopcode 712 die Operation, welche die Ausführungseinheit durchführen wird. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden aus. Beispielsweise führt die Ausführungseinheit als Reaktion auf eine Addieranweisung eine gleichzeitige Addieroperation über jeden Farbkanal, der ein Texturelement oder Bildelement repräsentiert, durch. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden aus. In einigen Ausführungsformen ermöglicht ein Anweisungssteuerfeld 714 die Steuerung konkreter Ausführungsoptionen, wie etwa der Kanalauswahl (z. B. Prädikation) und der Datenkanalreihenfolge (z. B. Swizzle). Für Anweisungen in dem 128-Bit-Anweisungsformat 710 begrenzt ein Ausführungsgrößenfeld 716 die Anzahl der Datenkanäle, die parallel ausgeführt werden. In einigen Ausführungsformen steht das Ausführungsgrößenfeld 716 für eine Verwendung in dem kompakten 64-Bit-Anweisungsformat 730 nicht zur Verfügung.
Einige Ausführungseinheitsanweisungen haben bis zu drei Operanden, einschließlich zweier Quelloperanden src0 720, src1 722 und ein Ziel 718. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Doppelzielanweisungen, worin eines der Ziele impliziert ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden (z. B. SRC2 724) aufweisen, wobei der Anweisungsopcode 712 die Anzahl der Quelloperanden bestimmt. Der letzte Quelloperand einer Anweisung kann ein mit der Anweisung übergebener unmittelbarer (z. B. hart codierter) Wert sein.
In einigen Ausführungsformen weist das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726 auf, das zum Beispiel spezifiziert, ob ein direkter Registeradressiermodus oder ein indirekter Registeradressiermodus verwendet wird. Wenn ein direkter Registeradressiermodus 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 Zugriffs-/Adressmodusfeld 726 auf, welches einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung spezifiziert. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Einige Ausführungsformen unterstützen Zugriffsmodi einschließlich eines 16-Byte-ausgerichteten-Zugriffsmodus und eines ausgerichteten 1-Byte-Zugriffsmodus, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Zum Beispiel kann in einem ersten Modus die Anweisung eine Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden und in einem zweiten Modus die Anweisung eine 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressmodusteil des Zugriffs-/Adressmodusfelds 726, ob die Anweisung direkte oder indirekte Adressierung verwenden wird. Wenn der direkte Registeradressiermodus verwendet wird, stellen Bits in der Anweisung direkt die Registeradresse von einem oder mehreren Operanden bereit. Wenn der indirekte Registeradressiermodus verwendet wird, kann die Registeradresse von einem oder mehreren Operanden basierend auf einem Adressregisterwert und einem Adressimmediatefeld in der Anweisung berechnet werden.
In einigen Ausführungsformen werden Anweisungen auf der Grundlage von Opcode-712-Bit-Feldern gruppiert, um die Opcodedecodierung 740 zu vereinfachen. Für einen 8-Bit-Opcode ermöglichen es die Bits 4, 5 und 6, dass die Ausführungseinheit den Typ des Opcodes bestimmt. Die gezeigte genaue Opcodegruppierung ist nur ein Beispiel. In einigen Ausführungsformen weist eine Verschiebungs- und Logikoperationscodegruppe 742 Datenverschiebungs- und Logikanweisungen auf (z. B. mov(move), compare(cmp)). In einigen Ausführungsformen teilt sich die Verschiebungs- und Logikgruppe 742 die fünf höchstwertigen Bits (MSB, Most Significant Bits), wobei Bewegungsanweisungen (mov) in Form von 0000xxxxb vorliegen und Logikanweisungen in Form von 0001xxxxb vorliegen. Eine Ablaufsteuerungsanweisungsgruppe 744 (z. B. call, jump (jmp)) weist Anweisungen in Form von 0010xxxxb auf (z. B. 0x20). Eine vermischte Anweisungsgruppe 746 weist eine Anweisungsmischung unter Einschluss von Synchronisationsanweisungen (z. B. Warten, Senden) in der Form von 0011xxxxb (z. B. 0x30) auf. Eine parallele Mathematikanweisungsgruppe 748 weist komponentenweise arithmetische Anweisungen (z. B. add, multiply (mul)) in Form von 0100xxxxb (z. B. 0x40) auf. Die parallele mathematische Gruppe 748 führt die arithmetischen Operationen über Datenkanäle parallel aus. Die mathematische Vektorgruppe 750 weist arithmetische Anweisungen (z. B. dp4) in Form von 0101xxxxb (z. B. 0x50) auf. Die mathematische Vektorgruppe führt arithmetische Berechnungen in der Art von Skalarproduktberechnungen an Vektoroperanden durch.
Grafikpipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Diejenigen Elemente aus 8, die dieselben Bezugszeichen (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine beliebige ähnliche Art wie die andernorts hierin beschriebene wirken 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 Anzeigeengine 840, eine Thread-Ausführungslogik 850 und eine Renderausgabepipeline 870 auf. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb von einem Mehrfachkernverarbeitungssystem, das einen oder mehrere Universalverarbeitungskerne aufweist. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle, die an den Grafikprozessor 800 über eine Ringverschaltung 802 ausgegeben werden, gesteuert. In einigen Ausführungsformen koppelt die Ringverschaltung 802 den Grafikprozessor 800 mit anderen Verarbeitungskomponenten, wie etwa anderen Grafikprozessoren oder Universalprozessoren. Befehle von der Ringverschaltung 802 werden von einem Befehls-Streamer 803 interpretiert, welcher Befehle einzelnen Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 zuführt.
In einigen Ausführungsformen führt der Befehls-Streamer 803 den Betrieb eines Vertexabrufers 805, der Vertexdaten aus dem Speicher liest und Vertexverarbeitungsbefehle ausführt, die von dem Befehls-Streamer 803 bereitgestellt werden. In einigen Ausführungsformen stellt der Vertexabrufer 805 Vertexdaten einem Vertex-Shader 807 bereit, welcher Koordinatenraumtransformations- und Beleuchtungsoperationen für jeden Vertex durchführt. In einigen Ausführungsformen führen der Vertexabrufer 805 und der Vertex-Shader 807 Vertexverarbeitungsbefehle durch Abfertigen von Ausführungsthreads für die Ausführungseinheiten 852A-852B über einen Thread-Abfertiger 831 aus.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B eine Anordnung von Vektorprozessoren, die einen Anweisungssatz zum Durchführen von Grafik- und Medienoperationen aufweisen. In einigen Ausführungsformen weisen die Ausführungseinheiten 852A-852B einen angefügten L1-Cache 851 auf, der für jede Anordnung spezifisch ist oder unter den Anordnungen geteilt wird. Der Cache kann als ein Datencache, ein Anweisungscache oder ein einzelner Cache, der partitioniert ist, um Daten und Anweisungen in verschiedenen Partitionen zu enthalten, konfiguriert sein.
In einigen Ausführungsformen weist die Geometrie-Pipeline 820 Tesselationskomponenten auf, um eine hardwarebeschleunigte Tesselation von 3D-Objekten durchzuführen. In einigen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tesselationsoperationen. Ein programmierbarer Domain-Shader 817 stellt eine Backend-Auswertung der Tesselationsausgabe bereit. Ein Tesselator 813 arbeitet in der Richtung des Hull-Shaders 811 und enthält eine spezielle Logik, um einen Satz detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell zu erzeugen, das als Eingabe in die Geometrie-Pipeline 820 bereitgestellt wird. In einigen Ausführungsformen, wenn keine Tesselation verwendet wird, können die Tesselationskomponenten (z. B. der Hull-Shader 811, der Tesselator 813 und der Domain-Shader 817) umgangen werden.
In einigen Ausführungsformen können vollständige geometrische Objekte von einem Geometrie-Shader 819 über einen oder mehrere Threads, die für die Ausführungseinheiten 852A-852B abgefertigt werden, verarbeitet werden, oder direkt zu dem Clipper 829 übergehen. In einigen Ausführungsformen verarbeitet der Geometrie-Shader gesamte geometrische Objekte anstelle von Vertices oder Patches von Vertices wie in früheren Stufen der Grafikpipeline. Wenn die Tesselation deaktiviert ist, erhält der Geometrie-Shader 819 Eingabe von dem Vertex-Shader 807. In einigen Ausführungsformen ist der Geometrie-Shader 819 durch ein Geometrie-Shader-Programm programmierbar, um Geometrietesselation durchzuführen, wenn die Tesselationseinheiten deaktiviert sind.
Vor der Rasterisierung verarbeitet ein Clipper 829 Vertexdaten. Der Clipper 829 kann ein Festfunktionsclipper oder ein programmierbarer Clipper, der Clipping- und Geometrie-Shader-Funktionen aufweist, sein. In einigen Ausführungsformen fertigt eine Rasterisierer- und Tiefentestkomponente 873 in der Renderausgabepipeline 870 Pixel-Shader ab, um die geometrischen Objekte in ihre Darstellungen pro Pixel umzuwandeln. In einigen Ausführungsformen ist die Pixel-Shader-Logik in der Thread-Ausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung die Rasterisierer- und Tiefentestkomponente 873 umgehen und auf ungerasterte Vertexdaten über eine Stream-out-Einheit 823 zugreifen.
Der Grafikprozessor 800 weist einen Verschaltungsbus, ein Verschaltungsfabric oder einen anderen Verschaltungsmechanismus auf, der eine Daten- und Nachrichtübergabe zwischen den wichtigsten Komponenten des Prozessors erlaubt. In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B und die zugehörigen Logikeinheiten (z. B. der L1-Cache 851, der Abtaster 854, der Texturcache 858 usw.) über einen Datenport 856 verbunden, um einen Speicherzugriff durchzuführen und mit Renderausgabepipelinekomponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen weisen der Abtaster 854, die Caches 851, 858 und die Ausführungseinheiten 852A-852B jeweils separate Speicherzugriffspfade auf. In einer Ausführungsform kann der Texturcache 858 auch als ein Abtastercache konfiguriert sein.
In einigen Ausführungsformen enthält die Renderausgabepipeline 870 eine Rasterisier- und Tiefentestkomponente 873, die vertexbasierte Objekte in eine zugehörige pixelbasierte Darstellung umwandelt. In einigen Ausführungsformen weist die Rasterisiererlogik eine Windower-/Masker-Einheit auf, um eine Dreieck- und Linienrasterisierung mit fixer Funktion durchzuführen. Ein zugehöriger Rendercache 878 und Tiefencache 879 sind auch in einigen Ausführungsformen verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen bei den Daten durch, wenngleich in einigen Fällen Pixeloperationen, die mit 2D-Operationen (z. B. Bit-Block-Bildtransfers mit Blending verknüpft sind, von der 2D-Engine 841 durchgeführt werden oder zum Anzeigezeitpunkt durch den Anzeigecontroller 843 unter Verwendung von Überlagerungsanzeigeebenen ersetzt werden. In einigen Ausführungsformen ist ein geteilter L3-Cache 875 für alle Grafikkomponenten verfügbar, wobei das Teilen von Daten ohne die Verwendung des Hauptsystemspeichers erlaubt wird.
In einigen Ausführungsformen weist die Grafikprozessormedienpipeline 830 eine Medienengine 837 und ein Videofrontend 834 auf. In einigen Ausführungsformen erhält das Videofrontend 834 Pipelinebefehle von dem Befehls-Streamer 803. In einigen Ausführungsformen weist die Medien-Pipeline 830 einen separaten Befehls-Streamer auf. In einigen Ausführungsformen verarbeitet das Videofrontend 834 Medienbefehle vor dem Senden des Befehls zu der Medienengine 837. In einigen Ausführungsformen weist die Medienengine 837 eine Thread-Hervorbringungsfunktionalität auf, um Threads zum Abfertigen für die Thread-Ausführungslogik 850 über den Thread-Abfertiger 831 hervorzubringen.
In einigen Ausführungsformen weist der Grafikprozessor 800 eine Anzeigeengine 840 auf. In einigen Ausführungsformen ist die Anzeigeengine 840 extern bezüglich des Prozessors 800 und ist mit dem Grafikprozessor über die Ringverschaltung 802 oder einen anderen Verschaltungsbus oder ein anderes Verschaltungsfabric gekoppelt. In einigen Ausführungsformen weist die Anzeigeengine 840 eine 2D-Engine 841 und einen Anzeigecontroller 843 auf. In einigen Ausführungsformen enthält die Anzeigeengine 840 eine spezielle Logik, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen ist der Anzeigecontroller 843 mit einer Anzeigevorrichtung (nicht gezeigt) gekoppelt, welche eine in einem System integrierte Anzeigevorrichtung, wie in einem Laptop-Computer, oder eine externe Anzeigevorrichtung, die über einen Anzeigevorrichtungsstecker verbunden ist, sein kann.
In einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 derart konfigurierbar, dass sie Operationen basierend auf mehreren Grafik- und Medienprogrammierungsschnittstellen durchführen, und sind nicht für irgendeine Anwendungsprogrammierungsschnittstelle (API, Application Programming Interface) spezifisch. In einigen Ausführungsformen übersetzt eine Treibersoftware für den Grafikprozessor API-Aufrufe, die spezifisch für eine konkrete Grafik- oder Medienbibliothek sind, in Befehle, die von dem Grafikprozessor verarbeitet werden können. In einigen Ausführungsformen wird Unterstützung für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan-Grafik und Rechen-API, allesamt von der Khronos Group, bereitgestellt. In einigen Ausführungsformen kann auch Unterstützung für die Direct3D Library von der Microsoft Corporation bereitgestellt werden. In einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Es kann auch die Open Source Computer Vision Library (OpenCV) unterstützt werden. Eine künftige API mit einer kompatiblen 3D-Pipeline würde auch unterstützt werden, wenn ein Abgleichen von der Pipeline der künftigen API mit der Pipeline des Grafikprozessors vorgenommen werden kann.
Grafikpipelineprogrammierung
9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat 900 gemäß einigen Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 910 gemäß einer Ausführungsform veranschaulicht. Die in durchgezogenen Linien dargestellten Kästchen in 9A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten aufweisen, die optional sind oder die nur in einem Teilsatz der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessorbefehlsformat 900 aus 9A weist Datenfelder auf, um einen Client 902, einen Befehlsoperationscode (Opcode) 904 und die Daten 906 für den Befehl zu identifizieren. Ein Unteropcode 905 und eine Befehlsgröße 908 sind auch in einigen Befehlen enthalten.
In einigen Ausführungsformen spezifiziert der Client 902 die Client-Einheit der Grafikvorrichtung, die die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessorbefehlsparser das Client-Feld jedes Befehls, um die weitere Verarbeitung des Befehls zu bedingen und die Befehlsdaten zu der geeigneten Client-Einheit zu leiten. In einigen Ausführungsformen schließen die Grafikprozessorclienteinheiten eine Speicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit ein. Jede Client-Einheit weist eine entsprechende Verarbeitungspipeline auf, die die Befehle verarbeitet. Nachdem der Befehl von der Client-Einheit erhalten worden ist, liest die Client-Einheit den Opcode 904 und, falls vorhanden, den Unteropcode 905, um die Operation zu bestimmen, die durchzuführen ist. Die Client-Einheit führt den Befehl unter Verwendung von Informationen in dem Datenfeld 906 durch. Für einige Befehle wird erwartet, dass eine explizite Befehlsgröße 908 die Größe des Befehls spezifiziert. In einigen Ausführungsformen bestimmt der Befehlsparser automatisch die Größe von mindestens einigen der Befehle basierend auf dem Befehlsopcode. In einigen Ausführungsformen werden die Befehle über Vielfache eines Doppelworts ausgerichtet.
Das Flussdiagramm in 9B veranschaulicht eine beispielhafte Grafikprozessorbefehlssequenz 910. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors aufweist, eine Version der gezeigten Befehlssequenz, um einen Satz Grafikoperationen einzurichten, auszuführen und zu beenden. Eine Abtastbefehlssequenz ist nur beispielhaft gezeigt und beschrieben, da die Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlssequenz beschränkt sind. Ferner können die Befehle als Befehlsstapel in einer Befehlssequenz derart ausgegeben werden, dass der Grafikprozessor die Befehlssequenz mindestens teilweise gleichzeitig verarbeiten wird.
In einigen Ausführungsformen kann die Grafikprozessorbefehlssequenz 910 mit einem Pipelineleerungsbefehl 912 beginnen, um zu bewirken, dass eine beliebige aktive Grafikpipeline die aktuell ausstehenden Befehle für die Pipeline abschließt. In einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Die Pipelineleerung wird durchgeführt, um zu bewirken, dass die aktive Grafikpipeline beliebige ausstehenden Befehle abschließt. Als Reaktion auf eine Pipelineleerung wird der Befehlsparser für den Grafikprozessor die Befehlsverarbeitung unterbrechen, bis die aktiven Zeichnungsengines ausstehende Operationen abschließen und die relevanten Lese-Caches ungültig gemacht sind. Optional können beliebige Daten in dem Rendercache, die als „dirty“ markiert sind, in den Speicher geschrieben werden. In einigen Ausführungsformen kann der Pipelineleerungsbefehl 912 zur Pipelinesynchronisierung oder vor dem Versetzen des Grafikprozessors in einen Zustand mit verringerter Leistung verwendet werden.
In einigen Ausführungsformen wird ein Pipelineauswahlbefehl 913 verwendet, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen Pipelines wechselt. In einigen Ausführungsformen wird ein Pipelineauswahlbefehl 913 nur einmal innerhalb eines Ausführungskontexts benötigt, bevor Pipelinebefehle ausgegeben werden, es sei denn, der Kontext gibt Befehle für beide Pipelines aus. In einigen Ausführungsformen wird ein Pipelineleerungsbefehl 912 unmittelbar vor einem Pipelinewechseln über den Pipelineauswahlbefehl 913 benötigt.
In einigen Ausführungsformen konfiguriert ein Pipelinesteuerungsbefehl 914 eine Grafikpipeline zur Operation und wird verwendet, um die 3D-Pipeline 922 und die Medien-Pipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Pipelinesteuerungsbefehl 914 den Pipelinezustand für die aktive Pipeline. In einer Ausführungsform wird der Pipelinesteuerungsbefehl 914 zur Pipelinesynchronisierung und zum Löschen von Daten aus einem oder mehreren Cache-Speichern innerhalb der aktiven Pipeline vor dem Verarbeiten eines Befehlsstapels verwendet.
In einigen Ausführungsformen werden Befehle für den Rücklaufpufferzustand 916 verwendet, um einen Satz Rücklaufpuffer für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipelineoperationen erfordern die Zuordnung, Auswahl oder Konfiguration eines oder mehrerer Rücklaufpuffer, in welche die Operationen Zwischendaten während der Verarbeitung schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rücklaufpuffer, um Ausgabedaten zu speichern und eine Kreuz-Thread-Kommunikation durchzuführen. In einigen Ausführungsformen umfasst der Rücklaufpufferzustand 916 das Auswählen der Größe und Anzahl an Rücklaufpuffern zur Verwendung für einen Satz Pipelineoperationen.
Die verbleibenden Befehle in der Befehlssequenz unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipelinebestimmung 920 wird die Befehlssequenz an die 3D-Pipeline 922 beginnend mit dem 3D-Pipelinezustand 930 oder auf die Medien-Pipeline 924 beginnend bei dem Medien-Pipeline-Zustand 940 angepasst.
Die Befehle zum Konfigurieren des 3D-Pipelinezustands 930 umfassen 3D-Zustandseinstellungsbefehle für den Vertexpufferzustand, Vertexelementzustand, konstanten Farbzustand, Tiefenpufferzustand und sonstige Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitiv-Befehle verarbeitet werden. Die Werte dieser Befehle werden mindestens teilweise basierend auf der konkreten 3D API, die verwendet wird, bestimmt. In einigen Ausführungsformen sind Befehle des 3D-Pipelinezustands 930 auch in der Lage, gezielt konkrete Pipelineelemente zu deaktivieren oder umgehen, wenn diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird der Befehl des 3D-Primitivs 932 verwendet, um 3D-Primitive zuzuführen, die von der 3D-Pipeline zu verarbeiten sind. Befehle und zugehörige Parameter, die über den Befehls des 3D-Primitivs 932 an den Grafikprozessor übergeben werden, werden an die Vertexabruffunktion in der Grafikpipeline weitergeleitet. Die Vertexabruffunktion verwendet die Befehlsdaten des 3D-Primitivs 932, um Vertexdatenstrukturen zu erzeugen. Die Vertexdatenstrukturen werden in einem oder mehreren Rücklaufpuffern gespeichert. In einigen Ausführungsformen wird der Befehl des 3D-Primitivs 932 verwendet, um Vertexoperationen bei 3D-Primitiven über Vertex-Shader durchzuführen. Um Vertex-Shader zu verarbeiten, fertigt die 3D-Pipeline 922 Shader-Ausführungsthreads für Grafikprozessorausführungseinheiten ab.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Ausführungsbefehl oder -ereignis 934 ausgelöst. In einigen Ausführungsformen löst ein Registerschreibvorgang die Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über einen „Go“- oder „Kick“-Befehl in der Befehlssequenz ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Piplinesynchronisierungsbefehls zum Leeren der Befehlssequenz durch die Grafikpipeline ausgelöst. Die 3D-Pipeline wird eine Geometrieverarbeitung für die 3D-Primitive durchführen. Nachdem die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und färbt die Pixelengine die resultierenden Pixel. Zusätzliche Befehle zum Steuern von Pixelshading- und Pixelbackendoperationen können auch für diese Operationen aufgenommen werden.
In einigen Ausführungsformen folgt die Grafikprozessorbefehlssequenz 910 dem Pfad der Medien-Pipeline 924, wenn Medienoperationen durchgeführt werden. Allgemein hängt die spezifische Verwendung und Art der Programmierung für die Medien-Pipeline 924 von den durchzuführenden Medien- oder Rechenoperationen ab. Spezifische Mediendecodieroperationen können in die Medien-Pipeline während dem Mediendecodieren abgeladen werden. In einigen Ausführungsformen kann die Medien-Pipeline auch umgangen werden und kann ein Mediendecodieren ganz oder zum Teil unter Verwendung von Ressourcen, die von einem oder mehreren Universalverarbeitungskernen bereitgestellt werden, durchgeführt werden. In einer Ausführungsform weist die Medien-Pipeline auch Elemente für Universalgrafikprozessoreinheit(GPGPU, General-Purpose Graphics Processor Unit)-operationen auf, wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Rechenshaderprogrammen, die nicht explizit mit dem Rendern von Grafikprimitiven verknüpft sind, durchzuführen.
In einigen Ausführungsformen ist die Medien-Pipeline 924 auf eine ähnliche Art wie die 3D-Pipeline 922 konfiguriert. Ein Satz Befehle zum Konfigurieren des Medien-Pipeline-Zustands 940 wird in eine Befehlswarteschlange vor den Medienobjektbefehlen 942 abgefertigt oder platziert. In einigen Ausführungsformen weisen Befehle für den Medien-Pipeline-Zustand 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medienobjekte verwendet werden, auf. Dies umfasst Daten zum Konfigurieren der Videodecodier- und Videocodierlogik innerhalb der Medien-Pipeline, wie etwa Codier- oder Decodierformat. In einigen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Zustand 940 auch die Verwendung von einem oder mehreren Zeigern zu „indirekten“ Zustandselementen, die einen Stapel von Zustandseinstellungen enthalten.
In einigen Ausführungsformen führen die Medienobjektbefehle 942 Zeiger Medienobjekten zur Verarbeitung durch die Medien-Pipeline zu. Die Medienobjekte umfassen Speicherpuffer, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medien-Pipeline-Zustände gültig sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Nachdem der Pipelinezustand konfiguriert ist und die Medienobjektbefehle 942 in eine Warteschlange gebracht sind, wird die Medien-Pipeline 942 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (z. B. ein Registerschreibvorgang) ausgelöst. Ausgabe von der Medien-Pipeline 924 kann dann durch Operationen, die von der 3D-Pipeline 922 oder der Medien-Pipeline 924 bereitgestellt werden, nachbearbeitet werden. In einigen Ausführungsformen werden GPGPU-Operationen auf eine ähnliche Art 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 in dem Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 einen oder mehrere Shaderprogramme einschließlich der Shader-Anweisungen 1012. Die Shadersprach-Anweisungen können in einer höheren Shadersprache, wie etwa der High Level Shader Language (HLSL) oder der OpenGL Shader Language (GLSL), vorliegen. Die Anwendung weist auch ausführbare Anweisungen 1014 in einer Maschinensprache, die zur Ausführung durch den Universalprozessorkern 1034 geeignet ist, auf. Die Anwendung weist auch Grafikobjekte 1016 auf, die durch Vertexdaten definiert sind.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows®-Betriebssystem von der Microsoft Corporation, ein proprietäres UNIX-artiges Betriebssystem oder ein frei verfügbares UNIX-artiges Betriebssystem, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022, wie etwa die Direct3D API, die OpenGL API oder die Vulkan API, unterstützen. Wenn die Direct3D API verwendet wird, verwendet das Betriebssystem 1020 einen Frontend-Shader-Kompilierer 1024, um beliebige Shader-Anweisungen 1012 in HLSL in eine niedrigere Shader-Sprache zu kompilieren. Die Kompilierung kann eine Just-in-Time(JIT)-Kompilierung sein, oder die Anwendung kann eine Shader-Vorkompilierung durchführen. In einigen Ausführungsformen werden höhere Shader zu niederen Shadern während der Kompilierung der 3D-Grafikanwendung 1010 kompiliert. In einigen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform, wie etwa einer Version der Standard Portable Intermediate Representation (SPIR), die von der Vulkan API verwendet wird, bereitgestellt.
In einigen Ausführungsformen enthält der Benutzermodusgrafiktreiber 1026 einen Backend-Shader-Kompilierer 1027, um die Shader-Anweisungen 1012 in eine hardwarespezifische Darstellung umzuwandeln. Wenn die OpenGL API verwendet wird, werden die Shader-Anweisungen 1012 in der GLSL High-Level-Language an einen Benutzermodusgrafiktreiber 1026 zur Kompilierung übergeben. In einigen Ausführungsformen verwendet der Benutzermodusgrafiktreiber 1026 Betriebssystem-Kernelmodusfunktionen 1028 zum Kommunizieren mit einem Kernelmodusgrafiktreiber 1029. In einigen Ausführungsformen kommuniziert der Kernelmodusgrafiktreiber 1029 mit dem Grafikprozessor 1032 zum Abfertigen 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 etwa einem Prozessor, darstellt und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Anweisungen aufweisen, welche diverse Logik innerhalb des Prozessors darstellen. Wenn sie von einer Maschine gelesen werden, können die Anweisungen bewirken, dass die Maschine die Logik herstellt, um die hierin beschriebenen Techniken durchzuführen. Solche Darstellungen, die als „IP-Kerne“ bekannt sind, sind wiederverwendbare Einheiten von Logik für eine integrierte Schaltung, die auf einem dingbaren maschinenlesbaren Medium als ein Hardwaremodell, das die Struktur der integrierten Schaltung beschreibt, gespeichert werden können. Das Hardwaremodell kann verschiedenen Kunden oder Herstellungseinrichtungen zugeführt werden, welche das Hardwaremodell auf Herstellungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann derart hergestellt werden, dass die Schaltung Operationen durchführt, die in Verbindung mit einer der hierin beschriebenen Ausführungsformen beschrieben sind.
11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100 gemäß einer Ausführungsform veranschaulicht, das verwendet werden kann, um eine integrierte Schaltung herzustellen, um Operationen durchzuführen. Das IP-Kern-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs zu erzeugen, die in ein größeres Design aufgenommen oder verwendet werden können, um eine gesamte integrierte Schaltung (z. B. eine integrierte SOC-Schaltung) zu konstruieren. Eine Designeinrichtung 1130 kann eine Softwaresimulation 1110 eines IP-Kern-Designs in einer höheren Programmiersprache (z. B. C/C++) erzeugen. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu gestalten, testen und verifizieren. Das Simulationsmodell 1112 kann funktionelle Simulationen, Verhaltenssimulationen und/oder Zeitsteuerungssimulationen aufweisen. Ein Registertransferlevel(RTL)-design 1115 kann dann anhand des Simulationsmodells 1112 erstellt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Strom von digitalen Signalen zwischen Hardwareregistern modelliert, einschließlich der zugehörigen Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs niederer Ebene an der Logikebene oder Transistorebene erstellt, gestaltet oder synthetisiert werden. Somit können die konkreten Details des anfänglichen Designs und der anfänglichen Simulation variieren.
Das RTL-Design 1115 oder ein Äquivalent kann ferner durch die Designeinrichtung zu einem Hardwaremodell 1120 synthetisiert werden, welches in einer Hardwarebeschreibungssprache (HDL, Hardware Description Language) oder einer anderen Darstellung von physikalischen Designdaten vorliegen kann. Die HDL kann ferner simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann zur Lieferung an eine Drittherstellungseinrichtung 1165 unter Verwendung von nichtflüchtigem Speicher 1140 (z. B. Festplatte, Flash-Speicher oder ein beliebiges nichtflüchtiges Speichermedium) gespeichert werden. Alternativ kann das IP-Kern-Design über eine drahtgebundene Verbindung 1150 oder drahtlose Verbindung 1160 übertragen werden (z. B. über das Internet). Die Herstellungseinrichtung 1165 kann dann eine integrierte Schaltung herstellen, die mindestens zum Teil auf dem IP-Kern-Design basiert. Die hergestellte integrierte Schaltung kann konfiguriert sein, um Operationen gemäß mindestens einer hierin beschriebenen Ausführungsform durchzuführen.
11B veranschaulicht eine Querschnittsseitenansicht einer integrierten Schaltungspackungsanordnung 1170 gemäß einigen hierin beschriebenen Ausführungsformen. Die integrierte Schaltungspackungsanordnung 1170 veranschaulicht eine Implementierung einer oder mehrerer Prozessor- oder Beschleunigervorrichtungen, wie sie hierin beschrieben sind. Die Packungsanordnung 1170 weist mehrere Einheiten von Hardwarelogik 1172, 1174 auf, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann zumindest teilweise in einer konfigurierbaren Logikhardware oder einer Logikhardware mit fixer Funktionalität implementiert sein und einen oder mehrere Teile von einem beliebigen des Prozessorkerns bzw. der Prozessorkerne, des Grafikprozessors bzw. der Grafikprozessoren oder von sonstigen Beschleunigervorrichtungen, die hierin beschrieben sind, aufweisen. Jede Einheit der Logik 1172, 1174 kann innerhalb eines Halbleiterchips implementiert werden und über eine Verschaltungsstruktur 1173 mit dem Substrat 1180 gekoppelt sein. Die Verschaltungsstruktur 1173 kann konfiguriert sein, um elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten, und kann Verschaltungen, wie etwa Kontakthöcker oder Säulen, ohne jedoch auf diese beschränkt zu sein, aufweisen. In einigen Ausführungsformen kann die Verschaltungsstruktur 1173 konfiguriert sein, um elektrische Signale, wie zum Beispiel Eingangs-/Ausgangs(E/A)-signale und/oder Leistungs- oder Erdungssignale in Verbindung mit der Operation der Logik 1172, 1174, zu leiten. In einigen Ausführungsformen ist das Substrat 1180 ein epoxibasiertes Laminatsubstrat. Das Packungssubstrat 1180 kann andere geeignete Arten von Substraten in anderen Ausführungsformen umfassen. Die Packungsanordnung 1170 kann über eine Packungsverschaltung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Packungsverschaltung 1183 kann mit einer Fläche des Substrats 1180 gekoppelt werden, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie ein Motherboard, ein anderer Chipsatz oder ein Mehrfachchipmodul, zu leiten.
In einigen Ausführungsformen sind die Einheiten der Logik 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die konfiguriert ist, um elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Brücke 1182 kann eine dichte Verschaltungsstruktur sein, die eine Route für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat aufweisen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Es können elektrische Leitmerkmale auf dem Brückensubstrat zum Bereitstellen einer Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 gebildet sein.
Wenngleich zwei Einheiten der Logik 1172, 1174 und eine Brücke 1182 veranschaulicht sind, können die hierin beschriebenen Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Chips umfassen. Der eine oder die mehreren Chips können durch null oder mehr Brücken verbunden sein, da die Brücke 1182 ausgeschlossen werden kann, wenn die Logik auf einem einzelnen Chip aufgenommen ist. Alternativ können mehrere Chips oder Einheiten der Logik durch eine oder mehrere Brücken verbunden sein. Zusätzlich können mehrere Logikeinheiten, Chips und Brücken in anderen möglichen Konfigurationen einschließlich dreidimensionaler Konfigurationen miteinander verbunden sein.
Beispielhafte integrierte System-on-a-Chip-Schaltung
12-14 veranschaulichen beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden können, gemäß verschiedenen hierin beschriebenen Ausführungsformen. Zusätzlich zu dem Veranschaulichten können eine andere Logik und andere Schaltungen enthalten sein, einschließlich zusätzlicher Grafikprozessoren/-kerne, Peripherieschnittstellensteuerungen oder Universalprozessorkerne.
12 ist ein Blockdiagramm, das eine beispielhafte integrierte System-on-a-Chip-Schaltung 1200, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform veranschaulicht. Die beispielhafte integrierte Schaltung 1200 weist einen oder mehrere Anwendungsprozessoren 1205 (z. B. CPUs), mindestens einen Grafikprozessor 1210, auf, und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 aufweisen, von welchen jeder ein modularer IP-Kern von derselben oder mehreren verschiedenen Designeinrichtungen sein kann. Die integrierte Schaltung 1200 weist eine periphere Logik oder Buslogik einschließlich eines USB-Controllers 1225, UART-Controllers 1230, eines SPI/SDIO-Controllers 1235 und eines I²S/I²C-Controllers 1240 auf. Zusätzlich kann die integrierte Schaltung eine Anzeigevorrichtung 1245 aufweisen, die mit einem bzw. einer oder mehreren eines hochauflösenden Multimediaschnittstellen(HDMI, High-Definition Multimedia Interface)-Controllers 1250 und einer mobilen Industrieprozessorschnittstellen(MIPI, Mobile Industry Processor Interface)-anzeigeschnittstelle 1255 gekoppelt ist. Die Speicherung kann durch ein Flash-Speicher-Untersystem 1260, das Flash-Speicher und einen Flash-Speichercontroller aufweist, bereitgestellt werden. Die Speicherschnittstelle kann über einen Speichercontroller 1265 zum Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt werden. Einige integrierte Schaltungen weisen zusätzlich eine eingebettete Sicherheitsengine 1270 auf.
13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung innerhalb eines SoC gemäß hierin beschriebenen Ausführungsformen veranschaulichen. 13A veranschaulicht einen beispielhaften Grafikprozessor 1310 einer integrierten System-on-a-Chip-Schaltung, 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 System-on-a-Chip-Schaltung, 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 einer geringen Leistung. Der Grafikprozessor 1340 von 13B ist ein Beispiel eines Grafikprozessorkerns mit einer höheren Leistungsfähigkeit. Jeder der Grafikprozessoren 1310, 1340 kann Varianten des Grafikprozessors 1210 von 12 sein.
Wie in 13A gezeigt ist, weist der Grafikprozessor 1310 einen Vertexprozessor 1305 und einen oder mehrere Fragmentprozessoren 1315A-1315N (z. B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N) auf. Der Grafikprozessor 1310 kann verschiedene Shaderprogramme über eine separate Logik derart ausführen, dass der Vertexprozessor 1305 optimiert ist, um Operationen für Vertex-Shader-Programme auszuführen, während der eine oder die mehreren Fragmentprozessor(en) 1315A-1315N Fragment(z. B. Pixel-)-shadingoperationen für Fragment- oder Pixelshaderprogramme ausführen. Der Vertexprozessor 1305 führt die Vertexverarbeitungsstufe der 3D-Grafikpipeline durch und erzeugt Primitive und Vertexdaten. Der/die Fragmentprozessor(en) 1315A-1315N verwenden die Primitive und Vertexdaten, die von dem Vertexprozessor 1305 erzeugt werden, um einen Rahmenpuffer zu produzieren, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform ist bzw. sind der bzw. die Fragmentprozessor(en) 1315A-1315N optimiert, um Fragmentshaderprogramme auszuführen, wie in der OpenGL API vorgesehen, welche verwendet werden können, um ähnliche Operationen wie ein Pixelshaderprogramm, wie in der Direct 3D API vorgesehen, durchzuführen.
Der Grafikprozessor 1310 weist zusätzlich eine oder mehrere Speicherverwaltungseinheiten (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 stellen eine Adressenumsetzung von virtuell zu physikalisch für den Grafikprozessor 1310 einschließlich für den Vertexprozessor 1305 und/oder Fragmentprozessor(en) 1315A-1315N bereit, welche sich auf Vertex- oder Bild-/Texturdaten, die in dem Speicher gespeichert sind, zusätzlich zu Vertex- oder Bild-/Texturdaten, die in dem einen oder den mehreren Cache(s) 1325A-1325B gespeichert sind, beziehen kann. In einer Ausführungsform können die eine oder die mehreren MMU(s) 1320A-1320B mit anderen MMUs derart innerhalb des Systems synchronisiert werden, einschließlich einer oder mehrerer MMUs, die mit dem einen oder den mehreren Anwendungsprozessor(en) 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 aus 12 verknüpft sind, dass jeder Prozessor 1205-1220 an einem geteilten oder vereinheitlichten virtuellen Speichersystem beteiligt sein kann. Die eine oder die mehreren Schaltungsverbindung(en) 1330A-1330B ermöglichen dem Grafikprozessor 1310, sich mit anderen IP-Kernen innerhalb des SoC entweder über einen internen Bus des SoC oder über eine direkte Verbindung gemäß Ausführungsformen zu verbinden.
Wie in 13B gezeigt ist, 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 aus 13A auf. Der Grafikprozessor 1340 weist einen oder mehrere Shaderkern(e) 1355A-1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N) auf, was eine vereinheitlichte Shaderkernarchitektur bereitstellt, in welcher ein einzelner Kern oder Typ oder Kern alle Arten von programmierbarem Shadercode einschließlich Shader-Programmcode zum Implementieren von Vertex-Shadern, Fragment-Shadern und/oder Rechen-Shadern ausführen kann. Die genaue Anzahl an vorhandenen Shader-Kernen kann zwischen Ausführungsformen und Implementierungen variieren. Zusätzlich weist der Grafikprozessor 1340 einen Zwischen-Kern-Taskmanager 1345 auf, welcher als ein Thread-Abfertiger agiert, um Ausführungsthreads für einen oder mehrere Shader-Kern(e) 1355A-1355N und eine Tiling-Einheit 1358 zum Beschleunigen von Tiling-Operationen für tile-basiertes Rendern abzufertigen, wo Renderoperationen für eine Szene in Bildraum unterteilt werden, zum Beispiel, um lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder die Verwendung von internen Caches zu optimieren.
14A-14B veranschaulichen eine 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 ein vereinheitlichter Shaderkern 1355A-1355N sein kann, wie in 13B. 14B veranschaulicht eine hochparallele Universalgrafikverarbeitungseinheit 1430, die zum Einsatz auf einem Mehrfach-Chipmodul geeignet ist.
Wie in 14A gezeigt ist, weist der Grafikkern 1400 einen geteilten Anweisungscache 1402, eine Textureinheit 1418 und einen Cache-/geteilten Speicher 1420 auf, die für die Ausführungsressourcen innerhalb des Grafikkerns 1400 gemeinsam sind. Der Grafikkern 1400 kann mehrere Slices 1401A-1401N oder eine Partition für jeden Kern aufweisen, und ein Grafikprozessor kann mehrere Instanzen des Grafikkerns 1400 aufweisen. Die Slices 1401A-1401N können eine Unterstützungslogik aufweisen, die einen lokalen Anweisungscache 1404A-1404N, einen Thread-Planer 1406A-1406N, einen Thread-Abfertiger 1408A-1408N und einen Satz Register 1410A aufweist. Um Logikoperationen durchzuführen, können die Slices 1401A-1401N einen Satz zusätzlicher Funktionseinheiten (AFUs, Additional Function Units, 1412A-1412N), Gleitkommaeinheiten (FPU, Floating-Point Units, 1414A-1414N), ganzzahligen arithmetischen Logikeinheiten (ALUs, Arithmetic Logic Units, 1416-1416N), Adressrecheneinheiten (ACU, Address Computational Units, 1413A-1413N), Doppelpräzisionsgleitkommaeinheiten (DPFPU, Double-Precision Floating-Point Units, 1415A-1415N) und Matrixverarbeitungseinheiten (MPU, Matrix Processing Units, 1417A-1417N) aufweisen.
Einige der Recheneinheiten arbeiten mit einer spezifischen Genauigkeit. Zum Beispiel können die FPUs 1414A-1414N einfachgenaue (32-Bit) und halbgenaue (16-Bit) Gleitkommaoperationen durchführen, während die DPFPUs 1415A-1415N doppeltgenaue (64-Bit) Gleitkommaoperationen durchführen. Die ALUs 1416A-1416N können variable Präzisionsganzzahloperationen mit einer Präzision von 8 Bits, 16 Bits und 32 Bits durchführen und können für Mischpräzisionsoperationen konfiguriert sein. Die MPUs 1417A-1417N können auch für Mischpräzisionsmatrixoperationen einschließlich Halbpräzisionsgleitkomma- und 8-Bit-Ganzzahloperationen konfiguriert sein. Die MPUs 1417A-1417N können eine Vielfalt an Matrixoperationen zum Beschleunigen von Maschinenlernanwendungsframeworks einschließlich des Ermöglichens von Unterstützung für beschleunigte allgemeine Matrix-zu-Matrix-Multiplikation (GEMM, General Matrix to Matrix Multiplication) durchführen. Die AFUs 1412A-1412N können zusätzliche Logikoperationen durchführen, die nicht von den Gleitkomma- oder Ganzzahleinheiten unterstützt werden, einschließlich trigonometrischer Operationen (z. B. Sinus, Cosinus usw.).
Wie in 14B gezeigt ist, kann eine Universalverarbeitungseinheit (GPGPU, General-Purpose Processing Unit) 1430 konfiguriert sein, um zu ermöglichen, dass hochparallele Rechenoperationen von einer Anordnung von Grafikverarbeitungseinheiten durchgeführt werden. Zusätzlich kann die GPGPU 1430 direkt mit anderen Instanzen der GPGPU verbunden sein, um ein Mehrfach-GPU-Cluster zu erzeugen, um die Trainingsgeschwindigkeit für besonders tiefe neuronale Netzwerke zu verbessern. Die GPGPU 1430 weist eine Host-Schnittstelle 1432 auf, um eine Verbindung mit einem Host-Prozessor zu ermöglichen. In einer Ausführungsform ist die Host-Schnittstelle 1432 eine PCI Express-Schnittstelle. Die Host-Schnittstelle kann jedoch auch eine anbieterspezifische Kommunikationsschnittstelle oder ein anwenderspezifisches Kommunikationsfabric sein. Die GPGPU 1430 erhält Befehle von dem Host-Prozessor und verwendet einen globalen Planer 1434 zum Verteilen von Ausführungsthreads, die mit jenen Befehlen verknüpft sind, auf einen Satz Rechencluster 1436A-1436H. Die Rechencluster 1436A-1436H teilen sich einen Cache-Speicher 1438. Der Cache-Speicher 1438 kann als ein Cache höherer Ebene für Cache-Speicher innerhalb der Rechencluster 1436A-1436H dienen.
Die GPGPU 1430 weist den Speicher 1434A-1434B auf, der mit den Rechenclustern 1436A-1436H über einen Satz Speichercontroller 1442A-1442B gekoppelt ist. In verschiedenen Ausführungsformen kann der Speicher 1434A-1434B verschiedene Arten von Speichervorrichtungen einschließlich eines dynamischen Direktzugriffsspeichers (DRAM, Dynamic Random Access Memory) oder Grafikdirektzugriffsspeichers, wie etwa eines synchronen Grafikdirektzugriffsspeichers (SGRAM, Synchronous Graphics Random Access Memory), einschließlich eines Grafikdoppeldatenraten(GDDR)-speichers umfassen.
In einer Ausführungsform weisen die Rechencluster 1436A-1436H jeweils einen Satz Grafikkerne, wie etwa den Grafikkern 1400 von 14A, auf, welcher mehrere Arten von Ganzzahl- und Gleitkommalogikeinheiten umfassen kann, die Rechenoperationen in einem Präzisionsbereich einschließlich der Eignung für Maschinenlernberechnungen durchführen können. Beispielsweise und in einer Ausführungsform kann mindestens eine Teilgruppe der Gleitkommaeinheiten in jedem der Rechencluster 1436A-1436H konfiguriert sein, um 16-Bit-oder 32-Bit-Gleitkommaoperationen durchzuführen, während eine andere Teilgruppe der Gleitkommaeinheiten konfiguriert sein kann, um 64-Bit-Gleitkommaoperationen durchzuführen.
Mehrere Instanzen der GPGPU 1430 können konfiguriert sein, um als ein Rechencluster zu arbeiten. Der Kommunikationsmechanismus, der von dem Rechencluster zur Synchronisierung und zum Datenaustausch verwendet wird, variiert unter den Ausführungsformen. 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 einem GPU-Link 1440 koppelt, die eine direkte Verbindung mit anderen Instanzen der GPGPU ermöglicht. In einer Ausführungsform ist die GPU-Verknüpfung 1440 mit einer dedizierten GPU-zu-GPU-Brücke gekoppelt, die eine Kommunikation und Synchronisierung zwischen mehreren Instanzen der GPGPU 1430 ermöglicht. In einer Ausführungsform ist die GPU-Verknüpfung 1440 mit einer Hochgeschwindigkeitsverschaltung gekoppelt, um Daten zu anderen GPGPUs oder parallelen Prozessoren zu senden oder von diesen zu empfangen. In einer Ausführungsform liegen die mehreren Instanzen der GPGPU 1430 in separaten Datenverarbeitungssystemen und kommunizieren über eine Netzwerkvorrichtung, auf die über die Host-Schnittstelle 1432 zugegriffen werden kann. In einer Ausführungsform kann die GPU-Verknüpfung 1440 konfiguriert sein, um eine Verbindung mit einem Host-Prozessor zusätzlich zu oder als Alternative zu der Host-Schnittstelle 1432 zu ermöglichen.
Wenngleich die veranschaulichte Konfiguration der GPGPU 1430 konfiguriert sein kann, um neuronale Netzwerke zu trainieren, stellt eine Ausführungsform eine alternative Konfiguration der GPGPU 1430 bereit, die zum Einsatz innerhalb einer Hochleistungs- oder Niederenergieinferenzierungsplattform konfiguriert sein kann. Bei einer Inferenzierungskonfiguration weist die GPGPU 1430 wenigere der Rechencluster 1436A-1436H bezüglich der Trainingskonfiguration auf. Zusätzlich kann sich die Speichertechnologie in Verbindung mit dem Speicher 1434A-1434B zwischen Inferenzierungs- und Trainingskonfigurationen unterscheiden, wobei Speichertechnologien mit größerer Bandbreite für Trainingskonfigurationen bestimmt sind. In einer Ausführungsform kann die Inferenzierungskonfiguration der GPGPU 1430 ein Inferenzieren von spezifischen Anweisungen unterstützen. Zum Beispiel kann eine Inferenzierungskonfiguration Unterstützung für einen oder mehrere 8-Bit-Ganzzahl-Skalarproduktanweisungen bereitstellen, welche für gewöhnlich während Inferenzierungsoperationen für eingesetzte neuronale Netzwerke verwendet werden.
15A ist eine Veranschaulichung eines Systems zum Bereitstellen einer automatischen Leistungsdomänenbestimmung gemäß einigen Ausführungsformen. In einigen Ausführungsformen stellt ein Treiber 1515, der auf einem Prozessor (oder Prozessoren) 1510 arbeitet, Grafikkonfigurationsanforderungen (welche Lese- und Schreibanforderungen umfassen können) Registern der Grafik 1560 bereit, wobei die Register in verschiedenen Leistungsdomänen 1565 enthalten sind. Ein Zielregister für eine konkrete Grafikkonfigurationsanforderung kann sich innerhalb einer Leistungsdomäne befinden, die zum Zeitpunkt der Anforderung abgeschaltet wird, und somit muss die Leistungsdomäne zur Verarbeitung der Anforderung eingeschaltet werden. Die Leistungsdomänen 1565 sind der besseren Veranschaulichung wegen als einheitliche Elemente in 15 gezeigt. Die Leistungsdomänen sind jedoch nicht hinsichtlich der Form, Größe oder Anzahl beschränkt und können in variierenden Implementierungen abgeändert werden.
In einigen Ausführungsformen werden die Anforderungen über die Schnittstellenbrücke 1530 zwischen dem Prozessor 1510 und der Grafik 1560 übertragen, wobei die Schnittstellenbrücke einen automatischen Leistungsdomänenmechanismus (APDM, Automatic Power Domain Mechanism) 1540 aufweist, wobei der APDM 1540 ein Hardwaremechanismus zum automatischen Kennzeichnen einer Zielleistungsdomäne ist, und, falls nötig, eine Aufweckanforderung an solch eine Leistungsdomäne als Reaktion auf den Erhalt einer Anforderung bezüglich eines konkreten Zielregisters zu richten.
In einigen Ausführungsformen wird dem APDM 1540 Zugang zu geteilten Informationen 1545 in der Schnittstellenbrücke 1530 gewährt, die verwendet werden können, um eine Leistungsdomäne für ein Register zu bestimmen. In einigen Ausführungsformen werden die geteilten Informationen 1545 von einer Client-Tabelle abgeleitet, die von Nachrichtenkanalroutern verwaltet wird, wobei die Client-Tabelle Client-Adressdaten aufweist, die gesucht werden können, um die Leistungsdomänen für die Clients zu bestimmen, wie nachstehend weiter beschrieben wird.
In einigen Ausführungsformen kombiniert die automatische Domänenbestimmung durch den APDM 1540 das Entkoppeln von Anforderungen mit der automatischen Bestimmung der angezielten Leistungsdomäne, wobei die automatische Bestimmung der Leistungsdomäne die geteilten Informationen 1545 verwendet, die von einer Client-Tabelle abgeleitet werden, die bereits zu Weiterleitungszwecken verwaltet wird.
Im Betrieb vereinfacht eine Ausführungsform eines automatischen Leistungsdomänenmechanismus das Programmieren und schützt den Treibercode vor Systemmodifikationen einschließlich Änderungen bezüglich künftiger Produkte. Der Leistungsdomänenbestimmungsprozess kann somit eine feinere Granularität bei der Leistungsdomänensteuerung ohne Belastung des Treibers ermöglichen, welcher keinerlei Kenntnisse bezüglich der Bestimmung von Leistungsdomänen haben muss. Ferner wird der Abschluss von Grafikkonfigurationsanforderungen von dem Domänenaufweckfluss entkoppelt, so dass die Nicht-Kern-Fabric nicht zum Stillstand gebracht wird, während darauf gewartet wird, dass die geeignete Zielleistungsdomäne aktiv ist.
15B ist ein Flussdiagramm zum Veranschaulichen eines Prozesses zur automatischen Leistungsdomänenbestimmung gemäß einigen Ausführungsformen. In einigen Ausführungsformen umfasst ein Prozess:

1570: Empfangen durch einen Leistungsdomänenbestimmungsmechanismus innerhalb einer Schnittstellenbrücke einer Konfigurationsanforderung bezüglich eines Zielregisters, wobei sich das Zielregister in einer einer Anzahl an Leistungsdomänen befindet.
1572: Kennzeichnen der Leistungsdomäne für das Zielregister basierend auf geteilten Informationen, die in der Schnittstellenbrücke enthalten sind.
1574: Bestimmen, ob sich die gekennzeichnete Leistungsdomäne in einem Zustand mit verringerter Leistung befindet.
1576: Wenn sich die Leistungsdomäne in einem Zustand mit verringerter Leistung befindet, Senden einer Aufweckanzeige für die Leistungsdomäne. Wenn sich die Leistungsdomäne nicht in einem Zustand mit verringerter Leistung befindet, fährt der Prozess zu 1580 fort.
1578: Entsperren der Schnittstellenbrücke, um zu erlauben, dass die Konfigurationsanforderung fortfährt.
1580: Übertragen der Konfigurationsanforderung zu dem angezielten Register.

16 ist eine Veranschaulichung einer Schnittstellenbrücke einschließlich automatischer Leistungsdomänenbestimmung gemäß einigen Ausführungsformen. 16 ist eine Veranschaulichung einer konkreten Topologie mit einer CPU-zu-GT-Schnittstellenbrücke und mehreren Leistungsdomänen in dem Grafikteilsystem gemäß einer Ausführungsform. In einigen Ausführungsformen enthält eine Brückendomäne 1625, welche immer während dem Betrieb eingeschaltet sein kann, eine Schnittstellenbrücke 1630 und einen Nachrichtenkanalrouter (MCR, Message Channel Router) 1636. Die Schnittstellenbrücke umfasst einen IOSF-Seitenband(IOSF SB)-endpunkt 1632 und einen Nachrichtenkanalendpunkt (MCEP, Message Channel Endpoint) 1634. In einigen Ausführungsformen wird die Schnittstellenbrücke 1630 eine automatische Leistungsdomänenbestimmung für eine Grafikkonfigurationsanforderung bereitstellen, wobei die Schnittstellenbrücke 1630 einen Mechanismus zum Verwenden von Nachrichtenroutinginformationen zur Kennzeichnung einer Zielleistungsdomäne zum Bereitstellen einer Entkopplung der Ausführung der Anforderung von dem Treiber aufweist.
Eine Treiberanforderung bezüglich der Grafikkonfiguration (von einem Treiber über den Grafikteilsystemumfang) wird an dem IOSF SB-Endpunkt 1632 erhalten und der MCEP 1634 stellt dem MCR 1636 eine entkoppelte Adresse bereit. Die Schnittstellenbrücke 1630 wird sich anfangs in einem gesperrten Zustand befinden, um ein Aufwecken einer beabsichtigten Zielleistungsdomäne in dem automatischen Leistungsdomänenbestimmungsprozess zu erlauben.
In der in 16 bereitgestellten Veranschaulichung zielt eine Anforderung von dem Treiber auf ein konkretes angezieltes Register in der Leistungsdomäne 0 (PD0) ab. Um einen Fehlerzustand zu verhindern, muss PD0 aktiv sein, bevor die Anforderung zu dem Register gesendet wird. In 16 umfassen die GT-Domänen die Leistungsdomänen 0 bis 5, wobei jede Leistungsdomäne ein oder mehrere Register aufweisen kann. In einigen Ausführungsformen wird eine Grafikleistungsverwaltungseinheit (GPM, Graphics Power Management) 1680 die geeignete Leistungsdomäne (die Leistungsdomäne 0 in diesem Beispiel) aufwecken und entsperrt die Schnittstellenbrücke, um eine Übertragung der Konfigurationsanforderung zu dem Zielregister 1675 zu erlauben. Die Grafikdomänen 1670 und die Brückendomäne 1625 können unterschiedliche Frequenzdomänen sein, und somit kann der Datentraffic eine Umwandlung erfordern. In einigen Ausführungsformen leitet das MCR 1636 die Anforderung über die asynchrone Überquerungswarteschlange (ACQ, Asynchronous Crossing Queue) 1640 an der Partitionsgrenze zu dem MCR 1672 in der Leistungsdomäne 0, wobei die ACQ eine Umwandlung zwischen den Frequenzdomänen handhabt.
In einigen Ausführungsformen ist der Prozessfluss zum Ansprechen der PD0 und Weiterleiten der Anforderung an ihr Ziel transparent für den Treiber. Die automatische Domänenbestimmungslogik in der Schnittstellenbrücke, die mit der Client-Topologie in Grafik ausgerichtet ist, ermöglicht somit eine Steuerung mit feiner Granularität einer skalierbaren Menge von Domänen über Projekten, da die Leistungsdomänen bezüglich der Anzahl erhöht und modifiziert werden können, ohne den Treiber zu beeinträchtigen. Die feine Granularität wiederum bietet einen Vorteil bezüglich der Leistungseffizienz des Grafikteilsystems, indem sie erlaubt, dass weniger Teile des Teilsystems aktiv sind, wenn benötigte Operationen bereitgestellt werden.
17A und 17B veranschaulichen Elemente eines automatischen Leistungsdomänenmechanismus gemäß einigen Ausführungsformen. In einigen Ausführungsformen umfasst der automatische Leistungsdomänenmechanismus (APDM, Automatic Power Domain Mechanism) 1700 Hardware innerhalb von einer Prozessor-GT-Schnittstellenbrücke, wobei die Schnittstellenbrücke die Schnittstellenbrücke 1530, die in 15 veranschaulicht ist, oder die Schnittstellenbrücke 1630, die in 16 veranschaulicht ist, umfassen kann.
In einigen Ausführungsformen umfasst der APDM 1700 Folgendes

1. Einen Konfigurationsregisterblock (cfg) 1710 (wie in 17B gezeigt) innerhalb der Schnittstellenbrücke 1700, der Folgendes aufweist:
- a. ein Speichern für Schnittstellenbrückenregister 1712-1714, wobei die Register Entkopplungsanforderungsregisterpaare 1714 aufweisen;
- b. eine automatische Domänenbestimmungslogik 1716. Die Bestimmungslogik teilt Informationen, die von einer Client-Tabelle abgeleitet sind, mit der Routing-Fabric (Nachrichtenkanalrouting) innerhalb der GT-Domänen. Da auf dieselben Informationen durch die Bestimmungslogik und die Routing-Fabric Bezug genommen wird, wird das Zielrouting innerhalb der GT mit der Domänenbestimmung in der Schnittstellenbrücke ausgerichtet sein; und
- c. eine Aufweckanzeigelogik 1718, um eine beliebige Leistungsdomäne zu kennzeichnen, die für eine Konfigurationsanforderung aktiviert werden muss (d. h., sich in einem Zustand mit verringerter Leistung befindet).
2. einen Entkopplungsanforderungsprozessor (dcr) 1750 (wie in 17A gezeigt) einschließlich folgender Logik:
- a. einen Arbitrierer (rr_arbiter) 1752 zum Auswählen und Präsentieren einer Anforderung bezüglich einer aktiven Leistungsdomäne, und
- b. eine automatisierte Handshake(block fsm)-logik 1754 zum Bereitstellen eines Handshakes mit einem Blockcontroller (block_ctrl) 1760.

In einigen Ausführungsformen stellt der Entkopplungsanforderungsprozessor 1750 dem CPU-Softwaretreiber einen nicht-sperrenden Pfad während dem CPD (Clock Power Down, Taktabschalten) bereit. Bei einer Implementierung werden sechzehn Paare (16x2) von Entkopplungsanforderungsregistern 1714, die sich in der Schnittstellenbrücke 1710 befinden, für verschiedene Softwarethreads zur Verwendung bereitgestellt. Jedes Registerpaar der Entkopplungsanforderungsregister 1714 unterstützt eine Lese- oder Schreibanforderung, die über den Nachrichtenkanal 1780 gesendet werden wird, sobald die programmierte Leistungssenkendomäne entsperrt ist. Die Programmierung des Registerpaars wird von der Nachrichtenkanalanforderung entkoppelt, die erzeugt wird, und wird immer unmittelbar abgeschlossen, selbst während dem GT CPD. Um zu bestimmen, wann die Anforderung bei dem Nachrichtenkanal zu ihrem vorgesehenen Ziel abgeschlossen worden ist, wird ein GO-Statusbit in DW1 des Entkopplungsregisterpaars von dem Treiber abgefragt, bis GO gelöscht worden ist.
18 ist eine Veranschaulichung eines Registerpaars, das bei der automatischen Leistungsdomänenbestimmung zu verwenden ist, gemäß einigen Ausführungsformen. Auf die Entkopplungsanforderungs(DCR)-registerpaare kann von der CPU innerhalb eines MMIO(Memory Mapped Input/Output, speicherabgebildete Eingabe/Ausgabe)-raums, der zu der Schnittstellenbrücke gehört, zugegriffen werden. Jedes Entkopplungsanforderungs(DCR)-registerpaar kann wie in 18 vorgesehen definiert werden, welche ein beispielhaftes Paar von Konfigurationsregistern veranschaulicht, in welchem jedes Register 32 Bits aufweist. Das Registerpaar umfasst:

(a) das Entkopplungsregister DW0, das 32 Datenbits enthält - Daten[31:0]; und
(b) das Entkopplungsregister Dw1 - ein einzelnes Bit für GO - GO[31]; drei Bits für Opcode-OP[30:28]; vier Bits für Byte Enables aktiv niedrig - BE B [27:24]; und vierundzwanzig Bits für die Adresse[23:0].

In einem herkömmlichen Betrieb kann ein Prozess zum Lesen in oder Schreiben von durch eine CPU zugängliche Grafikregister einen von drei separaten Flüssen je nachdem, ob das Zielregister für eine konkrete Anforderung schattiert ist und ob Schattenlesedaten für solch eine Anforderung akzeptabel sind, verwenden. Bei solchen Flüssen kann der Treiber entweder die Anforderung direkt senden; die Anforderung in einem Zwangsaufweckfluss einwickeln; oder den Entkopplungsanforderungsmechanismus verwenden. In einem Beispiel des Zwangsaufweckflusses können die folgenden Prozesse angewendet werden, um in durch CPU zugängliche Register in GT-Domänen zu lesen oder schreiben:

1. Der Treiber bestimmt, zu welcher Leistungsdomäne eine empfangene Adresse gehört. Die Leistungsdomäne kann sich von einem Projekt zum anderen ändern, und somit ist es wichtig, sicherzustellen, dass die richtige Domäne für das Projekt ausgewählt wird.
2. Der Treiber schreibt in die jeweilige Zwangsaufweckdomäne, um den Wunsch anzuzeigen, das Ziel aufzuwecken, und fragt das Register ab, um zu bestimmen, wann es sicher ist, die Anforderung zu dem Register zu senden. Das Zwangsaufweckregister wird schattiert und die Aktualisierung bezüglich des Schattenregisters bewirkt eine GT-Aufweckanzeige.
3. Die Schnittstellenbrücke, welche den Domänenstatus versteht, bestätigt der GT-Leistungsverwaltungseinheit (GPM) ein Aufwecksignal. Die GPM weckt die GT auf und entsperrt die Schnittstellenbrücke.
4. Die Schnittstellenbrücke ist dann in der Lage, die Zwangsaufweckanzeige zu der GPM zu senden, welche die GPM dann verwendet, um die spezifische Domäne aufzuwecken, innerhalb der sich das Zielregister befindet. Die GPM sendet dann eine Entsperrungsanzeige zu der Schnittstellenbrücke. Die Abfrage von dem Treiber wird dann erfolgreich mit einer Anzeige, dass die Zielleistungsdomäne eingeschaltet ist, abschließen.
5. Sobald der Treiber bestimmt hat, dass die Zielleistungsdomäne eingeschaltet ist, wird die gewünschte Anforderung von dem Treiber initiiert und auf dem Nachrichtenkanal zu dem Zielregister gesendet.

In einigen Ausführungsformen implementiert ein automatischer Leistungsdomänenmechanismus folgende Prozesse, um in durch CPU zugängliche Register in GT-Domänen zu lesen oder schreiben:

1. Der Treiber programmiert ein verfügbares DCR(Decouple Register, Entkopplungsregister)-Registerpaar mit dem Opcode, der Zieladresse und Daten im Falle von Schreib-Opcode. Der Treiber ruft dann dieses Register für den Abschlussstatus ab.
2. Die Schnittstellenbrücke verwendet die programmierte Adresse, um automatisch zu bestimmen, welche eine oder mehreren Domänen aufgeweckt sein müssen, und bestätigt eine Aufweckleitung bezüglich den spezifischen Domänen. Die GPM weckt die eine oder mehreren Domänen auf und entsperrt die Schnittstellenbrücke.
3. Sobald die Schnittstellenbrücke entsperrt ist, ist die programmierte Anforderung in der Lage, die Übertragung auf dem Nachrichtenkanal abzuschließen. Die nächste Abtastung des Treibers von dem DCR-Register wird den Anforderungsabschluss anzeigen.

Es werden deutliche Vorteile durch eine Ausführungsform eines Leistungsdomänenmechanismus bereitgestellt, der die Entkopplungsanforderungsregister kombiniert mit dem automatischen Domänenbestimmungsmechanismus verwendet, einschließlich der Folgenden:

1. Der Treiber kann einen Fluss für alle Register, auf die durch die CPU zugegriffen werden kann, verwenden, ohne den Schattenstatus eines Registers zu berücksichtigen oder zu berücksichtigen, zu welcher Leistungsdomäne das Register gehört.
2. Der Treiber benötigt nur eine Schreibanforderung gefolgt von dem Abrufen eines Registers, in Bezug auf welches garantiert wird, dass es ohne Verzögerung abschließt. Im Vergleich dazu benötigt ein alter Zwangsaufweckfluss ein zusätzliches Handshake von dem Treiber, um sicherzustellen, dass das Zielregister eingeschaltet ist.
3. Da die Leistungsdomäne automatisch bestimmt wird, ist es nicht möglich, dass ein System eine falsche Leistungsdomäne programmiert oder zwanghaft aufweckt. Bei einer alten Lösung umfassen, wenn ein Fehler bezüglich der Leistungsdomäne für ein Zielregister gemacht wird, und folglich die vorgesehene Leistungsdomäne nicht während einer Anforderung aktiv ist, die möglichen Konsequenzen verloren gegangene Schreibdaten, falsche Lesedaten oder eine Systemaufhängung.

In einigen Ausführungsformen ist der automatische Leistungsdomänenmechanismus eine Komponente einer Leistungsverwaltungsstrategie, um Leistungsdomänen nur während den Zeiträumen aktiv (eingeschaltet) zu halten, während welchen sie Anforderungen bedienen oder anderweitig aktiv sein müssen.
In einigen Ausführungsformen bestimmt der Entkopplungsanforderungsprozessor automatisch die Leistungssenke, die aufgeweckt werden muss, wobei Informationen von derselben Client-Tabelle wirksam eingesetzt werden, die von einem Nachrichtenkanalfabric verwendet werden. Der mcuiddec (Message Channel UID Decoder, Nachrichtenkanal-UID-Decodierer) stellt eine Anzeige für Render-, Medien-, Medien-Slice ID und Medien-Subslice-ID bereit, welche zusammen mit der uid erlaubt, dass die Brücke zwischen jeder GT, Rendern und jeder der VDBOX- und VEBOX-Domänen unterscheidet. Das Medien-Slice-SPC-Ziel befindet sich in der GT-Leistungsdomäne, so dass für Aufweckanzeigen diese als GT zählen.
Die Adresse wird zunächst verwendet, um zu bestimmen, in welchen Client-Bereich (uid (Unit ID)) die Anforderung fällt. Die n-te uid wird verwendet, um die Leistungsdomäne zu bestimmen.
Der folgende Pseudocode veranschaulicht in einer Ausführungsform, wie die automatische Leistungsdomänenbestimmungshardware die Bestimmungsdomäne anhand der Client-ID (uid) bestimmen kann:
Bei einer Implementierung kann die Adresse-zu-Domäne-Berechnung in einem einzigen Takt innerhalb des cfg-Blocks durchgeführt werden.
19 ist ein beispielhafter Prozessfluss, der eine automatische Leistungsdomänenbestimmung unter Verwendung eines Entkopplungsanforderungsschreibens gemäß einigen Ausführungsformen veranschaulicht. Wie in 19 veranschaulicht ist, umfasst der Prozessfluss Kommunikationen über ein IOSF-Seitenband (Treiberoperation) 1905, eine Schnittstellenbrücke 1910 und einen GT(Grafik)-Nachrichtenkanal 1915. In einigen Ausführungsformen umfasst der Prozessfluss Folgendes:

1. Ein Treiber wird eine Lese- oder Schreibanforderung senden, die auf die Grafikdomäne abzielt. In einem möglichen Beispiel ist die Adresse für eine Schreibanforderung 22040. Der Treiber programmiert zunächst ein Registerpaar (wobei das Registerpaar wie in 18 veranschaulicht sein kann), wie etwa ein Programmieren von DCR0 DW0 mit den vorgesehenen Schreibdaten (MWr DCR0 DW0) und Erhalten einer Bestätigung (Cmp). In diesem Beispiel programmiert dann der Treiber DCR0 DW1 (MWr DCR0 DW1) mit den folgenden Attributen (wie die Felder in 18 veranschaulicht sind):
- GO = 1'b1,
- OP = WRITE,
- Address = 22040
Alternativ kann die Programmierung in einem Einzel-QW(Quad-Word, Länge 2) - Schreibvorgang erzielt werden. Während diesem Zeitraum ist verboten, dass SB-Zyklen zu dem Nachrichtenkanal weitergeleitet werden (1920).
2. Die Schnittstellenbrücke wird entsperrt (GT-Entsperrungsanforderung gefolgt von Leseanforderung MRd DCR 0 DW1). Während diesem Zeitraum können SB-Zyklen zu dem Nachrichtenkanal weitergeleitet werden (1925).
3. Der DCR-Prozessor der Brücke fertigt die Schreibanforderung (DCR Write) für die Adresse 22040 ab, wobei die Daten präsentiert werden, die in dem DCR0 DW0-Datenfeld aufgenommen werden.
4. Das MCR bestätigt die Anforderung (Entsperrungsbestätigung) und die Schnittstellenbrücke löscht das GO-Abschlussstatusbit in DCR0 DW1 (DCR 0 DW1, GO = 0). Während diesem Zeitraum müssen SB-Zyklen zu dem Nachrichtenkanal weitergeleitet werden (1930).
5. Der Treiber fragt das GO-Abschlussstatusbit in DCR DW1 ab (1935). Da das Status-Bit gelöscht worden ist, versteht der Treiber, dass die Anforderung abgeschlossen worden ist.
6. Der IA-Treiber kann nun das Entkopplungsregister 0 für eine neue Anforderung wiederverwenden.

20 ist ein Flussdiagramm zum Veranschaulichen eines Prozesses zum Bereitstellen einer automatischen Leistungsdomänenbestimmung gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann ein Prozess Folgendes umfassen:

2002: Erhalten einer Grafikkonfigurationsanforderung an einem oder mehreren Konfigurationsregistern (wie etwa einem Registerpaar, wie in 18 veranschaulicht ist, was im Folgenden als Konfigurationsregister bezeichnet wird) einer Schnittstellenbrücke, wobei die Anforderung an ein Zielgrafikregister in einer Grafikdomäne gerichtet ist. In einigen Ausführungsformen ist die Anforderung von einem automatischen Leistungsdomänenmechanismus handzuhaben (welcher den APDM 1540, der in 15 veranschaulicht ist, oder den APDM 1700, der in 17 veranschaulicht ist, umfassen kann). Die Anforderung kann von einem Treiber eines Systemprozessors erhalten werden. Die Schnittstellenbrücke befindet sich anfangs in einem gesperrten Zustand, um eine Übertragung einer Konfigurationsanforderung zu verhindern.
2006: Festlegen mindestens eines Registerbits (wie etwa GO = 1) in dem Konfigurationsregister, wobei das Registerbit ein Abschlussstatusbit ist, wobei das Festlegen des Abschlussstatusbits anzeigt, dass das eine oder die mehreren Register nicht zur Verwendung für eine andere Konfigurationsanforderung bereit sind.
2008: Kennzeichnen einer Leistungsdomäne für das angezielte Register basierend mindestens teilweise auf geteilten Informationen, wobei die geteilten Informationen umfassen können, die von einer Client-Tabelle mit Ausrichtung von Adressen auf Clients und den Leistungsdomänen, zu denen die Clients gehören, abgeleitet sind. Die Client-Tabelle kann die geteilten Informationen 1545 aufweisen, die mit Nachrichtenkanalroutern geteilt werden, wie in 15 veranschaulicht ist.
2010: Bestimmen, ob sich die gekennzeichnete Leistungsdomäne aktuell in einem Zustand mit verringerter Leistung befindet.
2012: Erzeugen einer Aufweckanzeige für die gekennzeichnete Leistungsdomäne des angezielten Registers, wenn sich die Leistungsdomäne in einem Zustand mit verringerter Leistung befindet. Wenn sich die Leistungsdomäne nicht in einem Zustand mit verringerter Leistung befindet, fährt der Prozess zu 2018 fort.
2014: Bereitstellen eines Handshakes mit einem Block-Controller, um eine Implementierung der Grafikkonfigurationsanforderung zu ermöglichen.
2016: Entsperren der Schnittstellenbrücke, um eine Übertragung der Konfigurationsanforderung zu erlauben.
2018: Übertragen der Konfigurationsanforderung zu dem angezielten Register in der Grafikdomäne. Das Übertragen der Konfigurationsanforderung kann das Arbitrieren zwischen mehreren Anforderungen bezüglich der Grafikregister umfassen.
2020: Aktualisieren von Daten in dem einen oder den mehreren Konfigurationsregistern, wie für die Konfigurationsanforderung benötigt, und Löschen des GO-Abschlussstatusbits, um die Wiederverwendung des jeweiligen einen oder der jeweiligen mehreren Konfigurationsregister zu erlauben.
2022: Die Brücke bestätigt die Aufweckanzeige für die Domäne nicht auf die Konfigurationsanforderungsübertragung folgend, wobei dem GPM erlaubt wird, die Schnittstellenbrücke zu sperren und die Domäne in Bereitschaft zu versetzen.

In einigen Ausführungsformen weist eine Vorrichtung eine Schnittstelle zum Erhalten einer Grafikkonfigurationsanforderung, wobei die Grafikkonfigurationsanforderung an ein Zielgrafikregister in einer Grafikdomäne gerichtet ist; mehrere Register zum Speichern von Daten, wobei die mehreren Register ein oder mehrere Konfigurationsregister umfassen, auf die zum Speichern der Grafikkonfigurationsanforderung zugegriffen werden kann; eine automatische Leistungsdomänenbestimmungslogik zum Kennzeichnen einer Leistungsdomäne für das Zielgrafikregister basierend auf geteilten Informationen, auf die von der automatischen Leistungsdomänenbestimmungslogik zugegriffen wird; und eine Aufweckanzeigelogik zum Bestimmen, ob sich die Leistungsdomäne für das Zielgrafikregister in einem Zustand mit verringerter Leistung befindet, und nach dem Durchführen einer Bestimmung eines Zustands mit verringerter Leistung, zum Erzeugen einer Aufweckanzeige für die Leistungsdomäne, auf.
In einigen Ausführungsformen werden die geteilten Informationen von einer Client-Tabelle mit Daten mit Ausrichtung von Adressen auf Clients und Leistungsdomänen für die Clients abgeleitet.
In einigen Ausführungsformen werden die Informationen von der Client-Tabelle mit Nachrichtenkanalroutern für einen Nachrichtenkanal für die Grafikdomäne geteilt.
In einigen Ausführungsformen befindet sich die Vorrichtung innerhalb einer Schnittstellenbrücke zwischen einem Systemprozessor und der Grafikdomäne.
In einigen Ausführungsformen weist die Vorrichtung ferner einen Entkopplungsanforderungsprozessor zum Verarbeiten von Anforderungen einschließlich der Grafikkonfigurationsanforderung auf.
In einigen Ausführungsformen weist der Entkopplungsanforderungsprozessor einen Arbitrierer zum Auswählen und Präsentieren von Konfigurationsanforderungen bezüglich aktiver Leistungsdomänen auf.
In einigen Ausführungsformen weist der Entkopplungsanforderungsprozessor eine automatisierte Handshake-Logik zum Bereitstellen eines Handshakes mit einem Block-Controller auf.
In einigen Ausführungsformen sperrt der Block-Controller die Schnittstellenbrücke, um eine Übertragung von Anforderungen zu verhindern, bevor sich eine Leistungsdomäne in einem aktiven Leistungszustand befindet, und die Schnittstellenbrücke entsperren, um eine Übertragung der Konfigurationsanforderung nach der Bestimmung, dass sich die gekennzeichnete Leistungsdomäne in dem aktiven Leistungszustand befindet, zu erlauben.
In einigen Ausführungsformen umfassen das eine oder die mehreren Konfigurationsregister ein oder mehrere Entkopplungsanforderungsregister.
In einigen Ausführungsformen weisen das eine oder die mehreren Konfigurationsregister ein oder mehrere Bits zum Anzeigen eines Abschlussstatus für die Konfigurationsanforderung auf.
In einigen Ausführungsformen sind auf einem nichtflüchtigen computerlesbaren Speichermedium Daten gespeichert, die Sequenzen von Anweisungen darstellen, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Operationen durchführen, die das Erhalten einer Grafikkonfigurationsanforderung an einem oder mehreren Konfigurationsregistern einer Schnittstellenbrücke, wobei die Anforderung an ein Zielgrafikregister gerichtet ist; das Kennzeichnen einer Leistungsdomäne für das Zielgrafikregister, wobei die Kennzeichnung der Leistungsdomäne mindestens zum Teil auf geteilten Informationen basiert, die für Adressrouting verwaltet werden; das Bestimmen, ob sich die gekennzeichnete Leistungsdomäne in einem Zustand mit verringerter Leistung befindet; nach dem Bestimmen, dass sich die gekennzeichnete Leistungsdomäne in einem Zustand mit verringerter Leistung befindet, das Erzeugen einer Aufweckanzeige für die gekennzeichnete Leistungsdomäne; und das Übertragen der Konfigurationsanforderung zu dem Zielgrafikregister umfassen.
In einigen Ausführungsformen sind das eine oder die mehreren Konfigurationsregister in einer Schnittstellenbrücke zwischen einem Prozessor und einer Grafikdomäne enthalten.
In einigen Ausführungsformen wird die Konfigurationsanforderung von einem Treiber erhalten, der von einem Prozessor ausgeführt wird.
In einigen Ausführungsformen umfassen die geteilten Informationen Daten mit Ausrichtung von Adressen auf Clients und Leistungsdomänen für die Clients.
In einigen Ausführungsformen weist das Medium ferner Anweisungen auf, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Operationen durchführen, die das Festlegen eines Abschlussstatusbits des einen oder der mehreren Konfigurationsregister nach dem Erhalten der Konfigurationsanforderung und Löschen des Abschlussstatusbits nach dem Übertragen der Konfigurationsanforderung zu dem Zielgrafikregister umfassen.
In einigen Ausführungsformen weist das Medium ferner Anweisungen auf, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Operationen durchführen, die das Sperren der Schnittstellenbrücke, um eine Übertragung von Anforderungen zu verhindern, bevor sich eine Leistungsdomäne in einem aktiven Leistungszustand befindet, und das Entsperren der Schnittstellenbrücke, um eine Übertragung der Konfigurationsanforderung nach dem Bestimmen, dass sich die gekennzeichnete Leistungsdomäne in dem aktiven Leistungszustand befindet, zu erlauben, umfassen.
In einigen Ausführungsformen umfassen das eine oder die mehreren Konfigurationsregister ein oder mehrere Entkopplungsanforderungsregister.
In einigen Ausführungsformen umfasst das Übertragen der Konfigurationsanforderung zu dem Zielgrafikregister das Arbitrieren zum Auswählen und Präsentieren von Konfigurationsanforderungen bezüglich aktiver Leistungsdomänen.
In einigen Ausführungsformen weist eine Vorrichtung Mittel zum Erhalten einer Grafikkonfigurationsanforderung an einem oder mehreren Konfigurationsregistern einer Schnittstellenbrücke, wobei die Anforderung an ein Zielgrafikregister gerichtet ist; Mittel zum Kennzeichnen einer Leistungsdomäne für das Zielgrafikregister, wobei die Kennzeichnung der Leistungsdomäne mindestens teilweise auf geteilten Informationen basiert, die für Adressrouting verwaltet werden; Mittel zum Bestimmen, ob sich die gekennzeichnete Leistungsdomäne in einem Zustand mit verringerter Leistung befindet; Mittel zum Erzeugen einer Aufweckanzeige für die gekennzeichnete Leistungsdomäne nach dem Bestimmen, dass sich die gekennzeichnete Leistungsdomäne in einem Zustand mit verringerter Leistung befindet; und Mittel zum Übertragen der Konfigurationsanforderung zu dem Zielgrafikregister auf.
In einigen Ausführungsformen sind das eine oder die mehreren Konfigurationsregister in einer Schnittstellenbrücke zwischen einem Prozessor und einer Grafikdomäne enthalten.
In einigen Ausführungsformen wird die Konfigurationsanforderung von einem Treiber erhalten, der von einem Prozessor ausgeführt wird.
In einigen Ausführungsformen umfassen die geteilten Informationen Daten mit Ausrichtung von Adressen auf Clients und Leistungsdomänen für die Clients.
In einigen Ausführungsformen weist die Vorrichtung ferner Mittel zum Festlegen eines Abschlussstatusbits des einen oder der mehreren Konfigurationsregister nach dem Erhalten der Konfigurationsanforderung und Löschen des Abschlussstatusbits nach dem Übertragen der Konfigurationsanforderung zu dem Zielgrafikregister auf.
In einigen Ausführungsformen weist die Vorrichtung ferner Mittel zum Sperren der Schnittstellenbrücke, um eine Übertragung von Anforderungen zu verhindern, bevor sich eine Leistungsdomäne in einem aktiven Leistungszustand befindet, und Entsperren der Schnittstellenbrücke, um eine Übertragung der Konfigurationsanforderung nach der Bestimmung, dass sich die gekennzeichnete Leistungsdomäne in dem aktiven Leistungszustand befindet, zu erlauben, auf.
In einigen Ausführungsformen umfassen das eine oder die mehreren Konfigurationsregister ein oder mehrere Entkopplungsanforderungsregister.
In einigen Ausführungsformen umfassen die Mittel zum Übertragen der Konfigurationsanforderung zu dem Zielgrafikregister Mittel zum Arbitrieren, um Konfigurationsanforderungen bezüglich aktiver Leistungsdomänen auszuwählen und zu präsentieren.
In einigen Ausführungsformen umfasst ein System einen Prozessor zum Verarbeiten von Daten; eine Grafikdomäne zur Grafikoperation; einen Treiber, der von dem Prozessor ausgeführt wird, um Zielgrafikregistern in der Grafikdomäne Konfigurationsanforderungen bereitzustellen; und eine Schnittstellenbrücke zwischen dem Prozessor und der Grafikdomäne, wobei die Schnittstellenbrücke mehrere Konfigurationsregister aufweist, wobei die Konfigurationsregister mehrere Register zum Erhalten von Grafikkonfigurationsanforderungen umfassen, einen automatischen Leistungsdomänenmechanismus zum Kennzeichnen einer Leistungsdomäne für ein Zielgrafikregister für jede Konfigurationsanforderung, die von dem Treiber erhalten wird, um zu bestimmen, ob sich eine gekennzeichnete Leistungsdomäne in einem Zustand mit verringerter Leistung befindet, und nach dem Bestimmen, dass sich eine gekennzeichnete Leistungsdomäne in einem Zustand mit verringerter Leistung befindet, eine Aufweckanzeige für die Leistungsdomäne zu erzeugen, und einen Prozessor zum Verarbeiten von Konfigurationsanforderungen. In einigen Ausführungsformen kennzeichnet der automatische Leistungsdomänenmechanismus eine Leistungsdomäne für das Zielgrafikregister basierend auf geteilten Informationen, auf die von dem automatischen Leistungsdomänenmechanismus zugegriffen wird.
In einigen Ausführungsformen umfassen die geteilten Informationen Informationen, die von einer Client-Tabelle mit Daten mit Ausrichtung von Adressen auf Clients und Leistungsdomänen für die Clients abgeleitet sind.
In einigen Ausführungsformen ist die Schnittstellenbrücke während dem Betrieb des Systems eingeschaltet.
In einigen Ausführungsformen ist der Prozessor zum Verarbeiten von Konfigurationsanforderungen ein Entkopplungsanforderungsprozessor.
In einigen Ausführungsformen weist der Entkopplungsanforderungsprozessor einen Arbitrierer zum Auswählen und Präsentieren von Konfigurationsanforderungen bezüglich aktiver Leistungsdomänen auf.
In einigen Ausführungsformen weist der Entkopplungsanforderungsprozessor eine automatisierte Handshake-Logik zum Bereitstellen eines Handshakes mit einem Block-Controller auf, wobei der Block-Controller die Schnittstellenbrücke sperrt, um eine Übertragung von Anforderungen zu verhindern, bevor sich eine Leistungsdomäne in einem aktiven Leistungszustand befindet, und die Schnittstellenbrücke entsperrt, um eine Übertragung der Konfigurationsanforderung nach der Bestimmung, dass sich die gekennzeichnete Leistungsdomäne in dem aktiven Leistungszustand befindet, zu erlauben.
Bei der vorherigen Beschreibung sind zu Erläuterungszwecken spezifische Details dargelegt, um ein umfassendes Verständnis der beschriebenen Ausführungsformen bereitzustellen. Für einen Fachmann wird jedoch offensichtlich sein, dass die Ausführungsformen ohne einige dieser spezifischen Details durchgeführt werden können. In anderen Fällen sind hinreichend bekannte Strukturen und Vorrichtungen in Blockdiagrammform gezeigt. Es kann eine Zwischenstruktur zwischen den veranschaulichten Komponenten vorhanden sein. Die hierin beschriebenen oder veranschaulichten Komponenten können zusätzliche Eingänge oder Ausgänge aufweisen, die nicht veranschaulicht oder beschrieben sind.
Verschiedene Ausführungsformen können verschiedene Prozesse umfassen. Diese Prozesse können durch Hardwarekomponenten durchgeführt werden oder können in von einem Computerprogramm oder einer Maschine ausführbaren Anweisungen ausgeführt werden, welche verwendet werden können, um zu bewirken, dass ein Universalprozessor oder Sonderzweckprozessor oder Logikschaltungen, die mit den Anweisungen programmiert sind, die Prozesse durchführen. Alternativ können die Prozesse durch eine Kombination von Hardware und Software durchgeführt werden.
Teile verschiedener Ausführungsformen können als ein Computerprogrammprodukt bereitgestellt werden, welches ein computerlesbares Medium umfassen kann, auf dem Computerprogrammanweisungen gespeichert sind, welche verwendet werden können, um einen Computer (oder andere elektronische Vorrichtungen) zur Ausführung durch einen oder mehrere Prozessoren zum Durchführen eines Prozesses gemäß konkreten Ausführungsformen zu programmieren. Das computerlesbare Medium kann Magnetplatten, optische Platten, einen Nur-Lese-Speicher (ROM, Read-Only Memory), einen Direktzugriffsspeicher (RAM, Random Access Memory), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM, Erasable Programmable Read-Only Memory), einen elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM, Electrically Erasable Programmable Read-Only Memory), magnetische oder optische Karten, einen Flash-Speicher oder eine sonstige Art von computerlesbarem Medium, das zum Speichern von elektronischen Anweisungen geeignet ist, ohne jedoch darauf beschränkt zu sein, umfassen. Ferner können die Ausführungsformen auch als ein Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer an einen anfordernden Computer übertragen werden kann. In einigen Ausführungsformen sind auf einem nichtflüchtigen computerlesbaren Speichermedium Daten gespeichert, die Sequenzen von Anweisungen darstellen, die, wenn sie von einem Prozessor ausgeführt werden, bewirken, dass der Prozessor konkrete Operationen durchführt.
Viele der Verfahren sind in ihrer grundlegendsten Form beschrieben, es können jedoch Prozesse zu beliebigen der Verfahren hinzugefügt oder von diesen entfernt werden, und Informationen können zu beliebigen der beschriebenen Nachrichten hinzugefügt oder von diesen subtrahiert werden, ohne sich von dem grundlegenden Umfang der vorliegenden Ausführungsformen zu entfernen. Es wird für einen Fachmann offensichtlich sein, dass viele weitere Modifikationen und Anpassungen vorgenommen werden können. Die konkreten Ausführungsformen sollen das Konzept nicht einschränken, sondern es veranschaulichen. Der Umfang der Ausführungsformen ist nicht durch die zuvor bereitgestellten spezifischen Beispiele, sondern nur durch die nachstehenden Ansprüche zu bestimmen.
Wenn erwähnt wird, dass ein Element „A“ an ein oder mit einem Element „B“ gekoppelt ist, kann das Element A direkt mit dem Element B gekoppelt sein oder indirekt, zum Beispiel durch das Element C, gekoppelt sein. Wenn in der Beschreibung oder in den Ansprüchen angegeben wird, dass eine Komponente, eine Funktion, eine Struktur, ein Prozess oder ein Merkmal A eine Komponente, eine Funktion, eine Struktur, einen Prozess oder ein Merkmal B „bewirkt“, bedeutet dies, das „A“ mindestens eine Teilursache von „B“ ist, dass jedoch auch mindestens eine andere Komponente, eine andere Funktion, eine andere Struktur, ein anderer Prozess oder ein anderes Merkmal vorhanden sein kann, das bei dem Bewirken von „B“ hilft. Wenn die Beschreibung angibt, dass eine Komponente, eine Funktion, eine Struktur, ein Prozess oder ein Merkmal enthalten sein „kann“ oder „könnte“, ist es nicht notwendig, dass diese konkrete Komponente, diese konkrete Funktion, diese konkrete Struktur, dieser konkrete Prozess oder dieses konkrete Merkmal enthalten ist. Wenn sich die Beschreibung oder ein Anspruch auf „ein“ Element bezieht, bedeutet dies nicht, dass nur eines der beschriebenen Elemente vorhanden ist.
Eine Ausführungsform ist eine Implementierung oder ein Beispiel. Die Bezugnahme in der Beschreibung auf „eine Ausführungsform“, „einer Ausführungsform“, „einige Ausführungsformen“ oder „andere Ausführungsformen“ bedeutet, dass ein konkretes Merkmal, eine konkrete Struktur oder ein konkretes Element, das in Verbindung mit den Ausführungsformen beschrieben ist, in mindestens einigen Ausführungsformen, jedoch nicht notwendigerweise allen Ausführungsformen enthalten ist. Die verschiedenen Auftritte von „einer Ausführungsform“, „eine Ausführungsform“ oder „einigen Ausführungsformen“ beziehen sich nicht notwendigerweise alle auf dieselben Ausführungsformen. Es versteht sich, dass in der vorherigen Beschreibung von beispielhaften Ausführungsformen verschiedene Merkmale manchmal in einer einzigen Ausführungsform, Figur oder Beschreibung davon zusammengruppiert sind zum Zwecke der Straffung der Offenbarung und zur Hilfestellung beim Verstehen eines oder mehrerer der verschiedenen neuartigen Aspekte. Dieses Verfahren der Offenbarung soll jedoch nicht derart interpretiert werden, dass es eine Absicht widerspiegelt, dass die beanspruchten Ausführungsformen mehr Merkmale benötigen, als ausdrücklich in jedem Anspruch ausgedrückt sind. Vielmehr liegen neuartige Aspekte in weniger als allen Merkmalen einer einzelnen vorherigen offenbarten Ausführungsform, wie die folgenden Ansprüche widerspiegeln. Somit sind die Ansprüche hierbei ausdrücklich in dieser Beschreibung aufgenommen, wobei jeder Anspruch für sich selbst für eine separate Ausführungsform steht.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 15716239 [0001]

Claims

Vorrichtung, umfassend: eine Schnittstelle zum Erhalten einer Grafikkonfigurationsanforderung, wobei die Grafikkonfigurationsanforderung an ein Zielgrafikregister in einer Grafikdomäne gerichtet ist; mehrere Register zum Speichern von Daten, wobei die mehreren Register ein oder mehrere Konfigurationsregister umfassen, auf die zum Speichern der Grafikkonfigurationsanforderung zugegriffen werden kann; eine automatische Leistungsdomänenbestimmungslogik zum Kennzeichnen einer Leistungsdomäne für das Zielgrafikregister basierend auf geteilten Informationen, auf die von der automatischen Leistungsdomänenbestimmungslogik zugegriffen wird; und eine Aufweckanzeigelogik zum Bestimmen, ob sich die Leistungsdomäne für das Zielgrafikregister in einem Zustand mit verringerter Leistung befindet, und, nach dem Vornehmen der Bestimmung eines Zustands mit verringerter Leistung, zum Erzeugen einer Aufweckanzeige für die Leistungsdomäne.
Vorrichtung nach Anspruch 1, wobei die geteilten Informationen von einer Client-Tabelle mit Daten mit Ausrichtung von Adressen auf Clients und Leistungsdomänen für die Clients abgeleitet sind.
Vorrichtung nach Anspruch 2, wobei die Informationen von der Client-Tabelle mit Nachrichtenkanalroutern für einen Nachrichtenkanal für die Grafikdomäne geteilt werden.
Vorrichtung nach Anspruch 1, wobei sich die Vorrichtung innerhalb einer Schnittstellenbrücke zwischen einem Systemprozessor und der Grafikdomäne befindet.
Vorrichtung nach Anspruch 4, ferner umfassend einen Entkopplungsanforderungsprozessor zum Verarbeiten von Anforderungen einschließlich der Grafikkonfigurationsanforderung.
Vorrichtung nach Anspruch 5, wobei der Entkopplungsanforderungsprozessor einen Arbitrierer zum Auswählen und Präsentieren von Konfigurationsanforderungen bezüglich aktiver Leistungsdomänen aufweist.
Vorrichtung nach Anspruch 5, wobei der Entkopplungsanforderungsprozessor eine automatisierte Handshake-Logik zum Bereitstellen eines Handshakes mit einem Block-Controller aufweist.
Vorrichtung nach Anspruch 7, wobei der Block-Controller die Schnittstellenbrücke sperren soll, um eine Übertragung von Anforderungen zu verhindern, bevor sich eine Leistungsdomäne in einem aktiven Leistungszustand befindet, und die Schnittstellenbrücke entsperren soll, um eine Übertragung der Konfigurationsanforderung nach der Bestimmung, dass sich die gekennzeichnete Leistungsdomäne in dem aktiven Leistungszustand befindet, zu erlauben.
Vorrichtung nach Anspruch 1, wobei das eine oder die mehreren Konfigurationsregister ein oder mehrere Entkopplungsanforderungsregister umfassen.
Vorrichtung nach Anspruch 1, wobei das eine oder die mehreren Konfigurationsregister ein oder mehrere Bits aufweisen, um einen Abschlussstatus für die Konfigurationsanforderung anzugeben.
Nichtflüchtiges computerlesbares Speichermedium, auf dem Daten gespeichert sind, die Sequenzen von Anweisungen darstellen, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Operationen durchführen, die Folgendes umfassen: Erhalten einer Grafikkonfigurationsanforderung an einem oder mehreren Konfigurationsregistern einer Schnittstellenbrücke, wobei die Anforderung an ein Zielgrafikregister gerichtet ist; Kennzeichnen einer Leistungsdomäne für das Zielgrafikregister, wobei die Kennzeichnung der Leistungsdomäne zumindest teilweise auf geteilten Informationen basiert, die für Adressrouting verwaltet werden; Bestimmen, ob sich die gekennzeichnete Leistungsdomäne in einem Zustand mit verringerter Leistung befindet; nach dem Bestimmen, dass sich die gekennzeichnete Leistungsdomäne in einem Zustand mit verringerter Leistung befindet, Erzeugen einer Aufweckanzeige für die gekennzeichnete Leistungsdomäne; und Übertragen der Konfigurationsanforderung zu dem Zielgrafikregister.
Medium nach Anspruch 11, wobei das eine oder die mehreren Konfigurationsregister in einer Schnittstellenbrücke zwischen einem Prozessor und einer Grafikdomäne enthalten sind.
Medium nach Anspruch 12, wobei die Konfigurationsanforderung von einem Treiber erhalten wird, der von einem Prozessor ausgeführt wird.
Medium nach Anspruch 11, wobei die geteilten Informationen Daten mit Ausrichtung von Adressen auf Clients und Leistungsdomänen für die Clients umfassen.
Medium nach Anspruch 11, ferner umfassend Anweisungen, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Operationen durchführen, die Folgendes umfassen: Festlegen eines Abschlussstatusbits des einen oder der mehreren Konfigurationsregister nach dem Erhalten der Konfigurationsanforderung und Löschen des Abschlussstatusbits nach dem Übertragen der Konfigurationsanforderung zu dem Zielgrafikregister.
Medium nach Anspruch 11, ferner umfassend Anweisungen, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Operationen durchführen, die Folgendes umfassen: Sperren der Schnittstellenbrücke, um eine Übertragung von Anforderungen zu verhindern, bevor sich eine Leistungsdomäne in einem aktiven Leistungszustand befindet, und Entsperren der Schnittstellenbrücke, um eine Übertragung der Konfigurationsanforderung nach der Bestimmung, dass sich die gekennzeichnete Leistungsdomäne in dem aktiven Leistungszustand befindet, zu erlauben.
Medium nach Anspruch 11, wobei das eine oder die mehreren Konfigurationsregister ein oder mehrere Entkopplungsanforderungsregister umfassen.
Medium nach Anspruch 11, wobei das Übertragen der Konfigurationsanforderung zu dem Zielgrafikregister das Arbitrieren zum Auswählen und Präsentieren von Konfigurationsanforderungen bezüglich aktiver Leistungsdomänen umfasst.
System, umfassend: einen Prozessor zum Verarbeiten von Daten; eine Grafikdomäne zur Grafikoperation; einen Treiber, der von dem Prozessor ausgeführt wird, um Zielgrafikregistern in der Grafikdomäne Konfigurationsanforderungen bereitzustellen; und eine Schnittstellenbrücke zwischen dem Prozessor und der Grafikdomäne, wobei die Schnittstellenbrücke Folgendes aufweist: mehrere Konfigurationsregister, wobei die Konfigurationsregister mehrere Register zum Erhalten von Grafikkonfigurationsanforderungen umfassen, einen automatischen Leistungsdomänenmechanismus zum Kennzeichnen einer Leistungsdomäne für ein Zielgrafikregister für jede Konfigurationsanforderung, die von dem Treiber erhalten wird, um zu bestimmen, ob sich eine gekennzeichnete Leistungsdomäne in einem Zustand mit verringerter Leistung befindet, und nach dem Bestimmen, dass sich eine gekennzeichnete Leistungsdomäne in einem Zustand mit verringerter Leistung befindet, eine Aufweckanzeige für die Leistungsdomäne zu erzeugen, und einen Prozessor zum Verarbeiten von Konfigurationsanforderungen; wobei der automatische Leistungsdomänenmechanismus eine Leistungsdomäne für das Zielgrafikregister basierend auf geteilten Informationen, auf die von dem automatischen Leistungsdomänenmechanismus zugegriffen wird, kennzeichnen soll.
System nach Anspruch 19, wobei die geteilten Informationen Informationen umfassen, die von einer Client-Tabelle mit Daten mit Ausrichtung von Adressen auf Clients und Leistungsdomänen für die Clients abgeleitet sind.
System nach Anspruch 19, wobei die Schnittstellenbrücke während dem Betrieb des Systems eingeschaltet ist.
System nach Anspruch 19, wobei der Prozessor zum Verarbeiten von Konfigurationsanforderungen ein Entkopplungsanforderungsprozessor ist.
System nach Anspruch 22, wobei der Entkopplungsanforderungsprozessor einen Arbitrierer zum Auswählen und Präsentieren von Konfigurationsanforderungen bezüglich aktiver Leistungsdomänen aufweist.
System nach Anspruch 22, wobei der Entkopplungsanforderungsprozessor eine automatisierte Handshake-Logik zum Bereitstellen eines Handshakes mit einem Block-Controller aufweist, wobei der Block-Controller die Schnittstellenbrücke sperren soll, um eine Übertragung von Anforderungen zu verhindern, bevor sich eine Leistungsdomäne in einem aktiven Leistungszustand befindet, und die Schnittstellenbrücke entsperren soll, um eine Übertragung der Konfigurationsanforderung nach der Bestimmung, dass sich die gekennzeichnete Leistungsdomäne in dem aktiven Leistungszustand befindet, zu erlauben.