Voodoo Speicherverwaltung

[loewe]

Da wir ja gerade in einer Phase sind, in der so einige schon fast vergessene Technologien zurückkehren mal diese Frage. ;)

Ich suche seit einiger Zeit nähere Informationen zur Speicherverwaltung der Voodoo Karten von 3dfx, also wie genau mit wieviel Speicher für welche Bereiche die Voodoos was genau zu leisten im Stande waren.
Konnte leider nichts finden.

[Bokill]

Meinst du die Voodoo II oder die Voodoo I ... is ja nicht so klar.

Die anderen waren dann ja schon (fast) klassische AGP Grakas (auch wenn sie nicht alle Features von AGP beherrschten).

MFG Bokill

[loewe]

Eigentlich meine ich die Voodoo1, wobei sicher die Voodoo2 noch sehr ähnlich funktionierte, wenn auch andere Speichergrößen zum Einsatz kamen.

[del_4901]

2-8Mb für Texturen dabei 90Mhz EDO Rams ca. 60ns
2-4Mb für den Framebuffer. ... Voodoo1
Die V2 war etwa doppelt so schnell.

[mirp]

Vorhin hatte ich nach etwas ähnlichem gesucht und das hier gefunden:

http://www.molgen.mpg.de/~jacobs/3dchips/#VOODOO

[loewe]

@mirp

Danke etwas ähnliches hatte ich gesucht. :)

Auch so etwas läßt sich doch wieder aufwärmen. Wenn die Bandbreite ein Problem werden könnte, hier kann man doch lernen oder? ;)

[q@e]

Separate Busse?

Gibt's doch bei den Pro-Karten von 3Dlabs bsw. schon seit längerer Zeit (immer?).
Davon ab halte ich das auch für eine gute, allerdings sehr teuere Möglichkeit. AFAIK sollte das PCB-Design dadurch extrem verkompliziert werden.

Klar wäre es toll, einen embedded Speicher mit quasi beliebiger Breite für Z- und eine gewisse Anzahl AA-Buffer zu haben, sowie getrennte Speicherbusse bsw. pro PP.

[saaya]

wäre aber völliger unsinn ^^

die meisten leute benutzen noch immer kein aa, also wäre der speicher dann nicht benutzt. speicher ist teuer, und deswegen wird das niemals im mainstream markt anwendung finden.


3dlabs ist ne ausnahme, die sind für cad anwendungen und da die viel mit gittergrafiken arbeiten ist aa eigentlich immer an.

[loewe]

@saaya

Sag niemals nie!
Einfach auch mal in andere Richtungen denken, es gibt schon Bereiche wo es Sinn macht und diese von dir beschriebene Art der Verschwendung nicht relvant ist. :)

[Xmas]

Getrennte Speicherbusse läuft auf Multichip hinaus - mit all den bekannten Schwächen.

[q@e]

Notwendigerweise oder nur aus Erfahrung heraus?

[loewe]

Original geschrieben von Xmas
Getrennte Speicherbusse läuft auf Multichip hinaus - mit all den bekannten Schwächen.

Nein!
Nein natürlich zu Multichip. :)

[Xmas]

Original geschrieben von loewe
Nein!
Nein natürlich zu Multichip. :)
Wenn nicht Multichip, warum sollte man den Speicherbus dann auftrennen? Gut, prinzipiell kann man die heutigen Mehrkanal-Architekturen mit Crossbar Memory Controller auch als getrennte Speicherbusse betrachten, aber man hat ja dort dennoch einen gemeinsamen Speicherraum, und dieser wird für alle Arten von Daten benutzt. Unified Memory eben. Ich sehe absolut keinen Sinn darin, davon wieder abzukommen, zumal für WGF Unified Memory praktisch unumgänglich ist.

[loewe]

Kleiner Tipp: Bandbreite! :)

[Legolas]

Original geschrieben von loewe
Kleiner Tipp: Bandbreite! :)

Man kann auch so einfach die Breite des Speicherinterfaces erhöhen. Dazu braucht man keine getrennten Speicherbusse. Das breitere Speichersubsystem läßt sich dann ja per Crossbar-Controller effizient nutzen.

[zeckensack]

Original geschrieben von loewe
Kleiner Tipp: Bandbreite! :) Das macht aber nur dann Sinn, wenn man die Daten nicht zwischen den an den getrennten Bussen hängenden Speichern transferieren muss.
Eben render-to-texture, render-to-vertex buffer, etc, tätä, ist sehr problematisch.

