DeltaChrome Vorabanalyse (Theorie)

[AMC]

Eins vorweg, ich möchte euch bitten, keine ATI vs. nVidia Diskussion in diesem Thread anzufangen. Ich möchte hier über die !technischen! Möglichkeiten des DeltaChrome spekulieren und diskutieren und dabei einzig alleine den Chip selber, nicht seine Treiber, die Vergangenheit seines Herstellers usw., durchkauen.

Gut, nachdem das geklärt ist, würde ich gerne von den Spezialisten, allen voran Demirug (wenn er die Zeit finden sollte), eine Analyse des DeltaChrome Chips erbitten, die unter folgendem Gesichtspunkt ablaufen sollte:

Wie schnell könnte der DeltaChrome maximal sein, wenn technisch beim Chipdesign alles glattgegangen ist und wir die Treiberqualität mal völlig ignorieren?

Ich möchte bei der Spekulation folgende Rahmenbedingungen vorgeben: (auch hier gilt, ich möchte aufgrund dieser Werte spekulieren, egal wie wenig gesichert sie gelten, also posting´s a la "das ist noch gar nicht raus blubb", bitte für einen anderen Speku-Thread aufsparen.) Thx. :chainsaw:

Rahmenbedingungen:

[list=1]
8 Pipelines mit je einer trillinearen TMU
Chiptakt : 375 Mhz
Speichertakt: 375 Mhz
Füllrate : 3 Gpix trillinearer Füllrate bei 375 Mhz Chiptakt
128-bit Speicherinterface
16 Texturen per pass (Rendering Durchgang)
funktionierendes Advanced Deffered Rendering (FtB, BtF)
funktionierendes Hierarchical Z
keine Shaderschwäche a la GFFX
Crossbar Memory Controller
Shadergeschwindigkeit: 9700er Niveau
diese DirectX 9 Fähigkeiten:
3DCenter (http://www.3dcenter.de/artikel/2002/12-19_c.php)
[/list=1]
Anmerkung zu den Rahmenbedingungen: Ich nahm den F1 Pole als Ausgangsbasis. Der Chip soll mit 350 - 400 Mhz getaktet werden und ich nahm einfach die goldene Mitte. Dasselbe gilt für den Speichertakt.

Die alles entscheidende Frage ist für mich jetzt, wie schell könnte der DeltaChrome mathematisch betrachtet und bei höchster Effizienz überhaupt sein? Vor allem, wenn man an die mittlerweile doch recht betagte Speicherbandbreite von nur 11 Gb/sec denkt. Wieviel könnte das Deferred Rendering im positivsten Fall von dieser Schwäche ausmerzen? Wie man sieht, berufe ich mich sehr oft auf könnte/sollte etc. ;D Ich traue S3 "noch" nicht wirklich über den Weg, obwohl ich sehr hoffe, dass der DeltaChrome ein würdiger Nachfolger meiner G4Ti sein 'könnte'. (Ups, da ist es wieder. :D)

Ich schätze, dass es doch für unsere Experten möglich sein sollte, eine Leistungsprognose ausgehend von meinen Rahmenbedingungen abzugeben. :D

Oder um es zu konkretisieren: Könnte ein solcher Chip auf das Niveau einer 5900/9700/Pro kommen?

[Aquaschaf]

Eine nicht unwichtige Rolle wird sicher die Effizienz der bandbreiteschonenden Maßnahmen sein, in etwa die Geschwindigkeit einer 9800 Pro wird man wohl erwarten müssen, aber wie es aussieht wird die Karte mit AA/AF nicht punkten können, was für eine Karte in der Preisklasse jedoch eigentlich entscheidend wäre.

[Tyler_Durden]

Original geschrieben von Aquaschaf
Eine nicht unwichtige Rolle wird sicher die Effizienz der bandbreiteschonenden Maßnahmen sein, in etwa die Geschwindigkeit einer 9800 Pro wird man wohl erwarten müssen, aber wie es aussieht wird die Karte mit AA/AF nicht punkten können, was für eine Karte in der Preisklasse jedoch eigentlich entscheidend wäre.

Mit Verlaub glaube ich nicht das der DC an einen R350 rankommt! Schon alleine nicht wegen des 256 Bit Interaces der R350 Karten!
Wenn S3 es aber schaffen sollte, dann Respekt!

[AMC]

Original geschrieben von Aquaschaf
Eine nicht unwichtige Rolle wird sicher die Effizienz der bandbreiteschonenden Maßnahmen sein, in etwa die Geschwindigkeit einer 9800 Pro wird man wohl erwarten müssen, aber wie es aussieht wird die Karte mit AA/AF nicht punkten können, was für eine Karte in der Preisklasse jedoch eigentlich entscheidend wäre.

Was die bandbreitenschonenden Maßnahmen angeht, hast du natürlich Recht. Ob der DeltaChrome allerdings 9800 Pro Niveau erreicht, naja, das vage ich schon eher zu bezweifeln. So weit hinauf müssen sie eigentlich auch gar nicht, um eine Alternative darzustellen. Es wäre natürlich sehr krass, wenn sie auf dieses Niveau kommen könnten, aber auch 9700/Pro Level wäre doch schon mal nett.

Was das AA angeht, hast Du auch Recht.
Bei dem AF hingegen, muss ich Dich korrigieren: Der DeltaChrome soll 16x AF beherrschen. Da der DC nativ im trillinearen Modus laufen soll, gehe ich mal spontanerweise von 16x-tri AF aus, was wiederrum von keinem anderen Hersteller derzeit geboten wird. Wobei hier natürlich noch keine Aussagen über Winkelabhängigkeit und ähnliches gemacht werden können. Und selbst wenn der DC winkelabhängiges AF bieten sollte, dann schätze ich ihn zumindest auf ATI´s AF Niveau, vielleich auch leicht drüber, ein.

Lesenswert ist auch dieser Artikel: Techreport (http://www.techreport.com/etc/2003q3/deltachrome/index.x?pg=1)

[zeckensack]

Ist doch ganz einfach:
50% schneller als 9500Pro, vielleicht etwas mehr (trilinear single-cycle). Und die gleiche Schwäche:
Bei massivem Einsatz von AA und gleichzeitig simplen (bzw garkeinen) Shadern wird das Teil derbe einbrechen. Dafür braucht man einfach Bandbreite. Dabei ist's btw ziemlich irrelevant für die Performance, wie gut das AA letztlich ist. Wenn es Multisampling ist (was ich doch sehr hoffe), dann zählt hier nur die Subpixel-Anzahl, und die Kompression.

[AMC]

Original geschrieben von zeckensack
Ist doch ganz einfach:
50% schneller als 9500Pro, vielleicht etwas mehr (trilinear single-cycle). Und die gleiche Schwäche:
Bei massivem Einsatz von AA und gleichzeitig simplen (bzw garkeinen) Shadern wird das Teil derbe einbrechen. Dafür braucht man einfach Bandbreite.

Wobei wir hier allerdings noch nicht wissen, wie effektiv das ADR des DC ist. Vielleicht kann er ja wesentlich effektiver seine 128-bit Bandbreite nutzen, als die 9500Pro.

Mal abgesehen davon, 9500Pro + 50% = 9700 wenn ich mich net irre. :D

AMC

[Ailuros]

Original geschrieben von AMC
Wobei wir hier allerdings noch nicht wissen, wie effektiv das ADR des DC ist. Vielleicht kann er ja wesentlich effektiver seine 128-bit Bandbreite nutzen, als die 9500Pro.

Mal abgesehen davon, 9500Pro + 50% = 9700 wenn ich mich net irre. :D

AMC

Egal welche sampling Methoden, das advanced deferred rendering hat die Nachteile eines IMR und TBDR in einem, mit Antialiasing.

Wenn es Multisampling ist (was ich doch sehr hoffe), dann zählt hier nur die Subpixel-Anzahl, und die Kompression.

Wieso hab ich das Gefuehl, dass es nicht nur das ist? Auf einem wahren TBDR gibt es weniger Probleme mit dem FSAA space, da das downsampling auf dem tile Level stattfindet und der externe framebuffer haelt nur den display resolution buffer. DC braucht Platz fuer deferring und fuer den FSAA buffer. Um einiges schlimmer wenn die originalen Spezifikationen eingehalten werden, ergo 16x MSAA.

[Gast]

Über das Thema Antialiasing beim Deltachrome brauchen wird doch gar nicht mehr zu reden. Es ist bekannt daß er bloß OG Supersampling AA kann.

Daß es besser ist höhere Auflösung + AF zu wählen statt dieser Art von Antialising wurde ja schon oft festgestellt.

[robbitop]

hallo Gast, wo hast du denn her, dass er nur OG kann? ich habe sowas noch nicht gelesen..würde mich aber interessieren....ausserdem ist 16xOG gar nicht so schlecht wenn es edge FAA wäre ;-)

[Quasar]

Ich glaub', er verwechselt Delta Chrome gerade mit den Volaris...

[robbitop]

dort wurde nicht explizit OG gesagt...dort wurde was von SSAA erzählt ;-)
wobei ich schon länger ahne dass das teil wie sein Vorgänger nur OGSSAA hat ...wie traurig für so eine Karte...

