TMUs des NV30 (Split aus: 4200 schneller als 9500) [Archiv]

Demirug

2002-10-20, 17:31:56

So ich hab das mal rausgesplitet.

das mit dem AF ist natürlich ein Argument. Man sollte aber auch bedenken das man die TMUs mit Daten versorgen muss. Zudem bin ich mir nicht sicher ob die wenigen zusätzlichen Transitoren die man im verhältniss zum R300 hat neben den ganzen anderen Spielereien auch noch für 16 tri TMUs reichen.

Ich habe ja sowieso an anderer Stelle schon die vermutung bezüglich Pipeline entkoppelter TMUs geäusert. Und Bi TMUs sind halt einfach flexibler.

Xmas

2002-10-20, 18:07:32

Originally posted by Demirug
Ich habe ja sowieso an anderer Stelle schon die vermutung bezüglich Pipeline entkoppelter TMUs geäusert. Und Bi TMUs sind halt einfach flexibler.
Wobei mir nicht ganz klar ist wie du das meinst. Meinst du der Chip kann bis zu 8 (16?) Pixel pro Takt mit einer/zwei Texturen, 5 mit 3, 4 mit 4, 3 mit 5 und 2 mit bis zu 8 berechnen? Irgendwie kein allzu großer Gewinn... Oder zwei Dreiecke gleichzeitig bearbeiten?

Quasar

2002-10-20, 18:35:29

Für wie sicher haltet ihr es denn, dass es überhaupt 16 Stück werden werden? ;)

IMO würden, gemäß der Devise "Grundspeed reicht langsam" eher single-TMUs Sinn ergeben, die dann aber mind. trilinear single-Cycle können müssten und darüberhinaus am besten auch noch sehr schnelles AF ermöglichen müssten. Was genau da technisch nötig ist, weiss ich nicht, aber es macht IMO mehr Sinn, als 16 bi-TMUs, die zu großen Teilen verschwendete Transistoren darstellen, da mit dem nV30 (und R300) eh keiner mehr auf AF verzichten wird.

Demirug

2002-10-20, 19:14:06

Ok da muss ich etwas weiter ausholen.

Stellen wir uns mal einen Shader mit 3 Texturen und 5 Ops vor. PS >= 2.0.

pipeline 1 2 3 4 5 6 7 8 Samples

Befehl 1S 1S 1S 1S 1S 1S 1S 1S 8
2S 2S 2S 2S 2S 2S 2S 2S 8
3S 3S 3S 3S 3S 3S 3S 3S 8
40 4O 4O 4O 4O 4O 4O 4S 0
5O 5O 5O 5O 5O 5O 5O 5O 0
6O 6O 6O 6O 6O 6O 6O 6O 0
7O 7O 7O 7O 7O 7O 7O 7O 0
8O 8O 8O 8O 8O 8O 8O 8O 0

Nun versetzten wir die Befehlsbearbeitung der Pipelines zueinader.

pipeline 1 2 3 4 5 6 7 8 Samples

Befehl 1S 2S 3S 4O 5O 6O 7O 8O 3
2S 3S 4O 5O 6O 7O 8O 1S 3
3S 4O 5O 6O 7O 7O 1S 2S 3
40 5O 6O 7O 8O 1S 2S 3S 3
5O 6O 7O 8O 1S 2S 3S 4O 3
6O 7O 8O 1S 2S 3S 4O 5O 3
7O 8O 1S 2S 3S 4O 5O 6O 3
8O 1S 2S 3S 4O 5O 6O 7O 3

Jetzt haben wir die Samples gleichmäsig verteilt. Wären die TMUs aber fest einer Pipeline zugeordent wäre das nutzloss. Sind die TMUs aber von der Pipeline getrennt könnte man sie viel besser ausnutzen. In unserem Fall hätten wir 16 TMUs um 3 Samples zu erzeugen. Das heist wir können für jedes Sample ca 5 TMUs einsetzten. Die Formel dafür lautet:

TMUs pro Sample und Takt = TMUs * Länge des Shaders / (Samples * Pipelines)

16*8 / 3*8 = 5,33

wenn wir nun einen Shader mit 5 Samples und 25 ops hätten (durchaus wahrscheinlich)ergibt sich folgende Rechnung.

16*30 / 5*8 = 12

Durch eine Entkopplung der TMUs kann man also eine besser Auslastung erreichen.

P.S. Das ganze ist nicht aleine auf meinem Mist gewachsen sondern bassiert auf einer 3dfx Idee.

Xmas

2002-10-20, 22:35:18

Hm... ich werd mir das mal noch genauer überlegen. Aber dein Beispiel ist - sorry - Blödsinn, weil Textursampling und Color-Ops parallel ablaufen (wenn auch nicht zwangsläufig vom selben Pixel, es kann durchaus sein dass die TMUs bereits für das nächste Pixel samplen), es wären also 5 Takte pro Pixel bei 1 Color-Op/Takt.

aths

2002-10-20, 22:59:58

Originally posted by Xmas
Gesichert ist das ganz und gar nicht, ich bezweifle es sogar stark. Geht man vom 128-Bit-Interface beim NV30 aus - im Moment sieht es ja so aus - sehe ich keine Möglichkeit, 16 trilineare TMUs ausreichend mit Daten zu versorgen. 8x2 bi bedeutet schon, doppelt so hohe Anforderungen an den Speicher wie bei NV2x. Das kann man mit dem RAM-Takt u.U. ausgleichen. Bei trilinearen TMUs sehe ich keine Chance.

aths

2002-10-20, 23:03:47

Originally posted by Quasar
Für wie sicher haltet ihr es denn, dass es überhaupt 16 Stück werden werden? ;)

IMO würden, gemäß der Devise "Grundspeed reicht langsam" eher single-TMUs Sinn ergeben, die dann aber mind. trilinear single-Cycle können müssten und darüberhinaus am besten auch noch sehr schnelles AF ermöglichen müssten. Was genau da technisch nötig ist, weiss ich nicht, aber es macht IMO mehr Sinn, als 16 bi-TMUs, die zu großen Teilen verschwendete Transistoren darstellen, da mit dem nV30 (und R300) eh keiner mehr auf AF verzichten wird. Zwei bilineare TMUs auf der Pipeline sind natürlich flexibler als eine trilineare. Gerade wenn man Shader einsetzt, könnten dann immerhin 2 Texturen pro Takt bearbeitet werden.

Demirug

2002-10-21, 07:38:31

Originally posted by Xmas
Hm... ich werd mir das mal noch genauer überlegen. Aber dein Beispiel ist - sorry - Blödsinn, weil Textursampling und Color-Ops parallel ablaufen (wenn auch nicht zwangsläufig vom selben Pixel, es kann durchaus sein dass die TMUs bereits für das nächste Pixel samplen), es wären also 5 Takte pro Pixel bei 1 Color-Op/Takt.

Nicht mehr bei PS >= 2.0. Dort sind die Texturesample Anweisungen an beliebiger Stelle im Shader und die Texturkorrdinaten können aus beliebigen Register (auch die Temporären) kommen. Deswegen ist das Samplen der nächsten Pixel auch nur eingeschrängt möglich.

zeckensack

2002-10-21, 08:37:37

Aber bei dependant reads kann das doch garnicht aufgelöst werden? Da muß das Ergebnis der Colorops feststehen, bevor man die Textur addressieren kann.

Oder ist das einer der Gründe, warum man möglichst viel rechnen, und möglichst wenig lookups machen soll? :D

Demirug

2002-10-21, 08:51:50

zeckensack,

In wie fern die PS 2.0 Lookups die Pipeline wirklich blocken weis ich nicht (auch beim R300 kann das wohl ausser ATI im Moment keiner genau sagen). Das Rechnen läst sich wie bei einer CPU gut kalkulieren. Aber sobald Speicherzugriffe ins Spiel kommen sieht die Welt anders aus. Deswegen ja auch die Idee die TMUs von den Pipes zu entkoppeln.

zeckensack

2002-10-21, 08:57:26

Ok, rechnen=gut, lookup=böse :D

Aber die eigentliche Frage war ja auch mehr auf unvermeidbare dependant reads bezogen, environment maps und sowas.

Dann geht dieser Lösungsansatz doch wieder den Bach runter, oder???

Dann müßte im Extremfall der Pipelineversatz deaktiviert werden :|

Demirug

2002-10-21, 09:26:12

Originally posted by zeckensack
Ok, rechnen=gut, lookup=böse :D

Aber die eigentliche Frage war ja auch mehr auf unvermeidbare dependant reads bezogen, environment maps und sowas.

Dann geht dieser Lösungsansatz doch wieder den Bach runter, oder???

Dann müßte im Extremfall der Pipelineversatz deaktiviert werden :|

Warum sollte das den Bach runter gehen?

Jede Pipeline für sich arbeitet ja den Shader genau in der vorgegebenen Rheienfolge ab. Durch den Versatz erreicht man lediglich das nicht alle 8 Pipelines gleichzeitig ein Sample anfordern oder es eben nicht tuen. Die Pipelines arbeiten ja nach wie vor vollkommen unabhängig voneinander.

Xmas

2002-10-21, 09:53:19

Originally posted by Demirug
Nicht mehr bei PS >= 2.0. Dort sind die Texturesample Anweisungen an beliebiger Stelle im Shader und die Texturkorrdinaten können aus beliebigen Register (auch die Temporären) kommen. Deswegen ist das Samplen der nächsten Pixel auch nur eingeschrängt möglich.
Das beeinflusst aber doch nicht dass man aufeinanderfolgende Pixel in einer Pipeline versetzt bearbeiten kann, so dass Sampling und Color-Ops möglichst parallel ablaufen. Dazu benötigt man freilich ein paar Register mehr.

Demirug

2002-10-21, 10:23:50

Xmas,

so einfach ist das nicht.

Die PS 1.x arbeiten noch folegndem Prinzip:

1. Sample (max 4)
2. Color Ops (max 8)

bzw 1.4:

1.Sample (max 6)
2.Ops (max 8)
3.Sample (max 6)
4.Color Ops (max 8)

die PS >= 2.0 arbeiten so

1. Sample/Op (max 64 ops / 32 Sample bei 2.0)

Eine Sample anweisung nimmt dabei die Koordinaten aus einem beliebigen Register und speichert den Samplewert in einem gewählten Temp Register. Der Samplewert kann in der nächsten Anweisung dann beliebig eingesetzt werden. Die Ops sind unproblematisch. Bei den Samples kann es aber zu Verzögerungen kommen.

Wie will man bei dieser Funktionsweise für den nächsten Pixel schon vorsampeln? Spätestens wenn die Sampelanweisung sich die Koordinaten aus einem Tempregister holt geht das nicht mehr. Die einzige möglichkeit die ich sehe wäre:

Während die TMUs der Pipeline ein Sampel erzeugen rechnet die ALU schon an einem anderen Pixel weiter. Dies würde aber erfordern das man den PS-Datensatz (10 Input + min. 12 Temps) mehrfach pro Pipe hätte. In Summe recht aufwendig.

Wenn man sich die NV30 API Spec anschaut kann man leicht zu folgendem Schluss kommen. Der NV30 enthält weiterhin die vom NV25 bekannten Registercombinder. Vor diesen befindet sich die PS 2.x Pipeline welche wie auch immer mit den TMUs verbunden ist. Das heist das bei allen "alten" Shadern das Samplen und rechnen nach wie vor parrallel erfolgen kann. Das Sampeln wird dann eben von der PS 2.x Pipeline übernommen welche 4 Farbwerte an die Registercombinder liefert.

Xmas

2002-10-21, 12:32:03

Originally posted by Demirug
die PS >= 2.0 arbeiten so

1. Sample/Op (max 64 ops / 32 Sample bei 2.0)

Eine Sample anweisung nimmt dabei die Koordinaten aus einem beliebigen Register und speichert den Samplewert in einem gewählten Temp Register. Der Samplewert kann in der nächsten Anweisung dann beliebig eingesetzt werden. Die Ops sind unproblematisch. Bei den Samples kann es aber zu Verzögerungen kommen.

Der Aufbau der PS2.0+ ist mir weitestgehend bekannt.

Wie will man bei dieser Funktionsweise für den nächsten Pixel schon vorsampeln? Spätestens wenn die Sampelanweisung sich die Koordinaten aus einem Tempregister holt geht das nicht mehr. Die einzige möglichkeit die ich sehe wäre:

Während die TMUs der Pipeline ein Sampel erzeugen rechnet die ALU schon an einem anderen Pixel weiter. Dies würde aber erfordern das man den PS-Datensatz (10 Input + min. 12 Temps) mehrfach pro Pipe hätte. In Summe recht aufwendig.

In den allermeisten Fällen bräuchte man gerade eine Handvoll Register mehr, und ich gehe sehr stark davon aus dass diese vorhanden sind. Ich denke, man kann durchaus davon ausgehen dass die Operationen für zwei aufeinanderfolgende Pixel "überlagert" werden, vergleichbar mit dem "FPU Scheduling" ab Pentium.

btw, Register Combiner schreibt man ohne d ;)

Demirug

2002-10-21, 13:08:13

Ja überlagert wird da sicherlich ansonsten liese sich die ALU ja gar nicht brauchbar in Stages aufteilen. Ich gehe sogar davon aus das minimum 3 Pixel (eher 5) gleichzeitig pro Pipeline "in flight" sind.

So in etwa:

ALU
Stages Takt >>

1 2 3 4 5 6
1 P1 P2 P3 P4 P5 P6
2 P1 P2 P3 P4 P5
3 P1 P2 P3 P4

Das löst aber nicht das Problem mit der ungleichmässigen Belastung der TMUs.

Xmas

2002-10-21, 17:18:41

Also mal sehen... das Entkoppeln der TMUs von den Pipelines bringt genau dann etwas, wenn der Shader zeitweise TMU-limitiert ist, sprich auf das Textursampling warten muss und die ALU während dieser Zeit nichts anderes tun kann. Ist der Shader voll TMU-limitiert, bringt auch das Versetzen nichts weil eh alle arbeiten. Ist er voll ALU-limitiert, spielen die TMUs eh keine Rolle.

Nun, ich glaube ehrlich gesagt nicht, dass dieser Fall oft auftritt. Dass die ALU während sie auf die TMU wartet nichts sinnvolles für einen anderen Pixel berechnen kann, finde ich unwahrscheinlich. Und selbst wenn es vorkommen sollte, ist es den Logikaufwand nicht wirklich wert.

Demirug

2002-10-21, 18:19:31

ich glaube das ich es immer noch nicht richtig verständlich gemacht habe.

nehmen wir mal einen ausgeglichenen Shader: 4 Sample 4 Ops immer wechselweise und die ColorOp braucht das Sampelergebniss: also

1: S
2: O
3: S
4: O
5: S
6: O
7: S
8: O

Da wir ja ein bischen Qualität wollen sagen wir mal tri 2xAF als Filter.

Jetzt jagen wir den Shader mal durch unsere 2 TMU pipeline. Die Stages hab ich jetzt der übersicht wegen weggelassen.

Takt Instruction Samples
1 1.S 2*8 = 16
2 1.S 2*8 = 16
3 2.O 0 = 0
4 3.S 2*8 = 16
5 3.S 2*8 = 16
6 4.O 0 = 0
7 5.S 2*8 = 16
8 5.S 2*8 = 16
9 6.O 0 = 0
10 7.S 2*8 = 16
11 7.S 2*8 = 16
12 8.O 0 = 0

So jetzt erlauben wir dem Chip das er die TMUs frei umverteilen darf und verschieben die Pipes zueinader.

Der übersicht wegen nur 2 Pipes:

Takt I.Pipe 1 I.Pipe 2 Samples
1 1.S 8.O 4*4 = 16
2 2.O 1.S 4*4 = 16
3 3.S 2.O 4*4 = 16
4 4.O 3.S 4*4 = 16
5 5.S 4.O 4*4 = 16
6 6.O 5.S 4*4 = 16
7 7.S 6.O 4*4 = 16
8 8.O 7.S 4*4 = 16

Ich hoffe jetzt ist klar auf was ich hinaus wollte.

Xmas

2002-10-21, 19:00:42

Originally posted by Demirug

Takt Instruction Samples
1 1.S 2*8 = 16
2 1.S 2*8 = 16
3 2.O 0 = 0
4 3.S 2*8 = 16
5 3.S 2*8 = 16
6 4.O 0 = 0
7 5.S 2*8 = 16
8 5.S 2*8 = 16
9 6.O 0 = 0
10 7.S 2*8 = 16
11 7.S 2*8 = 16
12 8.O 0 = 0

Sind das dependent Texture Reads oder wieso machst du O und darauffolgende S nicht im selben Takt?

Demirug

2002-10-21, 19:49:24

Originally posted by Xmas

Sind das dependent Texture Reads oder wieso machst du O und darauffolgende S nicht im selben Takt?

Es könnten dependent reads sein.

Damit der syncron Betrieb aber funktioniert müsste man jedenfall sTeile der Pipeline duplizieren. Die TMUs bräuchten eine Swizzle and Modification einheit sowie eine WriteMask Einheit. Zudem müsste man die TMUs auch noch an die PS-Datensätze anbinden und das PS-Programm entsprechend zerlegen. Also das ist ebenfalls sehr aufwendig und bringt nicht wenige Probleme mit sich. Da scheint mir ein konfigurierbares TMU Feld wesentlich einfacher in den Griff zu bekommen. Und damit könnte man wesentlich mehr fälle abdecken.

Ich denke mal das wir beide recht haben könnten. Sobald es Karte gibt kann man ja mal ein Programm schreiben mit dem man den aufbau herausbekommt wenn NV es nicht veröffentlicht.

Xmas

2002-10-22, 02:40:57

Originally posted by Demirug
Ich denke mal das wir beide recht haben könnten. Sobald es Karte gibt kann man ja mal ein Programm schreiben mit dem man den aufbau herausbekommt wenn NV es nicht veröffentlicht.
Eine gute Idee... und wahrscheinlich kommt dabei ein Ergebnis heraus das keiner wirklich deuten kann ;)

Richthofen

2002-10-22, 22:14:19

was sagtn ihr dazu?

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ft00&s1=nvidia&OS=nvidia&RS=nvidia

Quasar

2002-10-22, 22:30:47

Die Seite kann nicht angezeigt werden :(

Demirug

2002-10-22, 23:14:48

Link funktioniert nur wenn man in kopiert und in einem neuen Browserfenster benutzt.

Das ganze ist ein AA-Verfahren. Und die Beschreibung ist wie in Patenten üblich etwas undurchsichtig. Wenn ich morgen etwas wacher bin verstehe ich möglicherweise worauf das genau hinauslaufen soll.