DE102014018567A1

DE102014018567A1 - PRIMITIVENVERARBEITUNG IN EINEM GRAFlKVERARBEITUNGSSYSTEM

Info

Publication number: DE102014018567A1
Application number: DE102014018567.2A
Authority: DE
Inventors: c/o Imagination Technologies L Redshaw Jonathan
Original assignee: Imagination Technologies Ltd
Current assignee: Imagination Technologies Ltd
Priority date: 2013-12-13
Filing date: 2014-12-15
Publication date: 2015-06-18
Also published as: US20220020206A1; US11748941B1; US20170337729A1; GB2520365B; CN104715503B; US11164365B2; US20150170407A1; CN104715503A; US9830738B2; GB2520365A; CN110264557A; US11538215B2; US20230419598A1; US20200105052A1; CN110264557B; US20210065438A1; US10529123B2; GB201322041D0; US10867433B2

Abstract

Ein Grafikverarbeitungssystem weist einen Renderingraum auf, der in Kacheln unterteilt ist. Primitive innerhalb der Kacheln werden verarbeitet, um eine verdeckte Oberflächenentfernung durchzuführen und ein Texturieren auf die Primitiven anzuwenden. Das Grafikverarbeitungssystem enthält mehrere Tiefenpuffer, durch die ein Verarbeitungsmodul Primitive einer Kachel durch Zugriff auf einen der Tiefenpuffer verarbeitet, während Primitivenidentifikatoren einer anderen, teilweise verarbeiteten Kachel in einem anderen der Tiefenpuffer gespeichert werden. Somit kann das Grafikverarbeitungssystem „mehrere Kacheln in Bearbeitung” aufweisen, was die Effizienz des Grafikverarbeitungssystems erhöhen kann.

Description

