nVIDIAs memory controller (2GiB@192-Bit)

[Mad-Marty]

Hi,

ich lese immer wieder die 2 Theorien bezüglich des Memory Controllers bei asynchroner Bestückung bei Karten wie der 660 TI,
die von einer Performanceverringerung ausgingen wenn der letzte Block benutzt wird, der ja wesentlich mehr RAM an einem Kanal hat.


Ist es nicht sehr viel wahrscheinlicher, daß der memory controller ein interleaving betreibt? Das würde absolut konstante performance abliefern (in summe allerdings trotzdem geringer).

Ein Beispiel wie ich mir das vorstelle:
A = 64 bit 512 MB
B = 64 bit 512 MB
C = 64 bit 1024 MB

Wenn der controller jetzt einen Read oder Write request für 4096 KB durchführt:

A -> 1024 KB
B -> 1024 KB
C -> 2048 KB

Was denkt ihr?
Damit wäre die Performance absolut konstant und der gesamte Performancehit nicht so groß, da das Memory Interface ja nicht immer zu 100 % ausgelastet ist (verglichen mit dem "langsamen Bereich" ansatz).

[AnarchX]

Hier gibt es viel Lesematerial dazu: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9450375#post9450375

Im CUDA-Bandbreiten-Benchmark (nur ~300MiB Auslastung) ist die 2GiB@192-Bit Karte genauso schnell wie 3GiB@192-Bit: http://ht4u.net/reviews/2012/evga_geforce_gtx_660_ti_sc_3_gb_test/index5.php

[Mad-Marty]

Ok, der thread impliziert das genannte 1,5 GB im triple channgel interleave, und 512 MB nur als not-Ram via 1 channel.

Ich würde aber trotzdem behaupten das das 1:1:2 Szenario insgesamt bessere Ergebnisse abwerfen müsste (wegen nicht permanenter vollauslastung).

Allerdings weiss ich nicht wie kompliziert das ist so ein interleaving zu konstruieren?

Andere Meinungen, warum dieses oder das andere Insgesamt besser sein sollen gern erwünscht.

[Der_Korken]

Für mich sieht es so aus, als würde die Performance bei der 1:1:2-Aufteilung auf konstante 128-bit SI sinken. Wenn viel geschrieben wird, müssen die ersten beiden Controller ständig auf den dritten warten und verschenken damit selbst bei geringer Speicherauslastung wertvolle Bandbreite. Teilt man immer auf alle Controller auf, nutzt man grob 1,5GB VRAM mit voller Geschwindigkeit, was in der Praxis oft ausreicht. Also lieber oft schnell und manchmal lahm als immer ein bischen lahm.

[Coda]

Ich gehe nicht davon aus, dass die Performance sinkt. Sie werden da schon entsprechendes Load-Balancing machen.

[Simon Moon]

Sowieso ist eine 1:1:2 Aufteilung nicht sinnvoll. Sollten Memory Controller da nicht flexibel zugreifen können, wenn schon eine 3:3:2 Aufteilung.

[Gipsel]

Sowieso ist eine 1:1:2 Aufteilung nicht sinnvoll. Sollten Memory Controller da nicht flexibel zugreifen können, wenn schon eine 3:3:2 Aufteilung.
64Bit/3 = ??? ;)

[aths]

64Bit/3 = ??? ;)
Wieso /3? Eher *3. Man müsste für eine 2-GiB-Karte an eines der 64-Bit-Interfaces 512 MiB hängen und an die anderen beiden jeweils 768 MiB. Da liegt der Hase im Pfeffer. Es wäre sicherlich irgendwie möglich, 768 MiB an einen Controller zu hängen, aber die Adressierung stelle ich mir etwas komisch vor.

[Gipsel]

Wieso /3? Eher *3. Man müsste für eine 2-GiB-Karte an eines der 64-Bit-Interfaces 512 MiB hängen und an die anderen beiden jeweils 768 MiB. Da liegt der Hase im Pfeffer. Es wäre sicherlich irgendwie möglich, 768 MiB an einen Controller zu hängen, aber die Adressierung stelle ich mir etwas komisch vor.
Simon wollte an zwei der 64Bit-Controller 3 Speicherchips hängen (und an den anderen 2). Deswegen war die Frage 64/3=? schon die richtige. Das geht eben einfach nicht, wenn Du keine 21,333 Bit pro Chip liefern kannst. Und eine Bestückung mit 2 Chips im Clamshell-Modus und einem mit den vollen 32Bit hilft Dir auch nicht weiter. Das klappt nur (eventuell), wenn die Chips im Clamshell-Modus genau halb so groß sind wie der andere, man hat also auch entweder 512MB oder 1 GB am Controller hängen. 768 MB an einem 64 Bit Controller geht einfach nicht (GDDR5 erfordert Punkt-zu-Punkt-Verbindungen, das ist kein Bus mit Support von Daisy-Chaining). Deshalb ist eine symmetrische Bestückung erforderlich für die Funktionsweise. Man bräuchte 6x32Bit-Controller statt 3x64Bit, um andere Interleaving Schemata als oben dargestellt zu ermöglichen. Die haben aber heutige GPUs nicht.

