PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : NV30 - drei Chips!?!?! Mögliche Aufteilung :D :P ;)


zeckensack
2002-07-29, 09:43:17
God bless the Speku-Forum!

Es gab folgende Andeutung ganz kurz auf 3DChipset zu lesen (jetzt nicht mehr):
1)NV30 will be multiple Chips
2)There will be an uneven number of chips,
3)but less than eight

So, gehen wir mal davon aus, daß diese Info authentisch ist.
#1 spricht für sich selbst.
#3 schließt das Mitzählen der Speicherchips aus. Zur Geforce4Ti4200 könnte man sagen, sie besteht aus neun Chips.
#1 & #2 -> ungerade und >1

Naheliegend (und IMO die einzig brauchbare Lösung für dieses kleine Rätsel) wären also drei Chips.

Jetzt stellt sich die Frage, wie das Problem mit dem verteilten Speicherinterface gelöst werden soll. Sowohl die Geoeinheit, wie auch die Pixeleinheit brauchen viel Speicherbandbreite. Ich gehe übrigens davon aus, daß diese beiden Einheiten in mehreren Chips sitzen, da ich einen SLI-Ansatz für komplett falsch halte (siehe dazu Demirug's Ausführungen zu depth textures, aber auch die Notwendigkeit zur Verdoppelung der statischen Texturdaten).

Geometriedaten kommen über den AGP oder aus dem lokalen RAM (nur Lesezugriff) und durchlaufen folgende Stufen:
FF-T&L oder Vertex Shader
Primitive Assembly
Backface culling/Triangle Setup

Das ist das Maximum, was man ohne Frame-/Z-Bufferzugriffe machen kann, deswegen setze ich hier die Trennung zwischen Vertex- und Pixel-Einheit an.

Danach können sie an die Rastereinheit weitergehen, die sich mit Early-Z, Early-Stencil, Texturen, Pixel-Shadern, Fog und Blending befaßt.

Diese Einheit braucht Lese/Schreibzugriff auf den Framebuffer und die Texturdaten, kommt aber mit reinem Lesezugriff auf die vorgekauten Geometriedaten aus. Dh das Interface zwischen Geometrie- und Pixel-Einheit braucht nur unidirektional zu sein. Die Geoeinheit kann diese verarbeiteten Daten über einen dedizierten Bus in die Rastereinheit 'schieben', ohne daß diese jemals abgespeichert werden müssen.

Ich schlage folgende Varianten vor:
a)Widerspruch #1
1.kombinierter Geoprozessor/AGP/Speichercontroller
2.Rasterprozessor

Probläm:
Der Rasterprozessor muß einen bidirektionalen Bus zum Geoprozessor haben, um Texturen abzuholen und auf den Framebuffer/andere Rendertargets zugreifen zu können.
Außerdem natürlich Widerspruch zur Annahme, daß drei Chips vorhanden sind.

b)Widerspruch #2
1.Geoprozessor
2.kombinierter Rasterprozessor/AGP/Speichercontroller

Probläm:
Der Rasterprozessor muß einen bidirektionalen Bus zum Geoprozessor haben, um Geometriedaten an diesen zu übergeben und wieder abzuholen. Wieder der Widerspruch zur Annahme, daß drei Chips vorhanden sind. (Cöpy änd Päste rüle)

c)Naiv
1.Kombiniertes AGP-/Speicherinterface ( :=Arbiter)
2.Geometrieprozessor
3.Rasterprozessor

Probläm: Nur geringe Reduzierung der Komplexität. Für eine 'faire' Aufteilung der Bandbreite muß dieser Chip breite und schnelle Busse zu den beiden anderen Chips haben.

d)'meine' Idee
1.reines AGP-Interface
2.Geometrieprozessor mit eigenem Speicherinterface (32/64MB, 64bit DDR@200MHz)
3.Rasterprozessor mit eigenem Speicherinterface (>=128bit DDR, so schnell wie möglich)

Busse:
1->3: 8bit HT bidirektional @ 400MHz (800MB/s)
1->2: proprietäres unidirektionales Bussystem mit moderater Bandbreite (>=AGP8x), evtl 32bit HT @400MHz (3,2GB/s)
2->3: proprietär, unidirektional, so schnell wie nötig/möglich für guten Dreiecksdurchsatz. kA wieviel Bit man pro Dreieck schaufeln muß.

