DE102020118860A1

DE102020118860A1 - Techniken zum vorladen von texturen beim rendering von graphik

Info

Publication number: DE102020118860A1
Application number: DE102020118860.9A
Authority: DE
Inventors: Pranava Ajith Rai; Amit Jain
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2019-07-22
Filing date: 2020-07-16
Publication date: 2021-01-28
Also published as: CN112288619A; US10810784B1

Abstract

Systeme und Verfahren werden zum verbesserten Textur-Mapping und Graphikverarbeitung beschrieben. Gemäß einer beispielhaften Implementierung werden ganze oder Teile von Texturblöcken in einen Zwischen-Cache durch eine Verarbeitungseinheit vorabgerufen, so dass die gleiche Verarbeitungseinheit oder eine andere Verarbeitungseinheit anschließend den vorabgerufenen Texturblock aus dem Zwischen-Cache erhalten kann. Außerdem können in einigen beispielhaften Implementierungen Steuerschaltungen, die dem Zwischen-Cache zugeordnet sind, Vorababrufanforderungen drosseln, um zu vermeiden, dass das Speichersystem und/oder das Zwischenverbindungssystem übermäßige Mengen an Vorababrufanforderungen empfängt. Außerdem kann in einigen Implementierungen eine Entduplikation von Vorababrufanforderungen bei dem Zwischen-Cache und/oder der Verarbeitungseinheit durchgeführt werden. Einige Implementierungen umfassen auch eine effiziente Technik zum Berechnen der Adresse des nächsten vorabzurufenden Texturblocks.

Description

TECHNISCHES GEBIET
Diese Offenbarung betrifft Computergraphik, Textur-Mapping und genauer gesagt Systeme und Verfahren zum Abrufen von Texturen aus einem Speicher zur Graphikverarbeitung.
HINTERGRUND
Intelligente Fernseher, tragbare Telefone und andere intelligente Vorrichtungen, Videospielsysteme, Beförderungsmittel-Anwenderschnittstellen, wie beispielsweise Auto- und Flugzeug-Heads-Up-Anzeigen, intelligente Brillen und Virtual-Reality-Brillen und viele andere Vorrichtungen weisen die Fähigkeit auf, 3D-Computergraphik zu erzeugen. Benutzer erwarten gewöhnlicherweise, dass ihre Computergraphiksysteme in der Lage sind, photorealistische Bilder von beliebig komplexen Szenen in Echtzeit zu erzeugen. Eine gebräuchliche Art und Weise, die Komplexität einer Szene zu verringern, besteht darin, sie wie eine Oberfläche zu modellieren, auf die ein zusätzliches Bild abgebildet wird. Genauso wie ein Ölgemälde auf einer Leinwand, kann das gerenderte 3D-Modell anscheinend viele komplexe Elemente enthalten (z.B. das Spiel von Schatten und Licht auf der Kathedrale Notre Dame, die Tausenden von Blättern eines Baums, die Hunderten von Ziegeln in einer Ziegelmauer oder die exquisite Holzmaserung eines Konferenzraumtisches) während die Notwendigkeit vermieden wird, jedes derartige Element zu modellieren. Grundsätzlich wird ein Bild, das eine derartige Komplexität zeigt, auf Oberflächen des gerenderten Modells virtuell geklebt oder abgebildet. Das zusätzliche Bild wird herkömmlich als eine „Textur“ bezeichnet und der Prozess zum Anwenden der Textur auf der Modelloberfläche wird „Textur-Mapping“ genannt Häufig werden die Texturen erfasst oder zuvor erzeugt und im Speicher gespeichert. Wenn das Graphiksystem die Oberfläche rendert, ruft es die notwendigen Texturbilddaten (Texturelemente oder „Texel“) aus dem Speicher ab und wendet das Texturbild auf die Oberfläche unter Verwendung eines Abbildungsprozesses an, der das Bild entsprechend skaliert und filtert. Weil Texturen selbst reiche, komplizierte Bilder sein können, werden sie häufig komprimiert, um Speicheranforderungen zu verringern. Eine Graphikverarbeitung „Textur-Mapping-Vorrichtung“ umfasst häufig die Fähigkeit, Texturbilder zu dekomprimieren, wenn sie aus dem Speicher abgerufen werden. Des Weiteren können Texturen typischerweise in einer Vielfalt von unterschiedlichen Formaten abhängig von der Auslastung gespeichert werden.
Beispielsweise stellten einige frühere Graphiksysteme spezielle Textur-Cache-Speicher und Oberflächenspeicher bereit, die verwendet wurden, um Texturen in speziellen internen Formaten zu speichern, die einen effizienteren Zugriff bereitstellen. Als Beispiel sind gemäß der NVIDIA CUDA Programming Guide Version v10.1.105, die verwendet wird, um bestimmte NVIDIA-Produkte zu programmieren, CUDA Arrays (opake Speicheranordnungen, optimiert zum Texturabrufen) eindimensional, zweidimensional oder dreidimensional und aus Elementen zusammengesetzt, von denen jedes 1, 2 oder 4 Komponenten aufweist, die vorzeichenbehaftete oder vorzeichenlose ganzzahlige Werte oder Gleitkommawerte unterschiedlicher Auflösungen sein können. In einigen beispielhaften, nicht einschränkenden NVIDIA-Graphiksystemen sind CUDA-Arrays mittels Kernel durch Texturabrufen oder flächigen Lesen und Schreiben zugänglich. Ein Texturobjekt oder eine Texturreferenz spezifiziert die Textur hinsichtlich eines Stücks des Texturspeichers, das abgerufen wird. Eine Dimensionalität spezifiziert, ob die Textur wie ein eindimensionales Array unter Verwendung einer Texturkoordinate, ein zweidimensionales Array unter Verwendung von zwei Texturkoordinaten oder ein dreidimensionales Array unter Verwendung von drei Texturkoordinaten adressiert wird. Elemente des Arrays sind Texel. Die Texturbreite, Höhe und Tiefe bezieht sich auf die Größe des Arrays in jeder Dimension. In derartigen Implementierungen kann der Texturabruf selbst lineares Filtern oder „Mip-Mapping“ bereitstellen, das Wiederabtasten beinhalten kann, um die Textur auf einen bestimmten Ort einer Oberfläche abzubilden, auf der die Textur anzuzeigen ist.
Es war ebenfalls vorteilhaft, Texturen in unterschiedlichen Formaten für einen effizienteren Zugriff zu speichern. Siehe beispielsweise U.S. Patent Nr. 7,916,149 , das hier durch Bezugnahme aufgenommen ist. Insbesondere ist ein sogenanntes „Pitch linear“ Format bzw. „Pitch-lineares“ Format ein gebräuchliches Format zum Speichern von Texturen. In einem derartigen Pitch-linearen Format werden die Texel sequenziell in dem Speicher gespeichert, d.h., Texel in einer gegebenen Reihe eines rechteckigen Texturbereichs (der „Pitch“) werden sequenziell gespeichert und dann werden die Texel in der nächsten Reihe sequenziell gespeichert und so weiter. In einem derartigen Format wird jede Texelreihe somit in sequenziell zunehmenden Speicherorten gespeichert. Diese „Pitch-lineare“ Anordnung ist fein, wenn auf das Texel horizontal über jede Reihe zugegriffen wird. Typische Zugriffsmuster weisen jedoch häufig eine zweidimensionale (2D) (oder dreidimensionale (3D) für 3D-Texturen) räumliche Lokalität auf. Somit gehen Zugriffe, die zeitlich eng beabstandet sind, voraussichtlich an nahe gelegene Texel in jeder Richtung, nicht nur horizontal, weiter. Die Orientierung dieser räumlichen Lokalität kann gewöhnlicherweise nicht vorbestimmt werden, weil es häufig vom Blickpunkt des Beobachters abhängt. Somit wird die gleiche Textur unterschiedliche Muster von räumlicher Lokalität aufweisen, wenn sich der Beobachter umher bewegt.
Als eine Alternative können Texeldaten in einem computerlesbaren Medium in einem „Block linear“ Format bzw. „Block-linearen Format“ gespeichert werden. Im Block-linearen Format ist der Speicher in mehrere Blöcken logisch organisiert, die eine Funktion einer spezifischen Seitengröße einer bestimmten Implementierung (beispielsweise einer Cache-Zeilengröße) sind. Texel werden in xy(z) Blockreihenfolgebildung gespeichert. Innerhalb jedes Blocks werden die Texel sequenziell in dem Speicher gespeichert, d.h., Texel in einem vorgegebenen Block werden sequenziell gespeichert und dann werden die Texel in dem nächsten Block sequenziell gespeichert und so weiter. In einem derartigen Format wird jeder Texelblock somit in sequenziell zunehmenden Speicherorten gespeichert. In einem beispielhaften Block-linearen Format enthält eine Speicherseite 8 sequenzielle 4-Byte-Texels (z.B., 32 Bytes) in 32 sequenziellen Reihen. Die Speicherzugriffskosten (z.B. Latenzzeit) des linearen Blockformats ist proportional zu der Gesamtzahl der Seitengrenzen.
Eine Weise, ein derartiges „Block linear“ Format zu verwenden, um Seitenadressierungsstrafen weiter zu verringern, ist derartige Blöcke als Speicher-„Kacheln“ zu organisieren oder zu definieren. Alle Texel innerhalb einer Kachel befinden sich in der gleichen physischen oder virtuellen Speicherseite. Eine derartiges Kachelbildung kann Strafen beim Kreuzen von Speicherseiten verringern. Siehe beispielsweise https://developer.nvidia.com/gpugems/GPUGems2/gpugems2_chapter 12.html, eine elektronische Version von Kapitel 12 von GPU Gems 2 (NVIDIA 2005).
Während Altlast und Rückwärtskompatibilität ein Problem sein können, wurden die oben beschriebenen Vorgehensweisen durch technologische und konzeptionelle Fortschritte erheblich beeinträchtigt. Insbesondere ist die Graphikverarbeitungseinheit (GPU) nun in ihrer Struktur und ihrem Betrieb eine allgemeinere Hochleistungsrechenvorrichtung, die nicht auf Graphikverarbeitung beschränkt ist. Aus diesen und anderen Gründen werden die fest zugeordneten Textur-Caches der Vergangenheit viel weniger verwendet und sind viel weniger nützlich. Stattdessen wurde eine allgemeinere Speicherarchitektur unter Verwendung mehreren Cache-Speicherebenen (in einigen Aspekten den CPU-Cache-Speicherarchitekturen ähnlich) zunehmend verwendet, um die Speicherlatenzzeit von Hochleistung-GPUs zu verringern.
Im Einzelnen werden mit der Zunahme von Prozessorgeschwindigkeiten andere Aspekte der Prozessorlatenzzeit, wie beispielsweise Speicherzugriffslatenzzeit und Intra-Chip-Kommunikationslatenzzeiten, signifikanter. Parallelprozessoren, wie beispielsweise moderne Hochleistung-Graphikverarbeitungseinheiten (GPU), weisen mehrere schnelle Verarbeitungskerne auf und werden somit häufig sogar wesentlicher durch Speicherzugriffslatenzzeiten und dergleichen beeinflusst. Der Trend in modernen GPUs in Richtung einer zunehmenden Bedeutung von Speicherzugriffslatenzzeiten kann der Leistungsskalierung von neuen Mehrprozessor-GPUs schaden. In einer kürzlich freigegebenen GPU wird beispielsweise geschätzt, dass eine 50%-ige Zunahme in Gesamtrechenleistung in allen ihren Verarbeitungseinheiten eine Verbesserung in der Leistung von lediglich 32-39% im Mittel abhängig von den Arbeitslasten ergab. Wenn größere Chips gebaut werden, wird erwartet, dass die Latenzzeitbeschränkungen von Prozessoren weiter in der Bedeutung als ein Anteil des Gesamtsystemleistungsverlusts zunehmen werden.
Speicherzugriffanforderungen für eine GPU, die Graphikverarbeitung durchführt, können wesentlich von den Speicherzugriffanforderungen einer CPU unterschiedlich sein, die eine typische CPU-Arbeitslast ausführt. Weil Texturen sehr groß sein können, werden Texturzugriffe, wie oben erläutert, aufgrund der Speicherlatenzzeit eine der am meisten beeinflussten, und sie machen ebenfalls häufig den größten Chunk des Leseverkehrs von dynamischen Direktzugriffspeichern (DRAM) in typischen Graphikarbeitslasten aus. Texturverarbeitungseinheiten und/oder andere Prozessoren können Texturen (ebenfalls als „Textur-Maps“ bezeichnet) aus einem Speicher laden, so dass abgetastete Texturwerte zur Verwendung bei Schattierern und beim Bild-Rendering bereitgestellt werden können. Aufgrund des Fehlens einer angemessenen Latenzzeit, die sich in Textur-Mapping-Einheiten versteckt, oder einer anderen Unfähigkeit der Textur-Mapping-Einheiten, zu verhindern, dass die Texturabruflatenzzeit einen Flaschenhals verursacht, können Prozessoren ihre optimale Leistung nicht erreichen, wenn lange Speicherzugriffe in einer Arbeitslast auftreten. Beispielsweise sind Ausreißer der Speicherlatenzzeit von mehr als 1000 Taktzyklen nicht ungewöhnlich. Derartiges Verlangsamen von Prozessoren kann häufig zu Nichtauslastung des Speichersubsystem und zum Hungern des Speichersystems nach Anforderungen führen.
Herkömmliche Systeme setzen viele Techniken ein, um die Leistungsverschlechterungen zu mildern, die durch lange Speicherzugriffslatenzzeiten verursacht werden. Derartige Techniken umfassen Pipeline-Bildung (in CPU- und GPU-Umgebungen) und Datenvorabrufung (primär in CPU-Umgebungen). Diese herkömmlichen Techniken können sich jedoch nicht ausreichend den Latenzzeiten widmen, die dem Abrufen von großen und verschiedenartigen Texturen moderner Graphikverarbeitung zugeordnet sind. Daher werden verbesserte Systeme mit niedriger Latenzzeit und Techniken zum Zugreifen auf Texturen in Graphikverarbeitungssystemen gewünscht.
ZUSAMMENFASSUNG
Beispielhafte Ausführungsformen stellen einige der Unzulänglichkeiten der oben beschriebenen Techniken für Texturverarbeitung ab.
Eine beispielhafte Ausführungsform stellt ein Verfahren zum Anzeigen einer Szene bereit. Das Verfahren umfasst: während des Durchführens eines Textur-Mapping der Szene unter Verwendung eines ersten Blocks einer gespeicherten Textur, Erzeugen einer Vorababrufanforderung durch einen Prozessor, um alles oder Teil eines zweiten Blocks der gespeicherten Textur aus einem Speicher erster Ebene einer Speicherhierarchie abzurufen; Abrufen alles oder eines Teils des zweiten Blocks aus dem Speicher erster Ebene als Antwort auf die Vorababrufanforderung; Speichern des abgerufenen ganzen oder Teils des zweiten Blocks in einem Bereich eines Speichers der zweiten Ebene der Speicherhierarchie, wobei der Bereich des Speichers der zweiten Ebene durch den Prozessor und einem anderen Prozessor zugänglich ist, und wobei die zweite Ebene des Speichers eine Zwischenebene des Speichers zwischen der ersten Ebene des Speichers und einer dritten Ebene des Speichers in der Speicherhierarchie ist;
Durchführen eines Textur-Mapping der Szene unter Verwendung des abgerufenen ganzen oder Teils des zweiten Blocks; und
Rendering der Szene auf eine Anzeigevorrichtung. In einigen beispielhaften Implementierungen kann das Textur-Mapping der Szene unter Verwendung des ersten Blocks von dem Prozessor durchgeführt werden und das Textur-Mapping der Szene unter Verwendung des zweiten Blocks kann von dem anderen Prozessor durchgeführt werden.
Eine weitere beispielhafte Ausführungsform stellt ein Parallelverarbeitungssystem zum Anzeigen einer Szene bereit.
Die Szene umfasst mehrere Prozessoren, eine Cache-Hierarchie, die zumindest einen Cache-Speicher der ersten Ebene und einen Cache-Speicher der zweiten Ebene umfasst, eine Anzeigeschnittstelle und eine Speicherschnittstelle, die konfiguriert ist, um den mehreren Prozessoren Zugriff auf einen Off-Chip-Speicher bereitzustellen. Die mehreren Prozessoren und Steuerschaltungen, die der Cache-Hierarchie zugeordnet sind, sind konfiguriert um, während des Durchführens von Textur-Mapping der Szene unter Verwendung eines ersten Blocks einer gespeicherten Textur, eine Vorababrufanforderung durch einen ersten Prozessor der mehreren Prozessoren zu erzeugen, um alles oder Teil eines zweiten Blocks der gespeicherten Textur aus einer Speicherhierarchie abzurufen, welche die Cache-Hierarchie umfasst. Die mehreren Prozessoren und die der Cache-Hierarchie zugeordneten Steuerschaltungen sind ferner konfiguriert, um den angeforderten ganzen oder Teil des zweiten Blocks aus dem Off-Chip-Speicher über die Speicherschnittstelle als Antwort auf die Vorababrufanforderung abzurufen; den abgerufenen ganzen oder Teil des zweiten Blocks in einem Bereich des Cache-Speichers der zweiten Ebene zu speichern, wobei der Bereich des Cache-Speichers der zweiten Ebene durch den ersten Prozessor und einen zweiten Prozessor von den mehreren Prozessoren zugänglich ist, und wobei der Cache-Speicher der zweiten Ebene eine Zwischenebene des Speichers zwischen dem Off-Chip-Speicher und dem Cache-Speicher der ersten Ebene ist; Textur-Mapping der Szene unter Verwendung des abgerufenen ganzen oder Teil des zweiten Blocks durchzuführen ; und Rendern der Szene auf eine Anzeigevorrichtung über die Anzeigeschnittstelle.
Eine beispielhafte Ausführungsform stellt ein System-on-Chip (SoC) bereit, das zumindest eine zentrale Verarbeitungseinheit (CPU) und zumindest eine Parallelverarbeitungseinheit (PPU) umfasst, die mit der CPU verbunden ist. Jede PPU umfasst mehrere Multiprozessoren, mehrere Spezialfunktionseinheiten, eine Cache-Hierarchie, die zumindest einen Cache-Speicher der ersten Ebene und einen Cache-Speicher der zweiten Ebene umfasst, und eine Speicherschnittstelle, die konfiguriert ist, um
Zugriff auf einen Off-Chip-Speicher bereitzustellen.
Die mehreren Spezialfunktionseinheiten und die Steuerschaltungen, die der Cache-Hierarchie zugeordnet sind, sind konfiguriert, um als Antwort auf eine von einem der Multiprozessoren empfangenen Anweisung mehrere Operationen durchzuführen. Die Operationen umfassen, während des Textur-Mapping einer Szene unter Verwendung eines ersten Blocks einer gespeicherten Textur, Erzeugen einer Vorababrufanforderung durch eine erste Spezialfunktionseinheit von den mehreren Spezialfunktionseinheiten, um alles oder Teil eines zweiten Blocks der gespeicherten Textur aus einer Speicherhierarchie wiederzugewinnen, welche die Cache-Hierarchie umfasst. Die Operationen umfassen ebenfalls Abrufen des angeforderten ganzen oder Teil des zweiten Blocks aus dem Off-Chip-Speicher über die Speicherschnittstelle als Antwort auf die Vorababrufanforderung, Speichern des abgerufenen ganzen oder Teil des zweiten Block in einem Bereich des Cache-Speichers der zweiten Ebene, wobei der Bereich des Cache-Speichers der zweiten Ebene durch die erste Spezialfunktionseinheit und einer zweiten Spezialfunktionseinheit von den mehreren Spezialfunktionseinheiten zugänglich ist, und wobei der Cache-Speicher der zweiten Ebene eine Speicherzwischenebene zwischen dem Off-Chip-Speicher und dem Cache-Speicher der ersten Ebene ist, Textur-Mapping der Szene unter Verwendung des abgerufenen ganzen oder Teil des zweiten Blocks und Rendering der Szene auf einer Anzeigevorrichtung über eine Anzeigeschnittstelle.
Figurenliste