[Demirug]

Original geschrieben von Ailuros
Egal welche sampling Methoden, das advanced deferred rendering hat die Nachteile eines IMR und TBDR in einem, mit Antialiasing.

Nicht unbedingt. Es hängt sehr stark davon ab wie das advanced deferred rendering denn nun genau funktioniert. Beim ersten durchlauf wird wohl nur die obereste Ebene des Hir-Z Buffers gefüllt. Ist das Cache mangement gut erfolgt diese Arbeit komplett im Chip. Vertexshader Technisch wird man wahrscheinlich einen reduzierten benutzten welcher nur die Position berechnet. Das Problem ist natürlich das jeden Takt den man zu füllen des Z-Buffers benutzt natürlich nicht für das normale Rendern benutzt werden kann. Ist das System aber schlau genug kann man sich da einige Takte wieder zurückholen.

Wieso hab ich das Gefuehl, dass es nicht nur das ist? Auf einem wahren TBDR gibt es weniger Probleme mit dem FSAA space, da das downsampling auf dem tile Level stattfindet und der externe framebuffer haelt nur den display resolution buffer.

Sobald man aber nicht mehr komplett alles in die Displaylist bekommt wird FSAA auch zum Problem.

DC braucht Platz fuer deferring und fuer den FSAA buffer. Um einiges schlimmer wenn die originalen Spezifikationen eingehalten werden, ergo 16x MSAA.

