Wie viel Speicher (On Die) hat der NV25?

[Demirug]

Eingien dürften diese Dokument schon gesehen haben:

http://vlsicad.ucsd.edu/~abk/TALKS/dac2002_session26_malachowsky.pdf

Auf Seite 4 findet man nun die Angabe das 20% des Chips (20% of die)aus Speicher bestehen.

Die Frage die nicht entgültig geklärt wird ist ob sich die 20% auf die Fläche oder die Transitoren Anzahl beziehen.

Falls es die Transitoren sind so komme ich bei 12,6 Mio Transitoren für den Speicher. Gehen wir nun von 6T-SDRAM aus haben wir 2,1 Mio Speicherzellen. Was dann 268,8 KB Speicher ergibt.

Falls es um die Fläche geht bräuchte ich erst mal eine angabe wie gross der DIE überhaut ist. Hat die gerade jemand zur Hand? Jedenfalls kommt eine 6T-SDRAM Zelle bei TSMC in 0,15 auf 3,42µm².

[micki]

interresanter wäre es zu wissen wofür die verbraucht werden, z.B. wie bei ATI für einen komprimierten z-buffer,für caches von vertices, oder einfach nur für texturen.


wenn man vom DIE spricht, dann würde ich auf fläche tippen, wobei der unterschied zwischen transistoren und fläche nicht sonderlich gross sein sollte.

und mit einer aussage ~256kB kann ich leben &rechnen :)

irgendwo (ich glaube auf nvidias seite) war mal ein paper in dem verschieden dinge gebencht wurden wie z.B. optimale vertex-size, vertexbuffer-size, texture-size... darin konnte man sehen dass 256KB texturen die beste performance lieferten. das könnte jetzt ja ein HINT sein ;D

MfG
micki

[Endorphine]

Wer sagt denn, dass es sich um DRAM handelt - ich würde eher sagen, dass SRAM verwendet wird. Dann ändert sich das Verhältnis Transistor:Speicherzellen schon deutlich.

[Demirug]

Originally posted by Endorphine
Wer sagt denn, dass es sich um DRAM handelt - ich würde eher sagen, dass SRAM verwendet wird. Dann ändert sich das Verhältnis Transistor:Speicherzellen schon deutlich.

Ich habe doch mit 6T-SRAM gerechnet.

[StefanV]

Originally posted by Endorphine
Wer sagt denn, dass es sich um DRAM handelt - ich würde eher sagen, dass SRAM verwendet wird. Dann ändert sich das Verhältnis Transistor:Speicherzellen schon deutlich.

???

DRAM in eine logische Schaltung einzufügen ist nicht ganz einfach, da man kapazitätsreiche Prozesse mit kapazitätsarmen Prozessen verbinden muss.

[Endorphine]

Originally posted by Stefan Payne
???

DRAM in eine logische Schaltung einzufügen ist nicht ganz einfach, da man kapazitätsreiche Prozesse mit kapazitätsarmen Prozessen verbinden muss.??? Ich hab doch gesagt, dass wohl eher SRAM verwendet wird. Dass es sich bei dem "SDRAM" von Demi eher um einen Schusselfehler handelt haben wir ja nun schon rausgefunden...

[zeckensack]

Demirug,

NV25 beherrscht paletted textures in hardware und single-cycle, das sind in einer naiven Implementierung nochmal 4 Pipes*2 Sampler*4 Texel (bilinear for free)*768 Bytes (Größe der LUT) = 24kiB Speicher.

Alternativ weniger SRAM, dafür mit vielen schnellen read ports.

Nochmal alternativ wird die Textur 'dekodiert', sobald sie in den Texturcache geladen wird.

Sind die 12,6Mios ein Block, oder ist da eine Verteilung über den Chip ersichtlich?

[Endorphine]

Originally posted by zeckensack
Sind die 12,6Mios ein Block, oder ist da eine Verteilung über den Chip ersichtlich? Es sind aus meiner Sicht nicht mal sicher 12,6 M, sondern "Memory: 20% of die". Also Diefläche. Und auf dem Bild kann man mangels Auflösung kaum ausmachen, was was sein soll (in dem Dokument nur minimal besser als auf meinem Screenshot).

[Demirug]

Originally posted by zeckensack
Demirug,

NV25 beherrscht paletted textures in hardware und single-cycle, das sind in einer naiven Implementierung nochmal 4 Pipes*2 Sampler*4 Texel (bilinear for free)*768 Bytes (Größe der LUT) = 24kiB Speicher.

Alternativ weniger SRAM, dafür mit vielen schnellen read ports.

Nochmal alternativ wird die Textur 'dekodiert', sobald sie in den Texturcache geladen wird.

