TBR notwendig ?

[Labberlippe]

Hi

Auch auf die Gefahr hin das ich mich jetzt als Anfänger oute aber ich habe mir ein paar Gedanken Richtung Kyro als TBR gemacht.

Die Frage die sich mir stellt ob ein TBR Chip überhaupt Vorteile noch zu einen herkömmlichen Renderer hat.
nVIDIA und ATi haben möglichkeiten mit LMA und HyperZ entwickelt um Bandbreite zu sparen.
Auch diese Chip lassen quasi einen Teil der Polygone weg, welche nicht benötigt werden.
Wenn ich mir die Boliden von einer R9700 und FX oder GeForce4 TI4600 ansehe, welche bei Standartsettings von 1024x768 noch immer auf die CPU quasi warten müssen, dann kann hier der TBR auch nicht schneller werden. (Theoretisch zumindest)

Bei spielen ala Fifa wo die Szenen Ansicht schräg von oben ist, gibt es nicht viel Dinge die ein TBR weglassen kann.
Ok ich sage mal die Details von Stadien welche im moment nicht wirklich sichtbar sind aber viel ist das gerade nicht.

Was mich eigentlich interresiert ist, wie das mit der beleuchtung funktioniert.
Angenommen das Stadium wird von mehreren Lichtquellen dynamisch beleuchtet.
Wie handhabt das der TBR dann. ???
Nach meinen Gedankengang müsste auch der TBR zuerst die Beleuchtung machen und erst dann kann er das Bild in Tiles zerlegen und wie gehabt ausgeben.
Wenn er das erst danach macht dann müsste er ja dennoch auf einen Z Buffer zurückgreifen, damit die Beleuchtung korrekt ist.
Kurz wenn der TBR die Beleuchtung vor dem bearbeiten durchführt, dann muss der TBR in der Lage sein wirklich mehrerer Lichtquellen schnell zu beleuchten, sonst bremst er sich wieder selbst aus.
Mein Gedanke ist der, wenn er die beluchtung vorher macht, dann kann sich hier der TBR auch nicht viel Zeit einsparen.


Die neuen Karten ala ATi und nVIDIA bieten ja Pixel und Vertesshader in div. Versionen welche immer flexibler werden.
Hier stelle ich mir die Frage wie das ein TBR anstellen wird.
Die Frage ist sind die Pipelines so flexibel aufgebaut wie bei den Mitbewerbern.
Div Effekte werden ja über Instruktionen über die Pipelinse erledigt.
Wenn hier ein TBR dies nicht direkt über die Pipelines abarbeitet, dann müste er quasi eine exterene PS und VS Einheit haben.
Ob die jetzt ein extra Chip ist oder in der GPU integriert ist, spielt keine Rolle.
Kurz ein Teil in der GPU berechnet die PS Effekte gibt das dann weiter, dann kommt die Beleuchtung und erst jetzt wird das Bild in Kacheln aufgeteilt.
Da Frage ich mich dann wo der Vorteil von der TBR Technik sein soll wenn hier wieder auf die exterene PS Einheit gewartet werden muss.

Leider habe ich nicht allzuviel Ahnung wie ein TBR genau funktioniert und hoffe das Ihr mir hier weiterhelfen könnt.
Allzuviel Dokumentationen wie genau der TBR funktioniert habe ich leider nicht gefunden und mein Englisch ist nicht das beste.

Thx schon mal im vorraus.

Hoffe ein festes plauern


Gruss Labberlippe

[x-dragon]

Das interessiert mich ehrlich gesagt auch. Besonders bei Licht- und Schatteneffekten müssten ja oft Polygone berücksichtigt werden, die eigentlich gar nicht direkt sichtbar sind (also z.B. nur dessen Schatten).

[Demirug]

Ich verschieb das mal nach Technologie, und schreibe später noch eine ausführliche Antwort.

[HOT]

Na ja wer weiss ob PowerVR in der serie5 überhaupt noch das klassische TBR nutzt ;)

[ice cool69]

ich bin mir sicher dass sie TBR verwenden werden. die technik funktioniert klasse und man muss nicht so teuren speicher/hohen chiptakt anbieten um auf eine ähnliche leistung zu kommen.

[LovesuckZ]

Originally posted by ice cool69
ich bin mir sicher dass sie TBR verwenden werden. die technik funktioniert klasse und man muss nicht so teuren speicher/hohen chiptakt anbieten um auf eine ähnliche leistung zu kommen.

Hm, jedoch muessen sie mehr Chiptakt, in relation, verwenden als noch zur GF2 Zeiten.Da die beiden großen Firmen mehr auf schoenende Maßnahmen setzen und dabei weiter an der Taktschraube drehen.

[loewe]

Ich kann mich ja mal kurz an einen Beantwortung versuchen.

Zum ersten es ist falsch das TBR auf Tiling zu zu beschränken. Eigentlich sollten wir grundsätzlich vom deferred Rendering sprechen, Tiling ist eigentlich "nur" die logische Konsequenz.
Weiterhin ist es genauso flasch die TBDRs auf den Vorteil bezüglich des Overdraws zu beschränken, der Vorteil bleibt zwar bestehen, erreicht aber nie wieder die Größe wie beim Vergleich KYRO - GF2MX. Natürlich kann ich bei IMRs durch entsprechende Massnahmen (z.b. LMA und HyperZ) einen gut Teil des Overdraws vermeiden, aber es bleibt dabei, wirklich funktionieren tut das nur für eine gute Front to Back Sortierung, in jedem anderen Fall muss ein IMR hier versagen. Es ist aber sicher nicht möglich oder auch nicht sinnvoll immer alle Dreiecke durch die Applikation entsprechend zu sortieren, ich habe aber davon keine Ahnung, da sollte sich Demirug zu äußern.
Wie gut so etwas sein kann hat NVidia übrigens mit ihren GF4MX Karten bewiesen, die Karten kommen in einer ganzen Menge von Anwendungen durchaus an die Effizienz der KYRO heran, wie mein nie erschienenes Review der K2SE gezeigt hätte.

Nur ein TBDR kann den Overdraw, welcher durch undurchsichtige Objekte entsteht auf Null bringen, aber darauf läßt sich ein TBDR ja nicht beschränken.

Vielleicht noch mal ein kurzer Überblick:

Die PowerVR Architektur unterteilt den Chip in folgende drei Teile: TA (Tile accelerator), ISP (Image Synthesis Processor) und TSP (Texture Shading Processor).

1. TA
Der TA übernimmt die Grafikpipeline nach der Applikationsebene, sprich er übernimmt
- Tesselation
- Transformation
- Lighting
- small object culling
- Clipping
- Tilling.

Ein Triangle Setup wird nicht gebraucht, das macht der HSR Algorithmus nebenbei mit.
Der TA erzeugt im Ergebnis eine komplette Displayliste des Frames und die Pointerlisten jedes einzelnen Tiles, sprich eine Displayliste je Tile.

Ob Transformation und Lighting nun durch die CPU oder durch eine Hardware T&L Einheit, in welcher Form auch immer, durchgeführt werden ist dabei völlig egal. Wie wir schön öfter mal bemerkt haben, PowerVR hat durchaus Erfahrung mit Hardware T&L, siehe Naomi2.