Begründung:
1.1)Das AGP-Interface leitet Geometriedaten an den Geoprozessor weiter, der diese entweder sofort verarbeitet, oder im eigenen RAM ablegt. Der Bus in diese Richtung sollte relativ schnell sein, muß aber nur unidirektional ausfallen. Schneller als der zugrundeliegende AGP8x braucht er nicht zu sein.
1.2)Das AGP-Interface leitet Texturdaten an den Rasterprozessor weiter. Dafür reicht ein vergleichsweise schmaler Bus, da sowohl AGP-Texturing wie auch (von der CPU generierte) dynamische Texturen von 99% aller Apps gemieden werden, wie das Weihwasser vom Teufel gemieden wird. Die Bandbreite in diese Richtung ist daher relativ wurscht, meistens wird im lokalen Texturspeicher gearbeitet. Dieser Bus muß bidirektional sein, weil das Zurücklesen von Texturen und Framebuffer (zB Screenshots) unterstützt werden muß, aber auch diese Richtung ist nicht performancekritisch und kann mit sehr geringer Bandbreite ausgelegt sein.
2)Die Geometrieeinheit braucht ein bisserl eigenen Speicher für statische Vertex-Buffer (und evtl Displacement-Maps). Da dieser Bus nicht mit der brutalen Rastereinheit geteilt werden muß, kann er im Vergleich mit den Vorgängern geradezu lächerlich ausfallen.
Rechenbeispiel:
250Mio Vertices/s unter Annahme von nur Position ergibt 250M*12 Bytes=3GB/s Bandbreitenbedarf, respektive 64bittiges DDR@200MHz.
Zum Vergleich: Eine Geforce4Ti4600 schafft unter gleichen Bedingungen maximal 35Mio Verts/s (reine Transformationsleistung ohne Post Cache-Effekte).

Indizien:
Wer sich etwas mit den Möglichkeiten der aktuellen NV-Karten auseinandersetzt (OpenGL-Forum lesen und nach VAR fragen), der weiß daß man maximal 32MB an lokalen Vertex-Buffern belegen kann (oder waren's 16MB und 32MB sind Maximum für AGP ???). Es existiert hier also bereits ein 'künstliches' Maximum, sodaß eine echte Trennung der Speicherbereiche keine zusätzlichen Hürden oder Probleme mit der Abwärtskompatibilität verursacht. Da sich NVIDIA sicher steigern will (und zusätzlich Platz für Displacement-Maps gebraucht wird), kann dieser Speicherbereich auch auf 64MB anwachsen. Dies ist trotzdem sehr billig zu haben, aufgrund der mundänen Taktrate und Bitbreite.

Richtig in die vollen gehen muß man dann nur beim Rasterizer, wie üblich.

Comments? Flames? Corrections?

Demirug
2002-07-29, 10:23:54
Sowas am frühen Morgen. schäm dich.

Die Frage die sich mir immer zuerst stellt wenn ich etwas von Mehrchiplösung höre ist: Warum?

Die einzigen Vorteile sind eine bessere Ausbeute bei der Produktion und eine Verteilung der Hotspots.

Aber nun zu deinen Vermutungen:

Den Einsatz eines eignen Memorycontroller nur für Geodaten halte ich eher für unwahrscheinlich. Bei Spielen die keine Statischen Geodaten benutzen (AFAIK DOOM III) wäre der Speicher verschenkt.

Meine Theorie wenn es wirklich mehrer Chips werden sollten:

1. Chip Systemconnector: Wahlweise AGP, PCI, PCI-X, usw)
2. Rendereinheit 1: 2 VS, 4/8 Fragmentpipelines, 64 Bit Memoryinterface, Verbindung (HT) zum Systemconnector
3. Fast Identisch mit 2 es fehlt nur die Verbindung zum Systemconnector

Die Chip 2 und 3 sind über eine 32 Bit HT2 verbindung gekoppelt. Die XBar im 2 Chip hat 4 Kanäle (Connector, 2Chip, Ram1, Ram2) die im zweiten Chip 3 (1Chip, Ram3, Ram4)

