-
Technisches Gebiet
-
Der hierin offenbarte Gegenstand betrifft im Allgemeinen Techniken zum Speichern und Abrufen von Bilddaten.
-
Stand der Technik
-
Die Nachfrage nach Grafikverarbeitung zeigt sich in Gebieten wie z. B. Computerspielen, Computeranimationen und medizinischer Bildgebung. Die Grafikpipeline ist für das Rendern von Grafiken verantwortlich. Zahlreiche Grafikpipeline-Konfigurationen sind bekannt. Beliebte Pipelinearchitekturen zum Rendern werden beispielsweise in Segal, M. und Akeley, K. „The OpenGL Graphics System: A Specification (Version 2.0)" (2004) und The Microsoft DirectX 9 Programmable Graphics Pipe-line, Microsoft Press (2003) beschrieben. Die heutige Pipeline verfügt über drei programmierbare Schritte, einen zum Verarbeiten von Eckpunktdaten (z. B. ein Vertex-Shader), einen zweiten zum Verarbeiten geometrischer Grundelemente (z. B. ein Geometrie-Shader) und einen dritten zum Verarbeiten von Pixelfragmenten (z. B. ein Fragment oder Pixel-Shader). Microsoft® DirectX 10 hat Geometrie-Shader und einen Geometrie-Streamout-Schritt eingeführt. Ein Überblick über das Direct3D 10 System wird in D. Blythe „The Direct3D 10 System", Microsoft Corporation (2006), gegeben. DirectX ist eine Gruppe von Programmierschnittstellen (application program interfaces, APIs), die sich mit Grafiken bei Eingabegeräten, Audio und Video beschäftigen.
-
Kurze Beschreibung der Zeichnungen
-
Erfindungsgemäße Ausführungsformen werden exemplarisch und in keiner Weise einschränkend in den Zeichnungen veranschaulicht, bei denen gleiche Bezugsnummern zum Verweis auf ähnliche Elemente verwendet werden.
-
1 stellt ein Beispiel einer Grafikverarbeitungspipeline in Blockdiagramm-Format gemäß einer Ausführungsform dar.
-
2 stellt ein Beispiel einer herkömmlichen Pixel-Shader-Verarbeitung von Pixel-Coverage-Masken sowie eine Verarbeitung von Pixel-Coverage-Masken bei einer Kachel gemäß verschiedener Ausführungsformen dar.
-
3 stellt ein Beispiel einer Kernauslastung, wenn ein einzelner Kern Kacheln verarbeitet, und einer Kernauslastung vor und nach der Verteilung einer Verarbeitung einer einzelnen Kachel auf mehrere Kerne dar.
-
4 stellt Beispiele einer individuellen Rasterungsverarbeitung von Grundelementen und Pixel-Coverage-Masken dar.
-
5 stellt ein Ablaufdiagramm einer Art und Weise dar, Grundelemente und Pixel-Coverage-Masken in einem gepufferten Modus gemäß einer Ausführungsform zu speichern.
-
6 stellt ein Ablaufdiagramm einer Art und Weise dar, Grundelemente und Pixel-Coverage-Masken in einem gepufferten Modus gemäß einer Ausführungsform abzurufen.
-
Ausführliche Beschreibung
-
Verweise in dieser Beschreibung auf „eine Ausführungsform” bedeuten, dass ein bestimmtes Merkmal, eine Struktur oder Charakteristik, die in Verbindung mit der Ausführungsform beschrieben wird, mindestens in einer Ausführungsform der vorliegenden Erfindung enthalten ist. Somit beziehen sich die Verwendungen des Ausdrucks „bei einer Ausführungsform” an verschiedenen Stellen in dieser Beschreibung nicht notwendigerweise immer auf die gleiche Ausführungsform. Des Weiteren können die bestimmten Merkmale, Strukturen oder Charakteristika in einer oder mehr Ausführungsformen kombiniert werden.
-
Verschiedene Ausführungsformen stellen eine Art und Weise bereit, Eigenschaften von Grundelementen und Pixel-Coverage-Information während oder nach einem Rasterungsschritt in einer Grafikpipeline zu speichern. Ein Post-Clip-Stream-Ausgabe-Schritt setzt Teile von Puffern in einem Speicher ein, um Grundelemente und Pixel-Coverage-Masken zu speichern, die die Grundelemente betreffen. Als Kacheln bekannte Unterbereiche des Bildschirms sind räumlich kohärente Sammlungen von Pixeldaten im Bildschirmraum. Die Grundelemente werden pro Kachel geordnet und gegebenenfalls mit Pixel-Coverage-Masken an die Kachelränder geclippt. Pixel-Coverage-Masken identifizieren eine Beziehung eines Pixels zu einem Grundelement. Beispielsweise kann die Pixel-Coverage-Maske identifizieren, ob sich ein Pixel innerhalb eines Grundelements, außerhalb eines Grundelements oder an der Kante eines Grundelements befindet. Die gespeicherten Grundelemente und Pixel-Coverage-Information können ausgelesen und auf viele verschiedene Arten verarbeitet werden. Beispielsweise können dieselbe Kachel betreffende Pixel-Coverage-Masken parallel oder der Reihe nach ausgelesen werden und die dieselbe Kachel betreffenden Pixel-Coverage-Masken können gemeinsam verarbeitet werden. Pixelverarbeitung kann auf Pixel-Coverage-Masken, die zu derselben Kachel gehören, durchgeführt werden, sodass verarbeitete Daten, wo immer möglich, für Pixel-Coverage-Masken wiederverwendet werden können.
-
DirectX 10 spezifiziert ein Generieren geclippter Dreiecksdaten in einem Geometrie-Shader. DirectX 10 zeigt enthaltene Pixel-Coverage-Masken lediglich in einem skalaren Modus bei dem Pixel-Shader. Im Gegenzug dazu stellen verschiedene Ausführungsformen Pixel-Coverage-Masken pro Grundelement zur Verfügung, um ganze Kacheln mittels SIMD-vektorisiertem Code (Single Instruction, Multiple Data, SIMD) oder durch parallel über mehrere Kerne oder Threads ablaufende Tasks parallel zu verarbeiten.
-
1 stellt ein Beispiel einer Grafikverarbeitungspipeline 100 in Blockdiagramm-Format gemäß einer Ausführungsform dar. Bei verschiedenen Ausführungsformen kann Pipeline 100 zumindest basierend auf Microsofts DirectX 10 oder OpenGL 2.1 programmiert werden. Bei verschiedenen Ausführungsformen können alle Schritte mittels einer oder mehr Programmierschnittstellen (application program interfaces, API) konfiguriert werden. Grundelemente von Zeichnungen (z. B. Dreiecke, Rechtecke, Quadrate, Linien, Punkte oder Formen mit mindestens einem Eckpunkt) fließen oben an dieser Pipeline hinein und werden umgewandelt und zum Zeichnen auf einen Computerbildschirm in Bildschirmraum-Pixel gerastert.
-
Eingabe-Assembler-Schritt 102 soll Eckpunktdaten von bis zu acht Eckpunktpuffer-Eingabestreams sammeln. Andere Anzahlen an Eckpunktpuffer-Eingabestreams können gesammelt werden. Bei verschiedenen Ausführungsformen kann Eingabe-Assembler-Schritt 102 ebenfalls einen Prozess unterstützen, der „Instancing” genannt wird, bei dem Eingabe-Assembler-Schritt 102 ein Objekt mit nur einem Zeichenaufruf mehrfach reproduziert.
-
Vertex-Shader-(VS)-Schritt 104 soll Eckpunkte von Objektraum zu Clipraum umwandeln. VS-Schritt 104 soll einen einzelnen Eckpunkt lesen und einen einzelnen umgewandelten Eckpunkt als Ausgabe erzeugen.
-
Geometrie-Shader-Schritt 106 soll die Eckpunkte eines einzelnen Grundelements empfangen und die Eckpunkte von null oder mehr Grundelementen generieren. Geometrie-Shader-Schritt 106 soll Grundelemente und Linien als verbundene Streifen von Eckpunkten ausgeben. In einigen Fällen soll Geometrie-Shader-Schritt 106 in einem Prozess, der Datenverstärkung genannt wird, bis zu 1.024 Eckpunkte von jedem Eckpunkt des Vertex-Shader-Schritts abgeben. In einigen Fällen soll Geometrie-Shader-Schritt 106 ebenfalls eine Gruppe von Eckpunkten von Vertex-Shader-Schritt 104 nehmen und kombinieren, um weniger Eckpunkte abzugeben.
-
Stream-Ausgabe-Schritt 108 soll Geometriedaten von Geometrie-Shader-Schritt 106 direkt an einen Teil eines Framepuffers in Speicher 150 übertragen. Nachdem sich die Daten von Stream-Ausgabe-Schritt 108 zu dem Framepuffer bewegen, können Daten zur weiteren Verarbeitung zu jedem Punkt in der Pipeline zurückkehren. Beispielsweise kann Stream-Ausgabe-Schritt 108 eine Untermenge der durch Geometrie-Shader-Schritt 106 ausgegebenen Eckpunktinformation der Reihe nach in Ausgabepuffer in Speicher 150 kopieren.
-
Rasterizer-Schritt 110 soll Operationen wie z. B. Clipping, Culling, Fragmentgenerierung, Scissoring, Perspektiventeilung, Viewport-Transformation, Erstellung von Grundelementen und Tiefenstaffelung durchführen. Zusätzlich kann Rasterungsschritt 110 irgendeine oder alle folgenden Funktionen durchführen:
Grundelemente des Bildschirmraumes zur parallelisierten Verarbeitung mit Kacheln verbinden (z. B. Unterbereiche des Bildschirms); die Grundelemente an die Bereiche der Kacheln clippen (oder im Falle einer einzelnen Kachel den gesamten Bildschirm-Viewport); Pixel-Coverage-Masken generieren, die Listen der Pixel darstellen, die bei jeder Kachel von den Grundelementen berührt werden; und/oder interpolierte Werte von Flächen- und Materialeigenschaften für jedes berührte Pixel generieren.
-
Rasterizer-Schritt 110 soll mindestens einen Ausgabe-Stream bereitstellen. Der Ausgabe-Stream beinhaltet zwei Substreams: einen Substream für Grundelemente und einen Substream für Pixel-Coverage-Masken. Die Substreams können mit unterschiedlichen Geschwindigkeiten ausgegeben werden. Die gestreamten Daten können, sobald sie verfügbar sind, für jede gerasterte Kachel unabhängig verarbeitet werden. Dies ist bei Multi-Thread-Umgebungen zweckmäßig, bei denen Arbeit unterschiedlichen Threads zugeordnet sein kann, und, obwohl die Stream-Daten für andere Kacheln noch in der Grafikpipeline generiert werden, parallel verarbeitet werden kann.
-
Mit Bezug auf eine Verarbeitung von Pixeln in Reihenfolge der Pipeline befindet sich ein Post-Clip-Stream-Ausgabe-Schritt 112 in der Pipeline nach dem Rasterungsschritt 110 und vor dem Pixel-Shading-Schritt 114. Post-Clip-Stream-Ausgabe-Schritt 112 soll einen Grundelement-Stream in einen Teil eines Grundelementspeicherbereichs 152 speichern und er soll Pixel-Coverage-Masken in einen Teil von Kachelspeicherbereich 154 speichern. In einigen Fällen werden durch Rasterungsschritt 110 generierte Pixel-Coverage-Masken nicht in Speicherbereich 154 gespeichert. In diesem Fall ist Speicherbereich 154 nicht zugeordnet.
-
Bei verschiedenen Ausführungsformen beinhaltet der Grundelement-Stream geclippte Bildschirmraum-Grundelemente und befindet sich in Zeichenreihenfolge, ist aber nicht notwendigerweise pro Kachel gruppiert. Der Grundelement-Stream beinhaltet Bildschirmraum-Eckpunktpositionen der Grundelemente sowie Tiefeninformation pro Eckpunkt zur individuellen Interpolation. Weitere Eigenschaften pro Eckpunkt für Grundelemente beinhalten Texturkoordinaten, Farbe, Lebensdauer, Glanz, Beleuchtungsstärke und Tiefe, und diese Eigenschaften können ebenfalls in dem Stream beinhaltet sein, abhängig von den Anwendungsanforderungen für Speicherangebot, -merkmale und -leistung.
-
Bei verschiedenen Ausführungsformen referenziert der Pixel-Coverage-Stream die Grundelemente und wird pro geclipptem Grundelement gruppiert. Die Pixel-Coverage-Masken definieren, welche Bildschirmpixel von dem entsprechenden Grundelement berührt werden. Bei einigen Ausführungsformen wird dieser Pixel-Coverage-Masken-Stream nicht gespeichert. Dafür generiert individueller, anwendungsseitiger Coverage-Masken generierender Code die Pixel-Coverage-Masken. Eine Anwendung, die Pixel-Coverage-Masken generiert, kennt die Eckpunktpositionen der Grundelemente und bestimmt, ob ein Pixel basierend auf den Eckpunktpositionen zu einem Grundelement gehört. Solch eine Anwendung könnte einen Puffer in Speicher 150 zuordnen, um Pixel-Coverage-Masken in den zugeordneten Bereich im Speicher zu speichern.
-
Bei verschiedenen Ausführungsformen soll Post-Clip-Stream-Ausgabe-Schritt 112 Grundelementdaten und gegebenenfalls Pixel-Coverage-Daten in einem Speicherpuffer variabler Größe entweder in einem Streaming-Modus oder gepuffertem Modus mit einer Darstellung als verlinkte Liste speichern, die eine Verarbeitung der Grundelement- und Pixel-Coverage-Streams in Zeichenreihenfolge ermöglicht. Wenn Pixel-Coverage-Masken generiert werden, dann enthält eine Coverage-Stream-Datenstruktur einen Zeiger auf die Datenstruktur des zu ihr gehörenden Grundelements in dem Grundelement-Stream.
-
Im Streaming-Modus werden Grundelementdaten durch eine Anwendung in einer Callback-Funktion pro Kachel verarbeitet. Im Streaming-Modus stehen der Anwendung nur Teile des Streams (z. B. Größe einer Kachel) auf einmal bereit. Im Streaming-Modus können die Grundelement- und Pixel-Coverage-Daten nach dem Verarbeiten überschrieben werden. Nachdem die Anwendung die Verarbeitung dieses Kachelteiles des Streams abgeschlossen hat, ist der Teil des Streams zum Überschreiben bereit. Dieser Modus verbraucht weniger Speicher, ermöglicht eine Verarbeitung von Daten, sobald diese in einer Multi-Thread-Umgebung bereitstehen, ermöglicht aber keine Arbeitsverteilung über Kacheln.
-
Im gepufferten Modus werden Daten für den gesamten Bildschirm in einem Puffer gespeichert und eine Anwendung kann darauf zugreifen, nachdem der gesamte Stream (z. B. alle Kacheln oder eine bestimmte Anzahl oder ein bestimmter Bereich von Kacheln) generiert wurde. Demnach werden im gepufferten Modus die Pixel-Coverage-Masken aller Kacheln eines Frames in Kachelspeicherbereich 154 gespeichert. Kachelspeicherbereich 154 wird mittels Post-Clip-Ausgabe-Schritt 112 gefüllt und die Pixel-Coverage-Masken von Kacheln eines Frames sind für eine Verarbeitung bereit, wenn Pixel-Coverage-Masken aller Kacheln eines Frames gespeichert sind oder der Kachelspeicherbereich 154 gefüllt ist. Eine oder mehr Anwendungen können dann anschließend alle Daten auf einmal verarbeiten.
-
Sowohl im Streaming- als auch im gepufferten Modus werden die Daten an eine Speicherquelle gestreamt, die auf der Grafikpipeline verwaltet wird, und können nicht direkt programmiert werden und die Anwendung kann nicht direkt darauf zugreifen. Die Daten können anwendungsseitig in einer Callback-Funktion pro Kachel verarbeitet werden. Die Daten können in einem anschließenden Rendering-Pass ohne anwendungsseitiges Einschreiten in die Pipeline zurückgestreamt oder in eine Schritt-Ressource kopiert werden, sodass sie von der Anwendung asynchron gelesen werden können. Die Grafikpipeline kann die Generierung des Datenstreams beliebig schedulen, da die Grafikpipeline die Abhängigkeiten der verwalteten Stream-Speicherressourcen kennt. Eine Speicherressourcenabhängigkeit kann auftreten, wenn die Streamout-Daten in einem anschließenden Rendering-Pass verwendet werden, oder wenn die Daten nach der Verarbeitung durch die Anwendung verworfen werden können. Im gepufferten Modus kann eine Anwendung auf die Daten zugreifen, indem sie entweder eine Sperre auf der Ressource oder eine asynchrone Kopie anfragt.
-
Pixel-Shader-Schritt 114 soll die Eigenschaften jedes einzelnen Pixelfragments lesen und ein Ausgabefragment mit Farbe und Tiefenwerten erzeugen.
-
Ausgabe-Merger-Schritt 116 soll Stencil- und Tiefentests an Fragmenten von Pixel-Shader-Schritt 114 durchführen. In einigen Fällen soll Ausgabe-Merger-Schritt 116 eine Renderzielmischung durchführen.
-
Speicher 150 kann als irgendeine Form oder eine Kombination der Folgenden implementiert sein: ein flüchtiges Speichergerät, wie z. B., aber nicht beschränkt auf, ein Direktzugriffsspeicher (Random Access Memory, RAM), dynamischer Direktzugriffsspeicher (Dynamic Random Access Memory, DRAM), statischer Direktzugriffsspeicher (Static RAM, SRAM) oder jede andere Art Speicher auf Halbleiterbasis oder magnetischer Speicher.
-
2 stellt ein Beispiel einer herkömmlichen Pixel-Shader-Verarbeitung von Pixeln sowie eine Verarbeitung von Pixeln in einer Kachel gemäß verschiedener Ausführungsformen dar. Bei der herkömmlichen Pixel-Shader-Verarbeitung bei bekannten Grafikpipelines werden Pixel von Grundelementen zur Verarbeitung über mehrere Pixel-Shader verteilt. Bei verschiedenen Ausführungsformen stehen jedoch Pixel, die dieselbe Kachel betreffen, zur Verarbeitung bereit. Eine Verarbeitung von Pixeln, die dieselbe Kachel betreffen, kann gegenüber einer Verarbeitung von Pixeln mittels herkömmlicher Pixel-Shader einige Vorteile bieten, aber solche Vorteile sind von keiner Ausführungsform erforderliche Merkmale. Erstens können viele für ein einzelnes Grundelement gängige Berechnungen vorab berechnet und für alle Pixel innerhalb der Kachel wiederverwendet werden. Beispiele solcher Berechnungen sind Interpolationsmatrizen für Inside-Triangle-Tests und Early-Out-Strategien. Zweitens bietet eine Verarbeitung pro Grundelement die Flexibilität, dass benachbarte Pixeldaten kommunizieren können und ermöglicht dabei Bildschirmraum-Effekte, wie z. B. Bloom und Depth-of-Field, auf der Anwendungsseite.
-
Bei bekannten Grafikpipelines ist eine Kachelverarbeitung auf einen einzigen Kern in dem Geometrie- oder Pixel-Shader beschränkt. Verschiedene Ausführungsformen erlauben jedoch, dass Grundelemente und Pixel einer Kachel parallel von mehreren Kernen verarbeitet werden. Bei verschiedenen Ausführungsformen erlaubt die Tatsache, dass Grundelemente und Pixel nach der Rasterung verfügbar sind, dass Grundelemente nach Kacheln verarbeitet werden, wie z. B. Verarbeiten von Unterbereichen eines Bildes. Zusätzlich erlaubt die Tatsache, dass Grundelemente und Pixel nach der Rasterung verfügbar sind, dass es möglich ist, Arbeit auf der Anwendungsseite zu parallelisieren und neu zu verteilen. Beispielsweise können mehrere Kerne Grundelemente und Pixel parallel verarbeiten. Demzufolge sind, da Grundelemente und Pixel nach der Rasterung verfügbar sind, beträchtliche Leistungsverbesserungen im Vergleich zu herkömmlichen Grafikpipelines möglich.
-
Kachel-geordnete Zugriffsmuster ermöglichen bedeutende Leistungsvorteile für viele Grafikverarbeitungstechniken, die dazu neigen, eine räumliche Kohärenz im Bildschirmraum aufzuweisen. Solch eine Ordnung ermöglicht eine optimale Nutzung des Grafik-Cache und verhindert Leistungsnachteile aufgrund von falschen Cache-Abrufen.
-
3 stellt ein Beispiel einer Kernauslastung, wenn ein einzelner Kern Kacheln verarbeitet, und einer Kernauslastung nach der Verteilung einer Verarbeitung einer einzelnen Kachel auf mehrere Kerne dar. Die Diagramme stellen eine Vektorauslastung gegenüber der Zeit dar. Diagramm 302 zeigt, dass die Arbeit für jede Kachel auf einen einzelnen Kern beschränkt ist. Manche Kerne gehen schnell in den Leerlaufzustand über, während andere noch arbeitsintensive Kacheln verarbeiten. Diagramm 304 zeigt, dass die Arbeit dieser Kacheln über mehrere Kerne neu verteilt wird, um eine sehr viel bessere Kernauslastung gegenüber der Zeit zu erzielen.
-
Bei verschiedenen Ausführungsformen ermöglicht die Tatsache, dass Grundelemente und Pixel nach der Rasterung verfügbar sind, eine individuelle Verarbeitung von Grundelementen und Pixel-Coverage-Masken. Eine Callback-Routine kann jedes Mal aufgerufen werden, wenn ein Teil des Bildschirmes gerendert werden soll. Eine beispielhafte Callback-Routine ist eine Kachel-Rendering-Operation. Im Streaming-Modus können neue Grafikmerkmale und -effekte hinzugefügt werden, indem Code in der Callback-Routine hinzugefügt wird, der die individuelle Rasterungsverarbeitung von Grundelementen und Pixeln implementiert.
-
4 stellt Beispiele einer individuellen Rasterungsverarbeitung von Grundelementen und Pixeln dar. Beispielsweise kann individuelle Rasterungsverarbeitung unregelmäßige Rasterung beinhalten. Unregelmäßige Rasterung beinhaltet eine Rasterung, die beim Rendern von Bildern eine nicht zweidimensionale Raster-Datenstruktur verwendet. Beispielsweise bei unregelmäßigen Rasterungs- und Abschattungsanwendungen kann die Anwendung individuelle Interpolationstechniken implementieren, da die für die Grundelemente spezifischen Flächen- und Materialeigenschaften pro Bildschirmeckpunkt bereitgestellt werden und da Grundelement-Eckpunktwerte zur Verwendung zur Verfügung stehen. Individuelle Interpolation kann beinhalten, dass Flächeneigenschaftswerte basierend auf Grundelement-Eckpunktwerten an exzentrischen Pixelstellen bestimmt werden. Diese Grundelement-Eckpunktdaten stehen bei herkömmlichen Pixel-Shadern nicht zur Verfügung, da sie nur mit interpolierten Werten in der Mitte des Pixels bereitgestellt werden. Die individuelle Interpolation wird mittels der Anwendung durchgeführt, die Streamout verwendet, und somit können diese Ergebnisse von der Anwendung, nicht der Grafikpipeline, verwendet werden.
-
Als zweites Beispiel kann die Anwendung wählen, ob sie auf eine reguläre Coverage-Masken-Berechnung in dem Rasterizer verzichtet und stattdessen individuelle Coverage-Masken berechnet. Eine Coverage-Maske ist eine Maske, die definiert, welche Pixel von einem Grundelement berührt werden. Beispielsweise könnte ein Designer bestimmen, welche Regeln angewendet werden, um zu bestimmen, ob ein Pixel ein Grundelement berührt. Beispielsweise kann eine individuelle Coverage-Maske es einem Grundelement ermöglichen, ein Pixel zu berühren, wenn das Pixel ein Grundelement kaum berührt, sich aber nicht innerhalb des Grundelements befindet. Die Anwendung kann diese individuellen Coverage-Masken verwenden.
-
Ein unregelmäßiger Z-Puffer ist in dem Artikel
Gregory S. Johnson, William R. Mark und Christopher A. Burns "The Irregular Z-Buffer and its Application to Shadow Mapping," The University of Texas in Austin, Fakultät für Informatik, Technischer Bericht TR-04-09 beschrieben. Bei
3 des Artikels geben die gelben Punkte die Stellen innerhalb eines Pixels an, an denen Attribute des Grundelements, wie z. B. Farbe und Tiefe, berechnet sind. Diese Berechnung wird „Interpolation” genannt. Mit Bezug auf
3 des Artikels wird bei der klassischen Grafikpipeline die Tiefe an der Pixelmitte berechnet. Im Gegensatz dazu wird bei einem unregelmäßigen Z-Puffer die Tiefe (ebenfalls als „Z” bekannt) an willkürlichen Stellen bestimmt. Bei verschiedenen Ausführungsformen ermöglicht ein Speichern von Grundelementen und Pixel-Coverage-Masken, dass Anwendungen an willkürlichen Stellen interpolieren können, was bei Implementierungen eines unregelmäßigen Z-Puffers verwendet wird.
-
5 stellt ein Ablaufdiagramm eines Prozesses 500 dar, der eine Art und Weise darstellt, Grundelemente und Pixel in einem gepufferten Modus gemäß einer Ausführungsform zu speichern. Der Prozess von 5 kann mittels einer von einem Prozessor ausgeführten Anwendung durchgeführt werden. Block 502 beinhaltet, dass ein Kachelpuffer in einem Speicher zugeordnet wird, um zu einer Kachel gehörende Pixel-Coverage-Masken zu speichern, und dass ein Grundelementpuffer in einem Speicher zugeordnet wird, um Grundelemente zu speichern. Block 502 muss in den Fällen, in denen die Anwendung individuelle Pixel-Coverage-Masken generieren soll, nicht durchgeführt werden. Beispielsweise kann ein Zuordnen eines Kachelpuffers in einem Speicher, um zu einer Kachel gehörende Pixel-Coverage-Masken zu speichern, in den Fällen nicht durchgeführt werden, in denen die Anwendung individuelle Pixel-Coverage-Masken generieren soll. In den Fällen, in denen die Anwendung individuelle Pixel-Coverage-Masken generieren soll, kann die Anwendung einen Puffer zuordnen, um die individuellen Pixel-Coverage-Masken zu speichern. Beispielsweise kann eine Kachel ein Bereich von 4×4 Pixeln sein. Bei dem nachstehenden Pseudocode beispielsweise ordnet der Befehl SetFrontEndSOTargets die Puffer zu.
-
Block 504 beinhaltet, dass Aufrufe ausgegeben werden, um Grundelementeigenschaften von einem Rasterizer in den Grundelementpuffer zu speichern, und um zu Grundelementen gehörende Pixel-Coverage-Masken von einem Rasterizer in den Kachelpuffer zu speichern. Ein Ausgeben von Aufrufen, um zu Grundelementen gehörende Pixel-Coverage-Masken von einem Rasterizer in den Kachelpuffer zu speichern, kann in den Fällen nicht durchgeführt werden, in denen die Anwendung individuelle Pixel-Coverage-Masken generieren soll.
-
Block 506 beinhaltet, ein Speichern von Pixel-Coverage-Masken und Grundelementeigenschaften in zugeordnete Puffer zu sperren. Bei dem nachstehenden Pseudocode beispielsweise sperrt der Befehl FrontEndSOTargets ein Speichern in zugeordnete Puffer. Ein Sperren eines Speicherns von Pixel-Coverage-Masken in zugeordnete Puffer kann in den Fällen nicht durchgeführt werden, in denen die Anwendung individuelle Pixel-Coverage-Masken generieren soll.
-
6 stellt ein Ablaufdiagramm eines Prozesses 600 dar, der eine Art und Weise darstellt, auf Grundelementeigenschaften und Pixel-Coverage-Masken gemäß einer Ausführungsform zuzugreifen. Prozess 600 kann mittels einer hostseitigen Anwendung ausgeführt werden. Block 602 beinhaltet, Charakteristika von Grundelementeigenschaften und Kachelpuffern zu bestimmen. Block 602 kann beispielsweise beinhalten, dass ein zu jedem Puffer gehörender Überlauf-Flag abgerufen wird, und dass eine Anzahl an in dem Kachelpuffer gespeicherten Kacheln bestimmt wird. Bei dem nachstehenden Pseudocode ruft der Befehl Query_GetData den Überlauf-Flag ab.
-
Block 604 beinhaltet, dass bestimmt wird, ob ein Überlauf der Kachel- und Grundelementpuffer stattfindet. Block 604 kann beispielsweise beinhalten, dass basierend auf dem Überlauf-Flag ein Überlauf der Puffer identifiziert wird. Wird ein Überlauf ermittelt, kann der Prozess abgebrochen werden. Bei verschiedenen Ausführungsformen kann der Prozess zusätzlichen Speicherplatz in Kachel- und Grundelementpuffern verlangen; sodass ein Überlauf solcher Puffer nicht stattfindet. Der zusätzliche Speicherplatz kann mehr sein als derjenige, der den übergelaufenen Puffern zugeordnet ist. Der zusätzliche Speicherplatz kann es beispielsweise ermöglichen, mehr Kacheln zu speichern, als in dem Kachelpuffer gespeichert sind, und mehr Grundelemente zu speichern, als in dem Grundelementpuffer gespeichert sind. Bei dem nachstehenden Pseudocode beispielsweise ordnet der Befehl SetFrontEndSOTargets die Größe der Puffer zu. Demnach kann, wenn der Befehl SetFrontEndSOTargets das nächste Mal ausgeführt wird, die Größe der Puffer geändert werden.
-
Block 606 beinhaltet, dass eine Speichersperre von Puffern oder Teilen von Puffern angefragt wird, die Grundelementeigenschaften und dazugehörige Pixel-Coverage-Masken speichern. Eine Speichersperre kann beinhalten, dass andere Prozesse vom Überschreiben der Daten in den Puffern von Interesse ausgeschlossen werden. Bei dem nachstehenden Pseudocode verursacht der Befehl ViewLock eine Sperrung eines Teiles eines Kachelpuffers.
-
Block 608 beinhaltet, dass gespeicherte Grundelementeigenschaften und dazugehörige Pixel-Coverage-Masken abgerufen werden. Abgerufene Grundelementdaten können auf jegliche Art und Weise zur Verarbeitung freigegeben werden. Die mit Bezug auf 4 beschriebenen Prozesse können beispielsweise die Grundelement- und Pixeldaten verarbeiten.
-
Block 610 beinhaltet, dass die Speichersperre des Teiles des Puffers, der gesperrt war, freigegeben wird. Bei dem nachstehenden Pseudocode gibt der Befehl ViewUnlock den gesperrten Teil des Puffers frei, sodass der Puffer von anderen Prozessen gelesen oder geschrieben werden kann.
-
Nachstehend wird Pseudocode für eine Art und Weise bereitgestellt, Grundelemente und Pixel (5) zu speichern und auf gespeicherte Grundelemente und Pixel zuzugreifen (6).
-
-
-
-
-
Ausführungsformen der vorliegenden Erfindung können als irgendeine Form oder eine Kombination der Folgenden implementiert sein: ein oder mehr Mikrochips oder integrierte Schaltungen, die mittels eines Motherboards verbunden sind, fest verdrahtete Logik, von einem Speichergerät gespeicherte und von einem Mikroprozessor ausgeführte Software, Firmware, ein anwendungsspezifischer integrierter Schaltkreis (application specific integrated circuit, ASIC) und/oder ein Field Programmable Gate Array (FPGA). Der Begriff „Logik” kann beispielsweise Software oder Hardware und/oder Kombinationen von Software und Hardware beinhalten.
-
Die hierin beschriebenen Grafik- und/oder Videoverarbeitungs-Techniken können in verschiedenen Hardware-Architekturen implementiert werden. Beispielsweise kann Grafik- und/oder Videofunktionalität innerhalb eines Chipsatzes integriert sein. Alternativ kann ein separater Grafik- und/oder Videoprozessor verwendet werden. Als noch weitere Ausführungsform können die Grafik- und/oder Videofunktionen durch einen Universalprozessor, einschließlich eines Mehrkernprozessors, implementiert werden. Bei einer weiteren Ausführungsform können die Funktionen bei einem Gerät der Unterhaltungselektronik, wie z. B. einem tragbaren mobilen Computer oder Mobiltelefon mit einem Display-Gerät implementiert sein, um von der Grafikpipeline verarbeitete Bilder oder ein Video anzuzeigen.
-
Ausführungsformen der vorliegenden Erfindung können beispielsweise als ein Computerprogramm-Produkt bereitgestellt sein, das ein oder mehr maschinenlesbare Medien mit darauf gespeicherten maschinenausführbaren Befehlen beinhalten kann, die, wenn sie von einer oder mehr Maschinen, wie z. B. einem Computer, einem Netzwerk von Computern oder anderen elektronischen Geräten ausgeführt werden, dazu führen können, dass die eine oder die mehreren Maschinen Operationen in Übereinstimmung mit Ausführungsformen der vorliegenden Erfindung ausführen. Ein maschinenlesbares Medium kann beinhalten, ist aber nicht beschränkt auf, Disketten, optische Disks, CD-ROMs (Compact Disc-Read Only Memories) und magnetooptische Disks, ROMs (Read Only Memories), RAMs (Random Access Memories), EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetische oder optische Karten, Flash-Memory oder andere Art von Medien/maschinenlesbarem Medium, das zum Speichern maschinenausführbarer Befehle geeignet ist.
-
Die Zeichnungen und die vorstehende Beschreibung gaben Beispiele der vorliegenden Erfindung. Obwohl sie als eine Anzahl ganz verschiedener funktionaler Objekte dargestellt sind, ist es für Fachleute selbstverständlich, dass eins oder mehrere solcher Elemente sehr wohl zu einzelnen funktionalen Elementen kombiniert werden können. Alternativ können bestimmte Elemente in mehrere funktionale Elemente geteilt werden. Elemente aus einer Ausführungsform können einer weiteren Ausführungsform hinzugefügt werden. Beispielsweise können hierin beschriebene Reihenfolgen von Prozessen verändert werden und sind nicht auf die hierin beschriebene Art und Weise beschränkt. Außerdem müssen die Handlungen eines jeden Ablaufdiagramms weder in der gezeigten Reihenfolge implementiert sein, noch müssen alle Vorgänge unbedingt ausgeführt werden. Ebenfalls können diejenigen Vorgänge, die nicht von anderen Vorgängen abhängen, parallel mit den anderen Vorgängen ausgeführt werden. Der Umfang der vorliegenden Erfindung ist jedoch keineswegs durch diese spezifischen Beispiele beschränkt. Zahlreiche Variationen, entweder ausdrücklich in der Beschreibung gegeben oder nicht, wie z. B. Unterschiede in Struktur, Abmessung und Verwendung von Material, sind möglich. Der erfindungsgemäße Umfang ist zumindest so breit, wie von den folgenden Ansprüchen gegeben.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- Segal, M. und Akeley, K. „The OpenGL Graphics System: A Specification (Version 2.0)” (2004) [0002]
- The Microsoft DirectX 9 Programmable Graphics Pipe-line, Microsoft Press (2003) [0002]
- D. Blythe „The Direct3D 10 System”, Microsoft Corporation (2006) [0002]
- Gregory S. Johnson, William R. Mark und Christopher A. Burns ”The Irregular Z-Buffer and its Application to Shadow Mapping,” The University of Texas in Austin, Fakultät für Informatik, Technischer Bericht TR-04-09 [0037]