1A ist ein Blockdiagramm eines Systems, das ein verbessertes Textur-Rendering bereitstellt, gemäß bestimmter beispielhafter Ausführungsformen.
1B veranschaulicht eine beispielhafte Texturzuordnung zu Prozessorkerne.
1C veranschaulicht schematisch eine Textur, die in dem Speicher gemäß einem Pitch-linearen Format organisiert ist.
1D veranschaulicht schematisch eine Textur, die in dem Speicher gemäß einem Block-linearen Format organisiert ist.
1E veranschaulicht eine Beziehung zwischen den virtuellen Adressen von Texturdaten-Chunks im Speicher und der Zeit des Rendering für diesen Chunk gemäß einigen beispielhaften Ausführungsformen.
1F stellt eine weitere beispielhafte Veranschaulichung der im Speicher organisierten Texturdaten und ihre Beziehung zu der auf dem Bildschirm gerenderten Textur gemäß einigen beispielhaften Ausführungsformen bereit.
1G veranschaulicht die Beziehung zwischen einer Textur, einem Chunk und einem Block gemäß einigen beispielhaften Ausführungsformen.
2A ist ein Blockdiagramm einer Graphikverarbeitungseinheit, die in dem System von 1A verwendet werden kann, gemäß einigen beispielhaften Ausführungsformen.
2B zeigt ein Ablaufdiagramm für einen Prozess, der von einem Prozessor und/oder einer Texturverarbeitungseinheit einer GPU durchgeführt wird, um Texturdaten vorabzurufen, gemäß einigen beispielhaften Ausführungsformen.
2C zeigt ein Ablaufdiagramm für einen Prozess, der von der Speicherhierarchie als Antwort auf das Vorabrufen durchgeführt wird, das durch einen Prozessor und/oder einer Texturverarbeitungseinheit einer GPU eingeleitet wird, wie in 2B gezeigt, gemäß einigen beispielhaften Ausführungsformen.
3 veranschaulicht eine Parallelverarbeitungseinheit gemäß einer Ausführungsform.
4A veranschaulicht einen allgemeinen Verarbeitung-Cluster innerhalb der Parallelverarbeitungseinheit von 3 gemäß einer Ausführungsform.
4B veranschaulicht eine Speicherpartitionseinheit der Parallelverarbeitungseinheit von 3 gemäß einer Ausführungsform.
5A veranschaulicht den Streaming-Multiprozessor von 4A gemäß einer Ausführungsform.
5B ist ein Konzeptdiagramm eines Verarbeitungssystems, das unter Verwendung der Parallelverarbeitungseinheit (PPU) von 3 implementiert wird, gemäß einer Ausführungsform.
5C veranschaulicht ein beispielhaften System, bei dem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden kann.
6 ist ein Konzeptdiagramm einer Graphikverarbeitung-Pipeline, die durch die PPU von 3 implementiert wird, gemäß einer Ausführungsform.

