DE102020129625A1

DE102020129625A1 - Seitentabellen-mapping-mechanismus

Info

Publication number: DE102020129625A1
Application number: DE102020129625.8A
Authority: DE
Inventors: Ankur N. Shah; Geethacharan Rajagopalan; Ronald W. Silvas; Todd M. Witter
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-12-23
Filing date: 2020-11-10
Publication date: 2021-06-24
Also published as: JP2021099779A; CN113094300A; US20210191878A1; KR20210081232A

Abstract

Es wird eine Vorrichtung zum Ermöglichen von Seitenübersetzungen offenbart. Die Vorrichtung umfasst einen Framebuffer auf mehrere Datenseiten, mehrere Anzeigeseitentabellen zum Speichern von Übersetzungen von virtuellen Adressen in physische Adressen auf die Datenseiten im Framebuffer und eine Seitentabelle mit mehreren Seitentabelleneinträgen (PTEs), wobei jeder PTE auf eine der mehreren Anzeigeseitentabellen mappt.

Description

HINTERGRUND DER BESCHREIBUNG
Grafikverarbeitungseinheiten (Graphics Processing Units, GPUs) implementieren typischerweise Seitentabellen, die ein Array von Seitenübersetzungseinträgen (Page Translation Entries, PTEs) enthalten, die beim Mapping von logischen Grafikspeicheradressen auf physische Speicheradressen verwendet werden. Eine Seitentabelle erzeugt typischerweise einen einzigen systemweiten virtuellen Adressraum von 4 Gigabytes (GB), um Scatter-Gather-Zugriff auf Systemspeicher oder lokalen Speicher für integrierte oder diskrete Hardware bereitzustellen. Die Seitentabelle ist häufig als eine physisch zusammenhängende Tabelle mit einem Level implementiert, um die Latenz einer Tabelle mit mehreren Leveln sowie eine Anforderung, physisch zusammenhängende Seiten von einem virtuellen Maschinenüberwachungs- oder Betriebssystem zuzuweisen, zu vermeiden.
Allerdings ist die Beschränkung der Seitentabelle auf 4 GB von Nachteil, weil hohe Anzeigeauflösungen in Kombination mit zunehmender Verwendung von Anzeige-Hardware für Fensterkomposition einen außerordentlichen Bedarf an Adressierbarkeit von Anzeigespeichern erzeugt haben. Außerdem sind Betriebssysteme und Anwendungen durch den installierten Speicher begrenzt, daher wird keine feste Grenze für anzeigbare Zuweisungen erwartet. Das Erhöhen der Größe der Seitentabelle ist keine skalierbare Lösung und würde sich auf derzeitige Anzeige-Hardware-Implementierungen auswirken.
Figurenliste
Damit die Art und Weise, in der die oben aufgeführten Merkmale der vorliegenden Erfindung umgesetzt werden, im Detail verstanden werden kann, kann eine eingehendere Beschreibung der Erfindung, die oben kurz zusammengefasst wird, durch Bezugnahme auf Ausführungsformen erlangt werden, von denen einige in den beigefügten Zeichnungen dargestellt sind. Es ist allerdings anzumerken, dass die beigefügten Zeichnungen lediglich typische Ausführungsformen dieser Erfindung veranschaulichen und daher nicht so aufzufassen sind, dass sie ihren Schutzbereich einschränken, weil die Erfindung möglicherweise andere, gleichermaßen wirksame Ausführungsformen zulässt.

