DE102009046847A1 - Mehrklassen-Daten-Cache-Verfahren - Google Patents

Mehrklassen-Daten-Cache-Verfahren Download PDF

Info

Publication number
DE102009046847A1
DE102009046847A1 DE102009046847A DE102009046847A DE102009046847A1 DE 102009046847 A1 DE102009046847 A1 DE 102009046847A1 DE 102009046847 A DE102009046847 A DE 102009046847A DE 102009046847 A DE102009046847 A DE 102009046847A DE 102009046847 A1 DE102009046847 A1 DE 102009046847A1
Authority
DE
Germany
Prior art keywords
data
cache
cache line
entry
class
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.)
Withdrawn
Application number
DE102009046847A
Other languages
English (en)
Inventor
David B. Austin Glasco
Peter B. Holmqvist
George R. Lynch
Patrick R. Marchand
James Austin Roberts
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 DE102009046847A1 publication Critical patent/DE102009046847A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12—Replacement control
    • G06F12/121—Replacement control using replacement algorithms
    • G06F12/126—Replacement control using replacement algorithms with special data handling, e.g. priority of data or instructions, handling errors or pinning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12—Replacement control
    • G06F12/121—Replacement control using replacement algorithms
    • G06F12/128—Replacement control using replacement algorithms adapted to multidimensional cache systems, e.g. set-associative, multicache, multiset or multilevel
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