AUSFÜHRLICHE BESCHREIBUNG
Ausführungsformen der vorliegenden Erfindung sehen effizienteres Textur-Mapping durch Verringern von Speicherzugriffslatenzzeiten vor, die dem Zugreifen auf Texturdaten im Speicher während einer Graphikverarbeitung zugeordnet sind. Obwohl Pipeline-Bildungstechniken die einem Texturzugriff zugeordneten Verlangsamungseffekte in verschiedenen Anwendungen verringern kann, ist es häufig der Fall, dass durch Pipelinebildung-Techniken bereitgestelltes Verbergen von Latenz für einige der längeren Latenzzeiten unangemessen ist, die bestimmten Texturzugriffen zugeordnet sind. Herkömmliche Vorabruftechniken können ebenfalls, wie beispielsweise jene, die von CPUs verwendet werden, wirksam für eine Texturverarbeitung in Umgebungen mit mehreren Prozessoren nicht ausreichend sein. Beispielhafte Ausführungsformen stellen verbesserte Texturvorabruftechniken und Systeme bereit, die verbesserte Speicherauslastung und/oder verringerte wirksame Speicherlatenzzeit während der Graphikverarbeitung ergeben, um dadurch eine verbesserte Systemleistung zu ergeben.
Bestimmte beispielhafte Ausführungsformen verbessern Speicherauslastung und/oder verringern wirksame Speicherlatenzzeit in GPUs. Die Verbesserungen werden durch spekulatives Abrufen von Daten erreicht, die tatsächlich noch nicht von irgendeiner Verarbeitungseinheit in einem Zwischen-Cache, wie beispielsweise einem Cache-Speicher der zweiten Ebene (L2-Cache), abgerufen wurden. Das spekulative Abrufen, bevor die Daten tatsächlich von einer Verarbeitungseinheit angefordert werden, wird hier als „Vorabrufen“ bezeichnet, und die Anforderung, die ein derartiges spekulatives Abrufen einleitet, wird hier als eine „Vorababrufanforderung“ bezeichnet. Im Einzelnen sehen bestimmte beispielhafte Ausführungsformen das Vorabrufen von Teilen oder alles eines anderen (z.B. einem nächsten sequenziellen) Blocks von Texturinformation in den L2-Cache-Speicher einer GPU vor, während der aktuell geladene Block von Texturinformation durch die Texturverarbeitungseinheiten und/oder andere Verarbeitungseinheit der GPU verwendet und verarbeitet wird. Derartige spekulative Vorabrufungen können manchmal Texturdaten abrufen, die dabei enden, tatsächlich nicht verwendet oder benötigt zu werden (z.B., wie die NASCAR-Boxenstoppmannschaft, die einen neuen Satz von Reifen gerade in dem Fall bekommt, wenn der Rennfahrer einen weiteren Reifenwechsel benötigt, bevor das Rennen endet), können jedoch beim Verringern der Wartezeit zum Abrufen neuer Texturdaten aus dem Speicher wirksam sein, wenn die vorabgerufenen Daten abgeholt und zum Textur-Mapping benötigt werden.
Während spekulatives Vorabrufen primär in CPU-Zusammenhängen bekannt ist, betrifft eine Herausforderung, derartige Techniken in einem Texturabrufkontext anzuwenden, wie vorherzusagen ist, welche Textur-Map-Daten die Textur-Mapping-Vorrichtung als nächstes oder in der Zukunft benötigen wird. Aufgrund einer Anzahl von Faktoren ist Textur-Mapping häufig kein vollständig vorhersagbarer Prozess. Das heißt, dass es im Gegensatz zu der NASCAR-Boxenmannschaft, die genau weiß, welche Reifen der Fahrer beim nächsten Reifenwechsel benötigen wird, es schwierig sein kann, vorherzusagen, welchen Block von Texturdaten die Textur-Mapping-Vorrichtung als nächstes benötigen wird, wenn sie die Verarbeitung der Texturdaten abgeschlossen hat, die sie bereits aus dem Speicher abgerufen hatte. Daher wurde bei vergangenen Versuchen wurde nicht notwendigerweise nachgewiesen, dass Vorabrufen/spekulativen Lasten von Texturinformation für hochparallele Graphikarbeitslasten nützlich sind. Dieses Fehlen von nachgewiesenem Erfolg ist zumindest teilweise auf Schwierigkeiten beim Vorhersagen oder Inferieren von Textur-Map-Zugriffsmustern zurückzuführen. Die Herausforderung ergibt sich, weil Texturspeicherzugriffe sehr variable von Faktoren abhängig sind, wie beispielsweise Blickpunkt, Oberflächenorientierung und dergleichen. Die Notwendigkeit, Leistungsregressionen aufgrund von Cache-Thrashing und/oder nicht relevanten DRAM-Verkehr zu vermeiden, trägt zu der Komplexität bei.
Bestimmte beispielhafte Ausführungsformen nehmen häufige Speicherzugriffsmuster ins Visier, wie beispielsweise Vollbildzeichnen zur gesteigerten Effizienz. Derartige beispielhafte Ausführungsformen, während sie die Systemleistung in vielen Typen von Textur-abgebildeten Anzeigen verbessern können, sind besonders beim Verbessern eines Texturzugriffs hochwirksam, dem Vollbildzeichnen zugeordnet ist. Vollbildzeichnen tritt sehr häufig in Spieleanwendungen jedoch ebenfalls in vielen anderen Anwendungen auf. Ein Vollbildzeichnen beinhaltet Rendering eines Bildes auf dem gesamten Bildschirm und wird typischerweise durch eine spezifische Anweisung verursacht, die in dem Anwendungsprogramm enthalten ist. In vielen Spielen und anderen Anwendungen, wenn ein Vollbildzeichnen durchgeführt wird, beinhaltet die Art und Weise, bei der im Speicher gespeicherte Texturdaten konsumiert werden, ein spezifisches Muster einer Speicheradressentraversierung. Die Texturvorabruftechniken von beispielhaften Ausführungsformen machen sich derartige Speicheradressen-Traversierungsmuster zu nutze.
Beispielsweise könnte ein Vollbildzeichnen einer Textur tatsächlich am effizientesten durch ein Pitch-lineares Texturformat bedient werden, da man sich gewöhnlicherweise darauf verlassen kann, dass das Vollbildzeichnen auf jedes Texel in aufsteigender horizontaler Reihenfolge zugreift. Die gleiche Textur kann jedoch ebenfalls in anderen Zusammenhägen als Vollbildzeichnen verwendet werden, wobei räumliche Lokalität nicht vorher vorhersagbar sein kann. Als Beispiel sei ein Szenario einer virtuellen Realität betrachtet, bei dem eine Szene eine virtuelle Computeranzeige enthält (d.h. eine Anzeige innerhalb der Anzeige für virtuelle Realität). Der Benutzer kann, abhängig von dem Blickpunkt, die virtuelle in-Szene Anzeige in einer Vielfalt von unterschiedlichen Orientierungen betrachten (z.B. von der Seite oder sogar auf dem Kopf). Der Benutzer kann dann jedoch seine Betrachtungsausrichtung und Betrachtungsposition verschieben, um die virtuelle Anzeige frontal zu betrachten, um den gesamten Betrachtungskegelstumpf auszufüllen. In diesem einfachen Beispiel können Effizienzen das Ergebnis des Speicherns der Textur in Block-linearem Format sein, wobei das Block-lineare Format jedoch nicht die effizienteste Speicherdarstellung für all Verwendungen der Textur sein kann (z.B., wenn es über den gesamten Bildschirm der Anzeige für virtuelle Realität angezeigt wird).
In bestimmten beispielhaften Ausführungsformen wird, während des Durchführens des Vorabrufens von Texturdaten, der Versatz für einen Block, aus dem Daten vorabzurufen sind, auf einer pro Texturgrundlage unter Verwendung von Information von dem Textur-Header dynamisch berechnet. Die dynamische Berechnung ermöglicht dem System, getrennte Versätze in gleichzeitigem Gebrauch für unterschiedlich-dimensionierte Texturen aufzuweisen.
In bestimmten beispielhaften Ausführungsformen kann die Verarbeitungseinheit, welche die Vorababrufanforderung ausführt, von der Verarbeitungseinheit unterschiedlich sein, die anschließend die vorabgerufenen Daten verwendet und somit davon profitiert.
Außerdem sind in bestimmten beispielhaften Ausführungsformen Drosselmechanismen für Vorababrufanforderungen enthalten, um sicherzustellen, dass die Speicherhierarchie durch das Vorabrufen nicht überwältigt wird. Außerdem kann eine Entduplikation von Anforderungen durchgeführt werden, um die Effizienz des Vorabrufens zu verbessern. Diese Optimierungen können zum Verringern von Speicherlatenzzeiten führen, wie durch die Textureinheiten und/oder anderen Verarbeitungseinheiten gesehen wird, und können ebenfalls Cache-Trefferquoten verbessern.
In Experimenten, die beispielhafte Ausführungsformen verwenden, wurde in einer Block-linearen Anordnung gespeicherte Texturinformation in einer Art und Weise vorabgerufen, welche die Systemleistung wesentlich verbesserte. Obwohl die Block-lineare Anordnung (nachstehend in Relation zu 1D beschrieben) der Texturinformation in dem Speicher und die durch die lineare Blockanordnung ermöglichte zugeordnete Adressenberechnung bestimmte Effizienzen bereitstellen, sind Ausführungsformen nicht auf die Verwendung von Block-linearen Anordnungen der Textur beschränkt.
Systeme zur Texturvorabrufung
1A veranschaulicht ein schematisches Blockdiagramm eines Systems 100, das konfiguriert ist, um eine Texturvorabrufung durchzuführen, welche die Leistungsverschlechterungen verringert, die Speicherzugriff-Latenzzeitwirkungen zugeordnet sind, gemäß einigen beispielhaften Ausführungsformen. Das System 100 kann ein System-on-Chip (SoC) sein, das eine oder mehrere zentrale Verarbeitungseinheiten (CPUs) 104 und/oder Graphikverarbeitungseinheiten (GPUs) 102 umfasst.
Die GPU 102 kann Anweisungen und Daten von der CPU 104 über eine Host-Schnittstelle 110 empfangen. Die GPU 102 greift auf einen Graphikspeicher 114 über einen Graphikspeichercontroller 105 zu und kann ebenfalls Daten von einem Systemspeicher 108 über die Host-Schnittstelle 110 und einem Systemspeichercontroller 106 anfordern. Der Systemspeicher 108 kann zwischen mehreren Verarbeitungseinheiten in dem System, wie beispielsweise der CPU 104 und GPU 102, gemeinsam genutzt werden. Die in dem Graphikspeicher 114 gespeicherten Graphikdaten, wie beispielsweise Framebuffer-Information, können auf einer Anzeige 118 über einen Anzeigencontroller 116 angezeigt werden.
Die GPU 102 umfasst mehrere Verarbeitungskerne 122 und mehrere Texturverarbeitungseinheiten 120. Die Verarbeitungskerne können parallele Verarbeitungsprozessoreinheiten umfassen, die eine große Anzahl von parallelen Threads ausführen können. Die Verarbeitungskerne empfangen und führen Anweisungen von der CPU 104 oder einem anderen Prozessor in dem System 100 aus.
Die GPU 102 umfasst eine Cache-Hierarchie 124. Die Cache-Hierarchie 124 umfasst zwei oder mehr Ebenen von Cache-Speichern. Die Cache-Hierarchie kann strukturiert sein, so dass jeder Cache-Speicher höherer Ebene zwei oder mehr Cache-Speicher bei der nächsten unteren Ebene bedient. Beispielsweise kann auf einen Cache-Speicher der zweiten Ebene (d.h. „L2-Cache“) 126 von zwei oder mehr Cache-Speichern der ersten Ebene (d.h. „L1-Cache“) 128 zugegriffen werden. In dieser Offenbarung wird die Cache-Hierarchie 124 in Kombination mit dem Graphikspeicher 114 und dem Systemspeicher 108 als die „Speicherhierarchie“ bezeichnet. Während des Betriebs der GPU 102 kann, wenn angestrebt wird, auf ein Stück von Daten zuzugreifen, ein bestimmter Verarbeitungskern 122 zuerst seinen L1-Cache, dann den L2-Cache und dann den Graphikspeicher 114 oder den Systemspeicher 108 durchsuchen.
Dies ist vergleichbar mit einem Koch, der seine Vorratskammer durchsucht, bevor zum Laden zu gehen, um ein für ein Rezept benötigtes bestimmtes Bestandteil abzuholen. Wenn der Artikel in der Vorratskammer ist, kann der Koch ihn unmittelbar verwenden. Wenn der Artikel nicht in der Vorratskammer ist, muss der Koch jemand zu dem Laden schicken, um ihn zu bekommen, was Zeit erfordert. Wenn der Laden ihn nicht vorrätig hat, muss der Laden ihn von einem Lieferanten bestellen, was sogar mehr Zeit erfordert. Somit ist die „Latenzzeit“ oder Zeitverzögerung, die dem Erhalten von Bestandteilen aus der lokalen Vorratskammer in ihrem Heim zugeordnet ist, ziemlich niedrig, wobei man jedoch ebenfalls keinen Platz in ihrer Vorratskammer aufweisen muss, um alles das zu speichern, was möglicherweise benötigt wird, und außerdem könnten einige dieser Artikel verderben oder Frische verlieren, wenn sie in der Vorratskammer gespeichert sind. Ein Abholen derartiger Artikel aus dem Laden kann die zusätzliche Latenzzeit wert sein. Dennoch kann es für den Koch hilfreich sein, im Voraus zu planen, so dass man alle notwendigen Bestandteile aufweist, bevor mit dem Kochen begonnen wird.
Genau wie bei der obigen Vorratskammeranalogie sind die Speicherzugriffslatenzzeiten unterschiedlich, die dem Zugriff auf die jeweiligen Ebenen in der Speicherhierarchie zugeordnet sind. Ein bestimmter Kern 122 greift beispielsweise auf Daten in seinem L1-Cache 128 mit weniger Latenzzeit als Daten in dem L2-Cache 126 zu. Beim Zugreifen auf den Graphikspeicher 114 oder den Systemspeicher 108 fallen erheblich mehr Taktzyklen als beim Zugreifen auf den L2-Cache an.
Die Texturverarbeitungseinheiten 120 sind spezialisierte Verarbeitungseinheiten zur Verarbeitung von Texturinformation, die auf Szenen in Bildern zu rendern ist, die anzuzeigen sind. Während des Durchführens der Graphikverarbeitung, die beispielsweise dem Rendering eines Bild auf einer Anzeige zugeordnet ist (z.B. Graphikverarbeitung-Pipeline), können sich Kerne 122 auf Texturverarbeitungseinheiten 120 stützen, um das Textur-Mapping dieses Bildes durchzuführen. Jede GPU 102 kann eine oder mehrere Texturverarbeitungseinheiten 120 umfassen. Die Texturverarbeitungseinheiten 120 können nicht auf Textur-Mapping beschränkt sein und können ebenfalls andere Verarbeitungsaufgaben als jene durchführen, die sich auf Texturinformation beziehen.
Die Texturinformation umfasst Metriken, welche die Textur eines Bildes und jeweilige Objekte in dem Bild definieren. Die Texturinformation kann Information über die räumliche Anordnung von Farbe oder Intensitäten in verschiedenen Bereichen des Bildes umfassen. Die Texturdaten können durch Bildverarbeitung berechnet werden. Häufig ist die Texturinformation, die dem Bild zugeordnet ist, das auf dem Anzeigebildschirm anzeigen ist, zu groß, um in einem Speicher on-Chip auf der GPU gespeichert zu werden, und wird daher in einem externen Speicher (z.B. einem Off-Chip-Speicher) gespeichert, wie beispielsweise dem Systemspeicher 108 oder dem Graphikspeicher 114 (z.B. Texturdaten 130 im Systemspeicher 108 oder Texturdaten 132 im Graphikspeicher 114) .
Wie obenstehend bemerkt, kann der Abruf von Texturinformation aus dem Systemspeicher häufig lange Latenzzeiten auf sich ziehen, was zu Ineffizienzen in dem System führt. In einigen Fällen können derartigen Latenzzeiten in den Tausenden von Taktzyklen sein. In beispielhaften Ausführungsformen können die Textureinheiten 120, die Verarbeitungskerne 122 und/oder die Cache-Speicherhierarchie 124 mit zusätzlichen Schaltungen konfiguriert sein, um Vorabrufen von Texturdaten durchzuführen, um die dem Texturdatenzugriff zugeordnete Latenzzeit zu verringern. Eine Beschreibung hinsichtlich der Konfiguration der GPU 102, um das Vorabrufen gemäß beispielhaften Ausführungsformen bereitzustellen, wird nachstehend in Relation zu 2A usw. bereitgestellt. 3 und die zugeordnete Beschreibung stellen ausführlichere Information über eine beispielhafte Parallelverarbeitungseinheit (PPU) bereit, die der GPU 102 entsprechen kann.
1B zeigt eine beispielhafte logische Unterteilung eines Vollanzeigebildschirmbereichs 140 in rechteckige Kacheln, so dass die auf dem Bildschirm 140 zu rendernde Texturinformation zwischen mehreren Textureinheiten 120 verteilt werden kann. Das veranschaulichte Beispiel zeigt Texturinformation 144, die einen Bereich des Bildschirms 140 belegt. Die Texturinformation ist in 1B in drei unterschiedlichen Füllmustern veranschaulicht. Wenn die GPU 102 angewiesen wird, ein Objekt, wie beispielsweise ein Objekt 142 auf einem Bildschirm zu rendern, können eine oder mehrere Verarbeitungskerne 122 der GPU 102 das Textur-Mapping des Objekts 142 in der gezeigten Art und Weise zuteilen. Das heißt, dass das Textur-Mapping des Objekts 142 jeweils vier (T1-T4) der Texturverarbeitungseinheiten 120 in der gezeigten Art und Weise zugeteilt werden kann. Jede der Texturverarbeitungseinheiten 120 wendet die Textur 144 auf jeweilige Abschnitte der Oberfläche(n) des Objekts 142 an, wie beispielsweise in 1B gezeigt.
Die Verteilung der Texturinformation 144 zwischen den Texturverarbeitungseinheiten T1-T4 kann durch eine Kernverarbeitungseinheit (z.B. der Kernverarbeitungseinheit 120) in der GPU gesteuert werden. In bestimmten beispielhaften Ausführungsformen kann eine Anweisung von der Kernverarbeitungseinheit an eine Texturverarbeitungseinheit Informationen umfassen, welche die Textur 144, das Texturabzubildende Objekt 142 und den Abschnitt 142 beschreibt, der durch diese Texturverarbeitungseinheit Textur-abzubilden ist. Die von der Kernverarbeitungseinheit der Texturverarbeitungseinheit bereitgestellte Texturinformation 144 kann einen Header für die Texturinformation 144 umfassen, der die Größe und die Koordinaten der Textur, die Größe von Blöcken, in denen die Texturinformation im Speicher gespeichert wird, usw. beschreibt. Basierend auf der Information in dem Textur-Header, der Objektinformation und der Information hinsichtlich des zugewiesenen Abschnitts des Objekts kann jede Texturverarbeitungseinheit die Texturinformation bestimmen, die abzurufen ist, um das Textur-Mapping des Abschnitts des Objekts durchzuführen, das ihm zugewiesen ist.
Wie in 1B ersichtlich ist, kann während des Textur-Mapping einer bestimmten Szene jede Texturverarbeitungseinheit T1-T4 mehrere Abschnitte des gleichen Objekts und jeweilige entsprechende Abschnitte der Textur zugewiesen werden. Die Zuweisung kann durch die Kachelmuster der Texturverarbeitungseinheiten über den Bildschirmbereich und die Position, Größe und Form der Textur und dem Objekt oder der Szene, die Textur-abgebildet werden soll, bestimmt werden.
Das in 1B gezeigte Muster der Zuweisung von Texturprozessoren ist ein Beispiel und ist nicht einschränkend. In beispielhaften Ausführungsformen kann Texturinformation zwischen einer beliebigen Anzahl von zwei oder mehr Texturverarbeitungseinheiten gemäß einem beliebigen Muster der Zuweisung verteilt werden. Beispielhafte Ausführungsformen sind nicht auf irgendein Kachelmuster von Texturverarbeitungseinheiten über einen Bildschirmbereich oder irgendeine bestimmte Textur oder Szenen- /Objektcharakteristiken beschränkt.
1C veranschaulicht eine beispielhafte, nicht einschränkende Textur 154, die im Speicher gemäß einem Pitch-linearen Format organisiert ist. Beispielsweise wird ein 16 × 16 Texelbereich gezeigt, wobei die innerhalb der Textur angegeben Zahlen die jeweiligen virtuellen Speicheradressen (oder Versätze einer virtuellen Speicheradresse) darstellen, bei denen die Texel gespeichert sind. Die Größe eines Texels, in Byte, kann sich von Textur zu Textur abhängig von derartigen Dingen wie dem Detaillierungsgrad in der Auflösung der Textur unterscheiden. Die Größe eines Texels in Byte in einer bestimmten Textur kann in dem Header dieser Textur angegeben werden.
Gemäß dem Pitch-linearen Format zum Speichern von Texturinformation im Speicher wird jede Reihe von Texeln von oben nach unten der Textur in einer Art und Weise ausgelegt, die bei dem oberen linken Rand des Speicherbereichs beginnt und sich dann horizontal von links nach rechts erstreckt, bevor mit dem Speichern der nächsten Reihe von Texeln begonnen wird (z.B. von links nach rechts und oben nach unten). 1C zeigt Texel 0-255 der Textur 154, die im Speicher in einer Pitch-linearen Art und Weise angeordnet sind. Das heißt, dass jede Reihe von Texeln der Textur 154, wie sie in einem gerenderten Bild auf dem Anzeigebildschirm abgebildet werden kann, in einer Reihe in dem virtuellen Speicher gespeichert wird. Der Speicher, in dem die Textur 154 gespeichert wird, kann beispielsweise ein externer Speicher sein, wie beispielsweise der Systemspeicher 108 oder der Graphikspeicher 114.
1D veranschaulicht eine Textur 156, die im Speicher gemäß einem Block-linearen Format organisiert ist. Wie in 1C, zeigt 1D ebenfalls ein Beispiel einer 16 × 16 Pixelbereich-Bildschirmanordnung, wobei die Zahlen innerhalb der Textur 156 die jeweiligen virtuellen Speicheradressen (oder Versätze von einer virtuellen Speicheradresse) spezifiziert in Texeln darstellen. Das Block-lineare Format wird für viele 2D- und 3D-Zugriffsmuster optimiert. Wie in 1D gezeigt, sind Texel 0-15 und 16-31, die der ersten Reihe und der zweiten Reihe in der Anordnung der Textur 156 in dem Speicher entsprechen, jeweils ein rechteckiger 4x4 Texelbereich (ein „Block“) auf dem Bildschirm. In der beispielhaften Block-linearen Anordnung entspricht jede Reihe von Texeln im Speicher einem 4x4 Block und jeweils vier aufeinanderfolgende Reihen von Texeln im Speicher entsprechen einem 8x8 Block. In 1C und 1D wird jede 16-Texelreihe in der Speicherauslegung durch ein unterscheidbares Füllmuster dargestellt.
1E veranschaulicht Texturanforderungen, die sich aus einem Vollbildzeichnen ergeben. Das veranschaulichte beispielhafte Muster zeigt die virtuellen Adressen der Speicherblöcke, die Texturinformationen im Laufe der Zeit halten. Die x-Achse stellt zunehmende Zeit von links nach rechts dar und die y-Achse stellt zunehmende virtuelle Adressen von unten nach oben dar. Jeder schattierte Bereich stellt einen Chunk des Speichers dar, auf den zugegriffen wird, und der Ort des schattierten Bereichs in dem Graphen stellt seine Position in der Zeit und seine virtuelle Adresse in Relation zum Anfang der Zugreifens auf Texturdaten für dieses Vollbild dar. Jeder Chunk ist aus einem oder mehreren angrenzenden Blöcken aufgebaut. In ihrer Gesamtheit veranschaulicht 1E die Texturdaten, auf die zum Zeichnen eines Vollbilds zugegriffen wird.
Der Chunk 152 stellt den virtuellen Adressraum dar, der aktuell von den Textureinheiten verwendet wird, welche die Textur für den Bildschirm verarbeiten. Wie veranschaulicht, ist der Versatz, der jedem Chunk 152 zugeordnet ist, die Höhe 150 jedes Blocks (z.B. in Texel). Das heißt, dass die Höhe jedes Chunk (z.B. in Texel) verwendet werden kann, um den Versatz zwischen aufeinanderfolgend angeforderten Chunks darzustellen. In einigen beispielhaften Ausführungsformen kann der Chunk eine Höhe von einem Block aufweisen.
1F stellt eine weitere beispielhafte Veranschaulichung der im Speicher organisierten Texturdaten und ihre Beziehung zu der auf dem Bildschirm gerenderten Textur gemäß einigen beispielhaften Ausführungsformen dar. Diese Figur veranschaulicht, wie sich jede Reihe von Texturinformation 160 in dem Speicher auf einen Chunk 158 gemäß einer Block-linearen Anordnung abbildet.
1G veranschaulicht ferner graphisch, dass in einigen beispielhaften Ausführungsformen die Texturoberfläche 160 mehrere Chunks umfasst, wie beispielsweise Chunk 158, und dass jeder Chunk mehrere Blöcke umfasst, wie beispielsweise die in der linearen Blockanordnung von Textur gezeigten Blöcke in 1D. In dem veranschaulichten Beispiel entspricht jede Zeile der Texturinformation 160 einem jeweiligen Chunk.
2A ist ein Blockdiagramm einer GPU, die in dem System von 1A verwendet werden kann, gemäß einigen beispielhaften Ausführungsformen. Beispielsweise kann die GPU 200 der in 1A gezeigten GPU 102 entsprechen.
Die GPU 200 umfasst Verarbeitungskerne 201 (Verarbeitungskern 201a und Verarbeitungskern 201b), Texturverarbeitungseinheiten 202 (Textureinheit A 202a und Textureinheit B 202b), Cache-Hierarchie 204 und eine Schnittstelle 210 zu dem Graphikspeicher (z.B. dem Graphikspeicher 114) und/oder einen externen Speicher, wie beispielsweise einen Systemspeicher (z.B. den Systemspeicher 108).
In der Cache-Hierarchie 204 kann auf jeden L1-Cache 206 durch einen Verarbeitungskern und eine Textureinheit zugegriffen werden. Beispielsweise ist der L1-Cache 206a dem Verarbeitungskern 201a und der Textureinheit A 202a zugänglich und der L1-Cache 206b dem Verarbeitungskern 201b und der Textureinheit B 202b zugänglich. Die Prozessorkerne 201 oder Textureinheiten 202 können auf den L2-Cache 208 für Daten zugreifen, die nicht in den L1-Caches 206 gefunden werden. Wenn die Daten nicht im L2-Cache 208 gefunden werden, dann kann auf den externen Speicher (z.B. Off-Chip-Speicher, wie beispielsweise Systemspeicher oder Graphikspeicher) durch die Schnittstelle 210 zugegriffen werden, um die Daten zu erhalten.
Beispielhafte Ausführungsformen veranlassen jede Textureinheit, während sie einen ersten Block von Texturinformation verarbeitet (oder nachdem sie den ersten Block von Texturinformation abruft und bevor sie die Verarbeitung desselben abschließt), alle oder Teile von Daten von einem zweiten Texturinformationsblock vorabzurufen. Die Verarbeitung eines Blocks von Texturinformation kann das Verwenden dieses Texturinformationsblocks zum Textur-Mapping eines Objekts und/oder einer Szene umfassen. Blöcke einer Vorabruflogik 214 (z.B. Vorabruflogik 214a und 214b) umfassen Hardwareschaltungen zum Berechnen der Adresse des vorabzurufenden Blocks von Texturinformation. Die Adresse des vorabzurufenden Blocks wird basierend auf der Adresse der Blocks, der aktuell verarbeitet wird, und einem Versatz berechnet. Die Texturvorabruflogik 214 kann ebenfalls eine Entduplikationsanforderung implementieren, um die Menge an doppelten Vorababrufanforderungen zu verringern, die an den L2-Cache übertragen werden.
Gemäß beispielhaften Ausführungsformen wird die aus dem externen Speicher vorabgerufene Texturinformation 215 in dem L2-Cache 208 gespeichert und nicht der anfordernden Texturverarbeitungseinheit und/oder dem Verarbeitungskern bereitgestellt. Die vorabgerufene Texturinformation 215 im L2-Cache ist mehreren Texturverarbeitungseinheiten und/oder mehreren Prozessorkernen verfügbar, die mit diesem L2-Cache verbunden sind. Hardwareschaltungen der Texturvorabruflogik 216, die konfiguriert sind, um die vorabgerufene Information zu speichern, können in den Steuerschaltungen sein, die dem L2-Cache 208 zugeordnet sind.
Ein Zähler für anstehende Vorababrufanforderungen 218 ist ebenfalls den Schaltungen der Texturvorabruflogik 216 zugeordnet. Der Zähler für anstehende Vorabrufe 218 verfolgt den Zählwert der Anzahl von Texturvorababrufanforderungen 212, die unerledigt sind. Das heißt, dass gemäß einer Ausführungsform an dem L2-Cache der Zähler inkrementiert wird, wenn eine Texturvorababrufanforderung von den Schaltungen des L2-Cache an einen externen Speicher übertragen wird, und dekrementiert wird, wenn Texturinformation, die der Anforderung entspricht, in dem L2-Cache empfangen und gespeichert wird. In Kombination mit dem Zähler für anstehende Vorababrufanforderungen 218 kann die Texturvorabruflogik einen Drosselmechanismus implementieren, um ankommende Vorababrufanforderungen stillschweigend fallenzulassen, wenn der Zählwert der anstehenden Vorababrufanforderungen eine vordefinierte Schwelle überschreitet. Die Texturvorabruflogik 216 kann ebenfalls eine Entduplikationsanforderung implementieren, um die Menge an doppelten Vorababrufanforderungen zu verringern, die an den externen Speicher übertragen wird. Die Entduplikation und/oder das Drosseln kann zumindest in einigen Ausführungsformen notwendig sein, um das Vorabrufen von Texturen effizient durchzuführen, während das Speichersystem und Systemzwischenverbindungen nicht mit irrelevanten Vorababrufanforderungen überfordert werden.
Gemäß einigen Ausführungsformen kann die GPU 200 der PPU 300 entsprechen, die beispielsweise in 3 gezeigt und in Relation zu 3-6 beschrieben wird. Die Kernprozessoren 201 können den Streaming-Multiprozessoren (SM) 440 entsprechen und die Texturverarbeitungseinheiten 202 können den Spezialfunktionseinheiten (SFU) 552 entsprechen. In derartigen Ausführungsformen kann das in Relation zu Prozessen 220 und 240 beschriebene Texturvorabrufen während der Verarbeitung der Graphik-Pipeline durchgeführt werden, die beispielsweise in Relation zu 6 beschrieben ist.
Beispielhaftes Texturvorabrufverfahren
2B zeigt ein Ablaufdiagramm für einen Prozess 220, durch den ein Prozessor Texturinformation zur Verarbeitung anfordert, gemäß bestimmter beispielhafter Ausführungsformen. Der Prozess 220 kann von einer Kernverarbeitungseinheit und/oder einer Texturverarbeitungseinheit durchgeführt werden. In einigen beispielhaften Ausführungsformen wird der Prozess 220 von der Vorabruflogik 214 (z.B. in Vorabruflogikschaltungen 214a und/oder 214b) gezeigt in 2A durchgeführt. Der Klarheit halber wird der Prozess 220 nachstehend in Relation zu der Texturverarbeitungseinheit 202a und der Kernverarbeitungseinheit 201a beschrieben, wobei der Prozess 220 jedoch nicht auf diese Verarbeitungseinheiten beschränkt ist.
Nach Eintreten in den Prozess 220 bestimmt während der Verarbeitung eines Texturinformationsblocks n bei Operation 222 die Texturverarbeitungseinheit 202a einen Texturinformationsblock n+k, aus dem Daten vorabzurufen sind. k ist die Versatzgröße (ebenfalls der Vorabversatz genannt), die als ein Vielfaches k der Blockgröße ausgedrückt wird. Jeder der Blöcke n und n+k kann ein Block einer größeren Texturinformation A sein (z.B. ein Block aus Pixel/Texel 0-15 der in 1D gezeigten Textur 156). Gemäß einer beispielhaften Ausführungsform beginnt die Texturverarbeitungseinheit 202a die Verarbeitung von Block n als Antwort auf die Verarbeitung von Block n, die ihr durch eine Kernverarbeitungseinheit zugewiesen ist (z.B. einer Kernverarbeitungseinheit 201a oder einer anderen Kernverarbeitungseinheit 201b). Beispielsweise kann die Kernverarbeitungseinheit 201a eine Anweisung der Texturverarbeitungseinheit 202a zuweisen, um Block n zu verarbeiten. Die Texturinformation für Block n kann durch die Texturverarbeitungseinheit 202a von der Speicherhierarchie entweder als Antwort auf ihre eigene Anforderung oder einer von einer Kernverarbeitungseinheit durchgeführten Anforderung empfangen werden.
Während der Verarbeitung von Block n bestimmt die Texturverarbeitungseinheit einen Block n+k, aus dem Daten vorabzurufen sind. In einigen Ausführungsformen ist jede Texturverarbeitungseinheit konfiguriert, um Daten aus dem unmittelbar nächsten Block zu dem Block abzurufen, der aktuell auf dieser Texturverarbeitungseinheit verarbeitet wird. In einigen Ausführungsformen kann jedoch ein anderer Block als der unmittelbar nächste Block verwendet werden, aus dem Vorabzurufen ist.
Das Bestimmen der vorabzurufenden Daten gemäß der beispielhaften Ausführungsform kann das Bestimmen eines Versatzes in Byte für die Adresse dieses Blocks erfordern. In beispielhaften Ausführungsformen, bei denen eine Block-lineare Adressen-Mapping-Anordnung benutzt wird, ist der Versatz die Größe des Chunk in Byte. Die Größe eines Chunk ist ein Vielfaches der Größe eines Blocks. Die Block- und Chunk Strukturen in derartigen Ausführungsformen sind eine unmittelbare Konsequenz des Block-linearen Adressen-Mapping, das verwendet wird, um viele der von modernen Spielen verwendeten Texturen zu speichern. In derartigen Ausführungsformen kann die Adresse des nächsten Blocks basierend auf der Adresse des aktuellen Blocks und dem Versatz und auf ähnliche Weise für den nächsten Chunk bestimmt werden.
Die Block- und Chunk-Größen können nicht die gleichen für alle Texturen sein und können eine intrinsische Eigenschaft der Textur sein. Daher kann es notwendig sein, den Versatz auf einer Pro-Texturgrundlage dynamisch zu berechnen. Ferner kann, wenn mehrere Texturen gleichzeitig in Gebrauch sind, ein separater Versatz pro aktiver Textur beibehalten werden.
Jede Textur kann einen Header (einen „Texturheader“) umfassen, der eine bestimmte Art von Information über diese Textur speichert, wie beispielsweise ihre Höhe, Breite, Detaillierungsgrad, Datentyp usw. In einigen beispielhaften Ausführungsformen sind die Texturheader (und/oder Parameterwerte von den Headern) bereits in der Textureinheit für alle Texturen verfügbar, die bei zu einem beliebigen Zeitpunkt in aktivem Gebrauch sind. Mit Zugriff auf Parameter, die eine bestimmte Textur in dem entsprechenden Header beschreiben, berechnen einige beispielhafte Ausführungsformen die Größe des Chunk für eine bestimmte Block-lineare Textur als: $\begin{array}{l} {Größe}_{Chunk} = {Breite}_{Textur} * {Höhe}_{Chunk} * Byte_pro_Texel \\ Versatz - Größe oder Vorabruf - Versatz = Sklierungsfakto * \\ {Größe}_{Chunk} \end{array}$
Somit kann die Versatzgröße zur Laufzeit unter Verwendung von Informationen wirtschaftlich berechnet werden, die in der Texturverarbeitungseinheit und/oder dem Verarbeitungskern verfügbar sind. Beispielsweise kann der Versatz als die Versatzgröße in Byte berechnet werden. Ein Skalierungsfaktor, F, kann verwendet werden, um zu einem feinabgestimmten Wert des Vorabruf-Versatzes durch Multiplizieren desselben mit der Größe des Chunk zu gelangen. Beispielsweise könnte eine kleinere GPU möglicherweise von einem Wert von F profitieren, der kleiner als 1 ist. Ein Standardwert für den Skalierungsfaktor kann 1 sein.
Nachdem der Versatz, basierend auf dem Block, der aktuell in der Texturverarbeitungseinheit verarbeitet wird, und dem berechneten Versatz berechnet ist, wird die Adresse des Blocks oder Teil des Blocks, der vorabzurufen ist, bestimmt. Beispielsweise kann die Adresse des Blocks oder Teil des nächsten Blocks, der vorabzurufen ist, durch Hinzufügen des Versatzes zu der Adresse der Daten des aktuellen Blocks bestimmt werden. Es wurde gezeigt, dass das Vorabrufen der Adressen, die zu dem nächsten Chunk gehören (d.h. Adressen, die zu Blöcken oder Teilen von Blöcken in dem nächsten Chunk gehören), zu dem L2-Cache, wenn die Textureinheiten an dem aktuellen Block arbeiten (der zu dem aktuellen Chunk gehört), die Leistung in vielen Arbeitslasten/Anwendungen, wie beispielsweise Spieleanwendungen, verbessern.
Bei Operation 224 kann optional eine Überprüfung durchgeführt werden, um zu bestimmen, ob die beabsichtigte Vorababrufanforderung ein Duplikat ist. Diese optionale Überprüfung kann mit Informationen wirtschaftlich durchgeführt werden, die in der Texturverarbeitungseinheit verfügbar sind. Beispielsweise kann ein Register, das die Identitäten einer vorbestimmten Anzahl der unmittelbar vorangehenden Vorabrufe weiterverfolgt, die von der Texturverarbeitungseinheit angefordert wurden, gegen die Adresse geprüft werden, die für den nächsten Block oder Teil von Block berechnet wird, der vorabzurufen ist. Wenn bestimmt wird, dass der nächste Block oder Teil von Block mit irgendeinem der zuletzt vorabgerufenen Anforderungen übereinstimmt (z.B. bestimmt wird, dass die beabsichtigte Vorababrufanforderung ein Duplikat ist), dann wird der aktuell bestimmte nächste Block oder Teil von Block zum Vorabrufen fallengelassen 226 und Operation 222 wird wiederholt, um einen anderen Block oder Teil von Block zu bestimmen, der vorabzurufen ist (d.h. eine andere Anforderung bestimmen), der kein Duplikat eines Blocks oder Teil eines Blocks ist, der bereits vorabgerufen wurde.
Wenn bei der optionalen Operation 224 bestimmt wird, dass der bestimmte nächste Block oder Teil von Block zum Vorabrufen kein Duplikat ist, geht der Prozess 220 zu Operation 228 weiter. Wenn die Vorababrufanforderung für alles oder einen Teil von Block n+k beispielsweise bestimmt wird, kein Duplikat zu sein, dann wird bei Operation 228 eine TexturVorababrufanforderung für Daten aus dem Block n+k erzeugt. Die Vorababrufanforderung kann eine Vorabrufangabe umfassen, die sie von einer Texturabrufanforderung unterscheidet. Gemäß einer beispielhaften Ausführungsform umfasst die Vorababrufanforderung, wie beispielsweise die Vorababrufanforderung 212, einen Header mit einem oder mehreren Bits, die sie als eine Vorababrufanforderung kennzeichnen, und die Adresse oder den Versatz des angeforderten Blocks von Texturinformation. In einigen Ausführungsformen kann der Vorababrufanforderung-Header ebenfalls eine eindeutige Kennung oder Adresse (z.B. Adresse des ersten Blocks in der Textur) für die Textur umfassen.
Die erzeugte Vorababrufanforderung wird an die Speicherhierarchie übertragen. Die Übertragung kann auf eine ähnliche Art und Weise durchgeführt werden, wie eine Abrufanforderung von der Textureinheit zu der Speicherhierarchie übertragen wird.
Die Handhabung der erzeugten Vorababrufanforderung für den ganzen oder einen Teil des Blocks n+k in der Speicherhierarchie wird in Relation zu dem nachstehenden Prozess 240 beschrieben.
Nach dem Abschluss der Texturverarbeitung (z.B. Textur-Mapping) unter Verwendung von Block n, geht der Prozess 220 zu Operation 230 weiter. Bei Operation 230 empfängt die Texturverarbeitungseinheit 202a alles oder einen Teil des nächsten Texturblocks aus der Textur A (wie beispielsweise einen weiteren Block aus der Oberflächentextur 156), um verarbeitet zu werden. Dieser nächste Texturblock kann durch einen oder mehrere Speicherzugriffe erhalten werden, die als Antwort auf eine oder mehrere Anweisungen durchgeführt werden, die von einer Kernverarbeitungseinheit empfangen werden. Dieser nächste Block kann nicht der Block sein, der Block n unmittelbar folgt (gemäß dem Speicherzugriffsmuster), dessen Verarbeitung gerade durch die Texturverarbeitungseinheit 202a abgeschlossen wurde, und kann ein beliebiger anderer Block m in der gleichen Textur A sein. Der Block m kann durch die Texturverarbeitungseinheit 202a aus dem L2-Cache 208 erhalten worden sein, wo er gespeichert worden sein kann, nachdem er durch eine andere Texturverarbeitungseinheit vorabgerufen wurde.
In einigen beispielhaften Ausführungsformen wird eine Bestimmung dahingehend, ob das Textur-Mapping Teil eines bestimmten Typs von Rendering ist, vor dem Erzeugen der Vorababrufanforderung bei Operation 222 durchgeführt. In derartigen Ausführungsformen kann das Erzeugen der Vorababrufanforderung als Antwort auf die Bestimmung sein. Wenn beispielsweise die Bestimmung durchgeführt wird, dass das Textur-Mapping Teil einer Vollbildzeichnen-Operation ist, dann wird die Vorababrufanforderung erzeugt und die Vorabrufprozesse 220 und 240 werden abgeschlossen. Wenn die Bestimmung ist, dass das Textur-Mapping nicht Teil eines Vollbildzeichnens ist, dann wird kein Vorabruf durchgeführt. Die Bestimmung kann auf dem Anweisungstyp basieren. Die Bestimmung kann nicht auf die oben beschriebene Bestimmung des Vollbildzeichnens beschränkt sein.
2C zeigt ein Ablaufdiagramm für einen Prozess 240, der von der Speicherhierarchie als Antwort auf das von einem Prozessor eingeleitete Vorabrufen durchgeführt wird, wie in 2B gezeigt, gemäß einigen beispielhaften Ausführungsformen. Der Prozess 240 kann vollständig oder teilweise in den Texturvorabruflogikschaltungen 216 durchgeführt werden, die dem L2-Cache 208 und/oder der Cache-Hierarchie 204 zugeordnet ist.
Der Prozess 240 kann für jede von einer Texturverarbeitungseinheit empfangene Vorababrufanforderung bei Operation 242 beginnen. Die Erzeugung und Übertragung einer Vorababrufanforderung von einer Texturverarbeitungseinheit wurde in Relation zu 2B beschrieben.
Bei Operation 244 wird optional bestimmt, ob die empfangene Vorababrufanforderung ein Duplikat einer bereits empfangenen und/oder bereits bedienten Vorababrufanforderung ist. Um das Senden mehrerer Vorababrufanforderungen in die gleiche Zieladresse zu vermeiden, umfassen einigen Ausführungsformen ein Vorabruf-Entduplikationsschema, wobei eine zweite Vorababrufanforderung nicht für einen Lesevorgang gesendet wird, wenn eine bereits aufgrund eines früheren Lesevorgangs an die gleiche Cache-Zeile gesendet wurde (z.B. für mehrere Leseanforderungen in die gleiche 128B/256B ausgerichtete Adresse, wird lediglich eine Vorababrufanforderung an die Adresse gesendet, die eine Versatzanzahl von Bytes von der 128B/256B ausgerichteten Leseadresse entfernt ist). Diese Entduplikation kann Bandbreite (z.B. Anforderungsbandbreite und/oder Datenbandbreite) einsparen.
Wenn die Vorababrufanforderung als ein Duplikat bestimmt wird, dann wird die empfangene Vorababrufanforderung bei Operation 246 fallengelassen. Wenn bestimmt wird, dass die Anforderung keine Duplikatanforderung ist, dann geht der Prozess 240 zu Operation 248 weiter.
Bei Operationen 248-250 wird optional bestimmt, ob die empfangene Vorababrufanforderung eine Anzahl von anstehenden Vorababrufanforderungen über eine vorbestimmten Schwelle hinaus erhöht. Das heißt, dass bei Empfangen der Vorababrufanforderung und optionalem Bestimmen, dass sie kein Duplikat ist, ein Zähler, der die Anzahl von aktuell anstehenden Vorababrufanforderungen verfolgt, bei Operation 248 inkrementiert wird. Dann wird bei Operation 250 bestimmt, ob der inkrementierte Zählwert von anstehenden Vorababrufanforderungen eine vorbestimmte Schwelle überschreitet. Wenn die anstehenden Anforderungen die Schwelle überschreiten, dann wird die Anforderung bei Operation 246 fallengelassen.
Die Drosseltechnik von Operationen 248-250 sieht Adressierszenarien vor, bei denen das Speichersystem bereits der limitierende Faktor der Leistung aufgrund übermäßiger Abrufanforderungen sein könnte. In derartigen Szenarien ist es am besten, das Speichersystem nicht weiter mit spekulativen Vorababrufanforderungen zu belasten. Demgemäß benutzt das oben beschriebene Drosselschema Information, die hinsichtlich Cache-Sektoren mit anstehenden Füllanforderung verfügbar ist, um Vorababrufanforderungen dynamisch fallen zu lassen, wenn die Anzahl derartiger unerledigter Sektoren oberhalb einer bestimmten Schwelle ist.
Wenn die anstehenden Anforderungen die Schwelle nicht überschreiten, dann geht der Prozess 240 zu Operation 252 weiter.
Bei Operation 252 wird die Vorababrufanforderung an den externen (z.B. off-chip) Speicher übertragen. In einigen Ausführungsformen können die Abrufanforderungen, die von dem L2-Cache an den externen Speicher für Abrufanforderungen und Vorababrufanforderungen übertragen wurden, nicht voneinander unterscheidbar sein. In derartigen Ausführungsformen können die L2-Cache-Schaltungen die angeforderten und empfangenen Texturblöcke verfolgen, so dass die empfangenen Blöcke bei dem L2-Cache abhängig davon entsprechend behandelt werden können, ob jeder für eine Abrufanforderung oder eine Vorababrufanforderung empfangen wird. In einigen anderen Ausführungsformen können die Abrufanforderungen, die von dem L2-Cache für Vorababrufanforderungen übertragen wurden, von jenen unterscheidbar sein, die für Abrufanforderungen übertragen wurden. In einigen Ausführungsformen kann ein Speicherblock, der bei dem L2-Cache von dem externen Speicher empfangen wurde, von Headerinformation begleitet sein, die angibt, ob es eine Vorababrufanforderung betrifft.
Bei Operation 254 werden die von dem Vorabrufblock angeforderten Daten bei dem L2-Cache empfangen. Die L2-Cache-Steuerschaltungen können zwischen Anforderungen an Texturblöcken, die einem Vorabruf zugeordnet sind, und jenen, die Abrufanforderungen zugeordnet sind, in beliebiger Art und Weise unterscheiden. Einige beispielhafte Techniken, durch die eine derartige Unterscheidung durchgeführt werden kann, wurde in Relation zu Operation 252 beschrieben.
Bei Operation 256 wird in Anbetracht des Empfangens der Daten des angeforderten vorabgerufenen Blocks (oder Teilen davon) der Zähler für anstehende Anforderung dekrementiert.
Bei Operation 258 wird der teilweise oder vollständig vorabgerufene Block im L2-Cache gespeichert. Gemäß einigen Ausführungsformen werden im Gegensatz dazu, wie es mit Abrufanforderungen der Fall ist, die vorabgerufenen Blockdaten weder dem L1-Cache noch der anfordernden Texturverarbeitungseinheit bereitgestellt. Die vorabgerufenen Blockdaten werden lediglich in dem L2-Cache gespeichert. Der Prozessor, der die vorabgerufenen Blockdaten anforderte, oder ein anderer Prozessor kann anschließend durch eine Abrufanforderung die vorabgerufenen Blockdaten wiedergewinnen, die in dem L2-Cache gespeichert sind, und sie in dem L1-Cache speichern. Obwohl in einigen Ausführungsformen beim Abschließen des Vorabrufs die vorabgerufenen Daten ebenfalls in dem L1-Cache und/oder der Texturverarbeitungseinheit gespeichert werden können, welche die Vorababrufanforderung zusätzlich zu dem L2-Cache ausgab, können derartige Ausführungsformen weniger effizient als Ausführungsformen sein, welche die vorabgerufenen Daten nicht in dem L1-Cache oder der Texturverarbeitungseinheit speichern.
Nach Operation 258 ist die Vorabrufoperation abgeschlossen.
Eine Parallelverarbeitungsarchitektur zur Rauschreduzierung in Video
Weitere veranschaulichende Informationen werden nun in Hinblick auf verschiedene optionale Architekturen und Merkmale dargelegt, mit denen das vorhergehende Rahmenwerk je nach den Wünschen des Benutzers implementiert werden kann. Es sollte stark beachtet werden, dass die folgenden Informationen für erläuternde Zwecke dargelegt werden und nicht als in irgendeiner Weise beschränkend ausgelegt werden sollten. Jedes der folgenden Merkmale kann optional mit oder ohne den Ausschluss von anderen beschriebenen Merkmalen eingefügt werden.
3 veranschaulicht eine Parallelverarbeitungseinheit (PPU) 300 gemäß einer Ausführungsform. In einer Ausführungsform ist die PPU 300 ein Multi-Threaded-Prozessor bzw. mehrsträngiger Prozessor, der auf einer oder mehreren integrierten Schaltungsvorrichtungen implementiert ist. Die PPU 300 ist eine Latenz-verbergende Architektur, die ausgestaltet ist, um eine große Anzahl von Threads bzw. Strängen parallel zu verarbeiten. Ein Thread bzw. Strang (d.h. ein Ausführungsthread) ist eine Instanziierung eines Satzes von Anweisungen, die konfiguriert sind, um von der PPU 300 ausgeführt zu werden. In einer Ausführungsform ist die PPU 300 eine Graphikverarbeitungseinheit (GPU), die konfiguriert ist, um eine Graphik-Rendering-Pipeline zur Verarbeitung von dreidimensionalen (3D) Graphikdaten zu implementieren, um zweidimensionale (2D) Bilddaten zur Anzeige auf einer Anzeigevorrichtung, wie beispielsweise einer Flüssigkristallanzeige(LCD)-Vorrichtung, zu erzeugen. In anderen Ausführungsformen kann die PPU 300 zum Durchführen von Allzweckberechnungen benutzt werden. Während ein beispielhafter paralleler Prozessor hier für veranschaulichende Zwecke bereitgestellt wird, sei nachdrücklich bemerkt, dass ein derartiger Prozessor lediglich für veranschaulichende Zwecke dargelegt wird und dass ein beliebiger Prozessor benutzt werden kann, um dasselbe zu ergänzen und/oder zu ersetzen.
Eine oder mehrere PPUs 300 können konfiguriert sein, um Tausende von HPC(High Performing Computing)-, Datenzentrum- und Maschinenlern-Anwendungen zu beschleunigen. Die PPU 300 kann konfiguriert sein, um zahlreiche Systeme und Anwendungen für tiefgehendes Lernen zu beschleunigen, die autonome Fahrzeugplattformen, tiefgehendes Lernen, hochgenaue Sprache, Bild- und Texterkennungssysteme, intelligente Videoanalyse, molekulare Simulationen, Wirkstoffentdeckung, Krankheitsdiagnose, Wettervorhersage, Analyse großer Datenmengen, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotertechnik, Fabrikautomation, Sprachübersetzung in Echtzeit, Online-Suchoptimierungen und personalisierte Benutzerempfehlungen und dergleichen umfassen.
Wie in 3 gezeigt, umfasst die PPU 300 eine Eingabe/Ausgabe(E/A)-Einheit 305, eine Frontend-Einheit 315, eine Planer-Einheit 320, eine Arbeitsverteilungs-Einheit 325, einen Hub 330, eine Kreuzschiene (XBar) 370, einen oder mehrere allgemeine Verarbeitungscluster (GPCs) 350 und eine oder mehrere Partitions-Einheiten 380. Die PPU 300 kann mit einem Host-Prozessor oder anderen PPUs 300 über einen Interconnect des Hochgeschwindigkeits-NVLink 310 verbunden sein. Die PPU 300 kann ebenfalls mit einem Host-Prozessor oder anderen peripheren Vorrichtungen über einen Interconnect 302 verbunden sein. In einer Ausführungsform kann der lokale Speicher eine Anzahl von Direktzugriffsspeicher(DRAM)-Vorrichtungen umfassen. Die DRAM-Vorrichtungen können als ein HBM(Speicher mit hoher Bandbreite)-Subsystem konfiguriert sein, wobei mehrere DRAM-Dies innerhalb jeder Vorrichtung gestapelt sind.
Der Interconnect des NVLink 310 ermöglicht Systemen, eine oder mehrere PPUs 300 zu skalieren und zu umfassen, die mit einer oder mehreren CPUs kombiniert sind, unterstützt Cache-Kohärenz zwischen den PPUs 300 und CPUs sowie CPU-Mastering. Daten und/oder Befehle können mittels des NVLink 310 durch den Hub 330 an/von anderen Einheiten der PPU 300, wie beispielsweise eine oder mehrere Kopiermaschinen, einen Videocodierer, einen Videodecodierer, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt) übertragen werden. Das NVLink 310 wird ausführlicher in Verbindung mit 5B beschrieben.
Die E/A-Einheit 305 ist konfiguriert, um Kommunikationen (d.h. Befehle, Daten usw.) von einem Host-Prozessor (nicht gezeigt) über den Interconnect 302 zu übertragen und zu empfangen. Die E/A-Einheit 305 kann mit dem Host-Prozessor direkt über den Interconnect 302 oder durch eine oder mehrere Zwischenvorrichtungen, wie beispielsweise eine Speicherbrücke, kommunizieren. In einer Ausführungsform kann die E/A-Einheit 305 mit einem oder mehreren anderen Prozessoren, wie beispielsweise eine oder mehrere der PPUs, über den Interconnect 302 kommunizieren. In einer Ausführungsformen implementiert die E/A-Einheit 305 eine PCIe(Peripheral Component Interconnect Express)-Schnittstelle für Kommunikationen über einen PCIe-Bus und der Interconnect 302 ist ein PCIe-Bus. In alternativen Ausführungsformen kann die E/A-Einheit 305 andere Typen von wohlbekannten Schnittstellen zum Kommunizieren mit externen Vorrichtungen umfassen.
Die E/A-Einheit 305 decodiert Pakete, die über den Interconnect 302 empfangen wurden. In einer Ausführungsform stellen die Pakete Befehle dar, die konfiguriert sind, um die PPU 300 zu veranlassen, verschiedene Operationen durchzuführen. Die E/A-Einheit 305 überträgt die decodierten Befehle an verschiedene andere Einheiten der PPU 300, wie es die Befehle spezifizieren können. Beispielsweise können einige Befehle an die Frontend-Einheit 315 übertragen werden. Andere Befehle können an den Hub 330 oder andere Einheiten der PPU 300, wie beispielsweise eine oder mehrere Kopiermaschinen, einen Video-Codierer, einen Video-Decodierer, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt) übertragen werden. Mit anderen Worten ist die E/A-Einheit 305 konfiguriert, um Kommunikationen zwischen und unter den verschiedenen logischen Einheiten der PPU 300 weiterzuleiten.
In einer Ausführungsform codiert ein Programm, das von dem Host-Prozessor ausgeführt wird, einen Befehlsstrom in einem Puffer, welcher der PPU 300 Arbeitslasten zur Verarbeitung bereitstellt. Eine Arbeitslast kann mehrere Anweisungen und Daten umfassen, die von diesen Anweisungen zu verarbeiten sind. Der Puffer ist eine Region in einem Speicher, der von sowohl dem Host-Prozessor als auch der PPU 300 zugänglich ist (d.h. Lesen/Schreiben). Beispielsweise kann die Host-Schnittstelleneinheit 305 konfiguriert sein, um auf den Puffer in einem Systemspeicher, der mit dem Interconnect 302 verbunden ist, über Speicheranfragen, die über den Interconnect 302 übertragen werden, zuzugreifen. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und überträgt dann einen Zeiger zu dem Start des Befehlsstroms an die PPU 300. Die Frontend-Einheit 315 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Frontend-Einheit 315 verwaltet den einen oder mehrere Ströme, liest Befehle aus den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 300 weiter.
Die Frontend-Einheit 315 ist mit einer Planer-Einheit 320 gekoppelt, welche die verschiedenen GPCs 350 konfiguriert, um Aufgaben zu verarbeiten, die durch den einen oder mehrere Ströme definiert sind. Die Planer-Einheit 320 ist konfiguriert, um Zustandsinformation zu verfolgen, die verschiedene Aufgaben betrifft, die von der Planer-Einheit 320 verwaltet werden. Der Zustand kann angeben, welchem GPC 350 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, ob ein Prioritätsniveau der Aufgabe zugeordnet ist und so weiter. Die Planer-Einheit 320 verwaltet die Ausführung einer Mehrzahl von Aufgaben auf dem einen oder mehreren GPCs 350.
Die Planer-Einheit 320 ist mit einer Arbeitsverteilungs-Einheit 325 gekoppelt, die konfiguriert ist, um Aufgaben zur Ausführung auf den GPCs 350 zu versenden. Die Arbeitsverteilungs-Einheit 325 kann eine Anzahl von eingeplanten Aufgaben verfolgen, die von der Planer-Einheit 320 empfangen werden. In einer Ausführungsform verwaltet die Arbeitsverteilungs-Einheit 325 einen Pool für anstehende Aufgaben und einen Pool für aktive Aufgaben für jeden der GPCs 350. Der Pool für anstehende Aufgaben kann eine Anzahl von Schlitzen (z.B. 32 Schlitze) umfassen, die Aufgaben enthalten, die zugewiesen sind, um von einem bestimmten GPC 350 verarbeitet zu werden. Der Pool für aktive Aufgaben kann eine Anzahl von Schlitzen (z.B. 4 Schlitze) für Aufgaben umfassen, die von den GPCs 350 aktiv verarbeitet werden. Wenn ein GPC 350 die Ausführung einer Aufgabe abschließt, wird diese Aufgabe aus dem Pool für aktive Aufgaben für den GPC 350 geräumt und eine der anderen Aufgaben wird aus dem Pool für anstehende Aufgaben ausgewählt und zur Ausführung auf dem GPC 350 eingeplant. Wenn eine aktive Aufgabe auf dem GPC 350 inaktiv war, wie beispielsweise während darauf gewartet wird, dass eine Datenabhängigkeit behoben wird, dann kann die aktive Aufgabe aus dem GPC 350 geräumt und zu dem Pool für anstehende Aufgaben zurückgeführt werden, während eine weitere Aufgabe in dem Pool für anstehende Aufgaben ausgewählt und zur Ausführung auf dem GPC 350 eingeplant wird.
Die Arbeitsverteilungs-Einheit 325 kommuniziert mit dem einen oder mehreren GPCs 350 über eine Kreuzschiene bzw. XBar 370. Die XBar 370 ist ein Interconnect-Netzwerk, das viele der Einheiten der PPU 300 mit anderen Einheiten der PPU 300 koppelt. Beispielsweise kann die XBar 370 konfiguriert sein, um die Arbeitsverteilungs-Einheit 325 mit einem bestimmten GPC 350 zu koppeln. Obwohl nicht explizit gezeigt, kann eine oder mehrere andere Einheiten der PPU 300 ebenfalls mit der XBar 370 über den Hub 330 verbunden sein.
Die Aufgaben werden von der Planer-Einheit 320 verwaltet und an einen GPC 350 durch die Arbeitsverteilungs-Einheit 325 versandt. Der GPC 350 ist konfiguriert, um die Aufgabe zu verarbeiten und Ergebnisse zu erzeugen. Die Ergebnisse können von anderen Aufgaben innerhalb des GPC 350 verbraucht werden, an einen unterschiedlichen GPC 350 über die XBar 370 weitergeleitet oder im Speicher 304 gespeichert werden. Die Ergebnisse können in den Speicher 304 über die Partitions-Einheiten 380 geschrieben werden, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/von dem Speicher 304 implementieren. In einer Ausführungsform umfasst die PPU 300 eine Anzahl U von Speicherpartitions-Einheiten 380, die gleich der Anzahl von getrennten und unterschiedlichen Speichervorrichtungen 304 ist, die mit der PPU 300 gekoppelt sind. Eine Speicherpartitions-Einheit 380 wird nachstehend ausführlicher in Verbindung mit 4B beschrieben.
In einer Ausführungsform führt ein Host-Prozessor einen Treiber-Kernel aus, der eine Anwendungsprogrammmier-Schnittstelle (API) implementiert, die einer oder mehreren Anwendungen ermöglicht, die auf dem Host-Prozessor ausgeführt werden, Operationen zur Ausführung auf der PPU 300 einzuplanen. In einer Ausführungsform werden mehrere Rechenanwendungen gleichzeitig von der PPU 300 ausgeführt und die PPU 300 stellt Isolierung, Dienstqualität (QoS) und unabhängige Adressräume für die mehreren Rechenanwendungen bereit. Eine Anwendung kann Anweisungen (d.h. API-Aufrufe) erzeugen, welche den Treiber-Kernel veranlassen, eine oder mehrere Aufgaben zur Ausführung durch die PPU 300 zu erzeugen. Der Treiberkernel gibt Aufgaben an einen oder mehrere Streams aus, die von der PPU 300 verarbeitet werden. Jede Aufgabe kann eine oder mehrere Gruppen von in Beziehung stehender Threads umfassen, die hier als ein Warp bezeichnet werden. In einer Ausführungsform umfasst ein Warp 32 in Beziehung stehende Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Mehrzahl von Threads beziehen, die Anweisungen umfassen, um die Aufgabe durchzuführen, und die Daten durch einen gemeinsam benutzten Speicher austauschen können. Threads und kooperierende Threads werden ausführlicher in Verbindung mit 5A beschrieben.
4A veranschaulicht einen GPC 350 der PPU 300 von 3 gemäß einer Ausführungsform. Wie in 4A gezeigt, umfasst jeder GPC 350 eine Anzahl von Hardwareeinheiten zur Verarbeitung von Aufgaben. In einer Ausführungsform umfasst jeder GPC 350 einen Pipeline-Manager 410, eine Vor-Raster-Operationen-Einheit (PROP) 415, eine Raster-Engine 425, eine Arbeitsverteilungs-Kreuzschiene (WDX) 480, eine Speicherverwaltungseinheit (MMU) 490 und einen oder mehrere Datenverarbeitungscluster (DPCs) 420. Es wird anerkannt, dass der GPC 350 von 4A andere Hardwareeinheiten anstelle von oder zusätzlich zu den in 4A gezeigten Einheiten umfassen kann.
In einer Ausführungsform wird der Betrieb des GPC 350 durch den Pipeline-Manager 410 gesteuert. Der Pipeline-Manager 410 verwaltet die Konfiguration des einen oder mehrerer DPCs 420 zur Verarbeitung von Aufgaben, die dem GPC 350 zugeteilt sind. In einer Ausführungsform kann der Pipeline-Manager 410 mindestens einen des einen oder mehrerer DPCs 420 konfigurieren, um mindestens einen Abschnitt einer Graphik-Rendering-Pipeline zu implementieren. Beispielsweise kann ein DPC 420 konfiguriert sein, um ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 440 auszuführen. Der Pipeline-Manager 410 kann ebenfalls konfiguriert sein, um Pakete, die von der Arbeitsverteilungs-Einheit 325 empfangen werden, an die geeigneten logischen Einheiten innerhalb des GPC 350 weiterzuleiten.
Beispielsweise können einige Pakete an Festfunktions-Hardwareeinheiten in der PROP 415 und/oder der Raster-Engine 425 weitergeleitet werden, während andere Pakete an die DPCs 420 zur Verarbeitung durch die Primitiven-Engine 435 oder den SM 440 weitergeleitet werden können. In einer Ausführungsform kann der Pipeline-Manager 410 mindestens einen oder mehrere DPCs konfigurieren, um ein neuronales Netzwerkmodell und/oder eine Rechen-Pipeline zu implementieren.
Die PROP-Einheit 415 ist konfiguriert, um Daten, die von der Raster-Engine 425 und den DPCs 420 erzeugt werden, an eine Raster-Operationen-Einheit (ROP-Einheit) weiterzuleiten, die nachstehend ausführlicher in Verbindung mit 4B beschrieben wird. Die PROP-Einheit 415 kann ebenfalls konfiguriert sein, um Optimierungen zur Farbenmischung durchzuführen, Pixeldaten zu organisieren, Adressenübersetzungen und dergleichen durchzuführen.
Die Raster-Engine 425 umfasst eine Anzahl von Festfunktions-Hardwareeinheiten, die konfiguriert sind, um verschiedene Raster-Operationen durchzuführen. In einer Ausführungsform umfasst die Raster-Engine 425 eine Setup-Engine, eine Grobraster-Engine, eine Aussonderungs-Engine, eine Abschneide-Engine, eine Feinraster-Engine und eine Kachel-verschmelzende Engine. Die Setup-Engine empfängt transformierte Vertices und erzeugt Ebenengleichungen, die den geometrischen Primitiven zugeordnet sind, die durch die Vertices definiert werden. Die Ebenengleichungen werden an die Grobraster-Engine übertragen, um Abdeckungsinformation (z.B. eine (x,y)-Abdeckungsmaske für eine Kachel) für die Primitive zu erzeugen. Die Ausgabe der Grobraster-Engine wird an die Aussonderungs-Engine übertragen, wo Fragmente, die der Primitiven zugeordnet sind, die einen z-Test nicht bestehen, ausgesondert und an eine Abschneide-Engine übertragen werden, wo Fragmente, die außerhalb eines Betrachtungsstumpfes liegen, abgeschnitten werden. Diejenigen Fragmente, welche die Abschneidung und Aussonderung überleben, können an eine Feinraster-Engine weitergeben werden, um Attribute für die Pixelfragmente basierend auf den Ebenengleichungen zu erzeugen, die durch die Setup-Engine erzeugt werden. Die Ausgabe der Raster-Engine 425 umfasst Fragmente, die beispielsweise von einem Fragment-Shader zu verarbeiten sind, der innerhalb eines DPC 420 implementiert ist.
Jeder DPC 420, der in dem GPC 350 umfasst ist, umfasst einen M-Pipe-Controller (MPC) 430, eine Primitiven-Engine 435 und einen oder mehrere SMs 440. Der MPC 430 steuert den Betrieb des DPC 420, wobei von dem Pipeline-Manager 410 empfangene Pakete an die geeigneten Einheiten im DPC 420 weiterleitet werden. Beispielsweise können einem Vertex zugeordnete Pakete an die Primitiven-Engine 435 weitergeleitet werden, die konfiguriert ist, um der Vertex zugeordnete Vertexattribute von dem Speicher 304 abzurufen. Im Gegensatz dazu können einem Shader-Programm zugeordnete Pakete an den SM 440 übertragen werden.
Der SM 440 umfasst einen programmierbaren Streaming-Prozessor, der konfiguriert ist, um Aufgaben zu verarbeiten, die durch eine Anzahl von Threads dargestellt werden. Jeder SM 440 umfasst mehrere Threads (ist multi-threaded) und ist konfiguriert, um eine Mehrzahl von Threads (z.B. 32 Threads) von einer bestimmten Gruppe von Threads nebenläufig auszuführen. In einer Ausführungsform implementiert der SM 440 eine SIMD(Einzelne-Anweisung, Mehrere-Daten)-Architektur, wobei jeder Thread in einer Gruppe von Threads (d.h. einem Warp) konfiguriert ist, um einen unterschiedlichen Satz von Daten basierend auf dem gleichen Satz von Anweisungen zu verarbeiten. Alle Threads in der Gruppe von Threads führen die gleichen Anweisungen aus. In einer anderen Ausführungsform implementiert der SM 440 eine SIMT(Einzelne Anweisung, Mehrere Threads)-Architektur, wobei jeder Thread in einer Gruppe von Threads konfiguriert ist, um einen unterschiedlichen Satz von Daten basierend auf dem gleichen Satz von Anweisungen zu verarbeiten, wobei jedoch einzelnen Threads in der Gruppe von Threads ermöglicht wird, während der Ausführung zu divergieren. In einer Ausführungsform wird ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand für jeden Warp beibehalten, was eine Nebenläufigkeit zwischen Warps und eine serielle Ausführung innerhalb Warps ermöglicht, wenn Threads innerhalb des Warp divergieren. In einer weiteren Ausführungsform wird ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand für jeden einzelnen Thread beibehalten, was eine gleiche Nebenläufigkeit zwischen allen Threads, innerhalb und zwischen Warps ermöglicht. Wenn der Ausführungszustand für jeden einzelnen Thread beibehalten wird, können Threads, welche die gleichen Anweisungen ausführen, konvergiert und für maximale Effizienz parallel ausgeführt werden. Der SM 440 wird ausführlicher nachstehend in Verbindung mit 5A beschrieben.
Die MMU 490 stellt eine Schnittstelle zwischen dem GPC 350 und der Partitions-Einheit 380 bereit. Die MMU 490 kann eine Übersetzung von virtuellen Adressen in physische Adressen, einen Speicherschutz und eine Arbitrierung von Speicheranfragen bereitstellen. In einer Ausführungsform stellt die MMU 490 einen oder mehrere Adressenübersetzungspuffer (TLBs = translation lookaside buffers) zum Durchführen der Übersetzung von virtuellen Adressen in physische Adressen in dem Speicher 304 bereit.
4B veranschaulicht eine Speicherpartitions-Einheit 380 der PPU 300 von 3 gemäß einer Ausführungsform. Wie in 4B gezeigt, umfasst die Partitions-Einheit 380 eine Raster-Operationen(ROP)-Einheit 450, einen L2-Cache-Speicher 460 und eine Speicherschnittstelle 470. Die Speicherschnittstelle 470 ist mit dem Speicher 304 gekoppelt. Die Speicherschnittstelle 470 kann 32-, 64-, 38-, 1024-Bit-Datenbusse oder dergleichen für Hochgeschwindigkeits-Datentransfer implementieren. In einer Ausführungsform umfasst die PPU 300 U Speicherschnittstellen 470, eine Speicherschnittstelle 470 pro Paar von Speicherpartitions-Einheiten 380, wobei jedes Paar von Speicherpartitions-Einheiten 380 mit einer entsprechenden Speichervorrichtung 304 verbunden ist. Beispielsweise kann die PPU 300 mit bis zu Y Speichervorrichtungen 304, wie beispielsweise Speicherstapel mit hoher Bandbreite oder Graphikdoppeldatenraten, Version 5 SDRAM oder andere Typen von persistenter Speicherung verbunden sein.
In einer Ausführungsform implementiert die Speicherschnittstelle 470 eine HBM2-Speicherschnittstelle und Y ist gleich einem halben U. In einer Ausführungsform sind die HBM2-Speicherstapel auf der gleichen physischen Packung wie die PPU 300 lokalisiert, die wesentliche Leistungs- und Flächeneinsparungen verglichen mit herkömmlichen GDDR5 SDRAM Systemen bereitstellt. In einer Ausführungsform umfasst jeder HBM2-Stapel vier Speicher-Dies und Y ist gleich 4, wobei der HBM2-Stapel zwei 38-Bit Kanäle pro Die für eine Gesamtzahl von 8 Kanälen und eine Datenbusbreite von 1024 Bit umfasst.
In einer Ausführungsform unterstützt der Speicher 304 Fehlerkorrekturcode (ECC) mit Einzelfehlerkorrektur und Doppelfehlerdetektion (SECDED), um Daten zu schützen. Der ECC stellt eine höhere Zuverlässigkeit für Rechenanwendungen bereit, die gegen Datenverfälschung empfindlich sind. Zuverlässigkeit ist besonders wichtig in großen Cluster-Rechenumgebungen, wo PPUs 300 sehr große Datensätze verarbeiten und/oder Anwendungen für längere Zeiträume ausführen.
In einer Ausführungsform implementiert die PPU 300 eine Mehrebenen-Speicherhierarchie. In einer Ausführungsform unterstützt die Speicherpartitions-Einheit 380 einen vereinheitlichten Speicher, um einen einzigen vereinheitlichten virtuellen Adressraum für den Speicher der CPU und den Speicher der PPU 300 bereitzustellen, der Datenteilung zwischen virtuellen Speichersystemen ermöglicht. In einer Ausführungsform wird die Häufigkeit von Zugriffen durch eine PPU 300 auf einen Speicher verfolgt, der auf anderen Prozessoren lokalisiert ist, um sicherzustellen, dass Speicherseiten in den physischen Speicher der PPU 300 bewegt werden, die häufiger auf die Seiten zugreift. In einer Ausführungsform unterstützt das NVLink 310 Adressenübersetzungsdienste, die der PPU 300 erlauben, auf Seitentabellen einer CPU direkt zuzugreifen und einen vollen Zugriff auf den CPU-Speicher durch die PPU 300 bereitstellen.
In einer Ausführungsform transferieren Kopiermaschinen Daten zwischen mehreren PPUs 300 oder zwischen PPUs 300 und CPUs. Die Kopiermaschinen können Seitenfehler für Adressen erzeugen, die nicht in den Seitentabellen abgebildet werden. Die Speicherpartitions-Einheit 380 kann dann die Seitenfehler bedienen, wobei die Adressen in der Seitentabelle abgebildet werden, nachdem die Kopiermaschine den Transfer durchführen kann. In einem herkömmlichen System ist der Speicher für mehrere Kopiermaschinenoperationen zwischen mehreren Prozessoren gesperrt (d.h. nicht auslagerbar), was den verfügbaren Speicher wesentlich verringert. Mit Hardware-Seiten-Faulting können Adressen an die Kopiermaschinen weitergeleitet werden, ohne sich Sorgen zu machen, ob die Speicherseiten resident sind und das Kopierverfahren transparent ist.
Daten von dem Speicher 304 oder einem anderen Systemspeicher können von der Speicherpartitions-Einheit 380 abgerufen und in dem L2-Cache-Speicher 460 gespeichert werden, der Auf-Chip lokalisiert ist und zwischen den verschiedenen GPCs 350 gemeinsam benutzt wird. Wie gezeigt, umfasst jede Speicherpartitions-Einheit 380 einen Bereich des L2-Cache-Speichers 460, der einer entsprechenden Speichervorrichtung 304 zugeordnet ist. Cache-Speicher niedrigerer Ebene können dann in verschiedenen Einheiten innerhalb der GPCs 350 implementiert werden. Beispielsweise kann jeder der SMs 440 einen L1-Cache-Speicher implementieren. Der L1-Cache-Speicher ist ein privater Speicher, der einem bestimmten SM 440 fest zugeordnet ist. Daten von dem L2-Cache-Speicher 460 können abgerufen und in jedem der L1-Cache-Speicher zur Verarbeitung in den Funktionseinheiten der SMs 440 gespeichert werden. Der L2-Cache-Speicher 460 ist mit der Speicherschnittstelle 470 und der XBar 370 gekoppelt.
Die ROP-Einheit 450 führt Graphik-Raster-Operationen durch, welche die Pixelfarbe betreffen, wie beispielsweise Farbenkomprimierung, Pixelmischung und dergleichen. Die ROP-Einheit 450 implementiert ebenfalls Tiefentesten in Verbindung mit der Raster-Engine 425, wobei eine Tiefe für einen Abtastort, der einem Pixelfragment zugeordnet ist, von der Aussonderungs-Engine der Raster-Engine 425 empfangen wird. Die Tiefe wird gegen eine entsprechende Tiefe in einem Tiefenpuffer für einen Abtastort geprüft, der dem Fragment zugeordnet ist. Wenn das Fragment den Tiefentest für den Abtastort besteht, dann aktualisiert die ROP-Einheit 450 den Tiefenpuffer und überträgt ein Ergebnis des Tiefentests an die Raster-Engine 425. Es wird anerkannt, dass sich die Anzahl von Speicherpartitions-Einheiten 380 von der Anzahl von GPCs 350 unterscheiden kann, und daher kann jede ROP-Einheit 450 mit jedem der GPCs 350 gekoppelt werden. Die ROP-Einheit 450 verfolgt Pakete, die von den unterschiedlichen GPCs 350 empfangen werden, und bestimmt, zu welchem GPC 350 ein durch die ROP-Einheit 450 erzeugtes Ergebnis durch die Xbar 470 weitergeleitet wird. Obwohl die ROP-Einheit 450 innerhalb der Speicherpartitions-Einheit 380 in 4B umfasst ist, kann die ROP-Einheit 450 außerhalb der Speicherpartitions-Einheit 380 sein. Beispielsweise kann die ROP-Einheit 450 in dem GPC 350 oder einer anderen Einheit liegen.
5A veranschaulicht den Streaming-Multiprozessor 440 von 4A gemäß einer Ausführungsform. Wie in 5A gezeigt, umfasst der SM 440 einen Anweisungs-Cache-Speicher 505, eine oder mehrere Planer-Einheiten 510, eine Registerdatei 520, einen oder mehrere Verarbeitungskerne 550, eine oder mehrere Spezialfunktionseinheiten (SFUs) 552, eine oder mehrere Lade/Speicher-Einheiten (LSUs) 554, ein Interconnect-Netzwerk 580 und einen gemeinsam benutzten Speicher/L1-Cache-Speicher 570.
Wie oben beschrieben, versendet die Arbeitsverteilungs-Einheit 325 Aufgaben zur Ausführung auf den GPCs 350 der PPU 300. Die Aufgaben werden einem bestimmten DPC 420 innerhalb eines GPC 350 zugeteilt, und wenn die Aufgabe einem Shader-Programm zugeordnet ist, kann die Aufgabe einem SM 440 zugeteilt werden. Die Planer-Einheit 510 empfängt die Aufgaben von der Arbeitsverteilungs-Einheit 325 und verwaltet die Anweisungs-Planung (instruction scheduling) für einen oder mehrere Thread-Blöcke, die dem SM 440 zugewiesen sind. Die Planer-Einheit 510 plant Thread-Blöcke zur Ausführung als Warps von parallelen Threads, wobei jeder Thread-Block mindestens einem Warp zugeordnet ist. In einer Ausführungsform führt jeder Warp 32 Threads aus. Die Planer-Einheit 510 kann eine Mehrzahl von unterschiedlichen Thread-Blöcken verwalten, welche die Warps den unterschiedlichen Thread-Blöcken zuordnet und dann Anweisungen von der Mehrzahl von unterschiedlichen kooperativen Gruppen an die verschiedenen Funktionseinheiten (d.h. Kerne 550, SFUs 552 und LSUs 554) während jedes Taktzyklus versendet.
Cooperative Groups ist ein Programmiermodell zum Organisieren von Gruppen von kommunizierenden Threads, die Entwicklern ermöglicht, die Granularität auszudrücken, bei der Threads kommunizieren, wobei der Ausdruck von reicheren, effizienten Parallelzerlegungen ermöglicht wird. Cooperative-Start-APIs unterstützen die Synchronisierung unter Thread-Blöcken für die Ausführung von parallelen Algorithmen. Herkömmliche Programmiermodelle stellen einen einzigen, einfachen Aufbau zum Synchronisieren von kooperierenden Threads bereit: eine Barriere über alle Threads eines Threadblocks (d.h. die Funktion syncthreads( )). Programmierer würden jedoch häufig gerne Gruppen von Threads bei kleineren als Thread-Block-Granularitäten definieren und innerhalb der definierten Gruppen synchronisieren, um größere Leistung, Gestaltungsflexibilität und Software-Wiederverwendung in der Form von kollektiven gruppenweiten Funktionsschnittstellen zu ermöglichen.
Cooperative Groups ermöglicht Programmierern, Gruppen von Threads explizit bei Sub-Block(d.h. so klein wie ein einziger Thread)- und Mehr-Block-Granularitäten zu definieren und kollektive Operationen, wie beispielsweise Synchronisierung, an den Threads in einer kooperativen Gruppe durchzuführen. Das Programmiermodell unterstützt eine saubere Zusammensetzung über Softwaregrenzen, so dass Bibliotheken und Hilfsfunktionen innerhalb ihres lokalen Kontexts sicher synchronisieren können, ohne Annahmen über Konvergenz machen zu müssen. Cooperative-Groups-Primitive ermöglichen neue Muster von kooperativer Parallelität, die Erzeuger-Verbraucher Parallelität, opportunistische Parallelität und globale Synchronisierung über ein gesamtes Gitter von Threadblöcken umfassen.
Eine Versandeinheit 515 ist konfiguriert, um Anweisungen an eine oder mehrere der Funktionseinheiten zu übertragen. In der Ausführungsform umfasst die Planer-Einheit 510 zwei Versandeinheiten 515, die ermöglichen, dass zwei unterschiedliche Anweisungen von dem gleichen Warp während jedes Taktzyklus versandt werden. In alternativen Ausführungsformen kann jede Planer-Einheit 510 eine einzige Versandeinheit 515 oder zusätzliche Versandeinheiten 515 umfassen.
Jeder SM 440 umfasst eine Registerdatei 520, die einen Satz von Registern für die Funktionseinheiten des SM 440 bereitstellt. In einer Ausführungsform ist die Registerdatei 520 zwischen jeder der Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein zugehöriger Abschnitt der Registerdatei 520 zugeteilt ist. In einer anderen Ausführungsform ist die Registerdatei 520 zwischen den unterschiedlichen Warps aufgeteilt, die von dem SM 440 ausgeführt werden. Die Registerdatei 520 stellt temporäre Speicherung für Operanden bereit, die mit den Datenpfaden der Funktionseinheiten verbunden sind.
Jeder SM 440 umfasst L Verarbeitungskerne 550. In einer Ausführungsform umfasst der SM 440 eine große Anzahl (z.B., 128 usw.) von unterschiedlichen Verarbeitungskernen 550. Jeder Kern 550 kann eine vollständig in einer Pipeline angeordnete (fully-pipelined) Einfach-Präzisions-Verarbeitungseinheit umfassen, die eine Gleitkommaarithmetik-Logikeinheit und eine Ganzzahlarithmetik-Logikeinheit umfasst. In einer Ausführungsform implementieren die Gleitkommaarithmetik-Logikeinheiten den IEEE 754-3008 Standard für Gleitkommaarithmetik. In einer Ausführungsform umfassen die Kerne 550 64 Einfach-Präzisions-(32-Bit)-Gleitkommakerne, 64 Integer-Kerne, 32 Doppel-Präzisions-(64-Bit)-Gleitkommakerne und 8 Tensorkerne.
Tensorkerne sind konfiguriert, um Matrix-Operationen durchzuführen, und in einer Ausführungsform sind ein oder mehrere Tensorkerne in den Kernen 550 enthalten. Insbesondere sind die Tensorkerne konfiguriert, um tiefgehendes Lernen-Matrix-Arithmetik, wie beispielsweise Faltungsoperationen für neuronales Netzwerktraining und Inferenzieren, durchzuführen. In einer Ausführungsform arbeitet jeder Tensorkern an einer 4x4 Matrix und führt eine Matrix-Multiplikations- und Akkumulations-Operation D=A×B+C durch, wobei A, B, C und D 4x4 Matrizen sind.
In einer Ausführungsform sind die Matrix-Multiplikations-Eingaben A und B 16-Bit-Gleitkomma-Matrizen, während die Akkumulationsmatrizen C und D 16-Bit-Gleitkomma- oder 32-Bit-Gleitkomma-Matrizen sein können. Tensorkerne arbeiten an 16-Bit-Gleitkomma-Eingabedaten mit 32-Bit-Gleitkomma-Akkumulation. Die 16-Bit-Gleitkomma-Multiplikation erfordert 64 Operationen und ergibt ein Produkt voller Präzision, das dann unter Verwendung einer 32-Bit-Gleitkomma-Addition mit den anderen Zwischenprodukten für eine 4×4×4-Matrix-Multiplikation akkumuliert wird. In der Praxis werden Tensorkerne verwendet, um viel größere zweidimensionale oder höherdimensionale Matrixoperationen durchzuführen, die von diesen kleineren Elementen aufgebaut werden. Eine API, wie beispielsweise die CUDA 9 C++ API, stellt spezialisierte Matrix-Lade-, Matrix-Multiplikations- und Matrix-Akkumulations- und Matrix-Speicher-Operationen bereit, um Tensorkerne von einem CUDA-C++ Programm effizient zu verwenden. Bei der CUDA-Ebene nimmt das Warp-Schnittstellenniveau 16x16 große Matrizen an, die alle 32 Threads des Warp überspannen.
Jeder SM 440 umfasst ebenfalls M SFUs 552, die Sonderfunktionen durchführen (z.B. Attributauswertung, reziproke Quadratwurzel und dergleichen). In einer Ausführungsform können die SFUs 552 eine Baumtraversierungseinheit umfassen, die konfiguriert ist, um eine hierarchische Baumdatenstruktur zu durchlaufen. In einer Ausführungsform können die SFUs 552 eine Textureinheit umfassen, die konfiguriert ist, um Texturkarten-Filteroperationen durchzuführen. In einer Ausführungsform sind die Textureinheiten konfiguriert, um Texturkarten (z.B. eine 2D-Anordnung von Texeln) von dem Speicher 304 zu laden und die Texturkarten abzutasten, um abgetastete Texturwerte zum Gebrauch in Shader-Programmen zu erzeugen, die durch den SM 440 ausgeführt werden. In einer Ausführungsform werden die Texturkarten in dem gemeinsam benutzten Speicher/L1-Cache-Speicher 470 gespeichert. Die Textureinheiten implementieren Texturoperationen, wie beispielsweise Filteroperationen, unter Verwendung von Mip-Maps (d.h. Texturkarten von veränderlichem Detaillierungsgrad). In einer Ausführungsform umfasst jeder SM 340 zwei Textureinheiten.
Jeder SM 440 umfasst ebenfalls N LSUs 554, die Lade- und Speicheroperationen zwischen dem gemeinsam benutzten Speicher/L1-Cache-Speicher 570 und der Registerdatei 520 implementieren. Jeder SM 440 umfasst ein Interconnect-Netzwerk 580, das jede der Funktionseinheiten mit der Registerdatei 520 und die LSU 554 mit der Registerdatei 520, dem gemeinsam benutzten Speicher/ L1-Cache-Speicher 570 verbindet. In einer Ausführungsform ist das Interconnect-Netzwerk 580 eine Kreuzschiene, die konfiguriert sein kann, um irgendeine der Funktionseinheiten mit irgendeinem der Register in der Registerdatei 520 zu verbinden und die LSUs 554 mit der Registerdatei und Speicherorten im gemeinsam benutzten Speicher/L1-Cache-Speicher 570 zu verbinden.
Der gemeinsam benutzte Speicher/L1-Cache-Speicher 570 ist eine Auf-Chip-Speicheranordnung, die Datenspeicherung und Kommunikation zwischen dem SM 440 und der Primitiven-Engine 435 und zwischen Threads in dem SM 440 ermöglicht. In einer Ausführungsform umfasst der gemeinsam benutzte Speicher/L1-Cache-Speicher 570 38KB von Speicherkapazität und ist in dem Pfad von dem SM 440 zu der Partitions-Einheit 380. Der gemeinsam benutzte Speicher/L1-Cache-Speicher 570 kann verwendet werden, um Lese- und Schreibvorgänge zwischenzuspeichern. Einer oder mehrere des gemeinsam benutzten Speicher/L1-Cache-Speichers 570, L2-Cache-Speichers 460 und des Speichers 304 sind Hintergrundspeicher.
Das Kombinieren von Daten-Cache und gemeinsam benutzter Speicherfunktionalität in einem einzigen Speicherblock stellt die beste Gesamtleistung für beide Arten von Speicherzugriffen bereit. Die Kapazität ist als ein Cache-Speicher von Programmen benutzbar, die den gemeinsam benutzten Speicher nicht verwenden. Wenn der gemeinsam benutzte Speicher beispielsweise konfiguriert ist, um die Hälfte der Kapazität zu verwenden, können Textur- und Lade/Speicher-Operationen die verbleibende Kapazität verwenden. Integration innerhalb des gemeinsam benutzten Speichers/L1-Cache-Speicher 570 ermöglicht dem gemeinsam benutzten Speicher/L1-Cache-Speicher 570 als eine Leitung mit hohem Durchsatz zum Streamen von Daten zu arbeiten, während gleichzeitig eine höhere Bandbreite und ein latenzarmer Zugriff auf häufig wiederverwendete Daten bereitgestellt werden.
Wenn für Allzweck-Parallelberechnung konfiguriert wird, kann im Vergleich mit der Graphikverarbeitung eine einfachere Konfiguration verwendet werden. Im Einzelnen werden die in 3 gezeigten Festfunktions-Graphikverarbeitungseinheiten umgangen, wobei ein viel einfacheres Programmiermodell erzeugt wird. In der Allzweck-Parallelberechnungs-Konfiguration werden Blöcke von Threads von der Arbeitsverteilungs-Einheit 325 direkt den DPCs 420 zugewiesen und verteilt. Die Threads in einem Block führen das gleiche Programm unter Verwendung einer eindeutigen Thread-ID in der Berechnung, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, unter Verwendung des SM 440, um das Programm auszuführen und Berechnungen durchzuführen, eines gemeinsam benutzten Speicher/L1-Cache-Speichers 570, um zwischen Threads zu kommunizieren, und der LSU 554 aus, um globalen Speicher durch den gemeinsam benutzten Speicher/L1-Cache-Speicher 570 und die Speicherpartitions-Einheit 380 zu lesen und zu beschreiben. Wenn für Allzweck-Parallelberechnung konfiguriert, kann der SM 440 ebenfalls Befehle schreiben, welche die Planer-Einheit 320 verwenden kann, um neue Arbeit auf den DPCs 420 zu starten.
Die PPU 300 kann in einem Tischcomputer, einem Laptop-Computer, einem Tablet-Computer, einem Smartphone (z.B. einer drahtlosen handgehaltenen Vorrichtung), einem persönlichen digitalen Assistenten (PDA), einer Digitalkamera, einer handgehaltenen elektronischen Vorrichtung und dergleichen enthalten sein. In einer Ausführungsform ist die PPU 300 auf einem einzelnen Halbleitersubstrat verkörpert. In einer anderen Ausführungsform ist die PPU 300 in einem System-auf-Chip (SoC) zusammen mit einer oder mehreren anderen Vorrichtungen, wie beispielsweise zusätzlichen PPUs 300, dem Speicher 304, einem Rechner-mit-reduziertem-Befehlssatz(RISC)-CPU, einer Speicherverwaltungseinheit (MMU), einem Digital/Analog-Wandler (DAC) und dergleichen enthalten.
In einer Ausführungsform kann die PPU 300 auf einer Graphikkarte enthalten sein, die eine oder mehrere Speichervorrichtungen 304 umfasst. Die Graphikkarte kann konfiguriert sein, um sich mit einem PCIe-Schlitz auf einer Hauptplatine eines Tischcomputers schnittstellenmäßig zu verbinden. In noch einer anderen Ausführungsform kann die PPU 300 eine integrierte Graphikverarbeitungseinheit (iGPU) oder ein Parallelprozessor sein, der in dem Chipsatz der Hauptplatine umfasst ist.
Beispielhaftes Rechensystem
Systeme mit mehrere GPUs und CPUs werden in einer Vielfalt von Industrien verwendet, da Entwickler mehr Parallelität in Anwendungen, wie beispielsweise Rechnen für künstliches Intelligenz, freilegen und wirksam einsetzen. Hochleistungs-GPU-beschleunigte Systeme mit zehn bis vielen Tausenden von Rechenknoten werden in Datenzentren, Forschungsanlagen und Supercomputern eingesetzt, um immer größere Probleme zu lösen.
Da die Anzahl von Verarbeitungsvorrichtungen innerhalb der Hochleistungssysteme zunimmt, müssen die Kommunikations- und Datentransfermechanismen angepasst werden, um die erhöhte Bandbreite zu unterstützen.
5B ist ein Konzeptdiagramm eines Verarbeitungssystems 500, das unter Verwendung der PPU 300 von 3 implementiert wird, gemäß einer Ausführungsform. Das beispielhafte System 500 kann konfiguriert sein, um die in 2B-C gezeigten Verfahren 220 und 240 und/oder die in einer der 1A und 2A gezeigten Systeme zu implementieren. Das Verarbeitungssystem 500 umfasst eine CPU 530, einen Schalter 555 und jeweils mehrere PPUs 300 und jeweilige Speicher 304. Das NVLink 310 stellt Hochgeschwindigkeits-Kommunikationslinks zwischen jeder der PPUs 300 bereit. Obwohl eine bestimmte Anzahl von Verbindungen des NVLink 310 und des Interconnect 302 in 5B veranschaulicht werden, kann die Anzahl von Verbindungen zu jeder PPU und der CPU 530 variieren. Der Schalter 555 verbindet sich schnittstellenmäßig zwischen dem Interconnect 302 und der CPU 530. Die PPUs 300, die Speicher 304 und die NVLinks 310 können auf einer einzigen Halbleiterplattform gelegen sein, um ein Parallelverarbeitungsmodul 525 zu bilden. In einer Ausführungsform unterstützt der Schalter 555 zwei oder mehrere Protokolle, um sich schnittstellenmäßig zwischen verschiedenen unterschiedlichen Verbindungen und/oder Links zu verbinden.
In einer anderen Ausführungsform (nicht gezeigt) stellt das NVLink 310 ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen jeder der PPUs 300 und der CPU 530 bereit und der Schalter 555 ist schnittstellenmäßig zwischen dem Interconnect 302 und jeder der PPUs 300 verbunden. Die PPUs 300, die Speicher 304 und der Interconnect 302 können auf einer einzigen Halbleiterplattform situiert sein, um ein Parallelverarbeitungsmodul 525 zu bilden. In noch einer anderen Ausführungsform (nicht gezeigt) stellt der Interconnect 302 ein oder mehrere Kommunikationslinks zwischen jeder der PPUs 300 und der CPU 530 bereit und der Schalter 555 ist schnittstellenmäßig zwischen jeder der PPUs 300 unter Verwendung des NVLink 310 verbunden, um ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen den PPUs 300 bereitzustellen. In einer anderen Ausführungsform (nicht gezeigt) stellt das NVLink 310 ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen den PPUs 300 und der CPU 530 durch den Schalter 555 bereit. In noch einer anderen Ausführungsform (nicht gezeigt) stellt der Interconnect 302 ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen jeder der PPUs 300 direkt bereit. Ein oder mehrere der NVLink 310 Hochgeschwindigkeits-Kommunikationslinks können als ein physischer NVLink-Interconnect oder entweder als ein Auf-Chip- oder Auf-Die-Interconnect unter Verwendung des gleichen Protokolls wie das NVLink 310 implementiert werden.
Im Kontext der vorliegenden Beschreibung kann sich eine einzige Halbleiterplattform auf eine einzelne unitäre Halbleiterbasierte integrierte Schaltung beziehen, die auf einem Die oder Chip angefertigt ist. Es sei bemerkt, dass sich der Begriff einzige Halbleiterplattform ebenfalls auf Mehr-Chip-Module mit erhöhter Konnektivität beziehen kann, die eine Auf-Chip-Operation simulieren und die wesentlichen Verbesserungen gegenüber der Benutzung einer herkömmlichen Busimplementierung vornehmen. Natürlich können die verschiedenen Schaltungen oder Vorrichtungen ebenfalls getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen gemäß den Wünschen des Benutzers situiert sein. Alternativ kann das Parallelverarbeitungsmodul 525 als ein Leiterplattensubstrat implementiert sein und jede der PPUs 300 und/oder Speicher 304 können verpackte Vorrichtungen sein. In einer Ausführungsform sind die CPU 530, der Schalter 555 und das Parallelverarbeitungsmodul 525 auf einer einzigen Halbleiterplattform situiert.
In einer Ausführungsform ist die Signalrate von jedem NVLink 310 gleich 20 bis 25 Gigabit/s und jede PPU 300 umfasst sechs NVLink 310 Schnittstellen (wie in 5B gezeigt, fünf NVLink 310 Schnittstellen sind für jede PPU 300 umfasst). Jedes NVLink 310 stellt eine Datentransferrate von 25 Gigabyte/s in jeder Richtung bereit, wobei sechs Verknüpfungen 300 Gigabyte/s bereitstellen. Die NVLinks 310 können exklusiv für PPU-zu-PPU Kommunikation, wie in 5B gezeigt, oder einer Kombination von PPU-zu-PPU und PPU-zu-CPU verwendet werden, wenn die CPU 530 ebenfalls eine oder mehrere NVLink 310 Schnittstellen umfasst.
In einer Ausführungsform ermöglicht das NVLink 310 einen direkten Lade/Speicher/atomaren Zugriff von der CPU 530 auf jeden Speicher 304 der PPU 300. In einer Ausführungsform unterstützt das NVLink 310 Kohärenzoperationen, die ermöglichen, das von dem Speicher 304 gelesene Daten in der Cache-Hierarchie der CPU 530 gespeichert werden können, was die Cachezugriffslatenz für die CPU 530 verringert. In einer Ausführungsform umfasst das NVLink 310 Unterstützung für Address Translation Services (ATS), was der PPU 300 ermöglicht, auf Seitentabellen innerhalb der CPU 530 direkt zuzugreifen. Eines oder mehrere der NVLinks 310 können ebenfalls konfiguriert sein, um in einem Niedrigleistungsmodus zu arbeiten.
5C veranschaulicht ein beispielhaftes System 565, bei dem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden kann.
Wie gezeigt, wird ein System 565 bereitgestellt, das mindestens eine zentrale Verarbeitungseinheit 530 umfasst, die mit einem Kommunikationsbus 575 verbunden ist. Der Kommunikationsbus 575 kann unter Verwendung jedes geeigneten Protokolls, wie beispielsweise PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), Hyper-Transport oder irgendeinem anderen Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll(en), implementiert sein. Das System 565 umfasst ebenfalls einen Hauptspeicher 540. Steuerlogik (Software) und Daten werden in dem Hauptspeicher 540 gespeichert, der die Form eines Direktzugriffspeichers (RAM) annehmen kann.
Das System 565 umfasst ebenfalls Eingabevorrichtungen 560, das Parallelverarbeitungssystem 525 und Anzeigevorrichtungen 545, z.B. eine herkömmliche CRT (Kathodenstrahlröhre), eine LCD (Flüssigkristallanzeige), eine LED (lichtemittierende Diode), eine Plasmaanzeige oder dergleichen. Eine Benutzereingabe kann von den Eingabevorrichtungen 560, z.B. Tastatur, Maus, Berührfeld, Mikrophon und dergleichen empfangen werden. Jedes der vorhergehenden Module und/oder Vorrichtungen kann sogar auf einer einzigen Halbleiterplattform situiert sein, um das System 565 zu bilden. Alternativ können die verschiedenen Module auch getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen gemäß den Wünschen des Benutzers situiert sein.
Ferner kann das System 565 mit einem Netzwerk (z.B. einem Telekommunikationsnetzwerk, Lokalbereichsnetzwerk (LAN), drahtlosen Netzwerk, Weitbereichsnetzwerk (WAN), wie beispielsweise dem Internet, Peer-zu-Peer-Netzwerk, Kabelnetzwerk oder dergleichen) durch eine Netzwerkschnittstelle 535 für Kommunikationszwecke gekoppelt sein.
Das System 565 kann ebenfalls einen Sekundärspeicher umfassen (nicht gezeigt). Der Sekundärspeicher umfasst beispielsweise ein Festplattenlaufwerk und/oder ein entfernbares Speicherlaufwerk, das ein Diskettenlaufwerk darstellt, ein Magnetbandlaufwerk, ein Kompaktdisklaufwerk, ein DVD(digitale versatile disk)-Laufwerk, eine Aufzeichnungsvorrichtung und einen Universal-Serial-Bus-(USB)-Flash-Speicher. Das entfernbare Speicherlaufwerk liest von und/oder schreibt auf eine entfernbare Speichereinheit auf eine wohlbekannte Art und Weise.
Computerprogramme oder Computersteuerlogik-Algorithmen können in dem Hauptspeicher 540 und/oder dem Sekundärspeicher gespeichert sein. Derartige Computerprogramme, wenn ausgeführt, ermöglichen dem System 565, verschiedene Funktionen durchzuführen. Der Speicher 540, die Speicherung, und/oder jede andere Speicherung sind mögliche Beispiele von computerlesbaren Medien.
Die Architektur und/oder Funktionalität der verschiedener vorherigen Figuren kann im Kontext eines allgemeinen Computersystems, eines Schaltungsplatinensystems, eines Unterhaltungszwecken fest zugeordneten Spielkonsolensystems, eines anwendungsspezifischen Systems und/oder jedem anderen gewünschten System implementiert sein. Beispielsweise kann das System 565 die Form eines Tischcomputers, eines Laptop-Computers, eines Tablet-Computers, von Servern, von Supercomputern, eines Smartphones (z.B. einer drahtlosen handgehaltenen Vorrichtung), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, einer am Kopf angebrachten Anzeige, einer handgehaltenen elektronischen Vorrichtung, eines mobilen Telefongeräts, eines Fernsehers, einer Arbeitsstation, einer Spielkonsole, eines eingebetteten Systems und/oder von jedem anderen Typ von Logik annehmen.
Während verschiedene Ausführungsformen oben beschrieben wurden, sei zu verstehen, dass sie lediglich beispielhaft und nicht einschränkend präsentiert wurden. Somit sollte die Breite und der Umfang einer bevorzugten Ausführungsform nicht durch irgendeine der oben beschriebenen beispielhaften Ausführungsformen begrenzt werden, sondern sollte nur durch die folgenden Ansprüche und ihrer Äquivalente definiert werden.
Graphikverarbeitungs-Pipeline
In einer Ausführungsform umfasst die PPU 300 eine Graphikverarbeitungseinheit (GPU). Die PPU 300 ist konfiguriert, um Befehle zu empfangen, die Shader-Programme zur Verarbeitung von Graphikdaten spezifizieren. Graphikdaten können als ein Satz von Primitiven, wie beispielsweise Punkte, Linien, Dreiecke, Vierecke, Dreieckstreifen und dergleichen, definiert sein. Typischerweise umfasst eine Primitive Daten, die eine Anzahl von Vertices für die Primitive (z.B., in einem Modellraum-Koordinatensystem) sowie auch Attribute spezifizieren, die jedem Vertex der Primitive zugeordnet sind. Die PPU 300 kann konfiguriert sein, um die Graphikprimitive zu verarbeiten, um ein Frame-Puffer zu erzeugen (d.h. Pixeldaten für jedes der Pixel der Anzeige).
Eine Anwendung schreibt Modelldaten für eine Szene (d.h. eine Sammlung von Vertices und Attributen) in einen Speicher, wie beispielsweise einen Systemspeicher oder Speicher 304. Die Modelldaten definieren jedes der Objekte, die auf einer Anzeige sichtbar sein können. Die Anwendung führt dann einen API-Aufruf an dem Treiber-Kernel aus, der die Modelldaten anfragt, die zu rendern und anzuzeigen sind. Der Treiber-Kernel liest die Modelldaten und schreibt Befehle an den einen oder mehrere Ströme, um Operationen durchzuführen, um die Modelldaten zu verarbeiten. Die Befehle können unterschiedliche Shader-Programme referenzieren, die auf den SMs 440 der PPU 300 zu implementieren sind, die einen oder mehrere eines Vertex-Shader, Hull-Shader, Domain-Shader, Geometrie-Shader und eines Pixel-Shader umfassen können. Beispielsweise können eine oder mehrere der SMs 440 konfiguriert sein, um ein Vertex-Shader-Programm auszuführen, das eine Anzahl von Vertices verarbeitet, die durch die Modelldaten definiert sind. In einer Ausführungsform können die unterschiedlichen SMs 440 konfiguriert sein, um unterschiedliche Shader-Programme nebenläufig auszuführen. Beispielsweise kann eine erste Untermenge von SMs 440 konfiguriert sein, um ein Vertex-Shader-Programm auszuführen, während eine zweite Untermenge von SMs 440 konfiguriert sein kann, um ein Pixel-Shader-Programm auszuführen. Die erste Untermenge von SMs 440 verarbeitet Vertexdaten, um verarbeitete Vertexdaten zu erzeugen, und schreibt die verarbeiteten Vertexdaten in den L2-Cache-Speicher 460 und/oder den Speicher 304. Nachdem die verarbeiteten Vertexdaten gerastert sind (d.h. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum transformiert sind), um Fragmentdaten zu erzeugen, führt die zweite Untermenge von SMs 440 einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, die dann mit anderen verarbeiteten Fragmentdaten gemischt werden und in den Frame-Puffer im Speicher 304 geschrieben werden. Das Vertex-Shader-Programm und das Pixel-Shader-Programm können nebenläufig ausgeführt werden, wobei unterschiedliche Daten von der gleichen Szene in einem Pipeline-Verfahren verarbeitet werden, bis alle der Modelldaten für die Szene gerenderten zu dem Frame-Puffer gerendert wurden. Dann wird der Inhalt des Frame-Puffers an einen Anzeigencontroller zur Anzeige auf einer Anzeigevorrichtung übertragen.
6 ist ein Konzeptdiagramm einer von der PPU 300 von 3 implementierten Graphikverarbeitungs-Pipeline 600 gemäß einer Ausführungsform. Die Graphikverarbeitungs-Pipeline 600 ist ein abstraktes Ablaufdiagramm der Verarbeitungsschritte, die implementiert werden, um 2D-Computer-erzeugte Bilder aus 3D-Geometriedaten zu erzeugen. Wie bekannt ist, können Pipeline-Architekturen Operationen mit langer Latenzzeit effizienter durch Aufteilen der Operation in eine Mehrzahl von Stufen durchführen, wobei die Ausgabe jeder Stufe mit dem Eingang der nächsten aufeinanderfolgenden Stufe gekoppelt ist. Somit empfängt die Graphikverarbeitungs-Pipeline 600 Eingabedaten 601, die von einer Stufe an die nächste Stufe der Graphikverarbeitungs-Pipeline 600 übertragen werden, um Ausgabedaten 602 zu erzeugen. In einer Ausführungsform kann die Graphikverarbeitungs-Pipeline 600 eine Graphikverarbeitungs-Pipeline darstellen, die durch die OpenGL^® API definiert ist. Als eine Option kann die Graphikverarbeitungs-Pipeline 600 im Kontext der Funktionalität und Architektur der vorherigen Figuren und/oder etwaiger nachfolgenden Figur(en) implementiert werden.
Wie in 6 gezeigt, umfasst die Graphikverarbeitungs-Pipeline 600 eine Pipeline-Architektur, die eine Anzahl von Stufen umfasst. Die Stufen umfassen, sind jedoch nicht beschränkt auf, eine Datenanordnungs-Stufe 610, eine Vertex-Shading-Stufe 620, eine Primitivenanordnungs-Stufe 630, eine Geometrie-Shading-Stufe 640, eine Darstellungsfeld-Skalierungs-, Aussonderungs- und Abschneide-(VSCC)-Stufe 650, eine Rasterungs-Stufe 660, eine Fragment-Shading-Stufe 670 und eine Raster-Operationen-Stufe 680. In einer Ausführungsform umfassen die Eingabedaten 601 Befehle, welche die Verarbeitungseinheiten konfigurieren, um die Stufen der Graphikverarbeitungs-Pipeline 600 zu implementieren, und geometrische Primitive (z.B., Punkte, Linien, Dreiecke, Vierecke, Dreieckstreifen oder Fächer, usw.), die mittels der Stufen zu verarbeiten sind. Die Ausgabedaten 602 können Pixeldaten (d.h. Farbdaten) umfassen, die in einen Frame-Puffer oder einen anderen Typ von Oberflächen-Datenstruktur in einem Speicher kopiert werden.
Die Datenanordnungs-Stufe 610 empfängt die Eingabedaten 601, die Vertexdaten für Oberflächen höherer Ordnung, Primitive oder dergleichen spezifizieren. Die Datenanordnungs-Stufe 610 sammelt die Vertexdaten in einem temporären Speicher oder Warteschlange, wie beispielsweise durch Empfangen eines Befehls von dem Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher umfasst und die Vertexdaten aus dem Puffer liest. Die Vertexdaten werden dann an die Vertex-Shading-Stufe 620 zur Verarbeitung übertragen.
Die Vertex-Shading-Stufe 620 verarbeitet Vertexdaten durch Durchführen eines Satzes von Operationen (d.h. eines Vertex-Shader oder eines Programms) einmal für jede der Vertices. Vertices können beispielsweise als ein 4-Koordinaten-Vektor (d.h. <x, y, z, w>) spezifiziert sein, der einem oder mehreren Vertexattributen (z.B., Farbe, Texturkoordinaten, Oberflächennormalen, usw.) zugeordnet ist. Die Vertex-Shading-Stufe 620 kann einzelne Vertexattribute, wie beispielsweise Position, Farbe, Texturkoordinaten und dergleichen, manipulieren. Mit anderen Worten führt die Vertex-Shading-Stufe 620 Operationen an den Vertex-Koordinaten oder anderen Vertexattributen durch, welche einem Vertex zugeordnet sind. Derartige Operationen umfassen gewöhnlicherweise Beleuchtungs-Operationen (d.h. Modifizieren von Farbattributen für einen Vertex) und Transformations-Operationen (d.h. Modifizieren des Koordinatenraums für einen Vertex). Beispielsweise können Vertices unter Verwendung von Koordinaten in einem Objekt-Koordinatenraum spezifiziert sein, die durch Multiplizieren der Koordinaten mittels einer Matrix transformiert werden, welche die Koordinaten aus dem Objekt-Koordinatenraum in einen Welt-Raum oder einen normierten Vorrichtungskoordinaten(NCD = Normalized Device Coordinates)-Raum übersetzt. Die Vertex-Shading-Stufe 620 erzeugt transformierte Vertexdaten, die an die Primitivenanordnungs-Stufe 630 übertragen werden.
Die Primitivenanordnungs-Stufe 630 sammelt Vertices, die mittels der Vertex-Shading-Stufe 620 ausgegeben werden, und gruppiert die Vertices in geometrische Primitive zur Verarbeitung durch die Geometrie-Shading-Stufe 640. Beispielsweise kann die Primitivenanordnungs-Stufe 630 konfiguriert sein, um alle drei aufeinanderfolgenden Vertices als eine geometrische Primitive (d.h. ein Dreieck) zur Übertragung an die Geometrie-Shading-Stufe 640 zu gruppieren. In einigen Ausführungsformen können spezifische Vertices für aufeinanderfolgende geometrische Primitive erneut verwendet werden (z.B. können zwei aufeinanderfolgende Dreiecke in einem Dreieckstreifen zwei Vertices gemeinsam benutzen). Die Primitivenanordnungs-Stufe 630 überträgt geometrische Primitive (d.h. eine Sammlung von zugeordneten Vertices) an die Geometrie-Shading-Stufe 640.
Die Geometrie-Shading-Stufe 640 verarbeitet geometrische Primitive durch Durchführen eines Satzes von Operationen (d.h. eines Geometrie-Shader oder Programms) an den geometrischen Primitiven. Tessellations-Operationen können eine oder mehrere geometrische Primitive aus jeder geometrischen Primitive erzeugen. Mit anderen Worten kann die Geometrie-Shading-Stufe 640 jede geometrische Primitive in ein feineres Netz von zwei oder mehreren geometrischen Primitiven zur Verarbeitung durch den Rest der Graphikverarbeitungs-Pipeline 600 unterteilen. Die Geometrie-Shading-Stufe 640 überträgt geometrische Primitive an die Darstellungsfeld-SCC-Stufe 650.
In einer Ausführungsform kann die Graphikverarbeitungs-Pipeline 600 innerhalb eines Streaming-Multiprozessors arbeiten und die Vertex-Shading-Stufe 620, die Primitivenanordnungs-Stufe 630, die Geometrie-Shading-Stufe 640, die Fragment-Shading-Stufe 670 und/oder die damit zugeordnete Hardware/Software kann sequenziell Verarbeitungsoperationen durchführen. Sobald die sequenziellen Verarbeitungsoperationen in einer Ausführungsform abgeschlossen sind, kann die Darstellungsfeld-SCC-Stufe 650 die Daten benutzen. In einer Ausführungsform können Primitivendaten, die durch eine oder mehrere der Stufen in der Graphikverarbeitungs-Pipeline 600 verarbeitet wurden, in einen Cache-Speicher (z.B. einen L1-Cache-Speicher, einen Vertex-Cache-Speicher usw.) geschrieben werden. In diesem Fall kann in einer Ausführungsform die Darstellungsfeld-SCC-Stufe 650 auf die Daten in dem Cache-Speicher zugreifen. In einer Ausführungsform sind die Darstellungsfeld-SCC-Stufe 650 und die Rasterungs-Stufe 660 als Festfunktionsschaltungen implementiert.
Die Darstellungsfeld-SCC-Stufe 650 führt Darstellungsfeld-Skalierung, Aussonderung und Abschneidung der geometrischen Primitive durch. Jede Oberfläche, die gerendert wird, wird einer abstrakten Kameraposition zugeordnet. Die Kameraposition stellt einen Ort eines Betrachters dar, der die Szene betrachtet, und definiert einen Betrachtungsstumpf, der die Objekte der Szene einschließt. Der Betrachtungsstumpf kann eine Betrachtungsebene, eine hintere Ebene und vier Abschneideebenen umfassen. Jede geometrische Primitive, die vollständig außerhalb des Betrachtungsstumpfes ist, kann ausgesondert (d.h. verworfen) werden, weil die geometrische Primitive nicht zu der endgültigen gerenderten Szene beitragen wird. Jede geometrische Primitive, die innerhalb des Betrachtungsstumpfs und teilweise außerhalb des Betrachtungsstumpf ist, kann abgeschnitten werden (d.h. in eine neue geometrische Primitive transformiert werden, die innerhalb des Betrachtungsstumpf eingeschlossen ist). Des Weiteren können geometrische Primitive jeweils basierend auf einer Tiefe des Betrachtungsstumpfes skaliert werden. Alle potenziell sichtbaren geometrischen Primitive werden dann an die Rasterungs-Stufe 660 übertragen.
Die Rasterungs-Stufe 660 wandelt die 3D-geometrischen Primitive in 2D-Fragmente um (die z.B. in der Lage sind, zur Anzeige benutzt zu werden, usw.). Die Rasterungs-Stufe 660 kann konfiguriert sein, um die Vertices der geometrischen Primitive zu benutzen, um einen Satz von Ebenengleichungen aufzustellen, von denen verschiedene Attribute interpoliert werden können. Die Rasterungs-Stufe 660 kann ebenfalls eine Abdeckungsmaske für eine Mehrzahl von Pixeln berechnen, die angibt, ob eine oder mehrere Abtastorte für das Pixel die geometrische Primitive schneiden. In einer Ausführungsform kann auch z-Testen durchgeführt werden, um zu bestimmen, ob die geometrische Primitive von anderen geometrischen Primitiven verdeckt wird, die bereits gerastert wurden. Die Rasterungs-Stufe 660 erzeugt Fragmentdaten (d.h. interpolierte Vertexattribute, die einem bestimmten Abtastort für jedes abgedeckte Pixel zugeordnet sind), die an die Fragment-Shading-Stufe 670 übertragen werden.
Die Fragment-Shading-Stufe 670 verarbeitet Fragmentdaten durch Durchführen eines Satzes von Operationen (d.h. eines Fragment-Shader oder eines Programms) an jedem der Fragmente. Die Fragment-Shading-Stufe 670 kann Pixeldaten (d.h. Farbenwerte) für das Fragment erzeugen, wie beispielsweise durch Durchführen von Beleuchtungs-Operationen oder Abtasten von Texturabbildungen unter Verwendung von interpolierten Texturkoordinaten für das Fragment. Die Fragment-Shading-Stufe 670 erzeugt Pixeldaten, die an die Rasteroperationen-Stufe 680 übertragen werden.
Die Rasteroperationen-Stufe 680 kann verschiedene Operationen an den Pixeldaten durchführen, wie beispielsweise Alpha-Tests, Stencil-Tests und Mischung der Pixeldaten mit anderen Pixeldaten, die anderen Fragmente entsprechen, die dem Pixel zugeordnet sind. Wenn die Raster-Operationen-Stufe 680 die Verarbeitung der Pixeldaten (d.h. der Ausgabedaten 602) beendet hat, können die Pixeldaten in ein Render-Ziel, wie beispielsweise einen Frame-Puffer, einen Farbenpuffer oder dergleichen, geschrieben werden.
Es wird anerkannt, dass eine oder mehrere zusätzliche Stufen in der Graphikverarbeitungs-Pipeline 600 zusätzlich zu oder anstatt einer oder mehrerer der oben beschriebenen Stufen enthalten sein können. Verschiedene Implementierungen der abstrakten Graphikverarbeitungs-Pipeline können unterschiedliche Stufen implementieren. Des Weiteren können eine oder mehrere der oben beschriebenen Stufen der Graphikverarbeitungs-Pipeline in einigen Ausführungsformen (wie beispielsweise der Geometrie-Shading-Stufe 640) ausgeschlossen sein. Andere Arten von Graphikverarbeitungs-Pipelines werden betrachtet, als innerhalb des Schutzumfangs der vorliegenden Offenbarung zu liegen. Des Weiteren können beliebige der Stufen der Graphikverarbeitungs-Pipeline 600 von einer oder mehreren dedizierten Hardwareeinheiten innerhalb eines Graphikprozessors, wie beispielsweise der PPU 300, implementiert werden. Andere Stufen der Graphikverarbeitungs-Pipeline 600 können durch programmierbare Hardwareeinheiten, wie beispielsweise dem SM 440 der PPU 300, implementiert werden.
Die Graphikverarbeitungs-Pipeline 600 kann über eine Anwendung implementiert werden, die von einem Host-Prozessor, wie beispielsweise einer CPU, ausgeführt wird. In einer Ausführungsform kann ein Vorrichtungstreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, die verschiedene Funktionen definiert, die von einer Anwendung benutzt werden können, um graphische Daten zur Anzeige zu erzeugen. Der Vorrichtungstreiber ist ein Softwareprogramm, das eine Mehrzahl von Befehlen umfasst, die den Betrieb der PPU 300 steuern. Die API stellt eine Abstraktion für einen Programmierer bereit, die einem Programmierer erlaubt, spezialisierte Graphikhardware zu benutzen, wie beispielsweise die PPU 300, um die graphischen Daten zu erzeugen, ohne zu verlangen, dass der Programmierer den spezifischen Befehlssatz für die PPU 300 benutzen muss. Die Anwendung kann einen API-Aufruf umfassen, der an den Vorrichtungstreiber für die PPU 300 weitergeleitet wird. Der Vorrichtungstreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu antworten. In einigen Fällen kann der Vorrichtungstreiber Operationen durch Ausführen von Befehlen auf der CPU 550 durchführen. In anderen Fällen kann der Vorrichtungstreiber Operationen, zumindest teilweise, durch Starten von Operationen auf der PPU 300 durchführen, wobei eine Eingabe/Ausgabe-Schnittstelle zwischen der CPU und der PPU 300 benutzt wird. In einer Ausführungsform ist der Vorrichtungstreiber konfiguriert, um die Graphikverarbeitungs-Pipeline 600 unter Benutzung der Hardware der PPU 300 zu implementieren.
Verschiedene Programme können innerhalb der PPU 300 ausgeführt werden, um die verschiedenen Stufen der Graphikverarbeitungs-Pipeline 600 zu implementieren. Beispielsweise kann der Vorrichtungstreiber ein Kernel auf der PPU 300 starten, um die Vertex-Shading-Stufe 620 auf einem SM 440 (oder mehreren SMs 440) durchzuführen. Der Vorrichtungstreiber (oder den von der PPU 300 ausgeführten Anfangskernel) kann ebenfalls andere Kernels auf der PPU 300 starten, um andere Stufen der Graphikverarbeitungs-Pipeline 600 durchzuführen, wie beispielsweise die Geometrie-Shading-Stufe 640 und die Fragment-Shading-Stufe 670. Außerdem können einige der Stufen der Graphikverarbeitungs-Pipeline 600 auf einer festen Hardwareeinheit implementiert werden, wie beispielsweise einem Rasterer oder einem Daten-Assembler, der innerhalb der PPU 300 implementiert ist. Es wird anerkannt, dass Ergebnisse von einem Kernel durch eine oder mehrere intervenierende Festfunktions-Hardwareeinheiten verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einem SM 440 verarbeitet werden.
Maschinenlernen
Tiefe neuronale Netzwerke (DNNs), die auf Prozessoren entwickelt wurden, wie beispielsweise der PPU 300, wurden für diverse Verwendungsfälle, von selbstfahrenden Wagen bis schnellerer Wirkstoffentwicklung, von automatischer Bildbeschriftung in Online-Bilddatenbanken bis smarter Echtzeit-Sprachenübersetzung in Video-Chat-Anwendungen verwendet. Tiefgehendes Lernen ist eine Technik, welche das neuronale Lernverfahren des menschlichen Gehirns modelliert, kontinuierlich lernt, kontinuierlich immer smarter wird und genauere Ergebnisse im Laufe der Zeit schneller liefert. Ein Kind wird anfangs von einem Erwachsenen unterrichtet, verschiedene Formen korrekt zu identifizieren und zu klassifizieren, um schließlich imstande zu sein, Formen ohne irgendeine Nachhilfe zu identifizieren. Auf ähnliche Weise muss ein System für tiefgehendes Lernen oder ein System für neuronales Lernen in Objekterkennung und Klassifizierung trainiert werden, damit es smarter und effizienter beim Identifizieren von Grundobjekten, verdeckten Objekte usw. wird, während ebenfalls Objekten Kontext zugewiesen wird.
Auf der einfachsten Ebene schauen Neuronen im menschlichen Gehirn auf verschiedene Eingaben, die empfangen werden, wobei Wichtigkeitsgrade jeder dieser Eingaben zugewiesen werden und eine Ausgabe an andere Neuronen weitergeleitet wird, um auf diese zu wirken. Ein künstliches Neuron oder ein Perzeptron ist das grundlegendste Modell eines neuronalen Netzwerks. In einem Beispiel kann ein Perzeptron eine oder mehrere Eingaben empfangen, die verschiedene Merkmale eines Objekts darstellen, die das Perzeptron trainiert wird, zu erkennen und zu klassifizieren, und jedem dieser Merkmale wird ein bestimmtes Gewicht basierend auf der Wichtigkeit des Merkmals beim Definieren der Gestalt eines Objekts zugewiesen.
Ein Modell eines tiefen neuronalen Netzwerks (DNN) umfasst mehrere Schichten von vielen verbundenen Perzeptronen (z.B. Knoten), die mit enormen Mengen an Eingabedaten trainiert werden können, um komplexe Probleme mit hoher Genauigkeit schnell zu lösen. In einem Beispiel gliedert eine erste Schicht des DNN-Modells ein Eingabebild eines Automobils in verschiedene Abschnitte auf und sucht nach Grundmustern, wie beispielsweise Linien und Winkel. Die zweite Schicht setzt die Linien zusammen, um nach Mustern höherer Ebene, wie beispielsweise Rädern, Windschutzscheiben und Spiegeln, zu suchen. Die nächste Schicht kennzeichnet den Typ des Fahrzeugs und die letzten paar Schichten erzeugen ein Etikett für das Eingabebild, welches das Modell einer speziellen Automobilmarke kennzeichnet.
Sobald das DNN trainiert ist, kann das DNN eingesetzt und verwendet werden, um Objekte oder Muster in einem als Inferenz bekannten Verfahren zu identifizieren und zu klassifizieren. Beispiele von Inferenz (der Prozess, durch den ein DNN nützliche Information von einer gegebenen Eingabe extrahiert) umfassen ein Identifizieren handgeschriebener Zahlen auf Schecks, die in Geldausgabe-Maschinen eingezahlt werden, ein Identifizieren von Bildern von Freunden in Photos, Liefern von Filmempfehlungen an über fünfzig Millionen Nutzern, Identifizieren und Klassifizieren unterschiedlicher Typen von Automobilen, Fußgängern und Straßengefahren in fahrerlosen Wagen oder Übersetzen von menschlicher Sprache in Echtzeit.
Während des Trainings strömen Daten durch das DNN in einer Vorwärtspropagierungsphase, bis eine Vorhersage erzeugt wird, die ein Etikett angibt, das der Eingabe entspricht. Wenn das neuronale Netzwerk die Eingabe nicht korrekt kennzeichnet, dann werden Fehler zwischen dem korrekten Etikett und dem vorhergesagten Etikett analysiert und die Gewichte werden für jedes Merkmal während einer Rückwärtspropagierungsphase eingestellt, bis das DNN die Eingabe und andere Eingaben in einem Trainingsdatensatz korrekt kennzeichnet. Das Training komplexer neuronaler Netzwerke erfordert enorme Mengen an paralleler Rechenleistung, die Gleitkomma-Multiplikationen und Gleitkomma-Additionen umfassen, die von der PPU 300 unterstützt werden. Inferenzieren ist weniger rechenintensiv als Training, das ein Latenz-empfindliches Verfahren ist, wobei ein trainiertes neuronales Netzwerk auf neue Eingaben angewandt wird, die es zuvor nicht gesehen hat, um Bilder zu klassifizieren, Sprache zu übersetzen und im Allgemeinen neue Informationen abzuleiten.
Neuronale Netzwerke stützen sich sehr auf Matrixrechenoperationen und komplexe mehrschichtige Netzwerke erfordern enorme Mengen an Gleitkomma-Leistung und Bandbreite für sowohl Effizienz als auch Geschwindigkeit. Mit Tausenden von Verarbeitungskernen, die für Matrixrechenoperationen optimiert sind und von zehn bis hunderten von TFLOPS von Leistung liefern, ist die PPU 300 eine Rechenplattform, die imstande ist, Leistung zu liefern, die für tiefe neuronale Netzwerk-basierte künstliche Intelligenz und Maschinenlernanwendungen erforderlich ist.
Beispielhafte Technische Vorteile einiger Ausführungsformen
Bestimmte beispielhafte Ausführungsformen sehen eine verbesserte Systemleistung durch Verringern von Speicherzugriffslatenzen für Texturinformationszugriff während Graphikverarbeitung vor.
Wie obenstehend bemerkt, können herkömmliche Latenzverbergende Techniken, wie beispielsweise Pipeline-Bildung, nicht ausreichend sein, um die Leistungsverschlechterungen zu mildern, die durch relativ lange Latenzzeiten verursacht werden, die durch Zugreifen auf Textur-Maps und dergleichen während einer Graphikverarbeitung erlitten wurden. Die herkömmlichen Vorabruftechniken, die meistens in Relation zu der CPU angewendet wurden, können ebenfalls für die hochparallelen GPUs und für Texturinformation nicht angemessen sein, die unterschiedlichen Speicherungs- und Zugriffcharakteristiken aufweisen als die typischen CPU-Arbeitslasten. Somit ermöglichen durch das Bereitstellen von verbesserter Systemleistung durch Verringern von Speicherzugriffslatenzzeiten für Texturinformation bestimmte Ausführungsformen der vorliegenden Erfindung, dass die durch schnellere Prozessoren bereitgestellten Verbesserungen der Verarbeitungsgeschwindigkeit beibehalten werden und nicht aufgrund von langen Speicherzugriffslatenzzeiten Verschlechterungen unterworfen werden.
In bestimmten beispielhaften Ausführungsformen sind die zusätzlichen Schaltungen, die bei den Textureinheiten und dem L2-Cache-Speicher in bestimmten beispielhaften Ausführungsformen erforderlich sind, wirtschaftlich und effizient in die Schaltungen von Texturverarbeitungseinheiten und den L2-Cache-Steuerschaltungen aufgenommen, um dadurch eine effiziente Technik bereitzustellen, um durch dieselben den Texturzugriffen zugeordnete Geschwindigkeiten zu verbessern. Durch Optimieren für bestimmte häufige Speicherzugriffsmuster beschleunigen beispielhafte Ausführungsformen außerdem mindestens einige der Speicherzugriffe.
Während die Beschleunigung in beispielhaften Ausführungsformen, die durch effizienteren Speicherzugriff von Textur-Maps erreicht wurde, in vielen Arten von Anwendungen hilfreich ist, kann die Beschleunigung besonders hilfreich in Spielen mit sehr schnellen Bildschirmänderungen und/oder Aktionen und in höchstem Maße zeitkritische Anwendungen sein, wie beispielsweise, jedoch nicht beschränkt auf, Automobilanzeigen (z.B. autonome Fahrzeuganzeigen usw.) und dergleichen.
Angesichts der obigen Lehren sind zahlreiche Modifikationen und Variationen der vorliegenden Offenbarung möglich. Es versteht sich daher, dass die Erfindung innerhalb des Umfangs der beigefügten Ansprüche anders als hier speziell beschrieben praktiziert werden kann.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 7916149 [0004]