Sind die 12,6Mios ein Block, oder ist da eine Verteilung über den Chip ersichtlich?

mhm für Paletted Textures braucht man doch eigentlich vor den TMU eingängen noch eine Stufe welche den FarbIndex in den richtigen Farbwert umsetzt. Den Speicher für die Palette würde ich dann vom Texturecache abzweigen. Aber das Dekodieren beim laden hat auch was für sich.

wie Endorphine schon sagt kann man das nicht wirklich erkennen. Ich tippe mal auf einen grossen Block bei den Memorycontrollern und dann noch ein paar kleinere Blöcke (Post Vertex Cache, Primitive und Pixel-FIFOs, ...) im Chip verteilt.

[StefanV]

@Demi

Braucht man nicht viel Cache vorm Mem Controller, wenn man ein echtes Async Design design ??

Wenn man es nicht täte, würde der Chip dann nicht an Leistung verlieren, wenn man Chip und Speicher asynchron takten würde ??

[Demirug]

Originally posted by Stefan Payne
@Demi

Braucht man nicht viel Cache vorm Mem Controller, wenn man ein echtes Async Design design ??

Wenn man es nicht täte, würde der Chip dann nicht an Leistung verlieren, wenn man Chip und Speicher asynchron takten würde ??

Nicht unbedingt da ja mehr oder minder alle Speicherzugriffe sowieso über irgendwelche zwischenspeicher laufen müssen brauchen diese Speicher auf der Seite zum Speichercontroller eben I/O-Ports welche mit der Taktrate des RAMs arbeiten können.

Ich würden den grössten Block bei den Speichercontroller positionieren weil man in dann für alles benutzten kann. Immer so wie es die Situation erfordert. Zum Beispiel braucht man bei einem Z-Pass ja keinen Cachespeicher für Texturen oder den Framebuffer sondern nur Z-Werte.

[zeckensack]

Originally posted by Demirug
mhm für Paletted Textures braucht man doch eigentlich vor den TMU eingängen noch eine Stufe welche den FarbIndex in den richtigen Farbwert umsetzt. Den Speicher für die Palette würde ich dann vom Texturecache abzweigen. Aber das Dekodieren beim laden hat auch was für sich. Jau, schon klar. Paletten sind aber nunmal pre-filtering, deswegen muß man für jedes Quelltexel den Lookup getrennt ausführen.

Ich hab's nur erwähnt, weil es IMO auch sehr viel SRAM fressen kann, je nachdem wie's implementiert ist.

[Demirug]

Originally posted by zeckensack
Jau, schon klar. Paletten sind aber nunmal pre-filtering, deswegen muß man für jedes Quelltexel den Lookup getrennt ausführen.

Ich hab's nur erwähnt, weil es IMO auch sehr viel SRAM fressen kann, je nachdem wie's implementiert ist.

Letzende endes aber eigentlich nicht mehr als wenn man die Texture gleich als 32 Bit Texture gespeichert hätte. Ausser bei einer ganz kleinen Texture möglicherweise.

AFAIR hat NVIDIA auch mal die Empfehlung herausgegeben Paletted Textures als Mittel zum Sparen von Speicherplatz zu nutzten. Ich weis aber jetzt nicht mehr für welche Chips diese Empfehlung war. Aber sicherlich nicht mehr für den NV25.

[ow]

Originally posted by Demirug

AFAIR hat NVIDIA auch mal die Empfehlung herausgegeben Paletted Textures als Mittel zum Sparen von Speicherplatz zu nutzten. Ich weis aber jetzt nicht mehr für welche Chips diese Empfehlung war. Aber sicherlich nicht mehr für den NV25.

Aber sicher für irgendeinen GF-Chip, denn die TNTs haben keinen HW-Support für paletted textures.

[Demirug]

Originally posted by ow


Aber sicher für irgendeinen GF-Chip, denn die TNTs haben keinen HW-Support für paletted textures.

So ich habe das ganze mal rausgesucht. Das erste mal taucht dieses Sache in den Optimize Guides für den NV10 auf. Vorher hätte es für NVIDIA wie du schon sagst keinen Sinn gemacht. Bis heute wurde das auch nicht aus dem Guides entfernt. Es wird aber immer erwähnt das normale Texturekompression vorzuziehen ist und man die paletted texturen nur Benutzten soll wenn die normale kompression nicht zu gebrauchen weil man auf genaue Werte angewissen ist (normal map).

[Xmas]

Ich gehe sehr stark davon aus dass paletted Textures vor dem Cache realisiert werden. Ebenso wie höchstwahrscheinlich die Texturdekompression bei NVidia. Dafür braucht man zwar viel Cache, aber spart dafür an anderer Stelle deutlich an Transistoren.