Für eine Profi Version läst sich der 32 Bit HT2 Bus in 2*16 Bit aufsplitten und erlaubt den weiteren Paarweisen Anschlus von Typ3 Chips. Bis zu maximal 6 Rendereinheiten.

ow
2002-07-29, 10:36:07
Spricht eigentlich irgendwas (APi,....) dagegen, die Aufteilung wie bei frueheren 3Dlabs Boards vorzunehmen?

a) Glint MX Rasterizer
b) Glint Gammma Geo-Prozessor + Glint MX Rasterizer
c) Glint Gammma Geo-Prozessor + 2x Glint MX Rasterizer

Demirug
2002-07-29, 10:48:01
Originally posted by ow
Spricht eigentlich irgendwas (APi,....) dagegen, die Aufteilung wie bei frueheren 3Dlabs Boards vorzunehmen?

a) Glint MX Rasterizer
b) Glint Gammma Geo-Prozessor + Glint MX Rasterizer
c) Glint Gammma Geo-Prozessor + 2x Glint MX Rasterizer

Von der API her nicht. Nur wie Zeckensack ja schon gesagt hat wird bei solchen Mehrchiplösungen die Speicherverwaltung kompliziert.

ow
2002-07-29, 10:53:45
Waere es denkbar, als zentrales Element einen Memory X-Bar einzusetzen, auf den die getrennten Geo- und Rasterizer Chips arbeiten?
Dann haette ich hinter dem X-Bar doch wieder ein unified memory.
Ist IMO ebenfalls aufwendig. Aber das sind Grafikchip heutzutage sowieso.:D

zeckensack
2002-07-29, 10:56:19
Originally posted by Demirug
Sowas am frühen Morgen. schäm dich.Nein :P ;)
Die Frage die sich mir immer zuerst stellt wenn ich etwas von Mehrchiplösung höre ist: Warum?

Die einzigen Vorteile sind eine bessere Ausbeute bei der Produktion und eine Verteilung der Hotspots.Weil es sich lohnen könnte? Wenn man die Nachteile (zusätzliche Busse, dadurch teureres PCB) minimieren kann, dann sehe ich da gute Chancen. Wenn Gleichzeitig sogar noch ein Performancevorteil entstehen könnte (den ich in meiner Variante d durchaus sehe), dann frage ich umgekehrt: Warum nicht?

Ich bin auch kein großer Freund der Idee an sich, ich halte MCM für wesentlich einfacher, wenn man nicht noch zusätzliche Boni reinbastelt.

Aber all dies geschah unter dieser Voraussetzung:So, gehen wir mal davon aus, daß diese Info authentisch ist.Ich wollte die Idee einfach mal verfolgen, um zu sehen was dabei herauskommt :)

Aber nun zu deinen Vermutungen:

Den Einsatz eines eignen Memorycontroller nur für Geodaten halte ich eher für unwahrscheinlich. Bei Spielen die keine Statischen Geodaten benutzen (AFAIK DOOM III) wäre der Speicher verschenkt.Richtig, aber das halte ich für wenig tragisch, wenn man derart billiges RAM benutzen kann. Pi mal Daumen 15$. Da der Speicherbus dafür nur einen einzigen Chip bedienen muß, kann er auf dem PCB völlig abseits liegen, führt also IMO nicht zu höherer Layer-Anzahl oder ähnlichen Problemen.
Meine Theorie wenn es wirklich mehrere Chips werden sollten:

1. Chip Systemconnector: Wahlweise AGP, PCI, PCI-X, usw)
2. Rendereinheit 1: 2 VS, 4/8 Fragmentpipelines, 64 Bit Memoryinterface, Verbindung (HT) zum Systemconnector
3. Fast Identisch mit 2 es fehlt nur die Verbindung zum Systemconnector


Die Chip 2 und 3 sind über eine 32 Bit HT2 verbindung gekoppelt. Die XBar im 2 Chip hat 4 Kanäle (Connector, 2Chip, Ram1, Ram2) die im zweiten Chip 3 (1Chip, Ram3, Ram4)

