FX-5900 Nachfolger noch 2003

[Mr. Anderson]

Obwohl NV FX 5900 noch nicht richtig im Laden steht,ist der Nachfolger bereits fast fertig.
Der NV 40 soll eine revolutionäre Neuerung enthalten: Direkt im mit 350 Millionen Transistoren extrem komplexen Grafikchip sollen 16 Mbyte High-Speed-Speicher stecken.
Der dürfte die Performance dramatisch erhöhen - die Speicheranbindung ist schließlich immer noch der Flaschenhals.
Chip-und Speicher dürften mit 800/1.400 MHz laufen.
Dementsprechend schaufelt die Speicheranbindung bis zu 44.8 GByte/s.
Release Herbst 2003

PS. Ich denke NV wird alles daran setzen die Krone zurück zu erobern - gut so:D

[betasilie]

Kannst Du deine suspekte Behauptung mal mit einer Quelle belegen! :|

´Ist nicht das erste mal, dass Du irgendwelche tollen Infos postest, ohne eine Quelle anzugeben.

[Dunkeltier]

Quelle? Oder nur ausgedacht?

[Demirug]

Macht hier weiter. *move*

[Winter[Raven]]

kann es sein das diese Daten aus der LAMER Zeitschrieft GAMESTAR stammen ?

[ActionNews]

...die sich auch nur auf ein Gerücht beriefen, dass sich als Fake herausgestellt hat?

CU ActionNews

[mRofsimpsOn]

genau diese informationen mi dem integriertem 16 Mbyte speicher sind schonmal vor einiger zeit aufgetaucht ... allerdings als im der luft stehndes gerücht ..

so wird es hier nicht anders sein ....

wenn nvidia noch dieses jahr den neuen chip rausbringt bedeutet das , dass nvidia 2 entwicklugstemas hat .. das eine hat die FX reihe gebaut .. das andere parallel den neuene NV40 .. ansonsten könnte das nvidia garnich bewerkstelligen

[Gil-galad]

Original geschrieben von Mr. Anderson
Der NV 40 soll eine revolutionäre Neuerung enthalten: Direkt im mit 350 Millionen Transistoren extrem komplexen Grafikchip sollen 16 Mbyte High-Speed-Speicher stecken.

Das mit embedded RAM bezweifel ich doch stark. 350 Millionen Transistoren sind meiner Meinung nach mit dem 0,13µm Prozess nicht zu schaffen, vorallem wenn der Chip mit 800 MHz laufen soll. Ich denke mit embedded RAM ist frühestens beim NV50/R500 zu rechnen. Und dann wird sicher auch schon der 0,09µm Prozess zur Verfügung stehen.

PS: BitBoys wollten auch embedded RAM verwenden. Allerdings hat Infineon, die das fertigen sollten, das Projekt aufgegeben, da es einfach zuviel Ausschuss gab.

[Exxtreme]

Ausserdem kann man hohe AA-Stufen mit nur 16 MB Framebuffer von vorneherein knicken.

[robbitop]

nicht wenn man eine adaptive Verlustbehaftete Kompression verwendet, dessem Auswirkung für das Menschliche Auge nicht zu sehen ist.

Naja eDRAM wird kommen aber nicht gleich in solchen Mengen.
Muss ja auch nicht gleich der Framebuffer sein

[Exxtreme]

Original geschrieben von robbitop
nicht wenn man eine adaptive Verlustbehaftete Kompression verwendet, dessem Auswirkung für das Menschliche Auge nicht zu sehen ist.

Verlustbehaftete Kompression kannst du hier wirklich schlecht anwenden, da kannst du gleich verlustlose Kompression nehmen.

[Gast]

Lossy Compression geht schon, aber nur beim Framebuffer. Beim Z-Buffer ist es tödlich. 16MB reichen aber trotzdem nicht. Außerdem würde es nur Sinn machen den Z-Buffer in das eDRAM zu packen, da der immer noch die meiste Bandbreite braucht (und man dann den ganzen EarlyZ-Schrott, der so viele Transistoren frisst und trotzdem nicht richtig funktioniert wegschmeißen könnte).

