S3 DeltaChrome Advanced Deferred Rendering

[Demirug]

S3 hat heimlich (schon vor einiger Zeit) die webseite aktualisiert.

Unter anderem ist dort jetzt auch folgedes zu lesen:

Deferred Rendering with a Two-Pass Rendering Scheme
DeltaChrome renderings from the Z-buffer can occur in either Single-Pass or Two-Pass schemes. The Single Pass scheme is most effective with applications where polygons are drawn front-to-back. and allows "back" polygons to be removed early in the pipeline.

DeltaChrome's Two Pass Advanced Deferred Rendering scheme significantly reduces the bandwidth required to write to the destination and Z-buffers. During Pass One evaluation of depth complexity occurs, but no pixels are actually rendered to the destination or Z-buffers. During Pass Two final processing to the destination and Z-buffers is optimized to occur with minimal reads.

Greater Performance by avoiding redundant Overdraws
Deferred Two-Pass rendering virtually eliminates opaque (redundant) back-to-front overdraw and saves precious conventional Z-write traffic.

http://www.s3graphics.com/DeltaChromeADR.html

Es scheint sich also nicht um eine reine Treibersache zu handeln.

Denkbar wäre es IMO das man in diesem Ersten Pass nur einen Teil des den Hir-Z buffer mit Werten füllt und deswegen auch nicht bis auf Pixelebene rasterisert was Pixelfillrate sparen sollte.

PS: Auf einer anderen Seite findet man übrigens noch das

Trilinear-filtered fill rate of 2.4 Giga-pixels per second
http://www.s3graphics.com/DeltaChromeV8.html

Also 8 Pipelines mit 300 Mhz und Tri-TMUs.

[mapel110]

hm, is das nun nen tiler wie die powervr series oder nit ?!

wenn nein, wo liegen dann noch unterschiede ?

[Demirug]

Ein TBDR nach dem PowerVR verfahren ist das nun bestimmt nicht.

Die Unterschiede im Detail lassen sich aber schwer aus diesen paar Sätzen ableiten.

[ActionNews]

Original geschrieben von mapel110
hm, is das nun nen tiler wie die powervr series oder nit ?!

wenn nein, wo liegen dann noch unterschiede ?

Nene...ist total verschieden.

Das was der DeltaCrome da zu machen scheint. Soll auch Doom3 in Software ausführen.
Dazu werden zwei "render"-passes pro Bild gebraucht. Im ersten werden nur Z-Werte berechnet und keine Pixel und dann im Zweiten Pass nur noch die Pixel, die sichtbar sind (bestimmt durch den vorherigen "Z-Pass").

Ein TBDR geht anders vor: Er speichert alle Notwendigen Daten über Das Bild in einer "Display-List", teilt das Bild dann in viele kleine Kacheln (Tiles) um die Tiles Bequem mit Hilfe von Caches bearbeiten zu können und verwirft alle nicht sichtbaren Dreiecke und Pixel. Im Unterschied zum DeltaCrome aber alles in einem einzigen Pass.

Dadurch, dass ein TBDR sehr viel mit Caches arbeiten kann und in einem pass rendert dürfte die Methode des DeltaCrome nicht so effektiv sein. Der Delta Crome ist im Grunde genommen immer noch ein reiner IMR. Das "Two Pass Advanced Deferred Rendering scheme" des DeltaCrome dürfte aber doch ein paar Vorteile bringen.

CU ActionNews

[Demirug]

ActionNews, angeblich berechnet der DeltaChrome ja gerade nicht während des ersten Pass den Z-Buffer sonder führt nur eine Analyse der Tiefen Komplexität durch und nutzt diese Information um dann im zweiten Pass die benötigte Bandbreite zu reduzieren in der er verdeckte Teile aussortiert. Also irgendwas spezielles muss da schon noch in der Hardware sein. Aber das ganze ist ja noch sehr undeutlich.

[robbitop]

ist der Delta Chrome also ein sogenannter First Z Pass Renderer??

