TMUs im nV30

[Quasar]

Da sich nVidia bei der Texelfüllrate des nV30 bei der Präsentation ja nicht so wirklich festgelegt hat, was die Anzahl der TMUs angeht, ExtremeTech (http://www.extremetech.com/article2/0,3973,710340,00.asp) sogar soweit geht, in der Vergleichstabelle von "undisclosed" bzw. "unknown" zu sprechen, während quasi der Rest der Welt von einem 8x1-Design ausgeht, habe ich mal ein wenig rumgelesen.

Texuter Samplers
CineFX pixel shaders can take advantage of 16 texture samplers. Programmers designate which sampler and which coordinate to pair up to performa a texture fetch. Each texture coordinate is no longer paired with the corresponding spcific texture. Therefore, fetches can be performed from 16 different textures using just one texture coordinate. Similarly, fetches could be performance from eight different unmodified coordinates within one texture.
(aus dem TB-00626-001_v01_Shaders_110402.pdf, Seite 17 von nV)

Da ich mir einbilde, über ein recht gutes Englisch zu verfügen, scheint's hier IMO eher an der deutschen Bedeutung zu mangeln:
Heisst das nun, dass die Texture Samplers quasi beliebigi kombiniert werden können, um entweder sehr schnelles BF, schnelles TF oder halbwegs schnelles AF durchzuführen. Oder sind die 16 TS womöglich gar pro Pipe?
Das würde doch heissen, dass bei 4 Texture Fetches für ein bilineares Sample die besagten 16 ausreichend für trilineares Filtering sind, oder?

Das allein wäre ja noch nix so dolles (ATi scheint das auch gut hinzukriegen), aber daraus könnte man dann doch 2 Bilineare TMUs pro Pipe basteln, oder?

*grübel*

edit:
DK dazu:
Pipes don't mean as much as they used to. In the [dual-pipeline] TNT2 days you used to be able to do two pixels in one clock if they were single textured, or one dual-textured pixel per pipe in every two clocks, it could operate in either of those two modes. We've now taken that to an extreme. Some things happen at sixteen pixels per clock. Some things happen at eight. Some things happen at four, and a lot of things happen in a bunch of clock cycles four pixels at a time. For instance, if you're doing sixteen textures, it's four pixels per clock, but it takes more than one clock. There are really 32 functional units that can do things in various multiples. We don't have the ability in NV30 to actually draw more than eight pixels per cycle. It's going to be a less meaningful question as we move forward...[GeForceFX] isn't really a texture lookup and blending pipeline with stages and maybe loop back anymore. It's a processor, and texture lookups are decoupled from this hard-wired pipe.

[Demirug]

Was den Text aus dem TB-00626-001_v01_Shaders_110402.pdf angeht so ist das vollkommen klar was gemeint ist. Ein Texture Sampler ist etwas virtuelles. Dort wird lediglich gespeichert welche Texture mit welchen Filter benutzt wird. Bisher war es nun so das es eine feste zuordnung zwischen Texturkoordinate und Textursampler gab. Also Sampler 1 benutzte immer koordinate 1 der 2 Sampler die 2 Koordinate usw. Diese feste Verbindung wurde jetzt aufgehoben.

Was nun die Aussage von Kirk angeht so bin ich mir noch nicht so ganz sicher was er genau meint.

[Demirug]

Habe gerade bei Digit-Live etwas interesantes zu dem Thema gefunden:

"8 texture filtering units which provides up to 8 fetched and filtered results per tact, but can process (fetch and filter) up to 16 bilinear textures per tact."

[ow]

Heisst das 8 trilineare oder 16 bilineare Samples mit den 8TMUs??

[Demirug]

ow, hört sich für mich so an. Wobei ich davon ausgehe das es bei den bilineare Samples irgendeine Einschrängung gibt sonst hätte man ja eher 16 TMUs geschrieben.

Ich halte es aber nach wie vor für möglich das die TMUs nicht fest mit den Pipelines verbunden sind. Die Idee dazu stamt ja von den angeblich beteiligten 3dfx Leuten. Und gerade in Verbindung mit der neuen Filtermethode macht das auch irgendwie Sinn.

[seahawk]

Kannst Du das bitte erklären.

[Unregistered]

Originally posted by Demirug
ow, hört sich für mich so an. Wobei ich davon ausgehe das es bei den bilineare Samples irgendeine Einschrängung gibt sonst hätte man ja eher 16 TMUs geschrieben.

Ich halte es aber nach wie vor für möglich das die TMUs nicht fest mit den Pipelines verbunden sind. Die Idee dazu stamt ja von den angeblich beteiligten 3dfx Leuten. Und gerade in Verbindung mit der neuen Filtermethode macht das auch irgendwie Sinn.

Leider Wahr der thread closed aber die nv 3dfx matrox ingeneure kommen alle aus der selben ecke und haben sgi Verlassen und eigene Firmen Gegründet also lasst das mal mit 3dfx sonst gibts noch richtig stress ich dachte das hätte man nun hintersich gelassen

[Lost Prophet]

eigetnlich wollt ich nen eigenen thread eröffnen aber da der schon da is.........

ok, bis jetzt hört man zum gffx eher dass er ein 8*1 pipeline sys hat

welcher technische aufwand (kleine änderung, teilweise designveränderungen, oder komplettes Redesign) würde ein wechsel von 8*1 auf 8*2 (r300 & nv30) bzw in weiterer folge von 128 bit auf 256 bit interface ( nv30) nach sich ziehen

da nv ( und auch ATI, aber vor allem nv) dazu neigen ihre "Neuerfindungen" zu refreshen, bzw soll das heißen das uns die nächsten 2 jahre ( bei nv) ein 128 bit 8*1 layout erwartet?? ?? ?? ?? ?? ??


cya axel

[Demirug]

@unreg:

Ich wollte in keiner form gegen 3dfx stänkern. Nur irgendwas in dem neuen Chip ist bestimmt von den ehemaligen Mitarbeiter weil man sie ja sonst nicht für gutes Geld angestellt hätte.

@seahawk:

Das ganze ist erfordert ein umdenken weil es ein komplett anderer Lösungansatz ist.

1. Die TMUs und Pixelshader ALUs besitzen keine direkte zuordnung mehr.

2. Eine Pixelshader ALU arbeitet mit microops. Jede PS-Operation wird vom Treiber oder Chip in diese microops zerlegt und optimiert. Pro Takt kann eine microop ausgeführt werden.

3. Jede ALU bearbeitet immer ein Fragment. Es wird solange geloopt bis alle Microops ausgeführt sind. Trift die ALU auf einen Fetch Befehl werden die Koordinaten und ein paar Steuerinformationen zum TMU-Feld übertragen. Die ALU macht dann mit den nächten microop weiter sollange bis sie auf die Anweisung trift die den gefetchten Wert braucht. Ist der Wert durch das TMU-Feld bereits ermittelt geht es ganz normal weiter ansonsten wird die ALU blockiert bis der Wert zur Verfügung steht.

4. Das TMU-Feld ist mit jeder ALU über eine Bus verbunden. Bei jedem Takt prüft der Samplermanager wie viele TMUs er zu verfügung hat und teilt diese auf die anstehenden Aufträge auf. Das beste Aufteilungsverfahren zu finden dürfte aber sehr aufwendig in der Entwicklung sein. Jedesmal wenn ein Auftrag ausgeführt ist wird das der entsprechenden ALU über den entsprechende Bus gemeldet.

Der Vorteil dieser ganzen Technik ist das man eine viel bessere Auslastung von TMUs und PS ALUs erreichen kann.

[Demirug]

Originally posted by Purple_Stain
eigetnlich wollt ich nen eigenen thread eröffnen aber da der schon da is.........

ok, bis jetzt hört man zum gffx eher dass er ein 8*1 pipeline sys hat

welcher technische aufwand (kleine änderung, teilweise designveränderungen, oder komplettes Redesign) würde ein wechsel von 8*1 auf 8*2 (r300 & nv30) bzw in weiterer folge von 128 bit auf 256 bit interface ( nv30) nach sich ziehen

da nv ( und auch ATI, aber vor allem nv) dazu neigen ihre "Neuerfindungen" zu refreshen, bzw soll das heißen das uns die nächsten 2 jahre ( bei nv) ein 128 bit 8*1 layout erwartet?? ?? ?? ?? ?? ??


cya axel

Ich persönlich denke das die Zeiten in denen man mehr als eine TMU pro Pipeline benutzt vorbei sind. Man wird in Zukunft IMO eher die Anzahl der Pipelines als ganzen erhöhen.

Das 128 Bit Interface dürfte relative leicht auf 256 Bit zu ändern sein. Da ja beim NV30 scheinbar die gesamte Datenkommunikation zwischen dem Speicher und der Arbeitseinheiten entweder über den Cache oder die Compressions/Decompressions einheiten läuft.

[nggalai]

In Waveys GFFX-Interview (http://www.beyond3d.com/previews/nvidia/nv30launch) hatte Geoff Ballew das folgende zu zu sagen:We know that GeForce FX has a total of 8 pixel pipelines running at 500MHz, however how many texture mapping units does it feature per pipeline?

Well, as we move into programmable shading the old conventions of fixed pipelines are becoming less important and less accurate, so with that caveat let me go back and answer your question.

We have 8 pipelines and they can each apply one texture per clock so we can apply 8 textures per clock.

Does that apply for both FP32 (128-bit) as well as FP16 (64-bit)? For example can FP16 do two texture reads per clock?

No, you're limited to 8 textures applied per clock. However, we can do addressing for 16 textures at any one time. So even though you can only rigidly apply 8 per clock, you can line up the next 8 then apply them in the next clock. So that level of flexibility is very important as we move to procedural shading and sophisticated shader programs, so they key thing is how many textures can you queue up and address and how quickly can you apply them in a shader program.

Kirk hat sich auch geweigert, von "TMUs" zu sprechen.

ta,
-Sascha.rb

[zeckensack]

Sind wir uns halbwegs einig, daß im Moment massiv Blendwerk für den 'average Joe' unterwegs ist, aber Leute die halbwegs von der Materie Ahnung haben kaum verwertbare Infos bekommen können?

[Demirug]

Langsam glaube ich das Teil hat gar keine TMUs. Und das Filtern wird von den ALUs gemacht. Das würde einige Dinge erklären.

[zeckensack]

Originally posted by Demirug
Langsam glaube ich das Teil hat gar keine TMUs. Und das Filtern wird von den ALUs gemacht. Das würde einige Dinge erklären. Das widerum glaube ich auch nicht.

Float-Texturen muß man selbst filtern, das hatten wir schon. Das heißt dann, daß der Filter nicht 'automatisch' ins Shader-Programm eingefügt wird.

Bei Integer-Texturen gibt's diese Einschränkung aber AFAIK nicht, also gehe ich davon aus daß es schon noch Hardware für Texturfilter gibt (die halt nur für Integerformate gedacht sind). Das würde ich btw - FP hin oder her - immernoch als TMUs bezeichnen. Frage: Wieviele? ;)

Die Anzahl der Texturkoordinaten (=> Interpolatoren) liegt bei 8. Aber das ist ja leider was ganz anderes ...

[Demirug]

Originally posted by zeckensack
Float-Texturen muß man selbst filtern, das hatten wir schon. Das heißt dann, daß der Filter nicht 'automatisch' ins Shader-Programm eingefügt wird.

Bei Integer-Texturen gibt's diese Einschränkung aber AFAIK nicht, also gehe ich davon aus daß es schon noch Hardware für Texturfilter gibt (die halt nur für Integerformate gedacht sind). Das würde ich btw - FP hin oder her - immernoch als TMUs bezeichnen. Frage: Wieviele? ;)

Folgend Überlegung:

Zu erzeugen eines Integer Bi-Sample werden 4 Farbwerte a 32 bit und mindestens 2 Gewichtungsfaktoren benötigt.

Zu erzeugen eines Integer Tri-Sample werden 8 Farbwerte a 32 bit und mindestens 3 Gewichtungsfaktoren benötigt.

Das ergebniss ist in beiden fällen ein fertig gesampelter Texturewert. Wenn man nun 4 Texturwerte als 128 Bit wert in die PS ALU lädt und die ALU entsprechend aufgebaut ist könnte sie diese 4 bzw 8 bei tri Texturwerte zum Samplewert verechnen. Der Vorteil dabei wäre das man eine solche ALU sicher mit weniger Transitoren als eine "normale" ALU + TMU bauen könnte.

Die Anzahl der Texturkoordinaten (=> Interpolatoren) liegt bei 8. Aber das ist ja leider was ganz anderes ...

Ja da gibt es keinen Zusammenhang

[Unregistered]

Originally posted by Demirug
Habe gerade bei Digit-Live etwas interesantes zu dem Thema gefunden:

"8 texture filtering units which provides up to 8 fetched and filtered results per tact, but can process (fetch and filter) up to 16 bilinear textures per tact."

Für den Laien;

heißt das dann nun, das die NV30 "nur" 8 Trilinear gefilterte Pixel/Takt schafft und damit nur 4 16tap-anisotropic gefilterte, während der R300 8 16tap-anisotropic gefilterte Texturen schafft?

Würde ja heißen die AF speed ist wieder schlechter als bei ATi????

[Demirug]

Originally posted by Unregistered


Für den Laien;

heißt das dann nun, das die NV30 "nur" 8 Trilinear gefilterte Pixel/Takt schafft und damit nur 4 16tap-anisotropic gefilterte, während der R300 8 16tap-anisotropic gefilterte Texturen schafft?

Würde ja heißen die AF speed ist wieder schlechter als bei ATi????

Nein so ist das nicht zu verstehen. Die Art und Anzahl der TMUs geben lediglich an wie viele Grundwerte pro Takt verrechnet werden können.

Bei BI-TMUs können 4 Werte verrechnet werden. TRI-TMUs können 8 Werte verrechnen. Möchte man nun einen Filter benutzten der mehr Grundwerte benötig müssen die TMUs im Loopback betrieben werden. Das führt dann dazu das mehr als ein Takt pro Textursample benötigt wird.

Von der Grundvoraussetzung haben sowohl der R300 wie auch der NV30 (soweit man den Berichten glauben darf) die fähigkeit 8*8 Werte pro Takt zu 8 Sampels zu verarbeiten. Der Unterschied in der Geschwindigkeit kann sich also nur durch den Takt und die Optimierungsmethode ergeben. Zu der Methode beim R300 wurde ja schon einiges gesagt und von dem neuen NVIDIA Verfahren gibt es noch keine Details.

[Unregistered]

Originally posted by Demirug


Nein so ist das nicht zu verstehen. Die Art und Anzahl der TMUs geben lediglich an wie viele Grundwerte pro Takt verrechnet werden können.

Bei BI-TMUs können 4 Werte verrechnet werden. TRI-TMUs können 8 Werte verrechnen. Möchte man nun einen Filter benutzten der mehr Grundwerte benötig müssen die TMUs im Loopback betrieben werden. Das führt dann dazu das mehr als ein Takt pro Textursample benötigt wird.

Von der Grundvoraussetzung haben sowohl der R300 wie auch der NV30 (soweit man den Berichten glauben darf) die fähigkeit 8*8 Werte pro Takt zu 8 Sampels zu verarbeiten. Der Unterschied in der Geschwindigkeit kann sich also nur durch den Takt und die Optimierungsmethode ergeben. Zu der Methode beim R300 wurde ja schon einiges gesagt und von dem neuen NVIDIA Verfahren gibt es noch keine Details.

OK, dann habe ich das schon richtig verstanden. Der R300 kann aber 8x16 Werte pro Takt miteinander verrechnen. Da ist jede Pipeline in der Lage 1 6Werte pro Takt zu 8 Pixeln / Samples zu verarbeiten. Ist also unter bestimmten Bedingungen wirklich doppelt so schnell wie die NV30 ( Pro Takt/MHz ). WOW

[Demirug]

Originally posted by Unregistered


OK, dann habe ich das schon richtig verstanden. Der R300 kann aber 8x16 Werte pro Takt miteinander verrechnen. Da ist jede Pipeline in der Lage 1 6Werte pro Takt zu 8 Pixeln / Samples zu verarbeiten. Ist also unter bestimmten Bedingungen wirklich doppelt so schnell wie die NV30 ( Pro Takt/MHz ). WOW

Wie kommst du den auf die Rechnung???

Der R300 hat pro Pipeline eine Tri TMU er kann also aus 8 Texturen jeweils 8 Werte verrechen. Das entspricht nach derzeitigem wissensstand der Leistung des NV30.

[zeckensack]

Originally posted by Unregistered


OK, dann habe ich das schon richtig verstanden. Der R300 kann aber 8x16 Werte pro Takt miteinander verrechnen. Da ist jede Pipeline in der Lage 1 6Werte pro Takt zu 8 Pixeln / Samples zu verarbeiten. Ist also unter bestimmten Bedingungen wirklich doppelt so schnell wie die NV30 ( Pro Takt/MHz ). WOW Nö :D

Der Chip kann 16 Texturen pro Pass, das kann der NV30 aber wohl auch (Voraussetzung für PS2.0).
Vielleicht hast du da was verwechselt ???

[Börk]

Originally posted by Demirug


Wie kommst du den auf die Rechnung???

Der R300 hat pro Pipeline eine Tri TMU er kann also aus 8 Texturen jeweils 8 Werte verrechen. Das entspricht nach derzeitigem wissensstand der Leistung des NV30.

Heißt des dann, dass der R300 sowie der NV30 beim einsatzt von AF nur noch die halbe Füllrate besitzt???
Weil wenn die TMUs nur tri filtern können, brauchen sie ja 2 passes für AF.
Dann theoretisch müsste es ja einen enormen leistungs vorteil für bilneares AF geben, wie´s in der Praxis ja nicht vorkommt.

[Demirug]

Ja die Texelfüllrate verringert sich mit zunehmendem AF Level. Da aber ja nicht alle Samples immer mit dem maximalen Level erzeugt werden kann man diese Rechnung nicht so pauschal aufstellen.

Ob nun bi AF schneller als Tri AF ist hängt vom Aufbau des Textursamplers und der frage ob das Sampeln der limitierenden Punkt in der Pipeline ist ab. Kann eine Tri-TMU nur jeweils 4 Werte von der gleichen Position aus 2 Ebenen der Mip-Map zu verrechnen wird sie bei bi AF keinen Leistungsgewinn erzielen können den dort müssten zweimal 4 Werte von 2 Stellen in einer Ebene der Mip-Map geholt werden. Das bi af könnte in diesem Fall nur zu einer besseren Leistung führen wenn das tri-af Bandbreiten Probleme verursacht.

[Unregistered]

Hi;

der R300 kann, lt. einem ATi-Mitarbeiter, der das auf Beyond3d gepostet hat (sorry kein Link) max. 4 bilinear gefilterte Samples pro Pipeline rendern. Ausgeben kann es natürlich nur 1 Pixel/Pipeline und Zyklus. Jede Pipeline kann also ein anisotropic gefiltertes Pixel/Takt ausgeben.

[Börk]

Originally posted by Unregistered
Jede Pipeline kann also ein anisotropic gefiltertes Pixel/Takt ausgeben.
Hab ichs mir doch gedacht.
Also wirds der NV30 auch können.

[Demirug]

Originally posted by Unregistered
Hi;

der R300 kann, lt. einem ATi-Mitarbeiter, der das auf Beyond3d gepostet hat (sorry kein Link) max. 4 bilinear gefilterte Samples pro Pipeline rendern. Ausgeben kann es natürlich nur 1 Pixel/Pipeline und Zyklus. Jede Pipeline kann also ein anisotropic gefiltertes Pixel/Takt ausgeben.

AFAIK und da geben mir auch die Previews vom R300 recht kann der Chip aber nur 2 bi Samples pro takt pro Pipe erzeugen.

[Unregistered]

Originally posted by Demirug


AFAIK und da geben mir auch die Previews vom R300 recht kann der Chip aber nur 2 bi Samples pro takt pro Pipe erzeugen.

hier ist ein Link:
http://www.beyond3d.com/forum/viewtopic.php?t=2326&start=0&postdays=0&postorder=asc

Allerdings nicht von einem ATi-Mitarbeiter. Chalnoth ist ein Nvidia-Fan, kennst sich aber meistens gut aus. Ich versuche auch noch das originale Posting von dem ATi-Mitarbeiter zu finden.

[egdusp]

Bedeutet der evtl. Verzicht auf klassische TMUs, dass die AA Handicaps des NV30, wie sie Aths in seinem GFFX AA Artikel beschrieben hat, nicht zutreffen?

dort hatte er moniert, dass bei den neuen AA Varianten 6Xs und 8x einige Samples pro Pipeline verfallen.

mfg
egdusp

[aths]

Originally posted by egdusp
Bedeutet der evtl. Verzicht auf klassische TMUs, dass die AA Handicaps des NV30, wie sie Aths in seinem GFFX AA Artikel beschrieben hat, nicht zutreffen?

dort hatte er moniert, dass bei den neuen AA Varianten 6Xs und 8x einige Samples pro Pipeline verfallen.Das eine hat mit dem anderen wenig zu tun. Die TMU ist ja für das Pixel, und nicht das Subpixel da. Die AA-Samples werden von der Pipeline erzeugt, die eine Pixelfarbe für alle Samples innerhalb des Polygons von der TMU.

[Demirug]

Originally posted by Unregistered


hier ist ein Link:
http://www.beyond3d.com/forum/viewtopic.php?t=2326&start=0&postdays=0&postorder=asc

Allerdings nicht von einem ATi-Mitarbeiter. Chalnoth ist ein Nvidia-Fan, kennst sich aber meistens gut aus. Ich versuche auch noch das originale Posting von dem ATi-Mitarbeiter zu finden.

Chalnoth scheint mir überzeugt von seiner Idee zu sein. Das Problem ist das ich bisher noch keine Bestätigung aus einer zweiten Quelle gefunden habe. Möglich wäre es natürlich denoch.

[zeckensack]

Originally posted by aths
Das eine hat mit dem anderen wenig zu tun. Die TMU ist ja für das Pixel, und nicht das Subpixel da. Die AA-Samples werden von der Pipeline erzeugt, die eine Pixelfarbe für alle Samples innerhalb des Polygons von der TMU. Ich glaube da wirfst du die Begriffe etwas durcheinander.

Die 'TMU' ist Teil der Pixelpipe. Die Farben der Subpixel sind ja nicht nur rohe Textursamples, sondern eben das fertige Produkt der Pixelpipe/Combiner/wieauchimmermandasnennenwill.

[ow]

Originally posted by Demirug


Chalnoth scheint mir überzeugt von seiner Idee zu sein. Das Problem ist das ich bisher noch keine Bestätigung aus einer zweiten Quelle gefunden habe. Möglich wäre es natürlich denoch.


In Anbetracht der Leistungen unter verschiedenen Filtermodi (bi, tri, aniso) auf der R9700 scheint mir das eher ausgeschlossen.
Oder der Engpass sitzt sonst irgendwo, was dann den Vorteil der TMU-Moeglichkeiten wieder komplett auffrisst (s.a Gf2 und 32Bit;)).

[Demirug]

Originally posted by ow
In Anbetracht der Leistungen unter verschiedenen Filtermodi (bi, tri, aniso) auf der R9700 scheint mir das eher ausgeschlossen.


Sehe ich ähnlich weil ja in allen Previews die was zu den TMUs vom R300 Chip sagten immer nur was von Tri-TMUs geschrieben wurde.

[aths]

Originally posted by zeckensack
Ich glaube da wirfst du die Begriffe etwas durcheinander.

Die 'TMU' ist Teil der Pixelpipe. Die Farben der Subpixel sind ja nicht nur rohe Textursamples, sondern eben das fertige Produkt der Pixelpipe/Combiner/wieauchimmermandasnennenwill. AA-Samples werden trotzdem nicht von der TMU (und Combiner etc.) erzeugt :) Eine Lösung der TMU von der Pipeline, wie beim NV30 vermutet, hat auf die Subpixelmaske keine Auswirkung.