Für eine Profi Version läst sich der 32 Bit HT2 Bus in 2*16 Bit aufsplitten und erlaubt den weiteren Paarweisen Anschlus von Typ3 Chips. Bis zu maximal 6 Rendereinheiten.
Sorry, aber gegen solche Designs hast du dich AFAIK schon selbst gewehrt. Probleme mit Render to texture waren glaube ich ausschlaggebend. Jede Veränderung an einer Textur muß an die anderen Nodes weitergegeben werden, wodurch Bandbreite aufgefressen wird, ganz zu schweigen von der Speicherverschwendung, schließlich müssen sowieso alle Texturen gespiegelt werden.
Außerdem kann es für maximale Performance nur abträglich sein, wenn ich einen Speicherzugriff über mehrere Nodes hüpfen lassen muß.

Wenn man schon eine Trennung vornimmt, dann bitte so, daß wo sie keine neuen Probleme aufwirft.

PS: meine Idee würde sich sogar mit den Aussagen "256bit is overkill", "tiling is bad" etc decken :)

Demirug
2002-07-29, 11:05:31
@zeckensack:

Ich will kein SLI im 3dfx sinn haben. Mir schwebt da eher sowas wie beim Hammer vor. Das Hopping über die Knoten stell ich mir da nicht so Problematisch vor da es durch entsprechende Caches und etwas längere Pipelines zwischen den Einheiten ausgeglichen werden kann.

zeckensack
2002-07-29, 11:09:18
Originally posted by Demirug
@zeckensack:

Ich will kein SLI im 3dfx sinn haben. Mir schwebt da eher sowas wie beim Hammer vor. Das Hopping über die Knoten stell ich mir da nicht so Problematisch vor da es durch entsprechende Caches und etwas längere Pipelines zwischen den Einheiten ausgeglichen werden kann. Dann habe ich dich wohl falsch verstanden :)
Also meinst du zB, daß ein Pixelprozessor seine Ergebnisse im Zweifelsfall nicht nur in sein eigenes RAM, sondern in das RAM eines anderen Knotens schreiben kann, und Texturen auch über Fernabruf geholt werden?

HOT
2002-07-29, 11:13:59
Hmm.. jetzt hab ich auch noch ne Lösung :D

Meine Speku: 2 Rasterizer und eine Geometrieeinheit mit AGP Interface. Der Bus von Geometrieeinheit zu den Rasterizern ist gecached mit 4-16MB RAM (weiss net ob das mit HT geht).
Die 2 Rasterizer arbeiten im SLI Verfahren, haben aber gleichzeitig Zugriff auf die selben Texturdaten, ein Raterizer bietet übrgiens 4x2 Renderpipes und ein 128Bit LMAIII DDR/II Speicherinterface; wobei LMAIII Zugriffe der beiden Rasterizer koordiniert.

Vom Kostenfaktor her gesehen:
1.) man würde den Waver besser ausnutzen, da man kleinere Chips baut
2.) man würde vielleicht 500Pins pro Chip brauchen, aber keine 1000+, man könnte also weiterhin mit billigem BGA arbeiten
3.) man könnte die Rasterizer SEHR hoch takten, da sie wenig Transistoren bei 130nm liefern
4.) die Geometrieeinheit könnte weiterhin in 150nm gefertigt werden und brächte wahrscheinlich nichtmal Kühlung.
5.) das PCB bräuchte wahrscheinlich keine 10 Layer
6.) das Design ist skalierbar, man könnte einfach eine billigere Lösung in Form von 1x Geo und 1x Raster und 2x Geo und 4x Raster bauen.
7.) niedrig getaktete Rasterizer (300MHz) brächten keine Lüfter, passiv könnte reichen.

negativ:
1.) grosses PCB
2.) 3 Chips müssen getestet und verpackt werden

Fazit: in der jetzigen Zeit wäre es vermutlich billiger, eine Multichiplösung zu bauen, als einen 100Mio+ Monsterchip.

Demirug
2002-07-29, 11:19:31
Originally posted by zeckensack
Dann habe ich dich wohl falsch verstanden :)
Also meinst du zB, daß ein Pixelprozessor seine Ergebnisse im Zweifelsfall nicht nur in sein eigenes RAM, sondern in das RAM eines anderen Knotens schreiben kann, und Texturen auch über Fernabruf geholt werden?

Genau dieses meine ich.

