DE102013020967B4 - Technik zur Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware - Google Patents

Technik zur Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware Download PDF

Info

Publication number
DE102013020967B4
DE102013020967B4 DE102013020967.6A DE102013020967A DE102013020967B4 DE 102013020967 B4 DE102013020967 B4 DE 102013020967B4 DE 102013020967 A DE102013020967 A DE 102013020967A DE 102013020967 B4 DE102013020967 B4 DE 102013020967B4
Authority
DE
Germany
Prior art keywords
texture
memory access
unit
data
access request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102013020967.6A
Other languages
English (en)
Other versions
DE102013020967A1 (de
Inventor
Brian Fahs
Eric T. Anderson
Nick BARROW-WILLIAMS
Shirish Gadre
Joel James McCormack
Bryon S. Nordquist
Nirmal Raj Saxena
Lacky V. Shah
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nvidia Corp
Original Assignee
Nvidia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE102013020967A1 publication Critical patent/DE102013020967A1/de
Application granted granted Critical
Publication of DE102013020967B4 publication Critical patent/DE102013020967B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/60—Memory management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/005—General purpose rendering architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2210/00—Indexing scheme for image generation or computer graphics
    • G06T2210/36—Level of detail

Abstract

Ein computerimplementiertes Verfahren zur Ausführung einer Datenzugriffsoperation, wobei das Verfahren umfasst:Empfangen einer ersten Speicherzugriffsanforderung;Ermitteln, dass die erste Speicherzugriffsanforderung eine Zugriffsoperation für allgemeine Daten repräsentiert, die nicht speziell mit Texturdaten verknüpft sind;Konfigurieren einer Textur-Verarbeitungs-Pipeline (500), um Zugriffsoperationen für allgemeine Daten anstelle von Zugriffsoperationen für Texturdaten auszuführen, wobei das Konfigurieren der Textur-Verarbeitungs-Pipeline (500) umfasst: Konfigurieren einer Textur-orientierten Verarbeitungseinheit innerhalb der Textur-Verarbeitungs-Pipeline (500), um die erste Speicherzugriffsanforderung an eine nachfolgende Verarbeitungseinheit in der Textur-Verarbeitungs-Pipeline (500) weiterzuleiten, ohne Textur-bezogene Operationen mit der ersten Speicherzugriffsanforderung auszuführen; undAusführen der Zugriffsoperation für allgemeine Daten durch Abrufen eines Teils von allgemeinen Daten aus einer Stelle, die aus der ersten Speicherzugriffsanforderung abgeleitet ist.

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft allgemein Speicherzugriffsoperationen und insbesondere eine Technik zur Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware.
  • Beschreibung des Stands der Technik
  • Eine konventionelle grafische Verarbeitungseinheit (GPU) enthält eine Textur-Verarbeitungshardware, die ausgebildet ist, eine Vielzahl von Texturbezogenen Operationen auszuführen, wozu Textur-Ladeoperationen und Textur-Cache-Operationen gehören. Ein Entwickler eines Grafikprogramms kann Schattierungsprogramme erzeugen, die von dieser Textur-Verarbeitungshardware Gebrauch machen, um eine zweidimensionale graphische Szene zu erzeugen.
  • GPU Gems 2: Chapter 32. Taking the Plunge into GPU Computing. </http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter32.html> In: <web.archive.org> am 25.04.2009 (recherchiert am 19.11.2014) beschreibt, wie GPUs als allgemeine Rechenmaschinen verwendet werden können. US 2007 / 0 091 089 A1 beschreibt ein System und ein Verfahren zum dynamischen Lastausgleich mehrerer Shaderstufen in einem gemeinsamen Pool von Verarbeitungseinheiten. US 7 002 591 B1 beschreibt eine Technik zur Durchführung von Speicherzugriffsoperationen über Texturhardware.
  • In jüngerer Zeit habe Entwickler von Programmen damit begonnen, Schattierungsprogramme zu erzeugen, die willkürliche, eine Grafik betreffende Operationen ausführen, die die Parallelverarbeitungs-Architektur der GPU vorteilhaft ausnutzen. Jedoch müssen unter Berücksichtigung der Architektur der Textur-Verarbeitungshardware diese Speicherzugriffsoperationen sehr sorgfältig gestaltet werden, um Textur-Verarbeitungsoperationen nachzubilden. Beispielsweise liest eine typische Textur-Zugriffsoperation zweidimensionale (2D) Texturdaten aus einem Speicher auf der Grundlage von 2D-Koordinaten und Dimensionen, die mit der Textur verknüpft sind, aus. Um ein Schattierungsprogramm zu erzeugen, das in der Lage ist, Nicht-Texturdaten zu laden, muss ein Programmentwickler explizit alle Datenelemente so deklarieren, dass diese 2D-Koordinaten und Abmessungen besitzen, die eine 2D-Datenstruktur ähnlich zu einer Textur wiedergeben, unabhängig von den tatsächlichen Abmessungen, die mit diesen Daten einhergehen.
  • Die oben genannte Vorgehensweise ist problematisch dahingehend, dass eine Erzeugung eines Schattierungsprogramms, das beliebige Berechnungen ausführt, eine extensive Kenntnis der Textur-Verarbeitungsoperationen benötigt, und viele Programmentwickler, die die Parallelverarbeitungsarchitektur der GPUs vorteilhaft ausnutzen wollen, haben eine derartige Kenntnis nicht. Diese Anforderungen stellen eine beträchtliche Hürde für viele Programmentwickler dar.
  • Eine Lösung für dieses Problem besteht darin, einen separaten Datenpfad für allgemeine Speicherzugriffsoperationen zusätzlich zu der bestehenden Textur-Verarbeitungshardware zu schaffen. Mit dieser Vorgehensweise können Programmentwickler, die Verarbeitungsoperationen mit beliebigen Nicht-Texturdaten ausführen wollen, einfach Programme schreiben, die vollständig auf diesem separaten Pfad beruhen. Jedoch ist diese Vorgehensweise problematisch, da konventionelle GPUs einfach nicht den Platz haben, der erforderlich ist, um weitere Datenpfade zu integrieren, und eine Vergrößerung der GPU ist kostenaufwendig.
  • Was daher auf diesem Gebiet der Technik benötigt wird, ist eine effizientere Technik zur Ausführung allgemeiner Datenzugriffsoperationen über eine Textur-Verarbeitungshardware.
  • ÜBERBLICK ÜBER DIE ERFINDUNG
  • Ein computerimplementiertes Verfahren zur Ausführung einer Datenzugriffsoperation umfasst: Empfangen einer ersten Speicherzugriffsanforderung, Ermitteln, dass die erste Speicherzugriffsanforderung eine allgemeine Datenzugriffsoperation repräsentiert, die nicht speziell mit Texturdaten verknüpft sind, Konfigurieren einer Textur-Verarbeitungs-Pipeline derart, dass Zugriffsoperationen für allgemeine Daten anstelle von Zugriffsoperationen für Texturdaten ausgeführt werden, wobei das Konfigurieren der Textur-Verarbeitungs-Pipeline umfasst: Konfigurieren einer Textur-orientierten Verarbeitungseinheit innerhalb der Textur-Verarbeitungs-Pipeline, um die erste Speicherzugriffsanforderung an eine nachfolgende Verarbeitungseinheit in der Textur-Verarbeitungs-Pipeline weiterzuleiten, ohne Textur-bezogene Operationen mit der ersten Speicherzugriffsanforderung auszuführen und Auswählen der Zugriffsoperationen für allgemeine Daten durch Abrufen eines Teils von allgemeinen Daten aus einer Position, die aus der ersten Speicherzugriffsanforderung abgeleitet ist.
  • Ein Vorteil der offenbarten Technik besteht darin, dass die Textur-Verarbeitungshardware in einer grafischen Verarbeitungseinheit (GPU) konfiguriert werden kann, um Zugriffsoperationen für generische bzw. allgemeine Daten auszuführen. Dieser Ansatz ermöglicht es einem Software-Entwickler, Programm-Code zu erzeugen, der vorteilhaft die parallele Architektur der GPU ausnutzt, ohne dass es erforderlich ist, Textur-betreffende Speicherzugriffsoperationen zu implementieren.
  • Figurenliste
  • Um die Art und Weise, in der die oben genannten Merkmale der vorliegenden Erfindung detailliert verstanden werden können, anzugeben, wird eine speziellere Beschreibung der Erfindung, die zuvor kurz zusammengefasst ist, mit Bezug zu Ausführungsformen angegeben, wovon einige in den angefügten Zeichnungen dargestellt sind. Es sollte jedoch beachtet werden, dass die angefügten Zeichnungen nur typische Ausführungsformen dieser Erfindung darstellen und daher nicht als Einschränkung ihres Schutzbereichs zu betrachten sind, da die Erfindung andere gleichermaßen wirksame Ausführungsformen zulässt.
    • 1 ist eine Blockansicht, die ein Computersystem darstellt, das ausgebildet ist, einen oder mehrere Aspekte der vorliegenden Erfindung zu realisieren;
    • 2 ist eine Blockansicht eines Parallelverarbeitungssubsystems für das Computersystem aus 1 gemäß einer Ausführungsform der vorliegenden Erfindung;
    • 3A ist eine Blockansicht des Frontbereichs aus 2 gemäß einer Ausführungsform der vorliegenden Erfindung;
    • 3B ist eine Blockansicht eines allgemeinen Verarbeitungs-Clusters in einer der Parallelverarbeitungseinheiten aus 2 gemäß einer Ausführungsform der vorliegenden Erfindung;
    • 3C ist eine Blockansicht eines Teils des Datenstrom-Multiprozessors aus 3B gemäß einer Ausführungsform der vorliegenden Erfindung;
    • 4 ist eine Konzeptansicht einer Grafikverarbeitungs-Pipeline, in die eine oder mehrere der Parallelverarbeitungseinheiten aus 2 zur Realisierung konfiguriert werden können, gemäß einer Ausführungsform der vorliegenden Erfindung;
    • 5 ist eine Konzeptansicht einer Textur-Verarbeitungs-Pipeline, in die eine Textureinheit innerhalb des allgemeinen Verarbeitungs-Cluster aus 3B zur Realisierung konfiguriert werden kann, gemäß einer Ausführungsform der vorliegenden Erfindung;
    • 6 ist eine Konzeptansicht einer Markierungstabelle gemäß einer
  • Ausführungsform der vorliegenden Erfindung;
  • 7 ist ein Flussdiagramm von Verfahrensschritten zur Ausführung einer Speicherzugriffsoperation über die in 5 gezeigte Textur-Verarbeitungs-Pipeline gemäß einer Ausführungsform der vorliegenden Erfindung; und
  • 8 ist ein Flussdiagramm von Verfahrensschritten zur Zwischenspeicherung und zur Ungültigsetzung von Daten, die mit einer Gruppe von Strängen verknüpft sind, die in dem Datenstrom-Multiprozessor, der in 3B gezeigt ist, gemäß einer Ausführungsform der vorliegenden Erfindung ausgeführt werden.
  • DETAILLIERTE BESCHREIBUNG
  • In der folgenden Beschreibung sind diverse spezielle Details dargestellt, um ein gründlicheres Verständnis der vorliegenden Offenbarung zu ermöglichen. Es ist jedoch für den Fachmann ersichtlich, dass die Erfindung ohne eines oder mehrere dieser speziellen Details praktiziert werden kann.
  • Systemüberblick
  • 1 ist eine Blockansicht, die ein Computersystem 100 darstellt, das ausgebildet ist, einen oder mehrere Aspekte der vorliegenden Erfindung zu realisieren. Das Computersystem 100 umfasst eine zentrale Recheneinheit (CPU) 102 und einen Systemspeicher 104, die über einen Verbindungspfad in Verbindung stehen, der eine Speicherbrücke 105 enthalten kann. Die Speicherbrücke 105, die beispielsweise ein Nordbrücken-Chip sein kann, ist über einen Bus oder einen anderen Kommunikationspfad 106 (beispielsweise eine HyperTransport-Verbindung) mit einer I/O-(Eingangs/Ausgangs-) Brücke 107 verbunden. Die I/O-Brücke 107, die beispielsweise ein Südbrücken-Chip sein kann, empfängt eine Anwendereingabe aus einem oder mehreren Anwender-Eingabegeräten 108 (beispielsweise Tastatur, Maus) und leitet die Eingabe an die CPU 102 über den Kommunikationspfad 106 und die Speicherbrücke 105 weiter. Ein Parallelverarbeitungssubsystem 112 ist mit der Speicherbrücke 105 über einen Bus oder einen zweiten Kommunikationspfad 113 (beispielsweise peripherer Komponentenverbindungs-Express (PCI), beschleunigter Graphikport oder eine HyperTransport-Verbindung) verbunden; in einer Ausführungsform ist das Parallelverarbeitungssubsystem 112 ein grafisches Subsystem, das Pixel an eine Anzeigeeinrichtungen 110 liefert (beispielsweise ein Monitor auf Basis einer konventionellen Kathodenstrahlröhre oder einer Flüssigkristallanzeige). Eine Systemdiskette 114 ist ebenfalls mit der I/O-Brücke 107 verbunden. Ein Schalter 116 stellt Verbindungen zwischen der I/O-Brücke 107 und anderen Komponenten, etwa einem Netzwerkadapter 118 und diversen Zusatzkarten 120 und 121 her. Andere Komponenten (nicht explizit gezeigt) einschließlich eines universellen seriellen Busses (USB) oder andere Portverbindungen, Kompaktdisketten-(CD) Laufwerke, digitale Video Disketten-(DVD) Laufwerke, Filmaufzeichnungsgeräte und dergleichen können ebenfalls mit der I/O-Brücke 107 verbunden sein. Die diversen Kommunikationspfade, die in 1 gezeigt sind, wozu die speziell genannten Kommunikationspfade 106 und 113 gehören, können unter Anwendung beliebiger geeigneter Protokolle eingerichtet werden, etwa PCI-Express, AGP (beschleunigter Graphikport), HyperTransport oder einem beliebigen anderen Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll bzw. Protokollen, und für Verbindungen zwischen unterschiedlichen Geräten können unterschiedliche Protokolle verwenden, wie dies im Stand der Technik bekannt ist.
  • In einer Ausführungsform enthält das Parallelverarbeitungssubsystem 112 eine Schaltung, die für Grafik-und Videoverarbeitung optimiert ist mit beispielsweise einer Videoausgabeschaltung, und bildet eine grafische Verarbeitungseinheit (GPU). In einer weiteren Ausführungsform enthält das Parallelverarbeitungssubsystem 112 eine Schaltung, die für eine Verarbeitung für Allgemeinzwecke optimiert ist, wobei die zu Grunde liegende Rechenarchitektur, wie sie in größerem Detail beschrieben ist, bewahrt ist. In einer noch weiteren Ausführungsform kann das Parallelverarbeitungssubsystem 112 in einem oder mehreren anderen Systemelementen in einem einzelnen Subsystem integriert sein, etwa durch Verbinden der Speicherbrücke 105, der CPU 102 und der I/O-Brücke 107, um ein System auf einem Chip (SoC) zu bilden.
  • Zu beachten ist, dass das hierin beschriebene System nur anschaulich ist und dass Variationen und Modifizierungen möglich sind. Die Verbindungstopologie, wozu die Anzahl und die Anordnung von Brücken, die Anzahl von CPUs 102 und die Anzahl von Parallelverarbeitungssubsystemen 112 gehören, kann nach Bedarf modifiziert werden. Beispielsweise ist in einigen Ausführungsformen der Systemspeicher 104 mit der CPU 102 direkt anstatt über eine Brücke verbunden, und andere Einrichtungen kommunizieren mit dem Systemspeicher 104 über die Speicherbrücke 105 und die CPU 102. In anderen alternativen Topologien ist das Parallelverarbeitungssubsystem 112 mit der I/O-Brücke 107 oder direkt mit der CPU 102 anstatt mit der Speicherbrücke 105 verbunden. In noch anderen Ausführungsformen können die I/O-Brücke 107 und die Speicherbrücke 105 in einem einzelnen Chip integriert sein, anstatt dass sie als eine oder mehrere diskrete Einrichtungen vorgesehen sind. Große Ausführungsformen können zwei oder mehr CPUs 102 und zwei oder mehrere parallele Verarbeitungssysteme 112 enthalten. Die hierin gezeigten speziellen Komponenten sind optional; beispielsweise kann eine beliebige Anzahl an Zusatzkarten oder peripheren Geräten unterstützt werden. In einigen Ausführungsformen kann der Schalter 116 nicht vorhanden sein, und der Netzwerkadapter 118 und die Zusatzkarten 120, 121 können direkt mit der I/O-Brücke 107 verbunden sein.
  • 2 zeigt ein Parallelverarbeitungssubsystem 112 gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt, enthält das Parallelverarbeitungssubsystem 112 eine oder mehrere Parallelverarbeitungseinheiten (PPU) 202, wovon jede mit einem lokalen Parallelverarbeitungs-(PP) Speicher 204 verbunden ist. Generell enthält ein Parallelverarbeitungssubsystem eine Anzahl an PPUs, wobei U ≥1 ist. (Hierin sind mehrere Vertreter gleicher Objekte mit Bezugszeichen belegt, die das Objekt angeben und Ziffern in Klammern geben den Vertreter an, wenn dies erforderlich ist.) Die PPUs 202 und die Parallelverarbeitungs-Speicher 204 können unter Verwendung einer oder mehrerer integrierter Schaltungseinrichtungen, etwa programmierbare Prozessoren, anwendungsspezifische integrierte Schaltungen (ASIC) oder Speichereinrichtungen oder in anderer technisch machbarer Weise realisiert sein.
  • Es sei wieder auf 1 sowie 2 verwiesen; in einigen Ausführungsformen sind einige oder alle PPUs 202 in dem Parallelverarbeitungssubsystem 112 grafische Prozessoren mit Bilderzeugungspipelines, die ausgebildet sein können, diverse Operationen auszuführen, die mit der Erzeugung von Pixeldaten aus Grafikdaten in Beziehung stehen, die von der CPU 102 und/oder dem Systemspeicher 104 über die Speicherbrücke 105 und dem zweiten Kommunikationspfad 113 zugeleitet sind, wobei mit dem lokalen Parallelverarbeitungs-Speicher 204 interagiert wird (der als Grafikspeicher verwendbar ist, beispielsweise einen konventionellen Blockpuffer enthält), um Pixeldaten zu speichern und zu aktualisieren, Pixeldaten zu der Anzeigeeinrichtungen 110 zu liefern, und dergleichen. In einigen Ausführungsformen kann das Parallelverarbeitungssubsystem 112 eine oder mehrere PPUs 202 umfassen, die als Grafikprozessoren arbeiten, und kann eine oder mehrere andere PPUs 202 aufweisen, die für Berechnungen für Allgemeinzwecke verwendet werden. Die PPUs können identisch oder unterschiedlich sein, und jede PPU kann eine spezielle Parallelverarbeitungs-Speichereinrichtung bzw. Einrichtungen oder keine spezielle Parallelverarbeitungs-Speicher bzw. Einrichtungen aufweisen. Eine oder mehrere PPUs 202 in dem Parallelverarbeitungssubsystem 112 können Daten an die Anzeigeeinrichtungen 110 ausgeben, oder jede PPU 202 in dem Parallelverarbeitungssubsystem 112 kann Daten an eine oder mehrere Anzeigeeinrichtungen 110 ausgeben.
  • Im Betrieb ist die CPU 102 der übergeordnete Prozessor des Computersystems 100, und steuert und koordiniert die Operationen anderer Systemkomponenten. Insbesondere gibt die CPU 102 Befehle aus, die den Betrieb der PPUs 202 steuern. In einigen Ausführungsformen schreibt die CPU 102 einen Strom von Befehlen für jede PPU 202 in eine Datenstruktur (in 1 oder 2 nicht explizit gezeigt), die in dem Systemspeicher 104, in dem Parallelverarbeitungs-Speicher 204 oder an einer weiteren Speicherstelle angeordnet sein kann, auf die sowohl die CPU 102 als auch die PPU 202 zugreifen können. Einen Zeiger auf jede Datenstruktur wird in einem Schiebepuffer (das heißt einem Puffer im Speicher, der einen Befehlsstrom für die PPU 202 speichert) abgelegt, um die Verarbeitung des Befehlsstroms in der Datenstruktur zu initiieren. Die PPU 202 liest Befehlsströme aus einem oder mehreren Schiebepuffern aus und führt dann Befehle asynchron relativ zur Betriebsweise der CPU 102 aus. Die Prioritäten für die Ausführung können jedem Schiebepuffer durch ein Anwendungsprogramm über den Gerätetreiber 103 angegeben werden, um die Disponierung bzw. den Ablauf der unterschiedlichen Schiebepuffer zu steuern.
  • Es sei nun wieder zurückverwiesen auf 2 sowie auf 1; jede PPU 202 enthält eine I/O-(Eingangs/Ausgangs-) Einheit 205, die mit dem Rest des Computersystems 100 über den Kommunikationspfad 113 in Verbindung steht, der mit der Speicherbrücke 105 (oder in einer alternativen Ausführungsform direkt mit der CPU 102) verbunden ist. Die Verbindung der PPU 202 mit dem Rest des Computersystems 100 kann auch anders sein. In einigen Ausführungsformen ist das Parallelverarbeitungssubsystem 112 als eine Zusatzkarte realisiert, die in einen Erweiterungsplatz des Computersystems 100 eingeführt werden kann. In anderen Ausführungsformen kann eine PPU 202 auf einem einzelnen Chip zusammen mit einer Busbrücke, etwa der Speicherbrücke 105 oder der I/O-Brücke 107 integriert sein. In noch anderen Ausführungsformen können einige oder alle Elemente der PPU 202 in einem einzelnen Chip zusammen mit der CPU 102 integriert sein.
  • In einer Ausführungsform ist der Kommunikationspfad 113 eine PCI-Express-Verbindung, in der jeder PPU 202 spezielle Bahnen zugewiesen sind, wie dies im Stand der Technik bekannt ist. Es können auch andere Kommunikationspfade verwendet werden. Eine I/O-Einheit 205 erzeugt Pakete (oder andere Signale) zur Übertragung auf dem Kommunikationspfad 113 und empfängt ferner alle eintreffenden Pakete (oder andere Signale) aus dem Kommunikationspfad 113, wobei die eintreffenden Pakete zu entsprechenden Komponenten der PPU 202 geleitet werden. Beispielsweise können Befehle, die mit Verarbeitungsaufgaben in Beziehung stehen, zu einer übergeordneten Schnittstelle 206 geleitet werden, während Befehle, die mit Speicheroperationen in Verbindung stehen (beispielsweise Lesen aus oder schreiben in den Parallelverarbeitungs-Speicher 204) können zu einer Speicherkreuzungseinheit 210 geleitet werden. Die übergeordnete Schnittstelle 206 liest jeden Schiebepuffer aus und gibt den in dem Schiebepuffer gespeicherten Befehlsstrom an einen Frontbereich 212 aus.
  • Jede PPU 202 realisiert vorteilhafterweise eine hoch parallele Verarbeitungsarchitektur. Wie im Detail gezeigt ist, enthält die PPU 202(0) ein Verarbeitung-Cluster-Array 230, das eine Anzahl C an allgemeinen Verarbeitungs-Clustern (GPCs) 208 enthält, wobei C ? 1 ist. Jeder GPC 208 ist in der Lage, eine große Anzahl (beispielsweise hunderte oder tausende) an Strängen gleichzeitig auszuführen, wobei jeder Strang eine Instanz eines Programms ist. In diversen Anwendungen können unterschiedliche GPC 208 unterschiedlichen Arten von Programmen zugewiesen werden oder für das Ausführen unterschiedlicher Arten von Berechnungen zugewiesen werden. Die Zuweisung von GPCs 208 kann in Abhängigkeit von der Arbeitsauslastung variieren, die für jede Art von Programmen oder Berechnung entsteht.
  • Die GPCs 208 empfangen auszuführende Verarbeitungsaufgaben von einer Arbeitsverteilungseinheit innerhalb einer Aufgaben/Arbeitseinheit 207. Die Arbeitsverteilungseinheit empfängt Zeiger auf Verarbeitungsaufgaben, die als Aufgaben-Meta-Daten (TMD) codiert und im Speicher gespeichert sind. Die Zeiger auf die TMD sind in dem Befehlstrom enthalten, der als ein Schiebepuffer gespeichert ist und von der Frontbereichseinheit 212 aus der übergeordneten Schnittstelle 206 empfangen wird. Verarbeitungsaufgaben, die als TMD codiert sein können, enthalten Indizes von zu verarbeitenden Daten, sowie Zustandsparameter und Befehle, die festlegen, wie die Daten zu verarbeiten sind (beispielsweise welches Programm auszuführen ist). Die Aufgaben/Arbeitseinheit 207 empfängt Aufgaben aus dem Frontbereich 212 und stellt sicher, dass die GPCs 208 auf einen zulässigen Zustand konfiguriert sind, bevor die von jeweiligen der TMD spezifizierte Verarbeitung initiiert wird. Es kann eine Priorität für alle TMD festgelegt werden, die verwendet wird, um die Ausführung der Verarbeitungsaufgaben zu disponieren. Verarbeitungsaufgaben können auch aus dem Verarbeitungs-Cluster-Array 230 empfangen werden. Optional können die TMD einen Parameter enthalten, der steuert, ob die TMD dem Kopf oder dem Endbereich für eine Liste von Verarbeitungsaufgaben hinzugefügt werden (oder eine Liste aus Zeigern auf die Verarbeitungsaufgaben), wodurch eine weitere Ebene einer Steuerung für die Priorität bereitgestellt wird.
  • Die Speicherschnittstelle 214 enthält eine Anzahl D an Partitionseinheiten 215, die jeweils direkt mit einem Teilbereich des Parallelverarbeitungs-Speichers 204 verbunden sind, wobei D ≥ 1 ist. Wie gezeigt, ist die Anzahl an Partitionseinheiten 215 generell gleich der Anzahl an dynamischen Speichern mit wahlfreiem Zugriff (DRAM) 220. In anderen Ausführungsformen ist die Anzahl an Partitionseinheiten 215 unter Umständen nicht gleich der Anzahl an Speichereinrichtungen. Der Fachmann erkennt, dass der DRAM 220 durch andere geeignete Speichereinrichtungen ersetzt werden kann und generell von konventioneller Gestaltung sein kann. Eine detaillierte Beschreibung wird daher weggelassen. Bilderzeugungsziele, etwa Blockpuffer oder Texturzuordnungen können über die DRAMs 220 hinweg gespeichert werden, wodurch es den Partitionseinheiten 215 möglich ist, Teilbereiche jedes Bilderzeugungsziels parallel zu beschreiben, um effizient die verfügbare Bandbreite des Parallelverarbeitungs-Speichers 204 auszunutzen.
  • Jede der GPCs 208 kann Daten verarbeiten, die in einem der DRAMs 220 in dem Parallelverarbeitungs-Speicher 204 zu schreiben sind. Die Kreuzungseinheit 210 ist ausgebildet, die Ausgabe jedes GPC 208 zum Eingang einer beliebigen Partitionseinheit 215 oder einer weiteren GPC 208 für die Weiterverarbeitung zu leiten. Die GPCs 208 kommunizieren mit der Speicherschnittstelle 214 über die Kreuzungseinheit 210, um aus diversen externen Speichereinrichtungen zu lesen oder in diese zu schreiben. In einer Ausführungsform besitzt die Kreuzungseinheit 210 eine Verbindung zu der Speicherschnittstelle 214, um mit der I/O-Einheit 205 in Verbindung zu treten, und besitzt auch eine Verbindung zu dem lokalen Parallelverarbeitungs-Speicher 204, wodurch die Verarbeitungskerne in den unterschiedlichen GPCs 208 in der Lage sind, mit dem Systemspeicher 104 oder einem anderen Speicher, der nicht lokal für die PPU 202 ist, zu kommunizieren. In der in 2 gezeigten Ausführungsform ist die Kreuzungseinheit 210 direkt mit der I/O-Einheit 205 verbunden. Die Kreuzungseinheit 210 kann virtuelle Kanäle verwenden, um Verkehrsströme zwischen den GPCs 208 und den Partitionseinheiten 215 zu trennen.
  • Wiederum können die GPCs 208 programmiert sein, um Verarbeitungsaufgaben, die mit einer Fülle von Anwendungen in Beziehung stehen, auszuführen, wozu, ohne einschränkend zu sein, lineare und nicht-lineare Datentransformationen, die Filterung von Video-und/oder Audiodaten, Modelloperationen (beispielsweise Anwendung physikalischer Gesetze zur Bestimmung von Position, Geschwindigkeit und anderen Attributen von Objekten), Bilderzeugungsoperation (beispielsweise Programmen für Parkettierungs-Schattierung, Eckpunkte-Schattierung, Geometrie-Schattierung, und/oder Pixel-Schattierung) usw. gehören. Die PPUs 202 können Daten von dem Systemspeicher 104 und/oder von lokalen Parallelverarbeitungs-Speicher 204 in interne (chipinterne) Speicher übertragen, können die Daten verarbeiten und Ergebnisdaten zurück in den Systemspeicher 104 und/oder die lokalen Parallelverarbeitungs-Speicher 204 schreiben, wodurch auf derartige Daten von anderen Systemkomponenten zugegriffen werden kann, wozu die CPU 102 oder ein weiteres Parallelverarbeitungssubsystem 112 gehören.
  • Eine PPU 202 kann mit einer beliebigen Größe an lokalem Parallelverarbeitungs-Speicher 204 versehen sein, wozu auch kein lokaler Speicher gehört, und kann den lokalen Speicher und den Systemspeicher in beliebiger Kombination verwenden. Beispielsweise kann eine PPU 202 ein Grafikprozessor sein in einer vereinheitlichten Speicherarchitektur-(UMA) Ausführungsform. In derartigen Ausführungsformen würde wenig oder kein spezieller Grafikspeicher (Parallelverarbeitungs-Speicher) bereitgestellt werden, und die PPU 202 würde ausschließlich oder nahezu ausschließlich den Systemspeicher verwenden. In UMA-Ausführungsformen kann eine PPU 202 in einen Brückenchip oder einem Prozessorchip integriert sein oder kann als ein diskreter Chip mit einem Hochgeschwindigkeitsanschluss, beispielsweise PCI-Express) vorgesehen werden, die die PPU 202 mit dem Systemspeicher über einen Brückenchip oder andere Kommunikationseinrichtungen verbindet.
  • Wie zuvor angegeben ist, kann eine beliebige Anzahl an PPUs 202 in einem Parallelverarbeitungssubsystem 112 enthalten sein. Beispielsweise können mehrere PPUs 202 in einer einzelnen Zusatzkarte bereitgestellt sein, oder es können mehrere Zusatzkarten mit dem Kommunikationspfad 113 verbunden sein, oder eine oder mehrere der PPUs 202 können in einem Brückenchip integriert sein. Die PPUs 202 in einem Multi-PPU-System können identisch oder unterschiedlich zueinander sein. Beispielsweise können unterschiedliche PPUs 202 eine unterschiedliche Anzahl an Verarbeitungskernen, unterschiedliche Größen an lokalem Parallelverarbeitungs-Speicher usw. aufweisen. Wenn mehrere PPUs 202 vorhanden sind, können diese PPUs parallel betrieben werden, um Daten mit einem höheren Durchsatz zu verarbeiten, als dies mit einer einzelnen PPU 202 möglich ist. Systeme, die eine oder mehrere PPUs 202 enthalten, können in einer Vielzahl von Konfigurationen und Formfaktoren realisiert sein, wozu Tischrechner, mobile Rechner, oder Hand-Personalcomputer, Dienstleistungsrechner, Arbeitsplatzrechner, Spielekonsolen, eingebettete Systeme usw. gehören.
  • Mehrfache gleichzeitige Aufgabendisponierung
  • Es können mehrere Verarbeitungsaufgaben gleichzeitig in den GPCs 208 ausgeführt werden, und eine Verarbeitungsaufgabe kann während der Ausführung ein oder mehrere „Kind-“ Verarbeitungsaufgaben erzeugen. Die Aufgaben/Arbeitseinheit 207 empfängt die Aufgaben und disponiert dynamisch die Verarbeitungsaufgaben und die Kind-Verarbeitungsaufgaben für die Ausführung durch die GPCs 208.
  • 3A ist eine Blockansicht der Aufgaben/Arbeitseinheit 207 aus 2 gemäß einer Ausführungsform der vorliegenden Erfindung. Die Aufgaben/Arbeitseinheit 207 umfasst eine Aufgabenverwaltungseinheit 300 und die Arbeitsverteilungseinheit 340. Die Aufgabenverwaltungseinheit 300 verwaltet Aufgaben derart, dass diese auf der Grundlage des Grades an Aufgabenpriorität disponiert werden. Für jede Prioritätsebene speichert die Aufgabenverwaltungseinheit 300 eine Liste aus Zeigern auf die TMD 322, die den Aufgaben in der Disponiertabelle 321 entsprechen, wobei die Liste als eine verknüpfte Liste realisiert werden kann. Die TMD 322 können in dem PP-Speicher 204 oder in dem Systemspeicher 104 gespeichert sein. Die Rate, mit der die Aufgabenverwaltungseinheit 300 Aufgaben annimmt und die Aufgaben in der Disponiertabelle 321 speichert, ist unabhängig von der Rate, mit der die Aufgabenverwaltungseinheit 300 Aufgaben für die Ausführung disponiert. Daher kann die Aufgabenverwaltungseinheit 300 mehrere Aufgaben vor dem Disponieren der Aufgaben sammeln. Die gesammelten Aufgaben können dann auf der Grundlage einer Prioritätsinformation oder unter Anwendung von Techniken, etwa einer Rundlauf-Disponierung, disponiert werden.
  • Die Arbeitsverteilungseinheit 340 umfasst eine Aufgabentabelle 345 mit Spalten bzw. Zeitnischen, die jeweils von den TMD 322 für eine Aufgabe, die gerade ausgeführt wird, besetzt sein können. Die Aufgabenverwaltungseinheit 300 kann Aufgaben für die Ausführung disponieren, wenn es eine freie Spalte in der Aufgabentabelle 345 gibt. Wenn es keine freie Spalte bzw. Zeitnische gibt, kann eine Aufgabe mit höherer Priorität, die keine Spalte besetzt, eine Aufgabe mit geringerer Priorität verdrängen, die eine Spalte einnimmt. Wenn eine Aufgabe verdrängt wird, wird die Aufgabe angehalten, und wenn die Ausführung der Aufgabe nicht abgeschlossen ist, dann kann ein Zeiger auf die Aufgabe zu einer Liste aus Aufgabenzeiger, die zu disponieren sind, hinzugefügt werden, so dass die Ausführung der Aufgabe zu einer späteren Zeit wieder fortgesetzt wird. Wenn eine Kind-Verarbeitungsaufgabe während der Ausführung einer Aufgabe erzeugt wird, wird ein Zeiger auf die Kind-Aufgabe der Liste aus Aufgabenzeiger, die zu disponieren sind, hinzugefügt. Eine Kind-Aufgabe kann von den TMD 322 erzeugt werden, die in dem Verarbeitungs-Cluster-Array 230 abgearbeitet werden.
  • Anders als eine Aufgabe, die von der Aufgaben/Arbeitseinheit 207 aus dem Frontbereich 212 empfangen wird, werden Kind-Aufgaben aus dem Verarbeitungs-Cluster-Array 230 empfangen. Kind-Aufgaben werden nicht in Schiebepuffer eingefügt oder an den Frontbereich gesendet. Die CPU 102 wird nicht verständigt, wenn eine Kind-Aufgabe erzeugt wird oder Daten für die Kind-Aufgabe in dem Speicher gespeichert werden. Ein weiterer Unterschied zwischen den Aufgaben, die mittels Schiebepuffern bereitgestellt werden, und Kind-Aufgaben besteht darin, dass die durch die Schiebepuffer bereitgestellten Aufgaben von dem Anwendungsprogramm definiert sind, wohingegen die Kind-Aufgaben während der Ausführung der Aufgaben dynamisch erzeugt werden.
  • Überblick über die Aufgabenverarbeitung
  • 3B ist eine Blockansicht einer GPC 208 innerhalb einer der PPUs 202 aus 2 gemäß einer Ausführungsform der vorliegenden Erfindung. Jeder GPC 208 kann ausgebildet sein, eine große Anzahl an Strängen parallel auszuführen, wobei der Begriff „Strang“ eine Instanz eines speziellen Programms bezeichnet, das auf einem speziellen Satz an Eingangsdaten operiert. In einigen Ausführungsformen werden Einzelbefehl, Mehrfach-Daten-(SIMD) Befehlsausgabetechniken angewendet, um eine parallele Abarbeitung einer großen Anzahl an Strängen ohne das Vorsehen mehrerer unabhängiger Befehlseinheiten zu unterstützen. In anderen Ausführungsformen werden Einzelbefehl, Mehrfach-Strang- (SIMT) Techniken eingesetzt, um eine parallele Abarbeitung einer großen Anzahl an generell synchronisierten Strängen zu unterstützen, wobei eine übliche Befehlseinheit verwendet wird, die ausgebildet ist, Befehle an eine Gruppe von Verarbeitungseinheiten innerhalb jeder einzelnen der GPCs 208 auszugeben. Anders als bei einem SIMD-Ausführungsregime, in welchem Verarbeitungseinheiten typischerweise identische Befehle ausführen, erlaubt eine SIMT-Ausführung, dass unterschiedliche Stränge besser divergenten Ausführungspfaden durch ein gegebenes Strangprogramm folgen. Der Fachmann auf dem Gebiet versteht, dass ein SIMD-Verarbeitungsregime eine funktionale Untergruppe eines SIMT-Verarbeitungsregimes darstellt.
  • Der Betrieb des GPC 208 wird vorteilhafterweise über einen Pipeline-Verwalter 305 gesteuert, der Verarbeitungsaufgaben an Datenstrom-Multi-Prozessoren (SM) 310 verteilt. Der Pipeline-Verwalter 305 kann auch ausgebildet sein, eine Arbeitsverteilungskreuzungseinheit 330 dadurch zu steuern, dass spezielle Ziele durch den SM 310 für verarbeitete Datenausgaben angegeben werden.
  • In einer Ausführungsform umfasst jeder GPC 208 eine Anzahl M aus SM 310, wobei M ≥ 1 ist, wobei jeder SM 310 ausgebildet ist, eine oder mehrere Stranggruppen zu verarbeiten. Ferner enthält jeder SM 310 vorteilhafterweise eine identische Gruppe aus Funktionsausführungseinheiten (beispielsweise Ausführungseinheiten und Lade-Speicher-Einheiten - die als Exec-Einheiten 302 und LSUs 303 in 3C gezeigt sind), die als Pipeline betrieben werden können, wodurch ein neuer Befehl ausgegeben werden kann, bevor ein vorhergehender Befehl fertig bearbeitet ist, wie dies im Stand der Technik bekannt ist. Es kann eine beliebige Kombination aus Funktionsausführungseinheiten bereitgestellt werden. In einer Ausführungsform unterstützen die Funktionseinheiten eine Vielzahl von Operationen, wozu Ganzzahl-oder Gleitkommazahlarithmetik (beispielsweise Addition und Multiplikation), Vergleichsoperationen, Bool'sche Operationen (UND, ODER, XOR), Bit-Verschiebung und Berechnung diverser algebraischer Funktionen (beispielsweise ebene Interpolation, Trigonometrie, exponentielle und logarithmische Funktionen usw.) gehören; und die gleiche Funktionseinheiten-Hardware kann wirksam eingesetzt werden, um unterschiedliche Operationen auszuführen.
  • Die Reihe von Befehlen, die einem speziellen GPC 208 zugeleitet werden, bilden einen Strang, wie dies zuvor hierin definiert ist, und die Ansammlung einer gewissen Anzahl an gleichzeitig ausgeführten Strängen über die Parallelverarbeitungseinheiten hinweg (nicht gezeigt) innerhalb eines SM 310 wird hierin als eine „Wölbung“ oder „Stranggruppe“ bezeichnet. Im hierin verwendeten Sinne bezeichnet eine „Stranggruppe“ eine Gruppe aus Strängen, die gleichzeitig das gleiche Programm an verschiedenen Eingangsdaten ausführt, wobei ein einzelner Strang der Gruppe einer anderen Verarbeitungseinheit innerhalb eines SM 310 zugewiesen ist. Eine Stranggruppe kann weniger Stränge als die Anzahl an Verarbeitungseinheiten innerhalb des SM 310 enthalten, in welchem Falle gewisse Verarbeitungseinheiten in Zyklen untätig sind, wenn diese Stranggruppe verarbeitet wird. Eine Stranggruppe kann ferner mehr Stränge als die Anzahl an Verarbeitungseinheiten innerhalb des SM 310 enthalten, in welchem Falle die Verarbeitung über aufeinanderfolgende Taktzyklen hinweg erfolgen wird. Da jeder SM 310 bis zu G Stranggruppen gleichzeitig handhaben kann, folgt, dass bis zu G*M Stranggruppen in dem GPC 208 zu jeder Zeit ausgeführt werden können.
  • Ferner können mehrere in Beziehung stehende Stranggruppen (in unterschiedlichen Phasen der Ausführung) gleichzeitig innerhalb eines SM 310 aktiv sein. Diese Ansammlung aus Stranggruppen wird hierin als ein „kooperatives Strang-Array“ („CTA“) oder „Strang-Array“ bezeichnet. Die Größe eines speziellen CTA ist gleich m*k, wobei k die Anzahl gleichzeitig ausgeführter Stränge in einer Stranggruppe ist und typischerweise ein ganzzahliges Vielfaches der Anzahl an Parallelverarbeitungseinheiten innerhalb des SM 310 ist, und m ist die Anzahl an Stranggruppen, die gleichzeitig innerhalb des SM 310 aktiv sind. Die Größe eines CTA ist generell von dem Programmierer und der Menge an Hardwareressourcen, etwa Speichern oder Registern, die für das CTA verfügbar sind, bestimmt.
  • Jeder SM 310 enthält einen Cache-Speicher der Ebene 1 (L1) (in 3C gezeigt) oder verwendet Speicherplatz in einem entsprechenden L1-Cache-Speicher außerhalb des SM 310, der verwendet wird, um Lade-und Speicheroperationen auszuführen. Jeder SM 310 hat ferner Zugriff auf Cache-Speicher der Ebene 2 (L2), die gemeinsam von allen GPCs 208 benutzt werden und die verwendet werden können, um Daten zwischen Strängen auszutauschen. Schließlich haben die SMs 310 auch Zugriff auf einen chipexternen „globalen“ Speicher, der beispielsweise den Parallelverarbeitungs-Speicher 204 und/oder den Systemspeicher 104 umfassen kann. Zu beachten ist, dass ein beliebiger Speicher außerhalb der PPU 202 als globaler Speicher verwendet werden kann. Ferner kann ein Cache-Speicher der Ebene eins-Punkt-fünf (L1.5) in dem GPC 208 enthalten und ausgebildet sein, Daten zu empfangen und zu halten, die aus dem Speicher über die Speicherschnittstelle 214 abgerufen werden und von dem SM 310 angefordert sind, wozu Befehle, gleichmäßige Daten und konstante Daten gehören, und die angeforderten Daten dem SM 310 zuzuführen. Ausführungsformen mit mehreren SMs 310 in dem GPC 208 verwenden vorteilhafterweise gemeinsame Befehle und Daten, die in dem Cache-Speicher L1.5 335 abgelegt sind.
  • Jeder GPC 208 kann eine Speicherverwaltungseinheit (MMU) 328 enthalten, die ausgebildet ist, virtuelle Adressen physikalischen Adressen zuzuordnen. In anderen Ausführungsformen kann bzw. können die MMU(s) 328 innerhalb der Speicherschnittstelle 214 angeordnet sein. Die MMU 328 enthält eine Gruppe aus Seitentabelleneinträgen (PTEs), die zum Zuordnen einer virtuellen Adresse zu einer physikalischen Adresse einer Kachel verwendet ist, und optional einen Cache-Zeilenindex. Die MMU 328 kann Adressen-Translations-Nebenschau-Puffer (TLB) oder Cache-Speicher enthalten, die in dem Multiprozessor SM 310 oder dem L1-Cache-Speicher oder dem GPC 208 angeordnet sind. Die physikalische Adresse wird verarbeitet, um Oberflächendaten-Zugriffslokalität zu verteilen, so dass eine effiziente Anforderungsverschachtelung zwischen Partitionseinheiten 215 möglich ist. Der Cache-Zeilenindex kann verwendet werden, um zu bestimmen, ob eine Anforderung für eine Cache-Zeile ein Treffer oder kein Treffer ist.
  • In grafischen Anwendungen und Rechenanwendungen kann ein GPC 208 so ausgebildet sein, dass jeder SM 310 mit einer Textureinheit 315 zum Ausführen von Texturzuordnungsoperationen verbunden ist, beispielsweise die Bestimmung von Texturprobenpositionen, das Auslesen von Texturdaten und das Filtern der Texturdaten. Texturdaten werden aus einem internen Textur-L1-Cache-Speicher (nicht gezeigt) oder in einigen Ausführungsformen aus dem L1-Cache-Speicher innerhalb des SM 310 ausgelesen und aus einem L2-Cache-Speicher, der für alle GPCs 208 gemeinsam ist, aus dem Parallelverarbeitungs-Speicher 204 oder dem Systemspeicher 104 nach Bedarf abgerufen. Jeder SM 310 gibt verarbeitete Aufgaben an die Arbeitsverteilungskreuzungseinheit 330 aus, um die verarbeitete Aufgabe einem weiteren GPC 208 für die weitere Verarbeitung zuzuleiten oder um die verarbeitete Aufgabe in einem L2-Cache-Speicher, in dem Parallelverarbeitungs-Speicher 204 oder in dem Systemspeicher 104 über die Kreuzungseinheit 210 zu speichern. Eine Vor-ROP-Einheit (Vor-Rasteroperationen) 325 ist ausgebildet, Daten aus dem SM 310 zu empfangen, Daten an ROP-Einheiten innerhalb der Partitionseinheiten 215 weiterzuleiten und Optimierungen für die Farbmischung auszuführen, Pixel-Farbdaten zu organisieren und Adressenübersetzungen auszuführen.
  • Es ist zu beachten, dass die hierin beschriebene Kernarchitektur anschaulich ist und dass Variationen und Modifizierungen möglich sind. Es kann eine beliebige Anzahl an Verarbeitungseinheiten, beispielsweise SMs 310 oder Textureinheiten 315, Vor-ROP-Einheiten 325 in einem GPC 208 enthalten sein. Wie ferner in 2 gezeigt ist, kann eine PPU 202 eine beliebige Anzahl an GPCs 208 enthalten, die vorteilhafterweise in funktionaler Hinsicht ähnlich zueinander sind, so dass das Arbeitsverhalten nicht davon abhängt, welcher GPC 208 eine spezielle Verarbeitungsaufgaben empfängt. Ferner arbeitet jeder GPC 208 vorteilhafterweise unabhängig von anderen GPCs 208 unter Verwendung separater und unabhängiger Verarbeitungseinheiten, L1-Cache Speicher, um Aufgaben für ein oder mehrere Anwendungsprogramme auszuführen.
  • Der Fachmann auf diesem Gebiet weiß, dass die in den 1, 2, 3A und 3B beschriebene Architektur in keiner Weise den Schutzbereich der vorliegenden Erfindung beschränkt und dass die hierin gelehrten Techniken in einer beliebigen geeignet konfiguriertem Verarbeitungseinheit realisiert werden können, wozu, ohne Einschränkung, gehören: eine oder mehrere CPUs, eine oder mehrere CPUs mit mehreren Kernen, eine oder mehrere PPUs 202, ein oder mehrere GPCs 208, eine oder mehrere grafische Verarbeitungseinheiten oder Verarbeitungseinheiten für spezielle Zwecke, usw., ohne von dem Schutzbereich der vorliegenden Erfindung abzuweichen.
  • In Ausführungsformen der vorliegenden Erfindung ist es wünschenswert, die PPU 202 oder einen anderen Prozessor oder Prozessoren eines Rechnersystems zu verwenden, um Berechnungen für Allgemeinzwecke unter Verwendung von Strang-Arrays auszuführen. Jedem Strang in dem Strang-Array ist eine eindeutige Strangkennung („Strang-ID“) zugewiesen, auf die von dem Strang während der Ausführung des Strangs zugegriffen werden kann. Die Strang-ID, die als ein eindimensionaler oder mehrdimensionaler numerischer Wert definiert sein kann, steuert diverse Aspekte des Prozessverhaltens des Strangs. Beispielsweise kann eine Strang-ID verwendet werden, um zu bestimmen, welcher Teilbereich des Eingangsdatensatzes von einem Strang verarbeitet werden soll, und/oder um zu bestimmen, welcher Teilbereich eines Ausgangsdatensatzes von einem Strang erzeugt oder geschrieben werden soll.
  • Eine Sequenz aus Befehlen pro Strang kann mindestens einen Befehl umfassen, der ein kooperatives Verhalten zwischen dem repräsentativen Strang und einem oder mehreren anderen Strängen des Strang-Arrays festlegt. Beispielsweise kann die Sequenz aus Befehlen pro Strang einen Befehl enthalten, um die Ausführung von Operationen für den repräsentativen Strang an einem speziellen Punkt in der Sequenz auszusetzen, bis zu dem Zeitpunkt, an welchem ein oder mehrere der anderen Stränge diesen speziellen Punkt erreichen, einen Befehl für den repräsentativen Strang enthalten, um Daten in einem gemeinsamen Speicher zu speichern, auf den ein oder mehrere der anderen Stränge Zugriff haben, einen Befehl für den repräsentativen Strang enthalten, um Daten in atomarer Weise zu lesen und zu aktualisieren, die in einem gemeinsamen Speicher abgelegt sind, auf den ein oder mehrere der anderen Stränge auf Grundlage ihrer Strang-ID Zugriff haben, oder dergleichen. Das CTA-Programm kann ferner einen Befehl enthalten, um eine Adresse für den gemeinsamen Speicher zu berechnen, aus dem Daten auszulesen sind, wobei die Adresse eine Funktion der Strang-ID ist. Durch das Definieren geeigneter Funktionen und das Bereitstellen von Synchronisiertechniken können Daten an eine gegebene Speicherstelle in einem gemeinsamen Speicher durch einen Strang eines CTA geschrieben und aus dieser Speicherstelle durch einen anderen Strang des gleichen CTA in einer vorhersagbaren Weise ausgelesen werden. Folglich kann ein beliebiges gewünschtes Muster für die gemeinsame Nutzung von Daten zwischen Strängen unterstützt werden, und jeder Strang in einem CTA kann Daten mit einem anderen Strang in dem gleichen CTA gemeinsam benutzen. Der Grad, falls verhandeln, der gemeinsamen Datennutzung zwischen den Strängen eines CTA ist durch das CTA-Programm bestimmt; es ist daher zu beachten, dass in einer speziellen Anwendung, die CTAs verwendet, die Stränge eines CTA gemeinsam Daten nutzen können oder auch nicht, wobei dies von dem CTA-Programm abhängt, und die Begriffe „CTA“ und „Strang-Array“ werden hierin als Synonym verwendet.
  • 3C ist eine Blockansicht des SM 310 aus 3B gemäß einer Ausführungsform der vorliegenden Erfindung. Der SM 310 umfasst einen Befehls-L1-Cache-Speicher 370, der ausgebildet ist, Befehle und Konstanten aus dem Speicher über den L1.5-Cache-Speicher 335 zu empfangen. Eine Wölbungs-Disponier- und Befehlseinheit 312 empfängt Befehle und Konstanten aus dem Befehls-L1-Cache-Speicher 370 und steuert eine lokale Registerdatei 304 und die SM 310-Funktionseinheiten entsprechend den Befehlen und den Konstanten. Die SM 310-Funktionseinheiten enthalten N Exec-(Ausführungs-oder Verarbeitungs-) Einheiten 302 und P Lade-Speicher-Einheiten (LSU) 303.
  • Der SM 310 stellt chipinternen (internen) Datenspeicherplatz bereit mit unterschiedlichen Ebenen an Zugreifbarkeit. Spezialregister (nicht gezeigt) können ausgelesen aber nicht beschrieben werden durch die LSU 303 und werden verwendet, um Parameter zu speichern, die die „Position“ jedes Strangs festlegen. In einer Ausführungsform umfassen die Spezialregister ein einzelnes Register pro Strang (oder pro Exec-Einheit 302 innerhalb des SM 310), das eine Strang-ID speichert; jedes Strang-ID-Register kann nur von einer entsprechenden einen der Exec-Einheiten 302 ausgelesen werden. Die Spezialregister können ferner zusätzliche Register umfassen, die von allen Strängen ausgelesen werden können, die die gleiche Verarbeitungsaufgaben ausführen, die von einem Satz an TMD 322 repräsentiert ist (oder von allen LSUs 303), die eine CTA-Kennung, die CTA-Dimensionen, die Dimensionen eines Gitters, zu welchen das CTA gehört (oder Warteschlangenposition, wenn die TMD 322 eine Warteschlangeaufgabe anstelle einer Gitteraufgabe kodieren) und eine Kennung der TMD 322 speichern, denen das CTA zugeordnet ist.
  • Wenn die TMD 322 Gitter-TMD sind, verursacht die Ausführung der TMD 322, dass eine feste Anzahl an CTA gestartet und ausgeführt wird, um die festgelegte Menge an Daten zu verarbeiten, die in der Warteschlange 525 gespeichert sind. Die Anzahl an CTAs ist als das Produkt der Gitterbreite, Gitterhöhe und Gittertiefe spezifiziert. Die festgelegte Menge an Daten kann in den TMD 322 gespeichert sein oder die TMD 322 können einen Zeiger auf die Daten speichern, die von den CTAs verarbeitet werden. Die TMD 322 speichern ferner eine Startadresse des Programms, das von den CTAs ausgeführt wird.
  • Wenn die TMD 322 Warteschlangen-TMD sind, dann wird ein Warteschlangemerkmal der TMD 322 verwendet, was bedeutet, dass die zu verarbeitende Datenmenge nicht notwendigerweise festgelegt ist. Warteschlangeneinträge speichern Daten für die Verarbeitung durch die CTAs, die den TMD 322 zugeordnet sind. Die Warteschlangeneinträge können auch eine Kind-Aufgabe repräsentieren, die von weiteren TMD 322 während der Ausführung eines Strangs erzeugt wird, wodurch eine eingebettete Parallelität bereitgestellt wird. Typischerweise wird die Ausführung des Strangs oder des CTA, der bzw. das den Strang enthält, ausgesetzt, bis die Ausführung der Kind-Aufgabe abgeschlossen ist. Die Warteschlange kann in den TMD 322 oder separat zu den TMD 322 gespeichert sein, in welchem Falle die TMD 322 einen Warteschlangenzeiger auf die Warteschlange speichern. Vorteilhafterweise können Daten, die von der Kind-Aufgabe erzeugt sind, in die Warteschlange geschrieben werden, während die TMD 322, die die Kind-Aufgabe repräsentieren, abgearbeitet werden. Die Warteschlange kann als eine Ring-Warteschlange realisiert werden, so dass die gesamte Menge an Daten nicht durch die Größe der Warteschlange begrenzt ist.
  • CTA, die zu einem Gitter gehören, besitzen implizite Parameter für die Gitterbreite, Höhe und Tiefe, wodurch die Position des jeweiligen CTA innerhalb des Gitters angegeben ist. Die Spezialregister werden während der Initialisierung in Reaktion auf Befehle beschrieben, die über den Frontbereich 212 aus dem Gerätetreiber 103 empfangen werden, und die Register ändern sich nicht während der Ausführung einer Verarbeitungsaufgabe. Der Frontbereich 212 disponiert jede Verarbeitungsaufgabe für die Ausführung. Jedes CTA ist mit speziellen TMD 322 für die gleichzeitige Ausführung einer oder mehrerer Aufgaben verknüpft. Ferner kann ein einzelner GPC 208 mehrere Aufgaben gleichzeitig ausführen.
  • Ein Parameterspeicher (nicht gezeigt) speichert Laufzeitparameter (Konstanten), die von einem beliebigen Strang innerhalb des gleichen CTA (oder einer LSU 303) ausgelesen aber nicht geschrieben werden können. In einer Ausführungsform leitet der Gerätetreiber 103 Parameter dem Parameterspeicher zu, bevor der SM 310 angewiesen wird, die Ausführung einer Aufgabe zu beginnen, die diese Parameter verwendet. Ein beliebiger Strang innerhalb eines beliebigen CTA (oder einer Exec-Einheit 302 in dem SM 310) kann auf den globalen Speicher über eine Speicherschnittstelle 214 zugreifen. Bereiche des globalen Speichers können in dem L1-Cache-Speicher 320 gespeichert werden.
  • Die lokale Registerdatei 304 wird von jedem Strang als Arbeitsraum verwendet; jedes Register ist für die ausschließliche Verwendung durch einen einzelnen Strang reserviert, und Daten in einer beliebigen lokalen Registerdatei 304 sind nur von dem Strang abrufbar, dem das Register zugewiesen ist. Die lokale Registerdatei 304 kann als eine Registerdatei realisiert werden, die physikalisch oder logisch in P Bahnen unterteilt ist, wobei jede eine gewisse Anzahl an Einträgen besitzt (wobei jeder Eintrag beispielsweise ein 32-Bit-Wort speichern kann). Es ist jeweils eine Bahn jeder der N Exec-Einheiten 302 und jeder der P Lade-Speicher-Einheiten LS 303 zugewiesen, und entsprechende Einträge in unterschiedlichen Bahnen können mit Daten für unterschiedliche Stränge, die das gleiche Programm ausführen, angereichert werden, um eine SIMD-Ausführung zu ermöglichen. Unterschiedliche Bereiche der Bahnen können unterschiedlichen Gruppen der G gleichzeitigen Stranggruppen zugewiesen werden, so dass ein gegebener Eintrag in der lokalen Registerdatei 304 nur von einem speziellen Strang abgerufen werden kann. In einer Ausführungsform sind gewisse Einträge innerhalb der lokalen Registerdatei 304 zur Speicherung von Strangkennungen reserviert, wodurch eines der Spezialregister realisiert wird. Ferner enthält ein Gleichmäßigkeits-L1 -Cache-Speicher 375 gleichmäßige oder konstante Werte für jede Bahn der N Exec-Einheiten 302 und der P Lade-Speicher-Einheiten LS 303.
  • Auf den gemeinsamen Speicher 306 kann von Strängen innerhalb eines einzelnen CTA zugegriffen werden; anders ausgedrückt, jede Speicherstelle in dem gemeinsamen Speicher 306 ist für jeden Strang innerhalb des gleichen CTA ansprechbar (oder eine beliebige Verarbeitungseinheit innerhalb des SM 310). Der gemeinsame Speicher 306 kann als eine gemeinsame Registerdatei oder ein gemeinsamer chipinterner Cache-Speicher mit einer Verbindung realisiert sein, die es einer beliebigen Verarbeitungseinheit ermöglicht, eine beliebige Stelle in dem gemeinsamen Speicher zu beschreiben oder diese auszulesen. In anderen Ausführungsformen kann ein gemeinsamer Zustandsraum auf ein Gebiet pro CTA eines chipexternen Speichers abgebildet sein, und kann in dem L1-Cache-Speicher 320 zwischengespeichert sein. Der Parameterspeicher kann als ein spezieller Abschnitt innerhalb der gleichen gemeinsamen Registerdatei oder des gemeinsamen Cache-Speichers realisiert sein, der den gemeinsamen Speicher 306 bildet, oder kann als eine separate gemeinsame Registerdatei oder ein chipinterner Cache-Speicher realisiert sein, auf den die LSUs 303 einen Nur-Lese-Zugriff besitzen. In einer Ausführungsform wird der Bereich, der den Parameterspeicher realisiert, auch verwendet, um die CTA-ID und die Aufgaben-ID sowie CTA-und Gitterabmessungen oder Warteschlangenposition zu speichern, wodurch Bereiche der Spezialregister realisiert werden. Jede LSU 303 in dem SM 310 ist mit einer vereinheitlichten Adressenzuordnungseinheit 352 verbunden, die eine Adresse, die für ade-und Speicherbefehle bereitgestellt ist, die in einem vereinheitlichten Speicherbereich angegeben sind, in eine Adresse in jedem separaten Speicherbereich umwandelt. Folglich kann ein Befehl verwendet werden, um auf den lokalen, gemeinsamen oder globalen Speicherbereich zuzugreifen, indem eine Adresse in dem vereinheitlichten Speicherbereich angegeben wird.
  • Der L1 -Cache-Speicher 320 in jedem SM 310 kann verwendet werden, um private lokale Daten pro Strang und auch globale Daten pro Anwendung zwischenzuspeichern. In einigen Ausführungsformen können die gemeinsamen Daten pro CTA in dem L1-Cache-Speicher 320 zwischengespeichert werden. Die LSUs 303 sind mit dem gemeinsamen Speicher 306 und dem L1-Cache-Speicher 320 über eine Speicher-und Cache-Verbindung 380 verbunden.
  • Architektur der Grafik-Pipeline
  • 4 ist eine Konzeptansicht einer Grafikverarbeitungs-Pipeline 400, die in eine oder mehrere der PPUs 202 aus 2 zur Realisierung konfiguriert werden können gemäß einer Ausführungsform der vorliegenden Erfindung. Beispielsweise kann einer der SM 310 so gestaltet sein, dass er die Funktionen einer oder mehrerer Vertex-Verarbeitungseinheiten 415, einer Geometrie-Verarbeitungseinheit 425 und einer Fragment-Verarbeitungseinheit 460 ausführt. Die Funktionen eines Daten-Assemblers 410, eines Grundelemente-Assemblers 420, einer Rastereinheit 455 und einer Rasteroperationen-Einheit 465 können ebenfalls durch andere Verarbeitungseinheiten innerhalb eines GPC 208 und einer entsprechenden Partitionseinheit 215 ausgeführt werden. Andernfalls kann die Grafikverarbeitungs-Pipeline 400 unter Verwendung spezieller Verarbeitungseinheiten für eine oder mehrere Funktionen realisiert werden.
  • Die Verarbeitungseinheit in Form des Daten-Assemblers 410 sammelt Vertex-Daten für Oberflächen höherer Ordnung, Grundelemente und dergleichen und gibt die Vertex-Daten, wozu die Vertex-Attribute gehören, an die Vertex-Verarbeitungseinheit 415 aus. Die Vertex-Verarbeitungseinheit 415 ist eine programmierbare Ausführungseinheit, die ausgebildet ist, Vertex-Schattierungsprogramme auszuführen, um Beleuchtung und die Transformation von Vertex-Daten anzugeben, wie sie durch die Vertex-Schattierungsprogramme spezifiziert sind. Beispielsweise kann die Vertex-Verarbeitungseinheit 415 programmiert sein, um die Vertex-Daten von einer objektbasierten Koordinatendarstellung (Objektraum) in ein Koordinatensystem mit alternativer Basis zu transformieren, etwa in einen Welt-Raum oder in einen normierten Gerätekoordinaten-(NDC) Raum. Die Vertex-Verarbeitungseinheit 415 kann Daten auslesen, die in dem L1-Cache-Speicher 320, in dem Parallelverarbeitungsspeicher 204 oder in dem Systemspeicher 104 von dem Daten-Assemblers 410 zur Verwendung bei der Verarbeitung der Vertex-Daten gespeichert sind.
  • Der Assembler für Grundelemente 420 empfängt Vertex-Attribute aus der Vertex-Verarbeitungseinheit 415, wobei gespeicherte Vertex-Attribute nach Bedarf ausgelesen werden, und baut grafische Grundelemente für die Verarbeitung durch die Geometrie-Verarbeitungseinheit 425 auf. Zu grafischen Grundelementen gehören Dreiecke, Liniensegmente, Punkte und dergleichen. Die Geometrie-Verarbeitungseinheit 425 ist eine programmierbare Ausführungseinheit, die ausgebildet ist, Geometrie-Schattierungsprogramme auszuführen, wobei grafische Grundelemente, die von dem Assembler für Grundelemente 420 empfangen werden, transformiert werden, wie dies durch die Geometrie-Schattierungsprogramme angegeben ist. Beispielsweise kann die Geometrie-Verarbeitungseinheit 425 so programmiert sein, dass sie die grafischen Grundelemente in ein oder mehrere neue grafische Grundelemente unterteilt und Parameter berechnet, etwa Koeffizienten für die Ebenengleichung, die verwendet werden, um die neuen grafischen Grundelemente in Raster einzuteilen.
  • In einigen Ausführungsformen kann die Geometrie-Verarbeitungseinheit 425 auch Elemente dem Geometrie-Strom hinzufügen oder aus diesem löschen. Die Geometrie-Verarbeitungseinheit 425 gibt die Parameter und Vertices bzw. Eckpunkte, die die neuen grafischen Grundelemente angeben, an eine Darstellungsfeld-Skalierungs-, Auswahl-, und Schneideeinheit 450 aus. Die Geometrie-Verarbeitungseinheit 425 kann Daten lesen, die in dem Parallelverarbeitungsspeicher 204 oder in den Systemspeicher 104 gespeichert sind und zur Weiterverarbeitung der Geometriedaten verwendet werden. Die Darstellungsfeld-Skalier-, Auswahl-, und Schneideeinheit 450 führt einen Schneiden, Auswählen und eine Darstellungsfeldskalierung aus und gibt die verarbeiteten grafischen Grundelemente an eine Rastereinheit 455 aus.
  • Die Rastereinheit 455 konvertiert in abtastender Weise die neuen grafischen Grundelemente und gibt Fragmente und Abdeckungsdaten an die Fragment-Verarbeitungseinheit 460 aus. Ferner kann die Rastereinheit 455 ausgebildet sein, eine z-Auswahl und andere z-basierte Optimierungen durchzuführen.
  • Die Fragment-Verarbeitungseinheit 460 ist eine programmierbare Ausführungseinheit, die ausgebildet ist, Fragment-Schattierungsprogramme auszuführen, wobei Fragmente, die aus der Rastereinheit 455 erhalten werden, transformiert werden in der Art, wie dies durch die Fragment-Schattierungsprogramme angegeben ist. Beispielsweise kann die Fragment-Verarbeitungseinheit 460 so programmiert sein, dass Operationen ausgeführt werden, etwa eine perspektivische Korrektur, eine Texturzuordnungen, eine Schattierung, eine Mischung und dergleichen, um schattierte Fragmente zu erzeugen, die an die Rasteroperationen-Einheit 465 ausgegeben werden. Die Fragment-Verarbeitungseinheit 460 kann Daten lesen, die in dem Parallelverarbeitungsspeicher 204 oder in den Systemspeicher 104 zur Verwendung bei der Verarbeitung der Fragmentdaten gespeichert sind. Fragmente können schattiert sein auf Ebene von Pixel, Abtastwerten oder entsprechend einer anderen Auflösung, wobei dies von der programmierten Abtastrate abhängig.
  • Die Rasteroperationseinheit 465 ist eine Verarbeitungseinheit, die Rasteroperationen ausführt, etwa Schablonenbildung, z-Test, Mischung, und dergleichen, und die Pixeldaten als verarbeitete Grafikdaten zur Speicherung an den Grafikspeicher ausgibt. Die verarbeiteten Grafikdaten können in dem Grafikspeicher, beispielsweise den Parallelverarbeitungsspeicher 204 und/oder den Systemspeicher 104 zur Anzeige auf dem Anzeigegerät 110 oder zur weiteren Verarbeitung durch die CPU 102 oder das Parallelverarbeitungssubsystem 112 gespeichert werden. In einigen Ausführungsformen der vorliegenden Erfindung ist die Rasteroperationseinheit 465 ausgebildet, z-oder Farbdaten zu komprimieren, die in den Speicher geschrieben werden, und z-oder Farbdaten zu dekomprimieren, die aus dem Speicher ausgewiesen werden.
  • Wie zuvor in Verbindung mit 3B erwähnt ist, ist die in 3B gezeigte Textureinheit 315 ausgebildet, Textur-Verarbeitungsoperationen anstelle des SM 310 (der ebenfalls in 3B gezeigt ist) auszuführen. Wenn dies bewerkstelligt wird, ist die Textureinheit 315 ausgebildet, Texturdaten aus einer beliebigen der in den 1-3C gezeigten Speichereinheiten zu lesen. Ferner kann die Textureinheit 315 auch ausgebildet sein, Ladeoperationen für den globalen Speicher auszuführen, um beliebige Daten aus diesem Speichereinheiten auszulesen, wobei bestehende Textur-Datenpfade verwendet werden. Wenn der SM 310 ausgebildet ist, Verarbeitungsoperationen für Allgemeinzwecke auszuführen, kann die Textureinheit 315 ausgebildet sein, eine Textur-Verarbeitungs-Pipeline zu realisieren, wie dies nachfolgend in Verbindung mit 5 erläutet ist. Die Textur-Verarbeitungs-Pipeline, die nachfolgend erläutert wird, erlaubt es der Textureinheit 315, Texturdaten oder generische bzw. allgemeine globale Daten über den gleichen Datenpfad auszulesen.
  • Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware
  • 5 ist eine Konzeptansicht einer Textur-Verarbeitungs-Pipeline 500, in die die Textureinheit 315 in dem allgemeinen Verarbeitungs-Cluster 208 aus 3B zur Realisierung gemäß einer Ausführungsform der vorliegenden Erfindung konfiguriert werden kann. Wie gezeigt, umfasst die Textur-Verarbeitungs-Pipeline 500 eine Textur Eingangs-(TEXIN) Einheit 502, die mit einem Zustands-Cache-Speicher 504 verbunden ist, eine Grad-an-Detail-(LOD) Einheit 506, eine Adresseneinheit 508, eine Markierungseinheit 510, eine Fehltreffer-Verarbeitungseinheit 512, und eine Dateneinheit 514, die einen zuersthinein-zuerst-heraus-Speicher (FIFO) 516 und eine Cache-Einheit 518 enthält.
  • Die Textur-Verarbeitungs-Pipeline 500 ist ausgebildet, Speicherzugriffsanforderungen, die aus dem in 3B gezeigten SM 310 empfangen werden, zu verarbeiten. Eine gegebene Speicherzugriffsanforderung könnte eine Zugriffsoperation für Texturdaten repräsentieren, etwa eine Leseoperation, die eine Textur aus dem Speicher ausliest. Alternativ könnte eine gegebene Speicherzugriffsanforderung eine Zugriffsoperation für allgemeine Daten sein, etwa eine Ladeoperation für den globalen Speicher.
  • Eine gegebene Speicherzugriffsanforderung enthält einen „Zustandsindex“, die die TEXIN-Einheit 502 verwendet, um zu ermitteln, ob die Speicherzugriffsanforderung eine Zugriffsoperation für Texturdaten oder eine Zugriffsoperation für allgemeine Daten repräsentiert. Wenn die Textur-Verarbeitungs-Pipeline 500 eine Speicherzugriffsanforderung empfängt, extrahiert die TEXIN-Einheit 502 den Zustandsindex aus der Speicherzugriffsanforderung und vergleicht dann einen Teil des Zustandsindex mit einem Anforderungszustandsregister innerhalb der TEXIN-Einheit 502. Das Anforderungszustandsregister zeigt einen speziellen Index an, der mit Zugriffsoperationen für allgemeine Daten verknüpft ist. Wenn der Zustandsindex, der zu einer gegebenen Speicherzugriffsanforderung gehört, mit dem Anforderungszustandsregister übereinstimmt, dann konfiguriert die TEXIN-Einheit 502 die Textur-Verarbeitungs-Pipeline 500 derart, dass diese eine Zugriffsoperation für allgemeine Daten ausführt. Die TEXIN-Einheit 502 kann auch die Speicherzugriffsanforderung modifizieren, so dass diese eine spezielle Ebene der Zwischenspeicherung für Daten wiedergibt, die mit der Zugriffsoperation für allgemeinen Daten verknüpft sind. In einer Ausführungsform wird die TEXIN-Einheit 502 von einer Softwareanwendung konfiguriert, die in dem SM 310 ausgeführt wird, um Speicherzugriffsanforderungen so zu modifizieren, dass spezielle Zwischenspeicherebenen wiedergegeben werden.
  • In Situationen, in denen die TEXIN-Einheit 502 ermittelt, dass die Speicherzugriffsanforderung eine Zugriffsoperation für Texturdaten repräsentiert, konfiguriert die TEXIN-Einheit 502 die Textur-Verarbeitungs-Pipeline 500 derart, dass diese eine Zugriffsoperation für Texturdaten ausführt. In einer Ausführungsform kann eine Softwareanwendung, etwa beispielsweise der in 1 gezeigten Treiber 103 ausgeführt werden, um das Anforderungszustandsregister zu konfigurieren.
  • Bei der Verarbeitung von Speicherzugriffsanforderungen, die Zugriffsoperationen für Texturdaten repräsentieren, verwendet die TEXIN-Einheit 502 den Zustandsindex, um auf den Zustands-Cache-Speicher 504 zuzugreifen. Die TEXIN-Einheit 502 extrahiert aus dem Zustands-Cache-Speicher 504 zusätzliche Texturinformation, die den Texturdaten entspricht, die aus dem Speicher abzurufen sind. Die zusätzliche Texturinformation kann eine Textelement-Größe, den Anfangspunkt der Textur, die Texturabmessungen und Begrenzungsdaten für die Textur zusätzlich zu anderen Arten von Texturbezogener Information enthalten. Die TEXIN-Einheit 502 kann diese zusätzliche Texturinformation in die Speicherzugriffsanforderung einbinden und dann die Speicherzugriffsanforderung an die LOD-Einheit 506 weiterleiten.
  • Die LOD-Einheit 506 ist ausgebildet, eine „Ebene an Detail bzw. einen Grad an Detail“ für die Texturdaten, die aus dem Speicher abzurufen sind, auf der Grundlage der Position und Orientierung einer Gruppe von Koordinaten zu berechnen, die in der Speicherzugriffsanforderung enthalten sind. Die Gruppe an Koordinaten kann die Position und die Orientierung einer Textur repräsentieren, die in einer Grafikszene liegt. Die LOD-Einheit 506 kann den berechneten Grad an Detail in die Speicherzugriffsanforderung einbinden und dann die Speicherzugriffsanforderung an die Adresseneinheit 508 weitergeben. Die Adresseneinheit 508 ist ausgebildet, diverse Adressenberechnungen auf der Grundlage der Koordinaten in der Speicherzugriffsanforderung auszuführen. Die Ergebnisse der Sprecherberechnungen können verwendet werden, um einen Eintrag in einer Markierungstabelle zu ermitteln, die in der Markierungseinheit 510 enthalten ist. Die Adresseneinheit 508 gibt die Speicherzugriffsanforderung und die Ergebnisse der Adressenberechnung an die Markierungseinheit 510 weiter.
  • Die Markierungseinheit 510 enthält eine Markierungstabelle, die eine Gruppe aus Einträgen enthält. Jeder Eintrag repräsentiert eine Zeile in der Cache-Einheit 518. Die Cache-Einheit 518 repräsentiert einen Cache-Speicher, der in der Textureinheit 315 liegt, oder sie kann auch den L1-Cache-Speicher 320 repräsentieren, der in dem in 3C gezeigten SM 310 liegt, wobei auch andere Cache-Speichereinheiten möglich sind. Bei Empfang der Speicherzugriffsanforderung und der Ergebnisse der Adressenberechnung aus der Adresseneinheit 508 ermittelt die Markierungseinheit 510, ob die Markierungstabelle einen Eintrag enthält, der den abzurufenden Texturdaten entspricht. Die Markierungstabelle, die in der Markierungseinheit 510 enthalten ist, wird nachfolgend detaillierter in Verbindung mit 6 erläutert.
  • Wenn die Markierungstabelle einen Eintrag enthält, der den abzurufenden Texturdaten entspricht, tritt ein Cache-Treffer auf, und die Markierungseinheit 510 ermittelt, dass die abzurufenden Texturdaten in der Cache-Einheit 518 liegen. Die Markierungseinheit 510 ruft den Eintrag ab, indem die Markierungstabelle durchsucht wird, und ruft einen Offset innerhalb der Cache-Einheit 518 ab, in der die Texturdaten tatsächlich liegen. Dieser Eintrag kann eine u-Koordinate und eine v-Koordinate enthalten. Die Markierungseinheit 510 gibt den Offset an den FIFO 516 weiter, und die Cache-Einheit 518 kann dann die zwischengespeicherten Texturdaten für den SM 310 bereitstellen.
  • Wenn die Markierungstabelle keinen Eintrag enthält, der den abzurufenden Texturdaten entspricht, tritt ein Cache-Fehltreffer auf, und die Markierungseinheit 510 veranlasst die Fehltreffer-Verarbeitungseinheit 512, auf die angeforderten Texturdaten in dem globalen Speicher zuzugreifen. Die Fehltreffer-Verarbeitungseinheit 512 kann auf die angeforderten Texturdaten zugreifen, indem eine virtuelle Adresse auf der Grundlage von Daten berechnet wird, die in der Speicherzugriffsanforderung enthalten sind, indem eine Übersetzung von virtueller in physikalische Adresse ausgeführt wird und indem die angeforderten Daten aus einer physikalischen Stelle ausgelesen werden. In einer Ausführungsform liegt die Fehltreffer-Verarbeitungseinheit 512 in der in 3B gezeigten MMU 328. Die Fehltreffer-Verarbeitungseinheit 512 kann dann die Cache-Einheit 518 mit den Texturdaten, die aus dem globalen Speicher abgerufen wurden, anreichern und kann die Markierungstabelle in der Markierungseinheit 512 so aktualisieren, dass die neue zwischengespeicherten Texturdaten wiedergegeben werden. Die Texturdaten können dann für den SM 310 bereitgestellt werden.
  • Wie zuvor erwähnt ist, kann die Textur-Verarbeitungs-Pipeline 500 auch konfiguriert werden, um Zugriffsoperationen für allgemeine Daten zu verarbeiten, die nicht speziell mit Texturdaten verknüpft sind, etwa unter anderem Ladeoperationen für den globalen Speicher. Wenn die Textur-Verarbeitungs-Pipeline 500 eine Speicherzugriffsanforderung empfängt, die mit einer Zugriffsoperation für allgemeine Daten verknüpft ist, ermittelt die TEXIN-Einheit 502, dass die Speicherzugriffsanforderung mit Zugriffsoperationen für allgemeine Daten verknüpft ist, auf der Grundlage eines Zustandsindex, der in der Speicherzugriffsanforderung enthalten ist, d.h. durch Vergleichen des Zustandsindex mit dem Anforderungszustandsregister in gleicher Weise, wie dies zuvor beschrieben ist. Wie ferner beschrieben ist, kann die TEXIN-Einheit 502 die Speicherzugriffsanforderung modifizieren, so dass sie einen speziellen Grad an Zwischenspeicherung bzw. eine spezielle Ebene an Zwischenspeicherung für Daten wiedergibt, die mit der Zugriffsoperation für allgemeine Daten verknüpft ist.
  • Wenn die TEXIN-Einheit 502 ermittelt, dass die Speicherzugriffsanforderung mit einer Zugriffsoperation für allgemeine Daten verknüpft ist, dann konfiguriert die TEXIN-Einheit 502 die Textur-Verarbeitungs-Pipeline 500 entsprechend. Dabei kann die TEXIN-Einheit 502 die LOD-Einheit 506 veranlassen, die Speicherzugriffsanforderung direkt zu der Adresseneinheit 508 weiterzugeben (d.h. ohne Ausführung jeglicher Verarbeitungsoperationen mit der Speicherzugriffsanforderung). Die TEXIN-Einheit 502 kann ferner die Adresseneinheit 508 veranlassen, die Speicherzugriffsanforderung aus der LOD-Einheit 506 direkt zu der Markierungseinheit 510 weiterzuleiten (d. h. ohne die Ausführung von Verarbeitungsoperationen mit der Speicherzugriffsanforderung). Auf diese Weise kann die Speicherzugriffsanforderung wirksam die LOD-Einheit 506 und die Adresseneinheit 508 umgehen.
  • Die Markierungseinheit 510 empfängt die Speicherzugriffsanforderung und extrahiert eine virtuelle Adresse, die in der Speicherzugriffsanforderung enthalten ist. Die virtuelle Adresse entspricht allgemeinen Daten, die abzurufen sind, indem die Zugriffsoperation für allgemeine Daten, die mit der Speicherzugriffsanforderung verknüpft ist, ausgeführt wird. Die Markierungseinheit 510 ermittelt dann, ob die Markierungstabelle einen Eintrag enthält, der der extrahierten virtuellen Adresse entspricht. Die Markierungstabelle ist ausgebildet, Einträge zu speichern, die mit Texturdaten verknüpft sind, wie dies zuvor erläutert ist, sowie auch virtuelle Adressen, die mit allgemeinen Daten verknüpft sind. Wie zuvor erwähnt ist, ist die Markierungstabelle in der Markierungseinheit 510 nachfolgend in Verbindung mit 6 näher erläutert.
  • Wenn die Markierungstabelle einen Eintrag enthält, der der extrahierten virtuellen Adresse entspricht, tritt ein Cache-Treffer auf, und die abzurufenden allgemeinen Daten liegen in der Cache-Einheit 518. Die Markierungseinheit 510 extrahiert einen Offset aus der virtuellen Adresse und schiebt diesen Offset in den FIFO 516. Die Dateneinheit 514 kann diesen Offset dann aus dem FIFO 516 abrufen, wenn zuvor bestehende Offsets in dem FIFO 516 den FIFO 516 verlassen haben, und kann dann die angeforderten Daten aus der Cache-Einheit 518 auf der Grundlage des Offsets abrufen. Die Dateneinheit 514 kann dann die mit diesem Offset verknüpften Daten für den SM 310 bereitstellen.
  • Wenn die Markierungstabelle keinen Eintrag enthält, der der extrahierten virtuellen Adresse entspricht, dann tritt ein Cache-Fehltreffer auf, und die Markierungseinheit 510 veranlasst die Fehltreffer-Verarbeitungseinheit 512, die angeforderten allgemeinen Daten aus dem globalen Speicher abzurufen, d.h. durch Ausführen einer Übersetzung von virtueller in physikalische Adresse und durch Auslesen der angeforderten Daten aus einer physikalischen Speicherstelle. Die Fehltreffer-Verarbeitungseinheit 512 kann dann die Cache-Einheit 518 mit den abgerufenen allgemeinen Daten anreichern und kann die Markierungstabelle in der Markierungseinheit 512 so aktualisieren, dass sie die neue zwischengespeicherten allgemeinen Daten wiedergibt. Diese allgemeinen Daten können dann dem SM 310 zur Verfügung gestellt werden.
  • Durch Realisierung der Textur-Verarbeitungs-Pipeline 500 in der zuvor erläuterten Weise, kann die Textureinheit 315 ausgebildet sein, Zugriffsoperationen für Texturdaten sowie Zugriffsoperationen für allgemeine Daten über den gleichen Datenpfad vorzunehmen. Ferner kann die Software, die in der CPU 102 und/oder in dem Parallelverarbeitungssubsystem 112 ausgeführt wird, einschließlich des Treibers 103, ausgebildet sein, vereinfachte Speicherzugriffsbefehle zu enthalten, die die allgemeinen Datenzugriffsoperationen für einen Software-Entwickler zugänglich machen. Mit dieser Vorgehensweise ist der Software-Entwickler in der Lage, einen Programm-Code zu entwickeln, der allgemeine Speicherzugriffsoperationen enthält, die von dem SM 310 und der Textur-Verarbeitungs-Pipeline 500 abgearbeitet werden können. Ferner ist es für den Software-Entwickler nicht mehr erforderlich, einen Textur-orientierten Programm-Code mit aufzunehmen, um diese Speicherzugriffsoperationen zu realisieren.
  • 6 ist eine Konzeptansicht einer Markierungstabelle 600, die in Verbindung mit 5 erläutet ist, gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt, umfasst die Markierungstabelle 600 eine Reihe von Einträgen 602-1, 602-2, 602-3 und 602-N. Jeder Eintrag 602 enthält einen entsprechenden Zustandsindex 604. Die Eintrag 602-1 enthält den Zustandsindex 604-1, der Eintrag 602-2 enthält den Zustandsindex 604-2, der Eintrag 602-3 enthält den Zustandsindex 604-3 und der Eintrag 602-N enthält den Zustandsindex 604-N. Jeder Eintrag 602 entspricht einem Teil der Daten, die in der in 5 gezeigten Cache-Einheit 518 gespeichert sind. Der Teil der in der Cache-Einheit 518 gespeicherten Daten können Texturdaten oder generische bzw. allgemeine Daten sein.
  • Ein gegebener Eintrag 602, der Texturdaten entspricht, enthält eine u-Koordinate 606 sowie eine v-Koordinate 608. Wie gezeigt ist, entspricht der Eintrag 602-1 Texturdaten und enthält daher eine u-Koordinate 606-1 und eine v-Koordinate 608-1. In ähnlicher Weise entspricht der Eintrag 602-N Texturdaten und enthält daher eine u-Koordinate 606-N und eine v-Koordinate 608-N. Ein gegebener Eintrag 602, der den allgemeinen Daten entspricht, umfasst eine virtuelle Adresse 610, die mit diesen allgemeinen Daten verknüpft ist. Wie gezeigt ist, entspricht der Eintrag 602-2 allgemeinen Daten und enthält daher eine virtuelle Adresse 610-2, während der Eintrag 602-3 ebenfalls allgemeinen Daten entspricht und daher eine virtuelle Adresse 610-3 enthält.
  • Wenn die in 5 gezeigte Textur-Verarbeitungs-Pipeline 500 ausgebildet ist, Speicherzugriffsanforderungen zu verarbeiten, wie dies im Zusammenhang mit 5 erläutet ist, kann die Markierungseinheit 510 die Markierungstabelle 600 im Hinblick auf jede derartige Speicherzugriffsanforderung abfragen. Für eine gegebene Speicherzugriffsanforderung führt die Markierungseinheit 510 eine Abfrage der Markierungstabelle 600 aus, um zu ermitteln, ob in Verbindung mit dieser Speicherzugriffsanforderung abzurufende Daten in der Cache- Einheit 518 liegen oder ob sie aus dem globalen Speicher abgerufen werden sollten.
  • Wenn eine gegebene Speicherzugriffsanforderung eine Zugriffsoperation für Texturdaten repräsentiert, kann die Markierungseinheit 510 einen Eintrag 602 in der Markierungstabelle 600 ermitteln, der einen Cache-Treffer anzeigt. Die Markierungseinheit 510 kann dann eine Cache- Adresse für die abzurufenden Texturdaten aus diesem Eintrag extrahieren. Wenn eine gegebene Speicherzugriffsanforderung eine Zugriffsoperation für allgemeine Daten repräsentiert, dann kann die Markierungseinheit 510 ebenfalls einen Eintrag 602 in der Markierungstabelle 600 ermitteln, der einen Cache-Treffer bezeichnet. Die Markierungseinheit 510 kann dann eine Cache-Adresse für die abzurufenden Texturdaten aus diesem Eintrag extrahieren.
  • Mit der oben genannten Vorgehensweise können Texturdaten und allgemeine Daten in gleicher Weise in der Cache-Einheit 518 zwischengespeichert und mittels der Markierungstabelle 600 verwaltet werden. Es sei nun wieder auf 5 verwiesen; die Textur-Verarbeitungs-Pipeline 500 kann von der Textureinheit 315, die in 3B gezeigt ist, eingerichtet werden, wenn der SM 310 (der ebenfalls in 3B gezeigt ist) eine oder mehrere Stranggruppen ausführt. Eine gegebene Stranggruppe kann Zugriffsoperationen für Texturdaten oder Zugriffsoperationen für allgemeine Daten über die Techniken ausführen, die zuvor in Verbindung mit 5 beschrieben sind.
  • Wenn eine Speicherzugriffsanforderung, die eine Zugriffsoperation für allgemeine Daten repräsentiert, anstelle eines Strangs innerhalb einer gegebenen Stranggruppe verarbeitet wird, kann die Markierungseinheit 510 ermitteln, dass die von der Speicherzugriffsanforderung gekennzeichneten allgemeinen Daten nicht in der Cache-Einheit 518 liegen (das heißt es tritt ein Cache-Fehltreffer auf). In Reaktion darauf ist die Markierungseinheit 510 ausgebildet, die Fehltreffer-Verarbeitungseinheit 512 zu veranlassen, die globalen Daten abzurufen und diese Daten in der Cache-Einheit 518 zu speichern, wie dies zuvor erläutert ist. Durch die Zwischenspeicherung der Daten, die mit einem gegebenen Strang in der Stranggruppe verknüpft sind, kann die Markierungseinheit 510 andere Stränge innerhalb dieser Stranggruppe in die Lage versetzen, auf eine zwischengespeicherte Version der für den gegebenen Strang abgerufenen Daten zuzugreifen. Mit dieser Vorgehensweise kann die Markierungseinheit 510 Situationen vermeiden, in der jeder Strang in der Stranggruppe versucht, auf den gleichen Teil der Daten zu zugreifen, wodurch mehrere gleichzeitige Cache-Fehltreffer für den gleichen Teil an Daten hervorgerufen werden. Eine derartige Situation könnte dazu führen, dass die Fehltreffer-Verarbeitungseinheit 512 den gleichen Teil an Daten mehrere Male abruft (d.h. einmal für jeden Strang).
  • Wenn ferner allgemeine Daten für eine gegebene Stranggruppe zwischengespeichert werden, ist die Markierungseinheit 510 ausgebildet, die Markierungstabelle 600 so zu aktualisieren, dass sie wiedergibt, dass die zwischengespeicherten Daten nur für die Dauer der Stranggruppe, für die die Daten abgerufen wurden, zwischengespeichert sind. Da allgemeine Daten, die für eine gegebene Stranggruppe zwischengespeichert sind, gegebenenfalls nicht vom nachfolgenden Stranggruppen benötigt werden, können die Daten als ungültig gekennzeichnet werden beim Verlassen der Stranggruppe, wodurch Cache-Ressourcen bewahrt werden. In einer Ausführungsform gibt der Zustandsindex 604, der mit einem gegebenen Eintrag in der Markierungstabelle 600 verknüpft ist, an, ob die mit diesem Eintrag verknüpften Daten für die Dauer der aktuellen Stranggruppe oder für mehr als eine Stranggruppe zwischenzuspeichern sind. In einer weiteren Ausführungsform aktualisiert die TEXIN-Einheit 502 die Speicherzugriffsanforderung auf der Grundlage des Zustandsindex, so dass eine Marke mit eingeschlossen ist, die eine Stufe bzw. einen Grad an Zwischenspeicherung für Daten angibt, die mit der Speicherzugriffsanforderung verknüpft sind, und die Markierungseinheit 510 nimmt diese Marke in einen Eintrag innerhalb der Markierungstabelle mit auf, der mit der Speicherzugriffsanforderung verknüpft ist.
  • Die Techniken, die zur Ausführung von Zugriffsoperationen für allgemeine Daten über die Textur-Pipeline 500 und zur Ungültigsetzung allgemeiner Daten beschrieben sind, die für die Dauer einer Stranggruppe zwischengespeichert sind, sind detaillierter nachfolgend in Verbindung mit 7 und 8 beschrieben.
  • 7 ist ein Flussdiagramm von Verfahrensschritten zur Ausführung einer Ladeoperation für den globalen Speicher über die in 5 gezeigte Textur-Verarbeitungs-Pipeline gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1, 2, 3A, 3B und 3C beschrieben sind, erkennt der Fachmann, dass ein beliebiges System, das zur Ausführung der Verfahrensschritte in beliebiger Reihenfolge geeignet ist, innerhalb des Schutzbereichs der Erfindungen liegt.
  • Wie gezeigt, beginnt ein Verfahren 700 im Schritt 702, in welchem die TEXIN-Einheit 502 in der Textur-Verarbeitungs-Pipeline 500 eine Speicherzugriffsanforderung aus dem SM 310 empfängt. Die Speicherzugriffsanforderung kann eine Zugriffsoperation für Texturdaten oder eine Zugriffsoperation für allgemeine Daten repräsentieren.
  • Im Schritt 704 ermittelt die TEXIN-Einheit 502, dass die Speicherzugriffsanforderung eine Zugriffsoperation für allgemeine Daten repräsentiert. In einer Ausführungsform extrahiert die TEXIN-Einheit 502 einen Zustandsindex aus der Speicherzugriffsanforderung und vergleicht einen Teil des Zustandsindex mit einem Anforderungsregister, um zu ermitteln, dass die Speicherzugriffsanforderung eine Zugriffsoperation für allgemeine Daten repräsentiert. Das Anforderungsregister speichert einen Zustandsindex, der Zugriffsoperationen für allgemeine Daten entspricht, und kann durch eine Softwareanwendung, die in den SM 310 ausgeführt wird, konfiguriert werden.
  • Im Schritt 706 konfiguriert die TEXIN-Einheit 502 die Textur-Verarbeitungs-Pipeline 500, um eine Datenzugriffsoperation für allgemeine Daten auszuführen. Dabei kann die TEXIN-Einheit 502 die LOD-Einheit 506 und die Adresseneinheit 508 veranlassen, eine empfangene Speicherzugriffsanforderung einfach an eine nachfolgende Einheit in der Textur-Verarbeitungs-Pipeline 500 weiterzugeben, ohne dass Verarbeitungsoperationen an dieser Speicherzugriffsanforderung ausgeführt werden. Auf diese Weise kann die TEXIN-Einheit 502 bewirken, dass die Speicherzugriffsanforderung die LOD-Einheit 506 und die Adresseneinheit 508 umgeht.
  • Im Schritt 708 extrahiert die Markierungseinheit 510 in der Textur-Verarbeitungs-Pipeline 500 eine virtuelle Adresse aus der Speicherzugriffsanforderung und ermittelt, ob die virtuelle Adresse in einer Markierungstabelle vorhanden ist. Die Markierungstabelle könnte beispielsweise die in 6 gezeigte Markierungstabelle 600 sein. Wenn die Markierungseinheit 510 ermittelt, dass die virtuelle Adresse in der Markierungstabelle vorhanden ist, tritt ein Cache-Treffer auf, und das Verfahren 700 geht weiter zum Schritt 710.
  • Im Schritt 710 veranlasst die Markierungseinheit 510 die Dateneinheit 514, die Daten, die mit der virtuellen Adresse verknüpft sind, aus der Cache-Einheit 518 abzurufen. Die Markierungseinheit 510 kann einen Offset, der mit der virtuellen Adresse verknüpft ist, in den FIFO 516 schieben, und die Dateneinheit 514 kann den Offset dann aus dem FIFO 516 abrufen, wenn zuvor bestehende Offset-Werte innerhalb des FIFO 516 den FIFO 516 verlassen haben. Die Dateneinheit 514 kann dann die angeforderten Daten aus der Cache- Einheit 518 auf der Grundlage dieses Offsets abrufen. Das Verfahren 700 geht dann weiter zum Schritt 714, in welchem die Dateneinheit 514 die zwischengespeicherten Daten dem SM 310 zur Verfügung stellt.
  • Wenn im Schritt 708 die Markierungseinheit 510 ermittelt, dass die virtuelle Adresse nicht in der Markierungstabelle vorhanden ist, tritt ein Cache-Fehltreffer auf, und das Verfahren 700 geht weiter zum Schritt 712. Im Schritt 712 ruft die Fehltreffer-Verarbeitungseinheit 512 die angeforderten Daten aus dem globalen Speicher ab. Dabei kann die Fehltreffer-Verarbeitungseinheit 514 eine Übersetzung von virtueller in physikalische Adresse vornehmen und dann auf die angeforderten Daten in einer physikalischen Speicherstelle zugreifen. Die Fehltreffer-Verarbeitungseinheit 514 ist ausgebildet, die angeforderten Daten in der Cache-Einheit 518 zwischenzuspeichern. Das Verfahren geht dann zum Schritt 714 weiter, in welchem die Dateneinheit 514 die neu zwischengespeicherten Daten für den SM 310 in ähnlicher Weise bereitstellt, wie dies zuvor beschrieben ist.
  • Durch die Umsetzung des Verfahrens 700 kann die Textureinheit 315 ausgebildet sein, die Textur-Verarbeitungs-Pipeline 500 zu realisieren, so dass diese Zugriffsoperationen für Texturdaten sowie Zugriffsoperationen für allgemeine Daten über den gleichen Datenpfad ausführt.
  • 8 ist ein Flussdiagramm von Verfahrensschritten zur Zwischenspeicherung und zur Ungültigsetzung von Daten, die mit einer Gruppe aus Strängen verknüpft sind, die in dem Datenstrom-Multiprozessor, der in 3B gezeigt ist, gemäß einer Ausführungsform der vorliegenden Erfindung ausgeführt werden. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1, 2, 3A, 3B und 3C beschrieben sind, erkennt der Fachmann, dass ein beliebiges System, das zur Ausführung der Verfahrensschritte in beliebiger Reihenfolge geeignet ist, innerhalb des Schutzbereichs der Erfindungen liegt.
  • Wie gezeigt, beginnt ein Verfahren 800 im Schritt 802, in welchem der SM 310 eine Gruppe an Strängen startet. Die Gruppe an Strängen kann Speicherzugriffsanforderungen erzeugen, die Zugriffsoperationen für Texturdaten oder Zugriffsoperationen für allgemeine Daten darstellen. Der SM 310 ist ausgebildet, die Textureinheit 315 zu veranlassen, diese Speicherzugriffsanforderungen abzuarbeiten. Dabei kann die Textureinheit 315 die in 5 gezeigte Textur-Verarbeitungs-Pipeline realisieren und kann das Verfahren 700 ausführen, das zuvor in Verbindung mit 7 beschrieben ist.
  • Im Schritt 804 ermittelt die Markierungseinheit 510 in der Textur-Verarbeitungs-Pipeline 500, dass eine Zugriffsoperation für allgemeine Daten, die von einem Strang in der Gruppe an Strängen erzeugt wurde, bewirkt, dass ein Cache-Fehltreffer auftritt. Die Zugriffsoperation für allgemeine Daten ist durch eine Speicherzugriffsoperation repräsentiert, die von der Textur-Verarbeitungs-Pipeline 500 aus dem Strang innerhalb der Gruppe an Strängen empfangen wird. Die Speicherzugriffsoperation enthält eine virtuelle Adresse, die den abzurufenden Daten entspricht. Die Markierungseinheit 510 ist ausgebildet zu ermitteln, dass ein Cache-Fehltreffer aufgetreten ist, indem ermittelt wird, dass die virtuelle Adresse nicht in einer Markierungstabelle, die in der Markierungseinheit 510 enthalten ist, vorhanden ist.
  • Im Schritt 806 veranlasst die Markierungseinheit 510 die Fehltreffer-Verarbeitungseinheit 512, Daten, die mit der Zugriffsoperation für allgemeine Daten verknüpft sind, aus dem globalen Speicher abzurufen. Dabei kann die Fehltreffer-Verarbeitungseinheit 512 die in der Speicherzugriffsanforderung enthaltene virtuelle Adresse in eine physikalische Adresse übersetzen. Die Fehltreffer-Verarbeitungseinheit 512 kann dann die angeforderten Daten aus einer physikalischen Speicherstelle auslesen, die zu dieser physikalischen Adresse gehört.
  • Im Schritt 808 weist die Markierungseinheit 510 eine Cache-Zeilen innerhalb der Cache-Einheit 518 zu, um die von der Fehltreffer-Verarbeitungseinheit 512 abgerufenen Daten zu speichern, und veranlasst dann, diese Daten in der zugewiesenen Cache-Zeile zu speichern. Im Schritt 810 kennzeichnet die Markierungseinheit 510 einen Eintrag in der Markierungstabelle, die in der Markierungseinheit 510 enthalten ist, im Hinblick auf die neu zwischengespeicherten Daten. Die Markierungstabelle könnte beispielsweise die in 6 gezeigte Markierungstabelle 600 sein. Der gekennzeichnete Eintrag gibt an, dass die neu zwischengespeicherten Daten nur für Dauer der Stranggruppe zwischengespeichert sind, die den Strang enthält, der für die Auslösung des Cache-Fehltreffers verantwortlich ist. In einer Ausführungsform gibt die Speicherzugriffsanforderung, die von dem Strang in der Stranggruppe erzeugt wurde, eine Ebene bzw. einen Grad der Zwischenspeicherung an, der mit den neu zwischengespeicherten Daten verknüpft ist, wozu unter anderem eine Verdrängungsstrategie gehört.
  • Das Verfahren 800 wartet im Schritt 812, bis alle Stränge in der Stranggruppe die Ausführung beendet haben. Wenn der letzte Strang oder eine Teilgruppe aus Strängen innerhalb der Stranggruppe beendet ist, geht das Verfahren 800 weiter zum Schritt 814, in welchem die Markierungseinheit 510 den Eintrag in der Cache-Einheit 518 ungültig gesetzt hat, der mit den Daten verknüpft ist, die für die Stranggruppe abgerufen wurden. Die für die Stranggruppe zwischengespeicherten allgemeinen Daten können dann aus der Cache-Einheit 518 entleert werden. Das Verfahren 800 endet dann.
  • Mit dieser Vorgehensweise können Daten, die abgerufen werden, wenn eine Zugriffsoperation für allgemeine Daten für Stränge innerhalb einer Stranggruppe verarbeitet wird, für die Dauer der Stranggruppe zwischengespeichert werden und können dann als ungültig bezeichnet werden, sobald die Stranggruppe beendet ist. Eine derartige Funktion kann verhindern, dass mehrere Cache-Fehltreffer, die von unterschiedlichen Strängen in der Stranggruppe hervorgerufen werden, auftreten und kann eine bessere Ausnutzung der Cache-Ressourcen ermöglichen.
  • Zusammengefasst gilt: eine Textur-Verarbeitungs-Pipeline kann ausgebildet sein, Speicherzugriffsanforderungen abzuarbeiten, die Zugriffsoperationen für Texturdaten oder Zugriffsoperationen für allgemeine Daten repräsentieren. Wenn die Textur-Verarbeitungs-Pipeline eine Speicherzugriffsanforderung empfängt, die eine Zugriffsoperation für Texturdaten repräsentiert, kann die Textur-Verarbeitungs-Pipeline Texturdaten auf der Grundlage von Texturkoordinaten abrufen. Wenn die Speicherzugriffsanforderung eine Zugriffsoperation für allgemeine Daten repräsentiert, dann extrahiert die Textur-Pipeline eine virtuelle Adresse aus der Speicherzugriffsanforderung und ruft dann Daten auf der Grundlage der virtuellen Adresse ab. Die Textur-Verarbeitungs-Pipeline ist ferner ausgebildet, allgemeine Daten, die für eine Gruppe an Strängen abgerufen wird, zwischenzuspeichern und dann diese allgemeinen Daten als ungültig zu kennzeichnen, wenn die Gruppe an Strängen beendet ist.
  • Vorteilhafterweise kann die Textur-Hardware innerhalb einer grafischen Verarbeitungseinheit (GPU) ausgebildet sein, Zugriffsoperationen für allgemeine Daten auszuführen. Diese Vorgehensweise ermöglicht es einem Software-Entwickler, einen Programm-Code zu erzeugen, der vorteilhaft die parallele Architektur der GPU ausnutzt, ohne dass es erforderlich ist, Textur-orientierte Speicherzugriffsoperationen zu realisieren. Ferner ist die Textur-Hardware in der Lage, allgemeine Daten, die für eine Gruppe an Strängen abgerufen werden, für die Dauer dieser Stranggruppen zwischenzuspeichern, wodurch die Cache-Ressourcen in der Textur-Hardware effizient genutzt werden.
  • Eine Ausführungsform der Erfindung kann als ein Programmprodukt zur Verwendung in einem Computersystem realisiert sein. Das bzw. die Programme des Programmprodukts definieren Funktionen der Ausführungsformen (einschließlich der hierin beschriebenen Verfahren) und können in einer Vielzahl von computerlesbaren Speichermedien enthalten sein. Zu anschaulichen computerlesbaren Speichermedien gehören, ohne einschränkend zu sein: (i) nicht-flüchtige beschreibbare Speichermedien (beispielsweise Nur-Lese-Speichereinrichtungen innerhalb eines Computers, etwa Kompaktdisketten-Nur-Lese-Speicher-(CD-ROM) Disketten, die mit einem CD-ROM-Laufwerk lesbar sind, Flash-Speicher, Nur-Lese-Speicher-(ROM) Chips oder andere Arten von nicht-flüchtigen Halbleiterspeichern), auf denen Information permanent gespeichert ist; und (ii) beschreibbare Speichermedien (beispielsweise Disketten in einem Diskettenlaufwerk oder einem Festplattenlaufwerk oder eine andere Art an Halbleiterspeicher mit wahlfreiem Zugriff), auf denen veränderbare Information gespeichert ist.