Entweder läuft der Chip zweimal über den gleichen Komandobuffer oder es gibt zwei davon. Ein Kommandobuffer nimmt aber nur einen Bruchteil einer kompletten Displaylist ein.

[AMC]

Original geschrieben von Demirug
Nicht unbedingt. Es hängt sehr stark davon ab wie das advanced deferred rendering denn nun genau funktioniert. Beim ersten durchlauf wird wohl nur die obereste Ebene des Hir-Z Buffers gefüllt. Ist das Cache mangement gut erfolgt diese Arbeit komplett im Chip. Vertexshader Technisch wird man wahrscheinlich einen reduzierten benutzten welcher nur die Position berechnet. Das Problem ist natürlich das jeden Takt den man zu füllen des Z-Buffers benutzt natürlich nicht für das normale Rendern benutzt werden kann. Ist das System aber schlau genug kann man sich da einige Takte wieder zurückholen.


Hmm, kannst Du mir vielleicht mal erklären, warum der DC grundsätzlich diese Probleme (Nachteile vom TBDR und IMR zusammen), wie Ailuros sagte, haben soll? Ich steh glaube ich auf dem Schlauch. :D

AMC

P.S. Demi, wie schätzt Du die Geschwindigkeit des von mir angenommenen DeltaChrome in etwa ein?

