DE102012213643B4

DE102012213643B4 - Multitthread-Physik-Engine mit Impulsweiterleitung

Info

Publication number: DE102012213643B4
Application number: DE102012213643.6A
Authority: DE
Inventors: Eric O. Mejdrich; Paul E. Schardt; Robert A. Shearer; Matthew R. Tubbs
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-08-18
Filing date: 2012-08-02
Publication date: 2022-07-21
Anticipated expiration: 2032-08-03
Also published as: CN103106120B; DE102012213643A1; GB2493807A; CN103106120A; US20130046518A1; GB201209170D0; US8413166B2

Abstract

Schaltkreisanordnung, die Folgendes umfasst:Network-on-Chip-Hardware-Logik, die eine Vielzahl von eine Vielzahl von Hardware-Threads festlegenden Verarbeitungskernen und ein chipintegriertes Netzwerk enthält, das die Vielzahl von Verarbeitungskernen miteinander verbindet; undeine von mindestens einem Teil der Vielzahl von Hardware-Threads ausgeführte Physik-Engine, wobei die Physik-Engine eine Multithread-Software-Pipeline enthält, die eine Vielzahl von Stufen enthält, die so konfiguriert sind, dass sie Zusammenstöße zwischen Objekten aus einer Vielzahl von Objekten in einer Szene erkennen, sowie eine Vielzahl von Impuls-Weiterleitungs-Threads enthält, die so konfiguriert sind, dass sie Impulse zwischen einer Reihe von benachbarten Objekten aus der Vielzahl von sich berührenden Objekten weiterleiten;wobei die Physik-Engine so konfiguriert ist, dass sie für jedes aus der Reihe von benachbarten Objekten den Besitz an dem Objekt einem der Vielzahl von Impuls-Weiterleitungs-Threads zuweist und eine Tabelle über benachbarte Objekte für den Impuls-Weiterleitungs-Thread erzeugt, dem das Objekt zugewiesen ist, die jedes Objekt aus der Reihe von benachbarten Objekten identifiziert, die das Objekt berührt;wobei die Physik-Engine so konfiguriert ist, dass sie als Reaktion auf einen erkannten Zusammenstoß mit einem ersten Objekt aus der Reihe von benachbarten Objekten eine erste thread-übergreifende Impulsnachricht erzeugt, die eine Größenordnung und eine Richtung enthält;wobei jeder Impuls-Weiterleitungs-Thread unter der Vielzahl von Impuls-Weiterleitungs-Threads so konfiguriert ist, dass er als Reaktion auf das Empfangen einer einem Impuls zugehörigen thread-übergreifenden Impulsnachricht den Impuls lokal durch ein Objekt weiterleitet, dessen Besitz dem Impuls-Weiterleitungs-Thread zugewiesen ist, für jedes in der Tabelle über benachbarte Objekte für den Impuls-Weiterleitungs-Thread identifizierte benachbarte Objekt eine Größenordnung und eine Richtung einer weitergeleiteten Kraft ermittelt, den Impuls für jedes in der Tabelle über benachbarte Objekte für den Impuls-Weiterleitungs-Thread identifizierte benachbarte Objekt an den Impuls-Weiterleitungs-Thread weiterleitet, indem er eine thread-übergreifende Impulsnachricht an diesen sendet, welche die dafür ermittelte Größenordnung und Richtung der weitergeleiteten Kraft enthält, eine thread-übergreifende Impulsbestätigungsnachricht von jedem benachbarten Objekt empfängt, das in der Tabelle über benachbarte Objekte für den Impuls-Weiterleitungs-Thread identifiziert wurde,eine Größenordnung und eine Richtung einer Reaktionskraft zumindest teilweise beruhend auf den thread-übergreifenden Impulsbestätigungsnachrichten ermittelt und eine thread-übergreifende Impulsbestätigungsnachricht mit der Größenordnung und Richtung der Reaktionskraft als Bestätigung für die empfangene thread-übergreifende Impulsnachricht sendet, undwobei die Physik-Engine so konfiguriert ist, dass sie als Reaktion auf das Erkennen eines zukünftigen Zusammenstoßes zwischen Objekten in einer Szene eine Neuzuordnung der Arbeitslast unter der Vielzahl von Impuls-Weiterleitungs-Threads wahlweise in Abhängigkeit von Objekteigenschaften der als zukünftig zusammenstoßend erkannten Objekten einleitet,

Description

GEBIET DER ERFINDUNG
Die Erfindung betrifft allgemein die Datenverarbeitung und insbesondere die grafische Bildverarbeitung und Wiedergabe (rendering) sowie die damit zusammenhängende Physikimpulsweiterleitung.
HINTERGRUND DER ERFINDUNG
Der Prozess des Wiedergebens von zweidimensionalen Bildern aus dreidimensionalen Szenen wird häufig Bildverarbeitung genannt. Mit zunehmender Entwicklung der modernen Computerindustrie entwickelt sich auch die Bildverarbeitung weiter. Ein bestimmtes Ziel bei der Entwicklung der Bildverarbeitung besteht darin, zweidimensionale Simulationen bzw. Darstellungen von dreidimensionalen Szenen so realistisch wie möglich zu gestalten.
Außerdem wird die Bildverarbeitung häufig im Zusammenhang mit dem Modellieren bzw. Simulieren von realen Szenarien verwendet, wobei virtuelle bzw. simulierte Objekte reale physische Objekte darstellen, die sich in den simulierten Szenen gegenseitig beeinflussen. Videospiele sind zum Beispiel immer besser in der Lage, realistischere virtuelle Umgebungen abzubilden, sei es durch den Flug eines Golfballs, realistische Fahreigenschaften eines Rennwagens, den Flug eines Luftfahrzeugs oder das Ergebnis einer Explosion in einem Kriegsspiel. In anderen kommerziellen und wissenschaftlichen Anwendungen der Bildverarbeitung, z.B. Flugsimulationen, ballistische Simulationen usw., ist das genaue Modellieren der gegenseitigen Beeinflussung von Objekten in einer virtuellen Umgebung von noch größerem Interesse.
In vielen modernen Datenverarbeitungssystemen wird das Modellieren der realen gegenseitigen Beeinflussung von Objekten von Computersoftware bewältigt, die allgemein als Physik-Engine bezeichnet wird. Eine Physik-Engine versucht unter Verwendung von Grundgedanken der Dynamik starrer Körper, der Dynamik weicher Körper und/oder der Strömungslehre, physikalische Phänomene zu simulieren. Eine Schlüsselkomponente der meisten Physik-Engines stellt ein Zusammenstoßerkennungs-/Zusammenstoßreaktionssystem dar, das versucht zu erkennen, wenn Objekte in einer virtuellen Umgebung miteinander zusammenstoßen. Beruhend auf erkannten Zusammenstößen wird üblicherweise eine Dynamiksimulation durchgeführt, um die auf die Objekte angewendeten Kräfte und Bewegungen nach den Zusammenstößen aufzulösen.
Einige Physik-Engines hängen auch von auf Impulsen beruhenden Algorithmen ab, wobei Impulse zwischen Objekten angewendet werden, um Kräfte zwischen diesen weiterzuleiten. Wenn sich zum Beispiel starre oder verformbare Körper gegenseitig berühren, müssen auf einen Körper angewendete Kräfte üblicherweise auf die anderen Körper angewendet werden, die diesen Körper berühren. Gleichermaßen müssen auf strömende Medien, Gewebe und andere hoch verformbare Einheiten angewendete Kräfte üblicherweise durch diese Einheiten hindurch weitergeleitet werden.
Während einige genauere Physik-Engines nicht durch die Zeit eingeschränkt sind, müssen viele andere, insbesondere diejenigen, die in interaktiven Videospielanwendungen verwendet werden, in „Echtzeit“ arbeiten. Folglich müssen die in Zusammenhang mit Physikberechnungen wie Zusammenstoßerkennung und Impulsweiterleitung durchgeführten Arbeitsschritte schnell und effizient ausgeführt werden.
Herkömmliche Techniken für das Erkennen von Zusammenstößen und das Weiterleiten von Impulsen werden üblicherweise in einer seriellen, Einzel-Thread-Anwendung ausgeführt, wobei jedes sich bewegende Objekt im Vergleich zu allen anderen Objekten in der Szene geprüft wird und Impulse einzeln zwischen Objekten weitergeleitet werden. In einigen Fällen kann die Zusammenstoßerkennung eine räumliche Filterung (spatial culling) zur Verringerung der Anzahl von benötigten Zusammenstoßberechnungen verwenden. Des Weiteren können Objekte unter Verwendung von Detailstufen- (LOD-) Modellen modelliert werden, um Objekte zu einfacher zu berechnenden Formen zu vereinfachen, um zu erkennen, wenn zwei Objekte miteinander in Berührung kommen. Viele Techniken für das Erkennen von Zusammenstößen verwenden einfache Formen wie Kugeln und andere würfelförmige dreidimensionale Raumbereiche (cubic volumes) zur Darstellung von komplexeren Objekten. In einigen Anwendungen können genauere begrenzende dreidimensionale Raumbereiche (bounding volumes) ersonnen werden, um die Genauigkeit der Zusammenstöße zu verbessern, wobei dies jedoch normalerweise auf Kosten einer längeren Verarbeitungszeit und/oder höherer Hardware-Anforderungen geht.
Mit fortschreitenden Verbesserungen in der Halbleitertechnologie in Bezug auf Taktgeschwindigkeit und die häufigere Verwendung von Parallelverarbeitung werden die Funktionen von Echtzeit-Physik-Engines unausweichlich besser werden. Auf Chip-Ebene werden häufig mehrere Prozessorkerne auf demselben Chip angeordnet, die auf im Wesentlichen gleiche Weise wie separate Prozessor-Chips bzw. zu einem gewissen Maße wie vollständig separate Computer funktionieren. Außerdem wird selbst innerhalb von Kernen Parallelverarbeitung durch die Verwendung von mehreren Ausführungseinheiten eingesetzt, die darauf spezialisiert sind, bestimmte Arten von Arbeitsschritten zu bewältigen. Auf Hardware beruhendes Pipelining wird auch in vielen Fällen eingesetzt, so dass bestimmte Arbeitsschritte, deren Ausführung mehrere Taktzyklen benötigen kann, in Stufen aufgeteilt werden, wodurch es möglich wird, andere Arbeitsschritte vor dem Abschluss früherer Arbeitsschritte zu beginnen. Multithreading wird auch eingesetzt, um das parallele Verarbeiten mehrerer Anweisungsströme zu ermöglichen, wodurch mehr allgemeine Aufgaben in jedem beliebigen Taktzyklus durchgeführt werden können.
Selbst mit einer höheren Taktgeschwindigkeit und Parallelverarbeitung stellen herkömmliche Techniken für das Erkennen von Zusammenstößen und das Weiterleiten von Impulsen in den meisten herkömmlichen Architekturen noch immer Leistungsengpässe dar. Insbesondere benötigen herkömmliche Techniken häufig eine große Anzahl von Direktspeicherzugriffen zum Abrufen und Verwalten von Objekten in einer Szene, wodurch sich, wie sich gezeigt hat, eine geringe Auslastung des Cachespeichers sowie andere mit der Leistungsfähigkeit zusammenhängende Engpässe ergeben.
Des Weiteren kann das Verteilen der Arbeitslast zwischen mehreren parallelen Ausführungs-Threads in vielen dynamischen Echtzeitumgebungen problematisch sein. Insbesondere die Anzahl von Objekten und die Verteilung dieser Objekte innerhalb einer gegebenen Szene können im Zeitverlauf schwanken. Während Zusammenstöße zwischen mehreren Objekten, die erhebliche Verarbeitungsressourcen benötigen, zu einem Zeitpunkt in einem Bereich einer Szene auftreten können, können zu einem anderen Zeitpunkt umfangreichere Zusammenstöße und somit eine höhere Verarbeitungsarbeitslast in anderen Bereichen der Szene auftreten.
Deshalb gibt es in dem Stand der Technik weiterhin einen Bedarf für eine Art des effizienten Bewältigens der Physikzusammenstoßerkennung und Impulsweiterleitung in einer Physik-Engine.
Die wissenschaftliche Veröffentlichung „Massively Parallel Rigid Multi-Body Dynamics. Technical Report 09-8“ von K. Iglberger und U. Rüde, erschienen am 09. Juli 2009 am Lehrstuhl für Informatik 10 (Systemsimulation) der Friedrich-Alexander Universität Erlangen-Nürnberg, offenbart einen Ansatz für groß angelegte Starrkörperdynamiksimulationen. Der vorgestellte Algorithmus ermöglicht Starrkörpersimulationen von mehr als einer Milliarde Starrkörpern. Die Autoren beschreiben im Detail den parallelen Starrkörper-Algorithmus und seine notwendigen Erweiterungen für eine groß angelegte MPI-Parallelisierung und analysieren den parallelen Algorithmus anhand eines bestimmten Simulationsszenarios. Bei den vorgestellten Techniken zur parallelen Mehrkörpersimulation ist der Simulationsbereich in Unterbereiche aufgeteilt, die einem jeweiligen Prozess zugeordnet sind, und die Prozesse werden auf eine Vielzahl von Cores verteilt. Hinsichtlich Kollisionen, an denen Festkörper verschiedener Unterbereiche beteiligt sind, tauschen die Prozesse Nachrichten betreffend die Kollisions- und Reibungsbedingungen aus.
Die wissenschaftliche Veröffentlichung „Scalability of relaxed consistency models in NoC based multicore architectures“ von A. Naeem et al., erschienen in ACM SIGARCH Computer Architecture News, 2010, Vol. 37(5): 8-15, enthält Lehren hinsichtlich der Skalierbarkeit von abgeschwächten Speicherkonsistenzmodellen in als Network-On-Chip realisierten Multi-Core-Systemen mit verteiltem gemeinsamem Speicher. Dabei werden eine Speicherstrategie mit schwacher Speicherkonsistenz und eine Speicherstrategie mit Freigabekonsistenz einander gegenübergestellt. Das Modell der schwachen Speicherkonsistenz erzwingt Synchronisierung-zu-Daten, Daten-zu-Synchronisierung und Synchronisierung-zu-Synchronisierung als globale Ordnungen für Operationen im gemeinsamen Speicher. Das Modell der Freigabekonsistenz erzwingt bei Operationen im gemeinsamen Speicher Erwerben-zu-Daten, Daten-zu-Freigeben, Erwerben-zu-Freigeben und Freigeben-zu-Erwerben als globale Ordnungen.
ZUSAMMENFASSUNG DER ERFINDUNG
Die der Erfindung zugrundeliegenden Aufgaben werden jeweils mit den Merkmalen der unabhängigen Patentansprüche gelöst. Ausführungsformen der Erfindung sind Gegenstand der abhängigen Patentansprüche.
Die Erfindung geht diese und andere mit dem Stand der Technik verbundene Probleme an, indem sie eine Schaltkreisanordnung und ein Verfahren bereitstellt, welche die Impulsweiterleitung in einer Multithread-Physik-Engine realisieren, indem der Besitz von Objekten in einer Szene einzelnen Threads zugewiesen wird und Impulse zwischen sich berührenden Objekten weitergeleitet werden, indem thread-übergreifende Impulsnachrichten zwischen den Threads weitergeleitet werden, denen die sich berührenden Objekte gehören, während durch Verwendung der Threads, denen derartige Objekte zugewiesen sind, Impulse lokal durch Objekte weitergeleitet werden.
Deshalb werden Impulse in Übereinstimmung mit einem Aspekt der Erfindung zwischen einer Vielzahl von Objekten in einer Szene unter Verwendung einer Multithread-Physik-Engine weitergeleitet. Für jedes der Vielzahl von Objekten wird einem aus einer Vielzahl von Threads in der Multithread-Physik-Engine der Besitz eines derartigen Objekts zugewiesen. Außerdem wird der Impuls als Reaktion darauf, dass ein Impuls durch ein erstes Objekt unter der Vielzahl von Objekten empfangen wird, lokal durch das erste Objekt weitergeleitet, indem ein erster Thread unter der Vielzahl von Threads verwendet wird, dem der Besitz an dem ersten Objekt zugewiesen wurde, und der Impuls wird an mindestens ein zusätzliches Objekt unter der Vielzahl von Objekten weitergeleitet, welches das erste Objekt berührt, indem eine thread-übergreifende Nachricht von dem ersten Thread an einen zweiten Thread unter der Vielzahl von Threads gesendet wird, dem der Besitz an dem zusätzlichen Objekt zugewiesen wurde.
In einem anderen Aspekt betrifft die Erfindung eine Schaltkreisanordnung, die Folgendes umfasst:

Network-on-Chip-Hardware-Logik, die eine Vielzahl von eine Vielzahl von Hardware-Threads festlegenden Verarbeitungskernen und ein chipintegriertes Netzwerk enthält, das die Vielzahl von Verarbeitungskernen miteinander verbindet; und
eine von mindestens einem Teil der Vielzahl von Hardware-Threads ausgeführte Physik-Engine, wobei die Physik-Engine eine Multithread-Software-Pipeline enthält, die eine Vielzahl von Stufen enthält, die so konfiguriert sind, dass sie Zusammenstöße zwischen Objekten aus einer Vielzahl von Objekten in einer Szene erkennen, sowie eine Vielzahl von Impuls-Weiterleitungs-Threads enthält, die so konfiguriert sind, dass sie Impulse zwischen einer Reihe von benachbarten Objekten aus der Vielzahl von sich berührenden Objekten weiterleiten;
wobei die Physik-Engine so konfiguriert ist, dass sie für jedes aus der Reihe von benachbarten Objekten den Besitz an dem Objekt einem der Vielzahl von Impuls-Weiterleitungs-Threads zuweist und eine Tabelle über benachbarte Objekten für den Impuls-Weiterleitungs-Thread erzeugt, dem das Objekt zugewiesen ist, die jedes Objekt aus der Reihe von benachbarten Objekten identifiziert, die das Objekt berührt;
wobei die Physik-Engine so konfiguriert ist, dass sie als Reaktion auf einen erkannten Zusammenstoß mit einem ersten Objekt aus der Reihe von benachbarten Objekten eine erste thread-übergreifende Impulsnachricht erzeugt, die eine Größenordnung und eine Richtung enthält; und
wobei jeder Impuls-Weiterleitungs-Thread unter der Vielzahl von Impuls-Weiterleitungs-Threads so konfiguriert ist, dass er als Reaktion auf das Empfangen einer einem Impuls zugehörigen thread-übergreifenden Impulsnachricht den Impuls lokal durch ein Objekt weiterleitet, dessen Besitz dem Impuls-Weiterleitungs-Thread zugewiesen ist, für jedes in der Tabelle über benachbarte Objekte für den Impuls-Weiterleitungs-Thread identifizierte benachbarte Objekt eine Größenordnung und eine Richtung einer weitergeleiteten Kraft ermittelt, den Impuls für jedes in der Tabelle über benachbarte Objekte für den Impuls-Weiterleitungs-Thread identifizierte benachbarte Objekt an den Impuls-Weiterleitungs-Thread weiterleitet, indem er eine thread-übergreifende Impulsnachricht an diesen sendet, welche die dafür ermittelte Größenordnung und Richtung der weitergeleiteten Kraft enthält, eine thread-übergreifende Impulsbestätigungsnachricht von jedem benachbarten Objekt empfängt, das in der Tabelle über benachbarte Objekte für den Impuls-Weiterleitungs-Thread identifiziert wurde, eine Größenordnung und eine Richtung einer Reaktionskraft zumindest teilweise beruhend auf den thread-übergreifenden Impulsbestätigungsnachrichten ermittelt und eine thread-übergreifende Impulsbestätigungsnachricht mit der Größenordnung und Richtung der Reaktionskraft als Bestätigung für die empfangene thread-übergreifende Impulsnachricht sendet.

In einem weiteren Aspekt betrifft die Erfindung eine Schaltkreisanordnung, die Folgendes umfasst:

Eine Hardware-Multithread-Physik-Engine; und Programmcode, der zumindest einen Teil einer Multithread-Physik-Engine umsetzt, wobei der Programmcode so konfiguriert ist, dass er Impulse zwischen einer Vielzahl von Objekten in einer Szene weiterleitet, wobei der Programmcode so konfiguriert ist, dass er für jedes der Vielzahl von Objekten einem aus einer Vielzahl von Threads in der Multithread-Physik-Engine den Besitz des Objekts zuweist, wobei der Programmcode ferner so konfiguriert ist, dass er als Reaktion auf einen von einem ersten Objekt unter der Vielzahl von Objekten empfangenen Impuls den Impuls lokal durch das erste Objekt unter Verwendung eines ersten Thread unter der Vielzahl von Threads weiterleitet,
dem der Besitz des ersten Objekts zugewiesen wurde, und den Impuls an mindestens ein weiteres Objekt unter der Vielzahl von Objekten weiterleitet, welches das erste Objekt berührt, indem er eine thread-übergreifende Nachricht von dem ersten Thread an einen zweiten Thread unter der Vielzahl von Threads sendet, dem der Besitz an dem zusätzlichen Objekt zugewiesen wurde.

Gemäß einer Ausführungsform der Erfindung berührt das erste Objekt eine Vielzahl von benachbarten Objekten, wobei der Programmcode so konfiguriert ist, dass er den Impuls weiterleitet, indem er für jedes der Vielzahl von benachbarten Objekten eine thread-übergreifende Nachricht von dem ersten Thread an einen Thread unter der Vielzahl von Threads sendet, dem der Besitz an dem benachbarten Objekt zugewiesen wurde.
Gemäß einer Ausführungsform der Erfindung ist der Programmcode so konfiguriert, dass er den Impuls an das zusätzliche Objekt weiterleitet, indem er auf eine physische Konstante zugreift, die einer physischen Beziehung zwischen dem ersten und dem zusätzlichen Objekt zugehörig ist, um eine Größenordnung und Richtung einer Kraft zu ermitteln, wobei die thread-übergreifende Nachricht die ermittelte Größenordnung und Richtung der Kraft enthält, wobei die physische Konstante mindestens entweder eine Federkonstante oder eine Reißkonstante enthält.
Gemäß einer Ausführungsform der Erfindung ist der Programmcode so konfiguriert, dass er den Impuls als Reaktion auf eine zweite thread-übergreifende Nachricht, die durch den ersten Thread empfangen wurde, lokal weiterleitet, wobei die zweite thread-übergreifende Nachricht eine dem Impuls zugehörige Größenordnung und Richtung enthält, und wobei der Programmcode so konfiguriert ist, dass er den Impuls lokal weiterleitet, indem er ermittelt, ob eine Restkraft verbleibt, die an das zusätzliche Objekt weiterzuleiten ist, so dass der Impuls nur dann an das zusätzliche Objekt weitergeleitet wird, wenn eine Restkraft verbleibt.
Gemäß einer Ausführungsform der Erfindung ist der Programmcode ferner so konfiguriert, dass er eine Reaktionskraft ermittelt und als Bestätigung für die zweite thread-übergreifende Nachricht eine thread-übergreifende Nachricht mit der ermittelten Reaktionskraft sendet.
Gemäß einer Ausführungsform der Erfindung ist der Programmcode ferner so konfiguriert, dass er in dem ersten Thread als Bestätigung für die erste thread-übergreifende Nachricht eine dritte thread-übergreifende Nachricht von dem zweiten Thread empfängt, wobei die dritte thread-übergreifende Nachricht eine zweite Reaktionskraft enthält, wobei das Ermitteln der ersten Reaktionskraft zumindest teilweise auf der zweiten Reaktionskraft beruht.
Gemäß einer Ausführungsform der Erfindung ist der Programmcode ferner so konfiguriert, dass er für das erste Objekt eine Reihe von benachbarten Objekten ermittelt, die das erste Objekt in der Szene berührt, und eine Datenstruktur über benachbarte Objekte erzeugt, welche die Reihe von benachbarten Objekten identifiziert, wobei der erste Thread so konfiguriert ist, dass er auf die Datenstruktur über benachbarte Objekte zugreift, um zu ermitteln, an welche Objekte unter der Vielzahl von Objekten der Impuls weitergeleitet werden sollte.
Gemäß einer Ausführungsform der Erfindung enthält die Vielzahl von Threads eine Vielzahl von Impuls-Weiterleitungs-Threads, wobei die Multithread-Physik-Engine mindestens einen Zusammenstoß-Erkennungs-Thread enthält, und wobei der Programmcode ferner so konfiguriert ist, dass er als Reaktion auf das Erkennen eines zukünftigen Zusammenstoßes zwischen Objekten in einer Szene eine Neuzuordnung der Arbeitslast unter der Vielzahl von Impuls-Weiterleitungs-Threads einleitet.
Gemäß einer Ausführungsform der Erfindung umfasst die Multithread-Physik-Engine eine Multithread-Software-Pipeline, die eine Vielzahl von Hardware-Threads verwendet, wobei die Multithread-Software-Pipeline eine Vielzahl von Stufen enthält, die so konfiguriert sind, dass sie Zusammenstöße zwischen Objekten in einer Szene erkennen, wobei die Vielzahl von Stufen mindestens eine Komponentenladestufe, eine Vielzahl von der Vielzahl von Hardware-Threads zugewiesenen Zusammenstoßerkennungsstufen und eine Vielzahl von Impuls-Weiterleitungs-Threads enthält.
Gemäß einer Ausführungsform der Erfindung ist die Multithread-Physik-Engine in Network-on-Chip-Hardware-Logik umgesetzt, die eine Vielzahl von eine Vielzahl von Hardware-Threads festlegenden Verarbeitungskernen und ein die Vielzahl von Verarbeitungskernen miteinander verbindendes chipintegriertes Netzwerk enthält, und wobei die thread-übergreifenden Nachrichten unter Verwendung des chipintegrierten Netzwerks zwischen Hardware-Threads ausgetauscht werden.
Figurenliste
Bevorzugte Ausführungsformen der vorliegenden Erfindung werden nun lediglich beispielhaft unter Bezugnahme auf die beigefügten Zeichnungen beschrieben. Es zeigen:

1 ein Blockschaltbild einer beispielhaften automatisierten Datenverarbeitungsmaschine, die einen beispielhaften Computer enthält, der für die Datenverarbeitung in Übereinstimmung mit Ausführungsformen der vorliegenden Erfindung nützlich ist.
2 ein Blockschaltbild eines beispielhaften NOC, das in dem Computer aus 1 umgesetzt ist;
3 ein Blockschaltbild, das eine beispielhafte Umsetzung eines Knotens des NOC aus 2 ausführlicher veranschaulicht;
4 ein Blockschaltbild, das eine beispielhafte Umsetzung des IP-Blocks des NOC aus 2 veranschaulicht;
5 ein Blockschaltbild einer Thread-Pipeline-Software-Engine, die zum Umsetzen in dem NOC aus 2 geeignet ist;
6 ein Blockschaltbild einer beispielhaften Software-Pipeline, die zum Umsetzen in der Thread-Pipeline-Software-Engine aus 5 geeignet ist;
7 ein Blockschaltbild einer beispielhaften Wiedergabe-Software-Pipeline, die zum Umsetzen in der Thread-Pipeline-Software-Engine aus 5 geeignet ist;
8 ein Schaubild einer beispielhaften Szene zum Veranschaulichen des Erzeugens einer geometrie-internen Darstellung unter Verwendung des GIR-Erzeugers aus 7;
9 ein Blockschaltbild einer geometrie-internen Darstellung, die für die beispielhafte Szene aus 9 erzeugt wurde;
10 einen Ablaufplan, der den Programmablauf einer durch den GIR-Erzeuger aus 7 ausgeführten Geometrie-Anordnungsroutine veranschaulicht;
11 einen Ablaufplan, der den Programmablauf einer durch den GIR-Erzeuger aus 7 ausgeführten Hinzufügen-Geometrie-Routine veranschaulicht;
12 ein Blockschaltbild einer beispielhaften Umsetzung des im Datenstrom übertragenden Geometrie-Front-End, auf das in 7 Bezug genommen wird;
13 ein Blockschaltbild einer beispielhaften Umsetzung des Back-End zum punktweisen Betrachten, auf das in 7 Bezug genommen wird;
14A und 14B gemeinsam eine ausführlichere Veranschaulichung einer Umsetzung der Wiedergabe-Software-Pipeline aus 7;
15 ein Schaubild einer beispielhaften Szene zum Veranschaulichen des Erkennens von Zusammenstößen in einer mit der Erfindung übereinstimmenden Weise;
16 ein Blockschaltbild eines beispielhaften NOC, das dazu geeignet ist, die Zusammenstoßerkennung in einer mit der Erfindung übereinstimmenden Weise umzusetzen;
17 einen Ablaufplan, der den Programmablauf einer beispielhaften durch einen Master-Thread in dem NOC aus 16 ausgeführten Zusammenstoßerkennungsroutine veranschaulicht;
18 einen Ablaufplan, der den Programmablauf einer beispielhaften durch einen Slave-Thread in dem NOC aus 16 ausgeführten Zusammenstoßerkennungsroutine veranschaulicht;
19 ein Schaubild einer beispielhaften Szene zum Veranschaulichen des vorausschauenden Lastenausgleichs in einer mit der Erfindung übereinstimmenden Weise;
20 einen Ablaufplan, der den Programmablauf einer beispielhaften Physik-Engine veranschaulicht, die den vorausschauenden Lastenausgleich in einer mit der Erfindung übereinstimmenden Weise einschließt;
21 einen Ablaufplan, der den Programmablauf der vorausschauenden Lastenausgleichsroutine veranschaulicht, auf die in 20 Bezug genommen wird
22 einen Ablaufplan, der den Programmablauf einer beispielhaften durch einen Master-Thread in dem NOC aus 16 ausgeführten Zusammenstoßerkennungsroutine veranschaulicht, die einen vorausschauenden Lastenausgleich in Übereinstimmung mit der Erfindung verwendet;
23 einen Ablaufplan, der den Programmablauf einer beispielhaften durch einen Slave-Thread in dem NOC aus 16 ausgeführten Zusammenstoßerkennungsroutine veranschaulicht, die einen vorausschauenden Lastenausgleich in Übereinstimmung mit der Erfindung verwendet;
24 ein Blockschaubild eines beispielhaften dynamischen Partikeldynamikgitters zur Verwendung mit der Impulsweiterleitung in einer mit der Erfindung übereinstimmenden Weise;
25 ein Blockschaltbild eines beispielhaften NOC, das dazu geeignet ist, die Impulsweiterleitung in einer mit der Erfindung übereinstimmenden Weise umzusetzen;
26 einen Ablaufplan, der den Programmablauf einer beispielhaften Initialisierungsroutine zur Verwendung in Verbindung mit der Impulsweiterleitung in Übereinstimmung mit der Erfindung unter Verwendung des NOC aus 25 veranschaulicht;
27 ein Blockschaubild einer beispielhaften Umsetzung der Tabelle über benachbarte Objekte, auf die in 26 Bezug genommen wird; und
28 einen Ablaufplan, der den Programmablauf einer beispielhaften durch einen Software-Thread in dem NOC aus 25 ausgeführten Impulsweiterleitungsroutine veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Ausführungsformen in Übereinstimmung mit der Erfindung verwenden thread-übergreifende Impulsnachrichten in einer Multithread-Physik-Engine zur Verbesserung des Durchsatzes in einem zum Weiterleiten von Impulsen zwischen Objekten in einer Szene verwendeten Impulsweiterleitungsalgorithmus. Eine Szene in dem Kontext der Erfindung betrifft die „Welt“ bzw. den mehrdimensionalen Raum, innerhalb dessen Objekte platziert werden, bevor ein Bildrahmen wiedergegeben wird. Üblicherweise handelt es sich bei einer Szene um einen dreidimensionalen Objektraum; zur Vereinfachung der folgenden Erörterung veranschaulichen viele der Beispiele jedoch eine zweidimensionale Szene. Man wird jedoch verstehen, dass eine Szene in Übereinstimmung mit der Erfindung beliebig viele Dimensionen enthalten kann.
In mit der Erfindung übereinstimmenden Ausführungsformen werden Objekte in einer Szene einer Vielzahl von Threads zugewiesen, so dass jeder Thread faktisch ein oder mehrere Objekte „besitzt“. Threads können die Objekte, welche die ihnen gehörenden Objekte berühren, sowie die Threads, die diese berührten Objekte besitzen, ermitteln, so dass der Thread des Objekts als Reaktion auf das Anwenden eines Impulses auf ein Objekt den Impuls durch das Objekt lokal weiterleiten und unter der Annahme, dass der Impuls nicht vollständig in dem Objekt gedämpft wird, thread-übergreifende Impulsnachrichten an die Threads senden kann, denen die das Objekt berührenden Objekte gehören, um es diesen Threads zu ermöglichen, den Impuls durch deren entsprechende Objekte weiterzuleiten. Impulsnachrichten enthalten üblicherweise einen Wert, der die Größenordnung des an das berührte Objekt weitergeleiteten Impulses darstellt, sowie einen Vektor, der die Richtung des Impulses darstellt.
Außerdem kann in einigen Ausführungsformen jeder Thread im Namen der ihm gehörenden Objekte einen Reaktionsimpuls in Form einer thread-übergreifenden Impulsbestätigungsnachricht zurücksenden. Bestätigungsnachrichten können in einigen Ausführungsformen auch optional sein, falls keine Reaktionsimpulse als Reaktion auf einen Impuls erzeugt werden (z.B., wenn das einen Impuls empfangende Objekt den Impuls vollständig dämpft).
Wie nachfolgend besser ersichtlich werden wird, verwendet eine besonders nützliche Hardware-Umgebung, die in Verbindung mit einer mit der Erfindung übereinstimmenden Impulsweiterleitung verwendet werden kann, eine Network-on-Chip- (NOC-) Anordnung, in der mehrere Prozessorkerne auf derselben integrierten Schaltkreiseinheit angeordnet und über ein Netzwerk von Punkt-zu-Punkt-Verbindungen miteinander verbunden sind, wobei zum Weiterleiten von Nachrichten zwischen den Kernen Eingänge (inboxes) verwendet werden. Thread-übergreifende Nachrichten können in derartigen Ausführungsformen durch zwischen Kernen weitergeleitete kernübergreifende Nachrichten umgesetzt werden, z.B. durch die nachfolgend ausführlicher erörterten IP-Blöcke. Man wird jedoch verstehen, dass andere Multithread-Hardware-Anordnungen und andere Meldeformate und - netzwerke zum Weiterleiten von kernübergreifenden Impulsnachrichten zwischen Threads in Übereinstimmung mit der Erfindung verwendet werden können.
In einigen Ausführungsformen kann eine Physik-Engine Impulsweiterleitung durch Übertragen von Detailstufenkomponenten im Datenstrom zwischen Hardware-Threads in einer Multithread-Schaltkreis-Anordnung umsetzen, z.B. wie in der US-Patentanmeldung Nr. 12/778 , 390 dargelegt, die am 12. Mai 2010 eingereicht und demselben Anmelder wie für die vorliegende Erfindung übertragen wurde und die hierin durch Bezugnahme aufgenommen wird, und sie kann vorausschauenden Lastenausgleich verwenden, z.B., wie in der US-Patentanmeldung Nr. 12/822 , 615 dargelegt, die am 24. Juni 2010 eingereicht und demselben Anmelder wie für die vorliegende Erfindung übertragen wurde und die hierin durch Bezugnahme aufgenommen wird. In derartigen Ausführungsformen wird ein Komponenten-Lade-Hardware-Thread, der als Master-Thread arbeitet, zum Abrufen von Detailstufendaten für ein Objekt aus einem Speicher und zum Übertragen der Daten im Datenstrom an einen oder mehrere Zusammenstoß-Erkennungs-Threads, die als Slave-Hardware-Threads arbeiten, verwendet. Slave-Hardware-Threads können ebenfalls Detailstufendaten an andere Slave-Hardware-Threads im Datenstrom übertragen, z.B. an weiter hinten in einer Software-Pipeline angeordnete Slave-Hardware-Threads. Da die Slave-Hardware-Threads Detailstufendaten von dem Master-Thread empfangen, müssen die Slave-Hardware-Threads üblicherweise die Daten nicht aus dem Speicher laden, wodurch Bandbreitenanforderungen an den Speicher verringert werden und die Durchführung beschleunigt wird. Man wird jedoch verstehen, dass Impulsweiterleitung in Übereinstimmung mit der Erfindung in anderen Physik-Engine-Konstruktionen als die in den oben erwähnten Anmeldungen dargelegten verwendet werden kann.
Für einen Fachmann werden andere Abwandlungen und Abänderungen ersichtlich sein. Deshalb ist die Erfindung nicht auf die speziellen hierin erörterten Ausführungen beschränkt.
HARDWARE- UND SOFTWARE-UMGEBUNG
Wenden wir uns nun den Zeichnungen zu, in denen gleiche Zahlen gleiche Teile in den mehreren Ansichten angeben, so veranschaulicht 1 eine beispielhafte automatisierte Datenverarbeitungsmaschine, die einen beispielhaften Computer 10 enthält, der für die Datenverarbeitung in Übereinstimmung mit Ausführungsformen der vorliegenden Erfindung nützlich ist. Der Computer 10 aus 1 enthält mindestens einen Computerprozessor 12 bzw. eine ,CPU' sowie den Direktzugriffsspeicher 14 (,RAM'), der über einen Hochgeschwindigkeits-Speicherbus 16 und den Busadapter 18 mit dem Prozessor 12 und mit anderen Komponenten des Computers 10 verbunden ist.
In dem RAM 14 ist ein Anwendungsprogramm 20 gespeichert, ein Modul mit Computerprogrammanweisungen auf Benutzerebene zum Ausführen bestimmter Datenverarbeitungsaufgaben wie Textverarbeitung, Tabellenkalkulation, Datenbankoperationen, Videospiele, Aktienmarktsimulationen, atomare Quanten-Verarbeitungssimulationen oder andere Anwendungen auf Benutzerebene. In dem RAM 14 ist ebenfalls ein Betriebssystem 22 gespeichert. Zu Betriebssystemen, die in Verbindung mit Ausführungsformen der Erfindung nützlich sind, gehören UNIX™, Linux™, Microsoft Windows XP™, AIX™, IBMs i5/OS™ und andere, wie einem Fachmann klar sein wird. Das Betriebssystem 22 und die Anwendung 20 in dem Beispiel aus 1 sind in dem RAM 14 gezeigt, wobei viele Komponenten derartiger Software üblicherweise auch in nichtflüchtigem Speicher, z.B. auf einem Plattenlaufwerk 24, gespeichert sind.
Wie nachfolgend besser ersichtlich wird, können mit der Erfindung übereinstimmende Ausführungsformen in Network-on-Chip- (NOC-) integrierten Schaltkreiseinheiten bzw. Chips umgesetzt werden, und als solches ist der Computer 10 als zwei beispielhafte NOCs enthaltend dargestellt: einen Videoadapter 26 und einen Coprozessor 28. Bei dem NOC-Video-Adapter 26, der alternativ Grafikadapter genannt werden kann, handelt es sich um einen E/A-Adapter, der speziell für die Grafikausgabe an eine Anzeigeeinheit 30 wie einen Anzeigeschirm oder Computerbildschirm entworfen wurde. Der NOC-Video-Adapter 26 ist mit dem Prozessor 12 über einen Hochgeschwindigkeits-Videobus 32, den Busadapter 18 und den Front-Side-Bus 34 verbunden, bei dem es sich auch um einen Hochgeschwindigkeitsbus handelt. Der NOC-Coprozessor 28 ist mit dem Prozessor 12 über den Busadapter 18 und die Front-Side-Busse 34 und 36 verbunden, bei denen es sich auch um einen Hochgeschwindigkeitsbus handelt. Der NOC-Coprozessor aus 1 kann zum Beispiel so optimiert sein, dass er bestimmte Datenverarbeitungsaufgaben auf Geheiß des Hauptprozessors 12 beschleunigt.
Der beispielhafte NOC-Video-Adapter 26 und der NOC-Coprozessor 28 aus 1 enthalten jeweils ein NOC, die integrierte Prozessor- (,IP'-) Blöcke, Router, Speicher-Datenübertragungs-Steuereinheit und Netzwerkschnittstellen-Steuereinheiten enthalten, deren Einzelheiten ausführlicher in Zusammenhang mit den 2 bis 3 erörtert werden. Der NOC-Video-Adapter und der NOC-Coprozessor sind jeweils für Programme optimiert, die eine parallele Verarbeitung verwenden und auch einen schnellen Direktzugriff auf gemeinsam genutzten Speicher benötigen. Mit Unterstützung der vorliegenden Darlegung wird ein Fachmann jedoch verstehen, dass die Erfindung in anderen Einheiten und Einheitenarchitekturen als NOC-Einheiten und NOC-Einheitenarchitekturen umgesetzt werden kann. Die Erfindung ist deshalb nicht auf eine Umsetzung in einer NOC-Einheit beschränkt.
Der Computer 10 aus 1 enthält den Plattenlaufwerksadapter 38, der über einen Erweiterungsbus 40 und den Busadapter 18 mit dem Prozessor 12 und anderen Komponenten des Computers 10 verbunden ist. Der Plattenlaufwerksadapter 38 verbindet nichtflüchtigen Datenspeicher mit dem Computer 10 in Form der Plattenlaufwerke 24 und kann zum Beispiel unter Verwendung von IDE-Adaptern (Festplatten-Schnittstelle - Integrated Drive Electronics), SCSI-Adaptern (Kleinrechner-Schnittstelle - Small Computer System Interface) u.a. umgesetzt werden, wie einem Fachmann klar sein wird. Nichtflüchtiger Computerspeicher kann auch als optisches Plattenlaufwerk, elektrisch löschbarer programmierbarer Nur-Lese-Speicher (sogenannter ,EEPROM' bzw. Flash'-Speicher), RAM-Laufwerke usw. umgesetzt werden, wie einem Fachmann klar sein wird.
Der Computer 10 enthält auch einen oder mehrere Eingabe/Ausgabe- (,E/A'-) Adapter 42, die eine benutzerorientierte Eingabe/Ausgabe zum Beispiel durch Software-Treiber und Computer-Hardware zum Steuern einer Ausgabe an Anzeigeeinheiten wie Computeranzeigeschirme sowie Benutzereingaben von den Benutzereingabeeinheiten 44 wie Tastaturen und Mäusen umsetzen. Außerdem enthält der Computer 10 einen Datenübertragungsadapter 46 für den Datenaustausch mit anderen Computern 48 und für den Datenaustausch mit einem Datenübertragungsnetzwerk 50. Derartige Datenübertragungen können seriell über RS-232-Verbindungen, über externe Busse wie einen universellen seriellen Bus (,USB'), über Datenübertragungsnetzwerke wie IP-Datenübertragungsnetzwerke und auf andere Arten ausgeführt werden, wie einem Fachmann klar sein wird. Datenübertragungsadapter setzen die Hardware-Ebene der Datenübertragung um, durch die ein Computer Datenübertragungen direkt oder über ein Datenübertragungsnetzwerk an andere Computer sendet. Zu Beispielen von Datenübertragungsadaptern, die zur Verwendung in dem Computer 10 geeignet sind, gehören Modems für drahtgebundene Einwähldatenübertragungen, Ethernet-(IEEE 802.3-) Adapter für drahtgebundene Datenübertragungs-Netzwerkdatenübertragungen sowie 802.11-Adapter für drahtlose Datenübertragungs-Netzwerkdatenübertragungen.
Zur näheren Erläuterung legt 2 ein Funktionsblockschaltbild eines beispielhaften NOC 102 gemäß Ausführungsformen der vorliegenden Erfindung dar. Das NOC in 2 ist auf einem ,Chip' 100 umgesetzt, d.h., auf einem integrierten Schaltkreis. Das NOC 102 enthält die integrierten Prozessor- (,IP'-) Blöcke 104, die Router 110, die Speicher-Datenübertragungs-Steuereinheiten 106 und die Netzwerkschnittstellen-Steuereinheiten 108, die in zusammengeschaltete Knoten gruppiert sind. Jeder IP-Block 104 ist über eine Speicher-Datenübertragungs-Steuereinheit 106 und eine Netzwerkschnittstellen-Steuereinheit 108 mit einem Router 110 verbunden. Jede Speicher-Datenübertragungs-Steuereinheit steuert den Datenaustausch zwischen einem IP-Block und Speicher, und jede Netzwerkschnittstellen-Steuereinheit 108 steuert IP-Block-übergreifende Datenübertragungen über die Router 110.
In dem NOC 102 stellt jeder IP-Block eine wiederverwendbare Einheit mit einer synchronen oder asynchronen Logikstruktur dar, die als Modul für die Datenverarbeitung in dem NOC verwendet wird. Der Begriff ,IP-Block' wird manchmal als ,geistiger Eigentumsblock' ausgeschrieben, was einen IP-Block effektiv als eine Konstruktion kennzeichnet, die einer Partei gehört, d.h. das geistige Eigentum einer Partei zum Lizenzieren an andere Benutzer oder Entwickler von Halbleiter-Schaltkreisen darstellt. Im Umfang der vorliegenden Erfindung gibt es jedoch keine Notwendigkeit, dass IP-Blöcke irgendeinem Eigentumsrecht unterliegen müssen, so dass der Begriff in dieser Beschreibung immer als integrierter Prozessorblock' ausgeschrieben wird. Bei den hier beschriebenen IP-Blöcken handelt es sich um wiederverwendbare Einheiten eines Logik-, Zellen- oder Chip-Layout-Entwurfs, die einem geistigen Eigentum unterliegen können, aber nicht müssen. Bei IP-Blöcken handelt es sich um Logikkerne, die als ASIC-Chip-Entwürfe bzw. FPGA-Logikentwürfe gebildet werden können.
Eine Art zum Beschreiben von IP-Blöcken durch Analogien lautet, dass IP-Blöcke für NOC-Entwürfe das darstellen, was eine Bibliothek für das Programmieren von Computern darstellt oder was eine einzelne Komponente einer integrierten Schaltung für die Konstruktion von Leiterplatten bedeuten. In mit Ausführungsformen der vorliegenden Erfindung übereinstimmenden NOCs können IP-Blöcke als allgemeine Gatternetzlisten, als vollständige Spezial- oder Universal-Mikroprozessoren oder auf andere Arten umgesetzt werden, wie einem Fachmann klar sein wird. Bei einer Netzliste handelt es sich um eine boolesche Algebra-Darstellung (Gatter, Standardzellen) einer Logikfunktion eines IP-Blocks, analog einer Assembler-Code-Liste für eine höhere Programmanwendung. NOCs können zum Beispiel auch in synthetisierbarer Form umgesetzt werden, beschrieben in einer Hardware-Beschreibungssprache wie Verilog oder VHDL. Außer Umsetzungen als Netzliste und synthetisierbar, können NOCs auch in physischen Beschreibungen auf niedrigerem Niveau bereitgestellt werden. Analoge IP-Block-Elemente wie SERDES, PLL, DAC, ADC usw. können in einem Transistoranordnungsformat wie GDSII verteilt werden. Digitale Elemente von IP-Blöcken werden manchmal auch in Anordnungsformat (layout format) angeboten. Man wird auch verstehen, dass IP-Blöcke sowie andere Logikschaltungen, die in Übereinstimmung mit der Erfindung umgesetzt sind, in Form von Computerdatendateien wie Logikdefinitions-Programmcode verteilt werden können, welche die Funktionalität und/oder die Anordnung der eine derartige Logik umsetzenden Schaltkreisanordnungen in unterschiedlichen Detailstufen festlegen. Obwohl die Erfindung in Zusammenhang mit Schaltkreisanordnungen beschrieben wurde und nachfolgend beschrieben wird, die in voll funktionsfähigen integrierten Schaltungseinheiten, derartige Einheiten nutzenden Datenverarbeitungssystemen und anderen greifbaren, physischen Hardware-Schaltungen umgesetzt sind, wird ein Fachmann mit Unterstützung der vorliegenden Darlegung verstehen, dass die Erfindung auch in einem Programmprodukt umgesetzt werden kann, und dass die Erfindung gleichermaßen Anwendung findet, unabhängig von einer bestimmten Art von durch einen Computer lesbaren Speichermedium oder durch einen Computer lesbaren signalführenden Medium, das zum Verteilen des Programmprodukts verwendet wird. Zu Beispielen von durch einen Computer lesbaren Speichermedien gehören physische, beschreibbare Medien wie flüchtige und nichtflüchtige Speichereinheiten, Floppy-Disketten, Festplattenlaufwerke, CD-ROMs und DVDs (und andere), jedoch nicht darauf beschränkt, während zu Beispielen von signalführenden Medien übertragungsartige Medien wie digitale und analoge Datenübertragungsverbindungen gehören, aber nicht darauf beschränkt sind.
Jeder IP-Block 104 in dem Beispiel aus 2 ist über eine Speicher-Datenübertragungs-Steuereinheit 106 mit einem Router 110 verbunden. Bei jeder Speicher-Datenübertragungs-Steuereinheit handelt es sich um eine Anhäufung synchroner und asynchroner Logikschaltungen, die dafür geeignet sind, Datenübertragungen zwischen einem IP-Block und Speicher bereitzustellen. Zu Beispielen für derartige Datenübertragungen zwischen IP-Blöcken und Speicher gehören Ladeanweisungen für einen Speicher und Speicheranweisungen für einen Speicher. Die Speicher-Datenübertragungs-Steuereinheiten 106 werden nachfolgend in Bezug auf 3 ausführlicher beschrieben. Jeder IP-Block 104 ist über eine Netzwerkschnittstellen-Steuereinheit 108, der die Datenübertragungen durch die Router 110 zwischen den IP-Blöcken 104 steuert, ebenfalls mit einem Router 110 verbunden. Zu Beispielen für Datenübertragungen zwischen IP-Blöcken gehören Nachrichten, die Daten und Anweisungen zum Verarbeiten der Daten zwischen IP-Blöcken in parallelen Anwendungen und in Pipeline-Anwendungen tragen. Die Netzwerkschnittstellen-Steuereinheiten 108 werden nachfolgend in Bezug auf 3 ebenfalls ausführlicher beschrieben.
Die Router 110 und die entsprechenden Verbindungen 118 zwischen diesen setzen die Netzwerkoperationen des NOC um. Bei den Verbindungen 118 kann es sich um Paketstrukturen handeln, die auf physischen, parallelen, sämtliche Router verbindenden Drahtbussen umgesetzt sind. Das heißt, jede Verbindung kann auf einem Drahtbus umgesetzt werden, der breit genug ist, um gleichzeitig ein gesamtes Datenvermittlungspaket aufzunehmen, das sämtliche Kopfzeilendaten und Nutzdaten beinhaltet. Wenn eine Paketstruktur zum Beispiel 64 Bytes enthält, darunter eine Kopfzeile mit acht Bytes und 56 Bytes an Nutzdaten, ist der Drahtbus gegenüber jeder Verbindung 64 Bytes breit, 512 Drähte. Außerdem kann jede Verbindung bidirektional sein, so dass der Drahtbus tatsächlich 1024 Drähte zwischen jedem Router und jedem seiner Nachbarn in dem Netzwerk enthält, wenn die Verbindungspaketstruktur 64 Bytes enthält. In einer derartigen Ausführung könnte eine Nachricht mehr als ein Paket enthalten, wobei jedes Paket aber genau auf die Breite des Drahtbusses passen würde. Alternativ kann eine Verbindung auf einem Drahtbus realisiert werden, der nur breit genug ist, um einen Teil eines Pakets aufzunehmen, so dass ein Paket in mehrere Teile (beats) aufgeteilt würde, z.B. so, dass ein 64-Byte-Paket in vier Teile aufgeteilt werden könnte, wenn eine Verbindung als 16 Bytes breit bzw. mit 128 Drähten umgesetzt wird. Man wird verstehen, dass verschiedene Ausführungen beruhend auf praktischen physischen Grenzen sowie auf gewünschten Leistungseigenschaften unterschiedliche Busbreiten verwenden können. Wenn die Verbindung zwischen dem Router und jedem Abschnitt des Drahtbusses Anschluss (port) genannt wird, enthält jeder Router fünf Anschlüsse, einen für jede der vier Richtungen einer Datenübertragung in dem Netzwerk und einen fünften Anschluss zum Anschließen des Routers an einen bestimmten IP-Block über eine Speicher-Datenübertragungs-Steuereinheit und eine Netzwerkschnittstellen-Steuereinheit.
Jede Speicher-Datenübertragungs-Steuereinheit 106 steuert Datenübertragungen zwischen einem IP-Block und Speicher. Zu Speicher kann chipexterner Haupt-RAM 112, über eine Speicher-Datenübertragungs-Steuereinheit 106 direkt mit einem IP-Block verbundener Speicher 114, chipintegrierter, als IP-Block freigegebener Speicher 116 sowie chipintegrierter Cachespeicher zählen. In dem NOC 102 kann einer der chipintegrierten Speicher 114, 116 zum Beispiel als chipintegrierter Cachespeicher umgesetzt sein. All diese Speicherformen können sich in demselben Adressraum befinden, als physische Adressen oder virtuelle Adressen, was sogar für den direkt mit einem IP-Block verbundenen Speicher gilt. Deshalb können speicheradressierte Nachrichten in Bezug auf IP-Blöcke vollständig bidirektional sein, da derartiger Speicher direkt von jedem beliebigen IP-Block irgendwo in dem Netzwerk aufgerufen werden kann. Der Speicher 116 in einem IP-Block kann von diesem IP-Block oder von jedem beliebigen anderen IP-Block in dem NOC aufgerufen werden. Der direkt mit einer Speicher-Datenübertragungs-Steuereinheit verbundene Speicher 114 kann durch den IP-Block aufgerufen werden, der durch diese Speicher-Datenübertragungs-Steuereinheit mit dem Netzwerk verbunden ist - und er kann ebenfalls von jedem beliebigen anderen IP-Block irgendwo in dem NOC aufgerufen werden.
Das NOC 102 enthält zwei Speicherverwaltungseinheiten (,MMUs', memory management units) 120, 122, die zwei alternative Speicherarchitekturen für NOCs in Übereinstimmung mit Ausführungsformen der vorliegenden Erfindung veranschaulichen. Die MMU 120 ist innerhalb eines IP-Blocks umgesetzt und ermöglicht es einem Prozessor innerhalb des IP-Blocks Arbeitsschritte in virtuellem Speicher durchzuführen, während die gesamte restliche Architektur des NOC Arbeitsschritte in einem physischen Speicheradressraum durchführt. Die MMU 122 ist chipextern umgesetzt und mit dem NOC über einen Datenübertragungsanschluss 124 verbunden. Der Anschluss 124 enthält die Anschlussstifte und andere zum Leiten von Signalen zwischen dem NOC und der MMU benötigte Anschlüsse sowie eine ausreichend hohe Intelligenz, um Nachrichtenpakete von dem NOC-Paketformat in das von der externen MMU 122 benötigte Busformat umzuwandeln. Die externe Lage der MMU bedeutet, dass sämtliche Prozessoren in sämtlichen IP-Blöcken der NOC Arbeitsschritte in virtuellem Speicheradressraum durchführen können, wobei sämtliche Umwandlungen in physische Adressen des chipexternen Speichers durch die chipexterne MMU 122 bewältigt werden.
Zusätzlich zu den beiden durch die Verwendung der MMUs 120, 122 veranschaulichten Speicherarchitekturen veranschaulicht der Datenübertragungsanschluss 126 eine dritte Speicherarchitektur, die in NOCs nützlich ist, die in Ausführungsformen der vorliegenden Erfindung verwendet werden können. Der Anschluss 126 stellt eine direkte Verbindung zwischen dem IP-Block 104 des NOC 102 und dem chipexternen Speicher 112 bereit. Ohne MMU in dem Verarbeitungspfad stellt diese Architektur die Verwendung eines physischen Adressraums durch sämtliche IP-Blöcke des NOC bereit. Durch das gemeinsame Nutzen des Adressraums auf bidirektionale Weise können sämtliche IP-Blöcke des NOC über durch den direkt mit dem Anschluss 126 verbundenen IP-Block geleitete, speicheradressierte Nachrichten, darunter Ladevorgänge und Speichervorgänge, auf Speicher in dem Adressraum zugreifen. Der Anschluss 126 enthält die Anschlussstifte und andere zum Leiten von Signalen zwischen dem NOC und dem chipexternen Speicher 112 benötigte Anschlüsse sowie eine ausreichend hohe Intelligenz, um Nachrichtenpakete von dem NOC-Paketformat in das von dem chipexternen Speicher 112 benötigte Busformat umzuwandeln.
In dem Beispiel aus 2 ist einem der IP-Blöcke ein Host-Schnittstellen-Prozessor 128 zugewiesen. Ein Host-Schnittstellen-Prozessor 128 stellt eine Schnittstelle zwischen dem NOC und einem Host-Computer 10 bereit, in dem das NOC installiert werden kann, und stellt ebenfalls den anderen IP-Blöcken in dem NOC Datenverarbeitungsdienste bereit, darunter zum Beispiel das Empfangen und Senden der NOC-Datenverarbeitungsanforderungen von dem Host-Computer zwischen den IP-Blöcken. Ein NOC kann zum Beispiel einen Videografikadapter 26 oder einen Coprozessor 28 auf einem größeren Computer 10 als oben in Bezug auf 1 beschrieben realisieren. In dem Beispiel aus 2 ist der Host-Schnittstellen-Prozessor 128 mit dem größeren Host-Computer durch einen Datenübertragungsanschluss 130 verbunden. Der Anschluss 130 enthält die Anschlussstifte und andere zum Leiten von Signalen zwischen dem NOC und dem Host-Computer benötigte Anschlüsse sowie eine ausreichend hohe Intelligenz, um Nachrichtenpakete von dem NOC-Paketformat in das von dem Host-Computer 10 benötigte Busformat umzuwandeln. In dem Beispiel des NOC-Coprozessors in dem Computer aus 1 würde ein derartiger Anschluss eine Übersetzung von Datenübertragungsformaten zwischen der Verbindungsstruktur des NOC-Coprozessors 28 und dem für den Front-Side-Bus 36 zwischen dem NOC-Coprozessor 28 und dem Busadapter 18 benötigten Protokoll bereitstellen.
Als nächstes veranschaulicht 3 ein Funktionsblockschaltbild, das die innerhalb eines IP-Blocks 104, der Speicher-Datenübertragungs-Steuereinheit 106, der Netzwerkschnittstellen-Steuereinheit 108 und des Routers 110 in dem NOC 102 umgesetzten Komponenten, die bei 132 gemeinsam veranschaulicht sind, ausführlicher veranschaulicht. Der IP-Block 104 enthält einen Computerprozessor 134 und die E/A-Funktionalität 136. In diesem Beispiel wird der Computerspeicher durch ein Segment des Direktzugriffsspeichers (,RAM') 138 in dem IP-Block 104 dargestellt.
Wie oben in Bezug auf 2 beschrieben wurde, kann der Speicher Segmente eines physischen Adressraums belegen, dessen Inhalte in jedem IP-Block aufrufbar sind und auf die von jedem IP-Block in dem NOC zugegriffen werden kann. Die Prozessoren 134, die E/A-Funktionen 136 und der Speicher 138 in jedem IP-Block setzen in ihrer Wirkung die IP-Blöcke als allgemein programmierbare Mikrocomputer um. Wie oben erläutert stellen IP-Blöcke im Umfang der vorliegenden Erfindung jedoch allgemein wiederverwendbare Einheiten mit synchroner bzw. asynchroner Logik dar, die als Module für die Datenverarbeitung innerhalb eines NOC verwendet werden. Das Umsetzen von IP-Blöcken als allgemein programmierbare Mikrocomputer ist deshalb keine Einschränkung der vorliegenden Erfindung, obwohl es sich dabei um eine gebräuchliche Ausführungsform handelt, die zum Zwecke der Erläuterung nützlich ist.
In dem NOC 102 aus 3 enthält jede Speicher-Datenübertragungs-Steuereinheit 106 eine Vielzahl von Speicher-Datenübertragungs-Ausführungssteuerkomponenten (memory communications execution engines) 140. Jede Speicher-Datenübertragungs-Ausführungssteuerkomponente 140 ist in der Lage, Speicher-Datenübertragungsanweisungen von einem IP-Block 104 auszuführen, darunter der bidirektionale Speicher-Datenübertragungs-Anweisungsfluss 141, 142, 144 zwischen dem Netzwerk und dem IP-Block 104. Die von der Speicher-Datenübertragungs-Steuereinheit ausgeführten Speicher-Datenübertragungsanweisungen können nicht nur von dem IP-Block stammen, der über eine bestimmte Speicher-Datenübertragungs-Steuereinheit mit einem Router verbunden ist, sondern auch von jedem beliebigen IP-Block 104 irgendwo in dem NOC 102. Das heißt, jeder beliebige IP-Block in dem NOC kann eine Speicher-Datenübertragungsanweisung erzeugen und diese Speicher-Datenübertragungsanweisung über die Router des NOC an eine andere, einem anderen IP-Block zugehörige Speicher-Datenübertragungs-Steuereinheit übertragen, damit diese Speicher-Datenübertragungsanweisung ausgeführt wird. Zu derartigen Speicher-Datenübertragungsanweisungen können zum Beispiel Steueranweisungen für Adressumsetzpuffer (translation lookaside buffer), Steueranweisungen für Zwischenspeicher, Sperranweisungen sowie Lade- und Speicheranweisungen für einen Speicher gehören.
Jede Speicher-Datenübertragungs-Ausführungssteuerkomponente 140 ist in der Lage, eine vollständige Speicher-Datenübertragungsanweisung einzeln und parallel mit anderen Speicher-Datenübertragungs-Ausführungssteuerkomponenten durchzuführen. Die Speicher-Datenübertragungs-Ausführungssteuerkomponenten setzen einen skalierbaren Speichertransaktionsprozessor um, der für den gleichzeitigen Durchsatz von Speicher-Datenübertragungsanweisungen optimiert ist. Die Speicher-Datenübertragungs-Steuereinheit 106 unterstützt mehrere Speicher-Datenübertragungs-Ausführungssteuerkomponenten 140, die alle gleichzeitig laufen, um mehrere Speicher-Datenübertragungsanweisungen gleichzeitig auszuführen. Eine neue Speicher-Datenübertragungsanweisung wird von der Speicher-Datenübertragungs-Steuereinheit 106 einer Speicher-Datenübertragungs-Steuerkomponente 140 zugeordnet, und die Speicher-Datenübertragungs-Ausführungssteuerkomponente 140 kann mehrere Antwortereignisse gleichzeitig annehmen. In diesem Beispiel sind sämtliche Speicher-Datenübertragungs-Ausführungssteuerkomponenten 140 identisch. Deshalb wird ein Skalieren der Anzahl von Speicher-Datenübertragungsanweisungen, die durch eine Speicher-Datenübertragungs-Steuereinheit 106 gleichzeitig bewältigt werden können, durch Skalieren der Anzahl von Speicher-Datenübertragungs-Ausführungssteuerkomponenten 140 umgesetzt.
In dem NOC 102 aus 3 ist jede Netzwerkschnittstellen-Steuereinheit 108 in der Lage, Datenübertragungsanweisungen von Befehlsformat in Netzwerkpaketformat zur Übertragung zwischen den IP-Blöcken 104 über die Router 110 umzuwandeln. Die Datenübertragungsanweisungen können von dem IP-Block 104 oder der Speicher-Datenübertragungs-Steuereinheit 106 in Befehlsformat formuliert und der Netzwerkschnittstellen-Steuereinheit 108 in Befehlsformat bereitgestellt werden. Bei dem Befehlsformat kann es sich um ein natives Format handeln, das Architektur-Register-Dateien des IP-Blocks 104 und der Speicher-Datenübertragungs-Steuereinheit 106 entspricht. Bei dem Netzwerkpaketformat handelt es sich üblicherweise um das Format, das für das Übertragen über die Router 110 des Netzwerks benötigt wird. Jede derartige Nachricht besteht aus einem oder mehreren Netzwerkpaketen. Zu Beispielen für derartige Datenübertragungsanweisungen, die in der Netzwerkschnittstellen-Steuereinheit von Befehlsformat in Paketformat umgewandelt werden, gehören Ladeanweisungen für einen Speicher und Speicheranweisungen für einen Speicher zwischen IP-Blöcken und Speicher. Derartige Datenübertragungsanweisungen können auch Datenübertragungsanweisungen enthalten, die Nachrichten zwischen IP-Blöcken senden, die Daten und Anweisungen zum Verarbeiten der Daten zwischen IP-Blöcken in parallelen Anwendungen und in Pipeline-Anwendungen tragen.
In dem NOC 102 aus 3 ist jeder IP-Block in der Lage, auf Speicheradressen beruhende Datenübertragungen zu und von dem Speicher durch die Speicher-Datenübertragungs-Steuereinheit des IP-Blocks und dann auch durch dessen Netzwerkschnittstellen-Steuereinheit an das Netzwerk zu senden. Bei einer auf Speicheradressen beruhenden Datenübertragung handelt es sich um eine Speicherzugriffsanweisung wie eine Ladeanweisung oder eine Speicheranweisung, die von einer Speicher-Datenübertragungs-Ausführungssteuerkomponente einer Speicher-Datenübertragungs-Steuereinheit eines IP-Blocks ausgeführt wird.
Derartige auf Speicheradressen beruhende Datenübertragungen stammen ursprünglich von einem IP-Block, sind in Befehlsformat formuliert und werden an eine Speicher-Datenübertragungs-Steuereinheit zur Ausführung übergeben.
Viele auf Speicheradressen beruhende Datenübertragungen werden mit Nachrichtenverkehr ausgeführt, da sich jeder beliebige Speicher, auf den zuzugreifen ist, irgendwo in dem physischen Speicheradressraum befinden kann, chipintegriert oder chipextern, direkt mit einer beliebigen Speicher-Datenübertragungs-Steuereinheit in dem NOC verbunden, oder auf den letztendlich von jedem beliebigen IP-Block des NOC zugegriffen werden kann - unabhängig davon, von welchem IP-Block irgendeine bestimmte auf Speicheradressen beruhende Datenübertragung stammt. Somit werden in dem NOC 102 sämtliche auf Speicheradressen beruhenden Datenübertragungen, die mit Nachrichtenverkehr ausgeführt werden, von der Speicher-Datenübertragungs-Steuereinheit an eine zugehörige Netzwerkschnittstellen-Steuereinheit zum Umwandeln von Befehlsformat in Paketformat und zum Senden über das Netzwerk in einer Nachricht weitergeleitet. Beim Umwandeln in Paketformat identifiziert die Netzwerkschnittstellen-Steuereinheit ebenfalls eine Netzwerkadresse für das Paket in Abhängigkeit von der Speicheradresse bzw. den Speicheradressen, auf die von einer auf Speicheradressen beruhenden Datenübertragung zugegriffen werden soll. Auf Speicheradressen beruhende Nachrichten werden mit Speicheradressen aufgerufen. Jede Speicheradresse wird von den Netzwerkschnittstellen-Steuereinheiten auf eine Netzwerkadresse abgebildet, üblicherweise die Netzwerkposition einer Speicher-Datenübertragungs-Steuereinheit, die für einen gewissen Bereich von physischen Speicheradressen zuständig ist. Bei der Netzwerkposition einer Speicher-Datenübertragungs-Steuereinheit 106 handelt es sich natürlich auch um die Netzwerkposition des dieser Speicher-Datenübertragungs-Steuereinheit zugehörigen Routers 110, der Netzwerkschnittstellen-Steuereinheit 108 und des IP-Blocks 104. Die Anweisungsumwandlungslogik 150 innerhalb jeder Netzwerkschnittstellen-Steuereinheit ist in der Lage, Speicheradressen in Netzwerkadressen umzuwandeln, um auf Speicheradressen beruhende Datenübertragungen über die Router eines NOC zu übertragen.
Beim Empfangen von Nachrichtenverkehr von den Routern 110 des Netzwerks untersucht jede Netzwerkschnittstellen-Steuereinheit 108 jedes Paket auf Speicheranweisungen. Jedes eine Speicheranweisung enthaltende Paket wird an die der empfangenden Netzwerkschnittstellen-Steuereinheit zugehörige Speicher-Datenübertragungs-Steuereinheit 106 übergeben, welche die Speicheranweisung ausführt, bevor die restlichen Nutzdaten des Pakets an den IP-Block zur weiteren Verarbeitung gesendet werden. Auf diese Weise sind Speicherinhalte immer darauf vorbereitet, die Datenverarbeitung durch einen IP-Block zu unterstützen, bevor der IP-Block mit dem Ausführen der Anweisungen aus einer von einem bestimmten Speicherinhalt abhängenden Nachricht beginnt.
In dem NOC 102 aus 3 ist jeder IP-Block 104 in der Lage, seine Speicher-Datenübertragungs-Steuereinheit 106 zu umgehen und die IP-Block-übergreifenden, netzwerkadressierten Datenübertragungen 146 über die Netzwerkschnittstellen-Steuereinheit 108 des IP-Blocks direkt an das Netzwerk zu senden. Bei netzwerkadressierten Datenübertragungen handelt es sich um Nachrichten, die von einer Netzwerkadresse an einen anderen IP-Block geleitet werden. Derartige Nachrichten übertragen Arbeitsdaten in Pipeline-Anwendungen, mehrere Daten zur Einzelprogrammverarbeitung zwischen IP-Blöcken in einer SIMD-Anwendung usw., wie einem Fachmann klar sein wird. Derartige Nachrichten unterscheiden sich von auf Speicheradressen beruhenden Datenübertragungen dadurch, dass sie von Anfang an von dem Ursprungs-IP-Block netzwerkadressiert sind, der die Netzwerkadresse kennt, an welche die Nachricht über Router des NOC zu leiten ist. Derartige netzwerkadressierte Datenübertragungen werden von dem IP-Block in Befehlsformat über die E/A-Funktionen 136 direkt an die Netzwerkschnittstellen-Steuereinheit des IP-Blocks weitergeleitet, dann durch die Netzwerkschnittstellen-Steuereinheit in Paketformat umgewandelt und über Router des NOC an einen anderen IP-Block übertragen. Derartige netzwerkadressierte Datenübertragungen 146 sind bidirektional, wobei sie in Abhängigkeit ihrer Verwendung in einer beliebigen bestimmten Anwendung möglicherweise zu und von jedem IP-Block des NOC vorrücken. Jede Netzwerkschnittstellen-Steuereinheit ist jedoch in der Lage, derartige Datenübertragungen an einen und von einem zugehörigen Router sowohl zu senden als auch zu empfangen, und jede Netzwerkschnittstellen-Steuereinheit ist in der Lage, derartige Datenübertragungen sowohl direkt an einen zugehörigen IP-Block zu senden als auch direkt von diesem zu empfangen und dadurch eine zugehörige Speicher-Datenübertragungs-Steuereinheit 106 zu umgehen.
Jede Netzwerkschnittstellen-Steuereinheit 108 in dem Beispiel aus 3 ist ebenfalls in der Lage, virtuelle Kanäle in dem Netzwerk umzusetzen und Netzwerkpakete nach Typ zu kennzeichnen. Jede Netzwerkschnittstellen-Steuereinheit 108 enthält die virtuelle Kanalumsetzungslogik 148, die jede Datenübertragungsanweisung nach Typ einordnet und den Typ der Anweisung in einem Feld des Netzwerkpaketformats einträgt, bevor die Anweisung in Paketform an einen Router 110 zum Übertragen an das NOC übergeben wird. Zu Beispielen von Datenübertragungs-Anweisungstypen gehören IP-Block-übergreifende, auf Netzwerkadressen beruhende Nachrichten, Anforderungsnachrichten, Antworten auf Anforderungsnachrichten, Annullieren von an Cachespeicher gerichtete Nachrichten; Lade- und Speichernachrichten für Speicher; sowie Antworten auf Speicherladenachrichten usw.
Jeder Router 110 in dem Beispiel aus 3 enthält die Weiterleitungslogik 152, die virtuelle Kanalsteuerungslogik 154 sowie die virtuellen Kanalpuffer 156. Die Weiterleitungslogik ist üblicherweise als Netzwerk von synchroner und asynchroner Logik umgesetzt, die einen Datenübertragungsprotokoll-Stapel zur Datenübertragung in dem Netzwerk umsetzt, der durch die Router 110, die Verbindungen 118 und die Busdrähte zwischen den Routern gebildet wird. Die Weiterleitungslogik 152 enthält die Funktionalität, die ein Fachmann mit Routing-Tabellen in chipexternen Netzwerken in Verbindung bringen kann, wobei Routing-Tabellen zumindest in einigen Ausführungsformen für zu langsam und hinderlich zur Verwendung in einem NOC erachtet werden. Eine als Netzwerk von synchroner und asynchroner Logik umgesetzte Weiterleitungslogik kann so konfiguriert sein, dass sie Routing-Entscheidungen sogar in nur einem einzelnen Taktzyklus trifft. Die Weiterleitungslogik in diesem Beispiel leitet Pakete weiter, indem sie einen Anschluss zum Weiterleiten jedes in einem Router empfangenen Pakets auswählt. Jedes Paket enthält eine Netzwerkadresse, an die das Paket zu leiten ist.
In der obigen Beschreibung von auf Speicheradressen beruhenden Datenübertragungen wurde jede Speicheradresse so beschrieben, dass sie durch Netzwerkschnittstellen-Steuereinheiten auf eine Netzwerkadresse, eine Netzwerkposition einer Speicher-Datenübertragungs-Steuereinheit, abgebildet werden. Bei der Netzwerkposition einer Speicher-Datenübertragungs-Steuereinheit 106 handelt es sich natürlich auch um die Netzwerkposition des dieser Speicher-Datenübertragungs-Steuereinheit zugehörigen Routers 110, der Netzwerkschnittstellen-Steuereinheit 108 und des IP-Blocks 104. Bei IP-Block-übergreifenden bzw. auf Speicheradressen beruhenden Datenübertragungen ist es daher auch üblich, dass die Datenverarbeitung auf Anwendungsebene Netzwerkadressen als die Position eines IP-Blocks innerhalb des durch die Router, die Verbindungen sowie die Busdrähte des NOC gebildeten Netzwerks ansehen. 2 veranschaulicht, dass eine Organisation eines derartigen Netzwerks ein Netz (mesh) aus Reihen und Spalten darstellt, in dem jede Netzwerkadresse zum Beispiel entweder als eine eindeutige Kennung für jeden Satz aus zugehörigem Router, zugehörigem IP-Block, zugehöriger Speicher-Datenübertragungs-Steuereinheit sowie zugehöriger Netzwerkschnittstellen-Steuereinheit des Netzes oder als X-, Y-Koordinaten jedes derartigen Satzes in dem Netz umgesetzt werden kann.
In dem NOC 102 aus 3 setzt jeder Router 110 zwei oder mehr virtuelle Datenübertragungskanäle um, wobei jeder virtuelle Datenübertragungskanal durch einen Datenübertragungstyp gekennzeichnet ist. Zu Datenübertragungs-Anweisungstypen und somit zu virtuellen Kanaltypen gehören die oben erwähnten: IP-Block-übergreifende, auf Netzwerkadresse beruhende Nachrichten, Anforderungsnachrichten, Antworten auf Anforderungsnachrichten, Annullieren von an Cachespeicher gerichtete Nachrichten; Lade- und Speichernachrichten für Speicher; sowie Antworten auf Speicherladenachrichten usw. Zur Unterstützung von virtuellen Kanälen enthält jeder Router 110 in dem Beispiel aus 3 auch die virtuelle Kanalsteuerungslogik 154 sowie die virtuellen Kanalpuffer 156. Die virtuelle Kanalsteuerungslogik 154 untersucht jedes empfangene Paket auf dessen zugehörigen Datenübertragungstyp und platziert jedes Paket in einen abgehenden virtuellen Kanalpuffer für diesen Datenübertragungstyp zum Übertragen an einen benachbarten Router in dem NOC über einen Anschluss.
Jeder virtuelle Kanalpuffer 156 weist einen endlichen Speicherplatz auf. Beim Empfangen von vielen Paketen in einer kurzen Zeitspanne kann sich ein virtueller Kanalpuffer füllen - so dass keine weiteren Pakete mehr in dem Puffer platziert werden können. In anderen Protokollen würden Pakete verworfen, die auf einem virtuellen Kanal ankommen, dessen Puffer voll ist. Jeder virtuelle Kanalpuffer 156 in diesem Beispiel ist jedoch durch Steuersignale der Busdrähte in der Lage, über die virtuelle Kanalsteuerlogik umliegende Router anzuweisen, das Übertragen auf einem virtuellen Kanal zu unterbrechen, d.h., das Übertragen von Paketen eines bestimmten Datenübertragungstyps zu unterbrechen. Wenn ein virtueller Kanal derart unterbrochen wird, bleiben sämtliche anderen virtuellen Kanäle davon unbeeinflusst - und können weiterhin mit voller Kapazität arbeiten. Die Steuersignale sind über jeden Router bis hin zu der jedem Router zugehörigen Netzwerkschnittstellen-Steuereinheit 108 verbunden. Jede Netzwerkschnittstellen-Steuereinheit ist so konfiguriert, dass sie beim Empfangen eines derartigen Signals von ihrer zugehörigen Speicher-Datenübertragungs-Steuereinheit 106 bzw. von ihrem zugehörigen IP-Block 104 die Annahme von Datenübertragungsanweisungen für den unterbrochenen virtuellen Kanal verweigern kann. Auf diese Weise beeinträchtigt eine Unterbrechung eines virtuellen Kanals die gesamte Hardware, die den virtuellen Kanal umsetzt, bis hin zu den Ursprungs-IP-Blöcken.
Eine Auswirkung des Unterbrechens von Paketübertragungen in einem virtuellen Kanal besteht darin, dass keine Pakete jemals verworfen werden. Wenn ein Router auf eine Situation trifft, in der ein Paket in irgendeinem unzuverlässigen Protokoll wie dem Internet-Protokoll möglicherweise verworfen werden würde, können die Router in dem Beispiel aus 3 über ihre virtuellen Kanalpuffer 156 und ihre virtuelle Kanalsteuerlogik 154 sämtliche Übertragungen von Paketen auf einem virtuellen Kanal so lange unterbrechen, bis wieder Platz im Puffer zur Verfügung steht, wodurch die Notwendigkeit des Verwerfens von Paketen beseitigt wird. Das NOC aus 3 kann deshalb hoch zuverlässige Netzwerk-Datenübertragungsprotokolle mit einer äußerst dünnen Hardware-Schicht umsetzen.
Das beispielhafte NOC aus 3 kann auch so konfiguriert sein, dass es die Cachespeicher-Kohärenz zwischen Cachespeichern von sowohl chipintegrierten als auch chipexternen Speichern aufrechterhält. Jedes NOC kann mehrere Cachespeicher unterstützen, die jeweils in Abhängigkeit von demselben zu Grunde liegenden Speicheradressraum funktionieren. Cachespeicher können zum Beispiel durch IP-Blöcke, durch Speicher-Datenübertragungs-Steuereinheiten bzw. durch Cachespeicher-Steuereinheiten außerhalb des NOC gesteuert werden. Jeder der chipintegrierten Speicher 114, 116 in dem Beispiel aus 2 kann auch als chipintegrierter Cachespeicher umgesetzt werden, und im Rahmen der vorliegenden Erfindung kann Cachespeicher auch chipextern umgesetzt werden.
Jeder in 3 veranschaulichte Router 110 enthält fünf Anschlüsse, die vier Anschlüsse 158A bis D, die über die Busdrähte 118 mit anderen Routern verbunden sind, und einen fünften Anschluss 160, der jeden Router über eine Netzwerkschnittstellen-Steuereinheit 108 und eine Speicher-Datenübertragungs-Steuereinheit 106 mit dessen zugehörigem IP-Block 104 verbindet. Wie aus den Veranschaulichungen in den 2 und 3 ersichtlich ist, bilden die Router 110 und die Verbindungen 118 des NOC 102 ein Netzwerk (mesh network) mit vertikalen und horizontalen Verbindungen, die vertikale und horizontale Anschlüsse in jedem Router verbinden. In der Veranschaulichung aus 3 sind die Anschlüsse 158A, 158C und 160 als vertikale Anschlüsse benannt, und die Anschlüsse 158B und 158D sind als horizontale Anschlüsse benannt.
Als nächstes veranschaulicht 4 auf eine andere Weise eine beispielhafte Ausführung eines IP-Blocks 104 in Übereinstimmung mit der Erfindung, umgesetzt als ein Verarbeitungselement, das in eine Anweisungseinheit (IU) 162, eine Ausführungseinheit (XU) 164 und eine Hilfsausführungseinheit (AXU) 166 aufgeteilt ist. In der veranschaulichten Ausführung enthält die IU 162 eine Vielzahl von Anweisungspuffern 168, die Anweisungen von einem L1-Anweisungs-Cachespeicher (iCACHE) 170 empfangen. Jeder Anweisungspuffer 168 ist speziell für einen aus einer Vielzahl, z.B. vier, symmetrischer Multithread- (SMT-) Hardware-Threads vorgesehen. Eine Effektiv-Real-Übersetzungseinheit (iERAT) 172 ist mit dem iCACHE 170 verbunden und wird dazu verwendet, Anweisungsabrufanforderungen von einer Vielzahl von Thread-Abruf-Sequencern 174 in reale Adressen zu übersetzen, um Anweisungen aus Speicher niedrigerer Ordnung abzurufen. Jeder Thread-Abruf-Sequencer 174 ist speziell für einen bestimmten Hardware-Thread vorgesehen und wird dazu verwendet sicherzustellen, dass durch den zugehörigen Thread auszuführende Anweisungen in den iCACHE abgerufen werden, um sie an die entsprechende Ausführungseinheit zu senden. Wie ebenfalls in 4 gezeigt ist, können in den Anweisungspuffer 168 abgerufene Anweisungen ebenfalls durch die Verzweigungsvorhersagelogik 176 überwacht werden, die jedem Thread-Abruf-Sequencer 174 Hinweise gibt, um sich nicht im Cachespeicher befindliche Anweisungen (instruction cache misses), die sich aus Verzweigungen in ausführenden Threads ergeben, zu minimieren.
Die IU 162 enthält ebenfalls einen Abhängigkeits/Ausgabe-Logikblock 178, der speziell für jeden Hardware-Thread vorgesehen und so konfiguriert ist, dass er Abhängigkeiten auflöst und die Ausgabe von Anweisungen aus dem Anweisungspuffer 168 an die XU 164 steuert. Außerdem wird in der veranschaulichten Ausführungsform in der AXU 166 eine separate Abhängigkeits/Ausgabe-Logik 180 bereitgestellt, wodurch es ermöglicht wird, separate Anweisungen durch verschiedene Threads gleichzeitig an die XU 164 und die AXU 166 auszugeben. In einer alternativen Ausführungsform kann sich die Logik 180 in der IU 162 befinden oder vollständig weggelassen werden, so dass die Logik 178 Anweisungen an die AXU 166 ausgibt.
Die XU 164 ist als eine Festkomma-Ausführungseinheit umgesetzt und enthält eine Reihe von Universalregistern (GPRs, general purpose registers) 182, die mit der Festkommalogik 184, der Verzweigungslogik 186 und der Lade/Speicher-Logik 188 verbunden sind. Die Lade/Speicher-Logik 188 ist mit einem L1-Datencachespeicher (dCACHE) 190 verbunden, wobei eine Effektiv-Real-Übersetzung durch die dERAT-Logik 192 bereitgestellt wird. Die XU 164 kann so konfiguriert sein, dass sie praktisch jede Reihe von Anweisungen ausführen kann, z.B. alle oder einen Teil einer Reihe von 32b- bzw. 64b-PowerPC-Anweisungen.
Die AXU 166 fungiert als Hilfsausführungseinheit, welche die speziell vorgesehene Abhängigkeits/Ausgabe-Logik 180 gemeinsam mit einem oder mehreren Ausführungsblöcken 194 enthält. Die AXU 166 kann jede beliebige Anzahl von Ausführungsblöcken enthalten und praktisch jede beliebige Art von Ausführungseinheit umsetzen, z.B. eine Gleitkommaeinheit oder eine oder mehrere spezialisierte Ausführungseinheiten wie Verschlüsselungs/Entschlüsselungs-Einheiten, Coprozessoren, Vektorverarbeitungseinheiten, Grafikverarbeitungseinheiten, XML-Verarbeitungseinheiten usw. In der veranschaulichten Ausführungsform enthält die AXU 166 eine Hochgeschwindigkeits-Hilfsschnittstelle mit der XU 164, z.B. um direkte Verschiebungen zwischen AXU-zweckgestaltetem Zustand und XUzweckgestaltetem Zustand zu unterstützen.
Der Datenaustausch mit dem IP-Block 104 kann auf die oben in Zusammenhang mit 2 erörterte Weise über eine mit dem NOC 102 verbundene Netzwerkschnittstellen-Steuereinheit 108 verwaltet werden. Auf Adressen beruhende Datenübertragung, z.B. zum Zugreifen auf L2-Cachespeicher, kann gemeinsam mit auf Nachrichten beruhender Datenübertragung bereitgestellt werden. Jeder IP-Block 104 kann zum Beispiel einen speziell vorgesehenen Eingang und/oder Ausgang enthalten, um knotenübergreifende Datenübertragungen zwischen IP-Blöcken zu bewältigen.
Ausführungsformen der vorliegenden Erfindung können in der in Zusammenhang mit den 1 bis 4 oben beschriebenen Hardware- und Software-Umgebung umgesetzt werden. Mit Unterstützung der vorliegenden Darlegung wird ein Fachmann jedoch verstehen, dass die Erfindung in einer Vielzahl von verschiedenen Umgebungen umgesetzt werden kann, und dass andere Abwandlungen an der oben erwähnten Hardware- und Software-Ausführungsform vorgenommen werden können, ohne von dem Gedanken und dem Umfang der Erfindung abzuweichen. Als solche ist die Erfindung nicht auf die bestimmte hierin dargelegte Hardware- und Software-Umgebung beschränkt.
SOFTWARE-PIPELINING
Wenden wir uns nun 5 zu, in der das NOC 102 in einigen Ausführungsformen zum Umsetzen einer auf Software beruhenden Pipeline verwendet werden kann. Insbesondere veranschaulicht 5 eine beispielhafte Verarbeitungseinheit 200, die eine Thread-Pipeline-Software-Steuerkomponente 202 enthält, die zum Umsetzen und Ausführen einer oder mehrerer Software-Pipelines 204 auf einer NOC-Architektur verwendet werden kann. Jede Pipeline 204 ist üblicherweise einer oder mehreren Datenstrukturen 206 in einem gemeinsam genutzten Speicher 208 zugeordnet, um verschiedene Stufen einer Pipeline zum Austauschen von Daten zu ermöglichen. Des Weiteren wird ein Unterbrechungsmechanismus 210 bereitgestellt, um es Stufen einer Pipeline zu ermöglichen, sich gegenseitig über anstehende durchzuführende Aufgaben zu benachrichtigen.
In der Steuerkomponente 202 werden auch ein oder mehrere Host-Schnittstellen-Prozessoren (HIPs, host interface processors) 212 bereitgestellt, um die Ausgabe von Aufgaben an die Software-Pipelines 204 zu bewältigen. Es werden ein oder mehrere Aussendepuffer (push buffer) 214 bereitgestellt, damit jeder HIP 212 eine Schnittstelle zu einer Software-Anwendung 216 und dem Treiber 218 aufweist, die sich außerhalb der Steuerkomponente befinden. Zum Einleiten einer Aufgabe in einer Pipeline gibt eine Software-Anwendung 216 über einen entsprechenden Treiber 218 Anforderungen in Form von API-Aufrufen aus, woraufhin entsprechende Anforderungen für den HIP erzeugt und die Anforderungen in einem Aussendepuffer 214 gespeichert werden. Der HIP 212 für die entsprechende Pipeline ruft Aufgabenanforderungen aus dem Aussendepuffer 214 ab und leitet das Verarbeiten der Anforderung durch die zugehörige Pipeline ein.
In der veranschaulichten Ausführungsform und wie in einem NOC 102 umgesetzt führt eine Software-Pipeline 204 eine Funktion aus, die in eine Reihe von Modulen bzw. ,Stufen' von Computerprogrammanweisungen eingeteilt ist, die miteinander zusammenarbeiten, um eine Reihe von Datenverarbeitungsaufgaben der Reihe nach auszuführen. Jede Stufe in einer Pipeline besteht aus einem flexibel konfigurierbaren Modul mit Computerprogrammanweisungen, das für jede auf einem Ausführungs-Thread in einem IP-Block 104 eines NOC 102 ausgeführte Stufe durch eine Stufenkennung identifiziert wird. Die Stufen sind dahingehend flexibel konfigurierbar, dass jede Stufe mehrere Instanzen der Stufe unterstützen kann, so dass eine Pipeline skaliert werden kann, indem zusätzliche Instanzen einer Stufe instanziiert werden, wie in Abhängigkeit von der Arbeitslast benötigt wird. Da jede Stufe durch in einem IP-Block 104 eines NOC 102 ausgeführte Computerprogrammanweisungen umgesetzt wird, ist jede Stufe in der Lage, über eine Speicher-Datenübertragungs-Steuereinheit 106 auf aufgerufenen Speicher zuzugreifen. Außerdem ist mindestens eine Stufe in der Lage, auf Netzwerkadressen beruhende Datenübertragungen zwischen anderen Stufen zu senden, wobei die auf Netzwerkadressen beruhenden Datenübertragungen die Paketreihenfolge beibehalten.
Die auf Netzwerkadressen beruhenden Datenübertragungen können zum Beispiel unter Verwendung von „Eingängen“ in jeder Stufe umgesetzt werden, die Daten und/oder Befehle von vorausgehenden Stufen in der Pipeline empfangen. Die auf Netzwerkadressen beruhenden Datenübertragungen behalten die Paketreihenfolge bei, und es handelt sich bei ihnen um Datenübertragungen derselben Art, die in der Lage sind, durch denselben virtuellen Kanal wie oben beschrieben zu fließen. Jedes Paket in derartigen Datenübertragungen wird auf die oben beschriebene Weise durch einen Router 110 weitergeleitet, wobei es der Reihe nach in einen virtuellen Kanalpuffer eintritt und diesen in FIFO-Reihenfolge verlässt, wodurch die Paketreihenfolge strikt eingehalten und die Unversehrtheit der Nachrichten geschützt wird.
Jede Stufe setzt eine Produzenten/Konsumenten-Beziehung mit einer nächsten Stufe um. Die erste Stufe empfängt Arbeitsanweisungen und Arbeitsstückdaten (work piece data) über einen HIP 212, führt ihre vorgesehenen Datenverarbeitungsaufgaben an dem Arbeitsstück durch, erzeugt Ausgabedaten und sendet die erzeugten Ausgabedaten an die nächste Stufe in der Pipeline, welche die erzeugten Ausgabedaten von der ersten Stufe durch Ausführen ihrer vorgesehenen Datenverarbeitungsaufgaben an den erzeugten Ausgabedaten von der ersten Stufe konsumiert, wodurch Ausgabedaten erzeugt werden, die anschließend an eine nächste Stufe in der Pipeline gesendet werden. Diese Folge von Arbeitsschritten wird bis zur letzten Stufe der Pipeline fortgeführt, die dann ihre erzeugten Ausgabedaten in einer Ausgabedatenstruktur speichert, damit sie letztendlich über den HIP 212 an die Ursprungsanwendung 216 zurückgesendet werden.
Die Anordnung von Stufen in einer Pipeline kann in verschiedenen Ausführungsformen sowie zum Durchführen verschiedener Funktionen in verschiedenen Anwendungen variieren. 6 veranschaulicht zum Beispiel eine beispielhafte Software-Pipeline 220, die eine Vielzahl von Stufeninstanzen 222 enthält, ebenfalls separat als Instanzen A bis I gekennzeichnet, von denen jede einen in einem IP-Block in dem NOC 102 ausgeführten Ausführungs-Thread darstellt. Die Stufeninstanzen 222 sind in der Pipeline 220 in fünf Stufen angeordnet, einer ersten Stufe mit der Instanz A, einer zweiten Stufe mit den Instanzen B und C, einer dritten Stufe mit den Instanzen D, E und F, einer vierten Stufe mit den Instanzen G und H und einer fünften Stufe mit der Instanz I. Wie aus 6 ersichtlich ist, können Instanzen eine eins-zu-eins, eine eins-zu-vielen und/oder eine viele-zu-eins Beziehung mit anderen Instanzen in der Pipeline haben. Instanzen können in einer bestimmten Stufe gemeinsam miteinander arbeiten, um parallele Aufgaben auszuführen und die Arbeitslast zu teilen, wodurch der Gesamtdurchsatz der Stufe beim Durchführen der Aufgabe verbessert wird. Instanzen in einer Stufe können auch voneinander unterschiedliche Aufgaben durchführen, um das parallele Durchführen verschiedener Aufgaben zu ermöglichen. Instanzen können Daten an mehr als eine Instanz liefern, während andere Instanzen von mehreren Instanzen Daten sammeln und Daten verarbeiten können.
In der veranschaulichten Ausführungsform ist jede Instanz jeder Stufe einer Pipeline üblicherweise als ein Modul auf Anwendungsebene von in einem separaten IP-Block in einem NOC ausgeführten Computerprogrammanweisungen umgesetzt, und jede Stufe ist einem Ausführungs-Thread in einem IP-Block eines NOC zugewiesen. Jeder Stufe ist eine Stufenkennung zugewiesen, und jeder Instanz einer Stufe ist eine Kennung zugewiesen. Der HIP 212 (5) baut die Pipeline üblicherweise durch Konfigurieren jeder Stufe mit einer gewünschten Anzahl von Instanzen auf, wobei die Netzwerkposition jeder Instanz jeder Stufe anderen Instanzen anderer Stufen mitgeteilt wird, um es jeder Instanz zu ermöglichen, ihre sich ergebende Arbeitslast an die richtige Instanz in der nächsten Stufe zu senden, frühere und/oder spätere Stufe 3, für die eine Instanz von Stufe 2 berechtigt ist, ihre sich ergebende Arbeitslast zu senden. Mehrere Instanzen können einer bestimmten Stufe zugewiesen werden, um zusätzliche Verarbeitungsressourcen bezogen auf andere Stufen bereitzustellen, z.B. damit Aufgaben so effizient wie möglich durch die Pipeline fließen und keine einzelne Stufe einen Leistungsengpass darstellt. Man wird auch verstehen, dass ein Überwachen der Arbeitslast während der Laufzeit durchgeführt werden kann, und dass Instanzen dynamisch einer Stufe hinzugefügt oder davon entfernt werden können, wie zum Ausgleichen der Last unter den Stufen der Pipeline benötigt wird.
Jede Stufe ist mit einer Stufenkennung für jede Instanz einer nächsten Stufe konfiguriert, die auch die Anzahl von Instanzen in der nächsten Stufe sowie die Netzwerkposition jeder Instanz davon enthalten kann. Durch das Konfigurieren einer Stufe mit Kennungen für Instanzen einer nächsten Stufe werden der Stufe die Informationen bereitgestellt, die zum Ausführen eines Lastenausgleichs zwischen Stufen benötigt werden. Ein derartiger Lastenausgleich kann zum Beispiel durch Überwachen der Leistungsfähigkeit der Stufen und Instanziieren mehrerer Instanzen jeder Stufe in Abhängigkeit von der Leistungsfähigkeit einer oder mehrerer Stufen ausgeführt werden. Das Überwachen der Leistungsfähigkeit der Stufen kann ausgeführt werden, indem jede Stufe so konfiguriert wird, dass sie Leistungsfähigkeitsstatistiken an eine separate Überwachungsanwendung berichtet, die wiederum in einem anderen Ausführungs-Thread in einem IP-Block oder einem HIP läuft. Leistungsfähigkeitsstatistiken können zum Beispiel die zum Ausführen einer Datenverarbeitungsaufgabe benötigte Zeit, eine Anzahl von in einer bestimmten Zeitspanne ausgeführten Datenverarbeitungsaufgaben usw. enthalten, wie einem Fachmann klar sein wird. Das Instanziieren mehrerer Instanzen jeder Stufe in Abhängigkeit von der Leistungsfähigkeit einer oder mehrerer der Stufen kann dadurch ausgeführt werden, dass ein HIP eine neue Instanz einer Stufe instanziiert, wenn die überwachte Leistungsfähigkeit auf den Bedarf für eine neue Instanz hindeutet.
PIPELINE-WIEDERGABE-ARCHITEKTUR
Wenden wir uns nun 7 zu, die eine Umsetzung einer Verarbeitungseinheit 200 veranschaulicht, die so konfiguriert ist, dass sie eine Pipeline-Wiedergabe-Architektur umsetzt, die in Verbindung mit einer Physik-Engine in Übereinstimmung mit der Erfindung verwendet werden kann. Insbesondere veranschaulicht 7 eine Hybrid-Wiedergabe-Software-Pipeline 230, die ein im Datenstrom übertragendes Geometrie-Front-End 232 enthält, das über einen GIR-Erzeuger 236 mit einem Back-End zum punktweisen Betrachten 234 verbunden ist. Das im Datenstrom übertragende Geometrie-Front-End 232 kann zum Beispiel als OpenGL- oder DirectX-kompatibles Front-End umgesetzt sein, wie es z.B. in mehreren verschiedenen auf Rastern beruhenden Techniken verwendet wird, das eine Reihe von Basiselementen für eine Szene im Datenstrom überträgt. Das Front-End 232 kann die OpenGL- oder DirectX-APIs auch nativ unterstützen, und als solches kann eine Anwendung 216 darauf zugreifen, die zur Verwendung mit einem auf Rastern beruhenden Wiedergabealgorithmus über API-Aufrufe entwickelt wurde, die von dem Treiber 218 in Aufgabenanforderungen umgewandelt werden, die über den Aussendepuffer 214 an den HIP 212 gesendet werden, um das Umsetzen dieser API-Aufrufe durch das Front-End 232 einzuleiten.
Der GIR-Erzeuger 236 wiederum verarbeitet den Strom von durch das im Datenstrom übertragende Geometrie-Front-End 232 ausgegebenen Basiselementen und erzeugt und speichert eine Datenstruktur mit geometrie-interner Darstellung (GIR, geometry internal representation) 238 in dem Speicher 208. Die GIR 238 dient als beschleunigte Datenstruktur (ADS, accelerated data structure) und wird als solche von dem Back-End zum punktweisen Betrachten 234 verwendet, um einen Rahmen mit Bilddaten für eine Szene an einen Rahmenpuffer 240 wiederzugeben. Der GIR-Erzeuger 236 erzeugt die GIR dynamisch unter Verwendung einer Vielzahl von parallelen Ausführungs-Threads bzw. Hardware-Threads und verringert als solches die Wahrscheinlichkeit, dass das Erzeugen der GIR als Engpass für die Gesamtleistungsfähigkeit dient. Falls gewünscht, wird es dem Back-End 234 außerdem gestattet, parallel mit dem die GIR dynamisch aufbauenden GIR-Erzeuger mit dem Zugreifen auf die GIR zu beginnen, bevor der GIR-Erzeuger die GIR abgeschlossen hat. Als Alternative kann das Back-End 234 keine Arbeitsschritte für die GIR ausführen, bis der Aufbau der GIR abgeschlossen wurde. Als weitere Alternative können das Front-End 232 und das Back-End 234 Arbeitsschritte für verschiedene Datenrahmen ausführen, so dass das Front-End 232 Basiselementdaten an den GIR-Erzeuger 236 im Datenstrom überträgt, um eine GIR für einen Rahmen aufzubauen, während das Back-End 234 die GIR für einen früher erzeugten Rahmen verarbeitet.
Mit einer derartigen Konfiguration sind das im Datenstrom übertragende Front-End 232, der GIR-Erzeuger 236 und das Back-End zum punktweisen Betrachten 234 jeweils für eine Ausführung durch eine Vielzahl von parallelen Ausführungs-Threads geeignet. Des Weiteren dient der GIR-Erzeuger 236 dazu, die Ausgabe eines normalerweise zur Verwendung mit einem auf Rastern basierenden Back-End konfigurierten, im Datenstrom übertragenden Geometrie-Front-End zur Verwendung mit einem physischen Wiedergabe-Back-End wie einem Back-End zum punktweisen Betrachten oder einem Photonen-Abbildungs-Back-End anzupassen. Als solche kann dasselbe API, das für eine auf Rastern beruhende Wiedergabetechnik verwendet würde, zum neuen Zweck der physischen Wiedergabe verwendet werden, häufig ohne dass Änderungen an der API oder an einer Anwendung, die Aufrufe an die API durchführt, erforderlich wären.
DYNAMISCHE ADS-ERZEUGUNG
Eine ADS kann dazu verwendet werden, einen physischen Wiedergabealgorithmus wie einen Algorithmus zum punktweisen Betrachten zu ermöglichen und wirksam festzustellen, in welchen Bereichen einer Szene ein ausgegebener Strahl irgendwelche Objekte innerhalb einer wiederzugebenden Szene schneidet. Eine ADS kann zum Beispiel als Raumindex umgesetzt werden, der eine dreidimensionale Szene bzw. Welt in kleinere dreidimensionale Raumbereiche (volumes) (kleiner im Vergleich zu der gesamten dreidimensionalen Szene) aufteilt, die Basiselemente enthalten können. Ein Bildverarbeitungssystem kann dann dafür verwendet werden, die bekannten Grenzen dieser kleineren dreidimensionalen Raumbereiche zu ermitteln, wenn ein Strahl Basiselemente schneidet, die in den kleineren dreidimensionalen Raumbereichen enthalten sind. Wenn ein Strahl einen Basiselemente enthaltenden dreidimensionalen Raumbereich schneidet, kann unter Verwendung der Bewegungsbahn des Strahls für die bekannte Position und die Abmessungen der in diesem dreidimensionalen Raumbereich enthaltenen Basiselemente eine Strahlüberschneidungsprüfung durchgeführt werden. Wenn ein Strahl keinen bestimmten dreidimensionalen Raumbereich überschneidet, ist es nicht erforderlich, eine Strahl-Basiselement-Überschneidungsprüfung für die in diesem dreidimensionalen Raumbereich enthaltenen Basiselemente durchzuführen. Des Weiteren ist es nicht erforderlich, Strahl-Basiselement-Überschneidungsprüfungen für einen keine Basiselemente enthaltenden begrenzenden dreidimensionalen Raumbereich durchzuführen, wenn ein Strahl diesen begrenzenden dreidimensionalen Raumbereich schneidet. Somit verbessert die Verwendung eines Raumindex die Leistungsfähigkeit eines Bildverarbeitungssystems zum punktweisen Betrachten durch Verringern der Anzahl von Strahl-Basiselement-Überschneidungsprüfungen. Zu einigen Beispielen für verschiedene Raumindex-Beschleunigungsdatenstrukturen gehören Octrees, k-dimensionale Bäume (kd-Trees) sowie binäre Raumaufteilungsbäume (BSP trees, binary space partitioning trees). Obwohl es mehrere verschiedene Raumindexstrukturen gibt und diese in Verbindung mit den hierin dargelegten physischen Wiedergabetechniken verwendet werden können, hängen die veranschaulichten Ausführungsformen von einem Verzweigungsbaum ab, der als Baum mit Basis b umgesetzt ist, der in kleinere Bäume mit Tiefe k aufgeteilt ist.
8 und 9 veranschaulichen beispielhaft eine relativ einfache Umsetzung eines Verzweigungsbaums, der an den Achsen ausgerichtete begrenzende dreidimensionale Raumbereiche verwendet, um die gesamte Szene bzw. den gesamten Raum in kleinere dreidimensionale Raumbereiche aufzuteilen. Das heißt, dass der Verzweigungsbaum einen eine Szene umfassenden dreidimensionalen Raum durch die Verwendung von teilenden Ebenen aufteilen kann, die parallel zu bekannten Achsen sind. Die teilenden Ebenen teilen einen größeren Raum in kleinere begrenzende dreidimensionale Raumbereiche auf. Gemeinsam ergeben die kleineren begrenzenden dreidimensionalen Raumbereiche den gesamten Raum in der Szene. Das Bestimmen des Aufteilens eines größeren begrenzenden dreidimensionalen Raumbereichs in zwei kleinere begrenzende dreidimensionale Raumbereiche kann von dem Bildverarbeitungssystem durch die Verwendung eines Verzweigungsbaum-Konstruktionsalgorithmus durchgeführt werden.
Ein Kriterium zum Bestimmen, wann ein begrenzender dreidimensionaler Raumbereich in kleinere dreidimensionale Raumbereiche aufzuteilen ist, kann die Anzahl von in dem begrenzenden dreidimensionalen Raumbereich enthaltenen Basiselementen darstellen. Das heißt, so lange ein begrenzender dreidimensionaler Raumbereich mehr Basiselemente als ein vorbestimmter Schwellwert enthält, kann der Baumkonstruktionsalgorithmus damit fortfahren, durch Zeichnen von weiteren teilenden Ebenen dreidimensionale Raumbereiche aufzuteilen. Ein weiteres Kriterium zum Bestimmen, wann ein begrenzender dreidimensionaler Raumbereich in kleinere dreidimensionale Raumbereiche aufzuteilen ist, kann die Größe des in dem begrenzenden dreidimensionalen Raumbereich enthaltenen Raums darstellen. Des Weiteren kann eine Entscheidung über das Fortführen des Aufteilens des begrenzenden dreidimensionalen Raumbereichs auch darauf beruhen, wie viele Basiselemente die Ebene schneiden darf, die den begrenzenden dreidimensionalen Raumbereich erzeugt.
Das Aufteilen der Szene kann zum Beispiel durch eine binäre Baumstruktur dargestellt werden, die aus Knoten, Zweigen und Blättern besteht. Jeder interne Knoten innerhalb des Baums kann einen relativ großen begrenzenden dreidimensionalen Raumbereich darstellen, während der Knoten Verzweigungen zu Unterknoten enthalten kann, die zwei relativ kleinere aufgeteilte dreidimensionale Raumbereiche darstellen können, die sich nach einer Aufteilung des relativ großen begrenzenden dreidimensionalen Raumbereichs durch eine teilende Ebene ergeben. In einem an den Achsen ausgerichteten Verzweigungsbaum kann jeder interne Knoten lediglich zwei Verzweigungen zu anderen Knoten enthalten. Der interne Knoten kann Verzweigungen (d.h., Verweise) zu einem oder zwei Blattknoten enthalten. Bei einem Blattknoten handelt es sich um einen Knoten, der nicht weiter in kleinere dreidimensionale Raumbereiche aufgeteilt ist und Verweise auf Basiselemente enthält. Ein interner Knoten kann auch Verzweigungen zu anderen internen Knoten enthalten, die weiter unterteilt sind. Ein interner Knoten kann auch die Informationen enthalten, die zum Feststellen benötigt werden, entlang welcher Achse die teilende Ebene gezeichnet wurde und wo entlang der Achse die teilende Ebene gezeichnet wurde.
8 veranschaulicht zum Beispiel einen beispielhaften zweidimensionalen Raum, der von einem Bildverarbeitungssystem wiederzugeben ist, während 9 einen entsprechenden Verzweigungsbaum 258 veranschaulicht, der die Knoten 260 bis 268 für die in 8 gezeigten Basiselemente umfasst. Der Einfachheit halber wird eine zweidimensionale Szene zum Veranschaulichen des Aufbaus eines Verzweigungsbaums veranschaulicht, wobei jedoch auch Verzweigungsbäume zum Darstellen von dreidimensionalen Szenen verwendet werden können. In der zweidimensionalen Veranschaulichung aus 8 werden zum Beispiel teilende Linien an Stelle von teilenden Ebenen dargestellt, und begrenzende Flächen werden an Stelle von begrenzenden dreidimensionalen Raumbereichen dargestellt, die in einer dreidimensionalen Struktur verwendet würden. Ein Fachmann wird jedoch schnell erkennen, dass die Konzepte einfach auf eine Objekte enthaltende dreidimensionale Szene angewendet werden kann.
8 veranschaulicht eine zweidimensionale Szene 250, welche die in dem Endbild wiederzugebenden Basiselemente 252A, 252B und 252C enthält. Der größte dreidimensionale Raumbereich, der den gesamten dreidimensionalen Raumbereich der Szene darstellt, wird durch den dreidimensionalen Raumbereich 1 (BV₁) umgeben (der in 8 nicht einzeln gezeigt ist, da er die gesamte Szene umfasst).
In dem entsprechenden Verzweigungsbaum kann dies durch den obersten Knoten 260 dargestellt werden, der auch Wurzel- bzw. Weltknoten genannt wird. In einer Ausführungsform kann ein Bildverarbeitungssystem das Aufteilen von begrenzenden dreidimensionalen Raumbereichen in kleinere begrenzende dreidimensionale Raumbereiche fortführen, wenn der begrenzende dreidimensionale Raumbereich zum Beispiel mehr als zwei Basiselemente enthält. Wie bereits erwähnt, kann die Entscheidung über das Fortführen des Aufteilens eines begrenzenden dreidimensionalen Raumbereichs in kleinere begrenzende dreidimensionale Raumbereiche auf vielen Faktoren beruhen, wobei die Entscheidung über das Fortführen des Aufteilens eines begrenzenden dreidimensionalen Raumbereichs in diesem Beispiel der einfacheren Erklärung halber jedoch lediglich auf der Anzahl von Basiselementen beruht.
Somit kann BV₁ zum Beispiel, wie aus 8 ersichtlich ist, in zwei kleinere begrenzende dreidimensionale Raumbereiche BV₂ bzw. BV₃ aufgeteilt werden, indem eine teilende Ebene 254 entlang der X-Achse an Punkt X₁ gezeichnet wird. Dieses Aufteilen von BV₁ wird auch in dem Verzweigungsbaum durch die beiden BV₂ bzw. BV₃ entsprechenden Knoten 262 bzw. 264 unter dem internen bzw. Eltern-Knoten BV₁ 260 widergespiegelt. Der BV₁ entsprechende interne Knoten kann nun Daten wie zum Beispiel Verweise auf die beiden Knoten unterhalb von BV₁ (z.B. BV₂ und BV₃), entlang welcher Achse die teilende Ebene gezeichnet wurde (z.B. die X-Achse) und wo entlang der Achse die teilende Ebene gezeichnet wurde (z.B. bei Punkt X₁) speichern, ist aber nicht darauf beschränkt.
Der begrenzende dreidimensionale Raumbereich BV₃ kann dann in die beiden kleineren begrenzenden dreidimensionalen Raumbereiche BV₄ und BV₅ aufgeteilt werden, indem eine teilende Ebene 256 entlang der Y-Achse an Punkt Y₁ gezeichnet wird. Da BV₃ in zwei Unterknoten aufgeteilt wurde, kann er nun als interner Knoten bezeichnet werden. Das Aufteilen von BV₃ wird auch in dem Verzweigungsbaum durch die beiden BV₄ bzw. BV₅ entsprechenden Knoten 266 bzw. 268 widergespiegelt. Bei BV₄ und BV₅ handelt es sich um Blattknoten, da die durch sie dargestellten dreidimensionalen Raumbereiche nicht weiter in kleinere begrenzende dreidimensionale Raumbereiche aufgeteilt sind. Die beiden Blattknoten BV₄ und BV₅ befinden sich unter dem internen Knoten BV₃, der den begrenzenden dreidimensionalen Raumbereich darstellt, der in dem Verzweigungsbaum aufgeteilt wurde.
Der BV₃ entsprechende interne Knoten kann Daten wie zum Beispiel Verweise auf die beiden Blattknoten (z.B. BV₄ und BV₅), entlang welcher Achse die teilende Ebene gezeichnet wurde (d.h. die Y-Achse) und wo entlang der Achse die teilende Ebene gezeichnet wurde (z.B. bei Punkt Y₁) speichern, ist aber nicht darauf beschränkt.
Wenn somit ein verfolgter Strahl (traced ray) durch einen Punkt (X, Y) in den begrenzenden dreidimensionalen Raumbereich BV₅ projiziert wird, kann ein Algorithmus der punktweisen Betrachtung schnell und wirksam ermitteln, welche Basiselemente auf Überschneidung durch das Durchlaufen des bei Knoten 260 beginnenden Baums hin geprüft werden müssen, wobei aus der X-Koordinate des Punkts ermittelt wird, dass sich der Punkt in dem begrenzenden dreidimensionalen Raumbereich BV₃ befindet und zu Knoten 264 läuft, und aus der Y-Koordinate des Punkts ermittelt wird, dass sich der Punkt in dem begrenzenden dreidimensionalen Raumbereich BV₅ befindet und zu Knoten 268 läuft. Der Knoten 268 stellt einen Zugriff auf die Basiselementdaten für die Basiselemente 252C bereit, und somit kann der Algorithmus der punktweisen Betrachtung Überschneidungsprüfungen für diese Basiselement durchführen.
10 und 11 veranschaulichen als nächstes einen Verzweigungsbaumerzeugungs-Algorithmus, der zur Verwendung in dem GIR-Erzeuger 236 geeignet ist, um eine GIR zu erzeugen, die als eine Form von Verzweigungsbaum umgesetzt ist, der auf hoch parallele Weise erzeugt werden kann. Der hierin beschriebene Verzweigungsbaumerzeugungs-Algorithmus erzeugt eine dynamisch aufgebaute beschleunigte Datenstruktur (ADS) zum Übertragen von Daten im Datenstrom auf einer hoch parallelen Maschine, beruhend auf einem relativen Aufbau- und Traversierungsalgorithmus, der minimalen Speicher und minimale Speicherbandbreite verwendet, und der üblicherweise außer den von allgemeinen Wiedergabe-APIs wie DirectX und OpenGL derzeit bereitgestellten Informationen keine zusätzlichen Informationen benötigt.
Ein durch die hierin beschriebene Ausführungsform erzeugter Verzweigungsbaum ist als Baum mit Basis b umgesetzt, der in kleinere Bäume mit Tiefe k aufgeteilt ist, wobei jeder kleine Baum eine Verzweigung genannt werden kann. Wenn ein Blattknoten in der Verzweigung ein innerer Knoten des größeren Baums ist, enthält er einen Verweis auf eine andere, den Baum fortführende Verzweigung. Wenn es nur gestattet ist, Objekte an Blattknoten der kleineren Bäume zu platzieren, gibt es keine Notwendigkeit, die oberen Ebenen des Baums mit Tiefe k einzubinden, und der Baum kann daher als ein Baum mit Basis b^k angesehen werden. In einer Ausführungsform handelt es sich bei dem Verzweigungsbaum um einen Octree, der in kleine Bäume mit Tiefe 2 aufgeteilt ist und Daten nur auf geraden Ebenen speichern lässt, was im Wesentlichen gleichbedeutend mit einem Baum mit Basis 64 ist.
Der Verzweigungsbaum kann ebenfalls als sich ausdehnendes Gitter angesehen werden. Es wird ein Anfangsgitter aus 64 Voxeln hergestellt. Wenn es innerhalb eines dieser Voxel eine ausreichend kleine Geometrie gibt, wird in diesem ein weiteres Gitter aus 64 Voxeln bzw. eine Verzweigung hergestellt. Das Muster wird so lange fortgeführt, bis eine nennenswerte bzw. maximale Tiefe an Gittern/Verzweigungen erreicht ist. Vom Speicherstandpunkt aus ist jeder Zweig jedoch einfach als 64 Knoten gespeichert, wie nachfolgend gezeigt ist:

struct branch{
   node nodes[64];
 };

In der veranschaulichten Ausführungsform handelt es sich bei den Knoten der Verzweigung um 4-Byte-Wörter, die entweder einen Verweis auf Geometrie, eine Geometrieliste, einen Nullwert oder eine relative Position (offset) einer anderen Verzweigung enthalten. Wenn ein Knoten in der Verzweigung ein oder mehrere Geometriestücke enthält, enthält er einen Verweis zu der Geometrie bzw. Geometrieliste. Es ist wünschenswert, dass die Adresse der Geometrie bzw. Geometrieliste größer als die Anzahl von Verzweigungen ist, aus denen der Baum besteht, da der Datentyp des Knotens dadurch ermittelt werden kann, dass der vorzeichenlose ganzzahlige Wert des Knotens höher bzw. niedriger als dieser Schwellwert ist. Wenn ein Knoten leer ist, enthält er einen Nullwert. Wenn es sich um einen inneren Knoten handelt, enthält er eine relative Position der Verzweigung, die den Baum danach fortsetzt. Bei der relativen Position handelt es sich um einen Index in einer Verzweigungsliste, die während des Aufbauprozesses des Baums erstellt wird. Ein Knoten kann zum Beispiel die folgende Struktur haben:

struct node{
   union {
       uint offset;
       geometry *geo;
       geometry_list * geo_list; 
};
}

während eine Geometrieliste zum Beispiel die folgende Struktur haben kann:

struct geometry_list{
   uint num_geometry;
   geometry * geo_ptr;
        
        };

In der veranschaulichten Ausführungsform ist der Aufbau des Verzweigungsbaums so ausgeführt, dass er dynamisch und parallel durchgeführt werden kann. Der Algorithmus hängt von zwei globalen Variablen ab, einem Verweis auf den dem Baum zugeordneten Speicher und einer ganzen Zahl next_offset, die einen Index in diesem Speicher speichert, in dem eine neu aufgebaute Verzweigung gespeichert werden kann. Der Index kann entweder gemeinsam global genutzt werden, oder reservierter Speicher kann in Gruppen aufgeteilt werden, damit mehrere next_offset-Verweise verwendet werden können. Der einfacheren Beschreibung halber wird eine einzelne Zahl next_offset angenommen; in einigen Ausführungsformen können jedoch mehrere relative Positionen wünschenswert sein, um Speicherkonflikte zu verringern.

Dem Algorithmus wird auch die durch den Baum zulässige Maximaltiefe bereitgestellt. Da Gleitkommazahlen eine 24-Bit-Mantisse aufweisen, kann es wünschenswert sein, jede Tiefe eines Baums mit Basis 64 in die Lage zu versetzen, zwei Bits in jeder Richtung zu verwenden, so dass eine Maximaltiefe von max_d = 12 verwendet werden kann. Ein Verzweigungsbaum mit Tiefe zwölf und Basis 64 weist die gleichwertige Genauigkeit wie ein 64¹²-Voxelgitter auf.

Zum Initialisieren des Baums wird next_offset auf 65 gesetzt, und ein Zweig mit ausschließlich leeren Knoten (Nullwerten) wird in den ersten Zweig (oberster Zweig) in der Speicherzuordnung geschrieben. Es werden keine weiteren Schritte benötigt.

Danach wird jedes im Datenstrom übertragene Geometrie-Basiselement von dem im Datenstrom übertragenden Geometrie-Front-End unter Verwendung einer Instanz einer Routine wie der Routine 270 aus 10 in der Szene platziert. Folglich ist der GIR-Erzeuger so konfiguriert, dass er eine Instanz einer Platzierungsroutine in jedem der Vielzahl von dem GIR-Erzeuger zugehörigen parallelen Ausführungs-Threads ausführt und eine Vielzahl von Basiselementen parallel in den Verzweigungsbaum einfügt.

Die Platzierungsfunktion empfängt als Eingabe einen Verweis auf die Geometrie sowie die dreidimensionalen Minimal- und Maximalwerte, die von Gleitkommakoordinaten in ganzzahlige Gitterkoordinaten umgewandelt wurden. Die Gitterkoordinaten gehen bei Maximaltiefe von einer Schrittgröße von eins aus. Außerdem kann der Baumaufbauprozess durch Verwenden einiger weniger Vergleiche an Stelle von Masken üblicherweise ohne Umwandlung von Gleitkomma zu ganzer Zahl durchgeführt werden.

Die Routine 270 beginnt in Block 272 durch das Entscheiden, an welchen Knoten die Geometrie-Basiselemente zu platzieren sind. Dieser Prozess geht üblicherweise mit dem Erstellen von Schlüsseln aus den Minimal- und Maximalwerten einher. Die Schlüssel können entweder mit Vergleichen oder aus in ganzzahlige Werte umgewandelten Gleitkommawerten erstellt werden. In der veranschaulichten Ausführungsform wird ein Vergleich mit ganzzahligen Werten verwendet. Ein 6-Bit-Schlüssel stellt den Knotenindex in der aktuellen Verzweigung dar und besteht aus einer Reihe von ganzzahligen X-, Y- und Z-Werten für einen Punkt. Die Gleichung für das Erstellen des Baums lautet:

node_key [0:5] = {x [2 * (max_d - d) : + 1], y [2 * (max_d - d) : + 1], z [2 * (max_d - d) : + 1]};

wobei d die aktuelle Tiefe der Verzweigung darstellt, und max_d die maximale Tiefe des Baums darstellt, wobei die Knoten Würfel mit dem ganzzahligen Rauminhalt 1 darstellen.

Der Algorithmus kann sämtliche Knoten finden, die das Geometrie-Basiselement betreffen, indem er für die Minimal- und Maximalpunkte der Geometrie die X-, Y- und Z-Komponenten der Schlüssel findet und alle möglichen Schlüssel zwischen und einschließlich der Minimal- und Maximalwerte erzeugt. Alternativ können genauere Verfahren verwendet werden.

Somit leitet der Block 274 eine FÜR-Schleife ein und ruft für jeden Knoten den Knoten in Block 276 ab, bestimmt in Block 278, ob der Knoten ein innerer Knoten ist, und wenn dem nicht so ist, springt in Block 280 zu der nächsten Verzweigung.

Wenn jedoch ermittelt wird, dass ein Knoten ein Blattknoten und kein innerer Knoten ist, gibt der Block 278 die Steuerung an Block 282 ab, um zu ermitteln, ob das Geometrie-Basiselement in der aktuellen Tiefe in dem Baum zu platzieren ist. Es können zwei Faktoren verwendet werden, um diese Ermittlung durchzuführen. Der erste besteht darin, zu ermitteln, in welcher Art Knoten es sich befindet. Wenn der Knoten ein innerer Knoten ist, gibt es darunter eine Geometrie und es wird nicht auf dieser Ebene platziert, was in Block 278 ermittelt wird. Der zweite Faktor besteht in der Größe des Geometrie-Basiselements. In der veranschaulichten Ausführungsform wird das Geometrie-Basiselement platziert, wenn die Knotenbreite größer als vier Mal die Größe des Vektors von dem Minimalwert zu dem Maximalwert des Geometrie-Basiselements ist.

Wenn die Entscheidung getroffen wird, das Geometrie-Basiselement zu platzieren, geht die Steuerung weiter zum Kennzeichnen und Hinzufügen des Geometrie-Basiselements in Block 284, wobei das Basiselement platziert wird und die aktuelle Wiederholung der Routine 270 abgeschlossen ist. Wenn entschieden wird, das Geometrie-Basiselement nicht in der aktuellen Tiefe zu platzieren, wird der Knoten in den Blöcken 286, 288, 290 und 292 erweitert. Konkret ruft der Block 288 die Routine 270 rekursiv auf, um das Geometrie-Basiselement in der neuen Verzweigung zu platzieren. Der Block 290 ermittelt, ob es irgendeine andere Geometrie in dem Knoten gibt, und wenn dem so ist, übergibt er die Steuerung an Block 292, um die andere Geometrie durch Aufrufen der Routine 270 für jedes gekennzeichnete Geometrie-Basiselement in dem Knoten rekursiv in dem Knoten zu platzieren. Nach Abschluss von Block 292 bzw. wenn der Knoten sonst leer ist, wie in Block 290 ermittelt wurde, ist die Routine 270 abgeschlossen.

Somit wird in dem Fall, dass der Knoten ein leerer Knoten ist, an der durch *next_offset angegebenen Stelle eine neue leere Verzweigung erstellt. Der Wert von *next_offset wird dann in dem sich erweiternden Knoten gespeichert und erhöht. So wird der Baum erweitert und aufgebaut. Wenn der Knoten bestehende gekennzeichnete Geometrie-Basiselemente enthält, wird die Geometrie eingebettet, um aus dem aktuellen Knoten einen inneren Knoten zu machen. Die bestehende Geometrie wird nach dem Platzieren des neuen Geometrie-Basiselements eingebettet, da sie kleiner ist und tiefer gehen kann als die gekennzeichnete Geometrie. Als solche stellt die Routine 270 sicher, dass sämtliche Geometrie in die Blattknoten geschoben wird, wenn diese erweitert werden. Die Routine 270 erweitert folglich immer dann dynamisch den Verzweigungsbaum, wenn ein Basiselement in eine volle Verzweigung eingefügt werden muss.

11 veranschaulicht eine Routine zum Hinzufügen von Geometrie 300, die zum Beispiel in Block 284 der Routine 270 (10) aufgerufen werden kann. Die Routine 300 ermittelt zunächst unter Verwendung der Blöcke 302 und 304, in welchem Zustand (leer, einzelne Geometrie, Geometrieliste) sich der Knoten befindet, und geht entsprechend vor.

Wenn der Wert des Knotens 0 ist, ist der Knoten leer, und als solches übergibt der Block 302 die Steuerung an den Block 306, um die neue Geometrie zu verknüpfen, indem der Wert in dem Knoten durch einen Verweis auf das Geometrie-Basiselement, das platziert wird, ersetzt wird, wodurch die Routine 300 abgeschlossen ist. Wenn der Knoten einen Wert ungleich Null aufweist, ermittelt der Block 304, ob der Knoten einen Verweis auf ein einzelnes Geometrie-Basiselement oder eine Geometrieliste gespeichert hat, indem der Wert an der verwiesenen Adresse als vorzeichenlose ganze Zahl geladen wird. Wenn dieser ganzzahlige Wert zwischen einschließlich eins und der maximalen Anzahl von zulässigen Basiselementen (z.B. 15) liegt, wird bestimmt, dass der Verweis ein geometry_list-Verweis ist, da der Wert die num_geometry-Komponente einer geometry_list ist. Andernfalls wird angenommen, dass der Wert ein einzelnes Geometrie-Basiselement ist.

Es ist wichtig, anzumerken, dass Gleitkommawerte bzw. Binärwerte zulässig sind, die gleich ganzzahligen Werten zwischen 1 und 15 sind. Außerdem kann durch das Vermeiden des Verarbeitens einer Liste für den Fall, dass es lediglich ein einzelnes Geometrie-Basiselement in einem Knoten gibt, eine erhebliche Menge an Zeit und Speicher eingespart werden, wobei dies jedoch lediglich dann angewendet werden kann, wenn es entweder nur einen Typ von Geometrie-Basiselement in einer Szene gibt oder wenn das Geometrie-Basiselement mit einer den Typ beschreibenden Kopfzeile (type header) bereitgestellt wird. Andernfalls wird für sämtliche Basiselemente irgendeine Art Liste benötigt.

Geometrielisten in der veranschaulichten Ausführungsform weisen eine ganze Zahl num_geometry auf, die angibt, wie viele Geometriestücke sich in der Liste befinden, sowie eine Liste mit Verweisen auf Geometrie. Der zugeordnete Platz für die Anzahl von Verweisen ist gleich oder niedriger als die Anzahl von notwendigen Neuzuordnungen. Deshalb wird beim Hinzufügen eines neuen Geometriestücks zu der Liste neuer Speicherplatz zugeordnet, wenn der num_geometry-Wert gerade ist. Wenn er nicht gerade ist, wird einfach ein Verweis auf die Geometrie an das Ende der Verweisliste hinzugefügt. Num_geometry wird in beiden Fällen erhöht.

Als solches wird die Steuerung an Block 308 übergeben, wenn der Block 304 ermittelt, dass der Knoten ein einzelnes Geometrie-Basiselement enthält, um eine Geometrieliste zu erstellen und der neuen Liste eine Verknüpfung für das Geometrie-Basiselement hinzuzufügen. Andernfalls übergibt der Block 304 die Steuerung an Block 310 um zu ermitteln, ob die Liste voll ist. Wenn dem nicht so ist, fügt der Block 312 das Geometrie-Basiselement zu der Liste hinzu. Wenn die Liste voll ist, ermittelt der Block 314, ob es zu viele Basiselemente in dem Knoten gibt. Wenn dem nicht so ist, wird in Block 316 eine neue Liste mit zwei zusätzlichen Plätzen erstellt, und das neue Geometrie-Basiselement wird mit der Liste verknüpft. Wenn der Knoten zu voll ist, bettet der Block 318 die neuen und bestehenden Geometrie-Basiselemente durch rekursives Aufrufen der Routine 270 ein.

Es ist beachtenswert, dass die Routinen 270 und 300 in einer parallelen Hardware-Architektur verwendet werden können, da mehrere Instanziierungen derartiger Routinen verwendet werden können, um verschiedene Basiselemente gleichzeitig in demselben Verzweigungsbaum zu platzieren. Wenn man davon ausgeht, dass eine ausreichende Anzahl von parallelen Ausführungs-Threads einem ADS-Erzeuger zugeordnet sind, der derartige Routinen umsetzt, kann das Erzeugen einer ADS folglich mit derselben Geschwindigkeit geschehen, wie Basiselemente von dem im Datenstrom übertragenden Geometrie-Front-End im Datenstrom übertragen werden, und sobald sämtliche Basiselementdaten für eine Szene von dem im Datenstrom übertragenden Geometrie-Front-End im Datenstrom übertragen wurden, ist eine vollständig aufgebaute ADS nahezu unmittelbar zur Verwendung durch ein physisches Wiedergabe-Back-End verfügbar.

Wenden wir uns nun 12 zu, in der wie oben angemerkt mehrere im Datenstrom übertragende Geometrie-Front-Ends in Übereinstimmung mit der Erfindung verwendet werden können. 12 veranschaulicht zum Beispiel ein auf Rastern beruhendes, im Datenstrom übertragendes Geometrie-Front-End 330, das einen Grouper 332, die Geometrie-Engine 334 und das Nach-Geometrie-Engine-Modul 336 enthält. Der Grouper 332 gruppiert Daten zur Übertragung im Datenstrom durch die Pipeline, während die Geometrie-Engine 334 Objektumwandlungen durchführt und die Geometrie-Basiselemente erzeugt. Das Modul 336 führt Arbeitsschritte wie Perspektivenaufteilungen, Filterung (culling), Sortierung oder Aufteilen von Geometrie durch, und bei dem von dem Modul 336 ausgegebenen Endergebnis handelt es sich um einen Strom von Geometrie-Basiselementen. Man wird verstehen, dass eine große Vielfalt von im Datenstrom übertragenden Geometrie-Front-End-Architekturen in Übereinstimmung mit der Erfindung verwendet werden kann, und als solche ist die Erfindung nicht auf die bestimmte, in 12 veranschaulichte Architektur beschränkt.

13 veranschaulicht als nächstes eine Umsetzung der punktweisen Betrachtung eines physischen Wiedergabe-Back-End 340 in Übereinstimmung mit der Erfindung. Das Back-End 340 enthält ein Hauptstrahl-Verwaltungsmodul 342, das die Schnittstellen mit dem Wiedergabe-Front-End, das Einleiten und Synchronisieren sämtlicher Anfangsstrahlen und das Durchführen der Leistungsüberwachung und des dynamischen (bzw. statischen) Lastenausgleichs handhabt. Ein oder mehrere andere Strahlenverwaltungsmodule 344 agieren als Slave-Strahlenverwaltungsmodul, das Strahlen von den Master- oder anderen Slave-Modulen erhält und die ADS so lange durchläuft, bis ermittelt wird, ob der Strahl einen vollen Blattknoten schneidet. Wenn dem nicht so ist, wird die Standardhintergrundfarbe angelegt. Wenn dem so ist, wird der Strahl an ein Strahl-Basiselement-Überschneidungsmodul 346 gesendet, das die Überschneidungen zwischen Strahlen und Basiselementen ermittelt. Ein Farbaktualisierungsmodul 348 aktualisiert Pixel in einer Szene beruhend auf den ermittelten Überschneidungen von Strahlen und Basiselementen. Man wird verstehen, dass eine große Vielfalt von Back-End-Architekturen zum punktweisen Betrachten in Übereinstimmung mit der Erfindung verwendet werden kann, und als solche ist die Erfindung nicht auf die bestimmte, in 13 veranschaulichte Architektur beschränkt.

Eine Umsetzung einer Software-Pipeline zum Umsetzen der oben erwähnten Hybrid-Wiedergabe-Funktionalität ist bei 400 in den 14A und 14B veranschaulicht. 14A veranschaulicht insbesondere hauptsächlich die Front-End-Aspekte der Architektur, während 14B hauptsächlich die Back-End-Aspekte der Architektur veranschaulicht. Die Software-Pipeline 400 ist durch ein NOC umgesetzt, das sich in einer Grafikprozessoreinheit (GPU) befindet, die über einen Bus wie zum Beispiel einen PCI-Express-Bus 414 mit einem Host-Prozessor (CPU) verbunden ist.

Wie in 14A gezeigt ist, verwendet die Anwendung 402 einen Treiber 404 zum Liefern von Aufgabenanforderungen an die Software-Pipeline über einen Aussendepuffer 406. Die Anwendung 402 und der Treiber 404 werden in der CPU ausgeführt, während sich der Aussendepuffer 406 in dem gemeinsam genutzten Speicher befindet, auf den sowohl von der CPU als auch von der GPU zugegriffen werden kann. Aufgabenanforderungen werden durch eine Befehlsverarbeitungslogik und insbesondere einen Host-Schnittstellen-Prozessor (HIP) 408 aus dem Aussendepuffer 406 abgerufen. Außerdem werden Treiberzustandsinformationen in dem zugeordneten Speicher 410, 412 in der CPU bzw. GPU gepflegt. Die Zustände der Aussendepuffer-Kopf- und -Ende-Verweise für den Aussendepuffer 406 werden bei 416 bzw. 418 in dem Speicher 410 gepflegt, während der Zustand der Ende-Verweise bei 420 in dem Speicher 420 gepflegt wird.

Der HIP 408 richtet die Software-Pipeline ein, weist Stufeninstanzen in der Pipeline Ausführungs-Threads zu, gibt Aufgabenanforderungen an die Pipeline aus und überwacht den Arbeitsfluss, um Ausführungs-Threads dynamisch anderen Stufen der Pipeline zuzuordnen, um den Durchsatz zu maximieren und Engpässe zu minimieren. In diesem Zusammenhang weist der HIP 408, der selbst üblicherweise in einem IP-Block eines NOC umgesetzt ist, einen oder mehrere IP-Blöcke an, jede Stufe der Pipeline sowie andere unterstützende Logik, die zum Verwalten des Betriebs der Pipeline erforderlich sein können, zu bewältigen. Ein Ausführungs-Thread in diesem Zusammenhang stellt einen in einem IP-Block umgesetzten Hardware-Thread dar, wobei es klar ist, dass in mehrere Hardware-Threads unterstützenden IP-Blöcken verschiedenen Threads in demselben IP-Block mehrere Stufeninstanzen in einer Pipeline zugewiesen werden können.

Zu Beispielen für unterstützende Logik gehören die DMA-Engines 422, 424, die jeweils dazu verwendet werden, Vertex-Daten von einem Vertex-Puffer 426 und komprimierte Texturdaten von einem Texturdatenpuffer 428 im Direktspeicherzugriffsverfahren zu übertragen. Ein Pufferspeicher 430, der eine Indexanordnung 432, den Vertex-Puffer 434 und die komprimierten Texturdaten 436 enthält, dient als Ziel für die DMA-Engines 422, 424. Der HIP 408 richtet in den DMA-Engines 422, 424 eine Reihe von Eingängen 437 zum Empfangen von Aufgabenanforderungen von dem HIP ein. Ein Eingang 437 wird für jede DMA-Engine in der Pipeline bereitgestellt.

Ein Unterbrechungsmechanismus 441 wird in der Software-Pipeline 400 verwendet, um eine knotenübergreifende Datenübertragung zwischen Logikeinheiten in der Pipeline zu ermöglichen. Knoten wie der HIP 408 und die DMA-Engines 422, 424 empfangen Unterbrechungen von dem Mechanismus 441 und sind in der Lage, über an den Unterbrechungsmechanismus ausgegebene speicherabgebildete Eingabe/Ausgabe- (MMIO-) Anforderungen Unterbrechungen an andere Knoten auszugeben.

Das Front-End der Pipeline 400 ist durch einen Vertex-Prozessor umgesetzt, der eine erste, als Grouper konfigurierte Einheit 450 und eine zweite, als Geometrie-Shader konfigurierte Einheit 452 sowie einen Texturprozessor 454 enthält.

Der HIP 408 leitet Aufgaben in dem Vertex-Prozessor 450, 452 und dem Texturprozessor 454 unter Verwendung der Eingänge 438, 440 ein. Mindestens ein Eingang 438 ist jeder Einheit in dem Vertex-Prozessor zugeordnet, und mindestens ein Eingang 440 ist jeder Einheit in dem Texturprozessor 454 zugeordnet. Außerdem ist der HIP in der Lage, Daten in eine Wiedergabe-Kontext-Tabelle 442, eine Vertex-Sortier-Tabelle 444, eine Basiselement-Sortier-Tabelle 446 und eine Textur-Kontext-Tabelle 48 zu schreiben. Die Vertex-Prozessor-Einheit 450 reagiert auf einem Eingang 438 zugeführte Anforderungen und ruft von der Index-Anordnung 432 und dem Vertex-Puffer 434 Arbeitsdaten ab. Die Einheit 450 tauscht über einen Eingang 456 Daten mit der Vertex-Prozessor-Einheit 452 aus, und die Einheit 452 gibt Basiselemente an eine Anordnung von Eingängen 458, 460 aus. Der Texturprozessor 454 empfängt Anforderungen von einem Eingang 440, liest die Texturdaten 436 von dem Pufferspeicher 430 und gibt Daten an einen Texturspeicher 462 aus.

Wie in 14B gezeigt ist, ist eine Reihe von Eingängen 458, 460 jedem aus einer Vielzahl von GIR-Erzeugerelementen 464 zugeordnet, die gemeinsam einen GIR-Erzeuger umsetzen und es dem Front-End der Pipeline ermöglichen, Basiselementdaten zur Verwendung beim Aufbauen einer GIR 472 bereitzustellen. Wie oben angemerkt wird eine Vielzahl von parallelen Ausführungs-Threads, z.B. einer oder mehrere pro Element 464, zum Erzeugen der GIR auf die oben beschriebene Weise verwendet.

Ein oder mehrere Haupt-Strahl-Verwaltungselemente 466, ein oder mehrere Strahl-Verwaltungselemente 468, ein oder mehrere Strahl-Basiselement-Überschneidungselemente 470 bzw. ein oder mehrere Farbaktualisierungselemente 471 setzen ein Back-End zur punktweisen Betrachtung um. Eine variable Anzahl von Ausführungs-Threads kann jeder Art von Element 466, 468, 470, 471 zugeordnet werden, um den Durchsatz durch die Software-Pipeline zu optimieren. Die Elemente 466, 468 und 470 verwenden die GIR 472 zum Durchführen von Arbeitsschritten zur punktweisen Betrachtung, während das Element 470 Texturdaten aus dem Texturspeicher 462 abruft. Die Datenübertragung zwischen Stufen des Back-End wird durch die Eingänge 474, 476 und 478 bereitgestellt, die jeweils den Elementen 468, 470 bzw. 471 zugeordnet sind. Die Farbaktualisierungselemente 471 geben Bilddaten an ein Wiedergabeziel 480 aus, z.B. an einen Bildpuffer, die dann über die digitale Videoausgabeschaltung 482 ausgegeben werden.

Man wird verstehen, dass die Umsetzung eines im Datenstrom übertragenden Geometrie-Front-End und eines Back-End zur punktweisen Betrachtung in den Software-Pipeline-Elementen und der zugrunde liegenden NOC-Architektur im Rahmen der Fähigkeiten eines gewöhnlichen Fachmanns mit Unterstützung der vorliegenden Darlegung läge. Man wird auch verstehen, dass zum Umsetzen jeder Stufe der Software-Pipeline eine unterschiedliche Anzahl von Elementen verwendet werden kann, und dass verschiedene Stufen verwendet werden können, um das Front-End und/oder Back-End der Pipeline beruhend auf den dadurch verwendeten bestimmten Algorithmen umzusetzen. Des Weiteren kann es durch das aktive Überwachen der Arbeitslast jeder Stufe der Pipeline in einigen Ausführungsformen wünschenswert sein, die Zuordnung von IP-Blöcken und Ausführungs-Threads zu verschiedenen Stufen der Pipeline dynamisch zu ändern und somit für verschiedene Arten von Aufgaben einen optimalen Durchsatz bereitzustellen.

MULTITHREAD-WIEDERGABE-SOFTWARE-PIPELINE ZUM ERKENNEN VON PHYSIKZUSAMMENSTÖSSEN

Wie oben erwähnt kann in einigen Ausführungsformen eine Multithread-Wiedergabe-Software-Pipeline verwendet werden, um das Erkennen von Physikzusammenstößen durchzuführen, indem Detailstufen- (LOD-) Komponenten für Objekte in einer Szene zwischen einer Vielzahl von Slave-Zusammenstoß-Erkennungs-Threads im Datenstrom übertragen werden. 15 veranschaulicht zum Beispiel die zweidimensionale Szene 490, die durch ein Bildverarbeitungssystem wiederzugeben ist. Man wird verstehen, dass eine Szene üblicherweise die physische Welt darstellt und somit üblicherweise in drei Dimensionen festgelegt ist. In 15 werden jedoch der Einfachheit halber zwei Dimensionen veranschaulicht.

Die Szene 490 enthält eine Vielzahl von Objekten 492 und kann in eine Vielzahl von räumlichen Bereichen 494 aufgeteilt werden, die auch begrenzende dreidimensionale Raumbereiche (BVs, Bounding Volumes) genannt werden können. Wie in der Figur veranschaulicht können die räumlichen Bereiche 494 verschieden groß und hierarchisch festgelegt sein, so dass einige räumliche Bereiche Bereiche anderer räumlicher Bereiche darstellen. Des Weiteren können räumliche Bereiche auf gleichartige Weise wie die für die punktweise Betrachtung verwendeten begrenzenden dreidimensionalen Raumbereiche festgelegt werden, z.B. so, dass jeder räumliche Bereich so festgelegt werden kann, dass er die Arbeitslast ausgleicht, wobei ein Bereich einer Szene, der mehr Objekte 492 enthält, in kleinere räumliche Bereiche aufgeteilt wird, um die Arbeitslast besser unter den Hardware-Threads auszugleichen, die zum Durchführen der Zusammenstoßerkennung für derartige Bereiche zugewiesen sind.

Die Zusammenstoßerkennung geht üblicherweise mit dem Erkennen von Zusammenstößen zwischen sich in einer Szene bewegenden Objekten und anderen, sowohl sich bewegenden als auch feststehenden Objekten einher. Somit kann wie in 15 gezeigt die Zusammenstoßerkennung dazu verwendet werden, einen Zusammenstoß zwischen den zwei sich bewegenden Objekten 496, 498 miteinander sowie mit den anderen Objekten 492 in der Szene zu erkennen.

In einigen Ausführungsformen in Übereinstimmung mit der Erfindung ist die Physikzusammenstoßerkennung unter Verwendung einer Vielzahl von Hardware-Ausführungs-Threads umgesetzt, die untereinander Detailstufenkomponenten im Datenstrom übertragen, um Zusammenstöße zwischen Objekten in einer Szene zu erkennen. Wie in 16 gezeigt kann eine Physikzusammenstoßerkennung in einer Schaltkreisanordnung 500 umgesetzt werden, die ein mit einem Speicherteilsystem 504 verbundenes NOC 502 enthält, die beide in dieselbe integrierte Schaltung integriert sein können oder alternativ in separaten integrierten Schaltungen umgesetzt sein können. Das NOC 502 kann die IP-Blöcke 506 enthalten, die miteinander über ein Netzwerk 508 verbunden sind, das die oben in Zusammenhang mit dem NOC 102 aus 2 erörterte Netzwerklogik enthalten kann.

Wie oben angemerkt können verschiedene Teilmengen der IP-Blöcke 506 verschiedenen Funktionalitäten zugeordnet sein, und in Zusammenhang mit der Physikzusammenstoßerkennung können ein oder mehrere IP-Blöcke eine Physik-Engine bereitstellen, die einen Master- bzw. Komponenten-Lade-Thread 510 umfasst, der dafür verwendet wird, Detailstufendaten für ein Objekt aus dem Speicher 504 abzurufen und die Daten an einen oder mehrere Zusammenstoß-Erkennungs-Threads 512 im Datenstrom zu übertragen, die als Slave-Hardware-Threads arbeiten und sich in einem oder mehreren anderen IP-Blöcken 506 befinden. Slave-Hardware-Threads können ebenfalls Detailstufendaten an andere Slave-Hardware-Threads im Datenstrom übertragen, z.B. an weiter hinten in einer Software-Pipeline angeordnete Slave-Hardware-Threads.

Da die Slave-Hardware-Threads Detailstufendaten von dem Master-Thread empfangen, müssen die Slave-Hardware-Threads üblicherweise die Daten nicht aus dem Speicherteilsystem 504 laden, wodurch Bandbreitenanforderungen an den Speicher verringert werden, Datenübertragungskosten gesenkt werden und die Durchführung beschleunigt wird. Als solches kann es wünschenswert sein, den Master-Thread 510 physisch in einem IP-Block 506 zu platzieren, der sich nahe an dem Speicher 504 befindet (d.h. mit minimaler Netzwerklatenzzeit), und die Slave-Threads 512 in den IP-Blöcken 506 zu platzieren, die sich nahe an dem Master-Thread 510 sowie nahe zueinander befinden, wiederum um die Netzwerklatenzzeit beim Weiterleiten von Daten von einem Thread zu einem anderen zu minimieren.

Das Erkennen von Physikzusammenstößen kann auch in einer Software-Pipeline umgesetzt werden, die gleichartig wie die in Zusammenhang mit 5 beschriebene ist, und wie durch die Pfeile in 16 veranschaulicht ist, können Detailstufendaten von dem Master-Thread 510 an die Slave-Threads 512 im Datenstrom übertragen werden, und mit den Ergebnissen der von dem letzten Slave-Thread 512 im Datenstrom übertragenen Zusammenstoßerkennung zurück an den Master-Thread 510, und all das über das Netzwerk 508. Ein HIP (in 16 nicht gezeigt) kann dazu verwendet werden, die an die Master- und Slave-Threads weitergeleiteten Aufgaben auf gleichartige Weise zu verwalten, wie ein HIP Aufgaben in Verbindung mit der Wiedergabe verwaltet. Jeder Master- und Slave-Thread kann eine Stufe der Pipeline umsetzen, obwohl man verstehen wird, dass in einigen Ausführungsformen mehrere Hardware-Threads eine Stufe umsetzen können, und in anderen Ausführungsformen ein Hardware-Thread mehrere Stufen umsetzen kann.

Außerdem kann die Anordnung von Threads und das Zuweisen selbiger zu räumlichen Bereichen zum Durchführen des Erkennens von Zusammenstößen in vielerlei Hinsicht gleichartig sein, wie Threads in Zusammenhang mit der oben beschriebenen punktweisen Betrachtung angeordnet werden. Als solches kann es auch wünschenswert sein, zum Speichern der Objekte in einer Szene eine wie oben beschriebene beschleunigte Datenstruktur zu verwenden, um das Erkennen von Zusammenstößen in Übereinstimmung mit der Erfindung durchzuführen.

17 veranschaulicht als nächstes eine durch einen Master-Thread ausgeführte beispielhafte Routine 520. Die Routine 520 wird für jeden Zeitabschnitt ausgeführt, für das ein Erkennen von Zusammenstößen durchzuführen ist, bei dem es sich abhängig von der in Zusammenhang mit der Zusammenstoßerkennung benötigten Genauigkeit um denselben Zeitabschnitt zwischen Bildrahmen handeln kann. Die Routine 520 beginnt in Block 522 mit dem Einleiten einer FÜR-Schleife, um jedes sich bewegende Objekt in der Szene zu verarbeiten. Der Block 524 ermittelt für jedes derartige Objekt zunächst, ob bereits irgendeine Detailstufenkomponente für das Objekt erstellt wurde. Wenn dem nicht so ist, wird in Block 526 eine geeignete Detailstufenkomponente erstellt. Wie oben angemerkt, kann das Erstellen einer Detailstufenkomponente mit dem Erstellen einer Komponente mit schwankender Komplexität einhergehen, die auf Faktoren wie System-Ressourcen und gewünschter Genauigkeit beruhen. Je einfacher die Detailstufenkomponente ist und je weniger prozessorintensive Detailstufenberechnungen benötigt werden, desto geringer ist üblicherweise die erreichte Genauigkeit. Deshalb können in einigen Ausführungsformen kompliziertere Detailstufenkomponenten erstellt werden, wenn die verfügbaren System-Ressourcen größer sind und Genauigkeit wünschenswert ist.

Nach der Erstellung wird die Detailstufenkomponente in Block 528 gemeinsam mit dem „Durchlauf“ („sweep“) des Objekts an einen oder mehrere Slave-Threads im Datenstrom übertragen. Auch wird der Block 526 umgangen, wenn in Block 524 festgestellt wird, dass für das Objekt bereits eine Detailstufenkomponente vorhanden ist, und der Block 524 übergibt die Steuerung direkt an Block 526. In der veranschaulichten Ausführungsform stellt der Durchlauf eines Objekts die Bewegung des Objekts von einer Ausgangsposition zu einer Endposition während des aktuellen Intervalls dar. Somit kann der Durchlauf durch einen Vektor sowie Start- und End-Voxel dargestellt werden, welche die Richtung und die Entfernung der Bewegung eines Objekts in einem gegebenen Intervall darstellen.

Sobald die Daten für ein Objekt in Block 528 im Datenstrom übertragen werden, kehrt die Steuerung zu Block 522 zurück, um weitere Objekte zu verarbeiten. Sobald alle Objekte verarbeitet wurden, übergibt der Block 522 die Steuerung an Block 530, um auf die durch die Slave-Threads erzeugten Zusammenstoßdaten zu warten und diese beim Empfangen entsprechend zu verarbeiten. Die Slave-Threads können zum Beispiel Daten zurückmelden, die angeben, (1) welche Objekte zusammengestoßen sind und (2) wann diese Zusammenstöße in dem Intervall stattgefunden haben. Die Routine 520 ist dann abgeschlossen.

18 veranschaulicht als nächstes eine durch einen Slave-Thread während der Zusammenstoßerkennung ausgeführte beispielhafte Routine 540. Die Routine 540 beginnt in Block 542 mit dem Empfangen der Stromdaten von der vorherigen Stufe in der Pipeline (Master oder Slave). Der Block 544 ermittelt dann, ob der Objektdurchlauf den Bereich schneidet, dem der Thread zugewiesen ist. Wenn dem nicht so ist, wird die Steuerung an Block 546 übergeben, um die Detailstufenkomponente, den Objektdurchlauf und jegliche von vorausgehenden Slave-Threads erzeugten Zusammenstoßdaten an einen oder mehrere Slave-Threads in der Pipeline bzw. alternativ, falls es sich um den letzten Slave-Thread in der Pipeline handelt, zurück an den Master-Thread zur weiteren Verarbeitung im Datenstrom zu übertragen. Die Routine 540 ist dann abgeschlossen.

Sollte der Objektdurchlauf den dem Thread zugewiesenen Bereich schneiden, übergibt der Block 544 die Steuerung an Block 548, um zu ermitteln, ob der Zeitpunkt des Eintretens der Überschneidung (z.B. relativ zu dem Zeitabschnitt) früher liegt als ein gekennzeichneter Zusammenstoß, der von einem vorausgehenden Slave-Thread erkannt wurde. Wenn dem nicht so ist, würde jegliche in dem Bereich auftretende Überschneidung erst nach einem anderen Zusammenstoß eintreten, so dass es keinen Grund gibt, in diesem Thread eine weitere Zusammenstoßerkennung durchzuführen. Folglich wird die Steuerung an Block 546 übergeben.

Andernfalls wird die Steuerung an Block 550 übergeben, um eine gründliche Zusammenstoßerkennung durchzuführen, um zu ermitteln, ob sich irgendwelche Objekte (sich bewegend oder ortsfest) in dem Bereich befinden, die sich mit dem betreffenden Objekt überschneiden. Die Steuerung wird dann an Block 552 übergeben, um festzustellen, ob ein Zusammenstoß erkannt wurde. Wenn dem nicht so ist, wird die Steuerung an Block 546 übergeben. Wenn jedoch ein Zusammenstoß erkannt wird, wird die Steuerung an Block 556 übergeben, um die Zusammenstoßdaten zu aktualisieren und den Zeitpunkt und das Objekt, mit dem das betreffende Objekt zusammengestoßen ist, anzugeben. Die Steuerung wird dann an Block 546 übergeben, um die aktualisierten Zusammenstoßdaten gemeinsam mit der Detailstufenkomponente und dem Objektdurchlauf an einen oder mehrere Slave-Threads bzw. alternativ zurück an den Master-Thread mit den Ergebnissen der Zusammenstoßerkennung im Datenstrom zu übertragen.

Die Umsetzung einer Physik-Zusammenstoß-Erkennungs-Software-Pipeline in der hierin beschriebenen NOC-Architektur, wie z.B. in den 14A bis 14B veranschaulicht ist, läge im Rahmen der Fähigkeiten eines gewöhnlichen Fachmanns mit Unterstützung der vorliegenden Darlegung. Außerdem wird man verstehen, dass zusätzliche Routinen, beispielsweise zum Zuweisen von Threads zu räumlichen Bereichen, zum Laden von Detailstufenkomponenten für statische Objekte in einer Szene, zum Ausgleichen der Lasten von Threads für optimale Leistungsfähigkeit usw., auch in Ausführungsformen in Übereinstimmung mit der Erfindung verwendet werden können.

PHYSIK-ENGINE MIT VORAUSSCHAUENDEM LASTENAUSGLEICH

Wie oben erwähnt kann es in einigen Ausführungsformen der Erfindung auch wünschenswert sein, einen vorausschauenden Lastenausgleich zu verwenden, um die Arbeitslast besser den Hardware-Threads in einer Multithread-Physik-Engine zuzuordnen.

Der vorausschauende Lastenausgleich beruht zumindest teilweise auf der Bewegung von Objekten in einer Szene und insbesondere auf dem Erkennen von vorhergesagten zukünftigen Zusammenstößen zwischen den Objekten in einer Szene, d.h., Zusammenstöße, die während des aktuellen Zeitabschnitts bzw. Schritts noch nicht eingetreten sind, die aber wahrscheinlich in einem späteren Zeitabschnitt bzw. Schritt eintreten werden. Des Weiteren kann es, obwohl in einigen Ausführungsformen bei jedem Erkennen eines zukünftigen Zusammenstoßes ein vorausschauender Lastenausgleich durchgeführt werden kann, in anderen Ausführungsformen wünschenswert sein, einen vorausschauenden Lastenausgleich nur in den Fällen durchzuführen, in denen erwartet wird, dass der Zusammenstoß eine erhebliche Auswirkung auf Arbeitslasten von Hardware-Threads hat.

19 veranschaulicht zum Beispiel eine beispielhafte Szene 600, in der sich ein Geschoss 602 durch die Szene auf eine Mauer 604 zu bewegt, die eine Vielzahl von Ziegelsteinen 606 enthält. Die aktuelle Position des Geschosses 602 zu einem aktuellen Zeitpunkt wird durch die Linie t₀ veranschaulicht. Die Bewegungsrichtung des Geschosses 602 wird durch den Vektor 608 veranschaulicht, und die erwarteten Positionen des Geschosses 602 zu drei aufeinanderfolgenden Zeitpunkten wird durch die Linien t₁, t₂ und t₃ veranschaulicht. Ein vorhergesagter Zusammenstoß 610 zwischen dem Geschoss 602 und der Mauer 604 zu Zeitpunkt t₃ ist ebenfalls veranschaulicht.

Nimmt man für die Zwecke dieses Beispiels an, dass die Mauer 604 und somit deren Ziegelsteine in der Szene ortsfest sind, wäre es nicht unvernünftig zu erwarten, dass die Arbeitslast jedes beliebigen zum Durchführen entweder der Zusammenstoßerkennung oder der Impulsweiterleitung zugeordneten Hardware-Thread nicht besonders hoch wäre, und als solches kann die Anzahl von Hardware-Threads, die dem die Mauer 604 umfassenden Bereich zugeordnet sind, wünschenswerterweise niedrig sein.

Andererseits kann eine realistische Simulation des Zusammenstoßens des Geschosses 602 mit der Mauer 604 mit einem wesentlich größeren Verarbeitungsaufwand einhergehen, da es wahrscheinlich ist, dass Impulse und Zusammenstöße zwischen mehreren Ziegelsteinen 606 auftreten. Folglich würden die dem die Mauer umfassenden Bereich zugeordneten Threads wahrscheinlich überlastet, wenn die Zuordnung der Arbeitslast statisch bliebe, was zu einer verringerten Leistungsfähigkeit führen würde. Außerdem kann das Neuzuordnen der Arbeitslast bei Erkennen des Zusammenstoßes die Leistungsfähigkeit verbessern; mit dem Neuzuordnen von Arbeitslasten ist jedoch üblicherweise ein Aufwand verbunden, da zum Durchführen der vorher bestimmten Threads zugeordneten Aufgaben üblicherweise Daten an neue Threads übertragen werden müssen, damit diese neuen Threads die Aufgaben durchführen können.

Ausführungsformen in Übereinstimmung mit der Erfindung versuchen daher das Auftreten von zukünftigen Zusammenstößen vorherzusagen und eine Neuzuordnung von Arbeitslast zwischen Hardware-Threads vor den eigentlichen Zusammenstößen einzuleiten, so dass der mit der Neuzuordnung verbundene Aufwand teilweise oder sogar vollständig vor dem Erkennen von aktuellen Zusammenstößen, die den erkannten zukünftigen Zusammenstößen entsprechen, anfällt, und dass eine optimale Zuordnung von Threads verfügbar ist, sobald die Zusammenstöße stattfinden.

Man wird verstehen, dass durch das vorausschauende Einleiten einer Neuzuordnung von Hardware-Threads die Neuzuordnung wünschenswerterweise, jedoch nicht notwendigerweise, abgeschlossen ist, wenn ein vorhergesagter Zusammenstoß letztendlich stattfindet. Selbst in Fällen, in denen die Neuzuordnung nicht abgeschlossen ist, wird die Neuzuordnung jedoch üblicherweise früher abgeschlossen sein, als wenn die Neuzuordnung als Reaktion auf einen erkannten Zusammenstoß eingeleitet würde. Man wird auch verstehen, dass in einigen Fällen ein Arbeitsschritt des vorausschauenden Lastenausgleichs zu einer vorübergehend nicht optimalen Zuordnung von Aufgaben zwischen Hardware-Threads führen kann, bis ein vorhergesagter Zusammenstoß letztendlich erkannt wird, im Gegensatz zu vielen Lastenausgleichsalgorithmen, die versuchen, beruhend auf aktuellen Arbeitslastanforderungen, eine optimale Zuordnung von Ressourcen zu erreichen.

Wenden wir uns nun 20 zu, die eine Routine 620 auf hoher Ebene für eine Physik-Engine veranschaulicht, die einen vorausschauenden Lastenausgleich in Übereinstimmung mit der Erfindung einschließt. Eine Physik-Engine in diesem Zusammenhang kann als eine beliebige Software angesehen werden, die zum Durchführen von mit Physik in Zusammenhang stehenden Berechnungen konfiguriert ist, und als solche gilt die Erfindung für jede beliebige mit Physik in Zusammenhang stehende Berechnungs-Software, unabhängig davon, ob diese Software als eine einzelne „Engine“ angesehen wird. In dieser Ausführungsform handelt es sich bei der Physik-Engine um eine Multithread-Physik-Engine, in der mehrere Hardware-Threads, die sich zum Beispiel in einem oder mehreren Verarbeitungskernen und in einem oder mehreren integrierten Schaltungschips befinden, die Arbeitslast der Physik-Engine gemeinsam ausführen.

Eine typische Physik-Engine führt auf einer hohen Ebene eine Schleife aus, die eine Arbeitsfolge zwischen dem Verarbeiten von Bewegungen von Objekten über einen gegebenen Zeitabschnitt bzw. Schritt (Block 622), dem Entdecken von Zusammenstößen (Block 624) und dem Weiterleiten von Impulsen beruhend auf irgendwelchen erkannten Zusammenstößen (Block 626) erstellt. In der veranschaulichten Ausführungsform wird jedoch in Block 628 ein zusätzlicher Schritt des vorausschauenden Lastenausgleichs durchgeführt, üblicherweise nach dem Erkennen eines Zusammenstoßes und vor dem Weiterleiten eines Impulses. Man wird verstehen, dass ein vorausschauender Lastenausgleich an verschiedenen Punkten in der Routine 620 durchgeführt bzw. in anderen Ausführungsformen als in einem der Blöcke 622 bis 626 eingeschlossen angesehen werden kann.

Ein Pool von Hardware-Threads (nicht gezeigt) kann zugeordnet werden, um verschiedene Funktionen in der Physik-Engine zu bewältigen. Es können zum Beispiel separate Thread-Pools verwendet werden, um die Funktionen der Physik-Engine zum Verarbeiten von Bewegungen, zum Erkennen von Zusammenstößen und zum Weiterleiten von Impulsen zu bewältigen. Es können auch ein oder mehrere Master-Threads zum Koordinieren der Aktivitäten dieser verschiedenen Thread-Pools verwendet werden. In alternativen Ausführungsformen können einzelne Threads mehrere der in den Blöcken 622, 624 und 626 durchgeführten Funktionen bewältigen. Diese Threads sind üblicherweise auf eine Weise zugeordnet, die versucht, die Arbeitslast gleichmäßig zwischen den Threads zu verteilen, z.B. durch Zuweisen von Threads zu bestimmten Bereichen einer Szene oder durch Zuweisen von Threads zu bestimmten Objektgruppen.

In der veranschaulichten Ausführungsform verarbeitet Schritt 622 der Routine 620 die Bewegung durch das Berechnen eines Objektdurchlaufs über eine Vielzahl von Zeitabschnitten für jedes Objekt in einer Szene. Wie in einer herkömmlichen Physik-Engine erkennt Schritt 624 „aktuelle“ Zusammenstöße in dem ersten Zeitabschnitt bzw. Schritt, welche die Bewegung darstellen, die während des aktuellen Zeitabschnitts in der Szene aufgetreten ist. Außerdem versucht Schritt 624 auch, „zukünftige“ Zusammenstöße zu erkennen, die Überschneidungen von über mehrere Zeitabschnitte vorhergesagten Objektdurchläufen darstellen, d.h. jenseits des ersten Zeitabschnitts.

Beruhend auf diesen zukünftigen Zusammenstößen und ausführlicher durch die Routine 630 für einen vorausschauenden Lastenausgleich aus 21 veranschaulicht, können Hardware-Threads vorausschauend neu zugeordnet werden. Insbesondere beginnt die Routine 630 in Block 632 durch das Feststellen beruhend auf der in dem Zusammenstoßerkennungsschritt 624 durchgeführten Analyse, ob irgendwelche zukünftigen Zusammenstöße vorhergesagt wurden. Wenn dem nicht so ist, wird kein Lastenausgleich benötigt, und die Routine 630 ist abgeschlossen.

Andererseits wird die Steuerung an den Block 634 übergeben, wenn irgendwelche zukünftigen Zusammenstöße erkannt/vorhergesagt werden, um die Eigenschaften jedes zukünftigen Zusammenstoßes zu analysieren und zu ermitteln, ob ein Lastenausgleich benötigt wird. Beruhend auf dieser Analyse ermittelt der Block 636, ob eine Neuverteilung der Last erforderlich ist, und wenn dem so ist, übergibt er die Steuerung an Block 638, um die Last neu zu verteilen (d.h., um die Hardware-Threads neu zuzuordnen), wodurch die Routine 630 abgeschlossen ist. Andernfalls wird der Block 638 umgangen, und die Routine 630 endet.

Die Analyse, ob eine Neuverteilung für einen zukünftigen erkannten Zusammenstoß benötigt wird, kann in verschiedenen Ausführungsformen variieren. Zu zwei Faktoren, die berücksichtigt werden können, gehören zum Beispiel die Anzahl von potenziell an den Zusammenstößen beteiligten Objekten sowie die Eigenschaften der potenziell an den Zusammenstößen beteiligten Objekte. Was die Anzahl von beteiligten Objekten angeht, kann der Zusammenstoß eines Geschosses mit einer Ziegelmauer wie oben in Verbindung mit 19 erörtert mit der gegenseitigen Beeinflussung einer großen Anzahl von Ziegelsteinen einhergehen, wenn sich die Mauer verformt und letztendlich explodiert. Wenn Objekte kompliziert sind und mit vielen gegebenenfalls an Zusammenstößen beteiligten grafischen Basiselementen einhergehen (die selbst als Objekte angesehen werden können), kann gleichermaßen eine kompliziertere Verarbeitung zum Bewältigen dieser Objekte erforderlich sein.

Was die Objekteigenschaften angeht, kann die physische Beschaffenheit der beteiligten Objekte mehr oder weniger Verarbeitung durch solchen Objekten zugewiesene Hardware-Threads erfordern. Ein harmlos von einer Mauer abprallender Gummiball, der nicht dazu führt, dass sich die Ziegelsteine der Mauer lösen, würde zum Beispiel keine wesentliche Zuordnung zusätzlicher Verarbeitung benötigen. Gleichermaßen würden zwei harte Objekte, die mit einer Kraft zusammenstoßen, die nicht ausreicht die Objekte zu zerbrechen, keine wesentliche Zuordnung zusätzlicher Verarbeitung benötigen. Im Gegensatz dazu würde ein energiereicher Zusammenstoß zwischen brüchigen und/oder komplexen Objekten wahrscheinlich (zumindest während der Dauer des Zusammenstoßes) zu erheblichen zusätzlichen Verarbeitungsanforderungen führen, um die mit derartigen Objekten verbundenen Zusammenstöße und/oder Impulsweiterleitungen zu bewältigen. Deshalb können beim Ermitteln, ob für einen bestimmten erkannten zukünftigen Zusammenstoß eine Neuzuordnung wünschenswert ist, Objekteigenschaften wie Steifigkeit, Verformbarkeit, Elastizität, Geschwindigkeit, Masse, Federkonstanten, Komplexität des Objekts usw. berücksichtigt werden.

Die Neuzuordnung von Hardware-Threads während des vorausschauenden Lastenausgleichs kann auf viele Arten in Übereinstimmung mit der Erfindung stattfinden. In Ausführungsformen, in denen die Zusammenstoßerkennung und die Impulsweiterleitung zum Beispiel durch verschiedene Thread-Pools durchgeführt werden, kann ein vorausschauender Lastenausgleich für die Zusammenstoßerkennung durchführende Threads, für die Impulsweiterleitung durchführende Threads oder für beide durchgeführt werden.

Obwohl ein vorausschauender Lastenausgleich in anderen Ausführungsformen von Multithread-Physik-Engines beruhend auf anderen Hardware-Architekturen umgesetzt werden kann, kann außerdem eine beispielhafte Umsetzung des vorausschauenden Lastenausgleichs dem Zwecke des Lastenausgleichs für Slave-Zusammenstoß-Erkennungs-Threads in einem NOC wie dem in 16 veranschaulichten und oben beschriebenen NOC 500 dienen, das eine im Datenstrom übertragende Multithread-Software-Pipeline-Architektur verwendet, die Detailstufenkomponenten von einem Master-Hardware-Thread zum Laden von Komponenten an eine Vielzahl von Slave-Zusammenstoß-Erkennungs-Threads im Datenstrom überträgt. 22 und 23 veranschaulichen zum Beispiel die Zusammenstoßerkennungsroutinen 640, 660, die durch Master- bzw. Slave-Threads ausgeführt werden und gleichartig wie die in den 17 und 18 veranschaulichten Routinen 520, 540 sind.

Die Routine 640 aus 22 wird für jeden Zeitabschnitt ausgeführt, für den eine Zusammenstoßerkennung durchzuführen ist, und beginnt in Block 642 mit dem Einleiten einer FÜR-Schleife, um jedes sich bewegende Objekt in der Szene zu verarbeiten. Der Block 644 ermittelt für jedes derartige Objekt zunächst, ob bereits irgendeine Detailstufenkomponente für das Objekt erstellt wurde. Wenn dem nicht so ist, wird in Block 646 eine geeignete Detailstufenkomponente erstellt. Nach der Erstellung wird die Detailstufenkomponente in Block 648 gemeinsam mit dem „Durchlauf“ („sweep“) des Objekts an einen oder mehrere Slave-Threads im Datenstrom übertragen. Auch wird der Block 646 umgangen, wenn in Block 644 festgestellt wird, dass für das Objekt bereits eine Detailstufenkomponente vorhanden ist, und der Block 644 übergibt die Steuerung direkt an Block 648. Im Gegensatz zu der Routine 520, bei welcher der Durchlauf eines Objekts die Bewegung eines Objekts von einer Ausgangsposition zu einer Endposition während des aktuellen Intervalls darstellt, stellt der in Block 648 der Routine 640 berechnete und im Datenstrom übertragene Durchlauf die Bewegung eines Objekts von einer Ausgangsposition zu einer Endposition während einer Vielzahl von Zeitabschnitten dar, so dass sowohl aktuelle als auch zukünftige Zusammenstöße erkannt werden können.

Sobald die Daten für ein Objekt in Block 648 im Datenstrom übertragen werden, kehrt die Steuerung zu Block 642 zurück, um weitere Objekte zu verarbeiten. Sobald alle Objekte verarbeitet wurden, übergibt der Block 642 die Steuerung an Block 650, um auf die durch die Slave-Threads erzeugten Zusammenstoßdaten zu warten und diese beim Empfangen entsprechend zu verarbeiten. Wie bei der Routine 520 aus 17 können die Slave-Threads Daten zurückmelden, die angeben, (1) welche Objekte zusammengestoßen sind und (2) wann diese Zusammenstöße in dem Intervall stattgefunden haben. In Block 650 können die Slave-Threads jedoch ebenfalls eine Anforderung oder Empfehlung für eine Neuverteilung der Last zwischen den Slave-Threads zurücksenden.

Als solches übergibt der Block 650 die Steuerung an den Block 652, um zu ermitteln, ob von irgendeinem Slave-Thread eine Neuverteilung empfohlen wurde. Wenn dem nicht so ist, wird keine Neuverteilung durchgeführt, und die Routine 640 ist abgeschlossen. Wenn jedoch eine Neuverteilung empfohlen wird, wird in Block 654 eine Neuverteilung durchgeführt, um die Slave-Threads neu zuzuordnen, z.B. um zusätzliche Threads zum Bewältigen vorhergesagter zukünftiger Zusammenstöße in bestimmten Bereichen einer Szene bereitzustellen.

23 veranschaulicht als nächstes eine durch einen Slave-Thread während der Zusammenstoßerkennung ausgeführte beispielhafte Routine 660. Die Routine 660 beginnt in Block 662 mit dem Empfangen der Stromdaten von der vorherigen Stufe in der Pipeline (Master oder Slave). Der Block 664 ermittelt dann, ob der Objektdurchlauf den Bereich schneidet, dem der Thread zugewiesen ist. Wenn dem nicht so ist, wird die Steuerung an Block 666 übergeben, um die Detailstufenkomponente, den Objektdurchlauf und jegliche von vorherigen Slave-Threads erzeugten Zusammenstoßdaten an einen oder mehrere Slave-Threads in der Pipeline bzw. alternativ, falls es sich um den letzten Slave-Thread in der Pipeline handelt, zurück an den Master-Thread zur weiteren Verarbeitung im Datenstrom zu übertragen. Die Routine 660 ist dann abgeschlossen.

Sollte der Objektdurchlauf den dem Thread zugewiesenen Bereich schneiden, übergibt der Block 664 die Steuerung an Block 668, um zu ermitteln, ob der Zeitpunkt des Eintretens der Überschneidung (z.B. relativ zu dem Zeitabschnitt) früher liegt als ein gekennzeichneter Zusammenstoß, der von einem vorausgehenden Slave-Thread erkannt wurde. Wenn dem nicht so ist, würde jegliche in dem Bereich auftretende Überschneidung erst nach einem anderen Zusammenstoß eintreten, so dass es keinen Grund gibt, in diesem Thread eine weitere Zusammenstoßerkennung durchzuführen. Folglich wird die Steuerung an Block 666 übergeben.

Andernfalls wird die Steuerung an Block 670 übergeben, um eine gründliche Zusammenstoßerkennung durchzuführen, um zu ermitteln, ob sich irgendwelche Objekte (sich bewegend oder ortsfest) in dem Bereich befinden, die sich mit dem betreffenden Objekt überschneiden. Die Steuerung wird dann an Block 672 übergeben, um festzustellen, ob ein Zusammenstoß erkannt wurde. Wenn ein Zusammenstoß erkannt wird, wird die Steuerung an Block 674 übergeben, um die Zusammenstoßdaten zu aktualisieren und den Zeitpunkt und das Objekt, mit dem das betreffende Objekt zusammengestoßen ist, anzugeben. Die Steuerung wird dann an Block 666 übergeben, um die aktualisierten Zusammenstoßdaten gemeinsam mit der Detailstufenkomponente und dem Objektdurchlauf an einen oder mehrere Slave-Threads bzw. alternativ zurück an den Master-Thread mit den Ergebnissen der Zusammenstoßerkennung im Datenstrom zu übertragen.

Wenn der Block 672 jedoch keinen Zusammenstoß erkennt, wird die Steuerung an Block 676 übergeben, um zu ermitteln, ob beruhend auf der Bewegung des Objekts (wie durch den Objektdurchlauf dargestellt) in einem oder mehreren Zeitabschnitten in der Zukunft ein zukünftiger Zusammenstoß erkannt wurde. Wenn dem nicht so ist, kehrt die Steuerung zurück zu Block 666. Wenn jedoch ein zukünftiger Zusammenstoß erkannt wird, wird die Steuerung an Block 678 übergeben, um die Eigenschaften des zukünftigen Zusammenstoßes zu analysieren. Während mehrere verschiedene Eigenschaften des Zusammenstoßes wie oben erwähnt analysiert werden können, veranschaulicht die Routine 660 zwei verwandte Faktoren: ob der zukünftige Zusammenstoß mit zahlreichen Objekten einhergeht, z.B. eine Anzahl von Objekten, die einen bestimmten Schwellwert überschreitet (Block 680), und ob die Eigenschaften der zusammenstoßenden Objekte voraussichtlich eine zusätzliche Verarbeitungslast benötigen (Block 682). Wenn keiner der Faktoren gefunden wird, wird die Steuerung an Block 666 übergeben. Wenn die Feststellung jedoch positiv ist, wird die Steuerung an Block 684 übergeben, um die an die nächsten Slave-Threads bzw. an den Master-Thread im Datenstrom übertragenen Zusammenstoßdaten zu aktualisieren, um eine Neuverteilung der Last zu empfehlen. Die Steuerung wird dann an Block 666 übergeben, wodurch die Routine 660 abgeschlossen ist.

Es sei angemerkt, dass in dieser Ausführungsform Slave-Threads eine Neuverteilung empfehlen, obwohl die eigentliche Neuverteilung durch den Master-Thread verwaltet wird. In anderen Ausführungsformen kann das Ermitteln, wann eine Neuverteilung benötigt wird, und das Durchführen der eigentlichen Neuverteilung jedoch ausschließlich in einem Master-Thread, ausschließlich in einem Slave-Thread oder durch einen vollständig anderen Thread umgesetzt werden.

Deshalb kann durch Einleiten eines Arbeitsschritts zum Lastenausgleich als Reaktion auf vorhergesagte zukünftige Zusammenstöße zwischen Objekten die Zuordnung von Threads in einer Physik-Engine vor Ereignissen optimiert werden, die voraussichtlich die Arbeitslastverteilung in der Physik-Engine erheblich ändern, und als solches ist es wahrscheinlicher, dass die Physik-Engine optimal konfiguriert ist, wenn derartige Ereignisse später eintreten, d.h., wenn aktuelle Zusammenstöße erkannt werden, die den zukünftigen Zusammenstößen entsprechen.

Man wird verstehen, dass die Umsetzung eines vorausschauenden Lastenausgleichs in der hierin beschriebenen NOC-Architektur im Rahmen der Fähigkeiten eines gewöhnlichen Fachmanns mit Unterstützung der vorliegenden Darlegung läge. Außerdem wird man verstehen, dass geeignete Algorithmen zur Zuordnung und Neuzuordnung von Threads zu räumlichen Bereichen beruhend auf vorhergesagten Arbeitslasten auch im Rahmen der Fähigkeiten eines gewöhnlichen Fachmanns mit Unterstützung der vorliegenden Darlegung lägen.

IMPULSWEITERLEITUNG UNTER VERWENDUNG VON THREAD-ÜBERGREIFENDEN IMPULSNACHRICHTEN

Ausführungsformen in Übereinstimmung mit der Erfindung leiten Impulse zwischen Objekten in einer Szene weiter, indem sie thread-übergreifende Nachrichten verwenden, die zwischen Threads weitergeleitet werden, die sich gegenseitig berührende Objekte in einer Szene besitzen. Wie in 24 gezeigt können zum Beispiel sich gegenseitig berührende Objekte in einem Partikeldynamikgitter 690 dargestellt werden, in denen die sich gegenseitig berührenden Objekte 692 mit Federn 692 verbunden sind. Die Federn 692 legen physische Eigenschaften wie Verformbarkeit, Elastizität, Steifigkeit usw. eines aus den Objekten 692 gebildeten größeren Körpers fest. Sich berührende Objekte können zum Beispiel durch Federkonstanten miteinander in Verbindung stehen, welche die Elastizität zwischen den sich berührenden Objekten festlegen. Außerdem können Reißkonstanten verwendet werden, um die Kraft festzulegen, die mindestens angelegt werden muss, um eine Trennung von zwei sich berührenden Objekten zu verursachen. Ein Partikeldynamikgitter 690 kann willkürlich mit Objekten festgelegt werden, die über Federn in verschiedenen Anordnungen und Geometrien verbunden sind, um verschiedene Arten physischer Körper zu formen, z.B. Festkörper wie Ziegelsteine oder Ziegelmauern, elastische bzw. verformbare Körper wie aufgeblasene Bälle, Gewebe, strömende Medien, Flüssigkeiten, Gase, Feuer usw. Obwohl in den nachfolgend beschriebenen Ausführungsformen ein Partikeldynamikgitter verwendet wird, wird man verstehen, dass in anderen Ausführungsformen in Übereinstimmung mit der Erfindung eine große Vielfalt von anderen Datenstrukturen zur Darstellung von sich berührenden Objekten verwendet werden können, so dass die Erfindung nicht auf die Verwendung derartiger Gitter beschränkt ist.

Üblicherweise leitet ein Objekt, an das eine Kraft angelegt wird (z.B. als Ergebnis eines Zusammenstoßes mit einem anderen Objekt, das vorher nicht berührt wurde), bei der Impulsweiterleitung einen Impuls lokal durch das Objekt mit einer Geschwindigkeit weiter, die von den physischen Eigenschaften des Objekts abhängt (z.B. breitet sich eine Kraft schneller durch einen Ziegelstein als durch Gummi aus), und wenn sich der Impuls durch das Objekt hin zu einer Grenze mit einem anderen Objekt ausbreitet, werden die Richtung und die Größe der Restkraft an das andere Objekt weitergeleitet, das dann dieselben Berechnungen durchführt, um den Impuls lokal weiterzuleiten und danach, falls zutreffend, den Impuls an alle anderen Objekte weiterzuleiten, die es berührt, bis der Impuls vollständig gedämpft wurde.

Das Weiterleiten eines Impulses führt üblicherweise auch zu einer Änderung des relativen Abstands zwischen Objekten (z.B. um die Objekte zu dehnen oder zusammenzuziehen, Kräuselungen durch ein Gewebe oder über die Oberfläche eines fließenden Mediums weiterzuleiten usw.). Außerdem kann das Weiterleiten eines Impulses auch zu der Trennung von Objekten führen, wenn die Höhe des Impulses ausreicht (z.B. Zerreißen eines Gewebes oder Explodieren einer Ziegelmauer). Des Weiteren kann das Weiterleiten eines Impulses mit der Rückkehr einer Reaktionskraft zu dem ursprünglichen Objekt verbunden sein. Ein gewöhnlicher Fachmann versteht gut die bei der Impulsweiterleitung verwendeten Physikgrundlagen und Gleichungen sowie Partikeldynamikgitter und andere Arten der Darstellung der physischen Eigenschaften von Körpern.

Im Kontext der vorliegenden Darlegung kann ein „Objekt“ einen einzelnen physischen Körper darstellen (z.B. ein Geschoss, einen Ziegelstein usw.), oder wie es üblicher ist, wenn es wünschenswert ist, eine physische Umgebung genauer zu modellieren, kann es einen kleinen Teil eines physischen Körpers darstellen, so dass ein physischer Körper (z.B. ein Ziegelstein, ein Kleidungsstück usw.) durch mehrere Objekte festgelegt ist, die als sich gegenseitig berührend angesehen werden. Insbesondere in letzterem Fall, in dem physische Körper in einer Szene durch hunderte, tausende oder Millionen von Objekten dargestellt werden können, kann die Weiterleitung von Impulsen äußerst rechenintensiv sein.

Ausführungsformen der Erfindung verwenden andererseits mehrere Threads in einer Multithread-Physik-Engine, um die Arbeitslast der Impulsweiterleitung besser zu verteilen und den Gesamtdurchsatz der Physik-Engine zu verbessern. In derartigen Ausführungsformen werden Objekte als einzelnen Threads „gehörend“ angesehen, und thread-übergreifende Nachrichten werden zwischen Threads weitergeleitet, um Impulse zwischen Objekten weiterzuleiten. Wie in 25 gezeigt kann zum Beispiel eine Impulsweiterleitung in einer Schaltkreisanordnung 700 umgesetzt werden, die ein mit einem Speicherteilsystem 704 verbundenes NOC 702 enthält, die beide in dieselbe integrierte Schaltung integriert sein können oder alternativ in separaten integrierten Schaltungen umgesetzt sein können. Das NOC 702 kann die IP-Blöcke 706 enthalten, die miteinander über ein Netzwerk 708 verbunden sind, das die oben in Zusammenhang mit dem NOC 102 aus 2 erörterte Netzwerklogik enthalten kann.

Wie oben erwähnt können verschiedene Teilmengen der IP-Blöcke 706 verschiedenen Funktionalitäten zugeordnet werden, und in Verbindung mit Impulsweiterleitung können ein oder mehrere IP-Blöcke eine Physik-Engine bereitstellen, die eine Vielzahl von Impuls-Weiterleitungs-Threads 710 umfasst. Obwohl dies nicht in 25 gezeigt ist, kann eine Physik-Engine ferner andere Threads enthalten, z.B. Komponentenlade-Threads, Zusammenstoßüberwachungs-Threads, Master-Threads, Slave-Threads usw., wie oben in Zusammenhang mit den oben beschriebenen Zusammenstoßüberwachungsaspekten einer Physik-Engine beschrieben wurde.

Impulse können weitergeleitet werden, indem Impulsnachrichten zwischen Threads weitergeleitet werden, z.B. auf ähnliche Weise wie das Weiterleiten von Strahlen bei der punktweisen Betrachtung durchgeführt wird. Außerdem kann ein Partikeldynamikgitter neben anderen Arten von physischen Modellen in einer Datenstruktur wie einer ADS dargestellt werden, so dass die vorher erwähnten, oben beschriebenen Techniken zur Übertragung von Detailstufenkomponenten im Datenstrom in Zusammenhang mit Impulsweiterleitung in Übereinstimmung mit der Erfindung verwendet werden können. Des Weiteren ist die Impulsweiterleitung zur Umsetzung in einer wie oben in Verbindung mit den 14A bis 14B dargelegten Software-Pipeline geeignet, wobei Impuls-Weiterleitungs-Threads Eingänge bereitgestellt werden können, und über die Eingänge und die durch das NOC 702 unterstützte zugrundeliegende Nachrichtenweiterleitungsinfrastruktur Impulsnachrichten zwischen Threads im Datenstrom übertragen werden können.

Man wird auch verstehen, dass es in einigen Ausführungsformen wünschenswert sein kann, Threads den Besitz von Objekten auf der Grundlage der relativen Anordnung von Objekten in einer Szene zuzuweisen, z.B. so, dass sich in direktem Kontakt miteinander befindliche Objekte Threads zugewiesen werden, die einen minimalen Datenübertragungsaufwand haben, z.B. weil sie sich in demselben IP-Block oder in benachbarten IP-Blöcken befinden. In einigen Ausführungsformen können Threads auch mehrere Objekte besitzen.

Außerdem wird man verstehen, dass die Threads, die Objekte besitzen, als Software-Threads angesehen werden können, so dass eine Thread-Zeitplanung verwendet werden kann, um Software-Threads effizient verschiedenen Hardware-Ausführungs-Threads zuzuweisen, die über einen oder mehrere IP-Blöcke verteilt sind. Auf eine derartige Weise können Software-Threads, beruhend auf dem Zustand einer Szene, Hardware-Ausführungs-Threads dynamisch neu zugeordnet werden, z.B. so, dass sich berührende Objekte denselben oder benachbarten IP-Blöcken zugewiesen werden, um die Netzwerklatenzzeit für Impulsnachrichten zu minimieren. Es kann auch ein statischer oder dynamischer Lastenausgleich verwendet werden, um sicherzustellen, dass die Impulsweiterleitung wirksam gemeinsam mit anderen Aufgaben einer Physik-Engine durchgeführt wird. Des Weiteren kann es in einigen Ausführungsformen wünschenswert sein, für einen vorausschauenden Lastenausgleich die Impulsweiterleitung zusätzlich zu oder an Stelle der Zusammenstoßerkennung in Betracht zu ziehen, z.B. damit im Falle eines Geschosses, das kurz vor einer Berührung mit einer Ziegelmauer steht, ausreichend Hardware-Ressourcen verfügbar sind, um die Impulse zu bewältigen, die durch sämtliche Ziegelsteine in der Mauer weitergeleitet werden.

Man wird auch verstehen, dass Impulsweiterleitung ausführende Software-Threads auch mit der Durchführung anderer Aufgaben beschäftigt sein können, z.B. können dieselben Threads eine Zusammenstoßerkennung und Impulsweiterleitung durchführen. In anderen Fällen können Threads in Leerlauf fallen, wenn zu einem bestimmten Augenblick keine Impulse weitergeleitet werden müssen.

26 bis 28 veranschaulichen eine Art der Umsetzung von Impulsweiterleitung auf eine Weise, die mit der Erfindung übereinstimmt. 26 veranschaulicht zum Beispiel eine Initialisierungsroutine 720, die durch eine Software-Pipeline wie einen Master-Thread ausgeführt werden kann, zum Initialisieren einer Vielzahl von Impuls-Weiterleitungs-Threads zum Bewältigen der Impulsweiterleitung für eine Szene. Die Routine 720 beginnt in Block 722 mit dem Zuweisen eines Software-Thread zu jedem Objekt in einer Szene, so dass jedes Objekt einem Software-Thread gehört, und Block 724 leitet eine FÜR-Schleife zum Verarbeiten jedes derartigen Objekts ein. Zunächst werden in Block 726 die Eigenschaften des Objekts mit dem das Objekt besitzenden Software-Thread verknüpft, um dem Software-Thread die physischen Eigenschaften des Objekts zum Zwecke der Impulsweiterleitung bereitzustellen, z.B. durch Speichern von einem oder mehreren Attributen, welche die physischen Eigenschaften des Objekts darstellen, darunter zum Beispiel Federkonstanten, Reißkonstanten usw., die das Objekt mit dessen benachbarten Objekten in Verbindung bringen. Zweitens wird eine Datenstruktur wie eine Tabelle über benachbarte Objekte für den besitzenden Software-Thread mit Verknüpfungen zu allen benachbarten Objekten des sich im Besitz befindlichen Objekts gefüllt, d.h., zu allen anderen Objekte in der Szene, die das sich im Besitz befindliche Objekt berührt. Sobald alle Objekte einem Software-Thread zugewiesen wurden und die benachbarten Objekte für jedes Objekt identifiziert wurden, ist die Routine 720 abgeschlossen.

Informationen über benachbarte Objekte können in Übereinstimmung mit der Erfindung in mehreren Datenstrukturen gespeichert werden. 27 veranschaulicht zum Beispiel eine Tabelle über benachbarte Objekte 730, die eine Vielzahl von Einträgen enthält, die jeweils ein Objekt 732 und einen besitzenden Thread 734 identifizieren. Durch die Verwendung der Tabelle 730 ist ein Thread in der Lage, zu ermitteln, welche Objekte ein bestimmtes Objekt berührt, sowie die Threads, die diese Objekte besitzen, so dass der Thread in der Lage ist, Impulsnachrichten an die Threads weiterzuleiten, welche die benachbarten Objekte besitzen. Es können verschiedene Arten der Identifizierung eines Objekts und Thread verwendet werden, z.B. numerische Kennungen, Zeiger, Speicheradressen, Netzwerkadressen usw. Es können verschiedene alternative Datenstrukturen wie Verknüpfungslisten, Hash-Tabellen usw. verwendet werden, und für jedes benachbarte Objekt können in einigen Ausführungsformen zusätzliche Daten gespeichert werden, darunter zum Beispiel die verschiedenen physischen Konstanten (z.B. Federkonstanten, Reißkonstanten usw.), welche die gegenseitige physische Beeinflussung zwischen den verknüpften Objekten darstellen. Deshalb ist die Erfindung nicht auf die bestimmte Konfiguration der in 27 veranschaulichten Tabelle über benachbarte Objekte beschränkt.
28 veranschaulicht als nächstes eine Impulsweiterleitungsroutine 740, die durch einen besitzenden Software-Thread ausgeführt werden kann, um einen Impuls weiterzuleiten. Die Routine 740 wird als Reaktion auf das Empfangen eines Impulses eingeleitet und beginnt in Block 742 mit dem Ermitteln der Größenordnung und des Vektors der weitergeleiteten Kraft, die dem empfangenen Impuls zugehörig ist, was üblicherweise in der durch den Thread empfangenen Impulsnachricht bereitgestellt wird.

Der Block 744 leitet dann die Kraft durch das sich im Besitz befindliche Objekt beruhend auf den physischen Eigenschaften des Objekts weiter. Man sollte sich bewusst sein, dass die Weiterleitung des Impulses in einigen Ausführungsformen mehrere Zeitschritte dauern kann.

Als nächstes ermittelt der Block 746, ob es irgendeine Restkraft nach der Weiterleitung gibt, d.h., ob die Kraft vollständig gedämpft wurde. Wenn es eine Restkraft gibt, wird die Steuerung an Block 748 übergeben, damit eine FÜR-Schleife eingeleitet wird, um jedes benachbarte Objekt, das in der dem Objekt zugehörigen Tabelle über benachbarte Objekte identifiziert wurde, zu verarbeiten. Für jedes derartige benachbarte Objekt wird die Steuerung an Block 750 weitergeleitet, um die Größenordnung und den Vektor der an das benachbarte Objekt weitergeleiteten Kraft zu ermitteln, und dann an Block 752, damit an den Thread, der das benachbarte Objekt besitzt, eine Impulsnachricht gesendet wird.

Sobald an alle entsprechenden benachbarten Objekte Impulsnachrichten gesendet wurden, übergibt der Block 748 die Steuerung an Block 754, damit Impulsbestätigungsnachrichten von den benachbarten Objekten gesammelt werden, und dann ermittelt der Block 756 beruhend auf den Bestätigungsnachrichten eine Größenordnung und einen Vektor jeglicher Reaktionskraft. Die Steuerung wird dann an Block 758 übergeben, damit eine Impulsbestätigungsnachricht an den Thread gesendet wird, von dem die Impulsnachricht ursprünglich empfangen wurde, welche die Größenordnung und den Vektor der Reaktionskraft bereitstellt. Die Routine 740 ist dann abgeschlossen. Wenn außerdem zurück in Block 746 ermittelt wird, dass nach der lokalen Weiterleitung keine Kraft übrig bleibt, übergibt Block 746 die Steuerung direkt an Block 758, damit eine Impulsbestätigungsnachricht erzeugt und gesendet wird, die kennzeichnet, dass es keine Reaktionskraft gibt.

In der veranschaulichten Ausführungsform werden Impulsbestätigungsnachrichten unabhängig davon gesendet, ob eine Reaktionskraft zurückgemeldet wird. In anderen Ausführungsformen können jedoch Impulsbestätigungsnachrichten unterdrückt werden, wenn keine Reaktionskraft zurückgemeldet werden muss, wobei das Fehlen einer Impulsbestätigungsnachricht das Fehlen einer Reaktionskraft angibt.

Üblicherweise aktualisiert ein Zusammenstoßüberwachungsalgorithmus die Tabelle über benachbarte Objekte für jedes Objekt beruhend auf den Ergebnissen von Zusammenstößen zwischen Objekten. Folglich kann es in einigen Ausführungsformen wünschenswert sein, dass die Routine 740 immer dann einen Zusammenstoß-Erkennungs-Thread benachrichtigt, wenn als Folge einer Impulsweiterleitung die Trennung von Objekten erkannt wird, z.B. jedes Mal dann, wenn die Reißkonstante für ein Objekt von einem Impuls überschritten wird. In anderen Ausführungsformen kann die Pflege einer Tabelle über benachbarte Objekte von einem Impuls-Weiterleitungs-Thread oder von einem vollständig anderen Thread bewältigt werden.

Deshalb wird man verstehen, dass durch das Verteilen der Funktionalität der Impulsweiterleitung zwischen einer Vielzahl von Threads, die verschiedene Objekte in einer Szene besitzen, und durch das Weiterleiten von Impulsen zwischen Objekten durch die Verwendung von thread-übergreifenden Nachrichten Hardware-Ressourcen wirksam auf optimale Weise für eine bestimmte Szene und eine Anordnung von Objekten darin zugeordnet werden können, wodurch der Gesamtdurchsatz der Physik-Engine verbessert wird.

Es können verschiedene Abänderungen an den dargelegten Ausführungsformen vorgenommen werden, ohne von dem Umfang der Erfindung abzuweichen. Es kann zum Beispiel auch ein vorausschauender Lastenausgleich in Verbindung mit Impulsweiterleitung verwendet werden, um andere Hardware-Ressourcen wie Speicher, E/A-Ressourcen usw. neu zuzuordnen. Für einen Fachmann werden andere Abänderungen ersichtlich sein. Deshalb liegt die Erfindung in den nachfolgend beigefügten Ansprüchen.

Claims

Schaltkreisanordnung, die Folgendes umfasst: Network-on-Chip-Hardware-Logik, die eine Vielzahl von eine Vielzahl von Hardware-Threads festlegenden Verarbeitungskernen und ein chipintegriertes Netzwerk enthält, das die Vielzahl von Verarbeitungskernen miteinander verbindet; und eine von mindestens einem Teil der Vielzahl von Hardware-Threads ausgeführte Physik-Engine, wobei die Physik-Engine eine Multithread-Software-Pipeline enthält, die eine Vielzahl von Stufen enthält, die so konfiguriert sind, dass sie Zusammenstöße zwischen Objekten aus einer Vielzahl von Objekten in einer Szene erkennen, sowie eine Vielzahl von Impuls-Weiterleitungs-Threads enthält, die so konfiguriert sind, dass sie Impulse zwischen einer Reihe von benachbarten Objekten aus der Vielzahl von sich berührenden Objekten weiterleiten; wobei die Physik-Engine so konfiguriert ist, dass sie für jedes aus der Reihe von benachbarten Objekten den Besitz an dem Objekt einem der Vielzahl von Impuls-Weiterleitungs-Threads zuweist und eine Tabelle über benachbarte Objekte für den Impuls-Weiterleitungs-Thread erzeugt, dem das Objekt zugewiesen ist, die jedes Objekt aus der Reihe von benachbarten Objekten identifiziert, die das Objekt berührt; wobei die Physik-Engine so konfiguriert ist, dass sie als Reaktion auf einen erkannten Zusammenstoß mit einem ersten Objekt aus der Reihe von benachbarten Objekten eine erste thread-übergreifende Impulsnachricht erzeugt, die eine Größenordnung und eine Richtung enthält; wobei jeder Impuls-Weiterleitungs-Thread unter der Vielzahl von Impuls-Weiterleitungs-Threads so konfiguriert ist, dass er als Reaktion auf das Empfangen einer einem Impuls zugehörigen thread-übergreifenden Impulsnachricht den Impuls lokal durch ein Objekt weiterleitet, dessen Besitz dem Impuls-Weiterleitungs-Thread zugewiesen ist, für jedes in der Tabelle über benachbarte Objekte für den Impuls-Weiterleitungs-Thread identifizierte benachbarte Objekt eine Größenordnung und eine Richtung einer weitergeleiteten Kraft ermittelt, den Impuls für jedes in der Tabelle über benachbarte Objekte für den Impuls-Weiterleitungs-Thread identifizierte benachbarte Objekt an den Impuls-Weiterleitungs-Thread weiterleitet, indem er eine thread-übergreifende Impulsnachricht an diesen sendet, welche die dafür ermittelte Größenordnung und Richtung der weitergeleiteten Kraft enthält, eine thread-übergreifende Impulsbestätigungsnachricht von jedem benachbarten Objekt empfängt, das in der Tabelle über benachbarte Objekte für den Impuls-Weiterleitungs-Thread identifiziert wurde, eine Größenordnung und eine Richtung einer Reaktionskraft zumindest teilweise beruhend auf den thread-übergreifenden Impulsbestätigungsnachrichten ermittelt und eine thread-übergreifende Impulsbestätigungsnachricht mit der Größenordnung und Richtung der Reaktionskraft als Bestätigung für die empfangene thread-übergreifende Impulsnachricht sendet, und wobei die Physik-Engine so konfiguriert ist, dass sie als Reaktion auf das Erkennen eines zukünftigen Zusammenstoßes zwischen Objekten in einer Szene eine Neuzuordnung der Arbeitslast unter der Vielzahl von Impuls-Weiterleitungs-Threads wahlweise in Abhängigkeit von Objekteigenschaften der als zukünftig zusammenstoßend erkannten Objekten einleitet,
Verfahren zum Weiterleiten von Impulsen zwischen einer Vielzahl von Objekten in einer Szene unter Verwendung einer Multithread-Physik-Engine, wobei das Verfahren Folgendes umfasst: für jedes der Vielzahl von Objekten Zuweisen des Besitzes eines derartigen Objekts zu einem aus einer Vielzahl von Threads in der Multithread-Physik-Engine; und als Reaktion darauf, dass ein Impuls durch ein erstes Objekt unter der Vielzahl von Objekten empfangen wird: lokales Weiterleiten des Impulses durch das erste Objekt unter Verwendung eines ersten Thread unter der Vielzahl von Threads, dem der Besitz an dem ersten Objekt zugewiesen wurde; und Weiterleiten des Impulses an mindestens ein zusätzliches Objekt unter der Vielzahl von Objekten, welches das erste Objekt berührt, durch Senden einer thread-übergreifenden Nachricht von dem ersten Thread an einen zweiten Thread unter der Vielzahl von Threads, dem der Besitz an dem zusätzlichen Objekt zugewiesen wurde, wobei die Vielzahl von Threads eine Vielzahl von Impuls-Weiterleitungs-Threads enthält, die Multithread-Physik-Engine mindestens einen Zusammenstoß-Erkennungs-Thread enthält, und das Verfahren das wahlweise Einleiten einer Neuzuordnung der Arbeitslast unter der Vielzahl von Impuls-Weiterleitungs-Threads als Reaktion auf das Erkennen eines zukünftigen Zusammenstoßes zwischen Objekten in einer Szene in Abhängigkeit von Objekteigenschaften der als zukünftig zusammenstoßend erkannten Objekten umfasst.
Verfahren nach Anspruch 2, bei dem das erste Objekt eine Vielzahl von benachbarten Objekten berührt, und bei dem das Weiterleiten des Impulses für jedes der Vielzahl von benachbarten Objekten das Senden einer thread-übergreifenden Nachricht von dem ersten Thread an einen Thread unter der Vielzahl von Threads enthält, dem der Besitz an dem benachbarten Objekt zugewiesen wurde.
Verfahren nach Anspruch 2, bei dem das Objekt mindestens ein einer physischen Eigenschaft des Objekts zugehöriges Attribut enthält, und bei dem das lokale Weiterleiten des Impulses durch das erste Objekt das Zugreifen auf das Attribut für das erste Objekt enthält, um die Weiterleitung eines Impulses durch das erste Objekt zu simulieren.
Verfahren nach Anspruch 2, bei dem das Weiterleiten des Impulses an das zusätzliche Objekt das Zugreifen auf eine physische Konstante enthält, die einer physischen Beziehung zwischen dem ersten und dem zusätzlichen Objekt zugehörig ist, um eine Größenordnung und Richtung einer Kraft zu ermitteln, wobei die thread-übergreifende Nachricht die ermittelte Größenordnung und Richtung der Kraft enthält.
Verfahren nach Anspruch 5, bei dem die physische Konstante mindestens eine Federkonstante und/oder eine Reißkonstante enthält.
Verfahren nach Anspruch 2, bei dem das lokale Weiterleiten des Impulses als Reaktion auf eine zweite thread-übergreifende Nachricht eingeleitet wird, die durch den ersten Thread empfangen wurde, wobei die zweite thread-übergreifende Nachricht eine dem Impuls zugehörige Größenordnung und Richtung enthält, und bei dem das lokale Weiterleiten des Impulses das Ermitteln enthält, ob eine Restkraft verbleibt, die an das zusätzliche Objekt weiterzuleiten ist, so dass der Impuls nur dann an das zusätzliche Objekt weitergeleitet wird, wenn eine Restkraft verbleibt.
Verfahren nach Anspruch 7, das ferner das Ermitteln einer Reaktionskraft und das Senden einer thread-übergreifenden Nachricht mit der ermittelten Reaktionskraft als eine Bestätigung für die zweite thread-übergreifende Nachricht umfasst.
Verfahren nach Anspruch 8, das ferner das Empfangen einer dritten thread-übergreifenden Nachricht von dem zweiten Thread als Bestätigung für die erste thread-übergreifende Nachricht in dem ersten Thread umfasst, wobei die dritte thread-übergreifende Nachricht eine zweite Reaktionskraft enthält, wobei das Ermitteln der ersten Reaktionskraft zumindest teilweise auf der zweiten Reaktionskraft beruht.
Verfahren nach Anspruch 2, das ferner das Ermitteln einer Reihe von benachbarten Objekten für das erste Objekt umfasst, die das erste Objekt in der Szene berührt, und das Erzeugen einer Datenstruktur über benachbarte Objekte umfasst, welche die Reihe von benachbarten Objekten identifiziert, wobei der erste Thread so konfiguriert ist, dass er auf die Datenstruktur über benachbarte Objekte zugreift, um zu ermitteln, an welche Objekte unter der Vielzahl von Objekten der Impuls weitergeleitet werden sollte.
Verfahren nach Anspruch 2, bei dem die Multithread-Physik-Engine eine Multithread-Software-Pipeline umfasst, die eine Vielzahl von Hardware-Threads verwendet, wobei die Multithread-Software-Pipeline eine Vielzahl von Stufen enthält, die so konfiguriert sind, dass sie Zusammenstöße zwischen Objekten in einer Szene erkennen, wobei die Vielzahl von Stufen mindestens eine Komponentenladestufe, eine Vielzahl von der Vielzahl von Hardware-Threads zugewiesenen Zusammenstoßerkennungsstufen und eine Vielzahl von Impuls-Weiterleitungs-Threads enthält.
Verfahren nach Anspruch 2, bei dem die Multithread-Physik-Engine in Network-on-Chip-Hardware-Logik umgesetzt ist, die eine Vielzahl von eine Vielzahl von Hardware-Threads festlegenden Verarbeitungskernen und ein die Vielzahl von Verarbeitungskernen miteinander verbindendes chipintegriertes Netzwerk enthält, und bei dem die thread-übergreifenden Nachrichten unter Verwendung des chipintegrierten Netzwerks zwischen Hardware-Threads ausgetauscht werden.
Schaltkreisanordnung, die Folgendes umfasst: eine Hardware-Multithread-Physik-Engine; und Programmcode, der zumindest einen Teil einer Multithread-Physik-Engine umsetzt, wobei der Programmcode so konfiguriert ist, dass er Impulse zwischen einer Vielzahl von Objekten in einer Szene weiterleitet, wobei der Programmcode so konfiguriert ist, dass er für jedes der Vielzahl von Objekten einem aus einer Vielzahl von Threads in der Multithread-Physik-Engine den Besitz des Objekts zuweist, wobei der Programmcode ferner so konfiguriert ist, dass er als Reaktion auf einen durch ein erstes Objekt unter der Vielzahl von Objekten empfangenen Impuls den Impuls lokal durch das erste Objekt unter Verwendung eines ersten Thread unter der Vielzahl von Threads weiterleitet, dem der Besitz des ersten Objekts zugewiesen wurde, und den Impuls an mindestens ein weiteres Objekt unter der Vielzahl von Objekten weiterleitet, welches das erste Objekt berührt, indem er eine thread-übergreifende Nachricht von dem ersten Thread an einen zweiten Thread unter der Vielzahl von Threads sendet, dem der Besitz an dem zusätzlichen Objekt zugewiesen wurde, wobei die Vielzahl von Threads eine Vielzahl von Impuls-Weiterleitungs-Threads enthält, die Multithread-Physik-Engine mindestens einen Zusammenstoß-Erkennungs-Thread enthält, und der Programmcode ferner so konfiguriert ist, dass er als Reaktion auf das Erkennen eines zukünftigen Zusammenstoßes zwischen Objekten in einer Szene eine Neuzuordnung der Arbeitslast unter der Vielzahl von Impuls-Weiterleitungs-Threads wahlweise in Abhängigkeit von Objekteigenschaften der als zukünftig zusammenstoßend erkannten Objekten einleitet.
Integrierte Schaltkreiseinheit, welche die Schaltkreisanordnung nach Anspruch 14 enthält.
Programmprodukt, das ein nichtflüchtiges durch einen Computer lesbares Medium und sich auf dem nichtflüchtigen durch einen Computer lesbaren Medium befindlichen Logikdefinitions-Programmcode enthält, der die Schaltkreisanordnung nach Anspruch 14 festlegt.