Claims (9)

  1. Ein computerimplementiertes Verfahren zur Ausführung einer Datenzugriffsoperation, wobei das Verfahren umfasst: Empfangen einer ersten Speicherzugriffsanforderung; Ermitteln, dass die erste Speicherzugriffsanforderung eine Zugriffsoperation für allgemeine Daten repräsentiert, die nicht speziell mit Texturdaten verknüpft sind; Konfigurieren einer Textur-Verarbeitungs-Pipeline (500), um Zugriffsoperationen für allgemeine Daten anstelle von Zugriffsoperationen für Texturdaten auszuführen, wobei das Konfigurieren der Textur-Verarbeitungs-Pipeline (500) umfasst: Konfigurieren einer Textur-orientierten Verarbeitungseinheit innerhalb der Textur-Verarbeitungs-Pipeline (500), um die erste Speicherzugriffsanforderung an eine nachfolgende Verarbeitungseinheit in der Textur-Verarbeitungs-Pipeline (500) weiterzuleiten, ohne Textur-bezogene Operationen mit der ersten Speicherzugriffsanforderung auszuführen; und Ausführen der Zugriffsoperation für allgemeine Daten durch Abrufen eines Teils von allgemeinen Daten aus einer Stelle, die aus der ersten Speicherzugriffsanforderung abgeleitet ist.
  2. Das computerimplementierte Verfahren nach Anspruch 1, wobei Ermitteln, dass die erste Speicherzugriffsanforderung die Zugriffsoperation für allgemeine Daten repräsentiert, umfasst: Extrahieren eines Zustandsindex aus der ersten Speicherzugriffsanforderung; und Ermitteln, dass ein Teil des Zustandsindex mit einem Wert übereinstimmt, der in einem Anforderungsregister gespeichert ist.
  3. Das computerimplementierte Verfahren nach Anspruch 2, wobei der Wert des Anforderungsregisters, das von einer Softwareanwendung, die in der Verarbeitungseinheit ausgeführt wird, konfiguriert wird.
  4. Das computerimplementierte Verfahren nach Anspruch 1, wobei Ausführen der Zugriffsoperation für allgemeine Daten umfasst: Ermitteln, dass eine virtuelle Adresse, die in der ersten Speicherzugriffsanforderung enthalten ist, in einem Eintrag vorhanden ist, der in einer Markierungstabelle (600) enthalten ist; Abrufen eines Offset aus einer Markierungstabelle (600) auf der Grundlage der virtuellen Adresse; und Abrufen des Teils an allgemeinen Daten aus einer Cache-Speichereinheit auf der Grundlage des Offset.
  5. Das computerimplementierte Verfahren nach Anspruch 1, wobei Ausführen der Zugriffsoperation für allgemeine Daten umfasst: Ermitteln, dass eine virtuelle Adresse, die in der ersten Speicherzugriffsanforderung enthalten ist, nicht in einem Eintrag vorhanden ist, der in einer Markierungstabelle (600) enthalten ist; Veranlassen, dass eine Fehltreffer-Verarbeitungseinheit (512) den Teil an allgemeinen Daten aus einer physikalischen Stelle abruft, die mit der physikalischen Adresse verknüpft ist, die aus der virtuellen Adresse abgeleitet ist.
  6. Das computerimplementierte Verfahren nach Anspruch 1, das ferner umfasst: Empfangen einer zweiten Speicherzugriffsanforderung; Ermitteln, dass die zweite Speicherzugriffsanforderung eine Zugriffsoperation für Texturdaten repräsentiert; Konfigurieren der Textur-Verarbeitungs-Pipeline (500) derart, dass sie Zugriffsoperationen für Texturdaten anstatt Zugriffsoperationen für allgemeine Daten ausführt; und Ausführen der Zugriffsoperation für Texturdaten durch Abrufen eines Teils von Texturdaten aus einer Stelle, die aus der zweiten Speicherzugriffsanforderung abgeleitet ist.
  7. Das computerimplementierte Verfahren nach Anspruch 1, wobei Konfigurieren der Textur-Verarbeitungs-Pipeline (500) zur Ausführung von Zugriffsoperationen für allgemeine Daten anstelle von Zugriffsoperationen für Texturdaten umfasst: Konfigurieren einer Markierungseinheit (510), um einen Offset, der mit einer Cache- Einheit (518) verknüpft ist, aus einer Markierungstabelle (600) auf der Grundlage einer virtuellen Adresse, die in einer Speicherzugriffsanforderung enthalten ist, anstatt einer u-Koordinate und einer v-Koordinate, die in einer Speicherzugriffsanforderung enthalten sind, zu extrahieren.
  8. Eine Recheneinrichtung, die ausgebildet ist, eine Datenzugriffsoperation auszuführen, mit: einer Verarbeitungseinheit, die ausgebildet ist, um: eine erste Speicherzugriffsanforderung zu empfangen; zu ermitteln, dass die erste Speicherzugriffsanforderung eine Zugriffsoperation für allgemeine Daten repräsentiert, die nicht speziell mit Texturdaten verknüpft sind; eine Textur-Verarbeitungs-Pipeline (500) zur Ausführung von Zugriffsoperationen für allgemeine Daten anstelle von Zugriffsoperationen für Texturdaten zu konfigurieren, wobei das Konfigurieren der Textur-Verarbeitungs-Pipeline (500) umfasst: Konfigurieren einer Textur-orientierten Verarbeitungseinheit innerhalb der Textur-Verarbeitungs-Pipeline (500), um die erste Speicherzugriffsanforderung an eine nachfolgende Verarbeitungseinheit in der Textur-Verarbeitungs-Pipeline (500) weiterzuleiten, ohne Textur-bezogene Operationen mit der ersten Speicherzugriffsanforderung auszuführen; und die Zugriffsoperation für allgemeine Daten auszuführen, indem ein Teil von allgemeinen Daten aus einer Stelle abgerufen wird, die aus der ersten Speicherzugriffsanforderung abgeleitet ist.
  9. Die Recheneinrichtung nach Anspruch 8, die ferner umfasst: eine Speichereinheit, die mit der Verarbeitungseinheit verbunden ist und Programmbefehle speichert, die, wenn sie von der Verarbeitungseinheit ausgeführt werden, die Verarbeitungseinheit veranlassen, um: die erste Speicherzugriffsanforderung zu empfangen; zu ermitteln, dass die erste Speicherzugriffsanforderung die Zugriffsoperation für allgemeine Daten repräsentiert; die Textur-Verarbeitungs-Pipeline (500) zu konfigurieren, Zugriffsoperationen für allgemeine Daten anstelle von Zugriffsoperationen für Texturdaten auszuführen, wobei das Konfigurieren der Textur-Verarbeitungs-Pipeline (500) umfasst: Konfigurieren einer Textur-orientierten Verarbeitungseinheit innerhalb der Textur-Verarbeitungs-Pipeline (500), um die erste Speicherzugriffsanforderung an eine nachfolgende Verarbeitungseinheit in der Textur-Verarbeitungs-Pipeline (500) weiterzuleiten, ohne Textur-bezogene Operationen mit der ersten Speicherzugriffsanforderung auszuführen; und die Zugriffsoperation für allgemeine Daten auszuführen.