zeckensack
2002-07-29, 11:44:47
@Demirug:
Aaaah sooo :)
Trotzdem hätte ich Angst (wenn auch nur, um meine eigene Idee zu verteidigen *eg* ), daß sich Pixel- und Geometrieprozessor gegenseitig den Speicherbus verstopfen (wie zB ganz extrem bei der Geforce2MX, aber sicherlich begrenzt auch bei aktuelleren Chips)).

@ow, HOT
Das mit dem zentralen Speicher-/AGP-Controller und daran angehängten Vertex- und Pixel-Einheiten halte ich für unvorteilhaft. Das war das was ich oben als "Möglichkeit c - naiv" umschrieben habe. Nochmal ausführlicher:

Dieser "Arbiter" müsste ein AGP-Interface, ein brachial schnelles Speicherinterface, eine sehr schnelle bidirektionale Anbindung an den Pixelprozessor und eine moderate Anbindung an den Geometrieprozessor haben, der wiederum eine recht flotte Anbindung an den Pixelchip braucht. Der 'Arbiter' hätte also alleine schon einen höheren Pincount als ein 'normaler' monolithischer Grafikchip, der mit 'nur' AGP, Speicher und RAMDAC-Out auskommt.

Das ist doch sehr unpassend, weil die höchste Bandbreite ausgerechnet da vorhanden ist, wo sie überhaupt nicht benutzt wird. Der Arbiter reicht diese schließlich nur weiter, die eigentlichen Konsumenten der Speicherbandbreite werden mit (Bus-)Strafzyklen belegt.

Außerdem hätte ausgerechnet der Chip mit dem geringsten Transistorcount (quasi Null Rechenleistung) den höchsten Pincount, wäre also extrem Pad-limitiert und dadurch gemessen am Ergebnis IMO viel zu groß=teuer.

Unter diesen Voraussetzungen hätte die Aufteilung auf mehrere Chips deswegen (wieder IMO) nur noch Nachteile.

HOT
2002-07-29, 11:58:30
Das hast du leider falsch verstanden :D

Der Geometriechip enthält die AGP/PCI(X) Bridge. Und zwar eine solche, die auch mehrere Geometrieprozessoren zusammenschliessen kann! Desweiteren hat der Geometriechip einen breiten gecachten Connect zu den Rasterizern, über die die komplette transformierte Datenflut zusammen mit den Texturdaten laufen.
Also rücktransport für AGP Texturing etc. reicht wie du schon sagtest ein kleiner bidirektionaler Connect. Denn kann man zusätzlich verdrahten; damit braucht der 2. (Slave) Rasterizer ja auch nicht in Berührung kommen.

Demirug
2002-07-29, 11:59:47
@zeckensack:

HT2 bei 32 parallelen Kanälen = 12,8 GByte/s (effektiv) in jede Richtung

Laborversion vor dem 17.05.2002 kam auf 20 GByte/s (effektiv) in jede Richtung

Sollte doch reichen auch wenn es sehr spekulativ ist das NVIDIA schon HT2 benutzt:D

zeckensack
2002-07-29, 12:16:33
Originally posted by Demirug
@zeckensack:

HT2 bei 32 parallelen Kanälen = 12,8 GByte/s (effektiv) in jede Richtung

Laborversion vor dem 17.05.2002 kam auf 20 GByte/s (effektiv) in jede Richtung

Sollte doch reichen auch wenn es sehr spekulativ ist das NVIDIA schon HT2 benutzt:D 32 parallele Kanäle? :o
Ich erlaube mir mal, die Pincounts für Hypertransport (bidirektional) hier niederzuschreiben :D
pins
8bit 24
16bit 42
32bit 76

edit: Ich sehe gerade, daß ein HT-Link @ 800MHz pro Bit 75mW Strom verbraten darf.

Hmmm ... 1024 Bits -> 75W :jedifire:

:D

edit2: 12,8GB/s, das sind ja nur 400MB/s pro Link. Lächerlich :-)

Demirug
2002-07-29, 12:32:02
@zeckensack:

AFAIK Sind sogar noch mehr Pins notwendig. Aber genau da liegt ja das Problem einen Effektiven Datentransfer zwischen den einzelnen Einheiten bei einer Multichiplösung hinzubekommen. Gerade im Zeitalter von HyperZ und LMA kann man ja kaum nach teile aus dem Hauptchip rausnehmen ohne gleich busse mit ordentlicher Kapazität zwischen den Chips einzurichten.

