DE112011101725T5 - Sub-Puffer-Objekte - Google Patents

Sub-Puffer-Objekte Download PDF

Info

Publication number
DE112011101725T5
DE112011101725T5 DE112011101725T DE112011101725T DE112011101725T5 DE 112011101725 T5 DE112011101725 T5 DE 112011101725T5 DE 112011101725 T DE112011101725 T DE 112011101725T DE 112011101725 T DE112011101725 T DE 112011101725T DE 112011101725 T5 DE112011101725 T5 DE 112011101725T5
Authority
DE
Germany
Prior art keywords
buffer
sub
data
memory
parent
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.)
Ceased
Application number
DE112011101725T
Other languages
English (en)
Inventor
Aaftab A. Munshi
Ian R. Ollman
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.)
Apple Inc
Original Assignee
Apple Inc
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 Apple Inc filed Critical Apple Inc
Publication of DE112011101725T5 publication Critical patent/DE112011101725T5/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/001—Arbitration of resources in a display system, e.g. control of access to frame buffer by video controller and/or main processor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/167—Interprocessor communication using a common memory, e.g. mailbox
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/80—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/60—Memory management
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2360/00—Aspects of the architecture of display systems
    • G09G2360/12—Frame memory handling
    • G09G2360/127—Updating a frame memory using a transfer of data from a source area to a destination area

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Image Processing (AREA)
  • Image Generation (AREA)
  • Multi Processors (AREA)
  • Memory System (AREA)
  • Electron Beam Exposure (AREA)
  • Advance Control (AREA)

Abstract

Ein Verfahren und eine Vorrichtung für ein parallel rechnendes Programm, welches Sub-Puffer verwendet, um eine Datenverarbeitungsaufgabe parallel unter heterogenen Recheneinheiten auszuführen, werden beschrieben. Die Recheneinheiten können einen heterogenen Mix aus Zentralverarbeitungseinheiten (CPUs) und Graphikerarbeitungseinheiten (GPUs) umfassen. Ein System kreiert einen Sub-Puffer aus einem übergeordneten Puffer für jede einer Mehrzahl von heterogenen Recheneinheiten. Wenn ein Sub-Puffer nicht mit der gleichen Recheneinheit wie der übergeordnete Puffer assoziiert ist, kopiert das System Daten aus dem Sub-Puffer in den Speicher jener Recheneinheit. Das System verfolgt weiterhin Aktualisierungen der Daten und überträgt jene Aktualisierungen zurück an den Sub-Puffer.