DE102013020967.6A 2012-12-19 2013-12-11 Technik zur Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware Active DE102013020967B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/720,745 2012-12-19
US13/720,745 US9720858B2 (en) 2012-12-19 2012-12-19 Technique for performing memory access operations via texture hardware

Publications (2)

Publication Number Publication Date
DE102013020967A1 DE102013020967A1 (de) 2014-06-26
DE102013020967B4 true DE102013020967B4 (de) 2021-07-15

Family

ID=50878814

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102013020967.6A Active DE102013020967B4 (de) 2012-12-19 2013-12-11 Technik zur Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware

Country Status (4)

Country Link
US (1) US9720858B2 (de)
CN (1) CN103885903A (de)
DE (1) DE102013020967B4 (de)
TW (1) TWI525438B (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102072656B1 (ko) * 2013-07-16 2020-02-03 삼성전자 주식회사 캐시를 포함하는 테셀레이션 장치, 그의 동작 방법, 및 상기 장치를 포함하는 시스템
US9781225B1 (en) * 2014-12-09 2017-10-03 Parallel Machines Ltd. Systems and methods for cache streams
JP2018120449A (ja) * 2017-01-26 2018-08-02 ソニーセミコンダクタソリューションズ株式会社 演算処理装置および情報処理システム
US10403003B2 (en) * 2017-04-24 2019-09-03 Intel Corporation Compression mechanism
US11513686B2 (en) * 2020-05-05 2022-11-29 Nvidia Corporation Techniques for dynamically compressing memory regions having a uniform value
US11500692B2 (en) * 2020-09-15 2022-11-15 Apple Inc. Dynamic buffering control for compute work distribution
CN117093640B (zh) * 2023-10-18 2024-01-23 上海柯林布瑞信息技术有限公司 基于池化技术的数据抽取方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7002591B1 (en) 2000-08-23 2006-02-21 Nintendo Co., Ltd. Method and apparatus for interleaved processing of direct and indirect texture coordinates in a graphics system
US20070091089A1 (en) 2005-10-14 2007-04-26 Via Technologies, Inc. System and method for dynamically load balancing multiple shader stages in a shared pool of processing units

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5798762A (en) 1995-05-10 1998-08-25 Cagent Technologies, Inc. Controlling a real-time rendering engine using a list-based control mechanism
WO2000004482A2 (en) * 1998-07-17 2000-01-27 Intergraph Corporation Multi-processor graphics accelerator
US6851038B1 (en) 2000-05-26 2005-02-01 Koninklijke Philips Electronics N.V. Background fetching of translation lookaside buffer (TLB) entries
US6664958B1 (en) 2000-08-23 2003-12-16 Nintendo Co., Ltd. Z-texturing
US6885378B1 (en) 2000-09-28 2005-04-26 Intel Corporation Method and apparatus for the implementation of full-scene anti-aliasing supersampling
KR101099463B1 (ko) 2002-11-18 2011-12-28 에이알엠 리미티드 보안 도메인과 비보안 도메인을 갖는 시스템 내에서 가상메모리 어드레스의 물리적 메모리 어드레스로의 매핑
US6973557B2 (en) 2003-02-04 2005-12-06 Sun Microsystems, Inc. Apparatus and method for dual access to a banked and pipelined data cache memory unit
TWI221221B (en) 2003-02-27 2004-09-21 Via Tech Inc Address decoding method and related apparatus by comparing mutually exclusive bit-patterns of address
US7532537B2 (en) 2004-03-05 2009-05-12 Netlist, Inc. Memory module with a circuit providing load isolation and memory domain translation
US7538773B1 (en) * 2004-05-14 2009-05-26 Nvidia Corporation Method and system for implementing parameter clamping to a valid range in a raster stage of a graphics pipeline
US7290116B1 (en) 2004-06-30 2007-10-30 Sun Microsystems, Inc. Level 2 cache index hashing to avoid hot spots
US6972769B1 (en) 2004-09-02 2005-12-06 Nvidia Corporation Vertex texture cache returning hits out of order
CN1928918B (zh) * 2005-10-14 2012-10-10 威盛电子股份有限公司 图形处理装置及于图形处理装置中执行着色操作的方法
US7492368B1 (en) 2006-01-24 2009-02-17 Nvidia Corporation Apparatus, system, and method for coalescing parallel memory requests
US20080028181A1 (en) 2006-07-31 2008-01-31 Nvidia Corporation Dedicated mechanism for page mapping in a gpu
US7793038B2 (en) 2007-06-26 2010-09-07 International Business Machines Corporation System and method for programmable bank selection for banked memory subsystems
US8200939B2 (en) 2008-01-31 2012-06-12 Arm Norway As Memory management unit in a microprocessor system
US7945757B1 (en) 2008-02-13 2011-05-17 Nvidia Corporation Conserving and shaping address space with arrays
US8219778B2 (en) 2008-02-27 2012-07-10 Microchip Technology Incorporated Virtual memory interface
US8489801B2 (en) 2009-03-04 2013-07-16 Henry F. Huang Non-volatile memory with hybrid index tag array
TWI379195B (en) 2009-04-13 2012-12-11 Realtek Semiconductor Corp Method and device for accessing memory and central processing unit using the same
US8806144B2 (en) * 2009-05-12 2014-08-12 Stec, Inc. Flash storage device with read cache
US8799553B2 (en) 2010-04-13 2014-08-05 Apple Inc. Memory controller mapping on-the-fly
US8626989B2 (en) 2011-02-02 2014-01-07 Micron Technology, Inc. Control arrangements and methods for accessing block oriented nonvolatile memory

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7002591B1 (en) 2000-08-23 2006-02-21 Nintendo Co., Ltd. Method and apparatus for interleaved processing of direct and indirect texture coordinates in a graphics system
US20070091089A1 (en) 2005-10-14 2007-04-26 Via Technologies, Inc. System and method for dynamically load balancing multiple shader stages in a shared pool of processing units

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
GPU Gems 2: Chapter 32. Taking the Plunge into GPU Computing.</http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter32.html>In: <web.archive.org> am 25.04.2009(recherchiert am 19.11.2014) *

Also Published As

Publication number Publication date
US20140168245A1 (en) 2014-06-19
TWI525438B (zh) 2016-03-11
CN103885903A (zh) 2014-06-25
TW201439762A (zh) 2014-10-16
US9720858B2 (en) 2017-08-01
DE102013020967A1 (de) 2014-06-26

Similar Documents

Publication Publication Date Title
DE102013020967B4 (de) Technik zur Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware
DE102013017640B4 (de) Verteilte gekachelte Zwischenspeicherung
DE102009039231B4 (de) Einzeldurchgang-Kachelung
DE102013020968A1 (de) Technik zum Zugreifen auf einen inhaltsadressierbaren Speicher
DE102018132468A1 (de) Multi-gpu-frame-rendern
DE102013020485A1 (de) Technik zur Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware
DE102013017639B4 (de) Zwischenspeicherung von adaptiv dimensionierten Cache-Kacheln in einem vereinheitlichten L2-Cache-Speicher mit Oberflächenkomprimierung
DE102012222558B4 (de) Signalisieren, Ordnen und Ausführung von dynamisch erzeugten Aufgaben in einem Verarbeitungs-System
DE102012211670A1 (de) Simultanes Unterbreiten an eine Mehr-Produzenten-Queue mittels mehrerer Threads
DE102013018139A1 (de) Technik zur Speicherung gemeinsamer Vertices
DE102013017509A1 (de) Effiziente Speichervirtualisierung in mehrsträngigen Verarbeitungseinheiten
DE102012220267B4 (de) Rechenarbeitsverteilungs - Referenzzähler
DE102013208554A1 (de) Verfahren und System zum Managen verschachtelter Ausführungsströme
DE102013020613A1 (de) Umgehung der Pixel-Schattierung für die grafische Bilderzeugung mit geringer Leistung
DE102013017511A1 (de) Effiziente speichervirtualisierung in mehrsträngigen verarbeitungseinheiten
DE102013205886A1 (de) Dynamische Bankmodus-Adressierung für Speicherzugriff
DE102013017510A1 (de) Effiziente Speichervirtualisierung in mehrsträngigen Verarbeitungseinheiten
DE102013020614A1 (de) Mit Mehrfachauflösung konsistente Rastereinteilung
DE102013020966B4 (de) Leistungseffiziente Attribut-Handhabung für Parkettierungs- und Geometrie-Schattierungseinheiten
DE102013202173A1 (de) Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads
DE102013114072A1 (de) System und Verfahren zum Hardware-Scheduling von indexierten Barrieren
DE102013200997A1 (de) Ein blockierungsfreies FIFO
DE102013100179A1 (de) Verfahren und System zum Auflösen von Thread-Divergenzen
DE112010003750T5 (de) Hardware für parallele Befehlslistenerzeugung
DE102013020810A1 (de) Effiziente Super-Abtastung mit Schattierungs-Strängen pro Pixel

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R002 Refusal decision in examination/registration proceedings
R006 Appeal filed
R008 Case pending at federal patent court
R082 Change of representative

Representative=s name: KRAUS & WEISERT PATENTANWAELTE PARTGMBB, DE

R009 Remittal by federal patent court to dpma for new decision or registration
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final