DE102016122297A1 - Mehrfach-Durchlauf-Rendering in einer Bildschirm-Raum-Pipeline - Google Patents

Mehrfach-Durchlauf-Rendering in einer Bildschirm-Raum-Pipeline Download PDF

Info

Publication number
DE102016122297A1
DE102016122297A1 DE102016122297.6A DE102016122297A DE102016122297A1 DE 102016122297 A1 DE102016122297 A1 DE 102016122297A1 DE 102016122297 A DE102016122297 A DE 102016122297A DE 102016122297 A1 DE102016122297 A1 DE 102016122297A1
Authority
DE
Germany
Prior art keywords
pass
state
screen space
graphics
unit
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.)
Pending
Application number
DE102016122297.6A
Other languages
English (en)
Inventor
Ziyad Hakura
Cynthia Allison
Dale Kirkland
Jeffrey Bolz
Yury Uralsky
Johan Alben
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 DE102016122297A1 publication Critical patent/DE102016122297A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/003D [Three Dimensional] image rendering
    • G06T15/005General purpose rendering architectures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00General purpose image data processing
    • G06T1/20Processor architectures; Processor configuration, e.g. pipelining
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/003D [Three Dimensional] image rendering
    • G06T15/10Geometric effects
    • G06T15/40Hidden part removal
    • G06T15/405Hidden part removal using Z-buffer
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/003D [Three Dimensional] image rendering
    • G06T15/50Lighting effects
    • G06T15/503Blending, e.g. for anti-aliasing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/003D [Three Dimensional] image rendering
    • G06T15/50Lighting effects
    • G06T15/80Shading
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T17/00Three dimensional [3D] modelling, e.g. data description of 3D objects
    • G06T17/20Finite element generation, e.g. wire-frame surface description, tesselation

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Graphics (AREA)
  • Geometry (AREA)
  • Software Systems (AREA)
  • Image Generation (AREA)
  • Image Processing (AREA)

Abstract