Description

  • VERWANDTE ANMELDUNGEN
  • Die Anmelderin beansprucht den Nutzen der Priorität aus der mitanhängigen vorläufigen Anmeldung Nr. 61/346,866, eingereicht am 20. Mai 2010, welche in ihrer Gesamtheit durch Verweis aufgenommen wird.
  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich im Allgemeinen auf Datenparallelrechnen. Insbesondere bezieht sich diese Erfindung auf das Verwalten von Sub-Puffer-Objekten, welche mit einem Puffer in einer heterogenen Mehrrecheneinheits-Umgebung assoziiert sind.
  • HINTERGRUND
  • Da sich die GPUs weiterhin zu Hochleistungsparallelrechen-vorrichtungen entwickeln, werden mehr und mehr Anwendungen geschrieben, um Datenparallelberechnungen in GPUs ähnlich den Universal-Computervorrichtungen auszuführen. Heute werden diese Anwendungen gestaltet, um auf spezifischen GPUs unter Verwendung von anbieterspezifischen Schnittstellen zu laufen. Daher sind diese Anwendungen nicht in der Lage, sich Verarbeitungsressourcen von CPUs zu Nutze zu machen, selbst wenn sowohl GPUs als auch CPUs in einem Datenverarbeitungssystem verfügbar sind. Auch können Verarbeitungsressourcen nicht über GPUs unterschiedlicher Anbieter hinweg wirksam eingesetzt werden, wo solch eine Anwendung läuft.
  • Weil jedoch immer mehr CPUs mehrere Kerne umfassen, um Datenparallelberechnungen auszuführen, können immer mehr Verarbeitungsaufgaben durch entweder CPUs und/oder GPUs unterstützt werden, welche auch immer verfügbar sind. Traditionell werden GPUs und CPUs eingerichtet durch separate Programmierumgebungen, welche nicht miteinander kompatibel sind. Die meisten GPUs erfordern dedizierte Programme, welche anbieterspezifisch sind. Als Ergebnis ist es sehr schwierig für eine Anwendung, sich Verarbeitungsressourcen von sowohl GPUs als auch CPUs zu Nutze zu machen, z. B. das sich zu Nutze machen von Verarbeitungs-ressourcen von GPUs mit Datenparallelrechenfähigkeiten zusammen mit Mehrkern-CPUs.
  • Zusätzlich verwenden CPUs und GPUs separate Speicheradressräume. Der Speicherpuffer muss zugeordnet werden und in den GPU-Speicher für die GPU kopiert werden, um Daten zu verarbeiten. Wenn eine Anwendung will, dass die CPU und eine oder mehrere GPUs auf Bereichen eines Datenpuffers operieren, muss die Anwendung das Zuordnen und das Kopieren von Daten aus geeigneten Bereichen des Puffers verwalten, welcher zwischen CPU und GPU oder über GPUs gemeinsam zu nutzen ist. Daher gibt es in modernen Datenverarbeitungssystemen einen Bedarf an einem heterogenen Mix aus CPUs und GPUs, welche einen Puffer gemeinsam nutzen.
  • ZUSAMMENFASSUNG DER BESCHREIBUNG
  • Ein Verfahren und eine Vorrichtung für ein Parallelrechenprogramm unter Verwendung von Sub-Puffern zum parallelen Ausführen einer Datenverarbeitungsaufgabe unter heterogenen Recheneinheiten werden beschrieben. Die Recheneinheiten können einen heterogenen Mix aus Zentralverarbeitungseinheiten (central processing units, CPUs) und Graphikverarbeitungseinheiten (graphic processing units, GPUs) umfassen. Ein System kreiert einen Sub-Puffer aus einem übergeordneten Puffer für jede aus einer Mehrzahl von heterogenen Recheneinheiten. Wenn ein Sub-Puffer nicht mit der gleichen Recheneinheit wie der übergeordnete Puffer assoziiert ist, kopiert das System Daten aus einem Sub-Puffer in einen Speicher jener Recheneinheit. Das System verfolgt weiterhin Aktualisierungen der Daten und überträgt jene Aktualisierungen zurück an den Sub-Puffer.
  • Andere Merkmale der vorliegenden Erfindung werden offensichtlich werden aus den begleitenden Zeichnungen und aus der detaillierten Beschreibung, welche folgt.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegende Erfindung wird beispielhaft und nicht beschränkend in den Figuren der begleitenden Zeichnungen gezeigt, in welchen gleiche Verweise ähnliche Elemente anzeigen und in welchen:
  • 1 ein Blockdiagramm ist, welches eine Ausführungsform eines Systems zeigt, um Computervorrichtungen einschließlich CPUs und/oder GPUs einzurichten, um Datenparallelrechnen für Anwendungen auszuführen;
  • 2 ein Blockdiagramm ist, welches ein Beispiel einer Computervorrichtung mit mehreren Rechenprozessoren zeigt, welche parallel operieren, um mehrere Threads gleichzeitig auszuführen;
  • 3 ein Blockdiagramm ist, welches eine Ausführungsform einer Mehrzahl von physischen Computervorrichtungen zeigt, welche als eine logische Computervorrichtung eingerichtet sind, unter Verwendung eines Computervorrichtungsbezeichners;
  • 4 ein Blockdiagramm ist, welches eine Ausführungsform eines Puffers zeigt, der in mehrere Sub-Puffer unterteilt ist;
  • 5 ein Blockdiagramm ist, welches eine Ausführungsform von mehreren Sub-Puffern in einem eindimensionalen Puffer zeigt;
  • 6 ein Blockdiagramm ist, welches eine Ausführungsform eines zweidimensionalen Bildes zeigt, welches in mehrere Sub-Puffer unterteilt ist;
  • 7 ein Blockdiagramm ist, welches eine Ausführungsform eines dreidimensionalen Bildes zeigt, welches in mehrere Sub-Puffer unterteilt ist;
  • 8 ein Flussdiagramm ist, welches eine Ausführungsform eines Prozesses zeigt zum Einrichten einer Mehrzahl physischer Computer-vorrichtungen mit einem Computervorrichtungsbezeichner durch Abgleichen eines Fähigkeitserfordernisses, welches von einer Anwendung empfangen wird;
  • 9 ein Flussdiagramm ist, welches eine Ausführungsform eines Prozesses zeigt, um eine rechenausführbare Datei in einer logischen Computervorrichtung auszuführen;
  • 10 ein Flussdiagramm ist, welches eine Ausführungsform eines Laufzeitprozesses zeigt, zum Kreieren und Verwenden von Sub-Puffern mit mehreren Recheneinheiten;
  • 11 ein Flussdiagramm ist, welches eine Ausführungsform eines Prozesses zeigt, um Rückrufe, welche mit Ereignissen assoziiert sind, welche interne und externe Abhängigkeiten aufweisen auszuführen;
  • 12 ein Blockdiagramm ist, welches eine Ausführungsform einer Kette von Ereignissen mit internen und externen Abhängigkeiten zeigt;
  • 13 ein Beispiel-Quellcode ist, welcher ein Beispiel einer Rechen-Kernel-Quelle für eine Rechen-kernel-ausführbare Datei zeigt, die in einer Mehrzahl von physischen Computervorrichtungen auszuführen ist;
  • 14A bis 14C einen Beispiel-Quellcode umfassen, welcher ein Beispiel zum Einrichten einer logischen Computervorrichtung zeigt zum Ausführen einer aus einer Mehrzahl von ausführbaren Dateien in einer Mehrzahl von physischen Computervorrichtungen durch das Aufrufen von APIs;
  • 15 ein Beispiel eines typischen Computersystems mit einer Mehrzahl von CPUs und GPUs (Graphikverarbeitungseinheit) zeigt, welche in Verbindung mit den hierin beschriebenen Ausführungsformen verwendet werden können.
  • DETAILLIERTE BESCHREIBUNG
  • Ein Verfahren und eine Vorrichtung für Datenparallelrechnen auf mehreren Prozessoren unter Verwendung von Sub-Puffern, welche aus einem übergeordneten Puffer kreiert werden, werden hierin beschrieben. In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um eine gründliche Erklärung der Ausführungsformen der vorliegenden Erfindung bereitzustellen. Jedoch wird es einem Fachmann klar sein, dass Ausführungsformen der vorliegenden Erfindung ohne diese spezifischen Details ausgeführt werden können. In anderen Fällen sind wohlbekannte Komponenten, Strukturen und Techniken nicht im Detail gezeigt worden, um das Verständnis dieser Beschreibung nicht unklar zu machen.
  • Verweis in der Beschreibung auf „eine Ausführungsform” bedeutet, dass ein spezielles Merkmal, eine spezielle Struktur oder Charakteristik, welche in Verbindung mit der Ausführungsform beschrieben wird, zumindest in einer Ausführungsform der Erfindung umfasst sein kann. Das Auftreten des Ausdrucks „in einer Ausführungsform” an verschiedenen Stellen in der Beschreibung bezieht sich nicht notwendigerweise immer auf die gleiche Ausführungsform.
  • Die Prozesse, welche in den Figuren, welche folgen, gezeigt werden, werden durch Verarbeitungslogik ausgeführt, welche Hardware (z. B. Schaltungen, dedizierte Logik usw.), Software (wie z. B. solche, die auf einem Universal-Computersystem oder auf einer dedizierten Maschine läuft), oder eine Kombination von beidem aufweist. Obwohl die Prozesse unten mittels einiger sequentieller Operationen beschrieben werden, sollte beachtet werden, dass einige der Operationen, welche beschrieben werden, in unterschiedlicher Reihenfolge ausgeführt werden können. Außerdem können einige Operationen parallel statt sequentiell ausgeführt werden.
  • Eine Graphikverarbeitungseinheit (GPU) kann ein dedizierter Graphikprozessor sein, welcher hocheffiziente graphische Operationen implementiert, wie z. B. 2D-, 3D-graphische Operationen und/oder Digital-Video-bezogene Funktionen. Eine GPU kann spezielle (programmierbare) Hardware umfassen, um graphische Operationen auszuführen, z. B. Blitter-Operationen, Textur-Abbilden, Polygon-Rendering, Pixel-Shading und Vertex-Shading. GPUs holen bekanntlich Daten aus einem Rahmenpuffer und verschmelzen Bildpunkte zusammen, um ein Bild zurück in den Rahmenpuffer zur Anzeige zu rendern. GPUs können auch den Rahmenpuffer steuern und es dem Rahmenpuffer erlauben, zum Aktualisieren einer Anzeige verwendet zu werden, z. B. einer CRT- oder einer LCD-Anzeige. Entweder eine CRT- oder eine LCD-Anzeige ist eine Anzeige mit kurzer Nachleuchtdauer, welche eine Aktualisierung bei einer Rate von zumindest 20 Hz erfordert (z. B. alle 1/30 einer Sekunde wird die Anzeige mit Daten aus einem Rahmenpuffer aktualisiert). Normalerweise können GPUs Graphikverarbeitungsaufgaben von CPUs nehmen, gekoppelt mit den GPUs, um rastergraphische Bilder auszugeben, um Vorrichtungen über Anzeigesteuereinheiten anzuzeigen. Verweise auf „GPU” in der Beschreibung können ein Graphikprozessor oder ein programmierbarer Graphikprozessor sein, wie beschrieben in „Method and Apparatus for Multithreaded Processing of Data In a Programmable Graphics Processor”, Lindhold et al., US Patent Nr. 7015913 , und „Method for Deinterlacing Interlaced Video by A Graphics Processor”, Swan et al, US Patent Nr. 6970206 , welche hiermit durch Verweis aufgenommen werden.
  • In einer Ausführungsform kann eine Mehrzahl von unterschiedlichen Typen von Prozessoren, wie beispielsweise CPUs oder GPUs, Daten-Parallelverarbeitungsaufgaben für eine oder mehrere Anwendungen gleichzeitig ausführen, um die Nutzungseffizienz von verfügbaren Verarbeitungsressourcen in einem Datenverarbeitungs-system zu erhöhen. Verarbeitungsressourcen eines Datenverarbeitungssystems können basieren auf einer Mehrzahl von physischen Computervorrichtungen wie beispielsweise CPUs oder GPUs. Eine physische Computervorrichtung kann eine oder mehrere Recheneinheiten umfassen. In einer Ausführungsform können Daten-Parallelverarbeitungsaufgaben (oder Datenparallelaufgaben) an eine Mehrzahl von Typen von Prozessoren delegiert werden, wie beispielsweise CPUs oder GPUs, welche fähig sind, die Aufgaben auszuführen. Eine Datenparallelaufgabe kann bestimmte spezifische Verarbeitungsfähigkeiten von einem Prozessor erfordern. Verarbeitungsfähigkeiten können z. B. dedizierte Textur-Hardware-Unterstützung, doppelte Genauigkeits-Fließkommaarithmetik, dedizierter lokaler Speicher, Stream-Daten-Cache oder Synchronisierungsprimitive sein. Separate Typen von Prozessoren können unterschiedliche, jedoch überlappende Gruppen von Verarbeitungsfähigkeiten bereitstellen. Zum Beispiel können sowohl eine CPU als auch eine GPU fähig sein, Fließkommaberechnungen doppelter Genauigkeit auszuführen. In einer Ausführungsform ist eine Anwendung fähig, sich entweder eine CPU oder eine GPU zu Nutze zu machen, welche auch immer verfügbar ist, um eine Daten-Parallelverarbeitungsaufgabe auszuführen.
  • In einer anderen Ausführungsform kann das System einen übergeordneten Puffer zuordnen und weiterhin diesen übergeordneten Puffer in mehrere Sub-Puffer unterteilen. Wenn die Recheneinheit für den Sub-Puffer die gleiche Recheneinheit wie diejenige ist, welche mit dem übergeordneten Puffer assoziiert ist, greift jene Recheneinheit unter Verwendung von Zeigern auf die Sub-Pufferdaten zu. Wenn die Recheneinheit für den Sub-Puffer zu der Recheneinheit für den übergeordneten Puffer unterschiedlich ist, kopiert das System die Daten aus dem Sub-Puffer in den Speicher, welcher für die Recheneinheit für den Sub-Puffer lokal ist. Des Weiteren verfolgt das System Aktualisierungen der kopierten Daten und überträgt die aktualisierten Daten zurück an den Sub-Puffer.
  • 1 ist ein Blockdiagramm, welches eine Ausführungsform eines Systems 100 zeigt, um Computervorrichtungen einzurichten, welche CPUs und/oder GPUs umfassen, um Datenparallelrechnungen für Anwendungen auszuführen. Das System 100 kann eine Parallelrechenarchitektur implementieren. In einer Ausführungsform kann das System 100 ein Graphiksystem sein, welches einen oder mehrere Host-Prozessoren umfasst, welche mit einem oder mehreren zentralen Prozessoren 117 und einem oder mehreren anderen Prozessoren, wie z. B. Medien-Prozessoren 115, über einen Datenbus 113 gekoppelt sind. Die Mehrzahl von Host-Prozessoren kann in Hosting-Systemen 101 vernetzt werden. Die Mehrzahl von zentralen Prozessoren kann Mehrkern-CPUs von verschiedenen Anbietern umfassen. Ein Rechenprozessor oder eine Recheneinheit wie beispielsweise eine CPU oder eine GPU kann einer Gruppe von Fähigkeiten assoziiert sein. Zum Beispiel kann ein Medien-Prozessor eine GPU mit dedizierter Textur-Rendering-Hardware sein. Ein anderer Medien-Prozessor kann eine GPU sein, welcher sowohl dedizierte Textur-Rendering-Hardware als auch Fließkommaarithmetik doppelter Genauigkeit unterstützt. Mehrere GPUs können zusammen verbunden werden für Scalable Link Interface (SLI)- oder CrossFire-Konfigurationen.
  • In einer Ausführungsform können die Hosting-Systeme 101 einen Softwarestapel unterstützen. Der Softwarestapel kann Softwarestapelkomponenten wie beispielsweise Anwendungen 103, eine Rechenplattformschicht 141, z. B. eine OpenCL(Open Computing Language)-Plattform, eine Rechenlaufzeitschicht 109, einen Rechen-Compiler 107 und Rechenanwendungsbibliotheken 105 umfassen. Eine Anwendung 103 kann eine Schnittstelle mit anderen Stapelkomponenten über API-Aufrufe bilden. Ein oder mehrere Threads können gleichzeitig für die Anwendung 103 in den Hosting-Systemen 101 laufen. Die Rechenplattformschicht 141 kann eine Datenstruktur oder eine Computervorrichtungsdatenstruktur unterhalten, wobei sie Verarbeitungsfähigkeiten für jede angefügte physische Computervorrichtung speichert. In einer Ausführungsform kann eine Anwendung Informationen über verfügbare Verarbeitungsressourcen der Hosting-Systeme 101 über die Rechenplattformschicht 141 abrufen. Eine Anwendung kann Fähigkeitserfordernisse auswählen und spezifizieren zum Ausführen einer Verarbeitungsaufgabe über die Rechenplattformschicht 141. Dementsprechend kann die Rechenplattformschicht 141 eine Konfiguration für physische Computervorrichtungen bestimmen, um Verarbeitungsressourcen von den angefügten CPUs 117 und/oder GPUs 115 für die Verarbeitungsaufgabe zuzuordnen und zu initialisieren. In einer Ausführungsform kann die Rechenplattformschicht 141 ein oder mehrere logische Computervorrichtungen für die Anwendung erzeugen, welche einer oder mehreren aktueller physischer Computervorrichtungen, welche konfiguriert sind, entsprechen.
  • Die Rechenlaufzeitschicht 109 kann die Ausführung einer Verarbeitungsaufgabe gemäß den konfigurierten Verarbeitungsressourcen für eine Anwendung 103 z. B. basierend auf einer oder mehreren logischen Computervorrichtungen verwalten. In einer Ausführungsform kann das Ausführen einer Verarbeitungsaufgabe das Kreieren eines Computerprogrammobjekts umfassen, welches die Verarbeitungsaufgabe repräsentiert und das Zuordnen von Speicherressourcen umfassen, wie beispielsweise zum Halten von ausführbaren Dateien, Eingabe/Ausgabe-Daten usw. Eine ausführbare Datei, welche für ein Computerprogrammobjekt geladen wurde, kann eine Rechenprogrammausführbare Datei sein. Eine Rechenprogramm-ausführbare Datei kann in einem Computerprogrammobjekt umfasst sein, welches in einem Rechenprozessor oder einer Recheneinheit auszuführen ist, wie beispielsweise einer CPU oder einer GPU. Die Rechenlaufzeitschicht 109 kann mit den zugeordneten physischen Vorrichtungen interagieren, um die derzeitige Ausführung der Verarbeitungsaufgabe durchzuführen. In einer Ausführungsform kann die Rechenlaufzeitschicht 109 das Ausführen mehrerer Verarbeitungsaufgaben von unterschiedlichen Anwendungen koordinieren, gemäß den Laufzeitzuständen jedes Prozessors, wie beispielsweise einer CPU oder einer GPU, welche für die Verarbeitungsaufgaben eingerichtet sind. Die Rechenlaufzeitschicht 109 kann, basierend auf den Laufzeitzuständen, ein oder mehrere Prozessoren aus den physischen Computervorrichtungen, welche zum Ausführen der Verarbeitungsaufgaben eingerichtet sind, auswählen. Das Ausführen einer Verarbeitungsaufgabe kann das gleichzeitige Ausführen mehrerer Threads einer oder mehrerer ausführbarer Dateien in einer Mehrzahl von physischen Computervorrichtungen umfassen. In einer Ausführungsform kann die Rechenlaufzeitschicht 109 den Zustand jeder ausgeführten Verarbeitungsaufgabe durch Überwachen des Laufzeitausführungszustands jedes Prozessors verfolgen. Die Laufzeitschicht kann ein oder mehrere ausführbare Dateien als Rechenprogramm-ausführbare Dateien, welche einer Verarbeitungsaufgabe aus der Anwendung 103 entsprechen, laden. In einer Ausführungsform lädt die Rechenlaufzeitschicht 109 automatisch zusätzliche ausführbare Dateien, welche erforderlich sind zum Ausführen einer Verarbeitungsaufgabe, aus der Rechenanwendungsbibliothek 105. Die Rechenlaufzeitschicht 109 kann sowohl eine ausführbare Datei als auch ihr entsprechendes Quellprogramm für ein Rechenprogrammobjekt aus der Anwendung 103 oder der Rechenanwendungsbibliothek 105 laden. Ein Quellprogramm für ein Rechenprogrammobjekt kann eine Rechenprogrammquelle sein. Eine Mehrzahl von ausführbaren Dateien basierend auf einer einzelnen Rechenprogrammquelle kann gemäß einer logischen Computervorrichtung, welche eingerichtet ist zum Umfassen von mehreren Typen und/oder unterschiedlichen Versionen von physischen Computervorrichtungen, geladen werden. In einer Ausführungsform kann die Rechenlaufzeitschicht 109 den Rechen-Compiler 107 aktivieren, um ein geladenes Quellprogramm in eine ausführbare Datei online zu kompilieren, welche für einen Zielprozessor, z. B. eine CPU oder eine GPU optimiert ist, welcher eingerichtet ist zum Ausführen der ausführbaren Datei.
  • Eine online kompilierte ausführbare Datei kann für einen zukünftigen Aufruf zusätzlich zu existierenden ausführbaren Dateien gemäß einem entsprechenden Quellprogramm gespeichert werden. Zusätzlich können die ausführbaren Dateien offline kompiliert und in die Rechenlaufzeit 109 unter Verwendung von API-Aufrufen geladen werden. Die Rechenanwendungsbibliothek 105 und/oder die Anwendung 103 können eine assoziierte ausführbare Datei in Antwort auf Bibliotheks-API-Anfragen von einer Anwendung laden. Kürzlich kompilierte ausführbare Dateien können dynamisch für die Rechenanwendungsbibliothek 105 oder für die Anwendung 103 aktualisiert werden. In einer Ausführungsform kann die Rechenlaufzeit 109 eine existierende Rechenprogramm-ausführbare Datei in einer Anwendung durch eine neue ausführbare Datei ersetzen, welche durch den Rechen-Compiler 107 für eine kürzlich aktualisierte Version der Computervorrichtung online kompiliert wird. Die Rechenlaufzeit 109 kann eine neue online kompilierte ausführbare Datei einfügen, um die Rechenanwendungsbibliothek 105 zu aktualisieren. In einer Ausführungsform kann die Rechenlaufzeit 109 den Rechen-Compiler 107 beim Laden einer ausführbaren Datei für eine Verarbeitungsaufgabe aufrufen. In einer anderen Ausführungsform kann der Rechen-Compiler 107 offline aufgerufen werden, um ausführbare Dateien für die Rechenanwendungsbibliothek 105 zu bilden. Der Rechen-Compiler 107 kann ein Rechen-Kernel-Programm kompilieren und verbinden, um eine Rechenprogramm-ausführbare Datei zu erzeugen. In einer Ausführungsform kann die Rechenanwendungsbibliothek 105 eine Mehrzahl von Funktionen zum Unterstützen z. B. von Entwicklungstoolkits und/oder Bildverarbeitung umfassen. Jede Bibliotheksfunktion kann einer Rechenprogrammquelle und ein oder mehreren Rechenprogramm-ausführbaren Dateien entsprechen, welche in der Rechenanwendungsbibliothek 105 für eine Mehrzahl von physischen Computervorrichtungen gespeichert sind.
  • 2 ist ein Blockdiagramm, welches ein Beispiel einer Computervorrichtung mit mehreren Rechenprozessoren (z. B. Recheneinheiten) zeigt, welche parallel operieren zum gleichzeitigen Ausführen von mehreren Threads. Jeder Rechenprozessor kann eine Mehrzahl von Threads parallel (oder gleichzeitig) ausführen. Threads, welche in einem Rechenprozessor oder in einer Recheneinheit parallel ausgeführt werden können, können als eine Thread-Gruppe bezeichnet werden. Eine Computervorrichtung könnte mehrere Thread-Gruppen aufweisen, welche parallel ausgeführt werden können. Zum Beispiel werden M Threads gezeigt, um als eine Thread-Gruppe in der Computervorrichtung 205 ausgeführt zu werden. Mehrere Thread-Gruppen, z. B. Thread 1 des Rechenprozessors_1 205 und Thread N des Rechenprozessors_L 203 können parallel über separate Rechenprozessoren auf einer Computervorrichtung oder über mehrere Computervorrichtungen ausgeführt werden. Eine Mehrzahl von Thread-Gruppen über mehrere Computer-Rechenprozessoren kann eine Rechenprogramm-ausführbare Datei parallel ausführen. Mehr als ein Rechenprozessor kann basiert sein auf einem einzelnen Chip, wie beispielsweise einer ASIC(Applications Specific Integrated Circuit)-Vorrichtung. In einer Ausführungsform können mehrere Threads aus einer Anwendung gleichzeitig in mehr als einem Rechenprozessor über mehrere Chips hinweg ausgeführt werden.
  • Eine Computervorrichtung kann einen oder mehrere Computerrechenprozessoren oder Recheneinheiten umfassen, wie beispielsweise Prozessor_1 205 und Prozessor_L 203. Ein lokaler Speicher kann mit einem Rechenprozessor gekoppelt werden. Der lokale Speicher, welcher unter Threads in einer einzelnen Thread-Gruppe, welche in einem Rechenprozessor läuft, gemeinsam genutzt wird, kann durch den lokalen Speicher, welcher mit dem Rechenprozessor gekoppelt ist, unterstützt werden. Mehrere Threads aus unterschiedlichen Thread-Gruppen wie beispielsweise Thread 1 213 und Thread N 209, können ein Rechenspeicherobjekt gemeinsam nutzen, wie beispielsweise einen Stream, welcher in einem Computervorrichtungsspeicher 217 gespeichert wird, welcher mit der Computervorrichtung 201 gekoppelt ist. Ein Computervorrichtungsspeicher 217 kann einen globalen Speicher und einen konstanten Speicher umfassen. Ein globaler Speicher kann verwendet werden zum Zuordnen von Rechenspeicherobjekten, wie beispielsweise Streams. Ein Rechenspeicherobjekt kann eine Sammlung von Datenelementen umfassen, auf welchen durch eine Rechenprogramm-ausführbare Datei operiert werden kann. Ein Rechenspeicherobjekt kann ein Bild, eine Textur, einen Rahmen-Puffer, ein Feld eines skalaren Datentyps, ein Feld einer nutzerdefinierten Struktur, Puffer, Sub-Puffer oder eine Variable usw. repräsentieren. Ein konstanter Speicher kann Nur-Lese-Speicher sein, welcher konstante Variablen, welche häufig durch eine Rechenprogramm-ausführbare Datei verwendet werden, speichert.
  • In einer Ausführungsform kann ein lokaler Speicher für einen Rechenprozessor oder eine Recheneinheit verwendet werden zum Zuordnen von Variablen, welche durch alle Threads in einer Thread-Gruppe oder eine Thread-Gruppe gemeinsam genutzt werden. Ein lokaler Speicher kann implementiert werden als eine dedizierte lokale Speicherung, wie beispielsweise lokal gemeinsam genutzter Speicher 219 für Prozessor_1 und lokaler gemeinsam genutzter Speicher 211 für Prozessor_L. In einer anderen Ausführungsform kann ein lokaler Speicher für einen Rechenprozessor implementiert werden als ein Lese-Schreib-Cache für einen Computervorrichtungsspeicher für ein oder mehrere Rechenprozessoren einer Computervorrichtung, wie beispielsweise Daten-Cache 215 für Rechenprozessoren 205, 203 in der Computervorrichtung 201. Eine dedizierte lokale Speicherung könnte nicht durch Threads über unterschiedliche Thread-Gruppen hinweg gemeinsam genutzt werden. Wenn der lokale Speicher eines Rechenprozessors wie beispielsweise Prozessor_1 205 als ein Lese-Schreib-Cache implementiert wird, z. B. Daten-Cache 215, kann eine Variable, welche als in dem lokalen Speicher deklariert wird, aus dem Computervorrichtungsspeicher 217 zugeordnet werden und gecached werden in dem Lese-Schreib-Cache, z. B. Daten-Cache 215, welcher den lokalen Speicher implementiert. Threads innerhalb einer Thread-Gruppe können lokale Variablen gemeinsam nutzen, welche in dem Computervorrichtungsspeicher 217 zugeordnet sind, wenn z. B. weder Lese-Schreib-Cache noch eine dedizierte lokale Speicherung für die entsprechende Computervorrichtung verfügbar sind. In einer Ausführungsform wird jeder Thread mit einem privaten Speicher assoziiert, um Threads privater Variablen zu speichern, welche durch Funktionen, welche in dem Thread aufgerufen werden, verwendet werden. Zum Beispiel kann der private Speicher 1 211 nicht durch Threads anderer gesehen werden, außer Thread 1 213.
  • Des Weiteren, in einer Ausführungsform, umfasst die Computervorrichtung 217 einen Puffer 223, welcher verwendet wird zum Speichern von Daten, welche durch den Prozessor_1 205–Prozessor_L 203 verwendet werden. Der Puffer 223 kann ein eindimensionaler Puffer, ein zweidimensionales Bild, ein dreidimensionales Bild oder ein anderer Typ von Puffer, wie in der Technik bekannt, sein. In einer Ausführungsform speichert die Computervorrichtung 201 Daten, auf welchen durch die Prozessoren (Prozessor_1 205–Prozessor_L 203) im Puffer 223 operiert wird. Zum Beispiel und in einer Ausführungsform, kann der Puffer ein Feld von Daten, ein zweidimensionales Bild, ein dreidimensionales Bild usw. und/oder andere Daten, wie in der Technik bekannt, speichern. In einer Ausführungsform können Daten zwischen dem Puffer 223 und einem anderen Speicher in dem System 201 (privater Speicher 211, 207, lokaler gemeinsam genutzter Speicher 219, 221, Daten-Cache 215 usw.) übertragen werden unter Verwendung irgendeines Verfahrens, welches in der Technik bekannt ist, zum Inter-Speicher-Daten-Transfer (direkter PCIe-Transfer, asynchroner direkter Speicherzugriff usw.).
  • 3 ist ein Blockdiagramm, welches eine Ausführungsform einer Mehrzahl von physischen Computervorrichtungen zeigt, welche eingerichtet sind als eine logische Computervorrichtung unter Verwendung eines Computervorrichtungsbezeichners. In einer Ausführungsform können eine Anwendung 303 und eine Plattformschicht 305 in einer Host-CPU 301 laufen. Die Anwendung 303 kann eine der Anwendungen 103 der 1 sein. Die Hosting-Systeme 101 können die Host-CPU 301 umfassen. Jede der physischen Computervorrichtungen Physical_Compute_Device-1 305 bis Physical_Compute_Device-N 311 kann eine der CPUs 117 oder GPUs 115 der 14 sein. In einer Ausführungsform kann die Rechenplattformschicht 141 einen Computervorrichtungsbezeichner 307 erzeugen in Antwort auf API-Anfragen von der Anwendung 303 zum Einrichten von Daten-Parallelverarbeitungsressourcen gemäß einer Liste von Fähigkeitserfordernissen, welche in den API-Anfragen umfasst ist. Der Computervorrichtungsbezeichner 307 kann sich auf eine Auswahl von aktuellen physischen Computervorrichtungen Physical_Compute_Device-1 305 bis Physical_Compute_Device-N 311 gemäß der Konfiguration durch die Rechenplattformschicht 141 beziehen. In einer Ausführungsform kann eine logische Computervorrichtung 309 die Gruppe der ausgewählten aktuellen physischen Computervorrichtungen, getrennt von der Host-CPU 301 repräsentieren.
  • 4 ist ein Blockdiagramm, welches eine Ausführungsform eines Puffers, welcher in mehrere Sub-Puffer unterteilt ist, zeigt. In einer Ausführungsform ist ein Puffer 400 der Puffer 223 wie in 2 oben gezeigt. In 4 wird einem Puffer 408 Speicher zugeordnet, welcher verwendet wird zum Speichern von Daten, welche verwendet werden durch die Recheneinheiten 402A–D. Der Puffer 408 kann ein eindimensionales Feld, zweidimensionales Bild, dreidimensionales Bild oder ein anderer Typ von Puffer, wie in der Technik bekannt, sein. Der Puffer 408 ist weiterhin unterteilt in mehrere Sub-Puffer 410A–D. In einer Ausführungsform wird jeder Sub-Puffer 410A–D durch einen Zeiger 412A–D in den Puffer referenziert. Zum Beispiel und in einer Ausführungsform wird der Sub-Puffer 410A durch einen Zeiger 412A referenziert, Sub-Puffer 410B durch den Zeiger 412B referenziert, Sub-Puffer 410C durch den Zeiger 412C referenziert und Sub-Puffer 410D durch den Zeiger 412D referenziert. In einer Ausführungsform zeigen diese Zeiger 412A–D den Start jedes Puffers an. In dieser Ausführungsform, um auf die Daten in dem Sub-Puffer 410A–D zuzugreifen, würden die Recheneinheiten 402A–D die entsprechenden Zeiger 412A–D und einen Offset des gewünschten Bereichs des Sub-Puffers 410–D bereitstellen.
  • In einer Ausführungsform wird jede Recheneinheit 402A–D mit einem der Sub-Puffer 410A–D des Puffers 408 assoziiert. In einer Ausführungsform verwendet jede dieser Recheneinheiten 402A–D die Daten für die Rechenaufgabe, welche jeder Recheneinheit zugewiesen wird. Jede der Recheneinheiten kann Daten lesen und/oder Daten auf die entsprechenden Sub-Puffer 410A–D schreiben. Zum Beispiel und in einer Ausführungsform, verwendet die Recheneinheit 402A Sub-Puffer 410A, Recheneinheit 402B verwendet Sub-Puffer 410B, Recheneinheit 402C verwendet Sub-Puffer 410C und Recheneinheit 402D verwendet Sub-Puffer 410D. In dieser Ausführungsform, um auf die Daten in den Sub-Puffern 410A–D zuzugreifen, würden die Recheneinheiten 402A–D die entsprechenden Zeiger 412A–D und einen Offset dem gewünschten Bereich des Sub-Puffers 410–D bereitstellen. Die Offsets können ein Feldindex, eine zweidimensionale Referenz, eine dreidimensionale Referenz und so weiter sein. Die Puffer-408-Struktur wird weiter in 5–7 unten beschrieben.
  • In einer Ausführungsform wird jeder Sub-Puffer kreiert durch einen Funktionsaufruf und Bereitstellen eines Pufferzeigers und Sub-Puffergrößenwerts. Das Kreieren eines Sub-Puffers wird weiter unten in 10 beschrieben.
  • In einer Ausführungsform überträgt eine Recheneinheit 402A–D Daten von dem entsprechenden Sub-Puffer 410A–D zu dem privaten Speicher 404A–D jener Recheneinheit 402A–D. In einer Ausführungsform ist der private Speicher 404A-D Speicher, welcher lokal für die Recheneinheit ist (z. B. privater Speicher 1 – M 211, privater Speicher 1 – N 207, lokaler gemeinsam genutzter Speicher 219 und 221 und/oder Datencache 215, wie in 2 gezeigt). In einer Ausführungsform überträgt die Recheneinheit 402A–D die Daten über einen Bus, welcher die Recheneinheiten 402A–D und den Speicher, welcher den Puffer 408 beinhaltet, koppelt. Zum Beispiel und in einer Ausführungsform ist der koppelnde Bus ein peripherer Komponentenschnittstellentypbus (PCI, PCI-Express (PCIe), usw.) und der Übertragungsmechanismus ist ein PCI-Direkter-Speicher-Transfer (PCI Direct Memory Transfer).
  • 5 ist ein Blockdiagramm, welches eine Ausführungsform von mehreren Sub-Puffern 502A–D in einem eindimensionalen Puffer 500 zeigt. In 5, während Puffer 500 mit vier Sub-Puffern 502A–D gezeigt wird, in alternativen Ausführungsformen kann der Puffer 500 mehr oder weniger Sub-Puffer und/oder Sub-Puffer von verschiedenen Größen aufweisen. In einer Ausführungsform ist der Puffer 500 ein eindimensionales Feld von einem Datentyp (Ints, Floats, Strings, nutzerdefinierte Structs, nutzerdefinierte Objekte, und so weiter). Um Daten zu einem der Sub-Puffer 502A–D zu referenzieren, kann ein Offset von einem Startzeiger 504A–D des Sub-Puffers 502A–D verwendet werden. Zum Beispiel und in einer Ausführungsform umfasst der Puffer 500 zwei Felder von jeweils einer Milliarde Fließkommazahlen. In diesem Beispiel werden die Recheneinheiten die Inhalte der Felder zusammenaddieren und jeder Sub-Puffer 502A–D beinhaltet Teile der zwei Felder (zum Beispiel jeder Sub-Puffer 502A–D hat die Hälfte von einer Milliarde Fließkommazahlen für jedes der zwei Felder, eine Milliarde Fließkommazahlen insgesamt). Die Recheneinheiten in diesem Beispiel übertragen die Daten von dem Sub-Puffer, welcher der Recheneinheit entspricht, addieren die Floats und Speichern den resultierenden Wert in den Sub-Puffer.
  • 6 ist ein Blockdiagramm, welches eine Ausführungsform eines zweidimensionalen Bildpuffers 600 zeigt, welcher in mehrere Sub-Puffer 602A–D unterteilt ist. In 6, während Puffer 600 mit vier Sub-Puffern 602A–D gezeigt ist, kann der Puffer 600 in alternativen Ausführungsformen mehr oder weniger Sub-Puffer und/oder Sub-Puffer von verschiedenen Größen aufweisen. In 6 ist der zweidimensionale Bildpuffer 600 ein zweidimensionaler Puffer, welcher Daten beinhaltet, welche durch einen X-Offset und einen V-Offset referenziert sind. Dieser Puffer kann Daten von verschiedenen Typen speichern (Ints, Floats, Strings, nutzerdefinierte Structs, nutzerdefinierte Objekte, und so weiter). Zum Beispiel und in einer Ausführungsform, kann der Puffer 600 ein zweidimensionales Bild von Bildpunkten in der X- und V-Richtung speichern. Zum Beispiel, in einer Ausführungsform, speichert der Puffer 600 ein zweidimensionales Bild, um ein Farbhistogramm des gespeicherten Bilds zu berechnen. In diesem Beispiel wird das Bild unterteilt in vier Sub-Puffer 602A–D und jeder Sub-Puffer 602A–D wird verwendet durch eine Recheneinheit, um den Teil des Bildes, welchen die Recheneinheit verarbeitet, zu halten. Des Weiteren kopiert jede Recheneinheit 602A–D relevante Abschnitte des Bildes aus dem entsprechenden Sub-Puffer in den privaten Speicher der Recheneinheit. Die Recheneinheit berechnet die Histogramminformationen unter Verwendung jener Bilddaten und gibt diese Histogramminformationen zurück.
  • 7 ist ein Blockdiagramm, welches eine Ausführungsform eines dreidimensionalen Bildpuffers 700 zeigt, welcher in mehrere Sub-Puffern 702A-D unterteilt ist. In 7, während der Puffer 700 mit vier Sub-Puffern 702A–D gezeigt ist, kann der Puffer 700 in alternativen Ausführungsformen mehr oder weniger Sub-Puffer und/oder Sub-Puffer von verschiedenen Größen aufweisen. In 7, ist der dreidimensionale Bildpuffer 700 ein dreidimensionaler Puffer, welcher Daten beinhaltet, welche durch einen X-, Y- und einen Z-Offset oder ein anderes geeignetes System zum Referenzieren eines Orts in einem dreidimensionales Raum, referenziert. Wie mit den Puffern 500 und 600, kann dieser Puffer 700 Daten von verschiedenen Typen speichern (Ints, Floats, Strings, nutzerdefinierte Structs, nutzerdefinierte Objekte, und so weiter). Zum Beispiel und in einer Ausführungsform, kann der Puffer 700 ein dreidimensionales Bild von Bildpunkten in der X-, Y- und Z-Richtung speichern.
  • 8 ist ein Flussdiagramm, welches eine Ausführungsform eines Prozesses 800 zeigt, um eine Mehrzahl von physischen Computervorrichtungen mit einem Computervorrichtungsbezeichner einzurichten, durch Abgleichen eines Fähigkeitserfordernisses, welches von einer Anwendung empfangen wird. Der beispielhafte Prozess 800 kann ausgeführt werden durch eine Verarbeitungslogik, welche Hardware (Schaltungen, dedizierte Logik und so weiter), Software (wie beispielsweise auf der dedizierten Maschine laufend) oder eine Kombination von beiden aufweist. Zum Beispiel kann der Prozess 800 ausgeführt werden in Übereinstimmung mit dem System 100 der 1 in einem Datenverarbeitungssystem, welches durch die Hosting-Systeme 101 gehostet wird. Das Datenverarbeitungssystem kann einen Hostprozessor, welcher eine Plattformschicht hostet, wie beispielsweise die Rechenplattformschicht 141 von 1, und mehrere physische Computervorrichtungen, welche an den Hostprozessor angefügt sind, wie beispielsweise CPUs 117 und GPUs 115 von 1, umfassen.
  • Bei Block 801 in einer Ausführungsform kann die Verarbeitungslogik des Prozesses 800 eine Datenstruktur bilden (oder eine Computervorrichtungsdatenstruktur), welche mehrere physische Computervorrichtungen repräsentiert, welche mit einer oder mehreren entsprechenden Fähigkeiten assoziiert sind. Jede physische Computervorrichtung kann an das Verarbeitungssystem angefügt werden, welches die Verarbeitungslogik 800 ausführt. Die Fähigkeiten oder Rechenfähigkeiten einer physischen Computervorrichtung, wie beispielsweise einer CPU oder GPU, können umfassen, ob die physische Computervorrichtung ein Verarbeitungsmerkmal, einen Speicherzugriffsmechanismus, eine genannte Erweiterung oder assoziierte Beschränkungen unterstützt. Ein Verarbeitungsmerkmal kann bezogen sein auf dedizierte Texturhardwareunterstützung, Fließkommaarithmetik von doppelter Genauigkeit oder Synchronisationsunterstützung (zum Beispiel Mutex).
  • Fähigkeiten einer Computervorrichtung können einen Typ umfassen, welcher auf Verarbeitungscharakteristiken oder -beschränkungen, welche mit einer Computervorrichtung assoziiert sind, hinweist. Eine Anwendung kann einen Typ von erforderlicher Computervorrichtung spezifizieren oder den Typ einer spezifischen Computervorrichtung unter Verwendung von APIs abfragen. Beispiele von unterschiedlichen Typen von Computervorrichtungen werden in der folgenden Tabelle gezeigt:
    cl_device_type Beschreibung
    CL_DEVICE_TYPE_CPU Eine Computervorrichtung, welche der Hostprozessor ist. Der Hostprozessor führt die OpenCL-Implementierungen aus und ist ein Einzel- oder Mehrkern-CPU.
    CL_DEVICE_TYPE_GPU Eine Computervorrichtung, welche eine GPU ist. Durch dieses meinen wir, dass die Vorrichtung auch zum Beschleunigen einer 3D-API, wie beispielsweise OpenGL oder DirectX verwendet werden kann.
    CL_DEVICE_TYPE_ACCELERA-TOR Dedizierter Rechenbeschleuniger (zum Beispiel der IBM CELL Blade). Diese Vorrichtungen kommunizieren mit dem Hostprozessor unter Verwendung einer peripheren Verbindung, wie beispielsweise PCIe.
    CL_DEVICE_TYPE_DEFAULT Die Default-Computervorrichtung in dem System.
    CL_DEVICE_TYPE_ALL Alle in dem verfügbaren System Computer-vorrichtungen.
    Tabelle 1
  • Zusätzlich können Fähigkeiten einer Computervorrichtung zum Beispiel Konfigurationswerte, wie in der folgenden Tabelle gezeigt, umfassen.
    cl_device_info Beschreibung
    CL_DEVICE_TYPE Der Computervorrichtungstyp. Derzeitig unterstützte Werte sind: CL_DEVICE_TYPE_CPU, CL_DEVICE_TYPE_GPU, CL_DEVICE_TYPE_ACCELERATOR, CL_DEVICE_TYPE_DEFAULT oder eine Kombination der obigen.
    CL_DEVICE_VENDOR_ID Ein eindeutiger Vorrichtungsanbieterbezeichner. Ein Beispiel eines eindeutigen Vorrichtungsbezeichners könnte die PCIe-ID sein.
    CL_DEVICE_MAX_COMPUTE_UNITS Die Zahl der parallelen Rechenkerne auf der Computervorrichtung. Der minimale Wert ist 1.
    CL_DEVICE_MAX WORK_ITEM_DIMENSIONS Maximale Dimensionen, welche die globalen und lokalen Work-Item-IDs, welche durch das Datenparallelausführungsmodell verwendet werden, spezifiziert.
    CL_DEVICE_MAX_WORK_ITEM_SIZES Maximale Zahl von Work-Items, welche in jeder Dimension der Work-Gruppe spezifiziert werden können.
    CL_DEVICE_MAX_WORK_GROUP_SIZE Maximale Zahl von Work-Items in einer Work-Gruppe, welche einen Kernel ausführen, unter Verwendung des Datenparallelausführungsmodells.
    CL_DEVICE_PREFERRED_VECTOR_WIDTH_CHAR CL_DEVICE_PREFERRED_VECTOR_WIDTH_SHORT CL_DEVICE_PREFERRED_VECTOR_WIDTH_INT CL_DEVICE_PREFERRED_VECTOR_WIDTH_LONG CL_DEVICE_PREFERRED_VECTOR_WIDTH_FLOAT CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE Bevorzugte systemeigene Vektorbreitengröße für eingebaute skalare Typen, welche in Vektoren gesetzt werden können. Die Vektorbreite wird definiert als die Zahl von skalaren Elementen, welche in dem Vektor gespeichert werden können.
    CL_DEVICE_MAX_CLOCK_FREQUENCY Maximale eingerichtete Taktfrequenz der Vorrichtung in MHz.
    CL_DEVICE_ADDRESS_BITS Die Default-Computervorrichtungs-Adressenraumgröße, welche als ein vorzeichenloser Ganzzahlwert in Bits, zum Beispiel 32 oder 64 Bits, spezifiziert ist.
    CL_DEVICE_MAX_MEM_ALLOC_SIZE Max-Größe der Speicherobjektzuordnung in Bytes. Der minimale Wert ist max (1/4 der CL_DEVICE_GLOBAL_MEM_SIZE 128*1024*1024)
    CL_DEVICE_IMAGE_SUPPORT Ist CL_TRUE, wenn Bilder durch die Computervorrichtung unterstützt werden und ansonsten CL_FALSE.
    CL_DEVICE_MAX_READ_IMAGE_ARGS Max-Zahl von simultanen Bildobjekten, welche durch einen Kernel gelesen werden können.
    CL_DEVICE_MAX_WRITE_IMAGE_ARGS Max-Zahl von simultanen Bilderobjekten, auf welche durch einen Kernel geschrieben werden kann.
    CL_DEVICE_IMAGE2D_MAX_WIDTH Max-Breite eines 2D-Bilds in Bildpunkten. Der minimale Wert ist 8192.
    CL_DEVICE_IMAGE2D_MAX_HEIGHT Max-Höhe eines 2D-Bilds in Bildpunkten. Der minimale Wert ist 8192.
    CL_DEVICE_IMAGE3D_MAX_WIDTH Max-Breite eines 3D-Bilds in Bildpunkten. Der minimale Wert ist 2048.
    CL_DEVICE_IMAGE3D_MAX_HEIGHT Max-Höhe eines 3D-Bilds in Bildpunkten. Der minimale Wert ist 2048, wenn CL_DEVICE_IMAGE_SUPPORT CL_TRUE ist.
    CL_DEVICE_IMAGE3D_MAX_DEPTH Max-Tiefe eines 3D-Bilds in Bildpunkten. Der minimale Wert ist 2048.
    CL_DEVICE_MAX_SAMPLERS Maximale Anzahl von Samplern, welche in einem Kernel verwendet werden können. Der minimale Wert kann 16 sein.
    CL_DEVICE_MAX_PARAMETER_SIZE Max-Größe in Bytes der Argumente, welche an einen Kernel weitergegeben werden können. Der minimale Wert ist 256.
    CL_DEVICE_MEM_BASE_ADDR_ALIGN Beschreibt die Ausrichtung in Bits der Basisadresse irgendeines zugeordneten Speicherobjekts.
    CL_DEVICE_MIN_DATA_TYPE_ALIGN_SIZE Die kleinste Ausrichtung in Bytes, welche für irgendeinen Datentyp verwendet werden kann.
    CL_DEVICE_SINGLE_FP_CONFIG Beschreibt Fließkomma-Fähigkeit einfacher Genauigkeit der Vorrichtung. Dies ist ein Bit-Feld, welches ein oder mehrere der folgenden Werte beschreibt: CL_FP_DENORM – Denormalisierte Zahlen werden unterstützt. CL_FP_INF_NAN – INF and stille NaNs werden unterstützt. CL_FP_ROUND_TO_NEAREST – Rundung zur nächstgelegenen geraden Zahl-Rundungsmodus (round to nearest even rounding-mode) wird unterstützt. CL_FP_ROUND_TO_ZERO – Rundung gegen Null-Rundungsmodus (round to zero rounding mode) wird unterstützt. CL_FP_ROUND_TO_INF – Rundung gegen +Unendlich und gegen –Unendlich Rundungsmodi (round to +ve and –ve infinity rounding modes) werden unterstützt. CL_FP_FMA – IEEE754-2008 Fused multiply-add wird unterstützt. Die vorgeschriebene minimale Fließkomma-Fähigkeit ist: CL_FP_ROUND_TO_NEAREST|CL_FP_INF_NAN.
    CL_DEVICE_GLOBAL_MEM_CACHE_TYPE Typ von globalem Speichercache, welcher unterstützt wird. Gültige Werte sind:
    CL_NONE, CL_READ_ONLY_CACHE und CL_READ_WRITE_CACHE.
    CL_DEVICE_GLOBAL_MEM_CACHELINE_SIZE Größe der globalen Speichercachelinie in Bytes.
    CL_DEVICE_GLOBAL_MEM_CACHE_SIZE Größe des globalen Speichercaches in Bytes.
    CL_DEVICE_GLOBAL_MEM_SIZE Größe des globalen Vorrichtungsspeichers in Bytes.
    CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE Max-Größe in Bytes einer konstanten Pufferzuordnung. Der minimale Wert ist 64 KB.
    CL_DEVICE_MAX_CONSTANT_ARGS Max-Anzahl von Argumenten, welche mit dem_constant Qualifizierer in einen Kernel deklariert werden. Der minimale Wert ist 8.
    CL_DEVICE_LOCAL_MEM_TYPE Typ von lokalem Speicher, welcher unterstützt wird. Zum Beispiel kann dies auf CL_LOCAL gesetzt werden, was dedizierte lokale Speicherspeicherung, wie beispielsweise SRAM oder CL_GLOBAL, impliziert.
    CL_DEVICE_LOCAL_MEM_SIZE Größe des lokalen Speicherbereichs in Bytes.
    CL_DEVICE_ERROR_CORRECTION_SUPPORT Ist CL_TRUE, wenn die Vorrichtung Fehlerkorrektur für die Speicher, Cache, Register und so weiter in der Vorrichtung implementiert. Ist CL_FALSE, wenn die Vorrichtung nicht Fehlerkorrektur implementiert.
    CL_DEVICE_PROFILING_TIMER_RESOLUTION Beschreibt die Auflösung des Vorrichtungs-Timers. Diese ist gemessen in Nanosekunden.
    CL_DEVICE_ENDIAN_LITTLE Ist CL_TRUE, wenn die Computervorrichtung eine little-endian-Vorrichtung ist und ansonsten CL_FALSE.
    CL_DEVICE_AVAILABLE Ist CL_TRUE, wenn die Vorrichtung verfügbar ist und CL_FALSE, wenn die Vorrichtung nicht verfügbar ist.
    CL_DEVICE_COMPILER_AVAILABLE Ist CL_FALSE, wenn die Implementierung nicht einen Compiler aufweist, welcher verfügbar ist zum Kompilieren der Programmquelle. Ist CL_TRUE, wenn der Compiler verfügbar ist. Dies kann CL_FALSE sein nur für das eingebettete Plattformprofil.
    CL_DEVICE_EXECUTION_CAPABILITIES Beschreibt die Ausführungsfähigkeiten der Vorrichtung. Dies ist ein Bit-Feld, welches einen oder mehrere der folgenden Werte beschreibt: CL_EXEC_KERNEL – Die Computervorrichtung kann Rechenkernels ausführen. CL_EXEC_NATIVE_KERNEL – Die Computervorrichtung kann systemeigene Kernels ausführen. Die vorgeschriebene minimale Fähigkeit ist: CL_EXEC_KERNEL
    CL_DEVICE_QUEUE_PROPERTIES Beschreibt die Befehlswarteschlangeneigenschaften, welche durch die Vorrichtung unterstützt werden. Dies ist ein Bit-Feld, welches ein oder mehrere der folgenden Werte beschreibt: CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE CL_QUEUE_PROFILING_ENABLE Die vorgeschriebene minimale Fähigkeit ist: CL_QUEUE_PROFILING_ENABLE
    CL_DEVICE_PLATFORM Die Plattform, welche mit dieser Vorrichtung assoziiert ist.
    CL_DEVICE_NAME Vorrichtungsnamen-String.
    CL_DEVICE_VENDOR Anbieternamen-String
    CL_DRIVER_VERSION Computersoftware-Treiberversions-String in der Form major_number.minor_number.
    CL_DEVICE_PROFILE1 Berechnen des Profilstrings. Zurückgeben des Profilnamens, welcher durch die Vorrichtung unterstützt wird. Der Profilname, welcher zurückgegeben wird, kann einer der folgenden Strings sein: FULL_PROFILE – wenn die Vorrichtung die Berechnungsspezifikation unterstützt (Funktionalität, definiert als ein Teil der Kernspezifikation und nicht irgendwelche Erweiterungen erfordert, welche zu unterstiitzen sind). EMBEDDED_PROFILE – wenn die Vorrichtung das recheneingebettete Profil unterstiitzt.
    CL_DEVICE_VERSION Berechnen des Rechenversionsstrings. Gibt die berechnete Version, welche durch die Vorrichtung unterstützt wird, zurück.
    CL_DEVICE_EXTENSIONS Ein String von optionalen Eigenschaften, welche unterstiitzt werden. Die Liste der derzeitig zurückgegebenen Erweiterungsnamen kann ein oder mehrere der folgenden genehmigten Erweiterungsnamen umfassen: cl_khr_fp64 cl_khr_select_fprounding_mode cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomia cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_fp16 cl_khr_gl_sharing
    Tabelle 2
  • 1 Das Plattform-Profil gibt das Profil zurück, dass durch das OpenCL-Framework implementiert wird. Wenn das zurückgegebene Plattform-Profil FULL_PROFILE ist, wird das OpenCL-Framework Vorrichtungen unterstützen, welche FULL_PROFILE sind und kann auch Vorrichtungen unterstützen, welche EMBEDDED_PROFILE sind. Der Compiler muss für alle Vorrichtungen verfügbar sein, d. h. CL_DEVICE_COMPILER_AVAILABLE ist CL_TRUE. Wenn das zurückgegebene Plattform-Profil EMBEDDED_PROFILE ist, dann werden Vorrichtungen unterstützt, welche nur EMBEDDED_PROFILE sind.
  • Ein Speicherzugriffmechanismus für eine physische Verarbeitungsvorrichtung kann bezogen sein auf einen Typ von variablem Cache (z. B. keine Unterstützung, Nur-Lese oder Lese-Schreib), einem Typ von Rechenspeicherobjekt-Cache, Größe von Cache-Unterstützung einer dedizierten lokalen Speicherunterstützung oder assoziierten Beschränkungen. Die Speicherzugriffsbeschränkungen können eine maximale Zahl von Rechenspeicherobjekten, welche gleichzeitig gelesen oder durch eine Computerprogrammausführbare Datei beschrieben werden können, eine maximale Zahl von Rechenspeicherobjekten, welche zugeordnet werden können, oder eine maximale Zahl entlang einer Dimension eines multidimensionalen Rechenspeicherobjekts, z. B. einer maximalen Breite eines Rechenspeicherobjekts für ein 2D (zweidimensionales) Bild, umfassen. Eine Systemanwendung des Datenverarbeitungssystems kann die Datenstruktur aktualisieren in Antwort auf das Anbringen einer neuen physischen Computervorrichtung an ein Datenverarbeitungssystem. In einer Ausführungsform können die Fähigkeiten einer physischen Computervorrichtung vorherbestimmt werden. In einer anderen Ausführungsform kann eine Systemanwendung des Datenverarbeitungssystems eine kürzlich angefügte physische Verarbeitungsvorrichtung während der Laufzeit entdecken. Die Systemanwendung kann die Fähigkeiten der kürzlich entdeckten physischen Computervorrichtung abrufen, um die Datenstruktur zu aktualisieren, welche die angefügten physischen Computervorrichtungen und ihre entsprechenden Fähigkeiten repräsentiert.
  • Gemäß einer Ausführungsform kann die Verarbeitungslogik des Prozesses 800 ein Rechenfähigkeitserfordernis von einer Anwendung bei Block 803 empfangen. Die Anwendung kann das Rechenfähigkeitserfordernis an eine Systemanwendung durch Aufrufen von APIs senden. Die Systemanwendung kann einer Plattformschicht eines Softwarestapels in einem Hosting-System für die Anwendung entsprechen. In einer Ausführungsform kann ein Rechenfähigkeitserfordernis eine Liste von erforderlichen Fähigkeiten identifizieren zum Anfragen von Verarbeitungsressourcen, um eine Aufgabe für die Anwendung auszuführen. In einer Ausführungsform kann die Anwendung es erfordern, dass die angefragten Verarbeitungsressourcen die Aufgabe in mehreren Threads gleichzeitig ausführen. In Antwort kann die Verarbeitungslogik des Prozesses 800 eine Gruppe von physischen Computervorrichtungen aus angefügten physischen Computervorrichtungen bei Block 805 auswählen. Die Auswahl kann bestimmt werden basierend auf einem Abgleichen zwischen den Rechenfähigkeitserfordernissen gegen die Rechenfähigkeiten, welche in der Fähigkeitsdatenstruktur gespeichert sind. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 800 das Abgleichen ausführen gemäß einem Hinweis, welcher durch das Fähigkeitserfordernis bereitgestellt wird.
  • Die Verarbeitungslogik des Prozesses 800 kann eine Abgleich-Zahl gemäß der Anzahl von Rechenfähigkeiten, welche zwischen einer physischen Computervorrichtung und dem Rechenfähigkeitserfordernis abgeglichen werden, bestimmen. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 800 mehrere physische Computervorrichtungen mit höchsten Abgleich-Zahlen auswählen. In einer anderen Ausführungsform kann die Verarbeitungslogik des Prozesses 800 eine physische Computervorrichtung auswählen, wenn jede Fähigkeit in dem Fähigkeitserfordernis abgeglichen wird. Die Verarbeitungslogik des Prozesses 800 kann mehrere Gruppen von passenden physischen Computervorrichtungen bei Block 805 bestimmen. In einer Ausführungsform wird jede Gruppe der passenden physischen Computervorrichtungen gemäß einer Lastausgleichsfähigkeit jeder Vorrichtung ausgewählt. Bei Block 807, in einer Ausführungsform, kann die Verarbeitungslogik des Prozesses 800 einen Rechencomputervorrichtungsbezeichner für jede Gruppe von physischen Computervorrichtungen erzeugen, welche bei Block 805 ausgewählt werden. Die Verarbeitungslogik des Prozesses 800 kann eine oder mehrere der erzeugten Computervorrichtungsbezeichner zurück an die Anwendung über die aufrufenden APIs geben. Eine Anwendung kann wählen, welche Verarbeitungsressourcen anzuwenden sind zum Ausführen einer Aufgabe gemäß den Computervorrichtungsbezeichnern. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 800 höchstens einen Computervorrichtungsbezeichner bei Block 807 für jedes Fähigkeitserfordernis, welches empfangen wurde, erzeugen.
  • Bei Block 809, in einer Ausführungsform, kann die Verarbeitungslogik des Prozesses 800 Ressourcen zum Initialisieren von einer logischen Computervorrichtung für eine Gruppe von physischen Computervorrichtungen, welche bei Block 805 ausgewählt werden, gemäß einem entsprechenden Computervorrichtungsbezeichner zuordnen. Eine logische Computervorrichtung kann eine Computervorrichtungsgruppe einschließlich einer oder mehrerer physischer Computervorrichtungen sein. Die Verarbeitungslogik des Prozesses 800 kann das Initialisieren einer logischen Computervorrichtung in Antwort auf API-Anfragen von einer Anwendung ausführen, welche ein oder mehrere Computervorrichtungsbezeichner gemäß der Auswahl bei Block 805 empfangen hat.
  • Die Verarbeitungslogik des Prozesses 800 kann ein Kontextobjekt auf der logischen Computervorrichtung für eine Anwendung bei Block 811 kreieren. Befehle, welche auf dem Rechenspeicherobjekt operieren, Rechenprogrammobjekte und/oder Rechenprogramm-ausführbare Dateien für ein Kontextobjekt können der Reihe nach (z. B. synchron) oder nicht der Reihe nach (z. B. asynchron) gemäß den Parametern, welche in den API-Anfragen spezifiziert sind, beim Kreieren des Kontextobjektes ausgeführt werden. Profilbildende Befehle, welche auf Rechenspeicherobjekten operieren, Rechenprogramme oder Rechen-Kernels können für ein Kontextobjekt unter Verwendung von API-Anfragen befähigt werden. In einer Ausführungsform wird ein Kontextobjekt mit einem Anwendungsthread in einem Hosting-System, welches die Anwendung ausführt, assoziiert. Mehrere Threads, welche Verarbeitungsaufgaben in einer logischen Computervorrichtung oder über unterschiedliche logische Computervorrichtungen hinweg gleichzeitig ausführen, können auf separaten Kontextobjekten basiert sein.
  • In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 800 basieren auf mehreren APIs einschließlich clCreateContext, clRetainContext und clReleaseContext. Die API clCreateContext kreiert einen Rechenkontext. Ein Rechenkontext kann einem Rechenkontextobjekt entsprechen. Die API clRetainContext erhöht die Anzahl von Instanzen unter Verwendung eines speziellen Rechenkontexts, welcher durch einen Kontext als ein Eingabeargument für clRetainContext identifiziert wird. Die API clCreateContext führt ein impliziertes Halten aus. Dies ist nützlich für Drittparteienbibliotheken, welche typsicherweise einen Kontext bekommen, welcher ihnen durch die Anwendung weitergeben wird. Jedoch ist es möglich, dass die Anwendung den Kontext ohne das Informieren der Bibliothek löscht. Das mehreren Instanzen Erlauben an einen Kontext anzufügen und sich von einem Kontext zu lösen, löst das Problem eines Rechenkontexts, welcher durch eine Bibliothek verwendet wird, welche nicht länger gültig ist. Wenn ein Eingabeargument an clRetainContext nicht einem gültigen Rechenkontextobjekt entspricht, gibt clRetainContext an das CU_INVALID_CONTEXT wieder. Die API clReleaseContext löst eine Instanz von einem gültigen Rechenkontext. Wenn ein Eingabeargument an clReleaseContext nicht einem gültigen Rechenkontextobjekt entspricht, gibt clReleaseContext CU_INVALID_CONTEXT zurück.
  • 9 ist ein Flussdiagramm, welches eine Ausführungsform eines Beispielprozesses 900 zeigt, um eine rechenausführbare Datei in einer logischen Computervorrichtung auszuführen. In einer Ausführungsform kann der Prozess 900 ausgeführt werden durch eine Laufzeitschicht in einem Datenverarbeitungssystem, wie beispielsweise der Rechenlaufzeitschicht 109 der 1. Bei Block 901 kann die Verarbeitungslogik des Prozesses 900 ein oder mehrere Rechenspeicherobjekte (z. B. Streams) in einer logischen Computervorrichtung zuordnen, um eine rechenausführbare Datei auszuführen. Ein Rechenspeicherobjekt kann ein oder mehrere Datenelemente umfassen, um zum Beispiel ein Bildspeicherobjekt oder ein Feldspeicherobjekt zu repräsentieren. Ein Feldspeicherobjekt kann eine eindimensionale Sammlung von Datenelementen sein. Ein Bildspeicherobjekt kann eine Sammlung sein, um zweidimensionale, dreidimensionale oder mehrdimensionale Daten zu speichern, wie beispielsweise eine Textur, einen Rahmenpuffer oder ein Bild. Eine Verarbeitungsaufgabe kann durch eine Rechenprogramm-ausführbare Datei ausgeführt werden, welche auf Rechenspeicherobjekten oder -streams operiert, welche Rechenspeicher-APIs verwenden, einschließlich dem Lesen von eingegebenen Rechenspeicherobjekten und Schreiben auf ausgegebene Rechenspeicherobjekte. In einer Ausführungsform kann ein Rechenspeicherobjekt an ein Datenobjekt angefügt werden, wie beispielsweise ein Pufferobjekt, Texturobjekt oder ein Renderpufferobjekt, zum Aktualisieren des Datenobjekts unter Verwendung der Rechenspeicher APIs. Ein Datenobjekt kann assoziiert werden mit APIs, welche graphische Datenverarbeitungsoperationen aktivieren, wie beispielsweise Textrendering, auf dem Datenobjekt. In einer Ausführungsform ist ein Speicherobjekt ein Puffer mit mehreren Sub-Puffern, wie in 2 oben beschrieben.
  • Beim Zuordnen eines Rechenspeicherobjekts kann die Verarbeitungslogik des Prozesses 900 bestimmen, wo die Zuordnung gemäß den Spezifikationen in einem API liegen sollte. Zum Beispiel kann ein Rechenspeicherobjekt aus einem Hostspeichers zugeordnet werden, wie beispielsweise einem Hostspeicher für die Hosting-Systeme 101 der 1 und/oder ein Computervorrichtungsspeicher, wie beispielsweise einem globalen Speicher oder einem konstanten Speicher 217 von 2. Ein Rechenspeicherobjekt, welches in einem Hostspeicher zugeordnet ist, kann es erfordern, in einem Computervorrichtungsspeicher gecached zu werden. Die Verarbeitungslogik des Prozesses 900 kann asynchron Daten in zugeordnete Rechenspeicherobjekte unter Verwendung von nichtblockierenden API-Schnittstellen laden, zum Beispiel basierend auf erzeugten Ereignisobjekten, welche Synchronisationsdaten umfassen, welche anzeigen, ob Daten in ein Rechenspeicherobjekt geladen worden sind. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 900 Speicherzugriffsoperationen beim Lesen von oder Schreiben auf zugeordnete Rechenspeicherobjekte planen. Die Verarbeitungslogik des Prozesses 900 kann einen zugeordneten Streamspeicher abbilden, um eine logische Adresse einer Anwendung zu bilden. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 900 Operationen bei Block 901 ausführen, basierend auf API-Anfragen von einer Anwendung, welche in einem Hostprozessor ausgeführt wird, wie beispielsweise Anwendungen 103 der 1.
  • Bei Block 903, gemäß einer Ausführungsform, kann die Verarbeitungslogik des Prozesses 900 ein Rechenprogrammobjekt für die logische Computervorrichtung (z. B. eine Computervorrichtungsgruppe) kreieren. Ein Rechenprogrammobjekt kann eine Gruppe von Rechenkernels umfassen, welche exportierte Funktionen oder Eintrittspunkte von einem Datenparallelprogramm repräsentieren. Ein Rechenkernel kann einen Zeiger auf eine Rechenprogramm-ausführbare Datei umfassen, welche auf einer Recheneinheit ausgeführt werden kann, um eine Datenparallelausgabe auszuführen (z. B. eine Funktion). Jeder Rechenkernel kann mit einer Gruppe von Funktionsargumenten assoziiert werden, einschließlich Rechenspeicherobjekten oder -streams, welche für Funktionseingaben oder -ausgaben zugeordnet werden, wie beispielsweise die Streams, welche bei Block 901 zugeordnet werden.
  • Die Verarbeitungslogik des Prozesses 900 kann eine Rechenprogrammbinärdatei und/oder eine Rechenprogrammquelle in das Rechenprogrammobjekt bei Block 909 laden. Eine Rechenprogrammbinärdatei kann Bits umfassen, welche eine Rechenprogramm-ausführbare Datei beschreiben, welche auf einer Computervorrichtung ausgeführt wird. Eine Rechenprogrammbinärdatei kann eine Rechenprogramm-ausführbare Datei und/oder eine Zwischendarstellung einer Rechenprogrammquelle sein, welche in eine Rechenprogramm-ausführbare Datei zu konvertieren ist. In einer Ausführungsform kann eine Rechenprogramm-ausführbare Datei Beschreibungsdaten umfassen, welche zum Beispiel mit dem Typ von Ziel-physischen Computervorrichtungen (zum Beispiel einer GPU oder einer CPU), Versionen und/oder Kompilierungsoptionen oder Flags, wie beispielsweise eine Thread-Gruppengröße und/oder Thread-Gruppendimensionen assoziiert sind. Eine Rechenprogrammquelle kann der Quellcode sein, von wo ein Rechenprogramm-ausführbarer Teil kompiliert wird. Die Verarbeitungslogik des Prozesses 900 kann mehrere Rechenprogrammausführbare Dateien laden, welche einer Rechenprogrammquelle entsprechen, bei Block 909. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 900 eine Rechenprogramm-ausführbare Datei von einer Anwendung oder durch eine Rechenbibliothek, wie beispielsweise die Rechenanwendungsbibliothek 105 von 1, laden. Eine Rechenprogrammausführbare Datei kann mit der entsprechenden Rechenprogrammquelle geladen werden. Die Verarbeitungslogik des Prozesses 900 kann Funktionsargumente für ein Rechenprogrammobjekt bei Block 905 einstellen. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 900 Operationen bei Blocks 903, 905 und 909 gemäß den API-Anfragen von einer Anwendung ausführen.
  • Bei Block 911 kann die Verarbeitungslogik des Prozesses 900 eine Ausführungswarteschlange aktualisieren, um das Rechenkernelobjekt mit einer logischen Computervorrichtung auszuführen. Die Verarbeitungslogik des Prozesses 900 kann einen Computerkernel in Antwort auf die API-Aufrufe mit geeigneten Argumenten an eine Rechenlaufzeit, zum Beispiel Rechenlaufzeit 109 von 1, von einer Anwendung oder einer Rechenanwendungsbibliothek, wie beispielsweise Anwendungen 103 oder Rechenanwendungsbibliothek 105 von 1, ausführen. Das Ausführen eines Rechenkernels kann das Ausführen einer Rechenprogramm-ausführbaren Datei, welche mit dem Rechenkernel assoziiert ist, umfassen. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 900 eine Rechenkernelausführungsinstanz erzeugen, um einen Rechenkernel auszuführen. API-Aufrufe an eine Rechenlaufzeit, wie beispielsweise Rechenlaufzeit 109 von 1, zum Ausführen eines Rechenkernels können in ihrer Natur asynchron sein. Eine Ausführungsinstanz kann identifiziert werden durch ein Rechenereignisobjekt, welches durch eine Rechenlaufzeit, wie beispielsweise Rechenlaufzeit 109 von 1, zurückgegeben wird. Eine Rechenkernelausführungsinstanz kann zu einer Ausführungswarteschlange hinzugefügt werden, um eine Rechenkernelinstanz auszuführen.
  • In einer Ausführungsform können API-Aufrufe an eine Rechenlaufzeit, um einen Rechenkernel auszuführen, die Anzahl von Threads umfassen, welche gleichzeitig parallel auf einem Rechenprozessor als eine Thread-Gruppe ausgeführt werden. Ein API-Aufruf kann die Anzahl von Rechenprozessoren zur Verwendung umfassen. Eine Rechenkernelausführungsinstanz kann einen Prioritätswert umfassen, welcher eine gewünschte Priorität anzeigt, um die entsprechende Rechenprogramm-ausführbare Datei auszuführen. Eine Rechenkernelausführungsinstanz kann auch ein Ereignisobjekt umfassen, welches eine vorherige Ausführungsinstanz und/oder erwartete totale Gesamtzahl von Threads und Anzahl von Thread-Gruppen, um die Ausführung auszuführen, identifiziert. Die Zahl von Thread-Gruppen und die Gesamtzahl von Threads können in den API-Aufrufen spezifiziert werden. In einer Ausführungsform kann ein Ereignisobjekt eine Ausführungsreihenfolgebeziehung zwischen der Ausführungsinstanz, welche das Ereignisobjekt umfasst, und einer anderen Ausführungsinstanz, welche durch das Ereignisobjekt identifiziert wird, anzeigen. Eine Ausführungsinstanz einschließlich eines Ereignisobjekts kann es erfordern ausgeführt zu werden, nachdem eine andere Ausführungsinstanz, welche durch das Ereignisobjekt identifiziert wird, die Ausführung beendet. Ein Ereignisobjekt kann bezeichnet werden als ein q_after_event-Objekt. Ereignisse und Ereignisabhängigkeiten werden weiter in 11 und 12 unten beschrieben. In einer Ausführungsform kann eine Ausführungswarteschlange mehrere Rechenkernelausführungsinstanzen zur Ausführung entsprechender Rechenprogramm-ausführbarer Dateien umfassen. Ein oder mehrere Rechenkernelausführungsinstanzen für eine Rechenprogramm-ausführbare Datei können für die Ausführung in einer Ausführungswarteschlange geplant werden. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 900 die Ausführungswarteschlange in Antwort auf API-Anfragen von einer Anwendung aktualisieren. Die Ausführungswarteschlange kann durch die Hosting-Datensysteme gehostet werden, wo die Anwendung läuft.
  • Bei Block 913 kann die Verarbeitungslogik des Prozesses 900 eine Rechenkernelausführungsinstanz aus der Ausführungswarteschlange für die Ausführung auswählen. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 900 mehr als eine Rechenkernelausführungsinstanz zur gleichzeitigen Ausführung gemäß den entsprechenden logischen Computervorrichtungen auswählen. Die Verarbeitungslogik des Prozesses 900 kann bestimmen, ob eine Rechenkernelausführungsinstanz aus der Ausführungswarteschlange basierend auf ihrer assoziierten Priorität und Abhängigkeitsbeziehungen mit anderen Ausführungsinstanzen in der Ausführungswarteschlange ausgewählt wird. Eine Rechenkernelausführungsinstanz kann ausgeführt werden durch Ausführen ihres entsprechenden Rechenkernelobjekts gemäß einer ausführbaren Datei, welche in das Rechenkernelobjekt geladen wird.
  • Bei Block 917, in einer Ausführungsform, kann die Verarbeitungslogik des Prozesses 900 eine der Mehrzahl von ausführbaren Dateien, welche in das Rechenkernelobjekt geladen werden, auswählen, welche der ausgewählten Rechenkernelinstanz für die Ausführung in einer physischen Computervorrichtung entsprechen, welche mit der logischen Computervorrichtung für das Rechenkernelobjekt assoziiert ist. Die Verarbeitungslogik des Prozesses 900 kann mehr als eine ausführbare Datei zur Ausführung in mehr als einer physischen Computervorrichtung parallel auswählen für eine Rechenkernelausführungsinstanz. Die Auswahl kann basieren auf derzeitigen Ausführungszuständen der physischen Computervorrichtungen entsprechend der logischen Computervorrichtung, welche mit der ausgewählten Rechenkernelausführungsinstanz assoziiert ist. Ein Ausführungszustand einer physischen Computervorrichtung kann die Anzahl von laufenden Threads, den Lokalspeichernutzungslevel und den Prozessornutzungslevel (z. B. Höchstzahl von Operationen pro Einheitszeit) usw. umfassen. In einer Ausführungsform kann die Auswahl basieren auf vorbestimmten Nutzungsleveln. In einer anderen Ausführungsform kann die Auswahl basieren auf der Zahl von Threads und Anzahl von Threadgruppen, welche mit der Rechenkernelausführungsinstanz assoziiert sind. Die Verarbeitungslogik des Prozesses 900 kann einen Ausführungsstatus von einer physischen Computervorrichtung abrufen. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 900 Operationen ausführen zum Auswählen einer Rechenkernelausführungsinstanz von der Ausführungswarteschlange, um bei den Blöcken 913, 917 asynchron mit Anwendungen, welche in den Hosting-Systemen laufen, ausgeführt zu werden.
  • Bei Block 919 kann die Verarbeitungslogik des Prozesses 900 den Ausführungszustand einer Rechenkernelausführungsinstanz überprüfen, welche für die Ausführungen der Ausführungswarteschlange geplant ist. Jede Ausführungsinstanz kann durch ein eindeutiges Rechenereignisobjekt identifiziert werden. Ein Ereignisobjekt kann an eine Anwendung oder eine Rechenanwendungsbibliothek, wie beispielsweise Anwendung 103 oder Rechenanwendungsbibliothek 105 von 9 zurückgegeben werden, welche APIs aufruft, um die Ausführungsinstanz auszuführen, wenn die entsprechende Rechenkernelausführungsinstanz gemäß einer Rechenlaufzeit, wie beispielsweise die Laufzeit 109 von 1, in eine Warteschlange gesetzt wurde. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 900 das Überprüfen des Ausführungszustands ausführen in Antwort auf die API-Anfragen von einer Anwendung. Die Verarbeitungslogik des Prozesses 900 kann die Fertigstellung des Ausführens einer Rechenkernelausführungsinstanz bestimmen durch Abfragen eines Zustands des Rechenereignisobjekts, welches die Rechenkernelausführungsinstanz identifiziert. Die Verarbeitungslogik des Prozesses 900 kann warten bis die Ausführung einer Rechenkernelausführungsinstanz fertiggestellt ist, um zu API-Aufrufen von einer Anwendung zurückzukehren. Die Verarbeitungslogik des Prozesses 900 kann Lesen und/oder Schreiben von Rechenkernelausführungsinstanzen von verschiedenen Streams basierend auf Rechenereignisobjekten steuern.
  • Bei Block 921, gemäß einer Ausführungsform, kann die Verarbeitungslogik des Prozesses 900 Ergebnisse des Ausführens einer Rechenkernelausführungsinstanz abrufen. Anschließend kann die Verarbeitungslogik des Prozesses 900 Verarbeitungsressourcen bereinigen, welche für die Ausführung der Rechenkernelausführungsinstanz zugeordnet werden. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 900 einen Stream-Speicher, welcher Ergebnisse des Ausführens einer Rechenkernel-ausführbaren Datei bereithält, in einen lokalen Speicher kopieren. Die Verarbeitungslogik des Prozesses 900 kann variable Streams oder Bildstreams, welche bei Block 901 zugeordnet werden, löschen. Die Verarbeitungslogik des Prozesses 900 kann ein Kernelereignisobjekt löschen zum Detektieren, wann eine Rechenkernelausführung fertiggestellt ist. Wenn jede Rechenkernelausführungsinstanz, welche mit einem spezifischen Rechenkernelobjekt assoziiert ist, komplett ausgeführt worden ist, kann die Verarbeitungslogik des Prozesses 900 das spezifische Rechenkernelobjekt löschen. In einer Ausführungsform kann die Verarbeitungslogik des Prozesses 900 Operationen bei Block 921 ausführen basierend auf API-Anfragen, welche durch eine Anwendung initiiert werden.
  • 10 ist ein Flussdiagramm, welches eine Ausführungsform eines Laufzeitprozesses 1000 zeigt, zum Kreieren und Verwenden von Sub-Puffern mit mehreren Recheneinheiten. Der beispielhafte Prozess 1000 kann ausgeführt werden durch eine Verarbeitungslogik, welche Hardware (Schaltungen, dezidierte Logik usw.), Software (wie beispielsweise auf einer dedizierten Maschine laufend), oder eine Kombination von beiden aufweisen kann. Zum Beispiel kann der Prozess 1000 ausgeführt werden gemäß dem System 100 der 1 in einem Datenverarbeitungssystem, welches durch die Hosting-Systeme 101 gehostet wird. Das Datenverarbeitungssystem kann einen Hostprozessor, welcher eine Plattformschicht hostet, wie beispielsweise eine Rechenplattformschicht 141 der 1 und mehrere physische Computervorrichtungen umfassen, welche an dem Hostprozessor angefügt sind, wie beispielsweise CPUs 117 und GPUs 115 von 1.
  • In 10 kreiert der Prozessor 1000 einen Sub-Puffer für eine Recheneinheit, wo der Sub-Puffer mit einem Puffer assoziiert ist. In einer Ausführungsform kreiert der Prozess 1000 einen Sub-Puffer aus einem derzeitig zugeordneten Puffer. Zum Beispiel und in einer Ausführungsform kreiert der Prozess 1000 einen Sub-Puffer aus einem zugeordneten Puffer unter Verwendung des Funktionsaufrufs:
    cl_mem clCreateSubBuffer (cl_mem buffer,
    cl_mem_flags flags,
    cl_buffer_create_type buffer_create_type,
    const void*buffer_create_info,
    cl_int*errcode_ret)
    wobei buffer ein existierender Puffer ist, flags ein Bitfeld ist, welches verwendet wird zum Spezifizieren der Zuordnung und Verwendungsinformationen über das Bildspeicherobjekt, welches kreiert und in Tabelle 3 beschrieben wird, size die Größe in Bytes des Sub-Pufferspeicherobjekts, welches zuzuordnen ist, ist, buffer_create_type und buffer_create_info den Typ von zu kreierendem Pufferobjekt beschreiben. Die Liste von unterstützen Werten für buffer_create_type und den entsprechenden Deskriptor, auf welchen buffer_create_info zeigt, wird in Tabelle 4 beschrieben.
    cl_mem_flags Beschreibung
    CL_MEM_READ_WRITE Dieses Flag spezifiziert, dass das Speicherobjekt durch einen Kernel gelesen und beschrieben wird. Dies ist der Default.
    CL_MEM_WRITE_ONLY Dieses Flag spezifiziert, dass das Speicherobjekt durch einen Kernel beschrieben werden wird, aber nicht gelesen wird.
    CL_MEM_READ_ONLY Dieses Flag spezifiziert, dass das Speicherobjekt ein Nur-Lese-Speicherobjekt ist, wenn es innerhalb eines Kernels verwendet wird.
    CL_MEM_USE_HOST_PTR Dieses Flag ist gültig nur wenn host_ptr nicht NULL ist. Wenn spezifiziert, zeigt es an, dass die Anwendung will, dass die Implementierung Speicher verwendet, welcher durch host_ptr referenziert ist als Speicherbits für das Speicherobjekt. Implementieren kann es erlaubt werden, die Pufferinhalte zu cachen, auf welche durch host_ptr im Vorrichtungsspeicher gezeigt wird. Diese gecachte Kopie kann verwendet werden, wenn die Kernels auf einer Vorrichtung ausgeführt werden. Das Ergebnis von OpenCL-Befehlen, welche auf mehreren Pufferobjekten operieren, welche mit der gleichen host_ptr oder überlappenden Hostregionen kreiert werden, wird betrachtet als undefiniert.
    CL_MEM_ALLOC_HOST_PTR Dieses Flag spezifiziert, dass die Anwendung will, dass die Implementierung Speicher von Host-zugreifbarem Speicher zuordnet. CL_MEM_ALLOC_HOST_PTR und CL_MEM_USE_HOST_PTR sind beidseitig exklusiv.
    CL_MEM_COPY_HOST_PTR Dieses Flag ist gültig, wenn host_ptr nicht NULL ist. Wenn spezifiziert, zeigt es an, dass die Anwendung will, dass die Implementierung Speicher für das Speicherobjekt zuordnet und die Daten vom Speicher, welcher durch host_ptr referenziert wird, kopiert. CL_MEM_COPY_HOST_PTR und CL_MEM_USE_HOST_PTR sind beidseitig exklusiv. CL_MEM_COPY_HOST_PTR kann verwendet werden mit CL_MEM_ALLOC_HOST_PTR zum Initialisieren der Inhalte des cl_mem-Objekts, welches zugeordnet wird unter Verwendung von Host-zugreifbarem (z. B. PCIe) Speicher.
    Tabelle 3. Sub-Pufferspecherkreierungsflags
    cl_buffer_create_type Beschreibung
    CL_BUFFER_CREATE_TYPE _REGION Kreieren eines Pufferobjekts, welches einen spezifischen Bereich im buffer repräsentiert. buffer_create_info ist ein Zeiger auf die folgende Struktur: typedef struct_cl_buffer_region { size_t origin; size_t size; } cl_buffer_region; (origin, size) definiert den Offset und die Größe in Bytes im buffer. Wenn buffer kreiert wird mit CL_MEM_USE_HOST_PTR, ist der host_ptr, welcher mit dem zurückgegebenen Pufferobjekt assoziiert ist, host_ptr + origin. Das zurückgegebene Pufferobjekt referenziert den Datenspeicher, welcher für buffer zugeordnet wurde und zeigt auf einen spezifischen Bereich, welcher durch (origin, size) in diesem Datenspeicher angegeben wird. CL_INVALID_VALUE wird zurückgegeben in errcode_ret, wenn der Bereich, welcher durch (origin, size) spezifiziert wird, außerhalb der Grenzen in buffer ist. CL_MISALIGNED_SUB_BUFFER_OFFSET wird zurückgegeben in errcode_ret, wenn es keine Vorrichtungen im Kontext gibt, welche mit buffer assoziiert sind, für welchen der origin-Wert ausgerichtet ist an dem CL_DEVICE_MEM_BASE_ADDR_ALIGN-Wert.
    Tabelle 4 CL_BUFFER_CREATE_TYPE_-Werte
  • Bei Block 1004 bestimmt der Prozess 1000, ob die Recheneinheit für den Sub-Puffer die gleiche Recheneinheit wie der übergeordnete Puffer ist. Zum Beispiel und in einer Ausführungsform bestimmt der Prozess 1000, dass der Sub-Puffer für eine CPU kreiert wird. Wenn die Recheneinheit unterschiedlich ist, kopiert der Prozess 1000 die Daten auf den privaten Speicher der Recheneinheit, welcher mit dem Sub-Puffer assoziiert ist. Zum Beispiel und in einer Ausführungsform, wenn die Recheneinheit eine GPU ist und die Recheneinheit, welche mit dem Puffer assoziiert ist, eine CPU ist, würde der Prozess 1000 die Daten, welche mit dem Sub-Puffer assoziiert sind, in den Speicher der GPU kopieren. Zurück zu 4 würde der Prozess 1000 die Daten von einem der Sub-Puffer (z. B. Sub-Puffer 410A) in den Speicher der GPU (z. B. privater Speicher 404A der Recheneinheit 402A) kopieren. Wenn die Recheneinheiten die gleichen für Sub-Puffer und den Puffer sind, verwendet der Prozess 1000 die Zeiger, um auf die Daten im Sub-Puffer bei Block 1006 zuzugreifen. Zum Beispiel und in einer Ausführungsform würde der Prozess 1000 den Zeiger 412A verwenden, um auf die Daten im Sub-Puffer 410A zuzugreifen, wie beschrieben in 4 oben. Weil der Prozess 1000 Zeiger verwendet zum Zugreifen auf die Daten und es nicht benötigt die Daten zu aktualisieren, welche geändert werden, endet der Prozess 1000 bei 1006.
  • Andererseits, wenn der Prozess 1000 die Daten in den privaten Speicher der Recheneinheit, welche mit dem Sub-Puffer assoziiert ist, kopiert hat, verfolgt der Prozess 1000 die Aktualisierungen der Daten in dem privaten Speicher jener Recheneinheit. Zum Beispiel und in einer Ausführungsform bei Block 1010. Basierend auf den verfolgten Aktualisierungen sendet der Prozess 1000 die Aktualisierungen an den übergeordneten Puffer bei Block 1012. Während in einer Ausführungsform der Prozess 1000 die Aktualisierungen sofort sendet, sendet in einer alternativen Ausführungsform der Prozess 1000 die Aktualisierungen in einer unterschiedlichen Art (z. B. sendet periodisch Aktualisierungen, sendet automatisch Aktualisierungen usw.).
  • Zusätzlich zum Kreieren, Verwenden und/oder Verwalten von Sub-Puffern für Recheneinheiten kann das System 100 Ereignisse verwenden zum Synchronisieren von Operationen eines Kontexts wie oben beschrieben mit Verweis auf 8 und 9. In einer Ausführungsform enthält ein Ereignisobjekt jenen Zustand einer Operation, wie beispielsweise einen Befehl. In dieser Ausführungsform können diese Objekte verwendet werden zum Synchronisieren von Operationen in einem Kontext. Zusätzlich kann das System 100 Ereigniswartelisten verwenden, um zu steuern, wann ein spezieller Befehl die Ausführung beginnt. Eine Ereigniswarteliste ist eine Liste von Ereignisobjekten.
  • 11 ist ein Flussdiagramm, welches eine Ausführungsform von einem Prozess 1100 zeigt, um Rückrufe, welche mit Ereignissen assoziiert sind, welche interne und externe Abhängigkeiten aufweisen, ausführt. In einer Ausführungsform wird ein Rückruf verwendet zum Berichten von Ereignissen (z. B. Fehlern usw.), welche innerhalb eines Kontexts auftreten. Wie oben beschrieben mit Verweis auf 8 wird ein Kontext kreiert mit einer oder mehreren Recheneinheiten und wird verwendet zum Verwalten von Objekten, wie beispielsweise Befehlswarteschlangen, Speicher-, Programm-, Kernelobjekten und zur Ausführung von Kernels auf einer oder mehreren Recheneinheiten, welche in dem Kontext spezifiziert sind.
  • Der beispielhafte Prozess 1100 kann ausgeführt werden durch eine Verarbeitungslogik, welche Hardware (Schaltungen, dedizierte Logik, usw.), Software (wie beispielsweise auf einer dedizierten Maschine laufend) oder eine Kombination von beiden aufweisen kann. Zum Beispiel kann der Prozess 1100 ausgeführt werden in Übereinstimmung mit dem System 100 von 1 in einem Datenverarbeitungssystem, welches durch die Hosting-Systeme 101 gehostet wird. Das Datenverarbeitungssystem kann einen Hostprozessor, welcher eine Plattformschicht hostet, wie beispielweise die Rechenplattformschicht 141 von 1, und mehrere physische Computervorrichtungen, welche an den Hostprozessor angefügt sind, wie beispielsweise CPUs 117 und GPUs 115 von 1 umfassen.
  • Der Prozess 1100 registriert ein Ereignis, um einen Rückruf mit einem Kontext auszuführen, wo das Ereignis externe Abhängigkeiten aufweist, bei Block 1102. In einer Ausführungsform kann ein Ereignis interne, externe und/oder keine Abhängigkeiten aufweisen. Ein Ereignis mit einer internen Abhängigkeit bedeutet, dass, bevor der Rückruf, welcher mit dem Ereignis assoziiert ist, ausgeführt werden kann, die interne Abhängigkeit aufzulösen ist. In einer Ausführungsform ist die interne Abhängigkeit ein System-erkanntes Ereignis, wie beispielsweise ein Kernelausführungsbefehl oder Verwaltungsbefehle (z. B. Lesen, Schreiben, Abbilden, Kopieren von Befehlen auf Speicherobjekte). Eine externe Abhängigkeit ist ein nutzerdefiniertes Ereignis und diese externe Abhängigkeit sollte aufgelöst werden, bevor der Rückruf ausgeführt werden kann. Zum Beispiel und in einer Ausführungsform kann ein nutzerdefiniertes Ereignis es Anwendungen erlauben, Befehle in einer Warteschlange einzureihen, welche auf das Enden des Nutzerereignisses warten, bevor der eingereihte Befehl durch die entsprechende Recheneinheit ausgeführt wird. In einer anderen Ausführungsform kann ein Nutzerereignisobjekt verwendet werden eine anwendungsspezifische Fehlerbedingung zu melden. In einer Ausführungsform können Ereignisabhängigkeiten in einer Ereigniswarteliste gespeichert werden.
  • Bei Block 1104 empfingt der Prozess 1100 eine Meldung, dass das registrierte Ereignis aufgetreten ist. In einer Ausführungsform empfängt der Prozess 1100 die Benachrichtigung des Ereignisses durch Aufrufen einer Funktion, welche auf Ereignisse wartet. Bei Block 1106 bestimmt der Prozess 1100, ob das registrierte Ereignis irgendwelche nicht aufgelösten internen Ereignisse aufweist. Zum Beispiel und in einer Ausführungsform bestimmt der Prozess 1100, ob eine Ereigniswarteliste, welche mit dem registrierten Ereignis assoziiert ist, irgendwelche internen Abhängigkeiten aufweist. Wenn es irgendwelche internen Abhängigkeiten gibt, verzögert der Prozess 1100 die Ausführung des Rückrufs bei 1112. In einer Ausführungsform verzögert der Prozess 1100 die Ausführung bis die internen Abhängigkeiten aufgelöst werden. Zum Beispiel in einer Ausführungsform kann das Auflösen einer Abhängigkeit Warten bis ein Befehl, welcher mit einem abhängigen Ereignis assoziiert ist, fertiggestellt ist, umfassen.
  • Wenn es keine internen Abhängigkeiten für das registrierte Ereignis gibt, bestimmt der Prozess 1100, ob das registrierte Ereignis irgendwelche externen Abhängigkeiten aufweist, bei Block 1108. Zum Beispiel und in einer Ausführungsform bestimmt der Prozess 1100, ob eine Ereigniswarteliste, welche mit dem registrierten Ereignis assoziiert ist, irgendwelche externen Abhängigkeiten aufweist. Wenn es irgendwelche externen Abhängigkeiten gibt, verzögert der Prozess 1100 die Ausführung des Rückrufs bei Block 1112. In einer Ausführungsform verzögert der Prozess 1100 die Ausführung bis die externen Abhängigkeiten aufgelöst werden. Zum Beispiel und in einer Ausführungsform kann das Auflösen einer Abhängigkeit Warten bis ein Befehl, welcher mit einem abhängigen Ereignis assoziiert ist, fertiggestellt ist, umfassen.
  • 12 ist ein Blockdiagramm, welches eine Ausführungsform einer Kette von Ereignissen 1202A–D mit internen und externen Abhängigkeiten zeigt. In 12 weist das Ereignis 1202A eine Kette von Abhängigkeiten einschließlich dreier interner Ereignisse 1202B–D und ein externes Ereignis, Nutzerereignis 1204 auf. Zum Beispiel und in einer Ausführungsform hängt das Ereignis 1202A von dem Ereignis 1202B ab, welches wiederum abhängig ist von dem Ereignis 1202C, welches wiederum abhängig ist von dem Ereignis 1202D, welches wiederum abhängig ist von dem Nutzerereignis 1204. In dieser Ausführungsform wartet das Ereignis 1202D, dass das Nutzerereignis 1204 aufgelöst wird, das Ereignis 1202C wartet, dass die Ereignisse 1202D und 1204 aufgelöst werden, das Ereignis 1202B wartet, dass die Ereignisse 1202C–D und 1204 aufgelöst werden, und das Ereignis 1202B wartet, dass die Ereignisse 1202B–D und 1204 aufgelöst werden.
  • 13 ist ein Beispielquellcode, welcher ein Beispiel eines Rechenprogrammquellcodes für eine Rechenprogramm-ausführbare Datei zeigt, welche in mehreren physischen Computervorrichtungen auszuführen ist. Das Beispiel 1300 kann eine API-Funktion mit Argumenten einschließlich Variablen 1301 und Streams (oder Rechenspeicherobjekten) 1303 repräsentieren. Das Beispiel 1300 kann basieren auf einer Programmiersprache für eine Parallelrechenumgebung, wie beispielsweise System 131 von 1. In einer Ausführungsform kann die parallele Programmiersprache spezifiziert sein gemäß ANSI (American National Standards Institute) C Standard mit zusätzlichen Erweiterungen und Beschränkungen, welche gestaltet sind zum Implementieren einer oder mehrerer der Ausführungsformen, welche hierin beschrieben werden. Die Erweiterungen können einen Funktionsqualifizierer, wie Qualifizierer 1305, umfassen, um eine Rechenkernelfunktion zu spezifizieren, welche in einer Computervorrichtung auszuführen ist. Eine Rechenkernelfunktion kann nicht durch andere Rechenkernelfunktionen aufgerufen werden. In einer Ausführungsform kann eine Rechenkernelfunktion durch eine Hostfunktion in der parallelen Programmiersprache aufgerufen werden. Eine Hostfunktion kann eine reguläre ANSI C Funktion sein. Eine Hostfunktion kann ausgeführt werden in einem Hostprozessor getrennt von der Computervorrichtung, welche eine Rechenkernelfunktion ausführt. In einer Ausführungsform können die Erweiterungen einen lokalen Qualifizierer zum Beschreiben von Variablen umfassen, welche in einem lokalen Speicher zugeordnet werden müssen, welcher mit einer Computervorrichtung assoziiert ist, welche durch alle Threads einer Threadgruppe gemeinsam zu nutzen ist. Der lokale Qualifizierer kann deklariert werden innerhalb einer Rechenkernelfunktion. Die Beschränkungen der parallelen Programmiersprache können umgesetzt werden während der Compilerzeit oder Laufzeit, um Fehlerbedingungen zu erzeugen, wie beispielsweise das Ausgeben von Fehlernachrichten oder das Verlassen einer Ausführung, wenn die Beschränkungen verletzt werden.
  • Die 14A–14C umfassen einen Beispielquellcode, welcher ein Beispiel zum Einrichten einer logischen Computervorrichtung zum Ausführen einer der mehreren ausführbaren Dateien in mehreren physischen Computervorrichtungen durch Aufrufen von APIs zeigt. Beispiele 1400A–14000 können ausgeführt werden durch eine Anwendung, welche in einem Hostsystem ausgeführt wird, welches mit mehreren physischen Computervorrichtungen angefügt ist, wie beispielsweise Hosting-Systeme 101 von 1. Die Beispiele 1400A–14000 können eine Hostfunktion einer parallelen Programmiersprache spezifizieren. Die Verarbeitungsoperationen in den Beispielen 1400A–14000 können ausgeführt werden als API-Aufrufe durch einen Prozess, wie beispielsweise Prozess 800 von 8 und/oder Prozess 900 von 9. Die Verarbeitungsoperationen zum Kreieren eines Kontextobjektes von einer Computervorrichtung, einer Computervorrichtungsgruppe oder einer logischen Computervorrichtung 1401 können ausgeführt werden durch die Verarbeitungslogik von Prozess 800 bei Block 811 von 8. Die Verarbeitungsoperationen zum Zuordnen von Eingabe-/Ausgabe-Bildspeicherobjekten (z. B. Rechenspeicherobjekte) können ausgeführt werden durch die Verarbeitungslogik von Prozess 900 bei Block 901 von 9.
  • Sich nun zuwendend zu 14B, können die Verarbeitungsoperationen zum Zuordnen und Laden von Feldspeicherobjekten 1403b ausgeführt werden durch die Verarbeitungslogik vom Prozess 900 bei Block 901 von 9. Die Verarbeitungsoperation zum Kreieren eines Rechenprogrammobjekts 1405 kann ausgeführt werden durch die Verarbeitungslogik von Prozess 900 bei Block 903 von 9. Die Verarbeitungsoperation 1407 kann eine Rechenprogrammquelle, wie beispielsweise das Beispiel 900 von 9, in das Rechenprogrammobjekt laden, welches kreiert wurde. Die Verarbeitungsoperation 1409 kann explizit eine Rechenprogramm-ausführbare Datei aus der geladenen Rechenprogrammquelle bilden. In einer Ausführungsform kann die Verarbeitungsoperation 1409 eine bereits gebildete Rechenprogramm-ausführbare Datei in das kreierte Rechenprogrammobjekt laden. Anschließend kann die Verarbeitungsoperation 1411 ein Rechenkernelobjekt, welches auf die gebildete Rechenprogrammausführbare Datei zeigt, zum Planen einer Ausführung auf einer Computervorrichtung kreieren.
  • Sich nun zuwendend zu 14C, in einer Ausführungsform, kann die Verarbeitungsoperation 1413 Variablen und Rechenspeicherobjekte als Funktionsargumente für das kreierte Rechenkernelobjekt anbringen. Die Verarbeitungsoperation 1413 kann ausgeführt werden durch die Verarbeitungslogik von Prozess 900 bei Block 905 von 9. Die Verarbeitungsoperation 1415 kann das kreierte Rechenkernelobjekt ausführen. In einer Ausführungsform kann die Verarbeitungsoperation 1415 ausgeführt werden durch die Verarbeitungslogik von Prozess 900 bei Block 911 von 9. Die Verarbeitungsoperation 1415 kann eine Ausführungswarteschlange veranlassen aktualisiert zu werden mit einer Rechenkernelausführungsinstanz, welche dem kreierten Rechenkernelobjekt entspricht. Die Verarbeitungsoperation 1417 kann synchron auf die Fertigstellung des Ausführens des kreierten Rechenkernelobjekts warten. In einer Ausführungsform kann die Verarbeitungsoperation 1419 ein Ergebnis von dem Ausführen des Rechenkernelobjekts abrufen. Anschließend können die Verarbeitungsoperationen 1191 zugeordnete Ressourcen zum Ausführen des Rechenkernelobjekts bereinigen, wie beispielsweise ein Ereignisobjekt, das kreierte Rechenkernelobjekt und die zugeordneten Speicher. In einer Ausführungsform kann die Verarbeitungsoperation 1417 asynchron ausgeführt werden basierend darauf, ob ein Kernelereignisobjekt gesetzt wurde. Die Verarbeitungsoperation 1417 kann ausgeführt werden durch den Prozess 900 bei Block 919 von 9.
  • 15 zeigt ein Beispiel eines Computersystems 1500, welches verwendet werden kann mit einer Ausführungsform der vorliegenden Erfindung. Zum Beispiel kann das System 1500 implementiert werden als ein Teil des Systems, welches in 1 gezeigt ist. Es sollte beachtet werden, dass während 15 verschiedene Komponenten eines Computersystems zeigt, nicht irgendeine spezielle Architektur oder Art von Verbinden der Komponenten repräsentiert werden soll, weil solche Details nicht von Bedeutung für die vorliegende Erfindung sind. Es wird auch klar sein, dass Netzwerkcomputer und andere Datenverarbeitungssysteme (z. B. handgehaltene Computer, persönliche digitale Assistenten (PDAs), Mobiltelefone, Entertainmentsysteme, verbraucherelektronische Vorrichtungen, usw.), welche weniger Komponenten oder vielleicht mehr Komponenten aufweisen, auch verwendet werden können, um eine oder mehrere Ausführungsformen der vorliegenden Erfindung zu implementieren.
  • Wie in 15 gezeigt umfasst das Computersystem 1500, welches eine Art von einem Datenverarbeitungssystem ist, einen Bus 1503, welcher an einen Mikroprozessor(en) 1505 gekoppelt ist, wie beispielsweise CPUs und/oder GPUs, einen ROM (Nur-Lese-Speicher) 1507, flüchtigen RAM 1509 und einen nichtflüchtigen Speicher 1911. Der Mikroprozessor 1505 kann die Anweisungen aus den Speichern 1507, 1509, 1911 abrufen und die Anweisungen unter Verwendung des Cache 1521 ausführen, um Operationen wie oben beschrieben auszuführen. Der Bus 1503 verbindet diese verschiedenen Komponenten miteinander und verbindet auch diese Komponenten 1505, 1507, 1509 und 1911 mit einer Anzeigesteuereinheit und einer Anzeigevorrichtung 1913 und mit peripheren Vorrichtungen, wie beispielsweise Eingabe-/Ausgabe (I/O) Vorrichtungen, welche Mäuse, Tastaturen, Modems, Netzwerkschnittstellen, Drucker und andere Vorrichtungen sein können, welche in der Technik wohlbekannt sind. Typischerweise werden die Eingabe-/Ausgabevorrichtungen 915 mit dem System über Eingabe-/Ausgabesteuereinheiten 1917 gekoppelt. Der flüchtige RAM (Speicher mit wahlfreiem Zugriff) 1509 ist typischerweise implementiert als dynamischer RAM (DRAM), welcher kontinuierliche Leistung erfordert, um die Daten in dem Speicher zu aktualisieren und aufrechtzuerhalten. Die Anzeigesteuereinheit, welche mit einer Anzeigevorrichtung 1913 gekoppelt ist, kann optional eine oder mehrere GPUs umfassen, um Anzeigedaten zu verarbeiten. Optional kann der GPU-Speicher 1919 bereitgestellt werden zum Unterstützen der GPUs, welche in der Anzeigevorrichtung 1913 umfasst sind.
  • Der Massenspeicher 1911 ist typischerweise ein magnetisches Festplattenlaufwerk oder ein magnetisches optisches Laufwerk oder ein optisches Laufwerk oder ein DVD-RAM oder ein Flash-Speicher oder andere Typen von Speichersystemen, welche Daten aufrechterhalten (z. B. große Mengen von Daten), selbst nachdem Leistung von dem System entfernt wird. Typischerweise wird der Massenspeicher 1911 auch ein Speicher mit wahlfreiem Zugriff sein, obwohl dies nicht erforderlich ist. Während 15 zeigt, dass der Massenspeicher 1911 eine lokale Vorrichtung ist, welche direkt mit dem Rest der Komponenten in dem Datenverarbeitungssystem gekoppelt ist, wird es klar sein, dass die vorliegende Erfindung auch nicht-flüchtigen Speicher verwenden kann, welcher fern von dem System ist, wie beispielsweise eine Netzwerkspeichervorrichtung, welche mit dem Datenverarbeitungssystem über eine Netzwerkschnittstelle, wie beispielsweise ein Modern oder eine Ethernet-Schnittstelle oder eine Drahtlosnetzwerkschnittstelle gekoppelt ist. Der Bus 1503 kann einen oder mehrere Busse, welche miteinander über verschiedene Brücken, Steuereinheiten und/oder Adapter verbunden sind, umfassen, wie es in der Technik wohlbekannt ist.
  • Teile von dem, was oben beschrieben wurde, kann mit logischen Schaltungen implementiert werden, wie beispielsweise einer dedizierten logischen Schaltung oder mit einem Mikrocontroller oder anderer Form von Verarbeitungskern, welcher Programmcodeanweisungen ausführt. Daher können Prozesse, welche durch die obige Diskussion gelehrt werden, mit Programmcode ausgeführt werden, wie beispielsweise maschinenausführbaren Anweisungen, welche eine Maschine veranlassen, welche diese Anweisungen ausführt, bestimmte Funktionen auszuführen. In diesem Kontext kann eine ”Maschine” eine Maschine sein, welche Zwischenform-(oder ”abstrakte”) Anweisungen in prozessorspezifische Anweisungen konvertieren (z. B. eine abstrakte Ausführungsumgebung wie beispielsweise eine ”virtuelle Maschine” (z. B. eine Java Virtual Machine), einen Interpreter, eine Common Language Runtime, eine High Level Language Virtual Machine, usw.) und/oder elektronische Schaltungen, welche auf einem Halbleiterchip angeordnet sind, (z. B. ”logische Schaltung”, welche mit Transistoren implementiert wird), welche gestaltet sind zum Ausführen von Anweisungen, wie beispielsweise einen Universalprozessor und/oder einen Spezialzweckprozessor. Prozesse, welche durch die obige Diskussion gelehrt werden, können auch ausgeführt werden durch (in der Alternative zu einer Maschine oder einer Kombination mit einer Maschine) elektronische Schaltungen, welche gestaltet sind zum Ausführen der Prozesse (oder einen Teil davon) ohne die Ausführung von Programmcode.
  • Ein Artikel einer Herstellung kann verwendet werden zum Speichern von Programmcode, z. B. einschließlich mehreren Tokens. Ein Artikel einer Herstellung, welcher Programmcode speichert, kann verkörpert sein als, aber ist nicht beschränkt auf, einen oder mehrere Speicher (z. B. einen oder mehrere Flash-Speicher, Speicher mit wahlfreiem Zugriff (statisch, dynamisch oder andere)), optische Platten, CD-ROMS, DVD-ROMS, EPROMs, EEPROMs, magnetische oder optische Karten oder andere Typen von maschinenlesbaren Medien, welche geeignet sind zum Speichern von elektronischen Anweisungen. Der Programmcode kann auch heruntergeladen werden von einem fernen Computer (z. B. einem Server) auf einen anfragenden Computer (z. B. einen Client) durch Datensignale, welche in einem Übertragungsmedium verkörpert sind (z. B. unter Verwendung einer Kommunikationsverbindung (z. B. einer Netzwerkverbindung)).
  • Die vorangehenden detaillierten Beschreibungen werden hinsichtlich Algorithmen und symbolischer Repräsentierungen von Operationen auf Datenbits innerhalb eines Computerspeichers präsentiert. Diese algorithmischen Beschreibungen und Repräsentierungen sind Werkzeuge, welche verwendet werden durch den Fachmann, welcher die Technik verarbeitet, um möglichst effektiv die Substanz ihrer Arbeit anderen Fachleuten zu übermitteln. Ein Algorithmus ist hier und im Allgemeinen entworfen eine selbstkonsistente Sequenz von Operationen zu sein, welche zu einem gewünschten Ergebnis führen. Die Operationen sind jene, welche physische Manipulationen von physischen Quantitäten erfordern. Normalerweise, jedoch nicht notwendigerweise, nehmen diese Quantitäten die Form von elektrischen oder magnetischen Signalen an, welche fähig sind gespeichert, übertragen, kombiniert, verglichen oder anderweitig manipuliert zu werden. Es hat sich beizeiten als geeignet erwiesen, prinzipiell aus Gründen von allgemeinem Gebrauch, auf diese Signale als Bits, Werte, Elemente, Symbole, Buchstaben, Ausdrücke, Zahlen oder Ähnliches zu verweisen.
  • Es sollte jedoch beachtet werden, dass alle dieser und ähnlicher Ausdrücke mit den geeigneten physischen Quantitäten zu assoziieren sind und lediglich geeignete Bezeichnungen sind, welche auf diese Quantitäten angewendet werden. Wenn nicht spezifisch anders als offensichtlich aus der obigen Diskussion angegeben, ist es klar, dass durch die Beschreibung hinweg, Diskussionen, welche Ausdrücke wie beispielsweise ”Verarbeiten” oder ”Rechnen” oder ”Berechnen” oder ”Bestimmen” oder ”Anzeigen” oder ”Kopieren” oder ”Verfolgen” oder ”Senden” oder Ähnliches sich auf die Handlung und Prozesse eines Computersystems beziehen oder einer ähnlichen elektronischen Computervorrichtung, welche Daten, welche als physische (elektronische) Quantitäten innerhalb der Register und der Speicher des Computersystems repräsentiert sind, manipulieren und in andere Daten transformieren, welche ähnlich repräsentiert sind als physische Quantitäten innerhalb der Speicher oder Register des Computersystems oder anderer solcher Informationsspeicher, Übertragungs- oder Anzeigevorrichtungen.
  • Die vorliegende Erfindung bezieht sich auch auf eine Vorrichtung zum Ausführen der hierin beschriebenen Operationen. Diese Vorrichtung kann speziell konstruiert sein für den erforderlichen Zweck oder sie kann einen Universalcomputer aufweisen, welcher selektiv aktiviert wird oder rekonfiguriert wird durch ein Computerprogramm, welches in dem Computer gespeichert ist. Solch ein Computerprogramm kann gespeichert werden in einem computerlesbaren Speichermedium, wie beispielsweise aber nicht beschränkt auf irgendeinen Typ von Platte einschließlich Disketten, optischen Platten, CD-ROMS und magnetisch-optischen Platten, Nur-Lese-Speichern (ROMs), RAMs, EPROMs, EEPROMs, magnetischen oder optischen Karten oder irgendeinem Typ von Medien, welche geeignet sind zum Speichern von elektronischen Anweisungen, und von denen jede an einen Computersystembus gekoppelt ist.
  • Die Prozesse und Anzeigen, welche hierin präsentiert werden, beziehen sich nicht inhärent auf irgendeinen speziellen Computer oder eine andere Vorrichtung. Verschiedene Universalsysteme können verwendet werden mit Programmen gemäß den Lehren hierin, oder es kann sich als geeignet erweisen eine spezialisiertere Vorrichtung zum Ausführen der beschriebenen Operationen zu konstruieren. Die erforderliche Struktur für eine Vielzahl von diesen Systemen wird aus der Beschreibung unten evident werden. Zusätzlich wird die vorliegende Erfindung nicht mit Verweis auf irgendeine spezielle Programmiersprache beschrieben. Es ist klar, dass eine Vielzahl von Programmiersprachen zum Implementieren der Lehren der hierin beschriebenen Erfindung verwendet werden kann.
  • Die vorangehende Diskussion beschreibt lediglich einige beispielhafte Ausführungsformen der vorliegenden Erfindung. Ein Fachmann wird sogleich aus solch einer Diskussion, den begleitenden Zeichnungen und den Ansprüchen erkennen, dass verschiedene Modifikationen gemacht werden können, ohne von dem Geist und dem Geltungsbereich der Erfindung abzuweichen.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 7015913 [0027]
    • US 6970206 [0027]
  • Zitierte Nicht-Patentliteratur
    • IEEE754-2008 [0049]

