Combiner-Formel

[aths]

Welche Variante ist denn nun richtig?

(A + B) x (C + D)?

Oder (A x B) + (C x D)?

[Demirug]

Bei nVidia (A x B) + (C x D) s http://developer.nvidia.com/object/programmable_texture_blending.html

3dfx hat im Rampage (A+B)*C+D benutzt.

EDIT Rampage Formel berichtigt.

[zeckensack]

Zusatz:
1)Die beiden Multiplikationen und das Ergebnis der mittleren Operation sind getrennt verfügbar (können in verschiedene Register ausgegeben werden).
2)Die Operation in der Mitte kann auch 'Mux' sein, statt Addition. Mux wählt entweder den linken, oder den rechten Term, abhängig vom MSB des SPARE0-Registers (festgelegt).
3)Die Multiplikationsterme links und rechts können (im RGB-Combiner) durch DOT3 ersetzt werden. Und zwar unabhängig voneinander. Aber: bei mindestens einer DOT3-Berechnung verliert der Combiner die Fähigkeit, die Terme zu addieren oder zu muxen.

Ein RGB-Combiner kann also eine der folgenden Funktionen berechnen, wobei 'Ausgänge' selektiv abschaltbar, und Zielregister wählbar sind
out1=a*b out2=c*d out3=a*b+c*d
out1=a*b out2=c*d out3=mux(a*b,c*d)
out1=a dot3 b out2=c dot3 d -
out1=a dot3 b out2=c*d -
out1=a*b out2=c dot3 d -

4)Scale, Bias, Clamp ...

5)Die Konstante 0 ist hardwired als Input erfügbar, und lässt sich mit scale/bias bei Bedarf zu 1,0.5,-0.5 umformen.

6)Der Alpha-Combiner verhält sich fast gleich, nur dot3 fehlt (duh!), und er arbeitet mit Skalaren (duh!!).

7)Die 'blau'-Komponente eines RGB-Registers kann als Input für Alpha-Combiner benutzt werden. Alpha kann (natürlich) auch Input für den RGB-Teil sein.

[aths]

Danke, zecki. Zu einem späteren Zeitpunkt werde ich dich bezüglich deiner Ausführung noch mal nerven.

Demi (oder zecki), mit welcher dieser Formeln ließen sich einfacher Lerps (für TMUs) gestalten? Wenn man die richtigen Vorberechnungen macht, sollte (A x B) + (C x D) dafür ja gut geeignet sein. Lässt sich auch (A + B) x (C + D) dafür zweckentfremden?

[Demirug]

Original geschrieben von aths
Danke, zecki. Zu einem späteren Zeitpunkt werde ich dich bezüglich deiner Ausführung noch mal nerven.

Demi (oder zecki), mit welcher dieser Formeln ließen sich einfacher Lerps (für TMUs) gestalten? Wenn man die richtigen Vorberechnungen macht, sollte (A x B) + (C x D) dafür ja gut geeignet sein. Lässt sich auch (A + B) x (C + D) dafür zweckentfremden?

Ups die Rampage Formel stimmt nicht: Richtig ist (a+b)*c+d

Also ein Lerp lässt sich auf zwei Arten berechnen:

1. factor * src1 + (1-factor) * src2

oder

2. src2 + factor * (src1 - src2)

Mit (a+b)*(c+d) würde es allerdings nicht funktionieren.

[ScottManDeath]

mit den register combinern kriegt man ein lerp mit einem combiner hin, man muss nur den lerp faktor per input mapping (1-x) machen und dann den mux ausgang auf sum setzen und A*lerp und B*(1-lerp) für die AB bzw CD ausgänge nehmen

[zeckensack]

Original geschrieben von aths
Danke, zecki. Zu einem späteren Zeitpunkt werde ich dich bezüglich deiner Ausführung noch mal nerven.
Ich ergänze lieber jetzt schonmal, was ich bisher ausgelassen habe. Das beantwortet vielleicht auch die Frage, wie man Lerps auf RCs abbildet :)

Original geschrieben von zeckensack
4)Scale, Bias, Clamp ...... negate, invert.

Das ist aber schon abstrahiert, im Detail gibt es folgende Möglichkeiten für Input-"Mapping": x.clamp(0,1) ("UNSIGNED_IDENTITY")
1-x.clamp(0,1) ("UNSIGNED_INVERT")
x ("SIGNED_IDENTITY")
-x ("SIGNED_NEGATE")
2*x.clamp(0,1)-1 ("EXPAND_NORMAL)
-2*x.clamp(0,1)-1 ("EXPAND_NEGATE")
x.clamp(0,1)-0.5 ("HALF_BIAS")
-x.clamp(0,1)+0.5 ("HALF_NEGATE")

So kann man zB mit UNSIGNED_INVERT aus der Null-Konstante eine 1 machen, und mit EXPAND_NEGATE eine -1.

Für LERP auf RC benutzt man den Summen-Output, legt das 'Gewicht' an a (UNSIGNED_IDENTITY) und c (UNSIGNED_INVERT), und die beiden Quellfarben an b und d (UNSIGNED_IDENTITY oder SIGNED_IDENTITY). Die dazugehörige Variablenbenennung und Rechenvorschrift steht weiter oben :)