Die 1 ist ein Blockdiagramm eines Verarbeitungssystems gemäß einer Ausführungsform;
die 2A - 2D veranschaulichen Rechensysteme und Grafikprozessoren, die durch hier beschriebene Ausführungsformen bereitgestellt werden;
die 3A - 3C veranschaulichen Blockdiagramme von zusätzlichen Grafikprozessor- und Rechenbeschleuniger-Architekturen, die durch Ausführungsformen bereitgestellt werden;
die 4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine eines Grafikprozessors gemäß einigen Ausführungsformen;
die 5A - 5B veranschaulichen Thread-Ausführungslogik 500, die ein Array von Verarbeitungselementen enthält, die in einem Grafikprozessorkern eingesetzt werden, gemäß Ausführungsformen;
die 6 veranschaulicht eine zusätzliche Ausführungseinheit 600 gemäß einer Ausführungsform;
die 7 ist ein Blockdiagramm, das ein Grafikprozessor-Anweisungsformat gemäß einigen Ausführungsformen veranschaulicht;
die 8 ist ein Blockdiagramm eines Grafikprozessors gemäß einer anderen Ausführungsform;
die 9A & 9B veranschaulichen ein Grafikprozessor-Befehlsformat und -Befehlssequenz gemäß einigen Ausführungsformen;
die 10 veranschaulicht eine beispielhafte Grafik-Software-Architektur für ein Datenverarbeitungssystem gemäß einigen Ausführungsformen;
die 11A - 11D veranschaulichen eine integrierte Schaltungs-Package-Baugruppe gemäß einer Ausführungsform;
die 12 ist ein Blockdiagramm einer beispielhaften integrierten System-on-Chip-Schaltung gemäß einer Ausführungsform;
die 13A & 13B sind ein Blockschaltbild, das einen zusätzlichen Grafikprozessor veranschaulicht;
die 14 veranschaulicht eine Ausführungsform einer Recheneinrichtung, die einen Seitentabellen-Mapping-Mechanismus einsetzt;
die 15 veranschaulicht ein konventionelles Framebuffer-Mapping;
die 16 veranschaulicht eine andere Ausführungsform einer Grafikverarbeitungseinheit;
die 17 veranschaulicht eine Ausführungsform eines Mechanismus zum Durchführen von Framebuffer-Mapping;
die 18A veranschaulicht eine andere Ausführungsform eines Mechanismus zum Durchführen von Framebuffer-Mapping;
die 18B veranschaulicht eine Ausführungsform eines Framebuffers; und
die 19 ist ein Flussdiagramm, das eine Ausführungsform eines Prozesses zum Durchführen der Übersetzung von virtuellen Adressen in physische Adressen über Framebuffer-Mapping veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein gründlicheres Verständnis der vorliegenden Erfindung bereitzustellen. Allerdings wird für einen Fachmann offensichtlich sein, dass die vorliegende Erfindung ohne eines oder mehrere dieser spezifischen Details umgesetzt werden kann. In anderen Beispielen sind allgemein bekannte Merkmale nicht beschrieben worden, um zu vermeiden, die vorliegende Erfindung unverständlich zu machen.
In den Ausführungsformen ist ein Seiten-Mapping-Mechanismus zum Durchführen von Mapping von Seitentabellen auf Framebuffer implementiert, um einen Zwei-Level-Seitentabellen-Walk bereitzustellen, in dem jeder Seitentabelleneintrag auf eine Anzeigeseitentabellen (Display Page Table, DPT)-Seite mappt und ein Walk auf dem zweiten Level der DPT auf physische Framebuffer-Seiten zeigt.
Systemüberblick
Die 1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. Das System 100 kann in einem Ein-Prozessor-Desktopsystem, einem Multiprozessor-Workstationsystem oder einem Server-System mit einer großen Anzahl an Prozessoren 102 oder Prozessorkernen 107 verwendet werden. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in einer integrierten System-on-Chip (SoC)-Schaltung zur Verwendung in einem Mobiltelefon, einem Handgerät oder eingebetteten Einrichtungen, wie zum Beispiel in Internet of Things (IoT)-Einrichtungen, mit drahtgebundener oder drahtloser Konnektivität zu einem Lokal- oder Weitverkehrsnetz eingebunden ist.
In einer Ausführungsform kann das System 100 Folgendes enthalten, mit Folgendem koppeln oder in Folgendem integriert sein: einer Gaming-Plattform auf Server-Basis; einer Spielekonsole, einschließlich einer Spiel- und Medienkonsole; einer mobilen Gaming-Konsole, einer handgeführten Spielekonsole oder einer Online-Spielekonsole. In einigen Ausführungsformen ist das System 100 Teil eines Mobiltelefons, eines Smartphones, einer Tablet-Recheneinrichtung oder einer mobilen, mit dem Internet verbundenen Einrichtung, wie zum Beispiel einem Laptop mit geringer interner Speicherkapazität. Das Verarbeitungssystem 100 kann ebenfalls Folgendes enthalten, mit Folgendem koppeln oder in Folgendem integriert sein: eine Wearable-Einrichtung, wie zum Beispiel eine Smart-Watch-Wearable-Einrichtung; intelligente Brillen oder Bekleidung, die mit Augmented Reality (AR) oder Virtual Reality (VR)-Merkmalen erweitert sind, um visuelle, Audio- oder taktile Ausgaben bereitzustellen, um reale visuelle, Audio- oder taktile Erlebnisse zu ergänzen oder anders Text, Audio, Grafiken, Video, holografische Bilder oder Video oder taktile Rückmeldung bereitzustellen; eine andere Augmented Reality (AR)-Einrichtung; oder eine andere Virtual Reality (VR)-Einrichtung. In einigen Ausführungsformen enthält das Verarbeitungssystem 100 eine Fernseh- oder Set-Top-Box-Einrichtung oder ist Teil davon. In einer Ausführungsform kann das System 100 ein selbstfahrendes Fahrzeug, wie zum Beispiel einen Bus, Sattelzugmaschine, Auto, Motorrad oder Elektrofahrrad, Flugzeug oder Segelflugzeug (oder irgendeine Kombination daraus) enthalten, damit koppeln oder darin integriert sein. Das selbstfahrende Fahrzeug kann das System 100 verwenden, um die um das Fahrzeug erfasste Umgebung zu verarbeiten.
In einigen Ausführungsformen enthalten der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 zum Verarbeiten von Anweisungen, die, wenn sie ausgeführt werden, Operationen für System- oder Anwender-Software durchführen. In einigen Ausführungsformen ist wenigstens einer von dem einen oder den mehreren Prozessorkernen 107 dazu ausgebildet, einen spezifischen Anweisungssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Anweisungssatz 109 Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC) oder Rechnen über ein Very Long Instruction Word (VLIW) ermöglichen. Einer oder mehrere Prozessorkerne 107 können einen anderen Anweisungssatz 109 verarbeiten, der Anweisungen enthalten kann, um die Emulation anderer Anweisungssätze zu ermöglichen. Der Prozessorkern 107 kann auch andere Verarbeitungseinrichtungen enthalten, wie zum Beispiel einem Digital-Signal-Prozessor (DSP).
In einigen Ausführungsformen enthält der Prozessor 102 den Cache-Speicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Level internen Cache aufweisen. In einigen Ausführungsformen wird der Cache-Speicher von verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z. B. einen Level-3 (L3)-Cache oder Last-Level-Cache (LLC)) (nicht dargestellt), die von den Prozessorkernen 107 unter Verwendung bekannter Cache-Kohärenztechniken gemeinsam genutzt werden können. Eine Registerdatei 106 kann zusätzlich im Prozessor 102 enthalten sein und kann unterschiedliche Registertypen zum Speichern von unterschiedlichen Datentypen enthalten (z. B. Integer-Register, Gleitkommaregister, Zustandsregister und ein Anweisungszeigerregister). Einige Register können universelle Register sein, während andere Register für das Design des Prozessors 102 spezifisch sein können.
In einigen Ausführungsformen sind einer oder mehrere Prozessor(en) 102 mit einem oder mehreren Schnittstellenbus(sen) 110 gekoppelt, um Kommunikationssignale, wie zum Beispiel Adressen, Daten oder Steuersignale, zwischen dem Prozessor 102 und anderen Komponenten im System 100 zu übertragen. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus sein, wie zum Beispiel eine Version eines Direct Media Interface (DMI)-Busses. Allerdings sind die Prozessorbusse nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral Component Interconnect-Busse (z. B. PCI, PCI Express), Speicherbusse oder andere Typen von Schnittstellenbussen enthalten. In einer Ausführungsform enthält/enthalten der/die Prozessor(en) 102 einen integrierten Speicher-Controller 116 und einen Plattform-Controller-Hub 130. Der Speicher-Controller 116 ermöglicht Kommunikation zwischen einer Speichereinrichtung und anderen Komponenten des Systems 100, während der Plattform-Controller-Hub (PCH) 130 Verbindungen zu E/A-Einrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Speichereinrichtung 120 kann eine dynamische Direktzugriffsspeicher (Dynamic Random Access Memory, DRAM)-Einrichtung, eine statische Direktzugriffsspeicher (Static Random Access Memory, SRAM)-Einrichtung, eine Flash-Speichereinrichtung, eine Phasenwechselspeicher-Einrichtung oder irgendeine andere Speichereinrichtung sein, die geeignete Performance, um als Prozessspeicher zu dienen, aufweist. In einer Ausführungsform kann die Speichereinrichtung 120 als ein Systemspeicher für das System 100 arbeiten, um Daten 122 und Anweisungen 121 zur Verwendung zu speichern, wenn der eine oder die mehreren Prozessoren 102 eine Anweisung oder einen Prozess ausführen. Der Speicher-Controller 116 koppelt auch mit einem optionalen externen Grafikprozessor 118, der mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen können Grafik-, Medien- und/oder Rechenoperationen durch einen Beschleuniger 112 unterstützt werden, der ein Coprozessor ist, der dazu ausgebildet sein kann, einen spezialisierten Satz Grafik-, Medien- oder Rechenoperationen durchzuführen. Zum Beispiel ist der Beschleuniger 112 in einer Ausführungsform ein Matrizenmultiplikations-Beschleuniger, der verwendet wird, um maschinelles Lernen oder Rechenoperationen zu optimieren. In einer Ausführungsform ist der Beschleuniger 112 ein Strahlverfolgungsbeschleuniger, der verwendet werden kann, um Strahlverfolgungsoperationen zusammen mit dem Grafikprozessor 108 durchzuführen. In einer Ausführungsform kann ein externer Beschleuniger 119 anstelle des oder zusammen mit dem Beschleuniger 112 verwendet werden.
In einigen Ausführungsformen kann eine Anzeigeeinrichtung 111 mit dem/den Prozessor(en) 102 verbinden. Die Anzeigeeinrichtung 111 kann eine oder mehrere von einer internen Anzeigeeinrichtung, wie in einer mobilen elektronischen Einrichtung oder einer Laptop-Einrichtung oder einer externen Anzeigeeinrichtung sein, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angeschlossen sind. In einer Ausführungsform kann die Anzeigeeinrichtung 111 ein Head-Mounted Display (HMD), wie zum Beispiel eine stereoskopische Anzeige, zur Verwendung in Virtual Reality (VR)-Anwendungen oder Augmented Reality (AR)-Anwendungen sein.
In einigen Ausführungsformen ermöglicht der Plattform-Controller-Hub 130, Peripheriegeräte mit der Speichereinrichtung 120 und dem Prozessor 102 über einen Hochgeschwindigkeits-E/A-Bus zu verbinden. Zu den E/A-Peripheriegeräten zählen, ohne darauf beschränkt zu sein, ein Audio-Controller 146, ein Netzwerk-Controller 134, eine Firmware-Schnittstelle 128, ein drahtloser Transceiver 126, Berührungssensoren 125, eine Datenspeichereinrichtung 124 (z. B. nichtflüchtiger Speicher, flüchtiger Speicher, Festplattenlaufwerk, Flash-Speicher, NAND, 3D-NAND, 3D-XPoint usw.). Die Datenspeichereinrichtung 124 kann über eine Speicherschnittstelle (z. B. SATA) oder über einen Peripheriegerätebus, wie zum Beispiel einen Peripheral Component Interconnect Bus (z. B. PCI, PCI Express) verbinden. Zu den Berührungssensoren 125 können Touch-Screen-Sensoren, Drucksensoren oder Fingerabdrucksensoren zählen. Der drahtlose Transceiver 126 kann ein Wi-Fi-Transceiver, ein Bluetooth-Transceiver oder ein mobiler Netzwerk-Transceiver, wie zum Beispiel ein 3G-, 4G-, 5G- oder Long-Term Evolution (LTE)-Transceiver, sein. Die Firmware-Schnittstelle 128 ermöglicht Kommunikation mit System-Firmware und kann zum Beispiel eine Unified Extensible Firmware Interface (UEFI) sein. Der Netzwerk-Controller 134 kann eine Netzwerkverbindung zu einem drahtgebundenen Netzwerk ermöglichen. In einigen Ausführungsformen koppelt ein Hochleistungs-Netzwerk-Controller (nicht dargestellt) mit dem Schnittstellenbus 110. Der Audio-Controller 146 ist in einer Ausführungsform ein Mehrkanal-High-Definition-Audio-Controller. In einer Ausführungsform enthält das System 100 einen optionalen Legacy-E/A-Controller 140 zum Koppeln von Legacy (z. B. Personal System 2 (PS/2))-Einrichtungen mit dem System. Der Plattform-Controller-Hub 130 kann auch mit einer oder mehreren Verbindungseingabeeinrichtungen zu Universal Serial Bus (USB)-Controllern 142, wie zum Beispiel zu Kombinationen von Tastatur und Maus 143, einer Kamera 144 oder anderen USB-Eingabeeinrichtungen, verbinden.
Es versteht sich, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, weil auch andere Typen von Datenverarbeitungssystemen, die anders ausgebildet sind, verwendet werden können. Zum Beispiel kann eine Instanz des Speicher-Controllers 116 und des Plattform-Controller-Hubs 130 in einem diskreten externen Grafikprozessor, wie zum Beispiel dem externen Grafikprozessor 118, integriert sein. In einer Ausführungsform können der Plattform-Controller-Hub 130 und/oder der Speicher-Controller 116 extern zu dem einen oder den mehreren Prozessor(en) 102 sein. Zum Beispiel kann das System 100 einen externen Speicher-Controller 116 und einen Plattform-Controller-Hub 130 enthalten, die als ein Speicher-Controller-Hub und ein Peripheriegeräte-Controller-Hub in einem System-Chipsatz, der in Kommunikation mit dem/den Prozessor(en) 102 steht, ausgebildet sein können.
Zum Beispiel können Leiterplatten („Schlitten“) verwendet werden, auf denen Komponenten, wie zum Beispiel CPUs, Speicher und andere Komponenten platziert sind, die für verbesserte thermische Performance entworfen sind. In einigen Beispielen befinden sich Verarbeitungskomponenten, wie zum Beispiel die Prozessoren, auf einer Oberseite eines Schlittens, während sich nahegelegene Speicher, wie zum Beispiel DIMMs, auf einer Unterseite des Schlittens befinden. Als ein Ergebnis des durch dieses Design bereitgestellten verbesserten Luftstroms können die Komponenten bei höheren Frequenzen und Leistungspegeln arbeiten als in typischen Systemen, wodurch sich die Performance verbessert. Des Weiteren sind die Schlitten zum verdeckten Ineinandergreifen mit Leistungs- und Datenkommunikationskabeln in einem Rack ausgebildet, wodurch ihre Eignung zum schnellen Entfernen, Nachrüsten, Neuinstallieren und/oder Ersetzen verbessert wird. Gleichermaßen sind einzelne Komponenten, die sich auf den Schlitten befinden, wie zum Beispiel Prozessoren, Beschleuniger, Speicher und Datenspeicherlaufwerke, so ausgebildet, dass sie wegen ihres vergrößerten Abstands voneinander einfach nachgerüstet werden können. In der veranschaulichenden Ausführungsform enthalten die Komponenten zusätzlich Hardware-Testierungsmerkmale, um ihre Authentizität zu belegen.
Ein Datenzentrum kann eine einzelne Netzwerkarchitektur („Struktur“) nutzen, die mehrere andere Netzwerkarchitekturen, einschließlich Ethernet und Omni-Path, unterstützt. Die Schlitten können mit Switches über Lichtwellenleiter gekoppelt sein, die höhere Bandbreite und geringere Latenz als typische verdrillte Doppelleitungsverkabelung bereitstellen (z. B. Category 5, Category 5e, Category 6 usw.). Aufgrund der hohen Bandbreite, der Verschaltungen mit geringer Latenz und der Netzwerkarchitektur kann das Datenzentrum im Einsatz Ressourcen, wie zum Beispiel Speicher, Beschleuniger (z. B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, Neuronalnetzbeschleuniger und/oder Beschleuniger für künstliche Intelligenz usw.) und Datenspeicherlaufwerke, die physisch getrennt sind, zusammenschließen und sie für Rechenressourcen (z. B. Prozessoren) auf einer bedarfsgerechten Basis bereitstellen, was den Rechenressourcen ermöglicht, auf die zusammengeschlossenen Ressourcen zuzugreifen, als ob sie lokal wären.
Eine Leistungsversorgung oder -quelle kann dem System 100 oder irgendeiner hier beschriebenen Komponente oder System Spannung und/oder Strom bereitstellen. In einem Beispiel enthält die Leistungsversorgung ein AC-DC (Wechselstrom zu Gleichstrom)-Anschlusselement zum Einstecken in eine Wandsteckdose. Solche Wechselstromleistung kann eine Leistungsquelle aus erneuerbarer Energie sein (z. B. Solarenergie). In einem Beispiel enthält die Leistungsquelle eine Gleichstrom-Leistungsquelle, wie zum Beispiel einen externen Wechselstrom-Gleichstrom-Wandler. In einem Beispiel enthält die Leistungsquelle oder die Leistungsversorgung drahtlose Lade-Hardware, um über die Nähe zu einem Aufladefeld zu laden. In einem Beispiel kann zur Leistungsquelle eine interne Batterie, eine Wechselstromversorgung, eine bewegungsbasierte Leistungsversorgung, eine Solarleistungsversorgung oder eine Brennstoffzellenquelle zählen.
Die 2A - 2D veranschaulichen Rechensysteme und Grafikprozessoren, die durch hier beschriebene Ausführungsformen bereitgestellt werden. Die Elemente der 2A - 2D, die die gleichen Bezugsnummern (oder Bezeichnungen) wie hier die Elemente irgendeiner anderen Figur aufweisen, können auf irgendeine Art und Weise, die der hier an anderer Stelle beschriebenen ähnelt, arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt.
Die 2A ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200, der einen oder mehrere Prozessorkerne 202A - 202N, einen integrierten Speicher-Controller 214 und einen integrierten Grafikprozessor 208 aufweist. Der Prozessor 200 kann zusätzliche Kerne bis zu einem zusätzlichen Kern 202N und diesen einschließlich enthalten, was durch die gestrichelt gezeichneten Kästen dargestellt ist. Jeder der Prozessorkerne 202A - 202N enthält eine oder mehrere interne Cache-Einheiten 204A - 204N. In einigen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf eine oder mehrere gemeinsam genutzte Cache-Einheiten 206. Die internen Cache-Einheiten 204A - 204N und die gemeinsam genutzten Cache-Einheiten 206 stellen eine Cache-Speicherhierarchie im Prozessor 200 dar. Die Cache-Speicherhierarchie kann wenigstens ein Level von Anweisungs- und Daten-Cache in jedem Prozessorkern und eines oder mehrere Level von gemeinsam genutztem Cache des mittleren Levels, wie zum Beispiel Level 2 (L2), Level 3 (L3), Level 4 (L4), oder andere Cache-Level enthalten, wobei der höchste Cache-Level vor externem Speicher als der LLC klassifiziert wird. In einigen Ausführungsformen erhält Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A - 204N aufrecht.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz aus einer oder mehreren Bus-Controller-Einheiten 216 und einem Systemagentenkern 210 enthalten. Die eine oder die mehreren Bus-Controller-Einheiten 216 managen einen Satz Peripheriegerätebusse, wie zum Beispiel einen oder mehrere PCI- oder PCI Express-Busse. Der Systemagentenkern 210 stellt Managementfunktionalität für die verschiedenen Prozessorkomponenten bereit. In einigen Ausführungsformen enthält der Systemagentenkern 210 einen oder mehrere integrierte Speicher-Controller 214, um den Zugriff auf verschiedene externe Speichereinrichtungen (nicht dargestellt) zu managen.
In einigen Ausführungsformen unterstützen einer oder mehrere der Prozessorkerne 202A - 202N simultanes Multithreading. In einer solchen Ausführungsformen enthält der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A - 202N während der Multi-Thread-Verarbeitung. Der Systemagentenkern 210 kann zusätzlich eine Leistungssteuereinheit (Power Control Unit, PCU) enthalten, die Logik und Komponenten zum Regeln des Leistungszustands der Prozessorkerne 202A - 202N und des Grafikprozessors 208 enthält.
In einigen Ausführungsformen enthält der Prozessor 200 zusätzlich den Grafikprozessor 208, um Grafikverarbeitungsoperationen auszuführen. In einigen Ausführungsformen koppelt der Grafikprozessor 208 mit dem Satz gemeinsam genutzter Cache-Einheiten 206 und dem Systemagentenkern 210 einschließlich des einen oder der mehreren Speicher-Controller 214. In einigen Ausführungsformen enthält der Systemagentenkern 210 auch einen Anzeige-Controller 211, um die Grafikprozessorausgabe an eine oder mehrere gekoppelte Anzeigen anzusteuern. In einigen Ausführungsformen kann der Anzeige-Controller 211 auch ein separates Modul sein, das mit dem Grafikprozessor über wenigstens eine Verschaltung gekoppelt ist oder das im Grafikprozessor 208 integriert sein kann.
In einigen Ausführungsformen wird eine Verschaltungseinheit 212 auf Ringbasis verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Allerdings kann eine alternative Verschaltungseinheit verwendet werden, wie zum Beispiel eine Punkt-zu-Punkt-Verschaltung, eine geschaltete Verschaltung oder andere Techniken, einschließlich im Fachbereich allgemein bekannter Techniken. In einigen Ausführungsformen koppelt der Grafikprozessor 208 mit der Ringverschaltung 212 über eine E/A-Verknüpfung 213.
Die beispielhafte E/A-Verknüpfung 213 stellt wenigstens eine von vielen Varianten von E/A-Verschaltungen dar, einschließlich einer On-Package-E/A-Verschaltung, die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungs-Speichermodul 218 ermöglicht, wie zum Beispiel einem eDRAM-Modul. In einigen Ausführungsformen können jeder der Prozessorkerne 202A - 202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als einen gemeinsam genutzten Last Level Cache verwenden.
In einigen Ausführungsformen sind die Prozessorkerne 202A - 202N homogene Kerne, die die gleiche Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A - 202N heterogen hinsichtlich der Anweisungssatzarchitektur (Instruction Set Architecture, ISA), wobei einer oder mehrere Prozessorkerne 202A - 202N einen ersten Anweisungssatz ausführen, während wenigstens einer der anderen Kerne einen Subsatz des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A - 202N heterogen hinsichtlich der Mikroarchitektur, wobei einer oder mehrere Kerne mit einer relativ höheren Leistungsaufnahme mit einem oder mehreren Leistungskernen mit einer geringeren Leistungsaufnahme gekoppelt sind. In einer Ausführungsform sind die Prozessorkerne 202A - 202N heterogen hinsichtlich der Rechenfähigkeit. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte SoC-Schaltung mit den veranschaulichten Komponenten, zusätzlich zu anderen Komponenten, implementiert sein.
Die 2B ist ein Blockdiagramm einer Hardware-Logik eines Grafikprozessorkerns 219 gemäß einigen hier beschriebenen Ausführungsformen. Elemente der 2B, die die gleichen Bezugsnummern (oder -bezeichnungen) wie die Elemente irgendeiner anderen Figur hier aufweisen, können auf irgendeine ähnliche Weise, wie die hier an anderer Stelle beschriebene arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Der Grafikprozessorkern 219, manchmal auch als ein Kern-Slice bezeichnet, kann einer oder mehrere Grafikkerne in einem modularen Grafikprozessor sein. Der Grafikprozessorkern 219 ist beispielhaft für einen Grafikkern-Slice, und ein Grafikprozessor, wie er hier beschrieben wird, kann mehrere Grafikkern-Slices, basierend auf Zielleistungs- und Performance-Umfängen enthalten. Jeder Grafikprozessorkern 219 kann einen Festfunktionsblock 230 enthalten, der mit mehreren Subkernen 221A - 221F gekoppelt ist, auch bezeichnet als Sub-Slices, die modulare Blöcke aus Universal- und Festfunktions-Logik enthalten.
In einigen Ausführungsformen enthält der Festfunktionsblock 230 eine Geometrie-/Festfunktions-Pipeline 231, die von allen Subkernen im Grafikprozessorkern 219 gemeinsam genutzt werden kann, zum Beispiel bei Grafikprozessorimplementierungen mit geringerer Performance und/oder mit geringerer Leistung. In verschiedenen Ausführungsformen enthält die Geometrie-/Festfunktions-Pipeline 231 eine Festfunktions-3D-Pipeline (z. B. die 3D-Pipeline 312 wie in der 3 und der 4, die nachstehend beschrieben werden), eine Video-Front-End-Einheit, einen Thread-Spawner und Thread-Dispatcher und einen Einheits-Rückgabepuffer-Manager, der Einheits-Rückgabepuffer managt (z. B. Einheits-Rückgabepuffer 418 in der 4, wie nachstehend beschrieben wird).
In einer Ausführungsform enthält der Festfunktionsblock 230 auch eine SoC-Grafikschnittstelle 232, einen Grafik-Mikrocontroller 233 und eine Medien-Pipeline 234. Die SoC-Grafikschnittstelle 232 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 219 und anderen Prozessorkernen in einer integrierten System-on-Chip-Schaltung bereit. Der Grafik-Mikrocontroller 233 ist ein programmierbarer Subprozessor, der dazu konfigurierbar ist, verschiedene Funktionen des Grafikprozessorkerns 219 zu managen, einschließlich der Thread-Verteilung, dem Scheduling und der Präemption. Die Medien-Pipeline 234 (z. B. die Medien-Pipeline 316 der 3 und der 4) enthält Logik, um das Decodieren, Codieren, Vorverarbeiten und/oder Nachbearbeiten von Multimediadaten, einschließlich Bild- und Videodaten, zu ermöglichen. Die Medien-Pipeline 234 implementiert Medienoperationen über Anforderungen an Rechen- oder Abtastlogik in den Subkernen 221 - 221F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232, dass der Grafikprozessor 219 mit universellen Anwendungs-Prozessorkernen (z. B. CPUs) und/oder anderen Komponenten in einem SoC, einschließlich Speicherhierarchieelementen, wie zum Beispiel einem gemeinsam genutzten Last Level Cache-Speicher, dem System-RAM und/oder dem eingebetteten On-Chip- oder On-Package-DRAM kommuniziert. Die SoC-Schnittstelle 232 kann auch Kommunikation mit Festfunktionseinrichtungen im SoC ermöglichen, wie zum Beispiel Kamerabildgebungs-Pipelines, und ermöglicht die Verwendung von globalen Speicheratomen, die vom Grafikprozessorkern 219 und den CPUs im SoC gemeinsam genutzt werden können, und/oder implementiert diese. Die SoC-Schnittstelle 232 kann auch Leistungsmanagementsteuerung für den Grafikprozessorkern 219 implementieren und eine Schnittstelle zwischen einer Taktsignaldomäne des Grafikkerns 219 und anderen Taktsignaldomänen im SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 Befehlspuffern den Empfang aus einem Befehls-Streamer und globalen Thread-Dispatcher, die dazu ausgebildet sind, Befehle und Anweisungen für jeden von einem oder mehreren Grafikkernen in einem Grafikprozessor bereitzustellen. Die Befehle und Anweisungen können an die Medien-Pipeline 234 verteilt werden, wenn Medienoperationen durchzuführen sind, oder eine Geometrie- und Festfunktions-Pipeline (z. B. die Geometrie- und Festfunktions-Pipeline 231, die Geometrie- und Festfunktions-Pipeline 237), wenn Grafikverarbeitungsoperationen durchzuführen sind.
Der Grafik-Mikrocontroller 233 kann dazu ausgebildet sein, verschiedene Scheduling- und Managementaufgaben für den Grafikprozessorkern 219 durchzuführen. In einer Ausführungsform kann der Grafik-Mikrocontroller 233 Grafik- und/oder Rechen-Arbeits-Scheduling auf den verschiedenen parallelen Grafik-Engines in den Ausführungseinheiten (EU)-Arrays 222A - 222F, 224A - 224F in den Subkernen 221A - 221F durchführen. In diesem Scheduling-Modell kann Host-Software, die auf einem CPU-Kern eines SoC, einschließlich des Grafikprozessorkerns 219, ausgeführt wird, Arbeiten über eine von mehreren Grafikprozessor-Türklingeln abgeben, was eine Scheduling-Operation auf der geeigneten Grafik-Engine aufruft. Scheduling-Operationen beinhalten das Bestimmen, welche Arbeit als Nächstes durchzuführen ist, das Abgeben einer Arbeit an einen Befehls-Streamer, die Präemption bereits vorhandener, auf einer Engine laufender Arbeiten, Überwachen des Fortschritts einer Arbeit und Melden an eine Host-Software, wenn eine Arbeit abgeschlossen ist. In einer Ausführungsform kann der Grafik-Mikrocontroller 233 auch Niedrigleistungs- oder Bereitschaftszustände für den Grafikprozessorkern 219 ermöglichen, was dem Grafikprozessorkern 219 die Fähigkeit bereitstellt, Register im Grafikprozessorkern 219 über Niedrigleistungszustandsübergänge einzusparen und wiederherzustellen, unabhängig vom Betriebssystem und/oder der Grafiktreiber-Software auf dem System.
Der Grafikprozessorkern 219 kann mehr oder weniger als die veranschaulichten Subkerne 221A - 221F aufweisen, bis zu N modulare Subkerne. Für jeden Satz aus N Subkernen kann der Grafikprozessorkern 219 auch gemeinsam genutzte Funktionslogik 235, gemeinsam genutzten und/oder Cache-Speicher 236, eine Geometrie-/Festfunktions-Pipeline 237 sowie zusätzliche Festfunktionslogik 238 zum Beschleunigen verschiedener Grafik- und Rechenverarbeitungsoperationen enthalten. Die gemeinsam genutzte Funktionslogik 235 kann Logikeinheiten enthalten, die mit der gemeinsam genutzten Funktionslogik 420 der 4 verknüpft sind (z. B. Sampler-, Mathematik- und/oder Inter-Thread-Kommunikationslogik), die von allen N Subkernen im Grafikprozessorkern 219 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 236 kann ein Last Level Cache für den Satz aus N Subkernen 221A - 221F im Grafikprozessorkern 219 sein und kann auch als gemeinsam genutzter Speicher dienen, der durch mehrere Subkerne zugriffsfähig ist. Die Geometrie-/Festfunktions-Pipeline 237 kann anstelle der Geometrie-/Festfunktions-Pipeline 231 im Festfunktionsblock 230 enthalten sein und kann die gleichen oder ähnliche Logikeinheiten enthalten.
In einer Ausführungsform enthält der Grafikprozessorkern 219 zusätzliche Festfunktionslogik 238, die verschiedene Festfunktions-Beschleunigungslogik zur Verwendung durch den Grafikprozessorkern 219 enthalten kann. In einer Ausführungsform enthält die zusätzliche Festfunktionslogik 238 eine zusätzliche Geometrie-Pipeline zur Verwendung beim Nur-Positions-Shading. Beim Nur-Positions-Shading sind zwei Geometrie-Pipelines vorhanden, die vollständige Geometrie-Pipeline in der Geometrie-/Festfunktions-Pipeline 238, 231 und eine Cull-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Festfunktionslogik 238 enthalten sein kann. In einer Ausführungsform ist die Cull-Pipeline eine reduzierte Version der vollständigen Geometrie-Pipeline. Die vollständige Pipeline und die Cull-Pipeline können unterschiedliche Instanzen der gleichen Anwendung ausführen, wobei jede Instanz einen anderen Kontext aufweist. Nur-Positions-Shading kann lange Cull-Durchläufe von verworfenen Dreiecken verbergen, was ermöglicht, dass in einigen Instanzen das Shading früher abgeschlossen wird. Zum Beispiel und in einer Ausführungsform kann die Cull-Pipeline-Logik in der zusätzlichen Festfunktionslogik 238 Position-Shader parallel zur Hauptanwendung ausführen und generiert im Allgemeinen kritische Ergebnisse schneller als die vollständige Pipeline, weil die Cull-Pipeline nur die Positionsattribute der Eckpunkte abruft und shadet, ohne Rasterisierung und Rendering der Pixel zum Framebuffer durchzuführen. Die Cull-Pipeline kann die generierten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle die Dreiecke zu berechnen, ungeachtet, ob diese Dreiecke gecullt worden sind. Die vollständige Pipeline (die in dieser Instanz als eine Wiedergabe-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen aufnehmen, um die gecullten Dreiecke zu überspringen, um nur die sichtbaren Dreiecke zu shaden, die schließlich an die Rasterisierungsphase übermittelt werden.
In einer Ausführungsform kann die zusätzliche Festfunktionslogik 238 auch Beschleunigungslogik für maschinelles Lernen, wie zum Beispiel Festfunktions-Matrizenmultiplikationslogik, für Implementierungen enthalten, die Optimierungen für Training und Inferenzieren von maschinellem Lernen enthalten.
Jeder Grafiksubkern 221A - 221F enthält ein Satz Ausführungsressourcen, die verwendet werden können, um Grafik-, Medien- oder Rechenoperationen als Reaktion auf Anforderungen von der Grafik-Pipeline, der Medien-Pipeline oder von Shader-Programmen durchzuführen. Die Grafiksubkerne 221A - 221F enthalten mehrere EU-Arrays 222A - 222F, 224A - 224F, Thread-Verteilungs- und Inter-Thread-Kommunikations (TD/IC)-Logik 223A - 223F, einen 3D (z. B. Textur)-Sampler 225A - 225F, einen Medien-Sampler 206A - 206F, einen Shader-Prozessor 227A - 227F und gemeinsam genutzten lokalen Speicher (SLM) 228A - 228F. Die EU-Arrays 222A - 222F, 224A - 224F enthalten jeweils mehrere Ausführungseinheiten, die universelle Grafikverarbeitungseinheiten sind, die in der Lage sind, Gleitkomma- und Integer-/Festkomma-Logikoperationen im Dienst einer Grafik-, Medien- oder Rechenoperation durchzuführen, einschließlich Grafik-, Medien- oder Compute-Shader-Programmen. Die TD/IC-Logik 223A - 223F führt lokale Thread-Verteilungs- und Thread-Steueroperationen für die Ausführungseinheiten in einem Subkern durch und ermöglicht Kommunikation zwischen Threads, indem sie auf den Ausführungseinheiten des Subkerns ausgeführt wird. Der 3D-Sampler 225A - 225F kann Textur- oder andere Daten, die zu 3D-Grafiken in Beziehung stehen, in Speicher einlesen. Der 3D-Sampler kann Texturdaten unterschiedlich lesen, basierend auf einem konfigurierten Abtastzustand und dem Texturformat, das mit einer gegebenen Textur verknüpft ist. Der Medien-Sampler 206A - 206F kann ähnliche Leseoperationen basierend auf dem mit Mediendaten verknüpften Typ und Format durchführen. In einer Ausführungsform kann jeder Grafiksubkern 221A - 221F wechselweise einen Einheits-3D- und einen Medien-Sampler enthalten. Threads, die auf Ausführungseinheiten in jedem der Subkerne 221A - 221F ausgeführt werden, können gemeinsam genutzten lokalen Speicher 228A - 228F in jedem Subkern verwenden, um zu ermöglichen, dass Threads, die in einer Thread-Gruppe ausgeführt werden, unter Verwendung eines gemeinsamen Pools von On-Chip-Speicher ausgeführt werden.
Die 2C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 239, die dedizierte Sätze von Grafikverarbeitungsressourcen enthält, die in Mehrkerngruppen 240A - 240N angeordnet sind. Obwohl nur die Details einer einzigen Mehrkerngruppe 240A bereitgestellt werden, versteht es sich, dass die anderen Mehrkerngruppen 240B - 240N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können.
Wie veranschaulicht wird, kann eine Mehrkerngruppe 240A einen Satz Grafikkerne 243, einen Satz Tensorkerne 244 und einen Satz Strahlverfolgungskerne 245 enthalten. Ein Scheduler/Dispatcher 241 plant und verteilt die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 243, 244, 245. Ein Satz Registerdateien 242 speichert Operandenwerte, die von den Kernen 243, 244, 245 verwendet werden, wenn die Grafik-Threads ausgeführt werden. Zu diesen können zum Beispiel zählen: Integer-Register zum Speichern von Integer-Werten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern von gepackten Datenelementen (Integer- und/oder Gleitkomma-Datenelementen) und Kachelregister zum Speichern von Tensor-/Matrizenwerten. In einer Ausführungsform sind die Kachelregister als kombinierte Sätze von Vektorregistern implementiert.
Einer oder mehrere kombinierte Level-1 (L1)-Caches und gemeinsam genutzte Speichereinheiten 247 speichern Grafikdaten, wie zum Beispiel Texturdaten, Vertexdaten, Pixeldaten, Strahldaten, Hüllkörperdaten usw. lokal in jeder Mehrkerngruppe 240A. Eine oder mehrere Textureinheiten 247 können auch verwendet werden, um Texturoperationen durchzuführen, wie zum Beispiel Textur-Mapping und -Abtastung. Ein Level-2 (L2)-Cache 253, der von allen oder einem Subsatz der Mehrkerngruppen 240A - 240N gemeinsam genutzt wird, speichert Grafikdaten und/oder Anweisungen für mehrere, gleichzeitig ablaufende Grafik-Threads. Wie veranschaulicht wird, kann der L2-Cache 253 über mehrere Mehrkerngruppen 240A - 240N gemeinsam genutzt werden. Einer oder mehrere Speicher-Controller 248 koppeln die GPU 239 mit einem Speicher 249, der ein Systemspeicher (z. B. DRAM) und/oder ein dedizierter Grafikspeicher (z. B. GDDR6-Speicher) sein kann.
Eingabe-/Ausgabe (E/A)-Schaltkreise 250 koppeln die GPU 239 mit einer oder mehreren E/A-Einrichtungen 252, wie zum Beispiel Digital-Signal-Prozessoren (DSPs), Netzwerk-Controllern oder Anwendereingabeeinrichtungen. Eine On-Chip-Verschaltung kann verwendet werden, um die E/A-Einrichtungen 252 mit der GPU 239 und dem Speicher 249 zu koppeln. Eine oder mehrere E/A-Speichermanagementeinheiten (E/A-MMUs) 251 der E/A-Schaltkreise 250 koppeln die E/A-Einrichtungen 252 direkt mit dem Systemspeicher 249. In einer Ausführungsform managt die E/A-MMU 251 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physische Adressen im Systemspeicher 249 zu mappen. In dieser Ausführungsform können die E/A-Einrichtungen 252, die CPU(s) 246 und die GPU(s) 239 den gleichen virtuellen Adressraum gemeinsam nutzen.
In einer Implementierung unterstützt die E/A-MMU 251 Virtualisierung. In diesem Fall kann sie einen ersten Satz Seitentabellen managen, um virtuelle Gast-/Grafik-Adressen auf physische Gast-/Grafik-Adressen zu mappen, und einen zweiten Satz Seitentabellen, um die physischen Gast-/Grafik-Adressen auf die physischen System-/Host-Adressen (z. B. im Systemspeicher 249) zu mappen. Die Basisadressen von jedem des ersten und zweiten Satzes Seitentabellen können in Steuerregistern und bei einem Kontextwechsel ausgelagert werden (z. B. so dass dem neuen Kontext Zugriff auf den relevanten Satz Seitentabellen bereitgestellt wird). Obwohl dies in der 2C nicht veranschaulicht wird, kann jeder der Kerne 243, 244, 245 und/oder jede der Mehrkerngruppen 240A - 240N Übersetzungspuffer (Translation Lookaside Buffers, TLBs) enthalten, um virtuelle Gast- in physische Gast-Übersetzungen, physische Gast- in physische Host-Übersetzungen und virtuelle Gast- in physische Host-Übersetzungen zu cachen.
In einer Ausführungsform sind die CPUs 246, die GPUs 239 und die E/A-Einrichtungen 252 auf einem einzigen Halbleiter-Chip und/oder Chip-Package integriert. Der veranschaulichte Speicher 249 kann auf dem gleichen Chip integriert sein oder kann mit dem Speicher-Controller 248 über eine Off-Chip-Schnittstelle gekoppelt sein. In einer Implementierung umfasst der Speicher 249 GDDR6-Speicher, der den gleichen virtuellen Adressraum wie andere physische Speicher auf dem Systemlevel nutzt, obwohl die zugrundeliegenden Prinzipien der Erfindung nicht auf diese spezifische Implementierung beschränkt sind.
In einer Ausführungsform enthalten die Tensorkerne 244 mehrere Ausführungseinheiten, die insbesondere dazu entworfen sind, Matrizenoperationen durchzuführen, die die grundlegenden Rechenoperationen sind, die zum Durchführen von Deep-Learning-Operationen verwendet werden. Zum Beispiel können zeitgleiche Matrizenmultiplikationsoperationen für Training und Inferenzieren von neuronalen Netzen verwendet werden. Die Tensorkerne 244 können Matrizenverarbeitung unter Verwendung einer Vielzahl von Operandengenauigkeiten durchführen, einschließlich Gleitkomma mit einfacher Genauigkeit (z. B. 32 Bits), Gleitkomma mit halber Genauigkeit (z. B. 16 Bits), Integer-Wörter (16 Bits), Bytes (8 Bits) und Halbbytes (4 Bits). In einer Ausführungsform extrahiert eine Implementierung eines neuronalen Netzes Merkmale jeder gerenderten Szene, wobei sie potentiell Details aus mehreren Frames kombiniert, um ein hochwertiges endgültiges Bild zu erstellen.
Bei Deep-Learning-Implementierungen können parallele Matrizenmultiplikationsvorgänge zur Ausführung auf den Tensorkernen 244 eingeplant werden. Das Training von neuronalen Netzen erfordert insbesondere eine erhebliche Anzahl an Matrizen-Skalarprodukt-Operationen. Um eine Skalarproduktformel einer N × N × N-Matrizenmultiplikation zu verarbeiten, können die Tensorkerne 244 wenigstens N Skalarprodukt-Verarbeitungselemente enthalten. Bevor die Matrizenmultiplikation beginnt, wird eine ganze Matrix in Kachelregister geladen, und wenigstens eine Spalte einer zweiten Matrix wird in jedem Zyklus für N Zyklen geladen. In jedem Zyklus gibt es N Skalarprodukte, die verarbeitet werden.
Matrizenelemente können mit unterschiedlicher Genauigkeit gespeichert werden, abhängig von der speziellen Implementierung, einschließlich als Wörter mit 16 Bits, Bytes mit 8 Bits (z. B. INT8) und Halbbytes mit 4 Bits (z. B. INT4). Unterschiedliche Genauigkeitsmodi können für die Tensorkerne 244 spezifiziert werden, um sicherzustellen, dass für unterschiedliche Arbeiten die effizienteste Genauigkeit verwendet wird (z. B. für Interferenzierarbeiten, die Quantisierung auf Bytes und Halbbytes tolerieren können).
In einer Ausführungsform beschleunigen die Strahlverfolgungskerne 245 Strahlverfolgungsoperationen sowohl für Implementierungen mit Echtzeit-Strahlverfolgung als auch mit Nicht-Echtzeit-Strahlverfolgung. Insbesondere enthalten die Strahlverfolgungskerne 245 Strahltraversierungs-/-kreuzungs-Schaltkreise zum Durchführen von Strahltraversierung unter Verwendung von Hüllkörperhierarchien (Bounding Volume Hierarchies, BVHs) und zum Identifizieren von Kreuzungen zwischen Strahlen und Primitiven, die in den BVH-Körpern eingeschlossen sind. Die Strahlverfolgungskerne 245 können auch Schaltkreise zum Durchführen von Tiefenprüfung und Culling enthalten (z. B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung). In einer Implementierung führen die Strahlverfolgungskerne 245 Traversierungs- und Kreuzungsoperationen zusammen mit den hier beschriebenen Rauschunterdrückungstechniken durch, von denen wenigstens ein Teil auf den Tensorkernen 244 ausgeführt werden kann. Zum Beispiel implementieren die Tensorkerne 244 in einer Ausführungsform ein neuronales Deep-Learning-Netzwerk, um Rauschunterdrückung bei Frames, die von den Strahlverfolgungskernen 245 generiert worden sind, durchzuführen. Allerdings können die CPU(s) 246, die Grafikkerne 243 und/oder die Strahlverfolgungskerne 245 auch alle oder einen Teil der Rauschunterdrückung und/oder der Deep-Learning-Algorithmen implementieren.
Wie oben beschrieben wird, kann zusätzlich ein verteilter Ansatz zur Rauschunterdrückung eingesetzt werden, bei dem die GPU 239 sich in einer Recheneinrichtung befindet, die mit anderen Recheneinrichtungen über ein Netzwerk oder eine Hochgeschwindigkeitsverschaltung gekoppelt ist. In dieser Ausführungsform nutzen die verschalteten Recheneinrichtungen neuronale Netzwerk-Lern-/Trainingsdaten, um die Geschwindigkeit, mit der das Gesamtsystem lernt, zu verbessern, um Rauschunterdrückung für unterschiedliche Typen von Bild-Frames und/oder unterschiedliche Grafikanwendungen durchzuführen.
In einer Ausführungsform verarbeiten die Strahlverfolgungskerne 245 alle BVH-Traversierungs- und Strahl-Primitiven-Kreuzungen, was die Grafikkerne 243 davor bewahrt, mit Tausenden Anweisungen pro Strahl überladen zu werden. In einer Ausführungsform enthält jeder Strahlverfolgungskern 245 einen ersten Satz spezialisierter Schaltkreise zum Durchführen von Hüllkörperprüfungen (z. B. für Traversierungsoperationen) und einen zweiten Satz spezialisierter Schaltkreise zum Durchführen der Strahl-Dreiecks-Kreuzungsprüfungen (z. B. kreuzende Strahlen, die traversiert worden sind). Somit kann in einer Ausführungsform die Mehrkerngruppe 240A einfach eine Strahlprobe einkoppeln, und die Strahlverfolgungskerne 245 führen unabhängig Strahltraversierung und -kreuzung durch und geben Trefferdaten (z. B. ein Treffer, kein Treffer, mehrere Treffer usw.) an den Thread-Kontext zurück. Die anderen Kerne 243, 244 werden freigegeben, um andere Grafik- oder Rechenarbeit durchzuführen, während die Strahlverfolgungskerne 245 die Traversierungs- und Kreuzungsoperationen durchführen.
In einer Ausführungsform enthält jeder Strahlverfolgungskern 245 eine Traversierungseinheit, um BVH-Prüfoperationen durchzuführen, und eine Kreuzungseinheit, die Strahl-Primitive-Kreuzungsprüfungen durchführt. Die Kreuzungseinheit generiert eine Antwort „Treffer“, „kein Treffer“ oder „mehrere Treffer“, die sie dem geeigneten Thread bereitstellt. Während der Traversierungs- und Kreuzungsoperationen sind die Ausführungsressourcen der anderen Kerne (z. B. der Grafikkerne 243 und der Tensorkerne 244) zum Durchführen von anderen Formen von Grafikarbeit freigegeben.
In einer nachstehend beschriebenen speziellen Ausführungsform wird ein Rasterisierungs-/Strahlverfolgungs-Hybridansatz verwendet, bei dem die Arbeit zwischen den Grafikkernen 243 und den Strahlverfolgungskernen 245 verteilt wird.
In einer Ausführungsform enthalten die Strahlverfolgungskerne 245 (und/oder andere Kerne 243, 244) Hardware-Unterstützung für einen Strahlverfolgungsanweisungssatz, wie zum Beispiel DirectX Ray Tracing (DXR) von Microsoft, der einen DispatchRays-Befehl enthält, sowie Strahlgenerierungs-, Closest-Hit-, Any-Hit- und Miss-Shader, die das Zuweisen eines eindeutigen Satzes von Shadern und Texturen für jedes Objekt ermöglichen. Eine andere Strahlverfolgungsplattform, die durch die Strahlverfolgungskerne 245, die Grafikkerne 243 und die Tensorkerne 244 unterstützt werden kann, ist Vulkan 1.1.85. Es sei allerdings angemerkt, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf irgendeine spezielle Strahlverfolgungs-ISA beschränkt sind.
Im Allgemeinen können die verschiedenen Kerne 245, 244, 243 einen Strahlverfolgungsanweisungssatz unterstützen, der Anweisungen/Funktionen für Strahlgenerierung, Closest Hit, Any Hit, Strahl-Primitiven-Kreuzung, Hüllkörpererstellung je Primitiv und hierarchisch, Miss, Visit und Ausnahmen enthält. Insbesondere enthält eine Ausführungsform Strahlverfolgungsanweisungen, um die folgenden Funktionen durchzuführen:
Ray Generation - Ray-Generation-Anweisungen können für jedes Pixel, jedes Abtasten oder andere anwenderdefinierte Arbeitszuweisung ausgeführt werden.
Closest Hit - Eine Closest-Hit-Anweisung kann ausgeführt werden, um den nächsten Kreuzungspunkt eines Strahls mit Primitiven innerhalb einer Szene aufzufinden.
Any Hit - Eine Any-Hit-Anweisung identifiziert mehrere Kreuzungen zwischen einem Strahl und Primitiven innerhalb einer Szene, potenziell, um einen neuen nächsten Kreuzungspunkt zu identifizieren.
Intersection - Eine Intersection-Anweisung führt eine Strahl-Primitiven-Kreuzungsprüfung durch und gibt ein Ergebnis aus.
Per-Primitive Bounding Box Construction - Diese Anweisung bildet einen Hüllkörper um ein gegebenes Primitiv oder eine Gruppe von Primitiven (z. B. beim Bilden einer neuen BVH oder einer anderen Beschleunigungsdatenstruktur).
Miss - Gibt an, dass ein Strahl jede Geometrie innerhalb einer Szene oder eines spezifizierten Bereichs einer Szene verfehlt.
Visit - Gibt die untergeordneten Körper an, die ein Strahl traversieren wird.
Ausnahmen - Enthält verschiedene Typen von Ausnahmebehandlungen (die z. B. für verschiedene Fehlerbedingungen aufgerufen werden).
Die 2D ist ein Blockdiagramm einer universellen Grafikverarbeitungseinheit (General Purpose Graphics Processing Unit, GPGPU) 270, die als ein Grafikprozessor und/oder Rechenbeschleuniger gemäß hier beschriebenen Ausführungsformen ausgebildet sein kann. Die GPGPU 270 kann mit Host-Prozessoren (z. B. einer oder mehreren CPU(s) 246) und Speicher 271, 272 über einen oder mehrere System- und/oder Speicherbusse verschalten. In einer Ausführungsform ist der Speicher 271 ein Systemspeicher, der mit der einen oder den mehreren CPU(s) 246 gemeinsam genutzt werden kann, während der Speicher 272 ein Einrichtungsspeicher ist, der für die GPGPU 270 dediziert ist. In einer Ausführungsform können Komponenten innerhalb der GPGPU 270 und dem Einrichtungsspeicher 272 in Speicheradressen gemappt werden, die für die eine oder die mehreren CPU(s) 246 zugriffsfähig sind. Der Zugriff auf den Speicher 271 und 272 kann über einen Speicher-Controller 268 ermöglicht werden. In einer Ausführungsform enthält der Speicher-Controller 268 einen internen Direkt-Speicherzugriffs (Direct Memory Access, DMA)-Controller 269 oder kann Logik zum Durchführen von Operationen enthalten, die andernfalls von einem DMA-Controller durchgeführt werden würden.
Die GPGPU 270 enthält mehrere Cache-Speicher, einschließlich einem L2-Cache 253, einem L1-Cache 254, einem Anweisungs-Cache 255 und gemeinsam genutztem Speicher 256, von dem wenigstens ein Teil ebenfalls als ein Cache-Speicher partitioniert sein kann. Die GPGPU 270 enthält auch mehrere Recheneinheiten 260A - 260N. Jede Recheneinheit 260A - 260N enthält einen Satz Vektorregister 261, Skalarregister 262, Vektorlogikeinheiten 263 und Skalarlogikeinheiten 264. Die Recheneinheiten 260A - 260N können auch gemeinsam genutzten lokalen Speicher 265 und einen Programmzähler 266 enthalten. Die Recheneinheiten 260A - 260N können mit einem Konstant-Cache 267 koppeln, der verwendet werden kann, um konstante Daten zu speichern, welche Daten sind, die sich während des Durchlaufs eines Kernel- oder Shader-Programms, das auf der GPGPU 270 ausgeführt wird, nicht ändern werden. In einer Ausführungsform ist der Konstant-Cache 267 ein Skalardaten-Cache, und gecachte Daten können direkt in die Skalarregister 262 abgerufen werden.
Während der Operation kann die eine oder die mehreren CPU(s) 246 Befehle in Register oder Speicher in der GPGPU 270 schreiben, die auf zugriffsfähigen Adressraum gemappt worden ist. Die Befehlsprozessoren 257 können Befehle aus Registern oder Speicher lesen und bestimmen, wie diese Befehle in der GPGPU 270 verarbeitet werden. Ein Thread-Dispatcher 258 kann dann verwendet werden, um Threads auf die Recheneinheiten 260A - 260N zu verteilen, um diese Befehle durchzuführen. Jede Recheneinheit 260A - 260N kann Threads unabhängig von den anderen Recheneinheiten ausführen. Zusätzlich kann jede Recheneinheit 260A - 260N unabhängig für bedingte Berechnung konfiguriert werden und die Ergebnisse der Berechnung bedingt zum Speicher ausgeben. Der Befehlsprozessor 257 kann die eine oder die mehreren CPU(s) 246 unterbrechen, wenn die abgegebenen Befehle abgeschlossen sind.
Die 3A - 3C veranschaulichen Blockdiagramme von zusätzlichen Grafikprozessor- und Rechenbeschleuniger-Architekturen, die durch hier beschriebene Ausführungsformen bereitgestellt werden. Die Elemente der 3A - 3C, die die gleichen Bezugsnummern (oder -bezeichnungen) wie hier die Elemente irgendeiner anderen Figur aufweisen, können auf irgendeine Art und Weise, die der hier an anderer Stelle beschriebenen ähnelt, arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt.
Die 3A ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit sein kann oder der ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen oder anderen Halbleitereinrichtungen, wie zum Beispiel, aber nicht darauf beschränkt, Speichereinrichtungen oder Netzwerkschnittstellen, integriert ist. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine speichergemappte E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die im Prozessorspeicher platziert sind. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Speicherschnittstelle 314, um auf Speicher zuzugreifen. Die Speicherschnittstelle 314 kann eine Schnittstelle zum lokalen Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam genutzten externen Caches und/oder dem Systemspeicher sein.
In einigen Ausführungsformen enthält der Grafikprozessor 300 auch einen Anzeige-Controller 302 zum Ansteuern von Anzeigeausgabedaten zur Anzeigeeinrichtung 318. Der Anzeige-Controller 302 enthält Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Komposition mehrerer Schichten von Video- oder Anwenderschnittstellenelementen. Die Anzeigeeinrichtung 318 kann eine interne oder externe Anzeigeeinrichtung sein. In einer Ausführungsform ist die Anzeigeeinrichtung 318 eine Head-Mounted Display-Einrichtung, wie zum Beispiel eine Virtual Reality (VR)-Anzeigeeinrichtung oder eine Augmented Reality (AR)-Anzeigeeinrichtung. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Video-Codec-Engine 306, um Medien zu, aus oder zwischen einem oder mehreren Mediencodierformaten zu codieren, zu decodieren oder umzucodieren, einschließlich, aber nicht darauf beschränkt, Moving Picture Experts Group (MPEG)-Formate, wie zum Beispiel MPEG-2, Advanced Video Coding (AVC)-Formate, wie zum Beispiel H.264/MPEG-4 AVC, H.265/HEVC, Alliance for Open Media (AOMedia) VP8, VP9, sowie die Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1- und die Joint Photographic Experts Group (JPEG)-Formate, wie zum Beispiel JPEG, und Motion JPEG (MJPEG)-Formate.
In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Block Image Transfer (BLIT)-Engine 304, um zweidimensionale (2D-) Rasterisiereroperationen durchzuführen, einschließlich zum Beispiel Bit-Boundary Block Transfers. Allerdings werden in einer Ausführungsform 2D-Grafikoperationen unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE) 310 durchgeführt. In einigen Ausführungsformen ist die GPE 310 eine Rechen-Engine zum Durchführen von Grafikoperationen, einschließlich dreidimensionaler (3D-) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen enthält die GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen, wie zum Beispiel Rendern von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivenformen (z. B. rechteckige, dreieckige usw.) einwirken. Die 3D-Pipeline 312 enthält programmierbare und feste Funktionselemente, die verschiedene Aufgaben innerhalb der Element- und/oder Spawn-Ausführungs-Threads an einem 3D-/Medien-Subsystem 315 durchführen. Während die 3D-Pipeline 312 verwendet werden kann, um Medienoperationen durchzuführen, enthält eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316, die insbesondere verwendet wird, um Medienoperationen, wie zum Beispiel Video-Nachbearbeitung und Bildverbesserung, durchzuführen.
In einigen Ausführungsformen enthält die Medien-Pipeline 316 Festfunktions- oder programmierbare Logikeinheiten, um eine oder mehrere spezialisierte Medienoperationen durchzuführen, wie zum Beispiel Videodecodierungsbeschleunigung, Video-Deinterlacing und Videocodierungsbeschleunigung, anstelle von oder im Auftrag der Video-Codec-Engine 306. In einigen Ausführungsformen enthält die Medien-Pipeline 316 zusätzlich eine Thread-Spawn-Einheit, um Threads für die Ausführung auf dem 3D-/Medien-Subsystem 315 zu spawnen. Die gespawnten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die im 3D-/Medien-Subsystem 315 enthalten sind.
In einigen Ausführungsformen enthält das 3D-/Medien-Subsystem 315 Logik zum Ausführen von Threads, die von der 3D-Pipeline 312 und der Medien-Pipeline 316 gespawnt worden sind. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanforderungen an das 3D-/Medien-Subsystem 315, das Thread-Verteilungslogik zum Arbitrieren und Verteilen der verschiedenen Anfragen an verfügbare Thread-Ausführungsressourcen enthält. Die Ausführungsressourcen enthalten ein Array von Grafikausführungseinheiten, um die 3D- und Medien-Threads zu verarbeiten. In einigen Ausführungsformen enthält das 3D-/Medien-Subsystem 315 einen oder mehrere interne Caches für Thread-Anweisungen und -Daten. In einigen Ausführungsformen enthält das Subsystem auch gemeinsam genutzten Speicher, einschließlich Registern und adressierbarem Speicher, um Daten unter Threads gemeinsam zu nutzen und Ausgabedaten zu speichern.
Die 3B veranschaulicht einen Grafikprozessor 320 mit einer Kachelarchitektur gemäß hier beschriebenen Ausführungsformen. In einer Ausführungsform enthält der Grafikprozessor 320 einen Grafikverarbeitungs-Engine-Cluster 322 mit mehreren Instanzen der Grafikverarbeitungs-Engine 310 der 3A in einer Grafik-Engine-Kachel 310A - 310D. Jede Grafik-Engine-Kachel 310A - 310D kann über einen Satz Kachelverbindungen 323A - 323F verschaltet sein. Jede Grafik-Engine-Kachel 310A - 310D kann auch mit einem Speichermodul oder einer Speichereinrichtung 326A - 326D über die Speicherverschaltungen 325A - 325D verbunden sein. Die Speichereinrichtungen 326A - 326D können irgendeine Grafikspeichertechnologie verwenden. Zum Beispiel können die Speichereinrichtungen 326A - 326D Graphics Double Data Rate (GDDR)-Speicher sein. Die Speichereinrichtungen 326A - 326D sind in einer Ausführungsform Speicher mit hoher Bandbreite (High-Bandwidth Memory, HBM)-Module, die sich auf einem Die mit ihrer jeweiligen Grafik-Engine-Kachel 310A - 310D befinden können. In einer Ausführungsform sind die Speichereinrichtungen 326A - 326D Stapelspeichereinrichtungen, die auf ihrer jeweiligen Grafik-Engine-Kachel 310A - 310D gestapelt sein können. In einer Ausführungsform befinden sich jede Grafik-Engine-Kachel 310A - 310D und der zugehörige Speicher 326A - 326D auf separaten Chiplets, die mit einem Basis-Die oder Basissubstrat gebondet sind, wie ausführlicher in den 11B - 11D beschrieben wird.
Der Grafikverarbeitungs-Engine-Cluster 322 kann mit einer On-Chip- oder On-Package-Strukturverschaltung 324 verbinden. Die Strukturverschaltung 324 kann Kommunikation zwischen Grafik-Engine-Kacheln 310A - 310D und Komponenten, wie zum Beispiel dem Video-Codec 306 und einer oder mehreren Kopier-Engines 304, ermöglichen. Die Kopier-Engines 304 können verwendet werden, um Daten aus den, in die und zwischen den Speichereinrichtungen 326A - 326D und Speicher, der für den Grafikprozessor 320 extern ist (z. B. der Systemspeicher), zu bewegen. Die Strukturverschaltung 324 kann auch verwendet werden, um die Grafik-Engine-Kacheln 310A - 310D zu verschalten. Der Grafikprozessor 320 kann optional einen Anzeige-Controller 302 enthalten, um eine Verbindung mit einer externen Anzeigeeinrichtung 318 zu ermöglichen. Der Grafikprozessor kann auch als ein Grafik- oder Rechenbeschleuniger ausgebildet sein. In der Beschleunigerausbildungsform können der Anzeige-Controller 302 und die Anzeigeeinrichtung 318 weggelassen sein.
Der Grafikprozessor 320 kann über eine Host-Schnittstelle 328 mit einem Host-System verbinden. Die Host-Schnittstelle 328 kann Kommunikation zwischen dem Grafikprozessor 320, dem Systemspeicher und/oder anderen Systemkomponenten ermöglichen. Die Host-Schnittstelle 328 kann zum Beispiel ein PCI Express-Bus oder ein anderer Typ von Host-Systemschnittstelle sein.
Die 3C veranschaulicht einen Rechenbeschleuniger 330 gemäß hier beschriebenen Ausführungsformen. Der Rechenbeschleuniger 330 kann architektonische Ähnlichkeiten zum Grafikprozessor 320 der 3B aufweisen und ist für die Rechenbeschleunigung optimiert. Ein Rechen-Engine-Cluster 332 kann einen Satz Rechen-Engine-Kacheln 340A - 340D enthalten, die Ausführungslogik enthalten, die für parallele oder vektorbasierte universelle Rechenoperationen optimiert ist. In einigen Ausführungsformen enthalten die Rechen-Engine-Kacheln 340A - 340D keine Festfunktions-Grafikverarbeitungslogik, obwohl in einer Ausführungsform eine oder mehrere der Rechen-Engine-Kacheln 340A - 340D Logik zum Durchführen von Medienbeschleunigung enthalten können. Die Rechen-Engine-Kacheln 340A - 340D können über die Speicherverschaltungen 325A - 325D mit dem Speicher 326A - 326D verbinden. Die Speicher 326A - 326D und die Speicherverschaltungen 325A - 325D können eine ähnliche Technologie wie im Grafikprozessor 320 sein, oder sie können sich unterscheiden. Die Grafik-Rechen-Engine-Kacheln 340A - 340D können auch über einen Satz Kachelverschaltungen 323A - 323F verschaltet sein und können mit einer Strukturverschaltung 324 verbunden und/oder durch eine Strukturverbindung 324 verschaltet sein. In einer Ausführungsform enthält der Rechenbeschleuniger 330 einen großen L3-Cache 336, der als ein einrichtungsübergreifender Cache ausgebildet sein kann. Der Rechenbeschleuniger 330 kann auch mit einem Host-Prozessor und Speicher über eine Host-Schnittstelle 328, in ähnlicher Weise wie der Grafikprozessor 320 der 3B, verbinden.
Grafikverarbeitungs-Engine
Die 4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors gemäß einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungs-Engine (GPE) 410 eine Version der in der 3A gezeigten GPE 310 und kann auch eine Grafik-Engine-Kachel 310A - 310D der 3B darstellen. Elemente der 4, die die gleichen Bezugsnummern (oder -bezeichnungen) wie die Elemente irgendeiner anderen Figur aufweisen, können auf irgendeine Art und Weise, die der hier an anderer Stelle beschriebenen ähnelt, arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Zum Beispiel sind die 3D-Pipeline 312 und die Medien-Pipeline 316 der 3A veranschaulicht. Die Medien-Pipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und ist möglicherweise nicht explizit in der GPE 410 enthalten. Zum Beispiel und in wenigstens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
In einigen Ausführungsformen koppelt die GPE 410 mit einem Befehls-Streamer 403 oder enthält diesen, der einen Befehlsstrom für die 3D-Pipeline 312 und/oder die Medien-Pipelines 316 bereitstellt. In einigen Ausführungsformen ist der Befehls-Streamer 403 mit Speicher gekoppelt, der Systemspeicher oder einer oder mehrere interne Cache-Speichern und gemeinsam genutzter Cache-Speicher sein kann. In einigen Ausführungsformen empfängt der Befehls-Streamer 403 Befehle aus dem Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medien-Pipeline 316. Die Befehle sind Anweisungen, die aus einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 312 und die Medien-Pipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Batch-Befehlspuffer enthalten, die Batches von mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Verweise auf im Speicher gespeicherte Daten enthalten, wie zum Beispiel, aber nicht darauf beschränkt, auf Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 312 und die Medien-Pipeline 316 verarbeiten die Befehle und Daten durch Durchführen von Operationen über Logik in den jeweiligen Pipelines oder durch Verteilen eines oder mehrerer Ausführungs-Threads an ein Grafikkern-Array 414. In einer Ausführungsform enthält das Grafikkern-Array 414 einen oder mehrere Blöcke von Grafikkernen (z. B. Grafikkern(e) 415A, Grafikkern(e) 415B), wobei jeder Block einen oder mehrere Grafikkerne enthält. Jeder Grafikkern enthält einen Satz Grafikausführungsressourcen, der universelle und grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Rechenoperationen sowie Festfunktions-Texturverarbeitung und/oder Beschleunigungslogik für maschinelles Lernen und künstliche Intelligenz enthält.
In verschiedenen Ausführungsformen kann die 3D-Pipeline 312 Festfunktions- und programmierbare Logik enthalten, um eines oder mehrere Shader-Programme, wie zum Beispiel Vertex-Shader, Geometry-Shader, Pixel-Shader, Fragment-Shader, Compute-Shader oder andere Shader-Programme, durch Verarbeiten der Anweisungen und Verteilen der Ausführungs-Threads an das Grafikkern-Array 414 zu verarbeiten. Das Grafikkern-Array 414 stellt einen Einheits-Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shader-Programme bereit. Mehrzweck-Ausführungslogik (z. B. Ausführungseinheiten) in dem/den Grafikkern(en) 415A - 414B des Grafikkern-Arrays 414 enthält Unterstützung für verschiedene 3D-API-Shader-Sprachen und kann mehrere simultane Ausführungs-Threads, die mit mehreren Shadern verknüpft sind, ausführen.
In einigen Ausführungsformen enthält das Grafikkern-Array 414 Ausführungslogik zum Durchführen von Medienfunktionen, wie zum Beispiel Video- und/oder Bildverarbeitung. In einer Ausführungsform enthalten die Ausführungseinheiten universelle Logik, die zum Durchführen von parallelen universellen Rechenoperationen zusätzlich zu Grafikverarbeitungsoperationen programmierbar ist. Die universelle Logik kann Verarbeitungsoperationen parallel oder in Verbindung mit universeller Logik innerhalb des/der Prozessorkern(e) 107 der 1 oder des Kerns 202A - 202N wie in der 2A durchführen.
Ausgabedaten, die von Threads generiert werden, die auf dem Grafikkern-Array 414 ausgeführt werden, können Daten an den Speicher in einem Einheits-Rückgabepuffer (Unified Return Buffer, URB) 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 unterschiedlichen Threads zu senden, die auf dem Grafikkern-Array 414 ausgeführt werden. In einigen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisation zwischen Threads auf dem Grafikkern-Array und Festfunktionslogik in der gemeinsam genutzten Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist das Grafikkern-Array 414 skalierbar, so dass das Array eine variable Anzahl an Grafikkernen enthält, die jeweils eine variable Anzahl an Ausführungseinheiten basierend auf der Zielleistung und dem Performancelevel der GPE 410 aufweisen. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, so dass Ausführungsressourcen nach Bedarf aktiviert oder deaktiviert werden können.
Das Grafikkern-Array 414 koppelt mit der gemeinsam genutzten Funktionslogik 420, die mehrere Ressourcen enthält, die von den Grafikkernen im Grafikkern-Array gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen in der gemeinsam genutzten Funktionslogik 420 sind Hardware-Logikeinheiten, die spezialisierte Zusatzfunktionalität für das Grafikkern-Array 414 bereitstellen. In verschiedenen Ausführungsformen enthält gemeinsam genutzte Funktionslogik 420, ohne jedoch darauf beschränkt zu sein, Sampler- 421, Mathematik- 422 und Inter-Thread-Kommunikations 423 (Inter-Thread Communication, ITC)-Logik. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Cache(s) 425 in der gemeinsam genutzten Funktionslogik 420.
Eine gemeinsam genutzte Funktion wird wenigstens in einem Fall implementiert, in dem die Forderung nach einer spezialisierten Funktion zum Einschluss in das Grafikkern-Array 414 unzureichend ist. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eine Standalone-Instanz in der gemeinsam genutzten Funktionslogik 420 implementiert und von den Ausführungsressourcen im Grafikkern-Array 414 gemeinsam genutzt. Der genaue Satz an Funktionen, die im Grafikkern-Array 414 gemeinsam genutzt werden und im Grafikkern-Array 414 enthalten sind, variiert zwischen Ausführungsformen. In einigen Ausführungsformen können spezifische gemeinsam genutzte Funktionen innerhalb der gemeinsam genutzten Funktionslogik 420, die vom Grafikkern-Array 414 extensiv verwendet werden, in der gemeinsam genutzten Funktionslogik 416 im Grafikkern-Array 414 enthalten sein. In verschiedenen Ausführungsformen kann die gemeinsam genutzte Funktionslogik 416 im Grafikkern-Array 414 etwas von oder die gesamte Logik in der gemeinsam genutzten Funktionslogik 420 enthalten. In einer Ausführungsform können alle Logikelemente in der gemeinsam genutzten Funktionslogik 420 in der gemeinsam genutzten Funktionslogik 416 des Grafikkern-Arrays 414 dupliziert sein. In einer Ausführungsform wird die gemeinsam genutzte Logikfunktion 420 zu Gunsten der gemeinsam genutzten Funktionslogik 416 im Grafikkern-Array 414 ausgeschlossen.
Ausführungseinheiten
Die 5A - 5B veranschaulichen Thread-Ausführungslogik 500, die ein Array von Verarbeitungselementen enthält, die in einem Grafikprozessorkern eingesetzt werden, gemäß Ausführungsformen. Elemente der 5A - 5B, die die gleichen Bezugsnummern (oder -bezeichnungen) wie die Elemente irgendeiner anderen Figur hier aufweisen, können auf irgendeine ähnliche Weise, wie die hier an anderer Stelle beschriebene arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Die 5A - 5B veranschaulichen einen Überblick über Thread-Ausführungslogik 500, der für Hardware-Logik repräsentativ sein kann, die mit jedem Subkern 221A - 221F der 2B veranschaulicht wird. Die 5A ist repräsentativ für eine Ausführungseinheit in einem universellen Grafikprozessor, während die 5B repräsentativ für eine Ausführungseinheit ist, die in einem Rechenbeschleuniger verwendet werden kann.
Wie in der 5A veranschaulicht wird, enthält die Thread-Ausführungslogik 500 in einigen Ausführungsformen einen Shader-Prozessor 502, einen Thread-Dispatcher 504, den Anweisungs-Cache 506, ein skalierbares Ausführungseinheiten-Array, das mehrere Ausführungseinheiten 508A - 508N enthält, einen Sampler 510, gemeinsam genutzten lokalen Speicher 511, einen Daten-Cache 512 und einen Daten-Port 514. In einer Ausführungsform kann das skalierbare Ausführungseinheiten-Array dynamisch skalieren, indem eine oder mehrere Ausführungseinheiten (z. B. irgendeine der Ausführungseinheiten 508A, 508B, 508C, 508D bis 508N-1 und 508N) basierend auf den Rechenanforderungen einer Arbeit aktiviert oder deaktiviert werden. In einer Ausführungsform sind die enthaltenen Komponenten über eine Verschaltungsstruktur verschaltet, die mit jeder der Komponenten verknüpft. In einigen Ausführungsformen enthält die Thread-Ausführungslogik 500 eine oder mehrere Verbindungen zu Speicher, wie zum Beispiel zum Systemspeicher oder Cache-Speicher, über einen oder mehrere Befehls-Caches 506, den Daten-Port 514, den Sampler 510 und die Ausführungseinheiten 508A - 508N. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 508A) eine universelle programmierbare Standalone-Recheneinheit, die in der Lage ist, mehrere simultane Hardware-Threads auszuführen, während sie mehrere Datenelemente parallel für jeden Thread verarbeitet. In verschiedenen Ausführungsformen ist das Array von Ausführungseinheiten 508A - 508N skalierbar, so dass es irgendeine Anzahl einzelner Ausführungseinheiten enthält.
In einigen Ausführungsformen werden die Ausführungseinheiten 508A - 508N primär verwendet, um Shader-Programme auszuführen. Ein Shader-Prozessor 502 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads, die mit den Shader-Programmen verknüpft sind, über einen Thread-Dispatcher 504 verteilen. In einer Ausführungsform enthält der Thread-Dispatcher Logik, um Thread-Einleitungsanforderungen aus den Grafik- und Medien-Pipelines zu arbitrieren und die angeforderten Threads auf eine oder mehrere Ausführungseinheiten in den Ausführungseinheiten 508A - 508N zu instanziieren. Zum Beispiel kann eine Geometrie-Pipeline Vertex-, Tessellations- oder Geometry-Shader an die Thread-Ausführungslogik zur Verarbeitung verteilen. In einigen Ausführungsformen kann der Thread-Dispatcher 504 auch Laufzeit-Thread-Spawning-Anforderungen aus den ausführenden Shader-Programmen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 508A - 508N einen Anweisungssatz, der native Unterstützung für viele Standard-3D-Grafik-Shaderanweisungen enthält, so dass Shader-Programme aus Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertexprogramme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z. B. Pixel-Shader, Fragment-Shader) und universelle Verarbeitung (z. B. Rechen- und Medien-Shader). Jede der Ausführungseinheiten 508A - 508N ist zur übergreifenden Single Instruction Multiple Data (SIMD)-Ausführung in der Lage, und Multi-Thread-Operation ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread in jeder Ausführungseinheit weist eine dedizierte Registerdatei mit hoher Bandbreite und verknüpftem, unabhängigem Thread-Zustand auf. Die Ausführung ist je Takt mehrfach ausgebend für Pipelines, die zu Integer-, Single- und doppelt genauen Gleitkommaoperationen in der Lage sind, für SIMD-Verzweigungsfähigkeit, logische Operationen, transzendente Operationen und andere sonstige Operationen. Während des Wartens auf Daten aus Speicher oder einer der gemeinsam genutzten Funktionen bewirkt Abhängigkeitslogik in den Ausführungseinheiten 508A - 508N, dass ein wartender Thread schläft, bis die angeforderten Daten zurückgegeben worden sind. Während der wartende Thread schläft, können Hardware-Ressourcen dem Verarbeiten anderer Threads gewidmet werden. Zum Beispiel kann eine Ausführungseinheit während einer Verzögerung, die mit einer Vertex-Shader-Operation verknüpft ist, Operationen für einen Pixel-Shader, Fragment-Shader oder einen anderen Typ von Shader-Programm, einschließlich eines anderen Vertex-Shaders, durchführen. Verschiedene Ausführungsformen können für die Ausführung durch Verwendung von Single Instruction Multiple Thread (SIMT) als einer Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD gelten. Der Verweis auf einen SIMD-Kern oder eine SIMD-Operation kann auch für SIMT oder für SIMD in Kombination mit SIMT gelten.
Jede Ausführungseinheit in den Ausführungseinheiten 508A - 508N arbeitet auf Arrays von Datenelementen. Die Anzahl an Datenelementen ist die „Ausführungsgröße“ oder die Anzahl an Kanälen für die Anweisung. Ein Ausführungskanal ist eine logische Einheit zur Ausführung für Datenelementezugriff, Maskierung und Flusssteuerung in Anweisungen. Die Anzahl an Kanälen kann unabhängig von der Anzahl an physischen Arithmetik-Logik-Einheiten (Arithmetic Logic Units, ALUs) oder Gleitkommaeinheiten (Floating Point Units, FPUs) für einen speziellen Grafikprozessor sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 508A - 508N Integer- und Gleitkomma-Datentypen.
Der Ausführungseinheiten-Anweisungssatz enthält 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 zum Beispiel auf einem 256 Bit breiten Vektor gearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert, und die Ausführungseinheit arbeitet auf dem Vektor als vier separate gepackte 54-Bit-Datenelemente (Datenelemente mit Quad-Word (QW)-Größe), acht separate gepackte 32-Bit Datenelemente (Datenelemente mit Doppelwort (DW)-Größe), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente mit Wort (W)-Größe) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente mit Byte (B)-Größe). Allerdings sind andere Vektorbreiten und Registergrößen möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten in einer vereinten Ausführungseinheit 509A - 509N mit Thread-Steuerlogik (507A - 507N) kombiniert werden, die den vereinten EUs gemeinsam ist. Mehrere EUs können in einer EU-Gruppe vereint sein. Jede EU in der vereinten EU-Gruppe kann dazu ausgebildet sein, einen separaten SIMD-Hardware-Thread auszuführen. Die Anzahl an EUs in einer vereinten EU-Gruppe kann gemäß Ausführungsformen variieren. Zusätzlich können verschiedene SIMD-Breiten je EU durchgeführt werden, einschließlich, aber nicht darauf beschränkt, SIMD8, SIMD16 und SIMD32. Jede vereinte Grafikausführungseinheit 509A - 509N enthält wenigstens zwei Ausführungseinheiten. Zum Beispiel enthält die vereinte Ausführungseinheit 509A eine erste EU 508A, eine zweite EU 508B und Thread-Steuerlogik 507A, die der ersten EU 508A und der zweiten EU 508B gemeinsam ist. Die Thread-Steuerlogik 507A steuert Threads, die auf der vereinten Grafikausführungseinheit 509A ausgeführt werden, was zulässt, dass jede EU in den vereinten Ausführungseinheiten 509A - 509N unter Verwendung eines gemeinsamen Anweisungszeigerregister ausgeführt wird.
Einer oder mehrere interne Anweisungs-Caches (z. B. 506) sind in der Thread-Ausführungslogik 500 enthalten, um Thread-Anweisungen für die Ausführungseinheiten zu cachen. In einigen Ausführungsformen sind einer oder mehrere Daten-Caches (z. B. 512) enthalten, um Thread-Daten während der Thread-Ausführung zu cachen. Threads, die auf der Ausführungslogik 500 ausgeführt werden, können auch explizit gemanagte Daten im gemeinsam genutzten lokalen Speicher 511 speichern. In einigen Ausführungsformen ist ein Sampler 510 enthalten, um Texturabtastung für 3D-Operationen und Medienabtastung für Medienoperationen bereitzustellen. In einigen Ausführungsformen enthält der Sampler 510 spezialisierte Textur- oder Medienabtastfunktionalität, um Textur- oder Mediendaten während des Sampling-Prozesses zu verarbeiten, bevor die abgetasteten Daten einer Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und Medien-Pipelines über Thread-Spawning- und -Verteilungslogik Thread-Einleitungsanforderungen an die Thread-Ausführungslogik 500. Sobald eine Gruppe von geometrischen Objekten verarbeitet und in Pixeldaten rasterisiert worden ist, wird Pixelprozessorlogik (z. B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) im Shader-Prozessor 502 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu bewirken, dass Ergebnisse an Ausgabeoberflächen geschrieben werden (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.). In einigen Ausführungsformen berechnen ein Pixel-Shader oder ein Fragment-Shader die Werte der verschiedenen Vertexattribute, die über das rasterisierte Objekt interpoliert werden sollen. In einigen Ausführungsformen führt Pixelprozessorlogik im Shader-Prozessor 502 dann ein über eine Anwendungsprogrammierschnittstelle (API) zugeführtes Pixel- oder Fragment-Shader-Programm aus. Um das Shader-Programm auszuführen, verteilt der Shader-Prozessor 502 Threads an eine Ausführungseinheit (z. B. 508A) über den Thread-Dispatcher 504. In einigen Ausführungsformen verwendet der Shader-Prozessor 502 Texturabtastlogik im Sampler 510, um auf Texturdaten in Texturkennfeldern zuzugreifen, die im Speicher gespeichert sind. Arithmetikoperationen auf den Texturdaten und den Geometriedaten berechnen Pixelfarbdaten für jedes Geometriefragment oder sondern eines oder mehrere Pixel von der weiteren Verarbeitung aus.
In einigen Ausführungsformen stellt der Daten-Port 514 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 500 bereit, um verarbeitete Daten zum Speicher für die weitere Verarbeitung auf einer Grafikprozessorausgabe-Pipeline auszugeben. In einigen Ausführungsformen enthält der Daten-Port 514 einen oder mehrere Cache-Speicher (z. B. den Daten-Cache 512) zum Cachen von Daten für den Speicherzugriff über den Daten-Port.
In einer Ausführungsform kann die Ausführungslogik 500 auch einen Strahlverfolger 505 enthalten, der Strahlverfolgungs-Beschleunigungsfunktionalität enthalten kann. Der Strahlverfolger 505 kann einen Strahlverfolgungs-Anweisungssatz unterstützen, der Anweisungen/Funktionen für die Strahlgenerierung enthält. Der Strahlverfolgungs-Anweisungssatz kann ähnlich dem Strahlverfolgungs-Anweisungssatz sein, der von den Strahlverfolgungskernen 245 in der 2C unterstützt wird, oder er kann sich davon unterscheiden.
Die 5B veranschaulicht beispielhafte interne Details einer Ausführungseinheit 508 gemäß Ausführungsformen. Eine Grafikausführungseinheit 508 kann eine Anweisungsabrufeinheit 537, ein allgemeines Registerdatei-Array (General Register File, GRF) 524, ein Architekturregisterdatei-Array (Architectural Register File, ARF) 526, einen Thread-Arbiter 522, eine Sendeeinheit 530, eine Verzweigungseinheit 532, einen Satz SIMD-Gleitkommaeinheiten (FPUs) 534 und in einer Ausführungsform einen Satz dedizierter Integer-SIMD-ALUs 535 enthalten. Das GRF 524 und das ARF 526 enthalten den Satz allgemeiner Registerdateien und Architekturregisterdateien, die mit jedem simultanen Hardware-Thread verknüpft sind, der in der Grafikausführungseinheit 508 aktiv sein kann. In einer Ausführungsform wird der architektonische Zustand für jeden Thread im ARF 526 aufrechterhalten, während Daten, die während der Thread-Ausführung verwendet werden, im GRF 524 gespeichert werden. Der Ausführungszustand jedes Thread, einschließlich der Anweisungszeiger für jeden Thread, kann in Thread-spezifischen Registern im ARF 526 gehalten werden.
In einer Ausführungsform weist die Grafikausführungseinheit 508 eine Architektur auf, die eine Kombination aus Simultaneous Multi-Threading (SMT) und feingranularem Interleaved Multi-Threading (IMT) ist. Die Architektur weist eine modulare Ausbildungsform auf, die zum Zeitpunkt des Designs basierend auf einer Zielanzahl an simultanen Threads und einer Anzahl an Registern je Ausführungseinheit fein abgestimmt werden kann, wobei die Ausführungseinheitenressourcen über Logik aufgeteilt werden, die verwendet wird, um mehrere simultane Threads auszuführen. Die Anzahl an logischen Threads, die von der Grafikausführungseinheit 508 ausgeführt werden können, ist nicht auf die Anzahl an Hardware-Threads beschränkt, und mehrere logische Threads können jedem Hardware-Thread zugewiesen werden.
In einer Ausführungsform kann die Grafikausführungseinheit 508 mehrere Anweisungen zusammen ausgeben, die jeweils unterschiedliche Anweisungen sein können. Der Thread-Arbiter 522 des Grafikausführungseinheiten-Threads 508 kann die Anweisungen zur Ausführung an eine der Folgenden verteilen, die Sendeeinheit 530, die Verzweigungseinheit 532 oder SIMD-FPU(s) 534. Jeder Ausführungs-Thread kann auf 128 Universalregister im GRF 524 zugreifen, wobei jedes Register 32 Bytes speichern kann, zugriffsfähig als ein SIMD 8-Element-Vektor der 32-Bit-Datenelemente. In einer Ausführungsform hat jeder Ausführungseinheiten-Thread Zugriff auf 4 kBytes im GRF 524, obwohl Ausführungsformen nicht darauf beschränkt sind, und größere oder weniger Registerressourcen können in anderen Ausführungsformen bereitgestellt werden. In einer Ausführungsform ist die Grafikverarbeitungseinheit 508 in sieben Hardware-Threads partitioniert, die unabhängig Rechenoperationen durchführen können, obwohl die Anzahl an Threads je Ausführungseinheit auch gemäß Ausführungsformen variieren kann. Zum Beispiel werden in einer Ausführungsform bis zu 16 Hardware-Threads unterstützt. In einer Ausführungsform, in der sieben Threads auf 4 kBytes zugreifen können, kann das GRF 524 insgesamt 28 kBytes speichern. Wenn 16 Threads auf 4 kBytes zugreifen können, kann das GRF 524 insgesamt 64 kBytes speichern. Flexible Adressiermodi können gestatten, dass Register zusammen adressiert werden, um effektiv breitere Register zu bilden oder um rechteckige schrittweise Blockdatenstrukturen darzustellen.
In einer Ausführungsform werden Speicheroperationen, Sampler-Operationen und andere Systemkommunikationen mit längerer Latenz über „Send“-Anweisungen verteilt, die von der Nachrichten übermittelnden Sendeeinheit 530 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 532 verteilt, um SIMD-Divergenz und schließlich Konvergenz zu ermöglichen.
In einer Ausführungsform enthält die Grafikausführungseinheit 508 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 534 zum Durchführen von Gleitkommaoperationen. In einer Ausführungsform unterstützt/unterstützen die FPU(s) 534 auch Integer-Berechnung. In einer Ausführungsform können die FPU(s) 534 bis zur Anzahl Man 32-Bit-Gleitkomma (oder Integer)-Operationen SIMD-ausführen oder bis zu 2M 16-Bit-Integer- oder 16-Bit-Gleitkommaoperationen SIMD-ausführen. In einer Ausführungsform stellt wenigstens eine der FPU(s) erweiterte Mathematikfähigkeit bereit, um Mathematikfunktionen mit hohem Durchsatz und doppelt genaue 54-Bit-Gleitkommafunktionen zu unterstützen. In einigen Ausführungsformen ist auch ein Satz 8-Bit-Integer-SIMD-ALUs 535 vorhanden und kann insbesondere zum Durchführen von Operation optimiert sein, die mit Berechnungen für maschinelles Lernen verknüpft sind.
In einer Ausführungsform können Arrays von mehreren Instanzen der Grafikausführungseinheit 508 in einer Grafik-Subkerngruppierung (z. B. einem Sub-Slice) instanziiert werden. Für die Skalierbarkeit können Produktarchitekten die exakte Anzahl an Ausführungseinheiten je Subkerngruppierung wählen. In einer Ausführungsform kann die Ausführungseinheit 508 Anweisungen über mehrere Ausführungskanäle ausführen. In einer weiteren Ausführungsform wird jeder auf der Grafikausführungseinheit 508 ausgeführte Thread auf einem anderen Kanal ausgeführt.
Die 6 veranschaulicht eine zusätzliche Ausführungseinheit 600 gemäß einer Ausführungsform. Die Ausführungseinheit 600 kann eine rechenoptimierte Ausführungseinheit sein, wie zum Beispiel zur Verwendung in einer Rechen-Engine-Kachel 340A - 340D, wie in der 3C, ist aber nicht darauf beschränkt. Varianten der Ausführungseinheit 600 können auch in einer Grafik-Engine-Kachel 310A - 310D verwendet werden, wie in der 3B. In einer Ausführungsform enthält die Ausführungseinheit 600 eine Thread-Steuereinheit 601, eine Thread-Zustandseinheit 602, eine Anweisungsabruf-/-vorabrufeinheit 603 und eine Anweisungsdecodiereinheit 604. Die Ausführungseinheit 600 enthält zusätzlich eine Registerdatei 606, die Register speichert, die Hardware-Threads innerhalb der Ausführungseinheit zugewiesen werden können. Die Ausführungseinheit 600 enthält zusätzlich eine Sendeeinheit 607 und eine Verzweigungseinheit 608. In einer Ausführungsform können die Sendeeinheit 607 und die Verzweigungseinheit 608 ähnlich wie die Sendeeinheit 530 und eine Verzweigungseinheit 532 der Grafikausführungseinheit 508 der 5B arbeiten.
Die Ausführungseinheit 600 enthält auch eine Recheneinheit 610, die mehrere unterschiedliche Typen von Funktionseinheiten enthält. In einer Ausführungsform enthält die Recheneinheit 610 eine ALU-Einheit 611, die ein Array von Arithmetik-Logik-Einheiten enthält. Die ALU-Einheit 611 kann dazu ausgebildet sein, 64-Bit-, 32-Bit- und 16-Bit-Integer- und -Gleitkommaoperationen durchzuführen. Integer- und Gleitkommaoperationen können simultan durchgeführt werden. Die Recheneinheit 610 kann auch ein systolisches Array 612 und eine Mathematikeinheit 613 enthalten. Das systolische Array 612 enthält ein W breites und D tiefes Netzwerk von Datenverarbeitungseinheiten, die verwendet werden können, um Vektor- oder andere in den Daten parallele Operationen auf eine systolische Weise durchzuführen. In einer Ausführungsform kann das systolische Array 612 dazu ausgebildet sein, Matrizenoperationen durchzuführen, wie zum Beispiel Matrizen-Skalarprodukt-Operationen. In einer Ausführungsform unterstützt das systolische Array 612 16-Bit-Gleitkommaoperationen sowie 8-Bit- und 4-Bit-Integer-Operationen. In einer Ausführungsform kann das systolische Array 612 dazu ausgebildet sein, maschinelle Lemoperationen zu beschleunigen. In solchen Ausführungsformen kann das systolische Array 612 mit Unterstützung für das Bfloat 16-Bit-Gleikommaformat ausgebildet sein. In einer Ausführungsform kann eine Mathematikeinheit 613 enthalten sein, um einen spezifischen Subsatz mathematischer Operationen auf eine effiziente Weise und mit geringerer Leistung als die ALU-Einheit 611 durchzuführen. Die Mathematikeinheit 613 kann eine Variante von Mathematiklogik enthalten, die in gemeinsam genutzter Funktionslogik einer Grafikverarbeitungs-Engine zu finden ist, die von anderen Ausführungsformen bereitgestellt wird (z. B. die Mathematiklogik 422 der gemeinsam genutzten Funktionslogik 420 der 4). In einer Ausführungsform kann die Mathematikeinheit 613 dazu ausgebildet sein, 32-Bit- und 64-Bit-Gleitkommaoperationen durchzuführen.
Die Thread-Steuereinheit 601 enthält Logik zum Steuern der Ausführung von Threads in der Ausführungseinheit. Die Thread-Steuereinheit 601 kann Thread-Arbitrierlogik für das Starten, Stoppen und die Präemption der Ausführung von Threads in der Ausführungseinheit 600 enthalten. Die Thread-Zustandseinheit 602 kann verwendet werden, um den Thread-Zustand für Threads zu speichern, die zum Ausführen auf der Ausführungseinheit 600 zugewiesen sind. Das Speichern des Thread-Zustands in der Ausführungseinheit 600 ermöglicht die schnelle Präemption von Threads, wenn diese Threads gesperrt oder untätig werden. Die Anweisungsabruf-/-vorabrufeinheit 603 kann Anweisungen aus einem Anweisungs-Cache der Ausführungslogik höherer Level abrufen (z. B. dem Anweisungs-Cache 506, wie in der 5A). Die Anweisungsabruf-/-vorabrufeinheit 603 kann auch Vorabrufanforderungen für Anweisungen, die in den Anweisungs-Cache geladen werden sollen, basierend auf einer Analyse der aktuell ausgeführten Threads ausgeben. Die Anweisungsdecodiereinheit 604 kann verwendet werden, um Anweisungen zu decodieren, die durch die Recheneinheiten ausgeführt werden sollen. In einer Ausführungsform kann die Anweisungsdecodiereinheit 604 als ein sekundärer Decodierer verwendet werden, um komplexe Anweisungen in einzelne Mikrooperationen zu decodieren.
Die Ausführungseinheit 600 enthält zusätzlich eine Registerdatei 606, die von Hardware-Threads verwendet werden kann, die auf der Ausführungseinheit 600 ausgeführt werden. Die Register in der Registerdatei 606 können über die Logik aufgeteilt werden, die verwendet wird, um mehrere simultane Threads in der Recheneinheit 610 der Ausführungseinheit 600 auszuführen. Die Anzahl an logischen Threads, die von der Grafikausführungseinheit 600 ausgeführt werden können, ist nicht auf die Anzahl an Hardware-Threads beschränkt, und mehrere logische Threads können jedem Hardware-Thread zugewiesen werden. Die Größe der Registerdatei 606 kann über Ausführungsformen variieren, basierend auf der Anzahl an unterstützten Hardware-Threads. In einer Ausführungsform kann Registerumbenennung verwendet werden, um Register dynamisch Hardware-Threads zuzuweisen.
Die 7 ist ein Blockdiagramm, das ein Grafikprozessor-Anweisungsformat 700 gemäß einigen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Anweisungssatz, der Anweisungen in mehreren Formaten aufweist. Die Kästchen mit durchgezogenen Linien veranschaulichen die Komponenten, die im Allgemeinen in einer Ausführungseinheitenanweisung enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einem Subsatz der Anweisungen enthalten sind. In einigen Ausführungsformen ist das beschriebene und veranschaulichte Anweisungsformat 700 Makroanweisungen insofern, als sie Anweisungen sind, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die sich aus Anweisungsdecodierung ergeben, sobald die Anweisung verarbeitet wird.
In einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten Anweisungen nativ in einem 128-Bit-Anweisungsformat 710. Ein verdichtetes 64-Bit-Anweisungsformat 730 ist für einige Anweisungen basierend auf der ausgewählten Anweisung, den Anweisungsoptionen und der Anzahl an Operanden verfügbar. Das native 128-Bit-Anweisungsformat 710 stellt Zugriff auf alle Anweisungsoptionen bereit, während einige Optionen und Operationen im 64-Bit-Format 730 eingeschränkt sind. Die im 64-Bit-Format 730 verfügbaren nativen Anweisungen variieren je nach Ausführungsform. In einigen Ausführungsformen wird die Anweisung zum Teil unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 verdichtet. Die Ausführungseinheiten-Hardware verweist basierend auf den Indexwerten auf einen Satz Verdichtungstabellen und verwendet die Verdichtungstabellenausgaben, um eine native Anweisung im 128-Bit-Anweisungsformat 710 umzubauen. Andere Größen und Formate von Anweisungen können verwendet werden.
Für jedes Format definiert der Anweisungs-Opcode 712 die Operation, die die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über mehrere Datenelemente jedes Operanden aus. Zum Beispiel führt die Ausführungseinheit als Reaktion auf eine Addier-Anweisung eine simultane Addier-Operation über jeden Farbkanal durch, der ein Texturelement oder Bildelement darstellt. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden durch. In einigen Ausführungsformen aktiviert das Anweisungssteuerfeld 714 die Steuerung über gewisse Ausführungsoptionen, wie zum Beispiel Kanalauswahl (z. B. Prädikation) und Datenkanalreihenfolge (z. B. Swizzle). Für Anweisungen im 128-Bit-Anweisungsformat 710 begrenzt ein Exec-Size-Feld 716 die Anzahl an Datenkanälen, die parallel ausgeführt werden. In einigen Ausführungsformen ist das Exec-Size-Feld 716 nicht für die Verwendung im verdichteten 64-Bit-Anweisungsformat 730 verfügbar.
Einige Ausführungseinheitenanweisungen weisen bis zu drei Operanden auf, einschließlich zwei Quelloperanden, SRC0 720, SRC1 722, und ein Ziel 718. In einigen Ausführungsformen unterstützen die Ausführungseinheiten duale Zielanweisungen, wobei eines der Ziele implizit ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden (z. B. SRC2 724) aufweisen, wobei der Anweisungs-Opcode 712 die Anzahl an Quelloperanden bestimmt. Ein letzter Quelloperand der Anweisung kann ein Immediate (z. B. fest programmierter) Wert sein, der mit der Anweisung übermittelt wird.
In einigen Ausführungsformen enthält das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressiermodusfeld 726, das zum Beispiel spezifiziert, ob der direkte Registeradressiermodus oder der indirekte Registeradressiermodus verwendet wird. Wenn der direkte Registeradressiermodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt von Bits in der Anweisung bereitgestellt.
In einigen Ausführungsformen enthält das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressiermodusfeld 726, das einen Adressiermodus 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 1-Byte-ausgerichteten Zugriffsmodus, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Zum Beispiel kann die Anweisung in einem ersten Modus byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und in einem zweiten Modus kann die Anweisung 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressiermodusabschnitt des Zugriffs-/Adressiermodusfelds 726, ob die Anweisung direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressiermodus verwendet wird, stellen Bits in der Anweisung die Registeradresse eines oder mehrerer Operanden direkt bereit. Wenn der indirekte Registeradressiermodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und Adress-Immediate-Feld in der Anweisung berechnet werden.
In einigen Ausführungsformen werden Anweisungen basierend auf Bit-Feldern des Opcodes 712 gruppiert, um Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit-Opcode gestatten die Bits 4, 5 und 6 der Ausführungseinheit, den Opcode-Typ zu bestimmen. Die genaue gezeigte Opcode-Gruppierung ist lediglich ein Beispiel. In einigen Ausführungsformen enthält eine Bewegungs- und Logik-Opcode-Gruppe 742 Datenbewegungs- und Logikanweisungen (z. B. bewegen (mov), vergleichen (cmp)). In einigen Ausführungsformen nutzt die Bewegungs- und Logik-Gruppe 742 die fünf höchstwertigsten Bits (Most Significant Bits, MSB), wobei Bewegen (mov)-Anweisungen in der Form von 0000xxxxb und Logikanweisungen in der Form von 0001xxxxb vorliegen. Eine Flusssteuerungs-Anweisungsgruppe 744 (z. B. aufrufen (call), springen (jmp)) enthält Anweisungen in der Form von 0010xxxxb (z. B. 0x20). Eine sonstige Anweisungsgruppe 746 enthält eine Mischung von Anweisungen, einschließlich Synchronisierungsanweisungen (z. B. warten (wait), senden (send)) in der Form von 0011xxxxb (z. B. 0x30). Eine Parallel-Mathematik-Anweisungsgruppe 748 enthält komponentenweise Arithmetikanweisungen (z. B. addieren (add), multiplizieren (mul)) in der Form von 0100xxxxb (z. B. 0x40). Die Parallel-Mathematik-Gruppe 748 führt Arithmetikoperationen parallel über Datenkanäle durch. Die Vektormathematikgruppe 750 enthält Arithmetikanweisungen (z. B. dp4) in der Form von 0101xxxxb (z. B. 0x50).
Die Vektor-Mathematikgruppe führt Arithmetik durch, wie zum Beispiel Skalarproduktberechnungen auf Vektoroperanden. Der veranschaulichte Opcode-Decodierer 740 kann in einer Ausführungsform verwendet werden, um zu bestimmen, welcher Abschnitt einer Ausführungseinheit verwendet wird, um eine decodierte Anweisung auszuführen. Zum Beispiel können einige Anweisungen als systolische Anweisungen festgelegt sein, die von einem systolischen Array durchgeführt werden. Andere Anweisungen, wie zum Beispiel Strahlverfolgungsanweisungen (nicht dargestellt) können zu einem Strahlverfolgungskern oder Strahlverfolgungslogik in einem Slice oder einer Partition der Ausführungslogik geleitet werden.
Grafik-Pipeline
Die 8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente der 8, die die gleichen Bezugsnummern (oder -bezeichnungen) wie die Elemente irgendeiner anderen Figur aufweisen, können auf irgendeine Art und Weise, die der hier an anderer Stelle beschriebenen ähnelt, arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Geometrie-Pipeline 820, eine Medien-Pipeline 830, eine Anzeige-Engine 840, Thread-Ausführungslogik 850 und eine Render-Ausgabe-Pipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor in einem Mehrkernverarbeitungssystem, das einen oder mehrere universelle Verarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreibvorgänge auf einem oder mehreren Steuerregistern (nicht dargestellt) 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 zum Beispiel anderen Grafikprozessoren oder universellen Prozessoren. Befehle aus der Ringverschaltung 802 werden von einem Befehls-Streamer 803 interpretiert, der einzelnen Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 Anweisungen zuführt.
In einigen Ausführungsformen lenkt der Befehls-Streamer 803 die Operation eines Vertex-Fetchers 805, der Vertexdaten aus dem Speicher liest, und führt Vertexverarbeitungsbefehle aus, die vom Befehls-Streamer 803 bereitgestellt werden. In einigen Ausführungsformen stellt der Vertex-Fetcher 805 Vertexdaten für einen Vertex-Shader 807 bereit, der Koordinatenraumtransformation und Beleuchtungsoperationen auf jeden Vertex durchführt. In einigen Ausführungsformen führen der Vertex-Fetcher 805 und der Vertex-Shader 807 Vertexverarbeitungsanweisungen durch Verteilen von Ausführungs-Threads an Ausführungseinheiten 852A - 852B über einen Thread-Dispatcher 831 aus.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A - 852B ein Array von Vektorprozessoren mit einem Anweisungssatz zum Durchführen von Grafik- und Medienoperationen. In einigen Ausführungsformen weisen die Ausführungseinheiten 852A - 852B einen angeschlossenen L1-Cache 851 auf, der für jedes Array spezifisch ist oder von den Arrays gemeinsam genutzt wird. Der Cache kann als ein Daten-Cache, ein Anweisungs-Cache oder ein einzelner Cache, der so partitioniert ist, dass er Daten und Anweisungen in unterschiedlichen Partitionen enthält, ausgebildet sein.
In einigen Ausführungsformen enthält die Geometrie-Pipeline 820 Tessellationskomponenten, um hardwarebeschleunigte Tessellation von 3D-Objekten durchzuführen. In einigen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tessellationsoperationen. Ein programmierbarer Domain-Shader 817 stellt Back-End-Auswertung der Tessellationsausgabe bereit. Ein Tesselator 813 arbeitet an der Lenkung des Hull-Shaders 811 und enthält Speziallogik, um einen Satz detaillierte geometrische Objekte basierend auf einem groben geometrischen Modell, das der Geometrie-Pipeline 820 als Eingabe bereitgestellt wird, zu generieren. Falls keine Tessellation verwendet wird, können in einigen Ausführungsformen Tessellationskomponenten (z. B. der Hull-Shader 811, der Tesselator 813 und der Domain-Shader 817) übersprungen werden.
In einigen Ausführungsformen können vollständige geometrische Objekte von einem Geometry-Shader 819 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 852A - 852B verteilt werden, oder können direkt zum Clipper 829 weiterlaufen. In einigen Ausführungsformen arbeitet der Geometry-Shader auf ganzen geometrischen Objekten, statt auf Vertices oder Teilflächen von Vertices wie in vorherigen Stufen der Grafik-Pipeline. Falls die Tessellation deaktiviert ist, empfängt der Geometry-Shader 819 Eingaben vom Vertex-Shader 807. In einigen Ausführungsformen ist der Geometry-Shader 819 durch ein Geometry-Shader-Programm programmierbar, damit er Geometrie-Tessellation durchführt, falls die Tessellationseinheiten deaktiviert sind.
Vor der Rasterisierung verarbeitet ein Clipper 829 Vertexdaten. Der Clipper 829 kann ein Festfunktions-Clipper oder ein programmierbarer Clipper mit Clipp- und Geometry-Shader-Funktionen sein. In einigen Ausführungsformen verteilt eine Rasterisierer- und Tiefenprüfkomponente 873 in der Render-Ausgabe-Pipeline 870 Pixel-Shader, um die geometrischen Objekte in Darstellungen je Pixel umzuwandeln. In einigen Ausführungsformen ist Pixel-Shader-Logik in der Thread-Ausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung die Rasterisierer- und Tiefenprüfkomponente 873 überspringen und auf nicht rasterisierte Vertexdaten über eine Stream-Out-Einheit 823 zugreifen.
Der Grafikprozessor 800 weist einen Verschaltungsbus, Verschaltungsstruktur oder irgendeinen anderen Verschaltungsmechanismus auf, der Daten- und Nachrichtenübermittlung zwischen den Hauptkomponenten des Prozessors gestattet. In einigen Ausführungsformen sind die Ausführungseinheiten 852A - 852B und die verknüpften Logik-Einheiten (z. B. L1-Cache 851, der Sampler 854, der Textur-Cache 858 usw.) über einen Daten-Port 856 verschaltet, um Speicherzugriff durchzuführen und mit Render-Ausgabe-Pipeline-Komponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen haben der Sampler 854, die Caches 851, 858 und die Ausführungseinheiten 852A - 852B jeweils separate Speicherzugriffspfade. In einer Ausführungsform kann der Textur-Cache 858 auch als ein Sampler-Cache ausgebildet sein.
In einigen Ausführungsformen enthält die Render-Ausgabe-Pipeline 870 eine Rasterisierer- und Tiefenprüfkomponente 873, die Objekte auf Vertexbasis in eine verknüpfte Darstellung auf Pixelbasis umwandelt. In einigen Ausführungsformen enthält die Rasterisiererlogik eine Fenster-/Maskierereinheit, um Festfunktions-Dreiecks- und -Linienrasterisierung durchzuführen. Ein verknüpfter Render-Cache 878 und Tiefen-Cache 879 sind in einigen Ausführungsformen ebenfalls verfügbar. Eine Pixeloperationskomponente 877 führt Operationen auf Pixelbasis auf den Daten durch, obwohl in einigen Instanzen Pixeloperationen, die mit 2D-Operationen verknüpft sind (z. B. Bit-Block-Bildtransfers mit Blending), von der 2D-Engine 841 durchgeführt werden oder zum Anzeigezeitpunkt vom Anzeige-Controller 843 unter Verwendung von Überlagerungsanzeigeebenen ersetzt werden. In einigen Ausführungsformen ist für alle Grafikkomponenten ein gemeinsam genutzter L3-Cache 875 verfügbar, was das gemeinsame Nutzen von Daten ohne die Verwendung des Hauptsystemspeichers gestattet.
In einigen Ausführungsformen enthält die Grafikprozessor-Medien-Pipeline 830 eine Medien-Engine 837 und ein Video-Frontend 834. In einigen Ausführungsformen empfängt das Video-Frontend 834 Pipeline-Befehle aus dem Befehls-Streamer 803. In einigen Ausführungsformen enthält die Medien-Pipeline 830 einen separaten Befehls-Streamer. In einigen Ausführungsformen verarbeitet das Video-Frontend 834 Medienbefehle, bevor der Befehl an die Medien-Engine 837 gesendet wird. In einigen Ausführungsformen enthält die Medien-Engine 837 Thread-Spawning-Funktionalität, um Threads zur Verteilung an die Thread-Ausführungslogik 850 über den Thread-Dispatcher 831 zu spawnen.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Anzeige-Engine 840. In einigen Ausführungsformen ist die Anzeige-Engine 840 extern zum Prozessor 800 und mit dem Grafikprozessor über die Ringverschaltung 802 oder irgendeinen anderen Verschaltungsbus oder irgendeine andere Struktur gekoppelt. In einigen Ausführungsformen enthält die Anzeige-Engine 840 eine 2D-Engine 841 und einen Anzeige-Controller 843. In einigen Ausführungsformen enthält die Anzeige-Engine 840 Speziallogik, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen koppelt der Anzeige-Controller 843 mit einer Anzeigeeinrichtung (nicht dargestellt), die eine in das System integrierte Anzeigeeinrichtung, wie in einem Laptop-Computer, oder eine externe Anzeigeeinrichtung, die über einen Anzeigeeinrichtungsverbinder angeschlossen wird, sein kann.
In einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 dazu konfigurierbar, Operationen auf Basis von mehreren Grafik- und Medienprogrammierschnittstellen durchzuführen und sind nicht spezifisch für irgendeine Anwendungsprogrammierschnittstelle (API). In einigen Ausführungsformen übersetzt Treiber-Software für den Grafikprozessor API-Aufrufe, die für eine spezielle Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die vom 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 die Vulkan-Grafik- und -Rechen-API, alle von der Khronos Group, bereitgestellt. In einigen Ausführungsformen kann auch Unterstützung für die Direct3D-Bibliothek der Microsoft Corporation bereitgestellt sein. In einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Unterstützung kann ebenfalls für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde ebenfalls unterstützt, falls ein Mapping von der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors vorgenommen werden kann.
Grafik-Pipeline-Programmierung
Die 9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat 900 gemäß einigen Ausführungsformen veranschaulicht. Die 9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 910 gemäß einer Ausführungsform veranschaulicht. Die Kästchen mit durchgezogenen Linien in der 9A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einem Subsatz der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessorbefehlsformat 900 der 9A enthält Datenfelder zum Identifizieren eines Clients 902, eines Befehlsoperationscodes (Opcode) 904 und der Daten 906 für den Befehl. Ein Sub-Opcode 905 und eine Befehlsgröße 908 sind ebenfalls in einigen Befehlen enthalten.
In einigen Ausführungsformen spezifiziert der Client 902 die Client-Einheit der Grafikeinrichtung, die die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessor-Befehls-Parser das Client-Feld jedes Befehls, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten an die geeignete Client-Einheit zu leiten. In einigen Ausführungsformen enthalten die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Client-Einheit weist eine entsprechende Verarbeitungs-Pipeline auf, die die Befehle verarbeitet. Sobald der Befehl von der Client-Einheit empfangen wird, liest die Client-Einheit den Opcode 904 und, falls vorhanden, den Sub-Opcode 905, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Informationen im 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 Befehls-Parser automatisch die Größe wenigstens einiger der Befehle basierend auf dem Befehls-Opcode. In einigen Ausführungsformen werden Befehle über Vielfache eines Doppelwortes ausgerichtet. Andere Befehlsformate können verwendet werden.
Das Flussdiagramm in der 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 wird lediglich als Beispiel gezeigt und beschrieben, weil Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlssequenz beschränkt sind. Außerdem können die Befehle als Batch von Befehlen in einer Befehlssequenz ausgegeben werden, so dass der Grafikprozessor die Sequenz von Befehlen in wenigstens teilweiser Gleichzeitigkeit verarbeiten wird.
In einigen Ausführungsformen kann die Grafikprozessorbefehlssequenz 910 mit einem Pipeline-Flush-Befehl 912 beginnen, um zu bewirken, dass jede aktive Grafik-Pipeline die aktuell für die Pipeline anhängigen Befehle abschließt. In einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Der Pipeline-Flush wird durchgeführt, um zu bewirken, dass die aktive Grafik-Pipeline alle anhängigen Befehle abschließt. Als Reaktion auf einen Pipeline-Flush wird der Befehls-Parser für den Grafikprozessor die Befehlsverarbeitung vorübergehend anhalten, bis die aktiven Zeichnungs-Engines anhängige Operationen abgeschlossen und die relevanten Lese-Caches ungültig gemacht sind. Optional können irgendwelche Daten im Render-Cache, die als ,schmutzig' markiert sind, zum Speicher entleert werden. In einigen Ausführungsformen kann der Pipeline-Flush-Befehl 912 zur Pipeline-Synchronisation verwendet werden oder bevor der Grafikprozessor in einen Niedrigleistungszustand gebracht wird.
In einigen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. In einigen Ausführungsformen ist ein Pipeline-Auswahlbefehl 913 nur einmal in einem Ausführungskontext erforderlich, bevor Pipeline-Befehle ausgegeben werden, es sei denn, der Kontext ist das Ausgeben von Befehlen für beide Pipelines. In einigen Ausführungsformen ist ein Pipeline-Flush-Befehl 912 unmittelbar vor einer Pipeline-Umschaltung über den Pipeline-Auswahlbefehl 913 erforderlich.
In einigen Ausführungsformen konfiguriert ein Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für die Operation und wird verwendet, um die 3D-Pipeline 922 und die Medien-Pipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Pipeline-Steuerbefehl 914 den Pipeline-Zustand für die aktive Pipeline. In einer Ausführungsform wird der Pipeline-Steuerbefehl 914 zur Pipeline-Synchronisation und zum Löschen von Daten aus einem oder mehreren Cache-Speichern in der aktiven Pipeline verwendet, bevor ein Batch von Befehlen verarbeitet wird.
In einigen Ausführungsformen werden die Rückgabepufferzustandsbefehle 916 verwendet, um einen Satz Rückgabepuffer für jeweilige Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen während der Verarbeitung Zwischendaten schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückgabepuffer, um Ausgangsdaten zu speichern und um Thread-übergreifende Kommunikation durchzuführen. In einigen Ausführungsformen enthält der Rückgabepufferzustand 916 das Auswählen der Größe und Anzahl an Rückgabepuffern, die für einen Satz Pipeline-Operationen verwendet werden sollen.
Die übrigen Befehle in der Befehlssequenz unterscheiden sich basierend auf der für Operationen aktiven Pipeline. Basierend auf einer Pipeline-Bestimmung 920 wird die Befehlsfolge auf die 3D-Pipeline 922, beginnend mit dem 3D-Pipeline-Zustand 930, oder die Medien-Pipeline 924, beginnend mit dem Medien-Pipeline-Zustand 940, zugeschnitten.
Die Befehle, um den 3D-Pipeline-Zustand 930 zu konfigurieren, beinhalten 3D-Zustandseinstellbefehle für den Vertexpufferzustand, den Vertexelementzustand, den Konstantfarbzustand, den Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitivenbefehle verarbeitet werden. Die Werte dieser Befehle werden wenigstens zum Teil basierend auf der speziellen 3D-API, die verwendet wird, bestimmt. In einigen Ausführungsformen sind Befehle für 3D-Pipeline-Zustände 930 auch in der Lage, gewisse Pipeline-Elemente selektiv zu deaktivieren oder zu überspringen, falls diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird der Befehl für 3D-Primitive 932 verwendet, um 3D-Primitive abzugeben, die von der 3D-Pipeline verarbeitet werden sollen. Befehle und verknüpfte Parameter, die über Befehle für 3D-Primitive 932 an den Grafikprozessor übermittelt werden, werden an die Vertexabruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Fetch-Funktion verwendet den Befehl für 3D-Primitive 932, um Vertexdatenstrukturen zu generieren. Die Vertexdatenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der Befehl für 3D-Primitive 932 verwendet, um Vertexoperationen auf 3D-Primitiven über Vertex-Shader durchzuführen. Um Vertex-Shader zu verarbeiten, verteilt die 3D-Pipeline 922 Shader-Ausführungs-Threads an Grafikprozessor- Ausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Befehl Ausführung 934 oder ein Ereignis getriggert. In einigen Ausführungsformen triggert ein Registerschreibvorgang die Befehlsausführung. In einigen Ausführungsformen wird die Ausführung über einen ,Go'- oder ,Kick'-Befehl in der Befehlssequenz getriggert. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipeline-Synchronisierungsbefehls getriggert, um die Befehlssequenz durch die Grafik-Pipeline zu entleeren. Die 3D-Pipeline wird Geometrieverarbeitung für die 3D-Primitiven durchführen. Sobald die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte rasterisiert, und die Pixel-Engine färbt die resultierenden Pixel. Zusätzliche Befehle zum Steuern von Pixel-Shading- und Pixel-Backend-Operationen können für diese Operationen ebenfalls enthalten sein.
In einigen Ausführungsformen folgt die Grafikprozessor-Befehlssequenz 910 dem Weg der Medien-Pipeline 924, wenn Medienoperationen durchgeführt werden. Im Allgemeinen hängt die spezifische Verwendung und Weise der Programmierung für die Medien-Pipeline 924 von den durchzuführenden Medien- oder Rechenoperationen ab. Spezifische Mediendecodieroperationen können während der Mediendecodierung an die Medien-Pipeline abgegeben werden. In einigen Ausführungsformen kann die Medien-Pipeline auch übersprungen werden, und Mediendecodierung kann im Ganzen oder zum Teil unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren universellen Verarbeitungskernen bereitgestellt werden. In einer Ausführungsform enthält die Medien-Pipeline auch Elemente für Operationen der universellen Grafikprozessoreinheit (GPGPU), wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Rechen-Shader-Programmen durchzuführen, die nicht explizit mit dem Rendering von Grafikprimitiven in Beziehung stehen.
In einigen Ausführungsformen ist die Medien-Pipeline 924 auf eine ähnliche Weise wie die 3D-Pipeline 922 ausgebildet. Ein Befehlssatz zum Konfigurieren des Medien-Pipeline-Zustands 940 wird vor den Medienobjektbefehlen 942 in eine Befehlswarteschlange verteilt oder platziert. In einigen Ausführungsformen enthalten Befehle für den Medien-Pipeline-Zustand 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medienobjekte verwendet werden. Dies schließt Daten zum Konfigurieren der Videodecodier- und Videocodierlogik in der Medien-Pipeline ein, wie zum Beispiel das Codier- oder Decodierformat. In einigen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Zustand 940 auch die Verwendung eines oder mehrerer Zeiger auf „indirekte“ Zustandselemente, die einen Stapel von Zustandseinstellungen enthalten.
In einigen Ausführungsformen führen Medienobjektbefehle 942 Zeiger auf Medienobjekte zur Verarbeitung durch die Medien-Pipeline zu. Zu den Medienobjekten zählen Speicherpuffer, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medien-Pipeline-Zustände valide sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Sobald der Pipeline-Zustand konfiguriert ist und Medienobjektbefehle 942 in der Warteschlange eingetragen sind, wird die Medien-Pipeline 924 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (z. B. einen Registerschreibvorgang) getriggert. Die Ausgabe aus der Medien-Pipeline 924 kann dann durch Operationen nachbearbeitet werden, die von der 3D-Pipeline 922 oder der Medien-Pipeline 924 bereitgestellt werden. In einigen Ausführungsformen werden GPGPU-Operationen in einer ähnlichen Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafik-Software-Architektur
Die 10 veranschaulicht eine beispielhafte Grafik-Software-Architektur für ein Datenverarbeitungssystem 1000 gemäß einigen Ausführungsformen. In einigen Ausführungsformen enthält die Software-Architektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und wenigstens einen Prozessor 1030. In einigen Ausführungsformen enthält der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere universelle Prozessorkern(e) 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 arbeiten jeweils im Systemspeicher 1050 des Datenverarbeitungssystems.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 eines oder mehrere Shader-Programme, die Shader-Anweisungen 1012 enthalten. Die Shader-Sprachanweisungen können in einer Shader-Hochsprache vorliegen, wie zum Beispiel der High-Level Shader Language (HLSL) von Direct3D, der OpenGL Shader Language (GLSL) und so weiter. Die Anwendung enthält auch ausführbare Anweisungen 1014 in einer Maschinensprache, die zur Ausführung durch den universellen Prozessorkern 1034 geeignet sind. Die Anwendung enthält auch Grafikobjekte 1016, die durch Vertexdaten definiert werden.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows®-Betriebssystem von der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein UNIX-ähnliches Open-Source-Betriebssystem, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022 unterstützen, wie zum Beispiel die Direct3D API, die OpenGL API oder die Vulkan API. Wenn die Direct3D API verwendet wird, verwendet das Betriebssystem 1020 einen Frontend-Shader-Kompilierer 1024, um alle Shader-Anweisungen 1012 in HLSL in eine Shader-Sprache auf niedrigerem Level zu kompilieren. Die Kompilierung kann eine Just-in-Time (JIT)-Kompilierung sein, oder die Anwendung kann Shader-Präkompilierung durchführen. In einigen Ausführungsformen werden die Shader höherer Level während der Kompilierung der 3D-Grafikanwendung 1010 in Shader niedrigerer Level kompiliert. In einigen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform bereitgestellt, wie zum Beispiel in einer Version der Standard Portable Intermediate Representation (SPIR), die von der Vulkan-API verwendet wird.
In einigen Ausführungsformen enthält der Anwendermodus-Grafiktreiber 1026 einen Backend-Shader-Kompilierer 1027, um die Shader-Anweisungen 1012 in eine hardwarespezifische Darstellung umzuwandeln. Wenn die OpenGL-API im Einsatz ist, werden Shader-Anweisungen 1012 in der GLSL-Hochsprache an einen Anwendermodus-Grafiktreiber 1026 zur Kompilierung übermittelt. In einigen Ausführungsformen verwendet der Anwendermodus-Grafiktreiber 1026 Betriebssystem-Kernelmodus-Funktionen 1028, um mit einem Kernelmodus-Grafiktreiber 1029 zu kommunizieren. In einigen Ausführungsformen kommuniziert der Kernelmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen zu verteilen.
IP-Kern-Implementierungen
Einer oder mehrere Aspekte wenigstens einer Ausführungsform können durch repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik in einer integrierten Schaltung, wie zum Beispiel einem Prozessor, darstellt und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Anweisungen enthalten, die verschiedene Logik im Prozessor darstellen. Wenn sie von einer Maschine gelesen werden, können die Anweisungen bewirken, dass die Maschine Logik zum Durchführen der hier beschriebenen Techniken erstellt. Solche Darstellungen, bekannt als „IP-Kerne“, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem dinghaften maschinenlesbaren Medium als ein Hardware-Modell gespeichert sein können, das die Struktur der integrierten Schaltung beschreibt. Das Hardware-Modell kann verschiedenen Kunden oder Herstellungsanlagen übergeben werden, die das Hardware-Modell auf Herstellungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann so hergestellt sein, dass die Schaltung Operationen durchführt, die in Verknüpfung mit allen hier beschriebenen Ausführungsformen beschrieben werden.
Die 11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100 veranschaulicht, das zur Herstellung einer integrierten Schaltung zur Durchführung von Operationen gemäß einer Ausführungsform verwendet werden kann. Das IP-Kern-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs zu erzeugen, die in ein größeres Design integriert oder verwendet werden können, um eine gesamte integrierte Schaltung (z. B. eine integrierte SOC-Schaltung) zu erstellen. Eine Design-Vorrichtung 1130 kann eine Software-Simulation 1110 eines IP-Kern-Designs in einer Programmierhochsprache (z. B. C/C++) generieren. Die Software-Simulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu entwerfen, zu testen und zu überprüfen. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Zeitsimulationen beinhalten. Ein Registertransferebenen- (Register Transfer Level, RTL)-Design 1115 kann dann aus dem Simulationsmodell 1112 erzeugt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, das den Fluss digitaler Signale zwischen Hardware-Registern modelliert, einschließlich der verknüpften Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs auf niedrigeren Leveln auf dem Logiklevel oder dem Transistorlevel erzeugt, entworfen oder synthetisiert werden. Somit können die speziellen Details des anfänglichen Designs und der Simulation variieren.
Das RTL-Design 1115 oder ein Äquivalent kann des Weiteren durch die Design-Vorrichtung in ein Hardware-Modell 1120 synthetisiert werden, das in einer Hardware-Beschreibungssprache (Hardware Description Language, HDL) oder einer anderen Darstellung von physischen Design-Daten vorliegen kann. Die HDL kann des Weiteren simuliert oder getestet werden, um das IP-Kern-Design zu überprüfen. Das IP-Kern-Design kann zur Lieferung an eine Herstellungsvorrichtung 1165 eines Dritten unter Verwendung von nichtflüchtigem Speicher 1140 (z. B. Festplatte, Flash-Speicher oder irgendein nichtflüchtiges Speichermedium) gespeichert werden. Alternativ kann das IP-Kern-Design über eine drahtgebundene Verbindung 1150 oder eine drahtlose Verbindung 1160 (z. B. über das Internet) übertragen werden. Die Herstellungsvorrichtung 1165 kann dann eine integrierte Schaltung herstellen, die wenigstens zum Teil auf dem IP-Kern-Design basiert. Die hergestellte integrierte Schaltung kann dazu ausgebildet sein, Operationen gemäß wenigstens einer hier beschriebenen Ausführungsform durchzuführen.
Die 11B veranschaulicht eine Querschnittsseitenansicht einer integrierten Schaltungs-Package-Baugruppe 1170 gemäß einigen hier beschriebenen Ausführungsformen. Die integrierte Schaltungs-Package-Baugruppe 1170 veranschaulicht eine Implementierung einer oder mehrerer Prozessor- oder Beschleunigereinrichtungen, wie sie hier beschrieben werden. Die Package-Baugruppe 1170 enthält mehrere Einheiten von Hardware-Logik 1172, 1174, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann wenigstens zum Teil in konfigurierbarer Logik oder Festfunktions-Logik-Hardware implementiert sein und kann einen oder mehrere Abschnitte irgendeines von Folgenden enthalten, den/die Prozessorkern(e), den/die Grafikprozessor(en) oder andere hier beschriebene Beschleunigereinrichtungen. Jede Logikeinheit 1172, 1174 kann in einem Halbleiter-Die implementiert und mit dem Substrat 1180 über eine Verschaltungsstruktur 1173 gekoppelt sein. Die Verschaltungsstruktur 1173 kann dazu ausgebildet sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten, und kann Verschaltungen, wie zum Beispiel Löthöcker oder Säulen enthalten, ist jedoch nicht darauf beschränkt. In einigen Ausführungsformen kann die Verschaltungsstruktur 1173 dazu ausgebildet sein, elektrische Signale zu leiten, wie zum Beispiel Eingabe/Ausgabe (E/A)-Signale und/oder Leistungs- oder Massesignale, die mit dem Betrieb der Logik 1172, 1174 verknüpft sind. In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidharzbasis. Das Substrat 1180 kann in anderen Ausführungsformen andere geeignete Typen von Substraten enthalten. Die Package-Baugruppe 1170 kann mit anderen elektrischen Einrichtungen über eine Package-Verschaltung 1183 verbunden sein. Die Package-Verschaltung 1183 kann mit einer Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Einrichtungen zu leiten, wie zum Beispiel zu einem Motherboard, einem anderen Chipsatz oder einem Mehr-Chip-Modul.
In einigen Ausführungsformen sind die Logikeinheiten 1172, 1174 elektrisch mit einer Bridge 1182 gekoppelt, die dazu ausgebildet ist, elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Bridge 1182 kann eine dichte Verschaltungsstruktur sein, die eine Leitung für elektrische Signale bereitstellt. Die Bridge 1182 kann ein Bridge-Substrat enthalten, das aus Glas oder einem geeigneten Halbleitermaterial zusammengesetzt ist. Elektrische Leitungsmerkmale können auf dem Bridge-Substrat gebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Obwohl zwei Logikeinheiten 1172, 1174 und eine Bridge 1182 veranschaulicht werden, können hier beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies enthalten. Der eine oder die mehreren Dies können durch keine oder mehrere Bridges verbunden sein, weil die Bridge 1182 gestrichen sein kann, wenn die Logik auf einem einzigen Die enthalten ist. Alternativ können mehrere Dies oder Logikeinheiten durch eine oder mehrere Bridges verbunden sein. Zusätzlich können mehrere Logikeinheiten, Dies und Bridges miteinander in anderen möglichen Ausbildungsformen verbunden sein, einschließlich dreidimensionaler Ausbildungsformen.
Die 11C veranschaulicht eine Package-Baugruppe 1190, die mehrere Einheiten von Hardware-Logik-Chiplets enthält, die mit einem Substrat 1180 (z. B. Basis-Die) verbunden sind. Eine Grafikverarbeitungseinheit, ein Parallelprozessor und/oder ein Rechenbeschleuniger, wie sie hier beschrieben werden, können aus diversen Silicium-Chiplets zusammengesetzt sein, die separat hergestellt sind. In diesem Kontext ist ein Chiplet eine wenigstens zum Teil gepackte integrierte Schaltung, die unterschiedliche Logikeinheiten enthält, die mit anderen Chiplets zu einem größeren Package zusammengefügt sein können. Ein verschiedenartiger Satz Chiplets mit unterschiedlicher IP-Kern-Logik kann zu einer einzigen Einrichtung zusammengefügt sein. Zusätzlich können die Chiplets zu einem Basis-Die oder einem Basis-Chiplet unter Verwendung aktiver Interposer-Technologie integriert sein. Die hier beschriebenen Konzepte ermöglichen die Verschaltung und Kommunikation zwischen den unterschiedlichen Formen von IP in der GPU. IP-Kerne können unter Verwendung unterschiedlicher Verarbeitungstechnologien hergestellt und während der Herstellung zusammengesetzt sein, wodurch die Komplexität beim Konvergieren mehrerer IPs, insbesondere auf einem großen SoC mit IPs mehrerer Varianten, zum gleichen Herstellungsprozess vermieden wird. Indem die Verwendung mehrerer Prozesstechnologien ermöglicht wird, wird die Markteinführungszeit verbessert und eine kostengünstige Weise zum Erstellen mehrerer Produkt-SKUs bereitgestellt. Zusätzlich sind die disaggregierten IPs eher für unabhängiges Bestromen zugänglich, Komponenten, die bei einer gegebenen Arbeit nicht im Einsatz sind, können abgeschaltet werden, was die Gesamtleistungsaufnahme reduziert.
Zu den Hardware-Logik-Chiplets können Spezial-Hardware-Logik-Chiplets 1172, Logik- oder E/A-Chiplets 1174 und/oder Speicher-Chiplets 1175 zählen. Die Hardware-Logik-Chiplets 1172 und die Logik- oder E/A-Chiplets 1174 können wenigstens zum Teil in konfigurierbarer Logik oder Festfunktions-Logik-Hardware implementiert sein und können einen oder mehrere Abschnitte irgendeines von Folgenden enthalten, den/die Prozessorkern(e), den/die Grafikprozessor(en), Parallelprozessoren oder andere hier beschriebene Beschleunigereinrichtungen. Die Speicher-Chiplets 1175 können DRAM (z. B. GDDR, HBM)-Speicher oder Cache (SRAM)-Speicher sein.
Jedes Chiplet kann als ein separater Halbleiter-Die hergestellt und mit dem Substrat 1180 über eine Verschaltungsstruktur 1173 gekoppelt sein. Die Verschaltungsstruktur 1173 kann dazu ausgebildet sein, elektrische Signale zwischen den verschiedenen Chiplets und Logik im Substrat 1180 zu leiten. Die Verschaltungsstruktur 1173 kann Verschaltungen, wie zum Beispiel Löthöcker oder Säulen enthalten, ist jedoch nicht darauf beschränkt. In einigen Ausführungsformen kann die Verschaltungsstruktur 1173 dazu ausgebildet sein, elektrische Signale zu leiten, wie zum Beispiel Eingabe/Ausgabe (E/A)-Signale und/oder Leistungs- oder Massesignale, die mit dem Betrieb der Logik, E/A und Speicher verknüpft sind.
In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidharzbasis. Das Substrat 1180 kann in anderen Ausführungsformen andere geeignete Typen von Substraten enthalten. Die Package-Baugruppe 1190 kann mit anderen elektrischen Einrichtungen über eine Package-Verschaltung 1183 verbunden sein. Die Package-Verschaltung 1183 kann mit einer Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Einrichtungen zu leiten, wie zum Beispiel zu einem Motherboard, einem anderen Chipsatz oder einem Mehr-Chip-Modul.
In einigen Ausführungsformen können ein Logik- oder E/A-Chiplet 1174 und ein Speicher-Chiplet 1175 über eine Bridge 1187 elektrisch gekoppelt sein, die dazu ausgebildet ist, elektrische Signale zwischen dem Logik- oder E/A-Chiplet 1174 und einem Speicher-Chiplet 1175 zu leiten. Die Bridge 1187 kann eine dichte Verschaltungsstruktur sein, die eine Leitung für elektrische Signale bereitstellt. Die Bridge 1187 kann ein Bridge-Substrat enthalten, das aus Glas oder einem geeigneten Halbleitermaterial zusammengesetzt ist. Elektrische Leitungsmerkmale können auf dem Bridge-Substrat gebildet sein, um eine Chip-zu-Chip-Verbindung zwischen dem Logik- oder E/A-Chiplet 1174 und einem Speicher-Chiplet 1175 bereitzustellen. Die Bridge 1187 kann auch als eine Silicium-Bridge oder eine Verschaltungs-Bridge bezeichnet werden. Zum Beispiel ist die Bridge 1187 in einigen Ausführungsformen eine Embedded Multi-die Interconnect Bridge (EMIB). In einigen Ausführungsformen kann die Bridge 1187 einfach eine direkte Verbindung von einem Chiplet zu einem anderen Chiplet sein.
Das Substrat 1180 kann Hardware-Komponenten für E/A 1191, Cache-Speicher 1192 und andere Hardware-Logik 1193 enthalten. Eine Struktur 1185 kann im Substrat 1180 eingebettet sein, um Kommunikation zwischen den verschiedenen Logik-Chiplets und der Logik 1191, 1193 innerhalb des Substrats 1180 zu ermöglichen. In einer Ausführungsform können die E/A 1191, die Struktur 1185, der Cache, die Bridge und andere Hardware-Logik 1193 in einem Basis-Die integriert sein, der auf der Oberseite des Substrats 1180 geschichtet ist.
In verschiedenen Ausführungsformen kann eine Package-Baugruppe 1190 eine kleinere oder größere Anzahl an Komponenten und Chiplets enthalten, die durch eine Struktur 1185 oder eine oder mehrere Bridges 1187 verschaltet sind. Die Chiplets in der Package-Baugruppe 1190 können in einer 3D- oder 2,5D-Anordnung angeordnet sein. Im Allgemeinen können Bridge-Strukturen 1187 verwendet werden, um eine Punktzu-Punkt-Verschaltung zum Beispiel zwischen Logik- oder E/A-Chiplets und Speicher-Chiplets zu ermöglichen. Die Struktur 1185 kann verwendet werden, um die verschiedenen Logik- und/oder E/A-Chiplets (z. B. die Chiplets 1172, 1174, 1191, 1193) mit anderen Logik- und/oder E/A-Chiplets zu verschalten. In einer Ausführungsform kann der Cache-Speicher 1192 im Substrat als ein globaler Cache für die Package-Baugruppe 1190, ein Teil eines verteilten globalen Caches oder als ein dedizierter Cache für die Struktur 1185 fungieren.
Die 11D veranschaulicht eine Package-Baugruppe 1194, die austauschbare Chiplets 1195 enthält, gemäß einer Ausführungsform. Die austauschbaren Chiplets 1195 können in standardisierte Slots auf einem oder mehreren Basis-Chiplets 1196, 1198 eingebaut sein. Die Basis-Chiplets 1196, 1198 können über eine Bridge-Verschaltung 1197 gekoppelt sein, die ähnlich den anderen hier beschriebenen Bridge-Verschaltungen und zum Beispiel eine EMIB sein können. Speicher-Chiplets können ebenfalls mit Logik- oder E/A-Chiplets über eine Bridge-Verschaltung verbunden sein. E/A- und Logik-Chiplets können über eine Verschaltungsstruktur kommunizieren. Die Basis-Chiplets können jeweils einen oder mehrere Slots in einem standardisierten Format für eines, Logik- oder E/A- oder Speicher/Cache, unterstützen.
In einer Ausführungsform können SRAM- oder Leistungsabgabeschaltungen in einem oder mehreren der Basis-Chiplets 1196, 1198 hergestellt sein, die unter Verwendung einer in Bezug auf die austauschbaren Chiplets 1195, die auf die Oberseite der Basis-Chiplets gestapelt sind, anderen Prozesstechnologie hergestellt sein können. Zum Beispiel können die Basis-Chiplets 1196, 1198 unter Verwendung größerer Prozesstechnologie hergestellt sein, während die austauschbaren Chiplets unter Verwendung kleinerer Prozesstechnologie hergestellt sein können. Eines oder mehrere der austauschbaren Chiplets 1195 können Speicher (z. B. DRAM)-Chiplets sein. Unterschiedliche Speicherdichten können für die Package-Baugruppe 1194 basierend auf der Leistung und/oder der Performance ausgewählt werden, die für das Produkt, das die Package-Baugruppe 1194 verwendet, angestrebt wird. Zusätzlich können Logik-Chiplets mit einer unterschiedlichen Anzahl an Typen von Funktionseinheiten zum Zeitpunkt des Zusammenbaus basierend auf der Leistung und/oder der Performance, die für das Produkt angestrebt werden, ausgewählt werden. Zusätzlich können Chiplets, die IP-Logikkerne unterschiedlicher Typen enthalten, in die austauschbaren Chiplet-Slot eingesetzt werden, was hybride Prozessor-Designs ermöglicht, bei denen IP-Blöcke unterschiedlicher Technologien gemischt und abgestimmt werden können.
Beispielhafte integrierte System-on-Chip-Schaltungen
Die 12 - 13 veranschaulichen beispielhafte integrierte Schaltungen und verknüpfte Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt sein können, gemäß verschiedenen, hier beschriebenen Ausführungsformen. Zusätzlich zum Veranschaulichten können andere Logik und Schaltungen enthalten sein, einschließlich zusätzlicher Grafikprozessoren/-kerne, Peripherieschnittstellen-Controllern oder universellen Prozessorkernen.
Die 12 ist ein Blockdiagramm, das eine beispielhafte integrierte System-on-Chip-Schaltung 1200 veranschaulicht, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt sein kann, gemäß einer Ausführungsform. Die beispielhafte integrierte Schaltung 1200 enthält einen oder mehrere Anwendungsprozessor(en) 1205 (z. B. CPUs), wenigstens einen Grafikprozessor 1210 und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 enthalten, von denen jeder ein modularer IP-Kern aus der gleichen oder mehreren unterschiedlichen Design-Vorrichtungen sein kann. Die integrierte Schaltung 1200 enthält Peripherie- oder Bus-Logik, einschließlich einem USB-Controller 1225, einem UART-Controller 1230, einem SPI/SDIO-Controller 1235 und einem I²S/I²C-Controller 1240. Zusätzlich kann die integrierte Schaltung eine Anzeigeeinrichtung 1245 enthalten, die mit einem oder mehreren von Folgenden, einem High-Definition Multimedia Interface (HDMI)-Controller 1250 und einer Mobile Industry Processor Interface (MIPI)-Anzeigeschnittstelle 1255, gekoppelt ist. Speicher kann durch ein Flash-Speicher-Subsystem 1260 bereitgestellt werden, das Flash-Speicher und einen Flash-Speicher-Controller enthält. Eine Speicherschnittstelle kann über einen Speicher-Controller 1265 für den Zugriff auf SDRAM- oder SRAM-Speichereinrichtungen bereitgestellt werden. Einige integrierte Schaltungen enthalten zusätzlich eine eingebettete Sicherheits-Engine 1270.
Die 13A - 13B sind Blockdiagramme, die beispielhafte Grafikprozessoren für die Verwendung in einer SoC veranschaulichen, gemäß hier beschriebenen Ausführungsformen. Die 13A veranschaulicht einen beispielhaften Grafikprozessor 1310 einer integrierten System-on-Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt sein kann, gemäß einer Ausführungsform. Die 13B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 1340 einer integrierten System-on-Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt sein kann, gemäß einer Ausführungsform. Der Grafikprozessor 1310 der 13A ist ein Beispiel für einen Niedrigleistungs-Grafikprozessorkern. Der Grafikprozessor 1340 der 13B ist ein Beispiel für einen Grafikprozessorkern mit höherer Performance. Jeder der Grafikprozessoren 1310, 1340 kann Varianten des Grafikprozessors 1210 der 12 sein.
Wie in der 13A gezeigt wird, enthält der Grafikprozessor 1310 einen Vertexprozessor 1305 und einen oder mehrere Fragment-Prozessor(en) 1315A - 1315N (z. B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N). Der Grafikprozessor 1310 kann unterschiedliche Shader-Programme über separate Logik ausführen, so dass der Vertexprozessor 1305 dazu optimiert ist, Operationen für Vertex-Shader-Programme auszuführen, während der eine oder die mehreren Fragmentprozessor(en) 1315A - 1315N Fragment (z. B. Pixel)-Shading-Operationen für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertex-Prozessor 1305 führt die Vertexverarbeitungsstufe der 3D-Grafik-Pipeline durch und generiert Primitiven- und Vertexdaten. Der/die Fragmentprozessor(en) 1315A - 1315N verwenden die vom Vertexprozessor 1305 generierten Primitiven- und Vertexdaten, um einen Framebuffer zu erstellen, der auf einer Anzeigeeinrichtung angezeigt wird. In einer Ausführungsform sind der/die Fragmentprozessor(en) 1315A - 1315N dazu optimiert, Fragment-Shader-Programme auszuführen, wie sie in der OpenGL-API zur Verfügung gestellt werden, die verwendet werden können, um ähnliche Operationen durchzuführen wie ein Pixel-Shader-Programm, wie es in der Direct 3D-API zur Verfügung gestellt wird.
Der Grafikprozessor 1310 enthält zusätzlich eine oder mehrere Speichermanagementeinheiten (Memory Management Units, MMUs) 1320A - 1320B, Cache(s) 1325A - 1325B und Schaltungsverschaltung(en) 1330A - 1330B. Die eine oder die mehreren MMU(s) 1320A - 1320B stellen Mapping von virtuellen auf physische Adressen für den Grafikprozessor 1310 zur Verfügung, einschließlich für den Vertex-Prozessor 1305 und/oder den/die Fragment-Prozessor(en) 1315A - 1315N, die auf im Speicher gespeicherte Vertex- oder Bild-/Texturdaten, zusätzlich zu den Vertex- oder Bild-/Texturdaten, die in dem einen oder den mehreren Cache(s) 1325A - 1325B gespeichert sind, verweisen können. In einer Ausführungsform können die eine oder die mehreren MMU(s) 1320A - 1320B mit anderen MMUs 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 der 12 verknüpft sind, so dass jeder Prozessor 1205 - 1220 an einem gemeinsam genutzten oder vereinheitlichten virtuellen Speichersystem teilhaben kann. Die eine oder die mehreren Schaltungsverschaltung(en) 1330A - 1330B ermöglichen, dass der Grafikprozessor 1310 mit anderen IP-Kernen im SoC verkoppeln kann, entweder über einen internen Bus des SoC oder über eine direkte Verbindung, gemäß Ausführungsformen.
Wie in der 13B gezeigt wird, enthält der Grafikprozessor 1340 die eine oder die mehreren MMU(s) 1320A - 1320B, den/die Cache(s) 1325A - 1325B und die Schaltungsverschaltung(en) 1330A - 1330B des Grafikprozessors 1310 der 13A. Der Grafikprozessor 1340 enthält einen oder mehrere Shader-Kern(e) 1355A - 1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), was eine vereinheitlichte Shader-Kern-Architektur zur Verfügung stellt, in der ein einzelner Kern oder Kerntyp alle Typen von programmierbarem Shader-Code ausführen kann, einschließlich Shader-Programmcode zum Implementieren von Vertex-Shadern, Fragment-Shadern und/oder Compute-Shadern. Die exakte Anzahl an vorhandenen Shader-Kernen kann zwischen Ausführungsformen und Implementierungen variieren. Zusätzlich enthält der Grafikprozessor 1340 einen Inter-Kern-Aufgabenmanager 1345, der als ein Thread-Dispatcher zum Verteilen von Ausführungs-Threads an einen oder mehrere Shader-Kerne 1355A - 1355N fungiert, und eine Kachelungseinheit 1358 zum Beschleunigen von Kachelungsoperationen für kachelbasiertes Rendering, wobei Rendering-Operationen für eine Szene in einen Bildraum unterteilt werden, um zum Beispiel lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder um die Verwendung von internen Caches zu optimieren.
Die 14 veranschaulicht eine Ausführungsform einer Recheneinrichtung, die einen Seitentabellen-Mapping-Mechanismus („Mapping-Mechanismus“) 1410 einsetzt. Zum Beispiel kann in einer Ausführungsform der Mapping-Mechanismus der 14 von der Recheneinrichtung 1400 eingesetzt oder gehostet sein. Wie veranschaulicht wird, kann der Mapping-Mechanismus 1410 von der oder einem Teil der Grafikverarbeitungseinheit („GPU“ oder „Grafikprozessor“) 1414 gemäß einer Ausführungsform gehostet sein.
In anderen Ausführungsformen kann der Mapping-Mechanismus 1410 von der oder einem Teil der Firmware der zentralen Verarbeitungseinheit („CPU“ oder „Anwendungsprozessor“) 1412 gehostet sein. In noch anderen Ausführungsformen kann der Mapping-Mechanismus 1410 von dem oder einem Teil des Grafiktreibers 1416 gehostet sein. Der Kürze, Klarheit und Vereinfachung des Verständnisses halber kann der Mapping-Mechanismus 1410 im restlichen Teil dieses Dokument durchweg als Teil der GPU 1414 erörtert werden; allerdings sind die Ausführungsformen von daher nicht beschränkt.
In noch einer anderen Ausführungsform kann der Mapping-Mechanismus 1410 als Software- oder Firmware-Logik vom Betriebssystem 1406 gehostet sein. In noch einer weiteren Ausführungsform kann der Mapping-Mechanismus 1410 zum Teil und zeitgleich von mehreren Komponenten der Recheneinrichtung 1400 gehostet sein, wie zum Beispiel einem oder mehreren Grafiktreibern 1416, der GPU 1414, GPU-Firmware, der CPU 1412, CPU-Firmware, dem Betriebssystem 1406 und/oder Ähnlichen. Es wird in Betracht gezogen, dass der Mapping-Mechanismus 1410 oder eine oder mehrere seiner Komponenten als Hardware, Software und/oder Firmware implementiert sein kann.
Die Recheneinrichtung 1400 stellt eine Kommunikations- und Datenverarbeitungseinrichtung dar, die irgendeine Anzahl und irgendeinen Typ von intelligenten Einrichtungen enthält oder darstellt, wie zum Beispiel (ohne Beschränkung) intelligente Befehlseinrichtungen oder intelligente persönliche Assistenzgeräte, Haus-/Büro-Automationssystem, Haushaltsgeräte (z. B. Waschmaschinen, Fernsehgeräte usw.), mobile Einrichtungen (z. B. Smartphones, Tablet-Computer usw.), Gaming-Einrichtungen, handgeführte Einrichtungen, Wearable Einrichtungen (z. B. Smartwatches, intelligente Armbänder usw.), Virtual-Reality (VR)-Einrichtungen, Head-Mounted Displays (HMDs), Internet of Things (IoT)-Einrichtungen, Laptop-Computer, Desktop-Computer, Server-Computer, Set-Top-Boxen (z. B. internetbasierte Kabelfernseh-Set-Top-Boxen usw.), Einrichtungen auf Basis eines Global Positioning Systems (GPS) usw.
In einigen Ausführungsformen kann die Recheneinrichtung 1400 autonome Maschinen oder Agenten der künstlichen Intelligenz enthalten (ohne Beschränkungen), wie zum Beispiel mechanische Agenten oder Maschinen, elektronische Agenten oder Maschinen, virtuelle Agenten oder Maschinen, elektromechanische Agenten oder Maschinen usw. Zu Beispielen für autonome Maschinen oder Agenten der künstlichen Intelligenz können Roboter, autonome Fahrzeuge (z. B. selbstfahrende Fahrzeuge, selbstfliegende Flugzeuge, selbstfahrende Boote usw.), autonome Geräte (selbstarbeitende Baufahrzeuge, selbstarbeitende medizinische Geräte usw.) und/oder Ähnliches zählen (ohne Beschränkung). Des Weiteren sind „autonome Fahrzeuge“ nicht auf Automobile beschränkt, sondern darauf, dass sie irgendeine Anzahl oder irgendeinen Typ von autonomen Maschinen, wie zum Beispiel Roboter, autonome Geräte, autonome Haushaltseinrichtungen und/oder Ähnliches, enthalten können, und auf irgendeine oder irgendwelche Aufgaben oder Operationen, die sich auf solche autonomen Maschinen beziehen, kann austauschbar als autonomes Fahren verwiesen werden.
Des Weiteren kann die Recheneinrichtung 1400 zum Beispiel eine Cloud-Rechenplattform enthalten, die aus mehreren Server-Computern besteht, wobei jeder Server-Computer einen Multifunktions-Perzeptronmechanismus einsetzt oder hostet. Zum Beispiel kann automatisches ISP-Tuning unter Verwendung von Komponenten-, System- und Architektur-Einstellungen durchgeführt werden, die früher in diesem Dokument beschrieben worden sind. Zum Beispiel können einige der zuvor erwähnten Einrichtungstypen verwendet werden, um eine kundenspezifisch gelernte Prozedur zu implementieren, wie zum Beispiel unter Verwendung von Field Programmable Gate Arrays (FPGAs) usw.
Des Weiteren kann die Recheneinrichtung 1400 zum Beispiel eine Computerplattform enthalten, die eine integrierte Schaltung („IC“) hostet, wie zum Beispiel ein System-on-Chip („SoC“ oder „SOC“), das verschiedene Hardware- und/oder Software-Komponenten der Recheneinrichtung 1400 auf einem einzigen Chip integriert.
Wie veranschaulicht wird, kann die Recheneinrichtung 1400 in einer Ausführungsform irgendeine Anzahl oder irgendeinen Typ von Hardware- und/oder Software-Komponenten enthalten, wie zum Beispiel (ohne Beschränkung) die Grafikverarbeitungseinheit 1414 („GPU“ oder einfach „Grafikprozessor“), den Grafiktreiber 1416 (auch als „GPU-Treiber“, „Grafiktreiberlogik“, „Treiberlogik“, Anwendermodustreiber (User-Mode Driver, UMD), UMD, Anwendermodustreiber-Framework (User-Mode Driver Framework, UMDF), UMDF oder einfach „Treiber“ bezeichnet), die zentrale Verarbeitungseinheit 1412 („CPU“ oder einfach „Anwendungsprozessor“), den Speicher 1404, Netzwerkeinrichtungen, Treiber oder Ähnliches sowie Eingabe-/Ausgabe (E/A)-Quellen 1408, wie zum Beispiel Touch-Screens, Touch-Panels, Touch-Pads, virtuelle oder normale Tastaturen, virtuelle oder normale Mäuse, Ports, Verbinder usw. Die Recheneinrichtung 100 kann das Betriebssystem (OS) enthalten, das als eine Schnittstelle zwischen Hardware und/oder physischen Ressourcen der Recheneinrichtung 1400 und einem Anwender dient.
Es versteht sich, dass ein weniger oder mehr ausgestattetes System als das oben beschriebene Beispiel für bestimmte Implementierungen bevorzugt werden kann. Daher kann die Ausbildungsform der Rechenvorrichtung 1400 von Implementierung zu Implementierung in Abhängigkeit von zahlreichen Faktoren variieren, wie Preisbeschränkungen, Performance-Anforderungen, technologischen Verbesserungen oder anderen Umständen.
Ausführungsformen können als irgendeines von Folgenden oder als eine Kombination von Folgenden implementiert sein: ein oder mehrere Mikrochips oder integrierte Schaltungen, die unter Verwendung einer Hauptplatine verbunden sind, festverdrahtete Logik, Software, die von einer Speichereinrichtung gespeichert und von einem Mikroprozessor ausgeführt wird, Firmware, eine anwendungsspezifische integrierte Schaltung (ASIC, Application Specific Integrated Circuit) und/oder ein Field Programmable Gate Array (FPGA). Die Begriffe „Logik“, „Modul“, „Komponente“, „Engine“ und „Mechanismus“ können beispielsweise Software oder Hardware und/oder eine Kombinationen davon, wie zum Beispiel Firmware, beinhalten.
Gemäß einer Ausführungsform ist die Recheneinrichtung 1400 mit einer oder mehreren Client-Recheneinrichtungen (oder Clients) 1440 über eines oder mehrere Netzwerke 1445 gekoppelt. Dementsprechend können der Server 1400 und der Client 1440 des Weiteren Netzwerkschnittstelle(n) enthalten, um Zugriff auf ein Netzwerk bereitzustellen, wie zum Beispiel ein LAN, ein Weitverkehrsnetz (Wide Area Network, WAN), ein Metropolitan Area Network (MAN), ein Personal Area Network (PAN), Bluetooth, ein Cloud-Netzwerk, ein mobiles Netzwerk (z. B. 3. Generation (3G), 4. Generation (4G) usw.), ein Intranet, das Internet usw. Zu Netzwerkschnittstelle(n) können zum Beispiel eine drahtlose Netzwerkschnittstelle mit Antenne zählen, die eine oder mehrere Antenne(n) darstellen kann. Zu Netzwerkschnittstelle(n) können ebenfalls zum Beispiel eine drahtgebundene Netzwerkschnittstelle zum Kommunizieren mit entfernten Einrichtungen über Netzwerkkabel zählen, das zum Beispiel ein Ethernet-Kabel, ein Koaxkabel, ein Lichtwellenleiterkabel, ein serielles Kabel oder ein Parallelkabel sein kann.
Ausführungsformen können zum Beispiel als ein Computerprogrammprodukt bereitgestellt sein, das ein oder mehrere maschinenlesbare Medien enthalten kann, auf denen maschinenausführbare Anweisungen gespeichert sind, die, wenn sie von einer oder mehreren Maschinen, wie zum Beispiel einem Computer, einem Computernetzwerk oder anderen elektronischen Einrichtungen, ausgeführt werden, bewirken können, dass die eine oder die mehreren Maschinen Operationen gemäß hier beschriebenen Ausführungsformen ausführen. Zu einem maschinenlesbaren Medium können, ohne darauf beschränkt zu sein, Floppy Disks, optische Platten, CD-ROMs (Compact Disc-Read Only Memories) und magnetooptische Platten, ROMs, RAMs, EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetische oder optische Karten, Flash-Speicher oder andere Arten von Medien/maschinenlesbaren Medien, die zum Speichern von maschinenausführbaren Anweisungen geeignet sind, zählen.
Darüber hinaus können Ausführungsformen als ein Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer (z. B. einem Server) an einen anfordernden Computer (z. B. einen Client) mittels eines oder mehrerer Datensignale übertragen werden kann, die durch eine Trägerwelle oder ein anderes Ausbreitungsmedium über eine Kommunikationsverknüpfung (z. B. eine Modem- und/oder eine Netzwerkverbindung) realisiert und/oder durch diese moduliert sind.
In diesem Dokument kann der Begriff „Anwender“ austauschbar durchweg als ein „Betrachter“, „Beobachter“, „Sprecher“, „Person“, Individuum‟, „Endanwender“ und/oder Ähnliches bezeichnet werden. Es ist anzumerken, dass in diesem Dokument auf Begriffe wie „Grafik-Domäne“ austauschbar durchweg als „Grafikverarbeitungseinheit“, „Grafikprozessor“ oder einfach „GPU“ verwiesen werden kann und dass gleichermaßen auf „CPU-Domäne“ oder „Host-Domäne“ austauschbar als „Computerverarbeitungseinheit“, „Anwendungsprozessor“ oder einfach „CPU“ verwiesen werden kann.
Es ist anzumerken, dass Begriffe wie „Knoten“, „Rechenknoten“, „Server“, „Server-Einrichtung“, „Cloud-Computer“, „Cloud-Server“, „Cloud-Server-Computer“, „Maschine“, „Host-Maschine“, „Einrichtung“, „Recheneinrichtung“, „Computer“, „Rechensystem“ und Ähnliche in diesem Dokument durchweg austauschbar verwendet werden können. Es ist des Weiteren anzumerken, dass Begriffe wie „Anwendung“, „Software-Anwendung“, „Programm“, „Software-Programm“, „Package“, „Software-Package“ und Ähnliche in diesem Dokument durchweg austauschbar verwendet werden können. Ebenfalls können Begriffe wie „Job“, „Eingabe“, „Anforderung“, „Nachricht“ und Ähnliche in diesem Dokument durchweg austauschbar verwendet werden.
Wie oben erörtert worden ist, mappen Seitentabellen-PTEs logische Grafikspeicheradressen auf physische Speicheradressen. Die 15 veranschaulicht eine konventionelle Seitentabelle, in der ein 540-kB-PTE auf eine 270-MB-Seite in einem Framebuffer gemappt wird. Allerdings nehmen die 540-kB-PTEs erheblichen Raum in der Seitentabelle ein, die höchstens 8 MB Raum zum Speichern aller Übersetzungen aufweist. Wie oben erwähnt worden ist, wäre das Erhöhen der Seitentabellengröße praktisch nicht umsetzbar, weil sich solch eine Größenzunahme auf aktuelle Anzeige-Hardware-Implementierungen auswirken würde.
Gemäß einer Ausführungsform wird der Mapping-Mechanismus 1410 implementiert, um Seitentabellen-auf-Framebuffer-Mapping durchzuführen. In solch einer Ausführungsform stellt der Seitentabellen-Mapping-Mechanismus 1410 einen Zwei-Level-Seitentabellen-Walk bereit, bei dem jeder Seitentabelleneintrag auf eine Anzeigeseitentabellen (DPT)-Seite mappt und ein Walk auf dem zweiten Level der DPT auf physische Framebuffer-Seiten zeigt. In dieser Ausführungsform enthalten Seitentabelleneinträge einen Zeiger auf eine verknüpfte DPT-Seite, die die eigentliche Übersetzung enthält.
In einer Ausführungsform befindet sich ein Framebuffer, der aus einer DPT gemappt ist, an der Null-Adresse seines eigenen virtuellen Adress (VA)-DPT-Raums. Somit verwendet eine DPT das gleiche PTE-Formal wie konventionelle Seitentabellen, wobei jede DPT auf 4 kB des Framebuffer-Speichers mappt. In einer weiteren Ausführungsform ist eine DPT ausreichend groß, um auf den Framebuffer (z. B. einschließlich Padding-Bytes) zu mappen, und kann physisch nicht zusammenhängende Seiten ähnlich dem Framebuffer implementieren.
Die 16 veranschaulicht eine Ausführungsform der GPU 1414. Wie in der 16 gezeigt wird, enthält die GPU 1414 den Mapping-Mechanismus 1510 und eine Speichermanagementeinheit (MMU) 1610. Die MMU 1610 enthält den TLB 1620. In einer Ausführungsform ist der TLB 1620 ein eingestellter verknüpfter Cache, der neueste Übersetzungen von virtuellem Speicher in physischen Speicher speichert. Der Seitentabellen-Mapping-Mechanismus 1410 sucht immer zuerst den TLB 1620, wenn eine virtuelle Adresse in eine physische Adresse zu übersetzen ist. Falls eine Übereinstimmung gefunden wird (z. B. ein TLB Hit), gibt der Seitentabellen-Mapping-Mechanismus 1410 die physische Adresse zurück, und der Speicherzugriff kann fortgesetzt werden. Falls allerdings keine Übereinstimmung vorhanden ist (z. B. ein TLB Miss), greift der Seitentabellen-Mapping-Mechanismus 1410 auf Seitentabellen 1610 zu, um die Übersetzung durchzuführen.
In einer Ausführungsform enthalten PTEs in Seitentabellen 1610 eine kleine Komponente (z. B. 1 kB) der virtuellen Adresse, die auf eine verknüpfte DPT zeigt. In solch einer Ausführungsform ist jeder PTE mit einem definierten Bereich des Framebuffers verknüpft (oder deckt diesen ab). Zum Beispiel kann jeder PTE 2 MB des Framebuffer-Mappings abdecken (z. B. eine gesamte Kachelzeile für eine schrittweise rechteckige Blockstruktur (oder Schritte) <= 64 kB). In einer weiteren Ausführungsform werden zwei PTEs für einen Schritt implementiert, der größer als 64 kB ist und kleiner oder gleich 128 kB. In noch einer weiteren Ausführungsform enthält jeder Cache-Zeilenabruf für die Seitentabelle 1610 acht Übersetzungseinträge. Somit wird nur ein Cache-Zeilenabruf auf dem ersten Level für die Seitentabelle 1610 für eine gesamte Kachelzeile implementiert. Bei einem Schritt >64 k ist die Oberflächen-Basisadresse 8-k-ausgerichtet, um zu garantieren, dass ein einziger Cache-Zeilen-GTT-Abrufausreichend ist, um die beiden PTEs des ersten Levels zu erhalten, die für die Kachelzeile benötigt werden.
Die 17 veranschaulicht eine Ausführungsform der Seitentabellen 1610 und des Speichers 1408, einschließlich einer DPT 1720 und eines verknüpften Framebuffers 1750. Wie in der 17 gezeigt wird, mappt der PTE in den Seitentabellen 1610 auf eine 540-kB-DPT 1720, die in eine 270-MB-Datenseite im Framebuffer 1750 übersetzt. Gemäß einer Ausführungsform beginnen Oberflächen auf einer neuen 4-k-DPT 1720 mit dem Offset 0. In dieser Ausführungsform weisen das enthaltene planare YUV-Format, die Y- und UV-Oberfläche und die Kompressionssteueroberflächen eine separate DPT 1720 auf, die beim Offset 0 beginnen. In einer weiteren Ausführungsform können mehrere Kachelzeileneinträge in einer einzigen Seite der DPT 1720 enthalten sein. Allerdings überspannen Einträge für eine Kachelzeile nicht zwei unterschiedliche Seiten der DPT 1720, außer bei Schritten größer als 64 k, wobei 2 Seiten DPT 1720 implementiert werden. Dies wird durch Beschränken eines Oberflächenschritts (z. B. in Anzahl an Kacheln) auf einen Satz von Zweierpotenzwerten implementiert, wobei die validen Werte 8, 16, 32, 64, 128, 256, 512, 1024 sind.
Die 18A veranschaulicht eine Ausführungsform einer Seitenlevelansicht der Seitentabellen 1610 und des Speichers 1408. Wie in der 18A gezeigt wird, mappt jeder PTE (z. B. DPTP0 - DPTP2) auf eine DPT 1720. Des Weiteren enthält die DPT 1720 mehrere Übersetzungen von physischen Seiten im Framebuffer 1850. Zum Beispiel enthält jede DPT 1720 512 Übersetzungen (z. B. 0 - 511) in 512 Seiten (z. B. Seite 0 - Seite 511) im Framebuffer 1750. Die 18B veranschaulicht eine Ausführungsform des Framebuffers, einschließlich Seite 0 - Seite 511.
Gemäß einer Ausführungsform ist der Mapping-Mechanismus 1510 konfigurierbar, um entweder gemäß einem konventionellen Seitentabellen-Mapping zu arbeiten oder über das Zwei-Level-DPT-Mapping. In dieser Ausführungsform wird Zwei-Level-DPT-Mapping für kachelbasierte (z. B. Kachel 4, Kachel Y und Kachel X) Framebuffer-Oberflächen implementiert, während lineare Framebuffer-Oberflächen direktes Seitentabellen-Mapping mit einem Ein-Level-Lookup implementieren. In einer weiteren Ausführungsform implementiert der Mapping-Mechanismus 1410 DPTgemappte Framebuffer durch Spezifizieren einer Seitentabellen-VA, die sich an einer Seitentabellen-VA befindet, die mit der DPT verknüpft ist (z. B. weil die Framebuffer die VAs nicht selbst aufweisen).
Die 19 ist ein Flussdiagramm, das eine Ausführungsform eines Prozesses zum Durchführen der Übersetzung von virtuellen Adressen in physische Adressen über den Mapping-Mechanismus 1510 veranschaulicht. Im Verarbeitungsblock 1910 wird eine Seitenübersetzungsanforderung für eine Adresse empfangen. Im Verarbeitungsblock 1920 wird ein TLB-Lookup von 1610 zur Seitenübersetzung durchgeführt. Im Entscheidungsblock 1930 erfolgt eine Bestimmung, ob es einen Miss der Seite im TLB 1610 gibt. Eine Seitenübersetzung wird bei einer Bestimmung zurückgegeben, dass die Seite im TLB 1610 gefunden worden ist, Verarbeitungsblock 1960. Andernfalls werden Seitentabellen abgesucht, um eine mit einer DPT verknüpfte Adresse abzufragen, Verarbeitungsblock 1940. Im Verarbeitungsblock 1950 wird auf die DPT unter Verwendung der abgefragten Adresse zugegriffen, um die Übersetzung zu erfassen. Anschließend wird die Seitenübersetzung im Verarbeitungsblock 1960 zurückgegeben. Im Verarbeitungsblock 1970 werden Daten aus dem Frame an der physischen Adresse abgefragt, die in der zurückgegebenen Übersetzung angegeben ist.
Der oben beschriebene Mechanismus erhöht die Anzeigespeicheradressierbarkeit, um vorhandene Probleme/Komplikationen, dass der Anzeigeadressraum auf Seitentabellenbasis ausgeht, zu überwinden, und ist kompatibel zu vorhandenen Hardware-Implementierungen.
Die folgenden Klauseln und/oder Beispiele betreffen weitere Ausführungsformen oder Beispiele. Einzelheiten in den Beispielen können an irgendeiner Stelle in einer oder mehreren Ausführungsformen verwendet werden. Die verschiedenen Merkmale der unterschiedlichen Ausführungsformen oder Beispiele können verschiedenartig mit einigen Merkmalen, die enthalten sind, und mit anderen, die ausgeschlossen sind, kombiniert werden, um für eine Vielzahl von unterschiedlichen Anwendungen geeignet zu sein. Zu Beispielen können Gegenstände zählen, wie zum Beispiel ein Verfahren, Mittel zum Durchführen von Handlungen des Verfahrens, wenigstens ein maschinenlesbares Medium, das Anweisungen enthält, die, wenn sie von einer Maschine durchgeführt werden, bewirken, dass die Maschine Handlungen des Verfahrens oder einer Vorrichtung oder eines Systems durchführt, um hybride Kommunikation gemäß hier beschriebenen Ausführungsformen und Beispielen zu ermöglichen.