Es gibt hier im ersten Teil keine so großen Unterschiede zu den IMRs, nur das eben zum Schluss eine Displayliste angelgt wird.
Die neueren Serien enthalten zusätzlich noch einen so genanten Event Manager, der die Bearbeitung beliebig großer Szenen mit festen Buffergrößen erlaubt.

2. ISP
Der wesentliche Teil des ISP besteht in der HSR Einheit. Der ISP arbeitet jetzt die Displayliste tileweise ab und bestimmt dabei für jedes Pixel im Tile das jeweils erste undurchsichtige Dreieck und für alle davor liegenden durchsichtigen Dreiecke wird je Pixel eine im Chip befindliche sortierte Liste erzeugt. Der Z-Wert vom undurchsichtigen Dreieck wird auch in einem Chipinternen Speicher für Operationen mit dem Tiefenbuffer gespeichert. Das hier benutzte Verfahren ist sehr effektiv und der Vorgang läßt sich theoretisch beliebig parallelisieren. KYRO verarbeitet je Takt ein Dreieck auf 32 Pixeln parallel, braucht also je Dreieck 16 Takte (ein Tile ist 32x16 Pixel).

Diese Daten werden an den TSP übergeben.

3 TSP
Der TSP ist für das Perpixel Shading und Texturing zuständig. Hier gibt es keine grossen Unterschiede zu IMRs, auch hier kann also problemlos ein Pixelshader zum Einsatz kommen. Wesentlich bleibt aber, alle Operationen werden hier auf den onchip Buffer durchgeführt, das bringt dem Tiler einen wesentlichen Bandbreitenvorteil. Der onchip Buffer wird erst in den Framebuffer geschrieben, wenn ein Tile vollständig abgearbeitet ist.


Wenn man also TBDR schon definieren will, sollte man als wesentlichen Punkt die bisher kaum zu schlagende Effizienz des Verfahrens nennen.
Zukünftige Chips werden darüber hinaus nahezu alle Daten die hier beteiligt sind komprimieren, also sowohl die Displayliste, als auch Texturen, selbst den Framebuffer. PowerVR verfügt hier über ein verlustfreies wohl recht gutes Komprimierungsverfahren, womit zusätzlich die Bandbreite geschont wird.


Was ich aber für unrealistisch halte sind die Aussagen mit dem wesentlich geringeren Chiptakt und dem billigen Speicher. Wenn ein TBDR ein highend Chip sein soll, wird er ähnlich viele Transistoren haben wie ein IMR, etwa gleich schnell getaktet sein und ein schnellen und viel Speicher benötigen.
Wovon ich aber überzeugt bin,
ein TBDR mit nahezu gleichen Daten wie ein IMR wird den IMRs das Leben sehr schwer machen.

[aths]

Originally posted by loewe
ein TBDR mit nahezu gleichen Daten wie ein IMR wird den IMRs das Leben sehr schwer machen. Imo kann es sich keiner auf Dauer leisten, High-End-Beschleunigung ohne Deferred Rendering zu entwerfen. Gerade wenn lange Shader ins Spiel kommen, ist man über jedes Sample froh, das gespart werden kann.

[Demirug]

so dann will ich mal :)

Zuerst muss man vorweg schicken das ein guter TBDR aus der gleichen grundmengen an Daten das gleiche Bild wie ein IMR zu erzeugen hat. Tut er das nicht ist er für den PC Markt nicht zu gebrauchen und kann nur in properitären Systemen (z.b. Konsolen) eingesetzt werden da dort die Programmierer ja auf die besonderheiten Rücksicht nemen können.

Die Frage ist also eigentlich nicht wie ein TBDR mit dynamischem Licht umgeht sonder wie es Hardwarerenderer allgemein tun.

Die einfache Antwort auf diese Frage ist:

Alle Licht und Schatten Effekte entstehen durch das Zusammenwirken von Vertex und Pixelshader sowie den davon getrenneten Teilen der Renderpipeline (z.b. Stencilbuffer).

Schauen wir und mal wieder DOOM III als Paradebeispiel für dynamisches Licht und Schatten an.

DOOM III arbeitet nach einen Lichtquelle für Lichtquelle Prinzip. Das heist jede Lichtquelle wird einzelen bearbeitet. Schauen wir uns nun einmal das Rendern einer solchen Lichtquelle an.

Da wir Licht und Schatten wollen sind auch zwei Schritte notwenig.

1. Ermitteln auf welche Pixel (bzw. AA-Sample) überhaupt Licht fällt. Das ganze wird mit Hilfe eines Schattenvolumen verfahrens gemacht. Dazu gibt es einiges im Internet zu finden. Kurz gesagt wird dabei für jedes von der Lichtquelle bestrahlten Objekts ein Schattenvolumen in den Stencilbuffer gerendert. Da Vorder und Rückseite unterschiedliche Aktionen im Stencilbuffer ausführen enthält der Stencilbuffer am Ende die Information wo Licht und wo Schatten ist. Für alle die nicht wissen was der Stencilbuffer ist. Es handelt sich dabei einfach um einen zusätzlich Speicher von ein paar Bits (üblicherweise 8) pro AA-Sample in welcher zusätzliche Informationen hinterlegt werden können. sowie in abhängigkeit von bestimmten Faktoren (z.b. Z-Test) einfache mathematische Operationen durchgeführt werden können (z.b. Aktuellerwert+1 oder Aktuellerwert-1)

In unserem Stencilbuffer ist also nun die Information gespeichert wo Licht und wo Schatten ist und wir können mit den nächsten Schritt weiter machen.

2. Jedes Objekt welches von der Lichtquelle bestrahlt wird muss nun gerendert werden. Für jeden Pixel der dabei entsteht wird nun mit dem Stencilbuffer geprüft ob dort überhaupt Licht sein darf. Falls nicht kann man sich den Rest schenken.

Für alle Pixel die den Stenciltest überleben muss nun die Farbe bestimmt werden. Dazu muss über den Vertex und Pixelshader eine mathematische Formel berechnet werden. Kurz gesagt berechnet Sich die Farbe eines beleuteten Pixel immer nach dem gleichen Grundprinzip.

a. Man bestimmt die Lichtmenge welche von der Lichtquelle ausgehend den Pixel erreicht. Dabei können Faktoren wie Entfernung, Richtung des Lichtvektors, die Lichtmenge die überhaupt von der Quelle augeht und vieles mehr eine Rolle Spielen.

b. Das zweite was nun bestimmt wird ist der Lichtanteil welcher von dem Pixel überhaupt reflektiert werden kann. Dabei können Dingen wie das Material, die räumliche Lage, der Auftreff-Winkel und noch so ein menge mehr eine Rolle spielen.

c. Das Produkt aus Lichtmenge die auftrifft und der Lichtmenge die refelktiert werden kann ergibt die Farbe die man dann zu sehen bekommt. Und damit das ganze auch schön Bunt wird macht man das für jeden Farbkanal (Rot, Grün und Blau) getrennt.

Jetzt haben wir eine Lichtquelle berechnet. Mit allen anderen machen wir das gleiche. Und bei allen Objekten die von mehr als einer Lichtquelle bestrahlt werden addiert man die Farbwerte von allen Lichtquellen einfach auf. Wenn man aber grundsätzlich den neuen Lichtwert zu dem im Framebuffer gespeicherten aktuellen addiert braucht man solche fälle gar nicht besonders zu betrachten. Dann man den Framebuffer am Anfang mit schwarz löscht besteht der Endwert im Falle von nur einer Lichtquelle eben aus Schwarz+Lichtwert und das ist nun mal das gleiche wie nur der Lichtwert weil sich schwarz bei einer addition neutral verhält.