Skalierung ist ein reiner Output-Modifikator, 0.5, 1 (duh!), 2 und 4 sind möglich. Zusätzlich darf der Output noch um -0.5 'gebiast' werden. Wenn Bias benutzt wird, sind nur noch 1 und 2 als Scale zulässig. Bias erfolgt zuerst, Scale danach. Danach erfolgt implizites Clamping auf [-1;1], weil die Register größere Werte nicht speichern können.

Daraus ergeben sich die folgendenden möglichen Output-Modifikatoren für out, was hier für das Ergebnis der Combiner-Berechnung stehen soll. reg sei das Ziel-Register.
reg=out.clamp(-1,1)
reg=(out*0.5).clamp(-1,1)
reg=(out*2).clamp(-1,1)
reg=(out*4).clamp(-1,1)
reg=(out-0.5).clamp(-1,1)
reg=((out-0.5)*2).clamp(-1,1)

Da ein Combiner bis zu drei Zeilregister haben kann, sollte ich noch anmerken, daß Output-scale/bias nur für alle Ziele gleichzeitig eingestellt werden kann. Oder anders herum, unterschiedliche Output-Modifikatoren für die einzelnen Zielregister sind nicht möglich.

[aths]

Zecki, eigentlich suche ich eine Möglichkeit, also... ok, der Reihe nach :naughty:

While ich wohl zuviel Zeit habe, überlege ich, was ich ab Mitte 1996 gemacht hätte, hätte ich das Wissen von Heute und das Geld, 4-5 fähige Leute zu bezahlen, sowie Chips produzieren zu lassen. Das geht ungefähr so los:

1996: 2D-Core entwickeln

Mitte 1996: Dazu eine superprimitive 3D-Pipe. Triangle Setup macht der Treiber, automatische MIP-Map-Generierung ebenfalls. Die Pipe kann Single Texturing, Bilineares Filtering, MIP-Mapping inkl. pixelgenauem LOD, Z-Buffering, Z-Tests mit <, >, <=, >=, =, !=, Alpha-Tests mit ebenfalls allen genannten Möglichkeiten, Alpha Blending, Fogging, sowie Unterstützung von den Texturformaten 5:5:5:1, 5:6:5, 8:8:8:8.

Zu diesem einfachen Core, der noch nicht für das Endprodukt freigeschaltet worden wäre, dann den ersten Treiber schreiben, auf dem die weitere Entwicklung aufsetzt.

Die nächste Stufe wäre dann, die Pipe mit einer 2x SIMD-Logik auszustatten, um 2 Pixel gleichzeitig rendern zu können. Dann ein "kleines Loopback" für Trilinear Filtering, und ein "großes Loopback" für 4x Multitexturing. Hier kommt zwangsläufig auch Combiner-Logik ins Spiel. Und da überlege ich, einfach weil's Spaß macht, mit welcher Transistor sparenden Methode man viel erreichen könnte. Vielleicht ginge es ja, die Pipe mit der gleichen Logik entweder filtern oder rechnen zu lassen, was den Transistor-Count (zulasten der Leistung) senken dürfte. Wenn man pro Stage gleich 2 "allgemein verwendbare" Combiner-Formeln hat, die auch als Lerp herhalten können, wäre in 2 Takten bilinear gefiltert, bei 3 solcher Formeln sogar in einem Takt. U.U. könnte man 2 allgemein verwendbare Combiner dafür nehmen und zusätzlich nur fürs Texture Filtering noch ein primitives Lerp verwenden. Dann hätte man auch ein sinnvolles Sampling/Arithmetik-Verhältnis von 1:2.

[zeckensack]

aths,
RCs sind für Sample-LERPs durchaus einsetzbar. Dafür sind sie allerdings ebenso Overkill, wie sie es für einen '96er Grafikchip sind ;)

Hardware, die nur LERPs für Texturfilter macht, kann stark spezialisiert werden, und ist erfahrungsgemäß zu Lebzeiten der Geforce-RCs auch immer recht gut ausgelastet gewesen, also keineswegs verschwendet.

Wie Demirug schon schrieb, ein reines Lerp kann man auch als
src2 + factor * (src1 - src2)
schreiben. Dafür brauche ich nur einen Vektor-Multiplikator, im Ggs zu zweien für die 'klassische' Formel, oder eben auch einen RC. Multis sind sozusagen das Fleisch bei solchen Sachen, Addition/Subtraktion ist im Integer-Bereich Kinderkram. Für Scale/Bias ala NV RC braucht man auch nur ein paar Bits umzuwerfen.

Für einen bilinearen Box-Filter brauche ich zwei Lerps, die ich parallel bauen kann (die beiden 'Gewichte' sind dabei sogar gleich, was zu weiteren Logik-Vereinfachungen führt) ... oder eben zwei seriell geschaltete und unterforderte RCs.

Auch die Trennung in RGB-RC und Alpha-RC ist bei Texturfiltern nicht notwendig bis nicht erwünscht.

Es ist IMO durchaus denkbar, den Texturfilter mit RCs zu implementieren, aber eine sinnvolle Einsparung wäre es wohl kaum gewesen.

[aths]

zs, der "neue" Chip sollte ja erst 1997 erscheinen. Auf jeden Fall mit 4x Multitexturing per Loop-Back. Combiner brauchts dazu ja eh. Oder reicht für "normales" Multitexturing eine MAD-Logik aus?

[aths]

Original geschrieben von aths
zs, der "neue" Chip sollte ja erst 1997 erscheinen. Auf jeden Fall mit 4x Multitexturing per Loop-Back. Combiner brauchts dazu ja eh. Oder reicht für "normales" Multitexturing eine MAD-Logik aus? zs?

[zeckensack]

:|
Original geschrieben von aths
zs, der "neue" Chip sollte ja erst 1997 erscheinen. Auf jeden Fall mit 4x Multitexturing per Loop-Back. Combiner brauchts dazu ja eh. Oder reicht für "normales" Multitexturing eine MAD-Logik aus? Multitexture-Sachen sind schon etwas konfigurierbarer.
Der klassische Ansatz war dabei eine einfache Reihenschaltung, wo jede 'TMU' aus Input und Textursample einen Output erzeugt. Register kamen erst später ins Spiel. Dh eine Stufe in einem klassischen MT-Setup zerstört den ursprünglichen Eingabewert.

Die Möglichkeiten sind je nach Chip recht unterschiedlich, der kleinste gemeinsame Nenner definiert sich wohl durch DX6, wofür ich aber nicht unbedingt ein Experte bin.

GL1.2 definiert Replace:
out.rgba=sample.rgba
Modulate:
out.rgba=sample.rgba*in.rgba
Decal für RGB-Texturen:
out.rgb=sample.rgb
out.alpha=in.alpha
Decal für RGBA-Texturen:
out.rgb=sample.alpha*sample.rgb+(1-sample.alpha)*in.rgb
out.alpha=in.alpha
Blend für RGB-Texturen:
out.rgb=const.rgb*sample.rgb+(1-sample.rgb)*in.rgb
out.alpha=in.alpha
Blend für RGBA-Texturen:
out.rgb=const.rgb*sample.rgb+(1-sample.rgb)*in.rgb
out.alpha=sample.alpha*in.alpha

Dafür braucht's schon mehr als MAD, parametrisierbare LERP-Hardware mit getrennter Verarbeitung von RGB und Alpha ist das Minimum. '97er Hardware hätte sich diesen Anforderungen IMO stellen müssen, besser noch mehr bieten.
RivaTNT zB erweitert das ganze nochmal erheblich (vier Inputs pro Formel, Subtraktion, etc).

Ich weiß auch noch, daß eine Voodoo 2-TMU ein Paar Combiner-Formeln kennt, die sich schon nicht mehr auf einem einzelnen NV-RC rechnen lassen.

[Demirug]

Vergiss DX6 da hat ist jede Operation ein eignes Caps Bit und am Ende darf der Treiber denoch jedes Setup ablehnen.

[aths]

Original geschrieben von Demirug
Ups die Rampage Formel stimmt nicht: Richtig ist (a+b)*c+d2 ADD und 1 MUL sollte auf Integerbasis ja nicht so wahnsinnig transistorfressend sein. 4 Input-Register sind klar. Was wäre als Output sinnvoll?

O1 = (A+B)*C+D ist klar.

Macht es Sinn, gleich immer auch weitere Outputs auszugeben?

Im Moment habe ich noch Probleme, mir die Registerzuweisung vorzustellen. Die Inputs sollten ja entweder Textursamples oder interpolierte Farben sein können. Bei 4x Multitexturing ists wohl sinnig, auch zu erlauben, alle Register mit Texturen zu belegen. Dann hätte man aber einige Takte reineweg mit Textur-Sampling zu tun, und die Combiner faulenzen herum.

Wie komplex mag eine Logik sein, welche versucht die Arbeit gleichmäßiger zu verteilen, z.B. indem Pixelshader-like erst mal gesampelt und dann erst gerechnet wird?

[Demirug]

Original geschrieben von aths
2 ADD und 1 MUL sollte auf Integerbasis ja nicht so wahnsinnig transistorfressend sein. 4 Input-Register sind klar. Was wäre als Output sinnvoll?

O1 = (A+B)*C+D ist klar.

Macht es Sinn, gleich immer auch weitere Outputs auszugeben?

3dfx hatte nur diesen einen Output vorgesehen.

Im Moment habe ich noch Probleme, mir die Registerzuweisung vorzustellen. Die Inputs sollten ja entweder Textursamples oder interpolierte Farben sein können. Bei 4x Multitexturing ists wohl sinnig, auch zu erlauben, alle Register mit Texturen zu belegen. Dann hätte man aber einige Takte reineweg mit Textur-Sampling zu tun, und die Combiner faulenzen herum.

So funktioniert das bei Rampage nicht. Nur einer der Inputs kann ein Texturesample sein.

Rampage arbeite:
1xSample
2xRechnen (TCU und CCU)
1xSample
2xRechnen (TCU und CCU)
1xSample
2xRechnen (TCU und CCU)
1xSample
2xRechnen (TCU und CCU)

Ob und in wie fern da entkoppelt ist kann ich nicht sagen da das nicht eindeutig aus meinen bescheidenen Unterlagen hervorgeht.

Wie komplex mag eine Logik sein, welche versucht die Arbeit gleichmäßiger zu verteilen, z.B. indem Pixelshader-like erst mal gesampelt und dann erst gerechnet wird?

Meinst du jetzt beim Rampage oder Allgemein?

[aths]

Original geschrieben von Demirug
3dfx hatte nur diesen einen Output vorgesehen.Ja, während man beim RC ja z.B. 2 unabhängige MUL haben kann, das geht bei der Rampage-Formel nicht. Macht es dennoch Sinn, Teilergebnisse per se in ein Output-Register zu schreiben?
Original geschrieben von Demirug
So funktioniert das bei Rampage nicht. Nur einer der Inputs kann ein Texturesample sein. Das ist ja shice.
Original geschrieben von Demirug
Meinst du jetzt beim Rampage oder Allgemein? Bei einer hypothetischen Architektur, welche die Rampage-Formel nutzt, aber bis zu 4 Texturen als Input erlaubt.

[Demirug]

Original geschrieben von aths
Ja, während man beim RC ja z.B. 2 unabhängige MUL haben kann, das geht bei der Rampage-Formel nicht. Macht es dennoch Sinn, Teilergebnisse per se in ein Output-Register zu schreiben?

Die beiden Add ergebnisse könnte man möglicherweise nutzen aber ob es unbedingt sinn macht.

Das ist ja shice.

Relative. Dafür hat man dann aber einen 4 fachen dependet Read und man hat ja auch noch ein Registerspeicher. Dumm ist es eben nur das man von den zwei Rechnungen nur ein Endergebniss in den nächsten Pass retten kann. Braucht man den Wert einer Texture unverändert im Registerspeicher weil man ihn nur mit einer anderen Texture verrechnen möchte verliert man die beiden Rechenoperationen weil man ja den Ausgang der Pipe für diesen einen Wert braucht.

Bei einer hypothetischen Architektur, welche die Rampage-Formel nutzt, aber bis zu 4 Texturen als Input erlaubt.

Also ein NV20 mit einer anderen Formel?. Dort ist das Problem ja so gelösst das der sampleteil und der combiner Teil immer an unterschiedlichen Pixeln arbeiten.

[aths]

QUOTE]Original geschrieben von Demirug
Also ein NV20 mit einer anderen Formel?. Dort ist das Problem ja so gelösst das der sampleteil und der combiner Teil immer an unterschiedlichen Pixeln arbeiten. [/QUOTE]Ja, aber leider gibt es keine Phasen. Dabei wäre das doch gar kein so großer Aufwand?

[Demirug]

Original geschrieben von aths
Ja, aber leider gibt es keine Phasen. Dabei wäre das doch gar kein so großer Aufwand?

relative. Aber beim NV25 Design machen phasen nur begrennzt Sinn weil man ja vom Wechsel aus dem Textureteil in den combinerteil Genauigkeit verliert.

[Xmas]

Original geschrieben von zeckensack
Ich weiß auch noch, daß eine Voodoo 2-TMU ein Paar Combiner-Formeln kennt, die sich schon nicht mehr auf einem einzelnen NV-RC rechnen lassen.
Ein Paar? Ich finde nur eine: GR_COMBINE_FUNCTION_SCALE_OTHER_MINUS_LOCAL_ADD_LOCAL_ALPHA (edit: wobei der Final Combiner das schaffen sollte)
Das entsprechende Gegenstück im Alpha-Kanal ist ja nur ein Lerp. Schon etwas erstaunlich dass es da drei Namen für dieselbe Funktion gibt...
3dfx hat eben von Anfang an auf (A+B)*C+D gesetzt, NVidia hat Multiplikationen für wichtiger erachtet.

[zeckensack]

Original geschrieben von Xmas
Ein Paar? Ich finde nur eine: GR_COMBINE_FUNCTION_SCALE_OTHER_MINUS_LOCAL_ADD_LOCAL_ALPHA (edit: wobei der Final Combiner das schaffen sollte)
Das entsprechende Gegenstück im Alpha-Kanal ist ja nur ein Lerp. Schon etwas erstaunlich dass es da drei Namen für dieselbe Funktion gibt...
3dfx hat eben von Anfang an auf (A+B)*C+D gesetzt, NVidia hat Multiplikationen für wichtiger erachtet. Ja, da hast du wie üblich Recht ;)
Ich hatte noch SCALE_OTHER_MINUS_LOCAL im Hinterkopf, aber auf NV RC paßt das. Auf R100 ist's zuviel für einen Combiner, beim R200 zuviel für eine Shader-Instruktion.

[aths]

Wie sind denn die "Grundformeln" der R100 bzw. R200-Combiner?

[zeckensack]

Original geschrieben von aths
Wie sind denn die "Grundformeln" der R100 bzw. R200-Combiner? :|

Ziemlich vollständig R100:
a
a*b
a+b
a+b-0.5
a*c+b*(1-c)
a*b+c
a*b-c
a*b+c-0.5
Dot3
EMBM

Getrennt nach RGB und Alpha.
Die Eingänge können noch invertiert werden (x'=1-x).
Als Quellen gibt's interpolierte Vertexfarbe, Konstante (eine pro 'TMU'), das Ergebnis eines vorangegangenen Combiners, oder eine beliebige 'un-verkombinierte' Textur (nicht nur die eigene, sondern auch von anderen 'TMUs').
Die Formeln sind bis auf die fett markierten Dingselchen absolute Standardkost, MAD und Lerp eben. Ist nur der Vollständigkeit halber aufgezählt.

Der R200 kann viel zu viel, um das jetzt alles aufzuzählen. Ein R100-Combiner lässt sich komplett in einen einzigen Shader-Befehl quetschen, derer bekanntermaßen sechzehn verarbeitet werden können. Die Mächtigkeit ergibt sich vor allem aus sehr flexiblen Modifikatoren für Quell- und Zielregister. Und die dependant reads natürlich.

[aths]

zecki, wie kann ich mir einen R100-Combiner "aufgebaut" vorstellen? Schaltet der etwa je nach gewünschem Combining diese oder jene Rechenlogik zu, oder hat er nicht vielmehr eine General-Logik, wo nur dessen Eingänge unterschiedlich beschaltet werden?

[Xmas]

Wie wäre es mit etwa so (die blauen Linien im zweiten Adder wären für DP3, die roten für eine normale Addition):

[aths]

Hm, gleich so aufwändig? Ich hätte beim Design ständig das Wort "Transistor-Count" im Kopf.

[zeckensack]

Original geschrieben von aths
Hm, gleich so aufwändig? Ich hätte beim Design ständig das Wort "Transistor-Count" im Kopf. Was willst du denn noch kürzen?
Du hast zwei Vektor-Addierer und einen -Multiplizierer und holst das Maximum an Flexibilität heraus.

Bzgl Modifikatoren, Inversion von Integer-Werten ist das Umkippen aller Bits. Simpelst. Subtraktion von 0.5 geht bei Integern [0...1] auch recht leicht:
Wenn das MSB eins ist, setze es auf Null.
Wenn es schon Null war, setze alle Bits auf Null.

Einen "0.5-Subtrahierer" kann man als einfachen per MSB gesteuerten Umschalter bauen, der entweder die führende Null&LSBs oder eine Konstante Null durchreicht.

[aths]

Original geschrieben von zeckensack
Was willst du denn noch kürzen?
Du hast zwei Vektor-Addierer und einen -Multiplizierer und holst das Maximum an Flexibilität heraus. Wenn ich mich nur besser mit Pixelshading auskennen würde... wegen der gesparten Transistoren wäre ich im Moment eigentlich ein Fan der "3dfx-Formel". Nur wird sich NV bei ihrer Formel ja auch was gedacht haben, wie oft sie dadurch Vorteile haben, kann ich leider nicht abschätzen.

Sehe ich das richtig, dass Xmas' Lösung mindestens 3 Takte braucht, ehe fertig gerechnet wurde (was durch eine Pipeline natürlich "versteckt" werden könne?) Ich stellte mir das bislang so vor, dass in einem Takt alles parallel läuft, und man dann am Ende die Ergebnis-Register entsprechend zuweist.

[Demirug]

Original geschrieben von aths
Wenn ich mich nur besser mit Pixelshading auskennen würde... wegen der gesparten Transistoren wäre ich im Moment eigentlich ein Fan der "3dfx-Formel". Nur wird sich NV bei ihrer Formel ja auch was gedacht haben, wie oft sie dadurch Vorteile haben, kann ich leider nicht abschätzen.

Die 3dfx Formel braucht in etwa die gleiche Konstruktion wie die von Xmas. Nur der Dot3 Krempel bei der zweiten Additionseinheit entfällt.

Sehe ich das richtig, dass Xmas' Lösung mindestens 3 Takte braucht, ehe fertig gerechnet wurde (was durch eine Pipeline natürlich "versteckt" werden könne?) Ich stellte mir das bislang so vor, dass in einem Takt alles parallel läuft, und man dann am Ende die Ergebnis-Register entsprechend zuweist.

Nein das ganze läuft in einem Takt durch. Xmas hat es nur schon so gezeichnet das man das ganze leicht zu einer 3 Takt Konstruktion umbauen kann.

[aths]

Wie wäre es eigentlich mit (A+B)*C+(D*E)? :devil: :naughty: Damit hätte man Nvs und 3dfx' Formel in einer... (Für den Register Combiner müsste A mit 0 geladen werden, für den 3dfx-Combiner E auf 1 gesetzt...)

edit: Je länger ich die Formel ansehe, umso mehr gefällt sie mir. Input-Register hätte man also 5, an vorgefertigten Konstanten gibts die 0, 0.5, 1, -1, -0.5. Die vier Output-Register sind:

O1: (A+B)
O2: (A+B)*C
O3: (D*E)
O4: (A+B)*C+(D*E)

also ein ADD, ein MUL, ein MAD, und einmal die volle Formel. Man kann 2 unabhängige Multiplikationen pro Takt haben, so man will.

[Demirug]

nene aths wenn du schon so mit Recheneinheiten um dich wirfst dann musst du die teile auch so verschalten das man pro Takt

2 Additionen
+
2 Multiplikationen

oder

2 Dot3/Dot4

oder

2 MAD

berechnen kann.

[aths]

Hm. Eigentlich versuchte ich ja gerade, diesen "CPU-Ansatz" zu umgehen, also eben nicht in kleinere Recheneinheiten zu unterteilen, die dann kombiniert werden, sondern mit einer "Gesamt-Formel" auszukommen...

Ich durchdenk das erst mal die Tage, aber lasst euch nicht von weiteren interessanten Kommentaren abhalten!

[zeckensack]

Original geschrieben von aths
Wie wäre es eigentlich mit (A+B)*C+(D*E)? :devil: :naughty: Damit hätte man Nvs und 3dfx' Formel in einer... (Für den Register Combiner müsste A mit 0 geladen werden, für den 3dfx-Combiner E auf 1 gesetzt...)

edit: Je länger ich die Formel ansehe, umso mehr gefällt sie mir. Input-Register hätte man also 5, an vorgefertigten Konstanten gibts die 0, 0.5, 1, -1, -0.5. Die vier Output-Register sind:

O1: (A+B)
O2: (A+B)*C
O3: (D*E)
O4: (A+B)*C+(D*E)

also ein ADD, ein MUL, ein MAD, und einmal die volle Formel. Man kann 2 unabhängige Multiplikationen pro Takt haben, so man will.

Wie wäre es, wenn die erst Multiplikation abschaltbar wäre? Also ein Split zwischen (A+B) und C+(D*E).

Dann könntest du sowas ausgeben:
O1: (A+B)
O2: C+(D*E)

Und nach Reduktion
O3: C+D oder C+E

Also die von Demirug geforderten zwei Additionen pro Takt.

[aths]

Rrr. Wenn man das weiter treibt, käme man dazu:

Ein Combiner verfügt über ADD und MUL-Einheiten, jede dieser hat 2 Inputs und einen Output. Nach jeder Stage kann man die Register beliebig auf die Eingänge verteilen... Wie wichtig wäre es denn, pro Takt 2 unabhängige ADD zu haben?

[zeckensack]

IMO nicht besonders wichtig. Aber wenn du die Recheneinheiten sowieso eingeplant hast, dann ist es auch sinnvoll, möglichst volle Nutzung zu ermöglichen.

Die sich aufdrängende Frage ist dann allerdings, ob man die ganzen Recheneinheiten wirklich braucht, ober ob man nicht auch damit auskommt, rechenlastigere 'Shader' auf mehrere Durchläufe aufzuteilen.

Bei klassischer Bindung Combiner<->Textursampler ist das problematisch, denn dadurch wird die erreichbare Texelfüllrate gesenkt (komplexe Schaltungen reduzieren den Maximaltakt). Zu Lebzeiten 'deines' Chips wären wohl eher simple Combiner-Berechnungen gefordert gewesen, und es ist immer doof, wenn etwas einfaches nicht auch schneller abläuft, als etwas kompliziertes. So wenig dir dieser Vergleich zusagen wird, aktuelle Chips sind deswegen auf bilineare Filter optimiert, weil es eine Handvoll Anwendungen für reines Bi gibt, und die sollen dann bitteschön auch schneller sein als trilinear.

R100 hat ja schon eine Crossbar für die Textursampler, also kann man die Trennung als vollzogen ansehen. Wenn man dickere Berechnungen braucht, schaltet man einfach weitere 'TMUs' hinzu. Die Texturen auf diesen 'Rechen-TMUs' können dank der Crossbar trotzdem noch benutzt werden.

Was dann noch fehlt, ist eine großzügige Loopback-Technik, zumindest für die Recheneinheiten. Daran scheitert der R100.

Btw, schnelle, einfache Einheiten mit viel Loopback sind IMO besser als viele mächtige serielle Combiner. Der Taktspielraum und die Spitzenleistung sind höher.

Die Performance soll ja mit der Shader-Komplexität skalieren. Durch eine lange Kette handelt man sich dabei eine gewisse Granularität ein, die im Zweifelsfall die Performance weiter behindert (vgl Geforce 3 mit ungerader Anzagl bi-gefilterter Texturen).

[aths]

zs, ich weiß nicht, ob ich deinem Posting in Gänze folgen konnte. Meine Idee wäre eigentlich, eine Fixed-Function-Pipe mit der "3dfx-Formel" zu gestalten, und erst später für "meine" "Register Combiner" auf die große Formel aufzurüsten. Nur ist die Frage, wie sinnvoll das ist. Wenn man pro Takt und Pipe nur ein MAD hat, dadurch aber einen schlanken Die bekommt, der sich höher takten lässt, käme man u.U. auf eine höhere Endleistung, weil man die Riesenformel ja nicht unbedingt pro Takt braucht. An Loopbacks bei einem RC-Combiner-Chip würde ich 3 sinnvolle "Kreise" sehen:

1. Um die TMU, für TF und AF.
2. Um die Combiner-Logik, um 8 Stages zu erreichen.
3. Um "das ganze", um mehrfach sampeln zu können ("Phase")

Ich sehe kaum einen anderen Weg, Sampling vom Rechnen zu trennen (also damit jeweils andere Pixel zu bearbeiten) um nicht zuviel Performance zu verschwenden. Eigentlich würde ich es besser finden, wenn man zwischendurch beliebig neu sampeln könnte, so dass man keine Phase braucht, um mit PS berechnete Koordinaten als Sample-Position zu benutzen. Doch dann könnte ja das Sampling das Rechnen aufhalten bzw. das Rechnen das Sampling behindern.

[Demirug]

Original geschrieben von aths
Ich sehe kaum einen anderen Weg, Sampling vom Rechnen zu trennen (also damit jeweils andere Pixel zu bearbeiten) um nicht zuviel Performance zu verschwenden. Eigentlich würde ich es besser finden, wenn man zwischendurch beliebig neu sampeln könnte, so dass man keine Phase braucht, um mit PS berechnete Koordinaten als Sample-Position zu benutzen. Doch dann könnte ja das Sampling das Rechnen aufhalten bzw. das Rechnen das Sampling behindern.

Der NV3X ist genau dafür ausgelegt nur leider ist das Registerfile zu klein geworden um das ganze mit viele Temp-Registern zu machen.

[Gast]

aths;

auch wenn ich nur einen kleinen Teil von dem verstehe, was hier so gesprochen wird. :(

Wie wärs, wenn du dir die Schemata des Pyramid3D-Chips anschaust. Der hatte 1997 angeblich schon VS und PS, wenn auch ziemlich primitive. Und schnell war der Chip auch nicht. Aber im Prinzip sollte er doch genau das bieten, was du willst.

[aths]

Also, mein bisheriges Planspiel sieht so aus:

1996 1. HJ: 2D-Core entwickeln, mit Windows-Beschleunigung (Chip-Code A1.) und 32-Bit-Overlay. Wird mit 32 Bit 4 MB oder 64 Bit 8 oder 16 MB verkauft.

1996 2. HJ: Superprimitiven 3D-Core dazu entwickeln (im gleichen Chip) aber 3D-Funktionen noch nicht freischalten, sondern die HW-Basis für einen ersten 3D-Treiber schaffen. Features: Single Texturing, Bilinear Filterng, MIP-Mapping mit pixelgenauem LOD, Z-Buffering, alle denkbaren Z-Tests sowie Alpha-Tests, Fog, die wichtigsten Textur-Formate (5:5:5:1, 5:6:5, 8:8:8:8). Texturen bis 2048x2048. Der Chip rendert kleine Tiles, von dem Frame- und Z-Buffer jeweils komplett im Chip sind. Codename A2.

1997 1. HJ: Diesen Core mit Trilinear Filtering, 4x Multitexturing per Loopback, 2x SIMD (= "2 Pipes") und einfachem Combiner basierend auf (A+B)xC+D erweitern. Speicher-Kontroller vom Chip-Takt entkoppeln, und mit einem Cache der 2-3 Burstlines vorhalten kann versehen. Privimites Early-Z: Sind beide Pixel verdeckt, fliegen beide aus der Pipe (1 Takt "Verschwendung" für den Test bleibt aber.) Ansonsten gehen beide durch die Pipe, das Z-Ergebnis wird gehalten, um ggf. einzelne unsichtbare Pixel auch nicht in den Onchip-Framebuffer-Cache zu schreiben.

Der 3D-Teil sampelt Texturen mit 10 Bit, und rechnet ansonsten durchgehend mit 12 Bit. (Vorzeichen, 1 Bit Overbright, 8 Bit Integer und 2 Bit "Fraction".) Für den 32-Bit-Framebuffer kann auf Wunsch gedithert werden. Mit 10-Bit-RAMDAC und 3dfx-mäßigem Postfilter beim Scanout. Gammakorrektes Textur-Filtern. Chip A5.

Chips mit kaputtem 3D-Teil werden als reiner 2D-Chip verkauft (namens A3.)

1997 2. HJ: Qualitäts-Offensive: 2x RGMSAA, 2x AF. Noch keine Z- oder Color-Compression, dafür trilineare TMUs, und einfacher CBMC, also Unterteilung des Speicher-Controllers in 2 Hälften. Zweistufiger Cache für die internen Tiles (es werden einige Tiles im Chip vorgehalten.) Größerer Textur-Cache. FSAA-Downfiltering beim RAMDAC-Scanout, und zwar gammakorrekt.

Werbekampagne, um den Qualitäts-Modus als Must-Have anzupreisen. Der alte A5 geht mit 64-Bit-Interface in den OEM-Markt. Der aktuelle Chip wird in 2 oder 3 Taktungen angeboten (A10), zudem gibt es einer 64-Bit-Linie, die allerdings mit einem besonderen Kürzel verkauft wird (A10L.)

1998 1. HJ: Register Combiner einführen, mit der "großen" Formel. Das Web mit Bumpmapping-Demos fluten. 8 Stages insgesamt, davon bis zu 4 fürs Sampling (wie beim PS.1.0) alles nach wie vor noch mit 12 Bit. Generell eine propritäre Texture Compression einführen, die per Treiber aktiviert werden kann. (A15) Niedrig getaktete Version für die "Value"-Freunde (A14). Modularen Konzept: Ist die MSAA- oder AF- oder RC-Logik kaputt, kann das alles ganz abgeschaltet werden, der Chip geht unter extra-Namen auch in den OEM-Markt. (A8L.)

1998 2. HJ: Den Chip auf 4x SIMD aufbohren. Den Speicher-Controller in eine 4xCrossbar aufteilen und die Cache-Logik optimieren. Verbesserter Early-Z-Test: Das Triangle Setup liefert nun viel schneller die Pixel und schreibt in einen Cache, der getestet wird. Finden sind im aktuellen Tile 4 sichtbare Pixel, kommen sie in die Pipe. Solange die Pipe nicht leer läuft, verschwenden verworfene Pixel keine Takte mehr. (A20.) Die bisherige 2-Pipe-Variante mit neuen Taktraten versehen, ggf. den Chip dafür optimieren. (A16.) Weiterhin A5 im OEM-Markt platzieren.

1999 1. HJ: Qualitäts-Offensive, 2x MSAA auf 4x aufbohren, AF bis 16x anbieten, und zwar ohne jede Winkel-"Optimierung". Z- und Color-Compression einführen. Overbright auf 3 Bit erweitern, also mit insgesamt 14 Bit pro Kanal rechnen. RAMDAC auf 12 Bit erweitern. (A25.) Im OEM-Markt nun den A10 (mit 2x AA/AF) platzieren.

1999 2. HJ: DXT1 und FXT1 implementieren. Fixed Function T&L teilweise per Software emuliert, aber "Hardware assisted", der Chip kann pro Takt 4 32-Bit-Skalare mit je einer MAD-Logik bearbeiten. Implementierung neuer 2D-Funktionen, vor allem für den DVD-Bereich. (A30.)

2000 1. HJ: Den Chip auf DDR-Speicher vorbereiten, ein logisches 256-Bit-Speicherinterface implementieren. Das Overlay mit aufwändigen Filtern verbessern. Ansonsten nur die bisherigen Produkte mit neuen Takten auf den Markt bringen. Versuchen, OpenGL-Treiberkapazitäten zu kaufen. OpenGL-Produkte vorbereiten.

2000 2. HJ: Für das Enthusiast-Segment den vorher entwickelten A35 mit DDR-RAM herausbringen. In den OpenGL-Markt mit dem A35 vordringen.

2001 1. HJ: Den Chip Vertexshader 1.1-tauglich machen. Für Pixelshader 1.3 die Register Combiner mit einer Phase-Möglichkeit versehen, unter OpenGL die neuen RC-Features vollständig freisetzen. Entwickeln einer kleineren Version mit nur 2 Pixeln / Takt und kleineren Caches, sowie nur 2x CBMC-Interface (A31.) Der Chip stellt die neue Midrange-Linie, ebenso die neuen Entry-Level-OpenGL-Karten.

2001 2. HJ: Öhm, keine Ahnung...

[Gast]

ähhh aths;

du bist dir aber ganz sicher, das du Rendition nicht wieder aufleben lassen willst ???
Deine Kommentare zu den kleinen Die's erinnern stark an den V1000. Die nächste Generation ( A5 ) an den V2000.

Und der Rest an den V3000. siehe : http://www.renditionrevival.com/fows/fowindex.html

[aths]

Von Rendition kenne ich nur den Namen, leider keine Produkte. Mein "Planspiel" ist ja insofern sinnfrei, dass über eine Zeit geredet wird, die längst abgelaufen ist, und ich außerdem die Perspektive mit heutigem Wissen wähle, was man zu diesen Zeitpunkten natürlich noch nicht gehabt haben kann; und ich nur austeste, ob ich den Überblick über alle relevanten Features einer Graka habe.

[Gast]

Hi aths;

falls du an den Pyramid3D - Datasheets interessiert bist :

http://www.vlsi.fi/download/index.htm

VS_VP und VS25203 heißen die beiden PDF's.

Ich bin mir nicht zu 100% sicher, das es sich um die Pyramid3D-Datenblätter handelt aber zu 99% (schaun wir mal ob ich mich geirrt habe). :)

[Ailuros]

Ein bisschen memorabilia:

http://www.tomshardware.com/graphic/19980121/index.html

[aths]

Hm, hat 3DLabs auch mal für den Consumer Market produziert?

[Gast]

noch eine Ergänzung zum Pyramid3D :

www.hotchips.org/archive/hc9/hc9pres_pdf/ hc97_10c_eerola_2up.pdf

[StefanV]

Original geschrieben von aths
Hm, hat 3DLabs auch mal für den Consumer Market produziert?

Ja, haben sie.

Allerdings haben sie auch nur 2 Chips ausgeliefert, den Permedia1 und den Permedia2...

Tja, damals gabs halt mehr Chiphersteller als du Finger hast, heute ists leider umgekehrt :(

[Ailuros]

Original geschrieben von Stefan Payne
Ja, haben sie.

Allerdings haben sie auch nur 2 Chips ausgeliefert, den Permedia1 und den Permedia2...

Tja, damals gabs halt mehr Chiphersteller als du Finger hast, heute ists leider umgekehrt :(

Dass es heute so wenig sind ist kein Zufall, und genauso nicht warum die Mehrheit von uns Freaks damals Voodoo´s kauften. ;)