DE102013224046A1 - System, Verfahren und Computer-Programm-Produkt zum Debuggen von Grafik-Programmen lokal unter Benutzung eines Systems mit einer einzelnen GPU - Google Patents

System, Verfahren und Computer-Programm-Produkt zum Debuggen von Grafik-Programmen lokal unter Benutzung eines Systems mit einer einzelnen GPU Download PDF

Info

Publication number
DE102013224046A1
DE102013224046A1 DE102013224046.5A DE102013224046A DE102013224046A1 DE 102013224046 A1 DE102013224046 A1 DE 102013224046A1 DE 102013224046 A DE102013224046 A DE 102013224046A DE 102013224046 A1 DE102013224046 A1 DE 102013224046A1
Authority
DE
Germany
Prior art keywords
api
context
gpu
memory
graphics
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102013224046.5A
Other languages
English (en)
Inventor
Jeffrey T. Kiel
Thomas H. Klein
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 DE102013224046A1 publication Critical patent/DE102013224046A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3636—Software debugging by tracing the execution of the program
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • Image Generation (AREA)

Abstract

Ein System, Verfahren und Computer-Programm-Produkt sind zum Debuggen von Grafik-Programmen über ein System mit einer einzelnen Grafik-Verarbeitungs-Einheit bereitgestellt. Das Verfahren umfasst die Schritte eines Speicherns eines initialen Zustandes eines Anwendungs-Programmier-Schnittstelle-Kontextes in einem Speicher, eines Abfangens eines Stroms von API-Befehlen, welcher mit dem Frame assoziiert ist, eines Übermittelns des Stroms von API-Befehlen an eine Software-Schicht, welche die API implementiert, um den Frame zu rendern, und in Antwort auf einen Unterbrechungs-Punkt, eines Speicherns eines Grafik-Verarbeitungs-Einheit-Kontextes in dem Speicher. Der initiale Zustand des API-Kontextes entspricht dem Start eines Frames und der Strom von API-Befehlen ist mittels einer Grafik-Anwendung erzeugt.