Das Verfahren funktioniert bei einem TBDR genauso gut wie bei einem IMR.

Die Frage noch dem Vorteil ist nun etwas schwerer zu beantworten.

Im Vertexshaderbereich gibt es im Prinzip eigentlich erst mal keinen Vorteil. Ein TBDR kann sich hier keine Arbeit sparen da alle Vertexdaten transformiert werden müssen. Da bei ihm aber die VS und PS entkoppelt sind können die PS die VS nicht Blockieren was auf einem IMR möglich ist. Dafür kann bei einem TBDR das Binning den Vertexshader blockieren. Hier spielen also die Caches eine grosse Rolle weswegen sich keine allgemeine Aussage machen läst.

Bei den PS hat der TBDR ja den Vorteil das dort keine Pixel mehr ankommen die nicht berechnet werden müssen. Da aber DOOM III ja zuerst einen Z-Only Pass rendert müssen bei einem IMR mit gutem Early-Z auch keine nicht sichtbaren Pixel mehr berechnet werden. Aber wenn sehr viele Pixel am stück verworfen werden laufen die Pixelpipeline leer. Das kann zwar auch bei einem TBDR passieren. Nur müssten dann dafür jeweils sehr viele Dreiecke pro Tile gespeichert sein damit das HSR länger dauert als die PS brauchen. Da die HSR einheiten aber oft sehr grosszügig ausgelegt werden ist das nicht unbedingt wahrscheinlich. Die PS auf einem TBDR könnte also in abhängig wie gut das Early-Z und die Caches auf einem IMR sind durchaus einen Vorteil haben.

Kommen wir nun zu der Bandbreiten Betrachtung. Einsparen von Bandbreite für Texturezugriffe ist im Verhältniss zu einem IMR mit gutem Early-Z nicht gegeben da ja bei beiden keine Texturen geholt werden die nicht sichtbar sind.

Bandbreiteverbrauch für Z und Stencilbuffer entfallen beim TBDR natürlich komplett. Im Gegenzug entsteht dort aber zusätzlicher Bandbreitenbedarf für das Speichern und wieder einladen der Gesammten Framedaten. Dazu gehören neben der eigentlichen Geometrie auch Angaben über benutzte Texturen, Pixelshader programme und Konstanten, Konstanten, Alaphablending Setting und vieles mehr. Im Verhältniss zu den Serie 3 Chips ist da einiges hinzugekommen. Wie sich zum Beispiel die Texturecaches bei einem TBDR verhalten ist auch schwer vorherzusagen.

IMO wird der Unterschied bei der benötigten Bandbreite, Coretakt und Transitorenanzahl zwischen einem Highend IMR und Highend TBDR nur sehr klein sein.

Wer sich bis hier her durch meinen vielen Text durchgekämpft hat darf sich einen Dauerlutscher nehmen. ;) Sorry für den vielen Text aber kürzer ging es irgendwie nicht.

[x-dragon]

*Dauerlutschernimmt* Danke, für die ausführliche Antwort jetzt ist es zumindest schon mal etwas klarer geworden :).

Aber vielleicht nochmal ganz kurz eine Erklärung dazu:
"Dafür kann bei einem TBDR das Binning den Vertexshader blockieren."

Wie kann das TBDR den VS blockieren?

[Xmas]

Originally posted by X-Dragon
Aber vielleicht nochmal ganz kurz eine Erklärung dazu:
"Dafür kann bei einem TBDR das Binning den Vertexshader blockieren."

Wie kann das TBDR den VS blockieren?
Wenn man ein kurzes, simples VS-Programm nimmt, das relativ große Polygone verarbeitet dauert das Binning länger als die Verarbeitung im VS.
Denn große Polygone belegen viele Tiles, und zu jedem belegten Tile muss ein Verweis auf dieses Polygon in eine Liste geschrieben werden. Das kostet natürlich Zeit.
Und wenn das Binning mehr Zeit als das Transformieren der Eckpunkte benötigt, wird der VS eben blockiert.

[Demirug]

Originally posted by Xmas

Wenn man ein kurzes, simples VS-Programm nimmt, das relativ große Polygone verarbeitet dauert das Binning länger als die Verarbeitung im VS.
Denn große Polygone belegen viele Tiles, und zu jedem belegten Tile muss ein Verweis auf dieses Polygon in eine Liste geschrieben werden. Das kostet natürlich Zeit.
Und wenn das Binning mehr Zeit als das Transformieren der Eckpunkte benötigt, wird der VS eben blockiert.

Ja, genau

Ergänzend muss man noch sagen das es beim Binning von Zeit zu Zeit auch immer Aktionen gibt die länger dauern können. z.B.

-Wenn der ursprunglich für die Tile reservierte Speicherplatz nicht mehr reicht muss ein neues Segement belegt werden.

-Wenn in eine Tile zum ersten mal ein Dreiecksfragment mit einem neuen Renderstate (PS-Programm, Konstanten, ...) eingefügt werden soll müssen auch die veränderten Setting gespeichert werden.


Noch ergänzend zum unrsprünglichen Text. Ich habe dort geschrieben:
"Bandbreiteverbrauch für Z und Stencilbuffer entfallen beim TBDR natürlich komplett"

Das ist allerdings nur die halbe Wahrheit. Da gerade DR ja immer das Problem haben was sie tun sollen wenn der Binnig-Speicher nicht mehr reicht gibt es da die Lösung wenn der Speicher voll ist ein gut gefülltes Tile zu nehmen und schon mal zu rendern. Dann wird der Z und Stencil Buffer sowie die zusätzlichen AA-Sample Farbwerte an den Anfang der nun leeren Tile geschrieben. Kommt zu der Tile bis zum Ende des Frames noch was hinzu wird der Z und Stencilbuffer sowie die Farbwerte wieder eingeladen und die Tile zu ende gerendert. Falls nicht mehr dazu kommt müssen nur noch die Farbwerte downgesampelt werden. In diesem Fall ist das HSR natürlich nicht mehr zu 100% Perfekt und die PS müssen unter Umständen auch Pixel rendern die später noch verdeckt werden. Die Buffer welche an den Anfang der Tile gespeichert werden müssen kann man natürlich komprimieren.

[zeckensack]

Originally posted by Xmas

Wenn man ein kurzes, simples VS-Programm nimmt, das relativ große Polygone verarbeitet dauert das Binning länger als die Verarbeitung im VS.
Denn große Polygone belegen viele Tiles, und zu jedem belegten Tile muss ein Verweis auf dieses Polygon in eine Liste geschrieben werden. Das kostet natürlich Zeit.
Und wenn das Binning mehr Zeit als das Transformieren der Eckpunkte benötigt, wird der VS eben blockiert. Ist das nicht ein pathologischer Fall???
Soll heißen: Wenn die Dreiecke derart riesig sind, dann gibt es (hoffentlich) nicht besonders viele davon, und die maximale Geschwindigkeit zu verfehlen ist nicht mehr wirklich schlimm.