Claims

Verfahren zum Anzeigen einer Szene, umfassend: während des Durchführens eines Textur-Mapping der Szene unter Verwendung eines ersten Blocks einer gespeicherten Textur, Erzeugen einer Vorababrufanforderung durch einen Prozessor, um alles oder Teil eines zweiten Blocks der gespeicherten Textur aus einem Speicher erster Ebene einer Speicherhierarchie abzurufen; Abrufen alles oder eines Teils des zweiten Blocks aus dem Speicher erster Ebene als Antwort auf die Vorababrufanforderung; Speichern des abgerufenen ganzen oder Teils des zweiten Blocks in einem Bereich eines Speichers der zweiten Ebene der Speicherhierarchie, wobei der Bereich des Speichers der zweiten Ebene durch den Prozessor und einen anderen Prozessor zugänglich ist, und wobei die zweite Ebene des Speichers eine Zwischenebene des Speichers zwischen der ersten Ebene des Speichers und einer dritten Ebene des Speichers in der Speicherhierarchie ist; Durchführen eines Textur-Mapping der Szene unter Verwendung des abgerufenen ganzen oder Teils des zweiten Blocks; und Rendering der Szene auf eine Anzeigevorrichtung.
Verfahren gemäß Anspruch 1, wobei das Textur-Mapping der Szene unter Verwendung des ersten Blocks von dem Prozessor durchgeführt wird und das Textur-Mapping der Szene unter Verwendung des zweiten Blocks von dem anderen Prozessor durchgeführt wird.
Verfahren gemäß Anspruch 1 oder 2, wobei eine Adresse für den ganzen oder Teil des zweiten Blocks durch den Prozessor basierend auf einem Blockgrößenwert dynamisch berechnet wird, der von der Headerinformation der Textur bestimmt wird, und wobei der Blockgrößenwert von einem anderen Blockgrößenwert unterschiedlich ist, der für eine andere Textur angegeben wird.
Verfahren gemäß Anspruch 3, wobei die Adresse für den ganzen oder Teil des zweiten Blocks basierend ferner auf einer Adresse des ersten Blocks bestimmt wird und wobei die Vorababrufanforderung die bestimmte Adresse des ganzen oder Teils des zweiten Blocks und/oder den Blockgrößenwert umfasst, der von der Headerinformation der Textur bestimmt wird.
Verfahren gemäß Anspruch 4, wobei der erste Block und der zweite Block jeweils eine ganzzahlige Anzahl von Texeln umfasst, die in der ersten Ebene des Speichers in einer Blocklinearen Anordnung in einer gleichen Textur-Map gespeichert sind.
Verfahren gemäß einem der vorangehenden Ansprüche, wobei das Verfahren ferner das Zählen einer Anzahl von anstehenden Vorababrufanforderungen umfasst und wenn die Anzahl von anstehenden Vorababrufanforderungen geringer als eine Schwelle ist, Übertragen der Vorababrufanforderung an den Speicher der ersten Ebene, anderenfalls Fallenlassen der Vorababrufanforderung ohne Übertragen derselben an den Speicher ersten Ebene.
Verfahren gemäß Anspruch 6, wobei das Zählen, das Übertragen und das Fallenlassen in Schaltungen durchgeführt wird, die dem Speicher der zweiten Ebene zugeordnet sind.
Verfahren gemäß einem der vorangehenden Ansprüche, wobei das Verfahren ferner ein Bestimmen umfasst, ob der angeforderte ganze oder Teil des zweiten Blocks in der zweiten Ebene in der Speicherhierarchie vorhanden ist, und wenn bestimmt wird, vorhanden zu sein, Fallenlassen der Vorababrufanforderung ohne Übertragen der Vorababrufanforderung an den ersten Speicher.
Verfahren gemäß Anspruch 8, wobei das Fallenlassen in Schaltungen durchgeführt wird, die dem Speicher der zweiten Ebene zugeordnet sind.
Verfahren gemäß Anspruch 8, wobei das Fallenlassen in Schaltungen durchgeführt wird, die dem Prozessor zugeordnet sind.
Verfahren gemäß einem der vorangehenden Ansprüche, wobei der Prozessor und der andere Prozessor jeweils auf unterschiedliche Bereiche in der dritten Ebene in jeweiligen L1-Caches zugreifen.
Verfahren gemäß einem der vorangehenden Ansprüche, ferner umfassend ein Erfassen, dass das Textur-Mapping ein Teil eines Vollbildzeichnens ist, und Durchführen des Erzeugens der Vorababrufanforderung als Antwort auf das Erfassen.
Verfahren gemäß einem der vorangehenden Ansprüche, wobei das Speichern ein Speichern des abgerufenen ganzen oder Teil des zweiten Blocks in einem Bereich des Speichers der zweiten Ebene umfasst, ohne in der dritten Ebene des Speichers gespeichert zu sein.
Verfahren gemäß Anspruch 13, wobei der abgerufene ganze oder Teil des zweiten Blocks, der in der zweiten Ebene des Speichers gespeichert ist, als Antwort auf eine anschließende Abrufanforderung von dem Prozessor oder dem anderen Prozessor anschließend in der dritten Ebene des Speichers gespeichert wird.
Parallelverarbeitungssystem zum Anzeigen einer Szene, umfassend: mehrere Prozessoren; eine Cache-Hierarchie, die zumindest einen Cache-Speicher der ersten Ebene und einen Cache-Speicher der zweiten Ebene umfasst; eine Anzeigeschnittstelle; und eine Speicherschnittstelle, die konfiguriert ist, um den mehreren Prozessoren Zugriff auf einen Off-Chip-Speicher bereitzustellen, wobei die mehreren Prozessoren und Steuerschaltungen, die der Cache-Hierarchie zugeordnet sind, konfiguriert sind, um: während des Durchführens eines Textur-Mapping der Szene unter Verwendung eines ersten Blocks einer gespeicherten Textur, Erzeugen einer Vorababrufanforderung, durch einen ersten Prozessor der mehreren Prozessoren, um alles oder Teil eines zweiten Blocks der gespeicherten Textur von ein Speicherhierarchie abzurufen, welche die Cache-Hierarchie umfasst; Abrufen des angeforderten ganzen oder Teil des zweiten Blocks aus dem Off-Chip-Speicher über die Speicherschnittstelle als Antwort auf die Vorababrufanforderung; Speichern des abgerufenen ganzen oder Teil des zweiten Blocks in einem Bereich des Cache-Speichers der zweiten Ebene, wobei der Bereich des Cache-Speichers der zweiten Ebene durch den ersten Prozessor und einen zweiten Prozessor von den mehreren Prozessoren zugänglich ist, und wobei der Cache-Speicher der zweiten Ebene eine Speicherzwischenebene zwischen dem Off-Chip-Speicher und dem Cache-Speicher der ersten Ebene ist; Durchführen eines Textur-Mapping der Szene unter Verwendung des abgerufenen ganzen oder Teil des zweiten Blocks; und Rendering der Szene auf einer Anzeigevorrichtung über die Anzeigeschnittstelle.
Parallelverarbeitungssystem gemäß Anspruch 15, wobei das Textur-Mapping der Szene unter Verwendung des ersten Blocks von dem ersten Prozessor durchgeführt wird und das Textur-Mapping der Szene unter Verwendung des zweiten Blocks von dem zweiten Prozessor durchgeführt wird.
Parallelverarbeitungssystem gemäß Anspruch 15 oder 16, wobei eine Adresse für den ganzen oder Teil des zweiten Blocks durch den ersten Prozessor basierend auf einem aus HeaderInformation bestimmten Blockgrößenwert der Textur dynamisch berechnet wird und wobei der Blockgrößenwert von einem anderen Blockgrößenwert unterschiedlich ist, der für eine andere Textur angegeben wird.
Parallelverarbeitungssystem gemäß Anspruch 17, wobei die Adresse für den ganzen oder Teil des zweiten Blocks basierend ferner auf eine Adresse des ersten Blocks bestimmt wird, und wobei die Vorababrufanforderung die bestimmte Adresse des zweiten Blocks und/oder den von der Headerinformation der Textur bestimmten Blockgrößenwert umfasst.
Parallelverarbeitungssystem gemäß Anspruch 18, wobei der ersten Block und der zweiten Block jeweils eine ganzzahlige Anzahl von Texeln umfasst, die in dem Off-Chip-Speicher in einer linearen Blockanordnung in einer gleichen Textur-Map gespeichert sind.
Parallelverarbeitungssystem gemäß einem der Ansprüche 15 bis 19, ferner umfassend Anforderung Drosselschaltungen, die mit dem Cache-Speicher der zweiten Ebene verbunden sind, wobei die Drosselschaltungen konfiguriert sind, um eine Anzahl von anstehenden Vorababrufanforderungen zu zählen, und wenn die Anzahl von anstehenden Vorababrufanforderungen kleiner als ein Schwelle ist, die Vorababrufanforderung an den Off-Chip-Speicher über die Speicherschnittstelle zu übertagen, und andernfalls Fallenlassen der Vorababrufanforderung, ohne sie an den Off-Chip-Speicher zu übertragen.
Parallelverarbeitungssystem gemäß einem der Ansprüche 15 bis 20, ferner umfassend Entduplikationsanforderung-Schaltungen, wobei die Entduplikation-Schaltungen konfiguriert sind, um zu bestimmen, ob der zweite Block in dem Cache-Speicher der zweiten Ebene vorhanden ist, und wenn bestimmt wird, vorhanden zu sein, Fallenlassen der Vorababrufanforderung ohne Übertragen der Vorababrufanforderung an den Off-Chip-Speicher.
Parallelverarbeitungssystem gemäß Anspruch 21, wobei die Entduplikationsanforderung-Schaltungen mit dem ersten Prozessor verbunden sind.
System-on-Chip (SoC), umfassend: zumindest eine zentrale Verarbeitungseinheit (CPU); und zumindest eine Parallelverarbeitungseinheit (PPU), die mit der CPU verbunden ist, wobei jede PPU umfasst: mehrere Multiprozessoren; mehrere Spezialfunktionseinheiten; eine Cache-Hierarchie, die zumindest einen Cache-Speicher der ersten Ebene und einen Cache-Speicher der zweiten Ebene umfasst; und eine Speicherschnittstelle, die konfiguriert ist, um Zugriff auf einen Off-Chip-Speicher bereitzustellen, wobei die mehreren Spezialfunktionseinheiten und die Steuerschaltungen, die der Cache-Hierarchie zugeordnet sind, konfiguriert sind, um als Antwort auf eine von einem der Multiprozessoren empfangenen Anweisung durchzuführen: während des Textur-Mapping einer Szene unter Verwendung eines ersten Blocks einer gespeicherten Textur, Erzeugen einer Vorababrufanforderung durch eine erste Spezialfunktionseinheit von den mehreren Spezialfunktionseinheiten, um alles oder Teil eines zweiten Blocks der gespeicherten Textur aus einer Speicherhierarchie wiederzugewinnen, welche die Cache-Hierarchie umfasst; Abrufen des angeforderten ganzen oder Teil des zweiten Blocks aus dem Off-Chip-Speicher über die Speicherschnittstelle als Antwort auf die Vorababrufanforderung; Speichern des abgerufenen ganzen oder Teil des zweiten Block in einem Bereich des Cache-Speichers der zweiten Ebene, wobei der Bereich des Cache-Speichers der zweiten Ebene durch die erste Spezialfunktionseinheit und einer zweiten Spezialfunktionseinheit der mehreren Spezialfunktionseinheiten zugänglich ist, und wobei der Cache-Speicher der zweiten Ebene eine Speicherzwischenebene zwischen dem Off-Chip-Speicher und dem Cache-Speicher der ersten Ebene ist; Textur-Mapping der Szene unter Verwendung des abgerufenen ganzen oder Teil des zweiten Blocks; und Rendering der Szene auf einer Anzeigevorrichtung über eine Anzeigeschnittstelle.