Claims (16)

  1. Computerisiertes Verfahren zum Verwalten einer Mehrzahl von Sub-Puffern, welche mit einem übergeordneten Puffer assoziiert sind, in einer heterogenen Rechenumgebung, wobei das Verfahren aufweist: für jeden Sub-Puffer in der Mehrzahl von Sub-Puffern, Kreieren jenes Sub-Puffers aus einer Mehrzahl von heterogenen Recheneinheiten, wobei der kreierte Sub-Puffer mit dem übergeordneten Puffer assoziiert ist.
  2. Computerisiertes Verfahren gemäß Anspruch 1, weiterhin aufweisend: wenn eine Recheneinheit der Mehrzahl von heterogenen Recheneinheiten, welche mit jenem Sub-Puffer assoziiert sind, nicht eine gleiche Recheneinheit ist, welche mit dem übergeordneten Puffer assoziiert ist, Kopieren der Daten in jenem Sub-Puffer in einen privaten Speicher für die Recheneinheit, welche jenem Sub-Puffer entspricht, Verfolgen von Aktualisierungen der Daten in jenem Sub-Puffer, und Senden der Aktualisierungen der Daten an den übergeordneten Puffer.
  3. Computerisiertes Verfahren gemäß Anspruch 1, weiterhin aufweisend: wenn die Recheneinheit, welche mit jenem Sub-Puffer assoziiert ist, die gleiche Recheneinheit ist, welche mit dem übergeordneten Puffer assoziiert ist, Kreieren eines Zeigers auf jenen Sub-Puffer in dem Puffer.
  4. Computerisiertes Verfahren gemäß Anspruch 1, wobei die Mehrzahl von heterogenen Recheneinheiten eine Zentralverarbeitungseinheit und eine Graphikverarbeitungseinheit umfasst.
  5. Computerisiertes Verfahren gemäß Anspruch 1, wobei der Zeiger ein Offset in den übergeordneten Puffer ist.
  6. Computerisiertes Verfahren gemäß Anspruch 1, wobei der übergeordnete Puffer ausgewählt wird aus einer Gruppe bestehend aus einem eindimensionalen Puffer, einem zweidimensionalen Bild und einem dreidimensionalen Bild.
  7. Computerisiertes Verfahren gemäß Anspruch 1, wobei der übergeordnete Puffer aus einem Systemspeicher konstruiert wird.
  8. Nicht-transitorisches maschinenlesbares Medium, welches ausführbare Anweisungen aufweist, um eine oder mehrere Verarbeitungseinheiten zu veranlassen, ein Verfahren zum Verwalten einer Mehrzahl von Sub-Puffern, welche mit einem übergeordneten Puffer in einer heterogenen Rechenumgebung assoziiert sind, auszuführen, wobei das Verfahren aufweist: für jeden Sub-Puffer in der Mehrzahl von Sub-Puffern, Kreieren jenes Sub-Puffers für eine aus einer Mehrzahl von heterogenen Recheneinheiten, wobei der kreierte Sub-Puffer mit dem übergeordneten Puffer assoziiert ist.
  9. Nicht-transitorisches maschinenlesbares Medium gemäß Anspruch 8, wobei das Verfahren weiterhin aufweist: wenn eine Recheneinheit aus der Mehrzahl von heterogenen Recheneinheiten, welche mit jenem Sub-Puffer assoziiert ist, nicht eine gleiche Recheneinheit ist, welche mit dem überordneten Puffer assoziiert ist, Kopieren der Daten in jenem Sub-Puffer in einen privaten Speicher für die Recheneinheit, welche jenem Sub-Puffer entspricht, Verfolgen von Aktualisierungen der Daten in jenem Sub-Puffer, und Senden der Aktualisierungen an den übergeordneten Puffer.
  10. Nicht-transitorisches maschinenlesbares Medium gemäß Anspruch 8, wobei das Verfahren weiterhin aufweist: wenn die Recheneinheit, welche mit jenem Sub-Puffer assoziiert ist, die gleiche Recheneinheit ist, welche mit dem übergeordneten Puffer assoziiert ist, Kreieren eines Zeigers auf jenen Sub-Puffer in dem Puffer.
  11. Nicht-transitorisches maschinenlesbares Medium gemäß Anspruch 8, wobei die Mehrzahl von heterogenen Recheneinheiten eine Zentralverarbeitungseinheit und eine Graphikverarbeitungseinheit umfasst.
  12. Nicht-transitorisches maschinenlesbares Medium gemäß Anspruch 8, wobei der übergeordnete Puffer ausgewählt wird aus einer Gruppe bestehend aus einem eindimensionalen Puffer, einem zweidimensionalen Bild und einem dreidimensionalen Bild.
  13. Vorrichtung zum Verwalten einer Mehrzahl von Sub-Puffern, welche mit einem übergeordneten Puffer assoziiert sind, in einer heterogenen Rechenumgebung, wobei die Vorrichtung aufweist: für jeden Sub-Puffer in der Mehrzahl von Sub-Puffern, Mittel zum Kreieren jenes Sub-Puffers für eine aus einer Mehrzahl von heterogenen Recheneinheiten, wobei der kreierte Sub-Puffer mit dem übergeordneten Puffer assoziiert ist; und Mittel zum Lesen der Daten, welche in jenem Sub-Puffer gespeichert werden.
  14. Vorrichtung gemäß Anspruch 13, weiterhin aufweisend: wenn eine Recheneinheit aus der Mehrzahl von heterogenen Recheneinheiten, welche mit jenem Sub-Puffer assoziiert ist, nicht eine gleiche Recheneinheit ist, welche mit dem überordneten Puffer assoziiert ist, Mittel zum Kopieren der Daten in jenem Sub-Puffer in einen privaten Speicher für die Recheneinheit, welche jenem Sub-Puffer entspricht, Mittel zum Verfolgen von Aktualisierungen der Daten in jenem Sub-Puffer, und Mittel zum Senden der Aktualisierungen an den übergeordneten Puffer.
  15. Vorrichtung gemäß Anspruch 13, weiterhin aufweisend: wenn die Recheneinheit, welche mit jenem Sub-Puffer assoziiert ist, die gleiche Recheneinheit ist, welche mit dem übergeordneten Puffer assoziiert ist, Mittel zum Kreieren eines Zeigers auf jenen Sub-Puffer in dem Puffer.
  16. Vorrichtung gemäß Anspruch 13, wobei die Mehrzahl von heterogenen Recheneinheiten eine Zentralverarbeitungseinheit und eine Graphikverarbeitungseinheit umfasst.
