DE112012002465T5

DE112012002465T5 - Grafikprozessor mit nicht blockierender gleichzeitiger Architektur

Info

Publication number: DE112012002465T5
Application number: DE112012002465.6T
Authority: DE
Inventors: Steven J. Clohset; Luke T. Peterson; Jason R. Redgrave; James A. Mccombe
Original assignee: Caustic Graphics Inc
Current assignee: Imagination Technologies Ltd
Priority date: 2011-06-16
Filing date: 2012-06-15
Publication date: 2014-03-20
Also published as: CN103765376B; GB2529075A; US20210065425A1; US9430811B2; GB2505818B; GB2505818A; GB201322076D0; CN103765376A; WO2012174334A1; US10861214B2; US8692834B2; GB201516157D0; US11625885B2; US20140327683A1; US20150339798A1; GB2529074A; US9098918B2; GB201516158D0; US20160335791A1; US20230245374A1

Abstract

In manchen Aspekten ermöglichen Systeme und Verfahren die Bildung von Gruppierungen einer Vielzahl von unabhängig spezifizierten Berechnungsarbeitsbelastungen, wie z. B. Grafikverarbeitungsarbeitsbelastungen, und in einem speziellen Beispiel Strahlenverfolgungsarbeitsbelastungen. Die Arbeitsbelastungen umfassen einen Scheduling-Schlüssel, der eine Basis ist, auf der die Gruppierungen gebildet werden können. Gemeinsam gruppierte Arbeitsbelastungen können allesamt von derselben Befehlsquelle aus ein oder mehrere verschiedene private Datenelemente ausführen. Solche Arbeitsbelastungen können rekursiv andere Arbeitsbelatungen instantiieren, die dieselben privaten Datenelemente referenzieren. In manchen Beispielen kann der Scheduling-Schlüssel dazu verwendet werden, ein Datenelement zu identifizieren, das von allen Arbeitsbelastungen einer Gruppierung verwendet werden kann. Speicherkonflikte bezüglich privater Datenelemente werden durch das Scheduling nicht in Konflikt stehender Arbeitsbelastungen oder spezieller Befehle zur Verschiebung in Konflikt stehender Arbeitsbelastungen gelöst, anstatt Speicherplätze zu sperren.

Description

VERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung beansprucht für alle Zwecke Priorität der vorläufigen US-Patentanmeldung Nr. 61/497.915, eingereicht am 16. Juni 2011, die hiermit zur Gänze durch Verweis aufgenommen ist.
HINTERGRUND
Gebiet:
Das Folgende bezieht sich im Allgemeinen auf die Nutzung paralleler Verarbeitungsressourcen und in einem konkreteren Aspekt auf eine Programmierung von Schnittstellen und Architekturen, die in verschiedenen Klassen von parallelen Berechnungsproblemen verwendet werden können, und insbesondere auf Grafikverarbeitung, einschließlich von Strahlenverfolgung.
Stand der Technik:
Computerarchitekturen dienen dem Versuch, Parallelismen auf der Hardware-Ebene und auf der Ebene der Software bzw. der Betriebssysteme zu erhöhen. Ein allgemeines Konzept besteht darin, Multithreading als Mechanismus zur Erhöhung des Parallelismus einzusetzen.
Was softwarebasiertes Multithreading betrifft, kann ein Betriebssystem gleichzeitig mehrere Prozesse (typischerweise mehrere unabhängige Programme) auf einer einzigen Hardware-Ausführungsressource ausführen, indem es die Ausführung der Prozesse zeitlich verschachtelt. Dieses Verschachteln lässt sich durch einen OS-Kernel erreichen, der bestimmt, welchem Prozess Priorität zukommt, und der auch auf die Ressourcen zugreifen kann, die er benötigt, um mit der Ausführung fortzufahren.
Wenn ein Prozess zwei oder mehrere halbunabhängige Unteraufgaben aufweist, kann mehrfaches Threading den Durchsatz erhöhen, bessere Antwortzeiten ergeben, Operationen beschleunigen, die Programmstruktur verbessern, weniger Systemressourcen verwenden und effizienter von Multiprozessoren Gebrauch machen. Beim Multithreading weist ein Prozess mehrere Steuerungsthreads auf. Das Konzept des Rechnens mittels Multithreadings wird immer verbreiteter, da schnellere Takte für Prozessoren untragbar viel Strom verbrauchen und Transistorbudgets für breitere Architekturen verwendet werden. So ist auch der Begriff ”Thread” immer stärker in Gebrauch, wird aber nicht immer zur Beschreibung ein und desselben Konzepts verwendet, vielmehr erklärt sich die Bedeutung des Begriffs aus dem jeweiligen Gebrauchszusammenhang.
Ein Prozess kann als einzelnes Programm oder als ausführbare Anwendung angesehen werden. Dementsprechend hat ein Prozess eine Folge von auszuführenden Anweisungen. Ein Thread weist auch eine Abfolge von Befehlen zur Ausführung auf, ist typischerweise aber eher granular. Beispielsweise kann eine Funktion die Befehlsabfolge eines Threads darstellen. Falls er von einem Prozess instantiiert ist, teilt ein Thread den Adressraum dieses Prozesses, kann jedoch innerhalb des Prozesses einmalige Ressourcen besitzen. Befehle von jedem Thread können einzeln eingeplant werden, was ermöglicht, dass Threads eines Prozesses einzeln ausgeführt werden, je nach Vorgabe durch die Verfügbarkeit von Ressourcen.
Threads können mittels eines Erzeugungsprozesses verwaltet werden und für einen Kernel eines Betriebssystems unsichtbar sein (auch als Benutzerebenen- oder Anwendungsebenenthreads bezeichnet). Benutzerthreads werden im Benutzerraum bedient und unter Verwendung einer in einer Bibliothek bereitgestellten API gesteuert. Eine solche Steuerung umfasst Vorgänge wie Erzeugung, Beendigung, Synchronisation, Scheduling. Erzeugungs-, Beendigungs- und Synchronisationsvorgänge können unter Verwendung von Benutzerraumthreads durchgeführt werden. Da Benutzerraumthreads für den Kernel (welcher nur des überschreibenden Prozesses, der die Benutzerraumthreads enthält, gewahr ist) nicht direkt sichtbar sind, blockiert, falls ein Benutzerraumthread blockiert, dessen gesamter Prozess. Wenn das geschieht, geht der Nutzen des Parallelismus von Threads verloren oder wird reduziert. Um das Blockieren zu reduzieren, können zusätzliche Komplexitätsschichten eingeführt werden, jedoch auf Kosten der Leistung.
Kernelthreads werden im Kernelraum bedient und von den Threadfunktionen in der Threadbibliothek erzeugt. Kernelthreads sind vom Kernel einplanbare Einheiten, die für das Betriebssystem sichtbar sind. Kernelthreads existieren im Zusammenhang eines Prozesses und stellen dem Betriebssystem die Mittel bereit, kleinere Abschnitte des Prozesses zu adressieren und auszuführen. Kernelthreads ermöglichen es Programmen auch, von der Hardware bereitgestellte Fähigkeiten zur gleichzeitigen und parallelen Verarbeitung auszunutzen. Mit Kernelthreads kann jeder Benutzerthread einen entsprechenden Kernelthread aufweisen. Jeder Thread ist vom Kernel unabhängig einplanbar, falls also ein von einem Thread ausgeführter Befehl blockiert, können Befehle von anderen Threads ausgeführt werden. Erzeugung, Beendigung und Synchronisation können mit Kernelthreads langsamer ablaufen als mit Benutzerthreads, da der Kernel an der Threadregelung beteiligt werden muss. Bei Verwendung von Kernelthreads mag zwar der Programmverwaltungsaufwand größer sein, dafür ist selbst bei einem Einprozessorsystem Gleichzeitigkeit möglich. Folglich kann die gesamte Anwendungsleistung bei Kernelraumthreads die Leistung von Benutzerraumthreads übersteigen. Entwickler müssen jedoch vorsichtiger sein, wenn sie große Mengen an Threads erzeugen, da jeder Thread mehr Gewicht zu dem Prozess hinzufügt und den Kernel belastet.
Kernelthreads können die Rolle von Prozessen insofern verändern, dass ein Prozess eine Art logischer Behälter ist, der verwendet wird, um verwandte Threads einer Anwendung in einer solchen Umgebung zu gruppieren. Jeder Prozess enthält wenigstens einen Thread. Dieser einzelne (erste) Thread wird von dem System automatisch erzeugt, wenn der Prozess beginnt. Eine Anwendung muss die zusätzlichen Threads ausdrücklich erzeugen. Eine Anwendung mit nur einem Thread ist eine „Singlethreading-Anwendung”. Eine Anwendung mit mehr als einem Thread ist eine „Multithreading-Anwendung”. Eine beispielhafte Behandlung eines Threads in Bezug auf andere Thread wird unten stehend bereitgestellt.
Die ”Status”-Information eines Prozesses umfasst einen Programmzähler, der eine Abfolge von Ausführungsbefehlen indiziert, und einen Registerstatus. Der Registerkontext und der Programmzähler enthalten Werte, die den aktuellen Status der Programmausführung angeben. Die Abfolge von Ausführungsbefehlen ist der eigentliche ProgrammCode. Wenn beispielsweise ein Prozesskontextwechsel stattfindet, teilen die Registerinformationen des neu eingeplanten Prozesses dem Prozessor mit, wo der Prozess mit seiner Ausführung aufgehört hat. Genauer gesagt enthält der Programmzähler eines Threads den aktuellen Befehl, der beim Start auszuführen ist.
Wie der Kontext eines Prozesses besteht der Kontext eines Threads aus Befehlen, Zuordnungen, einer Benutzerstruktur mit Registerkontext, privatem Speicher, Threadstruktur und Threadstack. Wie ein Prozess weist ein Thread eine Art Lebenszyklus auf, der auf der Ausführung eines Steuerbefehlssatzes basiert. Im Laufe der Zeit werden Threads erzeugt, laufen ab, ruhen und werden beendet – wie Prozesse. Neue Prozesse werden (und in einem Multithreading-OS wird wenigstens ein Thread für den Prozess) typischerweise unter Verwendung eines fork()-Aufrufs erzeugt, der eine Prozess- und eine Thread-ID hervorbringt. Der Prozess und sein Thread werden mit der aktiven Liste verbunden. Der neue Thread wird als ablauffähig markiert und wird danach in einer Ablaufwarteschlange platziert. Der Kernel plant den Ablauf des Threads ein und ändert den Thread-Status zu einem aktiven Ablaufstatus. Während er sich in diesem Status befindet, erhält der Thread die Ressourcen, die er benötigt. Dies wird fortgesetzt, bis ein Zeit-Interrupt erfolgt oder der Thread seine Wartezeit auf eine angefragte Ressource aufgibt oder dem Thread ein anderer Thread (mit höherer Priorität) zuvorkommt. Falls dies geschieht, wird der Kontext des Threads ausgeschaltet.
Ein Thread wird ausgeschaltet, wenn er auf eine angefragte Ressource warten muss (sonst würde der Prozessor blockieren). Dies führt dazu, dass der Thread in einen Ruhezustand tritt. Der Thread ruht, bis die von ihm angefragte Ressource wiederkehrt und ihn wieder für den Betrieb verfügbar macht. Während des Ruhezustands des Threads ändert der Kernel den aktuell ablaufenden Thread mit CPU-Verwendung. Nach einem gewissen Zeitraum kann der Kernel einen Kontextwechsel auf einen anderen Thread verursachen. Der nächste abzulaufende Thread ist dann der Thread mit der höchsten Priorität unter den Threads, die betriebsbereit sind. Was die verbleibenden Threads in diesem Bereitschaftszustand betrifft, kann ihre Priorität nach oben verändert werden. Sobald ein Thread die angefragte Ressource erhält, ruft er den Weckvorgang auf und ändert den Status wieder vom Ruhe- in den Betriebszustand, was den Thread wieder für den Ablauf verfügbar macht. Beim nächsten Kontextwechsel wird dem Thread erlaubt, in Betrieb zu gehen, vorausgesetzt, es handelt sich um den nächsten verfügbaren Kandidaten. Wenn er in Betrieb gehen darf, ändert sich der Status des Threads wieder zu aktiv ablaufend. Sobald der Thread zum Abschluss kommt, wird er beendet, gibt alle Ressourcen frei und kann in einen Zombie-Status übergehen. Sobald alle Ressourcen freigegeben sind, werden die Einträge von Thread und Prozess freigegeben und die verlinkten Listen aktiver Prozesse/Threads können aktualisiert werden.
Was mehr hardwareorientierten Parallelismus betrifft, steht in fast allen Computervorrichtungen die Fähigkeit, parallel rechnende Hardware umzusetzen, zur Verfügung, von starken mobilen oder Stand-CPU, die 4, 8, 16, 32 oder mehrere Dutzend relativ komplexe Verarbeitungselemente aufweisen können, bis zu Grafikprozessoren (GPU) mit zahlreichen (z. B. Hunderten) relativ einfachen Prozessoren.
Während GPU ursprünglich zur Beschleunigung von Rastergrafik konzipiert und auch heute noch vorwiegend dafür verwendet werden, werden sie allmählich immer besser programmierbar. Diese erhöhte Programmierbarkeit hat ermöglicht, dass manche Multithreading-Berechnungsprobleme auf GPU ausgedrückt und ausgeführt werden. Zwar weisen GPU-Architekturen äußerst hohe theoretische Spitzenleistungen in Gleitkommaoperationen pro Sekunde (FLOPS) auf, aber nur gerasterte Grafik und bestimmte manierliche, sehr leicht in den Griff zu bekommende Rechenprobleme können annähernd einen tatsächlichen Durchsatz erreichen, der dem theoretischen Durchsatz nahekommt.
Der zunehmende Rechnerparallelismus beinhaltet typischerweise ein Abwägen zwischen algorithmischer Komplexität und auftretendem Verwaltungsaufwand bei der Regelung des Teilens von Berechnungsressourcen. Eine weitere wichtiger Überlegung liegt darin, dass die Ausführung von Algorithmen korrekt ist, sodass die Datenwerte nicht verfälscht werden. Die parallele Ausführung von Threads, die geteilte Daten verwenden kann, kann eine Verfälschung von Daten durch ungenaue Zeitabstimmung von Reads und Writes auf geteilte Datenwerte verursachen. Ein Verhandeln des Zugriffs oder ein Reihen des Zugriffs auf solche geteilten Datenwerte zieht Verwaltungsaufwand nach sich.
Eine weitere Sorge liegt weitgehend im Gewährleisten der Richtigkeit von Daten bei zunehmend paralleler Ausführung. Grundsätzlich wird Parallelismus (und Vermeidung von Datenverfälschung) zwischen verschiedenen Threads durch Sperren auf Variablen gelöst, die Gefahr laufen, aufgrund von in Konflikt stehenden Prozessen in einem System außerhalb der richtigen Ordnung geschrieben (oder gelesen) zu werden. Das Konzept besteht im Wesentlichen darin, dass ein bestimmter Prozess, wenn er eine solche Variable anschreiben will (z. B. eine globale Variable), versucht, die Variable zu sperren. Falls kein anderer Prozess eine Sperre auf die Variable aufweist, kann die Sperre dem anfragenden Prozess gewährt werden. Der Prozess führt sein Write durch und gibt die Sperre dann frei. Wie zu erkennen ist, hängt die Verwendung von Sperren von einem Mechanismus zum Detektieren oder Identifizieren der Variablen, die von Sperren geschützt werden sollen, und einem Arbiter zum Prüfen des Sperrstatus, Gewähren des Sperrstatus und Aufheben des Sperrstatus ab. Oft hängt, welche Variablen geschützt werden müssen, auch davon ab, ob ein bestimmtes Softwareverfahren zur Verwendung auf Multithreading-Plattformen verfügbar sein soll, in denen eine Reihe solcher Instanzen dieses Verfahrens in gleichzeitigen Ausführungsprozessen ausgeführt werden können.
Programmierer können spezifizieren, dass Code-Teile in einem Prozess von einer Sperre geschützt sind. Zum Kompilierzeitpunkt kann ein Compiler einen solchen Code verarbeiten und in manchen Fällen auch gefährdete, aber nicht geschützte Variablen detektieren und solche Sperren in den compilierten Objektcode einbauen.
Eine Umsetzung einer Sperre ist ein wechselseitiger Ausschluss (Mutex), der steuert, wie verschiedene Teile eines Computercodes auf eine gemeinsame Ressource zugreifen, wie z. B. eine globale Variable. Beispielsweise sollte ein Teil des Codes, der eine bestimmte Variable nicht lesen muss, nicht während einer Aktualisierung dieser Variable durch ein anderes Verfahren ausgeführt werden dürfen. Der Begriff Mutex wird auch im Sinne eines Programmelements verwendet, das bewirkt, dass ein wechselseitiger Ausschluss verschiedener Programmelemente für in Konflikt stehende Variablen verhandelt wird. In einer Multithreading-Ausführungsumgebung können mehrere Threads ausgeführt werden, und letztlich kann es sein, dass sie auf ein bestimmtes Datenobjekt zugreifen müssen, das von einem Mutex geschützt ist. Wenn der Mutex gerade aktiv ist, verursacht typischerweise das Betriebssystem, dass die Threads, die auf diesen Mutex warten, in Ruhezustand treten (d. h. die Ausführung beenden). Während also mehr und mehr Threads den Mutex erreichen, werden sie in Ruhezustand gebracht, um einen Zeitpunkt zu erwarten, zu dem das Betriebssystem anzeigt, dass sie mit der Ausführung fortfahren können. Das Betriebssystem kann diese Threads in der relativen Reihenfolge, in der sie am Mutex angekommen sind, wecken; die Reihenfolge, in der sie geweckt werden, kann aber auch einfach unbestimmt sein.
Weitere Ansätze zur Zuweisung gemeinsamer Ressourcen umfassen Semaphoren, die eine Gruppe von undifferenzierten Ressourcenelementen auf Prozesse verteilen, die anstreben, diese Elemente zu verwenden. Ein Semaphor zählt im Wesentlichen, wie viele Elemente der Ressource aus der Gruppe zur Verwendung verfügbar sind und passt den Wert an, wenn Ressourcen besetzt und freigegeben werden. Wenn keine Elemente einer bestimmten Ressource verfügbar sind, wartet ein Prozess, der die Verwendung der Ressource anfordert, bis ein Element der Ressource freigegeben wurde. Typischerweise werden Semaphore in Betriebssystemen zur Ressourcenzuweisung implementiert.
Varianten grundlegender Sperrkonzepte existieren, z. B. der Spinlock, der es Threads ermöglicht, weiterhin aktiv nachzufragen, wann eine bestimmte Sperre frei ist, sodass ihre Empfänglichkeit erhöht wird, da sie nicht erst geweckt werden müssen, was zu Verwaltungsaufwand (Kontextwechsel) führen würde. Spinlocks arbeiten jedoch mit Prozessorzyklen und reduzieren folglich inhärent den Wirkungsgrad. Weitere Varianten umfassen rekursives Sperren, das Umsetzen von zeitlichen Beschränkungen an Sperren, sodass ein Prozess nicht unendlich wartet, um die Sperre für ein bestimmtes Objekt zu erhalten, sondern stattdessen mit der Ausführung fortfährt, falls dies möglich ist, falls seiner Sperrenanfrage nicht innerhalb eines bestimmten Zeitraums nachgekommen wurde. Ein solcher Ansatz ist in eingebetteten Systemen nützlich, wo die Ausführung bestimmter entscheidender Prozesse nach absoluten Zeitabläufen notwendig sein kann.
Eine weitere beispielhafte Variante ist rekursives Sperren, eine Strategie, die zur Berechnung von Architekturen vorgeschlagen ist, die Non-Uniform Memory Access (NUMA) auf einen gemeinsamen Speicher aufweisen. Typischerweise weisen Gruppen von Allzweckprozessoren, jeweils mit einem Cache auf dem Chip, die in einem System mit gemeinsamem Hauptspeicher operieren, NUMA-Eigenschaften auf (praktischerweise eine große Mehrheit der kostengünstigen Berechnungsplattformen). Rekursives Sperren beruht auf der Erkenntnis, dass ein auf einem Prozessor, der einen gesperrten Speicherplatz aufweist, befindlicher Prozess (Standard-Test- und Set-Locking) aufgrund von Unterschieden in der Kommunikationsverzögerung, die durch eine Zwischenverbindung zwischen den Prozessoren verursacht werden, mit höherer Wahrscheinlichkeit Zugriff auf diesen gesperrten Speicherplatz enthält als ein Prozess, der auf einem anderen Chip ausführt. Rekursives Sperren zielt darauf ab, eine vorhersehbare und steuerbare Präferenz für das Gewähren einer Sperre an einen Prozess durchzusetzen, der mehr Datenlokalität aufweisen kann, indem Sperren Prozessen gewährt werden, die an dem Knoten ausgeführt werden, der die Sperre bereits aufweist, indem dem Vorgang der Gewährung der Sperre eine Bedingung hinzugefügt wird, die einen Identifikator darauf testet, welcher Knoten den Thread, der die Sperre anfordert, aufweist.
ZUSAMMENFASSUNG
Aspekte eines beispielhaften Systems zur Durchführung gleichzeitiger Grafikberechnung umfassen einen Cluster von Berechnungselementen, wobei jedes Berechnungselement einen lokalen Speicher und eine Vielzahl von arithmetisch-logischen Einheiten (ALUs) von Single-Instruction-Multiple-Data (SIMD) umfasst. Das System weist auch einen Scheduler für den Cluster von Berechnungselementen auf. Der Scheduler ist betriebsfähig, Eingaben zu empfangen, die Instanzen einer ersten an dem Cluster durchzuführenden Berechnungsart definieren, wobei jede der Instanzen einem entsprechenden Scheduling-Schlüssel zugeordnet ist. Der Scheduler ist betriebsfähig, die Instanzen nach ihren Scheduling-Schlüsseln zu Paketen zu sortieren und ein Paket auszugeben, das eine Vielzahl von Berechnungsinstanzen umfasst. Das System weist einen Verteiler auf, der betriebsfähig ist, das Paket zu empfangen und die Instanzen auf die Berechnungselemente des Clusters zur Durchführung auf diesem zu verteilen. Jedes der Berechnungselemente ist betriebsfähig, Instanzen mit verschiedenen Scheduling-Schlüsseln zur gleichzeitigen Durchführung zu kombinieren, für welche die gleiche Berechnung durchzuführen ist, und gleichzeitig die Berechnung für die kombinierten Berechnungsinstanzen durchzuführen.
Beispielhafte weitere Aspekte können umfassen, dass Instanzen für Speicherzugriffe auf Speicherplätze synchronisiert sind, die für Lesen und Schreiben mit anderen Instanzen offen sind, indem in Konflikt stehende Speicherbereiche unter verschiedenen Instanzen der ersten Berechnungsart identifiziert werden, bevor Befehle, die auf diese in Konflikt stehenden Speicherbereiche zugreifen, zur Durchführung abgefertigt wurden. Der Scheduler kann dieses Identifizieren der in Konflikt stehenden Speicherbereiche unter Verwendung einer oder mehrerer instanzenspezifischer Speicheradressen für eine variable Deklaration durchführen. Das System kann während einer Einrichtungsphase instanzenspezifische Speicherbereiche innerhalb der Vielzahl von Berechnungselementen zuteilen. Jedes Berechnungselement kann betriebsfähig sein, Gruppierungen von Instanzen der zweiten Berechnungsart nach Kriterien einzuplanen, die (1) die Durchführung von einer gemeinsamen Befehlsquelle und (2) das Durchsetzen einer Regel umfassen, wonach keine Gruppierung von parallel durchzuführenden Instanzen mehrere Instanzen umfassen darf, die den gleichen Speicherplatz beschreiben.
In einem weiteren beispielhaften Aspekt sorgt ein Verfahren, das bei Scheduling-Berechnung in einem Computersystem durchzuführen ist, für das Verteilen von Arbeitsbelastungen einer ersten Art auf eine Vielzahl von Berechnungsclustern. Jeder Cluster ist betriebsfähig, die Ausführung von Befehlen aus den diesem Cluster zugeteilten Arbeitsbelastungen der ersten Art unabhängig von anderen Clustern aus der Vielzahl einzuplanen. Gruppierungen von Arbeitsbelastungen einer zweiten Art werden zur Durchführung in der Vielzahl von Berechnungsclustern ausgebildet. Die Gruppierungen werden auf der Basis von jeweiligen Scheduling-Schlüsseln, die Arbeitsbelastungen der zweiten Art zugeordnet sind, bestimmt. Jeder Scheduling-Schlüssel definiert eines oder mehrere eines während der Ausführung jeder Gruppierung von Arbeitsbelastungen zu verwendenden Datenelements und einen Befehlssatz, der für jede Arbeitsbelastung der zweiten Art auszuführen ist. Eine Gruppierung von Arbeitsbelastungen wird ausgewählt, und Arbeitsbelastungen der Gruppierung werden auf die Vielzahl von Berechnungsclustern verteilt.
Ein weiterer beispielhafter Aspekt umfasst eine Berechnungskomponente zur Verwendung in einem Berechnungssystem, die umfasst: einen Speicher, der einen vorläufigen Teil und einen ständigen Speicherteil umfasst. Die Komponente umfasst ferner eine Vielzahl von arithmetisch-logischen Einheiten (ALUs), die jeweils Lese- und Schreibzugriffsfähigkeit auf den Speicher aufweisen, und eine Warteschlange zum Empfangen gesonderter Definitionen der an der Vielzahl an ALUs durchzuführenden Berechnung. Die Definitionen umfassen eine Programmreferenz und einen Scheduling-Schlüssel. Ein lokaler Scheduler ist betriebsfähig, die Vielzahl von ALUs einzuplanen. Der lokale Scheduler ist betriebsfähig, beim Scheduling der Berechnung Prioritäten zu setzen, indem er Gruppierungen von Berechnungsdefinitionen mit der gleichen Programmreferenz und dem gleichen Scheduling-Schlüssel identifiziert. Der Scheduling-Schlüssel wird dazu verwendet, eine Position im umlaufstarken Teil des Daten speichernden Speichers zu identifizieren, die von den ALU verwendet werden soll, wenn sie das referenzierte Programm ausführen.
In einem weiteren Aspekt umfasst ein greifbares, von Computern lesbares Medium, auf dem von Computern ausführbare Befehle gespeichert sind, Befehle für einen Berechnungsthread, der auf einer Computereinheit auszuführen ist. Die Befehle für den Thread umfassen Befehle, eine Berechnungsroutine aufzurufen. Der Aufruf der Berechnungsroutine umfasst eine Definition eines Scheduling-Schlüssels, eine eingeschränkte Speicherreferenz, die einen Speicherplatz zum Lesen und Beschreiben definiert, und einen für diese Berechnungsroutine zu lesenden Speicherplatz sowie Befehle, die nach Aufruf der Berechnungsroutine auszuführen sind, ohne auf eine Rückgabe von Informationen zu warten, die von der aufgerufenen Berechnungsroutine während ihrer Ausführung produziert werden. Die Berechnungsroutine kann ferner rekursiv instantiiert werden, und jede rekursiv instantiierte Instanz erbt automatisch die eingeschränkte Speicherreferenz, und der Lesespeicherplatz ist anders. Der Lesespeicherplatz kann auf der Basis eines regelmäßigen Zugriffsmusters einer Datenart, auf die zugegriffen wird, aktualisiert werden.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 zeigt eine Architektur eines Beispielsystems, wobei gleichzeitiges und paralleles Processing und Scheduling gemäß den vorliegenden Offenbarungen umgesetzt werden können;
2 zeigt ein weiteres beispielhaftes System 202, an dem offenbarte Aspekte angewandt werden können;
3 zeigt einen Aspekt heterogener Berechnung, wobei ein Elternthread eine Instanz einer zweiten Berechnungsart instantiieren kann, welcher weitere Instanzen der zweiten Berechnungsart instantiieren kann;
4 zeigt beispielhafte Schritte, in denen eine heterogene Berechnungsarchitektur die gleichzeitige Ausführung von Instanzen mehrerer Berechnungsarten unterstützen kann;
5 zeigt weitere Aspekte von Faserberechnung gemäß der Offenbarung;
6 zeigt einen Strom von hereinkommenden Gruppen von Fasern, wobei ein Scheduling bzw. eine Arbeitsverteilungsabstraktion die Verteilung der Fasern auf die Gruppen bereitstellt;
7 zeigt eine beispielhafte Struktur für einen Cluster, der in Umsetzungen der in 1 oder 2 gezeigten Anordnung von Clustern verwendet werden kann;
8 zeigt die dynamische Sammlung, das Scheduling und die verteilte Ausführung von Faserroutinen auf einer Vielzahl von Berechnungseinheiten;
9 zeigt Aspekte des beispielhaften Betriebs eines Clusters, der eine Vielzahl von ALUs umfasst;
10 zeigt einen lokalen Speicher eines Berechnungsclusters, der lokale Threadvariablen speichert, und mehrere Elemente der Faserdatenspeicherung;
11 zeigt Teile eines Prozesses, der von einer zentralisierten Steuereinheit durchgeführt wird, welche in Implementierungen der vorliegenden Offenbarungen bereitgestellt ist;
12 zeigt Aspekte eines Priorisierungsprozesses, der in Systemen gemäß der Offenbarung zum Einsatz kommen kann;
13 zeigt Aspekte eines beispielhaften Prozesses gemäß der Offenbarung;
14 zeigt einen Sammlungsspeicher, in dem Fasern nach Aspekten der Offenbarung gruppiert werden können;
15 zeigt beispielhafte Implementierungsaspekte eines Eingabepuffers, der verteilte Fasern aufnimmt; und
16 zeigt Aspekte eines beispielhaften Prozesses gemäß der Offenbarung.
AUSFÜHRLICHE BESCHREIBUNG
Ein Grund dafür, dass Parallelismus sich nicht analog zur Verfügbarkeit von Berechnungsressourcen skalieren lässt, ist, dass Speicherbandbreite nicht im Verhältnis zur verfügbaren Berechnungskapazität zu skalieren ist. Daher können Berechnungsprobleme, die keine inhärente Datenlokalität genießen, verursachen, dass die Berechnungselemente auf Daten aus dem Speicher warten müssen, auf die sie zugreifen sollen. Speicherzugriff bleibt auch ein Problem, wenn maximale theoretisch erreichbare Speicherbandbreite gestiegen ist, da diese Spitzenbandbreiten explosionsartige Übertragungsraten voraussetzen, die für diese Art von Berechnungsproblemen oft unrealistisch sind. Zudem wird die Skalierbarkeit der Speicherschnittstellenleistung noch durch weitere Faktoren behindert, wie z. B. der Pin-Zahl der Speicherschnittstelle und der Tatsache, dass die Speicherzugriffsuchzeit nicht einfach analog zu Veränderungen der Prozesstechnologie skalierbar ist. Beispielsweise kann die Suchzeit von DDR3 Column Address Strobe (CAS) etwa 9 ns betragen, während die typische Suchzeit von DDR2 CAS bei etwa 10 ns liegt. Ebenso kann auch die Speichersuchzeit zwischen Verarbeitungsknoten einen Faktor in verschiedenen Berechnungsparadigmen, z. B. in NUMA-Architekturen, darstellen.
Ferner bedeutet die SIMD-Beschaffenheit der Berechnungscluster, dass das gleichzeitige Ausführen von Threads identischen Programmausführungspfaden folgen muss, um einen maximalen Berechnungsdurchsatz umzusetzen. Falls z. B. die Hälfte der Threads in einem solchem SIMD-Cluster einen Zweig in eine Richtung und der Rest den anderen Zweig nimmt, muss die Hardware diese beiden Pfade serialisieren (d. h. eine Hälfte wartet, während die andere Hälfte ausführt, sodass letztendlich der SIMD-Cluster wieder auf vektorisierten Daten ausgeführt werden kann). In einer solchen Situation führt die Berechnungseinheit bei nur 50%igem Durchsatz aus. In Situationen, in denen eine ausgeführte Codebasis zahlreiche Zweige enthält, kann eine Leistung aufgrund von SIMD-Verlust alleine im schlechtesten Fall 1/SIMD_Breite betragen, was auf einer 32 breiten SIMD-Architektur etwa 3% Wirkungsgrad bedeutet. Es gibt eine ganze Reihe von Berechnungsproblemen, darunter Strahlenverfolgung, räumliche Suche, Sortierung und Datenbankdurchquerung, die zwar theoretisch parallel führbar sind, aber nicht wirksam auf solche breiten SIMD-Architekturen angepasst wurden.
Manche Anwendungen der unten stehend beschriebenen Technologie betreffen Grafikprozessoren, wie z. B. Prozessoren, die Rasterisierung und/oder Strahlenverfolgung durchführen können. Um besonders auf Strahlenverfolgung einzugehen: Strahlenverfolgung kann eingesetzt werden, um aus 3D-Szenen gerenderte, realistische Bilder im Kontext von Videospielen, Filmen, animierter Werbung, Industriemodellen, Architektursimulation etc. zu erzeugen. Ein auf dem Gebiet des Renderings eingesetztes Konstrukt besteht darin, ein physisches Szenenmodell bereitzustellen und Oberflächeninformationen verschiedenen Teilen des Szenenmodells zuzuordnen. Beispielsweise kann ein Szenenmodell Objekte enthalten, die eine Person, ein Automobil und ein Gebäude umfassen. Das physische Modell der Szene würde die Oberflächen dieser Objekte z. B. als Drahtrahmenmodell beschreiben, das eine Vielzahl primitiver Formen umfassen kann, die miteinander verbunden sind, um Grenzen der Oberflächen zu beschreiben. Das physische Modell enthält im Allgemeinen keine Informationen über das äußere Erscheinungsbild der Oberflächen der Objekte. Zudem sind Informationen und Programmierung bestimmten Oberflächen und/oder Teilen bestimmter Oberflächen zugeordnet, die ihr Erscheinungsbild beschreiben. Diese Informationen können Texturen für die Oberflächen umfassen, während den Oberflächen zugeordnete Programmierung häufig modellieren soll, welche Wirkung die Oberfläche auf Licht ausübt, das auf die Oberfläche auftrifft. Beispielsweise ermöglicht das Programmieren die Modellierung von Glas, einer glänzenden Oberfläche, einer unebenen Oberfläche etc. Derlei Programmierung und Informationen sind mit diese Oberflächen beschreibenden Teilen des physischen Modells verbunden oder diesen auf sonstige Weise zugeordnet. Beispielsweise kann Programmierung einer bestimmten Primitivform zugeordnet oder an sie gebunden sein. Derlei Programmierung und sonstige Beschreibung oder Teile davon für eine bestimmte Basiseinheit oder ein bestimmtes Szenenobjekt sind allgemein als ”Shader” für diese Basiseinheit oder dieses Objekt zu bezeichnen.
Die oben stehende Beschreibung zeigt, dass der Begriff ”Thread” verschiedene Bedeutungen unter verschiedenen Umständen konnotieren kann (ist aber keine erschöpfende Erklärung möglicher Verwendungen des Begriffes). Daher wird in der folgenden Beschreibung die Terminologie in dem Versuch verwendet, die Abhängigkeit von mit Multithreading assoziierter Terminologie zu reduzieren, z. B. indem der Begriff ”Faser” als Name eingeführt wird, der kollektiv und einzeln eine Vielzahl von Konzepten bezeichnen soll, die nicht alle in jeder Implementierung gemäß der vorliegenden Offenbarung angewandt werden müssen. Dennoch können Multithreading-Betriebssysteme und Maschinen, die gleichzeitiges und paralleles Verarbeiten von Multithreading-Anwendungen unterstützen, angepasst werden, um Aspekte dieser Offenbarungen zu implementieren, was aus der folgenden Beschreibung deutlicher hervorgeht.
In einem Aspekt kann ein Prozess in einer Multiprocessing-Umgebung oder ein Thread in einer Multithreading-Umgebung (oder beides in einer Umgebung mit Multiprocessing und Multithreading) eine API dazu verwenden, eine oder mehrere Einheiten durchzuführender Arbeit zu erzeugen, die hier der Einfachheit halber jeweils eine ”Faser” genannt werden.
In einem Aspekt ist eine Faser eine Code-Instanz, wie z. B. eine Routine (z. B. eine C-Funktionsdeklaration), die wiederholt von einem Elternthread aufgespalten werden kann oder auf die rekursiv von einer anderen Instanz derselben Faserroutine zugegriffen werden kann. Eine Instanz einer Faserroutine (Instanzen von Faserroutinen werden der Einfachheit halber ”Fasern” genannt) umfasst einen Identifikator für ein als Scheduling-Schlüssel verwendetes Datenelement und die Identifizierung eines bestimmten Elements (einer Deklaration) von Faserspeicherung.
Fasern, die einen Scheduling-Schlüssel teilen, können zur gleichzeitigen Ausführung gruppiert werden (wie unten stehend beschrieben, erfordert dies Gruppierung nicht, dass diese Ausführung streng parallel erfolgt). Alle Fasern, die auf dasselbe Element der Faserspeicherung referenzieren, können zur Ausführung auf ein Berechnungselement kanalisiert werden, auf dem das Element der Faserspeicherung lokal gecacht ist. In einer beispielhaften Implementierung weist ein bestimmtes Element der Faserspeicherung für eine bestimmte Faser oder Gruppe von Fasern wenigstens die Eigenschaft auf, dass dieses Element der Faserspeicherung nur von dieser Faser lesbar und beschreibbar ist; diese Einschränkung kann mit der Zeit variabel oder absolut sein. Diese Einschränkung kann durch geeignete Programmierpraktiken, durch einen Compiler, durch Hardware und durch eine beliebige Kombination daraus durchgesetzt werden.
In einem Aspekt kann eine Faser durch eine Standard-C-Funktionsdeklaration definiert sein und enthält den gesamten Code, der erforderlich ist, um die Faser bis zur Vollendung auszuführen (Standard-Inline-Erweiterungen von Funktionen können bereitgestellt werden). Ein operativer Unterschied besteht dabei darin, dass eine Faser nicht auf einen Rückgabewert von einer anderen innerhalb der Faser aufgerufenen Funktion warten muss. In dem beispielhaften Aspekt enthält die Faserroutinenfunktionsdeklaration wenigstens ein Argument, für das ein Wert im Faserspeicher gespeichert ist, der dem Thread zugeordnet ist, der Fasern unter Verwendung dieser Faserroutinendeklaration aufspaltet.
In einem beispielhaften Aspekt ist bei allen Fasern, die auf ein bestimmtes Element der Faserspeicherung referenzieren (z. B. instantiiert von einem Elternthread (oder einer Elternfaser) die Ausführung gesteuert oder verteilt, sodass sie in Serie innerhalb eines bestimmten Prozessors (ein Prozessor kann selbst eine Gruppierung von Prozessorelementen sein und in einem Beispiel eine Vielzahl von SIMD-Prozessorelementen umfassen) und gleichzeitig parallel zu anderen Faserroutinen mit dem gleichen bzw. den gleichen (oder passenden) Faserschlüssel(n) ausführen. In einem Beispiel wird eine Gruppierung von Prozessorelementen, die im vorliegenden Kontext als Prozessor erachtet wird, danach bestimmt, welche Prozessorelemente einen bestimmten Faserspeicherplatz beschreiben können. In einem Beispiel gelten sämtliche Prozessorelemente, die auf einen bestimmten Faserspeicherplatz schreiben können, als Gruppe als Prozessor, um serielle Ausführung von Fasern durchzusetzen, die auf diesen bestimmten Faserspeicherplatz referenzieren. Derartiges Schreiben kann in Bezug auf eine Untergruppe von Speichern in einem System betrachtet werden, z. B. von lokalen Speichern, währen die Zugriffe womöglich nicht auf diese Weise behandelt werden.
In einem beispielhaften Aspekt greifen nur Fasern, die letztendlich auf einen gemeinsamen Ursprung zurückgehen, auf ein diesen Fasern zugewiesenes Faserspeicherelement zu. Somit greift eine Faser, die auf einen anderen Ursprung für diese Gruppe zurückgeht, nicht auf diesen Faserspeicherplatz zu. Ferner werden in beispielhaften Aspekten nie zwei oder mehr Fasern desselben Ursprungs zur parallelen Ausführung eingeplant, sodass keine Mutex- oder Lock-Verwaltung für die Faserspeicherplätze benötigt wird.
Jedoch kann in einem solchen beispielhaften Aspekt eine Faser sonst vollen Zugriff auf alle Merkmale aufweisen, die ein herkömmlicher Thread aufweist, darunter vollständiger globaler Speicherzugriff, lokaler Speicher, Barriers, Textur-Sampler, private Variablen und sämtliche arithmetischen und logischen Operationen. Die Faserroutine kann auch Argumente enthalten, die direkt aus den Kernelargumenten ihres Elternthreads stammen, was es der Faser ermöglicht, auf globale Basisregister und sonstige gemeinsame Variablen zuzugreifen. Auf diese Speicherplätze kann unter Verwendung herkömmlicher Speicherschutzverfahren zugegriffen werden.
Jeder Thread im System kann eine Vielzahl von Fasern definieren, jede mit einem entsprechenden Scheduling-Schlüssel. Ferner kann eine Vielzahl von Faserroutinen definiert werden, sodass ein bestimmter Thread eine Anzahl von Fasern definieren kann, die Instanzen verschiedener Faserroutinen sind. Wie oben stehend erläutert, überlappen sich Fasern derselben Faserroutine (die eine Code-Basis teilen) und aus demselben Ursprung (z. B. einem Elternthread oder einer Elternfaser) nicht bei der Ausführung in Implementierungen, die Mutexe oder Sperren vermeiden, um auf zumindest eine Variable oder Datenquelle zuzugreifen, die nur diesen Fasern zur Verfügung steht.
In manchen Umsetzungen kann eine API zur Instantiierung/zum Aufruf von Faserroutinen (wobei jede Faser ein Aufruf einer Faserroutine ist, wie oben stehend erläutert) von einem Elternthread (oder eine andere Faser) durch eine Semantik (wofür ein Beispiel weiter unten bereitgestellt ist) bereitgestellt sein. In manchen Aspekten und anders als bei einem Funktionsaufruf in einer typischen Multithreading-Umgebung versucht ein Kernel (oder eine sonstige Scheduler-Ressource im System) nicht zwingend sofort die derart aufgerufene Faser auszuführen oder ihre Ausführung vorzubereiten (wie das ein Thread in einer typischen Multithreading-Umgebung täte). Beispiele für solche Vorbereitungen wurden oben stehend vorgestellt.
Stattdessen wird in einem beispielhaften Aspekt ihre Aktivierung (die Zuweisung tatsächlicher Prozessorressourcen zur Ausführung) auf einen unbestimmten Zeitpunkt in der Zukunft verschoben. Ferner kann, nachdem ein Elternthread eine Faser instantiiert hat (z. B. durch Verwendung einer Faserdefinitions-API-Semantik), der Elternthread mit der Ausführung fortfahren, sofern dies sonst erlaubt ist (z. B. kann er damit fortfahren, ein aktiver Thread zu sein, seinen Programmzähler hochzählen und Hardware-Ressourcen verwenden). Eine API kann auch gleichzeitig eine Semantik für das Instantiieren einer Reihe von Fasern (z. B. von derselben Faserroutine oder von anderen Faserroutinen) bereitstellen. In einem Beispiel kann jede der Fasern einen gemeinsamen Faserschlüssel aufweisen, und in einem weiteren Beispiel können die Fasern denselben Faserschlüssel aufweisen, aber an einem oder mehreren verschiedenen Werten arbeiten.
Da in diesem beispielhaften Aspekt ein Elternthread nicht blockiert oder auf einen Rückgabewert aus dieser Faser wartet, gibt eine Faser keinen Rückgabewert an einen Elternthread zurück, wie das eine Standard-C-Funktion täte. Im Gegenteil, eine Faserroutine kann bei Abschluss einfach aufhören zu existieren (z. B. in ein Zombie-Stadium übergehen und auf den Entzug der Speicherressourcen warten) und kehrt nicht zum aufrufenden (Eltern-)Thread zurück. Somit muss eine Faser in diesem Aspekt, um wirksam zu sein oder nützlichen Output zu produzieren, Ergebnisse auf einen Faserspeicher schreiben. Es gilt zu beachten, dass zwar die Faser in der Lage ist, unter Verwendung einer Mutex- oder Sperren-Verwaltung Ergebnisse auf eine gemeinsame Speicherressource außerhalb der Faser zu schreiben (z. B. einen globalen oder lokalen Speicher), eine solche Operation aber wesentlich langsamer vonstatten ginge als ein Write auf einem Faserspeicher.
In einem beispielhaften Aspekt werden, da Fasern keinen Wert zurückgeben, Daten, die zwischen Fasern verbleiben (z. B. zwischen aus einem gemeinsamen Thread instantiierten Fasern), durch residente Daten eingegrenzt oder für resident im Faserspeicher erklärt. In der Praxis wird erwartet, dass die hier offenbarten beispielhaften Aspekte durch Zuweisen einer rasch verfügbaren Speicherressource an einen Faserspeicher angewandt werden, daher wird erwartet, dass es sich um eine stärker eingeschränkte Ressource handelt. Beispielsweise wäre bei einem Hauptspeicher und einem Cache-Speicher ein vergleichsweise größerer Anteil des Caches der Faserspeicherung zugeordnet als anderen Daten, die womöglich von Fasern verwendet werden.
Ein weiterer Aspekt mit einer gewissen Allgemeingültigkeit besteht darin, dass Fasern, die auf dasselbe Element der Faserspeicherung referenzieren, referenzgezählt werden (z. B. wird ein Zähler hochgezählt, wenn eine auf dieses Element referenzierende Faser der Faserspeicherung ausgegeben wird, und verringert, wenn eine solche Faser zum Abschluss kommt). Eine Referenzzählung, die Null erreicht, zeigt somit an, dass keine ausstehenden Fasern mehr übrig sind, die auf einen bestimmten Faserspeicherplatz referenzieren (oder auf -plätze in dem Fall, dass eine bestimmte Gruppe von Fasern auf mehrere Plätze referenziert). Somit kann eine solche Null erreichende Referenzzählung ein Auslöser für einen Elternthread sein, dass Daten in dem Faserspeicher zum Gebrauch und/oder zur Einholung verfügbar sind. Eine als Antwort auf den Nullwert gesetzte Markierung, z. B. eine durch eine eingebaute Funktion bereitgestellte Markierung, kann ferner beispielsweise von dem Elternthread überwacht werden.
Es folgt ein Beispielkonstrukt für das Codieren von Semantiken, die in einer Implementierung gemäß der vorliegenden Offenbarungen zum Einsatz kommen können. Dieses Beispiel dient der Erläuterung und nicht der Einschränkung dessen, wie eine bestimmte Implementierung strukturiert sein kann, oder des Inhalts einer solchen Implementierung.
_fibre: Dieses Attribut dient dazu, eine Funktion zur Faserroutine zu erklären. Bei einer Faserroutine steht dieses Attribut am Beginn der Funktionsdeklaration.
_fibrestorage: Dieses Attribut erklärt eine Variable als in Faserspeicherung vorliegend. Innerhalb eines Elternthreads werden Variablen, die auf Kinderfasern aufzuteilen sind, mit diesem Attribut deklariert. Faserroutinen deklarieren keine Faserspeicherung. Faserroutinen enthalten wenigstens ein Argument, das dieses Attribut aufweist.
_fibrekey: Ein Faserschlüssel (”fibre key”) dient dazu, ein oder mehrere Kriterien anzuzeigen, die beim Scheduling der Ausführung der Faser verwendet werden. Beispiele für Faserschlüssel umfassen ein Offset des globalen Speichers und eine Verzweigungsbedingung. Eine Plattform kann auf der Basis von Faserschlüsselanpassung einplanen, dass eine Faser parallel zu anderen Fasern verläuft. Bei einer Umsetzung enthält eine Faserroutinenfunktionsdeklaration genau ein Argument dieser Art.
+Fibrerouti ne(a, b): Eine Faserroutine (”fibre routine”) wird aufgerufen, indem ein herkömmlicher Funktionsaufruf vorgenommen, dabei aber ein +–Zeichen vor den Funktionsnamen gesetzt wird. Ein solcher Aufruf verursacht nicht unmittelbar einen Ausführungssprung zur Faserroutine, sondern verzögert ihren Aufruf bis zu einem späteren Zeitpunkt. Die Ausführung der Aufrufroutine kann normal fortgesetzt werden, und die Faserroutine gibt keinen Wert zurück, wie das ein normaler Funktionsaufruf tut.
bool is_initial_thread_launch(): Hierbei handelt es sich um eine eingebaute Funktion, die erst zur Geltung kommt, wenn sie bei ihrem ersten Start vom Elternthread aufgerufen wird. Diese Funktion ist der Einfachheit halber bereitgestellt, um zwischen der Elternthreadroutine, die von einem typischen Threadstart aufgerufen wird, und der Benachrichtigung zu unterscheiden, dass alle Kinderfasern von einem Elternthread abgeschlossen sind (diese kann ermittelt werden, indem ein Referenzwert Null erreicht).
Der Pseudocode im Anhang erläutert beispielhaft einen Faserberechnungsansatz, bei dem Threads Fasern instantiieren können, die sich gemäß der vorliegenden Offenbarung verhalten, und bei dem Fasern rekursiv andere Fasern instantiieren können, die auf denselben Faserdatenspeicher referenzieren, aber unterschiedliche Scheduling-Schlüssel aufweisen.
Angesichts der oben stehenden einführenden Erläuterung und im Sinne weiterer Erläuterung wird nachstehend eine Vielzahl von Architekturbeispielen und Betriebssituationen erläutert. Architekturen, in denen Faserberechnungsaspekte angewandt werden können, sind mannigfaltig. Eine beispielhafte Art von Architektur ist eine, bei der eine Vielzahl von Berechnungsclustern jeweils eine Vielzahl von arithmetisch-logischen Einheiten (ALUs) und eine lokale Steuereinheit, die die ALUs steuert, umfasst. In einem konkreteren Beispiel für eine solche Architektur werden alle ALUs eines Clusters von einem gemeinsamen Programmzähler aus betrieben, der von der lokalen Steuereinheit ausgewählt ist. Jede ALU kann jedoch einen unabhängigen Anschluss an einen lokalen Speicher aufweisen. In manchen Beispielen kann der lokale Speicher ähnlich wie ein Registersatz eines Allzweckprozessors arbeiten; jede ALU kann von dem lokalen Speicher lesen und auf diesen schreiben. In manchen Umsetzungen kann der aktive Programmzähler in jedem Cluster auf Befehl verändert werden, und zwar auf Befehlsbasis, ohne Suchzeit. In manchen Architekturen mit einer solchen Vielzahl von Clustern können ganze Threads in jedem Cluster ausgeführt werden, und der Status für solche Threads kann in den lokalen Speichern der Cluster aufrechterhalten werden. In manchen Implementierungen kann eine lokale Steuereinheit Fasern in dem Sinne anders behandeln als Threads, wie ihre Ausführung in den von dieser lokalen Steuereinheit gesteuerten ALU eingeplant wird. In manchen Implementierungen ist keine Faser, die auf einen gemeinsamen Faserspeicherplatz referenziert (d. h. die Fasern teilen sich einen gemeinsamen Ursprung) zur gleichzeitigen Ausführung in dem Cluster in irgendeiner Implementierung, bei der Speicherarbitration nicht umgesetzt ist, eingeplant. Eine Beispielarchitektur vermeidet ausdrücklich Arbitration für lokalen Speicherzugriff durch Fasern, sodass die Speicherzugriffe beschleunigt werden können.
Beispielhafte Arbeitsbelastungen, die in Berechnungsarchitekturen verarbeitet werden, bei denen offenbarte Aspekte umgesetzt sind, betreffen in erster Linie Grafikrendering-Arbeitsbelastungen, und konkret wird Strahlenverfolgung als Hauptanwendungsbeispiel für Faserberechnungsprinzipale bereitgestellt. Eine Vielzahl von Berechnungsproblemen kann jedoch durch die Anwendung offenbarter Aspekte der Faserberechnung bewältigt werden. Im Kontext der Umsetzung von Strahlenverfolgungsfunktionalität unter Anwendung von Aspekten der Faserberechnung kann ein Grafikchip weiterhin auf Rasterisierung basierende Grafikverarbeitung mit Threads berechnenden Prinzipalen und unter Verwendung derselben Vielzahl an Berechnungsclustern implementieren. Vertex- und Pixel-Shading-Funktionen, die auf ähnliche Weise auf Geometrie und Bildverarbeitung anwendbar sind, können gemäß Faserberechnungs- oder Threadberechnungsprinzipien implementiert werden.
Faserberechnungssystemarchitekturen sorgen also für die Verträglichkeit von spezifizierten Arbeitsbelastungen aus unterschiedlichen Quellen, z. B. verschiedenen Threads oder anderen Fasern. Jede Arbeitsbelastung kann ein erstes und ein zweites Datenelement aufweisen, wobei eines der Datenelemente als Scheduling-Schlüssel verwendet werden kann, um zu steuern, wie diese Arbeitsbelastung mit anderen Arbeitsbelastungen gruppiert wird, und das andere steuert, wo unter einer Vielzahl von Berechnungselementen diese Arbeitsbelastung ausgeführt wird.
Architekturen beispielhafter Systeme, in denen offenbarte Aspekte angewandt werden können, sind in den 1 und 2 dargestellt. 1 zeigt eine Architektur eines beispielhaften Systems 10, bei dem gleichzeitiges und paralleles Processing und Scheduling gemäß der vorliegenden Offenbarungen implementiert werden kann. Systeme gemäß dem beispielhaften System 10 können z. B. dazu verwendet werden, Grafikprozessoren zu implementieren.
Eine Host-Schnittstelle 40 kann eine Thread-API 42 umfassen und kann eine Faser-API 41 umfassen. Die Faser API 42 kann von Routinen verwendet werden, die auf einem Host-Prozessor (nicht abgebildet) ablaufen, um neue Threads zu instantiieren, die auf dem System 10 auszuführen sind. Die Thread-API 42 kann z. B. als Hardware-codierte API bereitgestellt sein, die in einem System-on-a-Chip (SoC) mit einem oder mehreren allgemein programmierbaren Prozessorkernen zur Verfügung steht, wie z. B. einem Berechnungskern, der gemäß einer Architekturspezifikation und mit einer Befehlssatzarchitektur operiert. In anderen Beispielen kann die Thread-API 42 mit einem Treiber für eine Add-on-Karte bereitgestellt sein, die Grafikverarbeitungsbelastungen aus dem Host-Prozessor ablädt.
In einem Beispiel, und wie unten stehend beschrieben, kann die Faser-API 41 von Threads verwendet werden, die auf dem Host-Prozessor ablaufen, um Fasern zu instantiieren, die in Systemen gemäß dem beispielhaften System 10 ausgeführt werden. Wie untenstehend beschrieben ist, können Threads, die in solchen Systemen ausgeführt werden, auch auf eine API zugreifen, die gemäß den vorliegenden Offenbarungen bereitgestellt ist, sodass Threads, die auf dem System ausgeführt werden, auch Fasern zur Ausführung definieren können. In manchen Beispielen ist eine Faser-API nicht auf der Ebene der Host-Schnittstelle exponiert, sondern wird nur für Threads verfügbar gemacht, die innerhalb des Grafikprozessorsystems 10 ausführen.
Das beispielhafte System 10 umfasst eine Reihe von Mastern, die bewirken, dass eine Einrichtungsberechnung im System 10 durchgeführt wird. In manchen Beispielen ist die in System 10 durchgeführte Berechnung deutlich regelmäßiger und umfangreicher als typischer Anwendungscode, der zur Ausführung auf einem Prozessor vorgesehen ist. Vielmehr können Arbeitsbelastungen z. B. Arbeitsbelastungen zum Schattieren großer Gruppen von Vertices oder Pixeln umfassen. Vertex-Datenmaster 10 und Pixel-Datenmaster 11 können bereitgestellt werden, um die Verwendung der (untenstehend beschriebenen) verfügbaren Berechnungselemente zur Durchführung einer solchen Berechnung einzurichten. Ferner können z. B. der Berechnungs-Datenmaster 2 und der Strahlen-Datenmaster 13 bereitgestellt werden, um eine Berechnung für ein breites Spektrum an numerischen Analyseprogrammen bzw. für Arbeitsbelastungen zur Strahlenverfolgung einzurichten.
Der Grob-Scheduler 44 empfängt Eingaben von Datenmastern, wie z. B. den obenstehend beschriebenen Datenmastern 10 bis 13. Der Grob-Scheduler kann bewirken, dass unabhängig betriebsfähige Berechnungselemente die Berechnungsbelastungen durchführen, die von den Datenmastern stammen können. Der Grob-Scheduler empfängt Statusinformationen von im System 10 verfügbaren Ressourcen. Diese Ressourcen umfassen Speicherstatus, die innerhalb einer Anordnung von Clustern 65 (unten stehend beschrieben) liegen. Solche Speicher können für bestimmte Berechnungseinheiten (z. B. die Kerne 70 bis 73) innerhalb der Anordnung von Clustern 65 reserviert sein, z. B. die Speicher 76 bis 79. Diese Speicher 76 bis 79 können als Caches umgesetzt sein, die unter den Threads zugewiesen sein können, die auf dem an den jeweiligen Speicher gekoppelten Kern ausführen (z. B. kann der Speicher 76 unter den auf dem Kern 71 ausführenden Threads zugewiesen sein). Die Zuweisung solcher Speicher kann durch den Grob-Scheduler 44 verwaltet werden. Jeder Datenmaster (Vertex-, Pixel-, Berechnungs-, Strahlen-) kann Speicherzuweisungsanforderungen an den Grob-Scheduler 44 übermitteln. Aspekte des Betriebs des Grob-Schedulers 44 und der Kommunikation zwischen einem Datenmaster für Zwecke des Thread-Schedulings und der Ressourcenzuweisung werden in der US-Patentveröffentlichung Nr. 2007/0101013 an Howson, die zur Gänze hierin durch Verweis aufgenommen ist, beschrieben. Ein solcher Vorgang ist beispielhaft, nicht erschöpfend; ein solcher Vorgang kann auch im Lichte der vorliegenden Offenbarungen angepasst werden.
Das beispielhafte System 10 umfasst auch eine Paketeinheit 105, die Bestandteile eines betriebsbereiten Stapelregisters 106, eines Sammlungsdefinitionsspeichers 107, eines leeren Stapelregisters 108 und einer Paketeinheit 109 umfasst. Die Funktionalität, die Verwendung und der Betrieb der Paketeinheit 105 innerhalb der beispielhaften Architektur 10 wird untenstehend beschrieben. Das beispielhafte System 10 kann auch eine Vielzahl von Koprozessoren umfassen, die zur Durchführung spezieller Funktionen angepasst und als Koprozessoren 115 bis 117 dargestellt sind. Weitere Sonderzweckfunktionalität kann bereitgestellt werden, wie z. B. ein Texturlader 118.
1 zeigt, dass von dem Grob-Scheduler 44 eingeplante Threads von einem Aufgabenverteiler 45 verteilt werden können. In der dargestellten Architektur von 1 können die Anordnung von Clustern, der Scheduler 44 und die Datenmaster 10 bis 13 allesamt unter Verwendung eines Busses 43 kommunizieren. Freilich ist ein Bus 43 ein beispielhafter Ansatz zur Kommunikation unter den dargestellten strukturellen und funktionellen Elementen, und auch andere Ansätze, wie z. B. eine Vermaschungsverbindung, ein mehrstufiges Netzwerk etc., können bereitgestellt werden.
Das beispielhafte System 10 kann auch eine Cache-Hierarchie 15, die eine oder mehrere Ebenen Cache-Speicher umfasst, und eine Systemspeicherschnittstelle 16 umfassen, die an einen Hauptspeicher anknüpft, der als eine oder mehrere von Hochgeschwindigkeitsgrafik RAM, DRAM und dergleichen implementiert sein kann. Ansätze einer umfangreichen Speicherkapazität können mit der Entwicklung neuer Technologien angepasst werden, und die Verwendung hinlänglich bekannter Akronyme wie DRAM soll die Anwendbarkeit der offenbarten Aspekte nicht auf einen bestimmten Prozess oder eine bestimmte Speichertechnologie beschränken.
2 zeigt ein weiteres beispielhaftes System 202, in dem offenbarte Aspekte angewandt werden können. Das System 202 umfasst eine Paketeinheit 205, die ein leeres Stapelregister, eine lokale Speicherzuweisungsvorrichtung 208, ein betriebsbereites Stapelregister 210, einen Sammlungsdefinitionsspeicher 212 und ein Paket 214 umfasst. Die Paketeinheit 205 kann mit dem Grob-Scheduler 222 kommunizieren, der ein Threadspeicherstatusmodul 220 umfassen kann. Die Paketeinheit 205 sammelt Gruppierungen von Fasern, die innerhalb der Vielzahl von Berechnungsclustern verteilt werden sollen, die Arbeit ausführen werden, welche von den Fasern spezifiziert ist, wie unten stehend beschrieben. Der Grob-Scheduler 222 verfolgt die Nutzung von Berechnungsressourcen in der Vielzahl von Berechnungsclustern, wie z. B. Speicherzuweisung und -nutzung. In manchen Umsetzungen ist eine Zuweisung eines Teils eines lokalen Speichers in einem bestimmten Berechnungscluster statisch und wird zugeordnet, wenn der Thread auf diesem Berechnungscluster eingerichtet wird. Der Grob-Scheduler 222 kann auch Fasern zur Ausführung in den Clustern zuweisen.
In einem Beispiel kann ein auf einem bestimmten Cluster ausführender Thread eine Faserroutine instantiieren (und dadurch eine Faser herstellen). Der Grob-Scheduler 222 kann die die Instanz betreffende Information empfangen und einen bestimmten Cluster für die Ausführung der Faser zuweisen. Wie oben eingeführt deutet die Zuweisung einer Faser für die Ausführung auf einem Cluster nicht darauf hin, dass die Ausführung augenblicklich beginnt, sondern die Ausführung einer solchen Faser ist abhängig von
Eine Abstraktions-/Verteilungsschicht 225 trennt eine Reihe von Berechnungsclustern (die Cluster 227 und 229 sind abgebildet) von einem Grob-Scheduler 222 und von der Paketeinheit 205. Die Verteilungsschicht 225 akzeptiert Fasergruppierungen von der Paketeinheit 205 und führt zur Verteilung der Faser entlang der Berechnungscluster, gemäß einem unten beschriebenen beispielhaften Ansatz. Die Schicht 225 ist ein Beispiel für die Verteilung der Gruppierungen in Berechnungsregionen, die die Berechnung ausführen.
Jeder Cluster umfasst eine entsprechende Steuereinheit (Steuereinheit 230 und 232 sind für Cluster 227 bzw. 229 abgebildet). Jede Cluster-Steuereinheit (z. B. 230 und 232) steuert eine Vielzahl arithmetischer logischer Einheiten (ALU) (z. B. Cluster-Steuereinheit 230 steuert eine Vielzahl von ALU einschließlich ALU 235 und ALU 236). Jede ALU eines Clusters kommuniziert mit einem lokalen Thread- und Fasernpeicher (z. B. lokaler Thread- und Fasernpeicher 240). In einer Ausführung hat jede ALU einen separaten und zugeordneten Zugriffspfad zum lokalen Thread- und Fasernpeicher, so dass jede ALU gleichzeitig mit anderen ALUs dieses Clusters aus dem Speicher lesen, bzw. in den Speicher schreiben kann. Speicherressourcen eines bestimmten Clusters umfassen zudem einen gesendeten Datenspeicher (z. B. gesendeter Datenspeicher 260 von Cluster 227). In einer beispielhaften Ausführungsform kann der gesendete Datenspeicher 260 im selben physischen Speichermedium wie der lokale Thread- und Fasernpeicher 240 umgesetzt werden. Ein Beispiel für einen gesendeten Datenspeicher 260 kann ein stark verschachtelter Cache sein, der erlaubt, eine bestimmte Stelle des Speichers auf eine Reihe verschiedener Stellen im gesendeten Datenspeicher abzubilden. In einigen Ausführungsformen kann der gesendete Datenspeicher einen Ringpuffer oder eine FIFO-Speicherimplementierung umfassen. Diese übertragenen Datenspeicher werden durch eine direkte Speicherzugriffeinheit (DMA) 241 gespeist. In einer beispielhaften Ausführungsform steuert die DMA 241 die Datenspeicherung in einer Vielzahl von gesendeten Datenspeichern in einer Reihe von Clustern. Ein Cluster ist ein Mittel, um gleichzeitige Berechnungen auf einer entsprechenden Vielzahl von Datenelementen mittels eines entsprechenden einzelnen Steuerflusses durchzuführen.
Jeder Cluster umfasst einen Eingabepuffer, z. B. umfasst Cluster 227 den Eingabepuffer 267. Jeder Eingabepuffer für jeden Cluster wird von der Verteilungssschicht 225 geschrieben und von der entsprechenden Steuereinheit dieses Clusters gelesen. Beispielsweise schreibt die Verteilungsschicht 225 in den Eingabepuffer 267, was von der Cluster-Steuerung 230 gelesen wird.
Angesichts der oben stehenden Einführung in die Bestandteile des Beispielsystems 202 werden Aspekte der Bedienung dieses Beispielsystems 202 unten stehend beschrieben.
3 zeigt einen Aspekt der Faserberechnung, wobei der Elternthread 305 eine erste Faser 308 instantiieren kann; die erste Faser 308 kann rekursiv eine weitere Gruppe von Fasern instantiieren, die kollektiv als 310 identifiziert werden. Ähnlich dazu können diese Fasern weitere kollektiv als 312 identifizierte Fasern instantiieren und so weiter bis zu den Fasern 314. Jede der in 3 abgebildeten Fasern bezieht sich auf einen lokalen Speicherplatz 317 und umfasst, wie beschrieben wird, zumindest ein weiteres Datenelement, das unter den Fasern variiert und was als ein Scheduling-Schlüssel zur Gruppierung von Fasern von verschiedenen Elternthreadquellen für die Verteilung und Ausführung unter den Berechnungsclusters verwendet werden kann. Während die abgebildeten Fasern auf einem Cluster (oder mehreren Clustern) ausführen, kann der Elternthread 305 die Ausführung unterbrechen oder mit der Ausführung eines unabhängigen Codes fortfahren. Zum Beispiel kann nach der Instanziierung der Fasern 308 kann der Elternthread 305 mit der Ausführung des Codes fortfahren, auch wenn die Fasern 308 bis 314 gleichzeitig auf demselben Cluster ausführen.
4 zeigt Beispielschritte, in denen eine heterogene Berechnungsarchitektur gleichzeitige Thread- und Faserausführung unterstützen kann. In 4 kann Thread 305 einen neuen Thread instantiieren, indem er einen neuen Thread 318 abspaltet. Jeder der darin verwendeten Datenmaster kann auch einen Eingabeanfrage für einen neuen Thread durchführen, um einen neuen Thread auf einer Anordnung von Clustern auszuführen. Scheduler 272 kann nach dem Erhalt von Abspaltung 318 die für die Durchführung oder andere Ausführung des Threads erforderlichen Ressourcen identifizieren; die für die Ausführung des Threads erforderlichen Ressourcen können mit dem derzeitigen Ressourcenverbrauch unter den verschiedenen Clustern in der Clusteranordnung 65 (im Beispiel von 1) verglichen werden. Zusätzlich dazu kann bei 324 eine Priorität des Threads identifiziert werden; Threads mit höherer Priorität können Priorität bei der Ausführung erhalten. Bei 326 kann dem Thread, der als bereit bestimmt wurde, die Ausführung zu beginnen, Speicher zugewiesen und andere Ressourcen innerhalb eines bestimmten Clusters, in dem der Thread ausgeführt werden wird, zugeordnet werden. Anschließend kann der Cluster, dem der Thread zugeordnet wurde, für das Scheduling (328) verantwortlich sein, wenn die Befehle innerhalb dieses Threads ausgeführt werden, um den Thread als Ganzes auszuführen.
4 wählt ebenfalls einen Beispielfluss für die Einrichtung einer innerhalb der Cluster-Anordnung 65 auszuführenden Faser. Insbesondere zeigt 4, dass eine neue Faserinstanz empfangen werden kann 330. In einem Beispiel kann die Faserinstanz einen Scheduling-Schlüssel umfassen, der, bei 332, identifiziert wird. Bei 333 wird ein Sammelgruppierungsalgorithmus ausgeführt. Der Sammelgruppierungsalgorithmus läuft, um Fasern basierend auf passenden Scheduling-Schlüssel der entsprechenden Fasern zu sammeln. Zusätzlich dazu kann jede instanziierte Faser einer entsprechenden Priorität zugeordnet werden. Bei 334, welche Prioritäten bestimmt und für die Bildung einer repräsentativen Priorität für eine Fasersammlung verwendet werden können. Bei 336 kann ein Algorithmus durchgeführt werden, um Sammlungen von auf der Clusteranordnung auszuführenden Fasern auszuwählen. Fasern ausgewählter Sammlungen identifizierende Information wird anschließend unter den Clustern in der Anordnung verteilt, wie unten erklärt wird. Bei 337 wird die Verteilung der ausgewählten Sammlungen) von Fasern unter den Clustern durchgeführt.
5 zeigt weitere Aspekte der Deklaration von Fasern, einschließlich der Deklaration von Faserspeicherelementen für die entsprechenden instanziierten Fasern und weitere Aspekte der Sammlung von Fasern entsprechend ihrer Scheduling-Schlüssel. Aspekte von 5 können zum Beispiel innerhalb von Paketeinheit 205 (2) implementiert werden.
In dem in 5 abgebildeten Beispiel resultiert eine erste instanziierte Faser, wie Faserinstanziierung 360 in der Zuweisung von deklarierter Faserdatenspeicherung 351, welche durch einen Schreibspeicher 355 bestückt werden kann. Mit fortgeschrittener Berechnungszeit können zunehmend mehr Fasern rekursiv instanziiert werden, welche alle auf die Faserdatenspeicherung 351 referenzieren. Jedoch würde jede dieser instanziierten Fasern üblicherweise über einen anderen Scheduling-Schlüssel verfügen und daher mit äußerst unterschiedlichen Fasern, die auf verschiedene Faserdatenelementspeicherungen referenzieren, gruppiert werden. Bei jeder weiteren rekursiven Instanziierung einer Faser wird der diesen Fasern zugeordnete Referenzzähler erhöht. Beispielhafte Anwendungen und andere Manipulationen eines solchen Referenzzählers werden unten beschrieben.
Diese Konzepte werden in 5 mit deklarierten Faserdatenelementspeicherungen 352 und 353 abgebildet, die jeweils von einer anderen Faserverzweigung referenziert werden. 5 zeigt zudem, dass all die instanziierten Fasern durch eine zentrale Fasersammlung und -instanziierung 358, welche Sammlungen jener Fasern entsprechend ihrer Scheduling-Schlüssel bilden, verwaltet werden können. Fasersammlung und -instanziierung 358 gibt Sammlungen zur Ausführung innerhalb der verfügbaren Rechnerressourcen aus. Während einer solchen Ausführung kann jede Faser ihr entsprechendes Faserdatenelement wie in der Legende abgebildet referenzieren, was darauf hinweist, dass Lesen/Schreiben während der Ausführung für alle Fasern, wiederholt werden kann, die von einer Anfangsfaserinstanz abstammen, welche ein bestimmtes Faserdatenelement geschaffen hat.
5 zeigt daher verschiedene Beispiele für Faserberechnungskonzepte. Viele Fasern senden oder werden auf andere Art rekursiv instanziiert von einer ursprünglichen Faserinstanz, die, wie in 3 und 4 gezeigt wird, von einem Thread geschaffen werden kann. Im Gegensatz dazu ist durch typisches Multithreading nicht unbedingt jede Faser zur Ausführung eingeteilt, oder wird überhaupt versucht sie einzuteilen. Tatsächlich werden instanziierte Fasern entsprechend einem Scheduling-Schlüssel gesammelt. Im Beispiel von 5 kann die Planung durch eine zentrale Planungsressource, die Fasersammlungen, die unter einer Vielzahl unabhängig ausführbarer Berechnungscluster als zur Ausführung bereit festgelegt wurden, final verteilen. Unabhängig von einer Reihe von Threads, die von einem bestimmten Thread abstammen kann jeder Thread letztendlich auf dasselbe Element der Faserdaten zugreifen. Wie in einem Beispiel beschrieben werden wird, wird jeder Thread, der auf ein bestimmtes Faserdatenelement referenziert, zur seriellen Ausführung auf einem einzelnen Cluster oder einer Clusteranordnung oder einer parallel verfügbaren Rechnerressource zur Ausführung gebracht. Zudem, da in vielen solchen Beispielen jedes Berechnungscluster unabhängig operieren kann, um zwischen der Ausführung einer Vielzahl von Threads und Fasern umzuschalten, wird die Ausgabe einer Fasersammlung vom zentralen Fasersammlungspunkt nicht ganz genau steuern, wann solche Fasern ausgeführt werden, sondern eher wie unten beschrieben werden die Fasern der Sammlung in einem geeigneten Eingabepuffer für ein Cluster gespeichert, in dem diese Fasern letztendlich ausgeführt werden.
6 setzt mit dem Bespiel aus 5 fort; 6 zeigt einen Stream einlangender Fasergruppen 432, eine Abstraktion zur Scheduling- und Arbeitsverteilung 430 verursacht, dass die Fasergruppen unter der Vielzahl von Clustern aufgeteilt werden, zwei davon werden in 6 abgebildet. Die Verteilung im Bespiel von 6 umfasst das Speichern einer Referenz auf die Faser und andere Daten, die unten beschrieben werden innerhalb eines entsprechenden lokalen Speichers für jedes Cluster, auf das von einem Scheduler für dieses Cluster zugegriffen wird. Insbesondere liest ein ALU-Cluster-Scheduler 420 von einem lokalen Speicher 424 und erhält diesen aufrecht, während der ALU-Cluster-Scheduler 422 von einem lokalen Speicher 426 liest und diesen aufrechterhält. Jeder ALU-Cluster-Scheduler 420 bis 422 steuert, welcher Stream von Befehlen auf seinem jeweiligen Cluster 416 bis 418 ausgeführt wird. Im Bespiel von 6 hat jeder Cluster 416 bis 418 Lese- und Schreibzugriff auf einen jeweiligen Cache 410 bis 412. Zusätzlich dazu hat jedes ALU-Cluster 416 bis 418 auch Lesezugriff auf einen jeweiligen einfachen Cache 411 und 413. Eine operative Unterscheidung zwischen Cache 410 und 412 mit Bezug auf ihre Gegenstücke, die einfachen Caches 411 bis 413 besteht darin, dass der einfache Cache häufig mit verschiedenen Daten überschrieben werden soll und die temporäre Lokalität unter den Datenzugriffen relativ niedrig sein soll. Im Gegensatz dazu sollen Caches 410 und 412 eine höhere temporäre Lokalität aufweisen. Im Beispiel von 6 speist eine Hauptspeicherhierarchie 405 die einfachen Caches 411 bis 412 abhängig von direkten Anfragen für Speicherzugriffeinrichtungen, die zum Beispiel durch die Arbeitsverteilungsabstraktion 430 generiert werden können. Jedoch würden die Caches 410 und 412 üblicherweise eingerichtet werden, um Faserdatenelemente zu speichern, zusätzlich zur lokalen Threadspeicherung. Daher wären diese Caches primär für die Thread- und Faserinstanziierung gesteuert und nicht basierend auf befehlsspezifischen Speicher-Lesezugriff-Anforderungen, insbesondere für die Faserausführung.
7 zeigt eine Beispielstruktur für ein Cluster, das zum Beispiel in der in 1 oder 2 abgebildeten Clusteranordnung verwendet werden kann. 7 zeigt, dass eine Cluster-Steuereinheit 455 eine Vielzahl von Programmzählern 456 bis 458 aufrechterhalten kann. Jeder Programmzähler kann zur Referenzierung auf Programmbefehlssequenzen, die aus einer Befehlsspeicherhierarchie 460 verfügbar sind, verwendet werden. In einigen Beispielen kann die Befehlsspeicherhierarchie einen Befehlscache umfassen, in dem kürzlich verwendete Befehle gespeichert werden können. Ein solcher Befehlscache kann zum Beispiel einen zuletzt verwendeten Algorithmus implementieren oder einen Trace-Cache-Ansatz, in dem eine Sequenz von Befehlen inklusive Branches innerhalb des Caches aufrechterhalten wird. Ein Trace-Cache-Ansatz kann für ein Cluster, in dem die ALU spekulative Befehle durchführen können, geeigneter sein, z. B. in dem ein Cluster-Controller einen prädiktiven Mechanismus umfassen kann um vorauszusagen, ob Branches verwendet werden oder nicht.
Ungeachtet der speziellen Implementationssequenz der Befehle, z. B. Befehl 462 und Befehl 464 können aus der Befehlsspeicherhierarchie 460 an eine Vielzahl von ALU 471 bis 473 geschickt werden. Daher führt jede in der in 7 abgebildeten Ausführung enthaltene ALU denselben Befehl aus; jedoch können die für die Ausführung dieses Befehls bereitgestellten Daten variieren. Jede ALU übermittelt Faserabschlussinformationen 476 und kann Anfragen erstellen oder auf andere Art Informationen für neue Fasern 475 bereitstellen. Der Faserzuweisungsstatus kann durch ein Faserzuweisungsmodul 479 für ein Cluster aufrechterhalten werden. In einigen Beispielen kann ein solches Modul in der Steuereinheit 455 umfasst sein. Ein solches Modul kann Statusinformation vom globalen Scheduler 478 empfangen. Zum Beispiel kann solche Faserinformation Information für neue innerhalb des Clusters auszuführende Fasern umfassen. Weitere Informationen, die zwischen dem globalen Scheduler und dem Cluster aufrechterhalten werden können umfasst Faserreferenzzählinformation, wobei in einigen Beispielen solche Faserreferenzzählinformation innerhalb des Clusters auf dem verwandte Fasern ausführen aufrechterhalten werden kann. In anderen Worten kann eine Beispielimplementierung die Ausführung aller verwandten Fasern auf einem einzigen Cluster verursachen und in einer solchen Ausführung können Referenzzählungen innerhalb dieses Clusters für diese verwandten Fasern aufrechterhalten werden.
Das Beispiel von 7 zeigt ebenfalls, dass jede ALU 471 bis 473 einen Anschluss zu einem Cache 480 aufrechterhält. Der Cache 480 speichert lokale Daten wie vom lokalen Threadspeicher 485 bis 487 gezeigt; der Cache 480 kann ebenfalls globale Cachevariablen 488 speichern. Der Cache 480 umfasst ebenfalls eine Vielzahl von Faserspeicherplätzen 490 bis 492. Das Beispiel von 7 umfasst ebenfalls eine Übertragungswarteschlange 495. Im Beispiel von 7 kann jede ALU 471 bis 473 den Cache 480 auf eine ähnliche Art wie einen Registrierungssatz verwenden, der derart eingestellt ist, dass die SIMD-Cluster-Steuereinheit 455 Befehle für verschiedene Threads und verschiedene Fasern einplant, und zwar auf Befehlsbasis, ohne Suchzeit. Cache 480 kann durch eine Cache-Kohärenz/Steuerung 481 gesteuert oder auf andere Weise kohärent gemacht werden. In manchen Umsetzungen kann ein Cache 480 verschiedenen Anteilen, die unterschiedlich gesteuert werden, zugewiesen werden. In einem Bespiel kann der Cache 480 in einen Cache-Teil und einen gesteuerten Abschnitt aufgeteilt werden. Der Cache-Teil wird entsprechend der während des Prozessierens der Befehlssequenz in den ALU 471 bis 473 generierten Lese-/Schreibtransaktionen bespielt werden. Der Cache-Teil strebt danach, die Kohärenz mit anderen Teilen einer Speicherhierarchie aufrechtzuerhalten und Schreibvorgänge auf den Cache würden daher Kohärenztranskationen generieren. Darüber hinaus können zum Erreichen eines cacheartigen Verhaltens im Cache-Teil Techniken wie Tag-Speicher und Kohärenzindikationen für den Cache-Teil aufrechterhalten werden.
Der gesteuerte Abschnitt wird einem speziellen lokalen Datenspeicher während der Berechnung zugewiesen und hat keine Erwartung oder Ziel mit einem anderen Speicher oder Speicherhierarchie kohärent zu sein. Der gesteuerte Abschnitt verwendet keine Tag-Speicher oder Kohärenzangaben, da der gesteuerte Abschnitt mit Daten in bekannten Orten eingerichtet ist und der Speicher wird nicht für Kohärenz aufrechterhalten. Aus diesem Grund wird ein ordnungsgemäß initiierter und ausführender Code, der auf den gesteuerten Abschnitt zugreift, in der Lage sein, von dem gesteuerten Abschnitt zu lesen und/oder in ihn zu schreiben ohne durch Kohärenz erzwungene Einschränkungen. Faserspeicher 490 bis 492 ist ein Beispiel für einen solchen Speichertyp. Ein globaler Scheduler oder Arbeitsverteilung kann in der Einrichtung der gesteuerten Abschnitte clusterlokaler Speicher teilnehmen. Zum Beispiel kann die Scheduling-Abstraktion 430 oder lokale Speicherzuweisung 208 diese Funktion durchführen. Der Grob-Scheduler 222 kann mit der lokalen Speicherzuweisung 208 zusammenarbeiten, um die Zuweisung der von Threads und/oder Fasern verwendeten Caches und die Abschnitte solcher Caches, die wie Caches funktionieren werden, zu koordinieren. In manchen Situationen kann der Cache-Teil von Fasern als Read-Only-Speicher behandelt werden, sodass die Förderung der Kohärenz keine Transaktionen zum Zurückkopieren generiert.
8 zeigt ein dynamisches Beispiel von Sammlung, Scheduling und verteilter Ausführung von Faserroutinen auf einer Vielzahl von Berechnungskernen 543 bis 545. Genauer zeigt das abgebildete Beispiel, dass eine Reihe zu prozessierender Fasern 505 instanziiert werden kann. Solch eine Instanziierung kann auftreten wenn Threads Fasern instantiieren oder wenn Fasern abgeleitete Fasern instantiieren. In manchen beispielhaften Umsetzungen können Threads neuen Faserspeicher instantiieren, aber Fasern können nur abgeleitete Fasern schaffen, die bereits instanziierten Faserspeicher innerhalb der instantiierenden Faser referenzieren. 8 zeigt, dass jede Faserdefinition einen Scheduling-Schlüssel 510, eine Datenreferenz 511 umfasst und zudem eine Priorisierungsinformation 512 umfassen kann. Die Datenreferenz 511 soll eine Referenz für Faserspeicherung sein. Der Scheduling-Schlüssel 510 kann abgeleitet werden oder er kann explizit sein.
8 zeigt zudem zwei Funktionsmodule, eines davon ist ein Sammlungsbildungsmodul 515 und das andere ein Faserspeicheraufrechterhaltungsmodul 516. Jede Funktion kann als Teil eines Scheduler-Moduls ausgeführt werden oder kann durch separate Hardware und/oder Software bereitgestellt werden. Diese Module empfangen Information über zu prozessierende Fasern 505. Diese Information kann während der Ausführung von Threads, Fasern oder einer Kombination davon in den Kernen 543–545 generiert werden. Die returnierte Information kann identifizierende Information für die Faser, wie einen Identifikationsstring (z. B. eine Zahl), Information über einen Scheduling-Schlüssel und Information über ein Programm, das bei der Ausführung der Faser laufen soll (z. B. ein Programmzähler), umfassen. Jedoch müssen nicht alle diese Informationen an das Sammlungsbildungsmodul 515 retourniert oder übertragen werden.
Beispielsweise können in manchen Ausführungsformen alle Fasern, die auf ein bestimmtes Faserspeicherelement referenzieren, auf dem Kern mit dem lokalen Speicher, zur Ausführung gebracht werden, welcher Zugriff auf das Faserspeicherelement hat (in einem Beispiel in dem es eine unzusammenhängende Trennung von Faserelementen unter den Speichern gibt). Daher kann in solchen Ausführungsformen, wenn eine auf ein solches Speicherelement referenzierende Faser eine andere Faser instanziiert, ein Teil der Information über die neu instanziierte Faser lokal gespeichert werden. Zum Beispiel kann die Information, die das Programm, welches die Faser ausführen wird, identifiziert, lokal gespeichert werden; der Ort des referenzierten Faserspeicherelements kann ebenfalls lokal gespeichert werden (im Gegensatz zum Beispiel zum Senden aller Faserdaten an eine zentrale Sammlungsaufrechterhaltungsfunktion – hier das Sammlungsbildungsmodul 515).
Das Faserspeichererhaltungsmodul 516 arbeitet in Verknüpfung mit der Faserspeichereinrichtung 525, um Faserspeicherplätze in den verteilten Speichern der Kerne 543 bis 545 bereitzustellen oder zuzuweisen. Somit kann das Faserspeicheraufrechterhaltungsmodul 516 Information über laufende Speicherverwendung in den Kernen 543 bis 545 aufrechterhalten. Solche Speicherverwendung kann die lokale Threadspeicherung für Threads zusätzlich zur Faserspeicherung umfassen.
Der Sammlungsspeicher 518 speichert Identifikationen von Fasern, die mit ihrem Scheduling-Schlüssel korrelieren, sodass Gruppierungen von Fasern, die einen gemeinsamen Scheduling-Schlüssel aufweisen, gemeinsam ausgewählt und ausgegeben werden können. Der Scheduler 533 kann innerhalb von auszugebenden Fasergruppierungen auswählen, und durch ein bestimmtes Beispiel wird ein abgefertigtes Faserpaket 519 gezeigt. Paket 519 umfasst ebenfalls einen Paketidentifikator und einen Paketprioritätsindikator. Diese Elemente können durch den Scheduler 533 bei der Auswahl einer Gruppe von Fasern geschaffen werden, basierend auf dem Zusammenpassen ihrer Scheduling-Schlüssel. Anschließend werden die Fasern eines gegebenen Pakets unter den Eingabepuffern 540 bis 542 aufgeteilt, welche jeweils einem bestimmten Kern 543 bis 545 entsprechen. Die Verteilung der Fasern wird bestimmt basierend darauf, wo sich von einer bestimmten Faser verwendete Faserdatenelemente unter den verteilten Speichern der Kerne befinden. Ein solcher Speicher kann zum Beispiel basierend auf einer Faser-ID oder basierend auf einer expliziten Speicherreferenz ausgewählt werden.
Jeder Kern kann beim Ausführen von Arbeitslasten, welche Thread- und Faserroutinen umfassen können, Faserstatusinformation 549 ausgeben. Diese Statusinformation kann zum Beispiel neue durch andere Fasern oder Threads instanziierte Fasern, sowie Informationen darüber, welche Fasern abgeschlossen wurden, umfassen. Information über das Abschließen von Fasern kann verwendet werden, um die Referenzzähler von Fasern, die Zugriff auf dasselbe Element im Faserspeicher erfordern, zu verringern; ähnlich dazu führt die Instanziierung neuer Faser, die auf ein bestimmtes Faserspeicherelement referenzieren zu einem Ansteigen solcher Referenzzähler. Diese Referenzzähler können durch einen bestimmten Kern, auf dem eine Gruppe verwandter Fasern ausführt oder durch eine zentralisierte Ressource, wie zum Beispiel in 2 gezeigt wird, aufrechterhalten werden.
In einer Beispielausführung wird eine Sammlungsbildung 515 umgesetzt mittels eines hardwarebasierten Hashs, wobei jeder Faser entsprechend eines Hashs eines bestimmten Faseridentifikators ein Slot in einer Sammlung zugewiesen wird. Die Sammlungsbildungsfunktion 515 gruppiert Fasern anhand der Scheduling-Schlüssel. 8 zeigt die mit den jeweiligen Sammlungen assoziierten Scheduling-Schlüssel 520 bis 523, wobei die Sammlungen über unterschiedliche Anzahlen an Fasern verfügen, die alle innerhalb dem Sammlungsspeicher 518 umfasst werden.
Insgesamt zeigt 8 wie Faser-Streams in einer verteilten Berechnungsressource gleichzeitig instanziiert und prozessiert werden kann, aber ohne starre Kriterien mit Bezug auf Synchronisation von Zugriffen auf den Speicher oder Synchronisation von Programmausführungen unter verschiedenen Kernen der Berechnungsressource. In Wahrheit zeigt 8, dass Sammlungen durchzuführender Arbeiten, z. B. Fasern, gemacht werden mit dem Ziel einer Amortisierung des Zugriffes auf eine größere und langsamere Speicherressource und die Beständigkeit der Datenspeicherung, die fortwährend verwendet oder aktualisiert wird während einer bestimmten Sequenz von Computerelementen.
9 wird zur Erläuterung einer Beispieloperation eines Clusters verwendet, welche eine Vielzahl von entsprechend dieser Offenbarung arbeitenden ALU 234–237 umfasst. Eine ALU-Cluster-Steuereinheit 230 liest aus einem Eingabepuffer 267, um eine Vielzahl von durchzuführenden Arbeitsabschnitten zu identifizieren. In diesem Beispiel können die Arbeitsabschnitte durch Arbeits-IDs identifiziert werden, welche in einer Ausführung Programmzähler oder andere Referenzen auf auszuführende Befehle darstellen. In einer Beispielausführung können diese Arbeits-IDs laufende Programmzähler sein, die den nächsten auszuführenden Befehl für jede Faser im Eingabepuffer 267 indizieren. Natürlich können nicht alle Fasern im Eingabepuffer 267 jederzeit für die Ausführung innerhalb des Clusters aufgenommen werden und in diesem Fall können diese Arbeits-IDs einfach ein Identifikator eines ersten Befehls für eine für diese Fasern auszuführende Faserroutine sein. Daher kann in diesem Beispiel Statusinformation für auf die Ausführung wartende Fasern und für teilweise ausgeführte Fasern aufrechterhalten werden. Ein Grund warum solche Programmzähler in den Eingabepuffern aufrechterhalten werden können ist der, dass alle ALU im Cluster in manchen Ausführungsformen vom selben Programmzähler gesteuert werden können, sodass nur Fasern, die den nächsten Befehl ausführen sollen, für die Ausführung vom ALU-Cluster-Steuerelement 230 gesammelt werden können.
Diese Statusinformation ist für Ausführungsformen, bei denen die ALU-Cluster-Steuereinheit Faserroutinen während der Ausführung unterbrechen kann, so wie auf einer Befehl-für-Befehl-Basis. Jedoch können in anderen Ausführungsformen eine Gruppe von Faserroutinen aus dem Eingabepuffer 267, die die Ausführung noch nicht begonnen haben, eingeplant werden und können gänzlich ohne Unterbrechung und ohne Ausführung eines anderen Programm-Streams ausgeführt werden. In jedem Fall können Threads unterschiedlich behandelt werden, bei denen die ALU-Cluster-Steuereinheit die Ausführung von Threads unterbrechen kann, etwa zum Zweck der Ausführung ausgewählter Faserroutinen aus dem Eingabepuffer 267. Zum Beispiel können ausführende Threads unterbrochen werden, um eine Faserroutine durchzuführen.
9 zeigt zudem, dass aus dem Eingabepuffer 267 ausgewählte Arbeits-IDs in eine lokale Faser-Scheduling-Ausgabe 560 gruppiert werden. In diesem Beispiel für Fasern kann jede mit einer passenden Arbeits-ID in Ausgabe 560 umfasst sein. Jede Faserreferenz kann verwendet werden, um ein bestimmtes Faserspeicherdatenelement aus dem lokalen Thread- und Faserspeicher 240 abzurufen und dieses entsprechende Faserspeicherdatenelement verschiedenen ALU 234 bis 237 bereitzustellen. Ähnlich kann jede in der Scheduling-Ausgabe 560 umfasste Faser auf ein oder mehrere in einem einfachen Cache 260 gespeicherte Datenelemente referenzieren.
In einem Beispiel kann jede Faser auf unterschiedliche Datenelemente in einem einfachen Cache 260 referenzieren und in anderen Ausführungsformen können viele dieser zur Ausführung auf der ALU 234 bis 237 eingeplanten Fasern auf dasselbe Datenelement aus dem einfachen Cache 260 referenzieren. Daher führt jede ALU 234 bis 237 denselben Steuerthread aus, kann aber auf unterschiedlichen Faserdatenelementen in verschiedenen Datenelementen des einfachen Caches 260 arbeiten. Jede ALU kann zudem Information ausgeben, die im lokalen Thread- und Faserspeicher 240 gespeichert werden soll. Diese Schreibvorgänge sind spezifisch für die Faserspeicherelemente und da keine zwei Fasern, die auf dasselbe Faserspeicherelement referenzieren, zur gleichzeitigen Ausführung durch die ALU 235 bis 237 eingeplant werden können, sind Schutzmechanismen für den lokalen Thread- und Faserspeicher 240 für solche Faserspeicherplätze in dieser Ausführungsform nicht erforderlich. Information betreffend Faser-Scheduling und -Status 564 kann ebenfalls von den ALUs 234 bis 237 an die ALU-Cluster-Steuereinheit 230 bereitgestellt werden. Umgekehrt kann die ALU-Cluster-Steuereinheit 230 den Faserspeicherplatzzähler 565 aktualisieren, um die durch ausgeführte Faserroutinen geschaffenen neuen Fasern zu berücksichtigen und auch um Fasern, die nun abgeschlossen sind, zu berücksichtigen. Es wird jedoch vermerkt, dass in vielen Ausführungsformen die ALU-Cluster-Steuereinheit die Bestückung ihres Eingabepuffers 267 mit neugeschaffenen Fasern nicht steuert. Vielmehr wird der Eingabepuffer 267 durch eine zentrale Steuereinheit bestückt, die ebenfalls einen oder mehrere andere Eingabepuffer für andere ALU-Cluster (hier nicht abgebildet) bestückt.
10 zeigt eine Situation, in der ein lokaler Speicher eines Berechnungsclusters lokale Threadvariablen und zahlreiche Faserdatenspeicherelemente speichert, zum Beispiel Thread 588 verwendet diesen lokalen Speicherabschnitt 590 im Speicher 589. Dieser Abschnitt soll während des Threadeinrichtungsprozesses als die Höchstmenge an Speicher, die der Thread 588 verwenden kann, zugewiesen werden. 10 zeigt zwei verschiedene Faserfamilien 582 und 584, die beide auf unterschiedliche Stellen im Faserspeicher 591 referenzieren, während die Mitglieder einer jeden Familie auf dasselbe Faserspeicherelement referenzieren. 10 zeigt zudem, dass die von den Mitgliedern einer bestimmten Faserfamilie, z. B. Fasern 584, gemachten Speicherreferenzen während des Verlaufs der rekursiven Instanziierung dieser verwandten Fasern variieren werden. In diesem Beispiel werden die Speicherreferenzen 585 auf einen Hauptspeicher 587 gemacht. Darüber hinaus zeigt dieses Beispiel, dass diese Speicherreferenzen in einem regulären Schritt oder im Intervall 588 sein können. In manchen Ausführungsformen können diese Speicherreferenzen als Scheduling-Schlüssel verwendet werden, um Fasern von verschiedenen Fasern zu sammeln, zum Beispiel Fasern von Fasern 582 und Fasern 584 können basierend auf einem Übereinstimmen dieser Speicherreferenzen zusammen gesammelt werden. 10 zeigt zudem die Berechnungsressourcen 592, die für die Ausführung von Fasern und Freunden, wie oben erklärt, konfiguriert werden können und auf Programmzähler basieren, die Steuer-Streams für Threads und Fasern, die gleichzeitig beim Berechnen 592 ausgeführt werden, verfolgen.
Wie aus dem vorstehenden hervorgeht, kann ein Speicher 589 verschiedenen unterschiedlichen Regelmodellen zugewiesen werden. Ein Abschnitt des Speichers 589 kann als ein Cache verwaltet werden, in welchen die Cache-Verwaltungsregeln wie die zuletzt verwendeten steuern können, welche Daten im Speicher abgelegt werden. Ebenso hat ein solcher Cache-Teil eines Speichers 589 den Zweck mit anderen Speicherkomponenten in einer Speicherhierarchie (z. B. Hauptspeicher 587) kohärent zu sein. Ein solcher Cache-Teil kann als ein verschachtelter Speicher oder unter Verwendung eines anderen organisatorischen Ansatzes innerhalb dieses Cache-Teiles angeordnet sein. 10 zeigt einen solchen Speicherabschnitt wie Cache-Teil 594. Eine einem Cache-Teil 594 zugewiesene Speichermenge 589 kann verändert oder variiert werden. In manchen Ausführungsformen kann die Veränderung dynamisch erfolgen; in anderen kann die Veränderung während einer Einrichtungsphase der Berechnung vorgenommen werden; wie etwa zwischen zwei unterschiedlichen Teilen der Arbeitsbelastung während Berechnungen. Zum Beispiel können während der Arbeitsbelastung durch graphische Prozesse Neuzuweisungen während des Renderns von Rahmen vorgenommen werden. Andere Bedingungen, die Neuzuweisungen hervorrufen können sind Threads (z. B. Thread 588), die abgeschlossen werden und dadurch zusätzlichen Speicher frei machen.
Zusätzlich zum Cache-Teil 594 umfasst der Speicher 589 auch einen verwalteten Teil, wofür der Faserspeicher 591 als Beispiel dient. Der verwaltete Teil weist Merkmale auf, die sich von den Merkmalen des Cachabschnitts 594 unterscheiden. Der gesteuerte Abschnitt hat nicht die Erwartung oder das Ziel kohärent mit anderen Speichern in einer Speicherhierarchie (z. B. Speicher 587) zu sein. Es wird angemerkt, dass letztendlich Daten im gesteuerten Abschnitt auf den Speicher 587 ausgelagert werden oder auf andere Art durch den Zugriff durch nichtlokale Berechnungen verfügbar gemacht werden können. Jedoch tritt dieser Speichervorgang oder die Verfügbarkeit nach einer Sequenz lokaler Berechnung auf, die viele Lese- und Schreibvorgänge auf den Speicher umfassen kann, für die keine Speicherkohärenzoperationen generiert werden.
Fasern können zum Ausführungsbeginn eingeteilt werden, abhängig vom Vorliegen eines Speicherkonflikts mit einer anderen ausführenden oder eingeplanten Faser, oder Befehle von Fasern können basierend auf solchen Speicherkonfliktprüfungen ähnlich abgefertigt werden oder zur Abfertigung bereitgehalten werden. In thread-orientierter Berechnung werden Befehle eines Threads zur Ausführung abgefertigt und Speicherkorrektheit wird aufrechterhalten durch das Blockieren von Speicherplätzen, wenn ein Befehl eine Speichertransaktion initiiert, die eine Gefahr für einen anderen Befehl darstellen würde. Der andere Befehl kann die Ausführung beginnen, aber der Thread dessen Befehl einen Teil darstellt wird pausieren und warten bis die Gefahr vorüber ist.
11 zeigt Abschnitte eines Prozesses, der von einer zentralisierten Steuereinheit in den Ausführungsführungsformen dieser Offenbarungen durchgeführt werden kann. Der abgebildete Prozess umfasst den Empfang (602) einer Spezifikation einer Faserroutine. Basierend auf der Spezifikation kann eine Hauptspeicherleseoperation identifiziert werden (604). Von der Hauptspeicherleseoperation kann eine Speicheradresse oder ein Abschnitt davon identifiziert werden (606); diese identifizierte Speicheradresse oder Abschnitt davon kann als ein Scheduling-Schlüssel verwendet werden. Eine Verwendung dieser Scheduling-Schlüssel ist es Scheduling-Schlüssel oder Abschnitte davon zu vergleichen/übereinzustimmen (608), um Fasern zusammen zu sammeln (610). Fasergruppen werden für das Scheduling ausgewählt (612), basierend auf Kriterien wie Priorität, Sammlungsfülle und Heuristik.
Wie oben erklärt können Fasern einzeln entweder durch einen Thread oder eine andere Faser instanziiert werden. Jedoch werden Fasern für die Ausführung in Gruppen abgefertigt. Wenn ein Priorisierungsmodell für diese Fasergruppierungen umgesetzt werden soll, dann ist eine Herangehensweise an eine solche Priorisierung in 12 illustriert. 12 zeigt, dass wenn eine Reihe zu gruppierender Fasern 646 verfügbar ist, diese Fasern gesammelt oder sortiert (632) werden können, entsprechend ihrer Faserschlüssel (hierin auch Scheduling-Schlüssel genannt). Jede Faser kann auch einer einzelnen Priorität zugeordnet werden, die erhalten werden kann (638). Bei der Bestimmung solcher Fasergruppierungen, kann eine Priorität 642 für jede bestimmende Gruppierung ebenfalls bestimmt werden (640). Ein Paketidentifikator 644 kann ebenfalls bestimmt werden (642).
Eine Vielzahl von Herangehensweisen kann zur Bestimmung einer Fasergruppierungspriorität bereitgestellt werden, basierend auf den Prioritäten der einzelnen in dieser Gruppierung umfassten Fasern. In einem Beispiel kann der Durchschnittswert der einzelnen Faserprioritäten verwendet werden, um eine Gruppenpriorität zu ermitteln. In einem anderen Beispiel kann ein gewichteter Durchschnitt verwendet werden, wo eine Faser mit einer besonders hohen Priorität eine größere Auswirkung auf die Gesamtpriorität der Gruppe haben kann, als ein einfacher Durchschnitt es ermöglicht hätte. In anderen Ausführungsformen können Fasergruppierungen zugeordnete Prioritäten ebenfalls durch den aktuellen Status der innerhalb des Systems ausführenden Threads beeinflusst werden.
Um solche Beispielvariationen zu fördern, zeigt 12 ebenfalls erwartete Speicherplätze für Faserdaten, die von den Fasern eines Pakets bei der Bestimmung der Priorität des Pakets verwendet werden können. Zum Beispiel wenn zahlreiche Faserdaten für Fasern in einem bestimmten Paket enthaltende Speicher in die Nähe ihrer Kapazitätsgrenze gelangen, dann kann die Priorität solcher Pakete erhöht werden. Besonders da die Faserspeicherung bereits für Fasern (außer neuinstanziierten Faserfamilien) zugewiesen wurde, ist zusätzlicher lokaler Speicher nicht notwendigerweise erforderlich, um die Anzahl von Fasern innerhalb derselben Familie zu erhöhen.
13 zeigt einen Prozess in Zusammenfassung einiger der vorstehenden Offenbarungen. Der abgebildete Prozess umfasst die Bestimmung (682) einer Fasersammlung für das Prozess-Scheduling, das Senden (684) eines die entsprechende Fasersammlung repräsentierenden Pakets. Dieses Faserpaket wird auf verschiedene Eingabewarteschlangen für Prozess-Cluster verteilt (686), welche die Berechnung basierend auf den Inhalten der entsprechenden Eingabewarteschlangen und der Threads, die für die Ausführung darin eingeplant oder gekennzeichnet sind, ausführen.
14 erklärt zudem bestimmte Aspekte dieser Faserberechnungvorgänge innerhalb des Beispiels, wobei ein Sammlungsspeicher 703 Information für eine Vielzahl von Fasern speichert, die abhängig davon zu welcher Sammlung die Faser gehört organisiert sind. Es wird im Allgemeinen erwartet, dass eine Faser nur in einer Sammlung existiert; jedoch wäre zu erwarten, dass auf dasselbe Faserdatenelement referenzierende Fasern in einer großen Anzahl von Sammlungen innerhalb des Sammlungsspeichers 703 existieren können. In Förderung des Beispiels werden die Sammlungen 705, 707, 709 und 711 für die Abfertigung ausgewählt. Als Reaktion dieser Auswahl werden Transaktionen auf eine Hauptspeicherhierarchie 701 initiiert, die Resultate davon werden dem lokalen Thread- und Faserspeicher 727, 729 und 731 bereitgestellt. Die ausgewählten Sammlungen werden jedoch abgefertigt und unter den Eingabepuffern 721, 723 und 725 aufgeteilt. Diese Verteilung kann in einem Beispiel auf einem Abschnitt eines Identifikators für jede Faser basieren, welcher wiederum sich auf einen Speicheradressenbereich des lokalen Thread- und Faserspeichers beziehen kann. Das abgebildete Beispiel zeigt ebenfalls, dass für ein beliebiges Faserpaket, die Fasern üblicherweise unter den verschiedenen Berechnungsclustern aufgeteilt und nicht lediglich auf eine Untergruppe davon konzentriert werden sollen.
15 zeigt ein Ausführungsbeispiel des in den obigen Beispielen gezeigten Eingabepuffers. 15 zeigt eine neue Sammlung 742, die auf die Eingabepuffer einer Vielzahl von Berechnungsclustern aufgeteilt werden soll. Jeder Eingabepuffer kann eine Priorität pro Faser 750 aufrechterhalten. Anfangs kann eine solche Priorität pro Faser auf einer Paketpriorität basieren, aber kann durch die lokale Cluster-Steuereinheit aktualisiert werden. Zusätzlich dazu kann ein Alterungsmechanismus für Fasern bereitgestellt werden, wobei die Alterung in die Faserprioritätsauswahl einbezogen werden kann. 15 kann auch in dem Kontext verstanden werden, dass Umsetzungen der Faserberechnung eine zentralisierte Auswahl ermöglichen, welche Berechnungsanteile für die Ausführung innerhalb eines allgemeinen Berechnungszeitfensters ausgewählt werden, und ein Hauptspeicherzugriff, der von diesen Berechnungsanteilen benötigt wird, mit den Ergebnissen eines solchen Hauptspeicherzugriffs erreicht und amortisiert werden kann, der in verteilter Manier unter den Berechnungsclustern verteilt ist, die die Berechnungsanteile ausführen werden. Jedoch kann in jedem Berechnungscluster ein breites Spektrum daran bereitgestellt werden, welche Befehle ausgeführt werden und in welcher Reihenfolge, wobei dieses lokale Scheduling von einer lokalen Steuereinheit verwaltet wird, um Bedingungen zu berücksichtigen, die für die Steuereinheit spezifisch sind, und um Verwaltungsaufwand zu vermeiden, der durch die Koordination innerhalb der Berechnungscluster entsteht.
16 zeigt Aspekte eines Beispielprozesses in Übereinstimmung mit diesen Offenbarungen. Bei 780 wird eine Spezifikation einer Faserroutine erhalten und bei 782 wird eine Hauptspeicherleseoperation innerhalb der Faserroutine identifiziert. Bei 784 wird eine Speicheradresse (oder ein Teil davon) als Scheduling-Schlüssel identifiziert. Prozessabschnitte 780, 782 und 784 können mehrmals für verschiedene Fasern durchgeführt werden. Bei 786 werden Scheduling-Schlüssel verschiedener Fasern verglichen. Bei 788 werden Fasern entsprechend ihrer Scheduling-Schlüssel gesammelt. Bei 790 wird/werden die Fasersammlung(en) für die Ausführung ausgewählt, basierend auf Kriterien wie ihrer Bereitschaft. Bereitschaftskriterien können Aspekte wie Priorität und Anzahl der Heuristiken umfassen.
Es wird erwartet, dass Fasern ihre Ausgaben durch Zurückkopieren in den lokalen Faserspeicher bewirken und für geteilte Speicherressourcen arbitrieren. Zudem sind Faserroutinen in vielen Ausführungsformen codiert, um das Aufrufen einer anderen Routine zu verhindern, die einen Wert zurückgibt, was die Faserroutine für einen unbestimmten Zeitraum pausieren lässt, da sie auf die Rückkehr dieses Werts wartet. Damit Grammatikelemente in diesen Ausführungsformen Fasern instantiieren oder auf sonstige Art aufrufen, müssen sie in diesen Umsetzungen auch nicht pausieren oder auf die Rückkehr eines Wertes zum aufrufenden Thread oder einer anderen Faser warten. Somit ist die Zeit, um die Ausführung einer bestimmten Faser abzuschließen, nicht so kritisch, da andere Berechnungsflüsse nicht pausieren müssen, um den Abschluss dieser Faser abzuwarten.
Scheduling-Schlüssel wurden in vielen vorstehenden Beispielausführungen beschrieben. In manchen Ausführungsformen und in manchen Instanzen, abhängig von der Art der durchgeführten Arbeitsbelastung, können Scheduling-Schlüssel komprimiert werden, oder es kann auf andere Art durch eine Kurznotationsweise auf sie referenziert werden. Eine Arbeitsbelastung durch Strahlenverfolgung wird als Beispiel dienen. In diesem Beispiel kann ein Strahlenverfolgungselternthread eine andere Faser für jeden Strahl, den er in einer Szene verfolgen wird, ausgeben. Daher können manche Threads ein paar Fasern ausgeben, einige können Zehn- oder hunderte Millionen oder Milliarden Fasern ausgeben. In manchen Instanzen kann jede Faser anfangs mit demselben Scheduling-Schlüssel beginnen. In einem Beispiel kann ein solcher Scheduling-Schlüssel auf eine Ausgangsspeicheradresse eines ersten Elements einer Beschleunigungsstruktur referenzieren, die die 3-D-Szene weiter unterteilt. Elemente dieser Struktur können in regelmäßigen Abständen im Speicher abgelegt werden (z. B. jedes Element kann in einem Viertelwort gespeichert werden). Somit kann eine Art Faserroutine mit einem Default-Scheduling-Schlüssel eingerichtet werden; z. B. kann eine Durchquerungsfaserroutine mit Beschleunigungsstruktur kann das Kopfelement der Beschleunigungsstruktur als Default aufweisen. Somit muss ein diese Fasern instantiierender Thread diesen Ort nicht explizit identifizieren.
Beispiele für Beschleunigungsstrukturen können Hüllkörperhierarchien sein, wie z. B. kugelförmige oder rechteckige Hierarchien und kD-Bäume, ohne auf diese beschränkt zu sein. Zum Beispiel sind in einer einheitlichen Kugelhierarchie die Elemente dieser Struktur Kugeln. Wenn die Beschleunigungsstruktur homogen ist, dann umhüllen die Blattknoten in der Struktur Primitive; eine heterogene Struktur kann Elemente haben, die andere Beschleunigungsstrukturelemente und Primitive beschränken.
Eine Vielzahl von Strukturen, Vorrichtungen, Bestandteile und andere Komponenten wurden abgebildet und oben beschrieben, gemeinsam mit den wechselseitigen Beziehungen, die den Fluss von Daten und anderen Informationen zwischen einander und unter sich ermöglichen und Funktionen und Zielsetzungen dafür wurden beschrieben. Diese sind die Mittel, um die ihnen in der Offenbarung zugeschriebenen Funktionen und Zielsetzungen durchzuführen.
Der Code für ein beliebiges Verfahren kann in permanenten computerlesbaren Medien, wie kontaktlosen Disks, Festplatten, CD-ROMs und anderen optischen Speichermitteln und temporär in nichtvolatilen Speichern gespeichert werden. Ein computerlesbares Medium kann auch Kommunikationssignale umfassen. Wenn dieser Code in einem Kommunikationssignal enthalten ist und dieses Kommunikationssignal wird von einem Computer gelesen und prozessiert, nutzt der Computer dieses Signal und sein physisches Medium als ein computerlesbares Medium.
Computerausführbare Befehle umfassen zum Beispiel Befehle und Daten, die einen Allzweckcomputer, einen Sonderzweckcomputer oder eine Sonderzweckverarbeitungsvorrichtung dazu veranlassen oder auf andere Art dazu konfigurieren, eine bestimmte Funktion oder eine Funktionsgruppe durchzuführen. Die computerausführbaren Befehle können zum Beispiel Binärprogramme, Zwischenformatbefehle, wie Assemblersprache, oder Quellcode sein. Manche Aspekte der hierin beschriebenen API können als Verfahren, Funktionen oder Aufrufe an solche Verfahren oder Funktionen sein. Die Beschreibung versteht sich nicht als Beschränkung der Programmiermethodologie, die zur Implementierung oder Bereitstellung der durch die hierin beschriebenen durch diese Verfahren und Funktionen verfügbaren Funktionalität eingesetzt werden kann, solange die Software, Hardware oder eine Kombination daraus, einem Programmierer die Möglichkeit bietet, auf diese Funktionalität durch ein dafür vorgesehenes Interface zuzugreifen. Diese Namen implizieren keine Notwendigkeit, wie der diese Funktionen ausführende Code in einer Implementierung bezeichnet werden soll.
In einigen Beispielen können für die Ausführung der Threads und Fasern verwendeten Berechnungsressourcen weitgehend undifferenziert sein. Vielmehr können viele der hierin beschriebenen Faserberechnungseigenschaften durch eine zentrale Steuereinheit, die Fasern gruppiert für die Abfertigung und Ausbreitung auf die diese Berechnungsressourcen bedienenden Berechnungsressourceneingabewarteschlangen und die Koordination und das Zählen welche Fasern noch ein bestimmtes Faserspeicherelement erfordern.
Wie aus diesen Offenbarungen hervorgeht, kann als Beispielssituation, in der die Faserberechnung verwendet werden kann, eine Situation dienen, in der eine große Anzahl von Datenelementen eines ersten Typs, die nicht alle vorab bekannt ist, prozessiert oder in Verbindung mit einem großen und vorbestimmten Datensatz verwendet werden muss. In manchen Beispielsituationen beeinflusst das Prozessieren von Datenelementen eines ersten Typs mit einem Abschnitt des vorbestimmten Datensatzes wie dieses Datenelement des ersten Typs mit anderen Abschnitten des vorbestimmten Datensatzes prozessiert wird. Der vorbestimmte Datensatz kann ebenfalls variieren, etwa indem er relativ selten aktualisiert wird. In einer beispielhaften Grafikanwendung kann der vorbestimmte Datensatz ein paar hundert Mal pro Sekunde aktualisiert werden und kann viele Millionen an Items enthalten, auf die millionen- oder milliardenmal pro Sekunde zugegriffen wird. Im Allgemeinen kann ein zentralisierter Scheduler für Faserberechnung, Fasersammlungen eher basierend auf erwarteter Maximierung des Berechnungsdurchsatzes einteilen, als explizit der Priorisierung einer bestimmten Faser zu dienen.
Die verschiedenen oben beschriebenen Beispiele dienen ausschließlich als Illustration und sollten nicht als einschränkend verstanden werden. Zum Bespiel wurde nur ein eingeschränktes Bespiel von Strahlenverfolgungsverhalten präsentiert und es versteht sich, dass praktische Implementierungen viel mehr Strahlen und oft mehrere gleichzeitige Verarbeitungsvorgänge davon umfassen können. Die Offenbarungen hierin können aus dieser Perspektive adaptiert und verstanden werden. Zusätzlich dazu implizieren separate Kästchen oder eine dargestellte Trennung funktionaler Elemente dargestellter Systeme keine physische Trennung dieser Funktionen, da die Kommunikation zwischen solchen Elementen durch Messaging, Funktionsaufrufe, Shared-Memory-Space usw. erfolgen kann, ohne jegliche physische Trennung. Allgemeiner wäre ein Fachmann auf dem Gebiet der Erfindung in der Lage, die sich auf die Programmierungssemantik beziehenden Offenbarungen für eine Reihe anderer Strahlenverfolgungs-/Strahlenschattierungsimplementierungen zu adaptieren und es existiert keine Limitierung in Bezug auf die Anwendung, die von den Systemen, Verfahren und anderen zur Erklärung der Beispiele davon verwendeten Offenbarung herrührt.
Anhang