[robbitop]

afair brauchte der FB am meisten Bandbreite beim AA. kann mich irren

aber Gast kannst du eine Äusserungen evl vertiefen/erläutern?

klingt imo sehr interessant

[Exxtreme]

Original geschrieben von Gast
Lossy Compression geht schon, aber nur beim Framebuffer. Beim Z-Buffer ist es tödlich. 16MB reichen aber trotzdem nicht. Außerdem würde es nur Sinn machen den Z-Buffer in das eDRAM zu packen, da der immer noch die meiste Bandbreite braucht (und man dann den ganzen EarlyZ-Schrott, der so viele Transistoren frisst und trotzdem nicht richtig funktioniert wegschmeißen könnte).
Der Vorteil einer verlustbehafteten Kompression ist, daß man eine definierte Kompressionsrate hat. Leider hat man keine definierte Bildqualität mehr. Wenn die Szene "ungünstig" ist, dann bekommt man u.U. sehr starke Kompressionsartefakte.

[Demirug]

Original geschrieben von Gast
Lossy Compression geht schon, aber nur beim Framebuffer. Beim Z-Buffer ist es tödlich. 16MB reichen aber trotzdem nicht. Außerdem würde es nur Sinn machen den Z-Buffer in das eDRAM zu packen, da der immer noch die meiste Bandbreite braucht (und man dann den ganzen EarlyZ-Schrott, der so viele Transistoren frisst und trotzdem nicht richtig funktioniert wegschmeißen könnte).

Selbst wenn der komplette Z-Buffer im Chip liegt braucht man immer noch Early-Z um sich sonst unnötig verschwendetet Fillrate zurückzuholen.

[robbitop]

war nicht Hirarchial Z zum Sparen von Füllrate nötig?

[Demirug]

Original geschrieben von robbitop
afair brauchte der FB am meisten Bandbreite beim AA. kann mich irren

aber Gast kannst du eine Äusserungen evl vertiefen/erläutern?

klingt imo sehr interessant

Solange der Z-Buffer und der Framebuffer die gleiche grösse haben und beide mit vergleichbaren Verfahren (was die Kompressionrate angeht) arbeiten braucht der Z-Buffer tendenziel mehr Bandbreite. Es lassen sich natürlich auch Situationen erzeugen wo es anders ist.

[Demirug]

Original geschrieben von Exxtreme
Der Vorteil einer verlustbehafteten Kompression ist, daß man eine definierte Kompressionsrate hat. Leider hat man keine definierte Bildqualität mehr. Wenn die Szene "ungünstig" ist, dann bekommt man u.U. sehr starke Kompressionsartefakte.

Ich glaube du bringst da was durcheinader. Es gibt durchaus auch verlustbehafteten Kompression mit variabler Kompressionrate aber dafür einer definierten Bildqualität.

[Demirug]

Original geschrieben von robbitop
war nicht Hirarchial Z zum Sparen von Füllrate nötig?

Ja, man kann aber auch Bandbreite damit einsparen.

[Exxtreme]

Original geschrieben von Demirug
Ich glaube du bringst da was durcheinader. Es gibt durchaus auch verlustbehafteten Kompression mit variabler Kompressionrate aber dafür einer definierten Bildqualität.
Ich weiss.

Dann hat man aber den Vorteil der definierten Kompressionsrate verschenkt. Und dann muss man den gesamten Speicher vorhalten denn es kann der Fall auftreten, daß die Kompressionsrate = 0 ist. Und dann kann man gleich lossless compression nehmen.

[Demirug]

Original geschrieben von Exxtreme
Ich weiss.

Dann hat man aber den Vorteil der definierten Kompressionsrate verschenkt. Und dann muss man den gesamten Speicher vorhalten denn es kann der Fall auftreten, daß die Kompressionsrate = 0 ist. Und dann kann man gleich lossless compression nehmen.

Wenn die minimale Kompressionrate = 0 ist dann hat man ja ein lossless verfahren. Variable Kompressionrate heist das die minimale Kompressionrate > 0% ist. Dafür kann es dann aber wie du sagst Artefakte geben. Und dann gibt es natürlich auch noch die Verfahren die eine feste Kompressionrate haben wie zum Beispiel Z3.