Onder anders herum, es würde sich kaum lohnen, extra für diese Fälle weitere Optimierungen zu suchen.

[Demirug]

Originally posted by zeckensack
Ist das nicht ein pathologischer Fall???
Soll heißen: Wenn die Dreiecke derart riesig sind, dann gibt es (hoffentlich) nicht besonders viele davon, und die maximale Geschwindigkeit zu verfehlen ist nicht mehr wirklich schlimm.

Onder anders herum, es würde sich kaum lohnen, extra für diese Fälle weitere Optimierungen zu suchen.

Ja, bei einem IMR hat man ja fast das gleiche Problem. Grosse Dreiecke bestehen aus mehr Pixel was dazu führt das das Trisetup ebenfalls länger zum zerlegen braucht. Dummerweise spielt dort aber dann auch noch die Länge des PS-Programms eine Rolle. So gesehen hat der TBDR hier schon einen Vorteil den IMRs mit Cache ausgleichen müssen. Dafür braucht ein TBDR an anderer Stelle wiederum mehr Cache-Speicher als ein IMR. Aber wie schon anderweitig gesagt Flaschenhälse bekommt man nicht wirklich weg sondern man verschiebt sie nur.

[Modulor @work]

Originally posted by zeckensack
...
Soll heißen: Wenn die Dreiecke derart riesig sind, dann gibt es (hoffentlich) nicht besonders viele davon, und die maximale Geschwindigkeit zu verfehlen ist nicht mehr wirklich schlimm.
Onder anders herum, es würde sich kaum lohnen, extra für diese Fälle weitere Optimierungen zu suchen.

Für solche Fälle hat PowerVR das Macro-Tiling Patent.Ein tile kann dann im Bedarfsfall z.B. 128x64 pixel groß sein statt 32x16. Das nachfolgende tile wiederum kann ebenfalls eine unabhängige Größe haben.

[loewe]

Originally posted by Demirug
so dann will ich mal :)

Zuerst muss man vorweg schicken das ein guter TBDR aus der gleichen grundmengen an Daten das gleiche Bild wie ein IMR zu erzeugen hat. Tut er das nicht ist er für den PC Markt nicht zu gebrauchen und kann nur in properitären Systemen (z.b. Konsolen) eingesetzt werden da dort die Programmierer ja auf die besonderheiten Rücksicht nemen können.

Die Frage ist also eigentlich nicht wie ein TBDR mit dynamischem Licht umgeht sonder wie es Hardwarerenderer allgemein tun.

Das ist zwar richtig, würde aber dazu führen das man grundsätzlich immer nur den kleinsten gemeinsamen Nenner verwenden kann, womit wir eigentlich immer noch keine DX8 Effekte sehen dürften.
Jede halbwegs brauchbare Engine verwendet heute auch entsprechende Codepfade für die gängige Hardware, aus dem Grunde arbeiten ja auch die Hardwarehersteller mit den Software Firmen zusammen.

Die einfache Antwort auf diese Frage ist:

Alle Licht und Schatten Effekte entstehen durch das Zusammenwirken von Vertex und Pixelshader sowie den davon getrenneten Teilen der Renderpipeline (z.b. Stencilbuffer).

Schauen wir und mal wieder DOOM III als Paradebeispiel für dynamisches Licht und Schatten an.

DOOM III arbeitet nach einen Lichtquelle für Lichtquelle Prinzip. Das heist jede Lichtquelle wird einzelen bearbeitet. Schauen wir uns nun einmal das Rendern einer solchen Lichtquelle an.

Da wir Licht und Schatten wollen sind auch zwei Schritte notwenig.

1. Ermitteln auf welche Pixel (bzw. AA-Sample) überhaupt Licht fällt. Das ganze wird mit Hilfe eines Schattenvolumen verfahrens gemacht. Dazu gibt es einiges im Internet zu finden. Kurz gesagt wird dabei für jedes von der Lichtquelle bestrahlten Objekts ein Schattenvolumen in den Stencilbuffer gerendert. Da Vorder und Rückseite unterschiedliche Aktionen im Stencilbuffer ausführen enthält der Stencilbuffer am Ende die Information wo Licht und wo Schatten ist. Für alle die nicht wissen was der Stencilbuffer ist. Es handelt sich dabei einfach um einen zusätzlich Speicher von ein paar Bits (üblicherweise 8) pro AA-Sample in welcher zusätzliche Informationen hinterlegt werden können. sowie in abhängigkeit von bestimmten Faktoren (z.b. Z-Test) einfache mathematische Operationen durchgeführt werden können (z.b. Aktuellerwert+1 oder Aktuellerwert-1)

In unserem Stencilbuffer ist also nun die Information gespeichert wo Licht und wo Schatten ist und wir können mit den nächsten Schritt weiter machen.

2. Jedes Objekt welches von der Lichtquelle bestrahlt wird muss nun gerendert werden. Für jeden Pixel der dabei entsteht wird nun mit dem Stencilbuffer geprüft ob dort überhaupt Licht sein darf. Falls nicht kann man sich den Rest schenken.

Für alle Pixel die den Stenciltest überleben muss nun die Farbe bestimmt werden. Dazu muss über den Vertex und Pixelshader eine mathematische Formel berechnet werden. Kurz gesagt berechnet Sich die Farbe eines beleuteten Pixel immer nach dem gleichen Grundprinzip.

a. Man bestimmt die Lichtmenge welche von der Lichtquelle ausgehend den Pixel erreicht. Dabei können Faktoren wie Entfernung, Richtung des Lichtvektors, die Lichtmenge die überhaupt von der Quelle augeht und vieles mehr eine Rolle Spielen.

b. Das zweite was nun bestimmt wird ist der Lichtanteil welcher von dem Pixel überhaupt reflektiert werden kann. Dabei können Dingen wie das Material, die räumliche Lage, der Auftreff-Winkel und noch so ein menge mehr eine Rolle spielen.

c. Das Produkt aus Lichtmenge die auftrifft und der Lichtmenge die refelktiert werden kann ergibt die Farbe die man dann zu sehen bekommt. Und damit das ganze auch schön Bunt wird macht man das für jeden Farbkanal (Rot, Grün und Blau) getrennt.

Jetzt haben wir eine Lichtquelle berechnet. Mit allen anderen machen wir das gleiche. Und bei allen Objekten die von mehr als einer Lichtquelle bestrahlt werden addiert man die Farbwerte von allen Lichtquellen einfach auf. Wenn man aber grundsätzlich den neuen Lichtwert zu dem im Framebuffer gespeicherten aktuellen addiert braucht man solche fälle gar nicht besonders zu betrachten. Dann man den Framebuffer am Anfang mit schwarz löscht besteht der Endwert im Falle von nur einer Lichtquelle eben aus Schwarz+Lichtwert und das ist nun mal das gleiche wie nur der Lichtwert weil sich schwarz bei einer addition neutral verhält.

Das Verfahren funktioniert bei einem TBDR genauso gut wie bei einem IMR.

Das kann man natürlich auf einem TBDR auch so machen, wird dort aber damit genauso uneffektiv wie auf den IMRs.

TBDRs können das aber auch ganz anders.