ow
2002-07-29, 13:06:56
ok, also:

Die Verbindungen zwischen den einzelnen Chips geschieht nur ueber optische Leiter, also mit extrem hoher Bandbreite. Spart ausserdem Pins.

Akzeptiert?
:D:D

zeckensack
2002-07-29, 15:17:17
Originally posted by Demirug
@zeckensack:

AFAIK Sind sogar noch mehr Pins notwendig. Aber genau da liegt ja das Problem einen Effektiven Datentransfer zwischen den einzelnen Einheiten bei einer Multichiplösung hinzubekommen. Gerade im Zeitalter von HyperZ und LMA kann man ja kaum nach teile aus dem Hauptchip rausnehmen ohne gleich busse mit ordentlicher Kapazität zwischen den Chips einzurichten. Also ich habe hier die HT-Spec rumfliegen (nach HT_IOLink_Spec.pdf googeln (oder googlen ?-))) und da steht, daß man pro 8 Datenleitungen eine Taktleitung braucht.
Das ganze dann in beide Richtungen.
Dann noch eine Leitung extra pro Richtung für ... ähh ... irgendwas anderes und schließlich vier Leitungen für nochwas anderes.

Macht bei acht Bit 2*(8+1+1)+4=24 Leitungen :liplick:

Demirug
2002-07-29, 15:22:32
@zeckensack:

Hast recht war die gesamte Hammer2Hammer Kommunikation die 103 Leitungen braucht.

Dr.Doom
2002-07-29, 16:47:42
Originally posted by zeckensack
Es gab folgende Andeutung ganz kurz auf 3DChipset zu lesen (jetzt nicht mehr):
1)NV30 will be multiple Chips
2)There will be an uneven number of chips,
3)but less than eight

Ich kenne den Kontext nicht, aber warum soll "NV30 will be multiple Chips" bedeuten, dass auf einer Karte die "GPU" in mehreren Chips untergebracht sein soll?

Das da oben könnte doch genauso bedeuten, dass es den NV30 in mehreren Ausführungen geben wird, so wie jetzt den NV25 ( ti4200 bis 4600 ).
Ti 4200, 4400 und 4600 ist "an uneven number of chips", nämlich genau gleich drei, und folglich sogar "less than eight".

*hardcore spekulier*

HOT
2002-07-29, 16:51:45
sollte man den NV30 wirklich wieder Chipset nennen können? ;)

zeckensack
2002-07-30, 10:01:44
Originally posted by HOT
sollte man den NV30 wirklich wieder Chipset nennen können? ;) Davon gehe ich hier aus :)
Wenn nicht, dann ist dieser Thread sowieso für die Tonne :D

zeckensack
2003-04-01, 11:29:24
Bump *eg*

Pussycat
2003-04-01, 21:51:47
ein April-bump?

Endorphine
2003-04-02, 01:07:17
Vielleicht ein fünfundsiebzig-Watt bump? *eg*

->>>>

Originally posted by zeckensack
32 parallele Kanäle? :o
Ich erlaube mir mal, die Pincounts für Hypertransport (bidirektional) hier niederzuschreiben :D
pins
8bit 24
16bit 42
32bit 76

edit: Ich sehe gerade, daß ein HT-Link @ 800MHz pro Bit 75mW Strom verbraten darf.

Hmmm ... 1024 Bits -> 75W :jedifire:

:D

edit2: 12,8GB/s, das sind ja nur 400MB/s pro Link. Lächerlich :-)

zeckensack
2003-04-02, 08:57:39
Originally posted by Pussycat
ein April-bump? Keineswegs ;)

Hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=63045) sind jedoch wieder aktuell Theorien über Multichip und MCM aufgekommen.
Da wollte ich meine 'alten Hirngespinste' beisteuern, sonst hätte ich sie ja nochmal neu schreiben müssen :bäh:
Ich habe diesen Thread hier auch von dem anderen aus verlinkt.

IMO ist 'mein' Vorschlag noch relativ brauchbar, da er vor allem auf die Einsparung von Package-Pins optimiert ist.