Claims

Verarbeitungssystem, das in der Lage ist, gleichzeitige Grafikberechnung durchzuführen, umfassend: eine Vielzahl von Berechnungselementen, wobei jedes Berechnungselement einen lokalen Speicher und eine Vielzahl von arithmetisch-logischen Einheiten (ALU) von Single-Instruction-Multiple-Data (SIMD) umfasst, einen Scheduler für den Cluster von Berechnungselementen, wobei der Scheduler betriebsfähig ist, Eingaben zu empfangen, die Instanzen einer ersten an dem Cluster durchzuführenden Berechnungsart definieren, wobei jede der Instanzen einem entsprechenden Scheduling-Schlüssel zugeordnet ist, wobei der Scheduler betriebsfähig ist, die Instanzen nach ihren Scheduling-Schlüsseln zu Paketen zu sortieren und ein Paket auszugeben, das eine Vielzahl von Berechnungsinstanzen umfasst; und einen Verteiler, der betriebsfähig ist, das Paket zu empfangen und die Instanzen auf die Berechnungselemente des Clusters zur Durchführung auf diesem zu verteilen, wobei jedes der Berechnungselemente betriebsfähig ist, Instanzen mit verschiedenen Scheduling-Schlüsseln zur gleichzeitigen Durchführung zu kombinieren, für welche die gleiche Berechnung durchzuführen ist, und gleichzeitig die Berechnung für die kombinierten Berechnungsinstanzen durchzuführen.
System zur gleichzeitigen Berechnung nach Anspruch 1, wobei jede Instanz einen Teil der Grafikberechnung definiert.
System zur gleichzeitigen Berechnung nach Anspruch 1, wobei Instanzen einer ersten Berechnungsart für Speicherzugriffe auf Speicherplätze synchronisiert sind, die für Lesen und Schreiben mit anderen Instanzen offen sind, indem in Konflikt stehende Speicherbereiche unter verschiedenen Instanzen der ersten Berechnungsart identifiziert werden, bevor Befehle, die auf diese in Konflikt stehenden Speicherbereiche zugreifen, zur Durchführung abgefertigt wurden.
System zur gleichzeitigen Berechnung nach Anspruch 3, wobei der Scheduler das Identifizieren der in Konflikt stehenden Speicherbereiche unter Verwendung einer oder mehrerer instanzenspezifischer Speicheradressen und instanzenspezifischer Registerpositionen vornimmt.
System zur gleichzeitigen Berechnung nach Anspruch 3, wobei die Vielzahl von Berechnungselementen betriebsfähig ist, Befehle von Programmen einer zweiten Berechnungsart ausführen, wobei Befehle von laufenden Programmen der zweiten Art für den Speicherzugriff unter Verwendung einer oder mehrerer von Read-/Write-Locks und -Barriers synchronisiert werden.
System zur gleichzeitigen Berechnung nach Anspruch 1, wobei das System ferner betriebsfähig ist, während einer Einrichtungsphase instanzenspezifische Speicherbereiche innerhalb der Vielzahl von Berechnungselementen zuzuteilen.
System zur gleichzeitigen Berechnung nach Anspruch 1, wobei jedes Berechnungselement betriebsfähig ist, Gruppierungen von Instanzen nach Kriterien einzuplanen, die (1) eine Durchführung von einer gemeinsamen Befehlsquelle und (2) ein Durchsetzen einer Regel umfassen, wonach keine Gruppierung von parallel durchzuführenden Instanzen mehrere Instanzen umfassen darf, die den gleichen Speicherplatz beschreiben.
Verfahren, das bei einer Scheduling-Berechnung in einem Computersystem durchzuführen ist, umfassend: Verteilen von Arbeitsbelastungen einer ersten Art auf eine Vielzahl von Berechnungsclustern, wobei jeder Cluster betriebsfähig ist, die Ausführung von Befehlen aus den diesem Cluster zugeteilten Arbeitsbelastungen der ersten Art unabhängig von anderen Clustern aus der Vielzahl einzuplanen; Bilden von Gruppierungen von Arbeitsbelastungen einer zweiten Art zur Durchführung in der Vielzahl von Berechnungsclustern, wobei die Gruppierungen auf der Basis von jeweiligen Scheduling-Schlüsseln, die Arbeitsbelastungen der zweiten Art zugeordnet sind, und eines für jede Arbeitsbelastung der zweiten Art auszuführenden Befehlssatzes bestimmt werden; Auswählen einer Gruppierung von Arbeitsbelastungen der zweiten Art; und Verteilen entsprechender Definitionen der Arbeitsbelastungen der ausgewählten Gruppierung auf die Vielzahl von Berechnungsclustern.
Verfahren nach Anspruch 8, wobei jeder Scheduling-Schlüssel von den Berechnungsclustern dazu verwendet werden kann, ein oder mehrere während der Ausführung jeder Gruppierung von Arbeitsbelastungen zu verwendende Datenelemente zu identifizieren.
Verfahren nach Anspruch 8, das ferner ein Einholen eines durch den Scheduling-Schlüssel der ausgewählten Gruppierung bestimmten Datenelements aus einem globalen Speicher umfasst, wobei das Datenelement innerhalb der Cluster, auf die die Definitionen der ausgewählten Gruppierung verteilt wurden, verfügbar gemacht ist.
Verfahren nach Anspruch 8, das ferner als Antwort auf eine Feststellung, dass ein Datenzugriffskonflikt vorliegt, ein Zurückhalten dieses Teils der Berechnung von einem Scheduling für die Durchführung und ein Scheduling eines anderen Teils der Berechnung, von dem festgestellt wurde, dass er keinen Datenzugriffskonflikt erzeugt, für die Durchführung umfasst.
Verfahren nach Anspruch 8, wobei das Feststellen des Vorliegens eines Datenzugriffskonflikts ein Vergleichen von Referenzen mit einer oder mehreren Positionen in einem lokalen Speicher eines Clusters umfasst.
Verfahren nach Anspruch 8, das ferner ein Empfangen von Arbeitsbelastungen der zweiten Art durch eine Schnittstelle umfasst, die von speicherresidenten Prozessen dazu verwendet werden kann, programmatische Arbeitsbelastungen zu spezifizieren, wobei die Schnittstelle einen Scheduling-Schlüssel und eine Referenz auf eine Position in einem lokalen Clusterspeicher annimmt.
Maschinell implementiertes Verfahren zur gleichzeitigen Berechnung, das umfasst: Ausführen von Befehlen von einer Vielzahl von Arbeitsbelastungen einer ersten Berechnungsart; Durchsetzen von Rechengenauigkeit während der Ausführung der Vielzahl von Arbeitsbelastungen der ersten Berechnungsart durch ein Steuern des Zugriffs auf Speicherplätze in einem Speicher, der Datengefahren aufweist, in Hinblick auf die aktuell von der Vielzahl von Arbeitsbelastungen der ersten Art ausgeführten Befehle; und Durchführen eines Scheduling-Vorgangs für Arbeitsbelastungen einer zweiten Art, wobei der Scheduling-Vorgang umfasst: Identifizieren wenigstens eines Speicheridentifikators für jede Arbeitsbelastung der zweiten Art; Bestimmen anhand des wenigstens einen Speicheridentifikators für jede Arbeitsbelastung durch Feststellen des Vorliegens eines Konflikts zwischen dem Speicheridentifikator für diese Arbeitsbelastung und den Speicheridentifikatoren der übrigen Arbeitsbelastungen der zweiten Art, ob eine Arbeitsbelastung der zweiten Art einplanbar ist, und gegebenenfalls Zurückstellen des Schedulings der Arbeitsbelastung in Reaktion auf die Feststellung des Vorliegens des Konflikts.
Maschinell implementiertes Verfahren zur gleichzeitigen Berechnung nach Anspruch 14, wobei das Zurückstellen des Schedulings das Scheduling einer anderen Arbeitsbelastung der zweiten Art umfasst, von der festgestellt wurde, dass sie in keinem Speicherkonflikt steht.
Maschinell implementiertes Verfahren zur gleichzeitigen Berechnung nach Anspruch 14, wobei das Feststellen des Vorliegens des Konflikts ein Interpretieren von von einem Compiler generierten und mit den Arbeitsbelastungen der zweiten Art zusammenhängenden Informationen umfasst.
Maschinell implementiertes Verfahren zur gleichzeitigen Berechnung nach Anspruch 14, wobei das Feststellen des Vorliegens des Konflikts ein Vergleichen einer Speicherreferenz mit einer Gruppe von Speicherbereichen umfasst und ferner ein Aufbauen der Speicherbereiche während einer Berechnungs-Einrichtungsphase umfasst.
Maschinell implementiertes Verfahren zur gleichzeitigen Berechnung nach Anspruch 14, wobei eine entsprechende Definition für jede Arbeitsbelastung der zweiten Art die Angabe eines in Konflikt stehenden Speicherbereichs umfasst und ferner ein Verwenden der Angabe zum Bestimmen des Speicheridentifikators für diese Arbeitsbelastung umfasst.
Berechnungskomponente zur Verwendung in einem Berechnungssystem, die umfasst: einen Speicher, der zwischen einem Cache-Teil und einem verwalteten Teil zuweisbar ist; eine Vielzahl von arithmetisch-logischen Einheiten, ALUs, die jeweils Lese- und Schreibzugriffsfähigkeit auf den Speicher aufweisen; eine Warteschlange zum Empfangen gesonderter Definitionen der an der Vielzahl von ALUs durchzuführenden Berechnung, wobei die Definitionen jeweils eine Programmreferenz und Daten, die einen Platz im verwalteten Teil des Speichers spezifizieren, umfassen; und einen lokalen Scheduler, der betriebsfähig ist, die Vielzahl von ALUs einzuplanen, indem er eine Gruppe von Berechnungsdefinitionen mit der gleichen Programmreferenz identifiziert, wobei der Speicher im Betrieb betriebsfähig ist, im Cache-Teil Daten zu speichern, die in Antwort auf Lesetransaktionen des Speichers, die während der Ausführung des Programms, auf das die gruppierten Berechnungsdefinitionen referenzieren, zurückerhalten wurden, und die Vielzahl von ALUs betriebsfähig sind, Plätze im verwalteten Teil des Speichers, die durch die jeweiligen Daten von jeder der Berechnungsdefinitionen in der Gruppierung spezifiziert werden, lesen und beschreiben zu können.
Berechnungskomponente nach Anspruch 19, wobei die Vielzahl von ALUs das referenzierte Programm ohne Unterbrechung zur Synchronisation ausführen und die Ausführung abschließen, indem sie Ergebnisse auf gesonderte Plätze im bestehenden Speicherteil des Speichers schreiben.
Verarbeitungssystem, das in der Lage ist, gleichzeitige Grafikberechnung durchzuführen, umfassend: ein Mittel zur Durchführung einer Vielzahl von gleichzeitigen arithmetischen und logischen Operationen an einer Vielzahl von Datenelementen unter Verwendung jeweils eines einzigen Befehlsstroms; ein Mittel zum Scheduling des Mittels zur Durchführung gleichzeitiger arithmetischer und logischer Operationen, wobei das Mittel zum Scheduling gekoppelt ist, Eingaben zu empfangen, die Instanzen einer ersten Art von durchzuführender Berechnung definieren, wobei jede der Instanzen einem eigenen Scheduling-Schlüssel zugeordnet ist, und betriebsfähig ist, die Instanzen nach ihren Scheduling-Schlüsseln zu Paketen zu sortieren und ein Paket auszugeben, das eine Vielzahl von Berechnungsinstanzen umfasst; und ein Mittel zur Verteilung der Instanzen eines Pakets im Mittel zur Durchführung gleichzeitiger Berechnungen, wobei das Mittel zur Durchführung einer Vielzahl von gleichzeitigen arithmetischen und logischen Operationen an einer Vielzahl von Datenelementen betriebsfähig ist, Instanzen mit verschiedenen Scheduling-Schlüsseln zur gleichzeitigen Durchführung jeweils einzelner Befehlsströme zu kombinieren und gleichzeitig die Berechnung für die kombinierten Berechnungsinstanzen durchzuführen.
System zur gleichzeitigen Berechnung nach Anspruch 21, wobei jede Instanz einen Teil der Grafikberechnung definiert.
System zur gleichzeitigen Berechnung nach Anspruch 21, das ferner ein Mittel zum Speichern von lokalen Daten im Mittel zur Durchführung einer Vielzahl von gleichzeitigen arithmetischen und logischen Operationen an einer Vielzahl von Datenelementen und ein Mittel zur Identifikation in Konflikt stehender Speicherbereiche unter verschiedenen Instanzen, bevor Befehle im Zusammenhang mit einer ersten Berechnungsart, die auf jene in Konflikt stehenden Speicherbereiche zugreifen, zur Ausführung abgefertigt wurden, umfassst.
System zur gleichzeitigen Berechnung nach Anspruch 23, wobei das Mittel zum Scheduling, der Scheduler, das Identifizieren in Konflikt stehender Speicherbereiche unter Verwendung einer oder mehrerer instanzenspezifischer Speicheradressen und instanzenspezifischer Registerpositionen vornimmt.
System zur gleichzeitigen Berechnung nach Anspruch 23, wobei das Mittel zur Durchführung einer Vielzahl von gleichzeitigen arithmetischen und logischen Operationen an einer Vielzahl von Datenelementen betriebsfähig ist, Befehle von Programmen einer zweiten Berechnungsart auszuführen, wobei Befehle von laufenden Programmen der zweiten Berechnungsart für den Speicherzugriff unter Verwendung einer oder mehrerer von Read-/Write-Locks und -Barriers synchronisiert werden.
System zur gleichzeitigen Berechnung nach Anspruch 21, wobei das Mittel zur Durchführung einer Vielzahl von gleichzeitigen arithmetischen und logischen Operationen an einer Vielzahl von Datenelementen betriebsfähig ist, Gruppierungen von Instanzen nach Kriterien einzuplanen, die (1) eine Durchführung von einer gemeinsamen Befehlsquelle und (2) ein Durchsetzen einer Regel umfassen, wonach keine Gruppierung von parallel durchzuführenden Instanzen mehrere Instanzen umfassen darf, die den gleichen Speicherplatz beschreiben.