Hintergrund
In einem 3D-Grafikverarbeitungssystem sind Objekte einer Szene mit Gruppen von Primitiven dargestellt, die üblicherweise während des Renderns (bzw. Rasterns) der Szene projiziert, scankonvertiert, texturiert und schattiert werden. Ein Primitiv weist eine einfache geometrische Form, oft ein Dreieck, auf, die von den Positionen eines oder mehrerer Ecken (z. B. drei Ecken im Fall, dass das Primitiv ein Dreieck ist) definiert wird, auf die eine Textur angewandt werden kann. Das Rendern einer 3D-Szene verarbeitet die Primitive, um ein Bild zu bilden, das eine Anordnung von Bildpixeln umfasst. Ein Schritt im Renderingvorgang ist es, für jede aus einer Mehrzahl von Abtastpositionen des Bilds zu bestimmen, welche(s) (der) Primitive) sichtbar ist/sind. Dieser Vorgang wird als verdeckte Oberflächenentfernung (engl. hidden surface removal, HSR) bezeichnet. Primitive oder Teile von Primitiven, die von anderen Primitiven verdeckt werden, müssen in der gerenderten Darstellung nicht weiter beachtet werden. Um eine HSR durchzuführen, werden die Tiefen (d. h. die Abstände vom Ansichtspunkt aus) von Primitiven in der Szene für jede Abtastposition berücksichtigt, um zu bestimmen, welche Primitive an jeder Pixelposition sichtbar sind. Primitive können undurchsichtig oder transluzent sein. Ein Renderingverfahren, in dem Texturen verwendet werden, um Löcher in ansonsten undurchsichtigen Primitiven zu bilden, ist als „Durchgriff” (engl. punch through) bekannt. Für undurchsichtige Primitive wird gewöhnlich der endgültige gerenderte Pixelwert an einer Pixelposition (die einer oder mehrerer der Abtastpositionen entsprechen kann) von dem texturierten Primitiv angegeben, das den kleinsten Tiefenwert an dieser Pixelposition aufweist. Für transluzente Primitive kann der endgültige gerenderte Pixelwert an einer Pixelposition von einer Mischung aus mehr als einem der texturierten Primitive, die die kleinsten Tiefenwerte an dieser Pixelposition aufweisen, angegeben werden. Wenn eine Szene Primitive enthält, deren Texturen einen Durchgriff umfassen, kann der endgültige gerenderte Pixelwert an einer Pixelposition von Primitiven bestimmt werden, die nicht die Primitive mit dem kleinsten Tiefenwert an dieser Pixelposition sind.
1 zeigt ein Grafikverarbeitungssystem 100, das ein Verarbeitungsmodul 102, das als Bildsyntheseprozessor (ISP) bezeichnet werden kann, einen Tiefenpuffer 104, der als Z-Puffer bezeichnet werden kann, ein Tag-Sortiermodul 106, eine Texturier- und Schattierungs-Engine 108, die als einheitliches Schattierungscluster (USC) bezeichnet werden kann, und einen Pixelpuffer 110 umfasst. Im Betrieb werden Primitive (z. B. Eckpunktkoordinaten und Primitivenidentifikatoren) an dem ISP 102 empfangen, und der ISP führt eine HSR auf den Primitiven durch, um zu bestimmen, welche Primitive an jeder von einer Mehrzahl von Abtastpositionen des zu rendernden Bilds sichtbar sind. Um die HSR für ein typisches Rendering umzusetzen, ist der ISP programmiert, für jede Abtastposition im Tiefenpuffer 104 einen Tiefenwert zu speichern, der die Tiefe des nächstgelegenen Primitivs darstellt, das bisher von dem ISP 102 verarbeitet wurde, so dass der ISP 102 die Tiefe eines Primitivs, das gerade verarbeitet wird, mit den im Tiefenpuffer 104 gespeicherten Tiefenwerten vergleichen kann, um zu bestimmen, ob das aktuelle Primitiv sichtbar ist. Die Ergebnisse der HSR, die vom ISP 102 durchgeführt wird, werden verwendet, um die Tiefenwerte, die im Tiefenpuffer 104 gespeichert sind, entsprechend zu aktualisieren. Es gilt anzumerken, dass in manchen Systemen der Tiefenpuffer 104 und das Tag-Sortiermodul 106 als Elemente des ISP 102 beschrieben werden können.
Das Tag-Sortiermodul 106 umfasst einen Tag-Puffer, der ausgelegt ist, für jede Abtastposition einen Primitivenidentifikator (ID) eines sichtbaren Primitivs an dieser Abtastposition, wie von der von dem ISP 102 durchgeführten HSR bestimmt, zu speichern. Das Tag-Sortiermodul 106 umfasst ebenfalls eine Steuereinheit, um das Aktualisieren und das Entleeren (engl. flushing) des Tag-Puffers zu steuern. Primitivenidentifikatoren werden in das USC 108 entleert. In Reaktion auf ein Empfangen der entleerten Primitivenidentifikatoren ruft das USC 108 die identifizierten Primitive ab und ruft Texturierdaten ab, um die Texturierung und Schattierung auf die Primitive, die von den entleerten Primitiven-IDs identifiziert wurden, anzuwenden. Die Steuereinheit im Tag-Sortiermodul 106, steuert, wann Primitivenidentifikatoren in das USC 108 entleert werden sollen. Beispielsweise können Primitivenidentifikatoren in das USC 108 entleert werden, wenn die Primitive für das Bild alle von dem ISP 102 verarbeitet wurden. Primitivenidentifikatoren können ebenfalls in das USC 108 entleert werden, wenn Primitivenidentifikatoren von transluzenten Primitiven oder Primitiven mit Texturierung, die einen Durchgriff umfassen, im Tag-Puffer gespeichert werden sollen. Dies geschieht, damit diese Primitive richtig gemischt werden können.
Kurzfassung
Diese Kurzfassung ist bereitgestellt, um eine Auswahl von Konzepten in vereinfachter Form zu präsentieren, die unten in der detaillierten Beschreibung weiter beschrieben sind. Diese Kurzfassung soll keine Hauptmerkmale oder wesentlichen Eigenschaften des beanspruchten Gegenstands identifizieren, noch soll sie verwendet werden, um den Schutzumfang des beanspruchten Gegenstands zu beschränkten.
Darin ist ein Grafikverarbeitungssystem mit einem Renderingraum (Rasterungsraum) bzw. Wiedergaberaum (engl. rendering space), der in Kacheln (engl. tile) unterteilt ist, bereitgestellt, wobei das Grafikverarbeitungssystem umfasst: mehrere Tiefenpuffer, wobei jeder der Tiefenpuffer ausgelegt ist, zu einer Zeit dynamisch einer Kachel zugewiesen zu sein, und ausgelegt ist, einen Tiefenwert für jede Abtastposition (engl. sample position) innerhalb der Kachel zu speichern; und ein Verarbeitungsmodul, das ausgelegt ist, Primitive und Kacheldaten zu empfangen, wobei für jedes Primitiv die Kacheldaten eine oder mehrere Kacheln angeben, in denen dieses Primitiv verarbeitet werden wird, und wobei das Verarbeitungsmodul ausgelegt ist, eine verdeckte Oberflächenentfernung für ein Primitiv einer Kachel durch Vergleich von Tiefenwerten für dieses Primitiv durchzuführen, wobei Tiefenwerte in dem der Kachel zugewiesenen Tiefenpuffer gespeichert sind, während ein anderer der Tiefenpuffer Tiefenwerte für eine andere teilweise verarbeitete Kachel speichert.
Außerdem ist ein Verfahren zum Verarbeiten von Primitiven in einem Grafikverarbeitungssystem mit einem Renderingraum bereitgestellt, der in Kacheln unterteilt ist, wobei das Verfahren umfasst: Speichern von Tiefenwerten in mehreren Tiefenpuffern, wobei jeder der Tiefenpuffer zu einer Zeit dynamisch einer Kachel zugewiesen und ausgelegt ist, einen Tiefenwert für jede Abtastposition innerhalb der Kachel zu speichern; Empfangen von Primitiven und Kacheldaten an einem Verarbeitungsmodul, wobei für jedes Primitiv die Kacheldaten eine oder mehrere Kacheln angeben, in denen dieses Primitiv verarbeitet werden wird, und Durchführen einer verdeckten Oberflächenentfernung am Verarbeitungsmodul für ein Primitiv einer Kachel durch Vergleich von Tiefenwerten für dieses Primitiv, wobei Tiefenwerte in dem der Kachel zugewiesenen Tiefenpuffer gespeichert sind, während ein anderer der Tiefenpuffer Tiefenwerte für eine andere teilweise verarbeitete Kachel speichert.
Es ist ebenfalls ein computerlesbarer Code bereitgestellt, der ausgelegt ist, die Schritte jedes der Verfahren der hier beschriebenen Beispiele durchzuführen, wenn der Code auf einem Computer ausgeführt wird. Außerdem kann ein computerlesbarer Code zum Erstellen jeder der Grafikverarbeitungssysteme der hier beschriebenen Beispiele bereitgestellt sein. Der computerlesbare Code kann auf einem computerlesbaren Speichermedium codiert sein.
Die obigen Merkmale können, wo angemessen, kombiniert werden, wie einem Fachmann klar ersichtlich ist, und können mit jedem der Aspekte der hier beschriebenen Beispiele kombiniert werden.
Kurzbeschreibung der Zeichnungen
Beispiele werden nun im Detail unter Bezugnahme auf die begleitenden Zeichnungen beschrieben, in denen:
1 eine schematische Darstellung eines Grafikverarbeitungssystems ist;
2 vier Kacheln eines Renderingraums darstellt;
3 eine schematische Darstellung eines Grafikverarbeitungssystems ist, das eine Mehrzahl von Tiefenpuffern ausführt;
4 ein Flussdiagramm für ein Verfahren zum Verarbeiten von Primitiven im in 3 dargestellten Grafikverarbeitungssystem ist;
5a eine Darstellung ist, die Primitive darstellt, die in einer Kachel in einem ersten Beispiel sichtbar sind;
5b entsprechende Spalten von einer Mehrzahl von Tag-Puffern zeigt, die Primitivenidentifikatoren für die in 5a dargestellten Primitive speichern;
5c eine Darstellung ist, die Primitive darstellt, die in einer Kachel in einem zweiten Beispiel sichtbar sind;
5d entsprechende Spalten einer Mehrzahl von Tag-Puffern zeigt, die Primitivenidentifikatoren für die in 5c dargestellten Primitive speichern;
6 eine schematische Darstellung eines Grafikverarbeitungssystems ist, das eine Mehrzahl von Tag-Puffern ausführt;
7 ein Flussdiagramm für ein Verfahren zum Verarbeiten von Primitiven im in 6 dargestellten Grafikverarbeitungssystem ist;
8 eine schematische Darstellung eines Grafikverarbeitungssystems ist, das eine Mehrzahl von Tiefenpuffern und eine Mehrzahl von Tag-Puffern ausführt; und
9a und 9b ein Flussdiagramm für ein Verfahren zum Steuern der Auswahl von Tag-Puffern und dem Entleeren von Tag-Puffern zeigen.
Der Fachmann wird anerkennen, dass die dargestellten Elementabgrenzungen (z. B. Kästen, Gruppen von Kästen oder anderen Formen) in den Zeichnungen ein Beispiel der Abgrenzungen darstellen. Es kann in manchen Beispielen vorkommen, dass ein Element als mehrere Elemente konstruiert ist oder dass mehrere Elemente als ein Element konstruiert sind. In allen Figuren werden gleiche Bezugsziffern, wo angebracht, verwendet, um ähnliche Merkmale zu bezeichnen.
Detaillierte Beschreibung
Das im obigen Hintergrundabschnitt beschriebene Grafikverarbeitungssystem 100 ist effizient, da eine verdeckte Oberflächenentfernung im ISP 102 durchgeführt wird und da nur sichtbare Oberflächen zum Texturieren und Schattieren am USC 108 weitergeleitet werden. Systeme, die ein Texturieren und Schattieren vor einer verdeckten Oberflächenentfernung durchführen, können möglicherweise weniger effizient sein, da die Arbeit, die für das Texturieren und Schattieren eines Objekts verwendet wird, umsonst ist, falls das Objekt später von anderen Objekten in der Szene verdeckt wird.
Das System aus 1 ist am effizientesten, wenn nur undurchsichtige Primitive verarbeitet werden, wenn eine verdeckte Oberflächenentfernung für eine ganze Szene oder einen Teil einer Szene abgeschlossen werden kann, bevor mit dem Texturieren und dem Schattieren begonnen wird. Die Primitiven-IDs der undurchsichtigen Objekte werden von dem Tag-Sortierer 106 gesammelt, so dass, wenn jedes undurchsichtige Primitiv von dem ISP 102 verarbeitet wurde, der Tag-Puffer einen Identifikator für das Primitiv speichert, das an jeder Abtastposition sichtbar ist. Der Tag-Puffer kann dann entleert werden, wodurch die Primitiven-IDs an das USC 108 gesendet werden, so dass die entsprechenden identifizierten Primitive texturiert und schattiert werden können. Der Tag-Sortierer 106 wird so bezeichnet, da Primitiven-IDs gruppiert oder sortiert werden können, wenn sie aus dem Puffer entleert werden, so dass das USC 108, wann immer möglich, dazu in der Lage ist, IDs aus einem einzelnen Primitiv oder aus Primitiven mit ähnlichen Texturierungs- und Schattierungsanforderungen als eine Gruppe zu verarbeiten. Ein Sortieren der Primitiven-IDs kann deshalb zu einer verbesserten Cache-Leistung im USC 108 führen. Wenn eine Szene nur aus undurchsichtigen Primitiven besteht, muss der Tag-Puffer nur einmal entleert werden.
Das System aus 1 weist in manchen Situationen Probleme auf, wie wenn eine Szene transluzente Primitive oder Primitive mit Durchgriff enthält.
Transluzenz bedeutet, dass Licht dazu in der Lage ist, durch Objekte zu dringen. Wenn transluzente Objekte gerendert werden, ist es nicht länger ausreichend, nur die Primitive mit dem kleinsten Tiefenwert zu rendern, da es notwendig sein kann, durch diese Primitive auf die dahinterliegenden Primitive zu blicken. Die Farbe eines Pixels im gerenderten Bild kann durch Mischen der Farbe eines transluzenten Primitivs mit der Farbe eines anderen oder mehrerer anderer Primitive gebildet werden. Typischerweise wird das gerenderte Bild durch Mischen von Schichten von transluzenten Objekten gebildet, angefangen mit den Primitiven mit dem größten Tiefenwert und endend mit den Primitiven mit dem kleinsten Tiefenwert. Nicht alle Renderingsysteme sind dazu in der Lage, transluzente Objekte zu sortieren, somit liegt es oftmals an der Softwareanwendung (z. B. einem Spiel), die Primitive in einer vorsortierten Reihenfolge von hinten nach vorne zu präsentieren. In einem Beispiel einer Transluzenzverarbeitung werden transluzente Primitive im ISP 102 verarbeitet (z. B. um zu bestimmen, ob sie hinter existierenden undurchsichtigen Objekten an jeder Abtastposition versteckt sind), und der Tag-Puffer wird nach jedem transluzenten Primitiv entleert, so dass das Primitiv texturiert und schattiert werden kann und mit zuvor texturierten und schattierten Primitiven in Pixelpuffer 110 vermischt werden kann. Falls die Anwendung nach den transluzenten Primitiven weitere undurchsichtige Primitive sendet, können die Ergebnisse des Vermischens verdeckt sein.
Durchgriff bezieht sich auf ein Renderingverfahren, bei dem eine Textur verwendet werden kann, um Löcher zu ansonsten undurchsichtigen Primitiven hinzuzufügen. Löcher in einem Primitiv sollten nicht dazu führen, dass der ISP 102 den Tiefenpuffer 104 aktualisiert, sondern das System aus 1 bewertet nur die Texturen und bestimmt deshalb die Position der Löcher im USC 108. Das System aus 1 muss deshalb einige zusätzliche Schritte verwenden, um Objekte mit Durchgriff zu rendern. In einem Beispiel einer Durchgriffverarbeitung wird ein Durchgriff-Primitiv, das am ISP 102 ankommt, abgetastet und kann wieder gegenüber dem Tiefenpuffer 104 getestet werden, um jegliche Teile zu bestimmen, die hinter existierenden undurchsichtigen Objekten versteckt sind. Jegliche Teile des Durchgriff-Objekts, die nicht versteckt sind, werden an den Tag-Sortierer 106 gesendet, der Tiefenpuffer 104 wird jedoch nicht aktualisiert. Der Tag-Puffer wird sofort entleert, was ein Entleeren jeglicher existierender Inhalte des Tag-Puffers beinhalten kann, dann wird das Durchgriff-Primitiv an das USC 108 gesendet. Das USC 108 führt wenigstens die Texturierungs- und Schattierungsvorgänge durch, die erforderlich sind, um zu bestimmen, ob irgendwelche Teile der Primitive Löcher aufweisen und es sendet die undurchsichtigen Teile durch den mit „PT-Feedback” markierten Pfad, der mit einer gepunkteten Linie in 1 dargestellt ist, wieder zurück an den ISP 102. Der ISP 102 führt einen weiteren Tiefentest durch, da sich der Zustand des Tiefenpuffers 104 während der Zeit, die erforderlich war, um das Durchgriff-Primitiv zu texturieren und zu schattieren, geändert haben kann und jegliche Teile des Primitivs, die sichtbar bleiben, werden als Primitiven-IDs im Tag-Puffer gespeichert. Wenn die Primitiven-ID schlussendlich zum zweiten Mal in das USC 108 entleert wird, wird der Rest des Texturierens und Schattierens durchgeführt, und Bildpixel werden in Pixelpuffer 110 gespeichert.
Ein Entleeren der Primitivenidentifikatoren für transluzente Primitive oder Primitive mit Durchgriff, wie oben beschrieben, kann unwirksam sein, da manche der entleerten Primitivenidentifikatoren Primitive betreffen können, die anschließend von anderen Primitiven verdeckt werden, die der ISP 102 erst verarbeiten muss. Außerdem kann ein Entleeren von Primitivenidentifikatoren jedes Mal, wenn transluzente Primitive oder Primitive mit Durchgriff-Texturen verarbeitet werden, dazu führen, dass viele Entleerungen durchgeführt werden (z. B. mit jeder Entleerung, umfassend eine kleine Anzahl von Primitivenidentifikatoren). Oftmals ist es weit weniger wirksam, viele kleine Entleerungen verglichen mit wenigeren größeren Entleerungen von Primitivenidentifikatoren in das USC 108 durchzuführen.
Außerdem verarbeitet der ISP 102 in einem Grafikverarbeitungssystem, in dem ein Renderingraum in eine Mehrzahl von Regionen oder „Kacheln” unterteilt ist, die unabhängig verarbeitet werden, Primitive im in 1 dargestellten Grafikverarbeitungssystem 100 nur für eine Kachel auf einmal. Wenn der ISP 102 die Primitive für eine Kachel verarbeitet hat (z. B. durch Durchführen einer HSR für die Primitive der Kachel), dann kann er beginnen, die Primitive einer nächsten Kachel zu verarbeiten. Der Tiefenpuffer 104 speichert Tiefenwerte für jede Abtastposition innerhalb einer Kachel, die der ISP 102 gerade verarbeitet; und der Tag-Puffer im Tag-Sortiermodul 106 speichert Primitivenidentifikatoren für jede Abtastposition innerhalb der Kachel, die der ISP 102 gerade verarbeitet. Das Grafikverarbeitungssystem 100, das in 1 dargestellt ist, ist deshalb auf ein Verarbeiten von Primitiven für Kacheln, Kachel für Kachel, beschränkt, so dass alle Primitive einer Kachel verarbeitet werden, bevor Primitive der nächsten Kachel verarbeitet werden. Das heißt, dass die Kacheln auf serielle Weise, d. h. aufeinanderfolgend verarbeitet werden.
Ausführungsformen werden nun ausschließlich beispielhaft beschrieben.
Wie oben angegeben, kann ein Grafikverarbeitungssystem einen Renderingraum aufweisen, der in eine Mehrzahl von Kacheln unterteilt ist, die unabhängig verarbeitet werden. 2 zeigt vier Kacheln 202 ₁ bis 202 ₄ eines Renderingraums 200, der zum Rendern eines Bilds verwendet wird. Der Renderingraum 200 kann mehr als vier Kacheln (oder weniger als vier Kacheln) umfassen, aber der Klarheit halber sind in 2 nur vier Kacheln dargestellt. Wie in 2 angegeben, weist jede der Kacheln in diesem Beispiel eine Größe von 32×32 Abtastpositionen auf. Eine Abtastposition stellt eine Position auf dem dargestellten Bild dar und kann mit den tatsächlichen Pixelpositionen des endgültigen Bilds korrespondieren, oder nicht, wodurch die Pixelpositionen die Positionen sind, für die Pixelwerte bestimmt und in einem Pixelpuffer zum Darstellen eines Bilds gespeichert werden. Die Primitive werden an jeder Abtastposition abgetastet, um „Fragmente” zu erschaffen, die dann im Rest des Renderingsystems verarbeitet werden, z. B. durch verdeckte Oberflächenentfernung, Texturieren und Schattieren. In manchen Beispielen kann es mehr Abtastpositionen als Pixelpositionen geben, was ermöglicht, dass das Verarbeiten der Primitive bei einer feineren Körnigkeit als die Körnigkeit der Pixel des endgültigen Bilds erfolgen kann. Dies kann zur Verwendung von Anti-Alias-Verfahren von Nutzen sein, um das Auftreten von gezackten Kanten im dargestellten Bild zu reduzieren. Wie in 2 dargestellt, wird jede Kachel ferner in Mikrokacheln 204 unterteilt, die in diesem Beispiel eine Größe von 4×4 Abtastpositionen aufweisen. Die Verwendung der Mikrokacheln wird in den unten beschriebenen Beispielen weiter beschrieben. Es gilt anzumerken, dass die Kacheln und Mikrokacheln in anderen Beispielen unterschiedliche Größen und/oder Formen als jene, die im in 2 dargestellten Beispiel gezeigt sind, aufweisen können.
3 zeigt ein Grafikverarbeitungssystem 300, das ausgelegt ist, zu ermöglichen, dass die Verarbeitung von Primitiven zwischen Primitiven von unterschiedlichen Kacheln umschalten kann, bevor alle Primitive einer bestimmten Kachel fertig verarbeitet wurden. In diesem Sinn kann das Grafikverarbeitungssystem 300 „mehrere Kacheln in Bearbeitung” (engl. in flight) aufweisen, d. h. mehrere Kacheln, für die die Primitive zu einer gegebenen Zeit teilweise verarbeitet werden. Um dies zu erzielen, umfasst das Grafikverarbeitungssystem 300 ein Verarbeitungsmodul 302, einen Tiefenpufferblock 304, ein Tag-Sortiermodul 306, eine Texturiereinheit 308, einen Pixelpuffer 310 und ein Steuermodul 316. Dieses Beispiel umfasst ebenfalls einen Block von Warteschlangen 312. Im in 3 dargestellten Beispiel umfasst der Block von Warteschlangen 312 vier Warteschlangen 314 ₁ bis 314 ₄; der Tiefenpufferblock 304 umfasst vier Tiefenpuffer 318 ₁ bis 318 ₄; das Tag-Sortiermodul 306 umfasst vier Tag-Puffer 320 ₁ bis 320 ₄ und ein Tag-Steuermodul 322; und die Texturiereinheit 308 umfasst vier Texturier-Engines 324 ₁ bis 324 ₄. Die Elemente des Grafikverarbeitungssystems 300, die in 3 dargestellt sind, können in Hardware, Software oder einer Kombination daraus ausgeführt sein.
Der Betrieb des Grafikverarbeitungssystems 300 wird unter Bezugnahme auf das in 4 dargestellte Flussdiagramm beschrieben. Primitive von unterschiedlichen Kacheln werden an dem Block von Warteschlangen 312 des Grafikverarbeitungssystems 300 empfangen. Die Primitive können Objekte einer zu rendernden Szene betreffen und können z. B. von einer Anwendung (z. B. einem Spiel), die auf derselben Vorrichtung (z. B. einer mobilen Benutzervorrichtung) läuft wie das Grafikverarbeitungssystem 300, an das Grafikverarbeitungssystem 300 gesendet werden. Den Primitiven werden Kacheldaten zugewiesen, die eine oder mehrere Kacheln 202 angeben, in denen die Primitive verarbeitet werden. Die Kacheldaten können in einem vorherigen Vorgang zum Bestimmen, welche Primitive in welchen Kacheln vorhanden sind, bestimmt worden sein, der hier nicht genau beschrieben ist. Jedes der Primitive wird von Primitivendaten beschrieben, die eine Angabe der Positionen der Eckpunkte des Primitivs umfassen und andere Informationen wie eine Angabe einer Textur, die auf das Primitiv angewandt werden soll, umfassen können. Jede der Warteschlangen 314 ₁ bis 314 ₄ ist ausgelegt, die Primitive für eine entsprechende Kachel nach der anderen zu speichern. In den hier beschriebenen Beispielen geben die Kacheldaten an, zu welcher Kachel jedes Primitiv gehört. In den oben beschriebenen Beispielen müssen die Kacheldaten, die zu den Primitiven gehören, nicht in den Warteschlangen gespeichert werden, um anzugeben, welche Kachel zu welchem Primitiv gehört, da eine Warteschlange zu jeder Zeit nur einer Kachel zugewiesen ist, und tun dies auch nicht. Jedoch können die Kacheldaten in manchen anderen Beispielen in den Warteschlangen mit den Primitiven gespeichert werden. Die Warteschlangen 314 können z. B. als First-In-First-Out(FIFO)-Puffer ausgeführt sein. Das in 3 dargestellte Grafikverarbeitungssystem 300 kann zu einer gegebenen Zeit bis zu vier Kacheln in Bearbeitung aufweisen. In manchen Beispielen kann es eine unterschiedliche Anzahl von Warteschlangen im Block 312 geben und in manchen Beispielen könnte es keine Warteschlangen geben und die Primitive und die Kacheldaten können direkt an dem Verarbeitungsmodul 302 ohne vorheriges Speichern der Primitive und der Kacheldaten in irgendeiner Warteschlange, wie in 3 dargestellt, empfangen werden.
In Schritt S402 empfängt das Verarbeitungsmodul 302 Primitive und die zugehörigen Kacheldaten. Die Kacheldaten identifizieren die Kachel oder Kacheln, in denen das Primitiv verarbeitet wird, und sollten wenigstens eine der Kacheln identifizieren, der die Ressourcen (z. B. der Tiefen- und der Tag-Puffer) des Verarbeitungsmoduls 302 gerade zugewiesen sind. Im in 3 dargestellten Beispiel werden die Primitive und die Kacheldaten an dem Verarbeitungsmodul 302 von einer der Warteschlangen 314 ₁ bis 314 ₄ empfangen. Da jede der Warteschlangen 314 ₁ bis 314 ₄ ausgelegt ist, die Primitive zu jeder Zeit nur für eine entsprechende Kachel zu speichern, können die Kacheldaten einfach die Identität der Warteschlange, von der das Primitiv empfangen wird, umfassen.
In Schritt S404 führt das Verarbeitungsmodul 302 die verdeckte Oberflächenentfernung (HSR) für ein Primitiv einer Kachel durch Vergleichen der Tiefenwerte für dieses Primitiv mit Tiefenwerten, die im der Kachel zugewiesenen Tiefenpuffer gespeichert sind, durch. Jeder der Tiefenpuffer 318 ₁ bis 318 ₄ ist ausgelegt, nur einer Kachel gleichzeitig zugewiesen zu sein und ist ausgelegt, einen Tiefenwert für jede Abtastposition innerhalb der jeweiligen dazugehörigen Kachel zu speichern. Beispielsweise können die vier Tiefenpuffer 318 ₁ bis 318 ₄ jeweils vier Kacheln (Kachel A bis Kachel D) zugewiesen sein. Die vier Kacheln, zu denen die Tiefenpuffer gehören, können aus jeder Position auf der Renderingoberfläche ausgewählt sein. Es ist nicht notwendig, dass die Kacheln benachbart zueinander sind. In manchen Beispielen können die Kacheln aus Positionen in mehr als einer Renderingoberfläche ausgewählt sein.
Die HSR, die von dem Verarbeitungsmodul 302 für ein Primitiv durchgeführt wird, umfasst ein Bestimmen, welche Abtastpositionen innerhalb der Primitive liegen (basierend auf den Eckpunktpositionen der Primitive), und ein Durchführen von Tiefentests an diesen Abtastpositionen basierend auf den Tiefenwerten, die im relevanten Tiefenpuffer 318 gespeichert sind.
Als Teil von Schritt S404 kann das Verarbeitungsmodul 302 einen oder mehrere der Tiefenwerte, die im Tiefenpuffer 318 gespeichert sind, der zu der Kachel, die gerade verarbeitet wird, gehört, aktualisieren.
Das Verarbeitungsmodul 302 weist eine Verarbeitungseinheit auf, die nur auf einem Primitiv gleichzeitig arbeitet. Jedoch ist sie dazu in der Lage, zwischen der Verarbeitung von Primitiven aus unterschiedlichen Kacheln umzuschalten, bevor die Verarbeitung aller Primitive innerhalb einer Kachel abgeschlossen ist, da das Grafikverarbeitungssystem 300 eine Mehrzahl von Tiefenpuffern 318 ₁ bis 318 ₄ umfasst. Das heißt, dass das Verarbeitungsmodul 302 eine HSR für ein Primitiv einer Kachel ausführen kann, während ein anderer der Tiefenpuffer 318 Tiefenwerte für eine teilweise verarbeitete Kachel speichert. Die teilweise verarbeitete Kachel unterscheidet sich in diesem Fall von der Kachel, für die ein Primitiv gerade von dem Verarbeitungsmodul 302 verarbeitet wird. Dies ermöglicht eine größere Flexibilität bei der Reihenfolge, in der die Primitive von dem Verarbeitungsmodul 302 verarbeitet werden, was zu einem effizienteren Verarbeiten der Primitive durch das Grafikverarbeitungssystem 300, verglichen mit der Verarbeitung, die von dem Grafikverarbeitungssystem 100 durchgeführt wird, führt, in dem alle Primitive einer Kachel von dem Verarbeitungsmodul 102 verarbeitet werden, bevor irgendeines der Primitive der nächsten Kachel von dem Verarbeitungsmodul 102 verarbeitet wird. Falls beispielsweise die Verarbeitung einer Kachel aus irgendeinem Grund, der die Kachel, die verarbeitet wird, betrifft, angehalten wird, dann kann das Verarbeitungsmodul 302 des Grafikverarbeitungssystems 300 weiterhin Primitive aus anderen Kacheln verarbeiten, wohingegen das Verarbeitungsmodul 102 des Grafikverarbeitungssystems 100 angehalten werden kann, bis die Verarbeitung für die angehaltene Kachel fortgesetzt werden kann. Außerdem können, wie unten beschrieben, mehrere Texturier-Engines 324 umgesetzt werden, um die Texturierungs- und Schattierungs-Leistung des Systems zu erhöhen. In früheren Systemen wurde eine Verarbeitungseinheit mit einem einzigen Tiefenpuffer mit mehreren Texturier-Engines gekoppelt. Es war deshalb notwendig, ein System zu entwickeln, das Fragmente auf eine Art an jede Texturier-Engine schickt, so dass die Belastung der Texturier-Engines relativ ausgewogen bleibt und so dass die Effizienz von Caches etc. aufrechterhalten wird. In der Praxis ist dies jedoch nur schwer zu erreichen.
Im vorliegenden System, in dem es mehrere Kacheln in Bearbeitung gibt, kann es effizient sein, dieselbe Texturier-Engine 324 zum Anwenden einer Texturierung auf alle sichtbaren Primitive innerhalb einer bestimmten Kachel zu verwenden. Das heißt, jede Texturier-Engine 324 kann einer jeweiligen Kachel zugewiesen sein.
Diese Zuweisung kann vorteilhaft sein, da jedes Primitiv in einer Kachel Texturierdaten für dieses Primitiv verursacht, die in die lokalen Caches der Texturier-Engine 324 geladen werden sollen. Durch Verarbeiten von Fragmenten eines Primitivs in einer einzigen Texturier-Engine 324 werden die Texturierdaten eines Primitivs nur in die Caches dieser Texturier-Engine geladen. Im Gegensatz dazu würden dieselben Texturierdaten in mehreren Caches dupliziert vorliegen, falls die Fragmente des Primitivs auf mehrere Texturier-Engines verteilt werden würden. Durch ein Vermeiden einer Duplikation der Daten wird die Effizienz der Caches verbessert. Die Anordnung ist auch deshalb vorteilhaft, da das Laden der Texturier-Engines 324 einfacher ausgeglichen gehalten werden kann, z. B. durch Zuweisen jeder Texturier-Engine 324 zu einer anderen der vielen Kacheln in Bearbeitung, anstelle dass versucht wird, die Fragmente aus einer Kachel gleichmäßig auf mehrere Texturier-Engines zu verteilen. Das Ausbalancieren von Ladungen ist unten genauer beschrieben.
In Schritt S406 werden Primitivenidentifikatoren für die Fragmente, die die verdeckte Oberflächenentfernung aus Schritt S404 überleben, in den Tag-Puffern 320 gespeichert, so dass, nachdem jedes Primitiv verarbeitet wurde, die Tag-Puffer die Identität des Primitivs enthalten, das bei jeder Abtastposition sichtbar ist. Im in 3 dargestellten Beispiel, gibt es vier Tag-Puffer (320 ₁ bis 320 ₄) im Tag-Sortiermodul 306, was dieselbe Anzahl ist wie die Anzahl von Tiefenpuffern 318, so dass jeder der Tag-Puffer 320 ₁ bis 320 ₄ einer jeweiligen bestimmten Kachel dynamisch zugewiesen ist. Das heißt, dass jeder der Tag-Puffer 320 die Primitivenidentifikatoren speichert, die die Primitive identifizieren, die von der HSR als bei jeder Abtastposition innerhalb einer jeweiligen Kachel sichtbar bestimmt wurden. Im Allgemeinen gibt es für jede der Kacheln, die „in Bearbeitung” sein kann, einen zugewiesenen Satz aus wenigstens einem Tag-Puffer 320, der ausgelegt ist, die Primitivenidentifikatoren für die sichtbaren Primitive dieser Kachel zu speichern. Im in 3 dargestellten Beispiel umfassen alle der „Sätze aus Tag-Puffern”, die bestimmten Kacheln zugewiesen sind, nur einen Tag-Puffer 320, aber, wie unten unter Bezugnahme auf 6 und 8 beschrieben ist, können diese Sätze mehr als einen Tag-Puffer umfassen.
Das Tag-Steuermodul 322 des Tag-Sortiermoduls 306 steuert die Auswahl eines der Tag-Puffer 320 zum Speichern jeder der Primitivenidentifikatoren, die an dem Tag-Sortiermodul 306 als die Ausgabe der HSR, die von dem Verarbeitungsmodul 302 durchgeführt wird, empfangen werden. Das Tag-Steuermodul 322 steuert ebenfalls das Entleeren von Primitivenidentifikatoren aus den Tag-Puffern 320 ₁ bis 320 ₄. Die entleerten Primitivenidentifikatoren werden an die Texturiereinheit 308 weitergegeben. Der Betrieb des Tag-Sortiermoduls 306 ist unten in Bezug auf 5a bis 9b genauer beschrieben.
In Schritt S408 wendet eine der Texturier-Engines 324 ₁ bis 324 ₄ eine Texturierung und Schattierung auf die Primitive an, die von den entleerten Primitivenidentifikatoren identifiziert wurden. Eine Texturier-Engine 324 ruft Texturierdaten und die identifizierten Primitive (z. B. aus einem Speicher) ab und wendet die Texturierdaten auf die Primitive an, die von den entleerten Primitivenidentifikatoren identifiziert wurden. Im in 3 dargestellten Beispiel gibt es vier Texturier-Engines 324 ₁ bis 324 ₄, d. h., es gibt dieselbe Anzahl von Texturier-Engines 324 wie von Tiefenpuffern 318. In diesem Fall ist jede der Texturier-Engines einer jeweiligen Kachel zugewiesen, so dass die gesamte Texturierung, die auf die Primitive einer bestimmten Kachel angewandt wird, von derselben Texturier-Engine 308 durchgeführt wird. Das heißt, dass die Primitivenidentifikatoren im/in den Tag-Puffer(n) 320, die einer bestimmten Kachel zugewiesen sind, alle an dieselben Texturier-Engines 324 gesendet werden, so dass die gesamte Texturierung, die auf die sichtbaren Primitive der bestimmten Kachel angewandt wird, von derselben Texturier-Engine 324 angewandt wird. Wie oben beschrieben kann dies die Effizienz der Texturierung der Primitive im Fall, dass es mehrere Kacheln in Bearbeitung gibt, verbessern. Verfahren zum Anwenden einer Texturierung auf Primitive sind in der Technik bekannt und somit wird ein solcher Texturierungsvorgang hier nicht näher beschrieben.
Das Ergebnis des Anwendens der Texturierung auf die Primitive an der Texturiereinheit 308 ist ein Satz aus Pixelwerten für das Bild. Die Texturiereinheit 308 kann eine Logik zum Konvertieren von Abtastwerten in Pixelwerte umfassen, wenn die Proben nicht genau den Pixeln entsprechen (z. B. wo es mehr Proben als Pixel gibt). Die Pixelwerte werden von der Texturiereinheit 308 ausgegeben und im Pixelpuffer 310 gespeichert. Der Pixelpuffer 310 speichert die Pixelwerte des Bilds, das dann auf jede geeignete Art verwendet werden kann, z. B. auf einer Anzeige ausgegeben werden kann oder in einem Speicher gespeichert werden kann oder auf eine andere Vorrichtung übertragen werden kann etc.
Das Steuermodul 316 steuert, welche Primitive von dem Verarbeitungsmodul 302 verarbeitet werden, um dadurch das Umschalten des Verarbeitungsmoduls 302 zwischen dem Verarbeiten von Primitiven für unterschiedliche Kacheln zu steuern. Um das Umschalten des Verarbeitungsmoduls 302 zu steuern, kann das Steuermodul 316 ein Steuersignal in den Block von Warteschlangen 312 senden, wodurch eine der Warteschlangen 314 ausgewählt wird. Alternativ dazu kann das Steuermodul 316 ein Steuersignal an das Verarbeitungsmodul 302 senden, das angibt, von welcher der Warteschlangen 314 das Verarbeitungsmodul 302 ablesen soll. Das Steuermodul 316 kann die Ablaufsteuerung auf unterschiedliche Arten verwalten und die zwei oben vorgeschlagenen Verfahren sind nur ein Beispiel dafür. Ein Primitiv aus der ausgewählten Warteschlange 314 wird an das Verarbeitungsmodul 302 gesendet. Die dem Primitiv zugewiesenen Kacheldaten werden ebenfalls an das Verarbeitungsmodul 302 gesendet, so dass das Primitiv wie oben beschrieben verarbeitet werden kann. Wie in 3 dargestellt, kann das Steuermodul 316 Zustandsinformationen empfangen, die den Zustand des Grafikverarbeitungssystems 300 beschreiben. Die Auswahl einer der Warteschlangen 314 durch das Steuermodul 316 kann basierend auf den Zustandsinformationen erfolgen. Die Zustandsinformationen können jegliche geeignete Informationen sein, die den Zustand des Grafikverarbeitungssystems 300 betreffen, die für das Steuermodul 316 dabei von Nutzen sein können, zu bestimmen, ob die Verarbeitung des Verarbeitungsmoduls 302 umgeschaltet werden soll, um Primitive einer anderen Kachel zu verarbeiten.
Beispielsweise kann das Steuermodul 316 Zustandsinformationen aus der Texturiereinheit 308 empfangen, die angeben, dass eine der Texturier-Engines 324 frei ist oder frei wird. In diesem Fall kann das Steuermodul 316 das Verarbeiten von Primitiven für die Kachel, die gerade der angegebenen Texturier-Engine 324 zugewiesen ist, priorisieren. Dies ist dafür von Nutzen, um die Verarbeitungslast an den verschiedenen Texturier-Engines 324 auszugleichen, wodurch z. B., falls angemessen, eine Situation vermieden wird, in der eine der Texturier-Engines 324 nicht voll verwendet wird. In einem Beispiel umfassen die Zustandsinformationen, die von dem Steuermodul 316 empfangen werden, Informationen über den Zustand der Puffer (z. B. FIFOs) an den Schnittstellen zwischen Tag-Puffern 320 und Texturier-Engines 324. Ein Tag-Puffer 320 kann viele Primitivenidentifikatoren zur gleichen Zeit entleeren und eine Texturier-Engine 324 kann sie nacheinander oder in kleinen Gruppen verarbeiten. Die Texturier-Engines können deshalb eine Anzahl von Primitivenidentifikatoren puffern, bis sie zur Ausführung von der Texturier-Engine eingeteilt werden. Wenn die Anzahl der gepufferten Primitivenidentifikatoren auf null abfällt, gibt es keine Arbeit mehr für die Texturier-Engine und sie wird frei. Das Steuermodul 316 kann die Verarbeitung von Primitiven priorisieren, in einem Versuch, um sicherzustellen, dass die Puffer nie oder nur selten leer werden. „Priorisieren” der Verarbeitung von Primitiven für eine Kachel kann bedeuten, dass die Frequenz, mit der die Primitive für diese Kachel für die Verarbeitung durch das Verarbeitungsmodul 302 ausgewählt werden, erhöht wird oder, wie unten beschrieben, dass ein Tag-Puffer, der dieser Kachel zugewiesen ist, wenn es notwendig ist, eine Entleerung durchzuführen, bevorzugt ausgewählt wird.
Als weiteres Beispiel kann das Steuermodul 316 Zustandsinformationen, z. B. aus dem Kachel-Vorgang, empfangen, die angeben, dass es eine große Menge an Daten (z. B. viele Schichten von Primitiven) gibt, die in einer Kachel verarbeitet werden müssen. In diesem Fall kann das Steuermodul 316 ausgelegt sein, die Verarbeitung von Primitiven für diese Kachel durch Sicherstellen, dass der Kachel bei der nächsten Gelegenheit eine Warteschlange 314 zugewiesen wird, zu priorisieren. Dadurch stellt das System sicher, dass andere Kacheln dazu in der Lage sind, gleichzeitig verarbeitet zu werden, wodurch die Auslastung der Texturier-Engines erhöht wird.
Als weiteres Beispiel kann das Steuermodul 316 Zustandsinformationen, z. B. aus der Texturiereinheit 308 oder dem Tag-Sortiermodul 306, empfangen, die angeben, dass die Verarbeitung einer Kachel angehalten wurde, z. B. da sie auf eine Antwort auf eine Speicherzugriffsanfrage an einen Chip-off-Speicher wartet. In diesem Fall ist das Steuermodul 316 ausgelegt, die Verarbeitung von Primitiven für die angehaltene Kachel zu depriorisieren bzw. entpriorisiern. „Depriorisieren” der Verarbeitung von Primitiven für eine Kachel kann ein Reduzieren der Frequenz, mit der die Primitive für diese Kachel zur Verarbeitung durch das Verarbeitungsmodul 302 ausgewählt werden, bedeuten. Die Zustandsinformationen können mehr als eine der oben beschriebenen Angaben umfassen und in diesem Fall können die Auswirkungen der unterschiedlichen Priorisierungen/Depriorisierungen kombiniert werden, um zu bestimmen, welche der Kacheln ausgewählt werden soll.
Andere beispielhafte Grafikverarbeitungssysteme könnten kein Steuermodul 316 umfassen, und die Auswahl, welche der Primitive von dem Verarbeitungsmodul 302 verarbeitet werden sollten, kann auf andere Weise bestimmt werden. Beispielsweise könnte eine der Warteschlangen 314 regelmäßig zufällig ausgewählt werden, um dem Verarbeitungsmodul 302 ein Primitiv bereitzustellen, wenn das Verarbeitungsmodul 302 bereit ist, ein neues Primitiv zu empfangen. Alternativ dazu könnten die Warteschlangen 314 jeweils abwechselnd in einem Muster ausgewählt werden, z. B. gemäß einem Ringverteilungsschema.
Es ist somit ersichtlich, dass das Graphikverarbeitungssystem 300 es mehreren Kacheln ermöglicht, „in Bearbeitung” zu sein, wobei das Verarbeitungsmodel 302 für Primitive für eine Kachel unter Verwendung einer der Tiefenpuffer 318 HSR durchführen kann, während Tiefenwerte für eine andere, teilweise verarbeitete Kachel in einem anderen der Tiefenpuffer 318 gespeichert werden.
Es kann eine Situation auftreten, in der viele Primitive an einer bestimmten Abtastposition innerhalb einer Kachel vorhanden sind, so dass die Primitive überlappen. Ein Beispiel für eine solche Situation ist in 5a dargestellt, die der Klarheit halber eine kleine Kachel 500 darstellt, die in ein 8-×-8-Gitter aufgeteilt ist. In diesem Beispiel entspricht jedes Gitterquadrat einem Bildschirmpixel und weist eine Abtastposition, üblicherweise an dessen Mittelpunkt, auf. Wie oben beschrieben, sind unterschiedliche Kachelanordnungen und Abtastmuster möglich. 5a zeigt, dass es ein Primitiv 502 gibt, das die gesamte Kachel 500 bedeckt und z. B. einen Hintergrund in einem Bild darstellen kann. Vor dem Primitiv 502 (d. h. näher zum Ansichtspunkt und deshalb in diesem Beispiel durch kleinere „Tiefen”-Werte dargestellt) gibt es zwei weitere Primitive 504 und 506, die sich nicht gegenseitig überlappen. In 5a kann gesehen werden, dass das Primitiv 504 sich nicht über die Kachel 500 hinaus erstreckt, wohingegen das Primitiv 506 sich über die Kachel 500 hinaus erstreckt, z. B. in eine andere Kachel hinein (nicht in 5a dargestellt), die unter der Kachel 500 angeordnet ist. Vor den Primitiven 502, 504 und 506 gibt es ein weiteres Primitiv 508. Ferner gibt es vor dem Primitiv 508 ein weiteres Primitiv 510. Falls die Primitive vollständig undurchsichtig sind, dann werden die endgültigen Abtastwerte von dem Primitiv bestimmt, das jeder der Abtastpositionen am nächsten ist. Falls manche der Primitive nicht vollständig undurchsichtig sind (z. B. weisen manche eine gewisse Transluzenz auf oder weisen Texturen auf, die einen Durchgriff umfassen), dann können die endgültigen Abtastwerte von einer Mischung aus mehr als einem der Primitive an den Abtastpositionen bestimmt werden.
Wie oben beschrieben werden dann, wenn eine verdeckte Oberflächenentfernung für ein Primitiv durchgeführt wird, das nicht vollständig undurchsichtig ist, die Primitivenidentifikatoren, die bereits im Tag-Puffer vorhanden sind, entleert, um zu ermöglichen, dass der neu verarbeitete Primitivenidentifikator im Tag-Puffer gespeichert wird, falls nur ein Tag-Puffer verwendet wird, um Primitivenidentifikatoren für Primitive innerhalb einer Kachel zu speichern. Dies führt zu einer großen Anzahl von getrennten Entleerungsvorgängen, die weniger effizient sein können, als wenn weniger, jedoch größere Entleerungsvorgänge durchgeführt werden, was eine bessere Möglichkeit für undurchsichtige Primitive bietet, zuvor verarbeitete Primitive zu verdecken, wodurch ein weiteres unnötiges Verarbeiten, das an den bereits zuvor verarbeiteten Primitiven durchgeführt wird, die schlussendlich im endgültigen Bild verdeckt sein werden, verhindert wird. 6 zeigt ein Grafikverarbeitungssystem 600, das die Anzahl von getrennten Entleerungsvorgängen, die durchgeführt werden, reduzieren kann. Das Grafikverarbeitungssystem 600 umfasst ein Verarbeitungsmodul 602, einen Tiefenpuffer 604, ein Tag-Sortiermodul 606, eine Texturier-Engine 608 und einen Pixelpuffer 610. Im in 6 dargestellten Beispiel umfasst das Tag-Sortiermodul 606 drei Tag-Puffer 620 ₁ bis 620 ₃ und ein Tag-Steuermodul 622. Die Elemente des in 6 dargestellten Grafikverarbeitungssystems 600 können in Hardware, Software oder einer Kombination daraus ausgeführt sein.
Der Betrieb des Grafikverarbeitungssystems 600 ist unter Bezugnahme auf das Flussdiagramm, das in 7 dargestellt ist, beschrieben. In Schritt S702 empfängt das Verarbeitungsmodul 602 Primitive, die Objekte einer zu rendernden Szene betreffen können und z. B. von einer Anwendung (z. B. einem Spiel), die auf derselben Vorrichtung (z. B. einer mobilen Benutzervorrichtung) ausgeführt wird wie das Grafikverarbeitungssystem 600, an das Grafikverarbeitungssystem 600 gesendet werden können. In diesem Beispiel betreffen Primitive eine einzige Kachel (z. B. Kachel 500), in der die Primitive verarbeitet werden. Im Gegensatz zum System aus 3 unterstützt das System aus 6 nicht „mehrere Kacheln in Bearbeitung”. Deshalb ist es nicht notwendig, dass das Verarbeitungsmodul 602 Kacheldaten empfängt, die angeben, in welcher der vielen Kacheln das Primitiv verarbeitet werden soll. Obwohl das Grafikverarbeitungssystem 600 so beschrieben ist, dass es einen Renderingraum aufweist, der in eine Mehrzahl von Kacheln unterteilt ist, gilt anzumerken, dass die Verwendung von mehreren Tag-Puffern, um ein Speichern von sich überlagernden Schichten von Primitivenidentifikatoren im Tag-Sortiermodul 606 zu ermöglichen, in anderen Beispielen verwendet werden kann, die keinen Renderingraum aufweisen, der in mehrere Kacheln unterteilt ist, d. h., die nur eine einzige Kachel aufweisen.
In Schritt S704 führt das Verarbeitungsmodul 602 eine verdeckte Oberflächenentfernung (HSR) für ein Primitiv der Kachel 500 durch Vergleichen von Tiefenwerten für dieses Primitiv mit Tiefenwerten, die im Tiefenpuffer 604 gespeichert sind, durch. Die HSR, die von dem Verarbeitungsmodul 602 für ein Primitiv durchgeführt wird, kann z. B. ein Bestimmen umfassen, welche Abtastpositionen innerhalb der Primitive liegen (basierend auf den Eckpositionen der Primitive) und ein Durchführen von Tiefentests an diesen Abtastpositionen basierend auf den im Tiefenpuffer 604 gespeicherten Tiefenwerten. Auf diese Art bestimmt die HSR Primitivenidentifikatoren, die die Primitive identifizieren, die an jeder der Abtastpositionen in der Kachel 500 sichtbar sind. Als Teil von Schritt S704 kann das Verarbeitungsmodul 602 einen oder mehrere der im Tiefenpuffer 604 gespeicherten Tiefenwerte aktualisieren.
Die drei Tag-Puffer 620 ₁ bis 620 ₃ bilden einen Satz aus Tag-Puffern, die ausgelegt sind, Primitivenidentifikatoren für jede der Abtastpositionen in der Kachel zu speichern, wodurch Primitivenidentifikatoren, die an entsprechenden Abtastpositionen in den Tag-Puffern 620 des Satzes gespeichert sind, sich überlagernde Schichten von Primitiven darstellen.
In Schritt S706 wählt das Tag-Steuermodul 622 einen der Tag-Puffer 620 für das Speichern jedes der Primitivenidentifikatoren aus, die von dem Verarbeitungsmodul 602, das Primitive identifiziert, die von der verdeckten Oberflächenentfernung als sichtbar bestimmt wurden, ausgegeben wurden. In einem Beispiel wird ein Tag-Puffer 620 unabhängig für jede Abtastposition, an der das Primitiv gemäß den bereits in den Tag-Puffern 620 an jeder Abtastposition gespeicherten Primitivenidentifikatoren als sichtbar bestimmt wurde, ausgewählt. In einem weiteren Beispiel führt das Verarbeitungsmodul 602 eine versteckte Oberflächenentfernung für ein Primitiv an jeder Abtastposition in einer Mikrokachel durch. Eine Mikrokachel ist eine Gruppe von Abtastpositionen, üblicherweise 4×4, für die eine verdeckte Oberflächenentfernung für ein Primitiv parallel durchgeführt werden kann. In diesem Fall kann es angebracht sein, einen Tag-Puffer auszuwählen, um alle Primitivenidentifikatoren für die Fragmente eines Primitivs, das als in der Mikrokachel sichtbar bestimmt wurde, zu speichern. In einem dritten Beispiel wird ein Tag-Puffer ausgewählt, um die Primitivenidentifikatoren für alle Fragmente eines Primitivs, das als in der Kachel sichtbar bestimmt wurde, zu speichern, während ein weiterer Tag-Puffer ausgewählt werden kann, um die Primitivenidentifikatoren für alle Fragmente eines weiteren Primitivs, das als in der Kachel sichtbar bestimmt wurde, zu speichern.
Deshalb wird im dritten Beispiel eine Auswahl eines Tag-Puffers zum Speichern der Primitivenidentifikatoren eines Primitivs in der Skalierung von ganzen Kacheln durchgeführt, anstelle von in der Skalierung von Mikrokacheln oder in der Skalierung von einzelnen Proben. In Schritt S708 werden die Primitivenidentifikatoren für die Fragmente, die von der HSR für jede der Abtastpositionen als sichtbar bestimmt wurden, im/in den entsprechenden ausgewählten Tag-Puffer(n) gespeichert.
5a und 5b zeigen das Beispiel, in dem ein Tag-Puffer unabhängig für jede Abtastposition ausgewählt wird. Unter Bezugnahme auf 5a wird eine der Spalten von Abtastpositionen von dem Pfeil 512 angegeben. Als ein Beispiel ist das Primitiv 502 undurchsichtig, wohingegen die anderen Primitive in der Kachel 500 (Primitive 504, 506, 508 und 510) alle transluzent sind. 5b zeigt eine Spalte 514 ₁ von Tag-Puffer 620 ₁, eine Spalte 514 ₂ von Tag-Puffer 620 ₂ und eine Spalte 514 ₃ von Tag-Puffer 620 ₃. Jede der Spalten 514 ₁ bis 514 ₃ ist ausgelegt, Primitivenidentifikatoren für die in der Spalte 512 in 5a dargestellten Primitive zu speichern. Es gilt anzuerkennen, dass die Primitive 502 bis 510 an manchen der Abtastpositionen innerhalb der Spalte 512 überlappen. 5b zeigt den Ansichtspunkt links neben der Figur, so dass im in 5b gezeigten Beispiel gesehen werden kann, dass die Spalte 514 ₁ des Tag-Puffers 620 ₁ für jede Abtastposition ausgelegt ist, Primitivenidentifikatoren für Primitive zu speichern, die weiter weg angeordnet sind als sich überlagernde Primitive, für die die Spalte 514 ₂ des Tag-Puffers 620 ₂ ausgelegt ist, Primitivenidentifikatoren zu speichern, die selbst weiter weg sind als sich überlagernde Primitive, für die die Spalte 514 ₃ des Tag-Puffers 620 ₃ ausgelegt ist, Primitivenidentifikatoren zu speichern. Auf diese Art stellen die Tag-Puffer 620 sich überlagernde Schichten von Primitiven an unterschiedlichen Abtastpositionen dar.
In einem Beispiel wird der Primitivenidentifikator für das Primitiv 502 an dem Tag-Sortiermodul 606 vor den Primitivenidentifikatoren für die anderen in 5a dargestellten Primitive empfangen. Das Primitiv 502 ist undurchsichtig und bedeckt alle Abtastpositionen von Kachel 500. Als solche wird sie jedes Primitiv verdecken, das zuvor für die Kachel 502 empfangen wurde, das weiter weg liegt, das z. B. größere Tiefenwerte aufweist als das Primitiv 502 (es gilt anzumerken, dass die Tiefenwerte in anderen Beispielen so definiert sein können, dass Primitive, die weiter weg liegen, kleinere Tiefenwerte aufweisen). Der Primitivenidentifikator für Primitiv 502 kann deshalb im Tag-Puffer 620 ₁ an allen Abtastpositionen gespeichert werden. Deshalb wählt das Tag-Steuermodul 622 den Tag-Puffer 620 ₁ aus, der in diesem Beispiel der eine der Tag-Puffer 620 ist, der Primitivenidentifikatoren für die entfernteste Schicht der Primitive speichert. Dies ist in 5b dadurch dargestellt, dass die Primitivenidentifikatoren für das Primitiv 502 in der Spalte 514 ₁ des Tag-Puffers 620 ₁ gespeichert sind. Das Tag-Sortiermodul 606 kann dann Primitivenidentifikatoren für das nächste Primitiv 504 (das transluzent ist) empfangen und es bestimmt, dass der Tag-Puffer 620 ₁ an den von dem Primitiv 504 abgedeckten Abtastpositionen voll ist und wird deshalb die nächste Schicht, d. h. Puffer 620 ₂, auswählen, um die Primitivenidentifikatoren für das Primitiv 504 zu speichern. Dies ist in 5b dadurch dargestellt, dass Primitivenidentifikatoren für das Primitiv 504 in der Spalte 514 ₂ des Tag-Puffers 620 ₂ gespeichert sind.
Das Tag-Sortiermodul 606 kann dann Primitivenidentifikatoren für das nächste Primitiv 506 (das transluzent ist) empfangen und bestimmt, dass der Tag-Puffer 620 ₁ an den Abtastpositionen in der Kachel 500, die von dem Primitiv 506 verdeckt werden, voll ist und wird deshalb die nächste Schicht auswählen, d. h. Puffer 620 ₂, um die Primitivenidentifikatoren, die in der Kachel 500 vorhanden sind, für das Primitiv 506 zu speichern. Es gilt anzumerken, dass das Primitiv 506 nicht mit dem Primitiv 504 überlappt und daher können Primitivenidentifikatoren für die Primitive 504 und 506 im selben Tag-Puffer 620 ₂ gespeichert werden. Dies ist in 5b dadurch gezeigt, dass Primitivenidentifikatoren für das Primitiv 506 in der Spalte 514 ₂ des Tag-Puffers 620 ₂ gespeichert sind.
Das Tag-Sortiermodul 606 kann dann Primitivenidentifikatoren für das nächste Primitiv 508 (das transluzent ist) empfangen und bestimmt, dass der Tag-Puffer 620 ₁ an allen Abtastpositionen, die von dem Primitiv 508 abgedeckt werden, voll ist. Für manche der Abtastpositionen des Primitivs 508 ist der Tag-Puffer 620 ₂ verfügbar, aber für manche andere Abtastpositionen des Primitivs 508 ist der Tag-Puffer 620 ₂ nicht verfügbar. Im in 5b dargestellten Beispiel wird der Primitivenidentifikator 508 ₂ in Spalte 514 ₂ von Puffer 620 ₂ an den Positionen gespeichert, an denen Speicherplatz verfügbar ist. Die Primitivenidentifikatoren 508 ₁ und 508 ₃ werden in Spalte 514 ₃ von Tag-Puffer 620 ₃ an den Positionen gespeichert, wo Speicherplatz in Tag-Puffer 620 ₂ nicht verfügbar ist. Das heißt, dass das Tag-Steuermodul 622 den Tag-Puffer 620 zum Speichern von Primitivenidentifikatoren auf einer Positionsbasis pro Probe auswählt.
Das Tag-Sortiermodul 606 kann dann Primitivenidentifikatoren für das nächste Primitiv 510 (das transluzent ist) empfangen und bestimmt, dass keiner der Tag-Puffer 620 ₁, 620 ₂ und 620 ₃ für die Spalte 512 an den Abtastpositionen, die von dem Primitiv 510 abgedeckt werden, verfügbar ist. Dies ist in 5b dargestellt. Deshalb wird einer der Tag-Puffer entleert, um die Primitivenidentifikatoren für das Primitiv 510 in einem Tag-Puffer zu speichern. Das heißt, dass in Schritt S710 die Primitivenidentifikatoren aus einem oder mehreren der Tag-Puffer 620 entleert werden. Das Tag-Steuermodul 622 steuert das Entleeren der Tag-Puffer 620. Wenn Primitivenidentifikatoren aus einem Tag-Puffer 620 entleert werden, werden sie an der Texturier-Engine 608 empfangen. Das Entleeren eines Tag-Puffers 620 bewirkt, dass der Tag-Puffer 620 verfügbar wird, so dass die Primitivenidentifikatoren für das Primitiv 510 im verfügbaren Tag-Puffer 620 gespeichert werden können.
In einem weiteren Beispiel wählt das Tag-Steuermodul 622 einen Tag-Puffer 620 zum Speichern aller Primitivenidentifikatoren eines Primitivs aus, die eine bestimmte Mikrokachel betreffen, so dass für jede der Mikrokacheln, falls alle Abtastpositionen innerhalb dieser Mikrokachel in einer Schicht verfügbar sind, die Primitivenidentifikatoren dann für das Primitiv im Tag-Puffer gespeichert werden, der dieser Schicht entspricht. Falls es jedoch nicht der Fall ist, dass alle Abtastpositionen innerhalb einer Mikrokachel in der Schicht verfügbar sind, dann werden die Primitivenidentifikatoren für die Primitive in der nächsten Schicht gespeichert. 5c zeigt dieselbe Kachel 500, dieselbe Spalte von Abtastpositionen 512 und dasselbe undurchsichtige Hintergrundprimitiv 502 wie 5a. 5d zeigt die Spalten 514 ₁, 514 ₂ und 514 ₃ der Tag-Puffer 620 ₁ bzw. 620 ₂ bzw. 620 ₃, wobei die Spalte 514 ₁ Primitivenidentifikatoren enthält, die Primitiv 502 entsprechen. Linien 530 und 532 teilen die Kachel 500 in vier Mikrokacheln, wobei jede sechzehn Abtastpositionen enthält. Ähnlich dazu teilt Linie 532 die Spalten 514 in obere und untere Teile, die den zwei Mikrokacheln entsprechen, die von der Spalte von Abtastpositionen 512 geteilt wird.
In diesem Beispiel kann das Tag-Sortiermodul 606 Primitivenidentifikatoren für das Primitiv 520 (das transluzent ist) empfangen. Tag-Puffer 620 ₁ enthält bereits Primitivenidentifikatoren für das undurchsichtige Primitiv 502, somit wählt das Tag-Steuermodul 622 Tag-Puffer 620 ₂ aus, um die Primitivenidentifikatoren für Primitiv 520 zu speichern. Dies ist in 5d dadurch dargestellt, dass die Primitivenidentifikatoren für das Primitiv 520 in der Spalte 514 ₂ des Tag-Puffers 620 ₂ gespeichert sind.
Das Tag-Sortiermodul 606 kann dann Primitivenidentifikatoren für das nächste Primitiv 522 (das transluzent ist) empfangen. In diesem Fall wird ein Teil 522 ₁ der Primitivenidentifikatoren für das Primitiv 522 in der Spalte 514 ₂ des Tag-Puffers 620 ₂ gespeichert, da alle Abtastpositionen innerhalb der relevanten Mikrokachel im Tag-Puffer 620 ₂ verfügbar sind, wohingegen Teil 522 ₂ der Primitivenidentifikatoren für das Primitiv 522 in der Spalte 514 ₃ des Tag-Puffers 620 ₃ gespeichert wird, da es nicht der Fall ist, dass alle Abtastpositionen innerhalb der relevanten Mikrokacheln im Tag-Puffer 620 ₂ verfügbar sind. Im Allgemeinen werden für jede Mikrokachel die Primitivenidentifikatoren von Abtastpositionen innerhalb der Mikrokachel in der von den Tag-Puffern dargestellten entferntesten Schicht, die für alle Abtastpositionen innerhalb der Mikrokachel verfügbar ist, gespeichert. Das heißt, die Auswahl in Schritt S706 umfasst ein Auswählen eines der Tag-Puffer 620, der der entferntesten verfügbaren Schicht der sich überlagernden Schichten für einen Block aus einer oder mehreren Abtastpositionen (d. h. für eine Mikrokachel) entspricht. In anderen Beispielen werden die Primitivenidentifikatoren von Abtastpositionen innerhalb der Mikrokachel für jede Mikrokachel in der von den Tag-Puffern dargestellten entferntesten Schicht gespeichert, die für alle Abtastpositionen, die von den Primitivenidentifikatoren innerhalb der Mikrokachel abgedeckt werden, verfügbar ist. Das heißt, die Auswahl in Schritt S706 kann ein Auswählen des einen der Tag-Puffer 620 umfassen, der der entferntesten verfügbaren Schicht der sich überlagernden Schichten für die Primitivenidentifikatoren innerhalb eines Blocks aus einer oder mehreren Abtastpositionen (d. h. für eine Mikrokachel) entspricht.
In Schritt S712 wendet die Texturier-Engine 608 eine Texturierung und Schattierung auf die Primitive an, die von den entleerten Primitivenidentifikatoren identifiziert wurden. Die Texturierung wird auf eine der oben in Bezug auf Schritt S408 beschriebene entsprechende Weise durchgeführt. Das heißt, dass die Texturier-Engine 608 Texturierdaten und die identifizierten Primitive (z. B. aus einem Speicher) abfragt und die Texturierdaten auf die von den entleerten Primitivenidentifikatoren identifizierten Primitive anwendet. Wie oben beschrieben ist das Ergebnis des Anwendens der Texturierung auf die Primitive an Texturiereinheit 608 ein Satz aus Pixelwerten für das Bild. Die Pixelwerte werden aus der Texturiereinheit 608 ausgegeben und im Pixelpuffer 610 gespeichert. Der Pixelpuffer 610 speichert die Pixelwerte des Bilds, das dann auf jede geeignete Art und Weise verwendet werden kann, z. B. an eine Anzeige ausgegeben werden kann oder in einem Speicher gespeichert werden kann oder an eine andere Vorrichtung übertragen werden kann etc.
In den oben detailliert beschriebenen Beispielen wird die Auswahl eines Tag-Puffers für die Primitivenidentifikatoren entweder für jede einzelne Abtastposition oder auf der Mikrokachel-Skalierung, z. B. für einen 4-×-4-Block von Abtastpositionen, die einer Mikrokachel entsprechen, durchgeführt. Jedoch kann die Auswahl eines Tag-Puffers in anderen Beispielen mit anderer Skalierung durchgeführt werden, z. B. für Blöcke von Abtastpositionen mit unterschiedlichen Größen und/oder Formen. Das Wählen einer größeren Skalierung kann dabei helfen, das Auftreten von Primitiven-Entleerungen in mehreren Phasen zu reduzieren, die erfolgen können, wenn unterschiedliche Teile der Primitivenidentifikatoren in unterschiedlichen Schichten gespeichert werden. Jedoch reduziert das Wählen einer größeren Skalierung die Möglichkeiten zum Füllen von Lücken innerhalb von Schichten der Tag-Puffer. Deshalb muss bei der Festlegung der Skalierung der Blöcke ein Kompromiss eingegangen werden.
Wenn einer der Tag-Puffer 620 entleert werden soll, bestimmt das Tag-Steuermodul 622 basierend auf einer Entleerungs-Strategie, welche der Tag-Puffer entleert werden sollen. Beispielsweise kann die Entleerungs-Strategie so sein, dass der Tag-Puffer 620, der Primitivenidentifikatoren der entferntesten Schicht enthält (z. B. Tag-Puffer 620 ₁ in den oben beschriebenen Beispielen) entleert werden soll, bevor ein weiterer Tag-Puffer 620 entleert wird. Als weiteres Beispiel kann die Entleerungs-Strategie so sein, dass der Tag-Puffer, der die meisten Primitivenidentifikatoren enthält (d. h. der vollste Tag-Puffer), entleert werden soll, bevor ein weiterer Tag-Puffer entleert wird. Das Tag-Steuermodul 622 kann das Entleeren der Primitivenidentifikatoren aus den Tag-Puffern 620 so steuern, dass Primitivenidentifikatoren nur aus einem der Tag-Puffer 620 zur gleichen Zeit entleert werden. Alternativ dazu kann das Tag-Steuermodul 622 das Entleeren der Primitivenidentifikatoren aus den Tag-Puffern 620 so steuern, dass die Primitivenidentifikatoren aus mehreren Tag-Puffern 620 gleichzeitig entleert werden. Hängt das korrekte Verhalten des Renderns von der Reihenfolge ab, in der Primitive gerendert werden, sollte die Entleerungs-Strategie so gewählt werden, dass diese aufrechterhalten wird. Es gilt anzumerken, dass, wenn Primitivenidentifikatoren in mehreren Tag-Puffern gespeichert sind, wie in 5b und 5d dargestellt, die Schichtung die Reihenfolge wiederspiegelt, in der Primitivenidentifikatoren von dem Tag-Sortiermodul 606 empfangen werden, und nicht die Tiefen der Primitive. Deshalb sind die mehreren Tag-Puffer dazu in der Lage, die Reihenfolge zu bewahren.
6 zeigt ein Beispiel dafür, wie das Grafikverarbeitungssystem, in dem drei Tag-Puffer 620 vorhanden sind, angeordnet sein könnte. In anderen Beispielen können zwei oder mehr als drei Tag-Puffer im Grafikverarbeitungssystem vorhanden sein, das ausgelegt sein könnte, Primitivenidentifikatoren für unterschiedliche Schichten von Primitiven innerhalb einer Kachel zu speichern.
Ein Vorteil der Verwendung von mehreren Tag-Puffern 620 zur Darstellung von sich überlagernden Schichten von Primitiven ist, dass Primitivenidentifikatoren, die einem Tag-Puffer zugeschrieben sind, manchmal Primitive identifizieren können, von denen anschließend durch die HSR, die von dem Verarbeitungsmodul 602 durchgeführt wird, herausgefunden wird, dass sie von anderen Primitiven verdeckt sind. In diesem Fall kann die Verwendung von mehreren Tag-Puffern die Anzahl von Primitivenidentifikatoren, die in die Texturier-Engine 608 entleert werden, reduzieren. Falls beispielsweise nur ein Tag-Puffer im in 5a dargestellten Beispiel verwendet würde, dann wären die Primitivenidentifikatoren für das Primitiv 502 in Reaktion auf das Eintreffen der Primitivenidentifikatoren für das transluzente Primitiv 504 an die Texturier-Engine entleert worden. Falls das nächste zu verarbeitende Primitiv undurchsichtig und vor den Primitiven 502 und 504 wäre, dann könnten die Primitive 502 und 504 zur Gänze oder teilweise verdeckt sein und als solche müssten die verdeckten Teile von den Primitiven 502 und 504 nicht texturiert werden. Durch die Verwendung von mehreren Tag-Puffern 620 würden die Primitivenidentifikatoren für das Primitiv 502 nicht in Reaktion auf das Eintreffen der Primitivenidentifikatoren für das Primitiv 504 an dem Tag-Sortiermodul 606 an die Texturier-Engine 608 entleert werden, da die Primitivenidentifikatoren für das Primitiv 504 in den zweiten Tag-Puffer 620 ₂ überschrieben werden könnten. Deshalb wurden keine Entleerungen durchgeführt, wenn die Primitivenidentifikatoren für das undurchsichtige Primitiv, das Primitive 502 und 504 abdeckt, an dem Tag-Sortiermodul 606 empfangen wird. In diesem Fall können Primitivenidentifikatoren für das Primitiv 502 und 504 in die Tag-Puffer 620 ₁ bzw. 620 ₂ überschrieben werden, wo sie nicht texturiert werden müssen. Somit kann das unnötige Texturieren von Fragmenten von Primitiven, die schlussendlich von anderen Primitiven verdeckt werden, reduziert werden.
Die zwei oben beschriebenen Ideen des Ermöglichens, dass sich durch die Verwendung von mehreren Tiefenpuffern mehrere Kacheln zu einer gegebenen Zeit in Bearbeitung befinden, und des Ermöglichens, dass sich überlagernde Schichten von Primitivenidentifikatoren in mehreren Tag-Puffern gespeichert werden, können kombiniert werden, um ein sehr flexibles Grafikverarbeitungssystem bereitzustellen.
8 zeigt ein Grafikverarbeitungssystem 800, das Merkmale der Grafikverarbeitungssysteme 300 und 600, die oben beschrieben und in 3 bzw. 6 dargestellt sind, kombiniert. Insbesondere umfasst das Grafikverarbeitungssystem 800 einige derselben Elemente wie das Grafikverarbeitungssystem 300 und diese Elemente sind in 8 mit denselben Bezugsziffern angegeben. Das heißt, dass das Grafikverarbeitungssystem 800 einen Block von Warteschlangen 312, die vier Warteschlangen 314 ₁ bis 314 ₄ umfassen; ein Verarbeitungsmodul 302; einen Block 304 aus Tiefenpuffern 318 ₁ bis 318 ₄, eine Texturiereinheit 308 mit vier Texturier-Engines 324 ₁ bis 324 ₄ und einen Pixelpuffer 310 umfasst. Diese Elemente funktionieren wie oben in Bezug auf das Grafikverarbeitungssystem 300 beschrieben. Alle Elemente des Grafikverarbeitungssystems 800, das in 8 dargestellt ist, können in Hardware, Software oder in einer Kombination daraus ausgeführt sein.
Wie unten genauer beschrieben ist, umfasst das Grafikverarbeitungssystem 800 ein Steuermodul 816, das dem Steuermodul 316 des Grafikverarbeitungssystems 300 ähnelt, jedoch nicht damit identisch ist. Außerdem umfasst das Grafikverarbeitungssystem 800 ein Tag-Sortiermodul 806, das nicht dasselbe ist wie das Tag-Sortiermodul 306 von Grafikverarbeitungssystem 300. Das Tag-Sortiermodul 806 umfasst ein Tag-Steuermodul 822 und acht Tag-Puffer 820 ₁ bis 820 ₈. Somit gibt es mehr Tag-Puffer 820 als Tiefenpuffer 318, also können mehrere als ein Tag-Puffer 820 verwendet werden, um sich überlagernde Schichten von Primitivenidentifikatoren für Primitive einer bestimmten Kachel, wie oben in Bezug auf eine Kachel unter Bezugnahme auf Grafikverarbeitungssystem 600 beschrieben wurde, zu speichern. Deshalb kann gesehen werden, dass es eine Gruppe aus acht Tag-Puffern 820 gibt, und das Grafikverarbeitungssystem 800 (insbesondere das Tag-Steuermodul 822) ausgelegt ist, einen jeweiligen Satz aus einem oder mehreren der acht Tag-Puffer 820 jedem der Tiefenpuffer 318 dynamisch zuzuweisen. Das Zuweisen der Tag-Puffer zu den Tiefenpuffern (was einem Zuweisen der Tag-Puffer zu den gerade verarbeiteten Kacheln entspricht) wird in dem Sinn dynamisch durchgeführt, dass es verändert werden kann, um den aktuellen Anforderungen des Grafikverarbeitungssystems 800 zu entsprechen.
Falls beispielsweise keiner der Tag-Puffer 820 eines Satzes, der gerade einer bestimmten Kachel zugewiesen ist, an einer Abtastposition verfügbar ist, wenn ein Primitivenidentifikator eines Primitivs, das diese Abtastposition abdeckt, an dem Tag-Sortiermodul 806 empfangen wird, dann kann das Tag-Steuermodul 822 einen verfügbaren Tag-Puffer 820 zu dem Satz aus Tag-Puffern, die dieser Kachel zugewiesen sind, hinzufügen. Der zusätzliche Tag-Puffer 820 im Satz stellt eine neue Schicht von Primitiven für die Kachel dar, und der Primitivenidentifikator kann im zusätzlichen Tag-Puffer, der die neue Schicht darstellt, gespeichert werden.
Falls (auf dieselbe Art wie im oben angegebenen Beispiel) ein Primitivenidentifikator an einer Abtastposition für einen Tag-Puffer aus dem Satz aus Tag-Puffern, die einer bestimmten Kachel zugewiesen sind, gespeichert werden soll, aber keiner der Tag-Puffer aus dem Satz aus der Abtastposition verfügbar ist und falls (im Gegensatz zu dem oben angegebenen Beispiel) es keine verfügbaren Tag-Puffer in der Gruppe von Tag-Puffern (820 ₁ bis 820 ₈) gibt, dann kann das Tag-Steuermodul 822 die Primitivenidentifikatoren aus einem der Tag-Puffer 820 ₁ bis 820 ₈ entleeren, wodurch der Tag-Puffer verfügbar gemacht wird, so dass der Primitivenidentifikator im verfügbaren Tag-Puffer gespeichert werden kann. Der Tag-Puffer, der zum Entleeren ausgewählt wurde, kann oder kann nicht ein Tag-Puffer sein, der gerade ein Bestandteil des Satzes aus Tag-Puffern ist, die der Kachel zugewiesen sind. Durch das Entleeren eines Tag-Puffers, der einer Kachel zugewiesen ist, und danach einem erneuten Zuweisen des entleerten Tag-Puffers zu einer anderen Kachel, wird der Tag-Puffer in einen anderen Satz verschoben.
Es kann eine vorbestimmte Maximalanzahl von Tag-Puffern 820 geben, die in einem der Sätze aus Tag-Puffern 820, die zu einer Kachel gehören, umfasst sein können. Beispielsweise könnte das Tag-Steuermodul 822 jeder gegebenen Kachel nicht mehr als vier der Tag-Puffer 820 zuweisen.
Die Verteilung von Objekten innerhalb einer Szene ist wahrscheinlich eine solche, dass manche Kacheln transluzente Objekte enthalten und manche nicht. Innerhalb jener Kacheln, die transluzente Objekte enthalten, kann die Komplexität der Szene, d. h. die Anzahl von Schichten der Transluzenz, beträchtlich variieren. Die Flexibilität der Zuordnung von Tag-Puffern 820 und den Kacheln zueinander ermöglicht es, dass die Tag-Puffer 820 verwendet werden können, um die aktuellen Anforderungen des Grafikverarbeitungssystems 800 am besten zu befriedigen.
Wie im oben beschriebenen Grafikverarbeitungssystem 300 werden die entleerten Primitivenidentifikatoren an die Texturiereinheit 308 weitergeleitet. Eine der Texturier-Engines 324 ₁ bis 324 ₄ wendet eine Texturierung und ein Schattieren auf das Primitiv, das von den entleerten Primitivenidentifikatoren identifiziert wurde, an. Wie oben beschrieben ruft eine Texturier-Engine 324 Texturierdaten und die identifizierten Primitive (z. B. aus einem Speicher) ab und wendet die Texturierdaten auf die Primitive, die von den entleerten Primitivenidentifikatoren identifiziert wurden, an. Im in 8 dargestellten Beispiel gibt es vier Texturier-Engines 324 ₁ bis 324 ₄, d. h. es gibt dieselbe Anzahl an Texturier-Engines 324 wie Tiefenpuffer 318 und in diesem Fall ist jede der Texturier-Engines einer jeweiligen Kachel zugewiesen, so dass die gesamte Texturierung, die auf die Primitive einer bestimmten Kachel angewandt wird, von derselben Texturier-Engine 308 durchgeführt wird. Wie oben beschrieben kann dies die Effizienz des Texturierens der Primitive in dem Fall verbessern, in dem es mehrere Kacheln in Bearbeitung gibt. Wie oben beschrieben gibt die Texturiereinheit 308 einen Satz aus Pixelwerten für das Bild aus, die dann im Pixelpuffer 310 gespeichert werden. In anderen Beispielen kann sich die Anzahl von Texturier-Engines 324 von der Anzahl an Tiefenpuffern 318 unterscheiden und in diesem Fall muss nicht jede der Texturier-Engines einer jeweiligen Kachel zugewiesen sein.
Wie oben erwähnt, ähnelt das Steuermodul 816 dem Steuermodul 316 von Grafikverarbeitungssystem 300. Jedoch kann das Steuermodul 816 ferner steuern, welche Primitive von dem Verarbeitungsmodul 302 verarbeitet werden, um dadurch das Umschalten des Verarbeitungsmoduls 302 zwischen einem Verarbeiten von Primitiven für unterschiedliche Kacheln, basierend auf der Anzahl von Tag-Puffern 820 in den Sätzen von Tag-Puffern 820, die unterschiedlichen Kacheln zugewiesen sind, zu steuern. Falls es beispielsweise viele Tag-Puffer 820 gibt, die einer bestimmten Kachel zugewiesen sind, kann das Steuermodul 816 den Block von Warteschlangen 312 steuern, die Ausgabe von Primitiven für diese Kachel zu priorisieren. Wenn viele Tag-Puffer 820 einer Kachel zugewiesen sind, kann dies ermöglichen, dass das Grafikverarbeitungssystem 800 die Primitive für diese Kachel effizienter verarbeitet und daher kann das Steuermodul 816 das Verarbeitungsmodul 302 steuern, Primitive aus dieser Kachel bevorzugt zu verarbeiten.
9a und 9b zeigen ein Flussdiagramm für ein Verfahren, durch das ein Tag-Steuermodul 822 die Auswahl von Tag-Puffern zum Speichern von eingehenden Primitivenidentifikatoren einer Kachel und das Entleeren von Tag-Puffern in einem Beispiel steuern kann.
Zu Beginn sind der Kachel keine Tag-Puffer zugewiesen. Bei Schritt 904 wird ein Satz aus Primitiven-IDs empfangen. Diese Primitiven-IDs entsprechen einem einzigen Primitiv und Abtastpositionen innerhalb der Kachel gemäß den Positionen, an denen das Primitiv als sichtbar bestimmt wurde. Das Primitiv kann undurchsichtig oder transluzent sein. Bei Schritt 906 wird eine Entscheidung getroffen, ob das Primitiv undurchsichtig oder transluzent ist und falls das Primitiv nicht transluzent (d. h. falls es undurchsichtig ist) ist, erfolgt bei Schritt 908 ein Entleerungsvorgang. Schritt 908 wird weiter unten beschrieben. Im anfänglichen Fall, in dem keine Tag-Puffer zugewiesen sind, hat Schritt 908 keine Wirkung. Bei Schritt 910 sucht das Tag-Steuermodul 822 einen Tag-Puffer, in dem die Primitiven-IDs gespeichert werden können. Der Vorgang innerhalb von Block 910 ist unten und in 9b genauer beschrieben. Bei Schritt 912 wird das Ergebnis des Suchvorgangs 910 getestet. Falls die Suche erfolgreich war und ein Tag-Puffer gefunden wurde, geht der Ablauf weiter zu Schritt 914, und die Primitiven-IDs werden im gefundenen Tag-Puffer gespeichert. Im anfänglichen Fall jedoch gibt es keine Tag-Puffer im Satz, der der Kachel zugewiesen ist, und deshalb wird die Suche 910 keinen geeigneten Tag-Puffer finden. In diesem Fall geht der Ablauf weiter zu einer Reihe von Schritten, die versuchen, einen neuen Tag-Puffer zu dem Satz, der der Kachel zugewiesen ist, hinzuzufügen. Schritt 918 testet, ob der Satz aus Tag-Puffern bereits eine vorbestimmte maximale Größe aufweist, und Schritt 920 überprüft, ob es einen verfügbaren Puffer gibt, der gerade keiner Kachel zugewiesen ist. Im anfänglichen Fall schreitet der Ablauf fort zu Schritt 922, in dem dem Satz, der der Kachel zugewiesen ist, ein freier Tag-Puffer hinzugefügt wird. Die Primitiven-IDs können dann in Schritt 914 im Tag-Puffer gespeichert werden. Bei Schritt 916 wird ein Test durchgeführt, um zu bestimmen, ob es mehrere zu verarbeitende Primitive gibt. Der Ablauf wird entsprechend fortgesetzt, entweder zu Schritt 904, um weitere Primitiven-IDs zu empfangen, oder zu Schritt 926, bei dem alle Puffer entleert werden (in der Reihenfolge von hinten nach vorne) und der Vorgang endet.
Der Untervorgang von Schritt 910 ist in 9b dargestellt. Es gilt anzumerken, dass für eine einfachere Erklärung 9a und 9b ein System darstellen, in dem ein Auswählen eines Tag-Puffers zum Speichern der Primitivenidentifikatoren eines Primitivs in der Skalierung von ganzen Kacheln anstatt in der Skalierung von Mikrokacheln oder in der Skalierung von einzelnen Proben durchgeführt wird. Beispiele, in denen ein Tag-Puffer pro Pixel oder pro Mikrokachel ausgewählt wird, können unter Verwendung von geradlinigen Modifikationen an dem hier beschriebenen Verfahren umgesetzt werden, was einem Fachmann klar ist. Der Vorgang beginnt bei 952 und bei 954 wird ein Test durchgeführt, um zu bestimmen, ob der Satz aus Tag-Puffern, die der Kachel zugewiesen sind, leer ist. Falls der Satz leer ist, dann endet der Untervorgang bei 964 und berichtet, dass kein Puffer gefunden wurde. Wenn der Satz wenigstens einen Puffer enthält, unterscheidet sich das Verarbeiten abhängig davon, ob das Primitiv undurchsichtig oder transluzent ist. Dies wird bei 956 getestet und im einfachen Fall eines undurchsichtigen Primitivs endet der Untervorgang bei 966 und berichtet, dass der hintere Puffer, d. h. der Tag-Puffer, der die am weitesten vom Ansichtspunkt entfernte Schicht darstellt, verfügbar ist, um Primitiven-IDs zu speichern. Die restlichen Schritte werden verwendet, wenn Schritt 956 identifiziert, dass das Primitiv transluzent ist. In diesem Fall ist es das Ziel des Untervorgangs, die Tag-Puffer in der Reihenfolge von vorne nach hinten zu durchsuchen und über die hinterste Schicht zu berichten, in der es möglich ist, die Primitiven-IDs zu speichern. Bei 958 stellen Variablen P und C die vorherigen bzw. die aktuellen Tag-Puffer dar. C wird ausgeführt, um den vordersten Puffer anzugeben. P wird den Puffer, der eine Schicht näher zum Vordergrund ist als C, angeben, jedoch wird P, da es keinen näheren Puffer gibt, mit einem Wert ausgeführt, der keinen Puffer angibt. Bei 960 wird ein Test durchgeführt, um zu bestimmen, ob alle Primitiven-IDs im von C angegebenen Puffer gespeichert werden können. Der Vorgang endet, wenn herausgefunden wird, dass die Primitiven-IDs nicht in C gespeichert werden können, da an diesem Punkt bekannt ist, dass der von P angegebene Puffer die hinterste Schicht sein muss, in der es möglich ist, die Primitiven-IDs zu speichern. Schritt 962 gibt die Identität von Puffer P zurück. Im Fall, dass der Test für die vorderste Schicht fehlschlägt, wird der Wert von P direkt angeben, dass aufgrund der Art, auf die P in Schritt 958 ausgeführt wurde, kein Puffer gefunden wurde. Falls der Vorgang nicht endet, d. h. falls die Primitiven-IDs in Puffer C gespeichert werden können, geht der Vorgang zu Schritt 968 weiter, der bestimmt, ob es einen weiteren Puffer gibt, der eine tiefere Schicht als der aktuelle Puffer C darstellt. Falls dies nicht so ist, ist C der hinterste Puffer und die Primitiven-IDs können darin gespeichert werden, somit wird die Identität von Puffer C bei 970 zurückgegeben. Falls ein weiterer Puffer existiert, dann stellt Schritt 972P und C durch einen Rückwärtsschritt ein, sodass P die Identität des zuvor aktuellen Puffers speichert und C die Identität des Puffers, der unmittelbar hinter dem aktuellen Puffer liegt, speichert. Der Ablauf kehrt zu dem Test aus Schritt 960 zurück, wo der Test durchgeführt wird, um zu sehen, ob die Primitiven-IDs im Puffer, der nun von C dargestellt wird, gespeichert werden können.
Zurück in 9a wird das Ergebnis des Untervorgangs 910 bei 912 getestet, um zu bestimmen, ob ein geeigneter Puffer gefunden wurde. Falls ein Puffer gefunden wurde, dann werden die Primitiven-IDs darin in Schritt 914 gespeichert. Wurde kein Puffer gefunden, werden Schritte 918–922 verwendet, um dem Satz einen neuen Tag-Puffer zuzuweisen, und Schritt 914 speichert dann die Primitiven-IDs im neuen Puffer. Im Allgemeinen wird der neue Puffer aus einem Pool aus freien Puffern zugewiesen. Jedoch kann es für den Satz aus Puffern, die einer Kachel zugewiesen sind, nicht wünschenswert sein, ohne Einschränkung zu wachsen, insbesondere falls der Pool aus Puffern mit mehreren anderen Kacheln geteilt wird, wie z. B. in 8 dargestellt. Der Test in Schritt 918 kann verwendet werden, um die Anzahl von Puffern in einem Satz zu beschränken und durch Lenken des Ablaufs zu Schritt 924 zu verursachen, dass der hinterste Puffer entleert wird (d. h. der Inhalt des Puffers wird an Texturier- und Schattierungseinheit 308 gesendet). Der entleerte Puffer kann dann wiederverwendet werden und dem Satz als neuer vorderer Puffer in Schritt 922 hinzugefügt werden. In einer anderen Situation kann der Pool aus freien Puffern leer sein, z. B. wurden die Puffer Sätzen, die anderen Kacheln zugewiesen sind, zugewiesen. Dies wird durch den Test in Schritt 920 detektiert. Der Ablauf wird wiederum zu Schritt 924 gelenkt, wenn ein Puffer entleert wird, um einen neuen, freien Puffer zu erschaffen. Im Fall, dass der Ablauf Schritt 924 aus Schritt 920 anstatt aus Schritt 918 erreicht, ist es möglich, dass der Puffer, der zum Entleeren ausgewählt wurde, ein Mitglied eines anderen Satzes ist als dem, der der aktuellen Kachel zugewiesen ist. Das heißt, vorausgesetzt, dass es möglich ist, einen Satz zu vergrößern, kann der Satz durch Entleeren und Übertragen eines Puffers aus einem anderen Satz vergrößert werden. Auf diese Art können die Tag-Puffer unter der Steuerung des Steuermoduls 816 und/oder des Tag-Sortiersteuermoduls 822 flexibel gemäß den Systemanforderungen zugewiesen werden.
Wird bei Schritt 906 ein undurchsichtiges Primitiv identifiziert, führt Schritt 908 einen Entleerungsvorgang durch. Der Tag-Sortierer empfängt nur Primitiven-IDs für Fragmente, die einen Tiefentest bestanden haben. Deshalb ist bekannt, dass undurchsichtige Primitiven-IDs vor allen anderen undurchsichtigen oder transluzenten Primitiven, die bereits verarbeitet wurden, angeordnet sein müssen und diese deshalb verdecken. Die Primitiven-IDs für undurchsichtige Objekte können deshalb immer im hintersten Tag-Puffer gespeichert werden. Schritte 956 und 966 von Untervorgang 910 identifizieren undurchsichtige Objekte und geben die Identität des hintersten Puffers zurück. Schritt 908 entleert die gespeicherten Primitiven-IDs in Bezug auf jegliche transluzenten Objekte, die bereits in irgendeiner Pufferschicht gespeichert sind, an den Positionen, die den undurchsichtigen Primitiven-IDs entsprechen. Dies hat den Effekt, dass die Schichtstruktur geebnet wird, was sicherstellt, dass transluzente Fragmente nicht unnötig oder inkorrekt gerendert werden. Gegebenenfalls kann Schritt 308 bestimmen, dass der Entleerungsvorgang einen Tag-Puffer vollständig entleert hat, und kann die leere Schicht zurück in den Pool aus freien Puffern schicken.
Wie oben beschrieben werden Primitive mit Durchgriff in zwei Durchgängen gerendert. Im ersten Durchgang können Primitiven-IDs für Primitive mit Durchgriff, bevor die Transluzenz bewertet wurde, wie transluzente Primitive behandelt werden. Im zweiten Durchgang entspricht eine Primitiven-ID mit Durchgriff einem Teil des Objekts, der bekanntlich undurchsichtig ist. Deshalb können Primitiven-IDs für Primitive mit Durchgriff im zweiten Durchgang wie undurchsichtige Primitive behandelt werden.
Oben sind Beispiele im Detail beschrieben, die ein Empfangen von Primitivenidentifikatoren von transluzenten Primitiven an dem Tag-Sortiermodul betreffen. Dieselben Prinzipien können verwendet werden, wenn Primitivenidentifikatoren für Primitive mit Texturen, einschließlich eines Durchgriffs, empfangen werden.
Die hier beschriebenen Verfahren könnten durch Ausführen eines geeigneten computerlesbaren Codes umgesetzt werden, der angepasst ist, um die Schritte der Verfahren durchzuführen. Außerdem könnte das hier beschriebene Grafikverarbeitungssystem durch Ausführen eines geeigneten computerlesbaren Codes erstellt werden. Der computerlesbare Code könnte auf einem computerlesbaren Speichermedium codiert sein.
Im Allgemeinen kann jede der Funktionen, jedes der Verfahren, jede der Techniken oder jedes der Elemente, die oben beschrieben sind, in Modulen unter Verwendung von Software, Firmware, Hardware (z. B. fixen logischen Schaltungen) oder jeder Kombination aus diesen Implementierungen umgesetzt werden. Die Begriffe „Modul”, „Funktionalität”, „Element”, „Block”, „Einheit” und „Logik” werden hier verwendet, um Software, Firmware, Hardware oder jede Kombination daraus allgemein darzustellen.
Im Fall einer Software-Implementierung stellt das Modul, die Funktionalität, das Element, der Block, die Einheit oder die Logik einen Programmcode dar, der spezielle Aufgaben ausführt, wenn er auf einem Prozessor (z. B. einem oder mehreren CPUs) ausgeführt wird. In einem Beispiel können die beschriebenen Verfahren von einem Rechner ausgeführt werden, der mit Software in maschinenlesbarer Form, gespeichert auf einem computerlesbaren Medium, konfiguriert ist. Eine solche Konfiguration eines computerlesbaren Mediums ist ein signaltragendes Medium und ist somit ausgelegt, die Befehle (z. B. als eine Trägerwelle) an die Rechnervorrichtung zu übertragen, wie über ein Netz. Das computerlesbare Medium kann ebenfalls als ein computerlesbares Speichermedium ausgelegt sein und ist somit kein signaltragendes Medium. Beispiele für ein computerlesbares Speichermedium umfassen einen Random Access Memory (RAM), einen Read Only Memory (ROM), eine Optical Disc, einen Flash Memory, einen Festplattenspeicher und andere Speichervorrichtungen, die eine magnetische, optische und andere Technologie verwenden, um Befehle oder andere Daten zu speichern, auf die von einer Maschine zugegriffen werden kann.
Die Software kann in Form eines Computerprogramms sein, das Computer-Programmiercode zum Konfigurieren eines Computers umfasst, um die einzelnen Teile der beschriebenen Verfahren durchzuführen, oder in Form eines Computerprogramms sein, das Computer-Programmcodemittel umfasst, die adaptiert sind, um alle Schritte jedes der hier beschriebenen Verfahren auszuführen, wenn das Programm auf einem Rechner ausgeführt wird und wo das Computerprogramm auf einem computerlesbaren Medium ausgeführt sein kann. Der Programmcode kann in einem oder mehreren computerlesbaren Medien gespeichert sein. Die Merkmale der hier beschriebenen Verfahren sind Plattformunabhängig, das bedeutet, dass die Verfahren auf einer Mehrzahl von Computerplattformen mit einer Mehrzahl von Prozessoren ausgeführt werden können.
Fachleute werden ebenfalls erkennen, dass die gesamte Funktionalität, alle Techniken oder alle Verfahren oder ein Teil davon von einer Festschaltung, einer anwendungsspeziellen integrierten Schaltung, einer programmierbaren Logikanordnung, einer feldprogrammierbaren Gatter-Anordnung oder dergleichen durchgeführt werden können. Beispielsweise kann das Modul, die Funktionalität, das Element oder die Logik Hardware in Form von Schaltungen umfassen. Solche Schaltungen können Transistoren und/oder andere Hardware-Elemente, die in einem Herstellungsprozess verfügbar sind, umfassen. Solche Transistoren und/oder andere Elemente können verwendet werden, um Schaltungen oder Strukturen zu bilden, die z. B. einen Speicherwie Register, Flip-Flop-Schaltungen oder Verriegelungen, logische Operatoren wie Boolsche Operatoren, mathematische Operatoren wie Addierer, Multiplikatoren oder Verschieber und Zwischenschaltungen ausführen und/oder enthalten. Solche Elemente können als spezielle Schaltungen oder Standard-Zellenbibliotheken, Makros oder auf anderen Abstraktionsebenen bereitgestellt sein. Solche Elemente können in einer speziellen Anordnung miteinander verbunden sein. Das Modul, die Funktionalität, das Element oder die Logik können Schaltungen umfassen, die eine fixe Funktion aufweisen, und Schaltungen, die programmiert sein können, eine Funktion oder Funktionen auszuführen; eine solche Programmierung kann durch ein Firmware- oder Softwareupdate oder einen Steuermechanismus bereitgestellt werden. In einem Beispiel weist eine Hardwarelogik Schaltungen auf, die einen fixen Funktionsbetrieb, eine Zustandsmaschine oder einen Vorgang ausführen.
Ebenfalls soll Software beinhaltet sein, die die Konfiguration von Hardware „beschreibt” oder definiert, die ein Modul, eine Funktionalität, ein Element oder eine Logik, die oben beschrieben wurden, wie HDL(Hardware Description Language)-Software, wie sie für das Erstellen von integrierten Schaltungen oder für das Konfigurieren von programmierbaren Chips verwendet wird, zum Durchführen der gewünschten Funktionen ausführt. Das heißt, es kann ein computerlesbares Speichermedium mit einem darauf codierten computerlesbaren Programmcode zum Erstellen einer Prozessoreinheit bereitgestellt sein, um jedes der hier beschriebenen Verfahren durchzuführen oder um eine Prozessoreinheit zu erstellen, die jede hier beschriebene Vorrichtung umfasst.
Die Begriffe „Prozessor” und „Rechner” sind hier so verwendet, dass sie sich auf jede Vorrichtung oder einen Teil davon mit einer Prozessorfähigkeit beziehen, so dass sie Befehle ausführen kann, oder dass sie sich auf eine Festschaltung beziehen, die in der Lage ist, die gesamte Funktionalität oder alle Verfahren oder einen Teil davon oder jede Kombination daraus durchzuführen.
Obwohl der Gegenstand in einer Sprache beschrieben wurde, die speziell auf strukturelle Merkmale und/oder methodologische Vorgänge ausgelegt ist, gilt zu verstehen, dass der Gegenstand, der in den angefügten Patentansprüchen definiert ist, nicht notwendigerweise auf die oben beschriebenen speziellen Merkmale oder Vorgänge beschränkt ist. Vielmehr sind die speziellen oben beschriebenen Merkmale und Vorgänge als beispielhafte Formen zum Ausführen der Patentansprüche offenbart. Es gilt zu verstehen, dass der oben beschriebene Nutzen und die Vorteile ein Beispiel betreffen können oder mehrere Beispiele betreffen können.
Jeder Bereich oder Wert, der hier angegeben ist, kann erweitert oder verändert werden, ohne dabei den gewünschten Effekt zu verlieren, wie einem Fachmann bewusst ist. Beispielsweise sind die speziellen Zahlen, die in den oben beschriebenen Beispielen angegeben sind (z. B. die Anzahl von Tag-Puffern, Tiefenpuffern, Warteschlangen, Texturier-Engines, Kacheln, Mikrokacheln innerhalb einer Kachel und Abtastpositionen innerhalb einer Mikrokachel), nur beispielhaft angegeben. Die Schritte der hier beschriebenen Verfahren können in jeder geeigneten Reihenfolge oder, falls angemessen, gleichzeitig durchgeführt werden. Aspekte jedes der oben beschriebenen Beispiele können mit Aspekten aus jedem der anderen beschriebenen Beispiele kombiniert werden, um weitere Beispiele zu bilden, ohne dabei den gewünschten Effekt zu verlieren.