[Gast]

Lol, diese Karte bräuchte bestimmt einen Staubsaugermotor mit Lüfter um die zu kühlen.

[Nedo]

wenn ich schon diese mordstakte sehe, wird mir so schlecht wie wenn ich an die fx5800 denk.
wenn der nv40 genauso floppt, dann lach ich.. :D

[robbitop]

ich muss sagen, mir gefällt eine so grosse Karte...sie strahlt irgendwie Power aus :D

[Quasar]

Power im Sinne von Wärmeenergie? ;-)

Nein, mal im Ernst. Es würde schon Sinn machen, den Z-Buffer (und damit auch den Stencil-Buffer on-chip und damit quasi beliebig breit à la PS2 anzubinden.
Das war ja damals auch meine Idee, als die ersten Gerüchte um 16MB on-die auftauchten.

Ob es jedoch mit 0,13µ und 350MTransistoren zu realisieren ist, glaube ich eher nicht.

Aber ein Z/Stencil-Buffer quasi for free, was die restliche Bandbreite angeht wäre schon schön, gerade angesichts von D3, 3DM03 und was da sonst noch alles kommt.

[Demirug]

Original geschrieben von Quasar
Power im Sinne von Wärmeenergie? ;-)

Nein, mal im Ernst. Es würde schon Sinn machen, den Z-Buffer (und damit auch den Stencil-Buffer on-chip und damit quasi beliebig breit à la PS2 anzubinden.
Das war ja damals auch meine Idee, als die ersten Gerüchte um 16MB on-die auftauchten.

Ob es jedoch mit 0,13µ und 350MTransistoren zu realisieren ist, glaube ich eher nicht.

Aber ein Z/Stencil-Buffer quasi for free, was die restliche Bandbreite angeht wäre schon schön, gerade angesichts von D3, 3DM03 und was da sonst noch alles kommt.

Also wenn schon onChip Speicher dann doch bitte als allgemein verwendbarer Cache zwischen dem Logikteil des Chips und dem echten Speicher.

Aber mal ganz im Vertrauen macht es wirklich Sinn die hälfte der Chipfläche für Speicher zu verbraten? Da macht es IMHO doch viel mehr Sinn noch ein paar Logikeinheiten mehr zu verbauen. Je komplexer die Shader ja werden desto weniger wichtig wird Bandbreite.

[-error-]

LOL! 350 Millionen Transistoren??? Ist derzeit garnicht machbar
Und ich glaube nicht das Nvidia wieder so hoch takten wird, dass das nichts ist haben die selbst gelernt.

[Ailuros]

Ich persoenlich schaetze an die 150+M Transistoren und =/<29GB/sec Bandbreite.

Es gibt uebrigens immer noch tonnenweise Loesungen bandwidth-requirements zu reduzieren und hiermit die verfuegbare Bandbreite zu erhoehen. Uebrigens sehen alle heutigen ultra high end chips danach aus als ob sie mehr Fuellraten als Bandbreiten-hungrig sind.

Hier macht es eher Sinn IMHO, die Taktrate ueber 500MHz zu erhoehen, selbst wenn Bandbreite immer noch bei ~25GB/sec bleibt.

[Quasar]

Original geschrieben von Demirug
Also wenn schon onChip Speicher dann doch bitte als allgemein verwendbarer Cache zwischen dem Logikteil des Chips und dem echten Speicher.

Aber mal ganz im Vertrauen macht es wirklich Sinn die hälfte der Chipfläche für Speicher zu verbraten? Da macht es IMHO doch viel mehr Sinn noch ein paar Logikeinheiten mehr zu verbauen. Je komplexer die Shader ja werden desto weniger wichtig wird Bandbreite.

Allgemeiner Cache wäre IMO ineffizient, da nicht so gut auf die verschiedenen Zugriffsmuster optimiert werden könnte, ausserdem würden sich verschiedene Einheiten mal wieder den Zugriff teilen müssen.

Ferner hätte ein separater und verteilt platzierter Cache dieser Größenorndung den Vorteil, dass er, je nach Granularität, auch sehr gut zur Verteilung der Hotspots beitragen könnte.

Mehr Logikeinheiten wären zwar die bessere Alternative, aber ich glaube, in der Masse wären sie schwierig zu realisieren, da ja meist nur eine Verdoppelung der Pipelines etwas bringt (und du selbst erwähntest, dass ein x*2x Design nicht so effizient wäre).

[Exxtreme]

Original geschrieben von Quasar
Allgemeiner Cache wäre IMO ineffizient, da nicht so gut auf die verschiedenen Zugriffsmuster optimiert werden könnte, ausserdem würden sich verschiedene Einheiten mal wieder den Zugriff teilen müssen.

Beide Cache-Strategien haben Vor- und Nachteile. Ein großer, allgemeiner Cache hat auch Vorteile. Wenn er sehr groß ist, dann kann man die Wahrscheinlichkeit minimieren, daß es zu Cache-Misses kommt und man entlastet das RAM-Interface.

Ein Nachteil eines großen, allg. Caches ist, daß er vlt. etwas langsamer ist, als ein kleinerer, spezialisierter Cache ist und wenn viele Einheiten drauf kurz hintereinander zugreifen, dann kann es doch zu Cache-Misses kommen, da die verschiedenen Einheiten den Cache jeweils wieder überschreiben. Diesem Effekt kann man entgegenwirken durch eine bessere Anordnung der Daten/Anweisungen.

[Morbid Angel]

Also ich habs in der PC Praxis gelesen im September NV 40

Naja dann wiegt sone Grafikkarte 3 kg wegen nem MONSTER Lüfter :D

[ShadowXX]

Original von Morbid Angel:
Also ich habs in der PC Praxis gelesen im September NV 40


damit meinen Sie nur die Vorstellung der Karte...wie lange es dauern kann bis Sie dann auch verfügbar ist, konnte man am nv30 sehen;D

Im Ernst: Sie werden sie wohl im September/Oktober vorstellen, aber die (Massen-)Verfügbarkeit ist wohl erst im 1.Quartal '04.

J.S.Shadow

[The Jackal]

Mir kommt das ein wenig komisch vor.

IBM hat in seinem neuestem Server Chip so weit ich weiß gerade mal 3 MB 3 Level Cache und da soll dann NV 16 MB im Chip realisieren.

:crazy:

[Winter[Raven]]

wie lange es dauern kann bis Sie dann auch verfügbar ist, konnte man am nv30 sehen

Also, so arrogante aussagen hab ich noch nie erlebt, nur weil sich der NV30 verspätet hatt heißt das nicht das man das jetzt auf alle NV Chips übertragen kann.

[robbitop]

@Jackal
in CPUs ist SRAM Vorhanden, dieser benötigt weitaus mehr schaltkreise Pro Speicherzelle als DRAM. Dafür ist er wesendlich schneller (er muss auch nicht wieder "aufgefrischt" werden, das kostet Wartezyklen).

In der GPU will man eDRAM (embedded DRAM also eingebetteter DRAM Speicher) einbauen. Wie gesagt billiger und weniger Schaltkreise. Das sind ganz andere Dimmensionen. 16MB würden ca 100Mio Transistoren kosten, dafür bekommst du bei SRAM gerade mal 2MB.

Weiterhin waren das nur falsche Gerüchte, eDRAM wird bei den IHVs schon noch kommen, aber nicht so schnell und nicht gleich in so riesigen Mengen, immer Stückchenweise ;) ...denn es macht ja nicht so viel sinn, gleich soviel Chipfläche für Speicher zu "verschwenden" zumal immo die Füllrate der Flaschenhals ist.