Eine Ausführungsform der Erfindung führt einen Mechanismus zum Ausweisen von Daten von einem Daten-Cache basierend auf der Datenklasse dieser Daten aus. Die Daten, welche in den Cache-Zeilen in dem Daten-Cache gespeichert sind, werden basierend auf den Datenklassen kategorisiert, welche das Wiederbenutzungspotential dieser Daten reflektieren. Die Datenklassen werden in einem Kennzeichenspeicher gespeichert, wo jedes Kennzeichen innerhalb des Kennzeichenspeichers einer einzelnen Cache-Zeile innerhalb des Daten-Caches entspricht. Beim Reservieren einer Cache-Zeile für die mit einem Befehl assoziierten Daten untersucht eine Kennzeichen-Nachschlageinheit die Datenklassen in dem Kennzeichenspeicher, um zu bestimmen, welche Daten auszuweisen sind. Daten, welche ein niedriges Wiederbenutzungspotential haben, werden mit einer höheren Priorität ausgewiesen als Daten, welche ein hohes Wiederbenutzungspotential haben. Vorteilhafterweise vermindert ein Ausweisen von Daten, welche zu einer Datenklasse gehören, welche ein geringeres Wiederbenutzungspotential hat, die Anzahl von Cache-Verlusten innerhalb des Systems.

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft im Allgemeinen das Gebiet von Speichermanagement und insbesondere Mehrklassen-Daten-Cache-Verfahren.
  • Beschreibung der betreffenden Technik
  • Ein Element in einem Speicheruntersystem innerhalb gewisser Verarbeitungseinheiten ist ein Level-2-Cache-Speicher (hierin bezeichnet als „L2-Cache”). Der L2-Cache ist ein großer Speicher auf dem Chip (on chip memory), welcher als ein intermediärer Punkt zwischen einem externen Speicher (z. B. Bildpufferspeicher (Framepufferspeicher) (frame buffer memory)) und internen Klienten (Client) des Speicheruntersystems (bezeichnet hierin als die „Klienten”) dient. Der L2-Cache speichert temporär Daten, welche durch verschiedene Klienten benutzt werden. Diese Daten können von einem externen Speicher (hierin bezeichnet als „DRAM”) abgerufen oder auf diesen geschrieben werden. Die Klienten können die Daten, welche in dem L2-Cache gespeichert sind, wieder benutzen, während sie gewisse Operationen durchführen.
  • Während einer Leseoperation mag ein Klient Daten von dem L2-Cache anfragen, welche momentan nicht in dem L2-Cache gespeichert sind, und daher aus dem DRAM abgerufen werden müssen. Eine Leseoperation, bei der die Daten von dem DRAM abgerufen werden müssen, wird in bedeutend mehr Taktzyklen verarbeitet als eine Leseoperation, bei der die Daten direkt von dem L2-Cache abgerufen werden. Somit mag eine Gesamtsystemperformanz schwerwiegend berührt sein, wenn Daten von dem DRAM für eine signifikante Anzahl von Leseoperationen abgerufen werden müssen. Da jedoch der durch den L2-Cache belegte Speicherplatz begrenzt ist, müssen die in dem L2-Cache befindlichen Daten routinemäßig ausgewiesen (evicted) werden, um Speicherplatz für zukünftige durch die Klienten übertragene Lese- oder Schreiboperationen frei zu machen. Wenn in dem L2-Cache befindliche Daten nicht häufig genug ausgewiesen werden, dann müssen zukünftige Lese- und Schreiboperationen ausgesetzt (stalled) werden, bis in dem L2-Cache Platz ist, um diese Operationen zu verarbeiten. Wiederum kann solch eine Dynamik eine Gesamtsystemperformanz signifikant beeinträchtigen.
  • Konventionelle Ausweisungsschemata implementieren normalerweise ein Verfahren, wobei die am wenigsten kürzlich benutzten Daten von dem Cache ausgewiesen werden. In gewissen Systemen jedoch, wo die Benutzungsmuster von Daten variieren, mag solch ein Zugang nicht die geeignete Balance zwischen einem schnellen Ausweisen von Daten, um Platz für zukünftige Lese- und Schreiboperationen zu machen, und einem Erlauben, dass Daten lange genug in dem Cache verbleiben, um wieder benutzt zu werden, so dass Anfragen an den externen Speicher vermieden werden können, treffen.
  • Was in der Technik gebraucht wird, ist, wie das Vorgehende illustriert, ein effizienterer Mechanismus zum Bestimmen, welche Daten als erstes von einem intermediären Cache, wie etwa einem L2-Cache, ausgewiesen werden sollten.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Eine Ausführungsform der vorliegenden Erfindung führt ein Verfahren zum Ausweisen von Daten von einem intermediären Cache aus, welcher mit einem oder mehr Klienten und mit einem externen Speicher gekoppelt ist. Das Verfahren umfasst die Schritte eines Empfangens eines Befehls von einem Klienten, welcher eine assoziierte Speicheradresse umfasst, eines Identifizierens von einer oder mehr Cache-Zeilen innerhalb des intermediären Caches, um basierend auf der Speicheradresse Daten zu speichern, welche mit dem Befehl assoziiert sind, eines Bestimmens, dass es einen Cache-Verlust bezüglich der einen oder mehr Cache-Zeilen gibt und des Bewirkens, dass zumindest ein Teil der Daten, welche sich in der einen oder mehr Cache-Zeilen befinden, ausgewiesen wird, oder des Anhaltens des Befehls, basierend auf einer oder mehr Ausweisungsklassen, welche mit den Daten assoziiert ist, welche sich in der einen oder mehr Cache-Zeilen befinden, wobei jede Ausweisungsklasse eine verschiedene Wahrscheinlichkeit reflektiert, dass Daten, welche mit der Ausweisungsklasse assoziiert sind, durch den Klienten oder einen verschiedenen Klienten wiederbenutzt werden.
  • Ein Vorteil des offenbarten Verfahrens ist, dass die Datenklasse, welche mit den Daten assoziiert ist, welche in dem Daten-Cache gespeichert sind, einer Kennzeichen-Nachschlageinheit (tag look-up unit) erlaubt, Daten auszuweisen, welche die geringste Wahrscheinlichkeit für Wiederbenutzung haben, wenn Platz für die Daten gemacht wird, welche mit dem hereinkommenden Lese- oder Schreibbefehl assoziiert sind. Dieser Mechanismus eines Ausweisens von Daten vermindert die Anzahl von Cache-Verlusten, welche aus der frühen Ausweisung von Daten resultieren, welche durch Klienten innerhalb des Systems benutzt werden mögen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Damit die Weise, in welcher die oben rezitierten Merkmale der vorliegenden Erfindung im Detail verstanden werden können, mag eine besondere Beschreibung der Erfindung, welche oben kurz zusammengefasst ist, mit Bezug auf Ausführungsformen gehabt sein, von denen einige in den angehängten Zeichnungen illustriert sind. Es ist jedoch zu bemerken, dass die angehängten Zeichnungen nur typische Ausführungsformen dieser Erfindung illustrieren und dass sie daher nicht zu betrachten sind, ihren Geltungsbereich zu beschränken, da die Erfindung andere genauso effektive Ausführungsformen einräumen mag.
  • 1 ist ein Blockdiagramm, welches ein Computersystem illustriert, welches konfiguriert ist, einen oder mehr Aspekte der vorliegenden Erfindung zu implementieren;
  • 2 ist ein Blockdiagramm eines Parallelverarbeitungsuntersystems für das Computersystem der 1, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3A ist ein Blockdiagramm eines GPC innerhalb einer der PPUs der 2, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3B ist ein Blockdiagramm einer Partitionseinheit innerhalb einer der PPUs der 2, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 4 ist ein detailliertes Blockdiagramm der Partitionseinheit der 3B, gemäß einer Ausführungsform der vorliegenden Erfindung; und
  • 5A–5D führen ein Flussdiagramm von Verfahrensschritten zum Handhaben des Flusses von Daten in den Daten-Cache der 4 herein und heraus aus, gemäß einer Ausführungsform der vorliegenden Erfindung.
  • DETAILLIERTE BESCHREIBUNG
  • In der folgenden Beschreibung werden zahlreiche spezifische Details ausgeführt, um ein durchgehenderes Verständnis der vorliegenden Erfindung bereitzustellen. Es wird jedoch für einen Fachmann in der Technik ersichtlich sein, dass die vorliegende Erfindung ohne eines oder mehr dieser spezifischen Details praktiziert werden mag. In anderen Fällen sind wohl bekannte Merkmale nicht beschrieben worden, um die vorliegende Erfindung nicht zu verschleiern.
  • Systemüberblick
  • 1 ist ein Blockdiagramm, welches ein Computersystem 100 illustriert, welches konfiguriert ist, einen oder mehr Aspekte der vorliegenden Erfindung zu implementieren. Computersystem 100 umfasst eine Zentralverarbeitungseinheit (CPU) 102 und einen Systemspeicher 104, welche über einen Buspfad durch eine Speicherbrücke 105 kommunizieren. Speicherbrücke 105 mag in CPU 102 integriert sein, wie in 1 gezeigt. Alternativ kann Speicherbrücke 105 ein konventionelles Gerät, z. B. ein Northbridge-Chip, sein, welches über einen Bus mit CPU 102 verbunden ist. Speicherbrücke 105 ist über Kommunikationspfad 106 (z. B. ein HyperTransport-Link) mit einer I/O-(Eingabe/Ausgabe)-Brücke 107 verbunden. I/O-Brücke 107, welche z. B. ein Southbridge-Chip sein kann, empfängt Benutzereingabe von einem oder mehr Benutzereingabegeräten 108 (z. B. Tastatur, Mouse) und leitet die Eingabe an CPU 102 über Pfad 106 und Speicherbrücke 105 weiter. Ein Parallelverarbeitungsuntersystem 112 ist mit Speicherbrücke 105 über einen Bus oder einen anderen Kommunikationspfad 113 (z. B. ein PCI-Express, Accelerated Graphics Port, oder HyperTransport Link) gekoppelt; in einer Ausführungsform ist Parallelverarbeitungsuntersystem 112 ein Graphikuntersystem, welches Pixel an ein Anzeigegerät 110 (z. B. ein konventioneller CRT-Monitor oder LCD-basierter Monitor) liefert. Eine Systemdisk 114 ist auch mit I/O-Brücke 107 verbunden. Ein Schalter (switch) 116 stellt Verbindungen zwischen I/O-Brücke 107 und anderen Komponenten, wie etwa ein Netzwerkadapter 118 und verschiedene Hinzufügungskarten 120 und 121, bereit. Andere Komponenten (nicht explizit gezeigt), umfassend USB- oder andere Port-Verbindungen, CD- Laufwerke, DVD-Laufwerke, Filmaufzeichnungsgeräte, und dergleichen, mögen auch mit I/O-Brücke 107 verbunden sein. Kommunikationspfade, welche die verschiedenen Komponenten in 1 miteinander verbinden, mögen unter Benutzung irgendwelcher geeigneten Protokolle implementiert sein, wie etwa PCI (Peripheral Component Interconnect), PCI-Express (PCI-E), AGP (Accelerated Graphics Port), HyperTransport, oder ein irgendein anderes Busprotokoll oder Punkt-zu-Punkt-Kommunikationsprotokoll(e), und Verbindungen zwischen verschiedenen Geräten können verschiedene Protokolle benutzen, wie in der Technik bekannt.
  • In einer Ausführungsform inkorporiert das Parallelverarbeitungsuntersystem 112 Schaltung, welche für Graphikverarbeitung und Videoverarbeitung optimiert ist, umfassend z. B. Videoausgabeschaltung, und bildet eine Graphikverarbeitungseinheit (GPU). In einer anderen Ausführungsform inkorporiert das Parallelverarbeitungsuntersystem 112 Schaltung, welche für Allzweckverarbeitung optimiert ist, während die darunter liegende Rechnerarchitektur beibehalten ist, welche in größerem Detail hierin beschrieben ist. In noch einer anderen Ausführungsform mag das Parallelverarbeitungsuntersystem 112 mit einem oder mehr anderen Systemelementen integriert sein, wie etwa Speicherbrücke 105, CPU 102, und I/O-Brücke 107, um ein System auf dem Chip zu bilden (system on chip) (SoC).
  • Es wird geschätzt werden, dass das hierin gezeigte System illustrativ ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, umfassend die Anzahl und die Anordnung von Brücken, mag wie gewünscht modifiziert sein. Zum Beispiel ist in anderen Ausführungsformen Systemspeicher 104 direkt mit CPU 102 verbunden, anstatt durch eine Brücke, und andere Geräte kommunizieren mit Systemspeicher 104 über Speicherbrücke 105 und CPU 102. In anderen alternativen Topologien ist Parallelverarbeitungsuntersystem 112 mit I/O-Brücke 107 oder direkt mit CPU 102 verbunden, anstatt mit Speicherbrücke 105. In noch anderen Ausführungsformen mag eine oder mehr von CPU 102, I/O-Brücke 107, Parallelverarbeitungsuntersystem 112 und Speicherbrücke 105 in einen oder mehr Chips integriert sein. Die hierin gezeigten bestimmten Komponenten sind optional; z. B. mag irgendeine Anzahl von Hinzufügungskarten (add-in cards) oder peripheren Geräten unterstützt sein. In einigen Ausführungsformen ist Schalter 116 eliminiert und Netzwerkadapter 118 und Hinzufügungskarten 120, 121 verbinden direkt mit I/O-Brücke 107.
  • 2 illustriert ein Parallelverarbeitungsuntersystem 112 gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt, umfasst Parallelverarbeitungssubsystem 112 eine oder mehr Parallelverarbeitungseinheiten (PPUs) 202, von denen jede mit einem lokalen Parallelverarbeitungs-(PP)-Speicher 204 gekoppelt ist. Im Allgemeinen umfasst ein Parallelverarbeitungsuntersystem eine Anzahl U von PPUs, wobei U ≥ 1. (Hierin werden viele Instanzen von ähnlichen Objekten mit Bezugsnummern bezeichnet, welche das Objekt identifizieren, und mit Nummern in Klammern, welche die Instanz identifizieren, wo benötigt). PPUs 202 und Parallelverarbeitungsspeicher 204 mögen unter Benutzung von einem oder mehr integrierte-Schaltung-Geräten implementiert sein, wie etwa programmierbare Prozessoren, anwendungsspezifische integrierte Schaltkreise (ASICs), oder Speichergeräte, oder in irgendeiner anderen technisch denkbaren Weise.
  • Mit Bezug wieder auf 1 sind in einigen Ausführungsformen einige oder alle von PPUs 202 in Parallelverarbeitungsuntersystem 112 Graphikprozessoren mit Rendering-Kanälen (rendering pipelines), welche konfiguriert sein können, um verschiedene Aufgaben durchzuführen, welche sich beziehen auf Erzeugen von Pixeldaten von Graphikdaten, welche durch CPU 102 und/oder Systemspeicher 104 zugeführt sind, Interagieren mit lokalem Parallelverarbeitungsspeicher 204 (welche als ein Graphikspeicher benutzt werden kann, umfassend z. B. einen konventionellen Bildpuffer, frame buffer), um Pixeldaten zu speichern und zu aktualisieren, Liefern von Pixeldaten an Anzeigegerät 110, und dergleichen. In einigen Ausführungsformen mag Parallelverarbeitungsuntersystem 112 eine oder mehr PPUs 202 umfassen, welche als Graphikprozessoren arbeiten, und eine oder mehr andere PPUs 202, welche für allgemeine Rechenzwecke benutzt werden. Die PPUs mögen identisch oder verschieden sein, und jede PPU mag ihr eigenes dediziertes Parallelverarbeitungsspeichergerät oder -geräte oder kein dediziertes Parallelverarbeitungsspeichergerät oder -geräte haben. Eine oder mehr PPUs 202 mögen Daten an Anzeigegerät 110 ausgeben oder jede PPU 202 mag Daten an ein oder mehr Anzeigegeräte 110 ausgeben.
  • Im Betrieb ist CPU 102 der Hauptprozessor von Computersystem 100, welcher Operationen von anderen Systemkomponenten steuert und koordiniert. Insbesondere erstellt CPU 102 Befehle, welche die Operation von PPUs 202 steuern. In einigen Ausführungsformen schreibt CPU 102 einen Strom von Befehlen für jede PPU 202 auf einen Befehlspuffer (weder in 1 noch in 2 explizit gezeigt), welcher in Systemspeicher 104, Parallelverarbeitungsspeicher 204, oder in einer anderen Speicherstelle gelegen sein mag, welcher bzw. welche sowohl CPU 102 als auch PPU 202 zugänglich ist bzw. sind. PPU 202 liest den Befehlsstrom von dem Befehlspuffer und führt dann asynchron bezogen auf den Betrieb von CPU 102 Befehle aus. CPU 102 mag auch Datenpuffer erzeugen, welche PPUs 202 in Antwort auf Befehle in dem Befehlspuffer lesen mag. Jeder Befehls- und Datenpuffer mag mittels jeder von PPUs 202 gelesen werden.
  • Mit Bezug nun zurück auf 2 umfasst jede PPU 202 eine I/O-(Eingabe/Ausgabe)-Einheit 205, welche mit dem Rest von Computersystem 100 über Kommunikationspfad 113 kommuniziert, welcher mit Speicherbrücke 105 verbindet (oder, in einer alternativen Ausführungsform, direkt mit CPU 102). Die Verbindung von PPU 202 mit dem Rest von Computersystem 100 mag auch variiert sein. In einigen Ausführungsformen ist Parallelverarbeitungsuntersystem 112 als eine Hinzufügungskarte implementiert, welche in einen Erweiterungsschacht (expansion slot) von Computersystem 100 eingefügt werden kann. In anderen Ausführungsformen kann eine PPU 202 auf einem einzelnen Chip mit einer Busbrücke integriert sein, wie etwa Speicherbrücke 105 oder I/O-Brücke 107. In noch anderen Ausführungsformen mögen einige oder alle Elemente von PPU 202 auf einem einzigen Chip mit CPU 102 integriert sein.
  • In einer Ausführungsform ist Kommunikationspfad 113 ein PCI-E-Link, in welchem dedizierte Wege (lanes) an jede PPU 202 (allocated to) vergeben sind, wie in der Technik bekannt ist. Andere Kommunikationspfade mögen auch benutzt werden. Eine I/O-Einheit 205 erzeugt Pakete (oder andere Signale) für Übertragung auf Kommunikationspfad 113 und empfängt auch alle hereinkommenden Pakete (oder andere Signale) von Kommunikationspfad 113, wobei sie die hereinkommenden Pakete an geeignete Komponenten von PPU 202 richtet. Zum Beispiel mögen Befehle, welche sich auf Verarbeitungsaufgaben beziehen, an eine Host-Schnittstelle 206 gerichtet werden, während Befehle, welche sich auf Speicheroperationen beziehen (z. B. Lesen von oder Schreiben auf Parallelverarbeitungsspeicher 204) an Speicher-Crossbar-Einheit 210 gerichtet werden mögen. Host-Schnittstelle 206 liest jeden Befehlspuffer und gibt die durch den Befehlspuffer spezifizierte Arbeit an ein Frontend 212 aus.
  • Jede PPU 202 implementiert in vorteilhafter Weise eine hochgradig parallele Verarbeitungsarchitektur. Wie im Detail gezeigt, umfasst PPU 202(0) ein Verarbeitungsclusterfeld 230, welches eine Anzahl C von generellen Verarbeitungsclustern (GPCs) 208 umfasst, wobei C ≥ 1. Jeder GPC 208 ist in der Lage, eine große Anzahl (z. B. Hunderte oder Tausende) von Threads simultan auszuführen, wobei jeder Thread eine Instanz eines Programms ist. In verschiedenen Anwendungen mögen verschiedene GPCs 208 für Verarbeitung von verschiedenen Typen von Programmen oder zum Durchführen von verschiedenen Typen von Rechnungen eingeteilt sein. Zum Beispiel mag in einer Graphikanwendung ein erster Satz von GPCs 208 eingeteilt sein, Mosaikoperationen (tessellation operations) durchzuführen und primitive Topologien für Füllstücke (patches) zu erzeugen, und ein zweiter Satz von GPCs 208 mag eingeteilt sein, Mosaikschattierung durchzuführen, um Patch-Parameter für die primitiven Topologien zu evaluieren und um Vertex-Positionen und andere Pro-Vertex-Attribute zu bestimmen. Die Einteilung der GPCs 208 mag abhängig von der Arbeitsbelastung variieren, welche für jeden Typ von Programm oder Rechnung auftritt. Alternativ mögen GPCs 208 eingeteilt sein, Verarbeitungsaufgaben unter Benutzung von einem Zeitschichtschema (time slice scheme) durchzuführen, um zwischen verschiedenen Verarbeitungsaufgaben umzuschalten.
  • GPCs 208 empfangen auszuführende Verarbeitungsaufgaben über eine Arbeitsverteilungseinheit 200, welche Verarbeitungsaufgaben definierende Befehle von Frontend-Einheit 212 empfängt. Verarbeitungsaufgaben umfassen Zeiger zu zu verarbeitenden Daten, z. B. Oberflächen(patch)-Daten, primitive Daten, Vertex-Daten, und/oder Pixeldaten, sowie Statusparameter und Befehle, welche definieren, wie die Daten zu verarbeiten sind (z. B. welches Programm auszuführen ist). Arbeitsverteilungseinheit 200 mag konfiguriert sein, den Verarbeitungsaufgaben entsprechende Zeiger zu holen, mag die Zeiger von Frontend 212 empfangen oder mag die Daten direkt von Frontend 212 empfangen. In einigen Ausführungsformen spezifizieren Indizes die Stelle der Daten in einem Feld. Frontend 212 stellt sicher, dass GPCs 208 in einem gültigen Zustand konfiguriert sind, bevor die durch die Befehlspuffer spezifizierte Verarbeitung initiiert wird.
  • Wenn PPU 202 z. B. für Graphikverarbeitung benutzt wird, wird die Verarbeitungsarbeitsbelastung für jeden Patch in ungefähr gleichgroße Aufgaben aufgeteilt, um Verteilung der Mosaikverarbeitung an viele GPCs 208 zu ermöglichen. Eine Arbeitsverteilungseinheit 200 mag konfiguriert sein, Aufgaben bei einer Frequenz auszugeben, welche befähigt ist, Aufgaben an viele GPCs 208 zur Verarbeitung bereitzustellen. In einigen Ausführungsformen der vorliegenden Erfindung sind Teile von GPCs 208 konfiguriert, verschiedene Typen von Verarbeitung durchzuführen. Zum Beispiel mag ein erster Teil konfiguriert sein, Vertex-Schattierung (vertex shading) und Topologieerzeugung durchzuführen, ein zweiter Teil mag konfiguriert sein, Mosaik- und Geometrieschattierung durchzuführen, und ein dritter Teil mag konfiguriert sein, Pixelschattierung in Schirm-Raum (screen space) durchzuführen, um ein gerendertes Bild zu erzeugen. Die Fähigkeit, Teile von GPCs 208 zum Durchführen von verschiedenen Typen von Verarbeitungsaufgaben einzuteilen, trägt effektiv irgendeiner Expansion und Kontraktion von Daten Rechnung, welche durch diese verschiedenen Typen von Verarbeitungsaufgaben erzeugt sind. Durch GPCs 208 erzeugte intermediäre Daten mögen gepullert sein, um zu erlauben, dass die intermediären Daten zwischen GPCs 208 mit minimalem Blockieren (stalling) übertragen werden, in Fällen, wo die Rate, mit welcher Daten durch eine stromabwärts-GPC 208 akzeptiert werden, der Rate nachhängt, bei welcher Daten mittels einer stromaufwärts-GPC 208 erzeugt werden.
  • Speicherschnittstelle 214 mag in einer Anzahl D von Speicherpartitionseinheiten partitioniert sein, welche jeweils mit einem Teil von Parallelverarbeitungsspeicher 204 gekoppelt sind, wobei D ≥ 1. Jeder Teil von Parallelverarbeitungsspeicher 204 umfasst im Allgemeinen ein oder mehr Speichergeräte (z. B. DRAM 220). Fachleute in der Technik werden schätzen, dass DRAM 220 durch andere geeignete Speichergeräte ersetzt werden können, und können von einem im Allgemeinen konventionellen Design sein. Eine detaillierte Beschreibung wird daher ausgelassen. Renderziele (render targets), wie etwa Bildpuffer oder Texturkarten (texture maps) mögen über DRAMs 220 hinweg gespeichert sein, was Partitionseinheit 215 erlaubt, Teile von jedem Renderziel parallel zu schreiben, um effektiv die verfügbare Bandbreite des Parallelverarbeitungsspeichers 204 zu nutzen.
  • Irgendeine der GPCs 208 mag Daten verarbeiten, welche zu irgendeiner der Partitionseinheiten 215 innerhalb von Parallelverarbeitungsspeicher 204 zu schreiben sind. Crossbar-Einheit 210 ist konfiguriert, die Ausgabe jeder GPC 208 zu der Eingabe von irgendeiner Partitionseinheit 214 oder zu einer anderen GPC 208 für weitere Verarbeitung zu leiten. GPCs 208 kommunizieren mit Speicherschnittstelle 214 durch Crossbar-Einheit 210, um von verschiedenen externen Speichergeräten zu lesen oder zu diesen zu schreiben. In einer Ausführungsform hat Crossbar-Einheit 210 eine Verbindung zu Speicherschnittstelle 214, um mit I/O-Einheit 205 zu kommunizieren, sowie eine Verbindung zu lokalem Parallelverarbeitungsspeicher 204, wodurch den Verarbeitungskernen innerhalb der verschiedenen GPCs 208 ermöglicht ist, mit Systemspeicher 104 oder anderem Speicher zu kommunizieren, welcher nicht lokal zu PPU 202 ist. Crossbar-Einheit 210 mag virtuelle Kanäle benutzen, um Verkehrsströme zwischen den GPCs 208 und Partitionseinheiten 215 zu separieren.
  • Wiederum können GPCs 208 programmiert sein, um Verarbeitungsaufgaben auszuführen, welche sich auf eine große Verschiedenheit von Anwendungen beziehen, umfassend, aber nicht darauf beschränkt, lineare und nicht lineare Datentransformationen, Filtern von Video- und/oder Audiodaten, Modellierungsoperationen (z. B. Anwenden von physikalischen Gesetzen, um Position, Geschwindigkeit und andere Attribute von Objekten zu bestimmen), Bildrenderoperationen (image rendering operations) (z. B. Mosaikschattierung, Vertex-Schattierung, Geometrie-Schattierung und/oder Pixel-Schattierungsprogramme), usw. PPUs 202 mögen Daten von Systemspeicher 104 und/oder von lokalen Parallelprozessierungsspeichern 204 in internen (on chip) Speicher übertragen, mögen die Daten verarbeiten, und mögen Ergebnisdaten zurück zu Systemspeicher 104 und/oder lokalen Parallelprozessierungsspeichern 204 zurückschreiben, wo auf solche Daten durch andere Systemkomponenten zugegriffen werden kann, umfassend CPU 102 oder ein anderes Parallelverarbeitungsuntersystem 112.
  • Eine PPU 202 mag mit irgendeiner Größe von lokalem Parallelverarbeitungsspeicher 204 ausgestattet sein, umfassend nicht lokalen Speicher, und mag lokalen Speicher und Systemspeicher in irgendeiner Kombination benutzen. Zum Beispiel kann eine PPU 202 ein Graphikprozessor in einer unifizierte-Speicherarchitektur-(UMA)-Ausführungsform sein. In solchen Ausführungsformen würde wenig oder kein dedizierter Graphik(Parallelverarbeitungs)-Speicher bereitgestellt sein und PPU 202 würde exklusiv oder beinahe exklusiv Systemspeicher benutzen. In UMA-Ausführungsformen mag eine PPU 202 in einen Brückenchip (bridge chip) oder Prozessorchip integriert sein oder mag als ein diskreter Chip mit einem Hochgeschwindigkeits-Link (high speed link) (z. B. PCI-E) bereitgestellt sein, welcher die PPU 202 mit Systemspeicher über einen Brückenchip oder ein anderes Kommunikationsmittel verbindet.
  • Wie oben bemerkt, kann irgendeine Anzahl von PPUs 202 in einem Parallelverarbeitungsuntersystem 112 umfasst sein. Zum Beispiel können viele PPUs 202 auf einer einzigen Hinzufügungskarte bereitgestellt sein oder viele Hinzufügungskarten können mit Kommunikationspfad 113 verbunden sein, oder eine oder mehr PPUs 202 können in einen Brückenchip integriert sein. PPUs 202 in einem Mehr-PPU-System mögen einander identisch sein oder mögen verschieden voneinander sein. Zum Beispiel mögen verschiedene PPUs 202 verschiedene Anzahlen von Verarbeitungskernen haben, verschiedene Größen von lokalem Parallelverarbeitungsspeicher, usw. Wo viele PPUs 202 vorhanden sind, mögen diese PPUs parallel betrieben sein, um Daten mit einem höheren Durchsatz zu prozessieren als mit einer einzelnen PPU 202 möglich ist. Systeme, welche eine oder mehr PPUs 202 inkorporieren, mögen in einer Verschiedenheit von Konfigurationen und Formfaktoren implementiert sein, umfassend Tischcomputer, Laptopcomputer oder handgetragene Personalcomputer, Server, Arbeitsstationen, Spielkonsolen, eingebettete Systeme, und dergleichen.
  • Verarbeitungsclusterfeldüberblick
  • 3A ist ein Blockdiagramm eines GPC 208 innerhalb einer der PPUs 202 der 2 gemäß einer Ausführungsform der vorliegenden Erfindung. Jeder GPC 208 mag konfiguriert sein, eine große Anzahl von Threads parallel auszuführen, wobei der Ausdruck „Thread” eine Instanz eines bestimmten Programms bezeichnet, welches auf einem bestimmten Satz von Eingabedaten ausführt. In einigen Ausführungsformen werden Einzelanweisungs-, Mehrdaten-(SIMD)-Anweisungserteilungstechniken benutzt, um parallele Ausführung einer großen Anzahl von Threads ohne Bereitstellen von vielen unabhängigen Anweisungseinheiten zu unterstützen. In anderen Ausführungsformen werden Einzelanweisungs-, Mehr-Thread-(SEMT)-Techniken benutzt, um parallele Ausführung einer großen Anzahl von im Allgemeinen synchronisierten Threads zu unterstützen, unter Benutzung einer gemeinsamen Anweisungseinheit, welche konfiguriert ist, Anweisungen für einen Satz von Verarbeitungsmaschinen innerhalb jeder der GPCs 208 zu erstellen. Im Unterschied zu einem SIMD-Ausführungsregime, wo alle Verarbeitungsmaschinen typischerweise identische Anweisungen ausführen, erlaubt SIMT-Ausführung, dass verschiedene Threads leichter divergenten Ausführungspfaden durch ein gegebenes Thread-Programm folgen. Fachleute in der Technik werden verstehen, dass ein SIMD-Verarbeitungsregime eine funktionale Untergruppe eines SIMT-Verarbeitungsregimes repräsentiert.
  • In Graphikanwendungen mag eine GPU 208 konfiguriert sein, um eine primitive Maschine zu implementieren zum Durchführen von Screen-Space-Graphics-Verarbeitungsfunktionen, welche umfassen mögen, aber nicht darauf beschränkt sind, primitiver Aufbau (primitive setup), Rasterung (rasterization) und z-Aussondern (z culling). Die primitive Maschine empfängt eine Verarbeitungsaufgabe von Arbeitsverteilungseinheit 200 und wenn die Verarbeitungsaufgabe die durch die primitive Maschine durchgeführten Operationen nicht erfordert, wird die Verarbeitungsaufgabe durch die primitive Maschine hindurch zu einem Pipeline-Manager 305 übergeben. Betrieb von GPC 208 wird vorteilhafterweise über einen Pipeline-Manager 305 gesteuert, welcher Verarbeitungsaufgaben an Streaming-Multiprozessoren (SPMs) 310 verteilt. Pipeline-Manager 305 mag auch konfiguriert sein, einen Arbeitsverteilungs-Crossbar 330 durch Spezifizieren von Bestimmungen für verarbeitete Daten, welche durch SPMs 310 ausgegeben sind, zu steuern.
  • In einer Ausführungsform umfasst jeder GPC 208 eine Anzahl M von SPMs 310, wobei M ≥ 1, ist jeder SPM 310 konfiguriert, eine oder mehr Thread-Gruppen zu verarbeiten. Auch umfasst jeder SPM 310 vorteilhafterweise einen identischen Satz von funktionalen Einheiten (z. B. arithmetische Logikeinheiten, etc.), welche hintereinander geschaltet (pipelined) sein mögen, was erlaubt, eine neue Anweisung zu erstellen, bevor eine vorherige Anweisung beendet worden ist, wie in der Technik bekannt ist. Irgendeine Kombination von funktionalen Einheiten mag bereitgestellt sein. In einer Ausführungsform unterstützen die funktionalen Einheiten eine Verschiedenheit von Operationen, umfassend Ganzzahlarithmetik und Gleitkommaarithmetik (z. B. Addition und Multiplikation), Vergleichsoperationen, Boolesche Operationen (AND, OR, XOR), Bitverschiebung (bit shifting), und Berechnung von verschiedenen algebraischen Funktionen (z. B. planare Interpolation, trigonometrische, exponentielle, und logarithmische Funktionen, etc.); und dieselbe funktionale-Einheit-Hardware kann eingesetzt werden, verschiedene Operationen durchzuführen.
  • Die Serie von Anweisungen, welche an einen bestimmten GPC 208 übermittelt sind, bildet einen Thread, wie vorher hierin definiert, und die Sammlung einer gewissen Anzahl von gleichzeitig ausführenden Threads über die Parallelverarbeitungsmaschinen (nicht gezeigt) innerhalb eines SPM 310 wird hierin als eine „Thread-Gruppe” bezeichnet. Wie hierin benutzt, bezieht sich eine „Thread-Gruppe” auf eine Gruppe von Threads, welche gleichzeitig dasselbe Programm auf verschiedenen Eingabedaten ausführen, wobei jeder Thread der Gruppe einer verschiedenen Verarbeitungsmaschine innerhalb eines SPM 310 zugewiesen ist. Eine Thread-Gruppe mag weniger Threads umfassen als die Anzahl von Verarbeitungsmaschinen innerhalb des SPM 310, in welchem Fall einige Verarbeitungsmaschinen während Zyklen untätig sein werden, wenn diese Thread-Gruppe gerade verarbeitet wird. Eine Thread-Gruppe mag auch mehr Threads umfassen als die Anzahl von Verarbeitungsmaschinen innerhalb des SPM 310, in welchem Fall Verarbeitung über mehrere Taktzyklen erfolgen wird. Da jeder SPM 310 bis zu G Thread-Gruppen gleichzeitig unterstützen kann, folgt, dass bis zu G × M Thread-Gruppen zu einer gegebenen Zeit in GPC 208 ausführen können.
  • Ein exklusiver lokaler Adressraum ist für jeden Thread verfügbar und ein pro-CTA geteilter Adressraum wird benutzt, um Daten zwischen Threads innerhalb eines CTA zu übergeben. In dem pro-Thread lokalen Adressraum und pro-CTA Adressraum gespeicherte Daten sind in L1-Cache 320 gespeichert und ein Ausweisungsverfahren mag benutzt werden, um Halten der Daten in L1-Cache 320 zu begünstigen. Jeder SPM 310 benutzt Raum in einem entsprechenden L1-Cache 320, welcher benutzt ist, um Lade- und Speicheroperationen durchzuführen. Jeder SPM 310 hat auch Zugriff auf L2-Caches innerhalb der Partitionseinheiten 215, welche unter allen GPCs 208 geteilt sind und benutzt werden mögen, um Daten zwischen Threads zu übertragen. Schließlich haben SPMs 310 auch Zugriff auf „globalen” Speicher außerhalb des Chips (off-chip), welcher z. B. Parallelverarbeitungsspeicher 204 und/oder Systemspeicher 104 umfassen kann. Ein L2-Cache mag benutzt werden, um Daten zu speichern, welche auf globalen Speicher geschrieben sind und von globalem Speicher gelesen sind. Es ist selbstverständlich, dass irgendein Speicher außerhalb von PPU 202 als globaler Speicher benutzt werden mag.
  • In Graphikanwendungen mag ein GPC 208 derart konfiguriert sein, dass jeder SPM 310 an eine Textureinheit 315 zum Durchführen von Texturzuordnungsoperationen (texture mapping operations) gekoppelt ist, z. B. Bestimmen von Texturabtastpositionen, Lesen von Texturdaten, und Filtern der Texturdaten. Texturdaten werden über Speicherschnittstelle 214 gelesen und von einem L2-Cache, von Parallelverarbeitungsspeicher 204, oder von Systemspeicher 104, wie benötigt, geholt. Textureinheit 315 mag konfiguriert sind, die Texturdaten in einem internen Cache zu speichern. In einigen Ausführungsformen ist Textureinheit 315 mit L1-Cache 320 gekoppelt und Texturdaten sind in L1-Cache 320 gespeichert. Jeder SPM 310 gibt verarbeitete Aufgaben an Arbeitsverteilungs-Crossbar 330 aus, um die verarbeitete Aufgabe an einen anderen GPC 208 für weitere Verarbeitung bereitzustellen oder um die verarbeitete Aufgabe in einem L2-Cache, Parallelverarbeitungsspeicher 204, oder Systemspeicher 104 über Crossbar-Einheit 210 zu speichern. Ein preROP (Vorrasterungsoperationen) 325 ist konfiguriert, Daten von SPM 310 zu empfangen, Daten an ROP-Einheiten innerhalb von Partitionseinheiten 215 zu richten, und Optimierungen für Farbmischung durchzuführen, Pixelfarbdaten zu organisieren, und Adressübersetzungen durchzuführen.
  • Es wird geschätzt werden, dass die hierin beschriebene Kernarchitektur illustrativ ist und dass Variationen und Modifikationen möglich sind. Irgendeine Anzahl von Verarbeitungsmaschinen, z. B. primitive Maschinen 304, SPMs 310, Textureinheiten 315, oder preROBs 325 mögen innerhalb eines GPC 208 umfasst sein. Während nur ein GPC 208 gezeigt ist, mag weiterhin eine PPU 202 irgendeine Anzahl von GPCs 208 umfassen, welche vorteilhafterweise funktionell ähnlich zueinander sind, so dass ein Ausführungsverhalten nicht davon abhängt, welcher GPC 208 eine bestimmte Verarbeitungsaufgabe empfängt. Weiterhin operiert jeder GPC 208 vorteilhafterweise unabhängig von anderen GPCs 208 unter Benutzung von separaten und distinkten Verarbeitungsmaschinen, L1-Caches 320 usw.
  • 3B ist ein Blockdiagramm einer Partitionseinheit 215 innerhalb einer der PPUs 202 der 2, gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt, umfasst Partitionseinheit 215 einen L2-Cache 350, einen Bildpuffer (frame buffer) (FB) 355 und eine Rasteroperationseinheit (ROP) 360. L2-Cache 350 ist ein Lese-/Schreib-Cache, welcher konfiguriert ist, Lade- und Speicheroperationen durchzuführen, welche von Crossbar-Einheit 210 und ROP 360 empfangen sind. Leseverluste (read misses) und dringende Rückschreibeanfragen (writeback requests) werden mittels L2-Cache 350 an FB 355 zur Verarbeitung ausgegeben. Unreine Aktualisierungen werden auch FB 355 für opportunistische Verarbeitung gesendet. FB 355 koppelt (interfaces) direkt an Parallelverarbeitungsspeicher 204 beim Ausgeben von Lese- und Schreibanfragen und Empfangen von Daten, welche von Parallelverarbeitungsspeicher 204 gelesen sind.
  • In Graphikanwendungen ist ROB 360 eine Verarbeitungseinheit, welche Rasteroperationen, wie etwa Schablonieren (stencil), z-Test, Angleichen (blending) und dergleichen durchführt, und gibt Pixeldaten als prozessierte Graphikdaten für Speicherung in Graphikspeicher aus. In einigen Ausführungsformen der vorliegenden Erfindung ist ROP 360 innerhalb jedes GPC 208 anstatt von Partitionseinheit 215 umfasst, und Pixellese- und -schreibanfragen werden über Crossbar-Einheit 210 anstatt von Pixelfragmentdaten übermittelt.
  • Die verarbeiteten Graphikdaten mögen auf Anzeigegerät 110 angezeigt werden oder mögen für weitere Verarbeitung mittels CPU 102 oder mittels einer der Verarbeitungsentitäten innerhalb von Paralielverarbeitungsuntersystem 112 weitergeleitet werden. Jede Partitionseinheit 215 umfasst einen ROP 360, um Verarbeitung von Rasteroperationen zu verteilen. In einigen Ausführungsformen mag ROP 360 konfiguriert sein, z-Daten oder Farbdaten zu komprimieren, welche auf Speicher geschrieben sind und z-Daten oder Farbdaten zu dekomprimieren, welche von Speicher gelesen sind.
  • Fachleute in der Technik werden verstehen, dass die in 1, 2, 3A und 3B beschriebene Architektur in keiner Weise den Geltungsbereich der vorliegenden Erfindung begrenzt und dass die hierin gelehrten Techniken auf irgendeiner richtig konfigurierten Verarbeitungseinheit implementiert werden mögen, umfassend, ohne Beschränkung, eine oder mehr CPUs, eine oder mehr Mehrkern-(multi-core)-CPUs, eine oder mehr PPUs 202, oder ein oder mehr GPCs 208, eine oder mehr Graphik- oder Spezialzweckverarbeitungseinheiten, oder dergleichen, ohne den Geltungsbereich der vorliegenden Erfindung zu verlassen.
  • Datenklasse-basierte Ausweisungsverfahren
  • 4 ist ein detailliertes Blockdiagramm der Partitionseinheit 215 von 3B, gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt, umfasst die Partitionseinheit 215 den L2-Cache 350, den FB 355 und die ROP 360. Der L2-Cache 350 umfasst eine L2-Cache-Scheibe (slice) 402. Wie in Verbindung mit 3B beschrieben, mag der L2-Cache 350 in zwei oder mehr Scheiben für effizientere Verarbeitung von Lese- und Schreibbefehlen geteilt sein. Die L2-Cache-Scheibe 402 ist eine solche Scheibe des L2-Cache 350. Die L2-Cache-Scheibe 402 umfasst einen Crossbar-Befehlspuffer 404, einen ROP-Befehlspuffer 406, einen Schiedsrichter (arbiter) 408, eine Kennzeichen-Nachschlageinheit (look-up unit) 410, einen Kennzeichenspeicher 412, einen Daten-Cache 414, einen Lese-Datenpuffer 416 und einen Schreib-Datenpuffer 418.
  • In Betrieb empfängt die L2-Cache-Scheibe 402 Lese- und Schreibbefehle von verschiedenen Klienten innerhalb des Parallelverarbeitungsuntersystems 112, wie etwa die GPCs 208 und die ROP 360. Von den GPCs 208 empfangene Lese- und Schreibbefehle werden über die Crossbar-Einheit 210 übermittelt. In dem Falle von Schreibbefehlen werden die mit dem Schreibbefehl assoziierten Daten auch an die L2-Cache-Scheibe 402 übermittelt.
  • Jeder mittels der L2-Cache-Scheibe 402 empfangene Lese- oder Schreibbefehl umfasst eine Speicheradresse, welche mit einem Satz von Cache-Zeilen innerhalb des Daten-Cache 414 assoziiert ist, wo die mit dem Lese- oder Schreibbefehl assoziierten Daten gespeichert werden mögen. In einer Ausführungsform ist der Daten-Cache 414 ein physikalisch indexierter und gekennzeichneter 64 KB-Satz-assoziativer-Daten-Cache. Der Daten-Cache 414 ist in vier Segmente unterteilt, wobei jedes Segment 32 Reihen hat und wobei jede Reihe 16 Cache-Zeilen von 32B hat. Eine Cache-Zeile ist eine physikalische Stelle innerhalb des Daten-Cache 414, wo mit Lese- und Schreibbefehlen assoziierte Daten gespeichert sind. Zu irgendeinem gegebenen Taktzyklus mag eine Cache-Zeile in dem Daten-Cache 414 leer sein, mag ansässige (resident) Daten umfassen, oder mag für einen Befehl reserviert sein, welcher im Gang ist. In einer Ausführungsform der vorliegenden Erfindung mögen aufgrund der Größe der mit einem Befehl assoziierten Daten mehrere Cache-Zeilen reserviert werden müssen, um die mit dem Befehl assoziierten Daten zu speichern. Die hierin beschriebenen Techniken können leicht auf Daten erweitert werden, welche in mehreren Cache-Zeilen gespeichert werden sollten.
  • Ein mittels der L2-Cache-Scheibe 402 empfangener Lese- oder Schreibbefehl umfasst auch die Datenklasse der Daten, welche mit dem empfangenen Befehl assoziiert sind. Die Datenklasse der Daten, welche mit einem Befehl assoziiert sind, wird mittels des Klienten bestimmt, welcher den bestimmten Befehl übermittelt, und reflektiert, wie im größeren Detail hierin beschrieben, das Wiederbenutzungspotential dieser Daten innerhalb des Parallelverarbeitungsuntersystems 112.
  • Der Crossbar-Befehlspuffer 404 ist mit der Crossbar-Einheit 210 gekoppelt und ist konfiguriert, Lese- und Schreibbefehle von verschiedenen GPCs 208 über die Crossbar-Einheit 210 zu empfangen. Der ROP-Befehlspuffer 406 ist mit der ROP 360 gekoppelt und ist konfiguriert, Lese- und Schreibbefehle von der ROP 360 zu empfangen. Der Crossbar-Befehlspuffer 404 und ROP-Befehlspuffer 406 sind FIFO-(erster Herein-erster-Heraus-(first-in-first-out))-Puffer, d. h. die durch die Befehlspuffer empfangenen Befehle werden in der Reihenfolge ausgegeben, in welcher die Befehle von der Crossbar-Einheit 210 oder der ROP 360 empfangen werden. Der Crossbar-Befehlspuffer 404 und der ROP-Befehlspuffer 406 sind auch an den Schiedsrichter 408 gekoppelt. Der Schiedsrichter 408 ist konfiguriert, Standard-Schiedsrichter-Techniken zu benutzen, um einen gegebenen Befehl von dem Crossbar-Befehlspuffer 404 oder dem ROP-Befehlspuffer 406 auszuwählen, und den ausgewählten Befehl an die Kennzeichen-Nachschlageinheit 410 zur Verarbeitung zu übermitteln.
  • Die Kennzeichen-Nachschlageinheit 410 ist konfiguriert, um zu bestimmen, ob für die mit einem Befehl, welcher von dem Schiedsrichter 408 empfangen ist, assoziierten Daten in dem Daten-Cache 414 eine Cache-Zeile verfügbar ist. Die Kennzeichen-Nachschlageinheit 410 ist auch konfiguriert, wo es möglich ist, Cache-Zeilen für Daten, welche mit einem neu empfangenen Lese- oder Schreibbefehl assoziiert sind, dadurch verfügbar zu machen, dass bewirkt ist, dass in dem Daten-Cache 414 befindliche Daten ausgewiesen werden. Sobald eine oder mehr Cache-Zeilen in dem Daten-Cache 414 für solche Daten verfügbar ist, ist die Kennzeichen-Nachschlageinheit 410 konfiguriert, eine identifizierte Cache-Zeile in dem Daten-Cache 414 für die mit dem Befehl assoziierten Daten zu reservieren.
  • Jede Cache-Zeile in dem Daten-Cache 414 hat einen entsprechenden Eintrag in dem Kennzeichenspeicher 412 und jeder Eintrag in dem Kennzeichenspeicher umfasst einen Statusteil und einen Kennzeichenteil. Der Statusteil eines Eintrags in dem Kennzeichenspeicher zeigt den bestimmten Status der Cache-Zeile an, welche diesem Eintrag entspricht. Der Statusteil eines Eintrags umfasst ein Gültig-Bit (valid bit), ein Unrein-Bit (dirty bit) und ein Verhaftet-Bit (pinned bit). Wenn gesetzt, zeigt das Gültig-Bit an, dass die diesem bestimmten Eintrag entsprechende Cache-Zeile gültige Daten speichert. Wenn gesetzt, zeigt das Unrein-Bit an, dass die dem bestimmten Eintrag entsprechende Cache-Zeile unreine Daten speichert. Wenn gesetzt, zeigt das Verhaftet-Bit an, dass die dem bestimmten Eintrag entsprechende Cache-Zeile verhaftete Daten speichert, d. h. Daten, welche momentan von dem L2-Cache 350 benutzt werden. Der Kennzeichenteil eines Eintrags umfasst die Datenklasse der Daten, welche innerhalb der Cache-Zeile gespeichert sind, welche mit diesem bestimmten Eintrag assoziiert ist. Wie vorher hierin angezeigt, ist die Cache-Semantik des L2-Cache 350 erweitert, um drei Datenklassen zu umfassen: Weise zuerst aus (evict_first), weise normal aus (evict_normal) und weise als letztes aus (evict_last). Innerhalb einer Cache-Zeile in dem Daten-Cache 414 gespeicherte Daten, welche zu der evict_first-Datenklasse gehören, haben typischerweise geringes oder kein Wiederverwendungspotential durch irgendeinen der Klienten, welche den L2-Cache 350 benutzen. Aufgrund der geringen Wahrscheinlichkeit von Wiederbenutzung können diese Daten schnell aus dem Daten-Cache 414 ausgewiesen werden, um Raum für andere Daten zu machen, ohne ein hohes Risiko nachfolgender Cache-Verluste zu bewirken. Innerhalb einer Cache-Zeile in dem Daten-Cache 414 gespeicherte Daten, welche zu der evict_normal-Datenklasse gehören, haben typischerweise ein gewisses Wiederverwendungspotential durch die Klienten, welche den L2-Cache 350 benutzen. Aufgrund des Wiederverwendungspotentials mögen diese Daten mit einer geringeren Priorität ausgewiesen werden als Daten, welche zu der evict_first-Datenklasse gehören, ohne eine signifikante Anzahl von nachfolgenden Cache-Verlusten zu bewirken. Innerhalb einer Cache-Zeile in dem Daten-Cache 414 gespeicherte Daten, welche zu der evict_last-Datenklasse gehören, haben typischerweise ein hohes Wiederverwendungspotential durch die Klienten, welche den L2-Cache 350 benutzen. Aufgrund der hohen Wahrscheinlichkeit einer Wiederbenutzung sollten diese Daten nicht aus dem Daten-Cache 414 ausgewiesen werden, um Raum für andere Daten zu machen, da dies zu einem hohen Risiko von nachfolgenden Datenverlusten führen würde. In anderen Ausführungsformen mag die L2-Cache 350 Semantik basierend auf den Anforderungen des Parallelverarbeitungsuntersystems 112 erweitert sein, andere Datenklassen zu umfassen.
  • In einer Cache-Zeile gespeicherte Daten werden auch als „rein” oder „unrein”, und „verhaftet” oder „unverhaftet” kategorisiert. Gespeicherte Daten gelten als rein, wenn die Daten kohärent mit den entsprechenden Daten in Parallelverarbeitungsspeicher 204 sind. Gespeicherte Daten gelten als unrein, wenn die Daten nicht kohärent mit den entsprechenden Daten in Parallelverarbeitungsspeicher 204 sind. Wie wohl bekannt ist, sollten unreine Daten gesäubert (cleaned) werden, bevor sie ausgewiesen werden. Unverhaftete Daten bilden in einer Datenzeile von Daten-Cache 414 gespeicherte Daten, welche momentan nicht benutzt werden. Verhaftete Daten bilden in einer Cache-Zeile des Daten-Cache 414 gespeicherte Daten, welche momentan durch den L2 benutzt werden. Da verhaftete Daten in Benutzung sind, sollten diese Daten nicht ausgewiesen werden. Das Gültig-Bit eines Eintrags in dem Kennzeichenspeicher 412, welcher mit einer Cache-Zeile in dem Daten-Cache 414 assoziiert ist, welcher ansässige Daten hat, ist gesetzt. Das Gültig-Bit eines Eintrages in dem Kennzeichenspeicher 412, welcher mit einer Cache-Zeile in dem Daten-Cache 414 assoziiert ist, welcher keine ansässigen Daten hat, ist gelöscht (cleared).
  • In dem Fall von Lesebefehlen ist der Lesedatenpuffer 416 konfiguriert, mit einem verarbeiteten Lesebefehl, welcher von dem Daten-Cache 414 empfangen ist, assoziierte Daten zu speichern, bis diese Daten zurück zu den CPGs 208, über die Crossbar-Einheit 210, oder die ROP 360, wie es der Fall sein mag, übermittelt sind. In dem Fall von Schreibbefehlen ist der Schreibdatenpuffer 418 konfiguriert, Daten zu speichern, welche mit einem Schreibbefehl assoziiert sind, welcher von den GPCs 208 über die Crossbar-Einheit 210, oder die ROP 360, wie es der Fall sein mag, empfangen ist, bis diese Daten zu einer entsprechenden reservierten Cache-Zeile in dem Daten-Cache 414 übermittelt sind.
  • Wie vorher hierin angezeigt, ist auf Empfangen eines Befehls von dem Schiedsrichter 408 hin die Kennzeichen-Nachschlageinheit 410 konfiguriert, einen Satz von Cache-Zeilen innerhalb des Daten-Cache 414 zu identifizieren, in welchem die mit dem empfangenen Befehl assoziierten Daten potentiell gespeichert werden mögen. Dieser Satz von Cache-Zeilen, hierin bezeichnet als die „identifizierten Cache-Zeilen”, ist basierend auf der Speicheradresse bestimmt, welche in dem Lese- oder Schreibbefehl umfasst ist, unter Benutzung von Standard-Satz-assoziative-Cache-Techniken (die Speicheradresse zeigt die tatsächliche Stelle innerhalb des Parallelverarbeitungsspeichers 204 an, von wo die Daten gelesen sind oder wohin die Daten schließlich geschrieben sind). In dem Fall eines Lesebefehls bestimmt die Kennzeichen-Nachschlageinheit 410 als nächstes, ob die mit dem Befehl assoziierten Daten momentan innerhalb einer der identifizierten Cache-Zeilen befindlich sind. Wenn dem so ist, was bedeutet, dass es einen Cache-Treffer (cache hit) gibt, führt dann die Kennzeichen-Nachschlageinheit 410 dazu, dass die angefragten Daten von dem Daten-Cache 414 zu dem Lesedatenpuffer 416 übermittelt werden, wo die Daten gespeichert werden, bis die Daten an den anfragenden Klienten zurückgegeben werden. In dem Falle eines Schreibbefehls bestimmt die Kennzeichen-Nachschlageinheit 410 zuerst, ob die mit dem Befehl assoziierten Daten über Daten geschrieben werden können, welche momentan innerhalb einer der identifizierten Cache-Zeilen befindlich sind. Wenn dem so ist, was wieder bedeutet, dass es einen Cache-Treffer gibt, führt dann die Kennzeichen-Nachschlageinheit 410 dazu, dass die mit dem Befehl assoziierten Daten, welche in dem Schreibdatenpuffer 418 gespeichert sind, auf die assoziierte Stelle des Daten-Cache 414 geschrieben werden.
  • In dem Fall eines Cache-Verlusts, was bedeutet, dass die mit dem Befehl assoziierten Daten nicht in (in dem Fall eines Lesebefehls) einer der identifizierten Cache-Zeilen befindlich sind oder nicht auf (in dem Fall eines Schreibbefehls) eine der identifizierten Cache-Zeilen geschrieben werden können, bestimmt dann die Kennzeichen-Nachschlageinheit 410, ob eine der identifizierten Cache-Zeilen leer ist. Wenn eine der identifizierten Cache-Zeilen leer ist, dann reserviert die Kennzeichen-Nachschlageinheit 410 die leere Cache-Zeile für die mit dem Lese- oder Schreibbefehl assoziierten Daten. Wenn keine der identifizierten Cache-Zeilen leer ist, dann implementiert die Kennzeichen-Nachschlageinheit 410 eine Serie von Cache-Ausweisungs-Verfahren basierend auf den Datenklassen der in den identifizierten Cache-Zeilen befindlichen Daten.
  • Die Kennzeichen-Nachschlageinheit 410 untersucht zuerst die Einträge in dem Kennzeichenspeicher 412, welcher mit jeder der identifizierten Cache-Zeilen assoziiert sind, um zu bestimmen, ob irgendwelche der Cache-Zeilen ansässige Daten haben, welche rein, unverhaftet und evict_first sind. Der Statusteil eines Eintrags in dem Kennzeichenspeicher 412, welcher mit irgendeiner Cache-Zeile assoziiert ist, welche ansässige Daten hat, welche rein, unverhaftet und evict_first sind, sollte ein gesetztes Gültig-Bit, ein gelöschtes Unrein-Bit und ein gelöschtes Verhaftet-Bit haben. Der Kennzeichenteil von solch einem Eintrag sollte anzeigen, dass die in der relevanten Cache-Zeile gespeicherten Daten zu der evict_first-Datenklasse gehören. Wenn irgend solche Cache-Zeilen existieren, dann führt die Kennzeichen-Nachschlageinheit 410 dazu, dass die am wenigstens kürzlich benutzten reinen, unverhafteten und evict_first-Daten von dem Daten-Cache 414 ausgewiesen werden. Nach Ausweisen der Daten reserviert die Kennzeichen-Nachschlageinheit 410 die resultierende leere Cache-Zeile für die mit dem Befehl assoziierten Daten.
  • Wenn keine der in den identifizierten Cache-Zeilen befindlichen Daten rein, unverhaftet und evict_first sind, dann untersucht die Kennzeichen-Nachschlageinheit 410 die Einträge in dem Kennzeichenspeicher 412, welcher mit jeder der identifizierten Cache-Zeilen assoziiert ist, um zu bestimmen, ob irgendeine der Cache-Zeilen ansässige Daten (Gültig-Bit ist gesetzt) hat, welche rein, unverhaftet und evict_normal sind. Der Statusteil eines Eintrags in dem Kennzeichenspeicher 412, welcher mit irgendeiner Cache-Zeile assoziiert ist, welche ansässige Daten hat, welche rein, unverhaftet und evict_normal sind, sollte ein gesetztes Gültig-Bit, ein gelöschtes Unrein-Bit und ein gelöschtes Verhaftet-Bit haben. Der Kennzeichenteil von solch einem Eintrag sollte anzeigen, dass die in der relevanten Cache-Zeile gespeicherten Daten zu der evict_normal-Datenklasse gehören. Wenn irgend solche Cache-Zeilen existieren, dann führt die Kennzeichen-Nachschlageinheit 410 dazu, dass die am wenigsten kürzlich benutzten reinen, unverhafteten und evict_normal-Daten von dem Daten-Cache 414 ausgewiesen werden. Nach Ausweisen der Daten reserviert die Kennzeichen-Nachschlageinheit 410 die resultierende leere Cache-Zeile für die mit dem Befehl assoziierten Daten.
  • Wenn keine der in den identifizierten Cache-Zeilen befindlichen Daten reine, unverhaftete und evict_first-Daten oder reine, unverhaftete und evict_normal-Daten sind, dann wird in einer Ausführungsform der Befehl angehalten, bis die in einer der identifizierten Cache-Zeilen befindlichen Daten aus dem Daten-Cache 414 ausgewiesen werden können.
  • Wenn in einer alternativen Ausführungsform keine der in den identifizierten Cache-Zeilen befindlichen Daten reine, unverhaftete und evict_first-Daten oder reine, unverhaftete und evict_normal-Daten sind, dann bestimmt die Kennzeichen-Nachschlageinheit 410, ob die mit dem Befehl assoziierten Daten zu der evict_last-Datenklasse gehören. Wenn die mit dem Befehl assoziierten Daten nicht zu der evict_last-Datenklasse gehören, dann wird der Befehl angehalten, bis die in einer der identifizierten Cache-Zeilen befindlichen Daten von dem Daten-Cache 414 ausgewiesen werden können. Wenn jedoch die mit dem Befehl assoziierten Daten zu der evict_last-Datenklasse gehören, dann untersucht die Kennzeichen-Nachschlageinheit 410 die Einträge in dem Kennzeichenspeicher 412, welcher mit jeder der identifizierten Cache-Zeilen assoziiert ist, um zu bestimmen, ob eine der Cache-Zeilen ansässige Daten hat, welche rein, unverhaftet und evict_last sind. Der Statusteil eines Eintrags in dem Kennzeichenspeicher 412, welcher mit irgendeiner Cache-Zeile assoziiert ist, welche ansässige Daten hat, welche rein, unverhaftet und evict_last sind, sollte ein gesetztes Gültig-Bit, ein gelöschtes Unrein-Bit und ein gelöschtes Verhaftet-Bit haben. Der Kennzeichenteil von solch einem Eintrag sollte anzeigen, dass die in der relevanten Cache-Zeile gespeicherten Daten zu der evict_last-Datenklasse gehören. Wenn in einer Ausführungsform irgend solche Cache-Zeilen existieren, dann führt die Kennzeichen-Nachschlageinheit 410 dazu, dass die am wenigsten kürzlich benutzten reinen, unverhafteten und evict_last-Daten von dem Daten-Cache 414 ausgewiesen werden. Nach Ausweisen der Daten reserviert die Kennzeichen-Nachschlageinheit 410 die resultierende leere Cache-Zeile für die mit dem Befehl assoziierten Daten.
  • Wenn in anderen Ausführungsformen zu der evict_last-Datenklasse gehörende Daten nicht von dem Daten-Cache 414 ausgewiesen werden können, dann reklassifiziert die Kennzeichen-Nachschlageinheit 410 die am wenigsten kürzlich benutzten reinen, unverhafteten und evict_last-Daten als reine, unverhaftete und evict_normal-Daten. Durch Ändern der Datenklasse der in der relevanten Cache-Zeile befindlichen Daten, ist dann die Kennzeichen-Nachschlageinheit 410 in der Lage, diese ansässigen Daten basierend auf den oben ausgeführten Cache-Ausweisungsverfahren auszuweisen. Die Kennzeichen-Nachschlageinheit 410 führt dann dazu, dass die am wenigsten kürzlich benutzten reinen, unverhafteten, evict_normal-Daten von dem Daten-Cache 414 ausgewiesen werden. Nach Ausweisen der evict_normal-Daten reserviert die Kennzeichen-Nachschlageinheit 410 die leere Cache-Zeile für die mit dem Befehl assoziierten Daten, wie vorher hierin beschrieben.
  • Um eine Cache-Zeile für die mit einem Befehl assoziierten Daten zu reservieren, setzt die Kennzeichen-Nachschlageinheit 410 das Verhaftet-Bit innerhalb des Eintrages, welcher mit der reservierten Cache-Zeile assoziiert ist. Die Kennzeichen-Nachschlageinheit 410 aktualisiert dann den Kennzeichenteil innerhalb des Eintrages, welcher mit der reservierten Cache-Zeile assoziiert ist, um die Datenklasse der mit dem Befehl assoziierten Daten und das Speicheradresse-Kennzeichen der reservierten Cache-Zeile zu reflektieren. Sobald die geeignete Cache-Zeile für einen Lesebefehl reserviert ist, übermittelt die Kennzeichen-Nachschlageinheit 410 eine Datenanfrage an den FB 355 nach den mit dem Lesebefehl assoziierten Daten. Der FB 355 übermittelt die mit dem Lesebefehl assoziierten Daten an die reservierte Cache-Zeile bei einem zukünftigen Taktzyklus. Für einen Schreibbefehl werden die mit dem Schreibbefehl assoziierten Daten von dem Schreibdatenpuffer 418 übermittelt und in der reservierten Cache-Zeile gespeichert. Die Kennzeichen-Nachschlageinheit 410 bestimmt dann, ob die mit dem Schreibbefehl assoziierten Daten in dem Parallelverarbeitungsspeicher 204 basierend auf der Datenklasse der Daten gespeichert werden sollen. Wenn die Daten in dem Parallelverarbeitungsspeicher 204 gespeichert werden sollen, dann übermittelt die Kennzeichen-Nachschlageinheit 410 eine Unreine-Daten-Benachrichtigung an den FB 355. Die Kennzeichen-Nachschlageinheit 410 setzt also das Unrein-Bit innerhalb des mit der reservierten Cache-Zeile assoziierten Eintrags. In Antwort übermittelt der FB 355 die Daten von der reservierten Cache-Zeile zu dem Parallelverarbeitungsspeicher 204 bei einem zukünftigen Taktzyklus. Sobald die Daten empfangen worden sind, wird das Verhaftet-Bit gelöscht.
  • In anderen Ausführungsformen mag der Statusteil eines Eintrags in dem Kennzeichenspeicher 422 in irgendeiner technisch durchführbaren Weise implementiert sein, umfassend, ohne Beschränkung, ein einzelnes Bit, um anzuzeigen, wenn Daten in der dem Eintrag entsprechenden Cache-Zeile rein und unverhaftet sind. Fachleute in der Technik werden daher verstehen, dass nichts in den Beschreibungen hierin Umfasstes beabsichtigt ist, den Geltungsbereich der vorliegenden Erfindung zu begrenzen.
  • In gewissen Ausführungsformen mögen Lesebefehle an die L2-Cache-Scheibe 402 mittels der Klienten innerhalb des Parallelverarbeitungsuntersystems 112 übermittelt werden, wo die mit diesen Befehlen assoziierten Daten von Systemspeicher 104 oder Speicher, welcher mit einer anderen GPU (oder PPU) innerhalb des Computersystems 100 assoziiert ist, abgerufen werden und temporär in dem Daten-Cache 414 gespeichert werden, im Gegensatz zu vorher hierin beschrieben, wobei die Daten von dem Parallelverarbeitungsspeicher 204 abgerufen werden, welcher mit FB 355 gekoppelt ist. Ähnlich mögen in gewissen Ausführungsformen Schreibbefehle an die L2-Cache-Scheibe 402 mittels der GPCs 208 oder der ROP 360 übermittelt werden, wo die mit diesen Befehlen assoziierten Daten in dem Daten-Cache 414 temporär gespeichert werden, bevor sie auf Systemspeicher 104 oder einen Speicher geschrieben werden, welcher mit einer anderen GPU (oder PPU) innerhalb des Computersystems 100 assoziiert ist, im Gegensatz zu wie vorher hierin beschrieben, wobei die Daten zu dem Parallelverarbeitungsspeicher 204 geschrieben werden, welcher mit FB 355 gekoppelt ist. In allen solchen Ausführungsformen bleibt die Weise, in welcher die mit den Lese- oder Schreibbefehlen assoziierten Daten in dem Daten-Cache 414 gecached sind und von dem Daten-Cache 414 ausgewiesen sind, wie hierin beschrieben, unverändert. Somit fallen alle solche Ausführungsformen innerhalb des Geltungsbereichs der vorliegenden Erfindung.
  • 5A bis 5D führen ein Flussdiagramm von Verfahrensschritten zum Handhaben des Flusses von Daten in den Daten-Cache 414 von 4 herein und heraus gemäß einer Ausführungsform der vorliegenden Erfindung aus. Obwohl die Verfahrensschritte in Verbindung mit 1–4 beschrieben sind, werden die Fachleute in der Technik verstehen, dass irgendein System, welches konfiguriert ist, die Verfahrensschritte, in irgendeiner Reihenfolge, durchzuführen, innerhalb des Geltungsbereichs der vorliegenden Erfindung fällt.
  • Das Verfahren 500 beginnt bei Schritt 502, wo die L2-Cache-Scheibe 402 einen Lese- oder Schreibbefehl von einem Klienten innerhalb des Systems 100 empfängt. Wie in Verbindung mit 4 beschrieben, umfasst jeder mittels der L2-Cache-Scheibe 402 empfangene Befehl eine Speicheradresse, welche mit einem Satz von Cache-Zeilen assoziiert ist, welche innerhalb des Daten-Cache 414 lokalisiert sind, wo die mit dem Befehl assoziierten Daten gespeichert werden mögen. Ein mittels der L2-Cache-Scheibe 402 empfangener Befehl umfasst auch die Datenklasse der mit dem Befehl assoziierten Daten. Bei Schritt 504 wird der Befehl in Crossbar-Befehlspuffer 404 oder in ROP-Befehlspuffer 406, wie es der Fall sein mag, gespeichert.
  • Bei Schritt 506, wenn der Befehl ein Schreibbefehl ist, schreitet dann das Verfahren 500 zu Schritt 508 fort, wo die mit dem Befehl assoziierten Daten mittels der L2-Cache-Scheibe 402 empfangen werden und in dem Schreibdatenpuffer 418 gespeichert werden. Bei Schritt 506, wenn der Befehl ein Lesebefehl ist, schreitet dann das Verfahren 500 direkt zu Schritt 510 fort. Bei Schritt 510 wird der mittels der L2-Cache-Scheibe 402 in Schritt 502 empfangene Befehl durch den Schiedsrichter 408 unter Benutzung von Standard-Schiedsrichter-Techniken ausgewählt und an die Kennzeichen-Nachschlageinheit 410 für Verarbeitung übermittelt.
  • Bei Schritt 512 identifiziert die Kennzeichen-Nachschlageinheit 410 basierend auf der Speicheradresse, welche in dem Befehl umfasst ist, und unter Benutzung von Satz-assoziative-Cache-Techniken den Satz von Cache-Zeilen in dem Daten-Cache 414, wo die mit dem ausgewählten Befehl assoziierten Daten gespeichert sein mögen. Wieder wird dieser Satz von Cache-Zeilen als die „identifizierten Cache-Zeilen” bezeichnet. Bei Schritt 514 bestimmt die Kennzeichen-Nachschlageinheit 410, ob es einen Cache-Verlust gibt. Es gibt einen Cache-Verlust, wenn die mit dem Befehl assoziierten Daten momentan nicht innerhalb einer der identifizierten Cache-Zeilen befindlich sind. In dem Fall eines Cache-Verlusts schreitet der Verfahrensschritt 500 zu Schritt 516 fort.
  • Bei Schritt 516 bestimmt die Kennzeichen-Nachschlageinheit 410, ob eine der identifizierten Cache-Zeilen leer ist (was bedeutet, dass die Cache-Zeile momentan verfügbar ist). Wenn keine der identifizierten Cache-Zeilen leer ist (was bedeutet, dass die Cache-Zeile momentan unrein oder verhaftet ist), dann schreitet das Verfahren 500 zu Schritt 518 fort. Bei Schritt 518 untersucht die Kennzeichen-Nachschlageinheit 410 die Kennzeichen in dem Kennzeichenspeicher 412, welcher den identifizierten Cache-Zeilen entspricht, um zu bestimmen, welche der Cache-Zeilen, wenn überhaupt, ansässige Daten hat, welche rein, unverhaftet und von der evict_first-Datenklasse sind. Wenn keine der Cache-Zeilen ansässige Daten hat, welche rein, unverhaftet und von der evict_first-Datenklasse sind, dann schreitet das Verfahren 500 zu Schritt 520 fort. Bei Schritt 520 untersucht die Kennzeichen-Nachschlageinheit 410 die Kennzeichen in dem Kennzeichenspeicher, welcher den identifizierten Cache-Zeilen entspricht, um zu bestimmen, welche dieser Cache-Zeilen, wenn überhaupt, ansässige Daten hat, welche rein, unverhaftet und von der evict_normal-Datenklasse sind. Wenn keine der Cache-Zeilen ansässige Daten hat, welche rein, unverhaftet und evict_normal sind, dann schreitet das Verfahren 500 zu Schritt 522 fort.
  • Bei Schritt 522 untersucht die Kennzeichen-Nachschlageinheit 410 die Datenklasse, welche in dem Befehl umfasst ist, um zu bestimmen, ob die mit dem Befehl assoziierten Daten von der evict_last-Datenklasse sind. Wenn die Datenklasse der mit dem Befehl assoziierten Daten von der evict_last-Datenklasse sind, dann schreitet das Verfahren 500 zu Schritt 524 fort, wo die Kennzeichen-Nachschlageinheit 410 die Kennzeichen in dem Kennzeichenspeicher 412 untersucht, welcher den identifizierten Cache-Zeilen entspricht, um zu bestimmen, welche dieser Cache-Zeilen, wenn überhaupt, ansässige Daten hat, welche rein, unverhaftet und von der evict_last-Datenklasse sind. Wenn eine oder mehr der identifizierten Cache-Zeilen ansässige Daten hat, welche rein, unverhaftet und von der evict_last-Datenklasse sind, dann wird die Cache-Zeile mit den am wenigsten kürzlich benutzten ansässigen Daten, welche rein, unverhaftet und von der evict_last-Datenklasse sind, für Ausweisung ausgewählt.
  • Bei Schritt 526 reserviert die Kennzeichen-Nachschlageinheit 410 die ausgewählte Cache-Zeile für die mit dem Befehl assoziierten Daten. Wie in Verbindung mit 4 beschrieben, setzt die Kennzeichen-Nachschlageinheit 410 den Gültig-Bit-Teil innerhalb des mit der ausgewählten Cache-Zeile assoziierten Eintrags, um eine Cache-Zeile für die mit einem Befehl assoziierten Daten zu reservieren. Die Kennzeichen-Nachschlageinheit aktualisiert dann den Kennzeichenteil innerhalb des mit der ausgewählten Cache-Zeile assoziierten Eintrags, um die Datenklasse der mit dem Befehl assoziierten Daten zu reflektieren.
  • Bei Schritt 528 bestimmt die Kennzeichen-Nachschlageinheit 410, ob der Befehl ein Schreibbefehl ist. Wenn der Befehl ein Schreibbefehl ist, dann schreitet das Verfahren 500 zu Schritt 530 fort, wo die mit dem Schreibbefehl assoziierten Daten von dem Schreibdatenpuffer 418 an die reservierte Cache-Zeile übermittelt werden. Bei Schritt 532 analysiert die Kennzeichen-Nachschlageinheit 410 die Datenklasse der mit dem Befehl assoziierten Daten, um zu bestimmen, ob die Daten an den externen Speicher zur Speicherung übermittelt werden sollen. In einer Ausführungsform sind Daten von evict_last-Datenklasse hinten angestellte Daten (queued data) und sollten nicht an den externen Speicher zur Speicherung übermittelt werden, während Daten der evict_first- und evict_normal-Datenklasse zu dem externen Speicher zur Speicherung übermittelt werden sollten. Wenn die Daten zu dem externen Speicher zur Speicherung übermittelt werden sollten, dann übermittelt bei Schritt 534 die Kennzeichen-Nachschlageinheit 410 eine Unreine-Daten-Benachrichtigung an die Bildpufferlogik 355. Die Bildpufferlogik (frame buffer logic) 355 übermittelt wiederum die unreinen Daten an den externen Speicher bei einem effizienten Taktzyklus. Wenn bei Schritt 532 die Kennzeichen-Nachschlageinheit 410 bestimmt, dass die Daten nicht an den externen Speicher zur Speicherung übermittelt werden sollten, dann endet das Verfahren 500.
  • Mit Bezug nun zurück auf Schritt 530, wenn der Befehl ein Lesebefehl ist, schreitet dann das Verfahren 500 zu Schritt 536 fort, wo die Kennzeichen-Nachschlageinheit 410 eine Datenanfrage-Benachrichtigung an die Bildpufferlogik 355 übermittelt. Die Bildpufferlogik 355 wiederum übermittelt die angefragten Daten zu der Cache-Zeile, welche bei Schritt 526 bei einem effizienten Taktzyklus reserviert wird. Das Verfahren 500 endet dann.
  • Mit Bezug nun zurück auf Schritt 524, wenn keine der Cache-Zeilen ansässige Daten hat, welche rein, unverhaftet und von der evict_last-Datenklasse sind, dann wird der Befehl bei Schritt 525 angehalten und das Verfahren 500 kehrt zu Schritt 516 zurück, vorher hierin beschrieben. Ähnlich, mit Bezug zurück auf Schritt 522, wenn die Datenklasse der mit dem Befehl assoziierten Daten nicht evict_last ist, dann wird bei Schritt 525 der Befehl angehalten und das Verfahren 500 kehrt zu Schritt 516 zurück, vorher hierin beschrieben.
  • Mit Bezug nun zurück auf Schritt 520, wenn eine oder mehr der identifizierten Cache-Zeilen ansässige Daten hat, welche rein, unverhaftet und von der evict_normal-Datenklasse sind, dann wird die Cache-Zeile mit den am wenigsten kürzlich benutzten ansässigen Daten, welche rein, unverhaftet und von der evict_normal-Datenklasse sind, zur Ausweisung ausgewählt. Das Verfahren 500 schreitet dann direkt zu Schritt 526 fort, vorher hierin beschrieben. Mit Bezug zurück auf Schritt 518, wenn eine oder mehr der identifizierten Cache-Zeilen ansässige Daten hat, welche rein, unverhaftet und von der evict_first-Datenklasse sind, dann wird die Cache-Zeile mit den am wenigsten kürzlich benutzten ansässigen Daten, welche rein, unverhaftet und von der evict_first-Datenklasse sind, zur Ausweisung ausgewählt. Das Verfahren 500 schreitet dann direkt zu Schritt 526 fort, vorher hierin beschrieben.
  • Mit Bezug zurück nun auf Schritt 516, wenn eine Cache-Zeile in dem Daten-Cache 414 verfügbar ist, schreitet dann das Verfahren 500 direkt zu Schritt 528 fort, vorher hierin beschrieben. Mit Bezug zurück schließlich auf Schritt 514, wenn es einen Cache-Treffer (im Gegensatz zu einem Cache-Verlust) gibt, dann schreitet das Verfahren 500 direkt zu Schritt 538 fort. Bei Schritt 538 bestimmt die Kennzeichen-Nachschlageinheit 410, ob der Befehl ein Schreibbefehl ist. Wenn der Befehl ein Schreibbefehl ist, dann schreitet das Verfahren 500 zu Schritt 540 fort, wo die mit dem Schreibbefehl assoziierten Daten von dem Schreibdatenpuffer 418 zu der bereits reservierten Cache-Zeile übermittelt werden. Wenn bei Schritt 538 der Befehl ein Lesebefehl ist, dann führt bei Schritt 542 die Kennzeichen-Nachschlageinheit 410 die in der bereits reservierten Cache-Zeile gespeicherten Daten zu dem Lesedatenpuffer 416. Bei Schritt 544 werden dann die Daten von dem Lesedatenpuffer 416 zu dem Klienten übermittelt, welcher den Lesebefehl bei Schritt 502 übermittelte.
  • Zusammenfassend umfasst jeder Lese- oder Schreibbefehl, welcher mittels eines Klienten an die L2-Cache-Scheibe übermittelt wird, eine Speicheradresse und die Datenklasse der mit diesem bestimmten Befehl assoziierten Daten. Die Kennzeichen-Nachschlageinheit innerhalb der L2-Cache-Scheibe analysiert die in solch einem Befehl umfasste Speicheradresse, um den Satz von potentiellen Cache-Zeilen zu bestimmen, in welchen die mit dem Befehl assoziierten Daten gespeichert werden mögen. Die Kennzeichen-Nachschlageinheit analysiert auch die Kennzeichen, welche in dem Kennzeichenspeicher gespeichert sind, welcher mit jeder der potentiellen Cache-Zeile assoziiert ist, um wenigstens eine Cache-Zeile zu identifizieren, welche für die mit dem Befehl assoziierten Daten reserviert werden mag. Wenn eine der potentiellen Cache-Zeilen leer ist, dann reserviert die Kennzeichen-Nachschlageinheit diese Cache-Zeilen für die angefragten oder geschriebenen Daten. Beim Reservieren einer Cache-Zeile für einen bestimmten Befehl speichert die Kennzeichen-Nachschlageinheit die Datenklasse der mit dem Befehl assoziierten Daten in dem Kennzeichenteil des Eintrags innerhalb des Kennzeichenspeichers, welcher dieser Cache-Zeile entspricht.
  • Wenn jedoch keine der identifizierten Cache-Zeilen leer ist, dann bestimmt die Kennzeichen-Nachschlageinheit, ob irgendeine der identifizierten Cache-Zeilen ansässige Daten hat, welche rein, unverhaftet sind und zu der evict_first-Datenklasse gehören. Wenn die Daten in einer oder mehr der identifizierten Zeilen alle diese Kriterien erfüllen, dann führt die Kennzeichen-Nachschlageinheit dazu, dass die am wenigsten kürzlich benutzten reinen, unverhafteten, evict_first-Daten ausgewiesen werden und reserviert die assoziierte Cache-Zeile für die angefragten oder geschriebenen Daten. Wenn keine der Daten in den identifizierten Cache-Zeilen alle diese Kriterien erfüllen, dann bestimmt die Kennzeichen-Nachschlageinheit, ob irgendeine der identifizierten Cache-Zeilen ansässige Daten hat, welche rein, unverhaftet sind und zu der evict_normal-Datenklasse gehören. Wenn die Daten in einer oder mehr der identifizierten Zeilen alle diese Kriterien erfüllen, dann führt die Kennzeichen-Nachschlageinheit dazu, dass die am wenigsten kürzlich benutzten reinen, unverhafteten, evict_normal-Daten ausgewiesen werden und reserviert die assoziierte Cache-Zeile für die angefragten oder geschriebenen Daten. Wenn keine der Daten in den identifizierten Cache-Zeilen alle diese Kriterien erfüllen, dann wird der Lese- oder Schreibbefehl angehalten, bis die Daten in einer der identifizierten Zeilen ausgewiesen werden können.
  • Vorteilhafterweise erlaubt die mit den in dem Daten-Cache gespeicherten Daten assoziierte Datenklasse der Kennzeichen-Nachschlageinheit, Daten auszuweisen, welche die geringste Wahrscheinlichkeit für Wiederverwendung haben, wenn Platz für mit einem Lese- oder Schreibbefehl assoziierte Daten gemacht wird. Dieser Mechanismus eines Ausweisens von Daten vermindert die Anzahl von Cache-Verlusten, welche aus einer frühen Ausweisung von Daten resultieren, welche durch Klienten innerhalb eines Systems wiederverwendet werden mögen. Zusätzlich mag der Daten-Cache benutzt werden, um Daten zu speichern, welche oft wiederbenutzt werden, aber nicht zu dem externen Speicher übermittelt zu werden brauchen durch Anbringen der geeigneten Datenklasse an diese Daten. Dies eliminiert das Erfordernis für zusätzliche Datenspeicherstrukturen, um diese Daten zu speichern.
  • Während das Vorangehende auf Ausführungsformen der vorliegenden Erfindung gerichtet ist, mögen andere und weitere Ausführungsformen der Erfindung entworfen werden, ohne von dem grundsätzlichen Geltungsbereich davon abzuweichen. Zum Beispiel mögen Aspekte der vorliegenden Erfindung in Hardware oder Software oder in einer Kombination von Hardware und Software implementiert sein. Eine Ausführungsform der Erfindung mag als ein Programmprodukt zur Benutzung mit einem Computersystem implementiert sein. Das Programm/die Programme des Programmprodukts definieren Funktionen der Ausführungsformen (umfassend die hierin beschriebenen Verfahren) und kann/können auf einer Verschiedenheit von Computer lesbaren Speichermedien umfasst sein. Illustrative Computer lesbare Speichermedien umfassen, sind jedoch nicht darauf beschränkt: (i) nicht-beschreibbare Speichermedien (z. B. nur-Lese-Speichergeräte innerhalb eines Computers, wie etwa CD-ROM-Disks, welche mittels eines CD-ROM-Laufwerks lesbar sind, Flashmemory, ROM-Chips oder irgendein Typ von Festkörper-nicht-volatilem Halbleiterspeicher), auf welchen Information permanent gespeichert sind; und (ii) beschreibbare Speichermedien (z. B. Floppydisketten innerhalb eines Diskettenlaufwerks oder Festplattenlaufwerks oder irgendein Typ von Festkörper-Direktzugriffs-Halbleiterspeicher (random-access semiconductor memory)), auf welchen veränderbare Information gespeichert ist. Solche Computer lesbaren Speichermedien sind Ausführungsformen der vorliegenden Erfindung, wenn sie Computer lesbare Anweisungen tragen, welche die Funktionen der vorliegenden Erfindung dirigieren. Daher ist der Geltungsbereich der vorliegenden Erfindung mittels der Ansprüche bestimmt, welche folgen.