[Mad-Marty]

Prinzipiell leuchtet natürlich ein, das 1:1:2 im schlechtesten fall A & B auf C warten müssten für 1 takt.
Da aber immer genug arbeit ansteht, greift da vielleicht ein OoO Prinzip und sie fetchen/schreiben daten in/aus einem Buffer?

Damit wäre der Performancehit praktisch nicht mehr vorhanden, bzw. die wartezeit auf C.

Das dürfte doch eigentlich alle Probleme weitgehend lösen ?!

[seaFs]

Hier hat Gipsel das schon ausführlich erklärt.
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9450579#post9450579
Weiter unten im Thread ist auch eine Aussage von nV selbst (ht4u-Link).

[aths]

Simon wollte an zwei der 64Bit-Controller 3 Speicherchips hängen (und an den anderen 2). Deswegen war die Frage 64/3=? schon die richtige. Das geht eben einfach nicht, wenn Du keine 21,333 Bit pro Chip liefern kannst. Und eine Bestückung mit 2 Chips im Clamshell-Modus und einem mit den vollen 32Bit hilft Dir auch nicht weiter. Das klappt nur (eventuell), wenn die Chips im Clamshell-Modus genau halb so groß sind wie der andere, man hat also auch entweder 512MB oder 1 GB am Controller hängen. 768 MB an einem 64 Bit Controller geht einfach nicht (GDDR5 erfordert Punkt-zu-Punkt-Verbindungen, das ist kein Bus mit Support von Daisy-Chaining). Deshalb ist eine symmetrische Bestückung erforderlich für die Funktionsweise. Man bräuchte 6x32Bit-Controller statt 3x64Bit, um andere Interleaving Schemata als oben dargestellt zu ermöglichen. Die haben aber heutige GPUs nicht.
Ob man an ein 64-Bit-Interface zwei 256-MiB-Bausteine hängt oder einen 512-MiB-Käfer oder vier 128-MiB-Chips ist doch nur ein schaltungstechnisches Detail. In diesem Fall müsste man einen schaltungstechnischen 1024-MiB-Chip ranhängen von dem aber nur 768 MiB nutzbar sind. (Oder zwei 512-MiB-Chips, von denen jeweils nur 384 MiB angesprochen werden können.)

[Gipsel]

Die Bitbreite des Speicherinterfaces betrifft doch die Datenbreite (Daten pro Takt) nicht die Adressbreite. Ob man an ein 64-Bit-Interface zwei 256-MiB-Bausteine hängt oder einen 512-MiB-Käfer oder vier 128-MiB-Chips ist doch nur ein schaltungstechnisches Detail. In diesem Fall müsste man einen schaltungstechnischen 1024-MiB-Chip ranhängen von dem aber nur 768 MiB nutzbar sind. (Oder zwei 512-MiB-Chips, von denen jeweils nur 384 MiB angesprochen werden können.)
Du willst also bei zwei Controllern von den angeschlossenen Speicherchips nur jeweils 3/4 der Kapazität nutzen? Dann verschwendest Du nur Kapazität (es ist praktisch ein künstliches Loch im Adressbereich), auf das Interleaving (und damit die Performance) hat das herzlich wenig Einfluß. Und man kann immer noch nicht 3 Chips an einen 64Bit Controller hängen. :rolleyes:
Achja, es gibt noch nicht so richtig DRAM-Bausteine mit einer Breite von 64Bit, ein 4GBit-Chip pro Controller geht also praktisch nicht.

Und zur Adressbreite, es gibt nur eine einzige Adresse beim Zugriff auf einen Controller. Alle Speicherchips an einem Controller erhalten also die gleiche Adresse. Wenn Du einer Hälfte des Controllers eine andere Adresse als der anderen Hälfte geben kannst, hast Du zwei Controller mit halber Breite ;). Insofern ist die nominelle Datenbreite eines Speichercontrollers natürlich auch gleich der minimalen Adressbreite (also die kleinste individuell adressierbare Einheit). Üblicherweise wird pro Adresse gleich erheblich mehr an Daten übertragen (eine ganze Cacheline = 512Bit = 64Byte, was dann die Granularität des Interleavings zwischen den Controllern sein dürfte), um die Effizienz zu steigern.