Eine Mehrfach-Durchlaufeinheit interoperiert mit einem Vorrichtungstreiber, um eine Bildschirm-Raum-Pipeline zu konfigurieren, um mehrere Verarbeitungsdurchläufe mit gepufferten Graphikgrundelementen durchzuführen. Die Mehrfach-Durchlaufeinheit empfängt Grundelementdaten und Zustandsbündel von dem Vorrichtungstreiber. Die Grundelementdaten umfassen ein Graphikgrundelement und eine Grundelementmaske. Die Grundelementmaske gibt die spezifischen Durchläufe an, wann das Graphikgrundelement verarbeitet werden sollte. Das Zustandsbündel umfasst eine oder mehrere Zustandseinstellungen und eine Zustandsmaske. Die Zustandsmaske gibt die spezifischen Durchläufe an, wobei die Zustandseinstellungen angewendet werden sollten. Das Grundelemente und die Zustandseinstellungen sind verschachtelt. Für einen gegebenen Durchlauf extrahiert die Mehrfach-Durchlaufeinheit die verschachtelten Zustandseinstellungen für diesen Durchlauf und konfiguriert die Bildschirm-Raum-Pipeline gemäß diesen Zustandseinstellungen. Die Mehrfach-Durchlaufeinheit extrahiert ebenfalls die verschachtelten Graphikgrundelemente, die in diesem Durchlauf zu verarbeiten sind. Dann bewirkt die Mehrfach-Durchlaufeinheit, dass die Bildschirm-Raum-Pipeline diese Graphikgrundelemente verarbeitet.

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Ausführungsformen der vorliegenden Erfindung betreffen im Allgemeinen die Graphikverarbeitung und genauer gesagt das Mehrfach-Durchlauf-Rendering in einer Bildschirm-Raum-Pipeline.
  • Beschreibung der Verwandten Technik
  • Eine herkömmliche Graphikverarbeitungseinheit (GPU = graphics processing unit) umfasst eine oder mehrere Graphik-Pipelines, die konfiguriert sein können, um eine Geometrie innerhalb einer dreidimensionalen (3D) Szene zu erzeugen. Eine gegebene Graphik-Pipeline kann eine Geometrie in der Graphikszene in einer bestimmten Reihenfolge bezüglich einer Betrachtungsposition zeichnen, von der die Szene letztendlich gerendert wird. Beispielsweise könnte eine Graphik-Pipeline, die dem Hintergrund der Szene zugeordnet ist, Geometrie relativ zu der Betrachtungsposition erzeugen und dann anschließend die dem Vordergrund der Szene zugeordnete Geometrie erzeugen. In diesem Beispiel wird die Szenengeometrie ”von hinten nach vorne” erzeugt. Die Reihenfolge, in der die Geometrie erzeugt wird, wird typischerweise von einer Softwareanwendung gesteuert, die sich auf die GPU für Graphikverarbeitungs-Operationen stützt. Diese Reihenfolge ist in der Technik als eine API(application programming interface)-Reihenfolge bekannt. Die Softwareanwendung könnte beispielsweise ein Videospiel oder ein 3D-Simulationsprogramm sein, das auf dem Computersystem ausgeführt wird, das für das Rendering der Bilder der 3D-Szene zur Anzeige verantwortlich ist.
  • In der Graphik-Pipeline werden, nachdem die Geometrie erzeugt ist, gewöhnlicherweise Hardware- oder Software-Schattierer ausgeführt, um Pixelwerte basierend auf der Geometrie in der 3D-Szene zu erzeugen. Die Schattierer arbeiten typischerweise an der Geometrie gemäß der API-Reihenfolge, mit der die Geometrie anfangs erzeugt wurde. Zurückkehrend zu dem obigen Beispiel würden somit die Schattierer Pixelwerte für den Hintergrund der 3D-Szene erzeugen und dann Pixelwerte für den Vordergrund der 3D-Szene erzeugen. Ineffizienzen können jedoch mit dieser Vorgehensweise entstehen, wenn Elemente des Vordergrunds Abschnitte des Hintergrunds verdecken, wobei diese Abschnitte aus der Betrachtungsposition unsichtbar gemacht werden. Insbesondere tragen jedwede Pixelwerte, die basierend auf den verdeckten Abschnitten der Geometrie erzeugt wurden, nicht zu dem endgültigen gerenderten Bild bei, so dass die Arbeit, die aufgewendet wurde, um diese Pixelwerte zu erzeugen, ungenutzt verloren geht.
  • Eine Lösung dieses Problems ist, die GPU über die Softwareanwendung zu programmieren, um eine als eine ”Z-Vordurchlauf” bekannte Operation durchzuführen. Beim Durchführen einer Z-Vordurchlauf-Operation rendert die Graphik-Pipeline lediglich die Positionen, die der Geometrie zugeordnet sind, und führt dann einen Tiefentest über alle resultierenden Pixel oder Abtastungen durch, um verdeckte Pixel und Abtastungen, die verdeckt sind, zu kennzeichnen. Die Graphik-Pipeline kann dann die verdeckten Pixel oder Abtastungen beim Durchführen nachfolgender Schattierungsoperationen ignorieren. Obwohl bei dieser Vorgehensweise vermieden wird, Schattierungsoperationen durchzuführen, die verdeckte Geometrie betreffen, verlangt diese Vorgehensweise, dass die gesamte 3D-Szene zweimal gerendert wird, was zu zusätzlichem Verarbeitungsmehraufwand führt.
  • Beispielsweise müssen Operationen, wie beispielsweise eine Vertex-Attribut-Abhol-Operation, eine Vertex-Schattierungs-Operation und eine Vertex-Parkettierungs-Operation, zweimal durchgeführt werden, um die Szene für den Z-Vordurchlauf und dann erneut für den nachfolgenden Schattierungsdurchlauf zu rendern. Diese Operationen erfordern zusätzliche Verarbeitungszyklen und konsumieren zusätzliche Leistung. Insbesondere erfordern Vertex-Attribut-Abhol-Operationen im Allgemeinen einen Zugriff auf einen dynamischen Speicher mit wahlfreiem Zugriff (DRAM) außerhalb des Chips, was aus einer Leistungsperspektive recht kostspielig sein kann. Graphikgrundelemente müssen ebenfalls von dem Speicher für jedes Rendering erhalten werden. Das Durchführen derartiger Operationen konsumiert Speicherbandbreite und erhöht ebenfalls die Belastung auf die zentrale Verarbeitungseinheit (CPU), womit sich gleichfalls der Leistungsverbrauch erhöht.
  • Leistungsbetrachtungen werden über alle Arten von Computersystem-Implementierungen immer bedeutsamer, wobei sie jedoch besonders in mobilen Implementierungen bedeutsam sind, da mobile Vorrichtungen begrenzte Leistungsressourcen aufweisen. Daher sollten, soweit möglich, unnötige Operationen, die zu zusätzlichen Verarbeitungszyklen und Leistungsverbrauch führen, wie diejenigen, die oben mit Bezug auf verdeckte Geometrie beschrieben wurden, wo möglich vermieden werden.
  • Was benötigt wird, wie das Vorhergehende veranschaulicht, sind wirksamere Techniken zum Rendern von Graphikszenen, die verdeckte Geometrie umfassen.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Eine Ausführungsform der vorliegenden Erfindung legt ein Graphiksubsystem zur Verarbeitung von Graphikgrundelementen dar, wobei das Subsystem eine Bildschirm-Raum-Pipeline, umfasst, die konfiguriert ist, um Graphikgrundelemente in mehreren Durchläufe zu verarbeiten, und eine Mehrfach-Durchlaufeinheit, die einen Puffer umfasst und konfiguriert ist, um ein erstes Graphikgrundelement aus einem ersten Abschnitt des Puffers zur Verarbeitung in einem ersten Durchlauf durch die Bildschirm-Raum-Pipeline zu extrahieren und das erste Graphikgrundelement aus dem ersten Abschnitt des Puffers zur Verarbeitung in einem zweiten Durchlauf durch die Bildschirm-Raum-Pipeline zu extrahieren.
  • Mindestens ein Vorteil der hier beschriebenen Techniken ist, dass die Bildschirm-Raum-Pipeline konfiguriert werden kann, um verschiedene Z-Durchläufe mit gepufferten Grundelementen durchzuführen und dann anschließend Farbschattierungs-Durchläufe mit diesen gleichen gepufferten Grundelementen durchzuführen. Somit können bestimmte Arten von Graphikszenen korrekt gerendert werden, ohne die Notwendigkeit, Graphikdaten erneut aus dem Speicher abzurufen. Diese Techniken können den Leistungsverbrauch verringern und daher die Batterielebensdauer von mobilen Vorrichtungen verbessern.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Um die Art und Weise anzugeben, in der die oben genannten Merkmale der Erfindung im Detail verstanden werden können, wird eine genauere Beschreibung der Erfindung, die oben kurz zusammengefasst ist, mit Bezug auf Ausführungsformen angegeben, wovon einige in den angefügten Zeichnungen veranschaulicht sind. Es sei jedoch bemerkt, dass die angefügten Zeichnungen lediglich typische Ausführungsformen dieser Erfindung veranschaulichen und daher nicht als ihren Schutzbereich beschränkend zu betrachten sind, da die Erfindung andere gleichermaßen wirksame Ausführungsformen zulassen kann.
  • 1 ist ein Blockdiagramm, das ein Computersystem veranschaulicht, das konfiguriert ist, um ein oder mehrere Aspekte der vorliegenden Erfindung zu implementieren;
  • 2 ist ein Blockdiagramm einer Parallelverarbeitungseinheit, die in dem Parallelverarbeitungssubsystem von 1 umfasst ist, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3A ist ein Blockdiagramm eines allgemeinen Verarbeitungs-Clusters, der in der Parallelverarbeitungseinheit von 2 umfasst ist, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3B ist eine Konzeptansicht einer Graphikverarbeitungs-Pipeline, die in der Parallelverarbeitungseinheit von 2 implementiert werden kann, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 4 ist eine Konzeptansicht einer Cache-Kachel, für die die Graphikverarbeitungs-Pipeline von 3B ausgebildet ist, diese zu erzeugen und zu verarbeiten, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 5 veranschaulicht einen Abschnitt der Graphikverarbeitungs-Pipeline von 3B, die konfiguriert ist, um Grundelementdaten in mehreren Durchläufen zu verarbeiten, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 6A bis 6H sind beispielhafte Veranschaulichungen, wie die Mehrfachdurchlauf(MP)-Einheit von 5 Durchlaufdaten zum Konfigurieren der Bildschirm-Raum-Pipeline von 3B erzeugt, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 7 ist ein Ablaufdiagramm von Verfahrensschritten zum Durchführen mehrerer Durchläufe innerhalb einer Graphikverarbeitungs-Pipeline gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 8 ist ein Ablaufdiagramm von Verfahrensschritten zum Bewahren des Zustands einer Graphikverarbeitungs-Pipeline über mehrere Durchläufe gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 9 ist eine Konzeptdarstellung, wie die MP-Einheit von 5 die Bildschirm-Raum-Pipeline von 3B konfiguriert, um mehrere Durchläufe durchzuführen, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 10 ist eine Konzeptdarstellung, wie die von der MP-Einheit von 5 durchgeführten Operationen die Rendering-Effizienz und die Genauigkeit verbessern können, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 11 ist ein Ablaufdiagramm von Verfahrensschritten zum Konfigurieren einer Graphikverarbeitungs-Pipeline, um mehrere Durchläufe in mehreren Intervallen durchzuführen, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 12 veranschaulicht einen Abschnitt der Bildschirm-Raum-Pipeline von 3B, die konfiguriert ist, um unterschiedliche Durchläufe, die unterschiedliche Cache-Kacheln beinhalten, gleichzeitig durchzuführen, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 13 ist ein Ablaufdiagramm von Verfahrensschritten zur nebenläufigen Verarbeitung mehrerer Cache-Kacheln gemäß einer Ausführungsform der vorliegenden Erfindung; und
  • 14 ist ein Ablaufdiagramm von Verfahrensschritten zum Durchführen einer durchlaufabhängigen Farbschattierung gemäß einer Ausführungsform der vorliegenden Erfindung.
  • DETAILLIERTE BESCHREIBUNG
  • In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt, um ein gründlicheres Verständnis der vorliegenden Erfindung bereitzustellen. Jedoch erkennt ein Fachmann auf diesem Gebiet, dass die vorliegende Erfindung ohne eine oder mehrerer dieser spezifischen Einzelheiten praktiziert werden kann.
  • Systemüberblick
  • 1 ist ein Blockdiagramm, das ein Computersystem 100 veranschaulicht, das konfiguriert ist, um ein oder mehrere Aspekte der vorliegenden Erfindung zu implementieren. Wie gezeigt, umfasst das Computersystem 100, ohne einschränkend zu sein, eine zentrale Recheneinheit (CPU) 102 und einen Systemspeicher 104, die über eine Speicherbrücke 105 und einen Kommunikationspfad 113 mit einem Parallelverarbeitungssubsystem 112 verbunden sind. Die Speicherbrücke 105 ist ferner mit einer I/O(Eingabe/Ausgabe)-Brücke 107 über einen Kommunikationspfad 106 verbunden, und die I/O-Brücke 107 ist ihrerseits mit einem Schalter 116 verbunden.
  • Im Betrieb ist die I/O-Brücke 107 konfiguriert, um Anwendereingabeinformation von Eingabevorrichtungen 108, wie beispielsweise einer Tastatur oder einer Maus, zu erhalten und die Eingabeinformation an die CPU 102 zur Verarbeitung über den Kommunikationspfad 106 und die Speicherbrücke 105 weiterzuleiten. Der Schalter 116 ist konfiguriert, um Verbindungen zwischen der I/O-Brücke 107 und anderen Komponenten des Computersystems 100, wie beispielsweise einem Netzwerkadapter 118 und verschiedenen Zusatzkarten 120 und 121, bereitzustellen.
  • Wie ebenfalls gezeigt, ist die I/O-Brücke 107 mit einer Systemdiskette 114 verbunden, die konfiguriert sein kann, um Inhalt und Anwendungen sowie Daten zur Verwendung durch die CPU 102 und das Parallelverarbeitungssubsystem 112 zu speichern. Allgemein stellt die Systemdiskette 114 nichtflüchtigen Speicherplatz für Anwendungen und Daten bereit und kann fest installierte oder entfernbare Festplattenlaufwerke, Flash-Speichervorrichtungen und CD-(Kompaktdisketten-Nur-Lese-Speicher), DVD(digital versatile disc)-ROM, Blu-ray, HD-DVD (hochauflösende DVD) oder andere magnetische, optische oder elektronische Speichervorrichtungen umfassen. Schließlich können, obwohl nicht explizit gezeigt, weitere Komponenten, wie beispielsweise ein universeller serieller Bus oder andere Portverbindungen, Kompaktdisketten-Laufwerke, DVD(digital versatile disc)-Laufwerke, Filmaufzeichnungsvorrichtungen und dergleichen ebenfalls mit der I/O-Brücke 107 verbunden sein.
  • In verschiedenen Ausführungsformen kann die Speicherbrücke 105 ein Nordbrücken-Chip und die I/O-Brücke 107 ein Südbrücken-Chip sein. Des Weiteren können die Kommunikationspfade 106 und 113 sowie andere Kommunikationspfade innerhalb des Computersystems 100 unter Verwendung beliebiger technisch geeigneter Protokolle implementiert werden, einschließlich, ohne einschränkend zu sein, AGP (beschleunigter Graphikport), HyperTransport oder anderer im Stand der Technik bekannter Bus- oder Punkt-Zu-Punkt-Kommunikationsprotokolle.
  • In einigen Ausführungsformen umfasst das Parallelverarbeitungssubsystem 112 ein Graphiksubsystem, das Pixel an eine Anzeigevorrichtung 110 liefert, die eine beliebige herkömmliche Kathodenstrahlröhre, eine Flüssigkristallanzeige, eine Leuchtdiodenanzeige oder dergleichen sein kann. In derartigen Ausführungsformen umfasst das Parallelverarbeitungssubsystem 112 Schaltungen, die für Graphik- oder Videoverarbeitung optimiert sind, wozu beispielsweise Video-Ausgabeschaltungen gehören. Wie nachfolgend in 2 detaillierter beschrieben, können derartige Schaltungen in einer oder mehreren Parallelverarbeitungseinheiten (PPUs) aufgenommen sein, die in dem Parallelverarbeitungssubsystem 112 umfasst sind. In anderen Ausführungsformen umfasst das Parallelverarbeitungssubsystem 112 Schaltungen, die für eine Verarbeitung für Allgemeinzwecke und/oder für eine Rechenverarbeitung optimiert sind. Derartige Schaltungen können ihrerseits in einer oder mehreren PPUs aufgenommen sein, die in dem Parallelverarbeitungssubsystem 112 umfasst sind und die konfiguriert sind, derartige Operationen für Allgemeinzwecke und/oder Berechnungen auszuführen. In noch anderen Ausführungsformen kann die eine oder mehrere PPUs, die in dem Parallelverarbeitungssubsystem 112 umfasst sind, konfiguriert sein, um Operationen für eine Graphikverarbeitung, eine Verarbeitung für Allgemeinzwecke und eine Verarbeitung von Berechnungen auszuführen. Der Systemspeicher 104 umfasst mindestens einen Vorrichtungstreiber 103, der konfiguriert ist, um die Verarbeitungsoperationen der einen oder der mehreren PPUs in dem Parallelverarbeitungssubsystem 112 zu verwalten.
  • In verschiedenen Ausführungsformen kann das Parallelverarbeitungssubsystem 112 in einem oder mehreren anderen der anderen Elemente von 1 integriert sein, um ein einzelnes System zu bilden. Beispielsweise kann das Parallelverarbeitungssubsystem 112 mit der CPU 102 und anderen Verbindungsschaltungen auf einem einzelnen Chip integriert sein, um ein System auf einem Chip (SoC) zu bilden.
  • Zu beachten ist, dass das hier gezeigte System veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Brücken, der Anzahl an CPUs 102 und der Anzahl an Parallelverarbeitungssubsystemen 112, kann nach Bedarf modifiziert werden. Beispielsweise könnte in einigen Ausführungsformen der Systemspeicher 104 mit der CPU 102 direkt anstatt über die Speicherbrücke 105 verbunden sein, und andere Vorrichtungen würden mit dem Systemspeicher 104 über die Speicherbrücke 105 und die CPU 102 kommunizieren. In anderen alternativen Topologien kann das Parallelverarbeitungssubsystem 112 mit der I/O-Brücke 107 oder direkt mit der CPU 102 anstatt über die Speicherbrücke 105 verbunden sein. In noch anderen Ausführungsformen können die I/O-Brücke 107 und die Speicherbrücke 105 in einem einzelnen Chip integriert sein, anstatt als ein oder mehrere diskrete Bauelemente vorhanden zu sein. Schließlich können in bestimmten Ausführungsformen eine oder mehrere der in 1 gezeigten Komponenten nicht vorhanden sein. Beispielsweise könnte der Schalter 116 weggelassen werden, und der Netzwerkadapter 118 und die Zusatzkarten 120, 121 könnten direkt mit der I/O-Brücke 107 verbunden sein.
  • 2 ist ein Blockdiagramm einer Parallelverarbeitungseinheit (PPU) 202, die in dem Parallelverarbeitungssubsystem 112 von 1 umfasst ist, gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl 2 eine PPU 202 darstellt, wie oben angegeben ist, kann das Parallelverarbeitungssubsystem 112 eine beliebige Anzahl an PPUs 202 umfassen. Wie gezeigt, ist die PPU 202 mit einem lokalen Parallelverarbeitungs(PP)-Speicher 204 gekoppelt. Die PPU 202 und der PP-Speicher 204 können unter Verwendung einer oder mehrerer integrierter Schaltungsvorrichtungen, wie beispielsweise programmierbaren Prozessoren, anwendungsspezifischen integrierten Schaltungen (ASIC) oder Speichervorrichtungen oder in irgendeiner anderen technisch machbaren Art und Weise implementiert sein.
  • In einigen Ausführungsformen umfasst die PPU 202 eine graphische Verarbeitungseinheit (GPU), die konfiguriert sein kann, um eine Graphik-Rendering-Pipeline zu implementieren, um verschiedene Operationen auszuführen, die mit der Erzeugung von Pixeldaten auf der Grundlage von Graphikdaten in Beziehung stehen, die von der CPU 102 und/oder dem Systemspeicher 104 zugeführt werden. Wenn Graphikdaten verarbeitet werden, kann der PP-Speicher 204 als ein Graphikspeicher verwendet werden, der einen oder mehrere herkömmliche Frame-Puffer und bei Bedarf auch ein oder mehrere andere Rendering-Ziele speichert. Unter anderem kann der PP-Speicher 204 verwendet werden, um Pixeldaten zu speichern und zu aktualisieren und endgültige Pixeldaten oder Anzeigeblöcke an die Anzeigevorrichtung 110 zur Anzeige zu leiten. In einigen Ausführungsformen kann die PPU 202 ebenfalls für Allzweckverarbeitung und Rechenoperationen konfiguriert sein.
  • Während des Betriebs ist die CPU 102 der Master-Prozessor des Computersystems 100, der den Betrieb anderer Systemkomponenten steuert und koordiniert. Insbesondere gibt die CPU 102 Befehle aus, die den Betrieb der PPU 202 steuern. In einigen Ausführungsformen schreibt die CPU 102 einen Strom von Befehlen für die PPU 202 in eine Datenstruktur (in 1 oder 2 nicht explizit gezeigt), die im Systemspeicher 104, im PP-Speicher 204 oder an einer anderen Speicherstelle lokalisiert sein kann, auf die sowohl die CPU 102 als auch die PPU 202 zugreifen können. Ein Zeiger auf die Datenstruktur wird in einen Schiebepuffer geschrieben, um die Verarbeitung des Stroms von Befehlen in der Datenstruktur einzuleiten. Die PPU 202 liest Befehlsströme aus dem Schiebepuffer aus und führt dann Befehle asynchron relativ zu der Betriebsweise der CPU 102 aus. In Ausführungsformen, in denen mehrere Schiebepuffer erzeugt werden, können Prioritäten für die Ausführung für jeden Schiebepuffer durch ein Anwendungsprogramm über den Vorrichtungstreiber 103 spezifiziert werden, um die Disponierung der unterschiedlichen Schiebepuffer zu steuern.
  • Wie ebenfalls gezeigt, umfasst die PPU 202 eine I/O(Eingabe/Ausgabe)-Einheit 205, die mit dem Rest des Computersystems 100 über den Kommunikationspfad 113 und die Speicherbrücke 105 kommuniziert. Die I/O-Einheit 205 erzeugt Pakete (oder andere Signale) zur Übertragung auf dem Kommunikationspfad 113 und empfängt ebenfalls alle ankommenden Pakete (oder andere Signale) von dem Kommunikationspfad 113 und leitet die ankommenden Pakete zu geeigneten Komponenten der PPU 202. Beispielsweise können Befehle, die mit Verarbeitungsaufgaben in Bezug stehen, an eine Host-Schnittstelle 206 geleitet werden, während Befehle, die mit Speicheroperationen in Verbindung stehen (beispielsweise Auslesen aus dem und Schreiben in den PP-Speicher 204) an eine Kreuzungseinheit 210 gesendet werden. Die Host-Schnittstelle 206 liest jeden Schiebepuffer aus und überträgt den in dem Schiebepuffer gespeicherten Befehlsstrom an einen Frontbereich 212.
  • Wie zuvor in Verbindung mit 1 erwähnt, kann die Verbindung der PPU 202 mit dem Rest des Computersystems 100 unterschiedlich sein. In einigen Ausführungsformen ist das Parallelverarbeitungssubsystem 112, das mindestens eine PPU 202 umfasst, als eine Zusatzkarte implementiert, die in einen Erweiterungssteckplatz des Computersystems 100 eingesetzt werden kann. In anderen Ausführungsformen kann die PPU 202 auf einem einzelnen Chip mit einer Busbrücke, wie beispielsweise der Speicherbrücke 105 oder der I/O-Brücke 107, integriert sein. In noch anderen Ausführungsformen können einige oder alle der Elemente der PPU 202 zusammen mit der CPU 102 in einer einzelnen integrierten Schaltung oder einem System auf Chip (SoC) umfasst sein.
  • Im Betrieb überträgt der Frontbereich 212 Verarbeitungsaufgaben, die von der Host-Schnittstelle 206 empfangen werden, an eine Arbeitsverteilungseinheit (nicht gezeigt) in der Aufgaben/Arbeits-Einheit 207. Die Arbeitsverteilungseinheit empfängt Zeiger auf Verarbeitungsaufgaben, die als Aufgaben-Metadaten (TMD) codiert und im Speicher gespeichert sind. Die Zeiger auf die TMD sind in einem Befehlsstrom umfasst, der als ein Schiebepuffer gespeichert ist und durch die Frontbereichseinheit 212 von der Host-Schnittstelle 206 empfangen wird. Verarbeitungsaufgaben, die als TMD codiert sein können, umfassen Indizes, die den zu verarbeitenden Daten zugeordnet sind, sowie Zustandsparameter und Befehle, die festlegen, wie die Daten zu verarbeiten sind. Beispielsweise können die Zustandsparameter und die Befehle das Programm festlegen, das an den Daten auszuführen ist. Die Aufgaben/Arbeits-Einheit 207 empfängt Aufgaben von dem Frontbereich 212 und stellt sicher, dass die GPCs 208 in einen gültigen Zustand konfiguriert werden, bevor die von jedem Satz der TMD spezifizierte Verarbeitungsaufgabe eingeleitet wird. Es kann eine Priorität für jeden Satz an TMD spezifiziert werden, die verwendet wird, um die Ausführung der Verarbeitungsaufgaben zu disponieren. Verarbeitungsaufgaben können ferner aus dem Verarbeitungs-Cluster-Array 230 empfangen werden. Optional können die TMD einen Parameter umfassen, der steuert, ob die TMD dem Anfang oder dem Ende einer Liste an Verarbeitungsaufgaben (oder einer Liste aus Zeigern auf die Verarbeitungsaufgaben) hinzugefügt werden, wodurch eine weitere Steuerebene über die Ausführungspriorität bereitgestellt wird.
  • Die PPU 202 implementiert vorteilhafterweise eine hoch parallele Verarbeitungsarchitektur auf der Grundlage eines Verarbeitungs-Cluster-Arrays 230, das einen Satz aus C allgemeinen Verarbeitungs-Clustern (GPCs) 208 umfasst, wobei C ≥ 1 ist. Jeder GPC 208 ist in der Lage, eine große Anzahl (beispielsweise Hunderte oder Tausende) von Threads gleichzeitig auszuführen, wobei jeder Thread eine Instanz eines Programms ist. In verschiedenen Anwendungen können unterschiedliche GPCs 208 zur Verarbeitung von unterschiedlichen Arten von Programmen oder zum Durchführen unterschiedlicher Arten von Berechnungen zugeteilt werden.
  • Die Zuteilung von GPCs 208 kann abhängig von der Arbeitslast unterschiedlich sein, die sich für jede Art von Programm oder Berechnung ergibt.
  • Eine Speicherschnittstelle 214 umfasst einen Satz aus D Partitionseinheiten 215, wobei D ≥ 1 ist. Jede Partitionseinheit 215 ist mit einem oder mehreren dynamischen Speichern mit wahlfreiem Zugriff (DRAM) 220 verbunden, die in dem PP-Speicher 204 liegen. In einer Ausführungsform ist die Anzahl an Partitionseinheiten 215 gleich der Anzahl an DRAMs 220, und jede Partitionseinheit 215 ist mit einem anderen DRAM 220 verbunden. In anderen Ausführungsformen unterscheidet sich die Anzahl an Partitionseinheiten 215 von der Anzahl an DRAMs 220. Fachleute werden erkennen, dass ein DRAM 220 durch eine beliebige andere technisch geeignete Speichervorrichtung ersetzt werden kann. Im Betrieb können verschiedene Rendering-Ziele, wie beispielsweise Texturzuordnungen und Frame-Puffer, über die DRAMs 220 hinweg gespeichert werden, wodurch es den Partitionseinheiten 215 ermöglicht wird, Abschnitte jedes Rendering-Ziels parallel zu beschreiben, um die verfügbare Bandbreite des PP-Speichers 204 effizient zu nutzen.
  • Ein gegebener GPC 208 kann Daten verarbeiten, die in einen oder mehrere der DRAMs 220 in dem PP-Speicher 204 zu schreiben sind. Die Kreuzungseinheit 210 ist konfiguriert, um die Ausgabe jedes GPC 208 an den Eingang einer beliebigen Partitionseinheit 215 oder an einen anderen GPC 208 zur weiteren Verarbeitung zu leiten. Die GPCs 208 kommunizieren mit der Speicherschnittstelle 214 über die Kreuzungseinheit 210, um aus verschiedenen DRAMs 220 zu lesen oder in diese zu schreiben. In einer Ausführungsform weist die Kreuzungseinheit 210 eine Verbindung zu der I/O-Einheit 205 zusätzlich zu einer Verbindung mit dem PP-Speicher 204 über die Speicherschnittstelle 214 auf, wodurch die Verarbeitungskerne in den unterschiedlichen GPCs 208 in die Lage versetzt werden, mit dem Systemspeicher 104 oder mit einem anderen Speicher, der nicht lokal zu der PPU 202 ist, zu kommunizieren. In der Ausführungsform von 2 ist die Kreuzungseinheit 210 direkt mit der I/O-Einheit 205 verbunden. In verschiedenen Ausführungsformen kann die Kreuzungseinheit 210 virtuelle Kanäle verwenden, um Verkehrsströme zwischen den GPCs 208 und den Partitionseinheiten 215 zu trennen.
  • Die GPCs 208 können ihrerseits so programmiert sein, dass sie Verarbeitungsaufgaben ausführen, die mit einer weiten Vielfalt von Anwendungen in Beziehung stehen, einschließlich, ohne einschränkend zu sein, lineare und nicht-lineare Datentransformationen, die Filterung von Video- und/oder Audiodaten, Modellierungsoperationen (beispielsweise die Anwendung physikalischer Gesetze zur Bestimmung von Position, Geschwindigkeit und anderen Attributen von Objekten), Bild-Rendering-Operationen (beispielsweise Programme zur Parkettierung-Schattierung, Vertex-Schattierung, Geometrie-Schattierung und/oder Pixel/Fragment-Schattierung), allgemeine Berechnungsoperationen, usw. Im Betrieb ist die PPU 202 konfiguriert, um Daten von dem Systemspeicher 104 und/oder dem PP-Speicher 204 an eine oder mehrere chipinterne Speichereinheiten zu übertragen, die Daten zu verarbeiten und Ergebnisdaten zurück in den Systemspeicher 104 und/oder den PP-Speicher 204 zu schreiben. Auf die Ergebnisdaten kann dann von anderen Systemkomponenten zugegriffen werden, wozu die CPU 102, eine weitere PPU 202 innerhalb des Parallelverarbeitungssubsystems 112 oder eines weiteren Parallelverarbeitungssubsystems 112 in dem Computersystem 100 gehören.
  • Wie zuvor bemerkt, kann eine beliebige Anzahl an PPUs 202 in einem Parallelverarbeitungssubsystem 112 umfasst sein. Beispielsweise können mehrere PPUs 202 in einer einzelnen Zusatzkarte bereitgestellt werden, oder es können mehrere Zusatzkarten mit dem Kommunikationspfad 113 verbunden werden, oder eine oder mehrere der PPUs 202 können in einem Brückenchip integriert sein. Die PPUs 202 in einem Mehrfach-PPU-System können identisch oder unterschiedlich voneinander sein. Beispielsweise können unterschiedliche PPUs 202 eine unterschiedliche Anzahl an Verarbeitungskernen und/oder unterschiedliche Größen des PP-Speichers 204 aufweisen. In Ausführungsformen, in denen mehrere PPUs 202 vorhanden sind, können diese PPUs parallel betrieben werden, um Daten mit einem höheren Durchsatz zu verarbeiten, als dies mit einer einzelnen PPU 202 möglich wäre. Systeme, in denen eine oder mehrere PPUs 202 umfasst sind, können in einer Vielzahl von Konfigurationen und Formfaktoren implementiert werden, wozu gehören, ohne einschränkend zu sein, Tischrechner, Mobilrechner, handgehaltene Personal-Computer oder andere handgehaltene Vorrichtungen, Server, Arbeitsplatzrechner, Spielekonsolen, eingebettete Systeme und dergleichen.
  • 3A ist ein Blockdiagramm eines GPC 208, der in der PPU 202 von 2 umfasst ist, gemäß einer Ausführungsform der vorliegenden Erfindung. Im Betrieb kann der GPC 208 konfiguriert sein, um eine große Anzahl an Threads parallel auszuführen, um Operationen für Graphik, allgemeine Verarbeitung und/oder Berechnungen durchzuführen. Wie hier verwendet, bezeichnet ein „Thread” eine Instanz eines bestimmten Programms, das an einem bestimmten Satz an Eingangsdaten ausgeführt wird. In einigen Ausführungsformen werden SIMD(Single Instruction, Multiple Data)-Befehlsausgabetechniken eingesetzt, um eine parallele Ausführung einer großen Anzahl an Threads zu unterstützen, ohne mehrere unabhängige Befehlseinheiten bereitzustellen. In anderen Ausführungsformen werden SIMT(Single Instruction, Multiple Threads)-Techniken verwendet, um die parallele Ausführung einer großen Anzahl an allgemein synchronisierten Threads unter Verwendung einer gemeinsamen Befehlseinheit zu unterstützen, die konfiguriert ist, um Befehle an einen Satz von Verarbeitungseinheiten innerhalb des GPC 208 auszugeben. Anders als ein SIMD-Ausführungsregime, in welchem alle Verarbeitungseinheiten typischerweise identische Befehle ausführen, ermöglicht eine SIMT-Ausführung, dass unterschiedliche Threads leichter effizienten divergenten Ausführungspfaden durch ein gegebenes Programm folgen. Fachleute werden erkennen, dass ein SIMD-Verarbeitungsregime eine funktionale Teilmenge eines SIMT-Verarbeitungsregimes darstellt.
  • Der Betrieb des GPC 208 wird über einen Pipeline-Verwalter 305 gesteuert, der Verarbeitungsaufgaben, die von einer Arbeitsverteilungseinheit (nicht gezeigt) in der Aufgaben/Arbeits-Einheit 207 empfangen werden, an einen oder mehrere Datenstrom-Multiprozessoren (SMs) 310 verteilt. Der Pipeline-Verwalter 305 kann ebenfalls konfiguriert sein, um eine Arbeitsverteilungs-Kreuzungseinheit 330 durch Spezifizieren von Zielen für verarbeitete Daten, die von den SM 310 ausgegeben werden, zu steuern.
  • In einer Ausführungsform umfasst der GPC 208 einen Satz M von SMs 310, wobei M ≥ 1 ist. Ferner umfasst jeder SM 310 einen Satz von Funktionsausführungseinheiten (nicht gezeigt), wie beispielsweise Ausführungseinheiten und Lade-Speicher-Einheiten. Die Verarbeitung von Operationen, die für jedwede der Funktionsausführungseinheiten speziell sind, kann als Pipeline betrieben bzw. parallel ausgeführt werden, wodurch es möglich ist, dass ein neuer Befehl zur Ausführung ausgegeben werden kann, bevor die Ausführung eines vorhergehenden Befehls abgeschlossen ist. Es kann eine beliebige Kombination von Funktionsausführungseinheiten in einem gegebenen SM 310 bereitgestellt werden. Die Funktionsausführungseinheiten können in verschiedenen Ausführungsformen konfiguriert sein, um eine Vielfalt unterschiedlicher Operationen zu unterstützen, wozu Ganzzahl- und Fließkommaarithmetik (beispielsweise Addition und Multiplikation), Vergleichsoperationen, boolesche Operationen (UND, ODER, EXKLUSIV ODER), Bit-Verschiebung und Berechnung verschiedener algebraischer Funktionen (beispielsweise ebene Interpolation, trigonometrische, exponentielle und logarithmische Funktionen usw.) gehören. Vorteilhafterweise kann die gleiche Funktionsausführungseinheit konfiguriert sein, um unterschiedliche Operationen auszuführen.
  • Im Betrieb ist jeder SM 310 konfiguriert, um eine oder mehrere Threadgruppen zu verarbeiten. Wie hier verwendet, bedeutet eine „Threadgruppe” oder „Wölbung” eine Gruppe von Threads, die gleichzeitig das gleiche Programm an unterschiedlichen Eingangsdaten ausführen, wobei einem Thread der Gruppe eine unterschiedliche Ausführungseinheit innerhalb eines SM 310 zugewiesen wird. Eine Threadgruppe kann weniger Threads umfassen als es der Anzahl an Ausführungseinheiten innerhalb des SM 310 entspricht, in welchem Falle einige der Ausführungseinheiten während Zyklen untätig sein können, wenn diese Threadgruppe verarbeitet wird. Eine Threadgruppe kann auch mehr Threads umfassen, als dies der Anzahl an Ausführungseinheiten innerhalb des SM 310 entspricht, wobei sich in diesem Fall die Verarbeitung über aufeinander folgende Taktzyklen erstrecken kann. Da jeder SM 310 bis zu G Threadgruppen nebenläufig unterstützen kann, folgt, dass bis zu G·M Threadgruppen in dem GPC 208 gleichzeitig ausgeführt werden können.
  • Außerdem kann eine Mehrzahl von in Beziehung stehender Threadgruppen gleichzeitig in einem SM 310 aktiv sein (in unterschiedlichen Phasen der Ausführung). Diese Ansammlung an Threadgruppen wird hier als ein „kooperatives Thread-Array” („CTA”) oder als „Thread-Array” bezeichnet. Die Größe eines bestimmten CTA ist gleich m·k, wobei k die Anzahl an gleichzeitig ausgeführten Threads in einer Threadgruppe ist, die typischerweise ein ganzzahliges Vielfaches der Anzahl an Ausführungseinheiten innerhalb des SM 310 ist, und m die Anzahl an Threadgruppen ist, die gleichzeitig in dem SM 310 aktiv sind.
  • Obwohl in 3A nicht gezeigt, umfasst jeder SM 310 einen Cache-Speicher der Ebene eins (L1) oder verwendet Platz in einem entsprechenden L1-Cache-Speicher außerhalb des SM 310, um unter anderem Lade- und Speicher-Operationen zu unterstützen, die von den Ausführungseinheiten durchgeführt werden. Jeder SM 310 weist ferner Zugriff auf Cache-Speicher der Ebene zwei (L2) (nicht gezeigt) auf, die gemeinsam von allen GPCs 208 in der PPU 202 verwendet werden. Die L2-Cache-Speicher können verwendet werden, um Daten zwischen Threads auszutauschen. Schließlich können die SMs 310 auch Zugriff auf einen chipexternen „globalen” Speicher aufweisen, der den PP-Speicher 204 und/oder den Systemspeicher 104 umfassen kann. Ferner ist zu beachten, dass ein beliebiger Speicher außerhalb der PPU 202 als globaler Speicher verwendet werden kann. Wie außerdem in 3A gezeigt ist, kann ein Cache-Speicher der Ebene eins-Punkt-fünf (L1.5) in dem GPC 208 verwendet werden und konfiguriert sein, um aus dem Speicher über die Speicherschnittstelle 214 von den SM 310 angeforderte Daten zu empfangen und zu halten. Derartige Daten können umfassen, ohne einschränkend zu sein, Anweisungen, gleichförmige Daten und konstante Daten. In Ausführungsformen mit mehreren SMs 310 innerhalb des GPC 208 können die SM 310 vorteilhafterweise gemeinsame Befehle und Daten, die in dem L1.5-Cache-Speicher 335 zwischengespeichert sind, gemeinsam nutzen.
  • Jeder GPC 208 kann eine zugeordnete Speicherverwaltungseinheit (MMU) 320 aufweisen, die konfiguriert ist, um virtuelle Adressen auf physikalische Adressen abzubilden. In verschiedenen Ausführungsformen kann die MMU 320 entweder in dem GPC 208 oder in der Speicherschnittstelle 214 liegen. Die MMU 320 umfasst einen Satz aus Seitentabelleneinträgen (PTE), die verwendet werden, um eine virtuelle Adresse in eine physische Adresse einer Kachel oder einer Speicherseite abzubilden und optional einem Cache-Zeilenindex zuzuordnen. Die MMU 320 kann Adressen-Translations-Nebenschaupuffer (TLB) oder Cache-Speicher umfassen, die in den SMs 310 in einem oder mehreren L1-Cache-Speichern oder in dem GPC 208 liegen können.
  • Der GPC 208 kann in Graphik- und Rechenanwendungen konfiguriert sein, so dass jeder SM 310 mit einer Textureinheit 315 zum Durchführen von Texturabbildungsanforderungen, wie beispielsweise der Bestimmung von Texturabtastpositionen, dem Auslesen von Texturdaten und der Filterung von Texturdaten, gekoppelt ist.
  • Im Betrieb sendet jeder SM 310 eine verarbeitete Aufgabe an die Arbeitsverteilungs-Kreuzungseinheit 330, um die verarbeitete Aufgabe einem weiteren GPC 208 zur Weiterverarbeitung bereitzustellen, oder um die verarbeitete Aufgabe in einem L2-Cache-Speicher (nicht gezeigt), dem Parallelverarbeitungsspeicher 204 oder dem Systemspeicher 104 über die Kreuzungseinheit 210 zu speichern. Außerdem ist eine Vor-Rasteroperationen(PreROP)-Einheit 325 konfiguriert, um Daten von dem SM 310 zu empfangen, Daten einer oder mehreren Rasteroperations(ROP)-Einheiten in den Partitionseinheiten 215 zuzuführen, Optimierungen zur Farbmischung durchzuführen, Pixel-Farbdaten zu organisieren und Adressenübersetzungen durchzuführen.
  • Zu beachten ist, dass die hier beschriebene Kernarchitektur veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Unter anderem kann eine beliebige Anzahl an Verarbeitungseinheiten, wie beispielsweise SMs 310, Textureinheiten 315 oder Vor-ROP-Einheiten 325 in dem GPC 208 umfasst sein. Wie ferner oben in Verbindung mit 2 beschrieben, kann die PPU 202 eine beliebige Anzahl an GPCs 208 umfassen, die konfiguriert sind, um funktionsmäßig zueinander ähnlich zu sein, so dass das Ausführungsverhalten nicht davon abhängt, welcher GPC 208 eine bestimmte Verarbeitungsaufgabe erhält. Ferner arbeitet jeder GPC 208 unabhängig von den anderen GPCs 208 in der PPU 202, um Aufgaben für ein oder mehrere Anwendungsprogramme auszuführen. Im Hinblick auf das Vorhergehende erkennen Fachleute, dass die in 1 3A beschriebene Architektur in keiner Weise den Schutzumfang der vorliegenden Erfindung einschränkt.
  • Graphik-Pipeline-Architektur
  • 3B ist ein Konzeptdiagramm einer Graphikverarbeitungs-Pipeline 350, die in der PPU 202 von 2 implementiert werden kann, gemäß einer Ausführungsform der vorliegenden Erfindung implementiert werden kann. Wie gezeigt, umfasst die Graphikverarbeitungs-Pipeline 350, ohne einschränkend zu sein, eine Grundelement-Verteilereinheit (PD) 355; eine Vertex-Attributabholeinheit (VAF) 360; eine Vertex-, Parkettierung-, Geometrie-Verarbeitungseinheit (VTG) 365; eine Darstellungsfeldskalier-, Auswahl- und Schneide-Einheit (VPC) 370; eine Kacheleinheit 375, eine Einrichtungseinheit (Setup) 380, eine Rastereinheit (Raster) 385; eine Fragment-Verarbeitungseinheit, auch als eine Pixel-Schattierungseinheit (PS) 390 bezeichnet, und eine Raster-Operationen-Einheit (ROP) 395.
  • Die PD 355 sammelt Vertex-Daten, die Oberflächen höherer Ordnung, graphischen Grundelementen und dergleichen zugeordnet sind, aus dem Frontbereich 212 und sendet die Vertex-Daten an die VAF 360.
  • Die VAF 360 ruft Vertex-Attribute, die jedem der ankommenden Vertices zugeordnet sind, aus dem gemeinsam benutzten Speicher ab und speichert die Vertex-Daten zusammen mit den zugeordneten Vertex-Attributen in dem gemeinsam benutzten Speicher.
  • Die VTG 365 ist eine programmierbare Ausführungseinheit, die konfiguriert ist, um Vertex-Schattierungsprogramme, Parkettierungs-Programme und Geometrieprogramme auszuführen. Diese Programme verarbeiten Vertex-Daten und Vertex-Attribute, die aus der VAF 360 empfangen werden, und erzeugen graphische Grundelemente, wie beispielsweise Farbwerte, Vektoren der Oberflächennormalen und Transparenzwerte an jedem Vertex für die graphischen Grundelemente zur weiteren Verarbeitung innerhalb der Graphikverarbeitungs-Pipeline 350. Obwohl nicht explizit gezeigt, kann die VTG 365 in einigen Ausführungsformen eine oder mehrere der folgenden Einheiten umfassen: eine Vertex-Verarbeitungseinheit, eine Parkettierung-Initialisierungs-Verarbeitungseinheit, eine Aufgabenerzeugungseinheit, eine Aufgabenverteilungseinheit, eine Topologie-Erzeugungseinheit, eine Parkettierung-Verarbeitungseinheit und eine Geometrie-Verarbeitungseinheit. Die Vertex-Verarbeitungseinheit ist eine programmierbare Ausführungseinheit, die konfiguriert ist, um Vertex-Schattierungsprogramme, Beleuchtung und Transformation von Vertex-Daten, wie sie von den Vertex-Schattierungsprogrammen angegeben werden, zu verarbeiten. Beispielsweise kann die Vertex-Verarbeitungseinheit programmiert sein, um die Vertex-Daten von einer objektbasierten Koordinatendarstellung (Objektraum) in ein Koordinatensystem mit alternativer Basis, wie beispielsweise einen Welt-Raum oder in einen Raum mit normierten Vorrichtungskoordinaten (NDC) umzuwandeln. Die Vertex-Verarbeitungseinheit kann Vertex-Daten und Vertex-Attribute auslesen, die in einem gemeinsam benutzten Speicher von der VAF gespeichert wurden, und kann die Vertex-Daten und die Vertex-Attribute verarbeiten. Die Vertex-Verarbeitungseinheit 415 speichert verarbeitete Vertices in einem gemeinsam benutzten Speicher.
  • Die Parkettierung-Initialisierungs-Verarbeitungseinheit ist eine programmierbare Ausführungseinheit, die konfiguriert ist, um Parkettierungs-Initialisierungs-Schattierungsprogramme auszuführen. Die Parkettierung-Initialisierungs-Verarbeitungseinheit verarbeitet Vertices, die von der Vertex-Verarbeitungseinheit erzeugt wurden, und erzeugt graphische Grundelemente, die als Flecken (patches) bekannt sind. Die Parkettierung-Initialisierungs-Verarbeitungseinheit erzeugt ferner verschiedene Fleckenattribute. Die Parkettierung-Initialisierungs-Verarbeitungseinheit speichert dann die Fleckendaten und Fleckenattribute in dem gemeinsam benutzten Speicher. In einigen Ausführungsformen kann das Parkettierung-Initialisierungs-Schattierungsprogramm eine Hüllenschattierung oder eine Parkettierungs-Steuer-Schattierung genannt werden.
  • Die Aufgabenerzeugungseinheit ruft Daten und Attribute für Vertices und Flecken aus dem gemeinsam benutzten Speicher ab. Die Aufgabenerzeugungseinheit erzeugt Aufgaben zur Verarbeitung der Vertices und Flecken für die Verarbeitung durch spätere Stufen in der Graphikverarbeitungs-Pipeline 350.
  • Die Aufgabenverteilungseinheit verteilt die von der Aufgabenerzeugungseinheit erzeugten Aufgaben um. Die von den verschiedenen Instanzen des Vertex-Schattierungsprogramms und dem Parkettierung-Initialisierungsprogramm erzeugten Aufgaben können sich zwischen einer Graphikverarbeitungs-Pipeline 350 und einer anderen deutlich variieren. Die Aufgabenverteilungseinheit verteilt diese Aufgaben derart um, dass jede Graphikverarbeitungs-Pipeline 350 während späterer Pipeline-Stufen ungefähr die gleiche Arbeitslast aufweist.
  • Die Topologie-Erzeugungseinheit ruft von der Aufgabenverwaltungseinheit verteilte Aufgaben ab. Die Topologie-Erzeugungseinheit indiziert die Vertices, einschließlich Flecken zugeordneter Vertices, und berechnet (U, V) Koordinaten für Parkettierungs-Vertices und die Indizes, welche die parkettartig verteilten Vertices verbinden, um graphische Grundelemente zu bilden. Die Topologie-Erzeugungseinheit speichert dann die indizierten Vertices in dem gemeinsam benutzten Speicher.
  • Die Parkettierung-Verarbeitungseinheit ist eine programmierbare Ausführungseinheit, die konfiguriert ist, um Parkettierung-Schattierungsprogramme auszuführen. Die Parkettierung-Verarbeitungseinheit liest Eingangsdaten aus dem gemeinsam benutzten Speicher und schreibt Ausgangsdaten in diesen hinein. Diese Ausgangsdaten in dem gemeinsam benutzten Speicher werden an die nächste Schattierungsstufe, d. h. die Geometrie-Verarbeitungseinheit 445, als Eingangsdaten weitergegeben. In einigen Ausführungsformen kann das Parkettierung-Schattierungsprogramm als eine Bereichsschattierungseinheit oder eine Parkettierung-Bewertungs-Schattierungseinheit bezeichnet werden.
  • Die Geometrie-Verarbeitungseinheit ist eine programmierbare Ausführungseinheit, die konfiguriert ist, um Geometrie-Schattierungsprogramme auszuführen, wodurch graphische Grundelemente transformiert werden. Es werden Vertices gruppiert, um graphische Grundelemente für die Verarbeitung zu bilden, wobei graphische Grundelemente Dreiecke, Liniensegmente, Punkte und dergleichen umfassen. Beispielsweise kann die Geometrie-Verarbeitungseinheit so programmiert sein, dass die graphischen Grundelemente in ein oder mehrere neue graphische Grundelemente unterteilt werden, und um Parameter zu berechnen, wie beispielsweise Koeffizienten für eine Ebenengleichung, die verwendet werden, um die neuen graphischen Grundelemente in Raster einzuteilen.
  • Die Geometrie-Verarbeitungseinheit sendet die Parameter und die Vertices, die die neuen graphischen Grundelemente angeben, an die VPC 370. Die Geometrie-Verarbeitungseinheit kann Daten auslesen, die in dem gemeinsam benutzten Speicher gespeichert sind, um diese bei der Verarbeitung der Geometriedaten zu verwenden. Die VPC 370 führt Schneidevorgänge, Auswahlvorgänge, perspektivische Korrekturen und eine Transformation des Darstellungsfeldes durch, um zu ermitteln, welche graphischen Grundelemente in dem schließlich erzeugten Bild potentiell betrachtet werden können, und welche graphischen Grundelemente potentiell nicht betrachtet werden können. Die VPC 370 sendet dann die verarbeiteten graphischen Grundelemente an die Kacheleinheit 375.
  • Die Kacheleinheit 375 ist eine Vorrichtung zum Sortieren graphischer Grundelemente, die zwischen einer Welt-Raum-Pipeline 352 und einer Bildschirm-Raum-Pipeline 354 liegt, wie hier näher beschrieben. Graphische Grundelemente werden in der Welt-Raum-Pipeline 352 verarbeitet und anschließend an die Kacheleinheit 375 übertragen. Der Bildschirm-Raum wird in Cache-Kacheln unterteilt, wobei jede Cache-Kachel einem Bereich des Bildschirm-Raums zugeordnet ist. Für jedes graphische Grundelement kennzeichnet die Kacheleinheit 375 den Satz an Cache-Kacheln, die einen Schnittpunkt mit den graphischen Grundelementen aufweisen, wobei dieser Vorgang als „Tiling” bezeichnet wird. Nachdem eine gewisse Anzahl an graphischen Grundelementen in Kacheln unterteilt ist, verarbeitet die Kacheleinheit 375 die graphischen Grundelemente auf Ebene von Cache-Kacheln, wobei graphische Grundelemente, die zu einer bestimmten Cache-Kachel gehören, an die Einrichtungseinheit 380 übertragen werden. Die Kreuzungseinheit 375 überträgt graphische Grundelemente an die Einrichtungseinheit 380, wobei eine einzige Cache-Kachel pro Zeiteinheit übergeben wird. Graphische Grundelemente, die mehrere Cache-Kacheln schneiden, werden typischerweise einmal in der Welt-Raum-Pipeline 352 verarbeitet, wobei sie jedoch dann mehrere Male an die Bildschirm-Raum-Pipeline 354 übertragen werden.
  • Eine derartige Technik verbessert die Cache-Speicherlokalität während der Verarbeitung in der Bildschirm-Raum-Pipeline 354, wobei mehrere Speicheroperationen, die einer ersten Cache-Kachel zugeordnet sind, auf eine Region der L2-Cache-Speicher zugreifen, oder auf einen anderen technisch machbaren Cache-Speicher, der während der Bildschirm-Raum-Verarbeitung der ersten Cache-Kachel resident bleiben kann. Sobald die graphischen Grundelemente, die der ersten Cache-Kachel zugeordnet sind, von der Bildschirm-Raum-Pipeline 354 verarbeitet sind, kann der Abschnitt der L2-Cache-Speicher, der zu der ersten Cache-Kachel gehört, gelöscht werden und die Kacheleinheit kann graphische Grundelemente, die zu einer zweiten Cache-Kachel gehören, übertragen. Mehrere Speicheroperationen, die einer zweiten Cache-Kachel zugeordnet sind, können dann auf das Gebiet der L2-Cache-Speicher zugreifen, die während der Bildschirm-Raum-Verarbeitung der zweiten Cache-Kachel resident bleiben. Folglich kann der gesamte Speicherverkehr zu den L2-Cache-Speichern und zu den Rendering-Zielen verringert werden. In einigen Ausführungsformen wird die Welt-Raum-Berechnung für ein gegebenes graphisches Grundelement einmal ausgeführt, unabhängig von der Anzahl an Cache-Kacheln in dem Bildschirm-Raum, die das graphische Grundelement schneiden.
  • Die Einrichtungseinheit 380 empfängt Vertex-Daten von der VPC 370 über die Kreuzungseinheit 375 und berechnet Parameter, die dem graphischen Grundelement zugeordnet sind, wozu gehören, ohne einschränkend zu sein, Kantengleichungen, Teilebenen- Gleichungen und Tiefebenen-Gleichungen. Die Einrichtungseinheit 380 überträgt dann die verarbeiteten graphischen Grundelemente an die Rastereinheit 385.
  • Die Rastereinheit 385 wandelt durch Abtastung die neuen graphischen Grundelemente um und überträgt Fragmente und Abdeckungsdaten an die Pixel-Schattierungseinheit 390. Des Weiteren kann die Rastereinheit 385 konfiguriert sein, um eine z-Auswahl und andere z-basierte Optimierungen auszuführen.
  • Die Pixel-Schattierungseinheit 390 ist eine programmierbare Ausführungseinheit, die konfiguriert ist, um Fragment-Schattierungsprogramme auszuführen, die Fragmente transformiert, die von der Rastereinheit 385 erhalten werden, wie sie von den Fragment-Schattierungsprogrammen spezifiziert werden. Fragment-Schattierungsprogramme können Fragmente mit einer Granularität auf Pixelebene schattieren, wobei derartige Schattierungsprogramme Pixel-Schattierungsprogramme genannt werden können. Alternativ können Fragment-Schattierungsprogramme mit einer Granularität auf Abtastebene schattieren, wobei jedes Pixel mehrere Abtastwerte umfasst und wobei jeder Abtastwert einen Abschnitt eines Pixels darstellt. Alternativ können Fragment-Schattierungsprogramme Fragmente mit einer beliebigen anderen technisch machbaren Granularität schattieren, wobei dies von der programmierten Abtastrate abhängig ist.
  • In verschiedenen Ausführungsformen kann die Fragment-Verarbeitungseinheit 460 programmiert sein, um Operationen, wie beispielsweise perspektivische Korrektur, Texturzuordnungen, Schattierung, Mischung und dergleichen durchzuführen, um schattierte Fragmente zu erzeugen, die an die ROP (raster operation pipeline) 395 übertragen werden. Die Pixel-Schattierungseinheit 300 kann Daten lesen, die in dem gemeinsam benutzten Speicher gespeichert sind.
  • Die ROP 395 ist eine Verarbeitungseinheit, die Raster-Operationen, wie beispielsweise Schablonen, z-Test, Mischung und dergleichen durchführt und die Pixeldaten als verarbeitete Graphikdaten zur Speicherung im Graphikspeicher über die Speicherschnittstelle 214 überträgt, wobei der Graphikspeicher typischerweise als ein oder mehrere Rendering-Ziele strukturiert ist. Die verarbeiteten Graphikdaten können in dem Graphikspeicher, in dem Parallelverarbeitungsspeicher 204 oder in den Systemspeicher 104 zur Anzeige auf der Anzeigevorrichtung 110 oder für die Weiterverarbeitung durch die CPU 102 oder das Parallelverarbeitungssubsystem 112 gespeichert werden. In einigen Ausführungsformen ist die ROP 395 konfiguriert, um z-Daten oder Farbdaten zu komprimieren, die in den Speicher geschrieben werden, und z-Daten oder Farbdaten, die aus dem Speicher gelesen werden, zu dekomprimieren. In verschiedenen Ausführungsformen kann die ROP 395 in der Speicherschnittstelle 214, in den GPCs 208, in dem Verarbeitungs-Cluster-Array 230 außerhalb der GPCs oder in einer separaten Einheit (nicht gezeigt) in den PPUs 202 angeordnet sein.
  • Die Graphikverarbeitungs-Pipeline kann durch ein oder mehrere Verarbeitungselemente in der PPU 202 implementiert sein. Beispielsweise kann einer der SM 310 von 3A konfiguriert sein, um die Funktionen der VTG 365 und/oder der Pixel-Schattierungseinheit 390 durchzuführen. Die Funktionen der PD 355, der VAF 360, der VPC 450, der Kacheleinheit 375, der Einrichtungseinheit 380, der Rastereinheit 385 und der ROP 395 können ebenfalls von Verarbeitungselementen innerhalb eines bestimmten GPC 208 in Verbindung mit einer entsprechenden Partitionseinheit 215 durchgeführt werden. Alternativ kann die Graphikverarbeitungs-Pipeline 350 unter Verwendung bestimmter Verbindungselemente mit festgelegter Funktion für eine oder mehrere der zuvor aufgeführten Funktionen implementiert werden. In verschiedenen Ausführungsformen kann die PPU 202 konfiguriert sein, um eine oder mehrere Graphikverarbeitungs-Pipelines 350 zu implementieren.
  • In einigen Ausführungsformen kann die Graphikverarbeitungs-Pipeline 350 in eine Welt-Raum-Pipeline 352 und eine Bildschirm-Raum-Pipeline 354 unterteilt werden. Die Welt-Raum-Pipeline 352 verarbeitet graphische Objekte im 3D-Raum, in welchem die Position jedes graphischen Objekts relativ zu anderen graphischen Objekten und relativ zu einem 3D-Koordinatensystem bekannt ist. Die Bildschirm-Raum-Pipeline 354 verarbeitet graphische Objekte, die von dem 3D-Koordinatensystem auf eine 2D-ebene Fläche projiziert wurden, die die Oberfläche der Anzeigevorrichtung 110 darstellt. Beispielsweise könnte die Welt-Raum-Pipeline 352 Pipeline-Stufen in der Graphikverarbeitungs-Pipeline 350 von der PD 355 bis zu der VPC 370 umfassen. Die Bildschirm-Raum-Pipeline 354 könnte Pipeline-Stufen in der Graphikverarbeitungs-Pipeline 350 von der Einrichtungseinheit 380 bis zu der ROP 395 umfassen. Die Kacheleinheit 375 würde der letzten Stufe der Welt-Raum-Pipeline 352, d. h. der VPC 370, folgen. Die Kacheleinheit 375 würde der ersten Stufe der Bildschirm-Raum-Pipeline 354, d. h. der Einrichtungseinheit 380, vorangehen.
  • Wie nachstehend in größerem Detail in Verbindung mit 5 bis 13 beschrieben ist, kann die Kacheleinheit 375 eine Mehrfach-Durchlaufeinheit umfassen, die konfiguriert ist, um Graphikgrundelementdaten für mehrere Durchläufe durch die Bildschirm-Raum-Pipeline 354 zu Puffern. Die Graphikgrundelementdaten können Graphikgrundelemente oder Grundelementindices umfassen, die unterschiedliche Graphikgrundelemente im Speicher kennzeichnen. Die Mehrfach-Durchlaufeinheit kann die Bildschirm-Raum-Pipeline 354 für jeden Durchlauf basierend auf von dem Vorrichtungstreiber 103 bereitgestellten Zustandsbündeln unterschiedlich konfigurieren. Auf diese Art und Weise interoperieren der Vorrichtungstreiber 103 und die Mehrfach-Durchlaufeinheit, um mehrere Durchläufe durch die Bildschirm-Raum-Pipeline 354 zu koordinieren. Mit dieser Vorgehensweise können bestimmte Arten von Rendering-Szenarien verbessert werden, wie nachstehend in größerem Detail in Verbindung mit 5 bis 13 beschrieben.
  • In einigen Ausführungsformen kann die Welt-Raum-Pipeline 352 in eine Alpha-Phasen-Pipeline und eine Beta-Phasen-Pipeline weiter unterteilt werden. Beispielsweise kann die Alpha-Phasen-Pipeline Pipeline-Stufen in der Graphikverarbeitungs-Pipeline 350 von der PD 355 bis zu der Aufgabenerzeugungseinheit umfassen. Die Beta-Phasen-Pipeline kann Pipeline-Stufen in der Graphikverarbeitungs-Pipeline 350 von der Topologie-Erzeugungseinheit bis zu der VPC 370 umfassen. Die Graphikverarbeitungs-Pipeline 350 führt einen ersten Satz von Operationen während der Verarbeitung in der Alpha-Phasen-Pipeline aus und führt einen zweiten Satz von Operationen während der Verarbeitung in der Beta-Phasen-Pipeline aus. Im hier verwendeten Sinne ist ein Satz von Operationen als eine oder mehrere Anweisungen definiert, die von einem einzelnen Thread, von einer Threadgruppe oder von mehreren Threadgruppen, die als Einheit agieren, ausgeführt werden.
  • In einem System mit mehreren Graphikverarbeitungs-Pipelines 350 können die Vertex-Daten und die Vertex-Attribute, die einem Satz von graphischen Objekten zugeordnet sind, so unterteilt werden, dass jede Graphikverarbeitungs-Pipeline 350 ungefähr den gleichen Betrag an Arbeitslast während der Alpha-Phase aufweist. Die Alpha-Phasenverarbeitung kann den Satz an Vertex-Daten und Vertex-Attributen deutlich erweitern, so dass die Menge an Vertex-Daten und Vertex-Attributen, die von der Aufgabenerzeugungseinheit erzeugt werden, deutlich größer als die Menge an Vertex-Daten und Vertex-Attributen ist, die von der PD 255 und der VAF 360 erzeugt wird. Ferner kann die Aufgabenerzeugungseinheit, die einer einzelnen Graphikverarbeitungs-Pipeline 350 zugeordnet ist, eine deutlich größere Menge an Vertex-Daten und Vertex-Attributen erzeugen als die Aufgabenerzeugungseinheit, die einer anderen Graphikverarbeitungs-Pipeline 350 zugeordnet ist, selbst in Fällen, in denen die beiden Graphikverarbeitungs-Pipelines 350 die gleiche Menge an Attributen zu Beginn der Alpha-Phasen-Pipeline verarbeiten. In derartigen Fällen verteilt die Aufgabenverteilungseinheit die Attribute, die von der Alpha-Phasen-Pipeline erzeugt werden, derart um, dass jede Graphikverarbeitungs-Pipeline 350 ungefähr die gleiche Arbeitsauslastung zu Beginn der Beta-Phasen-Pipeline aufweist.
  • Wie hier verwendet, können Verweise auf einen gemeinsam benutzten Speicher einen oder mehrere technisch machbare Speicher umfassen, wozu gehören, ohne einschränkend zu sein, ein lokaler Speicher, der gemeinsam von dem einen oder den mehreren SMs 310 benutzt wird, oder ein Speicher, auf den über die Speicherschnittstelle 214 zugegriffen werden kann, wie beispielsweise ein Cache-Speicher, der Parallelverarbeitungsspeicher 204 oder der Systemspeicher 104. Wie ebenfalls hier verwendet können Verweise auf einen Cache-Speicher einen oder mehrere technisch machbare Speicher umfassen, wozu gehören, ohne einschränkend zu sein, ein Li-Cache-Speicher, ein L1.5-Cache-Speicher und die L2-Cache-Speicher.
  • Gekachelte Zwischenspeicherung
  • 4 ist ein Konzeptdiagramm einer Cache-Kachel 410(0), für welche die Graphikverarbeitungs-Pipeline 350 von 3B konfiguriert sein kann, diese zu erzeugen und zu verarbeiten, gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt, stellt die Cache-Kachel 410(0) einen Abschnitt eines Bildschirm-Raums 400 dar und ist in mehrere Raster-Kacheln 420 unterteilt.
  • Der Bildschirm-Raum 400 stellt einen oder mehrere Pufferspeicher dar, die konfiguriert sind, um gerenderte Bilddaten und andere Daten, die von den Funktionseinheiten innerhalb der Graphikverarbeitung-Pipeline 350 übertragen wurden, zu speichern. In einigen Ausführungsformen können der eine oder die mehreren Pufferspeicher als ein oder mehrere Rendering-Ziele konfiguriert sein. Der Bildschirm-Raum stellt einen Pufferspeicher dar, der konfiguriert ist, um das von der Graphikverarbeitungs-Pipeline erzeugte Bild zu speichern. Der Bildschirm-Raum 400 kann einer beliebigen Anzahl an Rendering-Zielen zugeordnet sein, wobei jedes Rendering-Ziel unabhängig von anderen Rendering-Zielen so konfiguriert sein kann, dass es eine beliebige Anzahl an Feldern umfasst. Jedes Feld in einem Rendering-Ziel ist unabhängig von anderen Feldern so konfiguriert, dass es eine beliebige Anzahl an Bits umfasst. Jedes Rendering-Ziel kann mehrere Bildelemente (Pixel) umfassen, und jedes Pixel kann seinerseits mehrere Abtastwerte umfassen. In einigen Ausführungsformen kann die Größe jeder Cache-Kachel auf der Größe und der Konfiguration der Rendering-Ziele beruhen, die dem Bildschirm-Raum zugeordnet sind. Sobald im Betrieb das Rendering abgeschlossen ist, können die Pixel in dem einen oder den mehreren Rendering-Zielen an eine Anzeigevorrichtung übertragen werden, um das gerenderte Bild anzuzeigen.
  • Beispielsweise könnte ein Satz von Rendering-Zielen für den Bildschirm-Raum 400 acht Rendering-Ziele umfassen. Das erste Rendering-Ziel könnte vier Felder umfassen, die Farben darstellen, wozu Rot-, Grün- und Blau-Komponentenfarben und Transparenzinformation gehören, die einem entsprechenden Fragment zugeordnet sind. Das zweite Rendering-Ziel könnte zwei Felder umfassen, die entsprechend Tiefeninformationen und Schabloneninformation darstellen, die dem entsprechenden Fragment zugeordnet sind. Das dritte Rendering-Ziel könnte drei Felder umfassen, die Information über den Oberflächennormalenvektor einschließlich eines Normalenvektors in der X-Achse und eines Normalenvektors in der Y-Achse und eines Normalenvektors in der Z-Achse, die dem entsprechenden Fragment zugeordnet sind, darstellen. Die verbleibenden fünf Rendering-Ziele könnten konfiguriert sein, dass sie zusätzliche Informationen, die zu dem entsprechenden Fragment gehört, speichern. Derartige Konfigurationen könnten umfassen: einen Speicher für verschiedene Informationen einschließlich, ohne einschränkend zu sein, 3D-Positionsdaten, Information für diffuse Beleuchtung und Information für Glanzbeleuchtung.
  • Jede Cache-Kachel 410 stellt einen Abschnitt des Bildschirm-Raums 400 dar. Der Klarheit halber sind nur fünf Cache-Kacheln 410(0) bis 410(4) in 4 gezeigt. In einigen Ausführungsformen besitzen die Cache-Kacheln in dem X- und Y-Bildschirm-Raum eine willkürliche Größe. Wenn beispielsweise eine Cache-Kachel in einem Cache-Speicher liegt, der auch verwendet wird, um andere Daten zu speichern, dann kann die Cache-Kachel so dimensioniert sein, dass nur ein bestimmter Abschnitt des Cache-Speichers eingenommen wird. Die Größe einer Cache-Kachel kann auf einer Reihe von Faktoren beruhen, wozu gehören: die Quantität und die Konfiguration der Rendering-Ziele, die dem Bildschirm-Raum 400 zugeordnet sind, die Menge an Abtastwerten pro Pixel, und ob die in der Cache-Kachel gespeicherten Daten komprimiert sind. Allgemein gilt, dass eine Cache-Kachel so dimensioniert wird, dass die Wahrscheinlichkeit erhöht ist, dass die Cache-Kacheldaten in dem Cache-Speicher resident bleiben, bis alle graphischen Grundelemente, die der Cache-Kachel zugeordnet sind, vollständig verarbeitet sind.
  • Die Raster-Kacheln 420 stellen einen Abschnitt der Cache-Kachel 410(0) dar. Wie gezeigt, umfasst die Cache-Kachel 410(0) 16 Raster-Kacheln 420(0) bis 420(15), die in einem Array angeordnet sind, das eine Breite von vier Raster-Kacheln 420 und eine Höhe von vier Raster-Kacheln 420 aufweist. In Systemen, die mehrere GPCs 208 umfassen, kann die Verarbeitung, die einer gegebenen Cache-Kachel 410(0) zugeordnet ist, auf die verfügbaren GPCs 208 aufgeteilt werden. In dem gezeigten Beispiel gilt, dass, wenn die 16 Raster-Kacheln der Cache-Kachel 410(0) von vier unterschiedliche GPCs 208 zu verarbeiten sind, dann könnte jedem GPC 208 zugewiesen werden, vier der 16 Raster-Kacheln 420 in der Cache-Kachel 410(0) zu verarbeiten. Insbesondere könnte dem ersten GPC 208 zugewiesen werden, die Raster-Kacheln 420(0), 420(7), 420(10) und 420(13) zu verarbeiten. Dem zweiten GPC 208 könnte zugewiesen werden, Raster-Kacheln 420(1), 420(4), 420(11) und 420(14) zu verarbeiten. Dem dritten GPC 208 könnte zugewiesen werden, Raster-Kacheln 420(2), 420(5), 420(8) und 420(15) zu verarbeiten. Dem vierten GPC 208 könnte dann zugewiesen werden, Raster-Kacheln 420(3), 420(6), 420(9) und 420(12) zu verarbeiten. In anderen Ausführungsformen kann die Verarbeitung der unterschiedlichen Raster-Kacheln in einer gegebenen Cache-Kachel unter den GPCs 208 oder anderen Verarbeitungseinheiten, die in dem Computersystem 100 umfasst sind, auf eine beliebige technisch machbare Art und Weise aufgeteilt werden.
  • Mehrfach-Durchlauf-Rendering-Techniken
  • 5 veranschaulicht einen Abschnitt der Graphikverarbeitungs-Pipeline von 3B, die konfiguriert ist, um Grundelementdaten in mehreren Durchläufen zu verarbeiten, gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt, umfasst ein Abschnitt 500 eine Mehrfach-Durchlauf(MP)-Einheit 510, die stromaufwärts von der Bildschirm-Raum-Pipeline 354 liegt. Die MP-Einheit 510 kann innerhalb der in 3B gezeigten Kacheleinheit 375 liegen. Die MP-Einheit 510 ist mit einem Puffer 520 gekoppelt, der konfiguriert ist, um Grundelementdaten und Zustandsbündel zu speichern. Die im Puffer 520 gespeicherten Daten entsprechen allgemein einer oder mehreren Cache-Kacheln. In einer Ausführungsform ist der Puffer 520 eine Direktzugriffsspeicher(RAM)-Einheit. Der Puffer 520 umfasst Grundelementdaten PD0 bis PDN, wie gezeigt ist. Wie in größerem Detail nachstehend beschrieben, umfassen alle Grundelementdaten im Puffer 520 ein Graphikgrundelement oder Graphikgrundelementindices und eine Grundelementmaske. Der Puffer 520 umfasst ebenfalls Zustandsbündel SB0 bis SBM, wie gezeigt. Jedes Zustandsbündel im Puffer 520 umfasst eine oder mehrere Zustandseinstellungen und eine Zustandsmaske, wie ebenfalls nachstehend beschrieben.
  • Die MP-Einheit 510 ist konfiguriert, um eine oder mehrere Traversierungen des Puffers 520 durchzuführen, um einige oder alle der darin gespeicherten Grundelementdaten während eines oder mehreren entsprechenden Durchläufen durch die Bildschirm-Raum-Pipeline 354 zu verarbeiten. Für jeden derartigen Durchlauf konfiguriert die MP-Einheit 510 die Bildschirm-Raum-Pipeline 354 basierend auf spezifischen Zustandsbündeln im Puffer 520. Somit kann die Bildschirm-Raum-Pipeline 354 für jeden unterschiedlichen Durchlauf unterschiedlich konfiguriert werden. Außerdem kann für jeden unterschiedlichen Durchlauf die MP-Einheit 510 unterschiedliche Teilmengen von Graphikgrundelementen, die aus dem Puffer 520 extrahiert wurden, an die Bildschirm-Raum-Pipeline 354 zur Verarbeitung übertragen.
  • Die MP-Einheit 510 umfasst eine Durchlaufmaske 512, welche die durchzuführende Anzahl von Durchläufen und die aktuelle Durchlaufnummer angibt. Die Anzahl von Bits in der Durchlaufmaske 512 trägt der Anzahl von durchzuführenden Durchläufen Rechnung. Jedes Bit der Durchlaufmaske 512 entspricht einer unterschiedlichen Durchlaufnummer. Wenn die MP-Einheit 510 einen bestimmten Durchlauf durchführt, der eine spezifische Durchlaufnummer aufweist, wird das entsprechende Bit in der Durchlaufmaske 512 auf 1 gesetzt. Beispielsweise könnte die Durchlaufmaske 512 eine 4-Bit-Maske sein, die angibt, dass vier Durchläufe durchgeführt werden. Jedes unterschiedliche Bit der 4-Bit-Durchlaufmaske würde einer unterschiedlichen Durchlaufnummer entsprechen. Somit würde eine Durchlaufmaske von 0001 angeben, dass der aktuelle Durchlauf der Durchlauf 0 ist, oder alternativ würde eine Durchlaufmaske von 0100 angeben, dass der aktuelle Durchlauf der Durchlauf 2 ist. Beim Durchlaufen des Puffers 520 stützt sich die MP-Einheit 510 auf die Durchlaufmaske 512, um Grundelementdaten und Zustandsbündel auszufiltern, die für den aktuellen Durchlauf relevant sind.
  • Alle im Puffer 520 gespeicherten Grundelementdaten, wie beispielsweise PD0 oder PD1, umfassen ein Graphikgrundelement oder Graphikgrundelementindices sowie auch eine Grundelementmaske, wie oben erwähnt. Die Grundelementmaske gibt die bestimmten Durchläufe durch die Bildschirm-Raum-Pipeline 354 an, während derselben das Graphikgrundelement verarbeitet werden sollte. Die Grundelementmaske ist im Allgemeinen von gleicher Größe zu der Durchlaufmaske 512. Zurückkommend zu dem obigen Beispiel würde, wenn die MP-Einheit 510 konfiguriert ist, um vier Durchläufe durchzuführen und sich somit auf eine 4-Bit-Durchlaufmaske 512 stützt, jede Grundelementmaske innerhalb der verschiedenen Grundelementdaten gleichermaßen eine 4-Bit-Maske sein. Jedes Bit der Grundelementmaske würde angeben, ob das zugeordnete Graphikgrundelement während der entsprechende Durchlaufnummern verarbeitet werden sollte. Beispielsweise würde eine Grundelementmaske von 0011 angeben, dass das Graphikgrundelement während Durchlauf 0 und Durchlauf 1, jedoch nicht während Durchlauf 2 und Durchlauf 3 verarbeitet werden sollte.
  • Jedes im Puffer 520 gespeicherte Zustandsbündel, wie beispielsweise SB0 oder SB1, umfasst eine oder mehrere Zustandseinstellungen und eine Zustandsmaske, wie ebenfalls oben erwähnt. Jede Zustandseinstellung spiegelt im Allgemeinen die Konfiguration eines bestimmten Zustands der Bildschirm-Raum-Pipeline 354 wider. Beispielsweise könnte ein Zustand der Bildschirm-Raum-Pipeline 354 im Allgemeinen eine zu verwendende Tiefenfunktion widerspiegeln, und eine Zustandseinstellung für diesen Zustand könnte eine spezifische Tiefenfunktion sein, die von der ROP 395 auszuführen ist. Ein anderer Zustand könnte ein Tiefenpufferzustand sein und eine entsprechende Zustandseinstellung könnte widerspiegeln, dass der Tiefenpuffer gesperrt ist. Fachleute werden verstehen, dass ”Zustand” ein weitläufiger Begriff ist, der bedeutet, dass ein allgemein konfigurierbares Merkmal der Bildschirm-Raum-Pipeline 354 erfasst, und dass eine ”Zustandseinstellung” eine spezifische Konfiguration dieses Merkmals darstellt.
  • Die Zustandsmaske innerhalb eines gegebenen Zustandsbündels gibt die bestimmten Durchläufe durch die Bildschirm-Raum-Pipeline 354 an, die basierend auf den Zustandseinstellungen innerhalb dieses Zustandsbündels durchgeführt werden sollten. Die Zustandsmaske ist im Allgemeinen von gleicher Größe zu der Durchlaufmaske 512. Zurückkehrend auf das obige Beispiel würde, wenn die MP-Einheit 510 konfiguriert ist, um vier Durchläufe durchzuführen und sich somit auf eine 4-Bit-Durchlaufmaske 512 stützt, jede Zustandsmaske innerhalb der unterschiedlichen Zustandsbündel gleichermaßen eine 4-Bit-Maske sein. Jedes Bit einer gegebenen Zustandsmaske gibt an, ob die zugeordneten Zustandseinstellungen verwendet werden sollten, um die Bildschirm-Raum-Pipeline 354 während der entsprechende Durchlaufnummern zu konfigurieren. Beispielsweise würde eine Zustandsmaske von 0101 angeben, dass die dieser Maske zugeordneten Zustandseinstellungen verwendet werden sollten, um die Bildschirm-Raum-Pipeline 354 während der Durchläufe 0 und 2, jedoch nicht während der Durchläufe 1 und 3 zu konfigurieren. Jedes Zustandsbündel umfasst im Allgemeinen eine Zustandsmaske und eine beliebige Anzahl von unterschiedlichen Zustandseinstellungen. Die einem bestimmten Durchlauf zugeordneten Grundelemente und Zustandseinstellungen können als innerhalb eines ”Bucket(Eimer)” liegend bezeichnet werden, der dem bestimmten Durchlauf entspricht. Im Betrieb kann die MP-Einheit 510 Grundelemente und Zustandseinstellungen zur Platzierung in ein Bucket ausfiltern, wenn ein bestimmter Durchlauf verarbeitet wird.
  • In einer Ausführungsform weisen die für jeden Durchlauf implementierten Zustandseinstellungen keine Eins-zu-Eins-Beziehung mit jedem Bit der Durchlaufmaske in der oben beschriebenen Art und Weise auf. Insbesondere kann, wenn der Vorrichtungstreiber 103 die Durchlaufmaske konfiguriert, der Vorrichtungstreiber 103 ebenfalls zuweisen, welche Zustands-Buckets mit jedem Durchlauf verarbeitet werden. Beispielsweise könnte, wenn die MP-Einheit 510 für zwei Durchläufe konfiguriert ist, der Zustand-Bucket 1 für den Durchlauf 0 und der Zustand-Bucket 0 für Durchlauf 1 verwendet werden. Diese Art von Indirektion kann angewendet werden, so dass eine ”Stationärzustand”-Verarbeitung unter Verwendung des Zustand-Bucket 0 eingerichtet werden kann und dann eine bestimmte ”Vorverarbeitung” unter Verwendung des Zustand-Bucket 1 eingerichtet werden könnte. Dann kann die MP-Einheit 510 zwei Durchläufe unter Verwendung des Zustand-Bucket 1 (Vorverarbeitungs-Zustand) gefolgt dann vom Zustand-Bucket 0 (Stationärzustands-Verarbeitung) durchführen.
  • Im Betrieb erzeugt die MP-Einheit 510 für einen gegebenen Durchlauf durch die Bildschirm-Raum-Pipeline 354 Durchlaufdaten 530, die sowohl Zustandseinstellungen 540, die verwendet werden, um die Bildschirm-Raum-Pipeline 354 für den aktuellen Durchlauf zu konfigurieren, als auch Grundelemente 550, die während des aktuellen Durchlaufs verarbeitet werden, umfassen. Die MP-Einheit 510 kann dann die Bildschirm-Raum-Pipeline 354 basierend auf Zustandseinstellungen 540 konfigurieren und dann die Grundelemente 550 unter Verwendung der konfigurierten Bildschirm-Raum-Pipeline 354 verarbeiten. Für nachfolgende Durchläufe kann die MP-Einheit 510 eine analoge Operation durchführen. Da sich die Durchlaufmaske 512 jedoch basierend auf der aktuellen Durchlaufnummer unterscheidet, können sich die aus dem Puffer 520 extrahierten spezifischen Zustandseinstellungen 540 und Grundelemente 550 für den nachfolgenden Durchlauf im Vergleich mit dem vorangegangenen Durchlauf unterscheiden. Mit dieser Vorgehensweise ist die Graphikverarbeitungs-Pipeline 350 imstande, die Grundelementdaten mehrere Male und mit unterschiedlichen Konfigurationen der Bildschirm-Raum-Pipeline 354 zu verarbeiten, ohne die Graphikgrundelemente mehrere Male aus dem Speicher abrufen zu müssen. In verschiedenen Ausführungsformen kann die Graphikverarbeitungs-Pipeline 350 die Graphikgrundelemente aus dem L2-Cache mehrere Male abrufen, ohne diese Grundelemente mehrere Male aus dem Systemspeicher abrufen zu müssen.
  • Der in 1 gezeigte Vorrichtungstreiber 103 ist im Allgemein konfiguriert, um den Gesamtbetrieb der MP-Einheit 510 zu verwalten. Dabei kann der Vorrichtungstreiber 103 den Puffer 520 mit Grundelementdaten und Zustandsbündel befüllen, die ermöglichen, dass effizientere Arten eines Rendering durchgeführt werden. Diese Funktionalität kann die Programmierlast von Anwendungsentwicklern lindern. Beispielsweise könnte der Vorrichtungstreiber 103 die MP-Einheit 510 konfigurieren, um zwei Durchläufe des Puffers 520 durchzuführen. Im Durchlauf 0 würde der Vorrichtungstreiber 103 die MP-Einheit 510 konfigurieren, um einen Nur-Z-Durchlauf zu implementieren. Während dieses Durchlaufs könnte die MP-Einheit 510 einen Tiefentest durchführen und bestimmen, welche Graphikgrundelemente schattiert werden sollten. Im Durchlauf 1 würde der Vorrichtungstreiber 103 die MP-Einheit 510 konfigurieren, um ein Z+-Farbdurchlauf zu implementieren. Während dieses Durchlaufs würde die MP-Einheit 510 Z-Operationen nach Bedarf durchführen und dann ebenfalls eine Farbschattierung durchführen. Mit dieser Vorgehensweise kann die Rendering-Effizienz besonders im Kontext des Rendering ”von hinten nach vorne” verbessert werden. Insbesondere würden durch Vordergrund-Grundelemente verdeckte Hintergrund-Grundelemente im zweiten Durchlauf nicht schattiert werden. Ferner würde es nicht nötig sein, Graphikgrundelemente aus dem Speicher beim Durchführen zusätzlicher Durchläufe abzurufen, weil diese Grundelemente innerhalb des Puffers 520 gepuffert würden. Die bisher beschriebenen Techniken werden ebenfalls beispielhaft nachstehend in Verbindung mit 6A bis 6H beschrieben. 6A bis 6H sind beispielhafte Veranschaulichungen, wie die Mehrfach-Durchlauf(MP)-Einheit von 5 Durchlaufdaten zum Konfigurieren der Bildschirm-Raum-Pipeline von 3B erzeugt, gemäß einer Ausführungsform der vorliegenden Erfindung. Jede der 6A bis 6H veranschaulicht beispielhafte Daten, die einem von vier beispielhaften Durchläufen zugeordnet sind, die mit einer von zwei beispielhaften Cache-Kacheln durchgeführt werden. Insbesondere veranschaulicht 6A Daten, die im Durchlauf 0 der Cache-Kachel 0 verarbeitet werden. 6B veranschaulicht Daten, die im Durchlauf 1 der Cache-Kachel 0 verarbeitet werden. 6C veranschaulicht Daten, die im Durchlauf 2 der Cache-Kachel 0 verarbeitet werden. 6D veranschaulicht Daten, die im Durchlauf 3 der Cache-Kachel 0 verarbeitet werden. 6E veranschaulicht Daten, die im Durchlauf 0 der Cache-Kachel 1 verarbeitet werden. 6F veranschaulicht Daten, die im Durchlauf 1 der Cache-Kachel 1 verarbeitet werden. 6G veranschaulicht Daten, die im Durchlauf 2 der Cache-Kachel 1 verarbeitet werden. 6H veranschaulicht Daten, die im Durchlauf 3 der Cache-Kachel 1 verarbeitet werden.
  • Wie in jeder der 6A bis 6H gezeigt, umfasst der Puffer 520 Grundelementmasken (PMs) 612, Zustandsmasken (SMs) 614, verschiedene Grundelemente und verschiedene Zustandseinstellungen, die innerhalb des Puffers 520 gemäß der API-Reihenfolge angeordnet sind. Wie ebenfalls gezeigt, wurden verschiedene Zustandseinstellungen S0, S1, S2, S3, S4, S5 und S6 zuvor auf die Bildschirm-Raum-Pipeline 354 angewendet. In dem in Verbindung mit diesen Figuren beschriebenen Beispiel werden modifizierte Versionen dieser Zustandseinstellungen beispielsweise als S0', S0'', S0''' gezeigt.
  • Jeder PM 612 ist einer Teilmenge von Grundelementen zugeordnet und jeder SM 614 ist einer Teilmenge von Zustandseinstellungen zugeordnet. Beispielsweise ist der PM 612(0) dem Grundelement P0 zugeordnet. Der SM 614(0) ist Zustandseinstellungen S0' und S1' zugeordnet, die ihrerseits den modifizierten Versionen von Zustandseinstellungen S0 und S1 Rechnung tragen. Jedes Grundelement ist allgemein der jüngsten Grundelementmaske zugeordnet. Beispielsweise ist das Grundelement P1 dem M 612(0) zugeordnet. Jeder Satz von Zustandseinstellungen und der zugeordneten Zustandsmaske kann ein Zustandsbündel bilden, wie beispielsweise die in 5 gezeigten verschiedenen SBs. Beispielsweise können der SM 614(1) und die Zustandseinstellungen S2', S3' und S4' ein Zustandsbündel bilden.
  • Im Allgemeinen gibt die Zustandsmaske für ein gegebenes Zustandsbündel die bestimmten Durchläufe an, für welche die zugeordneten Zustandseinstellungen relevant sind. Gleichermaßen gibt die, einer bestimmten Teilmenge von Grundelementen zugeordnete Grundelementmaske die Durchläufe an, während derselben diese Teilmenge von Grundelementen verarbeitet werden sollte. Beispielsweise gibt SM 614(0) an, das Zustandseinstellungen S1' und S0' auf alle Durchläufe anwendbar sind, da alle Bits des SM 614(0) auf Eins gesetzt sind. Gleichermaßen gibt der PM 612(0) an, dass das Grundelement PO in allen Durchläufen verarbeitet werden sollte, da alle Bits des SM 612(0) auf Eins gesetzt sind.
  • Jede der 6A bis 6H veranschaulicht ebenfalls unterschiedliche Pipeline-Daten 600 und den Dirty-Zustand 610. Bestimmte Pipeline-Daten 600 geben die spezifischen Grundelemente und Zustandseinstellungen an, die an die Bildschirm-Raum-Pipeline 354 für einen bestimmten Durchlauf einer bestimmten Cache-Kachel übertragen werden. Jeder Dirty-Zustand 610 veranschaulicht Zustandseinstellungen, die nach dem Abschluss eines aktuellen Durchlaufs gesendet werden, um einen nachfolgenden Durchlauf einer gegebenen Cache-Kachel vorzubereiten. 6A bis 6H werden nun einzeln beschrieben.
  • Wie in 6A gezeigt, umfassen Pipeline-Daten 600(0-0) Daten, die an die Bildschirm-Raum-Pipeline 354 in Verbindung mit dem Durchführen des Durchlaufs 0 der Cache-Kachel 0 gesendet werden. Die Pipeline-Daten 600(0-0) veranschaulichen ebenfalls Dirty-Bits, die gesetzt sind, um zu verfolgen, welche Zustandseinstellungen von zuvor konfigurierten Werten abgewichen sind. In den Pipeline-Daten 600(0-0) werden modifizierte Zustandseinstellungen S0', S1', S2', S3' und S4' gesendet, und so werden diese Änderungen in entsprechenden Dirty-Bits aufgezeichnet. Wenn der Durchlauf 0 der Cache-Kachel 0 abgeschlossen ist, überträgt die MP-Einheit 510 den Dirty-Zustand 610(0-0), der Zustandseinstellungen S0, S1, S2, S3 und S4 umfasst, um die Bildschirm-Raum-Pipeline 354 für den Durchlauf 1 der Cache-Kachel 0 vorzubereiten.
  • Wie in 6B gezeigt, umfassen Pipeline-Daten 600(0-1) Daten, die an die Bildschirm-Raum-Pipeline 354 in Verbindung mit dem Durchführen des Durchlaufs 1 der Cache-Kachel 0 gesendet werden. Die Pipeline-Daten 600(0-1) veranschaulichen ebenfalls Dirty-Bits, die gesetzt sind, um zu verfolgen, welche Zustandseinstellungen von zuvor konfigurierten Werten abgewichen sind. In Pipeline-Daten 600(0-1) werden Zustandseinstellungen S0, S1, S2, S3 und S4 zu S0', S1', S2', S3' und S4' modifiziert, und so werden diese Änderungen in entsprechenden Dirty-Bits aufgezeichnet. Da keine Grundelemente nach S2', S3' und S4' gesendet wurden, wird dieser Zustand nicht an die Bildschirm-Raum-Pipeline 354 gesendet. Stattdessen wird der aktualisierte Zustand im Speicher gehalten, bis das nächste Grundelement gesendet wird oder der Durchlauf endet. Wenn der Durchlauf 1 der Cache-Kachel 0 abgeschlossen ist, überträgt die MP-Einheit 510 den Dirty-Zustand 610(0-1), der Zustandseinstellungen S0, S1, S2, S3 und S4 umfasst, um die Bildschirm-Raum-Pipeline 354 für den Durchlauf 2 der Cache-Kachel 0 vorzubereiten.
  • Wie in 6C gezeigt, umfassen die Pipeline-Daten 600(0-2) Daten, die an die Bildschirm-Raum-Pipeline 354 in Verbindung mit dem Durchführen des Durchlaufs 2 der Cache-Kachel 0 gesendet werden. Die Pipeline-Daten 600(0-2) veranschaulichen ebenfalls Dirty-Bits, die gesetzt sind, um zu verfolgen, welche Zustandseinstellungen von zuvor konfigurierten Werten abgewichen sind. In den Pipeline-Daten 600(0-2) werden modifizierte Zustandseinstellungen S0', S1', S4'' und S5' gesendet, und so werden diese Änderungen in entsprechenden Dirty-Bits aufgezeichnet. Die Zustandseinstellungen S2 werden gesendet, weil das Dirty-Bit noch gesetzt ist; die Zustandseinstellung S2 wurde jedoch im Durchlauf 2 nicht geändert, so dass der letzte gesendete Wert S2 (nicht S2') war. In einer Ausführungsform implementiert die MP-Einheit 510 einen Filtermechanismus, um Zustandseinstellungen zu filtern, wenn sich der zugeordnete Wert nicht änderte. Somit verhindert, obwohl S2 von der MP-Einheit 510 während der Vorbereitung für den Durchlauf 3 ausgesendet wird, der Filtermechanismus, dass S2 erneut zu der Bildschirm-Raum-Pipeline 354 gesendet wird, weil sich der Wert nicht änderte. Wenn der Durchlauf 2 der Cache-Kachel 0 abgeschlossen ist, überträgt die MP-Einheit 510 den Dirty-Zustand 610(0-2), der Zustandseinstellungen S0, S1, S2, S3, S4 und S5 umfasst, um die Bildschirm-Raum-Pipeline 354 für den Durchlauf 3 der Cache-Kachel 0 vorzubereiten.
  • Wie in 6D gezeigt, umfassen die Pipeline-Daten 600(0-3) Daten, die an die Bildschirm-Raum-Pipeline 354 in Verbindung mit dem Durchführen des Durchlaufs 3 der Cache-Kachel 0 gesendet werden. Pipeline-Daten 600(0-3) veranschaulichen ebenfalls Dirty-Bits, die gesetzt sind, um zu verfolgen, welche Zustandseinstellungen von zuvor konfigurierten Werten abgewichen sind. In Pipeline-Daten 600(0-3) werden modifizierte Zustandseinstellungen S0', S1', S4'', S5', S6' und S1'' gesendet, und so werden diese Änderungen in entsprechenden Dirty-Bits aufgezeichnet. Wenn der Durchlauf 3 der Cache-Kachel 0 abgeschlossen ist, überträgt die MP-Einheit 510 den Dirty-Zustand 600(0-3), der Zustandseinstellungen S0, S1, S2, S3, S4, S5 und S6 umfasst, um die Bildschirm-Raum-Pipeline 354 für den Durchlauf 0 der Cache-Kachel 1 vorzubereiten. Wenn der oben erwähnte Filtermechanismus angewendet wird, werden Zustandseinstellungen S2 und S3 gefiltert und nicht an die Bildschirm-Raum-Pipeline 354 gesendet, da diese Einstellungen nicht als Teil des vorangegangenen Durchlaufs aktualisiert wurden.
  • Wie in 6E gezeigt, umfassen die Pipeline-Daten 600(1-0) Daten, die an die Bildschirm-Raum-Pipeline 354 in Verbindung mit dem Durchführen des Durchlaufs 0 der Cache-Kachel 1 gesendet werden. Pipeline-Daten 600(1-0) veranschaulichen ebenfalls Dirty-Bits, die gesetzt sind, um zu verfolgen, welche Zustandseinstellungen von zuvor konfigurierten Werten abgewichen sind. In den Pipeline-Daten 600(1-0) werden modifizierte Zustandseinstellungen S0', S1', S2', S3' und S4' gesendet, und so werden diese Änderungen in entsprechenden Dirty-Bits aufgezeichnet. Wenn der Durchlauf 0 der Cache-Kachel 1 abgeschlossen ist, überträgt die MP-Einheit 510 den Dirty-Zustand 610(1-0), der Zustandseinstellungen S0, S1, S2, S3, S4, S5 und S6 umfasst, um die Bildschirm-Raum-Pipeline 354 für den Durchlauf 1 der Cache-Kachel 1 vorzubereiten. Wenn der oben erwähnte Filtermechanismus angewendet wird, werden Zustandseinstellungen S5 und S6 gefiltert und nicht an die Bildschirm-Raum-Pipeline 354 gesendet, da diese Einstellungen nicht als Teil des vorangegangenen Durchlaufs aktualisiert wurden.
  • Wie in 6F gezeigt, umfassen Pipeline-Daten 600(1-1) Daten, die an die Bildschirm-Raum-Pipeline 354 in Verbindung mit dem Durchführen des Durchlaufs 1 von Cache-Kachel 1 gesendet werden. Pipeline-Daten 600(1-1) veranschaulichen ebenfalls Dirty-Bits, die gesetzt sind, um zu verfolgen, welche Zustandseinstellungen von zuvor konfigurierten Werten abgewichen sind. In Pipeline-Daten 600(1-1) werden modifizierte Zustandseinstellungen S0', S1', S2', S3' und S4' gesendet, und so werden diese Änderungen in entsprechenden Dirty-Bits aufgezeichnet. Wenn der Durchlauf 1 der Cache-Kachel 1 abgeschlossen ist, überträgt die MP-Einheit 510 den Dirty-Zustand 610(1-1), der Zustandseinstellungen S0, S1, S2, S3, S4, S5 und S6 umfasst, um die Bildschirm-Raum-Pipeline 354 für den Durchlauf 2 der Cache-Kachel 1 vorzubereiten. Wenn der oben erwähnte Filtermechanismus angewendet wird, werden Zustandseinstellungen S5 und S6 gefiltert und nicht an die Bildschirm-Raum-Pipeline 354 gesendet, da diese Einstellungen nicht als Teil des vorangegangenen Durchlaufs aktualisiert wurden.
  • Wie in 6G gezeigt, umfassen Pipeline-Daten 600(1-2) Daten, die gesendet an die Bildschirm-Raum-Pipeline 354 in Verbindung mit dem Durchführen des Durchlaufs 2 der Cache-Kachel 1 gesendet werden. Die Pipeline-Daten 600(1-2) veranschaulichen ebenfalls Dirty-Bits, die gesetzt sind, um zu verfolgen, welche Zustandseinstellungen von zuvor konfigurierten Werten abgewichen sind. In den Pipeline-Daten 600(1-2) werden modifizierte Zustandseinstellungen S0', S1', S4'' und S5' gesendet, und so werden diese Änderungen in entsprechenden Dirty-Bits aufgezeichnet. Wenn der Durchlauf 2 der Cache-Kachel 1 abgeschlossen ist, überträgt die MP-Einheit 510 den Dirty-Zustand 610(1-2), der Zustandseinstellungen S0, S1, S2, S3, S4, S5 und S6 umfasst, um die Bildschirm-Raum-Pipeline 354 für den Durchlauf 3 der Cache-Kachel 1 vorzubereiten. Wenn der oben erwähnte Filtermechanismus angewendet wird, werden Zustandseinstellungen S2, S3 und S6 gefiltert und nicht an die Bildschirm-Raum-Pipeline 354 gesendet, da diese Einstellungen als Teil des vorangegangenen Durchlaufs nicht aktualisiert wurden.
  • Wie in 6H gezeigt, umfassen die Pipeline-Daten 600(1-3) Daten, die an die Bildschirm-Raum-Pipeline 354 in Verbindung mit dem Durchführen des Durchlaufs 3 der Cache-Kachel 1 gesendet werden. Die Pipeline-Daten 600(1-3) veranschaulichen ebenfalls Dirty-Bits, die gesetzt sind, um zu verfolgen, welche Zustandseinstellungen von zuvor konfigurierten Werten abgewichen sind. In den Pipeline-Daten 600(1-3) werden modifizierte Zustandseinstellungen S0', S1', S4'', S5', S6' und S1'' gesendet, und so werden diese Änderungen in entsprechenden Dirty-Bits aufgezeichnet. Am Ende des letzten Durchlaufs für die letzte Cache-Kachel kann das Dirty-Bit für jede Zustandseinstellung mit allen Bits der gesetzten zugeordneten Zustandsmaske gelöscht werden. In diesem Beispiel werden nach dem Durchlauf 3 der Cache-Kachel 1, die Dirty-Bits gleich 0x7E (in hex) sein, was bedeutet, dass S1, S2, S3, S4, S5 und S6 nicht den gleichen Wert für alle vier Durchläufe aufweisen und pro Durchlauf bei einer nachfolgenden Wiederholung eingestellt werden müssen. Die Startwerte für jeden der vier Durchläufe werden in 6H gezeigt.
  • Auf diese Art und Weise verfolgt die MP-Einheit 510, welche Zustandseinstellungen sich zwischen Durchläufen ändern und überträgt dann lediglich aktualisierte Zustandseinstellungen nach Bedarf. Diese Vorgehensweise kann den Durchsatz der Bildschirm-Raum-Pipeline 354 erhöhen, weil weniger Konfiguration zwischen Durchläufen benötigt wird. Die bisher in 6A bis 6H beschriebenen Techniken werden ebenfalls in einer schrittweisen Art und Weise nachstehend jeweils in Verbindung mit 7 und 8 beschrieben.
  • 7 ist ein Ablaufdiagramm von Verfahrensschritten zum Durchführen mehrerer Durchläufe innerhalb einer Graphikverarbeitungs-Pipeline gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl die Verfahrensschritte in Verbindung mit den Systemen von 1 bis 6B beschrieben werden, werden Fachleute verstehen, dass jedes System, das konfiguriert ist, um die Verfahrensschritte in einer beliebigen Reihenfolge durchzuführen, innerhalb des Schutzumfangs der vorliegenden Erfindung ist.
  • Wie gezeigt, beginnt ein Verfahren 700 bei Schritt 702, wobei die MP-Einheit 510 die Verarbeitung des Puffers 520 einleitet. Dabei beginnt die MP-Einheit 510 die im Puffer 520 gespeicherten Daten zu durchlaufen und empfängt Grundelementdaten und Zustandsbündel. Bei Schritt 704 bestimmt die MP-Einheit 510, ob Grundelementdaten empfangen werden. Grundelementdaten umfassen allgemein Daten oder Indices, die einem Graphikgrundelement zugeordnet sind, und eine Grundelementmaske, die angibt, in welchen Durchläufen das Grundelement verarbeitet werden sollte. Wenn keine Grundelementdaten bei Schritt 704 empfangen werden, dann geht das Verfahren 700 zu dem nachstehend beschriebenen Schritt 710 weiter. Andernfalls geht das Verfahren 700 zu Schritt 706 weiter.
  • Bei Schritt 706 vergleicht die MP-Einheit 510 die Durchlaufmaske 512 mit einer in den Grundelementdaten enthaltenen Grundelementmaske, um zu bestimmen, ob das zugeordnete Graphikgrundelement in dem aktuellen Durchlauf verarbeitet werden sollte. Wenn der Vergleich angibt, dass das Grundelement im aktuellen Durchlauf nicht verarbeitet werden sollte, dann geht das Verfahren 700 zu dem nachstehend beschriebenen Schritt 710 weiter. Andernfalls geht das Verfahren 700 zu Schritt 708 weiter. Bei Schritt 708 umfasst die MP-Einheit 510 das den Grundelementdaten zugeordnete Grundelement in den Durchlaufdaten 630 für den aktuellen Durchlauf. Das Verfahren 700 geht dann zu Schritt 710 weiter.
  • Bei Schritt 710 bestimmt die MP-Einheit 510, ob ein Zustandsbündel empfangen wird. Zustandsbündel umfassen im Allgemeinen eine oder mehrere Zustandseinstellungen und eine Zustandsmaske, die angibt, welche Durchläufe gemäß der einen oder den mehreren Zustandseinstellungen konfiguriert werden sollten. Wenn kein Zustandsbündel bei Schritt 710 empfangen wird, dann geht das Verfahren zu dem nachstehend beschriebenen Schritt 716 weiter. Wenn die MP-Einheit 510 bei Schritt 710 bestimmt, dass ein Zustandsbündel empfangen wird, dann geht das Verfahren 700 zu Schritt 712 weiter.
  • Bei Schritt 712 vergleicht die MP-Einheit 510 die Durchlaufmaske 512 mit einer in dem Zustandsbündel enthaltenen Zustandsmaske, um zu bestimmen, ob die eine oder die mehreren in dem Zustandsbündel enthaltenen Zustandseinstellungen verwendet werden sollten, um die Bildschirm-Raum-Pipeline 354 für den aktuellen Durchlauf zu konfigurieren. Wenn der Vergleich angibt, dass die Bildschirm-Raum-Pipeline 354 nicht basierend auf diesen Zustandseinstellungen konfiguriert werden sollte, dann geht das Verfahren zu dem nachstehend beschriebenen Schritt 716 weiter. Andernfalls geht das Verfahren 700 zu Schritt 714 weiter. Bei Schritt 714 umfasst die MP-Einheit 510 die eine oder die mehreren Zustandseinstellungen in den Durchlaufdaten 630 für den aktuellen Durchlauf. Das Verfahren 700 geht dann zu Schritt 716 weiter.
  • Bei Schritt 716 bestimmt die MP-Einheit 510, ob die Traversierung des Puffers 520 abgeschlossen ist. Wenn diese Traversierung abgeschlossen ist, dann endet das Verfahren 700. Andernfalls kehrt das Verfahren 700 zu Schritt 702 zurück und setzt die Verarbeitung des Puffers 520 fort.
  • Das Verfahren 700 kann ein oder mehrere Male für jeden Durchlauf durch die Bildschirm-Raum-Pipeline durchgeführt werden. In Verbindung mit dem Durchführen des Verfahrens 700 kann die MP-Einheit 510 ebenfalls eine andere Technik zum Verfolgen durchführen, welche Zustandseinstellungen benötigen, um für nachfolgende Durchläufe vorhanden zu sein, wie in größerem Detail nachstehend in Verbindung mit 8 beschrieben.
  • 8 ist ein Ablaufdiagramm von Verfahrensschritten zum Bewahren des Zustands einer Graphikverarbeitungs-Pipeline über mehrere Durchläufe gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl die Verfahrensschritte in Verbindung mit den Systemen von 1 bis 6B beschrieben sind, werden Fachleute verstehen, dass jedes System, das konfiguriert ist, um die Verfahrensschritte in einer beliebigen Reihenfolge durchzuführen, innerhalb des Schutzumfangs der vorliegenden Erfindung ist.
  • Wie gezeigt, beginnt ein Verfahren 800 bei Schritt 802, wobei die MP-Einheit 510 die Verarbeitung des Puffers 520 beginnt. Bei Schritt 804 bestimmt die MP-Einheit 510, ob irgendwelche Zustandseinstellungen von dem Puffer 520 empfangen werden. Wenn keine Zustandseinstellungen empfangen werden, dann geht das Verfahren 800 zu Schritt 816 weiter, wo die MP-Einheit 510 bestimmt, ob zusätzlichen Daten im Puffer 520 resident sind. Wenn mehrere Daten tatsächlich im Puffer 520 umfasst sind, dann kehrt das Verfahren 800 zu Schritt 802 zurück.
  • Wenn bei Schritt 804 Zustandseinstellungen von dem Puffer 520 empfangen werden, dann geht das Verfahren 800 zu Schritt 806 weiter, wo die MP-Einheit 510 bestimmt, ob die gekachelte Zwischenspeicherung aktiv ist. Wenn die gekachelte Zwischenspeicherung nicht aktiv ist, dann überspringt das Verfahren 800 Schritte 808 und 810 und geht zu Schritt 812 weiter. Andernfalls geht das Verfahren 800 zu Schritt 808 weiter, wo die MP-Einheit 510 bestimmt, ob die letzte Cache-Kachel wiederholt wird. Wenn die letzte Cache-Kachel nicht wiederholt wird, dann geht das Verfahren 800 zu Schritt 818 weiter. Andernfalls geht das Verfahren 800 zu Schritt 810 weiter. Bei Schritt 810 bestimmt die MP-Einheit 510, ob der letzte Durchlauf des Intervalls wiederholt wird. Wenn der letzte Durchlauf nicht wiederholt wird, geht das Verfahren 800 zu Schritt 818. Andernfalls geht das Verfahren 800 zu Schritt 812 weiter. Bei Schritt 812 bestimmt die MP-Einheit 510, ob die Zustandsmaske den Zustand für alle Durchläufe freigibt. Wenn die Zustandsmaske tatsächlich den Zustand für alle Durchläufe freigibt, dann geht das Verfahren 800 zu Schritt 814 weiter. Bei Schritt 814 löscht die MP-Einheit 510 das Dirty-Bit für den betroffenen Zustand. Wenn bei Schritt 812 die Zustandsmaske den Zustand nicht für alle Durchläufe freigibt, dann geht das Verfahren 800 zu Schritt 818 weiter, wo das Dirty-Bit für den betroffenen Zustand gesetzt wird. Das Verfahren geht zu Schritt 816 weiter und fährt weiter fort, wie oben beschrieben. Wenn keine zusätzlichen Daten im Puffer 520 gefunden werden, ist das Verfahren 800 abgeschlossen.
  • Die MP-Einheit 510 kann das Verfahren 800 durchführen, um zu verfolgen, welche Zustandseinstellungen sich zwischen Durchläufen ändern. Die MP-Einheit 510 kann somit arbeiten, um den Gesamtzustand der Bildschirm-Raum-Pipeline 354 in den Anfangszustand wiederherzustellen, der für jeden getrennten Durchlauf benötigt wird. Mit dieser Vorgehensweise kann die MP-Einheit 510 Ressourcen schonen, in dem ein Rekonfigurieren der Bildschirm-Raum-Pipeline 354 vermieden wird, außer wenn benötigt. Die bisher beschriebenen Techniken können ebenfalls angepasst werden, um mehrere Durchläufe für Abschnitte des Puffers 520 durchzuführen und dann später mehrere Durchläufe für andere Abschnitte des Puffers 520 durchführen. Diese Vorgehensweise kann für bestimmte Graphikszenen wertvoll sein, die transparente Schichten beinhalten, die den Z-Puffer modifizieren, wie nachstehend in größerem Detail in Verbindung mit 9 bis 11 beschrieben.
  • Mehrfach-Durchlauf-Rendering über Mehrere Intervallgrenzen 9 ist eine Konzeptdarstellung, wie die MP-Einheit von 5 die Bildschirm-Raum-Pipeline von 3B konfiguriert, um mehrere Durchläufe durchzuführen, gemäß einer Ausführungsform der vorliegenden Erfindung. In dem hier erläuterten Beispiel ist die MP-Einheit 510 konfiguriert, um zwei Durchläufe durchzuführen.
  • Wie gezeigt, ist die MP-Einheit 510 konfiguriert, um den Puffer 920 zu verarbeiten. Der Puffer 920 ist im Allgemeinen analog zu dem in 5 bis 6B gezeigten Puffer 520. Der Puffer 920 ist jedoch verglichen mit dem Puffer 20 unterschiedlich organisiert und umfasst unterschiedliche Daten. Insbesondere ist der Puffer 920 in Intervalldaten 900(0) und 900(1) unterteilt. Die Intervalldaten 900(0) liegen zwischen den Intervallgrenzen B0 und B1. Die Intervalldaten 900(1) liegen zwischen den Intervallgrenzen B1 und B2. Alle Intervalldaten 900 umfassen Grundelementdaten, die 2-Bit-Grundelementmasken und Zustandsbündel mit 2-Bit-Zustandsmasken aufweisen, wie gezeigt ist.
  • Für jeden Satz von Intervalldaten 900 verarbeitet die MP-Einheit 510 die umfassten Grundelementdaten und Zustandseinstellungen mit einem oder mehreren Durchläufen, um Durchlaufdaten 930 zu erzeugen. Die Durchlaufdaten 930 umfassen Grundelemente und Zustandseinstellungen, die von dem Puffer 520 hergeleitet werden. Jeder unterschiedliche Satz von Durchlaufdaten 930 ist einem unterschiedlichen Intervall und einem unterschiedlichen Durchlauf zugeordnet. Für ein gegebenes Intervall und einen gegebenen Durchlauf verarbeitet die Bildschirm-Raum-Pipeline 354 die Grundelemente in den zugeordneten Durchlaufdaten basierend auf den entsprechenden Zustandseinstellungen auf die gleiche Art und Weise wie in Verbindung mit 6A bis 6H beschrieben. Jeder der von der MP-Einheit 510 für jedes Intervall durchgeführten Durchläufe wird nachstehend beschrieben.
  • Für Intervall 0, Durchlauf 0, erzeugt die MP-Einheit 510 Durchlaufdaten 930(00), die Grundelemente P0 und P1 und Zustandseinstellung S0 umfassen. Dabei parst die MP-Einheit 510 die Grundelemente und die Zustandseinstellungen zwischen den Grenzen B0 und B1, die auf den Durchlauf 0 anwendbar sind. Die MP-Einheit 510 kann dann die Bildschirm-Raum-Pipeline 354 basierend auf den extrahierten Zustandseinstellungen konfigurieren und bewirken, dass die konfigurierte Bildschirm-Raum-Pipeline 354 die extrahierten Grundelemente verarbeitet.
  • Für Intervall 0, Durchlauf 1, erzeugt die MP-Einheit 510 Durchlaufdaten 930(01), die Grundelemente P0 und P1 und Zustandseinstellungen S1 umfassen. Dabei parst die MP-Einheit 510 die Grundelemente und Zustandseinstellungen zwischen Grenzen B0 und B1, die auf den Durchlauf 1 anwendbar sind. Die MP-Einheit 510 kann dann die Bildschirm-Raum-Pipeline 354 basierend auf den extrahierten Zustandseinstellungen konfigurieren und bewirken, dass die konfigurierte Bildschirm-Raum-Pipeline 354 die extrahierten Grundelemente verarbeitet.
  • Wenn Durchlauf 1 von Intervall 0 abgeschlossen ist, dann kann die MP-Einheit 510 zu Intervall 1 weitergehen und Intervalldaten 900(1) verarbeiten. Dabei stellt jedoch die MP-Einheit 510 vorher die Zustandseinstellungen der Bildschirm-Raum-Pipeline 354 auf diejenigen wieder her, die für den Durchlauf 0 benötigt werden. Die MP-Einheit 510 kann sich dann auf eine ähnliche Vorgehensweise wie die oben in Verbindung mit 6A bis 6H beschriebene stützen, um diese Einstellungen wiederherzustellen. Sobald die Bildschirm-Raum-Pipeline 354 für den Durchlauf 0 konfiguriert ist, dann kann die MP-Einheit 510 zu Intervall 1 weitergehen.
  • Für Intervall 1, Durchlauf 0, erzeugt die MP-Einheit 510 Durchlaufdaten 930(10), die das Grundelement P2 und die Zustandseinstellung S0 umfassen. Dabei parst die MP-Einheit 510 die Grundelemente und die Zustandseinstellungen zwischen den Grenzen B1 und B2, die auf den Durchlauf 0 anwendbar sind. Die MP-Einheit 510 kann dann die Bildschirm-Raum-Pipeline 354 basierend auf den extrahierten Zustandseinstellungen konfigurieren und bewirken, dass die konfigurierte Bildschirm-Raum-Pipeline 354 die extrahierten Grundelemente verarbeitet.
  • Für Intervall 1, Durchlauf 1, erzeugt die MP-Einheit 510 Durchlaufdaten 930(11), die das Grundelement P2 und die Zustandseinstellung S1 umfasst. Dabei parst die MP-Einheit 510 die Grundelemente und die Zustandseinstellungen zwischen den Grenzen B1 und B2, die auf den Durchlauf 1 anwendbar sind. Die MP-Einheit 510 kann dann die Bildschirm-Raum-Pipeline 354 basierend auf den extrahierten Zustandseinstellungen konfigurieren und bewirken, dass die konfigurierte Bildschirm-Raum-Pipeline 354 die extrahierten Grundelemente verarbeitet.
  • Wenn der Durchlauf 1 des Intervalls 1 abgeschlossen ist, dann kann sich die MP-Einheit 510 zu einer nachfolgenden Kachel weiterbewegen und daher unterschiedliche Grundelementdaten und Zustandseinstellungen innerhalb des Puffers 920 verarbeiten. Dabei stellt jedoch die MP-Einheit 510 vorher die Zustandseinstellungen der Bildschirm-Raum-Pipeline 354 auf diejenigen wieder her, die für den Durchlauf 0 am Anfang einer Kachel benötigt werden. Die MP-Einheit 510 kann sich auf eine ähnliche Vorgehensweise wie die oben in Verbindung mit 6A bis 6H beschriebene stützen, um diese Einstellungen wiederherzustellen. Insbesondere kann die MP-Einheit 510 Dirty-Bits beibehalten, die angeben, welche Zustandseinstellungen in Vorbereitung für eine neue Kachel vorhanden sein müssen. Sobald die Bildschirm-Raum-Pipeline 354 für die nächste Kachel konfiguriert ist, dann kann die MP-Einheit 510 zu Intervall 0, Durchlauf 0 für diese Kachel weitergehen.
  • Die hier beschriebene Vorgehensweis kann in Graphikszenen angewendet werden, die komplexe transparente Schichten beinhalten, um zu bewirken, dass die Verarbeitung von bestimmten Schichten abgeschlossen wird, bevor zu der Verarbeitung von anderen Schichten weitergegangen wird. Eine beispielhafte Graphikszene, wobei die hier beschriebenen Techniken wirksam angewendet werden können, wird in größerem Detail nachstehend in Verbindung mit 10 beschrieben.
  • 10 ist eine Konzeptdarstellung, wie die von der MP-Einheit von 5 durchgeführten Operationen die Rendering-Effizienz und die Genauigkeit verbessern können, gemäß einer Ausführungsform der vorliegenden Erfindung. Insbesondere ist die MP-Einheit 510 konfiguriert, um das Rendering von spezifischen Sätzen an Grundelementen in unterschiedliche Intervalle zu trennen, um das ordnungsgemäße Rendering dieser Grundelemente zu unterstützen. Diese Funktionalität kann in einer weiten Vielfalt von unterschiedlichen Rendering-Situationen implementiert werden. Eine derartige beispielhafte Situation wird nachstehend beschrieben. In diesem Beispiel trennt die MP-Einheit 510 das Rendering von Grundelementen, wenn mehrere lichtundurchlässige und transparente Schichten zusammen gerendert werden.
  • Wie gezeigt, umfasst eine Graphikszene 1000 Schichten 1010, 1020 und 1030 einer Geometrie. Die Schicht 1010 ist eine lichtundurchlässige Schicht, die einen durch P1 dargestellten Satz von lichtundurchlässigen Grundelementen umfasst, die Schicht 1020 ist eine transparente Schicht, die einen durch P2 dargestellten Satz von transparenten Grundelementen umfasst, und die Schicht 1030 ist eine lichtundurchlässige Schicht, die einen durch P3 dargestellten Satz von lichtundurchlässigen Grundelemente umfasst. Die Grundelemente innerhalb der Schichten der Graphikszene 1000 werden von der Betrachtungsposition 1040 in der Reihenfolge der Anwendungsprogrammierschnittstelle (API = Application Programming Interface) gerendert. Die Grundelemente P1 der Schicht 1010 werden zuerst gerendert, die Grundelemente P2 der Schicht 1020 werden als zweites gerendert, und die Grundelemente P3 von Schicht 1030 werden zuletzt gerendert. In dem hier beispielhaft erläuterten Szenario beinhaltet das Rendering von Grundelementen P2 innerhalb der Schicht 1020 ein Aktualisieren von Z.
  • Wenn Grundelemente P2 der Schicht 1020 mit Grundelementen P1 der Schicht 1010 zusammen im gleichen Intervall gerendert würden, dann könnten Grundelemente P2 inkorrekt gerendert werden. Insbesondere würden, weil das Rendering von Grundelementen P2 ein Aktualisieren von Z beinhaltet und jene Grundelemente einige Grundelemente P1 aus der Perspektive von Position 1040 verdecken, die verdeckten Grundelemente in der Schicht 1010 nicht gerendert. Folglich würden Grundelemente P2 nicht innerhalb der verdeckten Grundelemente von Schicht 1010 vermischt. Somit würde, obwohl die Schicht 1020 transparent ist und ein gewisses Maß an Vermischung mit der Schicht 1010 aufweisen sollte, diese Vermischung fehlen.
  • Um jedoch Probleme, wie beispielsweise diese zu vermeiden, konfiguriert der Vorrichtungstreiber 103 die MP-Einheit 510, um das Rendering von Schichten 1010, 1020 und 1030 in drei unterschiedliche Intervalle zu trennen. Grundelemente P1, P2 und P3 würden daher unterschiedlichen Z-Durchläufen unterworfen, die jenen unterschiedlichen Intervallen zugeordnet sind, und die verdeckten Grundelemente innerhalb der Schicht 1010 würden nicht zugunsten der Grundelemente von Schicht 1020 verworfen. Die Grundelemente P1 innerhalb der Schicht 1010 würden in einem ersten Intervall gerendert, die Grundelemente P2 in der Schicht 1020 würden in einem zweiten Intervall gerendert und die Grundelemente P3 in der Schicht 1030 würden in einem dritten Intervall gerendert. Somit würden bei der Verarbeitung der Grundelemente P2 im zweiten Intervall die Bildschirm-Raum-Pipeline 354 die Grundelemente P2 innerhalb der Schicht 1020 rendern, um eine ordnungsgemäße Vermischung mit den Grundelementen P1 innerhalb der Schicht 1010 aufzuweisen, da die Grundelemente P1 bereits in dem vorangegangenen Intervall gerendert wurden.
  • Als eine allgemeine Angelegenheit kann der Vorrichtungstreiber 103 Situationen erfassen, wenn Intervallen benötigt werden, und dann die MP-Einheit 510 demgemäß konfigurieren. Dabei kann der Vorrichtungstreiber 103 den Zustand verfolgen, der von einer Anwendung verwendet wird, die Schichten von Grundelementen erzeugt, und dann bestimmen, wann sich diese Schichten zwischen transparenten Schichten, die ein Schreiben in Z beinhalten, und lichtundurchlässigen Schichten abwechseln. Der Vorrichtungstreiber 103 kann dann die MP-Einheit 510 konfigurieren, um die transparenten und lichtundurchlässigen Schichten in unterschiedliche Intervalle zu trennen. Beim Erfassen von transparenten Schichten kann der Vorrichtungstreiber 103 auf Alpha-Mischung-Durchlässigkeit (alpha blending transparency) prüfen, bestimmen, ob ein Fragmentschattierer Pixel verwirft, kennzeichnen, wann Z-Durchlauf-Pixelzählung aktiviert ist, und verschiedene andere Bedingungen kennzeichnen, um zu bestimmen, dass ein oder mehrere Intervalle nötig sein können.
  • Der Vorteil der hier beispielhaft beschriebenen Technik ist, dass die MP-Einheit 510 den Puffer 520 zwischen lichtundurchlässigen und transparenten Schichten nicht leeren muss, um ordnungsgemäßes Rendering zu bewahren. Somit können Grundelemente innerhalb der Graphikszene tief gelagert werden, wodurch Leistung verbessert wird. Fachleute werden verstehen, dass das hier erläuterte Beispiel lediglich dazu bestimmt ist, eine beispielhafte Situation zu vermitteln, wobei ein Trennen der Verarbeitung von Grundelemente über Intervalle vorteilhaft sein kann. Als eine allgemeine Angelegenheit kann die oben in Verbindung mit 9 beschriebene Technik in einer weiten Vielfalt von unterschiedlichen Szenarien angewendet werden, um das Rendering zu verbessern. Diese Technik wird in schrittweiser Art und Weise nachstehend in Verbindung mit 11 beschrieben.
  • 11 ist ein Ablaufdiagramm von Verfahrensschritten zum Konfigurieren einer Graphikverarbeitungs-Pipeline, um mehrere Durchläufe in mehreren Intervallen durchzuführen, gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl die Verfahrensschritte in Verbindung mit den Systemen von 1 bis 6B und 9 bis 10 beschrieben sind, werden Fachleute verstehen, dass jedes System, das konfiguriert ist, um die Verfahrensschritte in einer beliebigen Reihenfolge durchzuführen, innerhalb des Schutzumfangs der vorliegenden Erfindung ist.
  • Wie gezeigt, beginnt ein Verfahren 1100 bei Schritt 1102, wo die MP-Einheit 510 die Verarbeitung des Puffers 920 einleitet. Der Puffer 920 umfasst Grundelementdaten und Zustandsbündel ähnlich zu dem Puffer 520 von 5. Der Puffer 920 umfasst ebenfalls Intervallgrenzen, wie oben in Verbindung mit 9 beschrieben. Bei Schritt 1104 empfängt die MP-Einheit 510 eine Intervallgrenze. Bei Schritt 1106 bestimmt die MP-Einheit 510 basierend auf der Intervallgrenze die Anzahl der von der Bildschirm-Raum-Pipeline 354 durchzuführenden Durchläufe. Bei Schritt 1108 konfiguriert die MP-Einheit 510 die Bildschirm-Raum-Pipeline 354 für jeden Durchlauf in dem Intervall, um die Graphikgrundelemente innerhalb dieses Intervalls zu verarbeiten. Beim Durchführen der mehreren Durchläufe stützt sich die MP-Einheit 510 auf eine in Verbindung mit 6A bis 6H beschriebene ähnliche Technik.
  • Bei Schritt 1110 bestimmt die MP-Einheit 510, ob das aktuelle Intervall abgeschlossen ist. Wenn das Intervall nicht abgeschlossen ist, kehrt das Verfahren 1100 zu Schritt 1108 zurück. Wenn das Intervall abgeschlossen ist, was bedeutet, dass alle Grundelemente in dem Intervall über die angegebene Anzahl von Durchläufen verarbeitet wurden, dann geht das Verfahren zu Schritt 1112 weiter.
  • Bei Schritt 1112 bringt die MP-Einheit 510 die Bildschirm-Raum-Pipeline 354 in den Anfangszustand zurück, der dem ersten Durchlauf des zuletzt abgeschlossenen Intervalls zugeordnet ist. Dabei wird die Pipeline für nachfolgende Intervalle bereitgemacht. Die MP-Einheit 510 kann sich auf ein Dirty-Bit-Register 660 beim Durchführen von Schritt 1112 stützen. Bei Schritt 1114 bestimmt die MP-Einheit 510, ob die aktuelle Kachel abgeschlossen ist. Wenn die Kachel noch nicht abgeschlossen ist, dann kehrt das Verfahren 1100 zu Schritt 1102 zurück und fährt mit dem nächsten Intervall fort. Andernfalls geht das Verfahren 1100 zu Schritt 1116 weiter. Bei Schritt 1116 bringt die MP-Einheit 510 die Bildschirm-Raum-Pipeline 354 in den Anfangszustand zurück, der zur Verarbeitung einer Kachel benötigt wird. Die MP-Einheit 510 kann sich auf das Dirty-Bit-Register 660 oder einem anderen Satz von Dirty-Bits, der zum Verfolgen des Anfangszustands der Kachel verwendet wird, beim Durchführen von Schritt 1114 stützen.
  • Fachleute werden erkennen, dass das Verfahren 1100 in Verbindung mit den oben beschriebenen Verfahren 700 und 800 jeweils in Verbindung mit 7 und 8 implementiert werden kann. Beispielsweise können die in dem Verfahren 700 durchgeführten Techniken angewendet werden, um Schritt 1108 des Verfahrens 1100 durchzuführen. Gleichermaßen können die in dem Verfahren 800 durchgeführten Techniken angewendet werden, um Schritte 1112 und/oder 1116 des Verfahrens 1100 durchzuführen.
  • Die oben beschriebenen Mehrfach-Durchlauf-Techniken können an einiger oder der gesamten Hardware innerhalb der Bildschirm-Raum-Pipeline 354 durchgeführt werden. Ferner können einige Durchläufe lediglich einen Abschnitt der Bildschirm-Raum-Pipeline 254 benötigen, während andere Durchläufe lediglich einen unterschiedlichen Abschnitt benötigen. Beispielsweise können Pixel-Schattierungsoperationen an einem SM 310 durchgeführt werden, während verschiedene ROP-Operationen innerhalb ROP 395 stattfinden. Um eine derartige nebenläufige Verarbeitung zu implementieren, kann die Graphikverarbeitungs-Pipeline 350 in gleicher Art und Weise konfiguriert werden, wie nachstehend in Verbindung mit 12 bis 13 beschrieben.
  • Parallele Ausführung von Durchlaufen
  • 12 veranschaulicht einen Abschnitt der Bildschirm-Raum-Pipeline von 3B, die konfiguriert ist, um unterschiedliche Durchläufe gleichzeitig durchzuführen, die unterschiedliche Cache-Kacheln beinhalten, gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt, umfasst die Bildschirm-Raum-Pipeline 354 die Einrichtungseinheit (Setup) 380, die Rastereinheit (Raster) 385; die PROP 1205, die ZROP 1210, den Zuerst-hinein/zuerst-hinaus FIFO 1225 und den SM 310. Die PROP 1205 und die ZROP 1210 können innerhalb der ROP 395 von 3B umfasst sein. Der SM 310 ist konfiguriert, um Pixelschattierungsprogramme auszuführen und kann somit die PS 390 implementieren, wie ebenfalls in 3B gezeigt. Die PROP 1205 ist mit der ZROP 1210 über einen Datenpfad 1215 gekoppelt. Die PROP 1205 ist ebenfalls mit dem SM 310 über einen Datenpfad 1220 gekoppelt. Der FIFO 1225 liegt innerhalb des Datenpfads 1220.
  • Die Bildschirm-Raum-Pipeline 354 implementiert die oben in Verbindung mit 5 bis 11 erläuterten Mehrfach-Durchlauftechniken, um unterschiedliche Durchläufe an Cache-Kacheln durchzuführen. Bestimmte Arten von Durchläufen stützen sich auf den Datenpfad 1215, während andere Arten von Durchläufen von dem Datenpfad 1220 abhängen. Beispielsweise sendet für Arten von Durchläufen, die Früh-Z-Arbeit beinhalten, die PROP 1205 Kacheldaten an die ZROP 1210 über den Datenpfad 1215 zur Verarbeitung. Für Arten von Durchläufen, die Farbschattierung beinhalten, sendet die PROP 1205 jedoch Kacheldaten an den SM 310 über den Datenpfad 1220 zur Verarbeitung.
  • Die Bildschirm-Raum-Pipeline 354 kann unterschiedliche Kacheldaten über Datenpfade 1215 und 1220 zur gleichzeitigen Verarbeitung durch die ZROP 1210 bzw. den SM 310 übertragen, wodurch bestimmte Arten von Durchläufen parallelisiert werden. Es sei beispielsweise angenommen, dass die Bildschirm-Raum-Pipeline 354 konfiguriert ist, um zwei Durchläufe an Cache-Kacheln, einen Nur-Z-Durchlauf gefolgt von einem Farbdurchlauf, durchzuführen. Die PROP 1205 könnte eine Kachel 1230 empfangen und diese Kachel an die ZROP 1210 über den Pfad 1215 für den Früh-Z-Durchlauf übertragen. Wenn die Früh-Z-Verarbeitung für die Kachel 1230 abgeschlossen ist, dann würde die PROP 1205 die verarbeitete Kachel in den FIFO 1225 drücken. Die PROP 1205 könnte dann eine Kachel 1240 empfangen und diese Kachel an die ZROP 1210 über den Pfad 1215 für einen Früh-Z-Durchlauf übertragen. Während die ZROP 1210 den Früh-Z-Durchlauf an der Kachel 1240 durchführt, könnte der SM 310 den FIFO 1225 entleeren und den Farbdurchlauf an der Kachel 1230 durchführen. Diese Funktionalität kann die Geschwindigkeit verbessern, mit der die Bildschirm-Raum-Pipeline 354 Durchläufe durch gleichzeitiger Benutzung mehrere Datenpfade durchführen kann, wodurch Latenzen verborgen werden, die sich potenziell jeder derartigere Pfad zuziehen kann.
  • Im Allgemeinen ist der FIFO 1225 dimensioniert, um alle Datenpakete unterzubringen, die einer gesamten Cache-Kachel zugeordnet sind. Somit kann die PROP 1205 die ganze Kachel 1230 innerhalb des FIFO 1225 speichern und dann ausreichende Speicherressourcen wiedererwerben, um einiges oder alles der Kachel 1240 an die ZROP 1210 zu übertragen. Wegen des fehlenden FIFO 1225 kann der SM 310 nicht imstande sein, alle Pakete einer gegebenen Kachel zu empfangen, bevor die nachfolgende Kachel von der PROP 1205 empfangen wird. In dem oben erläuterten Beispiel kann die PROP 1205 ohne den FIFO 1225 nicht imstande sein, die ganze Kachel 1230 an den SM 310 für den Farbdurchlauf zu übertragen. Dies könnte einen Druck gegen die PROP 1205 verursachen, und so würde die Früh-Z-Verarbeitung der Kachel 1240 zum Stillstand gebracht, was die Bildschirm-Raum-Pipeline 254 potenziell serialisiert. Ein Implementieren des FIFO 1225 in der beschriebenen Art und Weise umgeht jedoch diese Thematik und ermöglicht, dass unterschiedliche Durchläufe für unterschiedliche Kacheln parallelisiert werden können. Fachleute werden verstehen, dass verschiedene andere Arten von Durchläufen in der hier beschriebenen Art und Weise über jene hinaus parallelisiert werden können, welche die oben beispielhaft beschriebene Hardware beinhalten.
  • Die Bildschirm-Raum-Pipeline 354 ist ebenfalls konfiguriert, um mit dem Vorrichtungstreiber 103 zu interoperieren, um den SM 310 auf einer Per-Durchlauf-Grundlage zu konfigurieren. Insbesondere kann der Vorrichtungstreiber 103 Pixelschattierer konfigurieren, die auf dem SM 310 ausgeführt werden, um unterschiedliche Arten von Schattierungsoperationen abhängig von dem aktuellen Durchlauf durchzuführen. Diese Funktionalität kann die Effizienz von Mehrfach-Durchlauf-Konfigurationen verbessern, wobei Spät-Z während eines Durchlaufs gefolgt von Farbschattierung in einem nachfolgenden Durchlauf aktiviert wird. In einer herkömmlichen Konfiguration würde der Pixelschattierer eine Farbschattierung durchführen, wenn Spät-Z-Operationen ausgeführt werden, um Sichtbarkeit zu berechnen. In einer Mehrfach-Durchlauf-Konfiguration muss eine Farbschattierung jedoch nicht bis zum tatsächlichen Farbschattierungsdurchlauf durchgeführt werden.
  • Somit kann der Vorrichtungstreiber 103 den SM 310 konfigurieren, um ein leichtgewichtiges Schattierungsprogramm während Spät-Z-Durchläufen auszuführen, das lediglich Sichtbarkeit berechnet und keine volle Farbschattierung durchführt. Der Spät-Z-Durchlauf kann nur die Z-Cull-Einheit beeinflussen. Dann kann während nachfolgender Farbschattierungsdurchläufen der Vorrichtungstreiber 103 den SM 310 veranlassen, eine maximale Farbschattierung durchzuführen. Diese Vorgehensweise kann allgemein angewendet werden, um eine Farbschattierung unter Verwendung einer Kombination aus Z-Vordurchlauf und Z-Cull zu verringern.
  • Der Vorrichtungstreiber 103 konfiguriert den SM 310, um eine durchlaufabhängige Schattierung unter Verwendung von Zustandsbündeln durchzuführen. Der Vorrichtungstreiber 103 kann ein Zustandsbündel an den SM 310 übertragen, das einen oder mehrere Durchläufe angibt, und Konfigurationsdaten, die für diese Durchläufe relevant sind. Der SM 310 kann dann bestimmte Operationen für die angegebenen Durchläufe basierend auf den enthaltenen Konfigurationsdaten durchführen. Beispielsweise könnte der Vorrichtungstreiber 103 ein Zustandsbündel übertragen, das angibt, dass während eines ersten Durchlaufs der SM 310 lediglich Sichtbarkeit berechnen und von der Durchführung schwerer Farbschattierungsarbeiten absehen sollte. Dann könnte ein nachfolgendes Zustandsbündel ein bestimmtes Schattierungsprogramm angeben, das der SM 310 während eines zweiten Durchlaufs ausführen sollte. Der SM 310 ist konfiguriert, um die Daten innerhalb des empfangenen Zustandsbündels zu lesen und dann die relevante Operation durchzuführen. In einer Ausführungsform überträgt der Vorrichtungstreiber 103 Zustandsbündel an den SM 310, die eine Zustandsmaske ähnlich derjenigen umfassen, die oben in Verbindung mit 5 bis 11 beschrieben wurden. Die enthaltene Zustandsmaske gibt in der zuvor beschriebenen Art und Weise an, für welche Durchläufe die Konfigurationsdaten relevant sind.
  • 13 ist ein Ablaufdiagramm von Verfahrensschritten zur nebenläufigen Verarbeitung mehrerer Cache-Kacheln gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl die Verfahrensschritte in Verbindung mit den Systemen von 1 bis 6H, 9 bis 10 und 12 beschrieben werden, werden Fachleute verstehen, dass jedes System, das konfiguriert ist, um die Verfahrensschritte in einer beliebigen Reihenfolge durchzuführen, innerhalb des Schutzumfangs der vorliegenden Erfindung ist.
  • Wie gezeigt, beginnt ein Verfahren 1300 bei Schritt 1302, wobei die Bildschirm-Raum-Pipeline 354 eine erste Kachel empfängt, die für einen Schattierungsdurchlauf bereit ist. Die Bildschirm-Raum-Pipeline 354 führte bereits einen vorhergehenden Nur-Z-Durchlauf an der ersten Kachel unter Verwendung der ZROP 1210 durch. Bei Schritt 1304 puffert der FIFO 1225 die erste Kachel. Der FIFO 1225 ist allgemein dimensioniert, um eine gesamte Cache-Kachel unterzubringen, wodurch die Last des Speicherns der Abschnitte dieser Kachel von der PROP 1205 entfernt wird. Bei Schritt 1306 empfängt die PROP 1205 eine zweite Kachel, die für einen Nur-Z-Durchlauf bereit ist. Die PROP 1205 kann dann die zweite Kachel an die ZROP 1210 zur Verarbeitung übertragen. Bei Schritt 1308 führt der SM 310 einen Schattierungsdurchlauf mit der ersten Kachel aus, während die ZROP 1210 gleichzeitig einen Nur-Z-Durchlauf mit der zweiten Kachel ausführt. Das Verfahren 1300 endet dann.
  • Die Bildschirm-Raum-Pipeline 1300 kann das Verfahren 1300 implementieren, um zwei ansonsten serielle Aufgaben zu parallelisieren, wodurch die Latenzverbergung und die Verarbeitung von Kacheln beschleunigt werden. Die oben beschriebenen Techniken können ebenfalls in anderen Zusammenhängen implementiert werden. Als eine allgemeine Angelegenheit fällt jede Vorgehensweise, um unterschiedliche Durchläufe in der Bildschirm-Raum-Pipeline 354 zu parallelisieren, innerhalb des Schutzumfangs der vorliegenden Erfindung.
  • 14 ist ein Ablaufdiagramm von Verfahrensschritten zum Durchführen einer durchlaufabhängigen Farbschattierung, gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl die Verfahrensschritte in Verbindung mit den Systemen von 1 bis 6H, 9 bis 10 und 12 beschrieben werden, werden Fachleute verstehen, dass jedes System, das konfiguriert ist, um die Verfahrensschritte in einer beliebigen Reihenfolge durchzuführen, innerhalb des Schutzumfangs der vorliegenden Erfindung ist.
  • Wie gezeigt, beginnt ein Verfahren 1400 bei Schritt 1402, wo der SM 310 ein erstes Zustandsbündel von dem Vorrichtungstreiber 103 empfängt, das erste Konfigurationsdaten für einen ersten Durchlauf umfasst. Das erste Zustandsbündel kann eine Zustandsmaske umfassen, die angibt, dass die ersten Konfigurationsdaten auf den ersten Durchlauf angewendet werden sollten. Die ersten Konfigurationsdaten könnten beispielsweise bestimmte Werte oder ein Programmcode neben anderen Möglichkeiten sein. Der erste Durchlauf kann Sichtbarkeitsberechnungen umfassen, die dem Spät-Z-Modus zugeordnet sind. Bei Schritt 1404 führt der SM 310 ein Schattierungsprogramm (shader program) mit einer Cache-Kachel basierend auf der ersten Konfiguration für den ersten Durchlauf aus. Dabei kann der SM 310 Sichtbarkeitsdaten für die Cache-Kachel ohne Durchführen einer Farbschattierung berechnen.
  • Bei Schritt 1406 empfängt der SM 310 ein zweites Zustandsbündel von dem Vorrichtungstreiber 103, das zweite Konfigurationsdaten für einen zweiten Durchlauf umfasst. Das zweite Zustandsbündel kann eine Zustandsmaske umfassen, die angibt, dass die zweiten Konfigurationsdaten auf den zweiten Durchlauf angewendet werden sollten. Die zweiten Konfigurationsdaten könnten beispielsweise bestimmte Werte oder ein Programmcode neben anderen Möglichkeiten sein. Der zweite Durchlauf kann Farbschattierungs-Operationen umfassen, die dem Spät-Z-Modus zugeordnet sind. Bei Schritt 1408 führt der SM 310 ein Schattierungsprogramm mit der Cache-Kachel basierend auf der zweiten Konfiguration für den zweiten Durchlauf aus. Dabei kann der SM 310 Farbschattierungs-Operationen mit der Cache-Kachel durchführen.
  • Die oben beschriebene Technik kann angewendet werden, um die Menge an Farbschattierung zu verringern, die benötigt wird, wenn Cache-Kacheln verarbeitet werden. Insbesondere kann das Verfahren 1400 implementiert werden, um Farbschattierungsoperationen während Durchläufen zu verringern, die keine bedeutende Farbschattierung benötigen, und lediglich bedeutende Farbschattierungsoperationen für Durchläufe durchführen, die schwierige Farbschattierungsoperationen beinhalten. Fachleute werden erkennen, dass die oben jeweils in Verbindung mit 13 und 14 beschriebenen Verfahren 1300 und 1400 in Verbindung miteinander praktiziert werden können, um die Effizienz der Bildschirm-Raum-Pipeline 354 weiter zu verbessern. Beispielsweise kann das Verfahren 1300 implementiert werden, um die Effizienz, mit der erste und zweite Kacheln während ersten und zweiten Durchläufen verarbeitet werden, gegenüber denjenigen Kacheln zu verbessern, die Früh-Z-Arbeit beinhalten. Dann kann das Verfahren 1400 angewendet werden, um die Effizienz, mit der die ersten und zweiten Kacheln während dritter und vierter Durchläufe verarbeitet werden, gegenüber denjenigen Kacheln zu verbessern, die Spät-Z-Arbeit beinhalten.
  • In Summe interoperiert eine Mehrfach-Durchlaufeinheit mit einem Vorrichtungstreiber, um eine Bildschirm-Raum-Pipeline zu konfigurieren, um mehrere Verarbeitungsdurchläufe mit gepufferten Graphikgrundelementen durchzuführen. Die Mehrfach-Durchlaufeinheit empfängt Grundelementdaten und Zustandsbündel von dem Vorrichtungstreiber. Die Grundelementdaten umfassen ein Graphikgrundelement und eine Grundelementmaske. Die Grundelementmaske gibt die spezifischen Durchläufe an, wann das Graphikgrundelement verarbeitet werden sollte. Die Zustandsbündel umfassen eine oder mehrere Zustandseinstellungen und eine Zustandsmaske. Die Zustandsmaske gibt die spezifischen Durchläufe an, wobei die Zustandseinstellungen angewendet werden sollten. Für einen gegebenen Durchlauf extrahiert die Mehrfach-Durchlaufeinheit die Zustandseinstellungen für diesen Durchlauf und konfiguriert dann die Bildschirm-Raum-Pipeline gemäß diesen Zustandseinstellungen. Die Mehrfach-Durchlaufeinheit extrahiert ebenfalls die in diesem Durchlauf zu verarbeitenden Graphikgrundelemente. Dann bewirkt die Mehrfach-Durchlaufeinheit, dass die konfigurierte Bildschirm-Raum-Pipeline die extrahierten Graphikgrundelemente verarbeitet.
  • Mindestens ein Vorteil der hier beschriebenen Techniken ist, dass die Bildschirm-Raum-Pipeline konfiguriert werden kann, um verschiedene Z-Durchläufe mit gepufferten Grundelementen durchzuführen und dann anschließend Farbschattierungsdurchläufe mit diesen gleichen gepufferten Grundelementen durchführen. Somit können bestimmte Arten von Graphikszenen ohne die Notwendigkeit, Graphikdaten erneut aus dem Speicher abzurufen, korrekt gerendert werden. Diese Techniken können den Leistungsverbrauch verringern und daher die Batterielebensdauer von mobilen Vorrichtungen verbessern.
  • Die Beschreibungen der verschiedenen Ausführungsformen wurden für Zecke der Veranschaulichung vorgestellt, wobei sie jedoch nicht dazu gedacht sind, erschöpfend oder auf die offenbarten Ausführungsformen beschränkt zu sein. Viele Modifikationen und Variationen werden Fachleuten offensichtlich sein, ohne vom Umfang und Wesen der beschriebenen Ausführungsformen abzuweichen.
  • Aspekte der vorliegenden Ausführungsformen können als ein System, Verfahren oder Computerprogrammprodukt verkörpert sein. Demgemäß können Aspekte der vorliegenden Offenbarung die Form einer reinen Hardware-Ausführungsform, einer reinen Software-Ausführungsform (einschließlich Firmware, residenter Software, Mikrocode, usw.) oder einer Ausführungsform, die Software- und Hardware-Aspekte kombiniert, annehmen, die hier alle allgemein als „Schaltung”, ”Modul” oder ”System” bezeichnet werden können. Des Weiteren können Aspekte der vorliegenden Offenbarung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medium(Medien) verkörpert wird, die darauf verkörperten computerlesbaren Programmcode aufweisen.
  • Jede Kombination aus einem oder mehrere computerlesbares Medien kann benutzt werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann beispielsweise, jedoch ohne darauf begrenzt zu sein, ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleiter System, -Einrichtung oder -Vorrichtung oder jede geeignete Kombination des Vorhergehenden sein. Spezifischere Beispiele (eine nicht erschöpfende Liste) des computerlesbaren Speichermediums würde Folgendes umfassen: eine elektrische Verbindung mit einer oder mehreren Leitungen, eine tragbaren Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), einen löschbaren programmierbaren Festwertspeicher (EPROM oder Flash-Speicher), einen Lichtwellenleiter, einen tragbaren Compactdisk-Festwertspeicher (CD-ROM), eine optische Speichervorrichtung, eine magnetische Speichervorrichtung oder jede geeignete Kombination des Vorhergehenden. Im Kontext dieses Dokuments kann ein computerlesbares Speichermedium jedes materielle Medium sein, das ein Programm zur Verwendung durch oder in Verbindung mit einem Anweisungsausführungssystem, einer Einrichtung oder Vorrichtung enthalten oder speichern kann.
  • Aspekte der vorliegenden Offenbarung werden oben mit Bezug auf Ablaufdiagramme und/oder Blockdiagramme von Verfahren, Einrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Offenbarung beschrieben. Es versteht sich, dass jeder Block der Ablaufdiagramme und/oder der Blockdiagramme und Kombinationen von Blöcken in den Ablaufdiagrammen und/oder Blockdiagrammen durch Computerprogramm-Anweisungen implementiert werden können. Diese Computerprogramm-Anweisungen können für einen Prozessor eines Allzweckcomputers, Spezialzweckcomputers oder einer sonstigen programmierbaren Datenverarbeitungseinrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die Anweisungen, die über den Prozessor des Computers oder einer sonstigen programmierbaren Datenverarbeitungseinrichtung ausgeführt werden, die Implementierung der in dem Ablaufdiagramm und/oder Blockdiagramm oder Blockdiagramm spezifizierten Funktionen/Handlungen ermöglichen. Derartige Prozessoren können, ohne einschränkend zu sein, Allzweck-Prozessoren, Spezialzweck-Prozessoren, anwendungsspezifischen Prozessoren oder feldprogrammierbare Prozessoren sein.
  • Die Ablaufdiagramme und die Blockdiagramme in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedener Ausführungsformen der vorliegenden Offenbarung. In dieser Hinsicht kann jeder Block in den Ablaufdiagrammen oder Blockdiagrammen ein Modul, ein Segment oder einen Abschnitt eines Codes darstellen, der eine oder mehrere ausführbare Anweisungen zum Implementieren der spezifizierten logischen Funktion(en) umfasst. Es sei ebenfalls bemerkt, dass in einigen alternativen Implementierungen die in dem Block erwähnten Funktionen außerhalb der in den Figuren erwähnten Reihenfolge auftreten können. Beispielsweise können zwei aufeinanderfolgend gezeigte Blöcke tatsächlich im Wesentlichen nebenläufig ausgeführt werden oder die Blöcke können einige Male in umgekehrter Reihenfolge abhängig von der beteiligten Funktionalität ausgeführt werden. Es sei ebenfalls bemerkt, dass jeder Block der Blockdiagramme und/oder der Ablaufdiagramme sowie Kombinationen von Blöcken in den Blockdiagrammen und/oder den Ablaufdiagrammen von Spezialzweck-Hardware-basierten Systemen, welche die spezifizierten Funktionen oder Handlungen oder Kombinationen von Spezialzweck-Hardware und Computeranweisungen durchführen, implementiert werden können.
  • Während das Vorhergehende auf Ausführungsformen der vorliegenden Offenbarung gerichtet ist, können andere und weitere Ausführungsformen der Offenbarung erdacht werden, ohne vom grundlegenden Schutzumfang derselben abzuweichen, wobei der Umfang derselben von den Ansprüchen bestimmt wird, die folgen.