Es können die Schattenvolumen auch wie "feste Körper" behandelt werden, die eben nur durchsichtig sind und einen bestimmten Raum umschließen. Alles was sich innerhalb dieses Raumes befindet wird über eine einfache Blendingoperation im Erscheingsbild verändert, wobei alle oben angegebenen Effekte zum tragen kommen können. Ob ein Pixel sich innerhalb des Schattenvolumens befindet bestimmt die HSR-einheit nebenbei mit, da ja nur der Durchgang des Sehstrahls durch das Schattenvolumen, welches ja auch nur durch Dreiecke begrenzt wird, untersucht werden braucht. Entsprechende Flags für den Eintritt in das Volumen und den Austritt sind in der HSR-Einheit vorgesehen.

Wie gut das geht und welche Leistungsfähigkeit dabei erreicht werden kann zeigt recht gut der FabelMark von PowerVR. Hier werden massiv Stencilops für solche Beleuchtungseffekte verwendet, ich glaube es waren fünf Lichtquellen.

BTW, es müssen nicht nur Schatten sein die so berechnet werden können, jeder Effekt der auf spezielle Volumina zurück geführt werden kann ist so erzeugbar.

[loewe]

Originally posted by Modulor @work


Für solche Fälle hat PowerVR das Macro-Tiling Patent.Ein tile kann dann im Bedarfsfall z.B. 128x64 pixel groß sein statt 32x16. Das nachfolgende tile wiederum kann ebenfalls eine unabhängige Größe haben.

Ich denke da liegst du falsch!
Das Macro Tiling Patent löst die Probleme der Tiler mit zu vielen Polygonen, so dass der Speicherplatz für die Displayliste nicht reicht.

Aber der oben beschriebene Fall wäre sicher für einen TBDR nicht so gut, aber die vielen großen Dreiecke würden den Overdraw vergößern, womit die IMRs auch wieder ihre Probleme hätten.
Ich möchte da Zeckensack absolut zustimmen, dieser Fall sollte sehr selten sein.

[Demirug]

Originally posted by loewe

Das ist zwar richtig, würde aber dazu führen das man grundsätzlich immer nur den kleinsten gemeinsamen Nenner verwenden kann, womit wir eigentlich immer noch keine DX8 Effekte sehen dürften.
Jede halbwegs brauchbare Engine verwendet heute auch entsprechende Codepfade für die gängige Hardware, aus dem Grunde arbeiten ja auch die Hardwarehersteller mit den Software Firmen zusammen.

Du hast mich scheinbar falsch verstanden. Mir ging es darum das PC Chips API kompatibel sein müssen damit auch Spiele die Programmiert wurden bevor es den Chip gab damit laufen. Bei einer modernen DX-Engine baut man eigentlich keine Codepfade für unterschiedliche Chips mehr ein. Bei OpenGL geht es aufgrund der Extensions nicht anders. Man benutzt projektierbare Effekte welche den gleiche Effekt mit unterschiedlichen Technologie-Level und optischer Qualtät darstellt. Man kann aber duchaus für einen Effekt auch eine Spezialversion für einen speziellen Chip zu verfügung haben aber eine Basis Variante die zum Beispiel mit allen DX8 Karten läuft sollte man auch haben. Sonst hat man das Problem das es nicht auf allen Karten läuft und das ist sehr schlecht.

Das kann man natürlich auf einem TBDR auch so machen, wird dort aber damit genauso uneffektiv wie auf den IMRs.

TBDRs können das aber auch ganz anders.

Es können die Schattenvolumen auch wie "feste Körper" behandelt werden, die eben nur durchsichtig sind und einen bestimmten Raum umschließen. Alles was sich innerhalb dieses Raumes befindet wird über eine einfache Blendingoperation im Erscheingsbild verändert, wobei alle oben angegebenen Effekte zum tragen kommen können. Ob ein Pixel sich innerhalb des Schattenvolumens befindet bestimmt die HSR-einheit nebenbei mit, da ja nur der Durchgang des Sehstrahls durch das Schattenvolumen, welches ja auch nur durch Dreiecke begrenzt wird, untersucht werden braucht. Entsprechende Flags für den Eintritt in das Volumen und den Austritt sind in der HSR-Einheit vorgesehen.

Wie gut das geht und welche Leistungsfähigkeit dabei erreicht werden kann zeigt recht gut der FabelMark von PowerVR. Hier werden massiv Stencilops für solche Beleuchtungseffekte verwendet, ich glaube es waren fünf Lichtquellen.

BTW, es müssen nicht nur Schatten sein die so berechnet werden können, jeder Effekt der auf spezielle Volumina zurück geführt werden kann ist so erzeugbar.

Du weist aber schon das der FabelMark genau mit dem von mir beschriebenen Verfahren arbeitet. Nur das Lichtmodel ist einfach damit die Stencilops einen grösseren Gesamtanteil an der Szene bekommen. Das führt dazu das die IMR dabei sehr schlecht aussehen. Kyros können nun mal sehr viele Stencilops pro Takt ausführen:D

Und hört bitte auf bei einem TBDR von einem Sehstrahl zu sprechen. Die Chips sind immer noch renderchips und keine Raytracerchips. Ich weiss das es mal ein Dokument gab (oder sogar nicht gibt) in dem sowas in der Art beschrieben wurde. Das Problem dabei ist nur das es schlicht und ergreifend eine Fehlinformation ist.

Ein Kyro-Chip arbeitet nach dem gleichen Z-Buffer Prinzip wie ein IMR. Der Unterschied dabei ist nur das der Z/Stencil-Buffer komplett im Chip liegt und die Pixel erst dann wirklich gerendert werden wenn alle Dreiecke des Frames von einer Tile durch die HSR-Einheit gelaufen sind.

[loewe]

Originally posted by Demirug
Du hast mich scheinbar falsch verstanden. Mir ging es darum das PC Chips API kompatibel sein müssen damit auch Spiele die Programmiert wurden bevor es den Chip gab damit laufen. Bei einer modernen DX-Engine baut man eigentlich keine Codepfade für unterschiedliche Chips mehr ein. Bei OpenGL geht es aufgrund der Extensions nicht anders. Man benutzt projektierbare Effekte welche den gleiche Effekt mit unterschiedlichen Technologie-Level und optischer Qualtät darstellt. Man kann aber duchaus für einen Effekt auch eine Spezialversion für einen speziellen Chip zu verfügung haben aber eine Basis Variante die zum Beispiel mit allen DX8 Karten läuft sollte man auch haben. Sonst hat man das Problem das es nicht auf allen Karten läuft und das ist sehr schlecht.

Da gehe ich sofort mit. Was ich jetzt nicht beurteilen kann, ist es möglich das von dir beschriebene Standardverfahren durch Treiber auf das von PowerVR sicher zu bevorzugende mit den special Volumes um zu lenken.

Und hört bitte auf bei einem TBDR von einem Sehstrahl zu sprechen. Die Chips sind immer noch renderchips und keine Raytracerchips. Ich weiss das es mal ein Dokument gab (oder sogar nicht gibt) in dem sowas in der Art beschrieben wurde. Das Problem dabei ist nur das es schlicht und ergreifend eine Fehlinformation ist.