Claims

Grafikverarbeitungssystem mit einem Renderingraum, der in Kacheln unterteilt ist, wobei das Grafikverarbeitungssystem umfasst: mehrere Tiefenpuffer, wobei jeder der Tiefenpuffer ausgelegt ist, zu einer Zeit dynamisch einer Kachel zugewiesen zu sein, und ausgelegt ist, einen Tiefenwert für jede Abtastposition innerhalb der Kachel zu speichern; und ein Verarbeitungsmodul, das ausgelegt ist, Primitive und Kacheldaten zu empfangen, wobei für jedes Primitiv die Kacheldaten eine oder mehrere Kacheln angeben, in denen dieses Primitiv verarbeitet werden wird, und wobei das Verarbeitungsmodul ausgelegt ist, eine verdeckte Oberflächenentfernung für ein Primitiv einer Kachel durch Vergleich von Tiefenwerten für dieses Primitiv durchzuführen, wobei Tiefenwerte in dem der Kachel zugewiesenen Tiefenpuffer gespeichert sind, während ein anderer der Tiefenpuffer Tiefenwerte für eine andere teilweise verarbeitete Kachel speichert.
Grafikverarbeitungssystem nach Anspruch 1, wobei das Verarbeitungsmodul ausgelegt ist, einen oder mehrere Tiefenwerte, die im einer Kachel zugewiesenen Tiefenpuffer gespeichert sind, als Teil einer Durchführung der verdeckten Oberflächenentfernung für ein Primitiv der Kachel zu aktualisieren.
Grafikverarbeitungssystem nach Anspruch 1 oder 2, ferner umfassend mehrere Tag-Puffer, die ausgelegt sind, dynamisch den Kacheln zugewiesen zu sein, so dass ein Satz von einem oder mehreren der Tag-Puffer einer bestimmten Kachel zugewiesen ist, wobei der Satz von Tag-Puffern ausgelegt ist, Primitivenidentifikatoren zu speichern, die die Primitiven identifizieren, die durch die verdeckte Oberflächenentfernung als für jede Abtastposition in der entsprechenden Kachel sichtbar bestimmt wurden.
Grafikverarbeitungssystem nach Anspruch 3, wobei, falls der Satz von der bestimmten Kachel zugewiesenen Tag-Puffern mehr als einen Tag-Puffer enthält, dann Primitivenidentifikatoren, die an entsprechenden Abtastpositionen in den Tag-Puffern aus dem Satz gespeichert sind, überlagernde Schichten von Primitiven darstellen.
Grafikverarbeitungssystem nach Anspruch 3 oder 4, wobei das Grafikverarbeitungssystem mehr Tag-Puffer als Tiefenpuffer umfasst.
Grafikverarbeitungssystem nach einem der Ansprüche 3 bis 5, das ferner eine oder mehrere Texturier-Engines umfasst, die ausgelegt sind, eine Texturierung auf die Primitiven von Kacheln anzuwenden, die von Primitivenidentifikatoren identifiziert wurden, die in den Tag-Puffern gespeichert sind, die den Kacheln zugewiesen sind.
Grafikverarbeitungssystem nach Anspruch 6, wobei das Grafikverarbeitungssystem ausgelegt ist, alle der Primitivenidentifikatoren in dem Satz von Tag-Puffern, die einer bestimmten Kachel zugewiesen sind, an dieselbe Texturier-Engine zu schicken, so dass alle der Texturierungen, die auf die sichtbaren Primitiven der bestimmten Kachel angewandt werden, von derselben Texturier-Engine angewandt werden.
Grafikverarbeitungssystem nach Anspruch 6 oder 7, wobei die Anzahl von Texturier-Engines dieselbe wie die Anzahl von Tiefenpuffern ist.
Grafikverarbeitungssystem nach einem vorangehenden Anspruch, das ferner ein Steuermodul umfasst, das ausgelegt ist, zu steuern, welche Primitiven von dem Verarbeitungsmodul verarbeitet werden, um dadurch ein Umschalten des Verarbeitungsmoduls zwischen Verarbeiten von Primitiven für unterschiedliche Kacheln zu steuern.
Grafikverarbeitungssystem nach Anspruch 9, das ferner mehrere Warteschlangen umfasst, die Primitive für eine bestimmte Mehrzahl von Kacheln speichern, wobei das Steuermodul ausgelegt ist, eine der Warteschlangen auszuwählen, wobei ein Primitiv aus der ausgewählten Warteschlange von dem Verarbeitungsmodul verarbeitet wird.
Grafikverarbeitungssystem nach Anspruch 9 oder 10, wobei das Steuermodul ausgelegt ist, zu steuern, welche Primitiven von dem Verarbeitungsmodul verarbeitet werden, basierend auf Zustandsinformationen, die den Zustand des Grafikverarbeitungssystems betreffen.
Grafikverarbeitungssystem nach Anspruch 11, wenn von einem der Ansprüche 6 bis 8 abhängig, wobei die Zustandsinformationen eine Angabe umfassen, dass eine Texturier-Engine frei ist oder frei wird, und wobei das Steuermodul ausgelegt ist, das Verarbeiten von Primitiven für eine Kachel zu priorisieren, falls die Texturier-Engine, die ausgelegt ist, Texturierung auf die Primitiven dieser Kachel anzuwenden, als frei seiend oder frei werdend angegeben ist.
Grafikverarbeitungssystem nach Anspruch 11 oder 12, wobei die Zustandsinformationen eine Angabe umfassen, dass die Verarbeitung einer Kachel angehalten wurde, und wobei das Steuermodul ausgelegt ist, das Verarbeiten von Primitiven für eine angehaltene Kachel zu depriorisieren.
Grafikverarbeitungssystem nach einem der Ansprüche 11 bis 13, wobei die Zustandsinformationen eine Angabe umfassen, dass es eine große Menge an Daten gibt, die in einer Kachel verarbeitet werden müssen, und wobei das Steuermodul ausgelegt ist, das Verarbeiten von Primitiven für diese Kachel zu priorisieren.
Verfahren zum Verarbeiten von Primitiven in einem Grafikverarbeitungssystem mit einem Renderingraum, der in Kacheln unterteilt ist, wobei das Verfahren umfasst: Speichern von Tiefenwerten in mehreren Tiefenpuffern, wobei jeder der Tiefenpuffer zu einer Zeit dynamisch einer Kachel zugewiesen und ausgelegt ist, einen Tiefenwert für jede Abtastposition innerhalb der Kachel zu speichern; Empfangen von Primitiven und Kacheldaten an einem Verarbeitungsmodul, wobei für jedes Primitiv die Kacheldaten eine oder mehrere Kacheln angeben, in denen dieses Primitiv verarbeitet werden wird; und Durchführen einer verdeckten Oberflächenentfernung am Verarbeitungsmodul für ein Primitiv einer Kachel durch Vergleich von Tiefenwerten für dieses Primitiv, wobei Tiefenwerte in dem der Kachel zugewiesenen Tiefenpuffer gespeichert sind, während ein anderer der Tiefenpuffer Tiefenwerte für eine andere teilweise verarbeitetete Kachel speichert.
Verfahren nach Anspruch 15, das ferner ein Aktualisieren eines oder mehrerer Tiefenwerte umfasst, die im einer Kachel zugewiesenen Tiefenpuffer gespeichert sind, als Teil der Durchführung der verdeckten Oberflächenentfernung für ein Primitiv der Kachel.
Verfahren nach Anspruch 15 oder 16, das ferner umfasst: dynamisches Zuweisen mehrerer Tag-Puffer zu den Kacheln, so dass ein Satz von einem oder mehreren der Tag-Puffer einer bestimmten Kachel zugewiesen wird; und Speichern in dem Satz von Tag-Puffern von Primitivenidentifikatoren, die die Primitiven identifizieren, die durch die verdeckte Oberflächenentfernung als für jede Abtastposition in der entsprechenden Kachel sichtbar bestimmt wurden.
Verfahren nach Anspruch 17, das ferner eine Anwendung von Texturieren auf die Primitiven von Kacheln umfasst, die von Primitivenidentifikatoren identifiziert wurden, die in den Tag-Puffern gespeichert sind, die den Kacheln zugewiesen sind, wobei das Texturieren durch eine oder mehrere Texturier-Engines angewandt wird, und wobei das Verfahren ein Schicken aller der Primitivenidentifikatoren in dem Satz von Tag-Puffern, die der bestimmten Kachel zugewiesen sind, an dieselbe Texturier-Engine umfasst, so dass alle der Texturierungen, die auf die sichtbaren Primitiven der bestimmten Kachel angewandt werden, von derselben Texturier-Engine angewandt werden.
Verfahren nach einem der Ansprüche 15 bis 18, das ferner ein Steuern, welche Primitiven von dem Verarbeitungsmodul verarbeitet werden, um dadurch ein Umschalten des Verarbeitungsmoduls zwischen Verarbeiten von Primitiven für unterschiedliche Kacheln zu steuern, umfasst.
Computerlesbares Speichermedium, auf dem mindestens einer der Folgenden codiert ist: (i) computerlesbarer Code, der angepasst ist, um die Schritte des Verfahrens nach einem der Ansprüche 15 bis 19 durchzuführen, wenn der Code auf einem Computer ausgeführt wird, und (ii) computerlesbarer Code zum Erstellen eines Grafikverarbeitungssystems nach einem der Ansprüche 1 bis 14.