Description

  • PRIORITÄTSANSPRUCH
  • Diese Anmeldung beansprucht die Priorität von US-Provisional-Anmeldungs-Nr. 61/730,025, eingereicht am 26. November 2012, wobei die gesamten Inhalte davon hierin mittels Bezugnahme inkorporiert sind.
  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft Software-Design und insbesondere Debuggen bzw. Fehler-Diagnose (debugging) von Grafik-Programmen.
  • HINTERGRUND
  • Heutige Programmierer sind daran gewöhnt worden, in der Lage zu sein, Programme über eine Vielzahl von Werkzeugen zu erzeugen und auf Fehler zu untersuchen bzw. debuggen, welche in heutigen integrierten Entwicklungs-Umgebungen (IDEs) implementiert sind, wie etwa Mikrosoft® Visual Studio. Ein Programmierer kann Source-Code für ein Programm, welches mittels eines Ziel-Prozessors auszuführen ist, erzeugen, den Source-Code kompilieren, um eine ausführbare Datei zu erzeugen und kann die ausführbare Datei auf dem Ziel-Prozessor ablaufen lassen. Die IDE kann Werkzeuge umfassen, welche dem Programmierer erlauben, das Programm unter Benutzung von Unterbrechungs-Punkten (breakpoints) auszuführen, durch das Programm eine Anweisung zu einer Zeit hindurchzuschreiten, durch das Programm von Unterbrechungs-Punkt zu Unterbrechungs-Punkt durchzuschreiten und die Inhalte von Speicher oder Registern zu verschiedenen Punkten während der Programm-Ausführung zu betrachten.
  • Typischerweise kann der Ziel-Prozessor eine Zentral-Verarbeitungs-Einheit (CPU) sein, wie etwa die Intel® x86-Familie von Prozessoren oder die ARM®-Cortex-Familie von Prozessoren, welche einen RISC (Reduced Instruction Set Computing) basierten CPU-Kern umfassen. Solche Prozessoren können mit der Fähigkeit implementiert sein, die Ausführung von gewissem Code, welcher mittels des Prozessors ausgeführt wird, zu unterbrechen oder im voraus auszuführen (pre-empt). Diese Fähigkeit ermöglicht einem Programmierer, Programme über einen einzelnen Prozessor zu debuggen, welcher auch benutzt ist, das Betriebs-System (OS), IDE, oder andere Software im Wesentlichen gleichzeitig auszuführen. Heutige konventionelle Grafik-Verarbeitungs-Einheiten (GPUs) brauchen jedoch nicht in der Lage zu sein, in dieser Weise zu operieren. Zum Beispiel brauchen herkömmliche GPUs nicht einem Zuvorkommen bzw. einer Prävention (pre-emption) für spezifische Prozesse, welche auf der GPU ausführen, fähig sein. Mit anderen Worten kann der Programmierer die Ausführung eines Programms auf der GPU nicht anhalten, während erlaubt ist, dass andere Operationen, wie etwa ein Erzeugen von Grafik-Information zur Anzeige auf einem angehängten Monitor, damit fortfahren, ausgeführt zu werden. Ohne derartige Fähigkeiten sind Debugging-Plattformen für GPUs typischerweise auf entfernte Systeme begrenzt, welches eine GPU mit einem Klienten-System über ein Netzwerk verbunden hat, oder lokale Systeme mit mehreren GPUs, wobei eine GPU dediziert ist, Operationen anzuzeigen, und die andere GPU dediziert ist, Operationen zu debuggen. Solche Systeme sind komplexer aufzusetzen und zu betreiben, was zusätzliche Hardware und eine spezielle Konfiguration erfordert. Es wäre für Programmierer nützlich, in der Lage zu sein, auf einzelne-GPU-Systemen zu kodieren, welche weit verbreitet auf den meisten Schreibtisch- und Laptop-Computern verfügbar sind. Somit gibt es einen Bedarf zum Adressieren dieses Problems und/oder anderer Probleme, welche mit dem Stand der Technik assoziiert sind.
  • ZUSAMMENFASSUNG
  • Ein System, Verfahren und Computer-Programm-Produkt sind zum Debuggen von Grafik-Programmen über ein System mit einer einzelnen Grafik-Verarbeitungs-Einheit bereitgestellt. Das Verfahren umfasst die Schritte eines Speicherns eines anfänglichen Zustands eines Anwendungs-Programmier-Schnittstelle-Kontextes in einem Speicher, eines Abfangens eines Stroms von API-Befehlen, welche mit dem Frame assoziiert sind, eines Übermittelns des Stromes von API-Befehlen an eine Software-Schicht, welche die API implementiert, um den Frame zu rendern, und in Antwort auf einen Unterbrechungs-Punkt, eines Speicherns eines Grafik-Verarbeitungs-Einheit-Kontextes in dem Speicher. Der anfängliche Zustand des API-Kontextes entspricht dem Start eines Frames und der Strom von API-Befehlen ist mittels einer Grafik-Anwendung erzeugt.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 illustriert ein Flussdiagramm eines Verfahrens zum Debuggen von Grafik-Programmen unter Benutzung eines Systems, welches eine einzelne Grafik-Verarbeitungs-Einheit hat, in Übereinstimmung mit einer Ausführungsform;
  • 2 illustriert ein System, welches konfiguriert ist, Grafik-Programme zu debuggen, gemäß dem Stand der Technik;
  • 3 illustriert ein System, welches konfiguriert ist, Grafik-Programme zu debuggen, in Übereinstimmung mit einer Ausführungsform;
  • 4 illustriert eine Parallel-Verarbeitungs-Einheit gemäß einer Ausführungsform;
  • 5 illustriert den Streaming-Mehr-Prozessor von 4 gemäß einer Ausführungsform;
  • 6 ist ein konzeptionelles Diagramm einer Grafik-Verarbeitungs-Pipeline, welche mittels der Parallel-Verarbeitungs-Einheit von 4 implementiert ist, in Übereinstimmung mit einer Ausführungsform;
  • 7A illustriert einen Teil von Code für ein Shader-Programm in Übereinstimmung mit einer Ausführungsform;
  • 7B illustriert ein System zum Debuggen eines Shader-Programms unter Benutzung einer einzelnen Grafik-Verarbeitungs-Einheit in Übereinstimmung mit einer anderen Ausführungsform;
  • 8A, 8B und 8C illustrieren ein Flussdiagramm eines Verfahrens zum Debuggen von Grafik-Programmen mit einer einzelnen Grafik-Verarbeitungs-Einheit in Übereinstimmung mit einer anderen Ausführungsform; und
  • 9 illustriert ein exemplarisches System, in welchem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden kann.
  • DETAILLIERTE BESCHREIBUNG
  • Die vorliegende Offenbarung beschreibt einen Mechanismus zum Debuggen bzw. Fehler-Analysieren (debugging) von Grafik-Programmen auf einem System, welches eine einzelne GPU hat. Eine Anwendungs-Abstimmung bzw. Anwendungs-Shim ist konfiguriert, API-Befehle, welche mittels einer Grafik-Anwendung erzeugt sind, welche mittels eines Host-Prozessors ausgeführt ist, abzufangen (intercept). Die Grafik-Anwendung, wenn kompiliert, ist konfiguriert, API-Befehle zu erzeugen, welche zu einer Software-Schicht übermittelt sind, welche die API implementiert, wie etwa ein Treiber oder eine Laufzeit-Bibliothek. Die Anweisungen, welche konfiguriert sind, die API-Befehle für die Software-Schicht zu erzeugen, können durch Anweisungen ersetzt werden, welche konfiguriert sind, die API-Befehle für den Anwendungs-Shim zu erzeugen. Die Anweisungen können automatisch in den Binär-Code mittels eines Software-Werkzeuges oder manuell mittels eines Linkens des Anwendungs-Shims an den Quell-Code für die Grafik-Anwendung ersetzt werden. Wenn die Grafik-Anwendung ausgeführt ist, dann werden die API-Befehle an den Anwendungs-Shim anstatt der Software-Schicht geleitet (routed).
  • Der Anwendungs-Shim ist konfiguriert, einen API-Kontext, welcher mit der Grafik-Anwendung assoziiert ist, nachzuverfolgen (track). Der API-Kontext kann dadurch nachverfolgt werden, dass ein Zustand-Modell erzeugt und modifiziert ist, welches den momentanen API-Kontext repräsentiert. Der Anwendungs-Shim ist konfiguriert, das Zustand-Modell basierend auf den API-Befehlen zu aktualisieren, welche von der Grafik-Anwendung empfangen sind. Nachdem das Zustand-Modell aktualisiert ist, kann der Anwendungs-Shim die API-Befehle an die Software-Schicht weiterleiten, wie ursprünglich von der Grafik-Anwendung beabsichtigt ist.
  • Der Anwendungs-Shim kann konfiguriert sein, einen Wiederholen-Mechanismus (replay mechanism) zu implementieren, welcher einem Debugging-Werkzeug erlaubt, verschiedene Debugging-Techniken zu implementieren, welche gemeinhin nur mit herkömmlichen CPUs assoziiert sind. Der Wiederholen-Mechanismus umfasst die Schritte eines Speicherns eines anfänglichen Zustands des API-Kontext bei dem Start eines Renderns eines Frames von Bild-Daten zur Anzeige, eines Speicherns eines Stroms von API-Befehlen, welche mittels der Grafik-Anwendung für den Frame von Bild-Daten in einem Wiederholen-Puffer (replay buffer) erzeugt sind, und eines Initiierens einer Wiederholen-Schleife, um wiederholt den Frame von Bild-Daten eine Anzahl von Malen zu rendern. Jeder Durchgang der Wiederholen-Schleife weist ein Wiederherstellen (restoring) des API-Kontextes auf, um mit dem anfänglichen Zustand des API-Kontextes übereinzustimmen (match), und ein Übermitteln des Stroms von API-Befehlen in dem Wiederholen-Puffer an die Software-Schicht. Wenn einem Unterbrechungs-Punkt während der Wiederholen-Schleife begegnet ist, kann ein momentaner Zustand des GPU-Kontextes während des Renderns des Frames erfasst werden. Unter Benutzung des Wiederholen-Mechanismus, welcher oben beschrieben ist, kann ein Debugging-Werkzeug einem Programmierer erlauben, bei einem Unterbrechungs-Punkt in dem Programm zu stoppen, durch das Programm eine Anweisung zu einer Zeit zu schreiten, durch das Programm einen Unterbrechungs-Punkt zu einer Zeit zu schreiten, usw. auf einem System mit einer einzelnen GPU ohne ein Einfrieren der Anzeige.
  • 1 illustriert ein Flussdiagramm eines Verfahrens 100 zum Debuggen von Grafik-Programmen unter Benutzung eines Systems, welches eine einzelne GPU hat, in Übereinstimmung mit einer Ausführungsform. Bei Schritt 102 wird ein anfänglicher Zustand eines API-Kontextes in einem Speicher gespeichert. Der anfängliche Zustand des API-Kontextes kann Information entsprechen, welche in einem Zustands-Modell umfasst ist, welche den API-Kontext bei dem Start eines Frames repräsentiert. Der anfängliche Zustand des API-Kontextes wird in eine separate Daten-Struktur im Speicher kopiert, um den Zustand des API-Kontextes bei einem späteren Zeitpunkt zurückzusetzen. Bei Schritt 104 wird ein Strom von API-Befehlen, welche mittels einer Grafik-Anwendung erzeugt ist, abgefangen. Der Strom von API-Befehlen kann in einem Wiederholen-Puffer (replay buffer) gespeichert sein. Mehrere API-Kontexte können zu einem gegebenen Zeitpunkt existieren und jeder API-Kontext kann mit einem oder mehr Strömen von API-Befehlen assoziiert sein, welche mittels einer Grafik-Anwendung erzeugt sind. In einer Ausführungsform sind zwei oder mehr Ströme von API-Befehlen, welche mit dem API-Kontext assoziiert sind, in dem Wiederholen-Puffer gespeichert. In dem Kontext der vorliegenden Beschreibung ist ein Wiederholen-Puffer irgendeine Daten-Struktur, welche in Speicher alloziert ist und konfiguriert ist, eine geordnete Liste von API-Befehlen zu speichern. In einer Ausführungsform ist der Wiederholen-Puffer eine verkettete Liste (linked list). In einer anderen Ausführungsform ist der Wiederholen-Puffer ein FIFO.
  • Bei Schritt 106 wird der Strom von API-Befehlen an eine Software-Schicht übermittelt. In einer Ausführungsform kann die Software-Schicht ein Treiber sein, welcher die API implementiert, wie etwa ein Treiber, welcher die OpenGL-API implementiert. In einer anderen Form kann die Software-Schicht eine Laufzeit-Bibliothek sein, welche die API implementiert, wie etwa eine Laufzeit-Bibliothek, welche die Direct3D-API implementiert. In solchen Ausführungsformen kann die Software-Schicht mit einem anderen Treiber oder einer anderen intermediären Schicht gelinkt sein. Bei Schritt 108 bestimmt ein Anwendungs-Shim, ob ein Unterbrechungs-Punkt erreicht worden ist. In dem Kontext der vorliegenden Offenbarung ist ein Unterbrechungs-Punkt eine spezielle Anweisung, welche mittels eines Prozessors ausgeführt ist, welche dazu führt, dass die Ausführung angehalten wird und potentiell kann ein Fehler-Behandler oder eine andere Routine ausgeführt werden. Ein Unterbrechungs-Punkt kann eine spezielle Anweisung sein oder mit einer anderen Anweisung assoziiert sein (wie etwa ein Anweisungs-Präfix), welche anzeigt, dass die Anweisung mit einem Unterbrechungs-Punkt in dem Programm assoziiert ist. In einer Ausführungsform kann der Unterbrechungs-Punkt (entweder direkt oder indirekt durch einen Fehler-Behandler) die GPU veranlassen, eine Nachricht an den Treiber zu übermitteln, welche anzeigt, dass der Unterbrechungs-Punkt erreicht worden ist, und dass die GPU Ausführung von weiteren Anweisungen angehalten hat. Wenn kein Unterbrechungs-Punkt erreicht worden ist, dann kehrt das Verfahren 800 zu Schritt 106 zurück, wo zusätzliche API-Befehle an die Software-Schicht übermittelt werden. Zurückkehrend zu Schritt 108 jedoch, in Antwort auf ein Erreichen eines Unterbrechungs-Punktes, schreitet das Verfahren 800 zu Schritt 110 fort, wo ein momentaner Zustand des GPU-Kontextes in einem Speicher gespeichert wird. Bei Schritt 112 wird eine Wiederholen-Schleife initiiert, was dazu führt, dass der anfängliche Zustand des API-Kontextes wieder hergestellt wird, dass der Strom von API-Befehlen erneut an die Software-Schicht übermittelt wird, und dass ein anderer Zustand des GPU-Kontextes in dem Speicher gespeichert wird.
  • Illustrativere Information wird bezüglich der verschiedenen optionalen Architekturen und Merkmale nun ausgeführt, mit welchen das vorangehende Rahmenwerk implementiert werden kann oder nicht implementiert zu werden braucht, nach den Wünschen des Benutzers. Es sollte jedoch deutlich bemerkt sein, dass die folgende Information für illustrative Zwecke ausgeführt ist und nicht interpretiert werden sollte, in irgendeiner Weise zu begrenzen. Irgendwelche der folgenden Merkmale können optional mit oder ohne den Ausschluss von anderen beschriebenen Merkmalen inkorporiert werden.
  • 2 illustriert ein System, welches konfiguriert ist, Grafik-Programme zu debuggen, gemäß dem Stand der Technik. Wie in 2 gezeigt ist, umfasst das System eine Klienten-Plattform 200, welche mit einer Ziel-Plattform 250 über ein Netzwerk 230 gekoppelt ist. Die Klienten-Plattform 200 kann z. B. ein Schreibtisch-Computer, ein Laptop-Computer, ein Tablet-Computer oder irgendein anderes System sein, welches konfiguriert ist, eine IDE oder eine andere Debugging-Software ablaufen zu lassen. Die Klienten-Plattform 200 umfasst eine Zentral-Verarbeitungs-Einheit (CPU) 201, einen Speicher 204, eine GPU 206, ein Anzeige-Gerät 208 und eine Netzwerk-Schnittstelle-Steuerung (NIC) 203. Die CPU 201 kann ein x86-Typ-Prozessor, ein RISC-Prozessor, ein PowerPC-Prozessor oder dergleichen sein. Der Speicher 204 kann ein volatiler Speicher sein, wie etwa ein dynamischer Speicher mit willkürlichem Zugriff (DRAM). Obwohl es nicht explizit gezeigt ist, kann die Klienten-Plattform 200 ein nicht-volatiles Speicher-Gerät umfassen, wie etwa ein Festplatte-Laufwerk (HDD) oder einen anderen Typ von magnetischem oder optischem Speicher-System. Die NIC 203 kann ein TCP/IP-Protokoll zum Verbinden mit einem oder mehr anderen Geräten durch das Netzwerk 230 implementieren, welches z. B. ein Lokalbereichs-Netzwerk (LAN), ein Fernbereichs-Netzwerk (WAN), das Internet oder dergleichen sein kann. Das Anzeige-Gerät 208 kann ein Flüssigkristall-Anzeige-(LCD)-Gerät, ein organische-Licht-emittierende-Diode(OLED)-Anzeige-Gerät, ein Kathoden-Strahl-Röhre-(CRT)-Anzeige-Gerät oder dergleichen sein.
  • Die GPU 206 ist ein Prozessor, welcher eine programmierbare, Parallel-Verarbeitungs-Architektur implementiert, welche zumindest einen Teil einer Bild-Verarbeitungs-Pipeline umfasst. Die Bild-Verarbeitungs-Pipeline ist konfiguriert, Bild-Daten zur Anzeige auf dem Anzeige-Gerät 208 zu erzeugen, welches mit der GPU 206 über irgendeinen Kommunikationen-Link verbunden sein kann, wie etwa eine Video-Grafik-Array-(VGA)-Verbindung, eine High-Definition-Multimedia-Interface-(HDMI)-Verbindung, eine DisplayPort-(DP)-Verbindung, oder dergleichen. Obwohl nicht explizit gezeigt, kann die GPU 206 mit einem lokalen Grafik-Speicher verbunden sein, wie etwa ein synchroner dynamischer Speicher mit willkürlichem Zugriff (SDRAM) oder dergleichen. Die GPU 206 kann konfiguriert sein, Frames von Bild-Daten basierend auf Befehlen zu erzeugen, welche zu der GPU 206 von einem Treiber übermittelt sind, welche mittels der CPU 201 ausgeführt wird. Die Frames von Bild-Daten können in einem Frame-Puffer in dem lokalen Grafik-Speicher gespeichert sein und auf Video-Signale konvertiert werden, welche zu dem Anzeige-Gerät 208 über den Kommunikationen-Link übermittelt sind.
  • Die Ziel-Plattform 250 kann z. B. ein anderer Schreibtisch-Computer sein, welcher mit dem Netzwerk 230 verbunden ist, und einschließlich einer zweiten CPU 251, einer zweiten GPU 256, einem zweiten Speicher 254, und einer zweiten NIC 253. Die CPU 251, Speicher 254 und NIC 253 können ähnlich zu CPU 201, Speicher 204 und NIC 203 sein, welche oben beschrieben sind. Die zweite GPU 256 kann als ein Ziel-Gerät bezeichnet werden. Eine Entwicklungs-Anwendung, wie etwa eine IDE oder ein anderer Typ von Debugging-Werkzeug, kann mittels der Klienten-Plattform 200 ausgeführt werden. Die Entwicklungs-Anwendung kann dazu führen, dass ein Grafik-Programm (d. h. ein Shader) mittels der GPU 256 ausgeführt wird, welche solche Debugging-Mechanismen wie Unterbrechungs-Punkte, Anweisungs-Durchschreiten und dergleichen durch die Entwicklungs-Anwendung implementiert, welche auf der Klienten-Plattform 200 ausgeführt wird. Es wird geschätzt werden, dass die Ziel-Plattform 250 nicht ein Anzeige-Gerät, welches an die GPU 256 angehängt ist, umfassen braucht, weil während eines Debuggens, die GPU 256 angehalten sein kann, was somit die GPU 256 daran hindert, Anzeige-Signale für das Anzeige-Gerät zu erzeugen. Der Programmierer kann jedoch in der Lage sein, den Zustand der GPU 256 auf dem Anzeige-Gerät 208 der Klienten-Plattform 200 zu betrachten, weil die GPU 206 während eines Debuggens nicht angehalten ist und daher in der Lage ist, Anzeige-Signale für das Anzeige-Gerät 208 zu erzeugen.
  • Dieser Typ eines entfernten Systems, welcher zum Debuggen von Grafik-Programmen benutzt wird, kann für gewisse Situationen ausreichend sein, wie etwa, wo ein Programmierer eine Klienten-Plattform 200-Ausrüstung bei einem zentralen Büro benutzt und mit einer oder mehr Ziel-Plattformen 250 über ein Lokalbereichs-Netzwerk verbunden ist. Dieses System erfordert jedoch zusätzliche Hardware, was unnötige Ausgaben hinzufügt, und ist komplex aufzusetzen, was erfordert, dass der Programmierer oder ein Netzwerk-Manager die verschiedenen IP-Adressen der Ziel-Plattformen 250 konfiguriert und demgemäß die Entwicklungs-Anwendung konfiguriert. Häufig werden Programmierer nur Zugriff auf ein herkömmliches System haben (wie etwa ein Schreibtisch-Computer oder Laptop-Computer), welches nur eine einzelne GPU umfasst und die Programmierer brauchen keinen Zugriff auf eine Ziel-Plattform, welche mit einem Netzwerk verbunden ist, zu haben.
  • Es wird geschätzt werden, dass ein alternatives System konstruiert werden kann, welches mehrere GPUs in einer einzelnen Plattform inkorporiert, wo zumindest eine GPU dediziert sein kann, Bild-Daten zur Anzeige zu erzeugen, und wo zumindest eine andere GPU für Debugging-Operationen dediziert ist. Dieser Typ eines Systems ist zum Debuggen von Rechen-Anwendungen für Allgemeinzweck-Berechnung auf Grafik-Verarbeitungs-Einheiten (GPGPU) benutzt worden. Solche Systeme erfordern jedoch einen separaten Treiber für die GPU, welche für Debugging-Operationen dediziert ist, was die GPU, welche für die Debugging-Operationen dediziert ist, daran hindert, Grafik-Programme zu verarbeiten. Mit anderen Worten sind herkömmliche Betriebs-Systeme, wie etwa Microsoft®Windows, konfiguriert, Grafik-Operationen für irgendwelche der verfügbaren GPUs zu allozieren, welche konfiguriert sind, Grafik-Programme zu verarbeiten. Daher kann die Entwicklungs-Anwendung nicht den Betrieb eines Grafik-Programms für Debugging-Zwecke anhalten, ohne potentiell die Fähigkeit des Betriebs-Systems zu stoppen bzw. anzuhalten (stalling), Bild-Daten anzuzeigen, welche mittels des Betriebs-Systems oder andere Anwendungen erzeugt sind. Solche Probleme können unter Benutzung des unten beschriebenen Systems abgeschwächt werden.
  • 3 illustriert ein System, welches konfiguriert ist, Grafik-Programme zu debuggen, in Übereinstimmung mit einer Ausführungsform. Wie in 3 gezeigt ist, ist eine Klienten-Plattform 300 ähnlich zu der Klienten-Plattform 200, indem die Klienten-Plattform 300 eine CPU 301, einen Speicher 304, eine GPU 306, ein Anzeige-Gerät 308 und eine NIC 303 umfasst. In einer Ausführungsform sind diese Komponenten ähnlich den Komponenten der Klienten-Plattform 200. Der Speicher 304 kann ein Betriebs-System (OS) 331, einen Treiber 332, eine IDE 333, eine Grafik-Anwendung 334, ein oder mehr Shader-Programme bzw. Schattierungs-Programme 335 und einen Schatten-Zustand-Speicher (shadow state memory) 336 umfassen. Das OS 331 kann Microsoft®Windows, Linux®, Mac® OSX, oder dergleichen sein. Die IDE 333 kann Microsoft® Visual Studio, NVIDIA®Nsight (eine Erweiterung für Visual Studio), die Open-Source-Eclipse-Plattform oder irgendein anderer Typ einer Entwicklungsumgebung oder Debugging-Software sein, welcher fähig ist, Grafik-Programme zu debuggen.
  • Der Treiber 332 ist konfiguriert, Anweisungen an die GPU 306 zu übermitteln, um Aufgaben auf der GPU 306 auszuführen. In einer Ausführungsform implementiert der Treiber 332 eine API, welche mittels der OpenGL®-Spezifikation definiert ist. Die API ermöglicht der Grafik-Anwendung 334, Hardware-unabhängige API-Befehle zu erzeugen, welche zu dem Treiber 332 gesendet werden, welche wiederum die GPU 306 veranlassen, Operationen durchzuführen, welche mittels der API-Befehle spezifiziert sind. In einer anderen Ausführungsform implementiert der Treiber 332 eine API, welche mit einer Laufzeit-Bibliothek assoziiert ist, welche die Direct3D®-API implementiert. Die API ermöglicht der Grafik-Anwendung 334, Hardware-unabhängige API-Befehle zu erzeugen, welche zu der Laufzeit-Bibliothek gesendet werden, welche wiederum zusätzliche API-Befehle zu dem Treiber 332 übermittelt, welche die GPU 306 veranlassen, Anweisungen auszuführen, welche mittels der API-Befehle spezifiziert sind. Es wird geschätzt werden, dass API-Befehle, welche mittels der Grafik-Anwendung 334 erzeugt sind, zu dem Treiber 332 entweder direkt oder indirekt durch ein oder mehr Zwischen-Software-Schichten übermittelt werden können, wie etwa Anwendungs-Shims, Bibliotheken, etc.
  • Die Grafik-Anwendung 334 kann eine Software-Anwendung sein, welche konfiguriert ist, mittels der CPU 301 ausgeführt zu werden, um API-Befehle zu erzeugen, welche zu einer Software-Schicht übermittelt sind. Die Grafik-Anwendung 334 kann mit einem oder mehr Schattierungs-Programmen 335 assoziiert sein, wie etwa ein Vertex-Schattierer, ein Geometrie-Schattierer oder ein Fragment-Schattierer (d. h. Pixel-Schattierer), welche konfiguriert sind, mittels einer programmierbaren Programm-Einheit der GPU 306 ausgeführt zu werden. Ein Schattierer (shader) ist ein generischer Ausdruck für einen Satz von Anweisungen, welche konfiguriert sind, mittels einer GPU ausgeführt zu werden zum Transformieren von geometrischen Primitiven oder Schattieren von Pixeln (d. h. Erzeugen von Farbkomponent-Werten für ein oder mehr Pixel). Jeder Schattierer kann konfiguriert sein, ein oder mehr Eingabe-Puffer zu empfangen (z. B. ein Vertex-Puffer, etc.) und einen oder mehr Ausgabe-Puffer zu erzeugen (z. B. einen Dreiecks-Flecken (triangle patch), einen Farb-Vektor, etc.).
  • Wie oben diskutiert ist, haben herkömmliche GPUs nicht die Fähigkeit, während der Ausführung angehalten zu werden, während sie fortfahren, Bild-Daten zur Anzeige auf einem Anzeige-Gerät zu erzeugen. Um dieses Problem zu lösen, ist ein Anwendungs-Shim konfiguriert, Operationen zu wiederholen, welche mittels einer Grafik-Anwendung spezifiziert sind, derart, dass die IDE 333 den Zustand der GPU 306 anzeigen wird, als ob die GPU 306 während eines Debuggens angehalten ist, während der GPU tatsächlich erlaubt ist, Ausführung fortzuführen, um dadurch zu erlauben, dass der GPU-Kontext von dem API-Kontext, welcher mit der Grafik-Anwendung assoziiert ist, auf z. B. einen API-Kontext umgeschaltet wird, welcher mit dem Betriebs-System 331 assoziiert ist, welches Bild-Daten zur Anzeige auf dem Anzeige-Gerät 308 erzeugt.
  • In einer Ausführungsform ist ein Anwendungs-Shim konfiguriert, einen API-Kontext nachzuverfolgen, welcher mit der Grafik-Anwendung 334 assoziiert ist. Der Anwendungs-Shim speichert einen anfänglichen Zustand des API-Kontextes in dem Speicher 304 bei dem Start eines bestimmten Frames oder bestimmter Frames. Ein Programmierer kann ein Debugging-Werkzeug benutzen, um anzuzeigen, welcher Frame bzw. welche Frames von Interesse sind. Der Anwendungs-Shim speichert einen Strom von API-Befehlen für einen oder mehr Frames, welche mittels der Grafik-Anwendung 334 erzeugt sind, in dem Speicher 304. Der Anwendungs-Shim kann dann eine Wiederholen-Schleife initiieren, um wiederholt den Strom von API-Befehlen auszuführen, um den einen oder die mehreren Frames von Bild-Daten eine Anzahl von Malen zu rendern. Mit anderen Worten führt eine einzelne Iteration der Wiederholen-Schleife den Strom von API-Befehlen aus, um den einen oder die mehreren Frames von Bild-Daten zu rendern. Bei dem Ende des Stroms von API-Befehlen kann der anfängliche Zustand des API-Kontextes wieder hergestellt werden und der Strom von API-Befehlen kann wiederholt werden, um die Operationen in im Wesentlichen derselben Reihenfolge zu wiederholen und den einen oder die mehreren Frames von Bild-Daten erneut zu rendern. Die API-Befehle können Aufrufe, ein bestimmtes Schattierungs-Programm zu laden, Aufrufe, welche einen Push-Puffer spezifizieren, welcher eine Mehrzahl von geometrischen Primitiven (z. B. Dreiecke) umfasst, Zeichen-Aufrufe und dergleichen umfassen. Der Strom von API-Befehlen kann in einem Wiederholen-Puffer in dem Speicher 304 gesichert werden und dann wieder und wieder erneut abgespielt bzw. wiederholt werden (replayed), so oft wie der Benutzer es wünscht, um die Debugging-Operationen durchzuführen.
  • Diese Wiederholen-Funktionalität kann von der IDE 333 oder anderen Debugging-Werkzeugen ausgenutzt werden, um verschiedene Debugging-Techniken zu implementieren. Zum Beispiel kann eine Grafik-Anwendung 334 und/oder Schattierungs-Programm 335 dadurch debugged werden, dass die Grafik-Anwendung 334 ausgeführt wird und dass eine Wiederholen-Schleife während eines bestimmten Frames initiiert wird. Ein Unterbrechungs-Punkt (d. h. eine spezielle Anweisung) kann in einem Schattierungs-Programm 335 bei einer bestimmten Zeile umfasst sein, was die GPU 306 veranlasst, Ausführung bei irgendwelchen weiteren Anweisungen anzuhalten, welche mit der Grafik-Anwendung 334 assoziiert sind. In einer Ausführungsform führt die Unterbrechungs-Punkt-Anweisung dazu, dass ein Fehler-Behandler mittels der GPU 306 ausgeführt wird. Der Fehler-Behandler kann dazu führen, dass eine Nachricht an den Anwendungs-Shim (z. B. über den Treiber 332) übermittelt wird. In einer Ausführungsform ist der Anwendungs-Shim konfiguriert, den momentanen Zustand des GPU-Kontextes in den Schatten-Zustands-Speicher 336 zu kopieren. Sobald der momentane Zustand des GPU-Kontextes in dem Schatten-Zustands-Speicher 336 gespeichert worden ist, kann der GPU 306 erlaubt sein, Ausführung des Schattierungs-Programms 335 und irgendwelcher anderer Anweisungen fortzusetzen, welche mittels des Stroms von API-Befehlen spezifiziert sind. Normalerweise würde ein der GPU 306 Erlauben, Ausführung fortzusetzen, einen Programmierer daran hindern, den Zustand des GPU-Kontextes (d. h. Register, assoziierte Speicher-Konstrukte, etc.) zu inspizieren, weil der GPU-Kontext aktualisiert würde, wenn zusätzliche Anweisungen ausgeführt werden. In dem Fall ist jedoch der Zustand des GPU-Kontextes in dem Schatten-Zustands-Speicher 336 gespeichert und wird nicht dadurch beeinflusst, dass dem Programm erlaubt ist, fortzuführen, oder erlaubt ist, dass ein verschiedener Kontext auf die GPU 306 geladen wird. Während sich die GPU 306 weiter zu anderen Aufgaben bewegt hat, kann somit der Programmierer die gespeicherte Information in dem Schatten-Zustands-Speicher 336 inspizieren.
  • In einer Ausführungsform weist die GPU 306 die Parallel-Verarbeitungs-Einheit 400 auf, welche unten im Zusammenhang mit 4 und 5 beschrieben ist. Es wird geschätzt werden, dass andere Ausführungsformen eine GPU mit einer anderen Architektur umfassen können und dass solche Architektur unten für illustrative Zwecke gezeigt ist.
  • 4 illustriert eine Parallel-Verarbeitungs-Einheit (PPU) 400 gemäß einer Ausführungsform. Während ein Parallel-Prozessor hierin als ein Beispiel der PPU 400 bereitgestellt ist, sollte deutlich bemerkt sein, dass solch ein Prozessor nur für illustrative Zwecke ausgeführt ist und dass irgendein Prozessor eingesetzt werden kann, um denselben zu ergänzen und/oder zu ersetzen. In einer Ausführungsform ist die PPU 400 konfiguriert, eine Mehrzahl von Threads gleichzeitig in zwei oder mehr Streaming-Mehr-Prozessoren (SMs) 450 auszuführen. Ein Thread (d. h. ein Thread von Ausführung) ist eine Instanziierung eines Satzes von Anweisungen, welche innerhalb eines bestimmten SM 450 ausführen. Jeder SM 450, welcher unten im größeren Detail im Zusammenhang mit 5 beschrieben ist, kann umfassen, ist jedoch nicht darauf beschränkt, einen oder mehrere Verarbeitungs-Kerne, eine oder mehrere Lade-/Speicher-Einheiten (LSUs), einen Level-Eins-(L1)-Zwischenspeicher, gemeinsam benutzten Speicher, und dergleichen.
  • In einer Ausführungsform umfasst die PPU 400 eine Eingabe/Ausgabe-(I/O)-Einheit 405, welche konfiguriert ist, Kommunikationen (d. h. Befehle, Daten, etc.) von einer Zentral-Verarbeitungs-Einheit (CPU) (nicht gezeigt) über den System-Bus 402 zu übermitteln und zu empfangen. Die I/O-Einheit 405 kann eine Peripheral-Component-Interconnect-Express-(PCIe)-Schnittstelle für Kommunikationen über einen PCIe-Bus implementieren. In alternativen Ausführungsformen kann die I/O-Einheit 405 andere Typen von wohl bekannten Bus-Schnittstellen implementieren.
  • Die PPU 400 umfasst auch eine Host-Schnittstelle-Einheit 410, welche die Befehle dekodiert und die Befehle zu der Aufgabe-Management-Einheit 415 oder anderen Einheiten der PPU 400 (z. B. Speicher-Schnittstelle 480) übermittelt, wie es die Befehle spezifizieren können. Die Host-Schnittstelle-Einheit 410 ist konfiguriert, Kommunikationen zwischen und unter den verschiedenen logischen Einheiten der PPU 400 zu führen.
  • In einer Ausführungsform ist ein Programm, welches als ein Befehls-Strom kodiert ist, auf einen Puffer mittels der CPU geschrieben. Der Puffer ist ein Bereich im Speicher, z. B. Speicher 404 oder System-Speicher, auf welchen sowohl von der CPU als auch der PPU 400 zugreifbar ist (d. h. Lesen/Schreibe). Die CPU schreibt den Befehls-Strom auf den Puffer und übermittelt dann einen Zeiger auf den Start des Befehls-Stroms an die PPU 400. Die Host-Schnittstelle-Einheit 410 stellt der Aufgabe-Management-Einheit (TMU) 415 Zeiger auf einen oder mehr Ströme bereit. Die TMU 415 wählt einen oder mehrere Ströme aus und ist konfiguriert, die ausgewählten Ströme als einen Pool von anhängigen Gittern (pending grids) zu organisieren. Der Pool von anhängigen Gittern kann neue Gitter umfassen, welche noch nicht zur Ausführung ausgewählt worden sind, und Gitter, welche teilweise ausgeführt worden sind und ausgesetzt worden sind.
  • Eine Arbeits-Verteilungs-Einheit 420, welche zwischen der TMU 415 und den SMs 450 gekoppelt ist, managed einen Pool von aktiven Gittern, Auswählen und Absetzen von aktiven Gittern zur Ausführung mittels der SMs 450. Anhängige Gitter werden zu einem aktiven Gitter-Pool mittels der TMU 415 transferiert, wenn ein anhängiges Gitter berechtigt ist auszuführen, d. h. keine unaufgelösten Daten-Abhängigkeiten hat. Ein aktives Gitter wird zu dem anhängigen Pool transferiert, wenn Ausführung des aktiven Gitters mittels einer Abhängigkeit blockiert ist. Wenn Ausführung eines Gitters vollendet ist, wird das Gitter von dem aktiven Gitter-Pool von der Arbeit-Verteilungs-Einheit 420 entfernt. Zusätzlich zum Empfangen von Gittern von der Host-Schnittstelle-Einheit 410 und der Arbeit-Verteilungs-Einheit 420 empfängt auch die TMU 415 Gitter, welche dynamisch mittels der SMs 450 während Ausführung eines Gitters erzeugt sind. Diese dynamisch erzeugten Gitter gesellen sich (join) zu den anderen anhängigen Gitter in dem anhängigen Gitter-Pool.
  • In einer Ausführungsform führt die CPU einen Treiber-Kernel aus, welcher eine Anwendungs-Programmier-Schnittstelle (API) implementiert, welche einer oder mehr Anwendungen, welche auf der CPU ausführen, ermöglicht, Operationen zur Ausführung auf der PPU 400 zu planen (schedule). Eine Anwendung kann Anweisungen umfassen (d. h. API-Befehle), welche den Treiber-Kernel veranlassen, ein oder mehr Gitter zur Ausführung zu erzeugen. In einer Ausführungsform implementiert die PPU 400 eine SIMD(Einzel-Anweisung, Mehr-Daten)-Architektur, wo jeder Thread-Block (d. h. Warp) in einem Gitter gleichzeitig auf einem verschiedenen Daten-Satz mittels verschiedener Threads in dem Thread-Block ausgeführt wird. Der Treiber-Kernel definiert Thread-Blocks, welche aus k bezogenen Threads gebildet sind, so dass Threads im selben Thread-Block Daten durch gemeinsam benutzten Speicher austauschen können. In einer Ausführungsform weist ein Thread-Block 32 bezogene Threads auf und ein Gitter ist ein Feld von einem oder mehr Thread-Blocks, welche denselben Strom ausführen und die verschiedenen Thread-Blocks können Daten durch globalen Speicher austauschen.
  • In einer Ausführungsform weist die PPU 400 X SMs 450(X) auf. Zum Beispiel kann die PPU 400 15 distinkte SMs 450 umfassen. Jeder SM 450 ist Mehrprozessor-gestützt und konfiguriert, eine Mehrzahl von Threads (z. B. 32 Threads) von einem bestimmten Thread-Block gleichzeitig auszuführen. Jeder der SMs 450 ist mit einem Level-Zwei-(L2)-Zwischenspeicher 465 über eine Kreuzschiene 460 (oder einen anderen Typ von Zwischenverbindungs-Netzwerk) verbunden. Der L2-Zwischenspeicher 465 ist mit einer oder mehr Speicher-Schnittstellen 480 verbunden. Speicher-Schnittstellen 480 implementieren 16-, 32-, 64-, 128-Bit-Daten-Busse, oder dergleichen, für Hoch-Geschwindigkeits-Daten-Übertragung. In einer Ausführungsform weist die PPU 400 U Speicher-Schnittstellen 480(U) auf, wobei jede Speicher-Schnittstelle 480(U) mit einem entsprechenden Speicher-Gerät 404(U) verbunden ist. Zum Beispiel kann PPU 400 mit bis zu 6 Speicher-Geräten 404 verbunden sein, wie etwa Grafik-Doppel-Daten-Rate, Version 5, synchroner dynamischer willkürlicher Zugriffs-Speicher (GDDR5 SDRAM).
  • In einer Ausführungsform implementiert die PPU 400 eine Mehr-Level-Speicher-Hierarchie. Der Speicher 404 ist außerhalb des Chips (Off-Chip) in SDRAM lokalisiert, gekoppelt mit der PPU 400. Daten von dem Speicher 404 können in dem L2-Zwischenspeicher 465 geholt und gespeichert werden, welcher Auf-Chip lokalisiert ist und zwischen den verschiedenen SMs 450 gemeinsam genutzt ist. In einer Ausführungsform implementiert jeder der SMs 450 auch einen L1-Zwischenspeicher. Der L1-Zwischenspeicher ist ein privater Speicher, welcher für einen bestimmten SM 450 dediziert ist. Jeder der L1-Zwischenspeicher ist mit dem gemeinsam benutzten L2-Zwischenspeicher 465 gekoppelt. Daten von dem L2-Zwischenspeicher 465 können in jedem der L1-Zwischenspeicher zum Verarbeiten in den funktionalen Einheiten der SMs 450 geholt und gespeichert werden.
  • In einer Ausführungsform weist die PPU 400 eine Grafik-Verarbeitungs-Einheit (GPU) auf. Die PPU 400 ist konfiguriert, Befehle zu empfangen, welche Schattierungs-Programme zum Verarbeiten von Grafik-Daten spezifizieren. Grafik-Daten können als ein Satz von Primitiven definiert werden, wie etwa Punkte, Linien, Dreiecke, Quadrate, Dreiecks-Streifen und dergleichen. Typischerweise umfasst eine Primitive Daten, welche eine Anzahl von Vertizes für die Primitive spezifizieren (z. B. in einem Modell-Raum-Koordinaten-System) sowie Attribute, welche mit jedem Vertex der Primitive assoziiert sind. Attribute können eines oder mehr einer Position, Farbe, Oberflächen-Normale-Vektor, Textur-Koordinaten, etc. umfassen. Die PPU 400 kann konfiguriert sein, die Grafik-Primitiven zu verarbeiten, um einen Frame-Puffer zu erzeugen (d. h. Pixel-Daten für jedes der Pixel der Anzeige). Der Treiber-Kernel implementiert eine Grafik-Verarbeitungs-Pipeline, wie etwa die Grafik-Verarbeitungs-Pipeline, welche mittels der OpenGL-API definiert ist.
  • Eine Anwendung schreibt Modell-Daten für eine Szene (d. h. eine Sammlung von Vertizes und Attributen) auf Speicher. Die Modell-Daten definieren jedes der Objekte, welches auf einer Anzeige sichtbar sein kann. Die Anwendung macht dann einen API-Aufruf an den Treiber-Kernel, welcher die Modell-Daten, welche zu rendern und anzuzeigen sind, anfragt. Der Treiber-Kernel liest die Modell-Daten und schreibt Befehle auf den Puffer, um eine oder mehr Operationen durchzuführen, um die Modell-Daten zu verarbeiten. Die Befehle können verschiedene Schattierungs-Programme kodieren, einschließlich eines oder mehr eines Vertex-Schattierers, Hülle-(hull)-Schattierers, Geometrie-Schattierers, Pixel-Schattierers, etc. Zum Beispiel kann die TMU 415 ein oder mehrere SMs 450 konfigurieren, ein Vertex-Schattierer-Programm auszuführen, welches eine Anzahl von Vertizes verarbeitet, welche mittels der Modell-Daten definiert sind. In einer Ausführungsform kann die TMU 415 verschiedene SMs 450 konfigurieren, verschiedene Schattierungs-Programme gleichzeitig auszuführen. Zum Beispiel kann eine erste Untermenge von SMs 450 konfiguriert sein, ein Vertex-Schattierungs-Programm auszuführen, während eine zweite Untermenge von SMs 450 konfiguriert sein kann, ein Pixel-Schattierungs-Programm auszuführen. Die erste Untermenge von SMs 450 verarbeitet Vertex-Daten, um verarbeitete Vertex-Daten zu erzeugen und schreibt die verarbeiteten Vertex-Daten auf den L2-Zwischenspeicher 465 und/oder den Speicher 404. Nachdem die verarbeiteten Vertex-Daten gerastert sind (d. h. von dreidimensionalen Daten in zweidimensionale Daten in Schirm-Raum transformiert sind), um Fragment-Daten zu erzeugen, führt die zweite Untermenge von SMs 450 einen Pixel-Schattierer aus, um verarbeitete Fragment-Daten zu erzeugen, welche dann mit anderen prozessierten Fragment-Daten gemischt werden (blended) und auf den Frame-Puffer in Speicher 404 geschrieben werden. Das Vertex-Schattierer-Programm und das Pixel-Schattierer-Programm können gleichzeitig ausführen, wobei verschiedene Daten von derselben Szene in einer Pipeline-Weise prozessiert werden, bis alle der Modell-Daten für die Szene an den Frame-Puffer gerendert worden sind. Dann werden die Inhalte des Frame-Puffers an eine Anzeige-Steuerung zur Anzeige auf einem Anzeige-Gerät übermittelt.
  • Die PPU 400 kann in einem Schreibtisch-Computer, einem Laptop-Computer, einem Tablet-Computer, einem Smartphone (z. B. ein drahtloses, angehaltenes Gerät), einem persönlichen digitalen Assistenten (PDA), einer Digital-Kamera, einem handgehaltenen elektronischen Gerät, und dergleichen umfasst sein. In einer Ausführungsform ist die PPU 400 auf einem einzelnen Halbleiter-Substrat verkörpert. In einer anderen Ausführungsform ist die PPU 400 in einem System-auf-einem-Chip (SoC) zusammen mit einer oder mehr anderen Logik-Einheiten umfasst, wie etwa eine reduzierte-Anweisungs-Satz-Computer-(RISC)-CPU, eine Speicher-Management-Einheit (MMU), ein Digital-zu-Analog-Konverter (DAC), und dergleichen.
  • In einer Ausführungsform kann die PPU 400 auf einer Grafik-Karte umfasst sein, welche ein oder mehr Speicher-Geräte 404, wie etwa GDDR5 SDRAM, umfasst. Die Grafik-Karte kann konfiguriert sein, mit einem PCIe-Schlitz bzw. Fach auf einer Mutter-Platine eines Schreibtisch-Computers eine Schnittstelle zu bilden, welcher z. B. einen Northbridge-Chip-Satz und einen Southbridge-Chip-Satz umfasst. In noch einer anderen Ausführungsform kann die PPU 400 eine integrierte Grafik-Verarbeitungs-Einheit (iGPU) sein, welche in dem Chip-Satz (d. h. Northbridge) der Mutter-Platine umfasst ist.
  • 5 illustriert den Streaming-Mehr-Prozessor 450 von 4 gemäß einer Ausführungsform. Wie in 5 gezeigt ist, umfasst der SM 450 einen Anweisungs-Zwischenspeicher 505, eine oder mehr Planer-Einheiten 510, eine Register-Datei 520, ein oder mehrere Verarbeitungs-Kerne 550, eine oder mehr Doppel-Präzisions-Einheiten (DPUs) 551, eine oder mehr Spezial-Funktions-Einheiten (SFUs) 552, eine oder mehr Lade/Speicher-Einheiten (LSUs) 553, ein Zwischenverbindungs-Netzwerk 580, einen gemeinsam benutzten Speicher/L1-Zwischenspeicher 570, und eine oder mehr Textur-Einheiten 590.
  • Wie oben beschrieben ist, setzt die Arbeit-Verteilungs-Einheit 420 aktive Gitter zur Ausführung auf einem oder mehr SMs 450 der PPU 400 ab. Die Planer-Einheit 510 empfängt die Gitter von der Arbeit-Verteilungs-Einheit 420 und managed ein Anweisungs-Planen für einen oder mehr Thread-Blöcke jedes aktiven Gitters. Die Planer-Einheit 510 plant Threads zur Ausführung in Gruppen von parallelen Threads, wobei jede Gruppe ein Warp genannt wird. In einer Ausführungsform umfasst jeder Warp 32 Threads. Die Planer-Einheit 510 kann eine Mehrzahl von verschiedenen Thread-Blöcken managen, Allozieren der Thread-Blöcke an Warps zur Ausführung und dann Planen von Anweisungen von der Mehrzahl von verschiedenen Warps auf den verschiedenen funktionalen Einheiten (d. h. Kerne 550, DPUs 551, SFUs 552, und LSUs 553) während jedes Takt-Zyklus.
  • In einer Ausführungsform umfasst jede Planer-Einheit 510 eine oder mehr Anweisungs-Absetz-Einheiten 515. Jede Absetz-Einheit 515 ist konfiguriert, Anweisungen an eine oder mehr der funktionalen Einheiten zu übermitteln. In der in 5 gezeigten Ausführungsform umfasst die Planer-Einheit 510 zwei Absetz-Einheiten 515, welche ermöglichen, dass zwei verschiedene Anweisungen von demselben Warp während jedes Takt-Zyklus abgesetzt werden. In alternativen Ausführungsformen kann jede Planer-Einheit 510 eine einzelne Absetz-Einheit 515 oder zusätzliche Absetz-Einheiten 515 umfassen.
  • Jeder SM 450 umfasst eine Register-Datei 520, welche einen Satz von Registern für die funktionalen Einheiten des SM 450 bereitstellt. In einer Ausführungsform ist die Register-Datei 520 zwischen jeder der funktionalen Einheiten derart geteilt, dass jeder funktionalen Einheit ein dedizierter Teil der Register-Datei 520 alloziert ist. In einer anderen Ausführungsform ist die Register-Datei 520 zwischen verschiedenen Warps geteilt, welche mittels des SM 450 ausgeführt werden. Die Register-Datei 520 stellt zeitweiligen Speicher für Operanden bereit, welche mit den Daten-Pfaden der funktionalen Einheiten verbunden sind.
  • Jeder SM 450 weist L Verarbeitungs-Kerne 550 auf. In einer Ausführungsform umfasst der SM 450 eine große Zahl (z. B. 192, etc.) von distinkten Verarbeitungs-Kernen 550. Jeder Kern 550 ist eine vollständig in einer Pipeline angeordnete, Einzel-Präzisions-Verarbeitungs-Einheit, welche eine Fließpunkt-Arithmetik-Logik-Einheit und eine Ganzzahl-Arithmetik-Logik-Einheit umfasst. In einer Ausführungsform implementiert die Fließpunkt-Arithmetik-Logik-Einheit den IEEE 754-2008-Standard für Fließpunkt-Arithmetik. Jeder SM 450 weist auch M DPUs 551 auf, welche Doppel-Präzision-Fließpunkt-Arithmetik implementieren, N SFUs 552, welche spezielle Funktionen durchführen (z. B. Pixel-Misch-Operationen und dergleichen), und P LSUs 553, welche Lade- und Speicher-Operationen zwischen dem gemeinsamen Speicher/L1-Zwischenspeicher 570 und der Register-Datei 520 implementieren. In einer Ausführungsform umfasst der SM 450 64 DPUs 551, 32 SFUs 552 und 32 LSUs 553.
  • Jeder SM 450 umfasst ein Zwischenverbindungs-Netzwerk 580, welches jede der funktionalen Einheiten mit der Register-Datei 520 und dem gemeinsam benutzten Speicher/L1-Zwischenspeicher 570 verbindet. In einer Ausführungsform ist das Zwischenverbindungs-Netzwerk 580 eine Kreuzschiene, welche konfiguriert sein kann, irgendeine der funktionalen Einheiten mit irgendeinem der Register in der Register-Datei 520 oder den Speicherstellen in dem gemeinsam benutzten Speicher/L1-Zwischenspeicher 570 zu verbinden.
  • In einer Ausführungsform ist der SM 450 innerhalb einer GPU implementiert. In solch einer Ausführungsform weist der SM 450 J Textur-Einheiten 590 auf. Die Textur-Einheiten 590 sind konfiguriert, Textur-Karten (z. B. ein 2D-Feld von Texeln) von dem Speicher 404 zu laden und die Textur-Karten abzutasten, um abgetastete Textur-Werte zur Benutzung in Schattierungs-Programmen zu erzeugen. Die Textur-Einheiten 590 implementieren Textur-Operationen, wie etwa Anti-Alising-Operationen unter Benutzung von Mip-Karten (d. h. Textur-Karten eines variierenden Detail-Levels). In einer Ausführungsform umfasst der SM 450 16 Textur-Einheiten 590.
  • Die PPU 400, welche oben beschrieben ist, kann konfiguriert sein, Hochparallel-Berechnungen viel schneller als herkömmliche GPUs durchzuführen. Parallel-Berechnung hat Vorteile in Grafik-Verarbeitung, Daten-Kompression, Biometrik, Strom-Verarbeitungs-Algorithmen und dergleichen.
  • 6 ist ein konzeptionelles Diagramm einer Grafik-Verarbeitungs-Pipeline 600, welche mittels der PPU 400 von 4 implementiert ist, in Übereinstimmung mit einer Ausführungsform. Die Grafik-Verarbeitungs-Pipeline 600 ist ein abstraktes Flussdiagramm der Verarbeitungs-Schritte, welche implementiert sind, um 2D-Computer-erzeugte Bilder von 3D-Geometrie-Daten zu erzeugen. Wie es wohl bekannt ist, können Pipeline-Architekturen Lang-Latenz-Operationen effizienter dadurch durchführen, dass die Operation in eine Mehrzahl von Stufen geteilt wird, wobei die Ausgabe jeder Stufe mit der Eingabe der nächsten aufeinanderfolgenden Stufe gekoppelt ist. Somit empfängt die Grafik-Verarbeitungs-Pipeline 600 Eingabe-Daten 601, welche von einer Stufe zu der nächsten Stufe der Grafik-Verarbeitungs-Pipeline 600 übermittelt sind, um Ausgabe-Daten 602 zu erzeugen. In einer Ausführungsform kann die Grafik-Verarbeitungs-Pipeline 600 eine Grafik-Verarbeitungs-Pipeline repräsentieren, welche mittels der OpenGL® API definiert ist.
  • Wie in 6 gezeigt ist, weist die Grafik-Verarbeitungs-Pipeline 600 eine Pipeline-Architektur auf, welche eine Zahl von Stufen umfasst. Die Stufen umfassen, sind jedoch nicht darauf beschränkt, eine Daten-Assemblierungs-Stufe 610, eine Vertex-Schattierungs-Stufe 620, eine Primitive-Assemblierungs-Stufe 630, eine Geometrie-Schattierungs-Stufe 640, eine Sichtpunkt-Skala (viewport scale), Cull, und Abschneide(clip)(VSCC)-Stufe 650, eine Rasterungs-Stufe 660, eine Fragment-Schattierungs-Stufe 670, und eine Raster-Operationen-Stufe 680. In einer Ausführungsform weisen die Eingabe-Daten 601 Befehle auf, welche die Verarbeitungs-Einheiten konfigurieren, die Stufen der Grafik-Verarbeitungs-Pipeline 600 zu implementieren und geometrische Primitive (z. B. Punkte, Linien, Dreiecke, Quader (quads), Dreiecks-Streifen oder Fächer (fans) etc.), welche mittels der Stufen zu prozessieren sind. Die Ausgabe-Daten 602 können Pixel-Daten (d. h. Farb-Daten) aufweisen, welche in einen Frame-Puffer oder einen anderen Typ von Oberflächen-Datenstruktur in einem Speicher kopiert sind.
  • Die Daten-Assemblierungs-Stufe 610 empfängt die Eingabe-Daten 601, welche Vertex-Daten für hohe-Ordnung-Oberflächen, Primitive oder dergleichen spezifizieren. Die Daten-Assemblierungs-Stufe 610 sammelt die Vertex-Daten in einem temporären Speicher oder Queue, wie etwa mittels eines Empfangens eines Befehls von dem Host-Prozessor, welcher einen Zeiger auf einen Puffer im Speicher umfasst, und mittels eines Lesens der Vertex-Daten aus dem Puffer. Die Vertex-Daten werden dann zu der Vertex-Schattierungs-Stufe 620 zur Verarbeitung übermittelt.
  • Die Vertex-Schattierungs-Stufe 620 verarbeitet Vertex-Daten dadurch, dass ein Satz von Operationen (d. h. ein Vertex-Schattierer oder ein Programm) durchgeführt wird, einmal für jeden der Vertizes. Vertizes können z. B. als ein Vier-Koordinate-Vektor spezifiziert sein, welcher mit einem oder mehr Vertex-Attributen assoziiert ist. Die Vertex-Schattierungs-Stufe 620 kann Eigenschaften manipulieren, wie etwa Position, Farbe, Textur-Koordinaten und dergleichen. Mit anderen Worten führt die Vertex-Schattierungs-Stufe 620 Operationen auf den Vertex-Koordinaten oder anderen Vertex-Attributen durch, welche mit einem Vertex assoziiert sind. Solche Operationen umfassen gewöhnlich Helligkeits-Operationen bzw. Beleuchtungs-Operationen (lighting operations) (d. h. Modifizieren von Farb-Attributen für einen Vertex) und Transformations-Operationen (d. h. Modifizieren des Koordinaten-Raumes für ein Vertex). Zum Beispiel können Vertizes unter Benutzung von Koordinaten in einem Objekt-Koordinaten-Raum spezifiziert sein, welche dadurch transformiert werden, dass die Koordinaten mittels einer Matrix multipliziert werden, welche die Koordinaten von dem Objekt-Koordinaten-Raum in einen Weltraum oder einen normalisiertes-Gerät-Koordinaten-(NCD)-Raum übersetzt. Die Vertex-Schattierungs-Stufe 620 erzeugt transformierte Vertex-Daten, welche zu der Primitive-Assemblierungs-Stufe 630 übermittelt sind.
  • Die Primitive-Assemblierungs-Stufe 630 sammelt Vertizes, welche mittels der Vertex-Schattierungs-Stufe 620 ausgegeben werden, und gruppiert die Vertizes in geometrische Primitive zur Verarbeitung mittels der Geometrie-Schattierungs-Stufe 640. Zum Beispiel kann die Primitive-Assemblierungs-Stufe 630 konfiguriert sein, alle drei aufeinanderfolgenden Vertizes als eine geometrische Primitive (d. h. ein Dreieck) zur Übermittlung an die Geometrie-Schattierungs-Stufe 640 zu gruppieren. In einigen Ausführungsformen können spezifische Vertizes für nachfolgende geometrische Primitive (z. B. zwei aufeinanderfolgende Dreiecke in einem Dreiecks-Streifen können zwei Vertizes teilen) wieder benutzt werden. Die Primitive-Assemblierungs-Stufe 630 übermittelt geometrische Primitive (d. h. eine Sammlung von assoziierten Vertizes) an die Geometrie-Schattierungs-Stufe 640.
  • Die Geometrie-Schattierungs-Stufe 640 prozessiert geometrische Primitive, indem ein Satz von Operationen (d. h. ein Geometrie-Schattierer oder Programm) auf den geometrischen Primitiven durchgeführt wird. Kachelungs-(Tessellations)-Operationen können eine oder mehr geometrische Primitive von jeder geometrischen Primitiven erzeugen. Mit anderen Worten kann die Geometrie-Schattierungs-Stufe 640 jede geometrische Primitive in ein feineres Gitter von zwei oder mehr geometrischen Primitiven zum Verarbeiten mittels des Restes der Grafik-Verarbeitungs-Pipeline 600 unterteilen. Die Geometrie-Schattierungs-Stufe 640 übermittelt geometrische Primitive an die Darstellungs-Feld-(viewport)-SCC-Stufe 650.
  • Die Darstellungs-Feld-SCC-Stufe 650 führt Darstellungs-Feld-Skalierung, Absondern (culling) und Abschneiden (clipping) der geometrischen Primitiven durch. Jede gerenderte Oberfläche ist mit einer abstrakten Kamera-Position assoziiert. Die Kamera-Position repräsentiert eine Stelle eines Beobachters, welcher auf die Szene schaut, und definiert einen Betrachtungs-Stumpf (viewing frustum), welcher die Objekte der Szene einschließt. Der Betrachtungs-Stumpf kann eine Betrachtungs-Ebene, eine hintere Ebene und vier Abschneide-Ebenen (clipping planes) umfassen. Irgendeine geometrische Primitive vollständig außerhalb des Betrachtungs-Stumpfes kann ausgesondert bzw. herausgefiltert sein (culled) (d. h. verworfen sein), weil die geometrische Primitive nicht zu der finalen gerenderten Szene beitragen wird. Irgendeine geometrische Primitive, welche teilweise innerhalb des Betrachtungs-Stumpfes und teilweise außerhalb des Betrachtungs-Stumpfes ist, kann abgeschnitten sein (d. h. in eine neue geometrische Primitive transformiert sein, welche innerhalb des Betrachtungs-Stumpfes eingeschlossen ist. Ferner können geometrische Primitive jeweils basierend auf Tiefe des Betrachtungs-Stumpfes skaliert sein. Alle potentiell sichtbaren geometrischen Primitiven werden dann zu der Rasterierungs-Stufe 660 übermittelt.
  • Die Rasterierungs-Stufe 660 konvertiert die 3D-geometrischen Primitiven in 2D-Fragmente. Die Rasterierungs-Stufe 660 kann konfiguriert sein, die Vertizes der geometrischen Primitiven zu benutzen, um einen Satz von Ebenen-Gleichungen aufzustellen, von welchen verschiedene Attribute interpoliert werden können. Die Rasterierungs-Stufe 660 kann auch eine Abdeckungs-Maske für eine Mehrzahl von Pixeln berechnen, welche anzeigt, ob ein oder mehr Proben-Position für das Pixel die geometrische Primitive schneiden. In einer Ausführungsform kann z-Testen auch durchgeführt werden, um zu bestimmen, ob die geometrische Primitive von anderen geometrischen Primitiven verdeckt ist, welche bereits gerastert worden sind. Die Rasterierungs-Stufe 660 erzeugt Fragment-Daten (d. h. interpolierte Vertex-Attribute, welche mit einer bestimmten Probe-Position für jedes abgedeckte Pixel assoziiert sind), welche zu der Fragment-Schattierungs-Stufe 670 übermittelt werden.
  • Die Fragment-Schattierungs-Stufe 670 verarbeitet Fragment-Daten, indem ein Satz von Operationen (d. h. ein Fragment-Schattierer oder ein Programm) auf jedem der Fragmente durchgeführt wird. Die Fragment-Schattierungs-Stufe 670 kann Pixel-Daten (d. h. Farbwerte) für das Fragment erzeugen, wie etwa mittels eines Durchführens von Beleuchtungs-Operationen oder eines Abtastens von Textur-Karten unter Benutzung von interpolierten Textur-Koordinaten für das Fragment. Die Fragment-Schattierungs-Stufe 670 erzeugt Pixel-Daten, welche zu der Raster-Operationen-Stufe 680 übermittelt werden.
  • Die Raster-Operationen-Stufe 680 kann verschiedene Operationen auf den Pixel-Daten durchführen, wie etwa ein Durchführen von Alpha-Tests, Stencil-Tests, Mischen (blending) der Pixel-Daten mit anderen Pixel-Daten entsprechend anderen Fragmenten, welche mit dem Pixel assoziiert sind. Wenn die Raster-Operationen-Stufe 680 Verarbeiten der Pixel-Daten beendet hat (d. h. die Ausgabe-Daten 602), können die Pixel-Daten zu einem Render-Ziel geschrieben werden, wie etwa ein Frame-Puffer, ein Farb-Puffer oder dergleichen.
  • Es wird geschätzt werden, dass eine oder mehr zusätzliche Stufen in der Grafik-Verarbeitungs-Pipeline 600 zusätzlich oder anstatt von einer oder mehr der Stufen umfasst sein kann, welche oben beschrieben sind. Verschiedene Implementierungen der abstrakten Grafik-Verarbeitungs-Pipeline können verschiedene Stufen implementieren. Ferner können eine oder mehr der oben beschriebenen Stufen von der Grafik-Verarbeitungs-Pipeline in einigen Ausführungsformen ausgeschlossen sein (wie etwa Geometrie-Schattierungs-Stufe 640). Andere Typen von Grafik-Verarbeitungs-Pipelines sind auch betrachtet, innerhalb des Geltungsbereichs der vorliegenden Offenbarung zu sein. Ferner kann irgendeine der Stufen der Grafik-Verarbeitungs-Pipeline 600 mittels einer oder mehr dedizierter Hardware-Einheiten innerhalb eines Grafik-Prozessors implementiert sein, wie etwa PPU 400. Andere Stufen der Grafik-Verarbeitungs-Pipeline 600 können mittels programmierbarer Hardware-Einheiten implementiert sein, wie etwa der SM 450 der PPU 400.
  • Unähnlich GPGPU-Programmen, wo ein einzelner Kernel auf der GPU 306 gestartet ist (launched), was Hunderte oder Tausende von Threads initiiert, sind Grafik-Programme dadurch implementiert, dass ein initialer Kernel auf der GPU 306 gestartet wird, welcher wiederum ein oder mehrere nachfolgende Kernel ohne eine Intervention mittels der CPU 301 startet. Zum Beispiel kann ein Grafik-Programm einen Kernel auf der GPU 306 starten, um die Vertex-Schattierungs-Stufe 620 auf einem SM 450 (oder mehreren SMs 450) durchzuführen. Dieser Kernel startet dann einen separaten Kernel, um die Geometrie-Schattierungs-Stufe 640 durchzuführen, welche wiederum einen anderen Kernel startet, um die Fragment-Schattierungs-Stufe 670 durchzuführen, usw. Zusätzlich können einige der anderen Stufen der Grafik-Verarbeitungs-Pipeline 600 auf fixierte-Einheit-Hardware implementiert sein, wie etwa ein Rasterer oder ein Daten-Assemblierer. Es wird geschätzt werden, dass Ergebnisse von einem Kernel mittels einer oder mehr dazwischen kommenden fixierte-Funktion-Hardware-Einheiten verarbeitet werden können, bevor sie mittels eines nachfolgenden Kernels auf einem SM 450 verarbeitet werden. Folglich sind unähnlich zu GPGPU-Programmen, welche möglicherweise mittels eines Ladens eines gesicherten Zustandes in einen der SMs 450 und eines erneuten Startens des angehaltenen Kernels wieder hergestellt werden können, Grafik-Programme viel schwieriger erneut zu laden, weil viele fixierte-Funktion-Einheiten es nicht erlauben, dass ein gesicherter Zustand erneut geladen wird. Der Wiederholen-Mechanismus, welcher oben beschrieben ist, vermindert dieses Problem.
  • 7A illustriert einen Teil von Code für ein Schattierungs-Programm 700 in Übereinstimmung mit einer Ausführungsform. Wie in 7A gezeigt ist, ist das Schattierungs-Programm 700 ein Vertex-Schattierer, welcher in einer Hoch-Level-Schattierer-Sprache, wie etwa NVIDIA® Cg (C für Grafik) programmiert ist. Das Schattierer-Programm 700 ist ein Teil von Code, welcher zum Rendern einer gekachelten (tessellated) Geometrie entwickelt ist. Es wird geschätzt werden, dass der Code für das Schattierungs-Programm 700 nur für illustrative Zwecke ist und dass irgendein Schattierer-Programm-Code unter Benutzung der hierin beschriebenen Techniken debugged werden kann.
  • Wie oben beschrieben ist, empfängt die Daten-Assemblierungs-Stufe 610 eine Liste von geometrischen Primitiven von der Grafik-Anwendung 334. Der API-Kontext ist konfiguriert, den Zustand der PPU 400 zu setzen, um zumindest einen Teil der Grafik-Verarbeitungs-Pipeline 600 zu implementieren. Sobald der API-Kontext aufgesetzt ist, kann ein anderer API-Befehl Aufgaben auf der PPU 200 starten bzw. einführen (launch). Die Aufgaben können eine Mehrzahl von Threads aufweisen, welche konfiguriert sind, z. B. ein Schattierungs-Programm zu implementieren. Jeder Thread in der Mehrzahl von Threads repräsentiert eine einzelne Instanz des Schattierungs-Programms 700. Wenn Vertizes von der Daten-Assemblierungs-Stufe 610 zu der Vertex-Schattierungs-Stufe 620 übermittelt sind, alloziert die Planer-Einheit 520 die Vertizes an einen verfügbaren Thread.
  • 7B illustriert ein System 750 zum Debuggen eines Schattierungs-Programms 335 unter Benutzung einer einzelnen GPU 306 in Übereinstimmung mit einer anderen Ausführungsform. Wie in 7B gezeigt ist, umfasst das System 750 eine Grafik-Anwendung 334, ein API-Abfang-Modul (interception module) 755, einen Treiber 332, eine GPU 306, und ein Anzeige-Gerät 308. Die Grafik-Anwendung 334, das API-Abfang-Modul 755 und der Treiber 332 werden mittels der CPU 301 ausgeführt. Um Quell-Code für das Schattierungs-Programm 335 zu debuggen, kann der Quell-Code mittels eines Compilers kompiliert werden und in einem Speicher gespeichert sein, welcher von der GPU 306 zugreifbar ist. Die Grafik-Anwendung 334 erzeugt einen Strom von API-Befehlen, welcher zumindest einen Befehl umfasst, welcher das Schattierungs-Programm 335 auf einem SM 450 der PPU 400 lädt und eine Anzahl von Threads auf dem SM 450 einführt bzw. startet, wobei jeder Thread eine Instanz des Schattierungs-Programms 335 ist. Das API-Abfang-Modul 755 ist konfiguriert, den Strom von API-Befehlen abzufangen, welcher mittels der Grafik-Anwendung 334 erzeugt ist. Das API-Abfang-Modul 755 verfolgt den Zustand des API-Kontextes dadurch nach, dass ein Zustand-Modell gemanaged wird, welches konfiguriert ist, den sich ändernden Zustand des API-Kontextes in Antwort auf den Strom von API-Befehlen zu emulieren. Das API-Abfang-Modul 755 leitet den Strom von API-Befehlen an den Treiber 332 weiter. Wiederum kann in einigen Ausführungsformen der Strom von API-Befehlen zu einer oder mehr intermediären Software-Schichten weitergeleitet werden, wie etwa eine Laufzeit-Bibliothek, welche die Direct3D® API implementiert. Der Treiber 332 übersetzt dann die API-Befehle in Anweisungen oder Befehle, welche zu der GPU 306 gesendet werden, um verschiedene Operationen durchzuführen, welche Bild-Daten zur Anzeige auf dem Anzeige-Gerät 308 erzeugen.
  • Um Debuggen des Quell-Codes 335 für das Grafik-Programm zu beginnen, kann die IDE 333 einen Befehl an das API-Abfang-Modul 755 übermitteln. Bei dem Start des nächsten Frames kann das API-Abfang-Modul 755 einen anfänglichen Zustand des API-Kontextes speichern. Dann speichert das API-Abfang-Modul 755 den Strom von API-Befehlen, welche mittels der Grafik-Anwendung 334 erzeugt sind, für ein oder mehr Frames in einem Wiederholen-Puffer. Sobald ein Strom von API-Befehlen in dem Wiederholen-Puffer gespeichert worden ist, initiiert dann das API-Abfang-Modul 755 eine Wiederholen-Schleife, bis die GPU 306 einem Unterbrechungs-Punkt begegnet. Wiederum ist der Unterbrechungs-Punkt eine spezielle Anweisung, welche in das kompilierte Schattierungs-Programm 335 Code mittels der IDE 333 eingefügt ist. Wenn der Unterbrechungs-Punkt mittels der GPU 306 ausgeführt ist, wird ein Fehler-Behandler ausgeführt, welcher dazu führt, dass das API-Abfang-Modul 755 den momentanen Zustand des GPU-Kontextes heraus auf den Schatten-Zustand-Speicher 336 speichert. Es wird geschätzt werden, dass Speichern des momentanen Zustands des GPU-Kontextes ein Kopieren der Information, welche auf das Zustand-Modell bezogen ist, einschließlich von Parametern, Register-Werten und gemeinsam benutztem Speicher, in den Schatten-Zustand-Speicher 336 aufweist. In einer Ausführungsform umfasst der GPU-Kontext Information über die momentan aktiven Threads, Register-Werte, lokaler-Speicher-Werte, Puffer, welche in globalem Speicher gespeichert sind, usw. Sobald der momentane Zustand des GPU-Kontextes auf den Schatten-Zustand-Speicher 336 gespeichert ist, kann den Threads auf der GPU 306 erlaubt sein, Ausführung zu beenden. Die GPU 306 kann dann befreit sein, einen verschiedenen Kontext zu verarbeiten. Folglich ist dem Anzeige-Gerät 308 erlaubt, neue Bild-Daten zur Anzeige zu erzeugen, so dass das Anzeige-Gerät 308 nicht auf dem vorherigen Frame eingefroren ist oder abgeschaltet ist, weil das Anzeige-Gerät 306 ein Empfangen von Video-Signalen stoppt.
  • Zurückkehrend auf 7A ermöglicht das API-Abfang-Modul 755, dass verschiedene Debuggen-Funktionalität unter Benutzung eines Systems mit einer einzelnen GPU 306 implementiert wird. Zum Beispiel kann der Benutzer die IDE 333 benutzen, um einen Unterbrechungs-Punkt in den Quell-Code des Schattierungs-Programms 335 einzusetzen. Der Programmierer kann eine spezifische Zeile des Quell-Codes auswählen und einen Unterbrechungs-Punkt unter Benutzung eines Befehls einfügen, welcher mittels der IDE 333 implementiert ist. Sobald der Programmierer einen Unterbrechungs-Punkt spezifiziert hat, kann der Programmierer einen Befehl innerhalb der IDE 333 auswählen, um eine momentane Version des Quell-Codes für das Schattierungs-Programm 335 zu kompilieren. In einer Ausführungsform kann der Unterbrechungs-Punkt in eine bereits kompilierte Version des Schattierungs-Programms 335 unter Benutzung von binären Zusammensetz-Techniken (patching techniques) eingefügt werden (d. h. Ersetzen von Anweisungen in dem Schattierungs-Programm, um zu einem Satz von Anweisungen zu springen, welche einen Unterbrechungs-Punkt umfassen). Die Grafik-Anwendung 334 kann ausgeführt werden, was einen Strom von API-Befehlen erzeugt, welche an eine Software-Schicht, wie etwa den Treiber 332, zu übermitteln sind. Die API-Befehle erzeugen einen API-Kontext, um einen Frame von Video-Daten zu rendern. Der Strom von API-Befehlen führt dazu, dass das modifizierte Schattierungs-Programm 335 mittels der GPU 306 ausgeführt wird.
  • Sobald der erste Unterbrechungs-Punkt erreicht ist, wird ein Fehler-Behandler in der GPU 306 ausgeführt und die Anweisungen des Fehler-Behandlers veranlassen das API-Abfang-Modul 755, den Zustand des GPU-Kontextes auf den Schatten-Zustand-Speicher 336 zu sichern. Der GPU 306 ist dann erlaubt, Ausführung der Threads fortzusetzen, bis der Frame gerendert worden ist. Der Programmierer kann dann den Zustand des GPU-Kontextes, welcher in dem Schatten-Zustand-Speicher 336 gespeichert ist, unter Benutzung der grafischen Benutzer-Schnittstelle (GUI), welche mittels der IDE 333 implementiert ist, untersuchen. Sobald der Programmierer den Zustand der GPU 306 bei dem ersten Unterbrechungs-Punkt untersucht hat, kann der Programmierer diesen Prozess wiederholen, wobei ein anderer Unterbrechungs-Punkt in dem Quell-Code für das Schattierungs-Programm 335 gesetzt wird.
  • Ein anderer Debugging-Mechanismus, welcher unter Benutzung des Wiederholen-Mechanismus implementiert ist, ist ein Durchschreiten von Anweisungen bzw. ein Anweisungs-Durchschreiten (instruction stepping). Es wird geschätzt sein, dass ein Schreiten zu der nächsten Anweisung oder dem nächsten Unterbrechungs-Punkt nicht so leicht ist wie ein einfaches Ausführen der nächsten anhängigen Anweisung für ein Thread oder eine Gruppe von Threads, weil die GPU 306 nicht für eine Zeitperiode angehalten werden kann, während sie darauf wartet, dass der Programmierer anzeigt, dass das Programm Ausführen fortsetzen sollte, ohne das Bild einzufrieren, welches auf dem Anzeige-Gerät 308 angezeigt ist. Daher kann die Wiederholen-Funktionalität, welche mittels des API-Abfang-Moduls 755 ermöglicht ist, benutzt werden, um wiederholt den Strom von API-Befehlen auszuführen, wobei Ausführung bei verschiedenen Punkten in dem Programm angehalten wird, wobei der momentane Zustand des GPU-Kontextes bei einem verschiedenen Punkt während jeder Iteration der Wiederholen-Schleife gespeichert ist, und wobei der gespeicherte Zustand des GPU-Kontextes angezeigt wird, während der GPU 306 erlaubt ist, Ausführen fortzusetzen.
  • In einer Ausführungsform ist das API-Abfang-Modul 755 konfiguriert, den anfänglichen Zustand des API-Kontextes während jedes Durchganges der Wiederholen-Schleife wieder herzustellen. Sobald der anfängliche Zustand des API-Kontextes wieder hergestellt worden ist, kann das API-Abfang-Modul 755 den Strom von API-Befehlen, welcher in dem Wiederholen-Puffer gespeichert ist, an die Software-Schicht übermitteln, was die GPU 306 veranlasst, den einen oder die mehreren Frames erneut zu rendern. Für Anweisungs-Durchschreiten zwischen Unterbrechungs-Punkten kann das API-Abfang-Modul 755 eine Liste von Unterbrechungs-Punkten nachverfolgen, welchen bereits begegnet worden sind. Jeder Unterbrechungs-Punkt kann mit einem bestimmten API-Befehl (z. B. ein dritter Zeichnen-Aufruf) sowie mit einer bestimmten Zeilen-Nummer in dem Schattierungs-Programm 335 assoziiert sein. Der Unterbrechungs-Punkt kann auch mit einem anderen Zustand assoziiert sein, wie etwa eine bestimmte Primitive (z. B. Vertex, Dreieck, Fragment, etc.), ein bestimmter Frame, etc. Wenn die GPU 306 einen Unterbrechungs-Punkt ausführt, führt der Fehler-Behandler dazu, dass das API-Abfang-Modul 755 den bestimmten Unterbrechungs-Punkt evaluiert, welcher zu dem Fehler führte, und bestimmt, ob dem Programm erlaubt werden sollte, fortzufahren, oder ob der momentane Unterbrechungs-Punkt der nächste Unterbrechungs-Punkt in einer sequentiellen Ordnung ist, welcher dem Programmierer angezeigt werden sollte. Der nächste Unterbrechungs-Punkt kann einen einzelnen Schritt von der vorherigen Anweisung repräsentieren.
  • Auf diese Weise wird durch das Programm Anweisung um Anweisung oder Unterbrechungs-Punkt um Unterbrechungs-Punkt geschritten. In Realität wird jedoch der volle Frame (oder Frames) erneut gerendert jedes Mal, wenn die Wiederholen-Schleife verarbeitet ist, und das API-Abfang-Modul 755 versucht einfach, den Zustand des GPU-Kontextes bei verschiedenen Punkten in dem Render-Prozess zu erfassen. Die Realität ist, dass die genaue Anordnung von Ausführung mittels der GPU 306 nicht dieselbe während jedes Durchganges der Wiederholen-Schleife sein muss. Mit anderen Worten, während der Strom von API-Befehlen eine konstante Ordnung hat, kann die Architektur der GPU 306 Ausführung von bestimmten Threads in verschiedener Ordnung basierend auf verschiedenen Planungs-Algorithmen planen, derart, dass die Ordnung von Ausführung von Threads nicht genau dieselbe während verschiedener Iterationen der Wiederholen-Schleife sein muss, aber der Zustand für einen bestimmten Thread von Interesse kann genau wieder hergestellt werden, verglichen mit den vorherigen Iterationen der Wiederholen-Schleife. Mittels eines Fortfahrens, durch die Anweisungen zu schreiten und eines Inspizierens des Zustandes des GPU-Kontextes während jedes Schrittes, scheint das Programm sequentiell ausgeführt zu werden und der Programmierer kann mögliche Fehler (bugs) in dem Quell-Code ähnlich zu herkömmlichen Debugging-Werkzeugen identifizieren.
  • Es wird geschätzt werden, dass in gewissen Architekturen ein bestimmtes Schattierungs-Programm 335 im Wesentlichen parallel für Hunderte oder Tausende von Threads ausgeführt werden kann. Somit kann ein einzelner Unterbrechungs-Punkt in einem Schattierungs-Programm 335 während jedes Takt-Zyklus für eine bestimmte Gruppe von Threads (d. h. ein Warp) erreicht werden, während derselbe Unterbrechungs-Punkt während einem oder mehrerer zusätzlicher Takt-Zyklen für verschiedene Gruppen von Threads erreicht werden kann, welche Instanzen desselben Schattierungs-Programms 335 sind. Zum Beispiel kann ein Fragment-Schattierer ein oder mehrere Male für jedes Pixel eines Bildes ausgeführt werden, wobei ein 1080p HD-Bild über 2 Mio. Pixel hat. Die GPU 306 kann nur einen Teil dieser Threads während irgendeines gegebenen Takt-Zyklus verarbeiten. Daher kann ein einzelner Unterbrechungs-Punkt in dem Schattierungs-Programm 335 eine Anzahl von Malen für eine Gruppe von bezogenen Threads erreicht werden. In einer Ausführungsform verfolgt das API-Abfang-Modul 755 die Anzahl von Malen nach, für welche der momentane Durchgang der Wiederholen-Schleife einem bestimmten Unterbrechungs-Punkt begegnet ist. Mit anderen Worten kann das API-Abfang-Modul 755 einen Zähler halten, welcher anzeigt, wie viele Male der Unterbrechungs-Punkt während einer bestimmten Debugging-Sitzung getroffen worden ist. Dann wird während eines bestimmten Durchgangs der Wiederholen-Schleife das API-Abfang-Modul 755 nachverfolgen, wie viele Male dieser bestimmte Unterbrechungs-Punkt den Fehler-Behandler ausgelöst hat. Wenn dem Unterbrechungs-Punkt nicht eine Schwellwert-Anzahl von Malen während dieses bestimmten Durchganges der Wiederholen-Schleife begegnet worden ist, dann erlaubt das API-Abfang-Modul 755 der GPU 306, Ausführung fortzuführen. Wenn jedoch dem Unterbrechungs-Punkt die Schwellwert-Anzahl von Malen während dieses bestimmten Durchganges der Wiederholen-Schleife begegnet worden ist, dann veranlasst das API-Abfang-Modul 755, dass der momentane Zustand des GPU-Kontextes auf den Schatten-Zustand-Speicher 336 gespeichert wird. Dieser Typ von Betrieb stellt die Illusion eines Fortschrittes für die Ausführung des Schattierungs-Programmes 335 bereit, selbst wenn es nur einen einzelnen Unterbrechungs-Punkt gibt, welcher in dem Schattierungs-Programm 335 umfasst ist.
  • Mit anderen Worten würde Stoppen bei dem ersten Unterbrechungs-Punkt in einem Schattierungs-Programm, welches mittels Hunderten oder Tausenden von Threads in paralleler Weise ausgeführt wird, immer das Rendern bei einem bestimmten Punkt nahe dem Beginn des Frames stoppen. Die Illusion eines Fortschrittes ist dadurch bereitgestellt, dass automatisch eine Anzahl von Unterbrechungs-Punkten während jeder Iteration der Wiederholen-Schleife übersprungen wird, um auf einen verschiedenen Punkt bei dem Rendern des Frames vorzurücken.
  • 8A, 8B und 8C illustrieren ein Flussdiagramm eines Verfahrens 800 zum Debugging von Grafik-Programmen mit einer einzelnen GPU 306 in Übereinstimmung mit einer anderen Ausführungsform. Bei Schritt 802 überwacht ein API-Abfang-Modul 755 einen Strom von API-Befehlen, welcher mittels einer Grafik-Anwendung 334 erzeugt sind. In einer Ausführungsform ist das API-Abfang-Modul 755 ein Anwendungs-Shim, welcher konfiguriert ist, API-Befehle, welche mittels einer Grafik-Anwendung 334 erzeugt sind, abzufangen, und ein Zustand-Modell zu managen, welches einen API-Kontext repräsentiert, welcher mit der Grafik-Anwendung 334 assoziiert ist. Bei Schritt 804 bestimmt das API-Abfang-Modul 755, ob der nächste Frame erfasst werden soll. In einer Ausführungsform kann das API-Abfang-Modul 755 konfiguriert sein, einen Befehl von der IDE 333 zu empfangen, welcher das API-Abfang-Modul 755 veranlasst, den Strom von API-Befehlen für den nächsten Frame zu erfassen. In einer anderen Ausführungsform kann das API-Abfang-Modul 755 konfiguriert sein, einen Frame automatisch zu erfassen, wenn ein erster Unterbrechungs-Punkt in einem Schattierungs-Programm 335 gesetzt ist, und konfiguriert, einen Frame nicht automatisch zu erfassen, wenn alle Unterbrechungs-Punkte von dem Schattierungs-Programm 335 entfernt sind. Wenn das API-Abfang-Modul 755 keine Anweisung empfangen hat, den nächsten Frame zu erfassen, dann fährt das API-Abfang-Modul 755 fort, den Strom von API-Befehlen, welcher mittels der Grafik-Anwendung 334 erzeugt ist, zu überwachen. Wenn jedoch das API-Abfang-Modul 755 eine Anweisung, den nächsten Frame zu erfassen, empfangen hat, dann erfasst bei Schritt 806 das API-Abfang-Modul 755 einen initialen Zustand des API-Kontextes. In einer Ausführungsform erzeugt das API-Abfang-Modul 755 eine Kopie des Zustands-Modells bei dem Start des nächsten Frames in dem Speicher 304.
  • Bei Schritt 808 speichert das API-Abfang-Modul 755 einen Strom von API-Befehlen für den momentanen Frame in einem Wiederholen-Puffer. Der Wiederholen-Puffer ist eine Daten-Struktur in dem Speicher 304, welche eine geordnete Liste der API-Befehle für zumindest einen Frame hält. Bei Schritt 810 kann das API-Abfang-Modul 755 die Ausführung der Grafik-Anwendung 334 pausieren. Es wird geschätzt werden, dass gewisse Prozesse in heutigen modernen Betriebs-Systemen angehalten werden können. Bei Schritt 812 initiiert das API-Abfang-Modul 755 eine Wiederholen-Schleife. Jeder Durchgang der Wiederholen-Schleife wird den API-Kontext auf den anfänglichen Zustand des API-Kontextes zurücksetzen, welcher in Schritt 806 erfasst ist, und den Strom von API-Befehlen, welche in dem Wiederholen-Puffer gespeichert sind, zu der Software-Schicht erneut übermitteln, um den Frame ein oder mehrere Male erneut zu rendern.
  • Bei Schritt 814 setzt das API-Abfang-Modul 755 den Zustand des API-Kontextes auf den initialen Zustand des API-Kontextes zurück. In einer Ausführungsform kann das API-Abfang-Modul 755 konfiguriert sein, einen neuen API-Kontext zu erzeugen, welcher den initialen Zustand des API-Kontextes repräsentiert, welcher in dem Speicher 304 gesichert ist. Der neue API-Kontext kann dadurch erzeugt werden, dass neue API-Befehle ausgestellt sind, welche Parameter umfassen, welche auf den anfänglichen Zustand des API-Kontextes bezogen sind. In einer anderen Ausführungsform ist das API-Abfang-Modul 755 konfiguriert, API-Befehle zu erzeugen, welche den momentanen API-Kontext modifizieren, um den initialen Zustand des API-Kontextes zurückzusetzen. Es wird geschätzt werden, dass das API-Abfang-Modul 755 auch konfiguriert sein kann, den Zustand von Objekten (z. B. Puffer, Texturen, etc.) in dem Speicher 304 basierend auf dem initialen Zustand des API-Kontextes zurückzusetzen.
  • Bei Schritt 816 übermittelt das API-Abfang-Modul 755 einen API-Befehl von dem Strom von API-Befehlen, welcher in dem Wiederholen-Puffer gespeichert ist, an eine Software-Schicht. Wiederum kann die Software-Schicht ein Treiber oder eine Laufzeit-Bibliothek sein, welche die API implementiert. Bei Schritt 818 bestimmt das API-Abfang-Modul 755, ob ein Unterbrechungs-Punkt erreicht worden ist. In einer Ausführungsform führt die GPU 306 einen Fehler-Behandler aus, wenn ein Unterbrechungs-Punkt erreicht ist, welcher veranlasst, dass eine Nachricht an den Treiber 332 übermittelt wird. Der Treiber 332 kann das API-Abfang-Modul 755 informieren, dass ein Unterbrechungs-Punkt dazu geführt hat, dass die GPU 306 Ausführung des Grafik-Programms anhält, und das API-Abfang-Modul 755 kann verschiedene Operationen, welche auf den Unterbrechungs-Punkt bezogen sind, durchführen. Wenn ein Unterbrechungs-Punkt nicht erreicht worden ist, dann kehrt das Verfahren 800 zu Schritt 816 zurück, wo der nächste API-Befehl in dem Wiederholen-Puffer an die Software-Schicht übermittelt wird. Wenn jedoch ein Unterbrechungs-Punkt erreicht worden ist, dann bestimmt bei Schritt 820 das API-Abfang-Modul 755, ob Ausführung fortzuführen ist. In einer Ausführungsform bestimmt das API-Abfang-Modul 755, ob der bestimmte Unterbrechungs-Punkt, welcher den Fehler-Behandler ausgelöst hat, das API-Abfang-Modul 755 veranlassen sollte, den momentanen Zustand des GPU-Kontextes auf den Schatten-Zustand-Speicher 336 zu speichern. Wenn z. B. der Unterbrechungs-Punkt erreicht worden ist, bevor und das API-Abfang-Modul 755 ist konfiguriert, die Illusion eines Fortschrittes dadurch bereitzustellen, dass gewartet wird, bis spätere Threads den Unterbrechungs-Punkt auslösen, dann erlaubt das API-Abfang-Modul 755, dass die GPU Ausführung fortsetzt, und das Verfahren kehrt zu Schritt 818 zurück, um auf den nächsten Unterbrechungs-Punkt zu warten. Wenn jedoch Ausführung gestoppt werden sollte, dann wird bei Schritt 822 der GPU-Kontext in dem Schatten-Zustand-Speicher 336 gespeichert. Sobald der GPU-Kontext in dem Schatten-Zustand-Speicher 336 gespeichert ist, dann kann bei Schritt 824 die GPU wieder aufgenommen werden und erlaubt werden, Ausführung fortzusetzen.
  • Bei Schritt 826 übermittelt das API-Abfang-Modul 755 den nächsten API-Befehl in dem Wiederholen-Puffer an die Software-Schicht. Bei Schritt 828 bestimmt das API-Abfang-Modul 755, ob das Ende des Frames erreicht worden ist. Ein bestimmter API-Befehl in dem Strom von API-Befehlen kann anzeigen, dass das Ende des Frames erreicht worden ist. Wenn das Ende des Frames nicht erreicht worden ist, dann kehrt das Verfahren 800 zu Schritt 826 zurück und übermittelt einen anderen API-Befehl an die Software-Schicht. Wenn jedoch das Ende des Frames erreicht worden ist, dann bestimmt bei Zustand 830 das API-Abfang-Modul 755, ob mit einem anderen Durchgang der Wiederholen-Schleife fortzufahren ist. Das API-Abfang-Modul 755 kann auf einen Befehl von einem Debugging-Werkzeug warten, welcher anzeigt, dass ein Programmierer einen anderen Durchgang durchführen will und den GPU-Kontext bei einem anderen Punkt in dem Programm inspizieren möchte. Wenn das API-Abfang-Modul 755 bestimmt, dass ein anderer Durchgang der Wiederholen-Schleife gemacht werden sollte, dann kehrt das Verfahren 800 zu Schritt 814 zurück, wo der initiale Zustand des API-Kontextes wieder hergestellt wird. Wenn jedoch das API-Abfang-Modul 755 bestimmt, dass die Wiederholen-Schleife terminiert werden sollte, dann säubert bei Schritt 832 das API-Abfang-Modul 755 die Wiederholen-Schleife. In einer Ausführungsform kann das API-Abfang-Modul 755 Speicher, welcher für den Schatten-Zustand-Speicher 336 den initialen Zustand der API, usw. benutzt ist, deallozieren. Nach Schritt 832 terminiert das Verfahren 800.
  • 9 illustriert ein exemplarisches System 900, in welchem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert sein kann. Wie gezeigt ist, ist ein System 900 bereitgestellt, welches zumindest einen Zentral-Prozessor 901 umfasst, welcher mit einem Kommunikations-Bus 902 verbunden ist. Der Kommunikations-Bus 902 kann unter Benutzung irgendeines geeigneten Protokolls implementiert werden, wie etwa PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), Hyper-Transport, oder irgendein anderes Bus- oder Punkt-zu-Punkt-Kommunikation-Protokoll(e). Das System 900 umfasst auch einen Hauptspeicher 904. Steuer-Logik (Software) und Daten sind in dem Hauptspeicher 904 gespeichert, welcher die Form eines Speichers mit willkürlichem Zugriff (RAM) annehmen kann.
  • Das System 900 umfasst auch Eingabe-Geräte 912, einen Grafik-Prozessor 906 und eine Anzeige 908, d. h. einen konventionellen CRT (Kathoden-Strahl-Röhre), LCD (Flüssigkristall-Anzeige), LED (Licht emittierende Diode), Plasma-Anzeige oder dergleichen. Benutzer-Eingabe kann von den Eingabe-Geräten 912 empfangen werden, z. B. Tastatur, Maus, Berührfeld, Mikrofon, und dergleichen. In einer Ausführungsform kann der Grafik-Prozessor 906 eine Mehrzahl von Schattierungs-Modulen, ein Raster-Modul, etc. umfassen. Jedes der vorangehenden Module kann sogar auf einer einzelnen Halbleiter-Plattform situiert sein, um eine Grafik-Verarbeitungs-Einheit (GPU) zu bilden.
  • In der vorliegenden Beschreibung bezieht sich eine einzelne Halbleiter-Plattform auf eine einzelne unitäre Halbleiter-basierte integrierte Schaltung oder Chip. Es sollte bemerkt sein, dass der Ausdruck einzelne Halbleiter-Plattform sich auch auf Mehr-Chip-Module mit einer erhöhten Konnektivität beziehen kann, welche Auf-Chip-Operation simulieren, und welche wesentliche Verbesserungen über ein Benutzen einer konventionellen Zentral-Verarbeitungs-Einheit (CPU) und Bus-Implementierung machen. Natürlich können die verschiedenen Module auch separat oder in verschiedenen Kombinationen von Halbleiter-Plattformen nach den Wünschen des Benutzers situiert sein.
  • Das System 900 kann auch einen sekundären Speicher 910 umfassen. Der sekundäre Speicher 910 umfasst z. B. ein Festplatte-Laufwerk und/oder ein entfernbares Speicher-Laufwerk, welches ein Floppydisk-Laufwerk repräsentiert, ein Magnetband-Laufwerk, ein Kompaktdisk-Laufwerk, digitale versatile Disk-(DVD)-Laufwerk, Aufzeichnungs-Laufwerk, Universal-Serial-Bus-(USB)-Flash-Speicher. Das entfernbare Speicher-Laufwerk liest von und/oder schreibt auf eine entfernbare Speicher-Einheit in einer wohl bekannten Weise.
  • Computer-Programme oder Computer-Steuerlogik-Algorithmen können in dem Hauptspeicher 904 und/oder dem sekundären Speicher 910 gespeichert sein. Solche Computer-Programme, wenn ausgeführt, befähigen das System 900, verschiedene Funktionen durchzuführen. Der Speicher 904, Speicherung 910 und/oder irgendein anderer Speicher sind mögliche Beispiele von Computer-lesbaren Medien.
  • In einer Ausführungsform kann die Architektur und/oder Funktionalität der verschiedenen vorherigen Figuren in dem Kontext des Zentral-Prozessors 901, Grafik-Prozessors 906, und integrierte Schaltung (nicht gezeigt) implementiert sein, welche befähigt ist von zumindest einem Teil der Fähigkeiten von sowohl dem Zentral-Prozessor 901 als auch dem Grafik-Prozessor 906, ein Chip-Satz (d. h. eine Gruppe von integrierte Schaltungen, welche ausgelegt sind, als eine Einheit zum Durchführen betreffender Funktionen zu arbeiten und verkauft zu werden, etc.), und/oder irgendeine andere integrierte Schaltung für diesen Zweck.
  • Noch weiter kann die Architektur und/oder Funktionalität der verschiedenen vorherigen Figuren in dem Zusammenhang eines Allgemein-Computer-Systems, eines Schaltungsplatte-Systems, eine Spielkonsole-Systems, welches für Unterhaltungs-Zwecke dediziert ist, eines Anwendungs-spezifischen Systems, und/oder irgendeines anderen gewünschten Systems implementiert sein. Zum Beispiel kann das System 900 die Form eines Schreibtisch-Computers, Laptop-Computers, Servers, Arbeitsstation, Spielkonsole, eingebettetes System und/oder irgendeinen anderen Typ von Logik annehmen. Noch weiter kann das System 900 die Form von verschiedenen anderen Geräten annehmen, einschließlich, aber nicht darauf beschränkt, ein persönlicher-digitaler-Assistenten-(PDA)-Gerät, ein mobiles Telefongerät, ein Fernseher, etc.
  • Ferner kann, während es nicht gezeigt ist, das System 900 mit einem Netzwerk (z. B. ein Telekommunikations-Netzwerk, Lokalbereichs-Netzwerk (LAN), drahtloses Netzwerk, Fernbereichs-Netzwerk (WAN) wie etwa das Internet, Peer-to-Peer-Netzwerk, Kabel-Netzwerk, oder dergleichen) für Kommunikations-Prozesse gekoppelt sein.
  • Während verschiedene Ausführungsformen oben beschrieben worden sind, sollte es verstanden sein, dass sie nur als Beispiel und nicht als Begrenzung präsentiert worden sind. Somit sollte die Breite und der Geltungsbereich der bevorzugten Ausführungsform nicht mittels der oben beschriebenen beispielhaften Ausführungsformen begrenzt sein, sondern sollte nur in Übereinstimmung mit den folgenden Ansprüchen und ihren Äquivalenten definiert sein.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • IEEE 754-2008-Standard [0050]