Claims (10)

  1. System zum Ausweisen von Daten aus einem intermediären Cache, welcher mit einem oder mehr Client und mit einem externen Speicher gekoppelt ist, wobei das System aufweist: eine oder mehr Daten-Cache-Einheiten; eine Kennzeichenspeicher-Einheit, welche konfiguriert ist, einen verschiedenen Eintrag für jede einer Mehrzahl von Cache-Zeilen zu speichern, welche mit der einen oder mehr Daten-Cache-Einheiten assoziiert sind, wobei jeder Eintrag ein Kennzeichen, welches eine Ausweisungsklasse anzeigt, welche mit Daten assoziiert ist, welche in der Cache-Zeile gespeichert sind, welche dem Eintrag entspricht, und einen Statusteil umfasst, welcher anzeigt, ob die Daten in der Cache-Zeile, welche dem Eintrag entspricht, einwandfrei und unverhaftet sind, und wobei die Ausweisungsklasse die Wahrscheinlichkeit anzeigt, dass die Daten, welche in der Cache-Zeile gespeichert sind, welche dem Eintrag entspricht, durch den einen oder mehr Client wieder benutzt werden werden; eine Kennzeichen-Nachschlageinheit, welche mit der einen oder mehr Daten-Cache-Einheiten und der Kennzeichenspeicher-Einheit gekoppelt ist, und konfiguriert ist, um: einen Befehl von einem Client zu empfangen, welcher eine assoziierte Speicheradresse umfasst, eine oder mehr Cache-Zeilen innerhalb der einen oder mehr Daten-Cache-Einheiten zu identifizieren, um Daten, welche mit dem Befehl assoziiert sind, basierend auf der Speicheradresse zu speichern, zu bestimmen, dass es einen Cache-Verlust bezogen auf die eine oder mehr Cache-Zeilen gibt, und zu bewirken, dass in zumindest einer der einen oder mehr Cache-Zeilen befindliche Daten ausgewiesen werden basierend auf der Ausweisungsklasse, welche mit den Daten assoziiert ist, welche in der zumindest einen Cache-Zeile gespeichert sind, welche in dem Eintrag in der Kennzeichenspeicher-Einheit umfasst sind, welche der zumindest einen Cache-Zeile entspricht.
  2. System nach Anspruch 1, wobei der Statusteil ein Gültig-Flag, ein Unrein-Flag, und ein Verhaftet-Flag umfasst.
  3. System nach Anspruch 1, wobei das Kennzeichen, welches in dem Eintrag in der Kennzeichenspeicher-Einheit umfasst ist, welche der zumindest einen Cache-Zeile entspricht, anzeigt, dass die Daten, welche in der zumindest einen Cache-Zeile gespeichert sind, zu einer Zuerst-Ausweisungsklasse gehören, wobei der Statusteil, welcher in dem Eintrag umfasst ist, anzeigt, dass Daten, welche in der zumindest einen Cache-Zeile gespeichert sind, rein und unverhaftet sind, und wobei die Kennzeichen-Nachschlageinheit konfiguriert ist, zu bestimmen, dass die Daten in der zumindest einen Cache-Zeile die am wenigsten kürzlich benutzten, reinen, unverhafteten, Zuerst-Ausweisungsklassedaten in der einen oder mehr Cache-Zeilen sind und dann zu bewirken, dass die Daten in der zumindest einen Cache-Zeile ausgewiesen werden.
  4. System nach Anspruch 1, wobei das Kennzeichen, welches in dem Eintrag in der Kennzeichen-Speichereinheit umfasst ist, welche der zumindest einen Cache-Zeile entspricht, anzeigt, dass die Daten, welche in der zumindest einen Cache-Zeile gespeichert sind, zu einer Normal-Ausweisungsklasse gehören, wobei der Statusteil, welcher in dem Eintrag umfasst ist, anzeigt, dass Daten, welche in der zumindest einen Cache-Zeile gespeichert sind, rein und unverhaftet sind, und wobei die Kennzeichen-Nachschlageinheit konfiguriert ist, zu bestimmen, dass die Daten in der zumindest einen Cache-Zeile die am wenigsten kürzlich benutzten, reinen, unverhafteten, Normal-Ausweisungsdaten in der einen oder mehr Cache-Zeilen sind und dann zu bewirken, dass die Daten in der zumindest einen Cache-Zeile ausgewiesen werden.
  5. System nach Anspruch 1, wobei die Kennzeichen-Nachschlageinheit konfiguriert ist, zu bestimmen, dass die Daten, welche mit dem Befehl assoziiert sind, zu einer Zuletzt-Ausweisungsklasse gehören, wobei das Kennzeichen, welches in dem Eintrag in der Kennzeichenspeicher-Einheit umfasst ist, welche der zumindest einen Cache-Zeile entspricht, anzeigt, dass die Daten, welche in der zumindest einen Cache-Zeile gespeichert sind, zu einer Zuletzt-Ausweisungsklasse gehören, wobei der Statusteil, welcher in dem Eintrag umfasst ist, anzeigt, dass die Daten, welche in der zumindest einen Cache-Zeile gespeichert sind, rein und unverhaftet sind, und wobei die Kennzeichen-Nachschlageinheit konfiguriert ist, zu bestimmen, dass die Daten in der zumindest einen Cache-Zeile die am wenigstens kürzlich benutzten, reinen, unverhafteten, Zuletzt-Ausweisungsklassedaten in der einen oder mehr Cache-Zeilen sind und dann zu bewirken, dass die Daten in der zumindest einen Cache-Zeile ausgewiesen werden.
  6. System nach Anspruch 1, wobei die Daten, welche in der zumindest einen Cache-Zeile gespeichert sind, zu einer Zuletzt-Ausweisungsklasse gehören, und wobei die Kennzeichen-Nachschlageinheit konfiguriert ist, die Daten als gehörig zu einer Normal-Ausweisungsklasse zu reklassifizieren, und wobei der Statusteil, welcher in dem Eintrag in der Kennzeichenspeicher-Einheit umfasst ist, welche der zumindest einen Cache-Zeile entspricht, anzeigt, dass Daten, welche in der zumindest einen Cache-Zeile gespeichert sind, rein und unverhaftet sind, und wobei die Kennzeichen-Nachschlageinheit weiterhin konfiguriert ist, zu bestimmen, dass die Daten in der zumindest einen Cache-Zeile die am wenigsten kürzlich benutzten, reinen, unverhafteten, Normal-Ausweisungsdaten in der einen oder mehr Cache-Zeilen sind und dann zu bewirken, dass die Daten in der zumindest einen Cache-Zeile ausgewiesen werden.
  7. System nach Anspruch 1, wobei die Kennzeichen-Nachschlageinheit weiterhin konfiguriert ist, eine Rein-Benachrichtigung an Framepufferlogik für die in der zumindest einen Cache-Zeile befindlichen Daten zu übertragen und die zumindest eine Cache-Zeile für die Daten zu reservieren, welche mit dem Befehl assoziiert sind.
  8. Rechengerät, aufweisend: einen oder mehr Client; einen intermediären Cache, welcher umfasst: eine oder mehr Daten-Cache-Einheiten, eine Kennzeichenspeicher-Einheit, welche konfiguriert ist, einen verschiedenen Eintrag für jede einer Mehrzahl von Cache-Zeilen zu speichern, welche mit der einen oder mehr Daten-Cache-Einheiten assoziiert sind, wobei jeder Eintrag ein Kennzeichen, welches eine Ausweisungsklasse anzeigt, welche mit Daten assoziiert ist, welche in der Cache-Zeile gespeichert sind, welche dem Eintrag entspricht, und einen Statusteil umfasst, welcher anzeigt, ob die Daten in der Cache-Zeile, welche dem Eintrag entspricht, rein und unverhaftet sind, und wobei die Ausweisungsklasse die Wahrscheinlichkeit anzeigt, dass die Daten, welche in der Cache-Zeile gespeichert sind, welche dem Eintrag entspricht, durch den einen oder mehr Client wieder benutzt werden werden, und eine Kennzeichen-Nachschlageinheit, welche mit der einen oder mehr Daten-Cache-Einheiten gekoppelt ist; einen externen Speicher, welcher mit dem intermediären Cache gekoppelt ist; und eine Crossbar-Einheit, welche den einen oder mehr Client mit dem intermediären Cache koppelt, wobei die Kennzeichen-Nachschlageinheit konfiguriert ist, um: einen Befehl von einem Client zu empfangen, welcher eine assoziierte Speicheradresse umfasst, eine oder mehr Cache-Zeilen innerhalb der einen oder mehr Daten-Cache-Einheiten zu identifizieren, um Daten, welche mit dem Befehl assoziiert sind, basierend auf der Speicheradresse zu speichern, zu bestimmen, dass es einen Cache-Verlust bezogen auf die eine oder mehr Cache-Zeilen gibt, und zu bewirken, dass in zumindest einer der einen oder mehr Cache-Zeilen befindliche Daten ausgewiesen werden basierend auf der Ausweisungsklasse, welche mit den Daten assoziiert ist, welche in der zumindest einen Cache-Zeile gespeichert sind, welche in dem Eintrag in der Kennzeichenspeicher-Einheit umfasst ist, welche der zumindest einen Cache-Zeile entspricht.
  9. Rechengerät nach Anspruch 8, wobei der Statusteil ein Gültig-Flag, ein Unrein-Flag und ein Verhaftet-Flag umfasst.
  10. Rechengerät nach Anspruch 8, wobei Kennzeichen-Nachschlageinheit weiter konfiguriert ist, eine Rein-Benachrichtigung an Framepufferlogik für die Daten zu übertragen, welche sich in der zumindest einen Cache-Zeile befinden, und die zumindest eine Cache-Zeile für Daten zu reservieren, welche mit den Befehl assoziiert sind.