[Demirug]

Original geschrieben von AMC
Hmm, kannst Du mir vielleicht mal erklären, warum der DC grundsätzlich diese Probleme (Nachteile vom TBDR und IMR zusammen), wie Ailuros sagte, haben soll? Ich steh glaube ich auf dem Schlauch. :D

AMC

Das musst du Ailuros fragen. Da ich das genaue verfahren nicht kenne kann ich nur spekulieren. Ich vermute mal das Ailuros davon ausgeht das im adr Modus der Chip in einem ersten durchlauf eine Displayliste und einen Z-Buffer erzeugt und dann in einem zweiten durchlauf diese Displayliste nach dem IMR prinzip abarbeitet aber aufgrund des Z-Buffers alle Pixel die nicht sichtbar sind verworfen werden. Ich vermute ja ein etwas anderes Verfahren.

P.S. Demi, wie schätzt Du die Geschwindigkeit des von mir angenommenen DeltaChrome in etwa ein?

Solange man nicht weiss wie und wann das adr arbeitet lässt sich das schwer einschätzen und von den Theoretischen Zahlen auf die Leistung zu schlussfolgern ist ja öfter in die Hose gegangen.

[Ailuros]

Das musst du Ailuros fragen. Da ich das genaue verfahren nicht kenne kann ich nur spekulieren. Ich vermute mal das Ailuros davon ausgeht das im adr Modus der Chip in einem ersten durchlauf eine Displayliste und einen Z-Buffer erzeugt und dann in einem zweiten durchlauf diese Displayliste nach dem IMR prinzip abarbeitet aber aufgrund des Z-Buffers alle Pixel die nicht sichtbar sind verworfen werden. Ich vermute ja ein etwas anderes Verfahren.

Ja so etwa. Problem ist dass DC mit 16xMSAA angekuendigt wurde und es verbleibt momentan noch ein Fragezeichen ob die es doch noch schaffen die finalen chips mit so hoher sampling Anzahl zu veroeffentlichen oder zur 2xSSAA SW Alternative greifen werden. Was mir aber wieder nicht Sinn macht ist dass ADR soweit ich weiss nur fuer spezifische Anwendungen vorgesehen war (Z-pass only first applications wie Doom3), was die obrige Theorie dann wieder einbrechen laesst; theoretisch sehe ich dann wieder keinen Grund warum MSAA nicht einsetzbar sein sollte wenn ADR nicht operativ ist.

Sobald man aber nicht mehr komplett alles in die Displaylist bekommt wird FSAA auch zum Problem.

Kein Problem theoretisch zumindest mit eingesetzter Parameter Kompression und Framebuffern von 256 bis 512MB. KYRO hatte nur 6MB fuer binning.

S3 wollte doch chips im Herbst Entwicklern ausreichen; immer noch nichts?

[Demirug]

Original geschrieben von Ailuros
Ja so etwa. Problem ist dass DC mit 16xMSAA angekuendigt wurde und es verbleibt momentan noch ein Fragezeichen ob die es doch noch schaffen die finalen chips mit so hoher sampling Anzahl zu veroeffentlichen oder zur 2xSSAA SW Alternative greifen werden. Was mir aber wieder nicht Sinn macht ist dass ADR soweit ich weiss nur fuer spezifische Anwendungen vorgesehen war (Z-pass only first applications wie Doom3), was die obrige Theorie dann wieder einbrechen laesst; theoretisch sehe ich dann wieder keinen Grund warum MSAA nicht einsetzbar sein sollte wenn ADR nicht operativ ist.

Wenn sich ADR nicht in Verbindung mit MSAA funktioniert dann gibt es schlicht und ergreifend einen Designfehler im Chip.

Gerade bei Z-Pass First Apps macht ADR eigentlich gar keinen Sinn denn in diesem Fall füllt ja die App schon den Z-Buffer und gerade D3 braucht den vollständig gefüllten Z-Buffer.