Claims (15)

  1. Graphiksubsystem zur Verarbeitung von Graphikgrundelementen, wobei das Subsystem, umfasst: eine Bildschirm-Raum-Pipeline, die konfiguriert ist, um Graphikgrundelemente in mehreren Durchläufen zu verarbeiten; und eine Mehrfach-Durchlaufeinheit, die einen Puffer umfasst und konfiguriert ist, um: ein erstes Graphikgrundelement aus einem ersten Abschnitt des Puffers zur Verarbeitung in einem ersten Durchlauf durch die Bildschirm-Raum-Pipeline zu extrahieren und das erste Graphikgrundelement aus dem ersten Abschnitt des Puffers zur Verarbeitung in einem zweiten Durchlauf durch die Bildschirm-Raum-Pipeline zu extrahieren.
  2. Graphiksubsystem gemäß Anspruch 1, wobei die Mehrfach-Durchlaufeinheit ferner eine Durchlaufmaske umfasst, die einen aktuellen Durchlauf in den mehreren Durchläufen angibt.
  3. Graphiksubsystem gemäß Anspruch 2, wobei das erste Graphikgrundelement einer ersten Grundelementmaske zugeordnet ist, die angibt, dass das erste Graphikgrundelement im ersten Durchlauf durch die Bildschirm-Raum-Pipeline zu verarbeiten ist.
  4. Graphiksubsystem gemäß Anspruch 3, wobei die Mehrfach-Durchlaufeinheit das erste Graphikgrundelement aus dem ersten Abschnitt des Puffers extrahiert, durch: Vergleichen eines ersten Bits der Durchlaufmaske mit einem entsprechenden ersten Bit der ersten Grundelementmaske; und Bestimmen, dass das erste Bit und das entsprechende erste Bit beide gesetzt sind, wobei das erste Bit angibt, dass der aktuelle Durchlauf der erste Durchlauf ist, und das erste entsprechende Bit angibt, dass das erste Graphikgrundelement im ersten Durchlauf zu verarbeiten ist.
  5. Graphiksubsystem gemäß Anspruch 3 oder 4, wobei das erste Grundelementmaske ferner angibt, dass das erste Graphikgrundelement in einem zweiten Durchlauf durch die Bildschirm-Raum-Pipeline zu verarbeiten ist, und wobei die Mehrfach-Durchlaufeinheit das erste Graphikgrundelement aus dem ersten Abschnitt des Puffers zur Verarbeitung im zweiten Durchlauf extrahiert, durch: Vergleichen eines zweiten Bits der Durchlaufmaske mit einem entsprechenden zweiten Bit der ersten Grundelementmaske; und Bestimmen, dass das zweite Bit und das entsprechende zweite Bit beide auf Eins gesetzt sind, wobei das zweite Bit angibt, dass der aktuelle Durchlauf der zweite Durchlauf ist, und das zweite entsprechende Bit angibt, dass das erste Graphikgrundelement im zweiten Durchlauf zu verarbeiten ist.
  6. Graphiksubsystem gemäß einem der Ansprüche 2 bis 5, wobei das Puffer ferner ein erstes Zustandsbündel umfasst, das eine erste Zustandsmaske und einen ersten Satz von Zustandseinstellungen zum Konfigurieren der Bildschirm-Raum-Pipeline umfasst, wobei die erste Zustandsmaske einen oder mehrere Durchläufe angibt, wobei der erste Satz von Zustandseinstellungen beim Konfigurieren der Bildschirm-Raum-Pipeline zur Verarbeitung anzuwenden ist.
  7. Graphiksubsystem gemäß Anspruch 6, wobei die Mehrfach-Durchlaufeinheit ferner konfiguriert ist, um: das erste Zustandsbündel aus dem Puffer zu extrahieren; bestimmen, dass die erste Zustandsmaske angibt, dass der erste Satz von Zustandseinstellungen beim Konfigurieren der Bildschirm-Raum-Pipeline für den ersten Durchlauf anzuwenden ist; und die Bildschirm-Raum-Pipeline für den ersten Durchlauf basierend auf dem ersten Satz von Zustandseinstellungen zu konfigurieren.
  8. Graphiksubsystem gemäß Anspruch 7, wobei der Puffer ferner ein zweites Zustandsbündel umfasst, das eine zweite Zustandsmaske und einen zweiten Satz von Zustandseinstellungen zum Konfigurieren der Bildschirm-Raum-Pipeline umfasst, wobei die zweite Zustandsmaske eine oder mehrere Durchläufe angibt, wobei der zweite Satz von Zustandseinstellungen beim Konfigurieren der Bildschirm-Raum-Pipeline zur Verarbeitung anzuwenden ist.
  9. Graphiksubsystem gemäß Anspruch 8, wobei die Mehrfach-Durchlaufeinheit ferner konfiguriert ist, um: das zweite Zustandsbündel aus dem Puffer zu extrahieren; zu bestimmen, dass die zweite Zustandsmaske angibt, dass der zweite Satz von Zustandseinstellungen beim Konfigurieren der Bildschirm-Raum-Pipeline für den zweiten Durchlauf anzuwenden ist; und die Bildschirm-Raum-Pipeline für den zweiten Durchlauf basierend auf dem zweiten Satz von Zustandseinstellungen zu konfigurieren.
  10. Graphiksubsystem gemäß einem der vorhergehenden Ansprüche, wobei die Mehrfach-Durchlaufeinheit ferner konfiguriert ist, um: die Bildschirm-Raum-Pipeline zur Verarbeitung des ersten Graphikgrundelements im ersten Durchlauf zu konfigurieren; die Bildschirm-Raum-Pipeline zur Verarbeitung des ersten Graphikgrundelements im zweiten Durchlauf zu konfigurieren; die Bildschirm-Raum-Pipeline zur Verarbeitung eines zweiten Graphikgrundelements in einem zusätzlichen ersten Durchlauf zu konfigurieren; und die Bildschirm-Raum-Pipeline zur Verarbeitung des zweiten Graphikgrundelements in einem zusätzlichen zweiten Durchlauf zu konfigurieren.
  11. Graphiksubsystem gemäß Anspruch 10, wobei die Mehrfach-Durchlaufeinheit ferner konfiguriert ist, um: das zweite Graphikgrundelement aus einem zweiten Abschnitt des Puffers zur Verarbeitung im zusätzlichen ersten Durchlauf durch die Bildschirm-Raum-Pipeline zu extrahieren, und das zweite Graphikgrundelement aus dem zweiten Abschnitt des Puffers zur Verarbeitung in dem zusätzlichen zweiten Durchlauf durch die Bildschirm-Raum-Pipeline zu extrahieren.
  12. Graphiksubsystem gemäß Anspruch 11, wobei die Mehrfach-Durchlaufeinheit ein Dirty-Bit-Register umfasst, das ein erstes Dirty-Bit aufweist, das einem der Bildschirm-Raum-Pipeline zugeordneten Anfangszustand entspricht, wobei die Bildschirm-Raum-Pipeline zur Verarbeitung basierend auf dem Anfangszustand vor dem ersten Durchlauf und vor dem zusätzlichen ersten Durchlauf konfiguriert ist.
  13. System zur Verarbeitung von Graphikgrundelementen, wobei das System umfasst: eine Graphikverarbeitungs-Pipeline, die umfasst: eine Bildschirm-Raum-Pipeline, die konfiguriert ist, um Graphikgrundelemente in mehreren Durchläufen zu verarbeiten; und eine Mehrfach-Durchlaufeinheit, die einen Puffer umfasst und konfiguriert ist, um: ein erstes Graphikgrundelement aus einem ersten Abschnitt des Puffers zur Verarbeitung in einem ersten Durchlauf durch die Bildschirm-Raum-Pipeline zu extrahieren, und das erste Graphikgrundelement aus dem ersten Abschnitt des Puffers zur Verarbeitung in einem zweiten Durchlauf durch die Bildschirm-Raum-Pipeline zu extrahieren.
  14. Computerimplementiertes Verfahren zur Verarbeitung von Graphikgrundelementen, wobei das Verfahren umfasst: Extrahieren eines ersten Graphikgrundelements aus einem ersten Abschnitt eines Puffers zur Verarbeitung in einem ersten Durchlauf durch eine Bildschirm-Raum-Pipeline; Extrahieren des ersten Graphikgrundelements aus dem ersten Abschnitt des Puffers zur Verarbeitung in einem zweiten Durchlauf durch die Bildschirm-Raum-Pipeline; Extrahieren eines zweiten Graphikgrundelements aus einem zweiten Abschnitt des Puffers zur Verarbeitung in einem zusätzlichen ersten Durchlauf durch die Bildschirm-Raum-Pipeline; und Extrahieren des zweiten Graphikgrundelements aus dem zweiten Abschnitt des Puffers zur Verarbeitung in einem zusätzlichen zweiten Durchlauf durch die Bildschirm-Raum-Pipeline.
  15. Computerimplementiertes Verfahren gemäß Anspruch 14, ferner umfassend: Konfigurieren der Bildschirm-Raum-Pipeline für den ersten Durchlauf basierend auf einem ersten Zustandsbündel, das einen ersten Satz von Zustandseinstellungen umfasst; Konfigurieren der Bildschirm-Raum-Pipeline für den zweiten Durchlauf basierend auf einem zweiten Zustandsbündel, das einen zweiten Satz von Zustandseinstellungen umfasst; Konfigurieren der Bildschirm-Raum-Pipeline für den zusätzlichen ersten Durchlauf basierend auf dem ersten Zustandsbündel; und Konfigurieren der Bildschirm-Raum-Pipeline für den zusätzlichen zweiten Durchlauf basierend auf dem zweiten Zustandsbündel.