Ein Kyro-Chip arbeitet nach dem gleichen Z-Buffer Prinzip wie ein IMR. Der Unterschied dabei ist nur das der Z/Stencil-Buffer komplett im Chip liegt und die Pixel erst dann wirklich gerendert werden wenn alle Dreiecke des Frames von einer Tile durch die HSR-Einheit gelaufen sind.
Das sollte hier jedem klar sein, ich habe auch bewusst ein Wort wie Raytracing nicht verwendet! :)
Aber die Vorgänge in der HSR Einheit lassen sich nun mal am einfachsten mit solchen Begriffen beschreiben, dort wird nun mal entlang einer Scanlinie durch jedes Pixel untersucht und diese entspricht einem Sehstrahl.

[Demirug]

Originally posted by loewe

Da gehe ich sofort mit. Was ich jetzt nicht beurteilen kann, ist es möglich das von dir beschriebene Standardverfahren durch Treiber auf das von PowerVR sicher zu bevorzugende mit den special Volumes um zu lenken.

Das sollte hier jedem klar sein, ich habe auch bewusst ein Wort wie Raytracing nicht verwendet! :)
Aber die Vorgänge in der HSR Einheit lassen sich nun mal am einfachsten mit solchen Begriffen beschreiben, dort wird nun mal entlang einer Scanlinie durch jedes Pixel untersucht und diese entspricht einem Sehstrahl.

Die Special Volumen die du hier beschreibst bringen bei Shattenvolumen überhaupt nichts. Die Technik macht Sinn wenn man irgendwo im Raum zum Beispiel ein Nebelvolumen braucht. Dafür gibt es aber auch Verfahren welche auf IMR und TBDR laufen und im vergleich zu den "Special Volumen" nicht schlechter abschneiden sollten. Ist die "Special Volumen" Technik in den Kyros überhaupt noch verfügbar?

Ich weiss schon warum ich den Begriff Sehstrahl in dem Zusammenhang nicht mag. Bei diesem Erklärungsversuch gehen die meisten Leute davon aus das der Chip pro Pixel einen Sehstrahl erzeugt und dann in allen Dreiecken in der Tile das sucht welches am dichtesten an der vorderen Clipplane liegt. Ein solches Verfahren wäre schon machbar aber ineffektiv und zu einem IMR nicht kompatibel.

[loewe]

Originally posted by Demirug
Bei diesem Erklärungsversuch gehen die meisten Leute davon aus das der Chip pro Pixel einen Sehstrahl erzeugt und dann in allen Dreiecken in der Tile das sucht welches am dichtesten an der vorderen Clipplane liegt. Ein solches Verfahren wäre schon machbar aber ineffektiv und zu einem IMR nicht kompatibel.

???
Aber ziemlich genau das tut die HSR Einheit!
Was ist daran ineffektiv und nicht zu IMR kompatibel, ich halte PowerVR für sehr effektiv und ebenso für absolut kompatibel.

[Demirug]

Ich glaube hier liegt ein Missverständniss vor.

Das "Sehstrahlverfahren" welches ich hier meine ist das bei dem der Chip für jeden Pixel alle Dreiecke der Tile nach dem Z-Werte sortiert. Und dann jeweils von Start der Liste das erste Dreieck ohne Alpha-Bleding sucht und von dem Dreieck aufsteigend rendert.

Es wurde in einem Paper im Internet mal behauptet das PowerVR Chips so arbeiten würden. Das kann aber nicht sein.

So ist zum Beispiel das Sortieren eine Operation die nicht linear mit der Anzahl der Dreiecke skaliert. Die Kyros tun dies aber. Sortieren währe also reichlich inefftiv

Beim Sortieren ginge die ursprüngliche Render-Rheienfolge der Dreiecke verloren. Da die Rheienfolge aber beim rendern auswirkungen auf das Endprodukt hat würde jede aktion welche die Rheienfolge zerstört inkompatibel sein. Und das sind die Kyros ja nicht.

Im Prinzip ist auch ein Kyrochip ein normaler Renderchip welcher lediglich zwei Verzögerungsstufen hat.

1. Es wird die gesamte Szene im Speicher zin Form von Tiles zwischengespeichert. Dadurch wird es möglich die Bandbreite und den Speicher für den Z/Stencil und Backbuffer zu sparen.
2. Beim Rendern wird das ausführen der Pixeloperationen so lange verzögert bis alle Dreiecke einer Tile abgearbeit sind. Dadurch wird Fillrate und Bandbreite für Texturzugriffe gespart.

Im Prinzip unterscheidet sich das rendern einer Tile erst mal gar nicht so stark von dem Vorgang in einem IMR. Jedes Dreieck wird in Zeilen und Pixel zerlegt (wenn das bei PowerVR auch äusert Trickreich geht). Für jeden Pixel wird (falls nötig) der Z-Test durchgeführt. Stenciltests und operationen werden ausgeführt. Kommt der Chip nun zu der Erkenntniss das der Pixel gerendert werden müsste (er könnte aber durch ein nachfolgendes Dreieck durchaus noch verdeckt werden) so übergibt er den Pixel nicht einer Pixelpipline sondern schreibt in den Interen Framebuffer einen Verweiss auf die für diesen Pixel notwendingen Rendersettings und die restlichen Daten die später zum Rendern gebraucht werden. Steht im Framebuffer bereits ein Datenblock so muss in abhängigkeit der Rendersettings entscheiden werden was damit passieren soll. Es gibt aber primär nur zwei optionen Überschreiben oder Zwischenspeichern. Sind nun alle Dreiecke durch werden die im "Framebuffer" gespeicherten Informationen benutzt um die entgültige Pixelfarbe zu bestimmen.

[Labberlippe]

Hi

Ich sage vorerst mal ein grosses Dankeschön für diesen super Thread.
Ich hätte noch einige Fragen die ich aber später stellen werde.

Thx im vorruas.

Gruss Labberlippe

[loewe]

Originally posted by Demirug
Ich glaube hier liegt ein Missverständniss vor.

Na dann ist ja gut, ich fing schon an zu Zweifeln. Nicht an mir! :)

Das "Sehstrahlverfahren" welches ich hier meine ist das bei dem der Chip für jeden Pixel alle Dreiecke der Tile nach dem Z-Werte sortiert. Und dann jeweils von Start der Liste das erste Dreieck ohne Alpha-Bleding sucht und von dem Dreieck aufsteigend rendert.
Es wurde in einem Paper im Internet mal behauptet das PowerVR Chips so arbeiten würden. Das kann aber nicht sein.

Ich kenne diese Grüchte, es waren aber immer nur Gerüchte und diese sind durch uns, die Hand voll PowerVR "nahen" Seiten auch nie verbreitet worden.

So ist zum Beispiel das Sortieren eine Operation die nicht linear mit der Anzahl der Dreiecke skaliert. Die Kyros tun dies aber. Sortieren währe also reichlich inefftiv

Naja nicht ganz, CountingSort ist O(n) und damit linear, aber eben nur für ganze Zalen. ;)

Beim Sortieren ginge die ursprüngliche Render-Rheienfolge der Dreiecke verloren. Da die Rheienfolge aber beim rendern auswirkungen auf das Endprodukt hat würde jede aktion welche die Rheienfolge zerstört inkompatibel sein. Und das sind die Kyros ja nicht.

Im Prinzip ist auch ein Kyrochip ein normaler Renderchip welcher lediglich zwei Verzögerungsstufen hat.

zustimm