DE102009046847A 2008-11-21 2009-11-18 Mehrklassen-Daten-Cache-Verfahren Withdrawn DE102009046847A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/276,154 2008-11-21
US12/276,154 US8868838B1 (en) 2008-11-21 2008-11-21 Multi-class data cache policies

Publications (1)

Publication Number Publication Date
DE102009046847A1 true DE102009046847A1 (de) 2010-05-27

Family

ID=41565470

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102009046847A Withdrawn DE102009046847A1 (de) 2008-11-21 2009-11-18 Mehrklassen-Daten-Cache-Verfahren

Country Status (6)

Country Link
US (1) US8868838B1 (de)
JP (1) JP5229968B2 (de)
KR (1) KR101121487B1 (de)
CN (1) CN101739357B (de)
DE (1) DE102009046847A1 (de)
GB (1) GB2465474B (de)

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007143278A2 (en) 2006-04-12 2007-12-13 Soft Machines, Inc. Apparatus and method for processing an instruction matrix specifying parallel and dependent operations
EP2122461A4 (de) 2006-11-14 2010-03-24 Soft Machines Inc Vorrichtung und verfahren zur verarbeitung von befehlen in einer multithread-architektur mit kontextwechsel
KR101064178B1 (ko) * 2010-08-24 2011-09-14 한국과학기술원 버퍼 캐시 관리 시스템 및 방법
EP2616928B1 (de) 2010-09-17 2016-11-02 Soft Machines, Inc. Mehrfach verzweigte einzelzyklus-vorhersage mit einem latenten cache für frühe und entfernte verzweigungsvorhersage
US9218686B2 (en) 2010-12-03 2015-12-22 Digital Media Professionals Inc. Image processing device
US9274793B2 (en) 2011-03-25 2016-03-01 Soft Machines, Inc. Memory fragments for supporting code block execution by using virtual cores instantiated by partitionable engines
WO2012135041A2 (en) 2011-03-25 2012-10-04 Soft Machines, Inc. Register file segments for supporting code block execution by using virtual cores instantiated by partitionable engines
EP2689327B1 (de) 2011-03-25 2021-07-28 Intel Corporation Ausführung von befehlsfolgen-codeblocks mittels durch partitionierbare engines realisierter virtueller kerne
JP2012203881A (ja) * 2011-03-28 2012-10-22 Fujitsu Ltd ストレージ装置及びストレージ制御装置
TWI548994B (zh) 2011-05-20 2016-09-11 軟體機器公司 以複數個引擎支援指令序列的執行之互連結構
KR101639853B1 (ko) 2011-05-20 2016-07-14 소프트 머신즈, 인크. 복수의 엔진에 의해 명령어 시퀀스들의 실행을 지원하기 위한 자원들 및 상호접속 구조들의 비집중 할당
EP2783281B1 (de) 2011-11-22 2020-05-13 Intel Corporation Durch einen mikroprozessor beschleunigter code-optimierer
KR101842550B1 (ko) 2011-11-22 2018-03-28 소프트 머신즈, 인크. 다중 엔진 마이크로프로세서용 가속 코드 최적화기
US9720829B2 (en) * 2011-12-29 2017-08-01 Intel Corporation Online learning based algorithms to increase retention and reuse of GPU-generated dynamic surfaces in outer-level caches
US8930674B2 (en) 2012-03-07 2015-01-06 Soft Machines, Inc. Systems and methods for accessing a unified translation lookaside buffer
CN103309818B (zh) * 2012-03-09 2015-07-29 腾讯科技（深圳）有限公司 存储数据的方法及装置
US9740612B2 (en) 2012-07-30 2017-08-22 Intel Corporation Systems and methods for maintaining the coherency of a store coalescing cache and a load cache
US9229873B2 (en) 2012-07-30 2016-01-05 Soft Machines, Inc. Systems and methods for supporting a plurality of load and store accesses of a cache
US9710399B2 (en) * 2012-07-30 2017-07-18 Intel Corporation Systems and methods for flushing a cache with modified data
US9430410B2 (en) 2012-07-30 2016-08-30 Soft Machines, Inc. Systems and methods for supporting a plurality of load accesses of a cache in a single cycle
US9916253B2 (en) 2012-07-30 2018-03-13 Intel Corporation Method and apparatus for supporting a plurality of load accesses of a cache in a single cycle to maintain throughput
US9311251B2 (en) 2012-08-27 2016-04-12 Apple Inc. System cache with sticky allocation
US20140089600A1 (en) * 2012-09-27 2014-03-27 Apple Inc. System cache with data pending state
US9678882B2 (en) 2012-10-11 2017-06-13 Intel Corporation Systems and methods for non-blocking implementation of cache flush instructions
US9372811B2 (en) * 2012-12-13 2016-06-21 Arm Limited Retention priority based cache replacement policy
CN103092920B (zh) * 2012-12-26 2017-04-12 新浪网技术(中国)有限公司 半结构化数据的存储方法及存储系统
US9904625B2 (en) 2013-03-15 2018-02-27 Intel Corporation Methods, systems and apparatus for predicting the way of a set associative cache
CN105247484B (zh) 2013-03-15 2021-02-23 英特尔公司 利用本地分布式标志体系架构来仿真访客集中式标志体系架构的方法
US9891924B2 (en) 2013-03-15 2018-02-13 Intel Corporation Method for implementing a reduced size register view data structure in a microprocessor
WO2014150806A1 (en) 2013-03-15 2014-09-25 Soft Machines, Inc. A method for populating register view data structure by using register template snapshots
EP2972845B1 (de) 2013-03-15 2021-07-07 Intel Corporation Verfahren zur ausführung von in blöcken gruppierten befehlen aus mehreren threads
US10140138B2 (en) 2013-03-15 2018-11-27 Intel Corporation Methods, systems and apparatus for supporting wide and efficient front-end operation with guest-architecture emulation
US9811342B2 (en) 2013-03-15 2017-11-07 Intel Corporation Method for performing dual dispatch of blocks and half blocks
WO2014150991A1 (en) 2013-03-15 2014-09-25 Soft Machines, Inc. A method for implementing a reduced size register view data structure in a microprocessor
US10275255B2 (en) 2013-03-15 2019-04-30 Intel Corporation Method for dependency broadcasting through a source organized source view data structure
WO2014150971A1 (en) 2013-03-15 2014-09-25 Soft Machines, Inc. A method for dependency broadcasting through a block organized source view data structure
US9569216B2 (en) 2013-03-15 2017-02-14 Soft Machines, Inc. Method for populating a source view data structure by using register template snapshots
US9886279B2 (en) 2013-03-15 2018-02-06 Intel Corporation Method for populating and instruction view data structure by using register template snapshots
CN103336844B (zh) * 2013-07-22 2016-12-28 广西师范大学 大数据rd分割方法
US10152410B2 (en) * 2014-03-28 2018-12-11 Empire Technology Development Llc Magnetoresistive random-access memory cache write management
US9866498B2 (en) * 2014-12-23 2018-01-09 Intel Corporation Technologies for network packet cache management
US10866901B2 (en) 2018-06-02 2020-12-15 International Business Machines Corporation Invalidating CKD data tracks prior to unpinning, wherein upon destaging invalid track image from cache to a track of data on storage drive, the track of data on the storage drive is unpinned which enables destages of data from the cache to the track of data on the storage drive going forward
KR20200059493A (ko) * 2018-11-21 2020-05-29 에스케이하이닉스 주식회사 데이터 처리 시스템
US11099989B2 (en) 2019-03-12 2021-08-24 International Business Machines Corporation Coherency maintenance via physical cache coordinate comparison
US10831661B2 (en) 2019-04-10 2020-11-10 International Business Machines Corporation Coherent cache with simultaneous data requests in same addressable index

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3236287B2 (ja) 1990-11-29 2001-12-10 キヤノン株式会社 マルチプロセッサシステム
JPH04215151A (ja) 1990-12-13 1992-08-05 Nec Commun Syst Ltd キャッシュ制御方式
JPH06348595A (ja) * 1993-06-07 1994-12-22 Hitachi Ltd キャッシュ装置
JPH0728706A (ja) 1993-07-14 1995-01-31 Sumitomo Electric Ind Ltd キャッシュメモリ装置
US5893920A (en) * 1996-09-30 1999-04-13 International Business Machines Corporation System and method for cache management in mobile user file systems
US6223256B1 (en) * 1997-07-22 2001-04-24 Hewlett-Packard Company Computer cache memory with classes and dynamic selection of replacement algorithms
KR19990026501A (ko) * 1997-09-25 1999-04-15 구자홍 분산 공유 메모리의 캐시 일관성 제어방법 및 장치
GB2345987B (en) 1999-01-19 2003-08-06 Advanced Risc Mach Ltd Memory control within data processing systems
JP2002024088A (ja) 2000-07-07 2002-01-25 Matsushita Electric Ind Co Ltd データ処理装置
JP2002140234A (ja) * 2000-11-02 2002-05-17 Hitachi Ltd キャッシュ装置
JP4417715B2 (ja) 2001-09-14 2010-02-17 サン・マイクロシステムズ・インコーポレーテッド キャッシュメモリにおける、タグおよびデータアクセスを分断する方法および装置
US7027064B2 (en) * 2002-02-28 2006-04-11 Sun Microsystems, Inc. Active block write-back from SRAM cache to DRAM
US6961821B2 (en) 2002-10-16 2005-11-01 International Business Machines Corporation Reconfigurable cache controller for nonuniform memory access computer systems
JP2004145780A (ja) 2002-10-28 2004-05-20 Mitsubishi Electric Corp マルチプロセッサ・キャッシュ装置
JP2004326187A (ja) * 2003-04-21 2004-11-18 Matsushita Electric Ind Co Ltd 情報処理装置およびその制御方法
US7024521B2 (en) 2003-04-24 2006-04-04 Newisys, Inc Managing sparse directory evictions in multiprocessor systems via memory locking
US7398304B2 (en) 2003-06-23 2008-07-08 Microsoft Corporation General dependency model for invalidating cache entries
US7010649B2 (en) * 2003-10-14 2006-03-07 International Business Machines Corporation Performance of a cache by including a tag that stores an indication of a previously requested address by the processor not stored in the cache
JP2006048447A (ja) * 2004-08-05 2006-02-16 Matsushita Electric Ind Co Ltd キャッシュメモリ装置およびそれを用いる集積回路ならびにデータのキャッシュメモリ方法およびプログラム
US7380065B2 (en) 2005-03-30 2008-05-27 International Business Machines Corporation Performance of a cache by detecting cache lines that have been reused
US7536513B2 (en) * 2005-03-31 2009-05-19 International Business Machines Corporation Data processing system, cache system and method for issuing a request on an interconnect fabric without reference to a lower level cache based upon a tagged cache state
US7793049B2 (en) 2007-10-30 2010-09-07 International Business Machines Corporation Mechanism for data cache replacement based on region policies
US8464009B2 (en) 2008-06-04 2013-06-11 Oracle America, Inc. Method for memory interleave support with a ceiling mask
US20100079454A1 (en) 2008-09-29 2010-04-01 Legakis Justin S Single Pass Tessellation

