-
QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
-
Diese Anmeldung beansprucht die Priorität der vorläufigen US-Patentanmeldung mit der Nummer 62/051,183, die am 16. September 2014 eingereicht wurde, und die hiermit in ihrer Gesamtheit mit eingeschlossen ist.
-
HINTERGRUND DER ERFINDUNG
-
Rechensysteme haben einen wesentlichen Beitrag zur Entwicklung der modernen Gesellschaft geleistet und werden in einer Reihe von Anwendungen eingesetzt, um vorteilhafte Ergebnisse zu erreichen. Zahlreiche Geräte, etwa Personalcomputer (PC) als Tischrechner, Tragbarer PCs, Tablett-PCs, Netzbuch-Rechner, intelligente Telefone, Dienstleistungsrechner und dergleichen haben eine erhöhte Produktivität und reduzierte Kosten bei der Übermittlung und Analyse von Daten in den meisten Gebieten der Unterhaltung, Erziehung, der Geschäftswelt und der Wissenschaft ermöglicht. Ein Aspekt von Rechensystemen ist die Anwendungsprogrammierschnittstelle (API), die eine Gruppe von Routinen, Protokollen und Werkzeugen ist, die Funktionen definieren, die von der jeweiligen Implementierung unabhängig sind, um eine Anwendung aufzubauen, zwischen Anwendungen zu kommunizieren und/oder um auf Hardware-Ressourcen eines Rechensystems zu zugreifen.
-
In konventionellen APIs binden/hängen Anwendungen Ressourcen, etwa Texturen und Bilderzeugungsziele, an einen Kontext. Der Treiber verfolgt alle diese Anhänge, um die Abhängigkeiten zu verstehen und um „Wartephasen dafür” (WSIs), Cache-Speicher-Validierungen und dergleichen nach Bedarf einzufügen. Der Aufwand zur Verfolgung dieser Anhänge ist einer der wesentlichen Engstellen in einer zentralen Recheneinheit (CPU) in dem System. In jüngeren APIs gibt es einen Wunsch, die Bindung von Ressourcen zu vermeiden. In APIs ohne Bindung spezifiziert die Anwendung „Ressourcenübergänge” auf Objekte, wenn sich ihre Verwendung ändert, etwa das Umschalten von einer Bilderzeugung zu einer Textur, um daraus eine Textur zu bilden. Dies liefert die gleiche Information wie die Bindungen in älteren APIs mit Ausnahme von separaten/expliziten Befehlen anstelle von impliziten als Nebeneffekt des Bindens. Diese Vorgehensweise funktioniert, obwohl in unbeholfener Weise, für die Synchronisierung und die Cache-Speicher-Steuerung, es mangelt dabei aber an Kachelbildungsinformation und dergleichen. Sie ist auch für Anwendungen mühsam, die manchmal Übergänge auf hunderte von Objekten anwenden müssen, um eine einzelne „Abhängigkeit” zu spezifizieren. Die nicht in der Reihenfolge vorliegende Art von Arbeitsspezifizierungen gegenüber der Arbeitsausgabe (über Befehlspuffer-Aufzeichnung/Abrufung) kompliziert die konventionellen Systeme ohne Bindungen noch weiter. Daher gibt es einen fortgesetzten Bedarf für verbesserte APIs ohne Bindungen.
-
ÜBERBLICK ÜBER DIE ERFINDUNG
-
Die vorliegende Technik kann am besten verstanden werden, indem auf die folgende Beschreibung und die begleitenden Zeichnungen Bezug genommen wird, die verwendet werden, um Ausführungsformen der vorliegenden Technik darzustellen, die sich an Techniken zur Weiterleitung bzw. Übermittlung von Abhängigkeiten in APIs richten.
-
In einer Ausführungsform umfassen die Techniken Ermitteln bzw. Erkennen von mehreren Weiterleitungen bzw. Übermittlungen von empfangenen Befehlen. Die empfangenen Befehle können Bilderzeugungsbefehle für die Ausführung durch eine oder mehrere Ausführungseinheiten einer Graphikverarbeitungseinheit (GPU) umfassen. Für jede Gruppe von Übermittlungen, wobei eine erste Übermittlung der Gruppe eine Zielübermittlung und eine zweite Übermittlung der Gruppe eine Ursprungsübermittlung ist, werden eine oder mehrere Abhängigkeiten zwischen den Befehlen der Zielübermittlung und der Ursprungsermittlung ermittelt. Die ermittelten Abhängigkeiten können eine oder mehrere Abhängigkeitsarten sein, einschließlich von Ausführungsabhängigkeiten, Cache-Speicher-Abhängigkeiten, Kachelbildungsabhängigkeiten und dergleichen. Es werden dann Übermittlungsobjekte für jede ermittelte Übermittlung erzeugt. Jedes Übermittlungsobjekt zeichnet die Befehle und Abhängigkeiten zwischen der entsprechenden Zielübermittlung und Ursprungsübermittlung auf. Daraufhin werden die Befehle der mehreren Übermittlungsobjekte zur Ausführung gemäß dem entsprechenden Übermittlungsobjekt ausgegeben.
-
Dieser Überblick wird bereitgestellt, um eine Auswahl von Konzepten in vereinfachter Form einzuführen, die nachfolgend in der detaillierten Beschreibung dargelegt sind. Dieser Überblick beabsichtigt nicht, Schlüsselmerkmale oder wesentliche Merkmale des beanspruchten Gegenstands anzugeben, und es ist auch nicht beabsichtigt, damit den Schutzbereich des beanspruchten Gegenstands zu beschränken.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
Ausführungsformen der vorliegenden Technik sind anhand von Beispielen und nicht durch Beschränkungen in den Figuren der begleitenden Zeichnungen dargestellt, in denen gleiche Bezugszeichen ähnliche Elemente bezeichnen, und in denen:
-
1 eine Blockansicht einer anschaulichen Recheneinrichtung zur Implementierung von Ausführungsformen der vorliegenden Technik zeigt.
-
2 ein Flussdiagramm eines Verfahrens zur Übermittlung von Abhängigkeiten in einer Anwendungsprogrammierschnittstelle (API) gemäß Ausführungsformen der vorliegenden Technologie zeigt.
-
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
-
Es sei nun detailliert auf die Ausführungsformen der vorliegenden Technik verwiesen, wovon Beispiele in den begleitenden Zeichnungen dargestellt sind. Obwohl die vorliegende Technik in Verbindung mit diesen Ausführungsformen beschrieben ist, ist zu beachten, dass sie nicht beabsichtigen, die Erfindung auf diese Ausführungsformen einzuschränken. Vielmehr beabsichtigt die Erfindung, Alternativen, Modifizierungen und Äquivalente abzudecken, die innerhalb des Schutzbereichs der Erfindung liegen, wie sie durch die angefügten Patentansprüche definiert ist. Des Weiteren sind in der folgenden detaillierten Beschreibung der vorliegenden Technik zahlreiche spezielle Details angegeben, um ein gründlicheres Verständnis der vorliegenden Technik zu ermöglichen. Jedoch ist zu beachten, dass die vorliegende Technik auch ohne diese speziellen Details praktiziert werden kann. In anderen Fällen sind gut bekannte Verfahren, Prozeduren, Komponenten und Schaltungen nicht detailliert beschrieben, um nicht in unnötiger Weise Aspekte der vorliegenden Technik zu verdunkeln.
-
Einige der folgenden Ausführungsformen der vorliegenden Technik sind anhand von Routinen, Modulen, Logikblöcken und anderen symbolischen Darstellungen von Operationen an Daten innerhalb einer oder mehreren elektronischen Einrichtungen präsentiert. Die Beschreibungen und Darstellungen sind diejenigen Mittel, die vom Fachmann verwendet werden, um in höchst effizienter Weise seine Arbeit anderen Fachleuten zu vermitteln. Eine Routine, ein Modul, ein Logikblock und/oder dergleichen ist hierin und auch allgemein als eine selbstkonsistente Abfolge von Prozessen oder Befehlen zu verstehen, die zu einem gewünschten Ergebnis führt. Die Prozesse sind solche, die physikalische Manipulationen von physikalischen Größen umfassen. Für gewöhnlich, ohne dass dies jedoch erforderlich ist, nehmen diese physikalischen Manipulationen die Form elektrischer oder magnetischer Signale an, die in einer elektronischen Einrichtung gespeichert, übertragen, verglichen oder anderweitig verarbeitet werden können. Aus Gründen der Bequemlichkeit im Hinblick auf die übliche Verwendung werden diese Signale als Daten, Bits, Werte, Elemente, Symbole, Zeichen, Terme, Zahlen, Zeichenfolgen und/oder dergleichen mit Bezug zu Ausführungsformen der vorliegenden Technik bezeichnet.
-
Es sollte jedoch bedacht werden, dass alle diese Begriffe so zu verstehen sind, dass sie sich auf physikalische Manipulationen und Größen beziehen und lediglich bequeme Namen sind, die weiterhin im Hinblick auf Terme zu interpretieren sind, die üblicherweise in diesem Bereich verwendet werden. Sofern nicht anderweitig aus der folgenden Diskussion zu entnehmen ist, ist zu beachten, dass in den Erläuterungen der vorliegenden Technik Erklärungen, die Begriffe verwenden, etwa „empfangen” und/oder dergleichen, Aktionen und Prozesse einer elektronischen Einrichtung bezeichnen, etwa einer elektronischen Recheneinrichtung, die Daten manipuliert und transformiert. Die Daten sind als physikalische (beispielsweise elektronische) Größen innerhalb der Logikschaltungen, Register, Speicher und/oder dergleichen der elektronischen Einrichtung dargestellt und werden in andere Daten transformiert, die in ähnlicher Weise als physikalische Größen in der elektronischen Einrichtung repräsentiert sind.
-
In dieser Anmeldung soll die Verwendung einer disjunkten Verknüpfung auch die verbindende Verknüpfung umfassen. Die Verwendung eines bestimmten oder unbestimmten Artikels soll nicht eine Reihenfolge angeben. Insbesondere soll ein Verweis auf „das” Objekt oder „ein” Objekt auch eines von möglichen mehreren derartigen Objekten bezeichnen. Ferner ist zu beachten, dass die Begriffe und Terminologie, wie sie hierin verwendet sind, dem Zwecke der Beschreibung dienen und nicht als Einschränkung betrachtet werden sollen.
-
Gemäß 1 ist eine anschauliche Recheneinrichtung zum Implementieren von Ausführungsformen der vorliegenden Technik gezeigt. Die Recheneinrichtung 100 kann ein Personalcomputer, ein tragbarer Computer, ein Tablett-Computer, ein intelligentes Telefon, eine Spielekonsole, ein Dienstleister-Computer bzw. ein Server-Computer, ein Klient-Computer, ein verteiltes Computersystem oder dergleichen sein. Die Recheneinrichtung 100 enthält eine oder mehrere zentrale Recheneinheiten (CPU) 110, eine oder mehrere spezialisierte Verarbeitungseinheiten, etwa grafische Verarbeitungseinheiten (GPU) 115, ein oder mehrere von einer Recheneinrichtung lesbare Medien 120, 125, 130 und eine oder mehrere Eingabe/Ausgabe-(I/O-)Einrichtungen 135, 140, 145, 150. Die I/O-Einrichtung 135, 140, 145, 150 kann einen Netzwerkadapter (beispielsweise Ethernet-Karte), ein CD-Laufwerk, ein DVD-Laufwerk und/oder dergleichen sowie Peripheriegeräte, etwa eine Tastatur, eine Zeigereinrichtung, einen Lautsprecher, einen Drucker und/oder dergleichen umfassen.
-
Die von einer Recheneinrichtung lesbaren Medien 120, 125, 130 können als primärer Speicher und sekundärer Speicher eingestuft werden. Generell stellt der sekundäre Speicher, etwa ein Magnetspeicher und/oder optischer Speicher, einen nicht-flüchtigen Speicherplatz für computerlesbare Befehle und Daten zur Verwendung durch die Recheneinrichtung 100 bereit. Beispielsweise kann das Diskettenlaufwerk 125 das Betriebssystem (OS) 155 und Anwendungen und Daten 160 speichern. Der primäre Speicher, etwa der Systemspeicher 130 und/oder der Grafikspeicher 130, stellt flüchtigen Speicherplatz für computerlesbare Befehle und Daten zur Verwendung durch die Recheneinrichtung 100 bereit. Beispielsweise kann der Systemspeicher 130 einen Teil des Betriebssystems 155' und einen Teil einer oder mehrerer Anwendungen und zugehöriger Daten 160', die aktuell von der CPU 110, GPU 115 und dergleichen verwendet werden, temporär speichern.
-
Die von einer Recheneinrichtung lesbaren Medien 120, 125, 130, die I/O-Einrichtungen 135, 140, 145, 150 und die GPU 115 können kommunizierend mit dem Prozessor 110 durch einen Chipsatz 165 und einen oder mehrere Busse verbunden sein. Der Chipsatz 165 dient als ein einfacher Eingabe/Ausgabe-Knoten für die Übermittlung von Daten und Befehle zwischen dem Prozessor 110 und den von einer Recheneinrichtung lesbaren Medien 120, 125, 130, den I/O-Einrichtungen 135, 140, 145, 150 und der GPU 115. In einer Implementierung umfasst der Chipsatz 165 eine Nordbrücke 170 und eine Südbrücke 175. Die Nordbrücke 170 stellt die Kommunikation mit dem Prozessor 110 und Interaktion mit dem Systemspeicher 115 bereit. Die Südbrücke 175 stellt Eingabe/Ausgabe-Funktionen bereit.
-
Ein üblicher Aspekt der Abarbeitung der Software, die auf der Hardware der Recheneinrichtung 100 ausgeführt wird, sind Anwendungsprogrammierschnittstellen (API). Während der Ausführung von Befehlen gibt es eine große Anzahl an Abhängigkeiten, die die korrekte Ausführung der Anwendungen steuern. Die API muss einen Mechanismus bereitstellen, um Information über die Abhängigkeiten für die Ausführung der Befehle zu übermitteln bzw. übergeben.
-
Es sei nun auf 2 verwiesen, in der ein Verfahren zur Übermittlung von Abhängigkeiten in einer Anwendungsprogrammierschnittstelle (API) gemäß Ausführungsformen der vorliegenden Technik gezeigt ist. Das Verfahren kann als von einer Recheneinrichtung ausführbare Befehle (beispielsweise ein Computerprogramm) implementiert werden, die in von einer Recheneinrichtung lesbare Medien (beispielsweise Computerspeicher) gespeichert und von einer Recheneinrichtung (beispielsweise Prozessor) ausgeführt werden.
-
Das Verfahren beginnt mit dem Empfangen von Ausführungsbefehlen bei 210. Die Ausführungsbefehle umfassen in einer Implementierung Bilderzeugungsbefehle für die Ausführung durch eine oder mehrere Ausführungseinheiten einer oder mehrerer grafischer Verarbeitungseinheiten oder zentraler Recheneinheiten. Bei 220 werden mehrere Übermittlungen für die empfangenen Ausführungsbefehle ermittelt bzw. erkannt. Bei 230 werden für jede Gruppe aus Übermittlungen, wobei eine Übermittlung die Zielübermittlung und die andere Übermittlung die Ursprungsübermittlung relativ zueinander sind, eine oder mehrere Abhängigkeiten aus einer oder mehreren Abhängigkeitsarten zwischen der gegebenen Zielübermittlung und ihrer entsprechenden Ursprungsübermittlung ermittelt. Die Abhängigkeitsarten können Ausführungsabhängigkeiten, Cache-Speicher-Abhängigkeiten, Kachelbildungs-Abhängigkeiten und dergleichen einschließen. Bei 240 wird für jede ermittelte Übermittlung ein Übermittlungsobjekt erzeugt. Die Übermittlungsobjekte zeichnen die Ausführungsbefehle und Abhängigkeiten zwischen der entsprechenden gegebenen Übermittlung und ihrer jeweiligen Ursprungsübermittlung auf. Die Abhängigkeiten können durch eine Ursprungsmaske, Zielmaske, eine Löschmaske, eine Invalidierungsmaske und dergleichen spezifiziert sein. Bei 250 werden die Bilderzeugungsbefehle für die Übermittlungsobjekte zur Ausführung entsprechend dem jeweiligen Übermittlungsobjekt ausgegeben.
-
Eine Übermittlung enthält den Zustand des Bilderzeugungsziels, das den Bildspeicher enthält, in den Ergebnisse geschrieben werden, und die Bilderzeugungsbefehle, die den Bildinhalt erzeugen. Die Abhängigkeiten zwischen den Übermittlungen besteht darin, wie die API ausdrückt, was erforderlich ist, um die Ursprungsabhängigkeit abzuschließen, bevor mit der Verarbeitung in der Übermittlung begonnen wird, die das Ziel der Abhängigkeiten ist.
-
In einem Beispiel kann eine erste Übermittlung (Ursprung) eine Bilderzeugung einer Textur in ihr Bilderzeugungsziel sein, während eine zweite Übermittlung (Ziel) die Texturerzeugung in einer Fragmentschattierungseinheit aus der Textur des Bilderzeugungsziels der Ursprungsübermittlung ist, die in ihr eigenes Bilderzeugungsziel schreibt. Die Abhängigkeiten würden daher angeben, dass die Ursprungsübermittlung alle ihre Schreiboperationen in ihr Bilderzeugungsziel abschließen muss, bevor die Zielübermittlung die Fragmentschattierung beginnt. Ferner gibt eine Abhängigkeit in einer Implementierung, die in einer oder mehreren Leerungsmasken enthalten ist, an, dass wenn Rückspeicheroperationen in der Ursprungsübermittlung angewendet werden, dann die Daten auf einmal in den Speicher übertragen bzw. geleert werden müssen. In ähnlicher Weise gibt eine Abhängigkeit, die in einer Implementierung in einer oder mehreren Invalidierungsmasken enthalten ist, an, dass, wenn ein oder mehrere Cache-Speicher für Leseoperationen in der Zielübermittlung verwendet werden, der Cache-Speicher auf ungültig gesetzt werden muss.
-
Bilderzeugungsübermittlungen können an Bilddaten von 1000×1000 Pixel bzw. Bildelementen operieren. Die Daten können in kleine Kacheln von etwa beispielsweise 100×100 Pixel aufgeteilt werden. In einem derartigen Falle ist es wünschenswert, die Zeichenbefehle für eine gegebene Kachel in dem Befehlsblock so zu gruppieren, dass die Daten lokal in der Verarbeitungseinheit zwischengespeichert werden können, um Leseoperationen und/oder Schreiboperationen zum Speicher für entsprechende Ursprungs- und Zielübermittlungen zu reduzieren oder zu vermeiden. Wenn die Art der Abhängigkeit so ist, dass jedes Pixel in der zweiten Übermittlung nur von einem entsprechenden Pixel in der ersten Übermittlung abhängt, wird der Rand zwischen den beiden Übermittlungen als eine Kachelgrenze betrachtet und die beiden Übermittlungen werden als in Kacheln einteilbar erachtet. Daher können relevante Befehle ausgegeben und ausgeführt werden in einer Reihenfolge pro Kachel, und die Abhängigkeiten zwischen den Übermittlungen geben an, dass sie in Kacheln einteilbar sind.
-
Auf der Grundlage des zuvor beschriebenen Verfahrens kann die Abhängigkeitsinformation in drei Konzepte eingestuft werden: Ausführungsabhängigkeiten, Cache-Speicher-Abhängigkeiten und Kachelbildungs-Abhängigkeiten. Keines der Abhängigkeitskonzepte erfordert eine Zustandsverfolgung pro Ressource. Die Übermittlungsobjekte und die Abhängigkeiten können als ein direkter azyklischer Graf konzeptionell ausgedrückt werden. Die Übermittlungsobjekte und Abhängigkeiten bilden eine partielle Reihenfolge derart, dass eine Ansammlung von Befehlen in einer geordneten Abfolge ausgeführt werden muss. Obwohl nicht in Beziehung stehende Übermittlungen vorteilhaft weiterhin ausgeführt werden können, werden Abhängigkeiten zwischen anderen Übermittlungen verarbeitet.
-
Gemäß Ausführungsformen der vorliegenden Technik werden Bilderzeugungsübermittlungen in Übermittlungsobjekte gekapselt. Übermittlungsobjekte spezifizieren ihre Abhängigkeiten von anderen Übermittlungen und ein Teil der Spezifizierung dieser Abhängigkeit besteht darin, Ausführungs- und Cache-Speicher-Abhängigkeiten von den abhängigen Übermittlungen anzugeben. In einer Implementierung verwenden die Ausführungs- und Cache-Speicher-Abhängigkeiten eine neuartige Erweiterung des glMemoryBarrier-Befehls, einschließlich eines mehr ganzheitlichen Cache-Speicher-Modells. Das Übermittlungsobjekt dient auch als ein Platz, um Information über gekachelte Cache-Speicher-Interaktionen mit vorhergehenden Übermittlungen zu sammeln, und insbesondere um eine gekachelte Zwischenspeicherung für Mehrfach-Übermittlungen sowie eine kachelspezifische Zwischenspeicherung einer Mischung aus Grafik und Rechnung zu ermöglichen.
-
Ein wesentlicher Gestaltungsunterschied zwischen Ausführungsformen der vorliegenden Technik und früheren APIs, etwa wie OpenGL, besteht darin, dass Ausführungsformen der vorliegenden Technik, im Weiteren hierin als RAD bezeichnet, eine explizitere Kontrolle der Anwendungen in Bezug auf Gefährdungen und Abhängigkeiten zwischen Bilderzeugungsübermittlungen benötigen. Da ein erstes Ziel der API darin besteht, Zustands- und Anbindungs-Änderungen direkt für die GPU ohne CPU/Treiber-Eingriff bereitzustellen, gibt es eine zentrale Verteilungseinheit mit Kenntnis darüber, wie Ressourcen verwendet worden sind und wie sich diese Verwendung ändert, nicht mehr, so dass sich RAD darauf stützen muss, dass die Anwendung dieser Informationen in gewisser Weise bereitstellt. Insbesondere schließen die wesentlichen Funktionen, die ersetzt werden müssen, mit ein:
- – Ausführungsabhängigkeiten: verstehen, welcher Arbeitsanteil abgeschlossen werden muss, bevor ein späterer Arbeitsanteil beginnen kann;
- – Cache-Speicher-Leerung und Ungültigsetzung: sicherstellen, dass das nicht-kohärente Cache-Speicher geleert bzw. gelöscht werden oder als ungültig gesetzt werden, wenn neue Daten in eine Ressourcen geschrieben werden;
- – Dekomprimierung: Auflösen einer komprimierten Oberfläche, die zu dekomprimieren ist, wenn auf sie durch eine Hardware-Einheit zugegriffen wird, die keine Komprimierung unterstützt;
- – Kachelbildung: Ausdrücken von Abhängigkeiten zwischen Bilderzeugungsübermittlungen in einer Weise, die es ermöglicht, dass eine oder mehrere Übermittlungen pro Kachel erneut ausgeführt werden, um die Bandbreite des Chip-externen Speichers zu optimieren.
-
Diese vier Funktionen werden häufig gleichzeitig während eines Bilderzeugungsalgorithmus benötigt und erfordern ähnliche Informationen, so dass eine signifikante Überlappung in den Operationen auftritt, die für die Bereitstellung dieser Information für den Treiber verwendet werden.
-
Es sei ein einfaches Beispiel betrachtet – Bilderzeugung in eine Textur, um anschließend daraus in einer Fragmentschattierungseinheit eine Oberfläche zu bilden. Die Ausführungsabhängigkeit besteht darin, dass die Schreiboperationen des Bilderzeugungsziels in der ersten Übermittlung abgeschlossen sein müssen, bevor weitere Fragmentierungsarbeit begonnen wird. Wenn Schreiboperationen des Bilderzeugungsziels durch Rückschreibung im Cache-Speicher gespeichert werden, muss ein derartiger Cache-Speicher gelöscht werden, und wenn Daten aus dem Bilderzeugungsziel zuvor in einem Textur-Cache-Speicher zwischengespeichert wurden, muss ein derartiger Cache-Speicher auf ungültig gesetzt werden. Wenn die Textureinheit den Zugriff auf dieses Bilderzeugungsziel in komprimierter Weise nicht unterstützt, muss dieser komprimiert werden. Schließlich muss der Treiber wissen, ob die zweite Bilderzeugungsübermittlung pro Kachel zusammen mit der ersten Übermittlung ausgeführt werden kann, was davon abhängt, welche Texturelemente des Bilderzeugungsziels von welchem Pixel der zweiten Übermittlung ausgelesen werden.
-
Von diesen vier Funktionen operiert die Dekomprimierung auf einem spezifischen Objekt, so dass sie unterschiedlich zum Rest zu handhaben ist. Wenn eine Textur erzeugt wird, spezifiziert die Anwendung, mit welchen Zugriffsarten sie zu verwenden ist, über den Befehl radTextureAccess (früher dokumentiert). Dies ermöglicht es dem Treiber, den Speicher für Komprimier-Ressourcen zuzuweisen, wenn eine Zugriffsart von der Komprimierung profitieren würde. Eine Anwendung kann auch dazu optieren, explizit die Dekomprimierung zu steuern, indem der folgende Befehl oder Zuweisung von Speicher aufgerufen wird mit <enable> = RAD_TRUE:
void radTextureCompressionControl(RADtexture texture, RADboolean enable);
-
Nachdem der Speicher zugewiesen ist, kann die Anwendung dann abfragen, ob Format und Art der Textur eine manuelle Dekomprimierung erfordern, wenn sie von speziellen Zugriffsarten verwendet wird. Wenn eine Textur die Komprimier-Steuerung aktiviert hat, dann ist die Anwendung für die Dekomprimierung des Speichers nach Bedarf verantwortlich, wobei der Befehl verwendet wird:
void radDecompressTexture(RADtexture texture, RADuint level,
RADuint xoffset, RADuint yoffset, RADuint zoffset,
RADsizei width, RADsizei height, RADsizei depth);
-
Wenn eine Textur die Komprimier-Steuerung deaktiviert hat, dekomprimiert der Treiber automatisch den Speicher jedes Mal, wenn seine Zuordnung als ein Bilderzeugungsziel aufgehoben wird. (Beachte: dies setzt voraus, dass die Bilderzeugung der hauptsächliche Weg ist, mit welchem der Speicher komprimiert wird. Wenn dies nicht der Fall ist, kann der Treiber gegebenenfalls eine manuelle explizite Dekomprimier-Steuerung erfordern, um eine Komprimierung für die Textur zuzuweisen).
-
Vor dem Definieren einer Cache-Speicher-InvValidierungs-Schnittstelle ist es wichtig, ein mentales Modell zu haben, das die Cache-Speicher-Hierarchie definiert, mit dem eine beliebige Schnittstelle bewertet werden kann.
- – Jede Zugriffsart kann einen nicht-kohärenten und möglicherweise verteilten L1-Cache-Speicher (verteilt, um näher an der Schattierungseinheit oder einer anderen Verarbeitungseinheit zu sein). Wenn die Zugriffsart nur-lesen (Textur, uniformer Puffer) ist, dann ist der Cache-Speicher nur-lesend. Wenn die Zugriffsart beschreibbar ist (SSPO, Bild, Bilderzeugungsziel), kann der Cache-Speicher schreibend oder durchschreibend sein. Mehrere Zugriffsarten können in einigen Implementierungen einen einzigen Cache-Speicher gemeinsam nutzen. Aufgrund der Lokalität mit einem Prozessor könnten gegebenenfalls L1-Cache-Speicher nur mittels der Warteschlange als ungültig setzbar sein, die die Cache-Speicher-Einträge erzeugt.
- – Alle GPU-Zugriffe können einen kohärenten L2-Cache-Speicher gemeinsam nutzen. Dieser Cache-Speicher, wenn er besteht, muss kohärent zwischen allen GPU-Zugriffen sein, muss aber nicht kohärent zwischen der CPU und der GPU sein. Kohärent bedeutet in diesem Falle, dass Schreiboperationen von beliebigen GPU-Zugriffen in eine beliebige Einheit der GPU von anderen GPU-Zugriffen auf eine beliebige Einheit der GPU gesehen werden, wobei angenommen wird, dass die Schreiboperation in dem L2-Cache-Speicher angekommen ist und dass die Leseoperation keinen alten L1-Cache-Speicher-Eintrag betrifft. Wenn eine Implementierung keinen L2-Cache-Speicher hat, dann muss der GPU-Speicher dieses gleiche kohärente Verhalten haben. Der L2-Cache-Speicher kann entweder rückschreibend oder durchschreibend sein.
- – Ein FenceSync-Befehl bewirkt, dass jeder Rückschreib-L1-Cache-Speicher, der für die Warteschlange relevant ist, auf die ausgegeben wird, zu dem kohärenten L2 durch geschrieben wird, bevor die Beendigung angezeigt wird.
-
Es gibt einige Klassen von Speicher-„Klienten”, die alle Speicher auslesen und beschreiben, und die folgenden Cache-Speicher-Invalidierungsregeln definieren, welche Operationen erforderlich sind, um diese Schreiboperationen und Leseoperation effektiv kohärent zueinander zu machen. Klienten schließen die CPU, die Gruppe der GPU-Kopierbefehle und die Gruppe der GPU-Zugriffe über GPU-Referenznummern bzw. Handles (alle Zugriffsarten) mit ein.
-
CPU-Schreiboperationen, die auftreten, bevor Befehle an eine Warteschlange ausgegeben werden, werden automatisch für diese nachfolgenden Befehle in dieser Warteschlange sichtbar, ohne dass zusätzliche Information von der Anwendung bereitgestellt wird. Eine mögliche Treiberimplementierung dieses Erfordernisses besteht darin, jegliche CPU-abrufbare Zeile aller L1-Cache-Speicher und des L2-Cache-Speichers jedes Mal als ungültig zu setzen, wenn ein Stapel an Arbeit an eine Warteschlange ausgegeben (oder „geleert”) wird. Obwohl dies unbeholfen klingen mag, sind Speicherleerungen für gewöhnlich selten und der Anteil der Cache-Speicher, die von CPU-abrufbare Zeilen verwendeten, ist für gewöhnlich klein.
-
Um das Ergebnis von GPU-Schreiboperationen für CPU-Leseoperationen zu sehen, entweder über Kopier-Befehle oder GPU-Referenznummern, müssen diese Schreiboperationen aus jeglichen Rückschreibe-L1- oder L2-Cache-Speichern geleert werden und anschließend muss die CPU warten, bis die Schreiboperationen abgeschlossen sind. Dies kann bewerkstelligt werden, indem die geeignete Marke in dem FenceSync-Befehl verwendet wird.
-
Wenn sowohl die CPU als auch die GPU den gleichen Speicher ohne ausreichende Synchronisierung der Ausführung und Cache-Speicher-Leerung beschreiben, gelten die vorhergehenden Regeln nicht und das Ergebnis ist nicht definiert.
-
GPU-Kopierbefehle sollen „Datenstrom-”Operationen sein und verwenden daher keinen persistenten L1-Cache-Speicher. Sie haben üblicherweise eine einfache Zeilenspeicherung, um diese Operationen und Schreiboperationen zusammenzuführen, die nach Verwendung unmittelbar geleert werden. Insbesondere werden ihre Schreiboperationen stets aktuelle Daten aus dem L2 abrufen und die Schreiboperationen schreiben durch bis zum L2. Damit haben sie keine Cache-Speicher für sich selbst, die eine Invalidierung erfordern, aber ihre Schreiboperationen können Zeilen in L1-Cache-Speichern anderer Zugriffsart veraltet machen.
-
Kopierbefehle bewirken, dass andere L1-Cache-Speicher-Einheiten in halbautomatisierter Weise als ungültig gesetzt werden. Die Anwendung ist nur zum Ausdrücken von *Ausführungsabhängigkeiten* zwischen Kopierwarteschlangen und andere Warteschlangen über Sync-Objekte verantwortlich, und Regeln auf der Grundlage dieser Ausführungsabhängigkeiten versorgen den Treiber mit Informationen, die zum Ungültigsetzen der geeigneten Cache-Speicher erforderlich sind. Ferner weiß der Treiber, welche Zugriffsarten für den Zielspeicher der Kopie aktiviert sind, wodurch es möglich ist, weiter einzuschränken, welche Cache-Speicher ungültig gesetzt werden.
-
Die fundamentale Regel besteht darin, dass Kopierbefehle an einer Kopierwarteschlange ein genau definiertes Verhalten haben, es muss gelten:
- – eine FenceSync(OtherQ) = > QueueWaitSync(CopyQ)-Abhängigkeit aus beliebigen Warteschlangen, die alte gespeicherte Werte haben, wobei die FenceSync nach der letzten Lese-/Schreib-Operation des Speichers erfolgt und die QueueWaitSync vor dem Kopieren ist. Und,
- – eine FenceSync(CopyQ) = > QueueWaitSync(OtherQ)-Abhängigkeit nach dem Kopieren und vor jeglichen nachfolgenden Lese-/Schreiboperationen des Speichers an der anderen Warteschlange.
-
Es gibt viele mögliche Implementierungen dieses Verhaltens mit automatischer Cache-Speicher-Invalidierung. Wenn zunächst eine Kopierwarteschlange in der Lage ist, andere L1-Cache-Speicher-Warteschlangen als ungültig zu setzen, könnte sie dies unmittelbar oder beim nächsten FenceSync-Befehl tun, wodurch in trivialerweise diese Anforderung erfüllt wird.
-
Eine zweite mögliche Implementierung besteht darin, Cache-Speicher-Invalidierung an den QueueWaitSync-Zeiten auszuführen, wobei Information verwendet wird, die von der Warteschlange bereitgestellt wird, die der Ursprung des Sync-Objekts ist. Dies macht es möglich, Invalidierungen zu der Warteschlange zu verschieben, die ihre eigenen Cache-Speicher als ungültig setzen kann.
-
Wenn GPU-Speicher freigegeben und erneut durchlaufen/erneut zugewiesen wird, ist der Treiber dafür verantwortlich, dass sichergestellt ist, dass es keine veralteten Cache-Speicher-Zeilen für diesen Speicher gibt, bevor der Speicher neu zugewiesen wird.
-
Die verbleibenden Klienten sind Leseoperationen und Schreiboperationen jeglicher dieser Zugriffsarten, die GPU-Referenznummern bzw. Handles verwenden. Es liegt in der Verantwortung der Anwendung, diese Cache-Speicher zu leeren und als ungültig zu setzen, wenn es eine Abhängigkeit gibt, wobei eine „Barriere” verwendet wird. Die spezielle API für eine Barriere ist in dem folgenden Abschnitt beschrieben, jedoch hat konzeptionell die Barriere vier Zustandselemente:
- – srcMosk, dstMask: Bit-Felder aus Pipeline-Stufen
- – flushMask, invalidoteMask: Bit-Felder aus Zugriffsarten
-
Eine Barriere liefert Information über Ausführungsbarrieren und Cache-Speicher-Leerungen und Invalidierung. <srcMask> und <dstMask> zeigen den Ursprung und das Ziel der Auslandsabhängigkeit an, d. h., jegliche Arbeit in den Pipeline-Stufen, die durch <dstMask> angegeben ist, beginnt gegebenenfalls nicht, bis alle vorhergehende Arbeit in den Pipeline-Stufen, die durch <srcMask> angegeben ist, abgeschlossen ist. <flushMask> und <invalidateMask> geben an, welche Cache-Speicher-Zugriffsart zurück geschrieben werden müssen (in den L2 geleert) oder als ungültig gesetzt (verworfen) werden müssen. Die Cache-Speicher-Leerung und/oder Invalidierung tritt auf, nachdem die durch <srcMask> angegebene Arbeit, beendet ist und bevor die durch <dstMask> angegebene Arbeit beginnt.
-
Wenn dies auf unser früheres einfaches Beispiel mit Bilderzeugung-zu-Textur angewendet wird, wäre die Operation für das Einfügen einer Barriere zwischen der Bilderzeugungsübermittlung und der Textur-Übermittlung mit den Parametern verantwortlich:
srcMask = RAD_RENDERTARGET_STAGE_BIT
dstMask = RAD_FRAGMENT_STAGE_BIT
flushMask = RAD_RENDERTARGET_ACCESS_BIT
invalidateMask = RAD_TEXTURE_ACCESS_BIT
-
Ein Bilderzeugungsalgorithmus besteht im Allgemeinen aus einer Gruppe von „Übermittlungen”, wobei jede Übermittlung ein einzelnes Bilderzeugungsziel als eine Ausgabe (oder mehrere Bilderzeugungsziele, d. h. „MRT”, die kollektive erzeugt werden) erzeugt. Unter Verwendung des einfachen Beispiels Bilderzeugung-zu-Textur ist die Bilderzeugung zu der Textur die erste Übermittlung und die Bilderzeugung in das zweite Bilderzeugungsziel, während Texturzuordnung aus der Textur erfolgt, ist die zweite Übermittlung.
-
Die wahren Abhängigkeiten zwischen diesen Übermittlungen bilden einen direkten azyklischen Graphen (DAG), wobei jedoch konventionelle Grafik-APIs lediglich eine lineare Abfolge von Befehlen ausdrücken, wodurch effektiv eine „abgeflachte” Form des DAG repräsentiert wird. Diese APIs beruhen ebenfalls auf einer strikten Reihenfolge von Befehlen, um sicherzustellen, dass eine abhängige Übermittlung abgeschlossen ist, bevor eine nachfolgende Übermittlung beginnt. In einer modernen API wie RAD, in der der Treiber die Binde-Information nicht untersucht, ist der Treiber nicht in der Lage, die waren Abhängigkeiten herauszufinden, und es ist somit wichtig, dass die Anwendung dieser Information explizit bereitstellt.
-
Ein „Übermittlungs-”Objekt repräsentiert einen Knoten in dem DAG und enthält Abhängigkeitsinformation, die die Kanten in dem DAG repräsentiert. Die Übermittlung enthält Information über Eingänge (Abhängigkeiten, Barrieren, reservierte Puffer), Ausgaben (Bilderzeugungsziele, verworfene Puffer, aufgelöste Puffer) und einen Kachelbildungszustand (1:1-Pixel-Abbildung, Filterbreite, Speichergröße). Der Kachelbildungszustand liefert genug Information für eine Implementierung, um eine Kacheleinteilung mit mehreren Übermittlungen zu unterstützen, d. h., mehr als eine einzelne Übermittlung vor dem Schritt zu der nächsten Kachel in den Bilderzeugungszielen erzeugen.
-
Genauer gesagt, der Zustand beinhaltet:
- – Bilderzeugungszielanhänge: Farb-, Tiefen- und Schablonen-Puffer, in die die Ergebnisse der Übermittlung geschrieben werden. Der anfängliche Zustand ist keine Anhänge.
void radPassRenderTargets(RADpass pass, RADuint numColors,
canst RADrenderTargetHandle *colors.
RADrenderTargetHandle depth,
RADrenderTargetHandle stencil);
- – Bewahrte Puffer: welche Anhänge für Farbe, Tiefe und Schablone haben ihren Inhalt zu Beginn der Übermittlung beibehalten. Wenn der Inhalt eines Anhangs nicht bewahrt wird, erzeugt der Bezug auf diesen Inhalt ein undefiniertes Verhalten. Der Anfangszustand ist: alle Anhänge werden bewahrt. void radPassPreserve(RADpass pass, RADattachment attachment, RADboolean enable);
- – Verworfene Puffer: welche Texturen haben ihre Inhalte am Ende der Übermittlung verworfen. Dieser Befehl nimmt Textur-CPU-Referenznummern bzw. Handles anstelle von Nummern der Anhänge, weil ein Puffer, der verworfen werden muss, ein Bilderzeugungsziel in einer vorhergehenden Übermittlung aber nicht in der aktuellen Übermittlung gewesen sein kann. Dieser Befehl akzeptiert auch eine „Pixel-Verschiebung”, die auf jedes Verwerfen angewendet wird, was nachfolgend im Zusammenhang mit Mehrfach-Übermittlungs-Kacheleinteilung bzw. Kachelbildung beschrieben ist. Der Anfangszustand ist, dass keine Texturen verworfen werden.
void radPassDiscard(RADpass pass, RADui.nt numTextures,
canst RADtexture *textures,
canst RADoffsetZD *offsets);
- – Aufgelöste Puffer: welche Mehrfachabtastungs-Farbanhänge werden in einem Nicht-Mehrfachabtastungs-Farbpuffer am Ende der Übermittlung aufgelöst. Wenn ein derartiger Mehrfachabtastungs-Puffer auch für das Verwerfen markiert ist, dann erfolgt das Auflösen unmittelbar vor dem Verwerfen. Anfangszustand ist, dass keine Anhänge aufgelöst werden.
void radPassResolve(RADpass pass, RADattachment attachment,
RADtexture resolved);
- – Gespeicherte Puffer: welche Texturen sollten ihren Inhalt in einen Speicher am Ende der Übermittlung entleeren. „Speichern” ist ein Hinweis, dass die Textur von dem Kachel-Speicher in den chip-externen Speicher entleert werden sollte, da ein Inhalt für den Rest einer Kacheleinteilungssequenz mit mehreren Übermittlungen nicht benötigt wird. Die Nichtmarkierung einer Textur, die zu speichern ist, impliziert nicht, dass sie verworfen wird, der Inhalt wird vielmehr bewahrt, doch eine Speicherung eines Puffers zur geeigneten Zeit kann länger als notwendig in dem Kachel-Speicher halten. Die Speicherung beinhaltet auch eine Pixel-Verschiebung aus Gründen, die ähnlich zu den Gründen beim Verwerfen sind. Anfänglicher Zustand ist, dass keine Texturen gespeichert sind.
void radPassStore(RADpass pass, RADuint numTextures,
canst RADtexture *textures,
canst RADoffset2D *offsets);
- – Rechteck abschneiden: ein zweidimensionales Gebiet der Bilderzeugungsziele, das als eine Schere für alle Operationen in der Übermittlung dient, einschließlich von Bilderzeugung, Verwerfen und Auflösungen. Anfänglicher Zustand ist ungeschnitten, d. h., (x, y) = (0, 0), (Breite, Höhe) = (Max, Max).
void radPassClip(RADpass pass, RADuint x, RADuint y,
RADuint width, RADuint height);
- – abhängige Übermittlungen: eine Liste aus Übermittlungen, von denen diese Übermittlung abhängt. Die Implementierung muss sicherstellen, dass diese Übermittlungen abgeschlossen sind bis zu einem Grad, der von der Barriere beschrieben ist. Anfänglicher Zustand ist keine Abhängigkeiten.
void radPassDependencies(RADpass pass, RADuint numPasses,
canst RADpass *otherPasses);
- – Barriere: eine Beschreibung der Stufen und Cache-Speicher, die in der Abhängigkeit zwischen den vorhergehenden Übermittlungen und der aktuellen Übermittlung beteiligt sind. Wie in dem Abschnitt Barriere beschrieben ist, müssen Arbeiten in den abhängigen Übermittlungen vollständig abgeschlossen werden so weit wie <srcMask> und müssen aus dem Cache-Speicher gemäß <flushMask> geleert und gemäß <invalidateMask> ungültig gesetzt werden, bevor eine Arbeit in der aktuellen Übermittlung so weit wie <dstMask> weitergehen kann. Anfänglicher Zustand ist keine Barriere.
void radPassBarrier(RADpass pass, RADbitfield srcMask, RADbitfield dstMask,
RADbitfield flushMask, RADbitfield invalidateMask);
Kacheleinteilungsgrenze: eine Bool'sche Variable, die angibt, ob es sicher ist, diese Übermittlung pro Kachel zusammen mit ihren Abhängigkeiten auszuführen. Wenn dies wahr ist (wodurch angegeben ist, dass dies eine Grenze ist), muss die Kachel-Bildungseinheit geleert werden, bevor diese Übermittlung begonnen wird. Eine Anwendung kann dies auf falsch setzen, wenn es eine Bildschirm-Raum-Korrelation zwischen Fragment-Strängen bzw. Threads in der aktuellen Übermittlung und welche Texturelemente der vorhergehenden Bilderzeugungsziele von diesen Fragment-Strängen abgeholt werden. Normalerweise muss dies eine 1:1-Abbildung sein, aber die API erlaubt auch eine nicht-null-„Filterbreite”. Anfänglicher Zustand ist Grenze = WAHR.
void radPassTilingBoundary(RADpass pass, RADboolean boundary);-Kacheleinteilung-Kacherfilterbreite: die API erlaubt Kacheleinteilung mit mehreren Übermittlungen, wobei die zweite Übermittlung keine exakte 1:1-Zuordnung zwischen den Koordinaten der Ursprungstextur und den Fensterkoordinaten des Fragment-Strangs hat. Wenn die Anwendung sicherstellen kann, dass die Texturkoordinaten innerhalb von +/– [Filterbreite, Filterlänge] der Fensterkoordinaten liegen, kann sie eine Kacheleinteilung mit mehreren Übermittlungen (d. h., Grenze = FALSCH) über eine derartige Abhängigkeit hinweg zulassen. Anfänglicher Zustand ist Filterbreite = Filterhöhe = 0.
void radPassTileFilterWidth(RADpass pass,
RADuint filterWidth, RADuint filterHeight);
- – Kachelgröße: für Kacheleinteilung mit mehreren Übermittlungen muss die Implementierung gegebenenfalls im Voraus wissen, wie viel Speicher von einer Kachel eingenommen wird, so dass sie die effizienteste Kachelgröße auswählen kann. Die Speichergröße hängt von der „eingestellten Arbeitsgröße” jedes Pixels ab, d. h., von der Gesamtzahl an Bytes pro Pixel, die zu jeder Zeit während der Mehrfachübermittlung aktiv sind. Die Größe hängt auch von der maximalen Filterbreite ab, die beeinflusst, wie viele Pixel zu jeder Zeit am Leben gehalten werden müssen. Anfangszustand ist BytesproPixel = maxFilterbreite = 0.
void radPassTileFootprint(RADpass pass, RADuint bytesPerPixel,
RADuint maxFilterWidth);
Die Bytes pro Pixel müssen gegebenenfalls genau präzisiert werden, indem Bildfehlerbehebungs-Modi eingebunden werden.
-
Eine Lebensdauer einer Übermittlung wird mit den üblichen Befehlen (radCreatePass, radReferencePass, radReleasePass) verwaltet und wird unveränderlich gemacht durch radCompilePass. Kompilieren einer Übermittlung beinhaltet nicht eine Zuordnung von Bilderzeugungsbefehlen zu ihr, es bedeutet vielmehr, dass die Übermittlung nachfolgend verwendet werden kann, um Bilderzeugungsbefehle auszugeben.
-
Bevor das Verhalten der Übermittlung genauer beleuchtet wird, ist es wichtig, die Modelle der Kachelbildungs-Hardware zu verstehen und zu verstehen, wie sie mit mehreren Übermittlungen wechselwirken. Es gibt zwei Klassen von Verhaltensweisen von Kacheleinheiten:
- (1) Explizit verwalteter Kachelspeicher. Diese Klasse an Hardware erfordert das explizite Laden des Chip-externen Speichers in einen Chip-internen Kachelspeicher zu Beginn jeder Übermittlung, und umgekehrt, Speicherung des Kachelspeicher in den Chip-externen Speicher am Ende jeder Übermittlung. Mit Ausnahme von einigen einfachen Fällen, etwa die Auflösung einer Mehrfach-Abtastung, ist explizit verwaltete Hardware generell nicht geeignet für Kacheleinteilung mit mehreren Übermittlungen und wird gegebenenfalls tatsächlich eine Grenze zwischen jeder Übermittlung einfügen. Kacheleinteilung mit mehreren Übermittlungen würde die Partitionierung des Kachelspeichers durch Bilderzeugungsziele möglicherweise komplexer Art und Weise erfordern und möglicherweise erfordern, dass Texturanforderungen in der Lage sind, die Teile des Kachelspeichers zu adressieren. Wenn die Anwendung eine Kacheleinteilung mit mehreren Übermittlungen anfordert, ist es verständlich, dass sie zurückgeht auf einen Einzeldurchlauf bzw. Einzelübermittlung.
- (2) Vereinigter Cache-Speicher-basierter Kachelspeicher. Diese Klasse an Hardware zwingt den Kachelspeicher dazu, als ein Cache-Speicher zu fungieren, wobei Zeilen nach Bedarf aus dem Speicher geladen und nach Bedarf in den Speicher ausgeladen werden. Ferner verarbeitet dieser Cache-Speicher auch andere Speicherzugriffsarbeit, etwa Textur, so dass es möglich ist, eine Texturabbildung aus dem Kachelspeicher durchzuführen. Dies kann der gleiche LZ-Cache-Speicher sein, wie er zuvor beschrieben ist. Diese Art an Hardware ist für Kacheleinteilung mit mehreren Übermittlungen geeignet und ist das Hauptziel der Gestaltungsform für mehrfache Übermittlungen bzw. Durchläufe.
-
Einige Aspekte des Übermittlungszustands können unterschiedliche interne Verhaltensweisen abhängig von der Klasse der Kacheleinteilungs-Hardware haben:
- – „Bewahren”: in explizit verwalteter Hardware erfordert dies ein Laden/Kopieren aus dem Chip-externen Speicher in den Kachelspeicher. In Cache-Speicher-basierter Hardware kann dies ein NAP sein.
- – „Verwerfen”: in explizit verwalteter Hardware impliziert ein verworfener Puffer das Überspringen eines Speichern/Kopieren aus dem Kachelspeicher in den Chip-externen Speicher. Cache-Speicher-basierter Hardware kann diese Zeilen des Cache-Speichers als ungültig erklären, ohne dass die geänderten Zeilen in den Chip-externen Speicher geleert werden. Wenn ein Anhang NICHT verworfen wird, wird explizit verwaltete Hardware den Speicher am Ende einer Übermittlung speichern/kopieren, und eine Cache-Speicher-basierte Hardware unternimmt gegebenenfalls nichts. Cache-Speicher-basierte Hardware kann ferner Speicher verwerfen/invalidieren während einer nachfolgenden Übermittlung aus einer Abfolge mehrerer Übermittlungen.
- – „Speichern”: in explizit verwalteter Hardware kann dies ein NAP sein, da die Daten bereits in dem Chip-externen Speicher aufgrund einer vorhergehenden Übermittlungen sind, oder sie werden am Ende der aktuellen Übermittlung in den Speicher kopiert. In Cache-Speicher-basierter Hardware kann dies einen Teil des Rückschreibe-Cache-Speicher leeren.
- – „Abschneiderechteck”: in explizit verwalteter Hardware definiert dieses Rechteck die Gebiete, die Ladeoperationen und Speicheroperationen betreffen. In Cache-Speicher-basierter Hardware dient dies lediglich als eine Schere für Bilderzeugungsbefehle.
- – „Kachelgröße”: in explizit verwalteter Hardware kann dies ignoriert werden und die Kachelgröße kann auf der Grundlage lediglich der Bilderzeugungsziele ausgewählt werden. In Cache-Speicher-basierter Hardware kann diese Größe verwendet werden, um die gewünschte Kachelgröße für eine Abfolge aus mehreren Übermittlungen bzw. Durchläufen zu berechnen.
-
In Cache-Speicher-basierter Hardware ist die Kacheleinteilung in mehreren Übermittlungen relativ einfach unter der Annahme, dass es eine genaue 1:1-Abbildung von Texturelement-Koordinaten, die aus einer früheren Übermittlung ausgelesen werden, zu Fragmentkoordinaten in der aktuellen Übermittlung gibt. Die Anwendung kann dies angeben, indem gesetzt wird Grenze == FALSCH und Filterbreite/Höhe == 0. Wenn dies der Fall ist, kann die Implementierung eine Kachelgröße derart auswählen, dass der gesamte Arbeitsplatz aus Übermittlungen in der Mehrfach-Übermittlung in den Cache-Speicher passt, indem die Bytes pro Pixel des Kachelgrößenzustands verwendet werden. Die Implementierung muss dennoch den Barrierenzustand auf Basis einer einzelnen Kachel beachten, aber alle Kacheln der relevanten Übermittlungen können in dem Cache-Speicher Platz finden und Befehle zum Verwerfen und zum Speichern können in normalerweise arbeiten.
-
Eine Kacheleinteilung mit mehreren Übermittlungen ist dennoch möglich, obwohl sie komplexer ist, wenn die Abbildung von Texturelement-Koordinaten zu Fensterpositionen nicht genau 1:1 ist. RAD unterstützt eine derartige Kacheleinteilung mit mehreren Übermittlungen, wenn die Anwendung sicherstellen kann, dass die Texturelement-Koordinaten innerhalb einer vorbestimmten „Filterbreite” der Fensterkoordinaten liegen, wobei dies Details des radPassTileFilterWidth-Befehls spezifiziert ist. Die Implementierung kann dies nutzen, um das Kachel-Rechteck zwischen Übermittlungen durch (Filterbreite, Filterhöhe)-Pixel in Richtung auf den Ursprung zu so nutzen, dass eine Grenze gültigen Inhalts aus der vorhergehenden Übermittlung aus den entfernten Kanten der Kachel verfügbar ist. In ähnlicher Weise ist die Anwendung verantwortlich, genaue Pixel-Verschiebungen für Befehle zum Verwerfen und zum Speichern bereitzustellen. Diese Befehle sind ebenfalls in Richtung zum Ursprung hin verschoben, und durch die Verschiebung um die doppelte Filterbreite bleibt ein zulässiges Gebiet um die zwei nah gelegenen Kanten der Kachel herum.
-
Diese zusätzlichen Streifen an zulässigem Speicher um die aktuelle und die vorhergehende Kachel herum sind der Grund, warum eine Anwendung danach streben sollte, eine genaue maximale Filterbreite bereitzustellen, da die Implementierung versuchen wird, Cache-Speicher-Raum zu reservieren, um diesen Speicher im Cache-Speicher zu halten.
-
Anders als andere APIs, in denen Rechenbefehle in freier Weise mit Grafik-Befehlen verschachtelt werden können und diese Befehle implizit geordnet werden, erfordert die RAD-API Rechenbefehle, die in separaten rechenspezifischen Übermittlungen (oder asynchron in anderen Rechenwarteschlangen laufen) sind. Rechen-Übermittlungen können auch mild Bilderzeugungs-Übermittlungen in Kacheln eingeteilt werden; wenn es eine Abhängigkeit zwischen Texturkoordinaten und Aufruf-Kennungen einer Rechenschattierungseinheit gibt. Eine Rechen-Übermittlung kann die Natur dieser Abhängigkeit spezifizieren, die ein Pixel pro Rechenaufruf oder N×M Pixel pro Rechenaufruf sein kann. Die Kacheleinteilung über eine derartige Übermittlung hinweg ist möglich, wenn die Rechenaufrufe natürlicherweise in die Kachelform passen, die für die Bilderzeugung ausgewählt ist. Die Anwendung kann die Form einer Rechenarbeitsgruppe in Pixel angegeben, wobei der Befehl radPassTileComputeFootprint verwendet wird.
-
Zusätzlich zur Spezifizierung von Abhängigkeiten mittels mehrerer Übermittlungen ist es auch möglich, Abhängigkeiten innerhalb einer Übermittlung unter Anwendung des Befehls zu definieren:
radQueuePassBarrier(RADqueue queue, RADbitfield srcMask, RADbitfield dstMask,
RADbitfield flushMask, RADbitfield invalidateMask);
-
Dies kann als eine Aufteilung des aktuellen Knotens in zwei Knoten aufgefasst werden, wobei der zweite Knoten von dem ersten entsprechend der spezifizierten Barriere abhängt. Dies kann in Situationen geeignet sein, in denen MemoryBarrier oder TextureBarrier im OpenGL zweckdienlich sind.
-
Arbeit für die Übermittlung wird an eine Warteschlange unter Anwendung der Befehle ausgegeben:
void radQueueBeginPass(RADqueue queue, RADpass pass);
//Ausgeben von Arbeit an die Warteschlange zwischen Beginn/Ende void radQueueEndPass(RADqueue queue);
-
Es ist nicht zulässig, Kopier- oder FenceSync -Befehle während einer Übermittlung auszugeben, oder Rechenausgabebefehle während einer grafischen Übermittlung auszugeben. Diese Befehle müssen entweder außerhalb einer Übermittlung auftreten (in welchem Falle sie als abhängig von allen zuvor ausgegebenen Übermittlungen erachtet werden), oder Kopier- und Rechenbefehle müssen an unterschiedliche (asynchrone) Warteschlangen ausgegeben werden.
-
Einige Beispiele, wie Übermittlungen zu verwenden sind:
Einzelne Übermittlung, keine Abhängigkeiten, Verwerfen der Tiefe am Ende:
poss0 = radCreatePass(device);
//Festlegen der Farb- und Tiefen-Puffer
radPassRendertargets(pass0, 1, &color0, depth, 0);
//Tiefen-Puffer ist am Ende zu verwerfen, ohne Verschiebung
radPassDiscard(pass0, depth CPU handle, /*offset*/{0,0});
//Finalisieren des Übermittlungsobjekts
radCompilePass(pass0);
//Verwenden der Übermittlung
radQueueBeginPass(queue, pass0);
//Ausgeben der Arbeit
radQueueEndPass(queue);
-
Einzelne Übermittlung, Abwärtsabtastung, dann verwerfen:
pass0 = radCreatePass(device);
//Festlegen des Farbpuffers mit Mehrfachabtastung radPassRendertargets(pass0, 1, &colorMS, 0, 0);
//früherer Inhalt des Puffers mit Mehrfachabtastung wird nicht bewahrt
radPassPreserve(pass0, color attachment 0, RAD_FALSE);
//Daten der Mehrfachabtastung werden am Ende der Übermittlung verworfen
radPassDiscard(pass0, colorMS, I*offset*/{0,0});
//Die Daten der Mehrfachabtastung werden in den color1X-Puffer aufgelöst,
//bevor er verworfen wird.
radPassResolve(pass0, color attachment 0, colorIX);
radCompilePass(pass0);
radQueueBeginPass(queue, pass0);
//Arbeit ausgeben
radQueueEndPass(queue);
-
Bilderzeugung in zwei Texturen hinein, dann verwenden dieser mit einer 1:1 Texturelement:Pixel-Abbildung:
//Übermittlung 0 erzeugt das Bild in eine der Texturen hinein (color0)
pass0 = radCreatePass(device);
radPassRendertargets(pass0, 1, &color0, 0, 0);
radPassTileFootprint(pass0, 12 bytes per pixel, 0 pixel max filter width);
radCompilePass(pass0);
//Ausgeben von Arbeit an Übermittlung0 bzw. pass0, Wiederholen für
//Übermittlung1 bzw. pass1
pass2 = radCreatePass(device);
radPassRendertargets(pass2, 1, &color2, 0, 0);
radPassTileFootprint(pass2, 12 bytes per pixel, 0 pixel filter width);
//Übermittlung2 bzw. pass2 hängt von Übermittlung0 bzw. pass0 und
//Übermittlung1 bzw. pass1 ab
radPassDependencies(pass2, 2, {pass0, passI});
//Zulassen von Kacheleinteilung mit mehreren Übermittlungen mit pass0 bzw.
//Übermittlung0, pass1 bzw. Übermittlung1
radPassTilingBoundary(FALSE);
//Aktuelle Übermittlung kann ich Fragmentarbeit starten, bis Schreiboperationen
//des vorhergehenden Bilderzeugungsziels abgeschlossen sind
radPassBarrier(pass2,
/*srcMask*IRAD_RENDERTARGET_STAGE_BIT,
/*dstMask*IRAD_RENDERTARGET_STAGE_BIT,
/*flushMask*IRAD_RENDERTARGET_ACCESS_BIT,
/*invalidateMask*IRAD_TEXTURE_ACCESS_BIT);
//Verwerfen der Übergangs-Farbe011 bzw. color011 am Ende dieser
//Übermittlung
radPassDiscard(pass2, color0, 0);
radPassDiscard(pass2, colorI, 0);
radCompilePass(pass2);
Komplexe Mehrfachübermittlungen mit Verschiebung und Verwerfen:
pass0 = radCreatePass(device);
radPassRendertargets(pass0, 1, &color0, 0, 0);
//8 Bytes pro Pixel (4 in color0 bzw. Farbe0, 4 in color1 bzw. Farbe1) radPassTileFootprint(pass0, 8 bytes per pixel, 2 pixel max filter width);
radCompilePass(pass0);
//Ausgeben von Arbeit an Übermittlung0 bzw. pass0
passI = radCreatePass(device);
radPassRendertargets(passI, 1, &colorI, 0, 0);
radPassTileFootprint(passI, 8 bytes per pixel, 2 pixel filter width);
//Textur-Koordinaten innerhalb von +/–2×2 Pixel der Fensterposition
radPassTileFilterWidth(passI, {2,2} pixels);
//Kachel über die eintreffenden Abhängigkeiten (Übermittlung0 bzw. pass0)
radPassTilingBoundary(FALSE);
radPassDependencies(passI, 1, &pass0);
//Aktuelle Übermittlung kann Fragmentarbeit nicht starten, bis Schreiboperationen
//des früheren Bilderzeugungsziels abgeschlossen sind
radPassBarrier(passI,
I*srcMask*IRAD_RENDERTARGET_STAGE_BIT,
I*dstMask*IRAD_FRAGMENT_STAGE_BIT,
I*flushMask*IRAD_RENDERTARGET_ACCESS_BIT,
I*invalidateMask*IRAD_TEXTURE_ACCESS_BIT);
//Verwerfen der Übergangsfarbe0 bzw. color0 am Ende dieser Übermittlung mit
//einer Verschiebung,
//die gleich der doppelten Filterbreite ist
radPassDiscard(passI, color0, 4 pixels);
//Speichern von Farbe1 bzw. color1 am Ende dieser Übermittlung
radPassStore(passI, colorI, 0 pixels);
radCompilePass(passI);
-
Ausführungsformen der vorliegenden Technik spezifizieren vorteilhafterweise Anwendungsfälle für Abhängigkeiten zur Synchronisierung, Cache-Speicher-Steuerung und Kacheleinteilung des Speichers und dergleichen. Ausführungsformen der vorliegenden Technik sind sowohl einfacher als auch effizienter, um Treiber und Anwendungen zu implementieren und zu verwenden.
-
Die vorhergehenden Beschreibungen spezieller Ausführungsformen der vorliegenden Technik sind zum Zwecke der Darstellung und der Beschreibung angegeben. Sie beabsichtigen nicht, umfassend zu sein oder die Erfindung auf die genauen offenbarten Formen zu beschränken, und es sind viele Modifizierungen und Variationen im Lichte der obigen Lehre ersichtlich. Die Ausführungsformen wurden ausgewählt und beschrieben, um die Prinzipien der vorliegenden Technik und ihre praktische Anwendung am besten zu erläutern, um dadurch Fachleute in die Lage zu versetzen, die vorliegende Technik und diverse Ausführungsformen mit diversen Modifizierungen am besten einzusetzen, wie dies für die spezielle betrachtete Anwendung geeignet ist. Es ist beabsichtigt, dass der Schutzbereich der Erfindung durch die angefügten Patentansprüche und ihre Äquivalente festgelegt ist.