DE102016122297.6A 2015-11-25 2016-11-21 Mehrfach-Durchlauf-Rendering in einer Bildschirm-Raum-Pipeline Pending DE102016122297A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/952,390 2015-11-25
US14/952,390 US10147222B2 (en) 2015-11-25 2015-11-25 Multi-pass rendering in a screen space pipeline

Publications (1)

Publication Number Publication Date
DE102016122297A1 true DE102016122297A1 (de) 2017-06-01

Family

ID=58693365

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102016122297.6A Pending DE102016122297A1 (de) 2015-11-25 2016-11-21 Mehrfach-Durchlauf-Rendering in einer Bildschirm-Raum-Pipeline

Country Status (3)

Country Link
US (1) US10147222B2 (de)
CN (1) CN107038742B (de)
DE (1) DE102016122297A1 (de)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2526598B (en) * 2014-05-29 2018-11-28 Imagination Tech Ltd Allocation of primitives to primitive blocks
US10535114B2 (en) * 2015-08-18 2020-01-14 Nvidia Corporation Controlling multi-pass rendering sequences in a cache tiling architecture
GB2543866B (en) * 2016-03-07 2017-11-01 Imagination Tech Ltd Task assembly for SIMD processing
KR102644276B1 (ko) * 2016-10-10 2024-03-06 삼성전자주식회사 그래픽 처리 장치 및 방법
US10699368B1 (en) * 2017-08-30 2020-06-30 Apple Inc. Memory allocation techniques for graphics shader
CN107886466B (zh) * 2017-11-24 2021-03-26 中国航空工业集团公司西安航空计算技术研究所 一种图形处理器图像处理单元系统
US10672185B2 (en) 2018-07-13 2020-06-02 Nvidia Corporation Multi-rate shading using replayed screen space tiles
KR102589969B1 (ko) 2018-11-05 2023-10-16 삼성전자주식회사 지연 쉐이딩에서 보간을 수행하는 그래픽스 처리 장치, 그래픽스 처리 시스템 및 그래픽스 처리 방법
CN111327439B (zh) * 2018-12-14 2023-07-25 中国移动通信集团山东有限公司 非冲突式人机命令交互通道并行工作控制方法及装置
CN112116519B (zh) * 2019-06-19 2022-12-27 畅想科技有限公司 图形处理系统中的粗略深度测试
US11170461B2 (en) * 2020-02-03 2021-11-09 Sony Interactive Entertainment Inc. System and method for efficient multi-GPU rendering of geometry by performing geometry analysis while rendering
WO2021158468A1 (en) * 2020-02-03 2021-08-12 Sony Interactive Entertainment Inc. System and method for efficient multi-gpu rendering of geometry by geometry analysis while rendering
US11893654B2 (en) * 2021-07-12 2024-02-06 Qualcomm Incorporated Optimization of depth and shadow pass rendering in tile based architectures

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3481296B2 (ja) * 1993-04-12 2003-12-22 ヒューレット・パッカード・カンパニー グラフィックスクリーン上の項目の選択方法
US6856320B1 (en) * 1997-11-25 2005-02-15 Nvidia U.S. Investment Company Demand-based memory system for graphics applications
AU5686199A (en) * 1998-08-20 2000-03-14 Apple Computer, Inc. Deferred shading graphics pipeline processor
US6919896B2 (en) * 2002-03-11 2005-07-19 Sony Computer Entertainment Inc. System and method of optimizing graphics processing
US20050122338A1 (en) * 2003-12-05 2005-06-09 Michael Hong Apparatus and method for rendering graphics primitives using a multi-pass rendering approach
JP4260734B2 (ja) * 2004-12-21 2009-04-30 株式会社ソニー・コンピュータエンタテインメント 描画処理装置、ラスタライザ、および描画処理方法
US20070165042A1 (en) * 2005-12-26 2007-07-19 Seitaro Yagi Rendering apparatus which parallel-processes a plurality of pixels, and data transfer method
US9324175B2 (en) * 2009-09-11 2016-04-26 Nvidia Corporation Memory coherency in graphics command streams and shaders
KR20130124618A (ko) * 2012-05-07 2013-11-15 삼성전자주식회사 영상 처리 장치 및 방법
US8941676B2 (en) * 2012-10-26 2015-01-27 Nvidia Corporation On-chip anti-alias resolve in a cache tiling architecture
US9953455B2 (en) * 2013-03-13 2018-04-24 Nvidia Corporation Handling post-Z coverage data in raster operations