[Mad-Marty]

268.435.456 Transistoren für das edram .... (2 transis per bit)

bzw. 134.217.728 Transis bei 1bit = 1 Transistor


Da fehlt aber noch die logik usw., das wären nur reine daten-speicher.


glaubt ihr doch selbst nicht, das das was wird, jedenfalls nicht mit 1400 Mhz. Auserdem sind bei > 300 M in 0,15 µm die leckströme der transistoren so gross, und der stromverbrauch so gigantisch, das das nicht kühlbar wäre - und 600 W Netzteil zwingend.
(ausgehend von 800 Mhz ....)

Selbst mit IBM's SOI halte ich das für äusserst fragwürdig.

Und der Fertigungsausschuss, dürfte dermassen gross sein,
das es nicht lohnen könnte.

[robbitop]

okok 134MIO Transistoren. eDRAM ist allerdings nicht so verbauchsintensiv wie andere Chipteile und die Frage nach Kühlbarkeit und verlustleistung lasse ich mal im Raum stehen...1400Mhz Takt für ne GPU??? zu utopisch

Man sollte für 130nm 150 vieleicht 200MIO Transistoren als Grenze sehen. Mit 16MB hat man bei 130nm und auch bei 90nm nicht mehr genug Transistoren für die Logikschaltkreise übrig.