Claims (20)

  1. Verfahren, aufweisend: Speichern eines initialen Zustandes eines Anwendungs-Programmier-Schnittstelle-(API)-Kontextes in einem Speicher, wobei der anfängliche Zustand des API-Kontextes dem Start eines Frames entspricht; Abfangen eines Stroms von API-Befehlen, welcher mit dem Frame assoziiert ist, wobei der Strom von API-Befehlen mittels einer Grafik-Anwendung erzeugt ist; Übermitteln des Stroms von API-Befehlen an eine Software-Schicht, welche die API implementiert, um den Frame zu rendern; und in Antwort auf einen Unterbrechungs-Punkt, Speichern eines Grafik-Verarbeitungs-Einheit-(GPU)-Kontextes in dem Speicher.
  2. Verfahren gemäß Anspruch 1, ferner aufweisend Ausführen einer Wiederholen-Schleife, aufweisend: Erzeugen eines oder mehrerer API-Befehle, um den API-Kontext auf den initialen Zustand wieder herzustellen; erneut Übermitteln des Stromes von API-Befehlen an die Software-Schicht, um den Frame erneut zu rendern; und in Antwort auf einen anderen Unterbrechungs-Punkt, Speichern eines anderen GPU-Kontextes in dem Speicher.
  3. Verfahren gemäß Anspruch 2, wobei die Wiederholen-Schleife in Antwort auf einen Befehl wiederholt wird, welcher von einer integrierten Entwicklungs-Umgebung (IDE) empfangen ist.
  4. Verfahren gemäß Anspruch 1, wobei die Software-Schicht ein Treiber ist.
  5. Verfahren gemäß Anspruch 4, wobei der Treiber eine OpenGL® API implementiert.
  6. Verfahren gemäß Anspruch 1, wobei die Software-Schicht eine Laufzeit-Bibliothek ist.
  7. Verfahren gemäß Anspruch 6, wobei die Laufzeit-Bibliothek eine Direct3D® API implementiert.
  8. Verfahren gemäß Anspruch 1, ferner aufweisend Nachverfolgen des Zustandes des API-Kontextes.
  9. Verfahren gemäß Anspruch 8, wobei Nachverfolgen des Zustandes des API-Kontextes aufweist: Initiieren eines Zustand-Modells, welches mit der Grafik-Anwendung assoziiert ist; und für jeden API-Befehl, welcher mittels der Grafik-Anwendung erzeugt ist, Aktualisieren des Zustand-Modells basierend auf dem API-Befehl.
  10. Verfahren gemäß Anspruch 1, wobei der Strom von API-Befehlen mittels eines Anwendungs-Shims abgefangen wird.
  11. Verfahren gemäß Anspruch 1, ferner aufweisend: in Antwort auf einen Unterbrechungs-Punkt, Bestimmen, ob Ausführung fortzuführen ist basierend auf dem Unterbrechungs-Punkt; und wenn Ausführung fortgeführt werden sollte, dann Übermitteln eines API-Befehls an die Software-Schicht, um Ausführung wieder aufzunehmen, oder wenn Ausführung nicht fortgesetzt werden sollte, dann Speichern des GPU-Kontextes in dem Speicher.
  12. Verfahren gemäß Anspruch 11, wobei Bestimmen, ob Ausführung fortzuführen ist, basierend auf dem Unterbrechungs-Punkt, Vergleichen eines Zählers, welcher mit dem Unterbrechungs-Punkt assoziiert ist, mit einem Schwellwert aufweist, welcher mit einer Zahl von Iterationen der Wiederholen-Schleife assoziiert ist.
  13. Verfahren gemäß Anspruch 1, wobei der initiale Zustand des API-Kontextes einen Zustand einer Grafik-Verarbeitungs-Einheit repräsentiert, welche mit dem API-Kontext bei dem Beginn des Frames assoziiert ist.
  14. Nicht-transitorisches Computer-lesbares Speichermedium, welches Anweisungen speichert, welche, wenn mittels eines Prozessors ausgeführt, den Prozessor veranlassen, die Schritte durchzuführen, aufweisend: Speichern eines initialen Zustandes eines Anwendungs-Programmier-Schnittstelle-(API)-Kontextes in einem Speicher, wobei der anfängliche Zustand des API-Kontextes dem Start eines Frames entspricht; Abfangen eines Stroms von API-Befehlen, welcher mit dem Frame assoziiert ist, wobei der Strom von API-Befehlen mittels einer Grafik-Anwendung erzeugt ist; Übermitteln des Stroms von API-Befehlen an eine Software-Schicht, welche die API implementiert, um den Frame zu rendern; und in Antwort auf einen Unterbrechungs-Punkt, Speichern eines Grafik-Verarbeitungs-Einheit-(GPU)-Kontextes in dem Speicher.
  15. Nicht-transitorisches Computer-lesbares Speichermedium gemäß Anspruch 14, wobei die Software-Schicht ein Treiber ist.
  16. Nicht-transitorisches Computer-lesbares Speichermedium gemäß Anspruch 14, wobei die Schritte ferner aufweisen Nachverfolgen des Zustandes des API-Kontextes mittels: eines Initiierens eines Zustand-Modells, welches mit der Grafik-Anwendung assoziiert ist; und mittels eines Aktualisierens des Zustand-Modelles basierend auf dem API-Befehl für jeden API-Befehl, welcher mittels der Grafik-Anwendung erzeugt ist.
  17. System, aufweisend: eine Grafik-Verarbeitungs-Einheit (GPU); einen Speicher, welcher konfiguriert ist, einen Anwendungs-Shim zu speichern, wobei der Anwendungs-Shim konfiguriert ist, um: einen initialen Zustand eines Anwendungs-Programmier-Schnittstelle-(API)-Kontextes in einem Speicher zu speichern, wobei der initiale Zustand des API-Zustandes einem Start eines Frames entspricht, einen Strom von API-Befehlen, welche mit dem Frame assoziiert sind, abzufangen, wobei der Strom von API-Befehlen mittels einer Grafik-Anwendung erzeugt ist, den Strom von API-Befehlen an eine Software-Schicht zu übermitteln, welche die API implementiert, um den Frame zu rendern, und in Antwort auf einen Unterbrechungs-Punkt, Speichern eines GPU-Kontextes in dem Speicher.
  18. System gemäß Anspruch 17, wobei die Grafik-Anwendung mit einem oder mehr Schattierungs-Programmen assoziiert ist, welche konfiguriert sind, mittels der GPU ausgeführt zu werden.
  19. System gemäß Anspruch 17, wobei die Software-Schicht einen Treiber aufweist, welcher eine OpenGL-API implementiert.
  20. System gemäß Anspruch 17, wobei der Anwendungs-Shim ferner konfiguriert ist, einen Zustand des API-Kontextes nachzuverfolgen mittels: eines Initiierens eines Zustand-Models, welches mit der Grafik-Anwendung assoziiert ist; und eines Aktualisierens des Zustands-Modells basierend auf dem API-Befehl für jeden API-Befehl, welcher mittels der Grafik-Anwendung erzeugt ist.