Also Published As

Publication number Publication date
US20170148203A1 (en) 2017-05-25
US10147222B2 (en) 2018-12-04
CN107038742B (zh) 2021-01-08
CN107038742A (zh) 2017-08-11

Similar Documents

Publication Publication Date Title
DE102016122297A1 (de) Mehrfach-Durchlauf-Rendering in einer Bildschirm-Raum-Pipeline
DE102013017639B4 (de) Zwischenspeicherung von adaptiv dimensionierten Cache-Kacheln in einem vereinheitlichten L2-Cache-Speicher mit Oberflächenkomprimierung
DE102013017640B4 (de) Verteilte gekachelte Zwischenspeicherung
DE102018132468A1 (de) Multi-gpu-frame-rendern
DE102013020613A1 (de) Umgehung der Pixel-Schattierung für die grafische Bilderzeugung mit geringer Leistung
DE102013020614A1 (de) Mit Mehrfachauflösung konsistente Rastereinteilung
DE102013020807A1 (de) Handhabung von nachgeordneten Z-Abdeckungsdaten in Rasteroperationen
DE102015115232A1 (de) Verbessertes Anti-Aliasing durch räumliches und/oder zeitliches Variieren von Sample-Mustern
DE102013018445A1 (de) Festlegung eines nachgeordneten Bilderzeugungszustands in einer vorgeordneten Schattierungseinheit
DE102018114286A1 (de) Durchführen einer Traversierungs-Stack-Komprimierung
DE102013018139A1 (de) Technik zur Speicherung gemeinsamer Vertices
DE102016109905A1 (de) Stückweise lineare unregelmäßige Rasterisierung
DE102012211670A1 (de) Simultanes Unterbreiten an eine Mehr-Produzenten-Queue mittels mehrerer Threads
DE102013020810A1 (de) Effiziente Super-Abtastung mit Schattierungs-Strängen pro Pixel
DE102013022257A1 (de) Programmierbares Mischen in mehrsträngigen Verarbeitungseinheiten
DE112018004343T5 (de) Mehrraum-rendering mit konfigurierbaren transformationsparametern
DE102009039231A1 (de) Einzeldurchgang-Kachelung
DE102013020968A1 (de) Technik zum Zugreifen auf einen inhaltsadressierbaren Speicher
DE102013020966B4 (de) Leistungseffiziente Attribut-Handhabung für Parkettierungs- und Geometrie-Schattierungseinheiten
DE112010003750T5 (de) Hardware für parallele Befehlslistenerzeugung
DE102013018136A1 (de) Technik zur Speicherung gemeinsamer Vertices
DE102017109472A1 (de) Stereo-mehrfach-projektion implementiert unter verwendung einer graphikverarbeitungs-pipeline
DE102013020485A1 (de) Technik zur Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware
DE102013020967B4 (de) Technik zur Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware
DE102013017981A1 (de) Optimierung einer Dreieck-Topologie für Pfad-Bilderzeugung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06T0001200000

Ipc: G06T0015000000

R016 Response to examination communication