Einige Ausführungsformen gehören zum Beispiel 1, das eine Vorrichtung zum Ermöglichen von Seitenübersetzungen beinhaltet, was einen Framebuffer auf mehrere Datenseiten, mehrere Anzeigeseitentabellen zum Speichern von Übersetzungen von virtuellen Adressen in physische Adressen auf die Datenseiten im Framebuffer und eine Seitentabelle mit mehreren Seitentabelleneinträgen (PTEs), wobei jeder PTE auf eine der mehreren Anzeigeseitentabellen mappt, umfasst.
Das Beispiel 2 beinhaltet den Gegenstand des Beispiels 1, wobei jeder PTE einen Zeiger auf eine Anzeigeseitentabelle enthält.
Das Beispiel 3 beinhaltet den Gegenstand der Beispiele 1 und 2, wobei der Zeiger eine Komponente einer virtuellen Adresse, die in der Anzeigeseitentabelle gespeichert ist, umfasst.
Das Beispiel 4 beinhaltet den Gegenstand der Beispiele 1 - 3, wobei jeder PTE mit einem definierten Bereich des Framebuffer-Mappings verknüpft ist.
Das Beispiel 5 beinhaltet den Gegenstand der Beispiele 1 - 4, der des Weiteren einen Translation Lookaside Buffer (TLB) umfasst, der mehrere Einträge enthält, um die Übersetzungen von virtuellen in physische Speicheradressen zu speichern.
Das Beispiel 6 beinhaltet den Gegenstand der Beispiele 1 - 5, der des Weiteren Mapping-Hardware umfasst, um eine Seitenübersetzungsanforderung für eine Adresse zu empfangen.
Das Beispiel 7 beinhaltet den Gegenstand der Beispiele 1 - 6, wobei die Mapping-Hardware eine Suche im TLB nach einer Übersetzung beim Empfang der Seitenübersetzungsanforderung durchführt.
Das Beispiel 8 beinhaltet den Gegenstand der Beispiele 1 - 7, wobei die Mapping-Hardware in den PTEs in der Seitentabelle bei einer Bestimmung, dass der TLB keine Übersetzung enthält, sucht, um eine Adresse zu finden, die mit einer ersten von mehreren Anzeigeseitentabellen verknüpft ist.
Das Beispiel 9 beinhaltet den Gegenstand der Beispiele 1 - 8, wobei die Mapping-Hardware auf die erste Anzeigenseitentabelle zugreift, um die Übersetzung zu erfassen.
Einige Ausführungsformen gehören zum Beispiel 10, das ein Verfahren zum Ermöglichen von Seitenübersetzungen enthält, das umfasst, eine Seitenübersetzungsanforderung für eine virtuelle Adresse zu empfangen, in einer ersten Seitentabelle zu suchen, um eine Adresse, die mit einer ersten der mehreren Anzeigeseitentabellen verknüpft ist, abzufragen, in der ersten Anzeigeseitentabelle nach einer physischen Seitenübersetzung auf Basis der abgefragten Adresse zu suchen und eine physische Adresse aus der ersten Anzeigeseitentabelle zurückzugeben.
Das Beispiel 11 beinhaltet den Gegenstand des Beispiels 10, das des Weiteren umfasst, in einem Translation Lookaside Buffer (TLB) nach der physischen Seitenübersetzung zu suchen, bevor in der ersten Seitentabelle gesucht wird.
Das Beispiel 12 beinhaltet den Gegenstand der Beispiele 10 und 11, wobei die erste Tabelle mehrere Seitentabelleneinträge (PTEs) umfasst, die jeweils einen Zeiger auf die mehreren Anzeigeseitentabellen enthalten.
Das Beispiel 13 beinhaltet den Gegenstand der Beispiele 1 - 12, wobei jeder PTE einen Zeiger auf eine Anzeigeseitentabelle umfasst.
Das Beispiel 14 beinhaltet den Gegenstand der Beispiele 1 - 13, wobei der Zeiger eine Komponente einer virtuellen Adresse, die in der Anzeigeseitentabelle gespeichert ist, umfasst.
Das Beispiel 15 beinhaltet den Gegenstand der Beispiele 1 - 14, wobei jeder PTE mit einem definierten Bereich des Framebuffer-Mappings verknüpft ist.
Einige Ausführungsformen gehören zum Beispiel 16, das ein System zum Ermöglichen von Seitenübersetzungen beinhaltet, was einen Speicher umfasst, der Framebuffer auf mehrere Datenseiten, mehrere Anzeigeseitentabellen zum Speichern von Übersetzungen von virtuellen Adressen in physische Adressen auf die Datenseiten im Framebuffer und eine Speichermanagementeinheit (MMU), die mit dem Speicher gekoppelt ist, einschließlich einer Seitentabelle mit mehreren Seitentabelleneinträgen (PTEs), wobei jeder PTE auf eine der mehreren Anzeigeseitentabellen mappt, beinhaltet.
Das Beispiel 17 beinhaltet den Gegenstand des Beispiels 16, wobei die MMU des Weiteren einen Translation Lookaside Buffer (TLB) umfasst, der mehrere Einträge enthält, um die Übersetzungen von virtuellen in physische Speicheradressen zu speichern.
Das Beispiel 18 beinhaltet den Gegenstand der Beispiele 16 und 17, wobei die MMU des Weiteren die Mapping-Hardware umfasst, um eine Seitenübersetzungsanforderung für eine Adresse zu empfangen.
Das Beispiel 19 beinhaltet den Gegenstand der Beispiele 16 - 18, wobei die Mapping-Hardware eine Suche im TLB nach einer Übersetzung beim Empfang der Seitenübersetzungsanforderung durchführt.
Das Beispiel 20 beinhaltet den Gegenstand der Beispiele 16 - 19, wobei die Mapping-Hardware in den PTEs in der Seitentabelle bei einer Bestimmung, dass der TLB keine Übersetzung enthält, sucht, um eine Adresse zu finden, die mit einer ersten von mehreren Anzeigeseitentabellen verknüpft ist.
Das Beispiel 21 beinhaltet den Gegenstand der Beispiele 16 - 20, wobei die Mapping-Hardware auf die erste Anzeigenseitentabelle zugreift, um die Übersetzung zu erfassen.