DE102013224046.5A 2012-11-26 2013-11-25 System, Verfahren und Computer-Programm-Produkt zum Debuggen von Grafik-Programmen lokal unter Benutzung eines Systems mit einer einzelnen GPU Withdrawn DE102013224046A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201261730025P 2012-11-26 2012-11-26
US61/730,025 2012-11-26
US14/076,105 2013-11-08
US14/076,105 US9292414B2 (en) 2012-11-26 2013-11-08 System, method, and computer program product for debugging graphics programs locally utilizing a system with a single GPU

Publications (1)

Publication Number Publication Date
DE102013224046A1 true DE102013224046A1 (de) 2014-05-28

Family

ID=50679204

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102013224046.5A Withdrawn DE102013224046A1 (de) 2012-11-26 2013-11-25 System, Verfahren und Computer-Programm-Produkt zum Debuggen von Grafik-Programmen lokal unter Benutzung eines Systems mit einer einzelnen GPU

Country Status (4)

Country Link
US (1) US9292414B2 (de)
CN (1) CN103838669A (de)
DE (1) DE102013224046A1 (de)
TW (1) TW201426301A (de)

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014108733A1 (en) 2013-01-08 2014-07-17 Freescale Semiconductor, Inc. Method and apparatus for estimating a fragment count for the display of at least one three-dimensional object
US20150145871A1 (en) * 2013-11-22 2015-05-28 Nvidia Corporation System, method, and computer program product to enable the yielding of threads in a graphics processing unit to transfer control to a host processor
US9785536B2 (en) * 2013-11-29 2017-10-10 Nxp Usa, Inc. Code injection for conditional breakpoints
US9928564B2 (en) * 2014-06-26 2018-03-27 Intel Corporation Efficient hardware mechanism to ensure shared resource data coherency across draw calls
US9978171B2 (en) 2014-07-29 2018-05-22 Nvidia Corporation Control of a sample mask from a fragment shader program
CN104469385B (zh) * 2014-12-11 2018-11-13 北京星网锐捷网络技术有限公司 基于虚拟化技术的图形显示方法及装置
WO2016099467A1 (en) * 2014-12-16 2016-06-23 Hewlett-Packard Development Company, L.P. Processing data in a thin client terminal
US10402931B2 (en) * 2015-06-07 2019-09-03 Apple Inc. Systrace visualization tool
US9971542B2 (en) * 2015-06-09 2018-05-15 Ultrata, Llc Infinite memory fabric streams and APIs
US11023993B2 (en) 2015-06-23 2021-06-01 Nxp Usa, Inc. Apparatus and method for verifying fragment processing related data in graphics pipeline processing
US9836808B2 (en) 2015-06-23 2017-12-05 Nxp Usa, Inc. Apparatus and method for verifying image data comprising mapped texture image data
US9910760B2 (en) * 2015-08-07 2018-03-06 Nvidia Corporation Method and apparatus for interception of synchronization objects in graphics application programming interfaces for frame debugging
US10210655B2 (en) * 2015-09-25 2019-02-19 Intel Corporation Position only shader context submission through a render command streamer
US9672135B2 (en) * 2015-11-03 2017-06-06 Red Hat, Inc. System, method and apparatus for debugging of reactive applications
US9881352B2 (en) * 2015-11-13 2018-01-30 Intel Corporation Facilitating efficient graphics commands processing for bundled states at computing devices
CN106775749B (zh) * 2016-12-29 2019-11-05 东软集团股份有限公司 图像的处理方法及装置
US10235272B2 (en) * 2017-03-06 2019-03-19 Xilinx, Inc. Debugging system and method
US10719902B2 (en) * 2017-04-17 2020-07-21 Intel Corporation Thread serialization, distributed parallel programming, and runtime extensions of parallel computing platform
US10310895B2 (en) * 2017-04-21 2019-06-04 Intel Corporation Memory-based software barriers
US10726514B2 (en) * 2017-04-28 2020-07-28 Intel Corporation Compute optimizations for low precision machine learning operations
US10241766B2 (en) 2017-06-22 2019-03-26 Microsoft Technology Licensing, Llc Application binary interface cross compilation
US10289393B2 (en) 2017-06-22 2019-05-14 Microsoft Technology Licensing, Llc GPU-executed program sequence cross-compilation
US10102015B1 (en) 2017-06-22 2018-10-16 Microsoft Technology Licensing, Llc Just in time GPU executed program cross compilation
US10657698B2 (en) * 2017-06-22 2020-05-19 Microsoft Technology Licensing, Llc Texture value patch used in GPU-executed program sequence cross-compilation
US10452516B2 (en) * 2017-07-10 2019-10-22 Microsoft Technology Licensing, Llc Replaying time-travel traces relying on processor undefined behavior
US20190042390A1 (en) * 2017-08-01 2019-02-07 Microsoft Technology Licensing, Llc Focused execution of traced code in a debugger
US10733076B2 (en) * 2018-03-02 2020-08-04 Microsoft Technology Licensing, Llc Techniques for detecting faults in rendering graphics
US10972740B2 (en) 2018-03-06 2021-04-06 Forcepoint, LLC Method for bandwidth reduction when streaming large format multi-frame image data
CN112020741A (zh) * 2018-04-27 2020-12-01 惠普发展公司，有限责任合伙企业 故障屏蔽
US10846088B2 (en) * 2018-08-21 2020-11-24 Arm Limited Control of instruction execution in a data processor
US10997771B2 (en) * 2018-08-29 2021-05-04 Intel Corporation Position-based rendering apparatus and method for multi-die/GPU graphics processing
US11134087B2 (en) 2018-08-31 2021-09-28 Forcepoint, LLC System identifying ingress of protected data to mitigate security breaches
US11200063B2 (en) * 2018-09-27 2021-12-14 Intel Corporation Graphics engine reset and recovery in a multiple graphics context execution environment
US11140190B2 (en) 2018-10-23 2021-10-05 Forcepoint, LLC Automated user module assessment
US10761908B2 (en) * 2018-10-30 2020-09-01 Stoplight, Inc. Distillation of various application interface data structures distributed over distinctive repositories to form a data source of consolidated application interface data components
US11048611B2 (en) 2018-11-29 2021-06-29 Forcepoint, LLC Web extension JavaScript execution control by service/daemon
CN109783407B (zh) * 2019-01-14 2021-01-12 武汉精立电子技术有限公司 一种基于fpga实现pc与显卡桥接的装置及方法
US11132973B2 (en) * 2019-02-01 2021-09-28 Forcepoint, LLC System for capturing images from applications rendering video to a native platform with a graphics rendering library
US10917382B2 (en) 2019-04-03 2021-02-09 Forcepoint, LLC Virtual point of presence in a country to allow for local web content
CN110162302B (zh) * 2019-04-11 2023-06-20 北京达佳互联信息技术有限公司 数据处理方法、装置、电子设备及存储介质
US10981059B2 (en) * 2019-07-03 2021-04-20 Sony Interactive Entertainment LLC Asset aware computing architecture for graphics processing
CN110399124B (zh) * 2019-07-19 2022-04-22 浪潮电子信息产业股份有限公司 一种代码生成方法、装置、设备及可读存储介质
US10996942B1 (en) 2020-01-21 2021-05-04 Dell Products L.P. System and method for graphics processing unit firmware updates
US11431743B2 (en) 2020-02-03 2022-08-30 Forcepoint, LLC Cross domain dynamic data protection intermediary message transform platform
US11422920B2 (en) * 2020-03-12 2022-08-23 Micro Focus Llc Debugging multiple instances of code using thread patterns
US11455237B2 (en) 2020-06-01 2022-09-27 Agora Lab, Inc. Highly scalable system and method for automated SDK testing
US11621980B2 (en) 2020-07-07 2023-04-04 Agora Lab, Inc. System and method for providing upstream directives based on upstream signal quality of wireless network in real-time communication
US11470531B2 (en) 2020-07-13 2022-10-11 Agora Lab, Inc. System and method for automatically switching real-time communication device to new basic service set
US11350314B2 (en) 2020-07-13 2022-05-31 Agora Lab, Inc. System and method for classifying network data packets with provided classifier identifiers
CN111831284B (zh) * 2020-07-29 2023-08-08 网易（杭州）网络有限公司 渲染调试方法、装置及设备
CN112579174B (zh) * 2020-12-05 2023-01-31 西安翔腾微电子科技有限公司 一种多周期双发射指令可发射的检测电路及方法
CN112581585B (zh) * 2020-12-24 2024-02-27 西安翔腾微电子科技有限公司 一种基于SysML视图的GPU命令处理模块的TLM装置及操作方法
US11972240B2 (en) 2021-12-03 2024-04-30 Samsung Electronics Co., Ltd. Systems and methods for automapping source code to machine code
CN114745257B (zh) * 2022-03-28 2024-01-09 杭州义益钛迪信息技术有限公司 数据帧调试方法、装置、设备及存储介质
CN115861511B (zh) * 2022-12-30 2024-02-02 格兰菲智能科技有限公司 绘制命令的处理方法、装置、系统和计算机设备

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100601606B1 (ko) 1999-05-13 2006-07-14 삼성전자주식회사 소프트웨어/하드웨어 복합 방식을 이용한 데이터 처리장치 및방법
US6891543B2 (en) 2002-05-08 2005-05-10 Intel Corporation Method and system for optimally sharing memory between a host processor and graphics processor
US7380235B1 (en) * 2003-06-27 2008-05-27 Microsoft Corporation Application program interface call replay tool
US7328429B2 (en) 2003-11-13 2008-02-05 Intel Corporation Instruction operand tracing for software debug
US7548244B2 (en) * 2005-01-12 2009-06-16 Sony Computer Entertainment Inc. Interactive debugging and monitoring of shader programs executing on a graphics processor
US20070005323A1 (en) * 2005-06-30 2007-01-04 Patzer Aaron T System and method of automating the addition of programmable breakpoint hardware to design models
US8201029B2 (en) 2008-01-31 2012-06-12 International Business Machines Corporation Method and apparatus for operating system event notification mechanism using file system interface
US9256514B2 (en) * 2009-02-19 2016-02-09 Nvidia Corporation Debugging and perfomance analysis of applications
US8581916B2 (en) 2009-06-26 2013-11-12 Intel Corporation Graphics analysis techniques
US8572573B2 (en) 2012-03-09 2013-10-29 Nvidia Corporation Methods and apparatus for interactive debugging on a non-preemptible graphics processing unit

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
IEEE 754-2008-Standard