Für Binning-Speicher, der ja sowieso temporärer Natur ist, wäre es aber überhaupt kein Problem :grübel: :D :)

[loewe]

Original geschrieben von zeckensack
Für Binning-Speicher, der ja sowieso temporärer Natur ist, wäre es aber überhaupt kein Problem :grübel: :D :)

:up:

[Xmas]

Original geschrieben von loewe
Kleiner Tipp: Bandbreite! :)
Und wie willst du damit die Bandbreite steigern? Mehr Bandbreite bekommst du mit mehr Pins, aber dafür muss man den Speicher nicht teilen.

Den einzigen Vorteil den ich bei getrennten Bussen sehe ist dass man den Memory Controller vereinfachen kann, weil nicht ständig auf verschiedene Speicherbereiche zugegriffen werden muss, womit auch etwas die Effizienz steigt. Was dann aber dadurch wieder verloren gehen dürfte, dass die Busse dann für spezielle Daten gedacht sind und häufig nicht gleichmäßig ausgenutzt werden, so dass ein gehöriger Teil der Bandbreite sinnlos verpufft.

[loewe]

@Xmas
Du weißt wovon hier gesprochen wird?

@zeckensack
Kannst du das vielleicht mal erklären oder ein wenig weiter denken, ich habe schon viel zuviel gesagt. :)

[Xmas]

Original geschrieben von loewe
@Xmas
Du weißt wovon hier gesprochen wird?
Ich gehe stark davon aus.

[GloomY]

Original geschrieben von loewe
Kleiner Tipp: Bandbreite! :) Ich glaube du gehst davon aus, dass mit dieser Aufteilung durch das Vorhandensein von zwei Speicherbussen insgesamt mehr Bandbreite verfügbar ist als nur bei nur einem Bus.
Wenn man zwei Busse realisiert, dann kann man mit den gleichen Kosten aber auch einen gemeinsamen breiten bauen, welcher die gleiche Bandbreite wie die zwei einzelnen zusammen besitzt.


Ich vermute, dass die Voodoo1/2 zwei (Voodoo1) bzw. drei (Voodoo²) verschiedene Speicherbusse hatte, weil es eben auch zwei bzw. drei Chips auf der Platine waren. Es ist einfacher jedem Chip sein eigenes Interface zu geben, als irgend eine Lösung zu konstruieren, wo ein gemeinsamer Speicherzugriff stattfinden würde (wer darf wann, welcher Speicherbereich für wen usw). Gerade wenn man die einzelnen Chips schon designed hat und dort ein Speicherinterface vorgesehen hat, hängt man eben wie im Falle der V² noch einen dritten Bus an den neu dazugekommenen zweiten TMU-Chip.
Also so eine Art Baukastenprinzip. ;)


(In diesem kompletten Posting bitte "Bus durch Punkt-zu-Punkt Verbindung" ersetzen. :) )

[zeckensack]

Original geschrieben von loewe
@zeckensack
Kannst du das vielleicht mal erklären oder ein wenig weiter denken, ich habe schon viel zuviel gesagt. :) Ein TBDR verbraucht vergleichsweise wenig Framebuffer-Bandbreite (Farbe/Z/Stencil). Die Geometriebandbreite ist wie bei IMRs.

Was ggü einem IMR hinzukommt ist Binning-Bandbreite. "Gegner" von TBDRs (wie zB Chalnoth ;)) sehen hier den grössten Schwachpunkt der Architektur.

Es gibt keinerlei technische Gründe, die getrennte Speichercontroller für a)Framebuffer und Quellgeometrie und b)Binning erschweren oder unmöglichen machen. Zwischen diesen beiden Nutzungen des externen Speichers gibt es keine Überschneidungen, und es fallen niemals Kopieraktionen an.


Allerdings sind die bereits genannten Einwände gegen hart getrennte Speichercontroller trotzdem gültig:
1)ungenutzter Speicherplatz und -bandbreite des einen Speicherbereichs kann nicht von dem anderen Bereich aufgesogen werden, und liegt somit brach.
2)Zwei Controller der Breite X sind nicht wesentlich billiger zu konstruieren als ein Controller der Breite X*2. Man verbraucht sogar mehr Pins. Es ergibt sich höchstens ein kleiner Vorteil im PCB-Layout.

Es ist auf jeden Fall sehr einfach machbar.
Ob es handfeste Vorteile bringt weiss ich nicht.