D. Kirk hat schon oft gesagt, dass er lieber die Schaltkreise so effizient wie möglich nutzen will und das miente er im Zusammen hang mit HSR Einheiten für einen TBDR. Da wäre speicher für ihn sicher noch schlimmer ;)

So schnell wird niemand eDRAM in diesen Mengen verbauen.

[Ailuros]

Von der Theorie bis zur Praxis gibt es meistens so einige Abstaende. IHVs versuchen das beste zu tun fuer jede gewisse Zeitspalte mit was sie in ihrem Technologie-Portofolio haben und fuer einen sehr gewisses Preis-Niveau.

Es darf eben nicht mehr als maximal 400-500$ im schlimmsten Fall kosten fuer den Verbraucher, sonst waeren die Moeglichkeiten auch nicht so begrenzt, ueberhaupt heutzutage wo Shaders tonnenweise Transistoren verbrauchen.

Dabei verteidigt jeder IHV auch jegliche Entscheidungen was auch durchaus normal ist, jedoch hatten wir auch nie einen realen edram verpackten chip oder high end TBDR um irgendwelche Vergleich erstellen zu koennen.

Kirk und seine Teams verwenden aber trotzdem alles was moeglich ist und das wurde auch nie verleugnet. Hier mal ein uralter Ausschnitt:

Der GP-3 benoetigt fuer all die genannten Features gerade einmal 4 Millionen Gatter, weswegen er fuer hohe Taktfrequenzen praedestiniert ware, aber auch fuer low-cost Systeme in Betracht gezogen werden kann. Gigapixel spendierte dem GP-3 80 KB SRAM als Cache. Intern arbeitet der Chip ueber einen sogenannten "MO-BUS", eine Entwicklung von Gigapixel, welche sehr effiziente und flexible Kommunikation zwischen den einzelnen Teilen des Chips erlaubt.

http://www.3dconcept.ch/cgi-bin/showarchiv.cgi?show=763

Weiterentwicklungen dieser Cache Patenten wurden schon im NV25 verwendet und das mit den HSR Einheiten ist absoluter Quatsch und nur dumme Ausreden.

***edit:

Um Missverstaendnissen zu entgehen GP-3 war Hydra, und wurde mit dem Rampage Nachfolger in Fusion verschmolzen. Dabei verwendete man fuer Fusion Hierarchical Z/ Z Kompression und Geometrie Kompression. Alles auch nur Theorie da Gigapixel's Arbeit auch leider nur Vaporware war. MOJO waere wohl der idealste Platz fuer Ideen zu suchen (obwohl auch schon veraltet).

[robbitop]

selbst Fuison ist aus heutiger sicht veraltet, aber ein paar nette sachen sind sicher noch im Portfolio, die man nutzen könnte

[Ailuros]

Original geschrieben von robbitop
selbst Fuison ist aus heutiger sicht veraltet, aber ein paar nette sachen sind sicher noch im Portfolio, die man nutzen könnte

Genauso veraltet wie NV25 in dem Sinn. Wuerde man nach Kirk's Aussage gehen passt das ganze so ganz nicht mit mit nur 4M Gatter im GP-3 und den HSR Einheiten oder?

4*2 uebrigens fuer GP-3.

[robbitop]

wundere mich auch ..aber egal ;)