[Gipsel]

Prinzipiell leuchtet natürlich ein, das 1:1:2 im schlechtesten fall A & B auf C warten müssten für 1 takt.
Da aber immer genug arbeit ansteht, greift da vielleicht ein OoO Prinzip und sie fetchen/schreiben daten in/aus einem Buffer?

Damit wäre der Performancehit praktisch nicht mehr vorhanden, bzw. die wartezeit auf C.

Das dürfte doch eigentlich alle Probleme weitgehend lösen ?!
Nicht so richtig. Wenn irgendwelche Daten im Speicher an Controller x stehen, dann muß das auch von dort kommen. Da hilft keine OoOE oder sonstwas, wenn der Zugriff auf diesen Speicher das limitierende Element ist. Und wie verteilst Du denn die Sachen auf den Speicher an den verschiedenen Controllern am besten? Doch wohl so, daß immer etwa gleich viel von allen Controllern gelesen wird. Diese Zielanforderung kollidiert ziemlich augenscheinlich damit, daß an einem Controller doppelt so viel Speicher hängt. Verteilt man alles zufällig (oder gleichmäßig) auf den gesamten Speicher, muß zwangsläufig von dem Controller mit dem doppelten Speicher auch doppelt so viel gelesen werden wie von einem der anderen. In Situationen, in denen man in Bandbreitennot gerät, limitiert das also zwangsläufig.

Lösung: man nutzt erstmal nur die Hälfte des doppelten Speichers an dem einen Controller, also genau so viel wie an an den anderen auch hängt (am einfachsten über Interleaving zu erreichen). Die zusätzlichen 512MB werden nur angebrochen, wenn man damit Transfers über PCI-Express vermeiden kann, und dann bevorzugt für nur relativ sparsam benutzte Sachen.

[Mad-Marty]

Können die Memory Controller eigentlich sowas wie RVAs bei x86 memory virtualisierung?
Also mit virtuellen adressen umgehen, die per shaderprogramm o.ä. sind?

Wenn dann müsste diese "versuche eine memory adresse unter 1.5 GB zu benutzen bei malloc() ja rein der controller übernehmen, also ohne das die software darauf einfluß nehmen kann.


Sollte Gipsels beschreibung stimmen, dürfte die performance wenn man 1,5 GB daten mit statischem müll füllt und nur den rest verwendet ja exakt 1/3 sein.

Die Theorie mit "wenig benutzten daten in >1.5 GB Bereich schieben" halte ich für sehr unwahrscheinlich, normalerweise sind solche optimierungen zu aufwendig.

[Gipsel]

Allozieren von Speicher läuft immer über eine Routine des Betriebssystems (auf GPUs des Treibers), das kann ein Speichercontroller gar nicht alleine. Und die neueste Generation der Grafikkarten unterstützt schon schon mehr oder weniger die Virtualisierung des Speichers. Bei GCN ist über eine MMU sogar im Prinzip ein direkter (also ohne Treiberhilfe) Zugriff auf den pageable Speicher von x86er-CPUs möglich. Allerdings verstehe ich nicht so ganz, worauf Du bei Deiner Frage mit den RVAs hinaus willst (die spielen ja afaik bei der eigentlichen Ausführung eines Programmes keine Rolle mehr).

Übrigens können im Treiber hinterlegte Spieleprofile (die dann bei einem neuen Treiber der Grund für die "+xx% Performance"-Meldungen sind) sehr wohl Einfluß auf die Verteilung der Daten im Speicher nehmen. Glaube mal nicht, daß das nV zu mühsam wäre. ;)

[Simon Moon]

Du willst also bei zwei Controllern von den angeschlossenen Speicherchips nur jeweils 3/4 der Kapazität nutzen? Dann verschwendest Du nur Kapazität (es ist praktisch ein künstliches Loch im Adressbereich), auf das Interleaving (und damit die Performance) hat das herzlich wenig Einfluß.

Das ergäbe dann doch aber eine effektive Bandbreite von 160Bit über den vollen Speicher. Bzw. natürlich nicht, da die Speichercontroller natürlich trotzdem die vollen 1GB adressieren, es dann also effektiv einfach 1:2:2 wär. Ok, eine 1:1:2 erscheint wirklich sinniger.