Also Published As

Publication number Publication date
GB2465474B (en) 2011-08-31
CN101739357B (zh) 2012-08-29
GB2465474A (en) 2010-05-26
KR20100057516A (ko) 2010-05-31
JP5229968B2 (ja) 2013-07-03
US8868838B1 (en) 2014-10-21
JP2010123130A (ja) 2010-06-03
CN101739357A (zh) 2010-06-16
GB0920187D0 (en) 2010-01-06
KR101121487B1 (ko) 2012-02-28

Similar Documents

Publication Publication Date Title
DE102009046847A1 (de) Mehrklassen-Daten-Cache-Verfahren
DE102009039231B4 (de) Einzeldurchgang-Kachelung
DE102012216568B4 (de) Scheduling und Managen von Rechentasks mit unterschiedlichen Ausführungsprioritätsstufen
DE102009047518B4 (de) Computersystem und Verfahren geeignet zum Vermeiden von Datenkommunikationsverklemmungssituationen durch Markieren von CPU-Datenverkehr als speziell
DE102012222558B4 (de) Signalisieren, Ordnen und Ausführung von dynamisch erzeugten Aufgaben in einem Verarbeitungs-System
DE102018132468A1 (de) Multi-gpu-frame-rendern
DE112010003750T5 (de) Hardware für parallele Befehlslistenerzeugung
DE102012211670A1 (de) Simultanes Unterbreiten an eine Mehr-Produzenten-Queue mittels mehrerer Threads
DE102013017639B4 (de) Zwischenspeicherung von adaptiv dimensionierten Cache-Kacheln in einem vereinheitlichten L2-Cache-Speicher mit Oberflächenkomprimierung
DE102013201178B4 (de) Steuern von Arbeitsverteilung für Verarbeitung von Tasks
DE102013114072A1 (de) System und Verfahren zum Hardware-Scheduling von indexierten Barrieren
DE102013205886A1 (de) Dynamische Bankmodus-Adressierung für Speicherzugriff
DE112010003758T5 (de) Instruktionen zum Verwalten einer parallelen Cache-Hierarchie
DE102012220267B4 (de) Rechenarbeitsverteilungs - Referenzzähler
DE102012222394A1 (de) Verfahren und Vorrichtung zum Sammelzwischenspeichern von Quelloperanden
DE102012221502A1 (de) System und Verfahren zum Durchführen von gestalteter-Speicherzugriff-Operationen
DE102013202173A1 (de) Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads
DE102009047200A1 (de) Ein Komprimierungs-Zustandsbit-Zwischenspeicher und Zusatzspeicher
DE102013208423A1 (de) Virtuelle Speicherstruktur für Coprozessoren, die Speicherallokationsbegrenzungen haben
DE102013202495A1 (de) Verfahren zur Durchführung von interaktivem Debugging auf nicht unterbrechbaren Graphikverarbeitungseinheiten
DE102013208554A1 (de) Verfahren und System zum Managen verschachtelter Ausführungsströme
DE102012212639A1 (de) Temporäre SIMT-Ausführungs-Optimierung
US8131931B1 (en) Configurable cache occupancy policy
DE102013114351A1 (de) System und Verfahren für Hardware-Disponierung bedingter Barrieren und ungeduldiger Barrieren
DE102012221504A1 (de) Mehrniveau-Anweisung-Zwischenspeicher-Zuvor-Holen

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R016 Response to examination communication
R082 Change of representative

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

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee