Geforce 4 = Lieber mehr Textureinheiten statt pipelines??!!

[Etienne]

Die Radeon 256 hat's vorgemacht!
3 Textureinheiten pro Pipeline lassen 3 Texturen maps durchflutschen!

3D Mark 2k1 hat dieses 'Feature' vorinstalliert ... Deshalb kommt man (unter anderem...) mit Radeons auf höhere Ergebnissse. Das sind sicherlich nicht die einzigen Gründe, da die DX 8 (und 8.1) Anpassung der Radeon schon gut sind, aber die Radeon 256 hatte keine DX 8 anpassung und schlug (früher) jegliche Geforce 2 Pro...

[Leonidas]

Die Praxis hat gezeigt, das dies nicht viel bringt. Je mehr Textureneinheiten, um so höher die Ineffizienz. Lohnt nicht, dann lieber mehr Pipes.


Mehr Textureneinheiten werden in 1-2 Jahren todsicher kommen, aber momentan fehlt die Software, die diese dauerhaft auslastet.

[aths]

Der Radeon bot aber nur 2 Pipelines. 3 TMUs - na gut. Dann aber bitte trotz dem 4 Pipelines.

[Quasar]

...und jetzt scheint sogar ATi sogar davon wieder abgerückt zu sein...schade, das war eigentlich der Grund, warum ich mir zwischendurch mal eine Radeon SDR angetan hatte. Und nun? Piefiges Loop-Back...naja, wenigstens der Pixelshader ist gut gelungen...hoffen wir mal, daß in der nächsten GF auch min. 1.4 unterstützt wird, ansonsten wird dieses Feature wohl nur eine Zukunft in Techdemos haben...

[Xmas]

Na ja, "piefig" würde ich Loopback nicht bezeichnen. Es ist eigentlich ein sehr sinnvolles Feature, insbesondere wenn man mal an dependent Texture Reads denkt. Denn wenn eine Operation von einer anderen abhängig ist, muss ja eine zeitliche Versetzung da sein.

[Quasar]

Aber nen Loop-Back kann man doch nach belieben einfügen, oder?

Ich meine, wenn schon die zweite Textur nen Dependent Texture Read braucht, wird die zweite TMU ja auch nicht mehr genutzt, oder?

Also, ich bin für mehr TMUs...8xMT ohne Bandbreitennachteil...

[ow]

Originally posted by Quasar


Also, ich bin für mehr TMUs...8xMT ohne Bandbreitennachteil...


???
Wo siehst du denn da einen Bandbreitenvorteil?

8 Texturen gleichzeitg lesen oder nacheinander (loopback, zb. 4x2tex), was braucht mehr Bandbreite?

[Xmas]

Originally posted by Quasar
Ich meine, wenn schon die zweite Textur nen Dependent Texture Read braucht, wird die zweite TMU ja auch nicht mehr genutzt, oder?
Und genau deswegen machen mehr TMUs nicht so viel Sinn. Wenn in Zukunft mit vielen Texturschichten gearbeitet wird, werden höchstwahrscheinlich auch ein paar abhängige Texturzugriffe dabeisein. Also bringen mehr TMUs kaum einen Vorteil, da sie oft nicht zum Einsatz kommen. Mehr Pipelines sind da eindeutig der sinnvollere Ansatz, auch wenn man dafür mehr Chipfläche braucht.

[Quasar]

@ow:
Ich ging mal vom heutigen Standard aus: sowohl ATi als auch nVidia brauchen für mehr als Sechs Texturen mehrere Rendering Passes, was sehr wohl einem Bandbreitennachteil entspricht.

Wenn die beiden Chips z.B. 4TMUs hätten, würden GF3 auf 8 Texturen ohne Multi-Pass Rendering kommen und die Radeon auf 12.


Klar, der Kyro z.B. kann auch heute schon 8 Texturen pro Pass draufpappen, nur fehlt dem leider die Füllrate, daß auch sinnvoll zu nutzen...

@Xmas:
Was die Dependant Texture Reads angeht, so denke ich, das solch komplexe Operationen in zukünftigen Games eher in den Bereich des Pixelshadings fallen....

[ow]

Originally posted by Quasar
@ow:
Ich ging mal vom heutigen Standard aus: sowohl ATi als auch nVidia brauchen für mehr als Sechs Texturen mehrere Rendering Passes, was sehr wohl einem Bandbreitennachteil entspricht.




Das ist mir schon klar.

Aber hast du dich nicht auf das loopback bezogen?

[Xmas]

Originally posted by Quasar
@ow:
Ich ging mal vom heutigen Standard aus: sowohl ATi als auch nVidia brauchen für mehr als Sechs Texturen mehrere Rendering Passes, was sehr wohl einem Bandbreitennachteil entspricht.

Wenn die beiden Chips z.B. 4TMUs hätten, würden GF3 auf 8 Texturen ohne Multi-Pass Rendering kommen und die Radeon auf 12.

Ich bevorzuge die Mehrfach-Loopback-Lösung, weil die zusätzlichen TMUs nur selten gebraucht werden und damit die meiste Zeit brachliegen.


Was die Dependant Texture Reads angeht, so denke ich, das solch komplexe Operationen in zukünftigen Games eher in den Bereich des Pixelshadings fallen....
Dann wäre wohl zu klären, wie du dir das "Pixelshading" in der Pipeline integriert vorstellst...

Wenn man zweifach abhängige Texturzugriffe hat (A abhängig von B, B von C), dann muss das auf drei Takte verteilt werden. Ich denke drei TMUs wären dann vorerst ausreichend. Mehr ist ineffizient.

[Quasar]

Ich dachte eigentlich, die Texture-Reads im Pixelshader laufen weitestgehend unabhängig von den Beschränkungen der normalen Pipeline ab....wenn das nicht so ist, bitte ich um Enthauptung und Beschuldige das Gegenteil!

[tb]

Originally posted by Xmas

Ich bevorzuge die Mehrfach-Loopback-Lösung, weil die zusätzlichen TMUs nur selten gebraucht werden und damit die meiste Zeit brachliegen.


Dann wäre wohl zu klären, wie du dir das "Pixelshading" in der Pipeline integriert vorstellst...

Wenn man zweifach abhängige Texturzugriffe hat (A abhängig von B, B von C), dann muss das auf drei Takte verteilt werden. Ich denke drei TMUs wären dann vorerst ausreichend. Mehr ist ineffizient.

http://www.delphion.com/details?pn=US06333744__

"Pixel Shader" (Combiner....) und Pixelpipelines sind eng miteinander verbunden, anders ist es kaum sinnvoll zu lösen.
Schaut Euch einfach mal das NV20 Patent an.

Thomas

[Xmas]

Huch, das Posting von Quasar hatte ich gar nicht mehr gesehen...
Egal, die Antwort von tb sagt ja schon das meiste. Pixel Shader beim GF3 ist eigentlich nur eine Weiterentwicklung der Register Combiner-Technik des GF2 (des GF1,...), deswegen hält sich auch die "Programmierbarkeit" in engen Grenzen.
Ich finds immer komisch, wenn jemand sagt, GeForce4 hätte eine zusätzliche "Pixel-Shader-Einheit", dabei ist das integraler Bestandteil jeder Pixelpipeline.

[aths]

Hehe, ich sollte mal meine Idee vom Hyperthreading auf der Pixelpipeline konkretisieren :))

Einerseits halte ich 3 TMUs schon für sinnvoll: Moderne Spiele nutzen 3 Texturen pro Dreieck, und dann wird immerhin ein Takt gespart!! Insofern würde ich mich über 3 TMUs pro Pipeline sehr freuen. Andererseits würde meine Idee von wirklich programmierbaren Pixelpipelines auf 1 TMU pro Pipe hinauslaufen - mit (praktisch) unbegrenzer Loopback-Möglichkeit.

Echte Programmierbarkeit würde auch Loops etc. erfordern, so dass eine Pipeline je nach Situation unterschiedlich lange brauchen kann. Man müsste also noch eine intelligente Lastenverteilung entwickeln. Der Füllrate wegen sollten es dann schon 8 oder mehr Pipelines pro Chip sein. Das erscheint ungeheuer HW-aufwändig. Aber warum jede Logik 8-fach auslegen? Warum sollte eine Pixelpipeline nicht auf gemeinsame Combiner u.ä. zurückgreifen?

Die Grafikkarte würde damit wesentlich mehr Funktionen übernehmen.

Ehe man sowas "brauchen" könnte, wäre ich allerdings für 16-Bit-Floating Point-Farbe (Texturen, Rendering, Framebuffer) und "normalen" PS mit 3 TMUs auf der Pipeline. Die TMUs können zumindest beim normalen Rendering was bringen. Um an der Die-Größe zu sparen, könnte man ja auf trilineare Filterung verzichten, so dass einfach nur bilinear gefiltert wird. (Ist auf der Radeon ja auch so)

[aths]

Anmerkung: Eine genüngend flexibel ausgelegte Architektur könnte jeweils entweder 2 8-Bit-Integer oder 1 16-Bit-Integer verarbeiten :)

edit: Ich mag keine grafischen Smileys.

[Fragman]

@xmas:
hab mal gelesen, der pixal shader wird anstatt der normalen textureinheiten eingesetzt, was stimmt nun, kannst du es naeher erklaeren?

gruss, fragman

[Xmas]

Textureinheiten und Pixelshader sind ergänzende Elemente. Die einfache Beschreibung:
Textureinheit: Texturkoordinaten rein, Texel lesen, filtern, Farbwert raus.
Pixel Shader: Mehrere (Farb-)Werte rein, irgendwie kombinieren, ein Farbwert raus.

Oder im Falle von dependent Texture Reads: Farbwerte in PS rein, Texturkoordinaten raus -> in TMU rein, Farbwert raus -> in PS rein, weiterrechnen...

Einstellungen wie z.B. Filtermodus, Textur, Texturformat für die TMU bzw. Rechenschritte für den Pixel Shader werden vorher festgelegt.