Im Prinzip sehe ich bei hohen subsample Zahlen gar kein so grosses Problem da man durchaus die Tatsache das nicht alle Pixel auf einer Polygonenkante liegen ausnutzen kann.

Kein Problem theoretisch zumindest mit eingesetzter Parameter Kompression und Framebuffern von 256 bis 512MB. KYRO hatte nur 6MB fuer binning.

Theoretisch ist das immer ein Problem das bei ausreichendem Speicherplatz für die Displaylist praktisch nicht auftreten kann. Wenn wir hier aber den vergleich zu einem IMR ziehen so dürften wir der Displaylist eigentlich nur den Speicher geben den das TBDR Verfahren einspart. Ohne AA währe das nur der Z/Stencil-Buffer. Bei 1024*768 gerade mal 3 MB. Mit AA gibt es dann mehr Speicher.

S3 wollte doch chips im Herbst Entwicklern ausreichen; immer noch nichts?

Ich weiss nichts neues.

[Ailuros]

Gerade bei Z-Pass First Apps macht ADR eigentlich gar keinen Sinn denn in diesem Fall füllt ja die App schon den Z-Buffer und gerade D3 braucht den vollständig gefüllten Z-Buffer.

Siehst Du da kommen Laien leicht schnell zur Verwirrung:

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.

Wenn im oberen Fall eine aehnliche Methode wie bei heutigen IMRs gemeint ist, dann ist es natuerlich eher ein Idealfall. In jedem anderen Fall sieht es eher merkwuerdig aus.

Theoretisch ist das immer ein Problem das bei ausreichendem Speicherplatz für die Displaylist praktisch nicht auftreten kann. Wenn wir hier aber den vergleich zu einem IMR ziehen so dürften wir der Displaylist eigentlich nur den Speicher geben den das TBDR Verfahren einspart. Ohne AA währe das nur der Z/Stencil-Buffer. Bei 1024*768 gerade mal 3 MB. Mit AA gibt es dann mehr Speicher.

Es geht mir hier nicht um TBDR's vs IMRs, sondern dem Unterschied zwischen tile based deferred rendering und nur deferred rendering. Wie gesagt wenn DC mit den Kombinationen von Bandbreiten sparenden Methoden wie andere IMRs vorgeht, sehe ich kein Problem. Im besten Fall ist wohl das "deferred rendering" nur Marketing-Firlefanz, genauso wie XP4 ploetzlich als "tiler" erschien.

Was den Speicher oben betrifft, was ist so schlimm an der Speicherverbrauchung fuer binning? Selbst bei vollen 10% was ein verrueckter Extrem-Fall aus minimalen 256mb ram sehe ich kein grosses Problem. Was hab ich verpasst?

[Demirug]

Original geschrieben von Ailuros
Siehst Du da kommen Laien leicht schnell zur Verwirrung:

Wenn im oberen Fall eine aehnliche Methode wie bei heutigen IMRs gemeint ist, dann ist es natuerlich eher ein Idealfall. In jedem anderen Fall sieht es eher merkwuerdig aus.

Etwas anderes als erst einmal einen Z-Buffer zu füllen macht eigentlich keinen Sinn. Da man hier auch von Passes und nicht von Steps spricht gehe ich stark davon aus das man jeweils von vorne in der Pipeline anfängt. Das würde auch zu der Patentschrift bezüglich eines Early-Z Verfahrens von S3 passen.

Es geht mir hier nicht um TBDR's vs IMRs, sondern dem Unterschied zwischen tile based deferred rendering und nur deferred rendering. Wie gesagt wenn DC mit den Kombinationen von Bandbreiten sparenden Methoden wie andere IMRs vorgeht, sehe ich kein Problem. Im besten Fall ist wohl das "deferred rendering" nur Marketing-Firlefanz, genauso wie XP4 ploetzlich als "tiler" erschien.