DE112011101725T 2010-05-20 2011-04-20 Sub-Puffer-Objekte Ceased DE112011101725T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US34686610P 2010-05-20 2010-05-20
US61/346,866 2010-05-20
US12/892,834 US8723877B2 (en) 2010-05-20 2010-09-28 Subbuffer objects
US12/892,834 2010-09-28
PCT/US2011/033282 WO2011146197A1 (en) 2010-05-20 2011-04-20 Subbuffer objects

Publications (1)

Publication Number Publication Date
DE112011101725T5 true DE112011101725T5 (de) 2013-04-25

Family

ID=44260533

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112011101725T Ceased DE112011101725T5 (de) 2010-05-20 2011-04-20 Sub-Puffer-Objekte

Country Status (12)

Country Link
US (3) US8723877B2 (de)
EP (1) EP2572276B1 (de)
JP (2) JP5583844B2 (de)
KR (2) KR101477882B1 (de)
CN (1) CN102870096B (de)
AU (1) AU2011256745B2 (de)
BR (1) BR112012027950B1 (de)
CA (1) CA2795365C (de)
DE (1) DE112011101725T5 (de)
GB (1) GB2480536B (de)
MX (1) MX2012012534A (de)
WO (1) WO2011146197A1 (de)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8669990B2 (en) 2009-12-31 2014-03-11 Intel Corporation Sharing resources between a CPU and GPU
US8723877B2 (en) 2010-05-20 2014-05-13 Apple Inc. Subbuffer objects
US9552299B2 (en) 2010-06-11 2017-01-24 California Institute Of Technology Systems and methods for rapid processing and storage of data
US8752018B2 (en) 2011-06-21 2014-06-10 Nvidia Corporation Emitting coherent output from multiple threads for printf
US20130141443A1 (en) * 2011-12-01 2013-06-06 Michael L. Schmit Software libraries for heterogeneous parallel processing platforms
US9864635B2 (en) * 2012-01-06 2018-01-09 Intel Corporation Reducing the number of read/write operations performed by a CPU to duplicate source data to enable parallel processing on the source data
US9996394B2 (en) * 2012-03-01 2018-06-12 Microsoft Technology Licensing, Llc Scheduling accelerator tasks on accelerators using graphs
US9864638B2 (en) * 2012-06-22 2018-01-09 Intel Corporation Techniques for accessing a graphical processing unit memory by an application
US20140101761A1 (en) * 2012-10-09 2014-04-10 James Harlacher Systems and methods for capturing, replaying, or analyzing time-series data
US9424079B2 (en) 2013-06-27 2016-08-23 Microsoft Technology Licensing, Llc Iteration support in a heterogeneous dataflow engine
US9286328B2 (en) * 2013-07-19 2016-03-15 International Business Machines Corporation Producing an image copy of a database object based on information within database buffer pools
US9703696B1 (en) * 2013-09-11 2017-07-11 Altera Corporation Guided memory buffer allocation
US10564949B2 (en) * 2013-09-20 2020-02-18 Reservoir Labs, Inc. System and method for generation of event driven, tuple-space based programs
US11789769B2 (en) 2013-09-20 2023-10-17 Qualcomm Incorporated System and method for generation of event driven, tuple-space based programs
US20150091912A1 (en) * 2013-09-27 2015-04-02 Nvidia Corporation Independent memory heaps for scalable link interface technology
US9411652B2 (en) * 2014-08-22 2016-08-09 Advanced Micro Devices, Inc. Runtime for automatically load-balancing and synchronizing heterogeneous computer systems with scoped synchronization
CN104714850B (zh) * 2015-03-02 2016-03-30 心医国际数字医疗系统(大连)有限公司 一种基于opencl的异构共同计算均衡方法
US9916634B2 (en) * 2015-06-12 2018-03-13 Intel Corporation Facilitating efficient graphics command generation and execution for improved graphics performance at computing devices
GB2540940B (en) * 2015-07-31 2018-01-03 Advanced Risc Mach Ltd An apparatus and method for transferring a plurality of data structures between memory and one or more vectors of data elements stored in a register bank
EP3188013B1 (de) * 2015-12-29 2022-07-13 Dassault Systèmes Verwaltung mehrerer grafikkarten
WO2017126924A1 (ko) * 2016-01-19 2017-07-27 서울대학교 산학협력단 이종 시스템에서의 데이터 분배 기법
US10152243B2 (en) * 2016-09-15 2018-12-11 Qualcomm Incorporated Managing data flow in heterogeneous computing
KR20180044635A (ko) 2016-10-24 2018-05-03 삼성전자주식회사 저장 시스템 및 그것의 동작 방법
CN110121703B (zh) * 2016-12-28 2023-08-01 英特尔公司 用于向量通信的系统和方法
KR102066212B1 (ko) * 2017-01-19 2020-01-14 서울대학교산학협력단 병렬 시스템에서의 데이터 복사 방법 및 이를 수행하기 위한 병렬 시스템
JP6932755B2 (ja) * 2018-10-19 2021-09-08 イーソル株式会社 オペレーティングシステム及びメモリ割り当て方法
JP2024006858A (ja) 2022-07-04 2024-01-17 リベラルロジック株式会社 プログラム、情報処理システム及び情報処理方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6970206B1 (en) 2000-04-20 2005-11-29 Ati International Srl Method for deinterlacing interlaced video by a graphics processor
US7015913B1 (en) 2003-06-27 2006-03-21 Nvidia Corporation Method and apparatus for multithreaded processing of data in a programmable graphics processor

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2902092A (en) * 1991-10-24 1993-05-21 Intel Corporation Data processing system
US6115761A (en) 1997-05-30 2000-09-05 Lsi Logic Corporation First-In-First-Out (FIFO) memories having dual descriptors and credit passing for efficient access in a multi-processor system environment
US6754887B1 (en) * 1999-10-22 2004-06-22 International Business Machines Corporation Methods for implementing virtual bases with fixed offsets in object oriented applications
WO2001048620A1 (en) 1999-12-29 2001-07-05 The Johns Hopkins University System, method, and computer program product for high speed backplane messaging
US7673304B2 (en) 2003-02-18 2010-03-02 Microsoft Corporation Multithreaded kernel for graphics processing unit
US7523157B2 (en) * 2003-09-25 2009-04-21 International Business Machines Corporation Managing a plurality of processors as devices
US20050071578A1 (en) * 2003-09-25 2005-03-31 International Business Machines Corporation System and method for manipulating data with a plurality of processors
US7634776B2 (en) 2004-05-13 2009-12-15 Ittiam Systems (P) Ltd. Multi-threaded processing design in architecture with multiple co-processors
US7818507B2 (en) * 2005-04-04 2010-10-19 Sony Computer Entertainment Inc. Methods and apparatus for facilitating coherency management in distributed multi-processor system
JP4082706B2 (ja) * 2005-04-12 2008-04-30 学校法人早稲田大学 マルチプロセッサシステム及びマルチグレイン並列化コンパイラ
JP4836491B2 (ja) 2005-05-20 2011-12-14 株式会社ソニー・コンピュータエンタテインメント 情報処理装置、システム、方法およびプロセッサ
JP2007066759A (ja) 2005-08-31 2007-03-15 Toyota Motor Corp 燃料電池
JP2007172456A (ja) * 2005-12-26 2007-07-05 Toshiba Corp 描画装置
US7865898B2 (en) * 2006-01-27 2011-01-04 Oracle America, Inc. Repartitioning parallel SVM computations using dynamic timeout
TW200809764A (en) 2006-04-24 2008-02-16 Sony Corp Image processing device, image processing method and program recording medium
US8468532B2 (en) * 2006-06-21 2013-06-18 International Business Machines Corporation Adjusting CPU time allocated to next thread based on gathered data in heterogeneous processor system having plurality of different instruction set architectures
US8453132B2 (en) 2006-07-28 2013-05-28 Hewlett-Packard Development Company, L.P. System and method for recompiling code based on locality domain and thread affinity in NUMA computer systems
US20080109795A1 (en) * 2006-11-02 2008-05-08 Nvidia Corporation C/c++ language extensions for general-purpose graphics processing unit
US7701459B1 (en) 2006-11-03 2010-04-20 Nvidia Corporation Primitive oriented assembly for parallel vertex/geometry processing
US8269782B2 (en) 2006-11-10 2012-09-18 Sony Computer Entertainment Inc. Graphics processing apparatus
EP1956484B1 (de) 2007-02-07 2011-10-19 Robert Bosch Gmbh Verwaltungsmodul, Hersteller- und Verbraucherrechner, Anordnung davon und Verfahren zur Kommunikation zwischen Rechnern über einen gemeinsam verwendeten Speicher
US8108845B2 (en) * 2007-02-14 2012-01-31 The Mathworks, Inc. Parallel programming computing system to dynamically allocate program portions
JP5224498B2 (ja) 2007-02-28 2013-07-03 学校法人早稲田大学 メモリ管理方法、情報処理装置、プログラムの作成方法及びプログラム
US8108633B2 (en) * 2007-04-11 2012-01-31 Apple Inc. Shared stream memory on multiple processors
EP3413198A1 (de) 2007-04-11 2018-12-12 Apple Inc. Parallele datenverarbeitung auf mehreren prozessoren
US8095735B2 (en) * 2008-08-05 2012-01-10 Convey Computer Memory interleave for heterogeneous computing
US8806426B2 (en) * 2008-06-04 2014-08-12 Microsoft Corporation Configurable partitioning of parallel data for parallel processing
WO2009147741A1 (ja) 2008-06-05 2009-12-10 北陸電気工業株式会社 タッチパネルを備えた表示装置及び圧電アクチュエータ
JP5112386B2 (ja) * 2008-06-05 2013-01-09 株式会社東芝 画像処理装置及び画像処理方法
JP2009295032A (ja) * 2008-06-06 2009-12-17 Canon Inc 画像処理装置及びその制御方法
US8225325B2 (en) * 2008-06-06 2012-07-17 Apple Inc. Multi-dimensional thread grouping for multiple processors
US8397241B2 (en) * 2008-11-13 2013-03-12 Intel Corporation Language level support for shared virtual memory
CN101551761A (zh) * 2009-04-30 2009-10-07 浪潮电子信息产业股份有限公司 一种异构多处理器中共享流内存的方法
US9354944B2 (en) * 2009-07-27 2016-05-31 Advanced Micro Devices, Inc. Mapping processing logic having data-parallel threads across processors
US8669990B2 (en) * 2009-12-31 2014-03-11 Intel Corporation Sharing resources between a CPU and GPU
US8723877B2 (en) * 2010-05-20 2014-05-13 Apple Inc. Subbuffer objects

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6970206B1 (en) 2000-04-20 2005-11-29 Ati International Srl Method for deinterlacing interlaced video by a graphics processor
US7015913B1 (en) 2003-06-27 2006-03-21 Nvidia Corporation Method and apparatus for multithreaded processing of data in a programmable graphics processor

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
IEEE754-2008