Die Erfindung ist oben unter Bezugnahme auf spezifische Ausführungsformen beschrieben worden. Allerdings werden Fachleute verstehen, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne vom umfassenderen Wesen und Umfang der Erfindung abzuweichen, wie sie in den beigefügten Ansprüchen dargelegt wird. Die vorher genannte Beschreibung und die Zeichnungen sind dementsprechend in einem veranschaulichenden statt in einem einschränkenden Sinne zu betrachten.

Claims

Vorrichtung zum Ermöglichen von Seitenübersetzungen, die Folgendes umfasst: einen Framebuffer auf mehrere Datenseiten; mehrere Anzeigeseitentabellen, um Übersetzungen von virtuellen Adressen in physische Adressen auf die Datenseiten im Framebuffer zu speichern; und eine Seitentabelle mit mehreren Seitentabelleneinträgen (PTEs), wobei jeder PTE auf eine der mehreren Anzeigeseitentabellen mappt.
Vorrichtung nach Anspruch 1, wobei jeder PTE einen Zeiger auf eine Anzeigeseitentabelle umfasst.
Vorrichtung nach den Ansprüchen 1 oder 2, wobei der Zeiger eine Komponente einer virtuellen Adresse, die in der Anzeigeseitentabelle gespeichert ist, umfasst.
Vorrichtung nach den Ansprüchen 1-3, wobei jeder PTE mit einem definierten Bereich des Framebuffer-Mappings verknüpft ist.
Vorrichtung nach den Ansprüchen 1-4, die des Weiteren einen Translation Lookaside Buffer (TLB) umfasst, der mehrere Einträge enthält, um die Übersetzungen von virtuellen in physische Speicheradressen zu speichern.
Vorrichtung nach den Ansprüchen 1-5, die des Weiteren Mapping-Hardware umfasst, um eine Seitenübersetzungsanforderung für eine Adresse zu empfangen.
Vorrichtung nach den Ansprüchen 1-6, wobei die Mapping-Hardware eine Suche im TLB nach einer Übersetzung beim Empfang der Seitenübersetzungsanforderung durchführt.
Vorrichtung nach den Ansprüchen 1-7, wobei die Mapping-Hardware in den PTEs in der Seitentabelle bei einer Bestimmung, dass der TLB keine Übersetzung enthält, sucht, um eine Adresse zu finden, die mit einer ersten der mehreren Anzeigeseitentabellen verknüpft ist.
Vorrichtung nach den Ansprüchen 1-8, wobei die Mapping-Hardware auf die erste Anzeigenseitentabelle zugreift, um die Übersetzung zu erfassen.
Verfahren zum Ermöglichen von Seitenübersetzungen, das Folgendes umfasst: eine Seitenübersetzungsanforderung für eine virtuelle Adresse zu empfangen; in einer ersten Seitentabelle zu suchen, um eine Adresse abzufragen, die mit einer ersten der mehreren Anzeigeseitentabellen verknüpft ist; in der ersten Anzeigeseitentabelle nach einer physischen Seitenübersetzung basierend auf der abgefragten Adresse zu suchen; und eine physische Adresse aus der ersten Anzeigeseitentabelle zurückzugeben.
Verfahren nach Anspruch 10, das des Weiteren umfasst, in einem Translation Lookaside Buffer (TLB) nach der physischen Seitenübersetzung zu suchen, bevor in der ersten Seitentabelle gesucht wird.
Verfahren nach den Ansprüchen 10 oder 11, wobei die erste Tabelle mehrere Seitentabelleneinträge (PTEs) umfasst, die jeweils einen Zeiger auf die mehreren Anzeigeseitentabellen enthalten.
Verfahren nach den Ansprüchen 10-12, wobei jeder PTE einen Zeiger auf eine Anzeigeseitentabelle umfasst.
Verfahren nach den Ansprüchen 10-13, wobei der Zeiger eine Komponente einer virtuellen Adresse, die in der Anzeigeseitentabelle gespeichert ist, umfasst.
Verfahren nach den Ansprüchen 10-14, wobei jeder PTE mit einem definierten Bereich des Framebuffer-Mappings verknüpft ist.
System zum Ermöglichen von Seitenübersetzungen, das Folgendes umfasst: einen Speicher, der Folgendes enthält: einen Framebuffer auf mehrere Datenseiten; mehrere Anzeigeseitentabellen, um Übersetzungen von virtuellen Adressen in physische Adressen auf die Datenseiten im Framebuffer zu speichern; und eine Speichermanagementeinheit (MMU), die mit dem Speicher gekoppelt ist, die eine Seitentabelle mit mehreren Seitentabelleneinträgen (PTEs) enthält, wobei jeder PTE auf eine der mehreren Anzeigeseitentabellen mappt.
System nach Anspruch 16, wobei die MMU des Weiteren einen Translation Lookaside Buffer (TLB) umfasst, der mehrere Einträge zum Speichern der Übersetzungen von virtuellen in physische Speicheradressen enthält.
System nach den Ansprüchen 16 oder 17, wobei die MMU des Weiteren Mapping-Hardware zum Empfangen einer Seitenübersetzungsanforderung für eine Adresse umfasst.
System nach den Ansprüchen 16-18, wobei die Mapping-Hardware eine Suche im TLB nach einer Übersetzung beim Empfang der Seitenübersetzungsanforderung durchführt.
System nach den Ansprüchen 16-19, wobei die Mapping-Hardware in den PTEs in der Seitentabelle bei einer Bestimmung, dass der TLB keine Übersetzung enthält, sucht, um eine Adresse zu finden, die mit einer ersten der mehreren Anzeigeseitentabellen verknüpft ist.
System nach den Ansprüchen 16-20, wobei die Mapping-Hardware auf die erste Anzeigenseitentabelle zugreift, um die Übersetzung zu erfassen.