Also Published As

Publication number Publication date
US20140146062A1 (en) 2014-05-29
TW201426301A (zh) 2014-07-01
US9292414B2 (en) 2016-03-22
CN103838669A (zh) 2014-06-04

Similar Documents

Publication Publication Date Title
DE102013224046A1 (de) System, Verfahren und Computer-Programm-Produkt zum Debuggen von Grafik-Programmen lokal unter Benutzung eines Systems mit einer einzelnen GPU
US10949944B2 (en) System and method for unified application programming interface and model
DE102018132468A1 (de) Multi-gpu-frame-rendern
TWI637346B (zh) 圖形處理系統
DE102021118444A1 (de) Einrichtung und Verfahren zum Komprimieren von Strahlverfolgungsbeschleunigungsstrukturaufbaudaten
TW201832179A (zh) 使用一類神經網路過濾影像資料
DE102020124932A1 (de) Vorrichtung und Verfahren zur Echtzeit-Grafikverarbeitung mittels lokaler und cloudbasierter Grafikverarbeitungsbetriebsmittel
DE102018113845A1 (de) Systeme und Verfahren zum Trainieren von neuronalen Netzwerken mit dünnbesetzten Daten
DE102018127647A1 (de) Systeme und verfahren zum trainieren neuronaler netzwerke auf regression ohne referenzdaten-trainingsmuster
DE102009039231A1 (de) Einzeldurchgang-Kachelung
DE102018101030A1 (de) Filterung von Bilddaten unter Verwendung eines neutralen Netzwerks
DE112010003750T5 (de) Hardware für parallele Befehlslistenerzeugung
US9305324B2 (en) System, method, and computer program product for tiled deferred shading
DE102013224160A1 (de) System, Verfahren und Computer-Programm-Produkt zum Optimieren des Managements von Thread-Stapel-Speicher
DE102018120859A1 (de) Inline-Dateninspektion zur Arbeitslastvereinfachung
DE102016122297A1 (de) Mehrfach-Durchlauf-Rendering in einer Bildschirm-Raum-Pipeline
US9269179B2 (en) System, method, and computer program product for generating primitive specific attributes
WO2020192608A1 (zh) 图形渲染方法、装置和计算机可读存储介质
DE102017109472A1 (de) Stereo-mehrfach-projektion implementiert unter verwendung einer graphikverarbeitungs-pipeline
DE102019101871A1 (de) Verfahren und Vorrichtung zum Gewinnen von Abtastpositionen von Textuieroperationen
DE102013222685A1 (de) System, Verfahren und Computer-Programm-Produkt zum Abtasten einer hierarchischen Tiefe-Karte
US9721381B2 (en) System, method, and computer program product for discarding pixel samples
DE102020124872A1 (de) Verwendung von innere-abdeckung-informationen durch eine konservative-rasterung-pipeline zum aktivieren von earlyz für eine konservative rasterung
DE102021104310A1 (de) Reservoir-basiertes räumlich-zeitliches resampling nach wichtigkeit unter verwendung einer globalen beleuchtungsdatenstruktur
DE112018003999T5 (de) Verfahren und Vorrichtung für effiziente Verarbeitung von abgeleiteten einheitlichen Werten in einem Grafikprozessor

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

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

R120 Application withdrawn or ip right abandoned