DR impliziert aber auf jeden Fall das eine Arbeit verzögert wird bis der Frame von der CPU abgeschlossen wurde. Die nV Chips könnten sich nur schwer DR schimpfen wobei auch dort etwas deferred gemacht wird. Das berechen der finalen Pixelfarbe beim AA wird erst ausgeführt wenn der Frame komplett ist bzw sogar erst bei der Ausgabe.

Vom Grundansatz ist die Idee von S3 gar nicht mal so schlecht. Mit einem IMR müssen sie zuerst einmal nicht mit möglichen kompatibilitätsproblemen kämpfen. Durch geschicktes ausnutzen der vorhanden Einheiten ist aber denoch ein Einspareffekt möglich. Die Problematik die ich aber sehe ist die Wahl zu treffen ob man jetzt im Einzelfall besser als reiner IMR arbeitet oder ob man ADR hinzuschaltet.

Was den Speicher oben betrifft, was ist so schlimm an der Speicherverbrauchung fuer binning? Selbst bei vollen 10% was ein verrueckter Extrem-Fall aus minimalen 256mb ram sehe ich kein grosses Problem. Was hab ich verpasst?

Es ist nichts schlimmes am binning nur stellt sich eben immer wieder die Frage nach der Relation. Gehen wir einmal von der für einen TBDR im Vergleich eher ungünstigen Z-Pass Situation aus. nachdem der Z-Buffer einmal gefüllt ist gibt es keine unnötigen Schreibzugriffe auf den Framebuffer. Gehen wir von einem schönen Strip aus braucht man pro Dreieck einen neue Vertexdatensatz. Nutzt man jetzt zum Beispiel alle 8 Texturkoordinaten voll aus ergeben sich 8*4*4(FP32) = 128 Byte die einmal geschrieben und wieder eingelesen werden müssen. Mit diesen 256 Byte könnte ein IMR 64 Pixel schreiben. Wird das Dreieck also kleiner als 64 Pixel zahlt man beim TBDR drauf. Ich habe die Sache jetzt durchaus etwas vereinfacht aber das Grundprinzip bleibt nach wie vor.

Wird das Shading komplexer (mehr Daten zwischen VS und PS) und die geometrie feiner aufgelösst (weniger Pixel pro Dreieck) wird der Bandbreitenbedarf bei einem IMR geringer aber bei einem TBDR steigt er an.

Schaut man sich die Bestrebungen der IHV welche IMRs bauen an so geht der Trend eigentlich schon länger dahin den Bandbreitenbedarf ins innere des Chips zu verschieben um die externe Bandbreite zu entlasten.

Es geht mir also wie ich hoffentlich verständlich machen konnte weniger um den Speicherverbrauch sondern um die Bandbreite.

[Ailuros]

Die Problematik die ich aber sehe ist die Wahl zu treffen ob man jetzt im Einzelfall besser als reiner IMR arbeitet oder ob man ADR hinzuschaltet.

Wie unmoeglich waere es dem User es freizulassen ob single oder two pass ADR im CP zu waehlen?

Es geht mir also wie ich hoffentlich verständlich machen konnte weniger um den Speicherverbrauch sondern um die Bandbreite.

Hab ich auch in der Zwischenzeit verstanden, aber dann waere es noch kritischer fuer zukuenftige Produkte da die rohe Bandbreite der zukuenftigen IMRs wohl nie erreicht wird.

In dem Fall heisst es wohl dass entweder Loesungen fuer die meisten Probleme implementiert wurden oder das ganze wird ganz schoen darunter leiden. Alles was wir zur Hand haben ist ne oede alte KYRO, wobei deren Problem mit Vertex Bandwidth die Bandbreiten-Vorteile eines TBDR virtuell eliminierte, aber im Durchschnitt war sie nie mehr Bandbreiten-hungrig als ein vergleichbarer IMR. Es war auch nur die Supersampling Aera aber selbst mit diesem zeigte KYRO keine Nachteile gegen die Konkurrenz; ganz im Gegenteil; man brauchte stellenweise eine GF2PRO um auf die gleichen SSAA Nummern zu kommen.