Also Published As

Publication number Publication date
GB201108084D0 (en) 2011-06-29
CN102870096A (zh) 2013-01-09
JP5583844B2 (ja) 2014-09-03
CN102870096B (zh) 2016-01-13
CA2795365C (en) 2015-12-08
JP5939524B2 (ja) 2016-06-22
KR101558831B1 (ko) 2015-10-08
US20150187322A1 (en) 2015-07-02
US9691346B2 (en) 2017-06-27
GB2480536B (en) 2013-01-02
KR101477882B1 (ko) 2014-12-30
EP2572276B1 (de) 2018-07-11
US8957906B2 (en) 2015-02-17
EP2572276A1 (de) 2013-03-27
CA2795365A1 (en) 2011-11-24
BR112012027950B1 (pt) 2020-11-10
US8723877B2 (en) 2014-05-13
KR20130004351A (ko) 2013-01-09
AU2011256745A1 (en) 2012-11-01
US20110285729A1 (en) 2011-11-24
MX2012012534A (es) 2012-12-17
US20140313214A1 (en) 2014-10-23
GB2480536A (en) 2011-11-23
KR20140117689A (ko) 2014-10-07
WO2011146197A1 (en) 2011-11-24
AU2011256745B2 (en) 2014-01-23
JP2015007982A (ja) 2015-01-15
JP2013528861A (ja) 2013-07-11

