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?
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?