1. Es wird die gesamte Szene im Speicher zin Form von Tiles zwischengespeichert. Dadurch wird es möglich die Bandbreite und den Speicher für den Z/Stencil und Backbuffer zu sparen.
2. Beim Rendern wird das ausführen der Pixeloperationen so lange verzögert bis alle Dreiecke einer Tile abgearbeit sind. Dadurch wird Fillrate und Bandbreite für Texturzugriffe gespart.

Im Prinzip unterscheidet sich das rendern einer Tile erst mal gar nicht so stark von dem Vorgang in einem IMR. Jedes Dreieck wird in Zeilen und Pixel zerlegt (wenn das bei PowerVR auch äusert Trickreich geht). Für jeden Pixel wird (falls nötig) der Z-Test durchgeführt.
Stenciltests und operationen werden ausgeführt. Kommt der Chip nun zu der Erkenntniss das der Pixel gerendert werden müsste (er könnte aber durch ein nachfolgendes Dreieck durchaus noch verdeckt werden) so übergibt er den Pixel nicht einer Pixelpipline sondern schreibt in den Interen Framebuffer einen Verweiss auf die für diesen Pixel notwendingen Rendersettings und die restlichen Daten die später zum Rendern gebraucht werden. Steht im Framebuffer bereits ein Datenblock so muss in abhängigkeit der Rendersettings entscheiden werden was damit passieren soll. Es gibt aber primär nur zwei optionen Überschreiben oder Zwischenspeichern. Sind nun alle Dreiecke durch werden die im "Framebuffer" gespeicherten Informationen benutzt um die entgültige Pixelfarbe zu bestimmen.

Nein, so eine Zerlegung in Zeilen und Pixel erfolgt nicht.
Die HSR Einheit geht da doch gänzlich anders vor.
Es wird jedes Dreieck in vier Ebenen umgewandelt. Eine Ebene ist die Ebene in der das Dreieck selbst liegt, die anderen drei Ebenen werden aus den Dreieckskanten und als jeweils drittem Punkt ein Punkt des "Sehstrahls", wahrscheinlich das "virtuelle Auge", gebildet. Aus den Schnitten der Geraden durch "virtuelles Auge" und Pixel mit diesen vier Ebenen wird die Sichtbarkeit des Dreiecks für diesen Pixel gefolgert und gleichzeit der z-Wert bestimmt. Ist das Dreieck undurchsichtig wird der z-Wert gespeichert, ist es durhcsichtig werden die notwendigen Informationen in einer Liste gespeichert, je eine Liste je Pixel und natürlich alles in einem Cache im Chip.
Dabei wird jedes Dreieck für eine Tile genau einmal aufgerufen und dann vollständig für alle Pixel abgearbeitet.

Wenn alle Dreiecke durch sind ist die Tile fertig was den Tiefentest anbelangt und alle für das Texturing notwendigen Infos stehen für jeden Pixel bereit.

[Demirug]

Originally posted by loewe

Naja nicht ganz, CountingSort ist O(n) und damit linear, aber eben nur für ganze Zalen. ;)

ja, und bei einem grossen möglichen Zahlen-Bereich ist Countingsort der reinste Speicherfresser. Mit 24 Bit Z-Werte kaum zu machen deswegen habe ich Countingsort mal grosszügig unterschlagen ;)

Nein, so eine Zerlegung in Zeilen und Pixel erfolgt nicht.
Die HSR Einheit geht da doch gänzlich anders vor.
Es wird jedes Dreieck in vier Ebenen umgewandelt. Eine Ebene ist die Ebene in der das Dreieck selbst liegt, die anderen drei Ebenen werden aus den Dreieckskanten und als jeweils drittem Punkt ein Punkt des "Sehstrahls", wahrscheinlich das "virtuelle Auge", gebildet. Aus den Schnitten der Geraden durch "virtuelles Auge" und Pixel mit diesen vier Ebenen wird die Sichtbarkeit des Dreiecks für diesen Pixel gefolgert und gleichzeit der z-Wert bestimmt.

Zerlegt wird die gespeicherte Infinite Plane schon. Da nur genügend HSR-Zellen für jeweils eine Zeile zur Verfügung stehen muss erst einmal nach Zeilen zerlegt werden. Deswegen braucht man auch pro Dreieck 16 Takte um die 16 Zeilen abzuarbeiten. Das Zerlegen in Pixel geschieht ja automatisch beim durchschieben der Dreiecken durch die HSR-Zellen.

Das mit der Z-Plane ist klar. Darauf bassiert ja das HSR-Prinzip von PoverVR. Was mich aber jetzt doch etwas verwundert sind die 3 anderen Planes. Ist das eine von PowerVR bestätigte Information (Patente, Interviews)? Weil eigentlich geht das viel einfacher. Alles was man braucht ist der u und v Wert von 2 Kanten den Dreiecks. In dem Punkt indem die beiden Kanten zusammentreffen sind u und v jeweils 0 am anderen End-Punkt 1. Solange u+v >= 0 und <= 1 ist befindet sich der Pixel innerhalb des Dreiecks. Das schöne dabei ist das genau wie bei der z-Plane die beiden DeltaZ-Werte (Spalte und Zeile) auch bei der u und v plane die Deltas für ein Dreieck Konstant sind.

Ist das Dreieck undurchsichtig wird der z-Wert gespeichert, ist es durhcsichtig werden die notwendigen Informationen in einer Liste gespeichert, je eine Liste je Pixel und natürlich alles in einem Cache im Chip.

Ob der Z-Wert geispeichert wird oder nicht hängt weniger von der Transparenz sondern eher von den Rendersetting bezüglich des Z-Buffers ab. Es stimmt aber schon das diese Settings in der Regel mit der Transparenz in verbidnung stehen.

Dabei wird jedes Dreieck für eine Tile genau einmal aufgerufen und dann vollständig für alle Pixel abgearbeitet.

Eigentlich muss wie gesagt jedes Dreieck einmal pro Zeile aufgerufen werden. Da die Datenmenge für die HSR-Einheit pro Dreieck aber nicht sonderlich gross ist sollten alle Dreiecke einer Tile in den cache passen.

Wenn alle Dreiecke durch sind ist die Tile fertig was den Tiefentest anbelangt und alle für das Texturing notwendigen Infos stehen für jeden Pixel bereit.

Das war ja auch der Sinn der Übung ;)

[Xmas]

Originally posted by Demirug
Eigentlich muss wie gesagt jedes Dreieck einmal pro Zeile aufgerufen werden. Da die Datenmenge für die HSR-Einheit pro Dreieck aber nicht sonderlich gross ist sollten alle Dreiecke einer Tile in den cache passen.
Wieso sollte man die Infinite Plane-Daten cachen? Einmal holen, 16 Zeilen durchlaufen, fertig. Beim Texturieren werden diese Daten nicht mehr benötigt.

[Demirug]

Originally posted by Xmas

Wieso sollte man die Infinite Plane-Daten cachen? Einmal holen, 16 Zeilen durchlaufen, fertig. Beim Texturieren werden diese Daten nicht mehr benötigt.

Beim Texturieren braucht man sie natürlich nicht mehr.

Die Frage bei der der ich mir aber auch nicht ganz sicher bin ist. Wie werden die 16 Zeilen durchlaufen?

Es gibt da ja zwei Alternativen:

1. Für jedes Dreieck jede Zeile.

2. Für jede Zeile jedes Dreieck.