und wie ist dieser Chip nun angesetzt? ich dachte, dass er eher Low Cost wird. Aber 2,4GPixel Trilinear WOW...

[Demirug]

Original geschrieben von robbitop
ist der Delta Chrome also ein sogenannter First Z Pass Renderer??

IMHO eine Abart davon weil er ja im ersten Pass den Z-Buffer nicht komplett beschreibt.

und wie ist dieser Chip nun angesetzt? ich dachte, dass er eher Low Cost wird. Aber 2,4GPixel Trilinear WOW...

Der 2,4 GPixel Chip ist die Highend Variante F1 daneben soll es noch einen S8 und einen S4 geben.

[ActionNews]

Original geschrieben von Demirug
ActionNews, angeblich berechnet der DeltaChrome ja gerade nicht während des ersten Pass den Z-Buffer sonder führt nur eine Analyse der Tiefen Komplexität durch und nutzt diese Information um dann im zweiten Pass die benötigte Bandbreite zu reduzieren in der er verdeckte Teile aussortiert. Also irgendwas spezielles muss da schon noch in der Hardware sein. Aber das ganze ist ja noch sehr undeutlich.
Ach so.... ah ja...hast Recht. Hab ich leider überlesen :(!

CU ActionNews

[Ailuros]

Original geschrieben von Demirug
Ein TBDR nach dem PowerVR verfahren ist das nun bestimmt nicht.

Die Unterschiede im Detail lassen sich aber schwer aus diesen paar Sätzen ableiten.

Da es sich um "application driven DR" handelt, haengt es wohl von der Applikation ab.

Angenommen es wird moeglich sein Doom3 in single pass auf einem TBDR laufen zu lassen, wurde dann DeltaChrome nicht mehr Bandbreite fuer Z writes/reads verbruzeln und ein TBDR immer noch den Vorsprung der ungeteilten Stencil Fuellrate theoretisch haben? (zur Korrigierung offen natuerlich).

[Demirug]

Original geschrieben von Ailuros
Da es sich um "application driven DR" handelt, haengt es wohl von der Applikation ab.

Ailuros, aufgrund der Beschreibung auf der Seite kann es kein reines "application driven DR" sein. Diese "tiefen Komplexitäts Analyse" lässt sich ohne zusätzliche Hardware nicht machen.

Angenommen es wird moeglich sein Doom3 in single pass auf einem TBDR laufen zu lassen, wurde dann DeltaChrome nicht mehr Bandbreite fuer Z writes/reads verbruzeln und ein TBDR immer noch den Vorsprung der ungeteilten Stencil Fuellrate theoretisch haben? (zur Korrigierung offen natuerlich).

Der Z-Pass Bei Doom hat primär nicht die Aufgabe durch Ausnutzung der Early-Z Möglichkeiten eines Chips fillrate und Bandbreite zu sparen sondern ist einfach notwendig wegen der Stencilschatten.

DOOM III + TBDR + Single Pass = Geht einfach nicht.

Angeblich braucht der Deltachrome ja für den 1. Pass keine Bandbreite für den Z-Buffer weil er diesen gar nicht benutzt. Frag mich aber jetzt bitte nicht wie das genau geht denn da habe ich derzeit noch keine Ahnung.

Den Vorteil der hohen Stencilfillrate wird man dem TBDR nur schwer nehmen können. wenn nv auch mit UltraShadow daran arbeitet den Bedarf an Stencilfillrate zu senken.

[Ailuros]

Ailuros, aufgrund der Beschreibung auf der Seite kann es kein reines "application driven DR" sein. Diese "tiefen Komplexitäts Analyse" lässt sich ohne zusätzliche Hardware nicht machen.

Komischerweise hab ich application driven DR etwa so verstanden, denn SA bei B3D hat es mehr als oefters erwaehnt und auch teilweise erklaert (an unshaded pass immediately followed by a shaded pass); irgendwie hab ich auch dass Gefuehl dass S3 damit mehr auf Doom3 rendering zielt als auf jegliches andere, da die stencil ops ja back to front gerendert werden und der Overdraw extrem hoch sein muesste.

Meine Logik mit dem Namen application driven kommt daher dass wenn die Hartware erkennt dass back to front gerendert wird, dass das Feature dann automatisch eingeschaltet wird, ergo multipass anstatt von single pass rendering. Ich hatte dabei keine einfache software Optimierung im Sinn und natuerlich zweifle ich nicht daran dass ohne sowas ohne die notwendige Hartwaren-Unterstuetzung gar nicht moeglich ist.

Klingt es so besser oder hab ich mich schon wieder vertueftelt?

DOOM III + TBDR + Single Pass = Geht einfach nicht.

Liegt es an der Art und Weise wie das Spiel entwickelt wurde, oder gibt es irgend einen anderen Grund der mir fremd ist? Wenn (a) dann haben Tilers mal wieder Pech :D

Angeblich braucht der Deltachrome ja für den 1. Pass keine Bandbreite für den Z-Buffer weil er diesen gar nicht benutzt. Frag mich aber jetzt bitte nicht wie das genau geht denn da habe ich derzeit noch keine Ahnung.

Mist. Jetzt hat schon wieder jemand meine Gedanken gelesen :(

:P

[Demirug]

Original geschrieben von Ailuros
Komischerweise hab ich application driven DR etwa so verstanden, denn SA bei B3D hat es mehr als oefters erwaehnt und auch teilweise erklaert (an unshaded pass immediately followed by a shaded pass); irgendwie hab ich auch dass Gefuehl dass S3 damit mehr auf Doom3 rendering zielt als auf jegliches andere, da die stencil ops ja back to front gerendert werden und der Overdraw extrem hoch sein muesste.

Meine Logik mit dem Namen application driven kommt daher dass wenn die Hartware erkennt dass back to front gerendert wird, dass das Feature dann automatisch eingeschaltet wird, ergo multipass anstatt von single pass rendering. Ich hatte dabei keine einfache software Optimierung im Sinn und natuerlich zweifle ich nicht daran dass ohne sowas ohne die notwendige Hartwaren-Unterstuetzung gar nicht moeglich ist.

Klingt es so besser oder hab ich mich schon wieder vertueftelt?

OK wenn du "application driven" so definierst passt es schon. Ich würde es eher "Context abhängiges DR" nennen. Bleibt nur noch die Frage in wie weit der Chip überhaupt in der Lage ist zu erkennen wann welches Verfahren besser ist. Oder ob diese Auswahl dann Teil einer Applikationsspezifischen Optimierungsstrategie ist.

Liegt es an der Art und Weise wie das Spiel entwickelt wurde, oder gibt es irgend einen anderen Grund der mir fremd ist? Wenn (a) dann haben Tilers mal wieder Pech :D

Es liegt daran das zum rendern des Stencilbuffers für die Schatten der Z-Buffer bereits vollständig vorliegen muss. Bei der reinen Pixel/Texelfillrate kann ein TBDR bei der DOOM III Engine nicht viel Boden gut machen. Möglicherweise erreicht er eine höhere Ausnutzung weil die Pixelshader eines IMR bei DOOM III öfter mal leerlaufen dürften weil beim HSR grosse Blöcke einfach verworfen werden.

[zeckensack]

Original geschrieben von Ailuros
Komischerweise hab ich application driven DR etwa so verstanden, denn SA bei B3D hat es mehr als oefters erwaehnt und auch teilweise erklaert (an unshaded pass immediately followed by a shaded pass); irgendwie hab ich auch dass Gefuehl dass S3 damit mehr auf Doom3 rendering zielt als auf jegliches andere, da die stencil ops ja back to front gerendert werden und der Overdraw extrem hoch sein muesste.Die Stencil-Passes erfolgen mit abmaskiertem Z-Buffer (ie dieser wird nicht beschrieben, nur für Vergleiche gelesen).
Insofern ist die Unterscheidung F2B vs B2F irrelevant, weil alle 'Schichten' ausgewertet werden müssen. Oder anders gesagt: die Reihenfolge, in der ich die Schattenvolumen in den Stencil-Buffer blase ist egal, sowohl für die Optik, als auch für die Performance. Der Z-Test verwirft bei B2F genau die gleichen Pixel wie bei F2B.

[Ailuros]

OK wenn du "application driven" so definierst passt es schon. Ich würde es eher "Context abhängiges DR" nennen. Bleibt nur noch die Frage in wie weit der Chip überhaupt in der Lage ist zu erkennen wann welches Verfahren besser ist. Oder ob diese Auswahl dann Teil einer Applikationsspezifischen Optimierungsstrategie ist.

Soweit ich nichts falsch verstanden habe bei B3D als DeltaChrome Details zuerst erschienen, wird man es wohl auch abschalten koennen; was fuer mich auch Sinn macht, denn es ist nicht unmoeglich dass so manche Applikation auf die Methode merkwuerdig reagieren koennte.

Es liegt daran das zum rendern des Stencilbuffers für die Schatten der Z-Buffer bereits vollständig vorliegen muss. Bei der reinen Pixel/Texelfillrate kann ein TBDR bei der DOOM III Engine nicht viel Boden gut machen. Möglicherweise erreicht er eine höhere Ausnutzung weil die Pixelshader eines IMR bei DOOM III öfter mal leerlaufen dürften weil beim HSR grosse Blöcke einfach verworfen werden.

Danke. Obwohl ich's verstanden habe, waere ich nie selber darauf gekommen. :D

Die Stencil-Passes erfolgen mit abmaskiertem Z-Buffer (ie dieser wird nicht beschrieben, nur für Vergleiche gelesen).
Insofern ist die Unterscheidung F2B vs B2F irrelevant, weil alle 'Schichten' ausgewertet werden müssen. Oder anders gesagt: die Reihenfolge, in der ich die Schattenvolumen in den Stencil-Buffer blase ist egal, sowohl für die Optik, als auch für die Performance. Der Z-Test verwirft bei B2F genau die gleichen Pixel wie bei F2B.

zeckensack,

*confused*

Mein Paragraph war auf S3's eigene Behauptung hier ausgesetzt:

Greater Performance by avoiding redundant Overdraws

Deferred Two-Pass rendering virtually eliminates opaque (redundant) back-to-front overdraw and saves precious conventional Z-write traffic.

Was hab ich jetzt wieder falsch verstanden? :(

[zeckensack]

Original geschrieben von Ailuros
zeckensack,

*confused*

Mein Paragraph war auf S3's eigene Behauptung hier ausgesetzt:

Greater Performance by avoiding redundant Overdraws

Deferred Two-Pass rendering virtually eliminates opaque (redundant) back-to-front overdraw and saves precious conventional Z-write traffic.

Was hab ich jetzt wieder falsch verstanden? :( Nicht wirklich viel, das sollte nur eine kleine Korrektur zum Doom3-Rendering sein ;)

Wie im S3-Quote steht, DR eliminiert 'opaque b2f overdraw', das nützt natürlich auch in Doom 3, aber eben gerade nicht bei den Stencil-Operationen. Diese sind nicht 'opaque' :)

Die Schattenvolumen verdecken ja nichts, Z-Optimierungen (wie eben DR) sind dabei genauso nutzlos wie bei aktiviertem Blending.

[zeckensack]

Ailuros nochmal,
Original geschrieben von zeckensack
Die Reihenfolge, in der ich die Schattenvolumen in den Stencil-Buffer blase ist egal, sowohl für die Optik, als auch für die Performance. Der Z-Test verwirft bei B2F genau die gleichen Pixel wie bei F2B.
Und zwar werden während der Stencil-Passes (beim Zeichnen der Volumen) nur die Pixel vom Z-Test verworfen, die durch 'harte' Geometrie (Level-Geometrie und actors) verdeckt sind, die Volumen selbst verdecken aber nichts. Dazu gehört auch, daß die Vorderseite eines Volumens nicht die eigene Rückseite verdecken kann.

Wäre das der Fall, dann bräuchte man sowieso nur die front faces der Schattenvolumen zu zeichnen. Das ist natürlich falsch, dadurch visualisiert man dann nur die Form der Volumen, aber nicht den erwünschten Schatten.

Wenn du das schon wußtest, dann verzeih mir bitte meine Lehrer-Ambitionen :)

[Leonidas]

Original geschrieben von Demirug
S3 hat heimlich (schon vor einiger Zeit) die webseite aktualisiert.

Unter anderem ist dort jetzt auch folgedes zu lesen:



http://www.s3graphics.com/DeltaChromeADR.html

Es scheint sich also nicht um eine reine Treibersache zu handeln.

Denkbar wäre es IMO das man in diesem Ersten Pass nur einen Teil des den Hir-Z buffer mit Werten füllt und deswegen auch nicht bis auf Pixelebene rasterisert was Pixelfillrate sparen sollte.





Lagen wir doch gar nicht falsch:
http://www.3dcenter.org/artikel/2002/12-19_a.php

[Pappy]

Ist ja nicht schlecht das Ganze. Für eine Firma wie S3 finde ich das schon beachtlich. Aber leider hat man sich zu tode entwickelt, so daß das Teil ein wenig spät kommt. Aber mal sehen was daraus wird.

[Ailuros]

Wenn du das schon wußtest, dann verzeih mir bitte meine Lehrer-Ambitionen.

Ich vergib Dir gar nichts; irgendwie musst Du auch stutzig bleiben, sonst lern ich auch nie weiter :D

[Demirug]

Mein Kontakt bei S3 meinte übrigens das sie im dritten Quartal anfangen wollen die Testkarten an die Entwickler auszuliefern.

[robbitop]

das geht ja verdammt schnell bei S3. Anfang2003 ankündigen, Q3 ausliefern....verstehe das mal wer wolle ...

[Leonidas]

Original geschrieben von Demirug
Mein Kontakt bei S3 meinte übrigens das sie im dritten Quartal anfangen wollen die Testkarten an die Entwickler auszuliefern.


Oh super, Markteintritt 2004?


Wann hatte J.C. eine Testkarte der GFFX und wann kam die in den Markt?

[Demirug]

Original geschrieben von Leonidas
Oh super, Markteintritt 2004?


Wann hatte J.C. eine Testkarte der GFFX und wann kam die in den Markt?

Da habe ich echt keine Ahnung ich glaube auch das sich da S3 selbst noch nicht so ganz sicher ist.

Ich habe eben nur die Bestätigung erhalten das ich auf der Bezugsberechtigungsliste stehe und sie im dritten Quartal anfangen wollen an die Studios auf dieser Liste die Karten zu versenden. Da ich aber keine Ahnung habe wie gross diese Liste ist (über 100 Einträge sollen es aber sein) und wie viele Karten S3 dann hat bin ich noch nicht mal sicher ob und falls ja wann ich eine Karte bekomme. Es werden eben erst mal die bekannte Studios bedient werden.

[Leonidas]

Ich finde es erst einmal schön, daß Du Dich dazuzählen darfst. Außerdem stärkt es die Chancen auf einen realen Markteintritt des S3-Chips. Und eventuell sprichst Du mich im Q3 auch irgendwann mal ganz inoffiziell an, wenn es irgendwelche interessanten Infos gibt, die man bei 3DC verbraten könnte ;)

[Demirug]

So ich habe mal ein wenig in den Patenten die S3 in letzer Zeit veröffentlicht rumgesucht.

Das hier: http://l2.espacenet.com/espacenet/viewer?PN=US6473082&CY=gb&LG=en&DB=EPD

scheint der schlüssel zum "zero-cycle clear" und "Advanced DR" zu sein.

Das "Löschen" des Z-Buffers ohne den Speicher anzufassen ist dort erklärt. Zusammengefast ist es eine verbesserte Art eines Hir-Z Buffers welcher vollständig im Chip gespeichert wird.

Von DR wird dort zwar nichts gesagt aber man könnte wie ich bereits vermutet habe im Ersten Pass diesen Buffer füllen.