Similar Documents

Publication Publication Date Title
DE112011101725T5 (de) Sub-Puffer-Objekte
CN110262907B (zh) 用于统一应用编程接口和模型的系统和方法
DE102020115026A1 (de) Systeme und Verfahren zur Tonabbildung von Bildern mit hohem Dynamikumfang für auf tiefem Lernen basierende Verarbeitung von hoher Qualität
DE102020129003A1 (de) Vorrichtung und verfahren zum verwenden von alpha-werten zum verbessern einer strahlverfolgungseffizienz
DE112018005527T5 (de) Automatisches aufwecken von leistungsdomänen fürgrafikkonfigurationsanforderungen
DE112017003234T5 (de) Reduzieren von Speicherzugrifflatenzen während der Strahltraversierung
DE102020107080A1 (de) Grafiksysteme und Verfahren zum Beschleunigen von Synchronisation mittels feinkörniger Abhängigkeitsprüfung und Planungsoptimierungen basierend auf verfügbarem gemeinsam genutztem Speicherplatz
DE102021102589A1 (de) Berechnungsgraph-optimierung
DE102020121814A1 (de) Vorrichtung und Verfahren zum Verwenden von Dreieckspaaren und gemeinsam genutzten Transformationsschaltungen zum Verbessern der Strahlverfolgungsleistung
DE102021104561A1 (de) Asynchrone datenbewegungspipeline
DE102021104970A1 (de) Kooperative parallele speicherzuteilung
DE102020105902A1 (de) Hardware-indexzuordnungsmechanismus
DE102020115578A1 (de) Management von partiellem schreiben in einer grafik-enginemit mehreren kacheln
DE102020126177A1 (de) Verfahren und vorrichtung zum planen der threadreihenfolge, um den cache-wirkungsgrad zu verbessern
DE102021103492A1 (de) Anwendungsprogrammierschnittstelle zum beschleunigen von matrixoperationen
DE102020134334A1 (de) Vorrichtung und verfahren zur quantisierten konvergenten richtungsbasierten strahlsortierung
DE102021106797A1 (de) Techniken zur orchestrierung von phasen der thread-synchronisation
DE112018003999T5 (de) Verfahren und Vorrichtung für effiziente Verarbeitung von abgeleiteten einheitlichen Werten in einem Grafikprozessor
DE102022130536A1 (de) Sich selbst abstimmende thread-verteilungsrichtlinie
DE102020113400A1 (de) Registerteilungsmechanismus
DE102020104651A1 (de) Arbeitsspeicherkomprimierungs-Hashmechanismus
DE102019123443A1 (de) Mechanismus zum gemeinsamen Benutzen von Registern
DE112018007634T5 (de) Vorrichtung und verfahren für eine virtualisierte anzeige
DE102021116364A1 (de) Vorrichtung und verfahren für strahlverfolgungs-detaillierungsgradübergänge von hoher qualität
DE102020132088A1 (de) Berechnung effizienter kanalübergreifender operationen in parallelrechenmaschinen mit systolischen arrays

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final