Beide Verfahren haben da so ihere Vor und Nachteile. Bei Verfahren 2 müsste man die Dreiecke (planes) zwischenspeichern da sie ja alle 16 mal gebraucht werden. Bei Verfahren 1 müsste man die 16 Zeilen speichern und bräuchte eine etwas kompliziertet Logik in den HSR-Zellen. Ich bin da aber echt unentschlossen was nun besser ist.

[loewe]

Originally posted by Demirug
Zerlegt wird die gespeicherte Infinite Plane schon. Da nur genügend HSR-Zellen für jeweils eine Zeile zur Verfügung stehen muss erst einmal nach Zeilen zerlegt werden. Deswegen braucht man auch pro Dreieck 16 Takte um die 16 Zeilen abzuarbeiten. Das Zerlegen in Pixel geschieht ja automatisch beim durchschieben der Dreiecken durch die HSR-Zellen.

Naja, wenn du es so sehen willst. Von der Sache her ist das aber egal, ob ich nun nur eine HSR-Zelle habe oder eben auch 512 um die Tile komplett parallel zu bearbeiten. Das Dreieck wird aufgerufen, in die vier infinte planes "umgewandelt" und nun geht man die Pixel spalten und zeilenweise durch, erzeugt die entsprechende Gerade für den Sehstrahl, überprüft die Sichtbarkeit und bestimmt daraus den z-Wert und wenn notwendig die Liste der durchsichtigen Dreiecke.

Das mit der Z-Plane ist klar. Darauf bassiert ja das HSR-Prinzip von PoverVR. Was mich aber jetzt doch etwas verwundert sind die 3 anderen Planes. Ist das eine von PowerVR bestätigte Information (Patente, Interviews)? Weil eigentlich geht das viel einfacher. Alles was man braucht ist der u und v Wert von 2 Kanten den Dreiecks. In dem Punkt indem die beiden Kanten zusammentreffen sind u und v jeweils 0 am anderen End-Punkt 1. Solange u+v >= 0 und <= 1 ist befindet sich der Pixel innerhalb des Dreiecks. Das schöne dabei ist das genau wie bei der z-Plane die beiden DeltaZ-Werte (Spalte und Zeile) auch bei der u und v plane die Deltas für ein Dreieck Konstant sind.

Ja das Verfahren ist so bestätigt, sie sagen es scheint aufwendig, die für die Kanten sind aber sehr einfach zu erzeugen und zu berechnen, das lohnt schon.

Eigentlich muss wie gesagt jedes Dreieck einmal pro Zeile aufgerufen werden. Da die Datenmenge für die HSR-Einheit pro Dreieck aber nicht sonderlich gross ist sollten alle Dreiecke einer Tile in den cache passen.

Die HSR Einheit holt nur die Eckpunktkoordinaten und gibt nur je Pixel einen Pointer auf das undurchsichtige Dreieck und eben die Liste mit den Pointern auf die durchsichtigen Dreiecke zurück. Falls notwendig kann der z-Buffer aber ausgelagert werden.

[loewe]

Originally posted by Demirug
Es gibt da ja zwei Alternativen:

1. Für jedes Dreieck jede Zeile.

2. Für jede Zeile jedes Dreieck.

Beide Verfahren haben da so ihere Vor und Nachteile. Bei Verfahren 2 müsste man die Dreiecke (planes) zwischenspeichern da sie ja alle 16 mal gebraucht werden. Bei Verfahren 1 müsste man die 16 Zeilen speichern und bräuchte eine etwas kompliziertet Logik in den HSR-Zellen. Ich bin da aber echt unentschlossen was nun besser ist.

Definitiv:

for i:=1 to n do
begin
use Dreieck[i];
for z:=1 to 16 do
bearbeite Zeile[z]
end;

Aber das ist eindeutig KYRO, für andere Serien sieht das etwas anders aus!

[ActionNews]

Da habe ich noch eine Frage zu den Stencilops und DoomIII.
Ich erinnere mich an einen Beitrag von Kristof Beets im Beyond3d-Forum in dem er meinte, dass der FableMark, das gleiche Prinzip für die Schattenberechnung benutzt wie DoomIII. Gerade DoomIII wäre der Anlass für PowerVR gewesen den FableMark zu programmieren. Ein Vorteil der Stencilops bei PowerVR ist doch, dass diese on Chip gespeichert/bearbeitet werden, oder nicht?

Und noch mal DoomIII: Soweit ich weiß wird bei DoomIII ja in einem 2 Pass Verfahren gerendert. Erst ein Pass nur für die Z-Werte um den Overdraw zu eleminieren und dann im zweiten Pass erst die Texturen usw.! Aber wenn ich jetzt zwei Passes habe braucht das doch auch mehr Zeit, als bei einem TBDR, der dass in einem Pass erledigen kann, oder nicht? Wäre da nicht ein extra Rendering-Pfad für PowerVR-Chips sinnvoll, bei dem alles in einem Rutsch erledigt wird?

CU ActionNews

[Demirug]

Originally posted by ActionNews
Da habe ich noch eine Frage zu den Stencilops und DoomIII.
Ich erinnere mich an einen Beitrag von Kristof Beets im Beyond3d-Forum in dem er meinte, dass der FableMark, das gleiche Prinzip für die Schattenberechnung benutzt wie DoomIII. Gerade DoomII wäre der Anlass für PowerVR gewesen den FableMark zu programmieren. Ein Vorteil der Stencilops bei PowerVR ist doch, dass diese on Chip gespeichert/bearbeitet werden, oder nicht?

Vorteil 1: Der Stencil buffer befindet sich wie der Z-Buffer im Chip.

Vortiel 2: Stencilops werden bei den IMR Chips in den AA-Samplern durchgeführt. Das heisst maximal so viele Ops wie Pipelines pro Takt. Die KYRO-Chips können AFAIK in jeder HSR-Zelle eine Stencilop pro Takt ausführen. Da man beim FableMark sehr viele Stencilops im verhältniss zu "normalen" Renderops benutzt sehen die Kyros da auch so gut aus.

Und noch mal DoomIII: Soweit ich weiß wird bei DoomIII ja in einem 2 Pass Verfahren gerendert. erst ein Pass nur für die Z-Werte um den Overdraw zu eleminieren und dann im zweiten Pass erst die Texturen usw.! Aber wenn ich jetzt zwei Passes habe braucht das doch auch mehr Zeit, als bei einem TBDR, der dass in einem Pass erledigen kann, oder nicht? Wäre da nicht ein extra Rendering-Pfad für PowerVR-Chips sinnvoll, bei dem alles in einem Rutsch erledigt wird?

CU ActionNews

Der Z-Pass ist primär nicht dazu da den Overdraw zu elimieren. Das ist nur ein nebeneffekt. Der Z-Pass wird gebraucht damit die Schattenberechnung funktioniert. Auch bei einem TBDR kann deshalb nicht auf den Z-Pass verzichtet werden.

Meinst du jetzt einen Pfad für Kyros oder für Serie5. Für die Kyros und DOOM III sehe ich eigentlich nicht so viel Licht am Ende des Tunnels. Da fehlen einfach die Cubemaps. Mal schauen ob JC noch was spezielles für die Kyros einbaut oder man sich mit dem Default OpenGL Pfad begnügen muss.